Bug#920281: Re : Bug#920281: Re : Bug#920281: ntopng: Unable to finish the post-inst.

[nicolas . patrois]

Le 24/01/2019 20:15:54, Ludovico Cavedon a écrit :

> From the previous on sid, then, 3.2 (which never made it to testing).

> Can you also send me the output of the following commands, please?

> ls -ld  /var/lib/ntopng
drwx-- 2 ntopng ntopng 4096 janv. 22 02:46 /var/lib/ntopng

> ls -l  /var/lib/ntopng
total 0

> grep ntopng /var/log/dpkg.log
2019-01-23 07:03:42 upgrade ntopng:i386 3.2+dfsg1-1+b1 3.8+dfsg1-1
2019-01-23 07:03:42 status half-configured ntopng:i386 3.2+dfsg1-1+b1
2019-01-23 07:05:15 status unpacked ntopng:i386 3.2+dfsg1-1+b1
2019-01-23 07:05:15 status half-installed ntopng:i386 3.2+dfsg1-1+b1
2019-01-23 07:05:22 status unpacked ntopng:i386 3.8+dfsg1-1
2019-01-23 07:05:23 upgrade ntopng-data:all 3.2+dfsg1-1 3.8+dfsg1-1
2019-01-23 07:05:23 status half-configured ntopng-data:all 3.2+dfsg1-1
2019-01-23 07:05:23 status unpacked ntopng-data:all 3.2+dfsg1-1
2019-01-23 07:05:23 status half-installed ntopng-data:all 3.2+dfsg1-1
2019-01-23 07:05:31 status unpacked ntopng-data:all 3.8+dfsg1-1
2019-01-23 07:17:16 configure ntopng-data:all 3.8+dfsg1-1 
2019-01-23 07:17:16 status unpacked ntopng-data:all 3.8+dfsg1-1
2019-01-23 07:17:16 status half-configured ntopng-data:all 3.8+dfsg1-1
2019-01-23 07:17:16 status installed ntopng-data:all 3.8+dfsg1-1
2019-01-23 07:17:17 configure ntopng:i386 3.8+dfsg1-1 
2019-01-23 07:17:17 status unpacked ntopng:i386 3.8+dfsg1-1
2019-01-23 07:17:18 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-23 07:24:47 configure ntopng:i386 3.8+dfsg1-1 
2019-01-23 07:24:47 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-23 15:13:28 configure ntopng:i386 3.8+dfsg1-1 
2019-01-23 15:13:28 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-23 15:24:19 configure ntopng:i386 3.8+dfsg1-1 
2019-01-23 15:24:19 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-23 18:35:40 configure ntopng:i386 3.8+dfsg1-1 
2019-01-23 18:35:40 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-23 18:36:27 configure ntopng:i386 3.8+dfsg1-1 
2019-01-23 18:36:27 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-24 07:39:39 configure ntopng:i386 3.8+dfsg1-1 
2019-01-24 07:39:39 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-24 07:40:17 configure ntopng:i386 3.8+dfsg1-1 
2019-01-24 07:40:17 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-24 17:23:31 configure ntopng:i386 3.8+dfsg1-1 
2019-01-24 17:23:31 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-24 17:25:20 configure ntopng:i386 3.8+dfsg1-1 
2019-01-24 17:25:20 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-25 06:30:24 configure ntopng:i386 3.8+dfsg1-1 
2019-01-25 06:30:24 status half-configured ntopng:i386 3.8+dfsg1-1
2019-01-25 06:34:56 configure ntopng:i386 3.8+dfsg1-1 
2019-01-25 06:34:56 status half-configured ntopng:i386 3.8+dfsg1-1

 means  in French.

> The new ntopng uses /var/lib/ntopng instead of /var/tmp/ntopng, and a
> different user.
> Something is going wrong with the migration I have not been able to
> reproduce yet.

> If you do not care about the old data, you can just remove 
> /var/tmp/ntopng
> Otherwise you can move /var/tmp/ntopng to /var/lib/ntopng and
> chown -R ntopng:ntopng /var/lib/ntopng
> cmod 700 /var/lib/ntopng

Solved. Thanks.
You can close the bug report.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#920158: stterm: Crash when displaying emoji

[Timothy Allen]

On Thu, 2019-01-24 at 13:17 +0100, Paride Legovini wrote:
> Thanks for your report. Unfortunately I can't reproduce the crash (I
> actually get an octagonal sign with that printf), so it is difficult
> for
> me to debug the issue or forward the bug upstream.

Thanks for looking into it!

Out of curiosity, what fonts do you have installed? When I search for
fonts on my system that provide OCTAGONAL SIGN, I only get one match:

$ fc-list :charset=0x1F6D1
/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf: Noto Color 
Emoji:style=Regular

(from the fonts-noto-color-emoji package)

It looks like st does glyph-scavenging so it can display glyphs that
aren't in the selected font; perhaps it's not prepared to handle fonts
that provide colour bitmaps.

(I notice xterm added glyph-scavenging support in version 338 on 2018-
12-09, and subsequent versions have added various checks and safeguards
to avoid colour bitmap fonts rather than support them)

Bug#920409: splitpatch: please make the build reproducible

[Chris Lamb]

Source: splitpatch
Version: 1.0+20170926+git322ebca-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that splitpatch could not be built reproducibly.

This is because the embedded pod2man.mk uses the current build
date.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2019-01-25 08:42:48.543410438 
+0100
@@ -0,0 +1,21 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2019-01-25
+
+--- splitpatch-1.0+20170926+git322ebca.orig/man/pod2man.mk
 splitpatch-1.0+20170926+git322ebca/man/pod2man.mk
+@@ -36,7 +36,13 @@ RELEASE ?= $(PACKAGE)
+ 
+ # Optional variables to set
+ MANSECT   ?= 1
+-PODCENTER ?= $$(date "+%Y-%m-%d")
++
++DATE_FMT = %Y-%m-%d
++ifdef SOURCE_DATE_EPOCH
++PODCENTER ?= $$(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "+$(DATE_FMT)" 
2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "+$(DATE_FMT)" 2>/dev/null || 
date -u "+$(DATE_FMT)")
++else
++PODCENTER ?= $$(date "$(DATE_FMT)")
++endif
+ 
+ # Directories
+ MANSRC=
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2019-01-25 08:42:47.423403838 +0100
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Alexander Larsson]

On Fri, Jan 25, 2019 at 5:07 AM Akira TAGOH  wrote:
>
>
> >
> > as-path=... ?
>
> That sounds good to me.

This sounds good to me to. I updated the PR:
  https://github.com/flatpak/flatpak/pull/2635#issuecomment-457482239

Can I get an ack on this format?

Bug#917939: please enable CONFIG_ARM_ARMADA_37XX_CPUFREQ for arm64

[Andre Heider]

On Sat, 19 Jan 2019 17:04:43 +0900 Hideki Yamane 
 wrote:

Hi,

On Tue, 1 Jan 2019 10:27:00 +0100 Andre Heider  wrote:
> Source: linux
> Version: 4.19.12-1
> Severity: wishlist
> 
> Hi,
> 
> this option is missing for cpu frequency scaling on e.g. my espressobin.


 arch/arm64/configs/defconfig seems to have it in 4.19.12-1 to me.

$ grep CONFIG_ARM_ARMADA_37XX_CPUFREQ -r ./
./arch/arm64/configs/defconfig:CONFIG_ARM_ARMADA_37XX_CPUFREQ=y
./drivers/cpufreq/Makefile:obj-$(CONFIG_ARM_ARMADA_37XX_CPUFREQ)+= 
armada-37xx-cpufreq.o


Yes, that's the upstream defconfig, it's just missing for Debian.

Could we please get that option? Pretty please? :)

Bug#843021: [Pkg-javascript-devel] RFS: node-yarnpkg

[Paolo Greppi]

Il 25/01/19 07:18, Paolo Greppi ha scritto:
> Il 25/01/19 06:24, Pirate Praveen ha scritto:
>> On വെ, ജനു 25, 2019 at 10:22 രാവിലെ, Paolo Greppi  
>> wrote:
>>> ...
>>
>> E: yarnpkg: package-contains-ancient-file 
>> usr/lib/nodejs/yarn/node_modules/npm-logical-tree/CHANGELOG.md 1970-01-01 
>> (and some more)
> 
> ...
> I wonder how we can fix this !
> 
> Paolo

@yadd says:
> Remove *.orig.tar.gz and regenerate them with gbp buildpackage

and indeed:

rm ../node-yarnpkg_1.13.0.orig*
gbp buildpackage -uc -us

now the npm-logical-tree tarball is different and:

tar xf ../node-yarnpkg_1.13.0.orig-npm-logical-tree.tar.gz
ls node-yarnpkg-1.13.0/ -l
totale 28
-rw-r--r-- 1 paolog paolog 1222 gen 25 08:09 CHANGELOG.md
-rw-r--r-- 1 paolog paolog 4919 gen 25 08:09 index.js
-rw-r--r-- 1 paolog paolog  755 gen 25 08:09 LICENSE.md
-rw-r--r-- 1 paolog paolog 1380 gen 25 08:09 package.json
-rw-r--r-- 1 paolog paolog 4563 gen 25 08:09 README.md

Paolo

Bug#920408: mate-utils: Dependency problem

[Lars Skovlund]

Package: mate-utils
Version: 1.20.2-2
Severity: important

Dear Maintainer,

mate-utils has a hard dependency on mate-utils-common (>= 1.20.2-2), but it has
not been uploaded, breaking upgrades. The latest version of mate-utils-common is
1.20.2-1 as indicated below. I have checked in Incoming, and it is not there 
either. 
Please fix.

Thanks,

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

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

Versions of packages mate-utils depends on:
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-5
ii  libcairo-gobject2 1.16.0-2
ii  libcairo2 1.16.0-2
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.38.0+dfsg-7
ii  libglib2.0-0  2.58.2-4
ii  libgtk-3-03.24.3-1
ii  libgtop-2.0-112.38.0-4
ii  libice6   2:1.0.9-2
ii  libmate-panel-applet-4-1  1.20.4-2
ii  libmatedict6  1.20.2-2
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libsm62:1.2.2-1+b3
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  mate-desktop-common   1.20.4-2
ii  mate-utils-common 1.20.2-1
ii  zlib1g1:1.2.11.dfsg-1

mate-utils recommends no packages.

mate-utils suggests no packages.

-- no debconf information

Bug#920357: partitionmanager and F2FS

[pieter]

I installed f2fs-tools and learned that formatting a usb-stick to F2FS gives 
the same unwanted result. A user is not permitted to write.

Bug#843021: [Pkg-javascript-devel] RFS: node-yarnpkg

[Paolo Greppi]

Il 25/01/19 06:24, Pirate Praveen ha scritto:
> On വെ, ജനു 25, 2019 at 10:22 രാവിലെ, Paolo Greppi  
> wrote:
>> ...
> 
> E: yarnpkg: package-contains-ancient-file 
> usr/lib/nodejs/yarn/node_modules/npm-logical-tree/CHANGELOG.md 1970-01-01 
> (and some more)

tar xf ../node-yarnpkg_1.13.0.orig-npm-logical-tree.tar.gz
ls package -l
totale 28
-rw-r--r-- 1 paolog paolog 1222 gen  1  1970 CHANGELOG.md
-rw-r--r-- 1 paolog paolog 4919 gen  1  1970 index.js
-rw-r--r-- 1 paolog paolog  755 gen  1  1970 LICENSE.md
-rw-r--r-- 1 paolog paolog 1380 gen  1  1970 package.json
-rw-r--r-- 1 paolog paolog 4563 gen  1  1970 README.md

this is the only tarball that has this issue among the 14 that I have bundled 
...

and:

rm -rf package
wget https://registry.npmjs.org/npm-logical-tree/-/npm-logical-tree-1.2.1.tgz
tar xf npm-logical-tree-1.2.1.tgz
ls -l package
totale 28
-rw-r--r-- 1 paolog paolog 1222 gen  1  1970 CHANGELOG.md
-rw-r--r-- 1 paolog paolog 4919 gen  1  1970 index.js
-rw-r--r-- 1 paolog paolog  755 gen  1  1970 LICENSE.md
-rw-r--r-- 1 paolog paolog 1380 gen  1  1970 package.json
-rw-r--r-- 1 paolog paolog 4563 gen  1  1970 README.md

so it looks like an upstream issue

I wonder how we can fix this !

Paolo

Bug#920407: RFA: ropemode

[Arnaud Fontaine]

Package: wnpp
Severity: normal

I no longer use ropemacs nor have time  to maintain it so I would like someone
to take  over maintenance  of rope  and its  related packages  (namely pymacs,
ropemacs and ropemode) for which I have also filled RFAs.

Bug#916256: [pkg-go] Bug#916256: Bug#916256: gitlab-runner fails when it tries to pull docker image gitlab-runner-helper:11.2.0

[Dean Hamstead]

Im using hosted kubernetes (azure kubernetes in this case) which runs 
the actual docker machines all for me.


They are ubuntu it seems but they are entirely encapsulated as part of 
the service.


That said, this error would occur if the kubernetes cluster is external 
to the debian machine that runs the runner? (which is my scenario) as 
that docker instance running on the kubernetes node would not have that 
'local' image?


by manually setting the helper_image to something in the gitlab/ space - 
things work for me



On 25/1/19 12:16 am, Dmitry Smirnov wrote:

On Thursday, 24 January 2019 9:30:47 PM AEDT Dean Hamstead wrote:

In my case, i am using the kubernetes executor

That shouldn't matter as it failed in "executor_docker.go:166".

First it tries to load helper image from local file system:


ERRO[] Docker executor: prebuilt image helpers will be loaded from
/var/lib/gitlab-runner.


Then, in case helper image is not there, it falls back to pull from registry.
So once again, do you have a "/var/lib/gitlab-runner/gitlab-runner-
prebuilt.tar.xz" file?
Did you try to build helper image by "sudo dpkg-reconfigure gitlab-runner"?

If it fails to build a helper image, you would know what's the problem from
the error. Usually this happens when Docker daemon is not running when
gitlab-runner is installed...

Bug#920404: RFA: rope

[Arnaud Fontaine]

Package: wnpp
Severity: normal

I no longer use ropemacs nor have time  to maintain it so I would like someone
to take  over maintenance  of rope  and its  related packages  (namely pymacs,
ropemacs and ropemode) for which I have also filled RFAs.

Bug#920406: RFA: pymacs -- interface between Emacs Lisp and Python

[Arnaud Fontaine]

Package: wnpp
Severity: normal

I no longer use ropemacs nor have time  to maintain it so I would like someone
to take  over maintenance  of rope  and its  related packages  (namely pymacs,
ropemacs and ropemode) for which I have also filled RFAs.

Bug#920405: RFA: ropemacs

[Arnaud Fontaine]

Package: wnpp
Severity: normal

I no longer use ropemacs nor have time  to maintain it so I would like someone
to take  over maintenance  of rope  and its  related packages  (namely pymacs,
ropemacs and ropemode) for which I have also filled RFAs.

Bug#920403: libantlr3c: makefile error trapping and FTCBFS

[Helmut Grohne]

Source: libantlr3c
Version: 3.4+dfsg-2
Severity: serious
Justification: policy 4.6
Tags: patch

libantlr3c fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so is using
dh_auto_configure. That is sufficient for making libantlr3c cross
buildable.

While preparing the patch, I noticed that debian/rules is chaining build
command (configure and ln) with ";". Doing so is prohibited by Debian
policy section 4.6, because it can result in silent misbuilds.
Therefore, I bumped the severity to serious. 

The attached patch fixes both issues as they really affect the same
lines. Merging these issues felt simpler that filing two bugs with
conflicting patches.

Helmut
diff --minimal -Nru libantlr3c-3.4+dfsg/debian/changelog 
libantlr3c-3.4+dfsg/debian/changelog
--- libantlr3c-3.4+dfsg/debian/changelog2018-06-21 12:38:06.0 
+0200
+++ libantlr3c-3.4+dfsg/debian/changelog2019-01-25 06:33:12.0 
+0100
@@ -1,3 +1,10 @@
+libantlr3c (3.4+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use dh_auto_configure. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 25 Jan 2019 06:33:12 +0100
+
 libantlr3c (3.4+dfsg-2) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru libantlr3c-3.4+dfsg/debian/rules 
libantlr3c-3.4+dfsg/debian/rules
--- libantlr3c-3.4+dfsg/debian/rules2018-06-16 22:18:36.0 +0200
+++ libantlr3c-3.4+dfsg/debian/rules2019-01-25 06:33:10.0 +0100
@@ -16,22 +16,16 @@
 
 override_dh_auto_configure:
# Configure with ANTLR remote debugger enabled
-   mkdir build-dbg
-   ( cd build-dbg;   \
- ../configure $(CROSS) --prefix=/usr \
-   --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)\
+   dh_auto_configure --builddirectory=build-dbg --
--enable-debuginfo --disable-abiflags --enable-antlrdebug \
-   $(ENABLE_64BIT);  \
-   ln -s ../include )
+   $(ENABLE_64BIT)
+   ln -s ../include build-dbg/
 
# Configure with ANTLR remote debugger disabled
-   mkdir build-nodbg
-   ( cd build-nodbg;  \
- ../configure $(CROSS) --prefix=/usr  \
-   --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
+   dh_auto_configure --builddirectory=build-nodbg --
--enable-debuginfo --disable-abiflags --disable-antlrdebug \
-   $(ENABLE_64BIT);   \
- ln -s ../include )
+   $(ENABLE_64BIT)
+   ln -s ../include build-nodbg/
 
 override_dh_auto_build:
( cd build-dbg; $(MAKE) )

Bug#920402: RM: pyscript -- ROM; abandoned upstream

[Arnaud Fontaine]

Package: ftp.debian.org
Severity: normal

Hi,

I no longer use nor have time to take care of the package but for the
following reasons I'm requesting its removal rather than orphaning it:

  * No release for ~13 years and even then considered beta by its author.
  * Very low popcon.

Cheers,
Arnaud Fontaine

Bug#843021: [Pkg-javascript-devel] RFS: node-yarnpkg

[Pirate Praveen]

On വെ, ജനു 25, 2019 at 10:22 രാവിലെ, Paolo Greppi 
 wrote:

Hi, the package node-yarnpkg is ready since a couple of weeks:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-January/030472.html
I haven't received any feedback, but from my testing it seems to work 
in sid and buster.


Please someone sponsor the upload to unstable:
https://salsa.debian.org/js-team/node-yarnpkg



E: yarnpkg: package-contains-ancient-file 
usr/lib/nodejs/yarn/node_modules/npm-logical-tree/CHANGELOG.md 
1970-01-01 (and some more)



Paolo





--
Pkg-javascript-devel mailing list
pkg-javascript-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#920401: midori: SEGFAULT on i686 when setting preferences

[Ariela Wenner]

Package: midori
Version: 7.0-1
Severity: important


