Bug#888955: open-vm-tools.service 10.2.0 does not start on boot on jessie/stretch/etc

[Patrick Matthäi]

Am 31.01.2018 um 22:51 schrieb Bernd Zeimetz:
>> # systemctl status open-vm-tools.service
>> ● open-vm-tools.service - Service for virtual machines hosted on VMware
>>    Loaded: loaded (/lib/systemd/system/open-vm-tools.service; enabled)
>>    Active: failed (Result: resources)
>>  Docs: http://open-vm-tools.sourceforge.net/about.php
> please provide some more information - add
>
> [logging]
> log = true
> vmtoolsd.level = debug
> vmtoolsd.handler = file
>
>
> to
> /etc/vmware-tools/tools.conf and restart the service.

Added

>
>
> Then check /var/log/vmware-vmtoolsd.log.
>
> The other vmware logs might be interesting, too.
> Also please give power-cycling the VM a try.

Hi,

maybe I didn't wrote it very well. If I start the service after boot
manualy "service open-vm-tools start" it works, but not on restarting
the VM, it does not come up :/

Also with the tools.conf changes no log for the boot itself, also
nothing in journalcl

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#888957: linuxbrew-wrapper: Linuxbrew formulas may build or install non-free software

[Adrian Bunk]

Control: retitle -1 linuxbrew-wrapper should go to contrib: It is an installer 
for linuxbrew
Control: found -1 20150804-1

On Wed, Jan 31, 2018 at 10:38:42AM -0500, John Scott wrote:
> Package: linuxbrew-wrapper
> Version: 20170516-2
> Severity: serious
> Justification: Policy 2.2.1
> 
> Though the linuxbrew-wrapper package is free just as Linuxbrew is, Linuxbrew 
> does not commit to only free software. Linuxbrew's OpenCV formula builds with 
> -DOPENCV_ENABLE_NONFREE=ON, and FFmpeg builds with --enable-nonfree. Though a 
> comment in ffmpeg.rb notes that the flag produces unredistributable binaries, 
> no notice is given to the user.
> 
> Users that commit to only using free software may install this package and 
> believe that it is free because it is in main. Though the package is free, 
> and Linuxbrew is free, the purpose of Linuxbrew and this wrapper package is 
> to install software from outside of the Debian repository (some of which is 
> non-free).

With that logic apt would also have to go to contrib.

> I believe that this violates Debian Policy that packages in main "must not 
> require or recommend a package outside of main for compilation or execution."

The accepted interpretation of that section of policy is that a program 
can be in main as long as there is some way to use it with free software.

Additional optional uses with non-free software are fine.

> Because this package is a wrapper that will "invoke upstream install script 
> if found no linuxbrew instance" upon installation, I believe package is not 
> suited for main and is probably better suited for contrib. The Debian Policy 
> Manual says that packages that would be included in contrib include "wrapper 
> packages or other sorts of free accessories for non-free programs." Linuxbrew 
> is a wrapper for installing (with or without building from source) programs 
> that, though many of them are free, some are not.

This is actually a reason why it should be in contrib:
The package is just an installer that downloads the actual program.

cu
Adrian

-- 

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

Bug#889008: output for binaries-general test case on armhf changed

[Matthias Klose]

Package: src:lintian
Version: 2.5.72

seen with the launchpad autopkg tests and binutils 2.30:

tests::binaries-general: diff -u t/tests/binaries-general/tags
/tmp/autopkgtest.vLMxRU/autopkgtest_tmp/testsuite/tests/binaries-general/tags.binaries-general
--- t/tests/binaries-general/tags   2018-01-26 05:17:01.0 +
+++
/tmp/autopkgtest.vLMxRU/autopkgtest_tmp/testsuite/tests/binaries-general/tags.binaries-general
2018-02-01 00:53:43.350786126 +
@@ -6,7 +6,6 @@
 E: binaries-general: library-in-debug-or-profile-should-not-be-stripped
usr/lib/debug/usr/share/foo/basic
 E: binaries-general: statically-linked-binary usr/bin/static
 E: binaries-general: unstripped-binary-or-object usr/bin/unstripped
-W: binaries-general: binary-compiled-with-profiling-enabled usr/share/foo/basic
 W: binaries-general: binary-without-manpage usr/bin/static
 W: binaries-general: binary-without-manpage usr/bin/unstripped
 W: binaries-general: debug-file-should-use-detached-symbols
usr/lib/debug/.build-id/de/deadbeefdeadbeef.debug
fail tests::binaries-general: output differs!

it looks like this still succeeds on arm64, x86, ppc64el and s390x.

Bug#887688: [debhelper-devel] Bug#887688: debhelper: empty build of src:ck

[Adrian Bunk]

On Wed, Jan 31, 2018 at 07:11:00PM +, Niels Thykier wrote:
> clone 887688 -1
> retitle -1 debhelper: dh_makeshlibs --no-act isn't and causes FTBFS
> tags 887688 pending
> thanks
> 
> Hi,
> 
> Assuming I have not overlooked something, then I believe this bug is now
> resolved in debhelper and will close it in a few days.  This is because:
> 
>  * I have filed bugs for all known packages that currently FTBFS due to
>empty or incomplete targets (usually caused by .PHONY).  Most of
>these have a patch attached.
> 
>  * The autoreconf related issue was solved in dh-autoreconf/16, which
>solved the problems in some of the originally listed packages.
>(See #887482)
> 
>  * There was a regression in the --no-act that caused a single FTBFS.
>This has a patch in debhelper master that has yet to be uploaded
>(I just cloned this bug for that purpose).
> 
> 
> Overview of the packages mentioned in this bug report
> =

Thanks a lot for doing this.

> Packages that has an open RC bug related to this issue:
> 
>  * apr: #888593 (patch)
>  * ck: #888591 (patch)
>  * cpputest: #888598 (patch)
>  * debian-handbook: #888578 (patch)
>  * iaxmodem: #888601 (patch)
>  * moarvm: #888582 (patch)
>  * jscommunicator: #888579 (patch)
>  * libtemplate-perl: #888663 (patch)
>  * monotone: #888612 (patch)
>...

One new .PHONY case that needs a bug:
  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apr-util.html

> Thanks,
> ~Niels

Thanks
Adrian

-- 

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

Bug#889007: sqlparse: autopkgtest failure

[Graham Inggs]

Source: sqlparse
Version: 0.2.2-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Hi Maintainer

Since 2017-12-14, sqlparse's autopkgtests have been failing [1] with
the following error:

autopkgtest [15:35:15]: test python3-sqlparse: [---
/tmp/autopkgtest-lxc.0huf2ixv/downtmp/build.DAd/src/debian/tests/python3-sqlparse:
5: 
/tmp/autopkgtest-lxc.0huf2ixv/downtmp/build.DAd/src/debian/tests/python3-sqlparse:
2to3: not found
autopkgtest [15:35:15]: test python3-sqlparse: ---]
autopkgtest [15:35:15]: test python3-sqlparse:  - - - - - - - - - -
results - - - - - - - - - -
python3-sqlparse FAIL non-zero exit status 127

In case it is helpful, this date corresponds with an upload of
python3-defaults to unstable.

Regards
Graham


[1] https://ci.debian.net/packages/s/sqlparse/unstable/amd64/

Bug#888805: Also provide a non-Xwindows plain CLI version

[Yavor Doganov]

積丹尼 Dan Jacobson wrote:
> But I will be happy to run any tests you would like me to do to see
> what is the problem.

Your problem is that you are using experimental, which pulls in gcc-8
which in turn forces the removal of dkms for some reason.  Why this
happens is for you to analyze -- experimental is for experienced
users, it is not self-contained and there is no guarantee that
packages are installable all the time.  You can try to run `apt-get
update', it may fix the problem.  Or not.

The unar package doesn't depend on X libraries, this is obvious by
looking at its Depends: field.

Bug#889004: [3dprinter-general] Bug#889004: cura-engine: autopkgtest failure

[Gregor Riepl]

Hi Graham

> Since the upload of 1:3.1.0-1, cura-engine's autopkgtests have been
> failing [1] with the following error:
> 
> [ERROR] Trying to retrieve unregistered setting with no value given:
> 'slicing_tolerance'
> info: test exiting
> autopkgtest [23:15:10]: test test-command-line: ---]
> autopkgtest [23:15:10]: test test-command-line:  - - - - - - - - - -
> results - - - - - - - - - -
> test-command-lineFAIL non-zero exit status 253

Thanks for the report.

Looks like our test profile stopped working at some point.
I wonder why I didn't hit that error?
Maybe something is wrong with the test evaluation?

In any case, I'll try to update/fix the profile.
But perhaps the test needs to rewritten completely...

Regards,
Greg

Bug#889005: mm3d FTBFS on armel/armhf: error: OpenGL (with GLU) is required

[Adrian Bunk]

Source: mm3d
Version: 1.3.9-1
Severity: serious

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

...
checking for OpenGL... yes
checking for Qt... yes:
QT_CXXFLAGS=-I/usr/include/arm-linux-gnueabi/qt5
QT_DIR=
QT_LIBS=-L/usr/lib/arm-linux-gnueabi/qt5 -lQt5Core -lQt5Gui -lQt5Widgets 
-lQt5OpenGL -lQt5Network 
QT_UIC=/usr/lib/arm-linux-gnueabi/qt5/bin/uic
QT_MOC=/usr/lib/arm-linux-gnueabi/qt5/bin/moc
QT_LRELEASE=/usr/lib/arm-linux-gnueabi/qt5/bin/lrelease
checking correct functioning of Qt installation... success
checking Qt OpenGL... success
checking for x11 fonts... no
checking for gettimeofday... yes

configure: error: OpenGL (with GLU) is required.


Ideally it should be made working when Qt is using
OpenGL ES, but if that is not possible please:
- change the build dependency from libqt5opengl5-dev
  to libqt5opengl5-desktop-dev, and
- submit a bug against ftp.debian.org asking for the
  removal of the old armel+armhf binaries from unstable

Bug#889006: dh-autoreconf is run before patching

[Adrian Bunk]

Package: debhelper,dh-autoreconf
Severity: serious
Control: found -1 16
Control: affects -1 src:dansguardian

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

...
   dh_autoreconf
configure.ac:14: installing './compile'
src/Makefile.am:13: warning: source file 'contentscanners/clamav.cpp' is in a 
subdirectory,
src/Makefile.am:13: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding 
output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same 
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
src/Makefile.am:31: warning: source file 'contentscanners/icapscan.cpp' is in a 
subdirectory,
src/Makefile.am:31: but option 'subdir-objects' is disabled
src/Makefile.am:39: warning: source file 'contentscanners/kavdscan.cpp' is in a 
subdirectory,
src/Makefile.am:39: but option 'subdir-objects' is disabled
src/Makefile.am:25: warning: source file 'contentscanners/clamdscan.cpp' is in 
a subdirectory,
src/Makefile.am:25: but option 'subdir-objects' is disabled
src/Makefile.am:43: warning: source file 'contentscanners/commandlinescan.cpp' 
is in a subdirectory,
src/Makefile.am:43: but option 'subdir-objects' is disabled
src/Makefile.am:48: warning: source file 'downloadmanagers/default.cpp' is in a 
subdirectory,
src/Makefile.am:48: but option 'subdir-objects' is disabled
src/Makefile.am:53: warning: source file 'downloadmanagers/fancy.cpp' is in a 
subdirectory,
src/Makefile.am:53: but option 'subdir-objects' is disabled
src/Makefile.am:57: warning: source file 'downloadmanagers/trickle.cpp' is in a 
subdirectory,
src/Makefile.am:57: but option 'subdir-objects' is disabled
src/Makefile.am:62: warning: source file 'authplugins/proxy.cpp' is in a 
subdirectory,
src/Makefile.am:62: but option 'subdir-objects' is disabled
src/Makefile.am:63: warning: source file 'authplugins/ident.cpp' is in a 
subdirectory,
src/Makefile.am:63: but option 'subdir-objects' is disabled
src/Makefile.am:64: warning: source file 'authplugins/ip.cpp' is in a 
subdirectory,
src/Makefile.am:64: but option 'subdir-objects' is disabled
src/Makefile.am:70: warning: source file 'authplugins/ntlm.cpp' is in a 
subdirectory,
src/Makefile.am:70: but option 'subdir-objects' is disabled
src/Makefile.am:65: warning: source file 'authplugins/digest.cpp' is in a 
subdirectory,
src/Makefile.am:65: but option 'subdir-objects' is disabled
   dh_dpatch_patch
applying patch 03_add_unconfigures to ./ ... ok.
applying patch 07_fix_config_paths to ./ ... ok.
applying patch 11_FixOptionContainer.cpp_on_arm to ./ ... ok.
applying patch 50_clamav095_support to ./ ... ok.
applying patch 60_add_gcc4.4_support to ./ ... ok.
applying patch 65-fix_clamdsocket to ./ ... ok.
applying patch 70-gcc4.6 to ./ ... ok.
applying patch 70_fix_clamav_detection to ./ ... ok.
applying patch 80_fix_libcre3_max_sub_expression_allocation to ./ ... ok.
...
checking for CLAMAV... no
configure: error: Package requirements (libclamav >= 4) were not met:

Requested 'libclamav >= 4' but version of libclamav is 0.99.3-beta2


This is caused by:


dh-autoreconf (16) unstable; urgency=medium
...
  * Run dh_autoreconf after dh_update_autotools_config,
not before dh_auto_configure

Bug#888126: [patch] Please enable systemd-sysusers unit

[Michael Vogt]

Hi,

just a small update on this. systemd git master has the needed support
to reproduce the base-passwd passwd and group files now. The sysuers.d
conf file for this looks like this:

   
https://github.com/systemd/systemd/blob/master/test/TEST-21-SYSUSERS/test-5.input

and it generates output like this:

   
https://github.com/systemd/systemd/blob/master/test/TEST-21-SYSUSERS/test-5.expected-passwd
   
https://github.com/systemd/systemd/blob/master/test/TEST-21-SYSUSERS/test-5.expected-group

The only remaining problem is that it generates /sbin/nologin which we
do not have (we use /usr/sbin/nologin). But IMO that is not a blocker
we could make it a problem of the user (by recommending to the users
to create a symlink) - it may go away if UsrMerge takes off.

Cheers,
 Michael

Bug#888989: temp fix

[Paolo Greppi]

For temporary fix see: https://bugs.debian.org/887069#12

On sid with node-node-uuid 1.4-7-1 I did:

cd /usr/lib/nodejs/node-uuid/
sudo rm index.js
sudo ln -s ../../../share/javascript/node-uuid/uuid.js index.js
cd
npm2deb search monocle

and it worked.

BTW, this bug is probably a duplicate of 887069

Paolo

Bug#860503: libxcursor1: suggest /etc/alternatives/x-cursor-theme of the standard cursors

[Kevin Ryde]

Drew Parsons  writes:
>
> But you're asking for the core theme to be offered by a core
> X package,

Yes.  The core cursors live in some base part of the core and I think
could express their availability, as a theme, somewhere there.

> xcursor-themes is optional.

Ah, I don't think I knew it included core as a theme.  I'd say
/etc/X11/cursors/core.theme could be in a more base package.

> We could set this up in the
> postinst script of a X11 base package (libxcursor1 could be a
> reasonable choice, otherwise xorg, xserver-xorg or xserver-xorg-core),

Oh, now I'm not sure I know who actually reads the alternative.  The
server on reset?  All client programs (through libxcursor1)?

> But even then it would not solve your problem: xcursor-themes is
> priority 30 while adwaita-icon-theme is priority 90.

That's ok.  It's probably proper for an add-on to be above the core,
since installing it usually means you want it (though that's not the
case with adwaita - it being brought in for the pics in gtk programs but
then puts global cursors).

Bug#888787: dpkg-source: mention when picking up an upstream signature

[Mattia Rizzolo]

On Thu, Feb 01, 2018 at 02:37:13AM +0100, Guillem Jover wrote:
> > I'd like for dpkg-source to mention that it detected an .asc (probably
> > another "using existing" line?)
> 
> Right! Fixed this now locally.

Thanks!
(shouldn't you `tag -1 pending` this bug?)

> > On a related note, what does that "info: applying version" line mean? :)
> 
> Ah, that'd be a patch called just «version». :)

A stupid me.  Of course!
I see that line so many times that I forgot dpkg-source mentions patches
applied/unapplied…

> Perhaps a lintian check is in order?

To have peple call the patch files with a .diff or .patch extension?
I'd rather not, let's not introduce unecessary requirements.
This one was just me using a really generic name, but I tend to use
patch files 'fix_ftbfs_with_boost1.58' without .diff/.patch, and I find
them fine.


> I might try to improve the message, the problem is that too much text
> will make the line wrap, and for common cases with things like fo
> .diff or foo.patch saying something like:
> 
>   dpkg-source: info: applying patch "foo.patch"
> 
> would seem also a bit redundant?

Right.  Just forget and leave it there :)

-- 
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#888484: [Pkg-clamav-devel] Bug#888484: Updates for stretch/jessie not in security repo

[Salvatore Bonaccorso]

Hi Scott,

On Wed, Jan 31, 2018 at 10:57:30PM -0500, Scott Kitterman wrote:
> On Thursday, February 01, 2018 01:03:29 AM Matija Nalis wrote:
> > nor does debian security tracker list the updates as available for
> > jessie/stretch:
> > https://security-tracker.debian.org/tracker/source-package/clamav
> > 
> > (security-tracked does say in hover text that jessie
> > "gets updated via -updates", so it should pick that up)
> > 
> > it correctly reports wheezy, buster and sid as fixed.
> > 
> > for example, see also
> > https://security-tracker.debian.org/tracker/CVE-2017-12376
> > 
> > this looks to me also like something that should be fixed (somewhere)?
> 
> By design, the security tracker doesn't consider things 'fixed' in stable via 
> updates until after it's included in a Debian point release.  I agree it's 
> not 
> totally clear, but the way it's working is what the security team intends.

JFTR, yes that's correct. As a side node, we might need to look into
starting -updates and consider what is there to be 'accepted' for
stable (oldstable) already by the stable release managers. This would
need some work on the security-tracker side which would not support
that yet. Will think about it.

Regards,
Salvatore

Bug#889004: cura-engine: autopkgtest failure

[Graham Inggs]

Source: cura-engine
Version: 1:3.1.0-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Hi Maintainer

Since the upload of 1:3.1.0-1, cura-engine's autopkgtests have been
failing [1] with the following error:

[ERROR] Trying to retrieve unregistered setting with no value given:
'slicing_tolerance'
info: test exiting
autopkgtest [23:15:10]: test test-command-line: ---]
autopkgtest [23:15:10]: test test-command-line:  - - - - - - - - - -
results - - - - - - - - - -
test-command-lineFAIL non-zero exit status 253

Regards
Graham


[1] https://ci.debian.net/packages/c/cura-engine/unstable/amd64/

Bug#889003: netgen FTBFS with libtogl-dev 2.0-1

[Adrian Bunk]

Source: netgen
Version: 4.9.13.dfsg-11
Severity: serious

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

...
libtool: link: g++ -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -rdynamic -Wl,-z 
-Wl,relro -o netgen demoview.o ngappinit.o ngpkg.o onetcl.o nginterface.o 
nginterface_v2.o parallelfunc.o parallelinterface.o  
../libsrc/visualization/libvisual.a ../libsrc/csg/.libs/libcsg.a 
../libsrc/geom2d/.libs/libgeom2d.a ../libsrc/interface/.libs/libinterface.a 
../libsrc/stlgeom/.libs/libstl.a ../libsrc/occ/.libs/libocc.a 
../libsrc/meshing/.libs/libmesh.a ../libsrc/gprim/.libs/libgprim.a 
../libsrc/linalg/.libs/libla.a ../libsrc/general/.libs/libgen.a -L/usr/lib 
-lTKernel -lTKGeomBase -lTKMath -lTKG2d -lTKG3d -lTKXSBase -lTKOffset 
-lTKFillet -lTKShHealing -lTKMesh -lTKMeshVS -lTKTopAlgo -lTKGeomAlgo -lTKBool 
-lTKPrim -lTKBO -lTKIGES -lTKBRep -lTKSTEPBase -lTKSTEP -lTKSTL -lTKSTEPAttr 
-lTKSTEP209 -lTKXDESTEP -lTKXDEIGES -lTKXCAF -lTKLCAF -lFWOSPlugin 
-L/usr/lib/tk8.5/Togl1.7 -lTogl -lGLU -L/usr/lib/x86_64-linux-gnu -ltk8.5 
-ltcl8.5 -ljpeg -lGL
  -lXmu -lpthread
ngpkg.o: In function `Ng_Init':
./ng/ngpkg.cpp:5228: undefined reference to `Togl_CreateFunc'
./ng/ngpkg.cpp:5229: undefined reference to `Togl_DestroyFunc'
./ng/ngpkg.cpp:5230: undefined reference to `Togl_DisplayFunc'
./ng/ngpkg.cpp:5231: undefined reference to `Togl_ReshapeFunc'
./ng/ngpkg.cpp:5233: undefined reference to `Togl_CreateCommand'
./ng/ngpkg.cpp:5234: undefined reference to `Togl_CreateCommand'
collect2: error: ld returned 1 exit status
Makefile:526: recipe for target 'netgen' failed
make[3]: *** [netgen] Error 1

Bug#888917: ocrmypdf fails to run it's testsuite

[Sean Whitton]

Hello James,

On Wed, Jan 31 2018, James R Barlow wrote:

> Upstream here.

Thanks for the info.

> The reason the suite fails like that is that mandatory-for-testing
> dependencies were also removed.
>
> The test suite runs on Travis CI in 10-12 minutes. On Debian CI, 15
> minutes. For comparison ffmpeg, another compute intensive CLI program,
> takes 10 minutes.
>
> This is an OCR program and OCR takes a long time. There are
> opportunities to speed up testing on my end but no low hanging fruit
> without removing tests. I've done the obvious: use all cores, use
> caches and dummies where possible. Some OCR on the fly is essential
> because Tesseract is complex enough that output is not identical
> across platforms.
>
> Preserving the dynamically created tests/cache/ folder between test
> runs, if possible in Debian CI, would speed it up a lot.

Unfortunately not possible.

> I could mark a subset of essential tests for packagers so that Debian
> CI can specify it only wants those. There's a number of tests that are
> very unlikely to pass upstream testing (macOS and Ubuntu) then somehow
> fail downstream in Debian.

Just to be clear, this bug is about the tests run during the package
build, which is completely independent of Debian CI (in our terminology,
"autopkgtest" refers to Debian CI).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#888917: ocrmypdf fails to run it's testsuite

[Sean Whitton]

control: tag -1 +moreinfo

Dear Matthias,

On Wed, Jan 31 2018, Matthias Klose wrote:

> The recent changelog reads:
>
>   * Disable test suite at package build time.
> It now takes a prohibitively long time to run, so we are relying on
> autopkgtest instead.
>
> Sorry, but this is one of the most lame excuses I have ever seen. Trying to 
> run
> it on my laptop in unstable needs 30 seconds.  However re-enabling it and
> running it reveals
>
>   === 122 failed, 24 passed, 4 skipped in 33.92 seconds 
>
> these results are after adding tesseract-ocr qpdf unpaper as build 
> dependencies.

Looking at the errors, I strongly suspect that this is because you are
running the test suite on a tmpfs -- we have seen these permission
errors before under those conditions.  Could you try running the test
suite on a totally ordinary file system, please?

I further suspect that the test suite took 30 seconds only because so
many tests failed early.  In recent upstream versions, the test suite
has never finished running on my laptop after leaving it for multiple
hours.  When you run the test suite on a totally ordinary file system,
please report how long it takes, and whether your laptop is very
new/high spec.

I note that Policy does not require that a package be buildable under a
tmpfs, and certainly does not require that its test suite run under a
tmpfs.

> doubting that the primary reason for this change was build time ...

Several things:

1) I ran the test suite using deb-o-matic[1] before uploading.  Needless
   to say, I would not have uploaded had there been failures.

