Bug#909818: firefox: Web Content is eating nearly 100% CPU, several of them

[Norbert Preining]

Package: firefox
Version: 62.0.2-1
Severity: grave
Justification: renders package unusable

Since some recent update (within the last week) firefox is behaving
completely maniac on one of my computers. I have already removed
all of ~/.mozilla, started firefox with 
MOZILLA_DISABLE_PLUGINS=1 firefox
no extensions installed, all clean slate. Still, even the most simple
pages don't load. The typical output of top is:
  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
 8666 norbert   20   0 1617680 216316 101096 R  70.4   1.3   2:38.40 Web Content
 8855 norbert   20   0 1509408 147020  69056 R  70.1   0.9   1:18.98 Web Content
 8573 norbert   20   0 1637532 227256 105332 R  67.1   1.4   2:39.35 Web Content
 8520 norbert   20   0 2010728 265448 145644 D  42.9   1.6   1:16.82 firefox

As said, removing all extensions, plugins, everything and still the
browser behaves completely crazy.

What else then fully removing .mozilla and starting without plugins can
be done to get it back? It doesn't crash, just eats all the CPU and
doesn't display anything.

Thanks

Norbert

-- Package-specific info:


-- Addons package information

-- 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.10 (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 firefox depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.1-1
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.15.12-1
ii  libcairo2 1.15.12-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.1-1
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-7
ii  libgdk-pixbuf2.0-02.38.0+dfsg-6
ii  libglib2.0-0  2.58.1-2
ii  libgtk-3-03.24.0-3
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.39-1
ii  libpango-1.0-01.42.4-3
ii  libsqlite3-0  3.25.2-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-7
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.6-1
ii  libx11-xcb1   2:1.6.6-1
ii  libxcb-shm0   1.13-3
ii  libxcb1   1.13-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox recommends:
ii  libavcodec-extra57  7:3.4.3-1
ii  libavcodec587:4.0.2-2

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-5
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-6
ii  libgssapi-krb5-2   1.16-2
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.2-2

-- no debconf information

Bug#909809: openshot-qt: Please update to 2.4.3

[Dr. Tobias Quathamer]

Am 29. September 2018 01:39:39 MESZ schrieb Jeremy Bicha :
>Source: openshot-qt
>Version: 2.4.2-+dfsg1-1
>Severity: wishlist
>
>openshot 2.4.3 was recently released:
>
>https://www.openshot.org/blog/2018/09/22/openshot-243-released-animated-masks-language-improvements-improved-stability-and-more/
>
>Thanks,
>Jeremy Bicha

Hi,

I'm currently on vacation, it'll take about two to three weeks for the next 
upload.

Regards,
Tobias

Bug#909816: dependency issues - enigmail : Depends: thunderbird (>= 1:52.0) but it is not going to be installed or

[Patrick Schleizer]

Package: enigmail
Severity: grave
X-Debbugs-CC: whonix-de...@whonix.org

Happening on Debian stretch.

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

The following packages have unmet dependencies:
 enigmail : Depends: thunderbird (>= 1:52.0) but it is not going to be
installed or
 icedove (>= 1:52.0)
E: Unable to correct problems, you have held broken packages.

Bug#909817: gem: baseline violation on i386

[Adrian Bunk]

Source: gem
Version: 1:0.92.3-2
Severity: serious

MMX is not part of the i386 baseline.

Bug#909815: pd-readanysf FTBFS with puredata 0.49.0

[Adrian Bunk]

Source: pd-readanysf
Version: 0.43-2
Severity: serious
Tags: ftbfs patch

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

...
src/readanysf~.cpp: In function 'void m_open(t_readanysf*, t_symbol*)':
src/readanysf~.cpp:227:22: error: invalid conversion from 'const char*' to 
'char*' [-fpermissive]
  x->rm->openFile( s->s_name, 0, x->num_frames_in_fifo, 
x->num_samples_per_frame );
   ~~~^~
In file included from src/readanysf~.cpp:35:
src/ReadMedia.h:59:25: note:   initializing argument 1 of 'void 
ReadMedia::openFile(char*, int, int, int)'
   void openFile( char * filename, int vfifosize, int afifosize, int 
samples_per_frame);
  ~~~^~~~
make[2]: *** [Makefile:54: pd_linux] Error 1


Fix is attached.
Description: The first parameter of ReadMedia::openFile() should be const
 Fixes FTBFS with puredata 0.49.0.
Author: Adrian Bunk 

--- pd-readanysf-0.43.orig/src/ReadMedia.cpp
+++ pd-readanysf-0.43/src/ReadMedia.cpp
@@ -369,7 +369,7 @@ bool ReadMedia::quitAVThreads() {
return b;
 }
 
-void ReadMedia::openFile( char * fn, int vsize, int asize, int spf) {
+void ReadMedia::openFile(const char * fn, int vsize, int asize, int spf) {
lockState();
/*
if (  strcmp(m_filename, fn) == 0  && m_state == STATE_READY) {
--- pd-readanysf-0.43.orig/src/ReadMedia.h
+++ pd-readanysf-0.43/src/ReadMedia.h
@@ -56,7 +56,7 @@ class ReadMedia  {
ReadMedia();
~ReadMedia();
 
-   void openFile( char * filename, int vfifosize, int afifosize, 
int samples_per_frame);
+   void openFile(const char * filename, int vfifosize, int 
afifosize, int samples_per_frame);
 
int decodeAudio( gavl_audio_frame_t *af);
int decodeVideo( gavl_video_frame_t *vf);

Bug#909814: r-cran-afex: autopkgtest regression

[Paul Gevers]

Source: r-cran-afex
Version: 0.22-1-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of r-cran-afex the autopkgtest of r-cran-afex fails
in testing when that autopkgtest is run with the binary packages of
r-cran-afex from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
r-cran-afexfrom testing0.22-1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Is this bug
898441 [0] over again?

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/898441
[1] https://qa.debian.org/excuses.php?package=r-cran-afex

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-afex/1070145/log.gz

autopkgtest [04:33:46]: test run-unit-test: [---
Loading required package: lme4
Loading required package: Matrix

Welcome to afex. For support visit: http://afex.singmann.science/
- Functions for ANOVAs: aov_car(), aov_ez(), and aov_4()
- Methods for calculating p-values with mixed(): 'KR', 'S', 'LRT', and 'PB'
- 'afex_aov' and 'mixed' objects can be passed to emmeans() for
follow-up tests
- NEWS: library('emmeans') now needs to be called explicitly!
- Get and set global package options with: afex_options()
- Set orthogonal sum-to-zero contrasts globally: set_sum_contrasts()
- For example analyses see: browseVignettes("afex")


Attaching package: 'afex'

The following object is masked from 'package:lme4':

lmer

Error: testthat unit tests failed
Execution halted
autopkgtest [04:34:58]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#908438: Info received (Bug#908438: cubietruck wifi reversion)

[Joey Hess]

Tried with a different cubietruck and it did not have this problem.

Also, 4.14 failed on the cubietruck that I had been using, and I think
it was the same failure I was seeing with the newer kernel there.

So, I think this may be a case of somehow failing hardware on my
cubietruck.

Here it is working on the new cubietruck with 4.17.0:

Jun 22 07:11:53 honeybee kernel: brcmfmac: brcmf_fw_alloc_request: using 
brcm/brcmfmac43362-sdio for chip BCM43362/1
Jun 22 07:11:53 honeybee kernel: usbcore: registered new interface driver 
brcmfmac
Jun 22 07:11:53 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading 
firmware brcm/brcmfmac43362-sdio.bin
Jun 22 07:11:53 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading 
firmware brcm/brcmfmac43362-sdio.txt
Jun 22 07:11:53 honeybee kernel: brcmfmac: brcmf_fw_alloc_request: using 
brcm/brcmfmac43362-sdio for chip BCM43362/1
Jun 22 07:11:53 honeybee kernel: brcmfmac mmc1:0001:1: firmware: failed to load 
brcm/brcmfmac43362-sdio.clm_blob (-2)
Jun 22 07:11:53 honeybee kernel: brcmfmac mmc1:0001:1: Direct firmware load for 
brcm/brcmfmac43362-sdio.clm_blob failed with error -2
Jun 22 07:11:53 honeybee kernel: brcmfmac: brcmf_c_process_clm_blob: no 
clm_blob available (err=-2), device may have limited channels available
Jun 22 07:11:53 honeybee kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware: 
BCM43362/1 wl0: Oct 23 2017 10:33:17 version 5.90.240 FWID 01-0

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#909813: rr FTBFS with kernel 4.18 headers

[Adrian Bunk]

Source: rr
Version: 5.2.0-2
Severity: serious
Tags: ftbfs

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

...
/build/1st/rr-5.2.0/src/test/keyctl.c: In function 'main':
/build/1st/rr-5.2.0/src/test/keyctl.c:44:38: error: 'struct keyctl_dh_params' 
has no member named 'private'; did you mean 'dh_private'?
   struct keyctl_dh_params params = {.private = private_key,
  ^~~
  dh_private
/usr/bin/cc -g -O2 -ffile-prefix-map=/build/1st/rr-5.2.0=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -msse2 -D__MMX__ -D__SSE__ -D__SSE2__ -D__USE_LARGEFILE64 
-pthread -g3 -Wstrict-prototypes -std=gnu11-Wl,-z,relro -Wl,-z,now 
CMakeFiles/kcmp.dir/src/test/kcmp.c.o  -o bin/kcmp -lrt -ldl 
make[3]: *** [CMakeFiles/keyctl.dir/build.make:66: 
CMakeFiles/keyctl.dir/src/test/keyctl.c.o] Error 1

Bug#909812: python3-autopep8: Please provide /usr/bin/autopep8 in this package

[Zhang Jingqiang]

Package: python3-autopep8
Version: 1.4-1
Severity: wishlist

Dear Maintainer,

Maybe it's time to have python-autopep8 recommends python3-autopep8,
but not let python3 developers pull in python2 packages.

Thanks

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

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

Versions of packages python3-autopep8 depends on:
ii  python33.6.6-1
ii  python3-pep8   1.7.1-1
ii  python3-pkg-resources  40.2.0-1
ii  python3-pycodestyle2.4.0-2

Versions of packages python3-autopep8 recommends:
pn  python-autopep8  

python3-autopep8 suggests no packages.

-- no debconf information

Bug#909513: mutt-alias-el: Please obey "nodoc" build profile

[Nicholas D Steeves]

Control: tag -1 +pending
Hi Chris,

On Mon, Sep 24, 2018 at 05:55:16PM +0100, Chris Lamb wrote:
> Source: mutt-alias-el
> Version: 1.5-1
> Severity: wishlist
> X-Debbugs-CC: Nicholas D Steeves , 
> ftpmas...@debian.org
> 
> Hi,
> 
> I just ACCEPTed mutt-alias-el from NEW but was wondering if you could
> ensure "nodoc" is obeyed:

I packaged this one before you first asked me to support "nodoc".
Fixed in git, along with some other classes of things you've asked me
to fix in the past.

Thank you for pushing for excellence,
Nicholas


signature.asc
Description: PGP signature

Bug#907840: emacs-goodies-el: where are projects.el and ff-paths.el maintained?

[Nicholas D Steeves]

On Thu, Sep 27, 2018 at 01:01:39PM -0400, Peter S Galbraith wrote:
> BTW, sorry for the delay... I was on vacation in Europe and just got back.
> -- 
> Peter

No worries, I hope you had a wonderful vacation!


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#907840: emacs-goodies-el: where are projects.el and ff-paths.el maintained?

[Nicholas D Steeves]

On Thu, Sep 27, 2018 at 01:01:01PM -0400, Peter S Galbraith wrote:
> Nicholas D Steeves  wrote:
> 
> > Package: emacs-goodies-el
> > Version: 40.1
> > Severity: normal
> > 
> > Hi Peter,
> > 
> > We've just about (98%) finished transitioning emacs-goodies-el to a
> > set of elpafied packages. 
> 
> Congratulations!

Thank you :-)

> >I've had trouble finding an upstream source
> > for projects.el and ff-paths.el and David indicated that you might be
> > the upstream maintainer of these.  We're looking for something like a
> > release tarball or a project in VCS.
> 
> I wrote ff-paths.el a long time ago and "adopted" projects.el when it's
> author died.  There is no release tar ball as I was just inserting it in
> emacs-goodies-el myself.

Thank you for adopting that projects.el at that time :-) While they're
not technical issues, a lot of the effort I'm putting into
emacs-goodies-el is to try to recuperate all of the man-hours that
have been put into this package.  It's a tricky dance to decide
whether to maximally honour someone's work or to migrate to something
newer and more popular...

> It's probable safe to kill off projects.el and I can look at ff-paths.el
> to see if it still works well.

Here are the alternatives to continuing maintenance of projects.el
that I'm aware of:

The simple one:
  https://github.com/jorgenschaefer/project-el

The comprehensive one (already in Debian):
  https://github.com/bbatsov/projectile

If we drop projects.el I'd like to mark it as "transitioned" and
recommend one of these (probably projectile).  Have you used it, would
you recommend it as a replacement, and would you like your name to
appear next to the recommendation in goodies' README.Debian?

As for ff-paths.el, I've found an upstream recommendation to
transition to the GNU Emacs built-in ffap.el:
  https://github.com/emacsmirror/ff-paths/blob/master/ff-paths.el#L66

Other than that there are packages such as find-file-in-project,
counsel-ag (uses silversearcher-ag), and many others.

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#909811: RFS: muttrc-mode-el/1.2+git20180915.aa1601a-1 [previously part of emacs-goodies-el]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Hi Chris, and Dear mentors,

I am looking for a sponsor for my package "muttrc-mode-el".  I've
marked this bug as severity normal because this mode was previously
provided by bin:emacs-goodies-el.  Including this one, three packages
remain, but the other two might be dropped.

This package used to be maintained exclusively in
src:emacs-goodies-el; other than that, it was an emacswiki
pseudo-maintained package.  I pruned our source and prepared it for
inclusion into the Neomutt project.  I now have commit access to that
project and plan to tag a proper 1.2.1 or 1.3 release after making the
changes necessary to provide an upstream ELPA package that doesn't
depend on dh-elpa magic.  At that time the watch file will begin to
work as expected.

Package name: muttrc-mode-el
Version : 1.2+git20180915.aa1601a-1
Upstream Author : Laurent Pelecq 
URL : https://github.com/neomutt/muttrc-mode-el
License : GPL-2+
Section : lisp

It builds this binary package:

  elpa-muttrc-mode - Emacs major mode for editing muttrc

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

  https://mentors.debian.net/package/muttrc-mode-el

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/muttrc-mode-el/muttrc-mode-el_1.2+git20180915.aa1601a-1.dsc

Alternatively, download with git:

  git clone https://salsa.debian.org/emacsen-team/muttrc-mode-el
  cd muttrc-mode-el
  # either use the upstream/1.2+git20180915.aa1601a tag to get the orig tarball
  # or
  # git deborig

Regards,
Nicholas

Bug#909810: Refusing to sign with short key ID '01aa4a64'!

[Steve Langasek]

Package: devscripts
Version: 2.18.2

$ debsign -k01aa4a64 [...].changes
Refusing to sign with short key ID '01aa4a64'!
$ echo $?
1
$

Seriously?

  [ Chris Lamb ]
  * debsign:
+ To prevent collision attacks, refuse to sign with short key IDs (eg.
  0xCAFEBABE) and warn when not using full GPG fingerprint.  MR: !1

What kind of collision attack involves injecting a PRIVATE KEY into my gpg
keyring with the same short ID as the one I use for signing?  If someone has
write access to my private gpg keyring, I can think of a hundred other ways
they could exploit that which don't involve pushing a fake private key to
me, can't you?

So this provides no security benefit, and is hostile to the user.  I
memorize short IDs, and I use them, safely, with debsign -k when sponsoring
uploads.  I am not going to memorize long key IDs in response to this UX
change; this is just going to make sponsorship more of a hassle for no
reason.

devscripts should not second-guess gpg itself for what should be considered
a valid key identifier.

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


signature.asc
Description: PGP signature

Bug#909809: openshot-qt: Please update to 2.4.3

[Jeremy Bicha]

Source: openshot-qt
Version: 2.4.2-+dfsg1-1
Severity: wishlist

openshot 2.4.3 was recently released:

https://www.openshot.org/blog/2018/09/22/openshot-243-released-animated-masks-language-improvements-improved-stability-and-more/

Thanks,
Jeremy Bicha

Bug#906429: systemd: Please raise timeout for tests (for riscv64)

[Manuel A. Fernandez Montecelo]

Hi,

2018-09-04 22:44 GMT+02:00 Michael Biebl :
> On Fri, 17 Aug 2018 23:07:39 +0200 "Manuel A. Fernandez Montecelo"
>  wrote:
>
>> So perhaps debian/rules should be changed to use "meson test" instead,
>> as Meson upstream recommended, and so we can pass on the "-t 10" for
>> riscv64.
>
> I would prefer this approach
>
> Ideally this would be split into two commits:
> 1/ switching the existing ninja test to meson test
> 2/ adding the multiplier (for riscv64 alone or generally)
>
> Would be awesome if you can create a MR on salsa for that.

Submitted merge request:
https://salsa.debian.org/systemd-team/systemd/merge_requests/17

Not tested, but will do during the weekend and will report back.

Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#909808: compiz: Compiz started crashing 1-2 times a day

[Горбешко Богдан]

Package: compiz
Version: 1:0.9.13.1+18.04.20180302-1
Severity: normal

Dear Maintainer,

as the package wasn't upgraded for a half of year, looks like this is caused
with some external factors. Here is a backtrace I catched with gdb:

#0  0x77d45536 in CompRect::operator==(CompRect const&) const () at
/usr/lib/x86_64-linux-gnu/libcompiz_core.so.ABI-20180221
#1  0x77d45569 in CompRect::operator!=(CompRect const&) const () at
/usr/lib/x86_64-linux-gnu/libcompiz_core.so.ABI-20180221
#2  0x7fffdd370846 in
PolygonAnim::addGeometry(std::vector > const&, CompRegion const&, CompRegion
const&, unsigned int, unsigned int) () at /usr/lib/x86_64-linux-
gnu/compiz/libanimationaddon.so
#3  0x7fffebdcabdd in
GLWindow::glAddGeometry(std::vector > const&, CompRegion const&, CompRegion
const&, unsigned int, unsigned int) () at /usr/lib/x86_64-linux-
gnu/compiz/libopengl.so
#4  0x7fffebdcb9e3 in GLWindow::glDraw(GLMatrix const&, 
GLWindowPaintAttrib

const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#5  0x7fffe4e017d7 in DecorWindow::glDraw(GLMatrix const&,
GLWindowPaintAttrib const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libdecor.so
#6  0x7fffebdcba72 in GLWindow::glDraw(GLMatrix const&, 
GLWindowPaintAttrib

const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#7  0x7fffdde67fc5 in WallpaperWindow::glDraw(GLMatrix const&,
GLWindowPaintAttrib const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libwallpaper.so
#8  0x7fffebdcba72 in GLWindow::glDraw(GLMatrix const&, 
GLWindowPaintAttrib

const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#9  0x7fffdd5c2b39 in PrivateAnimWindow::glPaint(GLWindowPaintAttrib
const&, GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libanimation.so
#10 0x7fffebdcbc8e in GLWindow::glPaint(GLWindowPaintAttrib const&,
GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#11 0x7fffdc44f597 in FadeWindow::glPaint(GLWindowPaintAttrib const&,
GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libfade.so
#12 0x7fffebdcbc8e in GLWindow::glPaint(GLWindowPaintAttrib const&,
GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#13 0x7fffdc0233f9 in PrivateCubeWindow::glPaint(GLWindowPaintAttrib
const&, GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libcube.so
#14 0x7fffebdcbc8e in GLWindow::glPaint(GLWindowPaintAttrib const&,
GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#15 0x7fffebdcc18e in PrivateGLScreen::paintOutputRegion(GLMatrix 
const&,

CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#16 0x7fffebdcce79 in GLScreen::glPaintOutput(GLScreenPaintAttrib 
const&,

GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#17 0x7fffebdccdb5 in GLScreen::glPaintOutput(GLScreenPaintAttrib 
const&,

GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#18 0x7fffebdccdb5 in GLScreen::glPaintOutput(GLScreenPaintAttrib 
const&,

GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#19 0x7fffebdccdb5 in GLScreen::glPaintOutput(GLScreenPaintAttrib 
const&,

GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#20 0x7fffd7bd5455 in RotateScreen::glPaintOutput(GLScreenPaintAttrib
const&, GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/librotate.so
#21 0x7fffebdccdb5 in GLScreen::glPaintOutput(GLScreenPaintAttrib 
const&,

GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#22 0x7fffebdd2015 in
PrivateGLScreen::paintOutputs(std::__cxx11::list >&, unsigned int, CompRegion const&) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#23 0x7fffdc023b54 in
PrivateCubeScreen::paint(std::__cxx11::list >&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libcube.so
#24 0x700f2d2f in
CompositeScreen::paint(std::__cxx11::list >&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libcomposite.so
#25 0x700f5d62 in CompositeScreen::handlePaintTimeout() () at
/usr/lib/x86_64-linux-gnu/compiz/libcomposite.so
#26 0x77d438af in CompTimer::triggerCallback() () at
/usr/lib/x86_64-linux-gnu/libcompiz_core.so.ABI-20180221
#27 0x77d43996 in CompTimeoutSource::c

Bug#908463: [Pkg-privacy-maintainers] Bug#908463: torbrowser-launcher: Fails to start "Web Content" processes due to outdated AppArmor policy

[Antoine Beaupré]

On 2018-09-10 10:43:32, Antoine Beaupré wrote:
> On 2018-09-10 09:59:54, intrig...@debian.org wrote:
>> Package: torbrowser-launcher
>> Version: 0.2.9-4
>> Severity: serious
>> Tags: upstream fixed-upstream
>>
>> Hi,
>>
>> I've just pushed to commits to the upstream "develop" branch that fix
>> Tor Browser 8 for me. Without these, Tor Browser does start but with
>> e10s enabled, no tab will render as Firefox is not allowed to start
>> any "Web Content" process.
>
> I confirm this problem is real. It seems that as soon as anyone tries to
> upgrade torbrowser in Debian now it either fails with #908068 (before
> launcher upgrade) or this (after launcher upgrade).

For what it's worth, I was still getting that error with 0.2.9-5, but a
(forced) update to sid's 0.2.9-6 version fixes the issue on buster.

Thanks for all involved!

A.

-- 
Dr. King’s major assumption was that if you are nonviolent, if you
suffer, your opponent will see your suffering and will be moved to
change his heart. He only made one fallacious assumption: In order for
nonviolence to work, your opponent must have a conscience. The United
States has none.- Stokely Carmichael

Bug#909807: stretch-pu: package tomcat-native/1.2.12-2+deb9u1

[Markus Koschany]

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

Dear release team,

I would like to update tomcat-native in Stretch. It is currently
affected by CVE-2018-8019 and CVE-2018-8020. The security team marked
both issues as no-dsa.

Please find attached the debdiff.

Regards,

Markus
diff -Nru tomcat-native-1.2.12/debian/changelog 
tomcat-native-1.2.12/debian/changelog
--- tomcat-native-1.2.12/debian/changelog   2018-02-11 21:16:59.0 
+0100
+++ tomcat-native-1.2.12/debian/changelog   2018-09-28 23:51:20.0 
+0200
@@ -1,3 +1,15 @@
+tomcat-native (1.2.12-2+deb9u2) stretch; urgency=high
+
+  * Team upload.
+  * Fix CVE-2018-8019 and CVE-2018-8020.
+When using an OCSP responder Tomcat Native did not correctly handle invalid
+responses. This allowed for revoked client certificates to be incorrectly
+identified. It was therefore possible for users to authenticate with
+revoked certificates when using mutual TLS. Users not using OCSP checks are
+not affected by this vulnerability.
+
+ -- Markus Koschany   Fri, 28 Sep 2018 23:51:20 +0200
+
 tomcat-native (1.2.12-2+deb9u1) stretch-security; urgency=high
 
   * Non-maintainer upload by the LTS team.
diff -Nru tomcat-native-1.2.12/debian/patches/CVE-2018-8019.patch 
tomcat-native-1.2.12/debian/patches/CVE-2018-8019.patch
--- tomcat-native-1.2.12/debian/patches/CVE-2018-8019.patch 1970-01-01 
01:00:00.0 +0100
+++ tomcat-native-1.2.12/debian/patches/CVE-2018-8019.patch 2018-09-28 
23:51:20.0 +0200
@@ -0,0 +1,88 @@
+From: Markus Koschany 
+Date: Fri, 28 Sep 2018 22:59:06 +0200
+Subject: CVE-2018-8019
+
+Origin: https://svn.apache.org/r1832832
+---
+ native/src/sslutils.c | 38 +++---
+ 1 file changed, 23 insertions(+), 15 deletions(-)
+
+diff --git a/native/src/sslutils.c b/native/src/sslutils.c
+index 035c2b0..f7af4af 100644
+--- a/native/src/sslutils.c
 b/native/src/sslutils.c
+@@ -35,7 +35,7 @@ extern int WIN32_SSL_password_prompt(tcn_pass_cb_t *data);
+ #define ASN1_OID  0x06
+ #define ASN1_STRING   0x86
+ static int ssl_verify_OCSP(int ok, X509_STORE_CTX *ctx);
+-static int ssl_ocsp_request(X509 *cert, X509 *issuer);
++static int ssl_ocsp_request(X509 *cert, X509 *issuer, X509_STORE_CTX *ctx);
+ #endif
+ 
+ /*  _
+@@ -519,21 +519,22 @@ static int ssl_verify_OCSP(int ok, X509_STORE_CTX *ctx)
+ }
+ 
+ /* if we can't get the issuer, we cannot perform OCSP verification */
+-if (X509_STORE_CTX_get1_issuer(&issuer, ctx, cert) == 1 ) {
+-r = ssl_ocsp_request(cert, issuer);
+-if (r == OCSP_STATUS_REVOKED) {
++issuer = X509_STORE_CTX_get0_current_issuer(ctx);
++if (issuer != NULL) {
++r = ssl_ocsp_request(cert, issuer, ctx);
++switch (r) {
++case OCSP_STATUS_OK:
++X509_STORE_CTX_set_error(ctx, X509_V_OK);
++break;
++case OCSP_STATUS_REVOKED:
+ /* we set the error if we know that it is revoked */
+ X509_STORE_CTX_set_error(ctx, X509_V_ERR_CERT_REVOKED);
++break;
++case OCSP_STATUS_UNKNOWN:
++/* correct error code for application errors? */
++// X509_STORE_CTX_set_error(ctx, 
X509_V_ERR_APPLICATION_VERIFICATION);
++break;
+ }
+-else {
+-/* else we return unknown */
+-r = OCSP_STATUS_UNKNOWN;
+-}
+-X509_free(issuer); /* It appears that we  should free issuer since
+-* X509_STORE_CTX_get1_issuer() calls 
X509_OBJECT_up_ref_count()
+-* on the issuer object (unline 
X509_STORE_CTX_get_current_cert()
+-* that just returns the pointer
+-*/
+ }
+ return r;
+ }
+@@ -1038,7 +1039,7 @@ static int process_ocsp_response(OCSP_RESPONSE 
*ocsp_resp)
+ return o;
+ }
+ 
+-static int ssl_ocsp_request(X509 *cert, X509 *issuer)
++static int ssl_ocsp_request(X509 *cert, X509 *issuer, X509_STORE_CTX *ctx)
+ {
+ char **ocsp_urls = NULL;
+ int nid;
+@@ -1061,13 +1062,20 @@ static int ssl_ocsp_request(X509 *cert, X509 *issuer)
+the ocsp status. Otherwise, return OCSP_STATUS_UNKNOWN */
+ if (ocsp_urls != NULL) {
+ OCSP_RESPONSE *resp;
++int rv = OCSP_STATUS_UNKNOWN;
+ /* for the time being just check for the fist response .. a better
+approach is to iterate for all the possible ocsp urls */
+ resp = get_ocsp_response(cert, issuer, ocsp_urls[0]);
++if (resp != NULL) {
++rv = process_ocsp_response(resp);
++} else {
++/* correct error code for application errors? */
++X509_STORE_CTX_set_error(ctx, 
X509_V_ERR_APPLICATION_VERIFICATION);
++}
+ 
+ if (resp != NULL) {
+ apr_pool_destroy(p);
+

Bug#909577: hunspell-bg: Upgrade to fix encoding problem

[Mattia Rizzolo]

On Fri, Sep 28, 2018 at 11:33:01PM +0200, Rene Engelhard wrote:
> On Tue, Sep 25, 2018 at 04:33:40PM +0200, Pander wrote:
> > See also:
> > https://sourceforge.net/p/bgoffice/bugs/6/
> > https://bugs.documentfoundation.org/show_bug.cgi?id=117392
> 
> That was abandoned? Because "UTF-8 works now".
> 
> So what is the actual, still existing (in 6.1.1/.2) problem?

My reading is that currently (in 6.1.1, not sure about .2) the encoding
is still wrong like it was 2 years ago, but in upstream git or something
it was moved to UTF-8 that is correct.

I was thinking of just closing this bug (and its brother in launchpad)
with the first upstream version that included the move to UTF-8.


ICBW, in which case I urge the submitter to clarify what's the
situation.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#909577: hunspell-bg: Upgrade to fix encoding problem

[Rene Engelhard]

tag 909577 + moreinfo
thanks

Hi,

On Tue, Sep 25, 2018 at 04:33:40PM +0200, Pander wrote:
> Please, upgrade in order to fix an encoding problem, the incorrect
> encoding name was used. This has been fixed upstream.

And you are reporting this against 5.2.5 which is in stable. Of course
this fix didn't end up there since it it isn't critical. Or is it?

> See also:
> https://sourceforge.net/p/bgoffice/bugs/6/
> https://bugs.documentfoundation.org/show_bug.cgi?id=117392

That was abandoned? Because "UTF-8 works now".

So what is the actual, still existing (in 6.1.1/.2) problem?

Regards,

Rene

Bug#908438: cubietruck wifi reversion

[Joey Hess]

linux-image-4.18.0-1-armmp-lpae has the same problem.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#907258: Bug#907259: Bug#907258: Bug#907259: Bug#907258: Bug#907259: Bug#907258: Bug#907259: hiredis: New upstream "release" ?

[Tom Lee]

On Thu, Sep 27, 2018 at 2:21 AM Chris Lamb  wrote:

> Hi Tom,
>
> > Otherwise it should be fine aside from a few gripes from the pedantic
> > lintian checks.
>
> Hm, why don't you just fix these?


Time, mostly. Was expecting not to be available for a while, but had some
spare time today to wrap it up.

One outstanding lint check I'm not sure if I should be actioning yet:

P: hiredis source: debug-symbol-migration-possibly-complete
> --dbgsym-migration='libhiredis-dbg (line 37)
>

I should leave that one be until after this upload, right?


> Also, before I upload please could
> you address:
>
>  * Use compat level 11.
>
>  * Add  to the relevant build-dependencies.
>
>  * Drop unnecessary cruft (DEB_DESTDIR, "#export DH_VERBOSE=1" etc.
>etc.)
>
>
Should be all done.

Of note:

   - Haven't used the build profile stuff before, hopefully I'm doing it
   right.
   - I think dh_fixperms (or something else independent of the build) may
   be marking .pc/.cmake files under usr/lib, so had to work around that in
   override_dh_fixperms. Not sure if there's a better way.
   - No GPG signatures available upstream, so added a lintian override for
   that for now.

Cheers,
Tom
-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#594175: openssh-server: support generation of ssh host keys in init script

[Michael Prokop]

Hi!

Guido, sorry for not coming back to you earlier :(

* Guido Günther [Wed Sep 19, 2018 at 11:18:37AM +0200]:
> On Wed, Jan 10, 2018 at 10:36:51AM +0100, Guido Günther wrote:

> > Michael is grml working around this somehow? If so can you attach a
> > link?

Nowadays™ with systemd we use our own ssh.service, which looks
like that:

  
https://github.com/grml/grml-live/blob/8078724d5fa78f0b8fe0471b94368c58f204ee11/etc/grml/fai/config/files/etc/systemd/system/ssh.service/GRMLBASE

> I have moved things into a Debian package now:

> https://source.puri.sm/Librem5/gen-sshd-host-keys

> I'm wonder if we should upload this to Debian as a separate package
> given it only contains one script but since this is such a common thing
> it would be good if we'd have easy support.

Your gen-sshd-host-keys package LGTM and sounds like a good thing to
have in Debian, especially for all the derivatives.

regards,
-mika-


signature.asc
Description: Digital signature

Bug#908702: linux-image-4.18.0-1-amd64 prevents use of internet (more or les

[ghpy]

Dear maintainer,

~$ lspci
00:00.0 Host bridge: Intel Corporation Core Processor DMI (rev 11)
00:03.0 PCI bridge: Intel Corporation Core Processor PCI Express Root Port 1 
(rev 11)
00:05.0 PCI bridge: Intel Corporation Core Processor PCI Express Root Port 3 
(rev 11)
00:08.0 System peripheral: Intel Corporation Core Processor System Management 
Registers (rev 11)
00:08.1 System peripheral: Intel Corporation Core Processor Semaphore and 
Scratchpad Registers (rev 11)
00:08.2 System peripheral: Intel Corporation Core Processor System Control and 
Status Registers (rev 11)
00:08.3 System peripheral: Intel Corporation Core Processor Miscellaneous 
Registers (rev 11)
00:10.0 System peripheral: Intel Corporation Core Processor QPI Link (rev 11)
00:10.1 System peripheral: Intel Corporation Core Processor QPI Routing and 
Protocol Registers (rev 11)
00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 
Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High 
Definition Audio (rev 06)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 1 (rev 06)
00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 2 (rev 06)
00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 3 (rev 06)
00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 4 (rev 06)
00:1c.6 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 7 (rev 06)
00:1c.7 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 8 (rev 06)
00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 
Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation P55 Chipset LPC Interface Controller (rev 
06)
00:1f.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset 4 port 
SATA IDE Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller 
(rev 06)
00:1f.5 IDE interface: Intel Corporation 5 Series/3400 Series Chipset 2 port 
SATA IDE Controller (rev 06)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Redwood PRO [Radeon HD 5550/5570/5630/6510/6610/7570]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Redwood HDMI Audio 
[Radeon HD 5000 Series]
02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 
03)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 
PCI Express Gigabit Ethernet Controller (rev 03)
04:00.0 SATA controller: JMicron Technology Corp. JMB361 AHCI/IDE (rev 02)
04:00.1 IDE interface: JMicron Technology Corp. JMB361 AHCI/IDE (rev 02)
06:00.0 IDE interface: Marvell Technology Group Ltd. Device 914d (rev 10)
09:01.0 Communication controller: Conexant Systems, Inc. HSF 56k HSFi Modem 
(rev 01)
09:02.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet 
Adapter (rev 10)
3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture 
Generic Non-Core Registers (rev 04)
3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture 
System Address Decoder (rev 04)
3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 04)
3f:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 04)
3f:03.0 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller (rev 04)
3f:03.1 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller Target Address Decoder (rev 04)
3f:03.4 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller Test Registers (rev 04)
3f:04.0 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller Channel 0 Control Registers (rev 04)
3f:04.1 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller Channel 0 Address Registers (rev 04)
3f:04.2 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller Channel 0 Rank Registers (rev 04)
3f:04.3 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller Channel 0 Thermal Control Registers (rev 04)
3f:05.0 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller Channel 1 Control Registers (rev 04)
3f:05.1 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller Channel 1 Address Registers (rev 04)
3f:05.2 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller Channel 1 Rank Registers (rev 04)
3f:05.3 Host bridge: Intel Corporation Core Processor Integrated Memory 
Controller Channel 1 Thermal Control Registers (rev 04)

I will post the output of dmesg some other time this weekend, because I suppose 
it only makes sense when I am using kernel 4.18 which for obvious reasons I 
normally don't.

Regards
G. Heine

Bug#909806: libphonenumber: New upstream release 8.9.14

[Jeremy Bicha]

Source: libphonenumber
Version: 7.1.0-5
Severity: wishlist

libphonenumber has had many new releases in the past 3 years.

Please update your debian/watch file to track them.

https://github.com/googlei18n/libphonenumber/releases
https://github.com/googlei18n/libphonenumber/blob/master/release_notes.txt

Thanks,
Jeremy Bicha

Bug#909296: libical3: Enable GObject Introspection and Vala .vapi file generation

[Nicolas Mora]

Thanks for the MR, I guess I was too confident about the initial change
I made to close this issue.

The new package is named gir1.2-ical-3.0, shouldn't it be named
gir1.2-libical-3.0 ? I may be wrong though, I don't know the habits in
the other packages that have this feature.

Also, if the new package libical-doc only install files in
usr/share/gtk-doc/, I think I will also install some of the doc/ files
as well.

/Nicolas



signature.asc
Description: OpenPGP digital signature

Bug#904000: audacious: Opening URL fails

[Reiner Herrmann]

Control: found -1 3.7.2-1
Control: fixed -1 3.9-2

Tagging this with the version in stretch, as it was reported there.
I'm not able to reproduce it in unstable.


signature.asc
Description: PGP signature

Bug#909789: manpages-dev: stat(2) manpage on ENOENT for dangling symbolic links (broken links)

[Michael Kerrisk (man-opages)]

tags fixed-upstream
thanks

On 09/28/2018 01:38 PM, Alessandro Vesely wrote:

Package: manpages-dev
Version: 4.10-2
Severity: minor

Dear Maintainer,


Hello Ale,

Upstream maintainer here...


it seems to be a gotcha having stat(x, y) unexpectedly return -1 when x is a
broken link.  The stat(1) command works where stat(2) fails.  The obvious
solution is to use lstat.

It is difficult to fix this without ineffectually lengthening the text.
Perhaps, using the concept of unlinked file, which is valid for hard and soft
links alike, might help.  For example, the man page says:

ENOENT A component of pathname does not exist, or pathname is an empty string.

Alternatively, it could say:

ENOENT A component of pathname is unlinked (does not exist), or pathname is an
empty string.


Thanks for your report!

It's not merely a question of a broken symlink in the final pathname
component, which lstat() could address. ENOENT can also occur if any
component in the pathname is a dangling symbolic link. So I changed the
ENOENT text to:

   ENOENT A  component  of  pathname  does not exist or is a
  dangling symbolic link.

   ENOENT pathname is an empty string and AT_EMPTY_PATH  was
  not specified in flags.


Besides, the 1st paragraph in the NOTES section says "AT_NO_AUTOMOUNT fag".
Please substitute "AT_NO_AUTOMOUNT flag" lest someone smokes their unmounted
devices...


:-)

In fact, that text was fixed about a year ago, so you don't have quite
the most up-to-date pages :-).


Thanks for maintaining man pages


You are welcome!

Cheers,

Michael




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

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

Versions of packages manpages-dev depends on:
ii  manpages  4.10-2

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  jed-extra [man-browser]  2.5.7-2
ii  man-db [man-browser] 2.7.6.1-2

Bug#907674: xscreensaver: Please update to latest version 5.40

[Tormod Volden]

On Fri, Aug 31, 2018 at 10:36 AM Eduard Bloch wrote:
>
> I am reporting this as severity:normal because I would like to report a
> minor issue to upstream, but the upstream is known for the
> use-my-latest-version-from-yesterday-or-else policy.
>
> Therefore, please update the version to 5.40. Thank you.
>

Dear Eduard,

As you probably have noticed, 5.40 is in unstable and probably soon in testing.

However, if you want to report an issue directly upstream, you should
build and install the software from upstream's release tarball.

If you are using Debian's package, you should report the issue here in
the BTS, even if it is an "obvious" upstream issue. Often it comes out
the same, because upstream is sometimes following here.

Best regards,
Tormod

Bug#897774: infinipath-psm: ftbfs with GCC-8

[Reiner Herrmann]

Control: tags -1 + patch

The attached patch fixes the FTBFS with gcc 8.

Regards,
   Reiner
diff --git a/debian/patches/0003-gcc8.patch b/debian/patches/0003-gcc8.patch
new file mode 100644
index 000..b405d18
--- /dev/null
+++ b/debian/patches/0003-gcc8.patch
@@ -0,0 +1,29 @@
+Author: Reiner Herrmann 
+Description: Fix build with gcc 8
+ - psm_utils.c: reserve enough memory for both input strings and the fixed part
+ - psm_ep.c: e has sufficient space to copy including the NULL terminator,
+ which fixes a warning about truncation of the input string
+Bug-Debian: https://bugs.debian.org/897774
+
+--- a/psm_ep.c
 b/psm_ep.c
+@@ -1349,7 +1349,7 @@
+ 
+ b_new = (char *) devstr;
+ e = b_new + len;
+-strncpy(e, devstring, len-1);
++strncpy(e, devstring, len);
+ e[len-1] = '\0';
+ ee = e + len;
+ i = 0;
+--- a/psm_utils.c
 b/psm_utils.c
+@@ -955,7 +955,7 @@
+ 	union psmi_envvar_val env_fi;
+ 	char fvals_str[128];
+ 	char fname[128];
+-	char fdesc[256];
++	char fdesc[300];
+ 
+ 	snprintf(fvals_str, sizeof fvals_str - 1, "%d:%d:1", num, denom);
+ 	fvals_str[sizeof fvals_str - 1] = '\0';
diff --git a/debian/patches/series b/debian/patches/series
index c6d3224..cdf9028 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 0001-Fix-truncation-warnings-with-gcc7.patch
 0002-Include-sys-sysmacros.h-to-avoid-warning-about-minor.patch
+0003-gcc8.patch


signature.asc
Description: PGP signature

Bug#909076: ghostscript: ps2ascii crashes: Error: /typecheck in --.bind--

[Markus Koschany]

Hi,

Am 28.09.18 um 20:54 schrieb Salvatore Bonaccorso:
[...]
> So this would imply changed behaviour in a stable release, and thus
> need extra care to not break more (ps2ascii might not be widely used
> still).

Thanks for sharing this information. I agree that changed behavior in a
stable release is suboptimal but leaving the package vulnerable is not
desirable as well. At the moment I am in favor to apply those two
commits that were mentioned before because they seem to make a real
difference. Perhaps there will be other bug reports that will point us
to a complete fix in the future, and as you said ps2ascii is probably
not widely used, so the regression is apparently rather minor. If it
turns out differently, let's take a look again.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#909804: Excessive CPU usage at system startup

[Josh Triplett]

Package: gnome-software
Version: 3.28.2-1
Severity: grave

I don't know whether the bug here lies in gnome-software, packagekit, or
some combination of the two.

Every time I start my system, I see packagekit burning a huge amount of
CPU for a minute, and this affects the performance of the system until
it stops.

Corresponding to this, I see a large number of log messages like this:
Sep 28 12:24:38 s PackageKit[717]: search-file transaction /18520_ddabdebb from 
uid 1000 finished with success after 643ms
Sep 28 12:24:39 s PackageKit[717]: search-file transaction /18521_bbebdedd from 
uid 1000 finished with success after 301ms

On my most recent system boot, I see 167 such messages, spanning nearly
a minute worth of 100% CPU.

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

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

Versions of packages gnome-software depends on:
ii  appstream0.12.2-2
ii  apt-config-icons 0.12.2-2
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  gnome-software-common3.28.2-1
ii  gsettings-desktop-schemas3.28.1-1
ii  libappstream-glib8   0.7.12-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo21.15.12-1
ii  libfwupd21.1.2-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgnome-desktop-3-173.30.1-1
ii  libgspell-1-11.6.1-1
ii  libgtk-3-0   3.24.0-3
ii  libgtk3-perl 0.034-2
ii  libgudev-1.0-0   232-2
ii  libjson-glib-1.0-0   1.4.2-4
ii  libpackagekit-glib2-18   1.1.10-1
ii  libpolkit-gobject-1-00.105-21
ii  libsecret-1-00.18.6-3
ii  libsoup2.4-1 2.64.1-1
ii  packagekit   1.1.10-1
ii  software-properties-gtk  0.96.20.2-1

gnome-software recommends no packages.

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  fwupd  
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-limba
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#881506: xul-ext-gnome-keyring doesn't work with firefox >=57

[Moritz Mühlenhoff]

On Wed, Sep 26, 2018 at 02:27:00AM +, Ximin Luo wrote:
> Moritz Mühlenhoff:
> > On Tue, Dec 05, 2017 at 01:46:00AM +, Ximin Luo wrote:
> >> Control: severity -1 important
> >> Control: tags -1 + upstream
> >> Control: forwarded -1 
> >> https://github.com/swick/mozilla-gnome-keyring/issues/48
> >>
> >> Mozilla are being slow.
> >>
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=309807
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=106400
> > 
> > Given the pushback in the bugs listed above this seems unlikely
> > to be fixed in Firefox any time soon, so maybe let's drop
> > the Firefox and restrict to Thunderbird (if that is confirmed
> > to be still working fine with TB60)?
> > 
> 
> Pretty sure it doesn't work with TB60, I just upgraded myself and am no 
> longer using this extension.

Shall we remove it from the archive?

Cheers,
Moritz

Bug#909076: ghostscript: ps2ascii crashes: Error: /typecheck in --.bind--

[Mattia Rizzolo]

On Fri, Sep 28, 2018 at 08:54:24PM +0200, Salvatore Bonaccorso wrote:
> There is still the output changes produces, which might impact
> (build)-rdepends, so we might need to be extra careful here (although
> ps2ascii is possibly not widely used).

rather, I think very few software may be as annoying about their
dependencies output as diffoscope is.  And anyway it's only the
testsuite of diffoscope that it is.

> So this would imply changed behaviour in a stable release, and thus
> need extra care to not break more (ps2ascii might not be widely used
> still).

Diffoscope was later been updated to only check the output of ps2ascii
if the version reported was >= 9.21.
I think if that output change was to happen in a stable release and I
were asked to fix diffoscope, I'd just disable that one, rather the
going around asking dpkg what debian revision ghostscript has…

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#810583: libeigen3-doc: Navbar obscures documentation pages in HTML docs

[Anton Gladky]

fixed 810583 3.3.5-2
thanks

It looks like the bug is not more reproducible with the latest
version, available in the Debian.

Thus - closing the ticket

Cheers

Anton
Am So., 10. Jan. 2016 um 10:27 Uhr schrieb Kevin Murray :
>
> Hi Anton,
>
> On 09:48 10/01, Anton Gladky wrote:
> > Hi Kevin,
> >
> > as far as I can see [0] shows the same version which is
> > displayed on a local documentation, 3.2.92. The number
> > 3.2 will be changed on 3.3 only when a a stable 3.3 will be
> > released.
>
> Thanks for looking into this. That makes sense, now you mention it.
>
> Cheers,
> Kevin
>
> ---
> Kevin Murray
> 0xA4B4EE6A

Bug#909778: libsdl2-dev: SDL_config.h no longer in cflags provided by pkg-config/sdl2-config

[Adrian Bunk]

On Fri, Sep 28, 2018 at 12:47:28PM +, Hugh McMaster wrote:
> On Friday, 28 September 2018 5:09 PM, Simon McVittie wrote:
> > This is a regression caused by fixing #909740. Hugh McMaster correctly
> > pointed out that /usr/include/ is one of the default search
> > paths for headers. However, SDL_config.h is designed to be included as
> >  after -I/usr/include/SDL2, not as ,
> > according to the design documented in  > parallel.html="">
> > and popularized by packages like GLib and GTK+; so moving it to
> > /usr/include//SDL2 does not make it includable. How was the
> > patch in #909740 tested?
> 
> > If sdl2-config didn't exist, then this would be easy to fix by adding
> > -I/usr/include//SDL2 to the pkg-config file (similar to what
> > happens in GLib); but doing the same thing in sdl2-config would give it
> > per-architecture variation and make it non-co-installable, so that isn't
> > an option here.
> 
> The best solution is to drop sdl2-config... but, sadly, that is in an ideal
> world.

