Bug#874326: apt-get should provide a clear message if not root

[Jonny Grant]

Package: apt
Version: 1.2.24

Basically apt-get must run as root, so therefore the message should be 
appropriate. Can apt-get not provide a clearer message when that is the 
case?


Expected output
===

$ apt-get update
Reading package lists... Done
E: Permission denied. apt-get must be run as root user
$


Current output
==

$ apt-get update
Reading package lists... Done
W: chmod 0700 of directory /var/lib/apt/lists/partial failed - 
SetupAPTPartialDirectory (1: Operation not permitted)
E: Could not open lock file /var/lib/apt/lists/lock - open (13: 
Permission denied)

E: Unable to lock directory /var/lib/apt/lists/
W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches 
(13: Permission denied)
W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - 
RemoveCaches (13: Permission denied)

$

Bug#874306: autodep8: Support for Octave-Forge packages

[Rafael Laboissière]

* Rafael Laboissière  [2017-09-04 22:49]:

Notice that this patch should only be released in autodep8 when 
version 1.5.1 of the source package octave-pkg-dev (which contains the 
package octave-autopkgtest) reaches unstable.  Since this version 
introduces a new binary package, it will certainly goes through the 
NEW queue.


Indeed: https://ftp-master.debian.org/new/octave-pkg-dev_1.5.1.html

Rafael

Bug#869614: fontforge: CVE-2017-11568 CVE-2017-11569 CVE-2017-11570 CVE-2017-11571 CVE-2017-11572 CVE-2017-11573 CVE-2017-11574 CVE-2017-11575 CVE-2017-11576 CVE-2017-11577

[Salvatore Bonaccorso]

Control: severity -1 serious
# rationale: regression stable -> next stable

Hi

On Tue, Aug 29, 2017 at 12:16:22PM +0200, Salvatore Bonaccorso wrote:
> Control: clone -1 -2 -3
> Control: retitle -1 fontforge: CVE-2017-11568 CVE-2017-11569 CVE-2017-11571 
> CVE-2017-11572 CVE-2017-11574 CVE-2017-11575 CVE-2017-11576 CVE-2017-11577
> Control: retitle -2 fontforge: CVE-2017-11570
> Control: retitle -3 fontforge: CVE-2017-11573
> Control: fixed -1 20120731.b-5+deb8u1
> Control: fixed -1 1:20161005~dfsg-4+deb9u1
> Control: forwarded -2 https://github.com/fontforge/fontforge/issues/3097
> Control: forwarded -3 https://github.com/fontforge/fontforge/issues/3098
> 
> Hi
> 
> since the set of issues fixed together diverge a bit, let's split this
> bug up into the set of already fixed ones and then the two open CVEs
> yet.
> 
> Btw, any plan to do as well an unstable upload?

Raising severity to RC, since fixed in stable but implies regression
to testing as unfixed there yet.

Regards,
Salvatore

Bug#874325: ITP: apertium-cat-srd -- Apertium translation data for the Catalan-Sardinian pair

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: apertium-cat-srd
  Version : 0.9.0
  Upstream Author : Hèctor Alòs i Font  and others
* URL : http://www.apertium.org/
* License : GPL-3+
  Programming Lang:
  Description : Apertium translation data for the Catalan-Sardinian pair

Data package providing Apertium language resources for translating
between the Catalan and Sardinian languages.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#873557: mbedtls: CVE-2017-14032: authentication bypass

[Salvatore Bonaccorso]

Hi James

Apologies for the delay!

On Fri, Sep 01, 2017 at 11:03:45AM +0100, James Cowgill wrote:
> Hi,
> 
> On 30/08/17 20:48, Salvatore Bonaccorso wrote:
> > Control: retitle mbedtls: CVE-2017-14032: authentication bypass
> > 
> > Hi
> > 
> > On Tue, Aug 29, 2017 at 12:09:30AM +0100, James Cowgill wrote:
> >> Source: mbedtls
> >> Version: 2.1.2-1
> >> Severity: grave
> >> Tags: security
> >>
> >> Hi,
> >>
> >> The following security advisory was published for mbedtls:
> >> https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2017-02
> > 
> > MITRE has assigned CVE-2017-14032 for this issue.
> 
> Does the attached patch look OK for stretch? I did a bit of testing with
> it and it seems to fix the issue for me.

Thank you. Looks good to me (although without tests). If your are
confident enough with the results of your testing, please go ahead
with the upload to security-master. Keep in mind that you need to
build with -sa to include the orig tarball, since it's new to dak on
security-master.

Regards,
Salvatore


signature.asc
Description: PGP signature

Bug#874203: ITP: libapache2-mod-md -- ACME certificate support for apache2

[Harlan Lieberman-Berg]

Hello Ondřej!

if you're not planning on maintaining this as part of the Debian
Apache team, we'd be happy to have you under the Let's Encrypt team
umbrella.  We mostly work on our own tools, but we share a mailing
list and we have contacts with the Let's Encrypt upstream for whatever
we need from them.

On Mon, Sep 4, 2017 at 2:53 AM, Ondřej Surý  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: =?utf-8?b?T25kxZllaiBTdXLDvQ==?= 
>
> * Package name: libapache2-mod-md
>   Version : 0.8.1
>   Upstream Author : greenbytes GmbH
> * URL : github.com/icing/mod_md
> * License : Apache-2.0
>   Programming Lang: C
>   Description : ACME certificate support for apache2
>
>  This is an apache2 module for obtaining and maintaining certificates
>  issued by ACME-compatible Certificate Authority such as Let's Encrypt.
>



-- 
Harlan Lieberman-Berg
~hlieberman

Bug#874324: piuparts: experimental distribution doesn't work

[Ross Vandegrift]

Package: piuparts
Version: 0.77
Severity: normal

The manpage for piuparts says that experimental can be specified as the
distribution to test against:

 -d name, --distribution=name
Which Debian distribution to use: a code name (for example jessie,
stretch or sid) or experimental. The default is sid (=unstable).


But that does not work:

$ sudo piuparts -d experimental 
...
0m0.0s DEBUG: Starting command: ['eatmydata', 'debootstrap', 
'--variant=minbase', 
'--keyring=/usr/share/keyrings/debian-archive-keyring.gpg', 
'--include=eatmydata', '--components=main,contrib,non-free', 'experimental', 
'/tmp/tmptp2X0K', 'http://deb.debian.org/debian/']
0m0.0s DUMP:
  E: No such script: /usr/share/debootstrap/scripts/experimental
0m0.0s ERROR: Command failed (status=1): ['eatmydata', 'debootstrap', 
'--variant=minbase', 
'--keyring=/usr/share/keyrings/debian-archive-keyring.gpg', 
'--include=eatmydata', '--components=main,contrib,non-free', 'experimental', 
'/tmp/tmptp2X0K', 'http://deb.debian.org/debian/']
  E: No such script: /usr/share/debootstrap/scripts/experimental

0m0.2s DEBUG: Starting command: ['rm', '-rf', '--one-file-system', 
'/tmp/tmptp2X0K']
0m0.2s DEBUG: Command ok: ['rm', '-rf', '--one-file-system', '/tmp/tmptp2X0K']
0m0.2s DEBUG: Removed directory tree at /tmp/tmptp2X0K
0m0.2s ERROR: piuparts run ends.

Thanks,
Ross


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable'), (40, 'unstable'), (30, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages piuparts depends on:
ii  debootstrap  1.0.89
ii  debsums  2.2.2
ii  dpkg 1.18.24
ii  lsb-release  9.20161125
ii  lsof 4.89+dfsg-0.1
ii  piuparts-common  0.77
ii  python   2.7.13-2
ii  python-debian0.1.30

Versions of packages piuparts recommends:
ii  adequate  0.15.1

Versions of packages piuparts suggests:
ii  schroot  1.6.10-3+b1

-- no debconf information

Bug#874323: libvirt: New upstream version 3.7.0 available

[Salvatore Bonaccorso]

Source: libvirt
Severity: wishlist

Hi Guido

I realize it was just released on 04.09.2017, so no pressure, just to
give a heads up. A new upstream version for libvirt was released:

https://libvirt.org/news.html

At this point: thanks for all your work on the pkg-libvirt packages.

Regards,
Salvatore

Bug#874322: task-chinese-s: Please remove debian-zh-faq from the recommend list of task-chinese-s

[Boyuan Yang]

Package: task-chinese-s
Version: 3.39
Severity: normal

Dear tasksel maintainers,

According to https://bugs.debian.org/874093, we are removing the package
debian-zh-faq from Debian Archive.

Please consider removing debian-zh-faq from the recommend list of task-
chinese-s.

Thanks,
Boyuan Yang



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

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

Versions of packages task-chinese-s depends on:
ii  tasksel  3.39

Versions of packages task-chinese-s recommends:
pn  debian-zh-faq-s  
ii  fortune-zh   2.4
ii  manpages-zh  1.6.3.1-1~exp0
ii  opencc   1.0.4-5
pn  zhcon

task-chinese-s suggests no packages.

Bug#865502: #865502,siege: apparently runs, shows a report, then crashes while exiting

[Josue Abarca]

Thanks for the report and confirmation. I will work to get this updated
during the weekend.

Bug#853831: libqt5gui5: font rendering broken

[Ed Peguillan III]

I eventually fixed my issue by installing package 'freetype2-demos'. 
Your mileage may vary.


Ed

On Fri, 01 Sep 2017 18:12:33 -0500 Ed Peguillan III 
 wrote:

> Package: libqt5gui5
> Version: 5.9.1+dfsg-9
> Followup-For: Bug #853831
>
> Dear Maintainer,
>
> I think my problem is related. I initially thought the problem was with
> qjackctl specifically, but I realized that many qt5 applications would
> not start that depended on libqt5gui5, such as virtualbox.
>
> This error is given when starting qjackctl or virtualbox:
>
> $ virtualbox
> /usr/lib/virtualbox/VirtualBox: symbol lookup error:
> /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5: undefined symbol:
> FT_Property_Set
>
> $ qjackctl
> qjackctl: symbol lookup error:
> /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5: undefined symbol:
> FT_Property_Set
>
> See #873792 @
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873792
>
> After I deleted the file I mentioned in that bug report, virtualbox and
> qjackctl started, until I rebooted my machine. Now it is back to the
> same error.
>
> I had infinality fonts installed from this git repo
> https://github.com/cmpitg/infinality-debian-package
> This may be the cause of the conflict. Unfortunately, I don't know 
enough about this to figure out what is wrong. Uninstalling infinality 
did not fix the problem.

>
> # apt install --reinstall libqt5gui5
>
> did not work.
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers testing
> APT policy: (1000, 'testing'), (1000, 'stable'), (750, 'stable'), 
(50, 'unstable'), (1, 'experimental')

> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libqt5gui5 depends on:
> ii fontconfig 2.12.3-0.2
> ii libc6 2.24-14
> ii libdrm2 2.4.82-1
> ii libegl1-mesa [libegl1-x11] 13.0.6-1+b2
> ii libfontconfig1 2.12.3-0.2
> ii libfreetype6 2.8-0.2
> ii libgbm1 13.0.6-1+b2
> ii libgcc1 1:7.2.0-1
> ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2
> ii libglib2.0-0 2.53.4-3

Bug#865502: #865502,siege: apparently runs, shows a report, then crashes while exiting

[Dmitry Smirnov]

Package: siege
Version: 4.0.2-1.1+b1

I have exactly the same problem with crash at the very end of run:

