Bug#854439: also required for npm 5.x and yarnpkg

[Paolo Greppi]

Hi, this ITP has been idle for some time, now this module would also be is also 
required for npm 5.x and yarnpkg:
https://wiki.debian.org/Javascript/Nodejs/Tasks/npm
https://wiki.debian.org/Javascript/Nodejs/Tasks/yarn

I have seen you have already done some work on version 1.1.2 here:
https://anonscm.debian.org/cgit/pkg-javascript/node-sort-keys.git
but in the meantime upstream has release v 2.0.0

Do you plan to complete this package in the near future ?
Or should I take ownership of the ITP ?

Many thanks, Paolo

Bug#886742: postgresql-9.4-postgis-2.1 missing in stretch

[Jürgen Fuchsberger]

On 2018-01-09 18:18, Sebastiaan Couwenberg wrote:
> severity 886742 normal
> thanks
> 
> Hi Juergen,
> 
> On 01/09/2018 02:16 PM, Bas Couwenberg wrote:
>> On 2018-01-09 14:08, Christoph Berg wrote:
>>> Re: Juergen Fuchsberger 2018-01-09
 Due to missing postgresql-9.4-postgis-2.1 in stretch, a postgis enabled
 database becomes corrupt when upgrading from jessie to stretch since
 the required postgis libraries are missing. This can cause serious data
 loss, because once upgraded to stretch, the postgis data can't be
 accesed nor dumped (Database gives error "could not access file
 "$libdir/postgis-2.1": no such file or directory").
> 
> The database is not corrupt, your old database still works (after
> installing the old postgis).

Sure, but I can't install the old postgis-2.1 because it is not
available in stretch.

I think the problem is that postgis-2.1 was removed on updating which
should not be the case, should it?

Best,
Juergen

Bug#886093: searx: Fails to start when using Python 3

[Johannes Schauer]

Control: severity -1 normal
Control: tags -1 + unreproducible

On Tue, 2 Jan 2018 11:21:31 +0530 Joseph Nuthalapati  
wrote:
> SearX currently doesn't start up when run with Python 3 as it tries to parse
> the settings.yml file with ASCII codecs. The file has a list of languages
> which are in Unicode characters.

Please provide more proof of your claim.

I have the package installed on a live server. Please find the output of $(dpkg
-l | grep py) at the bottom of this email. You will find that I don't even have
python 2 installed. Thus, searx will definitely run using Python3. Still, I am
unable to reproduce your findings.

The package even Depends on Python3. I don't see any reason why the package
would use Python2 when deployed.

Another proof that this package works fine with Python3 is the continuous
integration data gathered for this package. The package contains an autopkgtest
test which is run regularly on Debian infrastructure and which checks whether
the front page of searx loads successfully.

You can see here what the test script does:

https://sources.debian.org/src/searx/0.13.1+dfsg1-3/debian/tests/general/

You can see here that the test passes:

https://ci.debian.net/packages/s/searx/unstable/amd64/

You can see in the data of the latest test, that *only* python3 packages were
installed:

https://ci.debian.net/data/packages/unstable/amd64/s/searx/20180109_160457.log
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/searx/20180109_160457/log.gz

Thus, there is no way that searx on my own live system or on the CI system
could possibly run with Python2 and not with Python3.

Please provide more support for your theory.

Thanks!

cheers, josch





$ dpkg -l | grep py
ii  dh-python   2.20170125  all  
Debian helper tools for packaging Python libraries and applications
ii  libpython3-stdlib:amd64 3.5.3-1 amd64
interactive high-level object-oriented language (default python3 version)
rc  libpython3.4:amd64  3.4.2-1 amd64
Shared Python runtime library (version 3.4)
rc  libpython3.4-minimal:amd64  3.4.2-1 amd64
Minimal subset of the Python language (version 3.4)
ii  libpython3.5:amd64  3.5.3-1 amd64
Shared Python runtime library (version 3.5)
ii  libpython3.5-minimal:amd64  3.5.3-1 amd64
Minimal subset of the Python language (version 3.5)
ii  libpython3.5-stdlib:amd64   3.5.3-1 amd64
Interactive high-level object-oriented language (standard library, version 3.5)
ii  python-apt-common   1.4.0~beta3 all  
Python interface to libapt-pkg (locales)
ii  python-babel-localedata 2.3.4+dfsg.1-2  all  
tools for internationalizing Python applications - locale data files
ii  python3 3.5.3-1 amd64
interactive high-level object-oriented language (default python3 version)
ii  python3-apt 1.4.0~beta3 amd64
Python 3 interface to libapt-pkg
ii  python3-babel   2.3.4+dfsg.1-2  all  
tools for internationalizing Python applications - Python 3.x
ii  python3-certifi 2016.2.28-1 all  
root certificates for validating SSL certs and verifying TLS hosts (python3)
ii  python3-cffi-backend1.9.1-2 amd64
Foreign Function Interface for Python 3 calling C code - runtime
ii  python3-chardet 2.3.0-2 all  
universal character encoding detector for Python3
ii  python3-click   6.6-1   all  
Simple wrapper around optparse for powerful command line utilities - Python 3.x
ii  python3-colorama0.3.7-1 all  
Cross-platform colored terminal text in Python - Python 3.x
ii  python3-cryptography1.7.1-2 amd64
Python library exposing cryptographic recipes and primitives (Python 3)
ii  python3-dateutil2.5.3-2 all  
powerful extensions to the standard datetime module
ii  python3-flask   0.12-1  all  
micro web framework based on Werkzeug and Jinja2 - Python 3.x
ii  python3-flask-babel 0.11.1-1all  
internationalization and localization support for Flask (Python 3)
ii  python3-idna2.2-1   all  
Python IDNA2008 (RFC 5891) handling (Python 3)
ii  python3-itsdangerous0.24+dfsg1-2all  
Various helpers to pass trusted data to untrusted environment - Python 3.x
ii  python3-jinja2  2.8-1   all  
small but fa

Bug#885010: python-ldap: Incomplete debian/copyright?

[Willem van den Akker]

On Fri, 22 Dec 2017 20:58:39 + Chris Lamb  wrote:
> Source: python-ldap
> Version: 3.0.0~b3-1
> Severity: serious
> Justication: Policy 12.5
> X-Debbugs-CC: Willem van den Akker 
> 
> Hi,
> 
> I just ACCEPTed python-ldap from NEW but noticed it was missing 
> attribution in debian/copyright for at least the code copy of
> shutil.which in Lib/ldap/compat.py.
> 
> (This is not exhaustive so please check over the entire package 
> carefully and address these on your next upload.)
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
> 
> 

Chris,

What is the best way to add those embedded source files?
Is the next entry in debian/config sufficient?

Files: Lib/ldap/compat.py
Comment: shutil.py is embedded in compat.py and has its own
 copyright.
Copyright: Python-ldap project
License: Python

/Willem

Bug#865588: [Python-modules-team] Bug#865588: Bug#865588: djangorestframework FTBFS with Django 1.11: ERROR collecting tests/test_fields.py

[Brian May]

Thijs Kinkhorst  writes:

> We're half a year on, so has this now changed? (I tried to check out the
> git repo and build it, but that had several problems so I might be missing
> one or two pieces to quickly verify it).

I believe Antonio has been looking at fixing the dependancies. I CCed him.

Possibly there are errors in the git packaging that need to be fixed. I
stopped as soon as I encountered problems, because I did not have the
time to fix them.
-- 
Brian May 

Bug#854479: laptop-mode-tools: With 1.71-1 boot to readonly filesystem if on battery

[Ritesh Raj Sarraf]

On Wed, 2018-01-10 at 06:46 +0900, Kubo Hiroshi wrote:
> Hi Raj,
> 
> Thank you for your response.
> 
> Please grep the log I sent with the keyword 'cupsd'.
> You can find the records like:
> 
> Jan 05 20:55:39 gingitsune cupsd[7047]: Unable to change
> ownership of "/var/log/cups" - Read-only file system
> 
> And here is the /etc/fstab attached.
> The root file system is in /dev/sda1, a plain old HDD partition.
> The problem occured without any USB disks.

THanks. Your /etc/fstab is pretty standard, so there's nothing
susceptible there.

Can you confirm the other question?

Does changing to following in /lib/udev/rules.d/99-laptop-mode.rules
help ?

ACTION=="add", SUBSYSTEM=="usb", RUN+="lmt-udev auto"


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

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

Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead

[Chris Lamb]

tags 886736 + pending
thanks

Cool. Should be fixed in Git...

  
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=59dc18184ea11f3efc0236acb914e6355e8493ad


Regards,

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

Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead

[Mike Hommey]

On Wed, Jan 10, 2018 at 10:36:02AM +0530, Chris Lamb wrote:
> Mike Hommey wrote:
> 
> > The two builds I was comparing:
> 
> […]
> 
> Thanks for sending this over. For some reason, I completely failed to
> realise that I would need access to otool to make use of these, and
> this is not in Debian ;)
> 
> Can you run some commands for me? In particular, is it sufficient to
> fallback to, say, -tdvVQ if -tdvV does not work?

It's enough for me. Although some versions of otool don't support -Q,
and I don't know what they do.

Note you can get otool and other mac tools for linux from
https://github.com/tpoechtrager/cctools-port/

Mike

Bug#886799: openafs-modules-dkms: install fails with compile error "implicit declaration of function 'inode_change_ok'"

[Benjamin Kaduk]

On Tue, Jan 09, 2018 at 02:40:23PM -0800, Adam Lewenberg wrote:
> Package: openafs-modules-dkms
> Version: 1.6.9-2+deb8u4~bpo70+1
> Severity: important
> 
> After upgrading wheezy kernel to 3.2.0-5-amd64 openafs-modules-dkms could not 
> rebuild 
> OpenAFS kernel module.
> 
> Here is the error message:
> 
>  CC [M]  
> /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.o
> /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:
>  In function 'osi_UFSTruncate':
> /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:187:5:
>  error: implicit declaration of function 'inode_change_ok' 
> [-Werror=implicit-function-declaration]

So the security update for meltdown/spectre changed the kernel ABI?
That's kind of unfortunate; usually Ben tries pretty hard to avoid
doing so.

I don't have much of a jessie environment floating around, so it
will probably be a bit before I can track down exactly which patches
to pull in from upstream to address this.  It also looks like an
updated version in -backports is unlikely to help; would you be
interested in a -backports-sloppy as a faster interim option?

Thanks for the report.

-Ben

Bug#882122: thunderbird: Thunderbird can't connect to X server, fails to start

[Phil Dibowitz]

I'm also having this issue. I'm getting apparmor denies:

[Tue Jan  9 00:11:47 2018] audit: type=1400 audit(1515485508.336:33):
apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd"
name="/usr/local/sbin/" pid=1117 comm="ntpd" requested_mask="r"
denied_mask="r" fsuid=0 ouid=0
[Tue Jan  9 00:11:47 2018] audit: type=1400 audit(1515485508.336:34):
apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd"
name="/usr/local/bin/" pid=1117 comm="ntpd" requested_mask="r"
denied_mask="r" fsuid=0 ouid=0
[Tue Jan  9 00:12:10 2018] audit: type=1400 audit(1515485531.381:35):
apparmor="DENIED" operation="file_mmap" profile="thunderbird"
name="/tmp/.glJkpxvk" pid=2413 comm="thunderbird" requested_mask="m"
denied_mask="m" fsuid=1000 ouid=1000
[Tue Jan  9 00:12:10 2018] audit: type=1400 audit(1515485531.381:36):
apparmor="DENIED" operation="file_mmap" profile="thunderbird"
name="/tmp/.glJkpxvk" pid=2413 comm="thunderbird" requested_mask="m"
denied_mask="m" fsuid=1000 ouid=1000
[Tue Jan  9 00:12:10 2018] audit: type=1400 audit(1515485531.381:37):
apparmor="DENIED" operation="mkdir" profile="thunderbird"
name="/home/phil.nv/" pid=2413 comm="thunderbird" requested_mask="c"
denied_mask="c" fsuid=1000 ouid=1000
[Tue Jan  9 00:30:24 2018] audit: type=1400 audit(1515486624.670:38):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4784 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:44 2018] audit: type=1400 audit(1515486644.998:39):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4791 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:46 2018] audit: type=1400 audit(1515486647.522:40):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4794 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:49 2018] audit: type=1400 audit(1515486650.514:41):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4797 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:50 2018] audit: type=1400 audit(1515486650.706:42):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4799 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:50 2018] audit: type=1400 audit(1515486650.874:43):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4801 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:51 2018] audit: type=1400 audit(1515486652.346:44):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4803 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:55 2018] audit: type=1400 audit(1515486655.990:45):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4805 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:55 2018] audit: type=1400 audit(1515486656.202:46):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4807 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:55 2018] audit: type=1400 audit(1515486656.366:47):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4809 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:56 2018] audit: type=1400 audit(1515486656.534:48):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4811 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 00:30:56 2018] audit: type=1400 audit(1515486656.698:49):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/firefox/firefox" pid=4813 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 20:52:40 2018] audit: type=1400 audit(1515559961.993:59):
apparmor="DENIED" operation="open" profile="thunderbird"
name="/proc/modules" pid=26653 comm="thunderbird" requested_mask="r"
denied_mask="r" fsuid=1000 ouid=0
[Tue Jan  9 20:52:40 2018] audit: type=1400 audit(1515559961.997:60):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/bin/nvidia-modprobe" pid=26654 comm="thunderbird"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[Tue Jan  9 20:52:40 2018] audit: type=1400 audit(1515559962.133:61):
apparmor="DENIED" operation="file_mmap"
profile="thunderbird//lsb_release" name="/usr/bin/python3.6" pid=26672
comm="lsb_release" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
[Tue Jan  9 20:52:56 2018] audit: type=1400 audit(1515559977.657:62):
apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg"
name="/usr/share/thunderbird/omni.ja" 

Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead

[Chris Lamb]

Mike Hommey wrote:

> The two builds I was comparing:

[…]

Thanks for sending this over. For some reason, I completely failed to
realise that I would need access to otool to make use of these, and
this is not in Debian ;)

Can you run some commands for me? In particular, is it sufficient to
fallback to, say, -tdvVQ if -tdvV does not work?


Regards,

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

Bug#886810: yubioath-desktop: New upstream release: 4.3.2

[Tristan Seligmann]

Package: yubioath-desktop
Version: 3.0.1-2
Severity: wishlist

There is a new upstream version available.

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

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

Versions of packages yubioath-desktop depends on:
ii  libykpers-1-11.18.0-1
ii  pcscd1.8.23-1
ii  python   2.7.14-4
ii  python-click 6.7-3
ii  python-crypto2.6.1-8
ii  python-pkg-resources 38.2.4-2
ii  python-pyscard   1.9.6-2
ii  python-pyside.qtgui  1.2.2+source1-3
ii  python-pyside.qtnetwork  1.2.2+source1-3

yubioath-desktop recommends no packages.

yubioath-desktop suggests no packages.

-- no debconf information

Bug#856729: evince: Landscape printing doesn't work

[Jason Crain]

Control: forwarded -1 https://bugzilla.gnome.org/792394
Control: tags + confirmed upstream

On Sat, Mar 04, 2017 at 09:28:22PM +0900, Hideki Yamane wrote:
>  When I tried to print document out with landscape mode, it doesn't work.
>  See attached picture.
> 
> 
> Step to reproduce)
> 
>  1. Open landscape documentation with evince
>  2. Select "Print"
>  3. Select "Page Setup"
>  4. Select "Landscacpe" in "Orientation"
>  5. Print out
> 

I've forwarded this upstream with a patch.  I think you must have both
the "Auto Rotate and Center" and "Select page size using document page
size" options selected in the "Page Handling" page of the Print dialog,
which is causing the orientation to be wrong.  It will likely print
correctly if you deselect the "Select page size" option.

Bug#873468: CUDA 9.0 transition

[Andreas Beckmann]

Hi,

CUDA 9.0 finally reached experimental. Did someone get around testing
it, yet?

