Bug#917707: golang-github-gin-gonic-gin: FTBFS: dh_auto_test: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 2 github.com/gin-gonic/gin github.com/gin-gonic/gin/binding github.com/gin-gonic/gin/gin

[Roger Shimizu]

user debian-rele...@lists.debian.org
usertags -1 + bsp-2019-01-jp-tokyo
thanks

I'm trying to see this issue in Tokyo BSP 2019/January.
- https://wiki.debian.org/BSP/2019/01/ja/Tokyo

But it builds fine under my ARCH=i386 git-pbuilder environment.
And it seems fine on reproducible-builds:
- 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-gin-gonic-gin.html

I guess it's a temporary FTBFS due to some dependencies, which is fixed already.
We can continue to observe the result from reproducible-builds for a
while. If it continuous OK, we can safely close this ticket.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#908783: ITP: firmware-microbit-micropython -- MicroPython runtime for the BBC micro:bit

[Petter Reinholdtsen]

[Nick Morrott]
> It is being reviewed at the moment.

Very good.  Any estimate on when this part is done?

I had a look, at there seem to be something wrong with the pristine-tar
branch at the moment.  The
firmware-microbit-micropython_1.0.1.orig.tar.xz.id files contain a
reference to a git commit that is not in the git repository, causing gbp
buildpackage to fail.

Changing the .id file to refer to the commit behind upstream/1.0.1
helped solve the problem.
-- 
Happy hacking
Petter Reinholdtsen

Bug#919751: buildbot: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Package: buildbot
Version: 1.7.0-2
Severity: wishlist
Tags: patch l10n

Please find the initial German debconf translation for buildbot
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# buildbot debconf templates translation
# Copyright (C) 2019
# This file is distributed under the same license as the buildbot package.
# Robin Jarry , 2019.
# Helge Kreutzmann , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: buildbot\n"
"Report-Msgid-Bugs-To: build...@packages.debian.org\n"
"POT-Creation-Date: 2019-01-08 11:33+0100\n"
"PO-Revision-Date: 2019-01-13 19:15+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: german \n"
"Language: de \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../buildbot.templates:1001
msgid "Upgrade buildbot master instances when installing new versions?"
msgstr ""
"Upgrade der Buildbot-Masterinstanz bei der Installation einer neuen Version "
"durchführen?"

#. Type: boolean
#. Description
#: ../buildbot.templates:1001
msgid ""
"Stop, run ``buildbot upgrade-master'' and restart all buildbot master "
"instances when installing new versions."
msgstr ""
"Stoppt alle Buildbot-Masterinstanzen, führt »buildbot upgrade-master« aus "
"und startet alle Buildbot-Masterinstanzen neu, wenn eine neue Version "
"installiert wird."

#. Type: boolean
#. Description
#: ../buildbot.templates:1001
msgid ""
"Please note that the ``buildbot upgrade-master'' operation is potentially "
"destructive and it is irreversible. It is not possible to \"downgrade\" an "
"upgraded master instance. For these reasons, some users may want to do "
"backups before doing it manually."
msgstr ""
"Bitte beachten Sie, dass die Aktion »buildbot upgrade-master« möglicherweise "
"zerstörerisch wirkt und nicht umkehrbar ist. Es ist nicht möglich, ein "
"»Downgrade« einer Masterinstanz durchzuführen, für die ein Upgrade "
"durchgeführt wurde, d.h. eine Rückkehr zu einer alten Version ist nicht "
"möglich. Aus diesem Grund möchten manche Benutzer eine Sicherungskopie "
"anlegen, bevor sie diesen Befehl von Hand ausführen."

#. Type: boolean
#. Description
#: ../buildbot.templates:1001
msgid ""
"However, this operation is mandatory and buildbot will fail to restart a "
"master instance if it has not been performed. See buildbot(7) for more "
"details."
msgstr ""
"Allerdings ist diese Aktion zwingend notwendig und Buildbot wird keine "
"Masterinstanz neu starten können, falls die Aktion nicht durchgeführt wurde. "
"Siehe buildbot(7) für weitere Details."

Bug#919596: build-dependencies when crossbuilding choose-mirror

[Cyril Brulebois]

Hi JH,

jhcha54008  (2019-01-17):
> Package: choose-mirror
> Version: 2.96
> Severity: wishlist
> Tags: patch
> 
> Dear Maintainer,
> 
> Crossbuilding choose-mirror with dpkg-buildpackage -a  results in
> an error at the present time.
> 
> It succeeds with the patch below.

I'd be happy to get a log for the failure and/or a complete description
on how to reproduce it; a description of why the change is needed / how
it works would also be welcome.

(No objections on the patch on its own, but not everyone is uptospeed
regarding crossbuilding, so some details would be appreciated.)


Thanks,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#919750: ITS: libzip

[Ondřej Surý]

Package: src:libzip
Version: 1.1.2-1.1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I intent to salvage the package.

Ondrej

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

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

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAlxCxJ9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcJ2mA//cZt3dlUFiz0b3U/mP6pmXa4BdTvS1P8fq1TEfueVfnIeWGv8Ol6s8j/v
R5CRErsL9L6FwZe4aKK/6EdlKNBNGulfD3caYRsKAnWpXzBGs/whsWsDPxOCbj0V
W297ZasPC2N9oJRrINzWbn29htSH3PtEdtKSPuBUehXb4w2MlMmv8jxm1I7vKR6m
GsNZDCM1NPI7W6wdsD/VwXuvdPNSRTJuR5DNntnfe7L2XjuH033/WnT7FkBaW7dE
QqeG1JztiTkYYyHu+zAG3RQ0OZuEbkcbR/ELUpN3zbH4T26J/uBl32yw9xPbKeaB
qpX8Nu2j4NGkUJXWhoRSC2lu6nBfdnDUHt1RCxHXpRoaY6qqSFBfI4zT4IbsODXg
DAZPvJorrXJ34ng3FoiimwTx1vGPFqN7sj5vbTGMNzKlMGv6iAvyQHhRrdmiWcKd
KoTIZgNHDrSraXtNRc7n4sRyggkqWI4GOtixTbDo8WCKFLZZg6HYT7oAvHqx79mB
mf3cL2Jq6pVilvlTaJbqtHx4jNKuTRzVv9Wn9AN4fmAD6Qc8U1QidPN6EakX7FTW
cVi7E5JpTq7bp1p6Hc+Qvo7KPUYFHOLCps7j9SU5vI1/UwE/60sndzQN6k0+XWZD
Obj2vj1MHHzpIiWCiClusyZSzTuY1S+UnTg0LaKIb/krTLRZCUE=
=9B3Z
-END PGP SIGNATURE-

Bug#912183: python3.7: changed reserved characters moved from RFC 2396 to RFC 3986

[SUGIMOTO Norimitsu]

tag 912183 + moreinfo


See Python 3.7 document,

https://docs.python.org/3.7/library/urllib.parse.html#urllib.parse.quote

  Changed in version 3.7: Moved from RFC 2396 to RFC 3986 for quoting URL 
strings. “~” is now included in the set of reserved characters.

I change test_cookies.py, test has success.

$ diff -u .pybuild/cpython3_3.7_cookies/build/test_cookies.py 
.pybuild/cpython3_3.7_cookies/build/test_cookies_my.py
--- .pybuild/cpython3_3.7_cookies/build/test_cookies.py 2014-07-26 
05:40:22.0 +0900
+++ .pybuild/cpython3_3.7_cookies/build/test_cookies_my.py  2019-01-19 
14:56:28.768869520 +0900
@@ -2225,7 +2225,7 @@
 else:
 assert cookie_value_re.match(quoted)
 
-assert set(dont_quote) == set("!#$%&'()*+/:<=>?@[]^`{|}~")
+assert set(dont_quote) == set("!#$%&'()*+/:<=>?@[]^`{|}")
 
 # From 128 on urllib.quote will not work on a unichr() return value.
 # We'll want to encode utf-8 values into ASCII, then do the quoting.
@@ -2257,7 +2257,7 @@
 else:
 assert extension_av_re.match(quoted)
 