*** Error in `siege': free(): invalid pointer: 0x8174cf08 ***

I confirm that patch fixed the problem for me as well.

--
Regards,
 Dmitry.

Bug#873792: qjackctl will not start at all

[Ed Peguillan III]

Just for posterity, qjackctl and virtualbox worked until I restarted my 
machine, then it started throwing the same errors again. I eventually 
found that installing package 'freetype2-demos' fixed it.


Ed

On Fri, 1 Sep 2017 12:38:56 +0200 Sebastian Ramacher 
 wrote:

> On 2017-09-01 03:38:28, Ed Peguillan III wrote:
> > My mail client replied to the wrong address, my apologies.
> >
> > After performing
> > $ sudo mv 
/usr/lib/x86_64-linux-gnu/freetype-infinality/liblibfreetype.so.6

> > ~
> >
> > qjackctl and virtualbox seem to start and work normally.
> >
> > It's too bad that I can't use infinality fonts anymore, my screen 
is back to

> > looking terrible.
> >
> > Thank you for your help! This bug can be closed.
>
> Thanks, closing.
> --
> Sebastian Ramacher

Bug#874321: backtraces from generic extractor: "Compressed file ended before the end-of-stream marker was reached"

[Joey Hess]

Package: youtube-dl
Version: 2017.05.18.1-1
Severity: normal

joey@darkstar:~>youtube-dl  http://debian.org/
[generic] debian: Requesting header
[redirect] Following redirect to http://www.debian.org/
[generic] www.debian: Requesting header
WARNING: Falling back on generic information extractor.
[generic] www.debian: Downloading webpage
Traceback (most recent call last):
  File "/usr/bin/youtube-dl", line 11, in 
load_entry_point('youtube-dl==2017.5.18.1', 'console_scripts', 
'youtube-dl')()
  File "/usr/lib/python3/dist-packages/youtube_dl/__init__.py", line 465, in 
main
_real_main(argv)
  File "/usr/lib/python3/dist-packages/youtube_dl/__init__.py", line 455, in 
_real_main
retcode = ydl.download(all_urls)
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 1896, in 
download
url, force_generic_extractor=self.params.get('force_generic_extractor', 
False))
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 771, in 
extract_info
return self.process_ie_result(ie_result, download, extra_info)
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 832, in 
process_ie_result
extra_info=extra_info)
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 760, in 
extract_info
ie_result = ie.extract(url)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py", line 
433, in extract
ie_result = self._real_extract(url)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/generic.py", line 
1942, in _real_extract
full_response = self._request_webpage(request, video_id)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py", line 
502, in _request_webpage
return self._downloader.urlopen(url_or_request)
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 2106, in 
urlopen
return self._opener.open(req, timeout=self._socket_timeout)
  File "/usr/lib/python3.5/urllib/request.py", line 472, in open
response = meth(req, response)
  File "/usr/lib/python3/dist-packages/youtube_dl/utils.py", line 981, in 
http_response
uncompressed = io.BytesIO(gz.read())
  File "/usr/lib/python3.5/gzip.py", line 274, in read
return self._buffer.read(size)
  File "/usr/lib/python3.5/gzip.py", line 480, in read
raise EOFError("Compressed file ended before the "
EOFError: Compressed file ended before the end-of-stream marker was reached

I'm able to reproduce this over an Excede satelite internet connection,
but not from a VPS. There's some transparent proxying involved,
which is apparently confusing the gzip Content-encoding support in
youtube-dl. (I have not seen the transparent proxying cause any
other problems with other programs.) Only http urls cause the problem,
since https bypasses the transparent proxy.

I edited the code to dump out the gzip compressed content it received
before it trys to decompress it.

joey@darkstar:~>file dump
dump: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
joey@darkstar:~>ls -l dump
-rw-r--r-- 1 joey joey 4744 Sep  4 21:00 dump
joey@darkstar:~>zcat < dump > data
gzip: stdin: unexpected end of file
joey@darkstar:~>curl --compressed -so raw http://www.debian.org/
joey@darkstar:~>cmp data raw
joey@darkstar:~>

So, it's apparently downloaded a gzip compressed chunk of data
which contains the whole url, but the gzip data is somehow shady,
although not in a way that prevents decompressing the whole page
content. I've attached the `dump` file to this bug report.

I've also attached a `wireshark.pcapng` which has the curl traffic
first followed by youtube-dl.

I suspect that the gzip compressed data has a missing gzip footer.
Normally, the last 8 bytes of `dump` would be the gzip footer. Those are:
93 C6 FF 00 00 00 FF FF
If that were a footer, the size would be  which is not the
actual size. And, changing any of these bytes except for the last one
exposes parts of the compression dictionary, so they must not be
part of the footer, and seem to instead be part of the DEFLATE data.

Similarly, looking at the http response to curl, 
the last 8 bytes of that are
9D 7B D7 66 E6 3B 00 00
Which again does not look like a gzip footer.

curl seems to follow Postel's law in handling this, so perhaps youtube-dl
should too?

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

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

Versions of packages youtube-dl depends on:
ii  dpkg   1.18.24
ii  python33.5.3-3
ii  python3-pkg-resources  36.2.7-2

Versions of packages youtube-dl recommends:
ii  aria21.32.0-1
ii  ca-certificates  20170717
ii  curl 7.55.1-1
ii 

Bug#760021: lintian: check for not wrap-and-sort formatted files

[Eric Dorland]

* Mattia Rizzolo (mat...@debian.org) wrote:
> On Thu, Aug 31, 2017 at 10:06:52AM +0100, Chris Lamb wrote:
> > > lintian: check for not wrap-and-sort formatted files
> > 
> > Good idea.
> 
> I don't think it is.
> wrap-and-sort (or the equivalent from cme) is not widely enough adopted
> as of yet.  I personally try to have all my sponsee use it, and I
> sometimes force a wrap-and-sort into NMUs, but it's still too rare.
> 
> Also, wouldn't you need to pick only one of the -t, -s, -a combinations?
> I see people disliking -t (trailing commas) also because it's not in
> policy, and arguments for and agaist -s and -a; see the wrap-and-sort
> manual if you don't understand what I'm talking about.
> And that's without considering cme's configuration.

You wouldn't necessarily have to proscribe one single wrap-and-sort
variant, you could check a number of variations and see if any of them
fit the current set of files. But yes, if policy could be more
prescriptive about what the formatting should look like that would be cool.

> > Alas, I fear that this would either require calling out to
> > wrap-and-sort (!) and diffing the result, or essentially reimplementing
> > it within Lintian itself?
> 
> You could use libconfig-model-dpkg-perl, most probably.  Therefore
> elevating cme's implementation.
> 
> Summing up: I don't think it's a practise ready to be nudged by lintian
> yet.

Not even at the pedantic level?

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#868286: Pending fixes for bugs in the plantuml package

[pkg-java-maintainers]

tag 868286 + pending
thanks

Some bugs in the plantuml package are closed in revision
051493f7d785dbaad8070ec9896f8cd1c62ed447 in branch 'master' by
Christopher Hoskin

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/plantuml.git/commit/?id=051493f

Commit message:

Fix "New version available" package upstream release (1.2017.15), new epoch 
(Closes: #868286)

Bug#874121: lintian: Please add more packagename to section mappings

[Guillem Jover]

Hi!

On Mon, 2017-09-04 at 22:27:03 +0100, Chris Lamb wrote:
> Thanks for the patch.
> 
>   ^lib.*\d[ad]?$  => lib
>  ^^^
> 
> Shouldn't this be "libs" … ?

Indeed, attached a revised version with some other corrections
included.

Thanks,
Guillem
From c6e65a85c0dc08d251bccb103e0cef0c014bcbf9 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 3 Sep 2017 15:42:26 +0200
Subject: [PATCH] data/fields/name_section_mappings: Add more mappings

Signed-off-by: Guillem Jover 
---
 data/fields/name_section_mappings | 32 +---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/data/fields/name_section_mappings b/data/fields/name_section_mappings
index 116fa3885..12e9bb89b 100644
--- a/data/fields/name_section_mappings
+++ b/data/fields/name_section_mappings
@@ -2,18 +2,44 @@
 # this list is tried from top to bottom
 -docs?$  => doc
 -dbg(?:sym)?$=> debug
+# application or framework specific
+^lib(?:apache2|nginx)-mod-  => httpd
+^lighttpd-mod   => httpd
+\.(?:framework|tool|app)(?:-common)?$   => gnustep
+^gnustep-   => gnustep
+^moblin-=> embedded
+# language-specific
 ^node-   => javascript
 ^(?:python-)?zope=> zope
 ^python3?-   => python
 ^r-(?:cran|bioc|other)-  => gnu-r
+^(?:cl|elpa)-   => lisp
+-elisp(?:-.*)$  => lisp
+^lib.*-guile$   => lisp
+^guile- => lisp
 ^lib.*-perl$ => perl
 lib.*-cil(?:-dev)?$  => cli-mono
-^lib.*-(?:java|gcj)$ => java
-^(?:lib)php- => php
+^lib.*-(?:java|gcj|jni)$=> java
+^(?:lib)?php(?:\d(?:\.\d)?)?-   => php
+^lib-.*-php$=> php
+^haskell-   => haskell
 ^lib(?:hugs|ghc6?)-  => haskell
 ^lib.*-ruby(?:1\.\d)?$   => ruby
+^ruby-  => ruby
+^lib.*-rust-dev$=> rust
+^rust-  => rust
 ^lib.*-(?:ocaml|camlp4)-dev$ => ocaml
 ^libjs-  => javascript
+^lib.*-(tcl|lua|gst)=> interpreters
+# data files
 ^gir\d+\.\d+-.*-\d+\.\d+$=> introspection
+^(?:x?fonts|ttf)-   => fonts
+^(?:aspell|hunspell|myspell|mythes)-=> localization
+^hyphen-[a-z]{2}(?:-[a-z]{2})?$ => localization
+^dict-freedict- => localization
+^gcompris-sound-=> localization
+-l10n(?:-.*)?$  => localization
+-(dkms|firmware)$   => kernel
 # catch remaining should be after specific lib
-^lib.*-dev$  => libdevel
+^lib.*-(dev|headers)$   => libdevel
+^lib.*\d[ad]?$  => libs
-- 
2.14.1

Bug#874301: libgtop2: FTBFS on kFreeBSD: strlcpy undefined

[Aaron M. Ucko]

Jeremy Bicha  writes:

> I'm not set up to test builds for those architectures.

Neither am I, except via porter boxes; I just like to make sure that
build failures involving NEW binary packages don't slip through the
cracks.  Any of these changes should be a small formal fix, though.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#813431: python-numpy: Debian adds include dir symlinks that break virtualenvs

[Sandro Tosi]

mind having a look at these packages:
https://codesearch.debian.net/search?q=%2Fusr%2Finclude%2Fnumpy%7C%2Fusr%2Finclude%2Fpython.*%2Fnumpy

would they work without any change if i stop providing those symlinks?
if they require changes, please file bugs and block this one against
them

thx!

On Fri, Aug 18, 2017 at 7:24 PM, Pauli Virtanen  wrote:
> Hi,
>
> Ping --- any news on this front?
>
> The symlinks added by Debian still break installing old numpy versions
> and packages depending on them in virtualenvs. These symlinks are not
> necessary, because Python packages obtain the appropriate include paths
> via `numpy.get_include()`.
>
> --
> Pauli Virtanen



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#872459: python-numpy: please make the output reproducible

[Sandro Tosi]

Hey Chris,

On Thu, Aug 17, 2017 at 12:29 PM, Chris Lamb  wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed
> that python-numpy generates output that is not reproducible. This
> affects packages such as numexpr.
>
> Patch attached.

would you like to forward it upstream or do you prefer me to do so?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#789927: Anthy library breakage

[NIIBE Yutaka]

Osamu Aoki  wrote:
> If what NOKUBI Takatsugu's comment is correct, I wonder why anthy is
> upgraded without coordinating with key users:
>  ibus
>  uim
>  fcitx
>
> (Please note these have many dependence packages so the testing
> migration is slow if package version dependency is correctly recorded.)

I'm sorry.  It was me who upload the anthy package for Sid.  Apparently,
I was conscious of the impact when I was uploading it for experimental
in 2015.  In August 2017, I forgot this issue when I was asked uploading
new Anthy for Debian.  I had thought as if it's only anthy's own problem.

The original plan in 2010 was doing the migration in Debian around 2010.
It didn't occur because of our human resources (and troubles).  What we
did in 2010 was: We made a team as pkg-anthy on Alioth and revived
upstream development to collect patches floating around and to merge.
Then, in 2015, I uploaded it in experimental.

> I agree moving to utf8 is right thing to do but this breakage is
> something we should avoid.

Yes.

> If -dev package version is bumped, we can have slow migration without
> breaking packages depending on old anthy.  But if we share the same -dev
> package name, all related package needs to be uploaded together
> (otherwise we suffer long broken sid system).

Thanks.  Now, I understand (I didn't know that fully).  I should have
learned before uploading to Sid.

> But if library change its API spec from non-utf8 to utf8, this needs to
> be coordinated carefully.

I learned.

> It's not simple. What does people think is the right way to fix.

I have been using Anthy since its birth, but I only use through Emacs
with egg.  Even if I don't use, I should be careful when I touch Debian
package.

Today, the Emacs module egg requires total rewrite for Emacs 25, due to
the change of Emacs (display property thing).  I was considering making
a loadable module for Emacs for Anthy.  That was another pressure.


Any suggestions are welcome.  It seems for me that it would be better
to change the -dev package name.
-- 

Bug#873757: e2fsck: buffer overflow in check_block_bitmaps()

[Theodore Ts'o]

tags 873757 +pending
thanks

Thanks for the bug report!  Proposed fix:

commit 4ed30b8e942bc75e8a2561b85719b6462bdce2cf
Author: Theodore Ts'o 
Date:   Mon Sep 4 20:32:22 2017 -0400

e2fsck, libext2fs: add checks for insanely large file systems

If the blocks count field is too large, this can cause numberic
overflows which can result in buffer overflows.

Addresses-Debian-Bug: #873757

Signed-off-by: Theodore Ts'o 
Reported-by: Jakub Wilk 

diff --git a/e2fsck/super.c b/e2fsck/super.c
index 8153f2bfe..47c89c56f 100644
--- a/e2fsck/super.c
+++ b/e2fsck/super.c
@@ -41,6 +41,23 @@ static void check_super_value(e2fsck_t ctx, const char 
*descr,
}
 }
 
+static void check_super_value64(e2fsck_t ctx, const char *descr,
+   __u64 value, int flags,
+   __u64 min_val, __u64 max_val)
+{
+   struct  problem_context pctx;
+
+   if ((flags & MIN_CHECK && value < min_val) ||
+   (flags & MAX_CHECK && value > max_val) ||
+   (flags & LOG2_CHECK && (value & (value - 1)) != 0)) {
+   clear_problem_context();
+   pctx.num = value;
+   pctx.str = descr;
+   fix_problem(ctx, PR_0_MISC_CORRUPT_SUPER, );
+   ctx->flags |= E2F_FLAG_ABORT; /* never get here! */
+   }
+}
+
 /*
  * helper function to release an inode
  */
@@ -468,6 +485,7 @@ void check_super_block(e2fsck_t ctx)
problem_t   problem;
blk64_t blocks_per_group = fs->super->s_blocks_per_group;
__u32   bpg_max, cpg_max;
+   __u64   blks_max;
int inodes_per_block;
int inode_size;
int accept_time_fudge;
@@ -497,6 +515,15 @@ void check_super_block(e2fsck_t ctx)
ctx->invalid_inode_table_flag = (int *) e2fsck_allocate_memory(ctx,
sizeof(int) * fs->group_desc_count, "invalid_inode_table");
 
+   blks_max = (1ULL << 32) * EXT2_MAX_BLOCKS_PER_GROUP(fs->super);
+   if (ext2fs_has_feature_64bit(fs->super)) {
+   if (blks_max > ((1ULL << 48) - 1))
+   blks_max = (1ULL << 48) - 1;
+   } else {
+   if (blks_max > ((1ULL << 32) - 1))
+   blks_max = (1ULL << 32) - 1;
+   }
+
clear_problem_context();
 
/*
@@ -504,8 +531,8 @@ void check_super_block(e2fsck_t ctx)
 */
check_super_value(ctx, "inodes_count", sb->s_inodes_count,
  MIN_CHECK, 1, 0);
-   check_super_value(ctx, "blocks_count", ext2fs_blocks_count(sb),
- MIN_CHECK, 1, 0);
+   check_super_value64(ctx, "blocks_count", ext2fs_blocks_count(sb),
+   MIN_CHECK | MAX_CHECK, 1, blks_max);
check_super_value(ctx, "first_data_block", sb->s_first_data_block,
  MAX_CHECK, 0, ext2fs_blocks_count(sb));
check_super_value(ctx, "log_block_size", sb->s_log_block_size,
diff --git a/lib/ext2fs/openfs.c b/lib/ext2fs/openfs.c
index da03bc147..f74cd2458 100644
--- a/lib/ext2fs/openfs.c
+++ b/lib/ext2fs/openfs.c
@@ -122,6 +122,7 @@ errcode_t ext2fs_open2(const char *name, const char 
*io_options,
char*dest, *cp;
int group_zero_adjust = 0;
int inode_size;
+   __u64   groups_cnt;
 #ifdef WORDS_BIGENDIAN
unsigned intgroups_per_block;
struct ext2_group_desc *gdp;
@@ -371,9 +372,14 @@ errcode_t ext2fs_open2(const char *name, const char 
*io_options,
retval = EXT2_ET_CORRUPT_SUPERBLOCK;
goto cleanup;
}
-   fs->group_desc_count = ext2fs_div64_ceil(ext2fs_blocks_count(fs->super) 
-
-fs->super->s_first_data_block,
-blocks_per_group);
+   groups_cnt = ext2fs_div64_ceil(ext2fs_blocks_count(fs->super) -
+  fs->super->s_first_data_block,
+  blocks_per_group);
+   if (groups_cnt >> 32) {
+   retval = EXT2_ET_CORRUPT_SUPERBLOCK;
+   goto cleanup;
+   }
+   fs->group_desc_count =  groups_cnt;
if (fs->group_desc_count * EXT2_INODES_PER_GROUP(fs->super) !=
fs->super->s_inodes_count) {
retval = EXT2_ET_CORRUPT_SUPERBLOCK;

Bug#874320: adequate: adequate shows a false positive at libgssapi-krb5-2 ?

[shirish शिरीष]

Package: adequate
Version: 0.15.1
Severity: normal

Dear Maintainer,

Thank you for maintaining adequate for so long. It makes it easier to
know of potential issues before they become an issue :)

Anyways I don't know/haven't looked up as to what criteria does
adequate use to tell if a file is obsolete or not.

For e.g. see -

[$] adequate libgssapi-krb5-2

libgssapi-krb5-2:amd64: obsolete-conffile /etc/gss/mech.d/README

Whereas when you go to /etc/gss/mech.d/README you see this -

obsolete-conffile: No such file or directory
 1  Any file places in this directory ending in .conf will be read as a
 2  GSS-API mechanism configuration file, and the mechanisms described in
 3  that file will be dynamically loaded.
 4  

Don't see any typical examples of conffiles as seen by me but more like note/s.


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

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

Versions of packages adequate depends on:
ii  debconf  1.5.63
ii  perl 5.26.0-5

Versions of packages adequate recommends:
ii  pkg-config  0.29-4+b1

adequate suggests no packages.

-- Configuration Files:
/etc/apt/apt.conf.d/20adequate changed:
// If you set this to "true", adequate will run on every install, reporting the
// results via debconf.
Adequate::Enabled "true";
DPkg::Pre-Install-Pkgs {
"adequate --help >/dev/null 2>&1 || exit 0; exec adequate --user
nobody --apt-preinst";
};
DPkg::Post-Invoke {
"adequate --help >/dev/null 2>&1 || exit 0;
DEBIAN_FRONTEND=readline exec adequate --debconf --user nobody
--pending";
};
DPkg::Tools::Options::adequate::Version "2";


-- no debconf information



-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#808336: Also adequate reports unattended-ugrades as having obsolete conffile

[shirish शिरीष]

Dear Maintainer,

See adequate -

[$] aptitude show adequate

Package: adequate
Version: 0.15.1
State: installed
Automatically installed: no
Priority: optional
Section: utils
Maintainer: Jakub Wilk 
Architecture: all
Uncompressed Size: 80.9 k
Depends: perl (>= 5.14), debconf
Recommends: pkg-config (>= 0.27)
Description: Debian package quality testing tool
 adequate checks packages installed on the system and reports bugs and
policy violations.

 The following checks are currently implemented:
 * broken symlinks;
 * missing copyright file;
 * obsolete conffiles;
 * Python modules not byte-compiled;
 * /bin and /sbin binaries requiring /usr/lib libraries;
 * missing libraries, undefined symbols, symbol size mismatches;
 * license conflicts;
 * program name collisions;
 * missing alternatives;
 * missing binfmt interpreters and detectors;
 * missing pkg-config dependencies.
Homepage: http://jwilk.net/software/adequate
Tags: implemented-in::perl

We are interested to know about if there are any obsolete-conffile

And as can be seen adequate reports it to be obsolete conffile -

─[$] adequate unattended-upgrades

unattended-upgrades: obsolete-conffile /etc/apt/apt.conf.d/50unattended-upgrades

Please fix it as soon as possible. From the bug-report it might be
just simple as simply changing from jessie to stretch or seeing if any
changes in curl or whatever is used to download updates and upgrades
is in working order or not.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#874319: nginx-common: adequate shows obsolete-conffile in /etc/init/nginx.conf script

[shirish शिरीष]

Package: nginx-common
Version: 1.13.4-1
Severity: normal

Dear Maintainer,

Thank you for maintaining nginx for so long. Today when I was
upgrading my system was hit with this -

nginx-common: obsolete-conffile /etc/init/nginx.conf

And as can be seen below -

─[$] adequate nginx-common

nginx-common: obsolete-conffile /etc/init/nginx.conf

It appears adequate is right. Please fix it as soon as possible.

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

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

Versions of packages nginx-common depends on:
ii  debconf  1.5.63
ii  init-system-helpers  1.49
ii  lsb-base 9.20170808

nginx-common recommends no packages.

Versions of packages nginx-common suggests:
pn  fcgiwrap   
pn  nginx-doc  
ii  ssl-cert   1.0.39

-- Configuration Files:
/etc/nginx/sites-available/default changed [not included]

-- debconf information:
  nginx/log-symlinks:


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#874318: epiphany-browser-data: adequate reports obsolete conffile as in mime-types-permissions.xml under epiphany-browser-data

[shirish शिरीष]

Package: epiphany-browser-data
Version: 3.24.3-1
Severity: normal

Dear Maintainer,

Thank you for maintaining epiphany browser for so long. Recently while
upgrading, came across this -

epiphany-browser-data: obsolete-conffile
/etc/gnome/epiphany/mime-types-permissions.xml

To check it again, I again ran the package under adequate -

[$] adequate epiphany-browser-data

epiphany-browser-data: obsolete-conffile
/etc/gnome/epiphany/mime-types-permissions.xml

And as can be seen adequate complains about obsolete conffile, please fix it.


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

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

Versions of packages epiphany-browser-data depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1

Versions of packages epiphany-browser-data recommends:
ii  epiphany-browser  3.24.3-1

epiphany-browser-data suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#874317: golang-1.9: Please add patch to reintroduce POWER5 support

[John Paul Adrian Glaubitz]

Source: golang-1.9
Version: 1.9-1
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64

Hi!

Starting with golang-1.9, upstream decided to drop support for
POWER5 on big-endian ppc64 systems and raised the minimum
instruction set for these systems to POWER8.

Since Debian's ppc64 port is still and will always be based
on POWER5, I have decided to revert the changes in question
to make golang-1.9 work on POWER5. Luckily, the changes in
question were actually just code clean-ups and simplifications,
none of which had actual performance impact on little-endian
ppc64 systems.

On a sidenote: Raising the instruction set level for the big-
endian ppc64 port to POWER8 actually never made any sense as
every Linux distribution available actually uses POWER5
on big-endian ppc64 systems. If users want to use POWER8,
they have to install a little-endian ppc64 port which is
what most users want anyway due to the improved level of
compatibility with most existing applications. No one will
buy a POWER8-capable machine and run a big-endian ppc64
port on it, there is simply no use case for the changes
upstream introduced.

Thus, it would be great if you could incorporate this patch
to the golang-1.9 Debian package to make it build on ppc64
again. I'm aware that some IBM folk might not agree with
this change, but I think it makes sense for Debian and
its users. We just released our first installation image
for ppc64 ever, so I am expecting a larger number of
Debian ppc64 installations in the future.

Thanks for consideration!

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Re-add support for POWER5
 Starting with golang-1.9, upstream dropped support for
 POWER5 on big-endian ppc64 systems to clean up the code
 a bit. This patch reverts a number of changes that upstream
 made to remove POWER5 support for ppc64 big-endian. This
 change does not have any negative impact on ppc64 little-
 endian targets but it will allow us to continue using
 golang-1.9 on ppc64 big-endian a little longer.
Author: John Paul Adrian Glaubitz 
Upstream: https://github.com/golang/go/issues/19074
Last-Update: 2017-09-04

Index: golang-1.9-1.9/src/cmd/compile/internal/ppc64/ssa.go
===
--- golang-1.9-1.9.orig/src/cmd/compile/internal/ppc64/ssa.go
+++ golang-1.9-1.9/src/cmd/compile/internal/ppc64/ssa.go
@@ -13,6 +13,20 @@ import (
"math"
 )
 
+var condOps = map[ssa.Op]obj.As{
+   ssa.OpPPC64Equal:ppc64.ABEQ,
+   ssa.OpPPC64NotEqual: ppc64.ABNE,
+   ssa.OpPPC64LessThan: ppc64.ABLT,
+   ssa.OpPPC64GreaterEqual: ppc64.ABGE,
+   ssa.OpPPC64GreaterThan:  ppc64.ABGT,
+   ssa.OpPPC64LessEqual:ppc64.ABLE,
+
+   ssa.OpPPC64FLessThan: ppc64.ABLT, // 1 branch for FCMP
+   ssa.OpPPC64FGreaterThan:  ppc64.ABGT, // 1 branch for FCMP
+   ssa.OpPPC64FLessEqual:ppc64.ABLT, // 2 branches for FCMP <=, second 
is BEQ
+   ssa.OpPPC64FGreaterEqual: ppc64.ABGT, // 2 branches for FCMP >=, second 
is BEQ
+}
+
 // iselOp encodes mapping of comparison operations onto ISEL operands
 type iselOp struct {
condint64
@@ -760,6 +774,27 @@ func ssaGenValue(s *gc.SSAGenState, v *s
//   rtmp := 1
//   isel rt,0,rtmp,!cond // rt is target in ppc asm
 
+   if v.Block.Func.Config.OldArch {
+   p := s.Prog(ppc64.AMOVD)
+   p.From.Type = obj.TYPE_CONST
+   p.From.Offset = 1
+   p.To.Type = obj.TYPE_REG
+   p.To.Reg = v.Reg()
+
+   pb := s.Prog(condOps[v.Op])
+   pb.To.Type = obj.TYPE_BRANCH
+
+   p = s.Prog(ppc64.AMOVD)
+   p.From.Type = obj.TYPE_CONST
+   p.From.Offset = 0
+   p.To.Type = obj.TYPE_REG
+   p.To.Reg = v.Reg()
+
+   p = s.Prog(obj.ANOP)
+   gc.Patch(pb, p)
+   break
+   }
+   // Modern PPC uses ISEL
p := s.Prog(ppc64.AMOVD)
p.From.Type = obj.TYPE_CONST
p.From.Offset = 1
@@ -771,6 +806,30 @@ func ssaGenValue(s *gc.SSAGenState, v *s
case ssa.OpPPC64FLessEqual, // These include a second branch for EQ -- 
dealing with NaN prevents REL= to !REL conversion
ssa.OpPPC64FGreaterEqual:
 
+   if v.Block.Func.Config.OldArch {
+   p := s.Prog(ppc64.AMOVW)
+   p.From.Type = obj.TYPE_CONST
+   p.From.Offset = 1
+   p.To.Type = obj.TYPE_REG
+   p.To.Reg = 

Bug#874100: thunderbird: Let's clarify what's the upstream for our AppArmor profile

[Simon Deziel]

On 2017-09-03 10:34 AM, Simon Deziel wrote:
> Hi,
> 
> Thanks for bringing this problem to my attention.
> 
> On 2017-09-03 03:01 AM, intrig...@debian.org wrote:
>> Hi!
>>
>> (Context: tackling my AppArmor-in-Debian backlog in order to move the
>> "let's enable AppArmor by default" topic forward.)
>>
>> Today I had a look at https://bugs.debian.org/855346 and thought
>> "well, I'll simply fix myself the issue I've raised when reviewing
>> https://code.launchpad.net/%7Eu-d/apparmor-profiles/+git/apparmor-profiles/+merge/320276/
>> and then will submit for merging upstream + to Debian". And then
>> I realized that the profile shipped in Debian has diverged from the
>> upstream / shared / cross-distro one: quite a few changes have been
>> cherry-picked from Simon's repo
>> (https://github.com/simondeziel/aa-profiles/) and didn't make their
>> way to the apparmor-profiles repository. And actually, currently the
>> profile in the packaging Vcs-Git is exactly Simon's one, modulo
>> a 1-newline difference.
>>
>> I see two problems with this situation:
>>
>>   * It's not clear to contributors where they should submit
>> improvements: e.g. if Ulrike's merge request was accepted
>> upstream, someone would still have to merge it with Simon's
>> profile (via another PR on GitHub?).
>>
>>   * It's not clear to the Thunderbird maintainers where they should
>> pick new versions from.
> 
> This situation is probably my fault, I apologize. I think we ended up
> with the current situation because merge proposals in apparmor-profiles
> are not reviewed quickly enough (and/or I'm not patient enough).
> 
>> I see two options to fix this confusing situation.
>>
>> A. Use lp:apparmor-profiles as the upstream
>>
>>This implies that Simon's improvements are submitted to
>>lp:apparmor-profiles. I guess it would be much easier to do so if
>>Simon's repo was a fork of lp:apparmor-profiles (that's in Git
>>now! :)  Who would handle that on a regular basis?
>>
>> B. Use Simon's repository as the upstream
>>
>>To reduce confusion, then I think we should:
>>
>>1. Document *inside* the profile where it comes from / where
>>   improvements shall be submitted.
>>2. Empty the usr.bin.thunderbird profile in lp:apparmor-profiles,
>>   pointing to the de facto new upstream repository.
>>
>> Personally I would prefer (A), that would avoid having to
>> learn/document yet another workflow. But I suspect it's not realistic,
>> and I prefer us doing (B) correctly that (A) poorly.
> 
> I'm OK with A and wouldn't mind sending any new rules to the official
> repo.

Let's see how it goes:

https://code.launchpad.net/~sdeziel/+git/apparmor-profiles/+ref/thunderbird-icedove-debian

Regards,
Simon



signature.asc
Description: OpenPGP digital signature

Bug#874195: libreoffice: Please enable Albanian (sq) l10n package

[Lior Kaplan]

On Tue, Sep 5, 2017 at 1:32 AM, Rene Engelhard  wrote:

> Hi,
>
> On Mon, Sep 04, 2017 at 06:31:54AM +0200, Rene Engelhard wrote:
> > On Mon, Sep 04, 2017 at 02:13:25AM +0300, Lior Kaplan wrote:
> > >Translation of Albanian is currently at 60-65%, would be nice to
> have a
> > >l10n package as upstream already provides them
> >
> > Hmm. 60-65% is quite low. Normally I'd put the threshold at 80-90%...
> > I'd more consider it a bug upstream ships it, thenaagain they probably
> build
> > with all languages? (Don't see any --with-lang in
>
> Oh, my. This is hilarious.
>
> I wrote a quick and dirty script to check the locales[1]:
>
> Even stuff we have in the packages right now is bad.
>
> Even ar and he and hi and... Is he really so bad?
>
> Even oc is better than them...
>


Yes, Hebrew does need attention. If it wasn't the need to pass through NEW
each time
I would be happy to do something more dynamic for this. But at the moment,
we can
raise the issue during the LibreOffice conference in Rome and than take a
decision
after talking (and warning) the translators.

Kaplan

Bug#874312: Acknowledgement (kdelibs4support: FTBFS on hppa - segmentation fault in desktoptojson)

[John David Anglin]

Function is __sync_sub_and_fetch_4 and it is called from 
ServiceTypeDefinition::parseValue(QByteArray const&, QString const&) const:

   0x00018a18 <+0>: stw rp,-14(sp)
   0x00018a1c <+4>: ldo 140(sp),sp
   0x00018a20 <+8>: stw r7,-a4(sp)
   0x00018a24 <+12>:ldo -fc(sp),r7
   0x00018a28 <+16>:stw r13,-bc(sp)
   0x00018a2c <+20>:copy r25,r13
   0x00018a30 <+24>:copy r26,r25
   0x00018a34 <+28>:stw r12,-b8(sp)
   0x00018a38 <+32>:copy r7,r26
   0x00018a3c <+36>:stw r11,-b4(sp)
   0x00018a40 <+40>:copy r19,r11
   0x00018a44 <+44>:stw r10,-b0(sp)
   0x00018a48 <+48>:copy r24,r10
   0x00018a4c <+52>:stw r9,-ac(sp)
   0x00018a50 <+56>:stw r8,-a8(sp)
   0x00018a54 <+60>:stw r3,-94(sp)
   0x00018a58 <+64>:stw r19,-20(sp)
   0x00018a5c <+68>:stw r14,-c0(sp)
   0x00018a60 <+72>:stw r6,-a0(sp)
   0x00018a64 <+76>:stw r5,-9c(sp)
   0x00018a68 <+80>:stw r4,-98(sp)
   0x00018a6c <+84>:b,l 0x1fd28 
,rp
   0x00018a70 <+88>:copy ret0,r9
   0x00018a74 <+92>:ldw 0(r7),r12
   0x00018a78 <+96>:ldw 4(r12),ret0
   0x00018a7c <+100>:   ldw c(r12),r8
   0x00018a80 <+104>:   add,l r12,r8,r3
   0x00018a84 <+108>:   shladd,l ret0,3,r8,r8
   0x00018a88 <+112>:   stw r3,4(r7)
   0x00018a8c <+116>:   add,l r12,r8,r8
   0x00018a90 <+120>:   ldi 1,ret0
   0x00018a94 <+124>:   stw r8,8(r7)
   0x00018a98 <+128>:   copy r11,r19
   0x00018a9c <+132>:   cmpb,= r8,r3,0x18ad0 

   0x00018aa0 <+136>:   stw ret0,c(r7)
   0x00018aa4 <+140>:   ldw 0(r13),r6
   0x00018aa8 <+144>:   copy ret0,r14
   0x00018aac <+148>:   ldw 4(r6),r5
   0x00018ab0 <+152>:   ldw 0(r3),ret0
   0x00018ab4 <+156>:   ldw 4(ret0),r20
   0x00018ab8 <+160>:   cmpb,= r5,r20,0x18cac 

   0x00018abc <+164>:   copy r19,r4
   0x00018ac0 <+168>:   ldo 8(r3),r3
   0x00018ac4 <+172>:   stw r14,c(r7)
   0x00018ac8 <+176>:   cmpb,<> r8,r3,0x18ab0 

   0x00018acc <+180>:   stw r3,4(r7)
   0x00018ad0 <+184>:   ldw 0(r12),ret0
   0x00018ad4 <+188>:   cmpib,= 0,ret0,0x18f58 

   0x00018ad8 <+192>:   copy r19,r4
   0x00018adc <+196>:   cmpib,= -1,ret0,0x18af4 

   0x00018ae0 <+200>:   ldi 1,r25
   0x00018ae4 <+204>:   b,l 0x22a78 <__sync_sub_and_fetch_4>,rp
   0x00018ae8 <+208>:   copy r12,r26
   0x00018aec <+212>:   cmpib,= 0,ret0,0x18f54 

   0x00018af0 <+216>:   copy r4,r19
   0x00018af4 <+220>:   b,l 0x16880 ,rp
   0x00018af8 <+224>:   copy r19,r4
   0x00018afc <+228>:   ldb 8(ret0),ret0
   0x00018b00 <+232>:   cmpib,= 0,ret0,0x18c98 

   0x00018b04 <+236>:   copy r4,r19
   0x00018b08 <+240>:   copy r19,r4
   0x00018b0c <+244>:   b,l 0x16880 ,rp
   0x00018b10 <+248>:   ldo -110(sp),r3
   0x00018b14 <+252>:   ldw 4(ret0),r21
   0x00018b18 <+256>:   stw r0,-134(sp)
   0x00018b1c <+260>:   ldi 2,ret0
   0x00018b20 <+264>:   ldo -138(sp),r20
   0x00018b24 <+268>:   stw ret0,-138(sp)
   0x00018b28 <+272>:   copy r4,r19
   0x00018b2c <+276>:   copy r7,ret0
   0x00018b30 <+280>:   stw r0,-130(sp)
   0x00018b34 <+284>:   copy r19,r4
   0x00018b38 <+288>:   copy r20,r26
   0x00018b3c <+292>:   stw r0,-12c(sp)
   0x00018b40 <+296>:   b,l 0x12db4,rp
   0x00018b44 <+300>:   stw r21,-128(sp)
   0x00018b48 <+304>:   ldw 0(r7),r5
   0x00018b4c <+308>:   copy r4,r19
   0x00018b50 <+312>:   addil L%0,dp,r1
   0x00018b54 <+316>:   ldw 6b4(r1),r26
   0x00018b58 <+320>:   copy r3,ret0
   0x00018b5c <+324>:   ldi 1d,r25
   0x00018b60 <+328>:   b,l 0x12c64,rp
   0x00018b64 <+332>:   copy r19,r4
   0x00018b68 <+336>:   copy r4,r19
   0x00018b6c <+340>:   copy r3,r25
   0x00018b70 <+344>:   copy r5,r26
   0x00018b74 <+348>:   b,l 0x12b84,rp
   0x00018b78 <+352>:   copy r19,r4
   0x00018b7c <+356>:   ldw 0(r3),r26
   0x00018b80 <+360>:   copy r4,r19
   0x00018b84 <+364>:   ldw 0(r26),ret0
   0x00018b88 <+368>:   cmpib,= 0,ret0,0x18bac 

   0x00018b8c <+372>:   copy r19,r4
   0x00018b90 <+376>:   cmpiclr,<> -1,ret0,r0
   0x00018b94 <+380>:   b,l,n 0x18bc0 
,r0
   0x00018b98 <+384>:   b,l 0x22a78 <__sync_sub_and_fetch_4>,rp
   0x00018b9c <+388>:   ldi 1,r25
   0x00018ba0 <+392>:   cmpib,<> 0,ret0,0x18bc0 

   0x00018ba4 <+396>:   copy r4,r19
   0x00018ba8 

Bug#874315: ITP: simulide -- real time electronic circuit simulator

[Milan Kupcevic]

Package: wnpp
Severity: wishlist
Owner: Milan Kupcevic 

* Package name: simulide
  Version : 0.1.5
  Upstream Author : Santiago González 
* URL : https://sourceforge.net/projects/simulide/
* License : GPL-3
  Programming Lang: C++
  Description : real time electronic circuit simulator

SimulIDE is a simple real time electronic circuit simulator.
It's intended for general purpose electronics and microcontroller
simulation, supporting PIC and AVR.
PIC simulation is provided by gpsim and AVR simulation by simavr.

Intended for hobbist or students to learn and experiment with simple
circuits.

https://sourceforge.net/p/simulide/svnrepo/HEAD/tree/branches/simulide_0.1.5-RC/

Bug#874316: ITP: simutron -- AVR simulator IDE

[Milan Kupcevic]

Package: wnpp
Severity: wishlist
Owner: Milan Kupcevic 

* Package name: simutron
  Version : 1.0.1
  Upstream Author : Santiago González 
* URL : https://sourceforge.net/projects/simutron/
* License : GPL-3
  Programming Lang: C++
  Description : AVR simulator IDE

Simple environment to run and debug firmware for AVR 8-bit
microprocessors.
Able to run arduino firmware.
Internally this program uses the open source Simavr AVR Processor
Simulator (https://github.com/buserror/simavr ) and wraps all its
functions in a GUI shell. Setups for firmware debugging scenarios can be
created dynamically. Able to run 16MHz MCU with decent set of external
parts in real time.

https://sourceforge.net/p/simutron/code/HEAD/tree/branches/RB-1.0.1/

Bug#874314: Boot fail after install - lots of console error messages

[Daniel Cardenas]

Package: installation-reports

Boot method: USB network install

Image version: Date: debian-9.1.0-amd64-netinst.iso

Machine: Acer Predator
https://www.newegg.com/Product/Product.aspx?Item=N82E16883101469

Processor: Intel Core i7
Memory: 32gb

Partitions: Single partition on 1tb drive

Output of lspci -knn (or lspci -nn): System won't boot so I can't do this.

Base System Installation Checklist: E
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Detect hard drives: [O ]
Partition hard drives:  [O ]
Install base system:[O ]
Clock/timezone setup:   [O ]
User/password setup:[O ]
Install tasks:  [O ]
Install boot loader:[O ]
Overall install:[ E]

Comments/Problems:
Screenshot of boot failure:
https://plus.google.com/photos/photo/106160719635456266010/6462052260033592018?icm=false=true

I don't know which of the errors are fatal.
* usb 1-4 device descriptor read/all, error -71
* Superblock last mount time is in the future.
* tpm [firmware bug] acpi region does not cover the entire
command/response buffer
* wifi firmware failed to load repeated many times.  (I don't have
wifi)  ethernet and it worked during install
* bluetooth hci0 firmware failed to load.  I don't care about
bluetooth.  Everything is wired.

Would appreciate which error(s) are fatal so I can try to address it.

Bug#873214: FTBFS with Java 9 (findbugs, now known as spotbugs upstream)

[tony mancill]

Hi Chris,

thank you for reporting this bug.  For the Java Team, any strong
opinions on whether we should upload a new src:spotbugs package or
continue with src:findbugs?

Thanks,
tony


signature.asc
Description: PGP signature

Bug#874195: libreoffice: Please enable Albanian (sq) l10n package

[Rene Engelhard]

Hi,

On Mon, Sep 04, 2017 at 06:31:54AM +0200, Rene Engelhard wrote:
> On Mon, Sep 04, 2017 at 02:13:25AM +0300, Lior Kaplan wrote:
> >Translation of Albanian is currently at 60-65%, would be nice to have a
> >l10n package as upstream already provides them
> 
> Hmm. 60-65% is quite low. Normally I'd put the threshold at 80-90%...
> I'd more consider it a bug upstream ships it, thenaagain they probably build 
> with all languages? (Don't see any --with-lang in

Oh, my. This is hilarious.

I wrote a quick and dirty script to check the locales[1]:

Even stuff we have in the packages right now is bad.

Even ar and he and hi and... Is he really so bad?

Even oc is better than them...

ab: 30882 strings, 29608 of 30882
ab: no help translations
ab: 5% translated, 95% untranslated
af: 30882 strings, 14879 of 30882
af: no help translations
af: 52% translated, 48% untranslated
am: 76796 strings, 868 of 76796
am: 99% translated, 1% untranslated
an: 30882 strings, 23230 of 30882
an: no help translations
an: 25% translated, 75% untranslated
ar: 76811 strings, 47820 of 76811
ar: 38% translated, 62% untranslated
as: 30879 strings, 9679 of 30879
as: no help translations
as: 69% translated, 31% untranslated
ast: 76811 strings, 18764 of 76811
ast: 76% translated, 24% untranslated
az: 30882 strings, 30041 of 30882
az: no help translations
az: 3% translated, 97% untranslated
be: 30882 strings, 2470 of 30882
be: no help translations
be: 93% translated, 7% untranslated
bg: 76811 strings, 3823 of 76811
bg: 96% translated, 4% untranslated
bn: 76811 strings, 26782 of 76811
bn: 66% translated, 34% untranslated
bn-IN: 76805 strings, 19473 of 76805
bn-IN: 75% translated, 25% untranslated
bo: 76795 strings, 31941 of 76795
bo: 59% translated, 41% untranslated
br: 30877 strings, 3218 of 30877
br: no help translations
br: 90% translated, 10% untranslated
brx: 30867 strings, 17153 of 30867
brx: no help translations
brx: 45% translated, 55% untranslated
bs: 76810 strings, 34054 of 76810
bs: 56% translated, 44% untranslated
ca: 76809 strings, 4354 of 76809
ca: 95% translated, 5% untranslated
ca-valencia: 76809 strings, 9948 of 76809
ca-valencia: 88% translated, 12% untranslated
cs: 76810 strings, 3693 of 76810
cs: 96% translated, 4% untranslated
cy: 30882 strings, 514 of 30882
cy: no help translations
cy: 99% translated, 1% untranslated
da: 76809 strings, 570 of 76809
da: 100% translated, 0% untranslated
de: 76830 strings, 570 of 76830
de: 100% translated, 0% untranslated
dgo: 30846 strings, 11952 of 30846
dgo: no help translations
dgo: 62% translated, 38% untranslated
dz: 76805 strings, 27330 of 76805
dz: 65% translated, 35% untranslated
el: 76811 strings, 570 of 76811
el: 100% translated, 0% untranslated
en-GB: 76811 strings, 570 of 76811
en-GB: 100% translated, 0% untranslated
en-ZA: 76811 strings, 22075 of 76811
en-ZA: 72% translated, 28% untranslated
eo: 76811 strings, 21338 of 76811
eo: 73% translated, 27% untranslated
es: 76811 strings, 988 of 76811
es: 99% translated, 1% untranslated
et: 76811 strings, 5910 of 76811
et: 93% translated, 7% untranslated
eu: 76810 strings, 1129 of 76810
eu: 99% translated, 1% untranslated
fa: 30853 strings, 17490 of 30853
fa: no help translations
fa: 44% translated, 56% untranslated
fi: 76811 strings, 12301 of 76811
fi: 84% translated, 16% untranslated
fr: 76811 strings, 569 of 76811
fr: 100% translated, 0% untranslated
ga: 30882 strings, 6636 of 30882
ga: no help translations
ga: 79% translated, 21% untranslated
gd: 30882 strings, 516 of 30882
gd: no help translations
gd: 99% translated, 1% untranslated
gl: 76806 strings, 10628 of 76806
gl: 87% translated, 13% untranslated
gu: 76806 strings, 22340 of 76806
gu: 71% translated, 29% untranslated
gug: 30875 strings, 7983 of 30875
gug: no help translations
gug: 75% translated, 25% untranslated
he: 76811 strings, 27572 of 76811
he: 65% translated, 35% untranslated
 <-- he
hi: 76803 strings, 44924 of 76803
hi: 42% translated, 58% untranslated
hr: 76811 strings, 33834 of 76811
hr: 56% translated, 44% untranslated
hsb: 30877 strings, 736 of 30877
hsb: no help translations
hsb: 98% translated, 2% untranslated
hu: 76811 strings, 3109 of 76811
hu: 96% translated, 4% untranslated
hu-Hung: 31675 strings, 31556 of 31675
hu-Hung: no help translations
hu-Hung: 1% translated, 99% untranslated
id: 76811 strings, 22167 of 76811
id: 72% translated, 28% untranslated
is: 76811 strings, 28534 of 76811
is: 63% translated, 37% untranslated
it: 76811 strings, 570 of 76811
it: 100% translated, 0% untranslated
ja: 76810 strings, 8250 of 76810
ja: 90% translated, 10% untranslated
jv: 30882 strings, 29499 of 30882
jv: no help translations
jv: 5% translated, 95% untranslated
ka: 76798 strings, 45351 of 76798
ka: 41% translated, 59% untranslated
kk: 30882 strings, 515 of 30882
kk: no help translations
kk: 99% translated, 1% untranslated
kl: 30882 strings, 30102 of 30882
kl: no help translations
kl: 3% translated, 97% untranslated
km: 

Bug#874313: ITP: btrfs-compsize -- calculate compression ratio of a set of files on btrfs

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: btrfs-compsize
  Upstream Author : me, Timofey Titovets
* URL : https://github.com/kilobyte/compsize
* License : GPL2+
  Programming Lang: C
  Description : calculate compression ratio of a set of files on btrfs

 Compsize takes a list of files on a btrfs filesystem (recursing directories)
 and measures used compression types and the effective compression ratio.
 .
 Because of partially used extents on one hand, and multiple reflinks to an
 extent on the other, the definition of used space can be quite unintuitive.
 This program provides answers at different stages:
  * blocks on the disk
  * uncompressed extents
  * apparent file sizes (sans holes)

Bug#874311: ITP: node-parse-base64vlq-mappings -- Parses out base64 VLQ encoded mappings

[Bastien ROUCARIES]

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

 * Package name: node-parse-base64vlq-mappings
   Version : 0.1.4
   Upstream Author : Thorsten Lorenz  (http://thlorenz.com)
 * URL : https://github.com/thlorenz/parse-base64vlq-mappings
 * License : Expat
   Programming Lang: JavaScript
   Description : Parses out base64 VLQ encoded mappings.

   This modules allows one to parse and decode VLQ
  (Variable Length Quantities) base64 encoded source map.
  .
  Source maps are JSON files that contain information on how to map
  transpiled source code back to their original source.
  Source maps are JavaScript’s version of debug symbols.
  .
  .
  Node.js is an event-based server-side JavaScript engine.

Bug#874312: kdelibs4support: FTBFS on hppa - segmentation fault in desktoptojson

[John David Anglin]

Source: kdelibs4support
Version: 5.37.0-2
Severity: normal

Dear Maintainer,

Build fails here:

Generating MOC compilation mocs_compilation.cpp
make[4]: Leaving directory '/<>/obj-hppa-linux-gnu'
Segmentation fault
src/solid-networkstatus/kded/CMakeFiles/kded_networkstatus_autogen.dir/build.mak
e:69: recipe for target 'src/solid-networkstatus/kded/networkstatus.json' failed
make[4]: *** [src/solid-networkstatus/kded/networkstatus.json] Error 139
make[4]: Leaving directory '/<>/obj-hppa-linux-gnu'
CMakeFiles/Makefile2:2927: recipe for target 'src/solid-networkstatus/kded/CMake
Files/kded_networkstatus_autogen.dir/all' failed
make[3]: *** [src/solid-networkstatus/kded/CMakeFiles/kded_networkstatus_autogen
.dir/all] Error 2
make[3]: *** Waiting for unfinished jobs
[ 39%] Automatic MOC for target kdebugdialog5

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=kdelibs4support=hppa=5.37.0-2=1504553058=0

The failure is caused by segmentation fault in desktoptojson:
do_page_fault() command='desktoptojson' type=15 address=0x6f64756c in 
desktoptojson[1+17000]
trap #15: Data TLB miss fault, vm_start = 0x00028000, vm_end = 0x0005f000

Sep  4 15:23:59 mx3210 kernel: do_page_fault() command='desktoptojson' type=15 
address=0x6f64756c in desktoptojson[1+17000]
Sep  4 15:23:59 mx3210 kernel: trap #15: Data TLB miss fault, vm_start = 
0x00028000, vm_end = 0x0005f000
Sep  4 15:23:59 mx3210 kernel: CPU: 0 PID: 10405 Comm: desktoptojson Not 
tainted 4.13.0 #1
Sep  4 15:23:59 mx3210 kernel: task: 0001be5220a0 task.stack: 
0001c5228000
Sep  4 15:23:59 mx3210 kernel: 
Sep  4 15:23:59 mx3210 kernel: YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
Sep  4 15:23:59 mx3210 kernel: PSW: 01101100 Not tainted
Sep  4 15:23:59 mx3210 kernel: r00-03  00ff0006fc0f 00027130 
00018ce7 6f64756c
Sep  4 15:23:59 mx3210 kernel: r04-07  00027130 0001 
ff05 f8d028c4
Sep  4 15:23:59 mx3210 kernel: r08-11  00036ec8 f8d02788 
f8d0265c 00027130
Sep  4 15:23:59 mx3210 kernel: r12-15  00036e78 f8d02674 
0001 f8d02664
Sep  4 15:23:59 mx3210 kernel: r16-19  00027130 f8498c90 
00027130 00027130
Sep  4 15:23:59 mx3210 kernel: r20-23  06f8 000321bd 
000321bd 654e616d
Sep  4 15:23:59 mx3210 kernel: r24-27  000321bd 0001 
6f64756c 00027130
Sep  4 15:23:59 mx3210 kernel: r28-31  0009 000321bc 
f8d02a00 0065
Sep  4 15:23:59 mx3210 kernel: sr00-03  0800 0800 
 0800
Sep  4 15:23:59 mx3210 kernel: sr04-07  0800 0800 
0800 0800
Sep  4 15:23:59 mx3210 kernel: 
Sep  4 15:23:59 mx3210 kernel:  VZOUICununcqcqcqcqcqcrmunTDVZOUI
Sep  4 15:23:59 mx3210 kernel: FPSR: 
Sep  4 15:23:59 mx3210 kernel: FPER1: 
Sep  4 15:23:59 mx3210 kernel: fr00-03    
 
Sep  4 15:23:59 mx3210 kernel: fr04-07  40141a9fbe76c8b4 4014083126e978d5 
0009e200 4014083126e978d5
Sep  4 15:23:59 mx3210 kernel: fr08-11  ca9e  
 
Sep  4 15:23:59 mx3210 kernel: fr12-15    
 
Sep  4 15:23:59 mx3210 kernel: fr16-19    
 
Sep  4 15:23:59 mx3210 kernel: fr20-23    
002c 067147690036
Sep  4 15:23:59 mx3210 kernel: fr24-27   3fe0 
412e8480 
Sep  4 15:23:59 mx3210 kernel: fr28-31  873cfdda681e5afa 3e3aeb62d14759c4 
873cfdda 267c737f
Sep  4 15:23:59 mx3210 kernel: 
Sep  4 15:23:59 mx3210 kernel: IASQ: 0800 0800 IAOQ: 
00022a9f 00022aa3
Sep  4 15:23:59 mx3210 kernel: IIR: 0c601082ISR: 0800  IOR: 
6f64756c
Sep  4 15:23:59 mx3210 kernel: CPU:0   CR30: 0001c5228000 CR31: 

Sep  4 15:23:59 mx3210 kernel: ORIG_R28: 
Sep  4 15:23:59 mx3210 kernel: IAOQ[0]: 00022a9f
Sep  4 15:23:59 mx3210 kernel: IAOQ[1]: 00022aa3
Sep  4 15:23:59 mx3210 kernel: RP(r2): 00018ce7

The faulting instruction is:
   0c 60 10 82 ldw 0(r3),rp

Start of faulting functions is:
   0x00022a78:  stw rp,-14(sp)
   0x00022a7c:  stw,ma r6,40(sp)
   0x00022a80:  ldi -fb,r6
   0x00022a84:  stw r5,-3c(sp)
   0x00022a88:  copy r25,r5
   0x00022a8c:  stw r3,-34(sp)
   0x00022a90:  copy r26,r3
   0x00022a94:  stw r4,-38(sp)
   0x00022a98:  stw r19,-20(sp)
   0x00022a9c:  ldw 0(r3),rp

Since symbols have been stripped, it hard to tell which function faulted but the
fault is caused by the first 

Bug#829671: Custom real addition doesn't seem to work

[Thorsummoner0 .]

I've done a manual interactive install `sudo apt install krb5-config`
and dumped the config values like so

printf '\ec'; sudo debconf-get-selections  | grep -i krb5-config


Notibly, the `krb5-config/kerberos_servers` and
`krb5-config/admin_server` are both empty strings from
debconf-get-selections, that seems incorrect to me. Anyway,
i correct the blank entries and prepended each like with `d-i ` and
plopped it into my preseed file like so, krb5-config inherited by the
libpam-krb5 package dependency chain.

# ...

d-i pkgsel/include string [...] libpam-krb5 libpam-ccreds
d-i pkgsel/upgrade select full-upgrade

# Auth
d-i krb5-config/add_servers_realm   string  KDC.EXAMPLE.ORG
d-i krb5-config/add_servers boolean true
d-i krb5-config/read_conf   boolean true
d-i krb5-config/kerberos_serversstring  example
d-i krb5-config/admin_serverstring  example
d-i krb5-config/default_realm   string  KDC.EXAMPLE.ORG

# ...

where `example` resolves to my primary kdc and admin server.

In this case I've tried with `krb5-config/read_conf` set to `true` and
`false`. Both cases the resulting installation's `/etc/krb5.conf` has
the default_realm populated correctly, but the custom ream has not
been added.

It was my understanding that supply debconf values ahead of time would
behave exactly like supplying them when prompted interactively. This
appears to be inconsistent.

This bug thread is the closest thing I've found to a lead; while I
could handle the realm addition as a postinstall rind replace It seems
like there is indeed a bug in how krb5-config determines if it should
add a realm, I assumed

krb5-configkrb5-config/add_serversbooleantrue

is pretty darn clear that server should be added and under the ream
declared for this purpose

krb5-configkrb5-config/add_servers_realmstring KDC.EXAMPLE.ORG


If nothing else it should be a bug that debconf's selections don't
remember user provided values, and that declaring theses values can be
ignored in a matter unlike the interactive prompt.

I took a peak at the `kerberos-configs-2.3/krb5-config.in` script,
admittedly I don't speak perl. I see a lot of confusing logic
operations, guessing a domain appears to be the primary operation. And
the literal realm addition seem to be held behind a cascade of
confusing-to-me subroutines, and I'm not really sure how to approach
debugging this script. As an uniformed observer trying to use the
software I suggest considering an explicit "add the thing" debconf key
boolean key, and an explciit "dont guess" boolean key so we can deploy
realm membership automatically

# For example, I feel were missing something like this:
krb5-configkrb5-config/add_realm boolean true
krb5-configkrb5-config/attempt_guess boolean false

Although this is still a confusing interface to me as now there are
multiple "please add the thing" keys that must be true for the thing
to be added, there should be one and only one obvious way to get your
realm added to the config with native machinery; I dont know, is there
a good way to respect the `krb5-config/add_servers` key? Maybe an
"attempt_guess boolean false" would be enough?

I'm really not sure how to proceed. Is this a bug that can get fixed
or do I need to develop a workaround and not use the Debian packaging
tooling that I'm so fond of.

Thank you for all your great work <3

Bug#874309: Acknowledgement (kde-config-screenlocker: kscreenlocker_greet fail on activation dpms.)

[Santiago José López Borrazás]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi of new:

If I do it in black screen, no problem, if I do it with an OpenGL
screensaver fails. Then it's going to be something else.

Has something similar happened to anyone?

- -- 
Saludos de Santiago José López Borrazás.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETRfKj4A1yyB7NXbdgVkC5li0mYwFAlmtxhMACgkQgVkC5li0
mYz6KQ/+LCVoLM4bpzuA4ub13l8S5VF72ux3MYwk3frvBQOFw59u9hl2NFA672h8
/czuoSdfKM9u3+FBmDSdoLcmr4G2qBwW98OHI92NUwOndtbfTAr7gTevtjUS4K7y
wC3kyk1jtDbpvUtAiLQgJiUxKh0nijM/4VGvfzhtmr3ZXzjyXWzwN5s9r2sE/jjJ
XM6SQH+Ekn+tXVsFf6ODxvVN72baVfuD0XhXFC9NkfoYOfAIBVNR8Ip0Uoxy8HPr
vYM+0ZfSvWKdgjFvmhQdI6RsFBi7eY9LlawZZnyowmhLPqLo0LejBGqj9mwKF4ni
6IFM+QZk9Uwx/MvQkOTckNvm7Y9B8tRPYxrnjm5NAXljsQr8pCvD8cnMcI+WXoTt
bK5W2kUUD2llD958/TY3jrwTat9QQlaO6WpceOro0cl70NBara+qKdtil6ieajQn
ej0m7hx3cyPQ0yLsDxCuq11DrQxLH4me6lEFe9FMrQwxFZYrP4Fy2q6fpZoEVpYH
mpHgFsl5EMgriPuoKW2kFeZpvXmvzL7r6RlJH2CfJtyPs59akTvsxrBBjdmT297i
xa2z+xm1m+iGf8hrcB0PX6I0K0xXZxTtaJoQ7Fm6xPypeAEuIST7eSjaOwJHl5rc
/XTULTBsbeNIeOjOnTvEIJ0nCS8BxSmAagXP7JJo+vQYeRK5Dyk=
=+NL3
-END PGP SIGNATURE-
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 295.40  
(buildmeis...@swio-display-x86-rhel47-04.nvidia.com)  Thu Apr  5 22:33:07 PDT 
2012

# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type "man /etc/X11/xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg
#Section "InputDevice"
#Identifier "Configured Mouse"
#Driver "mouse"
#Option "CorePointer"
#Option "Device" "/dev/input/mice"
#Option "Protocol" "ImPS/2"
#Option "Emulate3Buttons" "true"
#Option "ZAxisMapping" "4 5"
#EndSection
#Section "InputDevice"
## generated from default
#Identifier "Mouse0"
#Driver "mouse"
#Option "Protocol" "auto"
#Option "Device" "/dev/input/mice"
#Option "Emulate3Buttons" "yes"
#Option "ZAxisMapping" "4 5"
#EndSection
#Section "DRI"
#Mode 0660
#EndSection

Section "ServerLayout"

#InputDevice"Configured Mouse"
#InputDevice"Mouse0"
Identifier "Default Layout"
Screen "Default Screen" 0 0
InputDevice"Mouse0" "CorePointer"
InputDevice"Generic Keyboard"
InputDevice"Synaptics Touchpad"
Option "AIGLX" "true"
EndSection

Section "Files"

# path to defoma fonts
FontPath"/usr/share/fonts/X11/misc"
FontPath"/usr/share/fonts/X11/cyrillic"
FontPath"/usr/share/fonts/X11/100dpi/:unscaled"
FontPath"/usr/share/fonts/X11/75dpi/:unscaled"
FontPath"/usr/share/fonts/X11/Type1"
FontPath"/usr/share/fonts/X11/100dpi"
FontPath"/usr/share/fonts/X11/75dpi"
FontPath"/usr/share/fonts/truetype/freefont"
FontPath"/usr/share/fonts/truetype/sjfonts"
FontPath"/usr/share/fonts/truetype/ttf-dejavu"
FontPath"/usr/share/fonts/truetype/ttf-liberation"
FontPath"/usr/local/share/fonts"
FontPath"/usr/share/fonts/truetype/msttcorefonts"
FontPath"/usr/share/fonts/truetype/dustin"
FontPath"/usr/share/ghostscript/fonts"
FontPath"/usr/share/fonts/type1/gsfonts"
EndSection

Section "Module"
Load   "i2c"
Load   "bitmap"
Load   "dbe"
Load   "extmod"
SubSection   "extmod"
Option   "omit xfree86-dga"
EndSubSection
Load   "freetype"
Load   "type1"
Load   "glx"
Load   "record"
Load   "vbe"
Load   "int10"
#Load   "v4l"
#Load   "v4l2"
EndSection

Section "ServerFlags"
Option "Xinerama" "0"
Option "AllowMouseFail"
Option "DontZap" "on"
Option "DontVTSwitch" "false"
#Option "IgnoreABI" "false"
Option "RandR" "on"
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
Option "AllowEmptyInput" "false"
Option "AutoAddDevices" "false"
Option "AutoEnableDevices" "false"
EndSection

Section "InputDevice"
# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" 

Bug#874121: lintian: Please add more packagename to section mappings

[Chris Lamb]

Hi Guillem,

Thanks for the patch.

  ^lib.*\d[ad]?$  => lib
 ^^^

Shouldn't this be "libs" … ?


Regards,

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

Bug#874310: eog-plugins: postr plugin fails build on non-linux architectures

[Jeremy Bicha]

Source: eog-plugins
Version: 3.16.6-2

Building the postr plugin fails the build on non-Linux architectures.
Apparently, postr is installable on those architectures but for some
reason python3 needs to be installed first or the apt resolver gets
confused on the buildds. I don't know.

https://buildd.debian.org/status/logs.php?pkg=eog-plugins=3.16.6-2

I intend to disable that plugin on those architectures with my next
upload as a workaround, but I'm filing this bug for tracking.

Thanks,
Jeremy Bicha

Bug#874309: Acknowledgement (kde-config-screenlocker: kscreenlocker_greet fail on activation dpms.)

[Santiago José López Borrazás]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

My file /etc/X11/xorg.conf is attach.

- -- 
Saludos de Santiago José López Borrazás.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETRfKj4A1yyB7NXbdgVkC5li0mYwFAlmtw3cACgkQgVkC5li0
mYzvBA/9GNuNTGnP9lFTa04uz2EGCKHIf80KK2v7QzCmDSruXE0J6sxdaEQG0eMs
yXSV8eoKRgKBOvMxbyOilQujXF9+K1CokESX+KHof8Fqjh0jGznfrv7f1iSSci/r
aFo6hizJl+Uekl2QtFPKfBSKebLZjfruJGvrYvgSZRK7b74L64vvvFU48x1O04ui
La3UH0SeQoOWvfrYiHgZhOeoxS1aX7h1NTaVOPAUiSGilarXPISgOLlEYy/nGQfK
yhqfPEQcz6i3fzcC+9/VwcyTniW97ZQd+/P5qXNwAdtC20cpeuDDyS0+JAaV6jfK
rZ9qc0vGEFITAdNILOGlMa9ilLfhn4jt/E8CGtjCq7zDuN1TdmRMGDydi437DgSt
d21boj47nKPJfXx1HWCP1zV196oTvFRxjgDSFHl8Dny5eTteaoUwhjhTpfpOCc16
TT7H/uk60ljnJdHSpFaq+drxoOb8sM1SXOKiC1ZPa+9qs8mm9exloU9rQI88oT4G
RW6Ri9Ldo7F3cziCdbKCus4+38q1w8iCas0wYno7c21aVdAOyleG1wBKLz6tRATh
lB9MPwCrAyfZZh5oLjSE+V0sLLxQ81YnPYSvqCbR52S5b5O0hKP0jSTb6jjUhZ/Y
EgfFRjTyDMeQkI73Do7IFC7iiFpHZcg20IlwOqOixwjAwrxCTJk=
=gLjg
-END PGP SIGNATURE-
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 295.40  
(buildmeis...@swio-display-x86-rhel47-04.nvidia.com)  Thu Apr  5 22:33:07 PDT 
2012

# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type "man /etc/X11/xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg
#Section "InputDevice"
#Identifier "Configured Mouse"
#Driver "mouse"
#Option "CorePointer"
#Option "Device" "/dev/input/mice"
#Option "Protocol" "ImPS/2"
#Option "Emulate3Buttons" "true"
#Option "ZAxisMapping" "4 5"
#EndSection
#Section "InputDevice"
## generated from default
#Identifier "Mouse0"
#Driver "mouse"
#Option "Protocol" "auto"
#Option "Device" "/dev/input/mice"
#Option "Emulate3Buttons" "yes"
#Option "ZAxisMapping" "4 5"
#EndSection
#Section "DRI"
#Mode 0660
#EndSection

Section "ServerLayout"

#InputDevice"Configured Mouse"
#InputDevice"Mouse0"
Identifier "Default Layout"
Screen "Default Screen" 0 0
InputDevice"Mouse0" "CorePointer"
InputDevice"Generic Keyboard"
InputDevice"Synaptics Touchpad"
Option "AIGLX" "true"
EndSection

Section "Files"

# path to defoma fonts
FontPath"/usr/share/fonts/X11/misc"
FontPath"/usr/share/fonts/X11/cyrillic"
FontPath"/usr/share/fonts/X11/100dpi/:unscaled"
FontPath"/usr/share/fonts/X11/75dpi/:unscaled"
FontPath"/usr/share/fonts/X11/Type1"
FontPath"/usr/share/fonts/X11/100dpi"
FontPath"/usr/share/fonts/X11/75dpi"
FontPath"/usr/share/fonts/truetype/freefont"
FontPath"/usr/share/fonts/truetype/sjfonts"
FontPath"/usr/share/fonts/truetype/ttf-dejavu"
FontPath"/usr/share/fonts/truetype/ttf-liberation"
FontPath"/usr/local/share/fonts"
FontPath"/usr/share/fonts/truetype/msttcorefonts"
FontPath"/usr/share/fonts/truetype/dustin"
FontPath"/usr/share/ghostscript/fonts"
FontPath"/usr/share/fonts/type1/gsfonts"
EndSection

Section "Module"
Load   "i2c"
Load   "bitmap"
Load   "dbe"
Load   "extmod"
SubSection   "extmod"
Option   "omit xfree86-dga"
EndSubSection
Load   "freetype"
Load   "type1"
Load   "glx"
Load   "record"
Load   "vbe"
Load   "int10"
#Load   "v4l"
#Load   "v4l2"
EndSection

Section "ServerFlags"
Option "Xinerama" "0"
Option "AllowMouseFail"
Option "DontZap" "on"
Option "DontVTSwitch" "false"
#Option "IgnoreABI" "false"
Option "RandR" "on"
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
Option "AllowEmptyInput" "false"
Option "AutoAddDevices" "false"
Option "AutoEnableDevices" "false"
EndSection

Section "InputDevice"
# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/psaux"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
Identifier  

Bug#874309: kde-config-screenlocker: kscreenlocker_greet fail on activation dpms.

[Santiago José López Borrazás]

Package: kde-config-screenlocker
Version: 5.8.7-1
Severity: important

Dear Maintainer,

This sitaución is boring.

When I close the lid of the laptop, nothing more raises it (because FIGHT 
activates the function, dice to the file/etc/systemd/logind.conf with the 
following lines:

HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore
LidSwitchIgnoreInhibited=yes

The screen is blocked not only, since also kscreenlocker_greet and I cannot 
even already unblock not anything.

With xscreensaver yes I can perfectly.

This I do not know if it happens to me with the driver nouveau.

This laptop is old.

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

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

Versions of packages kde-config-screenlocker depends on:
ii  kpackagetool5 5.37.0-2
ii  libc6 2.24-17
ii  libkf5configcore5 5.37.0-2
ii  libkf5configgui5  5.37.0-2
ii  libkf5configwidgets5  5.37.0-2
ii  libkf5coreaddons5 5.37.0-2
ii  libkf5declarative55.37.0-2
ii  libkf5globalaccel55.37.0-2
ii  libkf5i18n5   5.37.0-2
ii  libkf5package55.37.0-2
ii  libkf5textwidgets55.37.0-2
ii  libkf5xmlgui5 5.37.0-2
ii  libkscreenlocker5 5.8.7-1
ii  libqt5core5a  5.9.1+dfsg-9
ii  libqt5dbus5   5.9.1+dfsg-9
ii  libqt5gui55.9.1+dfsg-9
ii  libqt5qml55.9.1-5
ii  libqt5quickwidgets5   5.9.1-5
ii  libqt5widgets55.9.1+dfsg-9
ii  libstdc++67.2.0-3

kde-config-screenlocker recommends no packages.

kde-config-screenlocker suggests no packages.

-- no debconf information

Bug#749826: Documenting `Multi-Arch: foreign`

[Helmut Grohne]

Hi Simon,

On Sat, Sep 02, 2017 at 05:26:57PM +0100, Simon McVittie wrote:
> That seems like it might be a bug (or design flaw if you prefer). If a
> package (build-)depends on foo:any, it is saying "I am only using the
> arch-indep parts of foo's interface", whatever those are.

You may call it feature. The idea here was that :any should not be used
mindlessly. Thus it is only allowed on packages properly marked for that
used with ``Multi-Arch: allowed``. In Build-Depends, you can mostly
achieve the same effect with :native (which essentially is :any on any
package (but Architecture: all packages (though our dependency resolvers
don't agree here))).

> Perhaps a dependency on foo:any by (for example) bar:mips should
> always be satisfiable by foo:mips (as though the :any had been omitted),
> regardless of foo's multi-arch status? This would bring it back to the
> same meaning as omitting the :any, in the trivial case where only one
> architecture is enabled.

That proposal may ease meta data changes indeed. I suspect that it would
also cause a lot of useless :any annotations. It's a two-sided sword.

> Perhaps a dependency on foo:any should be satisfiable by any instance
> of foo that is Multi-Arch: foreign? (In this case the :any is completely
> redundant, because foreign sets up a similar situation from the other end)

After studying Multi-Arch for many years now, I recognize that a core
idea is to almost always flag the architecture constraint on the target
of an edge. To understand this wicked sentence, consider a dependency
graph and label each node (package) with an architecture. Now Multi-Arch
says that by default every edge (dependency) must enforce equal
architecture on both ends. Most of the header's job is relaxing this
restriction. The designers of Multi-Arch decided that this relaxing
should not be a property of the edges (e.g. :any), but a property of the
dependee.

Thus the current implementation ensures that :any cannot be used in
situations where it is inappropriate. As you point out, that design is
annoying for meta data transitions.

> > > I think "the files installed by ``Architecture: all`` packages always
> > > provide architecture-independent interfaces." is too broad. The counter
> > > example is haskell-devscripts-minimal. This needs to be weakened
> > > somehow.
> 
> I would argue that these interfaces are architecture-independent from
> the perspective of the package's (lack of) architecture. What they
> are not independent of is the *build machine* architecture, just like
> running uname -m or inspecting /proc/cpuinfo aren't independent of the
> build machine architecture. This is certainly a problem for
> cross-compilation, but it isn't the same issue as in dpkg or pkg-config,
> where the architecture for which dpkg or pkg-config was built gets
> hard-coded into its installed files (as the output of --print-architecture
> or part of the default search path, respectively).

That's a nice view, but it is not the view expressed by Multi-Arch. The
meaning of the header considers the whole installation set as a unit.
Whether you view this in a package building context or runtime context
does not matter, what matters is whether the tools behave differently
when you swap the architecture of underlying parts.

As a side note, we marked pkg-config Multi-Arch: foreign, but that is
technically wrong on another level. The marking would imply that it
doesn't matter which architecture you use to supply the package. A
prospective README.multiarch would need to say that you must not use
plain pkg-config (without a triplet prefix). Yet that is what most
packages do. If you perform an archive rebuild of pkg-config build-rdeps
on amd64 in a chroot with preinstalled pkg-config:i386, the majority of
builds will fail even though their Build-Depends are installable.

This is another place where we bend the rules just to make it barely
useful. For performing useful cross builds, one needs to discard host
architecture instances of ``Multi-Arch: foreign`` packages.

> > > For instance, the policy should make it
> > > clear that marking libmdds-dev `Multi-Arch: foreign` (fictional, see
> > > #843023) would be a policy violation.
> 
> It is not clear to me that doing so *should* be a policy violation. If
> libmdds-dev contains only headers (no shared or static library), and it
> exposes architecture-independent libboost-dev headers (but no Boost
> shared or static library), is there really anything wrong with having
> libboost-dev from "the wrong architecture"?

As long as everything is header-only, you can use ``Multi-Arch:
foreign``.  The thing is, even if libboost-dev was
architecture-independent, it would expose libstdc++-7-dev. Since
exposure is transitive, that carries over to libmdds-dev.

Boost's dependency on libstdc++-4.8-dev | libstdc++-dev looks a bit
strange though. Since libc++-dev provides libstdc++-dev (and no compiler
will just use libc++-dev when it is installed without further 

Bug#863663: libgstreamer1.0-0: plays MJPEG AVI files (and possibly other formats) at degraded quality

[Francesco Poli]

On Sat, 19 Aug 2017 15:04:51 +0200 Francesco Poli wrote:

> On Wed, 28 Jun 2017 22:27:00 +0200 Francesco Poli wrote:
> 
> [...]
> > waiting for [bug 783267] to be fixed
> [...]
> > 
> > [bug 783267]: 
> 
> Is there any progress on this bug?
> Please let me know: I am looking forward to seeing this issue fixed
> once and for all...
> 
> Thanks for your time!

May I have a reply, please?
Thanks for your understanding.


> P.S.: Please Cc me, as well as the Debian bug address and the
> gstreamer-devel mailing list. Thanks for your understanding!



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


pgppM9_djcCga.pgp
Description: PGP signature

Bug#749826: Documenting `Multi-Arch: foreign`

[Helmut Grohne]

On Sat, Sep 02, 2017 at 08:44:14AM -0700, Sean Whitton wrote:
> Rather than introduce the new terminology 'intended interface', which we
> would definitely have to define, how about something like this:
> 
> If all a package's architecture-dependent interfaces are listed in
> README.multiarch, the package is not considered to have any
> architecture-dependent interfaces for the purposes of determining
> whether it may be labelled Multi-Arch: foreign.

This is not how it works. It's not like you can just mark any package
Multi-Arch: foreign after saying that it is architecture-dependent. That
documentation must come with a contract saying that reverse dependencies
must not use those architecture-dependent interfaces.

> If libc6's use is legitimate then it seems we'd need to include this as
> an exception.

Well, it's not exactly legitimate. It's more like unavoidable as Simon
pointed out in his reply. Technically, libc6's behaviour is wrong and
causes unpack errors. The reasonable solution would be prohibiting
coinstallation of libc6:mips and libc6:mipsel, but package metadata does
not allow us to do that currently (#747261 -> self-conflicts are always
ignored). The other option of removing Multi-Arch: same from libc6 would
essentially render Multi-Arch useless. So all we can do now is pretend
the issue wasn't there.

> > * If you rebuild the source package with a very different
> > installation set (i.e. much newer Build-Depends), does it still
> > have to match with older instances? Example: #825146. What
> > divergence in installation sets is ok?
> 
> We could just say that it must match the instances in the target suite.

We could. That would render libgiac0 rc buggy for instance, because it
was built on mips64el three weeks later than on other architectures and
thus uses an incompatible gettext.

That definition is pretty annoying for bootstraps though as replicating
ancient toolchain is kinda the opposite of what bootstrappers do.

> >(A simple way to satisfy this requirement is to use
> >architecture-dependent paths exclusively. That works except for
> >/usr/share/doc/$pkg.)
> >
> >  * The maintainer scripts must handle multiple configuration and
> >multiple deconfiguration correctly. In particular, a package can be
> >purged for one architecture while being installed for another.
> >Example: #682420.
> >
> >(A simple way to satisfy this requirement is to not ship maintainer
> >scripts.)
> >
> >  * Source packages carrying any binary package marked `Multi-Arch: same`
> >must always be binNMUed in lock-step. (Presently violated e.g. by
> >libselinux1)
> 
> Could you turn this into some commits against my branch, please?

I tried and ran into a new problem: I am now convinced that we cannot
just describe one Multi-Arch value after another as they do share some
common values. That "interface" aspect and architecture-constraints on
dependencies is a common theme and likely deserves an introductory text.

Yet, I am attaching what I have.

> It sounds like we need to just drop the whole bullet point.
> Architecture: all packages need to be checked carefully, just like
> Architecture: any packages.

Reworded.

> To my mind, the most important ways to achieve readability in this case
> are
> 
> - avoid repetition
> - avoid "probably", "likely" sentences.

The latter is particularly hard, because we violate the strict
definitions more often than is immediately apparent.

As Simon's mail demonstrates, we likely need more answers/consensus
before continuing. I'll reply in a separate mail.

Helmut
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 509a96e..e6451d5 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -1028,6 +1028,18 @@ control file.
 We consider the meaning of each possible value of this field
 separately.
 
+``Multi-Arch: no``
+++
+
+This value is the default. When satisfying a dependency on a package
+(implicitly) marked ``Multi-Arch: no``, the depender and the dependee
+must have the same architecture. For the purpose of this matching,
+``Architecture: all`` packages are treated as if they had the
+architecture value of ``dpkg``.
+
+The value ``no`` cannot currently be used in binary packages due to
+limitations of the archive processing.
+
 ``Multi-Arch: foreign``
 +++
 
@@ -1037,12 +1049,15 @@ architecture.
 In order to determine whether this holds, you should consider
 
 the files installed by the package
-``Architecture: all`` packages always provide
-architecture-independent interfaces.  Shared and static libraries
-provide architecture-dependent ABIs.  Binary executables may
-provide architecture-independent interfaces: could software
-interacting with the executable determine the architecture for
-which it was built without reading the executable file?
+``Architecture: all`` packages tend to provide

Bug#874308: libglib2.0-0 > 2.52.3-1 does not allow udisks/gvfs/nautilus to show user mounts from /etc/fstab

[Junior Polegato]

Package: libglib2.0-0
Version: 2.52.3-1
Severity: important
Tags: upstream

Dear Maintainer,

Hi!

I no more see user/noauto mount points from /etc/fstab in my nautilus, also in
gvfs or udisks2.

I tryed many things...

I searched on the web and found a sugestion to downgrade libglib2.0-0 to
2.52.3-1, I did it and now I can see thoses mount points.

Please, can you fix it?

Thanks.




-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (65, 'unstable'), (60, 'stable'), (55, 
'experimental')
Architecture: i386 (i686)

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

Versions of packages libglib2.0-0 depends on:
ii  libc62.24-17
ii  libffi6  3.2.1-6
ii  libmount12.29.2-4
ii  libpcre3 2:8.39-4
ii  libselinux1  2.6-3+b2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages libglib2.0-0 recommends:
ii  libglib2.0-data   2.53.6-1
ii  shared-mime-info  1.8-1
ii  xdg-user-dirs 0.15-3

libglib2.0-0 suggests no packages.

-- no debconf information

Bug#874307: multiple openvpn instances wrongly remove status files of preceding ones

[Daniel Haid]

Package: openvpn
Version: 2.4.0-6+deb9u1
Severity: normal

Dear Maintainer,

I am running two openvpn instances via config files

/etc/openvpn/server/first.conf
/etc/openvpn/server/second.conf

Starting the second instance via

systemctl start openvpn-server@second

while the first instance is running removes the
status file /run/openvpn-server/status-first.log.

But the correct behaviour should be that all status
files remain accessible.

Bug#866364: Partial implementation of live boot localisation

[Steve McIntyre]

On Tue, Aug 29, 2017 at 12:07:44PM +0200, Raphael Hertzog wrote:
>Hello,
>
>On Thu, 29 Jun 2017, Narcis Garcia wrote:
>> No keyboard localisation when choosing "Debian Live with Localisation
>> Support". For example, choosing "Spanish" at this boot submenu, keyboard
>> is set to an USA layout (in any X, TTY and pty).
>> 
>> Keyboard layout should do same associations as Debian-Installer suggests
>> for choosen language.
>
>What are you referring to?
>
>live-config is a generic tool that integrates in the boot sequence, the
>boot menu is not under its control and it's definitely not responsible
>of the "Debian Live with Localisation Support" thingie that you are
>speaking of.
>
>I'm tempted to close this bug right away but maybe it must be reassigned
>somewhere so please let us know what live image you did use for your test.
>
>Where did you get it from? If its a custom image, what tool did you use
>to build it?

It's something that live-wrapper generates, so it's in the official
Stretch images. Unfortunately, as we can see, it's not complete - it
would need more work in live-config to make it properly functional.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?

Bug#874305: RFS: mitlm/0.4.2-1 -- MIT Language Modeling toolkit

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist

Dear Jakub,

  I am looking for a sponsor for an updated version of my package "mitlm"

* Package name: mitlm
  Version : 0.4.2
  Upstream Author : Bo-June (Paul) Hsu 
* URL : https://github.com/mitlm/mitlm
* License : BSD
  Programming Lang: (C, C++, Fortran)
  Section : misc

It builds those binary packages:

 libmitlm1  - MIT Language Modeling toolkit library
 libmitlm1-dev - MIT Language Modeling toolkit development files
 mitlm - MIT Language Modeling toolkit

You can find the source of the package at:

  https://anonscm.debian.org/cgit/collab-maint/mitlm.git

Regards,
   Giulio Paci



signature.asc
Description: OpenPGP digital signature

Bug#874306: autodep8: Support for Octave-Forge packages

[Rafael Laboissière]

Package: autodep8
Version: 0.9
Severity: wishlist
Tags: patch

Dear autodep8 maintainers,

I added the Git repository of the autodep8 package the support for the 
Octave-Forge packages [1] that are maintained by the Debian Octave Group 
[2].  I put it in the 'octave' branch of the Git repository [3].  I am 
attaching below the patch that applies to the current HEAD of the Git 
master branch (obtained with "git diff master..octave").


There are currently 51 packages in Debian that would be detected by 
autodep8 with the support I am proposing.


There was a discussion around this patch in the autopkgtest-devel 
mailing list [4].


Notice that this patch should only be released in autodep8 when version 
1.5.1 of the source package octave-pkg-dev (which contains the package 
octave-autopkgtest) reaches unstable.  Since this version introduces a 
new binary package, it will certainly goes through the NEW queue.


Thanks in advance for considering this patch,

Best,

Rafael Laboissière

1. https://octave.sourceforge.io/
2. https://wiki.debian.org/Teams/DebianOctaveGroup
3. https://anonscm.debian.org/cgit/collab-maint/autodep8.git/log/?h=octave
4. 
http://lists.alioth.debian.org/pipermail/autopkgtest-devel/2017-September/002472.html
diff --git a/debian/control b/debian/control
index 8051198..a097ab8 100644
--- a/debian/control
+++ b/debian/control
@@ -26,3 +26,4 @@ Description: DEP-8 test control file generator
   - R packages
   - Emacs Lisp ELPA packages
   - Go packages
+  - Octave-Forge packages
diff --git a/examples.in b/examples.in
index d0eb1b5..21f7e35 100644
--- a/examples.in
+++ b/examples.in
@@ -4,6 +4,7 @@ dkmskpatch
 elpaflycheck
 go  prometheus
 nodejs  node-tar
+octave  octave-signal
 perllibtest-most-perl
 python  python-flaky
 r   r-cran-evaluate
diff --git a/examples.md b/examples.md
index 685b8b9..653ea4e 100644
--- a/examples.md
+++ b/examples.md
@@ -14,14 +14,20 @@
 ## go (prometheus)
 
 Test-Command: /usr/bin/dh_golang_autopkgtest
-Depends: @builddeps@, dh-golang
-Restrictions: rw-build-tree, allow-stderr
+Depends: @, @builddeps@, dh-golang
+Restrictions: allow-stderr
 
 ## nodejs (node-tar)
 
 Test-Command: cd $ADTTMP && nodejs -e "require('"'"'tar'"'"');"
 Depends: @
 
+## octave (octave-signal)
+
+Test-Command: /usr/share/octave-pkg-dev/check-pkg
+Depends: @, octave-autopkgtest
+Restrictions: allow-stderr
+
 ## perl (libtest-most-perl)
 
 Test-Command: /usr/share/pkg-perl-autopkgtest/runner build-deps
@@ -36,11 +42,11 @@
 
 ## python (python-flaky)
 
-Test-Command: cd "$ADTTMP" ; python -c "import flaky; print flaky"
-Depends: python-flaky
+Test-Command: set -e ; for py in $(pyversions -r 2>/dev/null) ; do cd "$ADTTMP" ; echo "Testing with $py:" ; $py -c "import flaky; print flaky" ; done
+Depends: python-all, python-flaky
 
-Test-Command: cd "$ADTTMP" ; python3 -c "import flaky; print(flaky)"
-Depends: python3-flaky
+Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$ADTTMP" ; echo "Testing with $py:" ; $py -c "import flaky; print(flaky)" ; done
+Depends: python3-all, python3-flaky
 
 Test-Command: cd "$ADTTMP" ; pypy -c "import flaky; print flaky"
 Depends: pypy-flaky
diff --git a/support/octave/detect b/support/octave/detect
new file mode 100755
index 000..78ce8a2
--- /dev/null
+++ b/support/octave/detect
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+### Select only the packages from Octave-Forge.  The detection is based on
+### the existence of an inst/ directory (which contains the *.m to be
+### tested) and a DESCRIPTION file, besides the name of the source package,
+### which must start with ""octave-"".
+
+test -d inst\
+&& test -f DESCRIPTION		\
+&& grep-dctrl --quiet -F Source -r '^octave-.*$' debian/control
diff --git a/support/octave/generate b/support/octave/generate
new file mode 100755
index 000..1191fe8
--- /dev/null
+++ b/support/octave/generate
@@ -0,0 +1,7 @@
+#!/bin/sh
+
+cat <

Bug#775456: Openboard / Sancore Update

[Christian Meyer]

Hello there,

is there any update in including Openboard or Sancore in Debian?

I saw this more than two year old ITP (#775456) and tried Miriams
Debian packages from http://www.miriamruiz.es/debian/sankore/ but I
failed because of the dependency to libssl1.0.

https://anonscm.debian.org/gitweb/?p=debian-edu/pkg-team/sankore.git
does not seem to be active any more.

Honestly I would like to see it in Debian but I can't do much for it.
Bu
t if you need testing or a german translater: here I am.

Is there any update on this project or is it dead?

Christian

Bug#874304: gpg: --refresh-keys became extremely verbose and complaining

[Francesco Poli (wintermute)]

Package: gpg
Version: 2.1.23-2
Severity: normal

Hello Debian GnuPG Maintainers!

After today's upgrade, I refreshed some keys in my keyring and noticed
that gpg has just become extremely verbose.

For instance:

  $ gpg --refresh-keys 0xCCD2ED94D21739E9
  gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net
  uid  Daniel Kahn Gillmor 
  sig! 0x5A94F3CA0B2713C8 2014-03-23  Ben Armstrong 
" 
not changed
  gpg: Total number processed: 1
  gpg:  unchanged: 1


In other words, 656 lines of output (on stderr) for 1 unchanged key!

The output seems to be (more or less) the old output of
"gpg --refresh-keys $KEYID", combined with the output of
"gpg --check-sigs $KEYID".

For reference, the old output was something like:

  $ gpg --refresh-keys 0xCCD2ED94D21739E9
  gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net
  gpg: key 0xCCD2ED94D21739E9: "Daniel Kahn Gillmor " 
not changed
  gpg: Total number processed: 1
  gpg:  unchanged: 1


I cannot find any additional option to restore the previous behavior:

  $ gpg --no-verbose --refresh-keys 0xCCD2ED94D21739E9

produces the same lengthy output.

  $ gpg -q --refresh-keys 0xCCD2ED94D21739E9

suppresses the old (useful) output, while retaining the lengthy
signature check output...


Where am I going wrong?
Could the old behavior be restored?

Please fix this bug and/or forward my report upstream, as appropriate.

Thanks for your time!


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

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

Versions of packages gpg depends on:
ii  gpgconf2.1.23-2
ii  libassuan0 2.4.3-3
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-17
ii  libgcrypt201.7.9-1
ii  libgpg-error0  1.27-3
ii  libreadline7   7.0-3
ii  libsqlite3-0   3.19.3-3
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gpg recommends:
ii  gnupg  2.1.23-2

gpg suggests no packages.

-- no debconf information

Bug#868286: plantuml: New version available

[Andrew Shadura]

Hi,

On 4 September 2017 at 22:07, Christopher Hoskin  wrote:
> Package: plantuml
> Version: 8039-1
> Followup-For: Bug #868286
>
> Dear Andrew,
>
> Would you be interested in an NMU to fix this bug? Or perhaps maintaining 
> this package within the pkg-java team?
>
> I've found that the recent versions of plantuml have an issue with v1.8 of 
> batik (URI is not hierarchical exception) so I uploaded v1.9 this morning 
> which appears to solve this problem.

Sure, either NUM or pkg-java team mainenance or both are fine, go for it :)

-- 
Cheers,
  Andrew

Bug#820904: ssh-askpass: cannot control position of ssh-askpass window

[Tony Finch]

> On 1 Sep 2017, at 22:18, Philip Hands  wrote:
> 
> Anyway, since I'm now preparing a release, I looked at this, and it
> occurs to me that it might be more useful to be able to specify the
> position on the screen as e.g. a percentage of the width/height.

That would be a satisfactory solution for me, thanks!

Tony.
-- 
f.anthony.n.finch    http://dotat.at

Bug#385907: [Pkg-openssl-devel] Bug#385907: marked as done (openssl: missing purging at remove-time)

[Kurt Roeckx]

> 
> Since
>   https://piuparts.debian.org/stretch/source/o/openssl.html
> 
> says "successfully-tested 1.1.0f-3" I think that we are done here.

I think it's other packages that call openssl from the maintainer
scripts that fail.


Kurt

Bug#874303: O: jsymphonic -- File manager for Sony's MP3 players

[Vincent Fourmond]

Package: wnpp
Severity: normal

I intend to orphan the jsymphonic package.

The package description is:
 Symphonic is a file manager for Sony's flash players (such as the
 NW-E00x series), where songs are stored in a proprietary format
 not very Unix-friendly.
 .
 This program provides functionalities similar to the proprietary
 Windows-only SonicStage software given by Sony to interact with
 the players.

Upstream hasn't released a newer version in now 7 years, and
incompatibilities with newer Java versions have arisen, see #873222. I
personally haven't used the package in years too. I'm orphaning the
package now, with the intent to request removal in probably a couple
of months if no one steps up.

  Best,

Vincent Fourmond

Bug#385907: [Pkg-openssl-devel] Bug#385907: marked as done (openssl: missing purging at remove-time)

[Sebastian Andrzej Siewior]

On 4 September 2017 22:08:27 CEST, Kurt Roeckx  wrote:
>> 
>> Since
>>   https://piuparts.debian.org/stretch/source/o/openssl.html
>> 
>> says "successfully-tested 1.1.0f-3" I think that we are done here.
>
>I think it's other packages that call openssl from the maintainer
>scripts that fail.

There is another issue where openssl creates a .rnd file which is not removed 
after 'purge'. But this is different.
>
>
>Kurt



Sebastian

Bug#874302: liblouis: CVE-2017-13738 CVE-2017-13739 CVE-2017-13740 CVE-2017-13741 CVE-2017-13742 CVE-2017-13743 CVE-2017-13744

[Salvatore Bonaccorso]

Source: liblouis
Version: 3.0.0-3
Severity: important
Tags: upstream security fixed-upstream

Hi

The new upstream version 3.3.0 fixes severaly CVEs for liblouis:

CVE-2017-13738
CVE-2017-13739
CVE-2017-13740
CVE-2017-13741
CVE-2017-13742
CVE-2017-13743
CVE-2017-13744

https://github.com/liblouis/liblouis/releases/tag/v3.3.0

The isses were marked no-dsa for stretch and jessie, but a fix is
welcomed via an upcoming point release if possible.

Regards,
Salvatore

Bug#868286: plantuml: New version available

[Christopher Hoskin]

Package: plantuml
Version: 8039-1
Followup-For: Bug #868286

Dear Andrew,

Would you be interested in an NMU to fix this bug? Or perhaps maintaining this 
package within the pkg-java team?

I've found that the recent versions of plantuml have an issue with v1.8 of 
batik (URI is not hierarchical exception) so I uploaded v1.9 this morning which 
appears to solve this problem. 

Christopher

Bug#874301: libgtop2: FTBFS on kFreeBSD: strlcpy undefined

[Jeremy Bicha]

On Mon, Sep 4, 2017 at 3:57 PM, Aaron M. Ucko  wrote:
> strlcpy may be part of FreeBSD's libc, but GNU libc (as used by
> kFreeBSD leaves it out); please either substitute a different
> function, supply a fallback definition, or build against libbsd-dev.

Do you want to submit a patch to do that?

I'm not set up to test builds for those architectures.

Thanks,
Jeremy Bicha

Bug#874301: libgtop2: FTBFS on kFreeBSD: strlcpy undefined

[Aaron M. Ucko]

Source: libgtop2
Version: 2.37.90-2
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

Builds of libgtop2 for kfreebsd-amd64 and kfreebsd-i386 (not release
architectures, admittedly) have been failing:

  ./sysdeps/freebsd/netload.c:109: undefined reference to `strlcpy'
  ./sysdeps/freebsd/netload.c:122: undefined reference to `strlcpy'

strlcpy may be part of FreeBSD's libc, but GNU libc (as used by
kFreeBSD leaves it out); please either substitute a different
function, supply a fallback definition, or build against libbsd-dev.

Thanks!

FTR, hurd-i386 isn't a release architecture either; sorry for
neglecting to note that in #847294.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#874298: O: vzdump -- OpenVZ backup scripts

[Ola Lundqvist]

Package: wnpp

I no longer have an interest in maintaining this package with same reason
for not maintaining vzctl.

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#874299: O: vzquota -- server virtualization solution - quota tools

[Ola Lundqvist]

Package: wnpp

I no longer have an interest in maintaining this package with same reason
for not maintaining vzctl.

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#874300: O: vzstats -- OpenVZ component to gather statistics

[Ola Lundqvist]

Package: wnpp

I have no longer an interest in maintaining this package.

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#874297: O: vzctl -- server virtualization solution - control tool

[Ola Lundqvist]

Package: wnpp

I no longer have an interest in maintaining this package.
The main reason is the trouble to maintain the kernel parts.

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#874295: clementine: installs non-free plugin at runtime

[Jonas Smedegaard]

Package: clementine
Version: 1.3.1+git276-g3485bbe43+dfsg-1
Severity: serious
Tags: upstream
Justification: Policy 2.2.1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

One of several functions of Clementine is to stream audio from cloud
service Spotify.  Initially selecting that function triggers a routine
where Clementine (asks for concent and then) downloads and installs a
non-free binary driver.

Policy 2.2.1 states that "None of the packages in the main archive area
require software outside of that area to function."

Clementine should either be moved to contrib, or the Spotify function be
removed.

PureOS issue tracker references how Parabola removes the function:
https://tracker.pureos.net/T100
https://git.parabola.nu/abslibre.git/tree/libre/clementine/remove-nonfree-artwork-and-spotify.patch


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlmtrf4ACgkQLHwxRsGg
ASHfOQ//dv2mg0X1InuD1dUe8/d9uKMlQUAbXeJxWqOghS0E6LWaekW4aJDprvhj
4f+YTaZJGvCAg3cBjba0XXvdrCuZrmpP5YNURU0F8pVXgcaOWH8TC9OHGDCWNKFp
2qkpGIQ6L6cKic0W92ToPCn15bbGJNw3MP/yDCDrg4rljERg3mzwQKVK1VTeNN47
hoDqyL6PwhcbsK1rUQ7f7dyJbRBw8naVFGTvC5/pZZxqwLE+TcQZ7nFe08EZJVNa
+BswrL39vqwduge0W2ZSh5rSAAeXvo82dGb2BaLYYmuZm8z802/Gpv/wfRXQ2eI8
1sN742YHHMz03CalJ7QfjXiPNfcQJxqaVt+N2o3emEfvkdukspRAcFzQVD6yCngH
Q0RbNGR8X9cPEvKuNaurxyqwChfupSg0PCEU5twpf40i+j5A/UGMfgzPhhMt2kds
mQjwtATP93buyrZS9RASi2xZIajMIkR6lQVqMeS5eH8aUKlqivuXjFV/w8ai43JI
9dhZisg2e6GKmKgeQ54wnSEYtxUiVUiC/JlgKDF2tS7MiCz0DzUdLJIMv/XJFKHA
RBww+6ex5U/dI7nGn7mf3krwYLsq7uIHAeBT1CJw1rWuTqInOPSQt4nFClg1304A
d2NlL0DMCMgdAsHDKAEvgsuP3OelrwW5nTScniFJ+il2lkJuIgk=
=nKTA
-END PGP SIGNATURE-

Bug#874296: O: ploop -- tools to work with ploop devices and images

[Ola Lundqvist]

Package: wnpp

I no longer have an interest in maintaining this package.
The main reason is the trouble to maintain the kernel parts.

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#742240: libssl1.0.0: TLSv1_client_method()/SSL_Connect() heap overrun

[Sebastian Andrzej Siewior]

On 2014-03-21 02:04:11 [-0400], Brandon wrote:
> When creating a client context with SSL_CTX_new(TLSv1_client_method()),
> SSL_Connect() triggers a heap overrun with the following output from valgrind:

Does this still occur as of 1.1.0f?

> Thanks,
> Brandon

Sebastian

Bug#874294: libgtop2: FTBFS on hurd-i386: glibtop_machine.h absent

[Aaron M. Ucko]

Source: libgtop2
Version: 2.37.90-2
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

Builds of libgtop2 on hurd-i386 have been failing:

  In file included from init.c:29:0:
  ../include/glibtop/machine.h:5:10: fatal error: glibtop_machine.h: No such 
file or directory

Could you please take a look?  The Linux configuration would probably
make a decent starting point.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#689529: libssl1.0.0: Cannot connect to www.labanquepostale.fr:443

[Sebastian Andrzej Siewior]

On 2012-10-04 00:17:45 [+0200], Kurt Roeckx wrote:
> For reference, BigIP tracks this as Bug 376483. It is fixed in
> the BIG-IP LTM 10.2.4 software release.
> 
> An other site that seems to be affected by this is
> my.t-mobile.com:443.

closing. This BigIP issue should be solved and even my.t-mobile.com
works by now.
Looking forward to new BigIP issues once TLS 1.3 is out :)

> 
> Kurt

Sebastian

Bug#873824: offlineimap: Offlineimap needs to call SSL_set_min_proto_version() for openssl

[ael]

On Thu, Aug 31, 2017 at 06:38:46PM +0300, Ilias Tsitsimpis wrote:
> Hi,
> 
> > OpenSSL responded:
> > [SSL: VERSION_TOO_LOW] version too low (_ssl.c:661)
> >  *** Finished account 'ntlspam' in 0:00
> 
> If I understand correctly, you tested the above with the latest openssl
> (1.1.0f-5), is that right? If so, could you please try and set the
> `ssl_version` in offlineimap.conf file to tls1_1 or tls1, accordingly?
> This should force offlineimap to use the specified version.

Sorry for the delay. Yes, those options worked. Thank you.

I do find the documentation about the tls/ssl options in
/usr/share/doc/offlineimap/examples/offlineimap.conf.gz
pretty confusing, and had tried various configurations that I thought
should have worked.

But both ssl_version = tls1 and tls1_1 both worked on my tests on
imap.ntlworld.com.

For information:
$ openssl s_client -connect imap.ntlworld.com:imaps

CONNECTED(0003)
---
Certificate chain
 0 s:/C=GB/OU=Domain Control Validated/CN=imap.ntlworld.com
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
 1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-BEGIN CERTIFICATE-
MIIHUzCCBjugAwIBAgIMcUncDtUF6SBWgudAMA0GCSqGSIb3DQEBCwUAMEwxCzAJ
  --[snip]--
-END CERTIFICATE-
subject=/C=GB/OU=Domain Control Validated/CN=imap.ntlworld.com
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
No client certificate CA names sent
Server Temp Key: DH, 2048 bits
---
SSL handshake has read 3958 bytes and written 518 bytes
Verification: OK
---
New, SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.1
Cipher: DHE-RSA-AES256-SHA
Session-ID: AF2CBF5AFAB05F8023146EACFC3389D060A82228599CF734500D9A77B1AF53CC
Session-ID-ctx: 
Master-Key: 
3F9357B6BD33C8C09122855A66F7CEC6F65F9CFA0EA6FED7B9D8C695912BBC8A0184CDB1CBF983DA396D9CDB27997651
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1504551118
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
* OK Virgin Media IMAP4 server ready [ e4c558782NTL ]


Thanks again.

Bug#874292: openjdk-9: Please re-enable Zero builds for Hotspot archs

[John Paul Adrian Glaubitz]

Source: openjdk-9
Version: 9~b181-4
Severity: normal
Tags: patch

Hello!

While fixing #871319 someone (me!) sent a patch which accidentally
disabled the Zero builds on the Hotspot architectures because the
patch unset "altzero_archs". The correct fix should have been to
set that variable to "$(hotspot_archs) $(altshark_archs)", hence:

--- debian/rules~   2017-08-24 19:10:11.0 +0200
+++ debian/rules2017-09-04 21:08:29.204400359 +0200
@@ -163,7 +163,7 @@
 # Shark build but just crash
  altshark_archs =

-# altzero_archs = $(filter-out , $(hotspot_archs)) $(altshark_archs)
+altzero_archs = $(hotspot_archs) $(altshark_archs)

 ifeq (,$(filter noaltzero, $(DEB_BUILD_OPTIONS))$(filter noaltshark, 
$(DEB_BUILD_OPTIONS)))
ifneq (,$(filter $(DEB_HOST_ARCH), $(altzero_archs)))

Attaching a patch. Please consider applying it for the next upload.

Thanks and sorry for the mistake!

Adrian

--
  .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules~   2017-08-24 19:10:11.0 +0200
+++ debian/rules2017-09-04 21:08:29.204400359 +0200
@@ -163,7 +163,7 @@
 # Shark build but just crash
 altshark_archs =
 
-# altzero_archs = $(filter-out , $(hotspot_archs)) $(altshark_archs)
+altzero_archs = $(hotspot_archs) $(altshark_archs)
 
 ifeq (,$(filter noaltzero, $(DEB_BUILD_OPTIONS))$(filter noaltshark, 
$(DEB_BUILD_OPTIONS)))
   ifneq (,$(filter $(DEB_HOST_ARCH), $(altzero_archs)))

Bug#783875: playonlinux: "Error in POL_Wine", fails to install new programs

[Phil]

Dear Maintainers,

I get the same problem but I'm trying to install Dashlane (a password 
manager), a non-listed program (at least I selected non-listed). The program 
does run after installation but I do still get that error message. After I 
click 'OK' on the error message, it goes to another dialog which shows 
'loading' and seems never to end (it just stays there).

See screenshots for info.

I can confirm that Dashlane is actually installed (on the playonlinux virtual 
drive) but doesn't not appear as an entry on playonlinux.

Phil

Bug#874291: developers-reference: security uploads should go to *.security.upload.d.o

[Ansgar Burchardt]

Package: src:developers-reference
Version: 3.4.18
Severity: normal
Tags: patch

Security uploads should not be uploaded to security-master.d.o, but
ftp.security.upload.debian.org or (in the future)
ssh.security.upload.debian.org.

A patch to refer to *.security.upload.d.o or ftp.security.upload.d.o
instead of security-master.d.o is attached.

Ansgar
--- pkgs.dbk.ori2017-09-04 20:55:50.143885377 +0200
+++ pkgs.dbk2017-09-04 20:52:17.635087895 +0200
@@ -443,7 +443,7 @@
 Security uploads
 
 Do NOT upload a package to the security
-upload queue (on security-master.debian.org)
+upload queue (on *.security.upload.debian.org)
 without prior authorization from the security team.  If the
 package does not exactly meet the team's requirements, it will cause many
 problems and delays in dealing with the unwanted upload.  For details, please
@@ -1193,7 +1193,7 @@
 Uploading the fixed package
 
 Do NOT upload a package to the security
-upload queue (on security-master.debian.org)
+upload queue (on *.security.upload.debian.org)
 without prior authorization from the security team.  If the
 package does not exactly meet the team's requirements, it will cause many
 problems and delays in dealing with the unwanted upload.
@@ -1212,7 +1212,7 @@
 Once you have created and tested the new package and it has been approved by
 the security team, it needs to be uploaded so that it can be installed in the
 archives.  For security uploads, the place to upload to is
-ftp://security-master.debian.org/pub/SecurityUploadQueue/.
+ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue/.
 
 
 Once an upload to the security queue has been accepted, the package will

Bug#874290: refcard: [INTL:nl] Dutch po file for the refcard package

[Frans Spiesschaert]

 
 
Package: refcard 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the refcard
package. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as "po4a/nl.po" in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874289: gnupg1: [INTL:nl] Dutch po file for the gnupg1 package

[Frans Spiesschaert]

 
 
Package: gnupg1 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the gnupg1 package. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874288: apt-listchanges: [INTL:nl] Dutch po file for the apt-listchanges package

[Frans Spiesschaert]

 
 
Package: apt-listchanges 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the apt-listchanges
package. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874287: debconf: [INTL:nl] Dutch po file for the debconf package

[Frans Spiesschaert]

 
 
Package: debconf 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the debconf
package. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874285: apt: [INTL:nl] Dutch po file for the apt package

[Frans Spiesschaert]

 
 
Package: apt 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the apt package. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874286: gnome-shell-pomodoro: uninstallable with gnome-shell 3.25+

[Jeremy Bicha]

Package: gnome-shell-pomodoro
Version: 0.13.2-1
Severity: important

GNOME 3.26 will be released next week. gnome-shell 3.25.91 is
available for testing now in Debian experimental. gnome-shell 3.26
will be available in Debian unstable soon, but it's currently blocked
by https://bugs.debian.org/873778

Please either raise the versioned dependency allowed for gnome-shell
or drop the maximum version check completely (as most GNOME Shell
extensions packaged in Debian have done).

Thanks,
Jeremy Bicha

Bug#855868: [pkg-gnupg-maint] Bug#855868: GPG_AGENT_INFO and SSH_AUTH_SOCK not set in wayland sessions

[rufo]

On 21/08/17 14:18, Raphael Hertzog wrote:
> 
> I agree it looks like a good solution. Daniel, can you implement this
> please?
> 

Quick amendment to my previous suggestion.

At least until this patch
(https://git.gnome.org/browse/gnome-session/commit/?id=818266a898b803960ce8dd6d330c1ef6934bba46)
lands in gnome-session-bin, we also need to set
GSM_SKIP_SSH_AGENT_WORKAROUND to prevent our SSH_AUTH_SOCK from being
clobbered.  Updated script below.

  --rufo



#!/bin/bash

if [ -n "$(gpgconf --list-options gpg-agent | \
  awk -F: '/^enable-ssh-support:/{ print $10 }')" ]; then
echo SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
echo GSM_SKIP_SSH_AGENT_WORKAROUND=true
fi

Bug#874283: isa-support: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: isa-support 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of isa-support
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874281: open-infrastructure-container-tools: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: open-infrastructure-container-tools 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of open-
infrastructure-container-tools debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874282: sash: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: sash 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of sash debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874280: openafs: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: openafs 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of openafs debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874279: RM: why [mips mips64el mipsel ppc64el s390x] -- RoM; ANAIS

[Ralf Treinen]

Package: ftp.debian.org

Hi,

please remove binaries of the package "why" for the following
architectures from unstable:

mips, mips64el, mipsel, powerpc, ppc64el, s390x

These are no longer supported by upstream.

Thanks -Ralf.


signature.asc
Description: PGP signature

Bug#874278: apt-listchanges: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: apt-listchanges 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of apt-listchanges
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874277: fontconfig: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: fontconfig 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of fontconfig
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#874276: ca-certificates-java: fails to install on armhf: Error: missing `server' JVM at `/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'

