Bug#910421: murasaki-mpi: broken symlinks: /usr/share/man/man1/*-mpi.1.gz -> *.1.gz

[Andreas Beckmann]

Package: murasaki-mpi
Version: 1.68.6-7
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

2m14.5s ERROR: FAIL: Broken symlinks:
  /usr/share/man/man1/murasaki-mpi.1.gz -> murasaki.1.gz (murasaki-mpi)
  /usr/share/man/man1/mbfa-mpi.1.gz -> mbfa.1.gz (murasaki-mpi)
  /usr/share/man/man1/geneparse-mpi.1.gz -> geneparse.1.gz (murasaki-mpi)


Perhaps the targeted manpages should be moved from murasaki to murasaki-common?


cheers,

Andreas


murasaki-mpi_1.68.6-7.log.gz
Description: application/gzip

Bug#910420: prometheus-alertmanager: broken symlinks: /usr/share/prometheus/alertmanager/ui/lib/* -> ../../../../javascript/*

[Andreas Beckmann]

Package: prometheus-alertmanager
Version: 0.15.1+ds-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m29.5s ERROR: FAIL: Broken symlinks:
  /usr/share/prometheus/alertmanager/ui/lib/moment -> 
../../../../javascript/moment (prometheus-alertmanager)
  /usr/share/prometheus/alertmanager/ui/lib/d3 -> ../../../../javascript/d3 
(prometheus-alertmanager)
  /usr/share/prometheus/alertmanager/ui/lib/angular.js -> 
../../../../javascript/angular.js (prometheus-alertmanager)


Is prometheus-alertmanager missing dependencies on some
javascript packages?


cheers,

Andreas


prometheus-alertmanager_0.15.1+ds-1.log.gz
Description: application/gzip

Bug#910419: pyfr-doc: broken symlink: /usr/share/doc/pyfr-doc/html/_static/MathJax.js -> ../../../../javascript/mathjax/MathJax.js

[Andreas Beckmann]

Package: pyfr-doc
Version: 1.5.0-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m30.3s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/pyfr-doc/html/_static/MathJax.js -> 
../../../../javascript/mathjax/MathJax.js (pyfr-doc)


Is pyfr-doc missing a Depends/Recommends/Suggests: libjs-mathjax ?


cheers,

Andreas


pyfr-doc_1.5.0-2.log.gz
Description: application/gzip

Bug#910418: python-pyregion-doc: broken symlink:

[Andreas Beckmann]

Package: python-pyregion-doc
Version: 2.0-4
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m29.6s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-pyregion/rst -> ../python-pyregion-doc/html/_sources 
(python-pyregion-doc)

But python-pyregion-doc now ships
  /usr/share/doc/python-pyregion/html/_sources
most likely due to a behavioral change of dh_installdocs
in debhelper compat level 11.


cheers,

Andreas


python-pyregion-doc_2.0-4.log.gz
Description: application/gzip

Bug#909706: epcr: Please provide autopkgtest

[Andreas Tille]

Hi Manas,

On Fri, Oct 05, 2018 at 09:22:45PM +0530, Manas Kashyap wrote:
>  I have tried to add autopkgtest to epcr package for the first time (as per
> Andreas instructed how to do it) , so please review it and give your view .

Do you have some not yet pushed changes to replace

  #do_stuff_to_test_package#

in debian/tests/run-unit-test?