sdl2-config is not to blame.

> Patching pkg-config is definitely the way to go.
>...

No, it is definitely not the way to go.

It is wrong that you are doing this fragile manual moving at all.

The following fixes it properly:
- revert the override_dh_install change, and
- add --includedir=\$${prefix}/include/$(DEB_HOST_MULTIARCH) to confflags

Things just work when you are using the facilities provided by the build 
system, instead of adding hack after hack when working against the build
system.

And doing it the right way automatically does the right thing for both 
pkg-config and sdl2-config.

cu
Adrian

-- 

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

Bug#909803: freeipa-client: depends chrony should be downgraded to recommends

[Michael Stone]

Package: freeipa-client
Version: 4.7.0-1
Severity: normal

freeipa client does not technically require chrony (or, previously, ntp). The
ipa-client-install routine provides an option to not configure NTP, and the
ipa docs instruct that this option should be used if the administrator wants
to use a different NTP configuration. Therefore, the debian freeipa-client
should not depend on chrony. In particular, the current dependency will
potentially rip out a working ntp config and replace it with a potentially
non-working chrony config, for no benefit. Downgrading the dependency to a
recommends would still cover the common case, but permit more flexibility for
other cases.

Bug#908973: osinfo-db: New upstream release 201809020

[Guido Günther]