I'd like to start the transition soon. There are only two rdepends left
in testing (and going to be autorm'ed in 5 days) - both pycuda and
hwloc-contrib seem to be (manually) binNMUable.
I didn't test the other rdepends that are in sid only. But they will
need sourceful uploads anyway for switching the compiler (to gcc-6/g++-6
- not the default, but the best we can get and still better than clang-3.x).


Andreas

Bug#886808: ITP: retdec-config -- A C++ library and tool for managing RetDec configuration databases.

[Yangfl]

Package: wnpp
Severity: wishlist
Owner: Yangfl 
Control: block 886718 by -1
Control: block -1 by 886758

* Package name: retdec-config
  Version : 1.0
  Upstream Author : Avast Software
* URL : https://github.com/avast-tl/retdec-config
* License : MIT
  Programming Lang: C++
  Description : A general C++ utility library used by various
Avast Threat Labs projects.

A C++ library and tool for managing RetDec configuration databases.

This repository contains the following libraries:

* retdec-config -- library for representing and managing RetDec
configuration databases.

This repository contains the following tools:

* retdec-configtool -- frontend for the retdec-config library.

Bug#886807: gnuradio: QT GUI fails with AttributeError: 'NoneType' object has no attribute 'toByteArray'

[Vasil Velichkov]

Package: gnuradio
Version: 3.7.11-6
Severity: normal

Dear Maintainer,

How to reproduce:

1. File -> New -> QT GUI (Ctrl + N)
2. File -> Save (Ctrl + S)
3. Run -> Execute (F6)

and it fails with

Traceback (most recent call last):
  File "/home/grgsm/test_qt_gui.py", line 96, in 
main()
  File "/home/grgsm/test_qt_gui.py", line 84, in main
tb = top_block_cls()
  File "/home/grgsm/test_qt_gui.py", line 53, in __init__
self.restoreGeometry(self.settings.value("geometry").toByteArray())
AttributeError: 'NoneType' object has no attribute 'toByteArray'

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

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

Versions of packages gnuradio depends on:
ii  libasound21.1.3-5
ii  libboost-atomic1.62.0 1.62.0+dfsg-4+b2
ii  libboost-chrono1.62.0 1.62.0+dfsg-4+b2
ii  libboost-date-time1.62.0  1.62.0+dfsg-4+b2
ii  libboost-filesystem1.62.0 1.62.0+dfsg-4+b2
ii  libboost-program-options1.62.01.62.0+dfsg-4+b2
ii  libboost-regex1.62.0  1.62.0+dfsg-4+b2
ii  libboost-system1.62.0 1.62.0+dfsg-4+b2
ii  libboost-thread1.62.0 1.62.0+dfsg-4+b2
ii  libc6 2.25-5
ii  libcodec2-0.7 0.7-1
ii  libcomedi00.10.2-4+b5
ii  libfftw3-single3  3.3.7-1
ii  libgcc1   1:7.2.0-18
ii  libgnuradio-analog3.7.11  3.7.11-6
ii  libgnuradio-atsc3.7.113.7.11-6
ii  libgnuradio-audio3.7.11   3.7.11-6
ii  libgnuradio-blocks3.7.11  3.7.11-6
ii  libgnuradio-channels3.7.113.7.11-6
ii  libgnuradio-comedi3.7.11  3.7.11-6
ii  libgnuradio-digital3.7.11 3.7.11-6
ii  libgnuradio-dtv3.7.11 3.7.11-6
ii  libgnuradio-fcd3.7.11 3.7.11-6
ii  libgnuradio-fec3.7.11 3.7.11-6
ii  libgnuradio-fft3.7.11 3.7.11-6
ii  libgnuradio-filter3.7.11  3.7.11-6
ii  libgnuradio-noaa3.7.113.7.11-6
ii  libgnuradio-pager3.7.11   3.7.11-6
ii  libgnuradio-pmt3.7.11 3.7.11-6
ii  libgnuradio-qtgui3.7.11   3.7.11-6
ii  libgnuradio-runtime3.7.11 3.7.11-6
ii  libgnuradio-trellis3.7.11 3.7.11-6
ii  libgnuradio-uhd3.7.11 3.7.11-6
ii  libgnuradio-video-sdl3.7.11   3.7.11-6
ii  libgnuradio-vocoder3.7.11 3.7.11-6
ii  libgnuradio-wavelet3.7.11 3.7.11-6
ii  libgnuradio-wxgui3.7.11   3.7.11-6
ii  libgnuradio-zeromq3.7.11  3.7.11-6
ii  libgsl23  2.4+dfsg-6
ii  libgslcblas0  2.4+dfsg-6
ii  libgsm1   1.0.13-4+b2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.10+20150825git1ed50c92~dfsg-5
ii  liblog4cpp5v5 1.1.1-3
ii  libportaudio2 19.6.0-1
ii  libpython2.7  2.7.14-4
ii  libqt5core5a  5.9.2+dfsg-6
ii  libqt5gui55.9.2+dfsg-6
ii  libqt5widgets55.9.2+dfsg-6
ii  libqwt-qt5-6  6.1.2-6
ii  libsdl1.2debian   1.2.15+dfsg2-0.1
ii  libstdc++67.2.0-18
ii  libuhd003.010.002 3.10.2.0-3
ii  libusb-1.0-0  2:1.0.21-2
ii  libvolk1-bin  1.3-2
ii  libvolk1.31.3-2
ii  libzmq5   4.2.3-1+b1
ii  python2.7.14-4
ii  python-cheetah2.4.4-4
ii  python-gtk2   2.24.0-5.1+b1
ii  python-lxml   4.1.0-1
ii  python-numpy  1:1.13.3-2
ii  python-opengl 3.1.0+dfsg-1
ii  python-sip4.19.6+dfsg-1
ii  python-wxgtk3.0   3.0.2.0+dfsg-6
ii  python-zmq16.0.2-2+b1

Versions of packages gnuradio recommends:
ii  gnuradio-dev   3.7.11-6
ii  python-matplotlib  2.0.0+dfsg1-2+b1
ii  python-networkx1.11-2
ii  python-pyqt5   5.9.2+dfsg-1
pn  python-qwt-qt5 
ii  python-scipy   0.19.1-1
ii  python-tk  2.7.14-1
ii  rtl-sdr0.5.3-13
ii  uhd-host   3.10.2.0-3

Versions of packages gnuradio suggests:
ii  gr-fosphor  3.7.0.2.7b6b996-2
ii  gr-osmosdr  0.1.4-14

-- no debconf information

Bug#886806: intel-microcode: New version 20180108 published

[Karl Kornel]

Package: intel-microcode
Version: 3.20171215.1
Severity: grave
Tags: security

Hello!

In the ancient past (last week…), Mr. Holschuh mentioned, “I expect an official 
release from Intel soon, hopefully with updates for everything.”.

Well, it looks like there has been a release!  The data file version is 
20180108.

The microcode download page is 
https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File

--
A. Karl Kornel | System Administrator
Research Computing | Stanford University

Bug#886803: apt: makes unattended-upgrades FTBFS due to changed acquire behaviour

[David Kalnischkies]

Control: reassign -1 unattended-upgrades 0.98

Hi,

On Wed, Jan 10, 2018 at 02:46:05AM +0100, Balint Reczey wrote:
> commit 355e1aceac1dd05c4c7daf3420b09bd860fd169d (HEAD, refs/bisect/bad)

This commit also drops support for "legacy filenames" as a comment was
dubbing them… I wanted to do that in a separate commit, but forgot about
it and then it has fallen through the cracks it seems…


Problem is that your Packages file says:
| Package: test-package
| Architecture: all
| Version: 2.0.test.pkg
| Description-en: test package
| Filename: test-package_2.0_all.deb

The "legacy" filename is the filename mentioned in the Packages file.
The filename apt will use to store a package on disk in its directory is
PKGNAME_VERSION_ARCH.deb, so in your case the filename you use for the
package in archives/ should be test-package_2.0.test.pkg_all.deb.

Usually (and that is actually the only case I was expecting) this is
only a matter with epochs as most repositories don't include the epoch
in the filename (as working with ":" in a filename is fun).


I don't think it is a good idea to bring back support for reading these
legacy filenames as a) apt isn't creating those files & the directory it
reads them from can easily be considered a private interface and b) this
legacy support creates problems for us in super-edgecases like
a test-package available in two repositories in version "0:2.0" and in
version "1:2.0" which both would carry it as "2.0".

I am therefore reassigning to unattended-upgrades and would suggest as
a quickfix to fix either the versionumber or the filename in the test.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#813658: Further progress?

[Hillel Lubman]

Now Debian already ships spice 0.14.0, so with this dependency issue out of the 
way, what else is needed
to enable virgl support in qemu? Should packages be split in some way to 
provide a headless variant for
those who only care about server side qemu usage and don't want many 
dependencies?

Regards,
Hillel Lubman.

Bug#886805: Updating the haskell98-report Uploaders list

[Mattia Rizzolo]

Source: haskell98-report
Version: 20080907-8
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Marco Túlio Gontijo e Silva  has retired, so can't work on
the haskell98-report package anymore (at least with this address).

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

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

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#886804: Updating the haskell-devscripts Uploaders list

[Mattia Rizzolo]

Source: haskell-devscripts
Version: 0.13.3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Marco Túlio Gontijo e Silva  has retired, so can't work on
the haskell-devscripts package anymore (at least with this address).

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

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

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#869994: proposed fix

[Stephen Schmiechen]

Yeah I tend to run several customised instances in lots of locations so
FindBin is less fragile for me and works most like the 'dot' did.
So hopefully it saves someone some time.
Cheers
--turtle

On Mon, Jan 8, 2018 at 12:24 PM, Robert J. Clay  wrote:

> > Greetings all using FindBin and adding the current directory everywhere
> > sql-ledger calls perl should fix the issue in all versions.
>
>I appreciate the example perl script you provided but since it's
> known where the package is installing sql-ledger to, I don't think
> using "FindBin" is necessary.  At least, that's what what I'm assuming
> with the patch I've created for the ITA[1] I've been working on.  I
> originally wrote the patch against sql-ledger 3.0.8 but will be
> updating as necessary for use against the most recent version I
> currently see, which is 3.2.6.
>
>
> --
> Robert J. Clay
> rjc...@gmail.com
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862963
>

Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead

[Mike Hommey]

On Wed, Jan 10, 2018 at 10:42:33AM +0900, Mike Hommey wrote:
> On Wed, Jan 10, 2018 at 10:23:59AM +0900, Mike Hommey wrote:
> > On Tue, Jan 09, 2018 at 01:07:58PM +, Chris Lamb wrote:
> > > Hi Mike,
> > > 
> > > > I only have a very large XUL library... you probably don't want that.
> > > 
> > > Probably not for the testsuite (!) but if you could make it available it
> > > would help with a fix anyway...
> > 
> > The two builds I was comparing:
> > https://queue.taskcluster.net/v1/task/AKmfRsZPQjqkc7ZoBmS2zw/runs/0/artifacts/public/build/target.dmg
> > https://queue.taskcluster.net/v1/task/Hs2lbc9dTFi4eXjwwM26NA/runs/0/artifacts/public/build/target.dmg
> > 
> > The corresponding diff:
> > https://queue.taskcluster.net/v1/task/QRazQl4PQZeuiU81C9PtlA/runs/0/artifacts/public/diff.html
> > 
> > Note that the actual diff you get is:
> > https://queue.taskcluster.net/v1/task/Uhv3G5XUQA6DDFrOhErA9Q/runs/0/artifacts/public/diff.html
> > 
> > which has more differences. Stripping the binaries first gets the first
> > diff. I should probably file another bug about that, those differences
> > show up when comparing nm -a output.
> 
> BTW, since I'm also looking at where those differences are coming from,
> the first one in the first diff is a UUID difference that appears in the
> otool -l output.

And some (all?) differences that are not in the disassembly differences
are visible in `dyldinfo -bind -weak_bind -lazy_bind` output.

Mike

Bug#876424: evince: breaking pages when reading pdf files greater than 500 pages

[Fabián Inostroza]

I'm having a similar problem, the pdf sent by Paulo shows the problem in
page 67, 69, 70, etc.
There are some artifacts in the evince toolbar.

I have attached a simpler pdf file and a screenshot. The file was generated
by Kicad eeschema and is a striped down version of a full schematic, The
schematic contained a hidden png image (scale was zero) and there were no
problems with eeschema. The hidden png was accidental.

Other pdf viewers/editors work fine (TeXworks, Inkscape, LibreOffice Draw,
Firefox), however Libreoffice Draw shows the hidden png image instead of
the schematic frame.

Evince shows the following information when the file is opened from the
command line:

(evince:10204): Gtk-WARNING **: Allocating size to EvSidebar 0x55e47e2636e0
without calling gtk_widget_get_preferred_width/height(). How does the code
know the size to allocate?

(evince:10204): Gtk-WARNING **: drawing failure for widget 'EvView': out of
memory

(evince:10204): Gtk-WARNING **: drawing failure for widget
'GtkScrolledWindow': out of memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'GtkOverlay':
out of memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'GtkBox': out of
memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'GtkPaned': out
of memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'GtkBox': out of
memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'EvWindow': out
of memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'EvView': out of
memory

(evince:10204): Gtk-WARNING **: drawing failure for widget
'GtkScrolledWindow': out of memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'GtkOverlay':
out of memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'GtkBox': out of
memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'GtkPaned': out
of memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'GtkBox': out of
memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'EvWindow': out
of memory

(evince:10204): Gtk-WARNING **: drawing failure for widget 'EvView': out of
memory


test.pdf
Description: Adobe PDF document

Bug#886803: apt: makes unattended-upgrades FTBFS due to changed acquire behaviour

[Balint Reczey]

Package: apt
Version: 1.6~alpha6
Severity: important
Control: affects -1 unattended-upgrades

Dear Maintainers,

Tests of unattended-upgrades started failing with the latest apt update.
https://ci.debian.net/data/autopkgtest/unstable/amd64/u/unattended-upgrades/20180105_155142/log.gz
:
...
Running ./test_remove_unused.py with python3
EE
==
ERROR: test_remove_unused_dependencies (__main__.TestRemoveUnused)
--
Traceback (most recent call last):
  File "./test_remove_unused.py", line 100, in test_remove_unused_dependencies
options, rootdir="./root.unused-deps")
  File 
"/tmp/autopkgtest-lxc.r972p9ul/downtmp/build.b49/src/test/unattended_upgrade.py",
line 1462, in main
sys.exit(1)
SystemExit: 1

==
ERROR: test_remove_unused_dependencies_new_unused_only
(__main__.TestRemoveUnused)
--
Traceback (most recent call last):
  File "./test_remove_unused.py", line 122, in
test_remove_unused_dependencies_new_unused_only
options, rootdir="./root.unused-deps")
  File 
"/tmp/autopkgtest-lxc.r972p9ul/downtmp/build.b49/src/test/unattended_upgrade.py",
line 1462, in main
sys.exit(1)
SystemExit: 1

--
Ran 2 tests in 0.776s

FAILED (errors=2)
An error occurred: '404  Not Found [IP: 91.189.88.162 80]'
The URI 'http://archive.ubuntu.com/ubuntu/test-package_2.0_all.deb'
failed to download, aborting
An error occurred: '404  Not Found [IP: 91.189.88.161 80]'
The URI 'http://archive.ubuntu.com/ubuntu/test-package_2.0_all.deb'
failed to download, aborting
Makefile:6: recipe for target 'check' failed
make: *** [check] Error 1
...

Unattended upgrades uses a pre-prepared apt state in tests in which
already downloaded packages are installed. Those packages don't exist
in the archive and apt did not try to download them, but starting with
the following commit in apt.git apt started looking for them online,
too:

commit 355e1aceac1dd05c4c7daf3420b09bd860fd169d (HEAD, refs/bisect/bad)
Author: David Kalnischkies 
Date:   Fri Oct 27 19:09:45 2017 +0200

implement fallback to alternative URIs for all items

For deb files we always supported falling back from one server to the
other if one failed to download the deb, but that was hardwired in the
handling of this specific item. Moving this alongside the retry
infrastructure we can implement it for all items and allow methods to
use this as well by providing additional URIs in a redirect.

I plan making the tests use local repositories of packages instead of
relying on apt's behavior, but looking for an already downloaded .deb
file online may not be desired from apt either.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead

[Mike Hommey]

On Wed, Jan 10, 2018 at 10:23:59AM +0900, Mike Hommey wrote:
> On Tue, Jan 09, 2018 at 01:07:58PM +, Chris Lamb wrote:
> > Hi Mike,
> > 
> > > I only have a very large XUL library... you probably don't want that.
> > 
> > Probably not for the testsuite (!) but if you could make it available it
> > would help with a fix anyway...
> 
> The two builds I was comparing:
> https://queue.taskcluster.net/v1/task/AKmfRsZPQjqkc7ZoBmS2zw/runs/0/artifacts/public/build/target.dmg
> https://queue.taskcluster.net/v1/task/Hs2lbc9dTFi4eXjwwM26NA/runs/0/artifacts/public/build/target.dmg
> 
> The corresponding diff:
> https://queue.taskcluster.net/v1/task/QRazQl4PQZeuiU81C9PtlA/runs/0/artifacts/public/diff.html
> 
> Note that the actual diff you get is:
> https://queue.taskcluster.net/v1/task/Uhv3G5XUQA6DDFrOhErA9Q/runs/0/artifacts/public/diff.html
> 
> which has more differences. Stripping the binaries first gets the first
> diff. I should probably file another bug about that, those differences
> show up when comparing nm -a output.

BTW, since I'm also looking at where those differences are coming from,
the first one in the first diff is a UUID difference that appears in the
otool -l output.

Mike

Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead

[Mike Hommey]

On Tue, Jan 09, 2018 at 01:07:58PM +, Chris Lamb wrote:
> Hi Mike,
> 
> > I only have a very large XUL library... you probably don't want that.
> 
> Probably not for the testsuite (!) but if you could make it available it
> would help with a fix anyway...

The two builds I was comparing:
https://queue.taskcluster.net/v1/task/AKmfRsZPQjqkc7ZoBmS2zw/runs/0/artifacts/public/build/target.dmg
https://queue.taskcluster.net/v1/task/Hs2lbc9dTFi4eXjwwM26NA/runs/0/artifacts/public/build/target.dmg

The corresponding diff:
https://queue.taskcluster.net/v1/task/QRazQl4PQZeuiU81C9PtlA/runs/0/artifacts/public/diff.html

Note that the actual diff you get is:
https://queue.taskcluster.net/v1/task/Uhv3G5XUQA6DDFrOhErA9Q/runs/0/artifacts/public/diff.html

which has more differences. Stripping the binaries first gets the first
diff. I should probably file another bug about that, those differences
show up when comparing nm -a output.

Mike

Bug#858418: [PKG-Openstack-devel] Bug#858418: Is it possible to release fixed packages now?

[Thomas Goirand]

On 01/09/2018 07:13 PM, Kepi wrote:
> Is it possible to release fixed packages soon?
> 
> This bug is making remote systems unaccessible after reboot, IMHO
> serverity should be critical. I don't think it is acceptable to have
> such bug for more than half year on stable distribution.
> 
> I can confirm that upstream patch mentioned by Nicolas is working.
> 
> Thanks

Hi,

While upstream patch may indeed fix the issue, it still relies on the
SYSTEMCTL_SKIP_REDIRECT systemd internal. Using any of these is in fact
*very wrong* and should never be used in the packaging of any package in
Debian. If you don't trust me, you can attempt asking the systemd
maintainers about this.

For this reason, unfortunately, it is very unlikely that the release
team will accept such a change in the stable release, and they will
likely ask for a better fix.

So, we should come up with a better way to fix the issue, a way that
will be accepted by the release team. According to my own experience, it
is also very unlikely that the release team will accept some new
.service files either, unfortunately.

I'd very happily accept any contribution if it's good enough. Though I
may very much dislike gratuitous comments on how much the work of
current package maintainers is unacceptable, even if I only very
recently started to take care of the OpenVSwitch package (ie: at least 6
months after this bug was opened, and many months after Stretch was
released). So please, Kepi, moderate yourself. FYI, I've been thinking
for a long time about ways to fix this problem, but so far haven't
figure out an acceptable way.

BTW, I don't agree severity should be set to critical. Definition for
critical is:

"makes unrelated software on the system (or the whole system) break, or
causes serious data loss, or introduces a security hole on systems where
you install the package."

Here, only the network as controlled by OpenVSwitch breaks (ie: only
OpenVSwitch breaks), and there's no data loss or security hole. Besides
this, it's not ideal, but it can be worked around by not using
/etc/network/interfaces for configuring OpenVSwitch. There's multiple
ways to achieve that. Yes, it's not ideal, but until we find a
satisfying way (in the eyes of the release team, that is) to fix the
issue, I don't think there's a choice, and that's still a workaround.

Last, is Philippe Latu's solution working? It doesn't feel right to me,
and didn't have time to test it out...

Cheers,

Thomas Goirand (zigo)

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
>> ...  Given the background of build-profiles, I'm very much in
>> favor of introducing the equivalent usage as Gentoo USE flags,
>> which was its main intention! :) It could make Debian a viable
>> source-based distribution to use or base on, could make many of
>> the embedded specific distribution solutions obsolete, ...

Adrian> Who would then implement, maintain and support this in all
Adrian> packages?

No one.  People would implement and test the feature where it was
sufficiently useful to implement and test.  I don't think all of the use
flags combinations are tested in source distributions that have them
today.

Even so, users find those flags useful enough to spend a fair bit of
work on them.

A build profile seems like a great way to express the flag, and like
many things in Debian, the work would fall on those who would benefit
from it.

So, I do support the use of build profiles for use flags.
I also believe there's sufficient utility for downstreams and users to
justify this.

--Sam

Bug#885680: gretl: Depends on unmaintained gtksourceview2 (fwd)

[Allin Cottrell]

On Sat, 30 Dec 2017, Dirk Eddelbuettel wrote:


On 29 December 2017 at 09:58, Riccardo (Jack) Lucchetti wrote:
|
| Using gtksourceview3 is already possible; actually, the default for the
| configure script is to prefer gtk3 over gtk2. Maybe it's just a matter of
| adjusting the debian-specific scripts?

Yes. It's all programmatic. A long time (5 years? 8 years?) ago I had issues
with gtk3 and just froze gretl it at gtk2.  Time to change.


Maybe, though in my opinion gretl is still better served by gtk2 
than gtk3. It's true that gtksourceview2 has not been updated in a 
long time now (though gtk2 itself continues to be updated), but it 
works OK and I'm not aware of any substantial enhancements in 
gtksourceview3 that are relevant for gretl.



 Installation path:  /usr
 Use readline library:   yes
 Use gnuplot for graphs: yes
 Use pdflatex for typesetting:   yes
 Use libgsf for zip/unzip:   no
 sse2 support for RNG:   no
 OpenMP support: yes
 MPI support:yes
 AVX support for arithmetic: no
 Build with GTK version: 3.0
 Build gretl documentation:  no
 Use Lucida fonts:   no
 Build message catalogs: yes
 Build gretl addons: no
 X-12-ARIMA support: yes
 TRAMO/SEATS support:yes
 libR support:   yes
 libsvm support: no
 ODBC support:   yes
 JSON parsing support:   yes
 Experimental audio support: no
 Use xdg-utils in installation:  no

 LAPACK libraries:
   -llapack -lblas -lgfortran