2) I should have mentioned in the changelog that another reason for this
   change was to reduce the number of heavy build dependencies.

   A further reason is that it reduces the amount of fragile code in
   d/rules needed to get the test suite running -- upstream's test suite
   is designed to be run on the installed package.

3) I am of the view that very heavy test suites are better run under
   autopkgtest.  We will soon have testing migration gating on
   autopkgtest, and it is not clear to me that it makes sense for the
   process of stitching the .deb to abort when a single integration test
   fails.

   (Ideally tests would be separated into those that should abort the
   build and those that should not, but in the absence of this work
   being done, it is reasonable not to run any of them.)

4) Your implicit comment that I lied in the changelog and disabled the
   test suite because I knew it would fail is entirely uncalled for.
   Please do not treat fellow package maintainers like that.

[1]  http://debomatic-amd64.debian.net/

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#889002: Simple reboot reminder

[martin f krafft]

Package: linux-base
Version: 4.5
Severity: wishlist

We use the following line from cron to remind us to reboot
a machine, if the initrd for the currently running kernel has been
updated:

  test /proc -nt /boot/initrd.img-$(uname -r) || echo reboot required

Would you be open to the idea to provide such functionality from
linux-base?

I'd be happy to extend it to make it work for systems without
initrd, as well as in the case of kernel version upgrades
(configurable), but I'd want to gauge first if this is the right
place for such a script.

If you don't think linux-base is the place for this, please
reassign.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#889001: stretch-pu: package publicsuffix/20180125.0922-0+deb9u1

[dkg]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 publicsuffix

Please consider an update to publicsuffix in debian stretch.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in stretch is attached.

This proposed release is also available at the
"publicsuffix_debian/20180125.0922-0+deb9u1" tag on the "stretch" branch at the 
git
repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to stretch.



publicsuffix_20171028.2055-0+deb9u1_20180125.0922-0+deb9u1.debdiff.gz
Description: application/gzip

Bug#888484: [Pkg-clamav-devel] Bug#888484: Updates for stretch/jessie not in security repo

[Scott Kitterman]

On Wednesday, January 31, 2018 12:52:35 PM Klaus Keppler wrote:
> Hi,
> 
> is there a special reason why the updates are not published through the
> "security" repositories of Debian Stretch/Jessie?
> 
> - on Debian 7, the update is in "wheezy" (via security)
> - on Debian 8, the update is in "jessie-updates"
> - on Debian 9, the update is in "stretch-updates"
> 
> With regard of the severity of the bug, I can't understand this release
> strategy. Or am I just too impatient?
> 
> Many "sources.list" files do not contain the "-updates" repository, for
> example unmodified Xen instances created with "xen-create-image".
> 
> So I suggest to push this update also into debian-security.
> 
> Thanks for your efforts & best regards