Hi,
On Fri, Sep 28, 2018 at 02:50:27PM -0400, Jeremy Bicha wrote:
> Control: retitle -1 osinfo-db: New upstream release 201809020
> 
> Hi, sorry to bother you again so soon. There's another new release
> with some Ubuntu iso fixes.
> 
> Since the bug was still open, I'm reusing the old bug number.
> 
> It looks like you are just releasing straight from git instead of
> using the git tags or tarballs?
> 
> https://gitlab.com/libosinfo/osinfo-db/tags
> https://releases.pagure.org/libosinfo/

Yept, releasing from tarballs is

 - harder in this case
 - usually outdated

so going from git is simpler.
 -- Guido

Bug#909076: ghostscript: ps2ascii crashes: Error: /typecheck in --.bind--

[Salvatore Bonaccorso]

Hi,

Futher tests and comparisons make me confident that with
cc746214644deacd5233a1453ce660573af09443 needed the output of stretch
aligns to the one produced in unstable's ghostscript (9.25~dfsg-2).

There is still the output changes produces, which might impact
(build)-rdepends, so we might need to be extra careful here (although
ps2ascii is possibly not widely used).

I try to make my point with the following example runs, all done with
the test1.ps (sha256sum:
7377c695e4b31e18bc37f84f9f63d511f0417240728924bc08f270fcc9ab67e2) from
diffoscope. test1.txt is generated running with the appropriate
version of ps2ascii and as well recording the sa256sum of it.

jessie: ghostscript/9.06~dfsg-2+deb8u8
test1.txt: sha256sum: 
e28d37c7a2e9014c7533667d2be03df483c9e401d3b691c19e8b2fae82a72a4f
>cut-cut-cut-cut-cut-cut-
>
>
>Today's date: February 28, 2016
>
>1
>cut-cut-cut-cut-cut-cut-

stretch: ghostscript/9.20~dfsg-1
test1.txt: sha256sum: 
e28d37c7a2e9014c7533667d2be03df483c9e401d3b691c19e8b2fae82a72a4f
>cut-cut-cut-cut-cut-cut-
>
>
>Today's date: February 28, 2016
>
>1
>cut-cut-cut-cut-cut-cut-

stretch: ghostscript/9.20~dfsg-3.2+deb9u2
test1.txt: sha256sum: 
e28d37c7a2e9014c7533667d2be03df483c9e401d3b691c19e8b2fae82a72a4f
>cut-cut-cut-cut-cut-cut-
>
>
>Today's date: February 28, 2016
>
>1
>cut-cut-cut-cut-cut-cut-

stretch: ghostscript/9.20~dfsg-3.2+deb9u5
test1.txt: sha256sum: none
This one is which caused this report, as it fails

stretch: ghostscript/9.20~dfsg-3.2+deb9u6
test1.txt: sha256sum: 
d12feab3e64550bc146d180931c9310a4f95dae9809a82ccce068ed0a2e64a8f
>cut-cut-cut-cut-cut-cut-
>Today’s date: February 28, 2016
>   1
>cut-cut-cut-cut-cut-cut-

