Bug#869116: kcharselect segfaults

[Stuart Prescott]

Hi Guillaume,

I was seeing similar crashes to you in kcharselect. Removing the package 
at-spi2-core and ensuring that its processes at-spi2-registryd and 
at-spi-bus-launcher were not still running was enough to prevent 
these crashes. 

Does that work for you?

cheers
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#874202: [borgbackup] undefined symbol: PyFPE_jbuf in crypto.cpython-35m-x86_64-linux-gnu.so

[Salvatore Bonaccorso]

Hi Adrien,

[dislcaimer: not the maintainer of either src:python3.5 nor
src:borgbackup here, but can comment]

On Mon, Sep 04, 2017 at 07:14:26AM +0200, Adrien CLERC wrote:
> Package: borgbackup
> Version: 1.0.11-3
> Severity: grave
> 
> --- Please enter the report below this line. ---
> Hi,
> I have the following python stacktrace:
> # borg
> Traceback (most recent call last):
> ?? File "/usr/bin/borg", line 11, in 
> ?? load_entry_point('borgbackup==1.0.11', 'console_scripts', 'borg')()
> ?? File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> 564, in load_entry_point
> ?? return get_distribution(dist).load_entry_point(group, name)
> ?? File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> 2662, in load_entry_point
> ?? return ep.load()
> ?? File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> 2316, in load
> ?? return self.resolve()
> ?? File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> 2322, in resolve
> ?? module = __import__(self.module_name, fromlist=['__name__'], level=0)
> ?? File "/usr/lib/python3/dist-packages/borg/archiver.py", line 22, in
> 
> ?? from .helpers import Error, location_validator,
> archivename_validator, format_line, format_time, format_file_size, \
> ?? File "/usr/lib/python3/dist-packages/borg/helpers.py", line 35, in
> 
> ?? from . import crypto
> ImportError:
> /usr/lib/python3/dist-packages/borg/crypto.cpython-35m-x86_64-linux-gnu.so:
> undefined symbol: PyFPE_jbuf
> 
> I cannot use borg at the moment. However, I don't understand why, since
> it is already installed on another server (though using the testing
> channel), and it didn't have the issue.

See as reported in #873921. There was an ABI change in src:python3.5.
Looking from the information you have as well unstable sources.list so
you probably got the python3.5 update from there already.

Regards,
Salvatore

Bug#874191: might be a duplicate

[Russell Coker]

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

Yesterday I was investigating an issue that might be related and I just filed 
the above bug report.  Please investigate whether that might be the cause.

# ps axZ|grep sddm
system_u:system_r:xdm_t:s0-s0:c0.c1023 963 ?   Ssl0:00 /usr/bin/sddm

Run "ps axZ|grep gdm3" to see the context, the output should be something like 
the above if all goes well (xdm_t is the relevant part).

# ls -lZ /usr/bin/sddm
-rwxr-xr-x. 1 root root system_u:object_r:xdm_exec_t:s0 475968 Mar 14 19:50 /
usr/bin/sddm

Also run "ls -lZ" on the binary to see if it has the right context, the output 
should be something like the above, xdm_exec_t is the relevant part.

If those checks pass then run the systemctl command suggested in #874201 and 
restart gdm3 to see if it gets the right context.

PS  I gave up on gdm3 last time due to some other issues.  Is there a gdm3 
specific feature you really need?  If you want to improve Debian then 
debugging this is a good thing to do, if you just want a working system then 
sddm might be a better choice.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#874048: catdoc 1:0.95-3 fails to extract text from certain documents

[Robert Zavalczki]

Hi Martín,

in the patch nLen is compared to OLENAMELENGTH * 2, not to OLENAMELENGTH:

diff --git a/src/ole.c b/src/ole.c
index 807ed5b..dbcda42 100644
--- a/src/ole.c
+++ b/src/ole.c
@@ -337,7 +337,7 @@ FILE *ole_readdir(FILE *f) {
e->blocks=NULL;
 
 	nLen=getshort(oleBuf,0x40);

-   if (nLen > (OLENAMELENGTH * 2)) {
+   if (nLen > OLENAMELENGTH) {
free(e);
return NULL;
}

I think that the problem is that "nLen" is in bytes, but OLENAMELENGTH is in UCS-2 
characters. When processing the LibreOffice document an OLE stream having the name 
"SummaryInformation\0" is encountered. The name in bytes of this stream is greater than 
OLENAMELENGTH (32) bytes so the parsing is aborted.

Regards,
Robert

On 04/09/17 02:50, Martín Ferrari wrote:

Hi Robert,

On 02/09/17 12:50, Robert Zavalczki wrote:

Package: catdoc
Version: 1:0.95-3
Tags: patch

Create a simple document in LibreOffice Writer 5.2.7.2 containing a single line: "Hello world!" and 
save it using the "Microsoft Word 97-2003 (.doc)" format. Run "catdoc" on the created 
document. The output is empty.

Details: this bug was introduced in version 1:0.95 and is not reproducible with 
previous versions of catdoc. Applying the attached patch to the source code in 
version 0.95 (catdoc_0.95.orig.tar.gz) seems to fix the issue.

Thanks for the report, but I am not sure I understand this. The current
code in ole.c reads already like your proposed patch:

 if (nLen > OLENAMELENGTH) {
 free(e);
 return NULL;
 }

Although I can reproduce the issue you mention, so there is definitely a
bug. Sadly, catdoc's code is not the easiest to follow :/

Bug#874201: selinux-policy-default: need typebounds support for systemd NoNewPrivileges=yes

[Russell Coker]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Severity: normal

https://github.com/systemd/systemd/issues/3845
https://bugzilla.redhat.com/show_bug.cgi?id=1411981
https://stackoverflow.com/questions/44127247/does-anyone-know-a-workaround-for-no-new-privileges-blocking-selinux-transitions
https://www.freedesktop.org/software/systemd/man/systemd.exec.html

Above are some relevant URLs to this issue (search for NoNewPrivileges in the
last one).  Currently I've noticed this problem with tor and mysql, but I expect
that other daemons have the same issue:
# ps axZ|grep init_t|grep -v grep
system_u:system_r:init_t:s0 1 ?Ss95:19 /sbin/init
system_u:system_r:init_t:s0  1287 ?Ssl  1042:39 /usr/bin/tor 
--defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc 
--RunAsDaemon 0
system_u:system_r:init_t:s0 30280 ?Ssl7:49 /usr/sbin/mysqld

For tor the following policy is needed to fix it.  This type of change means
that init_t needs EVERY permission that every domain it enters with
NoNewPrivileges=yes has.

typebounds init_t tor_t;
allow init_t tor_exec_t:file entrypoint;
allow init_t tmpfs_t:lnk_file read;

The workaround for this is to run a command like
"systemctl edit tor@default.service" and put in something like the following:
[Service]
NoNewPrivileges=no

But we don't want to disable NoNewPrivileges as that reduces protections on
non-SE systems, which hurts people who run in permissive some of the time and
allows the possibility of a security issue that is stopped by NoNewPrivileges
but not by SE Linux to exploit systems.

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

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

Versions of packages selinux-policy-default depends on:
ii  libselinux1  2.6-3+b1
ii  libsemanage1 2.6-2
ii  libsepol12.6-2
ii  policycoreutils  2.6-3
ii  selinux-utils2.6-3+b1

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.6-2
pn  setools  

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- no debconf information

Bug#874202: [borgbackup] undefined symbol: PyFPE_jbuf in crypto.cpython-35m-x86_64-linux-gnu.so

[Adrien CLERC]

Package: borgbackup
Version: 1.0.11-3
Severity: grave

--- Please enter the report below this line. ---
Hi,
I have the following python stacktrace:
# borg
Traceback (most recent call last):
  File "/usr/bin/borg", line 11, in 
    load_entry_point('borgbackup==1.0.11', 'console_scripts', 'borg')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
564, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
2662, in load_entry_point
    return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
2316, in load
    return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
2322, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 22, in

    from .helpers import Error, location_validator,
archivename_validator, format_line, format_time, format_file_size, \
  File "/usr/lib/python3/dist-packages/borg/helpers.py", line 35, in

    from . import crypto
ImportError:
/usr/lib/python3/dist-packages/borg/crypto.cpython-35m-x86_64-linux-gnu.so:
undefined symbol: PyFPE_jbuf

I cannot use borg at the moment. However, I don't understand why, since
it is already installed on another server (though using the testing
channel), and it didn't have the issue.

Thanks for the help,
Adrien

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

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

--- Package information. ---
Depends (Version) | Installed
===-+-==
fuse | 2.9.7-1
python3-llfuse (<< 2.0) | 1.2+dfsg-1+b1
python3-msgpack (>= 0.4.6~) | 0.4.8-1+b1
python3-pkg-resources | 36.2.7-2
python3 (<< 3.6) | 3.5.3-3
python3 (>= 3.5~) | 3.5.3-3
python3:any (>= 3.3.2-2~) |
libacl1 (>= 2.2.51-8) | 2.2.52-3+b1
libc6 (>= 2.14) | 2.24-17
liblz4-1 (>= 0.0~r114) | 0.0~r131-2+b1
libssl1.1 (>= 1.1.0) | 1.1.0f-5


Package's Recommends field is empty.

Suggests (Version) | Installed
=-+-===
borgbackup-doc |

Bug#873957: postfix: multiple instances not handled correctly by systemd

[Scott Kitterman]

On Friday, September 01, 2017 04:46:34 PM Raoul Gunnar Borenius wrote:
> Package: postfix
> Version: 3.2.2-1
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>  trying to use multiple instances as stated in README.Debian.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>  systemctl enable postfix@myinstance.service
>  systemctl start postfix
> 
>* What was the outcome of this action?
> 
>  only the 'main' Postfix instance was started
> 
>* What outcome did you expect instead?
> 
>  the instance 'myinstance' should also have been started
>  (at least that's how I understand README.Debian)
> 
> The following fix worked for me:
> 
> -
> --- /lib/systemd/system/post...@.service.orig   2017-06-17
> 19:57:19.0 +0200 +++ /lib/systemd/system/postfix@.service   
> 2017-09-01 16:18:43.569388300 +0200 @@ -16,4 +16,4 @@
>  ExecReload=/usr/sbin/postmulti -i %i -p reload
> 
>  [Install]
> -WantedBy=multi-user.target
> +WantedBy=postfix.service
> -
> 
> Now 'systemctl start postfix' starts and stops all enabled instances
> of postfix.
> 
> 
> However digging deeper into the possibilities of systemd there seems to
> be an even better way to handle multiple instances!
> 
> Provided with postfix is a systemd-generator file in
>  /lib/systemd/system-generators/postfix-instance-generator
> which takes care of the multi instance handling.
> At first it did not work for me but applying this small change:
> 
> -
> --- /lib/systemd/system-generators/postfix-instance-generator.orig 
> 2017-06-17 20:10:34.0 +0200 +++
> /lib/systemd/system-generators/postfix-instance-generator   2017-09-01
> 16:24:54.723601375 +0200 @@ -7,7 +7,7 @@
> 
>  mkdir -p "$WANTDIR"
> 
> -if [ -f main.cf ]; then
> +if [ -f /etc/postfix/main.cf ]; then
>  for NAME in $(postmulti -l -a | awk '{ print $1}'); do
>  ln -s "$SERVICEFILE" "$WANTDIR/postfix@$NAME.service"
>  done
> -
> 
> makes it behave as expected for me. It then creates symlinks in
> /run/systemd/generator/postfix.service.wants/...
> which makes the 'systemd enable postfix@myinstance.service'
> command completely unnecessary.
> 
> Would be nice to have that alternative documented in README.Debian,
> maybe even replacing the 'enable' variant because for me it looks
> more elegant.
> 
> Thanks for considering applying my patches and your time
> in maintaining the postifx package!

The change in postfix-instance-generator should be all that's needed.  Once 
that's fixed, I don't think the wanted-by change is needed as the global 
postfix.service already controls all instances through the PartOf field.

Scott K

P.S. Thanks to Raphael Hertzog  for reviewing the proposed 
patch for me.

Bug#864162: opendkim: systemd ExecStart ignore configuration options

[Scott Kitterman]

On Sunday, September 03, 2017 01:22:28 PM Scott Kitterman wrote:
> Once I have it fixed in unstable/testing, I plan to fix Stretch too.

I've uploaded to unstable and have prepared an update for Stretch.  It is 
currently waiting on stable release manager review.

Scott K

Bug#874195: libreoffice: Please enable Albanian (sq) l10n package

[Rene Engelhard]

Hi Lior,

On Mon, Sep 04, 2017 at 02:13:25AM +0300, Lior Kaplan wrote:
>Translation of Albanian is currently at 60-65%, would be nice to have a
>l10n package as upstream already provides them

Hmm. 60-65% is quite low. Normally I'd put the threshold at 80-90%...
I'd more consider it a bug upstream ships it, thenaagain they probably build 
with all languages? (Don't see any --with-lang in
https://cgit.freedesktop.org/libreoffice/core/tree/distro-configs/LibreOfficeLinux.conf
 though)

Regards,

Rene

Bug#874179: cysignals: Add python3 packages

[Jerome BENOIT]

I got it yesterday, hence my silly question about SageMath transition to Python 
3. Jerome

On 04/09/17 00:34, Tobias Hansen wrote:
> Source: cysignals
> Severity: wishlist
> 
> Hi Jerome,
> 
> please add python3 packages in one of the future updates. We will
> eventually need them for sagemath.
> 
> Best,
> Tobias
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#874200: ITP: node-lie -- basic but performant promise implementation

[Pirate Praveen]

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

* Package name: node-lie
  Version : 3.1.1
  Upstream Author : Calvin Metcalf
* URL : https://github.com/calvinmetcalf/lie#readme
* License : Expat
  Programming Lang: JavaScript
  Description :  basic but performant promise implementation

 lie is a small, performant, promise library implementing the
Promises/A+ spec
 Version 1.1.
 .
 Node.js is an event-based server-side JavaScript engine.

This library is a dependency of gitlab 9.x



signature.asc
Description: OpenPGP digital signature

Bug#874199: designate: podebconf error - Keystone authentication token

[Alban Vidal]

Package: designate
Version: 1_3.0.0-4
Severity: minor

Dear Maintainer,

In podebconf screen we can read:
« The admin auth token is not used anymore »

But, we have the question:
« Keystone authentication token: »

In other's OpenStack packages, the question is:
« Keystone admin password: »

Can you update the podebconf screen?

Regards,

Alban Vidal

Bug#873911: [Pkg-xfce-devel] Bug#873911: default user name doesn't change

[Harald Dunkel]

I mean the user name preset on the login screen. The idea is that the previous 
user doesn't have to enter his name again. Apparently this name is never reset 
but stays forever.

Bug#874167: gcc-6-doc: source uploaded without binaries, caused package removal

[Guo Yixuan]

Hello,

Thank you for pointing out the reasons for the current problem. I'll update
the package according to the instructions here:

https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#non-free-buildd

Regards,
Yixuan

On Sun, Sep 3, 2017 at 3:38 PM, Mattia Rizzolo  wrote:

> On Sun, Sep 03, 2017 at 09:30:08PM +0200, Adam Borowski wrote:
> > I've uploaded source+binary identical as before (as it has been in the
> > archive, any modifications would be a bad idea).  If this won't work, the
> > maintainer (Guo Yixuan) is a better person to bump the version and make
> > adjustments.
>
> I fear that it's going to be rejected…  but let's see :)
>
> > XS-Autobuild can be added -2 no matter if we need it tonight or months
> > later.
>
> Right.  But please consider adding it, as it makes only sense to have
> that stuff built on the buildds.  Also remember that XS-Autobuild is
> only the first step, you need to ask it to be whitelisted on the buildds
> https://www.debian.org/doc/manuals/developers-reference/
> ch05.en.html#non-free-buildd
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>



-- 
GUO Yixuan

Bug#873901: fonts-tlwg-waree: Adequate shows obsolete conffile for fonts-tlwg-waree

[Theppitak Karoonboonyanan]

On Fri, Sep 1, 2017 at 11:49 AM, shirish शिरीष  wrote:

>  Thank you for maintaining fonts-tlwg-waree. However, adequte reports
> obsolete conffile for fonts-tlwg-waree. Please fix/remove the same.
>
> $  adequate fonts-tlwg-waree
> [100%]
> fonts-tlwg-waree: obsolete-conffile
> /etc/fonts/conf.avail/89-tlwg-waree-synthetic.conf

Again, It has been removing the obsolete conffiles since 1:0.6.3-1.

$ adequate fonts-tlwg-waree
$

Please check its maintscripts.

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#873900: fonts-tlwg-loma: adequate shows fonts-tlwg-loma having obsolete conffiles

[Theppitak Karoonboonyanan]

On Fri, Sep 1, 2017 at 11:46 AM, shirish शिरीष  wrote:

>Thank you for maintaining fonts-tlwg-loma. adequate shows
> fonts-tlwg-loma having obsolete conffiles .
>
> $ adequate fonts-tlwg-loma
>[100%]
> fonts-tlwg-loma: obsolete-conffile
> /etc/fonts/conf.avail/89-tlwg-loma-synthetic.conf
> fonts-tlwg-loma: obsolete-conffile /etc/fonts/conf.avail/64-12-tlwg-loma.conf
>
> Please fix/remove the two obsolete conffiles.

It has been doing so since 1:0.6.3-1. Please see its maintscripts.

And, to confirm that, this is what adequate says on my box:

$ adequate fonts-tlwg-loma
$

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#874078: lintian: improve binary-file-built-without-LFS-support info field

[Boud Roukema]

Hi again Guillem (sorry I misspelt your surname :),

On Mon, 4 Sep 2017, Guillem Jover wrote:


On Mon, 2017-09-04 at 00:23:42 +0200, Boud Roukema wrote:

At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871956
Guillem Rover proposes to revert this patch (for bug #874078) and make a better
one.


Here's my proposal, let me know if this clarifies it sufficiently. :)


Looks excellent. It could hopefully lead to more LFS conformance in debian
packages, or even better, in upstream packages too.

Cheers
Boud

Bug#874198: stretch-pu: package opendkim/2.11.0~alpha-10+deb9u1

[Scott Kitterman]

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

Thanks to me not understanding some things about systemd service files and
how they interacted with opendkim (and incomplete testing on my part), the
package, as released for stretch, is pretty non-functional.

The attached fixes things.

Thanks,

Scott K
diff -Nru opendkim-2.11.0~alpha/debian/changelog opendkim-2.11.0~alpha/debian/changelog
--- opendkim-2.11.0~alpha/debian/changelog	2017-05-22 18:10:16.0 -0400
+++ opendkim-2.11.0~alpha/debian/changelog	2017-09-03 20:38:52.0 -0400
@@ -1,3 +1,14 @@
+opendkim (2.11.0~alpha-10+deb9u1) stretch; urgency=medium
+
+  * Update opendkim service file so that /etc/opendkim.conf is used (Closes:
+#864162)
+  * Start as root and drop privileges in opendkim so proper key file
+ownership works correctly
+  * Add new options to /etc/opendkim.conf to match the above service file
+changes
+
+ -- Scott Kitterman   Sun, 03 Sep 2017 20:22:45 -0400
+
 opendkim (2.11.0~alpha-10) unstable; urgency=medium
 
   * Do not remove /etc/default/opendkim on upgrade since it is a conffile
diff -Nru opendkim-2.11.0~alpha/debian/opendkim.conf opendkim-2.11.0~alpha/debian/opendkim.conf
--- opendkim-2.11.0~alpha/debian/opendkim.conf	2017-01-21 00:58:41.0 -0500
+++ opendkim-2.11.0~alpha/debian/opendkim.conf	2017-09-03 20:17:50.0 -0400
@@ -19,6 +19,29 @@
 #Mode			sv
 #SubDomains		no
 
+# Socket smtp://localhost
+#
+# ##  Socket socketspec
+# ##
+# ##  Names the socket where this filter should listen for milter connections
+# ##  from the MTA.  Required.  Should be in one of these forms:
+# ##
+# ##  inet:port@address   to listen on a specific interface
+# ##  inet:port   to listen on all interfaces
+# ##  local:/path/to/socket   to listen on a UNIX domain socket
+#
+#Socket  inet:8892@localhost
+Socket			local:/var/run/opendkim/opendkim.sock
+
+##  PidFile filename
+###  default (none)
+###
+###  Name of the file where the filter should write its pid before beginning
+###  normal operations.
+#
+PidFile   /var/run/opendkim/opendkim.pid
+
+
 # Always oversign From (sign using actual From and a null From to prevent
 # malicious signatures header fields (From and/or others) between the signer
 # and the verifier.  From is oversigned by default in the Debian pacakge
@@ -47,3 +70,11 @@
 ## at http://unbound.net for the expected format of this file.
 
 TrustAnchorFile   /usr/share/dns/root.key
+
+##  Userid userid
+###  default (none)
+###
+###  Change to user "userid" before starting normal operation?  May include
+###  a group ID as well, separated from the userid by a colon.
+#
+UserIDopendkim
diff -Nru opendkim-2.11.0~alpha/debian/opendkim.service opendkim-2.11.0~alpha/debian/opendkim.service
--- opendkim-2.11.0~alpha/debian/opendkim.service	2017-01-21 00:45:58.0 -0500
+++ opendkim-2.11.0~alpha/debian/opendkim.service	2017-09-03 20:17:50.0 -0400
@@ -6,9 +6,8 @@
 [Service]
 Type=forking
 PIDFile=/var/run/opendkim/opendkim.pid
-User=opendkim
 UMask=0007
-ExecStart=/usr/sbin/opendkim -P /var/run/opendkim/opendkim.pid -p local:/var/run/opendkim/opendkim.sock
+ExecStart=/usr/sbin/opendkim -x /etc/opendkim.conf
 Restart=on-failure
 ExecReload=/bin/kill -USR1 $MAINPID
 

Bug#874197: override: typecatcher:fonts/optional

[Andrew Starr-Bochicchio]

Package: ftp.debian.org
Severity: normal

See: #820386:

> The section “python” is for packages that install the Python
> programming language or libraries. Its packages are primarily of
> interest only to Python programmers.

> The package ‘typecatcher’ installs primarily an application, of
> interest regardless of the programming language. It should not be in
> the “python” section.

My next upload will set 'fonts' as the section. Please set that in
the override file as well.

Thanks!

Bug#864642: Additional bug information

[Richard Aghassibake]

I experienced this bug when attempting to curl s3.amazonaws.com over
https.  In my case, it manifested as a hardlock of the VM when running
curl.  The behavior also occurred with wget, and intermittently with a
direct openssl session.  The behavior did not occur when curling/wgetting
http.

I resolved the issue by switching the VM's NIC type from vmxnet3 to E1000e.

Please let me know what information or assistance I can provide in
isolating this bug.

Thank you,
Richard Aghassibake

Bug#874196: libreoffice: Icons and other images missing from UI with libreoffice 5.4.x packages

[Peter Eckersley]

Package: libreoffice
Version: 1:5.4.1-1
Severity: important

Dear Maintainer,

Since updating to unstable's 5.4.1 packages, all the icons and other
images are missing from the libreoffice UI. This has a serious impact on
usability (for instance, as shown in this screenshot the only way to pick a
slide layout in loimpress by using tooltips to recognise the buttons: 
https://isnot.org/bugs/lo-icons-missing.png )

The problem persists when I delete my libreoffice config, and is fixed when I
downgrade to 5.2.7-1.

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libreoffice depends on:
ii  libreoffice-avmedia-backend-gstreamer  1:5.4.1-1
ii  libreoffice-base   1:5.4.1-1
ii  libreoffice-calc   1:5.4.1-1
ii  libreoffice-core   1:5.4.1-1
ii  libreoffice-draw   1:5.4.1-1
ii  libreoffice-impress1:5.4.1-1
ii  libreoffice-math   1:5.4.1-1
ii  libreoffice-report-builder-bin 1:5.4.1-1
ii  libreoffice-writer 1:5.4.1-1
ii  python3-uno1:5.4.1-1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-1
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.34-1
ii  fonts-linuxlibertine5.3.0-2
ii  fonts-open-sans 1.11-1
ii  fonts-sil-gentium-basic 1.1-7
ii  libreoffice-java-common 1:5.4.1-1
ii  libreoffice-librelogo   1:5.2.7-1
ii  libreoffice-nlpsolver   0.9+LibO5.2.7-1
ii  libreoffice-ogltrans1:5.4.1-1
ii  libreoffice-report-builder  1:5.4.1-1
ii  libreoffice-script-provider-bsh 1:5.4.1-1
ii  libreoffice-script-provider-js  1:5.4.1-1
ii  libreoffice-script-provider-python  1:5.4.1-1
ii  libreoffice-sdbc-postgresql 1:5.4.1-1
ii  libreoffice-wiki-publisher  1.2.0+LibO5.4.1-1

Versions of packages libreoffice suggests:
ii  cups-bsd2.2.4-3
ii  default-jre [java6-runtime] 2:1.8-57
ii  ghostscript 9.20~dfsg-3.1
ii  gstreamer1.0-libav  1:1.4.4-dmo1
ii  gstreamer1.0-plugins-bad1.10.4-1
ii  gstreamer1.0-plugins-base   1.10.3-1
ii  gstreamer1.0-plugins-good   1.10.3-1
ii  gstreamer1.0-plugins-ugly   1.10.4-1
pn  hunspell-dictionary 
pn  hyphen-hyphenation-patterns 
ii  icedove 1:52.3.0-2
ii  imagemagick 8:6.9.7.4+dfsg-16
ii  imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-16
ii  libgl1-mesa-glx [libgl1]12.0.2-1
pn  libreoffice-gnome   
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
pn  libreoffice-officebean  
ii  libsane 1.0.25-4
ii  libxrender1 1:0.9.10-1
ii  myspell-en-au [myspell-dictionary]  2.1-5.4
pn  mythes-thesaurus
pn  openclipart2-libreoffice | openclipart-libreoffice  
ii  openjdk-8-jre [java6-runtime]   8u141-b15-1
ii  pstoedit3.62-2+b1
ii  thunderbird [icedove]   1:52.3.0-2
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig2.12.3-0.2
ii  fonts-opensymbol  2:102.10+LibO5.4.0-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-4+b1
ii  libc6 2.24-17
ii  libcairo2 1.14.10-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.4-3
ii  libcurl3-gnutls   7.55.0-1
ii  libdbus-1-3   1.11.16+really1.10.22-1
ii  libdbus-glib-1-2  0.108-2
ii  libdconf1 0.26.0-2+b1
ii  libeot0   0.01-4+b1
ii  libepoxy0 1.3.1-3
ii  libexpat1 2.2.3-1
ii  libexttextcat-2.0-0   3.4.4-2+b1
ii  libfontconfig12.12.3-0.2
ii  libfreetype6  2.8-0.2
ii  libgcc1   1:7.2.0-1
ii  

Bug#867710: systemd don't stop user processes reliable on logout, even with KillUserProcesses=yes

[Alf Gaida]

> Closing, due to the lack of further feedback. Feel free to reopen if you
> are available for debugging this further.
I can't reproduce the hangs reliable and i don't restart my main machine
every day.
Beside of that the bug is distribution agnosic. Feel free to ignore it
until it happend
again and can be reproduced reliable.

Bug#874048: catdoc 1:0.95-3 fails to extract text from certain documents

[Martín Ferrari]

Hi Robert,

On 02/09/17 12:50, Robert Zavalczki wrote:
> Package: catdoc
> Version: 1:0.95-3
> Tags: patch
> 
> Create a simple document in LibreOffice Writer 5.2.7.2 containing a single 
> line: "Hello world!" and save it using the "Microsoft Word 97-2003 (.doc)" 
> format. Run "catdoc" on the created document. The output is empty.
> 
> Details: this bug was introduced in version 1:0.95 and is not reproducible 
> with previous versions of catdoc. Applying the attached patch to the source 
> code in version 0.95 (catdoc_0.95.orig.tar.gz) seems to fix the issue.

Thanks for the report, but I am not sure I understand this. The current
code in ole.c reads already like your proposed patch:

if (nLen > OLENAMELENGTH) {
free(e);
return NULL;
}

Although I can reproduce the issue you mention, so there is definitely a
bug. Sadly, catdoc's code is not the easiest to follow :/

-- 
Martín Ferrari (Tincho)

Bug#872361: mpg123 misparses IPv6 address + port in http_proxy

[Thomas Orgis]

Am Sun, 03 Sep 2017 20:07:43 +
schrieb Ivan Shmakov : 

>  > https://mpg123.org/test/mpg123-1.25.7.tar.bz2  
> 
> […]
> 
>  > Ivan, can you test your two issues with the preliminary release and
>  > give feedback before I make it official?  
> 
>   The IPv6 http_proxy= handling seems to be the other way around
>   now; for instance:

Indeed. Please test the updated preview tarball.


Alrighty then,

Thomas


pgp9o8kqHb5hK.pgp
Description: Firma digital OpenPGP

Bug#874190: cinnamon-desktop-environment: Drop gnome-user-share recommends

[Jeremy Bicha]

To be fair, the recommends is not a fully functional Apache2.

Thanks,
Jeremy Bicha

Bug#874133: xfrisk: Always crashes due to "stack smashing" on pressing "Start game"

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> > I'm not seeing any -O2 in the 1.2-3 build log,
> > so my next guess would be buggy code breaking
> > when compiled with optimization.
> 
> Hrm, the old debian/rules contained this:
> 
> CFLAGS = -Wall -g
> ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
> CFLAGS += -O0
> else
> CFLAGS += -O2
> endif
> export CFLAGS
> 
> … so I thought that optimization shouldn't make a difference.
> 
> But since the old package didn't pass through CFLAGS properly anyway
> (had to fix that in 1.2-4), that's indeed a good point. Will check,
> thanks!

Indeed, this line in debian/rules helps:

export DEB_CFLAGS_MAINT_APPEND=-O0

*sigh*

Thanks for the help!

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

Bug#874195: libreoffice: Please enable Albanian (sq) l10n package

[Lior Kaplan]

Package: libreoffice
Version: 1:5.4.0-1
Severity: wishlist

Translation of Albanian is currently at 60-65%, would be nice to have a
l10n package as upstream already provides them

Kaplan

Bug#874133: xfrisk: Always crashes due to "stack smashing" on pressing "Start game"

[Axel Beckert]

Hi Adrian,

Adrian Bunk wrote:
> On Mon, Sep 04, 2017 at 12:59:59AM +0200, Axel Beckert wrote:
> > Nevertheless it must be something which is part of the 1.2-4 packaging
> > as just recompiling xfrisk 1.2-3 under the same current environment
> > results in a working binary.
> > 
> > Will continue to dig deeper. Hints welcome, though.
> 
> I'm not seeing any -O2 in the 1.2-3 build log,
> so my next guess would be buggy code breaking
> when compiled with optimization.

Hrm, the old debian/rules contained this:

CFLAGS = -Wall -g
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif
export CFLAGS

… so I thought that optimization shouldn't make a difference.

But since the old package didn't pass through CFLAGS properly anyway
(had to fix that in 1.2-4), that's indeed a good point. Will check,
thanks!

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

Bug#874078: lintian: improve binary-file-built-without-LFS-support info field

[Guillem Jover]

Hi!

On Mon, 2017-09-04 at 00:23:42 +0200, Boud Roukema wrote:
> At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871956
> Guillem Rover proposes to revert this patch (for bug #874078) and make a 
> better
> one.

Here's my proposal, let me know if this clarifies it sufficiently. :)

Thanks,
Guillem
From 5960c082e074c31b0bd12281eafba63fd173488f Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 4 Sep 2017 01:01:36 +0200
Subject: [PATCH 1/2] Revert "Apply patch from Boud Roukema to improve the
 description of the binary-file-built-without-LFS-support tag. (Closes:
 #874078)"

This reverts commit f40064ca2ec72bbed05eba25b87aaea4c13ccb20.

Signed-off-by: Guillem Jover 
---
 checks/binaries.desc | 10 +++---
 debian/changelog |  3 ---
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/checks/binaries.desc b/checks/binaries.desc
index 87bbab18d..659c23f10 100644
--- a/checks/binaries.desc
+++ b/checks/binaries.desc
@@ -439,15 +439,11 @@ Info: The listed ELF binary appears to be (partially) built without
  To support large files, code review might be needed to make sure that
  those files are not slurped into memory or mmap(2)ed, and that correct
  64-bit data types are used (ex: off_t instead of ssize_t), etc.  Once
- that has been done ensure, if needed, that _FILE_OFFSET_BITS
- is defined and
- set to 64 before the relevant files are included. This can be done
- conditionally by
+ that has been done ensure _FILE_OFFSET_BITS is defined and
+ set to 64 before the relevant files are included.  This can be done by
  using the AC_SYS_LARGEFILE macro with autoconf, or by appending
  the output of getconf LFS_CFLAGS and getconf LFS_LDFLAGS
- to CFLAGS and LDFLAGS respectively. Functions such
- as pwrite and pread should be replaced by pwrite64 and pread64 in
- cases where _FILE_OFFSET_BITS is defined and set to 64.
+ to CFLAGS and LDFLAGS respectively.
  .
  Take into account that even if this tag is not emitted, that does not
  mean the binary is LFS-safe (ie. no OOM conditions, file truncation
diff --git a/debian/changelog b/debian/changelog
index 8565bbe08..973ca8491 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,9 +5,6 @@ lintian (2.5.53) UNRELEASED; urgency=medium
   * checks/apache2.pm:
 + [CL] Fix an apache2-unparsable-dependency false positive by allowing
   periods (".") in dependency names.  (Closes: #873701)
-  * checks/binaries.pm:
-+ [CL] Apply patch from Boud Roukema to improve the description of the
-  binary-file-built-without-LFS-support tag.  (Closes: #874078)
   * checks/changes.{pm,desc}:
 + [CL] Ignore DFSG-repacked packages when checking for upstream
   source tarball signatures as they will never match by definition.
-- 
2.14.1

From 84e7f2b0342baace2cc80a43bf7de37b898ad212 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 4 Sep 2017 01:01:58 +0200
Subject: [PATCH 2/2] c/binaries: Improve LFS tag description

Mention when setting the _FILE_OFFSET_BITS macro is optional, and that
it does not require renaming function names. Mention the option of
providing parallel interfaces with _LARGEFILE64_SOURCE for shared
libraries. Add references to SUSv2 and the glibc manual.

Closes: #874078
Signed-off-by: Guillem Jover 
---
 checks/binaries.desc | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/checks/binaries.desc b/checks/binaries.desc
index 659c23f10..e0731fb06 100644
--- a/checks/binaries.desc
+++ b/checks/binaries.desc
@@ -440,10 +440,17 @@ Info: The listed ELF binary appears to be (partially) built without
  those files are not slurped into memory or mmap(2)ed, and that correct
  64-bit data types are used (ex: off_t instead of ssize_t), etc.  Once
  that has been done ensure _FILE_OFFSET_BITS is defined and
- set to 64 before the relevant files are included.  This can be done by
- using the AC_SYS_LARGEFILE macro with autoconf, or by appending
- the output of getconf LFS_CFLAGS and getconf LFS_LDFLAGS
- to CFLAGS and LDFLAGS respectively.
+ set to 64 before any system headers are included (note that on systems
+ were the ABI has LFS enabled by default, setting _FILE_OFFSET_BITS
+ to 64 will be a no-op, and as such optional).  This can be done by using
+ the AC_SYS_LARGEFILE macro with autoconf which will set any
+ macro required to enable LFS when necessary, or by appending the output
+ of getconf LFS_CFLAGS and getconf LFS_LDFLAGS to
+ CFLAGS and LDFLAGS respectively.  Using
+ _FILE_OFFSET_BITS should require no system function renames (eg.
+ from open(2) to open64(2)), and if this tag is still emitted, the most
+ probable cause is because the macro is not seen by the system code being
+ compiled.
  .
  Take into account that even if this tag is not emitted, that does not
  mean the binary is LFS-safe (ie. no OOM conditions, file truncation
@@ -451,4 +458,10 @@ Info: The listed ELF binary appears to 

Bug#874133: xfrisk: Always crashes due to "stack smashing" on pressing "Start game"

[Adrian Bunk]

On Mon, Sep 04, 2017 at 12:59:59AM +0200, Axel Beckert wrote:
>...
> Nevertheless it must be something which is part of the 1.2-4 packaging
> as just recompiling xfrisk 1.2-3 under the same current environment
> results in a working binary.
> 
> Will continue to dig deeper. Hints welcome, though.

I'm not seeing any -O2 in the 1.2-3 build log,
so my next guess would be buggy code breaking
when compiled with optimization.

>   Regards, Axel

cu
Adrian

-- 

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

Bug#874133: xfrisk: Always crashes due to "stack smashing" on pressing "Start game"

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> Adrian Bunk wrote:
> > Crashes for me with 1.2-4
> > Works for me with 1.2-3+b2
> > 
> > Looking at the build logs, the hardening flags
> > (especially -fstack-protector-strong) are new
> > in -4 and likely trigger the issue.
> 
> Thanks for that hint! Didn't notice it when uploading 1.2-4. Probably
> didn't test far enough.

Hrm, The crashes are less verbose with "export
DEB_BUILD_MAINT_OPTIONS=hardening=-all", "export
DEB_BUILD_MAINT_OPTIONS=hardening=-stackprotectorstrong" or "export
DEB_BUILD_MAINT_OPTIONS=hardening=-stackprotector,-relro,-pie", but
still there:

~ → xfrisk localhost
CLIENT: Connected to server.
CLIENT: Waiting for server to send client ID...Done.
[1]11208 segmentation fault (core dumped)  xfrisk localhost

The backtrace now looks as follows:

(gdb) bt
#0  CBK_IncomingMessage (iMessType=, pvMess=0x) at 
callbacks.c:327
#1  0xcfc6 in CBK_XIncomingMessage (pClientData=, 
iSource=, 
id=) at callbacks.c:97
#2  0x772fc58a in XtAppProcessEvent () from 
/usr/lib/x86_64-linux-gnu/libXt.so.6
#3  0x772f0dcd in XtAppMainLoop () from 
/usr/lib/x86_64-linux-gnu/libXt.so.6
#4  0xa28d in main (argc=2, argv=0x7fffdf38) at clientMain.c:103

Nevertheless it must be something which is part of the 1.2-4 packaging
as just recompiling xfrisk 1.2-3 under the same current environment
results in a working binary.

Will continue to dig deeper. Hints welcome, though.

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

Bug#874194: ansible: --force doesn't replace unversioned roles

[JD Friedrikson]

Package: ansible
Version: 2.3.1.0+dfsg-2
Severity: normal

Hello!

Currently ansible doesn't allow for updating roles via forced installs.
This affects all versions packaged by Debian. This is considered a bug
that was fixed upstream:
https://github.com/ansible/galaxy-issues/issues/249
https://github.com/ansible/ansible/pull/23391

Here's the patch:

```
commit 78836ec0b9719a62fa0f8619707a9f411ed4a4f0
Author: Michael Scherer 
Date:   Fri Apr 21 13:40:47 2017 +0200

Fix --force for unversionned requirements (#23391)

In current stable (2.2), ansible galaxy install --force do erase
a role, even if the version is not set. This commit should restore
that specific behavior, in accordance to people reports:
  https://github.com/ansible/ansible/issues/11266#issuecomment-273801480

It was also the behavior planned in the initial discussion:
"if you're not fixing versions in your roles file, then it's fine
to expect that the role will be reinstalled each time you run
ansible-galaxy install.", cf https://github.com/ansible/ansible/pull/12904

diff --git a/lib/ansible/cli/galaxy.py b/lib/ansible/cli/galaxy.py
index 8554b68c4..6baf7affb 100644
--- a/lib/ansible/cli/galaxy.py
+++ b/lib/ansible/cli/galaxy.py
@@ -389,8 +389,9 @@ class GalaxyCLI(CLI):
 (role.name, 
role.install_info['version'], role.version or "unspecified"))
 continue
 else:
-display.display('- %s is already installed, skipping.' % 
str(role))
-continue
+if not force:
+display.display('- %s is already installed, skipping.' 
% str(role))
+continue
 
 try:
 installed = role.install()
```

Please let me know if there's anything I can do to help this along.

Cheers,
JD

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (600, 'stable'), (500, 'stable'), (300, 'testing'), (1, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 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)

Versions of packages ansible depends on:
ii  python2.7.13-2
ii  python-crypto 2.6.1-7
ii  python-httplib2   0.9.2+dfsg-1
ii  python-jinja2 2.8-1
ii  python-netaddr0.7.18-2
ii  python-paramiko   2.0.0-1
ii  python-pkg-resources  33.1.1-1
ii  python-yaml   3.12-1

Versions of packages ansible recommends:
ii  python-cryptography  1.7.1-3
ii  python-jmespath  0.9.3-1
ii  python-kerberos  1.1.5-2+b2
ii  python-libcloud  1.5.0-1
ii  python-selinux   2.6-3+b1
pn  python-winrm 
ii  python-xmltodict 0.10.2-1

Versions of packages ansible suggests:
pn  cowsay   
pn  sshpass  

-- no debconf information

Bug#874078: lintian: improve binary-file-built-without-LFS-support info field

[Boud Roukema]

At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871956
Guillem Rover proposes to revert this patch (for bug #874078) and make a better
one.

Just to summarise again the point that to me still seems valid after
Guillem's clarification on p(write|read)(|64): to me it's confusing to
have text that sounds like AC_SYS_LARGEFILE will "ensure" that
_FILE_OFFSET_BITS is set to 64, when at least on amd64, it
does not ensure this.

Proposal: first recommend using AC_SYS_LARGEFILE, and then propose hardwiring
_FILE_OFFSET_BITS to 64 as a fallback or as an alternative for packages
that don't use autotools.

I propose something like:

 To support large files, code review might be needed to make sure that
 those files are not slurped into memory or mmap(2)ed, and that
 correct 64-bit compatible data types are used (ex: off_t instead of
 ssize_t), etc.  Once that has been done, use the
 AC_SYS_LARGEFILE macro with autoconf, or append the output
 of getconf LFS_CFLAGS and getconf LFS_LDFLAGS to
 CFLAGS and LDFLAGS respectively, or hardwire
 _FILE_OFFSET_BITS to be defined and set to 64 before the
 relevant files are included.

But someone (Guillem?) who knows more than me could propose a better wording...

I've attached this as a patch, in case people are happy with this text without
further changes.--- checks/binaries.desc.old2	2017-09-02 21:57:08.929153000 +0200
+++ checks/binaries.desc	2017-09-04 00:16:58.039294000 +0200
@@ -437,17 +437,14 @@
  files or files with large metadata values (ex: inode numbers) correctly.
  .
  To support large files, code review might be needed to make sure that
- those files are not slurped into memory or mmap(2)ed, and that correct
- 64-bit data types are used (ex: off_t instead of ssize_t), etc.  Once
- that has been done ensure, if needed, that _FILE_OFFSET_BITS
- is defined and
- set to 64 before the relevant files are included. This can be done
- conditionally by
- using the AC_SYS_LARGEFILE macro with autoconf, or by appending
- the output of getconf LFS_CFLAGS and getconf LFS_LDFLAGS
- to CFLAGS and LDFLAGS respectively. Functions such
- as pwrite and pread should be replaced by pwrite64 and pread64 in
- cases where _FILE_OFFSET_BITS is defined and set to 64.
+ those files are not slurped into memory or mmap(2)ed, and that
+ correct 64-bit compatible data types are used (ex: off_t instead of
+ ssize_t), etc.  Once that has been done, use the
+ AC_SYS_LARGEFILE macro with autoconf, or append the output
+ of getconf LFS_CFLAGS and getconf LFS_LDFLAGS to
+ CFLAGS and LDFLAGS respectively, or hardwire
+ _FILE_OFFSET_BITS to be defined and set to 64 before the
+ relevant files are included.
  .
  Take into account that even if this tag is not emitted, that does not
  mean the binary is LFS-safe (ie. no OOM conditions, file truncation

Bug#874160: src:glibc: default locale to C.UTF-8

[Aurelien Jarno]

On 2017-09-04 00:13, Adam Borowski wrote:
> On Sun, Sep 03, 2017 at 11:54:03PM +0200, Aurelien Jarno wrote:
> > On 2017-09-03 18:49, Adam Borowski wrote:
> > > Package: src:glibc
> > > Version: 2.24-17
> > > Severity: wishlist
> > > Tags: patch
> > > 
> > > Hi!
> > > Here's a simple patch set to change the default of setlocale(…, "") to
> > > C.UTF-8.  This is a drastically smaller change than altering the meaning 
> > > of
> > > "C" to mean "C.UTF-8" that upstream is mulling over -- it affects only
> > > programs that already have locale support, when the user fails to set any.
> > 
> > Even is the change is small, that might still change the behavior of
> > some programs, so I am not sure we want to diverge from upstream and
> > other distributions here.
> > 
> > One example comes to my mind: initializing a postgresql database
> > cluster. When not using the --locale option this would cause the
> > database to use a non C locale, which has significant performance
> > impact.
> 
> In this case, this will change anyway when (if?) upstream goes forward with
> their version -- which sounds as if postgresql wants an explicit LC_ALL=C.
> Doesn't pg_createcluster inherit locale settings from the user who's
> invoking it (thus usually en_US.UTF-8 or whatever)?  Thus, in the vast

Or the root account when install postgresql using apt-get.

> majority of uses, there's no change, merely a certain way to force the C
> locate (unset LC_ALL LANG LC_CTYPE LC_...) won't work anymore.

That's correct. My point there is that the usual unset command will work
on all distributions except Debian.

Also that's just an example of a behavior change, I am sure there are
many more.

> As for diverging from upstream, lemme ask the guy behind the upstream
> proposal wiki page what's the inclusion status.  You probably have a wee bit
> better idea than me about upstream's workings, though.

As I said in my first, it's about diverging from upstream *and* from
other distributions. If a few other distributions use your patch as the
default, I am fine with that.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#871956: lintian: false positive: binary-file-built-without-LFS-support on x32

[Guillem Jover]

On Fri, 2017-09-01 at 15:02:03 +0100, Chris Lamb wrote:
> > I'd suggest just marking what we have an idea about.  It's not
> > like lintian warnings matter for something that's not in the archive...
> 
> That's true.
> 
> (Implementation braindump for anyone interested in jumping in: we
> could simply blacklist x32 directly in checks/binaries.pm, but we
> have data/common/architectures so we might need to add a field there
> and update Lintian::Architecture. The testsuite will need some
> cleverness so that we don't fail under x32.)

I think this information is somewhat already provided by the dpkg
arch tables. Any architecture with a 64-bit CPU and with a 32-bit
ABI, as defined by the cputable and abitable files.

So this would include x32, arm64ilp32 and the mipsn32* arches.

AFAIR the OpenBSD port on 32-bit CPUs would be affected too as they
did a scorched-earth migration to 64-bit types ignoring any backwards
binary compatibility. But then I guess we can just ignore that one. :)

Thanks,
Guillem

Bug#874193: xml-security-c: Does not build with C++11 enabled, required for Xerces 3.2.0

[Roger Leigh]

Package: xml-security-c
Version: 1.7.3-4
Tags: patch

Please see the patches I attached to the upstream ticket here: 
https://issues.apache.org/jira/browse/SANTUARIO-471 which resolve a 
number of defects in the source which prevent it building.


They are safe to apply even when C++11 is not in use.


Regards,
Roger

Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Samuel Thibault]

Lisandro Damián Nicanor Pérez Meyer, on dim. 03 sept. 2017 19:08:38 -0300, 
wrote:
> So you mean that something changed between 5.7 and 5.9?

It seems so.

Samuel

Bug#874160: src:glibc: default locale to C.UTF-8

[Adam Borowski]

On Sun, Sep 03, 2017 at 11:54:03PM +0200, Aurelien Jarno wrote:
> On 2017-09-03 18:49, Adam Borowski wrote:
> > Package: src:glibc
> > Version: 2.24-17
> > Severity: wishlist
> > Tags: patch
> > 
> > Hi!
> > Here's a simple patch set to change the default of setlocale(…, "") to
> > C.UTF-8.  This is a drastically smaller change than altering the meaning of
> > "C" to mean "C.UTF-8" that upstream is mulling over -- it affects only
> > programs that already have locale support, when the user fails to set any.
> 
> Even is the change is small, that might still change the behavior of
> some programs, so I am not sure we want to diverge from upstream and
> other distributions here.
> 
> One example comes to my mind: initializing a postgresql database
> cluster. When not using the --locale option this would cause the
> database to use a non C locale, which has significant performance
> impact.

In this case, this will change anyway when (if?) upstream goes forward with
their version -- which sounds as if postgresql wants an explicit LC_ALL=C.
Doesn't pg_createcluster inherit locale settings from the user who's
invoking it (thus usually en_US.UTF-8 or whatever)?  Thus, in the vast
majority of uses, there's no change, merely a certain way to force the C
locate (unset LC_ALL LANG LC_CTYPE LC_...) won't work anymore.

As for diverging from upstream, lemme ask the guy behind the upstream
proposal wiki page what's the inclusion status.  You probably have a wee bit
better idea than me about upstream's workings, though.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#874186: svgpp: fix FTBFS on 32bit

[Adrian Bunk]

On Sun, Sep 03, 2017 at 11:59:01PM +0200, Anton Gladky wrote:
>...
> This library is really a header-only library and needs to be marked
> as "all". I still want to test it on different archs to be sure that it
> works on them. If there are a better solution for that, I would be
> glad to use it.

autopkgtest?

Debian has currently 2 architectures running autopkgtest and
Ubuntu has already more.

> Best regards
> 
> Anton

cu
Adrian

-- 

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

Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Lisandro Damián Nicanor Pérez Meyer]

El 3 sep. 2017 4:39 p.m., "Samuel Thibault"  escribió:

Samuel Thibault, on dim. 03 sept. 2017 21:17:12 +0200, wrote:
> I have checked with a vanilla reinstall of Debian 9, using the Mate
> desktop, and Qt 5.7.1.
>
> When QT_LINUX_ACCESSIBILITY_ALWAYS_ON is not set, I don't see Qt
> applications in accerciser, only the Mate applications. If I set
> QT_LINUX_ACCESSIBILITY_ALWAYS_ON, I do see them.
>
> On my current desktop, I have Qt 5.9.1, I made quick tests, it seems
> it behaves as I expect, so perhaps we can indeed avoid setting
> QT_LINUX_ACCESSIBILITY_ALWAYS_ON now. I'll retest with a vanilla
> reinstall of debian testing, to be sure.

Yes, a vanilla reinstall behaves as expected.  So we can drop that
variable, good :)

Samuel


So you mean that something changed between 5.7 and 5.9? In that case I
should try to track the necessary changes and try to backport them.

Thank you all for jumping in!

Bug#871112: Pending fixes for bugs in the surefire package

[pkg-java-maintainers]

tag 871112 + pending
thanks

Some bugs in the surefire package are closed in revision
d5a13a9afc56e91711bca95b747e1f153e6c6d99 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/surefire.git/commit/?id=d5a13a9

Commit message:

Fixed the build failure caused by the Doxia upgrade (Closes: #871112)

Bug#874192: ragel: please include generated PDF documentation

[Rinat]

Package: ragel
Version: 6.9-1.1+b1
Severity: wishlist

Hi.

As far as I understand, documentation is compiled into a PDF file
(/doc/ragel-guide.pdf), but not included in the package. That PDF
file contains an extensive description of Ragel. It would be great
to have it installable. Please package that file too, if possible.

--
Rinat

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

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

Versions of packages ragel depends on:
ii  libc6   2.24-14
ii  libgcc1 1:7.2.0-1
ii  libstdc++6  7.2.0-1

ragel recommends no packages.

ragel suggests no packages.

-- debconf-show failed

Bug#874191: gdm3 started users start in wrong context

[Harlan Lieberman-Berg]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Severity: serious

Hello maintainers,

It seems that shells started via Gnome start with the wrong context.
Logging in from a console shell gives me an id of
unconfined_u:unconfined_r:unconfined_t:s0-s0, whereas terminals opened
inside Gnome give me a context of system_u:system_r:initrc_t:s0.

Sincerely,

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

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

Versions of packages selinux-policy-default depends on:
ii  libselinux1  2.6-3+b2
ii  libsemanage1 2.6-2+b1
ii  libsepol12.6-2
ii  policycoreutils  2.6-3
ii  selinux-utils2.6-3+b2

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.6-2
ii  setools  4.0.1-6+b1

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- no debconf information

Bug#871956: lintian: false positive: binary-file-built-without-LFS-support on x32

[Boud Roukema]

hi Guillem, all,

On Sun, 3 Sep 2017, Guillem Jover wrote:


When you define _FILE_OFFSET_BITS=64 the interfaces are transparently
mapped to the 64-bit variants and no other code change is required. So
you *must* not be switching from foo to foo64 in the call sites. This
is IMO the preferred way to enable LFS.


Do you mean that the preferred way is to always hardwire _FILE_OFFSET_BITS to
64? Or is using AC_SYS_LARGEFILE, which seems to me to *not* set this on amd64,
also a long-term sustainable solution? (To me it seems that if some systems
do not need to define it to 64, and if AC_SYS_LARGEFILE handles this correctly,
then it's best to allow AC_SYS_LARGEFILE to do this.)


Nope, that looks wrong. The __USE_* macros are internal implementation
details, and applications should not be using those. In addition you
should just be using pread() and pwrite(), which will call the correct
interfaces.


OK, thanks for the correction.

[So presumably this means that the only bug in mpgrafic-0.3.15-1 in terms of LFS
is the failure to #include config.h.]


That patch needs to be reverted. I can provide a new patch explaining
in more detail this though and giving more pointers perhaps.


Please go ahead - the documentation bug is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874078

Cheers
Boud

Bug#873791: [python-numpy] Undefined symbols on several architectures

[Adrian Bunk]

Control: reopen -1

On Thu, Aug 31, 2017 at 12:48:53PM +0200, Matthias Klose wrote:
> On 31.08.2017 12:35, Adrian Bunk wrote:
> > Control: reassign -1 python2.7 2.7.14~rc1-1
> > Control: retitle -1 python2.7: fpectl extension removal broke the ABI for C 
> > extensions
> > Control: affects -1 python-numpy
> > 
> > On Thu, Aug 31, 2017 at 11:34:55AM +0200, Michał Klichowicz wrote:
> >> Got that error on amd64, too.
> >>
> >> This started today, after the upgrading python2.7 packages to 2.7.14~rc1
> >> in sid. Downgrading back to buster's 2.7.13-2 solves the problem.
> > 
> > I got the same error with Cython:
> > 
> > ImportError: 
> > /usr/lib/python2.7/dist-packages/Cython/Compiler/Code.x86_64-linux-gnu.so: 
> > undefined symbol: PyFPE_jbuf.  You should look at http://www.cython.org; 
> > 
> > It seems the following change in 2.7.14~rc1-1 broke the ABI:
> >   * Stop building the fpectl extension.
> 
> yes, that's intended. I'll add a break.  Are there other known packages 
> besides
> python-numpy?

A complete list of all packages in unstable on amd64 that need rebuild
and Breaks is attached.

Additionally, Breaks are required for the following packages
that were already fixed in sid:
- cython
- cython3
- python-lxml
- python3-lxml

To avoid breaking testing, please keep these bugs open and RC until
all Breaks are in place.

cu
Adrian

-- 

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

PyFPE ./pool/main/a/adios/python-adios_1.12.0-3_amd64.deb
PyFPE ./pool/main/a/adios/python3-adios_1.12.0-3_amd64.deb
PyFPE ./pool/main/a/astroml-addons/python-astroml-addons_0.2.2-4_amd64.deb
PyFPE ./pool/main/a/astroml-addons/python3-astroml-addons_0.2.2-4_amd64.deb
PyFPE ./pool/main/a/astroscrappy/python-astroscrappy_1.0.5-1+b1_amd64.deb
PyFPE ./pool/main/a/astroscrappy/python3-astroscrappy_1.0.5-1+b1_amd64.deb
PyFPE ./pool/main/a/asyncpg/python3-asyncpg_0.12.0-1_amd64.deb
PyFPE ./pool/main/b/bcolz/python-bcolz_1.1.0+ds1-4+b1_amd64.deb
PyFPE ./pool/main/b/bcolz/python3-bcolz_1.1.0+ds1-4+b1_amd64.deb
PyFPE ./pool/main/b/borgbackup/borgbackup_1.0.11-3_amd64.deb
PyFPE ./pool/main/b/breezy/python-breezy_3.0.0~bzr6772-1_amd64.deb
PyFPE ./pool/main/b/bzr/python-bzrlib_2.7.0+bzr6622-7_amd64.deb
PyFPE ./pool/main/c/cypari2/python-cypari2_1.0.0-3_amd64.deb
PyFPE ./pool/main/d/dipy/python-dipy-lib_0.12.0-1_amd64.deb
PyFPE ./pool/main/e/epigrass/epigrass_2.4.7-1_amd64.deb
PyFPE ./pool/main/f/fiona/python-fiona_1.7.9-1_amd64.deb
PyFPE ./pool/main/f/fiona/python3-fiona_1.7.9-1_amd64.deb
PyFPE ./pool/main/f/fpylll/python-fpylll_0.2.4+ds-3_amd64.deb
PyFPE ./pool/main/h/h5py/python-h5py_2.7.0-1+b1_amd64.deb
PyFPE ./pool/main/h/h5py/python3-h5py_2.7.0-1+b1_amd64.deb
PyFPE ./pool/main/h/healpy/python-healpy_1.10.3-2+b1_amd64.deb
PyFPE ./pool/main/h/healpy/python3-healpy_1.10.3-2+b1_amd64.deb
PyFPE ./pool/main/h/htseq/python-htseq_0.6.1p1-4_amd64.deb
PyFPE ./pool/main/i/invesalius/invesalius-bin_3.1.1-1_amd64.deb
PyFPE ./pool/main/k/kivy/python-kivy_1.9.1-1+b1_amd64.deb
PyFPE ./pool/main/k/kivy/python3-kivy_1.9.1-1+b1_amd64.deb
PyFPE ./pool/main/libg/libgpuarray/python-pygpu_0.6.9-2_amd64.deb
PyFPE ./pool/main/libg/libgpuarray/python3-pygpu_0.6.9-2_amd64.deb
PyFPE 
./pool/main/libi/libimobiledevice/python-imobiledevice_1.2.0+dfsg-3.1_amd64.deb
PyFPE ./pool/main/m/macs/macs_2.1.1.20160309-1_amd64.deb
PyFPE ./pool/main/m/meliae/python-meliae_0.4.0+bzr199-3_amd64.deb
PyFPE ./pool/main/n/netcdf4-python/python-netcdf4_1.2.9-1+b1_amd64.deb
PyFPE ./pool/main/n/netcdf4-python/python3-netcdf4_1.2.9-1+b1_amd64.deb
PyFPE ./pool/main/n/nipy/python-nipy-lib_0.4.1-1_amd64.deb
PyFPE ./pool/main/p/pandas/python-pandas-lib_0.20.3-1_amd64.deb
PyFPE ./pool/main/p/pandas/python3-pandas-lib_0.20.3-1_amd64.deb
PyFPE ./pool/main/p/petsc4py/python-petsc4py_3.7.0-3+b1_amd64.deb
PyFPE ./pool/main/p/petsc4py/python3-petsc4py_3.7.0-3+b1_amd64.deb
PyFPE ./pool/main/p/printrun/printrun_0~20150310-5_amd64.deb
PyFPE 
./pool/main/p/pybloomfiltermmap/python-pybloomfiltermmap_0.3.15-0.1+b1_amd64.deb
PyFPE ./pool/main/p/pycorrfit/pycorrfit_1.0.0+dfsg-1_amd64.deb
PyFPE ./pool/main/p/pyfai/python-pyfai_0.13.0+dfsg-1+b1_amd64.deb
PyFPE ./pool/main/p/pyfai/python3-pyfai_0.13.0+dfsg-1+b1_amd64.deb
PyFPE ./pool/main/p/pygame-sdl2/python-pygame-sdl2_6.99.12.4-1_amd64.deb
PyFPE ./pool/main/p/pygrib/python-grib_2.0.2-2_amd64.deb
PyFPE ./pool/main/p/pygrib/python3-grib_2.0.2-2_amd64.deb
PyFPE ./pool/main/p/pyliblo/python-liblo_0.10.0-3+b1_amd64.deb
PyFPE ./pool/main/p/pyliblo/python3-liblo_0.10.0-3+b1_amd64.deb
PyFPE ./pool/main/p/pymca/python-pymca5_5.1.3+dfsg-1+b1_amd64.deb
PyFPE ./pool/main/p/pymca/python3-pymca5_5.1.3+dfsg-1+b1_amd64.deb
PyFPE ./pool/main/p/pymssql/python-pymssql_2.1.3+dfsg-1+b1_amd64.deb
PyFPE ./pool/main/p/pymssql/python3-pymssql_2.1.3+dfsg-1+b1_amd64.deb
PyFPE 

Bug#874186: svgpp: fix FTBFS on 32bit

[Anton Gladky]

Hi Adrian,

thanks for the patch! I will apply it as fast as possible and do
a new upoad.

This library is really a header-only library and needs to be marked
as "all". I still want to test it on different archs to be sure that it
works on them. If there are a better solution for that, I would be
glad to use it.

Best regards

Anton


2017-09-03 23:31 GMT+02:00 Adrian Bunk :
> Source: svgpp
> Version: 1.2.3+dfsg1-2
> Severity: important
> Tags: patch
>
> https://buildd.debian.org/status/package.php?p=svgpp=sid
>
> ...
> cc1plus: out of memory allocating 11518920 bytes after a total of 37756928 
> bytes
> samples/CMakeFiles/Sample01e.dir/build.make:65: recipe for target 
> 'samples/CMakeFiles/Sample01e.dir/sample01e.cpp.o' failed
> make[4]: *** [samples/CMakeFiles/Sample01e.dir/sample01e.cpp.o] Error 1
>
> Fix by reducing the amount of debug information built
> (still enough for backtraces):
>
> --- debian/rules.old2017-09-03 13:45:27.791242648 +
> +++ debian/rules2017-09-03 15:39:02.587525204 +
> @@ -1,5 +1,12 @@
>  #!/usr/bin/make -f
>
> +# Reduce size of debug symbols to fix FTBFS due to the
> +# 2GB/3GB address space limits on 32bit
> +DEB_HOST_ARCH_BITS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_BITS)
> +ifeq (32,$(DEB_HOST_ARCH_BITS))
> +   export DEB_CXXFLAGS_MAINT_APPEND = -g1
> +endif
> +
>  export DEB_BUILD_MAINT_OPTIONS = hardening=+all
>
>  %:
>
>
>
> In a related question, is it intentional that none of the built
> files goes to the package?
>
> Currently libsvgpp-dev has the same contents on different
> architectures (I've compared amd64 and i386) and could as
> well be binary-all.

Bug#874190: cinnamon-desktop-environment: Drop gnome-user-share recommends

[Jeremy Bicha]

Package: cinnamon-desktop-environment
Version: 3.4

Please consider dropping cinnamon-desktop-environment's recommends on
gnome-user-share.

Since version 3.18, gnome-user-share's only feature is WebDAV sharing
which requires Apache being installed to work. gnome-user-share
doesn't provide any GUI to configure this except for what's built into
gnome-control-center.

Thanks,
Jeremy Bicha

Bug#874163: [libreoffice-kde] not installable

[Rene Engelhard]

tag 874163 + sid
thanks

Hi,

On Sun, Sep 03, 2017 at 10:45:52PM +0200, Rene Engelhard wrote:
> > --- Please enter the report below this line. ---
> > # LANG=C apt install libreoffice-kde
> > 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:
> >  libreoffice-kde : Depends: libreoffice-core (= 1:5.4.0-1) but it is not
> > going to be installed
> > E: Unable to correct problems, you have held broken packages.
> 
> Of course, because it tries to install testings libreoffice-kde
> on sid where the = dependency of course won't fit anymore ..

And it doesn't apply in pure testing (right now) either since there there
_is_ a matching 1:5.4.0-1 of libreoffice-core (together with libreoffice-kde
still existing there)

Sorry, but libreoffice-kde is dead until it gets ported to KF5. Which upstream
is working on, but no idea when it will be finished (or whether it actually
will be such early that one can enable it for buster - it needs big testing
first to avoid the bad experience with gtk3.)

Regards,
 
Rene

Bug#874160: src:glibc: default locale to C.UTF-8

[Aurelien Jarno]

On 2017-09-03 18:49, Adam Borowski wrote:
> Package: src:glibc
> Version: 2.24-17
> Severity: wishlist
> Tags: patch
> 
> Hi!
> Here's a simple patch set to change the default of setlocale(…, "") to
> C.UTF-8.  This is a drastically smaller change than altering the meaning of
> "C" to mean "C.UTF-8" that upstream is mulling over -- it affects only
> programs that already have locale support, when the user fails to set any.

Even is the change is small, that might still change the behavior of
some programs, so I am not sure we want to diverge from upstream and
other distributions here.

One example comes to my mind: initializing a postgresql database
cluster. When not using the --locale option this would cause the
database to use a non C locale, which has significant performance
impact.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#871956: lintian: false positive: binary-file-built-without-LFS-support on x32

[Adam Borowski]

On Sun, Sep 03, 2017 at 11:38:28PM +0200, Guillem Jover wrote:
> On Fri, 2017-09-01 at 21:35:07 +0200, Adam Borowski wrote:
> > The problem is in snowflake packages that do things their own way and enable
> > LFS only when it's actually needed.  Here's where the lintian false positive
> > triggers.
> 
> This is a common misconception. Pretty much all programs need to
> be LFS enabled, because even if these programs do not handle large
> files they will probably still fail when encountering files in the
> filsystem with large inode numbers (or other large metadata) for
> example.

By "if needed", I meant "on archs where off_t != off64_t".  There's neither
any benefit nor any harm in enabling LFS on amd64 or x32, no matter if a
program uses anything LFSey or not.  I agree with you that there's no good
reason with skipping LFS on i386.

This bug log includes some confusion with an unrelated problem with mpgrafic
on i386; my original report is about too smart packages that don't switch to
*64 variants if sizeof(off_t) is already 8 -- this triggers a lintian
warning on x32 (and, unconfirmed, on arm64ilp32).


Not sure if you'd want to clone this bug for the other problem (true
positive in mpgrafic and not helpful enough lintian message).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#874189: Patch for Xerces 3.2.0

[Roger Leigh]

Package: xqilla
Version: 2.3.3-2
Tags: patch

Xerces-C 3.2.0 removed castToNode (which relied on undefined behaviour) 
with a cleaner way of getting information about a node's containing 
node: a new fContainingNode member.


The attached patchs have conditionals for the 3.2.0 and earlier 
behaviour, so should be safe to apply without any breakage.
Tested on FreeBSD 11.1 and 10.3 for the xqilla port, and Debian unstable 
for the Debian package.


See also: https://sourceforge.net/p/xqilla/bugs/48/


Regards,
Roger
diff -urN XQilla-2.3.3.orig/src/dom-api/impl/XPathDocumentImpl.cpp XQilla-2.3.3/src/dom-api/impl/XPathDocumentImpl.cpp
--- XQilla-2.3.3.orig/src/dom-api/impl/XPathDocumentImpl.cpp	2015-05-18 18:38:59.0 +0100
+++ XQilla-2.3.3/src/dom-api/impl/XPathDocumentImpl.cpp	2017-09-03 22:15:41.999739206 +0100
@@ -62,7 +62,11 @@
 if (thisNodeImpl->isReadOnly())
 throw DOMException(DOMException::NO_MODIFICATION_ALLOWED_ERR, 0, getMemoryManager());
 
+#if _XERCES_VERSION >= 30200
+DOMNode* thisNode = fParent.fContainingNode;
+#else
 DOMNode* thisNode = castToNode();
+#endif
 if (newChild->getOwnerDocument() != thisNode)
 throw DOMException(DOMException::WRONG_DOCUMENT_ERR, 0, getMemoryManager());
 
diff -urN XQilla-2.3.3.orig/src/dom-api/impl/XPathNamespaceImpl.cpp XQilla-2.3.3/src/dom-api/impl/XPathNamespaceImpl.cpp
--- XQilla-2.3.3.orig/src/dom-api/impl/XPathNamespaceImpl.cpp	2015-05-18 18:39:00.0 +0100
+++ XQilla-2.3.3/src/dom-api/impl/XPathNamespaceImpl.cpp	2017-09-03 22:15:46.031991028 +0100
@@ -33,7 +33,11 @@
 
 XPathNamespaceImpl::XPathNamespaceImpl(const XMLCh* const nsPrefix, 
 		const XMLCh* const nsUri, DOMElement *owner, DOMDocument *docOwner) 
+#if _XERCES_VERSION >= 30200 
+	: fNode(this, docOwner)
+#else
 	: fNode(docOwner)
+#endif
 {
 DOMNodeImpl *argImpl = castToNodeImpl(this);
 
@@ -54,7 +58,13 @@
 }
 
 XPathNamespaceImpl::XPathNamespaceImpl(const XPathNamespaceImpl ) 
-	: fNode(other.fNode), uri(other.uri), prefix(other.prefix)
+#if _XERCES_VERSION >= 30200 
+	: fNode(this, other.fNode),
+#else
+	: fNode(other.fNode), 
+
+#endif
+	  uri(other.uri), prefix(other.prefix)
 {
 }
 
@@ -196,7 +206,11 @@
 
 //if it is a custom node and bigger than us we must ask it for the order
 if(otherType > DOMXPathNamespace::XPATH_NAMESPACE_NODE) {
+#if _XERCES_VERSION >= 30200 
+DOMNodeImpl tmp(const_cast(this), 0);
+#else
 DOMNodeImpl tmp(0);
+#endif
 #if _XERCES_VERSION >= 3
 return tmp.reverseTreeOrderBitPattern(other->compareDocumentPosition(this));
 #else

Bug#874188: fai-client: Integrate some form of file templating system

[Noah Meyerhans]

Package: fai-client
Severity: wishlist

In our use of FAI for generating the stretch cloud images, we use fcopy's
preinst scripts to implement a crude form of templating. See
https://anonscm.debian.org/cgit/cloud/fai-cloud-images.git/tree/files/etc/apt/sources.list
for the files and script.

In order to avoid having to re-implement the templating system everywhere
and encourage reduced repetition throughout the config tree, it would be
really helpful to have some kind of file templating system integrated into
FAI, possibly in the fcopy program directly.

Thanks
noah

Bug#874169: AppStreamQtConfig.cmake no longer usable in i386

[Maximiliano Curia]

¡Hola Matthias!

El 2017-09-03 a las 21:45 +0200, Matthias Klumpp escribió:

2017-09-03 21:15 GMT+02:00 Maximiliano Curia :

[...]
# check that the installed version has the same 32/64bit-ness as the one 
which is currently searching:
if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8") 
  math(EXPR installedBits "8 * 8") 
  set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)") 
  set(PACKAGE_VERSION_UNSUITABLE TRUE) 
endif()


This last part `NOT CMAKE_SIZEOF_VOID_P STREQUAL "8"', seems to indicate 
that it would never work on a 32 bit system. Is the "8" here meant to be 
replaced at build time?


Can you try removing that entire section and see if that fixes it? 
It serves no real purpose in how AppStreamQt is used anyway.


Commenting out that block allowed frameworkintegration to build.

Happy hacking,
--
"Any change looks terrible at first." -- Principle of Design Inertia
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#860797: please make packages with epochs bump go in new queue

[Michael Biebl]

On Thu, 20 Apr 2017 08:56:54 + (UTC) Gianfranco Costamagna
 wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> It started as a joke on #-devel, but it would be nice to have packages with 
> epoch bumped
> go in new queue, in the past we had a lot of such wrong bump done by DM, or DD
> not understanding correctly what they were doing.
> 
> Is it possible to make them go in a new queue so you can double check if the 
> bump
> is really needed?
> 
> thanks,
> 
> Gianfranco


Seconded, especially in light of uploads as
https://tracker.debian.org/news/764830

-- 
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#874186: svgpp: fix FTBFS on 32bit

[Adrian Bunk]

Source: svgpp
Version: 1.2.3+dfsg1-2
Severity: important
Tags: patch

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

...
cc1plus: out of memory allocating 11518920 bytes after a total of 37756928 bytes
samples/CMakeFiles/Sample01e.dir/build.make:65: recipe for target 
'samples/CMakeFiles/Sample01e.dir/sample01e.cpp.o' failed
make[4]: *** [samples/CMakeFiles/Sample01e.dir/sample01e.cpp.o] Error 1

Fix by reducing the amount of debug information built
(still enough for backtraces):

--- debian/rules.old2017-09-03 13:45:27.791242648 +
+++ debian/rules2017-09-03 15:39:02.587525204 +
@@ -1,5 +1,12 @@
 #!/usr/bin/make -f
 
+# Reduce size of debug symbols to fix FTBFS due to the
+# 2GB/3GB address space limits on 32bit
+DEB_HOST_ARCH_BITS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_BITS)
+ifeq (32,$(DEB_HOST_ARCH_BITS))
+   export DEB_CXXFLAGS_MAINT_APPEND = -g1
+endif
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:



In a related question, is it intentional that none of the built
files goes to the package?

Currently libsvgpp-dev has the same contents on different
architectures (I've compared amd64 and i386) and could as
well be binary-all.

Bug#605063: Pending fixes for bugs in the batik package

[pkg-java-maintainers]

tag 605063 + pending
thanks

Some bugs in the batik package are closed in revision
30a01c4c12f641c179ac98d15ce863d26de81978 in branch 'master' by
Christopher Hoskin

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/batik.git/commit/?id=30a01c4

Commit message:

Fix "batik is crashing (libbatik-java)" by patching build.xml to specify 
classpaths as appropriate for Debian (Closes: #605063)

Bug#871956: lintian: false positive: binary-file-built-without-LFS-support on x32

[Guillem Jover]

On Fri, 2017-09-01 at 21:35:07 +0200, Adam Borowski wrote:
> And what AC_SYS_LARGEFILE does, at least on Linux, is to return a hardcoded
> setting so programs switch from off_t to off64_t whether they need to or
> not.  This does the right thing on old 32-bit archs and is harmless on
> 64-bit and new 32-bit.

Just to make this extra clear, when setting _FILE_OFFSET_BITS=64,
the types and functions are transparently redirected to the 64-bit
variants if need be, so nothing needs to be changed in the code.

> The problem is in snowflake packages that do things their own way and enable
> LFS only when it's actually needed.  Here's where the lintian false positive
> triggers.

This is a common misconception. Pretty much all programs need to
be LFS enabled, because even if these programs do not handle large
files they will probably still fail when encountering files in the
filsystem with large inode numbers (or other large metadata) for
example.

Thanks,
Guillem

Bug#832159: ITP: qutebrowser -- A keyboard-driven, vim-like browser based on PyQt5.

[Axel Beckert]

Hi Fritz,

Fritz Reichwald wrote:
> At the moment I'm waiting for someone to sponsor the package.

Still on my todo list, yes.

> the status of packaging can be found here:
> https://github.com/fiete201/qutebrowser-debian

Hrm, is it on purpose that this git repo only contains the debian
directory? Doing so was common back in the Subversion days, but
nowadays, I'd expect the unpacked upstream tar ball in there, too.
Anyway, that's no blocker, just unexpected.

I nevertheless just had a look at this git repo and it seems to miss
one file which were in your earlier packages (0.9.0-1 and 0.10.1-2).
Namely the debian/source/ directory with its sole file
debian/source/format is missing. Lintian also argues about it:

  I: qutebrowser source: missing-debian-source-format

Please re-add that directory.

Additionally please take a look at

  I: qutebrowser source: missing-debian-source-format

Upstream now provides GPG signatures so we should verify them.

Further, it's no more necessary to list the full text of the MPL
1.1 since Debian Policy 4.0.0 as the license text of the MPL 1.1 is
now available under /usr/share/common-licenses/MPL-1.1. Please just
refer to that file. (Yes, I know, I very likely argued about adding
MPL-1.1 to debian/copyright in an earlier review — but the inclusion
of the MPL happened only very recently. :-)

Not immediately necessary, but should happen sooner or later: Debian
Policy 4.1.0 is out. It also explicitly recommends adding support for
verifying upstream PGP signatures.

And JFTR: I just uploaded the pypeg2 package (c.f.
https://bugs.debian.org/832937) so soon all runtime dependencies of
qutebrowser should be available in Debian unstable.

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


signature.asc
Description: Digital signature

Bug#874187: qtermwidget FTBFS with Qt 5.9: symbol differences

[Adrian Bunk]

Source: qtermwidget
Version: 0.7.1-4
Severity: serious

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

...
   dh_makeshlibs -O--buildsystem=cmake -O--fail-missing
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libqtermwidget5-0/DEBIAN/symbols doesn't match 
completely debian/libqtermwidget5-0.symbols
--- debian/libqtermwidget5-0.symbols (libqtermwidget5-0_0.7.1-4_amd64)
+++ dpkg-gensymbolsY7a7UW   2018-10-06 15:07:51.983955567 -1200
@@ -115,18 +115,18 @@
  (c++)"Konsole::AutoScrollHandler::~AutoScrollHandler()@Base" 0.6.0
  (c++)"Konsole::BlockArray::BlockArray()@Base" 0.6.0
  (c++)"Konsole::BlockArray::append(Konsole::Block*)@Base" 0.6.0
- (optional|c++)"Konsole::BlockArray::at(unsigned int)@Base" 0.6.0
+#MISSING: 0.7.1-4# (optional|c++)"Konsole::BlockArray::at(unsigned int)@Base" 
0.6.0
  (optional|c++)"Konsole::BlockArray::at(unsigned long)@Base" 0.6.0
- (optional|c++)"Konsole::BlockArray::decreaseBuffer(unsigned int)@Base" 0.6.0
+#MISSING: 0.7.1-4# (optional|c++)"Konsole::BlockArray::decreaseBuffer(unsigned 
int)@Base" 0.6.0
  (optional|c++)"Konsole::BlockArray::decreaseBuffer(unsigned long)@Base" 0.6.0
- (optional|c++)"Konsole::BlockArray::has(unsigned int) const@Base" 0.6.0
+#MISSING: 0.7.1-4# (optional|c++)"Konsole::BlockArray::has(unsigned int) 
const@Base" 0.6.0
  (optional|c++)"Konsole::BlockArray::has(unsigned long) const@Base" 0.6.0
  (c++)"Konsole::BlockArray::increaseBuffer()@Base" 0.6.0
  (c++)"Konsole::BlockArray::lastBlock() const@Base" 0.6.0
  (c++)"Konsole::BlockArray::newBlock()@Base" 0.6.0
- (optional|c++)"Konsole::BlockArray::setHistorySize(unsigned int)@Base" 0.6.0
+#MISSING: 0.7.1-4# (optional|c++)"Konsole::BlockArray::setHistorySize(unsigned 
int)@Base" 0.6.0
  (optional|c++)"Konsole::BlockArray::setHistorySize(unsigned long)@Base" 0.6.0
- (optional|c++)"Konsole::BlockArray::setSize(unsigned int)@Base" 0.6.0
+#MISSING: 0.7.1-4# (optional|c++)"Konsole::BlockArray::setSize(unsigned 
int)@Base" 0.6.0
  (optional|c++)"Konsole::BlockArray::setSize(unsigned long)@Base" 0.6.0
  (c++)"Konsole::BlockArray::unmap()@Base" 0.6.0
  (c++)"Konsole::BlockArray::~BlockArray()@Base" 0.6.0
@@ -172,7 +172,7 @@
  (c++)"Konsole::ColorSchemeManager::loadCustomColorScheme(QString 
const&)@Base" 0.6.0
  (c++)"Konsole::ColorSchemeManager::loadKDE3ColorScheme(QString const&)@Base" 
0.6.0
  (c++)"Konsole::ColorSchemeManager::~ColorSchemeManager()@Base" 0.6.0
- (optional|c++)"Konsole::CompactHistoryBlock::allocate(unsigned int)@Base" 
0.6.0
+#MISSING: 0.7.1-4# 
(optional|c++)"Konsole::CompactHistoryBlock::allocate(unsigned int)@Base" 0.6.0
  (optional|c++)"Konsole::CompactHistoryBlock::allocate(unsigned long)@Base" 
0.6.0
  (c++)"Konsole::CompactHistoryBlock::contains(void*)@Base" 0.6.0
  (c++)"Konsole::CompactHistoryBlock::deallocate()@Base" 0.6.0
@@ -180,7 +180,7 @@
  (c++)"Konsole::CompactHistoryBlock::length()@Base" 0.6.0
  (c++)"Konsole::CompactHistoryBlock::remaining()@Base" 0.6.0
  (c++)"Konsole::CompactHistoryBlock::~CompactHistoryBlock()@Base" 0.6.0
- (optional|c++)"Konsole::CompactHistoryBlockList::allocate(unsigned int)@Base" 
0.6.0
+#MISSING: 0.7.1-4# 
(optional|c++)"Konsole::CompactHistoryBlockList::allocate(unsigned int)@Base" 
0.6.0
  (optional|c++)"Konsole::CompactHistoryBlockList::allocate(unsigned 
long)@Base" 0.6.0
  (c++)"Konsole::CompactHistoryBlockList::deallocate(void*)@Base" 0.6.0
  (c++)"Konsole::CompactHistoryBlockList::~CompactHistoryBlockList()@Base" 0.6.0
@@ -189,7 +189,7 @@
  (c++)"Konsole::CompactHistoryLine::getCharacters(Konsole::Character*, int, 
int)@Base" 0.6.0
  (c++)"Konsole::CompactHistoryLine::getLength() const@Base" 0.6.0
  (c++)"Konsole::CompactHistoryLine::isWrapped() const@Base" 0.6.0
- (optional|c++)"Konsole::CompactHistoryLine::operator new(unsigned int, 
Konsole::CompactHistoryBlockList&)@Base" 0.6.0
+#MISSING: 0.7.1-4# (optional|c++)"Konsole::CompactHistoryLine::operator 
new(unsigned int, Konsole::CompactHistoryBlockList&)@Base" 0.6.0
  (optional|c++)"Konsole::CompactHistoryLine::operator new(unsigned long, 
Konsole::CompactHistoryBlockList&)@Base" 0.6.0
  (c++)"Konsole::CompactHistoryLine::setWrapped(bool)@Base" 0.6.0
  (c++)"Konsole::CompactHistoryLine::~CompactHistoryLine()@Base" 0.6.0
@@ -318,7 +318,7 @@
  (c++)"Konsole::HistoryScroll::addCellsVector(QVector 
const&)@Base" 0.6.0
  (c++)"Konsole::HistoryScroll::hasScroll()@Base" 0.6.0
  (c++)"Konsole::HistoryScroll::~HistoryScroll()@Base" 0.6.0
- 
(optional|c++)"Konsole::HistoryScrollBlockArray::HistoryScrollBlockArray(unsigned
 int)@Base" 0.6.0
+#MISSING: 0.7.1-4# 
(optional|c++)"Konsole::HistoryScrollBlockArray::HistoryScrollBlockArray(unsigned
 int)@Base" 0.6.0
  
(optional|c++)"Konsole::HistoryScrollBlockArray::HistoryScrollBlockArray(unsigned
 long)@Base" 0.6.0
  

Bug#871956: lintian: false positive: binary-file-built-without-LFS-support on x32

[Guillem Jover]

On Sat, 2017-09-02 at 21:47:15 +0200, Boud Roukema wrote:
> On Sat, 2 Sep 2017, Adam Borowski wrote:
> > > AC_SYS_LARGEFILE on i386 (linux) for mpgrafic-0.3.15-1 apparently does 
> > > *not*
> > > always do the right thing

> > Nope, you use pwrite() not pwrite64() -- on i386 you need the latter to get
> > LFS; they're aliases only on amd64, x32 and so on.

That's not correct, neither the new changes to the description of the
tag.

When you define _FILE_OFFSET_BITS=64 the interfaces are transparently
mapped to the 64-bit variants and no other code change is required. So
you *must* not be switching from foo to foo64 in the call sites. This
is IMO the preferred way to enable LFS.

The other way to enable LFS is to define _LARGEFILE64_SOURCE, which
makes visible the 64-bit variants in parallel to the 32-bit default
interfaces, so you get foo and foo64, and you can call either from the
code. This might be useful in case you are for example writing a
library and need to support entry points for both 32-bit and 64-bit
functions for backwards compatibility. Otherwise I'd strongly
discourage its use.

> OK, so config.h + p(read|write)64 should hopefully solve the mpgrafic
> bug. I initially tried hardwiring pwrite64 and pread64 (compiling on
> amd64), but got "warning: implicit declaration of function ‘pwrite64’
> [-Wimplicit-function-declaration]". My understanding is that
> _FILE_OFFSET_BITS and __USE_FILE_OFFSET64 are *not* set for amd64 by
> AC_SYS_LARGEFILE, and instead only set for some systems, such as i386.
> The following should correctly work together with AC_SYS_LARGEFILE, it
> seems to me.
> 
> Does this look OK?
> 
> #ifndef __USE_FILE_OFFSET64
>   i_stat=pwrite(fd,buffer,size,offset);
> #else
>   i_stat=pwrite64(fd,buffer,size,offset);
> #endif
> 
> #ifndef __USE_FILE_OFFSET64
>   i_stat = pread(fd,buffer,size,offset);
> #else
>   i_stat = pread64(fd,buffer,size,offset);
> #endif

Nope, that looks wrong. The __USE_* macros are internal implementation
details, and applications should not be using those. In addition you
should just be using pread() and pwrite(), which will call the correct
interfaces.

> > But in any case, even if it had been indeed a false positive, it'd be a
> > different bug.
> 
> I think I should post a lintian bug for improving the info field for
> the LFS unsafe detection - I spent quite a bit of time searching for how
> to handle this, and having more detailed information could help other
> debian contributors respond more easily to built-without-LFS-support
> warnings.

That patch needs to be reverted. I can provide a new patch explaining
in more detail this though and giving more pointers perhaps.

Thanks,
Guillem

Bug#605063: batik is crashing (libbatik-java)

[Christopher Hoskin]

Package: libbatik-java
Version: 1.8-4
Followup-For: Bug #605063

Upstream bundles third party jars in the lib/ folder, which are stripped out 
during repacking. As a result they are not included in batik-all.jar. Adding a 
classpath to batik-all.jar specifying where to find these third party jars 
(under /usr/share/java) seems to fix the issue.

Christopher

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Luc Van Oostenryck]

On Fri, Sep 1, 2017 at 9:02 AM, Josh Triplett  wrote:
> On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
>> On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König  Yes
>> that works. So to address the Debian bug I can do:
>> >
>> >  - move sparse to /usr/lib
>> >  - teach cgcc about the move of sparse
>> >  - make /usr/bin/sparse call cgcc -no-compile "$@"
>>
>> I don't like that. It means the user can't invoke sparse directly.
>>
>> >
>> > or is it easier to teach sparse about the architecture stuff?
>>
>> First of all. It is not very trivial to teach sparse about the architecture
>> stuff. To my mind, we need to move all the cgcc logic into sparse.
>
> Related to that: while it would mean we couldn't necessarily just rely
> entirely on GCC's definitions for a target platform, I think in an ideal
> world we could have a sparse binary that understood *all* target
> platforms at once, such that you could ask Sparse on x86_64 to "compile"
> as though targeting any arbitrary architecture. That would also have the
> major advantage of making it easy to run the Sparse testsuite for
> *every* target architecture without needing compilers for every such
> architecture.

I really think that the testsuite should not depend on system or library
header.

Otherwise, I'm not at all opposed to sparse being universal but I would like
to note that things can become very quickly very very messy.
For example, for the current problem here I understood that it was
at least partially based on the lack of a definition of _CALL_ELF
but do we need to define it to 1 or to 2, in other words, do we need
to support the ELFv1 ABI or the ELFv2? GCC has some flags for this
(-mabi=elfv[12]) but what default value do we want? ELFv1 is the default
for big-endian platform and ELFv2 for little-endian platform, so yes,
we need a flag for the endianness but which endianness we want as default?
And so on.

Things become even more fun when taking in account the difference
between GCC version. Do we want to be universal there too (and thus
have some flags for to specify which gcc's version we want to mimick)?
What about other compilers?


I think that part of the needed info can be auto-extracted from GCC
when doing a native build. Using some sort of spec file or a .sparserc
can help too.

I also note that currently, sparse is already largely universal *because*
it *doesn't* need those platform details (or only the very minimal: word size).

-- Luc Van Oostenryck

Bug#874184: [dpkg] Lack of error recovery of dpkg-maint-script

[Bastien ROUCARIÈS]

Package: dpkg
Version: 1.18.24
Severity: important

Hi,

They are some problem regarding pipe in dpkg-maintscript-helper.

I have done some work for one function, and I can continue for other functions 
if needed

cat /nonexistant | sed s/alpha//g 
will return sucess...

I have fixed md5sum will continue if you think it is worthwhilediff --git a/scripts/dpkg-maintscript-helper.sh b/scripts/dpkg-maintscript-helper.sh
index 378d03c15..e1806e253 100755
--- a/scripts/dpkg-maintscript-helper.sh
+++ b/scripts/dpkg-maintscript-helper.sh
@@ -84,6 +84,34 @@ rm_conffile() {
 	esac
 }
 
+
+safe_get_md5sum() {
+local FILE="$1"
+local error_md5
+
+exec 4>&1
+error_md5=$( ( (md5sum < $FILE ; echo "$?" >&3 ) | sed -e 's/ .*//' ) 3>&1 >&4) || \
+error "md5sum fail for '$FILE'"
+exec 4>&-
+test X"$error_md5" = "X0" || \
+	error "md5sum program fail with exit code '$error_md5' for '$FILE'"
+}
+
+safe_get_old_conf_md5sum() {
+local CONFFILE="$1"
+local PACKAGE="$2"
+local error_dpkg_q
+exec 4>&1
+error_dpkg_q=$( ( \
+		  (dpkg-query -W -f='${Conffiles}' "$PACKAGE" ; echo "$?" >&3 ) \
+			  | sed -n -e "\'^ $CONFFILE ' { s/ obsolete$//; s/.* //; p }" \
+		  ) 3>&1 >&4) || \
+	error "Could not get old md5sum for '$FILE'"
+exec 4>&-
+test X"$error_dpkg_q" = "X0" || \
+	error "dpkg-query fail for conffile '$CONFFILE' for package '$PACKAGE'"
+}
+
 prepare_rm_conffile() {
 	local CONFFILE="$1"
 	local PACKAGE="$2"
@@ -92,9 +120,8 @@ prepare_rm_conffile() {
 	ensure_package_owns_file "$PACKAGE" "$CONFFILE" || return 0
 
 	local md5sum old_md5sum
-	md5sum="$(md5sum "$CONFFILE" | sed -e 's/ .*//')"
-	old_md5sum="$(dpkg-query -W -f='${Conffiles}' "$PACKAGE" | \
-		sed -n -e "\'^ $CONFFILE ' { s/ obsolete$//; s/.* //; p }")"
+	md5sum="$(safe_get_md5sum "$CONFFILE")"
+	old_md5sum="$(safe_get_old_conf_md5sum "$CONFFILE" "$PACKAGE")"
 	if [ "$md5sum" != "$old_md5sum" ]; then
 		mv -f "$CONFFILE" "$CONFFILE.dpkg-backup"
 	else


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

Bug#874116: [Pkg-octave-devel] Bug#874116: Bug#874116: Bug#874116: octave-tisean FTBFS on !amd64: test failure

[Adrian Bunk]

On Sun, Sep 03, 2017 at 08:36:01PM +0200, Rafael Laboissière wrote:
> * Adrian Bunk  [2017-09-03 19:01]:
> 
> > On Sun, Sep 03, 2017 at 05:52:26PM +0200, Rafael Laboissière wrote:
> > 
> > > It seems that many of the unit test failures happen when the
> > > function henon is involved.  This function computes the Henon map
> > > with a default transient initial period of 1 samples.  The
> > > computation in the henon function is iterative and my guess is that
> > > the results are sensitive to the architecture-specific floating
> > > point representation.  Would -ffloat-store help here?
> > 
> > -ffloat-store sometimes matters on i386, but on most architectures it is
> > a complete nop.
> 
> Thanks for your quick reply.  Are there other sources of differences in the
> representation of float numbers across the architectures, that might explain
> the different results in the henon function?

Sorry, I don't have any immediate ideas on that
(and no time to debug it properly).

> Rafael

cu
Adrian

-- 

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

Bug#874185: _solve_toeplitz.x86_64-linux-gnu.so: undefinedsymbol: PyFPE_jbuf

[Sébastien Villemot]

Package: python-scipy
Version: 0.18.1-2+b2
Severity: serious

The linalg submodule currently cannot be loaded in sid:

$ python -c "from scipy import linalg"
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/scipy/linalg/__init__.py", line 175, 
in 
from .basic import *
  File "/usr/lib/python2.7/dist-packages/scipy/linalg/basic.py", line 21, in 

from ._solve_toeplitz import levinson
ImportError: 
/usr/lib/python2.7/dist-packages/scipy/linalg/_solve_toeplitz.x86_64-linux-gnu.so:
 undefined symbol: PyFPE_jbuf

This issue seems related to #873791.

Cheers,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#874183: xmlrpc-c FTCBFS: runs host architecture binaries

[Helmut Grohne]

Source: xmlrpc-c
Version: 1.33.14-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xmlrpc-c fails to cross build from source, because it fails running
gennmtab, which was built with the host architecture compiler. gennmtab
is part of an embedded code copy of expat. In any case, it is built with
BUILDTOOL_CC which strangely ends up being the host architecture
compiler. Properly setting BUILDTOOL_CC (and BUILDTOOL_CCLD) fixes that.
Further down the road, debian/rules unconditionally runs "make check"
(even when DEB_BUILD_OPTIONS=nocheck) and naturally fails doing so.
After also honouring DEB_BUILD_OPTIONS=nocheck, xmlrpc-c cross builds
successfully. Please consider applying the attached patch.

Also moving "make check" to override_dh_auto_test might make sense
conceptually.

Helmut
diff --minimal -Nru xmlrpc-c-1.33.14/debian/changelog 
xmlrpc-c-1.33.14/debian/changelog
--- xmlrpc-c-1.33.14/debian/changelog   2017-03-10 23:41:13.0 +0100
+++ xmlrpc-c-1.33.14/debian/changelog   2017-09-03 22:38:02.0 +0200
@@ -1,3 +1,12 @@
+xmlrpc-c (1.33.14-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Set BUILDTOOL_CC.
++ Do not run make check when DEB_BUILD_OPTIONS=nocheck.
+
+ -- Helmut Grohne   Sun, 03 Sep 2017 22:38:02 +0200
+
 xmlrpc-c (1.33.14-4) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru xmlrpc-c-1.33.14/debian/rules xmlrpc-c-1.33.14/debian/rules
--- xmlrpc-c-1.33.14/debian/rules   2017-03-10 23:41:13.0 +0100
+++ xmlrpc-c-1.33.14/debian/rules   2017-09-03 22:38:02.0 +0200
@@ -19,9 +19,11 @@
--disable-wininet-client
 
 override_dh_auto_build:
-   dh_auto_build
+   dh_auto_build -- BUILDTOOL_CC=gcc 'BUILDTOOL_CCLD=$$(BUILDTOOL_CC)'
( cd tools && make )
+ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
make check
+endif
 
 override_dh_auto_clean:
rm -f build-arch-stamp build-indep-stamp

Bug#870804: rtl-sdr: rtl_tcp fails listening on ipv6

[A. Maitland Bottoms]

tags 870804 + patch
stop

I am adding this patch to the Debian package, and submitting
it upstream.

-Maitland
>From 224f789ec669bb57f434fd6f5160d5d2d973f57a Mon Sep 17 00:00:00 2001
From: "A. Maitland Bottoms" 
Date: Sun, 3 Sep 2017 16:22:55 -0400
Subject: [PATCH] add ipv6 support

---
 src/rtl_tcp.c | 76 +--
 1 file changed, 58 insertions(+), 18 deletions(-)

diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c
index da6057b..8a45264 100644
--- a/src/rtl_tcp.c
+++ b/src/rtl_tcp.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #else
@@ -371,10 +372,18 @@ static void *command_worker(void *arg)
 int main(int argc, char **argv)
 {
 	int r, opt, i;
-	char* addr = "127.0.0.1";
-	int port = 1234;
+	char *addr = "127.0.0.1";
+	char *port = "1234";
 	uint32_t frequency = 1, samp_rate = 2048000;
-	struct sockaddr_in local, remote;
+	struct sockaddr_storage local, remote;
+	struct addrinfo *ai;
+	struct addrinfo *aiHead;
+	struct addrinfo  hints;
+	char hostinfo[NI_MAXHOST];
+	char portinfo[NI_MAXSERV];
+	char remhostinfo[NI_MAXHOST];
+	char remportinfo[NI_MAXSERV];
+	int aiErr;
 	uint32_t buf_num = 0;
 	int dev_index = 0;
 	int dev_given = 0;
@@ -413,10 +422,10 @@ int main(int argc, char **argv)
 			samp_rate = (uint32_t)atofs(optarg);
 			break;
 		case 'a':
-			addr = optarg;
+		addr = strdup(optarg);
 			break;
 		case 'p':
-			port = atoi(optarg);
+		port = strdup(optarg);
 			break;
 		case 'b':
 			buf_num = atoi(optarg);
@@ -515,16 +524,44 @@ int main(int argc, char **argv)
 	pthread_cond_init(, NULL);
 	pthread_cond_init(_cond, NULL);
 
-	memset(,0,sizeof(local));
-	local.sin_family = AF_INET;
-	local.sin_port = htons(port);
-	local.sin_addr.s_addr = inet_addr(addr);
-
-	listensocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
-	r = 1;
-	setsockopt(listensocket, SOL_SOCKET, SO_REUSEADDR, (char *), sizeof(int));
-	setsockopt(listensocket, SOL_SOCKET, SO_LINGER, (char *), sizeof(ling));
-	bind(listensocket,(struct sockaddr *),sizeof(local));
+	hints.ai_flags  = AI_PASSIVE; /* Server mode. */
+	hints.ai_family = PF_UNSPEC;  /* IPv4 or IPv6. */
+	hints.ai_socktype = SOCK_STREAM;
+	hints.ai_protocol = IPPROTO_TCP;
+
+	//memset(,0,sizeof(local));
+	//local.sin_family = AF_INET;
+	//local.sin_port = htons(atoi(port));
+	//local.sin_addr.s_addr = inet_addr(addr);
+
+	if ( ( aiErr = getaddrinfo( addr,
+port,
+,
+ ) ) != 0 )
+	  {
+	fprintf( stderr, "local address %s ERROR - %s.\n",
+		 addr, gai_strerror( aiErr ) );
+	return(-1);
+	  }
+	memcpy(, aiHead->ai_addr, aiHead->ai_addrlen);
+
+	for (ai = aiHead; ai != NULL; ai = ai->ai_next) {
+	  aiErr = getnameinfo((struct sockaddr *)ai->ai_addr, ai->ai_addrlen,
+			  hostinfo, NI_MAXHOST,
+			  portinfo, NI_MAXSERV, NI_NUMERICSERV|NI_NUMERICHOST);
+	  if (aiErr) fprintf( stderr, "getnameinfo ERROR - %s.\n",hostinfo);
+
+	  listensocket = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
+	  if (listensocket<0) continue;
+
+	  r = 1;
+	  setsockopt(listensocket, SOL_SOCKET, SO_REUSEADDR, (char *), sizeof(int));
+	  setsockopt(listensocket, SOL_SOCKET, SO_LINGER, (char *), sizeof(ling));
+	  if(bind(listensocket,(struct sockaddr *),sizeof(local))) {
+	fprintf(stderr, "rtl_tcp bind error: %s", strerror(errno));
+	  } else
+	break;
+	}
 
 #ifdef _WIN32
 	ioctlsocket(listensocket, FIONBIO, );
@@ -535,11 +572,11 @@ int main(int argc, char **argv)
 
 	while(1) {
 		printf("listening...\n");
-		printf("Use the device argument 'rtl_tcp=%s:%d' in OsmoSDR "
+		printf("Use the device argument 'rtl_tcp=%s:%s' in OsmoSDR "
 		   "(gr-osmosdr) source\n"
 		   "to receive samples in GRC and control "
 		   "rtl_tcp parameters (frequency, gain, ...).\n",
-		   addr, port);
+		   hostinfo, portinfo);
 		listen(listensocket,1);
 
 		while(1) {
@@ -559,7 +596,10 @@ int main(int argc, char **argv)
 
 		setsockopt(s, SOL_SOCKET, SO_LINGER, (char *), sizeof(ling));
 
-		printf("client accepted!\n");
+		getnameinfo((struct sockaddr *), rlen,
+			remhostinfo, NI_MAXHOST,
+			remportinfo, NI_MAXSERV, NI_NUMERICSERV);
+		printf("client accepted! %s %s\n",remhostinfo,remportinfo);
 
 		memset(_info, 0, sizeof(dongle_info));
 		memcpy(_info.magic, "RTL0", 4);
-- 
2.11.0

Bug#872361: mpg123 misparses IPv6 address + port in http_proxy

[Ivan Shmakov]

> Thomas Orgis  writes:

 > I prepared fixes for both bug 872362 and 872361 for an upcoming
 > mpg123 version 1.25.7.  A preliminary release tarball is available
 > via

 > https://mpg123.org/test/mpg123-1.25.7.tar.bz2

[…]

 > Ivan, can you test your two issues with the preliminary release and
 > give feedback before I make it official?

The IPv6 http_proxy= handling seems to be the other way around
now; for instance:

$ http_proxy=http://ip6-localhost:9993/ \
  LD_LIBRARY_PATH=src/libout123/.libs ./src/mpg123 \
  -- http://stream.chipbit.net:8000/autodj.m3u 
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.25.7; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes
HTTP request failed: 404 Not Found
main: [src/mpg123.c:686] error: Access to http resource 
http://stream.chipbit.net:8000/autodj.m3u failed.
$ http_proxy=http://\[::1\]:9993/ \
  LD_LIBRARY_PATH=src/libout123/.libs ./src/mpg123 \
  -- http://stream.chipbit.net:8000/autodj.m3u 
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.25.7; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes

Directory: http://stream.chipbit.net:8000/

Terminal control enabled, press 'h' for listing of keys and functions.

Playing MPEG stream 1 of 1: autodj.m3u ...
ICY-NAME: ChipBit
ICY-URL: http://chipbit.net

MPEG 1.0 L III cbr128 44100 j-s

ICY-META: StreamTitle='General Offensive, Mrsonic699 - Insert Cartridge 
[Prelude]';
...

(Note that there's also an HTTP server on TCP port 80, which is
not configured as a proxy.)

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Bug#874182: Regression breaks hourly, daily, weekly, and monthly snapshots

[Jason Wittlin-Cohen]

Package: zfs-auto-snapshot
Version: 1.2.2-1
Severity: Important

Dear Maintainer,

The update to zfs-auto-snapshot 1.2.2-1 has caused a regression preventing
hourly, daily, weekly, and monthly auto snapshots from running.  Frequent
snapshots still work.  Reverting the scripts to those used by the prior
version, 1.2.1-1, fixed the issue.

New script which does not work:

!/bin/sh

# Only call zfs-auto-snapshot if it's available
exec which zfs-auto-snapshot > /dev/null && \
 zfs-auto-snapshot --quiet --syslog --label=daily --keep=31 //

Old Script that works:

#!/bin/sh
exec zfs-auto-snapshot --quiet --syslog --label=daily --keep=31 //

   * What led up to the situation?

I installed zfs-auto-snapshot on my system running Debian Buster, and
enabled
frequent, hourly, and daily snapshots.  I noticed that only frequent
snapshots
were running.  In contrast, with the same settings, my Debian Stretch system
had functional frequent, hourly, and daily snapshots. Syslog only showed the
zfs-auto-snapshot running for frequent snapshots.  There was no indication
that
the system attempted to run hourly or daily snapshots, as instructed.


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

 ineffective)?

I was able to resolve the issue by replacing the zfs-auto-snapshot scripts
in
/etc/cron.daily and /etc/cron.hourly with the scripts from 1.2.1-1.

   * What was the outcome of this action?

Hourly and Daily snapshots now work as expected.

-- System Information:

Debian Release: buster/sid

  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages zfs-auto-snapshot depends on:

ii  cron3.0pl1-128+b1
ii  zfsutils-linux  0.6.5.11-1

zfs-auto-snapshot recommends no packages.
zfs-auto-snapshot suggests no packages.

-- Configuration Files:

/etc/cron.daily/zfs-auto-snapshot changed:

exec zfs-auto-snapshot --quiet --syslog --label=daily --keep=31 //

/etc/cron.hourly/zfs-auto-snapshot changed:

exec zfs-auto-snapshot --quiet --syslog --label=hourly --keep=24 //

Bug#874179: cysignals: Add python3 packages

[Tobias Hansen]

Source: cysignals
Severity: wishlist

Hi Jerome,

please add python3 packages in one of the future updates. We will
eventually need them for sagemath.

Best,
Tobias

Bug#874180: python3-tk: undefined symbol in _tkinter.cpython-35m-x86_64-linux-gnu.so

[Philippe Daouadi]

Package: python3-tk
Version: 3.5.3-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After updating my system, python3-tk stopped functionning:

>>> import _tkinter
Traceback (most recent call last):
  File "", line 1, in 
ImportError: 
/usr/lib/python3.5/lib-dynload/_tkinter.cpython-35m-x86_64-linux-gnu.so: 
undefined symbol: PyFPE_jbuf

Here is the output of ldd:

$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpython3.5m.so ldd -r 
/usr/lib/python3.5/lib-dynload/_tkinter.cpython-35m-x86_64-linux-gnu.so 
linux-vdso.so.1 (0x7ffd1fdfe000)
/usr/lib/x86_64-linux-gnu/libpython3.5m.so (0x7fca1211f000)
libBLT.2.5.so.8.6 => /usr/lib/libBLT.2.5.so.8.6 (0x7fca11db)
libtk8.6.so => /usr/lib/x86_64-linux-gnu/libtk8.6.so (0x7fca11a52000)
libtcl8.6.so => /usr/lib/x86_64-linux-gnu/libtcl8.6.so (0x7fca1169b000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7fca1135b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fca1113e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fca10da1000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x7fca10b76000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fca1095c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fca10758000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7fca10555000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fca10251000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7fca1003a000)
libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x7fca0fe24000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 
(0x7fca0fbe)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 
(0x7fca0f92b000)
libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x7fca0f728000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7fca0f516000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7fca0f2ee000)
/lib64/ld-linux-x86-64.so.2 (0x7fca129b)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 
(0x7fca0f0e4000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 
(0x7fca0eeb1000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7fca0ecad000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 
(0x7fca0eaa7000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7fca0e892000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fca0e68a000)
  undefined symbol: 
PyFPE_jbuf(/usr/lib/python3.5/lib-dynload/_tkinter.cpython-35m-x86_64-linux-gnu.so)
  undefined symbol: 
PyFPE_counter(/usr/lib/python3.5/lib-dynload/_tkinter.cpython-35m-x86_64-linux-gnu.so)

Philippe

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

Kernel: Linux 4.12.0-1-amd64 (SMP w/6 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 python3-tk depends on:
ii  blt   2.5.3+dfsg-3
ii  libc6 2.24-17
ii  libtcl8.6 8.6.7+dfsg-1
ii  libtk8.6  8.6.7-1
ii  libx11-6  2:1.6.4-3
ii  python3   3.5.3-3
ii  tk8.6-blt2.5  2.5.3+dfsg-3

python3-tk recommends no packages.

Versions of packages python3-tk suggests:
pn  python3-tk-dbg  
pn  tix 

-- no debconf information

Bug#874181: structure-synth: Please switch to use QT5

[Guillem Jover]

Source: structure-synth
Source-Version: 1.5.0-3
Severity: wishlist
Tags: upstream

Hi!

This package is still using the deprecated QT4, but it seems like
upstream has had some commits adding support for QT5. It would be
nice if those could either be cherry-picked, or perhaps a snapshot
packaged.

  

Thanks,
Guillem

Bug#874165: libvdpau FTBFS: configure: error: Documentation enabled but doxygen was not found in your path

[Luca Boccassi]

Control: close -1 1.1.1-8

On Sun, 2017-09-03 at 19:41 +0100, Luca Boccassi wrote:
> On September 3, 2017 7:15:04 PM GMT+01:00, Adrian Bunk  rg> wrote:
> > Source: libvdpau
> > Version: 1.1.1-7
> > Severity: serious
> > 
> > https://buildd.debian.org/status/package.php?p=libvdpau=sid
> > 
> > ...
> > checking for library containing pthread_once... -lpthread
> > checking for doxygen... no
> > checking for dot... no
> > configure: error: Documentation enabled but doxygen was not found
> > in
> > your path
> 
> Hi,
> 
> Yes, I did a boo-boo :-P
> I failed to see the problem when testing with pbuilder, but I've
> already pushed a fix some minutes ago, hopefully it's good this time.

Yep it's fixed now, thanks.

-- 
Kind regards,
Luca Boccassi

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

Bug#874177: expat/lib/nametab.h source missing

[Helmut Grohne]

Source: expat
Version: 2.2.3-1
Severity: serious
Justification: missing source
User: helm...@debian.org
Usertags: rebootstrap

The source code for generating expat/lib/nametab.h is missing from the
debian source package. It can be found at
https://github.com/libexpat/libexpat/blob/97c6bd01990090d4015364ae37dd141f3c39a30f/expat/gennmtab/gennmtab.c.

Helmut

Bug#874178: mutt: messes with the terminal output

[Mattia Rizzolo]

Package: mutt
Version: 1.8.3+neomutt20170609-2
Severity: minor

I noticed that mutt messes quite a bit with the terminal output.  I
mean, it's expected given that it has to draw stuff over it, but then,
when it gives the control back to the original terminal it's all messed
up somehow.  It's easy to notice it when, for example, it spawns gpg to
sign a message and I get the keyphrase wrong:

```
mattia@warren ~ % mutt
gpg: signing failed: Operation cancelled
gpg: signing failed: Operation cancelled

Press any key to continue...
gpg: signing failed: Operation cancelled
gpg: signing failed: Operation cancelled

Press any key to continue...
```

And so on.  Then, when mutt is killed something it's still borked and I
need a `reset` to get it back to normal.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#874145: vmtouch: FTBFS on non-Linux: many identifiers undeclared

[Aaron M. Ucko]

"Aaron M. Ucko"  writes:

> For kFreeBSD (__FreeBSD_kernel__), it should suffice to define various
> _*_SOURCE macros more broadly.

Alternatively, building with -std=gnu99 rather than the stricter
-std=c99 should eliminate the need for most or all of these explicit
_*_SOURCE settings.  You'll still need to do something about PATH_MAX on
the Hurd, though.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#874176: wrk: Fails to run with 'PANIC: unprotected error in call to Lua API'

[Federico Ceratto]

Package: wrk
Version: 4.0.2-2
Severity: grave

The error makes wrk unusable:

wrk -d 3 http://localhost:8080/
PANIC: unprotected error in call to Lua API (attempt to index a nil value)


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

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

Versions of packages wrk depends on:
ii  libc62.24-17
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-2
ii  libssl1.11.1.0f-5

wrk recommends no packages.

wrk suggests no packages.

-- no debconf information

Bug#874151: FTBFS with Java 9: [gettext-dist] msgfmt returned 1

[Martin Quinson]

Hello,

thanks for the report. Could you please point me to the procedure to
reproduce the bug? I did not knew it's possible to let default-jdk
pointing to the version you want. 

Thanks for your help,
Mt.

On Sun, Sep 03, 2017 at 05:12:21PM +0100, Chris West wrote:
> Source: plm
> Version: 2.6+repack
> Severity: normal
> User: debian-j...@lists.debian.org
> Usertags: default-java9
> 
> This package fails to build with default-jdk pointing to openjdk-9-jdk.
> Please fix it, so that we can start the transition to Java 9.
> The wiki has some common problems and their solutions:
> https://wiki.debian.org/Java/Java9Pitfalls
> 
> Unfortunately there's nothing really useful in the build log I can see,
> and I didn't look further.
> 
> Build log:
> 
> i18n-generate-jar:
> [mkdir] Created dir: /build/plm-2.6+repack/site/po
> [gettext-dist] Processing en.po
> [gettext-dist] msgfmt --java2 -d ./site/po -r org.plm.i18n.Messages -l en 
> /build/plm-2.6+repack/l10n/engine/en.po
> [gettext-dist] msgfmt returned 1
> 
> BUILD FAILED
> /build/plm-2.6+repack/build.xml:189: Build failed
> 
> 
> Cheers,
> Chris.

-- 
I'm not griping, I'm just observing what a miserable experience this is.
--- Calvin


signature.asc
Description: PGP signature

Bug#874168: Please update gpaste to 3.24

[Jeremy Bicha]

On Sun, Sep 3, 2017 at 3:45 PM, Jérémy Lal  wrote:
> 2017-09-03 21:10 GMT+02:00 Jeremy Bicha :
>> I've prepared packaging. Please let me know if you want me to push the
>> packaging to your collab-maint repo.
>
> Yes, please

Done.

Thanks,
Jeremy Bicha

Bug#873612: lintian: please check latest-debian-changelog-entry-without-new-date for sources as well

[Chris Lamb]

tags 873612 + patch
thanks

Hi Lintian devs,

> lintian: please check latest-debian-changelog-entry-without-new-date
> for sources as well

Patch attached; could I get some review? I tried to add the check within
changelog-file.pm by making it "Type: source, binary", but it required
too many conditionals wrt. checking $type here and there so this actually
looked far cleaner to me.

I moved the tag — as opposed to creating a new one — so that we don't
have to change dak, my previous related announcement to -devel, as well
as any (I guess possible!) overrides.
  
Diffstat is:


   checks/changelog-file.desc |  2 +-
   checks/changelog-file.pm   |  2 +-
   checks/source-changelog.desc   | 18 
   checks/source-changelog.pm | 52 
++
   debian/changelog   |  3 ++
   profiles/debian/main.profile   |  5 ++--
   t/tests/changelog-file-general/desc|  1 +
   t/tests/changelog-file-general/tags|  3 +-
   t/tests/changelog-file-unreleased/desc |  4 ++-
   t/tests/legacy-foo++/desc  |  1 +
   t/tests/legacy-foo++/tags  |  3 +-
   11 files changed, 87 insertions(+), 7 deletions(-)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
>From b499b7b80b5a3da4fdd31a2f574505e02b45d277 Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Sun, 3 Sep 2017 20:29:28 +0100
Subject: [PATCH] Move latest-debian-changelog-entry-without-new-date tag into
 a new check of type "source". (Closes: #873612)

---
 checks/changelog-file.desc |  2 +-
 checks/changelog-file.pm   |  2 +-
 checks/source-changelog.desc   | 18 
 checks/source-changelog.pm | 52 ++
 debian/changelog   |  3 ++
 profiles/debian/main.profile   |  5 ++--
 t/tests/changelog-file-general/desc|  1 +
 t/tests/changelog-file-general/tags|  3 +-
 t/tests/changelog-file-unreleased/desc |  4 ++-
 t/tests/legacy-foo++/desc  |  1 +
 t/tests/legacy-foo++/tags  |  3 +-
 11 files changed, 87 insertions(+), 7 deletions(-)
 create mode 100644 checks/source-changelog.desc
 create mode 100644 checks/source-changelog.pm

diff --git a/checks/changelog-file.desc b/checks/changelog-file.desc
index df848ac0c..07b4346be 100644
--- a/checks/changelog-file.desc
+++ b/checks/changelog-file.desc
@@ -195,7 +195,7 @@ Info: The NEWS.Debian file must be valid UTF-8, an encoding of the Unicode
   $ iconv -f ISO-8859-1 -t UTF-8 NEWS.Debian  NEWS.Debian.new
   $ mv NEWS.Debian.new NEWS.Debian
 
-Tag: latest-debian-changelog-entry-without-new-date
+Tag: latest-changelog-entry-without-new-date
 Severity: important
 Certainty: certain
 Info: The latest Debian changelog entry has either the same or even an
diff --git a/checks/changelog-file.pm b/checks/changelog-file.pm
index 26b5d7acb..74a03be96 100644
--- a/checks/changelog-file.pm
+++ b/checks/changelog-file.pm
@@ -299,7 +299,7 @@ sub run {
 my $second_timestamp = $entries[1]->Timestamp;
 
 if ($first_timestamp && $second_timestamp) {
-tag 'latest-debian-changelog-entry-without-new-date'
+tag 'latest-changelog-entry-without-new-date'
   unless (($first_timestamp - $second_timestamp) > 0
 or lc($entries[0]->Distribution) eq 'unreleased');
 }
diff --git a/checks/source-changelog.desc b/checks/source-changelog.desc
new file mode 100644
index 0..32f4615ea
--- /dev/null
+++ b/checks/source-changelog.desc
@@ -0,0 +1,18 @@
+Check-Script: source-changelog
+Author: Chris Lamb 
+Type: source
+Needs-Info: changelog-file, unpacked
+Info: This script checks if a source package conforms to policy
+ with regard to changelog files.
+ .
+ Each source package should have a debian/changelog file.
+
+Tag: latest-debian-changelog-entry-without-new-date
+Severity: important
+Certainty: certain
+Info: The latest Debian changelog entry has either the same or even an
+ older date as the entry before.
+ .
+ This can result in subtle bugs due to the SOURCE_DATE_EPOCH
+ environment variable being the same between the older and newer
+ versions.
diff --git a/checks/source-changelog.pm b/checks/source-changelog.pm
new file mode 100644
index 0..d37c4d5ea
--- /dev/null
+++ b/checks/source-changelog.pm
@@ -0,0 +1,52 @@
+# source-changelog -- lintian check script -*- perl -*-
+
+# Copyright (C) 2017 Chris Lamb 
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without 

Bug#874175: libfsoframework: please include needed header files

[Gianfranco Costamagna]

Source: libfsoframework
Version: 0.12.0-8
Severity: important
tags: patch

Hello, can you please consider adding this patch to the package (and forward 
upstream)?

  * Fix missing include of netlink/route/addr.h, resulting in FTBFS on
64-bit platforms.

e.g.
https://launchpadlibrarian.net/232311089/buildlog_ubuntu-xenial-amd64.libfsoframework_0.12.0-7_BUILDING.txt.gz

Function `rtnl_addr_get_local' implicitly converted to pointer at 
netlinknotifier.c:1002
Function `rtnl_addr_get_peer' implicitly converted to pointer at 
netlinknotifier.c:1017
Function `rtnl_addr_get_broadcast' implicitly converted to pointer at 
netlinknotifier.c:1032
Function `rtnl_addr_get_anycast' implicitly converted to pointer at 
netlinknotifier.c:1047
Function `rtnl_addr_get_multicast' implicitly converted to pointer at 
netlinknotifier.c:1062
Function `rtnl_addr_get_label' implicitly converted to pointer at 
netlinknotifier.c:
Function `rtnl_addr_flags2str' implicitly converted to pointer at 
netlinknotifier.c:1120



Description:  Fix missing include of netlink/route/addr.h, resulting in FTBFS 
on 64-bit platforms.
Author: Dimitri John Ledkov 

--- libfsoframework-0.12.0.orig/fsobasics/netlinknotifier.vala
+++ libfsoframework-0.12.0/fsobasics/netlinknotifier.vala
@@ -275,6 +275,9 @@ public class FsoFramework.BaseNetlinkNot
 
 protected void fillAddressProperties( Netlink.Address addr, ref 
HashTable properties )
 {
+   // trigger inclusion of netlink/route/addr.h
+   var unused = new Netlink.RouteAddress();
+   
 properties.insert( "ADDR_FAMILY", Netlink.af2Str( addr.get_family(), 
buffer ) );
 
 var local = addr.get_local();

attached the patch.


thanks for considering it,

Gianfranco
Description:  Fix missing include of netlink/route/addr.h, resulting in FTBFS on 64-bit platforms.
Author: Dimitri John Ledkov 

--- libfsoframework-0.12.0.orig/fsobasics/netlinknotifier.vala
+++ libfsoframework-0.12.0/fsobasics/netlinknotifier.vala
@@ -275,6 +275,9 @@ public class FsoFramework.BaseNetlinkNot
 
 protected void fillAddressProperties( Netlink.Address addr, ref HashTable properties )
 {
+// trigger inclusion of netlink/route/addr.h
+var unused = new Netlink.RouteAddress();
+
 properties.insert( "ADDR_FAMILY", Netlink.af2Str( addr.get_family(), buffer ) );
 
 var local = addr.get_local();


signature.asc
Description: OpenPGP digital signature

Bug#832159: ITP: qutebrowser -- A keyboard-driven, vim-like browser based on PyQt5.

[Fritz Reichwald]

Hi,

the status of packaging can be found here: 
https://github.com/fiete201/qutebrowser-debian
And the built package here:
https://github.com/qutebrowser/qutebrowser/releases

At the moment I'm waiting for someone to sponsor the package.

Best regards
Fritz

-- 


signature.asc
Description: PGP signature

Bug#872502: curl FTBFS for hppa: error: unknown type name 'curl_off_t'

[John David Anglin]

On 2017-09-02, at 6:20 AM, Alessandro Ghedini wrote:

> Anyway, it seems the hppa build is actually successful now:
> https://buildd.debian.org/status/fetch.php?pkg=curl=hppa=7.55.0-1=1503251821=0

The addition of "|| (defined(__SIZEOF_LONG__) && __SIZEOF_LONG__ == 4)" to the 
if fixes the hppa build.

Regards,
Dave
--
John David Anglin   dave.ang...@bell.net

Bug#874168: Please update gpaste to 3.24

[Jérémy Lal]

2017-09-03 21:10 GMT+02:00 Jeremy Bicha :

> Source: gpaste
> Version: 3.22.4-1
> Severity: important
>
> Please update gpaste to 3.24.
>
> https://github.com/Keruspe/GPaste/blob/master/NEWS
>
> I am filing this bug as Important instead of Wishlist because gpaste
> Build-Depends on libmutter-dev and it will need to be prepared to
> build against libmutter-1-dev for the gnome-shell/mutter 3.26
> transition.
>
> gpaste's soname has been bumped so it will need to go through the NEW
> queue. Could you look into uploading this to experimental soon?
>
> I've prepared packaging. Please let me know if you want me to push the
> packaging to your collab-maint repo.
>

Yes, please

https://anonscm.debian.org/git/users/jbicha/gpaste.git/
>
> gpaste-applet has been split to a separate source package but I
> haven't looked into it since I don't use a "traditional" desktop where
> it's useful.
>
> https://github.com/Keruspe/gpaste-applet


I don't have the intention to package it either.

Jérémy

Bug#874169: AppStreamQtConfig.cmake no longer usable in i386

[Matthias Klumpp]

2017-09-03 21:15 GMT+02:00 Maximiliano Curia :
> [...]
> # check that the installed version has the same 32/64bit-ness as the one
> which is currently searching:
> if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
>   math(EXPR installedBits "8 * 8")
>   set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
>   set(PACKAGE_VERSION_UNSUITABLE TRUE)
> endif()
>
> This last part `NOT CMAKE_SIZEOF_VOID_P STREQUAL "8"', seems to indicate
> that it would never work on a 32 bit system. Is the "8" here meant to be
> replaced at build time?

Can you try removing that entire section and see if that fixes it?
It serves no real purpose in how AppStreamQt is used anyway.

Cheers,
Matthias

Bug#874173: raincat: URL is now http://bysusanlin.com/raincat/

[Antoine Musso]

Package: raincat
Version: 1.1.1.2-3+b2
Severity: minor

Dear Maintainer,

http://raincat.bysusanlin.com/ is no more. I guess upstream hasn't
renewed the subdomain when migrating to a new host.

However it is reacheable via: http://bysusanlin.com/raincat/


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

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

Versions of packages raincat depends on:
ii  freeglut3 2.8.1-3
ii  libc6 2.24-11+deb9u1
ii  libffi6   3.2.1-6
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgmp10  2:6.1.2+dfsg-1
ii  libsdl-image1.2   1.2.12-5+b8
ii  libsdl-mixer1.2   1.2.12-11+b3
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  raincat-data  1.1.1.2-3

raincat recommends no packages.

raincat suggests no packages.

-- no debconf information

Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Samuel Thibault]

Control: clone -1 -2
Control: reassign -2 at-spi2-core
Control: retitle -2 Should not set QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 any more
Control: found -1 5.7.1+dfsg-3+b1
Control: done -1 5.9.1+dfsg-9

Samuel

Bug#874170: libappstreamqt-dev: AppStreamQtConfig.cmake hardcodes a 64bit behaviour

[Matthias Klumpp]

2017-09-03 21:22 GMT+02:00 Pino Toscano :
> Package: libappstreamqt-dev
> Version: 0.11.4-1
> Severity: grave
> Justification: renders package unusable
> Control: affects -1 src:frameworkintegration
> Control: affects -1 src:plasma-discover
>
> Hi,
>
> in the new version 0.11.4, I guess because of the switch from cmake to
> meson, the source got a template for the AppStreamQtConfig.cmake file.
> This template was created from an existing file on a 64bit system, so
> the final AppStreamQtConfig.cmake file is rejected by cmake when found
> by packages via cmake on 32bit architectures.
>
> Two examples are frameworkintergration, and plasma-discover:
> https://buildd.debian.org/status/logs.php?pkg=frameworkintegration=5.37.0-2
> https://buildd.debian.org/status/logs.php?pkg=plasma-discover=5.10.5-1
> In particular:
>
> <
> CMake Warning at CMakeLists.txt:44 (find_package):
>   Could not find a configuration file for package "AppStreamQt" that is
>   compatible with requested version "0.10.4".
>
>   The following configuration files were considered but not accepted:
>
> /usr/lib/i386-linux-gnu/cmake/AppStreamQt/AppStreamQtConfig.cmake, 
> version: 0.11.4 (64bit)
> <
>
> The severity is grave because this is an issue in the upstream sources,
> and because it's a regression compared to the previous version (and thus
> ought to not migrate to testing).

Bah... I'll see to fix this as soon as possible, first I need to read
up on how CMake determines which files are appropriate.

Cheers,
Matthias

Bug#874155: FTBFS with Java 9: overrides core packages

[Andreas Tille]

Hi Stephen,

could you please have a look.

Kind regards

  Andreas.

On Sun, Sep 03, 2017 at 05:21:19PM +0100, Chris West wrote:
> Source: phyutility
> Version: 2.7.3
> Severity: normal
> User: debian-j...@lists.debian.org
> Usertags: default-java9
> 
> This package fails to build with default-jdk pointing to openjdk-9-jdk.
> Please fix it, so that we can start the transition to Java 9.
> The wiki has some common problems and their solutions:
> https://wiki.debian.org/Java/Java9Pitfalls
> 
> This package seems to be trying to ship some org.xml.sax implementation,
> in source form, in the source tree. This is illegal, under that package
> name, now. But see also the java.xml section on the wiki.
> 
> Build log:
> 
> compile:
> [mkdir] Created dir: /build/phyutility-2.7.3/build/classes
> [javac] /build/phyutility-2.7.3/build.xml:7: warning: 'includeantruntime' 
> was not set, defaulting to build.sysclasspath=last; set to false for 
> repeatable builds
> [javac] Compiling 520 source files to 
> /build/phyutility-2.7.3/build/classes
> [javac] /build/phyutility-2.7.3/src/org/xml/sax/AttributeList.java:6: 
> error: package exists in another module: java.xml
> [javac] package org.xml.sax;
> [javac] ^
> [javac] /build/phyutility-2.7.3/src/org/xml/sax/Attributes.java:7: error: 
> package exists in another module: java.xml
> [javac] package org.xml.sax;
> [javac] ^
> 
> 
> 
> Cheers,
> Chris.
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Samuel Thibault]

Samuel Thibault, on dim. 03 sept. 2017 21:17:12 +0200, wrote:
> I have checked with a vanilla reinstall of Debian 9, using the Mate
> desktop, and Qt 5.7.1.
> 
> When QT_LINUX_ACCESSIBILITY_ALWAYS_ON is not set, I don't see Qt
> applications in accerciser, only the Mate applications. If I set
> QT_LINUX_ACCESSIBILITY_ALWAYS_ON, I do see them.
> 
> On my current desktop, I have Qt 5.9.1, I made quick tests, it seems
> it behaves as I expect, so perhaps we can indeed avoid setting
> QT_LINUX_ACCESSIBILITY_ALWAYS_ON now. I'll retest with a vanilla
> reinstall of debian testing, to be sure.

Yes, a vanilla reinstall behaves as expected.  So we can drop that
variable, good :)

Samuel

Bug#874167: gcc-6-doc: source uploaded without binaries, caused package removal

[Mattia Rizzolo]

On Sun, Sep 03, 2017 at 09:30:08PM +0200, Adam Borowski wrote:
> I've uploaded source+binary identical as before (as it has been in the
> archive, any modifications would be a bad idea).  If this won't work, the
> maintainer (Guo Yixuan) is a better person to bump the version and make
> adjustments.

I fear that it's going to be rejected…  but let's see :)

> XS-Autobuild can be added -2 no matter if we need it tonight or months
> later.

Right.  But please consider adding it, as it makes only sense to have
that stuff built on the buildds.  Also remember that XS-Autobuild is
only the first step, you need to ask it to be whitelisted on the buildds
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#non-free-buildd

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#874167: gcc-6-doc: source uploaded without binaries, caused package removal

[Adam Borowski]

On Sun, Sep 03, 2017 at 08:52:19PM +0200, Mattia Rizzolo wrote:
> Source: gcc-6-doc
> Severity: serious
> Version: 6.4.0-1
> X-Debbugs-Cc: culu@gmail.com, kilob...@angband.pl, dktrkr...@debian.org
> 
> Hi!
> 
> gcc-6-doc is a non-free package, therefore wanna-build doesn't attempt
> its build automatically.  Also, it is not manually whitelisted (it's
> also missing the XS-Autobuild header).
> Nonetheless you uploaded it source-only, without binaries; due to it,
> dak considered the binaries as not built anymore, and ended up in the
> cruft report.  From there an overzealous ftp-master removed it :)

Oif.

> Please upload the package again (which will end up in NEW), and remember
> to either always upload the binaries, or to ask to enable autobuilding.

I've uploaded source+binary identical as before (as it has been in the
archive, any modifications would be a bad idea).  If this won't work, the
maintainer (Guo Yixuan) is a better person to bump the version and make
adjustments.

XS-Autobuild can be added -2 no matter if we need it tonight or months
later.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#874171: network-manager-gnome: nm-connection-editor allows only 'shared' ip configuration for AP

[Vladimir Kudrya]

Package: network-manager-gnome
Version: 1.8.2-1
Severity: normal

Dear Maintainer, when wi-fi Hotspot mode is selected, nm-connection-editor does 
not allow
any ip configuration except 'shared' or disabled. Other options are greyed out.

This contradicts NetworkManager's abilities. Nmtui and nmcli also support other 
ip configurations
for hotspot connections. Therefore GUI has unnecessary restrictions.

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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.11.16+really1.10.22-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.0-2+b1
ii  libatk1.0-0   2.24.0-1
ii  libc6 2.24-14
ii  libcairo2 1.14.10-1
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.53.4-3
ii  libgtk-3-03.22.18-1
ii  libjansson4   2.10-1
ii  libmm-glib0   1.6.8-1
ii  libnm01.8.2-1
ii  libnma0   1.8.2-1
ii  libnotify40.7.7-2
ii  libpango-1.0-01.40.6-1
ii  libpangocairo-1.0-0   1.40.6-1
ii  libsecret-1-0 0.18.5-3.1
ii  libselinux1   2.6-3+b2
ii  lxqt-policykit [polkit-1-auth-agent]  0.11.1-2
ii  network-manager   1.8.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-6

Versions of packages network-manager-gnome recommends:
ii  dunst [notification-daemon] 1.1.0-2+b1
ii  gnome-keyring   3.20.1-1
ii  iso-codes   3.75-1
ii  mobile-broadband-provider-info  20161204-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
ii  network-manager-openvpn-gnome  1.2.10-1
ii  network-manager-pptp-gnome 1.2.4-4
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#874170: libappstreamqt-dev: AppStreamQtConfig.cmake hardcodes a 64bit behaviour

[Pino Toscano]

Package: libappstreamqt-dev
Version: 0.11.4-1
Severity: grave
Justification: renders package unusable
Control: affects -1 src:frameworkintegration
Control: affects -1 src:plasma-discover

Hi,

in the new version 0.11.4, I guess because of the switch from cmake to
meson, the source got a template for the AppStreamQtConfig.cmake file.
This template was created from an existing file on a 64bit system, so
the final AppStreamQtConfig.cmake file is rejected by cmake when found
by packages via cmake on 32bit architectures.

Two examples are frameworkintergration, and plasma-discover:
https://buildd.debian.org/status/logs.php?pkg=frameworkintegration=5.37.0-2
https://buildd.debian.org/status/logs.php?pkg=plasma-discover=5.10.5-1
In particular:

<
CMake Warning at CMakeLists.txt:44 (find_package):
  Could not find a configuration file for package "AppStreamQt" that is
  compatible with requested version "0.10.4".

  The following configuration files were considered but not accepted:

/usr/lib/i386-linux-gnu/cmake/AppStreamQt/AppStreamQtConfig.cmake, version: 
0.11.4 (64bit)
<

The severity is grave because this is an issue in the upstream sources,
and because it's a regression compared to the previous version (and thus
ought to not migrate to testing).

-- 
Pino

Bug#874169: AppStreamQtConfig.cmake no longer usable in i386

[Maximiliano Curia]

Source: appstream
Version: 0.11.4-1
Severity: critical

The latest appstream release migrates the build system to meson, but builds a 
cmake file for compatibility, so far so good. Sadly, the logic to 
detect if the build was for 32 bits or for 64 bits seems to be incorrect, 
which makes software that build depends on libappstreamqt-dev to ftbfs [1].


I looked at the code but couldn't find the root of the issue. The end of the generated 
file (/usr/lib/i386-linux-gnu/cmake/AppStreamQt/AppStreamQtConfigVersion.cmake) says:


# check that the installed version has the same 32/64bit-ness as the one which 
is currently searching:
if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
  math(EXPR installedBits "8 * 8")
  set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
  set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()

This last part `NOT CMAKE_SIZEOF_VOID_P STREQUAL "8"', seems to indicate that it 
would never work on a 32 bit system. Is the "8" here meant to be replaced at 
build time?


Happy hacking,

[1]
https://buildd.debian.org/status/fetch.php?pkg=frameworkintegration=i386=5.37.0-2=1504461982=0

-- System Information:
Debian Release: 9.1
 APT prefers stable-debug
 APT policy: (600, 'stable-debug'), (600, 'proposed-updates'), (600, 'stable'), 
(60, 'testing-debug'), (60, 'testing'), (50, 'unstable-debug'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

--
"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do it blows your whole leg off."
-- Bjarne Stroustrup
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Samuel Thibault]

Samuel Thibault, on dim. 03 sept. 2017 20:23:30 +0200, wrote:
> Allan Sandfeld Jensen, on dim. 03 sept. 2017 20:19:31 +0200, wrote:
> > On Sonntag, 3. September 2017 19:57:55 CEST Samuel Thibault wrote:
> > > Allan Sandfeld Jensen, on dim. 03 sept. 2017 19:13:38 +0200, wrote:
> > > 
> > > That's Qt's fault for not taking care of EventListenerRegistered
> > > signals to determine whether someone is listening.
> > 
> > So it is Qt's fault that is doing what you have told it to do? You have set 
> > the environment variable to ignore the absence of listeners. That is what 
> > QT_LINUX_ACCESSIBILITY_ALWAYS_ON does.
> 
> Ah?  That's not what I had gotten in my tests.  I'll check again, then.

I have checked with a vanilla reinstall of Debian 9, using the Mate
desktop, and Qt 5.7.1.

When QT_LINUX_ACCESSIBILITY_ALWAYS_ON is not set, I don't see Qt
applications in accerciser, only the Mate applications. If I set
QT_LINUX_ACCESSIBILITY_ALWAYS_ON, I do see them.

On my current desktop, I have Qt 5.9.1, I made quick tests, it seems
it behaves as I expect, so perhaps we can indeed avoid setting
QT_LINUX_ACCESSIBILITY_ALWAYS_ON now. I'll retest with a vanilla
reinstall of debian testing, to be sure.

Samuel

Bug#874168: Please update gpaste to 3.24

[Jeremy Bicha]

Source: gpaste
Version: 3.22.4-1
Severity: important

Please update gpaste to 3.24.

https://github.com/Keruspe/GPaste/blob/master/NEWS

I am filing this bug as Important instead of Wishlist because gpaste
Build-Depends on libmutter-dev and it will need to be prepared to
build against libmutter-1-dev for the gnome-shell/mutter 3.26
transition.

gpaste's soname has been bumped so it will need to go through the NEW
queue. Could you look into uploading this to experimental soon?

I've prepared packaging. Please let me know if you want me to push the
packaging to your collab-maint repo.

https://anonscm.debian.org/git/users/jbicha/gpaste.git/

gpaste-applet has been split to a separate source package but I
haven't looked into it since I don't use a "traditional" desktop where
it's useful.

https://github.com/Keruspe/gpaste-applet

Thanks,
Jeremy Bicha

Bug#860566: Pending fixes for bugs in the batik package

[pkg-java-maintainers]

tag 860566 + pending
thanks

Some bugs in the batik package are closed in revision
3985be1982175e4e17c6b6fdb63bf325338bbbf2 in branch 'master' by
Christopher Hoskin

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/batik.git/commit/?id=3985be1

Commit message:

New upstream (1.9)

* New upstream (1.9)
+ Fix "CVE-2017-5662: information disclosure vulnerability" Upstream 
claim
  BATIK-1139 is fixed in 1.9 (Closes: #860566)

Bug#874167: gcc-6-doc: source uploaded without binaries, caused package removal

[Mattia Rizzolo]

Source: gcc-6-doc
Severity: serious
Version: 6.4.0-1
X-Debbugs-Cc: culu@gmail.com, kilob...@angband.pl, dktrkr...@debian.org

Hi!

gcc-6-doc is a non-free package, therefore wanna-build doesn't attempt
its build automatically.  Also, it is not manually whitelisted (it's
also missing the XS-Autobuild header).
Nonetheless you uploaded it source-only, without binaries; due to it,
dak considered the binaries as not built anymore, and ended up in the
cruft report.  From there an overzealous ftp-master removed it :)

Date: Wed, 30 Aug 2017 12:29:23 +
Ftpmaster: Luca Falavigna
Suite: unstable
Binaries:
 gcc-6-doc_6.3.0-1 [all]
Reason: [auto-cruft] no longer built from source

Date: Wed, 30 Aug 2017 12:27:15 +
Ftpmaster: Luca Falavigna
Suite: unstable
Sources:
 gcc-6-doc_6.4.0-1
Reason: [auto-cruft] obsolete source package


Please upload the package again (which will end up in NEW), and remember
to either always upload the binaries, or to ask to enable autobuilding.


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#874166: ITP: node-grunt-babel -- grunt plugin of babel

[Rahulkrishnan R A]

Package: wnpp
Severity: wishlist
Owner: Rahulkrishnan R A 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-grunt-babel
  Version : 7.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/babel/grunt-babel#readme
* License : Expat
  Programming Lang: JavaScript
  Description : grunt plugin of babel

This package is the dependency of node-filesize module

I would like to  maintain this package for long term. I am a member of the
Debian
JavaScript maintainers team.