Bug#886453: [src:spl-linux] Fails to build for 4.14.0-3

[Antonio Russo]

Package: src:zfs-linux
Version: 0.7.4-1
Severity: grave

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

Building spl with linux 4.14.0-3 fails, due to a missing dependency on 
libelf-dev.
(installing the package allows the build to proceed).

Additionally, objtool is missing from the kernel source [1]. For anyone reading 
this,
you can fake this by installing linux source and then linking the tools 
directory in.
I.e., apt-get source linux then

ln -s tools /usr/src/linux-headers-4.14.0-3-amd64

That's obviously just a hack until [1] is properly addressed.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833500

Bug#886452: Subject: tex-common: installed tex-common package post-installation script subprocess returned error exit status 1

[Manfred Ilg]

Package: tex-common
Version: 6.09
Severity: important


Dear Maintainer,

when I try to uprade tex-commen I get the following error:

tex-common (6.09) wird eingerichtet ...
Running mktexlsr. This may take some time... done.
Running mtxrun --generate. This may take some time... done.
Running updmap-sys. This may take some time...
updmap-sys failed. Output has been stored in
/tmp/updmap.nZEeXO4z
Please include this file if you report a bug.

Sometimes, not accepting conffile updates in /etc/texmf/updmap.d
causes updmap-sys to fail.  Please check for files with extension
.dpkg-dist or .ucf-dist in this directory

dpkg: Fehler beim Bearbeiten des Paketes tex-common (--configure):

Fehler traten auf beim Bearbeiten von:
 tex-common
E: Sub-process /usr/bin/dpkg returned an error code (1)

cat /tmp/updmap.nZEeXO4z
updmap will read the following updmap.cfg files (in precedence order):
  /etc/texmf/web2c/updmap.cfg
  /usr/share/texmf/web2c/updmap.cfg
  /usr/share/texlive/texmf-dist/web2c/updmap.cfg
updmap may write changes to the following updmap.cfg file:
 /etc/texmf/web2c/updmap.cfg
dvips output dir: "/var/lib/texmf/fonts/map/dvips/updmap"
pdftex output dir: "/var/lib/texmf/fonts/map/pdftex/updmap"
dvipdfmx output dir: "/var/lib/texmf/fonts/map/dvipdfmx/updmap"
updmap [ERROR]: The following map file(s) couldn't be found:
updmap [ERROR]: emerald.map (in /etc/texmf/web2c/updmap.cfg)
updmap [ERROR]: Did you run mktexlsr?

    You can disable non-existent map entries using the option
  --syncwithtrees.

  Greeting

  Manfred Ilg


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

Kernel: Linux 4.14.11-towo.3-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de:en_US (charmap=UTF-8)

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

Versions of packages tex-common depends on:
ii  dpkg  1.19.0.4
ii  ucf   3.0036

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  11

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  libpaper-utils 1.1.24+nmu5
ii  texlive-binaries   2017.20170613.44572-8
ii  ucf    3.0036
ii  xdg-utils  1.1.2-2~siduction1

Versions of packages texlive-base recommends:
ii  lmodern  2.004.5-3

Versions of packages texlive-base suggests:
ii  ghostscript [postscript-viewer]  9.22~dfsg-1
ii  okular [postscript-viewer]   4:17.08.3-2
pn  perl-tk  
pn  xpdf-reader | pdf-viewer 

Versions of packages texlive-binaries depends on:
ii  dpkg  1.19.0.4
ii  install-info  6.5.0.dfsg.1-1
ii  libc6 2.26-2
ii  libcairo2 1.15.8-3
ii  libfontconfig1    2.12.6-0.1
ii  libfreetype6  2.8.1-1
ii  libgcc1   1:7.2.0-18
ii  libgmp10  2:6.1.2+dfsg-1.1
ii  libgraphite2-3    1.3.10-8
ii  libgs9    9.22~dfsg-1
ii  libharfbuzz-icu0  1.7.2-1
ii  libharfbuzz0b 1.7.2-1
ii  libice6   2:1.0.9-2
ii  libicu57  57.1-8
ii  libkpathsea6  2017.20170613.44572-8
ii  libmpfr4  3.1.6-1
ii  libpaper1 1.1.24+nmu5
ii  libpixman-1-0 0.34.0-2
ii  libpng16-16   1.6.34-1
ii  libpoppler72  0.61.1-2
ii  libpotrace0   1.14-2
ii  libptexenc1   2017.20170613.44572-8
ii  libsm6    2:1.2.2-1+b3
ii  libstdc++6    7.2.0-18
ii  libsynctex1   2017.20170613.44572-8
ii  libtexlua52   2017.20170613.44572-8
ii  libtexluajit2 2017.20170613.44572-8
ii  libx11-6  2:1.6.4-3
ii  libxaw7   2:1.0.13-1+b2
ii  libxext6  2:1.3.3-1+b2
ii  libxi6    2:1.7.9-1
ii  libxmu6   2:1.1.2-2
ii  libxpm4   1:3.5.12-1
ii  libxt6    1:1.1.5-1
ii  libzzip-0-13  0.13.62-3.1
ii  perl  5.26.1-3
ii  t1utils   1.41-2
ii  zlib1g    1:1.2.8.dfsg-5

Versions of packages texlive-binaries recommends:
ii  texlive-base  2017.20180103-1

-- debconf information:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  texlive-base/texconfig_ignorant:

Bug#886451: node-marked: CVE-2017-1000427: vulnerable to XSS attack in the data: URI parser

[Salvatore Bonaccorso]

Source: node-marked
Version: 0.3.6+dfsg-1
Severity: important
Tags: patch security upstream

Hi,

the following vulnerability was published for node-marked.

CVE-2017-1000427[0]:
| marked version 0.3.6 and earlier is vulnerable to an XSS attack in the
| data: URI parser.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-1000427
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000427
[1] https://snyk.io/vuln/npm:marked:20170112

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#886366: same issue with 4.14.0-3-amd64

[Alexandra Kossovsky]

I have similar issue with 4.14.0-3-amd64

make[6]: Entering directory '/usr/src/linux-headers-4.14.0-3-amd64'
  AR  /tmp/tmp.VCaeAIqv24/built-in.o
make[9]: *** No rule to make target 'tools/objtool/objtool', needed by 
'/tmp/tmp.VCaeAIqv24/test.o'.  Stop.
/usr/src/linux-headers-4.14.0-3-common/Makefile:1525: recipe for target 
'_module_/tmp/tmp.VCaeAIqv24' failed

make[8]: *** [_module_/tmp/tmp.VCaeAIqv24] Error 2
Makefile:146: recipe for target 'sub-make' failed
make[7]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make[6]: *** [all] Error 2
make[6]: Leaving directory '/usr/src/linux-headers-4.14.0-3-amd64'

Bug#874727: closed by Anton Gladky <gl...@debian.org> (Bug#874727: fixed in coin3 3.1.4~abc9f50+dfsg2-1)

[Don Armstrong]

Control: found -1 3.1.4-abc9f50+dfsg3-2

On Fri, 05 Jan 2018, mlampert wrote:
> Version libcoin89-dev 3.1.4-abc9f50+dfsg3-2 (in Debian Testing as of
> yesterday) still has a statically linked version of libexpat - and
> still causes any application using the system version libexpat to
> segfault.
> 
> 3.1.4-abc9f50+dfsg2-1 never became available in Testing - not sure what 
> happened.

You misdirected this to ow...@bugs.debian.org; that address is only for
reporting issues with the BTS itself.

I've gone ahead and marked this bug as found in that version; I have not
independently verified this, however.


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

Herodotus says, "Very few things happen at the right time, and the
rest do not happen at all. The conscientious historian will correct
these defects".
 -- Mark Twain _A Horse's Tail_

Bug#886450: tracker.debian.org: Separate subscription for official and non-official architectures builds

[Mike Hommey]

Package: tracker.debian.org
Severity: wishlist

I like to subscribe to the `build` keyword for some of my packages,
essentially to get notifications of build failures. The sad result is
that because some buildds are dumb, I'm being spammed by them trying
and failing to build over and over. Which would be kind of okay if those
were builds for official architectures supported by debian, but they
aren't.

So I would very much be interested by a separation between build for
official architectures and build for unofficial architectures.

Mike

PS: In case you're interested: see all the Maybe-Failed on this page:
https://buildd.debian.org/status/logs.php?pkg=firefox=powerpc
I received a mail for every single one of them. And they are mostly failed
because of disk space...

Bug#874727: closed by Anton Gladky <gl...@debian.org> (Bug#874727: fixed in coin3 3.1.4~abc9f50+dfsg2-1)

[mlampert]

Version libcoin89-dev 3.1.4-abc9f50+dfsg3-2 (in Debian Testing as of yesterday) 
still has a statically linked version of libexpat - and still causes any 
application using the system version libexpat to segfault.

3.1.4-abc9f50+dfsg2-1 never became available in Testing - not sure what 
happened.


On Thu, 21 Dec 2017 12:21:09 +
"Debian Bug Tracking System"  wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the libcoin80v5 package:
> 
> #874727: libcoin80v5: Program using libcoin80v5 and any other library
> that uses lebexpat1 segfaults.
> 
> It has been closed by Anton Gladky .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Anton Gladky
>  by replying to this email.
> 
> 

Bug#886316: gcc-7: fix typo for N32 conditions in debian/rules2

[Matthias Klose]

On 05.01.2018 14:26, YunQiang Su wrote:
> Ohhh, you are right.
> 
> in fact it is a quite simple patch:
> 
> just in debian/rules2, there are 4 snap
> $(biarchn32)-$(biarch32) for N32,
> 
> the $(biarchn32) should be $(biarch64) here.

please attach a proper patch.

I also see in rules2: --with-arch-64=mips64r2

is this correct, or should that be r6?

again, please attach a (tested) patch, please for gcc-7 and gcc-8.


thanks, Matthias

> On Thu, Jan 4, 2018 at 8:22 PM, James Cowgill  wrote:
>> Hi,
>>
>> On 04/01/18 11:00, YunQiang Su wrote:
>>> Package: src:gcc-7
>>> Version: 7.2.0-18
>>>
>>> when detect mipsn32 triarch,
>>> we use ifeq ($(biarchn32)-$(biarch32),yes-yes), but we should use
>>>   ifeq ($(biarch64)-$(biarch32),yes-yes)
>>>
>>
>> I guess you attached the wrong patch?
>>
>> James
>>
> 
> 
> 

Bug#886449: Include HTML docs from tarball in libfuse-dev

[Dato Simó]

Package: libfuse-dev
Version: 2.9.7-1
Severity: wishlist

It would be nice to have the ‘doc/html’ directory from the upstream
tarball made available in /usr/share/doc/libfuse-dev/html. 


-d

Bug#886117: FTBFS: most of testsuite

[Alexander Zangerl]

On Wed, 03 Jan 2018 16:24:57 +0100, Adam Borowski writes:
>Working hypothesis so far is that the testsuite fails on btrfs; I won't be
>able to confirm until the evening.

i'm just building a kernel with btrfs to verify your very probable hypothesis;

upstream's test suite is a fairly yucktastic setup that ditches a lot of
very useful output for content-free assertions.

what does fail in your tests is the test priming in testing/__init__.py,
where testing/testfiles.tar.gz is unpacked.