[Emilio Pozuelo Monfort]

Package: ca-certificates-java
Version: 20170531+nmu1
Severity: grave

Hi,

Your package fails to install on armhf:

Setting up ca-certificates-java (20170531+nmu1) ...
Error: missing `server' JVM at 
`/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'.
Please install or use the JRE or JDK that contains these missing components.
dpkg: error processing package ca-certificates-java (--configure):
 subprocess installed post-installation script returned error exit status 4

This may be related to one of the arm related changes in openjdk-8 8u144-b01-1.

For logs see e.g.

https://buildd.debian.org/status/logs.php?pkg=pdf2htmlex=0.14.6%2Bds-3%2Bb1=armhf
https://buildd.debian.org/status/logs.php?pkg=gdal=2.2.1%2Bdfsg-2%2Bb2=armhf

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

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

Versions of packages ca-certificates-java depends on:
ii  ca-certificates  20170717
ii  default-jre-headless [java7-runtime-headless]2:1.8-59
ii  libnss3  2:3.32-2
ii  openjdk-8-jre-headless [java7-runtime-headless]  8u144-b01-1

ca-certificates-java recommends no packages.

ca-certificates-java suggests no packages.

-- Configuration Files:
/etc/default/cacerts [Errno 13] Permission denied: '/etc/default/cacerts'

-- no debconf information

Bug#874275: exifprobe: Consistent segmentation fault

[Karl E. Jorgensen]

Package: exifprobe
Version: 2.0.1+git20170416.3c2b769-1
Severity: important

Dear Maintainer,

When running "exifprobe -L" I get consistent "segmentation fault". Same occurs 
without the -L option.

I grabbed the debian source, and combined with a core dump I have this 
backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x7ff6ebef9da8 in _IO_vfprintf_internal (s=s@entry=0x7ffd7d7bcdd0, 
format=, format@entry=0x55fc212e4c6d "%s%s%s", 
ap=ap@entry=0x7ffd7d7bcf48) at vfprintf.c:1637
#2  0x7ff6ebfa7aa6 in ___vsnprintf_chk (s=0x7ffd7d7bd030 "", 
maxlen=, flags=1, slen=, format=0x55fc212e4c6d 
"%s%s%s", args=args@entry=0x7ffd7d7bcf48) at vsnprintf_chk.c:63
#3  0x7ff6ebfa7a08 in ___snprintf_chk (s=s@entry=0x7ffd7d7bd030 "", 
maxlen=maxlen@entry=1024, flags=flags@entry=1, slen=slen@entry=1024, 
format=format@entry=0x55fc212e4c6d "%s%s%s") at snprintf_chk.c:34
#4  0x55fc212a3680 in snprintf (__fmt=0x55fc212e4c6d "%s%s%s", __n=1024, 
__s=0x7ffd7d7bd030 "") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:64
#5  splice (string1=, string1@entry=0x22509790 , sep=, 
sep@entry=0x55fc212e1329 ".", string2=) at misc.c:1313
#6  0x55fc21299c89 in process_tiff_ifd (inptr=inptr@entry=0x55fc22507010, 
byteorder=, ifd_offset=ifd_offset@entry=8, 
fileoffset_base=fileoffset_base@entry=12, max_offset=max_offset@entry=0, 
summary_entry=summary_entry@entry=0x55fc22509660, 
parent_name=0x22509790 , 
ifdtype=0, ifdnum=0, subifdnum=-1, indent=4) at process.c:183
#7  0x55fc2129f1e8 in process_app1 (inptr=inptr@entry=0x55fc22507010, 
app1_offset=app1_offset@entry=2, tag=tag@entry=65505, 
summary_entry=summary_entry@entry=0x55fc22509660, 
parent_name=parent_name@entry=0x55fc212e4ad8 "JPEG", indent=indent@entry=2) at 
process.c:3914
#8  0x55fc212a1620 in process_jpeg_segments (inptr=0x55fc22507010, 
marker_offset=2, tag=65505, data_length=0, summary_entry=, 
parent_name=0x55fc212e4ad8 "JPEG", prefix=0x55fc212e0ca2 "@", indent=0) at 
process.c:3103
#9  0x55fc2128c9fe in main (argc=, argv=0x7ffd7d7bd848) at 
main.c:214


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

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

Versions of packages exifprobe depends on:
ii  libc6  2.24-17

exifprobe recommends no packages.

exifprobe suggests no packages.

-- no debconf information

Downgrading exifprobe to version 2.0.1-11 makes exifprobe work normally again.

Bug#874251: installation-reports: Debian 9.1 installer fails on HP ProLiant DL360 G4 with HP Smart Array 6i

[rpr //]

On 4 September 2017 at 16:50, Steve McIntyre  wrote:
>>
>>Is that something to be fixed on the kernel side? Or some buggy UEFI
>>that would need a workaround maybe?
>
> That's a good question. acpi=off is often a workaround for buggy
> firmware in my experience, but not typically something fixable
> externally.

I can add to this report that some time ago I successfully installed
Debian 8.7.1 amd64 (kernel 3.16 without apci=off parameter) on the
same hardware. It seems to me this issue in Debian 9.1 installer is a
regression.

-- rpr.

Bug#871912: frama-c FTBFS on ppc64el/s390x/mips*: configure: error: native dynlink does not work.

[Ralf Treinen]

Hi,

On Sat, Aug 12, 2017 at 03:03:11PM -0400, Mehdi Dogguy wrote:
> Hi,
> 
> Thank you for this report.
> 
> On 12/08/2017 09:33, Adrian Bunk wrote:
> > configure: ***
> > configure: * CONFIGURE TOOLS AND LIBRARIES USED BY SOME PLUG-INS *
> > configure: ***
> > Ocamlfind -> using 
> > +lablgtk2.(/usr/lib/ocaml/lablgtk2,/usr/lib/ocaml/lablgtk2)
> > checking for /usr/lib/ocaml/lablgtk2/lablgtksourceview2.cma... yes
> > checking for /usr/lib/ocaml/lablgtk2/lablgnomecanvas.cma... yes
> > checking for /usr/lib/ocaml/lablgtk2/lablgtk.cma... yes
> > checking for dot... yes
> > configure: error: native dynlink does not work.
> > debian/rules:13: recipe for target 'override_dh_auto_configure' failed
> > make[1]: *** [override_dh_auto_configure] Error 2
> > 
> 
> For reference: After seeing this build failure after my upload, I have sent
> a mail to upstream asking whether bytecode architectures are still supported.
> I didn't want to patch Frama-C to make it build again there is there is no
> will from upstream to support those architectures (It is trivial to fix but
> might a useless effort). I am still waiting for their reply.

I agree with Mehdi, if upstream doesn't want to support bytecode
architecturd any longer then I don't think it is worth our time to fix
this. BTW, why (which seems to be the only reverse dependency of
frama-c) also dropped support for bytecode architectures.

-Ralf.

Bug#874274: libreoffice: FTBFS on hppa - undefined references linking slideshow

[John David Anglin]

Source: libreoffice
Version: 1:5.4.1-1
Severity: normal

Dear Maintainer,

Here is a summary:

[build MOD] slideshow
S=/<> && I=$S/instdir && W=$S/workdir &&  mkdir -p $W/Module/ && 
touch $W/Module/slideshow
/<>/workdir/CxxObject/svx/source/fmcomp/fmgridcl.o: In function 
`FmGridHeader::ExecuteDrop(ExecuteDropEvent const&)':
././svx/source/fmcomp/fmgridcl.cxx:266: undefined reference to 
`dbtools::getConnection_withFeedback(rtl::OUString const&, rtl::OUString 
const&, rtl::OUString const&, 
com::sun::star::uno::Reference const&)'
/<>/workdir/CxxObject/svx/source/fmcomp/fmgridcl.o: In function 
`FmGridHeader::PostExecuteColumnContextMenu(unsigned short, PopupMenu const&, 
unsigned short)':
././svx/source/fmcomp/fmgridcl.cxx:947: undefined reference to 
`dbtools::TransferFormComponentProperties(com::sun::star::uno::Reference
 const&, com::sun::star::uno::Reference 
const&, com::sun::star::lang::Locale const&)'
/<>/workdir/CxxObject/svx/source/fmcomp/fmgridcl.o: In function 
`FmGridHeader::OnAsyncExecuteDrop(void*)':
././svx/source/fmcomp/fmgridcl.cxx:378: undefined reference to 
`dbtools::getNumberFormats(com::sun::star::uno::Reference
 const&, bool, 
com::sun::star::uno::Reference const&)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`DbFormattedField::GetFormatText(com::sun::star::uno::Reference
 const&, com::sun::star::uno::Reference 
const&, Color**)':
././svx/source/fmcomp/gridcell.cxx:1486: undefined reference to 
`dbtools::DBTypeConversion::getValue(com::sun::star::uno::Reference
 const&, com::sun::star::util::Date const&)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`DbFormattedField::UpdateFromField(com::sun::star::uno::Reference
 const&, com::sun::star::uno::Reference 
const&)':
././svx/source/fmcomp/gridcell.cxx:1530: undefined reference to 
`dbtools::DBTypeConversion::getValue(com::sun::star::uno::Reference
 const&, com::sun::star::util::Date const&)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`FmXGridCell::getLock()':
././svx/source/fmcomp/gridcell.cxx:3242: undefined reference to 
`connectivity::checkDisposed(bool)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`FmXGridCell::addWindowListener(com::sun::star::uno::Reference
 const&)':
././svx/source/fmcomp/gridcell.cxx:3297: undefined reference to 
`connectivity::checkDisposed(bool)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`FmXGridCell::addFocusListener(com::sun::star::uno::Reference
 const&)':
././svx/source/fmcomp/gridcell.cxx:3311: undefined reference to 
`connectivity::checkDisposed(bool)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`FmXGridCell::addKeyListener(com::sun::star::uno::Reference
 const&)':
././svx/source/fmcomp/gridcell.cxx:3325: undefined reference to 
`connectivity::checkDisposed(bool)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`FmXGridCell::addMouseListener(com::sun::star::uno::Reference
 const&)':
././svx/source/fmcomp/gridcell.cxx:3339: undefined reference to 
`connectivity::checkDisposed(bool)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o:././svx/source/fmcomp/gridcell.cxx:3353:
 more undefined references to `connectivity::checkDisposed(bool)' follow
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`DbNumericField::implAdjustGenericFieldSetting(com::sun::star::uno::Reference
 const&)':
././svx/source/fmcomp/gridcell.cxx:1902: undefined reference to 
`dbtools::getConnection(com::sun::star::uno::Reference
 const&)'
././svx/source/fmcomp/gridcell.cxx:1902: undefined reference to 
`dbtools::getNumberFormats(com::sun::star::uno::Reference
 const&, bool, 
com::sun::star::uno::Reference const&)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`FmXGridCell::onFocusLost(com::sun::star::awt::FocusEvent const&)':
././svx/source/fmcomp/gridcell.cxx:3395: undefined reference to 
`connectivity::checkDisposed(bool)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`FmXGridCell::onFocusGained(com::sun::star::awt::FocusEvent const&)':
././svx/source/fmcomp/gridcell.cxx:3388: undefined reference to 
`connectivity::checkDisposed(bool)'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 
`DbTextField::GetFormatText(com::sun::star::uno::Reference
 const&, com::sun::star::uno::Reference 
const&, Color**)':
././svx/source/fmcomp/gridcell.cxx:1157: undefined reference to 
`dbtools::FormattedColumnValue::FormattedColumnValue(com::sun::star::uno::Reference
 const&, com::sun::star::uno::Reference 
const&)'
././svx/source/fmcomp/gridcell.cxx:1159: undefined reference to 
`dbtools::FormattedColumnValue::getFormattedValue() const'
././svx/source/fmcomp/gridcell.cxx:1157: undefined reference to 
`dbtools::FormattedColumnValue::~FormattedColumnValue()'
././svx/source/fmcomp/gridcell.cxx:1157: undefined reference to 
`dbtools::FormattedColumnValue::~FormattedColumnValue()'
/<>/workdir/CxxObject/svx/source/fmcomp/gridcell.o: In function 

Bug#874273: frama-c: FTBFS on i386

[Ralf Treinen]

Source: frama-c
Version: 20170501+phosphorus+dfsg-1
Severity: serious

Hi, frama-c FTBFS on i386. The tail of the build log says:

/usr/include/i386-linux-gnu/bits/mathinline.h: In function 'ceill':
/usr/include/i386-linux-gnu/bits/mathinline.h:764:1: error: expected ':' or ')' 
before string constant
 __inline_mathcodeNP (ceil, __x, \
 ^
Makefile:272: recipe for target 'src/jemalloc.pic.o' failed
make[2]: *** [src/jemalloc.pic.o] Error 1
make[2]: Leaving directory 
'/<>/frama-c-20170501+phosphorus+dfsg/src/plugins/e-acsl/contrib/libjemalloc'
src/plugins/e-acsl/Makefile:158: recipe for target 
'src/plugins/e-acsl/lib/libeacsl-jemalloc.a' failed
make[1]: *** [src/plugins/e-acsl/lib/libeacsl-jemalloc.a] Error 2
make[1]: Leaving directory '/<>/frama-c-20170501+phosphorus+dfsg'
dh_auto_build: make -j1 returned exit code 2
debian/rules:65: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

See

https://buildd.debian.org/status/fetch.php?pkg=frama-c=i386=20170501%2Bphosphorus%2Bdfsg-1=1502480362=0

for a complete log.

-Ralf.

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Christopher Li]

On Sun, Sep 3, 2017 at 5:14 PM, Luc Van Oostenryck
 wrote:
>
> I really think that the testsuite should not depend on system or library
> header.

I think that is a good point. We can start cleaning up the system header
file dependency in the existing test suite. See how it goes.

>
> Otherwise, I'm not at all opposed to sparse being universal but I would like
> to note that things can become very quickly very very messy.
> For example, for the current problem here I understood that it was
> at least partially based on the lack of a definition of _CALL_ELF
> but do we need to define it to 1 or to 2, in other words, do we need
> to support the ELFv1 ABI or the ELFv2? GCC has some flags for this
> (-mabi=elfv[12]) but what default value do we want? ELFv1 is the default

I think we can just sparse default to as late as the latest release
version of gcc.

> for big-endian platform and ELFv2 for little-endian platform, so yes,
> we need a flag for the endianness but which endianness we want as default?

I am tempting to make the endianness the same as the host gcc by default.
Then it can be overwrite by architecture flags.

>
> Things become even more fun when taking in account the difference
> between GCC version. Do we want to be universal there too (and thus
> have some flags for to specify which gcc's version we want to mimick)?
> What about other compilers?

I purpose just sync to the latest gcc version (or a late enough version
we can agree on. e.g. the one that supported by kernel compile.) Sparse
current try to sync to the latest gcc attributes already.

> I think that part of the needed info can be auto-extracted from GCC
> when doing a native build. Using some sort of spec file or a .sparserc

Is there a way to do auto-extract? That would be a good starting point.

> I also note that currently, sparse is already largely universal *because*
> it *doesn't* need those platform details (or only the very minimal: word 
> size).

Sparse is not universal, it just support a very small sub set of the C
source file that haven't expose to those platform detail macros. Adding
those architecture macro support will not make it any less universal.
Might slow things down, that is some thing we need to watch out for.

Chris

Bug#853491: libffado: ftbfs with GCC-7

[Philip Chung]

Control: tags -1 patch
Control: affects 871274 src:libffado

On Tue, 31 Jan 2017 09:32:52 + Matthias Klose  wrote:
> Package: src:libffado
> Version: 2.3.0-2
> Severity: normal
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-7
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The
> severity of this report may be raised before the buster release.
> There is no need to fix this issue in time for the stretch release.
> 
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc7-20170126/libffado_2.3.0-2_unstable_gcc7.log
> The last lines of the build log are at the end of this report.
> 
> To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
> 
>   apt-get -t=experimental install g++ 
> 
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-7/porting_to.html
> 
> [...]
> /usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
>template class auto_ptr;
> ^~~~
> In file included from src/fireworks/fireworks_device.cpp:30:0:
> src/fireworks/audiofire/audiofire_device.h:37:39: warning: 'template 
> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
>  AudioFire( DeviceManager& d, std::auto_ptr( configRom ));
>^~~~
> In file included from /usr/include/c++/7/memory:80:0,
>  from 
> /usr/include/libxml++-2.6/libxml++/parsers/saxparser.h:14,
>  from /usr/include/libxml++-2.6/libxml++/libxml++.h:53,
>  from src/libutil/serialize_libxml.h:29,
>  from src/libutil/serialize.h:32,
>  from src/libieee1394/configrom.h:32,
>  from src/devicemanager.h:30,
>  from src/fireworks/fireworks_device.cpp:25:
> /usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
>template class auto_ptr;
> ^~~~
> src/fireworks/fireworks_device.cpp:52:39: warning: 'template class 
> std::auto_ptr' is deprecated [-Wdeprecated-declarations]
>  Device::Device(DeviceManager& d, std::auto_ptr( configRom ))
>^~~~
> In file included from /usr/include/c++/7/memory:80:0,
>  from 
> /usr/include/libxml++-2.6/libxml++/parsers/saxparser.h:14,
>  from /usr/include/libxml++-2.6/libxml++/libxml++.h:53,
>  from src/libutil/serialize_libxml.h:29,
>  from src/libutil/serialize.h:32,
>  from src/libieee1394/configrom.h:32,

Attached is a patch that will fix the compilation errors.

The errors occur because pointers are being compared against the
character literal '\0' rather than 0. An initial reading of the code
suggests that the intent is to dereference the pointers first. The patch
dereferences the pointers using array syntax.

The code now compiles, the package still fails to build because of
linking problems with libconfig++ [1].

[1] https://bugs.debian.org/871274
Description: Fix pointer comparisons with null terminators
Author: Philip Chung 
Bug-Debian: https://bugs.debian.org/853491
Last-Update: 2017-09-04

Index: libffado/src/libieee1394/configrom.cpp
===
--- libffado.orig/src/libieee1394/configrom.cpp
+++ libffado/src/libieee1394/configrom.cpp
@@ -176,7 +176,7 @@ ConfigRom::initialize()
 ( void* )CSR1212_TEXTUAL_DESCRIPTOR_LEAF_DATA( m_vendorNameKv ),
 len );
 
-while ((buf + len - 1) == '\0') {
+while (buf[len - 1] == '\0') {
 len--;
 }
 // \todo XXX seems a bit strage to do this but the nodemgr.c code does
@@ -195,7 +195,7 @@ ConfigRom::initialize()
 memcpy( buf,
 ( void* )CSR1212_TEXTUAL_DESCRIPTOR_LEAF_DATA( m_modelNameKv ),
 len );
-while ((buf + len - 1) == '\0') {
+while (buf[len - 1] == '\0') {
 len--;
 }
 // \todo XXX for edirol fa-66 it seems somehow broken. see above

Bug#874272: new version breaks xpra, PyFPE_jbuf missing

[Marc Haber]

Package: python-numpy
Version: 1:1.12.1-3+b2
Severity: important

Hi,

after upgrading python and python-numpy, the xpra server won't start any
more:

xpra main error:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 126, in 
main
return run_mode(script_file, err, options, args, mode, defaults)
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 1008, in 
run_mode
return run_server(error_cb, options, mode, script_file, args, 
current_display)
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/server.py", line 1207, in 
run_server
from xpra.x11.gtk2.wm import wm_check
  File "/usr/lib/python2.7/dist-packages/xpra/x11/gtk2/wm.py", line 25, in 

from xpra.x11.bindings.keyboard_bindings import X11KeyboardBindings 
#@UnresolvedImport
ImportError: 
/usr/lib/python2.7/dist-packages/xpra/x11/bindings/keyboard_bindings.x86_64-linux-gnu.so:
 undefined symbol: PyFPE_jbuf

Downgrading python-numpy and python to the versions listed below makes
xpra run again.

Since googling for PyFPE_jbuf brings up references to python-numpy, I am
filing this against python-numpy. Please reassign if appropriate, and
also handle the (probably deflated) severity of this bug report.

Greetings
Marc



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

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

Versions of packages python-numpy depends on:
ii  libblas3 [libblas.so.3]  3.7.1-1
ii  libc62.24-15
ii  liblapack3 [liblapack.so.3]  3.7.1-1
ii  python   2.7.13-2
ii  python2.72.7.13-4

python-numpy recommends no packages.

Versions of packages python-numpy suggests:
ii  gcc   4:7.1.0-2
pn  gfortran  
pn  python-dev
pn  python-nose   
pn  python-numpy-dbg  
pn  python-numpy-doc  

-- no debconf information

Bug#874271: icewm: Properly reserve taskbar area in vertical dualhead configuraitons

[Dmitry Semyonov]

Package: icewm
Version: 1.4.3+mod+20170901-1
Severity: important
Tags: patch

Dear Maintainer,

Please, find the $subj patch in attachment. Created against the
debian/experimental branch.

-- 
...Bye..Dmitry.
From 04dced96a10e3ebe5836bf462106f214c53adfa3 Mon Sep 17 00:00:00 2001
From: Dmitry Semyonov 
Date: Mon, 4 Sep 2017 20:07:11 +0300
Subject: [PATCH] Properly reserve taskbar area in vertical dualhead
 configurations

Prevents windows placement under the taskbar when TaskBarAtTop=0, and fixes
placement of maximized windows on lower screen when TaskBarAtTop=1.
---
 src/wmtaskbar.cc | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/wmtaskbar.cc b/src/wmtaskbar.cc
index a1652f47..8b39b365 100644
--- a/src/wmtaskbar.cc
+++ b/src/wmtaskbar.cc
@@ -817,10 +817,7 @@ void TaskBar::updateWMHints() {
 
 long wk[4] = { 0, 0, 0, 0 };
 if (!taskBarAutoHide && !fIsCollapsed && getFrame()) {
-if (taskBarAtTop)
-wk[2] = getFrame()->y() + getFrame()->height();
-else
-wk[3] = dh - getFrame()->y();
+wk[taskBarAtTop ? 2 : 3] = getFrame()->height();
 }
 
 MSG(("SET NET WM STRUT"));
-- 
2.11.0