Bug#910041: Would you mind uploading the fix / workaround

[Andreas Tille]

Hi Stuart,

some of the Debian Med packages (and probably more) are affected
by this bug and got a "removal from testing warning".  What about
uploading the fix / workaround you prepared in Git?

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#911739: mirrors: Debian mirror ftp.utexas.edu: HTTP 403 on everything for about 5 days

[Matt Roberds]

Package: mirrors
Severity: normal

Dear Maintainer,

The Debian mirror ftp.utexas.edu is currently answering HTTP 403,
apparently to all HTTP queries.

Looking at
https://mirror-master.debian.org/status/mirror-info/ftp.utexas.edu.html
, the last time this site was available was about 2018-10-19, 10:25 UTC
- about 5 days ago.  After that time it always responded "Forbidden" to
the mirror status queries made by that page.

On my Debian system, I have these lines in /etc/apt/sources.list

---
deb http://ftp.utexas.edu/debian/ stretch main non-free contrib
deb-src http://ftp.utexas.edu/debian/ stretch main non-free contrib
---

but when I tried to install some new packages just now, I only got
HTTP 403 errors from ftp.utexas.edu for all the packages.

I tried manually going to http://ftp.utexas.edu/debian/ in various Web
browsers (Firefox, lynx, and wget), and it answers 403 to each browser.

I also tried the top level, http://ftp.utexas.edu/ , in those same three
browsers, and it answers 403 to each of them as well.

Interestingly, anonymous *FTP* access to ftp.utexas.edu works - you can
log in - but neither /pub nor /pub/mirror are available once you log in.

As of the date of this bug report, the University of Texas is not
reporting any outages on their public site:

https://ut.service-now.com/utss/

The university still mentions their FTP server on their site, but says
it "can be accessed by members of the university community" (horrible
URL ahead):

https://ut.service-now.com/utss/catalogoverview.do?sysparam_citems_id=4ad65c7c4ff9d200f6897bcd0210c77f_cat_id=e0d08b13c3330100c8b837659bba8fb4%2CInformation%20Technology_sys_id=%3Csubcategory.parent%3E%2CTechnology%20Infrastructure%20&%20Management_click_name=features

I don't work for or attend the University of Texas.  It is possible that
they have decided to restrict their site to university users only, or to
discontinue it.

Thanks for your help!

Matt Roberds

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

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

Bug#911666: mediawiki: Does not work with PHP 7.3

[Joseph Nuthalapati]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Kunal,

Thanks for the help. 

The issue seems to be with libapache2-mod-php indeed. The Debian
package does not automatically disable the older module and
enable the new one.

I raised a bug report on libapache2-mod-php (#9111738). Will
close this one.

Kunal Mehta  wrote:
> Hi,
> 
> On 10/23/18 2:51 AM, Joseph Nuthalapati wrote:
> > MediaWiki doesn't recognize the packages php-mbstring, php-xml
> > and php-sqlite3 if their PHP 7.3 versions are installed.
> > 
> > On Debian testing, the installation fails.
> > On Debian unstable, the installation works but MediaWiki fails to
> > start because it doesn't recognize php7.3-sqlite3 as its database
> > driver. Manually installing php7.2-sqlite3 fixes this.
> 
> I'm not able to reproduce this locally on unstable, I have
> MediaWiki running under PHP 7.3 just fine.
> 
> Given that installing php7.2-sqlite3 fixed your issue, I
> suspect that Apache was still using the php7.2 module instead
> of php7.3. Maybe you need to manually disable the old module
> (sudo a2dismod php7.2) and then enable the new one (sudo
> a2enmod php7.3)?
> 
> You can verify that Apache is properly using 7.3 by creating a
> PHP file that just calls ` seeing what the output is.
> 
> -- Kunal
>

- -- 
Regards,
Joseph Nuthalapati

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE4rQIdbX3Xc6j+BCYU5jwCi+kPDUFAlvP/tQACgkQU5jwCi+k
PDWdhQ//Y7tIcNQFDsNIWyTLkLKQymUUm/heNUXWH4wrMx/RoRpPgQh0mCnX9gWV
9ycD3ZVAzeeBXTPgsI5hrbbM4+cOhXmw2PJSysh0/zZUP8fHy/PMbemfwChWFqvD
0tDAAaYmVHobg1xv9H3Ni8GfAfEbV0HjNDJbKBryIKepIDCDlLh/2l7tQDm5R9iy
1NOHbgB9yn66Wuvb8gPIKzKZMcobQoHf+H1doMZ507wE4KT3XxrYn86Tq8TsJgqC
LzSQ+XxQYGecAMTObO8QnuI0BXJMejCOuEIzXwBC+n4fYktYpD7D9mVX7mYZVtB4
X7CU97S9Qrqkk4v7paXCkhJu/KxajXMthaLKmoiFDUe9fM+xGdHUFCTlPK4ZWXG3
5YRHK2SmG71psdga3++2HLxQMjHyJD/3ZNIC2Fob8SD+mKo/YCb0Bl3XWh+/Kkeb
TlCmXFla8teVjK5MQhv/emN5jlAn0yRxJHhXpGQNg5LxUMknAwaAVHJ8p0t+nzv1
qLqVIy3RQbnFdjVeRDzEo+Vqkev5I1Hrdppo4nFMuzQPxai13E/dJckwdp77d0KR
m1/sfI0XcrTQZ4Z+nN2MDgClQqbcm7UvoAOsy1MSJeNhFRAkzd5wdgRT9DqHJy/I
62zE+tTR+iM3EKKUZtst30Utk4EWhdi3quKAuPdaJg9VeZa+KB8=
=4sdC
-END PGP SIGNATURE-

Bug#887714: g15composer: Detect freetype2 using pkg-config

[Chris Knadle]

tags 887714 + pending
thanks

Hugh McMaster:
> A rebuild of your package with freetype 2.9.1 installed confirmed that your
> package will FTBFS once the new version of freetype enters unstable. In
> almost all cases, this build failure was caused by the configure script not
> detecting the freetype libraries, as freetype-config is not shipped in
> 2.9.1.
> 
> Given the build failure and upcoming upload of freetype 2.9.1, I am raising
> the severity of this bug to Serious.
> 
> Please use pkg-config to detect freetype.

I've prepared an NMU to fix this bug (as 3.2-2.1) and I'm attaching the
NMU diff to this message.  I've uploaded it to DELAYED/5.  Please let me know if
you'd like the upload delayed longer.

Thanks

   -- Chris


-- 
Chris Knadle
chris.kna...@coredump.us
diff -u g15composer-3.2/debian/control g15composer-3.2/debian/control
--- g15composer-3.2/debian/control
+++ g15composer-3.2/debian/control
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Giacomo Catenazzi 
 Build-Depends: cdbs, debhelper (>= 5), autotools-dev, libfreetype6-dev,
- libg15-dev, libg15render-dev (>= 1.2-3), libg15daemon-client-dev
+ libg15-dev, libg15render-dev (>= 1.2-3), libg15daemon-client-dev, pkg-config
 Standards-Version: 3.8.2
 Homepage: http://www.g15tools.com/
 
diff -u g15composer-3.2/debian/changelog g15composer-3.2/debian/changelog
--- g15composer-3.2/debian/changelog
+++ g15composer-3.2/debian/changelog
@@ -1,3 +1,12 @@
+g15composer (3.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control:
+- Add pkg-config to Build-Depends
+  * patched configure and configure.in to use pkg-config (Closes: #887714)
+
+ -- Christopher Knadle   Wed, 24 Oct 2018 04:20:30 +
+
 g15composer (3.2-2) unstable; urgency=low
 
   * Update policy, add ${misc:Depends}, add homepage
only in patch2:
unchanged:
--- g15composer-3.2.orig/configure
+++ g15composer-3.2/configure
@@ -3637,8 +3637,8 @@
 #define TTF_SUPPORT 1
 _ACEOF
 
-	CFLAGS="$CFLAGS `freetype-config --cflags`"
-	CXXFLAGS="$CXXFLAGS `freetype-config --cflags`"
+	CFLAGS="$CFLAGS `pkg-config --cflags freetype2`"
+	CXXFLAGS="$CXXFLAGS `pkg-config --cflags freetype2`"
 	FTLIB="-lfreetype"
 	ttf_support="yes"
 else
only in patch2:
unchanged:
--- g15composer-3.2.orig/configure.in
+++ g15composer-3.2/configure.in
@@ -19,8 +19,8 @@
 if [[[ "$enableval" = "yes" ]]]; then
 		AC_CHECK_LIB([g15render], [g15r_ttfLoad],
 	AC_DEFINE(TTF_SUPPORT, [1], [Define to 1 to enable FreeType2 support])
-	CFLAGS="$CFLAGS `freetype-config --cflags`"
-	CXXFLAGS="$CXXFLAGS `freetype-config --cflags`"
+	CFLAGS="$CFLAGS `pkg-config --cflags freetype2`"
+	CXXFLAGS="$CXXFLAGS `pkg-config --cflags freetype2`"
 	FTLIB="-lfreetype"
 	ttf_support="yes",
 			AC_MSG_ERROR(["libg15render does not support ttf functions. please reconfigure with --enable-ttf"])


signature.asc
Description: OpenPGP digital signature

Bug#911738: libapache2-mod-php: libapache2-mod-php7.2 is still the active PHP module even after upgrade to PHP 7.3

[Joseph Nuthalapati]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: libapache2-mod-php
Version: 1:7.3+66
Severity: important

Dear maintainer,

Upgrading to PHP 7.3 breaks all PHP applications running on the
Apache server, because the PHP libraries are all at version 7.3
but the Apache PHP module still stays at version 7.2.

A user has to manually disable the older version and enable the
new version of the module. It is expected that the Debian package
would take care of something like this to enable a smooth upgrade
process.

- -- 
Regards,
Joseph Nuthalapati

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE4rQIdbX3Xc6j+BCYU5jwCi+kPDUFAlvP/fwACgkQU5jwCi+k
PDXLpg//eP39BaYwTPBzxJvhY5rIG7I7DRFaDSBvfdfV2dTy4gv9ibAhma/89Xm3
NhOv9nO7k3qFT3vlp0Hj8snp9GakNLYxtpGJVFoe4xXu/8Vzc9A0ToIJeGGWhNkb
8MbXzdxDJqa4qE3XnIi6zMrJoy5RV0l2NiyDFOUX4nPiLsbciZZFg8MARyN9gBwI
zgnS1D1VsqJO8wBvlrUhQ9ZR9+TLn7sWRKZPG+ShFoeX3Do7puG12jLBCOmAGLxR
vAxH052oRVOvNgjuo+SDl+TOs4LRRABtnHqxVHe/21Lhwy1ERACUA+pGIrWrwMHx
6WCZAeReWPRU7d1Y1PL4dyqpt7qVmLe3Dqp3u7Wq3YKSIVLDQ7/M4oit9UsemusG
GF5xOOGP6RbhSJYOiTa+x/xvSNtS/biOP50wvOenf1+aJlcz24kItFTfhs1EjFIK
b+7iS52iyWzJxBPp7S9VFr7qj+RJTzYdWWKhKLqSuO2neGhgmNyU5CLbCkoES/xQ
bfEE1XhwP30gUJTsPBlm78wOd2e8DzawSoUcOALGtMOUsBZOo0I68xb9Q2c8j1f8
CeYsxox6LDHMRhvAJYezX2U/xGG97E2pfNOK2uBKQt+zMWEcEOsgf+IUanMDnHVH
qniciKRhkNf8udpoIXImgn9K8cV93MVWy1G05ei6VGkgJhlJcaQ=
=jMXo
-END PGP SIGNATURE-

Bug#911737: 'Warning: Unresponsive script' doesn't give URL

[Tovar]

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

The pop-up error window, "Warning: Unresponsive script" gives only the
pathname of the script that appears to be stuck, but not the web page
it is associated with.  Also, at this point, Firefox is usually rather
unresponsive.  Here's an example:
 ___
|
| A script on this page may be busy, or it may have stopped responding. You can 
| stop the script now, or you can continue to see if the script will complete.
|
| Script: chrome://global/content/bindings/notification.xml:337
|
| [ ] Don't ask me again
|[  Stop script  ] [  Continue  ]
|___

Thus one cannot find out who to report script problems to and/or which
website(s) to avoid to prevent Firefox from getting stuck.

Since it doesn't show what web page causes this, it is difficult to
explain how to reproduce this problem.  But adding the web page URL
to the error window will help avoid the error, mitigate it and/or 
begin the process of getting it fixed.

Please add to the pop-up window the URL that invokes the unresponsive
script.

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-11+deb9u3
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.40.5-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-18+deb9u1
ii  libvpx4   1.6.1-3+deb9u1
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
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.12-3+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages firefox-esr recommends:
ii  libavcodec57  10:3.3.8-dmo1+deb9u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-3
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-3
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libgtk2.0-02.24.31-2
ii  pulseaudio 10.0-1+deb9u1

-- no debconf information

--1540353332-eximdsn-347539218--

Bug#911736: pristine-tar: Improvement on completion script

[Dmitry Bogatov]

Package: pristine-tar
Version: 1.44
Severity: minor

Dear Maintainer,

please consider proposed improvements for completion script. Completion
of --signature-file option, git refs and more!

For your convenience, I am attaching both series of git commit in mbox
format (suitable for git-am) and new version of script.
>From 4a2c798d5638c4ebeecc7e1a03ac7d52bbf47cd5 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Tue, 23 Oct 2018 19:06:41 +
Subject: [PATCH 1/9] Remove have() function from bash-completion

This function is not needed, since completion scripts are loaded
dynamically, on first use.

For more information, see /usr/share/bash-completion/bash_completion
---
 bash_completion/pristine-tar | 12 
 1 file changed, 12 deletions(-)

diff --git a/bash_completion/pristine-tar b/bash_completion/pristine-tar
index a0b..69c2a17 100644
--- a/bash_completion/pristine-tar
+++ b/bash_completion/pristine-tar
@@ -1,14 +1,3 @@
-
-have()
-{
-unset -v have
-# Completions for system administrator commands are installed as well in
-# case completion is attempted via `sudo command ...'.
-PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin type $1 &>/dev/null &&
-have="yes"
-}
-
-have pristine-tar && 
 _pristine_tar()
 {
   COMPREPLY=()
@@ -33,5 +22,4 @@ _pristine_tar()
 } &&
 complete -F _pristine_tar pristine-tar
 
-unset -f have
 # vim: ft=sh

>From f1d3b695db7c64624596b8c4ba2aa73ac5dff02a Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Wed, 24 Oct 2018 00:05:03 +
Subject: [PATCH 2/9] Complete long versions of options

Long versions are much more useful, since they are self-explanatory.
Completing short options saves little to no typing, and provides little
information to user, who do not already know what option they need.
---
 bash_completion/pristine-tar | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/bash_completion/pristine-tar b/bash_completion/pristine-tar