Now type 'make' to build gretl. xdg-utils seems like a low-hanging 
fruit...


If you mean that enabling xdg-utils for installation might be good, 
I'd be careful with that: please check the manual for (e.g.) 
xdg-desktop-menu with its "install" option and ensure that it's 
compatible with your packaging practice. My understanding (which may 
be wrong) is that it will install things under (e.g.) /usr/share 
(which may not be what you want).


Allin Cottrell

Bug#886800: ITP: python-itypes -- Python basic immutable containers types library.

[Pierre-Elliott Bécue]

Le mercredi 10 janvier 2018 à 00:37:18+0100, Pierre-Elliott Bécue a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 
> 
> * Package name: itypes
>   Version : 1.1.0
>   Upstream Author : Tom Christie 
> * URL : https://github.com/tomchristie/itypes
> * License : BSD
>   Programming Lang: Python
>   Description : Python basic immutable containers types library.
> 
> This package provides basic immutable container types for Python.
> 
> Upstream source code is designed for simplicity over performance.
> 
> The classic use case of these is in circumstances where it may result in more
> comprehensible code, or when one wants to create custom types with restricted,
> immutable interfaces.
> 
> This package is a dependency of coreapi, and will be maintained under DPMT
> banner.

https://anonscm.debian.org/git/python-modules/packages/itypes.git

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2


signature.asc
Description: PGP signature

Bug#886802: python-uniconvertor: cannot be installed

[Christoph Anton Mitterer]

Package: python-uniconvertor
Version: 1.1.5-4
Severity: grave
Justification: renders package unusable


Hi.

Since python-imaging is gone now, the package can not longer be installed.

Cheers,
Chris.

Bug#885525: [Pkg-utopia-maintainers] Bug#885525: better log output

[Russell Klopfer]

Sean,

That worked for me too! Thanks a lot. When this patch is finally 
released by gnome, do I need to worry about removing the patch I just 
intalled? Or will apt properly install over top of it?


Thanks agian,

Russell

On Tue, Jan 9, 2018 at 11:13 AM, Laurent Martelli 
 wrote:

On Tue, 9 Jan 2018 01:44:01 -0600 Sean DuBois  wrote:
> Hey Russel,

Thanks Sean, it saved my day :-)