-assert set(dont_quote) == set(' !"#$%&\'()*+,/:<=>?@[\\]^`{|}~')
+assert set(dont_quote) == set(' !"#$%&\'()*+,/:<=>?@[\\]^`{|}')
 
 
 test_encode_cookie_value = _simple_test(encode_cookie_value,


$ python3.7 -m pytest .pybuild/cpython3_3.7_cookies/build/test_cookies_my.py 
= test session starts 
==
platform linux -- Python 3.7.2, pytest-4.0.2, py-1.7.0, pluggy-0.8.0
rootdir: /home/norimitu/mkdeb/python-cookies-2.2.1, inifile:
collected 67 items  
   

.pybuild/cpython3_3.7_cookies/build/test_cookies_my.py 
. [ 61%]
..  
 [100%]

=== warnings summary 
===
.pybuild/cpython3_3.7_cookies/build/cookies.py:312
  
/home/norimitu/mkdeb/python-cookies-2.2.1/.pybuild/cpython3_3.7_cookies/build/cookies.py:312:
 DeprecationWarning: Flags not at the start of the expression '(?ix)  # 
Case-insens' (truncated)
ATTR_RE = re.compile(ATTR)

.pybuild/cpython3_3.7_cookies/build/test_cookies_my.py::TestDefinitions::test_expires_av
  
/home/norimitu/mkdeb/python-cookies-2.2.1/.pybuild/cpython3_3.7_cookies/build/test_cookies_my.py:578:
 DeprecationWarning: Flags not at the start of the expression 
'^Expires=(?Phttps://docs.pytest.org/en/latest/warnings.html
 67 passed, 3 warnings in 0.28 seconds 
=

regards.

Bug#919749: RM: django-html-sanitizer -- ROM; Incompatible with current bleach and dead upstream

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

It's broken and won't be fixed, so time for it to go.

Scott K

Bug#919680: old patch found

[YOSHINO Yoshihito]

Control: retitle -1 anthy-el: does not work with emacs >= 24.3

I have found that exactly the same content of this patch was included
in older versions of anthy-el in order to work with emacs >= 24.3:

https://sources.debian.org/src/anthy/9100h-25/debian/patches/work-with-emacs-24.3.1.patch/

Many patches including this have been (perhaps accidentally?) dropped
somewhere between 9100h-25 and 1:0.3-1.

Please consider re-including this patch.

Thanks in advance,
-- 
YOSHINO Yoshihito 

Bug#919748: ITP: nvchecker -- new-version checker for software releases

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Afif Elghraoui 

* Package name: nvchecker
  Version : 1.3
  Upstream Author : lilydjwg 
* URL : https://github.com/lilydjwg/nvchecker
* License : MIT
  Programming Lang: Python
  Description : new-version checker for software releases

 nvchecker (short for new version checker) is for checking if a new
 version of some software has been released.


This is a nice vendor-neutral solution for release monitoring. I think it
can also be quite useful in research, for example, to watch for updates of all
tools used in an analysis. And it doesn't have to be limited to watching
software releases, either. It could be applied to watching updates in
reference databases.

I intend to maintain nvchecker in the Debian group on salsa.

Afif

Bug#919747: gnome-keysign: please package gnome-keysign 1.0.0

[Daniel Kahn Gillmor]

Package: gnome-keysign
Version: 0.9.8-1
Severity: wishlist

gnome-keysign 1.0.0 was released by upstream 11 days ago:

https://github.com/gnome-keysign/gnome-keysign/releases/tag/1.0.0

It would be great if we could have it in debian!

thanks for maintaining gnome-keysign,

   --dkg

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

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

Versions of packages gnome-keysign depends on:
ii  avahi-daemon 0.7-4+b1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gst-plugins-base-1.0  1.14.4-1
ii  gir1.2-gstreamer-1.0 1.14.4-1
ii  gir1.2-gtk-3.0   3.24.2-3
ii  gstreamer1.0-gtk31.14.4-1
ii  gstreamer1.0-plugins-bad 1.14.4-1+b1
ii  gstreamer1.0-plugins-good1.14.4-1
ii  gstreamer1.0-x   1.14.4-1
ii  python   2.7.15-3
ii  python-avahi 0.7-4+b1
ii  python-cairo 1.16.2-1+b1
ii  python-dbus  1.2.8-2+b3
ii  python-gi3.30.4-1
ii  python-gi-cairo  3.30.4-1
ii  python-gpg   1.12.0-4
ii  python-qrcode6.0-1
ii  python-requests  2.20.0-2
ii  python-twisted-core  18.9.0-3

gnome-keysign recommends no packages.

gnome-keysign suggests no packages.

-- no debconf information

Bug#912633: Solution

[Soren Stoutner]

TL;DR

The "No supported cipher suites have been found" error message actually
means "cannot read the SSL certificate file", either because it is not
there or because the permissions prevent access.

Details:

The updated imapd-ssl file included with courier-imap 5.0.5+1.0.5-1
specifies the following:

# TLS_CERTFILE - certificate to use. TLS_CERTFILE must be owned
# by the "courier" user, and must not be world-readable.

This is not fully correct.  The certificate can be owned by `root` and
be in the `courier` group with 640 permissions, giving the courier group
read access, and it will work correctly.  But it does not work if only
root has access.  This represents a change in behavior.  Previous
versions of Courier could read an SSL certificate that was only
accessible by root.  For example, my /etc/courier/imapd.pem file, which
was installed with Courier in 2014, was set to root:courier with 600. 
It worked at the time. Since then, I switched to using a Let's Encrypt
SSL certificate, which also worked for a while.

Tightening down the permission access is a good idea, so I applaud
Courier for no longer using root access for reading certificates.  It
would just have been helpful for the error message to point to a problem
accessing the SSL certificate file instead of describing a problem with
the cipher suites (which this isn't).

The solution for me was to create a copy of the Let's Encrypt
certificate that was accessible by the `courier` process.


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

Bug#903529: test Python 3.7 compat issue

[SUGIMOTO Norimitsu]

I built the package merged Messaege #12 patch.

It is success to build package.

My python3 websocket client program works fine.
(connect websocket sever for nodejs with ws:// .)

Regards.

Bug#919638: solr-tomcat: Permission problems after update to tomcat9

[Michael Welsh Duggan]

Emmanuel Bourg  writes:

> Le 18/01/2019 à 07:19, Michael Welsh Duggan a écrit :
>
>> I have no idea why it fails to write the lock file.
>
> It probably happens because tomcat9 is sandboxed to write only into its
> own directory. You'll have to tweak the systemd configuration to allow
> Tomcat to write into the solr directory (with the ReadWritePaths directive).
>
> The solr-tomcat package is rather old now, I'm tempted to remove it.
> Upstream has moved away from supporting deployments as a web
> application, Solr now embeds it own web server (Jetty). We wouldn't have
> this kind of issue with the latest versions.

I'm not attached to the package.  I use solr as a FTS backend for
dovecot.  If you have a suggestion for how to set this up using the
debian packages without using tomcat, I'm not using tomcat for anything
else.

-- 
Michael Welsh Duggan
(m...@md5i.com)

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

[François Revol]

Hi,
I also got this message and after an hour and more than 20 opened
Firefox tabs of searching where in the GRUB configuration files it could
be I ended up digging the package files to discover it was in debconf.

I think this should be documented on the wiki page at least…

And probably this message should list the existing values to give a clue.

Bug#919599: python3-httpretty: Fails to match hostname with different case

[Ben Finney]

Control: retitle -1 python3-httpretty: Fails to match hostname with different 
case
Control: tags -1 + patch

On 18-Jan-2019, Ben Finney wrote:

> The HTTPretty library is failing to correctly mock requests sent using
> the standard-library `http.client.HTTPConnection` class.

Specifically, the HTTPretty library will *sometimes* fail to normalise
letter case for hostname, when deciding whether to match a URI.

I have made a merge request to the upstream HTTPretty project
https://github.com/gabrielfalcao/HTTPretty/issues/369#issuecomment-455744083>.

To fix the bug in the Debian ‘python3-httpretty’ package, I have
also made a merge request for this package
https://salsa.debian.org/openstack-team/python/python-httpretty/merge_requests/1>.

-- 
 \ “I have the simplest tastes. I am always satisfied with the |
  `\best.” —Oscar Wilde, quoted in _Chicago Brothers of the Book_, |
_o__) 1917 |
Ben Finney 

Bug#910295: dput: FTBFS: tests fail to mock HTTP request

[Ben Finney]

Thanks for asking.

On 18-Jan-2019, Thomas Goirand wrote:

> I wonder what's the next course of action. Upstream has been known for
> not being reactive at all. I'd bet on no reply before Buster freeze.

(I think you mean the upstream for the HTTPretty library).

Okay, that's a worry. But it's possible we can change how the test
cases use HTTPretty, to do the test without hitting this bug.

Today I have been looking at what might be causing HTTPretty to act as
though the request is not mocked, to see whether we can patch it, or
whether the DPut test cases can be changed.

> Do we really want dput to be removed from Debian?

Definitely not! Thanks for the concern, I would welcome other attempts
to keep this test suite working.

-- 
 \ “We are human only to the extent that our ideas remain humane.” |
  `\  —_Breakfast of Champions_, Kurt Vonnegut |
_o__)  |
Ben Finney 

Bug#919745: RFS: ffcvt-1.3.1

[Tong Sun]

Package: sponsorship-requests
Severity: normal

Hi,

I've prepared the Debian package of "ffcvt". The package was
tested on sbuild and was successfully built. I've
uploaded the package to the salsa repo which may be found at:
https://salsa.debian.org/go-team/packages/ffcvt

It is a handy audio/video compression tool that wraps ffmpeg for easy usage.

Please consider to review and upload it.

Thanks,

tong

* Package name: ffcvt
  Version : 1.3.1
  Upstream Author : Tong Sun
* URL : https://github.com/suntong/ffcvt
* License : MIT
  Programming Lang: Go
  Description : ffmpeg convert wrapper tool

 ffcvt - ffmpeg convert wrapper to make it simple to do high
efficiency audio/video compression (Opus/H.265) encoding.

Bug#919744: RFS: golang-github-danverbraganza-varcaser

[Tong Sun]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org

Hi,

I've prepared the Debian package of
"golang-github-danverbraganza-varcaser". The package was
tested on sbuild and was successfully built. I've
uploaded the package to the salsa repo which may be found at:
https://salsa.debian.org/go-team/packages/golang-github-danverbraganza-varcaser

It is a dependency of easygen and hence were to be packaged.

It has been gone through one round of review already.
Please consider to review it finally and upload it.

Thanks,

tong

* Package name: golang-github-danverbraganza-varcaser
  Version : 0.0~git20151108.ce61ec4-1
  Upstream Author : Danver Braganza
* URL : https://github.com/danverbraganza/varcaser
* License : MIT
  Programming Lang: Go
  Description : Provide ability to transform between common
variable casing conventions.

 Varcaser Varcaser is a library for converting variables between different
 programming language casing conventions.
 .
 The case transformation component of Varcaser is implemented without
 regular expressions.

Bug#919743: RFS: rumur/2019.01.12-1 [ITP]

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
  Version : 2019.01.12-1
  Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : The Unlicense
  Section : devel

It builds those binary packages:

   rumur - model checker for the Murphi language

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2019.01.12-1.dsc

More information about rumur can be obtained from 
https://github.com/Smattr/rumur.

Changes since the last upload:

 Initial release. Closes #919220.


Regards,
 Matthew Fernandez

Bug#917864: closed by Gianfranco Costamagna (Re: Fails to build for non-current kernel version)

[Ben Hutchings]

Control: reopen -1

# module-assistant -l 4.20.0-trunk-amd64 auto-build virtualbox-guest-source
Reading package lists... Done
Building dependency tree   
Reading state information... Done
virtualbox-guest-source is already the newest version (5.2.24-dfsg-4).
0 upgraded, 0 newly installed, 0 to remove and 52 not upgraded.
W: --force-yes is deprecated, use one of the options starting with --allow 
instead.
.
Updated infos about 1 packages
Extracting the package tarball, /usr/src/virtualbox-guest.tar.bz2, please 
wait...
/usr/bin/make -C vboxguest clean
make[1]: Entering directory '/usr/src/modules/virtualbox-guest/vboxguest'
/usr/src/modules/virtualbox-guest/vboxguest/Makefile.include.header:141: *** 
Error: unable to find the headers of the Linux kernel to build against. Specify 
KERN_VER= (currently 4.19.0-1-amd64) and run Make again.  Stop.
make[1]: Leaving directory '/usr/src/modules/virtualbox-guest/vboxguest'
make: *** [debian/rules:44: clean] Error 2
/usr/bin/make  -f debian/rules kdist_clean kdist_config binary-modules
make[1]: Entering directory '/usr/src/modules/virtualbox-guest'
/usr/bin/make -C vboxguest clean
make[2]: Entering directory '/usr/src/modules/virtualbox-guest/vboxguest'
/usr/src/modules/virtualbox-guest/vboxguest/Makefile.include.header:141: *** 
Error: unable to find the headers of the Linux kernel to build against. Specify 
KERN_VER= (currently 4.19.0-1-amd64) and run Make again.  Stop.
make[2]: Leaving directory '/usr/src/modules/virtualbox-guest/vboxguest'
make[1]: *** [debian/rules:44: clean] Error 2
make[1]: Leaving directory '/usr/src/modules/virtualbox-guest'
make: *** [/usr/share/modass/include/common-rules.make:56: kdist_build] Error 2
BUILD FAILED!
See /var/cache/modass/virtualbox-guest-source.buildlog.4.20.0-trunk-amd64.154786

It's still trying to use headers for 4.19.0-1-amd64 (the running kernel
version) when I ask to build for 4.20.0-trunk-amd64.

This has nothing to do with compatibility with any particular kernel
version; the problem is you are not passing through the target kernel
version when invoking "make clean".

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
   Inside every large problem is a small problem struggling to get out.


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

Bug#919628: Apply Julia's LLVM patches

[Lumin]

Hi,

On Fri, 18 Jan 2019 at 10:31, Sylvestre Ledru  wrote:
> > Please check and apply Julia's LLVM patches to Debian's LLVM 6.0.1:
> >
> > https://github.com/JuliaLang/julia/blob/master/deps/llvm.mk#L390-L432
> > https://github.com/JuliaLang/julia/tree/master/deps/patches
> >
> > I don't quite understand what these patches are doing.
>
> Would be nice to have a better understanding of why they have been added.
>
> Performances, bug, stability, etc.

Upstream's note about these patches: https://github.com/julialang/julia#llvm
These patches relate to performance and bugs according to the above note.

> Besides the arm issue, what otherwise is blocking you with the current
> llvm-toolchain-6 ?

Nothing else. I have no reason to keep an embedded llvm if (1) the arm
problem and (2) the upstream patches have been dealt with.

> Do you know if there is a documentation somewhere?

I think the best documentation about these patches are git commit
messages following git blame. For example

https://github.com/JuliaLang/julia/commit/e99204b52be23c49b5185d270b6697b097b16513

refers to a bug:

https://github.com/JuliaLang/julia/issues/28726

I'm glad to assemble a detailed list of patches and their corresponding bugs
if you ask. And note that I'm traveling tomorrow (Jan 20) so please don't
expect response from me on that day.

> > So in order to
> > use upstream's LLVM patches, the most straightforward way is to
> > ship an embedded LLVM in Julia's source package.
>
> Sure but it doesn't scale and this is against the Debian policy (cf 4.13).

Indeed, and embedding an LLVM makes the package much much harder to build.

> We have already too many versions of llvm in the archive, no need to add
> one more (esp
> as I am active on llvm-toolchain-*)

Although patching LLVM for julia requires some time, the resulting Debian
package could do very well with Julia 1.0.X (upstream's long time support
branch, currently in unstable, planned for Buster), and Julia 1.X (non-LTS
branch. Not decided whether to upload)

Bug#915816: RM: uptimed -- ROM; long time bugs non-fixed, better alternatives

[gustavo panizzo]

Hello

Alex, any update on this?
Is there anything I can help with to move this forward?

--
IRC: gfa
GPG: 0X44BB1BA79F6C6333

Bug#919626: Emits NEON code on armv7a due to wrong CPU detection

[Lumin]

Glad to hear, thanks!

On Fri, 18 Jan 2019 at 09:49, Sylvestre Ledru  wrote:
>
> I fixed that in 7, I can probably easily backport the fix to 6.
>
> S
>
>
> Le 18/01/2019 à 04:41, M. Zhou a écrit :
> > Package: llvm-6.0-dev
> > Version: 1:6.0.1-9.2
> > X-Debbugs-CC: gin...@debian.org
> >
> > Dear LLVM maintainers,
> >
> > Recently Julia FTBFS on armhf due to SIGILL from NEON instruction.
> > (ginggs digged into the SIGILL and confirmed it's due to NEON)
> > However, julia is supposed to compile multiple code branches where
> > one of them involves no NEON instruction. Emulation based on QEMU's
> > cortex-a7 CPU proves this point.
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919183
> >
> > Neither Debian's LLVM, nor Julia's patched LLVM, has fixed this issue.
> >
> > The incorrect CPU detection can be reproduced on abel, LLVM
> > also emits NEON code to abel's CPU.
> >
> > ___
> > Pkg-llvm-team mailing list
> > pkg-llvm-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team



-- 
Best,

Bug#918722: debootstrap: says InRelease file expired

[Hideki Yamane]

On Wed, 9 Jan 2019 14:13:14 +0100
Julien Cristau  wrote:
> I reverted the 1.0.113 changes to unbreak this and uploaded 1.0.114.

 Thanks to take caring for this.

> I'm happy to review an updated version when you get that working.  Hope
> that's ok.

 Now I've pushed MR with (hopefully) fixed version, please check it.


-- 
Hideki Yamane 

Bug#919741: lilo.conf.5: Formatting and spelling corrections in the manual

[Bjarni Ingi Gislason]

Package: lilo
Version: 1:24.2-4
Severity: minor
Tags: patch

Dear Maintainer,

the compressed patch is in the attachment (uncompressed 722 lines).

Main issues:

Input file is lilo.conf.5

mandoc: Remove whitespace at end of input file

mandoc: lilo.conf.5:990:4: STYLE: unterminated quoted argument
mandoc: lilo.conf.5:695:1: WARNING: skipping paragraph macro: sp after LP
mandoc: lilo.conf.5:1066:1: WARNING: skipping paragraph macro: sp after LP
mandoc: lilo.conf.5:1065:2: WARNING: skipping paragraph macro: LP empty

#

Change 'b' to 'B' for a byte

Always use a (unpaddable or no-break) space between a number and an
unit (except if it is an input to a command, that prohibis that).

394:high in memory as possible, but never above 15Mb.  This is due to a BIOS
396:memory above 15Mb (up to a kernel imposed limit, around 768Mb) for

#

Use \&.\|.\|.\& to represent an ellipsis (or define a string, e.g. 'EL'
for it).

531:The per-image option `password=...' (see below) applies to all images. This



Reduce space between words.

#

Use "\e" to print the escape character instead of "\\" (which gets
interpreted in copy mode).

727:in more lines using "\\" as last character of a line, e.g.
750:using "\\" as last character of a line. See example of addappend option.

#

Use the word (in)valid instead of (il)legal if not related to legal matters.
See "www.gnu.org/prep/standards".

477:Legal color-scheme strings would be

#

Find a repeated word

! 258 --> be

#

Add a comma (or \&) after "e.g." and "i.e.", or use English words
(man-pages(7) [package "manpages"]).

191:Sets the name of the device (e.g. hard disk or partition) that contains
350:(e.g. PC/MS-DOS) are using the same disk, they may change the 
359:tracks. Also, with some disks (e.g. some large EIDE disks with address 
581:less secure than access to the console, e.g. if the line is connected 
727:in more lines using "\\" as last character of a line, e.g.
758:Like `append', but removes all other options (e.g. setting of the root
772:file system read-write later (e.g. after fsck'ing it).
1003:option, the next reboot (e.g. 
1051:are specified on the command line (e.g. 'single').  May be used

#

Add a missing left italic correction after \fI or use a macro

683:\fBimage=\fP\fI\fP
690:\fBother=\fP\fI\fP
701:\fBrange=\fP\fI-\fP
702:\fBrange=\fP\fI+\fP
703:\fBrange=\fP\fI\fP

#

Remove superfluous quotation marks (") from the argument of a
single-font macro.

78:.I "boot:"
455:.I "install="
486:.I "menu"
715:.B "append="
719:.B "append="
722:.B "addappend="
876:.I "automatic"

#

Rephrase the beginning of a sentence, if it starts with a digit (see a
style manual).

593:extended rates 19200, 38400, and 57600(56000).  115200 is allowed, but may

#

The name of a man page is set in bold and the section in roman (see
man-pages(7)).

29:is read by the boot loader installer 'lilo' (see lilo(8)).
755:drivers. See man pages for \fImkinitrd(8)\fP.
841:the rdev(8) program.)
1068:lilo(8), mkinitrd(8), mknod(1), mkrescue(8), rdev(8).

#



-- 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 linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lilo depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  dpkg   1.19.2
ii  libc6  2.28-5
ii  libdevmapper1.02.1 2:1.02.155-1
ii  perl   5.28.1-3

lilo recommends no packages.

Versions of packages lilo suggests:
ii  e2fsprogs  1.44.5-1

-- debconf information:
* lilo/diskid_uuid: true
  lilo/runme: false
* lilo/new-config:
  lilo/add_large_memory: false

-- 
Bjarni I. Gislason


lilo.conf.5.diff.gz
Description: GNU Zip compressed data

Bug#919742: orthanc-wsi FTBFS 'class GlobalDcmDataDictionary' has no member named 'unlock'

[peter green]

Package: orthanc-wsi
Severity: serious
Version: 0.5-2

orthanc-wsi fails to build in unstable, I presume this was triggered by the 
dcmtk transition.

https://buildd.debian.org/status/fetch.php?pkg=orthanc-wsi=amd64=0.5-2%2Bb3=1547409452=0


/<>/BuildApplications/Orthanc-1.3.2/Core/DicomParsing/FromDcmtkBridge.cpp:188:21:
 error: 'class GlobalDcmDataDictionary' has no member named 'unlock'; did you mean 'rdlock'?
  dcmDataDict.unlock();

Bug#919627: kodi: Segfault at startup on computer that has been working with Kodi

[Stephen Paul Weber]

libdrm-nouveau2:amd64 (2.4.74-1, 2.4.95-1~bpo9+1)

The libdrm-nouveau2 and related seem suspect, especially coming from 
backports.


Confirmed.  I downgraded libdrm-nouveau2 to the non-bpo version and then 
went through the pain of getting my system back to a consistent state.  Kodi 
now runs without issue once again.


signature.asc
Description: PGP signature

Bug#919627: kodi: Segfault at startup on computer that has been working with Kodi

[Stephen Paul Weber]

Could you please check the upgrade logs and maybe tell which package
upgrade broke kodi for you?


$ grep ^Upgrade /var/log/apt/history.log
Upgrade: libdatetime-timezone-perl:amd64 (1:2.09-1+2018g, 1:2.09-1+2018i), 
tzdata:amd64 (2018g-0+deb9u1, 2018i-0+deb9u1)
Upgrade: flatpak:amd64 (0.8.9-0+deb9u1, 1.0.4-1~bpo9+1), bubblewrap:amd64 
(0.1.7-1, 0.3.1-2~bpo9+1), flatpak-builder:amd64 (0.8.9-0+deb9u1, 
1.0.1-1~bpo9+1), libostree-1-1:amd64 (2016.15-5, 2018.9.1-1~bpo9+1), 
xdg-desktop-portal:amd64 (0.5-1, 1.0.3-1~bpo9+1)
Upgrade: libgles2-mesa:amd64 (13.0.6-1+b2, 18.2.6-1~bpo9+1), 
libdrm-nouveau2:amd64 (2.4.74-1, 2.4.95-1~bpo9+1), libdrm-nouveau2:i386 
(2.4.74-1, 2.4.95-1~bpo9+1), libegl1-mesa-dev:amd64 (13.0.6-1+b2, 
18.2.6-1~bpo9+1), libglapi-mesa:amd64 (13.0.6-1+b2, 18.2.6-1~bpo9+1), 
libglapi-mesa:i386 (13.0.6-1+b2, 18.2.6-1~bpo9+1), mesa-common-dev:amd64 
(13.0.6-1+b2, 18.2.6-1~bpo9+1), libegl1-mesa:amd64 (13.0.6-1+b2, 
18.2.6-1~bpo9+1), libgbm1:amd64 (13.0.6-1+b2, 18.2.6-1~bpo9+1), 
libwayland-client0:amd64 (1.12.0-1, 1.16.0-1~bpo9+1), libwayland-bin:amd64 
(1.12.0-1, 1.16.0-1~bpo9+1), libdrm-amdgpu1:amd64 (2.4.74-1, 2.4.95-1~bpo9+1), 
libdrm-amdgpu1:i386 (2.4.74-1, 2.4.95-1~bpo9+1), libwayland-dev:amd64 
(1.12.0-1, 1.16.0-1~bpo9+1), libwayland-egl1-mesa:amd64 (13.0.6-1+b2, 
18.2.6-1~bpo9+1), libgles2-mesa-dev:amd64 (13.0.6-1+b2, 18.2.6-1~bpo9+1), 
libdrm2:amd64 (2.4.74-1, 2.4.95-1~bpo9+1), libdrm2:i386 (2.4.74-1, 
2.4.95-1~bpo9+1), libgl1-mesa-dev:amd64 (13.0.6-1+b2, 18.2.6-1~bpo9+1), 
libgl1-mesa-glx:amd64 (13.0.6-1+b2, 18.2.6-1~bpo9+1), libgl1-mesa-glx:i386 
(13.0.6-1+b2, 18.2.6-1~bpo9+1), libdrm-intel1:amd64 (2.4.74-1, 
2.4.95-1~bpo9+1), libdrm-intel1:i386 (2.4.74-1, 2.4.95-1~bpo9+1), 
libdrm-radeon1:amd64 (2.4.74-1, 2.4.95-1~bpo9+1), libdrm-radeon1:i386 
(2.4.74-1, 2.4.95-1~bpo9+1), libdrm-dev:amd64 (2.4.74-1, 2.4.95-1~bpo9+1), 
libwayland-server0:amd64 (1.12.0-1, 1.16.0-1~bpo9+1), libwayland-cursor0:amd64 
(1.12.0-1, 1.16.0-1~bpo9+1)
Upgrade: fdroidserver:amd64 (0.7.0-2, 1.0.6-1~bpo9+1)
Upgrade: vlc-bin:amd64 (3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), 
vlc-plugin-video-output:amd64 (3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), 
vlc-plugin-samba:amd64 (3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), vlc-plugin-qt:amd64 
(3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), libsystemd0:amd64 (232-25+deb9u6, 
232-25+deb9u8), libzmq5:amd64 (4.2.1-4, 4.2.1-4+deb9u1), 
vlc-plugin-skins2:amd64 (3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), 
vlc-plugin-visualization:amd64 (3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), 
vlc-l10n:amd64 (3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), vlc-plugin-notify:amd64 
(3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), libvlc5:amd64 (3.0.3-1-0+deb9u1, 
3.0.6-0+deb9u1), udev:amd64 (232-25+deb9u6, 232-25+deb9u8), libvlccore9:amd64 
(3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), libudev1:amd64 (232-25+deb9u6, 
232-25+deb9u8), libvlc-bin:amd64 (3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), 
libudev-dev:amd64 (232-25+deb9u6, 232-25+deb9u8), systemd-sysv:amd64 
(232-25+deb9u6, 232-25+deb9u8), vlc:amd64 (3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), 
libpam-systemd:amd64 (232-25+deb9u6, 232-25+deb9u8), vlc-data:amd64 
(3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1), systemd:amd64 (232-25+deb9u6, 
232-25+deb9u8), vlc-plugin-video-splitter:amd64 (3.0.3-1-0+deb9u1, 
3.0.6-0+deb9u1), vlc-plugin-base:amd64 (3.0.3-1-0+deb9u1, 3.0.6-0+deb9u1)

I believe that last one (with vlc etc) was executed *after* I observed the 
problem.  The libdrm-nouveau2 and related seem suspect, especially coming 
from backports.


signature.asc
Description: PGP signature

Bug#919740: merge request submitted

[Mike Miller]

Control: tags -1 + patch

I've posted a MR at

  https://salsa.debian.org/lintian/lintian/merge_requests/130

Thanks,

-- 
mike

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Pierre Ynard]

> Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will
> be in 2.93-4 (due in few days). Sysvinit will *not* assume, that
> /usr is mounted at /sbin/init invocation in Buster. I promise.

Thank you.

> That ship has long since sailed. What's the point of making sysv-rc
> support non-/usr early boot if the rest of the system doesn't?

This is the classic systemd philosophy argument that if portability
cannot be fully guaranteed, it is counterproductive and harmful and
ought to be eliminated. Then it leads to absurd, complete reversals of
how things should be, such as udev (not even original systemd software)
imposing requirements on the kernel on any system where it's pulled
in (and unlike init, there's no alternative to it). Never mind that
"support" and "fully guaranteed" are fuzzy concepts whose goal posts can
be adjusted by the authority telling us what should be done. Personally
I think it's quite a perversion of common software standards to reach a
point where portability efforts are frowned upon and discouraged.

> It may still work on some simple installs, but even that quite rapidly
> degrades as random packages get changed to simplify this away.

It degrades as random packages get pushed into alignment with the
simplified state that systemd wants to achieve, which is itself based
on eliminating "harmful" portability. Just stop that self-fulfilling
prophecy, and it will work better.

> If someone insists to pretend / vs /usr on separate fs without initramfs
> would be supported for Buster

No, I don't think anybody is aiming at "pretending" "support". I think
what people are talking about here is just not breaking stuff, just not
choosing the one option (talking about the location of two files here)
that deliberately breaks more stuff for the sake of establishing clearly
what is broken and what isn't according to a controversial ideology.
Please don't make it sound like they are pretending things that you're
shooting down.

> But what next? Assumption of mounted /usr simplify things. You can
> take a look at #551555, but I do not think this is singular case.

First, #551555 is trying to solve a real problem with supporting many
different configurations; whereas putting init files on /usr solves and
supports nothing, it just potentially breaks things.

Assuming that /usr is mounted is one way to approach #551555; but
assuming that /usr isn't on NFS, or that mountnfs.sh won't need DNS,
would also simplify things - and would be less pervasive options. That
still doesn't mean they're good ideas. Of course, the only assumption
that could already be provided by a system-wide decision from the Debian
project when you start looking at this particular problem, is the /usr
one; so the solutions are skewed, but at least there is that option.

> Two-part mount process complicates initscripts for, well, what?

Note that the proposed solution to #551555 still requires shifting many
packages from rcS.d to rc2.d. Bootstrapping /usr is still a complicated
problem if you don't know in advance which set of tools and scripts will
need to do it.

Personally, I'm not talking about a two-part mount process. My
systems boot fine with a single mount pass, and so do plenty other
rationally designed boot setups mindful of that. If you leave them easy
possibilities, users can still tweak dependencies and scripts to get
their boot sequence just right.

And if anything, booting from initramfs then pivoting to / is the
two-part process I would personally try to avoid.

>   * what are benefits of setup without initramfs *and* with separate /usr
>   partition on *fresh installation*?

This systemd opinion itself names plenty of benefits for a separate /usr:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
These benefits are what /usr merge is trying to improve, further and
complete. The ideas behind them don't really relate to initramfs or
whether the installation is fresh.

> That you may hop onto a time machine with a modern install media but
> no modern hardware? I'm not aware of any widespread machines that
> have ~2GB of fast local storage with the rest separate. If there's a
> separate boot media, it tends to have up to ~256MB tops, fit only for
> the kernel and bootloader.

Wrong, 256MB is quite enough for my whole separate /, not just kernel
and bootloader.

> Around a decade ago, Nokia installed _tiny_ boot disk and large eMMC into
> N{7,8,9}00, but even then they found / vs /usr to be useless, and concocted
> their own scheme.  Same happens for other setups from this millenium.

You've mentioned one specialized use case that didn't find interest in
a separate /usr. So what, what have you proven? I've worked too on some
deployment setups that had no benefit in separate partitioning, that
doesn't mean it's pointless in every case. The reasons are diverse and
the most interesting ones to me are other than hardware size.

> If someone could show us a case when early 

Bug#908862: neutron: FTBFS (failing tests)

[Santiago Vila]

reopen 908862
found 908862 2:13.0.2-1
found 908862 2:13.0.2-3
found 908862 2:13.0.2-5
thanks

Hello Thomas.

This is still happening, both in reproducible-builds and also in my
own autobuilders. The reproducible-builds logs are available here:

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

and I've just put my build logs here:

https://people.debian.org/~sanvila/build-logs/neutron/

(I'm still using eatmydata, since you said you use it yourself and
it's supposed to work).

Please take a look at this. Just saying "it works for me" does not help.
While we are at it, I have yet to see how this is not serious, being a
FTBFS bug in a supported architecture, but I will be happy to skip the
discussion about the severity as far as you are really willing to
solve the problem.

If you still need a machine to reproduce this, please contact me privately.

Thanks.

Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]

[Adam Borowski]

On Sat, Jan 19, 2019 at 07:47:51AM +0800, Paul Wise wrote:
> On Fri, Jan 18, 2019 at 11:51 PM Adam Borowski wrote:
> 
> > I'm not entirely sure if enabling javascript is such a hot idea in a
> > codebase that hardly sees maintenance these days.  But it's up to you...
> 
> Personally I think the users of terminal-based web browsers would be
> very surprised and possibly upset that their browser suddenly supports
> JavaScript. At minimum, I would suggest a NEWS.Debian entry about
> this. The most ideal situation would be to leave it off by default but
> have a command-line option to turn it on.

I wouldn't be _this_ negative, but only if the defaults are reasonable (ie,
javascript only from the first-party site, akin to Firefox with uMatrix in
its default configuration).  I don't know how good this implementation of
Javascript is in practice -- previous attempt sucked -- but quite a large
part of sites rely on that abomination to display meaningful contents.

Thus, it might work adequately, only testing can show.  It's up to Ahmed to
decide -- this kind of decisions are what we have maintainers for (before
users start spamming complaints :p).

My remark was mostly about a project dormant for years -- or, with the fork,
not established enough to be trusted for security matters -- not being able
to provide reasonable support for something that's a notorious attack
surface.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Bug#919740: lintian: description-too-long text "must not exceed 80 characters" is incorrect

[Mike Miller]

Package: lintian
Version: 2.5.121
Severity: minor

Dear Maintainer,

The tag `description-too-long` says

The first line of the "Description:" must not exceed 80 characters.

which, at least to me, says that exactly 80 characters is allowed. But
the actual section in Policy says that the line must be strictly less
than 80, and the actual lintian check agrees with Policy.

Changing the tag text to

The first line of the "Description:" must be less than 80 characters.

makes this much clearer and correct.

I will submit a MR on salsa once I have a bug number.


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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-1
ii  patchutils 0.3.4-2
ii  perl   5.28.1-3
ii  t1utils1.41-3
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.53-1

-- no debconf information

Bug#919739: dicomscope FTBFS error: 'class DVInterface' has no member named 'getTargetCipherSuite'; did you mean 'getTargetTimeout'?

[peter green]

Package: dicomscope
Version: 3.6.0-19
Severity: serious

dicomscope FTBFS in sid, I presume this is the result of the dcmtk transition 
but I am not 100% positive.


/<>/interface/libsrc/DVInterface.cpp: In function '_jstring* 
Java_J2Ci_jDVInterface_getTargetCipherSuite(JNIEnv*, jobject, jstring, jint)':
/<>/interface/libsrc/DVInterface.cpp:3232:28: error: 'class 
DVInterface' has no member named 'getTargetCipherSuite'; did you mean 'getTargetTimeout'?

Bug#919638: solr-tomcat: Permission problems after update to tomcat9

[Emmanuel Bourg]

Hi Michael,

Le 18/01/2019 à 07:19, Michael Welsh Duggan a écrit :

> I have no idea why it fails to write the lock file.

It probably happens because tomcat9 is sandboxed to write only into its
own directory. You'll have to tweak the systemd configuration to allow
Tomcat to write into the solr directory (with the ReadWritePaths directive).

The solr-tomcat package is rather old now, I'm tempted to remove it.
Upstream has moved away from supporting deployments as a web
application, Solr now embeds it own web server (Jetty). We wouldn't have
this kind of issue with the latest versions.

Emmanuel Bourg

Bug#913978: is not accessible with Orca screenreader

[Jeremy Bicha]

On Fri, Jan 18, 2019 at 6:48 PM Mika Hanhijärvi  wrote:
> Thanks a lot. When this bug is fixed I hope it will be fixed also in
> Gnome 3.30, not just in Gnome 3.32 so that Debian Buster will also have
> the fix. It looks like Debian 10 "Buster" will be released with Gnome
> 3.30, I ofcourse may be wrong. I am usin Debian stable releases on
> desktop and laptop so I will upgrade all my computers to Debian Buster
> when it is released sometime in the next summer. And after that the next
> time I will upgrade is when Debian 11 will be released sometime in 2021...

Yes, if possible, we'd like to backport the fix to Debian 10. Feel
free to ping the Debian GNOME or Debian Accessibility teams once this
bug has been fixed in GNOME.

I did fix some smaller accessibility issues in gnome-control-center.
1:3.30.2-3 which landed in Buster this week.

Here's a workaround for you mentioned on the GNOME bug:
You can navigate from the sidebar to the main content by pressing the
right arrow twice. To get back to the sidebar, you can start a search
with Ctrl+F, type something, then hit Esc to cancel the search. Now
you can use your up and down arrow keys to navigate the sidebar. It is
not possible to select search results with the keyboard.

Thanks,
Jeremy Bicha

Bug#919738: asterisk-flite: FTBFS (Externally compiled modules must declare AST_MODULE_SELF_SYM)

[Santiago Vila]

Package: src:asterisk-flite
Version: 3.0-2
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules binary-arch
test -x debian/rules
dh_testroot
dh_prep 
dh_installdirs -A 
mkdir -p "."
/usr/bin/make -C . CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -pipe -fPIC -Wall 
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -D_REENTRANT 
-D_GNU_SOURCE" CXXFLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security" 
CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" 
make[1]: Entering directory '/<>'
awk: cannot open /etc/asterisk/asterisk.conf (No such file or directory)
gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -pipe -fPIC -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wmissing-declarations -D_REENTRANT -D_GNU_SOURCE -g -O2 
-c -o app_flite.o app_flite.c
In file included from app_flite.c:34:
/usr/include/asterisk.h:232:2: error: #error "Externally compiled modules must 
declare AST_MODULE_SELF_SYM."
 #error "Externally compiled modules must declare AST_MODULE_SELF_SYM."
  ^
In file included from app_flite.c:43:
app_flite.c: In function 'load_module':
app_flite.c:283:9: error: 'AST_MODULE_SELF' undeclared (first use in this 
function); did you mean 'AST_MODULE_INFO'?
  return ast_register_application(app, flite_exec, synopsis, descrip) ?
 ^~~~
app_flite.c:283:9: note: each undeclared identifier is reported only once for 
each function it appears in
app_flite.c:285:1: warning: control reaches end of non-void function 
[-Wreturn-type]
 }
 ^
make[1]: *** [Makefile:36: app_flite.o] Error 1
make[1]: Leaving directory '/<>'
make: *** [/usr/share/cdbs/1/class/makefile.mk:77: debian/stamp-makefile-build] 
Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/asterisk-flite.html

where you can get a full build log if you need it.

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#919637: RFS: elinks/0.13~20190114-1 [ITA]

[Paul Wise]

On Fri, Jan 18, 2019 at 11:51 PM Adam Borowski wrote:

> I'm not entirely sure if enabling javascript is such a hot idea in a
> codebase that hardly sees maintenance these days.  But it's up to you...

Personally I think the users of terminal-based web browsers would be
very surprised and possibly upset that their browser suddenly supports
JavaScript. At minimum, I would suggest a NEWS.Debian entry about
this. The most ideal situation would be to leave it off by default but
have a command-line option to turn it on.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#913978: is not accessible with Orca screenreader

[Mika Hanhijärvi]

Hi


Thanks a lot. When this bug is fixed I hope it will be fixed also in 
Gnome 3.30, not just in Gnome 3.32 so that Debian Buster will also have 
the fix. It looks like Debian 10 "Buster" will be released with Gnome 
3.30, I ofcourse may be wrong. I am usin Debian stable releases on 
desktop and laptop so I will upgrade all my computers to Debian Buster 
when it is released sometime in the next summer. And after that the next 
time I will upgrade is when Debian 11 will be released sometime in 2021...



On 1/1/19 1:05 AM, Jeremy Bicha wrote:

Control: forwarded -1
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/327

On Sat, Nov 17, 2018 at 4:03 PM Mika Hanhijärvi  wrote:

This is wery severe unacceptable problem. This bug makes Gnome 3.30 unusable
for the visually impaired users because you can not access or change the
desktop settings.

Thank you for taking the time to report this bug.

I agree that the GNOME Settings app has many accessible problems for
navigating with only a keyboard and screen reader.

I opened a bug now for the most critical issue. When that's fixed, you
should be able to navigate most of the Settings app, although there
are some elements that are not read and the context may be unclear.

Thanks,
Jeremy Bicha

Bug#919736: tj3: FTBFS (failing tests)

[Santiago Vila]

Package: src:tj3
Version: 3.6.0-5
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=ruby --with ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
dh_ruby --build
   dh_ruby --build
localehelper LANG=en_US.UTF-8 rake manual
mkdir -p manual/html
rake vim
rake help2man 
mkdir -p man
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
rake spec
/usr/bin/ruby2.5 /usr/bin/rspec --pattern spec/\*_spec.rb
Run options: exclude {:ruby=>#}
..F.F...

Failures:

  1) TaskJuggler::StatusSheetTest TaskJuggler::StatusSheetSender should have 
matching status sheets in body and attachment
 Failure/Error: bodySheet.should == attachedSheet

   expected: "statussheet boss 2011-03-16-00:00-+ - 
2011-03-23-00:00-+ {\r\n\r\n  # Task: T1\r\n  task t1 ...   #   # Work: 
100%Remaining: 5.0d (10.0d) \r\n#   author r2\r\n# }\r\n  
}\r\n\r\n}\r\n"
got: "statussheet boss 2011-03-16-00:00-+ - 
2011-03-23-00:00-+ {\n\n  # Task: T1\n  task t1 {\n   ...:00-+\n#   
# Work: 100%Remaining: 5.0d (10.0d) \n#   author r2\n# }\n  
}\n\n}\n" (using ==)
 # ./spec/StatusSheets_spec.rb:234:in `block (4 levels) in 
'
 # ./spec/StatusSheets_spec.rb:231:in `each'
 # ./spec/StatusSheets_spec.rb:231:in `block (3 levels) in 
'

  2) TaskJuggler::TimeSheets TaskJuggler::TimeSheetSender should have matching 
timesheets in body and attachment
 Failure/Error: bodySheet.should == attachedSheet

   expected: "timesheet r1 2011-03-14-00:00-+ - 2011-03-21-00:00-+ 
{\r\n\r\n  # Vacation time: 0.0%\r\n\r\...details\r\n  #   ->8-\r\n  # 
}\r\n\r\n  # You have no future assignments for this project!\r\n}\r\n"
got: "timesheet r1 2011-03-14-00:00-+ - 2011-03-21-00:00-+ 
{\n\n  # Vacation time: 0.0%\n\n  # Tas...  Some more details\n  #   ->8-\n  # 
}\n\n  # You have no future assignments for this project!\n}\n" (using ==)
 # ./spec/TimeSheets_spec.rb:220:in `block (4 levels) in 
'
 # ./spec/TimeSheets_spec.rb:217:in `each'
 # ./spec/TimeSheets_spec.rb:217:in `block (3 levels) in 
'

Finished in 24.83 seconds (files took 0.84252 seconds to load)
68 examples, 2 failures

Failed examples:

rspec ./spec/StatusSheets_spec.rb:230 # TaskJuggler::StatusSheetTest 
TaskJuggler::StatusSheetSender should have matching status sheets in body and 
attachment
rspec ./spec/TimeSheets_spec.rb:216 # TaskJuggler::TimeSheets 
TaskJuggler::TimeSheetSender should have matching timesheets in body and 
attachment

/usr/bin/ruby2.5 /usr/bin/rspec --pattern spec/\*_spec.rb failed
make[1]: *** [debian/rules:18: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

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

where you can get a full build log if you need it.

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#919728: beast2-mcmc: FTBFS (cannot find symbol jam.mac.Utils.macOSXRegistration)

[Santiago Vila]

Package: src:beast2-mcmc
Version: 2.5.1+dfsg-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 --with javahelper
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
   jh_linkjars -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/beast2-mcmc-2.5.1+dfsg'
# move tests requiring fest.swing out of the way
mv src/test/beast/app/beauti debian/fest_swing_tests
dh_auto_build
ant -Duser.name debian
Buildfile: /<>/beast2-mcmc-2.5.1+dfsg/build.xml

clean:

init:
 [echo] BUILD_BEAST_2: /<>/beast2-mcmc-2.5.1+dfsg/build.xml

compile-all:
 [echo] Building BEAST 2
[mkdir] Created dir: /<>/beast2-mcmc-2.5.1+dfsg/build
[javac] Compiling 475 source files to 
/<>/beast2-mcmc-2.5.1+dfsg/build
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 8
[javac] 
/<>/beast2-mcmc-2.5.1+dfsg/src/beast/app/beauti/Beauti.java:1274: 
error: cannot find symbol
[javac] 
jam.mac.Utils.macOSXRegistration(application);
[javac]  ^
[javac]   symbol:   method macOSXRegistration(Application)
[javac]   location: class Utils
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
[javac] 1 warning

BUILD FAILED
/<>/beast2-mcmc-2.5.1+dfsg/build.xml:77: Compile failed; see the 
compiler error output for details.

Total time: 38 seconds
dh_auto_build: ant -Duser.name debian returned exit code 1
make[1]: *** [debian/rules:32: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>/beast2-mcmc-2.5.1+dfsg'
make: *** [debian/rules:23: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/beast2-mcmc.html

where you can get a full build log if you need it.

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#919730: lemonldap-ng: FTBFS (failing tests)

[Santiago Vila]

Package: src:lemonldap-ng
Version: 2.0.1+ds-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 --with systemd
   dh_update_autotools_config -i
   dh_autoreconf -i
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/lemonldap-ng-2.0.1+ds'
/usr/bin/make configure STORAGECONFFILE=/etc/lemonldap-ng/lemonldap-ng.ini \
PERLOPTIONS="INSTALLDIRS=vendor"
make[2]: Entering directory '/<>/lemonldap-ng-2.0.1+ds'
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Lemonldap::NG::Common
Writing MYMETA.yml and MYMETA.json

[... snipped ...]

make[2]: Entering directory 
'/<>/lemonldap-ng-2.0.1+ds/lemonldap-ng-common'
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" 
"-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" 
t/*.t
t/01-Common-Conf.t . ok

#   Failed test 'File is  encoded'
#   at t/02-Common-Conf-File.t line 51.
Result: t/lmConf-1.json: JSON data


#   Failed test 'File is  encoded'
#   at t/02-Common-Conf-File.t line 51.
Result: t/lmConf-1.json: JSON data


#   Failed test 'File is  encoded'
#   at t/02-Common-Conf-File.t line 51.
Result: t/lmConf-1.json: JSON data

# Looks like you failed 3 tests of 14.
t/02-Common-Conf-File.t  
Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/14 subtests 
t/03-Common-Conf-CDBI.t  ok
t/03-Common-Conf-RDBI.t  ok
t/05-Common-Conf-LDAP.t  ok
t/30-Common-Safelib.t .. ok
t/35-Common-Crypto.t ... ok
t/36-Common-Regexp.t ... ok
t/40-Common-Session.t .. ok
t/50-Combination-Parser.t .. ok
t/99-pod.t . ok

Test Summary Report
---
t/02-Common-Conf-File.t  (Wstat: 768 Tests: 14 Failed: 3)
  Failed tests:  4, 8, 12
  Non-zero exit status: 3
Files=11, Tests=191,  3 wallclock secs ( 0.11 usr  0.04 sys +  2.55 cusr  0.45 
csys =  3.15 CPU)
Result: FAIL
Failed 1/11 test programs. 3/191 subtests failed.
make[2]: *** [Makefile:973: test_dynamic] Error 255
make[2]: Leaving directory 
'/<>/lemonldap-ng-2.0.1+ds/lemonldap-ng-common'
make[1]: *** [Makefile:361: common_test] Error 2
make[1]: Leaving directory '/<>/lemonldap-ng-2.0.1+ds'
dh_auto_test: make -j1 test returned exit code 2
make: *** [debian/rules:20: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/lemonldap-ng.html

where you can get a full build log if you need it.

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#919734: node-yauzl: FTBFS (TypeError: FdSlicer is not a constructor)

[Santiago Vila]

Package: src:node-yauzl
Version: 2.1.0-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
dh: Compatibility levels before 9 are deprecated (level 8 in use)
   dh_update_autotools_config -i
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
nodejs test/test.js
/<>/index.js:44
var fdSlicer = new FdSlicer(fd, {autoClose: true});
   ^

TypeError: FdSlicer is not a constructor
at /<>/index.js:44:20
at FSReqWrap.oncomplete (fs.js:153:5)
make[1]: *** [debian/rules:11: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

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

where you can get a full build log if you need it.

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#919725: [pkg-cryptsetup-devel] Bug#919725: cryptsetup: switch to LUKS2 by default for new installs

[Christoph Anton Mitterer]

On Fri, 2019-01-18 at 15:01 -0800, Matt Taggart wrote:
> Is it ready to become the default for new installs yet?

Being not much more than just a user of it and regularly following the
upstream mailing list… I'd rather suggest to be conservative in that
matter.

AEAD is still marked as experimental by upstream and while there are
other reasons to use LUKS2 (which could be quite stable already) it's
crypto what were talking about:
security is the upmost goal (which is also why most other writers and
myself seemed rather concerned about Debian's intention to default to
TRIM enabled in dm-crypt). 

A good thing, which makes it IMO also less pressing to switch to LUKS2
is, that LUKS1 can be in-place-converted to LUKS2 in most cases.
So users can most of the time switch later, without having to rewrite
everything.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#919733: libretro-desmume: Newer versions have worse performance

[Jeremy Bicha]

Source: libretro-desmume
X-Debbugs-CC: exalm7...@gmail.com

I was told that libretro-desmume has been rebased in newer versions.
The new version has worse performance. The old version has been forked
as libretro-desmume2015. So I'm filing this bug to let you know that
it will be a bit more annoying to users if you upload a newer version.

Thanks,
Jeremy Bicha

Bug#919732: node-es6-shim: FTBFS (ERROR: cannot write source map to STDOUT)

[Santiago Vila]

Package: src:node-es6-shim
Version: 0.35.4+ds-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
   dh_update_autotools_config -i
   dh_autoreconf -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/node-es6-shim-0.35.4+ds'
uglifyjs --support-ie8 --keep-fnames --comments -m -b 
ascii_only=true,beautify=false es6-shim.js --source-map=es6-shim.map > 
es6-shim.min.js
ERROR: cannot write source map to STDOUT
make[1]: *** [debian/rules:9: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>/node-es6-shim-0.35.4+ds'
make: *** [debian/rules:6: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

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

where you can get a full build log if you need it.

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#919737: underscore: FTBFS (ERROR: `underscore.min.map` is not a supported option)

[Santiago Vila]

Package: src:underscore
Version: 1.8.3~dfsg-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
test -x debian/rules
mkdir -p "."

Scanning upstream source for new/changed copyright notices...

set -e; LC_ALL=C.UTF-8 /usr/bin/licensecheck --check '.*' --recursive 
--copyright --deb-fmt --ignore 
'^(debian/(changelog|copyright(|_hints|_newhints)))$' --lines 0 * | 
/usr/lib/cdbs/licensecheck2dep5 > debian/copyright_newhints
9 combinations of copyright and licensing found.
WARNING:New or changed notices discovered:

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Copyright: NONE
Copyright: 2009-2015, Jeremy Ashkenas, DocumentCloud and Investigative
Files: docs/images/background.png
Copyright: 
…R…W…r…g…2…n…0f…X[E…p…O…8…y$)…F…d…X…1=…-…l-…r…n…
  …!…U…|…}…zQ…6'…N…Ij…dO…Q…C…WR…5…
  b,UE.…O…kz…~…1…kk…J….…;…%N…o…?~…"…[B…T…hd.
  e…"n|…|…4…/…9pwb…"…
  …w`…u…j…r…mt"…!…6(…v
License: UNKNOWN
 FIXME

Files: underscore.js
Copyright: 2009-2015, Jeremy Ashkenas, DocumentCloud and Investigative 
Reporters & Editors
License: UNKNOWN
 FIXME

Copyright: 2009-.
Files: docs/images/underscore.png
Copyright: …PA?2…J…P…{…   
…$…}c…6)…=…R<…,q……e…|…%z…J…1…Zf…1…G…D…
  …4…2…X=…J;U…Q…9…U6…K:…"-*…"…ch…

To fix the situation please do the following:
  1) Examine debian/copyright_* and referenced files
  2) Update debian/copyright as needed
  3) Replace debian/copyright_hints with debian/copyright_newhints
touch debian/stamp-copyright-check
touch debian/stamp-upstream-cruft
uglifyjs --source-map underscore.min.map -o underscore.min.js underscore.js
Supported options:
  content null
  filenamenull
  includeSources  false
  rootnull
  url null
ERROR: `underscore.min.map` is not a supported option
at DefaultsError.get (eval at  
(/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :71:23)
at fatal (/usr/lib/nodejs/uglify-js/bin/uglifyjs:291:53)
at run (/usr/lib/nodejs/uglify-js/bin/uglifyjs:235:9)
at Object. (/usr/lib/nodejs/uglify-js/bin/uglifyjs:160:5)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Function.Module.runMain (module.js:693:10)
make: *** [debian/rules:35: underscore.min.js] Error 1
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

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

where you can get a full build log if you need it.

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#919735: ruby-premailer-rails: FTBFS (failing tests)

[Santiago Vila]

Package: src:ruby-premailer-rails
Version: 1.9.7-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=ruby --with ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   dh_auto_build -i -O--buildsystem=ruby
dh_ruby --build
   dh_ruby --build
   dh_auto_test -i -O--buildsystem=ruby
dh_ruby --test
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=ruby --with ruby
   dh_testroot -i -O--buildsystem=ruby
   dh_prep -i -O--buildsystem=ruby

[... snipped ...]

  when HTML contains unicode
does not mess those up
  when adapter is hpricot
#to_plain_text
  includes the text from the HTML part
#to_inline_css
  when inline CSS block present
returns the HTML with the CSS inlined
  when CSS is loaded externally
returns the HTML with the CSS inlined
  when HTML contains unicode
does not mess those up
  .new
extracts the CSS
passes on the configs
does not allow to override with_html_string

Premailer::Rails
  #config
when set
  should eq {:foo=>:bar}

Failures:

  1) Premailer::Rails::Hook when message also contains a text part does not 
replace any message part
 Failure/Error:
   expect { run_hook(message) }.to_not \
 change { message.all_parts.map(&:content_type) }

   expected `message.all_parts.map(&:content_type)` not to have changed, 
but did change from ["multipart/alternative; 
boundary=\"--==_mimepart_5c425ea927787_76ba2ab410f145c014523\"; charset=UTF-8", 
"text/html; charset=UTF-8", "text/plain; charset=UTF-8"] to 
["multipart/alternative; 
boundary=\"--==_mimepart_5c425ea927787_76ba2ab410f145c014523\"; charset=UTF-8", 
"text/plain; charset=UTF-8", "text/html; charset=UTF-8"]
 # ./spec/integration/hook_spec.rb:93:in `block (3 levels) in '

Finished in 0.79986 seconds (files took 1.43 seconds to load)
68 examples, 1 failure

Failed examples:

rspec ./spec/integration/hook_spec.rb:92 # Premailer::Rails::Hook when message 
also contains a text part does not replace any message part

Coverage report generated for RSpec to /<>/coverage. 528 / 529 LOC 
(99.81%) covered.
/usr/bin/ruby2.5 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb --format 
documentation failed
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-premailer-rails 
returned exit code 1
make[1]: *** [debian/rules:12: override_dh_auto_install] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

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

where you can get a full build log if you need it.

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#919731: libpoe-component-client-mpd-perl: FTBFS (Can't locate object method "format" via package "Audio::MPD::Common::Item::Song")

[Santiago Vila]

Package: src:libpoe-component-client-mpd-perl
Version: 2.001-2
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
perl Build.PL --installdirs vendor --config "optimize=-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config 
"ld=x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'POE-Component-Client-MPD' version '2.001'
   dh_auto_build -i
perl Build
Building POE-Component-Client-MPD
   dh_auto_test -i
perl Build test --verbose 1
t/00-compile.t ... 

[... snipped ...]

ok 5 - all_artists() return the artists
ok 6
ok 7 - command 'coll.all_titles' returned an ok status
ok 8 - all_titles() return the titles
ok 9
ok 10 - command 'coll.all_files' returned an ok status
ok 11 - all_files() return the pathes
ok 12 - all_files() return strings
ok
Can't locate object method "format" via package 
"Audio::MPD::Common::Item::Song" at 
/<>/blib/lib/POE/Component/Client/MPD/Connection.pm line 232.
# No tests run!
t/62-coll-pick.t . 
1..9
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 9/9 subtests 
Can't locate object method "format" via package 
"Audio::MPD::Common::Item::Song" at 
/<>/blib/lib/POE/Component/Client/MPD/Connection.pm line 232.
# Looks like you planned 38 tests but ran 3.
t/63-coll-relations.t  
1..38
ok 1 - command 'coll.albums_by_artist' returned an ok status
ok 2 - albums_by_artist() return the album
ok 3 - albums_by_artist() return plain strings
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 35/38 subtests 
t/author-pod-coverage.t .. skipped: these tests are for testing by the author
t/author-pod-syntax.t  skipped: these tests are for testing by the author

Test Summary Report
---
t/23-conn-dialog.t (Wstat: 65280 Tests: 9 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 34 tests but ran 9.
t/60-coll-retrieve.t   (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 35 tests but ran 0.
t/62-coll-pick.t   (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 9 tests but ran 0.
t/63-coll-relations.t  (Wstat: 65280 Tests: 3 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 38 tests but ran 3.
Files=21, Tests=260, 98 wallclock secs ( 0.17 usr  0.09 sys + 43.59 cusr  4.31 
csys = 48.16 CPU)
Result: FAIL
Failed 4/21 test programs. 0/260 subtests failed.
dh_auto_test: perl Build test --verbose 1 returned exit code 255
make: *** [debian/rules:7: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libpoe-component-client-mpd-perl.html

where you can get a full build log if you need it.

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#919729: carrotsearch-hppc: FTBFS (Could not resolve dependencies for project com.carrotsearch:hppc-template-processor:maven-plugin:0.7.2)

[Santiago Vila]

Package: src:carrotsearch-hppc
Version: 0.7.2-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
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
mh_patchpoms -plibcarrotsearch-hppc-java --debian-build 
--keep-pom-version --maven-repo=/<>/debian/maven-repo
   dh_auto_build -i
/usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/<> 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/<>/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
-Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package 
-DskipTests -Dnotimestamp=true -Dlocale=en_US
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
com.google.inject.internal.cglib.core.$ReflectUtils$1 
(file:/usr/share/maven/lib/guice.jar) to method 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of 
com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
[INFO] Scanning for projects...
[WARNING] The project com.carrotsearch:hppc-parent:pom:0.7.2 uses prerequisites 
which is only intended for maven-plugin projects but not for non maven-plugin 
projects. For such purposes you should use the maven-enforcer-plugin. See 
https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] HPPC (parent POM)  [pom]
[INFO] HPPC Template Processor   [maven-plugin]
[INFO] HPPC Collections[bundle]
[INFO] 
[INFO] < com.carrotsearch:hppc-parent >
[INFO] Building HPPC (parent POM) 0.7.2   [1/3]
[INFO] [ pom ]-
[INFO] 
[INFO] --< com.carrotsearch:hppc-template-processor >--
[INFO] Building HPPC Template Processor 0.7.2 [2/3]
[INFO] [ maven-plugin ]
[WARNING] The POM for com.ibm.icu:icu4j:jar:debian is missing, no dependency 
information available
[INFO] 
[INFO] Reactor Summary for HPPC (parent POM) 0.7.2:
[INFO] 
[INFO] HPPC (parent POM) .. SUCCESS [  0.007 s]
[INFO] HPPC Template Processor  FAILURE [  0.415 s]
[INFO] HPPC Collections ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  4.096 s
[INFO] Finished at: 2019-01-18T23:11:57Z
[INFO] 
[ERROR] Failed to execute goal on project hppc-template-processor: Could not 
resolve dependencies for project 
com.carrotsearch:hppc-template-processor:maven-plugin:0.7.2: Cannot access 
central (https://repo.maven.apache.org/maven2) in offline mode and the artifact 
com.ibm.icu:icu4j:jar:debian has not been downloaded from it before. -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :hppc-template-processor
dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/<> 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/<>/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
-Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package 
-DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1
make: *** [debian/rules:4: 

Bug#919356: [PATCH] Add missing licensing info

[Arnaldo Carvalho de Melo]

Em Fri, Jan 18, 2019 at 08:02:40PM +0100, Domenico Andreoli escreveu:
> On Fri, Jan 18, 2019 at 03:44:27PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Jan 18, 2019 at 03:41:33PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Jan 18, 2019 at 03:28:33PM -0300, Arnaldo Carvalho de Melo 
> > > escreveu:
> > > > Em Fri, Jan 18, 2019 at 06:24:52PM +, Martin Lau escreveu:
> > > > > No concern on adding the SPDX notation.
> > > > > I would like to add my employer to a few btf files:
> > 
> > > > > + Copyright (c) 2018 Facebook
> > 
> > > > Sure, I'll add a patch, authored by you, with a signed-off-by you, etc,
> > > > CC the group and signed by me as well, just like the kernel process. On
> > > > top of Domenico's patch.
> > > 
> > > Now I noticed that the patch adds Copyright entries as well, so I'm
> > > fixing it up, as libbtf.[ch] I haven't authored, and btf_encoder.[ch]
> > > where authored by Facebook engineers based on ctf_encoder.[ch] that I'm
> > > the author, so I'm just fixing these things up in Martin's follow up
> > > patch.
> > 
> > End result, ok?
> 
> yes, thanks!
> 
> > 
> > commit 1610b9b4327d14589800606fc4d31229eb8f1daf
> > Author: Martin Lau 
> > Date:   Fri Jan 18 15:42:37 2019 -0300
> > 
> > Fixup copyright notices for BTF files authored by Facebook engineers
> > 
> > Cc: Andrii Nakryiko 
> > Cc: Domenico Andreoli 
> > Cc: Yonghong Song 
> > Signed-off-by: Martin Lau 
> > Signed-off-by: Arnaldo Carvalho de Melo 
> 
> could please add also mine?
> 
> Signed-off-by: Domenico Andreoli 

Sure!
 
> > 
> > diff --git a/btf_encoder.c b/btf_encoder.c
> > index 613e7e9a6d43..7aed9b454c1f 100644
> > --- a/btf_encoder.c
> > +++ b/btf_encoder.c
> > @@ -1,7 +1,12 @@
> >  /*
> >SPDX-License-Identifier: GPL-2.0-only
> >  
> > -  Copyright (C) 2019 Arnaldo Carvalho de Melo 
> > +  Copyright (C) 2019 Facebook
> > +
> > +  Derived from ctf_encoder.c, which is:
> > +
> > +  Copyright (C) Arnaldo Carvalho de Melo 
> > +  Copyright (C) Red Hat Inc
> >   */
> >  
> >  #include "dwarves.h"
> > diff --git a/btf_encoder.h b/btf_encoder.h
> > index daf5d372986a..80237bb4ca61 100644
> > --- a/btf_encoder.h
> > +++ b/btf_encoder.h
> > @@ -3,7 +3,10 @@
> >  /*
> >SPDX-License-Identifier: GPL-2.0-only
> >  
> > -  Copyright (C) 2019 Arnaldo Carvalho de Melo 
> > +  Copyright (C) 2019 Facebook
> > +
> > +  Derived from ctf_encoder.h, which is:
> > +  Copyright (C) Arnaldo Carvalho de Melo 
> >   */
> >  
> >  struct cu;
> > diff --git a/libbtf.c b/libbtf.c
> > index 64437f3bd2d9..c6ece9d84de5 100644
> > --- a/libbtf.c
> > +++ b/libbtf.c
> > @@ -1,7 +1,7 @@
> >  /*
> >SPDX-License-Identifier: GPL-2.0-only
> >  
> > -  Copyright (C) 2019 Arnaldo Carvalho de Melo 
> > +  Copyright (C) 2019 Facebook
> >   */
> >  
> >  #include 
> > diff --git a/libbtf.h b/libbtf.h
> > index ef1c49804a20..780f3ec888d7 100644
> > --- a/libbtf.h
> > +++ b/libbtf.h
> > @@ -1,7 +1,7 @@
> >  /*
> >SPDX-License-Identifier: GPL-2.0-only
> >  
> > -  Copyright (C) 2019 Arnaldo Carvalho de Melo 
> > +  Copyright (C) 2019 Facebook
> >   */
> >  
> >  #ifndef _LIBBTF_H
> 
> -- 
> 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13

-- 

- Arnaldo

Bug#919356: [PATCH] Add missing licensing info

[Arnaldo Carvalho de Melo]

Em Fri, Jan 18, 2019 at 06:54:41PM +, Martin Lau escreveu:
> On Fri, Jan 18, 2019 at 03:44:27PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Jan 18, 2019 at 03:41:33PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Jan 18, 2019 at 03:28:33PM -0300, Arnaldo Carvalho de Melo 
> > > escreveu:
> > > > Em Fri, Jan 18, 2019 at 06:24:52PM +, Martin Lau escreveu:
> > > > > No concern on adding the SPDX notation.
> > > > > I would like to add my employer to a few btf files:
> > 
> > > > > + Copyright (c) 2018 Facebook
> > 
> > > > Sure, I'll add a patch, authored by you, with a signed-off-by you, etc,
> > > > CC the group and signed by me as well, just like the kernel process. On
> > > > top of Domenico's patch.
> > > 
> > > Now I noticed that the patch adds Copyright entries as well, so I'm
> > > fixing it up, as libbtf.[ch] I haven't authored, and btf_encoder.[ch]
> > > where authored by Facebook engineers based on ctf_encoder.[ch] that I'm
> > > the author, so I'm just fixing these things up in Martin's follow up
> > > patch.
> > 
> > End result, ok?
> Perfect!

:-)
 
> 
> > 
> > commit 1610b9b4327d14589800606fc4d31229eb8f1daf
> > Author: Martin Lau 
> > Date:   Fri Jan 18 15:42:37 2019 -0300
> > 
> > Fixup copyright notices for BTF files authored by Facebook engineers
> > 
> > Cc: Andrii Nakryiko 
> > Cc: Domenico Andreoli 
> > Cc: Yonghong Song 
> > Signed-off-by: Martin Lau 
> > Signed-off-by: Arnaldo Carvalho de Melo 
> > 
> > diff --git a/btf_encoder.c b/btf_encoder.c
> > index 613e7e9a6d43..7aed9b454c1f 100644
> > --- a/btf_encoder.c
> > +++ b/btf_encoder.c
> > @@ -1,7 +1,12 @@
> >  /*
> >SPDX-License-Identifier: GPL-2.0-only
> >  
> > -  Copyright (C) 2019 Arnaldo Carvalho de Melo 
> > +  Copyright (C) 2019 Facebook
> > +
> > +  Derived from ctf_encoder.c, which is:
> > +
> > +  Copyright (C) Arnaldo Carvalho de Melo 
> > +  Copyright (C) Red Hat Inc
> >   */
> >  
> >  #include "dwarves.h"
> > diff --git a/btf_encoder.h b/btf_encoder.h
> > index daf5d372986a..80237bb4ca61 100644
> > --- a/btf_encoder.h
> > +++ b/btf_encoder.h
> > @@ -3,7 +3,10 @@
> >  /*
> >SPDX-License-Identifier: GPL-2.0-only
> >  
> > -  Copyright (C) 2019 Arnaldo Carvalho de Melo 
> > +  Copyright (C) 2019 Facebook
> > +
> > +  Derived from ctf_encoder.h, which is:
> > +  Copyright (C) Arnaldo Carvalho de Melo 
> >   */
> >  
> >  struct cu;
> > diff --git a/libbtf.c b/libbtf.c
> > index 64437f3bd2d9..c6ece9d84de5 100644
> > --- a/libbtf.c
> > +++ b/libbtf.c
> > @@ -1,7 +1,7 @@
> >  /*
> >SPDX-License-Identifier: GPL-2.0-only
> >  
> > -  Copyright (C) 2019 Arnaldo Carvalho de Melo 
> > +  Copyright (C) 2019 Facebook
> >   */
> >  
> >  #include 
> > diff --git a/libbtf.h b/libbtf.h
> > index ef1c49804a20..780f3ec888d7 100644
> > --- a/libbtf.h
> > +++ b/libbtf.h
> > @@ -1,7 +1,7 @@
> >  /*
> >SPDX-License-Identifier: GPL-2.0-only
> >  
> > -  Copyright (C) 2019 Arnaldo Carvalho de Melo 
> > +  Copyright (C) 2019 Facebook
> >   */
> >  
> >  #ifndef _LIBBTF_H

-- 

- Arnaldo

Bug#919725: [pkg-cryptsetup-devel] Bug#919725: cryptsetup: switch to LUKS2 by default for new installs

[Guilhem Moulin]

Hi Matt,

On Fri, 18 Jan 2019 at 15:01:59 -0800, Matt Taggart wrote:
> There was some discussion on the debian-boot list during the
> libcryptsetup transition about the format
> 
> https://lists.debian.org/debian-boot/2017/12/msg00231.html
> 
> including a comment,
> 
> "feel free to poke us again for partman-crypto when the new format
> looks mature enough so that we see about adding support for it."

Please see 
https://salsa.debian.org/installer-team/partman-crypto/merge_requests/1
and this thread https://www.saout.de/pipermail/dm-crypt/2018-July/005925.html .

We'd much prefer if the d-i default LUKS format was identical to the
cryptsetup(8) binary here, and we'd rather avoid a Debian-specific patch
to change the LUKS format version in the binary.  At least not without
upstream's blessing; the above thread indicates a few subtle — now fixed —
issues with libblkid for instance, so we should really be careful here).

Upstream is aware of the upcoming freeze, and AFAIK the plan is still to
release 2.1, defaulting to LUKS2, in time for Buster.  I actually
planned to bump the thread shortly before FOSDEM :-)  (Should we miss
the deadline, we'll consider a Debian-specific patch in src:cryptsetup
and ask for upstream's opinion.) 

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#889580: spectre-meltdown-checker: minor manpage issue due to show_header()

[Holger Levsen]

control: notfound -1 0.40-1
control: tag -1 unreproducible

Hi tony,

on stretch, I installed spectre-meltdown-checker (0.40-1~bpo9+1), then started
an xterm and ran 'man spectre-meltdown-checker' and the manpage looked fine to
me.

Can you confirm?


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

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

[Cyril Brulebois]

Hello Chris,

First off: Thanks a lot for your work, and for your patience.

Chris Lamb  (2019-01-12):
> I would dearly love to have reproducible installer images for buster
> and indeed this would be a good thing to provide and offer, let alone
> announce in the release notes, etc.
> 
> Now that mtools has been sorted out, could this bug & corresponding
> merge request get a closer look? Thanks in advance.

There's a new alpha coming up and I've just spent some time cleaning up
things in debian-installer.git (debhelper compat, standards-version,
etc.) right after the upload; I've almost merged your patch series as
is, but I'd like to raise a few points first. I'm fine with amending the
patches myself, just wanted to check with you first…

 * 0c19a29645a6a3136f3a51da5d5cf1cfcec5fdfb mentions file system
   ordering only, but that's just the sort part AFAIUI; you're also
   resetting some timestamps with the find | xargs touch loop aren't
   you? I'd be happy to see this documented in the commit message as
   well.
   [ basically the clamp_mtimes function in build/Makefile in later
 commits. ]

 * 71391967763708055a65ed68999db8f4ea6fc6e6 sets “deb1” as the FAT
   volume ID; have you checked with people like debian-cd@ whether
   another constant might make more sense? (cc-edd)
   [ also: “determinstic” in commit message. ]
   [ post-scriptum: ok, now I see we already had that in place
 elsewhere; keeping the cc anyway. ]

 * 7c533fa721c3ae89ca81d1336b5928a80ed0d531 thanks for the clarity, much
   appreciated.
   [ also: “becuase” in commit message. ]

 * c35b8688696b1b4563a45d0feeabc3a0c0f2eccb “determinstic” in commit
   message.

 * ea1a896181daa3b82c5a62ae31839b457a0dbe0b modifies BUILD_DATE, adding
   a few characters (“:SS”); that ends up in various help screens
   (hopefully not an issue) but also on some files: version.info,
   disk.lbl, etc.

   Also, coming to think about BUILD_DATE, it's defined with ?= in
   build/config/common but we also set it from debian/rules… I guess
   I'll have to check what happens.

 * f181b4fe90b9030f515c7e6129239b96131b3926 oh more en_GB, yay.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#919727: cmtk FTBFS in unstable, presumablly due to the new dcmtk

[peter green]

Package: cmtk
Version: 3.3.1-1.2
Severity: serious

cmtk FTBFS in sid. Preusmablly this is caused by the new dcmtk

https://buildd.debian.org/status/fetch.php?pkg=cmtk=amd64=3.3.1-1.2%2Bb2=1547410724=0


/<>/apps/dcm2image.cxx: In function 'void AddPatternToMap(std::map >&, const char*)':
/<>/apps/dcm2image.cxx:85:17: error: 'class 
GlobalDcmDataDictionary' has no member named 'unlock'; did you mean 'rdlock'?
  dcmDataDict.unlock();
  ^~

Bug#919726: ITP: lambda-align2 -- Local Aligner for Massive Biological DatA, version 2

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: lambda-align2
  Version : 2.0.0
  Upstream Author : Hannes Hauswedell
* URL : https://github.com/seqan/lambda
* License : AGPL-3
  Programming Lang: C++
  Description : Local Aligner for Massive Biological DatA, version 2

Lambda2 is a local biosequence aligner optimized for many query sequences
and searches in protein space. It is compatible to the de facto standard tool
BLAST, but often outperforms the best currently available alternatives at
reproducing BLAST’s results and is the fastest compared with the current
state of the art at comparable levels of sensitivity.

This package is for the Lambda v2.x series which has an incompatible
command line interface and on disk format from Lambda v1.x, which is
already packaged as lambda-align.

Bug#919724: cxxtest: git snapshot breaks compatibility with official release

[beuc]

Package: cxxtest
Version: 4.4+git171022-1

Hi,

I could not find information about this behavior change.

cxxtest has historically a limitation with
TS_ASSERT_EQUALS/TS_ASSERT_DIFFERS, which validates the following test:

    char str[] = "toto";
    char* str2 = strdup(str);
    TS_ASSERT_EQUALS(str, str2);
    TS_ASSERT_DIFFERS(str, str2);

With the new Git snapshot, this test now does not pass.
Whether this is a sensible result or not, this breaks existing
testsuites, AFAICS without notice from the package or the maintainer
(the ChangeLog is still from 4.4), nor a way to determine the cxxtest
variant (release/snapshot) installed by the end user.

Could you document the reason why Debian ships a Git snapshot rather
than an official release?

In addition, do you think it is better to revert the Debian version,
document this behavior change, or check with upstream how to implement
an upgrade plan?

Cheers!
Sylvain

Bug#919725: cryptsetup: switch to LUKS2 by default for new installs

[Matt Taggart]

Package: cryptsetup
Version: 2:2.0.6-1
Severity: wishlist

LUKS2 format was introduced in 2:2.0.0~rc0-1 which went into debian on
03 Oct 2017. There was some discussion on the debian-boot list during
the libcryptsetup transition about the format

https://lists.debian.org/debian-boot/2017/12/msg00231.html

including a comment,

  "feel free to poke us again for partman-crypto when the new format
  looks mature enough so that we see about adding support for it."

Is it ready to become the default for new installs yet?

I started thinking about this when I saw that Fedora is planning on
moving to it by default

https://www.phoronix.com/scan.php?page=news_item=Fedora-30-LUKS2-Default

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#919518: file:///usr/share/doc/ghc-doc/html/libraries/index.html hits the network

[Clint Adams]

On Wed, Jan 16, 2019 at 04:38:42PM -0400, Joey Hess wrote:
> This script is loaded from the network:
> https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS-MML_HTMLorMML

Fix committed to git

Bug#919723: Patch for some AppArmor profiles

[Jörg Sommer]

Package: apparmor
Version: 2.13.2-3
Severity: normal

Hi,

I've added some rules to profiles shipped with package to better match the
behaviour of Firefox and Skype. Maybe some of them are helpful and you
want pick them. Otherwise you're free to close this report.

Regards Jörg

diff -u -r /tmp/aa/etc/apparmor.d/abstractions/dconf 
/etc/apparmor.d/abstractions/dconf
--- /tmp/aa/etc/apparmor.d/abstractions/dconf   2019-01-01 19:03:54.0 
+0100
+++ /etc/apparmor.d/abstractions/dconf  2019-01-11 12:17:18.614182127 +0100
@@ -4,5 +4,5 @@
 # be specified in a specific application's profile.
 
   /etc/dconf/** r,
-  owner /{,var/}run/user/*/dconf/user r,
+  owner /{,var/}run/user/*/dconf/user rw,
   owner @{HOME}/.config/dconf/user r,
diff -u -r /tmp/aa/etc/apparmor.d/abstractions/fonts 
/etc/apparmor.d/abstractions/fonts
--- /tmp/aa/etc/apparmor.d/abstractions/fonts   2019-01-01 19:03:54.0 
+0100
+++ /etc/apparmor.d/abstractions/fonts  2019-01-18 22:56:20.159428688 +0100
@@ -18,14 +18,14 @@
   /usr/share/fonts/**   r,
 
   /etc/fonts/** r,
-  /usr/share/fontconfig/conf.avail/**   r,
+  /usr/share/fontconfig/conf.avail/{,**} r,
 
   /opt/kde3/share/fonts/**  r,
 
   /usr/lib{,32,64}/openoffice/share/fonts/**r,
 
   /var/cache/fonts/**   r,
-  /var/cache/fontconfig/**  mr,
+  /var/cache/fontconfig/**  rw,
   /var/lib/defoma/**mr,
 
   /usr/share/a2ps/fonts/**  r,
@@ -43,7 +43,7 @@
   owner @{HOME}/.local/share/fonts/**   r,
   owner @{HOME}/.fonts.cache-2  mr,
   owner @{HOME}/.{,cache/}fontconfig/   r,
-  owner @{HOME}/.{,cache/}fontconfig/** mrl,
+  owner @{HOME}/.{,cache/}fontconfig/** rwlk,
   owner @{HOME}/.fonts.conf.d/  r,
   owner @{HOME}/.fonts.conf.d/**r,
   owner @{HOME}/.config/fontconfig/ r,
diff -u -r /tmp/aa/etc/apparmor.d/abstractions/gnome 
/etc/apparmor.d/abstractions/gnome
--- /tmp/aa/etc/apparmor.d/abstractions/gnome   2019-01-01 19:03:54.0 
+0100
+++ /etc/apparmor.d/abstractions/gnome  2019-01-12 11:19:46.827157086 +0100
@@ -63,6 +63,7 @@
   owner @{HOME}/.fonts.cache-*rwl,
 
   # icon caches
+  owner @{HOME}/.cache/gtk-3.0/** r,
   /var/cache/**/icon-theme.cache  r,
   /usr/share/**/icon-theme.cache  r,
 
diff -u -r /tmp/aa/etc/apparmor.d/abstractions/mesa 
/etc/apparmor.d/abstractions/mesa
--- /tmp/aa/etc/apparmor.d/abstractions/mesa2019-01-01 19:03:54.0 
+0100
+++ /etc/apparmor.d/abstractions/mesa   2019-01-18 21:01:17.727350842 +0100
@@ -2,6 +2,8 @@
 # Rules for Mesa implementation of the OpenGL API
 
   # System files
+  /etc/drirc r,
+  /usr/share/drirc.d/{,*} r,
   /dev/dri/ r, # libGLX_mesa.so calls drmGetDevice2()
 
   # User files
diff -u -r /tmp/aa/etc/apparmor.d/tunables/alias /etc/apparmor.d/tunables/alias
--- /tmp/aa/etc/apparmor.d/tunables/alias   2019-01-01 19:03:54.0 
+0100
+++ /etc/apparmor.d/tunables/alias  2019-01-16 00:20:42.868356851 +0100
@@ -14,3 +14,5 @@
 #
 # Or if mysql databases are stored in /home:
 # alias /var/lib/mysql/ -> /home/mysql/,
+
+alias /bin/sh -> /bin/dash,


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

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages apparmor depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  libc6  2.28-5
ii  lsb-base   10.2018112800
ii  python33.7.1-3

apparmor recommends no packages.

Versions of packages apparmor suggests:
ii  apparmor-profiles-extra  1.24
ii  apparmor-utils   2.13.2-3

-- 
Wer A sagt, muß nicht B sagen. Er kann auch erkennen, daß A falsch war.
(Erich Kästner)


signature.asc
Description: PGP signature

Bug#919722: git-secret: Please update git-secret to upstream version

[Josh Rabinowitz]

Package: git-secret
Version: 0.2.3-1
Severity: normal

Dear Maintainer,

There have been a couple of versions of git-secret released since the last
Debian update of 0.2.3.

There have been several usability enhancements and bug fixes.

There is debian packaging here: 

  https://bintray.com/sobolevn/deb/git-secret/

Source: https://github.com/sobolevn/git-secret/

Thank you.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-8-686-pae (SMP w/1 CPU core)
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 git-secret depends on:
ii  coreutils8.26-3
ii  gawk 1:4.1.4+dfsg-1
ii  git  1:2.20.1-1
ii  gnupg [gpg]  2.1.18-8~deb9u3

git-secret recommends no packages.

git-secret suggests no packages.

-- no debconf information

Bug#919707: matrix-synapse: Missing depends

[Kurt Roeckx]

On Fri, Jan 18, 2019 at 10:34:36PM +0100, Andrej Shadura wrote:
> Hi,
> 
> On Fri, 18 Jan 2019 at 22:15, Kurt Roeckx  wrote:
> > On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> > > found 919707 0.34.1.1-2~bpo9+1
> > > notfound 919707 0.34.1.1-2
> >
> > I believe the version I've set it to was the correct version, even
> > when I did find the problem in backports, the problem really exist
> > is both testing and stretch-backports.
> >
> > You should always set the correct versioned requirements, even if
> > testing already contains the version you need. This will ensure
> > that partial upgrades work properly. It will also make sure that
> > backporting is easier.
> 
> In fact, I do have correct dependencies set

You Depend on python3-pymacaroons, while you should depend on
python3-pymacaroons (>= 0.9.3). You have
python3-msgpack (>= 0.3.0), while it should be be >= 0.4.2.

> looking at the code, you
> shouldn’t be getting this message since jinja2 is an optional
> dependency. Unless you enabled resources.consent or
> email.enable_notifs.

enable_notifs is commented out, can't find a thing about consent
in my config file. I don't know why it fails. From what I read, I
shouldn't need it. But even after installing the other 2 it still
failed.

Anyway, it has a Suggests python3-jinja2 (>= 2.8), while it should be 2.9.


Kurt

Bug#919632: "New" firmware instantly crashes on QCA9377

[Kevin Price]

I just saw that the upstream maintainer had noted the version numbering
in the very commit that broke my WiFi.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/ath10k/QCA9377/hw1.0?id=56e5de3261877e5ca9df285e0751368c72b0861a

What I've not tried is upstream's latest commit
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/ath10k/QCA9377/hw1.0?id=3e2e5d3c5bce21b4ef5bd89bad604e2be48c73b1
because it's not included in your latest 20190114-1. Would you like me
to give it a shot?

best
Kevin

Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration

[Zygo Blaxell]

On Fri, Jan 18, 2019 at 09:27:27PM +, Mark Hindley wrote:
> On Fri, Jan 18, 2019 at 03:19:11PM -0500, Zygo Blaxell wrote:
> > I get:
>  
> [snipped]
> 
> > HandleLidSwitch=suspend
> > HandleLidSwitchDocked=ignore
> > Docked=yes
>  
> > It seems there is some significant lag (several seconds, maybe a minute
> > or two) before "Docked" changes to the correct value.  The "Docked" state
> > definitely does not update while the rapid suspends are happening.  I can
> > wake the laptop with the docked keyboard spacebar, but it immediately
> > goes back to sleep again, at least 20 times.  After that it starts
> > ignoring the spacebar and stays asleep until I undock and open the lid.
> > 
> > I encountered a similar problem on another laptop some months ago, where
> > that laptop's lid switch was always reporting closed.  That system was
> > running systemd, and the fix was to set HandleLidSwitch=ignore, but in
> > a different configuration file from what elogind uses.
> 
> And does that fix work for elogind too if you set it in 
> /etc/elogind/logind.conf?

It seems to.

Given that elogind conflicts with and functionally replaces pieces of
systemd, wouldn't it make sense for them to use the same config file?

I proactively install systemd configuration fragments on systems running
sysvinit to avoid cases precisely like this one, where some piece of
systemd gets split off and suddenly appears on a sysvinit system during
an apt-get.  Had elogind read the systemd-logind config file instead of
its own, this could have been avoided (or at least resolved sooner by
replaying a previously documented solution).

> > I had configured acpi-support to take no suspend
> > action on lid close, docked or otherwise.  elogind appears to be
> > unaware of acpi-support's overlapping functionality, and the maintainer
> > scripts for elogind don't adjust elogind's configuration to disable
> > lid/power/hibernate key handling if there's another ACPI event handler
> > already installed on the system.  Both can be installed at the same time,
> > and by default both will try to suspend the system, so in the worst case
> > you could get two suspend/resume cycles per lid close (which is a great
> > way to find ACPI firmware bugs).
> 
> Yes, maybe elogind and acpi-support should just conflict.

That seems unfortunate as the two packages are not exact functional
replacements of each other, but it would solve this particular problem.

I'd expect systemd and acpi-support to conflict for the same reason,
but they don't.  Maybe the problem is solved there in a different way?
Or maybe installing systemd on a machine with previously configured
acpi-support has the same bug.

> Mark


signature.asc
Description: PGP signature

Bug#818793: Segmentation fault related to log filename and dateformat length when using compress, sharedscripts, olddir

[Bernhard Übelacker]

Dear Maintainer,
I tried to find out where this stack in message #25
would point to, if it may help.

The failing call to free, I guess, would be in
function rotateLogSet in logrotate.c, line 1749.

1748for (i = 0; i < log->numFiles; i++) {
1749free(rotNames[i]->firstRotated);   
1750free(rotNames[i]->disposeName);
1751free(rotNames[i]->finalName);
1752free(rotNames[i]->dirName);
1753free(rotNames[i]->baseName);
1754free(rotNames[i]);
1755}

Kind regards,
Bernhard


From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818793#25


=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x71ff5)[0x7f6bcc5f3ff5]
/lib/x86_64-linux-gnu/libc.so.6(+0x77946)[0x7f6bcc5f9946]
/lib/x86_64-linux-gnu/libc.so.6(+0x7812e)[0x7f6bcc5fa12e]
logrotate[0x407aa4]
logrotate[0x402f9c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6bcc5a2610]
logrotate[0x4036b2]
=== Memory map: 



