Bug#909557: Please name network-manager hook more descriptively

[Josh Triplett]

Package: cloud-init
Version: 0.7.9-5
Severity: normal

cloud-init ships a file
/etc/NetworkManager/dispatcher.d/hook-network-manager , a very generic
name that doesn't give any indication of its source. Please consider
naming this file something with "cloud-init" in the name.

Bug#909556: Change gnome-ppp on gtk-ppp

[Alexey Loginov]

Package: gtk-ppp
Version: 3.0.0

Gtk-ppp was built and tested:
https://launchpad.net/~linuxonly/+archive/ubuntu/gtk+ppp/+packages

URL: https://sourceforge.net/projects/gtk-ppp/

You removed gnome-ppp, but did not imported gtk-ppp.

Bug#858868: firebird3.0: 3.0.1.32609.ds4-14 FTBFS on hppa

[Damyan Ivanov]

Control: tag -1 patch pending

-=| Damyan Ivanov, 25.09.2018 05:06:19 + |=-
> -=| John David Anglin, 24.09.2018 20:58:01 -0400 |=-
> > On 2018-07-07 7:13 PM, John David Anglin wrote:
> > > The attached patch fixes the build on hppa-linux.
> > Ping.
> 
> The new upstream snapshot (3.0.4.33054.ds4-1) seems to have built on 
> the third attempt.

Oh, no. This third attempt is with an additional patch :)

> I'll add the patch anyway (sorry for missing it in the last upload). 
> It is targetted at hppa, and should not have effect on other 
> architectures.

Upload will happen in a couple of minutes.

Bug#909555: debci: testing blocked after binary package removed from source

[Drew Parsons]

Source: debci
Severity: normal

debci appears to hang, i.e. stops scheduling tests for testing, after
a binary package is removed from a source package. I think this bug is
triggered if the package removed was the last binary independent
package.

The problem affects the transition of mshr into testing.
mshr 2018.1.0+dfsg1-2 passed tests in both testing and unstable.  But
that's on amd64.  mshr 2018.1.0+dfsg1-2 failed to build on i386 and
other 32 bit arches.

To help with the 32 bit build problems, I dropped the arch-independent
package mshr-demos, moving demos to python3-mshr.

Later versions of mshr continue to pass debci tests on unstable.  But
tests on testing remain frozen at 2018.1.0+dfsg1-2.

PTS reports "arch:all not built yet, autopkgtest delayed".  So debci
is waiting for a package (mshr-demos) which no longer exists.

I've filed bug#907513 to expunge all trace of mshr-demos.  But
nevertheless, I think it is a bug that debci hangs on a missing
package like this.

Drew

-- 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.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#909554: asterisk: CVE-2018-17281: Remote crash vulnerability in HTTP websocket upgrade

[Salvatore Bonaccorso]

Source: asterisk
Version: 1:13.22.0~dfsg-2
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for asterisk.

CVE-2018-17281[0]:
| There is a stack consumption vulnerability in the
| res_http_websocket.so module of Asterisk through 13.23.0, 14.7.x
| through 14.7.7, and 15.x through 15.6.0 and Certified Asterisk through
| 13.21-cert2. It allows an attacker to crash Asterisk via a specially
| crafted HTTP request to upgrade the connection to a websocket.

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-2018-17281
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17281
[1] http://downloads.asterisk.org/pub/security/AST-2018-009.html
[2] https://issues.asterisk.org/jira/browse/ASTERISK-28013

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#907513: blocking transition

[Drew Parsons]

severity 907513 important
retitle 907513 RM: mshr-demos -- ROM; no longer built; blocks transition
thanks

This bug is blocking transition of both mshr and fenics into testing, so 
bumping up the severity.

Bug#858868: firebird3.0: 3.0.1.32609.ds4-14 FTBFS on hppa

[Damyan Ivanov]

-=| John David Anglin, 24.09.2018 20:58:01 -0400 |=-
> On 2018-07-07 7:13 PM, John David Anglin wrote:
> > The attached patch fixes the build on hppa-linux.
> Ping.

The new upstream snapshot (3.0.4.33054.ds4-1) seems to have built on 
the third attempt.

https://buildd.debian.org/status/fetch.php?pkg=firebird3.0=hppa=3.0.4.33054.ds4-1=1537835637=0

It is strange that some times the build fails and some times it 
succeeds. I'll add the patch anyway (sorry for missing it in the last 
upload). It is targetted at hppa, and should not have effect on other 
architectures.

-- dam

Bug#909553: ubertooth: partially unused Build-Depends: python-all-dev?

[Helmut Grohne]

Source: ubertooth
Version: 2018.08.R1-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ubertooth fails to cross build from source, because its build dependency
on python-all-dev is not satisfiable. I looked, but couldn't find a
Python extension in ubertooth, so I guess the dependency is partially
unnecessary. I tried demoting it to python-all (without -dev). On amd64
that results in a successful build whose only differences are build-ids
(according to diffoscope). So it seems that indeed, python-all would be
sufficient. This doesn't make ubertooth cross buildable, but the way of
making it cross buildable is a bit different for these dependencies, so
can we sort that out first? Please consider applying the attached patch.

Helmut
diff --minimal -Nru ubertooth-2018.08.R1/debian/changelog 
ubertooth-2018.08.R1/debian/changelog
--- ubertooth-2018.08.R1/debian/changelog   2018-08-10 13:32:26.0 
+0200
+++ ubertooth-2018.08.R1/debian/changelog   2018-09-25 06:06:52.0 
+0200
@@ -1,3 +1,10 @@
+ubertooth (2018.08.R1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Demote Build-Depends: python-all-dev to python-all. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 25 Sep 2018 06:06:52 +0200
+
 ubertooth (2018.08.R1-2) unstable; urgency=medium
 
   * Move python-pyside.qtcore and python-pyside.qtgui from Depends to
diff --minimal -Nru ubertooth-2018.08.R1/debian/control 
ubertooth-2018.08.R1/debian/control
--- ubertooth-2018.08.R1/debian/control 2018-08-10 13:32:26.0 +0200
+++ ubertooth-2018.08.R1/debian/control 2018-09-25 06:06:52.0 +0200
@@ -9,7 +9,7 @@
pkg-config,
libbluetooth-dev,
libbtbb-dev (>= 2018.06.R1),
-   python-all-dev,
+   python-all,
txt2man
 Build-Depends-Indep: gcc-arm-none-eabi,
  libnewlib-arm-none-eabi,

Bug#909550: possible conflict over the /usr/bin/ia namespace

[Antoine Beaupré]

Hi,

TL;DR: new package from archive.org conflicts with existing `ia`
binary from python-duckduckgo2. Policy §10.1 consensus sought.

I'm in the process of packaging the Internet Archive (archive.org)
Python commandline client and that installs a client that is
conveniently called "ia" in /usr/bin. It's a simple wrapper around a
more elaborate Python library, but it allows a fairly complete set of
operations of the archive like searching, downloading, uploading and
deleting data.

Unfortunately, apt-file (is there a better way?) tells me that
python-duckduckgo2 already claimed that command namespace, along with
the ddg command, naturally.

I tried to figure out what the other package does: there's no
documentation in the Debian package, and neither command supports has
inline help or manpages. From what I can tell, the `ddg` command output
structured data from a DDG (DuckDuckGo.com) search and `ia` command does
a "feel lucky" type of request to output only one answer. This seems to
be somewhat related "Instant Answers" API (hence the `ia` acronym)
as defined here:

https://duckduckgo.com/api

So the situation falls directly under section 10.1 of the Policy:

https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries

> Two different packages must not install programs with different
> functionality but with the same filenames.

The solution proposed by the policy is to rename one or both of the
packages, after a discussion here:

> [...] try to find a consensus about which program will have to be
> renamed. If a consensus cannot be reached, both programs must be
> renamed.

Obviously, DDG has the upper hand right now: it's already passed new and
is in the archive. My "internetarchive" package is only at the ITP stage
(in CC) but it's fairly complete and would be ready for upload. Right
now it Conflicts with the DDG package, but that's not the best solution
- I would need to rename the commandline binary to respect policy, if I
understand it correctly. But before doing that, I want to give the
Internet Archive a chance.

As an argument for the archive, I would say its acronym is more commonly
known and used than DDG's, which I found out for the first time here and
never heard about before. Wikipedia agrees; in this disambiguiation
page, DDG is not listed at the time of writing, while the Archive is:

https://en.wikipedia.org/wiki/IA

The "snap" package `ia` also points to the archive's software:

https://snapcraft.io/ia

Same for FreeBSD and, as far as I can tell, Arch Linux.

I would therefore propose for the python-duckduckgo2 ia binary to be
renamed to ddg-ia, as its "ia" use is only secondary in the package's
purpose.

The alternative course of action would be to rename the ia binary in the
internetarchive package to "internetarchive" but that's rather long and
unusual: all upstream documentation refers to the `ia` binary and this
could confuse our users needlessly, especially since other platforms
also use the `ia` acronym to refer to the archive as well.

The source of the package is available here:

https://salsa.debian.org/python-team/modules/python-internetarchive

Progress in the packaging can be followed in the CC'd bug report.

With good faith and spirit, sorry for the long email and thanks for any
feedback!

A,

PS: there is, incidentally, also the question of how to name this
(source and binary!) package: python3-internetarchive, internetarchive
and ia would all be interesting names for various reasons. I would
prefer the latter, but it would obviously require the DDG side to rename
first to make any sense. The Debian Python policy on this is, as far as
I know, rather undecided right now, especially for packages like
internetarchive that mix libraries and commandline tools.

-- 
I'm no longer accepting the things I cannot change.
I'm changing the things I cannot accept.
- Angela Davis

Bug#770598: gperiodic: French localization

[Alexey Loginov]

gperiodic is fully translated in French by transifex and French will
be updated in new version.

Bug#909550: ITP: internetarchive -- python interface to archive.org)

[Antoine Beaupré]

Control: tags -1 +pending +patch

Progress on this package:

 * the debianized source is here:

   https://salsa.debian.org/python-team/modules/python-internetarchive

 * tests are disabled because they fail as the `ia` binary is missing
   after build (but not, presumably, install)

 * similarly, the Py2 build is disabled because it requires
   backports.csv which is not in Debian at the time of writing

 * the upstream doc is also not built in a -doc package - that can be
   added later. this means no manpage is available for the `ia` command,
   but that should be okay as our package name is
   "python3-internetarchive", ie. we behave as a library and the `ia`
   command is auxiliary (even though the latter is what I use the most).

I'm still unsure about the binary package name: it would be pretty cool
to call this binary `ia` since it does provide this awesome commandline
tool. Unfortunately, that namespace is claimed by the python-duckduckgo2
package, which we conflict with.

I'll sit on this a little longer then upload as it seems pretty complete.

A.

-- 
Les plus beaux chants sont les chants de revendications
Le vers doit faire l'amour dans la tête des populations.
À l'école de la poésie, on n'apprend pas: on se bat!
- Léo Ferré, "Préface"

Bug#909552: mark cl-abnf Multi-Arch: foreign

[Helmut Grohne]

Package: cl-abnf
Version: 20150608-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:pgloader

pgloader fails to cross build from source, because its build dependency
on cl-abnf is unsatisfiable. In general, Architecture: all packages such
as cl-abnf can never satisfy cross Build-Depends unless marked
Multi-Arch: foreign. In this case, such a marking is correct, because
cl-abnf essentially is a data package: It does not have any maintainer
scripts nor dependencies. It only ships lisp source files. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru cl-abnf-20150608/debian/changelog 
cl-abnf-20150608/debian/changelog
--- cl-abnf-20150608/debian/changelog   2015-07-15 15:44:24.0 +0200
+++ cl-abnf-20150608/debian/changelog   2018-09-25 05:38:11.0 +0200
@@ -1,3 +1,10 @@
+cl-abnf (20150608-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark cl-abnf Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 25 Sep 2018 05:38:11 +0200
+
 cl-abnf (20150608-1) unstable; urgency=medium
 
   * Quicklisp release update.
diff --minimal -Nru cl-abnf-20150608/debian/control 
cl-abnf-20150608/debian/control
--- cl-abnf-20150608/debian/control 2014-08-04 17:25:23.0 +0200
+++ cl-abnf-20150608/debian/control 2018-09-25 05:38:01.0 +0200
@@ -11,6 +11,7 @@
 
 Package: cl-abnf
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: Common Lisp ABNF parser generator
  The generated parser is a regular expression scanner provided by the

Bug#909551: qdirstat: Segfault immediately after choosing scan directory

[Ed Peguillan III]

Package: qdirstat
Version: 1.4-2
Severity: grave
Tags: a11y
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

   I installed qdirstat and launched it. It gave me a GTK(3?) prompt for
   choosing the directory I wish to scan. After choosing the directory
   and clicking "Open", it crashes. The message given when run from the
   terminal is "Segmentation fault". This happens when running
   with/without root privileges. Here is the log:

2018-09-24 22:36:10.956 [5046] Logger.cpp:143 openLogFile():  -- Log 
Start --
2018-09-24 22:36:10.956 [5046] main.cpp:44 logVersion():  
QDirStat-1.4 built with Qt 5.7.1
2018-09-24 22:36:11.070 [5046]DirTreeModel.cpp:549 sort():  Sorting 
by NameCol ascending
2018-09-24 22:36:11.070 [5046]TreemapView.cpp:124 
setSelectionModel():  
2018-09-24 22:36:11.071 [5046] Cleanup.cpp:415 desktopSpecificApps(): 
 Detected desktop "XFCE"
2018-09-24 22:36:11.071 [5046] Cleanup.cpp:468 desktopSpecificApps(): 
 %filemanager => "thunar"
2018-09-24 22:36:11.071 [5046] Cleanup.cpp:468 desktopSpecificApps(): 
 %terminal => "xfce4-terminal &"
2018-09-24 22:36:11.071 [5046]DebugHelpers.cpp:133 
dumpExcludeRules():  
2018-09-24 22:36:11.071 [5046] MainWindow.cpp:818 
toggleVerboseSelection():  Verbose selection is now off. Change this with 
Shift-F7.
2018-09-24 22:36:12.818 [5046] DirTree.cpp:95 startReading(): 
url: "/home/yankee"
2018-09-24 22:36:12.818 [5046] DirTree.cpp:98 startReading():  
device: /dev/sda5
2018-09-24 22:36:12.818 [5046]DirReadJob.cpp:349 stat():  url: 
"/home/yankee"
2018-09-24 22:36:12.818 [5046]MainWindow.cpp:589 
expandTreeToLevel():  Expanding tree to level 1
2018-09-24 22:36:12.835 [5046]DirReadJob.cpp:248 startReading():  
Found cache file .qdirstat.cache.gz
2018-09-24 22:36:12.836 [5046]DirReadJob.cpp:260 startReading():  
Using cache file /home/yankee/.qdirstat.cache.gz for /home/yankee
2018-09-24 22:36:12.836 [5046]DirReadJob.cpp:544 killAll():  NOT 
killing read job 
2018-09-24 22:36:12.836 [5046]DirReadJob.cpp:278 startReading():  
Deleting subtree /home/yankee
2018-09-24 22:36:12.836 [5046]DirTree.cpp:237 deletingChildNotify(): 
 Deleting child /home/yankee
2018-09-24 22:36:12.836 [5046]DirTreeModel.cpp:918 deletingChild():  
Deleting child /home/yankee
2018-09-24 22:36:12.836 [5046]DirTreeModel.cpp:926 deletingChild():  
beginRemoveRows for /home/yankee row 0
2018-09-24 22:36:12.836 [5046]DirTreeModel.cpp:984 
invalidatePersistent():  Invalidating 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I attempted to start and use qdirstat, but it crashed when selecting
a directory to scan.

   * What was the outcome of this action?

   It crashed.

   * What outcome did you expect instead?

   It should not crash.

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

Kernel: Linux 4.18.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)
LSM: AppArmor: enabled

Versions of packages qdirstat depends on:
ii  libc62.27-6
ii  libgcc1  1:8.2.0-7
ii  libgl1   1.1.0-1
ii  libgl1-mesa-glx  18.1.7-1
ii  libqt5core5a 5.11.1+dfsg-8
ii  libqt5gui5   5.11.1+dfsg-8
ii  libqt5widgets5   5.11.1+dfsg-8
ii  libstdc++6   8.2.0-7
ii  liburi-perl  1.74-1
ii  perl 5.26.2-7
ii  zlib1g   1:1.2.11.dfsg-1

qdirstat recommends no packages.

qdirstat suggests no packages.

-- no debconf information

Bug#909522: emacs-goodies-el: questionable Depends/Recommends

[Nicholas D Steeves]

Hello!

On Mon, Sep 24, 2018 at 07:55:41PM +0200, Sven Joachim wrote:
> 
> There are several dependencies/recommendations in emacs-goodies-el which
> look questionable to me.
> 
> - elpa-debian-el, elpa-dpkg-dev-el, elpa-devscripts:
>   Those packages are the successors of debian-el, dpkg-dev-el and
>   devscripts-el which used to be built from the emacs-goodies-el source
>   package.  But the emacs-goodies-el _binary_ package in Stretch did not
>   depend on those, so why have these dependencies be introduced now?

I'm not sure.  David, 'git blame' says you're the one to ask.  Maybe
these could be downgraded to suggests in the next release?

My apologies for upgrading them to hard Depends.  You're absolutely
right Sven, they shouldn't be introduced as hard deps now.

> - bash (>= 2.05a) | bash-static, dpkg (>= 1.15.4) | install-info:
>   This seems to be (harmless) cruft that should be removed.
>
> - wget, perl-doc (both in Recommends):
>   Probably useless for the few lisp files still shipped in
>   emacs-goodies-el.  I think perl-doc was recommended because perldoc.el
>   needed it, don't really know why wget was put into Recommends.
> 

I had been waiting to do this until goodies had become a dummy
transitional package (hopefully 42.0 can be the last version :-p), but
yes, I'm happy to remove deps that are no longer required for 41.x
releases.

Policy 3.9.5 and compat 9 are new enough that we probably don't need
to worry about dpkg or install-info.  Bash seems to have been there
for the devscripts package so I'll remove it right now.  As for wget?
It was there for debbugs-el and dpkg-dev-el, so it is also safe to
remove now.  The two sets from the above quoted section have been
fixed in git.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#909549: cannot download... None details from PyPI: ContentTypeError

[Antoine Beaupré]

Control: tag -1 +patch +pending +upstream
Workaround:

PYPI_JSON_URL=https://pypi.org/pypi PYPI_XMLRPC_URL=https://pypi.org/pypi 
py2dsp  internetarchive

... which confirms this is probably fixed upstream.

A.

-- 
C'est avec les pierres de la loi qu'on a bâti les prisons,
et avec les briques de la religion, les bordels.
- William Blake

Bug#909550: ITP: internetarchive -- python interface to archive.org

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 
X-Debbugs-CC: debian-pyt...@lists.debian.org

* Package name: internetarchive
  Version : 1.8.1
  Upstream Author : Jacob M. Johnson 
* URL : https://github.com/jjjake/internetarchive
* License : AGPL 3
  Programming Lang: Python
  Description : python interface to archive.org

Command-line tool (`ia`) and Python library for searching, downloading
and uploading content to the Internet Archive.

--

Binary package names: python3-internetarchive python-internetarchive 
internetarchive

Unsure about those package names: I wonder if the libraries should be
separate from the main binary, although the latter is really just a
wrapper for the former.

Upstream documentation is available at:

https://archive.org/services/docs/api/internetarchive/

I've tested the package as installed by pip and it seems to work well.
py2dsp seems to work as well and was used to generate this email.

Can (should?) be maintained under the PAPT (or DPMT?) umbrella.


signature.asc
Description: PGP signature

Bug#909355: mirrors: Please, check Debian onion repositories. Most of them are "down".

[Paul Wise]

On Mon, 2018-09-24 at 11:53 +0200, Julien Cristau wrote:

> From what I understand this was due to an incompatibility between tor
> 0.3.4.8 and onionbalance 0.1.6
> (https://trac.torproject.org/projects/tor/ticket/27826) and has been
> worked around for now.

It turned out to be an issue in Tor 0.3.4.8, I worked around it:

https://trac.torproject.org/projects/tor/ticket/27849
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/commit/facf99b763703b445104beca01375a6472a5286e

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#909549: cannot download... None details from PyPI: ContentTypeError

[Antoine Beaupre]

Package: pypi2deb
Version: 2.20180318
Severity: grave
File: /usr/share/pypi2deb/py2dsp

Running py2dsp on Debian buster completely fails in my tests right
now:

$ py2dsp  internetarchive
W: py2dsp pypi:54: cannot download internetarchive None details from PyPI: 
ContentTypeError("0, message='Attempt to decode JSON with unexpected mimetype: 
text/html; charset=utf-8'",)
E: py2dsp py2dsp:57: invalid name: internetarchive
$ py2dsp  jinja2
W: py2dsp pypi:54: cannot download jinja2 None details from PyPI: 
ContentTypeError("0, message='Attempt to decode JSON with unexpected mimetype: 
text/html; charset=utf-8'",)
E: py2dsp py2dsp:57: invalid name: jinja2

The justification for the severity is the "unusable by most or all
users".

I suspect this is because of changes on PyPI's side. In fact, I
believe this might be fixed upstream: the GitHub repo has a newer
version but it is not in Debian right now.

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

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

Versions of packages pypi2deb depends on:
ii  build-essential  12.5
ii  devscripts   2.18.4
ii  dh-python3.20180723
ii  python3  3.6.5-3
ii  python3-aiohttp  3.1.3-1
ii  python3-debian   0.1.33
ii  python3-jinja2   2.10-1
ii  python3-redis2.10.6-4

Versions of packages pypi2deb recommends:
ii  python3-msgpack  0.5.6-1+b1

Versions of packages pypi2deb suggests:
pn  cython  
ii  cython3 0.28.4-1
ii  pypy6.0.0+dfsg-1
ii  python-all-dev  2.7.15-3
pn  python-nose 
ii  python-pytest   3.6.4-1
ii  python-setuptools   40.2.0-1
pn  python3-all-dev 
pn  python3-nose
ii  python3-pytest  3.6.4-1
ii  python3-setuptools  40.2.0-1
ii  python3-sphinx  1.7.9-1

-- no debconf information

Bug#909482: [Pkg-rust-maintainers] Bug#909482: rustc: FTBFS on mips64el on buildds: timeout

[Ximin Luo]

Control: reassign -1 src:rustc
Control: forcemerge 881845 -1

Ximin Luo:
> Control: forcemerge 881845 -1
> 
> Yes, we're aware, see the discussion in #881845. The issue is some mips CPUs 
> are (allegedly) buggy and so a porter with access to the allegedly non-buggy 
> ones have been doing manual builds.
> 
> I let this situation continue but would also be happy to just RM rustc 
> mips64el for the time being, to avoid blocking migration to Debian Testing to 
> the other bugs.
> 
> If nobody builds mips64el in the next few days I will go ahead and request RM 
> by FTP masters.
> 
> X
> 
> Ivo De Decker:
>> package: rustc
>> version: 1.28.0+dfsg1-2
>> severity: serious
>> tags: ftbfs
>>
>> Hi,
>>
>> The builds of rustc in sid on mips64el consistently fail on the buildds:
>>
>> https://buildd.debian.org/status/logs.php?pkg=rustc=mips64el
>>
>> Most of the fail with
>>
>> "Build killed with signal TERM after 150 minutes of inactivity"
>>
>> If the build is actually still going at that point, it should produce output
>> to avoid being killed.
>>
>> The builds that are in the archive seem to be manual builds that were
>> uploaded.
>>
>> Cheers,
>>
>> Ivo
>>
-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#909548: mk-build-deps: Please support generating a control file without building the package

[Josh Triplett]

Package: devscripts
Version: 2.18.4
Severity: wishlist
File: /usr/bin/mk-build-deps

Sometimes, I'd like to edit the control file before building the
build-dependencies package. I'd love to have an option to print the
control file to stdout. I could then edit it and run equivs-build.

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-6
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7
ii  python3   3.6.6-1
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.7.0~rc2
pn  at  
ii  curl7.61.0-1
ii  dctrl-tools 2.24-2+b1
pn  debian-keyring  
ii  dput1.0.2
ii  equivs  2.1.0
ii  fakeroot1.23-1
ii  file1:5.34-2
ii  gnupg   2.2.10-1
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
pn  libstring-shellquote-perl   
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.35-2
pn  licensecheck
ii  lintian 2.5.105
ii  man-db  2.8.4-2
ii  patch   2.7.6-3
ii  patchutils  0.3.4-2
ii  python3-apt 1.7.0~rc1
ii  python3-debian  0.1.33
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.18.4-2
pn  python3-unidiff 
ii  python3-xdg 0.25-4
ii  strace  4.21-1
ii  unzip   6.0-21
pn  wdiff   
ii  wget1.19.5-2
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
pn  bsd-mailx | mailx
ii  build-essential  12.5
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.2.2+dfsg1-2
ii  gnuplot-qt [gnuplot] 5.2.2+dfsg1-2
ii  gpgv 2.2.10-1
pn  how-can-i-help   
pn  libauthen-sasl-perl  
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
ii  mutt 1.10.1-2
ii  openssh-client [ssh-client]  1:7.8p1-1
pn  piuparts 
pn  postgresql-client
ii  quilt0.65-2
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information

Bug#909547: mk-build-deps: Please support an --exclude option

[Josh Triplett]

Package: devscripts
Version: 2.18.4
Severity: wishlist
File: /usr/bin/mk-build-deps

Sometimes, I'd like to install *most* of a package's build dependencies,
but not all of them. For instance, the package might have a large build
dependency needed to run one obscure test in its testsuite, but it
builds fine without that package installed.

Please consider providing an --exclude option to exclude a
build-dependency from the build-dependencies package by name.

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-6
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7
ii  python3   3.6.6-1
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.7.0~rc2
pn  at  
ii  curl7.61.0-1
ii  dctrl-tools 2.24-2+b1
pn  debian-keyring  
ii  dput1.0.2
ii  equivs  2.1.0
ii  fakeroot1.23-1
ii  file1:5.34-2
ii  gnupg   2.2.10-1
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
pn  libstring-shellquote-perl   
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.35-2
pn  licensecheck
ii  lintian 2.5.105
ii  man-db  2.8.4-2
ii  patch   2.7.6-3
ii  patchutils  0.3.4-2
ii  python3-apt 1.7.0~rc1
ii  python3-debian  0.1.33
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.18.4-2
pn  python3-unidiff 
ii  python3-xdg 0.25-4
ii  strace  4.21-1
ii  unzip   6.0-21
pn  wdiff   
ii  wget1.19.5-2
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
pn  bsd-mailx | mailx
ii  build-essential  12.5
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.2.2+dfsg1-2
ii  gnuplot-qt [gnuplot] 5.2.2+dfsg1-2
ii  gpgv 2.2.10-1
pn  how-can-i-help   
pn  libauthen-sasl-perl  
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
ii  mutt 1.10.1-2
ii  openssh-client [ssh-client]  1:7.8p1-1
pn  piuparts 
pn  postgresql-client
ii  quilt0.65-2
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information

Bug#909546: O: etcd-fs -- FUSE client for etcd

[Dmitry Smirnov]

Package: wnpp
Severity: normal
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 etcd-fs

This package needs new maintainer...
"etcd-fs" is an awesome addition to "ectd" which I no longer use...

-- 
Regards,
 Dmitry Smirnov.


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

Bug#904834: Thunderbird doesn't opens links

[Jiri Kanicky]

Hi.

I believe I found a workaround.

 1. Delete handlers.json file from the Thunderbird profile.
 2. Restart Thunderbird.
 3. Click on http link -> you will get offer which app you want to open
the link with. As I use Debian, I select other and use
/etc/alternatives/x-www-browser
 4. Click on https link -> you will get offer which app you want to open
the link with. As I use Debian, I select other and use
/etc/alternatives/x-www-browser
 5. Should work again.

Jiri


On 12/9/18 8:02 pm, Jiri Kanicky wrote:
>
> Hi,
>
> I am experiencing the same problem. Its the same in safe mode.
>
> I experimented with options:
> *network.protocol-handler.warn-external.http
> **network.protocol-handler.warn-external.https*
>
> I was able to make links for http work, but I am not able to make
> https links work. The prompt "Launch Application" does not come up.
>
> What I noticed is that the Attachments in Preferences were empty
> despite there was something there before. After playing the the
> options above, i added http -> x-www-browser and that is working. But
> I am simply not able to add https.
>
> I am wondering if there is any way how to edit the attachments setting
> manually? Or is there any way to reset the attachments setting?
>
> -- 
>
> Jiri
>
>

Bug#909545: SSL CERTIFICATE_VERIFY_FAILED when using gs (Google Cloud Storage) backend.

[Witold Baryluk]

Package: python-boto
Version: 2.44.0-1
Severity: normal


Not sure if boto, or duplicity issue.


duplicity with GS was working fine for year or two, and started failing few 
weeks ago.

Now it takes few minutes on any command, and then errors out:

Cleaning older backups
Traceback (innermost last):
  File "/usr/bin/duplicity", line 1567, in 
with_tempdir(main)
  File "/usr/bin/duplicity", line 1553, in with_tempdir
fn()
  File "/usr/bin/duplicity", line 1392, in main
action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 1127, 
in ProcessCommandLine
globals.backend = backend.get_backend(args[0])
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 223, in 
get_backend
obj = get_backend_object(url_string)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 209, in 
get_backend_object
return factory(pu)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/_boto_single.py", 
line 166, in __init__
self.resetConnection()
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/_boto_single.py", 
line 191, in resetConnection
location=self.my_location)
  File "/usr/lib/python2.7/dist-packages/boto/gs/connection.py", line 95, in 
create_bucket
data=get_utf8_value(data))
  File "/usr/lib/python2.7/dist-packages/boto/s3/connection.py", line 668, in 
make_request
retry_handler=retry_handler
  File "/usr/lib/python2.7/dist-packages/boto/connection.py", line 1071, in 
make_request
retry_handler=retry_handler)
  File "/usr/lib/python2.7/dist-packages/boto/connection.py", line 1030, in 
_mexe
raise ex
 SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed 
(_ssl.c:726)



gsutil still works for me.

I have system certificates from Debian and they are updated afaik.




-- 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.18.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8), 
LANGUAGE=pl_PL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-boto depends on:
ii  python   2.7.15-3
ii  python-requests  2.18.4-2
ii  python-six   1.11.0-2