The reason is that typically clamav updates include much more than just 
security fixes (as far as I can recall in roughly a decade of clamav 
maintenance this is the first time it's happened), so are not considered 
suitable for the security repository.

We believe that keeping clamav up to date so that, as a package that provides 
a security service, it is always kept as capable as possible is of overriding 
importance for clamav.

Wheezy is done through 'security' because it's no longer supported by the 
Debian project, but by the Long Term Support team.  The LTS team publishes ALL 
updates (security or not) via the security repository.  For Debian supported 
releases, clamav will always go via updates.

If you are just discovering this now, you've been missing out of clamav 
updates for a long time.  Debian started publishing Stable Update 
Announcements in March, 2011.  The very first clamav stable update 
announcement was published that same month[1].  These clamav updates virtually 
always include security relevant fixes.

Scott K


[1] https://lists.debian.org/debian-stable-announce/2011/03/msg3.html

Bug#888484: [Pkg-clamav-devel] Bug#888484: Updates for stretch/jessie not in security repo

[Scott Kitterman]

On Thursday, February 01, 2018 01:03:29 AM Matija Nalis wrote:
> nor does debian security tracker list the updates as available for
> jessie/stretch:
> https://security-tracker.debian.org/tracker/source-package/clamav
> 
> (security-tracked does say in hover text that jessie
> "gets updated via -updates", so it should pick that up)
> 
> it correctly reports wheezy, buster and sid as fixed.
> 
> for example, see also
> https://security-tracker.debian.org/tracker/CVE-2017-12376
> 
> this looks to me also like something that should be fixed (somewhere)?

By design, the security tracker doesn't consider things 'fixed' in stable via 
updates until after it's included in a Debian point release.  I agree it's not 
totally clear, but the way it's working is what the security team intends.

Scott K

Bug#848102: [octave] crashed with some random typing in octave editor

[Mike Miller]

On Wed, Dec 14, 2016 at 06:44:53 +, lumin wrote:
> Randomly typing something in octave editor will cause
> a crash with SIGSEGV.
> 
> For example, I launched Octave and typed merely "asdfasdf"
> and then octave crashed.

Can you please try with the version of octave currently in testing?
Since this was reported, Octave now uses Qt 5 and it's possible that
this bug only affects an older set of Qt and/or QScintilla libs.

I used to be able to trigger a similar bug by installing qt-at-spi and
setting the QT_ACCESSIBILITY environment variable. But as I understand
it the Qt 5 a11y support has been redesigned.

If octave still crashes for you, please provide your locale, keyboard
layout, and any input method settings.

-- 
mike


signature.asc
Description: PGP signature

Bug#889000: process-cpp: FTBFS on non-Linux: no sys/eventfd.h

[Aaron M. Ucko]

Source: process-cpp
Version: 3.0.1-2
Severity: important
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd

Hi, Chris.

Builds of process-cpp for (non-release) non-Linux architectures
(hurd-i386 so far) have been failing:

  /<>/src/core/posix/child_process.cpp:33:10: fatal error: 
sys/eventfd.h: No such file or directory

Could you please either arrange to support these architectures
(perhaps with somewhat reduced functionality) or formally restrict the
package to linux-any until such time as support for them materializes?

Thanks!

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

Bug#888998: cysignals: FTBFS on hurd-i386, m68k, and sh4: doctests silently fail

[Aaron M. Ucko]

Source: cysignals
Version: 1.6.5+ds-2
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd

Builds of cysignals for hurd-i386, m68k, and sh4 (admittedly not
release architectures) all failed with silent doctest errors:

  Doctesting 4 files.
  src/cysignals/alarm.pyx
  src/cysignals/pselect.pyx
  src/cysignals/pysignals.pyx
  src/cysignals/signals.pyx
  debian/rules:36: recipe for target 'override_dh_auto_test-arch' failed
  make[1]: *** [override_dh_auto_test-arch] Error 1

Perhaps you can obtain more details by reproducing the problem on a
porter box.  Could you please take a look?

Thanks!

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

Bug#888999: unbound-anchor: please move unbound-anchor from /usr/sbin to /usr/bin

[Daniel Kahn Gillmor]

Package: unbound-anchor
Version: 1.6.7-1
Severity: wishlist

the dns-root-data package's debian/rules uses unbound-anchor in its
get_orig_source target.  It currently specifies the path explicitly,
because it shouldn't need to be run as root.

This is a classic example of a program that doesn't need to be run as
root living in /usr/sbin when it should live in /usr/bin.  Let's let
people rely on their standard $PATH without making brittle scripts.
I'm fine with shipping a symlink from /usr/sbin/unbound-anchor so that
we don't break existing brittle scripts, but we shouldn't encourage
creation of more brittle scripts in the first place.

 --dkg


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

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

Versions of packages unbound-anchor depends on:
ii  libc62.26-4
ii  libexpat12.2.5-3
ii  libssl1.11.1.0g-2
ii  libunbound2  1.6.7-1

unbound-anchor recommends no packages.

unbound-anchor suggests no packages.

-- no debconf information

Bug#888997: openfortivpn: FTBFS on non-Linux

[Aaron M. Ucko]

Source: openfortivpn
Version: 1.6.0-1
Severity: important
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd

Builds of openfortivpn for hurd-i386 (admittedly not a release
architecture) have been failing.  Per [1], the immediate problem
appears to be the lack of ERESTART; however, [2] suggests that there
are deeper issues.

Please limit the package's architecture to linux-any until such time
as it supports other kernels.

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=openfortivpn=hurd-i386=1.6.0-1=1516930196=0
[2] https://github.com/adrienverge/openfortivpn/issues/241

-- 
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#888996: dbus-cpp: FTBFS on hppa: DBus.QueryingUnixProcessIdReturnsCorrectResult fails

[Aaron M. Ucko]

Source: dbus-cpp
Version: 5.0.0+18.04.20171031-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hppa

The build of dbus-cpp for hppa (admittedly not a release architecture)
failed as detailed below.  Could you please take a look?

Thanks!

--

 3/15 Test  #4: dbus_test ***Failed0.56 sec
Running main() from gmock_main.cc
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from DBus
[ RUN  ] DBus.QueryingUnixProcessIdReturnsCorrectResult
dbus[6265]: Attempted to unregister path (path[0] = this path[1] = is) which 
isn't registered
core::posix::fork(): An unhandled std::exception occured in the child process:
  what(): org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible 
causes include: the remote application did not send a reply, the message bus 
security policy blocked the reply, the reply timeout expired, or the network 
connection was broken.
   0@0xfd70b7f0: [0xfd70b7f0]
   1@0xfd70b920: [0xfd70b920]
terminate called after throwing an instance of 'std::runtime_error'
  what():  org.freedesktop.DBus.Error.NameHasNoOwner: Could not get PID of name 
':1.1': no such name
/<>/dbus-cpp-5.0.0+18.04.20171031/tests/dbus_test.cpp:123: Failure
  Expected: core::posix::exit::Status::success
  Which is: 4-byte object <00-00 00-00>
To be equal to: client_result.detail.if_exited.status
  Which is: 4-byte object <00-00 00-01>
/<>/dbus-cpp-5.0.0+18.04.20171031/tests/dbus_test.cpp:129: Failure
  Expected: core::posix::wait::Result::Status::exited
  Which is: 4-byte object <00-00 00-02>
To be equal to: service_result.status
  Which is: 4-byte object <00-00 00-03>
/<>/dbus-cpp-5.0.0+18.04.20171031/tests/dbus_test.cpp:131: Failure
  Expected: core::posix::exit::Status::success
  Which is: 4-byte object <00-00 00-00>
To be equal to: service_result.detail.if_exited.status
  Which is: 4-byte object <00-00 00-06>
[  FAILED  ] DBus.QueryingUnixProcessIdReturnsCorrectResult (380 ms)
[--] 1 test from DBus (380 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (380 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] DBus.QueryingUnixProcessIdReturnsCorrectResult

 1 FAILED TEST

[...]

93% tests passed, 1 tests failed out of 15

Total Test time (real) =  16.59 sec

The following tests FAILED:
  4 - dbus_test (Failed)
Errors while running CTest

-- 
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#888491: [Pkg-dns-devel] Bug#888491: bind9: Provide up to date db.root in stable Debian release

[Daniel Kahn Gillmor]

On Fri 2018-01-26 12:08:47 +0100, Witold Baryluk wrote:

> I noticed that db.root is rather old from February 17, 2016;
>
> but newest version on internic is from November 16, 2017.
>
> Notable changes between them:
>
> IPv4 and IPv6 addresses of B.ROOT-SERVERS.NET changed.
>
> IPv6 address added for E.ROOT-SERVERS.NET.
>
> IPv6 address added for G.ROOT-SERVERS.NET.
>
> IPv6 address changed for L.ROOT-SERVERS.NET.
>
>
> From my measurements (Zurich, Switzerland), all old addresses are still
> working, but new addresses are a bit faster in all cases. (by 10-20 ms
> compared to old addresses).

shouldn't this data be removed from the bind9 package, and just have it
instead depend directly on dns-root-data?

It'd be better if we only have to keep this stuff up-to-date in one
place, which should most likley be /usr/share/dns/root.hints

--dkg

Bug#888995: FTBFS: async_execution_load_test needs /run/user

[Aaron M. Ucko]

Source: dbus-cpp
Version: 5.0.0+18.04.20171031-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-m...@lists.debian.org
Usertags: mips mipsel

Builds of dbus-cpp for several architectures (armhf, mips, mipsel, and
the non-release architectures alpha and x32) failed with errors along
the lines of

  15/15 Test  #1: async_execution_load_test ***Failed  300.02 sec
  Running main() from gmock_main.cc
  [==] Running 1 test from 1 test case.
  [--] Global test environment set-up.
  [--] 1 test from AsyncExecutionLoadTest
  [ RUN  ] AsyncExecutionLoadTest.RepeatedlyInvokingAnAsyncFunctionWorks
  dbus[25970]: Unable to set up transient service directory: XDG_RUNTIME_DIR 
"/run/user/114" not available: No such file or directory
  
/<>/dbus-cpp-5.0.0+18.04.20171031/tests/async_execution_load_test.cpp:134:
 Failure
  Value of: ec->wait_for(std::chrono::minutes{5})
Actual: false (Current count of 378 does not match 500)
  Expected: true
  dbus[25966]: Attempted to unregister path (path[0] = org path[1] = 
freedesktop) which isn't registered
  [  FAILED  ] AsyncExecutionLoadTest.RepeatedlyInvokingAnAsyncFunctionWorks 
(300015 ms)
  [--] 1 test from AsyncExecutionLoadTest (300015 ms total)
  
  [--] Global test environment tear-down
  [==] 1 test from 1 test case ran. (300015 ms total)
  [  PASSED  ] 0 tests.
  [  FAILED  ] 1 test, listed below:
  [  FAILED  ] AsyncExecutionLoadTest.RepeatedlyInvokingAnAsyncFunctionWorks
  
   1 FAILED TEST
  
  
  93% tests passed, 1 tests failed out of 15
  
  Total Test time (real) = 300.02 sec
  
  The following tests FAILED:
  1 - async_execution_load_test (Failed)
  Errors while running CTest

Presumably, these architectures' autobuilders happen to lack /run/user.
(I'm just tagging the two affected mips architectures for now, as
presumably representative here.)

Could you please take a look?

-- 
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#888950: brotli: Use dh_missing --fail-missing

[Jeremy Bicha]

On Wed, Jan 31, 2018 at 5:56 PM, Tomasz Buchert  wrote:
> Both bugs you reported will be fixed in the next upload.

Thanks.

By the way, your debian/changelog says you bumped the debhelper compat
to 11, but that didn't happen in your git repo.

Jeremy Bicha

Bug#888978: developers-reference: 5.6.5 queued logfile

[Guillem Jover]

Hi!

On Wed, 2018-01-31 at 22:29:30 +0100, Thorsten Alteholz wrote:
> Package: developers-reference
> Version: 3.4.19
> Severity: normal
> Tags: patch

> in paragraph 5.6.5 you recommend to login to ssh.debian.org to find the
> logfile for queued. This seems to be no longer true. Nevertheless the
> logfiles can be found on usper.

> diff --git a/common.ent b/common.ent
> index 1bbed6a..561af11 100644
> --- a/common.ent
> +++ b/common.ent
> @@ -48,6 +48,7 @@
>  
>  
>  
> +

I think using ssh.upload.debian.org here would be the more correct fix?

Thanks,
Guillem

Bug#850753: [docker pkg] please please please, or may be we could help?

[Potter, Tim]

Hi Yaroslav.  I don't really have time to keep up to date with Docker at the 
moment.  The
pace of development is very fast!

I'm happy to look at any patches or help you out if you are keen to do some 
work.


Tim.

> On 31 Jan 2018, at 3:33 AM, Yaroslav Halchenko  wrote:
> 
> Current docker version in Debian started to "break on me"...
> Please let us know/guide us if you need help with the update.
> 
> --
> Yaroslav O. Halchenko
> Center for Open Neuroscience http://centerforopenneuroscience.org
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
> WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#888787: dpkg-source: mention when picking up an upstream signature

[Guillem Jover]

Hi!

On Mon, 2018-01-29 at 23:07:46 +0100, Mattia Rizzolo wrote:
> Package: dpkg-dev
> Version: 1.19.0.5
> Severity: minor

> I see this when building a package with an upstream signature available:
> 
> mattia@warren ~/devel/debian/limnoria/limnoria (git)-[master] % dpkg-source 
> -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: applying version
> dpkg-source: info: building limnoria using existing 
> ./limnoria_2018.01.25.orig.tar.gz
> dpkg-source: info: building limnoria in limnoria_2018.01.25-1.debian.tar.xz
> dpkg-source: info: building limnoria in limnoria_2018.01.25-1.dsc
> mattia@warren ~/devel/debian/limnoria/limnoria (git)-[master] % grep orig 
> ../limnoria_2018.01.25-1.dsc|head -n 2
>  fa91c2117b70aaf0f441d69bb13e9a3599fc0d28 876754 
> limnoria_2018.01.25.orig.tar.gz
>  81512d674d42b93681b48aad07a5886d00019981 833 
> limnoria_2018.01.25.orig.tar.gz.asc
> mattia@warren ~/devel/debian/limnoria/limnoria (git)-[master] %
> 
> 
> I'd like for dpkg-source to mention that it detected an .asc (probably
> another "using existing" line?)

Right! Fixed this now locally.

> On a related note, what does that "info: applying version" line mean? :)

Ah, that'd be a patch called just «version». :) Perhaps a lintian check
is in order? I might try to improve the message, the problem is that too
much text will make the line wrap, and for common cases with things like
foo.diff or foo.patch saying something like:

  dpkg-source: info: applying patch "foo.patch"

would seem also a bit redundant?

Thanks,
Guillem

Bug#888994: libjavacc-maven-plugin-java: plugin fails at runtime after jtb 1.4.12-1 update

[tony mancill]

Package: libjavacc-maven-plugin-java
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Packages that build-dep on libjavacc-maven-plugin-java fail a build-time
with:

[INFO] --- javacc-maven-plugin:2.6:javacc (javacc) @ javaparser ---
[WARNING] The POM for edu.ucla.cs.compilers:jtb:jar:debian is missing, no 
dependency information available

This appears correlated with the upload of jtb 1.4.12-1 [1].

[1] https://tracker.debian.org/news/899962


signature.asc
Description: PGP signature

Bug#886285: vim-runtime: tex syntax highlighting fails to enter math mode within align environment

[James McCoy]

On Wed, Jan 31, 2018 at 11:33:30PM +0100, Francesco Poli wrote:
> On Mon, 29 Jan 2018 21:12:01 -0500 James McCoy wrote:
> 
> > On Mon, Jan 29, 2018 at 07:33:40PM +0100, Francesco Poli wrote:
> [...]
> > > So I am puzzled: upstream dropped support for extended syntax provided
> > > by LaTeX packages (such as, for instance, amsmath), but, at the same
> > > time, suggest users to write extensions and contribute them upstream!
> > > 
> > > Do you find this confusing?
> > 
> > No.  There are lots of extensions to TeX, so he has decided to limit the
> > scope of what he supports in the main syntax file.  He has also provided
> > a mechanism for other people to add support for extensions.
> 
> Yes, but he also suggest those other people to contribute this enhanced
> support...
> Hence, I am not completely sure I understand the strategy.

The strategy is to focus on a specified scope and ask other people to
volunteer to develop/maintain support for extra packages.

> > 
> > As part of the package maintenance, neither are we going to develop the
> > syntax files for extensions nor solicit others to do so.  Therefore I'm
> > closing this.
> 
> I was not asking you to develop syntax files for extensions, or to
> solicit others to do so.
> I was just asking you to forward my feature request upstream.

That's just it, though.  There is no upstream to forward the request to.
Someone has to volunteer to do the work to support the amsmath package
and that person would then be the upstream.

Charles isn't upstream because he's explicitly restricted the scope of
what syntax/tex.vim is going to cover.  Bram isn't upstream because he
just aggregates runtime files from their maintainers when they request
to have them included with Vim.

That's why there's no action that I can take on this.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#888993: fakeroot: "apt update" fails with "seccomp prevented execution of syscall 0000000182 on architecture powerpc"

[Daniel Kahn Gillmor]

Package: fakeroot
Version: 1.22-2
Severity: normal
Control: affects -1 + debirf apt

I was using debirf 0.38 on powerpc, trying to build the rescue profile:

I: Configuring libc-bin...
I: Configuring systemd...
I: Base system installed successfully.
debirf> fixing debirf root dev tree...
debirf> executing modules...
run-parts: executing rescue/modules/a0_add_extra_repos
run-parts: executing rescue/modules/a0_add_security_repos
not adding security repository for sid/unstable
run-parts: executing rescue/modules/a0_motd
run-parts: executing rescue/modules/a0_prep-root
dpkg: warning: failed to open configuration file '/root/.dpkg.cfg' for reading: 
Permission denied
passwd: password expiry information changed.
0% [Working]
  Seccomp prevented execution of syscall 000182 on architecture powerpc 

Reading package lists... Done
W: --force-yes is deprecated, use one of the options starting with --allow 
instead.
E: Method http has died unexpectedly!
E: Sub-process http returned an error code (31)
run-parts: rescue/modules/a0_prep-root exited with return code 100
1 dkg@host:~/debirf$ fakeroot -i rescue/.fakeroot-state.debirf-rescue 
fakechroot chroot rescue/root apt update
0% [Working]
  Seccomp prevented execution of syscall 000182 on architecture powerpc 

Reading package lists... Done
E: Method http has died unexpectedly!
E: Sub-process http returned an error code (31)
100 dkg@host:~/debirf$ grep 182 
/usr/src/linux-headers-4.14.0-3-common/arch/powerpc/include/uapi/asm/unistd.h 
#define __NR_getcwd 182
0 dkg@host:~/debirf$ 

any suggestions on how this can work inside fakeroot and fakechroot?

--dkg

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

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

Versions of packages fakeroot depends on:
ii  libc62.26-6
ii  libfakeroot  1.22-2

fakeroot recommends no packages.

fakeroot suggests no packages.

-- no debconf information

Bug#888992: linux-image-4.14.0-3-amd64: kernel oops on dpkg/apt/aptitude

[Scott Bailey]

Package: src:linux
Version: 4.14.13-1
Severity: important

Dear Maintainer,

This bizarre behavior first appeared during the week between Christmas and
New Years (approx 28 December 2017) and has plagued me relentlessly since
that
time, across multiple kernel versions. I run testing (buster) and am in the
habit of applying updates at least every few days, so the update triggering
this behavior presumably migrated to testing very close to Christmas.

Every time I attempt to update software on my system using dpkg or apt or
aptitude, the kernel panics *UNLESS* I am in single-user mode, in which case
everything works fine. I had never seen this behavior prior to the end of
December, and now I can't escape it -- especially annoying for
quasi-headless
systems. :-p

My system refuses to generate crash dumps (a separate issue, sigh) and my
console is a little flaky (HDTV that clips first and last columns and has no
scrollback) but I have logs from a representative episode. Here's the
sequence
of events:

1. I use aptitude to update packages on the system. During application of
these
updates, the kernel panics.
2. I reset the system using the physical button on the front panel
3. I boot into single-user mode.
4. I run "dpkg --configure -a" to fix up work that was in progress at the
time of the panic.
5. To reproduce the problem, I use "systemctl isolate multi-user.target" to
change into a run level where I know the problem will occur.
6. In a putty session, I start "dmesg -w" to capture kernel output that will
scroll off the screen. This includes all output from the system boot.
7. On the console, I run aptitude and do an update and sit back to watch the
system panic again...
8. In another putty session, I belatedly start "tail -f /var/log/dpkg.log"
to
get a sense of what the system is doing

As expected, the system panicked. To the end of the dmesg -w output, I
manually
transcribed the final messages from the console. "??" at the beginning and
end
of the final lines represent columns that I know are there but which are not
visible on my HDTV.

The following steps are for completeness and don't appear in the attached
logs.

9. I punch the reset button again
10. I reboot into single-user mode again
11. I run "dpkg --configure -a" again.
12. I run aptitude to apply all remaining updates, again.
13. When that completes, I reboot the system normally.

Naturally, I expect the software updates to complete without system impact,
like they have for years and years until this popped up. At present, I
cannot
run "dpkg --configure -a" or apt or aptitude if any update ends up being
applied without clobbering my system.

I am attaching "buzz-dmesg-0131.txt", which contains dmesg output (step 6)
including the panic described above, and "buzz-dpkglog-0131.txt" (step 8) to
depict what was happening at the time of the panic.

It is somewhat tempting to blame this behavior on systemd, since it only
occurs
in multi-user (or graphic) runlevels, but ultimately I do not believe that
any
program should trigger a kernel panic in normal operation, and so you get
this
wonderful report. ;-)

Regards,

Scott Bailey 


-- Package-specific info:
** Version:
Linux version 4.14.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version
7.2.0 (Debian 7.2.0-19)) #1 SMP Debian 4.14.13-1 (2018-01-14)

** Command line:
BOOT_IMAGE=/vmlinuz-4.14.0-3-amd64 root=/dev/mapper/vg00-root ro vga=871
elevator=deadline kvm-intel.nested=1 crashkernel=256M crashkernel=256M

** Not tainted

** Kernel log:
[  167.403554] Ebtables v2.0 registered
[  188.627551] virbr0: port 1(virbr0-nic) entered blocking state
[  188.627555] virbr0: port 1(virbr0-nic) entered disabled state
[  188.627604] device virbr0-nic entered promiscuous mode
[  189.733198] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[  191.617203] virbr0: port 1(virbr0-nic) entered blocking state
[  191.617207] virbr0: port 1(virbr0-nic) entered listening state
[  192.071195] virbr0: port 1(virbr0-nic) entered disabled state
[  192.073425] virbr4: port 1(virbr4-nic) entered blocking state
[  192.073428] virbr4: port 1(virbr4-nic) entered disabled state
[  192.073458] device virbr4-nic entered promiscuous mode
[  192.210934] virbr4: port 1(virbr4-nic) entered blocking state
[  192.210937] virbr4: port 1(virbr4-nic) entered listening state
[  192.241110] virbr4: port 1(virbr4-nic) entered disabled state
[  192.243948] virbr1: port 1(virbr1-nic) entered blocking state
[  192.243951] virbr1: port 1(virbr1-nic) entered disabled state
[  192.243999] device virbr1-nic entered promiscuous mode
[  192.519658] virbr1: port 1(virbr1-nic) entered blocking state
[  192.519662] virbr1: port 1(virbr1-nic) entered listening state
[  192.519710] IPv6: ADDRCONF(NETDEV_UP): virbr1: link is not ready
[  194.526058] virbr1: port 1(virbr1-nic) entered learning state
[  196.542020] virbr1: port 1(virbr1-nic) entered forwarding state
[  196.542026] virbr1: topology change detected, propagating
[  

Bug#887553: Acknowledgement (xmltooling-schemas: backport to wheezy update for CVE-2018-0486)

[Chad William Seys]

Thanks so much!

Bug#888805: Also provide a non-Xwindows plain CLI version

[Yavor Doganov]

[Apologies to the unar maintainer for commenting on yet another unar bug.]

積丹尼 Dan Jacobson wrote:
> Package: unar
> Version: 1.10.1-2+b1
> 
> On some machines one just cannot install unar, without making the
> machine rather unusable.
> 
> One would think "I just want to install an program like gunzip. Why must
> I give up my nvidia-legacy-304xx-driver ?"

AFAICS unar doesn't have any GUI libraries as dependencies.  Your
nvidious issue is probably unrelated to unar and I guess it's
triggered by some apt pinning / mixing unstable and experimental
(gcc-8 is available only in experimental).

> OK it seems unar also has a graphical interface.

It does, unar (the tool and the Debian package) is just one component.
But the GUI is not portable to GNUstep, last time I checked.

> So, why no also provide a non-X version?

It is a pure CLI (non-X version) AFAICT.

Bug#888991: please add multiarch support

[Dmitry Eremin-Solenikov]

Package: libcunit1-dev
Version: 2.1-3-dfsg-2
Severity: normal

Hello,

Please make this package compatible with multiarch, as described at
.

More info: http://wiki.debian.org/ReleaseGoals/MultiArch

-- 
With best wishes
Dmitry

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

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

Versions of packages libcunit1-dev depends on:
ii  libcunit1  2.1-3-dfsg-2

libcunit1-dev recommends no packages.

Versions of packages libcunit1-dev suggests:
pn  libcunit1-doc  

-- no debconf information

Bug#787774: [Pkg-javascript-devel] Looking for help Re: Bug#787774: RFP: libjs-openpgp -- OpenPGP JavaScript Implementation (OpenPGP.js)

[Daniel Kahn Gillmor]

Control: retitle 787774 ITP: node-openpgp -- OpenPGP JavaScript Implementation 
(OpenPGP.js)
Control: claim 787774
Control: owner 787774 d...@fifthhorseman.net
Control: block 787774 with 888989

On Wed 2018-01-31 23:05:56 +0100, Jérémy Lal wrote:
> npm2deb can help you setting up things more quickly.
> For example it will tell there's a missing dependency on node-localstorage,
> which in turn luckily depends on a package already in debian.
> The build system (using grunt) might be missing some packages too.

thanks very much for your guidance!

I've run into https://bugs.debian.org/888989 in the process of trying to
follow the npm2deb instructions on a debian sid virtual machine. :(

If npm2deb isn't fixable in the near term, perhaps there's another
package that has similar layout that i could look to as an example instead?

> Since it's distributed with a package.json and it is built using nodejs,
> the source package should be node-openpgp
> and built packages should be node-openpgp and libjs-openpgp.

thanks, this is good to know.

i'm likely to set up a packaging repo for this, using the
git-buildpackage pattern with a debian branch that derives from the
upstream git repo.  Is this something that you'd want in salsa within
the js-team/ namespace (i.e. as js-team/node-openpgp), or should i upload it
as debian/node-openpgp ?  If you prefer the former, i guess i need
membership on the js-team group.

   --dkg


signature.asc
Description: PGP signature

Bug#888986: ITR: gnats -- problem report management system - central database

[Marco d'Itri]

On Feb 01, Adam Borowski  wrote:

> This removal would also allow retiring one of hard-coded uids from
> /etc/passwd that's currently present on every Debian system.
Yes please!

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#888484: Updates for stretch/jessie not in security repo

[Matija Nalis]

nor does debian security tracker list the updates as available for 
jessie/stretch:
https://security-tracker.debian.org/tracker/source-package/clamav

(security-tracked does say in hover text that jessie 
"gets updated via -updates", so it should pick that up)

it correctly reports wheezy, buster and sid as fixed.

for example, see also https://security-tracker.debian.org/tracker/CVE-2017-12376

this looks to me also like something that should be fixed (somewhere)?

Bug#778642: xfce4-power-manager-plugins: Serious memory leak in libxfce4powermanager.so

[Steven Chamberlain]

Hi,

I can reproduce the bug in Debian jessie by running the
power-manager-plugin applet on a laptop only using wall power and
having a fully-charged battery.  In the past 30 days the system's
OOM-killer has twice killed the applet, despite this machine having
~6 GiB RAM otherwise free.

I've tried also with Phil Davidov's 0002-memory-leak-fix.patch
(thanks!), which may have helped fixed some memory leaks, but apparently
not all of them.

The upstream bug report https://bugzilla.xfce.org/show_bug.cgi?id=12367
points to a glib2 upstream commit/backport:
http://pkgs.fedoraproject.org/cgit/rpms/glib2.git/commit/?h=f23=58034b4a48df078e37b55a13bbb855f7615c18b5

The version of glib2.0 in Debian stretch has that patch already applied,
but jessie does not.  Applying that patch against glib2.0 in jessie, I
actually *still* see the resident size of my power-manager-plugin
applet increasing over time.

I'm unfortunately unable to run valgrind on this machine.

Regards,
-- 
Steven Chamberlain
stev...@debian.org


signature.asc
Description: Digital signature

Bug#888990: jenkins.debian.org: redirects for t.r-b.o/debian/$pkg don't work if packages is not in unstable

[Mattia Rizzolo]

Package: jenkins.debian.org
User: jenkins.debian@packages.debian.org
Usertags: reproducible

This URL here:
https://tests.reproducible-builds.org/debian/winswitch
doesn't redirect to:

https://tests.reproducible-builds.org/debian/rb-pkg/stretch/amd64/winswitch.html
as it should.

The package has been removed from unstable, and it's now available only
in stable (stretch).

I believe I see similar instances of inabilities of redirects in other
cases in the past, like for testing-only packages maybe?

-- 
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#888989: Error: Cannot find module 'node-uuid'

[Daniel Kahn Gillmor]

Package: npm2deb
Version: 0.2.7-6
Severity: normal

https://wiki.debian.org/Javascript/Nodejs/Npm2Deb suggests that we ought 
to be able to do "npm2deb search monocle".

here's what happens:

0 dkg@sid:~$ npm2deb search monocle
npm reports errors about monocle module:
module.js:538
throw err;
^

Error: Cannot find module 'node-uuid'
at Function.Module._resolveFilename (module.js:536:15)
at Function.Module._load (module.js:466:25)
at Module.require (module.js:579:17)
at require (internal/module.js:11:18)
at Object. (/usr/lib/nodejs/request/index.js:29:12)
at Module._compile (module.js:635:30)
at Object.Module._extensions..js (module.js:646:10)
at Module.load (module.js:554:32)
at tryModuleLoad (module.js:497:12)
at Function.Module._load (module.js:489:3)
1 dkg@sid:~$ 

fwiw, i have node-uuid installed:

0 dkg@sid:~$ COLUMNS=85 dpkg -l | grep node-uuid
ii  libjs-node-uuid 1.4.7-1  all  simple and fast RFC4122 UUID 
genera
ii  node-node-uuid  1.4.7-1  all  simple and fast RFC4122 UUID 
genera
0 dkg@sid:~$ 

I don't know enough about node or javascript to know how to resolve this 
problem myself so it doesn't look like i can fix it easily.

--dkg

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

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

Versions of packages npm2deb depends on:
ii  devscripts2.17.12
ii  node-github-url-from-git  1.4.0-1
ii  npm   1.4.21+ds-2
ii  python3   3.6.4-1
ii  python3-dateutil  2.6.1-1

npm2deb recommends no packages.

npm2deb suggests no packages.

-- no debconf information

Bug#888917: ocrmypdf fails to run it's testsuite

[James R Barlow]

Upstream here.

The reason the suite fails like that is that mandatory-for-testing
dependencies were also removed.

The test suite runs on Travis CI in 10-12 minutes. On Debian CI, 15
minutes. For comparison ffmpeg, another compute intensive CLI program,
takes 10 minutes.

This is an OCR program and OCR takes a long time. There are opportunities
to speed up testing on my end but no low hanging fruit without removing
tests. I've done the obvious: use all cores, use caches and dummies where
possible. Some OCR on the fly is essential because Tesseract is complex
enough that output is not identical across platforms.

Preserving the dynamically created tests/cache/ folder between test runs,
if possible in Debian CI, would speed it up a lot.

I could mark a subset of essential tests for packagers so that Debian CI
can specify it only wants those. There's a number of tests that are very
unlikely to pass upstream testing (macOS and Ubuntu) then somehow fail
downstream in Debian.

Bug#853915: Bugreports and base64

[Nis Martensen]

control: clone 853915 -1
control: reassign 853915 python-debianbts
control: retitle -1 reportbug: base64 encoded reports rejected by bts

Reading and sending base64 message are two different bugs, so let's
split this report.

I believe that python-debianbts is supposed to decode a base64 message
body, therefore I'm reassigning the base64 reading bug.  Please reassign
back to reportbug if this assumption is wrong.

Bug#711135: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)

[Ivan Zakharyaschev]

Hello!

Issue 711135 seems to never have been resolved yet (since Debian 6 
"squeeze", which has the last kernel which boots on rx2620: 
2.6.32-5-mckinley)


Maybe this works:

https://lists.debian.org/debian-ia64/2013/07/msg9.html (Will Deacon):

...
Ok, after some more experimentation, this is looking more and more like
a compiler problem. Using 4.6.3, I *can* build a bootable kernel from the
Squeeze sources but only if I hack the kernel Makefile to pass -O1 instead
of -O2 or -Os.

https://lists.debian.org/debian-ia64/2013/07/msg00011.html (Lennert Van 
Alboom):


...
Aha - interesting. This might be the same issue as the one I'm seeing on HPVM
on zx6000 (rx2600) with wheezy (coredump & VM hard reset).

https://lists.debian.org/debian-ia64/2013/07/msg5.html (Lennert Van 
Alboom):


...
I've got a zx6000 workstation at home with HP-UX 11.31 and Integrity VM
B.04.30. I want to play with Linux VMs, so I decided to install Debian.

...
As you can see, I used the debian 7.1.0 ia64 netinstall iso. This failed
miserably - I selected "boot from file" and the elilo.efi loaded; when
selecting any option (normal or expert install) the following happens:

 Uncompressing Linux... done
 Loading file \initrd.gz...done

  Dumping Guest Image 
  Done with dump (3776Kbytes) 

*** VM restarting ***


So the installer never makes it.


Next, I swapped the 7.1.0 iso for the 6.0.7 one. Selected elilo.efi, selected
"Expert install"; the installer loads
...

A final follow-up in 2013/08 (just a thought, no really confirmed 
interesting thing): 
https://lists.debian.org/debian-ia64/2013/08/msg0.html (Émeric 
MASCHINO):


Since you all seem to hit a compiler option issue, rather than
dropping optimizations from -O2 to -O1, what about specifically
targeting Merced or McKinley CPU with -mtune=merced or -mtune=mckinley
gcc option? There are also itanium and itanium1 as accepted keywords,
but I don't know how they differ from merced. On a side note, I don't
know what's the difference between the mckinley and itanium2 keywords
(I'm currently rebuilding my whole Gentoo system using
-mtune=itanium2, since I'm running Madison CPUs on my zx6000).


--
Best regards,
Ivan

Bug#876541: [PATCH] Patch for bug 876541

[Thomas Kremer]

found 876541 0.2.3h+dfsg-1
tag 876541 patch

thanks.


And here is your patch.

Questions:
 - This exact version of xul-ext-sieve actually once worked for me. Has
there been a feature reduction in the underlying javascript engine?
 - Will this patch be implemented? In stable?
 - [some self-censored question about anonymous maintainer lists'
reaction patterns]


Yours
Thomas Kremer


-- 
OpenPGP Key ID: 0x6BFFE5CF3C7720398928CE741F2DAE97486A60BF

--- /usr/share/xul-ext/sieve/chrome/chromeFiles/content/editor/SieveFilterEditor.js.orig	2015-08-09 21:40:50.0 +0200
+++ /usr/share/xul-ext/sieve/chrome/chromeFiles/content/editor/SieveFilterEditor.js	2018-01-31 23:34:47.189097792 +0100
@@ -127,14 +127,9 @@
   
   var hash = ch.finish(false);  
   
-  // return the two-digit hexadecimal code for a byte  
-  function toHexString(charCode)  
-  {  
-return ("0" + charCode.toString(16)).slice(-2);  
-  }  
-  
   // convert the binary hash data to a hex string.  
-  return [toHexString(hash.charCodeAt(i)) for (i in hash)].join("");  
+  return Array.from(hash, 
+  function (cur, idx) { return ("0" + hash.charCodeAt(idx).toString(16)).slice(-2); } ).join(""); 
 }
 
 SieveFilterEditor.prototype.onGetScriptResponse

