Bug#887871: nftables nat postrouting not working

[denis]

Package: nftables
Version: 0.7-1 amd64



Hi
I migrated my iptables rules using iptables-migrate to nftables, but 
these two rules are not working under nftables:

---
chain postrouting {
type nat hook postrouting priority 100; policy accept;
ip saddr 10.9.0.0/24 ip daddr != 10.9.0.0/24 counter packets 0 
bytes 0 snat to 81.9.12.52
ip saddr 10.8.0.0/24 ip daddr != 10.8.0.0/24 counter packets 0 
bytes 0 snat to 81.9.12.52

}
---

under iptables they are like:

---
Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination
MASQUERADE  all  --  172.17.0.0/16anywhere
SNAT   all  --  10.8.0.0/24 !10.8.0.0/24  
to:81.9.12.52
SNAT   all  --  10.9.0.0/24 !10.9.0.0/24  
to:81.9.12.52

---


# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

# uname -a
Linux podciarou 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) 
x86_64 GNU/Linux


# nft -v
nftables v0.7 (Scrooge McDuck)

# iptables --version
iptables v1.6.0

Bug#886758: New version 1.8.4 available

[Peter Spiess-Knafl]

I will take care of it.

> Am 09.01.2018 um 16:52 schrieb Yangfl :
> 
> Package: libjsoncpp
> Version: 1.7.4-3
> 
> The current Debian version is outdated. Since I'm packing
> https://github.com/avast-tl/retdec-config which require 1.8.4, it
> would be nice to update it to the current upstream one.
> 
> Thanks,



signature.asc
Description: Message signed with OpenPGP

Bug#887870: RFS: pcc/1.2.0~DEVEL+20180120-1 [ITP]

[Yangfl]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: pcc
   Version : 1.2.0~DEVEL+20180120-1
   Upstream Author : Anders Magnusson <ra...@ludd.ltu.se>
 * URL : http://pcc.ludd.ltu.se/
 * License : BSD
   Section : devel

It builds those binary packages:

  pcc   - Portable C Compiler

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pcc/pcc_1.2.0~DEVEL+20180120-1.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

[your most recent changelog entry]


Regards,
 Yangfl

Bug#887869: python-filelock FTBFS: test failures

[Adrian Bunk]

Source: python-filelock
Version: 3.0.0-1
Severity: serious

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

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/python-filelock-3.0.0'
PYTHONPATH=. python2 /build/1st/python-filelock-3.0.0/debian/test.py
.FF..FF...
==
FAIL: test_threaded1 (__main__.FileLockTest)
--
Traceback (most recent call last):
  File "/build/1st/python-filelock-3.0.0/debian/test.py", line 228, in 
test_threaded1
threads1[i].join()
  File "/build/1st/python-filelock-3.0.0/debian/test.py", line 61, in join
raise (wrapper_ex.__class__, wrapper_ex, self.ex[2])
AssertionError

==
FAIL: test_timeout (__main__.FileLockTest)
--
Traceback (most recent call last):
  File "/build/1st/python-filelock-3.0.0/debian/test.py", line 248, in 
test_timeout
self.assertRaises(filelock.Timeout, lock2.acquire, timeout=1)
AssertionError: Timeout not raised

==
FAIL: test_default_timeout (__main__.SoftFileLockTest)
--
Traceback (most recent call last):
  File "/build/1st/python-filelock-3.0.0/debian/test.py", line 273, in 
test_default_timeout
self.assertRaises(filelock.Timeout, lock2.acquire)
AssertionError: Timeout not raised

==
FAIL: test_del (__main__.SoftFileLockTest)
--
Traceback (most recent call last):
  File "/build/1st/python-filelock-3.0.0/debian/test.py", line 330, in test_del
self.assertRaises(filelock.Timeout, lock2.acquire, timeout = 1)
AssertionError: Timeout not raised

--
Ran 22 tests in 19.163s

FAILED (failures=4)
debian/rules:12: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#887868: libgnomecanvas FTBFS with gtk-doc-tools 1.27-1

[Adrian Bunk]

Source: libgnomecanvas
Version: 2.30.3-3
Severity: serious
Tags: buster sid

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

...
Making all in reference
make[4]: Entering directory '/build/1st/libgnomecanvas-2.30.3/docs/reference'
gtk-doc: Scanning header files
gtk-doc: Building XML
./libgnomecanvas.args:7: warning: Property GnomeCanvasBpath:bpath has no 
documentation.
./libgnomecanvas.args:17: warning: Property GnomeCanvasClipgroup:path has no 
documentation.
./libgnomecanvas.args:27: warning: Property GnomeCanvasClipgroup:wind has no 
documentation.
./libgnomecanvas.args:47: warning: Property GnomeCanvas:focused-item has no 
documentation.
./libgnomecanvas.args:77: warning: Property GnomeCanvasItem:parent has no 
documentation.
./libgnomecanvas.args:87: warning: Property GnomeCanvasLine:arrow-shape-a has 
no documentation.
./libgnomecanvas.args:97: warning: Property GnomeCanvasLine:arrow-shape-b has 
no documentation.
./libgnomecanvas.args:107: warning: Property GnomeCanvasLine:arrow-shape-c has 
no documentation.
./libgnomecanvas.args:117: warning: Property GnomeCanvasLine:cap-style has no 
documentation.
./libgnomecanvas.args:127: warning: Property GnomeCanvasLine:fill-color has no 
documentation.
./libgnomecanvas.args:137: warning: Property GnomeCanvasLine:fill-color-gdk has 
no documentation.
./libgnomecanvas.args:147: warning: Property GnomeCanvasLine:fill-color-rgba 
has no documentation.
./libgnomecanvas.args:157: warning: Property GnomeCanvasLine:fill-stipple has 
no documentation.
./libgnomecanvas.args:167: warning: Property GnomeCanvasLine:first-arrowhead 
has no documentation.
./libgnomecanvas.args:177: warning: Property GnomeCanvasLine:join-style has no 
documentation.
./libgnomecanvas.args:187: warning: Property GnomeCanvasLine:last-arrowhead has 
no documentation.
./libgnomecanvas.args:197: warning: Property GnomeCanvasLine:line-style has no 
documentation.
./libgnomecanvas.args:207: warning: Property GnomeCanvasLine:points has no 
documentation.
./libgnomecanvas.args:217: warning: Property GnomeCanvasLine:smooth has no 
documentation.
./libgnomecanvas.args:227: warning: Property GnomeCanvasLine:spline-steps has 
no documentation.
./libgnomecanvas.args:237: warning: Property GnomeCanvasLine:width-pixels has 
no documentation.
./libgnomecanvas.args:247: warning: Property GnomeCanvasLine:width-units has no 
documentation.
./libgnomecanvas.args:257: warning: Property GnomeCanvasPixbuf:anchor has no 
documentation.
./libgnomecanvas.args:267: warning: Property GnomeCanvasPixbuf:height has no 
documentation.
./libgnomecanvas.args:277: warning: Property GnomeCanvasPixbuf:height-in-pixels 
has no documentation.
./libgnomecanvas.args:287: warning: Property GnomeCanvasPixbuf:height-set has 
no documentation.
./libgnomecanvas.args:297: warning: Property GnomeCanvasPixbuf:pixbuf has no 
documentation.
./libgnomecanvas.args:307: warning: Property GnomeCanvasPixbuf:width has no 
documentation.
./libgnomecanvas.args:317: warning: Property GnomeCanvasPixbuf:width-in-pixels 
has no documentation.
./libgnomecanvas.args:327: warning: Property GnomeCanvasPixbuf:width-set has no 
documentation.
./libgnomecanvas.args:337: warning: Property GnomeCanvasPixbuf:x has no 
documentation.
./libgnomecanvas.args:347: warning: Property GnomeCanvasPixbuf:x-in-pixels has 
no documentation.
./libgnomecanvas.args:357: warning: Property GnomeCanvasPixbuf:y has no 
documentation.
./libgnomecanvas.args:367: warning: Property GnomeCanvasPixbuf:y-in-pixels has 
no documentation.
./libgnomecanvas.args:377: warning: Property GnomeCanvasPolygon:points has no 
documentation.
./libgnomecanvas.args:387: warning: Property GnomeCanvasRE:x1 has no 
documentation.
./libgnomecanvas.args:397: warning: Property GnomeCanvasRE:x2 has no 
documentation.
./libgnomecanvas.args:407: warning: Property GnomeCanvasRE:y1 has no 
documentation.
./libgnomecanvas.args:417: warning: Property GnomeCanvasRE:y2 has no 
documentation.
./libgnomecanvas.args:627: warning: Property GnomeCanvasShape:cap-style has no 
documentation.
./libgnomecanvas.args:637: warning: Property GnomeCanvasShape:dash has no 
documentation.
./libgnomecanvas.args:647: warning: Property GnomeCanvasShape:fill-color has no 
documentation.
./libgnomecanvas.args:657: warning: Property GnomeCanvasShape:fill-color-gdk 
has no documentation.
./libgnomecanvas.args:667: warning: Property GnomeCanvasShape:fill-color-rgba 
has no documentation.
./libgnomecanvas.args:677: warning: Property GnomeCanvasShape:fill-stipple has 
no documentation.
./libgnomecanvas.args:687: warning: Property GnomeCanvasShape:join-style has no 
documentation.
./libgnomecanvas.args:697: warning: Property GnomeCanvasShape:miterlimit has no 
documentation.
./libgnomecanvas.args:707: warning: Property GnomeCanvasShape:outline-color has 
no documentation.
./libgnomecanvas.args:717: warning: Property GnomeCanvasShape:outline-color-gdk 
has no documentation.
./libgnomecanvas.args:727: 

Bug#887866: cxref FTBFS on amd64/i386 with glibc 2.26

[Adrian Bunk]

Source: cxref
Version: 1.6e-2
Severity: serious
Tags: buster sid

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

...
../src/cxref -O. -NREADME-TMP -xref README.c
/usr/include/x86_64-linux-gnu/bits/mathcalls-helper-functions.h:21: cxref: 
syntax error, unexpected IDENTIFIER, expecting ')'

The previous 10, current and next 10 symbols are:
-10 | 297 : LONG : long
 -9 | 301 :   DOUBLE : double
 -8 | 258 :   IDENTIFIER : __n
 -7 |  41 :  ')' : )
 -6 |  59 :  ';' : ;
 -5 | 286 :   EXTERN : extern
 -4 | 296 :  INT : int
 -3 | 258 :   IDENTIFIER : __fpclassifyf128
 -2 |  40 :  '(' : (
 -1 | 258 :   IDENTIFIER : _Float128
  0 | 258 :   IDENTIFIER : __value
  1 |  41 :  ')' : )
  2 |  59 :  ';' : ;
  3 | 286 :   EXTERN : extern
  4 | 296 :  INT : int
  5 | 258 :   IDENTIFIER : __signbitf128
  6 |  40 :  '(' : (
  7 | 258 :   IDENTIFIER : _Float128
  8 | 258 :   IDENTIFIER : __value
  9 |  41 :  ')' : )
 10 |  59 :  ';' : ;

../src/cxref -O. -NREADME-TMP -xref README.c -latex -html-src -rtf -sgml
/usr/include/x86_64-linux-gnu/bits/mathcalls-helper-functions.h:21: cxref: 
syntax error, unexpected IDENTIFIER, expecting ')'

The previous 10, current and next 10 symbols are:
-10 | 297 : LONG : long
 -9 | 301 :   DOUBLE : double
 -8 | 258 :   IDENTIFIER : __n
 -7 |  41 :  ')' : )
 -6 |  59 :  ';' : ;
 -5 | 286 :   EXTERN : extern
 -4 | 296 :  INT : int
 -3 | 258 :   IDENTIFIER : __fpclassifyf128
 -2 |  40 :  '(' : (
 -1 | 258 :   IDENTIFIER : _Float128
  0 | 258 :   IDENTIFIER : __value
  1 |  41 :  ')' : )
  2 |  59 :  ';' : ;
  3 | 286 :   EXTERN : extern
  4 | 296 :  INT : int
  5 | 258 :   IDENTIFIER : __signbitf128
  6 |  40 :  '(' : (
  7 | 258 :   IDENTIFIER : _Float128
  8 | 258 :   IDENTIFIER : __value
  9 |  41 :  ')' : )
 10 |  59 :  ';' : ;

mv README.c.tex README_c.tex
mv: cannot stat 'README.c.tex': No such file or directory
Makefile:100: recipe for target 'readme' failed
make[2]: *** [readme] Error 1

Bug#884796: preliminary packaging

[Jeffrey Cliff]

haven't got very far, but made it as far as the alpha release 0.0.1 in
terms of getting an installing package together. alpha release 0.0.1 really
doesn't look like it's the whole project, but it's a start - -

https://github.com/themusicgod1/py-evm/tree/debian1

hopefully that helps
Jeff Cliff

Bug#887787: [pkg-lxc-devel] Bug#887787: Bug#887787: lxc: CentOS 7 amd64 container can't be stoppedk you o o

[Bob]

Apologies, that was my phone typing from my pocket.

On 21 Jan. 2018 4:51 pm, "Bob"  wrote:

> tgi
>
> ___
> Pkg-lxc-devel mailing list
> pkg-lxc-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-lxc-devel
>
>

Bug#884294: Patch for pandas RC 884294, someone to sponsor?

[Lumin]

> I'd volunteer to upload once it is pushed.  Please ping me after pushing
> since there is not commit mailing list and I'm not sure whether the
> tracker solution is implemented yet.

Done.
https://salsa.debian.org/science-team/pandas/commits/debian

-- 
Best,

Bug#887787: [pkg-lxc-devel] Bug#887787: lxc: CentOS 7 amd64 container can't be stoppedk you o o

[Bob]

tgi

Bug#887660: RFS: minidb/2.0.2-1 [ITP]

[Paul Wise]

Control: owner -1 !
Control: tags -1 + moreinfo

I intend to sponsor this because the urlwatch RFS needs it.

On Fri, Jan 19, 2018 at 4:42 AM, Maxime Werlen wrote:

> I am looking for a sponsor for my package "minidb"

In future, I'd recommend using the BTS block command when filing an RFS
that depends on another RFS.

https://www.debian.org/Bugs/server-control#block

You can use this syntax when mailing submit@ or existing bugs (-1 means
the bug you are mailing or submitting):

Control: block 887659 by -1

These issues block the upload of minidb to Debian:

Since minidb only includes a Python 3 module, you need to rename the
binary package to python3-minidb. The source package can stay the same.

The orig.tar.gz you uploaded to Debian mentors is different to the one
that the debian/watch file downloads. You can use diffoscope to see the
differences, but it looks like you used the one from pip? That is
missing example.py but has a new PKG-INFO file.

It would be nice to fix these issues at some point:

Upstream is using distutils but debian/control has python3-setuptools.
The package still builds because python3-distutils is installed anyway.

Please include example.py from the github tar.gz as an example in the
binary package, using dh_installexamples.

Once minidb is accepted, please file a bug against gpodder asking the
maintainer to depend on minidb instead of using the internal copy.

I suggest licensing the debian/ directory under the same license as
upstream, so that they can include any patches or other info from
Debian with zero friction.

Please remove the comment characters, the ASCII minidb logo and the
Copyright line from the ISC license in debian/copyright.