> ```
> apt-get build-dep network-manager-gnome

You need sudo for this one too :

sudo apt-get build-dep network-manager-gnome

Bests,
Laurent

> apt-get source network-manager-gnome
> cd network-manager-applet-1.8.10/debian/patches/
> curl 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=885525;filename=Fix-segfault-on-vpn-connect.patch;msg=59"; 
> Fix-segfault-on-vpn-connect.patch

> echo Fix-segfault-on-vpn-connect.patch >> series
> cd ../..
> dpkg-buildpackage -uc -us
> sudo dpkg -i ../network-manager-gnome_1.8.10-1_amd64.deb
>

--
Laurent Martelli // Service Numérique
Tél : 01 80 48 16 14 / 614

--
To unsubscribe, send mail to 885525-unsubscr...@bugs.debian.org.

Bug#884994: systemd: shutdown does not send its warning messages when time is more than ten minutes

[Michael Biebl]

Am 08.01.2018 um 13:20 schrieb Christoph Pleger:
> Hello,
> 
>>
>> This functionality has been reworked completely based on systemd-logind.
>>
>> Can you please test with a more recent version, like 232 from stable.
> 
> at least, the problem does not occur in this form on a stretch machine,
> though I find it a disadvantage that no warning message is shown earlier
> than ten minutes before the actual shutdown. But from ten minutes and
> less, a warning is shown every minute.

Fwiw, this behaviour makes sense to me.
If you start a scheduled login 2 days in advance, sending a shutdown
message every minute would not be helpful. Restricting that to the last
ten minutes seems reasonable.

How did sysvinit behave in that regard?






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



signature.asc
Description: OpenPGP digital signature

Bug#886801: keepass2: KeePass exists unexpectedly after clicking at the password item with attached file

[Patryk Bęza]

Package: keepass2
Version: 2.37+dfsg-1
Severity: important



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

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

Versions of packages keepass2 depends on:
ii  libgcrypt20  1.8.1-4
ii  libmono-corlib4.5-cil4.6.2.7+dfsg-1
ii  libmono-system-drawing4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-security4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system-windows-forms4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil4.6.2.7+dfsg-1
ii  libmono-system4.0-cil4.6.2.7+dfsg-1
ii  libx11-6 2:1.6.4-3
ii  mono-runtime 4.6.2.7+dfsg-1

Versions of packages keepass2 recommends:
ii  xsel  1.2.0-4

Versions of packages keepass2 suggests:
pn  keepass2-doc  
pn  mono-dmcs 
pn  xdotool   

-- no debconf information

journalctl log after KeePass2 exited unexpectedly:

sty 10 00:36:34 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3800a50 (Attach Fil)
sty 10 00:36:34 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3800a50 (Attach Fil)
sty 10 00:36:39 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3800800 (Add Entry)
sty 10 00:36:39 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3800800 (Add Entry)
sty 10 00:36:39 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3800f2e (Text Encod)
sty 10 00:36:39 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3800f2e (Text Encod)
sty 10 00:36:39 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3800f2e (Text Encod)
sty 10 00:36:41 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3800f2e (Text Encod)
sty 10 00:36:50 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3800015 (keepass.kd)
sty 10 00:37:06 Host google-chrome-unstable.desktop[2195]: 
[2195:2195:0110/003706.403952:ERROR:navigation_entry_screenshot_manager.cc(135)]
 Invalid entry with unique id: 1152
sty 10 00:37:21 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Window 0x38014fa (Edit Entry) sets an MWM hint indicating it isn't resizable, 
but sets min size 104 x 1 and max size 649 x 747; this doesn't make much sense.
sty 10 00:37:21 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Window 0x38014fa (Edit Entry) sets an MWM hint indicating it isn't resizable, 
but sets min size 104 x 1 and max size 649 x 747; this doesn't make much sense.
sty 10 00:37:21 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x38014fa (Edit Entry)
sty 10 00:37:21 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x38014fa (Edit Entry)
sty 10 00:37:37 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3801650 (Edit Entry)
sty 10 00:37:37 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3801650 (Edit Entry)
sty 10 00:37:41 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x38014fa (Edit Entry)
sty 10 00:37:41 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x38014fa (Edit Entry)
sty 10 00:37:44 Host org.gnome.Shell.desktop[1809]: Window manager warning: 
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 
0x3800015 (keepass.kd)

Bug#886800: ITP: python-itypes -- Python basic immutable containers types library.

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: itypes
  Version : 1.1.0
  Upstream Author : Tom Christie 
* URL : https://github.com/tomchristie/itypes
* License : BSD
  Programming Lang: Python
  Description : Python basic immutable containers types library.

This package provides basic immutable container types for Python.

Upstream source code is designed for simplicity over performance.

The classic use case of these is in circumstances where it may result in more
comprehensible code, or when one wants to create custom types with restricted,
immutable interfaces.

This package is a dependency of coreapi, and will be maintained under DPMT
banner.

-- 
PEB

Bug#886799: openafs-modules-dkms: install fails with compile error "implicit declaration of function 'inode_change_ok'"

[Adam Lewenberg]

Package: openafs-modules-dkms
Version: 1.6.9-2+deb8u4~bpo70+1
Severity: important

After upgrading wheezy kernel to 3.2.0-5-amd64 openafs-modules-dkms could not 
rebuild 
OpenAFS kernel module.

Here is the error message:

 CC [M]  
/var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.o
/var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:
 In function 'osi_UFSTruncate':
/var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:187:5:
 error: implicit declaration of function 'inode_change_ok' 
[-Werror=implicit-function-declaration]



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

Kernel: Linux 3.2.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.2.0.3-1.2
ii  libc6-dev  2.13-38+deb7u12
ii  perl   5.14.2-21+deb7u5

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.6.9-2+deb8u4~bpo70+1

openafs-modules-dkms suggests no packages.

-- no debconf information

Bug#886606: RFS: pokemmo-installer/1.4.5-1 [ITP] -- Installer and Launcher for the PokeMMO emulator

[Carlos Donizete Froes]

Hi Tobias,

> Good! But But the license is not a great choice.
> It is not clear if it is acceptable for Debian as free license. I'd recommend
> not to use this license but select one from the sets which have ben cleared as
> DFSG. Why not using also the GPL for it like the rest of the package? This
> would also solve the problem that you did not update d/copyright to reflect 
> the
> license of the images... For details about the FreeArt License see and the
> thread linked within:
> https://wiki.debian.org/DFSGLicenses#Licence_Art_Libre_.28Free_Art_License.29

Withdrawn the FreeArt license in my created logo.

Supplemented in 'd/copyright' about the program.

Thanks!

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

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

Bug#886672: [ddtp] aeolus - german localization

[Martin Eberhard Schauer]

Package descriptions are translated by the DDTP volunteers. Mainly they
use the web GUI at [1].

I' ve pulled it in [2]. Now it needs a review to proceed to the database
and finally to Translation-de.bz2 under [3]. It will take up two weeks
then. In total three reviews are needed. One review is equivalent to one
week without change.

1: http://ddtp2.debian.net/ddtss/index.cgi/xx
2: http://ddtp2.debian.net/ddtss/index.cgi/de/forreview/aeolus?1515537014
3: http://ftp.debian.de/debian/dists/sid/main/i18n/

Bug#886714: Reopen (Was: Re: Bug#886714: marked as done (make[8]: no: Command not found))

[Євгеній Мещеряков]

package coccinelle
found 886714 1.0.6.deb-2
forwarded 886714 https://github.com/coccinelle/coccinelle/issues/130
tags 886714 - pending
tags 886714 + upstream
thanks

My "fix" acually did nothing at all on affected architectures, additionally 
support
for disabling optimizations looks broken.

9 січня 2018 о 21:51 + Debian Bug Tracking System написав(-ла):
> Your message dated Tue, 09 Jan 2018 21:49:33 +
> with message-id 
> and subject line Bug#886714: fixed in coccinelle 1.0.6.deb-2
> has caused the Debian Bug report #886714,
> regarding make[8]: no: Command not found
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 
> -- 
> 886714: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886714
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Tue, 9 Jan 2018 08:45:42 +0100
> From: Mathieu Malaterre 
> To: Debian Bug Tracking System 
> Subject: make[8]: no: Command not found
> 
> Package: coccinelle
> Version: 1.0.6.deb-1
> Severity: important
> User: debian-m...@lists.debian.org
> Usertags: mips mipsel mipsel64
> 
> For some reason coccinelle FTBFS on mips*, it fails with:
> 
> make[8]: Entering directory '/<>/commons'
> /usr/bin/ocamlc -unsafe -I ocamlextra   -c ocamlextra/dumper.mli
> no -unsafe -I ocamlextra   -c commands.ml
> make[8]: no: Command not found
> /usr/bin/ocamlc -unsafe -I ocamlextra   -c common.mli
> Makefile:216: recipe for target 'commands.cmx' failed
> make[8]: *** [commands.cmx] Error 127
> 
> 
> https://buildd.debian.org/status/fetch.php?pkg=coccinelle&arch=mips&ver=1.0.6.deb-1&stamp=1509401643&raw=0

> Date: Tue, 09 Jan 2018 21:49:33 +
> From: Євгеній Мещеряков 
> To: 886714-cl...@bugs.debian.org
> Subject: Bug#886714: fixed in coccinelle 1.0.6.deb-2
> 
> Source: coccinelle
> Source-Version: 1.0.6.deb-2
> 
> We believe that the bug you reported is fixed in the latest version of
> coccinelle, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 886...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Євгеній Мещеряков  (supplier of updated coccinelle package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Tue, 09 Jan 2018 22:03:55 +0100
> Source: coccinelle
> Binary: coccinelle coccinelle-doc
> Architecture: source
> Version: 1.0.6.deb-2
> Distribution: experimental
> Urgency: medium
> Maintainer: Debian OCaml Maintainers 
> Changed-By: Євгеній Мещеряков 
> Description:
>  coccinelle - semantic patching tool for C
>  coccinelle-doc - documentation for coccinelle
> Closes: 886714
> Changes:
>  coccinelle (1.0.6.deb-2) experimental; urgency=medium
>  .
>* Use --enable-opt configure option instead of --enable-release, this 
> should
>  fix FTBFS on some architectures (closes: #886714)
> Checksums-Sha1:
>  6933d0a503041cadabe12927812a9d65f10899ef 2519 coccinelle_1.0.6.deb-2.dsc
>  7113cc4122cc0f0ddd9e73efbbe63d597db6dbdf 9972 
> coccinelle_1.0.6.deb-2.debian.tar.xz
>  e4ea32e453d904cba8d19963c39bda0dd4a54a05 10954 
> coccinelle_1.0.6.deb-2_source.buildinfo
> Checksums-Sha256:
>  89c5405f6e09ce37efed8f0c3a7ef5ab3d9b9fc40a1d93a430502a015de05f34 2519 
> coccinelle_1.0.6.deb-2.dsc
>  4efbaa8a2a2055b14bc77952eaf135133be3d4aaa75ba413b4e7125c925ac0af 9972 
> coccinelle_1.0.6.deb-2.debian.tar.xz
>  a14829ca79eac34434b75cafb74f75e208d0e9611cf3c574d0585b7f22e1a3fc 10954 
> coccinelle_1.0.6.deb-2_source.buildinfo
> Files:
>  f7463ba34cfa8cef379c61997715d13b 2519 devel optional 
> coccinelle_1.0.6.deb-2.dsc
>  cb84a08d912b863c4e85a73689f26fdc 9972 devel optional 
> coccinelle_1.0.6.deb-2.debian.tar.xz
>  cdeffb6255bd6a35865353666274ed63 10954 devel optional 
> coccinelle_1.0.6.deb-2_source.buildinfo
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCAAdFiEErJ1oMWkY5MAmVndnwW2o5/RRuTwFAlpVLo0ACgkQwW2o5/RR
> uTxe5w//U2jOqh7vuxZ1uiE/0xwwY708UE+GUZ9YZbh2zKZ8nnSihcTQph/JYUEf
> m16XD5pQeKHvaWMYx0Y/6Sz+98iS1kDtNn5w8NJbq+51iVVxZhnPGMbCr1+yGCIs
> 6v2ZzAjWOQBN6iLM51AcOI15rNzstH2bEAELFuSOKqBLfpjaCAIqyMwUdTQX5Hou
> KvgbMvn3kAu5HlLzsyPs6kfHkE5HUR0kDl2VO1c5xznCQntYUYY0mCWW0dpsRxso
> U1mLVkIWLT+BZCURo/ur8Q0Zzwq48N6b+igawyCySrf5lP0Blmpo39/jN+95G/DZ
> K2

Bug#884740: RFS: pokemmo/1.4.2-1 [ITP] -- Multiplayer online game based on the Pokemon universe

[Carlos Donizete Froes]

Hi Chris,

> LGTM, although would s/Launcher/launcher/.  Please additionally mention
> in debian/copyright at the top why it's in contrib even though it's kinda
> obvious from the package long description.

Supplemented in 'd/copyright' as follows:

-
Disclaimer:
  PokeMMO Installer assists in downloading, installing and
  maintaining the game client.
  .
  This package is in contrib because it depends on PokeMMO client
  which is non-free.
  .
  The permitted usage of the PokeMMO game client is defined by
  a non-free license. The content of this license can be found in
  the game client after an account's first login or
  at https://pokemmo.eu/tos
-

Withdrawn the FreeArt license in my created logo.

Thanks!

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

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

Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

[Mert Dirik]

Package: sysvinit-utils
Version: 2.88dsf-59.9
Followup-For: Bug #826214

Please forgive my naivety, but simply moving the argument shift part before
sourcing /lib/lsb/init-functions seems to successfully redirect to systemctl.

The only variable leaking to /lib/lsb/init-functions is "script", which can be
easily renamed and namespaced in case of a possible problem.

After patching /lib/init/init-d-script, both /etc/init.d/<...> start and
"service <...> start" shows up correctly in "systemctl status <...>" output.


--- /lib/init/init-d-script.orig2018-01-09 21:25:41.763183856 +
+++ /lib/init/init-d-script 2018-01-09 22:38:48.463185948 +
@@ -5,6 +5,8 @@
 # Depend on lsb-base (>= 3.2-14) to ensure that this file is present
 # and status_of_proc is working.

+script="$1"
+shift
 . /lib/lsb/init-functions

 # PATH should only include /usr/* if it runs after the mountnfs.sh
@@ -154,11 +156,9 @@
 set -x
 fi

-SCRIPTNAME=$1
-scriptbasename="$(basename $1)"
+SCRIPTNAME="$script"
+scriptbasename="$(basename "$script")"
 if [ "$scriptbasename" != "init-d-script" ] ; then
-script="$1"
-shift
 . $script
 else
 exit 0


Is there anything wrong with this approach?



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

Kernel: Linux 4.4.91-mert (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages sysvinit-utils depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  util-linux   2.29.2-1

sysvinit-utils recommends no packages.

sysvinit-utils suggests no packages.

-- no debconf information

Bug#886797: mercurial: Mercurial is not localized

[Mike Hommey]

Package: mercurial
Version: 4.4.1-1
Severity: normal

Dear Maintainer,

I've always wondered why my local builds from the mercurial repository
were localized according to my locale, and not the mercurial package.

I finally looked at it, and it turns out that while the package does
ship the .mo files, they're not installed where mercurial is expecting
them.

$ dpkg -L mercurial-common | grep locale/ja
/usr/share/locale/ja
/usr/share/locale/ja/LC_MESSAGES
/usr/share/locale/ja/LC_MESSAGES/hg.mo

$ strace -f hg --version 2>&1 | grep locale/ja
stat("/usr/share/mercurial/locale/ja_JP.UTF-8/LC_MESSAGES/hg.mo", 
0x7ffebacad250) = -1 ENOENT (No such file or directory)
stat("/usr/share/mercurial/locale/ja_JP/LC_MESSAGES/hg.mo", 0x7ffebacad250) = 
-1 ENOENT (No such file or directory)
stat("/usr/share/mercurial/locale/ja.UTF-8/LC_MESSAGES/hg.mo", 0x7ffebacad250) 
= -1 ENOENT (No such file or directory)
stat("/usr/share/mercurial/locale/ja/LC_MESSAGES/hg.mo", 0x7ffebacad250) = -1 
ENOENT (No such file or directory)

Mike

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

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

Versions of packages mercurial depends on:
ii  libc6 2.26-1
ii  mercurial-common  4.4.1-1
ii  python2.7.14-4
ii  ucf   3.0036

Versions of packages mercurial recommends:
ii  openssh-client  1:7.6p1-2

Versions of packages mercurial suggests:
pn  kdiff3 | kdiff3-qt | kompare | meld | tkcvs | mgdiff  
pn  qct   

-- no debconf information

Bug#886798: libpoppler46: displays empty pages after security update

[Andreas Gösele]

Package: libpoppler46
Version: 0.26.5-2+deb8u2
Severity: important

Dear Maintainer,

after the security update from 0.26.5-2+deb8u1 to 0.26.5-2+deb8u2
programs like okular, xpdf and zathura don't display correctly many
pdf files, showing either blank pages, mostly blank pages or not
displaying certain characters. This concerns files I created myself
and files I downloaded from the internet like:

https://www.uni-heidelberg.de/md/awi/forschung/dp391.pdf

Okular gives many error messages of the type:

okular(18722) PDFGeneratorPopplerDebugFunction: [Poppler] "Error (180512): 
Missing or bad Type3 CharProc entry"

Going back and forth between 0.26.5-2+deb8u1 and 0.26.5-2+deb8u2
clearly show that the error is related to the new version of libpoppler46.

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

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

Versions of packages libpoppler46 depends on:
ii  libc6  2.19-18+deb8u10
ii  libfontconfig1 2.11.0-6.3+deb8u1
ii  libfreetype6   2.5.2-3+deb8u2
ii  libjpeg62-turbo1:1.3.1-12
ii  liblcms2-2 2.6-3+deb8u1
ii  libopenjpeg5   1:1.5.2-3
ii  libpng12-0 1.2.50-2+deb8u3
ii  libstdc++6 4.9.2-10
ii  libtiff5   4.0.3-12.3+deb8u4
ii  multiarch-support  2.19-18+deb8u10

Versions of packages libpoppler46 recommends:
ii  poppler-data  0.4.7-1

libpoppler46 suggests no packages.

-- no debconf information

Bug#869562: uploaded 0.12.4 to unstable

[Hans-Christoph Steiner]

I just uploaded 0.12.4 to unstable.   Please test it and let me know if
it works for you.  Then I'll see about trying to get the update into
stretch.

Bug#884707: apparmor breaks clamdscan

[Sebastian Andrzej Siewior]

On 2018-01-07 14:59:54 [+0100], intrigeri wrote:
> Hi,
Hi,

> Francois Gouget:
> /etc/apparmor.d/usr.sbin.clamd profile, then.
> 
> > So here is my feedback on the current configuration: […]
> 
> Thanks for thinking this through. I'm not knowledgeable with ClamAV so
> I'll stick to general comments and recommendations based on my
> experience maintaining AppArmor support in Debian and Tails.
> I'll leave it to the ClamAV maintainers to decide what they think is
> best for Debian and its users.
> 
> Some more data points for context:
> 
>  * Ubuntu has been shipping this AppArmor profile since April, 2009.

I think we included it on their request.

>  * In the Ubuntu bug tracker I see exactly one AppArmor-related bug:
>https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1659223

this does not look related to this bug.

>  * Since AppArmor has been enabled by default in Debian testing/sid
>(mid-November, 2017) one single user reported a regression caused
>by this change with clamd.
>
> So with my AppArmor in Debian maintainer hat, I would find it
> reasonable if the clamav-daemon maintainers decided to leave it as-is,
> possibly improving a little bit the existing documentation in
> README.Debian to provide better guidance to power-users whose use case
> is not supported by the current AppArmor policy. I'm happy to help
> with the latter part if needed.

So looking at this I think it is just fine. clamd should only access
specific files which includes files from postfix & exim spool
directories. By allowing accessing everything it kind of defeats its
purpose (however I am not sure how that $HOME rule works).
The rules file ends with
| # Site-specific additions and overrides. See local/README for details.
| #include 

Maybe if you could provide some info how to add a local rule to enable
clamd to read everything, that would be nice.

> > * Use 'clamdscan --fdpass'. This completely bypasses the apparmor profile. 
> >   What are the security implications of that? As far as I can tell it's 
It does not completely bypass the the profile because the profile does
not forbid fd-passing. It could :). So clamd it not allowed to open
random files on its own but it can open any file that the user (at the
other end of the socket) is able to.

> >   not possible to reopen an existing fd with different access bits so 
> >   if clamdscan opens the file to be scanned in read-only mode, then clamd 
> >   should not be able to write to it. So why not make --fdpass the default?
>
> I'm not knowledgeable enough wrt. ClamAV to have an informed opinion
> on this idea but I find it interesting :)

If you want to have it used / enabled by default then I could ask
upstream what they do think about it.
From the build logs, fdpassing is supported on linux & kfreebsd so it
should work everywhere within Debian.
 
> Cheers,

Sebastian

Bug#886796: Please package upstream tag sdk-1.0.65.2 (ignore previous 1.0.65 tags)

[Brett Johnson]

Package: vulkan
Severity: normal

Previous 1.0.65.* tags had a bug where the testing "Mock" ICD driver was
partially installed.  This problem has been fixed in upstream 1.0.65.2, so
the packaging won't fail on an unaccounted-for .json file left around in
/etc/icd.d.

-- 
Brett Johnson 

Bug#886795: fuse: doesn't handle 'nofail' flag (useful in fstab)

[Enrico Polesel]

Package: fuse
Version: 2.9.7-1
Severity: normal

Dear Maintainer,

fuse fails if it receives the option 'nofail', in my opinion it should
just ignore that option without failing. Upstream there is already a
fix in commit a83cd72f[1].

It can be reproduced, for example, mounting a bindfs:

> # apt-get install fuse libfuse2 bindfs
> ...
> # mkdir /dir1 /dir2
> # echo "bindfs#/dir1 /dir2 fuse nofail 0 2" >> /etc/fstab
> # mount /dir2
> fuse: unknown option `nofail`

The expected result is a successful mount without any error.

I expect the option 'nofail' to work because it is documented both in
fstab(5) and in systemd.mount(5).


The problem can be fixed applying the upstream patch[1], I attach a
debdiff that does it (using quilt).

A quick workaround with the "bugged" version consists in creating
custom systemd mount units instead of using the fstab file that uses
the "WantedBy" unit install option instead of "RequiredBy".


Some references:

[1] 
https://github.com/libfuse/libfuse/commit/a83cd72f641671b71b8268b1765e449cae071f3e

[2] https://github.com/libfuse/libfuse/issues/211

[3] https://github.com/systemd/systemd/issues/5032


Thank you for you time.

Best regards,
Enrico Polesel


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

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

Versions of packages fuse depends on:
ii  adduser   3.115
ii  libc6 2.24-11+deb9u1
ii  libfuse2  2.9.7-1
ii  mount 2.29.2-1
ii  sed   4.4-1

fuse recommends no packages.

fuse suggests no packages.

-- no debconf information
diff -Nru fuse-2.9.7/debian/changelog fuse-2.9.7/debian/changelog
--- fuse-2.9.7/debian/changelog	2016-06-23 20:54:56.0 +0200
+++ fuse-2.9.7/debian/changelog	2018-01-09 18:40:12.0 +0100
@@ -1,3 +1,10 @@
+fuse (2.9.7-1.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Do not fail if nofail option is passed (from upstream commit a83cd72f6416)
+
+ -- Enrico Polesel   Tue, 09 Jan 2018 18:40:12 +0100
+
 fuse (2.9.7-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru fuse-2.9.7/debian/patches/0007-nofail-option fuse-2.9.7/debian/patches/0007-nofail-option
--- fuse-2.9.7/debian/patches/0007-nofail-option	1970-01-01 01:00:00.0 +0100
+++ fuse-2.9.7/debian/patches/0007-nofail-option	2018-01-09 18:40:12.0 +0100
@@ -0,0 +1,12 @@
+Index: fuse-2.9.7/util/mount.fuse.c
+===
+--- fuse-2.9.7.orig/util/mount.fuse.c
 fuse-2.9.7/util/mount.fuse.c
+@@ -152,6 +152,7 @@ int main(int argc, char *argv[])
+ int ignore = 0;
+ const char *ignore_opts[] = { "",
+ 			  "user",
++			  "nofail",
+ 			  "nouser",
+ 			  "users",
+ 			  "auto",
diff -Nru fuse-2.9.7/debian/patches/series fuse-2.9.7/debian/patches/series
--- fuse-2.9.7/debian/patches/series	2015-06-09 21:41:34.0 +0200
+++ fuse-2.9.7/debian/patches/series	2018-01-09 18:17:51.0 +0100
@@ -4,3 +4,4 @@
 0004-fusermount-manpage.patch
 0005-dlsym.patch
 0006-arm64.patch
+0007-nofail-option


signature.asc
Description: PGP signature

Bug#886794: Annotation processing in Java_Lexer

[Lionel Draghi]

Package: libopentoken6.1-dev
Version: 6.0b-7
Severity: normal

Dear Maintainer,

Java Annotation, that is identifier starting with @, are not processed 
by the current Java_Lexer.


Here is an exemple of Java code :

/**
 * Test class for {@link PetTypeFormatter}
 *
 * @author Colin But
 */
@RunWith(MockitoJUnitRunner.class)
public class PetTypeFormatterTests {

    @Mock
    private PetRepository pets;

    private PetTypeFormatter petTypeFormatter;

    @Before
    public void setup() {
    this.petTypeFormatter = new PetTypeFormatter(pets);
    }
...

}

The Java lexer do not recognize @ character in code.

It's Ok in comments, and so no problem with Javadoc tags, but it raises 
an OpenToken.Syntax_Error exception when met in code.

So, annotations like @Override cause the analysis interruption.

I added a new Annotation_T token to the Java lexer, the patch file is 
joined.


(note that the last part of the patch is my proposal for bug Bug#886507, 
that is the buffer increase).


Best regards,


--

-- Lionel


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

Kernel: Linux 4.14.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libopentoken6.1-dev depends on:
ii  gnat 7
ii  gnat-7   7.2.0-18
ii  libopentoken9.1  6.0b-7

libopentoken6.1-dev recommends no packages.

Versions of packages libopentoken6.1-dev suggests:
ii  libopentoken-doc  6.0b-7

-- no debconf information


--- /usr/share/ada/adainclude/opentoken/java_lexer.ads	2017-08-09 20:52:16.0 +0200
+++ Patch/java_lexer.ads	2018-01-09 22:39:53.919915391 +0100
@@ -40,6 +40,7 @@
 with OpenToken.Recognizer.Separator;
 with OpenToken.Recognizer.String;
 with OpenToken.Token.Enumerated.Analyzer;
+
 package Java_Lexer is
 
-
@@ -116,6 +117,7 @@
   String_T,-- "Any characters except " or \ and escape sequences"
   --  Other tokens
   Identifier_T,
+  Annotation_T,
   EndOfLineComment_T,  -- // to end of line
   EmbeddedComment_T,   -- /* anything (even several lines) */
   Whitespace_T,
@@ -239,6 +241,10 @@
(Allow_Underscores  => False,
 Allow_Signs=> False,
 Allow_Laziness => True)),
+  Annotation_T => Tokenizer.Get
+(OpenToken.Recognizer.Identifier.Get
+   (Start_Chars=> Ada.Strings.Maps.To_Set ('@'),
+Body_Chars => Ada.Strings.Maps.Constants.Alphanumeric_Set)),
   Identifier_T => Tokenizer.Get
 (OpenToken.Recognizer.Identifier.Get
(Start_Chars=> Ada.Strings.Maps.Constants.Letter_Set,
@@ -260,6 +266,7 @@
 (OpenToken.Recognizer.Character_Set.Get (OpenToken.Recognizer.Character_Set.Standard_Whitespace)),
   End_of_File_T=> Tokenizer.Get (OpenToken.Recognizer.End_Of_File.Get));
 
-   Analyzer : constant Tokenizer.Handle := Tokenizer.Initialize (Syntax);
+   Analyzer : constant Tokenizer.Handle := Tokenizer.Initialize (Syntax,
+ Buffer_Size => 8192);
 
 end Java_Lexer;

Bug#886770: Package description still refers to Iceweasel

[Dr. Tobias Quathamer]

control: tag -1 pending

Am 09.01.2018 um 19:31 schrieb Christopher Chavez:
> Package: fonts-lyx
> Version: 2.2.3-2
> Severity: minor
> 
> The long description for the fonts-lyx package still refers to
> Iceweasel as an example of Gecko-based browser. Since Iceweasel is
> discontinued, should this be changed to Firefox instead?

Yes, indeed, thanks for the bug report. I've changed it now; it'll be
resolved with the next upload.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#886793: iptables-save: add reset chains counters and add help

[Alban Vidal]

Package: iptables
Version: 1.6.1-2~bpo9+1
Severity: wishlist
Tags: patch

Dear Maintainers,
 
Please find attached a suggest patch to add functionality in iptables-save.

---

1) Adding -z or --zero option: Reset to zero counters of the chains.

Example whithout:

iptables-save
# Generated by iptables-save v1.6.1 on Tue Jan  9 21:42:51 2018
*nat
:PREROUTING ACCEPT [923:217673]
:INPUT ACCEPT [309:97481]
(...)

Example whith:

iptables-save -z
# Generated by iptables-save v1.6.1 on Tue Jan  9 21:42:26 2018
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
(...)

---

2) Adding -h or --help option: print help/usage (inspired by manpage)

Content:

iptables-save -h
iptables-save and ip6tables-save are provides from iptables package — version 
1.6.1

iptables-save and ip6tables-save are used to dump the contents of IP or IPv6 
Table in easily parseable format to STDOUT. Use I/O-redirection provided by 
your shell to write to a file.

Usage: iptables-save  [-h] [-M modprobe] [-c] [-z] [-t table]
   ip6tables-save [-h] [-M modprobe] [-c] [-z] [-t table]

Options:
Either long or short options are allowed.

  -h, --help
  Print this help usage.

  -M, --modprobe modprobe_program
  Specify the path to the modprobe program. By default, iptables-save will 
inspect /proc/sys/kernel/mod‐probe to determine the executable's path.

  -c, --counters
  Include the current values of all packet and byte counters in the output.

  -z, --zero
  Reset to zero counters of the chains.

  -t, --table tablename
  Restrict output to only one table. If not specified, output includes all 
available tables.

---

3) Layout layout: uppercase, dot...


Best regards,

Alban Vidal

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

Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -pruN a/iptables/ip6tables-save.c b/iptables/ip6tables-save.c
--- a/iptables/ip6tables-save.c 2018-01-09 18:16:41.165710952 +0100
+++ b/iptables/ip6tables-save.c 2018-01-09 21:31:38.547256947 +0100
@@ -3,6 +3,9 @@
  * Original code: iptables-save
  * Authors: Paul 'Rusty' Russel  and
  *  Harald Welte 
+ * Contributor:
+ * (C) 2018 by Alban Vidal 
+ *
  * This code is distributed under the terms of GNU GPL v2
  */
 #include 
@@ -17,17 +20,12 @@
 #include "libiptc/libip6tc.h"
 #include "ip6tables.h"
 #include "ip6tables-multi.h"
+#include "ipXtables-save-common.c" /* Common code for iptables-save.c and 
ip6tables-save.c */
 
 static int show_counters = 0;
 
-static const struct option options[] = {
-   {.name = "counters", .has_arg = false, .val = 'c'},
-   {.name = "dump", .has_arg = false, .val = 'd'},
-   {.name = "table",.has_arg = true,  .val = 't'},
-   {.name = "modprobe", .has_arg = true,  .val = 'M'},
-   {NULL},
-};
-
+/* if = 1 (opt -z): Reset to zero counters of the chains */
+static int rst_chain_counters = 0;
 
 /* Debugging prototype. */
 static int for_each_table(int (*func)(const char *tablename))
@@ -94,7 +92,10 @@ static int do_output(const char *tablena
struct xt_counters count;
printf("%s ",
   ip6tc_get_policy(chain, &count, h));
-   printf("[%llu:%llu]\n", (unsigned long long)count.pcnt, 
(unsigned long long)count.bcnt);
+   if (rst_chain_counters > 0)
+   printf("[0:0]\n"); /* Reset to zero counters of 
the chains */
+   else
+   printf("[%llu:%llu]\n", (unsigned long 
long)count.pcnt, (unsigned long long)count.bcnt);
} else {
printf("- [0:0]\n");
}
@@ -143,7 +144,7 @@ int ip6tables_save_main(int argc, char *
init_extensions6();
 #endif
 
-   while ((c = getopt_long(argc, argv, "bcdt:M:", options, NULL)) != -1) {
+   while ((c = getopt_long(argc, argv, "bhcdzt:M:", options, NULL)) != -1) 
{
switch (c) {
case 'b':
fprintf(stderr, "-b/--binary option is not 
implemented\n");
@@ -151,14 +152,20 @@ int ip6tables_save_main(int argc, char *
case 'c':
show_counters = 1;
break;
-
case 't':
/* Select specific table. */
tablename = optarg;
break;
+   case 'h':
+   /* Print Help and quit */
+

Bug#886672: [ddtp] aeolus - german localization

[Jaromír Mikeš]

2018-01-09 21:31 GMT+01:00 Florian Rehnisch :

> On Tue, Jan 09, 2018 at 01:53:27PM +0100, Jaromír Mikeš wrote:
>

​​Hi Florian,

​Thank you for quick answer.
​I am also cc'ing 886...@bugs.debian.org to keep a record.​



> >
> >there is translation bug filled against aeolus package.
> >Which I am maintaining.
> >
> >[BTS#886672]
> >
> >I am not sure how to deal with this bug.
>
> The bug is in the german package description: "seinen" instead
> of "seinem". AFAIK the translated package descriptions can't
> be fixed for the once release wheezy, jessie, and stretch, but
> someone should fix this for the upcoming buster release and sid.
> Once the later is done, you should IMO close this bug.
>

​How I will know the bug is fixed? Someone will inform me?

Furthermore, for legacy reasons, I adhere to use Guillemets instead
> of German Quotes, as the »« are in the latin1 codepage.
>

​Ok​

>Thank you for help
>
> Hope I was useful,
> ​​
>

​It was.

bestt regads

mira​




​

Bug#854479: laptop-mode-tools: With 1.71-1 boot to readonly filesystem if on battery

[Kubo Hiroshi]

Hi Raj,

Thank you for your response.

Please grep the log I sent with the keyword 'cupsd'.
You can find the records like:

Jan 05 20:55:39 gingitsune cupsd[7047]: Unable to change ownership of 
"/var/log/cups" - Read-only file system

And here is the /etc/fstab attached.
The root file system is in /dev/sda1, a plain old HDD partition.
The problem occured without any USB disks.

--
Hiroshi Kubo 



From: Ritesh Raj Sarraf 
Subject: Re: Bug#854479: laptop-mode-tools: With 1.71-1 boot to readonly 
filesystem if on battery
Date: Tue, 09 Jan 2018 21:08:20 +0530

> On Mon, 2018-01-08 at 23:14 +0900, Kubo Hiroshi wrote:
>> I encontered the same problem with my Panasonic CF-N9 laptop PC,
>> which I installed Debian 9.3 (stretch) with laptop-mode-tools 1.71-2.
>> 
> 
> Can you give me your root fs setup ? Like how you have stacked your
> devices. From your logs, I think you have sda3_crypt as your root
> device. Do you have PV/LV on top of it, though I doubt that ?
> 
> It would help to have a proper configuration detail so that I can try
> to reproduce it in a VM setup. I am running LMT without any issues so
> far.
> 
> To start with, please share the contents of your /etc/fstab
> I'd like to have more logs. Maybe if you can also share details from
> the failed boot about to 'ro' remount. Because I see no kernel logs
> mentioning a remount to 'ro'
> 
> 
> There are 2 reports that are similar to this one.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762018
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1726930
> 
> From what I skimmed from the debian bug report (quite old though),
> systemd expects certain  behaviour. Maybe LMT is not in line with it,
> which I doubt. Because I am running LMT with systemd for so long and
> almost all the time I boot from battery.
> 
> Do you have USB disks attached ? Do you have USB enabled docking
> stations that you mount on, when you see this error ?
> 
> I am sorry but more debug information is needed for this bug report.
> 
> 
> -- 
> Ritesh Raj Sarraf | http://people.debian.org/~rrs
> Debian - The Universal Operating System
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
# / was on /dev/sda1 during installation
UUID=98212517-3502-4d65-8293-c0e08dfc6d0b /   ext4
errors=remount-ro 0   1
/dev/mapper/sda3_crypt /home   ext4defaults0   2
/dev/mapper/sda2_crypt noneswapsw  0   0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0

Bug#886792: Package search engine unusable

[Wolfgang Pfeiffer]

Package: www.debian.org
Severity: important

I tried to use
https://www.debian.org/distrib/packages

to search for the latest linux-image packages. With no luck. At best
I find dbg versions
https://packages.debian.org/search?searchon=contents&keywords=linux-image&mode=filename&suite=stable&arch=any

With google no problem. Search patterns e.g.:
debian linux-image amd64 stable

Thanks.

Regards,
Wolfgang Pfeiffer

Bug#884821: binutils-mipsel-linux-gnu: Can't find matching LO16 reloc against `.text' for R_MIPS_GOT16 at 0x1f8

[Paul Boddie]

On Tuesday 9. January 2018 18.28.52 James Cowgill wrote:
> 
> Thanks for this. I think I know what's going on now.

Thanks for replying and figuring it out from my notes!

[...]

> The problem here is that the assembler and GCC don't agree on whether
> thread2 is a global or local symbol. In GCC you have declared it
> non-static so it thinks it's a global symbol. In the assembler, all
> symbols default to local unless you say otherwise with a .global
> directive. This means that GCC only inserts a GOT16 relocation (no LO16)
> at the call sites of thread2. When the assembler looks at this, it sees
> that thread2 is a local symbol and therefore inserts a GOT16 relocation
> to the .text section in the object file (expecting a LO16 to later fix
> it up). Since there is no LO16 relocation, the linker rightfully 
> complains.
> 
> I guess you could add ".global thread2" to fix this, although I really
> don't know why you can't use C to implement L4UTIL_THREAD_STATIC_FUNC.
> Maybe there's some dark magic going on somewhere in L4re?

As I noted, I think it is perhaps done to avoid generating a few more 
instructions. However, as shown, it is certainly possible to generate 
something reasonable using a C-level function. And as far as I know, it would 
be preferable to do everything in C as well.

Using ".global thread2" suppresses the error, confirming your suspicions. It 
seems that ".internal thread2" is superfluous, at least from the output of 
"readelf -s" on the object both with and without it used in the assembly 
language portion:

30:  0 FUNCGLOBAL INTERNAL1 thread2

I'll let the L4Re developers know about this and try and figure out what the 
reasoning for changing this might have been. As far as I know, this code was 
tested with the Imagination compilers (which also differed in behaviour in 
other ways from GCC), so perhaps they have something to do with this code 
being introduced.

Thanks once again for looking at this!

Paul

Bug#884511: closed by Jonathan Carter (Uploaded)

[Nicholas D Steeves]

On Tue, Jan 09, 2018 at 01:48:04PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the sponsorship-requests package:
> 
> #884511: RFS: memleax/1.1.0-1 [ITP]
> 
> It has been closed by Jonathan Carter .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Jonathan Carter 
>  by
> replying to this email.
> 
> 
> -- 
> 884511: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884511
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Tue, 9 Jan 2018 15:44:56 +0200
> From: Jonathan Carter 
> To: 884511-d...@bugs.debian.org
> Subject: Uploaded
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
>  Thunderbird/52.5.2
> 
> Uploading, should hit NEW shortly.

Thank you Jonathan!

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#886791: ITP: golang-gopkg-macaroon-bakery.v2 -- We bake 'em sweet, we bake 'em nice

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-gopkg-macaroon-bakery.v2
  Version : 0.0~git20171221.21d9e9a-1
  Upstream Author :
* URL : https://github.com/go-macaroon-bakery/macaroon-bakery
* License : LGPL-3.0
  Programming Lang: Go
  Description : We bake 'em sweet, we bake 'em nice

This is needed for lnd

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



signature.asc
Description: OpenPGP digital signature

Bug#886790: ITP: golang-gopkg-macaroon-bakery.v2

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-gopkg-macaroon.v2
  Version : 0.0~git20171017.bed2a42-1
  Upstream Author :
* URL : https://github.com/go-macaroon/macaroon
* License : BSD-3-clause
  Programming Lang: Go
  Description : A native Go implementation of macaroons

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



signature.asc
Description: OpenPGP digital signature

Bug#886789: ITP: python-openapi-codec -- An OpenAPI codec for Core API

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: python-openapi-codec
  Version : 1.3.2
  Upstream Author : Tom Christie 
* URL : https://github.com/core-api/python-openapi-codec
* License : BSD
  Programming Lang: Python
  Description : An OpenAPI codec for Core API

Core API is a format-independent Document Object Model for representing
Web APIs.

It can be used to represent either Schema or Hypermedia responses, and
allows one to interact with an API at the layer of an application
interface, rather than a network interface.

This package provides a third-party codec for core API to support OpenAPI
format.

This package would be maintained under the DPMT sky.

-- 
PEB

Bug#886788: ITP: python-hal-codec -- A HAL codec for Core API

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: python-hal-codec
  Version : 1.0.2
  Upstream Author : Tom Christie 
* URL : https://github.com/core-api/python-hal-codec
* License : BSD
  Programming Lang: Python
  Description : A HAL codec for Core API

Core API is a format-independent Document Object Model for representing
Web APIs.

It can be used to represent either Schema or Hypermedia responses, and
allows one to interact with an API at the layer of an application
interface, rather than a network interface.

This package provides a third-party codec to handle HAL Hypermedia
format.

This package would be maintained unter the DPMT roof.

-- 
PEB

Bug#886714: make[8]: no: Command not found

[Eugeniy Meshcheryakov]

 Hi,

9 січня 2018 о 21:02 +0100 Ralf Treinen написав(-ла):
> Hello,
> 
> On Tue, Jan 09, 2018 at 08:45:42AM +0100, Mathieu Malaterre wrote:
> 
> > For some reason coccinelle FTBFS on mips*, it fails with:
> > 
> > make[8]: Entering directory '/<>/commons'
> > /usr/bin/ocamlc -unsafe -I ocamlextra   -c ocamlextra/dumper.mli
> > no -unsafe -I ocamlextra   -c commands.ml
> > make[8]: no: Command not found
> 
> mips and mipsel are the two architectures among the release architectures
> for which ocaml only provides compilation to bytecode. Without having
> looked into the makefile this smells a lot like a mistake in a test 
> of existence of native-code compilation or not.
You are right, the configure option name was changed so compiler
selection was not working correctly.

> 
> -Ralf.
> 


signature.asc
Description: PGP signature

Bug#886787: ITP: r-cran-whisker -- GNU R mustache, logicless templating

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-whisker
  Version : 0.3-2
  Upstream Author : Edwin de Jonge 
* URL : https://cran.r-project.org/package=whisker
* License : GPL
  Programming Lang: GNU R
  Description : GNU R mustache, logicless templating
 This GNU R package enables logicless templating, reuse templates in many
 programming languages including R.


Remark: This package will be maintained by the r-pkg-team.  Since there
is no list for the packaging team yet the Debian Science maintainers list
is used for the moment.  The repository is
https://salsa.debian.org/r-pkg-team/r-cran-whisker.git

Bug#886786: ITP: python-jsonhyperschema-codec -- A JSON Hyperschema codec for Core API.

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: python-jsonhyperschema-codec
  Version : 1.0.2
  Upstream Author : Tom Christie 
* URL : https://github.com/core-api/python-jsonhyperschema-codec
* License : BSD
  Programming Lang: Python
  Description : A JSON Hyperschema codec for Core API.

Core API is a format-independent Document Object Model for representing
Web APIs.

It can be used to represent either Schema or Hypermedia responses, and
allows one to interact with an API at the layer of an application
interface, rather than a network interface.

This package provides a third-party codec to coreapi in order to allow it
to support jsonhyperschema.

-- 
PEB

Bug#783607: libpoppler: Some contents in some pdf documents seem to be ignored

[Andreas Goesele]

This bug is still present in libpoppler46:amd64 0.26.5-2+deb8u1 and
libpoppler46:amd64 0.26.5-2+deb8u2

Bug#886785: buildd.debian.org: Firefox-esr (security !) upgrade missing some depedencies

[Pavel Mendl]

Package: buildd.debian.org
Severity: important

Dear Maintainer,

I am trying to apply security upgrade to firefox-esr under testing version of 
Debian
(literaly - I do have "testing" instead of exact version in my apt sources).
I had used:
$ sudo aptitude
as I use to each time, when KDE Upgrades asks for package deletions to have 
better control over deletions and their reason.
I got the recommendation to keep pakage in current state, as there are some 
packages firefox depends on reported as UNAVAILABLE,
so I can not continue.

The following is snapshot of relevant page "firefox-esr info" from aptitude:

 Actions  Undo  Package  Resolver  Search  Options  Views  Help
C-T: Menu  ?: Help  q: Quit  u: Update  g: Preview/Download/Install/Remove Pkgs
 Packages   
 firefox-esr info
aptitude 0.8.10 @ mnementh  
   #Broken: 1   Disk: +4 832 kB DL: 46,4 MB
iBA  --\ firefox-esr
+4 832 kB 52.5.0esr-152.5.2esr-1~de
  Description: Mozilla Firefox web browser - Extended Support Release (ESR)
Firefox ESR is a powerful, extensible web browser with support for modern 
web application technologies.
  Tags: interface::x11, role::program, uitoolkit::gtk, web::browser
  Priority: optional
  Section: web
  Maintainer: Maintainers of Mozilla-related packages 

  Architecture: amd64
  Compressed Size: 46,4 M
  Uncompressed Size: 114 M
  Source Package: firefox-esr
  Origin: Debian-Security:9/stable [amd64]
  Origin URI: 
http://security.debian.org/pool/updates/main/f/firefox-esr/firefox-esr_52.5.2esr-1~deb9u1_amd64.deb
  --\ Depends (37)
--- debianutils (>= 1.16)
--- fontconfig
--- libasound2 (>= 1.0.16)
--- libatk1.0-0 (>= 1.12.4)
--- libc6 (>= 2.17)
--- libcairo-gobject2 (>= 1.10.0)
--- libcairo2 (>= 1.10.0)
--- libdbus-1-3 (>= 1.9.14)
--- libdbus-glib-1-2 (>= 0.78)
--- libevent-2.0-5 (>= 2.0.10-stable) (UNAVAILABLE)
--- libffi6 (>= 3.0.4)
--- libfontconfig1 (>= 2.11)
--- libfreetype6 (>= 2.2.1)
--- libgcc1 (>= 1:4.0)
--- libgdk-pixbuf2.0-0 (>= 2.22.0)
--- libglib2.0-0 (>= 2.31.8)
--- libgtk-3-0 (>= 3.0.0)
--- libgtk2.0-0 (>= 2.10)
--- libhunspell-1.4-0 (UNAVAILABLE)
--- libjsoncpp1 (>= 1.7.4)
--- libpango-1.0-0 (>= 1.14.0)
--- libsqlite3-0 (>= 3.7.12-1~)
--- libstartup-notification0 (>= 0.8)
--- libstdc++6 (>= 5.2)
--- libvpx4 (>= 1.6.0)
--- libx11-6
--- libx11-xcb1
--- libxcb-shm0
--- libxcb1
--- libxcomposite1 (>= 1:0.3-1)
--- libxdamage1 (>= 1:1.1)
--- libxext6
--- libxfixes3
--- libxrender1
--- libxt6
--- procps
--- zlib1g (>= 1:1.2.3.4)
  --\ Suggests (5)
--- fonts-lmodern
--- fonts-stix | otf-stix
--- libcanberra0
--- libgssapi-krb5-2 | libkrb53
--- mozplugger (UNSATISFIED)
  --\ Conflicts (6)
--- firefox-esr
--- iceweasel (< 45)
--- iceweasel (< 45)
--- j2re1.4
--- pango-graphite (< 0.9.3)
--- pango-graphite (< 0.9.3)
  --\ Breaks (1)
--- xul-ext-torbutton
  --- Package names provided by firefox-esr (2)
  --- Packages which depend on firefox-esr (405)
  --\ Versions of firefox-esr (2)
idA  52.5.0esr-1 -109 MB
pBA  52.5.2esr-1~deb9u1  +114 MB

The following is snapshot of my /etc/apt/sources.list   

1546/1546  100%
#
# deb cdrom:[Debian GNU/Linux 7.3.0 _Wheezy_ - Official amd64 kde-CD Binary-1 
20131215-04:55]/ wheezy main

deb http://httpredir.debian.org/debian testing main contrib non-free
deb-src http://httpredir.debian.org/debian testing main contrib non-free

deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free

deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free


# - Below are items used before http://http.debian.net/ migration --


#deb ftp://ftp.cz.debian.org/debian/ testing main contrib non-free
#deb-src ftp://ftp.cz.debian.org/debian/ testing main contrib non-free

# deb ftp://ftp.cz.debian.org/debian/ stable main contrib non-free
# deb-src ftp://ftp.cz.debian.org/debian/ stable main contrib non-free

# deb http://ftp.cz.debian.org/debian/ testing main contrib non-free
# deb-src http://ftp.cz.debian.org/debian/ stable main contrib non-free


# deb http://security.debian.org/ testing/updates main contrib non-free
# deb-src http://security.debian.org/ testing/updates main contrib non-free

# deb http://security.debian.org/ stable/updates main contrib non-free
# deb-src http://security.debian.org/ stable/updates main contrib non-free


# te

Bug#886784: linux-image-4.14.0-0.bpo.2-amd64: apparmor blocks libvirtd

[Russell Mosemann]

Package: src:linux
Version: 4.14.7-1~bpo9+1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 
New install of Debian 9.3.0 and linux-image-4.14.0-0.bpo.2-amd64.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 
Starting and stopping a vm.

   * What was the outcome of this action?
 
The vm goes into "in shutdown" mode.
Entries logged to the journal that apparmor is blocking libvirtd.

   * What outcome did you expect instead?
 
vm should shutdown without further ado.
No error messages in the journal.


-- Package-specific info:
** Version:
Linux version 4.14.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18)) #1 SMP Debian 4.14.7-1~bpo9+1 
(2017-12-22)

** Command line:
BOOT_IMAGE=/vmlinuz-4.14.0-0.bpo.2-amd64 
root=UUID=63791703-1366-4bea-bf20-7362e014a07f ro console=tty0 
console=ttyS1,115200n8 quiet

** Not tainted

** Kernel log:
Jan 09 14:32:00 vhost003 audit[5200]: AVC apparmor="DENIED" operation="signal" 
profile="/usr/sbin/libvirtd" pid=5200 comm="libvirtd"
 requested_mask="send" denied_mask="send" signal=term 
peer="libvirt-d8a3cbb0-7b2a-4d72-a266-3ff89e7ca4e7"
Jan 09 14:32:00 vhost003 audit[5200]: AVC apparmor="DENIED" operation="signal" 
profile="libvirt-d8a3cbb0-7b2a-4d72-a266-3ff89e7ca4e7
" pid=5200 comm="libvirtd" requested_mask="receive" denied_mask="receive" 
signal=term peer="/usr/sbin/libvirtd"
 
Jan 09 14:33:40 vhost003 audit[6832]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-d8a3cbb0-7b2a-4d72-a266-3ff89e7ca4e7" 
name="/sys/devices/system/node/" pid=6832 comm="qemu-system-x86" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 09 14:33:40 vhost003 kernel: audit: type=1400 audit(1515530020.960:406): 
apparmor="DENIED" operation="open" 
profile="libvirt-d8a3cbb0-7b2a-4d72-a266-3ff89e7ca4e7" 
name="/sys/devices/system/cpu/" pid=6832 comm="qemu-system-x86" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 09 14:33:40 vhost003 audit[6832]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-d8a3cbb0-7b2a-4d72-a266-3ff89e7ca4e7" 
name="/sys/module/vhost/parameters/max_mem_regions" pid=6832 
comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Jan 09 14:33:41 vhost003 audit[6681]: AVC apparmor="DENIED" operation="ptrace" 
profile="/usr/sbin/libvirtd" pid=6681 comm="libvirtd" requested_mask="trace" 
denied_mask="trace" peer="libvirt-d8a3cbb0-7b2a-4d72-a266-3ff89e7ca4e7"


** Model information
sys_vendor: To Be Filled By O.E.M.
product_name: To Be Filled By O.E.M.
product_version: To Be Filled By O.E.M.
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: P2.30
board_vendor: ASRockRack
board_name: EPC612D4I
board_version:

** Loaded modules:
vhost_net
vhost
tap
tun
ocfs2
quota_tree
ebtable_filter
ebtables
ocfs2_dlmfs
ocfs2_stack_o2cb
ocfs2_dlm
ocfs2_nodemanager
ocfs2_stackglue
configfs
ip6table_filter
ip6_tables
iptable_filter
bridge
stp
llc
bonding
fuse
intel_rapl
iTCO_wdt
iTCO_vendor_support
sb_edac
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
kvm
irqbypass
crct10dif_pclmul
crc32_pclmul
ast
ghash_clmulni_intel
ttm
intel_cstate
drm_kms_helper
intel_uncore
igb
lpc_ich
drm
dca
mxm_wmi
evdev
intel_rapl_perf
pcspkr
sg
i2c_i801
mfd_core
i2c_algo_bit
e1000e
ehci_pci
xhci_pci
ehci_hcd
xhci_hcd
mei_me
ptp
usbcore
shpchp
pps_core
mei
usb_common
ipmi_si
acpi_power_meter
ipmi_devintf
wmi
ipmi_msghandler
acpi_pad
button
drbd
lru_cache
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
raid10
raid456
libcrc32c
crc32c_generic
async_raid6_recov
async_memcpy
async_pq
async_xor
xor
async_tx
sd_mod
raid6_pq
raid1
raid0
multipath
linear
md_mod
crc32c_intel
aesni_intel
aes_x86_64
crypto_simd
cryptd
glue_helper
ahci
libahci
libata
scsi_mod

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
v4/Xeon D DMI2 [8086:6f00] (rev 01)
Subsystem: ASRock Incorporation Xeon E7 v4/Xeon E5 v4/Xeon E3 v4/Xeon D 
DMI2 [1849:6f00]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
v4/Xeon D PCI Express Root Port 1 [8086:6f02] (rev 01) (prog-if 00 [Normal 
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:02.0 PCI bridge [0604]: Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
v4/Xeon D PCI Express Root Port 2 [8086:6f04] (rev 01) (prog-if 00 [Normal 
decode])
Control: I/O+ Mem+ Bus

Bug#886783: ITP: coreschema -- Python utilities to describe an abstract data schema to coreapi

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: coreschema
  Version : 0.0.4
  Upstream Author : Tom Christie 
* URL : https://github.com/core-api/python-coreschema
* License : BSD
  Programming Lang: Python
  Description : Python utilities to describe an abstract data schema to 
coreapi

Core API is a format-independent Document Object Model for representing
Web APIs.

It can be used to represent either Schema or Hypermedia responses, and
allows one to interact with an API at the layer of an application
interface, rather than a network interface.

This package, which is required by coreapi, provides an abstract Python library
to describe classic data (Integers, Strings et al.).

This package would be maintained under DPMT umbrella.

-- 
PEB

Bug#886781: firebird3.0-server-core: Duplicate values in columns with a unique constraint

[Damyan Ivanov]

Package: firebird3.0-server-core
Version: 3.0.1.32609.ds4-14
Severity: important
Tags: patch upstream fixed-upstream

Control: forwarded -1 http://tracker.firebirdsql.org/browse/CORE-5694

Copied from upstream bug report:

It is possible to get rows with duplicate values in columns with a unique 
constraint.

Sample database backup is in fb-dupl-uniq.fbk.gz

Notice the unique constraint on test(obj_id, prj_id) and the procedure 
add_obj_to_prj which inserts records in TEST ignoring constraint violation. 
That procedure is invoked by an after update/insert trigger of table OBJ.

To trigger the problem, run the following shell command:

(triggers updates in 5000 rows, in random order, in 6 parallel processes)

for j in $(seq 1 6); do
  (
( for i in $(seq 1 5000); do
echo $i;
  done | shuf | while read i; do
printf "update obj set data='Object %d' where id='911%07d';\n 
commit;\n" $i $i;
  done
) | isql-fb localhost:/var/lib/firebird/3.0/data/test.fdb
  ) &;
done

There may be some update conflicts, but that's irrelevant -- I see the problem 
even when there are no update conflicts.

The above may need to be run several times, or the process count to be 
increased to surpass the number of CPU cores.

Execute the following SQL to see if the problem is there:

select obj_id, prj_id, count(*) from test
group by 1,2
having count(*) > 1;


fb-dupl-uniq.fbk.gz
Description: application/gzip

Bug#886780: i2pd: crash with SIGILL on CPUs without avx and aes

[Adam Borowski]

Package: i2pd
Version: 2.17.0-1
Severity: serious
Justification: programs must support baseline arch (w/o a good reason otherwise)

Hi!
I'm afraid that current version of i2pd crashes on startup on processors
that don't support avx and aes, unless the package was built on a machine
without such support (the build system does _compile time_ detection).

The in-archive binary package 2.17.0-1:amd64 is ok as it was built on such a
processor (in fact, the very same machine I'm testing on).  Alas, this is not
the case for :i386 (and presumably :x32), which crashes on daemon's startup:

[37476.565483] traps: i2pd[14112] trap invalid opcode ip:565aeb9d sp:ffd6c0a0 
error:0 in i2pd[56578000+292000]

A rebuild of :amd64 (binNMU, new source-only upload, Ubuntu, ...) would also
crash this way.


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

Kernel: Linux 4.15.0-rc7-debug-00025-g6c558864404f (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages i2pd:i386 depends on:
ii  adduser 3.116
ii  libboost-date-time1.62.01.62.0+dfsg-5
ii  libboost-filesystem1.62.0   1.62.0+dfsg-5
ii  libboost-program-options1.62.0  1.62.0+dfsg-5
ii  libboost-system1.62.0   1.62.0+dfsg-5
ii  libc6   2.26-2
ii  libgcc1 1:7.2.0-19
ii  libssl1.1   1.1.0g-2
ii  libstdc++6  7.2.0-19
ii  lsb-base9.20170808
ii  zlib1g  1:1.2.8.dfsg-5

i2pd:i386 recommends no packages.

i2pd:i386 suggests no packages.

-- no debconf information

Bug#886779: RM: pyqwt5 -- ROM; Package only works for Qt4 and won't be upgraded to Qt5.

[Gudjon I. Gudjonsson]

Package: ftp.debian.org 

Bug#886778: qupzilla FTCBFS: uses build architecture qmake and pkg-config

[Helmut Grohne]

Source: qupzilla
Version: 2.2.3~dfsg1-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

qupzilla fails to cross build from source, because debian/rules invokes
qmake without cross flags. It supposedly runs qmake directly to select
qt5, but that's much easier achieved by setting QT_SELECT. Then it fails
because some .pro file manages to run (the build architecture)
pkg-config directly rather than using the (host architecture) pkg-config
passed to the build. After fixing both, qupzilla cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru qupzilla-2.2.3~dfsg1/debian/changelog 
qupzilla-2.2.3~dfsg1/debian/changelog
--- qupzilla-2.2.3~dfsg1/debian/changelog   2018-01-08 11:46:02.0 
+0100
+++ qupzilla-2.2.3~dfsg1/debian/changelog   2018-01-09 21:11:14.0 
+0100
@@ -1,3 +1,12 @@
+qupzilla (2.2.3~dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Closes: #-1
++ Select qt5 via QT_SELECT.
++ Use the right pkg-config.
+
+ -- Helmut Grohne   Tue, 09 Jan 2018 21:11:14 +0100
+
 qupzilla (2.2.3~dfsg1-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru qupzilla-2.2.3~dfsg1/debian/patches/cross.patch 
qupzilla-2.2.3~dfsg1/debian/patches/cross.patch
--- qupzilla-2.2.3~dfsg1/debian/patches/cross.patch 1970-01-01 
01:00:00.0 +0100
+++ qupzilla-2.2.3~dfsg1/debian/patches/cross.patch 2018-01-09 
21:11:14.0 +0100
@@ -0,0 +1,16 @@
+Index: 
qupzilla-2.2.3~dfsg1/src/plugins/GnomeKeyringPasswords/GnomeKeyringPasswords.pro
+===
+--- 
qupzilla-2.2.3~dfsg1.orig/src/plugins/GnomeKeyringPasswords/GnomeKeyringPasswords.pro
 
qupzilla-2.2.3~dfsg1/src/plugins/GnomeKeyringPasswords/GnomeKeyringPasswords.pro
+@@ -55,8 +55,9 @@
+ translations/zh_HK.ts \
+ translations/zh_TW.ts \
+ 
+-LIBS += $$system(pkg-config --libs gnome-keyring-1)
+-QMAKE_CXXFLAGS += $$system(pkg-config --cflags gnome-keyring-1)
++PKG_CONFIG = $$pkgConfigExecutable()
++LIBS += $$system($$PKG_CONFIG --libs gnome-keyring-1)
++QMAKE_CXXFLAGS += $$system($$PKG_CONFIG --cflags gnome-keyring-1)
+ 
+ PLUGIN_DIR = $$PWD
+ include(../../plugins.pri)
diff --minimal -Nru qupzilla-2.2.3~dfsg1/debian/patches/series 
qupzilla-2.2.3~dfsg1/debian/patches/series
--- qupzilla-2.2.3~dfsg1/debian/patches/series  2018-01-08 11:46:02.0 
+0100
+++ qupzilla-2.2.3~dfsg1/debian/patches/series  2018-01-09 21:11:14.0 
+0100
@@ -2,3 +2,4 @@
 gnome-integration.patch
 kde-integration.patch
 appdata.xml.patch
+cross.patch
diff --minimal -Nru qupzilla-2.2.3~dfsg1/debian/rules 
qupzilla-2.2.3~dfsg1/debian/rules
--- qupzilla-2.2.3~dfsg1/debian/rules   2018-01-08 11:46:02.0 +0100
+++ qupzilla-2.2.3~dfsg1/debian/rules   2018-01-09 21:11:12.0 +0100
@@ -9,6 +9,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+export QT_SELECT=qt5
+
 %:
dh $@
 
@@ -16,7 +18,7 @@
 # E: qupzilla source: source-is-missing src/lib/data/html/jquery-ui.js
 # E: qupzilla source: source-is-missing src/lib/data/html/jquery.js
 override_dh_auto_configure:
-   qmake -qt5 # enforce Qt5 build
+   dh_auto_configure
# copies uglified libraries for jquery and jquery-ui
cp /usr/share/javascript/jquery/jquery.js src/lib/data/html
cp /usr/share/javascript/jquery-ui/jquery-ui.js src/lib/data/html

Bug#886777: crashes with Mustek scanner which worked before

[W. Martin Borgert]

Package: sane
Version: 1.0.14-12
Severity: important

Unfortunately, I cannot scan anymore, neither with simple-scan
nor from Gimp. Both give similar error messages.

Last successful scan was on stretch, so it is not the version of
sane that is broken, but maybe bad interaction with glibc SSP.

$ lsusb 
Bus 004 Device 006: ID 055f:0409 Mustek Systems, Inc. BearPaw 2448 TA Pro

$ simple-scan

(simple-scan:24462): Gtk-WARNING **: Failed to register client: 
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "RegisterClient" 
with signature "ss" on interface "org.xfce.Session.Manager" doesn't exist

*** stack smashing detected ***: simple-scan terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x722fb)[0x7f38a37e42fb]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f38a386f947]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7f38a386f910]
/usr/lib/x86_64-linux-gnu/sane/libsane-mustek_usb2.so.1(+0xef40)[0x7f38806aef40]
/usr/lib/x86_64-linux-gnu/sane/libsane-mustek_usb2.so.1(+0xfbf5)[0x7f38806afbf5]
/usr/lib/x86_64-linux-gnu/sane/libsane-mustek_usb2.so.1(+0x13fe0)[0x7f38806b3fe0]
/usr/lib/x86_64-linux-gnu/sane/libsane-mustek_usb2.so.1(sane_mustek_usb2_open+0x35a)[0x7f38806b6eba]
/usr/lib/x86_64-linux-gnu/libsane.so.1(sane_dll_open+0xf6)[0x7f38a3f99b16]
simple-scan(+0x34143)[0x55be05b24143]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x72635)[0x7f38a5d6b635]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7519)[0x7f38a3357519]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f38a385ea4f]
=== Memory map: 
55be05af-55be05b4f000 r-xp  fd:01 12588957   
/usr/bin/simple-scan
55be05d4f000-55be05d52000 r--p 0005f000 fd:01 12588957   
/usr/bin/simple-scan
55be05d52000-55be05d53000 rw-p 00062000 fd:01 12588957   
/usr/bin/simple-scan
55be06305000-55be06919000 rw-p  00:00 0  [heap]
7f387000-7f3870021000 rw-p  00:00 0 
7f3870021000-7f387400 ---p  00:00 0 
7f3874fb2000-7f3874fb3000 ---p  00:00 0 
7f3874fb3000-7f38757b3000 rw-p  00:00 0 
7f38757b3000-7f38757c2000 r-xp  fd:01 13110634   
/usr/lib/x86_64-linux-gnu/sane/libsane-net.so.1.0.25
7f38757c2000-7f38759c1000 ---p f000 fd:01 13110634   
/usr/lib/x86_64-linux-gnu/sane/libsane-net.so.1.0.25
7f38759c1000-7f38759c2000 r--p e000 fd:01 13110634   
/usr/lib/x86_64-linux-gnu/sane/libsane-net.so.1.0.25
7f38759c2000-7f38759c3000 rw-p f000 fd:01 13110634   
/usr/lib/x86_64-linux-gnu/sane/libsane-net.so.1.0.25
7f38759c3000-7f38759d r-xp  fd:01 13107747   
/usr/lib/x86_64-linux-gnu/sane/libsane-abaton.so.1.0.25
7f38759d-7f3875bd ---p d000 fd:01 13107747   
/usr/lib/x86_64-linux-gnu/sane/libsane-abaton.so.1.0.25
7f3875bd-7f3875bd1000 r--p d000 fd:01 13107747   
/usr/lib/x86_64-linux-gnu/sane/libsane-abaton.so.1.0.25
7f3875bd1000-7f3875bd2000 rw-p e000 fd:01 13107747   
/usr/lib/x86_64-linux-gnu/sane/libsane-abaton.so.1.0.25
7f3875bd2000-7f3875be2000 r-xp  fd:01 13107910   
/usr/lib/x86_64-linux-gnu/sane/libsane-agfafocus.so.1.0.25
7f3875be2000-7f3875de1000 ---p 0001 fd:01 13107910   
/usr/lib/x86_64-linux-gnu/sane/libsane-agfafocus.so.1.0.25
7f3875de1000-7f3875de2000 r--p f000 fd:01 13107910   
/usr/lib/x86_64-linux-gnu/sane/libsane-agfafocus.so.1.0.25
7f3875de2000-7f3875de3000 rw-p 0001 fd:01 13107910   
/usr/lib/x86_64-linux-gnu/sane/libsane-agfafocus.so.1.0.25
7f3875de3000-7f3875df3000 r-xp  fd:01 13108298   
/usr/lib/x86_64-linux-gnu/sane/libsane-apple.so.1.0.25
7f3875df3000-7f3875ff3000 ---p 0001 fd:01 13108298   
/usr/lib/x86_64-linux-gnu/sane/libsane-apple.so.1.0.25
7f3875ff3000-7f3875ff4000 r--p 0001 fd:01 13108298   
/usr/lib/x86_64-linux-gnu/sane/libsane-apple.so.1.0.25
7f3875ff4000-7f3875ff5000 rw-p 00011000 fd:01 13108298   
/usr/lib/x86_64-linux-gnu/sane/libsane-apple.so.1.0.25
7f3875ff5000-7f387602 r-xp  fd:01 13109694   
/usr/lib/x86_64-linux-gnu/sane/libsane-avision.so.1.0.25
7f387602-7f387622 ---p 0002b000 fd:01 13109694   
/usr/lib/x86_64-linux-gnu/sane/libsane-avision.so.1.0.25
7f387622-7f3876221000 r--p 0002b000 fd:01 13109694   
/usr/lib/x86_64-linux-gnu/sane/libsane-avision.so.1.0.25
7f3876221000-7f3876223000 rw-p 0002c000 fd:01 13109694   
/usr/lib/x86_64-linux-gnu/sane/libsane-avision.so.1.0.25
7f3876223000-7f3876226000 rw-p  00:00 0 
7f3876226000-7f387623a000 r-xp  fd:01 13109407   
/usr/lib/x86_64-linux-gnu/sane/libsane-artec.so.1.0.25
7f387623a000-7f3876439000 ---p 00014000 fd:01 13109407   
/usr/lib/x86_64-l

Bug#884243: djmount status, two patches and about conversion to libupnp 1.8

[Rémi]

Hello Uwe,

you are right, I have not been active on djmount for quite some time now.
I tried to find a volonteer to maintain it at the time, but it didn't
happen.

I am sorry I don't have the right setup to validate these patches :-/
So removing should be considered, unless a maintainer can be found.

thanks for your interest,
best regards,



On Tue, Jan 9, 2018 at 10:30 AM, Uwe Kleine-König 
wrote:

> Hello Rémi,
>
> given that djmount didn't see any changes (judging from
> https://sourceforge.net/p/djmount/code/HEAD/tree/) I wonder if the
> project is still alive. The interest I have here is that I like to drop
> libupnp 1.6 from Debian and so the djmount package must either be
> dropped or converted to libupnp 1.8. As a conversion is non-trivial I
> wonder if it is worth the effort.
>
> See https://bugs.debian.org/884243 for some details. Another hint that
> removing might be the right alternative is that the Debian maintainer of
> djmount (implicitly on Cc via the bug address) didn't react on this bug
> yet.
>
> I started working on djmount, two patches are already finished (but only
> build tested) and I started to change the list handling as libupnp 1.8
> doesn't provide the implementation of linked lists any more. The two
> finished patches can be found in the attachment.
>
> It would be great do get some feed back about your actual interest on
> djmount.
>
> Best regards
> Uwe
>



-- 
Rémi

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Adrian Bunk]

On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
>...
> Given the background of build-profiles, I'm very much in favor of
> introducing the equivalent usage as Gentoo USE flags, which was its
> main intention! :) It could make Debian a viable source-based
> distribution to use or base on, could make many of the embedded specific
> distribution solutions obsolete,
>...

Who would then implement, maintain and support this in all packages?

Implementing that global flags like
  USE="-systemd -alsa -pulseaudio -wayland"
work across all 30k source packages would be a huge amount of work.

And then supporting that any combination of disabling/enabling various 
flags builds and works for all packages at the quality level people 
expect from a Debian stable - that's completely out of scope of what 
Debian could achieve with its already stretched developer resources.

> Thanks,
> Guillem

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#886714: make[8]: no: Command not found

[Ralf Treinen]

Hello,

On Tue, Jan 09, 2018 at 08:45:42AM +0100, Mathieu Malaterre wrote:

> For some reason coccinelle FTBFS on mips*, it fails with:
> 
> make[8]: Entering directory '/<>/commons'
> /usr/bin/ocamlc -unsafe -I ocamlextra   -c ocamlextra/dumper.mli
> no -unsafe -I ocamlextra   -c commands.ml
> make[8]: no: Command not found

mips and mipsel are the two architectures among the release architectures
for which ocaml only provides compilation to bytecode. Without having
looked into the makefile this smells a lot like a mistake in a test 
of existence of native-code compilation or not.

-Ralf.

Bug#886776: genisoimage: Buffer Overflow found in isoinfo executable

[Julian Jackson]

Package: genisoimage
Version: 9:1.1.11-3+b2
Severity: normal
Tags: security

Dear Maintainer,

Fuzzing the isoinfo binary from genisoimage using afl-fuzz identified a
vulnerable function, parse_dir which contains a  buffer overflow
vulnerability.
This seems to be related to the length of idr->name passed to the parse_dir
function on line 1230.

Steps to reproduce:
$ isoinfo -i crash.iso
*** stack smashing detected ***: isoinfo terminated
Aborted (core dumped)

Crash Information:
$ gdb isoinfo
(gdb) set args -i crash/crash.iso
(gdb) r
Starting program: /usr/bin/isoinfo -i crash/crash.iso
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
*** stack smashing detected ***: /usr/bin/isoinfo terminated

Program received signal SIGABRT, Aborted.
(gdb)


>From cwtriage:

Command: isoinfo -i crash/crash.iso
Faulting Frame:
   parse_dir @ 0x004081ac: in /usr/bin/isoinfo
Disassembly:
Stack Head (23 entries):
   __GI_raise@ 0x77825428: in /lib/x86_64-linux-gnu/
libc-2.23.so (BL)
   __GI_abort@ 0x7782702a: in /lib/x86_64-linux-gnu/
libc-2.23.so (BL)
   __libc_message@ 0x778677ea: in /lib/x86_64-linux-gnu/
libc-2.23.so (BL)
   __GI___fortify_fail   @ 0x7790911c: in /lib/x86_64-linux-gnu/
libc-2.23.so (BL)
   __stack_chk_fail  @ 0x779090c0: in /lib/x86_64-linux-gnu/
libc-2.23.so (BL)
   parse_dir @ 0x004081ac: in /usr/bin/isoinfo
   None  @ 0xd2d2d2d2d2d2d2d2: in ?
   None  @ 0xd2d2d2d2d2d2d2d2: in ?
   None  @ 0xd2d2d2d2d2d2d2d2: in ?
   None  @ 0xd2d2d2d2d2d2d2d2: in ?
   None  @ 0xd2d2d2d2d2d2d2d2: in ?
   None  @ 0xd2d2d2d2d2d2d2d2: in ?
   None  @ 0xd2d2d2d2: in ?
   None  @ 0x0001313030444301: in ?
   None  @ 0x20202058554e494c: in ?
   None  @ 0x2020202020202020: in ?
Registers:
rax=0x rbx=0x003d rcx=0x77825428
rdx=0x0006
rsi=0x4b55 rdi=0x4b55 rbp=0x7fffb990
rsp=0x7fffb678
 r8=0x6f666e696f73692f  r9=0x r10=0x0008
r11=0x0206
r12=0x003d r13=0x7fffb808 r14=0x7fffb808
r15=0x0001
rip=0x77825428 efl=0x0206  cs=0x0033
ss=0x002b
 ds=0x  es=0x  fs=0x
gs=0x000

A sample crashing test case is attached. More can be provided if necessary.

-Julian

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

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

Versions of packages genisoimage depends on:
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.24-11+deb9u1
ii  libmagic1   1:5.30-1+deb9u1
ii  zlib1g  1:1.2.8.dfsg-5

genisoimage recommends no packages.

Versions of packages genisoimage suggests:
pn  cdrkit-doc  
pn  wodim   

-- no debconf information


crash.iso
Description: application/cd-image

Bug#886133: ndpi: FTBFS on mips, s390x, powerpc, and ppc64: tests time out

[Ludovico Cavedon]

Hi,

 I have an update on this: I have a patch for upstream review at
https://github.com/ntop/nDPI/pull/506.
It fixes this issue, but unittests still fail on s90x (and I guess on the
other big endian archs), so no new upload for now, until I debug that.

Ludovico

Bug#249789: New login from Chrome on Windows

[Square]

[X]

New login from Chrome on Windows



Hello,
Your email address   was just used to log into Square from a new browser and/or 
device.
[X]
New login from Chrome on Windows