"debian stretch/sid" at "25 Mar 2016" ?

...
https://tracker.debian.org/pkg/logrotate
[2017-01-03] Accepted logrotate 3.11.0-0.1~exp1 (source powerpc) into 
experimental (Christoph Biedl)
[2015-08-24] Accepted logrotate 3.9.1-1~exp1 (source amd64) into experimental 
(Paul Martin)
[2015-05-16] logrotate 3.8.7-2 MIGRATED to testing (Britney)


-> logrotate 3.8.7-2 ?


#



# Jessie amd64 qemu VM


approx:
debian-9-stretch-snapshot.debian.org
https://snapshot.debian.org/archive/debian/20160325T00Z/
#debian-9-stretch-debug-snapshot.debian.org  
https://snapshot.debian.org/archive/debian-debug/20160325T00Z/

sources.list:
# snapshot
deb [check-valid-until=no] 
http://192.168.178.25:/debian-9-stretch-snapshot.debian.org/ stretch main
#deb-src [check-valid-until=no] 
http://192.168.178.25:/debian-9-stretch-snapshot.debian.org/ stretch main
#deb [check-valid-until=no] 
http://192.168.178.25:/debian-9-stretch-debug-snapshot.debian.org/ 
stretch-debug main



apt-get -o Acquire::Check-Valid-Until=false -o Acquire::Languages=none update
apt dist-upgrade
reboot