Please remove the commented-out Vcs-* fields from debian/control unless
you intend to use them, please note that alioth has been replaced by
salsa.debian.org.

I like to wrap and sort the debian/ directory:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages 
--trailing-comma

I like to wrap debian/watch to separate fields.

uscan fails unless I delete the filenamemangle:

$ uscan --verbose --download-current-version --destdir .
...
Could not read .//thp/minidb/archive/minidb-2.0.2.tar.gz: No such file or 
directory at /usr/bin/mk-origtargz line 397.
uscan: error: mk-origtargz --package minidb --version 2.0.2 --rename 
--compression gzip --directory . --copyright-file debian/copyright 
.//thp/minidb/archive/minidb-2.0.2.tar.gz subprocess returned exit status 2

Please add some upstream metadata:

https://wiki.debian.org/UpstreamMetadata

Please ask upstream to sign their commits and tarballs with OpenPGP:

https://mikegerwitz.com/papers/git-horror-story
https://wiki.debian.org/Creating%20signed%20GitHub%20releases

Automatic checks:

lintian

I: minidb source: binary-control-field-duplicates-source field "section" in 
package minidb
P: minidb source: file-contains-trailing-whitespace debian/changelog (line 3)
P: minidb source: file-contains-trailing-whitespace debian/control (line 4)
P: minidb source: package-uses-old-debhelper-compat-version 10
P: minidb source: insecure-copyright-format-uri 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
I: minidb source: testsuite-autopkgtest-missing
P: minidb source: debian-watch-may-check-gpg-signature
P: minidb: no-upstream-changelog
I: minidb: extended-description-is-probably-too-short

check-all-the-things

$ env PERL5OPT=-m-lib=. duck
I: debian/copyright:1: URL: 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/: INFORMATION 
(Certainty:possible)
   URL schema changed from HTTP to HTTPS during redirect(s): 
http://www.debian.org -> https://www.debian.org
   Please investigate and update the URL eventually, to avoid unneccesary 
redirects!

I: debian/copyright:48: URL: http://www.gnu.org/licenses/: INFORMATION 
(Certainty:possible)
   The web page at http://www.gnu.org/licenses/ works, but is also available 
via https://www.gnu.org/licenses/, please consider switching to HTTPS urls.

I: debian/control: Homepage: http://thp.io/2010/minidb/: INFORMATION 
(Certainty:certain)
   URL schema changed from HTTP to HTTPS during redirect(s): http://thp.io -> 
https://thp.io
   Please investigate and update the URL eventually, to avoid unneccesary 
redirects!

# check if these can be switched to https://
$ grep -nHrF http: .
./PKG-INFO:5:Home-page: http://thp.io/2010/minidb/
./PKG-INFO:9:Download-URL: http://thp.io/2010/minidb/minidb-2.0.2.tar.gz
./test/test_minidb.py:277:# 
http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ever
./debian/copyright:1:Format: 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
./debian/copyright:48: along with this program. If not, see 

./debian/control:9:Homepage: http://thp.io/2010/minidb/
./debian/control:11:#Vcs-Browser: 
http://git.debian.org/?p=collab-maint/minidb.git;a=summary
./minidb.py:27:__url__ = 'http://thp.io/2010/minidb/'

$ find . -type f -iname '*.py' 

Bug#887817: lintian: check for patches present in debian/patches/ but missing from the series file

[Chris Lamb]

tags 887817 + pending
thanks

Fixed in Git:

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


Regards,

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

Bug#887863: Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Guillem Jover]

On Sun, 2018-01-21 at 02:59:53 +0100, Andreas Beckmann wrote:
> Control: clone -1 -2
> Control: retitle -2 libglib2.0-dev: needs dummy empty prerm
> Control: reassign -2 libglib2.0-dev 2.54.2-1
> 
> >> On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:>>> For 
> >> now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
> Even if python is going to get fixed, this probably won't help
> libglib2.0-dev (which drops the python dependency in buster), therefore
> it will need to add the dummy empty prerm to mitigate this issue.

I don't see why this would be needed. If python gets fixed to use
Pre-Depends, then it does not matter whether libglib2.0-dev stops
depending on it, as python should then be always usable even when
just unpacked.

Thanks,
Guillem

Bug#887197: ansible should depend on e2fsprogs explicitly

[Harlan Lieberman-Berg]

On Fri, Jan 19, 2018 at 8:04 PM, Andreas Henriksson  wrote:
> In summary there are mainly two cases to consider here. Would be great
> to hear from maintainer(s) what their thought is on how to best see
> this through. Without further input I'd say a Depends on e2fsprogs
> is likely the best solution.

Because of the purpose of the tool, I think a Depends on e2fsprogs is
the best way to go.  It's not strictly required for all functionality,
but there's enough basic stuff that I think the principle of least
surprise tells us to go in that direction.

Either myself or Lee Garrett will add the Depends in the next upload.

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#887865: shimdandy FTBFS with libclojure-java 1.9.0~alpha15-1

[Adrian Bunk]

Source: shimdandy
Version: 1.2.0-1
Severity: serious

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

...
[WARNING] The POM for org.clojure:clojure:jar:1.8.x is missing, no dependency 
information available
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] shimdandy-api .. SUCCESS [  2.595 s]
[INFO] shimdandy-impl . FAILURE [  0.013 s]
[INFO] shimdandy-parent ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 2.847 s
[INFO] Finished at: 2019-02-18T00:38:30-12:00
[INFO] Final Memory: 17M/591M
[INFO] 
[ERROR] Failed to execute goal on project shimdandy-impl: Could not resolve 
dependencies for project org.projectodd.shimdandy:shimdandy-impl:jar:1.2.0: 
Cannot access central (https://repo.maven.apache.org/maven2) in offline mode 
and the artifact org.clojure:clojure:jar:1.8.x has not been downloaded from it 
before. -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :shimdandy-impl
dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
 -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/build/1st/shimdandy-1.2.0 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/build/1st/shimdandy-1.2.0/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/build/1st/shimdandy-1.2.0/debian 
-Dmaven.repo.local=/build/1st/shimdandy-1.2.0/debian/maven-repo --batch-mode 
package -DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1
debian/rules:4: recipe for target 'build' failed
make: *** [build] Error 2

Bug#887864: libint1 lost/renamed libraries without changing the package name

[Adrian Bunk]

Package: libint1
Version: 1.2.1-1
Severity: serious
Control: affects -1 src:ghemical

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

...
libtool: link: g++ -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z -Wl,relro -Wl,--as-needed -o ghemical fileio.o 
filetrans.o custom_app.o custom_camera.o custom_lights.o project.o spline.o 
pangofont_wcl.o oglview_wcl.o ac_stor_wcl.o p1dview_wcl.o p2dview_wcl.o 
eldview_wcl.o rcpview_wcl.o gpcview_wcl.o ogl_plane.o ogl_surface.o 
ogl_ribbon.o gtk_simple_dialogs.o gtk_glade_dialog.o gtk_file_export_dialog.o 
gtk_file_import_dialog.o gtk_geomopt_dialog.o gtk_moldyn_dialog.o 
gtk_progress_dialog.o gtk_setup_dialog.o gtk_stereo_dialog.o 
gtk_trajview_dialog.o gtk_wnd.o gtk_oglview_wnd.o gtk_p1dview_wnd.o 
gtk_p2dview_wnd.o gtk_eldview_wnd.o gtk_rcpview_wnd.o gtk_gpcview_wnd.o 
gtk_app.o gtk_project.o gtk_main.o -pthread -Wl,--export-dynamic -pthread  -lm 
-L/usr/X11R6/lib -lgthread-2.0 /usr/lib/x86_64-linux-gnu/libgtkglext-x11-1.0.so 
/usr/lib/x86_64-linux-gnu/libgdkglext-x11-1.0.so -lXmu -lXt -lSM -lICE 
-lpangox-1.0 -lX11 -lgmodule-2.0 -lglade-2.0 -lgtk-x11-2.0 -lgdk-x11-
 2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 
-lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig 
/usr/lib/x86_64-linux-gnu/libfreetype.so -lxml2 -lopenbabel -lghemical 
-lSCmbptr12 -lSCcints -lSCmbpt -lSCpsi -lSCdft -lSCscf -lSCwfn -lSCintv3 
-lSCbasis -lSCoint3 -lSCsolvent -lSCmolecule -lSCisosurf -lSCoptimize 
-lSCsymmetry -lSCscmat -lSCoptions -lSCgroup -lSCrender -lSCmisc -lSCstate 
-lSCkeyval -lSCclass -lSCcontainer -lSCref -lmopac7 -lGL -lGLU -loglappth 
-pthread
/usr/bin/ld: warning: libint-stable.so.1, needed by 
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so, not found (try 
using -rpath or -rpath-link)
/usr/bin/ld: warning: libr12-stable.so.1, needed by 
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so, not found (try 
using -rpath or -rpath-link)
/usr/bin/ld: warning: libderiv-stable.so.1, needed by 
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so, not found (try 
using -rpath or -rpath-link)
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so: undefined 
reference to `init_libint'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so: undefined 
reference to `init_libint_base'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so: undefined 
reference to `build_eri'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so: undefined 
reference to `libint_storage_required'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so: undefined 
reference to `build_r12_grt'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so: undefined 
reference to `libr12_storage_required'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so: undefined 
reference to `free_libint'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so: undefined 
reference to `init_libr12'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so: undefined 
reference to `free_libr12'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libSCcints.so: undefined 
reference to `init_libr12_base'
collect2: error: ld returned 1 exit status
Makefile:571: recipe for target 'ghemical' failed
make[4]: *** [ghemical] Error 1

Bug#860304: flash-kernel: Incorrect installation path for dtbs

[Heinrich Schuchardt]

With git HEAD the Odroid C2 now boots correctly.

Thank you for solving this issue.

Tested-by: Heinrich Schuchardt 

Bug#844788: Still failing hibernate/resume with stretch backport kernel linux-image-4.14.0-0.bpo.3-amd64

[Andrew Worsley]

Again on resume it just says "resume: Image successfully loaded" and
then nothing much See previous  image attached.
 I do get an additional interrupt related message when I plug in and
then remove my USB ethernet device.
So it seems the system is running but the display is not working.

I can reboot the laptop by ctrl-alt-del key combination which
apparently causes it to reboot.

Andrew

Bug#886897: samba: samba cannot export LUKs encrypted disks mounted manually after systemd boot

[Michael Biebl]

On Thu, 11 Jan 2018 13:58:56 +1100 David Maslen  wrote:
> Package: samba
> Version: 2:4.7.3+dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> I recently added a LUKS encrypted data disk to my system working system.
> I have samba configured to share some of the directories from that disk,
> mounted at /mnt/crypt.
> 
> By default, when my system boots I am prompted to enter my LUKs
> password. When I do, the systemd boots and samba serves the /mnt/crypt
> directories. My encrypted disks is mounted via the fstab, via the cryptab.
> 
> However the server is generally headless, so it suited me better to boot
> the machine remotely, then ssh in and mount the encypted data disk
> manually.
> 
> To achieve this I added "noauto" to the relevant line in /etc/crypttab
> and /etc/fstab.
> 
> Once logged in I could run
> # cryptdisks_start mydisk
> 
> followed by
> 
> # mount /mnt/crypt

This is most likely a duplicate of #885325

Please make sure that systemd is updated to 236-3 and test again.

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



signature.asc
Description: OpenPGP digital signature

Bug#871425: w3m can not be used in unwritable $HOME

[Tatsuya Kinoshita]

Control: tags -1 + pending

On August 7, 2017 at 5:30PM -0400, osamu (at debian.org) wrote:
> http://aws-logs.debian.net/2017/08/05/maint-guide_1.2.39_unstable.log
>
> Here, w3m is choking when $HOME is not writable.
>
> If unwritable, this should move on without choking.
>
> This is very annoying to get packahe build under some chroot test for
> reproducible build.

Fixed in the Git repo.

  - 
https://salsa.debian.org/debian/w3m/commit/b592dac63b39fba505525b0cee1d914182e825ff

Will be fixed in the next upload.

Thanks,
--
Tatsuya Kinoshita


pgp34ZE_cHrIO.pgp
Description: PGP signature

Bug#870844: Adopting pytest-xdist

[Scott Talbert]

Hi,

I'm willing to adopt pytest-xdist.

Scott

Bug#865673: umask

[Anthony Donegan]

This bug destroys umask privacy in multi-user systems and it is 
surprising that Debian did not announce this in the Stretch release 
notes and seems unconcerned about solving the problem.


Ubuntu seem similarly unconcerned about breaking umask and making all 
files world readable 
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1685754


Why?

Bug#849752: Hitting this bug

[Daniel Leidert]

Hi,

I'm also hitting this issue. I'm building the packages with pbuilder.
Interestingly the issue currently disappears when using 'lintian -
--keep-lab'.

Regards, Daniel

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

Bug#849752: Hitting this bug

[Daniel Leidert]

Am Sonntag, den 21.01.2018, 02:56 +0100 schrieb Daniel Leidert:
> 
> I'm also hitting this issue. I'm building the packages with pbuilder.
> Interestingly the issue currently disappears when using 'lintian
> - --keep-lab'.

Forget this. The issue is still there, independent from the mentioned
options. My mistake.

Regards, Daniel

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Andreas Beckmann]

Control: clone -1 -2
Control: retitle -2 libglib2.0-dev: needs dummy empty prerm
Control: reassign -2 libglib2.0-dev 2.54.2-1

>> On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:>>> For 
>> now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
Even if python is going to get fixed, this probably won't help
libglib2.0-dev (which drops the python dependency in buster), therefore
it will need to add the dummy empty prerm to mitigate this issue.


Andreas

Bug#885525: nm-applet crashes when connecting to VPN

[Leonardo Franchi Zeclhynscki]

glad this is fixed, what is the ETA for it making to debian buster repos? 
should I install directly from sid?

Bug#884003: FDT overlay support

[Vagrant Cascadian]

On 2017-12-12, Andre Heider wrote:
> Subject: [PATCH 06/10] beaglebone: clean up boot script
>
> Use $fk_image_locations and distro compatible variable names, get rid
> of the duplicated code from bootscr.uboot-generic, and use that script
> additionally instead.
>
> Signed-off-by: Andre Heider 
> ---
>  bootscript/armhf/bootscr.beaglebone | 49 
> +
>  db/all.db   |  4 +--
>  2 files changed, 8 insertions(+), 45 deletions(-)
>
> diff --git a/bootscript/armhf/bootscr.beaglebone 
> b/bootscript/armhf/bootscr.beaglebone
> index edc1cd0..f04532d 100644
> --- a/bootscript/armhf/bootscr.beaglebone
> +++ b/bootscript/armhf/bootscr.beaglebone
...
> -if test "${devnum}" = ""
> -then
> -  setenv partition ${bootpart}
> -elif test "${distro_bootpart}" = ""
> -then
> -  # use partition provided by bootpart
> -  setenv partition ${devnum}:${bootpart}
> -else
> -  # use partition provided by distro_bootpart
> -  setenv partition ${devnum}:${distro_bootpart}
> +if test -z "${devtype}"; then
> +  setenv devtype "mmc"
>  fi
...
> +if test -z "${devnum}"; then
> +  setenv devnum ${bootpart}
>  fi