sid: ghostscript/9.25~dfsg-2
test1.txt: sha256sum: 
d12feab3e64550bc146d180931c9310a4f95dae9809a82ccce068ed0a2e64a8f
>cut-cut-cut-cut-cut-cut-
>Today’s date: February 28, 2016
>   1
>cut-cut-cut-cut-cut-cut-

So this would imply changed behaviour in a stable release, and thus
need extra care to not break more (ps2ascii might not be widely used
still).

Regards,
Salvatore

Bug#908973: osinfo-db: New upstream release 201809020

[Jeremy Bicha]

Control: retitle -1 osinfo-db: New upstream release 201809020

Hi, sorry to bother you again so soon. There's another new release
with some Ubuntu iso fixes.

Since the bug was still open, I'm reusing the old bug number.

It looks like you are just releasing straight from git instead of
using the git tags or tarballs?

https://gitlab.com/libosinfo/osinfo-db/tags
https://releases.pagure.org/libosinfo/

Thanks,
Jeremy Bicha

Bug#857954: libdevmapper-dev: broken symlink: /usr/lib//libdevmapper-event-lvm2.so -> /lib//libdevmapper-event-lvm2.so.2.02

[Helmut Grohne]

Control: severity -1 important

On Thu, Nov 09, 2017 at 04:11:00PM +0100, Andreas Beckmann wrote:
> The broken symlink has returned:
> 
> 0m22.2s ERROR: FAIL: Broken symlinks:
>   /usr/lib/x86_64-linux-gnu/libdevmapper-event-lvm2.so -> 
> /lib/x86_64-linux-gnu/libdevmapper-event-lvm2.so.2.02

1. Yes, this symlink is still broken in version 2:1.02.145-4.1.
2. The issue August Karlstrom was seeing, is a different one.
   libdevmapper.so.1.02.1 is a different file. That's unrelated to the
   symlink Andreas reported and if this is still a problem, it should be
   reported separately.
3. The file referenced does exist in package dmeventd. However
   libdevmapper-dev does not Depends: dmeventd.

I see two potential solutions to this problem:
A. Add dmeventd to libdevmapper-dev's Depends.
B. Remove usr/lib/*/libdevmapper-event-lvm2.so from
   debian/libdevmapper-dev.install.

It's unclear to me which solution is to be preferred here.

In any case, I don't see that this violates the Debian policy in any
way. It certainly isn't nice, but why should it be rc? Downgrading.

Helmut

Bug#909802: poppler: CVE-2018-16646 denial-of-service via crafted file

[Markus Koschany]

Package: poppler
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for poppler.

CVE-2018-16646[0]:
| In Poppler 0.68.0, the Parser::getObj() function in Parser.cc may cause
| infinite recursion via a crafted file. A remote attacker can leverage
| this for a DoS attack.

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-16646
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16646

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#909801: Don't emit udevadm-called-without-guard if package depends on udev

[Chris Lamb]

tags 909801 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/40c3a4e4971648d771ae9baa10acd01dd490985e

  checks/scripts.desc  |  3 ++-
  checks/scripts.pm|  4 +++-
  debian/changelog |  3 +++
  .../debian/debian/control.in | 16 
  .../debian/debian/postinst   |  9 +
  t/tests/scripts-udevadm-called-without-guard-unrel/desc  |  5 +
  t/tests/scripts-udevadm-called-without-guard-unrel/tags  |  0
  7 files changed, 38 insertions(+), 2 deletions(-)


Regards,

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

Bug#876618: [Pkg-javascript-devel] Bug#876618: science.js build-depends on removed nodejs-legacy

[Bastien ROUCARIES]

Il

Le ven. 28 sept. 2018 à 07:27, Petter Reinholdtsen  a
écrit :

> Control: tags -1 + help upstream confirmed
>
> [Jérémy Lal]
> > Depending on nodejs-legacy was a serious bug in the first place.
> > Anyway (nodejs >= 6.11.2~) installs /usr/bin/node now.
>
> I had a look at this, and do not know how to fix it.  Replacing
> nodejs-legacy with nodejs in d/control is simple enough, but then the build
> fail like this:
>
> cat science.core.js science.lin.js science.stats.js >> science.v1.js
> uglifyjs < science.v1.js > science.v1.min.js
> node src/package.js > package.json
> (node:7549) [DEP0027] DeprecationWarning: util.puts is deprecated. Use
> console.log instead.
> rm science.stats.js science.lin.js science.core.js
> make[2]: Leaving directory '/home/pere/src/debian/science.js-debian'
> make[1]: Leaving directory '/home/pere/src/debian/science.js-debian'
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/home/pere/src/debian/science.js-debian'
> vows test/env-assert.js test/\*/\*-test.js
> module.js:549
> throw err;
> ^
>

Vow need to be updated or your pa ckage néed to dépend to node-glob

>
> Error: Cannot find module 'glob'
> at Function.Module._resolveFilename (module.js:547:15)
> at Function.Module._load (module.js:474:25)
> at Module.require (module.js:596:17)
> at require (internal/module.js:11:18)
> at Object. (/usr/lib/nodejs/vows/bin/vows:7:14)
> at Module._compile (module.js:652:30)
> at Object.Module._extensions..js (module.js:663:10)
> at Module.load (module.js:565:32)
> at tryModuleLoad (module.js:505:12)
> at Function.Module._load (module.js:497:3)
> make[1]: *** [debian/rules:17: override_dh_auto_test] Error 1
> make[1]: Leaving directory '/home/pere/src/debian/science.js-debian'
> make: *** [debian/rules:8: build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2
> debuild: fatal error at line 1152:
> dpkg-buildpackage -rfakeroot -us -uc -ui -ICVS -I.#* -I.cvsignore -I.bzr
> -I.svn -I.git failed
>
> Note, the git repo is at salsa now,
> https://salsa.debian.org/js-team/science.js.git >.
>
> --
> Happy hacking
> Petter Reinholdtsen
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#886758: New version 1.8.4 available

[Peter Spiess-Knafl]

I already packaged it on git:
https://salsa.debian.org/debian/libjsoncpp

I am waiting for sponsoring to upload to experimental.

Greetings,
Peter

> Am 28.09.2018 um 19:47 schrieb Elmar Gerdes :
> 
> Any news?  Upstream version contains bugfixes.
> 
> On Sun, 21 Jan 2018 08:22:15 +0100 Peter Spiess-Knafl  
> wrote:
>> I will take care of it.
>> > Am 09.01.2018 um 16:52 schrieb Yangfl :
>> > > Package: libjsoncpp
>> > Version: 1.7.4-3
>> > > The current Debian version is outdated. Since I'm packing
>> > https://github.com/avast-tl/retdec-config which require 1.8.4, it
>> > would be nice to update it to the current upstream one.
>> > > Thanks,



signature.asc
Description: Message signed with OpenPGP

Bug#909801: False positive udevadm-called-without-guard warning

[Chris Lamb]

retitle 909801 Don't emit udevadm-called-without-guard if package depends on 
udev
thanks

Hi Andreas,

> The udisks2 package has a direct dependency on udev
> (and would likely be completely useless without udev installed)
> so I think the lintian warning is invalid and should not trigger
> when a package has a direct udev dependency specified.

Retitling to be more specific.

> Please consider silencing the warning, because false positives
> makes lintian less useful.

Well, quite...


Regards,

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

Bug#909693: [pkg-gnupg-maint] Bug#909693: gpgsm: seems to be dead slow when verifying pkcs7-signatures from within Sylpheed

[Francesco Poli]

On Fri, 28 Sep 2018 08:35:57 +0200 Werner Koch wrote:

> On Fri, 28 Sep 2018 00:57, invernom...@paranoici.org said:
> 
> > It's clear that the CRL revocation check is the step that takes a long
> > time.
> 
> Right.  And it depends on the certificate issuer and how they maintain
> CRLs.  If they release CRLs only once a week, things should be okay
> becuase GnuPG caches them.  However, some CAs are creating new CRLs
> every hour or even more often and if they are really long (e.g. by
> including expired certifciates, which is silly, but some did this) this
> is an effective DoS.

Since these signatures are related to the IMHO absurd [PEC] Italian
system, it is quite likely that the certificate issuer behaves in a
silly way!:-/

[PEC]: 

> 
> > The man page states that disabling CRL checks is especially intended
> > for off-line operations (which is not my case, except for infrequent
> 
> Yes, that is the theory.  But in practise CRLs don't work and OCSP is
> also not much better.
> 
> > So, is disabling CRL checks advisable or not?
> 
> How often do you run a "gpg --refresh-key" which is basically the
> OpenPGP way for checking for revocations?

I refresh OpenPGP keys almost everyday, but not all of them.
I usually refresh a bunch of them each day.

I currently use a little [stupid script] that I wrote in order to do
so...
I honestly feel a little ashamed to mention such a stupid script to
you, but... by the way, is there a better way to refresh my public
keyring in a gradual manner?
I mean, maybe I could study [parcimonie], which uses Tor...
But, other than this, is there a gpg option to refresh n keys selected
from the user's own keyring (with the criterion that they must be the n
less recently refreshed keys)?

[stupid script]: 

[parcimonie]: 

> Does anyone actually revoke X.509 certifciates.

I don't know, frankly speaking...

> Weel, some organisations have their in-house use of
> C.509 and they can implement everything properly.  But everything else?
> I can't decide.

That's understandable...

> 
> It might be worth to add a black- or whitelist to our CRL checks or add
> an option to violate the nextUpdate field (expiration time) of a CRL and
> trigger an update only every few days.

I think a limit to the update frequency would be useful.
Something like an option to decide that one certificate should not be
checked for revocation more than once in Δt (where Δt may be one day,
one week, or any time interval set by the user).

Should we convert my bug report into a feature request?!?



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


pgpqoAHM1A0af.pgp
Description: PGP signature

Bug#909801: False positive udevadm-called-without-guard warning

[Andreas Henriksson]

Package: lintian
Version: 2.5.106
Severity: normal

Dear Maintainer,

I recently got the following lintian warning:

W: udisks2: udevadm-called-without-guard postinst:7


The udisks2 package has a direct dependency on udev
(and would likely be completely useless without udev installed)
so I think the lintian warning is invalid and should not trigger
when a package has a direct udev dependency specified.

Please consider silencing the warning, because false positives
makes lintian less useful.

Regards,
Andreas Henriksson

Bug#886758: New version 1.8.4 available

[Elmar Gerdes]

Any news?  Upstream version contains bugfixes.

On Sun, 21 Jan 2018 08:22:15 +0100 Peter Spiess-Knafl 
 wrote:

I will take care of it.

> Am 09.01.2018 um 16:52 schrieb Yangfl :
> 
> Package: libjsoncpp

> Version: 1.7.4-3
> 
> The current Debian version is outdated. Since I'm packing

> https://github.com/avast-tl/retdec-config which require 1.8.4, it
> would be nice to update it to the current upstream one.
> 
> Thanks,

Bug#890279: gzip (i386) uses TEXTRELs

[Andreas Pommer]

Hello Andreas and everybody else,

Andreas Henriksson wrote:
[...]
> Andreas Pommer: It would be great if you could verify that
> gzip built with the patch you find at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=890279;filename=gzip-no-asm.debdiff;msg=21
> (ie. attached to #890279 ) makes it possible for you to reenable the
> protection in the logrotate service file that Christian had to drop
> for you. (Either by downgrading to previous logrotate version or
> just systemctl edit and put the service changes back in again.)

yes, good news, it works.

I built gzip with the patch, installed the package, reconfigured logrotate,
systemctl daemon-reload, created a test entry in logrotate.d and a fake logfile
for rotatation and compression, and then restarted the logrotate service.

It worked, and I did not observe any errors:

# dpkg -l gzip
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  gzip   1.9-2.1  i386 GNU compression utilities

# ls -l /var/log/test/
total 4420
-rw-r- 1 root root 4523572 Sep 28 19:23 test.log

# systemctl restart logrotate

# ls -l /var/log/test/
total 200
-rw-r- 1 root root  0 Sep 28 19:24 test.log
-rw-r- 1 root root 202414 Sep 28 19:23 test.log.1.gz

Back when I encountered the issue logrotate would not have created the 1.gz
file, but leave the logfile uncompressed, and log some error messages.

And now 'systemctl status' does not show anything other than the usual
'starting' messages.

thanks a lot to everyone, and especially to Andreas Henriksson for your help,

Andreas

Bug#903396: patchelf: Makes some binaries impossible to strip

[Drew Parsons]

On 2018-09-28 21:05, Felipe Sateler wrote:

Hi,

On Fri, Sep 28, 2018, 06:16 Drew Parsons  wrote:



So that gives us 2 options for this strip bug
1) merge dparsons/0.9_fix_strip into a branch of debian/0.9-1
- applies 2 small patches only to 0.9
2) add the #127 patch to the debian branch
- applies one new small patch, but also other upstream patches
from
git



If you'd like to go ahead with 2), I can create a branch to merge
from.


 Thanks for testing both options, I prefer option 2 since it's easier
to merge.



Done.  I placed the patch in branch dparsons/patch_127_adjust_startPage 
and made the Merge Request.


Drew

Bug#909791: udev: Disk labels are not detected correctly

[Michael Biebl]

Am 28.09.2018 um 14:46 schrieb Michael Biebl:
> Control: tags -1 moreinfo
> Control: severity -1 normal
> 
> Am 28.09.18 um 14:37 schrieb pvsamsono...@gmail.com:
>> Package: udev
>> Version: 232-25+deb9u3
>> Severity: important
>>
>> Dear Maintainer,
>>
>> I have hybrid bootable iso image, created by grub-mkrescue.

Can you by any chance share that image and list the commands you used

[please always CC the bug number]


-- 
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#909701: RFS: wxmaxima/18.10.1-1

[Gunter Königsmann]

Seems like the internet did work after all => the corrected file is now
live at https://mentors.debian.net/package/wxmaxima

I've also

 - upstreamed the fix

 - added gitattribute files to the .git repo that will prevent this from
happening again

 - and added the fix to the release branch so if we make a service
release we can drop the patch again.

Thanks again,

and kind regards,


    Gunter.



pEpkey.asc
Description: application/pgp-keys

Bug#909701: RFS: wxmaxima/18.10.1-1

[Gunter Königsmann]

>> * Package name: wxmaxima
>>   Version : 18.10.1-1
> I'm afraid that the desktop file got converted to Windows line endings,
> which breaks some consumers.
>
> A lot of other files also suffered the same, this is harmless in the source
> but might harm other functionality as well.
>
Wentthrough the files. As far can see exactly 126 lines of Text were
affected => I have prepared a patch and now hope that my network
connection allows me to upload the repaired package to mentors.

Thanks a lot for having found this!

Kind regards,

   Gunter.



pEpkey.asc
Description: application/pgp-keys

Bug#904316: transition: boost-defaults

[Giovanni Mascellani]

Hi,

Il 23/09/18 09:59, Giovanni Mascellani ha scritto:
> BTW, I am trying to do a rebuild of all packages depending on boost with
> 1.62 and with 1.67, to see which new build failures are introduced. I
> don't have much experience in mass rebuild and my only available
> hardware is my own laptop, so it might take some time.

I did a first round of rebuilding packages. I rebuilt all the packages
listed in main by "build-rdeps --old libboost-dev" (379 source
packages). Around 70 packages fail with boost1.67, and they are listed
here[1]. The first block of packages also fails with boost1.62, so the
failure is most probably not due to the transition. For most of them a
FTBFS bug is present in the BTS and is indicated.

 [1] https://salsa.debian.org/gio/rebuilder/blob/master/reasons

The second block of packages have a failure that is rather clearly
related to the new boost version. For most of them the problem is that
something was moved to a different namespace or header, so the patch
should not be complicated to write.

The packages in the third block require more attention, because they
fail with boost1.67 and not with boost1.62, but the cause is not
evident. An exception is sagemath, for which the build stalls at some
point, both with 1.62 and 1.67.

In the next days I will study in more details the packages that require
more attention, and I will try to write appropriate patches (possibly
checking what can be recovered from Ubuntu).

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#909799: adios: Incomplete debian/copyright?

[Chris Lamb]

Source: adios
Version: 1.13.1-7
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Alastair McKinstry , 
ftpmas...@debian.org

Hi,

I just ACCEPTed adios from NEW but noticed it was missing attribution 
in debian/copyright for at least Michael Sweet, Seungyoung Kim, Jong
Choi, etc.

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

(It would also be great if you used the "real" DEP-5 style? You are so
close as it is, after all.)


Regards,

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

Bug#909798: ITP: ryzomcore -- science-fantasy MMORPG engine

[Phil Morrell]

Package: wnpp
Severity: wishlist
Owner: Phil Morrell 

* Package name: ryzomcore
  Version : 3.4.0
  Upstream Author : Winch Gate Property Ltd.
* URL : http://www.ryzomcore.com/
* License : AGPL3+, CC-BY-SA, GPL-2
  Programming Lang: C++, Lua
  Description : science-fantasy MMORPG engine

Ryzom Core is a software platform for creating and running massively
multi-user entertainment in a 3D environment over the Internet.

Ryzom Core provides the base technologies and a set of development
methodologies for the development of both client and server code. The
library contains independently reusable network, ai and 3d modules.

---

I'm not actually sure yet if the software is suitable for debian, but
I'm filing the ITP to avoid duplication of effort and to document any
relevant considerations. It will be packaged as part of the Games Team.

