Bug#888952: nvidia-driver and opencl

[Andreas Beckmann]

On 2018-02-05 08:44, Hiromasa YOSHIMOTO wrote:
> Although nvidia-modprobe is setuided, it seems
> not to work properly as expected. 

Which is probably caused by some hardening configuration on your
systems. Is there anything about nvidia-modprobe in the logfiles in
/var/log/ ?


Andreas

Bug#889293: src:alot: Please drop "Use file-magic instead of python-magic" patch, alot will FTBFS soon

[Christoph Biedl]

# FTBFS
severity 889293 serious
tags 889293 patch
thanks

Christoph Biedl wrote...

> The new python-magic implementation will hit unstable very soon,
> causing your package to FTBFS.

python-magic 2:0.4.15-1 is now in unstable, hence raising severity.

Also, I've prepared a NMU as attached but found alot fails to build on
some (non-release) archs and like to investigate first. Feel free to go
ahead, though.

Regards,

Christoph
diff -Nru alot-0.6/debian/changelog alot-0.6/debian/changelog
--- alot-0.6/debian/changelog   2017-09-07 02:41:22.0 +0200
+++ alot-0.6/debian/changelog   2018-02-04 18:24:59.0 +0100
@@ -1,3 +1,10 @@
+alot (0.6-2.1) unstable; urgency=high
+
+  * Non-maintainer upload
+  * Drop "Use file-magic instead of python-magic" patch. Closes: #889293
+
+ -- Christoph Biedl   Sun, 04 Feb 2018 
18:24:59 +0100
+
 alot (0.6-2) unstable; urgency=low
 
   * Depend on python-gpg rather than pygpgme for alot package
diff -Nru alot-0.6/debian/control alot-0.6/debian/control
--- alot-0.6/debian/control 2017-09-07 02:41:22.0 +0200
+++ alot-0.6/debian/control 2018-02-04 18:24:59.0 +0100
@@ -14,7 +14,7 @@
  python-configobj,
  python-doc,
  python-gpg,
- python-magic,
+ python-magic (>= 2:0.4.15),
  python-mock,
  python-notmuch,
  python-setuptools,
diff -Nru 
alot-0.6/debian/patches/0002-debian-Use-file-magic-instead-of-python-magic-in-set.patch
 
alot-0.6/debian/patches/0002-debian-Use-file-magic-instead-of-python-magic-in-set.patch
--- 
alot-0.6/debian/patches/0002-debian-Use-file-magic-instead-of-python-magic-in-set.patch
 2017-08-21 01:37:30.0 +0200
+++ 
alot-0.6/debian/patches/0002-debian-Use-file-magic-instead-of-python-magic-in-set.patch
 1970-01-01 01:00:00.0 +0100
@@ -1,26 +0,0 @@
-From c8e3b0d9fce9b95b52f5f9c42ba35a3a1c631d18 Mon Sep 17 00:00:00 2001
-From: Jordan Justen 
-Date: Thu, 16 Feb 2017 17:35:32 -0800
-Subject: [PATCH] debian: Use file-magic instead of python-magic in setup.py
-
-Signed-off-by: Jordan Justen 

- setup.py | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/setup.py b/setup.py
-index f20c5cba..03a1969e 100755
 a/setup.py
-+++ b/setup.py
-@@ -45,7 +45,7 @@ setup(
- 'urwid>=1.1.0',
- 'urwidtrees>=1.0',
- 'twisted>=10.2.0',
--'python-magic',
-+'file-magic',
- 'configobj>=4.7.0',
- 'gpg'
- ],
--- 
-2.14.0
-
diff -Nru alot-0.6/debian/patches/series alot-0.6/debian/patches/series
--- alot-0.6/debian/patches/series  2017-07-10 00:53:58.0 +0200
+++ alot-0.6/debian/patches/series  2018-02-04 18:24:59.0 +0100
@@ -1,2 +1 @@
 0001-Description-Use-local-intersphinx-inventories.patch
-0002-debian-Use-file-magic-instead-of-python-magic-in-set.patch


signature.asc
Description: PGP signature

Bug#888952: nvidia-driver and opencl

[Pascal Obry]

Hi Hiromasa,

I found a reproduce step. Could you try this?
>

I can reproduce with those steps indeed.

Thanks a lot!

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://photos.obry.net
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Bug#847520: please consider naming the new section go, not golang

[Michael Stapelberg]

Fair enough. Personally, I’m happy with either name. Certainly, “golang” is
used in enough places that people know what is meant. As long as we refer
to the language (e.g. in the section description) by “Go”, I think we
should be good.

On Mon, Feb 5, 2018 at 1:46 AM, Guillem Jover  wrote:

> Hi!
>
> On Sun, 2018-02-04 at 23:37:39 +0100, Michael Stapelberg wrote:
> > Matthias Klose  writes:
> > > Please could you consider using go as new tag name?  golang resembles
> > > too much to one particular implementation name.  For other languages
> > > we have python, not cpython, pypy, jython, we have java, not openjdk.
>
> I do care quite a bit about namespaces, and when checking the request
> and the bug history, I also considered the possiblity of using go, but
> discarded it pretty fast and went with the proposed golang name, because
> the former seems like a terrible name to use on a global namespace.
>
> It's at least both a verb, and an ancient game. And golang is definitely
> *not* the name of any specific implementation, the reference
> implementation tarballs go by just go, and its compiler by gc (which is
> also a rather overloaded term). Its wikipedia page even states that it's
> commonly referred as golang.
>
> If we had to add a section for a language named k or q or similar I'd
> expect it'd be named klang or qlang or something along these lines.
> We even have some kind of precedent in the archive, with gnu-r and not
> just r as section, which would be also be terrible. :)
>
> > Indeed, the language is called Go, and golang is the web site address:
> > https://twitter.com/rob_pike/status/886054143235719169
>
> Sure, it's still not a very good name on its own when taken out of the
> programming language context.
>
> I'm also very glad the package namespace for golang packages is
> precisely golang- and not go-, which would also be extremely confusing.
>
> > I agree that the new section should ideally be called “Go”.
>
> I think this would be a bad idea for our global section-space.
>
> > Guillem, thanks for sending the patches in the blocker bugs. Could you
> > update them to use “Go” instead of “golang” please?
>
> I'd rather not see the name changed, so I guess you'll understand
> that even if ftp-masters would unfortunately decide to go for the
> change, I won't be very enthused with updating patches. :)
>
> Thanks,
> Guillem
>



-- 
Best regards,
Michael

Bug#889608: man-db: man(1) dumps core (AppArmor involved)

[intrigeri]

Control: tag -1 + patch

intrigeri:
>> B) remove the AppArmor profile entirely and rely on seccomp instead
>> C) don't enable "no new privs" and rely on AppArmor instead

> I think B is fine given all the non-AppArmor hardening efforts Colin
> has been putting into man-db recently.

There we go: https://salsa.debian.org/debian/man-db/merge_requests/1

I've verified that upgrading from 2.8.0-1 successfully unloads the
profile on my system. I didn't test this upgrade path on a system
that has AppArmor disabled though.

Cheers,
-- 
intrigeri

Bug#889631: mpfr 4.0 branch fails to build with recent tex

[Matthias Klose]

Package: src:mpfr4
Version: 4.0.0-7
Severity: important

Trying to build the 4.0.0 release candidate 2 in Debian unstable, the package
fails to build the documentation:

texlive is version 2017.20180110-1.

/usr/bin/make -C build pdf info html
make[1]: Entering directory '/home/packages/gcc/mpfr/mpfr4-4.0.1~rc2/build'
Making pdf in doc
make[2]: Entering directory '/home/packages/gcc/mpfr/mpfr4-4.0.1~rc2/build/doc'
TEXINPUTS="../../doc:$TEXINPUTS" \
MAKEINFO='/bin/bash /home/packages/gcc/mpfr/mpfr4-4.0.1~rc2/missing makeinfo
--enable-encoding -I ../../doc' \
texi2dvi --pdf --batch  --build-dir=mpfr.t2p -o mpfr.pdf  \
../../doc/mpfr.texi
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) (preloaded
format=pdfetex)
 restricted \write18 enabled.
entering extended mode

(../../../.././../../doc/mpfr.texi
(/home/packages/gcc/mpfr/mpfr4-4.0.1~rc2/doc/texinfo.tex
Loading texinfo [version 2013-02-01.11]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc, environments,
defuns, macros, cross references, insertions,
(/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.4 <14 February 2011>
) localization, formatting, and turning on texinfo input format.) [1{/var/lib/t
exmf/fonts/map/pdftex/updmap/pdftex.map}]
Cross reference values unknown; you must run TeX again. [2] [-1] [-2]
(MPFR Copying Conditions) Chapter 1 [1] Chapter 2 [2] [3] Chapter 3 [4]
Chapter 4 [5] [6] [7] [8] [9] [10] Chapter 5 [11] [12] [13] [14] [15] [16]
../../../.././../../doc/mpfr.texi:1577: Undefined control sequence.
\GMPabs #1->\ensuremath
{|#1|}
 0.5\le {}\GMPabs {\var {d}}
  <1
\finishmath #1->#1
  $\endgroup
l.1577 such that @math{0.5@le{}@GMPabs{@var{d}}<1}

[17]
../../../.././../../doc/mpfr.texi:1593: Undefined control sequence.
\GMPabs #1->\ensuremath
{|#1|}
 0.5\le {}\GMPabs {\var {y}}
  <1
\finishmath #1->#1
  $\endgroup
l.1593 such that @math{0.5@le{}@GMPabs{@var{y}}<1}

[18]
../../../.././../../doc/mpfr.texi:1696: \scriptfont 5 is undefined (character b
).
l.1696 ...\log 2 \over \log @var{b}} \right\rceil$
  ,
[19] [20] [21]
../../../.././../../doc/mpfr.texi:1889: Undefined control sequence.
\GMPabs #1->\ensuremath
{|#1|}
 0 < \GMPabs {x}
   < 1
\finishmath #1->#1
  $\endgroup
l.1889 ...s infinity for @math{0 < @GMPabs{x} < 1}
  , and plus zero for @math{...

../../../.././../../doc/mpfr.texi:1889: Undefined control sequence.
\GMPabs #1->\ensuremath
{|#1|}
 \GMPabs {x}
   > 1
\finishmath #1->#1
  $\endgroup
l.1889 ... and plus zero for @math{@GMPabs{x} > 1}
  .
../../../.././../../doc/mpfr.texi:1890: Undefined control sequence.
\GMPabs #1->\ensuremath
{|#1|}
 0 < \GMPabs {x}
   < 1
\finishmath #1->#1
  $\endgroup
l.1890 ... plus zero for @math{0 < @GMPabs{x} < 1}
  , and plus infinity for @m...

../../../.././../../doc/mpfr.texi:1890: Undefined control sequence.
\GMPabs #1->\ensuremath
{|#1|}
 \GMPabs {x}
   > 1
\finishmath #1->#1
  $\endgroup
l.1890 ... plus infinity for @math{@GMPabs{x} > 1}
  .
[22]
../../../.././../../doc/mpfr.texi:1972: \scriptfont 5 is undefined (character e
).
l.1 ...@xeatspaces {@var{op2} @times 2^{@var{e}}}$
  @end tex@empty
\scanmacro ...spaceisspace \scantokens {#1\empty }
  \endgroup
\mxxx ...canmacro {@tex$\xeatspaces {#1}$@end tex}
  \egroup
l.1972 the power @var{e}}
 . Similar as above.
[23] [24]
../../../.././../../doc/mpfr.texi:2122: Undefined control sequence.
@GMPabs #1->@ensuremath
{|#1|}
 ...) = sign(y)*(Pi - atan(@GMPabs {y/x}
  ))
@tclose ...on @rawbackslash @plainfrenchspacing #1
  }@null
@codex #1->@tclose {#1}
   @endgroup
l.2122 ... x) = sign(y)*(Pi - atan(@GMPabs{y/x}))}
  ,
[25]
../../../.././../../doc/mpfr.texi:2212: \scriptfont 5 is undefined (character o
).
l.1 ...{-@int _{t=0}^{@var{op}} @log (1-t)/t@ dt}$
  @end tex@empty
\scanmacro ...spaceisspace \scantokens {#1\empty }
  \endgroup
\mxxx ...canmacro {@tex$\xeatspaces {#1}$@end 

Bug#889632: parallel: Option --nice not having effect anymore.

[Charles Plessy]

Package: parallel
Version: 20161222-1
Severity: normal

Hello,

with an old version of parallel, the `--nice` option sets the niceness of the 
process.

$ parallel --version
GNU parallel 20130922
[...]

$ parallel -vv --dry-run --nice 10 echo ::: hello
\nice -n10 /bin/bash -c echo\ hello

However, with the version in Stretch, it does not work anymore.

$ parallel --version
GNU parallel 20161222
[...]

$ parallel -vv --dry-run --nice 10 echo ::: hello
echo hello

Cheers

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#888952: nvidia-driver and opencl

[Andreas Beckmann]

On 2018-02-05 08:02, Pascal Obry wrote:
> First, unload is not possible as nvidia is in use.

in that case you could either stop X and work in the console ...
or just do the following steps, since obviously only the nvidia-uvm
module in interesting here, there is no need for rebooting:

$ sudo modprobe -r nvidia_uvm   # unload
$ lsmod | grep nvidia_uvm   # expect empty result
$ nvidia-modprobe -u ; echo $?  # load it; print return code
$ lsmod | grep nvidia_uvm   # expect non-empty result
$ sudo nvidia-modprobe -u   # if previous load didn't
# succeed, retry as root
$ lsmod | grep nvidia_uvm   # now it must be loaded


Are there any hardening settings enabled on your system that could
prevent this setuid executable from doing its job?
* filesystems mounted with option nosuid
* apparmor
* selinux
...

BTW, which version of the nvidia-modprobe package do you have installed?


Andreas

Bug#888952: nvidia-driver and opencl

[Hiromasa YOSHIMOTO]

Dear maintainers,

I found a reproduce step. Could you try this?

$ sudo modprobe -r nvidia_uvm
$ clinfo

$ nvidia-modprobe -u
$ clinfo

$ sudo modprobe nvidia_uvm
$ clinfo


I’m using newer driver 390.25-1 from SVN.
Although nvidia-modprobe is setuided, it seems
not to work properly as expected. 

Regards,
Hiromasa YOSHIMOTO

> 2018/02/05 16:02、Pascal Obry のメール:
> 
> Hello Andreas,
> 
> Thanks for your feedback. I have just rebooted and tested as you
> proposed:
> 
> First, unload is not possible as nvidia is in use.
> 
> $ sudo modprobe -r nvidia
> [sudo] password for obry: 
> modprobe: FATAL: Module nvidia_drm is in use.
> modprobe: FATAL: Error running remove command for nvidia
> 
> $ lsmod | grep nvidia
> nvidia_drm 53248  4
> drm_kms_helper192512  1 nvidia_drm
> drm   438272  7 nvidia_drm,drm_kms_helper
> nvidia_modeset860160  9 nvidia_drm
> nvidia  13168640  594 nvidia_modeset
> 
> $ nvidia-modprobe -u
> 
> Let's check clinfo:
> 
> $ clinfo
> Number of platforms   0
> 
> Not working, so let's run clinfo as root:
> 
> $ sudo clinfo
> Number of platforms   1
>  Platform Name   NVIDIA CUDA
>  Platform Vendor NVIDIA Corporation
>  Platform VersionOpenCL 1.2 CUDA 9.0.282
>  Platform ProfileFULL_PROFILE
>  Platform Extensions 
> cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics 
> cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics 
> cl_khr_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing 
> cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll 
> cl_nv_copy_opts cl_khr_gl_event cl_nv_create_buffer
>  Platform Extensions function suffix NV
> 
>  Platform Name   NVIDIA CUDA
> Number of devices 1
>  Device Name Quadro M1000M
>  Device Vendor   NVIDIA Corporation
> ...
> 
> All fine now. And running clinfo as user also works fine at this stage and 
> this until I reboot.
> 
> And the permissions bits are ok:
> 
> $ ls -la /usr/bin/nvidia-modprobe
> -rwsr-xr-x 1 root root 34904 Jan 13 16:43 /usr/bin/nvidia-modprobe
> 
> Please let me know if you want me to do some more testing.
> 
> This seems fishy and I can assure you that I have the same issue on two 
> different computers.
> 
> Regards,
> 
> -- 
>  Pascal Obry /  Magny Les Hameaux (78)
> 
>  The best way to travel is by means of imagination
> 
>  http://www.obry.net
> 
>  gpg --keyserver keys.gnupg.net --recv-key F949BD3B
> 
> ___
> pkg-nvidia-devel mailing list
> pkg-nvidia-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nvidia-devel

Bug#889630: stunnel4: Please add test dependency on net-tools

[Steve Langasek]

Package: stunnel4
Version: 3:5.44-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch autopkgtest

Dear Peter,

The autopkgtest in the latest version of the stunnel package is failing in
Ubuntu, specifically on armhf, because the test environment for this
architecture does not have net-tools pre-installed and one of the tests
expects the ifconfig command:

autopkgtest [09:18:43]: test command2: [---
Thu Dec 21 09:18:44 UTC 2017
stunnel 5.44 on arm-unknown-linux-gnueabihf platform
Compiled/running with OpenSSL 1.0.2g  1 Mar 2016
Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LI
BWRAP
 
test 010_require_cert   ok
test 011_verify_peerok
test 012_verify_chain   ok
test 013_CRL_file   ok
test 014_PSK_secretsok
test 015_p12_cert   ok
/tmp/autopkgtest.BKAEia/build.7kf/stunnel4-5.44/tests/recipes/020_IPv6: 24: /tmp
/autopkgtest.BKAEia/build.7kf/stunnel4-5.44/tests/recipes/020_IPv6: ifconfig: no
t found
test 020_IPv6   skipped
[...]
autopkgtest [09:19:11]: test command2: ---]
autopkgtest [09:19:14]: test command2:  - - - - - - - - - - results - - - - - - 
- - - -
command2 FAIL stderr: 
/tmp/autopkgtest.BKAEia/build.7kf/stunnel4-5.44/tests/recipes/020_IPv6: 24: 
/tmp/autopkgtest.BKAEia/build.7kf/stunnel4-5.44/tests/recipes/020_IPv6: 
ifconfig: not found
autopkgtest [09:19:14]: test command2:  - - - - - - - - - - stderr - - - - - - 
- - - -

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/armhf/s/stunnel4/20171221_091933_bcd85@/log.gz

The net-tools package is not essential, so should be depended on by packages
which require it.

I have uploaded the attached patch to Ubuntu which fixes this test failure. 
Please consider applying it in Debian as well.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru stunnel4-5.44/debian/tests/control stunnel4-5.44/debian/tests/control
--- stunnel4-5.44/debian/tests/control  2017-11-15 02:02:20.0 -0800
+++ stunnel4-5.44/debian/tests/control  2018-02-04 23:19:59.0 -0800
@@ -3,4 +3,4 @@
 Restrictions: allow-stderr
 
 Test-Command: debian/tests/upstream
-Depends: @, netcat-traditional
+Depends: @, netcat-traditional, net-tools

Bug#889608: man-db: man(1) dumps core (AppArmor involved)

[intrigeri]

intrigeri:
> A) drop the child profiles (groff, filter), merge their rules into the
>main /usr/bin/man profile, and use ix instead of Cx; these rules
>are not particularly scary so this doesn't seem crazy an option

I had a closer look and what's scary is not the rules that can be
found in the child profiles, it's the fact that if we drop the child
profiles, all processes run by man will have full access to the
filesystem:

  # The purpose of this profile isn't to confine man itself (that might be
  # nice in the future, but is tricky since it's quite configurable), but to
  # confine the processes it calls that parse untrusted data.
  /** mrixwlk,

… i.e. the /usr/bin/man profile would be mostly useless. So let's
forget about option A and instead choose between:

> B) remove the AppArmor profile entirely and rely on seccomp instead
> C) don't enable "no new privs" and rely on AppArmor instead

I think B is fine given all the non-AppArmor hardening efforts Colin
has been putting into man-db recently.

Cheers,
-- 
intrigeri

Bug#889629: pd-iemutils binary-all FTBFS: debian/*//usr/lib/pd/extra': No such file or directory

[Adrian Bunk]

Source: pd-iemutils
Version: 0.0.20161027-2
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=pd-iemutils&arch=all&ver=0.0.20161027-2&stamp=1517780292&raw=0

...
   debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install
find /<>/debian/*//usr/lib/pd/extra -name "*.pd_linux" -exec \
chmod 0664 {} +
find: '/<>/debian/*//usr/lib/pd/extra': No such file or directory
debian/rules:34: recipe for target 'override_dh_install' failed
make[1]: *** [override_dh_install] Error 1

Bug#889608: Bug#889617: man-db: all man pages fail to display with "command exited with status 4"

[intrigeri]

Ben Caradoc-Davies:
>> Ben Caradoc-Davies wrote:
>>> And what I would like to know is how the fscking apparmor module got
>>> loaded in the first place, given that I have the apparmor service
>>> masked:
>>> # ls -al /etc/systemd/system/apparmor.service
>>> lrwxrwxrwx 1 root root 9 Dec  8 11:24
>>> /etc/systemd/system/apparmor.service -> /dev/null
>>> Yet:
>>> # aa-status
>>> apparmor module is loaded.
>> You've masked a systemd service. But "module" probably refers to some
>> kernel module here, which is enabled by default since a while in
>> Debian Unstable.

More precisely "module" in this context is to be understood as in
Linux Security Module (LSM). To fully disable the AppArmor LSM, pass
apparmor=0 on the kernel command line (security= might be needed on
top of that, didn't check recently, sorry). Marking/disabling
apparmor.service merely prevents policy loading on boot and might not
be what you want.

Cheers,
-- 
intrigeri

Bug#889627: firebird3.0 FTBFS on most architectures: crash in self-build binaries during the build

[Adrian Bunk]

Source: firebird3.0
Version: 3.0.3.32900.ds4-1
Severity: serious

https://buildd.debian.org/status/package.php?p=firebird3.0&suite=sid

Symptoms are slightly varying, e.g. on arm64:

...
/usr/bin/make gpre
make[4]: Entering directory '/<>/gen'
rm -f metadata.fdb
/<>/gen/Release/firebird/bin/isql -q -i 
/<>/src/dbs/metadata.sql
free(): invalid size
Makefile:323: recipe for target 'metadata.fdb' failed
make[4]: *** [metadata.fdb] Aborted

Bug#889628: lintian: False-positive bad-jar-name

[Niels Thykier]

Package: lintian
Version: 2.5.72
Severity: normal

Hi,

Spotted a false-positive for bad-jar-name.

Thunderbird (among other) appears to be using jar files named
"bn-BD.jar" for language packs installed into packages such as
"lightning-l10n-bn-bd".

(Admittedly, the experimental version of thunderbird does not have
this issue).

I suspect we should limit this check to "common directories used for
public java libraries".

Thanks,
~Niels

Bug#889608: man-db: man(1) dumps core (AppArmor involved)

[intrigeri]

Hi,

gregor herrmann:
> drop_effective_privs()
> ++priv_drop_count = 1
> man: command exited with status 4: /usr/lib/man-db/zsoelim |
> /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e 
> UTF-8 | tbl
> | nroff -mandoc -rLL=146n -rLT=146n -Tutf8
> hashtable_free: 9 entries, 9 (100%) unique

> (without --debug only the last line)

> In parallel AppArmor says:

> Feb 4 23:37:53 jadzia kernel: [1342803.492299] audit: type=1400
> audit(1517783873.721:714): apparmor="DENIED" operation="exec" info="no new 
> privs"
> error=-1 profile="/usr/bin/man" name="/usr/bin/preconv" pid=14287 comm="man"
> requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 
> target="/usr/bin/man//groff"

"no new privs" forbids profile transitions, see
https://lists.ubuntu.com/archives/apparmor/2017-October/011142.html
for details.

So we have a few options:

A) drop the child profiles (groff, filter), merge their rules into the
   main /usr/bin/man profile, and use ix instead of Cx; these rules
   are not particularly scary so this doesn't seem crazy an option

B) remove the AppArmor profile entirely and rely on seccomp instead

C) don't enable "no new privs" and rely on AppArmor instead

Personally my choice would be A >> B >> C.

Colin, if you need help with option A, please let us know :)

Cheers,
-- 
intrigeri

Bug#889493: tech-ctte: Please review if systemd is reliable enough to be the default

[Gunnar Wolf]

Gunnar Wolf dijo [Mon, Feb 05, 2018 at 12:57:47AM -0600]:
> - Enough RC bugs (or evidence of regressions, could even be links to
>   blog posts from people complaining about how systemd is bad or
>   whatever)

Just to be clear - Yes, you linked to the list of bugs on systemd. No
piece of software as widely used as systemd is expected to be
completely bug-free; the list of bugs is as long as I'd expect it to
be, but there is only one grave bug (#784682, resolved) and only one
serious bug (#889144, open). Looking for bugs in unstable yields ~10
open serious bugs, but that's quite expectable at this point on the
release cycle.


signature.asc
Description: PGP signature

Bug#889626: man-db FTBFS on ppc64el: error: invalid application of 'sizeof' to incomplete type 'struct termios'

[Adrian Bunk]

Source: man-db
Version: 2.8.0-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=man-db&arch=ppc64el&ver=2.8.0-1&stamp=1517768128&raw=0

...
../../../lib/sandbox.c: In function 'make_seccomp_filter':
../../../lib/sandbox.c:435:50: error: invalid application of 'sizeof' to 
incomplete type 'struct termios'
   SC_ALLOW_ARG_1 ("ioctl", SCMP_A1 (SCMP_CMP_EQ, TCGETS));
  ^
../../../lib/sandbox.c:183:53: note: in definition of macro 'SC_ALLOW_ARG_1'
   if (seccomp_rule_add (ctx, SCMP_ACT_ALLOW, nr, 1, cmp1) < 0) \
 ^~~~
Makefile:1662: recipe for target 'libman_la-sandbox.lo' failed
make[3]: *** [libman_la-sandbox.lo] Error 1

Bug#888952: nvidia-driver and opencl

[Pascal Obry]

Hello Andreas,

Thanks for your feedback. I have just rebooted and tested as you
proposed:

First, unload is not possible as nvidia is in use.

$ sudo modprobe -r nvidia
[sudo] password for obry: 
modprobe: FATAL: Module nvidia_drm is in use.
modprobe: FATAL: Error running remove command for nvidia

$ lsmod | grep nvidia
nvidia_drm 53248  4
drm_kms_helper192512  1 nvidia_drm
drm   438272  7 nvidia_drm,drm_kms_helper
nvidia_modeset860160  9 nvidia_drm
nvidia  13168640  594 nvidia_modeset

$ nvidia-modprobe -u

Let's check clinfo:

$ clinfo
Number of platforms   0

Not working, so let's run clinfo as root:

$ sudo clinfo
Number of platforms   1
  Platform Name   NVIDIA CUDA
  Platform Vendor NVIDIA Corporation
  Platform VersionOpenCL 1.2 CUDA 9.0.282
  Platform ProfileFULL_PROFILE
  Platform Extensions 
cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics 
cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 
cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing 
cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll 
cl_nv_copy_opts cl_khr_gl_event cl_nv_create_buffer
  Platform Extensions function suffix NV

  Platform Name   NVIDIA CUDA
Number of devices 1
  Device Name Quadro M1000M
  Device Vendor   NVIDIA Corporation
...

All fine now. And running clinfo as user also works fine at this stage and this 
until I reboot.

And the permissions bits are ok:

$ ls -la /usr/bin/nvidia-modprobe
-rwsr-xr-x 1 root root 34904 Jan 13 16:43 /usr/bin/nvidia-modprobe

Please let me know if you want me to do some more testing.

This seems fishy and I can assure you that I have the same issue on two 
different computers.

Regards,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Bug#889493: tech-ctte: Please review if systemd is reliable enough to be the default

[Gunnar Wolf]

Philip Hands dijo [Sat, Feb 03, 2018 at 10:22:19PM +0100]:
> On Sat, 03 Feb 2018, "Kingsley G. Morse Jr."  wrote:
> > Package: tech-ctte
> 
> I don't formally have the right to simply close this bug (as I am now
> doing), so if anyone else on the TC thinks there is any merit whatsoever
> in this bug report, please feel free to reopen it.
> 
> Cheers, Phil.

Thanks for swiftly doing this, Phil.

Kingsley, answering to your point: The Technical Committee is not an
investigative body. If you want us to devote countless hours, as the
TC back in 2013-14 did, and expose to endless flaming again... Please
back your request with:

- Enough RC bugs (or evidence of regressions, could even be links to
  blog posts from people complaining about how systemd is bad or
  whatever)

- Clear reasons why the outlook back in 2014 should need to be
  reevaluated; "enough time has passed" is not a reason.

I clearly agree with Phil closing this bug.


signature.asc
Description: PGP signature

Bug#889625: poco: Please use mariadb directly, not mysql-defaults

[Steve Langasek]

Package: poco
Version: 1.8.0.1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear maintainers,

The latest version of poco is failing to build in Ubuntu, because it
build-depends on default-libmysqlclient-dev but is incompatible with the
current libmysqlclient-dev package, and Ubuntu's "default mysql" is MySQL
rather than MariaDB.

The attached patch has been uploaded to Ubuntu to fix the build by using
mariadb directly, since that is the implementation that poco is compatible
with.

The purpose of mysql-defaults is precisely to support derivatives making a
different choice for "default" mysql implementation, so if a package is not
compatible with both, it should depend directly on the one that it supports.

Please consider applying this patch in Debian.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru poco-1.8.0.1/debian/control poco-1.8.0.1/debian/control
--- poco-1.8.0.1/debian/control 2017-11-11 10:58:56.0 -0800
+++ poco-1.8.0.1/debian/control 2018-02-04 22:09:19.0 -0800
@@ -5,7 +5,7 @@
 Build-Depends: debhelper (>= 10),
cmake,
libexpat1-dev,
-   default-libmysqlclient-dev,
+   libmariadbclient-dev-compat,
libpcre3-dev,
libsqlite3-dev,
libssl-dev,
@@ -20,7 +20,7 @@
 Package: libpoco-dev
 Section: libdevel
 Architecture: any
-Depends: ${misc:Depends}, libpococrypto50 (= ${binary:Version}), libpocodata50 
(= ${binary:Version}), libpocofoundation50 (= ${binary:Version}), libpocojson50 
(= ${binary:Version}), libpocodatamysql50 (= ${binary:Version}), 
libpocomongodb50 (= ${binary:Version}), libpoconet50 (= ${binary:Version}), 
libpoconetssl50 (= ${binary:Version}), libpocodataodbc50 (= ${binary:Version}), 
libpocodatasqlite50 (= ${binary:Version}), libpocoredis50 (= 
${binary:Version}), libpocoutil50 (= ${binary:Version}), libpocoxml50 (= 
${binary:Version}), libpocozip50 (= ${binary:Version}), libexpat1-dev, 
default-libmysqlclient-dev, libpcre3-dev, libsqlite3-dev, libssl-dev, zlib1g-dev
+Depends: ${misc:Depends}, libpococrypto50 (= ${binary:Version}), libpocodata50 
(= ${binary:Version}), libpocofoundation50 (= ${binary:Version}), libpocojson50 
(= ${binary:Version}), libpocodatamysql50 (= ${binary:Version}), 
libpocomongodb50 (= ${binary:Version}), libpoconet50 (= ${binary:Version}), 
libpoconetssl50 (= ${binary:Version}), libpocodataodbc50 (= ${binary:Version}), 
libpocodatasqlite50 (= ${binary:Version}), libpocoredis50 (= 
${binary:Version}), libpocoutil50 (= ${binary:Version}), libpocoxml50 (= 
${binary:Version}), libpocozip50 (= ${binary:Version}), libexpat1-dev, 
libmariadbclient-dev-compat, libpcre3-dev, libsqlite3-dev, libssl-dev, 
zlib1g-dev
 Description: C++ Portable Components (POCO) Development files
  The POCO C++ Libraries are a collection of open source C++ class libraries
  that simplify and accelerate the development of network-centric, portable

Bug#889624: RFS: dav-text/0.8.8-1 -- minimal ncurses-based text editor

[Adam Bilbrough]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dav-text"

   Package name: dav-text
   Version: 0.8.8-1
   Upstream Author: Adam Bilbrough 
   URL: https://gitlab.com/atsb/dav-text
   License: GPLv2
   Section: text

  It builds these binary packages:

dav-text - minimal ncurses based text editor

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

  https://mentors.debian.net/package/dav-text


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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dav-text/dav-text_0.8.8-1.dsc

  More information about dav-text can be obtained from:

https://gitlab.com/atsb/dav-text

  Changes since the last upload:

  * New upstream release.
  * Cleaned up editor interface.
  * Fixed some spelling/grammar errors.
  * Clarified some wordings in the editor.
  * Removed optimising flag due to crash on startup for older systems.


  Regards,

   Adam

Bug#888952: nvidia-driver and opencl

[Andreas Beckmann]

Control: tag -1 moreinfo

On 2018-01-31 15:45, Pascal Obry wrote:
> I don't understand why clinfo as root seems to "unblock" something. Any idea?

it loads the kernel module, which *should* also work if clinfo is run as
regular user

> I have reproduced this 2 times, so I'm pretty sure about the above
> report even if it seems strange.
> 
> Let me know if you want me to do some more testing.

I cannot reproduce the problem here. (Tried the 384.111 driver from
stretch-backports, using both ocl-icl-libopencl1 and nvidia-libopencl1.
Only possible difference is that I'm running a rather old non-distro
kernel for unrelated reasons.)

But it should be easy for you to test the module loading mechanism,
assuming you don't have X running using the nvidia driver:

$ sudo modprobe -r nvidia   # unload all nvidia modules
$ lsmod | grep nvidia   # expect no output
$ nvidia-modprobe -u# NVIDIA's setuid root helper
$ lsmod | grep nvidia   # expect nvidia and nvidia-uvm

If that doesn't work for you, the setuid helper nvidia-modprobe is not
working properly on your system

$ ls -la /usr/bin/nvidia-modprobe

should print

-rwsr-xr-x 1 root root ...
   ^ 


Andreas

Bug#889097: nvidia-libopencl1: Missing NVidia OpenCL platform

[Andreas Beckmann]

Control: tag -1 moreinfo

On 2018-02-02 17:19, Krzysztof Marczak wrote:
> Thank you for quick reply.
> You were right. It's look like it's the same problem as reported in #888952
> When after reboot I don't run clinfo as a root, the NVidia OpenCL platform
> is not visible. After running 'sudo clinfo' it starts to work properly.
> It's reproducible all the time.
I cannot reproduce the problem here. (Tried the 384.111 driver from
stretch-backports, using both ocl-icl-libopencl1 and nvidia-libopencl1.
Only possible difference is that I'm running a rather old non-distro
kernel for unrelated reasons.)

But it should be easy for you to test the module loading mechanism,
assuming you don't have X running using the nvidia driver:

$ sudo modprobe -r nvidia   # unload all nvidia modules
$ lsmod | grep nvidia   # expect no output
$ nvidia-modprobe -u# NVIDIA's setuid root helper
$ lsmod | grep nvidia   # expect nvidia and nvidia-uvm

If that doesn't work for you, the setuid helper nvidia-modprobe is not
working properly on your system

$ ls -la /usr/bin/nvidia-modprobe

should print

-rwsr-xr-x 1 root root ...
   ^ 


Andreas

Bug#436135: pykaraoke: broken symlinks

[Stephan Krempel]

Actually right now in stretch, the package pykaraoke
contains the symlinks

/usr/share/pykaraoke/fonts/DejaVuSansCondensed-Bold.ttf
-> ../../fonts/truetype/ttf-dejavu/DejaVuSansCondensed-Bold.ttf
/usr/share/pykaraoke/fonts/DejaVuSansCondensed.ttf
-> ../../fonts/truetype/ttf-dejavu/DejaVuSansCondensed.ttf
/usr/share/pykaraoke/fonts/DejaVuSans.ttf
-> ../../fonts/truetype/ttf-dejavu/DejaVuSans.ttf


/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansCondensed-Bold.ttf
and /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansCondensed.ttf are
in package ttf-dejavu-extra
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans is in ttf-dejavu-core

So pykaraoke should have depended on ttf-dejavu-extra and
ttf-dejavu-core.

Since these are transitional packages, i think the symlinks should
be changed to point to /usr/share/fonts/truetype/dejavu/... and
pykaraoke should then depend on fonts-dejavu-core and fonts-dejavu-extra
 


pgpCAXtvZV8Fq.pgp
Description: Digitale Signatur von OpenPGP

Bug#889623: kraken: failing autopkgtest, possibly broken package

[Steve Langasek]

Source: kraken
Version: 1.0-1
Severity: important
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Dear Andreas,

Since the upload of kraken 1.0-1, the autopkgtests for this package
have been consistently failing in both Debian and Ubuntu.  While the test
failure is (unfortunately) not considered a blocker for Debian testing,
autopkgtest regressions are blockers for Ubuntu releases.

autopkgtest [18:36:18]: test run-unit-test: [---
scan_fasta_file.pl: unable to determine taxonomy ID for sequence gi|441431932|
autopkgtest [18:36:19]: test run-unit-test: ---]
autopkgtest [18:36:19]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-testFAIL non-zero exit status 25

  https://ci.debian.net/packages/k/kraken/unstable/amd64/

There is very little output from the test, so I'm unsure whether this
represents serious breakage in the package; but I do see that the tests
themselves have not changed from the previous version of the package where
the test did pass, so it does seem likely to me that this is a bug in the
package rather than in the test.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#734101: [Pkg-javascript-devel] Bug#734101: libjs-jquery-mobile: New Release

[Daniel Kahn Gillmor]

On Fri 2014-01-03 14:04:26 -0600, in https://bugs.debian.org/734101 Charlie 
Smotherman wrote:
> Package: libjs-jquery-mobile
> Version: 1.2.0+dfsg-2
> Severity: wishlist

What's going on with libjs-jquery-mobile?  It would be really good for
debian to ship an up-to-date version of libjs-jquery-mobile, or at least
as up-to-date as libjs-jquery at any rate.

is there a reason that libjs-jquery-mobile is in worse shape than the
other libjs-jquery-* packages?

  --dkg

Bug#889622: stretch-pu: package fuse-zip/0.4.0-2+deb9u1

[Matthew Harm Bekkema]

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

Hi,

I'd like to update fuse-zip in stretch to fix a bug which prevents it from
writing changes back to zip files. I took upstream's patch and applied it to the
version in stretch: https://bitbucket.org/agalanin/fuse-zip/commits/9b9c2f47cfe9

Changes:
 fuse-zip (0.4.0-2+deb9u1) stretch; urgency=medium
 .
   * Backport upstream commit 9b9c2f47cfe9 to fix writeback fail with libzip 1.0

Best regards,
Matthew
diff -Nru fuse-zip-0.4.0/debian/changelog fuse-zip-0.4.0/debian/changelog
--- fuse-zip-0.4.0/debian/changelog	2015-02-24 01:15:35.0 +1100
+++ fuse-zip-0.4.0/debian/changelog	2018-02-03 10:44:41.0 +1100
@@ -1,3 +1,9 @@
+fuse-zip (0.4.0-2+deb9u1) stretch; urgency=medium
+
+  * Backport upstream commit 9b9c2f47cfe9 to fix writeback fail with libzip 1.0
+
+ -- Matthew Harm Bekkema   Sat, 03 Feb 2018 10:44:41 +1100
+
 fuse-zip (0.4.0-2) unstable; urgency=low
 
   * Bump standards
diff -Nru fuse-zip-0.4.0/debian/control fuse-zip-0.4.0/debian/control
--- fuse-zip-0.4.0/debian/control	2015-02-24 01:14:52.0 +1100
+++ fuse-zip-0.4.0/debian/control	2018-02-03 10:44:41.0 +1100
@@ -1,7 +1,7 @@
 Source: fuse-zip
 Section: utils
 Priority: optional
-Maintainer: Matthew Bekkema 
+Maintainer: Matthew Harm Bekkema 
 Build-Depends: debhelper (>= 9),
  libfuse-dev,
  libzip-dev (>= 0.11.2),
diff -Nru fuse-zip-0.4.0/debian/patches/fix-zip-source-supports.patch fuse-zip-0.4.0/debian/patches/fix-zip-source-supports.patch
--- fuse-zip-0.4.0/debian/patches/fix-zip-source-supports.patch	1970-01-01 10:00:00.0 +1000
+++ fuse-zip-0.4.0/debian/patches/fix-zip-source-supports.patch	2018-02-03 10:44:41.0 +1100
@@ -0,0 +1,59 @@
+Author: Alexander Galanin 
+Description: Properly handle ZIP_SOURCE_SUPPORTS call introduced in libzip 1.0
+
+--- a/lib/bigBuffer.cpp
 b/lib/bigBuffer.cpp
+@@ -1,5 +1,5 @@
+ 
+-//  Copyright (C) 2008-2014 by Alexander Galanin  //
++//  Copyright (C) 2008-2016 by Alexander Galanin  //
+ //  a...@galanin.nnov.ru//
+ //  http://galanin.nnov.ru/~al//
+ ////
+@@ -282,9 +282,27 @@
+ delete b;
+ return 0;
+ }
+-default: {
++case ZIP_SOURCE_CLOSE:
+ return 0;
++case ZIP_SOURCE_ERROR: {
++// This code should not be called in normal case because none of
++// implemented functions raises error flag.
++int *errs = static_cast(data);
++#if LIBZIP_VERSION_MAJOR >= 1
++errs[0] = ZIP_ER_OPNOTSUPP;
++#else
++errs[0] = ZIP_ER_INVAL;
++#endif
++errs[1] = EINVAL;
++return 2 * sizeof(int);
+ }
++#if LIBZIP_VERSION_MAJOR >= 1
++case ZIP_SOURCE_SUPPORTS:
++return ZIP_SOURCE_SUPPORTS_READABLE;
++#endif
++default:
++// indicate unsupported operation
++return -1;
+ }
+ }
+ 
+--- a/lib/bigBuffer.h
 b/lib/bigBuffer.h
+@@ -1,5 +1,5 @@
+ 
+-//  Copyright (C) 2008-2014 by Alexander Galanin  //
++//  Copyright (C) 2008-2016 by Alexander Galanin  //
+ //  a...@galanin.nnov.ru//
+ //  http://galanin.nnov.ru/~al//
+ ////
+@@ -48,8 +48,6 @@
+ 
+ /**
+  * Callback for zip_source_function.
+- * ZIP_SOURCE_CLOSE is not needed to be handled, ZIP_SOURCE_ERROR is
+- * never called because read() always successfull.
+  * See zip_source_function(3) for details.
+  */
+ static zip_int64_t zipUserFunctionCallback(void *state, void *data,
diff -Nru fuse-zip-0.4.0/debian/patches/series fuse-zip-0.4.0/debian/patches/series
--- fuse-zip-0.4.0/debian/patches/series	1970-01-01 10:00:00.0 +1000
+++ fuse-zip-0.4.0/debian/patches/series	2018-02-03 10:44:41.0 +1100
@@ -0,0 +1 @@
+fix-zip-source-supports.patch

Bug#889621: Does not run script when it should

[martin f krafft]

Package: dibbler-client
Version: 1.0.1-1+b1
Severity: important
Tags: upstream

Dibbler only runs the provided script on RENEW and REBIND, but not
when it receives a new lease for the first time, or when it exits.
This makes it basically useless if you need to do anything other
than the hard-coded configurations it knows how to do (which are
pretty bad, cf. #828678).

Also, upstream's bugzilla is broken, so hence I need to file here.

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

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

Versions of packages dibbler-client depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  libc6  2.26-6
ii  libgcc11:7.3.0-1
ii  libstdc++6 7.3.0-1
ii  ucf3.0036

Versions of packages dibbler-client recommends:
pn  dibbler-doc  
ii  resolvconf   1.79

dibbler-client suggests no packages.


-- 
 .''`.   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#889620: missing entry in debian/copyright

[Thorsten Alteholz]

Package: jupyter-core
Version: 4.4.0
Severity: serious
thanks

Hi,

please add the missing licenses of:
 jupyter_core-4.4.0/jupyter_core/utils/shutil_which.py
to debian/copyright.

Thanks!
  Thorsten

Bug#889619: ITP: libp2pchat-java -- Peer To Peer Chat

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 

* Package name: libp2pchat-java
  Upstream Author : Devin & George Smith
* URL : http://litesoft.org/p2pchat/
* License : Public Domain
  Programming Lang: Java
  Description : Peer To Peer Chat

Provides peer-to-peer chat classes and two applications 
(AWT- and console-based)

This library (albeit being abandonware) would be needed for VASSAL engine 
integration, where it's used in unit tests.

I'm going to maintain it by myself, not much of activity is spotten on
the upstream.

Bug#889603: texlive-latex-extra: ucs support for Unicode character U+200A (hair space)?

[Petter Reinholdtsen]

Just to test, I tried without -b xetex in the dblatex call, and then
pdflatex do not report a failure unless
utf8 is used to enable UTF-8
input.

-- 
Happy hacking
Petter Reinholdtsen

Bug#889603: texlive-latex-extra: ucs support for Unicode character U+200A (hair space)?

[Petter Reinholdtsen]

Control: reopen -1
Control: reassign -1 dblatex
Control: found -1 0.3.10-2

Hi Norbert.  Thanks for the explanation and pointers.

[Norbert Preining]
> Closing this bug according to the Debian TeX guidelines as a but that is
> neither concerned with Debian nor upstream TeX Live, but upupstream.

I believe it is better to reassign the issue to dblatex, which is the
package triggering this bug and which might be in a better position to
avoid it.

Here is a short recipe to reproduce the problem, based on how the book
in question is built today, simplified to try to drop irrelevant command
line options:

cat > hairsp.md < hairsp.xml
dblatex -t tex -b xetex hairsp.xml 
pdflatex hairsp.tex

--
Happy hacking
Petter Reinholdtsen

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

[Ivan Zakharyaschev]

Hi Jason,

On Sun, 4 Feb 2018, Jason Duerstock wrote:


Does the kernel from here work for you?:

https://people.debian.org/~jrtc27/wheezy-backports-ia64/

Specifically 
https://people.debian.org/~jrtc27/wheezy-backports-ia64/linux-image-3.16.0-0.bpo.4-mckinley_3.16.39-1+deb8u1~bpo70+1+gcc4.4_ia64.deb


Yes, it works for our machine. Thanks!

It's amazing that you came to the same solution as regards the use of 
gcc-4.4 a while ago! If we could find it before, it'd have saved us some 
experiments. (The lack of a working installaton image which is easy to 
find was also discouraging at the first stage.)



On Sun, Feb 4, 2018 at 7:56 PM, Ivan Zakharyaschev  wrote:



As for gathering information, I can't think of some useful information
from a working system so far. The same applies to testing. We are able to
test it here. Anyway, thanks for your messages, Frank and Daniel! The
remaining useful tasks which I see are:

1) learn how to compile a bootable kernel for this machine and apply this
knowledge to compile a fresh current kernel;

2) understand what goes wrong (by bisecting gcc), suggest a fix. (Before
we understand it, we can't be sure what should be fixed: it's not
necessarily abug in gcc).

So far, we've done a number of attempts to compile and boot a kernel (I'm
going to post the details and the kernels soon), and my conclusion so far is
that the only affecting factor is the version of gcc (even not -O1 vs
-Os/-O2).

gcc <= 4.5.3 produces a bootable kernel (as for
linux-image-3.2.0-4-mckinley, gcc 4.4.7 from wheezy and gcc 4.5.3 from
snapshots produced a bootable one in my experiments);
gcc > = 4.6.3 produces a non-bootable kernel.

So this already gives an initial hypothesis about the solution to 1):

To compile a bootable kernel for this machine, use gcc <= 4.5.3.

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

[Jason Duerstock]

Does the kernel from here work for you?:

https://people.debian.org/~jrtc27/wheezy-backports-ia64/

Specifically 
https://people.debian.org/~jrtc27/wheezy-backports-ia64/linux-image-3.16.0-0.bpo.4-mckinley_3.16.39-1+deb8u1~bpo70+1+gcc4.4_ia64.deb

Jason

On Sun, Feb 4, 2018 at 7:56 PM, Ivan Zakharyaschev  wrote:
> On Mon, 5 Feb 2018, Ivan Zakharyaschev wrote:
>
>> On Sun, 4 Feb 2018, Frank Scheiner wrote:
>>
>>>  just a quick pointer:
>>>
>>>  I had Debian Wheezy with Linux v3.2.x (vmlinuz-3.2.0-4-mckinley, i.e.
>>>  [this one]) running w/o issues on my rx2620 with two Itanium 2 9040
>>>  (Montecito) both from an on-disk installation and a NFS root FS, but I
>>> ran
>>>  it on bare-metal, not in a VM.
>>
>>
>> Yes, [this one] doesn't boot on our system. It might even be in our case a
>> strange/buggy behavior caused by old firmware for an otherwise correct
>> kernel binary code (or, of course, the code might be not correct). Perhaps,
>> there is a difference between yours and ours machines:
>>
>> root@rx2620:~# cat /proc/cpuinfo
>> processor  : 0
>> vendor : GenuineIntel
>> arch   : IA-64
>> family : 31
>> model  : 2
>> model name : Madison up to 9M cache
>> revision   : 1
>> archrev: 0
>> features   : branchlong
>> cpu number : 0
>> cpu regs   : 4
>> cpu MHz: 1600.021
>> itc MHz: 1600.021752
>> BogoMIPS   : 2390.01
>> siblings   : 1
>> physical id: 0
>>
>> processor  : 1
>> vendor : GenuineIntel
>> arch   : IA-64
>> family : 31
>> model  : 2
>> model name : Madison up to 9M cache
>> revision   : 1
>> archrev: 0
>> features   : branchlong
>> cpu number : 0
>> cpu regs   : 4
>> cpu MHz: 1600.021
>> itc MHz: 1600.021752
>> BogoMIPS   : 2390.01
>> siblings   : 1
>> physical id: 1
>>
>> root@rx2620:~#
>>
>> It looks like ours has 2 Madison CPUs (if we are to trust this cpuinfo),
>> which are older than your Montecito ones.
>
>
>>>  [this one]:
>>>  https://packages.debian.org/wheezy/linux-image-3.2.0-4-mckinley
>>
>>
>> As for gathering information, I can't think of some useful information
>> from a working system so far. The same applies to testing. We are able to
>> test it here. Anyway, thanks for your messages, Frank and Daniel! The
>> remaining useful tasks which I see are:
>>
>> 1) learn how to compile a bootable kernel for this machine and apply this
>> knowledge to compile a fresh current kernel;
>>
>> 2) understand what goes wrong (by bisecting gcc), suggest a fix. (Before
>> we understand it, we can't be sure what should be fixed: it's not
>> necessarily abug in gcc).
>>
>> So far, we've done a number of attempts to compile and boot a kernel (I'm
>> going to post the details and the kernels soon), and my conclusion so far is
>> that the only affecting factor is the version of gcc (even not -O1 vs
>> -Os/-O2).
>>
>> gcc <= 4.5.3 produces a bootable kernel (as for
>> linux-image-3.2.0-4-mckinley, gcc 4.4.7 from wheezy and gcc 4.5.3 from
>> snapshots produced a bootable one in my experiments);
>> gcc > = 4.6.3 produces a non-bootable kernel.
>>
>> So this already gives an initial hypothesis about the solution to 1):
>>
>> To compile a bootable kernel for this machine, use gcc <= 4.5.3.
>
>
> Now that we know how to build a bootable kernel for such machines as ours
> (rx2620 with Madison CPU) and probably Daniel Kasza's rx2600, can such an
> update be published for wheezy?
>
> Perhaps, an additional variant of linux-image-mckinley built with gcc-4.4
> (4.4.7) present in wheezy? As a workaround for this bug.
>
> And what about an updated installation image? So that people trying to
> install Debian on such a machine would succeed not only of they take the
> Debian 6 (squeeze) image (which is definitely not the first thing they would
> try when searching for an installation image), but so that Debian 7 (wheezy)
> images (more likely to be found by them) would work for them, too.
>

Bug#889608: Bug#889617: man-db: all man pages fail to display with "command exited with status 4"

[Ben Caradoc-Davies]

On 05/02/18 13:40, Axel Beckert wrote:

Control: merge 889608 -1
Hi Ben,
thanks for the bug report.
Ben Caradoc-Davies wrote:

under man-db 2.8.0-1 amd64 all man pages fail to display with:
$ man man
man: command exited with status 4: /usr/lib/man-db/zsoelim | /usr/lib/man-
db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl |
nroff -mandoc -rLL=184n -rLT=184n -Tutf8

Ben Caradoc-Davies wrote:

With 2.8.0-1, I see AppArmor messages in the systemd journal for "man man":

This sounds like https://bugs.debian.org/889608 reported only shortly
before your bug report. Hence merging.


Thanks, Axel. I just read the MAN_DISABLE_SECCOMP=1 discussion in 
#889608 and I concur that they are likely the same apparmor problem.



Ben Caradoc-Davies wrote:

And what I would like to know is how the fscking apparmor module got
loaded in the first place, given that I have the apparmor service
masked:
# ls -al /etc/systemd/system/apparmor.service
lrwxrwxrwx 1 root root 9 Dec  8 11:24
/etc/systemd/system/apparmor.service -> /dev/null
Yet:
# aa-status
apparmor module is loaded.

You've masked a systemd service. But "module" probably refers to some
kernel module here, which is enabled by default since a while in
Debian Unstable.


Yes, I think you are right. I am guessing that the man-db package 
install phase dh_apparmor command loads or enables the kernel apparmor 
module and the man apparmor profile. Masking apparmor.service only 
prevents profile loading at boot time, but this is why rebooting with 
apparmor.service masked restore man functionality.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

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

[Ben Hutchings]

On Mon, 2018-02-05 at 03:56 +0300, Ivan Zakharyaschev wrote:
[...]
> Now that we know how to build a bootable kernel for such machines as ours 
> (rx2620 with Madison CPU) and probably Daniel Kasza's rx2600, can such an 
> update be published for wheezy?
[...]

Not officially.  wheezy is now in LTS status, and updates are only
built for x86 and ARM.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



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

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

[Ivan Zakharyaschev]

On Mon, 5 Feb 2018, Ivan Zakharyaschev wrote:


On Sun, 4 Feb 2018, Frank Scheiner wrote:


 just a quick pointer:

 I had Debian Wheezy with Linux v3.2.x (vmlinuz-3.2.0-4-mckinley, i.e.
 [this one]) running w/o issues on my rx2620 with two Itanium 2 9040
 (Montecito) both from an on-disk installation and a NFS root FS, but I ran
 it on bare-metal, not in a VM.


Yes, [this one] doesn't boot on our system. It might even be in our case a 
strange/buggy behavior caused by old firmware for an otherwise correct kernel 
binary code (or, of course, the code might be not correct). Perhaps, there is 
a difference between yours and ours machines:


root@rx2620:~# cat /proc/cpuinfo
processor  : 0
vendor : GenuineIntel
arch   : IA-64
family : 31
model  : 2
model name : Madison up to 9M cache
revision   : 1
archrev: 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz: 1600.021
itc MHz: 1600.021752
BogoMIPS   : 2390.01
siblings   : 1
physical id: 0

processor  : 1
vendor : GenuineIntel
arch   : IA-64
family : 31
model  : 2
model name : Madison up to 9M cache
revision   : 1
archrev: 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz: 1600.021
itc MHz: 1600.021752
BogoMIPS   : 2390.01
siblings   : 1
physical id: 1

root@rx2620:~#

It looks like ours has 2 Madison CPUs (if we are to trust this cpuinfo), 
which are older than your Montecito ones.



 [this one]:
 https://packages.debian.org/wheezy/linux-image-3.2.0-4-mckinley


As for gathering information, I can't think of some useful information from a 
working system so far. The same applies to testing. We are able to test it 
here. Anyway, thanks for your messages, Frank and Daniel! The remaining 
useful tasks which I see are:


1) learn how to compile a bootable kernel for this machine and apply this 
knowledge to compile a fresh current kernel;


2) understand what goes wrong (by bisecting gcc), suggest a fix. (Before we 
understand it, we can't be sure what should be fixed: it's not necessarily 
abug in gcc).


So far, we've done a number of attempts to compile and boot a kernel (I'm 
going to post the details and the kernels soon), and my conclusion so far is 
that the only affecting factor is the version of gcc (even not -O1 vs 
-Os/-O2).


gcc <= 4.5.3 produces a bootable kernel (as for linux-image-3.2.0-4-mckinley, 
gcc 4.4.7 from wheezy and gcc 4.5.3 from snapshots produced a bootable one in 
my experiments);

gcc > = 4.6.3 produces a non-bootable kernel.

So this already gives an initial hypothesis about the solution to 1):

To compile a bootable kernel for this machine, use gcc <= 4.5.3.


Now that we know how to build a bootable kernel for such machines as ours 
(rx2620 with Madison CPU) and probably Daniel Kasza's rx2600, can such an 
update be published for wheezy?


Perhaps, an additional variant of linux-image-mckinley built with 
gcc-4.4 (4.4.7) present in wheezy? As a workaround for this bug.


And what about an updated installation image? So that people trying to 
install Debian on such a machine would succeed not only of they take the 
Debian 6 (squeeze) image (which is definitely not the first thing they 
would try when searching for an installation image), but so that Debian 7 
(wheezy) images (more likely to be found by them) would work for them, 
too.

Bug#889618: entry in debian/copyright missing

[Thorsten Alteholz]

Package: flask-login
Version: 0.4.0-2
Severity: serious
thanks

Hi

one of our trainees looked at your package and found that a whole 
directory in the source (docs/_themes) is copyrighted by Armin Ronacher 
and licensed with a 3-clause BSD license.

This whole information is missing from the copyright file.

Thanks!
  Thorsten

Bug#847520: please consider naming the new section go, not golang

[Guillem Jover]

Hi!

On Sun, 2018-02-04 at 23:37:39 +0100, Michael Stapelberg wrote:
> Matthias Klose  writes:
> > Please could you consider using go as new tag name?  golang resembles
> > too much to one particular implementation name.  For other languages
> > we have python, not cpython, pypy, jython, we have java, not openjdk.

I do care quite a bit about namespaces, and when checking the request
and the bug history, I also considered the possiblity of using go, but
discarded it pretty fast and went with the proposed golang name, because
the former seems like a terrible name to use on a global namespace.

It's at least both a verb, and an ancient game. And golang is definitely
*not* the name of any specific implementation, the reference
implementation tarballs go by just go, and its compiler by gc (which is
also a rather overloaded term). Its wikipedia page even states that it's
commonly referred as golang.

If we had to add a section for a language named k or q or similar I'd
expect it'd be named klang or qlang or something along these lines.
We even have some kind of precedent in the archive, with gnu-r and not
just r as section, which would be also be terrible. :)

> Indeed, the language is called Go, and golang is the web site address:
> https://twitter.com/rob_pike/status/886054143235719169

Sure, it's still not a very good name on its own when taken out of the
programming language context.

I'm also very glad the package namespace for golang packages is
precisely golang- and not go-, which would also be extremely confusing.

> I agree that the new section should ideally be called “Go”.

I think this would be a bad idea for our global section-space.

> Guillem, thanks for sending the patches in the blocker bugs. Could you
> update them to use “Go” instead of “golang” please?

I'd rather not see the name changed, so I guess you'll understand
that even if ftp-masters would unfortunately decide to go for the
change, I won't be very enthused with updating patches. :)

Thanks,
Guillem

Bug#889617: man-db: all man pages fail to display with "command exited with status 4"

[Ben Caradoc-Davies]

Rebooting restores man page rendering, even with 2.8.0-1, but 
reinstalling causes the bug to reappear.


It looks like root can view man pages but an unprivileged user cannot.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#889617: man-db: all man pages fail to display with "command exited with status 4"

[Axel Beckert]

Control: merge 889608 -1

Hi Ben,

thanks for the bug report.

Ben Caradoc-Davies wrote:
> under man-db 2.8.0-1 amd64 all man pages fail to display with:
> 
> $ man man
> man: command exited with status 4: /usr/lib/man-db/zsoelim | /usr/lib/man-
> db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl |
> nroff -mandoc -rLL=184n -rLT=184n -Tutf8

Ben Caradoc-Davies wrote:
> With 2.8.0-1, I see AppArmor messages in the systemd journal for "man man":

This sounds like https://bugs.debian.org/889608 reported only shortly
before your bug report. Hence merging.

Ben Caradoc-Davies wrote:
> And what I would like to know is how the fscking apparmor module got
> loaded in the first place, given that I have the apparmor service
> masked:
> 
> # ls -al /etc/systemd/system/apparmor.service
> lrwxrwxrwx 1 root root 9 Dec  8 11:24
> /etc/systemd/system/apparmor.service -> /dev/null
> 
> Yet:
> 
> # aa-status
> apparmor module is loaded.

You've masked a systemd service. But "module" probably refers to some
kernel module here, which is enabled by default since a while in
Debian Unstable.

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

Bug#889617: man-db: all man pages fail to display with "command exited with status 4"

[Ben Caradoc-Davies]

And what I would like to know is how the fscking apparmor module got 
loaded in the first place, given that I have the apparmor service masked:


# ls -al /etc/systemd/system/apparmor.service
lrwxrwxrwx 1 root root 9 Dec  8 11:24 
/etc/systemd/system/apparmor.service -> /dev/null


Yet:

# aa-status
apparmor module is loaded.
3 profiles are loaded.
3 profiles are in enforce mode.
   /usr/bin/man
   /usr/bin/man//filter
   /usr/bin/man//groff
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#889617: man-db: all man pages fail to display with "command exited with status 4"

[Ben Caradoc-Davies]

With 2.8.0-1, I see AppArmor messages in the systemd journal for "man man":

Feb 05 13:09:30 ripley audit[30186]: AVC apparmor="DENIED" 
operation="exec" info="no new privs" error=-1 profile="/usr/bin/man" 
name="/usr/bin/preconv" pid=30186 comm="man" requested_mask="x" 
denied_mask="x" fsuid=1000 ouid=0 target="/usr/bin/man//groff"
Feb 05 13:09:30 ripley kernel: audit: type=1400 
audit(1517789370.641:103): apparmor="DENIED" operation="exec" info="no 
new privs" error=-1 profile="/usr/bin/man" name="/usr/bin/preconv" 
pid=30186 comm="man" requested_mask="x" denied_mask="x" fsuid=1000 
ouid=0 target="/usr/bin/man//groff"
Feb 05 13:09:30 ripley audit[30187]: AVC apparmor="DENIED" 
operation="exec" info="no new privs" error=-1 profile="/usr/bin/man" 
name="/usr/bin/tbl" pid=30187 comm="man" requested_mask="x" 
denied_mask="x" fsuid=1000 ouid=0 target="/usr/bin/man//groff"
Feb 05 13:09:30 ripley kernel: audit: type=1400 
audit(1517789370.641:104): apparmor="DENIED" operation="exec" info="no 
new privs" error=-1 profile="/usr/bin/man" name="/usr/bin/tbl" pid=30187 
comm="man" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 
target="/usr/bin/man//groff"
Feb 05 13:09:30 ripley audit[30195]: AVC apparmor="DENIED" 
operation="exec" info="no new privs" error=-1 profile="/usr/bin/man" 
name="/usr/bin/troff" pid=30195 comm="groff" requested_mask="x" 
denied_mask="x" fsuid=1000 ouid=0 target="/usr/bin/man//groff"
Feb 05 13:09:30 ripley kernel: audit: type=1400 
audit(1517789370.645:105): apparmor="DENIED" operation="exec" info="no 
new privs" error=-1 profile="/usr/bin/man" name="/usr/bin/troff" 
pid=30195 comm="groff" requested_mask="x" denied_mask="x" fsuid=1000 
ouid=0 target="/usr/bin/man//groff"


With 2.7.6.1-4+b1, there are no messages.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#889617: man-db: all man pages fail to display with "command exited with status 4"

[Ben Caradoc-Davies]

Package: man-db
Version: 2.8.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

under man-db 2.8.0-1 amd64 all man pages fail to display with:

$ man man
man: command exited with status 4: /usr/lib/man-db/zsoelim | /usr/lib/man-
db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl |
nroff -mandoc -rLL=184n -rLT=184n -Tutf8

(Where "all" means all those I tested including "man", "ls", "tar", "git
commit".)

Workaround is to downgrade man-db to 2.7.6.1-4+b1.

Kind regards,
Ben.



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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 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 man-db depends on:
ii  bsdmainutils   11.1.2
ii  debconf [debconf-2.0]  1.5.65
ii  dpkg   1.19.0.5
ii  groff-base 1.22.3-9
ii  libc6  2.26-6
ii  libgdbm5   1.14.1-2
ii  libpipeline1   1.5.0-1
ii  libseccomp22.3.1-2.1
ii  zlib1g 1:1.2.8.dfsg-5

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor2.12-2
ii  firefox [www-browser]   58.0.1-1
ii  google-chrome-stable [www-browser]  64.0.3282.140-1
pn  groff   
ii  less487-0.1

-- debconf information:
  man-db/auto-update: true
  man-db/install-setuid: false

Bug#889608: man-db: man(1) dumps core (AppArmor involved)

[gregor herrmann]

On Sun, 04 Feb 2018 23:32:38 +, Colin Watson wrote:

> On Sun, Feb 04, 2018 at 11:42:57PM +0100, gregor herrmann wrote:
> > Since the upgrade to 2.8.0-1, man(1) is not really cooperative:
> Does MAN_DISABLE_SECCOMP=1 help?  

Yes, `MAN_DISABLE_SECCOMP=1 man man' just works.

> I may have made the mistake of only
> trying this with the kernel in Ubuntu 16.04, which I suspect is relevant
> here ...

In case it matters, I'm not yet running the latest kernel from
unstable (reboot missing) but linux-image-4.14.0-3-amd64 / 4.14.12-2 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#889615: python-tifffile: broken autopkgtest, broken package

[Steve Langasek]

Source: tifffile
Version: 20170914-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Dear Andreas,

Since the upload of tifffile 20170914-1, the autopkgtests for this package
hav been consistently failing in both Debian and Ubuntu.  While the test
failure is (unfortunately) not considered a blocker for Debian testing,
autopkgtest regressions are blockers for Ubuntu releases.

The failure shows that the module simply fails a python import test,
indicating that the package has missing dependencies; therefore I am marking
this bug 'serious'.

autopkgtest [19:30:42]: test python-import: [---
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.1pxu7uus/downtmp/build.LXT/src/debian/tests/python-import",
 line 5, in 
import tifffile
  File "/usr/lib/python2.7/dist-packages/tifffile.py", line 313, in 
import enum
ImportError: No module named enum
autopkgtest [19:30:42]: test python-import: ---]
autopkgtest [19:30:42]: test python-import:  - - - - - - - - - - results - - - 
- - - - - - -
python-importFAIL non-zero exit status 1

  https://ci.debian.net/packages/t/tifffile/unstable/amd64/

After installing the python-enum34 package, the autopkgtest still fails with
another import error about concurrent.futures (package:
python-concurrent.futures).

And if all of these undeclared dependencies are installed, the test still
fails:

$ ./debian/tests/python-import 
2017.09.14
Traceback (most recent call last):
  File "./debian/tests/python-import", line 16, in 
for page in tif:
TypeError: 'TiffFile' object is not iterable
$

This part looks like it might be a bug in the test rather than the package,
but without being familiar with the package it's hard for me to know.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#889616: nm.debian.org: please block DM applications until the key requirements are satisfied

[Mattia Rizzolo]

Package: nm.debian.org
X-Debbugs-Cc: debian-newma...@lists.debian.org


Currently we have 6 DM processes that have been stalled for many months
(the oldest started last May, i.e. 9 months ago) because of issues with
the applicant GPG key.
Issues range from "no signatures at all" through "no dd signatures" to
"unacceptable uid, rejected by keyring-maint".

I believe the processes should not proceed (in particular, not accept
advocacies) until the key is not valid, or manually accepted by FD.
Those 6 processes I've looked at don't show any sign of a solution in
sight, and will probably be closed by FD one of these days, causing
unhappiness for all the involved parties¹.

I don't know how the situation is in DD processes, but there seem to be
no DD processes stuck at "keycheck" in the AM dashboard, so perhaps
that's not a issue for those, but otherwise I think the same
considerations there should apply.


A quick pool in #debian-newmaint reveled no opposition, so I'm opening a
bug report requesting the feature to be implemented, and at the same
time posting this to debian-newmaint@ to check if anybody would be too
upset by the change.


¹ as the process will then have to be restart if wanted, and previous
advocacies will have to either be re-made (i.e. bother the advocate
again) or some nm.d.o admin will need to carry it over to the new
process (not going to happen), or an FD need to manually approve the
requirement (i.e. bother FD + cause confusion to everybody because the
process doesn't link any advocacy, etc).

-- 
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#889608: man-db: man(1) dumps core (AppArmor involved)

[Colin Watson]

Control: severity -1 grave

On Sun, Feb 04, 2018 at 11:42:57PM +0100, gregor herrmann wrote:
> Since the upgrade to 2.8.0-1, man(1) is not really cooperative:

Does MAN_DISABLE_SECCOMP=1 help?  I may have made the mistake of only
trying this with the kernel in Ubuntu 16.04, which I suspect is relevant
here ...

-- 
Colin Watson   [cjwat...@debian.org]

Bug#889614: ITP: libwizard-java -- Wizards API

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 

* Package name: libwizard-java
  Version : 1.0.0
  Upstream Author : Tim Boudreau
* URL : https://github.com/karchie/Wizard
* License : CDDL
  Programming Lang: Java
  Description : Wizards API

Provides a simple API and UI for Wizards, a commonly used UI pattern in GUI 
interfaces. Traditionally, everybody has needed to write their own 
Wizards from scratch, and such code is painful and hard to get right. 

This library aims to provide a simple, relatively bulletproof API 
for writing Wizards. The UI for Wizards is pluggable; the default
implementation conforms to the JLF usability guidelines for Wizards.

This library was originally designed as a replacement for NetBeans' Wizard API,
and takes into account the long history
of that API and issues encountered with it over the years. It provides a 
simple, easy-to-use solution that enables any Swing application to provide 
Wizards with a minimum of code and effort.

This library (albeit being abandonware) would be needed for VASSAL engine 
integration. Similar functionality can be provided by Netbeans, but the
API is radically different.

I'm going to maintain it by myself, not much of activity is spotten on
the upstream.

Bug#869777: yara tests fail on ARM32, when run on a 64bit kernel

[Steve Langasek]

Package: yara
Followup-For: Bug #869777
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Hi Hilko,

I've applied the following patch to yara in Ubuntu which fixes the
non-portable alignment assumptions.  This should be reasonably performant
with modern gcc on supported architectures, and on some architectures will
likely improve performance by eliminating unaligned accesses that are
supported but costly to fix up.  (This includes ARM in some configurations,
since it's possible for unaligned access to not raise SIGBUS but still be an
expensive operation.)

Please consider applying this patch in Debian.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru yara-3.7.1/debian/patches/no-unaligned-access.patch 
yara-3.7.1/debian/patches/no-unaligned-access.patch
--- yara-3.7.1/debian/patches/no-unaligned-access.patch 1969-12-31 
16:00:00.0 -0800
+++ yara-3.7.1/debian/patches/no-unaligned-access.patch 2018-02-04 
14:08:33.0 -0800
@@ -0,0 +1,118 @@
+Description: use alignment-safe handling
+ Casting a char* to a uint64_t* is not universally safe due to alignment
+ constraints on reads on some platforms.  Just use memcpy() instead, which
+ the compiler should optimize adequately for us.
+ .
+ Also, force alignment of our arena-allocated structures that contain 64-bit
+ elements.
+Author: Steve Langasek 
+
+Index: yara-3.7.1/libyara/exec.c
+===
+--- yara-3.7.1.orig/libyara/exec.c
 yara-3.7.1/libyara/exec.c
+@@ -227,7 +227,7 @@
+ break;
+ 
+   case OP_PUSH:
+-r1.i = *(uint64_t*)(ip);
++memcpy(&r1.i, ip, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ push(r1);
+ break;
+@@ -237,13 +237,13 @@
+ break;
+ 
+   case OP_CLEAR_M:
+-r1.i = *(uint64_t*)(ip);
++memcpy(&r1.i, ip, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ mem[r1.i] = 0;
+ break;
+ 
+   case OP_ADD_M:
+-r1.i = *(uint64_t*)(ip);
++memcpy(&r1.i, ip, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ if (!is_undef(r2))
+@@ -251,27 +251,27 @@
+ break;
+ 
+   case OP_INCR_M:
+-r1.i = *(uint64_t*)(ip);
++memcpy(&r1.i, ip, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ mem[r1.i]++;
+ break;
+ 
+   case OP_PUSH_M:
+-r1.i = *(uint64_t*)(ip);
++memcpy(&r1.i, ip, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ r1.i = mem[r1.i];
+ push(r1);
+ break;
+ 
+   case OP_POP_M:
+-r1.i = *(uint64_t*)(ip);
++memcpy(&r1.i, ip, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ mem[r1.i] = r2.i;
+ break;
+ 
+   case OP_SWAPUNDEF:
+-r1.i = *(uint64_t*)(ip);
++memcpy(&r1.i, ip, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ 
+@@ -859,7 +859,7 @@
+ break;
+ 
+   case OP_IMPORT:
+-r1.i = *(uint64_t*)(ip);
++memcpy(&r1.i, ip, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ 
+ result = yr_modules_load((char*) r1.p, context);
+@@ -902,7 +902,7 @@
+ break;
+ 
+   case OP_INT_TO_DBL:
+-r1.i = *(uint64_t*)(ip);
++memcpy(&r1.i, ip, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ r2 = stack[sp - r1.i];
+ if (is_undef(r2))
+Index: yara-3.7.1/libyara/scan.c
+===
+--- yara-3.7.1.orig/libyara/scan.c
 yara-3.7.1/libyara/scan.c
+@@ -397,8 +397,11 @@
+ 
+   FAIL_ON_ERROR(yr_arena_allocate_memory(
+   context->matches_arena,
+-  sizeof(YR_MATCH),
++  sizeof(YR_MATCH) + sizeof(uint64_t) - 1,
+   (void**) &new_match));
++  /* force alignment */
++  new_match = (YR_MATCH *)(((size_t)new_match + sizeof(uint64_t) - 1)
++  & ~(sizeof(uint64_t) - 1));
+ 
+   new_match->data_length = yr_min(match_length, MAX_MATCH_DATA);
+ 
+@@ -500,8 +503,11 @@
+ 
+ FAIL_ON_ERROR(yr_arena_allocate_memory(
+ callback_args->context->matches_arena,
+-sizeof(YR_MATCH),
++sizeof(YR_MATCH) + sizeof(uint64_t) - 1,
+ (void**) &new_match));
++/* force alignment */
++new_match = (YR_MATCH *)(((size_t)new_match + sizeof(uint64_t) - 1)
++& ~(sizeof(uint64_t) - 1));
+ 
+ new_match->data_length = yr_min(match_length, MAX_MATCH_DATA);
+ 
diff -Nru yara-3.7.1/debian/patches/series yara-3.7.1/debian/patches/series
--- yara-3.7.1/debian/patches/series2018-01-16 04:45:26.0 -0800
+++ yara-3.7.1/debian/pa

Bug#889613: ITP: swiglpk -- Plain Python bindings for the GNU Linear Programming Kit

[Afif Elghraoui]

Package: wnpp
Owner: Afif Elghraoui 
Severity: wishlist

* Package name: swiglpk
  Version : 1.4.4
  Upstream Author : The Novo Nordisk Foundation Center for Biosustainability
* URL : https://github.com/biosustain/swiglpk
* License : GPL
  Programming Lang: Python
  Description : Plain Python bindings for the GNU Linear Programming Kit

swiglpk just provides plain SWIG bindings to the underlying C library
of the GNU Linear Programming Kit. It is not a high-level wrapper for GLPK.

This is a dependency of optlang and a new dependency of python-cobra. It
will be maintained by the Debian Science team.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#889607: no such package as sse-support, just sse2/3/4.2

[Afif Elghraoui]

Control: tag -1 + moreinfo

Hello,

على الأحد  4 شباط 2018 ‫17:56، كتب Adam Borowski:
> Hi!
>> nanopolish [:i386]
>> The package would not migrate to testing because it was not installable
>> on i386 for lack of sse-support.
> 
> There never was a package by that name.  The only variants are sse2-support
> [any-i386] sse3-support [any-i386 any-amd64] sse4.2-support [any-i386
> any-amd64] and stuff for architectures you're not interested in.
> 
> I really doubt you're looking for sse1 in particular -- I expect your
> package uses a newer variant; a package of this kind doesn't really care
> about CPUs so old anyway, thus the distinction doesn't matter.
> 
> (Note that marking packages that use a non-base CPU extension this way is
> controversial -- but no one implemented a better solution yet.)
> 

Thanks for pointing that out. I have to see what my co-maintainer had in
mind when adding this.

> 
> As for this RM, it won't work as your package still tries to build on i386,
> which will reintroduce nanopolish:i386 as soon as ftpmasters remove it.
> Thus, you'd need to upload a new version first.

I already did an upload before filing this bug, so it's now showing as
BD-Uninstallable on i386.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#889612: jenkins.debian.org: reproducible: maint_debian-qa packageset links to adopted packages

[Mattia Rizzolo]

Package: jenkins.debian.org
Severity: important
User: jenkins.debian@packages.debian.org
Usertags: reproducible
Control: submitter -1 Reiner Herrmann 
X-Debbugs-Cc: Reiner Herrmann 

https://tests.reproducible-builds.org/debian/unstable/amd64/pkg_set_maint_debian-qa.html
links some packages that have been adopted.

At this time it can be seen with src:crack and src:libopenobex.
The reason is that the Sources index file lists multiple version, one of
which has Maintainer:packa...@qa.debian.org.  There are multiple reason
to have an old source version hanging on in the index, the most common
being that some architectures are not up to date (kbsd-amd64/kbsd-i386
being a very common one these days).  Also, Extra-Source-Only.

I suspect other maintainer-based pkgsets are affected by this bug.

The thing building up the packagesets list should:
 1) ignore Extra-Source-Only:yes sources
 2) only consider the oldest version available

Note that its important for both of these conditions to be met in this
order, as technically speaking a given suite could have:
|Package: foo
|Version: 1
|
|Package: foo
|Version: 2
|Extra-Source-Only: yes
(despite being a very rare situation).


Thanks to Reiner Herrmann for reporting this issue.

-- 
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#889592: lintian: false positive for override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES

[gregor herrmann]

On Mon, 05 Feb 2018 00:10:21 +0100, Mattia Rizzolo wrote:

> > Very quick visual check: All I've seen use dh_auto_test, either with
> > some variables or with some actions before or after.
> If there are actions before or after dh_auto_test then it may still be
> "unsafe":  

Yes, they may, or they may not.

Second cursory visual check:

Mostly `mkdir -p $(BUILDHOME)'.
Some `mv file file.bak' before and the opposite afterwards. A `chmod'
or two of an existing file.

Ok, +/- 2 hardcoded `make test'.
2 hits for over 300 false positives sound like there's room for
improvement.

> I've seen package running `make -C test` before dh_auto_test,
> that one should be skipped if DEB_BUILD_OPTIONS=nocheck.

Ack.

> Or that try to move some test artifact after dh_auto_test: that would
> actually cause a ftbfs if dh_auto_test did nothing.

Yup, I've seen this in other packages.

> The only "safe" cases of command that are fine to run in an
> override_dh_auto_test are : and echo (if not redirected to a file).

Here I disagree. 


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#889592: lintian: false positive for override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES

[Chris Lamb]

tags 889592 + pending
thanks

"Fixed" in Git, pending upload:

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

Ah well, just too many false-positive cases.. I mean, we'd have to start
ignoring ": " comments, as well as detecting the differences between, say:

override_dh_auto_test:
  echo "input" | ./testsuite.sh

and

override_dh_auto_test:
  echo "Not running"

etc. etc. :)


Regards,

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

Bug#889611: ITP: optlang -- sympy-based mathematical programming language

[Afif Elghraoui]

Package: wnpp
Owner: Afif Elghraoui 
Severity: wishlist

* Package name: optlang
  Version : 1.3.0
  Upstream Author : Novo Nordisk Foundation Center for Biosustainability
* URL : http://optlang.readthedocs.org/
* License : Apache

  Programming Lang: Python

  Description : sympy-based mathematical programming language

Optlang is a Python package for solving mathematical optimization
problems, i.e. maximizing or minimizing an objective function over a set
of variables subject to a number of constraints. Optlang provides a
common interface to a series of optimization tools, so different solver
backends can be changed in a transparent way. Optlang's object-oriented
API takes advantage of the symbolic math library sympy to allow
objective functions and constraints to be easily formulated from
symbolic expressions of variables (see examples).

This is a new dependency of python-cobra. It will be maintained under
Debian Science.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#889592: lintian: false positive for override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES

[Mattia Rizzolo]

On Mon, Feb 05, 2018 at 12:03:56AM +0100, gregor herrmann wrote:
> % grep override_dh_auto_test */debian/rules | wc -l
> 321
> 
> Very quick visual check: All I've seen use dh_auto_test, either with
> some variables or with some actions before or after.

If there are actions before or after dh_auto_test then it may still be
"unsafe":  I've seen package running `make -C test` before dh_auto_test,
that one should be skipped if DEB_BUILD_OPTIONS=nocheck.
Or that try to move some test artifact after dh_auto_test: that would
actually cause a ftbfs if dh_auto_test did nothing.
The only "safe" cases of command that are fine to run in an
override_dh_auto_test are : and echo (if not redirected to a file).

-- 
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#889610: tesseract-ocr-srp-latn: uninstallable in sid: Depends: tesseract-srp (>= 3.99) which is unknown

[Andreas Beckmann]

Package: tesseract-ocr-srp-latn
Version: 4.00~git15-45ed289-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

The following packages have unmet dependencies:
 tesseract-ocr-srp-latn : Depends: tesseract-srp (>= 3.99) which is a virtual 
package and is not provided by any available package


Cheers,

Andreas

Bug#889592: lintian: false positive for override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES

[gregor herrmann]

On Sun, 04 Feb 2018 21:29:23 +0100, Mattia Rizzolo wrote:

> https://tracker.debian.org/media/packages/a/autoconf-dickey/rules-2.52%2B20170501-2
> https://tracker.debian.org/media/packages/a/avro-c/rules-1.8.2-1
> Not sure why this is matched, I thought it wouldn't have been:
> |override_dh_auto_test:
> | dh_auto_test --no-parallel
> 
> https://tracker.debian.org/media/packages/libx/libxcb/rules-1.12-1
> Similar to the previous:
> |override_dh_auto_test:
> | dh_auto_test -- VERBOSE=1

This will affect dozens or hundreds of perl packages. [0]

First encounter right now:

I: librole-rest-client-perl source: 
override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES (line 6)

and

% cat debian/rules 
#!/usr/bin/make -f

%:
dh $@

override_dh_auto_test:
http_proxy= dh_auto_test


Emitting this tag when dh_auto_test is contained within override_dh_auto_test
seems not ideal.



Cheers,
gregor

[0] First approximation:

% grep override_dh_auto_test */debian/rules | wc -l
321

Very quick visual check: All I've seen use dh_auto_test, either with
some variables or with some actions before or after.

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


signature.asc
Description: Digital Signature

Bug#889609: moonshot-gss-eap: uninstallable in sid: libgssapi-krb5-2 : Breaks: moonshot-gss-eap (<= 1.0) but 0.9.5-3+b1 is to be installed

[Andreas Beckmann]

Package: moonshot-gss-eap
Version: 0.9.5-3
Severity: serious
Tags: sid
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

The following packages have unmet dependencies:
 libgssapi-krb5-2 : Breaks: moonshot-gss-eap (<= 1.0) but 0.9.5-3+b1 is to be 
installed

This can probably be fixed by migrating the packages from experimental
to sid ...


Cheers,

Andreas

Bug#889591: lintian: emits package-does-not-install-examples although all examples are installed

[Chris Lamb]

tags 889591 + pending
thanks

Fixed in Git, pending upload:

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


Regards,

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

Bug#889144: stricter PIDfile handling breaks several daemons

[Simon Kelley]

On 04/02/18 20:26, Sven Hartge wrote:

> Does dnsmasq need a PIDfile when running under systemd? Can't it just
> not double fork, stay in the foreground using a Type=simple systemd unit?
> 
> That way the whole problem could be avoided all together.
> 

Sending signals to the dnsmasq process cause it to take various actions,
so it's likely that there are scripts out there that do the equivalent of

kill - `cat /run/dnsmasq/dnsmasq.pid`

The double-fork code in dnsmasq is also quite careful about error
handling; for instance passing an error code back through a pipe from
the forked process to the original process, so that any failure gets
reflected in the return code when the original process exits. That's
relevant to Michael's point, I think.

Cheers,

Simon.

Bug#889607: no such package as sse-support, just sse2/3/4.2

[Adam Borowski]

Hi!
> nanopolish [:i386]
> The package would not migrate to testing because it was not installable
> on i386 for lack of sse-support.

There never was a package by that name.  The only variants are sse2-support
[any-i386] sse3-support [any-i386 any-amd64] sse4.2-support [any-i386
any-amd64] and stuff for architectures you're not interested in.

I really doubt you're looking for sse1 in particular -- I expect your
package uses a newer variant; a package of this kind doesn't really care
about CPUs so old anyway, thus the distinction doesn't matter.

(Note that marking packages that use a non-base CPU extension this way is
controversial -- but no one implemented a better solution yet.)


As for this RM, it won't work as your package still tries to build on i386,
which will reintroduce nanopolish:i386 as soon as ftpmasters remove it.
Thus, you'd need to upload a new version first.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Bug#781909: NMU dropping python-zeitgeist package

[Jeremy Bicha]

>From what I can tell, python-zeitgeist isn't being used. It's better
for apps to switch to gir1.2-zeitgeist-2.0 instead. Switching to
GObject Introspection basically means switching from gtk2 to gtk3 too.

I am uploading an NMU to do this to the DEFERRED/15 queue. Please let
me know if I should speed up or slow down this upload. git patches
attached for my changes.

Thanks,
Jeremy Bicha
From 213b4d2ab81ce20935ea110795d39c54ef7d80ce Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Sun, 4 Feb 2018 17:47:11 -0500
Subject: [PATCH 1/3] Drop python-zeitgeist package (Closes: #781909)

---
 debian/changelog|  7 +++
 debian/control  | 22 --
 debian/python-zeitgeist.install |  1 -
 debian/rules|  1 +
 4 files changed, 8 insertions(+), 23 deletions(-)
 delete mode 100644 debian/python-zeitgeist.install

diff --git a/debian/changelog b/debian/changelog
index de65579..f3a4dc1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+zeitgeist (1.0-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python-zeitgeist package (Closes: #781909)
+
+ -- Jeremy Bicha   Sun, 04 Feb 2018 17:43:48 -0500
+
 zeitgeist (1.0-0.1) unstable; urgency=medium
 
   [ Jeremy Bicha ]
diff --git a/debian/control b/debian/control
index 8806363..39a49bc 100644
--- a/debian/control
+++ b/debian/control
@@ -31,7 +31,6 @@ Package: zeitgeist
 Architecture: all
 Depends: ${misc:Depends},
  zeitgeist-core,
- python-zeitgeist,
  zeitgeist-datahub
 Description: event logging framework
  Zeitgeist is a service which logs the user's activities and events (files
@@ -63,27 +62,6 @@ Description: event logging framework - engine
  codenamed "Bluebird"). It also includes the FTS (Full Text Search)
  extension.
 
-Package: python-zeitgeist
-Architecture: all
-Section: python
-Depends: ${misc:Depends},
- ${python:Depends},
- python-xdg,
- python-dbus,
- python-gobject-2,
- python-gi
-Replaces: zeitgeist-core (<< 0.8.99~alpha1)
-Breaks: zeitgeist-core (<< 0.8.99~alpha1)
-Description: event logging framework - Python bindings
- Zeitgeist is a service which logs the user's activities and events (files
- opened, websites visited, conversations held with other people, etc.) and
- makes the relevant information available to other applications.
- .
- It serves as a comprehensive activity log and also makes it possible to
- determine relationships between items based on usage patterns.
- .
- This package contains the Python API.
-
 Package: libzeitgeist-2.0-0
 Section: libs
 Architecture: any
diff --git a/debian/python-zeitgeist.install b/debian/python-zeitgeist.install
deleted file mode 100644
index 607c065..000
--- a/debian/python-zeitgeist.install
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib/python*
diff --git a/debian/rules b/debian/rules
index 7e8eb77..8797e5d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,4 +14,5 @@ override_dh_strip:
 	dh_strip --dbgsym-migration='libzeitgeist-2.0-0-dbg (<< 1.0-0.1~)'
 
 override_dh_install:
+	rm -rf debian/tmp/usr/lib/python*
 	dh_install -X".trig" -X".la" -X".pyc" -X".pyo" --fail-missing
-- 
2.15.1

From 5677d61cf44ca45798edf2694f8eefb6d101352b Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Sun, 4 Feb 2018 17:48:17 -0500
Subject: [PATCH 2/3] Use Launchpad site as homepage (LP: #1744536)

---
 debian/changelog | 1 +
 debian/control   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index f3a4dc1..7e4e40f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ zeitgeist (1.0-0.2) UNRELEASED; urgency=medium
 
   * Non-maintainer upload.
   * Drop python-zeitgeist package (Closes: #781909)
+  * Use Launchpad site as homepage (LP: #1744536)
 
  -- Jeremy Bicha   Sun, 04 Feb 2018 17:43:48 -0500
 
diff --git a/debian/control b/debian/control
index 39a49bc..66055a1 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,7 @@ Build-Depends: debhelper (>= 10),
  raptor2-utils,
  valac (>= 0.22),
  valadoc
-Homepage: http://zeitgeist-project.com/
+Homepage: https://launchpad.net/zeitgeist-project
 Standards-Version: 4.1.1
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/zeitgeist.git
 Vcs-Browser: https://anonscm.debian.org/git/collab-maint/zeitgeist.git
-- 
2.15.1

From 5798dc4388bd115bea7d52ca059c5062d8c70eb1 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Sun, 4 Feb 2018 17:48:26 -0500
Subject: [PATCH 3/3] releasing package zeitgeist version 1.0-0.2

---
 debian/changelog | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 7e4e40f..87e4f44 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,10 +1,10 @@
-zeitgeist (1.0-0.2) UNRELEASED; urgency=medium
+zeitgeist (1.0-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
   * Drop python-zeitgeist package (Closes: #781909)
   * Use Launchpad site as homepage (LP: #1744536)
 
- -- Jeremy Bicha   Sun, 04 Feb 2018 17:

Bug#810890: BE SECURE

[jorge . julian . sanchez]

HEY.
 LOOK WHAT PEOPLE ARE SAYING AND DOING BEHIND YOUR BACK 
 I THOUGHT YOU SHOULD KNOW, YOUR PHOTOS AND VIDEOS ARE ALL DISPLAYED
 IF YOU ARE NOT SUPPORT OF IT KINDLY REPORT TO US SO THAT WE CAN  
DELETE THE PHOTOS AND VIDEOS BEFORE IT GOES VIRAL  


Click here[1] to see what is going on 

http://caravel-transportation.com/vF0eE//WfZ8a2MXtbgOv6N/gm/en/?i=2553842


Links:
--
[1] http://caravel-transportation.com/vF0eE//WfZ8a2MXtbgOv6N/gm/en/?i=2553842

Bug#889608: man-db: man(1) dumps core (AppArmor involved)

[gregor herrmann]

Package: man-db
Version: 2.8.0-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since the upgrade to 2.8.0-1, man(1) is not really cooperative:

%man man

output in pager:
man: /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE: Bad system 
call (core dumped)

% man --debug man

full output in the console:

ruid=1000, euid=6
rgid=1000, egid=12
drop_effective_privs()
++priv_drop_count = 1
>From the config file /etc/manpath.config:

Mandatory mandir `/usr/man'.
Mandatory mandir `/usr/share/man'.
Mandatory mandir `/usr/local/share/man'.
Path `/bin' mapped to mandir `/usr/share/man'.
Path `/usr/bin' mapped to mandir `/usr/share/man'.
Path `/sbin' mapped to mandir `/usr/share/man'.
Path `/usr/sbin' mapped to mandir `/usr/share/man'.
Path `/usr/local/bin' mapped to mandir `/usr/local/man'.
Path `/usr/local/bin' mapped to mandir `/usr/local/share/man'.
Path `/usr/local/sbin' mapped to mandir `/usr/local/man'.
Path `/usr/local/sbin' mapped to mandir `/usr/local/share/man'.
Path `/usr/X11R6/bin' mapped to mandir `/usr/X11R6/man'.
Path `/usr/bin/X11' mapped to mandir `/usr/X11R6/man'.
Path `/usr/games' mapped to mandir `/usr/share/man'.
Path `/opt/bin' mapped to mandir `/opt/man'.
Path `/opt/sbin' mapped to mandir `/opt/man'.
Global mandir `/usr/man', catdir `/var/cache/man/fsstnd'.
Global mandir `/usr/share/man', catdir `/var/cache/man'.
Global mandir `/usr/local/man', catdir `/var/cache/man/oldlocal'.
Global mandir `/usr/local/share/man', catdir `/var/cache/man/local'.
Global mandir `/usr/X11R6/man', catdir `/var/cache/man/X11R6'.
Global mandir `/opt/man', catdir `/var/cache/man/opt'.
Added section `1'.
Added section `n'.
Added section `l'.
Added section `8'.
Added section `3'.
Added section `2'.
Added section `3posix'.
Added section `3pm'.
Added section `3perl'.
Added section `3am'.
Added section `5'.
Added section `4'.
Added section `9'.
Added section `6'.
Added section `7'.
`/usr/man'  `'  `1'
`/usr/share/man'`'  `1'
`/usr/local/share/man'  `'  `1'
`/bin'  `/usr/share/man'`0'
`/usr/bin'  `/usr/share/man'`0'
`/sbin' `/usr/share/man'`0'
`/usr/sbin' `/usr/share/man'`0'
`/usr/local/bin'`/usr/local/man'`0'
`/usr/local/bin'`/usr/local/share/man'  `0'
`/usr/local/sbin'   `/usr/local/man'`0'
`/usr/local/sbin'   `/usr/local/share/man'  `0'
`/usr/X11R6/bin'`/usr/X11R6/man'`0'
`/usr/bin/X11'  `/usr/X11R6/man'`0'
`/usr/games'`/usr/share/man'`0'
`/opt/bin'  `/opt/man'  `0'
`/opt/sbin' `/opt/man'  `0'
`/usr/man'  `/var/cache/man/fsstnd' `-1'
`/usr/share/man'`/var/cache/man'`-1'
`/usr/local/man'`/var/cache/man/oldlocal'   `-1'
`/usr/local/share/man'  `/var/cache/man/local'  `-1'
`/usr/X11R6/man'`/var/cache/man/X11R6'  `-1'
`/opt/man'  `/var/cache/man/opt'`-1'
`1' `'  `-5'
`n' `'  `-5'
`l' `'  `-5'
`8' `'  `-5'
`3' `'  `-5'
`2' `'  `-5'
`3posix'`'  `-5'
`3pm'   `'  `-5'
`3perl' `'  `-5'
`3am'   `'  `-5'
`5' `'  `-5'
`4' `'  `-5'
`9' `'  `-5'
`6' `'  `-5'
`7' `'  `-5'
is a tty
real user = 1000; effective user = 6

using most as pager

path directory /home/gregoa/bin is not in the config file
and doesn't have ../man, man, ../share/man, or share/man subdirectories

path directory /usr/lib/ccache is not in the config file
and doesn't have ../man, man, ../share/man, or share/man subdirectories

path directory /usr/local/bin is in the config file
warning: /usr/local/man: No such file or directory
warning: /usr/local/share/man: No such file or directory

path directory /usr/bin is in the config file
adding /usr/share/man to manpath

path directory /bin is in the config file
/usr/share/man is already in the manpath

path directory /usr/local/games is not in the config file
and doesn't have ../man, man, ../share/man, or share/man subdirectories

path directory /usr/games is in the config file
/usr/share/man is already in the manpath

adding mandatory man directories

warning: /usr/man: No such file or directory
/usr/share/man is already in the manpath
warning: /usr/local/share/man: No such file or directory
add_nls_manpaths(): processing /usr/share/man
checking for locale C
manpath search path (with duplicates) = /usr/share/man:/usr/share/man
adding /usr/share/man to manpathlist
adding /usr/share/man to manpathlist
Removing duplicate manpath entry /usr/share/man (1) -> /usr/share/man (0)
final search path = /usr/share/man
- --priv_drop_count = 0
regain_effective_privs()
searching in /usr/share/man, section 1
trying section 1 with globbing
Layout is GNU (1)
update_directory_cache /usr/share/man: miss
globbing pattern in /usr/share/man: man1*
matched: /usr/share/man/man1
update_directory_cache /usr/share/man/man1: miss
globbing pattern in /usr/share/man/man1: man.1*
matched: /usr/share/man/man1/

Bug#889598: plasma-desktop: FTBFS problems finding AppStreamQt

[Andreas Beckmann]

On 2018-02-04 23:02, Matthias Klumpp wrote:
> This bug was fixed in appstream quite a while ago, looking at the full
> buildlog one can see that an old version of the appstream package was
> used for building. Therefore, I think this bug can be closed. If the
> issue persists with the version of AppStream that is currently in
> testing/unstable, please reopen the issue (ideally with a fresh build
> log).
> See issue #888144 for details on the original bug.

Aargh, missed to reschedule this build yesterday and filed the bug for
the "persistent" problem today without checking build log date ...

Sorry for the noise.

Andreas

Bug#847520: please consider naming the new section go, not golang

[Michael Stapelberg]

Hi Matthias,

Matthias Klose  writes:
> Please could you consider using go as new tag name?  golang resembles too much
> to one particular implementation name.  For other languages we have python, 
> not
> cpython, pypy, jython, we have java, not openjdk.

Indeed, the language is called Go, and golang is the web site address:
https://twitter.com/rob_pike/status/886054143235719169

I agree that the new section should ideally be called “Go”.

Guillem, thanks for sending the patches in the blocker bugs. Could you
update them to use “Go” instead of “golang” please?

Let me know if you’d prefer me to post updated versions.

-- 
Best regards,
Michael

Bug#889606: mupen64plus-video-glide64mk2: uninstallable in sid: virtual package libtxc-dxtn0 is no longer provided

[Andreas Beckmann]

Package: mupen64plus-video-glide64mk2
Version: 2.5-4
Severity: serious
Tags: sid buster
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

The following packages have unmet dependencies:
 mupen64plus-video-glide64mk2 : Depends: libtxc-dxtn0 but it is not installable

libtxc-dxtn0 was provided by libtxc-dxtn-s2tc which has been
removed from sid.


Cheers,

Andreas

Bug#889607: RM: nanopolish [i386] -- ROM; sse-support not available

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal

The package would not migrate to testing because it was not installable
on i386 for lack of sse-support.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#889605: libreoffice: FTBFS on m68k: udkapi.rdb build fails ("Bad input")

[Aaron M. Ucko]

Source: libreoffice
Version: 1:6.0.0-1
Severity: normal
Tags: upstream
User: debian-...@lists.debian.org
Usertags: m68k
Control: forwarded -1 https://bugs.documentfoundation.org/show_bug.cgi?id=115450

Builds of libreoffice for m68k (admittedly not a release architecture)
have been failing lately:

  [build DBc] udkapi
  mkdir -p /<>/workdir/UnoApiTarget/  && 
RESPONSEFILE=/tmp/gbuild.RTQBLH && 
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"/<>/instdir/program:/<>/instdir/program"
   /<>/workdir/LinkTarget/Executable/unoidl-write  
/<>/udkapi @${RESPONSEFILE} 
/<>/workdir/UnoApiTarget/udkapi.rdb && rm -f ${RESPONSEFILE}   && 
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"/<>/instdir/program:/<>/instdir/program"
   /<>/instdir/sdk/bin/unoidl-check 
/<>/udkapi/type_reference/udkapi.idl --  
/<>/workdir/UnoApiTarget/udkapi.rdb
  [build MOD] codemaker
  Bad input 
>/udkapi/com/sun/star/reflection/TypeDescriptionSearchDepth.idl>:
 cannot parse line 37: "out-of-range enum 
com.sun.star.reflection.TypeDescriptionSearchDepth member INFINITE value 
9223372036854775807"
  /<>/solenv/gbuild/UnoApiTarget.mk:45: recipe for target 
'/<>/workdir/UnoApiTarget/udkapi.rdb' failed
  make[2]: *** [/<>/workdir/UnoApiTarget/udkapi.rdb] Error 1
  make[2]: *** Waiting for unfinished jobs

Per the official bug-reporting instructions, I already reported this
bug upstream (as #115450), and have marked this bug as forwarded
accordingly.

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#889604: nmu: ppl_1:1.2-2 logol_1.7.7-1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu ppl_1:1.2-2 . ANY . unstable . -m "Rebuild against swi-prolog-nox 7.6.4"
nmu logol_1.7.7-1 . ANY . unstable . -m "Rebuild against swi-prolog-nox 7.6.4"

They have strict dependncies on the swi-prolog upstream version used
during build.


Andreas

Bug#887461: btrfsmaintenance: blindly assumes systemd

[Nicholas D Steeves]

Hi Adam,

I've uploaded a new upstream release of btrfsmaintenance with many
changes.  Please close this bug if it addresses the issues raised in
this bug report, or alternatively retitle this bug to something
concrete and true ;-)

tldl; "Depends: systemd | cron", and upstream maintains that
btrfsmaintenance must not use both at the same time.

Because Debian defaults to systemd, I believe that is a reasonable
default.  Also, if btrfsmaintenance ever requires patching to function
without systemd I will search for someone to maintain a
btrfsmaintenance-nosystemd variant...and of course, you'll be the
first person I'll ask!

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#889487: linux-image-4.14.0-2-amd64: please enable CONFIG_X86_MCELOG_LEGACY

[Ben Hutchings]

Control: reassign -1 rasdaemon
Control: retitle -1 rasdaemon: Please add an init script
Control: tag -1 - wontfix

On Sat, 2018-02-03 at 20:41 -0500, Jon DeVree wrote:
> On Sun, Feb 04, 2018 at 01:03:59 +0100, Ben Hutchings wrote:
> > Control: severity -1 wishlist
> > Control: tag -1 wontfix
> > 
> > On Sat, 2018-02-03 at 14:32 -0500, Jon wrote:
> > > Package: src:linux
> > > Version: 4.14.7-1
> > > Severity: normal
> > > 
> > > Please enable CONFIG_X86_MCELOG_LEGACY so that /dev/mcelog exists again.
> > > 
> > > It seems this functionality was seperated from CONFIG_X86_MCE in 4.12
> > > and is not enabled by default. I don't see it explicitly set one way or
> > > another in the debian kernel source repo and no mention of it in the
> > > changelog, so I assume that not enabling it is unintentional
> > 
> > This was unintentional, but I think it's correct.  The Kconfig says to
> > use rasdaemon which is already packaged and in stable.
> > 
> > Ben.
> > 
> 
> rasdaemon has a hard dependency on systemd, it isn't installable on
> machines still running sysvinit.
> 
> Not sure if thats a hard dep or if it only just means rasdaemon is
> missing a sysvinit script.

From a quick look at the code, I think it just lacks a sysvinit script.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



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

Bug#889603: texlive-latex-extra: ucs support for Unicode character U+200A (hair space)?

[Petter Reinholdtsen]

Package: texlive-latex-extra
Version: 2017.20180110-1

While typesetting a book using the odf->md->docbook->dblatex path, I ran
into this error from LaTeX:

  [127] (/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uninames.dat)
  (/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uni-32.def)

  ! Package ucs Error: Unknown Unicode character 8202 = U+200A,
  (ucs)possibly declared in uni-32.def.
  (ucs)Type H to see if it is available with options.

  See the ucs package documentation for explanation.
  Type  H   for immediate help.
   ...  
  
  l.6839   for noncommercial use 
   — and there have been many, many do...

  ? 

The problematic character is the HTML entity  , unicode character
U+200A, also known as hair space.

Could ucs be extended to understand this Unicode character?

I found some notes on LaTeX and hair space in
http://www.read.seas.harvard.edu/~kohler/latex.html > which might
be useful. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#889601: RM: python-oerplib -- ROM; abandoned upstream, alternative exists

[W. Martin Borgert]

Package: ftp.debian.org
Severity: normal

Please use python-odoorpc by same author instead of this package.

Bug#889602: python-cloudkitty: uninstallable in sid: Depends: python-sqlalchemy (< 1.1.0) but 1.1.11+ds1-1 is to be installed

[Andreas Beckmann]

Package: python-cloudkitty
Version: 6.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is not
installable in sid:

The following packages have unmet dependencies:
 python-cloudkitty : Depends: python-sqlalchemy (< 1.1.0) but 1.1.11+ds1-1 is 
to be installed


Cheers,

Andreas

Bug#889144: stricter PIDfile handling breaks several daemons

[Michael Biebl]

Am 04.02.2018 um 21:26 schrieb Sven Hartge:
> On Sun, 4 Feb 2018 15:41:37 + Simon Kelley 
> wrote:
> 
>> With my dnsmasq maintainer hat on, the current arrangement looks like this.
>>
>> 1) /run/dnsmasq is a directory owned by dnsmasq:nogroup
>> 2) /run/dnsmasq/dnsmasq.pid gets written by dnsmasq before it drops
>> root, so is root:root
>> 3) The reason /run/dnsmasq is owned by dnsmasq is so that dnsmasq can
>> unlink the pidfile at shutdown, after it has dropped root and is running
>> as 'dnsmasq'
> 
> Does dnsmasq need a PIDfile when running under systemd? Can't it just
> not double fork, stay in the foreground using a Type=simple systemd unit?
> 
> That way the whole problem could be avoided all together.

If other services depend on dnsmasq, please keep
https://www.lucas-nussbaum.net/blog/?p=877 in mind




-- 
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#889600: btrfsmaintenance/0.4-1~exp1 [I maintain the package]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

Dear Marc and Sven,

I have CCed you because you sponsored previous releases of this
package.

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

It builds this binary package:

btrfsmaintenance - automate btrfs maintenance tasks on mountpoints or 
directories

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

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

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

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

Alternatively, one can clone this package's git repo using this command:

   git clone https://salsa.debian.org/sten-guest/btrfsmaintenance.git \
   && git checkout experimental

More information about btrfsmaintenance can be obtained from 
https://github.com/kdave/btrfsmaintenance.

Changes since the last upload:

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

  * New upstream version.
  * Install new systemd service that detects changes to config.
  * Install all services, timers, and watch units in a deactivated state.
  * Declare compat level 11.
  * Switch to debhelper 11.
  * debian/rules: Drop --with systemd, because dh 11 uses
dh_installsystemd, and use dh_installsystemd to install units.
  * Change Depends to systemd | cron (was cron).
  * Cleanup any enabled maintenance systemd units during postrm.
  * debian/rules: Add a commented-out stanza to in preparation for
the next upstream version, which will provide an upstream
changelog that debhelper might not detect.
  * Update README.Debian to be more clear and informative.
  * Patch watch file to watch /etc/default instead of /etc/sysconfig.
  * Cleanup /etc/systemd/system/btrfs-operation.timer.d in postrm
  * Switch Vcs from alioth to salsa.
  * Add NEWS.Debian to inform all users about new systemd support.

 -- Nicholas D Steeves   Sun, 04 Feb 2018 16:28:46 -0500

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


Regards,
Nicholas D Steeves

Bug#889599: RM: python-mpld3 -- ROM; abandoned upstream

[W. Martin Borgert]

Package: ftp.debian.org
Severity: normal

The github page states:
> Note: mpld3 is no longer being actively maintained: feature
> requests & bug reports are likely to go unanswered.

Bug#889598: plasma-desktop: FTBFS problems finding AppStreamQt

[Andreas Beckmann]

Source: plasma-desktop
Version: 4:5.11.4-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

plasma-desktop/experimental recently started to FTBFS:

from the attached buidlog:

[...]
-- The following RECOMMENDED packages have been found:

 * AppStreamQt (required version >= 0.10.4), Appstream integration
   Needed to allow appstream integration from application menus
 * KF5Baloo (required version >= 5.15), File Searching
   Needed to build the File Search KCM
[...]
[ 37%] Linking CXX shared library libkickerplugin.so
cd /build/plasma-desktop-5.11.4/obj-x86_64-linux-gnu/applets/kicker && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/kickerplugin.dir/link.txt 
--verbose=1
/usr/bin/c++ -fPIC -g -O2 -fdebug-prefix-map=/build/plasma-desktop-5.11.4=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c++0x -fno-operator-names -fno-exceptions -Wall 
-Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long 
-Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual 
-Werror=return-type -Wvla -Wdate-time -Wl,--no-undefined -Wl,--fatal-warnings 
-Wl,--enable-new-dtags -Wl,-z,relro -shared -Wl,-soname,libkickerplugin.so -o 
libkickerplugin.so CMakeFiles/kickerplugin.dir/plugin/abstractentry.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/abstractmodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/actionlist.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/appentry.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/appsmodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/computermodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/contactentry.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/containmentinterface.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/draghelper.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/simplefavoritesmodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/kastatsfavoritesmodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/fileentry.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/forwardingmodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/placeholdermodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/funnelmodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/dashboardwindow.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/kickerplugin.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/menuentryeditor.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/processrunner.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/rootmodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/runnermodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/runnermatchesmodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/recentcontactsmodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/recentusagemodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/submenu.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/systementry.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/systemmodel.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/systemsettings.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/wheelinterceptor.cpp.o 
CMakeFiles/kickerplugin.dir/plugin/windowsystem.cpp.o 
CMakeFiles/kickerplugin.dir/krunner_interface.cpp.o 
CMakeFiles/kickerplugin.dir/ksmserver_interface.cpp.o 
CMakeFiles/kickerplugin.dir/kickerplugin_autogen/mocs_compilation.cpp.o 
/usr/lib/x86_64-linux-gnu/libKF5ActivitiesStats.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5ItemModels.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5KDELibs4Support.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5PeopleWidgets.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5PlasmaQuick.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5Runner.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libkworkspace5.so.5.10.5 AppStreamQt-NOTFOUND 
/usr/lib/x86_64-linux-gnu/libKF5Activities.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5Crash.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5KIOFileWidgets.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5Bookmarks.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5UnitConversion.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5Parts.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5People.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5Solid.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5Plasma.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5Notifications.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5.9.2 
/usr/lib/x86_64-linux-gnu/libKF5TextWidgets.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5SonnetUi.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.9.2 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5.9.2 
/usr/lib/x86_64-linux-gnu/libKF5KIOWidgets.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5Service.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libQt5Network.so.5.9.2 
/usr/lib/x86_64-linux-gnu/libKF5Completion.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5JobWidgets.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5IconThemes.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5ConfigWidgets.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5.41.0 
/usr/lib/x86_64-linux-gnu/libKF5GuiAddons.so.5.41.0 
/usr/lib/x86_64-linux-gnu/l

Bug#889597: libtirpc: FTBFS: xdr_sizeof.c:93:13: error: 'uintptr_t' undeclared

[Andreas Beckmann]

Source: libtirpc
Version: 1.0.2-0.2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

libtirpc/experimental recently started to FTBFS:

/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  
-I../tirpc -include config.h -DPORTMAP -DINET6 -D_GNU_SOURCE -Wall -pipe 
-Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_RPCSEC_GSS -isystem /us
r/include/mit-krb5 -g -O2 -fdebug-prefix-map=/build/libtirpc-1.0.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
libtirpc_la-xdr_sizeof.lo `test -f 'xdr_sizeof.c' || echo './'`xdr_sizeof.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../tirpc -include config.h 
-DPORTMAP -DINET6 -D_GNU_SOURCE -Wall -pipe -Wdate-time -D_FORTIFY_SOURCE=2 
-DHAVE_RPCSEC_GSS -isystem /usr/include/mit-krb5 -g -O2 -fde
bug-prefix-map=/build/libtirpc-1.0.2=. -fstack-protector-strong -Wformat 
-Werror=format-security -c xdr_sizeof.c  -fPIC -DPIC -o 
.libs/libtirpc_la-xdr_sizeof.o
xdr_sizeof.c: In function 'x_inline':
xdr_sizeof.c:93:13: error: 'uintptr_t' undeclared (first use in this function); 
did you mean '__intptr_t'?
  if (len < (uintptr_t)xdrs->x_base) {
 ^
 __intptr_t
xdr_sizeof.c:93:13: note: each undeclared identifier is reported only once for 
each function it appears in
xdr_sizeof.c:93:23: error: expected ')' before 'xdrs'
  if (len < (uintptr_t)xdrs->x_base) {
   ^~~~
xdr_sizeof.c:105:38: error: expected ';' before 'len'
   xdrs->x_base = (caddr_t)(uintptr_t)len;
  ^~~
xdr_sizeof.c:109:1: warning: control reaches end of non-void function 
[-Wreturn-type]
 }
 ^
Makefile:977: recipe for target 'libtirpc_la-xdr_sizeof.lo' failed
make[3]: *** [libtirpc_la-xdr_sizeof.lo] Error 1


Andreas


libtirpc_1.0.2-0.2.log.gz
Description: application/gzip

Bug#889563: linphone: Wrong contact list sort order

[Rob van der Putten]

Hi there


On Sun, 4 Feb 2018, Geert Stappers wrote:


On Sun, Feb 04, 2018 at 03:52:02PM +0100, Rob van der Putten wrote:


Linphone sorts contacts by username (EG: ) as
opposed to display_name (EG: "John Doe").


SIP usernames are global unique, display_names not.

SIP username is always present, display_name is optional.



Below a small patch by a friend which fixes this problem;


Patch has been seen (at least by me)

But I don't understand the "problem".  Please elaborate.


In a regular VOIP context, sip usernames usually contain telephone 
numbers, E.G. . Which makes a sort by username 
rather inconvenient. Esp. in case of large contact lists.



Regards,
Rob

Bug#889596: libpinyin: FTBFS on sparc64: bus error in gen_binary_files

[Aaron M. Ucko]

Source: libpinyin
Version: 2.1.91-1
Severity: normal
Tags: upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64

Builds of libpinyin for sparc64 (admittedly not a release architecture)
have been failing:

  ../utils/storage/gen_binary_files --table-dir ../data
  Makefile:539: recipe for target 'bigram.db' failed
  make[3]: *** [bigram.db] Bus error

This error most likely indicates an unaligned memory access attempt, to
which sparc64 is particularly sensitive.  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#889482: Pending fixes for bugs in the golang-golang-x-sync package

[pkg-go-maintainers]

tag 889482 + pending
thanks

Some bugs in the golang-golang-x-sync package are closed in revision
053cd748e9a6fe6e262eb89530e04d7a34eebff8 in branch 'master' by Dr.
Tobias Quathamer

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-golang-x-sync.git/commit/?id=053cd74

Commit message:

Adopt package for the Debian Go team.

Closes: #889482

Bug#889595: grep -w mismatching

[George Vasiliou (GMAIL)]

Package: grep
Version: 3.1-2

Hello,

I am trying to use grep -w to match a word, but it seems that grep ignores
the -w switch and returns all occurencies.

Test case:
$ cat file1
one two three
one-two-three
one-two
two-three

$ grep -w 'two' file1 #or grep -Ew 'two'
Result: all four lines of file1 are returned.

According  to man grep:
-w, --word-regexp
  Select only those lines containing matches that form whole
words.  The test is  that  the  matching  substring  must either  be  at
the  beginning  of the line, or preceded by a non-word constituent
character.  Similarly, it must be either at the end of the line or followed
by a non-word  constituent  character. Word-constituent  characters
are letters,
digits, and the underscore.  This option has no effect if -x is also
specified.


Since dash '-' does not belong to word-constituent characters i was
expecting only first line to be matched : one two three

Just for the record , even options \, or \btwo\b will also return all
four lines.

Easy workaround for the job would be to use
grep ' two ' or grep -E '\stwo\s'

But this bug report is focused on the failure of -w flag

Cheers,

George Vasiliou

Bug#889146: AW: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889146

[Masi Osmani]

Hi Ben,

thank you for your fast answer and the very professional completion of my 
inquiry!

Finally i found the mistake, i installed a 64bit kernel on a 32 bit OS.


Best regards
Masi

-Ursprüngliche Nachricht-
Von: Ben Hutchings [mailto:b...@decadent.org.uk] 
Gesendet: Freitag, 2. Februar 2018 17:58
An: Masi Osmani 
Cc: 889...@bugs.debian.org
Betreff: Re: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889146

Control: tag -1 moreinfo

On Fri, 2018-02-02 at 17:30 +0100, Ben Hutchings wrote:
> On Fri, 2018-02-02 at 16:12 +, Masi Osmani wrote:
> > Hello mr. Hutchings,
> > 
> > i opened the bug 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889146
> > 
> > The bug tracker was not able to identify the responsible maintainer.
> 
> Oh, it doesn't recognise the new binary package name because that 
> package is not present in the main archive, only the security archive.
> I've reassigned this bug.
> 
> > I saw in this changelog 
> > https://tracker.debian.org/media/packages/l/linux/changelog-3.2.96-3 
> > that you commited the code for the kernel : linux (3.2.96-3) 
> > wheezy-security
> > 
> > i would appreciate it if you could evaluate my problems.
> 
> Did you build an "out-of-tree" driver for it previously?  If so, it 
> needs to be rebuilt against the new kernel headers.

I had a quick look at the source for the driver included in the kernel, and it 
does not appear to support 32-bit utilities working with a 64- bit kernel.

I eventually found the out-of-tree version of the driver (on Broadcom's web 
site), and that doesn't support any kernel version beyond Linux 2.6.37.  So I 
assume you weren't using this.

Did you switch from a 32-bit to a 64-bit kernel package?

Ben.

--
Ben Hutchings
Every program is either trivial or else contains at least one bug

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA] (was: Changes coming with VCS for Debian packaging)

[Gabriel F. T. Gomes]

On 03 Feb 2018, Juhani Numminen wrote:
>
>Quick note regarding debian/rules (which I only read online).
>https://salsa.debian.org/debian/bash-completion/blob/unstable/debian/rules
>
>debhelper(7) manpage tells me that autoreconf is enabled by default
>since compat 10, which means that "--with autoreconf" is not needed
>anymore.

Thanks, this is now fixed by:

https://salsa.debian.org/debian/bash-completion/commit/10ec55ff1c54543320b012b466b9e48c7e8611de

>Instead of doing version parsing the hard way, could you perhaps
>include /usr/share/dpkg/pkg-info.mk and use a suitable variable that
>it defines?

Indeed, but you also made me realize that the manpage was not being
re-generated, because the output (dh_bash-completion.1) was versioned
and not listed as a target dependency on debian/rules.

What do you think of the following change:

diff --git a/debian/extra/debhelper/dh_bash-completion.1 
b/debian/extra/debhelper/dh_bash-completion.1
deleted file mode 100644
index 82cde8b..000

diff --git a/debian/rules b/debian/rules
index 5ab9a19..8f7fb55 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-VERSION=$(shell parsechangelog | grep ^Version | awk -F": " '{print $$2}' | 
cut -d"-" -f1)
+include /usr/share/dpkg/pkg-info.mk
+
 REMOVE=adb bts nmcli hwclock ionice mock modules mount rtcwake dmesg renice 
umount
 
 override_dh_auto_configure:
@@ -23,10 +24,10 @@ override_dh_installchangelogs:
 dh_bash-completion.1: debian/extra/debhelper/dh_bash-completion
pod2man \
--center "Bash-Completion Debhelper" \
-   --release $(VERSION) \
+   --release $(DEB_VERSION_UPSTREAM) \
$< > debian/extra/debhelper/$@
 
-override_dh_install:
+override_dh_install: dh_bash-completion.1
dh_install
for i in $(REMOVE); do \
rm -vf 
debian/bash-completion/usr/share/bash-completion/completions/$$i; \


Cheers,
Gabriel

Bug#889594: dgit started to fails its autopkgtests, with git gnupg2/2.2.4-1+

[Dimitri John Ledkov]

Package: dgit
Version: 4.3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

dgit used to pass its autopkgtests, but doesn't anymore.

This appears to be true on both Debian CI and Ubuntu Proposed
Migration infrastructure. For more details please visit:

https://ci.debian.net/packages/d/dgit/

http://autopkgtest.ubuntu.com/packages/dgit/bionic/amd64

Note, this appears to be due to a change in gnupg2 package.

I am currently trying to upgrade gnupg2 package in Ubuntu, and this
autopkgtest failure is preventing me from doing so.

I am not familiar with the dgit internals, but there appear to be a
lot of warnings from gnupg w.r.t. unsave homedir permissions and lack
of secret keys. Possibly the dgit test-suite is not using gnupg-agent,
as it is now required by gnupg.

Would you please be able to look into upgrading/fixing dgit
autopkgtests?

Regards,

Dimitri.

-BEGIN PGP SIGNATURE-

iQFEBAEBCgAuFiEEdzyZ69ChEXIhenw/ysLYuc0spfkFAlp3c50QHHhub3hAdWJ1
bnR1LmNvbQAKCRDKwti5zSyl+Sv7B/9jDFmGqR38EoJC48rmCzKlBNmbMGux5K/f
Bu0gKCmhvoVBnjF9RYBhRYSVT7AsB92zwhZ2kFiEMMoI8DnzZ0dfOdCPGWLsfzXg
jsqxfxtMynE0yRx8XP9taIng1XWnej7kPPvsbprV2tOGhGHIJzdWNIqUgXnl8Ji3
X4J77D1gAT99GueZQRdRj29nH5gaVzuoBKPE/740bkeblJBNVoJIKEBk/2AMZEd8
pRlXeMVbdTiVdNR7i3wgt4RlMjPIWwGn3XfUUTDx76goRbb+kLtR2r0vPd5cclim
8gpol1/mH0HOTJG96JSeuuBX0NTOzoVcNJCAD2MHw3mjqR3dpy/g
=yKl1
-END PGP SIGNATURE-

Bug#889551: spectre-meltdown-checker should be in /usr/sbin/respect-meltdown-checker

[shirish शिरीष]

at bottom :-

On 04/02/2018, Sylvestre Ledru  wrote:
> Hello,
>
> Le 04/02/2018 à 13:56, shirish शिरीष a écrit :
>> Package: spectre-meltdown-checker
>> Version: 0.32-1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> I was trying to run spectre-meltdown-checker as a normal user first -
>>
>> /home/shirish> spectre-meltdown-checker
>> Spectre and Meltdown mitigation detection tool v0.32
>>
>> Note that you should launch this script with root privileges to get
>> accurate information.
>> We'll proceed but you might see permission denied errors.
>
> I had the feeling that a bunch of non-root information are still
> interesting and relevant.
>
> This is why I put it in /usr/bin/
>
> S
>
>

You are right, in that situation it still does produces interesting content.
Btw are you thinking of bumping it to 0.34 as that has been released or
are you waiting for the newer kernel 3.16 to arrive before you release
the new one.

from https://qa.debian.org/cgi-bin/vcswatch?package=spectre-meltdown-checker

I do see you did do an interim release on the git repo. but haven't
really released 0.33-1.

It does seem the vulnerabilities will be around for sometime. I did
read that newer chips will have few changes come in for
branch-prediction and stuff but those who got old chips, we will
either have to take a huge performance cut or go buy new chips. Of
course Intel benefits from taking no action then and now and simply
will sell more new chips


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

Bug#889593: freeradius-config: sites-enabled/default file is overwritten with symlink

[Kamil Jonca]

Package: freeradius-config
Version: 3.0.16+dfsg-1+b1
Severity: normal

With default configuration there is two directories:
sites-available - with modules/config files available to use
and 
sites-enabled - with config files actually used by freeradius daemon 
with default configuration all sites-enabled files are symlinks to 
sites-available ones.
Recommended way to customize configuration is 
1. remove symlink 
2. copy proper file from sites-available to sites-enabled and edit it

I modified "default" file this way.
And now my "sites-enabled/default" file is overwritten with symlink.

KJ


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

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

Versions of packages freeradius-config depends on:
ii  adduser3.117
ii  ca-certificates20170717
ii  freeradius-common  3.0.16+dfsg-1
ii  make   4.1-9.1
ii  openssl1.1.0g-2
ii  ssl-cert   1.0.39

freeradius-config recommends no packages.

freeradius-config suggests no packages.

-- Configuration Files:
/etc/freeradius/3.0/README.rst [Errno 13] Permission denied: 
'/etc/freeradius/3.0/README.rst'
/etc/freeradius/3.0/certs/Makefile [Errno 13] Permission denied: 
'/etc/freeradius/3.0/certs/Makefile'
/etc/freeradius/3.0/certs/README [Errno 13] Permission denied: 
'/etc/freeradius/3.0/certs/README'
/etc/freeradius/3.0/certs/bootstrap [Errno 13] Permission denied: 
'/etc/freeradius/3.0/certs/bootstrap'
/etc/freeradius/3.0/certs/ca.cnf [Errno 13] Permission denied: 
'/etc/freeradius/3.0/certs/ca.cnf'
/etc/freeradius/3.0/certs/client.cnf [Errno 13] Permission denied: 
'/etc/freeradius/3.0/certs/client.cnf'
/etc/freeradius/3.0/certs/inner-server.cnf [Errno 13] Permission denied: 
'/etc/freeradius/3.0/certs/inner-server.cnf'
/etc/freeradius/3.0/certs/server.cnf [Errno 13] Permission denied: 
'/etc/freeradius/3.0/certs/server.cnf'
/etc/freeradius/3.0/certs/xpextensions [Errno 13] Permission denied: 
'/etc/freeradius/3.0/certs/xpextensions'
/etc/freeradius/3.0/clients.conf [Errno 13] Permission denied: 
'/etc/freeradius/3.0/clients.conf'
/etc/freeradius/3.0/dictionary [Errno 13] Permission denied: 
'/etc/freeradius/3.0/dictionary'
/etc/freeradius/3.0/experimental.conf [Errno 13] Permission denied: 
'/etc/freeradius/3.0/experimental.conf'
/etc/freeradius/3.0/mods-available/README.rst [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/README.rst'
/etc/freeradius/3.0/mods-available/abfab_psk_sql [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/abfab_psk_sql'
/etc/freeradius/3.0/mods-available/always [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/always'
/etc/freeradius/3.0/mods-available/attr_filter [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/attr_filter'
/etc/freeradius/3.0/mods-available/cache [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/cache'
/etc/freeradius/3.0/mods-available/cache_eap [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/cache_eap'
/etc/freeradius/3.0/mods-available/chap [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/chap'
/etc/freeradius/3.0/mods-available/couchbase [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/couchbase'
/etc/freeradius/3.0/mods-available/counter [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/counter'
/etc/freeradius/3.0/mods-available/cui [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/cui'
/etc/freeradius/3.0/mods-available/date [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/date'
/etc/freeradius/3.0/mods-available/detail [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/detail'
/etc/freeradius/3.0/mods-available/detail.example.com [Errno 13] Permission 
denied: '/etc/freeradius/3.0/mods-available/detail.example.com'
/etc/freeradius/3.0/mods-available/detail.log [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/detail.log'
/etc/freeradius/3.0/mods-available/dhcp [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/dhcp'
/etc/freeradius/3.0/mods-available/dhcp_sqlippool [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/dhcp_sqlippool'
/etc/freeradius/3.0/mods-available/digest [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/digest'
/etc/freeradius/3.0/mods-available/dynamic_clients [Errno 13] Permission 
denied: '/etc/freeradius/3.0/mods-available/dynamic_clients'
/etc/freeradius/3.0/mods-available/eap [Errno 13] Permission denied: 
'/etc/freeradius/3.0/mods-available/eap'
/etc/freeradius/3.0/mods-available/echo [Errno 13] Permission d

Bug#878757: Openvswitch must started before networking servise

[Michael Biebl]

On Mon, 16 Oct 2017 20:28:26 +0700 Fedor Goncharov  wrote:
> Package: openvswitch-switch
> Version: 2.6.2~pre+git20161223-3
> Priority: critical
> 
> The Openvswitch daemon must be started before the network.service. 
> Because when the initiation of the network started interfaces from the 
> options should exist, or if you try to configure openvswitch in 
> /etc/network/interfaces, then the ovs daemon must be running to execute 
> commands.
> Please create a systemd configuration with the option "Before: 
> networking.service" for a stable version of debian.

That seems like the wrong thing to do.
networking.service is specific to ifupdown (auto). We do have several
other network configuration systems. I hope this was not actually
applied as a fix? The changelog is unfortunately unclear in that regard:

  * Added 2 debian/*.service files (Closes: #878757, #771507).

Thomas, can you please post the complete change that was actually applied.


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#889592: lintian: false positive for override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES

[Mattia Rizzolo]

Package: lintian
Version: 2.5.73

On Sun, Feb 04, 2018 at 03:36:45PM +0530, Chris Lamb wrote:
> Some results coming in:
> 
>   
> https://lintian.debian.org/tags/override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES.html
> 
> Thoughts?

Randomly checked few packages and they were mostly all fpos:

https://tracker.debian.org/media/packages/a/aff4/rules-0.24.post1-3
Ok, this is crazy, he deserves what he got for being too clever with
make :D

https://tracker.debian.org/media/packages/a/autoconf-dickey/rules-2.52%2B20170501-2
https://tracker.debian.org/media/packages/a/avro-c/rules-1.8.2-1
Not sure why this is matched, I thought it wouldn't have been:
|override_dh_auto_test:
|   dh_auto_test --no-parallel

https://tracker.debian.org/media/packages/libx/libxcb/rules-1.12-1
Similar to the previous:
|override_dh_auto_test:
|   dh_auto_test -- VERBOSE=1

https://tracker.debian.org/media/packages/o/osm2pgsql/rules-0.94.0%2Bds-1
Also similar:
|override_dh_auto_test:
|   dh_auto_test || echo "Ignoring test failures"

https://tracker.debian.org/media/packages/a/akonadi-calendar-tools/rules-417.08.3-2
https://tracker.debian.org/media/packages/b/biosig4c%2B%2B/rules-1.4.1-1.1
This seems to be a recurring pattern:
|override_dh_auto_test:
|   # Disable dh_auto_test at build time
|   :

https://tracker.debian.org/media/packages/b/bibletime/rules-2.11.1-1
I believe this is going the be another recurring pattern:
|override_dh_auto_test:
|   echo "Skip dh_auto_test because the tests rely on a display which is 
not there"


Whilst true that the last two technically should deal with
DEB_BUILD_OPTIONS=nocheck, I believe running a single `:` or a single
`echo` should be considered fine.


In my random pick, I saw this real positive:
https://tracker.debian.org/media/packages/l/lua-lgi/rules-0.9.2-1
|override_dh_auto_test:
|   make -C tests all
|   GI_TYPELIB_PATH=tests LD_LIBRARY_PATH=tests xvfb-run dh_auto_test
I recommend to add a similar thing to the testsuite, as this one is
*also* calling dh_auto_test, but it should still handle
DEB_BUILD_OPTIONS=nocheck by hand.

-- 
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#889591: lintian: emits package-does-not-install-examples although all examples are installed

[Sebastian Ramacher]

Package: lintian
Version: 2.5.73
Severity: normal

lintian reports

P: libbluray source: package-does-not-install-examples src/examples/

on libbluray. However, all files from src/examples are installed in
libbluray-doc:

$ ls src/examples
bd_info.c  bdsplice.c  index_dump.c  libbluray_test.c  list_titles.c  
sound_dump.c

$ cat debian/libbluray-doc.examples
src/examples/*.c

Cheers


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

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

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

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

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

-- no debconf information

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#889144: stricter PIDfile handling breaks several daemons

[Sven Hartge]

On Sun, 4 Feb 2018 15:41:37 + Simon Kelley 
wrote:

> With my dnsmasq maintainer hat on, the current arrangement looks like this.
> 
> 1) /run/dnsmasq is a directory owned by dnsmasq:nogroup
> 2) /run/dnsmasq/dnsmasq.pid gets written by dnsmasq before it drops
> root, so is root:root
> 3) The reason /run/dnsmasq is owned by dnsmasq is so that dnsmasq can
> unlink the pidfile at shutdown, after it has dropped root and is running
> as 'dnsmasq'

Does dnsmasq need a PIDfile when running under systemd? Can't it just
not double fork, stay in the foreground using a Type=simple systemd unit?

That way the whole problem could be avoided all together.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#889590: tesseract-ocr-aze has circular Depends on tesseract-ocr-aze-cyrl

[Bill Allombert]

Package: tesseract-ocr-aze
Version: 4.00~git15-45ed289-5
Severity: important

Hello Jeff,

There is a circular dependency between tesseract-ocr-aze and 
tesseract-ocr-aze-cyrl:

tesseract-ocr-aze   :Depends: tesseract-ocr-aze-cyrl (>= 3.99)
tesseract-ocr-aze-cyrl  :Depends: tesseract-ocr-aze (>= 3.99)

Circular dependencies are known to cause problems during upgrade between
stable releases, so we should try to avoid them.

See threads 
http://lists.debian.org/debian-devel/2005/06/msg02111.html
http://lists.debian.org/debian-devel/2005/11/msg01101.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#889589: geany has a missing-pkg-dependency according to adequate

[shirish शिरीष]

Package: geany
Version: 1.32-2
Severity: normal

Usertags: missing-pkgconfig-dependency adequate
User: debian...@lists.debian.org

Dear Maintainer,

I was installing geany when adequate reported that there is a missing
pkgconfig-dependency.

>From adequate's manpage -

  missing-pkgconfig-dependency
   Dependency of a pkg-config (.pc) file shipped by this
package couldn't be satisfied.

   References: Debian Policy §8.4.

/home/shirish> adequate geany
geany: missing-pkgconfig-dependency geany => gtk+-3.0

At the same time it should also change the suggests from libvte9 to
libvte-2.91-0 which is now in Debian buster/testing .

Please fix the same.

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

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

Versions of packages geany depends on:
ii  geany-common 1.32-2
ii  libatk1.0-0  2.26.1-3
ii  libc62.26-4
ii  libcairo-gobject21.15.10-1
ii  libcairo21.15.10-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  libstdc++6   7.2.0-19

geany recommends no packages.

Versions of packages geany suggests:
pn  doc-base  
pn  libvte9   

-- no debconf information


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

Bug#889578: [pkg-wicd-maint] Bug#889578: wicd: Confusion over multiple APs with the same name

[Axel Beckert]

Control: tag -1 + upstream

Hi,

Paul "LeoNerd" Evans wrote:
> I have two APs with the same name, to cover a wide area. These appear
> differently as different "networks" in the wicd GTK UI.

Yes. That way — and in contrary to Network Manager — you can
explicitly decide which AP you will connect to.

> They both require indivdual configuration, individual settings,

Not necessarily. If you configure the first AP, you can check the box
"use these settings for all APs with the same ESSID".

> But yet, clicking "connect" on one of them will quite often actually
> pick whichever one is the closer stronger signal, regardless of
> which of the two whose button I clicked on.

That seems to be a bug though. (For automatic connects, this is
another story.)

> wicd needs to make up its mind clearly about what the deal is with
> multiple APs having the same name. Are they part of the same "network",
> or not?

No, that's the users decision per ESSID if he wants to regard them as
the same network or not.

>  * If they are to be separate, then the "connect" button really ought to
>connect to the one I actually asked for.

Yes.

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

Bug#888201: mailman: CVE-2018-5950

[Salvatore Bonaccorso]

Control: found -1 1:2.1.18-1

On Thu, Feb 01, 2018 at 01:46:05PM +0100, Thijs Kinkhorst wrote:
> >> I plan to release Mailman 2.1.26 along with a patch for older releases
> >> to fix this issue on Feb 4, 2018. At that time, full details of the
> >> vulnerability will be public.
> 
> I've reserved time on Sunday to in any case to sid when the fix is
> released, and depending on the details/severity look into a security
> upload.

Thijs, unless I'm completely wrong, this issue goes at least back to
the jessie version? Marking as such for the BTS, but please correct me
if I'm wrong.

Regards,
Salvatore