I just realized that the handling of bootpart is incorrect here...

Before distro_bootcmd support was added, bootpart sometimes contained
both a device number and a the partition:

  bootpart=0:1

Then, distro_bootcmd support was added, and it changed to:

  bootpart=1

But that broke legacy scripts, so distro_bootpart was added:

  distro_bootpart=1

This will result in this expanding incorrectly:

  load ${devtype} ${devnum}:${partition} 

To render as this in the legacy case:

  load mmc 0:1:0:1 


I haven't figured out in u-boot's shell how to extract parts of
variables, and we're dealing with legacy versions of
u-boot... so... hrm.

This is a similar problem with the legacy u-boot-sunxi support in the
bootscr.sunxi with the "partition" variable.

Supporting legacy u-boot variables is a tangled mess, but u-boot is
definitely something people might be hesitant to update, at risk of
bricking a system.


live well,
  vagrant


signature.asc
Description: PGP signature

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

[Marco]

On Sun, 14 Jan 2018 18:52:03 -0300 Marco  wrote:
> This issue is not solved for me, running thunderbird's latest version on
> Sid's repository.
>
> I run an XFCE DE with no Display Manager. I login in a tty, and then
> startx. Maybe it has something to do with that.
>
> As for the other binaries suggested to run here, I have no different
> results. And line "deny @{HOME}/.* r" is not present in
> /usr/bin/thunderbird.
>
> Terminal output when running thunderbird is:
>
> No protocol specified
> Unable to init server: Could not connect: Connection refused
> Error: cannot open display: :0.0

I solved it by removing ~/.xinitrc

This file had only this line: exec ck-launch-session dbus-launch startxfce4

Deleting .xinitrc from my Home has not change the behavior of the XFCE 
DE, nor any other applications (that I know of, for now) and Thunderbird 
is working again.


I don't know how they're related, but that's what has worked for me.

Bug#886506: busybox sh broken on i386 with glibc 2.26, leads to kernel panic

[Ben Hutchings]

On Wed, 17 Jan 2018 12:31:06 +0100 Aurelien Jarno  wrote:
[...]
> busybox is compiled with -mpreferred-stack-boundary=2 on i386 which has
> the same effect of reducing the default stack alignment from 16 bytes to
> 2 bytes. This comes from arch/i386/Makefile:

The argument is the log2 of the alignment, so this sets alignment to 4
bytes - which is compliant with the System V psABI for i386.

Any assumption of 16-byte stack alignment in glibc on i386 will break
not only busybox but most binaries built with old versions of gcc
(before 4.2, if the comment in busybox is correct).  So this really
ought to be fixed there.

I think that any libraries that need to maintain backward binary
compatibility will need to be compiled with the option
-mincoming-stack-boundary=2.  gcc will then fix up the stack alignment
in functions that need greater alignment for local variables.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


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

Bug#887862: git-review: Download of change branch fails

[Jaap Keuter]

Package: git-review
Version: 1.25.0-2
Severity: normal

Dear Maintainer,

The following transpires when downloading a change with git-review


git review -d 25398
Using global/system git-review config files (/etc/git-review/git-review.conf) 
is deprecated
Downloading refs/changes/98/25398/1 from gerrit
Cannot set upstream to remote branch
The following command failed with exit code 128
"git branch --set-upstream review/jaap_keuter/25398 origin/master"
---
fatal: the '--set-upstream' option is no longer supported. Please use '--track' 
or '--set-upstream-to' instead.
---

Packaging the new 1.26 version would likely address this. Please consider 
packaging it.

Thanks,
Jaap


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

Kernel: Linux 4.14.0-3-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 git-review depends on:
ii  git  1:2.15.1-1
ii  python   2.7.14-1
ii  python-requests  2.18.4-1

git-review recommends no packages.

git-review suggests no packages.

-- no debconf information

Bug#887861: Enable NetworkManager.wait-online.service on diskful workstations

[Mike Gabriel]

Package: debian-edu-config
Severity: important

Hi,

for the last couple of years, we have always been struggling with a  
race condition during boot up of diskful Skolelinux Workstations. The  
race was between network coming up and autofs launching.


We thought we had fixed it several times since squeeze. But when  
hardware changed (mostly when the hardware became faster during boot),  
the issue turned back on.


The history of getting the issue solved is long. Our recent fix,  
however, seems to be sustainable:


  systemctl enable NetworkManager-wait-online.service

Once that unit is enabled, systems boot and logon to the system with  
an LDAP / NFS user is always possible. No failures seen so far. On  
different hardware variants.


@Wolfgang: Where would be the best place to put the above line during  
system installation of diskful normal workstations?


Greets,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpy6daKsny0g.pgp
Description: Digitale PGP-Signatur

Bug#887860: tracker-extract: repeated SIGSYS in execve()

[Mike Kupfer]

Simon McVittie wrote:

> I'm not sure under what circumstances GStreamer runs gst-plugin-scanner:
> it must be something slightly unusual about your system, perhaps a
> locally-installed GStreamer plugin with a timestamp newer than the
> registry of available plugins, otherwise other people would see this
> bug all the time.

Hmm.  Synaptic reports 4 locally installed gstreamer packages:

  gstreamer0.10-fluendo-mp3
  gstreamer0.10-plugins-base
  libgstreamer0.10-0
  libgstreamer-plugins-base0.10

I suspect these are left over from when the system was upgraded from
Jessie to Stretch.

I've removed the packages and will report back if any new core files
appear.

thanks,
mike

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Guillem Jover]

Control: reassign -1 python2.7-minimal,python3.6-minimal,debhelper
Control: retitle -1 python: Wants to be used like Essential:yes but does not 
follow its requirements
Control: affects -1 - libc6 libexpat1
Control: affects -1 + libglib2.0-dev

Hi!

On Sat, 2018-01-20 at 23:19:30 +0200, Niko Tyni wrote:
> On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:
> > For now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
> > error starts to show up elsewhere (e.g. in a package where both old and
> > new prerm use python3), probably adding the Pre-Depends to libexpat1
> > would be the general solution.
> 
> FWIW, I have the feeling that having libexpat1 Pre-Depend:libc6 would
> be a wrong place to fix this longer-term, though it might be a viable
> workaround for now. I fear that this will pop up with zlib1g (another
> dependency of python3.5-minimal in stretch) next as soon as it gets built
> against a newer glibc version. And having special handling in libexpat1
> and zlib1g because they happen to be dependencies of python3.x-minimal
> seems wrong.

Yes.

> The core problem here is python3 usage in 'prerm upgrade'. Non-essential
> packages are not generally safe to use at that point. AFAICS, if
> python3.x-minimal is intended to be usable in 'prerm upgrade', it
> needs to follow the same rules as essential packages: "must supply
> all of their core functionality even when unconfigured" (policy 3.8).
> In practice I think that means it must Pre-Depend on all the libraries
> it links against, (so libexpat1 and zlib1g in addition to the current
> pre-dependency on libc.)

Exactly right. :) BTW this would require a discussion on debian-devel,
even though I guess it might not be controversial.

> [I don't know if even that is enough or if apt/dpkg give special treatment
> to packages tagged Essential:yes in this context.]

dpkg only takes Essential:yes into account on removal, when showing
its scary prompt; and when deconfiguring a package, to refuse the
action. AFAIR apt uses Essential:yes as things that need to
be installed (if they are not), for its own scary prompt, and to
prioritize its installation at the beginning of the transaction.

> Now, as we can't change python3 in stretch anymore, we can either push
> this down the chain in sid/buster and modify new libexpat1 and zlib1g to
> pre-depend on libc as a workaround, or we have to add fallback 'new-prerm
> failed-upgrade' handling to the packages whose 'prerm upgrade' in stretch
> is using python3.

I don't think this needs to be changed in stretch anyway? The new
dependencies on the newer libc are coming from sid/buster, so fixing
that should be enough, AFAICS (but I've not looked very hard :).

> I see the py3clean invocation is generated by dh_python3 so this is
> probably going to be much wider issue than just libglib2.0-dev...

I'm also assigning to debhelper, in case this needs mitigations there
too. Feel free to sort this out between yourselves, by reassigning,
cloning or whatever. ;)

Thanks,
Guillem

Bug#884003: FDT overlay support

[Vagrant Cascadian]

On 2018-01-20, Vagrant Cascadian wrote:
> On 2017-12-12, Andre Heider wrote:
>> Subject: [PATCH 05/10] bootscr.uboot-generic: support multiple prefixes to
>>  load from
>> Subject: [PATCH 06/10] beaglebone: clean up boot script
>
> I might try to rework 5-6 with a slightly different approach.

Merged and pushed these too.


>> Subject: [PATCH 07/10] Introduce user variable OVERLAYS
>> Subject: [PATCH 08/10] Add a hook to bootscr.uboot-generic for post fdt
>>  loading tasks
>> Subject: [PATCH 09/10] Introduce fdt overlay support
>> Subject: [PATCH 10/10] beaglebone: enable fdt overlay support

You said you had some changes to make to this, please re-submit the
updated remaining patches against current git master.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#887860: tracker-extract: repeated SIGSYS in execve()

[Simon McVittie]

On Sat, 20 Jan 2018 at 23:33:52 +, Simon McVittie wrote:
> Before applying seccomp filters or making
> use of GStreamer, tracker-extract should set the environment variables
> GST_REGISTRY_UPDATE and GST_REGISTRY_FORK to "no" to prevent this.

I *thought* this sounded familiar. Looks like I suggested that before as
a solution to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853723
but that bug was solved differently in the end.

smcv

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Guillem Jover]

Hi!

On Thu, 2018-01-18 at 21:45:51 +0100, Aurelien Jarno wrote:
> On 2018-01-18 20:38, Julian Andres Klode wrote:
> > On Thu, Jan 18, 2018 at 06:41:52PM +0100, Aurelien Jarno wrote:
> > > This failure is normal given libexpat1 requires the new libc which has
> > > not been unpacked yet.
> > 
> > Yeah, well, it needs to Pre-Depend on it then I guess, if it's being used
> > in preinst actions. The thing is that Depends only after postinst ordering,
> > not unpack ordering.
> 
> Well it's not the preinst script, but the prerm script. The problem is
> unpacking libexpat1 before libc6 breaks libexpat1 and not usable
> anymore.

Depends only applies at configure time, not unpack time anyway. In
addition in this case dpkg does not even know there's such dependency
because the new package does not depend on python any longer (and dpkg
only tests the dependencies of the new version not the old one).

> From what I understand from the debian-policy, a prerm script might
> consider that all the dependencies have been at least unpacked when
> called:
> 
> | "The package whose prerm is being called will be at least
> | “Half-Installed”. All package dependencies will at least be
> | “Half-Installed” and will have previously been configured and not
> | removed. If there was no error, all dependencies will at least be
> | “Unpacked”, but these actions may be called in various error
> | states where dependencies are only “Half-Installed” due to a
> | partial upgrade.

First, notice that half-installed is one state lower than unpacked. In
addition when it says that "All package dependencies will at least be
“Half-Installed” and will have previously been configured and not
removed.", this means that they will have been fully configured before
on any version, but not the depended-on version (if there's such
dependency now).

Thanks,
Guillem

Bug#887860: tracker-extract: repeated SIGSYS in execve()

[Simon McVittie]

On Sat, 20 Jan 2018 at 15:08:18 -0800, Mike Kupfer wrote:
> Every few days I find a core file in $HOME.  file(1) tells me they're
> coming from tracker-extract.  I've taken a quick look at a couple with
> gdb, and (IIRC), gdb has said each time that tracker-extract died with
> SIGSYS in execve().

tracker-extract runs under seccomp sandboxing that kills it with SIGSYS
when it tries to do a system call that isn't on a whitelist, to make sure
an attacker wouldn't be able to use a vulnerability in its file parsing
to execute arbitrary code. Executing a different binary (execve())
is not on the whitelist.

> #2  0x7fde9dc5c31e in g_execute (search_path_from_envp=0, search_path=0, 
> envp=0x0, argv=0x7fde6bb198b0, file=0x7fde641bb000 
> "/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner") at 
> ././glib/gspawn.c:1680

This is a GStreamer library used by tracker-extract refreshing its
list of available GStreamer plugins. tracker-extract should configure
GStreamer to not do this: either it currently doesn't, or it tries to
but has been unsuccessful. Before applying seccomp filters or making
use of GStreamer, tracker-extract should set the environment variables
GST_REGISTRY_UPDATE and GST_REGISTRY_FORK to "no" to prevent this.

I'm not sure under what circumstances GStreamer runs gst-plugin-scanner:
it must be something slightly unusual about your system, perhaps a
locally-installed GStreamer plugin with a timestamp newer than the
registry of available plugins, otherwise other people would see this
bug all the time.

smcv

Bug#887815: [Pkg-utopia-maintainers] Bug#887815: network-manager-iodine FTBFS with network-manager 1.10.2-1

[Michael Biebl]

Control: reassign -1 network-manager
Control: found -1 1.10.2-1
Control: affects -1 network-manager-iodine

Hi Guido

Am 20.01.2018 um 13:58 schrieb Michael Biebl:
> Am 20.01.2018 um 12:09 schrieb Guido Günther:
>> /usr/include/libnm/nm-setting-tc-config.h:43:1: error: 'NMTCQdisc' is 
>> deprecated: Not available before 1.10.2
> 
> I suppose this is the problem in configure.ac
> 
> LIBNM_CFLAGS="$LIBNM_CFLAGS -DNM_VERSION_MIN_REQUIRED=NM_VERSION_1_2"
> LIBNM_CFLAGS="$LIBNM_CFLAGS -DNM_VERSION_MAX_ALLOWED=NM_VERSION_1_2"
> 
> This triggers a warning which together with Werror leads to the build
> failure.
> The pkg-utopia maintained VPN modules trigger this warning as well, but
> don't use Werror, so do not fail the build.

I poked NM upstream about this issue. They referred me to
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/libnm-core/nm-setting-tc-config.h?id=685cb5c88bf90b285a18a98a6bbeafa559938fee
which should solve this issue.
This will be part of the next NM release which should be anytime soon.

If the nm-iodine issue is pressing, I can cherry-pick this fix.
Otherwise I would just wait for 1.10.4.

Reassigning the bug accordingly.


Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#887860: tracker-extract: repeated SIGSYS in execve()

[Mike Kupfer]

Package: tracker-extract
Version: 1.10.5-1
Severity: normal

Dear Maintainer,

Every few days I find a core file in $HOME.  file(1) tells me they're
coming from tracker-extract.  I've taken a quick look at a couple with
gdb, and (IIRC), gdb has said each time that tracker-extract died with
SIGSYS in execve().

I haven't been able to determine if a particular file is causing the
crashes or if it's a more general problem.

Today I finally got around to getting a stack trace:

alto$ ls -l core
-rw--- 1 kupfer kupfer 192376832 Jan 20 07:29 core
alto$ file core
core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 
'/usr/lib/tracker/tracker-extract', real uid: 1000, effective uid: 1000, real 
gid: 1000, effective gid: 1000, execfn: '/usr/lib/tracker/tracker-extract', 
platform: 'x86_64'
alto$ gdb /usr/lib/tracker/tracker-extract core
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/tracker/tracker-extract...(no debugging symbols 
found)...done.