apt install gdb libc6-dbg
apt install dpkg-dev devscripts
apt build-dep logrotate




mkdir source/logrotate/orig -p
cdsource/logrotate/orig
apt source logrotate
cd

cd source/logrotate
cp orig try1 -a
cd try1/logrotate-3.8.7
dpkg-buildpackage


#


gdb -q --args /usr/sbin/logrotate
set width 0
set pagination off
set backtrace past-main on
display/i $pc
b __libc_start_main
run
print __libc_start_main+238
b *$1
cont
stepi


   0x00407a9f:  callq  0x402290 
   0x00407aa4:  mov0x8(%r13),%rdi

   0x00402f97:  callq  0x407310
   0x00402f9c:  mov0xd8(%rbx),%rbx

   0x7741f60e <__libc_start_main+238>:  callq  *%rax
=> 0x7741f610 <__libc_start_main+240>:  mov%eax,%edi

   0x004036ad:  callq  0x402570 <__libc_start_main@plt>
=> 0x004036b2:  hlt





#


gdb -q --args /home/benutzer/source/logrotate/try1/logrotate-3.8.7/logrotate
set width 0
set pagination off
set backtrace past-main on
display/i $pc
b main
run


   0x00407a37 :  callq  0x402280 
   0x00407a3c :  mov0x8(%r13),%rdi

   0x00402f7b :   callq  0x4072c0 
   0x00402f80 :   mov0xd8(%rbx),%rbx

   0x7741f60e <__libc_start_main+238>:  callq  *%rax
=> 0x7741f610 <__libc_start_main+240>:  mov%eax,%edi

   0x004036b4 <_start+36>:  callq  0x402560 <__libc_start_main@plt>
=> 0x004036b9 <_start+41>:  hlt




1748for (i = 0; i < log->numFiles; i++) {
   0x00407a16 <+1878>:  xor%r14d,%r14d
   0x00407a19 <+1881>:  test   %eax,%eax
   0x00407a1b <+1883>:  mov-0x90(%rbp),%r15
   0x00407a22 <+1890>:  jle0x407a6e 
   0x00407a24 <+1892>:  nopl   0x0(%rax)
   0x00407a2b <+1899>:  add$0x1,%r14d
   0x00407a2f <+1903>:  add$0x8,%r15
   0x00407a68 <+1960>:  cmp%r14d,0x10(%rbx)
   0x00407a6c <+1964>:  jg 0x407a28 

1749free(rotNames[i]->firstRotated);
   0x00407a28 <+1896>:  mov(%r15),%r13
   0x00407a33 <+1907>:  mov0x0(%r13),%rdi
   0x00407a37 <+1911>:  callq  0x402280 

1750free(rotNames[i]->disposeName);
   0x00407a3c <+1916>:  mov0x8(%r13),%rdi
   0x00407a40 <+1920>:  callq  0x402280 

1751free(rotNames[i]->finalName);
   0x00407a45 <+1925>:  mov0x10(%r13),%rdi
   0x00407a49 <+1929>:  callq  0x402280 

1752free(rotNames[i]->dirName);





0x407a37: file logrotate.c, line 1749.




(gdb) list logrotate.c:1740,1760
1740logHasErrors[i] |=
1741postrotateSingleLog(log, i, state[i], rotNames[i]);
1742hasErrors |= logHasErrors[i];
1743}
1744}
1745
1746}
1747

Bug#919679: Please apply patch from PR 3102

[Bill Allombert]

On Fri, Jan 18, 2019 at 09:45:06PM +0100, Tobias Hansen wrote:
> On 1/18/19 4:03 PM, Tobias Hansen wrote:
> > On 1/18/19 3:45 PM, Bill Allombert wrote:
> >> On Fri, Jan 18, 2019 at 03:28:04PM +0100, Tobias Hansen wrote:
> >>> Package: src:gap
> >>> Version: 4r10p0-6
> >>> Severity: wishlist
> >>> Tags: sid buster patch
> >>>
> >>> Hi Bill,
> >>>
> >>> a version of the remaining patch that sagemath applies to gap was
> >>> merged upstream a while ago [1] (and tagged for backporting to gap
> >>> 4.10). embray indicated in [2] that the patch is important for
> >>> non-interactive use of gap so I wanted to ask if you would add it to
> >>> the Debian package now that it is merged.
> >> Hello Tobias 
> >> Do you know when GAP 4.10.1 will be released ?
> >>
> >> There are two failure related to gap-tomlib in the sagemath
> >> build log. Could you check them ?
> >>
> >> Cheers,
> > No I don't know anything about the gap 4.10.1 release date.
> >
> > gap-table-of-marks is not yet a dependency of the sagemath which
> > should explain the failures. I will try if installing more gap
> > libraries fixes doctests.
> >
> Installing gap-online-help, gap-atlasrep and gap-table-of-marks fixes
> almost all remaining gap related doctests in sage, however if I
> install gap-io it leads to many failing tests. 

Could you see why ? I also have problem wth gac when gap-io is
installed.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#894476: Workarounds for rcc reproducibility issues due to mtime

[Peter Wu]

Hi all,

To improve reproducibility for an upstream project that does not rely on
a valid QFileInfo::lastModified value, we used the --format-version 1
option to force the use of the older (pre-Qt 5.8) format that does not
include the timestamp.

This upstream project uses CMake with AUTORCC enabled, the patch was
pretty simple: https://code.wireshark.org/review/31593

For the benefit of other distributions (I also use Arch Linux) and
upstream projects, I have documented this here as well:
https://reproducible-builds.org/docs/deterministic-build-systems/#cmake-notes

If you feel that the recommendations are wrong, feel free to edit the
page or discuss it here or on IRC, I aimed at having the peculiarities
documented somewhere.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

Bug#919720: RM: ruby-albino -- ROM; dead upstream, obsolete

[Cédric Boutillier]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

please remove ruby-albino from the archive. It has problems due to
transition of pygmentize to python3, dead upstream for many years and
obsolete. No reverse (build)dependencies.

Thanks in advance!

Cheers,

Cédric

Bug#919719: ITP: python-sqt -- SeQuencing Tools

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-sqt
  Version : 0.8.0
* URL : https://bitbucket.org/marcelm/sqt
* License : MIT/X
  Programming Lang: Python
  Description : SeQuencing Tools

To be co-maintained on salsa.debian.org/med-team/python-sqt

Bug#919707: matrix-synapse: Missing depends

[Andrej Shadura]

Hi,

On Fri, 18 Jan 2019 at 22:15, Kurt Roeckx  wrote:
> On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> > found 919707 0.34.1.1-2~bpo9+1
> > notfound 919707 0.34.1.1-2
>
> I believe the version I've set it to was the correct version, even
> when I did find the problem in backports, the problem really exist
> is both testing and stretch-backports.
>
> You should always set the correct versioned requirements, even if
> testing already contains the version you need. This will ensure
> that partial upgrades work properly. It will also make sure that
> backporting is easier.

In fact, I do have correct dependencies set, looking at the code, you
shouldn’t be getting this message since jinja2 is an optional
dependency. Unless you enabled resources.consent or
email.enable_notifs.

-- 
Cheers,
  Andrej

Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration

[Mark Hindley]

On Fri, Jan 18, 2019 at 03:19:11PM -0500, Zygo Blaxell wrote:
> I get:
 
[snipped]

>   HandleLidSwitch=suspend
>   HandleLidSwitchDocked=ignore
>   Docked=yes
 
> It seems there is some significant lag (several seconds, maybe a minute
> or two) before "Docked" changes to the correct value.  The "Docked" state
> definitely does not update while the rapid suspends are happening.  I can
> wake the laptop with the docked keyboard spacebar, but it immediately
> goes back to sleep again, at least 20 times.  After that it starts
> ignoring the spacebar and stays asleep until I undock and open the lid.
> 
> I encountered a similar problem on another laptop some months ago, where
> that laptop's lid switch was always reporting closed.  That system was
> running systemd, and the fix was to set HandleLidSwitch=ignore, but in
> a different configuration file from what elogind uses.

And does that fix work for elogind too if you set it in 
/etc/elogind/logind.conf?

> Note that docked state tracking is irrelevant to the original issue
> I was reporting.

Hmmm, the docked state changes which action elogind executes for the lid switch
-- HandleLidSwitch or HandleLidSwitchDocked. The defaults for each are
different. If the Docked state is slow to update then the wrong action might be
being invoked.

I also notice you have

>   InhibitDelayMaxUSec=5s
>   UserStopDelayUSec=0
>   HoldoffTimeoutUSec=30s
>   IdleActionUSec=30min

The manpage refers to InhibitDelayMaxSec, UserStopDelaySec, HoldoffTimeoutSec
and IdleActionSec (no 'U'). I will have to look into the significance of those.

> I had configured acpi-support to take no suspend
> action on lid close, docked or otherwise.  elogind appears to be
> unaware of acpi-support's overlapping functionality, and the maintainer
> scripts for elogind don't adjust elogind's configuration to disable
> lid/power/hibernate key handling if there's another ACPI event handler
> already installed on the system.  Both can be installed at the same time,
> and by default both will try to suspend the system, so in the worst case
> you could get two suspend/resume cycles per lid close (which is a great
> way to find ACPI firmware bugs).

Yes, maybe elogind and acpi-support should just conflict.

Mark

Bug#919718: ITP: igdiscover -- analyse immune repertoire to find new V genes

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: igdiscover
  Version : 0.11
* URL : https://github.com/NBISweden/IgDiscover
* License : MIT/X
  Programming Lang: Python
  Description : analyse immune repertoire to find new V genes

To be co-maintained on https://salsa.debian.org/med-team/igdiscover

Bug#919707: matrix-synapse: Missing depends

[Kurt Roeckx]

On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> found 919707 0.34.1.1-2~bpo9+1
> notfound 919707 0.34.1.1-2

I believe the version I've set it to was the correct version, even
when I did find the problem in backports, the problem really exist
is both testing and stretch-backports.

You should always set the correct versioned requirements, even if
testing already contains the version you need. This will ensure
that partial upgrades work properly. It will also make sure that
backporting is easier.


Kurt

Bug#918432: [Pkg-samba-maint] Bug#918432: samba: net ads join to armel arch Samba DC failed

[Mathieu Parent]

Control: forwarded -1 https://bugzilla.samba.org/show_bug.cgi?id=13755

Hi Tomasz,

Please keep the bug CC-ed.

Le mer. 9 janv. 2019 à 21:03, Tomasz Jeliński  a écrit :
>
>
> W dniu 09.01.2019 o 04:56, Mathieu Parent pisze:
> > Le dim. 6 janv. 2019 à 01:12, Tomasz Jelinski  a écrit 
> > :
> >> Package: samba
> >> Version: 2:4.5.12+dfsg-2+deb9u4
> >> Severity: normal
> >>
> >> Dear Maintainer,
> > Hi,
> Hi,
> >> I can't connect workstation to samba DC configured on Orion platform
> >> (armel arch) with installed  Debian Stretch (packages are fully updated to 
> >> newest avaliable versions).
> > Are you able to reproduce this from Debian testing (4.9.4)?
> >
> Today I upgraded samba to testing on device which trying to acts as
> samba AD DC (QNAP TS-209 armel arch). I cleaned samba databases
> (ldb,tdb) and performed DC provision from scratch. I acknowledge that
> problem still exists and I can reproduce this on samba packages from
> Debian testing repository (attachment - netadsjoin.log)

OK.

> System Information  from QNAP TS-209 samba AD-DC:
>
> Package: samba
> Version: 3:4.9.4+dfsg-1
>
> Debian Release: 10.6
>   APT prefers testing
>   APT policy: (561, 'testing'), (550, 'stable'), (510,
> 'stable-updates'), (500, 'stable')
> Architecture: armel (armv6tel)
>
> Kernel: Linux 4.9.0-8-marvell
> Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8),
> LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages samba depends on:
> ii  adduser   3.115
> ii  dpkg  1.18.25
> ii  libbsd0   0.8.3-1
> ii  libc6 2.28-2
> ii  libldb1   2:1.5.1+really1.4.3-1
> ii  libpam-modules1.1.8-3.6
> ii  libpam-runtime1.1.8-3.6
> ii  libpopt0  1.16-10+b2
> ii  libpython2.7  2.7.13-2+deb9u3
> ii  libtalloc22.1.8-1
> ii  libtdb1   1.3.16-2+b1
> ii  libtevent00.9.37-1
> ii  lsb-base  9.20161125
> ii  procps2:3.3.12-3+deb9u1
> ii  python2.7.13-2
> ii  python-dnspython  1.15.0-1
> ii  python-samba  2:4.9.4+dfsg-1
> ii  python2.7 2.7.13-2+deb9u3
> ii  samba-common  2:4.9.4+dfsg-1
> ii  samba-common-bin  2:4.9.4+dfsg-1
> ii  samba-libs2:4.9.4+dfsg-1
> ii  tdb-tools 1.3.11-2
>
> Versions of packages samba recommends:
> ii  attr1:2.4.47-2+b2
> ii  logrotate   3.11.0-0.1
> ii  samba-dsdb-modules  2:4.9.4+dfsg-1
> ii  samba-vfs-modules   2:4.9.4+dfsg-1
>
> Versions of packages samba suggests:
> pn  bind9  
> pn  bind9utils 
> pn  ctdb   
> ii  ldb-tools  2:1.1.27-1+b1
> ii  ntp1:4.2.8p10+dfsg-3+deb9u2
> pn  smbldap-tools  
> ii  ufw0.35-4
> ii  winbind2:4.9.4+dfsg-1
>
> -- no debconf information
>
> Workstation has a samba stable version - 2:4.5.12+dfsg-2+deb9u4. I
> suppose that problem is related to armel architecture because I can
> perform 'net ads join' from my workstation to samba DC stable version
> 2:4.5.12+dfsg-2+deb9u4 , configured in the same way on amd64 arch
> (tested on Debian Stretch VM in Virtualbox)

So, you have upgraded the server, but not the workstation. What if you
test with a testing/sid armel?

Regards

-- 
Mathieu Parent

Bug#919717: biosig4c++ FTBFS on 32bit: symbol differences

[Adrian Bunk]

Source: biosig4c++
Version: 1.9.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=biosig4c%2B%2B=sid