python-boto recommends no packages.

python-boto suggests no packages.

-- no debconf information

Bug#858868: firebird3.0: 3.0.1.32609.ds4-14 FTBFS on hppa

[John David Anglin]

On 2018-07-07 7:13 PM, John David Anglin wrote:

The attached patch fixes the build on hppa-linux.

Ping.

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

Bug#905977: kea-ctrl-agent: missing dependency on python3

[Jason Guy]

Thanks Adrian, I have made the changes to fix this, but I am running into
issues building the package. The odd part is the errors seem unrelated to
the changes. I just wanted to let you know I am working on it.




On Sun, Aug 12, 2018 at 1:58 PM, Adrian Bunk  wrote:

> Package: kea-ctrl-agent
> Version: 1.4.0.P1-3
> Severity: serious
>
> kea-ctrl-agent lacks a python3 dependency
> for /usr/sbin/kea-shell
>
> This can be fixed by adding dh-python to the build dependencies
> plus python3 to the "dh $@ --with" in debian/rules.
>

Bug#909544: Backport MKL 2019.0.117 to stretch

[Mo Zhou]

Package: intel-mkl
Version: 2019.0.117-1
Severity: wishlist

2019.0.117-1~bpo9+1

Bug#903163: [pkg-cryptsetup-devel] Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

[Guilhem Moulin]

On Mon, 24 Sep 2018 at 14:11:02 +0200, Peter Lebbing wrote:
> Well, the ultimate fail-safe migration mechanism is very
> straight-forward. Export to /etc/cryptsetup-initramfs/pubkey.gpg, and in
> the decrypt script, --import that first. I see you already use a
> default, empty homedir anyway, might as well just --import to that.

Ah yeah, I hadn't thought about this, but that's nice and foolproof
indeed, thanks!

> I do wonder why you ended up creating the homedir manually, doesn't
> GnuPG do that for you when it's the /default/ homedir? I can't just
> try it out and see myself, I don't have a Debian testing handy :-).
> Can build one, obviously.

It's created automatically indeed, but pre-creating it silences a
warning and I'm always afraid that adding `--quiet` would silence too
much.  (However I have no problem adding `--quiet` to `--import` since
public key management operations have less moving parts.  So with your
trick above the manual creation should be moot.)

> All the other issues but the trustdb issue are caused by the temporary
> homedir.

Oh, I misread you earlier in this thread and thought you were suggesting
/etc/cryptsetup-initramfs pubring by using the directory as temporary
homedir.  My bad, sorry.  Then shouldn't the following be enough, and
save a temporary file?

`| gpg --no-default-keyring --keyring … --trust-model=always --import`

I like your above trick better, though: the command to generate keyrings
is simpler, and not tied to a particular keyring format.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#872778: xterm -lc (with UTF-8 locale) cannot properly copy some utf-8 unicode chars

[積丹尼 Dan Jacobson]

T> Then this item can be closed.  I think you had in mind something like #578825

Well I read that but I still don't know the workaround that will show
U+9109 etc. super common characters in xterm.

Bug#909543: unattended-upgrades: should not depend on python3-cairo and other graphical packages via python3-gi

[Antoine Amarilli]

Package: unattended-upgrades
Version: 1.5
Severity: wishlist

Dear Maintainer,

unattended-upgrades depends on python3-gi which depends on python3-cairo. This
is annoying because, on headless machines, it means that installing
unattended-upgrades will install libcairo2 and other graphical stuff as a
dependency.

The reason why unattended-upgrades depends on python3-gi seems to be because
unattended-upgrades uses it to check whether the current network connection is
metered, and avoid performing the upgrades in that case.

A simple solution would be instead to change the code to work if python3-gi is
not installed (by assuming that the current network connection is not metered),
and change python3-gi to be a Recommends of unattended-upgrades rather than a
Depends. This would intuitively sense because metered connections are usually
only an issue on desktop systems (not headless systems), where (one hopes)
python3-gi would be installed.

Alternatively, a better fix would be to see whether the check for a metered
connection couldn't be performed differently, without depending on python3-gi.

Best,

-- 
Antoine Amarilli


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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  gir1.2-glib-2.01.58.0-1
ii  lsb-base   9.20170808
ii  lsb-release9.20170808
ii  powermgmt-base 1.33
ii  python33.6.6-1
ii  python3-apt1.6.2
ii  python3-gi 3.30.1-1
ii  ucf3.0038
ii  xz-utils   5.2.2-1.3

Versions of packages unattended-upgrades recommends:
ii  cron [cron-daemon]  3.0pl1-130

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-1
ii  exim4-daemon-light [mail-transport-agent]  4.91-7
ii  needrestart3.3-1

-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed [not included]

-- debconf information excluded

Bug#909474: xterm: cannot copy to both CLIPBOARD and PRIMARY

[Thomas Dickey]

On Mon, Sep 24, 2018 at 01:37:27PM +0200, Thorsten Glaser wrote:
> Package: xterm
> Version: 337-1
> Severity: important

hmm - no.  This is "wishlist".

https://www.debian.org/Bugs/Developer#severities

for any feature request, and also for any bugs that are very difficult
to fix due to major design considerations.

> Tags: upstream
> 
> What passes as a “fix” for #901249 broke things in a different manner.
> I’m filing as a new bug instead of reopening, though, because the
> original report was “behaviour does not match documentation”, and this
> one is “behaviour does not match expectation, documentation silent”.

Actually the documentation as such is oriented to the primary selection,
and describes how you could use the clipboard instead of the primary
selection.  But using both at the same time was never intended (and
consequently there is no discussion of that in the manual).

Changing that would be a feature request.
 
> Same scenario as in #901249.
> 
> I have two words on the command line, “foo” and “bar”.
> 
> I wish to have “foo” in CLIPBOARD and “bar” in PRIMARY.

I was reminded of this, which may be useful.

   keepClipboard (class KeepClipboard)
   Specifies whether xterm-dev will reuse the selection data which
   it copied to the keyboard rather than asking the clipboard for
   its current contents when told to provide the selection.  The
   default is “false”.
 
For either primary or clipboard, xterm has only one source-buffer which
it uses to satisfy requests for selection content.  That's been the case
"forever" (~1990).  Since the previous bug report would inevitably lead
to complaints that they were the same content (or that selections were
"lost"), I did this