warning: core file may not match specified executable file.
[New LWP 11353]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/tracker/tracker-extract'.
Program terminated with signal SIGSYS, Bad system call.
#0  0x7fde9d6c3677 in execve () at ../sysdeps/unix/syscall-template.S:84
84  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x7fde9d6c3677 in execve () at ../sysdeps/unix/syscall-template.S:84
#1  0x7fde9d6c376f in execv (path=, argv=)
at execv.c:25
#2  0x7fde9dc5c31e in g_execute (search_path_from_envp=0, search_path=0, 
envp=0x0, argv=0x7fde6bb198b0, file=0x7fde641bb000 
"/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner") at 
././glib/gspawn.c:1680
#3  0x7fde9dc5c31e in do_exec (child_err_report_fd=18, stdin_fd=, stdout_fd=22, stderr_fd=-1, 
working_directory=working_directory@entry=0x0, argv=argv@entry=0x7fde6bb198b0, 
envp=0x0, close_descriptors=1, search_path=0, search_path_from_envp=0, 
stdout_to_null=0, stderr_to_null=0, child_inherits_stdin=0, 
file_and_argv_zero=0, child_setup=0x0, user_data=0x0)
at ././glib/gspawn.c:1229
#4  0x7fde9dc5cb01 in fork_exec_with_pipes 
(intermediate_child=intermediate_child@entry=0, 
working_directory=working_directory@entry=0x0, argv=argv@entry=0x7fde6bb198b0, 
envp=envp@entry=0x0, close_descriptors=close_descriptors@entry=1, 
search_path=search_path@entry=0, search_path_from_envp=0, stdout_to_null=0, 
stderr_to_null=0, child_inherits_stdin=0, file_and_argv_zero=0, 
cloexec_pipes=0, child_setup=0x0, user_data=0x0, child_pid=0x7fde6400a6d4, 
standard_input=0x7fde6400a6d8, standard_output=0x7fde6400a6e0, 
standard_error=0x0, error=0x0)
at ././glib/gspawn.c:1426
#5  0x7fde9dc5d545 in g_spawn_async_with_pipes 
(working_directory=working_directory@entry=0x0, argv=argv@entry=0x7fde6bb198b0, 
envp=envp@entry=0x0, flags=flags@entry=G_SPAWN_DO_NOT_REAP_CHILD, 
child_setup=child_setup@entry=0x0, user_dat---Type  to continue, or q 
 to quit---
a=user_data@entry=0x0, child_pid=0x7fde6400a6d4, standard_input=0x7fde6400a6d8, 
standard_output=0x7fde6400a6e0, standard_error=0x0, error=0x0)
at ././glib/gspawn.c:656
#6  0x7fde70930ea9 in gst_plugin_loader_try_helper 
(loader=loader@entry=0x7fde6400a6c0, location=location@entry=0x7fde641bb000 
"/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner") at 
gstpluginloader.c:431
#7  0x7fde70930fd1 in gst_plugin_loader_spawn (loader=0x7fde6400a6c0)
at gstpluginloader.c:494
#8  0x7fde70931555 in gst_plugin_loader_spawn (loader=0x7fde6400a6c0)
at gstpluginloader.c:258
#9  0x7fde70931555 in plugin_loader_load (loader=0x7fde6400a6c0, 
filename=0x7fde641b92c0 
"/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so", file_size=732184, 
file_mtime=1487860804) at gstpluginloader.c:228
#10 0x7fde7093a73c in gst_registry_scan_plugin_file 
(context=context@entry=0x7fde6bb19b00, filename=filename@entry=0x7fde641b92c0 
"/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so", file_size=732184, 
file_mtime=1487860804)
at gstregistry.c:1176
#11 0x7fde7093b8a1 in gst_registry_scan_path_level 
(context=context@entry=0x7fde6bb19b00, 

Bug#654197: enabling gksudo: in d-e-c.postinst?

[Mike Gabriel]

Control: close -1

Hi,

On  Mo 01 Apr 2013 17:34:11 CEST, Mike Gabriel wrote:


Hi all,

enabling sudo functionality in gksu(do) requires an  
update-alternatives call. Where would that be best placed?  
d-e-c.postinst?


Any comments?

Thanks!
Mike


Closing this bug, gksu is about to be removed from Debian.

The easier approach for launching GUI apps as root via sudo is this:

  sudo echo "Defaults env_keep += \"DISPLAY\"" > /etc/sudoers.d/local-settings

Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpsm566IfDWB.pgp
Description: Digitale PGP-Signatur

Bug#887832: [arp-scan] Segmentation fault at launch

[Marcos Fouces]

Hello Manu

I believe that is the same problem as described in bug #881125. It is
solved in 1.9-3 release in the Debian testing

Could you install the package from testing and check if it works for
you? If so, i will close this bug.

Many thanks for your report.

Greetings.

Marcos



El 20/01/18 a las 12:33, manu escribió:
> Package: arp-scan
> Version: 1.9-1
> Severity: normal
>
> --- Please enter the report below this line. ---
> Hello,
> launching either "arp-scan" or "arp-scan --localnet" from command line
> leads to a segmentation fault.
> Feel free to ask for more information,
>
>
> --- System information. ---
> Architecture: Kernel:   Linux 3.19.0-trunk-amd64
>
> Debian Release: 9.3
>   900 stable  security.debian.org   900 stable
> ftp2.fr.debian.org   500 zesty   ppa.launchpad.net   100
> unstabledebian.qelectrotech.org
> --- Package information. ---
> Depends (Version) | Installed
> =-+-===
> libc6   (>= 2.15) | libpcap0.8 (>= 0.9.8) | ieee-data
>  |
>
> Recommends   (Version) | Installed
> ==-+-===
> libwww-perl| 6.15-1
>
>
> Package's Suggests field is empty.
>
>

Bug#884003: FDT overlay support

[Vagrant Cascadian]

On 2017-12-12, Andre Heider wrote:
> I added the ability to concatenate multiple scripts/snippets for the 
> final boot script.

> Subject: [PATCH 01/10] bootscr.uboot-generic: quote bootargs
> Subject: [PATCH 02/10] Allow compiling scripts from $tmpdir
> Subject: [PATCH 03/10] Add support for multiple scripts sources
> Subject: [PATCH 04/10] odroid-u3: clean up boot script

I've merged patches 1-4 into git so far, implementing multiple boot
scripts and cleaning up the odroid boot script.

Of course, those were the easiest to merge... :)


> Subject: [PATCH 05/10] bootscr.uboot-generic: support multiple prefixes to
>  load from
> Subject: [PATCH 06/10] beaglebone: clean up boot script

I might try to rework 5-6 with a slightly different approach.


> Subject: [PATCH 07/10] Introduce user variable OVERLAYS
> Subject: [PATCH 08/10] Add a hook to bootscr.uboot-generic for post fdt
>  loading tasks
> Subject: [PATCH 09/10] Introduce fdt overlay support
> Subject: [PATCH 10/10] beaglebone: enable fdt overlay support

And reworking 5-6 may affect these, will explore that when I get
there...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#887859: RM: sanduhr -- RoQA; long-dead upstream, old gnome libs

[Adam Borowski]

Package: ftp.debian.org
Severity: normal


Hi!
sanduhr's last update was in 2004, an experimental preview of a port to
Gnome 2.  Those fancy new libraries this preview uses are now themselves
being removed.

Last Debian upload in 2007, popcon: 68 inst 13 vote.

Bug#878994: Pending fixes for bugs in the zookeeper package

[pkg-java-maintainers]

tag 878994 + pending
thanks

Some bugs in the zookeeper package are closed in revision
2fa0162474fd730a73088bde2135220ff09bef68 in branch 'master' by tony
mancill

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

Commit message:

Drop transitional package libzookeeper2 (Closes: #878994)

Bug#870271: Pending fixes for bugs in the zookeeper package

[pkg-java-maintainers]

tag 870271 + pending
thanks

Some bugs in the zookeeper package are closed in revision
6bce520e5f862a626a697a25ac583bec9eb4 in branch 'master' by tony
mancill

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

Commit message:

/var/lib/zookeeper is no longer world-readable (Closes: #870271)

Bug#832528: Latest akonadi packages do not kick out old package baloo-utils

[Tim Ruehsen]

Am Samstag, den 20.01.2018, 19:28 +0100 schrieb Sandro Knauß:
> Control: reassign -1 baloo-utils
> Control: found -1 4:4.14.3-3
> Control: affects -1 akonadi-server
> 
> Hey,
> 
> With kdepim with 16.08+ baloo package was split into baloo (file
> indexer) and 
> akonadisearch the kdepim indexer. I can't tell you why at your system
> baloo-
> utils are not removed by default. Maybe you need to run apt
> autoremove. There 
> should normally no dependency stopping you from removing that cruft
> package. 
> Additionally baloo-utils are part of baloo4 aka based on Qt4. So only
> the 
> remaining Qt4 applications creating this unfortunate situation.

> Please try to find out, what application stops the autoremoval of
> baloo-utils. 

Hi, this bug is too old to investigate (mid 2016).
I wouldn't mind if you close it.

Regards, Tim

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

Bug#870509: editorconfig-core: hardcoded Pre-Depends on multiarch-support

[Jonas Smedegaard]

Quoting Aurelien Jarno (2018-01-20 22:20:46)
> tagging 870509 
> In-Reply-To: <150169715043.5184.5706663224181401234.reportbug@ohm.local>
> <1501699739-3715-bts-aure...@debian.org>
> 
> Control: tag -1 + pending
> 
> Dear maintainer,
> 
> I have prepared an NMU for editorconfig-core (versioned as
> 0.12.1-1.1), removing the hardcoded Pre-Depends on multiarch-support
> (bug #870509). You will find the diff attached. I have uploaded it to
> DELAYED/15. Please feel free to tell me if I should delay it longer
> or cancel it altogether.

Hi Aurelien,

On the contrary, your package change is quite appreciated, and you are 
welcome to speedup its release.

Hint for the future: You might want to check if a package/maintainer is 
listed at .  No problem if you 
don't (it is extra work after all), just in case you want :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#887341: pull request upstream

[Jeffrey Cliff]

Though I have my doubts that it will be merged ( due to their requiring tox
2.6 ), I have created a preliminary debian package directory in pull request

https://github.com/ethereum/eth-bloom/pull/11
from 'debian2'  branch in
https://github.com/themusicgod1/eth-bloom
which successfully builds an installable(if you've got the prerequisites,
which you'll find I've been slowly chipping away at) package like (obv
don't install this, it's an http link) http://82.221.128.217/python3-
eth-bloom_0.5.2-1_all.deb

Hope this helps

Jeff Cliff

Bug#887858: openjdk-7: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Source: openjdk-7
Version: 7u161-2.6.12-1
Severity: normal
Tags: experimental patch
User: debian-gl...@lists.debian.org
Usertags: multiarch-support-removal

The multiarch-support package has been introduced with squeeze so that
packages using the multiarch libraries can Pre-Depends on it to make
sure the multiarch path ares supported by the dynamic linker. As
dist-upgrades from such a distant release are not supported, the
Pre-Depends can now be dropped and then the package removed from the
archive.

Most of the packages added this Pre-Depends through debhelper and the
misc:Pre-Depends substvar, so a change in debhelper [1] was enough to
get rid of it. However it appears that your package uses a hardcoded
Pre-Depends, thus it needs to be removed manually. You will find a
patch attached to do so.

Please apply it as soon as possible as the multiarch-support package
will be removed from the archive for buster. Failing to do so will
therefore make your package uninstallable. In case you don't have
time to do so, don't hesitate to ask for a NMU.

Thanks,
Aurelien

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783898
diff -Nru openjdk-7-7u161-2.6.12/debian/control 
openjdk-7-7u161-2.6.12/debian/control
--- openjdk-7-7u161-2.6.12/debian/control   2017-12-07 09:12:51.0 
+0100
+++ openjdk-7-7u161-2.6.12/debian/control   2018-01-20 22:46:34.0 
+0100
@@ -39,7 +39,7 @@
 Package: openjdk-7-jre-headless
 Architecture: alpha amd64 armel armhf arm64 i386 ia64 mips mipsel mips64 
mips64el powerpc powerpcspe ppc64 ppc64el m68k sh4 sparc sparc64 s390x x32 
kfreebsd-i386 kfreebsd-amd64
 Multi-Arch: same
-Pre-Depends: ${dpkg:Depends}, ${multiarch:Depends}
+Pre-Depends: ${dpkg:Depends}
 Depends: ${jredefault:Depends}, ${cacert:Depends}, ${tzdata:Depends}, 
${jcommon:Depends}, ${dlopenhl:Depends}, ${mountpoint:Depends}, 
${shlibs:Depends}, ${misc:Depends}
 Recommends: ${dlopenhl:Recommends}, ${jamvm:Recommends}
 Suggests: ${jamvm:Suggests}, libnss-mdns, sun-java6-fonts, fonts-dejavu-extra, 
fonts-ipafont-gothic, fonts-ipafont-mincho, fonts-wqy-microhei, 
fonts-wqy-zenhei, fonts-indic,
diff -Nru openjdk-7-7u161-2.6.12/debian/control.in 
openjdk-7-7u161-2.6.12/debian/control.in
--- openjdk-7-7u161-2.6.12/debian/control.in2017-12-07 09:12:51.0 
+0100
+++ openjdk-7-7u161-2.6.12/debian/control.in2018-01-20 22:46:34.0 
+0100
@@ -39,7 +39,7 @@
 Package: @basename@-jre-headless
 Architecture: @any_archs@
 Multi-Arch: same
-Pre-Depends: ${dpkg:Depends}, ${multiarch:Depends}
+Pre-Depends: ${dpkg:Depends}
 Depends: ${jredefault:Depends}, ${cacert:Depends}, ${tzdata:Depends}, 
${jcommon:Depends}, ${dlopenhl:Depends}, ${mountpoint:Depends}, 
${shlibs:Depends}, ${misc:Depends}
 Recommends: ${dlopenhl:Recommends}, ${jamvm:Recommends}
 Suggests: ${jamvm:Suggests}, libnss-mdns, sun-java6-fonts, @core_fonts@, 
@cjk_fonts@
diff -Nru openjdk-7-7u161-2.6.12/debian/rules 
openjdk-7-7u161-2.6.12/debian/rules
--- openjdk-7-7u161-2.6.12/debian/rules 2017-12-07 09:12:51.0 +0100
+++ openjdk-7-7u161-2.6.12/debian/rules 2018-01-20 22:46:34.0 +0100
@@ -727,7 +727,6 @@
 
 ifneq (,$(DEB_HOST_MULTIARCH))
   control_vars += \
-   '-Vmultiarch:Depends=multiarch-support' \
'-Vmultiarch:Conflicts=icedtea-netx (<< 1.1.1-2~)'
 endif
 

Bug#887793: More info

[Yago Fernandez]

It seems that there are no text, but you can copy and paste it anywhere (in
kate for example) and the text is there.
Evince displays it right but qpdfview has same issue, so I think it's
related to poppler backend.

Bug#820517: bumping severity, proposing NMU

[Sergei Golovan]

severity 820517 important
thanks

Hi!

Since Tcl/Tk 8.5 has approached its end of life, we are seeking to
remove it from Debian before buster's release. So please, make znc
using Tcl/Tk 8.6.

I'm attaching a proposed NMU which replaces the tcl8.5-dev build
dependency by tcl-dev (the currently default Tcl/Tk version). The
package builds just fine with these changes, thoug I'd suggest to do
some additional testing.

So if you don't mind, I'll do NMU for you.

Cheers!
-- 
Sergei Golovan
diff -Nru znc-1.6.5/debian/changelog znc-1.6.5/debian/changelog
--- znc-1.6.5/debian/changelog  2017-07-03 12:55:24.0 +0300
+++ znc-1.6.5/debian/changelog  2018-01-21 00:17:42.0 +0300
@@ -1,3 +1,11 @@
+znc (1.6.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to the default Tcl/Tk (currently 8.6) from Tcl/Tk 8.5 which is to
+be removed from Debian (closes: #820517).
+
+ -- Sergei Golovan   Sun, 21 Jan 2018 00:17:42 +0300
+
 znc (1.6.5-2) unstable; urgency=medium
 
   * Enable PIE again.
diff -Nru znc-1.6.5/debian/control znc-1.6.5/debian/control
--- znc-1.6.5/debian/control2017-07-03 12:55:24.0 +0300
+++ znc-1.6.5/debian/control2018-01-21 00:16:09.0 +0300
@@ -7,7 +7,7 @@
  libicu-dev,
  zlib1g-dev,
  pkg-config,
- tcl8.5-dev,
+ tcl-dev,
  libsasl2-dev,
  swig3.0,
  dh-python,
@@ -48,7 +48,7 @@
  libssl-dev,
  libperl-dev,
  pkg-config,
- tcl8.5-dev,
+ tcl-dev,
  libsasl2-dev,
  python3-dev
 Recommends: g++

Bug#887793: Here is an example of pdf file (and its sources in lyx and latex)

[Yago Fernandez]

test.lyx
Description: application/lyx


test.tex
Description: TeX document


test.pdf
Description: Adobe PDF document

Bug#870537: gtk2-engines-oxygen: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

On 2017-08-06 21:35, Andreas Henriksson wrote:
> Control: tags -1 + pending
> 
> Hello!
> 
> This has already been fixed in packaging git repo:
> https://anonscm.debian.org/cgit/pkg-kde/kde-extras/gtk2-engines-oxygen.git/commit/?id=09873136534a3f9eca4a9933e4768305476cd9e9

Thanks!

> ... someone just needs to finally upload it.

What is needed to make that happen?

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#870512: libsass: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Hi,

On 2017-08-02 20:43, Aurelien Jarno wrote:
> Source: libsass
> Version: 3.4.3-1
> Severity: normal
> Tags: sid buster
> User: debian-gl...@lists.debian.org
> Usertags: multiarch-support-removal
> 
> Dear Maintainer,
> 
> The multiarch-support package has been introduced with squeeze so that
> packages using the multiarch libraries can Pre-Depends on it to make
> sure the multiarch path ares supported by the dynamic linker. As
> dist-upgrades from such a distant release are not supported, the
> Pre-Depends can now be dropped and then the package removed from the
> archive.
> 
> Most of the packages added this Pre-Depends through debhelper and the
> misc:Pre-Depends substvar, so a change in debhelper [1] was enough to
> get rid of it. However it appears that your package uses a hardcoded
> Pre-Depends, thus it needs to be removed manually. You will find a
> patch attached to do so.
> 
> Please apply it as soon as possible as the multiarch-support package
> will be removed from the archive for buster. Failing to do so will
> therefore make your package uninstallable. In case you don't have
> time to do so, don't hesitate to ask for a NMU.

This package has seen a few uploads since this bug has been reported. Is
there any issue with the patch? Could it be applied in the next upload?
It is one of the last packages left which depends on multiarch-support.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#870509: editorconfig-core: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

tagging 870509 
In-Reply-To: <150169715043.5184.5706663224181401234.reportbug@ohm.local>
<1501699739-3715-bts-aure...@debian.org>

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for editorconfig-core (versioned as
0.12.1-1.1), removing the hardcoded Pre-Depends on multiarch-support
(bug #870509). You will find the diff attached. I have uploaded it to
DELAYED/15. Please feel free to tell me if I should delay it longer
or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru editorconfig-core-0.12.1/debian/changelog editorconfig-core-0.12.1/debian/changelog
--- editorconfig-core-0.12.1/debian/changelog	2016-03-25 14:03:26.0 +0100
+++ editorconfig-core-0.12.1/debian/changelog	2018-01-20 22:17:16.0 +0100
@@ -1,3 +1,11 @@
+editorconfig-core (0.12.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870509).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 22:17:16 +0100
+
 editorconfig-core (0.12.1-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru editorconfig-core-0.12.1/debian/rules editorconfig-core-0.12.1/debian/rules
--- editorconfig-core-0.12.1/debian/rules	2016-03-25 14:00:23.0 +0100
+++ editorconfig-core-0.12.1/debian/rules	2018-01-20 22:17:15.0 +0100
@@ -50,7 +50,6 @@
 # Multiarch quirks (should ideally be resolved automagically)
 CDBS_BUILD_DEPENDS_rules_debhelper_buildinfo =
 CDBS_BUILD_DEPENDS_rules_buildcore_pkgrel =
-CDBS_PREDEPENDS = $(if $(DEB_HOST_MULTIARCH),multiarch-support)
 
 # avoid compressing documentation
 DEB_COMPRESS_EXCLUDE_DEFAULT += .html

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Niko Tyni]

On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:

> For now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
> error starts to show up elsewhere (e.g. in a package where both old and
> new prerm use python3), probably adding the Pre-Depends to libexpat1
> would be the general solution.

FWIW, I have the feeling that having libexpat1 Pre-Depend:libc6 would
be a wrong place to fix this longer-term, though it might be a viable
workaround for now. I fear that this will pop up with zlib1g (another
dependency of python3.5-minimal in stretch) next as soon as it gets built
against a newer glibc version. And having special handling in libexpat1
and zlib1g because they happen to be dependencies of python3.x-minimal
seems wrong.

The core problem here is python3 usage in 'prerm upgrade'. Non-essential
packages are not generally safe to use at that point. AFAICS, if
python3.x-minimal is intended to be usable in 'prerm upgrade', it
needs to follow the same rules as essential packages: "must supply
all of their core functionality even when unconfigured" (policy 3.8).
In practice I think that means it must Pre-Depend on all the libraries
it links against, (so libexpat1 and zlib1g in addition to the current
pre-dependency on libc.)

[I don't know if even that is enough or if apt/dpkg give special treatment
to packages tagged Essential:yes in this context.]

Now, as we can't change python3 in stretch anymore, we can either push
this down the chain in sid/buster and modify new libexpat1 and zlib1g to
pre-depend on libc as a workaround, or we have to add fallback 'new-prerm
failed-upgrade' handling to the packages whose 'prerm upgrade' in stretch
is using python3.

I see the py3clean invocation is generated by dh_python3 so this is
probably going to be much wider issue than just libglib2.0-dev...

Just my two cents,
-- 
Niko Tyni   nt...@debian.org

Bug#870557: lua-zlib: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for lua-zlib (versioned as
0.2+git+1+9622739-2.1), removing the hardcoded Pre-Depends on
multiarch-support (bug #870557). You will find the diff attached. I
have uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru lua-zlib-0.2+git+1+9622739/debian/changelog lua-zlib-0.2+git+1+9622739/debian/changelog
--- lua-zlib-0.2+git+1+9622739/debian/changelog	2014-08-31 18:58:46.0 +0200
+++ lua-zlib-0.2+git+1+9622739/debian/changelog	2018-01-20 22:12:35.0 +0100
@@ -1,3 +1,11 @@
+lua-zlib (0.2+git+1+9622739-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870557).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 22:12:35 +0100
+
 lua-zlib (0.2+git+1+9622739-2) unstable; urgency=medium
 
   * Rebuild against Lua 5.1.5-7 (Closes: #723493)
diff -Nru lua-zlib-0.2+git+1+9622739/debian/control lua-zlib-0.2+git+1+9622739/debian/control
--- lua-zlib-0.2+git+1+9622739/debian/control	2014-08-31 18:58:46.0 +0200
+++ lua-zlib-0.2+git+1+9622739/debian/control	2018-01-20 22:12:34.0 +0100
@@ -11,7 +11,7 @@
 Package: lua-zlib
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
@@ -22,7 +22,7 @@
 Package: lua-zlib-dev
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Section: libdevel
 Depends: lua-zlib (= ${binary:Version}), ${misc:Depends}
 Provides: ${lua:Provides}

Bug#870554: lua-rings: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for lua-rings (versioned as 1.3.0-3.1), removing
the hardcoded Pre-Depends on multiarch-support (bug #870554). You will
find the diff attached. I have uploaded it to DELAYED/15. Please feel
free to tell me if I should delay it longer or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru lua-rings-1.3.0/debian/changelog lua-rings-1.3.0/debian/changelog
--- lua-rings-1.3.0/debian/changelog	2015-01-18 19:59:59.0 +0100
+++ lua-rings-1.3.0/debian/changelog	2018-01-20 21:46:00.0 +0100
@@ -1,3 +1,11 @@
+lua-rings (1.3.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870554).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 21:46:00 +0100
+
 lua-rings (1.3.0-3) unstable; urgency=medium
 
   * Disable a cache related test on 5.2 (Close: #775622)
diff -Nru lua-rings-1.3.0/debian/control lua-rings-1.3.0/debian/control
--- lua-rings-1.3.0/debian/control	2015-01-18 19:59:59.0 +0100
+++ lua-rings-1.3.0/debian/control	2018-01-20 21:46:00.0 +0100
@@ -11,7 +11,7 @@
 Package: lua-rings
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
@@ -26,7 +26,7 @@
 Package: lua-rings-dev
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Section: libdevel
 Depends: lua-rings (= ${binary:Version}), ${misc:Depends}
 Provides: ${lua:Provides}

Bug#870556: lua-zip: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for lua-zip (versioned as 1.2.3-12.1), removing
the hardcoded Pre-Depends on multiarch-support (bug #870556). You will
find the diff attached. I have uploaded it to DELAYED/15. Please feel
free to tell me if I should delay it longer or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru lua-zip-1.2.3/debian/changelog lua-zip-1.2.3/debian/changelog
--- lua-zip-1.2.3/debian/changelog	2013-08-15 12:07:12.0 +0200
+++ lua-zip-1.2.3/debian/changelog	2018-01-20 22:11:41.0 +0100
@@ -1,3 +1,11 @@
+lua-zip (1.2.3-12.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870556).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 22:11:41 +0100
+
 lua-zip (1.2.3-12) unstable; urgency=low
 
   * Packaging moved to git
diff -Nru lua-zip-1.2.3/debian/control lua-zip-1.2.3/debian/control
--- lua-zip-1.2.3/debian/control	2013-08-15 12:07:12.0 +0200
+++ lua-zip-1.2.3/debian/control	2018-01-20 22:11:41.0 +0100
@@ -11,7 +11,7 @@
 Package: lua-zip
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
@@ -22,7 +22,7 @@
 Package: lua-zip-dev
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: lua-zip (= ${binary:Version}), ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}

Bug#870555: lua-svn: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for lua-svn (versioned as 0.4.0-9.1), removing
the hardcoded Pre-Depends on multiarch-support (bug #870555). You will
find the diff attached. I have uploaded it to DELAYED/15. Please feel
free to tell me if I should delay it longer or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru lua-svn-0.4.0/debian/changelog lua-svn-0.4.0/debian/changelog
--- lua-svn-0.4.0/debian/changelog	2013-08-12 14:18:13.0 +0200
+++ lua-svn-0.4.0/debian/changelog	2018-01-20 21:47:42.0 +0100
@@ -1,3 +1,11 @@
+lua-svn (0.4.0-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870555).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 21:47:42 +0100
+
 lua-svn (0.4.0-9) unstable; urgency=low
 
   * Package moved to git 
diff -Nru lua-svn-0.4.0/debian/control lua-svn-0.4.0/debian/control
--- lua-svn-0.4.0/debian/control	2013-08-12 14:18:13.0 +0200
+++ lua-svn-0.4.0/debian/control	2018-01-20 21:47:41.0 +0100
@@ -11,7 +11,7 @@
 Package: lua-svn
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, lua-expat, lua-socket
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
@@ -21,7 +21,7 @@
 Package: lua-svn-dev
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: lua-svn (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
 Section: libdevel
 Provides: ${lua:Provides}

Bug#886947: gxineplugin: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Followup-For: Bug #886947
Control: tag -1 pending patch

commit pushed to the GIT repo, but since I don't know how to update the
libmozjs B-D properly, I'm not going to upload it.


Andreas

Bug#870553: lua-md5: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for lua-md5 (versioned as
1.2+git+1+8d87fee-1.1), removing the hardcoded Pre-Depends on
multiarch-support (bug #870553). You will find the diff attached. I
have uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru lua-md5-1.2+git+1+8d87fee/debian/changelog lua-md5-1.2+git+1+8d87fee/debian/changelog
--- lua-md5-1.2+git+1+8d87fee/debian/changelog	2013-11-29 17:44:51.0 +0100
+++ lua-md5-1.2+git+1+8d87fee/debian/changelog	2018-01-20 21:33:30.0 +0100
@@ -1,3 +1,11 @@
+lua-md5 (1.2+git+1+8d87fee-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870553).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 21:33:30 +0100
+
 lua-md5 (1.2+git+1+8d87fee-1) unstable; urgency=low
 
   * New upstream release (plus some commit to fix 5.2 support)
diff -Nru lua-md5-1.2+git+1+8d87fee/debian/control lua-md5-1.2+git+1+8d87fee/debian/control
--- lua-md5-1.2+git+1+8d87fee/debian/control	2013-11-29 17:44:51.0 +0100
+++ lua-md5-1.2+git+1+8d87fee/debian/control	2018-01-20 21:33:30.0 +0100
@@ -11,7 +11,7 @@
 Package: lua-md5
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
@@ -23,7 +23,7 @@
 Package: lua-md5-dev
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: lua-md5 (= ${binary:Version}), ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}

Bug#870552: lua-lpty: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for lua-lpty (versioned as 1.0.1-1.1), removing
the hardcoded Pre-Depends on multiarch-support (bug #870552). You will
find the diff attached. I have uploaded it to DELAYED/15. Please feel
free to tell me if I should delay it longer or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru lua-lpty-1.0.1/debian/changelog lua-lpty-1.0.1/debian/changelog
--- lua-lpty-1.0.1/debian/changelog	2013-08-23 16:48:02.0 +0200
+++ lua-lpty-1.0.1/debian/changelog	2018-01-20 21:30:03.0 +0100
@@ -1,3 +1,11 @@
+lua-lpty (1.0.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870552).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 21:30:03 +0100
+
 lua-lpty (1.0.1-1) unstable; urgency=low
 
   * Initial release. (Closes: #719795)
diff -Nru lua-lpty-1.0.1/debian/control lua-lpty-1.0.1/debian/control
--- lua-lpty-1.0.1/debian/control	2013-08-23 16:48:02.0 +0200
+++ lua-lpty-1.0.1/debian/control	2018-01-20 21:30:03.0 +0100
@@ -11,7 +11,7 @@
 Package: lua-lpty
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
@@ -22,7 +22,7 @@
 Package: lua-lpty-dev
 Section: libdevel
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Architecture: any
 Depends: lua-lpty (= ${binary:Version}), ${misc:Depends}
 Provides: ${lua:Provides}

Bug#887787: lxc: CentOS 7 amd64 container can't be stopped

[Toni Mueller]

Hi,

the problem is not limited to CentOS. I just had a Debian container lock
up the same way, on the same host.


Cheers,
Toni

Bug#869480: Support multiple smarthosts (gmail support)

[Florian Weimer]

* Osamu Aoki:

> +Here, f...@example.org.sh should be as follows:
> +
> +#!/bin/sh
> +/usr/bin/ssh -p 22 \
> +-i /etc/exim4/ssh/f...@host.example.org.key \
> +-o "StrictHostKeyChecking no" \
> +f...@host.example.org \
> +/usr/bin/sendmail -bm -ti \
> +-f f...@example.org

This looks quite dangerous to me because there is a large temptation
to pass data on the command line (mainly to fix the sender address),
and it is going to be very difficult to do this in a secure fashion,
without introducing shell command injection.  The end of the message
is also not signalled reliably to the sendmail subprocess (i.e. a
dropped SSH connection results in a truncated message and data loss).
This looks more like an application for BSMTP.

Bug#870551: lua-ldap: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for lua-ldap (versioned as
1.1.0-1-geeac494-6.1), removing the hardcoded Pre-Depends on
multiarch-support (bug #870551). You will find the diff attached. I
have uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru lua-ldap-1.1.0-1-geeac494/debian/changelog lua-ldap-1.1.0-1-geeac494/debian/changelog
--- lua-ldap-1.1.0-1-geeac494/debian/changelog	2014-08-31 18:44:37.0 +0200
+++ lua-ldap-1.1.0-1-geeac494/debian/changelog	2018-01-20 21:29:02.0 +0100
@@ -1,3 +1,11 @@
+lua-ldap (1.1.0-1-geeac494-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870551).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 21:29:02 +0100
+
 lua-ldap (1.1.0-1-geeac494-6) unstable; urgency=medium
 
   * Rebuild against Lua 5.1.5-7 (Closes: #723490)
diff -Nru lua-ldap-1.1.0-1-geeac494/debian/control lua-ldap-1.1.0-1-geeac494/debian/control
--- lua-ldap-1.1.0-1-geeac494/debian/control	2014-08-31 18:44:37.0 +0200
+++ lua-ldap-1.1.0-1-geeac494/debian/control	2018-01-20 21:29:02.0 +0100
@@ -12,7 +12,7 @@
 Package: lua-ldap
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
@@ -28,7 +28,7 @@
 Package: lua-ldap-dev
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: lua-ldap (= ${binary:Version}), ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}

Bug#870548: lua-cjson: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for lua-cjson (versioned as 2.1.0+dfsg-2.1),
removing the hardcoded Pre-Depends on multiarch-support (bug
#870548). You will find the diff attached. I have uploaded it to
DELAYED/15. Please feel free to tell me if I should delay it longer
or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru lua-cjson-2.1.0+dfsg/debian/changelog lua-cjson-2.1.0+dfsg/debian/changelog
--- lua-cjson-2.1.0+dfsg/debian/changelog	2012-09-24 09:50:50.0 +0200
+++ lua-cjson-2.1.0+dfsg/debian/changelog	2018-01-20 21:15:36.0 +0100
@@ -1,3 +1,11 @@
+lua-cjson (2.1.0+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870548).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 21:15:36 +0100
+
 lua-cjson (2.1.0+dfsg-2) unstable; urgency=low
 
   * Add debian/watch file.
diff -Nru lua-cjson-2.1.0+dfsg/debian/control lua-cjson-2.1.0+dfsg/debian/control
--- lua-cjson-2.1.0+dfsg/debian/control	2012-08-24 15:21:32.0 +0200
+++ lua-cjson-2.1.0+dfsg/debian/control	2018-01-20 21:15:36.0 +0100
@@ -12,7 +12,7 @@
 Package: lua-cjson
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
@@ -29,7 +29,7 @@
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}, lua-cjson (= ${binary:Version})
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}

Bug#870550: lua-cyrussasl: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for lua-cyrussasl (versioned as 1.0.0-6.1),
removing the hardcoded Pre-Depends on multiarch-support (bug
#870550). You will find the diff attached. I have uploaded it to
DELAYED/15. Please feel free to tell me if I should delay it longer
or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru lua-cyrussasl-1.0.0/debian/changelog lua-cyrussasl-1.0.0/debian/changelog
--- lua-cyrussasl-1.0.0/debian/changelog	2014-08-31 18:36:12.0 +0200
+++ lua-cyrussasl-1.0.0/debian/changelog	2018-01-20 21:18:12.0 +0100
@@ -1,3 +1,11 @@
+lua-cyrussasl (1.0.0-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870550).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 21:18:12 +0100
+
 lua-cyrussasl (1.0.0-6) unstable; urgency=medium
 
   * Rebuild against Lua 5.1.5-7 (Closes: #723486)
diff -Nru lua-cyrussasl-1.0.0/debian/control lua-cyrussasl-1.0.0/debian/control
--- lua-cyrussasl-1.0.0/debian/control	2014-08-31 18:36:12.0 +0200
+++ lua-cyrussasl-1.0.0/debian/control	2018-01-20 21:18:12.0 +0100
@@ -11,7 +11,7 @@
 Package: lua-cyrussasl
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
@@ -21,7 +21,7 @@
 Package: lua-cyrussasl-dev
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Section: libdevel
 Depends: lua-cyrussasl (= ${binary:Version}), ${misc:Depends}
 Provides: ${lua:Provides}

Bug#870549: lua-curl: hardcoded Pre-Depends on multiarch-support

[Aurelien Jarno]

Control: tag -1 + pending

Dear maintainer,

I have prepared an NMU for lua-curl (versioned as 0.3.0-9.2), removing
the hardcoded Pre-Depends on multiarch-support (bug #870549). You will
find the diff attached. I have uploaded it to DELAYED/15. Please feel
free to tell me if I should delay it longer or cancel it altogether.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru lua-curl-0.3.0/debian/changelog lua-curl-0.3.0/debian/changelog
--- lua-curl-0.3.0/debian/changelog	2017-01-28 15:09:19.0 +0100
+++ lua-curl-0.3.0/debian/changelog	2018-01-20 21:17:08.0 +0100
@@ -1,3 +1,11 @@
+lua-curl (0.3.0-9.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop explicit Pre-Depends on multiarch-support
+(Closes: #870549).
+
+ -- Aurelien Jarno   Sat, 20 Jan 2018 21:17:08 +0100
+
 lua-curl (0.3.0-9.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lua-curl-0.3.0/debian/control lua-curl-0.3.0/debian/control
--- lua-curl-0.3.0/debian/control	2017-01-28 15:03:48.0 +0100
+++ lua-curl-0.3.0/debian/control	2018-01-20 21:17:07.0 +0100
@@ -11,7 +11,7 @@
 Package: lua-curl
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
@@ -24,7 +24,7 @@
 Package: lua-curl-dev
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
+Pre-Depends: ${misc:Pre-Depends}
 Section: libdevel
 Depends: lua-curl (= ${binary:Version}), ${misc:Depends}
 Provides: ${lua:Provides}

Bug#780606: Bug#792101: Done / Not Done

[Stefan Monnier]

> Just to be clear, this is not in Debian main, it is in contrib.

Thank you very much for that.  Happily running it on my BananaPi here now.
What is its status exactly: I see "contrib" described as "free but
depending on non-free code", but it's not clear exactly what non-free
code it relies on.

I see also that it's now in "unstable" (tho not yet in "testing",
apparently) and compiled for various architectures including the armhf
I'm using, which is great.  Until those JS packaging issues are
resolved, do you plan on keeping the package uptodate on
a regular basis?


Stefan

Bug#886799: fixing openafs kernel module for security updated kernel

[Benjamin Kaduk]

The SRU request for jessie is in #887857.

I don't think there is a way to get a fix into jessie-backports, so
I think we will need to remove openafs-modules-source and
openafs-modules-dkms from jessie-backports and pull the version from
buster into jessie-backports-sloppy (which will be a trip through
NEW and require a DD sponsor, since I'm only a DM).

I'm still looking at wheezy.

-Ben

Bug#887857: jessie-pu: package openafs/1.6.9-2+deb8u6

[Benjamin Kaduk]

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

The recent kernel update in jessie-security with meltdown/spectre remediation
measures introduced some minor ABI changes that cause the version of the openafs
kernel module in jessie to be unable to compile.  More recent upstream versions
of openafs do compile against this kernel, so I need to backport the appropriate
build fixes in order to make openafs-modules-source and openafs-modules-dkms
usable in jessie again.  (The version in jessie-backports is also broken,
not that that is directly relevant here.)

I attach a debdiff with the needed patches, and I have tested the resulting
package in a jessie VM with the latest kernel from jessie-security.

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

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru openafs-1.6.9/debian/changelog openafs-1.6.9/debian/changelog
--- openafs-1.6.9/debian/changelog  2017-12-08 20:59:25.0 -0600
+++ openafs-1.6.9/debian/changelog  2018-01-20 11:48:09.0 -0600
@@ -1,3 +1,11 @@
+openafs (1.6.9-2+deb8u7) jessie-proposed-updates; urgency=high
+
+  * Apply upstream patches needed to fix kernel module build against
+linux 3.16.51-3+deb8u1 kernels after security update-induced ABI changes.
+(Closes: #886719)
+
+ -- Benjamin Kaduk   Sat, 20 Jan 2018 11:48:09 -0600
+
 openafs (1.6.9-2+deb8u6) jessie-security; urgency=high
 
   * CVE-2017-17432: remote triggered Rx assertion failure
diff -Nru 
openafs-1.6.9/debian/patches/0023-Linux-4.9-inode_change_ok-becomes-setattr_prepare.patch
 
openafs-1.6.9/debian/patches/0023-Linux-4.9-inode_change_ok-becomes-setattr_prepare.patch
--- 
openafs-1.6.9/debian/patches/0023-Linux-4.9-inode_change_ok-becomes-setattr_prepare.patch
   1969-12-31 18:00:00.0 -0600
+++ 
openafs-1.6.9/debian/patches/0023-Linux-4.9-inode_change_ok-becomes-setattr_prepare.patch
   2018-01-20 11:46:01.0 -0600
@@ -0,0 +1,57 @@
+From: Mark Vitale 
+Date: Thu, 20 Oct 2016 00:49:37 -0400
+Subject: Linux 4.9: inode_change_ok() becomes setattr_prepare()
+
+Linux commit 31051c85b5e2 "fs: Give dentry to inode_change_ok() instead
+of inode" renames and modifies inode_change_ok(inode, attrs) to
+setattr_prepare(dentry, attrs).
+
+Modify OpenAFS to cope.
+
+Reviewed-on: https://gerrit.openafs.org/12418
+Tested-by: BuildBot 
+Reviewed-by: Benjamin Kaduk 
+(cherry picked from commit 8aeb711eeaa5ddac5a74c354091e2d4f7ac0cd63)
+
+Change-Id: I7f08c57b7f61465a1ea1806f52f77bd65084
+Reviewed-on: https://gerrit.openafs.org/12480
+Tested-by: BuildBot 
+Reviewed-by: Mark Vitale 
+Reviewed-by: Stephan Wiesand 
+Tested-by: Stephan Wiesand 
+(cherry picked from commit 8efca09a5daa3cfc08d0d86e2fb48c9b8d1b270a)
+---
+ acinclude.m4 | 3 +++
+ src/afs/LINUX/osi_file.c | 4 
+ 2 files changed, 7 insertions(+)
+
+diff --git a/acinclude.m4 b/acinclude.m4
+index 80a05b7..e1cdc8c 100644
+--- a/acinclude.m4
 b/acinclude.m4
+@@ -947,6 +947,9 @@ case $AFS_SYSNAME in *_linux* | *_umlinux*)
+AC_CHECK_LINUX_FUNC([set_nlink],
+[#include ],
+[set_nlink(NULL, 1);])
++   AC_CHECK_LINUX_FUNC([setattr_prepare],
++   [#include ],
++   [setattr_prepare(NULL, NULL);])
+AC_CHECK_LINUX_FUNC([sock_create_kern],
+[#include ],
+[sock_create_kern(0, 0, 0, NULL);])
+diff --git a/src/afs/LINUX/osi_file.c b/src/afs/LINUX/osi_file.c
+index b83f736..d6c0fd6 100644
+--- a/src/afs/LINUX/osi_file.c
 b/src/afs/LINUX/osi_file.c
+@@ -184,7 +184,11 @@ osi_UFSTruncate(struct osi_file *afile, afs_int32 asize)
+ newattrs.ia_ctime = CURRENT_TIME;
+ 
+ /* avoid notify_change() since it wants to update dentry->d_parent */
++#ifdef HAVE_LINUX_SETATTR_PREPARE
++code = setattr_prepare(file_dentry(afile->filp), );
++#else
+ code = inode_change_ok(inode, );
++#endif
+ if (!code)
+   code = afs_inode_setattr(afile, );
+ if (!code)
diff -Nru 
openafs-1.6.9/debian/patches/0024-LINUX-Debian-Ubuntu-build-regression-on-kernel-3.16..patch
 
openafs-1.6.9/debian/patches/0024-LINUX-Debian-Ubuntu-build-regression-on-kernel-3.16..patch
--- 

Bug#887856: intel-microcode: Spectre / Meltdown : bring intel-microcode 20180104 to stretch

[Julien Aubin]

Package: intel-microcode
Version: 3.20171117.1~bpo9+1
Severity: critical
Tags: security
Justification: root security hole

Hi,

As of now intel-microcode of stretch is still set to 20170707 (20171117
through
bpo) which lets users vulnerable to Spectre attack CVE-2017-5715. Could you
please bring quickly the microcode update to stretch, at least on bpo ?

Thanks a lot



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

Kernel: Linux 4.9.0-5-amd64 (SMP w/8 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)

Versions of packages intel-microcode depends on:
ii  iucode-tool  2.1.1-1

Versions of packages intel-microcode recommends:
ii  initramfs-tools  0.130

intel-microcode suggests no packages.

-- no debconf information

Bug#887145: ITA: bluefish -- advanced Gtk+ text editor for web and software development

[Innocent De Marchi]

Hi Daniel,
I use this program and I have looked at the package and I can take care
of its maintenance (...or for sponsorship).
I trust your help if I have a problem with him.

Regards!

I. De Marchi


pgp4T1fOT2G7w.pgp
Description: Signatura digital d'OpenPGP

Bug#832528: Latest akonadi packages do not kick out old package baloo-utils

[Sandro Knauß]

Control: reassign -1 baloo-utils
Control: found -1 4:4.14.3-3
Control: affects -1 akonadi-server

Hey,

With kdepim with 16.08+ baloo package was split into baloo (file indexer) and 
akonadisearch the kdepim indexer. I can't tell you why at your system baloo-
utils are not removed by default. Maybe you need to run apt autoremove. There 
should normally no dependency stopping you from removing that cruft package. 
Additionally baloo-utils are part of baloo4 aka based on Qt4. So only the 
remaining Qt4 applications creating this unfortunate situation.

Please try to find out, what application stops the autoremoval of baloo-utils. 

hefee


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

Bug#887676: Stretch kernel 4.9.0-5-amd64 breaks Xen PVH support

[Michael J. Redd]

Aha! Okay, that certainly explains some things. I didn't realize PVH
was a "use at your own risk" tech preview in Xen 4.8 and kernel 4.9.
Luckily, my infrastructure didn't rely on PVH to start with; I can go
back to conventional PV or HVM with no problem.

Thanks for investigating!

-Michael

Bug#887855: stretch-pu: package libvirt/3.0.0-4+deb9u2

[Guido Günther]

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

Hi,
the above update addresses CVE-2018-5748 as well as a bug where disks
with cache=directsync couldn't be migrated (#883208).
O.k. to upload to stretch-pu?
Cheers,
 -- Guido

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

Kernel: Linux 4.14.0-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)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 222b31e543..f9aca519eb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libvirt (3.0.0-4+deb9u2) stretch; urgency=medium
+
+  * CVE-2018-5748: qemu: avoid denial of service reading from QEMU monitor
+(Closes: #887700)
+  * qemu: shared disks with cache=directsync should be safe for migration.
+Thanks to Carsten Burkhardt (Closes: #883208)
+
+ -- Guido Günther   Sat, 20 Jan 2018 17:51:39 +0100
+
 libvirt (3.0.0-4+deb9u1) stretch-security; urgency=high
 
   * CVE-2017-1000256: qemu: ensure TLS clients always verify the server
diff --git 
a/debian/patches/qemu-avoid-denial-of-service-reading-from-QEMU-monitor-CV.patch
 
b/debian/patches/qemu-avoid-denial-of-service-reading-from-QEMU-monitor-CV.patch
new file mode 100644
index 00..5d675ae6c3
--- /dev/null
+++ 
b/debian/patches/qemu-avoid-denial-of-service-reading-from-QEMU-monitor-CV.patch
@@ -0,0 +1,49 @@
+From: "Daniel P. Berrange" 
+Date: Tue, 16 Jan 2018 17:00:11 +
+Subject: qemu: avoid denial of service reading from QEMU monitor
+ (CVE-2018-5748)
+
+We read from QEMU until seeing a \r\n pair to indicate a completed reply
+or event. To avoid memory denial-of-service though, we must have a size
+limit on amount of data we buffer. 10 MB is large enough that it ought
+to cope with normal QEMU replies, and small enough that we're not
+consuming unreasonable mem.
+
+Signed-off-by: Daniel P. Berrange 
+---
+ src/qemu/qemu_monitor.c | 15 +++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
+index 1610ae3..86ce2d1 100644
+--- a/src/qemu/qemu_monitor.c
 b/src/qemu/qemu_monitor.c
+@@ -55,6 +55,15 @@ VIR_LOG_INIT("qemu.qemu_monitor");
+ #define DEBUG_IO 0
+ #define DEBUG_RAW_IO 0
+ 
++/* We read from QEMU until seeing a \r\n pair to indicate a
++ * completed reply or event. To avoid memory denial-of-service
++ * though, we must have a size limit on amount of data we
++ * buffer. 10 MB is large enough that it ought to cope with
++ * normal QEMU replies, and small enough that we're not
++ * consuming unreasonable mem.
++ */
++#define QEMU_MONITOR_MAX_RESPONSE (10 * 1024 * 1024)
++
+ struct _qemuMonitor {
+ virObjectLockable parent;
+ 
+@@ -565,6 +574,12 @@ qemuMonitorIORead(qemuMonitorPtr mon)
+ int ret = 0;
+ 
+ if (avail < 1024) {
++if (mon->bufferLength >= QEMU_MONITOR_MAX_RESPONSE) {
++virReportSystemError(ERANGE,
++ _("No complete monitor response found in %d 
bytes"),
++ QEMU_MONITOR_MAX_RESPONSE);
++return -1;
++}
+ if (VIR_REALLOC_N(mon->buffer,
+   mon->bufferLength + 1024) < 0)
+ return -1;
diff --git 
a/debian/patches/qemu-shared-disks-with-cache-directsync-should-be-safe-fo.patch
 
b/debian/patches/qemu-shared-disks-with-cache-directsync-should-be-safe-fo.patch
new file mode 100644
index 00..01bcc4ca64
--- /dev/null
+++ 
b/debian/patches/qemu-shared-disks-with-cache-directsync-should-be-safe-fo.patch
@@ -0,0 +1,41 @@
+From: Hao Peng 
+Date: Sat, 15 Jul 2017 23:01:25 +0800
+Subject: qemu: shared disks with cache=directsync should be safe for
+ migration
+
+At present shared disks can be migrated with either readonly or cache=none. But
+cache=directsync should be safe for migration, because both cache=directsync 
and cache=none
+don't use the host page cache, and cache=direct write through qemu block layer 
cache.
+
+Signed-off-by: Peng Hao 
+Reviewed-by: Wang Yechao 
+---
+ src/qemu/qemu_migration.c | 7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
+index 0f4a6cf..dba5897 100644
+--- a/src/qemu/qemu_migration.c
 b/src/qemu/qemu_migration.c
+@@ -2375,9 +2375,10 @@ qemuMigrationIsSafe(virDomainDefPtr def,
+ const char *src = virDomainDiskGetSource(disk);
+ 
+ 

Bug#885042: Check inclusion of Apache 2.0 NOTICE files

[Russ Allbery]

Russ Allbery  writes:

> I'll be open about this: I think that there's a deep mismatch between
> how we like to discuss things, which is why I'm trying to avoid getting
> into a back and forth.  I think you're just trying to be clear and
> precise, but I find the close textual reading that you're doing in this
> discussion demoralizing and off-putting.

...which should have been my cue to just sleep on it.

Ben, I'm sorry, I now understand what happened, I think.  I was way too
tired last night and couldn't figure out what you were getting at, and
then got frustrated.

I believe you thought I was arguing that copying the contents of NOTICE
into debian/copyright *wasn't* allowed by the license for some reason.
That had never occurred to me; I was assuming as a given that of course
that was fine with the license.  So I got really confused about why you
were debating what the license said.

Then, in trying to figure out why you were talking about the specific
wording of the license, I ended up thinking you were arguing that any
normal construction of debian/copyright would naturally include all the
information that upstream would put in a NOTICE file, even if the
maintainer never looked at the NOTICE file.  (In my defense, I've seen a
fair number of Apache 2.0 packages where the NOTICE file was just a copy
of the license grant paraagraph, so if one only saw such packages, it
wouldn't be an outlandish assumption.)  So I started arguing about that,
which wasn't what you meant at all.

Anyway, just to try to finally clear up this misunderstanding, I
completely agree with you that putting the contents of NOTICE in
debian/copyright complies with the Apache 2.0 license.  My argument is
only that that's fragile and more effort to maintain, not that it's not
allowed.  I personally want the Lintian tag because I don't trust myself
to remember to check for NOTICE files, particularly if upstream introduces
one in a later release after the first packaging, and don't trust myself
to remember to update a copy of it.  I have no opinion about its severity
or certainty, given that there is an alternate way of satisfying the
license that would trigger the tag.

I'm very sorry for having gotten irritated with you over a
misunderstanding.  I really need to not reply to email I'm puzzled by at
the tail end of a long week without enough sleep.

-- 
Russ Allbery (r...@debian.org)   

Bug#887854: RFS: fet/5.35.1-1 [ITA]

[Innocent De Marchi]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: fet
   Version : 5.35.1-1
   Upstream Author : [Lalescu Liviu 
 * URL : http://www.lalescu.ro/liviu/fet/
 * License : AGPL-3+
   Section : utils

  It builds those binary packages:

fet   - timetable generator
 fet-data   - timetable generator - documentation and examples

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/f/fet/fet_5.35.1-1.dsc


  Changes since the last upload:

  * New upstream version 5.35.1
  * New Maintainer (Closes: #798954).
  * Bumped to python3 debian/control Recommends field.


  Regards,

  I. De Marchi

Bug#887852: /dev/kvm is no longer accessible to local users

[Alexander Kurtz]

Package: systemd
Version: 236-3

Hi!

Until recently, /dev/kvm was made accessible to local users by this
line in /lib/udev/rules.d/70-uaccess.rules:

# KVM
SUBSYSTEM=="misc", KERNEL=="kvm", TAG+="uaccess"

However, as of systemd 236, the above rule seems to be gone. After
reading up a bit on systemd's upstream and Debian bug tracker, I'm even
more confused than before: Which package is supposed to manage
permissions on /dev/kvm in Debian? Which package is supposed to create
the "kvm" group? Is the missing access for local users intentional?

Best regards

Alexander Kurtz

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

Bug#887853: RFS: gnustep-gui/0.26.2-1

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I'm looking for a sponsor for my package "gnustep-gui".

 * Package name: gnustep-gui
   Version : 0.26.2-1
   Upstream Author : Fred Kiefer ,
 Adam Fedor ,
 Richard Frith-Macdonald ,
 Nicola Pero ,
 Gregory Casamento ,
 Alexander Malmberg ,
 Ivan Vučica  and many others
 * URL : http://gnustep.org
 * License : LGPL-2+ (library), GPL-3+ (tools)
   Section : gnustep

It builds these binary packages:

gnustep-gui-common - GNUstep GUI Library - common files
gnustep-gui-doc - Documentation for the GNUstep GUI Library
gnustep-gui-runtime - GNUstep GUI Library - runtime files
libgnustep-gui-dev - GNUstep GUI header files and static libraries
libgnustep-gui0.26 - GNUstep GUI Library

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

  https://mentors.debian.net/package/gnustep-gui

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnustep-gui/gnustep-gui_0.26.2-1.dsc

Changes since the last upload:

  [ Eric Heintzmann ]
  * debian/patches/fix-spelling-errors.patch: Remove, applied upstream.
  * debian/patches/series: Update.
  * debian/templates/control.m4:
+ Bump Standards-Version to 4.1.0.
+ As required by Gürkan, update his name.
+ Use canonical URL in Vcs-Browser field.
  * Add a testsuite.
  * debian/rules:
+ Remove -pie option.
+ Now depends on latest gnustep-base.
+ Enable --as-needed LDFLAG.
+ Remove -shared-libgcc LDFLAG, now useless.
+ Recalculate dependencies of shared lib.

  [ Yavor Doganov ]
  * New upstream release 0.26.2:
+ Fixes printing via CUPS (Closes: #883583).
+ Fixes overlapping glyphs (Closes: #886226).
+ Rename library package following the SONAME change:
  - libgnustep-gui0.25 -> libgnustep-gui0.26
  * debian/watch: Switch to ftp.gnustep.org; much more reliable.
  * debian/compat: Bump compat level to 11.
  * debian/rules: Replace shell comments with makefile comments; strip
trailing whitespace.
(DEB_LDFLAGS_MAINT_APPEND): Add -Wl,--no-undefined.
(v_base): Bump to 1.25.1; required.
(override_dh_testdir): New target to regenerate debian/control.
(override_dh_auto_build_arch): Explicitly pass dpkg-buildflags;
gnustep-make discards environment flags so OBJCFLAGS is ignored
completely for all compilation units, while LDFLAGS is discarded for
some executables in the -runtime package.  Also pass $(optim) for
proper noopt support in DEB_BUILD_OPTIONS.
(override_dh_autotest): Run the testsuite.
(override_dh_install): Don't skip .gsdoc files; they're necessary for
generating proper cross-references.
(override_dh_installdocs): Don't act on the -dbg package.
(override_dh_strip): Remove override.
  * debian/templates/control.m4: Remove -dbg package in favor of automatic
-dbgsym packages.  Relax some dependencies for smoother transitions (a
reincarnation of #655433; regression introduced during the migration
to modern debhelper).
(Build-Depends): Require debhelper >= 11; remove dh-autoreconf.  Add
gnustep-make >= 2.7.0-3 for the optim variable conditional definition.
(Build-Depeends-Indep): Add gnustep-base-doc for usable xrefs to -base
classes and methods.
(gnustep-gui-doc): Recommend gnustep-base-doc.
(Standards-Version): Claim compliance with 4.1.3 as of this release.
  * debian/control: Regenerate.
  * debian/tests/testsuite: New test; run the testsuite.
  * debian/tests/control (Tests): Add testsuite.
(Restrictions): Add allow-stderr.
(Depends): Add file, needed by file-tests.
  * debian/templates/libgnustep-guiN.overrides.m4: Remove override for
no-symbols-control-file as lintian #749202 has been fixed.
  * debian/changelog: Whitespace cleanup.
  * debian/copyright: Update copyright years.

Bug#887797: libgaminggear-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc-base/libgaminggear

[Pierre-Elliott Bécue]

Le samedi 20 janvier 2018 à 01:24:53+0100, Andreas Beckmann a écrit :
> Package: libgaminggear-doc
> Version: 0.15.1-4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces
> 
> From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package libgaminggear-doc.
>   Preparing to unpack .../5-libgaminggear-doc_0.15.1-4_all.deb ...
>   Unpacking libgaminggear-doc (0.15.1-4) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-gCm8r9/5-libgaminggear-doc_0.15.1-4_all.deb (--unpack):
>trying to overwrite '/usr/share/doc-base/libgaminggear', which is also in 
> package libgaminggear-dev:amd64 0.15.1-3
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-gCm8r9/5-libgaminggear-doc_0.15.1-4_all.deb

Oops, my bad, sorry for the mess.

Fixing it in a new release.

Cheers,

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


signature.asc
Description: PGP signature

Bug#866458: Please update Git repository mentioned in VCS fields

[Yaroslav Halchenko]

On Sat, 20 Jan 2018, Andreas Tille wrote:



> Could you please bring the Git repository in sync to enable me to make
> a proper team upload instead of putting the work to inject a NMU into
> the repository for something that is so simple that if it would be less
> work if you do it yourself.

our bad

moszumanska:~
*$> cat /srv/git.debian.org/git/pkg-exppsy/pydicom.git/HEAD 
ref: refs/heads/debian-release

$> echo 'ref: refs/heads/debian' >| 
/srv/git.debian.org/git/pkg-exppsy/pydicom.git/HEAD


try now ;)
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#887851: python-gnupg: backport to stable/stretch

[W. Martin Borgert]

Package: python-gnupg
Version: 0.4.1-1
Severity: wishlist

As coordinated with the maintainer, I'll do the backport myself.
This is needed to solve #886539.

Bug#885384: Unblock

[Sean Whitton]

control: unblock 885384 by 885409

Hello,

I've thought about this some more and realised that packaging
cider-nrepl does not need to block packaging CIDER.  What matters is
that CIDER be configured not to surprise-download JARs by default, and I
can do that by patching to change the default value of
cider-inject-dependencies-at-jack-in.

In the future I hope we could have CIDER inject its deps from
/usr/share/maven-repo.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#887701: CUDA 9.1 available

[Andreas Beckmann]

Control: tag -1 pending

On 2018-01-19 09:04, Lumin wrote:
> Package: nvidia-cuda-toolkit
> Severity: wishlist
> 
> Upstream 9.1 is available:
> 
> https://developer.nvidia.com/cuda-toolkit
> https://developer.nvidia.com/cuda-toolkit/whatsnew
> https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html

Packaged and on its way to experimental/NEW, but completely untested.
Will need a 390.xx driver (with some Provides yet to be added).


Andreas

Bug#887728: RFS: nvidia-cudnn/7.0.5~cuda9.0-1 [ITP / ppc64el help needed]

[Andreas Beckmann]

quickly checked this since I was on plummer anyway for CUDA 9.1 ...

On 2018-01-19 13:58, Lumin wrote:
>   1. build on ppc64el to see if the rules is working for ppc64el
Works fine.

>   2. update *.symbols.ppc64el, stripping the debian revision.
No differences to the amd64 symbols -> rename to *.symbols


debian/gbp.conf:

[buildpackage]
overlay = True
export-dir = ../build-area
create-orig = False
pristine-tar = False
compression = gz
tarball-dir = ../tarballs-nvidia-cudnn
component = [ 'ppc64el', ]

lintian tells me this, the first three need to be fixed:

P: nvidia-cudnn source: source-contains-prebuilt-binary lib64/libcudnn.so.7.0.5
P: nvidia-cudnn source: source-contains-prebuilt-binary 
ppc64el/targets/ppc64le-linux/lib/libcudnn.so.7.0.5
I: nvidia-cudnn source: unused-file-paragraph-in-dep5-copyright paragraph at 
line 14
I: nvidia-cudnn source: testsuite-autopkgtest-missing
I: nvidia-cudnn source: debian-watch-file-is-missing
P: libcudnn7: no-upstream-changelog
P: libcudnn-dev: no-upstream-changelog

Andreas

Bug#882618: Pending fixes for bugs in the libdbix-class-schema-loader-perl package

[pkg-perl-maintainers]

tag 882618 + pending
thanks

Some bugs in the libdbix-class-schema-loader-perl package are closed
in revision 5c422180e28ee04e2d6197f9f7c27e5e09b15d07 in branch
'master' by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdbix-class-schema-loader-perl.git/commit/?id=5c42218

Commit message:

Add patch 0001-Disable-cloning-when-merging-hashes.patch

to handle Hash::Merge's changed cloning behaviour.

Thanks: Niko Tyni for writing the patch.
Closes: #882618

Bug#887850: dgit-maint-merge(7): Don't suggest using debian/source/patch-header for 1.0 source format

[Sean Whitton]

Package: dgit
Version: 4.2
Severity: minor
Tags: patch

Hello,

That file is ignored by the 1.0 format.  Thanks to Matthew Vernon for
pointing this out.

-- 
Sean Whitton
From 32cbb3e864604de03fe1f97644a7f809ddec81fe Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sat, 20 Jan 2018 09:32:56 -0700
Subject: [PATCH] dgit-maint-merge(7): debian/source/patch-header not in format
 1.0

Suggested-by: Matthew Vernon 
Signed-off-by: Sean Whitton 
---
 dgit-maint-merge.7.pod | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index 0040604..2674d66 100644
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -300,9 +300,14 @@ A single combined diff, containing all the changes, follows.
 
 =back
 
-Alternatively, this text could be added to README.source. However,
-this might distract from more important information present in the
-latter file.
+If you are using the version 1.0 source package format, this text
+should be added to README.source instead.  The version 1.0 source
+package format ignores debian/source/patch-header.
+
+If you're using the version 3.0 (quilt) source package format, you
+could add this text to README.source instead of
+debian/source/patch-header, but this might distract from more
+important information present in README.source.
 
 =head1 BUILDING AND UPLOADING
 
-- 
2.15.1



signature.asc
Description: PGP signature

Bug#873128: Is this a xepersian bug?

[Eliad Bagherzadegan]

  
  
Hi,


This is apparently a xepersian bug. See [1]. 





[1] https://github.com/tex-xet/xepersian/issues/20

-- 
Eliad Bagherzadegan (eliad@gmail.com)
  

Bug#887849: "qmake: could not find a Qt installation of ''" when QT_SELECT is unset

[Helmut Grohne]

Package: qtchooser
Version: 64-ga1b6736-5
File: /usr/bin/qmake
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:transmission

transmission fails to cross build from source. It runs qmake via
dh_auto_configure and is greeted with:

qmake: could not find a Qt installation of ''

A native build works. It doesn't export QT_SELECT, but after exporting
QT_SELECT=qt5 the qmake invocation succeeds. Thus I think this is a bug
in qtchooser. For native builds it defaults to qt5, but for cross builds
it doesn't. I have no clue why and simply hand this over to Dmitry and
Lisandro who have done an awful lot of work to make qt cross build
friendly. I hope you can figure out what is broken here.

Helmut

Bug#887810: krb5-multidev: "krb5-config.mit --cflags gssapi" returns wrong include directory

[Sam Hartman]

I am testing a fix.
My apologies for the sloppy change.

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Andreas Beckmann]

On 2018-01-18 23:59, David Kalnischkies wrote:
> Hi,
> 
> On Thu, Jan 18, 2018 at 09:45:51PM +0100, Aurelien Jarno wrote:
> [...]
>   Preparing to unpack .../3-libglib2.0-dev_2.54.3-1_i386.deb ...
>   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
> not found (required by /lib/i386-linux-gnu/libexpat.so.1)
>   dpkg: warning: subprocess old pre-removal script returned error exit 
> status 1
>   dpkg: trying script from the new package instead ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-wfemKS/3-libglib2.0-dev_2.54.3-1_i386.deb 
> (--unpack):
>there is no script in the new version of the package - giving up
>   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
> not found (required by /lib/i386-linux-gnu/libexpat.so.1)

 This failure is normal given libexpat1 requires the new libc which has
 not been unpacked yet.
>>>
>>> Yeah, well, it needs to Pre-Depend on it then I guess, if it's being used
>>> in preinst actions. The thing is that Depends only after postinst ordering,
>>> not unpack ordering.
>>
>> Well it's not the preinst script, but the prerm script. The problem is
>> unpacking libexpat1 before libc6 breaks libexpat1 and not usable
>> anymore.
> 
> prerm is the very first script being called (see §6.6) and usually it is
> the script of the version installed (only in error cases the script from
> the version being upgraded to will be tried as detailed in the dpkg
> messages) so I would argue that the dependencies (maybe) satisfied are
> the dependencies of the installed version, not the one being installed
> (argueably the dependency set of v1 and v2 could conflict with each
> other, so if dependencies of v2 would be satisfied that means v1 script
> would be bound to explode). But thats perhaps just the fear talking as
> going with dependencies of v2 would probably result in a lot of hard
> coding problems for apt & dpkg (and other low package managers).
> 
> In any case, the unpack of these packages is in the same dpkg call, so
> if dpkg would have wanted it could have reordered them & apt has no idea
> about maintainerscript in general, so I would say this isn't an apt bug.
> 
> (Althrough, if we decide on v2, I guess apt needs to change anyhow as
> that same call thing might be just dumb luck in this case. Not even sure
> if v1 is in any way "guaranteed" to be perfectly honest…)
> 
> Can't stop the feeling that we had issues with python begin called from
> prerm before and the general advice was: "don't – stick to essential".

I tested a bit more to find adding which Pre-Depends would solve the
issue *without* adding a dummy empty prerm to libglib2.0-dev:

libglib2.0-dev: Pre-Depends: libexpat1
OR
libexpat1: Pre-Depends: libc6 (>= 2.25)

The following does not help:

libglib2.0-dev: Pre-Depends: python3:any


For now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
error starts to show up elsewhere (e.g. in a package where both old and
new prerm use python3), probably adding the Pre-Depends to libexpat1
would be the general solution.


Andreas

Bug#846982: List of packages to change priority for

[Luca Falavigna]

Given Josh's attempt to provide an updated list, which was limited to
just amd64 and i386, I extracted all the packages with priority
standard or higher from projectb (therefore including all arches by
definition).

File "priorities" contains the full list of packages having standard
or higher priority, file "priorities to change" contains a filtered
list of packages which will have priority changed. Basically they are
all the packages having section libs or libdevel.

I had a look at the other packages to find potential candidates, but
it seems it's reasonable to leave them as they are.

Unless somebody objects, I'm going to change overrides in a few days.

-- 
Cheers,
Luca


priorities
Description: Binary data


priorities
Description: Binary data

Bug#887847: Extra quoting needed for the job description

[Yuri D'Elia]

Package: systemd-cron
Version: 1.5.12-2
Severity: normal

Found this in the wild: zfsutils-linux package has the following cron.d entry:


# Scrub the second Sunday of every month.
24 0 8-14 * * root [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/scrub ] && 
/usr/lib/zfs-linux/scrub


generating this timer unit:


[Unit]
Description=[Timer] "24 0 8-14 * * root [ $(date +\%w) -eq 0 ] && [ -x 
/usr/lib/zfs-linux/scrub ] && /usr/lib/zfs-linux/scrub"


which yields:

/run/systemd/generator/cron-zfsutils-linux-root-0.timer:2: Failed to resolve unit specifiers on [Timer] 
"24 0 8-14 * * root [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/scrub ] && 
/usr/lib/zfs-linux/scrub", ignoring: Invalid slot

The % should be escaped in Description as well using %%.

-- Package-specific info:
-- output of systemd-delta

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

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

Versions of packages systemd-cron depends on:
ii  libc6 2.26-4
ii  python3   3.6.4-1
ii  systemd-sysv  236-3

Versions of packages systemd-cron recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.90-3

systemd-cron suggests no packages.

Bug#887593: libreoffice-common: apparmor profiles triggers lot of ALLOWED entries

[Rene Engelhard]

Hi,

On Fri, Jan 19, 2018 at 11:24:56PM +0100, Christian Boltz wrote:
> If you want to have a common child profile for gpg and gpgsm, use
> 
>   /usr/bin/gpg  mrCx -> gpg,
>   /usr/bin/gpgsmmrCx -> gpg,
> 
>   profile gpg {
>   # whatever is needed
>   }

OK, done

https://cgit.freedesktop.org/libreoffice/core/commit/?id=24702687433842a6e9e8a1070ead46c035192bf3

and

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/f823c912e69cb0611a009f49c

Regards,

Rene

Bug#887846: libffado: new upstream release, qt5 and python3 support

[Benoît Delcour]

Source: libffado
Version: 2.3.0-5
Severity: wishlist

Dear Maintainer,

A new upstram version is available; it supports Qt5 and Python3.
I am working on it. It currently compiles, but is not tested yet.
WIP: updating and checking the copyright file requires some work.

Bug#851187: ITA: Pygithub -- Access the full Github API v3 from Python3

[eamanu15 .]

Control: retitle -1 ITA: Pygithub -- Access the full Github API v3 from Python3

Control: owner -1 emmanuelaria...@gmail.com

I would like to adopt this package

Regards!



-- 
Arias Emmanuel
https://www.linkedin.com/in/emmanuel-arias-437a6a8a
http://eamanu.com

Bug#883897: stretch-pu: package congress/4.0.0+dfsg1-3 -> +deb9u1

[Thomas Goirand]

On 01/13/2018 06:11 PM, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> On Sat, Dec  9, 2017 at 00:30:01 +0100, Thomas Goirand wrote:
> 
>> Package: release.debian.org
>> Severity: normal
>> Tags: stretch
>> User: release.debian@packages.debian.org
>> Usertags: pu
>>
>> Dear release team,
>>
>> congress-server was built with openstack-pkg-tools *before* it stopped using
>> /sbin/route from net-tools. Therefore, it's using /usr/sbin at setup time
>> even though net-tools isn't a runtime dependency.
>>
>> So I would like to upload a rebuild of Congress to Stretch, so its
>> maintainer scripts would not need net-tools anymore. This would fix #858693.
>>
>> Of course, since I am not planning any modification to the package, I have
>> no debdiff to show (it would only contain a new changelog entry, which isn't
>> very useful to review).
>>
> If the rebuild makes a difference, then please show what that difference
> actually is?  Possibly that means a binary debdiff in addition to the
> normal source diff.
> 
> Cheers,
> Julien

Hi Julien,

Here's the resulting changes on the config script, attached to this
message, together with the debdiff. As you can see, the script now reads
/proc/net/route directly instead of using /sbin/route, so we don't need
the net-tools package which was otherwise missing in dependencies.

Cheers,

Thomas Goirand (zigo)
diff -Nru congress-4.0.0+dfsg1/debian/changelog 
congress-4.0.0+dfsg1/debian/changelog
--- congress-4.0.0+dfsg1/debian/changelog   2016-11-03 11:16:31.0 
+
+++ congress-4.0.0+dfsg1/debian/changelog   2018-01-19 14:59:16.0 
+
@@ -1,3 +1,9 @@
+congress (4.0.0+dfsg1-3+deb9u1) stretch; urgency=medium
+
+  * Rebuilt with openstack-pkg-tools >= 54~.
+
+ -- Thomas Goirand   Fri, 19 Jan 2018 15:59:16 +0100
+
 congress (4.0.0+dfsg1-3) unstable; urgency=medium
 
   * Add patch to remove non-deterministic tests which are randomly failing.
diff -Nru congress-4.0.0+dfsg1/debian/control 
congress-4.0.0+dfsg1/debian/control
--- congress-4.0.0+dfsg1/debian/control 2016-11-03 11:16:31.0 +
+++ congress-4.0.0+dfsg1/debian/control 2018-01-19 14:59:16.0 +
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 9),
dh-python,
dh-systemd,
-   openstack-pkg-tools (>= 52~),
+   openstack-pkg-tools (>= 54~),
po-debconf,
python-all,
python-pbr (>= 1.8),
--- config_4.0.0+dfsg1-3	2018-01-19 15:01:06.435195600 +
+++ config	2018-01-20 13:10:12.214651060 +
@@ -651,8 +651,12 @@
 
 		db_get ${REG_ENDP_PKG_NAME}/endpoint-ip || true
 		if [ -z "${RET}" ] ; then
-			DEFROUTE_IF=`LC_ALL=C /sbin/route | grep default |awk -- '{ print $8 }'`
-			DEFROUTE_IP=`LC_ALL=C ip addr show "${DEFROUTE_IF}" | grep inet | head -n 1 | awk '{print $2}' | cut -d/ -f1 | grep -E '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$'`
+			if [ -x /bin/ip ] ; then
+DEFROUTE_IF=`awk '{ if ( $2 == "" ) print $1 }' /proc/net/route`
+DEFROUTE_IP=`LC_ALL=C ip addr show "${DEFROUTE_IF}" | grep inet | head -n 1 | awk '{print $2}' | cut -d/ -f1 | grep -E '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$'`
+			else
+DEFROUTE_IP=`hostname -i | grep -E '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$'`
+			fi
 			if [ -n "${DEFROUTE_IP}" ] ; then
 db_set ${REG_ENDP_PKG_NAME}/endpoint-ip ${DEFROUTE_IP}
 			fi

Bug#887624: new hardwired SetupAPTPartialDirectory foils non-root use

[積丹尼 Dan Jacobson]

Good.
Maybe add "test as non-root too" to any new feature test scripts,
to catch problems like these in the future.