Bug#880426: Acknowledgement (libreoffice-sdbc-firebird: fails to upgrade jessie -> stretch -> buster)

[Andreas Beckmann]

Don't forget to bump the version in
debian/libreoffice-sdbc-firebird.maintscript
That should have been done when that file was reintroduced in 1:5.4.2-1

Please use "1:5.4.3~rc1-3~" (or whatever will be the version including
the fix plus a trailing "~").

It's always the version right before the (working) d-m-h call was added,
not the (older) version that removed/renamed/changed the
conffile/symlink/ (but ideally both versions are the same).

You can probably leave the version in
debian/libreoffice-common.maintscript alone.


Andreas

Bug#880428: libwireshark-dev: plugin dir contains /usr//usr/ breaking libvirt backports

[Balint Reczey]

Control: unarchive 857729
Control: forcemerge 857729 -1

Hi,

Thanks for the bug report.

On Tue, Oct 31, 2017 at 2:10 PM, Marcin Juszkiewicz
 wrote:
> Package: libwireshark-dev
> Version: 2.2.6+g32dac6a-2
> Severity: normal
>
> Dear Maintainer,
>
> I am backporting libvirt for our use. During build of libvirt 3.6.0+
> wireshark dissector is supposed to be built. And it is built. No issues.
>
> But then it is installed to $(pkg-config --variable plugindir wireshark)
> directory. Which is /usr//usr/lib/ARCH-NAME-TRIPLET/wireshark/ while

This is fixed in later version.

Cheers,
Balint

-- 
Balint Reczey
Debian Developer

Bug#879850: stretch-pu: package sqldeveloper-package/0.2.4+deb9u1

[Phil Morrell]

Just following up this request to note that this change has now
migrated to testing and also been acked by the maintainer:
https://lists.debian.org/debian-mentors/2017/10/msg00340.html
--
Phil Morrell (emorrp1)

Bug#880428: libwireshark-dev: plugin dir contains /usr//usr/ breaking libvirt backports

[Marcin Juszkiewicz]

W dniu 31.10.2017 o 14:36, Balint Reczey pisze:
>> But then it is installed to $(pkg-config --variable plugindir wireshark)
>> directory. Which is /usr//usr/lib/ARCH-NAME-TRIPLET/wireshark/ while

> This is fixed in later version.

Which is not present in 'stretch' nor 'stretch-backports' therefore bug
is still valid.

Please backport the fix.

Bug#880217: ansible-tower-cli-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/ansible-tower-cli/CONFIG_CMD_OPTIONS.md.gz

[Evgeni Golov]

Hi,

On Mon, Oct 30, 2017 at 06:23:32PM +0100, Andreas Beckmann wrote:
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

This should be
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

Where can I file a bug against your templates? ;)

> From the attached log (scroll to the bottom...):

I'll fix these asap, thanks!

Evgeni

Bug#832558:

[Martin Galvan]

This also affects me on Ubuntu 17.10. Why hasn't this been fixed yet?

Bug#879544: netcdf transiton: ncl

[Bas Couwenberg]

On 2017-10-31 14:48, Alastair McKinstry wrote:
"ncl" is involved in the current netcdf (and upcoming hdf5) 
transition(s).


Its failed to build on mips64el (hardware issue on build machine?) but
also on the kfreebsd, hurd, hppa archs:

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

I've a fix for the kfreebsd, hurd FTBFS and also I think hppa (can't
test).   I've pushed it to git, but will hold off doing a release to
unstable subject unless you think its ok,


The netcdf package migrated to testing today, so the ncl package is no 
longer involved in ongoing transitions.


Uploading to unstable should be okay. I uploaded netcdf4-python earlier 
today for example.


Kind Regards,

Bas

Bug#879544: netcdf transiton: ncl

[Alastair McKinstry]

Hi,

"ncl" is involved in the current netcdf (and upcoming hdf5) transition(s).

Its failed to build on mips64el (hardware issue on build machine?) but
also on the kfreebsd, hurd, hppa archs:

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

I've a fix for the kfreebsd, hurd FTBFS and also I think hppa (can't
test).   I've pushed it to git, but will hold off doing a release to
unstable subject unless you think its ok,

Best trgards

Alastair


ncl (6.4.0-5) UNRELEASED; urgency=medium

  * Use libhdf5-dev instead of transitional libhdf5-serial-dev
  * Standards-Version: 4.1.1; no changes required
  * Use libopenblas on more archs as available
  * Fix needed for hppa, kfreebsd (+hppa?) support

 -- Alastair McKinstry   Tue, 31 Oct 2017 12:30:24
+


-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 




signature.asc
Description: OpenPGP digital signature

Bug#880440: ITP: python3-aioprocessing -- Multiprocessing support for Python asyncio