https://salsa.debian.org/emorrp1-guest/ryzomcore

https://ryzom.com/ is almost fully free software: client, server, tools,
and graphics. The audio assets are currently proprietary "as Ryzom has
not determined the copyright nature of those assets" and so is the
official world configuration and data. Assets are c. 8GB uncompressed.

A fully libre world server is in development https://khaganat.net

The NeL library was previously packaged in Debian up to Wheezy.


signature.asc
Description: PGP signature

Bug#909785: python-pcl: Incomplete debian/copyright and/or "freeware" source code?

[Chris Lamb]

Jochen,

> Do you have a proposal how to better document this?

Not entirely sure what you mean by "better" as you currently do not
document this at all (unless I am missing something).

However, as a concrete suggestion I would add "Comment" section to your
debian/copyright and almost-literally copy your (own) words, ie.:

  > This is only a comment, copied from the PCL sources (and I believe not 
  > even true over there).

  
Regards,

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

Bug#909755: [pkg-gnupg-maint] Bug#909755: gnupg: import screener bypass via crafted subkey

[Daniel Kahn Gillmor]

Control: forwarded 909755 https://dev.gnupg.org/T3398

On Thu 2018-09-27 19:37:08 +0200, Jakub Wilk wrote:
> To fix #725411, an import screener was implemented, which rejects keys 
> with fingerprints other than those that were requested by user.
>
> Unfortunately, it's possible to bypass the import screener by appending 
> a crafted subkey to an arbitrary key:
>
>$ gpg --keyserver keyserver.ubuntu.com --recv-key 
> 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
>gpg: key CCD2ED94D21739E9: public key "Daniel Kahn Gillmor 
> " imported
>gpg: no ultimately trusted keys found
>gpg: Total number processed: 1
>gpg:   imported: 1
>
>$ (printf 'HTTP/1.0 200 OK\n\n'; cat fakeCCD2ED94D21739E9.pgp) | 
> nc.openbsd -N -l -p 11371 > /dev/null &  # poor man's malicious key server
>
>$ gpg --keyserver localhost --recv-key 
> 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
>gpg: key 60B0EEAA28CB19E1: "Totally Legit Signing Key 
> " not changed
>gpg: Total number processed: 1
>gpg:  unchanged: 1
>
>$ gpg --list-packets fakeCCD2ED94D21739E9.pgp | tail -n6
># off=402 ctb=b9 tag=14 hlen=3 plen=525
>:public sub key packet:
>version 4, algo 1, created 1180812858, expires 0
>pkey[0]: [4096 bits]
>pkey[1]: [17 bits]
>keyid: CCD2ED94D21739E9
>
> The subkey was made by taking the original key's public key and changing 
> the packet's tag, so it has the same fingerprint as the original key.

yes, this is clearly a possible attack.  It has been discussed with
upstream in detail, and upstream knows about it as
https://dev.gnupg.org/T3398, where i've also offered a proposed
solution, which i'll copy here:


By default, when doing `--receive-keys` with a fingerprint, the
screener should only admit OpenPGP certificates that include a key
matching the fingerprint //which has a valid signature in the
certificate itself//.  This means, for example, that either this is
the fingerprint of the primary key itself, or it is the fingerprint
of a signing-capable subkey that has a well-formed (and
cryptographically valid) public key binding cross-signature.

This would mean that:

* refreshes of a curated keyring would still work

* you could still fetch a key based on the "Issuer Fingerprint" (or
  "Issuer Key ID") of a signature (in order to validate the
  signature) even if it was a subkey, because signing keys need
  cross-sigs

However:

* you could not necessarily use `--receive-keys` for retreiving a
  key based on the embedded key ID in a PKESK (e.g. "let's see who
  else this message appears to have been encrypted to").  I think
  this is a minor use case by comparison with the above two use
  cases, and it is less security-sensitive.  Perhaps we could add an
  additional option (`--keyserver-options
  no-require-signature-when-fetching-by-fpr`?) that would re-enable
  this use case, if we want to support it.


Regards,

--dkg


signature.asc
Description: PGP signature

Bug#909797: valgrind: Assertion 'cfsi_fits' fails when debugging BLAS-dependent programs

[Alberto Luaces]

Package: valgrind
Version: 1:3.13.0-2.1
Severity: important
Tags: upstream patch

Dear Maintainer,

programs that link to BLAS library make valgrind fail with the assertion in the 
subject.

It seems that upstream has solved it in

https://bugs.kde.org/show_bug.cgi?id=398028#c13

Can you please backport the fix?

Thanks!

This is the complete error output:

valgrind ./lapack
==26588== Memcheck, a memory error detector
==26588== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26588== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==26588== Command: ./lapack
==26588== 

valgrind: m_debuginfo/debuginfo.c:551 (check_CFSI_related_invariants): 
Assertion 'cfsi_fits' failed.

host stacktrace:
==26588==at 0x5804503A: show_sched_status_wrk (m_libcassert.c:355)
==26588==by 0x58045154: report_and_quit (m_libcassert.c:426)
==26588==by 0x580452D9: vgPlain_assert_fail (m_libcassert.c:492)
==26588==by 0x58079BEF: check_CFSI_related_invariants (debuginfo.c:551)
==26588==by 0x58079BEF: di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:766)
==26588==by 0x58079BEF: vgPlain_di_notify_mmap (debuginfo.c:1061)
==26588==by 0x580A5381: vgModuleLocal_generic_PRE_sys_mmap 
(syswrap-generic.c:2388)
==26588==by 0x580DC2C4: vgSysWrap_amd64_linux_sys_mmap_before 
(syswrap-amd64-linux.c:400)
==26588==by 0x580A1B13: vgPlain_client_syscall (syswrap-main.c:1857)
==26588==by 0x5809E37A: handle_syscall (scheduler.c:1126)
==26588==by 0x5809FAA6: vgPlain_scheduler (scheduler.c:1443)
==26588==by 0x580AFC40: thread_wrapper (syswrap-linux.c:103)
==26588==by 0x580AFC40: run_a_thread_NORETURN (syswrap-linux.c:156)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 26588)
==26588==at 0x401A693: mmap (mmap64.c:52)
==26588==by 0x40060AD: _dl_map_segments (dl-map-segments.h:94)
==26588==by 0x40060AD: _dl_map_object_from_fd (dl-load.c:1181)
==26588==by 0x400890E: _dl_map_object (dl-load.c:2461)
==26588==by 0x400D061: openaux (dl-deps.c:63)
==26588==by 0x401950A: _dl_catch_exception (dl-error-skeleton.c:196)
==26588==by 0x400D2F2: _dl_map_object_deps (dl-deps.c:249)
==26588==by 0x4003D95: dl_main (rtld.c:1726)
==26588==by 0x401862F: _dl_sysdep_start (dl-sysdep.c:253)
==26588==by 0x40020D7: _dl_start_final (rtld.c:414)
==26588==by 0x40020D7: _dl_start (rtld.c:521)
==26588==by 0x4001217: ??? (in /lib/x86_64-linux-gnu/ld-2.27.so)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Bug#787774: giving up on packaging OpenPGP.js

[Antoine Beaupré]

On 2018-09-24 14:02:52, Antoine Beaupre wrote:
> On Thu, May 31, 2018 at 02:23:31PM -0400, Daniel Kahn Gillmor wrote:
>> i don't currently have the time to maintain dozens of new node packages,
>> unfortunately.
>
> Hi Daniel!
>
> I feel so sorry for you. I understand how you feel - packaging
> Javascript stuff is hard in Debian! I have never managed to do anything
> in there myself.
>
> That said, I did spend a few minutes creating a task page here, as seems
> to be the custom in the team:
>
> https://wiki.debian.org/Javascript/Nodejs/Tasks/openpgp
>
> It reused part of your RFPs (in CC) but somehow missed asmcrypto which I
> added by hand. node-rusha also seems to be missing from the current
> dependencies, so maybe that was fixed/changed.
>
> Anways - from the looks of it, there are at least seven run-time
> dependencies missing, and 26 (or more?) build-time depends missing.

I found bugs in the js-task-edit script that mis-detected some
packages. After much wrangling (details in #909753), I managed to update
the page again and we're down to twenty build and seven run-time depends
missing.

Well. That was disappointing. But at least no one started working on
those 6 build-deps, right? :)

A.

-- 
That's the kind of society I want to build. I want a guarantee - with
physics and mathematics, not with laws - that we can give ourselves
real privacy of personal communications.
 - John Gilmore

Bug#909796: RFP: checksec -- Bash script to test executable properties

[Pierre Rudloff]

Package: wnpp
Severity: wishlist

* Package name: checksec
  Version : 1.8.0
  Upstream Author : Tobias Klein
* URL : https://github.com/slimm609/checksec.sh
* License : BSD
  Programming Lang: Bash
  Description : Bash script to test executable properties

Modern Linux distributions offer some mitigation techniques to make it harder
to exploit software vulnerabilities reliably. Mitigations such as RELRO,
NoExecute (NX), Stack Canaries, Address Space Layout Randomization (ASLR) and
Position Independent Executables (PIE) have made reliably exploiting any
vulnerabilities that do exist far more challenging. The checksec.sh script is
designed to test what standard Linux OS and PaX security features are being
used.

Bug#909770: gdm3: Does not show the list of users and fails to start any session

[Sergio Villar Senin]

> I basically started without plyumouth enabled and the screen becomes
black with the cursor in the top left corner of the screen.

I obviously meant _disabled_

BR

Bug#909785: python-pcl: Incomplete debian/copyright and/or "freeware" source code?

[Jochen Sprickerhof]

Hi Chris,

* Chris Lamb  [2018-09-28 10:07]:

I just ACCEPTed python-pcl from NEW but noticed it was missing
attribution or similar in debian/copyright for at least some files
listed as "freeware" (!= is this even DFSG-free software?).


I guess you are talking about this line:

https://salsa.debian.org/python-team/modules/python-pcl/blob/master/pcl/pcl_segmentation.pxd#L760

This is only a comment, copied from the PCL sources (and I believe not 
even true over there). The actual license of python-pcl is stated over 
here:


https://salsa.debian.org/python-team/modules/python-pcl/blob/master/docs/source/license.rst

Do you have a proposal how to better document this?

Cheers Jochen


signature.asc
Description: PGP signature

Bug#909701: RFS: wxmaxima/18.10.1-1

[Gunter Königsmann]

Hmmm...

...the Desktop File I can correct using a patch. But if it is many files 
perhaps a new upstream release is the only answer.

What is your opinion?

Kind regards,

  Gunter.

On 28 September 2018 15:51:52 CEST, Adam Borowski  wrote:
>On Thu, Sep 27, 2018 at 03:43:19AM +0200, Gunter Königsmann wrote:
>> * Package name: wxmaxima
>>   Version : 18.10.1-1
>
>> Changes since the last upload:
>> 
>>   * A new upstream version that comes with many bugfixes, features
>and
>> performance improvements.
>>   * Updated the Homepage and the main upstream contact of the
>program.
>>   * Dropped all the patches as they are incorporated in the new
>upstream
>> release.
>
>I'm afraid that the desktop file got converted to Windows line endings,
>which breaks some consumers.
>
>A lot of other files also suffered the same, this is harmless in the
>source
>but might harm other functionality as well.
>
>
>Meow!
>-- 
>⢀⣴⠾⠻⢶⣦⠀ 
>⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
>⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
>⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#909795: ITS: unrar-nonfree

[Norbert Preining]

Source: unrar-nonfree
Severity: important

Dear Martin,

I intend to salvate unrar-nonfree according to 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging

I haven't gotten any answer about libunrar in bug report 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720051
in more than a year, despite providing patches to support
libunrar shared lib building, and your last activity according to
https://qa.debian.org/developer.php?login=m...@debian.org
is also more than a year ago (last upload 2017-08-29).

Several new versions have been uploaded, and the need for
the shared library as been expressed in the above mentioned
bug report.

According to the procedure laid out, I will wait 21 days before
uploading a new package into the DELAYED queue, but I still hope
to hear from you.

All the best

Norbert


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

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

Bug#909794: manpages-dev: res_nclose is not mentioned in the resolver man page

[Michael Becker]

Package: manpages-dev
Version: 4.16-1
Severity: important

as res_nclose is not mentioned, programms developed according the documention 
loose some byte of memory with every call

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

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 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 manpages-dev depends on:
ii  manpages  4.16-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.8.4-2

-- no debconf information

Bug#907059:

[Fabricio Carvalho]

Just configured the ftpsync.conf file and "crontabed" to run every 4 hours.

Fabrício F. Carvalho
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Coordenador de redes, segurança e serviços
Analista em Tecnologia da Informação - NTI/UFAL
Bsc e Msc em Ciência da Computação
Email: fabricio.carva...@nti.ufal.br
Tel: 82 3214-1015

Bug#909770: gdm3: Does not show the list of users and fails to start any session

[Sergio Villar Senin]

O Ven, 28-09-2018 ás 12:47 +0100, Simon McVittie escribiu:
> On Fri, 28 Sep 2018 at 11:01:09 +0200, Sergio Villar Senin wrote:
> > O Xov, 27-09-2018 ás 22:39 +0100, Simon McVittie escribiu:
> > > On Thu, 27 Sep 2018 at 23:16:05 +0200, Sergio Villar Senin wrote:
> > > >The background of the plyumouth theme is shown but the list
> > > > of
> > > >users is not there as expected.
> 
> How many screens are you using, and how are they connected?  From
> your
> log it looks as though the answer might be one laptop internal panel,
> connected via eDP, and no external screens. Is that correct?

That's correct

> If you are using a plymouth theme that resembles the background you
> would
> expect for the gdm greeter (user list), please retry with a different
> plymouth theme such as softwave or lines and tell me what you see?
> (What
> I'm trying to determine here is whether the most recent pixels on
> your
> screen came from plymouth or gdm.)

I basically started without plyumouth enabled and the screen becomes
black with the cursor in the top left corner of the screen. At that
point I tried to attach an external screen, and guess what? then I
could see the VTs in F2,F3... and in F1 there was the gray background
(nothing else just that) from gdm.

> > I don't see anything specially wrong there except these lines:
> > 
> > laptop kernel: [drm:intel_dp_start_link_train [i915]] *ERROR*
> > [CONNECTOR:71:eDP-1] Link Training failed at link rate = 27,
> > lane
> > count = 2
> 
> I agree. This looks more like a kernel bug than anything else - I'm
> not
> sure that this is anything that gdm3 can fix - but I'll try to get a
> bit more information about what does and doesn't work before
> reassigning.
> 
> If you follow the workaround that you described (involving
> suspend/resume),
> do you get a similar warning about link training after resuming?

After resuming everything seems to work fine and I haven't seen any
error in the journal.

> You said that lightdm works OK. Do you get similar warnings about
> link
> training when using lightdm?

Not a single one. The last warning appears just after the
"/usr/lib/gdm3/gdm-x-session[3172]: (II) modeset(0)" lines.

> If you edit /etc/gdm3/daemon.conf and edit it to have
> 
> [daemon]
> WaylandEnable=false
> 
> then go back to gdm, does that make it work?

No luck, same result.

BR

Bug#909793: RFS: intel-mkl/2019.0.117-2~bpo9+1 [NEW,stable-backports]

[Mo Zhou]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

Dear mentors and science team,

I am looking for a sponsor for my package "intel-mkl". I'm a Debian
Developer but I don't have backports ACL permission. I filed this RFS
because I don't need that permission. Of all my packages, only intel-mkl
is worth backporting.

 * Package name: intel-mkl
   Version : 2019.0.117-2~bpo9+1
   Upstream Author : Intel
 * URL : https://software.intel.com/en-us/mkl
 * License : Intel Simplified Software License (ISSL)
   Section : non-free/math

Backports-Justification:

 * The best (yet non-free) x86 CPU based BLAS/LAPACK implementation.
 * Expected to be very stable for Debian stable users.
 * This package has migrated into testing.

How to build this package and prepare *_multi.changes for stretch-bpo:

 1. Clone https://salsa.debian.org/science-team/intel-mkl
And checkout to the "stretch-bpo" branch.
 2. Download orig.tar.gz from the archive.
 3. Build package for amd64 and i386, respectively.
 4. mergechanges -f xxx_amd64.changes xxx_i386.changes
 5. changestool xxx_multi.changes updatechecksums
 6. debsign and dput.

Changes since the last upload:

 intel-mkl (2019.0.117-2~bpo9+1) stretch-backports; urgency=medium
 
   * Downgrade python3 requirement to (>= 3.5)
   * Downgrade debhelper compat level to 10.
   * Enable control.bpo.py script in rules.
   * Backport to stretch.

Debdiff and Justification:

 * The debhelper compat level downgrade is very safe since this package
   is just repacking upstream binary tarball.

 * control.py is originally written in python3.6 . In order to build
   this package, I wrote control.bpo.py which automatically edits
   control.py, making it compatible with python3.5 . It actually
   replaces the following pattern (python3.6 feature: format string)

 f'blah {var1} blah {var2}'

   into

 'blah {var1} blah {var2}'.format(**locals())

   control.bpo.py has been verified in one of my VMs (stretch).

---
diff --git a/debian/changelog b/debian/changelog
index b1223f2..a5ec794 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+intel-mkl (2019.0.117-2~bpo9+1) stretch-backports; urgency=medium
+
+  * Downgrade python3 requirement to (>= 3.5)
+  * Downgrade debhelper compat level to 10.
+  * Enable control.bpo.py script in rules.
+  * Backport to stretch.
+
+ -- Mo Zhou   Tue, 25 Sep 2018 08:19:29 +
+
 intel-mkl (2019.0.117-2) unstable; urgency=medium

   * Export HOME=/tmp/ to fix FTBFS due to the failure that rpm would