it's running "tar xzf testfiles.tar.gz > /dev/null 2>&1" and that
tarball does contain a number of nastily named files (glancing at
hexdump tells me it's iso-8859-1 and not utf-8).
i suspect these file names are the root cause.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
"Ein Blitzableiter auf einem Kirchturm ist das denkbar stärkste 
Mißtrauensvotum gegen den lieben Gott." -- Karl Kraus


signature.asc
Description: Digital Signature

Bug#886403: [src:zfs-linux]

[Antonio Russo]

Control: merge -1 884812

As a side not: The changelog for 0.6.5 is

* 504bfc8b4 Fix multihost stale cache file import
* 53a8cbd70 Fix ZTS MMP tests and ztest -M behavior
* 505b97ae2 Enable QAT support in zfs-dkms RPM
* 30a64ebae Add zfs-import.target services in spec file
* da16fc573 Enable zfs-import.target in systemd preset (#6968)

The last three shouldn't affect Debian users. The ztest change
shouldn't affect normal users.

504bfc8b4, OTOH, is very relevant. Be especially careful force
importing any multihost pool, especially before 0.6.5 lands.

Bug#886447: [libc6-dev] Breaks Portal on Linux (steam)

[Antonio Russo]

Package: libc6-dev
Version: 2.26-1
Severity: normal

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

Upgrading to 2.26-1 causes Portal on Linux to segfault right before the main 
menu is shown.

Symptoms look very similar to [1], but for some reason I'm getting a minidump
instead of a regular core, so I cannot open it up in gdb to get a better trace.

Rolling libc back to 2.25-5 resolves the issue.

If someone can help me either convert the minidump to a core, or force a core 
dump
to be produced, I can poke around with gdb.

[1] https://github.com/ValveSoftware/Source-1-Games/issues/1573

Bug#886442: dgit: obtuse info in diff for permissions change

[Ian Jackson]

In my wip tree it now prints this:

dgit: HEAD specifies a different tree to rssh_2.3.4-6.dsc:
dgit:  conf_convert | 0
dgit:  1 file changed, 0 insertions(+), 0 deletions(-)
dgit: Mode change from 644 to 755: conf_convert
dgit: There is a problem with your source tree (see dgit(7) for some hints).
dgit: To see a full diff, run git diff dc66d4bce760602ff12f5894baaf931caa2c01fa 
b0d8df9d891ed99cd925749cdba44e6176e3cbcc
! Push failed, while preparing your push.
! You can retry the push, after fixing the problem, if you like.



-- 
Ian Jackson    These opinions are my own.

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

Bug#886416: libnih: uninstallable, and FTBFS when rebuilt: FAIL test_parse (unexpected line numbering)

[Axel Beckert]

Control: tag -1 + patch

Hi again,

Axel Beckert wrote:
> I don't know if that test suite failure shows that expat broke libnih
> or if the test suite just needs to be adapted to the new expat
> version.
> 
> Iff the later is the case, the following patch fixes the FTBFS:
> 
> --- a/nih-dbus-tool/tests/test_parse.c
> +++ b/nih-dbus-tool/tests/test_parse.c
> @@ -7950,7 +7950,7 @@
>  
> TEST_EQ_P (node, NULL);
>  
> -   TEST_FILE_EQ (output, ("test:foo:2:0: "
> +   TEST_FILE_EQ (output, ("test:foo:1:36: "
>"Invalid object path in  name 
> attribute\n"));
> TEST_FILE_END (output);
> TEST_FILE_RESET (output);
> 
> Haven't yet tried if the resulting packages still work, but will try
> that now.

So far no issues and nih-dbus-tool still generates a lot of C code.

The patch fixes the FTBFS with both, glibc 2.25 as well as glibc 2.26.

I've now pushed the above patch with some proper metadata to the newly
created git branch "adapt-testsuite-to-expat-2.2.5":

https://anonscm.debian.org/cgit/collab-maint/libnih.git/log/?h=adapt-testsuite-to-expat-2.2.5

I'd appreciate some more eyes on that change as I have not much of an
idea of libnih's guts.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#886440: linux: Support to build linux-libc-dev for the upcoming riscv64 architecture

[Manuel A. Fernandez Montecelo]

2018-01-06 01:09 Manuel A. Fernandez Montecelo:

Source: linux
Version: 4.15~rc5-1~exp1
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

The 4.15 kernel comes with initial support for RISC-V.

Enabling support to build linux-libc-dev is one of the first steps to bootstrap
the architecture, so please consider enabling it.

If there's anything wrong or missing, please let me know.


I was missing debian/config/defines, attached now.

--
Manuel A. Fernandez Montecelo 

--- defines	2017-12-22 04:54:44.0 +0100
+++ defines.riscv64	2018-01-06 02:53:49.627832251 +0100
@@ -91,6 +91,7 @@
  powerpcspe
  ppc64
  ppc64el
+ riscv64
  s390
  s390x
  sh3

Bug#886416: libnih: uninstallable, and FTBFS when rebuilt: FAIL test_parse (unexpected line numbering)

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> BAD: wrong content in file 0x5653145373a0 (output), expected 'test:foo:2:0: 
> Invalid object path in  name attribute
> ' got 'test:foo:1:36: Invalid object path in  name attribute
> '
> at tests/test_parse.c:7954 (test_parse_xml).
> FAIL test_parse (exit status: 134)

I don't know if that test suite failure shows that expat broke libnih
or if the test suite just needs to be adapted to the new expat
version.

Iff the later is the case, the following patch fixes the FTBFS:

--- a/nih-dbus-tool/tests/test_parse.c
+++ b/nih-dbus-tool/tests/test_parse.c
@@ -7950,7 +7950,7 @@
 
TEST_EQ_P (node, NULL);
 
-   TEST_FILE_EQ (output, ("test:foo:2:0: "
+   TEST_FILE_EQ (output, ("test:foo:1:36: "
   "Invalid object path in  name 
attribute\n"));
TEST_FILE_END (output);
TEST_FILE_RESET (output);

Haven't yet tried if the resulting packages still work, but will try
that now.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#886446: RFS: btrfsmaintenance/0.3.1-17-gf7d61e3-1~exp1 [I maintain the package]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

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

Marc, I CCed you because you sponsored the last upload.  Would you
please consider sponsoring this one too?

Package name: btrfsmaintenance
Version : 0.3.1-17-gf7d61e3-1~exp1
Upstream Author : David Sterba 
URL : https://github.com/kdave/btrfsmaintenance
License : GPL-2
Section : admin

It builds this binary package:

btrfsmaintenance - automate btrfs maintenance tasks on mountpoints or 
directories

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/b/btrfsmaintenance/btrfsmaintenance_0.3.1-17-gf7d61e3-1~exp1.dsc

Finally, one can get checkout the git repository with these commands:

git clone ssh://git.debian.org/git/collab-maint/btrfsmaintenance.git
git checkout experimental

Changes since the last upload:

btrfsmaintenance (0.3.1-17-gf7d61e3-1~exp1) experimental; urgency=medium

  * Add postrm script to clean up broken symlinks.
  * Fix Vcs-Git URL.
  * Install new systemd services and timers.
  * Uncapitalise short description.
  * Condense long description.
  * Declare Standards-Version: 4.1.3. (No additional changes needed)

 -- Nicholas D Steeves   Fri, 05 Jan 2018 18:55:21 -0500

btrfsmaintenance (0.3.1-1~exp1) experimental; urgency=medium


Regards,
Nicholas D Steeves

Bug#886416: libnih: uninstallable, and FTBFS when rebuilt: FAIL test_parse (unexpected line numbering)

[Axel Beckert]

Control: retitle -1 libnih: FTBFS with expat 2.2.5: "FAIL test_parse 
(unexpected line numbering)" and is now uninstallable due now failing BinNMU

Hi,

Simon McVittie wrote:
> > Testing parse_xml()
> > ...
> > BAD: wrong content in file 0x13be5e730 (output), expected 'test:foo:2:0: 
> > Invalid object path in  name attribute
> > ' got 'test:foo:1:36: Invalid object path in  name attribute
> > '
> >  at tests/test_parse.c:7954 (test_parse_xml).
> > FAIL test_parse (exit status: 134)
> 
> I don't know whether the test failure is triggered by glibc 2.26, or by
> something else that changed since November.

It doesn't seem to be caused glibc 2.26, because if I try to compile
libnih on Sid without having glibc updated from 2.25 to 2.26 yet (due
to libnih), it still FTBFS in the same way:

BAD: wrong content in file 0x5653145373a0 (output), expected 'test:foo:2:0: 
Invalid object path in  name attribute
' got 'test:foo:1:36: Invalid object path in  name attribute
'
at tests/test_parse.c:7954 (test_parse_xml).
FAIL test_parse (exit status: 134)

The reproducible build saw its first FTBFS on 2017-12-23 (sid) and
2017-12-30 (buster), and the last successful build on 2017-12-14 (sid)
2017-12-25 (buster):

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

Looking at libnih's build dependencies, the expat upstream version
bump on 2017-12-16 in Sid and on 2017-12-25 in buster fits quite well.

Another hint towards expat is the fact that the failing test involves
XML parsing.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#857090: command-not-found still doesn't do anything.

[shirish शिरीष]

Hi all,

I have used command-not-found in the past and it used to be good.

I just installed it , ran an apt update and tried to run a command
which I knew whose binary isn't installed but command-not-found didn't
work.

I am using zsh though if it makes any difference.

% apt-cache policy command-not-found
command-not-found:
  Installed: 0.2.38-4
  Candidate: 0.2.38-4
  Version table:
 *** 0.2.38-4 900
900 http://httpredir.debian.org/debian buster/main amd64 Packages
  1 http://httpredir.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

% sudo apt update
[sudo] password for shirish:
Hit:1 http://cdn-fastly.deb.debian.org/debian buster InRelease
Hit:2 http://cdn-fastly.deb.debian.org/debian unstable InRelease
Hit:3 http://cdn-fastly.deb.debian.org/debian experimental InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.

 % cmake
zsh: command not found: cmake

As I understand or remember it from before, it should have told that I
needed to install cmake binary/package to run the command

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

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

Versions of packages command-not-found depends on:
ii  apt-file 3.1.5
ii  lsb-release  9.20170808
ii  python   2.7.14-4
ii  python-gdbm  2.7.14-1

command-not-found recommends no packages.

command-not-found suggests no packages.

-- no debconf information

Hope it helps in diagnozing the situation, please let me know if any
more info. is needed.

-- 
  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#886382: Coming updates for meltdown/spectre

[Louis-Philippe Véronneau]

> No, we don't know if they will release it *only* to vendors for a
> firmware update, or also for operating system updates.  Also, for Zen
> and later one cannot just hope to update microcode through the operating
> system, often it requires such an early update that it has to be done by
> the firmware itself.

https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html

It seems AMD just released a microcode update to disable branch
prediction on its Zen architecture.

-- 
pollo



signature.asc
Description: OpenPGP digital signature

Bug#886445: needrestart: detect need to reboot due to Intel microcode updates

[Paul Wise]

Package: needrestart
Version: 2.11-4
Severity: wishlist

Please detect the need to reboot to apply Intel microcode updates.

When iucode_tool is installed, please check if /boot/initrd.img*
contain the same microcode rev for the current CPU signature as the
Linux kernel is listing in /proc/cpuinfo as the microcode version.

First, get the processor signature (also available in next step):

$ /usr/sbin/iucode_tool -Sv
/usr/sbin/iucode_tool: system has processor(s) with signature 0x00020655

Second, match the processor signature against the 'sig' field of the
selected microcodes in all the initrds and extract the 'rev' field of
that microcode.

$ /usr/sbin/iucode_tool -tr -Sl /boot/initrd.img-4.14.0-2-amd64
/usr/sbin/iucode_tool: system has processor(s) with signature 0x00020655
microcode bundle 1: /boot/initrd.img-4.14.0-2-amd64
selected microcodes:
  001/001: sig 0x00020652, pf_mask 0x12, 2015-06-30, rev 0x000f, size 8192
  001/002: sig 0x00020655, pf_mask 0x92, 2015-06-30, rev 0x0005, size 3072

Third, match the extracted rev field against the microcode field in the
 Linux /proc/cpuinfo file.

$ grep micro /proc/cpuinfo 
microcode   : 0x5
microcode   : 0x5
microcode   : 0x5
microcode   : 0x5

When running as root, the microcode versions are also in /sys:

$ head /sys/devices/system/cpu/*/microcode/version
head: cannot open '/sys/devices/system/cpu/cpu0/microcode/version' for reading: 
Permission denied
head: cannot open '/sys/devices/system/cpu/cpu1/microcode/version' for reading: 
Permission denied
head: cannot open '/sys/devices/system/cpu/cpu2/microcode/version' for reading: 
Permission denied
head: cannot open '/sys/devices/system/cpu/cpu3/microcode/version' for reading: 
Permission denied

$ sudo head /sys/devices/system/cpu/*/microcode/version
==> /sys/devices/system/cpu/cpu0/microcode/version <==
0x5

==> /sys/devices/system/cpu/cpu1/microcode/version <==
0x5

==> /sys/devices/system/cpu/cpu2/microcode/version <==
0x5

==> /sys/devices/system/cpu/cpu3/microcode/version <==
0x5

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#884646: marked as done (No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages)

[Ian Jackson]

# Thanks for your diligence in closing this bug, however:

reopen 884646

clone 884646 -1
retitle -1 obtuse info in diff for permissions change:
#
# dgit push printed this
# dgit: HEAD specifies a different tree to rssh_2.3.4-6.dsc:
# dgit:  conf_convert | 0
# dgit:  1 file changed, 0 insertions(+), 0 deletions(-)
#   which is a terribly obtuse way of reporting a permission
#   difference.

clone 884646 -2
retitle -2 wrong message about diff in split brain mode
#
# * dgit push printed this
# dgit:   ... To see a full diff, run
# dgit:   git diff dc66d4bce760602ff12f5894baaf931caa2c01fa HEAD
#but that is completely wrong and produces a bunch of irrelevant
#stuff.
#
#   I think the bug is that the message says HEAD but of course the
#   relevant diff is between the .dsc and the dgit view, not between the
#   .dsc and HEAD, in split brain mode.  If I do this
#  git diff dc66d4bce760602ff12f5894baaf931caa2c01fa 
4dcfadb60855855fa909fb1544c22af63084b4c0
#   I get only the expected mention of the mode of conf_convert.
#   (that hash came from "dgit view: found cached (commit id...)")

clone 884646 -3
retitle -3 dgit(7) should say something about permissions problems
#
# * dgit push printed this
# see dgit(7) for some hints
#   but dgit(7) mentions nothing about this kind of problem.

retitle 884646 wrong message about perhaps tree changed
#
# I discover from UTSL that dgit's quilt cache is keyed off not the tree
# object corresponding to git HEAD, but the HEAD commit id.  (This is
# necessary because the dgit view is a branchlet built on HEAD.)
# 
# But that does mean the message is misleading.  It ought to say:
# 
#dgit:  perhaps HEAD changed since dgit build[-source] ?
# 
# (And I think, here, that we do mean HEAD and not something else.)

thanks

Bug#886436: Rscript doesn't appear in package descriptions

[Charles Plessy]

Le Fri, Jan 05, 2018 at 11:42:04PM +0100, Juliusz Chroboczek a écrit :
> 
> A student just sent me a script that used the Rscript command.  Since I'm
> not an R programmer, I thought, no problem,
> 
>   apt-cache search Rscript
> 
> which gave me nothing useful.

Hello Juliusz,

in Debian, the best way to find a packaged file is to use the "apt-file"
tool (from the package of the same name).

$ apt-file search bin/Rscript   
 
r-base-core: /usr/bin/Rscript
r-base-core: /usr/lib/R/bin/Rscript
r-base-core-dbg: /usr/lib/debug/usr/bin/Rscript
r-base-core-dbg: /usr/lib/debug/usr/lib/R/bin/Rscript

Alternatively the packages.debian.org website can also be queried:

https://packages.debian.org/search?suite=default=all=any=contents=bin%2FRscript

Have a nice weekend,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#880658: dgit server rejects unattributed commits

[Ian Jackson]

Control: tags -1 found 2.15
Control: tags -1 notfound 3.13
Control: tags -1 fixed 3.11

Bizarrely, this bug is only still in production because the
dgit-repos-server is running dgit 2.15.

It's quite late in the day here so now is not a good time to mess with
it.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#886400: python3-pyqt5.qtwebengine: segfaults on simple test

[David Bremner]

Dmitry Shachnev  writes:

> Hi David!
>
> On Fri, Jan 05, 2018 at 07:39:59AM -0400, David Bremner wrote:
>> I encountered this when trying to run webmacs (a browser written in
>> python) on Debian.
>>
>> The attached script segfaults, seemingly on any URL. Feel free to
>> adjust the severity up or down; I'm guessing the package works for
>> some people / applications, but this seems like pretty core
>> functionality to be broken.
>
> I cannot reproduce this (tested with e.g. https://www.debian.org).
>
> Can you please attach some stacktrace?
>

Sure, here is a stracktrace from

 /usr/bin/python3 testbrowser_webengine.py url=https://www.debian.org
 
If you let me know which debug symbol packages to install, I'm happy to
try again with more symbols.

#0  0x in  ()
#1  0x71333826 in QOpenGLContext::makeCurrent(QSurface*) () at 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#2  0x7fffe733f6c7 in  () at 
/usr/lib/x86_64-linux-gnu/libQt5QuickWidgets.so.5
#3  0x7fffe734199e in QQuickWidget::resizeEvent(QResizeEvent*) ()
at /usr/lib/x86_64-linux-gnu/libQt5QuickWidgets.so.5
#4  0x7fffee6bfedd in  () at 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5
#5  0x71af2742 in QWidget::event(QEvent*) () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#6  0x7fffee6c01fb in  () at 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5
#7  0x71ab359c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
()
at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x71abae64 in QApplication::notify(QObject*, QEvent*) ()
at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x7254f97e in  () at 
/usr/lib/python3/dist-packages/PyQt5/QtWidgets.cpython-36m-x86_64-linux-gnu.so
#10 0x76042258 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
()
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x71aeac4b in QWidgetPrivate::sendPendingMoveAndResizeEvents(bool, 
bool) ()
at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x71aeea23 in QWidgetPrivate::show_helper() () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x71aee93e in QWidgetPrivate::showChildren(bool) () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x71aeea3f in QWidgetPrivate::show_helper() () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x71af173b in QWidget::setVisible(bool) () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x7fffee8e7183 in  ()
at 
/usr/lib/python3/dist-packages/PyQt5/QtWebEngineWidgets.cpython-36m-x86_64-linux-gnu.so
#17 0x72523512 in  () at 
/usr/lib/python3/dist-packages/PyQt5/QtWidgets.cpython-36m-x86_64-linux-gnu.so
#18 0x004c4dfd in _PyCFunction_FastCallKeywords ()
#19 0x0054f974 in  ()
#20 0x0055405f in _PyEval_EvalFrameDefault ()
#21 0x0054f571 in  ()
#22 0x00550523 in PyEval_EvalCode ()
#23 0x0042b4e9 in PyRun_FileExFlags ()
#24 0x0042b6d5 in PyRun_SimpleFileExFlags ()
#25 0x00441bcb in Py_Main ()
#26 0x00421f64 in main ()

Bug#826868: btrfs-progs: Please provide sample cron.montly btrfs-scrub job

[Nicholas D Steeves]

Hi Roman, Christoph, and Dmitri,

I've decided to package btrfsmaintenance-0.3.1-17-gf7d61e3~exp1 to
make the new systemd units and timers available for testing as early
as possible.  At the moment I'm waiting for someone to grant DM
permissions to E2A6261E3900AED7CDC667085A8830475F7D1061 for the
btrfsmaintenance; however, if one of you would prefer to review the
package and sponsor the upload please let me know and I'll file an RFS
and mark you as the owner without delay.

Happy new year!
Nicholas


signature.asc
Description: PGP signature

Bug#886441: DKIMproxy does not respect key location

[Martin Hanson]

Package: dkimproxy   
Version: 1.4.1-3
Debian Stretch

In /etc/dkimproxy/dkimproxy_out.conf

# specify location of the private key
keyfile   /etc/mail/dkim/private.key

Yet, dkimproxy looks for the key in: /var/lib/dkimproxy/private.key

>From the log:

dkimproxy.out[1166]: signing error: Error: cannot read 
/var/lib/dkimproxy/private.key: Permission denied

I then copied the key from /etc/mail/dkim to /var/lib/dkimproxy and changed the 
permissions and DKIMproxy signs the key.

No matter what I do the "keyfile" option is ignored.

Kind regards

Bug#871908: dgit fails to work when .git is a reference not a directory

[Ian Jackson]

Control: tag -1 fixed 4.1

Sam Hartman writes ("Bug#871908: dgit fails to work  when .git is a reference 
not a directory"):
> I tested with  dgit 4.1 and it worked well enough to dgit build-source.
> I did not check through a full push mostly because I don't have any
> packages to push ATM.
> However if it works that well, I think it is conclusive.

Thanks.  This will be going to unstable soonish.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#886283: tracker.debian.org: please do NOT yell

[Holger Levsen]

On Thu, Jan 04, 2018 at 05:19:26PM +0100, Mattia Rizzolo wrote:
> On Thu, Jan 04, 2018 at 04:01:18PM +, Holger Levsen wrote:
> > > Personally, in this case I would say you need to change two things:
> > > 1) edit the remote repository configuration so HEAD points to the debian
> > >branch

done this now.

> > > 2) change Vcs-Git of the version in experimental by adding '-b 
> > > debian-experimental'

done this in git now, not yet uploaded…

> > hm. how "personally" is that? will my simple suggestion also by
> > sufficient? why do you suggest what you suggest?
> Your suggestion is definitly enough for all automated tools (and for
> users using debcheckout).

Thanks for confirming.

> > > (but it should be pointing to 'debian', really).
> > why oh why?
> 
> Because that way people running
> git clone alioth:/git/collab-maint/munin.git
> like me (I'm even more evil, I'd do `git clone cm:munin`) will then get
> the packaging branch without further specifying flags for branches and
> stuff.
 
ah! & thanks, this made me point HEAD to debian! :)

> Quoting from the Policy about Vcs-*:
> | The field’s value uses the version control system’s conventional
> | syntax for describing repository locations and should be sufficient to
> | locate the repository used for packaging. Ideally, it also locates
> | the branch used for development of new versions of the Debian package.
> That means that the Vcs-* fields should ideally point to the packaging
> branch.  

also thanks for pointing this out.

> I like to take this one step further, as really what's in
> alioth is all about debian packaging, the default branches IMHO should
> be a packaging branch.


agreed.

> > to me its very simple: if there is a debian branch, this is the branch
> > for debian packaging. if there isnt, the debian stuff is probably in the
> > master branch…
> 
> Right, probably everybody if what they look for is not in the default
> branch, they have a look around at the available branches and can
> easily figure it out.  But really there ought to be no guesswork
> involved at all...

I like automated guesswork… not human guesswork.

> But yes, specifying -b in Vcs-Git is really all that's expected (and it
> will definitly make vcswatch happied :))

hm, so I will do this now in addition to having made HEAD point to
debian.

And then I'll wait two more days til 2.0.34-2 is in Buster and then
upload -3 to see if everything is working as it shall :)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#886440: linux: Support to build linux-libc-dev for the upcoming riscv64 architecture

[Manuel A. Fernandez Montecelo]

Source: linux
Version: 4.15~rc5-1~exp1
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

The 4.15 kernel comes with initial support for RISC-V.

Enabling support to build linux-libc-dev is one of the first steps to bootstrap
the architecture, so please consider enabling it.

If there's anything wrong or missing, please let me know.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -urN linux-4.15~rc5/debian/config/riscv64/defines 
linux-4.15~rc5+riscv64/debian/config/riscv64/defines
--- linux-4.15~rc5/debian/config/riscv64/defines1970-01-01 
01:00:00.0 +0100
+++ linux-4.15~rc5+riscv64/debian/config/riscv64/defines2018-01-06 
01:05:36.901367955 +0100
@@ -0,0 +1,4 @@
+[base]
+kernel-arch: riscv
+featuresets:
+# empty; just building headers yet

Bug#886439: byzanz-record should print messages on begin and end

[Jörg Sommer]

Package: byzanz
Version: 0.3.0+git20160312-2
Severity: wishlist

Hi,

it would be helpful if byzanz could print a message when the recording
begins and ends, because it's not always recogniseable what's happening,
esp. when the begin is delayed.

A proposal:

% byzanz-record --delay 4 -d 6
Starting recording in 4 seconds
Recording started
Recording stopped

Bye Jörg

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

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

Versions of packages byzanz depends on:
ii  gstreamer1.0-libav  1.12.4-1
ii  gstreamer1.0-plugins-base   1.12.4-1
ii  gstreamer1.0-plugins-good   1.12.4-1
ii  libc6   2.26-1
ii  libcairo2   1.15.8-3
ii  libglib2.0-02.54.2-5
ii  libgstreamer-plugins-base1.0-0  1.12.4-1
ii  libgstreamer1.0-0   1.12.4-1
ii  libgtk-3-0  3.22.26-2
ii  libxdamage1 1:1.1.4-3
ii  libxfixes3  1:5.0.3-1

byzanz recommends no packages.

byzanz suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#886436: Rscript doesn't appear in package descriptions

[Dirk Eddelbuettel]

On 5 January 2018 at 23:42, Juliusz Chroboczek wrote:
| Package: r-base-core
| Version: 3.4.3-1
| Severity: wishlist
| 
| A student just sent me a script that used the Rscript command.  Since I'm
| not an R programmer, I thought, no problem,
| 
|   apt-cache search Rscript
| 
| which gave me nothing useful.
| 
| Perhaps it would be useful to mention Rscript in the description of the
| r-base-core package?

Hm. Not sure.

R Core itself doesn;t push Rscript all that hard.  In any event, we have
'littler' and r-cran-littler and littler -- it is "better" (but not available
on Windows) so maybe just use that?

http://dirk.eddelbuettel.com/code/littler.html
https://cloud.r-project.org/web/packages/littler/index.html

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#860752: libnftnl: Please honour DEB_BUILD_OPTIONS=nocheck

[Manuel A. Fernandez Montecelo]

Control: fixed -1 1.0.7-2


Hi,

2017-04-20 11:11 Manuel A. Fernandez Montecelo:

Hi,

2017-04-20 10:58 GMT+02:00 Arturo Borrero Gonzalez :

On 19 April 2017 at 20:24, Manuel A. Fernandez Montecelo
 wrote:

Source: libnftnl
Version: Please honour DEB_BUILD_OPTIONS=nocheck
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

The workaround for the tests overriding dh_auto_test in debian/rules means that
DEB_BUILD_OPTIONS=nocheck is not honoured.

It would be great if you could fix this, either not overriding dh_auto_test (if
the issue is fixed now) or by surrounding the check with something like the
attached patch.


Thanks for the patch.

If you don't mind, I would wait for the stretch stable release to
happen before applying it.


Yes, it's fine, I expected that :-)


Fixed by applying another patch doing basically the same, so marking
this one as closed:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872326


Thanks.

--
Manuel A. Fernandez Montecelo 

Bug#886036: Improve changelog version parsing

[Felix Lechner]

Hi Chris!

Here are two preliminary bug fixes:

* 0001 Addresses an issue when the version contains two hyphens; now
the string is split properly into two parts.
* 0002 Removes an old exception allowing -0.X on native source NMUs,
which now triggers the appropriate warning.

The patches were rebased for today's master. They are perl-tidy and
run on all tests.

Please don't close the bug just yet. Thank you!

Best regards,
Felix



On Tue, Jan 2, 2018 at 8:33 AM, Chris Lamb  wrote:
> Hi Felix!
>
>> Please have a look at https://github.com/lechner/lintian
>
> Woah, looks great! Thank you. Before I merge, can you just…
>
>   a) Add some tests for the debian-changelog-version-malformed
>  tag.
>
>   b) Add a changelog entry that closes this bug (#886036)
>
> Many thanks again...
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-


0001-c-changelog-file-Fix-version-parsing-for-hyphen-in-u.patch.xz
Description: application/xz


0002-c-cruft-Fix-version-parsing-for-native-packages.patch.xz
Description: application/xz

Bug#494372: Need more information about potential tc-prio(8) bug

[Luca Boccassi]

Control: tags -1 -moreinfo
Control: close -1

On Sun, 31 Dec 2017 12:19:49 +0100 Harald Geyer 
wrote:
> Hi Andreas Henriksson!
> 
> Appologies for never following up on this bug. I solved my problem
back
> then the trial-and-error way and never had to use tc again, so never
> invested time into this.
> 
> However reading the man page again, it actually makes sense now. What
> cleared thing up for me was the following sentence:
> "The priomap also allows you to list higher priorities (> 7) which do
not
> correspond to TOS mappings, but which are set by other means."
> 
> Now I see: The priomap maps from "Linux Priority" to Band not from
TOS Bits.
> I guess what confused me was that the priomap has 16 entries which
also
> is the number of possible TOS values.
> 
> So actually there is no bug in the man page. Since we both had a hard
> time understanding it, maybe it should be improved. Or maybe is has
already
> been improved over the past 10 years - after all it looks
sufficiently clear
> to me now.
> 
> I think, unless you have an idea how to explain things more naturally
or
> unambiguous, this report can be closed.
> 
> Thanks,
> Harald

Hi,

I too think that it is now sufficiently clear, so I'll close this now.

-- 
Kind regards,
Luca Boccassi

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

Bug#886438: RFS: gnumail/1.2.3-1 [RC]

[Yavor Doganov]

Package: sponsorship-requests
Severity: important

Dear mentors,

I' looking for a sponsor for my package "gnumail".

 * Package name: gnumail
   Version : 1.2.3-1
   Upstream Author : Ludovic Marcotte  and others
 * URL : http://www.nongnu.org/gnustep-nonfsf/gnumail/
 * License : GPL-2+
   Section : gnustep

It builds these binary packages:

 gnumail.app - Mail client for GNUstep
 gnumail.app-common - Mail client for GNUstep (common files)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnumail/gnumail_1.2.3-1.dsc

Or clone the pkg-gnustep repository:

  gbp clone https://anonscm.debian.org/git/pkg-gnustep/gnumail.git

Changes since the last upload:

  * New upstream release.
  * Set urgency to "high" due to the nature of the bug it fixes.
  * debian/watch: Switch to Savannah.
  * debian/gnumail.app-common.install:
  * debian/gnumail.app.links: Don't install the Face bundle; removed
upstream due to unclear licensing.
  * debian/gnumail.app.install: Don't install a dangling symlink to the
non-existing Headers directory and the .xpm icon.
  * debian/rules: Strip trailing whitespace.
(DEB_LDFLAGS_MAINT_APPEND): Define to the previous value and pass
dpkg-buildflags explicitly to restore hardening and strip the libssl
dependency (Closes: #886305).  Pass $(optim), restoring lost support
for noopt in DEB_BUILD_OPTIONS.
(override_dh_auto_install): Pass GNUSTEP_SYSTEM_LIBRARIES to install
the framework in /usr/lib/gworkspace.app as per Policy §10.2.  Delete
dangling Headers symlink.
(override_dh_auto_clean): Remove; completely unnecessary.
(override_dh_link): Remove override and just delete the invalid
.desktop file in the override_dh_auto_install recipe.
(override_dh_makeshlibs): New override; pass --noscripts.
  * debian/compat: Bump compat level to 11.
  * debian/control (Homepage): Switch to the new one at nongnu.org.
(Build-Depends): Require debhelper >= 11.  Remove obsolete
libgnustep-gui-dev version requirement.  Add gnustep-make (>= 2.7.0-3)
for the optim variable definition.
(Breaks, Replaces): Remove; obsolete.
(Standards-Version): Claim compliance with 4.1.3.
  * debian/GNUMail.xpm: Delete as the menu file is gone.
  * debian/patches/spelling-fixes.patch: Refresh.
  * debian/patches/link-libs.patch: Refresh and remove -lssl from the
toplevel makefile, just in case.
  * debian/changelog: Delete trailing whitespace.
  * debian/copyright: Update Source location and copyright years; add more
copyright holders and missing licenses (LGPL-2+ for the StepTalk
support and LPGL-2.1+ for some icons).

Bug#886437: qt5core packaging breaks qDebug

[David Faure]

Package: libqt5core5a
Version: 5.9.0~beta+dfsg-1
Severity: important

As a fix for bug 805399, the file /etc/xdg/QtProject/qtlogging.ini was added to 
disable debug output from Qt (using *.debug = false).

This fix breaks the developer experience, because it makes qDebug() do nothing 
when working on a Qt application.

The way it's supposed to work is that KDE apps and libs are supposed to be 
using categorized logging (qCDebug, qCWarning etc.), with severity "debug" 
being disabled by default.
This way, the default category, the one used by qDebug(), should keep working.

Bug 805399 shows for instance this line:
org.kde.kded5[4940]: org.kde.kurifilter-shorturi: path = "xterm"  
isLocalFullPath= false  exists= false  url= QUrl("xterm")

This comes from KIO (which I maintain). Investigation shows this one has been 
fixed : since KDE Frameworks 5.23, the logging category is defined as
QLoggingCategory category("org.kde.kurifilter-shorturi", QtWarningMsg);
which means warnings (and above) are enabled by default, but debug is disabled 
by default.

The debug messages from kioremote don't exist anymore since commit 2a3b74df
in plasma-workspace (the code has now moved to kio).

So, overall, I think the underlying issue is fixed, we're trying to be better 
citizens by using qCDebug and by disabling debug output for all specific 
categories (since Qt 5.4 which supports it).

Conclusion: please remove /etc/xdg/QtProject/qtlogging.ini again.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Bug#886224: printer-driver-cups-pdf: Virtual pdf printer error: no output and config problem

[Brian Potkin]

severity 886224 normal
thanks


On Wed 03 Jan 2018 at 17:18:25 +0100, Rudolf Polzer wrote:

> You are right - the cups pdf printer is now working.
> 
> I changed the pdf output directory a long time ago before using
> Apparmor, but now Apparmor needs to allow rw access to this directory.
> 
> So I updated /etc/apparmor.d/usr.sbin.cupsd
> and the pdf printing works.

With what did you update it?

> The config problem remains unsolved.

Can you reproduce this problem?

-- 
Brian.

Bug#886417: linux-source-4.9: Kernel sources do not compile

[Salvatore Bonaccorso]

Hi,

On Fri, Jan 05, 2018 at 09:19:30PM +0100, David Reviejo wrote:
> Hi,
> 
> I have the same error with a very old machine, a Pentium-M one, (and so
> no SMP...) trying to compile the source from 4.9.65-3+deb9u2 with a
> custom config.
> 
> The problem is: the "load_new_mm_cr3" function in arch/x86/mm/tlb.c is
> compiled only when SMP config is defined, but is used in code compiled
> for no SMP machines (line 160); because of this the
> "implicit-function-declaration" error.
> 
> Trying your sugestion, upstream 4.9.75 compile without problems: the
> tlb.c there has no SMP special code (the header says something about:
> "formerly SMP-only"...).

There is indeed
https://git.kernel.org/linus/ce4a4e565f5264909a18c733b864c3f74467f69e
backported as 3e5daacf65173987436bad6ab9039a05f9545cdd in v4.9.74
which AFAICS did remove the surrounding directives.

Regards,
Salvatore

Bug#875116: [pyqwt3d] Future Qt4 removal from Buster

[Gudjon I. Gudjonsson]

Hi

qwtplot3d has recently been uploaded with only Qt5 support.

I will remove Qt4 support from pyqwt3d ASAP. Please don't let it
be in the way of any other upgrade.

Regards
Gudjon

Bug#787300: [pyqwt5] Future Qt4 removal from Buster

[Gudjon I. Gudjonsson]

Hi

This package will be replaced soon by PyQt-Qwt:
https://github.com/GauiStori/PyQt-Qwt

which works for Qwt verion 6 for Qt5.

Please remove it from Debian.

Regards
Gudjon

Bug#875166: [qwt5] Future Qt4 removal from Buster

[Gudjon I. Gudjonsson]

Hi

Qwt5 has been replaced by Qwt. It has just been packaged in Debian to provide 
PyQwt5 but
it will be removed from Debian and then Qwt5 can be removed as well.

Qwt5 is replaced by Qwt version 6.
https://packages.qa.debian.org/q/qwt.html

PyQwt5 will be replaced by PyQt-Qwt for Qwt version 6 soon.
https://github.com/GauiStori/PyQt-Qwt

I will ask for a removal of qwt5 from Debian unless you are faster.

Regards
Gudjon

Bug#886436: Rscript doesn't appear in package descriptions

[Juliusz Chroboczek]

Package: r-base-core
Version: 3.4.3-1
Severity: wishlist

A student just sent me a script that used the Rscript command.  Since I'm
not an R programmer, I thought, no problem,

  apt-cache search Rscript

which gave me nothing useful.

Perhaps it would be useful to mention Rscript in the description of the
r-base-core package?

Bug#822914: dpkg: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Manuel A. Fernandez Montecelo]

Hi,

2017-05-24 02:09 Guillem Jover:

Hi!

On Tue, 2017-05-23 at 01:44:29 +0200, Manuel A. Fernandez Montecelo wrote:

2016-05-04 2:03 GMT+02:00 Guillem Jover :
> On Fri, 2016-04-29 at 19:26:50 +0100, Manuel A. Fernandez Montecelo wrote:
> > - the support in the toolchain projects has not been merged yet,
> >  althought it's been planned for some time and can start at any moment
> >
> >  I understand if you don't want to enable support yet for this reason,
> >  I can ping the bug when that happens.
>
> Yes, I'd rather wait. I'm marking the bug as moreinfo, please remove
> the tag when the upstreaming is complete.

GCC (present in 7.x) and binutils (2.28 onwards, actually before that
in Debian due to backported patches to 2.27) have been upstreamed,
glibc and Linux (among others) are missing.

Do you still prefer to wait until all bits are upstreamed?  Aurelient
Jarno told me several times that it would be important to be have
support in stable releases, otherwise people like DSA are a bit more
reluctant (or gives them more work) to install from backports or
similar, for the bits of infrastructure which need support.


Yeah I'd like to wait, otherwise there is no guarantee the ABI is
properly defined. Regarding stable, as I think I've mentioned in the
past, adding arches within dpkg stable updates is standard practice
precisely due to the reasons you give. So I'm happy to do that one
the upstreaming is completed.


Can we have this now, and a backport to stretch?

Only glibc is missing, but patches have been already submitted and some
acked, and 2.27 will be released in February in principle... and I
assume that you will need a few days/weeks for that.

Aurelien cannot upload glibc with the arch enabled because dak will
reject it if dpkg doesn't know about it.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#838178: tracker.debian.org: "action needed" details show only with Javascript enabled

[Thomas Schmitt]

Hi,

Pierre-Elliott Bécue wrote:
> I'm sorry that it broke some backward compatibility with older browsers. :/

At least for me as JavaScript allergic it is still an improvement over
the previous situation. Better ugly than obscure.

Of course, for a Jessie Iceweasel user with JavaScript enabled it will be
more of a pain.


Have a nice day :)

Thomas

Bug#568324: awesome : display non updated when moving window from tag

[Reiner Herrmann]

Hi Simon,

On Mon, Oct 30, 2017 at 10:55:57PM +, Simon Chopin wrote:
> I'm not using awesome anymore, but I'll give it a try whenever I get to a
> Linux machine with both root access and a X11 server ;-) (should be
> sometime this week). The good news is that I distinctly remember how to
> trigger the bug with Iceweasel. The bad is that it dates back to when
> Iceweasel still existed.

I just wanted to ask if you meanwhile had an opportunity to check if
this issue still exists?
If it's too much effort, I would suggest to close the bug.

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#874529: And here is an unoffical updated package that fixes it.

[Michael Biebl]

Control: tags -1 + patch fixed-upstream
Control: fixed -1 3.24.1-1

Am 05.01.2018 um 23:13 schrieb hendriksen@gmail.com:
> Using the fix from github, I have created new packages. 
> 
> I have attached the updated packages. 
> 
> I have spent a good two hours trying to find out how to do a proper
> 'pull request' or something similar for Debian. 
> 
> I this works out :) 
> 
> On Thu, 21 Sep 2017 09:59:06 +1200 Eliot Blennerhassett  om> wrote:
>> https://github.com/GNOME/gdm/commit/60447f2016cd873b0a62a5885687d7b3a
> 8538d11#diff-daf9735fd40f92ad94e330eeab3c99a7

Thanks for finding this commit.
Seems 3.24.1 is the first version shipping this patch.
Marking the bug report accordingly.



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



signature.asc
Description: OpenPGP digital signature

Bug#839662: [firmware-atheros] ath10k_pci firmware crashes when ap changes bandwith

[Michael Meier]

Package: firmware-atheros
Version: 20170823-1~bpo9+1

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

The same problem here with firmware-atheros version 20170823-1~bpo9+1 
and kernel 4.14.0-2-amd64.

It's a dell xps 13 8th gen, with a:
3a:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless 
Network Adapter (rev 32)


When that happens I need to deactivate and reactive the wlan, and it 
works again...


[  326.283775] wlan0: AP c0:25:06:b7:87:d9 changed bandwidth, new config 
is 2412 MHz, width 2 (2422/0 MHz)

[  326.338516] ath10k_pci :3a:00.0: firmware crashed! (guid n/a)
[  326.338539] ath10k_pci :3a:00.0: qca6174 hw3.2 target 0x0503 
chip_id 0x00340aff sub 1a56:1535
[  326.338545] ath10k_pci :3a:00.0: kconfig debug 0 debugfs 0 
tracing 0 dfs 0 testmode 0
[  326.339963] ath10k_pci :3a:00.0: firmware ver 
WLAN.RM.4.4-00022-QCARMSWPZ-2 api 6 features wowlan,ignore-otp crc32 
4d458559
[  326.340970] ath10k_pci :3a:00.0: board_file api 2 bmi_id N/A 
crc32 07ee144e
[  326.340980] ath10k_pci :3a:00.0: htt-ver 3.32 wmi-op 4 htt-op 3 
cal otp max-sta 32 raw 0 hwcrypto 1

[  326.342993] ath10k_pci :3a:00.0: firmware register dump:
[  326.343003] ath10k_pci :3a:00.0: [00]: 0x0503 0x15B3 
0x009873D4 0x00955B31


[  326.343010] ath10k_pci :3a:00.0: [04]: 0x009873D4 0x00060730 
0x0004 0x0041FF88


[  326.343016] ath10k_pci :3a:00.0: [08]: 0x004089E0 0x00955A00 
0x000A0B00 0x0040
[  326.343021] ath10k_pci :3a:00.0: [12]: 0x0009 0x 
0x00952CD0 0x00952CE6
[  326.343027] ath10k_pci :3a:00.0: [16]: 0x00952CC4 0x00998131 
0x 0x0091080D
[  326.343032] ath10k_pci :3a:00.0: [20]: 0x409873D4 0x0040E7A8 
0x 0x0041EA7C
[  326.343037] ath10k_pci :3a:00.0: [24]: 0x809AB233 0x0040E808 
0x0040E8C0 0xC09873D4
[  326.343042] ath10k_pci :3a:00.0: [28]: 0x809A5AF4 0x0040E948 
0x0041FA80 0x0043418C
[  326.343047] ath10k_pci :3a:00.0: [32]: 0x809A526B 0x0040E988 
0x0040E9AC 0x0042CD84
[  326.343056] ath10k_pci :3a:00.0: [36]: 0x8091D252 0x0040E9A8 
0x0002 0x0001
[  326.343061] ath10k_pci :3a:00.0: [40]: 0x809FA4D1 0x0040EA58 
0x0043D11C 0x0042D130
[  326.343066] ath10k_pci :3a:00.0: [44]: 0x809F5BAB 0x0040EA78 
0x0043D11C 0x0001
[  326.343072] ath10k_pci :3a:00.0: [48]: 0x80911210 0x0040EAC8 
0x0010 0x004041D0
[  326.343077] ath10k_pci :3a:00.0: [52]: 0x80911154 0x0040EB28 
0x0040 0x
[  326.343082] ath10k_pci :3a:00.0: [56]: 0x8091122D 0x0040EB48 
0x 0x00400600

[  326.343087] ath10k_pci :3a:00.0: Copy Engine register dump:
[  326.343100] ath10k_pci :3a:00.0: [00]: 0x00034400   0   0   3   3
[  326.343113] ath10k_pci :3a:00.0: [01]: 0x00034800   8   8 117 118
[  326.343126] ath10k_pci :3a:00.0: [02]: 0x00034c00  25  25  24  25
[  326.343139] ath10k_pci :3a:00.0: [03]: 0x00035000   1   1   2   1
[  326.343151] ath10k_pci :3a:00.0: [04]: 0x00035400 6573 6573  24 216
[  326.343164] ath10k_pci :3a:00.0: [05]: 0x00035800   0   0  64   0
[  326.343178] ath10k_pci :3a:00.0: [06]: 0x00035c00  11  11  20  20
[  326.343192] ath10k_pci :3a:00.0: [07]: 0x00036000   1   1   1   1
[  326.442208] ieee80211 phy0: Hardware restart was requested
[  327.153570] ath10k_pci :3a:00.0: Unknown eventid: 90118
[  327.258250] ath10k_pci :3a:00.0: device successfully recovered
[  393.690488] wlan0: deauthenticating from c0:25:06:b7:87:d9 by local 
choice (Reason: 3=DEAUTH_LEAVING)

[  396.666205] ath10k_pci :3a:00.0: Unknown eventid: 90118




--- System information. ---
Architecture: Kernel:   Linux 4.14.0-2-amd64

Debian Release: 9.3
  900 stretch packagecloud.io   900 stable security.debian.org 
 900 stable  ftp.ch.debian.org   800 stretch-backports 
ftp.ch.debian.org   700 testing ftp.ch.debian.org   600 unstable 
ftp.ch.debian.org   500 stable-updates  ftp.ch.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Suggests (Version) | Installed
==-+-===
initramfs-tools| 0.130

Bug#886435: python-pygit2 FTBFS on big endian: FAIL: test_no_context_lines (test.test_patch.PatchTest)

[Adrian Bunk]

Source: python-pygit2
Version: 0.26.3-1
Severity: serious

https://buildd.debian.org/status/package.php?p=python-pygit2=sid

...
FAIL: test_no_context_lines (test.test_patch.PatchTest)
--
Traceback (most recent call last):
  File "/<>/test/test_patch.py", line 196, in test_no_context_lines
self.assertEqual(context_count, 0)
AssertionError: 1 != 0

--
Ran 339 tests in 2.760s

FAILED (failures=1, skipped=10)
E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1: 
python2.7 setup.py test 
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
debian/rules:8: recipe for target 'build-arch' failed
make: *** [build-arch] Error 25

Bug#886434: libcitadel FTBFS with "dpkg-buildpackage -B"

[Adrian Bunk]

Source: libcitadel
Version: 917-1
Severity: serious

https://buildd.debian.org/status/package.php?p=libcitadel=sid

...
 fakeroot debian/rules binary-arch
make: Nothing to be done for 'binary-arch'.
 dpkg-genbuildinfo --build=any
dpkg-genbuildinfo: error: binary build with no binary artifacts found; 
.buildinfo is meaningless
dpkg-buildpackage: error: dpkg-genbuildinfo --build=any subprocess returned 
exit status 25


This is caused by the following 916-1 -> 917-1 change in debian/rules:

-binary-arch: build install debian/libcitadel4.install 
debian/libcitadel-dev.install
+binary: build install debian/libcitadel4.install debian/libcitadel-dev.install

Bug#886433: org-mode-doc: Incomplete debian/copyright?

[Chris Lamb]

Source: org-mode-doc
Version: 9.1.6-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Sebastien Delafond 

Hi,

I just ACCEPTed org-mode-doc from NEW but noticed it was missing 
attribution in debian/copyright for at least the files under the
testing/lisp dir.

(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)

Thanks! :)


Regards,

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

Bug#886396: byzanz-record doesn't honor -w

[Markus Koschany]

Am 05.01.2018 um 12:00 schrieb Jörg Sommer:
> Package: byzanz
> Version: 0.3.0+git20160312-2
> Severity: normal
> 
> Hi,
> 
> I'm having a second display attached which is why my desktop is wider than
> the rectangle I would like to capture: 7680x2160 vs. 3840x2160. But using
> the options -w 3840 -h 2160 -x 0 -y 0 doesn't narrow the video to the
> expected screen. I still get the whole desktop recorded.
> 
> The whole command line: byzanz-record -c -d 5 -w 3840 -h 2160 -x 0 -y 0 
> video.ogv
> 
> Bye Jörg

Hello,

I guess you have to use the --display option to select your preferred
screen. Byzanz has no information about a virtual screen but should be
able to record the portion of your screen with the  -w option when you
use the --display option.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#886432: snapd FTBFS on 32bit: json.go:320:7: constant 9007199254740992 overflows int

[Adrian Bunk]

Source: snapd
Version: 2.30-1
Severity: serious

https://buildd.debian.org/status/package.php?p=snapd=sid

...
# gopkg.in/mgo.v2/bson
src/gopkg.in/mgo.v2/bson/json.go:320:7: constant 9007199254740992 overflows int

Bug#886431: snapd binary-all FTBFS: install: failed to access debian/snapd///usr/lib/snapd: No such file or directory

[Adrian Bunk]

Source: snapd
Version: 2.30-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=snapd=all=2.30-1=1515103055=0

...
/usr/bin/make -C systemd install
make[3]: Entering directory '/<>/data/systemd'
# NOTE: old (e.g. 14.04) GNU coreutils doesn't -D with -t
install -d -m 0755 /<>/debian/snapd//lib/systemd/system/
install -m 0644 -t /<>/debian/snapd//lib/systemd/system/ 
snapd.refresh.service snapd.core-fixup.service snapd.autoimport.service 
snapd.snap-repair.service snapd.service snapd.system-shutdown.service 
snapd.refresh.timer snapd.snap-repair.timer snapd.socket
install -m 0755 -t /<>/debian/snapd///usr/lib/snapd 
snapd.core-fixup.sh
install: failed to access '/<>/debian/snapd///usr/lib/snapd': No 
such file or directory
Makefile:36: recipe for target 'install' failed
make[3]: *** [install] Error 1

Bug#884601: "console=ttyAMA0,115200" --> "console=tty0"

[Matthias Luescher]

Hi Michael


> I just uploaded a new raspi3-firmware package which uses ttyS1 on Linux
> ≥ 4.14, which is the new device name for the UART on the pin header:
> https://anonscm.debian.org/cgit/pkg-raspi/raspi3-firmware.git/commit/?id=
> 4da2e6b1576f0a7513bffe7f95882693fdadd7ae


Many thanks - this works great!

I just verified it by fetching raspi3-firmware (1.20171201-1) from sid:
https://github.com/lueschem/edi-pi/commit/d3a1b5055fa4441b7ce42d6827868bdf8e46fdda

Best regards
Matthias

Bug#886430: iem-plugin-suite FTBFS on !amd64/x32

[Adrian Bunk]

Source: iem-plugin-suite
Version: 1.0.1-2
Severity: important

https://buildd.debian.org/status/package.php?p=iem-plugin-suite=sid

...
In file included from ../../Source/PluginProcessor.h:30:0,
 from ../../Source/PluginProcessor.cpp:23:
../../Source/../../resources/interpCoeffsSIMD.h:32:7: error: '__m128' does not 
name a type; did you mean '._118'?
 const __m128 interpCoeffsSIMD[129] = {{0.0, 1.0, 0.0, 0.0, },
   ^~


Either the package can be made build (and work) without SSE,
or the architecture list should be restricted to amd64 and x32.

Bug#886429: [L10N,DE] apt: updated german program translation

[Holger Wansing]

Package: apt
Severity: wishlist
Tags: patch,l10n


Hi,
attached is the updated german program translation for apt, version 1.6-alpha5.
Please include it in your package.


Thanks for your i18n efforts.

So long
Holger

-- 

Created with Sylpheed 3.2.0 under the new
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

Registered Linux User #311290 - https://linuxcounter.net/



apt_1.6-alpha5_de.po.gz
Description: application/gzip

Bug#886428: [kmail] Crashes on nouveau with mesa 17.3.1

[gisl]

Package: kmail
Version: 4:17.08.3-2
Severity: normal

--- Please enter the report below this line. ---
kmail, kontact and other applications using Qt's WebEngine crash when using 
the nouveau Xorg driver and mesa 17.3.1.

The output is like this:
nouveau: kernel rejected pushbuf: No such file or directory
nouveau: ch25: krec 0 pushes 0 bufs 2 relocs 0
nouveau: ch25: buf  0002 0004 0004 
nouveau: ch25: buf 0001 0006 0004  0004
*** KMail got signal 11 (Exiting)

Some search suggests that this is actually a well-known nouveau bug, which 
occurs with multithreaded rendering.

Qt appears to have decided to disable GL with nouveau altogether for Qt 5.10:
https://bugreports.qt.io/browse/QTBUG-41242
but for now, they suggest to set

QT_XCB_FORCE_SOFTWARE_OPENGL=1

as a workaround. So until nouveau is fixed, or Qt 5.10 released and packaged, 
it may be sensible to
- document this somewhere, e.g. with apt-listchanges or
- try to detect the use of nouveau and automatically set the environment 
variable, or
- use this ticket as documentation

Also see
- https://bugzilla.redhat.com/show_bug.cgi?id=1376107
- https://bugs.freedesktop.org/show_bug.cgi?id=91632

--- System information. ---
Architecture: 
Kernel:   Linux 4.14.0-2-amd64

Debian Release: buster/sid
  500 unstablewww.deb-multimedia.org 
  500 unstableftp.de.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-
==
akonadi-server  (>= 4:17.08~) | 
4:17.08.3-2
kdepim-runtime  (>= 4:17.08~) | 
4:17.08.3-3
libkf5akonadisearch-bin (>= 4:17.08~) | 
4:17.08.3-1
libkf5akonadisearch-plugins (>= 4:17.08~) | 
4:17.08.3-1
libkf5grantleetheme-plugins   (>= 17.08~) | 17.08.3-1
kio   | 5.37.0-2
libc6   (>= 2.14) | 
libgcc1(>= 1:3.0) | 
libgpgmepp6   (>= 1.10.0) | 
libkf5akonadiagentbase5 (>= 15.07.90) | 
libkf5akonadicontact5 | 
libkf5akonadicore5 (>= 4:17.08.0) | 
libkf5akonadimime5| 
libkf5akonadisearchdebug5 | 
libkf5akonadisearchpim5  (>= 16.08.0) | 
libkf5akonadiwidgets5  (>= 4:17.08.0) | 
libkf5bookmarks5  (>= 4.96.0) | 
libkf5calendarcore5 (>= 15.07.90) | 
libkf5calendarutils5  | 
libkf5codecs5   (>= 5.4.0+git20141202.0008+15.04) | 
libkf5completion5 (>= 4.97.0) | 
libkf5configcore5 (>= 4.98.0) | 
libkf5configgui5  (>= 4.97.0) | 
libkf5configwidgets5  (>= 5.23.0) | 
libkf5contacts5  (>= 15.12.0) | 
libkf5coreaddons5  (>= 5.2.0) | 
libkf5crash5  (>= 5.15.0) | 
libkf5dbusaddons5 (>= 4.97.0) | 
libkf5followupreminder5(>= 4:16.04.0) | 
libkf5gravatar5  (>= 4:15.12) | 
libkf5guiaddons5  (>= 4.96.0) | 
libkf5i18n5   (>= 4.97.0) | 
libkf5iconthemes5  (>= 5.0.0) | 
libkf5identitymanagement5(>= 17.08.0) | 
libkf5itemmodels5 (>= 4.96.0) | 
libkf5itemviews5  (>= 4.96.0) | 
libkf5jobwidgets5 (>= 4.96.0) | 
libkf5kcmutils5(>= 5.2.0+git20141003) | 
libkf5kiocore5(>= 4.96.0) | 
libkf5kiofilewidgets5 (>= 4.96.0) | 
libkf5kiowidgets5 (>= 5.35.0) | 
libkf5kontactinterface5   | 
libkf5ksieveui5   | 
libkf5libkdepim-plugins   | 
libkf5libkdepim5   (>= 16.04) | 
libkf5libkdepimakonadi5   | 
libkf5libkleo5 (>= 4:17.08.0) | 
libkf5mailcommon-plugins  | 

Bug#886362: openmw FTBFS on armel/armhf: error: 'GL_AMBIENT' was not declared in this scope

[Adrian Bunk]

On Fri, Jan 05, 2018 at 08:38:07AM +0100, bret curtis wrote:
> We've been wrestling with this for ages now, because libqt5opengl5-dev
> behaves differently on arm64 than on armel, can you guarantee that
> changing the dep to libqt5opengl5-desktop-dev will force to build
> against opengl and not gles2?
>...

There is no libqt5opengl5-desktop-dev on armel/armhf, the only point of 
this change is to not try to build openmw on armel/armhf at all since
it is known that this will always fail.

> Cheers,
> Bret
> 
> On Thu, Jan 4, 2018 at 10:55 PM, Adrian Bunk  wrote:
>...
> > Ideally it should be made working to build when Qt is using
> > OpenGL ES, bug if that is not possible it would be better to
> > avoid the FTBFS by changing the build dependency from
> > libqt5opengl5-dev to libqt5opengl5-desktop-dev.

cu
Adrian

-- 

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

Bug#885949: RM: gnome-specimen -- RoM; RoQA; depends on gnome-python

[Jeremy Bicha]

Control: tags -1 -moreinfo

I believe the dependency problem is fixed now.

Thanks,
Jeremy Bicha

Bug#838178: tracker.debian.org: "action needed" details show only with Javascript enabled

[Pierre-Elliott Bécue]

Le vendredi 05 janvier 2018 à 22:14:49+0100, Thomas Schmitt a écrit :
> Hi,
> 
> > Actually the toggle details is no longer relying on javascript but on a
> > HTML5 tag (TitleContent. Maybe
> > Iceweasel 31.7.0 does not support such a tag?
> 
> It seems so. At least the examples from
> 
>   https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
> 
> show up identically in my weasel:
> 
>   
> https://mdn.mozillademos.org/en-US/docs/Web/HTML/Element/details$samples/Providing_a_summary?revision=1338692
>   
> https://mdn.mozillademos.org/en-US/docs/Web/HTML/Element/details$samples/Creating_an_open_disclosure_box?revision=1338692
> 
> Chromium 43.0.2357.65 shows your work correctly and the "Toggle details"
> buttons toggle as they are supposed to.
> 
> So: Thank you for removing the need for JavaScript.
> 
> 
> Have a nice day :)

You're welcome, I'm sorry that it broke some backward compatibility with
older browsers. :/

CC to hertzog to get his opinion.

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


signature.asc
Description: PGP signature

Bug#886426: lintian: reports unoverridable bugs in auto-created dbgsym packages

[Chris Lamb]

tags 886426 + moreinfo
thanks

Hi Thorsten,

> I could, of course, override that in the mksh binary package,
> but the dbgsym package is auto-generated and therefore not
> available for overriding.

I'm a bit lost why your dbgsym package even has a Bugs field to begin
with. :)  What value does it have?


Regards,

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

Bug#886427: libapache2-mod-neko: multiarch and version issues

[David I. Lehn]

Package: libapache2-mod-neko
Severity: normal

I updated an i386 machine that still had libapache2-mod-neko installed.
It updated neko and libneko2 to 2.2.0-1 but libapache2-mod-neko is still
at 2.1.0-4.  This caused apache to fail to start since neko switched to
multiarch and the lib in neko.load has moved.  I'm unsure why the mod
pkg isn't updated, but from the source it looks like it should at least
switch from "Architecture: any" to "all" and have a dependency on
libneko2.

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libapache2-mod-neko depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.29-1
ii  neko2.2.0-1

libapache2-mod-neko recommends no packages.

libapache2-mod-neko suggests no packages.

Bug#886238: Please introduce official nosystemd build profile

[Eduard Bloch]

Hallo,
* Johannes Schauer [Wed, Jan 03 2018, 08:24:49PM]:
> > The speculation about a possible nosystemd profile in
> >  is
> > not consistent with that design principle. If a package contains systemd
> > units or uses of libsystemd, then it's safe to assume they were added for a
> > reason. Whether you value that reason or not, it's nearly always true to say
> > that cutting out systemd-related bits is a functional change.
> 
> Cutting out systemd-related bits is probably a functional change in most 
> cases.

It depends. Properly written software which checks for libsystemd-*
stuff at compile time would, in theory, support such polymorphic style
of integration. The question is - how many packages are prepared for
this, and how many upstreams have already moved to "only Linux and only
systemd" style?

I, for one, do still support non-systemd mode in my software (i.e.
upstream hat on) explicitly - but it's not sufficiently tested anymore
and relies on feedback from users from non-Linux worlds. And it requires
additional work, so some upstream developers might be tempted to drop
non-non-systemd support whatsoever.

So my general feeling is that we might add this profile but it is not
something which should be pushed through, at the expense of Debian
maintainers. It would be manpower stolen from us for the benefit of
ideological warriors from the "weird party". Which is something I am not
comfortable with.

Regards,
Eduard.

Bug#886152: /usr/bin/nm-applet: Re: nm-applet crashes when trying to start a VPN connection

[Gregory E. Maurer]

Package: network-manager-gnome
Version: 1.8.10-1
Followup-For: Bug #886152

Dear Maintainer,

   I can confirm this on my machine.

   After updating to 1.8.10 I have been unable to connect to a
   previously configured VPN connection throught the menu on the
   nm-applet (left click menu).
   
   Upon opening the submenu for "VPN Connections" and selecting the
   desired connection (a checkbox) the applet segfaults and the icon in the
   notification area disappears. It can be restarted from the command
   line (`nm-applet`) but the same actions produce the same results, and
   a segmentation fault is reported on the commandline.

   Under normal circumstances selecting the checkbox for the configured
   VPN connection would raise a window for VPN selection and password
   entry.

   backtrace below

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

Kernel: Linux 4.13.0-1-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)
LSM: AppArmor: enabled

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.2-1
ii  dbus-x11 [dbus-session-bus]   1.12.2-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.1-2
ii  libatk1.0-0   2.26.1-2
ii  libc6 2.25-5
ii  libcairo2 1.15.8-3
ii  libgdk-pixbuf2.0-02.36.11-1
ii  libglib2.0-0  2.54.2-5
ii  libgtk-3-03.22.26-2
ii  libjansson4   2.10-1
ii  libmm-glib0   1.6.8-2
ii  libnm01.10.2-1
ii  libnma0   1.8.10-1
ii  libnotify40.7.7-3
ii  libpango-1.0-01.40.14-1
ii  libpangocairo-1.0-0   1.40.14-1
ii  libsecret-1-0 0.18.5-5
ii  libselinux1   2.7-2
ii  network-manager   1.10.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-6

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring3.20.1-2
ii  iso-codes3.77-1
ii  mobile-broadband-provider-info   20170903-1
ii  notification-daemon  3.20.0-2
ii  xfce4-notifyd [notification-daemon]  0.4.1-1

Versions of packages network-manager-gnome suggests:
ii  network-manager-openconnect-gnome  1.2.4-1
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

The Backtrace:

*** Error in `nm-applet': double free or corruption (out): 0x55b56b4b0760 
***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x722fb)[0x7fb1d077a2fb]
/lib/x86_64-linux-gnu/libc.so.6(+0x7895e)[0x7fb1d078095e]
/lib/x86_64-linux-gnu/libc.so.6(+0x791be)[0x7fb1d07811be]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_strfreev+0x29)[0x7fb1d0d34449]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_datalist_clear+0x6b)[0x7fb1d0cf745b]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_unref+0x1a2)[0x7fb1d0ff1ea2]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x38e41)[0x7fb1d0d01e41]
/usr/lib/x86_64-linux-gnu/libnm.so.0(+0x62187)[0x7fb1d1f73187]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_datalist_clear+0x6b)[0x7fb1d0cf745b]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_unref+0x1a2)[0x7fb1d0ff1ea2]
nm-applet(+0x1629c)[0x55b56904b29c]
nm-applet(+0x198fc)[0x55b56904e8fc]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x47724)[0x7fb1d0d10724]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x155)[0x7fb1d0d13e15]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4b1e0)[0x7fb1d0d141e0]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c)[0x7fb1d0d1426c]
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(g_application_run+0x1fd)[0x7fb1d12d1bed]
nm-applet(+0x101b1)[0x55b5690451b1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fb1d0728561]
nm-applet(+0x102da)[0x55b5690452da]
=== Memory map: 
55b569035000-55b56907d000 r-xp  08:02 142082 
/usr/bin/nm-applet
55b56927d000-55b56927e000 r--p 00048000 08:02 142082 
/usr/bin/nm-applet
55b56927e000-55b56928 rw-p 00049000 08:02 142082 
/usr/bin/nm-applet
55b56b0e1000-55b56b5c6000 rw-p  00:00 0  [heap]
7fb1ac00-7fb1ac021000 rw-p  00:00 0 
7fb1ac021000-7fb1b000 ---p  00:00 0 
7fb1b000-7fb1b0022000 rw-p  00:00 0 
7fb1b0022000-7fb1b400 ---p  00:00 0 

Bug#838178: tracker.debian.org: "action needed" details show only with Javascript enabled

[Thomas Schmitt]

Hi,

> Actually the toggle details is no longer relying on javascript but on a
> HTML5 tag (TitleContent. Maybe
> Iceweasel 31.7.0 does not support such a tag?

It seems so. At least the examples from

  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details

show up identically in my weasel:

  
https://mdn.mozillademos.org/en-US/docs/Web/HTML/Element/details$samples/Providing_a_summary?revision=1338692
  
https://mdn.mozillademos.org/en-US/docs/Web/HTML/Element/details$samples/Creating_an_open_disclosure_box?revision=1338692

Chromium 43.0.2357.65 shows your work correctly and the "Toggle details"
buttons toggle as they are supposed to.

So: Thank you for removing the need for JavaScript.


Have a nice day :)

Thomas

Bug#750732: libanyevent-perl: Intermittent build failures on various architectures

[gregor herrmann]

On Fri, 05 Jan 2018 22:54:08 +0200, Niko Tyni wrote:

> > t/66_ioasync_02_signals.t or t/66_ioasync_03_child.t?
> t/66_ioasync_03_child.t, I think. See below.

Cool.
 
> > Anyway, IIRC we've seen failures in different tests over time.
> That's what I thought too but didn't find much at least
> in the buildd logs.

Ack, my search in recent logs also defeated my memory :)
 
> > On 
> > https://buildd.debian.org/status/fetch.php?pkg=libanyevent-perl=armel=7.140-1=1505267718=0
> > Bailout called.  Further testing stopped:  No child exit detected. This is 
> > either a bug in AnyEvent or a bug in your Perl (mostly some windows 
> > distributions suffer from that): child watchers might not work properly on 
> > this platform. You can force installation of this module if you do not rely 
> > on child watchers, or you could upgrade to a working version of Perl for 
> > your platform.
> > (Does this mean that t/66_ioasync_02_signals.t failed or the
> > following t/66_ioasync_03_child.t ?)
> I think it comes from the 'Bail out! No child exit detected' part in
> t/66_ioasync_03_child.t. Presumably the test libraries are buffering
> parts of the output.

Thanks, this was my assumption as well.
 
> So I guess this all boils down to the (sort of documented) "issues
> with IO::Async", at least until we see other failures.

Agreed.
 
> > Commit pushed to alioth, feedback welcome before I upload.
> LGTM, thanks!

Thanks for checking!


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#886426: lintian: reports unoverridable bugs in auto-created dbgsym packages

[Thorsten Glaser]

Package: lintian
Version: 2.5.67
Severity: minor

When building a modified package for my own repo, I get this:

N: Processing binary package mksh (version 56b.20180105+wtf1, arch i386) ...
N: 
N: Processing binary package mksh-dbgsym (version 56b.20180105+wtf1, arch i386) 
...
W: mksh-dbgsym: bugs-field-does-not-refer-to-debian-infrastructure line 39

I could, of course, override that in the mksh binary package,
but the dbgsym package is auto-generated and therefore not
available for overriding.


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

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.29.1-12
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1
ii  dpkg  1.19.0.4
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdigest-sha-perl6.01-1
ii  libdpkg-perl  1.19.0.4
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-2
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-4
ii  patchutils0.3.4-2
ii  perl  5.26.1-3
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.4
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information

Bug#733610: Webapp no longer part of Gramps

[Ross Gammon]

The latest news is that the webapp was split out of Gramps to a project
called gramps-connect. Then Gprime was created which is a web-based fork
of Gramps & Gramps-connect.

https://genealogycollective.github.io/gprime/

Gprime is a better target to package once it is ready.

Ross



signature.asc
Description: OpenPGP digital signature

Bug#750732: libanyevent-perl: Intermittent build failures on various architectures

[Niko Tyni]

On Fri, Jan 05, 2018 at 02:35:38AM +0100, gregor herrmann wrote:
> On Mon, 01 Jan 2018 18:56:52 +0200, Niko Tyni wrote:

> > Disregarding hurd-i386, the problematic test seems to be
> > t/66_ioasync_03_signals.t, 
> 
> t/66_ioasync_02_signals.t or t/66_ioasync_03_child.t?

t/66_ioasync_03_child.t, I think. See below.

> Anyway, IIRC we've seen failures in different tests over time.

That's what I thought too but didn't find much at least
in the buildd logs.

> > I'm not sure what to make of this. Maybe disarm this particular test somehow
> > for now and see how it fares otherwise?

> On 
> https://buildd.debian.org/status/fetch.php?pkg=libanyevent-perl=armel=7.140-1=1505267718=0

> Bailout called.  Further testing stopped:  No child exit detected. This is 
> either a bug in AnyEvent or a bug in your Perl (mostly some windows 
> distributions suffer from that): child watchers might not work properly on 
> this platform. You can force installation of this module if you do not rely 
> on child watchers, or you could upgrade to a working version of Perl for your 
> platform.
> 
> (Does this mean that t/66_ioasync_02_signals.t failed or the
> following t/66_ioasync_03_child.t ?)

I think it comes from the 'Bail out! No child exit detected' part in
t/66_ioasync_03_child.t. Presumably the test libraries are buffering
parts of the output.

> Looks like t/66_ioasync_03_child.t is our candidate, if I'm
> interpreting this correctly.

Agreed.
 
> Oh, and I have another hang on my Raspi:

Awesome, thanks for testing.

So I guess this all boils down to the (sort of documented) "issues
with IO::Async", at least until we see other failures.

> Commit pushed to alioth, feedback welcome before I upload.

LGTM, thanks!
-- 
Niko

Bug#884217: thunderbird: Latest VCS-Git AppArmor profile (will) break aa-enfroce usage on Jessie

[Carsten Schoenert]

control: reopen -1

Hello Vincas,

if you belive this issue isn't solved we can should reopen this
report.

On Tue, Jan 02, 2018 at 08:19:21PM +0200, Vincas Dargis wrote:
> Uhm, why this bug was marked as Done?
> 
> I have just upgraded some Jessie machine and got error (as expected) during 
> upgrade:
> 
> ```
> AppArmor parser error for /etc/apparmor.d/usr.bin.thunderbird in
> /etc/apparmor.d/usr.bin.thunderbird at line 12: syntax error, unexpected
> TOK_SET_VAR, expecting TOK_OPEN
> ```
> 
> Restarting AppArmorm fails:
> 
> ``
> sudo systemctl restart apparmor
> Job for apparmor.service failed. See 'systemctl status apparmor.service' and 
> 'journalctl -xn' for details.
> ```
> 
> ```
> $ sudo journalctl -xn
> -- Logs begin at An 2018-01-02 20:06:14 EET, end at An 2018-01-02 20:17:16 
> EET. --
> Sau 02 20:17:13 dev-debian8kde systemd[1]: Starting LSB: AppArmor 
> initialization...
> -- Subject: Unit apparmor.service has begun with start-up
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> -- 
> -- Unit apparmor.service has begun starting up.
> Sau 02 20:17:13 dev-debian8kde apparmor[7100]: Starting AppArmor
> profiles:AppArmor parser error for /etc/apparmor.d/usr.bin.thunderbird in
> /etc/apparmor.d/usr.bin.thunderbi
> Sau 02 20:17:13 dev-debian8kde apparmor[7100]: AppArmor parser error for
> /etc/apparmor.d/usr.bin.thunderbird in /etc/apparmor.d/usr.bin.thunderbird
> at line 12: syntax error
> Sau 02 20:17:14 dev-debian8kde apparmor[7100]: failed!
> Sau 02 20:17:14 dev-debian8kde systemd[1]: apparmor.service: control process 
> exited, code=exited status=123
> Sau 02 20:17:14 dev-debian8kde systemd[1]: Failed to start LSB: AppArmor 
> initialization.
> 
> ```

Is this only happen on a Jessie system?
I just ask for setting up the correct tags on this report.

Regards
Carsten

Bug#885633: gnome-chemistry-utils: Please drop Build-Depends on rarian-compat

[Andreas Tille]

Hi,

I'd volunteer to fix this if you give me permission to move the package from
SVN to Git.

Kind regards

Andreas.

On Fri, Jan 05, 2018 at 04:39:05AM +, Debian testing autoremoval watch 
wrote:
> gnome-chemistry-utils 0.14.15-1 is marked for autoremoval from testing on 
> 2018-01-26
> 
> It is affected by these RC bugs:
> 885633: gnome-chemistry-utils: Please drop Build-Depends on rarian-compat

-- 
http://fam-tille.de

Bug#886421: python-escript: FTBFS on m68k: hwloc_set_cpubind returned "Error" for bitmap "0"

[Laurent Vivier]

Le 05/01/2018 à 20:35, Aaron M. Ucko a écrit :
> Source: python-escript
> Version: 5.1-5
> Severity: important
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> User: debian-...@lists.debian.org
> Usertags: m68k
> 
> Builds of python-escript for m68k (admittedly not a release
> architecture) have been failing lately per the below excerpts from
> https://buildd.debian.org/status/fetch.php?pkg=python-escript=m68k=5.1-5=1514854858=0.
> FWIW, automatic builds for this architecture run with nocheck in
> DEB_BUILD_OPTIONS because there's little overall incremental value to
> running tests on such a slow architecture.  However, it's perhaps just
> as well that that setting had no effect here, since this problem
> doesn't affect any other Debian architectures and may be worth
> investigating.
> 
> Could you please take a look?
> 
> Thanks!
> 
> --
> 
> /<>/debian/stage2M/bin/run-escript 
> /<>/debian/tmp2M/scripts/release_sanity.py
> --
> WARNING: a request was made to bind a process. While the system
> supports binding the process itself, at least one node does NOT
> support binding memory to the process location.
> 
>   Node:  vs90
> 
> Open MPI uses the "hwloc" library to perform process and memory
> binding. This error message means that hwloc has indicated that
> processor binding support is not available on this machine.
> [...]
> This is a warning only; your job will continue, though performance may
> be degraded.
> --
> --
> Open MPI tried to bind a new process, but something went wrong.  The
> process was killed without launching the target application.  Your job
> will now abort.
> 
>   Local host:vs90
>   Application name:  /<>/debian/stage2M/lib/pythonMPI
>   Error message: hwloc_set_cpubind returned "Error" for bitmap "0"
>   Location:  rtc_hwloc.c:190
> --
> scons: *** [dummy] Error 213
> scons: building terminated because of errors.
> 
> *** Config Summary (see config.log and /lib/buildvars for details) ***
> Escript revision 6608
>   Install prefix:  /<>/debian/stage2M
>   Python:  /usr/bin/python (Version 2.7.14)
>boost:  /usr (Version 1.62.0)
>numpy:  YES (with headers)
>  MPI:  OPENMPI (Version 2.1.1)
>   Solver library:  paso
>Direct solver:  NONE
>  domains:  dudley, finley, ripley, speckley
>   netcdf:  YES (3)
>weipa:  YES
>   openmp:  YES
> 
>   DISABLED features: boomeramg cppunit cuda debug gdal gmsh gzip lapack mkl 
> papi parmetis pyproj scipy silo sympy trilinos umfpack visit
>   Treating warnings as errors
> 
> WARNING: Cannot import scipy. NetCDF sources will not be available for 
> inversions.
> WARNING: Cannot import pyproj. Inversions may not work.
> WARNING: Cannot import gdal. Inversions will not honour WKT coordinate system 
> information.
> WARNING: Cannot import sympy. Symbolic toolbox and nonlinear PDEs will not be 
> available.
> WARNING: matplotlib not found, will skip some unit tests
> WARNING: gmsh not available. Skipping tests usersguide/trapezoid.py 
> usersguide/quad.py usersguide/brick.py usersguide/refine.py 
> cookbook/example04a.py cookbook/example04b.py cookbook/example05a.py 
> cookbook/example05b.py cookbook/example05c.py cookbook/example06.py 
> cookbook/example08c.py cookbook/example09m.py cookbook/example09a.py 
> cookbook/example10m.py inversion/dc_forward.py!
> 
> ERROR: build stopped due to errors
> 
> debian/rules:57: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 2
> make[1]: Leaving directory '/<>'
> debian/rules:30: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2
> 

It seems this buildd is running a m68k chroot on AMD64 using qemu-m68k.

Samuel Thibault has posted patches to qemu-devel mailing-list to fix CPU
affinity related functions:

  [PATCH] linux-user: Add getcpu() support
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg502788.html

  [PATCH] linux-user: Fix sched_get/setaffinity conversion
  https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg05242.html

Perhaps it could fix this problem.

Thanks,
Laurent

Bug#886417: linux-source-4.9: Kernel sources do not compile

[David Reviejo]

Hi,

I have the same error with a very old machine, a Pentium-M one, (and so
no SMP...) trying to compile the source from 4.9.65-3+deb9u2 with a
custom config.

The problem is: the "load_new_mm_cr3" function in arch/x86/mm/tlb.c is
compiled only when SMP config is defined, but is used in code compiled
for no SMP machines (line 160); because of this the
"implicit-function-declaration" error.

Trying your sugestion, upstream 4.9.75 compile without problems: the
tlb.c there has no SMP special code (the header says something about:
"formerly SMP-only"...).

Cheers,
-- 
David

Bug#886425: radicale: Dependency on python*-tz is missing

[Matthias Urlichs]

Source: radicale
Version: 2.1.8-1
Severity: important

# radicale -f
[…]
ERROR:root:No module named 'pytz'

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

Kernel: Linux 4.13.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)