index 69c2a17..1805c1a 100644
--- a/bash_completion/pristine-tar
+++ b/bash_completion/pristine-tar
@@ -1,12 +1,21 @@
 _pristine_tar()
 {
+  local options='
+--verbose
+--debug
+--message
+--signature-file
+--recompress
+--recompress-threhold-bytes
+--recompress-threhold-percent
+  '
   COMPREPLY=()
   _get_comp_words_by_ref -n : cur prev
   #cur=`_get_cword :`
   #prev=`_get_pword`
 
   if [[ "$cur" == -* ]]; then
-COMPREPLY=( $( compgen -W '-v -d -f' -- "$cur" ) )
+COMPREPLY=( $( compgen -W "${options}" -- "$cur" ) )
 return 0
   fi
 

>From 9da80d0ab0e8bcf36055a20bed64ab62ad52f152 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Wed, 24 Oct 2018 00:22:16 +
Subject: [PATCH 3/9] Make bash completion more robust

Test, whether we are completing subcommands by checking
$COMP_CWORD index, not previous word.
---
 bash_completion/pristine-tar | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bash_completion/pristine-tar b/bash_completion/pristine-tar
index 1805c1a..48e9b4a 100644
--- a/bash_completion/pristine-tar
+++ b/bash_completion/pristine-tar
@@ -19,7 +19,7 @@ _pristine_tar()
 return 0
   fi
 
-  if [[ "$prev" == 'pristine-tar' ]]; then
+  if [[ "${COMP_CWORD}" = 1 ]]; then
 COMPREPLY=( $( compgen -W 'gendelta gentar commit checkout verify list' -- 
"$cur" ))
 return 0
   fi

>From 5eb983690b3cb0aca24f42fe11293da255e64cdc Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Wed, 24 Oct 2018 00:42:41 +
Subject: [PATCH 4/9] Keep bash-completion script ad 80 column limit

Factor list of sub-commands to separate local variable to make script
source to not exceed 80 column.
---
 bash_completion/pristine-tar | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/bash_completion/pristine-tar b/bash_completion/pristine-tar
index 48e9b4a..26e2384 100644
--- a/bash_completion/pristine-tar
+++ b/bash_completion/pristine-tar
@@ -9,6 +9,14 @@ _pristine_tar()
 --recompress-threhold-bytes
 --recompress-threhold-percent
   '
+  local subcommands='
+gendelta
+gentar
+commit
+checkout
+verify
+list
+  '
   COMPREPLY=()
   _get_comp_words_by_ref -n : cur prev
   #cur=`_get_cword :`
@@ -20,7 +28,7 @@ _pristine_tar()
   fi
 
   if [[ "${COMP_CWORD}" = 1 ]]; then
-COMPREPLY=( $( compgen -W 'gendelta gentar commit checkout verify list' -- 
"$cur" ))
+COMPREPLY=( $( compgen -W "${subcommands}" -- "$cur" ))
 return 0
   fi
 

>From 4b01a5589184fa667d271033f83d9f2ec1240062 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Wed, 24 Oct 2018 01:09:41 +
Subject: [PATCH 5/9] Improve handling f non-completeable options

---
 bash_completion/pristine-tar | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/bash_completion/pristine-tar b/bash_completion/pristine-tar
index 26e2384..f79fd2a 100644
--- a/bash_completion/pristine-tar
+++ b/bash_completion/pristine-tar
@@ -32,6 +32,12 @@ _pristine_tar()
 return 0
   fi
 
+  case "${prev}" in
+

Bug#911127: olm FTCBFS: python build dependency not installable

[Helmut Grohne]

Hi Hubert,

On Tue, Oct 23, 2018 at 11:02:13PM -0400, Hubert Chathi wrote:
> Thanks for filing this issue.  Olm 3 was released today, which has new
> Python bindings, and which will make python-olm arch-dependent.  I'll
> take a look at this issue when I create a new package, but having just
> skimmed this briefly, suggestion are welcome on how having python-olm
> being arch-dependent will affect this issue.

That'll render my patch essentially useless. I suggest that you leave
this bug open as long as python-olm is arch-independent. Once it becomes
arch-dependent, you close it with tags + wontfix. The closure will
prompt me to look into it again.

Python extensions can still be cross built. The dh-python dependency is
fine. python-all-dev is the problematic once. For enabling cross
compilation you typically use "libpython-all-dev, python-all-dev:native"
instead. Given that ":native" is irrelevant for native builds and that
python-all-dev depends on libpython-all-dev that works for native builds
as well. Then it depends on how the extension is built. The most common
ways include some form of setup.py and autotools. I'd expect autotools
to just work. For setup.py, you need to pass the cross toolchain along.
I think dh-python does that for Python 3.x already. In general, going
with the helpers tends to work best (e.g. use "dh_auto_configure --
--with-foo" instead of "./configure --with-foo").

Helmut

Bug#911735: origami-pdf: pdfwalker does not start

[Zagor]

Package: origami-pdf
Version: 2.0.0-1
Severity: normal

Dear Maintainer,

I found this software and I would like to test it but it did not started.

Since the moment it doesn't have a launcher I tried to launch it from a
terminal and I received this output:

$ pdfwalker
/usr/lib/ruby/vendor_ruby/origami/object.rb:28: warning: constant ::Bignum is
deprecated
/usr/lib/ruby/vendor_ruby/origami/object.rb:34: warning: constant ::Fixnum is
deprecated
/usr/lib/ruby/vendor_ruby/origami/numeric.rb:104: warning: constant ::Bignum is
deprecated
/usr/share/origami/gui/treeview.rb:54:in `':
'Pango::WEIGHT_NORMAL' has been deprecated. Use 'Pango::Weight::NORMAL' or
':normal'.
/usr/share/origami/gui/treeview.rb:54:in `':
'Pango::STYLE_NORMAL' has been deprecated. Use 'Pango::Style::NORMAL' or
':normal'.
/usr/share/origami/gui/treeview.rb:376:in `reset_appearance':
'Pango::WEIGHT_BOLD' has been deprecated. Use 'Pango::Weight::BOLD' or ':bold'.
/usr/share/origami/gui/treeview.rb:385:in `reset_appearance':
'Pango::STYLE_ITALIC' has been deprecated. Use 'Pango::Style::ITALIC' or
':italic'.
/usr/share/origami/gui/treeview.rb:390:in `reset_appearance':
'Pango::STYLE_OBLIQUE' has been deprecated. Use 'Pango::Style::OBLIQUE' or
':oblique'.
Traceback (most recent call last):
7: from /usr/bin/pdfwalker:6:in `'
6: from /usr/share/origami/gui/walker.rb:59:in `start'
5: from /usr/share/origami/gui/walker.rb:59:in `new'
4: from /usr/share/origami/gui/walker.rb:93:in `initialize'
3: from /usr/share/origami/gui/treeview.rb:28:in `create_treeview'
2: from /usr/share/origami/gui/treeview.rb:28:in `new'
1: from /usr/share/origami/gui/treeview.rb:63:in `initialize'
/usr/lib/ruby/vendor_ruby/glib2/deprecatable.rb:112:in `const_missing':
uninitialized constant Pango::FontDescription::Weight (NameError)
Did you mean?  Pango::Weight


I can't say more, thanks for you attention.

Daniel



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

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

Versions of packages origami-pdf depends on:
ii  ruby  1:2.5.1
ii  ruby-origami  2.0.0-1

Versions of packages origami-pdf recommends:
ii  ruby-gtk2  3.2.9-1

origami-pdf suggests no packages.

-- no debconf information

Bug#911127: olm FTCBFS: python build dependency not installable

[Hubert Chathi]

Hi Helmut,

Thanks for filing this issue.  Olm 3 was released today, which has new
Python bindings, and which will make python-olm arch-dependent.  I'll
take a look at this issue when I create a new package, but having just
skimmed this briefly, suggestion are welcome on how having python-olm
being arch-dependent will affect this issue.

Hubert

On Tue, 16 Oct 2018 06:34:26 +0200, Helmut Grohne  said:

> Source: olm Version: 2.2.2+git20170526.0fd768e+dfsg-1 Tags: patch
> User: helm...@debian.org Usertags: rebootstrap

> olm fails to cross build from source, because its Build-Depends
> request the host architecture python and that fails to
> install. Looking deeper, one sees that python is used in two
> capacities: Once for running rst2html and also for creating
> python-olm. The latter is only necessary for indep builds and the
> former wants the build architecture python.

> So we can shrink the problem by removing python-olm from the arch-only
> build. Doing so allows demoting python-all-dev to Build-Depends-Indep,
> which is irrelevant to cross building.

> The attached patch implements the moving of Build-Depends. Using
> diffoscope and reproducible builds I verified that the resulting .debs
> do not vary accross full builds arch-only builds or indep-only builds.

> Please close this bug when removing python-all-dev from Build-Depends
> even though that might not be sufficient for making olm cross
> buildable.  In case of further issues, I shall file further bug
> reports.

> Helmut

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#911734: yubikey-luks: enrolling yubikey does not work

[Norbert Preining]

Package: yubikey-luks
Version: 0.3.3+3.ge11e4c1-1
Severity: grave
Justification: renders package unusable

Dear all,

I want to use my yubikey (Neo) for unlocking the LUKS volume
of my laptop, and did the necessary steps of initialization
as well as
yubikey-enroll-luks -d /dev/sdaN
for my luks device.

Enrollment did not report any errors whatsoever.

Albeit, rebooting didn't allow me to use the yubikey and only the
complete passphrase is accepted.

Thanks

Norbert


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

Kernel: Linux 4.18.14 (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 yubikey-luks depends on:
ii  cryptsetup   2:2.0.4-3
ii  initramfs-tools  0.132
ii  yubikey-personalization  1.19.0-1

yubikey-luks recommends no packages.

yubikey-luks suggests no packages.

-- no debconf information

Bug#898940: lastpass-cli: error: Peer certificate cannot be authenticated with given CA certificates

[Chris Lamb]

Untested patch for stable:

  --- pins.h.orig   2018-10-23 23:11:58.073852655 -0400
  +++ pins.h2018-10-23 23:12:10.901914502 -0400
  @@ -5,8 +5,12 @@
"HXXQgxueCIU5TTLHob/bPbwcKOKw6DkfsTWYHbxbqTY=",
/* current lastpass.eu primary (AddTrust) */
"lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=",
  + /* future lastpass root CA (GlobalSign R1) */
  + "K87oWBWM9UZfyddvDfoxL+8lpNyoUB2ptGtn0fv6G2Q=",
/* future lastpass root CA (GlobalSign R2) */
"iie1VXtL7HzAMF+/PVPR9xzT80kQxdZeJ+zduCB3uj0=",
  + /* future lastpass root CA (GlobalSign R3) */
  + "cGuxAXyFXFkWm61cF4HPWX8S0srS9j0aSqN0k4AP+4A=",
/* future lastpass.com primary (leaf) */
"0hkr5YW/WE6Nq5hNTcApxpuaiwlwy5HUFiOt3Qd9VBc=",
/* future lastpass.com backup (leaf) */


Regards,

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

Bug#868551: File conflict between redis-server-dbgsym and redis-tools-dbgsym

[Chris Lamb]

Hi,

> File conflict between redis-server-dbgsym and redis-tools-dbgsym

This (still) affects stable but I fear the fix:

 redis (4:4.0.0-2) unstable; urgency=medium

   * Make /usr/bin/redis-server in the main redis-server package a symlink to
 /usr/bin/redis-check-rdb in the redis-tools package.

 Whilst this prevents a wasteful duplication of a binary, it moreover
 ensures there are no duplicate debug symbols which was preventing the
 simultaneous installation of the redis-server-dbgsym and
 redis-tools-dbgsym packages.

 Note that this results in the peculiar (and possibily confusing) situation
 where the main package does not have the main binary anymore, or indeed
 any binaries whatsoever. See also the previous parallel attempt at a
 symlink changes in 3.2.6-3 which was reverted in 3.2.8-3. Thanks to Adrian
 Bunk for the report. (Closes: #868551)
  
… is too invasive for a stable update. The version in stable is a
little outdated anyway, and the backport is recommended anyway…

Thoughts?


Regards,

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

Bug#911733: libfiu: FTBFS on 32-bit architectures?

[Chris Lamb]

Source: libfiu
Version: 0.97-1
Severity: serious
Justification: fails to build from source
X-Debbugs-CC: Alberto Bertogli 

Hi,

libfiu fails to build from source in sid/i386:

[…]

for i in modules/libc.mm.mod.fl modules/libc.str.mod.fl modules/linux.io.mod.fl 
modules/posix.io.mod.fl modules/posix.mm.mod.fl modules/posix.proc.mod.fl 
modules/posix.stdio.mod.fl; do cat $i >> function_list; done
In file included from modules/posix.stdio.mod.c:9:
modules/posix.stdio.mod.c:568:20: error: conflicting types for 'ftello64'
 mkwrap_top(off_t , ftello64, (FILE *stream), (stream), (FILE *), (-1))
^~~~
./codegen.h:99:8: note: in definition of macro 'mkwrap_def'
  RTYPE NAME PARAMS \
^~~~
modules/posix.stdio.mod.c:568:1: note: in expansion of macro 'mkwrap_top'
 mkwrap_top(off_t , ftello64, (FILE *stream), (stream), (FILE *), (-1))
 ^~
In file included from modules/posix.stdio.mod.c:14:
/usr/include/stdio.h:751:18: note: previous declaration of 'ftello64' was here
 extern __off64_t ftello64 (FILE *__stream) __wur;
  ^~~~
make[4]: *** [Makefile:67: modules/posix.stdio.mod.o] Error 1
m
[…]

The full build log is attached or can be viewed here:

  
https://buildd.debian.org/status/fetch.php?pkg=libfiu=i386=0.97-1=1540338469=1

§

Any ideas? There are some other failures that can be viewed here:

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

… which looks like 32-bit architectures only. (Click "Build
Attempted"...)


Best wishes,

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


libfiu.0.97-1.sid.i386.log.txt.gz
Description: Binary data

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[Jeremiah Mahler]

Re: Yves-Alexis,

On Tue, Oct 23, 2018 at 05:29:02PM +0200, Yves-Alexis Perez wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Tue, 2018-10-23 at 08:07 -0700, Jeremiah Mahler wrote:
> > Re: Yves-Alexis,
> > 
> > On Tue, Oct 23, 2018 at 11:01:21AM +0200, Yves-Alexis Perez wrote:
> > [...]
> > > On Mon, 2018-10-22 at 20:48 -0700, Jeremiah Mahler wrote:
> > > > I am experiencing this problem and I found a workaround ...
> > > 
> > > Did you try the other workarounds (vt-switch back and forth)? Was it not
> > > working?
> > > 
> > 
> > Alt-F1, Ctrl-Alt-Backspace, etc, don't get me to the terminal prompt.
> > Maybe I'm using the wrong keys in Xfce?
> 
> Try Ctrl-Alt-F1 then Ctrl-Alt-F8.

These don't work for me either.

> > 
> > > > If I create an Xorg config file that says to use the Intel
> > > > driver it works.
> > > 
> > > Interesting. There might be a bad interaction with the driver where it
> > > doesn't
> > > switch the backlight on or something.
> > > > Perusing the /var/log/Xorg.0.log finds that it was using the
> > > > fbdev driver before.
> > > 
> > > Are you sure? I think Intel cards should be using the “modesetting” driver
> > > by
> > > default.
> > > 
> > 
> > Hmm, I found references to both fbdev and modesetting modules in the
> > Xorg.0.log (see attached).
> 
> That's interesting indeed. Do you have multiple video adapters or just one?
> Can you try to remove xserver-xorg-video-fbdev and see what happens?
> 

As far as I can tell I just have one video adapter.
It is just a laptop and I'm not using any external monitors.

$ lspci
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 
08)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)
00:08.0 System peripheral: Intel Corporation Skylake Gaussian Mixture Model
00:13.0 Non-VGA unclassified device: Intel Corporation Sunrise Point-LP 
Integrated Sensor Hub (rev 21)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller (rev 21)
[...]

If I apt-get purge xserver-xorg-video-fbdev and remove
/etc/X11/xorg.conf.d/20-intel.conf the screen will lock
up as before.

With xserver-xorg-video-fbdev still removed, if I re-add
/etc/X11/xorg.conf.d/20-intel.conf then light-locker works
again.

Interestingly, xserver-xorg-video-modesetting is removed on
my system too.

> Regards,
> - -- 
> Yves-Alexis
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlvPPj4ACgkQ3rYcyPpX
> RFu+vwf9Fye72g4ifG+dRcnYDzMyXGCC9iz+5ovkj/Vmvm2VhB1YQX22BtqurFkx
> Nw3w0N5YqKto0geRmnaVUNkQgXeT4kRmhl4RGqmvYJvyfy939RY3qBNu4H7gz0m6
> F7bUMvxcB427Tbs1+AAkTDkMRvcek554Y2qFkGsfPkF19MfCIYWi2AZofon7yNPR
> iWPV9emqoIUmhsIg2xptEO3+xpU+m17pDtrf763t2nP8kg8mYbzV7vyKUgmjz1Wd
> dw9scn3JR8CNpjHfrL21JQhFvaVMuKZoomw8XXd6wHuh8VFo5caLU7GoOF8SMRgg
> /G30+guXUHQSMlsq7JItPO9I5CLp6A==
> =nwQh
> -END PGP SIGNATURE-

-- 
- Jeremiah Mahler

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[Chris Lamb]

Package: hiredis
Version: 0.14.0-1
Severity: wishlist

Hi,

Thank you for packaging 0.14.0 in #907259. Would it be possible
backport this version to stretch-backports? That would allow me
Redis to use the system hiredis for its own backport too.

Thanks in advance.


Regards,

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

Bug#910444: OpenRC called by update-rc.d should read defaults from headers

[Benda Xu]

Hi Adam,

Adam Borowski  writes:

> But something is amiss: that refactorization happened a year ago, yet there
> was no breakage I nor anyone else noticed.  And I obviously installed quite
> a few daemons in the meantime on systems running unstable (although I don't
> recall any on unstable in last 1-2 months).  Yet on current unstable
> installing new init scripts with openrc is broken (tested with 0.38 and
> 0.34.something) -- if it could have worked before, what did change?
> I'm pretty confused...

The update-rc.d calling of OpenRC is designed to be like this: insserv
makes new symlinks in /etc/rc?.d/, and then OpenRC interprets the
symlinks to populate the state to its own /etc/runlevels.

However, after the refactorization, OpenRC runs before insserv.  With a
refresh new installation of /initscripts/, OpenRC finds nothing in
/etc/rc?.d and it does nothing.  Only after that insserv installs
symlinks there.  At this stage, OpenRC knows nothing of /initscripts/.

But, the next time if some other daemon is installed, OpenRC is called
again by update-rc.d and it finds the left overs of /initscripts/
symlinks and synchroizes them.  Bug disappears!

That's why this bug is so hard to discover.  Many thanks to Axel!

Cheers,
Benda

Bug#909795: ITS: unrar-nonfree

[Norbert Preining]

Hi Martin,

> A brief look over the debdiff looks like there;'s nothing completely insane 
> in there.

Thanks.

> How about an NMU + Adding yourself to the Uploaders.

Well, these two are incompatible, either NMU or I'm an Uploader ;-)

I took the liberty to add myself to the Uploaders, and uploaded 5.6.6-1
You are still listed as maintainer, and feel free to remove me again if
you don't agree with it.

> Then we can work in the next few weeks (sorry, literally started a new Job on 
> Monday - so I'm super busy at the moment) and get a shared git repo or 
> similar setup.

Great. Do you have a git repo which you used? If yes, can you make it
available, then I can set up a repo at salsa where both of us can work 
and add my changes.

Otherwise, I can import the old versions as far as they are still
available into a new git repo, and then add my changes.

All the best

Norbert

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

Bug#911731: packagekitd: random crash (SIGABRT) during unattended-upgrades minimal steps upgrade

[Paul Wise]

Package: packagekit
Version: 1.1.11-1
Severity: normal
File: /usr/lib/packagekit/packagekitd
Usertags: crash

Yesterday during an unattended-upgrades minimal steps upgrade,
packagekitd crashed randomly with a SIGABRT.

If the information below is not useful, please close this bug.

$ ll 
/var/crash/0/16396-0-0-6-1540269143-chianamo--usr-lib-packagekit-packagekitd.core
-rw--- 1 pabs pabs 74M Oct 23 12:32 
/var/crash/0/16396-0-0-6-1540269143-chianamo--usr-lib-packagekit-packagekitd.core

$ grep -A27 '2018-10-23  12:30' /var/log/apt/history.log
Start-Date: 2018-10-23  12:30:15
Commandline: /usr/bin/unattended-upgrade
Upgrade: cups-filters-core-drivers:amd64 (1.21.3-1, 1.21.3-2)
End-Date: 2018-10-23  12:30:29

Start-Date: 2018-10-23  12:31:06
Commandline: /usr/bin/unattended-upgrade
Upgrade: libapparmor-perl:amd64 (2.13-8, 2.13.1-1)
End-Date: 2018-10-23  12:31:14

Start-Date: 2018-10-23  12:31:55
Commandline: /usr/bin/unattended-upgrade
Upgrade: libcupsfilters1:amd64 (1.21.3-1, 1.21.3-2)
End-Date: 2018-10-23  12:32:05

Start-Date: 2018-10-23  12:32:43
Commandline: /usr/bin/unattended-upgrade
Upgrade: libfontembed1:amd64 (1.21.3-1, 1.21.3-2)
End-Date: 2018-10-23  12:32:49

Start-Date: 2018-10-23  12:33:26
Commandline: /usr/bin/unattended-upgrade
Upgrade: libopenmpt-modplug1:amd64 (0.3.12-1, 0.3.13-1)
End-Date: 2018-10-23  12:33:34

Start-Date: 2018-10-23  12:34:10
Commandline: /usr/bin/unattended-upgrade
Upgrade: libqt5help5:amd64 (5.11.1-6, 5.11.2-3)
End-Date: 2018-10-23  12:34:16

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' 
--core 
/var/crash/0/16396-0-0-6-1540269143-chianamo--usr-lib-packagekit-packagekitd.core
 /usr/lib/packagekit/packagekitd
[New LWP 22817]
[New LWP 16396]
[New LWP 16397]
[New LWP 16398]
[New LWP 22813]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/packagekit/packagekitd'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7fc77efdb700 (LWP 22817))]
#0  0x7fc78132ef3b in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fc7813302f1 in __GI_abort () at abort.c:79
#2  0x7fc77e2d4943 in __gnu_cxx::__verbose_terminate_handler() () at 
../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x7fc77e2da896 in __cxxabiv1::__terminate(void (*)()) 
(handler=) at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x7fc77e2da8d1 in std::terminate() () at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x7fc77e2dab04 in __cxxabiv1::__cxa_throw(void*, std::type_info*, void 
(*)(void*)) (obj=obj@entry=0x7fc774037120, tinfo=0x7fc77e3be9a0 , dest=0x7fc77e2ef5f0 ) 
at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:95
#6  0x7fc77e2d6805 in std::__throw_length_error(char const*) () at 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x7fc77e366e4e in std::__cxx11::basic_string, std::allocator >::_M_check_length(unsigned long, 
unsigned long, char const*) const (__s=0x7fc77e384f81 
"basic_string::_M_replace", __n2=, __n1=0, this=0x7fc77efda960) 
at 
/build/gcc-8-xSRyaH/gcc-8-8.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/char_traits.h:285
#8  0x7fc77e366e4e in std::__cxx11::basic_string, std::allocator >::_M_replace(unsigned long, 
unsigned long, char const*, unsigned long) (this=this@entry=0x7fc77efda960, 
__pos=__pos@entry=0, __len1=__len1@entry=0, __s=, 
__len2=) at 
/build/gcc-8-xSRyaH/gcc-8-8.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:425
#9  0x7fc77f074c52 in std::__cxx11::basic_string, std::allocator >::replace(unsigned long, unsigned 
long, char const*, unsigned long) (__n2=, __s=, 
__n1=0, __pos=0, this=0x7fc77efda960) at 
/usr/include/c++/8/bits/basic_string.h:1918
#10 0x7fc77f074c52 in std::__cxx11::basic_string, std::allocator 
>::replace(__gnu_cxx::__normal_iterator, std::allocator > 
>, __gnu_cxx::__normal_iterator, std::allocator > >, char*, char*) 
(__k2=, __k1=, __i2=..., __i1=..., 
this=0x7fc77efda960) at /usr/include/c++/8/bits/basic_string.h:2112
#11 0x7fc77f074c52 in std::__cxx11::basic_string, std::allocator >::assign(char*, 
char*) (__last=, __first=, this=0x7fc77efda960) 
at /usr/include/c++/8/bits/basic_string.h:1462
#12 0x7fc77f074c52 in std::__cxx11::basic_stringbuf, std::allocator >::str() const 
(this=0x7fc77efda988) at /usr/include/c++/8/sstream:174
#13 0x7fc77f074c52 in std::__cxx11::basic_stringstream, std::allocator >::str() const 
(this=0x7fc77efda970) at /usr/include/c++/8/sstream:780
#14 0x7fc77f074c52 in show_errors(PkBackendJob*, PkErrorEnum, bool) 
(job=0x55acd99e5ee0 [PkBackendJob], errorCode=PK_ERROR_ENUM_CANNOT_GET_LOCK, 
errModify=200) at apt-messages.cpp:55
#15 0x7fc77f094fe0 in 

Bug#911730: yapps2: writes __future__ import after preparser

[Colin Watson]

Source: yapps2
Version: 2.2.1-1
Severity: important

Generator.generate_output starts like this:

def generate_output(self):
self.calculate()
self.write(self.preparser)
self.write("# Begin -- grammar generated by Yapps\n")
self.write("from __future__ import print_function\n")

This means that if you have any Python code in self.preparser, your
generated parser will fail with "SyntaxError: from __future__ imports
must occur at the beginning of the file".

I'd suggest moving the __future__ import to immediately before the
preparser to avoid this problem.

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

Bug#911714: serf FTBFS: ssl tests fail

[James McCoy]

On Tue, Oct 23, 2018 at 10:15:28PM +0200, Helmut Grohne wrote:
> serf fails to build from source in unstable e.g. on i386:
> 
> https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/serf_1.3.9-6.rbuild.log.gz
> 
> | There were 14 failures:
> | 1) test_ssl_trust_rootca: test/test_util.c:456: expected <0> but was 
> <120199>
> | 2) test_ssl_certificate_chain_with_anchor: test/test_util.c:456: expected 
> <0> but was <120199>

Ah, the bad cert timebomb has expired again (see #862027).  I was hoping
a new upstream release would have happened in the interim.

There is hope, as there's a release candidate out for their next
version, which contains a script to generate the bad certs at build
time.

I'll see about backporting the script if the upstream release doesn't
happen Real Soon Now.  I'll probably have to look into it anyway, since
this is going to affect stable builds too.

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

Bug#911729: libgc: New upstream version available

[Wookey]

Source: libgc
Severity: wishlist
Tags: patch

I have updated the libgc package to upstream version 7.6.8. Attached
is the necessary patch.

Upstream suggested that this would be a good idea for debian in issue
https://github.com/ivmai/bdwgc/issues/241

so I gave it a go and it is straightforward. Only issue was symbol
fix, discussed in https://github.com/ivmai/bdwgc/issues/243

I leave it up to you whether you agree that this would be the right
thing to do for buster, but if so I hope this report is useful.

Just do 
wget https://github.com/ivmai/bdwgc/releases/download/v7.6.8/gc-7.6.8.tar.gz
cd libgc-7.6.4
uupdate ../gc-7.6.8.tar.gz
cd ../libgc-7.6.8
and apply attached patch
to get the new package.

(If you do do a new upload adding the symbol fix for arm64ilp32 would be 
appreciated too):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872392
diff -Nru libgc-7.6.4/debian/libgc1c2.symbols 
libgc-7.6.8/debian/libgc1c2.symbols
--- libgc-7.6.4/debian/libgc1c2.symbols 2018-09-09 13:17:15.0 +
+++ libgc-7.6.8/debian/libgc1c2.symbols 2018-10-23 08:58:46.0 +
@@ -9,6 +9,7 @@
  GC_FirstDLOpenedLinkMap@Base 1:7.2d
  (arch=kfreebsd-amd64 kfreebsd-i386)GC_FreeBSDGetDataStart@Base 1:7.2d
  (arch=sparc sparc64)GC_SysVGetDataStart@Base 1:7.2d
+ GC_abort_on_oom@Base 1:7.6.8
  (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el 
!sh4)GC_acquire_mark_lock@Base 1:7.4.2
  (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el 
!sh4)GC_active_count@Base 1:7.4.2
  GC_add_ext_descriptor@Base 1:7.2d
@@ -618,7 +619,6 @@
  GC_split_block@Base 1:7.2d
  GC_stackbottom@Base 1:7.2d
  GC_start_call_back@Base 1:7.2d
- GC_start_debugging@Base 1:7.2d
  GC_start_debugging_inner@Base 1:7.4.2
  GC_start_mark_threads@Base 1:7.4.2
  (arch=!arm64 !hppa !hurd-i386 !ppc64el !sh4 !kfreebsd-amd64 
!kfreebsd-i386)GC_start_mark_threads_inner@Base 1:7.6.4
@@ -634,7 +634,6 @@
  GC_stop_init@Base 1:7.2d
  GC_stop_world@Base 1:7.2d
  GC_stopped_mark@Base 1:7.2d
- GC_store_debug_info@Base 1:7.2d
  GC_store_debug_info_inner@Base 1:7.2d
  GC_strdup@Base 1:7.2d
  GC_strndup@Base 1:7.2d
@@ -663,6 +662,7 @@
  GC_try_to_collect_inner@Base 1:7.2d
  GC_typed_mark_proc@Base 1:7.2d
  GC_typed_mark_proc_index@Base 1:7.2d
+ GC_unblock_gc_signals@Base 1:7.6.8
  GC_unix_get_mem@Base 1:7.2d
  GC_unix_mmap_get_mem@Base 1:7.6.4
  (arch=!hurd-i386)GC_unix_sbrk_get_mem@Base 1:7.6.4
@@ -689,6 +689,7 @@
  (arch=sparc sparc64)_etext@Base 1:7.2d
  (arch=kfreebsd-amd64 kfreebsd-i386)etext@Base 1:7.2d
 libgccpp.so.1 libgc1c2 #MINVER#
+ _Z18GC_throw_bad_allocv@Base 1:7.6.8 
  _ZdaPv@Base 1:7.2d
  (arch-bits=32)_ZdaPvj@Base 1:7.6.4
  (arch-bits=64)_ZdaPvm@Base 1:7.6.4
diff -Nru libgc-7.6.4/debian/patches/02-manpage.diff 
libgc-7.6.8/debian/patches/02-manpage.diff
--- libgc-7.6.4/debian/patches/02-manpage.diff  2018-09-08 15:22:10.0 
+
+++ libgc-7.6.8/debian/patches/02-manpage.diff  2018-10-23 08:58:46.0 
+
@@ -1,13 +1,11 @@
 
 Various manpage changes. Imported semi-automatically from .diff.gz.
 
-Index: b/doc/gc.man
+Index: libgc-7.6.8/doc/gc.man
 ===
 a/doc/gc.man
-+++ b/doc/gc.man
-@@ -1,8 +1,8 @@
--.TH GC_MALLOC 1L "2 October 2003"
-+.TH GC_MALLOC 3 "2 October 2003"
+--- libgc-7.6.8.orig/doc/gc.man
 libgc-7.6.8/doc/gc.man
+@@ -2,7 +2,7 @@
  .SH NAME
  GC_malloc, GC_malloc_atomic, GC_free, GC_realloc, GC_enable_incremental, 
GC_register_finalizer, GC_malloc_ignore_off_page, 
GC_malloc_atomic_ignore_off_page, GC_set_warn_proc \- Garbage collecting malloc 
replacement
  .SH SYNOPSIS
diff -Nru libgc-7.6.4/debian/patches/enable-parallel-mark-where-supported.diff 
libgc-7.6.8/debian/patches/enable-parallel-mark-where-supported.diff
--- libgc-7.6.4/debian/patches/enable-parallel-mark-where-supported.diff
2018-09-08 15:22:19.0 +
+++ libgc-7.6.8/debian/patches/enable-parallel-mark-where-supported.diff
2018-10-23 08:58:46.0 +
@@ -1,15 +1,15 @@
-Index: b/configure.ac
+Index: libgc-7.6.8/configure.ac
 ===
 a/configure.ac
-+++ b/configure.ac
-@@ -184,7 +184,9 @@ case "$THREADS" in
+--- libgc-7.6.8.orig/configure.ac
 libgc-7.6.8/configure.ac
+@@ -188,7 +188,9 @@ case "$THREADS" in
  AC_CHECK_LIB(pthread, pthread_self, THREADDLLIBS="-lpthread",,)
  case "$host" in
   x86-*-linux* | ia64-*-linux* | i586-*-linux* | i686-*-linux* \
 - | x86_64-*-linux* | alpha-*-linux* | powerpc*-*-linux* | sparc*-*-linux*)
 + | x86_64-*-linux* | alpha-*-linux* | powerpc-*-linux* | sparc*-*-linux* \
 + | s390*-*-linux* | ppc64-*-linux* | m68k-*-linux* | mips*-*-linux* \
-+ | arm*-*-linux* | ppc-*-linux* | powerpc64-*-linux*)
++ | arm*-*-linux* | aarch64-*-linux* | ppc-*-linux* | powerpc64-*-linux*)
  AC_DEFINE(GC_LINUX_THREADS)
  AC_DEFINE(_REENTRANT)
  if test 

Bug#910059: RFH: gnucash -- personal and small-business financial-accounting software

[Jason Vigil]

Hello Dmitry,

I'd be interested in helping to maintain gnucash. I am looking to get involved 
in Debian and use gnucash personally. Do you have any advice on how to get 
started?

Thank you,
Jason

Bug#911728: apt: man page discourages installing .deb files

[Jean-Ralph Aviles]

Package: apt
Version: 1.4.8
Severity: normal

Dear Maintainer,

The wording on the apt-get(8) man page discourages installing of .deb
files by stating that a package can not be a filename and by providing
an example using a .deb file.

  install is followed by one or more packages desired for installation or
  upgrading. Each package is a package name, not a fully qualified
  filename (for instance, in a Debian system, apt-utils would be the
  argument provided, not apt-utils_1.4.8_amd64.deb).

Apt supports installing .deb files directly and it should be called out
on the man page.

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

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

Versions of packages apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2017.5
ii  gpgv2.1.18-8~deb9u2
ii  gpgv1   1.4.21-4+deb9u1
ii  init-system-helpers 1.48
ii  libapt-pkg5.0   1.4.8
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libstdc++6  6.3.0-18+deb9u1

Versions of packages apt recommends:
ii  gnupg   2.1.18-8~deb9u2
ii  gnupg1  1.4.21-4+deb9u1

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.18.25
ii  powermgmt-base   1.31+nmu1
ii  python-apt   1.4.0~beta3

-- no debconf information

Bug#911697: at-spi2-core: causes SIGSEGV because of improper quoting of G_LOG_DOMAIN

[Jan Nordholz]

reopen 911697
retitle 911697 at-spi2-core: varying levels of quote removal during meson build 
process mess up compilation of G_LOG_DOMAIN macro
severity 911697 serious
thanks

Hi,

your build fix actually made it worse: now G_LOG_DOMAIN works properly for
the gtkdoc-scangobj stuff, but the extra quotes cause literal integer values
to be inserted wherever you expected a string pointer in the library proper:

jcn@inti:/tmp$ objdump -d /usr/lib/x86_64-linux-gnu/libatspi.so.0.0.1 | grep 
-A1 696e6422
[...]
   11326:   bf 22 64 6e 69  mov$0x696e6422,%edi
   1132b:   e8 60 ea ff ff  callq  fd90 
[...]

This causes crashes in all programs using libatspi, even if only the usual
"cannot find a11y bus" message is going to be printed.

Sample stacktrace of evince (note the value of "log_domain" appearing at frame 
#8):
=
(gdb) bt
#0  0x76e7b136 in __strlen_sse2 () at 
../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x771c63f8 in g_string_insert_len (string=0x5561a400, pos=-1, 
val=0x696e6422 , len=-1) at 
../../../../glib/gstring.c:436
#2  0x771ab2a5 in g_log_writer_format_fields 
(log_level=log_level@entry=G_LOG_LEVEL_WARNING, 
fields=fields@entry=0x7fffd240, n_fields=n_fields@entry=4, use_color=1) at 
../../../../glib/gmessages.c:2271
#3  0x771ac1ae in g_log_writer_standard_streams 
(log_level=log_level@entry=G_LOG_LEVEL_WARNING, 
fields=fields@entry=0x7fffd240, n_fields=n_fields@entry=4, 
user_data=user_data@entry=0x0) at ../../../../glib/gmessages.c:2562
#4  0x771ac2b2 in g_log_writer_default 
(log_level=log_level@entry=G_LOG_LEVEL_WARNING, 
fields=fields@entry=0x7fffd240, n_fields=n_fields@entry=4, 
user_data=user_data@entry=0x0) at ../../../../glib/gmessages.c:2666
#5  0x771aa657 in g_log_structured_array 
(log_level=G_LOG_LEVEL_WARNING, fields=0x7fffd240, n_fields=4)
at ../../../../glib/gmessages.c:1923
#6  0x771aaa9d in g_log_default_handler 
(log_domain=log_domain@entry=0x696e6422 , log_level=log_level@entry=G_LOG_LEVEL_WARNING, 
message=message@entry=0x5564c960 "Error retrieving accessibility bus 
address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was 
not provided by any .service files", unused_data=unused_data@entry=0x0) at 
../../../../glib/gmessages.c:3111
#7  0x771aacef in g_logv (log_domain=0x696e6422 , log_level=G_LOG_LEVEL_WARNING, format=, args=args@entry=0x7fffd380) at ../../../../glib/gmessages.c:1350
#8  0x771aaedf in g_log (log_domain=log_domain@entry=0x696e6422 , 
log_level=log_level@entry=G_LOG_LEVEL_WARNING, 
format=format@entry=0x73ef2c38 "Error retrieving accessibility bus address: 
%s: %s")
at ../../../../glib/gmessages.c:1413
#9  0x73ee6342 in get_accessibility_bus_address_dbus () at 
../atspi/atspi-misc.c:1533
=

Suggesting a patch is beyond me though, I won't touch ninja/meson stuff. ;)


Jan

Bug#911727: initramfs-tools-core: configure_networking avoid panic and wait for at least one network interface.

[Ivan Baldo]

Package: initramfs-tools-core
Version: 0.130
Severity: normal
Tags: patch

In stable/stretch if there are no interfaces yet and ip-config doesn't
configure anything we get a panic.

I am using this patch in production with good results, it waits for
network interfaces to show and avoids sourcing an inexistent file,
avoiding the panic.

This happens with a USB network card but it could happen with other
cards too.

Maybe it is too much for stable/stretch, but unstable/sid version
0.132 seems to have the same problem so can be applied there.

Here it is, hope you find it useful:

--- functions.old   2017-03-06 19:42:55.0 -0300
+++ functions   2018-10-23 19:20:26.726994846 -0300
@@ -182,6 +182,15 @@
 
 configure_networking()
 {
+   for device_wait_try in 5 4 3 2 1; do
+   for device in /sys/class/net/*; do
+   [ $device = /sys/class/net/lo ] && continue
+   break 2
+   done
+   sleep 1
+   done
+   [ $device_wait_try = 1 ] && log_warning_msg "No network device found"
+
if [ -n "${BOOTIF}" ]; then
# pxelinux sets BOOTIF to a value based on the mac address of 
the
# network card used to PXE boot, so use this value for DEVICE 
rather
@@ -269,10 +278,12 @@
if [ -n "${DEVICE}" ]; then
# source specific bootdevice
. /run/net-${DEVICE}.conf
-   else
+   elif [ -e /run/net-*.conf ]; then
# source any interface...
# ipconfig should have quit after first response
. /run/net-*.conf
+   else
+   log_warning_msg "Network configuration failed, maybe 
driver/module not loaded/initialized yet or cable/network problem"
fi
 }


Thanks a lot!!!


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

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

Versions of packages initramfs-tools-core depends on:
ii  cpio 2.11+dfsg-6
ii  klibc-utils  2.0.4-9
ii  kmod 23-2
ii  udev 232-25+deb9u4

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.22.0-19+b3

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.1-4.3

-- Configuration Files:
/etc/initramfs-tools/initramfs.conf changed:
MODULES=netboot
BUSYBOX=auto
KEYMAP=n
COMPRESS=xz
DEVICE=
NFSROOT=auto
BOOT=nfs


-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/initramfs-tools/scripts/functions (from 
initramfs-tools-core package)

Bug#871594: mediawiki-extensions-universallanguageselector - package description not really understandable

[Kunal Mehta]

Hi,

On Fri, 18 Aug 2017 20:48:09 +0200 (CEST) Tomas Pospisek
 wrote:
> Hello Kartik Mistry,
> 
> the description you chose for your package is: "Tool to select a language 
> and configure for MediaWiki".
> 
> What does "select a configure" mean? Do you mean "select a configuration"?
> 
> Or do you mean "Tool to select and configure a language for MediaWiki"?

I think the following should be clearer: "Tool to select a language and
configure it for MediaWiki".

To clarify, ULS allows you to pick a language to render the interface
in, and then it allows you to configure that language by enabling web
fonts or an IME.

-- Kunal

Bug#911726: RFS: golang-github-xanzy-go-gitlab/0.11.3-1

[Felix Lechner]

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

  Dear mentors,

  I am looking for a sponsor for my package "golang-github-xanzy-go-gitlab".

  The package is a prerequisite for my upcoming package 'git-lab' (#898246).

 * Package name: golang-github-xanzy-go-gitlab
   Version : 0.11.3-1
   Upstream Author : Sander Van Harmelen 
 * URL : https://github.com/xanzy/go-gitlab
 * License : Apache-2.0
   Section : devel

  It builds those binary packages:

golang-github-xanzy-go-gitlab-dev - Simple and uniform GitLab API for Go

  If you have access to Salsa, please check out:

https://salsa.debian.org/go-team/packages/golang-github-xanzy-go-gitlab

  Otherwise, please visit the following URL: (You can also find the
orig.tar.gz here.)

https://mentors.debian.net/package/golang-github-xanzy-go-gitlab


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

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-xanzy-go-gitlab/golang-github-xanzy-go-gitlab_0.11.3-1.dsc

  Changes since the last upload:

 * Initial release (Closes: #906986)


  Regards,
   Felix Lechner

Bug#909795: ITS: unrar-nonfree

[Martin Meredith]

A brief look over the debdiff looks like there;'s nothing completely insane in 
there.

How about an NMU + Adding yourself to the Uploaders. Then we can work in the 
next few weeks (sorry, literally started a new Job on Monday - so I'm super 
busy at the moment) and get a shared git repo or similar setup.
Sound good?
On Oct 23 2018, at 11:01 pm, Norbert Preining  wrote:
>
> Hi Martin,
> any new concerning how we proceed? We need to stop the upload from the
> delayed queue if you prefer a different approach, but without hearing
> from you what to do I am a bit in the dark what to do.
>
> Thanks
> Norbert
> On Mon, 22 Oct 2018, Norbert Preining wrote:
> > Hi Martin,
> >
> > great to hear from you!!!
> > > Well, it seems my email has been a bit weird of late, as I've not seen the
> > > ITS until now!
> >
> >
> > Umpf, nor the email from 1 year ago about library support it seems.
> > > All my packages have always been LowNMU - and help has always been
> > > welcome. You're more than welcome to take this package of you wish,
> > > although my preference would have been for us to work together.
> >
> >
> > I am more than happy to work with you, I just wanted to get the shared
> > library of rar back, since I need it for a python package that in turn
> > is useful for calibre ;-)
> >
> > I attach a patch that only shows the changes to the files under debian/,
> > please use it for a proper upload if it helps (just remove the
> > maintainer change part).
> >
> > We can also set up a common git repository on salsa under the colabmaint
> > and I commit there.
> >
> > I am more than happy NOT to take over this package, if there is no need
> > for it.
> >
> > All the best
> > Norbert
> > --
> > PREINING Norbert http://www.preining.info
> > Accelia Inc. + JAIST + TeX Live + Debian Developer
> > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
>
>
> > diff -Nru unrar-nonfree-5.5.8/debian/changelog 
> > unrar-nonfree-5.6.6/debian/changelog
> > --- unrar-nonfree-5.5.8/debian/changelog 2017-08-21 21:29:11.0 +0900
> > +++ unrar-nonfree-5.6.6/debian/changelog 2018-10-22 10:37:47.0 +0900
> > @@ -1,3 +1,11 @@
> > +unrar-nonfree (1:5.6.6-1) unstable; urgency=medium
> > +
> > + * Package salvaged (Closes: #909795)
> > + * add libunrar5 and libunrar-dev packages
> > + * bump standards version, no changes necessary
> > +
> > + -- Norbert Preining  Mon, 22 Oct 2018 10:37:47 +0900
> > +
> > unrar-nonfree (1:5.5.8-1) unstable; urgency=high
> >
> > * New upstream release
> > diff -Nru unrar-nonfree-5.5.8/debian/control 
> > unrar-nonfree-5.6.6/debian/control
> > --- unrar-nonfree-5.5.8/debian/control 2017-08-21 21:29:11.0 +0900
> > +++ unrar-nonfree-5.6.6/debian/control 2018-10-22 10:37:47.0 +0900
> > @@ -1,11 +1,13 @@
> > Source: unrar-nonfree
> > Section: non-free/utils
> > Priority: optional
> > -Maintainer: Martin Meredith 
> > +Maintainer: Norbert Preining 
> > Homepage: http://www.rarlabs.com/
> > Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~)
> > -Standards-Version: 4.0.1
> > +Standards-Version: 4.2.1
> > XS-Autobuild: yes
> > +Vcs-Browser: https://salsa.debian.org/preining/unrar-nonfree
> > +Vcs-Git: https://salsa.debian.org/preining/unrar-nonfree.git
> >
> > Package: unrar
> > Architecture: any
> > @@ -14,3 +16,22 @@
> > Description: Unarchiver for .rar files (non-free version)
> > Unrar can extract files from .rar archives. If you want to create .rar
> > archives, install package rar.
> > +
> > +Package: libunrar5
> > +Section: non-free/libs
> > +Architecture: any
> > +Multi-Arch: same
> > +Depends: ${misc:Depends}, ${shlibs:Depends}
> > +Pre-Depends: ${misc:Pre-Depends}
> > +Description: Unarchiver for .rar files (non-free version) - shared library
> > + library for unarchiving .rar files
> > +
> > +Package: libunrar-dev
> > +Section: non-free/libdevel
> > +Architecture: any
> > +Multi-Arch: same
> > +Depends: ${misc:Depends}, libunrar5 (= ${binary:Version}), 
> > ${shlibs:Depends}
> > +Description: Unarchiver for .rar files (non-free version) - development 
> > files
> > + This package contains the static library and header files for the
> > + libunrar library.
> > +
> > diff -Nru unrar-nonfree-5.5.8/debian/patches/fix-buildflags 
> > unrar-nonfree-5.6.6/debian/patches/fix-buildflags
> > --- unrar-nonfree-5.5.8/debian/patches/fix-buildflags 2017-06-23 
> > 02:07:52.0 +0900
> > +++ unrar-nonfree-5.6.6/debian/patches/fix-buildflags 2018-10-22 
> > 10:37:47.0 +0900
> > @@ -1,16 +1,30 @@
> >  a/makefile
> > -+++ b/makefile
> > -@@ -3,12 +3,10 @@
> > +---
> > + makefile | 6 +++---
> > + 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > +--- unrar.orig/makefile
> >  unrar/makefile
> > +@@ -3,12 +3,12 @@
> > +
> > # Linux using GCC
> > CXX=c++
> > --CXXFLAGS=-O2
> > --LIBFLAGS=-fPIC
> > +-CXXFLAGS=-O2 -Wno-logical-op-parentheses -Wno-switch -Wno-dangling-else
> > ++CXXFLAGS=-Wno-logical-op-parentheses -Wno-switch -Wno-dangling-else
> > + 

Bug#468114: Loopback file system support.

[Ivan Baldo]

  Seems like a trivial and yet useful enhancement!
  Would be nice to see it included.
  Thanks for your consideration.

-- 
Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/
Freelance C++/PHP programmer and GNU/Linux systems administrator.
The sky is not the limit!

Bug#911656: munin-plugins-core: postgres_x_ALL plugins produce 'FATAL: database "munin" does not exist' errors

[Lars Kruse]

Hello Vincas,

thank you for your bug report!

Could you please check whether reverting the changes introduced with
https://github.com/munin-monitoring/munin/commit/d7e138176e9a09b883031544e523e33e5ef9238b
would fix this issue for you?

Cheers,
Lars

Bug#910444: OpenRC called by update-rc.d should read defaults from headers

[Adam Borowski]

On Tue, Oct 23, 2018 at 10:19:50AM +0800, Benda Xu wrote:
> With the input and help from biebl, I was able to chase down this bug to
> update-rc.d.  After refactorization by fsateler, the execution order was
> changed and the previous assumption does not hold anymore.
> 
> Please find the pull request at
> https://salsa.debian.org/debian/init-system-helpers/merge_requests/6

Confirmed: the patch fixes at the very least startup of newly installed
daemons (I did not test mount on new installs in particular).

But something is amiss: that refactorization happened a year ago, yet there
was no breakage I nor anyone else noticed.  And I obviously installed quite
a few daemons in the meantime on systems running unstable (although I don't
recall any on unstable in last 1-2 months).  Yet on current unstable
installing new init scripts with openrc is broken (tested with 0.38 and
0.34.something) -- if it could have worked before, what did change?
I'm pretty confused...

But, not sure if chasing another cause is worth our time.  What matters is
that without this pull request openrc in unstable is badly broken, with it
applied it seems to work fine.  So please take it :p


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#911725: RFS: golang-github-pkg-xattr/0.3.1-1 [team upload]

[Felix Lechner]

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

Dear mentors,

I am looking for a sponsor to update the team-maintained package
"golang-github-pkg-xattr".

This version is a prerequisite for the latest version 1.6 of
'gocryptfs', which I co-maintain.

 * Package name: golang-github-pkg-xattr
   Version : 0.3.1-1
   Upstream Author : Kuba Podgórski & Dave Cheney
 * URL : https://github.com/pkg/xattr
 * License : BSD-2-clause
   Section : devel

  It builds those binary packages:

golang-github-pkg-xattr-dev - Extended attribute support for Go

  If you have access to Salsa, please have a look at:

https://salsa.debian.org/go-team/packages/golang-github-pkg-xattr

  Otherwise, please visit the following URL:

https://mentors.debian.net/package/golang-github-pkg-xattr

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-pkg-xattr/golang-github-pkg-xattr_0.3.1-1.dsc

  Thank you!

  Changes since the last upload:

[ Alexandre Viau ]
  * Point Vcs-* urls to salsa.debian.org.

  [ Felix Lechner ]
  * Team upload
  * New upstream version
  * Set Standards-Version: 4.2.1
  * Added Build-Depends: golang-golang-x-sys-dev
  * Added Testsuite: autopkgtest-pkg-go

  Regards,
   Felix Lechner

Bug#820230: initramfs-tools: DHCP is very flaky and sometimes doesn't work

[Ivan Baldo]

  Hello.
  Original reporter doesn't reply, maybe close?
  Thanks!

-- 
Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/
Freelance C++/PHP programmer and GNU/Linux systems administrator.
The sky is not the limit!

Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296

[Richard Ipsum]

On Sun, 21 Oct 2018, at 06:50, Gergely Nagy wrote:
> Hi!
> 
> I just had a quick look at the libtheft packaging on mentors, and
> noticed a few things that at the moment, prevent me from sponsoring the
> package. These are:

Hi! thanks for reviewing this!

> 
> - I was unable to find the public part of your GPG key, thus, was unable
>   to verify the signature on the source package. Where can one find it?

GPG key has now been uploaded to default keyservers, key id is 
3D3239533DAE7F5A9D322B7C52322452F1C90E1E

>   (Uploading it to a public key server might be best).
> - The package build-depends on `debhelper-compat (= 11)`, which works,
>   but it's a virtual package. I'd suggest build-depending on `debhelper
>   (>= 11)`, and adding a `debian/compat` file with "11" as its content.

skipping as discussed

>   This will get rid of one of the warnings on mentors, too.
> - debian/copyright does not document the license of `src/theft_hash.c`
>   (public domain, but that needs to be documented too).

fixed

> - debian/copyright does not document the license and author of
>   `debian/*`. In most cases - and theft is no exception - the Debian
>   packager is not the upstream author. If unspecified, the `*` wildcard
>   applies to `debian/*` too, which would be incorrect.

fixed

> - The control file does not set a Homepage - a minor thing, but while
>   fixing the other issues, might as well fix this one, and point the
>   Homepage field in debian/control to theft's GitHub.

fixed

> 
> Other than these, the package looks ok. Can you fix the above?
> 
> Drop me an email when done, and I'll have another look.

Fixed remaining issues, sorry this took me a while to get to.
I have uploaded a new version of the package to mentors.

Bug#911724: Regression: Does not heed settings for "Prefer HTML over plain text" and "Allow messages to load external references.."

[Jacob Hallén]

Package: kmail
Version: 4:18.08.1-1
Severity: normal
Tags: upstream

Dear Maintainer,

After the latest update to kmail in testing, several settings no longer have 
any effect. I want to set the preference
for getting the HTML format of the mail by default, automatically downloading 
links. I also want to remove mails,
using SHIFT-Delete without getting prompted if I really want do do this every 
time. All of this fails after the
latest upgrade. The former two were a problem with an earlier version, when you 
cahnged the settinsg while  running
kmail through kontact. In that older version you could fix the problem by 
running kmail directly and changing the settings.
That does not work this time. I have tried changing the settinge per folder, 
globally and editing the config file.
Nothing works. Considering the problems in the past, I'm surprised that there 
are no regression tests for these
problems.

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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:18.08.1-1
ii  kdepim-runtime   4:18.08.1-1
ii  kio  5.49.0-1
ii  libc62.27-6
ii  libgcc1  1:8.2.0-8
ii  libgpgmepp6  1.12.0-4
ii  libkf5akonadiagentbase5  4:18.08.1-1
ii  libkf5akonadicontact54:18.08.1-1
ii  libkf5akonadicore5abi2   4:18.08.1-1
ii  libkf5akonadimime5   4:18.08.1-2
ii  libkf5akonadisearch-bin  4:18.08.1-1+b1
ii  libkf5akonadisearch-plugins  4:18.08.1-1+b1
ii  libkf5akonadisearchdebug54:18.08.1-1+b1
ii  libkf5akonadisearchpim5  4:18.08.1-1+b1
ii  libkf5akonadiwidgets5abi14:18.08.1-1
ii  libkf5bookmarks5 5.49.0-1
ii  libkf5calendarcore5abi2  4:18.08.1-1
ii  libkf5calendarutils5 4:18.08.1-1
ii  libkf5codecs55.49.0-1
ii  libkf5completion55.49.0-1
ii  libkf5configcore55.49.0-1
ii  libkf5configgui5 5.49.0-1
ii  libkf5configwidgets5 5.49.0-1
ii  libkf5contacts5  4:18.08.1-1
ii  libkf5coreaddons55.49.0-1
ii  libkf5crash5 5.49.0-1
ii  libkf5dbusaddons55.49.0-1
ii  libkf5followupreminder5  4:18.08.1-1
ii  libkf5grantleetheme-plugins  18.08.1-1
ii  libkf5gravatar5abi2  4:18.08.1-1
ii  libkf5guiaddons5 5.49.0-1
ii  libkf5i18n5  5.49.0-1
ii  libkf5iconthemes55.49.0-1
ii  libkf5identitymanagement518.08.1-1
ii  libkf5itemmodels55.49.0-1
ii  libkf5itemviews5 5.49.0-1
ii  libkf5jobwidgets55.49.0-1
ii  libkf5kcmutils5  5.49.0-1
ii  libkf5kiocore5   5.49.0-1
ii  libkf5kiofilewidgets55.49.0-1
ii  libkf5kiowidgets55.49.0-1
ii  libkf5kontactinterface5  18.08.1-1
ii  libkf5ksieveui5  4:18.08.1-1
ii  libkf5libkdepim-plugins  4:18.08.1-1
ii  libkf5libkdepim5 4:18.08.1-1
ii  libkf5libkdepimakonadi5  4:18.08.1-1
ii  libkf5libkleo5   4:18.08.1-1
ii  libkf5mailcommon5abi24:18.08.1-1
ii  libkf5mailtransport5 18.08.1-2
ii  libkf5mailtransportakonadi5  18.08.1-2
ii  libkf5messagecomposer5abi1   4:18.08.1-1
ii  libkf5messagecore5abi1   4:18.08.1-1
ii  libkf5messagelist5abi1   4:18.08.1-1
ii  libkf5messageviewer5abi1 4:18.08.1-1
ii  libkf5mime5abi1  18.08.1-1
ii  libkf5mimetreeparser5abi14:18.08.1-1
ii  libkf5notifications5 5.49.0-1
ii  libkf5notifyconfig5  5.49.0-1
ii  libkf5parts5 5.49.0-1
ii  libkf5pimcommon5abi2 4:18.08.1-1
ii  libkf5pimcommonakonadi5abi1  4:18.08.1-1
ii  libkf5pimtextedit5abi2   18.08.1-1
ii  libkf5sendlater5 4:18.08.1-1
ii  libkf5service-bin5.49.0-1
ii  libkf5service5   5.49.0-1
ii  libkf5sonnetui5  5.49.0-1
ii  libkf5templateparser54:18.08.1-1
ii  libkf5textwidgets5   5.49.0-1
ii  libkf5tnef5  4:18.08.1-1
ii  libkf5wallet-bin 5.49.0-1
ii  libkf5wallet55.49.0-1
ii  libkf5webengineviewer5abi1   4:18.08.1-1
ii  libkf5widgetsaddons5 5.49.0-1
ii  libkf5windowsystem5  5.49.0-1
ii  libkf5xmlgui55.49.0-1
ii  libqgpgme7   1.12.0-4
ii  libqt5core5a 5.11.1+dfsg-9
ii  libqt5dbus5  5.11.1+dfsg-9
ii  libqt5gui5   5.11.1+dfsg-9
ii  libqt5network5   5.11.1+dfsg-9
ii  libqt5widgets5   5.11.1+dfsg-9
ii  libqt5xml5   5.11.1+dfsg-9
ii  libstdc++6   8.2.0-8

Versions of packages kmail 

Bug#910061: freecad: /build/freecad-XXQg0d/freecad-0.16.6712+dfsg1/src/Mod/Part/Gui/SoBrepEdgeSet.cpp:76: PartGui::SoBrepEdgeSet::SoBrepEdgeSet(): Assertion `SoBrepEdgeSet::classTypeId != SoType::badT

[Francesco Poli]

On Tue, 2 Oct 2018 10:29:28 +0200 Christoph Berg wrote:

[...]
> 0.17 from experimental doesn't crash.
[...]

Hello Christoph,
do I understand correctly that freecad/0.17+dfsg1-1 from experimental
was working fine for you?

If this is the case, then this should perhaps be notified to the BTS
version tracking with a "Control: fixed -1 freecad/0.17+dfsg1-1"
message to the bug address.

Or maybe even by closing this bug report as fixed in
freecad/0.17+dfsg1-1 ...



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


pgpxJjvPAeFfg.pgp
Description: PGP signature

Bug#909795: ITS: unrar-nonfree

[Norbert Preining]

Hi Martin,

any new concerning how we proceed? We need to stop the upload from the
delayed queue if you prefer a different approach, but without hearing
from you what to do I am a bit in the dark what to do.

Thanks

Norbert

On Mon, 22 Oct 2018, Norbert Preining wrote:
> Hi Martin,
> 
> great to hear from you!!! 
> 
> > Well, it seems my email has been a bit weird of late, as I've not seen the
> > ITS until now!
> 
> Umpf, nor the email from 1 year ago about library support it seems.
> 
> > All my packages have always been LowNMU - and help has always been
> > welcome.  You're more than welcome to take this package of you wish,
> > although my preference would have been for us to work together.
> 
> I am more than happy to work with you, I just wanted to get the shared
> library of rar back, since I need it for a python package that in turn
> is useful for calibre ;-)
> 
> I attach a patch that only shows the changes to the files under debian/,
> please use it for a proper upload if it helps (just remove the
> maintainer change part). 
> 
> We can also set up a common git repository on salsa under the colabmaint
> and I commit there.
> 
> I am more than happy NOT to take over this package, if there is no need
> for it.
> 
> All the best
> 
> Norbert
> 
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. +JAIST +TeX Live +Debian Developer
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

> diff -Nru unrar-nonfree-5.5.8/debian/changelog 
> unrar-nonfree-5.6.6/debian/changelog
> --- unrar-nonfree-5.5.8/debian/changelog  2017-08-21 21:29:11.0 
> +0900
> +++ unrar-nonfree-5.6.6/debian/changelog  2018-10-22 10:37:47.0 
> +0900
> @@ -1,3 +1,11 @@
> +unrar-nonfree (1:5.6.6-1) unstable; urgency=medium
> +
> +  * Package salvaged (Closes: #909795)
> +  * add libunrar5 and libunrar-dev packages
> +  * bump standards version, no changes necessary
> +
> + -- Norbert Preining   Mon, 22 Oct 2018 10:37:47 +0900
> +
>  unrar-nonfree (1:5.5.8-1) unstable; urgency=high
>  
>* New upstream release
> diff -Nru unrar-nonfree-5.5.8/debian/control 
> unrar-nonfree-5.6.6/debian/control
> --- unrar-nonfree-5.5.8/debian/control2017-08-21 21:29:11.0 
> +0900
> +++ unrar-nonfree-5.6.6/debian/control2018-10-22 10:37:47.0 
> +0900
> @@ -1,11 +1,13 @@
>  Source: unrar-nonfree
>  Section: non-free/utils
>  Priority: optional
> -Maintainer: Martin Meredith 
> +Maintainer: Norbert Preining 
>  Homepage: http://www.rarlabs.com/
>  Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~)
> -Standards-Version: 4.0.1
> +Standards-Version: 4.2.1
>  XS-Autobuild: yes
> +Vcs-Browser: https://salsa.debian.org/preining/unrar-nonfree
> +Vcs-Git: https://salsa.debian.org/preining/unrar-nonfree.git
>  
>  Package: unrar
>  Architecture: any
> @@ -14,3 +16,22 @@
>  Description: Unarchiver for .rar files (non-free version)
>   Unrar can extract files from .rar archives. If you want to create .rar
>   archives, install package rar.
> +
> +Package: libunrar5
> +Section: non-free/libs
> +Architecture: any
> +Multi-Arch: same
> +Depends: ${misc:Depends}, ${shlibs:Depends}
> +Pre-Depends: ${misc:Pre-Depends}
> +Description: Unarchiver for .rar files (non-free version) - shared library
> + library for unarchiving .rar files
> +
> +Package: libunrar-dev
> +Section: non-free/libdevel
> +Architecture: any
> +Multi-Arch: same
> +Depends: ${misc:Depends}, libunrar5 (= ${binary:Version}), ${shlibs:Depends}
> +Description: Unarchiver for .rar files (non-free version) - development files
> + This package contains the static library and header files for the
> + libunrar library.
> +
> diff -Nru unrar-nonfree-5.5.8/debian/patches/fix-buildflags 
> unrar-nonfree-5.6.6/debian/patches/fix-buildflags
> --- unrar-nonfree-5.5.8/debian/patches/fix-buildflags 2017-06-23 
> 02:07:52.0 +0900
> +++ unrar-nonfree-5.6.6/debian/patches/fix-buildflags 2018-10-22 
> 10:37:47.0 +0900
> @@ -1,16 +1,30 @@
>  a/makefile
> -+++ b/makefile
> -@@ -3,12 +3,10 @@
> +---
> + makefile |6 +++---
> + 1 file changed, 3 insertions(+), 3 deletions(-)
>  
> +--- unrar.orig/makefile
>  unrar/makefile
> +@@ -3,12 +3,12 @@
> + 
>   # Linux using GCC
>   CXX=c++
> --CXXFLAGS=-O2
> --LIBFLAGS=-fPIC
> +-CXXFLAGS=-O2 -Wno-logical-op-parentheses -Wno-switch -Wno-dangling-else
> ++CXXFLAGS=-Wno-logical-op-parentheses -Wno-switch -Wno-dangling-else
> + LIBFLAGS=-fPIC
>   DEFINES=-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DRAR_SMP
>   STRIP=strip
>   AR=ar
>  -LDFLAGS=-pthread
>  +LDFLAGS+=-pthread
>   DESTDIR=/usr
> -
> + 
>   # Linux using LCC
> +@@ -156,7 +156,7 @@ lib: CXXFLAGS+=$(LIBFLAGS)
> + lib:clean $(OBJECTS) $(LIB_OBJ)
> + @rm -f libunrar.so
> + @rm -f libunrar.a
> +-$(LINK) -shared -o libunrar.so $(LDFLAGS) $(OBJECTS) $(LIB_OBJ)
> ++$(LINK) -Wl,-soname,libunrar.so.5 -shared -o libunrar.so 

Bug#911723: fcitx-rime: Cannot memorize user configuration about selecting Simp. Chinese / Trad. Chinese input methods

[Boyuan Yang]

Package: fcitx-rime
Version: 0.3.2-3
Severity: important
Control: affects -1 + librime1
X-Debbugs-CC: hu...@mail2.sysu.edu.cn

Multiple users have reported that fcitx-rime will lose the status of
keep using Simplified Chinese input method after restarting fcitx or
rebooting the system. It is believed to be reproducible under Plasma
desktop with KDE's builtin Input Method widget. Further investigation
would be needed.

--
Regards,
Boyuan Yang

Bug#911722: RM: php-crypt-chap -- ROM; depends on removed php-mcrypt

[Ondřej Surý]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

on behalf of the team - php-mcrypt was removed from PHP as it depends
on the libmcrypt - a crypto library last updated in 2007 (shivers).

php-crypt-chap is the last thing that needs to be removed to cleanup
php-mcrypt cruft, so please do remove the package.

Thank you,
Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAlvPkMlfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcJhzQ//bjXqWmUeOWMRBhroTszfLwXODNwb76HHxLOL+e34MmkE9q2+SpYn/tsG
oRwKjNPS2BpZLmTYml+/ROneTYnAUJ2z7oZYDSd9n+60scR3fIHnH76tUnEp9fUv
lQpuopyRsj0Q2GytN2poD0yWgjUKodYF1YYdbE5q2GLZ/Kdp3/zMtI3X67XIWFu+
8ILlTzoVJLhh4EdLPfNQF6J/VpwrrThCCv6AwvWuVWNDdPRvnFWibSB4vhLKbDtV
+OkvGvcg1r5pBUhwq3RPHe0MsUaMMvtFe4cDiBApVEV/cQJGbRegLVFcBs82A/EO
AxXKJBPmWlhor+Mltjr26GqI8Ss7N8zJKpW4MQFHOt49PNWiCaJPU3EhJJnvcLH4
qT0bJALf2TSIb6UKHFA4F61hdyuF7GxRWhYs8cq0glVHmXQgv/O6xH2jgyQwwtfM
J4Vzvmz1mKzROOn336rDA6sP/HDr+FKLhll+n2bZWAAWVnVaCOMzOYTfsZ+OihgC
HDnPFBnA8g24hRZG4oeuIZMgHqLPF9EfElNgcLXqL4r0ypN8z7KC8JfgPximi4KJ
WkxJfl3h0kmff5yywtAMVohTtEWPEPv3bXmWSI/F1CSG247jJ1rfvWSB63Jf9mQ9
cUXuD9igr5gsoZmjc4wXsZJBbsdb52G+gdyyMQINF2isuOtIDiE=
=D2nm
-END PGP SIGNATURE-

Bug#911721: ITP: gramalign -- alignment of multiple biological sequences

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: gramalign
  Version : 3.0
* URL : http://bioinfo.unl.edu/gramalign.php
* License : academic non-free
  Description : alignment of multiple biological sequences

About to appear on salsa.debian.org/med-team/gramalign.

Bug#911716: python-urllib3 FTBFS: ssl tests fail

[Daniele Tricoli]

Hello Helmut,

On 10/23/18 10:23 PM, Helmut Grohne wrote:
> Source: python-urllib3
> Version: 1.22-1
> Severity: serious
> Tags: ftbfs
> 
> python-urllib3 fails to build from source in unstable. Building the
> experimental version succeeds.

Many thanks for your report. I plan to package requests tomorrow,
(urllib3 was uploaded to experimental because only requests >=
2.20.0 support it) and upload both into unstable.

Cheers,

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org



signature.asc
Description: OpenPGP digital signature

Bug#911720: who-uploads: bad signal handling leads to insecure use of /tmp

[Jakub Wilk]

Package: devscripts
Version: 2.18.6
Tags: security

who-uploads does this:

  GNUPGHOME=$(mktemp -d)
  trap '[ ! -d "$GNUPGHOME" ] ||  rm -r "$GNUPGHOME"' HUP INT QUIT PIPE ALRM 
TERM

So when the signal arrives, it removes $GNUPGHOME, and then... it 
doesn't exit, but continues checking signatures. This gives local 
attacker opportunity to create their own malicious $GNUPGHOME, which gpg 
would happily use.



-- System Information:
Architecture: i386

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.2
ii  libfile-homedir-perl  1.004-1
ii  sensible-utils0.0.12
ii  perl  5.26.2-7+b1
ii  python3   3.6.7-1
ii  libc6 2.27-6

--
Jakub Wilk

Bug#911719: [php-apcu] Changelog is missing reference to PHP versions

[Adrien CLERC]

Package: php-apcu
Severity: important

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

Hi,

Along with php-igbinary in #911670 this package was uploaded to testing.

There is no mention that the build with PHP 7.2 has been removed. This
renders the package unusable, so there should be at least a clear
mention of it.


Thanks for the package maintenance,

Adrien


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

Debian Release: buster/sid
500 unstable-debug debug.mirrors.debian.org
500 unstable ftp.fr.debian.org
500 testing download.jitsi.org
1 experimental ftp.fr.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#911718: apt: error message "apt install enigmail" failure is misleading

[Daniel Kahn Gillmor]

Package: apt
Version: 1.4.8
Severity: minor

Over in https://bugs.debian.org/909000,
On Mon 2018-10-22 08:28:50 -0400, Fabián Rodríguez wrote:
> This also fails in a clean Stretch install:
>
> # apt 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.

I just want to note that this error message specifically appears to be a
bug in apt -- the reason apt won't let you install enigmail is because
the version of thunderbird in debian-security stretch/updates
(thunderbird 1:60.0) is marked with:

   Breaks: enigmail (<< 2:2~)

That's correct, because versions of enigmail prior to 2.0 do not work on
thunderbird 60 any longer.

it would be nice if apt improved the reporting here, to identify that
the cause of the problem is a conflict between the currently installed
version of thunderbird, and the desired version of enigmail.

Compare the differences with neither thunderbird nor enigmail installed:

root@stretch:~# apt 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.
 root@stretch:~# apt install enigmail thunderbird
 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:
 thunderbird : Breaks: enigmail (< 2:2~) but 2:1.9.9-1~deb9u1 is to be
 installed
 E: Unable to correct problems, you have held broken packages.
 root@stretch:~#


the latter error message is clearly the correct one, but it doesn't
show in the former attempt.

--dkg

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

[Daniel Kahn Gillmor]

Hi Adam--

On Tue 2018-10-23 16:18:05 +0100, Adam D. Barratt wrote:

> Sure, but that's not what I said. My distinction was between including 
> the gnupg update in the point release versus pushing it more urgently 
> via stable-updates. I never implied the updates shouldn't be released at 
> all.

thanks for the clarification, i didn't understand that distinction.  I'm
glad you're considering it at least for the point release.

> FWIW I don't recognise that characterisation. Yes, I should have 
> confirmed the Security Team's intentions at an earlier point, but I 
> don't consider that buck-passing or the situation deadlocked.

fwiw, i'd heard privately earlier from the security team that they don't
see this fix as in their bailiwick, but they hadn't responded to my
requests for comments in public on the BTS.  So the deadlock
misperception may have been due to what looked like a longer delay from
my vantage point.

I'm glad it's not deadlock!

--dkg

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

[Daniel Kahn Gillmor]

On Tue 2018-10-23 20:00:06 +0100, Adam D. Barratt wrote:
> From discussions elsewhere, I understand that the "raw" upstream
> enigmail - i.e. installed via upstream's addons service - is actually
> already compatible with the new Thunderbird version, and the problem
> only affects the Debian packages - is that correct? (Specifically,
> upstream includes some kind of compatibility shim, which is not shipped
> in our packages for DFSG reasons.)

the version of enigmail shipped in the mozilla add-ons has at least two
problems, both arguably DFSG-free-related, and both described in
#909000, i believe.

 0) it ships a pre-built copy of OpenPGP.js, which i have not been able
to build directly in debian due to a deep dependency mess (see #787774)

 1) by default it downloads a binary from the internet, stores it in the
user's thunderbird profile, and executes it as the user without
checking its integrity with anything beyond an HTTPS (see #891882)

Encouraging users with sensitive communication needs to install
something with either of these choices made this way is pretty
problematic.  And users who install enigmail from the add-on store will
most likely never revert to the debian packages that fix these
misfeatures :/

> Explicitly CCing KiBi is generally more effective, as -boot@ is a
> fairly busy list at times. I imagine he'll want the SRM review
> completed first, but that also depends on whether the changes actually
> impact d-i's usage, which I'm not entirely clear on - could you provide
> any insight there?

d-i's usage is limited to gpgv; the gpgv-udeb is deliberately narrowly
targeted, since all d-i needs from gpgv is (a) interpret the debian
distro public keys, and (b) verify signatures on the apt manifests.
None of the changes in this update should affect gpgv's behavior in
either of these tasks.

hope that helps to clarify,

   --dkg


signature.asc
Description: PGP signature

Bug#909621: anjuta hangs on startup

[Andrea Calì]

Package: anjuta
Followup-For: Bug #909621

Dear Maintainer,

after installing the debug symbols for anjuta, the full gdb backtrace at the
moment of hangup (before the splashscreen loading) is the following:

#0  0xb69daf30 in g_hash_table_foreach (hash_table=0x15d8ae0, func=0xb6ae8fb0
, user_data=0xbfb4b854) at ././glib/ghash.c:1605
#1  0xb6aeac6b in g_param_spec_pool_list (pool=0x15dc470, owner_type=24117760,
n_pspecs_p=0xbfb4b898) at ././gobject/gparam.c:1306
#2  0xb6ae4f94 in g_object_class_list_properties (class=0x16e0c00,
n_properties_p=0xbfb4b904) at ././gobject/gobject.c:918
#3  0xb7668509 in gdl_dock_layout_setup_object (after_params=, n_after_params=, node=0xf5c2ca8, master=0x17184a8
[GdlDockMaster]) at gdl-dock-layout.c:312
#4  0xb7668509 in gdl_dock_layout_recursive_build
(master=master@entry=0x17184a8 [GdlDockMaster],
parent_node=parent_node@entry=0xc32bb48, parent=parent@entry=0x0) at gdl-dock-
layout.c:410
#5  0xb76690c6 in gdl_dock_layout_load (node=0xc32bb48, master=0x17184a8
[GdlDockMaster]) at gdl-dock-layout.c:473
#6  0xb76690c6 in gdl_dock_layout_load_layout (layout=0x16ccbc8
[GdlDockLayout], name=0x0) at gdl-dock-layout.c:691
#7  0x004e26fc in anjuta_window_layout_load (win=win@entry=0x17301a8
[AnjutaWindow], layout_filename=layout_filename@entry=0x1a65c00
"/home/murdock/.cache/anjuta/session/dock-layout.xml", name=0x0) at anjuta-
window.c:957
#8  0x004e2975 in on_session_load (shell=0x17301a8,
phase=ANJUTA_SESSION_PHASE_LAST, session=0x16e4e10 [AnjutaSession],
win=0x17301a8 [AnjutaWindow]) at anjuta-window.c:513
#12 0xb6afa394 in  (instance=0x17301a8, detailed_signal=0xb6952aba "load_session")
at ././gobject/gsignal.c:3487
#9  0xb6adec3b in g_closure_invoke (closure=0x1832ca8, return_value=0x0,
n_param_values=3, param_values=0xbfb4bb20, invocation_hint=0xbfb4bac4) at
././gobject/gclosure.c:804
#10 0xb6af101e in signal_emit_unlocked_R (node=node@entry=0x16d8348,
detail=detail@entry=0, instance=instance@entry=0x17301a8, emission_return=0x0,
instance_and_params=0xbfb4bb20) at ././gobject/gsignal.c:3635
#11 0xb6af9bb6 in g_signal_emit_valist (instance=0x17301a8, signal_id=230,
detail=0, var_args=0xbfb4bd20 "\250\001s\001P") at ././gobject/gsignal.c:3391
#13 0xb69051f2 in anjuta_shell_session_load () at /usr/lib/i386-linux-
gnu/libanjuta-3.so.0
#14 0x004de054 in on_profile_scoped (profile=0x16e32d0 [AnjutaProfile],
win=0x17301a8 [AnjutaWindow]) at anjuta-application.c:253
#18 0xb6afa394 in  (instance=0x16e32d0, detailed_signal=0xb695567e "scoped") at
././gobject/gsignal.c:3487
#15 0xb6adec3b in g_closure_invoke (closure=0x1834bb0, return_value=0x0,
n_param_values=1, param_values=0xbfb4bf00, invocation_hint=0xbfb4bea4) at
././gobject/gclosure.c:804
#16 0xb6af101e in signal_emit_unlocked_R (node=node@entry=0x1835af0,
detail=detail@entry=0, instance=instance@entry=0x16e32d0, emission_return=0x0,
instance_and_params=0xbfb4bf00) at ././gobject/gsignal.c:3635
#17 0xb6af9bb6 in g_signal_emit_valist (instance=0x16e32d0, signal_id=305,
detail=0, var_args=0xbfb4c0d8 "\360v~\001\001") at ././gobject/gsignal.c:3391
#19 0xb691328f in anjuta_profile_load () at /usr/lib/i386-linux-
gnu/libanjuta-3.so.0
#20 0xb6913948 in  () at /usr/lib/i386-linux-gnu/libanjuta-3.so.0
#21 0x004defae in anjuta_application_create_window (app=0x15e5090
[AnjutaApplication]) at anjuta-application.c:820
#22 0x004df435 in anjuta_application_open (application=0x15e5090
[AnjutaApplication], files=0x0, n_files=0, hint=0x16bd970 ";") at anjuta-
application.c:525
#23 0xb5dd3e3a in ffi_call_SYSV () at /usr/lib/i386-linux-gnu/libffi.so.6
#24 0xb5dd3aac in ffi_call () at /usr/lib/i386-linux-gnu/libffi.so.6
#25 0xb6adf830 in g_cclosure_marshal_generic_va (closure=0x15e1ff8,
return_value=0x0, instance=, args_list=0xbfb4c5dc "",
marshal_data=0x4df160 , n_params=3,
param_types=0x15e3df0) at ././gobject/gclosure.c:1604
#26 0xb6adee5f in _g_closure_invoke_va (closure=0x15e1ff8, return_value=0x0,
instance=0x15e5090, args=0xbfb4c5dc "", n_params=3, param_types=0x15e3df0) at
././gobject/gclosure.c:867
#27 0xb6af991e in g_signal_emit_valist (instance=0x15e5090, signal_id=9,
detail=0, var_args=0xbfb4c5dc "") at ././gobject/gsignal.c:3300
#28 0xb6af9ed5 in g_signal_emit (instance=0x15e5090, signal_id=9, detail=0) at
././gobject/gsignal.c:3447
#29 0xb6bc7709 in g_application_open (application=0x15e5090
[AnjutaApplication], files=0x0, n_files=0, hint=0x171eb68 ";") at
././gio/gapplication.c:2192
#30 0x004de985 in anjuta_application_local_command_line (application=0x15e5090
[AnjutaApplication], arguments=0xbfb4c7d0, exit_status=0xbfb4c7d4) at anjuta-
application.c:499
#31 0xb6bc8036 in g_application_run (application=0x15e5090 [AnjutaApplication],
argc=1, argv=0xbfb4c8e4) at ././gio/gapplication.c:2350
#32 0x004dd052 in main (argc=1, argv=0xbfb4c8e4) at main.c:38


but following your suggestion, using another (newly created) account I found
that anjuta runs normally without hanging.
So I tried running again 

Bug#911670: Add conflicts with php-redis

[Adrien CLERC]

Hi,

I get hits by this release in testing, while using php7.2 with php-redis:

PHP Warning:  PHP Startup: Unable to load dynamic library 'redis.so'
(tried: /usr/lib/php/20170718/redis.so (/usr/lib/php/20170718/redis.so:
undefined symbol: igbinary_serialize), /usr/lib/php/20170718/redis.so.so
(/usr/lib/php/20170718/redis.so.so: cannot open shared object file: No
such file or directory)) in Unknown on line 0

It seems that some Conflict are missing. Is it possible to either
compile igbinary against 7.2 in the transition?

In the meantime, I have to manually hold the package. I guess I'm not
the only one.

Bug#911244: stretch-pu: package publicsuffix/20181003.1334-0+deb9u1

[Daniel Kahn Gillmor]

On Sun 2018-10-21 11:47:51 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
>
> On Wed, 2018-10-17 at 11:13 -0400, Daniel Kahn Gillmor wrote:
>> Please consider an update to publicsuffix in debian stretch.
>> 
>> This package reflects the state of the network, and keeping it
>> current
>> is useful for all the packages that depend on it.
>
> Please go ahead.

uploaded, thanks.

  --dkg

Bug#911717: ruby2.5 FTBFS: missing Build-Depends: tzdata

[Helmut Grohne]

Source: ruby2.5
Version: 2.5.1-6
Severity: serious
Tags: ftbfs

ruby2.5 fails to build from source in unstable. The time zone tests fail
unless tzdata is installed. On the buildds, tzdata is installed, because
its Priority is required and debootstrap happens to install required
packages. tzdata is not essential nor build-essential though. You must
depend on it if you use it.

E.g.

|   1) Failure:
| TestTimeTZ#test_america_los_angeles 
[/<>/test/ruby/test_time_tz.rb:107]:
| TZ=America/Los_Angeles Time.local(2007, 3, 11, 2, 0, 0).
| <"2007-03-11 03:00:00 -0700"> expected but was
| <"2007-03-11 02:00:00 +">.

Helmut

Bug#911716: python-urllib3 FTBFS: ssl tests fail

[Helmut Grohne]

Source: python-urllib3
Version: 1.22-1
Severity: serious
Tags: ftbfs

python-urllib3 fails to build from source in unstable. Building the
experimental version succeeds. A build ends with:

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/python-urllib3_1.22-1.rbuild.log.gz

| === FAILURES 
===
| _ TestConnection.test_match_hostname_mismatch 
__
| 
| self = 
| 
| def test_match_hostname_mismatch(self):
| cert = {'subjectAltName': [('DNS', 'foo')]}
| asserted_hostname = 'bar'
| try:
| with mock.patch('urllib3.connection.log.error') as mock_log:
| >   _match_hostname(cert, asserted_hostname)
| 
| test/test_connection.py:39: 
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ 
| 
| cert = {'subjectAltName': [('DNS', 'foo')]}, asserted_hostname = 'bar'
| 
| def _match_hostname(cert, asserted_hostname):
| try:
| >   match_hostname(cert, asserted_hostname)
| 
| urllib3/connection.py:356: 
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ 
| 
| cert = {'subjectAltName': [('DNS', 'foo')]}, hostname = 'bar'
| 
| def match_hostname(cert, hostname):
| """Verify that *cert* (in decoded format as returned by
| SSLSocket.getpeercert()) matches the *hostname*.  RFC 2818 and RFC 
6125
| rules are followed.
| 
| The function matches IP addresses rather than dNSNames if hostname is 
a
| valid ipaddress string. IPv4 addresses are supported on all platforms.
| IPv6 addresses are supported on platforms with IPv6 support (AF_INET6
| and inet_pton).
| 
| CertificateError is raised on failure. On success, the function
| returns nothing.
| """
| if not cert:
| raise ValueError("empty or no certificate, match_hostname needs a 
"
|  "SSL socket or SSL context with either "
|  "CERT_OPTIONAL or CERT_REQUIRED")
| try:
| host_ip = _inet_paton(hostname)
| except ValueError:
| # Not an IP address (common case)
| host_ip = None
| dnsnames = []
| san = cert.get('subjectAltName', ())
| for key, value in san:
| if key == 'DNS':
| if host_ip is None and _dnsname_match(value, hostname):
| return
| dnsnames.append(value)
| elif key == 'IP Address':
| if host_ip is not None and _ipaddress_match(value, host_ip):
| return
| dnsnames.append(value)
| if not dnsnames:
| # The subject is only checked when there is no dNSName entry
| # in subjectAltName
| for sub in cert.get('subject', ()):
| for key, value in sub:
| # XXX according to RFC 2818, the most specific Common Name
| # must be used.
| if key == 'commonName':
| if _dnsname_match(value, hostname):
| return
| dnsnames.append(value)
| if len(dnsnames) > 1:
| raise CertificateError("hostname %r "
| "doesn't match either of %s"
| % (hostname, ', '.join(map(repr, dnsnames
| elif len(dnsnames) == 1:
| raise CertificateError("hostname %r "
| "doesn't match %r"
| >   % (hostname, dnsnames[0]))
| E   ssl.SSLCertVerificationError: ("hostname 'bar' doesn't match 
'foo'",)
| 
| /usr/lib/python3.7/ssl.py:327: SSLCertVerificationError
| 
| During handling of the above exception, another exception occurred:
| 
| self = 
| 
| def test_match_hostname_mismatch(self):
| cert = {'subjectAltName': [('DNS', 'foo')]}
| asserted_hostname = 'bar'
| try:
| with mock.patch('urllib3.connection.log.error') as mock_log:
| _match_hostname(cert, asserted_hostname)
| except CertificateError as e:
| >   assert str(e) == "hostname 'bar' doesn't match 'foo'"
| E   assert '("hostname \...ch \'foo\'",)' == "hostname 'bar...t match 
'foo'"
| E - ("hostname 'bar' doesn't match 'foo'",)
| E ? --  ---
| E + hostname 'bar' doesn't match 'foo'
| 
| test/test_connection.py:41: AssertionError
| === 1 failed, 545 passed, 51 skipped, 1 deselected in 11.58 seconds 

| /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:6: 
DeprecationWarning: the imp module is deprecated in favour of importlib; see 
the module's documentation for alternative uses
|   import imp
| /usr/lib/python3/dist-packages/pkg_resources/_vendor/pyparsing.py:943: 
DeprecationWarning: Using or 

Bug#911709: tomcat7: Security update broke apps with AccessControlException for org.apache.tomcat.util.http

[Markus Koschany]

Hello,

Am 23.10.18 um 21:20 schrieb Anthony DeRobertis:
> Package: tomcat7
> Version: 7.0.56-3+really7.0.91-1
> Severity: important
> 
> After applying the recent security update, the web app we're running
> (which is unfortunately a proprietary product provided by a vendor) no
> longer works. Instead, I get an exception and a blank page.
> Interestingly, in /etc/tomcat7/policy.d/40_«redacted».policy, there is a
> grant:
> 
> grant codeBase "file:/srv/hm/HPM54/WebApp-«Redacted»/-" {
>⋮
>permission java.lang.RuntimePermission 
> "accessClassInPackage.org.apache.tomcat";
> }
> 
> ... adding another grant for accessClassInPackage.org.apache.tomcat.util.http
> seems to get it working again, but that's not something you'd expect without
> warning from a security update.

We follow upstream releases of Tomcat 7 closely. Unfortunately I can't
tell why your webapp needs those permissions without having a look at
the source code. It is quite possible that your previous security
permissions were insufficient and just worked because of a bug in Tomcat
7 that got fixed alongside the last security update. I recommend to file
an upstream bug report instead because Debian ships the latest upstream
release without making any behavioral changes. [1] The upstream
developers will more likely be able to track this issue down.

Regards,

Markus

[1] https://tomcat.apache.org/bugreport.html



signature.asc
Description: OpenPGP digital signature

Bug#911715: ros-rosdep FTBFS: flake8 failure

[Helmut Grohne]

Source: ros-rosdep
Version: 0.12.2-2
Severity: serious
Tags: ftbfs

ros-rosdep fails to build from source in unstable:

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/ros-rosdep_0.12.2-2.rbuild.log.gz

| ==
| ERROR: test.test_flake8.test_flake8
| --
| Traceback (most recent call last):
|   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
| self.test(*self.arg)
|   File 
"/build/1st/ros-rosdep-0.12.2/.pybuild/cpython2_2.7_rosdep2/build/test/test_flake8.py",
 line 63, in test_flake8
| 'flake8 reported {report.total_errors} errors'
| AttributeError: 'str' object has no attribute 'format_map'
|  >> begin captured stdout << -
| 
| 8 W504 line break after binary operator
| 
| - >> end captured stdout << --
|  >> begin captured logging << 
...
| - >> end captured logging << -
| 
| --
| Ran 151 tests in 24.045s
| 
| FAILED (errors=1)
| E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/build/1st/ros-rosdep-0.12.2/.pybuild/cpython2_2.7_rosdep2/build; python2.7 -m 
nose -v test
| dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7 returned 
exit code 13
| make: *** [debian/rules:7: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Helmut

Bug#911667: proftpd-mod-mysql: mod_sql.log is not rotated and grows bigger and bigger

[Hilmar Preuße]

On 23.10.2018 12:11, Paolo Benvenuto wrote:

Hi Paolo,

> In my system the file /var/log/proftpd/mod_sql.log is not rotated, 
> I'm seeing that its content start from when I installed the package,
> and now it's alread 9GB big!
> 
> I suppose that rotation must be implemented for this file.
> 
According to [1] the sql module does not write log files by default. So
if you have a log file there you configured this by yourself. In this
case you also have to care for log file rotation yourself.

What did I miss?

Hilmar

[1] http://proftpd.org/docs/directives/linked/config_ref_SQLLogFile.html
-- 
#206401 http://counter.li.org

Bug#911582: emacspeak does'nt work after upgrading emacs

[Samuel Thibault]

Hello,

Michelangelo Rodriguez, le mar. 23 oct. 2018 10:21:09 +0200, a ecrit:
> On Tue, 23 Oct 2018, Samuel Thibault wrote:
> > Michelangelo Rodriguez, le mar. 23 oct. 2018 08:47:03 +0200, a ecrit:
> > > this is the output of dpkg -l \*emacs\*:
> > 
> > I'm still not geting the issue with that list of package.
> > 
> > Could you send the actual output you are getting during package
> > configuration?
> > 
> > Samuel
> > 
> Hi, this is the output when i run dpkg-reconfigure emacspeak:
> Install emacspeak for emacs
> /usr/lib/emacsen-common/packages/install/emacspeak running in /
> And that's all.
> when i open the script i read that if flavour is emacs it has to exit.
> And i think that it happens.

Ah, ok.

Could you try the package at
https://people.debian.org/~sthibault/tmp/emacspeak_47.0+dfsg-2~0_all.deb
?

Samuel

Bug#911714: serf FTBFS: ssl tests fail

[Helmut Grohne]

Source: serf
Version: 1.3.9-6
Severity: serious
Tags: ftbfs

serf fails to build from source in unstable e.g. on i386:

https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/serf_1.3.9-6.rbuild.log.gz

| There were 14 failures:
| 1) test_ssl_trust_rootca: test/test_util.c:456: expected <0> but was <120199>
| 2) test_ssl_certificate_chain_with_anchor: test/test_util.c:456: expected <0> 
but was <120199>
| 3) test_ssl_certificate_chain_all_from_server: test/test_util.c:456: expected 
<0> but was <120199>
| 4) test_ssl_no_servercert_callback_allok: test/test_util.c:456: expected <0> 
but was <120170>
| 5) test_ssl_large_response: test/test_util.c:456: expected <0> but was 
<120170>
| 6) test_ssl_large_request: test/test_util.c:456: expected <0> but was <120170>
| 7) test_ssl_client_certificate: test/test_util.c:456: expected <0> but was 
<120170>
| 8) test_ssl_future_server_cert: test/test_util.c:456: expected <0> but was 
<120199>
| 9) test_setup_ssltunnel: test/test_util.c:456: expected <0> but was <120170>
| 10) test_ssltunnel_basic_auth: test/test_context.c:2138: expected <0> but was 
<120170>
| 11) test_ssltunnel_basic_auth_server_has_keepalive_off: 
test/test_context.c:2138: expected <0> but was <120170>
| 12) test_ssltunnel_basic_auth_proxy_has_keepalive_off: 
test/test_context.c:2138: expected <0> but was <120170>
| 13) test_ssltunnel_basic_auth_proxy_close_conn_on_200resp: 
test/test_context.c:2138: expected <0> but was <120170>
| 14) test_ssltunnel_digest_auth: test/test_util.c:456: expected <0> but was 
<120170>
| 
| !!!FAILURES!!!
| Runs: 66 Passes: 52 Fails: 14
| 
| == Testing test/testcases/deflate.response ==
| == Testing test/testcases/chunked.response ==
| == Testing test/testcases/chunked-trailers.response ==
| == Testing test/testcases/chunked-empty.response ==
| == Testing test/testcases/simple.response ==
| == Running the unit tests ==
| ERROR: test(s) failed in test_all
| scons: *** [check] Error 1
| scons: building terminated because of errors.
| make[1]: *** [debian/rules:26: override_dh_auto_test-arch] Error 2
| make[1]: Leaving directory '/build/1st/serf-1.3.9'
| make: *** [debian/rules:18: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Helmut

Bug#911713: sdcc FTBFS: tex failure during documentation build

[Helmut Grohne]

Source: sdcc
Version: 3.7.0+dfsg2-0.1
Severity: serious
Tags: ftbfs

sdcc fails to build from source in unstable.

| LaTeX Warning: Reference `subsec:Search-Paths' on page 32 undefined on input 
li
| ne 2261.
| 
| [32]
| 
| ! LaTeX Error: File `MCS51_named' not found.
| 
| See the LaTeX manual or LaTeX Companion for explanation.
| Type  H   for immediate help.
|  ...  
|   
| l.2283 \includegraphics{MCS51_named}
| 
| ? 
| ! Emergency stop.
|  ...  
|   
| l.2283 \includegraphics{MCS51_named}
| 
| Output written on sdccman.dvi (33 pages, 170988 bytes).
| Transcript written on sdccman.log.
| make[1]: *** [Makefile:67: sdccman.dvi] Error 1
| make[1]: Leaving directory '/<>/doc'
| make: *** [debian/rules:71: build-indep-stamp] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Supposedly, this was fixed in #909995, but the issue persists.

This time around the traceback looks a little different:

| +Read the file doc/LaTeXConfig.lyx for more information.
| LyX: Done!
| Traceback (most recent call last):
|   File "/usr/share/lyx/scripts/convertDefault.py", line 38, in 
| output = output.decode()
| AttributeError: 'str' object has no attribute 'decode'
| support/Systemcall.cpp (294): Systemcall: 'python3 -tt 
"/usr/share/lyx/scripts/convertDefault.py" svg 
"/tmp/lyx_tmpdir.hxwECXKtFDVu/lyx_tmpbuf0/1_build_sdcc-KkmAiE_sdcc-3_7_0+dfsg2_doc_MCS51_named.svg"
 eps 
"/tmp/lyx_tmpdir.hxwECXKtFDVu/lyx_tmpbuf0/1_build_sdcc-KkmAiE_sdcc-3_7_0+dfsg2_doc_MCS51_named.eps"'
 finished with exit code 1
| Error: Cannot convert file
| 
| No information for converting svg format files to eps.
| Define a converter in the preferences.
| latex sdccman.tex

Helmut

Bug#911712: tigervnc FTBFS: missing Build-Depends: libunwind-dev

[Helmut Grohne]

Source: tigervnc
Version: 1.9.0+dfsg-1
Severity: serious
Tags: ftbfs

tigervnc passes --enable-libunwind to ./configure, but does not list
libunwind-dev in Build-Depends. Consequently it fails to build:

| checking for LIBUNWIND... no
| configure: error: libunwind requested but not installed.
| make: *** [debian/rules:219: 
obj-x86_64-linux-gnu/unix/xserver/configure.stamp] Error 1
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#911711: svgwrite FTBFS: tests fail

[Helmut Grohne]

Source: svgwrite
Version: 1.1.8-2
Severity: serious
Tags: ftbfs

svgwrite fails to build from source in unstable e.g. on amd64:

https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/svgwrite_1.1.8-2.rbuild.log.gz

| ==
| FAIL: test_is_number_optional_number 
(tests.test_full11_typechecker.TestFull11TypeChecker)
| --
| Traceback (most recent call last):
|   File 
"/build/1st/svgwrite-1.1.8/.pybuild/cpython3_3.7_svgwrite/build/tests/test_full11_typechecker.py",
 line 177, in test_is_number_optional_number
| self.assertTrue(self.checker.is_number_optional_number(' 1, 2'))
| AssertionError: False is not true
| 
| --
| Ran 455 tests in 0.191s
| 
| FAILED (failures=1, errors=6)
| E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/build/1st/svgwrite-1.1.8/.pybuild/cpython3_3.7_svgwrite/build; python3.7 -m 
unittest discover -v
| dh_auto_test: pybuild --test -i python{version} -p "3.7 3.6" returned exit 
code 13
| make: *** [debian/rules:9: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#911710: rkward FTBFS: debian/rules has a fi too much

[Helmut Grohne]

Source: rkward
Version: 0.7.0b-1
Severity: serious
Tags: ftbfs

rkward fails to build from source in unstable since dash fixed #550756.
debian/rules has a "fi" too much in the last line and now dash does not
like that anymore.

| # unfortunately, the r-base-core dependency can not be found by dh_shlibdeps, 
so we need to get at the version manually
| /bin/sh: 10: Syntax error: "fi" unexpected
| make[1]: *** [debian/rules:47: override_dh_shlibdeps] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:19: binary] Error 2
| dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2

Helmut

Bug#881696: courier: Please include /usr/lib/courier/courier/courierfilter in courier-mta

[Markus Wanner]

Control: tags -1 +pending

Hello Steve,

please excuse my late response.

On 11/14/2017 08:36 AM, Steve Langasek wrote:
> Please find attached a one-liner patch to add the missing file to the> 
> courier-mta binary package.

Thank you for this patch, it will make it into the next upload.

Kind Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#911698: ITS: tbb

[Steven Capper]

Hi Mo,
I maintain the package and we had it hosted on Debian Science. I would
like to keep maintaining the package, but I am happy to co-maintain
the package with others.

Out of interest, what would you like doing with the package? Would you
like the version updating?

Thanks,
--
Steve

Bug#911709: tomcat7: Security update broke apps with AccessControlException for org.apache.tomcat.util.http

[Anthony DeRobertis]

Package: tomcat7
Version: 7.0.56-3+really7.0.91-1
Severity: important

After applying the recent security update, the web app we're running
(which is unfortunately a proprietary product provided by a vendor) no
longer works. Instead, I get an exception and a blank page.
Interestingly, in /etc/tomcat7/policy.d/40_«redacted».policy, there is a
grant:

grant codeBase "file:/srv/hm/HPM54/WebApp-«Redacted»/-" {
   ⋮
   permission java.lang.RuntimePermission 
"accessClassInPackage.org.apache.tomcat";
}

... adding another grant for accessClassInPackage.org.apache.tomcat.util.http
seems to get it working again, but that's not something you'd expect without
warning from a security update.

Oct 23, 2018 2:58:47 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing HardMetrics action servlet.
Oct 23, 2018 2:58:54 PM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" 
"accessClassInPackage.org.apache.tomcat.util.http")
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at 
java.security.AccessController.checkPermission(AccessController.java:684)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at 
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1525)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:320)
at java.lang.ClassLoader.loadClass(ClassLoader.java:417)
at java.lang.ClassLoader.loadClass(ClassLoader.java:363)
at 
org.apache.coyote.http11.AbstractHttp11Processor.prepareResponse(AbstractHttp11Processor.java:1677)
at 
org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:825)
at org.apache.coyote.Response.action(Response.java:171)
at 
org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:185)
at org.apache.coyote.Response.doWrite(Response.java:495)
at 
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:405)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:442)
at 
org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:488)
at org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:273)
at 
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:540)
at 
org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:152)
at 
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:336)
at java.io.Writer.write(Writer.java:157)
at org.apache.jsp.base.logon.logon_jsp._jspService(logon_jsp.java:877)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:453)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:548)
at 
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
at 
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
at 
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 

Bug#911705: #911705 [l10n|gu] debian-installer: fonts broken for Gujarati

[Holger Wansing]

I filed this bugreport today, but forgot to add debian-boot as X-Debbugs-CC,
so I'm resending to debian-boot here a copy of the bug text:

Please keep debian-boot in CC


Holger Wansing  wrote:
> Package: fonts-freefont-udeb
> Severity: normal
> 
> 
> I just noticed that Gujarati is no longer unusable, because of broken font
> (all characters replaced by placeholder, see attached screenshot).
> 
> This seems to be related to the new fonts-freefont-udeb package, which 
> replaced ttf-freefont-udeb:
> When I use the ttf-freefont-udeb package from Stretch as localudeb to build
> the netboot-gtk target here locally, Gujarati fonts seem to be fine again
> (see second screenshot).
> 
> 
> Holger

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



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#911708: scikit-learn breaks astroml autopkgtest: ImportError: cannot import name 'GMM'

[Paul Gevers]

Source: scikit-learn, astroml
Control: found -1 scikit-learn/0.20.0+dfsg-1
Control: found -1 astroml/0.3-7
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of scikit-learn the autopkgtest of astroml fails in
testing when that autopkgtest is run with the binary packages of
scikit-learn from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
scikit-learn   from testing0.20.0+dfsg-1
astromlfrom testing0.3-7
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
of scikit-learn to testing [1]. Due to the nature of this issue, I filed
this bug report against both packages. Can you please investigate the
situation and reassign the bug to the right package? If needed, please
change the bug's severity.

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

Paul

[1] https://qa.debian.org/excuses.php?package=scikit-learn

https://ci.debian.net/data/autopkgtest/testing/amd64/a/astroml/1196880/log.gz

autopkgtest [04:37:20]: test command2: [---
/usr/lib/python3/dist-packages/astroML/time_series/periodogram.py:8:
UserWarning: Using slow version of lomb_scargle. Install astroML_addons
to use an optimized version
  warnings.warn("Using slow version of lomb_scargle. Install
astroML_addons "
/usr/lib/python3/dist-packages/astroML/dimensionality/iterative_pca.py:136:
RuntimeWarning: invalid value encountered in true_divide
  ratio_i = X[i][notM[i]] / X_recons[i][notM[i]]
.E../usr/lib/python3/dist-packages/astroML/stats/_binned_statistic.py:323:
RuntimeWarning: invalid value encountered in true_divide
  result[a] /= flatcount
/usr/lib/python3/dist-packages/numpy/core/fromnumeric.py:2957:
RuntimeWarning: Mean of empty slice.
  out=out, **kwargs)
/usr/lib/python3/dist-packages/numpy/core/_methods.py:80:
RuntimeWarning: invalid value encountered in double_scalars
  ret = ret.dtype.type(ret / rcount)
..
==
ERROR: Failure: ImportError (cannot import name 'GMM')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 417, in
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.6/imp.py", line 245, in load_module
return load_package(name, filename)
  File "/usr/lib/python3.6/imp.py", line 217, in load_package
return _load(spec)
  File "", line 684, in _load
  File "", line 665, in _load_unlocked
  File "", line 678, in exec_module
  File "", line 219, in
_call_with_frames_removed
  File
"/usr/lib/python3/dist-packages/astroML/classification/__init__.py",
line 1, in 
from .gmm_bayes import GMMBayes
  File
"/usr/lib/python3/dist-packages/astroML/classification/gmm_bayes.py",
line 8, in 
from sklearn.mixture import GMM
ImportError: cannot import name 'GMM'

==
ERROR: Failure: ImportError (cannot import name 'GMM')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 417, in
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.6/imp.py", line 245, in load_module
return load_package(name, filename)
  File "/usr/lib/python3.6/imp.py", line 217, in load_package
return _load(spec)
  File "", line 684, in _load
  File "", line 665, in _load_unlocked
  File "", line 678, in exec_module
  File "", line 219, in
_call_with_frames_removed
  File "/usr/lib/python3/dist-packages/astroML/clustering/__init__.py",
line 1, in 

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Tollef Fog Heen 

> ]] Tollef Fog Heen 
>
> That turned out to be in the rather more distant future than I
> intended.  Apologies about that.

… and again.

Diff from previous one:

- Included separate source packages as an alternative to build time
  patching.
- Fixed typo.

I have not included the language about release criticalness of bugs,
due to OdyX' comment about that being the domain of the release team,
not policy.

I hope to call for a vote on this by the end of the week.

Second draft:

=== DRAFT Resolution ===

Vendor-specific patch series are a feature of dpkg that can be used to
apply a different series of quilt patches when the source package is
unpacked on different systems.  Since Debian source packages are usually
treated as a pure transport format (like tar), this property can cause
confusion and frustration for users.  Examples could be if only the
series file for one vendor is updated, or a source package is unpacked
on one system and then transferred to a system with a different vendor
for debugging.

The Committee recognises that there is a need for packages to behave
differently when built on different distributions, but this should be
done by using different source packages, or as part of the build
process, using current and future practices such as patches with
conditional behaviour, patching of files during the build, rather than
at source unpacking time.

Since this feature is used by several packages today, we need a
reasonable transition period.  They will be considered buggy from when
this resolution is accepted, but it will not be considered severe enough
to warrant immediate removal from Debian.  After Buster is released, the
presence of a vender-specific patch series will be a violation of a MUST
directive in Debian policy.

The Committee therefore resolves that:

1. Any use of dpkg's vendor-specific patch series feature is a bug for
   packages in the Debian archive (including contrib and non-free).

   This should be implemented in Debian Policy by declaring that a
   package SHOULD NOT contain a non-default series file.

2. After Buster is released, use of the vendor-specific patch series
   feature is forbidden in the Debian archive.

   This should be implemented in Debian Policy by declaring that a
   package MUST NOT contain a non-default series file.

=== End DRAFT Resolution ===

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#911680: xserver-xorg-core: X server crashes when loading libglamorgl.so module (Bug #911680)

[Bernhard Übelacker]

Hello Massimo Manghi,
just tried to reproduce the issue inside a debian buster amd64 qemu VM.
I never hit the crash and found you were probably running inside a VirtualBox.

Nevertheless with installed debug informations I think the crash shown
in the Xorg.log points to that location:


(gdb) bt
#0  glamor_egl_init (scrn=scrn@entry=0x557fc0f0, fd=) at 
../../../../../../glamor/glamor_egl.c:992
#1  0x75088172 in try_enable_glamor (pScrn=0x557fc0f0) at 
../../../../../../../hw/xfree86/drivers/modesetting/driver.c:767
#2  PreInit (pScrn=0x557fc0f0, flags=) at 
../../../../../../../hw/xfree86/drivers/modesetting/driver.c:994
#3  0x555ef6c0 in InitOutput 
(pScreenInfo=pScreenInfo@entry=0x557c3780 , argc=argc@entry=1, 
argv=argv@entry=0x7fffed08) at 
../../../../../../hw/xfree86/common/xf86Init.c:522
#4  0x555b26df in dix_main (argc=1, argv=0x7fffed08, 
envp=) at ../../../../dix/main.c:193
#5  0x764cbb17 in __libc_start_main (main=0x5559c640 , 
argc=1, argv=0x7fffed08, init=, fini=, 
rtld_fini=, stack_end=0x7fffecf8) at ../csu/libc-start.c:310
#6  0x5559c67a in _start ()


glamor/glamor_egl.c:
990
991 renderer = glGetString(GL_RENDERER);
992 if (strstr((const char *)renderer, "llvmpipe")) {
993 xf86DrvMsg(scrn->scrnIndex, X_INFO,
994"Refusing to try glamor on llvmpipe\n");


Therefore my guess would be that "glGetString(GL_RENDERER)" returns
in VirtualBox (or at least that installation) something odd.


That line originates from this patch that is applied upstream and
I assume is cherry picked [1] for that debian package version:
./debian/patches/08_dont-init-glamor-on-llvmpipe.diff

Upstream added on top of that another patch [2] to
avoid a crash that is probably exact that one we see here.

Kind regards,
Bernhard

[1] https://cgit.freedesktop.org/xorg/xserver/commit/glamor/?id=0a9415cf
[2] 
https://cgit.freedesktop.org/xorg/xserver/commit/glamor/glamor_egl.c?id=af151895f3cb1755a7a5631f2398a3d3b219cbef

# original:
[23.879] (EE) Backtrace:
[23.879] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x564f404a2de9]
[23.880] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) 
[0x7fc54b81f92f]
[23.880] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (explicit_bzero+0x124ed) 
[0x7fc54b700d8d]
[23.880] (EE) 3: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_egl_init+0x11d) [0x7fc5497de1fd]
[23.880] (EE) 4: /usr/lib/xorg/modules/drivers/modesetting_drv.so 
(_init+0x5172) [0x7fc549a20ae2]
[23.880] (EE) 5: /usr/lib/xorg/Xorg (InitOutput+0x9c0) [0x564f403856c0]
[23.881] (EE) 6: /usr/lib/xorg/Xorg (InitFonts+0x1cf) [0x564f4034871f]
[23.881] (EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xe7) 
[0x7fc54b670b17]
[23.881] (EE) 8: /usr/lib/xorg/Xorg (_start+0x2a) [0x564f4033267a]




apt update

apt install dpkg-dev devscripts gdb xserver-xorg xserver-xorg-core-dbgsym
apt build-dep xserver-xorg-core


mkdir xserver-xorg-core/orig -p
cdxserver-xorg-core/orig
apt source xserver-xorg-core
cd ../..
 

gdb -q --args /usr/lib/xorg/Xorg

set height 0
set width 0
set pagination off
directory /home/benutzer/xserver-xorg-core/orig/xorg-server-1.20.1/glamor
b glamor_egl_init


glamor_egl_init+0x11d == glamor_egl_init+285












root@debian:~# gdb -q --args /usr/lib/xorg/Xorg
Reading symbols from /usr/lib/xorg/Xorg...Reading symbols from 
/usr/lib/debug/.build-id/92/cbd96948ba614f538b64667017f2b323ab4386.debug...done.
done.
(gdb) set height 0
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/xserver-xorg-core/orig/xorg-server-1.20.1/glamor
Source directories searched: 
/home/benutzer/xserver-xorg-core/orig/xorg-server-1.20.1/glamor:$cdir:$cwd

(gdb) b glamor_egl_init
Function "glamor_egl_init" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (glamor_egl_init) pending.

(gdb) run
Starting program: /usr/lib/xorg/Xorg 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

X.Org X Server 1.20.1
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
Current Operating System: Linux debian 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 
(2018-10-07) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.18.0-2-amd64 
root=UUID=3de4a194-fb38-4aa0-a7f8-5faf23bafde2 ro vga=788 quiet
Build Date: 10 October 2018  04:23:15PM
xorg-server 2:1.20.1-5 (https://www.debian.org/support) 
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Oct 23 20:58:31 2018
(==) 

Bug#910445: stretch-pu: package gnutls28/3.5.8-5+deb9u4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2018-10-06 at 14:43 +0200, Andreas Metzler wrote:
> I would like to fix CVE-2018-10844 and CVE-2018-10845 in stretch.
> Moritz has brought this up. Neither of us has strong feelings whether
> it is better fix this via proposed-updates or via stretch-security.
> However proposed-updates probably gets more public testing so we will
> try this way.

Please go ahead; thanks.

Regards,

Adam

Bug#911707: aioprocessing: autopkgtest regression: ./runtest.py: not found

[Paul Gevers]

Source: aioprocessing
Version: 1.0.1-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of aioprocessing the autopkgtest of aioprocessing
fails in testing when that autopkgtest is run with the binary packages
of aioprocessing from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
aioprocessing  from testing1.0.1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. Seems you
either missed to commit a file, or it is located elsewhere.

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

[1] https://qa.debian.org/excuses.php?package=aioprocessing

https://ci.debian.net/data/autopkgtest/testing/amd64/a/aioprocessing/1196808/log.gz

autopkgtest [04:11:31]: test test.sh: [---
/tmp/autopkgtest-lxc.zy9ef3bt/downtmp/build.mB3/src/debian/tests/test.sh:
8:
/tmp/autopkgtest-lxc.zy9ef3bt/downtmp/build.mB3/src/debian/tests/test.sh:
./runtest.py: not found
autopkgtest [04:11:32]: test test.sh: ---]



signature.asc
Description: OpenPGP digital signature

Bug#911702: okular: Does not print to network printers

[Brian Potkin]

On Tue 23 Oct 2018 at 18:28:59 +0100, Brian Potkin wrote:

> 2.2.8-5 is the CUPS version. cups-browsed is not running.
> 
>  brian@test:~$ lpstat -l -e
>  ENVY4500 network none ipp://ENVY4500._ipp._tcp.local/
>  LaserJet_300_desktop network none 
> ipps://LaserJet-300%20%40%20desktop._ipps._tcp.local/cups
>  realq_desktop network none ipps://realq%20%40%20desktop._ipps._tcp.local/cups
>  test permanent ipp://localhost/printers/test 
> usb://HP/ENVY%204500%20series?serial=CN56G332DT060D=1
>  zzz_desktop3 network none ipps://zzz%20%40%20desktop3._ipps._tcp.local/cups
> 
> There are three printers/queues on the network and a local queue, test.

Four, actually. But who's counting? And none of them print.

Regards,

Brian.

Bug#911666: mediawiki: Does not work with PHP 7.3

[Kunal Mehta]

Hi,

On 10/23/18 2:51 AM, Joseph Nuthalapati wrote:
> MediaWiki doesn't recognize the packages php-mbstring, php-xml
> and php-sqlite3 if their PHP 7.3 versions are installed.
> 
> On Debian testing, the installation fails.
> On Debian unstable, the installation works but MediaWiki fails to
> start because it doesn't recognize php7.3-sqlite3 as its database
> driver. Manually installing php7.2-sqlite3 fixes this.

I'm not able to reproduce this locally on unstable, I have MediaWiki
running under PHP 7.3 just fine.

Given that installing php7.2-sqlite3 fixed your issue, I suspect that
Apache was still using the php7.2 module instead of php7.3. Maybe you
need to manually disable the old module (sudo a2dismod php7.2) and then
enable the new one (sudo a2enmod php7.3)?

You can verify that Apache is properly using 7.3 by creating a PHP file
that just calls `

Bug#908632: linux-image-4.19.0-rc3-amd64-unsigned: kernel 4.19 fails to load amdgpu driver on R9 270X.

[felipe]

Hi!

Did as you suggested:

# apt purge firmware-amd-graphics
# rm -rf /lib/firmware/amdgpu
# apt install firmware-amd-graphics

Then I copied file by file, restarting the system between each copy until I got 
a working graphical environment.

The files needed for me are:

pitcairn_mc.bin
pitcairn_smc.bin
pitcairn_pfp.bin
pitcairn_me.bin
pitcairn_ce.bin
pitcairn_rlc.bin

Would you like me to test anything else?


Regards,
Felipe.

On 23/10/2018 15:41, Romain Perier wrote:
> Hello,
> 
> ...
> 
> Yeah that's introduced by commit 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8eaf2b1faaf4358c6337785f2192055c6ef41e0d
> 
> Instead of copying all the content of /lib/firmware/radeon into
> /lib/firmware/amdgpu, could you:
> 
> 1. Uninstall firmware-amd-graphics properly so /lib/firmware/radeon and
> /lib/firmware/amdgpu are empty
> 2. Re-install firmware-amd-graphics properly from archives (so,
> basically, these two steps undo your changes)
> 3. Copy only /lib/firmware/radeon/pitcairn_mc.bin to
> /lib/firmware/amdgpu/pitcairn_mc.bin
> 
> Does this work for you ? Otherwise try to find messages in dmesg
> complaining about missing firmware for your amdgpu driver, then
> copy the right missing firmwares from /lib/firmware/radeon to
> /lib/firmware/amdgpu and then once it works, please paste a list here.
> 
> Thanks in advance,
> Regards,
> Romain

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

[Adam D. Barratt]

On Tue, 2018-10-23 at 10:35 -0400, Daniel Kahn Gillmor wrote:
> The fact that the upstream-supported version of enigmail that works
> with the upcoming stretch version of thunderbird depends on these
> fixes is, as you say, another reason to suggest inclusion in debian
> stretch.

>From discussions elsewhere, I understand that the "raw" upstream
enigmail - i.e. installed via upstream's addons service - is actually
already compatible with the new Thunderbird version, and the problem
only affects the Debian packages - is that correct? (Specifically,
upstream includes some kind of compatibility shim, which is not shipped
in our packages for DFSG reasons.)

> > It's also going to need a d-i sign-off, because gnupg produces a
> > udeb.
> 
> I've added debian-b...@lists.debian.org in the hopes that someone
> from there can supply a d-i sign-off.

Explicitly CCing KiBi is generally more effective, as -boot@ is a
fairly busy list at times. I imagine he'll want the SRM review
completed first, but that also depends on whether the changes actually
impact d-i's usage, which I'm not entirely clear on - could you provide
any insight there?

Regards,

Adam

Bug#911706: even after purging I had to go and remove the entry from /var/games/

[shirish शिरीष]

Dear all,

Even after purging moria, it seems /var/games still has a moria directory -

/var/games$ ls | grep moria
  moria

It might just be high-scores or something else. When purging,
shouldn't those contents
be purged as well ?



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

Bug#911706: adequate reports obsolete conffile and unable to remove old directory

[shirish शिरीष]

Package: moria
Version: 5.7.10+20181022-1
Severity: normal

Usertags: obsolete-conffile adequate
User: debian...@lists.debian.org

Dear Maintainer,

While upgrading moria came across the following -

Unpacking moria (5.7.10+20181022-1) over (5.6.debian.1-2+b3) ...
dpkg: warning: unable to delete old directory '/var/games/moria':
Directory not empty

and then -

adequate found packaging bugs
-

moria: obsolete-conffile /etc/moria-hours


Please fix the bugs.

For now, the only workaround seems to be to purge moria and install afresh.

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

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

Versions of packages moria depends on:
ii  libc62.27-6
ii  libgcc1  1:8.2.0-8
ii  libncurses6  6.1+20180714-1
ii  libstdc++6   8.2.0-8
ii  libtinfo66.1+20180714-1

moria recommends no packages.

moria suggests no packages.

-- no debconf information


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

Bug#886394: pdfsam still shows the same error although it does give the banner as gimp does while starting up.

[Markus Koschany]

Control: forwarded -1 https://github.com/torakiki/pdfsam/issues/310
thanks

Apparently upstream managed to run PDFsam with OpenJFX 11. I'm currently
investigating why it doesn't work for us.



signature.asc
Description: OpenPGP digital signature

Bug#900517: courier-imap: Doesn't start: imapd/etc/init.d/courier-imap: xrealloc: .././print_cmd.c:1557: cannot allocate 512 bytes (376832 bytes allocated)

[Markus Wanner]

Control: tags -1 +unreproducible
Control: severity -1 normal

Hello Mehdi,

please excuse my late response to this issue.

On 05/31/2018 07:43 PM, Mehdi Amin wrote:
>  Starting Courier IMAP server: imapd/etc/init.d/courier-imap: xrealloc: 
> .././print_cmd.c:1557: cannot allocate 512 bytes (376832 bytes allocated)

There is no file `print_cmd.c` in the sources of courier.  Nor could I
reproduce this issue on oldstable.

Instead, `print_cmd.c` can be found in bash and has the following at
line 1557:

> the_printed_command = (char *)xrealloc (the_printed_command, 
> the_printed_command_size);

Therefore I think this is unrelated to courier-imap.  Please provide
further details, if you continue to have trouble with bash or
courier-imap.  Otherwise, I'd like to close this issue.  Thank you.

Kind Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#909000: [Pkg-mozext-maintainers] Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload

[Daniel Kahn Gillmor]

Control: clone 909000 -2
Control: retitle -2 apt: error message "apt install enigmail" failure is 
misleading
Control: reassign -2 apt 1.4.8
Control: severity -2 minor

On Mon 2018-10-22 08:28:50 -0400, Fabián Rodríguez wrote:
> This also fails in a clean Stretch install:
>
> # apt 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.

I just want to note that this error message specifically appears to be a
bug in apt -- the reason apt won't let you install enigmail is because
the version of thunderbird in debian-security stretch/updates
(thunderbird 1:60.0) is marked with:

   Breaks: enigmail (<< 2:2~)

That's correct, because versions of enigmail prior to 2.0 do not work on
thunderbird 60 any longer.

it would be nice if apt improved the reporting here, to identify that
the cause of the problem is a conflict between the currently installed
version of thunderbird, and the desired version of enigmail.

Compare the differences with neither thunderbird nor enigmail installed:

root@stretch:~# apt 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.
 root@stretch:~# apt install enigmail thunderbird
 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:
 thunderbird : Breaks: enigmail (< 2:2~) but 2:1.9.9-1~deb9u1 is to be
 installed
 E: Unable to correct problems, you have held broken packages.
 root@stretch:~#


the latter error message is clearly the correct one, but it doesn't
show in the former attempt.

--dkg


signature.asc
Description: PGP signature

Bug#911586: ejabberd: Fail to work with PAM authentication (wrong euid on epam) with systemd setup

[Petter Reinholdtsen]

[Philipp Huebner]
> thanks for the report, but this has been documented in ejabberd's
> README.Debian for quite some time (due to #854178), a quick look into
> the docs might have saved you a bit of time ;)

Right.  It did not occur to me that this was intended behaviour.  I
looked for a epam manual page and checked the systemd setup, but did not
think of checking README.Debian.

-- 
Happy hacking
Petter Reinholdtsen

Bug#911621: [Pkg-utopia-maintainers] Bug#911621: Re : Bug#911621: Re : Bug#911621: network-manager: crash since last apt upgrade

[Michael Biebl]

Am 23.10.18 um 20:10 schrieb Michael Biebl:
> Hi Bernhard
> 
> Am 23.10.18 um 18:45 schrieb Bernhard Übelacker:
>> Hello all,
>>
>> I tried to reproduce this issue and think I found the problem.
>>
>> In commit [1] a typo creeped in and "block->name" got replaced by 
>> "block_name".
>> Variable block_name gets not initialized and therefore g_str_has_prefix 
>> crashes.
>> Might be on other architectures just valid or zero by luck.
>>
>>  /* Bridge configuration */
>> -if(!strncmp ("br", block->name, 2)) {
>> +if (g_str_has_prefix (block_name, "br")) {
>>  /* Try to find bridge ports */
>>
> 
> Well, spotted. That looks indeed like the culprit.

This desperately cries for some autopkgtest tests which tests various
ifupdown configurations
- managed=true/false
- valid iface config with/without a corresponding auto/allow-hotplug
- invalid iface config with/without a corresponding auto/allow-hotplug
- ...

Lot's of combinations to test...

I'd be more then grateful if someone want's to give NM a bit of
autopkgtest love.

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



signature.asc
Description: OpenPGP digital signature

Bug#911621: [Pkg-utopia-maintainers] Bug#911621: Re : Bug#911621: Re : Bug#911621: network-manager: crash since last apt upgrade

[Michael Biebl]

Hi Bernhard

Am 23.10.18 um 18:45 schrieb Bernhard Übelacker:
> Hello all,
> 
> I tried to reproduce this issue and think I found the problem.
> 
> In commit [1] a typo creeped in and "block->name" got replaced by 
> "block_name".
> Variable block_name gets not initialized and therefore g_str_has_prefix 
> crashes.
> Might be on other architectures just valid or zero by luck.
> 
>   /* Bridge configuration */
> - if(!strncmp ("br", block->name, 2)) {
> + if (g_str_has_prefix (block_name, "br")) {
>   /* Try to find bridge ports */
> 

Well, spotted. That looks indeed like the culprit.

I've forwarded this upstream at
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/31

-- 
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#910567: Git respository issues for sn package.

[Robert J. Clay]

I have been working on the packaging, including resolving the 'serious' bug [1].
However, when attempting to test my progress so far, I've run into
issues with the git respository [2].

When attempting to do a package build from the git repository (using
'gbp'), the build fails with an error message referring a missing file
'patch-stamp', which had apparently been cleaned up at the start of
the build.  Found that the file is indeed in the repository and looks
to have been imported with Debian sn package version 0.3.8-3 some 10
years ago.  I had already found that the so-called 'upstream' branch
also has a 'debian' directory, which is not good for a non-native
package.

Fortunately I do have a clean sn_0.3.8.orig.tar.gz archive so I've
been working around the issue by doing manual test builds using
'debuild'.  That has slowed down working on the package, however...



-- 
Robert James Clay
rjc...@gmail.com
j...@rocasa.us
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909928
[2] https://salsa.debian.org/debian/sn

Bug#911704: keymapper: depends on obsolete yapps2-runtime

[Ivo De Decker]

package: keymapper
version: 0.5.3-10.1
severity: serious

Hi,

In the latest upload of yapps2, yapps2-runtime was removed, but keymapper
still depends on it. Please update this dependency.

Thanks,

Ivo

Bug#911703: xfce4-panel: Bug to hide painel

[Ewerton Urias]

Package: xfce4-panel
Version: 4.12.2-1
Severity: normal

Dear Maintainer,

When xfce4-panel is set to "Automatically hide the panel: Intelligently", if
there is a window behind the panel, when a pass the mouse over a plugin, and
then over the plugin description, the panel is hidden instantly.

This bug occurs only in this condition.

I've shutting down the screen composer, I've reinstalled Debian using the most
updated NetInst ISOs, until now there is no solution to this problem that has
been around for almost a year.

For better understanding, watch this video, the bug occurs after 0:18 seconds.

https://youtu.be/HnB72aDvCGQ



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

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

Versions of packages xfce4-panel depends on:
ii  exo-utils0.12.2-2
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo21.16.0-1
ii  libdbus-1-3  1.12.10-1
ii  libdbus-glib-1-2 0.110-3
ii  libexo-1-0   0.12.2-2
ii  libfontconfig1   2.13.1-1
ii  libfreetype6 2.8.1-2
ii  libgarcon-1-00.6.1-2
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgtk2.0-0  2.24.32-3
ii  libice6  2:1.0.9-2
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  libsm6   2:1.2.2-1+b3
ii  libwnck222.30.7-6
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfce4ui-1-0   4.12.1-3
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#908632: linux-image-4.19.0-rc3-amd64-unsigned: kernel 4.19 fails to load amdgpu driver on R9 270X.

[Romain Perier]

Hello,


On Fri, Sep 21, 2018 at 02:13:27PM -0300, felipe wrote:
> Tested again with experimental kernel 4.19-rc4 and the result is the same 
> (not able to find firmware) as with 4.19-rc3
> and 4.19-rc2.
> 
> Tried reinstalling the firmware-amd-graphics and firmware-linux packages.
> 
> Booting with kernel parameters 'radeon.si_support=0 amdgpu.si_support=1' and 
> kernel 4.19.rc-4 the system bails and
> cannot find the required firmware which is located at '/lib/firmware/radeon'.
> 
> If I copy the contents of '/lib/firmware/radeon' to '/lib/firmware/amdgpu' 
> and restart, the system boots, loads the
> firmware and works.
> 
> Since previous kernels (4.17, 4.18) the system had no problem finding the 
> correct firmware inside '/lib/firmware/radeon'
> when using amdgpu driver.
>

Yeah that's introduced by commit 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8eaf2b1faaf4358c6337785f2192055c6ef41e0d

Instead of copying all the content of /lib/firmware/radeon into
/lib/firmware/amdgpu, could you:

1. Uninstall firmware-amd-graphics properly so /lib/firmware/radeon and
/lib/firmware/amdgpu are empty
2. Re-install firmware-amd-graphics properly from archives (so,
basically, these two steps undo your changes)
3. Copy only /lib/firmware/radeon/pitcairn_mc.bin to
/lib/firmware/amdgpu/pitcairn_mc.bin

Does this work for you ? Otherwise try to find messages in dmesg
complaining about missing firmware for your amdgpu driver, then
copy the right missing firmwares from /lib/firmware/radeon to
/lib/firmware/amdgpu and then once it works, please paste a list here.

Thanks in advance,
Regards,
Romain

> 
> 
> 
> On 9/13/18 1:44 PM, felipe wrote:
> > Today I had some spare time and I did some tests.
> > 
> > On kernel 4.17 and 4.18 I can switch from radeonsi to amdgpu using/removing 
> > 'radeon.si_support=0 amdgpu.si_support=1'
> > and the system finds and loads the relevant firmware in 
> > /lib/firmware/radeon, giving this system a boost in performance,
> > correct HDMI output and no crashes.
> > 
> > Booting kernel 4.19, the system could not load the relevant firmware when I 
> > tried to use amdgpu, but booted using radeonsi.
> > 
> > Today I did copy all the firmware in '/lib/firmware/radeon' to 
> > '/lib/firmware/amdgpu' and the system booted in a working
> > state and has been stable for the last hour.
> > 
> > Since it is possible to use amdgpu with older GCN cards, the kernel should 
> > also look for the firmware inside
> > '/lib/firmware/radeon' when using 'amdgpu' driver.
> > 
> > 
> > '$ cat /var/log/syslog' of this working session with kernel 4.19-rc3 and 
> > 'cp /lib/firmware/radeon/* /lib/firmware/amdgpu'

Bug#880554: #880554: max grant frames problem

[Ian Jackson]

Control: retitle -1 max grant frames problem (domu freeze with 
linux-image-4.9.0-4-amd64)
Control: severity -1 important
Control: reassign -1 src:xen 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9

Just gardening here.

(i) Bug title should mention grant frames.

(ii) This does not affect all use cases and is not, IMO, RC.  Although
we should certainly see if we can improve it.

(iii) Britney is confused because the bug was reassigned to
xen-hypervisor-4.8-amd64 and thinks that updating to the 4.11-based
packages from sid would help reduce RC bugs since they lack that .deb.
This is wrong, of course.  For this reason in general bugs should be
reported against src:xen rather than against binary packages with
Xen versions in their package name.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#911701: New azure linux waagent

[Roiy Zysman]

Package: waagent
Version: 2.2.32
Hello, we have completed our work and published a new version of the Azure 
linux agent.
The new package is located here: 
https://github.com/Azure/WALinuxAgent/releases/tag/v2.2.32
Changes, bug fixes and improvements list:
[#1325] Enable cgroups by 
default on all distros
[#1327, 
#1347] Allow enforcing of 
cgroups limits
[#1337] Allow configuration 
for cgroups
[#1333] Add support for NSBSD
[#1319] Stream extension 
downloads to disk (do not buffer the download in memory)
[#1303] Fix to support custom 
DNS servers
[#1306] Log extension stdout 
and stderr
[#1302] Better of cloud-init 
configuration during deprovisioning
[#1295] Fix to report the 
correct extension error code
[#1289] Allow disabling the 
agent or extensions
[#1290] Use the "ip route" 
command instead of the "route" comand during network configuration
[#1281] Delete JIT accounts
[#1234] Fix for reading KVP 
values from host
[#1287] Add UDEV rule in azure 
disk encryption
Thanks
Roiy

Bug#911621: Re : Re : [Pkg-utopia-maintainers] Bug#911621: Re : Bug#911621: network-manager: crash since last apt upgrade

[nicolas . patrois]

Le 23/10/2018 16:02:58, Michael Biebl a écrit :

> Hm, so there is an incomplete config for eth2 and the ifupdown plugin
> fails while trying to parse /etc/network/interfaces.

> My recommendation would be to remove that "auto eth2" line or comment
> it out. That should make NetworkManager work again.

Nope, still the same crash when I comment this line.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#911621: Re : [Pkg-utopia-maintainers] Bug#911621: Re : Bug#911621: network-manager: crash since last apt upgrade

[Bernhard Übelacker]

Hello all,

I tried to reproduce this issue and think I found the problem.

In commit [1] a typo creeped in and "block->name" got replaced by "block_name".
Variable block_name gets not initialized and therefore g_str_has_prefix crashes.
Might be on other architectures just valid or zero by luck.

/* Bridge configuration */
-   if(!strncmp ("br", block->name, 2)) {
+   if (g_str_has_prefix (block_name, "br")) {
/* Try to find bridge ports */

Kind regards,
Bernhard

[1] 
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/src/settings/plugins/ifupdown/nms-ifupdown-plugin.c?id=f0938948bc506f2bddda2d574b0890cb4b67b4c4

Homepage: https://wiki.gnome.org/Projects/NetworkManager
Bug tracker: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues
Git: https://cgit.freedesktop.org/NetworkManager/NetworkManager/



# switch sources.list to unstable

apt update
apt dist-upgrade

apt install dpkg-dev devscripts systemd-coredump gdb network-manager 
network-manager-dbgsym libglib2.0-0-dbgsym



mkdir network-manager/orig -p
cdnetwork-manager/orig
apt source network-manager
cd ../..




dmesg
[ 3062.120572] NetworkManager[4737]: segfault at 1 ip b7711328 sp bfce5040 
error 4 in libc-2.27.so[b76a4000+14c000]
[ 3062.120580] Code: 83 c2 04 0f b6 42 ff 83 c1 04 0f b6 59 ff 84 c0 74 47 38 
d8 75 43 39 f2 75 b8 83 e7 03 eb 07 8d 76 00 31 db 31 c0 85 ff 74 2f <0f> b6 02 
0f b6 19 38 d8 75 25 84 c0 74 21 be 01 00 00 00 eb 16 8d 



root@debian:/var/cache/apt/archives# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2018-10-23 18:11:56 CEST   4737 0 0  11 present   
/usr/sbin/NetworkManager
...



set height 0
set width 0
set pagination off
directory /home/benutzer/network-manager/orig/network-manager-1.14.2




root@debian:/var/cache/apt/archives# coredumpctl gdb 4737
   PID: 4737 (NetworkManager)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Tue 2018-10-23 18:11:55 CEST (10min ago)
  Command Line: /usr/sbin/NetworkManager --no-daemon
Executable: /usr/sbin/NetworkManager
 Control Group: /system.slice/NetworkManager.service
  Unit: NetworkManager.service
 Slice: system.slice
   Boot ID: c10f4f5c16884a26add01274274b3c2f
Machine ID: 45f49504b47f4e5690bc479adf67aa5b
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.NetworkManager.0.c10f4f5c16884a26add01274274b3c2f.4737.15403500.lz4
   Message: Process 4737 (NetworkManager) of user 0 dumped core.

Stack trace of thread 4737:
#0  0xb7711328 n/a (libc.so.6)
#1  0xb7aba962 g_str_has_prefix (libglib-2.0.so.0)
#2  0xb62ca113 initialize 
(libnm-settings-plugin-ifupdown.so)
#3  0x0064f5c4 add_plugin (NetworkManager)
#4  0x006521df add_plugin_load_file (NetworkManager)
#5  0x00530823 nm_manager_start (NetworkManager)
#6  0x00502e7c main (NetworkManager)
#7  0xb76a49a1 __libc_start_main (libc.so.6)
#8  0x005031c8 _start (NetworkManager)

GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/NetworkManager...Reading symbols from 
/usr/lib/debug/.build-id/a4/c366d1bc0595bf150e362e650e64d1fd003eda.debug...done.
done.
[New LWP 4737]
[New LWP 4738]
[New LWP 4739]
[New LWP 4740]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/NetworkManager --no-daemon'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strncmp_ia32 (s1=0x2 , 
s2=0xb62ce23c "br", n=2) at ../string/strncmp.c:64
64  ../string/strncmp.c: Datei oder Verzeichnis nicht gefunden.
[Current thread is 1 (Thread 0xb6d0a640 (LWP 4737))]
(gdb) set height 0
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/network-manager/orig/network-manager-1.14.2
Source directories searched: 
/home/benutzer/network-manager/orig/network-manager-1.14.2:$cdir:$cwd

(gdb) bt
#0  __strncmp_ia32 (s1=0x2 , 

Bug#911045: xenstore-utils: removal of xenstore-utils makes files disappear from xen-utils-common

[Ian Jackson]

Control: severity -1 normal
Control: retitle -1 xenstore-utils should declare Breaks old xen-utils-common

Ian Jackson writes ("Re: xenstore-utils: removal of xenstore-utils makes files 
disappear from xen-utils-common"):
> Indeed I looked at the log and it does show a downgrade, not a
> removal, of xenstore-utils.

As discussed, I don't think this is an RC bug.  We should improve it
though at some point, by adding a Breaks, as that is straightforward.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#886055: [mssh] Port to GSettings

[Yavor Doganov]

Hector Garcia Alvarez wrote:
> I'll do a new upstream release and a new Debian package.

I just noticed that I forgot to remove mssh.schemas from EXTRA_DIST in
the top-level Makefile.am, so "make distcheck" is likely to fail.
Sorry about that.

Bug#911700: cmake: Please include upstream patch to fix GNU/kFreeBSD install directories

[James Clarke]

Source: cmake
Version: 3.12.3-2
Severity: important
Forwarded: https://gitlab.kitware.com/cmake/cmake/merge_requests/2511
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Control: affects -1 src:apt

Hi,
Please include the above patch submitted and applied upstream to fix
GNUInstallDirs's behaviour on GNU/kFreeBSD. This fixes man pages being
installed to the wrong directory, which is causing apt (and I imagine
many other packages) to FTBFS.

Regards,
James

Bug#886055: [mssh] Port to GSettings

[Hector Garcia Alvarez]

Hi Axel,

I'll do a new upstream release and a new Debian package.
I wasn't aware of the patch, sorry. I'll merge it ASAP
Thanks a lot Yavor

Regards,

Hector

On 23/10/2018 15:33, Axel Beckert wrote:

Hi Yavor,

Yavor Doganov wrote:

Attached is a patch which fixes this bug.

Thanks for that!


See #907826 for the rationale behind recommending gconf2.

Hehe, just wanted to ask.

For those too lazy to check there and figure out which mail in that
bug report is meant, here is the essence:

   This patch seems to include a conversion file to migrate the existing
   data/settings over from gconf2 to gsettings database, however the
   'gsettings-data-convert' tool is part of the 'gconf2' package
   but there's no dependency from gnomint against gconf2 so the
   conversion
   won't happen unless the user already has gconf2 installed (which
   is becoming less and less likely).
   
   With gsettings migration I guess you feel it's unwelcome to have

   a dependency on gconf2 remaining in buster, but for data conversion
   the dependency needs to remain until gsettings conversion has shipped
   in one stable debian release (as a minimum).

(Citing from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907826#14)

Hector: Can you do a new upstream release or at least an upload with
this patch? If not I'm tempted to do an NMU to keep mssh in Buster as
I rely on it a lot.

Regards, Axel

Bug#911699: RFS: xpad/5.1.0-1 -- sticky note application for X

[JCF Ploemen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for "xpad":

  Package name: xpad
  Version : 5.1.0-1
  Upstream Author : Arthur Borsboom
  URL : https://launchpad.net/xpad
  License : GPL-3+
  Section : x11

It builds a single binary package:
  xpad - sticky note application for X

Mentors URL:
  https://mentors.debian.net/package/xpad

Download with dget:
  dget -x https://mentors.debian.net/debian/pool/main/x/xpad/xpad_5.1.0-1.dsc

Changes since last upload:
  * New upstream release.
  * Bump Standards-Version to 4.2.1 (from 4.1.0; no further changes).
  * Compat: bump to 11 (from 10) and set debhelper version accordingly.
  * Copyright:
+ bump years for upstream and packaging.
+ use https for copyright format URI.
  * Rules: remove '--with autoreconf' from dh sequencer, obsolete.
  * Remove trailing whitespaces from d/{changelog,control}.
  * Control:
+ add build-dep on libgl1-mesa-dev (for pkgconfig/gl.pc).
+ add explicit build-dep on libglib2.0-dev (to enforce a required
  minimum version, see upstream rev. 961).
+ bump version for gtk-related build-deps to 3.22 (from 3.10).
  * Watch: add extra gpg key (0C4280A0) to d/upstream/signing-key.asc,
used by upstream alongside existing key (951FC552).


Regards.


pgp9RE2mJadVZ.pgp
Description: OpenPGP digital signature

Bug#911621: Re : [Pkg-utopia-maintainers] Bug#911621: Re : Bug#911621: network-manager: crash since last apt upgrade

[Michael Biebl]

Am 23.10.18 um 17:30 schrieb nicolas.patr...@gmail.com:
> Le 23/10/2018 15:27:52, Michael Biebl a écrit :
> 
>> Thanks. So it crashes in the ifupdown plugin.
>> Can you share your /etc/network/interfaces file
> 
>> cat /etc/network/interfaces
> # Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
> # /usr/share/doc/ifupdown/examples for more information.
> auto lo
> iface lo inet loopback
> 
> #NetworkManager#iface eth2 inet dhcp
> 
> auto eth2
> 
> #iface eth1 inet dhcp
> 
> #auto eth1

Hm, so there is an incomplete config for eth2 and the ifupdown plugin
fails while trying to parse /etc/network/interfaces.

My recommendation would be to remove that "auto eth2" line or comment it
out. That should make NetworkManager work again.

That said, NM should treat this more carefully, obviously.

And while at it, I would suggest setting managed=true to managed=false
(which is the default)

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



signature.asc
Description: OpenPGP digital signature

Bug#911525: iwd 0.10 supports building against external ell

[Andreas Henriksson]

On Tue, Oct 23, 2018 at 08:46:13PM +0900, Nobuhiro Iwamatsu wrote:
> Hi,
> 
> > For the record the just released iwd 0.10 supports building against an 
> > external ell (eg. not using the embedded code copy of ell).
> >
> > See the --enable-external-ell configure flag (which is still not being used 
> > because of previously mentioned issues).
> >
> 
> I just upload ell 0.12, and I test building iwd with
> '--enable-external-ell' option.
> Packge building is fine. I attached a patch for support compiling
> packages with external ELL.

Thanks for testing. Do we want to commit to doing this though?

That will mean:
a/ you'll need to be on your toes with new versions to not block
   uploading new iwd versions.
b/ every time you upload a new ell version we'll need to have
   some kind of mini-transition (potentially involving
   debian release team which will not look kindly on libraries
   which do breaking changes without bumping soname/sover).

Most likely I'd say we should generate a very strict dependency
from iwd on ell, since we know there are now ABI guarantees and
upstream will thus not bump soname/sover when doing breaking
changes. That would mean every new ell version would make iwd
uninstallable until it has been rebuilt (if API is still not
broken which would require a sourceful upload).

I'm not sure the hassle is worth it at this point.

OTOH, the hassle would be mostly on your side since Debian
normally frowns on breaking changes and you as ELL maintainer
would be the one doing those. :P

For now I'm leaning towards postponing this for a while still...

Regards,
Andreas Henriksson

Bug#911698: ITS: tbb

[Mo Zhou]

Package: libtbb-dev
Version: 2017~U7-8
Severity: important
X-Debbugs-CC: steven.cap...@gmail.com, 
debian-science-maintain...@lists.alioth.debian.org, 
debian-scie...@lists.debian.org

tbb packaging repo is hosted under debian-science team's namespace on
Salsa.  However the maintainer is not set to the team.

Someone with strong background about tbb contacted my and he/she might
want to help update this package.  To ensure that my further action on
this package, including sponsorship and team upload, is legal, I should
submit this ITS early.

[1] 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#ps-guidelines

Bug#911621: Re : [Pkg-utopia-maintainers] Bug#911621: Re : Bug#911621: network-manager: crash since last apt upgrade

[nicolas . patrois]

Le 23/10/2018 15:27:52, Michael Biebl a écrit :

> Thanks. So it crashes in the ifupdown plugin.
> Can you share your /etc/network/interfaces file

> cat /etc/network/interfaces
# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
# /usr/share/doc/ifupdown/examples for more information.
auto lo
iface lo inet loopback

#NetworkManager#iface eth2 inet dhcp

auto eth2

#iface eth1 inet dhcp

#auto eth1


nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2018-10-23 at 08:07 -0700, Jeremiah Mahler wrote:
> Re: Yves-Alexis,
> 
> On Tue, Oct 23, 2018 at 11:01:21AM +0200, Yves-Alexis Perez wrote:
> [...]
> > On Mon, 2018-10-22 at 20:48 -0700, Jeremiah Mahler wrote:
> > > I am experiencing this problem and I found a workaround ...
> > 
> > Did you try the other workarounds (vt-switch back and forth)? Was it not
> > working?
> > 
> 
> Alt-F1, Ctrl-Alt-Backspace, etc, don't get me to the terminal prompt.
> Maybe I'm using the wrong keys in Xfce?

Try Ctrl-Alt-F1 then Ctrl-Alt-F8.
> 
> > > If I create an Xorg config file that says to use the Intel
> > > driver it works.
> > 
> > Interesting. There might be a bad interaction with the driver where it
> > doesn't
> > switch the backlight on or something.
> > > Perusing the /var/log/Xorg.0.log finds that it was using the
> > > fbdev driver before.
> > 
> > Are you sure? I think Intel cards should be using the “modesetting” driver
> > by
> > default.
> > 
> 
> Hmm, I found references to both fbdev and modesetting modules in the
> Xorg.0.log (see attached).

That's interesting indeed. Do you have multiple video adapters or just one?
Can you try to remove xserver-xorg-video-fbdev and see what happens?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlvPPj4ACgkQ3rYcyPpX
RFu+vwf9Fye72g4ifG+dRcnYDzMyXGCC9iz+5ovkj/Vmvm2VhB1YQX22BtqurFkx
Nw3w0N5YqKto0geRmnaVUNkQgXeT4kRmhl4RGqmvYJvyfy939RY3qBNu4H7gz0m6
F7bUMvxcB427Tbs1+AAkTDkMRvcek554Y2qFkGsfPkF19MfCIYWi2AZofon7yNPR
iWPV9emqoIUmhsIg2xptEO3+xpU+m17pDtrf763t2nP8kg8mYbzV7vyKUgmjz1Wd
dw9scn3JR8CNpjHfrL21JQhFvaVMuKZoomw8XXd6wHuh8VFo5caLU7GoOF8SMRgg
/G30+guXUHQSMlsq7JItPO9I5CLp6A==
=nwQh
-END PGP SIGNATURE-