Bug#888987: ITP: jboss-threads -- JBoss Threads

[Markus Koschany]

Package: wnpp
Severity: wishlist
Owner: Markus Koschany 

* Package name: jboss-threads
  Version : 2.3.0
  Upstream Author : Red Hat Inc.
* URL : https://github.com/jbossas/jboss-threads
* License : Apache-2.0 and LGPL-2.1
  Programming Lang: Java
  Description : JBoss Threads

JBoss Threads is a component of the Wildfly Application Server where it is
an integral part of its threading subsystem. It is also used by other JBoss
artifacts like JBoss XNIO for thread related tasks.


This package is a new build-dependency of jboss-xnio.

Bug#888986: ITR: gnats -- problem report management system - central database

[Adam Borowski]

Package: wnpp
Severity: normal

(Please don't file other ITR bugs, I'm trying to gauge how our existing
infrastructure (PTS, wnpp-alert, etc) handles a new type of wnpp bug.  And
more importantly, let's see how _people_ handle this concept.)


I propose removal of "gnats", the old GNU bug tracking system.  While it's
not completely unused (popcon of gnats-user/gnats inst 17/12, vote 11/8),
the Debian QA-maintenance is so inadequate that the last bump of .orig was
in 2005.  Thus, I believe that users would be better served using the
files from upstream directly.  Or, preferably, not at all -- during those 13
years there was only 1 (one) release, and the amount of activity, and
commits (in CVS!) suggests that gnats is hardly on life support anymore.
For something like a bug tracker that inherently processed untrusted input,
I believe the lack of CVEs in due to no one bothering to look rather than
the code being actually secure.

Thus, unless someone objects in the next ${amount of time determined in the
d-devel thread}, I'll reassign this as a RoQA.

This removal would also allow retiring one of hard-coded uids from
/etc/passwd that's currently present on every Debian system.


The package description is:
 GNATS is a bug-tracking tool designed for use at a central "Support
 Site".  Users who experience problems use electronic mail to
 communicate these problems to "maintainers" at that Support Site.
 .
 GNATS offers many of the same features offered by more generalized
 databases, including editing, querying, and basic reporting.  You can
 access the submitting, editing, and querying functions of GNATS
 through provided utilities or from within GNU Emacs.
 .
 The "gnats" package has the full installation for the central database
 server.  For client systems, use the "gnats-user" package which has just
 the user tools.

Bug#888985: ITP: irtt -- Isochronous Round-Trip Tester

[Pete Heist]

Package: wnpp
Severity: wishlist
Owner: Pete Heist 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

* Package name: irtt
  Version : 0.9+git20180131.0.7d52098-1
  Upstream Author : Pete Heist
* URL : https://github.com/peteheist/irtt
* License : GPL-3.0
  Programming Lang: Go
  Description : Isochronous Round-Trip Tester

 IRTT (Isochronous Round-Trip Tester) IRTT measures round-trip time and
 other metrics using UDP packets sent on a fixed period, and produces
 both user and machine parseable output. See https://github.com/peteheist/irtt
 for more information.

Bug#865361: linux-image-4.9.0-3-amd64: kernel stuck at boot on HP ProLiant DL360 G4p

[Andreas Schwarz]

I can confirm that the bug is gone with "linux-image-4.9.0-5-amd64", tested 
with a system 
which was affected before.

-asc

Bug#888950: brotli: Use dh_missing --fail-missing

[Tomasz Buchert]

On 31/01/18 09:30, Jeremy Bicha wrote:
>  [...]

Thanks Jeremy!
Both bugs you reported will be fixed in the next upload.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#888062: pocl: FTBFS on arm64: test_fabs and test_shuffle_{char, ..., float} fail

[Punit Agrawal]

On Wed, Jan 31, 2018 at 12:46 AM, Andreas Beckmann  wrote:
> On 2018-01-31 01:16, Punit Agrawal wrote:
>>>   7/121 Test  #22: kernel/test_shuffle_char 
>>> ***Failed  
>>> Required regular expression found.Regex=[OK
>
>> The attached patch (on top of the package repository) fixes it for me.
>
> Thanks.
>
>> While investigating this failure, I noticed an unrelated issue with
>> the debian build for arm64 - instead of choosing a generic armv8 as
>> the target cpu, the rules file chooses to build with cortex-a53 (value
>> picked from debian/supported-arch). Just thought I'd mention it.
>
> Thanks. Do the shuffle tests still succeed for armv8?

All the tests (except for test_fabs) passed when LLVM_ARCH was set to
"generic" on arm64. I did this by modifying debian/supported_archs.

> It's damned hard to find the generic default -march= setting from llvm
> for each architecture - we have to set it explicitly for pocl, otherwise
> it will internally use the equivalent of -march=native.

I am not familiar with llvm configuration so could be misunderstanding
but I was just worried that choosing "cortex-a53" might assume
micro-architectural features that may not be present on other ARMv8
implementations. It's not so bad if the value is used as a hint to
choose optimised code sequences.

Punit

Bug#888984: RM: consolekit [linux-any] -- ROM; no longer useful on Linux

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

As can be seen in #92, consolekit is not only useless on Linux these
days bug actively harmful. I thus uploaded 0.4.6-6.1 to unstable which
marks the package as kfreebsd-any / hurd-any. Please remove the package
from linux-any accordingly.

Bug#888707: Make sure exim4-* are updated before, after, but not during, locales.

[積丹尼 Dan Jacobson]

Here is a program to find the possible culprits. Use
$ perl m /tmp/log #where log is attached to the bug report above.
#!/usr/bin/perl
use strict;
use warnings FATAL => 'all';
my %p;
while (<>) {
if (/Unpacking (\S+)/)  { $p{$1}++; next; }
if (/Setting up (\S+)/) { $p{$1}--; next; }
last if /locale: Cannot set LC_ALL to default locale/;
}
for ( sort keys %p ) { print "$_\n" if $p{$_}; }

-- System Information:
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

$ strace env 2>&1|grep \"/
execve("/usr/bin/env", ["env"], 0x7fff1e590110 /* 62 vars */) = 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
$ dlocate /usr/lib/locale/locale-archive
$ ls -l /usr/lib/locale/locale-archive
-rw-r--r-- 1 root root 4953856 01-30 10:29 /usr/lib/locale/locale-archive

Bug#886285: vim-runtime: tex syntax highlighting fails to enter math mode within align environment

[Francesco Poli]

On Mon, 29 Jan 2018 21:12:01 -0500 James McCoy wrote:

> On Mon, Jan 29, 2018 at 07:33:40PM +0100, Francesco Poli wrote:
[...]
> > So I am puzzled: upstream dropped support for extended syntax provided
> > by LaTeX packages (such as, for instance, amsmath), but, at the same
> > time, suggest users to write extensions and contribute them upstream!
> > 
> > Do you find this confusing?
> 
> No.  There are lots of extensions to TeX, so he has decided to limit the
> scope of what he supports in the main syntax file.  He has also provided
> a mechanism for other people to add support for extensions.

Yes, but he also suggest those other people to contribute this enhanced
support...
Hence, I am not completely sure I understand the strategy.

> 
> As part of the package maintenance, neither are we going to develop the
> syntax files for extensions nor solicit others to do so.  Therefore I'm
> closing this.

I was not asking you to develop syntax files for extensions, or to
solicit others to do so.
I was just asking you to forward my feature request upstream.

Oh well, I filed a RFP bug report for vimtex: #888981.
I hope someone will step in and package it for inclusion in Debian...

Bye.


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


pgpBCqkIlIsNK.pgp
Description: PGP signature

Bug#888983: dpkg setseclections() may loop without increasing line number

[Heinz Repp]

Package: dpkg
Version: git master
Severity: minor

In src/select.c in function setselections(...) (line 111 ff.) the for 
loop (line 135-196) reads stdin line for line, increasing variable lno 
whenever a newline is encountered. After having read package name and 
selection, the cursor is already advanced after the next newline, but 
the corresponding lno increase is not done until the end of the for loop 
- apparently to be able to reference it. But if the condition line 182 
to 186 is true, the program continues the for loop WITHOUT increasing 
the line number, so the next line is reported with the same line number.


Solution: increase lno already after line 177 and reference lno-1 
afterwards, remove line 195


Btw: I noticed this error running dpkg --setselections with hundreds of 
packages that pkg_is_informative() reported false even though all are in 
/var/lib/dpkg/available, and lots of them were reported on the same 
line: bulks of "warning: package not in database at line xxx" with same xxx.

Bug#888982: unusual mode used when creating /var/run subdir via systemd service

[Simon Deziel]

Package: tor
Version: 0.3.3.1-alpha-1
Severity: minor

Hi Peter,

While looking at the systemd units, I noticed an unusual (to me) mode
used by install when creating the directory under /var/run:

ExecStartPre=/usr/bin/install -Z -m 02755 -o ... -d /var/run/...

When looking in chmod(1) and install(1), I only saw the letters, 3 and 4
digits mode being documented. I don't know if the leading 0 is meant to
specify octal mode (as the chmod(2) system call argument).

It doesn't cause any actual problem as the resulting dir has the
intended permissions (2755) but it just caught my attention and might be
noticed by others so I though I'd mention it.

Regards,
Simon

P.S: it is entirely possible that I'll learn that this "unusual to me"
thing is in fact perfectly correct and valid. If that's the case, I
apologize for the noise ;)



signature.asc
Description: OpenPGP digital signature

Bug#888751: gdbm: bumping severity, transition has started

[Gianfranco Costamagna]

control: severity 888752 serious
control: severity 888753 serious
control: severity 888754 serious

Hello, the fun has started.

slgdbm started failing with 1.14.1 but not with 1.13, and this is the only 
regression I spotted
in the complete rebuild test I did today.

This is a QA package, and the reason is the change from gdbm_errno to 
gdbm_errno_location.
I prepared a patch and I'll upload it as soon as it starts building.

thanks

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#847135: Not fixed by 7.08

[Mike Miller]

On Wed, Dec 13, 2017 at 14:06:03 +0100, Adam Cecile wrote:
> Hello,

Hi,

> 7.08 still have the issue. I cannot push a docker image through openconnect.
> It stalls around 50Mbytes.

Upstream has kindly asked for more information on your issue, can you
please provide a response to
http://lists.infradead.org/pipermail/openconnect-devel/2017-December/004618.html
?

-- 
mike


signature.asc
Description: PGP signature

Bug#787774: [Pkg-javascript-devel] Looking for help Re: Bug#787774: RFP: libjs-openpgp -- OpenPGP JavaScript Implementation (OpenPGP.js)

[Jérémy Lal]

2018-01-31 21:51 GMT+01:00 Daniel Kahn Gillmor :

> Over on https://bugs.debian.org/787774, On Fri 2015-06-05 00:43:14 +0200,
> W. Martin Borgert wrote:
> > Package: wnpp
> > Severity: wishlist
> >
> > Package name: libjs-openpgp
> > Version : v0.10.1
> > Upstream Author : OpenPGP Development Team 
> > URL : http://openpgpjs.org/
> > License : LGPL3+
> > Programming Lang: JavaScript
> > Description : OpenPGP JavaScript Implementation
>
> OpenPGP.js is in even better shape today when this bug was filed, but it
> hasn't been included in debian yet.  This is an e-mail asking about the
> best next steps to get it into Debian.
>
> (btw, URL should be https://openpgpjs.org/ these days)
>
> I need OpenPGP.js in debian in order for me to upload the upcoming
> enigmail 2.0 release, because enigmail 2.0 includes OpenPGP.js, and
> upstream only has the minified versions available, which clearly isn't
> DFSG-free.
>
> I'm not very skilled with the node/grunt toolchain in debian, or with
> the current debian javascript packaging policy but i'd be happy to learn
> if someone wants to give me pointers.
>
> the upstream documentation looks like it can prepare everything for
> publication with:
>
> npm install
> npm test
>
> but that itself looks likely to use network access which is something we
> can't depend on during the debian build.
>

Indeed.


> Should i try to follow the npm2deb guidance here:
>
>https://wiki.debian.org/Javascript/Nodejs/Npm2Deb
>
> or is there a better approach?
>

Not really.
npm2deb can help you setting up things more quickly.
For example it will tell there's a missing dependency on node-localstorage,
which in turn luckily depends on a package already in debian.
The build system (using grunt) might be missing some packages too.


> Also, is libjs-openpgp still the best-practice name for the debian
> package for OpenPGP.js?  I'd be happy to take over this RFP if i can get
> guidance from wiser javascript people about this.
>

Since it's distributed with a package.json and it is built using nodejs,
the source package should be node-openpgp
and built packages should be node-openpgp and libjs-openpgp.

Hope that helps,
Jérémy

Bug#888955: open-vm-tools.service 10.2.0 does not start on boot on jessie/stretch/etc

[Bernd Zeimetz]

tag 888955 moreinfo
thanks

Hi,

> here all systems on vSphere 6.0/6.5 fail to start open-vm-tools.service
> on boot.
> The only thing I see is:
> 
> # systemctl status open-vm-tools.service
> ● open-vm-tools.service - Service for virtual machines hosted on VMware
>    Loaded: loaded (/lib/systemd/system/open-vm-tools.service; enabled)
>    Active: failed (Result: resources)
>  Docs: http://open-vm-tools.sourceforge.net/about.php

please provide some more information - add

[logging]
log = true
vmtoolsd.level = debug
vmtoolsd.handler = file


to
/etc/vmware-tools/tools.conf and restart the service.


Then check /var/log/vmware-vmtoolsd.log.

The other vmware logs might be interesting, too.
Also please give power-cycling the VM a try.

If that gives some clue, we can forward it to the upstream issues on
github. If you have a support contract with vmware, opening a case might
speed up things.

Best regards,

Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#888981: RFP: vim-vimtex -- modern Vim plugin for editing LaTeX files

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vim-vimtex
  Version : N/A
  Upstream Author : Karl Yngve Lervåg 
* URL : https://github.com/lervag/vimtex/
* License : Expat
  Programming Lang: Vim script
  Description : modern Vim plugin for editing LaTeX files

vimtex is a Vim plugin that provides support for writing LaTeX
documents. It is based on LaTeX-Box and it shares a similar goal: to
provide a simple and lightweight LaTeX plugin. It has been rewritten
from scratch to provide a more modern and modular code base.
.
See  for some more
comments on the difference between vimtex and other LaTeX plugins
for Vim.



I think this package may be useful to enhance the user experience
when editing LaTeX documents with Vim. Especially since it also
extends the Vim syntax highlighting for LaTeX, adding support
for a number of LaTeX packages (such as amsmath, and so forth...).

I hope someone is willing to package and maintain it in Debian.
Thanks a lot to anyone volunteering to do so!

Bug#888892: No permission on U2F security key

[Michael Biebl]

Am 31.01.2018 um 22:18 schrieb Kurt Roeckx:
> On Wed, Jan 31, 2018 at 09:24:44PM +0100, Michael Biebl wrote:
>> Am 31.01.2018 um 21:09 schrieb Kurt Roeckx:
>>> On Wed, Jan 31, 2018 at 08:56:40PM +0100, Michael Biebl wrote:
 Am 31.01.2018 um 20:13 schrieb Kurt Roeckx:
> On Wed, Jan 31, 2018 at 06:24:41PM +0100, Michael Biebl wrote:
>> Am 31.01.2018 um 18:20 schrieb Kurt Roeckx:
>>
>>> This is all not related to my issue, that while having udev rules
>>> to set permissions I do not get them.
>>
>> Then I have no idea what your problem is.
>
> The problem is fixed if I remove consolekit and install
> libpam-systemd

 Hm, right. On any system but a barebones server or container, you should
 have libpam-systemd installed. That's why it has priority standard and
 is recommended by systemd.

 consolekit should be uninstalled. I doesn't do anything useful anymore
 since jessie. I wasn't aware that it is actually harmful these days, 
 though.
 Maybe we should add a Conflicts somewhere to force its removal. Thoughts?
>>>
>>> So should conselekit be removed from the archive (on the linux
>>> arches)? 
>>
>> I think so. I already had such a change made years ago but never
>> uploaded that to the archive (at that time, we didn't have sourceful
>> uploads, so this would have been tricky, as I would have needed a
>> kfreebsd build system).
>>
>>> And if so, why not a Depends instead of a Recommends?
>>
>> You mean in systemd? Maybe we should. So far we were overly cautious to
>> not upset anyone and enforce anything unless absolutely necessary (as
>> said, there are use cases, like single-user bare-bones installations
>> where you don't strictly need libpam-systemd so should have the
>> opportunity to uninstall it).
>> History has taught me though, that there are much more users who have
>> disabled Recommends and ran into issues because libpam-systemd was not
>> installed.
>> (libpam-systemd is responsible to register a logind session when you
>> actually login. This is then used by systemd-logind to apply devices
>> permissions and sorts of other stuff).
> 
> I didn't check why, but when I removed consolekit, libpam-systemd
> was installed instead. This seems to be why:
> lightdm Depends libpam-systemd | consolekit
> 
> Maybe lightdm should drop the alternative?

That should definitely go, at least for the linux part.


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



signature.asc
Description: OpenPGP digital signature

Bug#888980: libnfs: Please package new upstream release

[Jeremy Bicha]

Source: libnfs
Version: 1.11.0-2
Severity: wishlist
X-Debbugs-CC: rbal...@debian.org, cnana...@debian.org

libnfs 2.0.0 was released in June. Please package the new version.

https://github.com/sahlberg/libnfs/blob/master/CHANGELOG

Thanks,
Jeremy Bicha

Bug#888978: developers-reference: 5.6.5 queued logfile

[Thorsten Alteholz]

Package: developers-reference
Version: 3.4.19
Severity: normal
Tags: patch

Hi,

in paragraph 5.6.5 you recommend to login to ssh.debian.org to find the 
logfile for queued. This seems to be no longer true. Nevertheless the 
logfiles can be found on usper.


  Thorstendiff --git a/common.ent b/common.ent
index 1bbed6a..561af11 100644
--- a/common.ent
+++ b/common.ent
@@ -48,6 +48,7 @@
 
 
 
+
 
 
 
diff --git a/pkgs.dbk b/pkgs.dbk
index 17c42e3..8af374f 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -504,7 +504,7 @@ linkend="irc-channels">IRC channel
 #debian-devel-changes. If your upload fails
 silently, it could be that your package is improperly signed, in which
 case you can find more explanations on
-ssh.debian.org:/srv/upload.debian.org/queued/run/log.
+:/srv/upload.debian.org/queued/run/log.
 
 
 

Bug#888979: nestopia: Excessive slowdown, distorted audio and crashes when closed

[Davi]

Package: nestopia
Version: 1.48-1
Severity: important

Dear Maintainer,

ROMS run at a low framerate with distorted audio even with all filters and
vsync desactivated. Also, the program crashes when closed.

Reinstalling the package has not solved any of the problems above, which were
not present in Debian Stretch with Nestopia UE 1.47.



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

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

Versions of packages nestopia depends on:
ii  libao4   1.2.2+20180113-1
ii  libarchive13 3.2.2-3.1
ii  libatk1.0-0  2.26.1-3
ii  libc62.26-4
ii  libcairo-gobject21.15.8-3
ii  libcairo21.15.8-3
ii  libepoxy01.4.3-1
ii  libgcc1  1:7.2.0-19
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.3-2
ii  libgtk-3-0   3.22.26-2
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libsdl2-2.0-02.0.7+dfsg1-3
ii  libstdc++6   7.2.0-19
ii  zlib1g   1:1.2.8.dfsg-5

nestopia recommends no packages.

nestopia suggests no packages.

-- no debconf information

Bug#888892: No permission on U2F security key

[Kurt Roeckx]

On Wed, Jan 31, 2018 at 09:24:44PM +0100, Michael Biebl wrote:
> Am 31.01.2018 um 21:09 schrieb Kurt Roeckx:
> > On Wed, Jan 31, 2018 at 08:56:40PM +0100, Michael Biebl wrote:
> >> Am 31.01.2018 um 20:13 schrieb Kurt Roeckx:
> >>> On Wed, Jan 31, 2018 at 06:24:41PM +0100, Michael Biebl wrote:
>  Am 31.01.2018 um 18:20 schrieb Kurt Roeckx:
> 
> > This is all not related to my issue, that while having udev rules
> > to set permissions I do not get them.
> 
>  Then I have no idea what your problem is.
> >>>
> >>> The problem is fixed if I remove consolekit and install
> >>> libpam-systemd
> >>
> >> Hm, right. On any system but a barebones server or container, you should
> >> have libpam-systemd installed. That's why it has priority standard and
> >> is recommended by systemd.
> >>
> >> consolekit should be uninstalled. I doesn't do anything useful anymore
> >> since jessie. I wasn't aware that it is actually harmful these days, 
> >> though.
> >> Maybe we should add a Conflicts somewhere to force its removal. Thoughts?
> > 
> > So should conselekit be removed from the archive (on the linux
> > arches)? 
> 
> I think so. I already had such a change made years ago but never
> uploaded that to the archive (at that time, we didn't have sourceful
> uploads, so this would have been tricky, as I would have needed a
> kfreebsd build system).
> 
> > And if so, why not a Depends instead of a Recommends?
> 
> You mean in systemd? Maybe we should. So far we were overly cautious to
> not upset anyone and enforce anything unless absolutely necessary (as
> said, there are use cases, like single-user bare-bones installations
> where you don't strictly need libpam-systemd so should have the
> opportunity to uninstall it).
> History has taught me though, that there are much more users who have
> disabled Recommends and ran into issues because libpam-systemd was not
> installed.
> (libpam-systemd is responsible to register a logind session when you
> actually login. This is then used by systemd-logind to apply devices
> permissions and sorts of other stuff).

I didn't check why, but when I removed consolekit, libpam-systemd
was installed instead. This seems to be why:
lightdm Depends libpam-systemd | consolekit

Maybe lightdm should drop the alternative?


Kurt

Bug#888807: RFS: qstardict/1.3-1

[Tobias Frost]

Control: tags -1 moreinfo

Hi Boyuan,

here's your review:

- small typo in d/copyright: Alexander had maintained the package in
  2007 and 2008. Also it should be "Comment:" (singular)
- Please review d/copyright. I found at least one file which is not
  properly recorded (wrong license and wrong copyright holder)
- don't install README.md -- it does not have extra information beyond
  a package  description and compilation instructions (which are useless
  for the users of the binary package)
  There is also a slight bug in it: The URLs at the bottom seems
  outdated, they will forward to the github project from the watch file.
  Maybe at least report that to upstream.)
- Please upstream the manpage (Alexander as upstream should include it
  there so that other distributions will also benefit from it)
- The embedded libqxt -- can you use the Debian packaged version?
- Some lintian stuff:
N: Processing binary package qstardict (version 1.3-1, arch amd64) ...
I: qstardict: spelling-error-in-binary usr/bin/qstardict writen written
I: qstardict: spelling-error-in-binary
usr/lib/qstardict/plugins/libstardict.so wil will
I: qstardict: spelling-error-in-binary
usr/lib/qstardict/plugins/libstardict.so formated formatted
I: qstardict: desktop-entry-lacks-keywords-entry
usr/share/applications/qstardict.desktop
(spelling errors should be at least sent upstream, but they
are quite easy to fix and then a patch can be sent upstream :))
note that the spelling errors might also needs fixing in the
translation templates.
- check-all-the-things also found a bit of stuff.
- The watch file is not working.