ensure that only one of PRIMARY and CLIPBOARD is owned by xterm at a
given time (Debian #901249).

> I select “foo” with Shift. Now I can paste it with ^V in
> a GUI application, but not with middle-click. Okaaay…

Middle-mouse pastes the primary OR clipboard selection for me
(using my test-package for #337 on Debian/testing).
 
> Then I select “bar” without Shift. I can paste it with
> middle-click, but ^V does not paste “foo” any more.
> 
> Then I select “foo” with Shift again. Now middle-click
> is dead again.
> 
> This is *not* why I have multiple clipboards in X11 and
> go through pains of mapping them distinctly in xterm!

so... what exactly are the points to consider in a feature request?
I can think of a lot of possibilities :-)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#909328: More information and new backtrace

[Bernhard Übelacker]

Hello all,
in my first attempt I assumed this happens with xorg.

In this attempt I could reproduce the issue within a
gnome wayland session inside a amd64 buster VM.

As far as I see for both terminals there is just one
process gnome-terminal-server - therefore if that fails
both windows disappear.

In "journalctl -f" appears following:
gnome-shell[4936]: Could not import pending buffer: Failed to create 
texture 2d due to size/format constraints
gnome-shell[4936]: WL: error in client communication (pid 5736)
gnome-terminal-[5736]: Error 71 (Protokollfehler) dispatching to Wayland 
display.

This I assume is kind of a "clean" shutdown of the gnome-terminal-server 
process.
An attached debugger does not trap.


Because of the terminal disasspearing the vim process receives now
following signals:

Program received signal SIGHUP, Hangup.
Program received signal SIGCONT, Continued.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGABRT, Aborted.
Program received signal SIGSEGV, Segmentation fault.
Program terminated with signal SIGSEGV, Segmentation fault.

A core dump recorded by systemd-coredump shows just the last SIGSEGV.
See attached file for the stacks on each signal.

So I assume there are really two problems:

- gnome-terminal-server requests some situation that gnome-shell could not 
deliver,
  therefore it should possibly avoid such a request.

- vim seems to have a problem to handle SIGHUPs while currently reacting to 
user input.
  Sending a SIGHUP while vim is idle does not produce a SIGSEGV.
  Also I thought inside a signal handler should be done just the absolute 
necessary,
  at least stdio/printf or malloc is forbidden - does this apply to sprintf too?

Kind regards,
Bernhard

apt update
apt install mc htop weston systemd-coredump strace valgrind gdb debian-goodies 
lz4 dpkg-dev devscripts tmux vim gnome-session gnome-terminal

systemctl start gdm3


mkdir vim/orig -p
cdvim/orig
apt source vim
cd ../..


mkdir ncurses/orig -p
cdncurses/orig
apt source ncurses
cd ../..


mkdir libc6/orig -p
cdlibc6/orig
apt source libc6
cd ../..


# login

# open terminal
# open second terminal


root@debian:~# ps aux | grep -i gnome-term
benutzer  5736  1.7  1.3 407636 42924 tty2 Sl+  22:53   0:00 
/usr/lib/gnome-terminal/gnome-terminal-server


vim test.txt
set lines=999

Sep 24 22:54:39 debian gnome-shell[4936]: Could not import pending buffer: 
Failed to create texture 2d due to size/format constraints
Sep 24 22:54:39 debian gnome-shell[4936]: WL: error in client communication 
(pid 5736)
Sep 24 22:54:39 debian gnome-terminal-[5736]: Error 71 (Protokollfehler) 
dispatching to Wayland display.
Sep 24 22:54:39 debian systemd[1]: Started Process Core Dump (PID 5777/UID 0).
Sep 24 22:54:39 debian systemd-coredump[5778]: Process 5776 (vim) of user 1000 
dumped core.
   
   Stack trace of thread 5776:
   #0  0x7effd8d5a717 
tcache_get (libc.so.6)
   #1  0x7effd8d45bbb 
__fopen_internal (libc.so.6)
   #2  0x56262a4b8c29 n/a 
(vim.basic)
   #3  0x56262a62cfec n/a 
(vim.basic)
   #4  0x56262a56964b n/a 
(vim.basic)
   #5  0x7effd8d0cfc0 
__restore_rt (libc.so.6)
   #6  0x7effd8d0cf3b 
__GI_raise (libc.so.6)
   #7  0x7effd8d0e2f1 
__GI_abort (libc.so.6)
   #8  0x7effd8d4f867 
__libc_message (libc.so.6)
   #9  0x7effd8d55e0a 
malloc_printerr (libc.so.6)
   #10 0x7effd8d5636c 
munmap_chunk (libc.so.6)
   #11 0x7effd8d45ca2 
__fopen_internal (libc.so.6)
   #12 0x56262a4b8c29 n/a 
(vim.basic)
   #13 0x56262a62cfec n/a 
(vim.basic)
   #14 0x7effd8d0cfc0 
__restore_rt (libc.so.6)
   #15 0x7effd8d25356 
_IO_vfprintf_internal (libc.so.6)
   #16 0x7effd8ddd94f 
___vsprintf_chk (libc.so.6)



cat 
/var/lib/systemd/coredump/core.vim.1000.64142658a3b9454598e120cd13728d3c.5776.153782247900.lz4
 | unlz4 > /tmp/core.5776

root@debian:~# find-dbgsym-packages /tmp/core.5776
libacl1-dbgsym libattr1-dbgsym libgpm2-dbgsym libpcre3-dbg libselinux1-dbgsym 
libtinfo6-dbg vim-dbgsym

apt install libacl1-dbgsym libattr1-dbgsym libgpm2-dbgsym libpcre3-dbg 
libselinux1-dbgsym libtinfo6-dbg 

Bug#909514: hub: Incomplete debian/copyright?

[Anthony Fok]

Hi Chris,

On Mon, Sep 24, 2018 at 11:04 AM Chris Lamb  wrote:
>
> Source: hub
> Version: 2.4.0~ds1-1
> Severity: normal
> X-Debbugs-CC: Anthony Fok , ftpmas...@debian.org
>
> Hi,
>
> I just ACCEPTed hub from NEW but noticed it was missing attribution
> in debian/copyright in the sense that it does not cover that this is
> a Go rewrite of some existing software.

Thank you so much for reviewing the "hub" package.
I have added a Comment section explaining the copyright information
of the original Ruby implementation (Hub v1) and the new Go rewrite (v2),
and, on second thought, added "2013 Jingwen Owen Ou" to the Copyright
field too.  See

https://salsa.debian.org/go-team/packages/hub/commit/312d8e849cb57206acb4f99287859e3770f8877a

for the commit that fixes this issue.  Please let me know that's the
appropriate way for attribution, or whether I should make other
changes.
(Feel free to re-open this bug if necessary.)

Thanks again!

Anthony

Bug#909542: opam: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Package: src:opam
Version: 2.0.0-4
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules binary-indep
dh binary-indep --with ocaml
   dh_testdir -i
   dh_update_autotools_config -i
   dh_autoreconf -i
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' 
-o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec 
md5sum {} + -o -type l -printf "symlink  %p
" > debian/autoreconf.before
grep -q ^XDT_ configure.ac
autoreconf -f -i
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' 
-o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec 
md5sum {} + -o -type l -printf "symlink  %p
" > debian/autoreconf.after
   dh_ocamlinit -i
touch ocamlinit-stamp
   debian/rules override_dh_auto_configure

[... snipped ...]

   dh_perl -i
   dh_usrlocal -i
   dh_link -i
   dh_installwm -i
   dh_installxfonts -i
   dh_strip_nondeterminism -i
rm -f debian/opam-docs.debhelper.log
   debian/rules override_dh_compress
make[1]: Entering directory '/<>'
dh_compress -X.pdf
cd debian/opam-docs
chmod a-x usr/share/doc/opam-docs/README.md 
usr/share/doc/opam-docs/changelog usr/share/doc/opam-docs/changelog.Debian 
usr/share/man/man1/opam-admin-cache.1 usr/share/man/man1/opam-admin-filter.1 
usr/share/man/man1/opam-admin-index.1 usr/share/man/man1/opam-admin-lint.1 
usr/share/man/man1/opam-admin-list.1 usr/share/man/man1/opam-admin-upgrade.1 
usr/share/man/man1/opam-admin.1 usr/share/man/man1/opam-clean.1 
usr/share/man/man1/opam-config.1 usr/share/man/man1/opam-env.1 
usr/share/man/man1/opam-exec.1 usr/share/man/man1/opam-help.1 
usr/share/man/man1/opam-info.1 usr/share/man/man1/opam-init.1 
usr/share/man/man1/opam-install.1 usr/share/man/man1/opam-lint.1 
usr/share/man/man1/opam-list.1 usr/share/man/man1/opam-pin.1 
usr/share/man/man1/opam-reinstall.1 usr/share/man/man1/opam-remote.1 
usr/share/man/man1/opam-remove.1 usr/share/man/man1/opam-repository.1 
usr/share/man/man1/opam-search.1 usr/share/man/man1/opam-show.1 
usr/share/man/man1/opam-source.1 usr/share/man/man1/opam-switch.1 usr
 /share/man/man1/opam-uninstall.1 usr/share/man/man1/opam-unpin.1 
usr/share/man/man1/opam-update.1 usr/share/man/man1/opam-upgrade.1 
usr/share/man/man1/opam-var.1 usr/share/man/man1/opam.1
gzip -9nf usr/share/doc/opam-docs/README.md 
usr/share/doc/opam-docs/changelog usr/share/doc/opam-docs/changelog.Debian 
usr/share/man/man1/opam-admin-cache.1 usr/share/man/man1/opam-admin-filter.1 
usr/share/man/man1/opam-admin-index.1 usr/share/man/man1/opam-admin-lint.1 
usr/share/man/man1/opam-admin-list.1 usr/share/man/man1/opam-admin-upgrade.1 
usr/share/man/man1/opam-admin.1 usr/share/man/man1/opam-clean.1 
usr/share/man/man1/opam-config.1 usr/share/man/man1/opam-env.1 
usr/share/man/man1/opam-exec.1 usr/share/man/man1/opam-help.1 
usr/share/man/man1/opam-info.1 usr/share/man/man1/opam-init.1 
usr/share/man/man1/opam-install.1 usr/share/man/man1/opam-lint.1 
usr/share/man/man1/opam-list.1 usr/share/man/man1/opam-pin.1 
usr/share/man/man1/opam-reinstall.1 usr/share/man/man1/opam-remote.1 
usr/share/man/man1/opam-remove.1 usr/share/man/man1/opam-repository.1 
usr/share/man/man1/opam-search.1 usr/share/man/man1/opam-show.1 
usr/share/man/man1/opam-source.1 usr/share/man/man1/opam-switch.1 usr
 /share/man/man1/opam-uninstall.1 usr/share/man/man1/opam-unpin.1 
usr/share/man/man1/opam-update.1 usr/share/man/man1/opam-upgrade.1 
usr/share/man/man1/opam-var.1 usr/share/man/man1/opam.1
cd '/<>'
make[1]: Leaving directory '/<>'
   dh_fixperms -i
find debian/opam-docs ! -type l -a -true -a -true -print0 2>/dev/null | 
xargs -0r chmod go=rX,u+rw,a-s
find debian/opam-docs/usr/share/doc -type f -a -true -a ! -regex 
'debian/opam-docs/usr/share/doc/[^/]*/examples/.*' -print0 2>/dev/null | xargs 
-0r chmod 0644
find debian/opam-docs/usr/share/doc -type d -a -true -a -true -print0 
2>/dev/null | xargs -0r chmod 0755
find debian/opam-docs/usr/share/man -type f -a -true -a -true -print0 
2>/dev/null | xargs -0r chmod 0644
find debian/opam-docs -type f \( -name '*.so.*' -o -name '*.so' -o 
-name '*.la' -o -name '*.a' -o -name '*.js' -o -name '*.css' -o -name '*.scss' 
-o -name '*.sass' -o -name '*.jpeg' -o -name '*.jpg' -o -name '*.png' -o -name 
'*.gif' -o -name '*.cmxs' \) -a -true -a -true -print0 2>/dev/null | xargs -0r 
chmod 0644
rm -f debian/opam-docs.debhelper.log
   debian/rules override_dh_missing
make[1]: Entering directory '/<>'
dh_missing --fail-missing
dh_missing: usr/doc/opam-installer/CHANGES exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/doc/opam-installer/README.md exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/doc/opam-installer/LICENSE exists in 

Bug#909541: .uuid files cause dpkg: warnings upon attempted package removal

[積丹尼 Dan Jacobson]

Package: fonts-font-awesome
Version: 5.0.10+really4.7.0~dfsg-1

Removing fonts-font-awesome (5.0.10+really4.7.0~dfsg-1) ...
dpkg: warning: while removing fonts-font-awesome, directory 
'/usr/share/fonts/woff/font-awesome' not empty so not removed
dpkg: warning: while removing fonts-font-awesome, directory 
'/usr/share/fonts/truetype/font-awesome' not empty so not removed
dpkg: warning: while removing fonts-font-awesome, directory 
'/usr/share/fonts/svg/font-awesome' not empty so not removed
dpkg: warning: while removing fonts-font-awesome, directory 
'/usr/share/fonts/opentype/font-awesome' not empty so not removed
dpkg: warning: while removing fonts-font-awesome, directory 
'/usr/share/fonts/eot/font-awesome' not empty so not removed

$ find /usr/share/fonts/ -type f -mtime -1
/usr/share/fonts/woff/.uuid
/usr/share/fonts/woff/font-awesome/.uuid
/usr/share/fonts/opentype/.uuid
/usr/share/fonts/opentype/font-awesome/.uuid
/usr/share/fonts/eot/.uuid
/usr/share/fonts/eot/font-awesome/.uuid
/usr/share/fonts/truetype/font-awesome/.uuid
/usr/share/fonts/svg/.uuid
/usr/share/fonts/svg/font-awesome/.uuid

Bug#909540: tomcat8: ignores umask, sudden(?) regression

[Markus Koschany]

Hi,

Am 24.09.18 um 23:54 schrieb Thorsten Glaser:
> Package: tomcat8
> Version: 8.5.14-1+deb9u3
> Severity: important
[...]
> Apparently, umask is not (no longer?) honoured. On a jessie box:
[...]

I guess it would help to check the previous version of Tomcat 8 in
Jessie again. If you think this version works as expected, then there
_might_ be a regression in the latest security update. I suggest to
contact Roberto, the last uploader, in this case too because he is most
likely able to clarify this behavior. Tomcat7 and Tomcat8 do not
necessarily have to behave identically.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#909540: tomcat8: ignores umask, sudden(?) regression

[Thorsten Glaser]

Package: tomcat8
Version: 8.5.14-1+deb9u3
Severity: important

I have “umask 002” at the end of my /etc/defaults/tomcat8 file.

root@foo-demo:~ # ls -l /var/lib/tomcat8/webapps/
total 96648
drwxr-xr-x 3 tomcat8 tomcat8 4096 Jul  4 15:45 ROOT
drwxr-x--- 4 tomcat8 tomcat8 4096 Sep 24 23:39 footool-importer
-rw-r--r-- 1 footool footool 40861327 Sep 24 23:37 footool-importer.war
drwxr-x--- 5 tomcat8 tomcat8 4096 Sep 24 23:39 footool-services
-rw-r--r-- 1 footool footool 58090741 Sep 24 23:38 footool-services.war

Apparently, umask is not (no longer?) honoured. On a jessie box:

root@foo-test:~ # ll /var/lib/tomcat7/webapps
total 96648
drwxr-xr-x 3 tomcat7 tomcat7 4096 Feb 23  2017 ROOT/
drwxrwxr-x 4 tomcat7 tomcat7 4096 Sep 24 22:27 footool-importer/
-rw-r--r-- 1 footool footool 40861191 Sep 24 22:26 footool-importer.war
drwxrwxr-x 5 tomcat7 tomcat7 4096 Sep 24 22:28 footool-services/
-rw-r--r-- 1 footool footool 58091138 Sep 24 22:26 footool-services.war
root@foo-test:~ # dpkg-query -W tomcat7
tomcat7 7.0.56-3+really7.0.90-1

The two systems are supposed to be set up mostly identically.
The umask is important because, as part of automated system
upgrades from Jenkins, the “footool” user executes the command
“rm -rf /var/lib/tomcat*/webapps/footool*” before installing the
new files (it has been added to the tomcat{7,8} group in order
to be able to do so).

I’m 80% certain that this tomcat8 not honouring umask any more
is new and that it used to work as the tomcat7/jessie system does.

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C.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 tomcat8 depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  lsb-base   9.20161125
ii  tomcat8-common 8.5.14-1+deb9u3
ii  ucf3.0036

Versions of packages tomcat8 recommends:
pn  authbind   
ii  libtcnative-1  1.2.12-2+deb9u1

Versions of packages tomcat8 suggests:
pn  tomcat8-admin 
pn  tomcat8-docs  
pn  tomcat8-examples  
pn  tomcat8-user  

-- Configuration Files:
/etc/tomcat8/catalina.properties changed:
package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.jasper.,org.apache.tomcat.
package.definition=sun.,java.,org.apache.catalina.,org.apache.coyote.,\
org.apache.jasper.,org.apache.naming.,org.apache.tomcat.
common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.base}/common/classes","${catalina.base}/common/*.jar","${catalina.home}/common/classes","${catalina.home}/common/*.jar"
server.loader="${catalina.base}/server/classes","${catalina.base}/server/*.jar","${catalina.home}/server/classes","${catalina.home}/server/*.jar"
shared.loader="${catalina.base}/shared/classes","${catalina.base}/shared/*.jar","${catalina.home}/shared/classes","${catalina.home}/shared/*.jar"
tomcat.util.scan.StandardJarScanFilter.jarsToSkip=\
javassist-*.jar,\
bootstrap.jar,commons-daemon.jar,tomcat-juli.jar,\
annotations-api.jar,el-api.jar,jsp-api.jar,servlet-api.jar,websocket-api.jar,\
jaspic-api.jar,\
catalina.jar,catalina-ant.jar,catalina-ha.jar,catalina-storeconfig.jar,\
catalina-tribes.jar,\
jasper.jar,jasper-el.jar,ecj-*.jar,\
tomcat-api.jar,tomcat-util.jar,tomcat-util-scan.jar,tomcat-coyote.jar,\
tomcat-dbcp.jar,tomcat-jni.jar,tomcat-websocket.jar,\
tomcat-i18n-en.jar,tomcat-i18n-es.jar,tomcat-i18n-fr.jar,tomcat-i18n-ja.jar,\
tomcat-juli-adapters.jar,catalina-jmx-remote.jar,catalina-ws.jar,\
tomcat-jdbc.jar,\
tools.jar,\
commons-beanutils*.jar,commons-codec*.jar,commons-collections*.jar,\
commons-dbcp*.jar,commons-digester*.jar,commons-fileupload*.jar,\
commons-httpclient*.jar,commons-io*.jar,commons-lang*.jar,commons-logging*.jar,\
commons-math*.jar,commons-pool*.jar,\
jstl.jar,taglibs-standard-spec-*.jar,\
geronimo-spec-jaxrpc*.jar,wsdl4j*.jar,\
ant.jar,ant-junit*.jar,aspectj*.jar,jmx.jar,h2*.jar,hibernate*.jar,httpclient*.jar,\
jmx-tools.jar,jta*.jar,log4j*.jar,mail*.jar,slf4j*.jar,\
xercesImpl.jar,xmlParserAPIs.jar,xml-apis.jar,\
junit.jar,junit-*.jar,hamcrest-*.jar,easymock-*.jar,cglib-*.jar,\
objenesis-*.jar,ant-launcher.jar,\
cobertura-*.jar,asm-*.jar,dom4j-*.jar,icu4j-*.jar,jaxen-*.jar,jdom-*.jar,\
jetty-*.jar,oro-*.jar,servlet-api-*.jar,tagsoup-*.jar,xmlParserAPIs-*.jar,\
xom-*.jar
tomcat.util.scan.StandardJarScanFilter.jarsToScan=\
log4j-web*.jar,log4j-taglib*.jar,log4javascript*.jar,slf4j-taglib*.jar
tomcat.util.buf.StringCache.byte.enabled=true

/etc/tomcat8/context.xml changed:






WEB-INF/web.xml
${catalina.base}/conf/web.xml





/etc/tomcat8/logging.properties changed:
handlers = 1catalina.org.apache.juli.AsyncFileHandler, 

Bug#840569: [Pkg-mozext-maintainers] Bug#840569: xul-ext-nosquint is dead, long live nosquint

[Moritz Mühlenhoff]

On Wed, Oct 12, 2016 at 11:23:32AM -1000, David Prévot wrote:
> Control: severity -1 serious
> 
> Le 12/10/2016 à 10:35, shirish शिरीष a écrit :
> > Source: nosquint
> > Version: 2.1.9-4
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > Nosquint is dead, please remove it
> 
> Then let’s use a proper RC-severity so it gets removed from Stretch. If
> someone wants to follow up and package something equivalent instead,
> please step up before the freeze (i.e., soon).

Noone followed up and packaged nosquint-plus for almost two years,
let's go ahead with removing it?

Cheers,
Moritz

Bug#906887: xul-ext-automatic-save-folder no longer works with firefox-esr 60

[Moritz Mühlenhoff]

On Tue, Aug 21, 2018 at 11:02:49PM +0300, Adrian Bunk wrote:
> Package: xul-ext-automatic-save-folder
> Version: 1.0.5~20140831-4
> Severity: serious
> 
> XUL addons are no longer supported. 

Per http://asf.mangaheart.org/closed.php the project is dead and
won't get fixed for Firefox > 57, so let's remove it from the archive.

Cheers,
Moritz

Bug#907258: Bug#907259: Bug#907258: Bug#907259: hiredis: New upstream "release" ?

[Tom Lee]

Works for me.

On Mon, Sep 24, 2018 at 2:21 PM Chris Lamb  wrote:

> Hi Tom,
>
> > So if you don't mind waiting a little longer to see where upstream
> hiredis
> > #609 lands that'd be awesome
>
> Mmm, although let's not wait too long. I've replied to the issue (which
> already has had one reply) so we'll see how it looks by this weekend...?
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#909539: dds: test failures on multiple Ubuntu architectures

[Jeremy Bicha]

Source: dds
Version: 2.9.0-4

dds has test failures on multiple Ubuntu architectures. Build logs can
be found by clicking the architecture at
https://launchpad.net/ubuntu/+source/dds/2.9.0-3

Build log excerpt


   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
ln -sf ../src/libdds.so.0 examples/libdds.so
/usr/bin/make -C examples -f Makefiles/Makefile_linux DealerPar
make[2]: Entering directory '/<>/examples'
g++ -O3 -flto -fopenmp -Wshadow -Wsign-conversion -pedantic -Wall
-Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy
-Wdisabled-optimization -Winit-self -Wlogical-op
-Wmissing-declarations -Wmissing-include-dirs -Wnoexcept
-Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wsign-promo
-Wstrict-null-sentinel -Wstrict-overflow=1 -Wswitch-default -Wundef
-Werror -Wno-unused -Wno-unknown-pragmas -Wno-long-long -Wno-format -c
hands.cpp -o hands.o
g++ -O3 -flto -fopenmp -Wshadow -Wsign-conversion -pedantic -Wall
-Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy
-Wdisabled-optimization -Winit-self -Wlogical-op
-Wmissing-declarations -Wmissing-include-dirs -Wnoexcept
-Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wsign-promo
-Wstrict-null-sentinel -Wstrict-overflow=1 -Wswitch-default -Wundef
-Werror -Wno-unused -Wno-unknown-pragmas -Wno-long-long -Wno-format -c
DealerPar.cpp -o DealerPar.o
g++ -O3 -flto -fopenmp -Wshadow -Wsign-conversion -pedantic -Wall
-Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy
-Wdisabled-optimization -Winit-self -Wlogical-op
-Wmissing-declarations -Wmissing-include-dirs -Wnoexcept
-Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wsign-promo
-Wstrict-null-sentinel -Wstrict-overflow=1 -Wswitch-default -Wundef
-Werror -Wno-unused -Wno-unknown-pragmas -Wno-long-long -Wno-format
hands.o DealerPar.o -L. -ldds -o DealerPar
make[2]: Leaving directory '/<>/examples'
LD_LIBRARY_PATH=src examples/DealerPar
Memory::GetPtr: 0 vs. 0


Thanks,
Jeremy Bicha

Bug#907258: Bug#907259: Bug#907258: Bug#907259: hiredis: New upstream "release" ?

[Chris Lamb]

Hi Tom,

> So if you don't mind waiting a little longer to see where upstream hiredis
> #609 lands that'd be awesome

Mmm, although let's not wait too long. I've replied to the issue (which
already has had one reply) so we'll see how it looks by this weekend...?


Best wishes,

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

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

[Witold Baryluk]

Package: emacs-common
Followup-For: Bug #907997

FYI


Preparing to unpack .../emacs-common_1%3a25.2+1-11_all.deb ...
Unpacking emacs-common (1:25.2+1-11) ...
dpkg: error processing archive 
/var/cache/apt/archives/emacs-common_1%3a25.2+1-11_all.deb (--unpack):
 trying to overwrite '/usr/share/emacs/25.2/etc/AUTHORS', which is also in 
package emacs25-common 25.2+1-6
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Selecting previously unselected package emacs-bin-common.
Preparing to unpack .../emacs-bin-common_1%3a25.2+1-11_amd64.deb ...
Unpacking emacs-bin-common (1:25.2+1-11) ...
dpkg: error processing archive 
/var/cache/apt/archives/emacs-bin-common_1%3a25.2+1-11_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/emacs/25.2/x86_64-linux-gnu/hexl', which is also 
in package emacs25-bin-common 25.2+1-6+b2
Selecting previously unselected package libmagickwand-6.q16-6:amd64.
Preparing to unpack .../libmagickwand-6.q16-6_8%3a6.9.10.8+dfsg-1_amd64.deb ...
Unpacking libmagickwand-6.q16-6:amd64 (8:6.9.10.8+dfsg-1) ...
Selecting previously unselected package emacs-gtk.
Preparing to unpack .../emacs-gtk_1%3a25.2+1-11_amd64.deb ...
Unpacking emacs-gtk (1:25.2+1-11) ...
dpkg: error processing archive 
/var/cache/apt/archives/emacs-gtk_1%3a25.2+1-11_amd64.deb (--unpack):
 trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in package 
emacs25 25.2+1-6+b2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack .../emacs23_1%3a25.2+1-11_all.deb ...
Remove latex-cjk-thai for emacs23
remove/latex-cjk-thai: purging byte-compiled files for emacs23
Remove latex-cjk-common for emacs23
remove/latex-cjk-common: purging byte-compiled files for emacs23
Remove systemtap-common for emacs23
remove/systemtap-common: Purging byte-compiled files for emacs23
Remove emacsen-common for emacs23
emacsen-common: Handling removal of emacsen flavor emacs23
Unpacking emacs23 (1:25.2+1-11) over (23.4+1-4.1+b1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/emacs-common_1%3a25.2+1-11_all.deb
 /var/cache/apt/archives/emacs-bin-common_1%3a25.2+1-11_amd64.deb
 /var/cache/apt/archives/emacs-gtk_1%3a25.2+1-11_amd64.deb
[ Rootkit Hunter version 1.4.6 ]
File updated: searched for 182 files, found 158
E: Sub-process /usr/bin/dpkg returned an error code (1)



-- 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.16.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs-common depends on:
ii  emacsen-common  2.0.8
it  install-info6.5.0.dfsg.1-4

Versions of packages emacs-common recommends:
pn  emacs-el  

Versions of packages emacs-common suggests:
pn  emacs-common-non-dfsg  
iu  ncurses-term   6.1+20180714-1

Bug#907258: Bug#907259: Bug#907258: Bug#907259: hiredis: New upstream "release" ?

[Tom Lee]

Back up and running again Chris, thanks for your patience!

After poking around in diffs between 0.13.3 and master for a bit, I raised
a ticket upstream to see if we can get a "real" release:
https://github.com/redis/hiredis/issues/609

I'd really prefer to see a real release than to go yanking from an
arbitrary SHA -- even if it is a relatively slow-moving code base. No doubt
as time goes on we can expect redis & hiredis to slowly diverge again, but
it would be nice to keep things sane for good citizens targeting a specific
version number.

So if you don't mind waiting a little longer to see where upstream hiredis
#609 lands that'd be awesome. On the other hand, if you're really desperate
for the phony release let me know & I'll figure it out.

Bug#909076: ghostscript: ps2ascii crashes: Error: /typecheck in --.bind--

[Salvatore Bonaccorso]

Hi

FTR, I tried to bisect the issue, by using commits between 9.20 and
9.21 upstream and applying on top each
fb713b3818b52d8a6cf62c951eba2e1795ff9624 . Due to a possibly unrelated
bug, some of the commits cause "empty" outputs, so I had to skip those
all. The resulting git bisect is

git bisect start '--term-old' 'broken' '--term-new' 'fixed'
# broken: [937efa62c23c2c79c7487895421041896e8c14b7] Fix previous JPEG commit.
git bisect broken 937efa62c23c2c79c7487895421041896e8c14b7
# fixed: [f80288c8a4b9c9abfc0fa3ccce3b6d169baa59ff] Dates for 9.21 release
git bisect fixed f80288c8a4b9c9abfc0fa3ccce3b6d169baa59ff
# fixed: [4d07b45685976bd38e5cec8062b3a61d2ada5575] Hide more JPEG entries.
git bisect fixed 4d07b45685976bd38e5cec8062b3a61d2ada5575
# fixed: [8894abf2985a58900e778957f93151b6cec1c17a] Address a segfault and 
error introduced in 4b3be09
git bisect fixed 8894abf2985a58900e778957f93151b6cec1c17a
# skip: [513d6fd7ddfc5a59fbf8bf6ce72eda6c97fea9f8] remove a bunch of now unused 
variables from the earlier shading code commit.
git bisect skip 513d6fd7ddfc5a59fbf8bf6ce72eda6c97fea9f8
# skip: [336c69b8be32c7193909a7f25b1a073b0ac2d92f] PDF Interpreter - have 
warning messages respect QUIET
git bisect skip 336c69b8be32c7193909a7f25b1a073b0ac2d92f
# skip: [c9f7be4f4de8e98df9d34ff8e4a7f781c0a33899] Bring master up to date with 
9.20 release branch
git bisect skip c9f7be4f4de8e98df9d34ff8e4a7f781c0a33899
# skip: [f42898997f249062f5da8fcf9c3a46cd6443fb39] PDF interpreter - skip 'R' 
operator in invalid context
git bisect skip f42898997f249062f5da8fcf9c3a46cd6443fb39
# skip: [2f6ddae95676585717159445001fda2ebb00db8d] Squash compiler warning.
git bisect skip 2f6ddae95676585717159445001fda2ebb00db8d
# skip: [b7ea690782c306241ed94fa3bdaf296f6bcc455f] Bug 697366
git bisect skip b7ea690782c306241ed94fa3bdaf296f6bcc455f
# skip: [0e2523b9dae517f91bd7da78323e5207d099a10e] Fix expat build on Windows
git bisect skip 0e2523b9dae517f91bd7da78323e5207d099a10e
# skip: [2f3679b53632c5b7b9e9a416311ae82f36645fc9] Bug 697220(2): Fix returning 
execstackoverflow
git bisect skip 2f3679b53632c5b7b9e9a416311ae82f36645fc9
# skip: [d4d8b7d51f79b47d21d3c82fe652a79e1f890df5] Fix bug 697323, Segfault 
after pattern with transparency.
git bisect skip d4d8b7d51f79b47d21d3c82fe652a79e1f890df5
# skip: [cb8022f3e15b761adf4bbc78621cf0699f69e21c] Fix SEGV caused by previous 
commit.
git bisect skip cb8022f3e15b761adf4bbc78621cf0699f69e21c
# skip: [0f6067d2531298060392d0e25fa759d320e03021] ps2write - don't try to 
alter /pagesave when modifying media size
git bisect skip 0f6067d2531298060392d0e25fa759d320e03021
# skip: [6655712ee1d0bf2a7818044613bbed226b7abddd] Update freetype to 2.7.0
git bisect skip 6655712ee1d0bf2a7818044613bbed226b7abddd
# skip: [8cefc79359e14fdb8b967697bba33b754e83bcad] pdfwrite - fix calculation 
of a bounding box
git bisect skip 8cefc79359e14fdb8b967697bba33b754e83bcad
# skip: [45268652fcddf2031f5edb592bc61e53d9ac4f5b] Set 
GX_DOWNSCALER_PARAMS_DEFAULTS in jpeg
git bisect skip 45268652fcddf2031f5edb592bc61e53d9ac4f5b
# skip: [8a26fa67398970f357e1292310ef20556a8e5d96] Fix 'corner' radial gradient 
case.
git bisect skip 8a26fa67398970f357e1292310ef20556a8e5d96
# skip: [99c6a18eb430a9091c79369b2bdd2952d481c7d5] Document use of string for 
subsituted CIDFont name
git bisect skip 99c6a18eb430a9091c79369b2bdd2952d481c7d5
# skip: [90b7603c1afb3ad79a6a0dfee97560b1c3565379] PCL - fix pdfmark parsing 
for PUTFILE
git bisect skip 90b7603c1afb3ad79a6a0dfee97560b1c3565379
# skip: [23dc144b3c3d3dbafd83dca7b9c09e6977b774d6] Update lcms2 to 2.8
git bisect skip 23dc144b3c3d3dbafd83dca7b9c09e6977b774d6
# skip: [a46245139253b2ec607fcd06c549a6293d05a3a8] Fix a bug in device 
subclassing
git bisect skip a46245139253b2ec607fcd06c549a6293d05a3a8
# skip: [0726780b28920045ee6f344a34bc5e8565bc4ed5] "cups" output device: When 
creating PWG Raster output, always output the bitmap of the full page, ignoring 
any unprintable margins suggested by the PPD file.
git bisect skip 0726780b28920045ee6f344a34bc5e8565bc4ed5
# skip: [21b582ca561214aa9c5b9c8987a1c0cdce43ace6] Add expat endian settings.
git bisect skip 21b582ca561214aa9c5b9c8987a1c0cdce43ace6
# skip: [71629c04758788b238d6ff3537d9708f430a4db7] Tweak to clip device nesting.
git bisect skip 71629c04758788b238d6ff3537d9708f430a4db7
# skip: [99e9ca317adbd28b5faf3e9eda4c63d636478f43] Bug 697045: Skip over broken 
tile data rather than aborting.
git bisect skip 99e9ca317adbd28b5faf3e9eda4c63d636478f43
# skip: [1eebbfa373d295bdd2bad88aaef1edc368450568] Bug 697231: Introduce 
caching to use of clipping paths.
git bisect skip 1eebbfa373d295bdd2bad88aaef1edc368450568
# broken: [ed425fcd620837bf63a18a3ee2a2202fa91b1207] Add -sPostRenderICCProfile 
support to tiffsep
git bisect broken ed425fcd620837bf63a18a3ee2a2202fa91b1207
# skip: [8dcec8cc076a0cf8350ca7a6ec1d3136812e2a24] Bug 697186: Workaround JPEG 
lib bug.
git bisect skip 8dcec8cc076a0cf8350ca7a6ec1d3136812e2a24
# fixed: 

Bug#909439: autopkgtest/debci: misleading "Version" if a new version becomes available during testing

[Rebecca N. Palmer]

On 23/09/2018 19:51, Paul Gevers wrote:

Hi,

On 23-09-18 19:29, Rebecca N. Palmer wrote:

What kind of logic do you have in mind?


If any binary of the package under test is being installed and isn't the
same version as the source, abort the run as a tmpfail.  (At least in a
standard debci run, as some documented uses probably want to allow such
mismatches:
https://sources.debian.org/src/autopkgtest/5.5/doc/README.running-tests.rst/#L65
)


As I mentioned in my previous reply, I consider the current behavior a
feature, so I don't like the logic you mention above.


What, if anything, do we actually disagree on?  I've already agreed that 
it should stay _possible_ to test non-matching source and binary 
versions: I just don't want this happening where it is unintended and 
confusing.


If the best place to fix this is outside autopkgtest, feel free to reassign.


failing (or tmpfail, but I don't think I like that)


Why not?  I suggested tmpfail because this isn't an actual problem with 
the package under test, and the whole point of this bug is that debci 
shouldn't claim that it is.  (Debci fail = code 4, 6 or 12 
https://sources.debian.org/src/debci/1.13/bin/debci-generate-index/#L168 ).


However, if we're passing a requested version to autopkgtest we should 
probably check that it is updated when retrying a tmpfail, to avoid 
endless retry loops.



debci could stop
showing the version, but I don't think that is actually helpful


Agreed that generally hiding the version would be worse.  (Hiding the 
version / changing it to something like 'mixed-versions' *only* when 
these issues happen would be a valid solution, but may or may not be 
practical.)

Bug#909538: RM: firebug -- RoQA; obsoleted with Firefox 60

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove firebug. It no longer works with Firefox 60 and has been obsoleted
by the Firefox Developer Tools, also see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906841#10

Cheers,
Moritz

Bug#906841: xul-ext-firebug no longer works with firefox-esr 60

[Moritz Mühlenhoff]

On Sat, Sep 08, 2018 at 03:14:50PM +0800, Paul Wise wrote:
> On Tue, 21 Aug 2018 20:01:17 +0300 Adrian Bunk wrote:
> 
> > Package: xul-ext-firebug
> > 
> > XUL addons are no longer supported.
> 
> The native Firefox developer tools were written to replace Firebug
> so I think this package can just be removed from Debian.
> 
> https://getfirebug.com/
> https://developer.mozilla.org/en-US/docs/Tools/Migrating_from_Firebug

I've filed a removal bug.

Cheers,
Moritz

Bug#909537: [devscripts] Files-Excluded-module-hyphen does not work

[Bastien Roucariès]

Package: devscripts
Version: 2.18.4
Severity: important

Hi,

If I create a tar module module-hyphen, i could not use 
 Files-Excluded-module-hyphen

Indeed mk-origintargz will upcase it to  Files-Excluded-Module-Hyphen and thus 
fail to found it.

Bastien

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

Bug#909536: mozjs60: FTBFS on s390x: around 80% of tests crash

[Simon McVittie]

Source: mozjs60
Version: 60.2.1-1
Severity: serious
Tags: ftbfs help
X-Debbugs-Cc: debian-s...@lists.debian.org
User: debian-s...@lists.debian.org
Usertags: s390x

Most of the test cases provided with mozjs60 crash:

grep '^TEST-' s390x.log | cut -d' ' -f1 | sort | uniq -c
   1714 TEST-KNOWN-FAIL
   6923 TEST-PASS
  28635 TEST-UNEXPECTED-FAIL

See 
https://buildd.debian.org/status/fetch.php?pkg=mozjs60=s390x=60.2.1-1=1537442189=0
for a full log. You'll see that the result of many tests is "rc = -11"
(I think that's signal 11, or SIGSEGV).

After reproducing this on the porterbox zelenka, a backtrace from one
such crash is below. The js interpreter seems to be crashing during a
garbage collection pass triggered during process shutdown.

This is a regression since mozjs52, in which only a few tests failed
(#878286). I'm willing to ignore a few isolated test failures, but when
80% of the tests fail, I don't think we can be confident that mozjs60
is at all usable on s390x.

We can't upgrade gjs to a version that uses mozjs60 until either this is
fixed somehow, or gjs and its dependencies (notably GNOME Shell) are
removed from s390x. The architecture-specific removal seems a more likely
short term solution; if this is done I'll downgrade this bug to important.

Thanks,
smcv

% gdb /home/smcv/mozjs60/debian/build/dist/bin/js js/src/tests/core
Core was generated by `/home/smcv/mozjs60/debian/build/dist/bin/js -f shell.js 
-f test262/shell.js -f'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  ContextToPC (context=0x3fff7e7d740) at 
./js/src/wasm/WasmSignalHandlers.cpp:452
452 MOZ_CRASH();
[Current thread is 1 (Thread 0x3ffad574750 (LWP 63693))]
Loading JavaScript value pretty-printers; see js/src/gdb/README.
If they cause trouble, type: disable pretty-printer .* SpiderMonkey
SpiderMonkey unwinder is disabled by default, to enable it type:
enable unwinder .* SpiderMonkey
(gdb) bt
#0  0x000112a11e96 in ContextToPC (context=0x3fff7e7d740) at 
./js/src/wasm/WasmSignalHandlers.cpp:452
#1  0x000112a11e96 in HandleFault (info=0x3fff7e7d6c0, ctx=0x3fff7e7d740, 
signum=)
at ./js/src/wasm/WasmSignalHandlers.cpp:1399
#2  0x000112a11e96 in WasmFaultHandler(int, siginfo_t*, void*) 
(signum=, info=0x3fff7e7d6c0, context=0x3fff7e7d740) at 
./js/src/wasm/WasmSignalHandlers.cpp:1477
#3  0x03fff7e7d6b8 in  ()
#4  0x000112aa6f04 in 
js::ProtectedData, unsigned 
int>::operator++(int) (this=0x7b0) at ./js/src/threading/ProtectedData.h:95
#5  0x000112aa6f04 in js::TenuringTracer::moveToTenured(JSString*) 
(this=0x3fff7e7dde8, src=Python Exception  'ascii' 
codec can't encode characters in position 3-4: ordinal not in range(128):
)
at ./js/src/gc/Marking.cpp:3226
#6  0x000112aa70d2 in js::TenuringTracer::traverse(JSString**) 
(this=this@entry=0x3fff7e7dde8, strp=0x11a89d598) at 
./js/src/gc/Marking.cpp:2743
#7  0x000112ab2d68 in 
js::gc::StoreBuffer::CellPtrEdge::trace(js::TenuringTracer&) const 
(this=this@entry=0x11a608e58, mover=...) at ./js/src/gc/Marking.cpp:2919
#8  0x000112ab2da8 in 
js::gc::StoreBuffer::MonoTypeBuffer::trace(js::gc::StoreBuffer*,
 js::TenuringTracer&) (this=this@entry=0x11a608e40, owner=, mover=...) at 
./js/src/gc/StoreBuffer.h:236
#9  0x000112ac8c00 in js::gc::StoreBuffer::traceCells(js::TenuringTracer&) 
(mover=..., this=)
at ./js/src/gc/StoreBuffer.h:440
#10 0x000112ac8c00 in js::Nursery::doCollection(JS::gcreason::Reason, 
js::gc::TenureCountCache&) (this=this@entry=0x11a608af8, 
reason=reason@entry=315707392, tenureCounts=...) at ./js/src/gc/Nursery.cpp:858
#11 0x000112ac9ffa in js::Nursery::collect(JS::gcreason::Reason) 
(this=this@entry=0x11a608af8, 
reason=reason@entry=JS::gcreason::DESTROY_RUNTIME) at 
./js/src/gc/Nursery.cpp:724
#12 0x000112a79f76 in js::gc::GCRuntime::minorGC(JS::gcreason::Reason, 
js::gcstats::PhaseKind) (this=this@entry=0x11a6069a8, 
reason=reason@entry=JS::gcreason::DESTROY_RUNTIME, 
phase=phase@entry=js::gcstats::PhaseKind::EVICT_NURSERY_FOR_MAJOR_GC) at 
./js/src/threading/ProtectedData.h:98
#13 0x000112a9f340 in js::gc::GCRuntime::minorGC(JS::gcreason::Reason, 
js::gcstats::PhaseKind) 
(phase=js::gcstats::PhaseKind::EVICT_NURSERY_FOR_MAJOR_GC, 
reason=JS::gcreason::DESTROY_RUNTIME, this=0x11a6069a8)
at ./debian/build/dist/include/mozilla/ThreadLocal.h:223
#14 0x000112a9f340 in js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, 
JS::gcreason::Reason) (this=this@entry=0x11a6069a8, 
nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., 
reason=reason@entry=JS::gcreason::DESTROY_RUNTIME) at ./js/src/gc/GC.cpp:7365
#15 0x000112a9f73e in js::gc::GCRuntime::collect(bool, js::SliceBudget, 
JS::gcreason::Reason) (this=this@entry=0x11a6069a8, 
nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., 
reason=reason@entry=JS::gcreason::DESTROY_RUNTIME) at ./js/src/gc/GC.cpp:7556
#16 0x000112a9f8ac in js::gc::GCRuntime::gc(JSGCInvocationKind, 

Bug#884352: virtualenvwrapper: Python interpreter inside virtualenv breaks after system python upgrade

[Andrey Rahmatullin]

On Mon, Sep 24, 2018 at 03:46:09PM -0400, Nicholas D Steeves wrote:
> > > after upgrading system-wide Python installation (in my case from 3.5.3 to 
> > > 3.5.4),
> > > virtualenvs may break due to the outdated interpreter 
> > > (somevirtualenv/bin/python3) inside the venv, trying to work with a newer 
> > > stdlib.
> > This is in no way specific to virtualenvwrapper which is just a wrapper.
> 
> Hi Andrey!  If this is the case would you please reassign this bug to
> virtualenv?
I don't see any real value in reassigning this bug and I don't want to
find out the correct binary package name.

> > > The problem is that mkvirtualenv copies rather than symlinks the python 
> > > interpreter binary, but symlinks the modules from standard library (e.g. 
> > > /usr/lib/python3.5).
> > This is done by virtualenv, not mkvirtualenv, and it was always that way,
> > and it's quite well known that the breakages happen and how to fix them
> > (by running virtualenv again). It is done because otherwise Python would
> > not find some files using relative paths.
> > 
> > See also https://github.com/pypa/virtualenv/pull/1171 and note "only for
> > Python 3.3 and higher".
> 
> As a beginner to Python it seems to me that the current behaviour
> (copied interpreter and symlinked modules) is incorrect and that there
> are three correct solutions:
> 
>   1) As proposed in that PR, symlink the interpreter.
This will fix itself when the PR is merged, not sooner.

>   2) Copy the libraries instead of symlinking them.
Can't comment on this.

>   3) Downgrade the severity of this bug to non-RC, because this is a
>  known and expected issue when using virtualenvs.
Sure, but this is up to the maintainer.

> I imagine that the current behaviour is useful because more
> vulnerabilities are found in libraries than in interpreters, and so it
> is beneficial for them to automatically follow system-wide security
> updates.  Of course apt isn't aware of all possible locations of
> venvs, so [2] would be bad, unless there was NEWS on each security
> update to "update all your virtualenvs".  In terms of annoyance
> factor, the [2] option (plus running virtualenv again) seems more
> annoying (but more secure) than using pip install --upgrade inside the
> venv.
Can't comment on this.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#827065: [uscan] please extend git tag support for signed git tag with pgpmode

[Xavier]

Hi all,

I have a problem to implement this: gpg accepts "--keyring" arg, so
uscan can give public key. I don't see any option to do that with "git
tag --verify" neither any environment variable...

Any idea ?

Bug#909535: gnome-shell-extensions: Native Window Placement screws up top-left gesture animation

[Manuel Bilderbeek]

Package: gnome-shell-extensions
Version: 3.30.0-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I upgraded to GNOME 3.30:

[UPGRADE] gnome-flashback:amd64 3.28.0-1 -> 3.30.0-1
[UPGRADE] gnome-flashback-common:amd64 3.28.0-1 -> 3.30.0-1
[UPGRADE] gnome-music:amd64 3.28.2.1-2 -> 3.30.0-2
[UPGRADE] gnome-shell:amd64 3.28.3-1 -> 3.30.0-1
[UPGRADE] gnome-shell-common:amd64 3.28.3-1 -> 3.30.0-1
[UPGRADE] gnome-shell-extensions:amd64 3.29.3+really3.28.1-1 -> 3.30.0-1
[UPGRADE] gnome-tweaks:amd64 3.28.1-1 -> 3.30.0-1

After this, the top-left hot-spot animation isn't working properly anymore. The
menu appears, but my windows aren't scaled down.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

I tried disabling all extensions. Then it worked normally again. Then I enabled
Native Window Placement and the problem reappeared.

So, enabling this extension causes the wrong behaviour. Disabling it causes the
right behaviour to appear again.

HTH...

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

Kernel: Linux 4.18.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)
LSM: AppArmor: enabled

Versions of packages gnome-shell-extensions depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  gir1.2-atk-1.0   2.30.0-1
ii  gir1.2-clutter-1.0   1.26.2+dfsg-4
ii  gir1.2-gdkpixbuf-2.0 2.38.0+dfsg-6
ii  gir1.2-glib-2.0  1.58.0-1
ii  gir1.2-gmenu-3.0 3.13.3-11
ii  gir1.2-gtk-3.0   3.24.0-3
ii  gir1.2-pango-1.0 1.42.4-3
ii  gnome-session-bin3.28.1-1
ii  gnome-settings-daemon3.30.0-1
ii  gnome-shell  3.30.0-1
ii  gvfs 1.38.0-2

Versions of packages gnome-shell-extensions recommends:
ii  gnome-tweaks  3.30.0-1

gnome-shell-extensions suggests no packages.

-- no debconf information

Bug#909530: t-coffee: autopkgtest regression

[Andreas Tille]

Control: tags -1 unreproducible
Control: tags -1 help

On Mon, Sep 24, 2018 at 09:12:16PM +0200, Paul Gevers wrote:
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/t/t-coffee/1045746/log.gz
> 
> # Command Line: t_coffee sample_seq1.fasta  [PROGRAM:T-COFFEE]
> 
> # TERMINATION STATUS: FAILURE [PROGRAM: T-COFFEE pid 1242 ppid 1131
> #CL: t_coffee sample_seq1.fasta

I admit I have no clue why this fails.  I've build the package with
autopkg hook in pbuilder successfully and the unit test also runs
on my local machine.

I suspect that using a more modern compiler than that was used for the
recent package compared to the previous with successful tests had
uncovered some hidden issue but it only happens under certain
circumstances.

Any idea why the test fails on ci infrastructure is welcome.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#909534: autopkgtest: Allow anybody to write to $AUTOPKGTEST_TMP

[Johannes 'josch' Schauer]

Package: autopkgtest
Version: 5.4.2
Severity: normal

When running with needs-root, $AUTOPKGTEST_TMP will be owned by root and
have permissions 0755. This means, that only root will be able to use
it. But as a temporary directory it should be possible for any user to
use it. Thus, please adjust permissions to 0777. Maybe also consider
setting the sticky bit (1777) like it is done with /tmp.

Thanks!

cheers, josch

Bug#909455: Info received (systemd FTBFS: meson_options.txt:49:0: ERROR: Option name debug is reserved.)

[Thiago Macieira]

Never mind, found out that this is a backport from upstream (commit 
8f6b442a78d0b485f044742ad90b2e8271b4e68e)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

Bug#909533: No ability to specify legacy arrays in mdadm.conf to build automatically at boot

[Witold Baryluk]

Package: mdadm
Version: 4.1~rc1-4
Severity: normal

I have a raw FAT32 that is for EFI system partition. I have it mirrored on two 
SSDs, but because it must be recognized by BIOS, it is stupid legacy partition 
with no superblocks or bitmaps.
It works well, because there is almost no writes to this file system. I also 
usually mount it with sync option.

I tried:

ARRAY /dev/md/bootefi level=mirror num-devices=2 
devices=/dev/disk/by-id/ata-M4-CT512M4SSD1_-part1,/dev/disk/by-id/ata-M4-CT512M4SSD1_-part1
 name=xyz_bootefi

and it doesn't work. doing mdadm --assemble --scan doesn't touch it.

I need to do manually mdadm --build /dev/md/bootefi --level... --num-devices=2 
/dev/xxx /dev/yyy

(plus minus --assume-clean, or full resync everytime because it is just 100MB 
in size).

Being able to put it in mdadm.conf would be nice.

PS. I need to do by-id or by-path, because doing this UUID will not work, as 
there in fact two devices (/dev/sda1 and /dev/sde1) with exactly same UUID, 
LABEL, etc.

Thanks.


-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST 
MAILADDR root
ARRAY /dev/md/0 metadata=1.2 UUID=a name=xyz:0
ARRAY /dev/md/1 metadata=1.2 UUID=b name=xyz:1
#ARRAY /dev/md/bootefi level=mirror num-devices=2 
devices=/dev/disk/by-id/ata-M4-CT512M4SSD1_AAA-part1,/dev/disk/by-id/ata-M4-CT512M4SSD1_BBB-part1
 name=xyz_bootefi

--- /etc/default/mdadm
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] 
[raid10]
md127 : active raid1 sdd1[1] sda1[0]
  123904 blocks super non-persistent [2/2] [UU]

md0 : active raid1 sda2[1] sdd2[0]
  624064 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sda3[1] sdd3[0]
  70247296 blocks super 1.2 [2/2] [UU]

unused devices: 

--- /proc/partitions:
major minor  #blocks  name

 2590 1000204632 nvme0n1
 2592 1000203264 nvme0n1p1
 2591 1000204632 nvme1n1
 2593 1000203264 nvme1n1p1
   8   64  250059096 sde
   8   65 307200 sde1
   8   66 102400 sde2
   8   67 131072 sde3
   8   68  249517056 sde4
   80  500107608 sda
   81 123904 sda1
   82 624640 sda2
   83   70312960 sda3
   84  429044736 sda4
   8   48  500107608 sdd
   8   49 123904 sdd1
   8   50 624640 sdd2
   8   51   70312960 sdd3
   8   52  429044736 sdd4
   8   16 2930266584 sdb
   8   17 2930265543 sdb1
   8   32  976762584 sdc
   91   70247296 md1
   90 624064 md0
 2530   70246272 dm-0
 25311949696 dm-1
 2532   25690112 dm-2
 2533   28946432 dm-3
 25343903488 dm-4
 25355558272 dm-5
 25364194304 dm-6
 2537  429043712 dm-7
 2538  429043712 dm-8
 2539 1000201216 dm-9
 253   10 1000201216 dm-10

--- mount output
/dev/md0 on /boot type ext4 (rw,nosuid,nodev,noatime,sync,data=ordered)
/dev/md127 on /boot/efi type vfat 
(rw,nosuid,nodev,noatime,sync,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)


--- initrd.img-4.16.0-2-amd64:

gzip: /boot/initrd.img-4.16.0-2-amd64: not in gzip format
cpio: premature end of archive

--- initrd's /conf/conf.d/md:
no conf/md file.

--- /proc/modules:
dm_crypt 40960 5 - Live 0xc02ca000
dm_mod 147456 31 dm_crypt, Live 0xc0469000
raid10 57344 0 - Live 0xc0395000
raid456 167936 0 - Live 0xc043f000
async_raid6_recov 20480 1 raid456, Live 0xc02b7000
async_memcpy 16384 2 raid456,async_raid6_recov, Live 0xc02b2000
async_pq 16384 2 raid456,async_raid6_recov, Live 0xc0253000
async_xor 16384 3 raid456,async_raid6_recov,async_pq, Live 0xc0246000
async_tx 16384 5 raid456,async_raid6_recov,async_memcpy,async_pq,async_xor, 
Live 0xc01b4000
raid6_pq 122880 4 btrfs,raid456,async_raid6_recov,async_pq, Live 
0xc0308000
libcrc32c 16384 3 nf_nat,nf_conntrack,raid456, Live 0xc017c000
raid0 20480 0 - Live 0xc015b000
multipath 16384 0 - Live 0xc00f4000
linear 16384 0 - Live 0xc011a000
raid1 45056 2 - Live 0xc020e000
md_mod 159744 8 raid10,raid456,raid0,multipath,linear,raid1, Live 
0xc0417000
raid_class 16384 1 mpt3sas, Live 0xc0165000
scsi_mod 253952 6 sg,sd_mod,mpt3sas,raid_class,libata,scsi_transport_sas, Live 
0xc00b5000

--- /var/log/syslog:

--- volume detail:
# mdadm --examine /dev/md127
/dev/md127:
   MBR Magic : aa55
# mdadm --detail /dev/md127
/dev/md127:
   Version :
 Creation Time : Mon Sep 24 21:53:46 2018
Raid Level : raid1
Array Size : 123904 (121.00 MiB 126.88 MB)
 Used Dev Size : 123904 (121.00 MiB 126.88 MB)
  Raid Devices : 2
 Total Devices : 2

 State : clean
Active Devices : 2
   Working Devices : 2
 

Bug#909532: patroni: autopkgtest regression: features/basic_replication.feature

[Paul Gevers]

Source: patroni
Version: 1.5.0-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

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

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

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=patroni

https://ci.debian.net/data/autopkgtest/testing/amd64/p/patroni/1045310/log.gz

  Scenario: check rejoin of the former master with pg_rewind  #
features/basic_replication.feature:48
Given I add the table splitbrain to postgres0 #
features/steps/basic_replication.py:27
And I start postgres0 #
features/steps/basic_replication.py:7
Then postgres0 role is the secondary after 20 seconds #
features/steps/basic_replication.py:48
  Assertion Failed: postgres0 role didn't change to secondary after
20 seconds


Failing scenarios:
  features/basic_replication.feature:48  check rejoin of the former
master with pg_rewind

5 features passed, 1 failed, 0 skipped
21 scenarios passed, 1 failed, 0 skipped
187 steps passed, 1 failed, 2 skipped, 0 undefined



signature.asc
Description: OpenPGP digital signature

Bug#884352: virtualenvwrapper: Python interpreter inside virtualenv breaks after system python upgrade

[Nicholas D Steeves]

Hello,

This bug came to my attention because elpy -> pyvenv-el
-> virtualenvwrapper.

On Sat, Sep 22, 2018 at 12:18:33PM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 14, 2017 at 01:33:18PM +0100, Krzysztof Słychań wrote:
> > after upgrading system-wide Python installation (in my case from 3.5.3 to 
> > 3.5.4),
> > virtualenvs may break due to the outdated interpreter 
> > (somevirtualenv/bin/python3) inside the venv, trying to work with a newer 
> > stdlib.
> This is in no way specific to virtualenvwrapper which is just a wrapper.

Hi Andrey!  If this is the case would you please reassign this bug to
virtualenv?

> > The problem is that mkvirtualenv copies rather than symlinks the python 
> > interpreter binary, but symlinks the modules from standard library (e.g. 
> > /usr/lib/python3.5).
> This is done by virtualenv, not mkvirtualenv, and it was always that way,
> and it's quite well known that the breakages happen and how to fix them
> (by running virtualenv again). It is done because otherwise Python would
> not find some files using relative paths.
> 
> See also https://github.com/pypa/virtualenv/pull/1171 and note "only for
> Python 3.3 and higher".

As a beginner to Python it seems to me that the current behaviour
(copied interpreter and symlinked modules) is incorrect and that there
are three correct solutions:

  1) As proposed in that PR, symlink the interpreter.
  2) Copy the libraries instead of symlinking them.
  3) Downgrade the severity of this bug to non-RC, because this is a
 known and expected issue when using virtualenvs.

I imagine that the current behaviour is useful because more
vulnerabilities are found in libraries than in interpreters, and so it
is beneficial for them to automatically follow system-wide security
updates.  Of course apt isn't aware of all possible locations of
venvs, so [2] would be bad, unless there was NEWS on each security
update to "update all your virtualenvs".  In terms of annoyance
factor, the [2] option (plus running virtualenv again) seems more
annoying (but more secure) than using pip install --upgrade inside the
venv.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#909510: please add a lintian note to inform/warn about python in the shebang (instead of python2/python2.7)

[Mattia Rizzolo]

On Mon, Sep 24, 2018 at 07:23:43PM +0100, Chris Lamb wrote:
> > please add a lintian note to inform/warn about python in the shebang 
> > (instead of
> > python2/python2.7).
> 
> Thanks for this. Can you draft a very rough tag description for this?
> Your following paragraph (re. easy and safe) seems to be a fairly good
> place to start.

Just noting here that the tag description should also say that if the
package uses dh_python2 (and it is throughly applied to all the python
files…) just rebuilding the package will fix the situation, starting
with dh-python 3.20180313 (from the changelog "dh_python2: rewrite
/usr/bin/python shebangs to /usr/bin/python2").

> In addition, just checking that you mean "#!/usr/bin/python" vs "#!/
> usr/bin/python2.7" (not "!#python" or somesuch).

TBH, I'd hope lintian already complains (laudly) about #!python ... at a
quite high severity even...

> Finally, linking to some good/bad packages in Debian would help us
> prioritise this effectively.

looking at current sid:

BAD:

mattia@warren ~ % rgrep 'usr/bin/python$' /usr/bin|head
/usr/bin/scons:#! /usr/bin/python
/usr/bin/cssparse_py2:#!/usr/bin/python
/usr/bin/pygmentize:#! /usr/bin/python
/usr/bin/dh_python2:#! /usr/bin/python
/usr/bin/csscombine_py2:#!/usr/bin/python
/usr/bin/pyflakes:#!/usr/bin/python
/usr/bin/sconsign:#! /usr/bin/python
Binary file /usr/bin/svtplay-dl matches
/usr/bin/bzr.bzr:#! /usr/bin/python
/usr/bin/markdown_py:#!/usr/bin/python

GOOD:

mattia@warren ~ % rgrep -E 'usr/bin/python2(\.7)?$' /usr/bin|head
/usr/bin/ubuntu-build:#! /usr/bin/python2
/usr/bin/seeded-in-ubuntu:#! /usr/bin/python2
/usr/bin/calibredb:#!/usr/bin/python2.7
/usr/bin/ubuntu-upload-permission:#! /usr/bin/python2
/usr/bin/pyclean:#! /usr/bin/python2
/usr/bin/tkconch:#! /usr/bin/python2
/usr/bin/mailmail:#! /usr/bin/python2
/usr/bin/pbuilder-dist:#! /usr/bin/python2
/usr/bin/backportpackage:#! /usr/bin/python2
/usr/bin/sponsor-patch:#! /usr/bin/python2


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#532097: RFA: cups -- Common UNIX Printing System

[Brian Potkin]

On Sat 06 Jun 2009 at 14:05:10 +0200, Martin Pitt wrote:

> Package: wnpp
> Severity: normal
> 
> Hello all,
> 
> cups is in severe need for a dedicated Debian maintainer. I became an
> uploader some years ago for more efficient integration of
> improvements/fixes done in Ubuntu, but now I have been the only
> uploader for 1.5 years. I cleaned up the patch mess, brought the
> package and test suite into a well working state, follow up on RC
> bugs, and prepare most security updates; Till Kamppeter is developing
> the PDF filters.
> 
> However, that's not enough. Neither Till nor I have a Debian unstable
> as primary workstation where we could test printing in a real Debian
> system, and neither of us has time to look at the Debian bug reports.
> 
> Right now, cups has hundreds of bug reports, many of them years old;
> many of them were probably fixed long ago, many aren't problems in
> cups but some driver (gutenprint, foomatic, ghostscript).
> 
> To get the Debian cups bugs into some useful state again, someone who
> knows the Linux printing system very well needs to sit down and write
> a comprehensive "how to debug printing problems" document: in
> particular, how to identify in which package the problem is, which
> debug information to collect, and common workarounds/tests which help
> the reporter's immediate problem and are useful for diagnosis.
> 
> Then we can declare a "bug bancrupcy" and mass-close all bugs which
> were filed before the Lenny release, with an honest apology and the
> request to re-file bugs again with following the debugging document.
> For all newer bugs we can just followup with the debugging document.
> 
> On the plus side, cups' upstream Mike Sweet is very responsive. It
> takes some dispassionateness to argue with him about patches and
> rejected bug reports, but he responds very fast. So the genuine
> problems remaining in the Debian BTS should be spoonfed to upstream,
> after making sure that it isn't a Debian specific or driver problem.
> 
> I'm happy to continue basic package maintenance as pointed out above,
> do sponsoring, and mentor interested newcomers. You don't need to be a
> DD, but you should have a printer or two, use Debian unstable
> regularly, and willing to learn about the printing architecture (cups
> spooler, drivers, etc.).
> 
> Many thanks in advance,

[...]

This bug report should be closed.

For a number of years Didier 'OdyX' Raboud has been the dedicated Debian
maintainer of cups and other packages and kept them in excellent shape
with timely package uploads and attention to detail. The printing team's
activities have also run smoothly.

The "hundreds of bug reports" have been reduced to a handful and the wiki
and cups documentation have been transformed.

Regards,

Brian.

Bug#909455: systemd FTBFS: meson_options.txt:49:0: ERROR: Option name debug is reserved.

[Thiago Macieira]

Has this issue been reported upstream? Or a PR sent to fix the issue?

I'm guessing this is caused by a change in meson in version 0.48
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

Bug#827065: [uscan] please extend git tag support for signed git tag with pgpmode

[Xavier]

Le 24/09/2018 à 21:24, Xavier a écrit :
> Hi all,
> 
> I have a problem to implement this: gpg accepts "--keyring" arg, so
> uscan can give public key. I don't see any option to do that with "git
> tag --verify" neither any environment variable...
> 
> Any idea ?

Found ! https://darkowlzz.github.io/post/git-tag-signature-verification/

Bug#909531: evince: Cannot open a new window

[Fabian Inostroza]

Package: evince
Version: 3.30.0-2
Severity: normal

Dear Maintainer,

If I launch evince and then try to open a new window by using the menu in 
evince nothing happens.
Also the new window entry is missing in the right click menu of the launcher.

If I try to open a new window from the Evince menu the following appears in the 
system log:

[ 3432.193280] audit: type=1400 audit(1537816996.565:31): apparmor="DENIED" 
operation="exec" profile="/usr/bin/evince" 
name="/usr/lib/x86_64-linux-gnu/glib-2.0/gio-launch-desktop" pid=11689 
comm="evince" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0



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

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  evince-common3.30.0-2
ii  gsettings-desktop-schemas3.28.0-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo-gobject21.15.12-1
ii  libcairo21.15.12-1
ii  libevdocument3-4 3.30.0-2
ii  libevview3-3 3.30.0-2
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgnome-desktop-3-173.30.0-1
ii  libgtk-3-0   3.24.0-3
ii  libnautilus-extension1a  3.30.0-4
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libsecret-1-00.18.6-2
ii  shared-mime-info 1.9-2

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1

Versions of packages evince suggests:
ii  gvfs 1.38.0-2
ii  nautilus-sendto  3.8.6-2
ii  poppler-data 0.4.9-2
pn  unrar

-- no debconf information

Bug#863631: conf file reset to default

[marc marc]

also in sympa 6.1.23~dfsg-2+deb8u3

Bug#909530: t-coffee: autopkgtest regression

[Paul Gevers]

Source: t-coffee
Version: 11.00.8cbe486-7
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of t-coffee the autopkgtest of t-coffee fails in
testing when that autopkgtest is run with the binary packages of
t-coffee from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
t-coffee   from testing11.00.8cbe486-7
all others from testingfrom testing

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

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=t-coffee

https://ci.debian.net/data/autopkgtest/testing/amd64/t/t-coffee/1045746/log.gz

# Command Line: t_coffee sample_seq1.fasta  [PROGRAM:T-COFFEE]

# TERMINATION STATUS: FAILURE [PROGRAM: T-COFFEE pid 1242 ppid 1131
#CL: t_coffee sample_seq1.fasta



signature.asc
Description: OpenPGP digital signature

Bug#909511: lintian: check for update-inetd --group without --add, --pattern with --add

[Andreas Beckmann]

On 2018-09-24 20:19, Chris Lamb wrote:
>> update-inetd got more strict recently w.r.t. valid option combinations
> 
> Thanks for this. Can you draft a very rough tag description for this?
> 
> I think I would also love to see which version got stricter (vs
> "recently") — it is not immediately clear from my glance at the
> changelog.

I had looked at that while fixing the bug in sendmail ...

The relevant changelog entry:

update-inetd (4.46) unstable; urgency=medium
...
  * Check whether --group and --pattern is used with the correct commands.
(Closes: #374542)
...
 -- Guillem Jover   Sat, 04 Aug 2018 15:55:57 +0200

and the matching commit:

https://git.hadrons.org/cgit/debian/update-inetd.git/commit/?id=d1441ad3a97449de481c4f93eb7692890e83be4d

I'll think about a tag description later.


Andreas

Bug#902582: (some kind of) transition: add python3.7 as a supported python3 version

[Adam D. Barratt]

On Sun, 2018-09-23 at 19:53 +0200, Andreas Beckmann wrote:
> is_affected = .build-depends ~ /python3-all-dev/ | .build-depends ~
> /python3-all-dbg/;
> 
> (or something like that)

Looks like someone did that.

Regards,

Adam

Bug#904316: transition: boost-defaults

[Anton Gladky]

Hi.

from my point of view it is also better to have new boost-defaults
in the unstable and fix needed packages there. We doe not have too
much time for now to have an intermediate upload into experimental.

If this transition will be smooth and fast, we could consider to package
1.68/1.69. But it would probably be too risky and can potentially delay
the next release.

Regards

Anton

Am Mo., 24. Sep. 2018 um 02:21 Uhr schrieb Dimitri John Ledkov
:
...
> Largely rebuilds in Ubuntu have been sufficient to identify and fix
> the bulk of boost transition issues
> http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.67.html
>
> After the initial rounds of NMUs I typically work off the Debian
> transition tracker to complete transition / files FTBFS bugs / NMU
> patches.
>
> I can prepare the boost-defaults upload into experimental, but I'd
> rather have this transition approved and boost-defaults uploaded into
> unstable.

Bug#906349: doublecmd: FTBFS in buster/sid (tries to write in /usr)

[Graham Inggs]

Hi Abou

On 23 September 2018 at 22:44, Abou Al Montacir  wrote:
> I've reverted this in b9ccece9. However this means that Bug#898310 needs to
> be reopen.

Thanks, I have a reassigned #906349 so it can be closed when lazarus
is uploaded.
Shall I go ahead with an upload, or do you wish to make more changes?

Regards
Graham

Bug#909529: python3-alembic and python3-astroid: file conflict on /usr/lib/python3/dist-packages/.pytest_cache/v/cache/nodeids

[Helmut Grohne]

Package: python3-alembic,python3-astroid
Severity: serious

When installing python3-alembic and python3-astroid in a fresh sid
chroot, this is what I get:

| ...
| Unpacking python3-sqlalchemy (1.2.8+ds1-1) ...
| Selecting previously unselected package python3-alembic.
| Preparing to unpack .../11-python3-alembic_1.0.0-1_all.deb ...
| Unpacking python3-alembic (1.0.0-1) ...
| Selecting previously unselected package python3-lazy-object-proxy.
| Preparing to unpack .../12-python3-lazy-object-proxy_1.3.1-1+b1_amd64.deb ...
| Unpacking python3-lazy-object-proxy (1.3.1-1+b1) ...
| Selecting previously unselected package python3-wrapt.
| Preparing to unpack .../13-python3-wrapt_1.10.11-1_amd64.deb ...
| Unpacking python3-wrapt (1.10.11-1) ...
| Selecting previously unselected package python3-setuptools.
| Preparing to unpack .../14-python3-setuptools_40.2.0-1_all.deb ...
| Unpacking python3-setuptools (40.2.0-1) ...
| Selecting previously unselected package python3-astroid.
| Preparing to unpack .../15-python3-astroid_2.0.4-1_all.deb ...
| Unpacking python3-astroid (2.0.4-1) ...
| dpkg: error processing archive 
/tmp/apt-dpkg-install-PRg25B/15-python3-astroid_2.0.4-1_all.deb (--unpack):
|  trying to overwrite 
'/usr/lib/python3/dist-packages/.pytest_cache/v/cache/nodeids', which is also 
in package python3-alembic 1.0.0-1
| dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
| Errors were encountered while processing:
|  /tmp/apt-dpkg-install-PRg25B/15-python3-astroid_2.0.4-1_all.deb
| E: Sub-process /usr/bin/dpkg returned an error code (1)

Helmut

Bug#908723: ITP: django-auto-one-to-one -- Django module to automatically connect child model instances to parent class

[Chris Lamb]

tags 908723 + pending
thanks

Uploaded:

 Uploading django-auto-one-to-one_3.0.0-1.dsc
 Uploading django-auto-one-to-one_3.0.0.orig.tar.gz
 Uploading django-auto-one-to-one_3.0.0-1.debian.tar.xz
 Uploading django-auto-one-to-one_3.0.0-1_amd64.buildinfo
 Uploading python3-django-auto-one-to-one_3.0.0-1_all.deb
 Uploading django-auto-one-to-one_3.0.0-1_amd64.changes


Regards,

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

Bug#908935: repository for working on this

[Dr. Tobias Quathamer]

Am 24.09.2018 um 18:46 schrieb Jeffrey Cliff:
> Please consider not using github for your working on packaging.  There
> are non-microsoft platforms available for others to follow your efforts.
> 
> https://notabug.org/themusicgod1/azure-storage-blob-go
> 
> in particular is here for you.

I'm not sure I understand what you're trying to say here. The packaging
will be on salsa.d.o, not github. But upstream is hosted on github, so I
need to fetch from there.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#909528: intel-mkl: [INTL:pt] Portuguese translation for debconf messages

[Traduz PT]

Package: intel-mkl
Version: 2018.3.222-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for intel-mkl's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org
# Copyright (C) 2018 THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the intel-mkl package.
#
# Rui Branco - DebianPT , 2018.
msgid ""
msgstr ""
"Project-Id-Version: intel-mkl 2018.3.222-3\n"
"Report-Msgid-Bugs-To: intel-...@packages.debian.org\n"
"POT-Creation-Date: 2018-06-16 10:31+\n"
"PO-Revision-Date: 2018-09-21 19:31+\n"
"Last-Translator: Rui Branco - DebianPT \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: title
#. Description
#: ../libmkl-rt.templates:1001
msgid "Intel Math Kernel Library (Intel MKL)"
msgstr "Biblioteca de Kernel Intel Math (Intel MKL)"

#. Type: boolean
#. Description
#: ../libmkl-rt.templates:2001
msgid "Use libmkl_rt.so as the default alternative to BLAS/LAPACK?"
msgstr ""
"Utilizar o libmkl_rt.so como alternativa de predefinição ao BLAS/LAPACK?"

#. Type: boolean
#. Description
#: ../libmkl-rt.templates:2001
msgid ""
"Intel MKL's Single Dynamic Library (SDL) is installed on your machine. This "
"shared object can be used as an alternative to both libblas.so.3 and "
"liblapack.so.3, so that packages built against BLAS/LAPACK can directly use "
"MKL without rebuild."
msgstr ""
"A Intel MKL's Single Dynamic Library (SDL) está instalada na sua máquina. "
"Este objecto partilhado pode ser utilizado como uma alternativa para o "
"libblas.so.3 e liblapack.so.3, para que pacotes construídos sobre o "
"BLAS/LAPACK possam usar a MKL sem recompilação."

#. Type: boolean
#. Description
#: ../libmkl-rt.templates:2001
msgid ""
"However, MKL is non-free software, and in particular its source code is not "
"publicly available. By using MKL as the default BLAS/LAPACK implementation, "
"you might be violating the licensing terms of copyleft software that would "
"become dynamically linked against it. Please verify that the licensing terms "
"of the program(s) that you intend to use with MKL are compatible with the "
"MKL licensing terms. For the case of software under the GNU General Public "
"License, you may want to read this FAQ:"
msgstr ""
"No entanto a MKL não é software livre e em particular o seu código fonte "
"não está disponível publicamente. Ao utilizar a MKL como predifinição da "
"implementação BLAS/LAPACK pode estar a violar os termos da licença dos "
"termos do software que estará dinamicamente ligado a este. Verifique por "
"favor se os termos da licença do programa que tenciona usar com a MKL "
"são compatíveis com os termos de licença do MKL. No caso de software "
"sobre a licença GNU General Public, pode querer ler este FAQ:"

#. Type: boolean
#. Description
#: ../libmkl-rt.templates:2001
msgid "https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs;
msgstr "https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs;

#. Type: boolean
#. Description
#: ../libmkl-rt.templates:2001
msgid ""
"If you don't know what MKL is, or unwilling to set it as default, just "
"choose the preset value or simply type Enter."
msgstr ""
"Se não sabe o que é a MKL ou não quer configura-la como predefinição "
"escolha o valor apresentado ou tecle simplesmente Enter. "

#. Type: multiselect
#. Description
#: ../libmkl-rt.templates:3001
msgid "Which of the these alternatives should point to MKL?"
msgstr "Quais destas alternativas deverão apontar para a MKL?"

#. Type: multiselect
#. Description
#: ../libmkl-rt.templates:3001
msgid ""
"Please select the alternatives that should point to MKL. The selection "
"applies to all available architectures, and the related development packages "
"will follow the same selection."
msgstr ""
"Por favor selecione as alternativas que devem apontar para a MKL. "
"A selecção aplica-se a toas as arquitecturas disponíveis e os pacotes "
"de desenvolvimento relacionados seguem a mesma selecção. "

#. Type: multiselect
#. Description
#: ../libmkl-rt.templates:3001
msgid ""
"Typically the user may want to point both BLAS/LAPACK to MKL (libmkl_rt.so). "
"Type Enter if you are not sure what to select."
msgstr ""
"Tipicamente o utilizador pode querer apontar ambos a BLAS/LAPACK para a "
"MKL (libmkl_rt.so). Tecle Enter se tiver dúvidas sobre o que escolher."

Bug#909527: mozilla-devscripts: dh_webext breaks on non-ascii debian/control when building with LANG=C

[Christoph Biedl]

Package: mozilla-devscripts
Version: 0.51
Severity: important
Tags: patch

Dear Maintainer,

when trying to rebuild mozilla-noscript (actually, preparing a backport),
I got an error:

| dh binary --with webext
|dh_testroot
|dh_prep
|dh_install
|dh_webext
| Traceback (most recent call last):
|   File "/usr/bin/dh_webext", line 217, in 
| sys.exit(install_webext(*sys.argv[1:]))
|   File "/usr/bin/dh_webext", line 144, in install_webext
| packages = args.packages or get_all_packages()
|   File "/usr/bin/dh_webext", line 73, in get_all_packages
| lines = open("debian/control").readlines()
|   File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
| return codecs.ascii_decode(input, self.errors)[0]
| UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 210: 
ordinal not in range(128)
| make: *** [debian/rules:4: binary] Error 1
| dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2

Turns out that package's debian/control contains utf-8 sequences but
dh_webext cannot deal with it with when LANG is set to e.g. "C". As far
as I can tell, sbuild does this by default.

Trivial reproducer using the mozilla-noscript source (version 10.1.9.6-1):

  ( export LANG=C ; dpkg-buildpackage  -uc -us -sa -rfakeroot )

Using "en_US.UTF-8" instead makes the build succeed.

The patch below, mostly taken from reportbug, solved the issue but my
Python foo isn't good enough yet to judge its quality.

Regards,

Christoph

--- /tmp/dh_webext  2018-09-23 23:28:42.0 +0200
+++ /usr/bin/dh_webext  2018-09-24 20:26:56.531677978 +0200
@@ -33,6 +33,7 @@
 import argparse
 import datetime
 import json
+import locale
 import os
 import shlex
 import subprocess
@@ -214,4 +215,9 @@
 return 1
 
 if __name__ == '__main__':
+try:
+locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
+except locale.Error as x:
+print('*** Warning:', x, file=sys.stderr)
+
 sys.exit(install_webext(*sys.argv[1:]))

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

Kernel: Linux 4.18.6 (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: unable to detect

Versions of packages mozilla-devscripts depends on:
ii  perl   5.26.2-7
ii  python 2.7.15-3
ii  python-librdf  1.0.17.1+dfsg-1.3+b5
ii  python33.6.6-1
ii  unzip  6.0-21
ii  zip3.0-11+b1

mozilla-devscripts recommends no packages.

mozilla-devscripts suggests no packages.

-- no debconf information



signature.asc
Description: PGP signature

Bug#909526: stretch-pu: package dom4j/1.6.1+dfsg.3-2

[Markus Koschany]

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

Dear release team,

I would like to update dom4j in Stretch. It is currently affected by
CVE-2018-1000632, a XML injection attack. The security team marked
this issue as no-dsa. Please find attached the debdiff.

Regards,

Markus
diff -Nru dom4j-1.6.1+dfsg.3/debian/changelog 
dom4j-1.6.1+dfsg.3/debian/changelog
--- dom4j-1.6.1+dfsg.3/debian/changelog 2013-06-26 23:31:01.0 +0200
+++ dom4j-1.6.1+dfsg.3/debian/changelog 2018-09-24 15:03:22.0 +0200
@@ -1,3 +1,18 @@
+dom4j (1.6.1+dfsg.3-2+deb9u1) stretch; urgency=high
+
+  * Team upload.
+  * Fix CVE-2018-1000632:
+Mario Areias discovered that dom4j, a XML framework for Java, was
+vulnerable to a XML injection attack. An attacker able to specify
+attributes or elements in the XML document might be able to modify the
+whole XML document.
+  * Compile with source/target 1.5 to fix a compilation issue with
+String.format.
+  * Add testng to Build-Depends. Build and test AllowedCharsTest to verify that
+CVE-2018-1000632 is correctly addressed.
+
+ -- Markus Koschany   Mon, 24 Sep 2018 15:03:22 +0200
+
 dom4j (1.6.1+dfsg.3-2) unstable; urgency=low
 
   * Removed the dependency on libjaxme-java
diff -Nru dom4j-1.6.1+dfsg.3/debian/control dom4j-1.6.1+dfsg.3/debian/control
--- dom4j-1.6.1+dfsg.3/debian/control   2013-06-26 23:12:47.0 +0200
+++ dom4j-1.6.1+dfsg.3/debian/control   2018-09-24 15:03:22.0 +0200
@@ -5,7 +5,7 @@
 Uploaders: Marcus Better , Emmanuel Bourg 
 Build-Depends: debhelper (>= 7), ant-optional, default-jdk, maven-repo-helper, 
cdbs
 Build-Depends-Indep: antlr, libjaxen-java, libxpp2-java, libxpp3-java,
- libxerces2-java, libxalan2-java (>= 2.7.0), junit, libjunitperf-java, 
libmsv-java,
+ libxerces2-java, libxalan2-java (>= 2.7.0), junit, testng, libjunitperf-java, 
libmsv-java,
  librelaxng-datatype-java
 Standards-Version: 3.9.4
 Vcs-Svn: svn://anonscm.debian.org/pkg-java/trunk/dom4j
diff -Nru dom4j-1.6.1+dfsg.3/debian/patches/01_build-tweaks.patch 
dom4j-1.6.1+dfsg.3/debian/patches/01_build-tweaks.patch
--- dom4j-1.6.1+dfsg.3/debian/patches/01_build-tweaks.patch 2013-06-26 
21:35:23.0 +0200
+++ dom4j-1.6.1+dfsg.3/debian/patches/01_build-tweaks.patch 2018-09-24 
15:03:22.0 +0200
@@ -1,17 +1,26 @@
-Description:
- Link the Javadoc with the Java API installed with default-jre
- Fix the classpath for the tests
- Ignore test failures
+From: Debian Java Maintainers 
+Date: Mon, 24 Sep 2018 15:45:49 +0200
+Subject: Link the Javadoc with the Java API installed with default-jre
+
+Fix the classpath for the tests
+Ignore test failures
 Forwarded: not-needed
+---
+ build.xml | 17 ++---
+ 1 file changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/build.xml b/build.xml
+index 0f87f2d..215c727 100644
 --- a/build.xml
 +++ b/build.xml
-@@ -24,6 +24,15 @@
+@@ -24,6 +24,16 @@
  
  
  
 +
 +
 +
++
 +
 +
 +
@@ -21,7 +30,7 @@
  
  
  
-@@ -155,6 +164,7 @@
+@@ -155,6 +165,7 @@

  http://sourceforge.net/sflogo.php?group_id=16035' width='88' height='31' 
border='0' alt='SourceForge Logo' /"
   stylesheetfile="${doc.dir}/style/javadoc.css">
@@ -38,7 +47,7 @@
http://java.sun.com/xml/jaxp-docs-1.1/docs/api"/>
  
  
-@@ -236,7 +246,7 @@
+@@ -236,7 +247,7 @@
   doctitle="${Name}"
   bottom="Copyright  ${year} MetaStuff Ltd. All Rights 
Reserved. Hosted by p img 
src='http://sourceforge.net/sflogo.php?group_id=16035' width='88' height='31' 
border='0' alt='SourceForge Logo' /"
   stylesheetfile="${doc.dir}/style/javadoc.css">
@@ -47,7 +56,7 @@
http://java.sun.com/xml/jaxp-docs-1.1/docs/api"/>

  
-@@ -270,7 +280,7 @@
+@@ -270,7 +281,7 @@


  
diff -Nru dom4j-1.6.1+dfsg.3/debian/patches/CVE-2018-1000632.patch 
dom4j-1.6.1+dfsg.3/debian/patches/CVE-2018-1000632.patch
--- dom4j-1.6.1+dfsg.3/debian/patches/CVE-2018-1000632.patch1970-01-01 
01:00:00.0 +0100
+++ dom4j-1.6.1+dfsg.3/debian/patches/CVE-2018-1000632.patch2018-09-24 
15:03:22.0 +0200
@@ -0,0 +1,302 @@
+From: Markus Koschany 
+Date: Mon, 24 Sep 2018 14:53:44 +0200
+Subject: CVE-2018-1000632
+
+Bug-Upstream: https://github.com/dom4j/dom4j/issues/48
+Origin: 
https://github.com/dom4j/dom4j/commit/e598eb43d418744c4dbf62f647dd2381c9ce9387
+---
+ build.xml|   4 +-
+ src/java/org/dom4j/Namespace.java|   5 +-
+ src/java/org/dom4j/QName.java| 103 ++-
+ src/java/org/dom4j/tree/QNameCache.java  |   4 +-
+ src/test/org/dom4j/AllowedCharsTest.java |  78 +++
+ 5 files changed, 189 insertions(+), 5 deletions(-)
+ create mode 100644 src/test/org/dom4j/AllowedCharsTest.java
+
+diff --git 

Bug#908723: ITP: django-auto-one-to-one -- Django module to > automatically connect child model instances to parent class

[Chris Lamb]

owner 908723 !
thanks

> I spoke with Chris, and we agreed to maintain this package as part of
> the python team.  He will have a look at the packaging and insert it
> into the correct location.

Altering owner to match.


Regards,

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

Bug#909525: sshguard: should recommend (not depend on) iptables and recommend nftables alternatively

[Jonas Smedegaard]

Package: sshguard
Version: 2.2.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

sshguard supports nftables since upstream release 2.2.1.

The package should therefore add nftables as alternative to iptables.

Also, sshguard supports other more exotic methods, and supports using
custom local methods instead.  Package relation should therefore be
recommendation (not dependency).


Thanks,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlupLEoACgkQLHwxRsGg
ASGt8BAAq0jWMH/rB8hcLyzWgOS/vNS1w5Mjt28L89aSKhV8ETrk16ybTdIFuMjw
SqKXQN9e6jNrAZAusm1qrA0MluRoMEmwIKDMNrv8QPIikIsHHZ6Ub6g1ESe143yK
+TRwSMWFtv9ZZcYXMSdp4fu26OMaoWzqDv1paulLKhhZEtcSR7N9hU7s1L8hU3z7
KUpEdHQjXjLcdrArOSIUucUBbOPdG4GlWkDgbHIAKm3er6mOZuG521Hpv6x80mTT
7Ds3lJ+6Jo/2DHETcpDMMiLz/rNDCQYX03JFyqO8/0kTJRf4VYRTRcgTZjGD6IGD
e29FK3DXneDckGD3DS5E5nle5eAqpFMlQvjB4FbsMHzNL1JCJc+hpB3XimmQ5JRs
RCjNXpB3y3dv1PqvgrGq4nr1Cu7EbT6ozvLFGl/0pBEZwUF4SXf4SaARemMBgjyA
8xCn4sN9eIR/ZBm+sbgQmgY+VDxE0uO+mLmWqe1BwSXn2+zcdxIpIECe91HXBTaq
ekTd+V4ydJbVle4twyxDNKh+v7z8CxPzOpYVLnlXIXu3GN97hs19ItaxgJUFboeG
6rsbhbsnfFsocUkPNzJkXtmMjmsY0qhBj14FmuxHqlWMRpABoTuhq15sKAKcGAoH
Jmpml/rTCPjr0NV9lnLwpWxSCebjDFHXvG4AIBj9R2ps9t+j+qc=
=NwHn
-END PGP SIGNATURE-

Bug#907697: fortunes-br: Inconsistent use of accents in fortunes-br

[Breno Leitao]

On Fri, 31 Aug 2018 11:46:03 -0300 Rafael Vargas  wrote:
> Package: fortunes-br
> Version: 20160820
> Severity: minor
> 
> Dear Maintainer,
> 
> Throughout the entire fortune file, several phrases uses some accents
> (mainly the tilde) but don't use the other accents needed to be
> grammatically correct.
> 
> I could offer myself to correct the file, but I couldn't find the latest
> sources in order to send a patch.
> 
> Thanks in advance for your time.

Hi Rafael,

I would love your help here. I do not think we have the sources somewhere, if
you want to import it and fix the accents, I can import and start using your
repo as the upstream version.

Bug#909524: uscan: git mode broken

[Xavier Guimard]

Package: devscripts
Version: 2.18.4
Severity: normal

git mode uses --git-dit= but --git-dir must point to .git
subdir. Replace --git-dir by -C to fix paths

Simple example to reproduce this:

version=4
opts=\
uversionmangle=s/%25/~/,\
dversionmangle=s/\+dfsg\d*$//,\
repacksuffix=+dfsg1,\
mode=git,\
gitmode=shallow,\
filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/MuseScore-$1\.tar\.gz/ \
  https://github.com/musescore/MuseScore.git refs/tags/v([\d\.]+)
debian

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-6
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7
ii  python3   3.6.5-3
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.7.0~rc2
ii  at  3.1.23-1
ii  curl7.61.0-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2018.07.24
ii  dput-ng [dput]  1.21
ii  equivs  2.1.0
ii  fakeroot1.23-1
ii  file1:5.34-2
ii  gnupg   2.2.10-1
ii  libdistro-info-perl 0.18
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.35-2
ii  licensecheck3.0.31-2
ii  lintian 2.5.104
ii  man-db  2.8.4-2
ii  patch   2.7.6-3
ii  patchutils  0.3.4-2
ii  python3-apt 1.6.2
ii  python3-debian  0.1.33
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.18.4-2
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-4
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2+b1
ii  wget1.19.5-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
ii  adequate  0.15.1
ii  autopkgtest   5.5
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.5
pn  check-all-the-things  
pn  cvs-buildpackage  
pn  devscripts-el 
pn  diffoscope
pn  disorderfs
pn  dose-extra
ii  duck  0.13
pn  faketime  
pn  gnuplot   
ii  gpgv  2.2.10-1
pn  how-can-i-help
ii  libauthen-sasl-perl   2.1600-1
ii  libdbd-pg-perl3.7.4-1
ii  libfile-desktopentry-perl 0.22-1
ii  libnet-smtps-perl 0.09-1
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
pn  libyaml-syck-perl 
pn  mozilla-devscripts
ii  mutt  1.10.1-2
ii  openssh-client [ssh-client]   1:7.8p1-1
ii  piuparts  0.91
ii  postgresql-client-10 [postgresql-client]  10.5-1
ii  quilt 0.65-2
pn  ratt  
pn  reprotest 
pn  svn-buildpackage  
ii  w3m   0.5.3-36+b1

-- no debconf information

Bug#909510: please add a lintian note to inform/warn about python in the shebang (instead of python2/python2.7)

[Chris Lamb]

tags 909510 + moreinfo
thanks

Matthias,

> please add a lintian note to inform/warn about python in the shebang (instead 
> of
> python2/python2.7).

Thanks for this. Can you draft a very rough tag description for this?
Your following paragraph (re. easy and safe) seems to be a fairly good
place to start.

In addition, just checking that you mean "#!/usr/bin/python" vs "#!/
usr/bin/python2.7" (not "!#python" or somesuch).

Finally, linking to some good/bad packages in Debian would help us
prioritise this effectively.

> It would be nice if lintian could help with this task. Maybe first as a note 
> so
> we can get an overview.

Lintian does not have a concept of a "note" — in the interests of
clarity, you can confirm which severity level you are referring to?
(E:/W:/I:/P: etc.)


Regards,

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

Bug#909511: lintian: check for update-inetd --group without --add, --pattern with --add

[Chris Lamb]

tags 909511 + moreinfo
thanks

Hi Andreas,

> update-inetd got more strict recently w.r.t. valid option combinations

Thanks for this. Can you draft a very rough tag description for this?

I think I would also love to see which version got stricter (vs
"recently") — it is not immediately clear from my glance at the
changelog.

> I assume there might be packages not caught by piuparts if they use
> update-inetd in their maintainer scripts only if it is available.

Covering this angle would also required in the aforementioned
description.


Regards,

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

Bug#909523: cachefilesd broken by apparmor

[Anthony DeRobertis]

Package: cachefilesd
Version: 0.10.10-0.1
Severity: important

Important since Apparmor is on by default now.

I rebooted after enabling Apparmor, and cachefilesd wouldn't start:

Sep 24 13:53:17 Zia cachefilesd[1105]: About to bind cache
Sep 24 13:53:17 Zia kernel: CacheFiles: Security denies permission to nominate 
security context: error -2
Sep 24 13:53:17 Zia cachefilesd[1105]: CacheFiles bind failed: errno 2 (No such 
file or directory)
Sep 24 13:53:17 Zia cachefilesd[1052]: Starting FilesCache daemon : cachefilesd 
failed!
Sep 24 13:53:17 Zia systemd[1]: cachefilesd.service: Control process exited, 
code=exited status=1
Sep 24 13:53:17 Zia systemd[1]: cachefilesd.service: Failed with result 
'exit-code'.
Sep 24 13:53:17 Zia systemd[1]: Failed to start LSB: CacheFiles daemon.


Trying a few more times (after the system booted) also produced the same error 
each time:

Sep 24 13:57:12 Zia systemd[1]: Starting LSB: CacheFiles daemon...
Sep 24 13:57:13 Zia cachefilesd[6213]: About to bind cache
Sep 24 13:57:13 Zia cachefilesd[6213]: CacheFiles bind failed: errno 2 (No such 
file or directory)
Sep 24 13:57:13 Zia kernel: CacheFiles: Security denies permission to nominate 
security context: error -2
Sep 24 13:57:13 Zia cachefilesd[6208]: Starting FilesCache daemon : cachefilesd 
failed!
Sep 24 13:57:13 Zia systemd[1]: cachefilesd.service: Control process exited, 
code=exited status=1
Sep 24 13:57:13 Zia systemd[1]: cachefilesd.service: Failed with result 
'exit-code'.
Sep 24 13:57:13 Zia systemd[1]: Failed to start LSB: CacheFiles daemon.

Rebooting with apparmor=0 on the kernel command line makes it work
again.

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

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

Versions of packages cachefilesd depends on:
ii  libc6  2.27-6

cachefilesd recommends no packages.

cachefilesd suggests no packages.

-- Configuration Files:
/etc/cachefilesd.conf changed [not included]
/etc/default/cachefilesd changed [not included]
/etc/init.d/cachefilesd changed [not included]
/etc/logcheck/ignore.d.workstation/cachefilesd [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.workstation/cachefilesd'

-- no debconf information

Bug#894752: Bug#787774: giving up on packaging OpenPGP.js

[Antoine Beaupre]

On Thu, May 31, 2018 at 02:23:31PM -0400, Daniel Kahn Gillmor wrote:
> i don't currently have the time to maintain dozens of new node packages,
> unfortunately.

Hi Daniel!

I feel so sorry for you. I understand how you feel - packaging
Javascript stuff is hard in Debian! I have never managed to do anything
in there myself.

That said, I did spend a few minutes creating a task page here, as seems
to be the custom in the team:

https://wiki.debian.org/Javascript/Nodejs/Tasks/openpgp

It reused part of your RFPs (in CC) but somehow missed asmcrypto which I
added by hand. node-rusha also seems to be missing from the current
dependencies, so maybe that was fixed/changed.

Anways - from the looks of it, there are at least seven run-time
dependencies missing, and 26 (or more?) build-time depends missing.

And that's not counting the peculiarities of OpenPGP.js you found during
your work as well.

Hopefully some Debian JavaScript wizard can pick that up eventually!

A.


signature.asc
Description: PGP signature

Bug#905634: tasksel: Please remove dependency on manpages-fr in task-french (#871564)

[Holger Wansing]

Control: tags -1 + pending

Niels Thykier  wrote:
> > Niels Thykier  wrote:
> >> The manpages-fr package is outdated and unmaintained
> >> (defacto-orphaned too).
> >>
> >> Please remove the dependency on manpages-fr in task-french so we can
> >> remove the package from testing or the archive.
> > 
> > What about manpages-fr-extra?
> > It's the same maintainer and had no upload since 2015. Seems that above
> > arguments count for this package as well?
> > 
> > And this has already been reported in #871563.
> > 
> > Should we remove dependency for this one as well?
> > 
> > 
> > Holger
> > 
> > 
> 
> Hi Holger,
> 
> Yes, that would make sense.  :)
>   I did not notice it because I was checking for hard-depends (with
> manpages-fr-extra being a recommends).  Thanks for being thorough. :)
> 
> ~Niels

Fixed in GIT.

Tagging this bug as pending.


-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

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

Bug#909522: emacs-goodies-el: questionable Depends/Recommends

[Sven Joachim]

Package: emacs-goodies-el
Version: 41.0

There are several dependencies/recommendations in emacs-goodies-el which
look questionable to me.

- elpa-debian-el, elpa-dpkg-dev-el, elpa-devscripts:
  Those packages are the successors of debian-el, dpkg-dev-el and
  devscripts-el which used to be built from the emacs-goodies-el source
  package.  But the emacs-goodies-el _binary_ package in Stretch did not
  depend on those, so why have these dependencies be introduced now?

- bash (>= 2.05a) | bash-static, dpkg (>= 1.15.4) | install-info:
  This seems to be (harmless) cruft that should be removed.

- wget, perl-doc (both in Recommends):
  Probably useless for the few lisp files still shipped in
  emacs-goodies-el.  I think perl-doc was recommended because perldoc.el
  needed it, don't really know why wget was put into Recommends.

Bug#909521: libpython3.5-minimal: "Exception ignored in: .remove"

[Andreas Krüger]

Package: libpython3.5-minimal
Version: 3.5.3-1
Severity: normal
Tags: patch

I'm running ansible from a virtualenv based on Python 3.5
as installed via the python-3 package in Debian Stretch.

I frequently (though not on all runs) see the error

Exception ignored in: .remove at
0x7f749113bbf8>
Traceback (most recent call last):
  File "/home/andreas/.../lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable

I understand that a known bug is the culprit, which can be found at
https://bugs.python.org/issue29519

This bug has been fixed upstream with Python versions 3.5.4 and 3.6.1.
The Debian Stretch Python 3.5 packages are based on 3.5.3.

The fix is a two-line patch to weakref.py available at
https://hg.python.org/cpython/rev/2cb530243943 .

Workaround:

I applied this patch to the copy of this file available in my virtualenv,
(after replacing the symlink with an actual copy).
That cured my problem.

Regards, and thank you for providing fine software,

Andreas



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

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

Versions of packages libpython3.5-minimal depends on:
ii  libc6  2.24-11+deb9u3
ii  libssl1.1  1.1.0f-3+deb9u2

Versions of packages libpython3.5-minimal recommends:
ii  libpython3.5-stdlib  3.5.3-1

libpython3.5-minimal suggests no packages.

-- no debconf information




signature.asc
Description: OpenPGP digital signature

Bug#909520: xcircuit: Please package 3.9.73 (or newer stable) of xcircuit

[Ruben Undheim]

Package: xcircuit
Version: 3.8.78.dfsg-1+b2
Severity: wishlist

The version in Debian is almost 4 years old. Please package a new version from
the stable 3.9.x series.

Best regards
Ruben


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

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

Versions of packages xcircuit depends on:
ii  libc6  2.24-11+deb9u3
ii  libice62:1.0.9-2
ii  libsm6 2:1.2.2-1+b3
ii  libtcl8.6  8.6.6+dfsg-1+b1
ii  libtk8.6   8.6.6-1+b1
ii  libx11-6   2:1.6.4-3
ii  libxpm41:3.5.12-1
ii  libxt6 1:1.1.5-1
ii  tk [wish]  8.6.0+9
ii  zlib1g 1:1.2.8.dfsg-5

xcircuit recommends no packages.

xcircuit suggests no packages.

-- debconf-show failed

Bug#909519: xul-ext-treestyletab: the maintainer address needs to be changed

[shirish शिरीष]

Package: xul-ext-treestyletab
Version: 2.5.4-1
Severity: normal

Dear Maintainer,

Due to changes to alioth, the maintainer address has changed from
pkg-mozext-maintain...@lists.alioth.debian.org to
pkg-mozext-maintain...@alioth-lists.debian.net.

I had sent a mail of kudos for packaging the new version which bounced back.

Please change the maintainer address to reflect the new reality.

Last but not the least, thank you for packaging the treestyletab webextension :)

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

Kernel: Linux 4.18.0-1-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 xul-ext-treestyletab depends on:
ii  webext-treestyletab  2.5.4-1

xul-ext-treestyletab recommends no packages.

xul-ext-treestyletab suggests no packages.

-- no debconf information

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

Bug#909518: webext-noscript: ships file under /etc/iceweasel

[Sven Joachim]

Package: webext-noscript
Version: 10.1.9.6-1
Severity: normal

The webext-noscript package ships the file
/etc/iceweasel/searchplugins/common/opensearch_html.xml which it has
taken over from xul-ext-noscript.  This is rather useless because

a) firefox(-esr) does not look there
b) duckduckgo appears to works fine without JavaScript these days (there
   is a short flash since it redirects the browser to
   https://duckduckgo.com/html?q=)

My suggestion is to remove the file, since the reason for its creation
(#739395) does not apply anymore.


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

Kernel: Linux 4.18.9-nouveau (SMP w/2 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 webext-noscript depends on:
ii  firefox-esr  60.2.1esr-1

webext-noscript recommends no packages.

webext-noscript suggests no packages.

-- no debconf information

Bug#909515: xcircuit: watch file does not check for new versions in the stable series

[Ruben Undheim]

Package: xcircuit
Version: 3.8.78.dfsg-1+b2
Severity: important

Dear maintainer,

The watch file looks for packages in the 3.7.x series, while the current stable
series is 3.9.x. Development happens at 3.10.x.

There have not been any new versions in the 3.7.x series since 2014.

The version in Debian is from the 3.8.x series, but it is very old (Feb 2015).


Please fix the watch file to this:
  http://opencircuitdesign.com/xcircuit/archive/xcircuit-(3\.9\..*)\.tgz

Best regards
Ruben


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

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

Versions of packages xcircuit depends on:
ii  libc6  2.24-11+deb9u3
ii  libice62:1.0.9-2
ii  libsm6 2:1.2.2-1+b3
ii  libtcl8.6  8.6.6+dfsg-1+b1
ii  libtk8.6   8.6.6-1+b1
ii  libx11-6   2:1.6.4-3
ii  libxpm41:3.5.12-1
ii  libxt6 1:1.1.5-1
ii  tk [wish]  8.6.0+9
ii  zlib1g 1:1.2.8.dfsg-5

xcircuit recommends no packages.

xcircuit suggests no packages.

-- debconf-show failed

Bug#909514: hub: Incomplete debian/copyright?

[Chris Lamb]

Source: hub
Version: 2.4.0~ds1-1
Severity: normal
X-Debbugs-CC: Anthony Fok , ftpmas...@debian.org

Hi,

I just ACCEPTed hub from NEW but noticed it was missing attribution 
in debian/copyright in the sense that it does not cover that this is
a Go rewrite of some existing software.


Regards,

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

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Geoff Levand]

Hi Ben,

On 09/21/2018 04:20 PM, Ben Hutchings wrote:
> I've applied these, with some changes:
> 
> 0001: Rather than changing the setting of CONFIG_ACPI_NFIT for arm64, I
> removed it entirely as it would be redundant with the top-level config.
> 
> 0002: I dropped several of the config symbols which are automatic.  Any
> config symbol that doesn't have a description can only be enabled via
> other symbols that select it.  These shouldn't be mentioned in
> debian/config files.
> 
> I also removed CONFIG_ACPI_CONFIGFS as I have a concern that this
> feature allows subverting Secure Boot.  If this feature is important to
> you, I can investigate further and maybe add a patch to conditionally
> disable it at run-time instead.

The changes you've committed look fine.  I have no need for
CONFIG_ACPI_CONFIGFS.  If it seems a risk, then I think
it OK to have it disabled until a real need comes up.

-Geoff

Bug#909517: torify: does not expand shell aliases

[Jeff Cliff]

Package: tor
Version: 0.3.4.8-1
Severity: normal

Dear Maintainer,

It is often handy to create shell aliases to do tasks that would otherwise 
require a lot
of retyping the same thing over and over.  For example 'git push' might very 
well be
aliased to 'push' at the shell level by 

alias push='git push'

then you could conceivably use 

> torify push 

as a shorthand for 

> torify git push 

this however fails: torify does not expand the aliases and doesn't know what 
'push' is.

As mentioned in the ubuntu downstream bug ( 
https://bugs.launchpad.net/ubuntu/+source/tor/+bug/1687037 )
it doesn't matter what shell you use, torify just doesn't check.

what happens: torify takes the arguments passed in without checking if there 
are aliases involved
what should happen: is torify should be alias-aware.

tor:Installed: 0.3.4.8-1
debian: buster

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

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

Versions of packages tor depends on:
ii  adduser 3.117
ii  libc6   2.27-6
ii  libcap2 1:2.25-1.2
ii  libevent-2.1-6  2.1.8-stable-4
ii  liblzma55.2.2-1.3
ii  libseccomp2 2.3.3-3
ii  libssl1.1   1.1.0h-4
ii  libsystemd0 239-9
ii  libzstd11.3.5+dfsg-1
ii  lsb-base9.20170808
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages tor recommends:
ii  logrotate3.14.0-4
ii  tor-geoipdb  0.3.4.8-1
ii  torsocks 2.2.0-2

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
pn  socat
pn  tor-arm  
pn  torbrowser-launcher  

-- no debconf information

Bug#884048: gnome-shell: /usr/lib/gnome-shell/gnome-shell-calendar-server continually crashes with segfault

[Jeremy Bicha]

I don't think there's anything else that needs to be done here in
libcal3. Can we close this bug now?

Thanks,
Jeremy Bicha

Bug#882287: fixed in mozilla-noscript 10.1.9.6-1

[Jiri Palecek]

Hello

On 9/24/18 11:00 AM, Ximin Luo wrote:

Source: mozilla-noscript
Source-Version: 10.1.9.6-1



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 22 Sep 2018 23:25:18 -0700
Source: mozilla-noscript
Binary: webext-noscript xul-ext-noscript
Architecture: source all
Version: 10.1.9.6-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Ximin Luo 
Description:
  webext-noscript - permissions manager for Firefox
  xul-ext-noscript - Show browser tabs like a tree - transitional package


Show browser tabs like a tree? I don't think so.

Please correct that.

Regards

    Jiri Palecek

Bug#909516: cowpatty: Homepage field 404s

[Chris Lamb]

Source: cowpatty
Version: 4.8-1
Severity: wishlist
X-Debbugs-CC: Samuel Henrique , 
ftpmas...@debian.org

Hi,

I just ACCEPTed cowpatty from NEW but was wondering if you could fix
the Homepage: field which does not work for me:

  http://www.willhackforsushi.com/Cowpatty.html


Regards,

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

Bug#909513: mutt-alias-el: Please obey "nodoc" build profile

[Chris Lamb]

Source: mutt-alias-el
Version: 1.5-1
Severity: wishlist
X-Debbugs-CC: Nicholas D Steeves , 
ftpmas...@debian.org

Hi,

I just ACCEPTed mutt-alias-el from NEW but was wondering if you could
ensure "nodoc" is obeyed:

  8 override_dh_auto_build:
  9 makeinfo mutt-alias.texi
 10 dh_auto_build


Regards,

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

Bug#908935: repository for working on this

[Jeffrey Cliff]

Please consider not using github for your working on packaging.  There are
non-microsoft platforms available for others to follow your efforts.

https://notabug.org/themusicgod1/azure-storage-blob-go

in particular is here for you.

Jeff Cliff
-- 
GENERATION 26: The first time you see this, copy it into your sig on any
forum and add 1 to the generation

Bug#909512: python-argon2: Incomplete debian/copyright?

[Chris Lamb]

Source: python-argon2
Version: 18.1.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Nicolas Dandrimont , 
ftpmas...@debian.org

Hi,

I just ACCEPTed python-argon2 from NEW but noticed it was missing 
some attribution in debian/copyright for the "original Argon2 repo".

It would be great if you could ensure this is more explicitly mention
in debian/copyright, perhaps in the Comment field or similar.

(This is in no way exhaustive so please check over the entire package 
carefully and address this or anything else on your next upload.)


Regards,

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