diff --git a/debian/compat b/debian/compat
index b4de394..f599e28 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-11
+10
diff --git a/debian/control b/debian/control
index 6566846..f5ec94b 100644
--- a/debian/control
+++ b/debian/control
@@ -3,11 +3,11 @@ Section: non-free/science
 Priority: optional
 Maintainer: Debian Science Maintainers 

 Uploaders: Mo Zhou ,
-Build-Depends: debhelper (>=11~),
+Build-Depends: debhelper (>=10~),
dh-exec,
 # The script control.py requires python3 >= 3.6 .
 # but you can patch it with debian/bpo.patch to support python3 >= 3.5 .
-   python3 (>= 3.6),
+   python3 (>= 3.5),
rpm,
cpio,
rpm2cpio,
diff --git a/debian/rules b/debian/rules
index 91f4bc5..805a4bc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -45,7 +45,7 @@ autogen: extract-rpms $(AUTOGEN_FILES)
chmod +x debian/libmkl-dev.postinst debian/libmkl-dev.prerm  
debian/libmkl-dev.config

 override_dh_auto_configure: autogen
-   #python3 debian/control.bpo.py  # Patch control.py to support python3.5
+   python3 debian/control.bpo.py  # Patch control.py to support python3.5
python3 debian/control.py  # Generate install files and lintian 
overrides

# deal with embedded libjs-jquery

Bug#909701: RFS: wxmaxima/18.10.1-1

[Adam Borowski]

On Thu, Sep 27, 2018 at 03:43:19AM +0200, Gunter Königsmann wrote:
> * Package name: wxmaxima
>   Version : 18.10.1-1

> Changes since the last upload:
> 
>   * A new upstream version that comes with many bugfixes, features and
> performance improvements.
>   * Updated the Homepage and the main upstream contact of the program.
>   * Dropped all the patches as they are incorporated in the new upstream
> release.

I'm afraid that the desktop file got converted to Windows line endings,
which breaks some consumers.

A lot of other files also suffered the same, this is harmless in the source
but might harm other functionality as well.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Bug#903396: patchelf: Makes some binaries impossible to strip

[Felipe Sateler]

Hi,

On Fri, Sep 28, 2018, 06:16 Drew Parsons  wrote:

> On 2018-09-28 06:37, Felipe Sateler wrote:
> >>
> >> But there are only 2 specific patches needed to fix the strip bug,
> >> https://github.com/NixOS/patchelf/pull/117 [1]
> >> https://github.com/NixOS/patchelf/pull/127 [2]
> >>
> >> Can we apply these patches to debian's 0.9 (copy the commits into
> >> debian/patches)? If that builds on all arches then it's a good
> >> resolution for this bug.
> >
> > I note that a comment in #127 says not all of the problems are
> > resolved. But if this helps mitigate the problem, I don't have a
> > problem applying those.
> >
> > Unfortunately I'm currently a bit lacking on time. Help in the form of
> > patches welcome, even better if in the form of a salsa MR.
>
>
> I created branch dparsons/0.9_fix_strip from tag debian/0.9-1 and
> applied the patches (refreshed to patch cleanly against 0.9).
> I pushed dparsons/0.9_fix_strip to salsa.
>
> I haven't set up an MR since it needs a target branch. The debian branch
> is too far ahead (latest git).
> We want a branch like 0.9 or debian/0.9, i.e.
>git checkout -b 0.9 debian/0.9-1
> or   git checkout -b debian/0.9 debian/0.9-1
> and then we can merge dparsons/0.9_fix_strip into it.  I figured I
> should let you decide which 0.9 branch to create.
>
> These patches seem to fix the strip problem. The bug I'm addressing is
> managing circular dependencies in hypre,
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902102).  This patched
> patchelf 0.9 allows the missing needed links to be added to the hypre
> libs, without breaking dh_strip.
>
> At the same time, I also tested adding the #127 patch to the debian
> branch (i.e. applying it to latest git). It does allow patchelf (latest
> git) to pass tests, and still works with hypre.  I don't know about any
> other unresolved problems, but it fixes what I want for hypre.
>
> So that gives us 2 options for this strip bug
> 1) merge dparsons/0.9_fix_strip into a branch of debian/0.9-1
> - applies 2 small patches only to 0.9
> 2) add the #127 patch to the debian branch
> - applies one new small patch, but also other upstream patches from
> git


> If you'd like to go ahead with 2), I can create a branch to merge from.
>
>
 Thanks for testing both options, I prefer option 2 since it's easier to
merge.

Saludos

Bug#909791: udev: Disk labels are not detected correctly

[Michael Biebl]

Control: tags -1 moreinfo
Control: severity -1 normal

Am 28.09.18 um 14:37 schrieb pvsamsono...@gmail.com:
> Package: udev
> Version: 232-25+deb9u3
> Severity: important
> 
> Dear Maintainer,
> 
> I have hybrid bootable iso image, created by grub-mkrescue.
> I write this image on usb flash pen:
> /dev/sdb: UUID="2018-09-28-11-12-33-00" LABEL="TinyInstall" TYPE="iso9660" 
> PTUUID="ca9a1be3-677f-4429-8d44-5b6a55ae7ff7" PTTYPE="gpt"
> /dev/sdb1: PARTLABEL="Gap0" PARTUUID="ca9a1be3-677f-4429-8d45-5b6a55ae7ff7"
> /dev/sdb2: SEC_TYPE="msdos" UUID="58C1-D634" TYPE="vfat" PARTLABEL="EFI boot 
> partition" PARTUUID="ca9a1be3-677f-4429-8d46-5b6a55ae7ff7"
> /dev/sdb3: LABEL="TinyInstall" TYPE="hfsplus" PARTLABEL="HFSPLUS" 
> PARTUUID="ca9a1be3-677f-4429-8d47-5b6a55ae7ff7"
> /dev/sdb4: PARTLABEL="Gap1" PARTUUID="ca9a1be3-677f-4429-8d40-5b6a55ae7ff7"
> When udev detect sdb sdb1 sdb2 sdb3 sdb4 then enviroment:
> ID_FS_LABEL=TinyInstall
> ID_FS_LABEL_ENC=TinyInstall
> ID_FS_UUID=2018-09-26-04-54-11-00
> ID_FS_UUID_ENC=2018-09-26-04-54-11-00
> not clear.

I don't understand what you are trying to say here.

> Finally the symlink /dev/disk/by-label/TinyInstall point to random /dev/sdb*

What do you mean by that?


-- 
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#909792: gnome-terminal: Japanese input always fails using ibus ,after another new window is opened.

[nozzy123nozzy]

Package: gnome-terminal
Version: 3.30.0-1
Severity: important

Dear Maintainer,

 I found gnome-terminal always fails to input Japanese text using ibus,
after new window of gnome-terminal  is opened. 

 Can anyone fix it?

 Thank you in advance,

 Takahide Nojima


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

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

Versions of packages gnome-terminal 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  gnome-terminal-data   3.30.0-1
ii  gsettings-desktop-schemas 3.28.1-1
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.27-6
ii  libdconf1 0.30.0-1
ii  libglib2.0-0  2.58.1-2
ii  libgtk-3-03.24.0-3
ii  libpango-1.0-01.42.4-3
ii  libuuid1  2.32.1-0.1
ii  libvte-2.91-0 0.54.0-1
ii  libx11-6  2:1.6.6-1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.38.0-2
pn  nautilus-extension-gnome-terminal  
ii  yelp   3.30.0-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#909791: udev: Disk labels are not detected correctly

[pvsamsono...@gmail.com]

Package: udev
Version: 232-25+deb9u3
Severity: important

Dear Maintainer,

I have hybrid bootable iso image, created by grub-mkrescue.
I write this image on usb flash pen:
/dev/sdb: UUID="2018-09-28-11-12-33-00" LABEL="TinyInstall" TYPE="iso9660" 
PTUUID="ca9a1be3-677f-4429-8d44-5b6a55ae7ff7" PTTYPE="gpt"
/dev/sdb1: PARTLABEL="Gap0" PARTUUID="ca9a1be3-677f-4429-8d45-5b6a55ae7ff7"
/dev/sdb2: SEC_TYPE="msdos" UUID="58C1-D634" TYPE="vfat" PARTLABEL="EFI boot 
partition" PARTUUID="ca9a1be3-677f-4429-8d46-5b6a55ae7ff7"
/dev/sdb3: LABEL="TinyInstall" TYPE="hfsplus" PARTLABEL="HFSPLUS" 
PARTUUID="ca9a1be3-677f-4429-8d47-5b6a55ae7ff7"
/dev/sdb4: PARTLABEL="Gap1" PARTUUID="ca9a1be3-677f-4429-8d40-5b6a55ae7ff7"
When udev detect sdb sdb1 sdb2 sdb3 sdb4 then enviroment:
ID_FS_LABEL=TinyInstall
ID_FS_LABEL_ENC=TinyInstall
ID_FS_UUID=2018-09-26-04-54-11-00
ID_FS_UUID_ENC=2018-09-26-04-54-11-00
not clear.
Finally the symlink /dev/disk/by-label/TinyInstall point to random /dev/sdb*

-- Package-specific info:

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

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

Versions of packages udev depends on:
ii  adduser  3.115
ii  dpkg 1.18.24
ii  libacl1  2.2.52-3+b1
ii  libblkid12.29.2-1+deb9u1
ii  libc62.24-11+deb9u3
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libkmod2 23-2
ii  libselinux1  2.6-3+b3
ii  libudev1 232-25+deb9u3
ii  lsb-base 9.20161125
ii  procps   2:3.3.12-3+deb9u1
ii  util-linux   2.29.2-1+deb9u1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  232-25+deb9u4

-- debconf information excluded
P: /devices/LNXSYSTM:00
E: DEVPATH=/devices/LNXSYSTM:00
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXSYSTM:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=9118890

P: /devices/LNXSYSTM:00/LNXCPU:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=9183071

P: /devices/LNXSYSTM:00/LNXCPU:01
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=9264942

P: /devices/LNXSYSTM:00/LNXCPU:02
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:02
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=9297104

P: /devices/LNXSYSTM:00/LNXCPU:03
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:03
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=9329891

P: /devices/LNXSYSTM:00/LNXPWRBN:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: DRIVER=button
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXPWRBN:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=9330088

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
E: EV=3
E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: KEY=10 0 0 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PRODUCT=19/0/1/0
E: PROP=0
E: SUBSYSTEM=input
E: TAGS=:seat:
E: USEC_INITIALIZED=9804403

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event1
N: input/event1
E: DEVNAME=/dev/input/event1
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event1
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: MAJOR=13
E: MINOR=65
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=9982339

P: /devices/LNXSYSTM:00/LNXSYBUS:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXSYBUS:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=9328392

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:PNP0A08:PNP0A03:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=9334705

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00
E: DRIVER=video
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXVIDEO:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=9340961

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:01
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:01
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5
E: EV=3
E: ID_FOR_SEA

Bug#909530: t-coffee: autopkgtest regression

[Andreas Tille]

Hi again,

On Fri, Sep 28, 2018 at 12:12:58PM +0200, Andreas Tille wrote:
> > also for me) I ran t_coffee:
> > root@autopkgtest-lxc-vfquea:/tmp/autopkgtest-lxc.3n021a13/downtmp/build.S6P/src#
> > t_coffee
> > ERROR: Could not set a HOME directory.
> > Set any of the following environement variables to some suitable
> > location: HOME, HOME_4_TCOFFEE, TMP or TEMP [FATAL:T-COFFEE]
> > Segmentation fault
> 
> Strange.  I'm able to reproduce this here even on my local machine in a
> shell where I did some `unset HOME`.  I wonder why this error was not
> produced with version 11.00.8cbe486-6 before.  Anyway, now since the
> issue can be easily reproduced I'll find a fix soonish.