Future homework (optional -- bonus points area ;-))
- There are many bugs on the BTS that needs bug triaging, e.g
  #494701, #611106, #699940 and maybe others too.  It is possible that
  those bugs are not valid anymore, as they are quite old already.
  Please document the findings in the BTS, file them upstream and/or
  link them to upstream bugs if relevant :)
- Please check with upstream if they have the source for the pngs
  which where obviously created with inkscape (check all the things
  told so). They should be included in the source...
# Check with upstream where the Inkscape SVG source files are.
$ find . -type f \( -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg'
-o -iname '*.jpeg' \) -exec grep -nHiF inkscape {} +
Binary file ./qstardict/pixmaps/system-search.png matches
Binary file ./qstardict/pixmaps/download.png matches
Binary file ./qstardict/pixmaps/plugin.png matches

Please fix the points above, and then remove the moreinfo tag to
signal that it is ready for another round.

Many thanks!

-- 
tobi


signature.asc
Description: PGP signature

Bug#887323: dewalls i386 test failure

[Philip Schuchardt]

Nice! I wonder if i386 don’t support exceptions properly or something...
On Tue, Jan 30, 2018 at 8:07 AM Wookey  wrote:

> On 2018-01-30 06:48 +, Philip Schuchardt wrote:
> > I know I’ve been dragging my feet on this. Let’s see if I can figure
> this out,
> > this week.
>
> I fished out an old netbook which is actually i386. And installed an
> unstable chroot on it (very slowly!) last night. Hopefully this will
> enable some bottom-getting-to.
>
> I should probbaly just have used a debian porter-box, but that machine
> needed updating anyway.
>
> Wookey
> --
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
>
-- 
Phi|ip

Bug#887041: notmuch: add an option to change the database path

[Rob Browning]

It looks like you may be able to direct mbsync to behave as it used to
(avoiding the problem for now) by adding this directive to the
MaildirStore section of .mbsyncrc:

  SubFolders Legacy

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#787774: Looking for help Re: Bug#787774: RFP: libjs-openpgp -- OpenPGP JavaScript Implementation (OpenPGP.js)

[Daniel Kahn Gillmor]

Over on https://bugs.debian.org/787774, On Fri 2015-06-05 00:43:14 +0200, W. 
Martin Borgert wrote:
> Package: wnpp
> Severity: wishlist
>
> Package name: libjs-openpgp
> Version : v0.10.1
> Upstream Author : OpenPGP Development Team 
> URL : http://openpgpjs.org/
> License : LGPL3+
> Programming Lang: JavaScript
> Description : OpenPGP JavaScript Implementation

OpenPGP.js is in even better shape today when this bug was filed, but it
hasn't been included in debian yet.  This is an e-mail asking about the
best next steps to get it into Debian.

(btw, URL should be https://openpgpjs.org/ these days)

I need OpenPGP.js in debian in order for me to upload the upcoming
enigmail 2.0 release, because enigmail 2.0 includes OpenPGP.js, and
upstream only has the minified versions available, which clearly isn't
DFSG-free.

I'm not very skilled with the node/grunt toolchain in debian, or with
the current debian javascript packaging policy but i'd be happy to learn
if someone wants to give me pointers.

the upstream documentation looks like it can prepare everything for
publication with:

npm install
npm test

but that itself looks likely to use network access which is something we
can't depend on during the debian build.

Should i try to follow the npm2deb guidance here:

   https://wiki.debian.org/Javascript/Nodejs/Npm2Deb

or is there a better approach?

Also, is libjs-openpgp still the best-practice name for the debian
package for OpenPGP.js?  I'd be happy to take over this RFP if i can get
guidance from wiser javascript people about this.

   --dkg


signature.asc
Description: PGP signature

Bug#888977: Unavailable dependencies

[David Cortes]

Package: libpango1.0-dev
Version: 1.40.5-1

libpango1.0-dev version 1.40.5-1 appears in debian stretch repositories,  
but its dependencies do not, thus libpango1.0-dev is uninstallable from  
debian's package manager:


libpango1.0-dev :
Depends: libcairo2-dev (>= 1.12.10) but it is not going to be installed
Depends: libfontconfig1-dev (>= 2.10.91) but it is not going to be  
installed

Depends: libpango-1.0-0 (= 1.40.5-1) but 1.40.14-1 is to be installed
Depends: libpangocairo-1.0-0 (= 1.40.5-1) but 1.40.14-1 is to be installed
Depends: libpangoft2-1.0-0 (= 1.40.5-1) but 1.40.14-1 is to be installed
Depends: libpangoxft-1.0-0 (= 1.40.5-1) but 1.40.14-1 is to be installed
Depends: libxft-dev but it is not going to be installed

Bug#888976: [munin-node] systemd 237 errors out rambling about an unsafe symlink chain

[Marcel Partap]

Package: munin-node
Version: 2.0.34-3
Severity: normal

--- Please enter the report below this line. ---
systemd db256aab13 broke munin-node.
> core: be stricter when handling PID files and MAINPID sd_notify() 
> messages   
> 
> Let's be more restrictive when validating PID files and MAINPID=  
>
> messages: don't accept PIDs that make no sense, and if the configuration  
>
> source is not trusted, don't accept out-of-cgroup PIDs. A configuratin
>
> source is considered trusted when the PID file is owned by root, or the   
>
> message was received from root.   
>
> 
> This should lock things down a bit, in case service authors write out 
>
> PID files from unprivileged code or use NotifyAccess=all with 
>
> unprivileged code. Note that doing so was always problematic, just now
>
> it's a bit less problematic.  
>
> 
> When we open the PID file we'll now use the CHASE_SAFE chase_symlinks()   
>
> logic, to ensure that we won't follow an unpriviled-owned symlink to a
>
> privileged-owned file thinking this was a valid privileged PID file,  
>
> even though it really isn't.  
>
> 
> Fixes: #6632  
>

That should teach me a lessen to follow systemd updates!
I don't even understand the problem, the pid file is no symlink and is owned by 
root. 
chase_symlinks() appears a massive fluke to me. 


--- System information. ---
Architecture: 
Kernel:   Linux 4.14.0-14.1-liquorix-amd64

Debian Release: buster/sid
  510 unstableliquorix.net 
  510 unstableftp.de.debian.org 
  510 unstabledl.winehq.org 
  510 unstabledeb-multimedia.org 
  510 testing ftp.de.debian.org 
  509 experimentalftp.de.debian.org 
  502 zesty   ppa.launchpad.net 
  502 yakkety ppa.launchpad.net 
  500 zesty   build.openmodelica.org 
  500 stable  ftp.de.debian.org 
  500 stable  dl.google.com 

--- Package information. ---
Depends(Version) | Installed
-+-==
perl | 5.26.1-4
gawk | 1:4.1.4+dfsg-1+b1
libnet-server-perl   | 2.008-4
lsb-base(>= 4.1) | 9.20170808
munin-common   (>= 2.0.34-3) | 2.0.34-3
munin-plugins-core   | 2.0.34-3
procps   | 2:3.3.12-3


Recommends   (Version) | Installed
==-+-===
libnet-snmp-perl   | 6.0.1-3
munin-plugins-extra| 2.0.34-3


Suggests  (Version) | Installed
===-+-===
acpi| 
 OR lm-sensors  | 1:3.4.0-4
ethtool | 1:4.11-1
hdparm  | 9.53+ds-1
libcrypt-ssleay-perl| 
libdbd-pg-perl  | 
liblwp-useragent-determined-perl| 
libnet-irc-perl | 
libtext-csv-xs-perl | 
libwww-perl | 6.31-1
libxml-simple-perl  | 2.24-1
logtail | 
munin   | 2.0.34-3
munin-plugins-java  | 
default-mysql-client| 
net-tools   | 1.60+git20161116.90da8a0-1
python  | 2.7.14-4
ruby| 1:2.3.3
smartmontools   | 6.5+svn4324-1

Bug#888892: No permission on U2F security key

[Michael Biebl]

Am 31.01.2018 um 21:09 schrieb Kurt Roeckx:
> On Wed, Jan 31, 2018 at 08:56:40PM +0100, Michael Biebl wrote:
>> Am 31.01.2018 um 20:13 schrieb Kurt Roeckx:
>>> On Wed, Jan 31, 2018 at 06:24:41PM +0100, Michael Biebl wrote:
 Am 31.01.2018 um 18:20 schrieb Kurt Roeckx:

> This is all not related to my issue, that while having udev rules
> to set permissions I do not get them.

 Then I have no idea what your problem is.
>>>
>>> The problem is fixed if I remove consolekit and install
>>> libpam-systemd
>>
>> Hm, right. On any system but a barebones server or container, you should
>> have libpam-systemd installed. That's why it has priority standard and
>> is recommended by systemd.
>>
>> consolekit should be uninstalled. I doesn't do anything useful anymore
>> since jessie. I wasn't aware that it is actually harmful these days, though.
>> Maybe we should add a Conflicts somewhere to force its removal. Thoughts?
> 
> So should conselekit be removed from the archive (on the linux
> arches)? 

I think so. I already had such a change made years ago but never
uploaded that to the archive (at that time, we didn't have sourceful
uploads, so this would have been tricky, as I would have needed a
kfreebsd build system).

> And if so, why not a Depends instead of a Recommends?

You mean in systemd? Maybe we should. So far we were overly cautious to
not upset anyone and enforce anything unless absolutely necessary (as
said, there are use cases, like single-user bare-bones installations
where you don't strictly need libpam-systemd so should have the
opportunity to uninstall it).
History has taught me though, that there are much more users who have
disabled Recommends and ran into issues because libpam-systemd was not
installed.
(libpam-systemd is responsible to register a logind session when you
actually login. This is then used by systemd-logind to apply devices
permissions and sorts of other stuff).

Michael



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



signature.asc
Description: OpenPGP digital signature

Bug#884173: SIGSEGV since 63.0.3239.84-1 w/ non-built-in extensions

[Nathan Schulte]

I found that, with all versions since (and including) chromium 
63.0.3239.84-1, Chromium would crash (SIGSEGV) shortly after startup or 
immediately at startup.


Initially, I found that disabling the uMatrix extension I have installed 
(from the Chrome Web Store) would avoid the crashes.  That wasn't a 
suitable work-around, so I've been held at version 63.0.3239.40-1.


(https://github.com/gorhill/uMatrix -- 
https://chrome.google.com/webstore/detail/umatrix/ogfcmafjalglgifnmanfmnieipoejdcf)


I found these information interesting, relating to this bug:

1) a bug report for ArchLinux re: Media Router Component, with a comment 
noting that the "load Media Router Component extension" flag may cause 
Chromium to crash:



https://bugs.archlinux.org/task/51832#comment154874



2) Debian ships Chromium with a "default-flag" to disable the media router:

$ grep -n media /etc/chromium.d/default-flags 
15:# Disable the builtin media router (bug #833477)

16:export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --media-router=0"


3) a bug report for Debian, much like the ArchLinux one above:


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


Thanks,

--
Nate

Bug#888892: No permission on U2F security key

[Kurt Roeckx]

On Wed, Jan 31, 2018 at 08:56:40PM +0100, Michael Biebl wrote:
> Am 31.01.2018 um 20:13 schrieb Kurt Roeckx:
> > On Wed, Jan 31, 2018 at 06:24:41PM +0100, Michael Biebl wrote:
> >> Am 31.01.2018 um 18:20 schrieb Kurt Roeckx:
> >>
> >>> This is all not related to my issue, that while having udev rules
> >>> to set permissions I do not get them.
> >>
> >> Then I have no idea what your problem is.
> > 
> > The problem is fixed if I remove consolekit and install
> > libpam-systemd
> 
> Hm, right. On any system but a barebones server or container, you should
> have libpam-systemd installed. That's why it has priority standard and
> is recommended by systemd.
> 
> consolekit should be uninstalled. I doesn't do anything useful anymore
> since jessie. I wasn't aware that it is actually harmful these days, though.
> Maybe we should add a Conflicts somewhere to force its removal. Thoughts?

So should conselekit be removed from the archive (on the linux
arches)? And if so, why not a Depends instead of a Recommends?


Kurt

Bug#888403: Fwd: [PATCH 1/1] efi_loader: fix building crt0 on arm

[Vagrant Cascadian]

Thanks for the patch!

It definitely seems to resolve the issue with v2018.03-rc1, but
unfortunately I haven't had success building it with v2018.01 yet:

  /<>/u-boot-2018.01+dfsg1/lib/efi_loader/efi_image_loader.c:
  In function ‘efi_load_pe’:

  /<>/u-boot-2018.01+dfsg1/lib/efi_loader/efi_image_loader.c:208:7:
  error: ‘IMAGE_SUBSYSTEM_SAL_RUNTIME_DRIVER’ undeclared (first use in
  this function); did you mean ‘IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER’?


I get the impression that EFI related support in u-boot has been very
active lately, which this code touches, which makes it harder to apply
patches from upstream directly.


live well,
  vagrant

On 2018-01-31, Heinrich Schuchardt wrote:
> Before the patch an undefined constant EFI_SUBSYSTEM was used in the
> crt0 code. The current version of binutils does not swallow the error.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888403
>
> The necessary constant IMAGE_SUBSYSTEM_EFI_APPLICATION is already
> defined in pe.h. So let's factor out asm-generic/pe.h for the
> image subsystem constants and use it in our assembler code.
>
> IMAGE_SUBSYSTEM_SAL_RUNTIME_DRIVER does not exist in the specification
> let's use IMAGE_SUBSYSTEM_EFI_ROM instead.
>
> The include pe.h is only used in code maintained by Alex so let him be the
> maintainer here too.
>
> Reported-by: Andre Przywara 
> Cc: Alexander Graf 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  MAINTAINERS   |  2 ++
>  arch/arm/lib/crt0_aarch64_efi.S   |  4 +++-
>  arch/arm/lib/crt0_arm_efi.S   |  4 +++-
>  include/asm-generic/pe.h  | 21 +
>  include/pe.h  |  8 ++--
>  lib/efi_loader/efi_image_loader.c |  2 +-
>  6 files changed, 32 insertions(+), 9 deletions(-)
>  create mode 100644 include/asm-generic/pe.h


signature.asc
Description: PGP signature

Bug#541538: pulseaudio: disable flat volumes

[Patrick Dunford]

I have the view the same, it should be so easy to resolve this problem 
in the config file, it must be so simple to implement


In addition to the problems you mention, developers of third party 
applications have to publish this fix and respond to queries of why 
altering the volume level in their applications also alters the system 
volume level.


For example, using Kodi, it would set the volume level every time a new 
track was played, resulting in the user having to keep readjusting the 
system volume level every time. My keyboard has these up/down volume 
control buttons I use to set the system volume. Every time a track 
started to play I would have to keep turning the system volume level 
down because the software had raised it. I should be able to set a 
maximum volume level for the system and not have it altered by applications.


So the question is how easy is it to change this default value and what 
is stopping it from being implemented.



On 01/02/18 01:01, Roland Hieber wrote:

I came here because I was just playing [1] on headphones, and Firefox
seemed to think that it would be a good idea to set the master volume to
100%. My ears are still ringing. At least now I know what to do.

[1]: https://en.wikipedia.org/wiki/File:AFSK_1200_baud.ogg

The fix of changing "flat-volumes = yes" to "flat-volumes = no" in
/etc/pulse/daemon.conf seems to be fairly easy to implement, considering
the fact that this bug is blocking a great number of other bugs, and no
one here apparently has to say any word against it in the comments. Is
there something else blocking it?

  - Roland

Bug#887744: redeclipse FTBFS with glibc 2.26

[Martin Erik Werner]

On Tue, 2018-01-23 at 13:46 +0200, Juhani Numminen wrote:
> On Fri, 19 Jan 2018 17:58:06 +0200 Adrian Bunk 
> wrote:
> > Source: redeclipse
> > ...
> > In file included from /usr/include/math.h:724:0,
> >  from /usr/include/c++/7/cmath:45,
> >  from /usr/include/c++/7/math.h:36,
> >  from shared/cube.h:13,
> >  from shared/crypto.cpp:1:
> > /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function
> > 'double tgamma(double)':
> > /usr/include/x86_64-linux-gnu/bits/math-finite.h:203:21: error:
> > 'gamma_r_finite' was not declared in this scope
> >    _Mdouble_ __res = __REDIRTO (gamma, _r, _MSUF_) (__d,
> > &__local_signgam);
> >  ^
> > /usr/include/x86_64-linux-gnu/bits/math-finite.h:203:21: note:
> > suggested alternative: '__gamma_r_finite'
> 
> The commit "remove gamma name hack" might be related, apparently
> there was some
> preprocessor hackery going on.
> https://github.com/red-eclipse/base/commit/b16b4963c1ad81bb9ef784bc49
> 13a4c8ab5f1bb4

Yep, applying this commit solves the issue.

Previously 'gamma' from math.h was masked in order to make it available
 to be defined by cubescript, and this masking was dependent on
implementation-specifics which had changed.

With this fix cubescript uses a different associated global name
'reqgamma' and thus does not need the masking.

-- 
Martin Erik Werner 

Bug#888918: release.debian.org: Update freeze policy for buster

[Paul Gevers]

IRC also mentioned:
*  https://release.debian.org/buster/freeze_policy.html says at
the very end: "After 5th January 2017, removed packages will not be
permitted to re-enter testing."

*  The #links in the first paragraph are also invalid.

Meaning, the date is wrong and the links don't work.

Happy hacking.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#888892: No permission on U2F security key

[Michael Biebl]

Am 31.01.2018 um 20:13 schrieb Kurt Roeckx:
> On Wed, Jan 31, 2018 at 06:24:41PM +0100, Michael Biebl wrote:
>> Am 31.01.2018 um 18:20 schrieb Kurt Roeckx:
>>
>>> This is all not related to my issue, that while having udev rules
>>> to set permissions I do not get them.
>>
>> Then I have no idea what your problem is.
> 
> The problem is fixed if I remove consolekit and install
> libpam-systemd

Hm, right. On any system but a barebones server or container, you should
have libpam-systemd installed. That's why it has priority standard and
is recommended by systemd.

consolekit should be uninstalled. I doesn't do anything useful anymore
since jessie. I wasn't aware that it is actually harmful these days, though.
Maybe we should add a Conflicts somewhere to force its removal. Thoughts?


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



signature.asc
Description: OpenPGP digital signature

Bug#228141: Have dh_clean remove temporary CVS files

[Niels Thykier]

On Sun, 31 Dec 2017 22:53:00 + Niels Thykier  wrote:
> Control: tags -1 moreinfo
> 
> On Fri, 16 Jan 2004 15:26:55 -0500 Joey Hess  wrote:
> > Matt Zimmerman wrote:
> > > Yes, it does...seems like exactly the same reasons that an editor makes
> > > backup files, and dh_clean deletes those.  But, if you don't like it,
> > > whatever...
> > 
> > I'm not unchangably opposed to it; I just don't know what's right.
> > 
> > -- 
> > see shy jo
> 
> Hi Matt,
> 
> It seems that 14 years have past on this bug without any reaction from
> neither you nor Joey.
> 
> I am pinging you to hear about your opinion on this bug.  If you still
> think it is relevant and you think it is the proper thing to do, then I
> am happy to apply the patch.
> 
>   Disclaimer: I have zero-knowledge of this part of CVS, so I would be
> trusting your judgement here.
> 
> Alternatively, if you are no longer interested in this (e.g. because you
> no longer use CVS), then I think I will take the liberty of closing the
> bug as "wont do".
> 
> Thanks,
> ~Niels
> 
> 
> 

Hi Matt,

A friendly ping on this.

If I have not heard from you (or anyone else with interest in this bug)
by 2018-02-19, then I will consider this bug obsolete and close it
without changing the behaviour of dh_clean.

Thanks,
~Niels

Bug#853008: [debian-mysql] Bug#853008: mysql-server-5.7: purge could delete mariadb-server files with inadequate warning

[Lars Tangvald]

On 01/31/2018 02:19 PM, Olaf van der Spek wrote:

Hi,


Anyone else have any good ideas on how to handle this?

I do. The solution is quite simple: do not, ever, remove user data / databases.

It makes everything so much simpler, both on the user side and on the
dev side. No weird questions when installing, no databases gone by
accident..

The problem is that MariaDB and MySQL use the same data location, so 
you'd instead get weird errors when trying to move to a variant/version 
that can't handle the old data (MySQL does not support migration from 
MariaDB, and MariaDB supports specific versions of MySQL). It's 
reasonable for a user to expect that purging one package would let them 
install the other without issues.


There is work going on to deal with this, which should both let users go 
back and forth between incompatible versions and make sure a package can 
only delete its own data.


--
Lars

Bug#888897: enigmail: please package recent 2.0x version of enigmail for experimental

[Daniel Kahn Gillmor]

Control: block 97 with 787774

On Tue 2018-01-30 23:37:01 +0100, Carsten Schoenert wrote:
> could you please try to package a recent enigmail 2.0x version so we can
> early see if Thunderbird and Enigmail installed from the experimental
> archive working well together?

so i've just looked into packaging the 2.0.x version, and the main
blocker that i see is the dependency on OpenPGP.js.

enigmail 2.0.x embeds a minified version of OpenPGP.js split across the
following two files:

   stdlib/openpgp-lib.js
   stdlib/openpgp.worker.min.js