...
dh_makeshlibs
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libbiosig2/DEBIAN/symbols doesn't match 
completely debian/libbiosig2.symbols
--- debian/libbiosig2.symbols (libbiosig2_1.9.3-1_i386)
+++ dpkg-gensymbolsvMyQ0c   2019-01-18 13:32:03.817439748 +
@@ -670,11 +670,11 @@
  (c++)"TiXmlPrinter::VisitExit(TiXmlDocument const&)@Base" 1.3.6
  (c++)"TiXmlPrinter::VisitExit(TiXmlElement const&)@Base" 1.3.6
  (c++)"TiXmlPrinter::~TiXmlPrinter()@Base" 1.3.6
- (c++)"TiXmlString::append(char const*, unsigned long)@Base" 1.3.6
- (c++)"TiXmlString::assign(char const*, unsigned long)@Base" 1.3.6
+#MISSING: 1.9.3-1# (c++)"TiXmlString::append(char const*, unsigned long)@Base" 
1.3.6
+#MISSING: 1.9.3-1# (c++)"TiXmlString::assign(char const*, unsigned long)@Base" 
1.3.6
  (c++)"TiXmlString::npos@Base" 1.3.6
  (c++)"TiXmlString::nullrep_@Base" 1.3.6
- (c++)"TiXmlString::reserve(unsigned long)@Base" 1.3.6
+#MISSING: 1.9.3-1# (c++)"TiXmlString::reserve(unsigned long)@Base" 1.3.6
  (c++)"TiXmlText::Accept(TiXmlVisitor*) const@Base" 1.3.6
  (c++)"TiXmlText::Blank() const@Base" 1.3.6
  (c++)"TiXmlText::Clone() const@Base" 1.3.6
@@ -713,6 +713,10 @@
  UnitsOfMeasurementCode_free@Base 1.3.6
  UnitsOfMeasurementCode_print@Base 1.3.6
  VERBOSE_LEVEL@Base 1.3.6
+ _Z8mymallocj@Base 1.9.3-1
+ _ZN11TiXmlString6appendEPKcj@Base 1.9.3-1
+ _ZN11TiXmlString6assignEPKcj@Base 1.9.3-1
+ _ZN11TiXmlString7reserveEj@Base 1.9.3-1
  
_ZN12TiXmlComment8StreamInEPSiPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 1.9.3
  
_ZN12TiXmlElement12SetAttributeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES7_@Base
 1.9.3
  
_ZN12TiXmlElement12SetAttributeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi@Base
 1.9.3
@@ -1138,7 +1142,7 @@
  makeTree@Base 1.3.6
  mfer_swap8b@Base 1.3.6
  month_string2int@Base 1.9.3
- (c++)"mymalloc(unsigned long)@Base" 1.3.6
+#MISSING: 1.9.3-1# (c++)"mymalloc(unsigned long)@Base" 1.3.6
  newNode@Base 1.3.6
  (c++)"operator+(TiXmlString const&, TiXmlString const&)@Base" 1.3.6
  (c++)"operator+(TiXmlString const&, char const*)@Base" 1.3.6
dh_makeshlibs: failing due to earlier errors
make[1]: *** [debian/rules:76: override_dh_makeshlibs] Error 2

Bug#919679: Please apply patch from PR 3102

[Tobias Hansen]

On 1/18/19 4:03 PM, Tobias Hansen wrote:
> On 1/18/19 3:45 PM, Bill Allombert wrote:
>> On Fri, Jan 18, 2019 at 03:28:04PM +0100, Tobias Hansen wrote:
>>> Package: src:gap
>>> Version: 4r10p0-6
>>> Severity: wishlist
>>> Tags: sid buster patch
>>>
>>> Hi Bill,
>>>
>>> a version of the remaining patch that sagemath applies to gap was
>>> merged upstream a while ago [1] (and tagged for backporting to gap
>>> 4.10). embray indicated in [2] that the patch is important for
>>> non-interactive use of gap so I wanted to ask if you would add it to
>>> the Debian package now that it is merged.
>> Hello Tobias 
>> Do you know when GAP 4.10.1 will be released ?
>>
>> There are two failure related to gap-tomlib in the sagemath
>> build log. Could you check them ?
>>
>> Cheers,
> No I don't know anything about the gap 4.10.1 release date.
>
> gap-table-of-marks is not yet a dependency of the sagemath which should 
> explain the failures. I will try if installing more gap libraries fixes 
> doctests.
>
> sagemath upstream now install all these libraries by default:
>
>     pkg/atlasrep \
>     pkg/autpgrp-* \
>     pkg/alnuth-* \
>     pkg/crisp-* \
>     pkg/ctbllib \
>     pkg/FactInt-* \
>     pkg/fga \
>     pkg/irredsol-* \
>     pkg/laguna-* \
>     pkg/polenta-* \
>     pkg/polycyclic-* \
>     pkg/resclasses-* \
>     pkg/sophus-* \
>     pkg/tomlib-* \
>
> A bunch of these I could not find in Debian:
>
>     pkg/crisp-* \
>     pkg/fga \
>     pkg/irredsol-* \
>     pkg/polenta-* \
>     pkg/resclasses-* \
>     pkg/sophus-* \
>
> I don't know yet if it is a problem that they are missing.
>
> Best,
>
> Tobias
>
Installing gap-online-help, gap-atlasrep and gap-table-of-marks fixes almost 
all remaining gap related doctests in sage, however if I install gap-io it 
leads to many failing tests. 

Best,

Tobias

Bug#919716: ITP: libgit-sub-perl -- git commands imported as System::Sub subs in the git:: namespace

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libgit-sub-perl
  Version : 0.163320
  Upstream Author : Olivier Mengué, 
* URL : https://metacpan.org/release/Git-Sub
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : git commands imported as System::Sub subs in the git:: 
namespace

 Git::Sub enables calling git commands
 easily from your Perl program.
 Each git command is imported as a System::Sub DWIM sub.

This package will be maintained in the Debian Perl team.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIyBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxCODoACgkQLHwxRsGg
ASHHog/3SjOqxBzFuJix8MGysPORSzFzt4mlRgPFIFHJGws9ylM/HLvn/m6VVIUf
W+8TAyh9W9JQF4uSFleQJ1GuvzNsy8zvygFFlSH4SA2xmSFzgud41eo/NjCeu8li
NVrxmoCFTesPNPtNGsXUxQoJlkklDxka3hQjrlYIqt8GFIQEt+dRyY80CZus5Q+/
nMrmeTcgk/DTz8mq7Z367DxmPEyLwJF7avYBIsTvzG9BNjyTJIaB7vAvaTW345j/
3wAFLb0ybT71N5vM7vHzgtnGyvOeD0WGMXRaN80+QRMiFoa0F772m6MB9kv0dj9k
Dw1wiW9nzFRE0cpg3h4ulDamaPTKybx1/lEiKYaFKXSvNmxF4yf6Fn9URE3hlfQn
/Q/Wka70w0YQb1G5J5ftAjG/JxaHfZpdnAlz0w1pMCEXW4nH1axnIQBxSbxDg/29
eA2EkDcAzULcWHTnCG+0L2Oc+DO0W7AlhuSDPfz3Bzf+wGJlt9Y5wd0pk4MdfF4e
NnCKywMIXIK2A+jaMmG6Kwzz3wcZlsbNP8wpGYBFttu4UIoKecWN9ulOq7pRObBa
FCAdrNNFnHGXs0LeofVkTo59mf/UWfldUpzdmDpE9CZr2BTqA672YQC0GsEvAVPm
wNM3bVPePdUAg5u1Vw1dKaMfTYbjnC5xXNMioaWi1x9s4D2XjA==
=+k8G
-END PGP SIGNATURE-

Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration

[Zygo Blaxell]

On Fri, Jan 18, 2019 at 05:00:19PM +, Mark Hindley wrote:
> On Fri, Jan 18, 2019 at 11:18:27AM -0500, Zygo Blaxell wrote:
> > Source: elogind
> > Version: 239.3-4+debian1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > I installed elogind on a laptop because it was a dependency of other
> > packages.  When I attempted to use the laptop in a docking station
> > with the lid closed, it immediately and repeatedly went into suspend,
> > despite my prior configuration of acpi-support to not take any action
> > on lid close.
> 
> Zygo,
> 
> Thanks for this.
> 
> Could you reinstall elogind and post the output of 'loginctl show-seat' when 
> in
> the docking station? I am particularly interested in the values of Docked,
> HandleLidSwitch and HandleLidSwitchDocked.

I get:

EnableWallMessages=no
KillUserProcesses=no
RebootToFirmwareSetup=no
IdleHint=yes
IdleSinceHint=0
IdleSinceHintMonotonic=0
InhibitDelayMaxUSec=5s
UserStopDelayUSec=0
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
HandleLidSwitchDocked=ignore
HoldoffTimeoutUSec=30s
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no
Docked=yes
RemoveIPC=yes
RuntimeDirectorySize=1649360896
InhibitorsMax=8192
NCurrentInhibitors=0
SessionsMax=8192
NCurrentSessions=0

It seems there is some significant lag (several seconds, maybe a minute
or two) before "Docked" changes to the correct value.  The "Docked" state
definitely does not update while the rapid suspends are happening.  I can
wake the laptop with the docked keyboard spacebar, but it immediately
goes back to sleep again, at least 20 times.  After that it starts
ignoring the spacebar and stays asleep until I undock and open the lid.

I encountered a similar problem on another laptop some months ago, where
that laptop's lid switch was always reporting closed.  That system was
running systemd, and the fix was to set HandleLidSwitch=ignore, but in
a different configuration file from what elogind uses.

Note that docked state tracking is irrelevant to the original issue
I was reporting.  I had configured acpi-support to take no suspend
action on lid close, docked or otherwise.  elogind appears to be
unaware of acpi-support's overlapping functionality, and the maintainer
scripts for elogind don't adjust elogind's configuration to disable
lid/power/hibernate key handling if there's another ACPI event handler
already installed on the system.  Both can be installed at the same time,
and by default both will try to suspend the system, so in the worst case
you could get two suspend/resume cycles per lid close (which is a great
way to find ACPI firmware bugs).



signature.asc
Description: PGP signature

Bug#919477: acl2 ftbfs on armel, armhf, arm64 and ppc64el

[Matthias Klose]

On 18.01.19 20:51, Camm Maguire wrote:
> Greetings, and thanks!  Identified a fix for ppc64el, and see the issue
> with armel, but can see none on armhf or arm64.  Am I missing something?

sorry, I saw armhf and arm64 on Ubuntu, but apparently these were just transient
build failures.

Bug#919715: wifite build depends on pyrit that is currently not in buster

[Adrian Bunk]

Source: wifite
Version: 2.2.5-2
Severity: serious
Tags: ftbfs
Control: block -1 by 906555

wifite build depends on pyrit that is currently
not in buster due to #906555.

Bug#919700: "apt-file list" prints files for wrong package

[Niels Thykier]

Control: block -1 by 703605

Jakub Wilk:
> Package: apt-file
> Version: 3.2.1
> 
> I ran into this odd corner case:
> 
>   $ apt-file list arc
>   arc: /usr/bin/arc
>   arc: /usr/bin/marc
>   arc: /usr/share/doc/arc/Arc521.doc.gz
>   arc: /usr/share/doc/arc/Arcinfo.gz
>   arc: /usr/share/doc/arc/Readme.gz
>   arc: /usr/share/doc/arc/changelog.Debian.gz
>   arc: /usr/share/doc/arc/changelog.gz
>   arc: /usr/share/doc/arc/copyright
>   arc: /usr/share/man/man1/arc.1.gz
>   arc: /usr/share/man/man1/marc.1.gz
>   arcanist: /usr/bin/arc
>   arcanist: /usr/share/man/man1/arc.1.gz
> 
> I guess apt-file got confused because "arc" is a substring of "arcanist"
> and they both ship the same files (bug #919697).
> 
> [...]
> 

Hi,

Thanks for the report.

I suspect it is the same (underlying) issue as #703605 (with the divert
case being a "more" legitimate clash).  I am keeping the bugs separate
for now but I suspect they will end up being solved at the same time.

Thanks,
~Niels

Bug#919714: satpy build depends on python3-h5netcdf that is currently not in buster

[Adrian Bunk]

Source: satpy
Version: 0.11.1-2
Severity: serious
Tags: ftbfs
Control: block -1 by 915260

satpy build depends on python3-h5netcdf that is currently
not in buster due to #915260.

Bug#919593: julia: Please use LLVM 6.0 packages

[Sylvestre Ledru]

Le 18/01/2019 à 13:42, Graham Inggs a écrit :

Hi Sylvestre

On 2019/01/17 20:00, Sylvestre Ledru wrote:

Julia should use LLVM debian packages, not embedding them.
If you have any issue with the current llvm packages, please
open bugs and we will adress them.


Why are you asking us to use the LLVM 6.0 packages when you are already filing 
bugs [1][2] against other packages asking them to switch to LLVM 7?

Well, if you can use llvm-7, this would be indeed better.


The llvm-toolchain-6.0 source package already has a removal bug [3] filed 
against it!

Which doesn't mean it will happen in time for Buster...
This is just a meta bug to keep track of the remaining work?

Sylvestre

Bug#919712: stretch-pu: package samba/2:4.5.16+dfsg-1

[Mathieu Parent]

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

Hello stable release team,

I want to upload a new version of samba on top of current stretch-security
(2:4.5.12+dfsg-2+deb9u4). The changelog is:

samba (2:4.5.16+dfsg-1) UNRELEASED; urgency=medium

  * New upstream release (latest 4.5.x)
- Drop merged patches
  * Fix CVE-2018-14629 regression when there're more than 20 records on a non