Sunday, October 8, 2017 at 10:27 PM (CDT)
Tulsa, Oklahoma, United States*

If you don’t recognize this activity, we recommend changing your password as 
soon as possible. Otherwise, you can disregard this message.
UPDATE PASSWORD


Alternatively, you can visit 
nonody.net/dfn/sq/Ma to reset 
your password.
Why are we sending this? We didn’t recognize the browser or device you used to 
log into your Square account. This could be the result of accessing your 
account from a new or public computer or changing your browser settings, but it 
could also be a sign of unauthorized account activity.
Manage Account Need help? Let 
us know.
Thanks,
The Square Team

Square Secure is here to help protect you so you can focus on running your 
business. Click here to find 
out more.
*This location is an approximation based on your IP address and its accuracy 
depends on your Internet Service Provider.


© 2017 SQUARE, INC. 
1455 MARKET STREET, SUITE 600, 
SAN 
FRANCISCO, 
CA 
94103

[X]

Bug#886775: keepass2: KeePass2 crashed unexpectedly while moving window from one monitor to the another

[Patryk Bęza]

Package: keepass2
Version: 2.37+dfsg-1
Severity: important



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

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

Versions of packages keepass2 depends on:
ii  libgcrypt20  1.8.1-4
ii  libmono-corlib4.5-cil4.6.2.7+dfsg-1
ii  libmono-system-drawing4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-security4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system-windows-forms4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil4.6.2.7+dfsg-1
ii  libmono-system4.0-cil4.6.2.7+dfsg-1
ii  libx11-6 2:1.6.4-3
ii  mono-runtime 4.6.2.7+dfsg-1

Versions of packages keepass2 recommends:
ii  xsel  1.2.0-4

Versions of packages keepass2 suggests:
pn  keepass2-doc  
pn  mono-dmcs 
pn  xdotool   

-- no debconf information


Stack trace from journalctl:

sty 09 20:05:01 Host CRON[4620]: pam_unix(cron:session): session opened for 
user root by (uid=0)
sty 09 20:05:01 Host CRON[4622]: (root) CMD (command -v debian-sa1 > /dev/null 
&& debian-sa1 1 1)
sty 09 20:05:01 Host CRON[4620]: pam_unix(cron:session): session closed for 
user root
sty 09 20:05:41 Host keepass2.desktop[25919]: Stacktrace:
sty 09 20:05:41 Host keepass2.desktop[25919]:   at  <0x>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at (wrapper managed-to-native) 
System.Windows.Forms.X11Keyboard.Xutf8LookupString 
(intptr,System.Windows.Forms.XEvent&,byte[],int,intptr&,System.Windows.Forms.XLookupStatus&)
 <0x000a4>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.X11Keyboard.LookupString 
(System.Windows.Forms.XEvent&,int,System.Windows.Forms.XKeySym&,System.Windows.Forms.XLookupStatus&)
 <0x000c3>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.X11Keyboard.EventToVkey (System.Windows.Forms.XEvent) 