Those files are missing their source in the enigmail git repo, and i
think the best DFSG way to handle that is to get the package available
directly in debian (https://bugs.debian.org/787774).

I'll follow up over on that bug report to see what can be done to move
it forward.  I'm not very skilled with the node+grunt toolchain. :/

 --dkg


signature.asc
Description: PGP signature

Bug#888837: thx for the hot-fix

[Noah Meyerhans]

On Wed, Jan 31, 2018 at 08:24:03PM +0100, SZÉPE Viktor wrote:
> There is no version constrain for FORGED_GMAIL_RCVD
> 
> Noah: Do you see a resolution?

Nope, you're right. Looks like it's taking >36 hours for changes to the
updates rulesets to propagate. The fix has been committed upstream, and
should get published to the channel within the next day or so.

The update latency is rather unfortunate. It makes it quite a bit harder
to respond to changes in spam patterns, and also to push fixes such as
this one. But that's something to discuss upstream more so than here.

noah

Bug#888975: localepurge: [INTL:ru] Russian debconf templates translation update

[Yuri Kozlov]

Package: localepurge
Version: 0.7.3.4
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

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

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

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

Russian debconf templates translation update is attached.

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

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


localepurge_0.7.3.4_ru.po.gz
Description: application/gzip

Bug#888837: thx for the hot-fix

[SZÉPE Viktor]

I think the current rules are still 3.4.1-incompatible:

$ host -t TXT 1.4.3.updates.spamassassin.org.
1.4.3.updates.spamassassin.org is an alias for 3.3.3.updates.spamassassin.org.
3.3.3.updates.spamassassin.org descriptive text "1822773"

$ wget -qO-  
https://svn.apache.org/repos/asf/spamassassin/site/updates/MIRRORED.BY|tail


#CONTACT: tobisworld gmail
http://sa-update.verein-clean.net/ weight=10

#CONTACT: Jari Fredriksson (jarif)
http://sa-update.bitwell.fi/ weight=10

#CONTACT: sysadm...@spamassassin.apache.org
http://sa-update.spamassassin.org/ weight=10

$ wget -qS http://sa-update.spamassassin.org/1822773.tar.gz
  HTTP/1.1 200 OK
  Date: Wed, 31 Jan 2018 19:17:47 GMT
  Server: Apache/2.4.6 (CentOS)
  Last-Modified: Wed, 31 Jan 2018 08:31:02 GMT
  ETag: "33afb-5640e4ca8bd80"
  Accept-Ranges: bytes
  Content-Length: 211707
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: application/x-gzip

$ tar -xf 1822773.tar.gz

$ grep -C3 "check_for_forged_gmail_received_headers" 20_head_tests.cf
header FORGED_YAHOO_RCVDeval:check_for_forged_yahoo_received_headers()
describe FORGED_YAHOO_RCVD  'From' yahoo.com does not match  
'Received' headers


header FORGED_GMAIL_RCVDeval:check_for_forged_gmail_received_headers()
describe FORGED_GMAIL_RCVD  'From' gmail.com does not match  
'Received' headers


header __FORGED_JUNO_RCVD   eval:check_for_forged_juno_received_headers()


There is no version constrain for FORGED_GMAIL_RCVD

Noah: Do you see a resolution?



SZÉPE Viktor, honlap üzemeltetés
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
--
+36-20-4242498  s...@szepe.net  skype: szepe.viktor
Budapest, III. kerület

Bug#887688: [debhelper-devel] Bug#887688: debhelper: empty build of src:ck

[Niels Thykier]

clone 887688 -1
retitle -1 debhelper: dh_makeshlibs --no-act isn't and causes FTBFS
tags 887688 pending
thanks

Hi,

Assuming I have not overlooked something, then I believe this bug is now
resolved in debhelper and will close it in a few days.  This is because:

 * I have filed bugs for all known packages that currently FTBFS due to
   empty or incomplete targets (usually caused by .PHONY).  Most of
   these have a patch attached.

 * The autoreconf related issue was solved in dh-autoreconf/16, which
   solved the problems in some of the originally listed packages.
   (See #887482)

 * There was a regression in the --no-act that caused a single FTBFS.
   This has a patch in debhelper master that has yet to be uploaded
   (I just cloned this bug for that purpose).


Overview of the packages mentioned in this bug report
=

Packages that has an open RC bug related to this issue:

 * apr: #888593 (patch)
 * ck: #888591 (patch)
 * cpputest: #888598 (patch)
 * debian-handbook: #888578 (patch)
 * iaxmodem: #888601 (patch)
 * moarvm: #888582 (patch)
 * jscommunicator: #888579 (patch)
 * libtemplate-perl: #888663 (patch)
 * monotone: #888612 (patch)

Packages that were affected and have now been fixed:

 * openal-soft: Already fixed by smcv
 * biojava-live: Already fixed by the maintainer
 * cysignals: Already fixed by the maintainer

Packages with unrelated issues or that were fixed by changes in other
packages:

 * jansson: Fixed in dh-autoreconf/16
 * scidavis: Will move to the cloned bug

Thanks,
~Niels

Bug#888892: No permission on U2F security key

[Kurt Roeckx]

On Wed, Jan 31, 2018 at 06:24:41PM +0100, Michael Biebl wrote:
> Am 31.01.2018 um 18:20 schrieb Kurt Roeckx:
> 
> > This is all not related to my issue, that while having udev rules
> > to set permissions I do not get them.
> 
> Then I have no idea what your problem is.

The problem is fixed if I remove consolekit and install
libpam-systemd


Kurt

Bug#876379: iio-sensor-proxy: Please package new version 2.3

[Jeremy Bicha]

On Wed, Jan 31, 2018 at 12:32 PM, Ritesh Raj Sarraf  wrote:
> On Wed, 2018-01-31 at 12:20 -0500, Jeremy Bicha wrote:
>> Could you be more specific about what broke? upstream was a bit
>> annoyed actually that Debian & Ubuntu had an old iio-sensor-proxy
>> version.
>
> From my last report, the 2.3 release broke on my machine itself. The
> orientation was inverted.

Does it work now though?

> Do you have test machines in your lab that you can verify upon ?

I don't have a lab. I have a computer where screen auto-rotation does
not work in Linux but does in Windows. The new version of
iio-sensor-proxy doesn't make things better or worse. (It's likely a
kernel bug.)

Thanks,
Jeremy Bicha

Bug#888973: guacd segfaults, error 6 in libcrypto.so.1.1, can't connect via SSH when using PKA

[Fabian Rodriguez]

Package: guacd
Version: 0.9.9-2
Severity: normal

Dear Maintainer,

Guacamole was installed following instructions here: 
https://wiki.debian.org/Guacamole - this provides guacd 0.9.9-2 from Debian 
packages and the Guacamole web application binary from the project (as it's 
broken in Debian, see Bug #887464).

After configuring an SSH connection using public key authentication (PKA), the 
SSH connection fails. The web interface shows an error indicating "DISCONNECTED 
- You have been disconnected". /var/log/message shows guacd[728]: segfault at 
10 ip 7f2ea379e935 sp 7f2e9e259208 error 6 in libcrypto.so.1.1.

The same SSH connection works when PKA is not used (when using password 
authentication) and was tested as working (both with and w/o PKA) using clients 
from Debian and from Windows.

Using the latest guacd 0.9.14 version from source worked, I only tested with 
the 0.9.9 version of the web application (.WAR file from the project site).

This bug is being reported from a system than can reproduce the bug.

To install the latest version from sources, see 
https://wiki.debian.org/Guacamole#Guacamole_server.2C_from_sources_.28v_0.9.14.29
 .


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

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

Versions of packages guacd depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libguac110.9.9-2
ii  libssl1.11.1.0f-3+deb9u1
ii  lsb-base 9.20161125

Versions of packages guacd recommends:
ii  libguac-client-rdp0  0.9.9-2
ii  libguac-client-ssh0  0.9.9-2
ii  libguac-client-vnc0  0.9.9-2

Versions of packages guacd suggests:
pn  libguac-client-telnet0  

-- no debconf information

Bug#871004: hyde: should hyde be removed from unstable?

[Andrew Shadura]

On Sun, 06 Aug 2017 09:50:12 -0400 Lucas Nussbaum  wrote:
> Source: hyde
> User: debian...@lists.debian.org
> Usertags: qa-removals-post-stretch
> 
> Hi,
> 
> Following a discussion[1] on the debian-qa@ mailing list on packages that
> missed both jessie and stretch, I am proposing the removal of this package 
> from
> unstable, because:
> 
>   it was in unstable at the time of the stretch freeze
> but wasn't part of stretch
> AND
>   it was in unstable at the time of the jessie freeze
> but it wasn't part of jessie
> AND
>   it is still not in testing
> AND
>   it was not uploaded since the beginning of 2017.
> 
> If you disagree and think that this package should remain in unstable, feel
> free to just close this bug.
> 
> If this bug is still open one month from now (on 2017-09-06), it will be 
> turned
> into a removal request, using:
> 
>   reassign -1 ftp.debian.org
>   retitle -1 RM: hyde -- RoQA; missed both jessie and stretch
>   thanks
> 
> - Lucas, for the QA team.

Oh, I missed this one. I was preparing a new upstream version, there
were a few things to fix left… and I see this :/

-- 
Cheers,
  Andrew

Bug#888403: Fwd: [PATCH 1/1] efi_loader: fix building crt0 on arm

[Heinrich Schuchardt]

 Forwarded Message 
Subject: [PATCH 1/1] efi_loader: fix building crt0 on arm
Date: Wed, 31 Jan 2018 18:45:35 +
From: Heinrich Schuchardt 
To: Alexander Graf 

Before the patch an undefined constant EFI_SUBSYSTEM was used in the
crt0 code. The current version of binutils does not swallow the error.

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

The necessary constant IMAGE_SUBSYSTEM_EFI_APPLICATION is already
defined in pe.h. So let's factor out asm-generic/pe.h for the
image subsystem constants and use it in our assembler code.

IMAGE_SUBSYSTEM_SAL_RUNTIME_DRIVER does not exist in the specification
let's use IMAGE_SUBSYSTEM_EFI_ROM instead.

The include pe.h is only used in code maintained by Alex so let him be the
maintainer here too.

Reported-by: Andre Przywara 
Cc: Alexander Graf 
Signed-off-by: Heinrich Schuchardt 
---
 MAINTAINERS   |  2 ++
 arch/arm/lib/crt0_aarch64_efi.S   |  4 +++-
 arch/arm/lib/crt0_arm_efi.S   |  4 +++-
 include/asm-generic/pe.h  | 21 +
 include/pe.h  |  8 ++--
 lib/efi_loader/efi_image_loader.c |  2 +-
 6 files changed, 32 insertions(+), 9 deletions(-)
 create mode 100644 include/asm-generic/pe.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 0aecc18a6c..879b41c97e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -291,6 +291,8 @@ S:  Maintained
 T: git git://github.com/agraf/u-boot.git
 F: doc/README.iscsi
 F: include/efi*
+F: include/pe.h
+F: include/asm-generic/pe.h
 F: lib/efi*/
 F: test/py/tests/test_efi*
 F: cmd/bootefi.c
diff --git a/arch/arm/lib/crt0_aarch64_efi.S
b/arch/arm/lib/crt0_aarch64_efi.S
index 52056469be..9b0e894f8a 100644
--- a/arch/arm/lib/crt0_aarch64_efi.S
+++ b/arch/arm/lib/crt0_aarch64_efi.S
@@ -8,6 +8,8 @@
  * This file is taken and modified from the gnu-efi project.
  */
 +#include 
+
.section.text.head
/*
@@ -62,7 +64,7 @@ extra_header_fields:
 */
.long   _start - ImageBase  /* SizeOfHeaders */
.long   0   /* CheckSum */
-   .short  EFI_SUBSYSTEM   /* Subsystem */
+   .short  IMAGE_SUBSYSTEM_EFI_APPLICATION /* Subsystem */
.short  0   /* DllCharacteristics */
.quad   0   /* SizeOfStackReserve */
.quad   0   /* SizeOfStackCommit */
diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S
index 967c885982..af55bba4ba 100644
--- a/arch/arm/lib/crt0_arm_efi.S
+++ b/arch/arm/lib/crt0_arm_efi.S
@@ -8,6 +8,8 @@
  * This file is taken and modified from the gnu-efi project.
  */
 +#include 
+
.section.text.head
/*
@@ -64,7 +66,7 @@ extra_header_fields:
 */
.long   _start - image_base /* SizeOfHeaders */
.long   0   /* CheckSum */
-   .short  EFI_SUBSYSTEM   /* Subsystem */
+   .short  IMAGE_SUBSYSTEM_EFI_APPLICATION /* Subsystem */
.short  0   /* DllCharacteristics */
.long   0   /* SizeOfStackReserve */
.long   0   /* SizeOfStackCommit */
diff --git a/include/asm-generic/pe.h b/include/asm-generic/pe.h
new file mode 100644
index 00..d1683f238a
--- /dev/null
+++ b/include/asm-generic/pe.h
@@ -0,0 +1,21 @@
+/*
+ *  Portable Executable and Common Object Constants
+ *
+ *  Copyright (c) 2018 Heinrich Schuchardt
+ *
+ *  based on the "Microsoft Portable Executable and Common Object File
Format
+ *  Specification", revision 11, 2017-01-23
+ *
+ *  SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _ASM_PE_H
+#define _ASM_PE_H
+
+/* Subsystem type */
+#define IMAGE_SUBSYSTEM_EFI_APPLICATION10
+#define IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER11
+#define IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER 12
+#define IMAGE_SUBSYSTEM_EFI_ROM13
+
+#endif /* _ASM_PE_H */
diff --git a/include/pe.h b/include/pe.h
index 4ef3e92efa..c3a19cef76 100644
--- a/include/pe.h
+++ b/include/pe.h
@@ -11,6 +11,8 @@
 #ifndef _PE_H
 #define _PE_H
 +#include 
+
 typedef struct _IMAGE_DOS_HEADER {
uint16_t e_magic;   /* 00: MZ Header signature */
uint16_t e_cblp;/* 02: Bytes on last page of file */
@@ -62,12 +64,6 @@ typedef struct _IMAGE_DATA_DIRECTORY {
  #define IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16
 -/* PE32+ Subsystem type for EFI images */
-#define IMAGE_SUBSYSTEM_EFI_APPLICATION 10
-#define IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER 11
-#define IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER  12
-#define IMAGE_SUBSYSTEM_SAL_RUNTIME_DRIVER  13
-
 typedef struct _IMAGE_OPTIONAL_HEADER64 {
uint16_t Magic; /* 0x20b */
uint8_t  

Bug#888531: transition: ruby2.5

[Antonio Terceiro]

On Tue, Jan 30, 2018 at 09:33:11AM -0200, Antonio Terceiro wrote:
> On Sat, Jan 27, 2018 at 12:37:46AM +0100, Emilio Pozuelo Monfort wrote:
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/ruby2.5.html
> > 
> > On 26/01/18 20:36, Antonio Terceiro wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > Hi,
> > > 
> > > I would like to start the transition to ruby2.5 in unstable. General
> > > information about Ruby transitions can be found in:
> > > https://wiki.debian.org/Teams/Ruby/InterpreterTransitions
> > > 
> > > ruby2.5 has been in testing for a while.
> > > 
> > > Building against ruby2.5 has been enabled in experimental, and we
> > > already did a test rebuild against it, with pretty good results:
> > > https://hackmd.io/EYBghgHA7AjFDMBaCZgE5EBYYCYAmiaEAxhjgKzFQCmAZtGHtTkA
> > > 
> > > So I would like to enable building against ruby2.5 in unstable, and to
> > > effectively start the transition. Soon after we have a transition page,
> > > I will have a first round of binNMUs to request.
> > 
> > You mention 315 build failures in your report, but I only see 46 bugs
> > in [1] and [2] looks empty.  Where are the rest of the bugs? Also,
> > there are on ~150 packages affected in [3]. How many of those fail to
> > build?
> 
> The test rebuild was not made in lavels, so a bunch of packages fail to
> build because they are missing ruby2.5 support in a dependency
> (ruby-nokogiri being the most common case), so those didn't get a bug
> report.
> 
> I checked a sample of the packages listed in the transition page, and
> those that failed did it either for unrelated reasons, or due to missing
> ruby2.5 support in dependencies.
> 
> Anyway, before I enable ruby2.5 in sid I will do a new rebuild with the
> dependency level n available for level n+1, to make sure.

So I did such rebuild, and got this:

https://people.debian.org/~terceiro/ruby2.5/builds/

18 failures out of 152. Not bad.

5 of those 18 still don't have appropriate RC bugs filed, this will be
done later today. After these bugs are files, I will raise the existing
ones to RC, and enable building for ruby2.5 in sid.

Then I will come back with the first round of binNMUs.


signature.asc
Description: PGP signature

Bug#878483: task-gnome-desktop: Drop extra Recommends

[Jeremy Bicha]

Control: tags -1 +pending

This has been pushed to the git repo:
https://anonscm.debian.org/git/tasksel/tasksel.git/commit/?id=49ef3e52

Thanks,
Jeremy Bicha