CNAME record.
  * Fix rmdir on non-empty samba directory (Closes: #915248)
  * Ignore nmbd start errors when there is no non-loopback interface
(Closes: #893762)
  * Ignore nmbd start errors when there is  no local IPv4 non-loopback interface
(Closes: #859526)
  * s3:ntlm_auth: fix memory leak in manage_gensec_request() (Closes: #919611)

 -- Mathieu Parent   Fri, 18 Jan 2019 07:35:15 +0100

The upstream changes are summarized in:
https://www.samba.org/samba/history/samba-4.5.13.html

The complete diff is too big, but can be obtained from the git repo:

  git diff 
9014cb5484b9fe550ce6547e05135626fbd5d179..faa8dd2a11501e75fee2aeeae4e943b0b17aa38c

See the attached diff of the debian directory.

I will 'dch --release' before upload. Is the version numbering correct? Should I
use stretch or stretch-security as dist?

Regards

Mathieu Parent
diff --git a/debian/changelog b/debian/changelog
index bbd5b90d9a3..a2f86eff095 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+samba (2:4.5.16+dfsg-1) UNRELEASED; urgency=medium
+
+  * New upstream release (latest 4.5.x)
+- Drop merged patches
+  * Fix CVE-2018-14629 regression when there're more than 20 records on a non
+CNAME record.
+  * Fix rmdir on non-empty samba directory (Closes: #915248)
+  * Ignore nmbd start errors when there is no non-loopback interface
+(Closes: #893762)
+  * Ignore nmbd start errors when there is  no local IPv4 non-loopback interface
+(Closes: #859526)
+  * s3:ntlm_auth: fix memory leak in manage_gensec_request() (Closes: #919611)
+
+ -- Mathieu Parent   Fri, 18 Jan 2019 07:35:15 +0100
+
 samba (2:4.5.12+dfsg-2+deb9u4) stretch-security; urgency=high
 
   * New upstream security release
diff --git a/debian/patches/CVE-2018-14629-v4-5.patch b/debian/patches/CVE-2018-14629-v4-5.patch
index 5b1c52b30cc..79d8cf7 100644
--- a/debian/patches/CVE-2018-14629-v4-5.patch
+++ b/debian/patches/CVE-2018-14629-v4-5.patch
@@ -191,3 +191,284 @@ index bef21f6bdaf..51a86198b54 100644
 -- 
 2.11.0
 
+From 6c73a2b3d77115d69f99baa2452d6539c697fc3b Mon Sep 17 00:00:00 2001
+From: Stefan Metzmacher 
+Date: Wed, 28 Nov 2018 15:21:56 +0100
+Subject: [PATCH 1/2] CVE-2018-14629 dns: fix CNAME loop prevention using
+ counter regression
+
+The loop prevention should only be done for CNAME records!
+
+Otherwise we truncate the answer records for A,  or
+SRV queries, which is a bad idea if you have more than 20 DCs.
+
+BUG: https://bugzilla.samba.org/show_bug.cgi?id=13600
+
+Signed-off-by: Stefan Metzmacher 
+---
+ source4/dns_server/dns_query.c | 29 -
+ 1 file changed, 20 insertions(+), 9 deletions(-)
+
+diff --git a/source4/dns_server/dns_query.c b/source4/dns_server/dns_query.c
+index 0c26f9f8fb5..19c4dc32faa 100644
+--- a/source4/dns_server/dns_query.c
 b/source4/dns_server/dns_query.c
+@@ -439,7 +439,8 @@ static struct tevent_req *handle_authoritative_send(
+ 	TALLOC_CTX *mem_ctx, struct tevent_context *ev,
+ 	struct dns_server *dns, const char *forwarder,
+ 	struct dns_name_question *question,
+-	struct dns_res_rec **answers, struct dns_res_rec **nsrecs);
++	struct dns_res_rec **answers, struct dns_res_rec **nsrecs,
++	size_t cname_depth);
+ static WERROR handle_authoritative_recv(struct tevent_req *req);
+ 
+ struct handle_dnsrpcrec_state {
+@@ -455,7 +456,8 @@ static struct tevent_req *handle_dnsrpcrec_send(
+ 	struct dns_server *dns, const char *forwarder,
+ 	const struct dns_name_question *question,
+ 	struct dnsp_DnssrvRpcRecord *rec,
+-	struct dns_res_rec **answers, struct dns_res_rec **nsrecs)
++	struct dns_res_rec **answers, struct dns_res_rec **nsrecs,
++	size_t cname_depth)
+ {
+ 	struct tevent_req *req, *subreq;
+ 	struct handle_dnsrpcrec_state *state;
+@@ -471,7 +473,7 @@ static struct tevent_req *handle_dnsrpcrec_send(
+ 	state->answers = answers;
+ 	state->nsrecs = nsrecs;
+ 
+-	if (talloc_array_length(*answers) >= MAX_Q_RECURSION_DEPTH) {
++	if (cname_depth >= MAX_Q_RECURSION_DEPTH) {
+ 		tevent_req_done(req);
+ 		return tevent_req_post(req, ev);
+ 	}
+@@ -516,7 +518,8 @@ static struct tevent_req *handle_dnsrpcrec_send(
+ 	if (dns_authoritative_for_zone(dns, new_q->name)) {
+ 		subreq = handle_authoritative_send(
+ 			state, ev, dns, forwarder, new_q,
+-			state->answers, state->nsrecs);
++			state->answers, state->nsrecs,
++			cname_depth + 1);
+ 		if (tevent_req_nomem(subreq, req)) {
+ 			return tevent_req_post(req, ev);
+ 		}
+@@ -600,6 +603,8 @@ struct handle_authoritative_state {
+ 
+ 	struct 

Bug#919713: virt-manager: autopkgtest regression

[Paul Gevers]

Source: virt-manager
Version: 1:2.0.0-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of virt-manager the autopkgtest of virt-manager
fails in testing when that autopkgtest is run with the binary packages
of virt-manager from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
virt-manager   from testing1:2.0.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. Are you
missing a (test) dependency?

Currently this regression is blocking the migration to testing [1]. 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=virt-manager

https://ci.debian.net/data/autopkgtest/testing/amd64/v/virt-manager/1724324/log.gz

Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-convert", line 19, in 
from virtconv import VirtConverter
  File "/usr/share/virt-manager/virtconv/__init__.py", line 10, in 
from virtconv.formats import VirtConverter
  File "/usr/share/virt-manager/virtconv/formats.py", line 10, in 
from distutils.spawn import find_executable
ModuleNotFoundError: No module named 'distutils.spawn'



signature.asc
Description: OpenPGP digital signature

Bug#919477: acl2 ftbfs on armel, armhf, arm64 and ppc64el

[Camm Maguire]

Greetings, and thanks!  Identified a fix for ppc64el, and see the issue
with armel, but can see none on armhf or arm64.  Am I missing something?

Take care,

Matthias Klose  writes:

> Package: src:acl2
> Version: 8.0dfsg-1
> Severity: serious
> Tags: sid buster
>
> acl2 ftbfs on armel, armhf, arm64 and ppc64el.
>
> https://buildd.debian.org/status/fetch.php?pkg=acl2=armel=8.0dfsg-1=1515868416=0
>
> and checked that it ftbfs on plummer (ppc64el).
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#919711: openfoam: autopkgtest regression

[Paul Gevers]

Source: openfoam
Version: 1812+dfsg1-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of openfoam the autopkgtest of openfoam fails in
testing when that autopkgtest is run with the binary packages of
openfoam from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
openfoam   from testing1812+dfsg1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. 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=openfoam

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openfoam/1724341/log.gz

autopkgtest [05:11:04]: test icoFoamElbow: [---
--> FOAM FATAL ERROR :
Could not find mandatory etc entry (mode=ugo)
'controlDict'

autopkgtest [05:11:04]: test icoFoamElbow: ---]



signature.asc
Description: OpenPGP digital signature

Bug#919710: blis: baseline violation on armhf and FTBFS on armel

[Adrian Bunk]

Source: blis
Version: 0.5.1-2
Severity: serious
Tags: ftbfs

NEON is not part of the armhf baseline.

Trying to build with NEON and hardfloat ABI causes the FTBFS on armel.

Bug#919709: matrix-synapse: sysvinit startup script bug: python-2

[Peter Gervai]

Package: matrix-synapse
Version: 0.34.1.1-2
Severity: normal

Dear Maintainer,

The startup script properly defined $PYTHON but there is one 'python' call left.
Shall be replaced as well. :-) Otherwise the package cannot start.

get_config_key() { $PYTHON -m synapse.config read "$1" $CONFIGS || return 2 }

Bug#916303: steam: installs to ~/.steam, which is not as intended by upstream

[Simon McVittie]

On Fri, 18 Jan 2019 at 18:55:55 +, Simon McVittie wrote:
> I've updated https://salsa.debian.org/games-team/steam/merge_requests/1
> to implement that (not tested yet); corresponding patch attached.
> I hope that seems OK to you?
> 
> Before merging I'll make sure it does the right thing in a user account
> that previously had the ~/.local/share/Steam setup, a user account that
> previously had the ~/.steam setup, and a new user account.

Yes, this seems to work as intended in all those situations.

* previously had STEAMDIR = ~/.steam (as set up by 1.0.0.56 Debian
  package): continues to use it

* previously had STEAMDIR = ~/.local/share/Steam (as set up by Valve's
  packages): continues to use that

* previously had no ~/.steam at all (new user account): installs with
  STEAMDIR = ~/.steam/debian-installation

smcv

Bug#919708: libglusterfs-dev: missing Depends: libacl1-dev

[Helmut Grohne]

Package: libglusterfs-dev
Version: 5.3-1
File: /usr/include/glusterfs/api/glfs.h
Severity: serious
Justification: missing dependency
Control: affects -1 + src:libvirt

When comping a file that includes /usr/include/glusterfs/api/glfs.h, one
gets:

/usr/include/glusterfs/api/glfs.h:46:10: fatal error: sys/acl.h: No such file 
or directory
 #include 
  ^~~

Clearly, libglusterfs-dev must depend on libacl1-dev.

I guess the libacl1-dev dependency can be dropped from glusterfs-common
then.

Helmut

Bug#914788: Please don't enable getty services for tty devices that don't exist

[Andras Korn]

On Wed, Nov 28, 2018 at 06:47:59PM +, Dmitry Bogatov wrote:

Hi,

sorry, didn't look at bug mail for a while.

> > However, whenever the getty-run package is installed in a vserver, I have to
> > manually remove the /service/getty-tty* symlinks.
> >
> > Can you please modify the postinst script so it only installs getty services
> > for /dev/tty* devices that are actually there?
> 
> I do not like maintainer scripts. They are pain to get right.  I can
> propose you to pre-provision your servers with
> `/etc/sv/getty{1-6}-run/down' file. See runsv(8).

That would still leave the runsv processes around and clutter the output of
"sv status /service/*".

The following postinst snippet should work:

export NAME='getty-tty1'
if [ -c /dev/tty1 ]; then
export ENABLE='yes'
else
export ENABLE='no'
fi

# Unlike postrm, I can be sure, that runit-helper is present on
# postinst.
/lib/runit-helper/runit-helper postinst "$@"

... and so on for the other ttys. (A lesser man would have used a for loop. :)

(Alternatively, the getty run scripts could start with something like this:

[ -c /dev/ttyX ] || rm /etc/service/getty-ttyX

and /etc/runit/1 could re-create these symlinks, just to be absolutely sure.

I don't like this approach; there is too much going on automatically.)

Or, you could add a debconf question with low priority, defaulting to "yes",
on whether to add the getty service symlinks. I could pre-seed debconf in
vservers with "no".

> > Or can we come up with a way to help people avoid shooting themselves in the
> > foot while not requiring me to install getty-run in vservers? For example,
> > runit-init could depend on "getty-run | some-way-to-log-in-interactively",
> > and "some-way-to-log-in-interactively" could be provided by an empty
> > "runit-no-getty" package as well as an "ssh-run" package that sets up a
> > runit service for ssh.
> 
> If it would help you, I can add dependency on 'getty-run | access-run'.
> You are free to provide `access-run' in whatever way you like.

That would work for me if you also build a "runit-no-getty" or similar
(empty) package that provides "access-run". It should be in Debian; we
shouldn't force every container user to build their own fake empty
"access-run" package.

> I am fine with `bin:unsafe-no-tty-run' package too, but not now. I do not
> want to get stuck in NEW before freeze.

Sure, it can wait until the freeze starts. (I almost always use sid anyway.)

Thanks!

András

-- 
  What is life but a sexually transmitted disease with a 100% mortality rate?

Bug#919706: RM: linux-signed/experimental -- obsolete

[Ben Hutchings]

On Fri, 2019-01-18 at 11:21 -0800, Ryan Tandy wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> I noticed that #915367 was closed by removing one binary package from 
> experimental. However, the source package linux-signed/5 and the rest of 
> its binaries are still there.
> 
> linux-signed was removed from unstable in 2017 (#862902). Please 
> consider removing it from experimental as well.
> 
> Maintainers are CCed for their input.

Yes, this "experiment" is over. :-)

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.




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

Bug#919207: squashfs-tools: Please apply frag_deflator_thread removal patch

[Chris Lamb]

László Böszörményi wrote:

> > From: Alexander Couzens 
> > Date: Tue, 8 Jan 2019 10:57:00 +0100
> > Subject: remove frag_deflator_thread
> [...]
>  I've applied this and uploaded to -10, but it breaks lzo compression.

Oh dear, I'm really sorry about that. Updated patch attached, with
the interdiff being:

 frag_deflator_thread compress fragments.
 Replace the deflator_thread with a function and
 use the function instead of the to_frag queue.
+
+Updated Fri, 18 Jan 2019 19:22:58 + by Chris Lamb  to
+fix issue with lack of compressor initialisation affecting (at least) LZO
+compression.
 ---
  
@@ -71,11 +75,11 @@ index 62888ec..465f9fe 100644
 +void frag_deflator(struct file_buffer *file_buffer)
  {
 -  void *stream = NULL;
--  int res;
--
--  res = compressor_init(comp, , block_size, 1);
--  if(res)
--  BAD_ERROR("frag_deflator:: compressor_init failed\n");
+   int res;
+ 
+   res = compressor_init(comp, , block_size, 1);
+   if(res)
+   BAD_ERROR("frag_deflator:: compressor_init failed\n");


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-
From: Alexander Couzens 
Date: Tue, 8 Jan 2019 10:57:00 +0100
Subject: remove frag_deflator_thread

frag_deflator_thread compress fragments.
Replace the deflator_thread with a function and
use the function instead of the to_frag queue.

Updated Fri, 18 Jan 2019 19:22:58 + by Chris Lamb  to
fix issue with lack of compressor initialisation affecting (at least) LZO
compression.
---
 squashfs-tools/info.c   |  5 
 squashfs-tools/mksquashfs.c | 71 +
 squashfs-tools/mksquashfs.h |  2 +-
 squashfs-tools/restore.c| 15 ++
 4 files changed, 30 insertions(+), 63 deletions(-)

diff --git a/squashfs-tools/info.c b/squashfs-tools/info.c
index 7968c77..028d578 100644
--- a/squashfs-tools/info.c
+++ b/squashfs-tools/info.c
@@ -96,11 +96,6 @@ void dump_state()
 	printf("compressed block queue (deflate thread(s) -> main thread)\n");
 	dump_seq_queue(to_main, 0);
 
-	printf("uncompressed packed fragment queue (main thread -> fragment"
-		" deflate thread(s))\n");
-	dump_queue(to_frag);
-
-
 	printf("locked frag queue (compressed frags waiting while multi-block"
 		" file is written)\n");
 	dump_queue(locked_fragment);
diff --git a/squashfs-tools/mksquashfs.c b/squashfs-tools/mksquashfs.c
index 62888ec..09fb68a 100644
--- a/squashfs-tools/mksquashfs.c
+++ b/squashfs-tools/mksquashfs.c
@@ -260,10 +260,10 @@ unsigned int sid_count = 0, suid_count = 0, sguid_count = 0;
 struct cache *reader_buffer, *fragment_buffer, *reserve_cache;
 struct cache *bwriter_buffer, *fwriter_buffer;
 struct queue *to_reader, *to_deflate, *to_writer, *from_writer,
-	*to_frag, *locked_fragment, *to_process_frag;
+	*locked_fragment, *to_process_frag;
 struct seq_queue *to_main;
 pthread_t reader_thread, writer_thread, main_thread;
-pthread_t *deflator_thread, *frag_deflator_thread, *frag_thread;
+pthread_t *deflator_thread, *frag_thread;
 pthread_t *restore_thread = NULL;
 pthread_mutex_t	fragment_mutex = PTHREAD_MUTEX_INITIALIZER;
 pthread_mutex_t	pos_mutex = PTHREAD_MUTEX_INITIALIZER;
@@ -309,7 +309,7 @@ struct dir_info *scan1_opendir(char *pathname, char *subpath, int depth);
 void write_filesystem_tables(struct squashfs_super_block *sBlk, int nopad);
 unsigned short get_checksum_mem(char *buff, int bytes);
 void check_usable_phys_mem(int total_mem);
-
+void frag_deflator(struct file_buffer *file_buffer);
 
 void prep_exit()
 {
@@ -1551,7 +1551,7 @@ void write_fragment(struct file_buffer *fragment)
 	pthread_mutex_lock(_mutex);
 	fragment_table[fragment->block].unused = 0;
 	fragments_outstanding ++;
-	queue_put(to_frag, fragment);
+	frag_deflator(fragment);
 	pthread_cleanup_pop(1);
 }
 
@@ -2423,51 +2423,39 @@ void *deflator(void *arg)
 }
 
 
-void *frag_deflator(void *arg)
+void frag_deflator(struct file_buffer *file_buffer)
 {
-	void *stream = NULL;
 	int res;
 
 	res = compressor_init(comp, , block_size, 1);
 	if(res)
 		BAD_ERROR("frag_deflator:: compressor_init failed\n");
 
-	pthread_cleanup_push((void *) pthread_mutex_unlock, _mutex);
-
-	while(1) {
-		int c_byte, compressed_size;
-		struct file_buffer *file_buffer = queue_get(to_frag);
-		struct file_buffer *write_buffer =
+	int c_byte, compressed_size;
+	struct file_buffer *write_buffer =
 			cache_get(fwriter_buffer, file_buffer->block);
 
-		c_byte = mangle2(stream, write_buffer->data, file_buffer->data,
-			file_buffer->size, block_size, noF, 1);
-		compressed_size = SQUASHFS_COMPRESSED_SIZE_BLOCK(c_byte);
-		write_buffer->size = compressed_size;
-		pthread_mutex_lock(_mutex);
-		if(fragments_locked == FALSE) {
-			fragment_table[file_buffer->block].size = c_byte;
-			fragment_table[file_buffer->block].start_block = bytes;
-			write_buffer->block = bytes;
-			bytes += 

Bug#919707: matrix-synapse: Missing depends

[Kurt Roeckx]

Package: matrix-synapse
Version: 0.34.1.1-2
Severity: serious

Hi,

When installing the version in stretch-backports, I get:
-- Unit matrix-synapse.service has begun starting up.
Jan 18 19:07:18 mirror python3[25438]: ERROR:root:Needed pymacaroons>=0.9.3, 
got pymacaroons==0.9.2
Jan 18 19:07:18 mirror python3[25438]: ERROR:root:Needed msgpack>=0.4.2 but it 
was not installed
Jan 18 19:07:18 mirror python3[25438]: ERROR:root:Needed Jinja2>=2.9 but it was 
not installed
Jan 18 19:07:18 mirror python3[25438]: Missing Requirements: 
python3-pymacaroons>=0.9.3, python3-msgpack>=0.4.2, python3-Jinja2>=2.9, 
python3-Jinja2>=2.9
Jan 18 19:07:18 mirror python3[25438]: To install run:
Jan 18 19:07:18 mirror python3[25438]: sudo apt install 
python3-pymacaroons>=0.9.3 python3-msgpack>=0.4.2 python3-Jinja2>=2.9 
python3-Jinja2>=2.9
Jan 18 19:07:18 mirror systemd[1]: matrix-synapse.service: Control process 
exited, code=exited status=1
Jan 18 19:07:18 mirror systemd[1]: Failed to start Synapse Matrix homeserver.

So something is missing versioned dependencies on those 3 packages.

python3-pymacaroons and python3-msgpack are available in
stretch-backports, but python3-jinja2 isn't.


Kurt

Bug#919706: RM: linux-signed/experimental -- obsolete

[Ryan Tandy]

Package: ftp.debian.org
Severity: normal

I noticed that #915367 was closed by removing one binary package from 
experimental. However, the source package linux-signed/5 and the rest of 
its binaries are still there.


linux-signed was removed from unstable in 2017 (#862902). Please 
consider removing it from experimental as well.


Maintainers are CCed for their input.

Bug#918925: i3: Status and title bar text do not appear with default config file

[Leo Singer]

Package: i3
Version: 4.16-1
Followup-For: Bug #918925

Actually, removing the 'pango:' string from the font option is just causing
it to fall back to the fixed-width X core font.

I tried using a handful of other fonts, such as:

font pango:Bistream Vera Sans Mono 8

And it turns out that the title and status bar text are missing for *any* pango
font option.

I looked through ~/.xsession-errors and I did not see any font-related errors.

[libi3] ../../i3-wm-4.16/libi3/font.c Using Pango font monospace, size 8
01/18/19 14:13:30 - dpi.c:init_dpi:41 - Resource Xft.dpi not specified, 
skipping.
01/18/19 14:13:30 - dpi.c:init_dpi:64 - Using fallback for calculating DPI.
01/18/19 14:13:30 - dpi.c:init_dpi:66 - Using dpi = 96
01/18/19 14:13:30 - main.c:main:561 - root_depth = 32, visual_id = 
0x0077.
01/18/19 14:13:30 - main.c:main:563 - root_screen->height_in_pixels = 1080, 
root_screen->height_in_millimeters = 285
01/18/19 14:13:30 - main.c:main:564 - One logical pixel corresponds to 1 
physical pixels on this display.

Bug#919356: [PATCH] Add missing licensing info

[Domenico Andreoli]

On Fri, Jan 18, 2019 at 03:45:03PM -0200, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 18, 2019 at 06:30:38PM +0100, Domenico Andreoli escreveu:
> > From: Domenico Andreoli 
> > 
> > Hi Arnaldo,
> > 
> >   I noticed that some files of pahole come without licensing and
> > copyright information, this makes Debian struggle with the redistribution
> > and, unfortunately, puts the inclusion of pahole into coming release
> > at risk.
> > 
> > For your convenience, I attached a patch that adds the info where
> > missing and also adopts the SPDX notation.
> 
> Thanks, I've added the fb team involved in recent changes to this
> package so that they are aware of it and can voice any concern, folks
> anything to say about this? Is everything okay?
> 
> I'm tentatively adding this to my repo, hope to tag 1.13 soon.

Excellent!

Would be also nice to have the COPYING file to cover every other file
without explicit copyright.

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#919356: [PATCH] Add missing licensing info

[Martin Lau]

On Fri, Jan 18, 2019 at 03:45:03PM -0200, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 18, 2019 at 06:30:38PM +0100, Domenico Andreoli escreveu:
> > From: Domenico Andreoli 
> > 
> > Hi Arnaldo,
> > 
> >   I noticed that some files of pahole come without licensing and
> > copyright information, this makes Debian struggle with the redistribution
> > and, unfortunately, puts the inclusion of pahole into coming release
> > at risk.
> > 
> > For your convenience, I attached a patch that adds the info where
> > missing and also adopts the SPDX notation.
> 
> Thanks, I've added the fb team involved in recent changes to this
> package so that they are aware of it and can voice any concern, folks
> anything to say about this? Is everything okay?
No concern on adding the SPDX notation.
I would like to add my employer to a few btf files:

+ Copyright (c) 2018 Facebook

> >  btf_encoder.c|  6 ++
> >  btf_encoder.h|  5 +
> >  libbtf.c |  6 ++
> >  libbtf.h |  6 ++
> >  libctf.c |  6 ++

Thanks!
Martin