<0x0003f>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.X11Keyboard.ToUnicode (int,int,string&) <0x0035f>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.X11Keyboard.TranslateMessage (System.Windows.Forms.MSG&) 
<0x00127>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.XplatUIX11.TranslateMessage (System.Windows.Forms.MSG&) 
<0x00027>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.XplatUI.TranslateMessage (System.Windows.Forms.MSG&) 
<0x00024>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Application.RunLoop 
(bool,System.Windows.Forms.ApplicationContext) <0x00da7>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Form.ShowDialog (System.Windows.Forms.IWin32Window) 
<0x0093b>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Form.ShowDialog () <0xf>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at (wrapper 
remoting-invoke-with-check) System.Windows.Forms.Form.ShowDialog () <0x0005b>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
KeePass.Forms.MainForm.OpenDatabase 
(KeePassLib.Serialization.IOConnectionInfo,KeePassLib.Keys.CompositeKey,bool) 
<0x0071f>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
KeePass.Forms.MainForm.OnFileLock (object,System.EventArgs) <0x0008f>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
KeePass.Forms.MainForm.OnFormResize (object,System.EventArgs) <0x00247>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Control.OnResizeInternal (System.EventArgs) <0x00088>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Control.OnResize (System.EventArgs) <0x00018>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Form.OnResize (System.EventArgs) <0x00013>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Control.OnSizeChanged (System.EventArgs) <0x00032>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Form.WmWindowPosChanged (System.Windows.Forms.Message&) 
<0x00069>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Form.WndProc (System.Windows.Forms.Message&) <0x00157>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
KeePass.Forms.MainForm.WndProc (System.Windows.Forms.Message&) <0x001d7>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Control/ControlWindowTarget.OnMessage 
(System.Windows.Forms.Message&) <0x00024>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.Control/ControlNativeWindow.WndProc 
(System.Windows.Forms.Message&) <0x0003a>
sty 09 20:05:41 Host keepass2.desktop[25919]:   at 
System.Windows.Forms.NativeWindow.WndProc 
(intptr,System.Windows.Forms.Msg,intptr,int

Bug#880660: xserver-xorg-video-nouveau: Crash when kernel tries to switch to frame buffer

[Sven Joachim]

On 2017-11-03 13:46 +0100, Christoph Pohl wrote:

> after upgrading to kernel 4.13, the nouveau kernel module crashes when
> the kernel tries to switch to frame buffer during boot. Under 4.12,
> where everything was working fine, this was the relevant output of
> dmesg:
>
> Nov  3 09:15:04 ws6779 kernel: [4.615541] nouveau :01:00.0: DRM: 
> allocated 1920x1200 fb: 0x6, bo 97aed7608800
> Nov  3 09:15:04 ws6779 kernel: [4.615989] fbcon: nouveaufb (fb0) is 
> primary device
> Nov  3 09:15:04 ws6779 kernel: [4.758665] Console: switching to colour 
> frame buffer device 240x75
> Nov  3 09:15:04 ws6779 kernel: [4.862120] nouveau :01:00.0: fb0: 
> nouveaufb frame buffer device
>
> Now, under 4.13, this happens and leaves the monitor without a signal,
> making the system unuseable:
>
> Nov  3 09:14:06 ws6779 kernel: [4.647634] nouveau :01:00.0: DRM: 
> allocated 1920x1200 fb: 0x6, bo 8c79da533000
> Nov  3 09:14:06 ws6779 kernel: [4.652071] fbcon: nouveaufb (fb0) is 
> primary device
> Nov  3 09:14:06 ws6779 kernel: [4.749172] BUG: unable to handle kernel 
> NULL pointer dereference at   (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749173] IP:   (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749174] PGD 0 
> Nov  3 09:14:06 ws6779 kernel: [4.749174] P4D 0 
> Nov  3 09:14:06 ws6779 kernel: [4.749174] 
> Nov  3 09:14:06 ws6779 kernel: [4.749175] Oops: 0010 [#1] SMP
> Nov  3 09:14:06 ws6779 kernel: [4.749176] Modules linked in: joydev 
> hid_generic usbhid hid binfmt_misc intel_uncore(+) hp_wmi sparse_keymap 
> rfkill wmi_bmof evdev intel_rapl_perf serio_raw pcspkr sg lpc_ich(+) mfd_core 
> snd_hda_intel(+) snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd 
> soundcore mei_me(+) mei battery i915(+) shpchp(+) tpm_infineon nouveau(+) 
> mxm_wmi wmi video button ttm drm_kms_helper drm i2c_algo_bit parport_pc ppdev 
> lp sunrpc parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
> crc32c_generic fscrypto ecb sr_mod cdrom sd_mod crc32c_intel ahci libahci 
> aesni_intel aes_x86_64 crypto_simd cryptd glue_helper libata xhci_pci 
> ehci_pci e1000e xhci_hcd ehci_hcd psmouse scsi_mod i2c_i801 ptp usbcore 
> pps_core usb_common fan thermal
> Nov  3 09:14:06 ws6779 kernel: [4.749204] CPU: 4 PID: 199 Comm: 
> kworker/u16:4 Not tainted 4.13.0-1-amd64 #1 Debian 4.13.4-2
> Nov  3 09:14:06 ws6779 kernel: [4.749205] Hardware name: Hewlett-Packard 
> HP EliteDesk 800 G1 TWR/18E4, BIOS L01 v02.65 07/13/2015
> Nov  3 09:14:06 ws6779 kernel: [4.749241] Workqueue: nvkm-disp 
> gf119_disp_super [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749241] task: 8c79d753d040 
> task.stack: b4f2821c4000
> Nov  3 09:14:06 ws6779 kernel: [4.749242] RIP: 0010:  (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749242] RSP: 0018:b4f2821c7c40 
> EFLAGS: 00010206
> Nov  3 09:14:06 ws6779 kernel: [4.749243] RAX: c081fec0 RBX: 
>  RCX: 0016
> Nov  3 09:14:06 ws6779 kernel: [4.749244] RDX:  RSI: 
>  RDI: 8c79dbe9a000
> Nov  3 09:14:06 ws6779 kernel: [4.749244] RBP:  R08: 
>  R09: 
> Nov  3 09:14:06 ws6779 kernel: [4.749244] R10: 1000 R11: 
> 10624dd3 R12: 
> Nov  3 09:14:06 ws6779 kernel: [4.749245] R13: b4f2821c7d6e R14: 
> b4f2821c7d60 R15: 8c79dce92c00
> Nov  3 09:14:06 ws6779 kernel: [4.749245] FS:  () 
> GS:8c79efb0() knlGS:
> Nov  3 09:14:06 ws6779 kernel: [4.749246] CS:  0010 DS:  ES:  
> CR0: 80050033
> Nov  3 09:14:06 ws6779 kernel: [4.749247] CR2:  CR3: 
> 000214009000 CR4: 001406e0
> Nov  3 09:14:06 ws6779 kernel: [4.749247] Call Trace:
> Nov  3 09:14:06 ws6779 kernel: [4.749272]  ? 
> nvkm_dp_train_drive+0x210/0x2f0 [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749294]  ? nvkm_dp_acquire+0x89c/0xca0 
> [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749317]  ? 
> nv50_disp_super_2_2+0x69/0x430 [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749337]  ? gf119_disp_super+0x1a5/0x2f0 
> [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749340]  ? process_one_work+0x181/0x370
> Nov  3 09:14:06 ws6779 kernel: [4.749341]  ? worker_thread+0x4d/0x3a0
> Nov  3 09:14:06 ws6779 kernel: [4.749342]  ? kthread+0xfc/0x130
> Nov  3 09:14:06 ws6779 kernel: [4.749343]  ? process_one_work+0x370/0x370
> Nov  3 09:14:06 ws6779 kernel: [4.749344]  ? 
> kthread_create_on_node+0x70/0x70
> Nov  3 09:14:06 ws6779 kernel: [4.749346]  ? ret_from_fork+0x25/0x30
> Nov  3 09:14:06 ws6779 kernel: [4.749346] Code:  Bad RIP value.
> Nov  3 09:14:06 ws6779 kernel: [4.749349] RIP:   (null) RSP: 
> b4f2821c7c40
> Nov  3 09:14:06 ws6779 kernel: [4.749349] CR2: 
> Nov  3 09:14:06 ws677

Bug#886768: (no subject)

[Arne Nordmark]

Control: reassign -1 src:linux

Bug#886774: RFS: sqldeveloper-package/0.5.3

[Lazarus Long]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sqldeveloper-package"

 * Package name: sqldeveloper-package
   Version : 0.5.3
   Upstream Author : Lazarus Long 
 * URL : 
 * License : GPL-3+
   Section : misc

It builds this binary package:

   sqldeveloper-package - Oracle SQL Developer Debian package builder

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

   


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

   dget -x 
https://mentors.debian.net/debian/pool/contrib/s/sqldeveloper-package/sqldeveloper-package_0.5.3.dsc

More information about sqldeveloper-package can be obtained from
.

Changes since the last upload:

   sqldeveloper-package (0.5.3) unstable; urgency=high

 * Fixed LD_LIBRARY_PATH initialization, which was rendering the wrapper
   script unusable, thus breaking the package
 * Fixed QA "unsatisfiable Depends" alerts by disabling cross-building
 * Updated debhelper compat version to 11
 * Verified compliancy with Standards-Version: 4.1.3

-- Lazarus Long   Tue, 09 Jan 2018 00:05:03 +

   sqldeveloper-package (0.5.2) unstable; urgency=low

 * Fixed wrapper script command line options invocation
 * Added environment variables ORACLE_PATH and SQLPATH initialization to
   wrapper script

-- Lazarus Long   Tue, 26 Dec 2017 00:05:02 +


Regards,

-- 
Lazarus Long

Bug#886729: atop: noisy service restarts every night

[Marc Haber]

On Tue, Jan 09, 2018 at 11:27:15AM +0100, Cristian Ionescu-Idbohrn wrote:
> Every night, two annoying mail messages are generated (see below).  I
> added the '--quiet' option to the systemctl command hoping for less
> noise, but it didn't help.  Is there anything that can be done to make
> it shut up?

I have never seen that. Are you running your systemd in some debug mode?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#886727: nouveau: no desktop on nvidia NVS 310 card on DELL precision 7810

[Sven Joachim]

Am 09.01.2018 um 11:00 schrieb Joachim Schmidt:

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.15-2
> Severity: important
> File: nouveau
>
> Dear Maintainer,
>
> * installed testing version parallel (stable version runs well)
> * no display will be shown - terminal goes into standby

Before or after X starts?  Does it work when you use the stretch kernel
on testing?

> VGA-compatible devices on PCI bus:
> --
> 03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 [NVS 310] 
> [10de:107d] (rev a1)

Probably that is https://bugs.freedesktop.org/show_bug.cgi?id=103421,
but a kernel log would be useful to be sure.  Can you find a backtrace
in /var/log/kern.log?

Cheers,
   Sven

Bug#886645: want guidance for changelogs when history is merge-ish

[Don Armstrong]

On Tue, 09 Jan 2018, Ian Jackson wrote:

> Don Armstrong writes ("Re: Bug#886645: want guidance for changelogs when 
> history is merge-ish"):
> > On Tue, 09 Jan 2018, Ian Jackson wrote:
> > >  * Each node inherits the merger of the bug map of its parents
> > >When merging, for each key we take the largest value for
> > >any parent where Undef < Found < Fixed
> >
> > I'm leery of this, because it's not conservative. If the inheritance
> > method preferred found over fixed, that might be workable. Another
> > concern is the complexity, and the lack of a mechanism to prune edges.
> > [Though maybe that won't be used in practice?]
> 

[...]

>  V
> / \
>   { B: found } X   \
>   /??? { B: fixed }
>  Z   \
>   `   \
>`   W fixed { B: fixed }
>??? |
>  `???
>   `   /
>` /
> B found
> |
> 

[...]

>   Suppose B is marked found, and W, a descendant of B, is marked
>   fixed.  Then W must have a bugfix for the version of the bug which
>   is in B.  That bugfix will be inherited by all of W's descendents,
>   even ones which also inherit the bug by other routes.

This is the part which isn't necessarily true. For example, in your
graph, if W was a new version ("2.0-1"), and the bug was "upgrade to new
upstream version 2.0" and marked found in "1.0-1", and V ("1.0-3") was a
descendant of W ("2.0-1") and Z ("1.0-2"), this algorithm would mark V
fixed, which it clearly isn't.

Admittedly, the way the BTS collapses this DAG into a tree would
probably also have that effect, so it might not be worse than the status
quo.

-- 
Don Armstrong  https://www.donarmstrong.com

Love is... a complex sequence of neurochemical reactions that makes
people behave like idiots. It's similar to intoxication, but the
hangover's even worse.
 -- J. Jacques _Questionable Content_ #1039
http://www.questionablecontent.net/view.php?comic=1039

Bug#886267: Voting for TC Chair

[Niko Tyni]

On Wed, Jan 03, 2018 at 05:38:56PM +0100, Didier 'OdyX' Raboud wrote:

> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A: Didier Raboud 
> B: Tollef Fog Heen 
> C: Phil Hands 
> D: Margarita Manterola 
> E: David Bremner 
> F: Niko Tyni 
> G: Gunnar Wolf 
> ===END===

I vote: A > B = C = D = E > F > G

Thanks for volunteering to serve as the chair.
-- 
Niko


signature.asc
Description: PGP signature

Bug#886644: openmpi: alternatives for libmpi*.so are not multiarch-safe

[Alastair McKinstry]

It appears that while the directories follow a M-A structure,
libopenmpi-dev is not labelled Multi-Arch, so i'm regrading this as
wishlist.

It would still be good for the alternatives link to be M-A aware, so I
will enable that. (and also in mpich).

The syntax in lapack, etc. is -$DEB_HOST_MULTIARCH, so I will
follow that convention.

Its currently not possible to make openmpi/mpich fully M-A aware,
because the alternatves switch needs to control not only the library
(and pkgconfig files, and includes), but also some "wrapper" scripts,
mpicc, etc. that are typically used to compiler MPI programs.

These currently reside in /usr/bin ; it would be possible to move them
to eg. /usr/lib/$DEB_HOST_MULTIARCH/openmpi/bin but they would be
expected to be on the default path by the MPI standard. Also, ideally
mpicc, etc. would be in opempi-bin, the package with openmpi
executables, but using the same alternatives switch in two packages
would be difficult (impossible?) and error-prone; using two switches so
libmpi.so points to one implementation while mpicc could use another
would be buggy.

So:

Can anyone think of a better solution than using alternatives to do
/usr/bin/mpicc -> /usr/lib/$DEB_HOST_MULTIARCH/openmpi/bin ? this is
simply ugly to me, though it would enable M-A for libopenmpi-dev and
proper cross-compilation,etc use cases.


09/01/2018 10:53, Wouter Verhelst wrote:

> The same is true for libdrmaa.so.* (provided by slurm-drmaa1 and
> gridengine-drmaa-1.0).
>
> I think it makes sense to have a detailed discussion about these
> things...?
>
> On Mon, Jan 08, 2018 at 12:01:53PM +, Alastair McKinstry wrote:
>> Package: openmpi
>> Severity: important
>>
>> openmpi installs links via alternatives for libmpi.so, as does mpich and lam.
>> Unfortunately its implementation is not multi-arch safe: there can be 
>> multiple multiarch implementations of libmpi.so present, but only one 
>> libmpi.so in /etc/alternatives.
>>
>> The best practice (see lapack, etc.) is /etc/alternatives/libmpi.so.${ARCH}.
>>
>> This needs to be fixed in both openmpi and mpich.
>>
>> lam needs to be updated to be multi-arch aware too, as it uses 
>> /etc/alternatives/libmpi.so -> a non-m-a aware location.
>>  
>>  
>> 

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
 believing the innocent had everything to fear, mostly from the guilty but in 
the longer term
 even more from those who say things like “The innocent have nothing to fear.”
 - T. Pratchett, Snuff

Bug#886645: want guidance for changelogs when history is merge-ish

[Ian Jackson]

Don Armstrong writes ("Re: Bug#886645: want guidance for changelogs when 
history is merge-ish"):
> On Tue, 09 Jan 2018, Ian Jackson wrote:
> >  * Each node inherits the merger of the bug map of its parents
> >When merging, for each key we take the largest value for
> >any parent where Undef < Found < Fixed
>
> I'm leery of this, because it's not conservative. If the inheritance
> method preferred found over fixed, that might be workable. Another
> concern is the complexity, and the lack of a mechanism to prune edges.
> [Though maybe that won't be used in practice?]

"fixed" in a later version has to trump "found" in an earlier version.
Specifically, consider this case:

4
   / \
  /   \
 / \
/   \
   3 2 fixed
\   /
 \ /
  \   /
   \ /
1 found

By my algorithm, nodes are annotated this way:

4 { 1: fixed }
   / \
  /   \
 / \
/   \
   3 2 fixed
   { 1:found }  \   /  { 1: fixed }
 \ /
  \   /
   \ /
1 found
  { 1: found }


Note that this trumping of foundness for version B by fixedness for
version B only occurs at a node one of whose ancestors has B for an
ancestor and is marked fixed.  Ie, like this in the general case:


 V
/ \
  { B: found } X   \
  /??? { B: fixed }
 Z   \
  `   \
   `   W fixed { B: fixed }
   ??? |
 `???
  `   /
   ` /
B found
|

I think you are worried about the case where an ancestor of Z
reintroduces the bug and a "found" mark there would be overwritten.
But if it does then X would be labelled
   { B: found, Z: found }
or some such.  The { B: found } gets squashed by { B: fixed }
but the { Z: found } remains so V gets { B: fixed, Z: found }
and is considered buggy.

This is exactly right.  What we are modelling here is this reasoning:

  Suppose B is marked found, and W, a descendant of B, is marked
  fixed.  Then W must have a bugfix for the version of the bug which
  is in B.  That bugfix will be inherited by all of W's descendents,
  even ones which also inherit the bug by other routes.

If the bug were reintroduced we get something like this:

4 { 1: fixed, 2.5: found }
   / \
  /   \
 / 2.5 found { 1: fixed, 2.5: found }
/   \
   3 2 fixed
   { 1:found }  \   /  { 1: fixed }
 \ /
  \   /
   \ /
1 found
  { 1: found }

What this is doing is effectively treating every "found" as a separate
bug and seeing if each version of interest has a fix for it, where "a
fix for it" is inferred to exist in any package version which is
marked fixed and which is descended from the bug.

> I've currently got some other things on my plate (database, changing
> templating engine) for Debbugs, but I'm happy to facilitate anyone
> working in this area.

Heh.

I don't think this is the most important thing to be doing.

> > 3. Alternatively, here is a non-DAG based algorithm:
> >
> >  * For each version, we determine whether it is considered to
> >have the bug as follows:
> >
> >  * Look at its changelog.  Work backwards through changelog entries
> >until we find a version which is tagged "found" or "fixed".  That
> >is the answer.  (If we don't find such a version, the bug is
> >considered absent.)
>
> This means that if a changelog ever deleted a version (on purpose or
> accidentally) that bugs which were marked found in that version would
> suddenly stop being buggy in future versions, even if they hadn't been
> fixed.

Good point.

Ian.

--
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#883973: fonts-wine: Please move the ttf/otf fonts to /usr/share/fonts

[Jens Reyer]

On 12/09/2017 11:01 PM, Rogério Brito wrote:
> For the benefit of other programs (thinking here especially of evince/atril
> and other PDF viewers, but also for people that need to collaborate with
> Windows users in an office environment), please put the Tahoma clone and
> other fonts under /usr/share/fonts.

We had the fonts there in the past.  AFAIK we only moved them to the
current position, because back then there was a bug in Wine which
required fonts to be in a specific place.  But this is fixed now, so I
think, we can probably do that.


Did you successfully test this for "the other purpose"?  AFAIK the Wine
fonts are greatly reduced in which glyphs they provide.  On the other
site those are probably very uncommon glyphs.

If we move the fonts, then I guess we have to move all fonts.  Not only
the ttf (marlett.ttf, symbol.ttf, tahomabd.ttf, tahoma.ttf,
wingding.ttf), but also a bunch of *.fon fonts.  Does anyone know if
they work for other applications, and if they are acceptable for a
system-wide position at all?

Greets
jre

Bug#886773: libvirtd: Resource Partitioning does not work with systemd and stretch

[Jonas Wielicki]

Package: libvirtd
Version: libvirt-daemon-system
Severity: normal

Dear Maintainer,

This is on a fresh installation of debian stretch (9.3.0).

I use libvirt Resource Partitioning [1] [2]. The cgroup is created with
systemd:

root@debian9:~# cat /etc/systemd/system/machine-jonas.slice 
[Unit]
Description=Slice: jonas
Before=slices.target
Wants=machine.slice

[Slice]
CPUShares=1024
MemoryLimit=9.5G

root@debian9:~# stat /sys/fs/cgroup/cpu/machine.slice/machine-jonas.slice/
  File: /sys/fs/cgroup/cpu/machine.slice/machine-jonas.slice/
[…]


When creating a domain with the following XML (using that resource
partition/cgroup according to [2]):

root@debian9:~# cat test.xml

  test
  524288
  524288
  8
  
/machine/jonas
  
  
hvm

  
  


  
  

  
  
  destroy
  restart
  restart
  


  
  
/usr/bin/qemu-system-x86_64

  
  


  
  

  

root@debian9:~# virsh define test.xml
Domain test defined from test.xml


Attempting to start the domain fails with:

root@debian9:~# virsh start test
error: Failed to start domain test
error: Failed to create controller cpu for group: No such file or directory


I attached strace to the libvirtd process to find out which cgroup path
it tries to use:

root@debian9:~# strace -ffp $(pidof libvirtd) 2>&1 | grep cpu
[pid 10876] lstat("/sys/fs/cgroup/cpu", {st_mode=S_IFLNK|0777, st_size=11, 
...}) = 0
[pid 10876] lstat("/sys/fs/cgroup/cpuacct", {st_mode=S_IFLNK|0777, st_size=11, 
...}) = 0
[pid 10876] lstat("/sys/fs/cgroup/cpu", {st_mode=S_IFLNK|0777, st_size=11, 
...}) = 0
[pid 10876] lstat("/sys/fs/cgroup/cpuacct", {st_mode=S_IFLNK|0777, st_size=11, 
...}) = 0
[pid 10876] access("/sys/fs/cgroup/cpu,cpuacct/machine/jonas.partition/", F_OK) 
= -1 ENOENT (No such file or directory)
[pid 10876] open("/sys/fs/cgroup/cpu,cpuacct/machine/jonas.partition/", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
[pid 10876] open("/sys/fs/cgroup/cpu,cpuacct/machine/jonas.partition/", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
[pid 10876] open("/sys/fs/cgroup/cpuset/machine/jonas.partition/", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
[pid 10876] sendto(8, {{len=192, type=0x9c5 /* NLMSG_??? */, 
flags=NLM_F_REQUEST|NLM_F_ACK, seq=42, pid=0}, "virt=qemu resrc=vcpu 
reason=star"...}, 192, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 
12) = 192


It tries to use the ``/machine/jonas.partition`` path, which is,
according to [2], only used on non-systemd systems. It appears that
libvirt does not recognize the system as systemd-based, making the start
of the domain fail. Removing the  section from the domain
config makes the domain start.


I would expect that libvirt recognizes the system such that operation
according to [2] (with a machine-foo.slice file, a
/machine/foo should work) is possible.


kind regards,
Jonas

   [1]: https://libvirt.org/formatdomain.html#resPartition
   [2]: https://libvirt.org/cgroups.html#customPartiton


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

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

Bug#663750: muse info file missing

[Leo Butler]

Hi Nicholas,

Thanks for following up on this and for taking over maintenance of
muse-el.

Yes, I still use muse and yes, it would still be desirable to have the
documentation available as debian package.

Leo

Nicholas D Steeves  writes:

> Control: severity -1 wishlist
>
> Hi Leo,
>
> On Tue, Mar 13, 2012 at 08:14:20PM +, Leo Butler wrote:
>> Package: muse-el
>> Version: 3.20-2
>> 
>> The info file, located in texi/muse.info of the Muse source, is not
>> included in the Debian package. If this cannot be included in the
>> muse-el package due to licensing conflicts, then perhaps it could be put
>> into a separate documentation package.
>> 
>
> I adopted maintenance of muse-el sometime last year, and sorry for the
> delay following up on this bug.  I've marked it as wishlist because
> new packages are wishlist priority.
>
> You're right, texi/muse.info is GFDL with invariants, thus is not
> DFSG-free, and providing it would require a muse-doc package in the
> non-free section.  I haven't yet investigated what the best way to
> maintain a single file orig.tarball.
>
> Please let me know if you're still interested in this package.
>
> Sincerely,
> Nicholas

Bug#886645: want guidance for changelogs when history is merge-ish

[Don Armstrong]

On Tue, 09 Jan 2018, Ian Jackson wrote:
> | What about making the BTS support DAGs which are not trees? I think
> | something like this would be useful, but I don't personally have a
> | good idea on how this could be specified using the changelog or how
> | bug fixed/found/absent should be propagated in the DAG. If you have
> | better ideas, email me!
> 
> Without thinking about it excessively hard, I have three suggestions:
> 
> 1. Use the following algorithm for constructing the DAG (which may now
> contain merges):

[...]

> 2. If we don't want to create nodes for un-uploaded versions:

[...]

> For both the above, use the following algorithm for fixed/found
> propagation:
> 
>  * Annotate every node with an "bug map",
>|-> Undef | Found | Fixed

>  * Each node inherits the merger of the bug map of its parents
>When merging, for each key we take the largest value for
>any parent where Undef < Found < Fixed

I'm leery of this, because it's not conservative. If the inheritance
method preferred found over fixed, that might be workable. Another
concern is the complexity, and the lack of a mechanism to prune edges.
[Though maybe that won't be used in practice?]

But that said, we do have historical changelog records for almost all
uploads to Debian from about potato, so it would be possible to actually
test these approaches and think about them in detail. [dgit and screen
look like two promising candidates; I could supply a tarball of their
changelog versions in order if that was useful.]

I've currently got some other things on my plate (database, changing
templating engine) for Debbugs, but I'm happy to facilitate anyone
working in this area.

> 3. Alternatively, here is a non-DAG based algorithm:
> 
>  * For each version, we determine whether it is considered to
>have the bug as follows:
> 
>  * Look at its changelog.  Work backwards through changelog entries
>until we find a version which is tagged "found" or "fixed".  That
>is the answer.  (If we don't find such a version, the bug is
>considered absent.)

This means that if a changelog ever deleted a version (on purpose or
accidentally) that bugs which were marked found in that version would
suddenly stop being buggy in future versions, even if they hadn't been
fixed.

> That algorithm involves storing a (possibly entirely different) list
> of versions for every version of interest.

We actually have that stored currently (but we don't use it for anything
but rebuilding the version tree if we have to). So that wouldn't be too
much difficulty.

-- 
Don Armstrong  https://www.donarmstrong.com

The sheer ponderousness of the panel's opinion [...] refutes its
thesis far more convincingly than anything I might say. The panel's
labored effort to smother the Second Amendment by sheer body weight
has all the grace of a sumo wrestler trying to kill a rattlesnake by
sitting on it---and is just as likely to succeed.
 -- Alex Kozinski, Dissenting in Silveira v. Lockyer
(CV-00-00411-WBS p5983-4)

Bug#842023: Tried updating to 11.5.1

[Sruthi Chandran]

Hi,

I tried updating node-jsdom to 11.5.1 but could not complete as there
are some unpackaged dependencies. I pushed what I did to my repo in
salsa[1].

[1] https://salsa.debian.org/srud-guest/node-jsdom



signature.asc
Description: OpenPGP digital signature

Bug#886772: ITP: debos -- Debian OS builder

[Hector Oron]

Package: wnpp
Severity: wishlist
Owner: Héctor Orón Martínez 

* Package name: debos
  Version : 1.0.0+git20171222.87b0d5e-1
  Upstream Author :
* URL : https://github.com/go-debos/debos
* License : Apache-2.0
  Programming Lang: Go
  Description : Debian OS builder

 debos Debian OS builder. debos is a tool to make creation of various
 debian based os "images" simpler. While most other tools focus on
 specific use-case, debos is more meant as a toolchain to make comon
 actions trivial while providing enough rope to do whatever tweaking that
 might be required behind the scene.
 debos Debian OS builder. debos is a tool to make creation of various
 debian based os "images" simpler. While most other tools focus on
 specific use-case, debos is more meant as a toolchain to make comon
 actions trivial while providing enough rope to do whatever tweaking that
 might be required behind the scene.
 .
 debos expects a yaml file as input, syntax description can be found at:
   https://godoc.org/github.com/go-debos/debos/actions
 .
 and examples are to be found at:
   https://github.com/go-debos/debos-recipes

-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


-- Would you like to make a donation for Debian Conference?
   ** http://debconf18.debconf.org **

Bug#886645: want guidance for changelogs when history is merge-ish

[Ian Jackson]

Don Armstrong writes ("Re: Bug#886645: want guidance for changelogs when 
history is merge-ish"):
> I worked back through this in
> https://www.donarmstrong.com/posts/debbugs_merge_versions/ and I think
> that has a better explanation of what is actually happening using dgit
> as an example.
> 
> Let me know if there's anything that could be clarified more.

Thanks.  I think I can mostly see what's going on now.  I don't think
it's very correct...

| What about making the BTS support DAGs which are not trees? I think
| something like this would be useful, but I don't personally have a
| good idea on how this could be specified using the changelog or how
| bug fixed/found/absent should be propagated in the DAG. If you have
| better ideas, email me!

Without thinking about it excessively hard, I have three suggestions:

1. Use the following algorithm for constructing the DAG (which may now
contain merges):

 * When a new version appears, create a node for every changelog
   entry.

 * Add an edge between every pair of adjacent versions in the
   changelog.

 * The result should be a DAG.  If it is not a DAG, repeatedly remove
   the oldest edges until it is (and maybe complain to someone once by
   email if that is convenient).

2. If we don't want to create nodes for un-uploaded versions:

 * When a new version V appears, create a node for it.

 * If the immediately preceding changelog entry refers to a version W
   which has no node, recurse with V=W.

 * Make an edge from our node V to the immediately preceding changelog
   entry W.

 * Search the rest of the changelog for entries referring to existing
   nodes.  If there is such a node X where the DAG does not contain a
   path from V to X, add an edge from V to X.

For both the above, use the following algorithm for fixed/found
propagation:

 * Annotate every node with an "bug map",
   |-> Undef | Found | Fixed

 * Each node inherits the merger of the bug map of its parents
   When merging, for each key we take the largest value for
   any parent where Undef < Found < Fixed

 * A node tagged "found" has the bug map it inherits plus
  => Found

 * A node tagged "fixed" has the bug map it inherits with
   every Found turned into Fixed

 * A node is considered to have the bug iff there is any
in its bug map with value Found

3. Alternatively, here is a non-DAG based algorithm:

 * For each version, we determine whether it is considered to
   have the bug as follows:

 * Look at its changelog.  Work backwards through changelog entries
   until we find a version which is tagged "found" or "fixed".  That
   is the answer.  (If we don't find such a version, the bug is
   considered absent.)

That algorithm involves storing a (possibly entirely different) list
of versions for every version of interest.

But we don't need to store that _for every version_.  We only need to
store it _for every suite_ because the BTS is only required to tell
anyone whether the version in each suite has the bug.

The UI on the BTS website would cease to be a DAG.  Instead, it would
be a set of parallel linear histories derived from the changelogs
(which might disagree about which versions have the bug).

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#886770: Package description still refers to Iceweasel

[Christopher Chavez]

Package: fonts-lyx
Version: 2.2.3-2
Severity: minor

The long description for the fonts-lyx package still refers to Iceweasel as an 
example of Gecko-based browser. Since Iceweasel is discontinued, should this be 
changed to Firefox instead?

Bug#884209: nmu: rpy_1.0.3-30

[Adrian Bunk]

Control: block 884134 by -1
Control: clone -1 -2
Control: tags -1 - stretch
Control: retitle -1 nmu: rpy_1.0.3-30 (sid)
Control: tags -2 - sid
Control: retitle -2 nmu: rpy_1.0.3-30 (stretch)

On Tue, Dec 12, 2017 at 06:47:07PM +0100, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch sid
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu 2 rpy_1.0.3-30 . ANY . stretch . -m "Rebuild against r-base 3.3"
> nmu 3 rpy_1.0.3-30 . ANY . unstable . -m "Rebuild against r-base 3.4"
> 
> Hi,
> 
> for fixing #884134 binNMUs for rpy are needed in stretch and sid.
> I hope I got the version skewing correct, since s390x already has +b1.
> 
> rpy is probably going to be removed (there is python3 rpy2 and python2
> rpy2-2.8), there is probably not much point ensuring that it gets proper
> dependencies on the virtual r-abi-xx package (or whatever is needed to
> prevent this bug from showing up again).
> 
> 
> Andreas

This was listed under stable binNMU requests only, plitting into two bugs:
- sid bug that some member of the release team will hopefully schedule soon
- stretch bug to be handled for the next point release

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#886769: ITP: fakemachine -- create and spawn virtual machines

[Hector Oron]

Package: wnpp
Severity: wishlist
Owner: Héctor Orón Martínez 

* Package name: fakemachine
  Version : 0.0~git20171207.6af110d-1
  Upstream Author : Sjoerd Simons 
* URL : https://github.com/go-debos/fakemachine
* License : Apache-2.0
  Programming Lang: Go
  Description : create and spawn virtual machines

  Create and spawn virtual machines for building images with debos tool.

  This is a build dependency for `debos'.

-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


-- Would you like to make a donation for Debian Conference?
   ** http://debconf18.debconf.org/ **

Bug#886768: linux-headers-3.16.0-5-amd64: inode_change_ok() missing, breaks openafs module build

[Arne Nordmark]

Package: linux-headers-3.16.0-5-amd64
Version: 3.16.51-3+deb8u1
Severity: normal

Since the latest jessie security update, the OpenAFS module (from 
openafs-modules-source, version 1.6.9-2+deb8u6)
no longer builds.

The error seems to be:
  CC [M]  
/usr/src/modass/usr_src/modules/openafs/src/libafs/MODLOAD-3.16.0-5-amd64-SP/osi_file.o
  
/usr/src/modass/usr_src/modules/openafs/src/libafs/MODLOAD-3.16.0-5-amd64-SP/osi_file.c:
 In function ‘osi_UFSTruncate’:
  
/usr/src/modass/usr_src/modules/openafs/src/libafs/MODLOAD-3.16.0-5-amd64-SP/osi_file.c:187:5:
 error: implicit declaration of function ‘inode_change_ok’ 
[-Werror=implicit-function-declaration]
   code = inode_change_ok(inode, &newattrs);
^
cc1: some warnings being treated as errors
/usr/src/linux-headers-3.16.0-5-common/scripts/Makefile.build:262: receptet för 
målet 
”/usr/src/modass/usr_src/modules/openafs/src/libafs/MODLOAD-3.16.0-5-amd64-SP/osi_file.o”
 misslyckades
make[8]: *** 
[/usr/src/modass/usr_src/modules/openafs/src/libafs/MODLOAD-3.16.0-5-amd64-SP/osi_file.o]
 Fel 1

This is a regression, since the module builds fine with 
linux-headers-3.16.0-4-amd64.

Arne

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

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

Versions of packages linux-headers-3.16.0-5-amd64 depends on:
ii  linux-compiler-gcc-4.8-x86 3.16.51-3+deb8u1
ii  linux-headers-3.16.0-5-common  3.16.51-3+deb8u1
ii  linux-kbuild-3.16  3.16.7-ckt20-1

linux-headers-3.16.0-5-amd64 recommends no packages.

linux-headers-3.16.0-5-amd64 suggests no packages.

-- no debconf information

Bug#858418: Is it possible to release fixed packages now?

[Kepi]

Is it possible to release fixed packages soon?

This bug is making remote systems unaccessible after reboot, IMHO
serverity should be critical. I don't think it is acceptable to have
such bug for more than half year on stable distribution.

I can confirm that upstream patch mentioned by Nicolas is working.

Thanks

-- 
Kepi


signature.asc
Description: PGP signature