Bug#919156: 404: pristine-tar: recommends -> depends or better error message

[Olaf van der Spek]

Op zo 13 jan. 2019 om 13:17 schreef Guido Günther :
> > pristine-tar is a recommends, not a depends, so it wasn't installed on
> > my system and it took quite some time to figure out why the
> > buildpackage was failing.
>
> pristine-tar is not required at all for gbp operation and people use it
> without it.

Isn't it required for some operations?

> If you disable recommends (it defaults to on in apt) you
> should be able to cope with such problems.

Is it worth it? What's the benefit?

> That said if somebody wants to come up with a better error message that
> fails upfront when pristine-tar is selected but not available I'm happy
> to apply it.

-- 
Olaf

Bug#919259: systemd: (Security?) update breaks systemd (inside unprivileged container?)

[matthijs]

Package: systemd
Version: 232-25+deb9u7
Severity: important

Hi folks,

this morning, some lxc containers on my machine did an unattended upgrade from
systemd 232-25+deb9u1 to version 232-25+deb9u7. As part of that upgrade,
systemd was reexecuted, which resulted in systemd freezing:

systemd[1]: Reloading.
systemd[1]: Reexecuting.
systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA 
+APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +
systemd[1]: Detected virtualization lxc.
systemd[1]: Detected architecture x86-64.
systemd[1]: Failed to create /../../init.scope control group: Operation not 
permitted
systemd[1]: Failed to allocate manager object: Operation not permitted
systemd[1]: Freezing execution.

Looking in my logs, the last time systemd was reexeuted like this was in 2017,
and neither of the error messages show above were present then.

This problem occurred inside all lxc containers running on the machine that
upgraded systemd. I suspect that the problem is related to running inside a
container, but the host has not upgraded systemd yet, so I cannot compare.

My containers run in unprivileged mode (e.g. without CAP_SYS_ADMIN and
others, see config below), which has caused some problems with systemd
in the past, so I suspect this is relevant in this case as well.

After the above happened, systemd froze (and is no longer reachable through
systemctl), but the systems are still running normally otherwise. I
haven't investigated more closely yet (e.g. restarting containers,
downgrading systemd, etc.), since I'm on a mobile connection now and
don't want risk breaking it further just yet.

I looked through the changelog from deb9u1 to deb9u7, and nothing springs out
as an obvious cause. Only the last update was a security update (relating to
the journal only), so this might be caused by one of the previous non-security
updates as well (which I did not have installed yet).

I'll investigate further soon. If you have suggestions on what changes might be
causing this, I'm happy to hear them.

Gr.

Matthijs

lxc config for one container:

  lxc.utsname = login.local
  lxc.rootfs = /containers/login
  lxc.console.logfile = /var/log/lxc/login.console
  lxc.logfile = /var/log/lxc/login.log
  lxc.network.type = veth
  lxc.network.flags = up
  lxc.network.veth.pair = lxc-login
  lxc.network.name = eth0
  lxc.network.link = br-lxc
  lxc.network.ipv4 = 10.42.0.16/24
  lxc.network.ipv4.gateway = auto
  lxc.network.script.up = /etc/lxc/enable-hairpin
  lxc.tty = 4
  lxc.pts = 256
  lxc.kmsg = 0
  lxc.autodev = 1
  lxc.cgroup.devices.deny = a
  lxc.cgroup.devices.allow = c 1:3 rwm
  lxc.cgroup.devices.allow = c 1:5 rwm
  lxc.cgroup.devices.allow = c 5:1 rwm
  lxc.cgroup.devices.allow = c 5:0 rwm
  lxc.cgroup.devices.allow = c 4:0 rwm
  lxc.cgroup.devices.allow = c 4:1 rwm
  lxc.cgroup.devices.allow = c 1:9 rwm
  lxc.cgroup.devices.allow = c 1:8 rwm
  lxc.cgroup.devices.allow = c 136:* rwm
  lxc.cgroup.devices.allow = c 5:2 rwm
  lxc.cgroup.devices.allow = c 254:0 rwm
  lxc.mount.auto = proc:rw
  lxc.mount.auto = sys:rw
  lxc.mount.auto = cgroup:mixed
  lxc.mount.entry = tmpfs dev/shm tmpfs rw,nosuid,nodev,create=dir 0 0
  lxc.mount.entry = tmpfs run tmpfs rw,nosuid,nodev,mode=755,create=dir 0 0
  lxc.mount.entry = tmpfs run/lock tmpfs 
rw,nosuid,nodev,noexec,relatime,size=5120k,create=dir 0 0
  lxc.mount.entry = debugfs sys/kernel/debug debugfs rw,relatime 0 0
  lxc.mount.entry = mqueue dev/mqueue mqueue rw,relatime,create=dir 0 0
  lxc.mount.entry = hugetlbfs dev/hugepages hugetlbfs rw,relatime,create=dir 0 0
  lxc.cap.drop = sys_module
  lxc.cap.drop = sys_rawio
  lxc.cap.drop = sys_time
  lxc.cap.drop = net_admin
  lxc.cap.drop = audit_control
  lxc.cap.drop = sys_admin

-- Package-specific info:

-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (990, 'stable'), (800, 'testing'), (700, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-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 systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3
ii  libaudit1   1:2.6.7-2
ii  libblkid1   2.29.2-1+deb9u1
ii  libc6   2.24-11+deb9u1
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcrypt20 1.7.6-2+deb9u3
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1+deb9u1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3+b3
ii  libsystemd0 232-25+deb9u7
ii  mount   2.29.2-1+deb9u1
ii  procps  2:3.3.12-3+deb9u1
ii  util-linux  2.29.2-1+deb9u1

Versions of packages systemd recommends:

Bug#822920: marked as done (lighttpd: compress should not be in main lightttpd.conf but in conf-available with a LOWER priority than SSI)

[Helmut Grohne]

Control: reopen -1

Hi Glenn,

On Sun, Jan 13, 2019 at 09:51:03PM +, Debian Bug Tracking System wrote:
> To: 822920-d...@bugs.debian.org
> 
> Package: lighttpd
> Version: lighttpd/1.4.35-4
> 
> fixed upstream in lighttpd 1.4.52-4

What seems like a good idea, is a bad one. Now the version tracking
refers to a version that doesn't exist yet (from an archive pov). The
usual process is as follows:

* If you fix a bug in git, you make sure that debian/changelog contains
  a suitable (Closes: #NN).
* Optional: A salsa web hook triggers some bot to tag the bug as
  pending to let others know that it is being worked on. This is not
  presently active for lighttpd, but we can activate it. I just don't
  happen to know how at the moment. I didn't find this worth spending
  time on thus far.
* When uploading the package, the changlog is forwarded to the bug
  tracking system and automatically closes the bug.

Therefore, please don't close bugs that are fixed in git. If anything,
tag them as pending (if fixed in packaging git) or fixed-upstream (if
fixed upstream). Please ensure that bugs are closed in debian/changelog.
You can either create the necessary changelog entry or use gbp-dch's
syntax, see man gbp-dch. Stefan prefers the latter.

I have created the necessary changelog entry for this particular bug. No
further action is needed here.

Thank you

Helmut

Bug#919257: RFS: antlr4-cpp-runtime/4.7.2-1 [ITP] -- ANTLR Parser Generator - C++ runtime support

[Andrius Merkys]

Package: sponsorship-requests
Severity: normal
Control: block 918109 by -1

Dear mentors,

I am looking for a sponsor for my package "antlr4-cpp-runtime". 
Package is required to update mysql-workbench (#902798).

 * Package name: antlr4-cpp-runtime
   Version : 4.7.2-1
   Upstream Author : Terence Parr
 * URL : http://www.antlr4.org
 * License : BSD-3-clause
   Section : libs

It builds those binary packages:

 libantlr4-runtime-dev - ANTLR Parser Generator - C++ runtime support 
(development files)
 libantlr4-runtime4.7.2 - ANTLR Parser Generator - C++ runtime support (shared 
library)

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

  https://mentors.debian.net/package/antlr4-cpp-runtime


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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/antlr4-cpp-runtime/antlr4-cpp-runtime_4.7.2-1.dsc

More information about antlr4-cpp-runtime can be obtained from 
https://www.example.com.

Changes since the last upload:

antlr4-cpp-runtime (4.7.2-1) unstable; urgency=medium

  * Initial release (Closes: #918109)

 -- Andrius Merkys   Thu, 03 Jan 2019 03:14:46 -0500

Regards,
Andrius Merkys

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#919234: [Pkg-freeradius-maintainers] Bug#919234: ttls fails with tls 1.3, enabled by default

[Michael Stapelberg]

I have no time to look into this. Can you send a patch please?

On Sun, Jan 13, 2019 at 11:33 PM Sam Hartman  wrote:

> package: freeradius
> severity: important
> version: 3.0.17+dfsg-1
> justification: regression that totally breaks connectivity
> tags: upstream
>
>
> I've cc'd Kurt because he requested openssl 1.3 test results a while
> back.
>
> While writing automated tests for moonshot-gss-eap, I discovered that
> by default freeradius will not constrain  the version of TLS in use
> (probably good), but that its ttls implementation fails with TLS 1.3.
> Things work fine if I explicitly set the max TLS version to 1.2.
>
> Based on the errors I suspect that  the issue had to deal with the
> handling of the ttls TLS session ticket used by TTLS for fast
> reauthentication.
> My suspicion (and recollection from the spec) is that ttls knows more
> about session internals than it should.
>
> As a quick fix, I think the ttls code should limit the maximum TLS
> version to 1.2 until the code can be fixed to work with 1.3.
>
>
> Please do not limit all freeradius uses of TLS to 1.2: in particular I'd
> really like to be able to use tls 1.3 with radsec.
> Also, I strongly recommend making this change in code not in config
> files.  People tend not to update their configs once they get one
> working.
>
> To reproduce, grab the moonshot-gss-eap sources.
> Comment out the TLS_MAX_VERSION on line 366 of
> debian/tests/freeradius/eap and then rerun autopkgtest on the resulting
> source package.
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>


-- 
Best regards,
Michael

Bug#919236: [Pkg-freeradius-maintainers] Bug#919236: Inappropriately broad default CA for EAP configuration

[Michael Stapelberg]

Can you send a patch please? It’s been like that since before I touched the
package.

On Sun, Jan 13, 2019 at 11:39 PM Sam Hartman  wrote:

> package: freeradius
> tags: security
> version: 3.0.17+dfsg-1
> severity: important
> justification: Inappropriately broad default authorization
>
> The debian freeradius package changes the default eap configuration to
> use the default list of Debian certification authorities as the default
> CAs for verifying client certificates for incoming EAP connections.
>
> The package leaves the following notice in
> /etc/freeradius/3.0/mods-available/eap:
>
> #  See also:
> #
> #  http://www.dslreports.com/forum/remark,9286052~mode=flat
> #
> #  Note that you should NOT use a globally known CA here!
> #  e.g. using a Verisign cert as a "known CA" means that
> #  ANYONE who has a certificate signed by them can
>
> And then proceeds to do something even worse: it sets the default CA to
> the entire list of Debian trusted CAs.
>
> As discussed by the freeradius docs, you want the default for EAP
> certificates to be an organization-specific CA.
>
> --Sam
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>


-- 
Best regards,
Michael

Bug#872191: [Freedombox-pkg-team] Bug#872191: plinth: Merge the Disks and Snapshots configuration tabs?

[Petter Reinholdtsen]

[Joseph Nuthalapati]
> It might not be a good idea to merge the snapshots feature into
> storage for the following reasons:

Interesting observations, but I miss how these arguments hold up when
seen from the users point of view.  My suggestion was based on my
experience as a user, wondering where my storage capacity disappered,
only to discover snapshots had filled up my disk with "invisible"
content.  I suspect users running out of space will, like me, visit the
'disk' menu to see if there is an explanation, and thus believe it
should be possible to see there how much space is spent on snapshots, as
well are purge some snapshots when running out of space.

-- 
Happy hacking
Petter Reinholdtsen

Bug#892656: even more tests fail with version 2.0.2

[Paolo Greppi]

Il 13/01/19 16:52, Paul Gevers ha scritto:
> user debian-rele...@lists.debian.org
> usertags 884543 bsp-2019-01-nl-venlo
> thanks
> 
> On Mon, 23 Apr 2018 14:36:00 +0200 Paolo Greppi 
> wrote:
>> So I'd propose we go straight for option #3 (downgrade node-is-descriptor to 
>> 1.0).
>> Can you do that please ?
> 
> Is this what needs to happen? Should this be packaged:
> https://github.com/jonschlinkert/is-descriptor/archive/1.0.2.tar.gz ?
> 
> Paul
> Sent from the BSP in Venlo

Hi Paul, seems like npm registry now has is-descriptor 3.0.0:
https://www.npmjs.com/package/is-descriptor

but even define-property 2.0.2 still wants is-descriptor 1.0.2:
https://github.com/jonschlinkert/define-property/blob/master/package.json#L27

Now that we consider acceptable to embed tiny node modules (and is-descriptor 
certainly is tiny) we have two options:
1. (old #3) downgrade node-is-descriptor to 1.0.2
2. remove node-is-descriptor 2.0.0 and embed is-descriptor 1.0.2 into 
node-define-property

Paolo

Bug#919195: cups: gutenprint driver nmo longer workin after upgrade

[Didier 'OdyX' Raboud]

Hi there Michal,

Le dimanche, 13 janvier 2019, 17.04:59 h CET Michal Suchanek a écrit :
> I upgraded cups from stable to testing and I am no longer able to print.
> 
> The driver used with stable was something like 'HP LaserJet 6MP
> CUPS+gutenprint v5.2' and after upgrade this driver is no longer
> available. There is something like 'HP LaserJet 6MP CUPS+gutenprint v5.3.2'
> (just different version number in the string) but it needs to be
> selected manually after upgrade. During upgrade I was required to type
> root password to do some upgrade but in spite of that the driver is not
> upgraded.

> Versions of packages cups recommends:
> ii  printer-driver-gutenprint5.3.1-6

This should be fixed by printer-driver-gutenprint 5.3.1-7 (#790045 / #918726); 
could you confirm this?

Cheers,
OdyX

Bug#919258: gnome-mahjongg: Can't change layout

[Richard]

Package: gnome-mahjongg
Version: 1:3.22.0-1
Severity: normal

Dear Maintainer,

Gmome-mahjongg is part of debian gnome destktop. I just start the game in
actual debian 9.6 standard desktop installation on a notebook.

When starting a mahjongg game, there is no way to select which layout to use.
It just starts with a default layout. At this time I right or left click about
everything to find a way to change the layout, but I cannot find any way to
change it.

The documentation on https://help.gnome.org/users/gnome-
mahjongg/stable/map.html.de claims, there should be a menu
mahjongg/einstellungen which allows to select one of 9 leyouts. I cannot find
such a menu.

When the game is finished, there is a pop-up window with title majongg. It
shows a dropdown to select the layout.

For one thing, in the dropdown, there is only two choices: easy and ziggurat!
Not nine layouts, like the mentioned documentation claims.

For the other thing, it does not matter which of the two layouts I select. When
I than press the new game button, it always starts a new game in the ziggurat
layout.

I expect to have the chance to select one of nine layouts, when starting the
game and I expect to select one of nine layouts when starting a new game after
finishing one. And I expect to play the layout, I selected.


I use debian, gnome and mahjongg for many years by now and I am afraid, the
problems do not actually come from the game itself, but have to do with the new
way gnome user interface changed from, gnome 2 to gnome 3.

Richard



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

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

Versions of packages gnome-mahjongg depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  libc62.24-11+deb9u3
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  librsvg2-2   2.40.16-1+b1

Versions of packages gnome-mahjongg recommends:
ii  yelp  3.22.0-1

gnome-mahjongg suggests no packages.

-- no debconf information

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

[Axel Beckert]

Package: dnssec-trigger
Version: 0.17+repack-1
Severity: serious

Setting up dnssec-trigger (0.17+repack-1) ...
Job for dnssec-triggerd.service failed because the control process exited with 
error code.
See "systemctl status dnssec-triggerd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript dnssec-triggerd, action "restart" failed.
# dnssec-triggerd.service - Reconfigure local DNSSEC resolver on connectivity 
changes
   Loaded: loaded (/lib/systemd/system/dnssec-triggerd.service; enabled; vendor 
preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2019-01-14 
07:20:18 CET; 16ms ago
  Process: 29431 ExecStartPre=/usr/lib/dnssec-trigger/dnssec-trigger-script 
--prepare (code=exited, status=0/SUCCESS)
  Process: 29438 ExecStart=/usr/sbin/dnssec-triggerd -d (code=exited, 
status=1/FAILURE)
  Process: 29439 ExecStartPost=/usr/lib/dnssec-trigger/dnssec-trigger-script 
--update_all (code=exited, status=0/SUCCESS)
  Process: 29443 ExecStopPost=/usr/lib/dnssec-trigger/dnssec-trigger-script 
--cleanup (code=exited, status=1/FAILURE)
 Main PID: 29438 (code=exited, status=1/FAILURE)
dpkg: error processing package dnssec-trigger (--configure):
 installed dnssec-trigger package post-installation script subprocess returned 
error exit status 1
Processing triggers for libc-bin (2.28-5) ...
Errors were encountered while processing:
 dnssec-trigger

I said "no" to the new dnssec-trigger.conf, but except comments the only
difference is the search domain setting:

$ diff /etc/dnssec-trigger/dnssec-trigger.conf 
/etc/dnssec-trigger/dnssec-trigger.conf.dpkg-dist 
28c28
< search: "deuxchevaux.org noone.org ethz.ch debian.org"
---
> # search: ""
51c51
< # check-updates: 
---
> # check-updates: no
65a66
> # These relay incoming DNS traffic on the other port numbers to the usual DNS
76a78,86
> 
> # Use VPN servers for all traffic
> # use-vpn-forwarders: no
> 
> # Forward RFC 1918 private addresses to global forwarders
> # use-private-addresses: yes
> 
> # Add domains provided by VPN connections into Unbound forward zones
> # add-wifi-provided-zones: no

The syslog shows again this:

Jan 14 07:18:59 c-cactus2 dnssec-triggerd[22039]: Jan 14 07:18:59 
dnssec-triggerd[22039] error: Error in SSL_CTX use_certificate_file crypto 
error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small

So maybe https://bugs.debian.org/898969 is not fully fixed yet?

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

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

Versions of packages dnssec-trigger depends on:
ii  gir1.2-nm-1.0   1.14.4-4
ii  libc6   2.28-5
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-7
ii  libglib2.0-02.58.2-3
ii  libgtk2.0-0 2.24.32-3
ii  libldns21.7.0-3.1+b1
ii  libssl1.1   1.1.1a-1
ii  python3 3.7.1-3
ii  python3-gi  3.30.4-1
ii  python3-lockfile1:0.12.2-2
ii  sensible-utils  0.0.12
ii  unbound 1.8.1-1+b1

dnssec-trigger recommends no packages.

dnssec-trigger suggests no packages.

-- Configuration Files:
/etc/dnssec-trigger/dnssec-trigger.conf changed:
search: "deuxchevaux.org noone.org ethz.ch debian.org"
url: "http://ster.nlnetlabs.nl/hotspot.txt OK"
url: "http://fedoraproject.org/static/hotspot.txt OK"
tcp80: 185.49.140.67
tcp80: 2a04:b900::10:0:0:67
ssl443: 185.49.140.67 
7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF
ssl443: 2a04:b900::10:0:0:67 
7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF


-- no debconf information

Bug#872191: plinth: Merge the Disks and Snapshots configuration tabs?

[Joseph Nuthalapati]

It might not be a good idea to merge the snapshots feature into storage
for the following reasons:

- Disk management and snapshots are different in functionality.
Snapshots is in fact more similar to Backups than to Storage.
- Snapshots already has a subsubmenu with 2 entries. Further nesting
into Storage will create an undesirable 2-level nesting. Or two tabs at
the top which are separate enough to be listed as two different apps.
- Operating systems that support snapshots do not combine it with
storage (Yast2 in OpenSuse and Time Machine in macOS)
- Once we open up the app store, we might have other applications which
do snapshots for different filesystems. Then snapper integrated into
storage might seem like preferential treatment to Btrfs.

We did merge the udiskie app into storage, since it is a utility related
to disk management.

-- 
Regards,
Joseph Nuthalapati



pEpkey.asc
Description: application/pgp-keys

Bug#919255: gnucap-python: please stop build-depending on python3.6

[Mattia Rizzolo]

Source: gnucap-python
Version: 0.0.2-1
Severity: serious
Control: block 916817 by -1

Deaer maintainer,

We would like to remove python3.6 from buster, so please drop the
build-depends on gnucap-python.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#905674: Citation notice FAQ

[Ole Tange]

Hi Kurt Fitzner

You question whether software should be cited and if so how?

These links suggest: Yes, you should cite software, and if the author
suggests a way of citing use that.

* 
https://blog.apastyle.org/apastyle/2015/01/how-to-cite-software-in-apa-style.html
* https://libguides.mit.edu/c.php?g=551454&p=3900280
* https://www.software.ac.uk/how-cite-software
* https://aut.ac.nz.libguides.com/APA6th/software
* https://libguides.rgu.ac.uk/c.php?g=380081&p=2983956
* https://journals.aas.org/policy-statement-on-software/
* https://guides.lib.monash.edu/c.php?g=219786&p=1454293
* https://www.maxqda.com/how-to-cite-maxqda

If you feel the benefit from using GNU Parallel is too small to
warrant a citation, then prove that by simply using another tool.

Here are other examples of software showing how to cite. Some of these
refer to peer-reviewed articles - others do not:

* https://www.scipy.org/citing.html
* https://octave.org/doc/interpreter/Citing-Octave-in-Publications.html
  (Octave has citation for individual packages, too)
* https://stat.ethz.ch/pipermail/r-help/2008-May/161481.html
* https://stat.ethz.ch/R-manual/R-devel/library/utils/html/citation.html
  (R has citation for individual packages, too)
* http://www.partek.com/citing-partek-software-in-a-publication/
* http://www.fluortools.com/misc/cite
* https://www.maxqda.com/how-to-cite-maxqda
* https://www.open-mpi.org/papers/
* https://www.tensorflow.org/about/bib
* http://www.fon.hum.uva.nl/paul/praat.html

I would think that most people, who appreciate GNU Parallel, would be
happy to help funding the development even if it is simply by making a
citation.

So what really puzzles me is: If you feel very strongly against
helping to fund future development of GNU Parallel, why not use an
alternative tool? No one forces you to use GNU Parallel. Here is a
list of alternatives to help you choose:
https://www.gnu.org/software/parallel/parallel_alternatives.html


You also pose it might be bad if more software asked for citations.

Let us make one thing abundantly clear: The reason for the citing
notice in GNU Parallel is _funding_ - not prestige of being cited in
an academic journal, as you hint. It has never been a secret and has
been explained from the start:
https://lists.gnu.org/archive/html/parallel/2013-11/msg6.html

If you find another way to pay my salary, so I can continue to devote
time to develop GNU Parallel, then I will have no objections to
removing the notice. So please help solve that problem. Not only will
it please me, but if you find a general solution, many other free
software developers will thank you for it.

Focusing on how we can get more free software funded is constructive.
Focusing on how we can remove funding for existing free software is
not.

It is unclear to me why you think that funding through citations
suddenly will be the prevailing way of funding, if Debian affirms GNU
Parallel's version of an 'OK. Do not show this again'-message (just
like the GUI-messages this message can be silenced in less than 10
seconds, and if you do not save more than 10 seconds by using GNU
Parallel, maybe you should not be using it anyway).

First of all, I think that is unrealistic that this sudden change will
happen (most other software is financed in different ways). But even
if it _did_ happen, then you would be free to use different tools (or
develop your own), if you prefer not to cite.

To me your email could be summarized as: "I do not want to help fund
the development, but I want to reap all the benefits - even if that
means killing the long term development."

To me it seems it is you whom Nadia Eghbal addresses in
https://www.slideshare.net/NadiaEghbal/consider-the-maintainer:

"Is it alright to compromise, or even deliberately ignore, the
happiness of maintainers so we that can enjoy free and open source
software?"


== Citation notice FAQ ==

> Why does GNU Parallel show a citation notice?

GNU Parallel is indirectly funded through citations. It is therefore
important for the long term survival of GNU Parallel that it is cited.
The citation notice makes users aware of this.

See also: https://lists.gnu.org/archive/html/parallel/2013-11/msg6.html


> Is the citation notice compatible with GPLv3?

Yes. The wording has been cleared by Richard M. Stallman to be
compatible with GPLv3. This is because the citation notice is not part
of the license, but part of academic tradition.

Therefore the notice is not adding a term that would require citation
as mentioned on:
https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation


> Do automated scripts break if the notice is not silenced?

No. Not a single time has that happened. This is due to the notice
only being printed, if the output is to the screen - not if the output
is to a file or a pipe.


> How do I silence the citation notice?

Run this once:

  parallel --citation

It takes less than 10 seconds to do and is thus comparable to an 'OK.
Do not show this again'-dial

Bug#917500: liggghts: FTBFS (style_atom.h: No such file or directory)

[Anton Gladky]

Hello Santiago,

thanks for the reporting it. Unfortunately I am not able
to reproduce the described error. It builds just fine and the
recent upload into Debian did not identified the problems
with the package [1].

Please give some more information, how can it be reproduced.

Thanks

[1] https://buildd.debian.org/status/package.php?p=liggghts

Anton

Am Fr., 28. Dez. 2018 um 00:57 Uhr schrieb Santiago Vila :
>
> Package: src:liggghts
> Version: 3.8.0+repack1-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> I tried to build this package in buster but it failed:
>
> 
> [...]
>  debian/rules build-indep
> dh build-indep --buildsystem=cmake 
> --builddirectory=/<>/liggghts-3.8.0+repack1/debian/build
>dh_update_autotools_config -i -O--buildsystem=cmake 
> -O--builddirectory=/<>/liggghts-3.8.0\+repack1/debian/build
>dh_autoreconf -i -O--buildsystem=cmake 
> -O--builddirectory=/<>/liggghts-3.8.0\+repack1/debian/build
>dh_auto_configure -i -O--buildsystem=cmake 
> -O--builddirectory=/<>/liggghts-3.8.0\+repack1/debian/build
> cd debian/build && cmake -DCMAKE_INSTALL_PREFIX=/usr 
> -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
> -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
> -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
> "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
> -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ../..
> -- The C compiler identification is GNU 8.2.0
> -- The CXX compiler identification is GNU 8.2.0
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
>
> [... snipped ...]
>
> CMAKE_EXPORT_NO_PACKAGE_REGISTRY
>
>
> -- Build files have been written to: 
> /<>/liggghts-3.8.0+repack1/debian/build
>dh_auto_build -i -O--buildsystem=cmake 
> -O--builddirectory=/<>/liggghts-3.8.0\+repack1/debian/build
> cd debian/build && make -j1 "INSTALL=install --strip-program=true"
> make[1]: Entering directory 
> '/<>/liggghts-3.8.0+repack1/debian/build'
> /usr/bin/cmake -S/<>/liggghts-3.8.0+repack1 
> -B/<>/liggghts-3.8.0+repack1/debian/build --check-build-system 
> CMakeFiles/Makefile.cmake 0
> /usr/bin/cmake -E cmake_progress_start 
> /<>/liggghts-3.8.0+repack1/debian/build/CMakeFiles 
> /<>/liggghts-3.8.0+repack1/debian/build/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[2]: Entering directory 
> '/<>/liggghts-3.8.0+repack1/debian/build'
> make -f src/CMakeFiles/libliggghts.dir/build.make 
> src/CMakeFiles/libliggghts.dir/depend
> make[3]: Entering directory 
> '/<>/liggghts-3.8.0+repack1/debian/build'
> cd /<>/liggghts-3.8.0+repack1/debian/build && /usr/bin/cmake -E 
> cmake_depends "Unix Makefiles" /<>/liggghts-3.8.0+repack1 
> /<>/liggghts-3.8.0+repack1/src 
> /<>/liggghts-3.8.0+repack1/debian/build 
> /<>/liggghts-3.8.0+repack1/debian/build/src 
> /<>/liggghts-3.8.0+repack1/debian/build/src/CMakeFiles/libliggghts.dir/DependInfo.cmake
>  --color=
> Scanning dependencies of target libliggghts
> make[3]: Leaving directory '/<>/liggghts-3.8.0+repack1/debian/build'
> make -f src/CMakeFiles/libliggghts.dir/build.make 
> src/CMakeFiles/libliggghts.dir/build
> make[3]: Entering directory 
> '/<>/liggghts-3.8.0+repack1/debian/build'
> [  0%] Building CXX object src/CMakeFiles/libliggghts.dir/angle.cpp.o
> cd /<>/liggghts-3.8.0+repack1/debian/build/src && /usr/bin/mpicxx  
> -Dlibliggghts_EXPORTS -DvtkIOGeometry_AUTOINIT="1(vtkIOMPIParallel)" 
> -DvtkIOParallel_AUTOINIT="1(vtkIOMPIParallel)" 
> -DvtkRenderingCore_AUTOINIT="3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL)"
>  -I/usr/include/vtk-6.3 -I/usr/include/freetype2 
> -I/usr/include/x86_64-linux-gnu -I/usr/include/hdf5/openmpi 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/include/jsoncpp 
> -I/usr/include/eigen3 -I/<>/liggghts-3.8.0+repack1 
> -I/<>/liggghts-3.8.0+repack1/src  -g -O2 
> -fdebug-prefix-map=/<>/liggghts-3.8.0+repack1=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2  -DLAMMPS_VTK6 -DLAMMPS_VTK -std=c++0x -DLAMMPS_JPEG 
> -fPIC   -o CMakeFiles/libliggghts.dir/angle.cpp.o -c 
> /<>/liggghts-3.8.0+repack1/src/angle.cpp
> [  0%] Building CXX object src/CMakeFiles/libliggghts.dir/angle_hybrid.cpp.o
> cd /<>/liggghts-3.8.0+repack1/debian/build/src && /usr/bin/mpicxx  
> -Dlibliggghts_EXPORTS -DvtkIOGeometry_AUTOINIT="1(vtkIOMPIParallel)" 
> -DvtkIOParallel_AUTOINIT="1(vtkIOMPIParallel)" 
> -DvtkRenderingCore_AUTOINIT="3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL)"
>  -I/usr/include/vtk-6.3 -I/usr/include/freetype2 
> -I/usr/include/x86_64-linux-gnu -I/usr/include/hdf5/openmpi 
> -I/usr/lib/x86_64-

Bug#919115: linux-image-4.19.0-0.bpo.1-amd64-unsigned: Graphical glitches (lightdm and cinnamon) after upgrading linux (RadeonRX540)

[N G]

Some details on the lightdm/lockscreen issue.

I just noticed that if I switch to tty1 and go back to lightdm 
everything is displayed properly, or well, that's what I thought at 
first, because when I tried to click something or even type, it was 
unresponsive, it's like a frozen frame, basically, like a lightdm's 
screenshot.  I could still notice the cursor responding to text areas, 
so I could as well login successfully since lightdm is actually running.

 From my deeply ignorant point of view, that 'black screen' at the 
beginning it's more like the last 'frame' from the booting process,  
after that, it never refreshes and appears to be pure blackness. If I go 
tty mode, and go back to lightdm it refreshes graphically for a second, 
but still, no animations at all, no text, no menus, nothing, like 
clicking/typing on a picture, except for the cursor which seems to be 
working correctly.

This is from journalctl, every time I go from lightdm/cinnamon's 
lockscreen to tty and vice versa.

#tty1

14 00:10:31 debian kernel: [drm] PCIE GART of 256M enabled (table at 
0x00F4).
14 00:10:31 debian kernel: [drm] UVD and UVD ENC initialized successfully.
14 00:10:31 debian kernel: [drm] VCE initialized successfully.
14 00:10:38 debian kernel: amdgpu :03:00.0: GPU pci config reset

#back to lockscreen (lightdm gives the same output)

14 00:11:03 debian kernel: [drm] PCIE GART of 256M enabled (table at 
0x00F4).
14 00:11:03 debian kernel: [drm] UVD and UVD ENC initialized successfully.
14 00:11:03 debian kernel: [drm] VCE initialized successfully.
14 00:11:10 debian kernel: amdgpu :03:00.0: GPU pci config reset

Bug#919254: chkrootkit: Fix for incorrectly initialized variable in chk_tcpd()

[Francois Marier]

Package: chkrootkit
Version: 0.52-2
Severity: normal
Tags: patch

Under certain circumstances, the CMD variable in chk_tcpd is incorrectly
initialized and this leads to a false positive: erroneously reported an
infected tcpd.

The attached patch fixes this for me in Ubuntu 18.04 but it makes sense to
include it in Debian as well.

Thanks to
https://www.linuxquestions.org/questions/linux-security-4/chkrootkit-tcpd-521683/page2.html#post5788733
for identifying the problem.

Link to the Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/1808882

Francois

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

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

Versions of packages chkrootkit depends on:
ii  binutils   2.31.1-11
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.28-4
ii  net-tools  1.60+git20180626.aebd88e-1
ii  openssh-client 1:7.9p1-4
ii  procps 2:3.3.15-2

chkrootkit recommends no packages.

chkrootkit suggests no packages.

-- debconf information:
  chkrootkit/diff_mode: false
  chkrootkit/run_daily_opts: -q
* chkrootkit/run_daily: false
Author: Francois Marier 
Description: Reinitialize variable in check_tcpd
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/1808882

--- a/chkrootkit	2019-01-13 14:30:39.608931525 -0800
+++ b/chkrootkit	2019-01-13 15:05:53.496917560 -0800
@@ -2588,6 +2588,7 @@
 chk_tcpd () {
 STATUS=${NOT_INFECTED}
 TCPD_INFECTED_LABEL="p1r0c4|hack|/dev/xmx|/dev/hdn0|/dev/xdta|/dev/tux"
+CMD=
 
 [ -r ${ROOTDIR}etc/inetd.conf ] &&
 CMD=`${egrep} '^[^#].*tcpd' ${ROOTDIR}etc/inetd.conf | _head -1 | \

Bug#919253: RM: postbooks [kfreebsd-amd64 kfreebsd-i386 hurd-i386] -- RoQA; Obsolete Qt4 cruft

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Built with Qt5 on other archs.

Scott K

Bug#919252: RM: brewtarget [kfreebsd-amd64 kfreebsd-i386] -- RoQA; Obsolete Qt4 cruft

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Package is updated for Qt5 on other archs.

Scott K

Bug#919251: RM: bibletime [kfreebsd-amd64 kfreebsd-i386] -- RoQA; Obsolete Qt4 cruft

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Package is updated for Qt5 on other archs.

Scott K

Bug#919250: RM: qtscriptgenerator -- RoQA; Obsolete, unmaintained, RC buggy

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Last maintainer upload was in 2012.  Package has been out of Testing for 15
months and will not return.  This is an obsolete, unmaintained Qt4 package
that should be removed.

Scott K

Bug#917406: RFS: elinks/0.13~20180825-1 [UPDATE]

[أحمد المحمودي]

Hello,

 I am adopting elinks. I have worked on the fork that Moritz has 
 mentioned: https://github.com/rkd77/felinks
 I have emailed previous upstream maintainers,asking them if they are 
 still maintaining elinks. Two emails bounced back, and I still got no 
 reply from the others.
 Anyways, this upload is targetting experimental, as I have enabled 
 several features like Bittorrent and Javascript.

Last changelog entry is:
elinks (0.13~20180825-1) experimental; urgency=medium

  * New upstream release (Closes: #891575, #797931, #797934, #757631,
#866015, #797968, #740981, #865852)
  * Add git-buildpackage conf file
  * Refreshed patches & removed patches that were includes upstream.
Removed patches:
08-drop-deprecated-gnutls-functions.diff (Closes: #879539)
08_524696_fix_imdb_urls.diff
09-Switch-to-use-lua-5.1.diff
  * Add libgcrypt20-dev to build deps
  * Re-added 14_debug_disable_Werror.diff to enable development versions debug
support
  * Added 16_POST_BUFFER_SIZE.diff patch which to enable  uploading large files
over https:// connections.
  * Add ascii-replacement-utf8-console.diff patch to print ASCII replacement
for characters not found in current codepage in utf8 mode
  * Enable LZMA support
  * Enable BitTorrent
  * Enable NNTP Support
  * Enable Unicode combining characters support
  * Enable EX mode support
  * Enable SpiderMonkey support
  * Enable terminfo support
  * Build documentation
  * Build with libev
  * Bumped to compat level 12.
No need to have dh-autoreconf, autotools-dev from build deps
Also no need to explicitly call the respective sequences in rules
  * Remove old upstream gpg key.
  * Remove whitespaces
  * Renamed elinks.config to elinks.conf, old name confused build scrips
  * debian/rules: Override dh_installexamples to exclude .gitignore
  * Add typos.diff patch to fix spelling mistakes
  * debian/control:
+ Replace Conflicts with Breaks+Replaces
+ Update standards version to 4.3.0
+ New maintainer (Closes: #917406)
+ Add Vcs-* fields
  * Add upstream metadata
  * Switch to DEP-5 copyright format

There is one lintian warning:
W: elinks-data: manpage-has-errors-from-man usr/share/man/man5/elinks.conf.5.gz 
1166: warning [p 14, 7.0i]: can't break line

The package is on: g...@salsa.debian.org:aelmahmoudy-guest/elinks.git , 
felinks branch

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#917406: RFS: elinks/0.13~20180825-1 [UPDATE]

[أحمد المحمودي]

Hello,

 I am adopting elinks. I have worked on the fork that Moritz has 
 mentioned: https://github.com/rkd77/felinks
 I have emailed previous upstream maintainers,asking them if they are 
 still maintaining elinks. Two emails bounced back, and I still got no 
 reply from the others.
 Anyways, this upload is targetting experimental, as I have enabled 
 several features like Bittorrent and Javascript.

Last changelog entry is:
elinks (0.13~20180825-1) experimental; urgency=medium

  * New upstream release (Closes: #891575, #797931, #797934, #757631,
#866015, #797968, #740981, #865852)
  * Add git-buildpackage conf file
  * Refreshed patches & removed patches that were includes upstream.
Removed patches:
08-drop-deprecated-gnutls-functions.diff (Closes: #879539)
08_524696_fix_imdb_urls.diff
09-Switch-to-use-lua-5.1.diff
  * Add libgcrypt20-dev to build deps
  * Re-added 14_debug_disable_Werror.diff to enable development versions debug
support
  * Added 16_POST_BUFFER_SIZE.diff patch which to enable  uploading large files
over https:// connections.
  * Add ascii-replacement-utf8-console.diff patch to print ASCII replacement
for characters not found in current codepage in utf8 mode
  * Enable LZMA support
  * Enable BitTorrent
  * Enable NNTP Support
  * Enable Unicode combining characters support
  * Enable EX mode support
  * Enable SpiderMonkey support
  * Enable terminfo support
  * Build documentation
  * Build with libev
  * Bumped to compat level 12.
No need to have dh-autoreconf, autotools-dev from build deps
Also no need to explicitly call the respective sequences in rules
  * Remove old upstream gpg key.
  * Remove whitespaces
  * Renamed elinks.config to elinks.conf, old name confused build scrips
  * debian/rules: Override dh_installexamples to exclude .gitignore
  * Add typos.diff patch to fix spelling mistakes
  * debian/control:
+ Replace Conflicts with Breaks+Replaces
+ Update standards version to 4.3.0
+ New maintainer (Closes: #917406)
+ Add Vcs-* fields
  * Add upstream metadata
  * Switch to DEP-5 copyright format

There is one lintian warning:
W: elinks-data: manpage-has-errors-from-man usr/share/man/man5/elinks.conf.5.gz 
1166: warning [p 14, 7.0i]: can't break line

The package is on: g...@salsa.debian.org:aelmahmoudy-guest/elinks.git

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#919249: security issue: instability and crash due to crafted message flooding

[Chris Knadle]

Package: mumble
Version: 1.2.19-3
Severity: important
Tags: security fixed-upstream fixed-in-experimental


It is currently possible to cause mumble-server to freeze and/or crash by
sending specifically it crafted commands, leading to a denial of service.
The server usually automatically recovers, however it has been reported that
in some instances it can take up to an hour after the attack has ended.
The attack can be done remotely and does not need special permissions.

All versions of mumble 1.2.x and 1.3.0 snapshots prior to 2018-08-31 are 
affected.



signature.asc
Description: OpenPGP digital signature

Bug#919248: RM: ruby-bcat -- ROM; dead upstream, dependency failure

[Hideki Yamane]

package: ftp.debian.org
X-debbugs-CC: pkg-ruby-extras-maintain...@lists.alioth.debian.org

Hi,

 Please ruby-bcat package that I maintain.

 ruby-aruba, the only package that build-depends on ruby-bcat is
 updated and it drops its dependency, so we can remove ruby-bcat
 package safely now.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane

Bug#919247: kthresher: cronjob exits with error after package removal

[Andreas Beckmann]

Package: kthresher
Version: 1.3.1-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your packages cronjob exits with
error after the package has been removed.

>From the attached log (scroll to the bottom...):

0m28.1s INFO: Package kthresher contains cron file: /etc/cron.daily/kthresher
0m28.1s DEBUG: Starting command: ['chroot', '/srv/piuparts/tmp/tmpTGHRnl', 
'/etc/cron.daily/kthresher']
0m28.1s ERROR: Command failed (status=1): ['chroot', 
'/srv/piuparts/tmp/tmpTGHRnl', '/etc/cron.daily/kthresher']


cheers,

Andreas


kthresher_1.3.1-2.log.gz
Description: application/gzip

Bug#919246: oss4-dkms: module FTBFS for Linux 4.19

[Andreas Beckmann]

Package: oss4-dkms
Version: 4.2-build2017-1
Severity: serious
Justification: fails to build from source
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

the oss4-dkms kernel module fails to build for Linux 4.19:

DKMS make.log for oss4-4.2-build2017 for kernel 4.19.0-1-amd64 (x86_64)
Mon Jan 14 04:22:16 UTC 2019
make: Entering directory '/usr/src/linux-headers-4.19.0-1-amd64'
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_core.o
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/os_linux.o
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_ac97.o
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_audio_core.o
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_audiofmt.o
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_grc3.o
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_spdif.o
/var/lib/dkms/oss4/4.2-build2017/build/core/os_linux.c: In function 
'osdev_create_201502111816':
/var/lib/dkms/oss4/4.2-build2017/build/core/os_linux.c:162:10: warning: 
assignment discards 'const' qualifier from pointer target type 
[-Wdiscarded-qualifiers]
  devpath = oss_pci_read_devpath (osdev->dip);
  ^
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_default_timer.o
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_midi_core.o
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_midi_mapper.o
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_midi_parser.o
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_midi_queue.o
/var/lib/dkms/oss4/4.2-build2017/build/core/oss_core.c: In function 
'oss_get_uid':
/var/lib/dkms/oss4/4.2-build2017/build/core/oss_core.c:479:23: error: 
dereferencing pointer to incomplete type 'const struct cred'
   return current->cred->uid.val;
   ^~
/var/lib/dkms/oss4/4.2-build2017/build/core/oss_core.c: In function 
'oss_timeout':
/var/lib/dkms/oss4/4.2-build2017/build/core/oss_core.c:570:3: error: implicit 
declaration of function 'init_timer'; did you mean 'init_timers'? 
[-Werror=implicit-function-declaration]
   init_timer (&tmout->timer);
   ^~
   init_timers
/var/lib/dkms/oss4/4.2-build2017/build/core/oss_core.c:572:15: error: 'struct 
timer_list' has no member named 'data'
   tmout->timer.data = id | (timeout_random & ~0xff);
   ^
/var/lib/dkms/oss4/4.2-build2017/build/core/oss_core.c:573:25: error: 
assignment to 'void (*)(struct timer_list *)' from incompatible pointer type 
'void (*)(long unsigned int)' [-Werror=incompatible-pointer-types]
   tmout->timer.function = oss_timer_callback;
 ^
  CC [M]  /var/lib/dkms/oss4/4.2-build2017/build/core/oss_midi_timers.o
cc1: some warnings being treated as errors
make[3]: *** 
[/usr/src/linux-headers-4.19.0-1-common/scripts/Makefile.build:308: 
/var/lib/dkms/oss4/4.2-build2017/build/core/oss_core.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [/usr/src/linux-headers-4.19.0-1-common/Makefile:1532: 
_module_/var/lib/dkms/oss4/4.2-build2017/build/core] Error 2
make[1]: *** [Makefile:146: sub-make] Error 2
make: *** [Makefile:8: all] Error 2
make: Leaving directory '/usr/src/linux-headers-4.19.0-1-amd64'


Andreas

Bug#918502: golang-github-opencontainers-runtime-tools: autopkgtest needs update for new version of golang-github-hashicorp-go-multierror

[Arnaud Rebillout]

I pushed some changes to Salsa:


  * New upstream version 0.8.0+dfsg
  * Update patches
  * Add patch to build against hashicorp-multierror 1.0

Can someone upload this package, as I'm just DM and I don't have
permission for that?

I CC Dmitry as he's the original author of the package, but really, any
DD from the Go team should feel free to tag a release and upload.

For more context:

There was very little changes upstream between 0.7 to 0.8, and no
changes at all in the vendor tree, so the update was rather trivial.
Additionally, we actually don't use this package (yet) to build any
other package, so nothing can possibly break.

Thanks,

  Arnaud

Bug#919060: same problem here...

[Pirate Praveen]

On 2019, ജനുവരി 13 11:26:54 PM IST, Dragos Jarca 
 wrote:
>after apt-get update and apt-get dist-upgrade...
>
>now gitlab cannot be used...

This is a different issue, please open a new bug.

>cannot upgrade to experimental to...
>
>root@omv:/usr/share/gitlab# apt-get install ruby-gitaly=1.5.0+dfsg-1 
>ruby-responders ruby-default-value-for=3.1.1-1 ruby-devise 
>ruby-doorkeeper ruby-doorkeeper-openid-connect ruby-recaptcha 
>ruby-devise-two-factor ruby-browser ruby-graphiql-rails 
>ruby-acts-as-taggable-on ruby-redis-rails ruby-asana=0.8.1-1 
>ruby-kubeclient=4.2.0-1 ruby-webpack-rails ruby-sass-rails 
>ruby-font-awesome-rails ruby-premailer-rails ruby-rails-i18n=5.1.2-1 
>ruby-peek ruby-peek-gc ruby-peek-pg ruby-peek-rblineprof
>ruby-peek-redis 
>ruby-lograge ruby-actionmailer=2:5.2.2+dfsg-1 
>ruby-actionpack=2:5.2.2+dfsg-1 ruby-actionview=2:5.2.2+dfsg-1 
>ruby-activemodel=2:5.2.2+dfsg-1 ruby-activerecord=2:5.2.2+dfsg-1 
>ruby-activesupport=2:5.2.2+dfsg-1 ruby-activestorage ruby-actioncable 
>ruby-activejob=2:5.2.2+dfsg-1 ruby-railties=2:5.2.2+dfsg-1 
>ruby-sprockets-rails ruby-rack=2.0.6-3 ruby-rails=2:5.2.2+dfsg-1 
>gitlab-common=11.6.0+dfsg-1 ruby-rails-dom-testing=2.0.3-3 
>ruby-arel=9.0.0-2 ruby-http=3.3.0-1 ruby-http-form-data=2.1.0-1 
>rails=2:5.2.2+dfsg-1 gitlab=11.6.0+dfsg-1 gitaly=1.12.0+debian-1 
>ruby-actionpack-xml-parser=2.0.1-1 redmine
>ruby-protected-attributes=1.1.4-2
>Reading package lists... Done
>Building dependency tree
>Reading state information... Done
>ruby-sprockets-rails is already the newest version (2.3.2-1).
>ruby-sprockets-rails set to manually installed.
>ruby-graphiql-rails is already the newest version (1.4.10-1).
>ruby-graphiql-rails set to manually installed.
>redmine is already the newest version (3.4.6-1).
>ruby-acts-as-taggable-on is already the newest version (5.0.0-2).
>ruby-acts-as-taggable-on set to manually installed.
>ruby-browser is already the newest version (2.5.3-1).
>ruby-browser set to manually installed.
>ruby-devise is already the newest version (4.5.0-1).
>ruby-devise set to manually installed.
>ruby-devise-two-factor is already the newest version (3.0.3-1).
>ruby-devise-two-factor set to manually installed.
>ruby-doorkeeper is already the newest version (4.4.2-1).
>ruby-doorkeeper set to manually installed.
>ruby-doorkeeper-openid-connect is already the newest version (1.5.2-1).
>ruby-doorkeeper-openid-connect set to manually installed.
>ruby-font-awesome-rails is already the newest version (4.7.0.4-1).
>ruby-font-awesome-rails set to manually installed.
>ruby-lograge is already the newest version (0.10.0-1).
>ruby-lograge set to manually installed.
>ruby-peek is already the newest version (1.0.1-1).
>ruby-peek set to manually installed.
>ruby-peek-gc is already the newest version (0.0.2-1).
>ruby-peek-gc set to manually installed.
>ruby-peek-pg is already the newest version (1.3.0-1).
>ruby-peek-pg set to manually installed.
>ruby-peek-rblineprof is already the newest version (0.2.0-1).
>ruby-peek-rblineprof set to manually installed.
>ruby-peek-redis is already the newest version (1.2.0-1).
>ruby-peek-redis set to manually installed.
>ruby-premailer-rails is already the newest version (1.9.7-1).
>ruby-premailer-rails set to manually installed.
>ruby-protected-attributes is already the newest version (1.1.4-2).
>ruby-protected-attributes set to manually installed.
>ruby-recaptcha is already the newest version (4.11.1-1).
>ruby-recaptcha set to manually installed.
>ruby-redis-rails is already the newest version (5.0.2-3).
>ruby-redis-rails set to manually installed.
>ruby-responders is already the newest version (2.4.0-3).
>ruby-responders set to manually installed.
>ruby-sass-rails is already the newest version (5.0.6-2).
>ruby-sass-rails set to manually installed.
>ruby-webpack-rails is already the newest version (0.9.11+git-1).
>ruby-webpack-rails set to manually installed.
>Some packages could not be installed. This may mean that you have
>requested an impossible situation or if you are using the unstable
>distribution that some required packages have not yet been created
>or been moved out of Incoming.
>The following information may help to resolve the situation:
>
>The following packages have unmet dependencies:
>  ruby-protected-attributes : Depends: ruby-activemodel (< 2:5.0) but 
>2:5.2.2+dfsg-1 is to be installed
>E: Unable to correct problems, you have held broken packages.
>root@omv:/usr/share/gitlab#
>
>Seems that is a incopatibility between gitlab and redmine...
>
>I try to use in production and now my team cannot commit changes.

This is because we could not get gitlab working with rails 5.2 in time for 
uploading rails 5.2 to unstable. Since transitions freeze was approaching, we 
did not have a choice to wait for gitlab, as gitlab will not be in buster 
anyway.

Rails 5.2 support is in progress by upstream, and as soon as it is complete we 
will upload it to unstable.

unstable is expected to have such temporary breakages from time 

Bug#919245: xdvi.1: Use the correct style macro for a single argument

[Bjarni Ingi Gislason]

Package: texlive-binaries
Version: 2018.20181218.49446-1
Severity: minor
Tags: patch

Dear Maintainer,

  the font-alternating macros are for two fonts and thus for two or more
arguments.

  See man-pages(7) for a style guide and an appropriate man-page for
the use of man-macros, for example groff_man(7).

--- xdvi.1  2019-01-14 02:13:33.0 +
+++ xdvi.1.new  2019-01-14 02:17:07.0 +
@@ -597,7 +597,7 @@ Same as
 .BR -fg .
 .\"""
 .TP
-.BI \-fullscreen
+.B \-fullscreen
 When this option is used, xdvi will (try to) run in fullscreen mode, with
 no window decorations.
 This option is not guaranteed to work with all windowmanagers/desktops;
@@ -794,7 +794,7 @@ List the names of all fonts used.
 Prints licensing information.
 .\"""
 .TP
-.BI \-linkcolor
+.B \-linkcolor
 .RB ( .linkColor )
 Color used for unvisited hyperlinks (`Blue2' by default). Hyperlinks
 are unvisited before you click on them, or after the DVI file has been 
reloaded.
@@ -808,7 +808,7 @@ and
 .BR \-linkstyle .
 .\"""
 .TP
-.BI \-linkstyle
+.B \-linkstyle
 .RB ( .LinkStyle )
 Determines the style in which hyperlinks are displayed. Possible
 values and their meanings are:
@@ -823,9 +823,9 @@ values and their meanings are:
 .sp 1n
 .fi
 The values for \fIlink color\fR are specified by the options/resources
-.BI \-linkcolor
+.B \-linkcolor
 and
-.BI \-visitedlinkcolor
+.B \-visitedlinkcolor
 (which see).
 .\"""
 .TP
@@ -1058,7 +1058,7 @@ to
 .\"""
 .\"""
 .TP
-.BI \-noomega
+.B \-noomega
 .RB ( .omega )
 This will disable the use of Omega extensions when interpreting DVI files.
 By default, the additional opcodes
@@ -1137,7 +1137,7 @@ to
 .BR tempFile:on .)
 .\"""
 .TP
-.BI \-notype1fonts
+.B \-notype1fonts
 .RB ( .type1 )
 This will disable the use of the FreeType library to display PostScript
 Type 1 fonts.
@@ -1344,7 +1344,7 @@ Determines the color of the rules used f
 (default: foreground color).
 .\"""
 .TP
-.BI \-q
+.B \-q
 .RB ( .noInitFile )
 Ignore the
 .I $HOME/.xdvirc
@@ -1453,7 +1453,7 @@ extensions in both filenames.
 Otherwise, if one of the filenames does contain a path component (e.g.:
 .IR ./test.tex ,
 .IR ../test.tex ,
-.IR /my/homedir/tex/test.tex
+.I /my/homedir/tex/test.tex
 or any combination of these), both filenames are expanded to a full path,
 with any occurrences of
 .I ../
@@ -1546,7 +1546,7 @@ controlling a remote instance of xdvi li
 currently ignored.
 .\"""
 .TP
-.BI \-useTeXpages
+.B \-useTeXpages
 Use logical \*(Te\& pages (the values of the
 .I \ecount0
 register) instead of physical pages for the pagelist labels and
@@ -1558,12 +1558,12 @@ This option can be toggled via the
 keystroke.
 .\"""
 .TP
-.BI \-version
+.B \-version
 Print information on the version of
 .BR xdvi .
 .\"""
 .TP
-.BI \-visitedlinkcolor
+.B \-visitedlinkcolor
 .RB ( .visitedLinkColor )
 Color used for visited hyperlinks (`Purple4' by default). Hyperlinks become
 visited once you click on them. As for
@@ -1838,7 +1838,7 @@ move forward
 history items.
 .\"""
 .TP
-.BR ^
+.B ^
 .RB [ home() ]
 Move to the ``home'' position of the page.  This is normally the upper
 left-hand corner of the page, depending on the margins as described in the
@@ -3129,7 +3129,7 @@ These specify the time (in milliseconds)
 stay open after the
 .B dvips
 process has terminated. The value of
-.BR dvipsHangTime
+.B dvipsHangTime
 is used if the process terminates successfully;
 .B dvipsFailHangTime
 is used if it terminates with an error. The default values are 1.5 and 5 
seconds, respectively.
@@ -3931,7 +3931,7 @@ string may contain the format string
 .IR %s ,
 which will be replaced by the file name.
 .TP
-.BI needsterminal
+.B needsterminal
 If this flag is used, the command will be executed in a new xterm
 window by prepending
 .RI `` "xterm -e "''



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

Kernel: Linux 4.9.144-1 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh

Bug#919244: RM: tomboy/experimental -- RoQA; unmaintained, depends on ancient GNOME libraries

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-CC: tom...@packages.debian.org

Please remove tomboy from experimental. It was removed from unstable 2
months ago. The experimental version has the same problems as the
unstable version.

https://bugs.debian.org/907316

Thanks,
Jeremy Bicha

Bug#918502: golang-github-opencontainers-runtime-tools: autopkgtest needs update for new version of golang-github-hashicorp-go-multierror

[Arnaud Rebillout]

Thanks for the report,

I'm looking into that. The FTBFS is not fixed by updating
opencontainers-runtime-tools to the latest version (0.8).

Actually, the issue is that opencontainers-runtime-tools is using an
outdated vendored copy of hashicorp-go-multierror. It doesn't build out
of the box against the latest version of multierror. I'm cooking a
little patch for that to work.

Bug#919243: Acknowledgement (resolvconf: man page missing important /etc/resolv.conf.d/ information)

[Pedro Ribeiro]

Sorry, made a mistake on the directory, I am referring to:
/etc/resolvconf/resolv.conf.d/


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

Bug#919242: update

[martian]

Seems to work when i run

$ aa-disable quassel-core

Seems the AppArmor profile is insufficient when quassel-core is ran by a 
regular user.

Bug#919243: resolvconf: man page missing important /etc/resolv.conf.d/ information

[Pedro Ribeiro]

Package: resolvconf
Version: 1.79
Severity: important

The man page of resolvconf is missing important information regarding
/etc/resolv.conf.d/

It appears the man page from other OS contains information about these
directories:
https://unix.stackexchange.com/a/128223

   /etc/resolvconf/resolv.conf.d/base
  File  containing  basic  resolver  information.  The lines in this
  file are included in the resolver configuration file even when no
  interfaces are configured.

   /etc/resolvconf/resolv.conf.d/head
  File to be prepended to the dynamically generated resolver
  configuration file.  Normally this is just a comment line.

   /etc/resolvconf/resolv.conf.d/tail
  File to be appended to the dynamically generated resolver
  configuration file.  To append nothing, make this  an  empty
  file.   This file is a good place to put a resolver options line
  if one is needed, e.g.,

  options inet6

This is very useful information for configuration, can you please add it to the
man page?

Thanks!



-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (750, 'stable'), (650, 'testing'), (600, 'unstable'), (550, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.20-grsec-botto+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages resolvconf depends on:
ii  cdebconf [debconf-2.0]  0.227
ii  debconf [debconf-2.0]   1.5.61
ii  ifupdown0.8.19
ii  init-system-helpers 1.48
ii  lsb-base9.20161125

resolvconf recommends no packages.

resolvconf suggests no packages.

-- Configuration Files:
/etc/resolvconf/resolv.conf.d/head changed [not included]

-- debconf information excluded

Bug#919242: quassel-core: fails to start, permission errors

[martian67]

Seems to work when i run

$ aa-disable quassel-core

Seems the AppArmor profile is insufficient when quassel-core is ran by a 
regular user.

Bug#918570: python3-sklearn-lib: dependency on libblas3 | libblas.so.3 instead of libatlas3-base?

[Stuart Prescott]

> some libraries of this package are linked to libcblas.so.3.
> Could this be replaced by linking to libblas.so?
> Could this package depend on libblas3 | libblas.so.3 instead of
> libatlas3-base?

Additionally, in a no-change rebuild of the package currently in sid 
(0.20.1+dfsg-1), the config output around finding the linear algebra packages 
has changed compared to the existing build in sid. I've not looked further to 
see what the consequence of this is.

## Previously:

x86_64-linux-gnu-gcc -pthread _configtest.o -lf77blas -lcblas -latlas -o 
_configtest
ATLAS version 3.10.3 built by buildd on Wed Jul 25 10:48:47 UTC 2018:
   UNAME: Linux binet 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) 
x86_64 GNU/Linux
   INSTFLG  : -1 0 -a 1 -l 1
   ARCHDEFS : -DATL_OS_Linux -DATL_ARCH_x86SSE2 -DATL_CPUMHZ=2400 -DATL_SSE2 -
DATL_SSE1 -DATL_USE64BITS -DATL_GAS_x8664
   F2CDEFS  : -DAdd_ -DF77_INTEGER=int -DStringSunStyle
   CACHEEDGE: 1048576
   F77  : /usr/bin/gfortran, version GNU Fortran (Debian 8.1.0-12) 8.1.0
   F77FLAGS : -g -O2 -fdebug-prefix-map=/build/atlas-cewjNG/atlas-3.10.3=. -
fstack-protector-strong -m64 -fPIC
   SMC  : /usr/bin/gcc, version gcc (Debian 8.1.0-12) 8.1.0
   SMCFLAGS : -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/
build/atlas-cewjNG/atlas-3.10.3=. -fstack-protector-strong -m64 -fPIC
   SKC  : /usr/bin/gcc, version gcc (Debian 8.1.0-12) 8.1.0
   SKCFLAGS : -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/
build/atlas-cewjNG/atlas-3.10.3=. -fstack-protector-strong -m64 -fPIC
success!
removing: _configtest.c _configtest.o _configtest.o.d _configtest
customize UnixCCompiler
customize UnixCCompiler
  FOUND:
language = c
define_macros = [('HAVE_CBLAS', None), ('ATLAS_INFO', '"\\"3.10.3\\""')]
libraries = ['f77blas', 'cblas', 'atlas', 'f77blas', 'cblas']
library_dirs = ['/usr/lib/x86_64-linux-gnu']

accelerate_info:
  NOT AVAILABLE

  FOUND:
language = c
define_macros = [('HAVE_CBLAS', None), ('ATLAS_INFO', '"\\"3.10.3\\""')]
libraries = ['f77blas', 'cblas', 'atlas', 'f77blas', 'cblas']
library_dirs = ['/usr/lib/x86_64-linux-gnu']



## Now:

x86_64-linux-gnu-gcc -pthread _configtest.o -L/usr/lib/x86_64-linux-gnu -
lf77blas -lcblas -latlas -o _configtest
customize UnixCCompiler
customize UnixCCompiler
  FOUND:
libraries = ['f77blas', 'cblas', 'atlas', 'f77blas', 'cblas']
library_dirs = ['/usr/lib/x86_64-linux-gnu']
language = c
define_macros = [('HAVE_CBLAS', None), ('NO_ATLAS_INFO', -1)]

accelerate_info:
  NOT AVAILABLE

  FOUND:
libraries = ['f77blas', 'cblas', 'atlas', 'f77blas', 'cblas']
library_dirs = ['/usr/lib/x86_64-linux-gnu']
language = c
define_macros = [('HAVE_CBLAS', None), ('NO_ATLAS_INFO', -1)]



I'm not quite sure what to make of these changes but the bigger problem is 
that as a result of not finding these libraries correctly, the build-system 
accidentally leaves behind two sets of files that are finding their way into 
the binary package:

/usr/lib/python2.7/dist-packages/_configtest
/usr/lib/python2.7/dist-packages/_configtest.c
/usr/lib/python2.7/dist-packages/_configtest.o
/usr/lib/python3/dist-packages/_configtest
/usr/lib/python3/dist-packages/_configtest.c
/usr/lib/python3/dist-packages/_configtest.o

(and they absolutely should not be there).

Do the build-deps need tweaking here?

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#874219: jxplorer: debian/watch is out of date

[tony mancill]

Package: jxplorer
Followup-For: Bug #874219

Hi,

I'm seeing as much activity on the SourceForge page for jxplorer [1] as
I am for the Github page [2], so I'm not sure whether we need to change
the watch file unless maybe the upstream authors express a preference.

I agree that the release of version 3.3.02 in Debian as 3.3.2 and then
the subsequent upstream release of version 3.3.1.2 is unfortunate.
We'll figure something out to get the version updates.

Thank you for the bug report.
tony

[1] https://sourceforge.net/projects/jxplorer/files/jxplorer/
[2] https://github.com/pegacat/jxplorer


signature.asc
Description: PGP signature

Bug#919242: quassel-core: fails to start, permission errors

[martian]

Package: quassel-core
Version: 1:0.13.0-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When attempting to start quassel-core as a regular user,
it is unable to start, errors below (note occurs without any config files
present. Permissions on the .config directory are drwxr-xr-x  martian:martian
so this is not the issue.

2019-01-13 18:31:03 [Error] Unable to create Quassel config directory: 
/home/martian/.config/quassel-irc.org
2019-01-13 18:31:03 [Warn ] SslServer: Certificate file quasselCert.pem does 
not exist 
2019-01-13 18:31:03 [Warn ] SslServer: Unable to set certificate file
   Quassel Core will still work, but cannot provide SSL for client 
connections.
   Please see https://quassel-irc.org/faq/cert to learn how to enable 
SSL support. 
2019-01-13 18:31:03 [Error] Unable to create Quassel config directory: 
/home/martian/.config/quassel-irc.org
2019-01-13 18:31:03 [Warn ] SslServer: Certificate file quasselCert.pem does 
not exist 
2019-01-13 18:31:03 [Error] Unable to create Quassel config directory: 
/home/martian/.config/quassel-irc.org
2019-01-13 18:31:03 [Warn ] PostgreSQL driver plugin not available for Qt. 
Installed drivers: QSQLITE 
2019-01-13 18:31:03 [Error] Unable to create Quassel config directory: 
/home/martian/.config/quassel-irc.org
2019-01-13 18:31:03 [Error] Unable to create Quassel config directory: 
/home/martian/.config/quassel-irc.org
2019-01-13 18:31:03 [Error] Unable to create Quassel config directory: 
/home/martian/.config/quassel-irc.org
2019-01-13 18:31:03 [Warn ] No storage backend selected! 
2019-01-13 18:31:03 [Error] "Cannot write quasselcore configuration; probably a 
permission problem."

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: arm64 (aarch64)

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

Versions of packages quassel-core depends on:
ii  adduser3.118
ii  libc6  2.28-4
ii  libgcc11:8.2.0-14
ii  libqca-qt5-2   2.1.3-2
ii  libqt5core5a   5.11.3+dfsg-2
ii  libqt5network5 5.11.3+dfsg-2
ii  libqt5script5  5.11.3+dfsg-2
ii  libqt5sql5 5.11.3+dfsg-2
ii  libqt5sql5-sqlite  5.11.3+dfsg-2
ii  libstdc++6 8.2.0-14
ii  lsb-base   10.2018112800
ii  openssl1.1.1a-1
ii  zlib1g 1:1.2.11.dfsg-1

quassel-core recommends no packages.

Versions of packages quassel-core suggests:
pn  libqt5sql5-psql  

-- no debconf information

Bug#919241: RFP: vroom -- Functional testing tool for VIM

[David Mandelberg]

Package: wnpp
Severity: wishlist

"Vroom is for testing vim.

Let's say you're a vimscript author. You want to test your new plugin. 
You could find a nice vimscript test suite, but that only lets you test 
your vimscript functions. What you really want is a way to specify vim 
commands — actual input keys that that the user hits — and then verify 
vim's output."


Homepage: https://github.com/google/vroom
License: Apache 2.0

--
https://david.mandelberg.org/

Bug#918418: django-prometheus FTBFS: test failures

[Martín Ferrari]

Hi,

On 05/01/2019 22:06, Adrian Bunk wrote:
> Source: django-prometheus

> Some recent change in unstable makes django-prometheus FTBFS:

This is due to the changes in the Prometheus Python client library. This
is discussed in https://github.com/korfuri/django-prometheus/issues/83
and there is a PR pending to fix this, but it is not yet complete...

-- 
Martín Ferrari (Tincho)

Bug#910373: gnucash: various UI issues with arrows keys and text selection

[Vincent Lefevre]

Control: found -1 1:3.2-1

This version is now affected too! I don't know why. Perhaps it is
less common or this is due to the upgrade of other parts of the
system. Now, it's time to upgrade to 3.4, for which the bug should
be fixed...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#914755: /etc/default/dnsmasq ENABLED=0 does not work

[Michael Biebl]

On Mon, 26 Nov 2018 17:29:48 -0600 Brent S Elmer  wrote:
> Package: dnsmasq
> Version: 2.79-1
> Severity: normal
> 
> Setting ENABLED=0 in /etc/default/dnsmasq does not prevent dnsmasq from
> starting at boot.  It appears that dnsmasq will start at boot regardless of
> what ENABLED is set to.
> 

Those ENABLED flags are a sysvinit anachronism and its usage is
discouraged (I would go as far and call it an anti-feature).

Simply use "systemctl disable dnsmasq" to prevent it from being started
during boot.



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



signature.asc
Description: OpenPGP digital signature

Bug#919240: reproducible: Add back jtk1b armhf node.

[Vagrant Cascadian]

Package: jenkins.debian.org
Severity: normal

I've gotten jtk1b up and running again, and made a branch to re-add it:

  https://salsa.debian.org/vagrant/jenkins.debian.net/tree/jtk1b-returns


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#919239: ball: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Package: src:ball
Version: 1.5.0+git20180813.37fc53c-2
Severity: serious
Tags: ftbfs

Hello Andreas. Just in case this went unnoticed:

This package fails to build with "dpkg-buildpackage -A". From my build log:


[...]
   create-stamp debian/debhelper-build-stamp
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=cmake --builddirectory=build --with python2
   dh_testroot -i -O--buildsystem=cmake -O--builddirectory=build
   dh_prep -i -O--buildsystem=cmake -O--builddirectory=build
rm -f -- debian/libball1.5-data.substvars 
debian/libball1.5-doc.substvars
rm -fr -- debian/.debhelper/generated/libball1.5-data/ 
debian/libball1.5-data/ debian/tmp/ debian/.debhelper/generated/libball1.5-doc/ 
debian/libball1.5-doc/
   debian/rules override_dh_auto_install-indep
make[1]: Entering directory '/<>/ball-1.5.0+git20180813.37fc53c'
mkdir -p debian/libball1.5-doc/usr/share/doc/libball1.5/html \
debian/libball1.5-data/usr/share/BALL-1.5/doc \
debian/libball1.5-doc/usr/share/doc/libball1.5/html/BALL
cpbuild/usr/share/doc/BALL/TUTORIAL/tutorial.pdf
debian/libball1.5-doc/usr/share/doc/libball1.5/
# we need the BALLView documentation in the data path as well... sorry for that
cp -r build/usr/share/doc/BALL/EXAMPLES/PYTHON/BALLView 
debian/libball1.5-data/usr/share/BALL-1.5/doc
cp -r build/usr/share/doc/BALL/html/*   
debian/libball1.5-doc/usr/share/doc/libball1.5/html/BALL
cp -r build/usr/share/BALL/*debian/libball1.5-data/usr/share/BALL-1.5
make[1]: Leaving directory '/<>/ball-1.5.0+git20180813.37fc53c'
   debian/rules override_dh_install
make[1]: Entering directory '/<>/ball-1.5.0+git20180813.37fc53c'
dh_install
install -d debian/.debhelper/generated/libball1.5-data
install -d debian/.debhelper/generated/libball1.5
install -d debian/.debhelper/generated/libball1.5-dev
install -d debian/.debhelper/generated/libballview1.5
install -d debian/.debhelper/generated/libballview1.5-dev
install -d debian/.debhelper/generated/python-ball
install -d debian/.debhelper/generated/ballview
install -d debian/.debhelper/generated/libball1.5-doc
dh_sip
(grep -a -s -v sip:Depends debian/libball1.5-data.substvars; echo 
sip:Depends=sip-api-12.5) > debian/libball1.5-data.substvars.new
mv debian/libball1.5-data.substvars.new debian/libball1.5-data.substvars
(grep -a -s -v sip:Depends debian/libball1.5-doc.substvars; echo 
sip:Depends=sip-api-12.5) > debian/libball1.5-doc.substvars.new
mv debian/libball1.5-doc.substvars.new debian/libball1.5-doc.substvars
find debian/python-ball/usr/lib/python*/dist-packages/ -name BALLPyMacros.h 
-delete
find: 'debian/python-ball/usr/lib/python*/dist-packages/': No such file or 
directory
make[1]: *** [debian/rules:158: override_dh_install] Error 1
make[1]: Leaving directory '/<>/ball-1.5.0+git20180813.37fc53c'
make: *** [debian/rules:16: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The usual recipe in cases like this is to split override_dh_install
into override_dh_install-arch and override_dh_install-indep.

Thanks.

Bug#919127: RFS: kio-gdrive/1.2.5+fixedtarball-1

[Nicholas D Steeves]

On Sun, Jan 13, 2019 at 12:02:30PM +0200, Adrian Bunk wrote:
> On Sat, Jan 12, 2019 at 03:05:55PM -0700, Nicholas D Steeves wrote:
> >...
> > Changes since the last upload:
> > 
> > kio-gdrive (1.2.5+fixedtarball-1) unstable; urgency=medium
> > 
> >   * Restore missing translations. (Closes: #915496)
> > - Previous release was accidentally built from git tag rather than from
> >   upstream tarball.  This release uses the correct orig tarball.
> >   * Add dversionmangle to watch file.
> >   * Declare Standards-Version: 4.3.0. (No additional changes needed)
> > 
> >  -- Nicholas D Steeves   Sat, 12 Jan 2019 14:15:46 -0700
> 
> Thanks, uploaded.
> 

Thank you Adrian, much appreciated!


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#919238: cloudsql-proxy: Non-working uploader address

[Scott Kitterman]

Package: cloudsql-proxy
Version: 1.13-1
Severity: important

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  sriva...@golden-gryphon.com
retry timeout exceeded

Version: 1.13-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team 

Changed-By: Manoj Srivastava 

Note: If it would have been the maintainer with a failing address, the bug
would be Serious (Policy 3.3).

Scott K

Bug#918901: binfmt-support: using fix-binary with existing magic installs detector

[Colin Watson]

On Thu, Jan 10, 2019 at 01:19:27PM +0100, Stefan Agner wrote:
> Using update-binfmts with the same magic and fix-binary twice, will
> install the detector on the second call. However, this breaks fix-binary
> since the whole point of fixed binary is to allow to use the interpreter
> inside a container/chroot. If a detector is in the play, this detector
> won't be able to load the interpreter from inside the container/chroot.
> 
> I think it would be more sensible for binfmt-support to warn the user on
> the second invocation.

This is a good point, thanks.  I think your patch adds the warning in
slightly the wrong place, though, as it misses the case where a detector
is requested explicitly (e.g. using --detector), which has essentially
the same problem.  We should probably also document the situation.

What do you think of the attached patch against upstream master?

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]
>From f55485ae190049f0cf4922133f3706ebdf4f7c5e Mon Sep 17 00:00:00 2001
From: Colin Watson 
Date: Sun, 13 Jan 2019 23:26:20 +
Subject: [PATCH] Warn about fix-binary/detectors incompatibility

"--fix-binary yes" is incompatible with detectors.  Warn the user if
they try to use both at once.

Thanks to Stefan Agner; fixes Debian bug #918901.

* src/update-binfmts.c (act_enable): Warn and return if a detector is
needed and the fix-binary flag is set.
* man/update-binfmts.man8 (BINARY FORMAT SPECIFICATIONS): Document the
incompatibility.
* NEWS: Document this.
---
 NEWS| 3 +++
 man/update-binfmts.man8 | 8 
 src/update-binfmts.c| 6 ++
 3 files changed, 17 insertions(+)

diff --git a/NEWS b/NEWS
index 9414a7a..c42367e 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,9 @@ Don't enable formats on import or disable them on unimport unless
 /proc/sys/fs/binfmt_misc is already mounted.  This avoids causing cleanup
 problems in chroots.
 
+"--fix-binary yes" is incompatible with detectors.  Warn the user if they
+try to use both at once.  Thanks to Stefan Agner.
+
 binfmt-support 2.1.8 (22 August 2017)
 =
 
diff --git a/man/update-binfmts.man8 b/man/update-binfmts.man8
index b0a11a8..9f5b133 100644
--- a/man/update-binfmts.man8
+++ b/man/update-binfmts.man8
@@ -256,6 +256,8 @@ This may be used when the binary format is more complex than can be handled
 by the kernel's format specifications alone.
 The program should return an exit code of zero if the file is appropriate
 and non-zero otherwise.
+This option cannot be used together with
+.Fl Fl fix\-binary Cm yes .
 .It Fl Fl credentials Cm yes , Fl Fl credentials Cm no
 Whether to keep the credentials of the original binary to run the interpreter;
 this is typically useful to run setuid binaries, but has security implications.
@@ -274,6 +276,12 @@ The default behaviour is
 meaning that the kernel should open the interpreter binary lazily when
 needed.
 This option requires Linux 4.8 or newer.
+It cannot be used together with
+.Fl Fl detector ,
+or with multiple binary formats that share the same magic number, since the
+kernel will only open a single interpreter binary which will then not be
+able to detect and execute the real interpreter from inside a chroot or from
+a different mount namespace.
 .El
 .Ss FORMAT FILES
 A format file is a sequence of options, one per line, corresponding roughly
diff --git a/src/update-binfmts.c b/src/update-binfmts.c
index f0d6526..e562b2a 100644
--- a/src/update-binfmts.c
+++ b/src/update-binfmts.c
@@ -359,6 +359,12 @@ static int act_enable (const char *name)
 	fix_binary =
 		(binfmt->fix_binary && !strcmp (binfmt->fix_binary, "yes"))
 		? "F" : "";
+	if (need_detector && *fix_binary) {
+	warning_err ("unable to enable binary format %s: another format "
+			 "with the same magic already exists and this is a "
+			 "fix-binary format", name);
+	return 0;
+	}
 	regstring = xasprintf (":%s:%c:%s:%s:%s:%s:%s%s%s\n",
 			   name, type, binfmt->offset, binfmt->magic,
 			   binfmt->mask, interpreter,
-- 
2.20.1

Bug#918588: libtool: generated libtool script is broken, affecting build on AIX

[Vincent Lefevre]

Hi,

On 2019-01-12 14:33:06 +, Alastair McKinstry wrote:
> I've disabled patch
> 0010-libtool-mitigate-the-sed_quote_subst-slowdown.patch, which includes the
> 'func_quote' code in the diff, which should revert back to previous working
> behavior, but I've no AIX system to debug or test.
> Can you test with 2.4.6-7 , just uploaded ?

Thanks. This solves the problem.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919197: Acknowledgement (qtwayland-opensource-src: FTBFS on hppa - Segmentation faults in testsuite)

[John David Anglin]

On 2019-01-13 2:52 p.m., John David Anglin wrote:
> Looks to me to be a NULL pointer check issue in mesa:
>
> static inline struct wl_drm_buffer *
> wayland_drm_buffer_get(struct wl_drm *drm, struct wl_resource *resource)
> {
>     if (resource == NULL)
>     return NULL;
>
>     if (wl_resource_instance_of(resource, &wl_buffer_interface,
>     &drm->buffer_interface))
>     return wl_resource_get_user_data(resource);
>     else
>     return NULL;
> }
>
> (gdb) disass $pc-32-16,$pc+16
> Dump of assembler code from 0xec46dd14 to 0xec46dd54:
>    0xec46dd14 : stw rp,-14(sp)
>    0xec46dd18 : ldo 80(sp),sp
>    0xec46dd1c : ldw -b4(sp),ret0
>    0xec46dd20 :    stw r5,-74(sp)
>    0xec46dd24 :    copy r23,r5
>    0xec46dd28 :    stw r4,-70(sp)
>    0xec46dd2c :    stw r3,-6c(sp)
>    0xec46dd30 :    stw r19,-20(sp)
>    0xec46dd34 :    stw ret0,-78(sp)
>    0xec46dd38 :    ldw 58(r25),ret0
>    0xec46dd3c :    ldo c0(ret0),ret0
>    0xec46dd40 :    movb,=
> r24,r3,0xec46dd94 
> => 0xec46dd44 :    ldw 0(ret0),ret0
>    0xec46dd48 :    addil L%800,r19,r1 
>    0xec46dd4c :    copy r19,r4
>    0xec46dd50 :    ldw 200(r1),r25
>
> The NULL pointer check has bee4n optimized away.
Actually, it has only been partially optimized away.  It appears the
check is still there (movb instruction)
but register r3 contains an undefined value (it is not an argument
register).  So, this seems a wrong
code bug.

Why are we building with gcc-7?

-- 
John David Anglin  dave.ang...@bell.net

Bug#918987: transition: ode

[Leopold Palomo-Avellaneda]

El 13/1/19 a les 15:52, Emilio Pozuelo Monfort ha escrit:
> On 11/01/2019 18:09, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 confirmed
>>
>> On 11/01/2019 15:17, Leopold Palomo-Avellaneda wrote:
>>> Subject: transition: ode
>>> Package: release.debian.org
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>> Severity: normal
>>>
>>> Dear release team,
>>>
>>> I would like to ask a transition slot for the ode library. Upstream 
>>> published a
>>> new version with a soname bump. The affected packages can be build without 
>>> any
>>> problem with the new version (I did it in an pbuilder environment).
>>>
>>> Please accept with transition slot. I know that is too close to Buster 
>>> freeze.
>>
>> Go ahead.
> 
> And your package fails (and was already failing) to build on several release
> architectures. You should have fixed that before requesting a transition slot.
> 
> Please look at those failures:
> 
> https://buildd.debian.org/status/package.php?p=ode
> 

First of all I'm so sorry. I didn't check the build of the package
because I thought that it was built. I was more worried about the
dependencies than the package itself. Upstream told me the there was no
important changes. I check specially ABI changes.

In any case, after I notice the problem I worked on. In some archs there
was a problem in autotest, and in others an assert that for an check
from upstream. The problem was in non common archs.

I pushed a new version of the package yesterday night solving the issue
in some archs and this morning I have pushed another version of the
package with the patches sent by upstream. Also, some people in
#debian-mentors helped me in this issue.

Now, it builds in all the archs expect ia64 because some dependencies,
not the package itself.

I can only say this...


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



signature.asc
Description: OpenPGP digital signature

Bug#919187: base-passwd: Reallocate 64044 (grsec-proc)

[Colin Watson]

On Sun, Jan 13, 2019 at 03:31:58PM +0100, Yves-Alexis Perez wrote:
> the range 64040-64044 is assigned to various grsec-related groups. The
> groups are created by the linux-grsec-base package postinst, which was
> used when src:linux-grsec was a thing. Unfortunately, there is no more
> package since grsecurity is now private, so linux-grsec-base doesn't
> really make sense anymore (although it can still be used for grsecurity
> customers).
> 
> The grsec-proc group (64044) can still be used with the hidepid feature
> of mainline Linux kernel, and I'm pondering providing a package doing
> some hardening and maybe creating that group.
> 
> It could also be a different gid, but I guess reusing it doesn't hurt
> that much?

Hmm.  I mean, it's possible that it wouldn't hurt, and I'm not sure
whether I have a strong opinion on it, but for the record could you
explain the positive benefits of reusing it?

Are you considering simply reusing the username and UID but creating it
in another package?

Thanks,

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

Bug#898969: Possible solution released

[Trout, Diane E.]

Hi,

I wasn't able to figure out how to test the trigger solution suggested
by Paul Wise. I did end up taking so long to fix this that OpenSSL
1.1.1 was released, and I tried to set an installation dependency so
the updated version of openssl would be installed first.

It does check to see if the too small keys are installed, deletes them
and then regenerates the keys. (With an autopkgtest)

Diane


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

Bug#919237: node-jsonld: FTBFS in sid (Error: Can't resolve 'rdf-canonize')

[Santiago Vila]

Package: src:node-jsonld
Version: 1.4.0-2
Severity: serious
Tags: ftbfs

Hello Jonas.

I tried to build this package in sid but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
BROWSERSLIST='node 6' babeljs \
--no-babelrc --presets=env \
--out-dir dist/node6/lib \
-- lib
lib/ActiveContextCache.js -> dist/node6/lib/ActiveContextCache.js
lib/DocumentCache.js -> dist/node6/lib/DocumentCache.js
lib/JsonLdError.js -> dist/node6/lib/JsonLdError.js
lib/JsonLdProcessor.js -> dist/node6/lib/JsonLdProcessor.js
lib/NQuads.js -> dist/node6/lib/NQuads.js

[... snipped ...]

 [239] /usr/lib/nodejs/core-js/fn/symbol/index.js 254 bytes {0} [built]
 [247] ./lib/jsonld.js 54.6 kB {0} [built]
 [281] ./lib/flatten.js 1.06 kB {0} [built]
 [282] ./lib/fromRdf.js 17.3 kB {0} [built]
 [283] ./lib/toRdf.js 10.3 kB {0} [built]
+ 277 hidden modules

WARNING in jsonld.min.js from UglifyJs
Side effects in initialization of unused variable _expandIri 
[./lib/jsonld.js:66,13]
Condition always false 
[./usr/lib/nodejs/regenerator-runtime/runtime.js:21,17]
Dropping side-effect-free statement [./lib/frame.js:91,23]
Side effects in initialization of unused variable _ret 
[./lib/frame.js:91,23]
Dropping side-effect-free statement [./lib/compact.js:165,40]
Side effects in initialization of unused variable _ret 
[./lib/compact.js:165,40]

ERROR in ./lib/jsonld.js
Module not found: Error: Can't resolve 'rdf-canonize' in 
'/<>/lib'
 @ ./lib/jsonld.js 60:15-38
 @ multi core-js/fn/array/from core-js/fn/array/includes core-js/fn/map 
core-js/fn/object/assign core-js/fn/promise core-js/fn/set 
core-js/fn/string/starts-with core-js/fn/symbol ./lib/index.js

ERROR in ./lib/NQuads.js
Module not found: Error: Can't resolve 'rdf-canonize' in 
'/<>/lib'
 @ ./lib/NQuads.js 8:17-40
 @ ./lib/jsonld.js
 @ multi core-js/fn/array/from core-js/fn/array/includes core-js/fn/map 
core-js/fn/object/assign core-js/fn/promise core-js/fn/set 
core-js/fn/string/starts-with core-js/fn/symbol ./lib/index.js

ERROR in ./lib/util.js
Module not found: Error: Can't resolve 'rdf-canonize' in 
'/<>/lib'
 @ ./lib/util.js 39:23-46
 @ ./lib/jsonld.js
 @ multi core-js/fn/array/from core-js/fn/array/includes core-js/fn/map 
core-js/fn/object/assign core-js/fn/promise core-js/fn/set 
core-js/fn/string/starts-with core-js/fn/symbol ./lib/index.js
make[1]: *** [debian/rules:8: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


This is just how the build ends in my autobuilder, but it also fails here:

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

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#919236: Inappropriately broad default CA for EAP configuration

[Sam Hartman]

package: freeradius
tags: security
version: 3.0.17+dfsg-1
severity: important
justification: Inappropriately broad default authorization

The debian freeradius package changes the default eap configuration to
use the default list of Debian certification authorities as the default
CAs for verifying client certificates for incoming EAP connections.

The package leaves the following notice in
/etc/freeradius/3.0/mods-available/eap:

#  See also:
#
#  http://www.dslreports.com/forum/remark,9286052~mode=flat
#
#  Note that you should NOT use a globally known CA here!
#  e.g. using a Verisign cert as a "known CA" means that
#  ANYONE who has a certificate signed by them can

And then proceeds to do something even worse: it sets the default CA to
the entire list of Debian trusted CAs.

As discussed by the freeradius docs, you want the default for EAP
certificates to be an organization-specific CA.

--Sam

Bug#919235: abcm2ps: FTBFS because debhelper uses ninja build system instead of autoconf

[Nicolas Boulenguez]

Package: abcm2ps
Version: 8.14.2-0.1
Severity: serious
Tags: patch
Justification: failure to build from scratch

Hello.

My NMU fails to build because debhelper uses ./build.ninja instead of
./configure and ./Makefile.in.  This is quite surprising, and I cannot
reproduce the issue in my chroot.

However, the attached patch selects an explicit build system and most
probably fixes the issue. It upgrades to debhelper 12 as well.

Do you want to upload the fix?
May I prepare another NMU?
Shall I set a shorter delay?
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+abcm2ps (8.14.2-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Debhelper 12.
+  * Fix the build with an explicit debhelper build system.
+
+ -- Nicolas Boulenguez   Sun, 13 Jan 2019 18:10:08 +0100
+
 abcm2ps (8.14.2-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
--- a/debian/compat
+++ /dev/null
@@ -1,1 +0,0 @@
-11
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: text
 Priority: optional
 Maintainer: Anselm Lingnau 
 Build-Depends:
- debhelper (>= 11),
+ debhelper-compat (= 12),
  libfreetype6-dev,
  libpango1.0-dev,
  pkg-config,
--- a/debian/rules
+++ b/debian/rules
@@ -4,4 +4,4 @@ export DEB_BUILD_MAINT_OPTIONS := hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND := -Wl,--as-needed
 
 %:
-	dh $@
+	dh $@ --buildsystem=autoconf

Bug#919234: ttls fails with tls 1.3, enabled by default

[Sam Hartman]

package: freeradius
severity: important
version: 3.0.17+dfsg-1
justification: regression that totally breaks connectivity
tags: upstream


I've cc'd Kurt because he requested openssl 1.3 test results a while
back.

While writing automated tests for moonshot-gss-eap, I discovered that
by default freeradius will not constrain  the version of TLS in use
(probably good), but that its ttls implementation fails with TLS 1.3.
Things work fine if I explicitly set the max TLS version to 1.2.

Based on the errors I suspect that  the issue had to deal with the
handling of the ttls TLS session ticket used by TTLS for fast
reauthentication.
My suspicion (and recollection from the spec) is that ttls knows more
about session internals than it should.

As a quick fix, I think the ttls code should limit the maximum TLS
version to 1.2 until the code can be fixed to work with 1.3.


Please do not limit all freeradius uses of TLS to 1.2: in particular I'd
really like to be able to use tls 1.3 with radsec.
Also, I strongly recommend making this change in code not in config
files.  People tend not to update their configs once they get one
working.

To reproduce, grab the moonshot-gss-eap sources.
Comment out the TLS_MAX_VERSION on line 366 of
debian/tests/freeradius/eap and then rerun autopkgtest on the resulting
source package.

Bug#919233: [installation-guide] document Secure-Boot related bits in the d-i manual

[Holger Wansing]

Package: installation-guide
Severity: wishlist


Steve McIntyre  wrote:
> I've just pushed changes to a few bits of d-i this weekend to make SB
> work for amd64:
> 
>  * build/util/efi-image:
> 
>We can use pre-existing (and already signed) EFI binaries instead
>of building a new monolithic image ourselves (which won't be
>signed). We'll also need to install the shim-signed binary so that
>it will be called first then can chain-load the grub binary.
> 
>Tested and working for boot both via netinst image and network
>boot for amd64 (signed) and i386 (non-signed). The netboot mini.iso
>is also updated and will now work with SB on amd64.
> 
>* This will want documentation updates. Most people won't
>  notice the change, *BUT* people using netboot on amd64 will
>  need to tftp-serve both shim (as bootnetx64.efi) and grub (as
>  grubx64.efi) where previously they just needed grub (as
>  bootnetx64.efi)

As a first step, I'm sending this to a bugreport, to prevent it from getting 
lost in 's holey memory :-)

Thanks for working on this, Steve!



Holger

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

Bug#908796:

[Aryan Duggal]

I can confirm that today's systemd update fixed it
I did apt full-upgrade and update-initramfs -c -k all

Tried a reboot and now it boots fine

Bug#919232: wireguard-dkms: Wireguard dkms module does not buuld against linux kernel 5.0-rc1 commit 7b55851367136b1efd84d98fea81ba57a98304cf

[Aryan Duggal]

I was able to solve the problem by temporarily compiling it from
https://git.zx2c4.com/WireGuard and installing it

On Mon, 14 Jan 2019, 03:37 Aryan Duggal  DKMS make.log for wireguard-0.0.20181218 for kernel 5.0.0-rc1+ (x86_64)
> Sun Jan 13 21:52:56 GMT 2019
> make: Entering directory '/usr/src/linux-headers-5.0.0-rc1+'
>   CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/main.o
>   CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/noise.o
>   CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/device.o
>   CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/peer.o
> /var/lib/dkms/wireguard/0.0.20181218/build/noise.c: In function
> ‘tai64n_now’:
> /var/lib/dkms/wireguard/0.0.20181218/build/noise.c:453:2: error: implicit
> declaration of function ‘getnstimeofday64’; did you mean ‘getnstimeofday’?
> [-Werror=implicit-function-declaration]
>   getnstimeofday64(&now);
>   ^~~~
>   getnstimeofday
>   CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/timers.o
>   CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/queueing.o
>   CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/send.o
> cc1: some warnings being treated as errors
> make[1]: *** [scripts/Makefile.build:277:
> /var/lib/dkms/wireguard/0.0.20181218/build/noise.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make: *** [Makefile:1554:
> _module_/var/lib/dkms/wireguard/0.0.20181218/build] Error 2
> make: Leaving directory '/usr/src/linux-headers-5.0.0-rc1+'
>
> On Mon, 14 Jan 2019, 03:36 anupritaisno1 
>> Package: wireguard-dkms
>> Version: 0.0.20181218-1
>> Severity: grave
>> Justification: renders package unusable
>>
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386, i686
>>
>> Kernel: Linux 5.0.0-rc1+ (SMP w/4 CPU cores)
>> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
>> (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages wireguard-dkms depends on:
>> ii  dkms  2.6.1-3
>>
>> Versions of packages wireguard-dkms recommends:
>> ii  wireguard-tools  0.0.20181218-1
>>
>> wireguard-dkms suggests no packages.
>>
>> -- no debconf information
>>
>

Bug#919232: wireguard-dkms: Wireguard dkms module does not buuld against linux kernel 5.0-rc1 commit 7b55851367136b1efd84d98fea81ba57a98304cf

[Aryan Duggal]

DKMS make.log for wireguard-0.0.20181218 for kernel 5.0.0-rc1+ (x86_64)
Sun Jan 13 21:52:56 GMT 2019
make: Entering directory '/usr/src/linux-headers-5.0.0-rc1+'
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/main.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/device.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/peer.o
/var/lib/dkms/wireguard/0.0.20181218/build/noise.c: In function
‘tai64n_now’:
/var/lib/dkms/wireguard/0.0.20181218/build/noise.c:453:2: error: implicit
declaration of function ‘getnstimeofday64’; did you mean ‘getnstimeofday’?
[-Werror=implicit-function-declaration]
  getnstimeofday64(&now);
  ^~~~
  getnstimeofday
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/timers.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/queueing.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/send.o
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:277:
/var/lib/dkms/wireguard/0.0.20181218/build/noise.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1554:
_module_/var/lib/dkms/wireguard/0.0.20181218/build] Error 2
make: Leaving directory '/usr/src/linux-headers-5.0.0-rc1+'

On Mon, 14 Jan 2019, 03:36 anupritaisno1  Package: wireguard-dkms
> Version: 0.0.20181218-1
> Severity: grave
> Justification: renders package unusable
>
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, i686
>
> Kernel: Linux 5.0.0-rc1+ (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages wireguard-dkms depends on:
> ii  dkms  2.6.1-3
>
> Versions of packages wireguard-dkms recommends:
> ii  wireguard-tools  0.0.20181218-1
>
> wireguard-dkms suggests no packages.
>
> -- no debconf information
>

Bug#919232: wireguard-dkms: Wireguard dkms module does not buuld against linux kernel 5.0-rc1 commit 7b55851367136b1efd84d98fea81ba57a98304cf

[anupritaisno1]

Package: wireguard-dkms
Version: 0.0.20181218-1
Severity: grave
Justification: renders package unusable



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

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

Versions of packages wireguard-dkms depends on:
ii  dkms  2.6.1-3

Versions of packages wireguard-dkms recommends:
ii  wireguard-tools  0.0.20181218-1

wireguard-dkms suggests no packages.

-- no debconf information

Bug#919213: irqbalance: endless loop during configure, system reaches maximum of open files

[Ben Caradoc-Davies]

Not seen when upgrading irqbalance (1.5.0-0.1 => 1.5.0-2) on sid amd64:

# apt-get dist-upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
   irqbalance (1.5.0-0.1 => 1.5.0-2)
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/52.6 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
serious bugs of irqbalance (1.5.0-0.1 -> 1.5.0-2) 
 b1 - #919213 - irqbalance: endless loop during configure, system 
reaches maximum of open files

Summary:
 irqbalance(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...]
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 243868 files and directories currently installed.)
Preparing to unpack .../irqbalance_1.5.0-2_amd64.deb ...
Unpacking irqbalance (1.5.0-2) over (1.5.0-0.1) ...
Processing triggers for systemd (240-4) ...
Processing triggers for man-db (2.8.5-1) ...
Setting up irqbalance (1.5.0-2) ...
[completes normally]

Kind regards,

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

Bug#919231: salt-master: Upgrade Stretch -> Buster: permission denied on certain files/directories

[Stijn Segers]

Package: salt-master
Version: 2018.3.3+dfsg1-2
Severity: important

Dear Maintainer,

Upgrading salt-master from its Stretch version to Buster (whole system was
upgraded) breaks the Salt master.

Symptoms:

E: Sub-process /usr/bin/dpkg returned an error code (1)

[...]

Job for salt-master.service failed because the control process exited with
error code.
See "systemctl status salt-master.service" and "journalctl -xe" for details.
invoke-rc.d: initscript salt-master, action "restart" failed.
● salt-master.service - The Salt Master Server
   Loaded: loaded (/lib/systemd/system/salt-master.service; enabled; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-01-13 22:43:04 CET; 6ms
ago
 Docs: man:salt-master(1)
   file:///usr/share/doc/salt/html/contents.html
   https://docs.saltstack.com/en/latest/contents.html
  Process: 14194 ExecStart=/usr/bin/salt-master (code=exited, status=1/FAILURE)
 Main PID: 14194 (code=exited, status=1/FAILURE)

jan 13 22:43:04 icarus salt-master[14194]:   File "/usr/lib/python3/dist-
packages/salt/daemons/masterapi.py", line 237, in access_keys
jan 13 22:43:04 icarus salt-master[14194]: key = mk_key(opts, user)
jan 13 22:43:04 icarus salt-master[14194]:   File "/usr/lib/python3/dist-
packages/salt/daemons/masterapi.py", line 206, in mk_key
jan 13 22:43:04 icarus salt-master[14194]: with
salt.utils.files.fopen(keyfile, 'w+') as fp_:
jan 13 22:43:04 icarus salt-master[14194]:   File "/usr/lib/python3/dist-
packages/salt/utils/files.py", line 387, in fopen
jan 13 22:43:04 icarus salt-master[14194]: f_handle = open(*args, **kwargs)
# pylint: disable=resource-leakage
jan 13 22:43:04 icarus salt-master[14194]: PermissionError: [Errno 13]
Permission denied: '/var/cache/salt/master/.salt_key'
jan 13 22:43:04 icarus systemd[1]: salt-master.service: Main process exited,
code=exited, status=1/FAILURE
jan 13 22:43:04 icarus systemd[1]: salt-master.service: Failed with result
'exit-code'.
jan 13 22:43:04 icarus systemd[1]: Failed to start The Salt Master Server.


It turns out renaming /var/cache/salt works around this - a new /var/cache/salt
directory gets created and the .salt_key gets generated (does not exist on a
Stretch installation). There is a .root_key though.

After overwriting the contents of the new /var/cache/salt/ directory with what
was in the old one (and keeping the .salt_key), the Salt service starts, but
still seems unable to access (existing) directories:

jan 13 22:48:37 icarus salt-master[16017]: Traceback (most recent call last):
jan 13 22:48:37 icarus salt-master[16017]:   File
"/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
jan 13 22:48:37 icarus salt-master[16017]: self.run()
jan 13 22:48:37 icarus salt-master[16017]:   File "/usr/lib/python3/dist-
packages/salt/utils/process.py", line 750, in _run
jan 13 22:48:37 icarus salt-master[16017]: return self._original_run()
jan 13 22:48:37 icarus salt-master[16017]:   File "/usr/lib/python3/dist-
packages/salt/master.py", line 234, in run
jan 13 22:48:37 icarus salt-master[16017]:
salt.utils.verify.check_max_open_files(self.opts)
jan 13 22:48:37 icarus salt-master[16017]:   File "/usr/lib/python3/dist-
packages/salt/utils/verify.py", line 429, in check_max_open_files
jan 13 22:48:37 icarus salt-master[16017]: accepted_count =
len(os.listdir(accepted_keys_dir))
jan 13 22:48:37 icarus salt-master[16017]: PermissionError: [Errno 13]
Permission denied: '/var/lib/salt/pki/master/minions'


This directory is 700, but when I chmod it to 755 (which I suppose is bad
practice, I presume it's 700 for a valid reason), restart
the Salt service, the permissions are reset to 700:

$ ls -lh /var/lib/salt/pki/master/|grep minions
drwx-- 2  755 root 4,0K dec 29 16:21 minions

Let me know if you need more information. This was a clean upgrade from Stretch
(no bits and pieces).

Thank you

Stijn Segers



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

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

Versions of packages salt-master depends on:
ii  adduser  3.118
ii  lsb-base 10.2018112800
ii  python3  3.7.1-3
ii  python3-crypto   2.6.1-9+b1
ii  python3-systemd  234-2+b1
ii  python3-zmq  17.1.2-1
ii  salt-common  2018.3.3+dfsg1-2

Versions of packages salt-master recommends:
ii  python3-pygit2  0.27.3-1

salt-master suggests no packages.

-- Configuration Files:
/etc/salt/master changed [not included]

-- no debconf information

Bug#636317: libagar (ITP) libtool troubles

[Tormod Volden]

On Sun, Jan 13, 2019 at 5:57 PM Tormod Volden wrote:
> Unfortunately, it doesn't build in the PPA yet, because of a libtool
> issue. If anyone can take a look at the failed build log and give me a

I believe I have fixed this issue (bug in BSDBuild makefile), and the
new package is at:
https://launchpad.net/~tormodvolden/+archive/ubuntu/m6809/+sourcefiles/agar/1.5.0-0~z~bionic4/agar_1.5.0-0~z~bionic4.dsc

Tormod

Bug#919001: emacs-gtk: fails to upgrade to 1.26.1+1-3

[Pavel Kreuzt]

It's emacspeak-47.0+dfsg-6

On Sun, Jan 13, 2019 at 8:10 PM Paul Gevers  wrote:

> On Sun, 13 Jan 2019 13:25:24 -0600 Rob Browning 
> wrote:
> > > Tried to uninstall emacspeak package only and the problems appears
> again,
> > > so you're right. I'm not able to uninstall it anyway. Should I report
> the
> > > bug to them?
> >
> > Hmm, suppose it may make sense to reassign this bug there for now, so
> > I've done that (above).  We can always reassign it to emacs if that
> > turns out to to be appropriate.
>
> Indeed.
>
> Which version of emacspeak are we talking about here?
>
> Paul
>
>

Bug#919229: RM: karma-tools libkarma-cil libkarma-cil-dev libkarma-dev libkarma0 [mips mips64el alpha hppa ia64 m68k powerpcspe riscv64 sh4 sparc64 x32] -- RoQA; ANAIS

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
Control: affects -1 src:libkarma

According to https://buildd.debian.org/status/package.php?p=mono&suite=sid ,
libkarma's build dependency, mono, is no longer being built on several
architectures (especially mips and mips64el). This left cruft of libkarma in
the archive and prevents the newer upload from migrating into testing. Please
remove those old binary packages. Thanks!

--
Regards,
Boyuan Yang


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

Bug#636317: libagar (ITP) libtool troubles

[Tormod Volden]

While looking for a Debian package of agar, I found Stephen's work
here: 
https://launchpad.net/~bregma/+archive/ubuntu/debian/+sourcefiles/agar/1.4.1-1/agar_1.4.1-1.dsc

I updated it for upstream 1.5.0 and a few other fixes here:
https://launchpad.net/~tormodvolden/+archive/ubuntu/m6809/+sourcefiles/agar/1.5.0-0~z~bionic2/agar_1.5.0-0~z~bionic2.dsc

I hope that it can be of help for anyone that would continue the ITP.

Unfortunately, it doesn't build in the PPA yet, because of a libtool
issue. If anyone can take a look at the failed build log and give me a
hint on how to go forward I would appreciate it. Search the log for
libag_core and libag_gui to find examples of the issue:

https://launchpadlibrarian.net/405443473/buildlog_ubuntu-bionic-amd64.agar_1.5.0-0~z~bionic2_BUILDING.txt.gz

Best regards,
Tormod

Bug#919206: udevadm segfaults when using --subsystem-match containing '/'

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/11416

Thanks,
forwarded this issue upstream.
I replaced the backtrace with one where libudev1-dbgsym and udev1-dbgsym
is installed [1]

Regards,
Michael

[1] https://wiki.debian.org/HowToGetABacktrace
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#918450: RFS: elpy/1.28.0-1

[Nicholas D Steeves]

Hi Chris,

On Sun, Jan 13, 2019 at 06:26:31PM +, Chris Lamb wrote:
> Nicholas D Steeves wrote:
> 
> > elpy (1.28.0-1) unstable; urgency=medium
> 
> … uploaded.

Thank you :-)

> Regarding:
> 
> ifneq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
>   echo -e "\nnodoc profile enabled, building without sphinxdoc..\n"
>   dh $@ --with elpa,python3 --buildsystem=pybuild
> else
>   dh $@ --with elpa,python3,sphinxdoc --buildsystem=pybuild
> endif
> 
> ... is there a bug report (or similar?) against sphinxdoc that will
> do the right thing by default? Very ugly IMHO to do this in debian/
> rules and, of course, this essentially has to be copy-pasted into
> every package that uses sphinxdoc...

I agree and filed #908078 "sphinx-common: should detect when 'nodoc'
is active, then --with sphinxdoc should do nil" back in September.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#919227: more acpi info

[Andrea Borgia]

It seems to be the case that the lid is the most visible breakage but 
not the only one: when charging, the battery information is not updated.


Attaching the output of "acpi -V" with the kernel from stable and the 
current one in unstable.
Battery 0: Charging, 86%, 00:21:57 until charged
Battery 0: design capacity 5200 mAh, last full capacity 5145 mAh = 98%
Adapter 0: on-line
Thermal 0: ok, 61.0 degrees C
Thermal 0: trip point 0 switches to mode critical at temperature 95.0 degrees C
Thermal 0: trip point 1 switches to mode passive at temperature 92.0 degrees C
Cooling 0: Processor 0 of 10
Cooling 1: Processor 0 of 10
Cooling 2: LCD 7 of 10
Cooling 3: Processor 0 of 10
Cooling 4: Processor 0 of 10
Battery 0: Charging, 100%,  until charged
Battery 0: design capacity 4300 mAh, last full capacity 4200 mAh = 97%
Adapter 0: on-line
Thermal 0: ok, 60.0 degrees C
Thermal 0: trip point 0 switches to mode critical at temperature 95.0 degrees C
Thermal 0: trip point 1 switches to mode passive at temperature 92.0 degrees C
Cooling 0: Processor 0 of 10
Cooling 1: Processor 0 of 10
Cooling 2: Processor 0 of 10
Cooling 3: LCD 7 of 10
Cooling 4: Processor 0 of 10

Bug#917607: marked as done (udev 240 Makes System Unbootable; rootfs Not Found)

[gregor herrmann]

On Sat, 12 Jan 2019 23:18:05 +, Debian Bug Tracking System wrote:

>* sd-device-monitor: Fix ordering of setting buffer size.
>  Fixes an issue with uevents not being processed properly during coldplug
>  stage and some kernel modules not being loaded via "udevadm trigger".
>  (Closes: #917607)

Hi Michael,

thanks alot for the immense amount of effort you've put into fixing
this bug over the last weeks, much appreciated!


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#919228: wrong Recommends:

[Thorsten Alteholz]

Package: toil
Version: 3.18.0-1
Severity: serious
thanks

Package toil Recommends: python3-futures which is not available. So this 
package might not be installable on some systems.

Did you mean python3-future?

  Thorsten

Bug#919227: linux-image-4.19.0-1-amd64: acpi lid regression from stable to testing

[Andrea Borgia]

Package: src:linux
Version: 4.19.13-1
Severity: normal

Dear Maintainer,

after the upgrade to Testing, the system is no longer able to detect a closed 
lid to initiate suspend-to-ram; reinstalling the kernel from Stable (4.9.0-7), 
while keeping the rest of the
system as is, brings the functionality back.

Using the archived images on snapshot.debian.org:
4.9.0-7: OK 
4.10.0-trunk: fails
4.11.0-2: fails
4.14.0-1: fails
4.19.0-1: fails (first failure detected on this version)
(those versions which are failing all have the "SW_LID" warning in dmesg, see 
below) 

Other observations:
* the sleep keycombo Fn+F1 works
* pm-suspend works
* pm-hibernate works

If I watch the state of /proc/acpi/button/lid/LID/state from a remote shell and 
close the lid, it shows "open".
/etc/default/acpi-support is fine: LID_SLEEP=true is active, both acpid and the 
system itself were restarted multiple times.

I have tried the button.lid_init_state option (see 
Documentation/acpi/acpi-lid.txt) but none of the values
work (method / open / ignore).

This upstream report looks relevant: 
https://bugzilla.kernel.org/show_bug.cgi?id=192231

I'm in the process of rebuilding the kernel with the suggested debug patch
and I'll follow up with the results.

-- Package-specific info:
** Version:
Linux version 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.13-1 (2018-12-30)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 
root=UUID=e19e81ac-9618-4735-8a7c-bff7f48b50cb ro 
resume=UUID=3464e393-b3d3-49c3-a1e0-858d6123f7c3 button.lid_init_state=open 
quiet

** Not tainted

** Kernel log:
[5.990210] input: Lid Switch as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input4
[5.990261] ACPI: Lid Switch [LID]
[5.993277] battery: ACPI: Battery Slot [BAT0] (battery present)
[5.993798] input: Sleep Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input5
[5.993850] ACPI: Sleep Button [SLPB]
[5.994349] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input6
[5.994410] ACPI: Power Button [PWRB]
[5.994914] ACPI: AC Adapter [AC0] (on-line)
[5.999389] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input7
[5.03] ACPI: Power Button [PWRF]
[6.092418] systemd-journald[201]: Received request to flush runtime journal 
from PID 1
[6.144603] audit: type=1400 audit(1547392874.667:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/haveged" pid=265 
comm="apparmor_parser"
[6.149025] audit: type=1400 audit(1547392874.671:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=267 comm="apparmor_parser"
[6.181730] audit: type=1400 audit(1547392874.703:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=266 
comm="apparmor_parser"
[6.181752] audit: type=1400 audit(1547392874.703:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium" 
pid=266 comm="apparmor_parser"
[6.184900] audit: type=1400 audit(1547392874.707:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=269 
comm="apparmor_parser"
[6.184916] audit: type=1400 audit(1547392874.707:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=269 
comm="apparmor_parser"
[6.184929] audit: type=1400 audit(1547392874.707:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=269 
comm="apparmor_parser"
[6.192163] audit: type=1400 audit(1547392874.711:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/mysqld-akonadi" 
pid=268 comm="apparmor_parser"
[6.192187] audit: type=1400 audit(1547392874.711:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/sbin/mysqld-akonadi///usr/sbin/mysqld" pid=268 comm="apparmor_parser"
[6.235938] audit: type=1400 audit(1547392874.755:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=270 comm="apparmor_parser"
[6.307677] iTCO_vendor_support: vendor-support=0
[6.346358] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[6.346500] iTCO_wdt: Found a NM10 TCO device (Version=2, TCOBASE=0x0860)
[6.348785] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[6.446257] input: PC Speaker as /devices/platform/pcspkr/input/input8
[6.497967] sd 0:0:0:0: Attached scsi generic sg0 type 0
[6.498169] sd 4:0:0:0: Attached scsi generic sg1 type 0
[6.731722] pci :00:00.0: Intel GMA3150 Chipset
[6.731775] pci :00:00.0: detected gtt size: 524288K total, 262144K 
mappable
[6.731884] pci :00:00.0: detected 8192K stolen memory
[6.731952] [drm] Replacing VGA console driver
[6

Bug#916075: policykit-1: Regression from CVE-2018-19788 fix

[Salvatore Bonaccorso]

Control: retitle -1 policykit-1: Regression from CVE-2018-19788 fix
Control: forwarded -1 https://gitlab.freedesktop.org/polkit/polkit/issues/77
Control: found -1 0.105-18+deb9u1
Control: affects -1 security.debian.org,release.debian.org

On Sun, Dec 09, 2018 at 09:00:59PM +0100, Paul Gevers wrote:
> Source: policykit-1
> Version: 0.105-23
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainers,
> 
> With a recent upload of policykit-1 the autopkgtest of policykit-1 fails
> in testing when that autopkgtest is run with the binary packages of
> policykit-1 from unstable. It passes when run with only packages from
> testing. In tabular form:
>passfail
> policykit-1from testing0.105-23
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. It seems the
> same error can be found in the python-dbusmock regression due to this
> update.
> 
> Currently this regression is NOT contributing to the delay of the
> migration to testing [1] because of the urgency. Can you please
> investigate the situation and fix it? If needed, please change the bug's
> severity.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=policykit-1
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/policykit-1/1474415/log.gz
> 
> autopkgtest [04:38:19]: test cli-root: [---
> TEST: pkaction
> No action with action id unknown.action
> TEST: pkcheck
> 
> ** (process:1436): CRITICAL **: 04:38:19.446:
> polkit_unix_process_set_property: assertion 'val != -1' failed
> 
> ** (process:1439): CRITICAL **: 04:38:19.453:
> polkit_unix_process_set_property: assertion 'val != -1' failed
> autopkgtest [04:38:19]: test cli-root: ---]
> autopkgtest [04:38:19]: test cli-root:  - - - - - - - - - - results - -
> - - - - - - - -
> cli-root FAIL stderr:

This is a regression from the fix for CVE-2018-19788 and it was
reported upstream by Martin Pitt in
https://gitlab.freedesktop.org/polkit/polkit/issues/77 .

Regards,
Salvatore

Bug#919226: ITP: hardening-runtime -- Runtime hardening configuration files

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Yves-Alexis Perez 

* Package name: hardening-runtime
  Version : 1
  Upstream Author : Yves-Alexis Perez https://salsa.debian.org/corsac/hardening-runtime
* License : GPL-2+
  Programming Lang: configuration file
  Description : Runtime hardening configuration files

The package contains configuration files (Linux command line and sysctl
for now) with settings recommended by the Linux Kernel Self-Protection
project
(https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings)

The package can be used to quickly harden a default Debian installation.

Bug#918308: transition: botan

[GCS]

Hi Emilio,

On Mon, Jan 7, 2019 at 6:08 PM Emilio Pozuelo Monfort  wrote:
> On 04/01/2019 23:08, Laszlo Boszormenyi (GCS) wrote:
> > It's a small transition with only three packages: biboumi,
> > libqtshadowsocks and qtcreator. All three build fine with
> > this botan release as well.
>
> Go ahead.
 Uploaded and even migrated to Buster, but just realized that I don't
see the binNMUs.
Meanwhile botan 2.9.0 was released[1], packaged and uploaded to
experimental as it contains a soname change again and fixes a security
issue. Also contain many other fixes to prevent side channel attacks.
Of course, the dependencies still build fine with this release as
well.
Is it allowed to further update an ongoing transition?

Regards,
Laszlo/GCS
[1] https://botan.randombit.net/news.html#version-2-9-0-2019-01-04

Bug#704180: Use p11-kit to replace nssckbi

[Laurent Bigonville]

Le 11/01/19 à 18:28, Daniel Kahn Gillmor a écrit :

On Fri 2019-01-11 18:17:26 +0100, Laurent Bigonville wrote:

The problem is what/who will decide if this package is installed? If
that package is being pulled by on other package for some reason, that
means that the local administrator will not be able to revert the
decision of the package maintainer who has added this dependency

agreed, a runtime dependency on that for anything but a "preferred
system configuration"-style metapackage would be a bad thing.  but it'd
also be a very visible thing.

Hopefully if that happend, the affected user could report a bug on that
dependency, and in the meantime work around it with something like
equivs.


The problem is that if nothing is pulling the new package in the default 
installation, nobody will ever use it. And we will create a new 
difference between debian and the other distributions.

Bug#919225: libballview1.5-dev: missing Breaks+Replaces: libballview1.4-dev

[Andreas Beckmann]

Package: libballview1.5-dev
Version: 1.5.0+git20180813.37fc53c-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack 
.../libballview1.5-dev_1.5.0+git20180813.37fc53c-1_amd64.deb ...
  Unpacking libballview1.5-dev (1.5.0+git20180813.37fc53c-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libballview1.5-dev_1.5.0+git20180813.37fc53c-1_amd64.deb
 (--unpack):
   trying to overwrite '/usr/include/BALL/VIEW/DATATYPE/colorExtensions.h', 
which is also in package libballview1.4-dev 1.4.3~beta1-3
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   
/var/cache/apt/archives/libballview1.5-dev_1.5.0+git20180813.37fc53c-1_amd64.deb


cheers,

Andreas


libballview1.4-dev=1.4.3~beta1-3_libballview1.5-dev=1.5.0+git20180813.37fc53c-1.log.gz
Description: application/gzip

Bug#915667: Reopen Bug 915667

[Boyuan Yang]

Control: reopen -1

Sorry for closing this bug by mistake. Reopening it now.

--
Regards,
Boyuan Yang

Bug#919108: wbar: segfaults sometimes, undetermined conditions

[Pavel Kreuzt]

It seems to happen when opening or closing windows. I have taskbar
activated (this could be relevant) so the number of icons changes along
running programs, base icons are 9. It was running happily with compton
until last libgdk (I think) upgrade. With default config it doesn't
trigger, so it definittely seems related to taskbar option. As soon as it
gets activated, the segfault triggers again on the next window close.

On Sun, Jan 13, 2019 at 4:10 PM Markus Koschany  wrote:

>
>
> Am 12.01.19 um 23:15 schrieb Pavel Kreuzt:
> > Here is the result of the BT:
> >
> > (gdb) bt
> > #0  0xda15 in std::_List_iterator::operator--
> > (this=0x55568500 ) at /usr/include/c++/8/bits/stl_list.h:239
> > #1  mapIcons () at ../src/core/Main.cc:443
> > #2  0xaaad in main (argc=,
> > argv=0x555a2630) at ../src/core/Main.cc:393
>
> I am afraid this is too little information, at least for me. In
> Main.cc:443 there is an iterator and the function is about removing
> icons from wbar. What are you doing when this error occurs? Is this
> reproducible with the default configuration? How many icons are on wbar?
> Also a few lines later in Main.cc the author of wbar works around "bad"
> window managers by ignoring errors. It could be that compton and wbar
> just don't play along together but I don't know how to make them
> compatible.
>
>

Bug#919027: wireshark: missing executables

[Balint Reczey]

Control: tags -1 confirmed

Hi Stefan,

On Sat, Jan 12, 2019 at 6:33 AM Stefan Pietsch  wrote:
>
> Package: wireshark-common
> Version: 2.6.6-1
> Severity: normal
>
> The wireshark-common package is missing these executable files:
>
> - captype

Adding it.

> - idl2wrs

This is already present in wireshark-dev.

> - randpkt

Adding it.

Thanks for the bug report!

Cheers,
Balint


--
Balint Reczey
Ubuntu & Debian Developer

Bug#901461: ITP: mu -- simple editor for beginner Python programmers

[Nick Morrott]

A quick update to let everyone know that mu-editor is in the NEW queue.

This "small packaging project" has resulted in 14 new Debian source
packages, of which 11 have already been accepted into unstable.

The last piece of the puzzle, the firmware-microbit-micropython [1]
source package is currently awaiting review by the Debian Python team
before being uploaded to the NEW queue. Its build tool - yotta - is
sitting in NEW along with mu-editor as I write this.

  [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908783

Thanks to the work of Peter Green, pigpio is also now in the NEW
queue. python-gpiozero is still arm-arch-only despite the request to
make it available on more architectures [2]:

  [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856413

Thanks,
Nick

Bug#919067: Please add a Recommends: on shim-signed

[Steve McIntyre]

So, looking through this diff: (holy crap, the grub-installer script
is getting big! :-()

On that front, I'm *tempted* to say it's time to stop caring about and
supporting grub-legacy here, maybe?

On Sat, Jan 12, 2019 at 01:51:41PM +, Colin Watson wrote:

>diff --git a/grub-installer b/grub-installer
>index 04016fb7..7fbcf7ee 100755
>--- a/grub-installer
>+++ b/grub-installer
>@@ -346,7 +346,7 @@ case $ARCH in
>   if [ -f /sys/firmware/efi/fw_platform_size ] ; then
>   SIZE=$(cat /sys/firmware/efi/fw_platform_size)
>   if [ $SIZE -eq 64 ] ; then
>-  grub_package="grub-efi-amd64"
>+  grub_package="grub-efi-amd64-signed"
>   elif [ $SIZE -eq 32 ] ; then
>   grub_package="grub-efi-ia32"
>   fi

I'm minded to not take this - I feel that grub-efi-amd64-signed is
more of an equivalent to grub-efi-amd64-bin, just containing the
actual grub binaries for the other packages to use. The metapackage
grub-efi-amd64 is still the correct thing to be installing here.

>@@ -484,14 +484,17 @@ db_progress INFO grub-installer/progress/step_install
> # to grub legacy, or vice-versa
> case "$grub_package" in
> grub)
>-  log-output -t grub-installer $chroot $ROOT dpkg -P grub-pc-bin grub-pc 
>grub-efi grub-efi-amd64-bin grub-efi-amd64 grub-efi-ia32-bin grub-efi-ia32
>+  log-output -t grub-installer $chroot $ROOT dpkg -P grub-pc-bin grub-pc 
>grub-efi grub-efi-amd64-bin grub-efi-amd64 grub-efi-amd64-signed 
>grub-efi-ia32-bin grub-efi-ia32
>   ;;
> grub-pc)
>-  log-output -t grub-installer $chroot $ROOT dpkg -P grub grub-legacy 
>grub-efi grub-efi-amd64-bin grub-efi-amd64 grub-efi-ia32-bin grub-efi-ia32
>-;;
>-grub-efi*)
>+  log-output -t grub-installer $chroot $ROOT dpkg -P grub grub-legacy 
>grub-efi grub-efi-amd64-bin grub-efi-amd64 grub-efi-amd64-signed 
>grub-efi-ia32-bin grub-efi-ia32
>+  ;;
>+grub-efi-amd64-signed)
>   log-output -t grub-installer $chroot $ROOT dpkg -P grub grub-legacy 
> grub-pc-bin grub-pc
>-;;
>+  ;;
>+grub-efi*)
>+  log-output -t grub-installer $chroot $ROOT dpkg -P grub grub-legacy 
>grub-pc-bin grub-pc grub-efi-amd64-signed
>+  ;;
> esac
> 
> exit_code=0

all obviously the right thing. I'm thinking it's time to wrap and
reformat those long command lines, though!

>@@ -507,6 +510,11 @@ case "$grub_package" in
>*)
>   # Will pull in os-prober based on global setting for Recommends
>   apt-install $grub_package || exit_code=$? 
>+  case $grub_package in
>+  *-signed)
>+  apt-install shim-signed || true
>+  ;;
>+  esac
>   ;;
> esac

This would clearly be the right thing to do too if we changed the
grub_package setting at the top. Maybe if we just change that to match
grub-efi-amd64 for now?

I'm about to test this lot locally and double-check it DTRT for both
amd64/efi with -signed and i386/efi (without), anyway.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Bug#919001: emacs-gtk: fails to upgrade to 1.26.1+1-3

[Pavel Kreuzt]

Tried to uninstall emacspeak package only and the problems appears again,
so you're right. I'm not able to uninstall it anyway. Should I report the
bug to them?

On Sat, Jan 12, 2019 at 6:43 PM Rob Browning  wrote:

> Pavel Kreuzt  writes:
>
> > Package: emacs-gtk
> > Version: 1:25.2+1-11
> > Severity: important
> >
> > Dear Maintainer,
> >
> > when trying to upgrade emacs to 1.26.1+1-3, some installation script
> fails with following error:
>
> I think it's very likely that this isn't a bug in emacs, but rather one
> of the add-on packages, perhaps emacspeak, judging from the placement.
>
> > Remove emacspeak for emacs
> > remove/emacspeak: purging byte-compiled files for emacs
> > rm: missing operand
> > Try 'rm --help' for more information.
> > ERROR: remove script from emacspeak package failed
> > dpkg: warning: old emacs-gtk package pre-removal script subprocess
> returned error exit status 1
> > dpkg: trying script from the new package instead ...
>
> --
> Rob Browning
> rlb @defaultvalue.org and @debian.org
> GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
> GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
>

Bug#907997: emacs-lucid: trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in package emacs25 25.2+1-6+b2

[Rob Browning]

Control: fixed -1 emacs/1:26.1+1-1

I think this bug may now be "fixed" by the switch of the emacs package
to upstream 26.1, which should avoid including any of the conflicting
paths.

While we may also consider simplifying the control dependencies now, I
think this problem is likely resolved.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#919067: Please add a Recommends: on shim-signed

[Steve McIntyre]

On Sun, Jan 13, 2019 at 05:34:41PM +, Steve McIntyre wrote:
>
>I'm about to test this lot locally and double-check it DTRT for both
>amd64/efi with -signed and i386/efi (without), anyway.

And all looks good in both cases. Committing now.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Bug#918979: Emacs now just shows dark red dots for images

[Rob Browning]

Sven Joachim  writes:

> Unfortunately, the binNMUs failed because of #918646. :-/

I should be uploading a -4 in the next day or so with the fix for that.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#902888: [lcl-utils-1.8] lazbuild crash when lazarus-src is not installed

[Abou Al Montacir]

On Sun, 2019-01-13 at 12:31 +0100, Abou Al Montacir wrote:...
> The error messages current location is decided by FPC make file and not by our
> scripts. And even it we are going to overwrite this we may want to move the
> error files to either/usr/share/fpc/3.0.4/compiler/msg/errore.msgor
> to/usr/share/fp-compiler-3.0.4/msg/errore.msgbut not
> to/usr/share/fpcsrc/3..4/compiler/msg/errore.msg
> For now I'll probably try to change Lazarus default search path.
I've tried several attempts to fix that but failed to find a way to get "gnu" in
"$(TargetCPU)-$(TargetOS)-gnu" in the attached patch.
I now consider again using the upstream path:
> /usr/share/fpcsrc/3..4/compiler/msg/errore.msg
using either a move command in rules file or a symbolic link entry in the .link
file.
Can anyone advise what is better? 
-- 
Cheers,
Abou Al Montacirdiff --git a/ide/etfpcmsgparser.pas b/ide/etfpcmsgparser.pas
index 38da4adb..4d423b44 100644
--- a/ide/etfpcmsgparser.pas
+++ b/ide/etfpcmsgparser.pas
@@ -1013,6 +1013,13 @@ begin
   FPCVer:=CodeToolBoss.FPCDefinesCache.GetFPCVersion(CompilerFilename,TargetOS,TargetCPU,false)
 else
   FPCVer:='';
+aFileName := GetForcedPathDelims('/usr/lib/$(TargetCPU)-$(TargetOS)-gnu/fpc/$(FpcVer)/msg/errore.msg');
+if not GlobalMacroList.SubstituteStr(aFilename) then begin
+  debugln(['TFPCMsgFilePool.GetMsgFileNames failed for ',CompilerFilename,' TargetCPU="',TargetCpu,'"',' TargetOS="',TargetOs,'"']);
+end;
+if FileExistsCached(aFilename) then begin
+  fCurrentEnglishFile:=aFilename;
+end else begin
 FPCSrcDir:=EnvironmentOptions.GetParsedFPCSourceDirectory(FPCVer);
 if FilenameIsAbsolute(FPCSrcDir) then begin
   // FPCSrcDir exists => use the errore.msg
@@ -1020,6 +1027,7 @@ begin
   if FileExistsCached(aFilename) then
 fCurrentEnglishFile:=aFilename;
 end;
+end;
 if not FileExistsCached(fCurrentEnglishFile) then begin
   // as fallback use the copy in the Codetools directory
   aFilename:=EnvironmentOptions.GetParsedLazarusDirectory;


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

Bug#919224: RM: maliit-framework/experimental -- ROM; dead upstream, unused

[Iain Lane]

Package: ftp.debian.org
Severity: normal

Control: clone -1 -2
Control: retitle -2 maliit-plugins/experimental -- ROM; dead upstream, unused

Hi,

These were going to be used as a general OSK type thing, but then the
project(s) died upstream, and I forgot about them until bunk reminded me
on IRC. We should remove them as they're not really useful/usable/used.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]

Bug#919223: ruby-haml-contrib FTBFS with ruby-haml 5.0.4-1

[Adrian Bunk]

Source: ruby-haml-contrib
Version: 1.0.0.1-2
Severity: serious
Tags: ftbfs buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-haml-contrib.html

...
┌──┐
│ Run tests for ruby2.5 from debian/ruby-tests.rb  │
└──┘

RUBYLIB=/build/1st/ruby-haml-contrib-1.0.0.1/debian/ruby-haml-contrib/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-haml-contrib/usr/share/rubygems-integration/all:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all
 ruby2.5 debian/ruby-tests.rb
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- temple (LoadError)
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /usr/lib/ruby/vendor_ruby/haml/temple_engine.rb:2:in `'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /usr/lib/ruby/vendor_ruby/haml/engine.rb:11:in `'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /usr/lib/ruby/vendor_ruby/haml.rb:23:in `'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /build/1st/ruby-haml-contrib-1.0.0.1/test/test_helper.rb:1:in 
`'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /build/1st/ruby-haml-contrib-1.0.0.1/test/php_filter_test.rb:1:in 
`'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from debian/ruby-tests.rb:2:in `block in '
from debian/ruby-tests.rb:2:in `each'
from debian/ruby-tests.rb:2:in `'
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install 
/build/1st/ruby-haml-contrib-1.0.0.1/debian/ruby-haml-contrib returned exit 
code 1
make: *** [debian/rules:4: binary] Error 1

Bug#919001: emacs-gtk: fails to upgrade to 1.26.1+1-3

[Paul Gevers]

On Sun, 13 Jan 2019 13:25:24 -0600 Rob Browning 
wrote:
> > Tried to uninstall emacspeak package only and the problems appears again,
> > so you're right. I'm not able to uninstall it anyway. Should I report the
> > bug to them?
> 
> Hmm, suppose it may make sense to reassign this bug there for now, so
> I've done that (above).  We can always reassign it to emacs if that
> turns out to to be appropriate.

Indeed.

Which version of emacspeak are we talking about here?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#919218: non-transition: libqt5gui5-gles

[Dmitry Shachnev]

Package: release.debian.org

Dear Release team,

In Qt/KDE team, we have recently been working on Qt packages built
with OpenGL ES support. This is what most participants of the Qt OpenGL
thread [1] expressed their wish for.

The main idea is that there is now a libqt5gui5-gles package (and,
in future, libqt5quick5-gles and some others) that can be installed
instead of their non-gles equivalents and provide mostly the same API.
It is described in more details in README.Debian [2].

However, in order for this scheme to work properly, we need to rebuild
all packages depending on libqt5gui5 to gain a new dependency on
libqt5gui5 | libqt5gui5-gles (they will get it automatically from the
symbols file if they do not use any desktop OpenGL specific ABI).

This is not a regular transition because the packages can be rebuilt
at any time, in any order, and there are no testing migrations involved.

Would such a rebuild be possible? If yes, can we plan for it to happen
after the freeze? Or maybe it's even possible to do it now?

Ben file:

title = "libqt5gui5-gles";
is_affected = .depends ~ "libqt5gui5";
is_good = .depends ~ "libqt5gui5-gles";
is_bad = .depends ~ "libqt5gui5" & ! .depends ~ "libqt5gui5-gles";

[1]: https://lists.debian.org/debian-arm/2018/11/msg00021.html
[2]: 
https://salsa.debian.org/qt-kde-team/qt/qtbase/blob/gles/master/debian/README.Debian

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#909699:

[Rob Browning]

Control: reassign -1 libotf0
Control: retitile -1 libotf0: crash on rendering Kannada script (affects Emacs)

"J. Smith"  writes:

> This is a libotf bug. See https://debbugs.gnu.org/30193
> According to ldd, gedit does not use libotf.

Thanks -- and if I read that right, it looks like a fix may be available
in newer versions.  Perhaps libotf0 can be upgraded soon (enough for
buster).

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#919220: ITP: rumur -- model checker for the Murphi language

[Matthew Fernandez]

Package: wnpp
Severity: wishlist
Owner: Matthew Fernandez 

* Package name: rumur
  Version : 2019.01.12
  Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : The Unlicense
  Programming Lang: C, C++, Python
  Description : model checker for the Murphi language

Rumur is a model checker for use in the formal verification of finite state
machines specified in the Murphi modelling language. It is based on a previous
tool, CMurphi, and attempts to provide an approximate drop-in replacement for
CMurphi.

Rumur works by reading an input file describing a collection of state variables
and transition rules, from which it generates a C program to verify safety and
security properties of this state machine. The generated verifier works by
exhaustively exploring the state space, checking for violation of invariants or
deadlocks.

In comparison to CMurphi, Rumur generates a verifier that runs significantly
faster and uses less memory on large input problems.

The Murphi modelling language has been used extensively for hardware
verification, in particular for analysing cache coherence protocols. Rumur is
able to improve existing users’ work flow by decreasing the time to check these
models. I am not aware of any other Debian packages that provide this
functionality; existing CMurphi users generally build the tool from source.

I am the sole developer and maintainer of this tool and intend to be its
Debian maintainer as well. I have not packaged or maintained a tool for Debian
before, so I am looking for a sponsor.

Bug#919060: same problem here...

[Dragos Jarca]

after apt-get update and apt-get dist-upgrade...

now gitlab cannot be used...

cannot upgrade to experimental to...

root@omv:/usr/share/gitlab# apt-get install ruby-gitaly=1.5.0+dfsg-1 
ruby-responders ruby-default-value-for=3.1.1-1 ruby-devise 
ruby-doorkeeper ruby-doorkeeper-openid-connect ruby-recaptcha 
ruby-devise-two-factor ruby-browser ruby-graphiql-rails 
ruby-acts-as-taggable-on ruby-redis-rails ruby-asana=0.8.1-1 
ruby-kubeclient=4.2.0-1 ruby-webpack-rails ruby-sass-rails 
ruby-font-awesome-rails ruby-premailer-rails ruby-rails-i18n=5.1.2-1 
ruby-peek ruby-peek-gc ruby-peek-pg ruby-peek-rblineprof ruby-peek-redis 
ruby-lograge ruby-actionmailer=2:5.2.2+dfsg-1 
ruby-actionpack=2:5.2.2+dfsg-1 ruby-actionview=2:5.2.2+dfsg-1 
ruby-activemodel=2:5.2.2+dfsg-1 ruby-activerecord=2:5.2.2+dfsg-1 
ruby-activesupport=2:5.2.2+dfsg-1 ruby-activestorage ruby-actioncable 
ruby-activejob=2:5.2.2+dfsg-1 ruby-railties=2:5.2.2+dfsg-1 
ruby-sprockets-rails ruby-rack=2.0.6-3 ruby-rails=2:5.2.2+dfsg-1 
gitlab-common=11.6.0+dfsg-1 ruby-rails-dom-testing=2.0.3-3 
ruby-arel=9.0.0-2 ruby-http=3.3.0-1 ruby-http-form-data=2.1.0-1 
rails=2:5.2.2+dfsg-1 gitlab=11.6.0+dfsg-1 gitaly=1.12.0+debian-1 
ruby-actionpack-xml-parser=2.0.1-1 redmine ruby-protected-attributes=1.1.4-2

Reading package lists... Done
Building dependency tree
Reading state information... Done
ruby-sprockets-rails is already the newest version (2.3.2-1).
ruby-sprockets-rails set to manually installed.
ruby-graphiql-rails is already the newest version (1.4.10-1).
ruby-graphiql-rails set to manually installed.
redmine is already the newest version (3.4.6-1).
ruby-acts-as-taggable-on is already the newest version (5.0.0-2).
ruby-acts-as-taggable-on set to manually installed.
ruby-browser is already the newest version (2.5.3-1).
ruby-browser set to manually installed.
ruby-devise is already the newest version (4.5.0-1).
ruby-devise set to manually installed.
ruby-devise-two-factor is already the newest version (3.0.3-1).
ruby-devise-two-factor set to manually installed.
ruby-doorkeeper is already the newest version (4.4.2-1).
ruby-doorkeeper set to manually installed.
ruby-doorkeeper-openid-connect is already the newest version (1.5.2-1).
ruby-doorkeeper-openid-connect set to manually installed.
ruby-font-awesome-rails is already the newest version (4.7.0.4-1).
ruby-font-awesome-rails set to manually installed.
ruby-lograge is already the newest version (0.10.0-1).
ruby-lograge set to manually installed.
ruby-peek is already the newest version (1.0.1-1).
ruby-peek set to manually installed.
ruby-peek-gc is already the newest version (0.0.2-1).
ruby-peek-gc set to manually installed.
ruby-peek-pg is already the newest version (1.3.0-1).
ruby-peek-pg set to manually installed.
ruby-peek-rblineprof is already the newest version (0.2.0-1).
ruby-peek-rblineprof set to manually installed.
ruby-peek-redis is already the newest version (1.2.0-1).
ruby-peek-redis set to manually installed.
ruby-premailer-rails is already the newest version (1.9.7-1).
ruby-premailer-rails set to manually installed.
ruby-protected-attributes is already the newest version (1.1.4-2).
ruby-protected-attributes set to manually installed.
ruby-recaptcha is already the newest version (4.11.1-1).
ruby-recaptcha set to manually installed.
ruby-redis-rails is already the newest version (5.0.2-3).
ruby-redis-rails set to manually installed.
ruby-responders is already the newest version (2.4.0-3).
ruby-responders set to manually installed.
ruby-sass-rails is already the newest version (5.0.6-2).
ruby-sass-rails set to manually installed.
ruby-webpack-rails is already the newest version (0.9.11+git-1).
ruby-webpack-rails set to manually installed.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ruby-protected-attributes : Depends: ruby-activemodel (< 2:5.0) but 
2:5.2.2+dfsg-1 is to be installed

E: Unable to correct problems, you have held broken packages.
root@omv:/usr/share/gitlab#

Seems that is a incopatibility between gitlab and redmine...

I try to use in production and now my team cannot commit changes.

--
Cu respect,
Dragos Jarca
Owner
Dynamic Puzzle S.R.L.
www.dynamicpuzzle.ro

Bug#919222: ubuntu-keyring: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: ubuntu-keyring
Version: 2018.09.18.1-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for ubuntu-keyring's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


ubuntu-keyring_2018.09.18.1-1_pt.po.gz
Description: application/gzip

Bug#919221: lxc: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: lxc
Version: 1_3.1.0+really3.0.3-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for lxc's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


lxc_1_3.1.0+really3.0.3-2_pt.po.gz
Description: application/gzip

Bug#919219: abcm2ps: fails to build from scratch because debhelper detects the ninja build system

[Nicolas Boulenguez]

Package: abcm2ps
Version: 8.14.2-0.1
Severity: important
Tags: patch

My NMU fails to build because debhelper uses ./build.ninja instead of
./configure and ./Makefile.in.  This is quite surprising, and I cannot
reproduce the issue in my chroot.

However, the attached patch selects an explicit build system and most
probably fixes the issue.

It upgrades to debhelper 12 as well.

Do you want to upload the fix?
May I prepare another NMU?
Shall I set a shorter delay?
>From 277477041beeecea5174ad858aef2bf2c9f1aa4b Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sun, 13 Jan 2019 18:29:28 +0100
Subject: Fix for the FTBFS. Please add the bug number in the changelog entry.


diff --git a/debian/changelog b/debian/changelog
index e58aa37..d26f0e4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+abcm2ps (8.14.2-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Debhelper 12.
+  * Fix the build with an explicit debhelper build system.
+
+ -- Nicolas Boulenguez   Sun, 13 Jan 2019 18:10:08 +0100
+
 abcm2ps (8.14.2-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index b4de394..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-11
diff --git a/debian/control b/debian/control
index ed43b92..d016670 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: text
 Priority: optional
 Maintainer: Anselm Lingnau 
 Build-Depends:
- debhelper (>= 11),
+ debhelper-compat (= 12),
  libfreetype6-dev,
  libpango1.0-dev,
  pkg-config,
diff --git a/debian/rules b/debian/rules
index e864f68..e2bff7f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,4 +4,4 @@ export DEB_BUILD_MAINT_OPTIONS := hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND := -Wl,--as-needed
 
 %:
-   dh $@
+   dh $@ --buildsystem=autoconf

Bug#918450: RFS: elpy/1.28.0-1

[Chris Lamb]

Nicholas D Steeves wrote:

> elpy (1.28.0-1) unstable; urgency=medium

… uploaded.

Regarding:

ifneq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
echo -e "\nnodoc profile enabled, building without sphinxdoc..\n"
dh $@ --with elpa,python3 --buildsystem=pybuild
else
dh $@ --with elpa,python3,sphinxdoc --buildsystem=pybuild
endif

... is there a bug report (or similar?) against sphinxdoc that will
do the right thing by default? Very ugly IMHO to do this in debian/
rules and, of course, this essentially has to be copy-pasted into
every package that uses sphinxdoc...


Regards,

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