While that is now really fixed[1] the other issues seem to be caused
by something else.  This is really only happening in the package in
unstable.  Back to gdb ... :-(
  
> > Paul
> > PS: also there is a typo in the error message:
> > environement -> environment
> 
> Will be fixed as well.

Is also fixed in[1].

Kind regards

Andreas.


[1] 
https://salsa.debian.org/med-team/t-coffee/commit/9cffa995e4603e396054062c6f3dbff1568bf243

-- 
http://fam-tille.de

Bug#909790: RFS: freetype-py/2.0.0.post6-1 [ITP]

[Bastian Germann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "freetype-py". I submitted this RFS
to the debian-python list a while ago but it did not get any attention.
Therefore I submit it here.

 * Package name: freetype-py
   Version : 2.0.0.post6-1
   Upstream Author : Nicolas P. Rougier
 * URL : https://github.com/rougier/freetype-py
 * License : BSD
   Section : python

It builds those binary packages:

 python-freetype - Freetype Python bindings
 python3-freetype - Freetype Python bindings for Python 3

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

 https://mentors.debian.net/package/freetype-py


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

 dget -x
https://mentors.debian.net/debian/pool/main/f/freetype-py/freetype-
py_2.0.0.post6-1.dsc

Regards,
Bastian Germann



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

Kernel: Linux 4.18.0-1-686-pae (SMP w/2 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)

Bug#909770: gdm3: Does not show the list of users and fails to start any session

[Simon McVittie]

On Fri, 28 Sep 2018 at 11:01:09 +0200, Sergio Villar Senin wrote:
> O Xov, 27-09-2018 ás 22:39 +0100, Simon McVittie escribiu:
> > On Thu, 27 Sep 2018 at 23:16:05 +0200, Sergio Villar Senin wrote:
> > >The background of the plyumouth theme is shown but the list of
> > >users is not there as expected.

How many screens are you using, and how are they connected?  From your
log it looks as though the answer might be one laptop internal panel,
connected via eDP, and no external screens. Is that correct?

If you are using a plymouth theme that resembles the background you would
expect for the gdm greeter (user list), please retry with a different
plymouth theme such as softwave or lines and tell me what you see? (What
I'm trying to determine here is whether the most recent pixels on your
screen came from plymouth or gdm.)

> I don't see anything specially wrong there except these lines:
> 
> laptop kernel: [drm:intel_dp_start_link_train [i915]] *ERROR*
> [CONNECTOR:71:eDP-1] Link Training failed at link rate = 27, lane
> count = 2

I agree. This looks more like a kernel bug than anything else - I'm not
sure that this is anything that gdm3 can fix - but I'll try to get a
bit more information about what does and doesn't work before reassigning.

If you follow the workaround that you described (involving suspend/resume),
do you get a similar warning about link training after resuming?

You said that lightdm works OK. Do you get similar warnings about link
training when using lightdm?

If you edit /etc/gdm3/daemon.conf and edit it to have

[daemon]
WaylandEnable=false

then go back to gdm, does that make it work?

smcv

Bug#885542: Bug #885542: lxcfs: virtualizing the btime field of /proc/stat screws up process start times

[Michael Banck]

Hi,

On Wed, 27 Dec 2017 21:38:41 +0100 Paul Slootman  wrote:
> As I find having accurate start times of processes far more important
> than having an accurate uptime counter for my containers, as do other
> people as well apparently, I would like to see this reverted until a
> better solution for the btime field /uptime is found.

Same here, this broke the patroni autopkgtest (see #909532 and https://g
ithub.com/zalando/patroni/issues/811 as well as https://github.com/giamp
aolo/psutil/issues/1344)

As ci.debian.net is running on LXC containers (on stable apparently)
could this be fixed in stable, please?

Should this be RC as it breaks unrelated software?


Michael

-- 
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax:  +49 2166 9901-100
Email: michael.ba...@credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

Bug#909754: dpkg -l now always pipes to less and ignores $COLUMNS

[Holger Levsen]

On Fri, Sep 28, 2018 at 02:42:19AM +1000, Craig Sanders wrote:
> I upgraded dpkg today and noticed that 'dpkg -l' now always pipes its output
> through less, even if $PAGER is unset.  The only way to get the output to go
> to the tty is to explicitly pipe it to cat.
> 
> This is exactly the opposite of how unix programs should behave - stdout
> goes to a tty unless redirected.  If a user **wants** to view the output of
> a program in a pager, then they can pipe it to less or whatever themselves.
> That's standard usage of the unix shell.  Hard-coding a program to always use
> a pager is wrong.
> 
> It also prevents dpkg's output from appearing in the scrollback buffer of
> terminal emulators because less (by default) switches to the alternate screen.
> 
> 
> dpkg now also ignore the COLUMNS variable, which is set by default in bash
> and other shells, and can be overidden on the command line as needed. With
> this change, flexibility and customisation has been replaced with a single
> hard-coded output format.  Previous versions of dpkg used $COLUMNS, and were
> documented to do so in the man page.
> 
> This makes the output ugly and difficult to read on standard 80 column
> terminals because the output will now typically be longer than 80 columns
> wide.  In fact, it's ugly and difficult to read on any terminal width
> less than the widest possible output line - it's no longer an easily read
> one-line-per-entry table, but a jumbled multiple-lines-per-entry mess.
[...]
 
I fully agree. (& thanks for writing this precice bug report, Craig.)

also, running eg 'dpkg -l dpkg' and then ending up in less is confusing
and breaking >20y old habbits, and then I press 'q' and get exit code 1.

> Please revert this change.

Yes, please.

And thanks for maintaining dpkg! :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#909789: manpages-dev: stat(2) manpage on ENOENT for dangling symbolic links (broken links)

[Alessandro Vesely]

Package: manpages-dev
Version: 4.10-2
Severity: minor

Dear Maintainer,

it seems to be a gotcha having stat(x, y) unexpectedly return -1 when x is a
broken link.  The stat(1) command works where stat(2) fails.  The obvious
solution is to use lstat.

It is difficult to fix this without ineffectually lengthening the text.
Perhaps, using the concept of unlinked file, which is valid for hard and soft
links alike, might help.  For example, the man page says:

ENOENT A component of pathname does not exist, or pathname is an empty string.

Alternatively, it could say:

ENOENT A component of pathname is unlinked (does not exist), or pathname is an
empty string.



Besides, the 1st paragraph in the NOTES section says "AT_NO_AUTOMOUNT fag".
Please substitute "AT_NO_AUTOMOUNT flag" lest someone smokes their unmounted
devices...



Thanks for maintaining man pages
Ale




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

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

Versions of packages manpages-dev depends on:
ii  manpages  4.10-2

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  jed-extra [man-browser]  2.5.7-2
ii  man-db [man-browser] 2.7.6.1-2

Bug#909788: rng-tools5: Missing init script

[Carsten Leonhardt]

Package: rng-tools5
Version: 5-1
Severity: important

Dear Maintainer,

the daemon doesn't start automatically because there's no init script
included.

I've attached a working example.

Regards,

Carsten

#!/bin/sh
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
### BEGIN INIT INFO
# Provides:  rngd
# Required-Start:$remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: entropy gathering daemon (rngd)
# Description:   Check and feed random data from hardware device
#to kernel random device

### END INIT INFO

# Author: Carsten Leonhardt 

DESC="entropy gathering daemon"
DAEMON=/usr/sbin/rngd

Bug#909284: minidlna: Minidlna needs libavcodec.so.57 which is not a dependancy

[Alexander Gerasiov]

Hello Alexander,

On Fri, 28 Sep 2018 13:48:21 +0300
Alexander Gerasiov  wrote:

> Hello Dean,
> 
> What distribution do you use?
> 
> I'm afraid it's not Debian, but Raspbian derivative.
> 
> I cant reproduce it with current debian archive. May be you should
> report to raspbian and ask binNMU for minidlna (or libavformat58, as
> minidlna do not links libavcodec itself).

Oh, it's not libavformat58, which should be rebuilt, but libchromaprint:

> /usr/sbin/minidlnad: /usr/lib/arm-linux-gnueabihf/libavcodec.so.58:
> version `LIBAVCODEC_57' not found (required by
> /usr/lib/arm-linux-gnueabihf/libchromaprint.so.1)

> 
> On Fri, 21 Sep 2018 10:26:25 +1000
> Dean  wrote:
> 
> > Package: minidlna
> > Version: 1.2.1+dfsg-1+b1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > * What led up to the situation?
> > I think i may have removed libavcodec57 at some point.
> > Now when i start the service It starts with the following in the
> > journal: /usr/sbin/minidlnad: error while loading shared libraries:
> > libavcodec.so.57: cannot open shared object file: No such file or
> > directory raspberrypi systemd[1]: minidlna.service: About to
> > execute: /etc/init.d/minidlna start
> > raspberrypi systemd[1]: minidlna.service:
> > Forked /etc/init.d/minidlna as 5123
> > raspberrypi systemd[1]: minidlna.service: Changed dead -> start
> > raspberrypi systemd[1]: Starting LSB: minidlna server...
> > raspberrypi systemd[5123]: minidlna.service: Executing:
> > /etc/init.d/minidlna start
> > raspberrypi systemd[1]: minidlna.service: Child 5123 belongs to
> > minidlna.service.
> > raspberrypi systemd[1]: minidlna.service: Control process exited,
> > code=exited status=0
> > raspberrypi systemd[1]: minidlna.service: Got final SIGCHLD for
> > state start. raspberrypi systemd[1]: minidlna.service: Changed
> > start -> exited raspberrypi systemd[1]: minidlna.service: Job
> > minidlna.service/start finished, result=done
> > raspberrypi systemd[1]: Started LSB: minidlna server.
> > raspberrypi systemd[1]: minidlna.service: Failed to send unit change
> > signal for minidlna.service: Connection reset by peer
> > * What exactly did you do (or not do) that was effective (or
> > ineffective)? I first tried linking libavcodec58 to 57 but then it
> > looks for version 57 of the rest of its libraries
> > I then tried to link each of the successive so's it complained about
> > (libavformat, libavutils, ...) with no avail
> > I then tried to install libavcodec57 but it is no longer in the repo
> > * What was the outcome of this action?
> > ln -s /usr/lib/arm-linux-gnueabihf/libavcodec.so.58.18.100
> > /usr/lib/arm-linux-gnueabihf/libavcodec.so.57
> > systemctl start minidlna:
> > /usr/sbin/minidlnad: /usr/lib/arm-linux-gnueabihf/libavcodec.so.58:
> > version `LIBAVCODEC_57' not found (required by
> > /usr/lib/arm-linux-gnueabihf/libchromaprint.so.1)
> > * What outcome did you expect instead?
> > I was hoping minidlna would work with libav* version 58
> > 
> > -- System Information:
> > Distributor ID: Raspbian
> > Description: Raspbian GNU/Linux testing (buster)
> > Release: testing
> > Codename: buster
> > Architecture: armv7l
> > 
> > Kernel: Linux 4.14.70-v7+ (SMP w/4 CPU cores)
> > Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
> > LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages minidlna depends on:
> > ii adduser 3.117
> > ii libavformat58 7:4.0.2-1+b2
> > ii libavutil56 7:4.0.2-1+b2
> > ii libc6 2.27-6+rpi1
> > ii libexif12 0.6.21-5
> > ii libflac8 1.3.2-3
> > ii libid3tag0 0.15.1b-13
> > ii libjpeg62-turbo 1:1.5.2-2+b1
> > ii libogg0 1.3.2-1
> > ii libsqlite3-0 3.24.0-1
> > ii libvorbis0a 1.3.6-1
> > ii lsb-base 9.20170808+rpi1
> > 
> > minidlna recommends no packages.
> > 
> > minidlna suggests no packages.
> > 
> > -- Configuration Files:
> > /etc/minidlna.conf changed:
> > media_dir=V,/mnt/media/Movies
> > media_dir=V,/mnt/media/Kids
> > merge_media_dirs=no
> > db_dir=/var/cache/minidlna
> > log_dir=/var/log
> > root_container=V
> > network_interface=eth0
> > port=8200
> > friendly_name="redacted"
> > inotify=yes
> > album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg
> > album_art_names=AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg
> > album_art_names=Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg
> > 
> > 
> > -- no debconf information  
> 
> 
> 



-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#909076: ghostscript: ps2ascii crashes: Error: /typecheck in --.bind--

[Markus Koschany]

Hi,

Am 28.09.18 um 00:16 schrieb Salvatore Bonaccorso:
> Hi Markus,
> 
> On Thu, Sep 27, 2018 at 10:33:06PM +0200, Markus Koschany wrote:
[...]
>> The text is correctly displayed now in Jessie but the Stretch version
>> shows Chinese characters instead. Hence I would appreciate it if you
>> could double-check and verify the output on your terminals.
> 
> The commit might be part indeed of the solution, that is to switch to
> the txtwrite device. In the bisect I did, I already used as well a
> variant with using the txtwrite device. This is what lead to
> previously posted git bisect log (with commits between a broken one in
> the 9.20 series, up to the a less broken one[*], and in each iteration
> always applying as strategy the mentioned commit for fixing the CVE
> and which caused the regression, and calling gs directly with the
> needed parameter using the txtwrite device).
> 
> I know already that e.g. using the commit
> http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=cc746214644deacd5233a1453ce660573af09443
> (*and* using the txtwrite device) seems to improve the situation. But
> there are still dispalying discrepancies and regressions with test
> files. So this is not enough for the stretch built at least :-/.
> In the jessie patched version, you did exact the same documents with
> old version and with patched one for e.g. alpahet.ps and waterfall.ps?

Could you post your test files somewhere and describe what you expect to
see? I would like to test them too. In Jessie it is sufficient to just
switch to the txtwrite device. If I apply the other Git commit
cc746214644deacd5233a1453ce660573af09443 then I even get the same
results in Stretch.

It is not surprising that both versions behave differently. The version
in Jessie is ancient and from 2012. A lot of bugs could have been
introduced and fixed between 2012 and today.






signature.asc
Description: OpenPGP digital signature

Bug#909787: dh-golang: Wrong iterate logic in exec_chunked

[Shengjing Zhu]

Control: found -1 1.27

This bug is a regression when fixing #885696. So set found version to 1.27.

Bug#909530: t-coffee: autopkgtest regression

[Andreas Tille]

Hi Paul,

On Thu, Sep 27, 2018 at 02:05:19PM +0200, Paul Gevers wrote:
> 
> I ran autopkgtest locally with the --shell option. After it failed (yes,
> also for me) I ran t_coffee:
> root@autopkgtest-lxc-vfquea:/tmp/autopkgtest-lxc.3n021a13/downtmp/build.S6P/src#
> t_coffee
> ERROR: Could not set a HOME directory.
> Set any of the following environement variables to some suitable
> location: HOME, HOME_4_TCOFFEE, TMP or TEMP [FATAL:T-COFFEE]
> Segmentation fault

Strange.  I'm able to reproduce this here even on my local machine in a
shell where I did some `unset HOME`.  I wonder why this error was not
produced with version 11.00.8cbe486-6 before.  Anyway, now since the
issue can be easily reproduced I'll find a fix soonish.
 
> Paul
> PS: also there is a typo in the error message:
> environement -> environment

Will be fixed as well.

Thanks a lot for all your QA work

 Andreas.

-- 
http://fam-tille.de

Bug#909697: keepalived: Keepalived does not parse correctly brakets without space

[Daniele Palumbo]

Il giorno 27 set 2018, alle ore 01:36, Daniele Palumbo  
ha scritto:
> Package: keepalived
> Version: 1:1.3.2-1
> Severity: normal
> 
> Hi,
> 
> The current squeeze version of keepalived is not parsing correctly the 
> brackets to open a section.

Sorry for the mistake, this is of course not Squeeze but Stretch.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#909761: porechop FTBFS: command 'PorechopClean' has no such option 'all'

[Andreas Tille]

Hi Mattia,

I can confirm that I get the same result:  Works on local machine (here
running testing) and fails with that error in pbuilder.

BTW, if I drop the

 --buildsystem pybuild

this problem vanishes.  So I guess pybuild is doing some magic.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#882715: neomutt: can I has an alternative for /usr/bin/mutt ?

[Andreas Henriksson]

Control: tag -1 + patch

Hi,

Please see attached patches for both neomutt and mutt to implement
this. Review welcome. If you lack time, I'm happy to help out with
a NMU. If so please just say, so we can skip the waiting.

Note for mutt: I did not revert the previous commit[1] that ripped out
alternatives, for the following reasons:
 - the debian/changelog entry should not be reverted
 - the old alternatives where for different files
 - given we divert different files now, we likely still want
   to keep the prerm remove-all call until upgrading from 1.6
   is considered unsupported (which I leave up to you to
   determine when that is).
Also, as noted in the top comment of the mutt debdiff the lintian
override for desktop file should most likely be reintroduced again.

Note for neomutt maintainers: This might also be a good time to
get #894688 fixed. And the patch also as a bonus could probably
be considered to fix #888260 which you might want to close.

CCing people who showed interest on the bug report. Help with
(additional) testing would be welcome.

Regards,
Andreas Henriksson

[1]: 
https://salsa.debian.org/mutt-team/mutt/commit/fd1a5ea0e9653473632af8ef8ae3bcc87c8b3161
diff -Nru mutt-1.10.1/debian/changelog mutt-1.10.1/debian/changelog
--- mutt-1.10.1/debian/changelog2018-08-07 10:31:52.0 +0200
+++ mutt-1.10.1/debian/changelog2018-09-28 09:19:02.0 +0200
@@ -1,3 +1,11 @@
+mutt (1.10.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Make /usr/bin/mutt , /usr/bin/mutt_dotlock , /usr/bin/smime_keys plus
+manpages an alternative that can be provided by others. (See #882715)
+
+ -- Andreas Henriksson   Fri, 28 Sep 2018 09:19:02 +0200
+
 mutt (1.10.1-2) unstable; urgency=low
 
   [ Jonathan Nieder ]
diff -Nru mutt-1.10.1/debian/mutt.install mutt-1.10.1/debian/mutt.install
--- mutt-1.10.1/debian/mutt.install 2018-04-15 10:11:26.0 +0200
+++ mutt-1.10.1/debian/mutt.install 2018-09-28 09:19:02.0 +0200
@@ -1,6 +1,6 @@
-debian/tmp/usr/bin/mutt
-debian/tmp/usr/bin/smime_keys
-debian/tmp/usr/bin/mutt_dotlock
+debian/tmp/usr/bin/original-mutt
+debian/tmp/usr/bin/original-smime_keys
+debian/tmp/usr/bin/original-mutt_dotlock
 debian/tmp/usr/share/locale/*
 
 debian/extra/lib/mailspell usr/lib/mutt
diff -Nru mutt-1.10.1/debian/mutt.manpages mutt-1.10.1/debian/mutt.manpages
--- mutt-1.10.1/debian/mutt.manpages2018-04-15 10:11:26.0 +0200
+++ mutt-1.10.1/debian/mutt.manpages2018-09-28 09:19:02.0 +0200
@@ -1,6 +1,6 @@
-debian/tmp/usr/share/man/man1/mutt.1
-debian/tmp/usr/share/man/man1/mutt_dotlock.1
-debian/tmp/usr/share/man/man5/muttrc.5
-debian/tmp/usr/share/man/man1/smime_keys.1
-debian/tmp/usr/share/man/man5/mbox.5
-debian/tmp/usr/share/man/man5/mmdf.5
+debian/tmp/usr/share/man/man1/original-mutt.1
+debian/tmp/usr/share/man/man1/original-mutt_dotlock.1
+debian/tmp/usr/share/man/man5/original-muttrc.5
+debian/tmp/usr/share/man/man1/original-smime_keys.1
+debian/tmp/usr/share/man/man5/original-mbox.5
+debian/tmp/usr/share/man/man5/original-mmdf.5
diff -Nru mutt-1.10.1/debian/mutt.postinst mutt-1.10.1/debian/mutt.postinst
--- mutt-1.10.1/debian/mutt.postinst1970-01-01 01:00:00.0 +0100
+++ mutt-1.10.1/debian/mutt.postinst2018-09-28 09:19:02.0 +0200
@@ -0,0 +1,36 @@
+#!/bin/sh
+set -e
+
+if [ "$1" = "configure" ]; then
+
+update-alternatives --install /usr/bin/mutt mutt /usr/bin/original-mutt 1000 \
+   --slave \
+   /usr/share/man/man1/mutt.1.gz mutt.1.gz \
+   /usr/share/man/man1/original-mutt.1.gz \
+   --slave \
+   /usr/share/man/man5/muttrc.5.gz muttrc.5.gz \
+   /usr/share/man/man5/original-muttrc.5.gz \
+   --slave \
+   /usr/share/man/man5/mbox.5.gz mbox.5.gz \
+   /usr/share/man/man5/original-mbox.5.gz \
+   --slave \
+   /usr/share/man/man5/mmdf.5.gz mmdf.5.gz \
+   /usr/share/man/man5/original-mmdf.5.gz
+
+update-alternatives --install /usr/bin/mutt_dotlock mutt_dotlock \
+   /usr/bin/original-mutt_dotlock 1000 \
+   --slave \
+   /usr/share/man/man1/mutt_dotlock.1.gz \
+   mutt_dotlock.1.gz \
+   /usr/share/man/man1/original-mutt_dotlock.1.gz \
+
+update-alternatives --install /usr/bin/smime_keys smime_keys \
+   /usr/bin/original-smime_keys 1000 \
+   --slave \
+   /usr/share/man/man1/smime_keys.1.gz \
+   smime_keys.1.gz \
+   /usr/share/man/man1/original-smime_keys.1.gz \
+
+fi
+
+#DEBHELPER#
diff -Nru mutt-1.10.1/debian/mutt.prerm mutt-1.10.1/debian/mutt.prerm
--- mutt-1.10.1/debian/mutt.prerm   1970-01-01 01:00:00.0 +0100
+++ mutt-1.10.1/debian/mutt.prerm   2018-09-28 09:19:02.0 +0200
@@ -0,0 +1,15 @@
+#!/bin/sh
+set -e
+
+case "$1" in
+   remove|configure)
+   update-alternatives --remove mutt \
+   

Bug#909681: gnome-builder: git plugin not working in a submodule

[Jérémy Lal]

Package: gnome-builder
Version: 3.30.1-2
Followup-For: Bug #909681

This has been fixed upstream by:
https://gitlab.gnome.org/GNOME/gnome-builder/commit/a80ca01093c5ad2e62216af89ea73e11a1ebed37



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

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

Versions of packages gnome-builder depends on:
ii  clang1:6.0-43
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  exuberant-ctags  1:5.9~svn20110310-12
ii  gir1.2-dazzle-1.03.30.1-1
ii  gir1.2-ggit-1.0  0.26.4-1+b1
ii  gir1.2-glib-2.0  1.58.0-1
ii  gir1.2-gtk-3.0   3.24.1-1
ii  gir1.2-gtksource-3.0 3.24.9-1
ii  gir1.2-gtksource-4   4.0.3-1
ii  gir1.2-json-1.0  1.4.2-4
ii  gir1.2-peas-1.0  1.22.0-2
ii  gir1.2-template-1.0  3.30.0-1
ii  gir1.2-vte-2.91  0.54.0-1
ii  gir1.2-webkit2-4.0   2.22.2-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo-gobject21.15.12-1
ii  libcairo21.15.12-1
ii  libclang1-6.01:6.0.1-9
ii  libdazzle-1.0-0  3.30.1-1
ii  libdevhelp-3-5   3.28.1-1
ii  libenchant1c2a   1.6.0-11.1
ii  libflatpak0  1.0.2-1
ii  libfontconfig1   2.13.1-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libgirepository-1.0-11.58.0-1
ii  libgit2-glib-1.0-0   0.26.4-1+b1
ii  libglib2.0-0 2.58.1-2
ii  libgspell-1-11.6.1-1
ii  libgtk-3-0   3.24.1-1
ii  libgtksourceview-4-0 4.0.3-1
ii  libjson-glib-1.0-0   1.4.2-4
ii  libjsonrpc-glib-1.0-13.30.0-1
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpangoft2-1.0-01.42.4-3
ii  libpcre3 2:8.39-11
ii  libpeas-1.0-01.22.0-2
ii  libsoup2.4-1 2.64.1-1
ii  libtemplate-glib-1.0-0   3.30.0-1
ii  libvala-0.42-0   0.42.1-1
ii  libvala-0.42-dev [libvala-dev]   0.42.1-1
ii  libvte-2.91-00.54.0-1
ii  libwebkit2gtk-4.0-37 2.22.2-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  python3  3.6.6-1
ii  python3-gi   3.30.1-1
ii  sysprof  3.30.1-1
ii  valac-0.42-vapi [valac-vapi] 0.42.1-1

Versions of packages gnome-builder recommends:
ii  autoconf  2.69-11
ii  autoconf-archive  20170928-2
ii  automake  1:1.16.1-1.1
ii  autopoint 0.19.8.1-7
ii  build-essential   12.5
ii  flatpak-builder   1.0.0-1
ii  gettext   0.19.8.1-7
ii  intltool  0.51.0-5
ii  libtool   2.4.6-4
ii  meson 0.48.0-2
ii  pkg-config0.29-4+b1
ii  python3-jedi  0.12.0-1
ii  python3-lxml  4.2.5-1
pn  valgrind  

gnome-builder suggests no packages.

-- no debconf information

Bug#880195: closed for me

[Hans-Willi Werres]

Hi,



I'v tested again and this config is OK for proxying proxmox (including vnc):






    ServerName 

    ErrorLog  ${APACHE_LOG_DIR}/Proxy__error.log
    CustomLog ${APACHE_LOG_DIR}/Proxy__access.log combined

    UseCanonicalPhysicalPort Off
    UseCanonicalName         Off
    DocumentRoot             /var/www/html/

    SSLEngine on
    SSLCertificateFile    
/etc/letsencrypt/live//fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live//privkey.pem

    ProxyRequests Off
    ProxyPreserveHost On

    #SSL Connect
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    #Header always set Strict-Transport-Security "max-age=15768000"

    # Encoded slashes need to be allowed
    AllowEncodedSlashes     NoDecode

    RewriteEngine on
    RewriteCond %{HTTP:Connection  } Upgrade [NC]
    RewriteCond %{HTTP:Upgrade  } websocket [NC]
    RewriteRule /(.*) wss://127.0.0.1:8006/$1  [P,L]

    SSLProxyEngine   on
    ProxyRequests    off

    #block Proxy for letsencrypt verification!
    ProxyPass        /.wellknown !
     ProxyPass        / https://127.0.0.1:8006/ flushpackets=On 
connectiontimeout=300 timeout=300
    ProxyPassReverse / https://127.0.0.1:8006/
    ProxyTimeout     600

Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

[YunQiang Su]

https://bugs.llvm.org/show_bug.cgi?id=32020
YunQiang Su  于2018年9月28日周五 上午11:05写道：
>
> Ximin Luo  于2018年9月27日周四 下午12:06写道：
> >
> > Ximin Luo:
> > > Do you have a link to a more detailed description of the problem, so that 
> > > the rest of us can understand it?
> > >
> > > For example James in message 29 gave a very detailed summary of other 
> > > previous problems:
> > >
> > > [29] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881845#29
> > >
> > > Nobody in this thread has stated what the supposed problem actually is 
> > > with these Cavium/Octeon machines. FYI the builds failed recently on 
> > > eberlin and manda-03, and has failed in the past on aql-01. These are all 
> > > octeon, and the other mips64el buildd sil-01 is also octeon. So it seems 
> > > all our buildds are affected by the bug. So the blacklist approach won't 
> > > even work.
> > >
> >
> > Oh I take that back, it seems aql-01 and manda-01,02 are not octeon, I had 
> > previously assumed all the x-{01..03} machines would be the same.
> >
> > Still, please give us a link to the description of the problem.
>
> I cannot remember clear.
> It seems that no branch instruction can be in ll/sc pair on Octeon,
> while llvm does generate code like this.
>
> Loongson has no this problem. anyway, we should patch llvm.
>
>
> >
> > X
> >
> > > Also unless I can understand the problem, I don't feel happy using the 
> > > blacklist as a temporary solution, even if it was going to work.
> > >
> > > X
> > >
> > > YunQiang Su:
> > >> It is still about llvm+octeon problem.
> > >>
> > >> Maybe we can ask pin rustc on Loongson machines.
> > >> Ximin Luo  于2018年9月24日周一 上午2:21写道：
> > >>>
> > >>> Aron Xu:
> >  [..]
> > >
> > > Aron, the next version 1.27.1 is already in binary-NEW so the same 
> > > issue will block testing migration again, when that gets accepted.
> > >
> > > Earlier you said "Binary only upload from porter is allowed [..]" but 
> > > I am not sure the other porters have access to a loongson-3a box. 
> > > Will you continue to run builds of new rustc versions on your box? I 
> > > think that is the key point here.
> > >
> > 
> >  Will do that and see if we can get the issue either fixed or have a
> >  blacklist placed at the same time.
> > 
> > >>>
> > >>> I have just uploaded 1.29.0 to unstable. It will need manual building 
> > >>> with a non-buggy mips machine, to unblock us for Debian Testing. The 
> > >>> previous build 1.29.0+dfsg1-1~exp1 failed due to hanging atomic tests:
> > >>>
> > >>> https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=mips64el&ver=1.29.0%2Bdfsg1-1%7Eexp1&stamp=1537686627&raw=0
> > >>>
> > >>> test sync.rs - sync::Arc (line 124) ... test sync.rs - sync::Arc (line 
> > >>> 124) has been running for over 60 seconds
> > >>> test sync.rs - sync::Arc::downgrade (line 418) ... test sync.rs - 
> > >>> sync::Arc::downgrade (line 418) has been running for over 60 seconds
> > >>> test sync.rs - sync::Arc::get_mut (line 856) ... test sync.rs - 
> > >>> sync::Arc::get_mut (line 856) has been running for over 60 seconds
> > >>> test sync.rs - sync::Arc::make_mut (line 769) ... test sync.rs - 
> > >>> sync::Arc::make_mut (line 769) has been running for over 60 seconds
> > >>> E: Build killed with signal TERM after 150 minutes of inactivity
> > >>>
> > >>> I still think we should just RM rustc on mips64el.
> > >>>
> > >>> X
> > >>>
> > >>> --
> > >>> GPG: ed25519/56034877E1F87C35
> > >>> GPG: rsa4096/1318EFAC5FBBDBCE
> > >>> https://github.com/infinity0/pubkeys.git
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > GPG: ed25519/56034877E1F87C35
> > GPG: rsa4096/1318EFAC5FBBDBCE
> > https://github.com/infinity0/pubkeys.git
>
>
>
> --
> YunQiang Su



-- 
YunQiang Su

Bug#909787: dh-golang: Wrong iterate logic in exec_chunked

[Shengjing Zhu]

Package: dh-golang
Severity: important
Tags: patch

Hmm, I think the previous discussion in #908552 has no relation to
this bug, although the result(incomplete Built-Using info) is same.

So I'm creating a new bug.

On Thu, Sep 27, 2018 at 09:06:34PM +0800, Shengjing Zhu wrote:
> I don't know perl enough, I just debug it with print...
> I debug it with packer(the package I maintain), which also misses some
> dependencies in Built-Using.
> 
> It turns out the wrong logic in exec_chunked func.
> 
> sub exec_chunked {
> my ($cmd, @list) = @_;
> my @result;
> for (my $i = 0; $i < @list; $i += CHUNKSIZE) {
>^^^
>why this is not the length of the array?
> push @result, exec_single($cmd, splice(@list, $i, CHUNKSIZE));
> ^^^
> I find after this sentence, the @list 
> array changes.
> }
> return @result;
> }
> 
> 
> Take packer as example, the uniq(@godeps) has 394 elements. But I find the
> exec_single only executed once, while the CHUNKSIZE is 200.
> 
> tincho, could you help look at the perl code?
> 


Coding with google and stackoverflow...
Here's the patch.

https://salsa.debian.org/go-team/packages/dh-golang/merge_requests/4

I've tested it with packer.
I think it should fix the problem.

Please review and test
(I've CCed #908552 for recording, but please leave comments on the new bug)

After this patch been uploaded, I may go to request binNMU for all go
packages before buster released.
But probably after we changed the Built-Using field to X-Go-Built-Using
(confirm with release/security team, see if this can be implemented without
changing d/control file, etc).

--
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#909786: ITP: node-timeago.js -- format datetime with *** time ago statement

[Pirate Praveen]

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

* Package name: node-timeago.js
  Version : 3.0.2
  Upstream Author : hustcc (http://git.hust.cc/timeago.js)
* URL : https://github.com/hustcc/timeago.js#readme
* License : Expat
  Programming Lang: JavaScript
  Description : format datetime with *** time ago statement

 timeago.js is a simple library (only 2kb) to used to format datetime
with ***
 time ago statement. eg: 3 hours ago. localization is supported.
 .
 Node.js is an event-based server-side JavaScript engine.

Dependency of gitlab 10.x. This will also provide canonical source for
timeago.js embedded in ruby-rails-timeago.



signature.asc
Description: OpenPGP digital signature

Bug#909766: rapmap FTBFS with spdlog 1:1.1.0-1

[Andreas Tille]

Control: tags -1 help

On Thu, Sep 27, 2018 at 11:38:55PM +0300, Adrian Bunk wrote:
> Source: rapmap
> Version: 0.5.0+dfsg-3
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rapmap.html
> 
> ...
> In file included from /build/1st/rapmap-0.5.0+dfsg/src/RapMapUtils.cpp:26:
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp: In function 'void 
> rapmap::utils::writeSAMHeader(IndexT&, std::shared_ptr)':
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:86:18: error: 
> 'MemoryWriter' is not a member of 'fmt'
>  fmt::MemoryWriter hd;
>   ^~~~
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:87:6: error: 'hd' was 
> not declared in this scope
>   hd.write("@HD\tVN:1.0\tSO:unknown\n");
>   ^~
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp: In function 'void 
> rapmap::utils::writeSAMHeader(IndexT&, std::ostream&)':
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:106:18: error: 
> 'MemoryWriter' is not a member of 'fmt'
>  fmt::MemoryWriter hd;
>   ^~~~
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:107:6: error: 'hd' was 
> not declared in this scope
>   hd.write("@HD\tVN:1.0\tSO:unknown\n");
>   ^~
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp: At global scope:
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:125:43: error: expected 
> template-name before '<' token
>  class FixedBuffer : public fmt::Buffer {
>^
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:125:43: error: expected 
> '{' before '<' token
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:125:43: error: expected 
> unqualified-id before '<' token
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:136:44: error: expected 
> class-name before '{' token
>  class FixedWriter : public fmt::Writer {
> ^
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:138:25: error: field 
> 'buffer_' has incomplete type 'rapmap::utils::FixedBuffer'
>  FixedBuffer buffer_;
>  ^~~
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:125:11: note: forward 
> declaration of 'class rapmap::utils::FixedBuffer'
>  class FixedBuffer : public fmt::Buffer {
>^~~
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp: In constructor 
> 'rapmap::utils::FixedWriter::FixedWriter(char*, std::size_t)':
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:141:30: error: expected 
> class-name before '(' token
>  : fmt::Writer(buffer_), buffer_(array, size) {}
>   ^
> /build/1st/rapmap-0.5.0+dfsg/include/RapMapUtils.hpp:141:30: error: expected 
> '{' before '(' token
> ...

I admit my limited knowledge in C++ does not enable me to see a
conncetion between the update of spdlog and these errors but a test
build with libspdlog from testing passed flawlessly.  However, later in
the log there are also

...
In file included from /usr/include/c++/8/memory:81,
 from /usr/include/c++/8/thread:39,
 from /build/rapmap-0.5.0+x/src/RapMapSAMapper.cpp:33:
/usr/include/c++/8/bits/shared_ptr.h:719:5: note: candidate: 'template std::shared_ptr<_Tp> std::make_shared(_Args&& ...)'
 make_shared(_Args&&... __args)
 ^~~
/usr/include/c++/8/bits/shared_ptr.h:719:5: note:   template argument 
deduction/substitution failed:
/build/rapmap-0.5.0+x/src/RapMapSAMapper.cpp:588:80: error: template argument 1 
is invalid
   auto consoleSink = 
std::make_shared();

^
/build/rapmap-0.5.0+x/src/RapMapSAMapper.cpp:589:62: error: no matching 
function for call to 'create(const char [10], )'
   auto consoleLog = spdlog::create("stderrLog", {consoleSink});
  ^


which are looking similar to the problem in #909763 (thus I again took
the freedom to set Gert in CC).

I see another option to work around the current issue since rapmap comes
with its own copy of spdlog (in latest Git version 0.16.3).  I could
revert the exclusion from the rapmap source code as long as upstream has
not yet switched to spdlog 1.1. (and ask in an issue for the migration).

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#903396: patchelf: Makes some binaries impossible to strip

[Drew Parsons]

On 2018-09-28 06:37, Felipe Sateler wrote:


But there are only 2 specific patches needed to fix the strip bug,
https://github.com/NixOS/patchelf/pull/117 [1]
https://github.com/NixOS/patchelf/pull/127 [2]

Can we apply these patches to debian's 0.9 (copy the commits into
debian/patches)? If that builds on all arches then it's a good
resolution for this bug.


I note that a comment in #127 says not all of the problems are
resolved. But if this helps mitigate the problem, I don't have a
problem applying those.

Unfortunately I'm currently a bit lacking on time. Help in the form of
patches welcome, even better if in the form of a salsa MR.



I created branch dparsons/0.9_fix_strip from tag debian/0.9-1 and 
applied the patches (refreshed to patch cleanly against 0.9).

I pushed dparsons/0.9_fix_strip to salsa.

I haven't set up an MR since it needs a target branch. The debian branch 
is too far ahead (latest git).

We want a branch like 0.9 or debian/0.9, i.e.
  git checkout -b 0.9 debian/0.9-1
or   git checkout -b debian/0.9 debian/0.9-1
and then we can merge dparsons/0.9_fix_strip into it.  I figured I 
should let you decide which 0.9 branch to create.


These patches seem to fix the strip problem. The bug I'm addressing is 
managing circular dependencies in hypre,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902102).  This patched 
patchelf 0.9 allows the missing needed links to be added to the hypre 
libs, without breaking dh_strip.


At the same time, I also tested adding the #127 patch to the debian 
branch (i.e. applying it to latest git). It does allow patchelf (latest 
git) to pass tests, and still works with hypre.  I don't know about any 
other unresolved problems, but it fixes what I want for hypre.


So that gives us 2 options for this strip bug
1) merge dparsons/0.9_fix_strip into a branch of debian/0.9-1
   - applies 2 small patches only to 0.9
2) add the #127 patch to the debian branch
   - applies one new small patch, but also other upstream patches from 
git


If you'd like to go ahead with 2), I can create a branch to merge from.

Bug#909698: rakudo: perl6-tap-harness fails to configure: Could not open /usr/share/perl6/install-dist.p6. Failed to stat file: no such file or directory

[Robert Lemmen]

Hi Axel,

On Thu, Sep 27, 2018 at 02:33:05PM +0200, Axel Beckert wrote:
> That might help for other cases, but not this one. As far as I
> understand, the file is at
> 
>   /usr/share/perl6/tools/install-dist.p6
>   ^^^
> 
> but /usr/share/perl6/rakudo-helper.pl looks for it at
> 
>   /usr/share/perl6/install-dist.p6
>   ^
> 
> So from my point of view that bug can be fixed by adding "tools/" to
> the script path at line 43 of /usr/share/perl6/rakudo-helper.pl.

totally correct, the (pending upload) version -2 does just that.

regards  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: PGP signature

Bug#909785: python-pcl: Incomplete debian/copyright and/or "freeware" source code?

[Chris Lamb]

Source: python-pcl
Version: 0.3.0~rc1+dfsg-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Jochen Sprickerhof , 
ftpmas...@debian.org

Hi,

I just ACCEPTed python-pcl from NEW but noticed it was missing 
attribution or similar in debian/copyright for at least some files
listed as "freeware" (!= is this even DFSG-free software?).

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#909784: python-treetime: Incomplete debian/copyright?

[Chris Lamb]

Source: python-treetime
Version: 0.5.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Andreas Tille , ftpmas...@debian.org

Hi,

I just ACCEPTed python-treetime from NEW but noticed it was missing 
attribution in debian/copyright for at least Emma Hodcroft.

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
   `-