Bug#886421: python-escript: FTBFS on m68k: hwloc_set_cpubind returned "Error" for bitmap "0"

[John Paul Adrian Glaubitz]

On 01/05/2018 08:35 PM, Aaron M. Ucko wrote:> DEB_BUILD_OPTIONS because there's 
little overall incremental value to
> running tests on such a slow architecture.  However, it's perhaps just

We could actually enable tests and I will do that in the future. It's
just currently not our current focus.

> as well that that setting had no effect here, since this problem> doesn't 
> affect any other Debian architectures and may be worth> investigating.
It could be an actual bug that just doesn't trigger on other environments
at the moment. It might also be a compiler bug or a QEMU bug, so it's
always worth investigating :).

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

Bug#824883: bug#824883

[Fabio Scotoni]

This issue is still current; I just wanted to add that SIMH has also
published bug fixes for 3.9-0 on their website:
http://simh.trailing-edge.com/interim/

Supposedly, these include "important fixes  for the VAX780, PDP-11, and
1401". It may be worth to include those in an update to 3.9.

The most recent file on there is from 2014, however. The same goes for
beta releases on GitHub. I'm unsure of the versioning policy that SIMH
follows; maybe it is worth considering picking a specific git commit for
the time being and stabilizing that.

Bug#886424: intel-microcode: amd64-microcode and intel-microcode cannot be used together when both use INITRAMFS=early

[Benjamin Drung]

Package: intel-microcode
Version: 3.20171215.1
Severity: important

Hi,

we create an initrd for a live system that should be bootable on AMD and
Intel systems. Due to various CPU bugs, the microcode update for both
AMD and Intel should be included in the initrd. We do not want to manage
two different initrd files.

amd64-microcode and intel-microcode are installed and configured to
AMD64UCODE_INITRAMFS=early and IUCODE_TOOL_INITRAMFS=early, but only the
microcode from AMD can be seen in the initrd:

$ lsinitramfs /boot/initrd.img | head -n 10
.
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/AuthenticAMD.bin
.
usr
usr/lib
usr/lib/x86_64-linux-gnu
usr/lib/x86_64-linux-gnu/libsgutils2.so.2.0.0

This is probably a bug in combination with initramfs-tools:
/usr/share/initramfs-tools/hook-functions from initramfs-tools-core
provides a prepend_earlyinitramfs() function:

prepend_earlyinitramfs() {
# Sanity check
if [ ! -e "${1}" ]; then
echo "W: prepend_earlyinitramfs: arg1='${1}' does not
exist." >&2
return
fi
cat "${1}" >>"${__TMPEARLYCPIO}"
}

When amd64-microcode and intel-microcode are configured to 'early', then
the amd64-microcode hook will call prepend_earlyinitramfs() to add a
cpio archive containing kernel/x86/microcode/AuthenticAMD.bin which is
added to an empty temporary file by prepend_earlyinitramfs(). Afterwards
the intel-microcode will call prepend_earlyinitramfs() to add a cpio
archive containing kernel/x86/microcode/GenuineIntel.bin which is added
to same temporary file by prepend_earlyinitramfs(). Concatenating two
cpio archives together doesn't seem to work as expected.

Instead one cpio archive should probably created that contain
kernel/x86/microcode/AuthenticAMD.bin and
kernel/x86/microcode/GenuineIntel.bin.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL: https://www.profitbricks.de

Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss, Matthias Steinberg

Bug#886338: missing url

[Jeffrey Cliff]

URL should be

 https://github.com/pytest-dev/pytest-asyncio not  https://github.com/Tinche

Bug#886423: python-pysaml2: CVE-2017-1000433: Access restriction bypass

[Salvatore Bonaccorso]

Source: python-pysaml2
Version: 2.0.0-1
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/rohe/pysaml2/issues/451

Hi,

the following vulnerability was published for python-pysaml2.

CVE-2017-1000433[0]:
| pysaml2 version 4.4.0 and older accept any password when run with
| python optimizations enabled. This allows attackers to log in as any
| user without knowing their password.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-1000433
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000433
[1] https://github.com/rohe/pysaml2/issues/451
[2] 
https://github.com/rohe/pysaml2/commit/6312a41e037954850867f29d329e5007df1424a5

Regards,
Salvatore

Bug#886422: /usr/include/glibmm-2.4/glibmm/variant.h: Incompatible with clang++-6.0

[Philipp Marek]

Package: libglibmm-2.4-dev
Version: 2.54.1-2
Severity: normal
File: /usr/include/glibmm-2.4/glibmm/variant.h


Trying to compile some sources (pulseview from the sigrok project) with 
clang++-6.0 I get this error:

/usr/include/glibmm-2.4/glibmm/variant.h:2132:3: error: use of this 
statement in a constexpr function is a C++14 extension 
[-Werror,-Wc++14-extensions]
  (void)arg;
  ^

If the message is correct, this header file should be fixed; if it ain't, 
I guess that clang++-6.0 is at fault.


Thanks!


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

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

Versions of packages libglibmm-2.4-dev:amd64 depends on:
ii  libglib2.0-dev 2.54.2-5
ii  libglibmm-2.4-1v5  2.54.1-2
ii  libsigc++-2.0-dev  2.10.0-1
ii  pkg-config 0.29-4+b1

libglibmm-2.4-dev:amd64 recommends no packages.

Versions of packages libglibmm-2.4-dev:amd64 suggests:
pn  libglibmm-2.4-doc  
pn  libgtkmm-3.0-dev   

-- no debconf information

-- 

Bug#886421: python-escript: FTBFS on m68k: hwloc_set_cpubind returned "Error" for bitmap "0"

[Aaron M. Ucko]

Source: python-escript
Version: 5.1-5
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: m68k

Builds of python-escript for m68k (admittedly not a release
architecture) have been failing lately per the below excerpts from
https://buildd.debian.org/status/fetch.php?pkg=python-escript=m68k=5.1-5=1514854858=0.
FWIW, automatic builds for this architecture run with nocheck in
DEB_BUILD_OPTIONS because there's little overall incremental value to
running tests on such a slow architecture.  However, it's perhaps just
as well that that setting had no effect here, since this problem
doesn't affect any other Debian architectures and may be worth
investigating.

Could you please take a look?

Thanks!

--

/<>/debian/stage2M/bin/run-escript 
/<>/debian/tmp2M/scripts/release_sanity.py
--
WARNING: a request was made to bind a process. While the system
supports binding the process itself, at least one node does NOT
support binding memory to the process location.

  Node:  vs90

Open MPI uses the "hwloc" library to perform process and memory
binding. This error message means that hwloc has indicated that
processor binding support is not available on this machine.
[...]
This is a warning only; your job will continue, though performance may
be degraded.
--
--
Open MPI tried to bind a new process, but something went wrong.  The
process was killed without launching the target application.  Your job
will now abort.

  Local host:vs90
  Application name:  /<>/debian/stage2M/lib/pythonMPI
  Error message: hwloc_set_cpubind returned "Error" for bitmap "0"
  Location:  rtc_hwloc.c:190
--
scons: *** [dummy] Error 213
scons: building terminated because of errors.

*** Config Summary (see config.log and /lib/buildvars for details) ***
Escript revision 6608
  Install prefix:  /<>/debian/stage2M
  Python:  /usr/bin/python (Version 2.7.14)
   boost:  /usr (Version 1.62.0)
   numpy:  YES (with headers)
 MPI:  OPENMPI (Version 2.1.1)
  Solver library:  paso
   Direct solver:  NONE
 domains:  dudley, finley, ripley, speckley
  netcdf:  YES (3)
   weipa:  YES
  openmp:  YES

  DISABLED features: boomeramg cppunit cuda debug gdal gmsh gzip lapack mkl 
papi parmetis pyproj scipy silo sympy trilinos umfpack visit
  Treating warnings as errors

WARNING: Cannot import scipy. NetCDF sources will not be available for 
inversions.
WARNING: Cannot import pyproj. Inversions may not work.
WARNING: Cannot import gdal. Inversions will not honour WKT coordinate system 
information.
WARNING: Cannot import sympy. Symbolic toolbox and nonlinear PDEs will not be 
available.
WARNING: matplotlib not found, will skip some unit tests
WARNING: gmsh not available. Skipping tests usersguide/trapezoid.py 
usersguide/quad.py usersguide/brick.py usersguide/refine.py 
cookbook/example04a.py cookbook/example04b.py cookbook/example05a.py 
cookbook/example05b.py cookbook/example05c.py cookbook/example06.py 
cookbook/example08c.py cookbook/example09m.py cookbook/example09a.py 
cookbook/example10m.py inversion/dc_forward.py!

ERROR: build stopped due to errors

debian/rules:57: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
debian/rules:30: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

-- 
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#886400: python3-pyqt5.qtwebengine: segfaults on simple test

[Dmitry Shachnev]

Hi David!

On Fri, Jan 05, 2018 at 07:39:59AM -0400, David Bremner wrote:
> I encountered this when trying to run webmacs (a browser written in
> python) on Debian.
>
> The attached script segfaults, seemingly on any URL. Feel free to
> adjust the severity up or down; I'm guessing the package works for
> some people / applications, but this seems like pretty core
> functionality to be broken.

I cannot reproduce this (tested with e.g. https://www.debian.org).

Can you please attach some stacktrace?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#804764: closed by Pino Toscano <p...@debian.org> (Re: Bug#804764: kdevelop-python: Python 2 support missing)

[Jacob Kanev]

Hi Pino,
thank you for the message. Switching to Python 2 is not an option, as our 
company management system (OpenERP / odoo) is written in Python 2 and I cannot 
rewrite that.
That said, I've switched to PyCharm which happily supports both 2 and 3.

Have a very nice week-end, all the best, Jacob.

   __
   Jacob Kanev
   Setting Orange, 5th of Chaos, 3184
  email: jka...@zoho.com
  twitter: @j_kanev  | jabber: jka...@jabber.ccc.de  |  skype: j_kanev
  web: http://jkanev.info  |  blog: http://jacobkanev.wordpress.com


On Friday, 5 January 2018 15:24:08 CET Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the kdevelop-python package:
> 
> #804764: kdevelop-python: Python 2 support missing
> 
> It has been closed by Pino Toscano .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Pino Toscano 
>  by
> replying to this email.
> 
> 
> 

Bug#886401: evince: Evince does not start: Error in `evince': double free or corruption (fasttop)

[Jason Crain]

Control: severity -1 important
Control: reassign -1 libfontconfig1 2.12.6-0.1
Control: affects -1 evince
Control: forcemerge 882590 -1

Crash appears to have happened while fontconfig was parsing a config
file.  If you have a customized fontconfig configuration it's possibly
triggering a bug in fontconfig.  Though memory corruption bugs are
tricky and can cause crashes in unrelated parts of the program.

I'm reassigning/merging this to fontconfig because your description
looks a lot like https://bugs.debian.org/882590.  According to some of
the comments in that bug, you could try downgrading libfontconfig1 or
removing your ~/.fonts.conf.  Keep a copy of your .fonts.conf though in
case it's useful for debugging.

Bug#885974: lintian: warn about non-git Vcs fields hosted on Debian infrastructure

[Chris Lamb]

tags 885974 + pending
thanks

[Note renamed bug for clarity / prevention of flamewars!]

Fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=51e416260cc4b84ce27f65e2fb8bfb132e84385d


Regards,

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

Bug#886335: addendum

[Brian Potkin]

On Fri 05 Jan 2018 at 01:10:52 +0100, SZABO Zsolt wrote:

> I think, that the bug is related to the utility gstoraster as described here
> (it does not recognise PJL encapsulated, PostScript document text
> starting with "\033%-12345X@PJL JOB"):
> 
> https://www.linuxquestions.org/questions/slackware-14/slackware-cups-can%27t-detect-file-type-4175605111/

This is a possibility. It would still be useful to have the asked-for
error_log though. Also view the file sent to CUPS with less and let us
have its first ten lines.
 
> As a dirty hack I replaced the last line of the gstopdf script (in
> /usr/lib/cups/filter) calling gstoraster for
> 
> /usr/bin/ps2pdf - -
> 
> and it works. (However, some options like jobid, user, copies, peculiar
> options etc. are not passed, so some more complex print jobs may
> not so be processed as expected.)
> 
> And I have not tested the local printings yet (from the linux host)...

Might it not be easier to get Windows to send plain PostScript?

Regards,

Brian.

Bug#884771: jetty9 doesn't start anymore

[Emmanuel Bourg]

Le 05/01/2018 à 10:49, Chris Donoghue a écrit :

> I did a diff between 9.2.22-3 and  9.2.22-2 extracted deb files and
> many don't there is missing version strings in the
> 9.2.22-3 debian package.
> 
> Perhaps issue lays there.

Thanks a lot that was indeed the cause of the issue. The missing version
is a consequence of recent changes in maven-debian-helper. This will be
fixed in jetty9/9.2.23-1.

Emmanuel Bourg

Bug#883153: dpdk: Please port to Python3

[Luca Boccassi]

Control: tags -1 pending

On Tue, 02 Jan 2018 18:29:53 +0100 Luca Boccassi 
wrote:
> On Thu, 30 Nov 2017 09:30:16 +0100 Matthias Klose 
> wrote:
> > Package: src:dpdk
> > Version: 16.11.2-4
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2-removal
> > 
> > dpdk: Please port to Python3. Looks like the package doesn't have
any
> > dependencies on other Python modules.
> 
> 3 things left to do:
> 
> - convert 2 examples from python2 to python3 (dpdk-doc package):
>   - dpdk/examples/ip_pipeline/config/pipeline-to-core-mapping.py
>   - dpdk/examples/ip_pipeline/config/diagram-generator.py
> - convert 3 scripts in the dpdk package from python2 to python3 (dpdk
> package):
>   - dpdk/usertools/dpdk-devbind.py
>   - dpdk/usertools/cpu_layout.py
>   - dpdk/usertools/cpu_layout.py
> - convert from python-pyelftools to python3-pyelftools - part of the
> above item
> 
> -- 
> Kind regards,
> Luca Boccassi

Hi,

I've given it a spin and it looks like all involved scripts work with
both python and python3.
I won't be changing the shebang (#!/usr/bin/env python) as I assume
once python2 is gone python will map to python3 in the PATH.

I've left an alternative Recommends: python-pyelftools | python3-
pyelftools given that at the moment the shebang will still call
python2. Once the python-pyelftools package is gone from the archive
though it should just keep working.


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

Bug#884771: Pending fixes for bugs in the jetty9 package

[pkg-java-maintainers]

tag 884771 + pending
thanks

Some bugs in the jetty9 package are closed in revision
d0c8a58d57e8ab0aaa19c2a71c19af8be60f03c6 in branch 'master' by
Emmanuel Bourg

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

Commit message:

Fixed the broken symlinks indirectly caused by the new pom patching 
sequence in maven-debian-helper 2.2.8 (Closes: #884771)

Bug#779809: /usr/bin/pahole: does not support DWARF 4

[Guus Sliepen]

severity: grave
thanks

None of the tools in the dwarves package seem to work anymore, rendering
the package in question unusable.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#886420: radicale: Please add a systemd unit file

[Matthias Urlichs]

Source: radicale
Version: 2.1.8-1
Severity: normal

Please add a systemd unit file.

A sample file is at http://radicale.org/setup/

This is a bug instead of a wishlist item because the standard init file
redirects stderr to /dev/null, which is not very nice when one needs to
find a broken ICS file that happens to abort the DAV sync . :-/


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

Kernel: Linux 4.13.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)

Bug#875115: [pyqwt5] Future Qt4 removal from Buster

[Gudjon I. Gudjonsson]

Hi

Please remove the package from Debian.
It is impossible to update it to Qt5.

I will check how to do that but I guess you are faster :)

Regards
Gudjon

Bug#841836: frescobaldi: Inserting Unicode Character 턾 is not shown in the Editor of Frescobaldi

[Ryan Kavanagh]

Control: tags -1 + moreinfo unreproducible

Hi Peter,

I'm unable to reproduce this with frescobaldi version 3.0.0+ds1-1. Could you
please let me know if you still experience this bug with the latest version of
frescobaldi?

Best wishes,
Ryan

-- 
|_)|_/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
| \| \  https://ryanak.ca/ |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#882130: fixed in reportbug 7.1.8

[Jochen Sprickerhof]

control: reopen -1

Hi,

this fix removes the error output of apt-cache showsrc when there is no 
deb-src.


reportbug-7.1.7:

$ reportbug release.debian.org
[..]
Choose the request type: 7
Please enter the name of the package: ros-bond-core
Checking status database...
E: You must put some 'source' URIs in your sources.list
This package doesn't appear to exist; continue? [y|N|?]?

reportbug-7.1.8:

$ reportbug release.debian.org
[..]
Choose the request type: 7
Please enter the name of the package: ros-bond-core
Checking status database...
This package doesn't appear to exist; continue? [y|N|?]?

The "E: You must put some 'source' URIs in your sources.list" is 
missing, because it's redirected to stdout. But in this case it helps a 
lot. I was not able to reproduce the libc6 bug, but I would propose to 
redirect stderr for that command to /dev/null (as done for others as

well) instead.

Cheers Jochen

* Sandro Tosi  [2017-12-29 04:50]:

Source: reportbug
Source-Version: 7.1.8

We believe that the bug you reported is fixed in the latest version of
reportbug, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 882...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sandro Tosi  (supplier of updated reportbug package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 28 Dec 2017 23:25:43 -0500
Source: reportbug
Binary: reportbug python3-reportbug
Architecture: source all
Version: 7.1.8
Distribution: unstable
Urgency: medium
Maintainer: Reportbug Maintainers 
Changed-By: Sandro Tosi 
Description:
python3-reportbug - Python modules for interacting with bug tracking systems
reportbug  - reports bugs in the Debian distribution
Closes: 695887 773346 849763 849765 863823 866596 868022 868154 871527 871769 
872780 875309 877650 878420 878436 878437 878538 882130 882983 883577
Changes:
reportbug (7.1.8) unstable; urgency=medium
.
  * reportbug/debbugs.py
- add `a11y` tag
- dont RFC2047-encode the Owner pseudo header when submitting a WNPP bug;
  patch by Nis Martensen; Closes: #872780
  * reportbug/utils.py, bin/*
- fix invalid escape sequence deprecation warnings with Python 3.6; patch by
  Ville Skyttä; Closes: #878437
- redirect stderr to stdout when running commands via get_command_output(),
  and this prevents errors to be sent to the terminal; Closes: #882130
  * reportbug/ui/gtk2_ui.py
- typo fix; Closes: #875309
  * debian/control
- add sensible-utils to reportbug depends, since we require sensible-*
  commands to be available; Closes: #871527
  * man/reportbug.1
- fix reference to -A/--attach in the include-file section; patch by Alex
  Muntada; Closes: #871769, #878420
  * reportbug/{debbugs.py, utils.py}
- add tailing new-line when processing strings line by line; patch by Nis
  Martensen; Closes: #866596
  * reportbug/submit.py
- remove spurious print() of MIME type, introduced during the py3k porting;
  patch by Nis Martensen; Closes: #868154
- use quoted-printable encoding for lines that are over 980 chars long;
  patch by Nis Martensen; Closes: #849765
  * fix some spelling errors; patch by Ville Skyttä; Closes: #878436
  * bin/reportbug
- preserve attachments order; patch by Ville Skyttä; Closes: #878538
  * add Linux Security Model (LSM) information to the 'System info' section of
the bug report (if any LSM is enabled on the system); patch by Laurent
Bigonville and intrigeri; Closes: #773346
  * debian/source/options
- use the default XZ compression algo by removing the custom setting to use
  bzip2; patch by Boyuan Yang; Closes: #863823
  * use context managers to avoid leaving unclosed file descriptors (which often
results in users losing control of their terminal windows); patch by Nis
Martensen; Closes: #695887, #849763, #882983
  * prevent Unicode(De|En)codeError with most open() calls by using
'backslashreplace' in case of errors; patch by Nis Martensen;
Closes: #877650, #883577, #868022
  * debian/copyright
- leave only me as Upstream-Author and Packaged-By
  * debian/control
- bump Standards-Version to 4.1.2 (no changes needed)
  * debian/rules
- dont call dpkg-parsechangelog directly, use dpkg/pkg-info.mk instead
Checksums-Sha1:
a2a0567f6c0e867eea588a3f86005e3b92a4714d 1818 reportbug_7.1.8.dsc
5a37448de289ef4a777065a3cab8b61f5a011db0 369944 reportbug_7.1.8.tar.xz

Bug#886419: systray-mdstat: complains at startup, despite everything appears to be fine

[Francesco Poli (wintermute)]

Package: systray-mdstat
Version: 1.1.0-1
Severity: normal

Hello,
thanks for developing and packaging this little nice notifier!

I am giving it a try, when I noticed something weird.

As soon as I start it, it complains on stdout (and Gtk complains on
stderr):

  $ systray-mdstat 
  no notify because setup failed: 
  Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

In the meanwhile, a dialog window appears, informing me that all my md
devices are OK. Since this is the same exact conclusion I can draw from
/proc/mdstat, I assume that systray-mdstat is working correctly.

But then, why the complaint on stdout?
What does it mean, anyway?
Which setup failed?
What am I supposed to do, in order to fix the setup?
I haven't found any trace of needed setup in the documentation.

Am I missing or misunderstanding something?

Moreover, I would love to see Gtk stop complaining.
Is there anything that can be done to fix the issue reported by Gtk,
if it is an issue at all?


Please let me know and/or fix the bug.
Bye and 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.14.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systray-mdstat depends on:
ii  libfile-sharedir-perl  1.104-1
ii  libgtk3-perl   0.032-1
ii  libtry-tiny-perl   0.30-1
ii  perl   5.26.1-3

systray-mdstat recommends no packages.

Versions of packages systray-mdstat suggests:
ii  fbpanel 7.0-4
pn  smart-notifier  

-- no debconf information

Bug#886389: dpkg: conffile marked as obsolete after being taken over by different package

[Sven Joachim]

On 2018-01-05 14:04 +0100, Guillem Jover wrote:

> On Fri, 2018-01-05 at 10:55:50 +0100, Sven Joachim wrote:
>> On 2018-01-05 10:44 +0100, Sven Joachim wrote:
>> 
>> > Package: dpkg
>> > Version: 1.19.0.4
>> > Severity: normal
>> >
>> > After switching from rxvt-unicode-256color to rxvt-unicode (see
>> > #848284), dpkg-query reports a conffile as obsolete:
>> >
>> > ,
>> > | $ dpkg-query -W -f='${Conffiles}\n' | grep obsolete$
>> > |  [...]
>> > |  /etc/X11/app-defaults/URxvt 7b221a2da49507e31f42e702791b085b obsolete
>> > | $ dpkg -S /etc/X11/app-defaults/URxvt 
>> > |  rxvt-unicode: /etc/X11/app-defaults/URxvt
>> > `
>> >
>> > This is bogus since the file is shipped in the package, otherwise it
>> > would belong to rxvt-unicode-256color which was its previous owner.
>
> This does not show what package owned that obsolete entry, though. But
> in principle that should have been rxvt-unicode-256color. Both packages
> will have such conffiles listed in their Conffiles fields, but the old
> one might have an obsolete entry, which will be ignored by dpkg for
> most operations.

That seems to be correct.  What I find confusing is that neither
"dpkg -S /etc/X11/app-defaults/URxvt" nor
"dpkg -L rxvt-unicode-256color" give any hint about this.  What is the
point of leaving the obsolete conffile in the dpkg database then?

>> Purging the rxvt-unicode-256color package helped, although that package
>> did not contain any files according to "dpkg -L" (I had already removed
>> but not purged it).  Now the conffile is no longer reported as obsolete.
>
> Was going to ask for the -s output for both packages, but it's too
> late now. :) Well, barring reinstalling the older package.

It was easy to replicate the upgrade, so here is the output which I
think matches your expectations:

,
| $ dpkg -s rxvt-unicode rxvt-unicode-256color
| Package: rxvt-unicode
| Status: install ok installed
| Priority: optional
| Section: x11
| Installed-Size: 3312
| Maintainer: Ryan Kavanagh 
| Architecture: i386
| Version: 9.22-2
| Replaces: aterm (<< 1.0.1dummy), aterm-ml (<< 1.0.1dummy), rxvt (<< 
1:2.7.10-7.1~), rxvt-ml (<< 1:2.7.10-7.1~), rxvt-unicode-256color (<< 9.22-2), 
rxvt-unicode-lite (<< 9.22-2)
| Provides: aterm, rxvt, x-terminal-emulator
| Depends: libc6 (>= 2.17), libfontconfig1 (>= 2.12), libfreetype6 (>= 2.2.1), 
libgcc1 (>= 1:4.2), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), 
libperl5.26 (>= 5.26.0~rc1), libstartup-notification0 (>= 0.2), libx11-6, 
libxft2 (>> 2.1.1), libxrender1, base-passwd (>= 2.0.3.4), ncurses-term (>= 
5.8-1)
| Recommends: fonts-dejavu, fonts-vlgothic | fonts-japanese-gothic
| Breaks: aterm (<< 1.0.1dummy), aterm-ml (<< 1.0.1dummy), rxvt (<< 
1:2.7.10-7.1~), rxvt-ml (<< 1:2.7.10-7.1~)
| Conflicts: rxvt-unicode-256color (<< 9.22-2), rxvt-unicode-lite (<< 9.22-2)
| Conffiles:
|  /etc/X11/app-defaults/URxvt 7b221a2da49507e31f42e702791b085b
| Description: RXVT-like terminal emulator with Unicode and 256-color support
|  rxvt-unicode is a modern, Unicode-aware color xterm replacement that uses
|  significantly less memory than a conventional xterm and many other Unicode
|  supporting terminal emulators.
|  .
|  It supports using multiple fonts at the same time, including Xft fonts, and
|  client-server technology to reduce memory consumption when using multiple
|  windows.
|  .
|  This package is configured with 256-color support, and TERM set to
|  "rxvt-unicode-256color". Any other systems you log into must have this
|  terminfo entry installed!
| Homepage: http://software.schmorp.de/pkg/rxvt-unicode.html
| 
| Package: rxvt-unicode-256color
| Status: deinstall ok config-files
| Priority: optional
| Section: x11
| Installed-Size: 62
| Maintainer: Ryan Kavanagh 
| Architecture: all
| Source: rxvt-unicode
| Version: 9.22-2
| Config-Version: 9.22-2
| Depends: rxvt-unicode (>= 9.22-2)
| Conflicts: rxvt-unicode (<< 9.22-2)
| Conffiles:
|  /etc/X11/app-defaults/URxvt 7b221a2da49507e31f42e702791b085b obsolete
| Description: dummy transitional package for rxvt-unicode
|  This is a dummy transitional package transitioning rxvt-unicode-256color to
|  rxvt-unicode. It can safely be removed.
| Homepage: http://software.schmorp.de/pkg/rxvt-unicode.html
`

Cheers,
   Sven

Bug#883965: not fixed

[128]

Hi,

I don't think this has been fixed. I upgraded to version 1.8.10-1, restarted 
the system and checked whether the bug has been fixed. The editor still crashes.

Bug#886417: linux-source-4.9: Kernel sources do not compile

[Yves-Alexis Perez]

On Fri, 2018-01-05 at 17:08 +0100, Robert Senger wrote:
> Package: linux-source-4.9
> Version: 4.9.65-3+deb9u2
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> Dear Maintainer,
> 
> compilation of Kernel sources 4.9.65-3+deb9u2 fails:
> 
> [snip]
>   CC  arch/x86/mm/gup.o
>   CC  arch/x86/mm/setup_nx.o
>   CC  arch/x86/mm/tlb.o
> arch/x86/mm/tlb.c: In function ‘switch_mm_irqs_off’:
> arch/x86/mm/tlb.c:160:3: error: implicit declaration of function
> ‘load_new_mm_cr3’ [-Werror=implicit-function-declaration]
>load_new_mm_cr3(next->pgd);
>^~~
> cc1: some warnings being treated as errors

Hi,

this is a bit confusing. Are you trying to rebuild a kernel using the linux-
source-4.9 package with a custom config, or are you trying to rebuild the
src:linux package with no change at all?

If the former, could you provide the configuration you use? Can you also check
if upstream just-released 4.9.75 builds with that .config?

Regards,
-- 
Yves-Alexis

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

Bug#886401: evince: Evince does not start: Error in `evince': double free or corruption (fasttop)

[Geoffrey Ferrari]

Hi Jason,

Sorry, I think that's beyond my expertise - there is no installable
package for evince-dbgsym and several in the debug repository and I'm
not competent enough to build these packages from scratch.

Geoffrey

On 5 January 2018 at 15:57, Jason Crain  wrote:
> Control: tags -1 + moreinfo
>
> On Fri, Jan 05, 2018 at 11:48:21AM +, Geoffrey Ferrari wrote:
>>* What led up to the situation?
>> Trying to run evince from command line or from gnome desktop, without or
>> without a pdf file to view.
>>
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>> Tried executing "evince" from command line with no pdf file specified.
>>* What was the outcome of this action?
>>
>> The following error message is reported:
>> *** Error in `evince': double free or corruption (fasttop): 
>> 0x55884b31a380
>> ***
>
> Can you provide a backtrace with debug symbols?  You'll need to install
> at least evince-dbgsym, libevdocument3-4-dbgsym, libevview3-3-dbgsym,
> libglib2.0-0-dbgsym, libgtk-3-0-dbgsym, libpango-1.0-0-dbgsym,
> libpangoft2-1.0-0-dbgsym, libpangocairo-1.0-0-dbgsym,
> libfontconfig1-dbgsym, and libexpat1-dbgsym.
>
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
> describes how to enable the repo for the dbgsym packages.