Midori seems to crash consistently on i686.

Steps to reproduce:
* Open midori and go to the preferences window
* Switch to the network tab, select http proxy and try to type
  something on the URI field
* Program crashes at this point, and will keep crashing if opened
  again, after attempting to open the preferences window

Backtrace attached.

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

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

Versions of packages midori depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-5
ii  libcairo-gobject21.16.0-2
ii  libcairo21.16.0-2
ii  libgck-1-0   3.28.0-4
ii  libgcr-base-3-1  3.28.0-4
ii  libgcr-ui-3-13.28.0-4
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libgirepository-1.0-11.58.3-2
ii  libglib2.0-0 2.58.2-3
ii  libgtk-3-0   3.24.4-1
ii  libjavascriptcoregtk-4.0-18  2.22.5-1
ii  libp11-kit0  0.23.14-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpeas-1.0-01.22.0-4
ii  libsoup2.4-1 2.64.2-2
ii  libsqlite3-0 3.26.0+fossilbc891ac6b-1
ii  libwebkit2gtk-4.0-37 2.22.5-1

Versions of packages midori recommends:
ii  gnome-icon-theme  3.12.0-3
ii  gnome-keyring 3.28.2-2

midori suggests no packages.

-- no debconf information

[New LWP 16959]
[New LWP 16972]
[New LWP 16974]
[New LWP 16971]
[New LWP 16977]
[New LWP 16973]
[New LWP 16976]
[New LWP 16975]
[New LWP 16995]
[New LWP 17003]
[New LWP 17002]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `midori'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
97  ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S: No such file or 
directory.
[Current thread is 1 (Thread 0xaefc1000 (LWP 16959))]

Thread 11 (Thread 0xa71ffb40 (LWP 17002)):
#0  0xb7f50d21 in __kernel_vsyscall () at 
/build/linux-CyNnMN/linux-4.19.12/arch/x86/entry/vdso/vdso32/system_call.S:72
#1  0xb2b935db in __GI___poll (timeout=-1, nfds=2, fds=0xa8302bf0) at 
../sysdeps/unix/sysv/linux/poll.c:29
resultvar = 
resultvar = 
sc_cancel_oldtype = 0
sc_ret = 
sc_ret = 
#2  0xb2b935db in __GI___poll (fds=0xa8302bf0, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:26
#3  0xb79a4410 in poll (__timeout=-1, __nfds=2, __fds=0xa8302bf0) at 
/usr/include/i386-linux-gnu/bits/poll2.h:46
#4  0xb79a4410 in g_poll (fds=0xa8302bf0, nfds=2, timeout=-1) at 
../../../glib/gpoll.c:124
#5  0xb7994f73 in g_main_context_poll (priority=, n_fds=2, 
fds=0xa8302bf0, timeout=, context=0xa8300b80)
at ../../../glib/gmain.c:4221
ret = 
errsv = 
poll_func = 0xb79a43f0 
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 
fds = 0xa8302bf0
#6  0xb7994f73 in g_main_context_iterate (context=0xa8300b80, 
block=block@entry=1, dispatch=dispatch@entry=1, self=)
at ../../../glib/gmain.c:3915
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 
fds = 0xa8302bf0
#7  0xb79953a9 in g_main_loop_run (loop=0xa8301ef0) at 
../../../glib/gmain.c:4116
__FUNCTION__ = "g_main_loop_run"
#8  0xb46c73b1 in WTF::RunLoop::run() () at 
./Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#9  0xb46c5dcd in operator() () at 
./Source/WTF/wtf/generic/WorkQueueGeneric.cpp:43
#10 0xb46c5dcd in call() () at ./Source/WTF/wtf/Function.h:101
#11 0xb469b0d8 in WTF::Function::operator()() const () at 
./Source/WTF/wtf/Function.h:56
#12 0xb469b0d8 in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at 
./Source/WTF/wtf/Threading.cpp:136
#13 0xb46c4fa8 in wtfThreadEntryPoint() () at 
./Source/WTF/wtf/ThreadingPthreads.cpp:227
#14 0xb2983fd2 in start_thread (arg=) at pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1298550784, -1491076288, 
-1298550784, -1491079256, 1142221547, 1270227648}, mask_was_saved = 0}}, priv = 
{pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 
0}}}
not_first_call = 0
#15 0xb2b9e146 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108

Thread 10 (Thread 0xa69feb40 (LWP 17003)):
#0  0xb7f50d21 in __kernel_vsyscall () at 

Bug#920400: linssid FTCBFS: upstream linssid-app.pro hard codes build architecture compiler

[Helmut Grohne]

Source: linssid
Version: 3.6-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

linssid fails to cross build from source, because
linssid/linssid-app.pro hard codes the build architecture compiler for
no good reason. After removing the relevant assignments and thus relying
on qmake/debhelper to figure out, linssid cross builds successfully.
Please consider applying the attached patch.

Helmut
--- linssid-3.6.orig/linssid-app/linssid-app.pro
+++ linssid-3.6/linssid-app/linssid-app.pro
@@ -15,8 +15,6 @@
 MOC_DIR = 
 RCC_DIR = 
 UI_DIR = 
-QMAKE_CC = gcc
-QMAKE_CXX = g++
 DEFINES += 
 INCLUDEPATH += /usr/include/boost
 INCLUDEPATH += /usr/include/qt5

Bug#920399: RM: nethack-el -- ROM; abandoned upstream

[Arnaud Fontaine]

Package: ftp.debian.org
Severity: normal

I no longer use nor have time to take care of the package but for the
following reasons I'm requesting its removal rather than orphaning it:

  * This lisp port has been dead upstream for ~12 years.
  * Not tested with recent nethack version and its maintainer no longer wish
to maintain the patch (#909026).
  * Low popcon.

Cheers,
Arnaud Fontaine

Bug#920398: RM: twill -- ROM; abandoned upstream

[Arnaud Fontaine]

Package: ftp.debian.org
Severity: normal

I no longer use nor have time to take care of the package but for the
following reasons I'm requesting its removal rather than orphaning it:

  * There has been no upstream release for 5 years.
  * Upstream website is no longer available.
  * It ships a (very old) modified copy of Python mechanize module.
  * Popcon is very low.

Cheers,
Arnaud Fontaine

Bug#843021: RFS: node-yarnpkg

[Paolo Greppi]

Hi, the package node-yarnpkg is ready since a couple of weeks:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-January/030472.html
I haven't received any feedback, but from my testing it seems to work in sid 
and buster.

Please someone sponsor the upload to unstable:
https://salsa.debian.org/js-team/node-yarnpkg

Paolo

Bug#915583: debian-policy: More attractive sphinx theme, please

[Sean Whitton]

Hello,

On Thu 24 Jan 2019 at 05:08PM +01, Chris Lamb wrote:

> Sean Whitton wrote:
>
>> >  Maybe more eye-candy theme  (see https://sphinx-themes.org/) is good for
>> >  policy-doc and other debian docs [..]
>>
>> Yup.  We put out a call for this as soon as we switched to Sphinx[1] and
>> it was included in Debian Project News.[2]
>
> Did you hear anything on this?
>
> (+1 for a "Debian" Sphinx theme. I am sure there are many other
> tools that would benefit from such a thing.)

Nothing yet.

Since things like dev-ref will probably  switch to Sphinx to someday,
it would indeed be really cool to have a Debian theme.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#919727:

[Torsten Rohlfing]

Hello again -

So I don't know how you guys pull CMTK sources, but I just published a new
release with the DCMTK compile errors fixed.

Download here:

https://www.nitrc.org/frs/download.php/11132/CMTK-3.3.1p1-Source.tar.gz

Or from SVN at NITRC via

https://nitrc.org/svn/cmtk/releases/3.3.1p1

Best,
  Torsten

Bug#908162: Is cryptomount line missing in grub.cfg?

[Gerardo Malazdrewicz]

Hello,
  in these circumstances, I needed to add a

 cryptomount -u 

  line in top of /boot/efi/EFI/debian/grub.cfg for grub to be able to
read the "real" configuration in the encrypted filesystem.

Thanks,
Gerardo

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Akira TAGOH]

On Thu, Jan 24, 2019 at 9:43 PM Alexander Larsson
 wrote:
>
> On Thu, Jan 24, 2019 at 1:18 PM Akira TAGOH  wrote:
> >
> > On Thu, Jan 24, 2019 at 8:55 PM Alexander Larsson
> >  wrote:
> > > I agree that cache path is wrong as we have something else by that name.
> > >
> > > host-path kinda hardcodes the sandbox case for rewriting though. Maybe
> > > "remapped-path"?
> >
> > "remap" looks redundant to the element name. simply "to" or "as" as
> > you proposed that earlier?
>
> as-path=... ?

That sounds good to me.

-- 
Akira TAGOH

Bug#920397: shutter: "Keyboard could not be grabbed" when taking fullscreen screenshot

[Ernesto Alfonso]

Package: shutter
Version: 0.93.1-1.3
Severity: important
Tags: upstream

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation? "shutter -e -f -o  -n -s"
   * What exactly did you do (or not do) that was effective (or
 ineffective)? removing the "-f" flag works for non-full-screen screenshots
   * What was the outcome of this action? an error: "Keyboard could not be 
grabbed"
   * What outcome did you expect instead? no error

A similar or the same bug was reported here in 2012:

https://bugs.launchpad.net/shutter/+bug/1021996

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 shutter depends on:
ii  imagemagick8:6.9.7.4+dfsg-11+deb9u6
ii  imagemagick-6.q16 [imagemagick]8:6.9.7.4+dfsg-11+deb9u6
ii  libfile-basedir-perl   0.07-1
ii  libfile-copy-recursive-perl0.38-1
ii  libfile-which-perl 1.21-1
ii  libglib-perl   3:1.324-1
ii  libgnome2-canvas-perl  1.002-4+b1
ii  libgnome2-gconf-perl   1.044-6+b1
ii  libgnome2-perl 1.046-3+b1
ii  libgnome2-vfs-perl 1.082-1+b3
ii  libgnome2-wnck-perl0.16-3+b3
ii  libgtk2-imageview-perl 0.05-2+b3
ii  libgtk2-perl   2:1.2499-1
ii  libgtk2-unique-perl0.05-2+b3
ii  libimage-magick-perl [perlmagick]  8:6.9.7.4+dfsg-11+deb9u6
ii  libjson-perl   2.90-1
ii  libjson-xs-perl3.030-1
ii  liblocale-gettext-perl 1.07-3+b1
ii  libnet-dbus-perl   1.1.0-4+b1
ii  libnet-dropbox-api-perl1.9-1
ii  libpath-class-perl 0.37-1
ii  libproc-processtable-perl  0.53-2
ii  libproc-simple-perl1.32-1
ii  librsvg2-common2.40.16-1+b1
ii  libsort-naturally-perl 1.03-1
ii  libwww-mechanize-perl  1.83-1
ii  libwww-perl6.15-1
ii  libx11-protocol-other-perl 29-2
ii  libx11-protocol-perl   0.56-7
ii  libxml-simple-perl 2.22-1
ii  perlmagick 8:6.9.7.4+dfsg-11+deb9u6
ii  procps 2:3.3.12-3+deb9u1
ii  xdg-utils  1.1.1-1+deb9u1

Versions of packages shutter recommends:
ii  libgoo-canvas-perl 0.06-2+b3
ii  libgtk2-appindicator-perl  0.15-1+b4

Versions of packages shutter suggests:
pn  gnome-web-photo 
pn  libimage-exiftool-perl  
pn  libnet-dbus-glib-perl   
pn  nautilus-sendto 

-- no debconf information

Bug#919988: wrong license

[Aaron M. Ucko]

Thorsten Alteholz  writes:

> please change the license of src/samurui/treegoo.* from GPL to LGPL in
> your debian/copyright.

Done, thanks!  (Better than getting it wrong in the other direction, I
suppose, but very much worth fixing nonetheless.)

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

Bug#920396: gnome-control-center: Configuring displays crashes to login

[Hunter Wardlaw]

Package: gnome-control-center
Version: 1:3.30.2-3
Severity: normal
File: /usr/bin/gnome-control-center

Dear Maintainer,

I am experiencing a reproducable crash (for me at least) where I crash to
the login manager when configuring my displays using the gnome control
center. I have experienced crashing while enabling and disabling a
monitor, and when switching my primary monitor. The following always
appears in /var/log/syslog following these crashes:

Jan 15 19:22:22 topbox at-spi-bus-launcher[21812]: XIO:  fatal IO error 11
(Resource temporarily unavailable) on X server ":1024"
Jan 15 19:22:22 topbox at-spi-bus-launcher[21812]:   after 21 requests
(21 known processed) with 0 events remaining.
Jan 15 19:22:22 topbox gnome-shell[21762]: Connection to xwayland lost
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.A11ySettings.desktop' killed
by signal 15
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.Datetime.desktop' killed by
signal 15
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.Housekeeping.desktop' killed
by signal 15
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.Mouse.desktop' killed by
signal 15
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.PrintNotifications.desktop'
killed by signal 15
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.Rfkill.desktop' killed by
signal 15
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.ScreensaverProxy.desktop'
killed by signal 15
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.Sharing.desktop' killed by
signal 15
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.Smartcard.desktop' killed by
signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.A11ySettings.desktop' killed by signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.Datetime.desktop' killed by signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.Housekeeping.desktop' killed by signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.Mouse.desktop' killed by signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.PrintNotifications.desktop' killed by signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.Rfkill.desktop' killed by signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.ScreensaverProxy.desktop' killed by signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.Sharing.desktop' killed by signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.Smartcard.desktop' killed by signal 15
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.Clipboard.desktop' killed by
signal 15
Jan 15 19:22:22 topbox gnome-session[21754]: gnome-session-binary[21754]:
WARNING: Application 'org.gnome.SettingsDaemon.Sound.desktop' killed by
signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.Clipboard.desktop' killed by signal 15
Jan 15 19:22:22 topbox gnome-session-binary[21754]: WARNING: Application
'org.gnome.SettingsDaemon.Sound.desktop' killed by signal 15
Jan 15 19:22:22 topbox gsd-color[0]: failed to connect to device:
Failed to connect to missing device
/org/freedesktop/ColorManager/devices/xrandr_Dell_Inc__DELL_U2312HM_2GFKN337252L_Debian_gdm_117
Jan 15 19:22:22 topbox gsd-color[0]: failed to connect to device:
Failed to connect to missing device
/org/freedesktop/ColorManager/devices/xrandr_Acer_Technologies_S220HQL_LTK0R0292400_Debian_gdm_117
Jan 15 19:22:22 topbox gsd-color[0]: failed to connect to device:
Failed to connect to missing device
/org/freedesktop/ColorManager/devices/xrandr_Funai_Electric_Co___Ltd__LCD_TV_Debian_gdm_117
Jan 15 19:22:22 topbox systemd[1]: session-c3.scope: Succeeded.
Jan 15 19:22:22 topbox gdm3: Child process -21750 was already dead.

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

Kernel: Linux 

Bug#909644: docker.io: dockerd warning: failed to retrieve docker-runc version: unknown output format: runc version spec: 1.0.1

[Arnaud Rebillout]

On Fri, 25 Jan 2019 08:20:03 +0700 Arnaud Rebillout
 wrote:
> On Thu, 24 Jan 2019 18:43:18 +0100 Marcel Partap  wrote:
>
> > reassign runc
> >
> > OK coreos fixed this by building runc with a commit hash:
> >
>
https://github.com/coreos/coreos-overlay/pull/2428/commits/a0294fbf2caf5f1a04651a22bb67357969f5831f
> >
> > Isn't this is quite a reasonable fix?
> >
>

Hmm, and on the other hand, the commit you refer to is not really about
patching runc, it's just about making the commit id available at compile
time. It's also something reasonable. But I still believe it's easier to
just patch docker.

Bug#888782: fp-compiler-3.0.4: fpselect segfaults on arm64

[peter green]

Tags 888782 +patch
Thanks

Freepascal upstream noted that this bug was not present in trunk, but didn't 
research when/how it was fixed, so I decided to do some digging in the source.

It turns out that the "generic syscalls" implementation of fpSelect (used for aarch64) 
translates the timeout parameter from a timeval (seconds and microseconds) to a timespec (seconds 
and nanoseconds) before passing it to the "pselect6" system call.

Unfortunately the version of the code in Debian 3.0.4 fails to check if the 
timeout is nil, dereferences the nil pointer and segfaults.

Using the "blame" tool on an unofficial github mirror of the freepascal source 
found the commit fixing the issue.

https://github.com/graemeg/freepascal/commit/e8335a145bfe3af52eed8d0d74ae3a461bbe9d1e

I turned the commit into a quilt patch, added it to the quilt series, built the 
compiler and was able to confirm it fixed the issue.

Debdiff is attatched, if noone else gets round to it first I'll probably commit 
and upload within the next week or so.

diff -Nru fpc-3.0.4+dfsg/debian/changelog fpc-3.0.4+dfsg/debian/changelog
--- fpc-3.0.4+dfsg/debian/changelog 2019-01-16 09:14:10.0 +
+++ fpc-3.0.4+dfsg/debian/changelog 2019-01-24 23:27:02.0 +
@@ -1,3 +1,10 @@
+fpc (3.0.4+dfsg-22) UNRELEASED; urgency=medium
+
+  * debian/patches/arm64-select.patch
+- Fix fpSelect with nil timestamp on aarch64 (closes: 888782)
+
+ -- Peter Michael Green   Thu, 24 Jan 2019 23:27:02 +
+
 fpc (3.0.4+dfsg-21) unstable; urgency=medium
 
   [ Paul Gevers ]
diff -Nru fpc-3.0.4+dfsg/debian/patches/arm64-select.patch 
fpc-3.0.4+dfsg/debian/patches/arm64-select.patch
--- fpc-3.0.4+dfsg/debian/patches/arm64-select.patch1970-01-01 
00:00:00.0 +
+++ fpc-3.0.4+dfsg/debian/patches/arm64-select.patch2019-01-24 
23:26:42.0 +
@@ -0,0 +1,37 @@
+This patch is based on the commit detailed below with paths adjusted
+to match the Debian fpc package --plugwash
+commit e8335a145bfe3af52eed8d0d74ae3a461bbe9d1e
+Author: Marco van de Voort 
+Date:   Wed Mar 30 19:21:05 2016 +
+
+ * fix timespec=nil for -dgeneric_linux_syscalls (aarch64) case.
+
+
+git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@33392 
3ad0048d-3df7-0310-abae-a5850022a9f2
+
+diff --git a/rtl/linux/bunxsysc.inc b/rtl/linux/bunxsysc.inc
+index c8d7849672..c6d18be4e9 100644
+--- a/fpcsrc/rtl/linux/bunxsysc.inc
 b/fpcsrc/rtl/linux/bunxsysc.inc
+@@ -463,12 +463,18 @@ Function 
fpSelect(N:cint;readfds,writefds,exceptfds:pfdSet;TimeOut:PTimeVal):cin
+ {$if defined(generic_linux_syscalls)}
+ 
+ var ts : timespec;
++pts : PTimeSpec;
+ begin
+-  ts.tv_sec := timeout^.tv_sec;
+-  ts.tv_nsec := timeout^.tv_usec * 1000;
++  pts:=nil;
++  if assigned(timeout) then
++begin
++  pts:=@ts;
++  ts.tv_sec := timeout^.tv_sec;
++  ts.tv_nsec := timeout^.tv_usec * 1000;
++end;
+   fpSelect:=do_syscall(syscall_nr_pselect6,n,
+tsysparam(readfds),tsysparam(writefds),
+-   tsysparam(exceptfds),tsysparam(@ts),0);
++   tsysparam(exceptfds),tsysparam(pts),0);
+ end;
+ 
+ {$else}
diff -Nru fpc-3.0.4+dfsg/debian/patches/series 
fpc-3.0.4+dfsg/debian/patches/series
--- fpc-3.0.4+dfsg/debian/patches/series2019-01-16 08:33:37.0 
+
+++ fpc-3.0.4+dfsg/debian/patches/series2019-01-24 23:26:55.0 
+
@@ -34,3 +34,4 @@
 fpcmake-m68k.patch
 ncurses6.patch
 fpc-r38400.patch
+arm64-select.patch

Bug#909644: docker.io: dockerd warning: failed to retrieve docker-runc version: unknown output format: runc version spec: 1.0.1

[Arnaud Rebillout]

On Thu, 24 Jan 2019 18:43:18 +0100 Marcel Partap  wrote:

> reassign runc
>
> OK coreos fixed this by building runc with a commit hash:
>
https://github.com/coreos/coreos-overlay/pull/2428/commits/a0294fbf2caf5f1a04651a22bb67357969f5831f
>
> Isn't this is quite a reasonable fix?
>

Runc is doing the right thing, it's free to report its version the way
it wants. There's no reason to patch it because one particular program
expects a different output. Maybe there are other programs out there
parsing the runc version string, and maybe you break them by patching
runc this way.

On the other end, patching docker is trivial, it's just one line to comment.

Bug#920219: [Pkg-emacsen-addons] Bug#920219: Bug#920219: elpa-company: Post install script failing

[David Bremner]

Control: tag -1 -moreinfo -unreproducible +confirmed

Erich Beyer  writes:

> 1) No, it is the same information that appears in the "dpkg --configure -a"
> output in my original email. I will duplicate it below.
>
> 2) I tried:
> A)
>  $ sudo emacs ...
> B)
>  $ sudo -s
>  # emacs ...
> C)
>  $ sudo -s
>  # su
>  # emacs ...
>
> Iteration C produced the same output as you. I have env_keep in my
> /etc/sudoers. I think emacs in the script is seaching $HOME/.emacs.d/ and my
> init.el is causing it to add $HOME/.emacs.d/elpa to the load-path. For
> iteration
> A and B, $HOME="/home/myusername" and no output was produced.
>
>  $ sudo sh -c 'echo $HOME'
>  /home/myusername
>

OK, I understand the problem now, thanks for experimenting.

Indeed the problem is your setting of $HOME for the root user (and emacs
using $HOME).  I'll see about making the maintainer scripts ignore the
value of $HOME.

Bug#920395: ITP: difference -- text diffing tool

[Robin Krahl]

Package: wnpp
Severity: wishlist
Owner: Robin Krahl 

* Package name: difference
  Version : 2.0.0
  Upstream Author : Johann Hofmann
* URL : https://github.com/johannhof/difference.rs
* License : MIT
  Programming Lang: Rust
  Description : text diffing tool

difference compares two strings and prints a colorful visual
representation of the diff.

I intend to package difference as part of the Rust packaging team.


signature.asc
Description: PGP signature

Bug#915426: git breaks git-remote-hg autopkgtest

[Jonathan McCrohan]

Jeremy, Jonas,

Please accept my apologies for the tardy response on this. I've been afk
for a couple of months due to life events.

On Wed, Jan 23, 2019 at 07:28:55PM -0500, Jeremy Bicha wrote:
> Could you please reply to Jonas' message? The deadline for
> git-remote-hg to re-enter Testing to be in this year's Debian 10
> "Buster" release is February 12.
> 
> > Wed, 02 Jan 2019 13:50:54 +0100
> > I can do yet another NMU to fix this, but am hesitating as I worry if
> > that will masquerade a lack of responsive maintenance.
> >
> > Please tell if it is sensible that I take over maintenance of this
> > package, or join as co-maintainer, or however is appreciated.

Thanks for the previous NMU. I am happy to work on fixing up the FTBFS, but
because I am not a DD, I would need a sponsor to upload for me.

Given the circumstances, and the impending freeze, it might make more
sense for you to take over as maintainer if you are willing to do so.

Let me know what you think.

Regards,
Jon


signature.asc
Description: PGP signature

Bug#920394: Does debian-spamd need real shell?

[Elliott Mitchell]

Package: spamassassin
Version: 3.4.2-1~deb9u1

The debian-spamd user is created with a shell of /bin/sh, and doesn't
appear to need a valid shell.  Unless there is a very good reason,
/bin/false or /usr/sbin/nologin should be used as the shell.  This may
not be a huge security hole, but is very poor practice.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 24, 2019, at 17:01, Jennifer Bryan  wrote:
> 
> Thanks for the update and fixes, Evan!
> 
> What sort of timeframe do you have in mind re: your official release?
> 
> That affects how I think about timing a readxl release. I don't do them 
> lightly but also want to get the fixes that address the CVEs into readxl 
> sooner rather than later.

I’m aiming to have a release in the next two weeks. Down to the last 4-5 issues 
unearthed by OSS-Fuzz but I will have limited computer access next week.

Evan

> 
> -- Jenny
> 
>> On Thu, Jan 24, 2019 at 1:36 PM Evan Miller  wrote:
>> 
>>> On Jan 23, 2019, at 01:16, Evan Miller  wrote:
>>> 
>>> #34 and #35 have returned from the dead on GitHub. I’ll take a closer look 
>>> later this week.
>>> 
>>> Evan
>> 
>> 
>> OK — I can confirm that all of the reported libxls bugs are fixed. I have 
>> successfully integrated libxls into OSS-Fuzz, and have added the 
>> researcher’s test files to the fuzzing corpus, so that this and related 
>> issues should be caught by the address sanitizer in the future.
>> 
>> OSS-Fuzz has turned up a number of other issues. I will plan to do a release 
>> when they are all addressed.
>> 
>> Evan
>> 
>>> 
 On Jan 15, 2019, at 14:12, Moritz Muehlenhoff  wrote:
 
> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote:
> 
> Hi Evan,
> 
> On 15 January 2019 at 11:18, Evan Miller wrote:
> | 
> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff  wrote:
> | > 
> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared 
> from GitHub. I don’t know if the original reporter intended to close 
> them, or what.
> | >> 
> | >> I have an email copy of #34 but do not have access to the PoC files. 
> So without the cooperation of the reporter (Zhao Liang, Huawei Weiran 
> Labs) my ability to research will be limited.
> | > 
> | > That's really strange, do you have the mail address of Zhao, could 
> you ask him what happened?
> | 
> | His address may be leon.zha...@gmail.com - I’ll try it. His GitHub 
> profile is now a 404.
> | 
> | > 
> | > MITRE doesn't archive security content per se, they only deal with 
> the organisation and assignment
> | > of numbers. The Internet Archive's Wayback machine also hasn't 
> archived the Github pages.
> | > 
> | > Cheers,
> | >Moritz
> | 
> | 
> | Here are the Google caches of #34 and #35:
> | 
> | 
> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+=1=en=clnk=us=safari
> | 
> | 
> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+=1=en=clnk=us=safari
> | 
> | The PoC links are dead.
> | 
> | Looking at the backtraces and the commit fixing #36 and #37 
> (https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e)
>  it is my belief that issues #34 and #35 are NOT fixed.
> | 
> | I’ll look into them soon.
> 
> You're awesome!  Much appreciated.
> 
> Moritz: Do you expect the CVE to puliverize too, or will it remain active 
> and
> open, but "simply" without any hard (public) evidence backing it?
 
 No, they stick around, it sometimes happens that references vanish, e.g. 
 then hosting sites
 go down (think of berlios or similar)
 
 Cheers,
Moritz
>>> 
>> 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 24, 2019, at 19:10, Dirk Eddelbuettel  wrote:
> 
> 
> On 24 January 2019 at 16:36, Evan Miller wrote:
> | 
> | > On Jan 23, 2019, at 01:16, Evan Miller  wrote:
> | > 
> | > #34 and #35 have returned from the dead on GitHub. I’ll take a closer 
> look later this week.
> | > 
> | > Evan
> | 
> | 
> | OK — I can confirm that all of the reported libxls bugs are fixed.
> 
> As in: in the current libxls GH version?  I can make a patched Debian
> release of that.

Yes, they are fixed in master on GitHub. Note that there are quite a few 
changes since 1.4 – I can’t promise that master has ABI compatibility with the 
last official 1.4 release. But if you compile the new sources using the old 
headers (or diff and merge manually) I don’t think there will be an issue on 
that front.

Evan

> 
> | I have successfully integrated libxls into OSS-Fuzz, and have added the 
> researcher’s test files to the fuzzing corpus, so that this and related 
> issues should be caught by the address sanitizer in the future.
> | 
> | OSS-Fuzz has turned up a number of other issues. I will plan to do a 
> release when they are all addressed.
> 
> That is awesome.
> 
> Thank you,  Dirk
> 
> | Evan
> | 
> | > 
> | >> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff  > wrote:
> | >> 
> | >> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote:
> | >>> 
> | >>> Hi Evan,
> | >>> 
> | >>> On 15 January 2019 at 11:18, Evan Miller wrote:
> | >>> | 
> | >>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff  > wrote:
> | >>> | > 
> | >>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
> | >>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have 
> disappeared from GitHub. I don’t know if the original reporter intended to 
> close them, or what.
> | >>> | >> 
> | >>> | >> I have an email copy of #34 but do not have access to the PoC 
> files. So without the cooperation of the reporter (Zhao Liang, Huawei Weiran 
> Labs) my ability to research will be limited.
> | >>> | > 
> | >>> | > That's really strange, do you have the mail address of Zhao, could 
> you ask him what happened?
> | >>> | 
> | >>> | His address may be leon.zha...@gmail.com 
>  - I’ll try it. His GitHub profile is now a 404.
> | >>> | 
> | >>> | > 
> | >>> | > MITRE doesn't archive security content per se, they only deal with 
> the organisation and assignment
> | >>> | > of numbers. The Internet Archive's Wayback machine also hasn't 
> archived the Github pages.
> | >>> | > 
> | >>> | > Cheers,
> | >>> | >Moritz
> | >>> | 
> | >>> | 
> | >>> | Here are the Google caches of #34 and #35:
> | >>> | 
> | >>> | 
> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+=1=en=clnk=us=safari
>  
> 
> | >>> | 
> | >>> | 
> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+=1=en=clnk=us=safari
>  
> 
> | >>> | 
> | >>> | The PoC links are dead.
> | >>> | 
> | >>> | Looking at the backtraces and the commit fixing #36 and #37 
> (https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e
>  
> )
>  it is my belief that issues #34 and #35 are NOT fixed.
> | >>> | 
> | >>> | I’ll look into them soon.
> | >>> 
> | >>> You're awesome!  Much appreciated.
> | >>> 
> | >>> Moritz: Do you expect the CVE to puliverize too, or will it remain 
> active and
> | >>> open, but "simply" without any hard (public) evidence backing it?
> | >> 
> | >> No, they stick around, it sometimes happens that references vanish, e.g. 
> then hosting sites
> | >> go down (think of berlios or similar)
> | >> 
> | >> Cheers,
> | >>Moritz
> | > 
> | 
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#920393: lmms: Find Wine 4 headers

[Javier Serrano Polo]

Source: lmms
Version: 1.1.3-8
Severity: wishlist
Tags: patch

Wine headers' location has changed in version 4.

This patch fixes the build for i386.Description: Find Wine 4 headers
 Wine headers' location has changed in version 4.
 .
 Fixed upstream in 1.2.0.
Author: Javier Serrano Polo 

Index: lmms-1.1.3/cmake/modules/FindWine.cmake
===
--- lmms-1.1.3.orig/cmake/modules/FindWine.cmake
+++ lmms-1.1.3/cmake/modules/FindWine.cmake
@@ -7,7 +7,7 @@
 #  WINE_DEFINITIONS - Compiler switches required for using wine
 #
 
-FIND_PATH(WINE_INCLUDE_DIR windows/windows.h PATH_SUFFIXES wine)
+FIND_PATH(WINE_INCLUDE_DIR windows/windows.h PATH_SUFFIXES wine wine/wine)
 FIND_LIBRARY(WINE_LIBRARY NAMES wine PATH_SUFFIXES wine)
 FIND_PROGRAM(WINE_CXX NAMES wineg++)
 


smime.p7s
Description: S/MIME cryptographic signature

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

[NIIBE Yutaka]

Hello,

I have been chasing the bug in gpg-agent, pinentry, libscret, and
gnome-keyring.  But, I forgot to consider about a simple problem of
data.  Sorry, I should have considered that, in the first place.

The exact cause would be there is an empty cache remained in
gnome-keyring-daemon.  In my case, it is under:

~/.local/share/keyrings/

I don't know the reason why it was created, but it makes sence to
remove the entry... to see if it's working well again. 

Attached is a Python script (I name it test_clear.py) to clear the cache
entry (your specific keygrip is hard-coded).  You need python3-gi
package (and ignoring warning about version specification).


Here is an example session of mine.
==
$ python3 test_clear.py 
test_clear.py:1: PyGIWarning: Secret was imported without specifying a version 
first. Use gi.require_version('Secret', '1') before import to ensure that the 
right version gets loaded.
  from gi.repository import Secret
False
==

In your case, it prints out "True".  After clearing the entry, it should
work again if this is the case.



While gpg-agent supports clearing cache entry for normal and user
usages (by CLEAR_PASSPHRASE command), currently, it doesn't support 
SSH usage.  I just created a task to request this feature.

https://dev.gnupg.org/T4340

-- 
from gi.repository import Secret

THE_KEYGRIP="s/A337DE390143074C6DBFEA64224359B9859B02FC"

the_schema = Secret.Schema.new("org.gnupg.Passphrase",
Secret.SchemaFlags.NONE,
{
"stored-by": Secret.SchemaAttributeType.STRING,
	"keygrip"  : Secret.SchemaAttributeType.STRING,
}
)

attributes = {
"stored-by" : "GnuPG Pinentry",
"keygrip"   : THE_KEYGRIP,
}

removed = Secret.password_clear_sync(the_schema, attributes, None)
print(removed)

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

On 24 January 2019 at 16:36, Evan Miller wrote:
| 
| > On Jan 23, 2019, at 01:16, Evan Miller  wrote:
| > 
| > #34 and #35 have returned from the dead on GitHub. I’ll take a closer look 
later this week.
| > 
| > Evan
| 
| 
| OK — I can confirm that all of the reported libxls bugs are fixed.

As in: in the current libxls GH version?  I can make a patched Debian
release of that.

| I have successfully integrated libxls into OSS-Fuzz, and have added the 
researcher’s test files to the fuzzing corpus, so that this and related issues 
should be caught by the address sanitizer in the future.
| 
| OSS-Fuzz has turned up a number of other issues. I will plan to do a release 
when they are all addressed.

That is awesome.

Thank you,  Dirk
 
| Evan
| 
| > 
| >> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff mailto:j...@inutil.org>> wrote:
| >> 
| >> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote:
| >>> 
| >>> Hi Evan,
| >>> 
| >>> On 15 January 2019 at 11:18, Evan Miller wrote:
| >>> | 
| >>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff mailto:j...@inutil.org>> wrote:
| >>> | > 
| >>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
| >>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared 
from GitHub. I don’t know if the original reporter intended to close them, or 
what.
| >>> | >> 
| >>> | >> I have an email copy of #34 but do not have access to the PoC files. 
So without the cooperation of the reporter (Zhao Liang, Huawei Weiran Labs) my 
ability to research will be limited.
| >>> | > 
| >>> | > That's really strange, do you have the mail address of Zhao, could 
you ask him what happened?
| >>> | 
| >>> | His address may be leon.zha...@gmail.com  
- I’ll try it. His GitHub profile is now a 404.
| >>> | 
| >>> | > 
| >>> | > MITRE doesn't archive security content per se, they only deal with 
the organisation and assignment
| >>> | > of numbers. The Internet Archive's Wayback machine also hasn't 
archived the Github pages.
| >>> | > 
| >>> | > Cheers,
| >>> | >Moritz
| >>> | 
| >>> | 
| >>> | Here are the Google caches of #34 and #35:
| >>> | 
| >>> | 
https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+=1=en=clnk=us=safari
 

| >>> | 
| >>> | 
https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+=1=en=clnk=us=safari
 

| >>> | 
| >>> | The PoC links are dead.
| >>> | 
| >>> | Looking at the backtraces and the commit fixing #36 and #37 
(https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e
 
)
 it is my belief that issues #34 and #35 are NOT fixed.
| >>> | 
| >>> | I’ll look into them soon.
| >>> 
| >>> You're awesome!  Much appreciated.
| >>> 
| >>> Moritz: Do you expect the CVE to puliverize too, or will it remain active 
and
| >>> open, but "simply" without any hard (public) evidence backing it?
| >> 
| >> No, they stick around, it sometimes happens that references vanish, e.g. 
then hosting sites
| >> go down (think of berlios or similar)
| >> 
| >> Cheers,
| >>Moritz
| > 
| 

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

Bug#920392: ITP: rusty-tags -- generate tags for source code navigation for a cargo project

[Robin Krahl]

Package: wnpp
Severity: wishlist
Owner: Robin Krahl 

* Package name: rusty-tags
  Version : 3.3.0
  Upstream Author : Daniel Trstenjak
* URL : https://github.com/dan-t/rusty-tags
* License : BSD-3-Clause
  Programming Lang: Rust
  Description : generate tags for source code navigation for a cargo project

rusty-tags is a command-line tool that creates tags for source code
navigation using ctags for a cargo project, all of its direct and
indirect dependencies and the Rust standard library.

I intend to package rusty-tags as part of the Rust packaging team.


signature.asc
Description: PGP signature

Bug#920391: bugs.debian.org: Boot fails without acpi=off on HP ENVY 13-ah0003na

[Jake P]

Package: bugs.debian.org
Severity: normal

Dear Maintainer,

I can only boot into Debian if I use the option acpi=off; this is from a fresh 
install. Using acpi=ht also fails to boot.

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

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

Bug#538304: Clarifying a few things

[Jesse Smith]

I'm looking into this bug in insserv and want to make sure I'm
understanding the issue correctly. As I read it, the problem is that if
the user specifies the same runlevel in both the Default-Start and
Default-Stop fields, insserv will set up the "Stop" symbolic link, but
will not complain about it?

Ideally, insserv should probably still use this behaviour, but print a
warning that the same runlevels should not be listed in both the
Default-Start and Default-Stop fields. Is this a correct summary of the
above request?

- Jesse

Bug#920386: build_user configuration crashes with "uninitialized value $chroot_arch in scalar chomp"

[James Clarke]

On Thu, Jan 24, 2019 at 06:06:30PM -0500, Antoine Beaupre wrote:
> Package: sbuild
> Version: 0.78.0-2
> Severity: normal
>
> I'm trying to setup sbuild so it builds under a different user by
> default. The sbuild.conf(5) manpage says:
>
>BUILD_USER
>   STRING type.  Username used for running dpkg-buildpackage. By 
> default the
>   user  running sbuild is used within the chroot as well but that 
> might al‐
>   low a process from within the chroot to break out of the  
> chroot  by  at‐
>   taching to a process running outside the chroot with eg. gdb 
> and then be‐
>   coming root inside the chroot through schroot and thus be able  
> to  leave
>   the chroot.
>
>   build_user = ...;
>
> I'm assuming the example code there is a typo and should be really:
>
> $build_user = 'sbuild';
>
> ... so I add the above to my `.sbuildrc`. Then I try a build and it
> fails early in the process:
>
> E: read_command failed to execute dpkg
> Use of uninitialized value $chroot_arch in scalar chomp at 
> /usr/share/perl5/Sbui
> ld/Build.pm line 3024.
>
> The "sbuild" user exists in the chroot:
>
> $ schroot -c unstable-amd64-sbuild --directory / id sbuild
> uid=129(sbuild) gid=138(sbuild) groups=138(sbuild)
>
> I have tried to look at the line pointed at by the error message:
>
> chomp(my $chroot_arch = $self->get('Session')->read_command(
>   { COMMAND => ['dpkg', '--print-architecture'],
> USER => $self->get_conf('BUILD_USER'),
> PRIORITY => 0,
> DIR => '/' }));
>
> .. but to figure out what the problem is, you need to dig into
> `read_command`, which is quite a rabbit hole. It calls
> Chroot::read_command which calls pipe_command, which calls
> pipe_command_internal, which calls exec_command, and *then* we hit the
> schroot specific code with get_command_internal, and *finally*
> _get_exec_argv, which shows the user is passed to the `schroot -u`
> argument.
>
> When trying to reproduce the problem outside of sbuild, I therefore
> do:
>
> $ schroot -c unstable-amd64-sbuild --directory / -u sbuild id
> [schroot] password for sbuild:
>
> I think that's where the problem lies: stdin is probably closed which
> makes the command fail. Even if it would be open, the process would
> just hang asking for a password, which doesn't exist (set to '*' in
> /etc/shadow).
>
> If I run schroot as root, that works however:
>
> $ sudo schroot -c unstable-amd64-sbuild --directory / -u sbuild id
> uid=129(sbuild) gid=138(sbuild) groups=138(sbuild)
>
> For what that's worth, the caller is in the `sbuild` group:
>
> $ grep sbuild /etc/group
> sbuild:x:138:anarcat
>
> The schroot has that configuration:
>
> [unstable-amd64-sbuild]
> description=Debian unstable/amd64 autobuilder
> groups=root,sbuild
> root-groups=root,sbuild
> profile=sbuild
> type=directory
> directory=/home/chroot/unstable-amd64-sbuild
> union-type=overlay
>
> So in *theory* it should allow users in the sbuild group to run
> commands without entering a password.
>
> Am I missing something?

Here's the discussion Antoine and I had on IRC about this:

[22:39:57] has anyone ever made $build_user work in sbuild? here 
it crashes with Use of uninitialized value $chroot_arch in scalar chomp at 
/usr/share/perl5/Sbuild/Build.pm line 3024.
[22:53:04]  anarcat: sounds like your chroot doesn't have that user?
[22:53:37]  sorry, *host*
[22:53:43]  the user gets passed as schroot -u
[22:54:01]  that or a perms issue
[22:54:27]  or use pbuilder :P
[23:05:04] i'll file a bug :p
[23:05:13] jrtc27: sudo schroot -u sbuild works
[23:05:19] but not as a regular user
[23:18:30]  sure
[23:18:44]  but you're not running sbuild under sudo
[23:19:25]  so schroot is also run as you
[23:20:30]  $build_user follows the rules of schroot -u argument, 
which is documented in its manpage under AUTHENTICATION
[23:21:32] ...
[23:21:38] so i need to enter the password of the sbuild user?
[23:22:05] this makes no sense to me - i can run schroot as root, 
but not as the sbuild user??
[23:22:31]  agreed that it doesn't make much sense if you're in 
root-users/groups
[23:23:08] there's also the problem that it doesn't "immediately 
fail with permission denied", it crashes with some unrelated, random message
[23:23:35] anyways, enough for today, thanks for the feedback!
[23:23:43]  well, yeah, the error running the command should be 
propagated up rather than the caller choking due to not getting output
[23:23:56] bug is #920386
[23:24:02]  so I guess two bugs, one against sbuild and one against 
schroot :P

Bug#889803: add package with cd-paranoia binary

[Klaumi Klingsporn]

Package: cd-paranoia
Followup-For: Bug #889803

On Tue, 14 Aug 2018 19:24:07 + Niels Thykier
 wrote:
> Source: libcdio-paranoia
> Source-Version: 10.2+0.94+2-4
> 
> We believe that the bug you reported is fixed in the
> latest version of libcdio-paranoia
> ...
>* Remove cd-paranoia package again; the binary is also
> provided by libcdio-utils.  (Reopens: #889803, Closes:
> #906112)   

Dear Niels,

cd-paranoia is no longer provided in the package
libcdio-utils >= 0.92. Version 2.0.0 is in testing
and unstable. 

So there is no need to remove cd-paranoia from debian. There
only needs to be set a
"Breaks: libcdio-utils (<< 2.0.0)" 
in the Debian/control file for the cd-paranoia package and
upgrades from stable should work fine, without trying
to overwrite anything.

Packages that I built with this change can be found at:
apt.klaumikli.de/testing.

You can't ban cd-paranoia from Debian because of a missing
Breaks-line! The binary is needed e.g. by whipper, the only
linux-equivalent to the ExactAudioCopy-cd-ripper in the
windows-world.

Nevertheless: Thanks for caring about this orphaned package!

Klaumi


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

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

Versions of packages cd-paranoia depends on:
ii  libc6  2.28-5
ii  libcdio-cdda2  10.2+0.94+2-5~kmk1
ii  libcdio-paranoia2  10.2+0.94+2-5~kmk1
ii  libcdio18  2.0.0-2

cd-paranoia recommends no packages.

cd-paranoia suggests no packages.

-- no debconf information

Bug#920368: texlive-pictures: tikz fails in pgf

[Henri Menke]

Current PGF maintainer here.
PGF requires e-TeX. Try with etex, pdftex, luatex, or xetex.
Requiring e-TeX is a good assumption in my opinion because it was
introduced in 1998, i.e. is 20 years old today.
We will not make PGF non-e-TeX compatible, sorry.

Kind regards, Henri

On Thu, 24 Jan 2019 20:34:08 +0100 Roland Rosenfeld 
wrote:
> Package: texlive-pictures
> Version: 2018.20190122-1
> Severity: important
> 
> On upgrade from 2018.20181214-1 to 2018.20190122-1 the testsuite of
> fig2dev package fails.
> 
> The root cause for this seems to be in a change of pgf code.
> 
> The fig2dev testsuite runs
> 
> $ tex test.tex
> 
> with the following test.tex input file:
> 
> --- snipp -
> \input tikz
> \bye
> --- snipp -
> 
> with the old version this runs without problems, while with the
> current version this fails with the following output:
> 
> --- snipp -
> $ tex test.tex
> This is TeX, Version 3.14159265 (TeX Live 2019/dev/Debian) (preloaded 
> format=tex)
> (./test.tex 
> (/usr/share/texlive/texmf-dist/tex/plain/pgf/frontendlayer/tikz.tex
> (/usr/share/texlive/texmf-dist/tex/plain/pgf/basiclayer/pgf.tex
> (/usr/share/texlive/texmf-dist/tex/plain/pgf/utilities/pgfrcs.tex
> (/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-common.tex
> (/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-common-lists.t
> ex)) 
> (/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-plain.def
> (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/atbegshi.sty
> (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty)
> (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)
> (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty)))
> (/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfrcs.code.tex
> (/usr/share/texlive/texmf-dist/tex/generic/pgf/pgf.revision.tex)))
> (/usr/share/texlive/texmf-dist/tex/plain/pgf/basiclayer/pgfcore.tex
> (/usr/share/texlive/texmf-dist/tex/plain/pgf/systemlayer/pgfsys.tex
> (/usr/share/texlive/texmf-dist/tex/plain/pgf/utilities/pgfrcs.tex)
> (/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsys.code.tex
> (/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex
> (/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeysfiltered.code.t
> ex))
> ! Undefined control sequence.
> \pgfkeyssetevalue ...gfkeys@temptoks =\scantokens
>   \expandafter 
> {\expandafter...
> 
> \pgfkeys@ifcsname ...\fi \ifpgfkeys@csname@test #2
>   \else #3\fi
> \pgfkeys@ifcsname ...gfkeys@csname@test #2\else #3
>   \fi
> \pgfkeys@ifcsname ...gfkeys@csname@test #2\else #3
>   \fi
> \pgfkeys@unpack ...pgfeov \else \pgfkeys@case@one
>   \fi \fi
> \pgfkeys@@normal ...pgfkeysnovalue =\pgfkeys@stop
>   \pgfkeys@parse
> ...

Bug#920388: ITP: golang-github-keltia-archive -- Small Go library for handling archives of various types.

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: golang-github-keltia-archive
  Version : 0.3.3-1
  Upstream Author : Ollivier Robert
* URL : https://github.com/keltia/archive
* License : BSD-3-clause
  Programming Lang: Go
  Description : Small Go library for handling archives of various types.

-- 

Dependency for #920385.



signature.asc
Description: PGP signature

Bug#920389: ITP: golang-github-intel-tfortools -- template scripting support to go programs

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: golang-github-intel-tfortools
  Version : 0.2.0+git20180102.ec3334c-1
  Upstream Author : Intel Corporation
* URL : https://github.com/intel/tfortools
* License : Apache-2.0
  Programming Lang: Go
  Description : template scripting support to go programs

 Package tfortools provides a set of functions that are designed to make
 it easier for developers to add template based scripting to their command
 line tools.
 .
 Command line tools written in Go often allow users to specify a template
 script to tailor the output of the tool to their specific needs. This can
 be useful both when visually inspecting the data and also when invoking
 command line tools in scripts. The best example of this is go list which
 allows users to pass a template script to extract interesting information
 about Go packages. For example,
 .
 .
 go list -f '{{range .Imports}}{{println .}}{{end}}'
 .
 .
 prints all the imports of the current package.
 .
 The aim of this package is to make it easier for developers to add
 template scripting support to their tools and easier for users of
 these tools to extract the information they need.   It does this by
 augmenting the templating language provided by the standard library
 package text/template in two ways: • It auto generates descriptions of
 the data structures passed as input to a template script for use in help
 messages.  This ensures that help usage information is always up to date
 with the source code.• It provides a suite of convenience functions to
 make it easy for script writers to extract the data they need.  There are
 functions for sorting, selecting rows and columns and generating nicely
 formatted tables.  For example, if a program passed a slice of structs
 containing stock data to a template script, we could use the following
 script to extract the names of the 3 stocks with the highest trade volume.
 .
 .
 {{table (cols (head (sort . "Volume" "dsc") 3) "Name" "Volume")}}
 .
 .
 The output might look something like this:
 .
 .
 Name  Volume Happy Enterprises 6395624278 Big Company
 750 Medium Company300122
 .
 .
 The functions head, sort, tables and col are provided by this package.

-- 

Dependency for #920385.



signature.asc
Description: PGP signature

Bug#920390: ITP: golang-github-ivpusic-grpool -- Lightweight Goroutine pool

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: golang-github-ivpusic-grpool
  Version : 0.0~git20170804.28957a2-1
  Upstream Author : Ivan Pusic
* URL : https://github.com/ivpusic/grpool
* License : MIT
  Programming Lang: Go
  Description : Lightweight Goroutine pool

 Clients can submit jobs. Dispatcher takes job, and sends it to first
 available worker.  When worker is done with processing job, will be
 returned back to worker pool.
 .
 Number of workers and Job queue size is configurable.

Dependency for #920385.


signature.asc
Description: PGP signature

Bug#920387: ITP: golang-github-proglottis-gpgme -- Go wrapper for the GPGME library

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: golang-github-proglottis-gpgme
  Version : 0.0~git20181127.3b0be09-1
  Upstream Author : James Fargher
* URL : https://github.com/proglottis/gpgme
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go wrapper for the GPGME library

 GPGME (golang) Go wrapper for the GPGME library.
 .
 This library is intended for use with desktop applications. If
 you are looking to add OpenPGP support to a server application
 I suggest you first look at golang.org/x/crypto/openpgp
 (https://godoc.org/golang.org/x/crypto/openpgp).  Installationgo
 get -u github.com/proglottis/gpgme Documentation• godoc
 (https://godoc.org/github.com/proglottis/gpgme)

Dependency for #920385.


signature.asc
Description: PGP signature

Bug#920386: build_user configuration crashes with "uninitialized value $chroot_arch in scalar chomp"

[Antoine Beaupre]

Package: sbuild
Version: 0.78.0-2
Severity: normal

I'm trying to setup sbuild so it builds under a different user by
default. The sbuild.conf(5) manpage says:

   BUILD_USER
  STRING type.  Username used for running dpkg-buildpackage. By 
default the
  user  running sbuild is used within the chroot as well but that 
might al‐
  low a process from within the chroot to break out of the  chroot  
by  at‐
  taching to a process running outside the chroot with eg. gdb and 
then be‐
  coming root inside the chroot through schroot and thus be able  
to  leave
  the chroot.

  build_user = ...;

I'm assuming the example code there is a typo and should be really:

$build_user = 'sbuild';

... so I add the above to my `.sbuildrc`. Then I try a build and it
fails early in the process:

E: read_command failed to execute dpkg
Use of uninitialized value $chroot_arch in scalar chomp at /usr/share/perl5/Sbui
ld/Build.pm line 3024.

The "sbuild" user exists in the chroot:

$ schroot -c unstable-amd64-sbuild --directory / id sbuild
uid=129(sbuild) gid=138(sbuild) groups=138(sbuild)

I have tried to look at the line pointed at by the error message:

chomp(my $chroot_arch = $self->get('Session')->read_command(
{ COMMAND => ['dpkg', '--print-architecture'],
  USER => $self->get_conf('BUILD_USER'),
  PRIORITY => 0,
  DIR => '/' }));

.. but to figure out what the problem is, you need to dig into
`read_command`, which is quite a rabbit hole. It calls
Chroot::read_command which calls pipe_command, which calls
pipe_command_internal, which calls exec_command, and *then* we hit the
schroot specific code with get_command_internal, and *finally*
_get_exec_argv, which shows the user is passed to the `schroot -u`
argument.

When trying to reproduce the problem outside of sbuild, I therefore
do:

$ schroot -c unstable-amd64-sbuild --directory / -u sbuild id
[schroot] password for sbuild: 

I think that's where the problem lies: stdin is probably closed which
makes the command fail. Even if it would be open, the process would
just hang asking for a password, which doesn't exist (set to '*' in
/etc/shadow).

If I run schroot as root, that works however:

$ sudo schroot -c unstable-amd64-sbuild --directory / -u sbuild id
uid=129(sbuild) gid=138(sbuild) groups=138(sbuild)

For what that's worth, the caller is in the `sbuild` group:

$ grep sbuild /etc/group
sbuild:x:138:anarcat

The schroot has that configuration:

[unstable-amd64-sbuild]
description=Debian unstable/amd64 autobuilder
groups=root,sbuild
root-groups=root,sbuild
profile=sbuild
type=directory
directory=/home/chroot/unstable-amd64-sbuild
union-type=overlay

So in *theory* it should allow users in the sbuild group to run
commands without entering a password.

Am I missing something?

The full build log is attached.

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

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

Versions of packages sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.78.0-2
ii  perl5.28.1-3

Versions of packages sbuild recommends:
ii  autopkgtest  5.8
ii  debootstrap  1.0.114
ii  schroot  1.6.10-6+b1

Versions of packages sbuild suggests:
ii  deborphan  1.7.31
ii  e2fsprogs  1.44.5-1
ii  kmod   25-2
ii  wget   1.20.1-1

-- no debconf information
sbuild (Debian sbuild) 0.78.0 (09 January 2019) on curie.anarc.at

+==+
| undertime 1.7.0 (amd64)  Thu, 24 Jan 2019 22:39:05 + |
+==+

Package: undertime
Version: 1.7.0
Source Version: 1.7.0
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

E: read_command failed to execute dpkg
Use of uninitialized value $chroot_arch in scalar chomp at 
/usr/share/perl5/Sbuild/Build.pm line 3024.

+--+
| Post Build Failed Commands   |
+--+


/usr/bin/notify-send "Build completed" "Build of 
/home/anarcat/src/undertime_1.7.0.dsc on %SBUILD_DISTRIBUTION-amd64 completed."



I: Finished running '/usr/bin/notify-send "Build 

Bug#759173: Urgent translation update for ocamlgraph

[Américo Monteiro]

A quinta-feira, 24 de janeiro de 2019 21:08:11 WET Helge Kreutzmann escreveu:
> Hello Américo,
> you provided a man page translation for ocamlgraph some time ago. I'm
> intending to update ocamlgraph to include your translation.
> Unfortunately the man page does not build as your translation is out of
> date.
> 
> I attached the current pt.po to this e-mail. If you update the file by
> 2019-01-31 I can include it in the next upload and it will hit Debian
> before the freeze.
> 
> I appologize for the short notice.
> 
> Greetings
> 
>   Helge

Translation updated

Best regards
Américo


ocamlgraph_pt.po.gz
Description: application/gzip

Bug#894285: some progress

[Hans-Christoph Steiner]

I can get some of this compiling with openjdk-11, but not all.

Ok, here's a fun problem: looks like I can build android-platform-23
with java11, but since it is in effect building Java core classes, the
compiler freaks.

There seems to be something like --patch-module java.base=src to deal
with this
but that won't work with sourceCompatibility 1.8
and Android wasn't Java9 until the most most recent release (9.0.0)
so... anyone have some ideas for alternate approaches?

here's a build log
https://salsa.debian.org/android-tools-team/android-framework-23/-/jobs/114477

Bug#920385: ITP: dmarc-cat -- decode the report sent by various email providers following the DMARC spec

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 

* Package name: dmarc-cat
  Version : 0.9.1
  Upstream Author : Ollivier Robert 
* URL : https://github.com/keltia/dmarc-cat/
* License : BSD-2-clause
  Programming Lang: Golang
  Description : decode the report sent by various email providers following 
the DMARC spec

This utility decodes the standard XML reports sent by providers to the
`rua` record configured in DMARC. It is useful to make sense of
reports that are otherwise very difficult to read.

--

I've tried it out and it was a life saver. I was about to just remove
that record because I couldn't make sense of those reports.

There's a comparable service online, which has a little more
information, but does not do reverse DNS:

https://mxtoolbox.com/DmarcReportAnalyzer.aspx

That online service is, of course, not free software as far as I
know.

I haven't found similar software in Debian, but I could have missed
something.

I will probably co-maintain this with the golang team.

Bug#920350: ITP: pkg-js-autopkgtest -- collection of autopktest scripts for nodejs packages

[Xavier]

Le 24/01/2019 à 20:12, Paul Gevers a écrit :
> Oops,
> 
> On 24-01-2019 20:09, Paul Gevers wrote:
>> Hi Xavier,
>>
>> On 24-01-2019 15:25, Xavier Guimard wrote:
>>> Packages using the tests with autopkgtests in this package will simply
>>> have to set "Testsuite: autopkgtest-pkg-js" in debian/control and write
>>> upstream test in debian/tests/pkg-js/test. This package provides also a
>>> test.mk file which can be include in debian/rule to avoid writing a
>>> override_dh_auto_test. The same test will be launched.
>>>
>>> This package is inspired from pkg-perl-autopkgtest. If accepted, a MR
>>> will be done on autodep8 project to include it.
>>
>> I am not sure if you are aware, but please make sure that anything that
>> a maintainer adds about test dependencies is recorded in
>> debian/tests/control. dpkg-source exports the content of the "Depends"
>> fields to the changes file where it is picked up by britney, the
>> migration software.

It's inspired from pkg-perl-autopkgtest package. I'll take care of this

> Another thing, autodep8 already has support for nodejs. If your scripts
> are smarter (which they probably are), could you please replace (instead
> of add) the current nodejs support? I.e. it would be "Testsuite:
> autopkgtest-pkg-nodejs". Let's not have two nodejs supports in autodep8.

Yes I see that and fixed this in my package
(https://salsa.debian.org/js-team/pkg-js-tools/tree/master/doc/autopkgtest#readme)

I'll just propose an update of autopkgtest-pkg-nodejs in autodep8

Thanks!
Xavier

Bug#920384: xorg: invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED

[Nicola]

Package: xorg
Version: 1:7.7+19
Severity: normal

Dear Maintainer,
Sometimes Xorg crashes, specially when opening libreoffice on battery usage.

PC: Lenovo Ideapad 320s-IKBR (Intel i5 8th, nVidia MX130)
lspci:

nicola@lenovo:~$ lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor
Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP
Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial
IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial
IO I2C Controller #1 (rev 21)
00:15.2 Signal processing controller: Intel Corporation Sunrise Point-LP Serial
IO I2C Controller #2 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI
#1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller
[AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port
(rev f1)
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5
(rev f1)
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #6
(rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9
(rev f1)
00:1f.0 ISA bridge: Intel Corporation Intel(R) 100 Series Chipset Family LPC
Controller/eSPI Controller - 9D4E (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 3D controller: NVIDIA Corporation GM108M [GeForce MX130] (rev a2)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI
Express Card Reader (rev 01)
03:00.0 Network controller: Intel Corporation Intel Dual Band Wireless-AC 3165
Plus Bluetooth (rev 99)
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD
Controller SM981/PM981



Xorg log:
[ 14556.501] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.508] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.516] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.522] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.530] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.536] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.544] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.551] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.558] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.565] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.573] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.579] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.587] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.594] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.601] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.608] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 14556.615] (EE) event2  - ELAN0650:01 04F3:304B Touchpad: libinput bug: 1:
invalid tap event TAP_EVENT_MOTION in state TAP_STATE_TAPPED
[ 17875.738] (EE)
[ 17875.738] (EE) Backtrace:
[ 17875.739] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55fd5044efc9]
[ 17875.740] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50)
[0x7fad526226bf]
[ 17875.742] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x10b)
[0x7fad5248485b]
[ 17875.743] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x121)
[0x7fad5246f535]
[ 17875.744] (EE) 4: 

Bug#912627: asymptote: Asymptote crashes on attempt to create pdf file

[Hilmar Preuße]

On 02.11.18 00:22, Dmitry Bogatov wrote:

> Dear Maintainer, here is the code:
> 
> 
>   draw((0, 0) -- (1, 1), opacity(0.7));
> 
> Here is error:
> 
Fixed in git on salsa.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#887399: python-certbot 0.28.0-1~deb9u1 flagged for acceptance

[Julien Cristau]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: python-certbot
Version: 0.28.0-1~deb9u1

Explanation: backport newer version for tls-sni-01 deprecation

Bug#918535: smartmontools: New upstream release (7.0)

[Dan Mick]

Is there anything I can do to help out or urge this along?

On Mon, 07 Jan 2019 08:37:56 + James Page  wrote:
> Package: smartmontools
> Version: 6.6-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> smartmontools upstream just did a 7.0 release that includes JSON
> output support which is needed for the disk health metrics scraping
> and failure prediction support currently in development for Ceph.
> 
> It would be great if this package could be updated to this new
> release to support this work.
> 
> Cheers
> 
> James
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers cosmic-updates
>   APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
> 'cosmic'), (100, 'cosmic-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.18.0-13-generic (SMP w/4 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages smartmontools depends on:
> ii  debianutils  4.8.6
> ii  init-system-helpers  1.54
> ii  libc62.28-0ubuntu1
> ii  libcap-ng0   0.7.9-1
> ii  libgcc1  1:8.2.0-7ubuntu1
> ii  libselinux1  2.8-1build1
> ii  libstdc++6   8.2.0-7ubuntu1
> ii  lsb-base 9.20170808ubuntu1
> 
> Versions of packages smartmontools recommends:
> pn  mailx | mailutils  
> 
> Versions of packages smartmontools suggests:
> pn  gsmartcontrol   
> pn  smart-notifier  
> 
> 

Bug#920383: RFP: elpa-git-gutter-fringe -- provide git diff alongside opened files in Emacs

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: elpa-git-gutter-fringe
  Version : 0.23
  Upstream Author : Syohei YOSHIDA 
* URL : https://github.com/syohex/emacs-git-gutter-fringe
* License : GPL-3+
  Programming Lang: Elisp
  Description : Show git diff information in the Emacs fringe

Gutter-fringe shows the diff for the currently edited file in the
"fringe" of the buffer. Features:

 * Asynchronous updating
 * Live updating
 * Support multiple VCS
 * Support Tramp
 * Work without vc-mode

git-gutter-fringe.el is fringe version of of git-gutter.el.

git-gutter.el is port of GitGutter which is a plugin of Sublime Text

git-gutter.el does not work with linum-mode but git-gutter-fringe.el
can work with linum-mode. In contrast, git-gutter-fringe.el does not
work in tty frame(emacs -nw), but git-gutter.el can work in tty frame.

--

This would probably require packaging `git-gutter` first, as it's a
dependency. I think.

I would love if the emacsen team would magically handle all of
this. :) I have tried the package as installed from package.el and
it's pretty awesome.

There's also a vim version, but I'm no heretic. ;)

https://github.com/airblade/vim-gitgutter

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Jennifer Bryan]

Thanks for the update and fixes, Evan!

What sort of timeframe do you have in mind re: your official release?

That affects how I think about timing a readxl release. I don't do them
lightly but also want to get the fixes that address the CVEs into readxl
sooner rather than later.

-- Jenny

On Thu, Jan 24, 2019 at 1:36 PM Evan Miller  wrote:

>
> On Jan 23, 2019, at 01:16, Evan Miller  wrote:
>
> #34 and #35 have returned from the dead on GitHub. I’ll take a closer look
> later this week.
>
> Evan
>
>
>
> OK — I can confirm that all of the reported libxls bugs are fixed. I have
> successfully integrated libxls into OSS-Fuzz, and have added the
> researcher’s test files to the fuzzing corpus, so that this and related
> issues should be caught by the address sanitizer in the future.
>
> OSS-Fuzz has turned up a number of other issues. I will plan to do a
> release when they are all addressed.
>
> Evan
>
>
> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff  wrote:
>
> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote:
>
>
> Hi Evan,
>
> On 15 January 2019 at 11:18, Evan Miller wrote:
> |
> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff  wrote:
> | >
> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared
> from GitHub. I don’t know if the original reporter intended to close them,
> or what.
> | >>
> | >> I have an email copy of #34 but do not have access to the PoC files.
> So without the cooperation of the reporter (Zhao Liang, Huawei Weiran Labs)
> my ability to research will be limited.
> | >
> | > That's really strange, do you have the mail address of Zhao, could you
> ask him what happened?
> |
> | His address may be leon.zha...@gmail.com - I’ll try it. His GitHub
> profile is now a 404.
> |
> | >
> | > MITRE doesn't archive security content per se, they only deal with the
> organisation and assignment
> | > of numbers. The Internet Archive's Wayback machine also hasn't
> archived the Github pages.
> | >
> | > Cheers,
> | >Moritz
> |
> |
> | Here are the Google caches of #34 and #35:
> |
> |
> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+=1=en=clnk=us=safari
> |
> |
> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+=1=en=clnk=us=safari
> |
> | The PoC links are dead.
> |
> | Looking at the backtraces and the commit fixing #36 and #37 (
> https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e)
> it is my belief that issues #34 and #35 are NOT fixed.
> |
> | I’ll look into them soon.
>
> You're awesome!  Much appreciated.
>
> Moritz: Do you expect the CVE to puliverize too, or will it remain active
> and
> open, but "simply" without any hard (public) evidence backing it?
>
>
> No, they stick around, it sometimes happens that references vanish, e.g.
> then hosting sites
> go down (think of berlios or similar)
>
> Cheers,
>Moritz
>
>
>
>

Bug#919901: [Debian-ha-maintainers] Bug#919901: Bug#919901: corosync-qnetd: fails to upgrade from 'stretch': certutil: Could not set password for the slot

[Valentin Vidic]

On Thu, Jan 24, 2019 at 10:27:39PM +0100, Valentin Vidic wrote:
> Password file indeed seems to be empty on stretch:
> 
> drwxr-x--- 2 root coroqnetd  4096 Jan 24 22:22 .
> drwxr-xr-x 3 root root   4096 Jan 24 22:22 ..
> -rw-r- 1 root coroqnetd 65536 Jan 24 22:22 cert8.db
> -rw-r- 1 root coroqnetd 16384 Jan 24 22:22 key3.db
> -rw-r- 1 root root 41 Jan 24 22:22 noise.txt
> -rw-r- 1 root root  0 Jan 24 22:22 pwdfile.txt
> -rw-r--r-- 1 root root   4223 Jan 24 22:22 qnetd-cacert.crt
> -rw-r- 1 root root  16384 Jan 24 22:22 secmod.db
> -rw-r- 1 root root  4 Jan 24 22:22 serial.txt

Seems the magic upgrade command is:

  # password file should have an empty line to be accepted
  test -f "$db/pwdfile.txt" -a ! -s "$db/pwdfile.txt" && echo > 
"$db/pwdfile.txt"
  certutil -N -d "sql:$db" -f "$db/pwdfile.txt" -@ "$db/pwdfile.txt"

-- 
Valentin

Bug#920382: stretch-pu: package nvidia-persistenced/390.87-1~deb9u1

[Andreas Beckmann]

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

Hi,

in addition to switching nvidia-graphics-drivers to the new 390.xx
upstream release in stretch (#916632), we also need to update some
related packages to the 390.xx series. We don't want to mix different
(major) versions which is completely untested (and unsupported
upstream). And since we build all the components of the driver that are
available in source code form as separate packages in contrib, we need
to update a few extra packages in case of the upstream major version
bump.

This request is for the nvidia-persistenced package.


Andreas


nvidia-persistenced_390.87-1~deb9u1.dsc.diff.gz
Description: application/gzip

Bug#920381: stretch-pu: package nvidia-modprobe/390.87-1~deb9u1

[Andreas Beckmann]

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

Hi,

in addition to switching nvidia-graphics-drivers to the new 390.xx
upstream release in stretch (#916632), we also need to update some
related packages to the 390.xx series. We don't want to mix different
(major) versions which is completely untested (and unsupported
upstream). And since we build all the components of the driver that are
available in source code form as separate packages in contrib, we need
to update a few extra packages in case of the upstream major version
bump.

This request is for the nvidia-modprobe package.


Andreas
diff --git a/debian/changelog b/debian/changelog
index 6dabe86..045a04a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,22 @@
+nvidia-modprobe (390.87-1~deb9u1) stretch; urgency=medium
+
+  * Rebuild for stretch.
+
+ -- Andreas Beckmann   Thu, 24 Jan 2019 22:36:05 +0100
+
+nvidia-modprobe (390.87-1) unstable; urgency=medium
+
+  * New upstream release.
+  * Bump Standards-Version to 4.3.0. No changes needed.
+
+ -- Andreas Beckmann   Thu, 17 Jan 2019 02:31:04 +0100
+
+nvidia-modprobe (390.25-1) unstable; urgency=medium
+
+  * New upstream release.
+
+ -- Andreas Beckmann   Tue, 06 Mar 2018 04:37:14 +0100
+
 nvidia-modprobe (384.111-2~deb9u1) stretch; urgency=medium
 
   * Rebuild for stretch.
diff --git a/debian/control b/debian/control
index 836da1b..c73e0fb 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends:
  dpkg-dev (>= 1.18.8),
  m4,
 Rules-Requires-Root: binary-targets
-Standards-Version: 4.1.3
+Standards-Version: 4.3.0
 Homepage: https://github.com/NVIDIA/nvidia-modprobe
 Vcs-Browser: https://salsa.debian.org/nvidia-team/nvidia-modprobe
 Vcs-Git: https://salsa.debian.org/nvidia-team/nvidia-modprobe.git
diff --git a/debian/copyright b/debian/copyright
index ad3f83a..3c08b65 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -25,7 +25,7 @@ Copyright: (C) Copyright IBM Corporation 2006
 License: Expat
 
 Files: debian/*
-Copyright: © 2014-2018 Andreas Beckmann 
+Copyright: © 2014-2019 Andreas Beckmann 
 License: Expat
 
 License: Expat
diff --git a/modprobe-utils/nvidia-modprobe-utils.c 
b/modprobe-utils/nvidia-modprobe-utils.c
index 61cdbe1..e5c1365 100644
--- a/modprobe-utils/nvidia-modprobe-utils.c
+++ b/modprobe-utils/nvidia-modprobe-utils.c
@@ -62,6 +62,11 @@
 
 #define NV_MODESET_MODULE_NAME "nvidia-modeset"
 
+#define NV_VGPU_VFIO_MODULE_NAME "nvidia-vgpu-vfio"
+
+#define NV_NVLINK_MODULE_NAME "nvidia-nvlink"
+#define NV_NVLINK_PROC_PERM_PATH "/proc/driver/nvidia-nvlink/permissions"
+
 #define NV_DEVICE_FILE_MODE_MASK (S_IRWXU|S_IRWXG|S_IRWXO)
 #define NV_DEVICE_FILE_MODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)
 #define NV_DEVICE_FILE_UID 0
@@ -477,6 +482,65 @@ static void init_device_file_parameters(uid_t *uid, gid_t 
*gid, mode_t *mode,
 fclose(fp);
 }
 
+/* 
+ * A helper to query device file states.
+ */
+static int get_file_state_helper(
+const char *path,
+int major,
+int minor,
+const char *proc_path,
+uid_t uid,
+gid_t gid,
+mode_t mode)
+{
+dev_t dev = NV_MAKE_DEVICE(major, minor);
+struct stat stat_buf;
+int ret;
+int state = 0;
+
+ret = stat(path, _buf);
+if (ret == 0)
+{
+nvidia_update_file_state(, NvDeviceFileStateFileExists);
+
+if (S_ISCHR(stat_buf.st_mode) && (stat_buf.st_rdev == dev))
+{
+nvidia_update_file_state(, NvDeviceFileStateChrDevOk);
+}
+
+if (((stat_buf.st_mode & NV_DEVICE_FILE_MODE_MASK) == mode) &&
+(stat_buf.st_uid == uid) &&
+(stat_buf.st_gid == gid))
+{
+nvidia_update_file_state(, NvDeviceFileStatePermissionsOk);
+}
+}
+
+return state;
+}
+
+int nvidia_get_file_state(int minor, int module_instance)
+{
+char path[NV_MAX_CHARACTER_DEVICE_FILE_STRLEN];
+char proc_path[NV_MAX_PROC_REGISTRY_PATH_SIZE];
+mode_t mode;
+uid_t uid;
+gid_t gid;
+int modification_allowed;
+int state = 0;
+
+assign_device_file_name(path, minor, module_instance);
+assign_proc_registry_path(proc_path, module_instance);
+
+init_device_file_parameters(, , , _allowed,
+proc_path);
+
+state = get_file_state_helper(path, NV_MAJOR_DEVICE_NUMBER, minor,
+  proc_path, uid, gid, mode);
+
+return state;
+}
 
 /*
  * Attempt to create the specified device file with the specified major
@@ -484,8 +548,8 @@ static void init_device_file_parameters(uid_t *uid, gid_t 
*gid, mode_t *mode,
  * permissions.  Returns 1 if the file is successfully created; returns 0
  * if the file could not be created.
  */
-static int mknod_helper(int major, int minor, const char *path,
-const char *proc_path)
+int mknod_helper(int major, int minor, const char *path,
+ const char *proc_path)
 {
   

Bug#920368: texlive-pictures: tikz fails in pgf

[Hilmar Preuße]

forwarded 920368 https://sourceforge.net/p/pgf/bugs/508
stop

On 24.01.19 20:34, Roland Rosenfeld wrote:

> Package: texlive-pictures
> Version: 2018.20190122-1
> Severity: important
> 
> On upgrade from 2018.20181214-1 to 2018.20190122-1 the testsuite of
> fig2dev package fails.
> 
Forwarded to upstream for now.

H.
-- 
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 23, 2019, at 01:16, Evan Miller  wrote:
> 
> #34 and #35 have returned from the dead on GitHub. I’ll take a closer look 
> later this week.
> 
> Evan


OK — I can confirm that all of the reported libxls bugs are fixed. I have 
successfully integrated libxls into OSS-Fuzz, and have added the researcher’s 
test files to the fuzzing corpus, so that this and related issues should be 
caught by the address sanitizer in the future.

OSS-Fuzz has turned up a number of other issues. I will plan to do a release 
when they are all addressed.

Evan

> 
>> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff > > wrote:
>> 
>> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote:
>>> 
>>> Hi Evan,
>>> 
>>> On 15 January 2019 at 11:18, Evan Miller wrote:
>>> | 
>>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff >> > wrote:
>>> | > 
>>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
>>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared 
>>> from GitHub. I don’t know if the original reporter intended to close them, 
>>> or what.
>>> | >> 
>>> | >> I have an email copy of #34 but do not have access to the PoC files. 
>>> So without the cooperation of the reporter (Zhao Liang, Huawei Weiran Labs) 
>>> my ability to research will be limited.
>>> | > 
>>> | > That's really strange, do you have the mail address of Zhao, could you 
>>> ask him what happened?
>>> | 
>>> | His address may be leon.zha...@gmail.com  - 
>>> I’ll try it. His GitHub profile is now a 404.
>>> | 
>>> | > 
>>> | > MITRE doesn't archive security content per se, they only deal with the 
>>> organisation and assignment
>>> | > of numbers. The Internet Archive's Wayback machine also hasn't archived 
>>> the Github pages.
>>> | > 
>>> | > Cheers,
>>> | >Moritz
>>> | 
>>> | 
>>> | Here are the Google caches of #34 and #35:
>>> | 
>>> | 
>>> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+=1=en=clnk=us=safari
>>>  
>>> 
>>> | 
>>> | 
>>> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+=1=en=clnk=us=safari
>>>  
>>> 
>>> | 
>>> | The PoC links are dead.
>>> | 
>>> | Looking at the backtraces and the commit fixing #36 and #37 
>>> (https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e
>>>  
>>> )
>>>  it is my belief that issues #34 and #35 are NOT fixed.
>>> | 
>>> | I’ll look into them soon.
>>> 
>>> You're awesome!  Much appreciated.
>>> 
>>> Moritz: Do you expect the CVE to puliverize too, or will it remain active 
>>> and
>>> open, but "simply" without any hard (public) evidence backing it?
>> 
>> No, they stick around, it sometimes happens that references vanish, e.g. 
>> then hosting sites
>> go down (think of berlios or similar)
>> 
>> Cheers,
>>Moritz
> 

Bug#920380: mariadb-10.1: do not release with buster

[Andreas Beckmann]

Source: mariadb-10.1
Version: 1:10.1.37-3
Severity: serious
Tags: sid buster

buster should only ship one mariadb version, and as it looks, that will
be 10.3


Andreas

Bug#920336: #920336 [xterm] Xterm doesn't support double-sized characters (DECDHL) when using Xft (client-side) fonts

[Thomas Dickey]

This is a wishlist item, that's been on my to-do list for a while.
(patches welcome).

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


signature.asc
Description: Digital signature

Bug#920379: stretch-pu: package nvidia-xconfig/390.87-1~deb9u1

[Andreas Beckmann]

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

Hi,

in addition to switching nvidia-graphics-drivers to the new 390.xx
upstream release in stretch (#916632), we also need to update some
related packages to the 390.xx series. We don't want to mix different
(major) versions which is completely untested (and unsupported
upstream). And since we build all the components of the driver that are
available in source code form as separate packages in contrib, we need
to update a few extra packages in case of the upstream major version
bump.

This request is for the nvidia-xconfig package.


Andreas
diff --git a/debian/changelog b/debian/changelog
index b4838f9..b9809d8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,31 @@
+nvidia-xconfig (390.87-1~deb9u1) stretch; urgency=medium
+
+  * Rebuild for stretch.
+
+ -- Andreas Beckmann   Thu, 24 Jan 2019 21:27:17 +0100
+
+nvidia-xconfig (390.87-1) unstable; urgency=medium
+
+  * New upstream release.
+  * Bump Standards-Version to 4.3.0. No changes needed.
+
+ -- Andreas Beckmann   Fri, 18 Jan 2019 16:48:41 +0100
+
+nvidia-xconfig (390.25-1) unstable; urgency=medium
+
+  * New upstream release.
+
+ -- Andreas Beckmann   Wed, 07 Mar 2018 01:58:28 +0100
+
+nvidia-xconfig (387.34-1) unstable; urgency=medium
+
+  * New upstream release.
+  * Add debian/upstream/metadata.
+  * Fix new Lintian issues.
+  * Switch Vcs-* URLs to salsa.debian.org.
+
+ -- Andreas Beckmann   Tue, 06 Mar 2018 01:23:54 +0100
+
 nvidia-xconfig (384.111-1~deb9u1) stretch; urgency=medium
 
   * Rebuild for stretch.
@@ -420,4 +448,3 @@ nvidia-xconfig (1.0+20051122-1) unstable; urgency=low
   * Initial Upload.
 
  -- Randall Donald   Mon,  7 Nov 2005 10:54:24 -0800
-
diff --git a/debian/control b/debian/control
index 43c7899..a2a89d5 100644
--- a/debian/control
+++ b/debian/control
@@ -12,10 +12,10 @@ Build-Depends:
  pkg-config,
  xserver-xorg-dev,
 Rules-Requires-Root: no
-Standards-Version: 4.1.3
+Standards-Version: 4.3.0
 Homepage: https://download.nvidia.com/XFree86/nvidia-xconfig/
-Vcs-Git: https://anonscm.debian.org/git/pkg-nvidia/nvidia-xconfig.git
-Vcs-Browser: https://anonscm.debian.org/cgit/pkg-nvidia/nvidia-xconfig.git
+Vcs-Browser: https://salsa.debian.org/nvidia-team/nvidia-xconfig
+Vcs-Git: https://salsa.debian.org/nvidia-team/nvidia-xconfig.git
 
 Package: nvidia-xconfig
 Architecture: i386 amd64 armhf
diff --git a/debian/copyright b/debian/copyright
index b1b087a..9503b72 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,6 +2,12 @@ Format: 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: nvidia-xconfig
 Upstream-Contact: NVIDIA Corporation
 Source: https://download.nvidia.com/XFree86/nvidia-xconfig/
+Disclaimer:
+ This package is not part of the GNU/Linux Debian distribution. It is
+ provided in the contrib archive area as a convenience to Debian users.
+ The contents of this source package are freely licensed under the Expat,
+ GPL, and other licenses, but it is only useful in combination with the
+ proprietary NVIDIA drivers in non-free.
 
 Files: *
 Copyright: (C) 2004-2012 NVIDIA Corporation
@@ -119,7 +125,7 @@ License: other-XFree
 
 Files: debian/*
 Copyright: © 2005 Randall Donald 
-   © 2010-2018 Andreas Beckmann 
+   © 2010-2019 Andreas Beckmann 
 License: GPL-2+
 
 License: GPL-2
diff --git a/debian/source/lintian-overrides b/debian/source/lintian-overrides
index 7ec9f82..8ebed74 100644
--- a/debian/source/lintian-overrides
+++ b/debian/source/lintian-overrides
@@ -1,2 +1,2 @@
 # upstream provides no signatures
-debian-watch-may-check-gpg-signature
+debian-watch-does-not-check-gpg-signature
diff --git a/debian/upstream/metadata b/debian/upstream/metadata
new file mode 100644
index 000..e9de2f9
--- /dev/null
+++ b/debian/upstream/metadata
@@ -0,0 +1,3 @@
+Name: nvidia-xconfig
+Repository: https://github.com/NVIDIA/nvidia-xconfig.git
+Repository-Browse: https://github.com/NVIDIA/nvidia-xconfig
diff --git a/nvidia-cfg.h b/nvidia-cfg.h
index 41c7a54..cac7565 100644
--- a/nvidia-cfg.h
+++ b/nvidia-cfg.h
@@ -442,4 +442,12 @@ NvCfgBool nvCfgFlashGSyncDevice(NvCfgGSyncHandle handle, 
int format,
 const unsigned char *newFirmwareImage,
 int size);
 
+
+/*
+ * nvCfgDumpDisplayPortAuxLog() - dump the DisplayPort AUX channel log to the
+ * system log. On success, NVCFG_TRUE will be returned. On failure, NVCFG_FALSE
+ * will be returned.
+ */
+NvCfgBool nvCfgDumpDisplayPortAuxLog(NvCfgDeviceHandle handle);
+
 #endif /* __NVIDIA_CFG__ */
diff --git a/nvidia-xconfig.c b/nvidia-xconfig.c
index 8e7a40a..fc007b3 100644
--- a/nvidia-xconfig.c
+++ b/nvidia-xconfig.c
@@ -333,7 +333,7 @@ static void parse_commandline(Options *op, int argc, char 
*argv[])
 break;
 }
 
-if (intval < 0 || intval > 13) {
+if (intval < 0 || intval > 14) {
 

Bug#919901: [Debian-ha-maintainers] Bug#919901: corosync-qnetd: fails to upgrade from 'stretch': certutil: Could not set password for the slot

[Valentin Vidic]

On Sun, Jan 20, 2019 at 05:07:25PM +0100, Andreas Beckmann wrote:
>   Setting up corosync-qnetd (3.0.0-1) ...
>   password file contains no data
>   Invalid password.
>   certutil: Could not set password for the slot: SEC_ERROR_INVALID_ARGS: 
> security library: invalid arguments.
>   dpkg: error processing package corosync-qnetd (--configure):
>installed corosync-qnetd package post-installation script subprocess 
> returned error exit status 255
>   Processing triggers for libc-bin (2.28-5) ...
>   Errors were encountered while processing:
>corosync-qnetd

Password file indeed seems to be empty on stretch:

drwxr-x--- 2 root coroqnetd  4096 Jan 24 22:22 .
drwxr-xr-x 3 root root   4096 Jan 24 22:22 ..
-rw-r- 1 root coroqnetd 65536 Jan 24 22:22 cert8.db
-rw-r- 1 root coroqnetd 16384 Jan 24 22:22 key3.db
-rw-r- 1 root root 41 Jan 24 22:22 noise.txt
-rw-r- 1 root root  0 Jan 24 22:22 pwdfile.txt
-rw-r--r-- 1 root root   4223 Jan 24 22:22 qnetd-cacert.crt
-rw-r- 1 root root  16384 Jan 24 22:22 secmod.db
-rw-r- 1 root root  4 Jan 24 22:22 serial.txt

-- 
Valentin

Bug#900746: xen toolstack xl causes a Segmentation fault on create domu

[Stephen Gelman]

On Thu, 28 Jun 2018 18:58:24 +0200 Hans van Kranenburg  wrote:
> Hi,
>
> On 06/28/2018 09:58 AM, Damian Pietras wrote:
> > I've also hit it on one of my boxes with
> > 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8
> >
> > This is related to too small stack size set for threads in XEN utils
> > which explicitly set it to use 16KB. Similar issue is reported here for
> > NTP: https://bugzilla.redhat.com/show_bug.cgi?id=1564527
> >
> > I've recompilled the package with the attached patch to increase the
> > stack size from 16KB to 32KB and it works.
>
> Thanks for doing "bug triaging"!
>
> > Technical details:
> >
> > The issue appears with modern CPU that support AVX-512 instruction set,
> > in my case it's Intel(R) Xeon(R) Gold 6148. More details are in this
> > bug report against glibc: https://bugzilla.redhat.com/show_bug.cgi?id=1
> > 527887#c18
> >
> > There was a post on xen-users acknowledging the bug that says it's
> > fixed in XEN 4.11: https://lists.xenproject.org/archives/html/xen-users
> > /2018-05/msg00034.html
>
> Following that post and what happened afterwards leads me to upstream
> commit 448c03b3cb "tools/xenstore: try to get minimum thread stack size
> for watch thread", which seems to solve this problem without hardcoding
> some size.
>
> Maybe this should be a nice candidate for upstream backport to stable
> branches, since users are buying newer hardware and otherwise cannot use
> Debian Stable without recompiling their Xen packages?
>
> Ian?
>
> Thanks,
> Hans

This patch fixed segfault problems for us on servers with Intel Xeon
Gold 6148 CPUs.  What would it take to get this patch included in the
next stretch update?  It's a pretty big deal for us right now and
while we'll be ok running this patched version for now it'd be great
to not have to maintain our own patch.

Thanks,

Stephen

Bug#920378: unbound: New upstream release available

[Scott Kitterman]

Package: unbound
Version: 1.8.1-1
Severity: wishlist

According to the upstream website, 1.8.3 is available.  It would be nice to
see the package updated before the release freeze.  This isn't showing up
on tracker.d.o or p.qa.d.o, so I imagine the watch file needs work too,
although I didn't look into details.

Scott K

Bug#915103: Apache2 HTTP/2 connection problems with Safari clients

[Philip Iezzi]

Hi Stefan
Do you have any news about this? I had to downgrade the major part of my 
customers to HTTP/1.1 because of this bug, which is quite a disaster.
I would greatly appreciate your help. Am also more than willing to pay you the 
hours you spend on this.
Best regards,
Philip

Bug#920377: dpkg > 1.19.3 breaks reprepro

[Alf Gaida]

Package: reprepro
Version: 5.2.0-1
Severity: grave

Dear Maintainer, 

Commit 
https://salsa.debian.org/dpkg-team/dpkg/commit/4a4619831de8b8972f86b489660dc98f187cfa34.patch
 breaks reprepro.

Error:
Jan 24 18:23:00 Missing 'Binary' field!
Jan 24 18:23:00 There have been errors!

Cheers Alf

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

Kernel: Linux 4.20.3-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reprepro depends on:
ii  libarchive13   3.3.3-3
ii  libbz2-1.0 1.0.6-9
ii  libc6  2.28-5
ii  libdb5.3   5.3.28+dfsg1-0.2
ii  libgpg-error0  1.33-3
ii  libgpgme11 1.12.0-6
ii  liblzma5   5.2.2-1.3
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages reprepro recommends:
ii  apt  1.8.0~beta1

Versions of packages reprepro suggests:
ii  gnupg-agent  2.2.12-1
ii  gpg-agent [gnupg-agent]  2.2.12-1
pn  inoticoming  
pn  lzip 
ii  pinentry-curses  1.1.0-1+b1

-- no debconf information

Bug#841208: [monkeysphere] Bug#841208: fixed in monkeysphere 0.41-1

[Daniel Kahn Gillmor]

re: https://bugs.debian.org/841208 --

entropy exhaustion should no longer be an issue on debian buster, since
the gcrypt started using getrandom() as of gcrypt 1.8.4 (see upstream
https://dev.gnupg.org/T3894)

--dkg


signature.asc
Description: PGP signature

Bug#920038: [Pkg-privacy-maintainers] Bug#920038: monkeysphere: autopkgtest times out since 2019-01-15

[Daniel Kahn Gillmor]

Control: tags 920038 + help

On Mon 2019-01-21 21:10:04 +0100, Paul Gevers wrote:
> Since 2019-01-15 the autopkgtest of your package times out (after 5:33h)
> on ci.debian.net.

Thanks for the heads-up, Paul.  Looking at this more closely:

> autopkgtest [02:55:29]: test command1: MONKEYSPHERE_TEST_USE_SYSTEM=true 
> MONKEYSPHERE_TEST_NO_EXAMINE=true tests/keytrans

This is apparently timing out on this first test, not even getting to 
tests/basic.

and it ends with:

> ##
>  Monkeysphere keytrans test completed successfully!
> ##
> ### removing temp dir...

which is what i would expect, invoking the cleanup() bash function from
tests/common:

--
cleanup() {
echo "### removing temp dir..."
rm -rf "$TEMPDIR"

if [ "$SSHD_PID" ] ; then
echo "### killing off lingering sshd..."
kill "$SSHD_PID"
fi

wait
}
--

So i imagine that it's hanging forever in the wait function.  I'll add a
"jobs" invocation before that for future tests to be able to see what
it's waiting on, i guess, but i don't see why that would have changed
from one invocation to the next.

i do note that the failure happened across a bash upgrade:

--- previous-run/testbed-packages
+++ current-run/testbed-packages
@@ -2,7 +2,7 @@
 apt1.8.0~alpha3
 base-files 10.1
 base-passwd3.5.45
-bash   4.4.18-3.1
+bash   5.0-1
 binutils   2.31.1-11
 binutils-common2.31.1-11
 binutils-x86-64-linux-gnu  2.31.1-11


Since bash essential, it's not listed as an explicit dependency in
monkeysphere.  That said, i can easily run this test with bash 5.0-1 on
my own systems and have no hanging problem.

So i'm mystified by this, and would appreciate any help figuring it out.

   --dkg


signature.asc
Description: PGP signature

Bug#920376: lintian: Add a check for binaries using obsolete DES encryption

[Zack Weinberg]

Package: lintian
Version: 2.5.123
Severity: wishlist
Tags: patch

The attached patch adds a Lintian check for binaries using the obsolete
DES encryption functions that were made inaccessible to newly linked
binaries in glibc 2.28.  See the patch's commit message for more detail.

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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.4
ii  dpkg-dev   1.19.4
ii  file   1:5.35-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.4
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-1
ii  patchutils 0.3.4-2
ii  perl   5.28.1-3
ii  t1utils1.41-3
ii  xz-utils   5.2.2-1.3

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

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.54-1

-- no debconf information
>From d79acb92725ef2ddbc2b33eba62a4e7b7f361a3d Mon Sep 17 00:00:00 2001
From: Zack Weinberg 
Date: Thu, 24 Jan 2019 15:40:26 -0500
Subject: [PATCH] Add a check for binaries using obsolete DES encryption.

libcrypt.so.1 (part of glibc) used to provide a set of functions that
allowed raw use of the DES block cipher.  Encryption with DES is now
inherently insecure (any use of single DES can be broken by brute
force) and therefore these functions were made inaccessible to newly
linked programs in glibc 2.28.

Any program in the archive that unconditionally uses one of these
functions will FTBFS with glibc 2.28.  Any program that conditionally
uses one of these functions may be falling back to an internal
implementation of DES and therefore have a security bug.

Therefore, I propose this new lintian check, which detects use of the
functions that were removed from libcrypt.so.1.  In sid it is arguably
redundant (since any program that would fail this check will FTBFS
anyway) but applying this check to the stable archive would detect
programs that were conditionally using these functions and need to be
audited for security bugs.
---
 checks/binaries.desc  | 45 
 checks/binaries.pm| 10 +++-
 data/binaries/obsolete-crypt-functions| 13 +
 t/tests/binaries-obsolete-des/desc|  7 +++
 t/tests/binaries-obsolete-des/orig/Makefile   | 51 +++
 t/tests/binaries-obsolete-des/orig/dummy.pod  | 12 +
 .../binaries-obsolete-des/orig/uses-encrypt.c | 30 +++
 .../orig/uses-encrypt_r.c | 33 
 .../binaries-obsolete-des/orig/uses-fcrypt.c  | 21 
 .../binaries-obsolete-des/orig/uses-setkey.c  | 45 
 .../orig/uses-setkey_r.c  | 48 +
 t/tests/binaries-obsolete-des/tags|  5 ++
 12 files changed, 319 insertions(+), 1 deletion(-)
 create mode 100644 data/binaries/obsolete-crypt-functions
 create mode 100644 t/tests/binaries-obsolete-des/desc
 create mode 100644 t/tests/binaries-obsolete-des/orig/Makefile
 create mode 100644 t/tests/binaries-obsolete-des/orig/dummy.pod
 create mode 100644 t/tests/binaries-obsolete-des/orig/uses-encrypt.c
 create mode 100644 t/tests/binaries-obsolete-des/orig/uses-encrypt_r.c
 create mode 100644 t/tests/binaries-obsolete-des/orig/uses-fcrypt.c
 create mode 100644 t/tests/binaries-obsolete-des/orig/uses-setkey.c
 create mode 100644 t/tests/binaries-obsolete-des/orig/uses-setkey_r.c
 create mode 100644 t/tests/binaries-obsolete-des/tags

diff --git 

Bug#920375: zoneminder: CVE-2019-6777

[Salvatore Bonaccorso]

Source: zoneminder
Version: 1.30.4+dfsg1-5
Severity: important
Tags: security upstream
Forwarded: https://github.com/ZoneMinder/zoneminder/issues/2436

Hi,

The following vulnerability was published for zoneminder.

CVE-2019-6777[0]:
| An issue was discovered in ZoneMinder v1.32.3. Reflected XSS exists in
| web/skins/classic/views/plugin.php via the zm/index.php?view=plugin pl
| parameter.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-6777
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6777
[1] https://github.com/ZoneMinder/zoneminder/issues/2436

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#920374: python-openssl: _ASN1_TYPE_TO_ENUM TypeError: 'type' object is not iterable

[matsche]

Package: python-openssl
Version: 18.0.0-1
Severity: important

Dear Maintainer,

importing the ssl module with:

Python 2.7.15+ (default, Nov 28 2018, 16:27:22) 
[GCC 8.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from OpenSSL import crypto, SSL
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/OpenSSL/__init__.py", line 8, in 

from OpenSSL import crypto, SSL
  File "/usr/lib/python2.7/dist-packages/OpenSSL/crypto.py", line 12, in 

from cryptography import x509
  File "/usr/lib/python2.7/dist-packages/cryptography/x509/__init__.py", line 
8, in 
from cryptography.x509.base import (
  File "/usr/lib/python2.7/dist-packages/cryptography/x509/base.py", line 16, 
in 
from cryptography.x509.extensions import Extension, ExtensionType
  File "/usr/lib/python2.7/dist-packages/cryptography/x509/extensions.py", line 
24, in 
from cryptography.x509.general_name import GeneralName, IPAddress, OtherName
  File "/usr/lib/python2.7/dist-packages/cryptography/x509/general_name.py", 
line 18, in 
from cryptography.x509.name import Name
  File "/usr/lib/python2.7/dist-packages/cryptography/x509/name.py", line 28, 
in 
_ASN1_TYPE_TO_ENUM = dict((i.value, i) for i in _ASN1Type)
TypeError: 'type' object is not iterable
>>>

python enum is the last one:
python-enum34 backport of Python 3.4's enum package   1.1.6-2
1.1.6-2



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

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

Versions of packages python-openssl depends on:
ii  python   2.7.15-3
ii  python-cryptography  2.3-1
ii  python-six   1.12.0-1

python-openssl recommends no packages.

Versions of packages python-openssl suggests:
pn  python-openssl-dbg  
pn  python-openssl-doc  

-- no debconf information

Bug#920281: Re : Bug#920281: ntopng: Unable to finish the post-inst.

[Ludovico Cavedon]

On Thu, Jan 24, 2019 at 1:57 AM  wrote:

> > Thank you for reporting the issue.
> > What version of ntopng where you upgrading from?
>
> From the previous one I guess, I upgrade my Sid every day.
>

>From the previous on sid, then, 3.2 (which never made it to testing).

Can you also send me the output of the following commands, please?

ls -ld  /var/lib/ntopng
ls -l  /var/lib/ntopng
grep ntopng /var/log/dpkg.log

The new ntopng uses /var/lib/ntopng instead of /var/tmp/ntopng, and a
different user.
Something is going wrong with the migration I have not been able to
reproduce yet.

If you do not care about the old data, you can just remove  /var/tmp/ntopng
Otherwise you can move /var/tmp/ntopng to /var/lib/ntopng and
chown -R ntopng:ntopng /var/lib/ntopng
cmod 700 /var/lib/ntopng

Thank you,
Ludovico

Bug#920304: Acknowledgement (mailman3-web: mailman3web / django does not like python3-pymysql)

[Bjoern Franke]

Hi,


> If you wish to submit further information on this problem, please
> send it to 920...@bugs.debian.org.
> 

I got further information from the mailman3-mailinglist. The dependency
of mailman3-web is wrong, it needs python3-mysqldb, not python3-pymysql:

"You need both pymysql and mysqlclient. The former is used by Mailman
core and the latter by Django.

These can be installed with pip via

pip3 install pymysql
pip3 install mysqlclient

or apt via

apt install python3-pymysql python3-mysqldb"

Kind regards
Bjoern

Bug#920373: /etc/timidity/timidity.cfg: please add: #source /etc/timidity/ms_general.cfg

[Thorsten Glaser]

Package: timidity
Version: 2.14.0-8
Severity: wishlist

Hi,

the new musescore-general-soundfont-lossless Debian package
contains a(n admittedly rudimentary) /etc/timidity/ms_general.cfg
configuration file sufficient to play some MIDIs with it
using timidity.

Please add a (commented-out) source command for it to the
shipped timidity.cfg file and, perhaps, amend Suggests as
to include musescore-general-soundfont-lossless (but not
the other two musescore-general-soundfont* packages since
those are in SF3 format, not SF2, and thus not usable by
timidity AIUI).

Thanks in advance!

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

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

Versions of packages timidity depends on:
ii  libao41.2.2+20180113-1
ii  libasound21.1.7-2+x32.1
ii  libc6 2.28-5
ii  libflac8  1.3.2-3
ii  libice6   2:1.0.9-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libncurses6   6.1+20181013-1
ii  libogg0   1.3.2-1+b1
ii  libpng16-16   1.6.36-3
ii  libsm62:1.2.2-1+b3
ii  libspeex1 1.2~rc1.2-1+b2
ii  libtinfo6 6.1+20181013-1
ii  libvorbis0a   1.3.6-1
ii  libvorbisenc2 1.3.6-1
ii  libx11-6  2:1.6.7-1
ii  libxaw7   2:1.0.13-1+b2
ii  libxext6  2:1.3.3-1+b2
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1
ii  lsb-base  10.2018112800
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages timidity recommends:
ii  fluid-soundfont-gm  3.1-5.1

Versions of packages timidity suggests:
ii  fluid-soundfont-gs  3.1-5.1
pn  freepats
pn  pmidi   
pn  timidity-daemon 

-- Configuration Files:
/etc/timidity/timidity.cfg changed [not included]

-- no debconf information

Bug#920364: [debian-mysql] Bug#920364: libmariadb-dev: dpkg unpack error when coinstalling

[Otto Kekäläinen]

Thanks for reporting!

This is a duplicate of issue reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863675#89 (and used
to reopen that issue) and has been fixed and uploaded about 1 hour ago
:)

Bug#759173: Urgent translation update for ocamlgraph

[Helge Kreutzmann]

Hello Américo,
you provided a man page translation for ocamlgraph some time ago. I'm
intending to update ocamlgraph to include your translation.
Unfortunately the man page does not build as your translation is out of 
date.

I attached the current pt.po to this e-mail. If you update the file by
2019-01-31 I can include it in the next upload and it will hit Debian
before the freeze.

I appologize for the short notice.

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
# Translation of ocamlgraph's manpage to European Portuguese
# Copyright (C) 2014 Free Software Foundation, Inc.
# This file is distributed under the same license as the ocamlgraph package.
#
# Américo Monteiro , 2014.
msgid ""
msgstr ""
"Project-Id-Version: ocamlgraph 1.8.5-1\n"
"POT-Creation-Date: 2019-01-24 21:01+0100\n"
"PO-Revision-Date: 2018-12-23 07:48+0100\n"
"Last-Translator: Américo Monteiro \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: ENCODINGLanguage: pt\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Lokalize 1.4\n"

#. type: Content of the debian entity
#: debian/xml-man/en/ocamlgraph-editor.xml:4 debian/xml-man/en/license.xml:4
msgid "Debian GNU/Linux"
msgstr "Debian GNU/Linux"

#. type: Content of the dhprg entity
#: debian/xml-man/en/ocamlgraph-editor.xml:5
msgid "ocamlgraph-editor"
msgstr "ocamlgraph-editor"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:37
msgid "OCAMLGRAPH-EDITOR"
msgstr "OCAMLGRAPH-EDITOR"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:38
msgid "1"
msgstr "1"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:39
msgid "OCamlGraph"
msgstr ""

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:40
msgid "User Commands"
msgstr ""

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:44
msgid "ocamlgraph-editor"
msgstr "ocamlgraph-editor.pt"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:46
msgid "GTK-based graph editor based on hyperbolic geometry."
msgstr "Editor de grafos baseado em GTK baseado em geometria hiperbólica."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:51
msgid ""
" -dfs -bfs -rr refresh-rate -aa  -help --help "
" graph-file"
msgstr ""
" -dfs -bfs -rr taxa-de-"
"refrescamento -aa  -help "
"--help  ficheiro-grafo"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:65
msgid "DESCRIPTION"
msgstr "DESCRIÇÃO"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:67
msgid "This manual page documents briefly the  command."
msgstr "Este manual documenta brevemente o comando ."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:69
msgid ""
"This manual page was written for the  distribution because the "
"original program does not have a manual page."
msgstr ""
"Este manual foi escrito para a distribuição  porque o programa "
"original não tem um manual."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:72
msgid ""
" is an OCaml and GTK based graph editor based on hyperbolic geometry."
msgstr ""
" é um editor de grafos baseado em OCaml e GTK baseado em geometria "
"hiperbólica."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:76
msgid "-dfs"
msgstr "-dfs"

#. type: Content of: 

#: debian/xml-man/en/ocamlgraph-editor.xml:78
msgid "DFS drawing strategy."
msgstr "Estratégia de desenho DFS."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:82
msgid "-bfs"
msgstr "-bfs"

#. type: Content of: 

#: debian/xml-man/en/ocamlgraph-editor.xml:84
msgid "BFS drawing strategy."
msgstr "Estratégia de desenho BFS."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:88
msgid "-rr refresh-rate"
msgstr "-rr taxa-de-refrescamento"

#. type: Content of: 

#: debian/xml-man/en/ocamlgraph-editor.xml:90
msgid "Set the refresh rate, must be greater than 0."
msgstr "Define a taxa de refrescamento, tem de ser maior que 0."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:94
msgid "-aa"
msgstr "-aa"

#. type: Content of: 

#: debian/xml-man/en/ocamlgraph-editor.xml:96
msgid "Turn off anti-aliased mode."
msgstr "Liga o modo anti-aliased."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:100
msgid "graph-file"
msgstr "ficheiro-grafo"

#. type: Content of: 

#: debian/xml-man/en/ocamlgraph-editor.xml:102
msgid "Files to edit."
msgstr "Ficheiros para editar."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:106
msgid "-help"
msgstr "-help"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:107
msgid "--help"
msgstr "--help"

#. type: Content of: 

#: 

Bug#866145: Urgent translation update for ocamlgraph

[Helge Kreutzmann]

Hello Chris,
you provided a man page translation for ocamlgraph some time ago. I'm
intending to update ocamlgraph to include your translation. Unfortunately
the man page does not build as your translation is out of date.

I attached the current de.po to this e-mail. If you update the file by
2019-01-31 I can include it in the next upload and it will hit Debian
before the freeze.

I appologize for the short notice.

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
# German translation of the po4a ocamlgraph-editor manpage for debian.
# Copyright (C) 2017 Free Software Foundation, Inc.
# This file is distributed under the same license as the 
# ocamlgraph-editor package.
# Copyright  of this file Chris Leick , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: ocamlgraph-editor 1.8.6-1\n"
"POT-Creation-Date: 2019-01-24 21:01+0100\n"
"PO-Revision-Date: 2018-12-23 07:44+0100\n"
"Last-Translator: Chris Leick \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. type: Content of the debian entity
#: debian/xml-man/en/ocamlgraph-editor.xml:4 debian/xml-man/en/license.xml:4
msgid "Debian GNU/Linux"
msgstr "Debian GNU/Linux"

#. type: Content of the dhprg entity
#: debian/xml-man/en/ocamlgraph-editor.xml:5
msgid "ocamlgraph-editor"
msgstr "ocamlgraph-editor"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:37
msgid "OCAMLGRAPH-EDITOR"
msgstr "OCAMLGRAPH-EDITOR"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:38
msgid "1"
msgstr "1"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:39
msgid "OCamlGraph"
msgstr ""

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:40
msgid "User Commands"
msgstr ""

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:44
msgid "ocamlgraph-editor"
msgstr "Ocamlgraph-Editor.de"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:46
msgid "GTK-based graph editor based on hyperbolic geometry."
msgstr "GTK-basierter Diagramm-Editor auf Basis hyperbolischer Geometrie."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:51
msgid ""
" -dfs -bfs -rr refresh-rate -aa  -help --help "
" graph-file"
msgstr ""
" -dfs -bfs -rr "
"Erneuerungsrate -aa  "
"-help --help  Diagrammdatei"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:65
msgid "DESCRIPTION"
msgstr "BESCHREIBUNG"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:67
msgid "This manual page documents briefly the  command."
msgstr "Diese Handbuchseite dokumentiert kurz den Befehl ."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:69
msgid ""
"This manual page was written for the  distribution because the "
"original program does not have a manual page."
msgstr ""
"Diese Handbuchseite wurde für die -Distribution geschrieben, da das "
"Originalprogramm keine Handbuchseite hat."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:72
msgid ""
" is an OCaml and GTK based graph editor based on hyperbolic geometry."
msgstr ""
" ist ein OCaml- und GTK-basierter Diagramm-Editor, der auf "
"hyperbolischer Geometrie beruht."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:76
msgid "-dfs"
msgstr "-dfs"

#. type: Content of: 

#: debian/xml-man/en/ocamlgraph-editor.xml:78
msgid "DFS drawing strategy."
msgstr "DFS-Zeichenstrategie"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:82
msgid "-bfs"
msgstr "-bfs"

#. type: Content of: 

#: debian/xml-man/en/ocamlgraph-editor.xml:84
msgid "BFS drawing strategy."
msgstr "BFS-Zeichenstrategie"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:88
msgid "-rr refresh-rate"
msgstr "-rr Erneuerungsrate"

#. type: Content of: 

#: debian/xml-man/en/ocamlgraph-editor.xml:90
msgid "Set the refresh rate, must be greater than 0."
msgstr "setzt die Erneuerungsrate, muss größer als 0 sein."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:94
msgid "-aa"
msgstr "-aa"

#. type: Content of: 

#: debian/xml-man/en/ocamlgraph-editor.xml:96
msgid "Turn off anti-aliased mode."
msgstr "deaktiviert den Antialiasing-Modus."

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:100
msgid "graph-file"
msgstr "Diagramm-Datei"

#. type: Content of: 

#: debian/xml-man/en/ocamlgraph-editor.xml:102
msgid "Files to edit."
msgstr "zu bearbeitende Dateien"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:106
msgid "-help"
msgstr "-help"

#. type: Content of: 
#: debian/xml-man/en/ocamlgraph-editor.xml:107
msgid "--help"
msgstr "--help"

#. type: Content of: 

#: 

Bug#920041: Info received (Bug#920041: Acknowledgement (pk12util 2:3.41-1 (buster) - cannot export certificate))

[Kostya Vasilyev]

Another follow-up:

Using -W "" (no passsword) makes things work.

However:

-W is listed in help as an optional parameter:

Usage:   pk12util -i importfile [-d certdir] [-P dbprefix] [-h tokenname]
 [-k slotpwfile | -K slotpw] [-w p12filepwfile | -W p12filepw]
 [-v]

Usage:   pk12util -o exportfile -n certname [-d certdir] [-P dbprefix]
 [-c key_cipher] [-C cert_cipher]
 [-m | --key_len keyLen] [--cert_key_len certKeyLen] [-v]
 [-k slotpwfile | -K slotpw]
 [-w p12filepwfile | -W p12filepw]


If a password is required, perhaps there should be a prompt or a more 
descriptive error message - not silent failure or cryptic "error"...

Bug#920372: stretch-pu: package nvidia-settings/390.87-1~deb9u1

[Andreas Beckmann]

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

Hi,

in addition to switching nvidia-graphics-drivers to the new 390.xx
upstream release in stretch (#916632), we also need to update some
related packages to the 390.xx series. We don't want to mix different
(major) versions which is completely untested (and unsupported
upstream). And since we build all the components of the driver that are
available in source code form as separate packages in contrib, we need
to update a few extra packages in case of the upstream major version
bump. An older version of the 390.xx driver has been available in
stretch-backports for a long time already with no known problems.

The diffstat looks huge, but most of this comes from the upstream
reorganization of the embedded image data:

 debian/changelog   |   103 +-
 debian/control |11 +-
 debian/copyright   | 2 +-
 debian/gbp.conf| 1 +
 debian/libxnvctrl0.symbols | 5 +-
 .../0001-nvidia-settings-Remove-STAMP_C.patch  |   266 +
 ...ettings-Remove-__DATE__-from-the-man-page.patch |48 +
 debian/patches/10_libxnvctrl_so_0.diff |23 +-
 debian/patches/SOURCE_DATE_EPOCH-for-STAMP_C.patch |58 -
 debian/patches/SOURCE_DATE_EPOCH-for-manpage.patch |33 -
 .../patches/dummy-hostname-user-for-STAMP_C.patch  |63 -
 debian/patches/link-order.diff |14 +-
 debian/patches/series  | 5 +-
 debian/rules   |32 +-
 debian/source/lintian-overrides| 2 +-
 debian/upstream/metadata   | 3 +
 doc/version.mk | 2 +-
 samples/nv-control-warpblend.c |11 +-
 samples/version.mk | 2 +-
 src/Makefile   |31 +-
 src/gtk+-2.x/ctkbanner.c   |   175 +-
 src/gtk+-2.x/ctkconfig.c   | 3 +
 src/gtk+-2.x/ctkdisplayconfig-utils.c  |45 +-
 src/gtk+-2.x/ctkdisplayconfig-utils.h  | 1 -
 src/gtk+-2.x/ctkdisplayconfig.c|63 +-
 src/gtk+-2.x/ctkdisplaylayout.c|54 +-
 src/gtk+-2.x/ctkdisplaylayout.h| 1 +
 src/gtk+-2.x/ctkecc.c  |78 +-
 src/gtk+-2.x/ctkecc.h  | 3 +-
 src/gtk+-2.x/ctkframelock.c|36 +-
 src/gtk+-2.x/ctkglstereo.c |   213 +
 src/gtk+-2.x/ctkglstereo.h |44 +
 src/gtk+-2.x/ctkglwidget.c |   282 +
 src/gtk+-2.x/ctkglwidget.h |91 +
 src/gtk+-2.x/ctkgridlicense.c  |   262 +-
 src/gtk+-2.x/ctkgridlicense.h  | 5 +
 src/gtk+-2.x/ctkopengl.c   |26 +-
 src/gtk+-2.x/ctkpowermizer.c   |14 +-
 src/gtk+-2.x/ctkscreen.c   |14 +
 src/gtk+-2.x/ctkslimm.c| 4 +
 src/gtk+-2.x/ctkui.c   | 6 +-
 src/gtk+-2.x/ctkutils.c|33 +
 src/gtk+-2.x/ctkutils.h| 2 +
 src/gtk+-2.x/ctkwindow.c   |16 +
 src/gtk+-2.x/ctkxvideo.c   | 9 +-
 src/gtk+-2.x/matrix_utils.c|   122 +
 src/gtk+-2.x/matrix_utils.h|39 +
 src/gtk+-2.x/opengl_loading.c  |   104 +
 src/gtk+-2.x/opengl_loading.h  |90 +
 src/gtk+-2.x/opengl_wrappers.c |   410 +
 src/gtk+-2.x/opengl_wrappers.h |68 +
 src/image_data/HOWTO-ADD-IMAGES|27 -
 src/image_data/antialias.png   |   Bin 13252 -> 12874 bytes
 src/image_data/antialias_pixdata.h |  1228 --
 src/image_data/background.png  |   Bin 34616 -> 32249 bytes
 src/image_data/background_pixdata.h|  6904 --
 src/image_data/background_tall.png |   Bin 62133 -> 60113 bytes
 src/image_data/background_tall_pixdata.h   | 12447 ---
 src/image_data/bnc_cable.png   |   Bin 8839 -> 7463 bytes
 src/image_data/bnc_cable_pixdata.h |   716 --
 src/image_data/bsd.png |   Bin 15687 -> 14742 bytes
 src/image_data/bsd_pixdata.h   |  1712 ---
 src/image_data/clock.png   |   Bin 14686 -> 12914 bytes
 src/image_data/clock_pixdata.h |  1422 ---
 

Bug#920371: telnetd-ssl: SSL_CTX_use_certificate, ee key too small

[Brian Minton]

Package: telnetd-ssl
Version: 0.17.41+0.2-3.1
Severity: normal

Dear Maintainer,

I installed telnetd-ssl.  It generated a key and self-signed certificate
in /etc/telnetd-ssl/telnetd.pem, which has 1024 bit RSA key.  This
caused an error when attempting to connect:

$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Error loading CRT /etc/telnetd-ssl/telnetd.pem: SSL_CTX_use_certificate,
ee key too small
do_ssleay_init() failed
140636104001344:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee
key too small:../ssl/ssl_rsa.c:310:
Connection closed by foreign host.


I can see that there's a generated cnf file too, which includes the line
default_bits= 1024


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

Versions of packages telnetd-ssl depends on:
ii  adduser   3.118
ii  libc6 2.28-5
ii  libssl1.1 1.1.1a-1
ii  openbsd-inetd [inet-superserver]  0.20160825-3
ii  openssl   1.1.1a-1
ii  passwd1:4.5-1.1

telnetd-ssl recommends no packages.

telnetd-ssl suggests no packages.

-- no debconf information

Bug#920370: python3-unbound: unboundmodule not working

[Scott Kitterman]

Package: python3-unbound
Version: 1.8.1-1
Severity: important

The python/python3-unbound packages ship both unbound and unboundmodule python
modules.  The unbound module seems to work (because the swig build for the
compile part is executed and then it is installed).  Currenlty though
unboundmodule is completely non-functional.  This is up to date sid:

Python 3.7.2 (default, Jan  3 2019, 02:55:40)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import unboundmodule
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/unboundmodule.py", line 14, in 
swig_import_helper
return importlib.import_module(mname)
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1006, in _gcd_import
  File "", line 983, in _find_and_load
  File "", line 965, in _find_and_load_unlocked
ModuleNotFoundError: No module named '_unboundmodule'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/unboundmodule.py", line 17, in 
_unboundmodule = swig_import_helper()
  File "/usr/lib/python3/dist-packages/unboundmodule.py", line 16, in 
swig_import_helper
return importlib.import_module('_unboundmodule')
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named '_unboundmodule'

The same error occurs with python2.7, the only variation is that paths in the
error message are, of course, different.

Looking at the source, I see compilable code in pythonmod directory that looks
like it is intended to provide the missing _unboundmodule, but I don't see a
functional Makefile to build it (i.e. like libunbound/python/Makefile).

It looks to me like the 'unbound' module wraps libunbound while
'unboundmodule' is meant to wrap the unbound application, so they both look
useful.

It would be nice to make unboundmodule work, but if it's not going to work,
the package shouldn't ship it.  My swig knowledge is approximately zero, so I
was unable to come up with a proper solution.

Scott K

Bug#897275: closed by Sylvestre Ledru (wontfix)

[Helmut Grohne]

Control: reopen -1

On Thu, Jan 24, 2019 at 07:36:12AM +, Debian Bug Tracking System wrote:
> tag 897275 wontfix
> thanks
> 
> I am not planning to fix that currently.
> S

Ok. I still need the open bug number to track the (non-)progress of this
issue. The bug is used to mask tests and thus avoids wasting qa time.

Helmut

Bug#920364: [debian-mysql] Bug#920364: libmariadb-dev: dpkg unpack error when coinstalling

[Helmut Grohne]

Hi Otto,

On Thu, Jan 24, 2019 at 09:30:11PM +0200, Otto Kekäläinen wrote:
> Thanks for reporting!
> 
> This is a duplicate of issue reported in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863675#89 (and used
> to reopen that issue) and has been fixed and uploaded about 1 hour ago
> :)

#863675 is about upgrading. This one (#920364) is about coinstallation.
These are separate issues with separate causes and separate fixes. Not
related at all.

If you read the error messages from dpkg, you'll note that they're
completely different.

Helmut

Bug#920369: boost1.62: do not release with buster

[Mattia Rizzolo]

Source: boost1.62
Severity: serious

An RC bug to keep boost 1.62 out of testing once we manage to get it
out.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#882395: still seeing this in buster

[Hans-Christoph Steiner]

I'm still seeing this in buster, using:

apache2  2.4.37-1
certbot  0.28.0-1

Bug#920368: texlive-pictures: tikz fails in pgf

[Roland Rosenfeld]

Package: texlive-pictures
Version: 2018.20190122-1
Severity: important

On upgrade from 2018.20181214-1 to 2018.20190122-1 the testsuite of
fig2dev package fails.

The root cause for this seems to be in a change of pgf code.

The fig2dev testsuite runs

$ tex test.tex

with the following test.tex input file:

--- snipp -
\input tikz
\bye
--- snipp -

with the old version this runs without problems, while with the
current version this fails with the following output:

--- snipp -
$ tex test.tex
This is TeX, Version 3.14159265 (TeX Live 2019/dev/Debian) (preloaded 
format=tex)
(./test.tex (/usr/share/texlive/texmf-dist/tex/plain/pgf/frontendlayer/tikz.tex
(/usr/share/texlive/texmf-dist/tex/plain/pgf/basiclayer/pgf.tex
(/usr/share/texlive/texmf-dist/tex/plain/pgf/utilities/pgfrcs.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-common.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-common-lists.t
ex)) (/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-plain.def
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/atbegshi.sty
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty)
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty)))
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfrcs.code.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/pgf.revision.tex)))
(/usr/share/texlive/texmf-dist/tex/plain/pgf/basiclayer/pgfcore.tex
(/usr/share/texlive/texmf-dist/tex/plain/pgf/systemlayer/pgfsys.tex
(/usr/share/texlive/texmf-dist/tex/plain/pgf/utilities/pgfrcs.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsys.code.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeysfiltered.code.t
ex))
! Undefined control sequence.
\pgfkeyssetevalue ...gfkeys@temptoks =\scantokens
  \expandafter {\expandafter...

\pgfkeys@ifcsname ...\fi \ifpgfkeys@csname@test #2
  \else #3\fi
\pgfkeys@ifcsname ...gfkeys@csname@test #2\else #3
  \fi
\pgfkeys@ifcsname ...gfkeys@csname@test #2\else #3
  \fi
\pgfkeys@unpack ...pgfeov \else \pgfkeys@case@one
  \fi \fi
\pgfkeys@@normal ...pgfkeysnovalue =\pgfkeys@stop
  \pgfkeys@parse
...
l.17 \pgfkeys{/pgf/.is family}

?
--- snipp -

I'm not deep enough in TeX to understand what this means, but since
the input file is quite minimal and the behavior changed in a quite
bad way on upgrade, I think that this is a bug in the new texlive
distribution...

Greetings
Roland

Bug#920367: RM: gcj-6 gcj-6-jdk gcj-6-jre gcj-6-jre-headless libgcj17 libgcj17-awt libgcj17-dbg libgcj17-dev gcj-jdk gcj-jre gcj-jre-headless libgcj-bc gcj-6-source gcj-6-jre-lib --NBS; no longer buil

[Mattia Rizzolo]

Package: ftp.debian.org

These binaries are old cruft, that come from both gcc-defaults and
gcc-6, they seem to depend on each other and are not getting
auto-decrufted (also because gcj-6-source and gcj-6-jre-lib are arch:all
and the cruft-report is not even noticing them…).

Removing them all in a single run does not show any dependency issue so
please remove them that way.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#920259: libpgm-dev: pkg-config adds include to non-existing directory

[Luca Boccassi]

On Thu, 2019-01-24 at 19:31 +0100, László Böszörményi (GCS) wrote:
> On Thu, Jan 24, 2019 at 7:27 PM Luca Boccassi 
> wrote:
> > On Wed, 23 Jan 2019 10:48:31 + Luca Boccassi 
> > wrote:
> > > Upstream's pkg-config file adds a -I flag to a non-
> > > existing /usr/lib/x86_64-linux-gnu/pgm-5.2/include directory:
> > > 
> > > $ pkg-config --cflags openpgm-5.2
> > > -I/usr/include/pgm-5.2 -I/usr/lib/x86_64-linux-gnu/pgm-
> > > 5.2/include
> > > 
> > > This unfortunately breaks programs that use strict compiler
> > > flags.
> > > 
> > > The patch is very simple and attached, submitted upstream as:
> > > 
> > > https://github.com/steve-o/openpgm/pull/57
> 
>  As I've seen yesterday, it contains other changes as well. Wanted to
> discuss it with its maintainer if s/he is going to do a new release
> or
> how important the individual changes are.

I see, sorry for being insistent - got a bunch of stuff borken :-)

> > If there are no objections I will do a NMU to DELAYED/1 tomorrow
> > morning, with priority high, so that the fixed version can reach
> > buster
> > early next week and fix the FTBFSes.
> 
>  OK, I'll skip other changes and going to do a normal upload soon
> with
> the change you proposed only.
> 
> Thanks,
> Laszlo/GCS

Great, thank you so much!

-- 
Kind regards,
Luca Boccassi

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

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Trek]

On Tue, 22 Jan 2019 18:21:43 -0800
Bill Brelsford  wrote:

> I'm still using version 1.19.2+test2 of dpkg, but without udev's
> --wait-daemon argument.  The next dpkg (1.19.3) will handle
> --wait-daemon; I assume including it in udev will fix the problem..?

these are two independent ways to fix the same issue:
1. modified dpkg to use start-stop-daemon with --notify-await parameter
2. modified udev to use udevadm trigger with --wait-daemon parameter

actually I don't know if the dpkg will be released with these
modifications in time for buster release

thanks to the work done by Michael Biebl, udev developers added the
--wait-daemon parameter


> Unfortunately, I'm not set up to re-compile so can't test your
> patches.

I can provide you a binary package with these patches applied, but it's
not a good security practice to install a package, that runs as root, if
it does not come from the package maintainers


if you want try to patch and compile yourself, you should type as root:

  apt install build-essential fakeroot

  echo 'deb-src http://httpredir.debian.org/debian buster main' \
>>/etc/apt/sources.list

  apt-get update

  LANG=C apt-get -s build-dep systemd | \
sed '/^ /!bA;H;$bA;d;:A;x;/The following NEW/!d;s/^The .*:\n//' \
>>/root/build-packages.txt

  apt-get build-dep systemd


then as a normal user, download the attached patch into your home
directory and type:

  mkdir ~/debian

  cd ~/debian

  apt-get source systemd

  cd systemd-240

  patch -p1 <~/udev-wait-daemon-full.patch

  dpkg-buildpackage -b -uc -us


finally you can install the binary package and remove the development
packages, as root:

  dpkg -i /home/user/debian/udev_240-4_i386.deb

  apt-get purge $(cat /root/build-packages.txt)

  apt-get purge build-essential fakeroot


for more info see https://wiki.debian.org/BuildingTutorial

thanks for your time!
ciaodiff -urN systemd-240/debian/udev.init systemd-240-new/debian/udev.init
--- systemd-240/debian/udev.init	2019-01-12 21:49:44.0 +0100
+++ systemd-240-new/debian/udev.init	2019-01-24 19:17:47.727632051 +0100
@@ -178,7 +178,7 @@
 fi
 
 log_action_begin_msg "Synthesizing the initial hotplug events (subsystems)"
-if udevadm trigger --type=subsystems --action=add; then
+if udevadm trigger --type=subsystems --action=add --wait-daemon; then
 log_action_end_msg $?
 else
 log_action_end_msg $?
diff -urN systemd-240/man/udevadm.xml systemd-240-new/man/udevadm.xml
--- systemd-240/man/udevadm.xml	2018-12-21 19:53:33.0 +0100
+++ systemd-240-new/man/udevadm.xml	2019-01-24 19:17:47.687632051 +0100
@@ -319,6 +319,14 @@
 the same command to finish.
   
 
+
+  --wait-daemon[=SECONDS]
+  
+Before triggering uevents, wait for systemd-udevd daemon to be initialized.
+Optionally takes timeout value. Default timeout is 5 seconds. This is equivalent to invoke
+invoking udevadm control --ping before udevadm trigger.
+  
+
 
 
   
diff -urN systemd-240/src/udev/udev-ctrl.c systemd-240-new/src/udev/udev-ctrl.c
--- systemd-240/src/udev/udev-ctrl.c	2018-12-21 19:53:33.0 +0100
+++ systemd-240-new/src/udev/udev-ctrl.c	2019-01-24 19:20:06.647633460 +0100
@@ -213,7 +213,7 @@
 
 DEFINE_TRIVIAL_REF_UNREF_FUNC(struct udev_ctrl_connection, udev_ctrl_connection, udev_ctrl_connection_free);
 
-static int ctrl_send(struct udev_ctrl *uctrl, enum udev_ctrl_msg_type type, int intval, const char *buf, int timeout) {
+static int ctrl_send(struct udev_ctrl *uctrl, enum udev_ctrl_msg_type type, int intval, const char *buf, usec_t timeout) {
 struct udev_ctrl_msg_wire ctrl_msg_wire;
 int err = 0;
 
@@ -246,7 +246,7 @@
 
 pfd[0].fd = uctrl->sock;
 pfd[0].events = POLLIN;
-r = poll(pfd, 1, timeout * MSEC_PER_SEC);
+r = poll(pfd, 1, DIV_ROUND_UP(timeout, USEC_PER_MSEC));
 if (r < 0) {
 if (errno == EINTR)
 continue;
@@ -267,35 +267,35 @@
 return err;
 }
 
-int udev_ctrl_send_set_log_level(struct udev_ctrl *uctrl, int priority, int timeout) {
+int udev_ctrl_send_set_log_level(struct udev_ctrl *uctrl, int priority, usec_t timeout) {
 return ctrl_send(uctrl, UDEV_CTRL_SET_LOG_LEVEL, priority, NULL, timeout);
 }
 
-int udev_ctrl_send_stop_exec_queue(struct udev_ctrl *uctrl, int timeout) {
+int udev_ctrl_send_stop_exec_queue(struct udev_ctrl *uctrl, usec_t timeout) {
 return ctrl_send(uctrl, UDEV_CTRL_STOP_EXEC_QUEUE, 0, NULL, timeout);
 }
 
-int udev_ctrl_send_start_exec_queue(struct udev_ctrl *uctrl, int timeout) {
+int udev_ctrl_send_start_exec_queue(struct udev_ctrl *uctrl, usec_t timeout) {
 return ctrl_send(uctrl, UDEV_CTRL_START_EXEC_QUEUE, 0, NULL, timeout);
 }
 
-int udev_ctrl_send_reload(struct udev_ctrl *uctrl, int timeout) {
+int 

Bug#920350: ITP: pkg-js-autopkgtest -- collection of autopktest scripts for nodejs packages

[Paul Gevers]

Oops,

On 24-01-2019 20:09, Paul Gevers wrote:
> Hi Xavier,
> 
> On 24-01-2019 15:25, Xavier Guimard wrote:
>> Packages using the tests with autopkgtests in this package will simply
>> have to set "Testsuite: autopkgtest-pkg-js" in debian/control and write
>> upstream test in debian/tests/pkg-js/test. This package provides also a
>> test.mk file which can be include in debian/rule to avoid writing a
>> override_dh_auto_test. The same test will be launched.
>>
>> This package is inspired from pkg-perl-autopkgtest. If accepted, a MR
>> will be done on autodep8 project to include it.
> 
> I am not sure if you are aware, but please make sure that anything that
> a maintainer adds about test dependencies is recorded in
> debian/tests/control. dpkg-source exports the content of the "Depends"
> fields to the changes file where it is picked up by britney, the
> migration software.

Another thing, autodep8 already has support for nodejs. If your scripts
are smarter (which they probably are), could you please replace (instead
of add) the current nodejs support? I.e. it would be "Testsuite:
autopkgtest-pkg-nodejs". Let's not have two nodejs supports in autodep8.

Paul

Bug#920350: ITP: pkg-js-autopkgtest -- collection of autopktest scripts for nodejs packages

[Paul Gevers]

Hi Xavier,

On 24-01-2019 15:25, Xavier Guimard wrote:
> Packages using the tests with autopkgtests in this package will simply
> have to set "Testsuite: autopkgtest-pkg-js" in debian/control and write
> upstream test in debian/tests/pkg-js/test. This package provides also a
> test.mk file which can be include in debian/rule to avoid writing a
> override_dh_auto_test. The same test will be launched.
> 
> This package is inspired from pkg-perl-autopkgtest. If accepted, a MR
> will be done on autodep8 project to include it.

I am not sure if you are aware, but please make sure that anything that
a maintainer adds about test dependencies is recorded in
debian/tests/control. dpkg-source exports the content of the "Depends"
fields to the changes file where it is picked up by britney, the
migration software.

Paul