There should be some code calling the executables with some sensible
data producing some sensible output.  The file README.txt contains some
example and it usually requires some bioinformaticians insight to find
those date samples and evaluate the output.  (And no, I can not help
here since I'm not a bioinformatician.)

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#910417: python3-fabulous-doc: broken symlink: /usr/share/doc/python3-fabulous-doc/rst -> html/_sources

[Andreas Beckmann]

Package: python3-fabulous-doc
Version: 0.3.0+dfsg1-4
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m29.0s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python3-fabulous-doc/rst -> html/_sources 
(python3-fabulous-doc)


But python3-fabulous-doc ships
  /usr/share/doc/python3-fabulous/html/_sources
most likely due to a behavioral change of dh_installdocs 
in debhelper compat level 11.


cheers,

Andreas


python3-fabulous-doc_0.3.0+dfsg1-4.log.gz
Description: application/gzip

Bug#910416: ruby-gettext-i18n-rails-js: broken symlink: /usr/share/rubygems-integration/all/gems/gettext_i18n_rails_js-1.3.0/vendor/assets/javascripts/gettext/jed.js -> vendor/assets/javascripts/gette

[Andreas Beckmann]

Package: ruby-gettext-i18n-rails-js
Version: 1.3.0+dfsg-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m38.7s ERROR: FAIL: Broken symlinks:
  
/usr/share/rubygems-integration/all/gems/gettext_i18n_rails_js-1.3.0/vendor/assets/javascripts/gettext/jed.js
 -> vendor/assets/javascripts/gettext/usr/share/javascript/jed/jed.js 
(ruby-gettext-i18n-rails-js)


cheers,

Andreas


ruby-gettext-i18n-rails-js_1.3.0+dfsg-2.log.gz
Description: application/gzip

Bug#910347: Acknowledgement (konsole: scaling factor causes tearing)

[ghost]

Control: tag -1 + confirmed upstream
Control: forwarded -1 + https://bugs.kde.org/show_bug.cgi?id=373232

found it on upstream's bug tracker... Although it's marked resolved for 
now, It's likely to be reopened as there are comments saying the fix is 
not working.

Bug#910415: sagetex-doc: broken symlink: /usr/share/texmf/doc/latex/sagetex/sagetex.pdf -> ../../../../doc/sagetex/sagetex.pdf

[Andreas Beckmann]

Package: sagetex-doc
Version: 3.0+ds-6
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m28.8s ERROR: FAIL: Broken symlinks:
  /usr/share/texmf/doc/latex/sagetex/sagetex.pdf -> 
../../../../doc/sagetex/sagetex.pdf (sagetex-doc)
^^^

The target should rather be /usr/share/doc/sagetex-doc/sagetex.pdf
   ^^^

cheers,

Andreas


sagetex-doc_3.0+ds-6.log.gz
Description: application/gzip

Bug#910414: ssake-examples: broken symlink: /usr/share/doc/ssake/examples/runSSAKE.sh -> ../tools/runSSAKE.sh

[Andreas Beckmann]

Package: ssake-examples
Version: 4.0-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m29.0s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/ssake/examples/runSSAKE.sh -> ../tools/runSSAKE.sh 
(ssake-examples)


The target does not seem to exist in any package in the archive.


cheers,

Andreas


ssake-examples_4.0-1.log.gz
Description: application/gzip

Bug#910413: zabbix-frontend-php: broken symlink: /usr/share/zabbix/fonts/DejaVuSans.ttf -> ../../fonts/truetype/ttf-dejavu/DejaVuSans.ttf

[Andreas Beckmann]

Package: zabbix-frontend-php
Version: 1:4.0.0+dfsg-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m14.5s ERROR: FAIL: Broken symlinks:
  /usr/share/zabbix/fonts/DejaVuSans.ttf -> 
../../fonts/truetype/ttf-dejavu/DejaVuSans.ttf (zabbix-frontend-php)


The link target should rather be /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
and zabbix-frontend-php seems to be missing a Depends/Recommends/Suggests: 
fonts-dejavu-core


cheers,

Andreas


zabbix-frontend-php_1:4.0.0+dfsg-1.log.gz
Description: application/gzip

Bug#910412: eric: broken symlink: /usr/share/eric/modules/WebBrowser/data/javascript/jquery-ui.js -> ../../../../../javascript/jquery/jquery-ui.js

[Andreas Beckmann]

Package: eric
Version: 18.10+ds1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m30.6s ERROR: FAIL: Broken symlinks:
  /usr/share/eric/modules/WebBrowser/data/javascript/jquery-ui.js -> 
../../../../../javascript/jquery/jquery-ui.js (eric)


The target actually lives in .../javascript/jquery-ui/jquery-ui.js
  ^^^

cheers,

Andreas


eric_18.10+ds1-1.log.gz
Description: application/gzip

Bug#910411: python3-django-hyperkitty: broken symlink: /usr/share/doc/python-django-hyperkitty/rst -> html/_sources

[Andreas Beckmann]

Package: python3-django-hyperkitty
Version: 1.2.1-3
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

2m8.7s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-django-hyperkitty/rst -> html/_sources 
(python3-django-hyperkitty)


This is either a copy+paste error missing s/python/python3/
or the link is placed in the wrong package.


cheers,

Andreas


python3-django-hyperkitty_1.2.1-3.log.gz
Description: application/gzip

Bug#910410: zulupolkit: doesn't seem to be used by the zulucrypt package

[ghost]

Package: zulupolkit
Version: 5.4.0-2
Severity: important

Dear Maintainer,

   According to upstream [0], the zulupolkit is used to make zulucrypt
   work without requiring root password at start up, and is the cited
   reason that upstream still maintains a binary package for debian. [1]

   While the zulupolkit is already in debian, the zulucrypt package does
   not seem to use it. I'm setting severity to important because this
   renders the whole package unusable for normal users even when a
   functionality doesn't specifically require root. 

Thanks.

[0]: https://github.com/mhogomchungu/zuluCrypt/issues/59#issuecomment-304850378
[1]: https://mhogomchungu.github.io/zuluCrypt/#binary-packages

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

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

Versions of packages zulupolkit depends on:
ii  libc6   2.27-6
ii  libgcc1 1:8.2.0-7
ii  libqt5core5a5.11.1+dfsg-9
ii  libqt5network5  5.11.1+dfsg-9
ii  libstdc++6  8.2.0-7
ii  policykit-1 0.105-21

zulupolkit recommends no packages.

zulupolkit suggests no packages.

-- no debconf information

Bug#910400: mysqli stopped connecting to MySQL servers using caching_sha2_password

[Ondřej Surý]

Control: severity -1 important 

That’s not a grave bug. Please do not abuse severities.

Ondřej
--
Ondřej Surý 

> On 6 Oct 2018, at 01:23, Piotr Jurkiewicz  
> wrote:
> 
> Package: php7.3-mysql
> Version: 7.3.0~rc2-2
> Severity: grave
> 
> After update to 7.3.0~rc2-2 (sid), mysqli extension stopped working. It can't 
> connect to MySQL server, giving the following error message:
> 
> PHP message: PHP Warning:  mysqli::__construct(): The server requested 
> authentication method unknown to the client [caching_sha2_password]
> 
> It worked before the update (version 7.3.0~alpha3-1, I think).
> 
> caching_sha2_password is the default authentication method in MySQL 8.0.
> 

Bug#910409: wayland-protocols: Can't use second monitor via HDMI

[Pavlo Solntsev]

Package: wayland-protocols
Version: 1.16-1
Severity: normal

Dear Maintainer,

I am not sure what package name I should use for this report. Today (Oct. 5,
22:40T+6) I updated my system debian testing and my external monitor stop
working. In my xrandr output I see only one monitor
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
XWAYLAND0 connected 1920x1080+0+0 (normal left inverted right x axis y axis)
290mm x 170mm
   1920x1080 59.96*+

Combination Fn+F8 (switch video mode) doesn't produce anything. I am not sure
what information I should ptovide. Please guide and I will send you info. You
can contact me directly if it helps: p.sun.fun at gmail dot com.

The following packages were upgraded:
2018-10-05 22:02:49 install libcamel-1.2-62:amd64  3.30.1-1
2018-10-05 22:02:49 status half-installed libcamel-1.2-62:amd64 3.30.1-1
2018-10-05 22:02:49 status half-installed evolution-plugin-bogofilter:amd64
3.28.5-1
2018-10-05 22:02:49 status half-installed evolution-plugin-bogofilter:amd64
3.28.5-1
2018-10-05 22:02:49 status half-installed evolution-plugin-pstimport:amd64
3.28.5-1
2018-10-05 22:02:49 status half-installed evolution-plugin-pstimport:amd64
3.28.5-1
2018-10-05 22:02:49 status half-installed evolution-plugins:amd64 3.28.5-1
2018-10-05 22:02:49 status half-installed evolution-plugins:amd64 3.28.5-1
2018-10-05 22:02:50 status half-installed evolution:amd64 3.28.5-1
2018-10-05 22:02:50 status half-installed evolution:amd64 3.28.5-1
2018-10-05 22:02:50 status half-installed libevolution:amd64 3.28.5-1
2018-10-05 22:02:50 status half-installed libevolution:amd64 3.28.5-1
2018-10-05 22:02:50 status half-installed evolution-data-server:amd64 3.28.5-3
2018-10-05 22:02:51 status half-installed evolution-data-server:amd64 3.28.5-3
2018-10-05 22:02:51 status installed libedata-cal-1.2-28:amd64 3.28.5-3
2018-10-05 22:02:51 status half-installed libedata-cal-1.2-28:amd64 3.28.5-3
2018-10-05 22:02:51 status not-installed libedata-cal-1.2-28:amd64 
2018-10-05 22:02:51 status half-installed libecal1.2-dev:amd64 3.28.5-3
2018-10-05 22:02:51 status half-installed libecal1.2-dev:amd64 3.28.5-3
2018-10-05 22:02:52 status half-installed libecal-1.2-19:amd64 3.28.5-3
2018-10-05 22:02:52 status half-installed libecal-1.2-19:amd64 3.28.5-3
2018-10-05 22:02:52 status half-installed libebook-1.2-19:amd64 3.28.5-3
2018-10-05 22:02:52 status half-installed libebook-1.2-19:amd64 3.28.5-3
2018-10-05 22:02:52 status half-installed libedata-book1.2-dev:amd64 3.28.5-3
2018-10-05 22:02:52 status half-installed libedata-book1.2-dev:amd64 3.28.5-3
2018-10-05 22:02:52 status half-installed libedata-book-1.2-25:amd64 3.28.5-3
2018-10-05 22:02:52 status half-installed libedata-book-1.2-25:amd64 3.28.5-3
2018-10-05 22:02:53 status half-installed libebackend1.2-dev:amd64 3.28.5-3
2018-10-05 22:02:53 status half-installed libebackend1.2-dev:amd64 3.28.5-3
2018-10-05 22:02:53 status half-installed libebackend-1.2-10:amd64 3.28.5-3
2018-10-05 22:02:53 status half-installed libebackend-1.2-10:amd64 3.28.5-3
2018-10-05 22:02:53 status half-installed libedataserverui1.2-dev:amd64
3.28.5-3
2018-10-05 22:02:53 status half-installed libedataserverui1.2-dev:amd64
3.28.5-3
2018-10-05 22:02:53 status half-installed libebook-contacts1.2-dev:amd64
3.28.5-3
2018-10-05 22:02:53 status half-installed libebook-contacts1.2-dev:amd64
3.28.5-3
2018-10-05 22:02:53 status half-installed libedataserver1.2-dev:amd64 3.28.5-3
2018-10-05 22:02:54 status half-installed libedataserver1.2-dev:amd64 3.28.5-3
2018-10-05 22:02:54 status half-installed libcamel1.2-dev:amd64 3.28.5-3
2018-10-05 22:02:54 status half-installed libcamel1.2-dev:amd64 3.28.5-3
2018-10-05 22:02:54 status half-installed libsecret-common:all 0.18.6-2
2018-10-05 22:02:54 status half-installed libsecret-common:all 0.18.6-2
2018-10-05 22:02:54 status half-installed libsecret-1-dev:amd64 0.18.6-2
2018-10-05 22:02:54 status half-installed libsecret-1-dev:amd64 0.18.6-2
2018-10-05 22:02:55 status half-installed libsecret-1-0:amd64 0.18.6-2
2018-10-05 22:02:55 status half-installed libsecret-1-0:amd64 0.18.6-2
2018-10-05 22:02:55 status half-installed gir1.2-secret-1:amd64 0.18.6-2
2018-10-05 22:02:55 status half-installed gir1.2-secret-1:amd64 0.18.6-2
2018-10-05 22:02:55 status half-installed gir1.2-ebookcontacts-1.2:amd64
3.28.5-3
2018-10-05 22:02:55 status half-installed gir1.2-ebookcontacts-1.2:amd64
3.28.5-3
2018-10-05 22:02:55 status half-installed gir1.2-edataserverui-1.2:amd64
3.28.5-3
2018-10-05 22:02:55 status half-installed gir1.2-edataserverui-1.2:amd64
3.28.5-3
2018-10-05 22:02:55 status half-installed gir1.2-edataserver-1.2:amd64 3.28.5-3
2018-10-05 22:02:55 status half-installed gir1.2-edataserver-1.2:amd64 3.28.5-3
2018-10-05 22:02:56 status half-installed gir1.2-camel-1.2:amd64 3.28.5-3
2018-10-05 22:02:56 status half-installed gir1.2-camel-1.2:amd64 3.28.5-3
2018-10-05 22:02:56 status half-installed libebook-contacts-1.2-2:amd64
3.28.5-3
2018-10-05 22:02:56 

Bug#910311: elpy FTBFS randomly: test elpy-promise-wait-should-return-early-for-resolved-promise fails

[Nicholas D Steeves]

Update: I just tried packaging elpy-1.2.5 and
`elpy-promise-wait-should-return-early-for-resolved-promise` failed in
4/10 builds (failed on 1,3,6,9).  So something changed in sid between
the 4th of September and now.  On the upside, this means I will be
able to get a debug shell tomorrow and figure out what's going on :-D

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#909847: sbuild: fails early with “chown: invalid user: 'sbuild:sbuild'”

[Johannes Schauer]

Hi Ben,

Quoting Ben Finney (2018-10-06 03:39:12)
> On 29-Sep-2018, Ben Finney wrote:
> > Package: sbuild
> > $ getent passwd sbuild
> > sbuild:x:126:136:Debian source builder,,,:/var/lib/sbuild:/bin/bash
> > $ getent group sbuild
> > sbuild:x:136:bignose
> 
> Prompted by a suggestion to try running those commands *in* the
> chroot, I get this failure instead:
> 
> =
> $ sbuild-shell unstable
> E: Access not authorised
> I: You do not have permission to access the schroot service.
> I: This failure will be reported.
> Chroot setup failed
> Error setting up unstable chroot
> Chroot setup failed at /usr/bin/sbuild-shell line 42.
> 
> $ sudo sbuild-shell unstable
> chown: invalid user: 'sbuild:sbuild'
> E: Failed to set sbuild:sbuild ownership on /build
> Failed to set up chroot
> Error setting up unstable chroot
> Chroot setup failed at /usr/bin/sbuild-shell line 42.
> =
> 
> What should I be doing to correct this chroot?
> 
> How could the SBuild chroot be created so that it fails like this?
> What should I be doing when creating future chroots, to avoid this
> failure?

how did you create the chroot? Did you use sbuild-createchroot?

I'm not yet able to reproduce your problem and sbuild's autopkgtest also seems
to pass just fine: https://ci.debian.net/packages/s/sbuild/unstable/amd64/

Did you read the EXAMPLES section of the sbuild man page? Or the man page of
sbuild-createchroot?

Did you maybe try using sbuild-debian-developer-setup which is a script that
should setup your machine so that you can start building packages right away?

Also: why are you attempting to run sbuild with sudo?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#910360: debbugs: get_bug_log SOAP operation truncates message

[Don Armstrong]

Control: severity -1 wishlist
Control: retitle -1 provide all mime attachments in get_bug_log

On Fri, 05 Oct 2018, Michael Albinus wrote:
> This bug has been reported to the GNU debbugs server, see
> https://debbugs.gnu.org/32941>:
> 
> The get_bug_log operation of the SOAP API truncates some messages. For
> example, look at the 4th message (indexing from 0) in bug 25235. In
> the web interface,
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25235#17 , one can see
> that the message has 2 parts, but the get_bug_log SOAP operation only
> returns the first part.

That's right; it's currently only returning the body and header of the
mail messages, not the attachments. There probably should be an option
to return all of them, but this particular interface isn't really the
right way to do it.

-- 
Don Armstrong  https://www.donarmstrong.com

First you take a drink,
then the drink takes a drink,
then the drink takes you.
 -- F. Scott Fitzgerald

Bug#910311: elpy FTBFS randomly: test elpy-promise-wait-should-return-early-for-resolved-promise fails

[Nicholas D Steeves]

Control: forwarded -1 https://github.com/jorgenschaefer/elpy/issues/1477

Hi Helmut,

On Thu, Oct 04, 2018 at 07:34:31PM +0200, Helmut Grohne wrote:
> Source: elpy
> Version: 1.24.0-1
> Severity: serious
> Tags: ftbfs
> 
> elpy fails to build from source randomly. A build log contains:

I'm aware of this and opened an upstream issue a few days ago;
however, I haven't been able to reproduce it locally.  I've run more
than 15 autopkgtest runs in my amd64 schroot and another 15 in my LXC
one (not including runs to just build the package).  I also can't
trigger it with a plain dpkg-buildpackage.

> | Test elpy-promise-wait-should-return-early-for-resolved-promise backtrace:
> |   (if (unwind-protect (setq value-774 (apply fn-772 args-773)) (setq f
> |   (let (form-description-776) (if (unwind-protect (setq value-774 (app
> |   (let ((value-774 (quote ert-form-evaluation-aborted-775))) (let (for
> |   (let ((fn-772 (function elpy-promise-resolved-p)) (args-773 (list pr
> |   (let ((start-time (current-time)) (promise (elpy-promise nil))) (run
> |   (progn (let ((start-time (current-time)) (promise (elpy-promise nil)
> |   (progn (setq elpy-rpc-timeout 100) (progn (let ((start-time (current
> |   (unwind-protect (progn (setq elpy-rpc-timeout 100) (progn (let ((sta
> |   (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
> |   (let ((temp-buffer (generate-new-buffer " *temp*"))) (save-current-b
> |   (progn (let ((temp-buffer (generate-new-buffer " *temp*"))) (save-cu
> |   (unwind-protect (progn (let ((temp-buffer (generate-new-buffer " *te
> |   (let ((old-process-list (process-list)) (old-buffer-list (buffer-lis
> |   (lambda nil (let ((old-process-list (process-list)) (old-buffer-list
> |   ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
> |   ert-run-test([cl-struct-ert-test elpy-promise-wait-should-return-ear
> |   ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test e
> |   ert-run-tests(t #[385 "\306^B\307\"\203G^@\211\211G\310U\203^T^@\211@\20
> |   ert-run-tests-batch(nil)
> |   ert-run-tests-batch-and-exit()
> |   eval((ert-run-tests-batch-and-exit))
> |   command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
> |   command-line()
> |   normal-top-level()
> | Test elpy-promise-wait-should-return-early-for-resolved-promise condition:
> | (ert-test-failed
> |  ((should
> |(elpy-promise-resolved-p promise))
> |   :form
> |   (elpy-promise-resolved-p
> |[*elpy-promise* nil nil # nil])
> |   :value nil))
> |FAILED  222/362  
> elpy-promise-wait-should-return-early-for-resolved-promise
> 
> This happened in sbuild on unstable/amd64.
> 
> The reproducible builds folks encountered the same failure in one out of
> two builds using pbuilder:
> 
> https://tests.reproducible-builds.org/debian/logs/unstable/amd64/elpy_1.24.0-1.build2.log.gz
> https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/elpy_1.24.0-1.rbuild.log.gz
> https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/elpy_1.24.0-1.rbuild.log.gz
> 
> For amd64, only the second build failed.

Other than the build1 to build2 diff, where can I find a list of
everything that varies between the two runs?  At this time my best
guesses are a UTF-8 issue (possibly related to python-3.7), behaviour
that changed between python-3.6 and python-3.7, the mysterious cl vs
cl-lib issue that only affects packages built in an LXC (see below
[2]).  The only reason I suspect something UTF-8 related is there was
an Elpy bug involving the "ö" character sometime in the last year, and
I noticed that build2 has « guillemets ».

> When I tried it locally in
> sbuild, three builds succeeded. I have no clue how the failure is
> caused, but it is evident that it is not broken infrastructure.

I'm not interested in a blame shifting game, because it's not yet
evident where the issue is.  eg: 1) Various emacs tests in other
packages will[have] fail[ed] in pbuilder or in LXC autopkgtest but
always pass in schroot.  2) Autopkgtests began to fail for various
Emacs packages after unversioned emacs was released, but only in LXC,
and no one knows why.  I discovered this hack, which doesn't feel
right: Add "ert_eval = (require 'cl)" to debian/elpa-tests.  It
doesn't feel right because cl-lib should be used.  Of course, it's
also possible that these upstreams have a dynamic (works with cl fails
with cl-lib ) vs lexical scope bug.  That said, I'm doing everything I
can to figure this out ;-)

Because you're able to reproduce it, would you please get a debug
shell and run the ERT tests interactively to get an untruncated
backtrace?  I'd be happy to help out with this if necessary.  If it's
the [2] class of issues then it will only trigger in batch mode and
never in interactive.  That said, the [2] class of issues is usually
reliably triggered on any LXC build or autopkgtest run, but it would
be valuable to eliminate this failure case.

Worst-case scenario will be 

Bug#907268: fix lirc

[Kees Cook]

tag 907268 patch
thanks

The attached patch fixes LIRC for me...

-- 
Kees Cook@debian.org
diff -Nru xine-ui-0.99.9/debian/changelog xine-ui-0.99.9/debian/changelog
--- xine-ui-0.99.9/debian/changelog	2017-01-21 19:12:02.0 -0800
+++ xine-ui-0.99.9/debian/changelog	2018-10-05 19:16:19.0 -0700
@@ -1,3 +1,12 @@
+xine-ui (0.99.9-1.4) unstable; urgency=medium
+
+  * Fix LIRC detection (Closes: #907268):
+- debian/rules: add dh_autoreconf.
+- debian/control: Build-Depend on dh-autoreconf.
+- m4/_xine.m4: Update lirc pkg-config name.
+
+ -- Kees Cook   Fri, 05 Oct 2018 19:16:19 -0700
+
 xine-ui (0.99.9-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xine-ui-0.99.9/debian/control xine-ui-0.99.9/debian/control
--- xine-ui-0.99.9/debian/control	2017-01-21 18:50:14.0 -0800
+++ xine-ui-0.99.9/debian/control	2018-10-05 19:16:19.0 -0700
@@ -8,7 +8,7 @@
   libxt-dev, libxtst-dev, libxv-dev, libxxf86vm-dev, libaa1-dev,
   libgpm-dev [linux-any],
   liblircclient-dev, libcurl4-gnutls-dev, libfreetype6-dev,
-  libreadline-dev, libcaca-dev
+  libreadline-dev, libcaca-dev, dh-autoreconf
 Build-Conflicts: libcurl4-openssl-dev
 Standards-Version: 3.9.5
 Vcs-Hg: http://hg.debian.org/hg/xine-lib/pkg/xine-ui.deb
diff -Nru xine-ui-0.99.9/debian/patches/fix-lirc-pkg-config.patch xine-ui-0.99.9/debian/patches/fix-lirc-pkg-config.patch
--- xine-ui-0.99.9/debian/patches/fix-lirc-pkg-config.patch	1969-12-31 16:00:00.0 -0800
+++ xine-ui-0.99.9/debian/patches/fix-lirc-pkg-config.patch	2018-10-05 19:16:19.0 -0700
@@ -0,0 +1,14 @@
+Description: LIRC pkg-config name changed to "lirc".
+Author: Kees Cook 
+
+--- xine-ui-0.99.9.orig/m4/_xine.m4
 xine-ui-0.99.9/m4/_xine.m4
+@@ -31,7 +31,7 @@ AC_DEFUN([AC_CHECK_LIRC],
+   found_lirc=no
+   if test x"$enable_lirc" = xyes; then
+ have_lirc=yes
+-PKG_CHECK_MODULES(LIRC, liblircclient0, [found_lirc=yes], [:])
++PKG_CHECK_MODULES(LIRC, lirc, [found_lirc=yes], [:])
+ if test "$found_lirc" = yes; then
+   LIRC_INCLUDE="$LIRC_CFLAGS"
+ else
diff -Nru xine-ui-0.99.9/debian/patches/series xine-ui-0.99.9/debian/patches/series
--- xine-ui-0.99.9/debian/patches/series	1969-12-31 16:00:00.0 -0800
+++ xine-ui-0.99.9/debian/patches/series	2018-10-05 19:16:19.0 -0700
@@ -0,0 +1 @@
+fix-lirc-pkg-config.patch
diff -Nru xine-ui-0.99.9/debian/rules xine-ui-0.99.9/debian/rules
--- xine-ui-0.99.9/debian/rules	2017-01-21 19:04:30.0 -0800
+++ xine-ui-0.99.9/debian/rules	2018-10-05 19:16:19.0 -0700
@@ -11,6 +11,7 @@
 
 config.status:
 	dh_testdir
+	dh_autoreconf
 	sh ./configure \
 		--prefix=/usr --mandir=\$${prefix}/share/man \
 		--with-aalib --enable-vdr-keys \
@@ -35,6 +36,7 @@
 	dh_testdir
 	dh_testroot
 	[ ! -f Makefile ] || $(MAKE) distclean
+	dh_autoreconf_clean
 	dh_clean build-stamp debian/gxine.postinst \
 		po/*.gmo po/stamp-po \
 		misc/xine-bugreport misc/xine-check \

Bug#910408: xrandr fails to configure monitor without first switching to a VT

[Ryan Kavanagh]

Package: x11-xserver-utils
Version: 7.7+8
Severity: normal

I have two monitors (work and home) that connect to my laptop over
display port. At work, I am able to directly configure my external
monitor using the command

xrandr \
--output HDMI-2 --mode 1600x1200 --pos 0x0 --rotate left --primary \
--output HDMI-1 --off \
--output DP-1 --off \
--output eDP-1 --mode 1920x1080 --pos 1200x0 --rotate normal \
--output DP-2 --off

At home, when I try try to configure my external monitor using the
command

xrandr \
--output HDMI-2 --off \
--output HDMI-1 --off \
--output DP-1 --off \
--output eDP-1 --primary --mode 1920x1080 --pos 0x1080 --rotate normal \
--output DP-2 --mode 1920x1080 --pos 0x0 --rotate normal \
--verbose

I get the error message:

screen 0: 1920x2160 503x566 mm  96.93dpi
crtc 0:1920x1080  60.02 +0+1080 "eDP-1"
crtc 1:1920x1080  60.00 +0+0 "DP-2"
xrandr: Configure crtc 1 failed
crtc 0: disable
crtc 1: disable
crtc 2: disable
screen 0: revert
crtc 0: revert
crtc 1: revert
crtc 2: revert

If I then switch to a vt, e.g., using "chvt 1", and switch back to
X, I can successfully configure the external monitor using the same
command, getting the output:

screen 0: 1920x2160 503x566 mm  96.93dpi
crtc 0:1920x1080  60.02 +0+1080 "eDP-1"
crtc 1:1920x1080  60.00 +0+0 "DP-2"

In the output of dmesg, I see the following drm error but nothing else
that is relevant.

[3132600.105286] [drm] Reducing the compressed framebuffer size.
This may lead to less power savings than a non-reduced-size. Try to
increase stolen memory size if available in BIOS.

I was going to report this against xserver-xorg before x11-xserver-utils
was the correct package. I've left the xserver-xorg information below,
just in case it is useful.

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 
[8086:1616] (rev 09)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 65 Jul 30  2017 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
Section "ServerFlags"
Option "DontVTSwitch" "off"
EndSection

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.17.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-28)) #1 SMP Debian 4.17.17-1 (2018-08-18)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 100605 Oct  5 21:41 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[2544317.647] 
X.Org X Server 1.20.1
X Protocol Version 11, Revision 0
[2544317.647] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[2544317.647] Current Operating System: Linux zeta 4.17.0-3-amd64 #1 SMP Debian 
4.17.17-1 (2018-08-18) x86_64
[2544317.647] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.17.0-3-amd64 
root=UUID=530001cc-dd95-43e4-9445-46a4e20767a8 ro quiet
[2544317.647] Build Date: 20 September 2018  08:26:11AM
[2544317.647] xorg-server 2:1.20.1-3 (https://www.debian.org/support) 
[2544317.647] Current version of pixman: 0.34.0
[2544317.647]   Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[2544317.647] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[2544317.647] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 27 13:02:21 
2018
[2544317.648] (==) Using config file: "/etc/X11/xorg.conf"
[2544317.648] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[2544317.650] (==) No Layout section.  Using the first Screen section.
[2544317.650] (==) No screen section available. Using defaults.
[2544317.650] (**) |-->Screen "Default Screen Section" (0)
[2544317.650] (**) |   |-->Monitor ""
[2544317.651] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[2544317.651] (**) Option "DontVTSwitch" "off"
[2544317.651] (==) Automatically adding devices
[2544317.651] (==) Automatically enabling devices
[2544317.651] (==) Automatically adding GPU devices
[2544317.651] (==) Max clients allowed: 256, resource mask: 0x1f
[2544317.651] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[2544317.651]   Entry deleted from font path.
[2544317.651] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.

Bug#862649: Dead upstream

[Chris Knadle]

I was investigating this orphaned package in relation to it being a dependency
for Logcheck, and unfortunately the inactive maintainer is also the upstream
author of mime-construct which was last updated 2010-06-23.  That can be seen at
the following link:

   http://www.argon.org/~roderick/

mime-construct appears to be a one-file Perl script (about 920 lines total
including documentation), license is GPLv2+.  Making note of this to the bug
report to help others looking to evaluate the package.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us



signature.asc
Description: OpenPGP digital signature

Bug#910407: openjfx: Need for openjfx for both OpenJDK8 and OpenJDK11

[Norbert Preining]

Package: openjfx
Version: 11+26-1
Severity: normal

Hi dear Java packagers,

thanks a lot for your hard work with these difficult packages.

I recently found that sid now carries openjfx in version 11, which made
the programs I am developing with ScalaFX stop working. ScalaFX uses
JavaFX8 and there are no builds available for OpenJDK/JavaFX11 by now.

I think in the same way as with jdk/jre itself, it would be useful to
have openjfx-8 and openjfx-11 available.

Thanks

Norbert

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

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

Versions of packages openjfx depends on:
ii  libopenjfx-java  11+26-1

Versions of packages openjfx recommends:
ii  openjfx-source  11+26-1

openjfx suggests no packages.

-- no debconf information

Bug#909847: sbuild: fails early with “chown: invalid user: 'sbuild:sbuild'”

[Ben Finney]

On 29-Sep-2018, Ben Finney wrote:
> Package: sbuild
> $ getent passwd sbuild
> sbuild:x:126:136:Debian source builder,,,:/var/lib/sbuild:/bin/bash
> $ getent group sbuild
> sbuild:x:136:bignose

Prompted by a suggestion to try running those commands *in* the
chroot, I get this failure instead:

=
$ sbuild-shell unstable
E: Access not authorised
I: You do not have permission to access the schroot service.
I: This failure will be reported.
Chroot setup failed
Error setting up unstable chroot
Chroot setup failed at /usr/bin/sbuild-shell line 42.

$ sudo sbuild-shell unstable
chown: invalid user: 'sbuild:sbuild'
E: Failed to set sbuild:sbuild ownership on /build
Failed to set up chroot
Error setting up unstable chroot
Chroot setup failed at /usr/bin/sbuild-shell line 42.
=

What should I be doing to correct this chroot?

How could the SBuild chroot be created so that it fails like this?
What should I be doing when creating future chroots, to avoid this
failure?

-- 
 \  “If I ever get real rich, I hope I'm not real mean to poor |
  `\  people, like I am now.” —Jack Handey |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#910406: ssh-add: ignores IdentityAgent configuration value

[Paul Wise]

Package: openssh-client
Version: 1:7.8p1-1
Severity: normal
File: /usr/bin/ssh-add

ssh-add appears to ignore the IdentityAgent configuration value and
only uses the SSH_AUTH_SOCK environment variable to determine which
agent to use. I wanted to make ssh-add use the GnuPG SSH agent.

$ ssh-add
Could not open a connection to your authentication agent.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.19.0.5+b1
ii  libc6 2.27-6
ii  libedit2  3.1-20180525-1
ii  libgssapi-krb5-2  1.16.1-1
ii  libselinux1   2.8-1+b1
ii  libssl1.0.2   1.0.2o-1
ii  passwd1:4.5-1.1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain 
pn  libpam-ssh   
ii  monkeysphere 0.41-1
ii  ssh-askpass-gnome [ssh-askpass]  1:7.8p1-1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#910404: gcr: please add gcr-ssh-askpass to the alternatives system for ssh-askpass

[Paul Wise]

Package: gcr
Version: 3.28.0-1
Severity: wishlist
File: /usr/lib/gcr/gcr-ssh-askpass

Please add gcr-ssh-askpass to the alternatives system for ssh-askpass
so that GNOME 3 users can use an SSH askpass implementation that integrates 
with GNOME better than the alternative implementations.

I suggest putting it at a high priority so that it is selected by
default on systems that include the GNOME desktop.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gcr depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.0-1
ii  libc6 2.27-6
ii  libgcr-base-3-1   3.28.0-1
ii  libgcr-ui-3-1 3.28.0-1
ii  libglib2.0-0  2.58.1-2
ii  libgtk-3-03.24.1-2

gcr recommends no packages.

gcr suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#910405: nheko: empty device name causes issue in e2ee chat room

[ghost]

Package: nheko
Version: 0.6.1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   If the device name is empty in the login process (which does not
   warn anything when the field is left as is), the nheko session will
   not show up in other clients (riot.im in my case). Messages sent to
   chat rooms with e2ee enabled either don't get encrypted for existing
   rooms, or get encrypted but appear as unknown in other clients for
   rooms created by the nheko session.

   Since the device name is needed for the session to be recognised by
   other clients, I would expect it either -
  a. be a required field in the login process.
  b. has a default value to be used when not specified.

   I believe this will need to be forwarded upstream, but since Debian
   discourages directly filing bugs to upstream, here I am...

Cheers.

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

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

Versions of packages nheko depends on:
ii  libboost-atomic1.67.0 1.67.0-7
ii  libboost-chrono1.67.0 1.67.0-7
ii  libboost-date-time1.67.0  1.67.0-7
ii  libboost-iostreams1.67.0  1.67.0-7
ii  libboost-random1.67.0 1.67.0-7
ii  libboost-regex1.67.0  1.67.0-7
ii  libboost-system1.67.0 1.67.0-7
ii  libboost-thread1.67.0 1.67.0-7
ii  libc6 2.27-6
ii  libcmark0 0.28.3-1
ii  libgcc1   1:8.2.0-7
ii  liblmdb0  0.9.22-1
ii  libolm2   2.2.2+git20170526.0fd768e+dfsg-1
ii  libqt5concurrent5 5.11.1+dfsg-9
ii  libqt5core5a  5.11.1+dfsg-9
ii  libqt5dbus5   5.11.1+dfsg-9
ii  libqt5gui55.11.1+dfsg-9
ii  libqt5multimedia5 5.11.1-2
ii  libqt5network55.11.1+dfsg-9
ii  libqt5svg55.11.1-2
ii  libqt5widgets55.11.1+dfsg-9
ii  libsodium23   1.0.16-2
ii  libssl1.1 1.1.0h-4
ii  libstdc++68.2.0-7
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages nheko recommends:
ii  ca-certificates  20170717

nheko suggests no packages.

-- no debconf information

Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload

[Daniel Kahn Gillmor]

On Tue 2018-10-02 14:31:13 -0500, Daniel Kahn Gillmor wrote:
> I'm now working on figuring out what updates are needed to GnuPG in
> debian stable (stretch) to be able to get the enigmail test suite to
> pass.  Hopefully they'll be minor, and comprehensible.

Turns out there were a half-dozen upstream GnuPG changes that needed
backporting to stretch to make the enigmail test suite pass.

Additionally, the Enigmail test suite itself needs a bit of cleanup to
deal sensibly with the older version of GnuPG (in particular, rapidly
setting up and tearing down ephemeral GnuPG homedirs during the test
suite causes problems for the older version of gpg-agent, reported
upstream as https://gitlab.com/enigmail/enigmail/merge_requests/30)

I've requested for the release team to consider the changes for GnuPG in
stretch here:

  https://bugs.debian.org/910398

If the security team (or other people interested in enigmail) want to
follow up on that report, i'd appreciate it.

In the meantime, for enigmail, i've pushed a debian/stretch branch into
salsa with commit id b6e978d64af1defdfed876b09c8a57acb796ad72 as
2:2.0.8-5~deb9u1, which i've tested against the proposed gnupg2
2.1.18-8~deb9u3.

I welcome review of both of the GnuPG and Enigmail branches.

  --dkg


signature.asc
Description: PGP signature

Bug#910403: x2goserver: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: x2goserver
Version: 4.1.0.2-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for x2goserver's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


x2goserver_4.1.0.2-2_pt.po.gz
Description: application/gzip

Bug#910110: aptitude: aptitude does not update libxapian30 during aptitude "self upgrade"

[Olly Betts]

On Fri, Oct 05, 2018 at 10:12:15PM +0100, Olly Betts wrote:
> On Fri, Oct 05, 2018 at 06:46:52PM +0200, Sven Joachim wrote:
> > Instead of shlibs.local, you probably want to generate
> > libxapian30.shlibs - see dh_makeshlibs(1).
> 
> Hmm, I thought I'd confirmed this was working, but I guess I checked
> xapian-tools which the shlibs.local would work with.
> 
> Thanks for catching.  I'll upload -4 later today.

Done.  To confirm the fix this time, I installed the new libxapian30
package and checked:

/var/lib/dpkg/info/libxapian30:amd64.shlibs

This now has:

libxapian 30 libxapian30 (>= 1.4.6~)

Cheers,
Olly

Bug#910344: libgssapi-krb5-2: conffiles not removed

[Paul Wise]

On Fri, 2018-10-05 at 19:28 -0500, Benjamin Kaduk wrote:

> How is this not a dup of #868121 (with additional discussion linked
> therefrom)?

Apologies, I forgot about that bug and since it was closed I did not
see any reason to submit the bug. I suggest keeping this one open and
marking it wontfix so that myself and others do not file it again.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#910402: Fails to determine partition uuid if /boot/efi is automounted

[Michael Biebl]

Package: refind
Version: 0.11.2-1.1
Severity: important

Hi,

to minimize the risk of /boot/efi getting corrupted (being FAT32 and
all), I use the following fstab entry:
UUID=ABCD-1234  /boot/efi   vfat
umask=0077,x-systemd.automount,x-systemd.idle-timeout=60  0   1

This ensures, /boot/efi is automounted (by systemd) whenever accessed
and unmounted after 60s idle timeout.
findmnt output looks like this:

# findmnt /boot/efi
TARGETSOURCEFSTYPE OPTIONS
/boot/efi systemd-1 autofs 
rw,relatime,fd=31,pgrp=1,timeout=60,minproto=5,maxproto=5,direct,pipe_ino=12788
/boot/efi /dev/sda2 vfat   
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro


When running refind-install, the generated efi boot entry is incorrect:

# efibootmgr -v | grep refind
Boot001C* rEFInd Boot Manager   
HD(12,GPT,----,0x0,0x1)/File(\EFI\refind\refind_x64.efi)

Notice how the GPT UUID is all set to '0'.

When mounting /boot/efi directly, the partition uuid is correctly set.

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

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

Versions of packages refind depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  efibootmgr 15-1
ii  openssl1.1.1-1
ii  parted 3.2-21+b1

Versions of packages refind recommends:
ii  python3 3.6.6-1
ii  sbsigntool  0.6-3.2

refind suggests no packages.


-- debconf information:
* refind/install_to_esp: true

Bug#881395: gedit-plugin-dashboard: traceback when opening new tabs: AttributeError: 'Image' object has no attribute 'get_children'

[Jeremy Bicha]

On Sat, Nov 11, 2017 at 4:45 AM Paul Wise  wrote:
> Package: gedit-plugin-dashboard
> Version: 3.22.0-3
> Severity: serious
> File: /usr/lib/x86_64-linux-gnu/gedit/plugins/dashboard/__init__.py
> Usertags: crash
>
> When I open a new tab in gedit, I get this traceback on the terminal
> where I ran gedit. Filing at serious because I guess this means the
> plugin package is broken, please downgrade the severity if the
> traceback is not problematic.

I "fixed" this bug by dropping the gedit-plugin-dashboard package in 3.30.1-2.

How do you want to handle this bug now?

Thanks,
Jeremy Bicha

Bug#910344: libgssapi-krb5-2: conffiles not removed

[Benjamin Kaduk]

On Fri, Oct 05, 2018 at 08:01:04AM +0800, Paul Wise wrote:
> 
> The recent upgrade did not deal with obsolete conffiles properly.
> Please use the dpkg-maintscript-helper support provided by
> dh_installdeb to remove these obsolete conffiles on upgrade.
> 
> https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
> https://manpages.debian.org/man/1/dh_installdeb
> 
> This bug report brought to you by adequate:
> 
> http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
> 
> $ pkg=libgssapi-krb5-2 ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' 
> $pkg | grep obsolete
> libgssapi-krb5-2:amd64: obsolete-conffile /etc/gss/mech.d/README
>  /etc/gss/mech.d/README 27e753ba1dc72900d2892b8efef6e35e obsolete

How is this not a dup of #868121 (with additional discussion linked
therefrom)?

-Ben

Bug#910401: ranger: [Request] Compile Ranger with python3

[Austin LaBerta]

Package: ranger
Version: 1.8.1-0.2
Severity: wishlist
Tags: upstream

Dear Maintainer,

   * What led up to the situation? I had checked the version and had noted you
had compiled the application using python2.
   * What outcome did you expect instead? Programs that do not require python2
explicitly should be compiled with python3, as python 2 is being depreciated in
2020. Regardless of if they provide an extension or not, it should be expected
that we do not encourage them to continue endlessly extending support for
python2.

I had noticed that someone else had requested that you update the version as
the current version of ranger is 9 versions behind. Please compile the next
version in python 3 instead.



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

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

Versions of packages ranger depends on:
ii  less487-0.1+b1
ii  python  2.7.15-3

Versions of packages ranger recommends:
ii  file1:5.34-2
ii  python-chardet  3.0.4-1
ii  w3m-img 0.5.3-36+b1

Versions of packages ranger suggests:
pn  atool  
pn  caca-utils 
pn  highlight  
ii  poppler-utils  0.63.0-2
ii  sudo   1.8.23-2
ii  w3m0.5.3-36+b1

-- no debconf information

Bug#910326: parted: include sys/sysmacros.h missing for major(), minor()

[Colin Watson]

On Thu, Oct 04, 2018 at 03:47:25PM -0400, Mathieu Trudel-Lapierre wrote:
> parted 3.2-21 FTBFS in latest test rebuild on ubuntu. major() and minor()
> macros are being used without include sys/sysmacros.h, leading to undefined
> symbols at linking for these macros.
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * debian/patches/sysmacros_for_major_minor.patch: include sys/sysmacros.h to
> account for the user of major() and minor() macros.

Thanks.  I took the similar upstream cherry-pick instead
(https://git.savannah.gnu.org/cgit/parted.git/commit/?id=ba5e0451b51c983e40afd123b6e0d3eddb55e610),
since that'll be slightly more convenient at the next upstream release
(git will automatically drop it rather than me having to resolve a
conflict).  It'll be in my next upload.

-- 
Colin Watson   [cjwat...@ubuntu.com]

Bug#910400: mysqli stopped connecting to MySQL servers using caching_sha2_password

[Piotr Jurkiewicz]

Package: php7.3-mysql
Version: 7.3.0~rc2-2
Severity: grave

After update to 7.3.0~rc2-2 (sid), mysqli extension stopped working. It 
can't connect to MySQL server, giving the following error message:


PHP message: PHP Warning:  mysqli::__construct(): The server requested 
authentication method unknown to the client [caching_sha2_password]


It worked before the update (version 7.3.0~alpha3-1, I think).

caching_sha2_password is the default authentication method in MySQL 8.0.

Bug#910399: minissdpd: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: minissdpd
Version: 1.5.20180223-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for minissdpd's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


minissdpd_1.5.20180223-3_pt.po.gz
Description: application/gzip

Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3

[Daniel Kahn Gillmor]

Package: release.debian.org
User: release.debian@packages.debian.org
X-Debbugs-Cc: pkg-gnupg-ma...@lists.alioth.debian.org, secur...@debian.org
Usertags: pu
Tags: stretch
Severity: normal
Control: affects -1 src:gnupg2 enigmail
Control: block 909000 -1

I'd like to update the version of GnuPG in debian stable with a series
of targeted bugfixes (most of which are backported from upstream).

There are four complementary reasons, which i explain in more detail
below:

 * ptrace hardening for scdaemon
 * bugfixes that target some common workflows
 * updating cryptographic defaults
 * fixing enigmail in stretch

All of the patches that implement these changes have been in buster
for many months (either as upstream improvements or debian-specific
improvements).


Debian logistics


I note that this is *not* itself a security fix -- these fixes do not
address a specific vulnerability in stretch's version of GnuPG.
However, they do have security implications for stretch, because they
are needed in order to support enigmail since the thunderbird 60
upgrade.

If the release team or the security team (x-debbug-cc'ed here) would
prefer that we handle this via stretch-security instead of
stretch-proposed-updates, that's fine with me: please let me know.

I've attached a debdiff below, and the git history of these changes is
also available on the debian/stretch git branch on
https://salsa.debian.org/debian/gnupg2 (commit
f74eb5b2898ced14f910a7e4c7a28cc295dbd3cb)

The debdiff contains some minor updates to patch metadata that makes it
easier to work with git-buildpackage going forward.  I apologize for
this extra noise, but syncing up with gbp like this should make
maintenance of any future changes easier.


Justification for changes
=

scdaemon hardening
--

scdaemon currently can hold sensitive data, comparable to the data
held by gpg-agent.  gpg-agent currently blocks ptrace access to its
internal RAM.  scdaemon now also blocks ptrace. (see: #878952)

common workflow bugfixes


 * Dirmngr currently fails on IPv6-only systems.  Enable dirmngr to
   query nameservers over IPv6. (see: #862282)

 * Malformed keys are currently rejected rather than being cleaned up.
   (some keys are malformed on the public keyservers). Clean keys
   before importing.  (see: #906545)

update cryptographic defaults
-

A user of debian stable who creates a key today will have a default
expiration date of two years, well into 2020.  Currently in stretch,
the default asymmetric key is 2048-bit RSA.

None of the reasonable guides to cryptographic strength think that
2048-bit RSA keys should be used past 2020. (see for example ECRYPT or
NIST recommendations).

Furthermore, AES128 today is considered slightly riskier than AES256,
due in part to batch attacks and its smaller margin of safety against
quantum cryptanalysis (see for example, the Modern TLS recommendations
at https://wiki.mozilla.org/Security/Server_Side_TLS, and djb's
http://blog.cr.yp.to/20151120-batchattacks.html).

Update the cryptographic defaults to create 3072-bit RSA keys, and to
prefer AES256 over AES128 when all recipients support it.

fixing Enigmail
---

As Thunderbird 60 is now in stretch, enigmail is broken (see
https://bugs.debian.org/909000) :/

This can be fixed by importing the current (buster/stretch) enigmail
into stretch as well, but this updated version of enigmail depends on
bugfixes in GnuPG that are not yet in debian stretch.

Backport a series of minor bugfixes and small functionality
improvements to enable enigmail's test suite to pass cleanly.  From
debian/changelog, those are:

  * backport --no-symkey-cache
  * backport improved import and export filtering
  * backport display of revocation certificates
  * backport stripping unusable subkey material during export-minimal
  * backport fix to make --dry-run work when listing secret keys
  * backport fix showing secret keys when listing keys


Testing
===

I've tested these changes on an x86_64 system running debian stretch.
The GnuPG test suite all passes, and an updated/backported version of
enigmail 2.0.8-5 also works on that platform.

I welcome any feedback on this!  sorry it has taken so long to produce
this series of changes.

Regards,

--dkg



gnupg2_2.1.18-8~deb9u2_2.1.18-8~deb9u3.debdiff.gz
Description: debdiff for proposed fixes for GnuPG for debian stretch

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

Kernel: Linux 4.18.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 

Bug#887485: libgd2: diff for NMU version 2.2.5-4.1

[Salvatore Bonaccorso]

Control: tags 887485 + patch
Control: tags 887485 + pending
Control: tags 906840 + pending
Control: tags 906886 + pending


Dear maintainer,

I've prepared an NMU for libgd2 (versioned as 2.2.5-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

I'm aware though that this upload will not allow the fixes go to
testing, as there are two more RC bugs (#899928, needing decision for
maintainer address, and a second one #883760).

The main purpose for this still incomplete NMU is to allow #910396
("stretch-pu: package libgd2/2.2.4-2+deb9u3") to be possible to be
included for 9.6.

Regards,
Salvatore
diff -Nru libgd2-2.2.5/debian/changelog libgd2-2.2.5/debian/changelog
--- libgd2-2.2.5/debian/changelog	2017-10-22 11:14:32.0 +0200
+++ libgd2-2.2.5/debian/changelog	2018-10-06 00:22:59.0 +0200
@@ -1,3 +1,17 @@
+libgd2 (2.2.5-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Potential infinite loop in gdImageCreateFromGifCtx (CVE-2018-5711)
+(Closes: #887485)
+  * bmp: check return value in gdImageBmpPtr (CVE-2018-1000222)
+(Closes: #906886)
+  * Remove src/Makefile.am patching in
+tests-make-a-little-change-for-autopkgtest.patch.  Fixes "libgd2 FTBFS:
+cannot find -lgd".
+Thanks to Helmut Grohne and Adrian Bunk (Closes: #906840)
+
+ -- Salvatore Bonaccorso   Sat, 06 Oct 2018 00:22:59 +0200
+
 libgd2 (2.2.5-4) unstable; urgency=medium
 
   [ Ji Pale??ek ]
diff -Nru libgd2-2.2.5/debian/patches/Fix-420-Potential-infinite-loop-in-gdImageCreateFrom.patch libgd2-2.2.5/debian/patches/Fix-420-Potential-infinite-loop-in-gdImageCreateFrom.patch
--- libgd2-2.2.5/debian/patches/Fix-420-Potential-infinite-loop-in-gdImageCreateFrom.patch	1970-01-01 01:00:00.0 +0100
+++ libgd2-2.2.5/debian/patches/Fix-420-Potential-infinite-loop-in-gdImageCreateFrom.patch	2018-10-06 00:22:59.0 +0200
@@ -0,0 +1,53 @@
+From: "Christoph M. Becker" 
+Date: Wed, 29 Nov 2017 19:37:38 +0100
+Subject: Fix #420: Potential infinite loop in gdImageCreateFromGifCtx
+origin: https://github.com/libgd/libgd/commit/a11f47475e6443b7f32d21f2271f28f417e2ac04
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-5711
+Bug-Debian: https://bugs.debian.org/887485
+Bug: https://github.com/libgd/libgd/issues/420
+
+Due to a signedness confusion in `GetCode_` a corrupt GIF file can
+trigger an infinite loop.  Furthermore we make sure that a GIF without
+any palette entries is treated as invalid *after* open palette entries
+have been removed.
+
+CVE-2018-5711
+
+See also https://bugs.php.net/bug.php?id=75571.
+---
+
+--- a/src/gd_gif_in.c
 b/src/gd_gif_in.c
+@@ -335,11 +335,6 @@ terminated:
+ 		return 0;
+ 	}
+ 
+-	if(!im->colorsTotal) {
+-		gdImageDestroy(im);
+-		return 0;
+-	}
+-
+ 	/* Check for open colors at the end, so
+ 	 * we can reduce colorsTotal and ultimately
+ 	 * BitsPerPixel */
+@@ -351,6 +346,11 @@ terminated:
+ 		}
+ 	}
+ 
++	if(!im->colorsTotal) {
++		gdImageDestroy(im);
++		return 0;
++	}
++
+ 	return im;
+ }
+ 
+@@ -447,7 +447,7 @@ static int
+ GetCode_(gdIOCtx *fd, CODE_STATIC_DATA *scd, int code_size, int flag, int *ZeroDataBlockP)
+ {
+ 	int i, j, ret;
+-	unsigned char count;
++	int count;
+ 
+ 	if(flag) {
+ 		scd->curbit = 0;
diff -Nru libgd2-2.2.5/debian/patches/bmp-check-return-value-in-gdImageBmpPtr.patch libgd2-2.2.5/debian/patches/bmp-check-return-value-in-gdImageBmpPtr.patch
--- libgd2-2.2.5/debian/patches/bmp-check-return-value-in-gdImageBmpPtr.patch	1970-01-01 01:00:00.0 +0100
+++ libgd2-2.2.5/debian/patches/bmp-check-return-value-in-gdImageBmpPtr.patch	2018-10-06 00:22:59.0 +0200
@@ -0,0 +1,79 @@
+From: Mike Frysinger 
+Date: Sat, 14 Jul 2018 13:54:08 -0400
+Subject: bmp: check return value in gdImageBmpPtr
+Origin: https://github.com/libgd/libgd/commit/ac16bdf2d41724b5a65255d4c28fb0ec46bc42f5
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-1000222
+Bug-Debian: https://bugs.debian.org/906886
+Bug: https://github.com/libgd/libgd/issues/447
+
+Closes #447.
+---
+ src/gd_bmp.c | 17 ++---
+ 1 file changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/src/gd_bmp.c b/src/gd_bmp.c
+index bde0b9d3abbd..78f40d9a475e 100644
+--- a/src/gd_bmp.c
 b/src/gd_bmp.c
+@@ -47,6 +47,8 @@ static int bmp_read_4bit(gdImagePtr im, gdIOCtxPtr infile, bmp_info_t *info, bmp
+ static int bmp_read_8bit(gdImagePtr im, gdIOCtxPtr infile, bmp_info_t *info, bmp_hdr_t *header);
+ static int bmp_read_rle(gdImagePtr im, gdIOCtxPtr infile, bmp_info_t *info);
+ 
++static int _gdImageBmpCtx(gdImagePtr im, gdIOCtxPtr out, int compression);
++
+ #define BMP_DEBUG(s)
+ 
+ static int gdBMPPutWord(gdIOCtx *out, int w)
+@@ -87,8 +89,10 @@ BGD_DECLARE(void *) gdImageBmpPtr(gdImagePtr im, int *size, int compression)
+ 	void *rv;
+ 	gdIOCtx *out = gdNewDynamicCtx(2048, NULL);
+ 	if (out == NULL) return NULL;
+-	gdImageBmpCtx(im, out, compression);
+-	rv = gdDPExtractData(out, size);
++	if 

Bug#910397: Tab crashes while connecting webrtc video conferencing

[Paul van der Vlis]

Package: firefox-esr
Version: 60.2.2esr-1~deb9u1

When I connect with webrtc microphone and webcam the Firefox tab crashes
when the second person connects. Both sides are crashing. This is since
version 60, before no problem. Also no problem with Chromium.

Easy to test without account with e.g.:
https://linkello.com
https://meet.jit.si

With regards,
Paul van der Vlis


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Bug#874849: O: cortina -- Wallpaper changer for gnome

[Jeremy Bicha]

Control: severity 874849 serious

> First of all, thanks for your work in Debian and previous package maintenance
> for cortina in Debian. Given the fact that upstream is really dead, Qt4
> Removal is slowly approaching and that alternatives (some gnome shell
> extensions do float around) exist to offer similar functionalities, I believe
> that we should try to remove this package from Debian archive before Buster
> release.
>
> I will submit an RM bug within two weeks, if no one objects.

Boyuan, could you file that removal bug now?

My specific interest is that we are planning to remove gjs and
gnome-shell from s390x and this is one of the reverse dependencies.

Thanks,
Jeremy Bicha

Bug#910110: aptitude: aptitude does not update libxapian30 during aptitude "self upgrade"

[Olly Betts]

On Fri, Oct 05, 2018 at 06:46:52PM +0200, Sven Joachim wrote:
> Instead of shlibs.local, you probably want to generate
> libxapian30.shlibs - see dh_makeshlibs(1).

Hmm, I thought I'd confirmed this was working, but I guess I checked
xapian-tools which the shlibs.local would work with.

Thanks for catching.  I'll upload -4 later today.

> The rebuilds should be scheduled with a dep-wait for libxapian-dev (>=
> 1.4.7-4) if that version indeed fixes the bug (see
> https://release.debian.org/wanna-build.html).

Yes, I know.

It seemed prudent to wait to see it was building OK and give a chance to
catch brown paper bag issues (like the one you spotted) rather than just
lean on dep-wait.  If I'd already filed a binnmu request with a suitable
dep-wait we'd have already pointlessly rebuilt a load of reverse deps.

Cheers,
Olly

Bug#902260: fixed in modemmanager 1.8.2-1

[Michael Biebl]

On Fri, 05 Oct 2018 16:19:21 + Mathieu Trudel-Lapierre
 wrote:

>  modemmanager (1.8.2-1) unstable; urgency=medium
>  .
>* New upstream version 1.8.2. (Closes: #910013) (Closes: #900907)
>* debian/modemmanager.postrm: don't unmask ModemManager on postrm; we were
>  unmasking because we're about to remove ModemManager anyway, and prerm 
> did
>  its mask with --runtime which is supposed to not be persistent.
>  (Closes: #902260)

If now a user uninstalls modemmanager and decides to re-install it, the
service will be (runtime) masked until the system is rebooted.

-- 
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#910396: stretch-pu: package libgd2/2.2.4-2+deb9u3

[Moritz Muehlenhoff]

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

Two minor security issues fixed in libgd2, not worth a DSA. Debdiff below.

Cheers,
Moritz

diff -Nru libgd2-2.2.4/debian/changelog libgd2-2.2.4/debian/changelog
--- libgd2-2.2.4/debian/changelog   2017-08-31 14:45:16.0 +0200
+++ libgd2-2.2.4/debian/changelog   2018-09-07 17:30:40.0 +0200
@@ -1,3 +1,10 @@
+libgd2 (2.2.4-2+deb9u3) stretch; urgency=medium
+
+  * CVE-2018-1000222 (Closes: #906886)
+  * CVE-2018-5711 (Closes: #887485)
+
+ -- Moritz Mühlenhoff   Fri, 07 Sep 2018 19:29:19 +0200
+
 libgd2 (2.2.4-2+deb9u2) stretch-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru libgd2-2.2.4/debian/patches/0008-CVE-2018-1000222.patch 
libgd2-2.2.4/debian/patches/0008-CVE-2018-1000222.patch
--- libgd2-2.2.4/debian/patches/0008-CVE-2018-1000222.patch 1970-01-01 
01:00:00.0 +0100
+++ libgd2-2.2.4/debian/patches/0008-CVE-2018-1000222.patch 2018-09-07 
17:28:33.0 +0200
@@ -0,0 +1,73 @@
+From ac16bdf2d41724b5a65255d4c28fb0ec46bc42f5 Mon Sep 17 00:00:00 2001
+From: Mike Frysinger 
+Date: Sat, 14 Jul 2018 13:54:08 -0400
+Subject: [PATCH] bmp: check return value in gdImageBmpPtr
+
+Closes #447.
+---
+ src/gd_bmp.c | 17 ++---
+ 1 file changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/src/gd_bmp.c b/src/gd_bmp.c
+index bde0b9d3..78f40d9a 100644
+--- a/src/gd_bmp.c
 b/src/gd_bmp.c
+@@ -47,6 +47,8 @@ static int bmp_read_4bit(gdImagePtr im, gdIOCtxPtr infile, 
bmp_info_t *info, bmp
+ static int bmp_read_8bit(gdImagePtr im, gdIOCtxPtr infile, bmp_info_t *info, 
bmp_hdr_t *header);
+ static int bmp_read_rle(gdImagePtr im, gdIOCtxPtr infile, bmp_info_t *info);
+ 
++static int _gdImageBmpCtx(gdImagePtr im, gdIOCtxPtr out, int compression);
++
+ #define BMP_DEBUG(s)
+ 
+ static int gdBMPPutWord(gdIOCtx *out, int w)
+@@ -87,8 +89,10 @@ BGD_DECLARE(void *) gdImageBmpPtr(gdImagePtr im, int *size, 
int compression)
+   void *rv;
+   gdIOCtx *out = gdNewDynamicCtx(2048, NULL);
+   if (out == NULL) return NULL;
+-  gdImageBmpCtx(im, out, compression);
+-  rv = gdDPExtractData(out, size);
++  if (!_gdImageBmpCtx(im, out, compression))
++  rv = gdDPExtractData(out, size);
++  else
++  rv = NULL;
+   out->gd_free(out);
+   return rv;
+ }
+@@ -141,6 +145,11 @@ BGD_DECLARE(void) gdImageBmp(gdImagePtr im, FILE 
*outFile, int compression)
+   compression - whether to apply RLE or not.
+ */
+ BGD_DECLARE(void) gdImageBmpCtx(gdImagePtr im, gdIOCtxPtr out, int 
compression)
++{
++  _gdImageBmpCtx(im, out, compression);
++}
++
++static int _gdImageBmpCtx(gdImagePtr im, gdIOCtxPtr out, int compression)
+ {
+   int bitmap_size = 0, info_size, total_size, padding;
+   int i, row, xpos, pixel;
+@@ -148,6 +157,7 @@ BGD_DECLARE(void) gdImageBmpCtx(gdImagePtr im, gdIOCtxPtr 
out, int compression)
+   unsigned char *uncompressed_row = NULL, *uncompressed_row_start = NULL;
+   FILE *tmpfile_for_compression = NULL;
+   gdIOCtxPtr out_original = NULL;
++  int ret = 1;
+ 
+   /* No compression if its true colour or we don't support seek */
+   if (im->trueColor) {
+@@ -325,6 +335,7 @@ BGD_DECLARE(void) gdImageBmpCtx(gdImagePtr im, gdIOCtxPtr 
out, int compression)
+   out_original = NULL;
+   }
+ 
++  ret = 0;
+ cleanup:
+   if (tmpfile_for_compression) {
+ #ifdef _WIN32
+@@ -338,7 +349,7 @@ BGD_DECLARE(void) gdImageBmpCtx(gdImagePtr im, gdIOCtxPtr 
out, int compression)
+   if (out_original) {
+   out_original->gd_free(out_original);
+   }
+-  return;
++  return ret;
+ }
+ 
+ static int compress_row(unsigned char *row, int length)
diff -Nru libgd2-2.2.4/debian/patches/0009-CVE-2018-5711.patch 
libgd2-2.2.4/debian/patches/0009-CVE-2018-5711.patch
--- libgd2-2.2.4/debian/patches/0009-CVE-2018-5711.patch1970-01-01 
01:00:00.0 +0100
+++ libgd2-2.2.4/debian/patches/0009-CVE-2018-5711.patch2018-09-07 
17:28:33.0 +0200
@@ -0,0 +1,54 @@
+From a11f47475e6443b7f32d21f2271f28f417e2ac04 Mon Sep 17 00:00:00 2001
+From: "Christoph M. Becker" 
+Date: Wed, 29 Nov 2017 19:37:38 +0100
+Subject: [PATCH] Fix #420: Potential infinite loop in gdImageCreateFromGifCtx
+
+Due to a signedness confusion in `GetCode_` a corrupt GIF file can
+trigger an infinite loop.  Furthermore we make sure that a GIF without
+any palette entries is treated as invalid *after* open palette entries
+have been removed.
+
+CVE-2018-5711
+
+See also https://bugs.php.net/bug.php?id=75571.
+---
+ src/gd_gif_in.c |  12 ++--
+
+diff --git a/src/gd_gif_in.c b/src/gd_gif_in.c
+index daf26e79..0a8bd717 100644
+--- a/src/gd_gif_in.c
 b/src/gd_gif_in.c
+@@ -335,11 +335,6 @@ BGD_DECLARE(gdImagePtr) 
gdImageCreateFromGifCtx(gdIOCtxPtr fd)
+   return 0;
+   }
+ 

Bug#910395: mediathekview: No longer works due to "missing" openjfx

[Hilko Bengen]

Package: mediathekview
Version: 13.0.6-1
Severity: serious

Dear Maintainer,

when trying to start mediathekview, I get the following:
,
| $ mediathekview 
| ===
| JavaFX wurde nicht im klassenpfad gefunden. 
|  Stellen Sie sicher, dass Sie ein Java JRE ab Version 8 benutzen. 
|  Falls Sie Linux nutzen, installieren Sie das openjfx-Paket ihres 
Package-Managers,
|  oder nutzen Sie eine eigene JRE-Installation.
| ===
`

(Translated into English: JavaFX was not found in the classpah. Ensure
that you are using JRE 8 or later. If you use Linux, install the openjfx
package provided by your pacakge manager or use a seaparate JRE
installation.)

As you can see below, libopenjfx-java is installed.

This is the version that is apparently selected by java_wrappers:
,
| $ bash
| $ . /usr/lib/java-wrappers/java-wrappers.sh
| $ find_java_runtime java8
| $ run_java --version
| openjdk 10.0.2 2018-07-17
| OpenJDK Runtime Environment (build 10.0.2+13-Debian-1)
| OpenJDK 64-Bit Server VM (build 10.0.2+13-Debian-1, mixed mode)
`

Let's see... Selecting different JREs does not help:
,
| $ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mediathekview 
| ===
| JavaFX wurde nicht im klassenpfad gefunden. 
|  Stellen Sie sicher, dass Sie ein Java JRE ab Version 8 benutzen. 
|  Falls Sie Linux nutzen, installieren Sie das openjfx-Paket ihres 
Package-Managers,
|  oder nutzen Sie eine eigene JRE-Installation.
| ===
`
,
| $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/ mediathekview
| ===
| JavaFX wurde nicht im klassenpfad gefunden. 
|  Stellen Sie sicher, dass Sie ein Java JRE ab Version 8 benutzen. 
|  Falls Sie Linux nutzen, installieren Sie das openjfx-Paket ihres 
Package-Managers,
|  oder nutzen Sie eine eigene JRE-Installation.
| ===
`

Unfortunately, the error message is made deliberately useless by hiding the
ClassNotFoundException:
,[ mediathekview-13.0.6/src/main/java/mediathek/Main.java ]
| private static boolean hasJavaFx() {
| try {
| Class.forName(JAVAFX_CLASSNAME_APPLICATION_PLATFORM);
| return true;
| 
| } catch (ClassNotFoundException e) {
| System.out.println(TEXT_LINE);
| System.out.printf(Messages.ERROR_NO_JAVAFX_INSTALLED.getText());
| System.out.println(TEXT_LINE);
| 
| return false;
| }
| }
`

I am not even able to rebuild the package with the try/catch nonsense
removed, so I am giving up here for the moment.

Cheers,
-Hilko

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

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

Versions of packages mediathekview depends on:
ii  default-jre [java8-runtime] 2:1.10-68
ii  java-wrappers   0.3
ii  libcommons-compress-java1.18-1
ii  libcommons-lang3-java   3.8-1
ii  libjackson2-core-java   2.9.4-1
ii  libjchart2d-java3.2.2+dfsg2-2
ii  libjgoodies-forms-java  1.9.0-3
ii  libjide-oss-java3.7.4+dfsg-1
ii  libmac-widgets-java 0.10.0+svn416-dfsg1-2
ii  libokhttp-java  3.11.0-1
ii  libopenjfx-java 11+26-1
ii  libswingx-java  1:1.6.2-3
ii  libtimingframework-java 1.0-1
ii  libxz-java  1.8-2
ii  openjdk-10-jre [java8-runtime]  10.0.2+13-1
ii  openjdk-8-jre [java8-runtime]   8u181-b13-1

Versions of packages mediathekview recommends:
ii  flvstreamer  2.1c1-1+b2
ii  mplayer  2:1.3.0-8+b4
ii  vlc  3.0.4-2+b1

Versions of packages mediathekview suggests:
ii  ffmpeg  7:4.0.2-2+b1

-- no debconf information

Bug#910393: RFP: node-husky -- Git hooks made easy

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-husky
  Version : 4378d180b7 
  Upstream Author : typicode ( @typic...@twitter.com ) 
* URL : https://notabug.org/themusicgod1/husky
* License : MIT
  Programming Lang: javascript
  Description : Git hooks made easy

Husky can prevent bad commit, push and more. "woof!"
Husky is used by over 4000 projects.  

(see https://libraries.io/npm/husky/dependent-repositories )
and in particular, meteor-dapp-wallet ( #908151).

Husky can keep existing user hooks, support GUI Git clients and 
supports all Git hooks (pre-commit, pre-push, ...).

Bug#910394: sqlcipher: Crashes on running any SQL Statement

[Chris]

Package: libsqlcipher0
Version: 3.2.0-2
Severity: grave
File: sqlcipher
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
 Installing the package using apt, delivers a version that does not work. 
However, if compiled from source, it works perfectly.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Compiling from source works.


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

Kernel: Linux 4.4.0-134-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libsqlcipher0:amd64 depends on:
ii  libc6  2.24-11+deb9u3
ii  libssl1.1  1.1.0f-3+deb9u2

libsqlcipher0:amd64 recommends no packages.

libsqlcipher0:amd64 suggests no packages.

-- no debconf information

Bug#910392: fontconfig: fc-cache regeneration fails unless EPOC time is set.

[Don Alex]

Package: fontconfig
Version: 2.13.1-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
apt upgrade. Regenerating fonts breaks other configurations like libreoffice
etc.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Following this ARCH thread (https://bugs.archlinux.org/task/59889) they
recommended running fc-cache with
"sudo SOURCE_DATE_EPOCH=$(date +%s)" which as explained from the fontconfig
documentation "SOURCE_DATE_EPOCH is used to ensure fc-cache(1) generates files
in a deterministic manner in order to support reproducible builds. When set to
a numeric representation of UNIX timestamp, fontconfig will prefer this value
over using the modification timestamps of the input files in order to identify
which cache files require regeneration."




   * What was the outcome of this action?

Patching /var/lib/dpkg/fontconfig.postinst with that command worked

   * What outcome did you expect instead?

fc-cache: failed




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

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

Versions of packages fontconfig depends on:
ii  fontconfig-config  2.13.1-1
ii  libc6  2.27-6
ii  libfontconfig1 2.13.1-1
ii  libfreetype6   2.8.1-2

fontconfig recommends no packages.

fontconfig suggests no packages.

-- debconf-show failed

Bug#909602: [Pkg-mailman-hackers] Bug#909602: Bug#909602: Bug#909602: mailmanclient causes python3-mailman-hyperkitty and mailman3-web to fail to install in buster

[Pierre-Elliott Bécue]

Le vendredi 05 octobre 2018 à 11:30:03+0200, Pierre-Elliott Bécue a écrit :
> Le jeudi 04 octobre 2018 à 08:57:52+0200, Paul Gevers a écrit :
> > Hi Pierre,
> > 
> > On 04-10-18 00:47, Pierre-Elliott Bécue wrote:
> > > Would you prefer if we push a fix or if we wait for mailman-hyperkitty
> > > migration?
> > 
> > I don't think my preference matters here. Do what you think is best for
> > the mailman suite. I'll just quote [1] a statement from the release team
> > on this matter: "Therefore, we highly recommend that people work on
> > solving the underlying issue rather than wait it out."
> > 
> > Paul
> > 
> > [1] https://lists.debian.org/debian-devel-announce/2018/09/msg4.html
> 
> I think I'll do something this evening. :)

Good evening.

I had a look ad it this evening.

The only really missing element was the explicit dependency for the latest
release of mailman3 (more specifically, bin:mailman3-full) on the latest
release of mailman3-web (ie 20180916).

Since this dep was missing, it was possible to install mailman3-full
alongside with mailman3-web 20170523 which draws py2 deps instead of py3
ones.

I'll do a batch of uploads that should set the dependency tree right.

That said, the problem is gone.

I'll close this bug by hand when the uploads are done.

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#910390: libpdfbox-java: CVE-2018-11797

[Salvatore Bonaccorso]

Source: libpdfbox-java
Version: 1:1.8.12-1
Severity: important
Tags: security upstream
Control: found -1 1:1.8.15-1
Control: clone -1 -2
Control: reassign -2 src:libpdfbox2-java 2.0.11-1
Control: retitle -2 libpdfbox2-java: CVE-2018-11797

Hi,

The following vulnerability was published for libpdfbox-java.

CVE-2018-11797[0]:
denial of service vulnerability

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-11797
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11797
[1] https://www.openwall.com/lists/oss-security/2018/10/05/4

Regards,
Salvatore

Bug#909677: aisleriot: Consider temporarily removing aisleriot/armel to deal with testing migration blocking

[Jeremy Bicha]

On Wed, Sep 26, 2018 at 11:51 AM Boyuan Yang  wrote:
> As discussed at https://lists.debian.org/debian-arm/2018/09/msg00058.html , it
> seems that one of aisleriot's build dependency, guile-2.2-dev, will not be
> available in Debian on armel for quite a while. To prevent from blocking
> package from migrating to testing, is it okay that a RM bug could be submitted
> to have aisleriot/armel removed for now so that the current testing migration
> block could be circumvented? [1]

Please file the removal bug.

We're demoting the gnome-games dependency on aisleriot to a Recommends.

Thanks,
Jeremy Bicha

Bug#910389: RFP: golang-notabug-themusicgod1-gosigar -- Gathers system and per process statistics

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: golang-notabug-themusicgod1-gosigar
  Version : 37f05ff46f
  Upstream Author : Andrew "andrewkroh" Kroh 
* URL : https://notabug.org/themusicgod1/gosigar
* License : Apache-2.0
  Programming Lang: Go
  Description : Gathers system and per process statistics

Go sigar is a golang implementation of the sigar API. The Go version of sigar 
has a very 
similar interface, but written from scratch in pure go/cgo.

Bug#910388: please allow to use "external viewers" for n-way diffs

[Tomas Pospisek]

Package: dirdiff
Version: 2.1-7.2
Severity: wishlist
Tags: patch

It'd be nice if it'd be possible to also view n-way diffs in external
viewers (here: in vimdiff). That's just what the attached patch does:
if set then the configured external viewer is also used for n-way diffs.

There's one aspect of this patch, that's a bit ugly: the patch is pretty
much an exact copy of the code of the "proc diff2" code part, that calls
the external viewer.

This results in the params given to the external viewer being a bit
"weird". Namely what the external viewer gets as parameters is:

dir1 dir2 dir3 ... file_path

That means that the external viewer needs to check the number of
parameters and if there's more than two, then it needs to construct the
filepaths like this:

dir1/file_path dir2/file_path dir3/file_path ...

I've implemented a wrapper for vimdiff that does that. It's using
`konsole` as a terminal, but that can be changed easily:

$ cat ~/bin/dirdiff_vimdiff 
#!/bin/bash
#
if [ $# -gt 2 ]; then
# dirdiff calls us with parameters:
#
#dir1 dir2 dir3 ... file_name_to_diff

# the file is the last parameter given
file_to_diff="${@:$#:1}"

# iterate over all parameters and construct
# the full_path=dir+file_to_diff
for i in $(seq 0 $(( $# - 1))); do
j=$(( $i + 1 ))
full_paths[$i]="${@:$j:1}/$file_to_diff"
done

# delete last element, since that's the file
# itself:
unset 'full_paths[-1]'

konsole --workdir `pwd` -e vimdiff "${full_paths[@]}"
else
konsole --workdir `pwd` -e vimdiff "$1" "$2"
fi

Alternatively the patch could be changed to do the path construction
inside dirdiff before calling the external program. I'll leave that
as a challenge ;-)

Thanks,
*t

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

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

Versions of packages dirdiff depends on:
ii  libc6  2.24-11+deb9u3
ii  libtcl8.6  8.6.6+dfsg-1+b1
ii  tk8.6  8.6.6-1+b1

dirdiff recommends no packages.

dirdiff suggests no packages.

-- no debconf information
--- /usr/bin/dirdiff2018-04-29 09:19:39.0 +0200
+++ /tmp/dirdiff2018-10-05 20:55:45.192961740 +0200
@@ -2517,6 +2517,7 @@
 }
 
 proc diffn {dirlist f {orig 1}} {
+global diffprogram
 global diffing diffdirs difffile difffds diffrel allf
 global difflnos diffndirs diffstate difflnum nextdiffhdr diffhdr
 global diffiflag diffwflag diffbflag diffdflag incline
@@ -2547,6 +2548,12 @@
 catch {unset incline}
 
 set diffopts "-u $diffiflag $diffwflag $diffbflag $diffdflag"
+
+if { [llength $diffprogram] > 0} {
+   exec $diffprogram {*}$dirlist $f &
+   return
+}
+
 set d [lindex $dirlist 0]
 set p [joinname $d $f]
 set diffrel(0) 0

Bug#910387: pycode-browser: FTBFS (endless loop)

[Santiago Vila]

Package: src:pycode-browser
Version: 1:1.02+git20171115-1
Severity: serious
Tags: ftbfs patch

Dear maintainer:

I tried to build this package in buster but the build entered an
endless loop and did never end. The endless loop also happens here:

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

The problem is in pybooksrc/Makefile which reads like this:

while (grep  Warning $${logfile}| grep -iq run); do \
  pdflatex $<; \
done

This is probably to detect this Warning message:

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.

but the iterated pdflatex runs now generate the following Warning
messages, of which the second one matches "Warning" and "run":

Package Babel Warning: The package option english' should not be used
--> Package geometry Warning: The marginal notes overrun the paper.
LaTeX Font Warning: Font shape OML/cmtt/m/n' undefined
LaTeX Font Warning: Font shape OMS/cmtt/m/n' undefined
LaTeX Font Warning: Some font shapes were not available, defaults substituted.

Suggested fix below.

Thanks.

--- a/pybooksrc/Makefile
+++ b/pybooksrc/Makefile
@@ -16,6 +16,6 @@ install:
 %.pdf: %.tex
pdflatex $<
logfile=$$(echo $< | sed 's/tex/log/'); \
-   while (grep  Warning $${logfile}| grep -iq run); do \
+   set -e; while grep -q Rerun $${logfile}; do \
  pdflatex $<; \
done

Bug#910386: [patch]: fix compiler warnings wrt unistd functions (read, close)

[Tomas Pospisek]

Package: dirdiff
Version: 2.1-7.2.tpo
Severity: minor
Tags: patch

The attached patch fixes this:

filecmp.c: In function ‘FileCmpCmd’:
filecmp.c:278:2: warning: implicit declaration of function ‘close’ 
[-Wimplicit-function-declaration]
  close(f1);
  ^
filecmp.c:293:11: warning: implicit declaration of function ‘read’ 
[-Wimplicit-function-declaration]
  n1 = read(f1, b1 + k1, BSIZE - k1);
   ^~~~


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

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

Versions of packages dirdiff depends on:
ii  libc6  2.24-11+deb9u3
ii  libtcl8.6  8.6.6+dfsg-1+b1
ii  tk8.6  8.6.6-1+b1

dirdiff recommends no packages.

dirdiff suggests no packages.

-- no debconf information
--- cvs-local.orig/filecmp.c
+++ cvs-local/filecmp.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include  /* close, read */
 
 #define BSIZE  32768
 #define MAXTAGLEN  512 /* max tag length for sanity, < BSIZE */

Bug#910377: Inhibit reboot/shutdown if dpkg is running

[Michael Biebl]

Am 05.10.18 um 18:36 schrieb Laurent Bigonville:
> Package: systemd
> Version: 239-10
> Severity: wishlist
> 
> Hi,
> 
> Not sure if this should be reported here or in dpkg
> 
> Shouldn't it be intresting to add a hook in dpkg to inhibit the
> reboot/shutdown of the machine while packages are being
> updated/installed?
> 


I don't see how this could be implemented via a dpkg hook.
Can you elaborate, maybe provide a hook file which implements what you
have in mind?

That said, also keep in mind, that the inhibit mechanism does not work
if the reboot request is triggered by privileged users [1], e.g. if you
trigger a reboot as root, an existing inhibitor blocks are ignored.

Michael

[1] https://github.com/systemd/systemd/issues/6644

-- 
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#910377: Inhibit reboot/shutdown if dpkg is running

[Michael Biebl]

Am 05.10.18 um 21:28 schrieb Michael Biebl:
> That said, also keep in mind, that the inhibit mechanism does not work
> if the reboot request is triggered by privileged users [1], e.g. if you
> trigger a reboot as root, an existing inhibitor blocks are ignored.
> [1] https://github.com/systemd/systemd/issues/6644

This issue describes this even better
https://github.com/systemd/systemd/issues/2680

-- 
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#909193: mpv shows artifacts when playing IPTV rtp:// streams

[Pavel Kreuzt]

Problem is I use private streams from my ISP/TV provider and they are not
visible out of customer home network. But as long  as I can tell the
problem is similar to this:

https://github.com/mpv-player/mpv/issues/1637

Also the ffmpeg pipe seems to workaround the problem with:

ffmpeg -i rtp://@somestream -c copy -f mpegts - | mpv -

Output of mpv included.

On Sat, Sep 29, 2018 at 8:50 PM James Cowgill  wrote:

> Control: tags -1 moreinfo
>
> Hi,
>
> On 19/09/2018 15:01, Pavel Kreuzt wrote:
> > Package: mpv
> > Version: 0.29.0-1+b1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > the artifacts are mostly located on the lower side of the window.
> Streams play correctly with ffplay without extra options, so it's not a
> decoder problem.
>
> Can you provide an example stream which exibits this behavior? I tested
> a few rtp streams and they seem to work fine.
>
> Also, please run mpv with the "-v" option on one of the broken streams,
> and attach the output to this bug report.
>
> Thanks,
> James
>
>

pavel@kant:~$ mpv -v rtp://@239.0.3.32:8208
[cplayer] Command line options: '-v' 'rtp://@239.0.3.32:8208'
[cplayer] mpv 0.29.0 Copyright © 2000-2018 mpv/MPlayer/mplayer2 projects
[cplayer]  built on UNKNOWN
[cplayer] ffmpeg library versions:
[cplayer]libavutil   56.14.100
[cplayer]libavcodec  58.18.100
[cplayer]libavformat 58.12.100
[cplayer]libswscale  5.1.100
[cplayer]libavfilter 7.16.100
[cplayer]libswresample   3.1.100
[cplayer] ffmpeg version: 4.0.2-2+b1
[cplayer] 
[cplayer] Configuration: ./waf configure --prefix=/usr 
--libdir=/usr/lib/x86_64-linux-gnu --confdir=/etc/mpv 
--zshdir=/usr/share/zsh/vendor-completions --enable-cdda --enable-dvdnav 
--enable-dvdread --enable-libmpv-shared --enable-libsmbclient --enable-sdl2 
--enable-sndio --enable-zsh-comp --disable-build-date --enable-dvbin
[cplayer] List of enabled features: 52arch alsa asm atomics caca cdda cplayer 
cplugins debug-build drm drmprime dvbin dvdnav dvdread dvdread-common egl-drm 
egl-helpers egl-x11 fchmod ffmpeg gbm gbm.h gl gl-wayland gl-x11 
glibc-thread-name glob glob-posix gnuc gpl iconv jack jpeg lcms2 libaf 
libarchive libass libass-osd libav-any libavcodec libavdevice libbluray libdl 
libm libmpv-shared librt libsmbclient linux-fstatfs lua optimize oss-audio 
plain-gl posix posix-or-mingw posix-spawn posix-spawn-native pthreads pulse 
rubberband sdl2 sndio stdatomic uchardet vaapi vaapi-drm vaapi-egl vaapi-glx 
vaapi-wayland vaapi-x-egl vaapi-x11 vdpau vdpau-gl-x11 vt.h vulkan wayland 
wayland-protocols x11 xv zlib zsh-comp
[cplayer] Reading config file /etc/mpv/encoding-profiles.conf
[cplayer] Reading config file /home/pavel/.config/mpv/mpv.conf
[cplayer] Waiting for scripts...
[ytdl_hook] script-opts/ytdl_hook.conf not found. 
[ytdl_hook] lua-settings/ytdl_hook.conf not found. 
[stats] script-opts/stats.conf not found. 
[stats] lua-settings/stats.conf not found. 
[osc] script-opts/osc.conf not found. 
[osc] lua-settings/osc.conf not found. 
[osd/libass] Shaper: FriBidi 0.19.7 (SIMPLE) HarfBuzz-ng 1.9.0 (COMPLEX)
[osd/libass] Setting up fonts...
[cplayer] Done loading scripts.
[cplayer] Playing: rtp://@239.0.3.32:8208
[ffmpeg] Opening rtp://@239.0.3.32:8208
[ffmpeg] Could not set AVOption reconnect='1'
[ffmpeg] Could not set AVOption reconnect_delay_max='7'
[ffmpeg] Could not set AVOption user_agent='mpv 0.29.0'
[ffmpeg] Could not set AVOption tls_verify='0'
[ffmpeg] Could not set AVOption icy='1'
[cache] Cache size set to 2 KiB (1 KiB backbuffer)
[demux] Trying demuxers for level=normal.
[osd/libass] Using font provider fontconfig
[osd/libass] Done.
[lavf] Found 'mpegts' at score=47 size=2048.
[ffmpeg/video] h264: non-existing SPS 0 referenced in buffering period
[ffmpeg/video] h264: SPS unavailable in decode_picture_timing
[ffmpeg/video] h264: non-existing PPS 0 referenced
[ffmpeg/video] h264: non-existing SPS 0 referenced in buffering period
[ffmpeg/video] h264: SPS unavailable in decode_picture_timing
[ffmpeg/video] h264: non-existing PPS 0 referenced
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
[ffmpeg/video] h264: cabac decode of qscale diff failed at 39 25
[ffmpeg/video] h264: error while decoding MB 39 24, bytestream 14753
[ffmpeg/video] h264: concealing 550 DC, 550 AC, 550 MV errors in I frame
[ffmpeg/video] h264: mmco: unref short failure
[ffmpeg/video] h264: mmco: unref short failure
[ffmpeg/video] h264: mmco: unref short failure
[ffmpeg/video] h264: reference picture missing during reorder
[ffmpeg/video] h264: Missing reference picture, default is 65548
[ffmpeg/video] h264: concealing 898 DC, 898 AC, 898 MV errors in P frame
[ffmpeg/video] h264: mmco: unref short failure
[lavf] avformat_find_stream_info() finished after 354568 bytes.
[demux] Detected file format: mpegts (libavformat)
[demux] Stream is not seekable.
[cache] blocking for STREAM_CTRL 6
[cplayer] Opening done: rtp://@239.0.3.32:8208
[cplayer] Running hook: 

Bug#910385: RFP: golang-github-openconfig-gnmi -- gRPC Network Management Interface

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: notabug-themusicgod1-gnmi
  Version : fc15ea7f1
  Upstream Author : Andrew Lytvynov ( @a...@github.com )
* URL : https://notabug.org/themusicgod1/gnmi
* License : Apache-2.0
  Programming Lang: go
  Description : gRPC Network Management Interface

includes abstracted client library with pluggable implementations, client 
implementation using gnmi.proto, client implementation using openconfig.proto, 
CLI that supports both of the above implementations

GNMI is a dependency of arista go ( # 858722 ).

Bug#900240: Upstream fixes of cmake for GNU/Hiurd

[Svante Signell]

Hello Samuel,

Time to make an NMU of cmake. The needed patches are now committed upstream, see
below:

From:   Brad King 
Subject: Re: CMake | Port to GNU Hurd (#18337)

AFAIK the only changes were 3c0bfb59 and c990649b. The former is already in
3.12.3. The latter will be in 3.13.

Bug#910384: libhandy-dev: Missing dependency on libgtk-3-dev

[Jeremy Bicha]

Package: libhandy-0.0-dev
Version: 0.0.3-1
Severity: serious

I see that libhandy-0.0.pc has this line:
Requires: gtk+-3.0

That means that libhandy-0.0-dev needs a dependency on libgtk-3-dev

By the way, GNOME 3.32 components might start depending on libhandy.
(Buster will include GNOME 3.30 so Unstable is fine for now.) Thanks
for packaging this!

Thanks,
Jeremy Bicha

Bug#910383: RM: spdy-indicator/2.2-1

[Moritz Muehlenhoff]

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

Broken with Firefox ESR 60, filed for removal from unstable in 910382.

Cheers,
Moritz

Bug#910104: hypre: autopkgtest times out most of the times

[Paul Gevers]

Dear Drew,

On 05-10-18 20:20, Drew Parsons wrote:
> Hi Paul, I replied to Bug#910104 but not sure if it forwarded to you.

No, bug submitters are not automatically subscribed, so you always need
to CC them.

> Is
> it possible to trigger debci the test the new hypre in testing?

You can do that yourself: see https://ci.debian.net/api/doc

> It
> already passed there. It will be useful to know if it still passes. That
> will help check if the problem is in hypre or in new versions of openmpi
> in unstable.

I learned that after submitting this bug. Please feel free to trigger a
couple of runs, but to avoid DoS, please one at a time.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#910382: RM: spdy-indicator -- RoQA; broken with current Firefox, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove spdy-indicator. It's broken with current Firefox and the 
maintainer
agreed to it's removal in #906826.

Cheers,
Moritz

Bug#863892: Splitting the zziplib vulnerabilities bug into two

[Moritz Mühlenhoff]

retitle 854727 zziplib: Update Homepage field
severity 854727 normal
thanks

On Sat, May 26, 2018 at 08:49:00AM +, Niels Thykier wrote:
> On Thu, 1 Jun 2017 19:37:10 +0300 Adrian Bunk  wrote:
> > clone 854727 -1
> > retitile -1 zziplib: unsuitable for future stable releases?
> > tags -1 - security
> > retitle 854727 zziplib: Multiple vulnerabilities
> > tags 854727 - jessie-ignore stretch-ignore
> > thanks
> > 
> > Considering the way the discussion developed, I am splitting this bug to 
> > track two separate issues:
> > - the original #854727 to track the status of the CVE fixes in jessie
> >   and stretch
> > - a new bug to track the suggested removal in buster
> > 
> > cu
> > Adrian
> > 
> 
> Hi,
> 
> It seems this bug has been standing still for almost a year (at least
> the bug log silent since the above mail).
> 
> If we are planning on removing zziplib in buster, then now would be a
> good time to act.  If there has not been any (significant) progress on
> this bug when we get closer to the freeze, then we will probably end up
> having to defer the issue until later.

Upstream seems to have moved to Github and is active again: 
https://github.com/gdraheim

So I think we can simply rename this bug to get the Homepage: updated.

Cheers,
Moritz

Bug#905411: New list creation: debian-fundraising

[Louis-Philippe Véronneau]

On 2018-10-04 1:28 p.m., Alexander Wirt wrote:
> On Wed, 03 Oct 2018, Louis-Philippe Véronneau wrote:
> 
>> On 2018-10-03 1:30 p.m., Hanno 'Rince' Wagner wrote:
>>> Hi Louis-Philippe!
>>>
>>> On Wed, 29 Aug 2018, Louis-Philippe Véronneau wrote:
>>>
 Any news regarding the creation of this ML?

 I know you said 'This has to be discussed within the team.', but it's
 been a month and it's hard to go forward with this project if we don't
 have a platform to discuss on...
>>>
>>> I am sorry that this has been delayed.
>>>
 Is the answer to our request of a closed ML from listmasters is a strait
 'No'?
>>>
>>> our experience is that closed lists make much more work than it is
>>> worth. I do not know your reasoning for a closed list - just
>>> confidentiality or more - but we would prefer an open list since this
>>> is just easier to maintain.
>>>
 If that is the only blocker for the creation of that mailing list, I
 guess we can work on an open ML for now. I don't think we'll be dealing
 with sponsors directly for the next year anyway.
>>>
>>> Okay, then If you agree to this, I can create that list without an
>>> archive. so please confirm that the list can be open.
>>>
>>> best regards, Hanno Wagner, Listmaster of the day
>>>
>>
>> I don't think we will discuss confidential sponsor infos on that list
>> for now, as we are only starting the process.
>>
>> An open list without archive thus suits me just fine.
>>
>> Thanks for your work maintaining the lists!
> By the way, what differentates that list from debconf-sponsoring? Why do you
> need two lists that do more or less the same? 

DebConf sponsorship is a list dedicated to the day to day activities of
the DebConf sponsorship team.

The idea behind the Debian Fundraising list is to try to to come up with
a unified fundraising plan for Debian, that would eventually include
DebConf, but also other teams in Debian such as DSA and other teams that
need funding.

A few of us have been talking about this for a while and during a BoF at
DebConf18 we agreed having a mailing list would help us go forward with
this.

We wanted a second list not to hinder the DC19 fundraising efforts.


-- 
  ,''`.
 : :'  : Louis-Philippe Véronneau
 `. `'`  po...@debian.org / veronneau.org
   `-



signature.asc
Description: OpenPGP digital signature

Bug#910381: RFP: node-chai-as-promised -- Chai as Promised extends Chai with a fluent language for asserting facts about promises.

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-chai-as-promised
  Version : 7.1.1
  Upstream Author :  
* URL : https://www.npmjs.com/package/chai-as-promised
* License : WTFPL
  Programming Lang: javascript
  Description : Extends Chai with a fluent language for asserting facts 
about promises.

Instead of manually wiring up your expectations to a promise's fulfilled and 
rejected handlers
you can write code that expresses what you really mean.

There are over 512 projects that depend on this package.  Including mist ( 
#827314 )

Bug#910327: Fwd: Bug#910327: RFS: javapoet/1.11.1-1 [ITP]

[Miroslav Kravec]

Hello Tony,

can you please take a look at it again? It can be downloaded from
mentors, using same command (URL):

dget -x 
https://mentors.debian.net/debian/pool/main/j/javapoet/javapoet_1.11.1-1.dsc

I have explicitly listed files copyrighted by Google in
debian/copyright. And, I have left Square, Inc. as default for all (*)
files, as it's library's primary author.

Kind regards,
Miroslav Kravec

Bug#910370: [mutter] mutter/gnome-shell 3.30.0 crashed when using touchscreen and wacom pen

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/mutter/issues/294
Control: tags -1 + fixed-upstream

On Fri, 05 Oct 2018 at 16:22:03 +0200, Christian Engwer wrote:
> There is a patch available, which is part of mutter 3.30.1:
>  * 
> https://gitlab.gnome.org/GNOME/mutter/commit/a3d9f987c8303550bc740cba4645c8fba161c7fb.diff

mutter 3.30.1 doesn't seem to exist yet, so this commit can't be part
of mutter 3.30.1 yet? (There isn't even a gnome-3-30 branch.)

The commit looks reasonable, though;
it fixes a line mistakenly removed in commit
,
between 3.29.2 and 3.29.3, which is why it wasn't in the batch of bugfixes
that I already applied (the ones corresponding to the gnome-3-28 branch).

smcv

Bug#910380: package makemime separately

[Vincent Breitmoser]

Package: maildrop
Version: 2.9.3-2
Severity: wishlist

Hi there,

I found makemime to be a very useful tool, particularly in combination with
mblaze, but do not actually use maildrop itself or any of the other tools in the
package. Given that makemime is easily complex to stand on its own, but has no
dependencies itself, I would very much welcome a separate packaging of makemime.

Thanks for considering!

 - V

Bug#887565: RFS: python-vlc/3.0.102-1 [ITP]

[Bastian Germann]

Hi,

I am looking for a sponsor for my package "python-vlc"

 * Package name: python-vlc
   Version : 3.0.102-1
   Upstream Author : Olivier Aubert
 * URL : http://wiki.videolan.org/PythonBinding
 * License : LGPL-2.1+
   Section : python

It builds those binary packages:

 python3-vlc - VLC Python bindings

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

 https://mentors.debian.net/package/python-vlc


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

 dget -x
https://mentors.debian.net/debian/pool/main/p/python-vlc/python-vlc_3.0.102-1.dsc

Regards,
Bastian Germann

Bug#910379: inkscape crashes when resizing elements with snapping on

[Andrej Shadura]

Package: inkscape
Version: 0.92.3-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I’ve repeatedly experienced crashes when trying to resize elements
in a drawing while having certain snapping modes on. One of the most
typical examples was trying to draw a strictly vertical line, holding
Ctrl while dragging, getting a crash.

See: 
https://bugs.launchpad.net/inkscape/+bug/1796046/+attachment/5197018/+files/crash%20recording.gif

The upstream has committed a fix: 
https://gitlab.com/inkscape/lib2geom/commit/f86669bdd13d467665c1b62104df7e66467ef37e

Please merge the patch fixing the issue so that it appears in the next
package release: 
https://salsa.debian.org/multimedia-team/inkscape/merge_requests/1

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAlu3lpkUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdKeqgf9HCmbo085eLfNl0MdvgCcYwpK0PTn
qh2tsEz3JE/pUP3YMSAO+W9jL50jtLwP0fRp4nUhFZ7BnOmVlIDF7NDp7uo0uPeK
I3XUpxDGMsFj+FYu8e3tcbTODlKC+x19C/k2m5LwU0b7SeqCH45ueTikOU42KtY0
8kmC447VJjCjy/yLzTyiWDEyGq0yAISE5m9e1k3lYwoz47pOeE8AU3bbu6/Ue4z+
bJZYrsxSzgJPB5zBfrhUbliS9i32PnQ8a0XesGQjCFqhvtasDBoCHoUCrQJBRU9m
ufNa69rP80+Q7GZsZhm6+fcyjaHhvX0XcL5A8sHcvU6xi/yTdVy6vf+7qA==
=HGRs
-END PGP SIGNATURE-

Bug#910378: mailman: Please include the List-Id header on subscription confirmation mails

[Chris Lamb]

Package: mailman
Version: 1:2.1.29-1
Severity: wishlist

Hi,

I just subscribed to a bunch of lists. Could you make the "You have
added to the subscriber list of […]" mails include the relevant List-ID
header?

That would mean I can setup filing right away instead of being confused
by the first email from these lists hitting my main inbox.


Best wishes,

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

Bug#910110: aptitude: aptitude does not update libxapian30 during aptitude "self upgrade"

[Sven Joachim]

Control: found -1 1.4.7-3

On 2018-10-05 03:08 +0100, Olly Betts wrote:

> On Tue, Oct 02, 2018 at 11:10:46PM +0200, Sven Joachim wrote:
>> Indeed, but that needs to be fixed in libxapian30's shlibs file.
>
> Fixed there by xapian-core 1.4.7-3.

Unfortunately it is not really fixed:

,
| $ cat /var/lib/dpkg/info/libxapian30:amd64.shlibs 
| libxapian 30 libxapian30
`

In debian/changelog you mentioned

,
|   * debian/rules: Generate shlibs.local so that reverse dependencies get a
| versioned dependency on libxapian30 based on the version when the ABI
| last changed. (Closes: #910110)
`

But shlibs.local only influences binaries built from the same source
package.  Instead of shlibs.local, you probably want to generate
libxapian30.shlibs - see dh_makeshlibs(1).

>> Then aptitude (and other reverse dependencies of libxapian30 that
>> might be affected) can be rebuilt to pick up the changed dependency.
>
> I've pulled out a list of the packages which need rebuilding from the
> buildinfo files on mirror.ftp-master.d.o (anything built against
> libxapian-dev 1.4.6-1 or higher which doesn't already have a suitably
> versioned dependency):
>
> 07/10/pinot_1.05-2_kfreebsd-i386.buildinfo: libxapian-dev (= 1.4.6-1),
> 07/10/zeitgeist_1.0.1-0.2_kfreebsd-i386.buildinfo: libxapian-dev (= 1.4.6-1),
> 08/08/maildir-utils_1.0-6_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 08/17/baloo-kf5_5.49.0-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 08/28/recoll_1.24.1-3_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 09/06/plasma-desktop_5.13.5-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 09/06/plasma-workspace_5.13.5-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 09/07/aptitude_0.8.11-3_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 09/29/packagesearch_2.7.9_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 10/02/cyrus-imapd_2.5.11-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 10/03/akonadiconsole_18.08.1-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 10/03/akonadi-search_18.08.1-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 10/04/notmuch_0.28~rc0-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 10/05/libsearch-xapian-perl_1.2.25.2-1_kfreebsd-amd64.buildinfo: 
> libxapian-dev (= 1.4.7-2),

Thanks for your research.

> I'll request rebuilds once 1.4.7-3 has built on most architectures,
> and recheck the latest buildinfo files in case anything gets built
> against the current libxapian-dev before the new one propagates
> everywhere.

The rebuilds should be scheduled with a dep-wait for libxapian-dev (>=
1.4.7-4) if that version indeed fixes the bug (see
https://release.debian.org/wanna-build.html).

Cheers,
   Sven

Bug#890819: packagekit: Update while booting always fails

[Laurent Bigonville]

On Mon, 19 Feb 2018 11:07:18 + Joel Cross 
 wrote:

>

> Dear Maintainer,

Hello,

>
> I update my (sid) distro on roughly a weekly basis using pkcon 
(packagekit-

> tools). The command I use is as follows:
> sudo apt update && pkcon update -d && pkcon offline-trigger
> I then proceed to restart my system, which does a complete update 
while the

> system boots up.
>
> Recently (a little over a month ago), this has stopped working. The 
initial
> command downloads fine and everything appears to work OK, but when I 
restart I
> see the update message for about a second, then the system restarts 
without

> applying the update.
>
> Output of the command `pkcon offline-status` is as follows:
> Status: Failed
> ErrorCode:failed-initialization
[...]

Could you please retry again? Is this fixed? I tried today and it was 
working for me with the current version in unstable (1.1.10-1)


Kind regards,

Laurent Bigonville

Bug#909718: debian-live: bootia32.efi + UEFI32 + SecureBoot => certificate error

[Steve McIntyre]

On Thu, Sep 27, 2018 at 08:45:17AM +0200, beta-tester wrote:
>Package: debian-live
>Severity: normal
>
>Dear Maintainer,
>
>i have a tablet/netbook with:
>
>- 32bit UEFI (only),
>- SecureBoot enabled,
>- 32/64bit CPU,
>- Windows 10 Pro (32bit)
>
>i can't use the live-dvd 64bit, 32bit version nor the multi-arch
>(debian-9.5.0-amd64-i386-netinst.iso) to boot LiveDVD or LiveUSB,
>because bootia32.efi on the Live iso media isn't signed properly. i
>get a signed certificat error at boot time from UEFI.
>
>on a PC with 64bit UEFI and SecureBoot enabled i don't have that problem.
>
>why is the bootx64.efi signed properly for SecureBoot an UEFI 64bit,
>but bootia32.efi isn't signed properly for SecureBoot an UEFI 32bit ?

We don't have Secure Boot enabled for *any* of our 9.x images
yet. Your 64-bit PC must have SB disabled, or it's ignoring the lack
of signature. Maybe it's booting in BIOS mode?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.

Bug#910377: Inhibit reboot/shutdown if dpkg is running

[Laurent Bigonville]

Package: systemd
Version: 239-10
Severity: wishlist

Hi,

Not sure if this should be reported here or in dpkg

Shouldn't it be intresting to add a hook in dpkg to inhibit the
reboot/shutdown of the machine while packages are being
updated/installed?

Kind regards,

Laurent Bigonville

-- Package-specific info:

-- 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)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13-8
ii  libaudit11:2.8.4-2
ii  libblkid12.32.1-0.1
ii  libc62.27-6
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.4-2
ii  libgcrypt20  1.8.3-1
ii  libgnutls30  3.5.19-1+b1
ii  libgpg-error01.32-1
ii  libidn11 1.33-2.2
ii  libip4tc01.6.2-1.1
ii  libkmod2 25-1
ii  liblz4-1 1.8.2-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.32.1-0.1
ii  libpam0g 1.1.8-3.8
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  239-10
ii  mount2.32.1-0.1
ii  procps   2:3.3.15-2
ii  util-linux   2.32.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.10-1
ii  libpam-systemd  239-10

Versions of packages systemd suggests:
ii  policykit-10.115-1
ii  systemd-container  239-10

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.132
ii  udev 239-10

-- no debconf information

Bug#910376: mat2: Incomplete debian/copyright?

[Chris Lamb]

Source: mat2
Version: 0.4.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Georg Faerber , ftpmas...@debian.org

Hi,

I just ACCEPTed mat2 from NEW but noticed it was missing attribution 
in debian/copyright for at least a certain "Marie Rose".

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#910375: puppet-module-barbican: Incomplete debian/copyright?

[Chris Lamb]

Source: puppet-module-barbican
Version: 13.1.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Thomas Goirand , ftpmas...@debian.org

Hi,

I just ACCEPTed puppet-module-barbican from NEW but noticed it was 
missing attribution in debian/copyright for at least Hewlett Packard.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#910374: puppet-module-barbican: Please remove unnecessary overrides

[Chris Lamb]

Source: puppet-module-barbican
Version: 13.1.0-1
Severity: important
X-Debbugs-CC: Thomas Goirand , ftpmas...@debian.org

Hi,

I just ACCEPTed puppet-module-barbican from NEW but was wondering if 
you could please remove the unnecessary overrides as previously
discussed.


Regards,

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

Bug#910373: gnucash: various UI issues with arrows keys and text selection

[Vincent Lefevre]

Package: gnucash
Version: 1:3.3-1
Severity: important
Tags: upstream
Forwarded: https://bugs.gnucash.org/show_bug.cgi?id=796875

GnuCash has various UI issues with arrows keys and text selection.
See: https://bugs.gnucash.org/show_bug.cgi?id=796875

I also reported https://bugs.gnucash.org/show_bug.cgi?id=796888 but
it might be seen as a dup of 796875 as it seems closely related.

This is a very annoying regression. The previous versions did not
have such issues.

-- 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.18.0-2-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)
LSM: AppArmor: enabled

Versions of packages gnucash depends on:
ii  gnucash-common   1:3.3-1
ii  guile-2.22.2.4+1-1
ii  guile-2.2-libs   2.2.4+1-1
ii  libaqbanking35   5.7.8-2
ii  libaqbanking35-plugins   5.7.8-2
ii  libatk1.0-0  2.30.0-1
ii  libboost-date-time1.62.0 1.62.0+dfsg-10
ii  libboost-filesystem1.62.01.62.0+dfsg-10
ii  libboost-locale1.62.01.62.0+dfsg-10
ii  libboost-regex1.62.0 1.62.0+dfsg-10
ii  libboost-system1.62.01.62.0+dfsg-10
ii  libc62.27-6
ii  libcairo-gobject21.14.10-1
ii  libcairo21.14.10-1
ii  libcrypt-ssleay-perl 0.73.06-1
ii  libdate-manip-perl   6.73-1
ii  libdbi1  0.9.0-5
ii  libfinance-quote-perl1.47-1
ii  libgc1c2 1:7.6.4-0.4
ii  libgcc1  1:8.2.0-7
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgtk-3-0   3.24.1-2
ii  libgwenhywfar60  4.20.0-7
ii  libhtml-tableextract-perl2.15-1
ii  libhtml-tree-perl5.07-1
ii  libicu60 60.2-6
ii  libjavascriptcoregtk-4.0-18  2.22.2-1
ii  libktoblzcheck1v51.49-4
ii  libofx7  1:0.9.13-2
ii  libpango-1.0-0   1.42.1-1
ii  libpangocairo-1.0-0  1.42.1-1
ii  libpython3.6 3.6.7~rc1-1
ii  libsecret-1-00.18.6-3
ii  libsoup2.4-1 2.64.1-1
ii  libstdc++6   8.2.0-7
ii  libwebkit2gtk-4.0-37 2.22.2-1
ii  libwww-perl  6.35-2
ii  libxml2  2.9.4+dfsg1-7+b1
ii  libxslt1.1   1.1.32-2
ii  perl 5.26.2-7
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gnucash recommends:
ii  gnucash-docs 3.3-1
ii  python3-gnucash  1:3.3-1
ii  yelp 3.30.0-1

Versions of packages gnucash suggests:
pn  libdbd-mysql
pn  libdbd-pgsql
ii  libdbd-sqlite3  0.9.0-6

-- no debconf information

Bug#910372: RM: mozjs60 [s390x] -- ROM; built but doesn't work

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org
Control: block 906016 by -1

mozjs60 60.1.0-1 was built on s390x, but only because build-time test
failures were ignored: it doesn't actually seem to work, with around 80%
of test-cases segfaulting (#909536). Newer releases to unstable do not
ignore these failures, resulting in FTBFS on s390x.

Please remove the non-functional mozjs60_60.1.0-1 binaries from s390x,
so that working mozjs60 versions for the other release architectures
can migrate to testing.

Thanks,
smcv

Bug#910269: pysnmp4 source is inconsistent

[Vincent Bernat]

 ❦  4 octobre 2018 12:08 +0200, Michal Arbet :

> Yes , diff looks big , just for sure , ls -la INSTALLED_PATH of pysnmp4
>
> root@sid-builder-pbuilder:/build/python-pysnmp4# ls -la
> /usr/lib/python3/dist-packages/pysnmp/hlapi/
> total 32
> drwxr-xr-x 5 root root 4096 Oct  4 09:56 .
> drwxr-xr-x 8 root root 4096 Sep 26 16:00 ..
> -rw-r--r-- 1 root root  236 Sep 13 23:30 __init__.py
> drwxr-xr-x 2 root root 4096 Sep 26 16:00 __pycache__
> -rw-r--r-- 1 root root 1907 Sep 13 23:30 transport.py
> drwxr-xr-x 4 root root 4096 Sep 26 16:00 v1arch
> drwxr-xr-x 6 root root 4096 Sep 26 16:00 v3arch
> -rw-r--r-- 1 root root 3007 Sep 13 23:30 varbinds.py
>
> For example asyncore folder is totally missing but on github there is >>
> https://github.com/etingof/pysnmp/tree/v4.4.6/pysnmp/hlapi

So, I have the original tarball I've used, it is named pysnmp-4.4.6, but
it looks like master. I suppose the wrong branch has been tagged. So,
I'll do another upload with a fixed tarball.
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#910104: hypre: autopkgtest times out most of the times

[Drew Parsons]

Source: hypre
Followup-For: Bug #910104

The autopkgtest timeouts are disappointing to be sure.  Especially
since they passed fine in testing.  That suggests the new openmpi3
versions might be at fault rather than hypre.  hypre is not the only
package with openmpi trouble at the moment.

Is it possible to trigger another debci test in testing to see if
hypre still passes there?

Drew

Bug#909288: transition: kdepim 18.08

[Emilio Pozuelo Monfort]

Hi,

kmailtransport and other packages are in bd-uninst and outdated on several
architectures because they need libkgapi which is blocked on the lack of
qtwebengine5. So either one of those get an optional build-dep so things can
build, or we'll need partial removals from the affected architectures. Can you
look into it?

Emilio

Bug#905889: transition: gdbm

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 04/10/2018 03:40, kact...@gnu.org wrote:
> 
> [2018-10-02 09:38] Emilio Pozuelo Monfort 
>> part   text/plain 567
>> On 11/08/2018 09:40, Dmitry Bogatov wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>>
>>> Hello. According to [1] I request approval of upload gdbm-1.17 into
>>> unstable. It will affect 28 packages, 26 of which build cleanly
>>> (no-changes source upload will be required) and I am ready to NMU
>>> patches for two others (perl and qsf).
> 
>> Is perl still unfixed? With the upcoming perl transition, that's
>> something th at I wouldn't like to see fixed through an NMU at this
>> point.
> 
> No, according to #904005, Perl maintainer fixed this issue himself.
> Only qsf left {no response from maintainer, will NMU}.

Let's do this now.

Emilio

Bug#910371: stretch-pu: package lxcfs/2.0.7-1.1

[Michael Banck]

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

Hi,

I would like to upload a lxcfs NMU to stable, fixing Bug #885542. This
would be useful for ci.debian.net autopkgtest, as ci.debian.net
currenlty runs lxc from stable.

I have sign-off from one of the maintainers:

09:39 < Zhenech> azeem, I don't have much time for LXC(FS) these days,
if terceiro does not object, feel free to NMU in stable.


Michael

-- System Information:
Debian Release: 8.10
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#910237: googletest breaks mathicgb autopkgtest: invalid cast

[Torrance, Douglas]

Control: forwarded -1 https://github.com/Macaulay2/mathicgb/issues/12

On 10/05/2018 09:40 AM, Paul Gevers wrote:
> Control: tags -1 ftbfs
> Control: severity -1 serious
> Control: retitle -1 googletest causes mathicgb to FTBFS: invalid cast
> 
> On 05-10-18 05:04, Steve Robbins wrote:
>>> Currently this regression is contributing to the delay of the migration
>>> of googletest to testing [1]. Due to the nature of this issue, I filed
>>> this bug report against both packages. Can you please investigate the
>>> situation and reassign the bug to the right package? If needed, please
>>> change the bug's severity.
>>
>> I had a look, but it's over my head.  Suggest to file bug upstream.
> 
> Which one? And by who?

I've forwarded the issue to mathicgb's upstream.

Doug

Bug#887565: ITP: retitle 887565 ITP: python-vlc -- Python bindings for VLC

[Bastian Germann]

I am currently working on the package at
https://salsa.debian.org/python-team/modules/python-vlc

Bug#906317: dgit: consider demoting git-buildpackage to recommends

[Ian Jackson]

Hector Oron writes ("Bug#906317: dgit: consider demoting git-buildpackage to 
recommends"):
> As I understood, DSA team had some concerns for security reasons since
> porterboxes are meant to be used to debug package build failures and
> not used for anything else, so it is much preferred a 'push' scenario
> where developers push the code to porterboxes, rather than 'pull',
> being `apt-get source` the unique exception to that unwritten policy.

That concern seems to be related to #790093 and the presence of dgit
at all, rather than the Depends on git-buildpackage ?

> So developers would like to use `dgit push` from porterboxes, however
> getting that functionality also opens a can of worms, allowing for
> pulls as well.

This is probably out of context for this bug, but:

I think developers ought not to run `dgit push' on a porterbox because
that would involve exposing their private key (via gpg agent at least)
to the porterbox.  It would be better to run `dgit rpush' on their own
machine.  In practice do man people try to upload directly from a
porterbox anyway ?

I confess I haven't looked at what howtos etc. we provide to porters.

Maybe we should have a `how to be a porter' guide which covers finding
a machine, proper gitish source code management, BTS interaction, etc.
(That would I think inevitably result in advising the user to run
`dgit clone' on the porterbox for the same reasons that in a legacy
source-package-based workflow they would say `apt source'.  Hence the
desire to fix #790093.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#906317: dgit: consider demoting git-buildpackage to recommends

[Hector Oron]

Hello,

Missatge de Ian Jackson  del dia dv.,
5 d’oct. 2018 a les 14:50:
> Ian Jackson writes ("Re: Bug#906317: dgit: consider demoting git-buildpackage 
> to recommends"):
> > So I'm inclined to think that the subset of dgit's functionality which
> > is useable without gbp pq is too small for your use case (and too
> > small to make it sensible to demote this depends).  But I'm happy to
> > talk about it some more.
> ...
> > What is the concern with git-buildpackage ?  I understand that it's a
> > big piece of software but it contains many important tools for
> > managing many styles of Debian packaging git branch.  I wasn't aware
> > that it had significant functionality of a kind that would be
> > undesirable on a porterbox.

As I understood, DSA team had some concerns for security reasons since
porterboxes are meant to be used to debug package build failures and
not used for anything else, so it is much preferred a 'push' scenario
where developers push the code to porterboxes, rather than 'pull',
being `apt-get source` the unique exception to that unwritten policy.
So developers would like to use `dgit push` from porterboxes, however
getting that functionality also opens a can of worms, allowing for
pulls as well.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#910370: [mutter] mutter/gnome-shell 3.30.0 crashed when using touchscreen and wacom pen

[Christian Engwer]

Package: mutter
Version: 3.30.0-1
Severity: normal
Tags: patch

--- Please enter the report below this line. ---

mutter 3.30.0 contains a bug which causes gnome-shell to crash, when
touching the touchscreen and using the wacom at the same time.

Please see the following bugs reports at gnome and ubuntu for
reference:
 * https://gitlab.gnome.org/GNOME/mutter/issues/294
 * https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1788483

There is a patch available, which is part of mutter 3.30.1:
 * 
https://gitlab.gnome.org/GNOME/mutter/commit/a3d9f987c8303550bc740cba4645c8fba161c7fb.diff

It would be highly appreciated if you could include this patch for the
3.30.0 package or update to 3.30.1. The patch applies without problems
to 3.30.0. For convinience I also attached the patch to this bug
report.

Best
Christian

--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-1-amd64

Debian Release: buster/sid
  990 testing www.deb-multimedia.org 
  990 testing deb.debian.org 
  500 unstabledeb.debian.org 
  500 stable-updates  ftp.de.debian.org 
  500 stable  www.deb-multimedia.org 
  500 stable  security.debian.org 
  500 stable  repo.skype.com 
  500 stable  packages.microsoft.com 
  500 stable  linux.teamviewer.com 
  500 stable  ftp.de.debian.org 
  500 stable  dl.google.com 

--- Package information. ---
Depends   (Version) | Installed
===-+-==
gnome-settings-daemon   | 3.30.0-1
gsettings-desktop-schemas   (>= 3.21.4) | 3.28.1-1
mutter-common (>= 3.30.0-1) | 3.30.0-1
zenity  | 3.28.1-1
libc6  (>= 2.4) | 
libglib2.0-0(>= 2.57.2) | 
libmutter-3-0   (>= 3.28.2) | 
libx11-6| 
libxcomposite1 (>= 1:0.3-1) | 


Package's Recommends field is empty.

Suggests (Version) | Installed
==-+-==
gnome-control-center (>= 1:3.25.2) | 1:3.28.2-1
xdg-user-dirs  | 0.17-1
diff --git a/src/backends/x11/meta-input-settings-x11.c b/src/backends/x11/meta-input-settings-x11.c
index 14a199e7e95b126daf70558b244145567dd4f257..cfcdf2ece000e3df9ff361eace012840173f35f1 100644
--- a/src/backends/x11/meta-input-settings-x11.c
+++ b/src/backends/x11/meta-input-settings-x11.c
@@ -782,6 +782,7 @@ meta_input_settings_x11_set_stylus_button_map (MetaInputSettings  *setti
 return;
 
   /* Grab the puke bucket! */
+  meta_x11_error_trap_push (display->x11_display);
   xdev = device_ensure_xdevice (device);
   if (xdev)
 {

Bug#790093: No TOFU for git server host key

[Hector Oron]

Hello Ian,

Missatge de Ian Jackson  del dia dv.,
5 d’oct. 2018 a les 14:51:
>
> Ian Jackson writes ("No TOFU for git server host key"):
> > I think now would be a good time to look at #790093 again.  Would
> > anyone from the DSA team with the requisite TLS knowledge be available
> > to get together with me to sketch out a solution ?
>
> Ping ?
>
> I think we are nearing the end of our opportunity to improve this in
> buster.

Apologies for not replying earlier, but I have no idea, I think it'd
be best if you drop by #debian-admin IRC channel and ask there for
support or email dsa mailing list about it.

Regards

-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#910273: severity of 910273 is important

[Olivier Berger]

severity 910273 important
thanks

I wasn't quite sure, but the impact is quite nasty, so raising severity
in the hope someone more knowledgable has hints on the likeliness it may
happen to anyone else in the next stable...

Best regards,

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#827310: xul-ext-pwdhash from stable is not compatible to firefox-esr and gets disabled

[Michal Politowski]

Package: xul-ext-pwdhash
Version: 1.7.4-1
Followup-For: Bug #827310

There appears to exist a webextension version 2.0 of PwdHash,
which should work with current Firefox.

https://addons.mozilla.org/en-GB/firefox/addon/pwdhash/
https://github.com/pwdhash/pwdhash-webextension

-- 
Michał Politowski

Bug#910369: mk-build-deps: please deal sane with packages without build-deps

[Joost van Baal-Ilić]

Package: devscripts
Version: 2.18.6
Severity: minor
Tags: patch

Hi,

Running mk-build-deps for a package without Build-Depends or
Build-Depends-Indep fields in its control file, here leads to mk-build-deps
exiting non-succesfully and printing

 mk-build-deps: Unable to find build-deps for uruk

.  I'd expect it to generate a uruk-build-deps_20181005-1_all.deb with just
build-essential:amd64 as Depends and exit succesfully.  Printing a warning
it is doing just that would be useful.

This trivial patch for mk-build-deps.pl as in git today does this:

---


--- mk-build-deps.pl,orig   2018-10-05 14:58:12.457780789 +0200
+++ mk-build-deps.pl2018-10-05 15:01:27.049531850 +0200
@@ -306,7 +306,7 @@
 $build_conflicts .= $conflict_indep;
 }
 
-die "$progname: Unable to find build-deps for $ctrl->{$name}\n"
+warn "$progname: $ctrl->{$name} has no build-deps\n"
   unless $build_deps;
 
 if (exists $ctrl->{Version}) {


---

Thanks, Bye,

Joost



signature.asc
Description: Digital signature

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Ian Jackson]

Sam Hartman writes ("Bug#904302: Whether vendor-specific patch series should be 
permitted in the archive [and 1 more messages]"):
> So imagine that Ubuntu and several other downstreams care more about
> security and hardening than they do about backward compatibility and
> they choose to change a number of gcc and other tool defaults in support
> of that.  I realize my example is not entirely hypothetical, but I want
> to emphasize I have not researched to get all the details right, because
> it doesn't matter.
> 
> Especially if multiple downstreams or individual users who build from
> source might want the change, I think carrying the delta in  the Debian
> source package can be valuable.  It needs to be balanced against a lot
> of other concerns.

I agree that carrying a switch-on-able delta in the Debian package
would be a good thing there.  So, the meat of the change should
definitely go to Debian or maybe even to upstream as a
--with-extra-hardening configure option or some such.

This should be enabled via DEB_BUILD_OPTIONS, or a commented-out line
in the rules file, or by reading /etc/compilers/hardening-enabled at
build- or runtime, or something.  Not by looking at `the vendor'.

A scenario why this is needed can be seen from this scenario:

Suppose someone wants to try to maintain a distro which is like
Debian, but which takes some subset of packages from Raspbian.

The obvious way to do this is to import most packages from Debian and
the other packages from Raspbian, and to fix up the bugs which occur
at the interface.

If packages in Debian and Raspbian use dpkg-vendor --is raspbian to
decide whether to do the Raspbian thing, then there is no way to make
this work because there is no correct answer: the answer to whether a
package should do the Raspbian thing depends not only on which distro
we are building or running on, but on which package it is.

In practice if I were maintaining that distro I would be tempted do
some kind of hideous hack to make the output of dpkg-vendor depend on
the name of package we were building.  Because how else will I do it ?
Playing whack-a-mole with dpkg-vendor calls would be impractical.

If the Raspbian-specific features are enabled by carrying a changed
source package in Raspbian, then things will mostly DTRT and generally
problems will occur only when the delta-enablement is done via some
kind of indirection, and the indirection messily crosses the `cutoff'
between the Raspbian-originated and Debian-originated packages.

Ie I only have to manually fix the problems that irreducible, not ones
introduced by ill-advised calls to dpkg-vendor.

> And yes, in many cases dgit is the answer.  That said, if I were
> maintaining the same package both for Debian and for the downstream I
> work on, I might well value having a single source tree enough to use
> dpkg-vendor or lsb-release or something to switch.

In that case, that is convenient for you but it is wrong for your
downstreams and users.  We should be discouraging such tradeoffs.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#910237: googletest breaks mathicgb autopkgtest: invalid cast

[Paul Gevers]

Control: tags -1 ftbfs
Control: severity -1 serious
Control: retitle -1 googletest causes mathicgb to FTBFS: invalid cast

On 05-10-18 05:04, Steve Robbins wrote:
>> Currently this regression is contributing to the delay of the migration
>> of googletest to testing [1]. Due to the nature of this issue, I filed
>> this bug report against both packages. Can you please investigate the
>> situation and reassign the bug to the right package? If needed, please
>> change the bug's severity.
> 
> I had a look, but it's over my head.  Suggest to file bug upstream.

Which one? And by who?

Anyways, mathicgb now FTBFS on the reproducibility infrastructure with
the same message (or at least one close to it), hence raising severity.

Paul



signature.asc
Description: OpenPGP digital signature