[David Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele 

* Package name: python3-aioprocessing
  Version : 1.0.0
  Upstream Author : Dan O'Reilly 
* URL : https://pypi.python.org/pypi/aioprocessing/1.0.0
* License : BSD-2
  Programming Lang: Python
  Description : Asynchronous multiprocessing support for Python asyncio

This module includes support for the multiprocessing module to work
with the Python asyncio module.

Packaging is at https://github.com/davesteele/aioprocessing/tree/debian/debian

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#880439: stretch-pu: package getmail4/4.53.0-2+deb9u1

[Osamu Aoki]

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

I just uploaded to the stable-proposed-upload.

This stable package was based on 4.53.0 which was released right before
the Stretch release.  Since then, upstream found a regression in 4.53.0
and released its specific fix as 4.54.0.

I had packaged it as 4.53.0-2 to sid and had no problem migrating to
testing.  Its changes are in patch file for your review.

This upload is a simple repackaging under stretch chroot to pass the
benefit to the stable package without risk.  Please accept this to the
nest stable release.

The testing will package new getmail version 5 series.  They carry more
changes and will not be uploaded like this to stable.  Also most likely,
its package name will be changed to simple "getmail".

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

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

Bug#879876: ipython fails after printing help on a variable definition

[Reverend Homer]

I've got zero feedback, but with latest ipython upgrade (5.5.0-1)
problem has gone.

Thank you, this bug can be closed now.

Bug#880423: mariadb-10.3: Stop generating packages for the embedded mariadb-connector-c library?

[Guillem Jover]

Source: mariadb-10.3
Source-Version: 10.3.0-0+exp2
Severity: normal

Hi!

While checking the libraries from the mariadb-connector-c project, and
switching some code to use them, I noticed that the mariadb-server
embeds them upstream. And in Debian, those library packages are generated
now (in experimental) from the embedded copies instead of the proper
upstream mariadb-connector-c source.

I think this is a bad idea, because (AFAIUI) the mariadb-server
statically links them anyway, and this would mean that we are tied
to have whatever mariadb-connector-c version is embedded in one of
the particular mariadb-server we happen to ship (see #877622, for an
example of this problem).

Also there is this upstream report, which I'm not entirely sure can be
read as a request to unbundle the mariadb-connector-c,
 (which I
think would be the correct thing to do no matter what). But there is
always the danger of that happening. And for starters that would imply
having to use an epoch in the mariadb-connector-c version. :(

Thanks,
Guillem

Bug#880430: lintian: check for invalid arguments to dpkg-maintscript-helper

[Andreas Beckmann]

Package: lintian
Version: 2.5.57
Severity: normal

I just came around this incorrect dpkg-maintscript-helper invocation in
libreoffice-sdbc-firebird (#880426):

# Automatically added by dh_installdeb/10.9
dpkg-maintscript-helper dir_to_symlink /usr/share/doc/libreoffice-sdbc-firebird 
/usr/share/doc/libreoffice-core 1:5.0.3\~rc1-2 \$DPKG_MAINTSCRIPT_PACKAGE -- 
"$@"
# End automatically added section

This is caused by dh_installdeb escaping shell metacaracters in compat
level 10, so the (superfluous) $DPKG_MAINTSCRIPT_PACKAGE argument that
worked in compat level 9 becomes an invalid package name now, and makes
d-m-h explode.

This error may not be recognized easily in standard testing since d-m-h
will skip the operation depending on the version argument.
And it is likely that a debian/*.maintscript file that worked in compat
level 9 will be a noop in most upgrade paths nowadays, creating a timebomb
for a case where the newer package gets installed over an even older one ...

src:libreoffice has two of these errors, but only one is triggered in piuparts
(I only found this because there is no libreoffice-sdbc-firebird in stretch
and an upgrade from jessie->stretch->buster is actually an upgrade
jessie->buster for this package and needs the d-m-h commands to run)

I'm not sure how to correctly detect this from lintian, but any package
name argument containing escaped shell meta characters is invalid.


Andreas

Bug#880353: Pending fixes for bugs in the golang-github-gophercloud-gophercloud package

[pkg-go-maintainers]

tag 880353 + pending
thanks

Some bugs in the golang-github-gophercloud-gophercloud package are
closed in revision 4df038751447bef2303ef10edcb21daa0e404404 in branch
'master' by Shengjing Zhu

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-gophercloud-gophercloud.git/commit/?id=4df0387

Commit message:

d/control: add tzdata to Build-Depends (Closes: #880353).

Signed-off-by: Shengjing Zhu 

Bug#880426: Acknowledgement (libreoffice-sdbc-firebird: fails to upgrade jessie -> stretch -> buster)

[Rene Engelhard]

Hi,

On Tue, Oct 31, 2017 at 02:37:53PM +0100, Andreas Beckmann wrote:
> Don't forget to bump the version in
> debian/libreoffice-sdbc-firebird.maintscript
> That should have been done when that file was reintroduced in 1:5.4.2-1

Indeed, with 1:5.2.3~rc1-1..

> Please use "1:5.4.3~rc1-3~" (or whatever will be the version including
> the fix plus a trailing "~").

sigh, ok. Changed.
(The next upload probably will be 1:5.4.3~rc2-1, though)

Regards,

Rene

Bug#879900: apparmor-profiles-extra: Totem segfaults when apparmor profile is enforced

[Jason Wittlin-Cohen]

Hi,

I would be happy to help. I have several machines running Stretch with a
variety of hardware and uses (desktop/server, Intel/NVIDIA GPUs etc.).  Are
there specific apparmor profiles you wish to test?

As for the totem profile on Stretch, simply adding #include
 to /etc/apparmor.d/local/usr.bin/totem and reloading
the profile did not fix the issue:

jason@jason-desktop:/etc/apparmor.d$ /usr/bin/totem

(totem:9153): Cogl-WARNING **: driver/gl/cogl-util-gl.c:96: GL error
(1281): Invalid value
(totem:9153): Cogl-WARNING **: driver/gl/cogl-util-gl.c:96: GL error
(1281): Invalid value
(totem:9153): Cogl-WARNING **: driver/gl/cogl-util-gl.c:96: GL error
(1281): Invalid value
(totem:9153): Cogl-WARNING **: driver/gl/cogl-util-gl.c:96: GL error
(1281): Invalid value
(totem:9153): Cogl-WARNING **: driver/gl/cogl-util-gl.c:96: GL error
(1281): Invalid value
Segmentation fault

The audit log shows continued errors related to the NVIDIA driver:

Oct 31 10:26:56 kernel: audit: type=1400 audit(1509460016.329:300):
apparmor="DENIED" operation="open" profile="/usr/bin/totem"
name="/dev/nvidia-modeset" pid=9153 comm="totem" requested_mask="rw"
denied_mask="rw" fsuid=1000 ouid=0
Oct 31 10:26:56 kernel: audit: type=1400 audit(1509460016.329:301):
apparmor="DENIED" operation="open" profile="/usr/bin/totem"
name="/dev/nvidia-modeset" pid=9153 comm="totem" requested_mask="rw"
denied_mask="rw" fsuid=1000 ouid=0
Oct 31 10:26:56 kernel: audit: type=1400 audit(1509460016.349:302):
apparmor="DENIED" operation="file_mmap" profile="/usr/bin/totem"
name="/tmp/.glVcerPq" pid=9153 comm="totem" requested_mask="m"
denied_mask="m" fsuid=1000 ouid=1000
Oct 31 10:26:56 kernel: audit: type=1400 audit(1509460016.349:303):
apparmor="DENIED" operation="file_mmap" profile="/usr/bin/totem"
name="/tmp/.glVcerPq" pid=9153 comm="totem" requested_mask="m"
denied_mask="m" fsuid=1000 ouid=1000
Oct 31 10:26:56 kernel: audit: type=1400 audit(1509460016.349:304):
apparmor="DENIED" operation="mkdir" profile="/usr/bin/totem"
name="/home/jason.nv/" pid=9153 comm="totem" requested_mask="c"
denied_mask="c" fsuid=1000 ouid=1000
Oct 31 10:26:56 kernel: audit: type=1400 audit(1509460016.353:305):
apparmor="DENIED" operation="file_mmap" profile="/usr/bin/totem"
name="/tmp/.gl6sStVi" pid=9153 comm="totem" requested_mask="m"
denied_mask="m" fsuid=1000 ouid=1000
Oct 31 10:26:56 kernel: audit: type=1400 audit(1509460016.353:306):
apparmor="DENIED" operation="file_mmap" profile="/usr/bin/totem"
name="/tmp/.gl6sStVi" pid=9153 comm="totem" requested_mask="m"
denied_mask="m" fsuid=1000 ouid=1000
Oct 31 10:26:56 kernel: audit: type=1400 audit(1509460016.353:307):
apparmor="DENIED" operation="mkdir" profile="/usr/bin/totem"
name="/home/jason.nv/" pid=9153 comm="totem" requested_mask="c"
denied_mask="c" fsuid=1000 ouid=1000
Oct 31 10:26:56 kernel: audit: type=1400 audit(1509460016.397:308):
apparmor="DENIED" operation="open" profile="/usr/bin/totem"
name="/var/lib/flatpak/exports/share/icons/hicolor/index.theme" pid=9153
comm="totem" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Oct 31 10:26:56 kernel: audit: type=1400 audit(1509460016.397:309):
apparmor="DENIED" operation="open" profile="/usr/bin/totem"
name="/var/lib/flatpak/exports/share/icons/hicolor/icon-theme.cache"
pid=9153 comm="totem" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
jason@jason-desktop:/etc/apparmor.d$


I also tried using the usr.bin.totem profile from sid, but that also failed:

jason@jason-desktop:/etc/apparmor.d/local$ /usr/bin/totem

(totem:11884): Cogl-WARNING **: driver/gl/cogl-util-gl.c:96: GL error
(1281): Invalid value
(totem:11884): Grilo-WARNING **: [bookmarks] grl-bookmarks.c:255: Could not
open database '/home/jason/.local/share/grilo-plugins/grl-bookmarks.db':
Failed to open database at
/home/jason/.local/share/grilo-plugins/grl-bookmarks.db
(totem:11884): GVFS-WARNING **: can't init metadata tree
/home/jason/.local/share/gvfs-metadata/root: open: Permission denied
(totem:11884): GVFS-WARNING **: can't init metadata tree
/home/jason/.local/share/gvfs-metadata/root: open: Permission denied
(totem:11884): GrlPodcasts-CRITICAL **: Failed to open database '': unable
to open database file
(totem:11884): Grilo-WARNING **: [thetvdb] grl-thetvdb.c:390: Could not
open database '/home/jason/.local/share/grilo-plugins/grl-thetvdb.db':
Failed to open database at
/home/jason/.local/share/grilo-plugins/grl-thetvdb.db
Segmentation fault

The audit log still contains NVIDIA related errors:

Oct 31 10:41:52 kernel: audit: type=1400 audit(1509460912.787:317):
apparmor="DENIED" operation="open" profile="/usr/bin/totem"
name="/dev/nvidia-modeset" pid=11884 comm="totem" requested_mask="rw"
denied_mask="rw" fsuid=1000 ouid=0
Oct 31 10:41:52 kernel: audit: type=1400 audit(1509460912.787:318):
apparmor="DENIED" operation="open" profile="/usr/bin/totem"
name="/dev/nvidia-modeset" pid=11884 comm="totem" requested_mask="rw"
denied_mask="rw" fsuid=1000 ouid=0
Oct 31 10:41:52 kernel: audit: 

Bug#880425: thunderbird: logs spurious apparmor denial messages

[Philipp Kern]

Package: thunderbird
Version: 1:52.4.0-1

When I use Thunderbird I see a lot of these in the kernel log (probably
whenever I look at a signed and/or encrypted email):

[94784.485686] audit: type=1400 audit(1509453045.981:153):
apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg"
name="/usr/share/thunderbird/omni.ja" pid=4440 comm="gpg2"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

I don't see an obvious degradation of the client. Even gpg-encrypted
mails get handled correctly by Enigmail. But I suppose some kind of rule
is missing to make the log lines go away?

Kind regards and thanks
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#880203: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Fwd: Re: Bug#880203: After suspend, cpufreq/scaling_max_freq is ignored)

[Leon Meier]

On 31.10.2017 11:39, Debian Bug Tracking System wrote:

Yes, but that doesn't mean we can do anything about it.


Why not simply re-issue the request setting the performance-level after 
resume?

Bug#875694: libnss3 still uses SSE2 instructions on i386 (cf. #871700)

[Fanael Linithien]

The bug has been fixed upstream in (not yet released) version 3.34,
feel free to close the report.

Bug#880424: thunderbird: apparmor should allow the execution of the configured browser

[Philipp Kern]

On 10/31/2017 01:30 PM, Philipp Kern wrote:
> I turned on AppArmor and Thunderbird stopped opening links for me. dmesg
> has the following denial message:
> 
>  [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
>  apparmor="DENIED" operation="exec" profile="thunderbird"
>  name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
>  comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
> 
> I think there needs to be some kind of defined way for browsers to be
> allowed to be executed. I understand that I use a browser that is not in
> the distribution, which makes this even more important. In this case the
> browser is literally set as the xdg default:
[...]

Note that this extends to generic URL handlers as well:

[95946.493507] audit: type=1400 audit(1509454207.986:185):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/bin/gobby-0.5" pid=6205 comm="thunderbird" requested_mask="x"
denied_mask="x" fsuid=1000 ouid=0

(From an infinote:// URL in an email.)

And I'd be surprised if Thunderbird were the only application with this
problem.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#880429: FTBFS: cryptonite-conduit-test: unknown RTS option: -N

[Aaron M. Ucko]

Source: haskell-cryptonite-conduit
Version: 0.2.0-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of cryptonite-conduit-test for a number of architectures failed
with

  Running 1 test suites...
  Test suite cryptonite-conduit-test: RUNNING...
  cryptonite-conduit-test: unknown RTS option: -N
  [...]
  Test suite cryptonite-conduit-test: FAIL
  Test suite logged to:
  dist-ghc/test/cryptonite-conduit-0.2.0-cryptonite-conduit-test.log
  0 of 1 test suites (0 of 1 test cases) passed.
  /usr/share/cdbs/1/class/hlibrary.mk:154: recipe for target 'check-ghc-stamp' 
failed
  make: *** [check-ghc-stamp] Error 1
  dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

as detailed at

https://buildd.debian.org/status/logs.php?pkg=haskell-cryptonite-conduit=0.2.0-1

Please limit the use of this option to the architectures (those with
Haskell thread support, IIRC) on which it is available.

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#843021: [Pkg-javascript-devel] node-yarnpkg status update

[Pirate Praveen]

On ചൊവ്വ 31 ഒക്ടോബര്‍ 2017 02:28 വൈകു, Paolo Greppi wrote:
> Before I file ITPs for these:
> - asap
> - chownr

https://github.com/isaacs/chownr/issues/14

> - dnscache
> - gulp-if
> - gulp-watch 

I think we could skip this, likely required only for development (to run
gulp when files change).

> - gunzip-maybe
> - is-ci
> - is-webpack-bundle
> - mock-stdin
> - node-emoji
> - prettier
> - puka
> - tar-fs
> - v8-compile-cache
> - yn
> do you have any comments on them ?
> 
> Paolo
> 




signature.asc
Description: OpenPGP digital signature

Bug#879690: maint-guide: debuild requires double dashes between debuild options and targets

[Osamu Aoki]

On Tue, Oct 24, 2017 at 06:11:43PM +0300, Francesco Montanari wrote:
> Package: maint-guide
> Version: 1.2.39
> Severity: normal
> 
> Dear Maintainer,
> 
> Cleaning source trees with 'debuild clean' as indicated in
> doc/06_build.xml I encounter the same error as in #846016:
> 
>  dpkg-buildpackage -rfakeroot -us -uc -I -i clean
>  dpkg-buildpackage: error: unknown option or argument clean
> 
> Seems like a double dash should be added 'debuild -- clean'?

True. -i causes this.

Osamu

Bug#879960: libqt5sql5-psql: [libqt5sql5-psql] basic support postgresql-10

[Dmitry Shachnev]

Hi Damir!

On Fri, Oct 27, 2017 at 11:34:08PM +0700, Damir R. Islamov wrote:
> Dear Maintainer,
>
> * QT-5.9.[1,2] (and future QT-5.10?) in the upstream do not support
>   PostgreSQL 10.
> * Future Debian release (at least the current SID) includes PostgreSQL 10.
> * Users who use QPSQLDriver in there applications (e.g. who use
>   akonadi-backend-postgresql) are not able to work completely.
> * I suppose that a basic support of PostgreSQL 10 in QPSQLDriver will
>   provide (at least temporal) solution until QT team support in the
>   upstream.

Do you have any upstream bug link for this? If not, please create a bug
on https://bugreports.qt.io/ or, even better, submit your patch to
https://codereview.qt-project.org/ (see [1] for the instructions).

We usually do not add patches that are not approved upstream and are not
going to be merged upstream in near future.

[1]: http://wiki.qt.io/Setting_up_Gerrit

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#880433: O: g-wrap -- scripting interface generator for C

[Tobias Frost]

Package: wnpp

The current maintainer of g-wrap, Andreas Rottmann ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

(I've put the uploader of the last NMUs in X-Debbugs-CC; Hideki, maybe you
want to adopt it)

Package: g-wrap
Binary: g-wrap, libgwrap-runtime-dev, libgwrap-runtime2, guile-g-wrap
Version: 1.9.15-0.2
Maintainer: Andreas Rottmann 
Build-Depends: debhelper (>= 10), cdbs, texinfo, guile-2.0-dev (>= 2.0.5), 
guile-library (>= 0.1.1), libglib2.0-dev, libffi-dev
Architecture: any all
Standards-Version: 4.0.0
Format: 3.0 (quilt)
Files:
 3c6899a21faeb80c4f26934857b3d1cc 2157 g-wrap_1.9.15-0.2.dsc
 037d465a28782636a995cf0179f1d7ff 701601 g-wrap_1.9.15.orig.tar.gz
 f5584a973e7f44ced365637280242683 9588 g-wrap_1.9.15-0.2.debian.tar.xz
Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/g-wrap.git
Vcs-Git: https://anonscm.debian.org/git/collab-maint/g-wrap.git
Checksums-Sha256:
 3375f292bb4b07f6e660104deeb3bd518cc615ded7c8c172dd63ce85832b3370 2157 
g-wrap_1.9.15-0.2.dsc
 0ff6e2700e74b457323726f7c2551a466d8ba44339705f6792d7b533145c602a 701601 
g-wrap_1.9.15.orig.tar.gz
 b74d4503d5aed4ed4ea15b34e8fe710d6db3553d3bf9d46652d620ad114b5621 9588 
g-wrap_1.9.15-0.2.debian.tar.xz
Homepage: http://www.nongnu.org/g-wrap/
Package-List: 
 g-wrap deb lisp optional arch=all
 guile-g-wrap deb lisp optional arch=any
 libgwrap-runtime-dev deb libdevel optional arch=any
 libgwrap-runtime2 deb libs optional arch=any
Directory: pool/main/g/g-wrap
Priority: source
Section: lisp

Package: g-wrap
Version: 1.9.15-0.2
Installed-Size: 212
Maintainer: Andreas Rottmann 
Architecture: all
Depends: guile-2.0, guile-library (>= 0.1.1), dpkg (>= 1.15.4) | install-info
Recommends: indent, libgwrap-runtime-dev (>= 1.9.15-0.2)
Conflicts: guile-g-wrap (<< 1.9.9-1), libgwrapguile-dev
Description-en: scripting interface generator for C
 G-Wrap is a tool (and Guile library) for generating function wrappers
 for inter-language calls. It currently only supports generating Guile
 wrappers for C functions.
 .
 G-Wrap takes a set of interface declarations (written in Scheme) and
 wraps the described interface for Guile.
Description-md5: c7c2bd9277521362b3f2191659ca8c54
Homepage: http://www.nongnu.org/g-wrap/
Tag: devel::code-generator, devel::lang:c, devel::lang:scheme,
 implemented-in::scheme, interface::commandline, role::program,
 scope::utility
Section: lisp
Priority: optional
Filename: pool/main/g/g-wrap/g-wrap_1.9.15-0.2_all.deb
Size: 70396
MD5sum: 0ae8fe8b7d199ce0db77482904e7b243
SHA256: 89d280a378481a264514895083504ebdc7f593e952744351b51085342b10b792

Package: g-wrap
Version: 1.9.15-0.1
Installed-Size: 212
Maintainer: Andreas Rottmann 
Architecture: all
Depends: guile-2.0, guile-library (>= 0.1.1), dpkg (>= 1.15.4) | install-info
Recommends: indent, libgwrap-runtime-dev (>= 1.9.15-0.1)
Conflicts: guile-g-wrap (<< 1.9.9-1), libgwrapguile-dev
Description-en: scripting interface generator for C
 G-Wrap is a tool (and Guile library) for generating function wrappers
 for inter-language calls. It currently only supports generating Guile
 wrappers for C functions.
 .
 G-Wrap takes a set of interface declarations (written in Scheme) and
 wraps the described interface for Guile.
Description-md5: c7c2bd9277521362b3f2191659ca8c54
Homepage: http://www.nongnu.org/g-wrap/
Tag: devel::code-generator, devel::lang:c, devel::lang:scheme,
 implemented-in::scheme, interface::commandline, role::program,
 scope::utility
Section: lisp
Priority: optional
Filename: pool/main/g/g-wrap/g-wrap_1.9.15-0.1_all.deb
Size: 70296
MD5sum: 9fb5291c171bed5989902c1df726e92a
SHA256: d945ad729f16179f06bf81f759cbbeebd610a3e6eca1373edef2a5c9d5c5eef5

Package: libgwrap-runtime-dev
Source: g-wrap
Version: 1.9.15-0.2
Installed-Size: 151
Maintainer: Andreas Rottmann 
Architecture: amd64
Replaces: libgwrapguile1 (<< 1.3.4-13)
Depends: libgwrap-runtime2 (= 1.9.15-0.2), guile-2.0-dev, libffi-dev, libc6-dev
Conflicts: libgwrap-runtime0-dev, libgwrapguile-dev
Description-en: scripting interface generator for C - development files
 G-Wrap is a tool (and Guile library) for generating function wrappers
 for inter-language calls. It currently only supports generating Guile
 wrappers for C functions.
 .
 This package contains the development files for the runtime shared
 libraries.
Description-md5: 24748cd5e1b1944106680102ef4f3f5e
Homepage: http://www.nongnu.org/g-wrap/
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/g/g-wrap/libgwrap-runtime-dev_1.9.15-0.2_amd64.deb
Size: 38300
MD5sum: 

Bug#880422: asymptote: please consider the attached suggestions

[Nicolas Boulenguez]

Source: asymptote
Severity: minor
Tags: patch

Hello.
The attached patches apply on 2.41-3.
The severity is not wishlist because some of them fix minor issues.
You may want to pick some of them.
Thanks.


suggestions.tar.gz
Description: application/gzip

Bug#880428: libwireshark-dev: plugin dir contains /usr//usr/ breaking libvirt backports

[Marcin Juszkiewicz]

Package: libwireshark-dev


Version: 2.2.6+g32dac6a-2


Severity: normal





Dear Maintainer,





I am backporting libvirt for our use. During build of libvirt 3.6.0+


wireshark dissector is supposed to be built. And it is built. No issues.





But then it is installed to $(pkg-config --variable plugindir wireshark)


directory. Which is /usr//usr/lib/ARCH-NAME-TRIPLET/wireshark/ while


libvirt packaging expects it to be in sane


/usr/lib/ARCH-NAME-TRIPLET/wireshark one.





I checked and the fault is in 'stretch' version of wireshark. Checked


amd64 and arm64 packages and both have plugindir defined wrong:





prefix=/usr


exec_prefix=${prefix}


libdir=${exec_prefix}//usr/lib/x86_64-linux-gnu


includedir=${prefix}/include


sharedlibdir=${libdir}


plugindir=${libdir}/wireshark/plugins/2.2.6





Please consider fixing it.





-- System Information:


Debian Release: 9.2


  APT prefers stable-updates


  APT policy: (500, 'stable-updates'), (500, 'stable')


Architecture: arm64 (aarch64)





Kernel: Linux 4.14.0-rc4-arm64 (SMP w/8 CPU cores)


Locale: LANG=en_GB.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash


Init: systemd (via /run/systemd/system)





Versions of packages libwireshark-dev depends on:


ii  libwireshark8  2.2.6+g32dac6a-2


ii  libwsutil-dev  2.2.6+g32dac6a-2





libwireshark-dev recommends no packages.





libwireshark-dev suggests no packages.





-- debconf-show failed

Bug#871537: cups-daemon: Fails to delete a printer via http://localhost:631 (AppArmor-related?)

[Michael Biebl]

Hi

Am 31.10.2017 um 07:59 schrieb intrigeri:
> Hi Michael,
> 
> do you need more time to test the proposed fix, or should we find
> someone else to do it?

Sorry for not responding earlier. Seems this email fell through the cracks.
Now, it seems I can't reproduce the original issue anymore :-/
So unless someone runs into this problem, this bug report should be
closed I guess.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#880428: libwireshark-dev: plugin dir contains /usr//usr/ breaking libvirt backports

[Balint Reczey]

Hi Marcin,

On Tue, Oct 31, 2017 at 2:40 PM, Marcin Juszkiewicz
 wrote:
> W dniu 31.10.2017 o 14:36, Balint Reczey pisze:
>>> But then it is installed to $(pkg-config --variable plugindir wireshark)
>>> directory. Which is /usr//usr/lib/ARCH-NAME-TRIPLET/wireshark/ while
>
>> This is fixed in later version.
>
> Which is not present in 'stretch' nor 'stretch-backports' therefore bug
> is still valid.

Yes, it is a valid bug which is closed in unstable and the current
state reflects that [1].

>
> Please backport the fix.

I will consider backporting it.

Cheers,
Balint

[1] https://www.debian.org/Bugs/Developer#closing

-- 
Balint Reczey
Debian Developer

Bug#880432: ITP: node-cli-table2 -- Pretty unicode tables for the command line

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-cli-table2
  Version : 0.2.0
  Upstream Author : James Talmage
* URL : https://github.com/jamestalmage/cli-table2
* License : Expat
  Programming Lang: JavaScript
  Description : Pretty unicode tables for the command line

 This utility allows you to render unicode-aided tables on the command line
 from your node.js scripts. Based on (and api compatible with) the original
 cli-table, cli-table2 is nearly a complete rewrite to accommodate
column and
 row spanning.
 .
 It passes the entire original cli-table test suite, and should be a drop in
 replacement for nearly all users.
 .
 Node.js is an event-based server-side JavaScript engine.

Dependency of npm 5.x



signature.asc
Description: OpenPGP digital signature

Bug#880438: libopencv-core-dev: installs headers in opencv2 directory

[Simon Frei]

Package: libopencv-core-dev
Version: 3.2.0+dfsg-3
Severity: normal

All the headers files are placed below
/usr/include/opencv2/
while libopencv-dev places its header files below
/usr/include/opencv/
Apart from this inconsistency, I also don't see any reason for the
"reference" to version2 - I assume this was forgotten during the
transition?
I detected this when trying to compile digikam (from upstream's source, not the
deb), which did not detect the presence of opencv.

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

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

Versions of packages libopencv-core-dev depends on:
ii  libopencv-core3.2  3.2.0+dfsg-3
ii  libtbb-dev 2017~U7-8
ii  zlib1g-dev 1:1.2.8.dfsg-5

libopencv-core-dev recommends no packages.

libopencv-core-dev suggests no packages.

-- no debconf information

Bug#812229: adns FTCBFS: does not support DEB_BUILD_OPTIONS=nocheck

[Ian Jackson]

Manuel A. Fernandez Montecelo writes ("Bug#812229: adns FTCBFS: does not 
support DEB_BUILD_OPTIONS=nocheck"):
> Control: tags -1 + pending
...
> >I still welcome an NMU.  As for a maintainer upload, I don't want to
> >make promises I can't keep.
> 
> So I just uploaded to delayed/2, only with the single change, .debdiff
> attached.

Thank you for taking good care of this package.

Ian.

Bug#878750: ITP: python-monasca-statsd -- monasca statsd Python client

[Corey Bryant]

On Tue, Oct 31, 2017 at 6:36 AM, Thomas Goirand  wrote:

> On 10/31/2017 01:58 AM, Jeremy Bicha wrote:
> > python-monasca-statsd is currently packaged in Ubuntu as source:
> monasca-statsd
> >
> > The biggest difference is that the Ubuntu package ships a
> > documentation package and the Debian package also ships the Python 3
> > module.
> >
> > https://launchpad.net/ubuntu/+source/monasca-statsd
> >
> > Thanks,
> > Jeremy Bicha
>

Hi Jeremy,

Thanks and feel free to report bugs against LP for OpenStack-related
packages as well.


>
> Hi,
>
> Thanks Jeremy, that's a good catch, and I'm happy to know. A few
> comments here though.


> Having a doc package here is silly, if you consider that the generated
> doc is nearly empty. The only thing it will contain is the index.rst
> that contains a long description of the package, which is also available
> in debian/control, plus where to find upstream source, also described in
> debian/control (homepage field), and that's about it.
>
> The Python 3 module is important to me, so I wont remove it, maybe
> Canonical should catch up on it.
>

Will do.


>
> Now, more in general. I don't even understand why it wasn't uploaded to
> Debian by the Ubuntu team. Ubuntu people have always claimed they wanted
> to collaborate with Debian people for the OpenStack stuff, yet when
> there's nobody outside of Canonical to do the work, no upload happens in
> Debian, it goes only to Ubuntu. So I'm tempted to say it's you guys
> fault here... Time to reboot the Ubuntu workflow for OpenStack? Maybe
> Corey should attempt to become a DD and do the work in Debian? If
> nothing happens to go that direction, I'm not sure I want to do any
> effort either. I've done enough in the past and got frustrated enough.
>

We've gone above and beyond to collaborate. Prior to this past year we
aligned with Debian as much as possible on OpenStack dependencies. In fact
I spent a significant amount of time a few cycles back dropping any delta
from Ubuntu deps to align with Debian. Unfortunately we can't align on the
core packages until we can come to an agreement there. For example, Debian
packages don't use pristine-tar and they use debconf prompts to users for
configuration - whereas we use pristine-tar and don't prompt users in
Ubuntu.  This past year, and possibly part of the year before, Debian
development on OpenStack ceased for a long stretch of time until just
recently.  That forced us to completely change our workflow to an Ubuntu
focus. If we shared all packages that could've been a different story.

Regards,
Corey


> Cheers,
>
> Thomas Goirand (zigo)
>

Bug#880437: Updating the libglade2 Uploaders list

[Tobias Frost]

Source: libglade2
Version: 1:2.6.4-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Andreas Rottmann  has not been working on
the libglade2 package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#880424: thunderbird: apparmor should allow the execution of the configured browser

[Philipp Kern]

Package: thunderbird
Version: 1:52.4.0-1

I turned on AppArmor and Thunderbird stopped opening links for me. dmesg
has the following denial message:

 [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
 apparmor="DENIED" operation="exec" profile="thunderbird"
 name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
 comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

I think there needs to be some kind of defined way for browsers to be
allowed to be executed. I understand that I use a browser that is not in
the distribution, which makes this even more important. In this case the
browser is literally set as the xdg default:

 $ xdg-settings get default-web-browser
 google-chrome-beta.desktop

/etc/apparmor.d/abstractions/ubuntu-browsers includes the regular
google-chrome:

  /opt/google/chrome/google-chrome Cx -> sanitized_helper,

Literally the only browser Thunderbird should be able to execute is the
one configured as the default, not some set of ancient and potentially
exploitable other browsers (like some compiled against old webkit
versions), looking at the current list in the abstraction.

I suppose one way would be to always launch some kind of
sensible-browser binary and let that call out to the default browser
only. Which might be what sanitized_helper is already trying to
accomplish. Except that the abstraction leaks into the... abstraction. :)

Another way would be to let browser packages ship a file that allows
their execution and then the installed ones are automatically available
to Thunderbird (or another browser-spawning program). In this case
Chrome would need to start shipping such a file.

Kind regards and thanks
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#875688: libreoffice-report-builder: Design view is missing and existing reports won't run

[Rene Engelhard]

Hi,

On Tue, Oct 31, 2017 at 12:16:01PM +0100, MAG4 Piemonte wrote:
> thank you for the really fast solution.

Well, it's a "solution" to just wait, so I am not really sure thanking
_me_ is worthwile here ;-) I "just" tested it with 6.0, nothing more :)

> We will test version 6.0 as it will land in testing ...

That will take some time... - 6.0.0 will only be released next year
in February: https://wiki.documentfoundation.org/ReleasePlan/6.0#6.0.0_release

Regards,

Rene

Bug#880426: libreoffice-sdbc-firebird: fails to upgrade jessie -> stretch -> buster

[Andreas Beckmann]

Package: libreoffice-sdbc-firebird
Version: 1:5.4.2-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie' to 'stretch' to 'buster'.
It installed fine in 'jessie', and upgraded to 'stretch' successfully,
but then the upgrade to 'buster' failed.

In case the package was not part of an intermediate stable release,
the version from the preceding stable release was kept installed.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../112-libreoffice-sdbc-firebird_1%3a5.4.2-3_i386.deb ...
  dpkg-query: no packages found matching $DPKG_MAINTSCRIPT_PACKAGE
  dpkg-query: error: --listfiles needs a valid package name but 
'$DPKG_MAINTSCRIPT_PACKAGE' is not: illegal package name in specifier 
'$DPKG_MAINTSCRIPT_PACKAGE': must start with an alphanumeric character
  
  Use --help for help about querying packages.
  dpkg-maintscript-helper: error: file 
'/usr/share/doc/libreoffice-sdbc-firebird' not owned by package 
'$DPKG_MAINTSCRIPT_PACKAGE'
  dpkg-query: error: --listfiles needs a valid package name but 
'$DPKG_MAINTSCRIPT_PACKAGE' is not: illegal package name in specifier 
'$DPKG_MAINTSCRIPT_PACKAGE': must start with an alphanumeric character
  
  Use --help for help about querying packages.
  dpkg-maintscript-helper: error: file 
'/usr/share/doc/libreoffice-sdbc-firebird/copyright' not owned by package 
'$DPKG_MAINTSCRIPT_PACKAGE'
  dpkg-query: error: --listfiles needs a valid package name but 
'$DPKG_MAINTSCRIPT_PACKAGE' is not: illegal package name in specifier 
'$DPKG_MAINTSCRIPT_PACKAGE': must start with an alphanumeric character
  
  Use --help for help about querying packages.
  dpkg-maintscript-helper: error: file 
'/usr/share/doc/libreoffice-sdbc-firebird/changelog.Debian.gz' not owned by 
package '$DPKG_MAINTSCRIPT_PACKAGE'
  dpkg-query: error: --listfiles needs a valid package name but 
'$DPKG_MAINTSCRIPT_PACKAGE' is not: illegal package name in specifier 
'$DPKG_MAINTSCRIPT_PACKAGE': must start with an alphanumeric character
  
  Use --help for help about querying packages.
  dpkg-maintscript-helper: error: file 
'/usr/share/doc/libreoffice-sdbc-firebird/README.gz' not owned by package 
'$DPKG_MAINTSCRIPT_PACKAGE'
  dpkg-maintscript-helper: error: directory 
'/usr/share/doc/libreoffice-sdbc-firebird' contains files not owned by package 
$DPKG_MAINTSCRIPT_PACKAGE, cannot switch to symlink
  dpkg: error processing archive 
/tmp/apt-dpkg-install-hwNvs8/112-libreoffice-sdbc-firebird_1%3a5.4.2-3_i386.deb 
(--unpack):
   subprocess new pre-installation script returned error exit status 1


Looks like you just need to drop the '$DPKG_MAINTSCRIPT_PACKAGE' from
debian/*.maintscript - that gets escaped properly by dh_installdeb
in compat level 10. It has always been redundant anyway.


cheers,

Andreas


libreoffice-sdbc-firebird_1:5.4.2-3.log.gz
Description: application/gzip

Bug#880427: tinyproxy: If tinyproxy receives a SIGHUP, then the children exit without being restarted and tinyproxy hangs.

[Stephan Leemburg]

Package: tinyproxy
Version: 1.8.4-2
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   
   Hanging tinyproxy, no proxied connections are handled anymore.

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

   Logrotate sends a SIGHUP, which triggers this problem.

   * What was the outcome of this action?

   Unusable tinyproxy.

   * What outcome did you expect instead?

   Usable tinyproxy


   Please see patch below

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

Kernel: Linux 4.4.19-1-pve (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tinyproxy depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  logrotate3.11.0-0.1
ii  lsb-base 9.20161125

tinyproxy recommends no packages.

tinyproxy suggests no packages.
-- no debconf information

### PATCH BELOW

--- tinyproxy-1.8.4/src/child.c 2015-12-07 15:19:00.0 +0100
+++ tinyproxy/src/child.c   2017-10-31 13:38:48.542095431 +0100
@@ -233,6 +233,9 @@
 
 ret = select(maxfd + 1, , NULL, NULL, NULL);
 if (ret == -1) {
+if (errno == EINTR) {
+continue;
+}
 log_message (LOG_ERR, "error calling select: %s",
  strerror(errno));
 exit(1);

Bug#880431: libxfce4ui-2-0 4.13.3-1 breaks xfce4-terminal

[chrysn]

Package: libxfce4ui-2-0
Version: 4.13.3-1
Severity: normal

While trying out the latest xfce4 experimental packages, I stumbled upon
a conflict that should probably be covered by a "Breaks" relation before
those versions hit unstable:

When libxfce4ui-2-0 version 4.13.3-1 is installed, running
xfce4-terminal and pressing F1 there returns in the following crash:

| (xfce4-terminal:26893): Gtk-ERROR **: failed to add UI: The resource at 
“/org/xfce/libxfce4ui/libxfce4ui-dialog-ui.ui” does not exist
| zsh: trace trap  xfce4-terminal --disable-server

Reverting libxfce4ui to 4.12.3-4 solves the issue, and F1 presents the
"Online Documentation" / "Do you want to read the Xfce Terminal manual
online" menu.

A (probably needless) word of warning: xfce4-terminal usually runs
single-process-per-user, so such a crash takes down all the terminal
windows; better test it on an instance started with the --disable-server
option.

Best regards
chrysn

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

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

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#880258: [Debian-med-packaging] Bug#880258: picard-tools: FTBFS: CollectRrbsMetricsTest.java:29: error: package org.testng does not exist

[Olivier Sallou]

testng maven definition needs to be modified in build.graddle to match
testng debian pom.

Following patch fix the compilation for tests:

--- a/build.gradle
+++ b/build.gradle
@@ -32,7 +32,7 @@
 compile 'com.github.samtools:htsjdk:' + htsjdkVersion
 //tools dependency for doclet requires sdk devel
 compile(files(((URLClassLoader)
ToolProvider.getSystemToolClassLoader()).getURLs()))
-    testCompile 'org.testng:testng:6.9.10'
+    testCompile 'org.testng:testng:debian'
 }
 
 sourceCompatibility = 1.8


however, all tests fail with the same issue than htsjdk when using
testng in graddle

Cannot nest operations in the same thread. Each nested operation must
run in its own thread.
java.lang.UnsupportedOperationException: Cannot nest operations in the
same thread. Each nested operation must run in its own thread.

I have no idea why (not using gradle), and asked to java team but got
not answer for the moment.

Olivier


On 10/30/2017 08:26 PM, Lucas Nussbaum wrote:
> Source: picard-tools
> Version: 2.8.1+dfsg-2
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20171030 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
>> make[1]: Entering directory '/<>/picard-tools-2.8.1+dfsg'
>> # Tests do not work with locales with a different decimal separator
>> # (for example ',') 
>> env LC_ALL=C \
>> dh_auto_build -- test
>>  mkdir -p .gradle/init.d
>>  cp /usr/share/gradle-debian-helper/init.gradle .gradle/init.d/
>>  gradle --info --console plain --offline --stacktrace --no-daemon 
>> --refresh-dependencies --gradle-user-home .gradle -Duser.home=. 
>> -Duser.name=debian -Ddebian.package=picard-tools -Dfile.encoding=UTF-8 
>> --parallel --max-workers=16 test
>> Initialized native services in: 
>> /<>/picard-tools-2.8.1+dfsg/.gradle/native
>> To honour the JVM settings for this build a new JVM will be forked. Please 
>> consider using the daemon: 
>> https://docs.gradle.org/3.2.1/userguide/gradle_daemon.html.
>> Starting daemon process: workingDir = 
>> /<>/picard-tools-2.8.1+dfsg/.gradle/daemon/3.2.1, daemonArgs: 
>> [/usr/lib/jvm/java-8-openjdk-amd64/bin/java, -XX:MaxPermSize=256m, 
>> -XX:+HeapDumpOnOutOfMemoryError, -Xmx1024m, -Dfile.encoding=UTF-8, 
>> -Duser.country=US, -Duser.language=en, -Duser.variant, -cp, 
>> /usr/share/gradle/lib/gradle-launcher-3.2.1.jar, 
>> org.gradle.launcher.daemon.bootstrap.GradleDaemon, 3.2.1]
>> Starting process 'Gradle build daemon'. Working directory: 
>> /<>/picard-tools-2.8.1+dfsg/.gradle/daemon/3.2.1 Command: 
>> /usr/lib/jvm/java-8-openjdk-amd64/bin/java -XX:MaxPermSize=256m 
>> -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 
>> -Duser.country=US -Duser.language=en -Duser.variant -cp 
>> /usr/share/gradle/lib/gradle-launcher-3.2.1.jar 
>> org.gradle.launcher.daemon.bootstrap.GradleDaemon 3.2.1
>> Successfully started process 'Gradle build daemon'
>> An attempt to start the daemon took 0.62 secs.
>> Connected to daemon DaemonInfo{pid=103081, 
>> address=[2e268c2e-3c63-4337-afd4-2e65ac75aac2 port:38729, 
>> addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Busy, 
>> lastBusy=1509376996459, 
>> context=DefaultDaemonContext[uid=2cc7999a-a025-4898-ba87-3e84d29d2241,javaHome=/usr/lib/jvm/java-8-openjdk-amd64,daemonRegistryDir=/<>/picard-tools-2.8.1+dfsg/.gradle/daemon,pid=103081,idleTimeout=12,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]}.
>>  Dispatching request BuildAndStop{id=642d5534-8837-4bd9-b101-9d40666366dc.1, 
>> currentDir=/<>/picard-tools-2.8.1+dfsg}.
>> Received result org.gradle.launcher.daemon.protocol.BuildStarted@4a3631f8 
>> from daemon DaemonInfo{pid=103081, 
>> address=[2e268c2e-3c63-4337-afd4-2e65ac75aac2 port:38729, 
>> addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Busy, 
>> lastBusy=1509376996459, 
>> context=DefaultDaemonContext[uid=2cc7999a-a025-4898-ba87-3e84d29d2241,javaHome=/usr/lib/jvm/java-8-openjdk-amd64,daemonRegistryDir=/<>/picard-tools-2.8.1+dfsg/.gradle/daemon,pid=103081,idleTimeout=12,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]}
>>  (build should be starting).
>> The client will now receive all logging from the daemon (pid: 103081). The 
>> daemon log file: 
>> /<>/picard-tools-2.8.1+dfsg/.gradle/daemon/3.2.1/daemon-103081.out.log
>> Closing daemon's stdin at end of input.
>> The daemon will no longer process any standard input.
>> Daemon will be stopped at the end of the build stopping after processing
>> Executing build with daemon context: 
>> 

Bug#879688: Acknowledgement (Pb install debian 9.2.1-amd64 et GRUB (français))

[Philippe Rey]

Bonjour,

Résolution du problème:
J'ai eu beau chercher, impossible de démarrer et connecter un utilisateur. 
Après maintes tentatives du côté des passwd et shadow (il y avait sûrement 
quelque chose à faire pour activer un compte...) je me suis résolu à relancer 
l'install complète et ça marche ! J'ai compris pourquoi je n'avais pas 
d'utilisateur défini : dans la procédure d'install, ils sont créés après 
l'install de GRUB, où s'était arrêtée l'installation.

En espérant au moins que ces infos puissent être utiles si quelqu'un 
rencontrait un problème.

Cordialement,
Philippe


Envoyé depuis notre immobile Pomme... 
Le 25/10/17 à 23:24, Philippe Rey a écrit :

Bonjour,

Je m'accroche (je me dis que j'apprendrai plus en essayant de réparer "à la 
main" plutôt que la solution de simplicité qui consisterait tout bêtement à 
relancer l'install depuis le début...) et du coup, j'ai un peu progressé sur le 
problème... En deux temps !

- J'ai réussi à installer GRUB (dans le mode récupération : grub install 
/dev/sda1) mais au boot, plus d'accès à rien (si j'ai bien compris GRUB a 
écrasé le boot pour windows !), juste une invite de commande où je n'ai rien su 
faire ; je crois bien que c'était GRUB qui attendait des infos pour aller plus 
loin !
- ensuite j'ai trouvé comment "réparer GRUB", d'abord avec la cmde os-prober 
(qui cherche les OS dans les partitions) et avec la cmde update-grub, qui m'a 
gentiment remis au boot une menu pour choisir entre debian et windows !

Maintenant, il me reste à savoir comment accéder à debian qui démarre avec un 
écran sobre où je peux rentrer un identifiant et un mot de passe, mais 
impossible d'ouvrir une session, ni root, ni utilisateur, qui pourtant ont bien 
été créés lors de l'installation…
Je suis en train de chercher du côté des fichiers passwd et shadow dans 
lesquels je vois bien une première ligne avec "root:x:17...:0:99...:7:::" 
suivie de bien d'autres toutes sur le même modèle "daemon:*:17... , 
bin:*:17..., sys:*:..., sync:*:... etc." j'ai essayé de virer le x de root, 
mais c'est pire ! Et là pour aujourd'hui je cale ! (j'ai "un peu" de sommeil à 
rattraper !)

Si quelqu'un a un conseil, je prend !
Merci, Philippe

Envoyé depuis notre immobile Pomme... 
Le 24/10/17 à 10:45, Debian Bug Tracking System a écrit :

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 879688: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879688.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Install Team 


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

Please do not send mail to ow...@bugs.debian.org 
unless you wish
to report a problem with the Bug-tracking system.

Bug#880434: O: guile-lib -- Library of useful Guile modules

[Tobias Frost]

Package: wnpp

The current maintainer of guile-lib, Andreas Rottmann ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: guile-lib
Binary: guile-library
Version: 0.2.2-0.2
Maintainer: Andreas Rottmann 
Build-Depends: cdbs, debhelper (>= 7)
Build-Depends-Indep: guile-2.0, guile-2.0-dev, texinfo
Build-Conflicts-Indep: guile-library (<< 0.1.9-1)
Architecture: all
Standards-Version: 3.9.1
Format: 3.0 (quilt)
Files:
 aac64d4f41a9abad897c10f2d78e85f1 1188 guile-lib_0.2.2-0.2.dsc
 77427e4ff3f2b1061bffa370666125f7 476723 guile-lib_0.2.2.orig.tar.gz
 edfcdc5cce527c5cc252b6ac940bc1cb 3164 guile-lib_0.2.2-0.2.debian.tar.xz
Checksums-Sha256:
 a3c3e1aa4a0248991c4505463fc41f83b607c046976af91926043b2564e855c1 1188 
guile-lib_0.2.2-0.2.dsc
 8bc0083c43923c08cbccee4aa07405e601f1ccfd667a1be5a7e5e4b2ca1236b9 476723 
guile-lib_0.2.2.orig.tar.gz
 a3bbb55171d627feb95014d5e58f32193de32e13c88208b943411e0d74ae4fd6 3164 
guile-lib_0.2.2-0.2.debian.tar.xz
Homepage: http://www.nongnu.org/guile-lib/
Package-List: 
 guile-library deb lisp optional arch=all
Directory: pool/main/g/guile-lib
Priority: source
Section: lisp

Package: guile-library
Source: guile-lib
Version: 0.2.2-0.2
Installed-Size: 848
Maintainer: Andreas Rottmann 
Architecture: all
Depends: guile-2.0
Description-en: Library of useful Guile modules
 A set of various-purpose library modules for Guile. Covered areas include:
 .
  * Unit testing framework ala JUnit
  * Logging system
  * String routines (wrapping, completion, soundex algorithm)
  * OS process chains (think "shell pipes in scheme")
  * ANSI escape sequence text coloring
Description-md5: 832ec85eda0cc08f7614e9770717e22d
Homepage: http://www.nongnu.org/guile-lib/
Tag: devel::lang:scheme, devel::library, devel::testing-qa,
 implemented-in::scheme, role::app-data
Section: lisp
Priority: optional
Filename: pool/main/g/guile-lib/guile-library_0.2.2-0.2_all.deb
Size: 207892
MD5sum: 94e7d22b54f5ae5147c8e2ba435e85bc
SHA256: 33ef4085f14a147aa3a2dc2717310e14fb64d02b29ae5fb5ef0b7d9776647d77



signature.asc
Description: PGP signature

Bug#880435: O: guile-cairo -- Guile bindings for Cairo

[Tobias Frost]

Package: wnpp

The current maintainer of guile-cairo, Andreas Rottmann ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: guile-cairo
Binary: guile-cairo, guile-cairo-dev
Version: 1.4.0-3.1
Maintainer: Andreas Rottmann 
Build-Depends: cdbs (>= 0.4.49), autotools-dev, debhelper (>> 7), 
dh-autoreconf, patchutils (>= 0.2.25), guile-2.0-dev, libcairo2-dev (>= 
1.4.10), guile-library (>= 0.1.2)
Architecture: any
Standards-Version: 3.9.1
Format: 3.0 (quilt)
Files:
 1ed5cd1ce895c0e6b3ec4885afe6e653 1416 guile-cairo_1.4.0-3.1.dsc
 196c2800f9816afeca82b1ca7619df63 512208 guile-cairo_1.4.0.orig.tar.gz
 db970ecf33f9d323b6e489050d33ef82 2820 guile-cairo_1.4.0-3.1.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=collab-maint/guile-cairo.git
Vcs-Git: git://git.debian.org/git/collab-maint/guile-cairo.git
Checksums-Sha256:
 1fea9443ed62510b54aa5184512e2fea415006c8bf34f01d5674ede70a9b106f 1416 
guile-cairo_1.4.0-3.1.dsc
 bad5d4b6c09b77930d811e333a4920337d222c0ea4ee5e561a0276efa8bb9507 512208 
guile-cairo_1.4.0.orig.tar.gz
 006de4809ca88eb843e616688353f719e4a31710f219ad480273f0fbde9c2208 2820 
guile-cairo_1.4.0-3.1.debian.tar.xz
Homepage: http://home.gna.org/guile-cairo/
Package-List: 
 guile-cairo deb lisp extra arch=any
 guile-cairo-dev deb libdevel extra arch=any
Directory: pool/main/g/guile-cairo
Priority: source
Section: lisp

Package: guile-cairo
Version: 1.4.0-3.1
Installed-Size: 282
Maintainer: Andreas Rottmann 
Architecture: amd64
Depends: guile-2.0-libs, libc6 (>= 2.4), libcairo2 (>= 1.4.10), libgc1c2 (>= 
1:7.2d)
Description-en: Guile bindings for Cairo
 This package contains Guile modules that provide access to the Cairo
 library.
Description-md5: 7f5afca3d3b7c21d5e48631d442ad7fe
Homepage: http://home.gna.org/guile-cairo/
Tag: devel::lang:scheme
Section: lisp
Priority: optional
Filename: pool/main/g/guile-cairo/guile-cairo_1.4.0-3.1_amd64.deb
Size: 53942
MD5sum: 89b70244696d3da94dae4e4e4d6febb3
SHA256: 2fd8b6b6357b6b3ab21186b27ebdfeb77ea2f3ef49cad8863a23a3024776a5a1

Package: guile-cairo-dev
Source: guile-cairo
Version: 1.4.0-3.1
Installed-Size: 89
Maintainer: Andreas Rottmann 
Architecture: amd64
Depends: guile-cairo (= 1.4.0-3.1), guile-2.0-dev, libcairo2-dev (>= 1.4.10), 
dpkg (>= 1.15.4) | install-info
Description-en: Guile bindings for Cairo, development files
 This package contains the info manual for guile-cairo and the header
 files to allow compilation of wrappers depending on guile-cairo.
Description-md5: d6c3bf40c7a4218f9a9168eade9404e9
Homepage: http://home.gna.org/guile-cairo/
Tag: devel::library, role::devel-lib
Section: lisp
Priority: optional
Filename: pool/main/g/guile-cairo/guile-cairo-dev_1.4.0-3.1_amd64.deb
Size: 38904
MD5sum: d4ecca3bc9efb0b495a38c436fc4eb03
SHA256: 28e0219fbd49ec2e22fe7d60cecdc0e32abee489a0ecd8dbbc7527273efa7eea



signature.asc
Description: PGP signature

Bug#880436: Updating the python-crypto Uploaders list

[Tobias Frost]

Source: python-crypto
Version: 2.6.1-7
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Andreas Rottmann  has not been working on
the python-crypto package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#878696: Debian mirror mirror.nbtelecom.com.br: broken mirror

[Pedro Alves]

Dear Peter,

   A few informations to update mirror site 
(https://www.debian.org/mirror/list-full#BR)


We are currently offering:

http://mirror.nbtelecom.com.br/debian/
http://mirror.nbtelecom.com.br/debian-cd/

rsync://mirror.nbtelecom.com.br::debian
rsync://mirror.nbtelecom.com.b::debian-cd

We are updating from sft.if.usp.br. If you could point me to main mirror 
i would appreciate !


We run ftpsync every 15 minutes

Thank You


 A *NB Telecom* é cadastrada na *Onip* como fornecedor qualificado da 
indústria do petróleo e gás e, associada da *Rede Petro Rio e da *Telcomp*.


Acesse nossas redes sociais: facebook.com/nbtelecom 
 e twiter.com/telecomnb1 
.   Nosso site:www.nbtelecom.com.br 



DISCLAIMER
Esta é uma mensagem estritamente confidencial cujo sigilo é protegido 
por lei. Quaisquer informações e documentos nela contidos
são direcionados exclusivamente a seu(s) destinatário(s) acima 
identificado(s). Caso a tenha recebido equivocadamente, solicitamos
que os mesmos sejam imediatamente apagados e o seu remetente comunicado. 
Fica V.Sa. notificada de que a divulgação, retenção,
disseminação, distribuição ou cópia desta mensagem e seus anexos, sem a 
autorização do remetente, constitui crime nos

termos da Lei Complementar 105/01.
Obrigado.*
Em 18/10/2017 06:57, Peter Palfrader escreveu:

On Tue, 17 Oct 2017, Pedro Alves wrote:


Dear Peter,

    Check again ! Tralalaa!

It seems your mirror is current again.

It runs syncs way more often than once very 6 hours (4 times a day),
maybe because your upstream mirror has a bad trace file.

Maybe this is something you want to look at, but for now the mirror
seems to be up-to-date.

Cheers,


Less broken, but very out of date.  Mirrors should update every 6 hours
to match the update frequency of the archive.


The latest ftpsync versions come with a wrapper script called
ftpsync-cron, which is intended to be run out of cron every hour or so
(at a randomish offset).  The script monitors your upstream mirror, and
if there was an update triggers a full sync using ftpsync.  You might
want to give it a try.  Or you could, if your upstream mirror also ran
ftpsync, which apparently it doesn't. :(

Bug#877590: [Debian-med-packaging] Bug#880258: picard-tools: FTBFS: CollectRrbsMetricsTest.java:29: error: package org.testng does not exist

[Olivier Sallou]

htsjdk and picard-tools test issues are gradle related.
After some deeper tests and discussions with debian-java team, it
appears the errors faced in testing (after the patches I proposed on
testng) are related to the gradle version on debian.
Someone in java team should upgrade to an upper release I tested
manually with success (though 1 test failed for picard-tools and should
be investigated later on, but other tests are fine, and issue is not
build related).

New release should fix the issue.

In the meanwhile, to avoid packages removal, I suggest to apply my
proposed patches and to disable testing.
Once gradle is upgraded in repo, then we could go for test reactivation.

I can update code and upload both if everyone agrees with this strategy.

Only point is to not forget to follow gradle upgrade and which packages
should be updated to reintegrate tests. Could lower severity of those 2
bugs to keep track of the issue.

Olivier

-- 


gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#880449: unison: Uncaught exception Failure("input_value: bad bigarray kind")

[Vincent Lefevre]

Package: unison
Version: 2.48.4-1
Severity: grave
Justification: renders package unusable

Since the upgrade to 2.48.4-1, I get when synchronizing with
a Debian/stable server:

Unison failed: Uncaught exception Failure("input_value: bad bigarray kind")
Raised by primitive operation at file "/tmp/buildd/unison-2.48.3/remote.ml", 
line 453, characters 18-45
Called from file "/tmp/buildd/unison-2.48.3/remote.ml", line 459, characters 
23-61
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 75, characters 
20-23
Re-raised at file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 135, characters 
12-13
Called from file "list.ml", line 73, characters 12-15
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 31, characters 
2-37
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 83, characters 
17-46
Called from file "/tmp/buildd/unison-2.48.3/lwt/generic/lwt_unix_impl.ml", line 
147, characters 6-40
Called from file "/tmp/buildd/unison-2.48.3/main.ml", line 202, characters 6-24
Called from file "/tmp/buildd/unison-2.48.3/main.ml", line 131, characters 4-9

Fatal error: Lost connection with the server

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

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

Versions of packages unison depends on:
ii  libc6  2.24-17

Versions of packages unison recommends:
ii  openssh-client [ssh-client]  1:7.6p1-2

Versions of packages unison suggests:
ii  unison-all  2.48+2

-- no debconf information

Bug#875838: fpc: test/units/sysutils/texpfncase fails on some systems (patch attached)

[Gianfranco Costamagna]

control: unarchive -1
control: reopen -1

On Thu, 14 Sep 2017 16:56:10 -0600 Adam Conrad  wrote:
> Package: fpc
> Version: 3.0.2+dfsg-5
> Severity: important
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu artful ubuntu-patch
> 
> 
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * fix_texpfncase_test.patch: Cherrypick upstream fix to texpfncase test.
> 
> After banging my head on a few walls, I couldn't quite sort out *why* this
> test passes on some of our infra and not others, but happily, the upstream
> commit above fixes it so it passes everywhere.
> 
> Would be nice to have this included in the unstable version so we can sync
> back again, but if the plan is to move to the experimental version soon,
> which I assume includes the fix (didn't check), then that works too.
> 
> ... Adam

Just checked with ubuntu autopkgtest infra... this is still needed.

G.



signature.asc
Description: OpenPGP digital signature

Bug#832558: dkms: mkdeb --source-only fails: can't find package

[Martin Galvan]

Package: dkms
Version: 2.3-3ubuntu3
Tags: patch
Followup-For: Bug #832558

I'm attaching a patch that fixes /etc/dkms/template-dkms-mkdeb/debian/control
so that the generated .deb has the arch suffix instead of 'all'.

-- System Information:
Debian Release: stretch/sid
  APT prefers artful-updates
  APT policy: (500, 'artful-updates'), (500, 'artful-security'), (500, 'artful')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dkms depends on:
ii  build-essential  12.4ubuntu1
ii  coreutils8.26-3ubuntu4
ii  dpkg-dev 1.18.24ubuntu1
ii  gcc  4:7.2.0-1ubuntu1
ii  kmod 24-1ubuntu2
ii  make 4.1-9.1
ii  patch2.7.5-1build1

Versions of packages dkms recommends:
ii  fakeroot 1.21-1ubuntu2
ii  linux-headers-4.13.0-16-generic [linux-headers]  4.13.0-16.19
ii  linux-headers-generic4.13.0.16.17
ii  lsb-release  9.20160110ubuntu5
ii  sudo 1.8.20p2-1ubuntu1

Versions of packages dkms suggests:
pn  menu
ii  python3-apport  2.20.7-0ubuntu3.1

-- no debconf information
--- a/etc/dkms/template-dkms-mkdeb/debian/control   2017-10-31 
14:40:41.690069116 -0300
+++ b/etc/dkms/template-dkms-mkdeb/debian/control   2017-10-31 
14:41:12.137973994 -0300
@@ -6,6 +6,6 @@
 Standards-Version: 3.8.1

 Package: DEBIAN_PACKAGE-dkms
-Architecture: all
+Architecture: DEBIAN_BUILD_ARCH
 Depends: dkms (>= 1.95), ${misc:Depends}
 Description: DEBIAN_PACKAGE driver in DKMS format.

Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs

[Ben Hutchings]

On Tue, 2017-10-31 at 17:10 +0100, Christoph Anton Mitterer wrote:
> The severity would have shown people which haven't upgraded, that there
> are issues... :-(
> 
> 
> On Tue, 2017-10-31 at 16:01 +, Ben Hutchings wrote:
[...]
> > Applications built for Linux are unrelated to Linux?  I don't think
> > so.
> 
> With that argument, one everything would be related on the kernel...
> and on the bootloader (cause without it, not applications at all)...
> and so on.
[...]

But without that argument, any regression in a kernel that breaks an
appplication is RC!  I doubt we could ever release Debian with a kernel
included if we followed your reasoning.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert
Einstein



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

Bug#880446: GitPython: new upstream version 2.1.7

[Robbie Harwood]

Package: python-git
Version: 2.1.6-1
Severity: normal

Dear Maintainer,

A new upstream version of GitPython is available (2.1.7), released three days
after 2.1.6.  Among other things, this version contains fixes for working
worktrees.

I would appreciate if you could package this.

Thanks!

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

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

Versions of packages python-git depends on:
ii  git [git-core]  1:2.14.2-1
ii  python  2.7.14-1
ii  python-gitdb2.0.2-1

python-git recommends no packages.

Versions of packages python-git suggests:
pn  python-git-doc  
ii  python-smmap2.0.3-1

-- no debconf information

Bug#880415: devscripts: uscan - also accept https://sf.net/

[Mattia Rizzolo]

Control: forcemerge -1 879207

On Tue, Oct 31, 2017 at 12:04:17PM +0100, Jeffrey Ratcliffe wrote:
> When I contacted the maintainers of lintian, I was asked to file a bug against
> uscan:
> 
> > Indeed; uscan special-cases the "http://sf.net/; URL and completely
> > rewrites it.  I think the best solution would be for uscan to also
> > accept "https://sf.net/;

That's already part of the latest release, 1.17.11.

-- 
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#880447: RFS: opencryptoki/3.8.1+dfsg-1

[Paulo Ricardo Paz Vital]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: opencryptoki
   Version : 3.8.1+dfsg-1
   Upstream Author : openCryptoki team
 * URL : http://github.com/opencryptoki/opencryptoki
 * License : CPL
   Section : admin

  It builds those binary packages:

 libopencryptoki-dev - PKCS#11 implementation (development)
 libopencryptoki0 - PKCS#11 implementation (library)
 opencryptoki - PKCS#11 implementation (daemon)

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/o/opencryptoki/opencryptoki_3.8.1+dfsg-1.dsc


  Changes since the last upload:

opencryptoki (3.8.1+dfsg-1) unstable; urgency=medium

  * New upstream release
  * Removed patch 08-reset-tpm-structures.patch
  * Removed patch systemd-targets.patch
  * Added patch tmpfiles-dir-creation.patch
  * Added patch icsf-spelling.patch
  * Fix Lintian error build-depends-on-obsolete-package:
Removed dh-systemd since used debhelper (>= 10)
  * Fix Lintian wanring useless-autoreconf-build-depends:
removed autotools-dev
  * Updated Standards-Version to 4.1.1

 -- Paulo Vital   Tue, 31 Oct 2017 10:16:06 -0200


  Regards,
   Paulo Vital

Bug#880448: alien: Large integers in version numbers are converted to floating point format

[Andrew Gallagher]

Package: alien
Version: 8.95
Severity: minor

When running alien against a package that has a large integer as one of the
version components (e.g. a nanosecond timestamp), alien appears to convert it
internally to floating point, with the result that the output filename contains
exponential notation. So, for example:

```
andrewg@fred:~/Downloads$ sudo alien --scripts 
dremio-community-1.2.2-201710100154510864_d40e31c_1.noarch.rpm 
dremio-community_1.2.2-2.01710100154511e+17_all.deb generated
```
 
One would expect that the version number components would be copied verbatim
between the input and output filenames.

Andrew.


-- System Information:
Debian Release: 9.1
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable'), (800, 'testing'), (700, 
'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages alien depends on:
ii  cpio   2.11+dfsg-6
ii  debhelper  10.2.5
ii  dpkg-dev   1.18.24
ii  make   4.1-9.1
ii  perl   5.24.1-3+deb9u1
ii  rpm4.12.0.2+dfsg1-2
ii  rpm2cpio   4.12.0.2+dfsg1-2

alien recommends no packages.

Versions of packages alien suggests:
ii  bzip21.0.6-8.1
pn  lintian  
ii  patch2.7.5-1+b2
ii  xz-utils [lzma]  5.2.2-1.2+b1

-- no debconf information

Bug#880449: unison: Uncaught exception Failure("input_value: bad bigarray kind")

[Vincent Lefevre]

On 2017-10-31 18:33:36 +0100, Vincent Lefevre wrote:
> Since the upgrade to 2.48.4-1, I get when synchronizing with
> a Debian/stable server:
> 
> Unison failed: Uncaught exception Failure("input_value: bad bigarray kind")
[...]

https://github.com/bcpierce00/unison/issues/94 says:

"This happens when unison is not compiled with the same version of ocaml
on both machines. I don't know the ocaml version used in debian testing,
but you should install the same one to compile in debian wheezy."

The reporter used wheezy there, but in my case, this is between
unstable (this version) and stretch.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#862461: tiptop: requires root to run

[Gunnar Wolf]

tags 862461 + patch
thanks

I agree with Nathaniel, the currently displayed message is too
confusing for regular users. A proper message should be displayed,
even if it means a (small!) deviation from upstream.

I am attaching a patch here, please consider!
Description: Report that root access is required
 When perf_event_paranoid level is set to 3 (default), tiptop requires
 root access to be run (#862461). Notify the user accordingly.
Author: Gunnar Wolf 

Origin: vendor https://bugs.debian.org/862461
Bug-Debian: https://bugs.debian.org/862461
Forwarded: no
Reviewed-By: Gunnar Wolf 
Last-Update: 2017-10-31

Index: tiptop-2.3.1/src/requisite.c
===
--- tiptop-2.3.1.orig/src/requisite.c
+++ tiptop-2.3.1/src/requisite.c
@@ -69,8 +69,11 @@ int check()
 else if (strcmp(os.release, "2.6.31") < 0) {  /* lexicographic order */
   fprintf(stderr, "Linux 2.6.31+ is required, OS reports '%s'.\n",
   os.release);
-}
-else {
+} else if (paranoia_level == 3) {
+  fprintf(stderr, "Your kernel is set with an event paranoia value of 3\n");
+  fprintf(stderr, "Either run this program as root, or set a lower\n");
+  fprintf(stderr, "paranoia value at '%s'.\n", PARANOID2);
+} else {
   fprintf(stderr, "Don't know why...\n");
 }
 exit(EXIT_FAILURE);


signature.asc
Description: PGP signature

Bug#880422: asymptote: please consider the attached suggestions

[Norbert Preining]

Hi Nicolas,

big thanks for your work, that is very much appreciated!
I have applied *all* of your patches besides one, the switch to python3.
I am not sure what the recommended way here is, so I would like to
discuss this before applying. The other items are all very fine and I
appreciated your help a lot!!!

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#812721: gbp could filter out Files-Excluded: entries when committing to the pristine-tar branch

[Michael Stapelberg]

Hi Guido,

The pkg-go team is currently discussing changes to its workflow, and
we’d be interested in resolving this feature request.

Guido Günther  writes:
> I would rather do this with a dfsg-clean branch. You delete once and
> then use git tools from there on.

Searching for how dfsg-clean branches should be named, I found
https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.branch.naming.html,
which recommends “dfsg/latest”.

However, my reading of section “About repacked upstream sources” of
http://dep.debian.net/deps/dep14/ directly contradicts the above advice:
DEP14 says upstream/* should contain the repackaged files.

How do we reconcile this apparent contradiction?

>> It would be great if gbp could produce the 1.2.3+dfsg tag itself by
>> reading debian/copyright and excluding the Files-Excluded: files.
>
> If somebody comes up with a clean patch I'm happy to merge that.

Which part of gbp specifically should be patched here? AFAICT, there is
no command which pulls a new version from upstream yet. Should one be
added? What should it be called?

-- 
Best regards,
Michael

Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs

[Christoph Anton Mitterer]

Package: src:linux
Version: 4.13.10-1
Severity: critical
Justification: breaks unrelated software


Hi.

Apparently AppArmor was enabled per default in the last version.

While I'm usually in favour of anything that improves security
(leaving aside the question here whether SELinux wouldn't be the much
more powerful solution ;-) )... this happened too silent (e.g. no
NEWS entry)... peopl may not even have installed the userland tools.

Also it breaks unrelated software, e.g. tor no longer starts and some
more as well.


Cheers,
Chris.

Bug#880443: RFS: spyder-reports/0.1.1-1 [ITP]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: spyder-reports
  Version : 0.1.1-1
  Upstream Author : Spyder Project Contributors
* URL : https://github.com/spyder-ide/spyder-reports
* License : Expat
  Section : python

Please check out the package by visiting the following URL:


https://anonscm.debian.org/cgit/debian-science/packages/spyder-reports.git

Changes since the last upload:

  * Initial release. (Closes: #872534)

Regards,
Ghis

Bug#880444: ITP: dde-qt-dbus-factory -- Qt DBus interface library for Deepin software

[Boyuan Yang]

Package: wnpp
Severity: wishlist
Owner: Boyuan Yang <073p...@gmail.com>
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: dde-qt-dbus-factory
  Version : 0.3.2
  Upstream Author : Deepin Technology Co., Ltd.
* URL : https://github.com/linuxdeepin/dde-qt-dbus-factory
* License : GPL-3+
  Programming Lang: C++/Qt
  Description : Qt DBus interface library for Deepin software

 Libdframeworkdbus provides Qt DBus interface for various Deepin software.
 It centralizes DBus-related code into single library for Deepin software
 written in Qt and get itself generated from handwritten XML DBus interface
 descriptions.
 .
 This package is part of DDE (Deepin Desktop Environment).

I intend to co-maintain it in pkg-deepin group.

Regards,
Boyuan Yang

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

Bug#879787: transition: qtbase-opensource-src 5.9.2

[Emilio Pozuelo Monfort]

On 31/10/17 01:53, Andreas Beckmann wrote:
> Followup-For: Bug #879787
> 
> The binNMUs for experimental:
> 
> nmu akonadi_4:17.08.0-1 . ANY . experimental . -m "Rebuild against 
> qtbase-abi-5-9-2."
> nmu qtspeech-opensource-src_5.9.1-1 . ANY . experimental . -m "Rebuild 
> against qtbase-abi-5-9-2."

Done, thanks.

Emilio

Bug#880310: recoll: FTBFS: configure: error: qmake seems to be using Qt version 3 which is not supported any more

[Jean-Francois Dockes]

Lucas Nussbaum writes:
 > Source: recoll
 > Version: 1.23.2-1
 > Severity: serious
 > Tags: buster sid
 > User: debian...@lists.debian.org
 > Usertags: qa-ftbfs-20171030 qa-ftbfs
 > Justification: FTBFS on amd64
 > 
 > Hi,
 > 
 > During a rebuild of all packages in sid, your package failed to build on
 > amd64.
 > 
 > Relevant part (hopefully):
 > > checking for pthread_create in -lpthread... yes
 > > checking for dlopen in -ldl... yes
 > > checking for zlibVersion in -lz... yes
 > > checking for type of inbuf parameter to iconv... checking for type of 
 > > string parameter to putenv... checking for xapian-config... 
 > > /usr/bin/xapian-config
 > > checking for qmake... /usr/bin/qmake
 > > configure: error: qmake seems to be using Qt version 3 which is not 
 > > supported any more
 > > debian/rules:28: recipe for target 'config.status' failed
 > 
 > The full build log is available from:
 >http://aws-logs.debian.net/2017/10/30/recoll_1.23.2-1_unstable.log
 > 
 > A list of current common problems and possible solutions is available at
 > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
 > 
 > About the archive rebuild: The rebuild was done on EC2 VM instances from
 > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
 > failed build was retried once to eliminate random failures.


This seems to work fine for me (Build log on my Debian unstable VM follows).

The message about qt 3 is misleading, I'll change it. The part which fails
is the following: 


  # Check Qt version
  qmakevers="`${QMAKE} --version 2>&1`"
  #echo "qmake version: $qmakevers"
  v4=`expr "$qmakevers" : '.*Qt[ ][ ]*version[ ][ ]*4.*'`
  v5=`expr "$qmakevers" : '.*Qt[ ][ ]*version[ ][ ]*5.*'`
  if test X$v4 = X0 -a X$v5 = X0; then
 AC_MSG_ERROR([qmake seems to be using Qt version 3 which is not supported 
any more])
  else
if test X$v4 != X0 ; then
   AC_MSG_NOTICE([using qt version 4 user interface])
else
   AC_MSG_NOTICE([using qt version 5 user interface])
fi
QTGUI=qtgui
  fi



Have you got a way to print the output from:

/usr/bin/qmake --version 

in your build environment ?

Jf


deb-sid-64$ cat /etc/debian_version 
buster/sid

deb-sid-64$ cat /etc/apt/sources.list
deb http://debian.proxad.net/debian/ unstable main
deb-src http://debian.proxad.net/debian/ unstable main


deb-sid-64$ sudo apt update
Hit:1 http://debian.proxad.net/debian unstable InRelease
Hit:2 http://www.lesbonscomptes.com/upmpdcli/downloads/debian stretch InRelease
Reading package lists... Done
Building dependency tree   
Reading state information... Done
All packages are up to date.


deb-sid-64$ sudo apt dist-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.


deb-sid-64$ mkdir rclsrc
deb-sid-64$ cd rclsrc/
deb-sid-64$ apt-get source recoll
Reading package lists... Done
NOTICE: 'recoll' packaging is maintained in the 'Git' version control system at:
https://anonscm.debian.org/cgit/collab-maint/recoll.git
Please use:
git clone https://anonscm.debian.org/cgit/collab-maint/recoll.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 2559 kB of source archives.
Get:1 http://debian.proxad.net/debian unstable/main recoll 1.23.2-1 (dsc) [2132 
B]
Get:2 http://debian.proxad.net/debian unstable/main recoll 1.23.2-1 (tar) [2547 
kB]
Get:3 http://debian.proxad.net/debian unstable/main recoll 1.23.2-1 (diff) 
[9680 B]
Fetched 2559 kB in 4s (534 kB/s)
dpkg-source: info: extracting recoll in recoll-1.23.2
dpkg-source: info: unpacking recoll_1.23.2.orig.tar.gz
dpkg-source: info: unpacking recoll_1.23.2-1.debian.tar.xz



deb-sid-64$ cd recoll-1.23.2/
deb-sid-64$ debuild
 dpkg-buildpackage -rfakeroot -us -uc -ui
dpkg-buildpackage: info: source package recoll
dpkg-buildpackage: info: source version 1.23.2-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Kartik Mistry 
 dpkg-source --before-build recoll-1.23.2
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp config.log
[ ! -f Makefile ] || /usr/bin/make distclean
dh_clean Makefile
 dpkg-source -b recoll-1.23.2
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building recoll using existing ./recoll_1.23.2.orig.tar.gz
dpkg-source: warning: ignoring deletion of file filters/#rclpdf.py#, use 
--include-removal to override
dpkg-source: info: building recoll in recoll_1.23.2-1.debian.tar.xz
dpkg-source: info: building recoll in recoll_1.23.2-1.dsc
 debian/rules build
dh_testdir
./configure CFLAGS="-g -O2 
-fdebug-prefix-map=/home/dockes/rclsrc/recoll-1.23.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2" 
LDFLAGS="-Wl,-z,relro" \

Bug#880439: stretch-pu: package getmail4/4.53.0-2+deb9u1

[Adam D. Barratt]

On 2017-10-31 14:40, Osamu Aoki wrote:

I just uploaded to the stable-proposed-upload.


Unfortunately you used an inappropriate version number, so I've flagged 
the package for rejection.


Currently unstable has version 4.53.0-2. The version you used - 
4.53.0-2+deb9u1 is *higher* than the unstable version, which is wrong. A 
backport to stable of that version should be 4.53.0-2~deb9u1, in the 
same way as backports uses ~.


Please also use "stretch" as the changelog distribution, rather than 
"stable".


Regards,

Adam

Bug#880201: www.debian.org: Release notes formats (html, pdf, txt) are shown in different order for each release

[Damyan Ivanov]

-=| Laura Arjona Reina, 30.10.2017 15:49:34 +0100 |=-
> Package: www.debian.org
> Severity: minor
> 
> The order of the formats in releases notes is different for every release:
> 
> https://www.debian.org/releases/jessie/releasenotes
> 
> shows the release notes available ordered by arch and txt pdf html
> 
> https://www.debian.org/releases/stretch/releasenotes
> shows the release notes available ordered by arch and pdf html txt
> 
> https://www.debian.org/releases/buster/releasenotes not yet available
> 
> All those pages are built using the Perl sub permute_as_matrix_new
> present in
> https://anonscm.debian.org/viewvc/webwml/webwml/english/template/debian/release.wml?view=markup
> 
> Maybe the cause is L176 of that script:
> 
>  foreach $ext (keys %formats) {
> 
> Does the "keys" function return the values always in the same order? (not sure
> about this point,
> I've read http://perldoc.perl.org/functions/keys.html but I didn't understand
> it very well, and I'm not
> a Perl programmer).
> 
> If this is the issue, the solution would be to change that line to 
> something sorting the output of keys.

Yep, this needs to become "foreach $ext (sort keys %formats) {"

I have just committed the fix.


Cheers,
dam

Bug#879590: apparmor breaks all kinds of stuff

[Christoph Anton Mitterer]

Hi.

First... shouldn't there have been at least some NEWS entry if
something like this is enabled?

Many people will not have even the apprmor packages/policies
installed... yet apparently it is still active.

All kinds of programs seem to fail now... e.g. tor won't start anymore,
 aptitude cannot download changelogs.

Please undo (or at least tell users what happens and what they can do
about it), until these issues are resolved.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#880442: RFS: python-jsonrpc/1.10.3-1 [ITP]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: python-jsonrpc
  Version : 1.10.3-1
  Upstream Author : Kirill Pavlov 
* URL : https://github.com/pavlov99/json-rpc
* License : Expat
  Section : python

Please check out the package by visiting the following URL:


https://anonscm.debian.org/cgit/python-modules/packages/python-jsonrpc.git

Changes since the last upload:

  * Initial release. (Closes: #879050)

Regards,
Ghis

Bug#880171: ITP: perse -- Permission settings GUI for udev devices

[Ville Ranki]

On Mon, 30 Oct 2017, Al Nikolov wrote:


Thought, you might be needing sponsorship for that, which I will gladly
provide.


Yes, that was my next question. The sources are in github,
including debian packaging. Could you review them, especially
debian packaging and tell me how to get this forward.

--
Ville Ranki 
http://www.iki.fi/~cos
PGP public key: http://www.iki.fi/~cos/vranki_pub.asc

Bug#879738: transition: gnustep-base

[Emilio Pozuelo Monfort]

On 30/10/17 17:19, Yavor Doganov wrote:
> On Thu, 26 Oct 2017 11:15:53 +0300,
> Emilio Pozuelo Monfort wrote:
>> On 25/10/17 10:28, Yavor Doganov wrote:
>>> We would like to carry out a gnustep-base transition:
>>> libgnustep-base1.24 -> libgnustep-base1.25
> 
>> Please go ahead.
> 
> 1.25.0-2 is built and installed on all arches; please schedule the
> binNMUs at your earliest convenience.  Thanks.

Done.

Emilio

Bug#880381: apparmor profile breaks xul-ext-exteditor

[W. Martin Borgert]

On 2017-10-31 07:57, intrigeri wrote:
> W. Martin, can you please retry with this profile:
> https://anonscm.debian.org/cgit/pkg-mozilla/thunderbird.git/tree/debian/apparmor/usr.bin.thunderbird

Works! :~) Thanks to all!


signature.asc
Description: PGP signature

Bug#851186: RFA: cligh -- Command-line interface to GitHub

[eamanu15 .]

Hello,

I am interested to adopt the cligh package.

Regards!

Bug#880171: ITP: perse -- Permission settings GUI for udev devices

[Al Nikolov]

Hello Ville

В Вт, 31/10/2017 в 17:07 +0200, Ville Ranki пишет:

> Yes, that was my next question. The sources are in github,
> including debian packaging. Could you review them, especially
> debian packaging and tell me how to get this forward.

These things hit my eye immediately.


If you publish this code under GPL, it's not enough just to briefly
mention that in your `README.md`. Please do what the official "How
to"[1] explains.

[1]https://www.gnu.org/licenses/gpl-howto.html


Shipping the "upstream" `debian` directory is undesirable[2]. I suggest
you to use at least a different branch in the repo of yours for Debian
packaging, or as many would prefer instead, Alioth[3]

[2]https://wiki.debian.org/DebianMentorsFaq#What.27s_wrong_with_upstrea
m_shipping_a_debian.2F_directory.3F

[3]https://wiki.debian.org/Alioth/Git


Squash the `debian/changelog` to contain just one proper entry, and
make sure it closes your ITP[4]

[4]https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#changelo
g


Build the source package and put it, for instance, to mentors[5]. Then,
let me know.

[5]https://mentors.debian.net/

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

Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs

[Ben Hutchings]

Control: severity -1 important
Control: affects -1 tor

On Tue, 2017-10-31 at 16:07 +0100, Christoph Anton Mitterer wrote:
> Package: src:linux
> Version: 4.13.10-1
> Severity: critical
> Justification: breaks unrelated software
>
> Apparently AppArmor was enabled per default in the last version.

Although you can disable it (security=dac or apparmor=0) if you want.

> While I'm usually in favour of anything that improves security
> (leaving aside the question here whether SELinux wouldn't be the much
> more powerful solution ;-) )... this happened too silent (e.g. no
> NEWS entry)... peopl may not even have installed the userland tools.

The change was noted in the changelog, so it's not silent.

I intend to add a NEWS entry in the next linux-latest upload.  It
doesn't make sense to add NEWS to linux-image-* packages as that will
only be displayed for upgrades that don't involve an ABI bump

My understanding was that enabling AppArmor shouldn't do very much
until a policy is loaded (which it won't be if you don't install the
userland tools).  As you've found, that isn't entirely correct.

> Also it breaks unrelated software, e.g. tor no longer starts and some
> more as well.

Applications built for Linux are unrelated to Linux?  I don't think so.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert
Einstein



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

Bug#880258: [Debian-med-packaging] Bug#880258: Bug#880258: picard-tools: FTBFS: CollectRrbsMetricsTest.java:29: error: package org.testng does not exist

[Olivier Sallou]

On 10/31/2017 03:05 PM, Olivier Sallou wrote:
> testng maven definition needs to be modified in build.graddle to match
> testng debian pom.
>
> Following patch fix the compilation for tests:
>
> --- a/build.gradle
> +++ b/build.gradle
> @@ -32,7 +32,7 @@
>  compile 'com.github.samtools:htsjdk:' + htsjdkVersion
>  //tools dependency for doclet requires sdk devel
>  compile(files(((URLClassLoader)
> ToolProvider.getSystemToolClassLoader()).getURLs()))
> -    testCompile 'org.testng:testng:6.9.10'
> +    testCompile 'org.testng:testng:debian'
>  }
>  
>  sourceCompatibility = 1.8
>
>
> however, all tests fail with the same issue than htsjdk when using
> testng in graddle
>
> Cannot nest operations in the same thread. Each nested operation must
> run in its own thread.
> java.lang.UnsupportedOperationException: Cannot nest operations in the
> same thread. Each nested operation must run in its own thread.
of course, we could easilly (though need to add patch anyway) to skip
testing, and wait to find a way to fix this gradle+testng issue, but
could lead to invalid packages
>
> I have no idea why (not using gradle), and asked to java team but got
> not answer for the moment.
>
> Olivier
>
>
> On 10/30/2017 08:26 PM, Lucas Nussbaum wrote:
>> Source: picard-tools
>> Version: 2.8.1+dfsg-2
>> Severity: serious
>> Tags: buster sid
>> User: debian...@lists.debian.org
>> Usertags: qa-ftbfs-20171030 qa-ftbfs
>> Justification: FTBFS on amd64
>>
>> Hi,
>>
>> During a rebuild of all packages in sid, your package failed to build on
>> amd64.
>>
>> Relevant part (hopefully):
>>> make[1]: Entering directory '/<>/picard-tools-2.8.1+dfsg'
>>> # Tests do not work with locales with a different decimal separator
>>> # (for example ',') 
>>> env LC_ALL=C \
>>> dh_auto_build -- test
>>> mkdir -p .gradle/init.d
>>> cp /usr/share/gradle-debian-helper/init.gradle .gradle/init.d/
>>> gradle --info --console plain --offline --stacktrace --no-daemon 
>>> --refresh-dependencies --gradle-user-home .gradle -Duser.home=. 
>>> -Duser.name=debian -Ddebian.package=picard-tools -Dfile.encoding=UTF-8 
>>> --parallel --max-workers=16 test
>>> Initialized native services in: 
>>> /<>/picard-tools-2.8.1+dfsg/.gradle/native
>>> To honour the JVM settings for this build a new JVM will be forked. Please 
>>> consider using the daemon: 
>>> https://docs.gradle.org/3.2.1/userguide/gradle_daemon.html.
>>> Starting daemon process: workingDir = 
>>> /<>/picard-tools-2.8.1+dfsg/.gradle/daemon/3.2.1, daemonArgs: 
>>> [/usr/lib/jvm/java-8-openjdk-amd64/bin/java, -XX:MaxPermSize=256m, 
>>> -XX:+HeapDumpOnOutOfMemoryError, -Xmx1024m, -Dfile.encoding=UTF-8, 
>>> -Duser.country=US, -Duser.language=en, -Duser.variant, -cp, 
>>> /usr/share/gradle/lib/gradle-launcher-3.2.1.jar, 
>>> org.gradle.launcher.daemon.bootstrap.GradleDaemon, 3.2.1]
>>> Starting process 'Gradle build daemon'. Working directory: 
>>> /<>/picard-tools-2.8.1+dfsg/.gradle/daemon/3.2.1 Command: 
>>> /usr/lib/jvm/java-8-openjdk-amd64/bin/java -XX:MaxPermSize=256m 
>>> -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 
>>> -Duser.country=US -Duser.language=en -Duser.variant -cp 
>>> /usr/share/gradle/lib/gradle-launcher-3.2.1.jar 
>>> org.gradle.launcher.daemon.bootstrap.GradleDaemon 3.2.1
>>> Successfully started process 'Gradle build daemon'
>>> An attempt to start the daemon took 0.62 secs.
>>> Connected to daemon DaemonInfo{pid=103081, 
>>> address=[2e268c2e-3c63-4337-afd4-2e65ac75aac2 port:38729, 
>>> addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Busy, 
>>> lastBusy=1509376996459, 
>>> context=DefaultDaemonContext[uid=2cc7999a-a025-4898-ba87-3e84d29d2241,javaHome=/usr/lib/jvm/java-8-openjdk-amd64,daemonRegistryDir=/<>/picard-tools-2.8.1+dfsg/.gradle/daemon,pid=103081,idleTimeout=12,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]}.
>>>  Dispatching request 
>>> BuildAndStop{id=642d5534-8837-4bd9-b101-9d40666366dc.1, 
>>> currentDir=/<>/picard-tools-2.8.1+dfsg}.
>>> Received result org.gradle.launcher.daemon.protocol.BuildStarted@4a3631f8 
>>> from daemon DaemonInfo{pid=103081, 
>>> address=[2e268c2e-3c63-4337-afd4-2e65ac75aac2 port:38729, 
>>> addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Busy, 
>>> lastBusy=1509376996459, 
>>> context=DefaultDaemonContext[uid=2cc7999a-a025-4898-ba87-3e84d29d2241,javaHome=/usr/lib/jvm/java-8-openjdk-amd64,daemonRegistryDir=/<>/picard-tools-2.8.1+dfsg/.gradle/daemon,pid=103081,idleTimeout=12,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]}
>>>  (build should be starting).
>>> The client will now receive all logging from the daemon (pid: 103081). The 
>>> daemon log file: 
>>> /<>/picard-tools-2.8.1+dfsg/.gradle/daemon/3.2.1/daemon-103081.out.log
>>> Closing daemon's stdin at end of input.
>>> The daemon will 

Bug#879900: apparmor-profiles-extra: Totem segfaults when apparmor profile is enforced

[Jason Wittlin-Cohen]

Woops.  The second line should read: "As for the totem profile on Stretch,
simply adding #include  to
/etc/apparmor.d/local/usr.bin.totem and reloading the profile did not fix
the issue:"

Bug#873860: [Pkg-ime-devel] Bug#873860: ibus-anthy FTBFS: UnicodeDecodeError: 'euc_jp' codec can't decode byte 0xe5 in position 46: illegal multibyte sequence

[Osamu Aoki]

Hi,

On Fri, Oct 27, 2017 at 04:38:08PM +0900, Takatsugu Nokubi wrote:
> On Fri, 22 Sep 2017 23:20:39 +0900 Osamu Aoki  wrote:
> > On Fri, Sep 22, 2017 at 09:14:22AM +0200, John Paul Adrian Glaubitz wrote:
> > > This FTBFS can be easily fixed with:
> > >
> > > --- ibus-anthy-1.5.9.orig/data/zipcode-textdic.py
> > > +++ ibus-anthy-1.5.9/data/zipcode-textdic.py
> > > @@ -21,7 +21,7 @@ if len(sys.argv) < 2:
> > >  anthy_zipfile = sys.argv[1]
> > >
> > >  try:
> > > -contents = codecs.open(anthy_zipfile, 'r', 'euc_jp').read()
> > > +contents = codecs.open(anthy_zipfile, 'r', 'utf-8').read()
> > >  except UnicodeDecodeError as e:
> > >  print('Your file is not eucJP? %s' % anthy_zipfile, file=sys.stderr)
> > >  contents = open(anthy_zipfile).read()
> 
> I think it seems right way.
> 
> > Question is how to coordinate with other anthy users and the latest
> > ibus.
> 
> I had to see the upstream code, and the script seems not there.
> https://github.com/phuang/ibus-anthy/tree/master/data
> 
> I think we can choose the 2 ways:
> 
> 1. just apply this patch
> It seems not come from the upstream, so we don't need to take
> care about it.
> 
> 2. fix to work with both encoding zipfile
> When the script get the exception, retry to open as utf-8, it may work
> both version of anthy.


I think 1 should be the way to move forward.

I thought about uploading ibus first but maybe I was wrong.  If you have
time, please upload fixed package.

The only thing to do maybe adding conflict to anthy in sid 1:0.3-6
to all the older non-UTF-8 compatible IM packages of
 ibus-anthy
 uim-anthy
 fcitx-anthy
as 1:0.3-7.  Then we can make all these packages move together from sid
to testing.  

Osamu

Bug#851651:

[MOHAMMED MAHMOUD]

add me to DV lottery

Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs

[Christoph Anton Mitterer]

The severity would have shown people which haven't upgraded, that there
are issues... :-(


On Tue, 2017-10-31 at 16:01 +, Ben Hutchings wrote:
> Although you can disable it (security=dac or apparmor=0) if you want.
Sure. I never said this wasn't possible.


> > While I'm usually in favour of anything that improves security
> > (leaving aside the question here whether SELinux wouldn't be the
> > much
> > more powerful solution ;-) )... this happened too silent (e.g. no
> > NEWS entry)... peopl may not even have installed the userland
> > tools.
> 
> The change was noted in the changelog, so it's not silent.

Well one cannot expect the average user to read every single entry of
the kernel changes included in there, can one?


> I intend to add a NEWS entry in the next linux-latest upload.  It
> doesn't make sense to add NEWS to linux-image-* packages as that will
> only be displayed for upgrades that don't involve an ABI bump

Perhaps one should have delayed the activation then until such bump, in
which the user will get an update for the meta-package as well.. which
then contains such notice :-)


> My understanding was that enabling AppArmor shouldn't do very much
> until a policy is loaded (which it won't be if you don't install the
> userland tools).  As you've found, that isn't entirely correct.

Mhh well that was a surprise for me as well :)


> Applications built for Linux are unrelated to Linux?  I don't think
> so.

With that argument, one everything would be related on the kernel...
and on the bootloader (cause without it, not applications at all)...
and so on.

smime.p7s
Description: S/MIME cryptographic signature

Bug#880445: digikam: Please make it installable using experimental packages

[valette]

Source: digikam
Version: 4:5.7.0-1
Severity: important


apt-get -t experimental install digikam digikam-private-libs kipi-plugins 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 digikam-private-libs : Depends: libmarblewidget-qt5-25 (>= 4:15.12.0) but it 
is not going to be installed
E: Unable to correct problems, you have held broken packages.
pink-floyd2:/home/valette# 

Version  libmarblewidget-qt5 is -28 no more -25

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

Kernel: Linux 4.9.59 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#880451: flatpak: older flatpak-dbus-proxy versions allowed legacy D-Bus eavesdropping

[Florian Weimer]

* Simon McVittie:

> My guess is that the security team is not interested in issuing a DSA
> for this vulnerability and would prefer me to issue a stable update
> (I'm going to ask the SRMs whether they'll accept 0.8.8 into stable,
> and if not, propose a 0.8.7-2~deb9u2 version). Is my guess correct?

This is not a vulnerability because Flatpak applications set their own
sandboxing policy, so no trust boundary is crossed.

Bug#880355: transition: libva

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 30/10/17 15:21, Sebastian Ramacher wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-libva.html
> Control: block -1 by 879064
> 
> libva 2.0 was released and it bumped its SONAME, so it needs a transition. 
> Note
> that somme reverse dependencies need sourceful uploads coordinated with the
> start of the transition: libva-utils and intel-vaapi-driver.
> 
> mesa (#879064) needs to be fixed. A rebuild will correctly rebuild against 
> libva
> 2.0, but it has an hard-coded dependency on libva1 which could be avoided by
> using dh_libva from libva-dev.
> 
> libyami currently fails to build (no bug, since I maintain that), but has a 
> fix
> available upstream. I'll upload a fixed version together with libva.
> 
> All other reverse dependencies build fine.

mesa is fixed now. Please go ahead.

Emilio

Bug#880454: mdns-scan FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: mdns-scan
Version: 0.5-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

mdns-scan fails to cross build from source, because it uses the build
architecture compiler. cdbs does set cross compilers via
DEB_MAKE_ENVVARS, but mdns-scan overrides them using a := assignment. By
switching that to +=, mdns-scan cross builds successfully. Please
consider applying the attached patch.

Helmut
diff -u mdns-scan-0.5/debian/changelog mdns-scan-0.5/debian/changelog
--- mdns-scan-0.5/debian/changelog
+++ mdns-scan-0.5/debian/changelog
@@ -1,3 +1,10 @@
+mdns-scan (0.5-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Append to DEB_MAKE_ENVVARS (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 31 Oct 2017 20:00:48 +0100
+
 mdns-scan (0.5-2) unstable; urgency=low
 
   * Team upload.
diff -u mdns-scan-0.5/debian/rules mdns-scan-0.5/debian/rules
--- mdns-scan-0.5/debian/rules
+++ mdns-scan-0.5/debian/rules
@@ -4,7 +4,7 @@
 include /usr/share/cdbs/1/class/makefile.mk
 
 DEB_MAKE_INSTALL_TARGET=install
-DEB_MAKE_ENVVARS:=DESTDIR=./debian/mdns-scan
+DEB_MAKE_ENVVARS+=DESTDIR=./debian/mdns-scan
 
 DEB_INSTALL_MANPAGES_mdns-scan:=mdns-scan.1
 

Bug#880455: decruft feed2exec 0.8.0

[Antoine Beaupre]

Package: ftp.debian.org
Severity: normal

I screwed up the first uploads of feed2exec by using Arch: any, and
switched to Arch: all in 0.9.0, which lead to 0.8.0 cruft.

The report says:

* package feed2exec is arch any in version 0.8.0 but arch all in version 0.9.0
  - suggested command:
dak rm -m "[auto-cruft] obsolete arch any package" -s unstable -a 
hurd-i386,i386,mips,mipsel,powerpc,amd64,armel,kfreebsd-i386,kfreebsd-amd64,armhf,s390x,arm64,ppc64el,mips64el
 -p -b feed2exec

https://ftp-master.debian.org/cruft-report-daily.txt

I hope everything is in order!

Bug#880453: nmu: castle-game-engine_6.2+dfsg1-1

[Paul Gevers]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Yesterday I uploaded a new upstream version of fpc. Now castle-game-engine
needs to be rebuild to pick up the new fpc-abi-3.0.4.

nmu castle-game-engine_6.2+dfsg1-1 . ANY . unstable . -m "Rebuild using fpc 
3.0.4"

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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAln4xQEACgkQnFyZ6wW9
dQpkYAgAtCMiswpRzVQEwZIgJqiR7LJTM/M17+v3siGizu8HqbzSn7l89e7v7+9p
1GFjjXqluf6KCEp4/Mq+yed1CD27KCbm4nlVNN8tymm6chZOwjd14+Zd6GcxECVp
0nx7ql1OCHmpzc7gsQm2SwqIAQa/32vTahbeWNumrxyaY0Q2ITxpwxkQcHb/MryM
gRtxue+QCxLqIyroANojMHyudzbFS+L/hOsTUII/Godo5DZ/Bl09dbZUR4FHNQY8
S9Nj18T+treDs9Bhj36MxBp3/mopqGcqlLFChZDwID5d55J+lH6wZrRZIXA0/KuT
Ss3r4dXnsEx2WYKEsCyqFqmriKurhw==
=0RM7
-END PGP SIGNATURE-

Bug#880452: nmu: lazarus_1.8.0~rc5+dfsg-1

[Paul Gevers]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I uploaded a new upstream version of fpc yesterday. Now lazarus needs to be
rebuild to pick up the new fpc-abi-3.0.4.

nmu lazarus_1.8.0~rc5+dfsg-1 . ANY . unstable . -m "Rebuild using fpc 3.0.4"

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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAln4w+8ACgkQnFyZ6wW9
dQp0KggA0XWjrLdxFNPvSb80RwnlbHjfvg9BxjOJmH+CKVrBQCBfKxNsp89Luc3H
Q3myiR+6fBf7m+hEaCeoFSN3yEplrxYT3kBLu87Nd0/NQiltmDwq8OxR5XtPf4Wp
GQ7dWbt9FZvOHlniorFpilbdpEXpywYaJH4jC5sl29qEhW6BbKsY16GXQ865XSk2
ZafIN/A94GOCZlcz5iD7FLYHMl7qrSCLB5/gd4VCFwjFfb2XTYhUz055r6lBcR6T
pPrZ71ZeivFAJrC5sKyqahs1vrsHsyEUlCHnkRC99LQNwup7ClzYAUwDVncD0n0n
klw+KLTzedoUzvGhLp9kLdmRrdOXJw==
=sp4W
-END PGP SIGNATURE-

Bug#880457: ITP: node-resolve-cwd -- Resolve the path of a module like require.resolve()

[Raju Devidas]

Package: wnpp
Severity: wishlist
Owner: Raju Devidas 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-resolve-cwd
  Version : 2.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/resolve-cwd#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Resolve the path of a module.
 Resolve the path of a module like require.resolve() but from the
current working directory
 .
 Node.js is an event-based server-side JavaScript engine.

I need to package node-resolve-cwd as it is a dependency required to
packagenode-awa

Bug#878760: chromium: Chromium toolbar and menus are very badly scaled

[Franklin Bynum]

> The toolbar and all menus are so ridiculously huge as to make the browser
> unusable

The problem is that Chromium does not respect the system HiDPI scaling setting. 
Using the --force-device-scale-factor flag will change it from the default of 
1. For example,

chromium --force-device-scale-factor=2

Bug#848909: at FTCBFS: unsatisifable Build-Depends: perl

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2017-10-31 08:55 Jose M Calhariz:

Please do a nmu.


I am just uploading it, so marking as +pending.

I normally prefer if responsive maintainers do the NMU, but for your
reply I understand that you are busy.

I applied the changes in the git repo as well, so other than refreshing
the local copy, there's no extra work for you (or co-maintainers).

Thanks!

--
Manuel A. Fernandez Montecelo 

Bug#880425: thunderbird: logs spurious apparmor denial messages

[Simon Deziel]

On 2017-10-31 08:32 AM, Philipp Kern wrote:
> When I use Thunderbird I see a lot of these in the kernel log (probably
> whenever I look at a signed and/or encrypted email):
> 
> [94784.485686] audit: type=1400 audit(1509453045.981:153):
> apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg"
> name="/usr/share/thunderbird/omni.ja" pid=4440 comm="gpg2"
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> 
> I don't see an obvious degradation of the client. Even gpg-encrypted
> mails get handled correctly by Enigmail. But I suppose some kind of rule
> is missing to make the log lines go away?

On Ubuntu, omni.ja is in /usr/lib/thunderbird and there is no symlink to
/usr/share/thundebird. This is probably not relevant here though. That
said, I never encountered this denial myself.

I don't see why gpg would need to access this zip file inherited by the
parent, so I'd be tempted to add a deny rule to silence it. Opinions?

Regards,
Simon



signature.asc
Description: OpenPGP digital signature

Bug#880451: flatpak: older flatpak-dbus-proxy versions allowed legacy D-Bus eavesdropping

[Simon McVittie]

Package: flatpak
Version: 0.8.5-2
Severity: important
Tags: security

In Flatpak versions prior to 0.9.9 (mainline) and 0.8.8 (0.8.x), the
flatpak-dbus-proxy that is optionally used to filter D-Bus traffic did not
forbid match rules with eavesdrop="true", as used by dbus-monitor versions
prior to 1.9.10. Such match rules could be used by a sandboxed app to
spy on non-sandboxed apps' D-Bus session bus method calls (a local
confidentiality breach).

Apps that are configured to have unrestricted D-Bus access
([Context] sockets=session-bus;, see flatpak-metadata(5)) can do this even
in later versions, but this is not considered to be a bug: unrestricted
D-Bus access is just as unrestricted as you might expect it to be.

Mitigations:
* The apps that could exploit this are not entirely untrusted (the user
  has chosen to install and run them, and in particular has given them
  access to the attack surface of the Linux kernel)
* In practical sandboxed apps, the ability to spy on X11 (which
  everything is going to need to have until Wayland is ubiquitous)
  is more sensitive than the ability to spy on D-Bus
* We can't spy on the system bus like this, because of the security
  boundary between users

My guess is that the security team is not interested in issuing a DSA
for this vulnerability and would prefer me to issue a stable update
(I'm going to ask the SRMs whether they'll accept 0.8.8 into stable,
and if not, propose a 0.8.7-2~deb9u2 version). Is my guess correct?

Thanks,
smcv

Bug#877638: mate-panel: guake doesn't show in mate-notification area

[Vlad Orlov]

Hi,

Can you actually reproduce the issue? For me guake always shows the icon.
I've tried with locally built mate-panel 1.19, then downgraded to 1.18.4-2
from the repos. Also tried both manual launch of guake and autostart with
the session. No luck with reproducing.

Bug#880369: [pkg-bacula-devel] Bug#880369: bacula: missing package location

[Carsten Leonhardt]

Hi,

>* What led up to the situation?
>
> trying to re-install bacula, bacula-dir test program is missing and I cannot 
> locate the package it is in

>* What outcome did you expect instead?
>
> to get /usr/sbin/bacula-dir installed

the package "bacula-director" contains the program
/usr/sbin/bacula-dir. You can also use the search at
https://packages.debian.org.

If this answer doesn't help, please clarify your problem more precisely.

Regards,

Carsten

Bug#880456: sjeng FTCBFS: uses the build architecture toolchain

[Helmut Grohne]

Source: sjeng
Version: 11.2-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

sjeng fails to cross build from source, because it uses the build
architecture toolchain. It forces the build architecture compiler "gcc"
upon configure by setting CC and it uses the build architecture strip
via install -s. The former issue is fixed by using a triplet-prefixed CC
and the latter is fixed by not stripping at install time. Doing so also
lets dh_strip produce meaningful -dbgsym packages. Please consider
applying the attached patch.

Helmut
diff -u sjeng-11.2/debian/rules sjeng-11.2/debian/rules
--- sjeng-11.2/debian/rules
+++ sjeng-11.2/debian/rules
@@ -13,7 +13,7 @@
 export DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 export DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
-CC = gcc
+CC = $(DEB_HOST_GNU_TYPE)-gcc
 CFLAGS = -Wall -W -g
 LDFLAGS = 
 
@@ -33,10 +33,6 @@
 INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755
 INSTALL_FILE= $(INSTALL) -p-o root -g root  -m  644
 
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   INSTALL_PROGRAM += -s
-endif
-
 export CC CFLAGS LDFLAGS CXX CXXFLAGS INSTALL INSTALL_PROGRAM INSTALL_FILE
 
 config.status: $(QUILT_STAMPFN) configure
diff -u sjeng-11.2/debian/changelog sjeng-11.2/debian/changelog
--- sjeng-11.2/debian/changelog
+++ sjeng-11.2/debian/changelog
@@ -1,3 +1,12 @@
+sjeng (11.2-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Use a triplet-prefixed CC.
++ Defer stripping to dh_strip.
+
+ -- Helmut Grohne   Tue, 31 Oct 2017 20:20:50 +0100
+
 sjeng (11.2-8) unstable; urgency=low
 
   * Apply a patch to satisfy the xboard protocol related to SAN

Bug#880454: [Pkg-utopia-maintainers] Bug#880454: mdns-scan FTCBFS: uses the build architecture compiler

[Michael Biebl]

Hi

Am 31.10.2017 um 20:05 schrieb Helmut Grohne:
> Source: mdns-scan
> Version: 0.5-2
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> mdns-scan fails to cross build from source, because it uses the build
> architecture compiler. cdbs does set cross compilers via
> DEB_MAKE_ENVVARS, but mdns-scan overrides them using a := assignment. By
> switching that to +=, mdns-scan cross builds successfully. Please
> consider applying the attached patch.

Feel free to do an NMU without delay.
-- 
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#848923: mark gsfonts Multi-Arch: foreign

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2016-12-20 21:51 Helmut Grohne:

Package: gsfonts
Version: 1:8.11+urwcyr1.0.7~pre44-4.3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:axiom src:gloox src:gri src:hylafax src:imagemagick 
src:ipe src:witty

The packages listed under affects fail to satisfy their cross
Build-Depends, because their dependency on gsfonts is unsatisfiable. In
general, Architecture: all packages such as gsfonts can never satisfy
cross build dependencies unless marked Multi-Arch: foreign. In this
case, such a marking is correct, because gsfonts does not have any
dependencies and its maintainer scripts only invoke update-gsfontmap,
which does not have architecture-specific behaviour. Please consider
applying the attached patch.


Since the fix is very straightforward and the package seems unmaintained
(multiple NMUs over the years, without uploads from maintainers in this
decade) I am going to upload immediately.

In the worst case, the patch can be easily reverted.

Cheers.

--
Manuel A. Fernandez Montecelo 

Bug#812682: w3m FTCBFS: uses build architecture compiler

[Manuel A. Fernandez Montecelo]

Hi

2016-01-25 22:02 Helmut Grohne:

Source: w3m
Version: 0.5.3-26
User: heml...@debian.org


Helmut: wrong user...



Usertags: rebootstrap

Hi,

w3m fails to cross build from source for a number of reasons. Most
immediately, configure is run without --host and thus configures for the
build architecture. Even though configure has code for detecting the
name of pkg-config, it still falls back to calling it directly causing
it to miss libraries such as imlib2. I am attaching a patch for these
issues. Even after applying it, the build fails due to executing
./mknames. Since mknames is executed during build and not installed into
any package, it should be compiled with the build architecture compiler.
For this to work, it needs to stop #including things such as config.h
however. Also object files such as Str.o need to be built for both
architectures. I haven't figured out the details yet, so my patch is
only a partial solution. Hope it helps whomever is looking into cross
compiling w3m at a later time.


Tatsuya, what do you think about applying this fix?

Lots of packages build-depent on w3m (x11proto* and basic X libraries,
mutt...), it would be nice to be able to cross-build it from other
systems, for bootstrapping new architectures and similar scenarios.

Cheers.

--
Manuel A. Fernandez Montecelo 

Bug#880458: libcatalyst-plugin-static-simple-perl: leaks files without extention, inadvertently

[Damyan Ivanov]

Package: libcatalyst-plugin-static-simple-perl
Version: 0.31
Severity: important
Tags: security upstream fixed-upstream
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=120558

>From upstream changelog for version 0.34:

Fix security vulnerability, when serving static files with dots in 
the names (RT#120558)

Catalyst::Plugin::Static::Simple is a plugin for Catalyst, a web 
framework in Perl. Its purpose is to serve static files, and it is 
supposed to only serve files with extensions (from which it determines 
the content type).

Due to the bug, however, any file under a directory whose name contains a 
dot could be served.

the upstream fix is as follows:

--- a/lib/Catalyst/Plugin/Static/Simple.pm
+++ b/lib/Catalyst/Plugin/Static/Simple.pm
@@ -64,7 +64,7 @@ before prepare_action => sub {
 }
 
 # Does the path have an extension?
-if ( $path =~ /.*\.(\S{1,})$/xms ) {
+if ( $path =~ /\.([^\/\\]+)$/m ) {
 # and does it exist?
 $c->_locate_static_file( $path );
 }

That is, instead of matching one or more non-space characters between a 
dot (including "/") and the end of the path, match one or more characters 
different from "/" and "\" between a dot and the end of the path.

Cheers,
dam

Bug#880459: mark libkf5kipi-data Multi-Arch: foreign

[Helmut Grohne]

Package: libkf5kipi-data
Version: 4:16.08.2-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:gwenview src:kde-spectacle src:digikam

The packages listed under affects cannot satisfy their cross
Build-Depends, because their (transitive) dependency on libkf5kipi-data
is unsatisfiable. In general, Architecture: all packages can never
satisfy cross Build-Depends unless marked Multi-Arch: foreign. In this
case, such a marking is correct, because libkf5kipi-data doesn't have
any maintainer scripts nor dependencies. It is a plain data package.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru libkf5kipi-16.08.2/debian/changelog 
libkf5kipi-16.08.2/debian/changelog
--- libkf5kipi-16.08.2/debian/changelog 2016-10-19 00:15:03.0 +0200
+++ libkf5kipi-16.08.2/debian/changelog 2017-10-31 20:50:15.0 +0100
@@ -1,3 +1,10 @@
+libkf5kipi (4:16.08.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libkf5kipi-data Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 31 Oct 2017 20:50:15 +0100
+
 libkf5kipi (4:16.08.2-1) unstable; urgency=medium
 
   * New upstream release (16.08.2)
diff --minimal -Nru libkf5kipi-16.08.2/debian/control 
libkf5kipi-16.08.2/debian/control
--- libkf5kipi-16.08.2/debian/control   2016-10-19 00:15:03.0 +0200
+++ libkf5kipi-16.08.2/debian/control   2017-10-31 20:50:13.0 +0100
@@ -54,6 +54,7 @@
 
 Package: libkf5kipi-data
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Replaces: kdegraphics-libs-data (<< 4:4.6.80),
   libkdcraw5,

Bug#879738: transition: gnustep-base

[Yavor Doganov]

clone 879738 -1
reassign -1 gnustep-gui-runtime/0.25.0-4
retitle -1 gnustep-gui-runtime: Depends on gnustep-back0.25
severity -1 serious
thanks

Emilio Pozuelo Monfort wrote:
> On 30/10/17 17:19, Yavor Doganov wrote:
> > 1.25.0-2 is built and installed on all arches; please schedule the
> > binNMUs at your earliest convenience.  Thanks.
> 
> Done.

Thanks, but it looks like the transition is held by a bug in
gnustep-gui: gnustep-gui-runtime depends on gnustep-back0.25 while it
shouldn't.  libgnustep-gui-dev is pulling in -runtime and because
-back is not binNMUed yet, it still depends on libgnustep-base1.24 so
the Build-Depends of all packages build-depending on
libgnustep-gui-dev cannot be satisfied.
Classic "Catch 22" scenario.

The bug was introduced in gnustep-gui/0.25.0-1 during the migration to
modern debhelper but was not really visible before the removal of the
.symbols files in 0.25.0-4 (the shlibs were unused until then).

We'll need a sourceful upload of gnustep-gui fixing this issue in
order to proceed with the transition.

@Eric:
In fact this is fixed in master, but how do we proceed with the
repository now that there are lots of changes in master intended for
experimental?  We have to prepare an upload fixing only this bug.

Bug#878418: closed by Ondřej Nový <n...@ondrej.org> (Re: flake8: cannot check python2 code)

[Sandro Tosi]

> And because Python 2 is obsolete and we will remove it from Debian later, i 
> consider this correct solution.

what? flake8 is a tool to check python code, not strictly limited to
code shipped as part of debian packages. in stretch, python2 is still
supported, so this justification is moot and (as usual) not user
friendly


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi