Bug#823868: (no subject)

[Yves-Alexis Perez]

On lun., 2016-05-09 at 23:09 +0200, Roland Hieber wrote:
> Additionally, when starting gnome-calculator from the terminal, there
> are a lot of warning messages about "Theme parsing error:
> gtk-widgets.css:3782:31: The :insensitive pseudo-class is deprecated.
> Use :disabled instead." which were not there before. Also see attached log.

Yes, GTK+ 3.20 broke themes *again*, Greybird needs to be basically rewritten
from scratch.

Regards,
-- 
Yves-Alexis



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

Bug#823896: vim-dbg package no longer built

[fREW Schmidt]

Package: vim
Version: 7.4.1683-1

vim-dbg is not available in testing.  I suspect somehow this commit
broke it:
https://anonscm.debian.org/cgit/pkg-vim/vim.git/commit/?id=cf485aa66700237f44721e5f6241c94728a4311e

I am not using Debian, I just confirmed this bug by searching:
https://packages.debian.org/search?keywords=vim-dbg=names=testing=all

(The bug exists in Ubuntu, so I noticed.)

-- 
fREW Schmidt
https://blog.afoolishmanifesto.com

Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture

[Geert Stappers]

To: bug report 823672

So the BTS has the message below



- Forwarded message from Wookey  -

Date: Tue, 10 May 2016 04:15:23 +0100
From: Wookey 
To: debian-de...@lists.debian.org
Subject: Re: Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction 
set extension to the x86 architecture
User-Agent: Mutt/1.5.23 (2014-03-12)

+++ Christian Seiler [2016-05-07 16:14 +0200]:
> On 05/07/2016 03:59 PM, Geert Stappers wrote:
> > I now have a better idea _why_  a sse-suport package.

I do think that this sort of ISA-level checking would be best done via
dpkg and package metadata, although this sse-support mechanism will
obviously work. i.e the cpontrol file says what ISA features are
wanted and dpkg can not install it if those HWCAPS are not available
(or indeed install alternate versions that will work if they are
available).

We worked up a prototype spec for this a couple of years ago (at the
bootstrap sprint), but it needs the namespace and granularity fleshing
out: what is the set of HWCAPS listed in each package, what is
presumed to be 'base' that we don't list individually, and so on.

Hopefully one day someone will care enough about this to implement it
:-) It's handy for a range of purposes, like i386/486/586/686 moves,
SSE/altivec/NEON usage, and particularly MIPS which has a lot of
variation in available ISA. It would have let us deal neatly with the
Raspi ARM v6 vs v7 baseline issue too.

> @Adam: One suggestion though: since this might also come in handy
> in other places, I'd recommend you name the source package something
> more generic (such as cpu-support or so, assuming that's not taken
> already, I didn't check)

Seems to me that isa-support or isa-check or hwcaps-support are better
names (it's about the ISA user or the hwcaps available, not the cpu in
general).

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/



- End forwarded message -

-- 
Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#823895: RFS: lsm/1.0.4-1

[Lucas Castro]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

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

* Package name: lsm
  Version : 1.0.4-1
  Upstream Author : Mika Ilmaranta 
* URL : http://lsm.foobar.fi/
* License : GPL-2
  Section : utils

  It builds those binary packages:

lsm   - Link connectivity monitor tool

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-1.dsc




signature.asc
Description: OpenPGP digital signature

Bug#823884: mount crashes via fstab entry

[Andreas Henriksson]

Control: reassign -1 src:linux

Hello Gene S.

Thanks for your bug report. It seems your kernel is crashing
and then all bets are off what happens in userspace.

Reassigning this bug report

Regards,
Andreas Henriksson

On Mon, May 09, 2016 at 05:22:37PM -0700, Gene S wrote:
> Package: mount
> Version: 2.25.2-6
> Severity: important
> 
> Dear Maintainer,
> 
> -- System Information:
> Debian Release: 8.4
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.7-ckt9-5 (SMP w/4 CPU cores)
> Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages mount depends on:
> ii  libc6  2.19-18+deb8u4
> ii  libmount1  2.25.2-6
> ii  libselinux12.3-2
> ii  libsmartcols1  2.25.2-6
> 
> mount recommends no packages.
> 
> Versions of packages mount suggests:
> pn  nfs-common  
> 
> -- no debconf information
> 
> "mount /dvd" crashes, with the following line in /etc/fstab
>   /dev/sr0  /dvd  udf,iso9660  user,noauto  0  0
> where /dev/sr0 is a cd/dvd drive.
> 
> A command of the form "mount /dev/sr0 /mnt" works O.K.
> 
> Debug output to /var/log/kernlog follows, see below...
> 
> After the mount error exit, an attempt to "mount /dev/sr0 /mnt"
> fails with "/dev/sr0 already mounted" message.  A "umount /dev/sr0"
> fails with "/dev/sr0 not mounted" message.  The sr0 device is now
> unreachable/unusable until after a system reboot.
> 
> kernlog (relevant lines) >>>
> 
> May  9 11:40:51 gene64 vmunix: [326817.943679] BUG: unable to handle kernel 
> paging request at 
> May  9 11:40:51 gene64 vmunix: [326817.943785] IP: [] 
> udf_get_last_session+0x0/0x40 [udf]
> May  9 11:40:51 gene64 vmunix: [326817.943860] PGD c01ef067 PUD 0 
> May  9 11:40:51 gene64 vmunix: [326817.943958] Oops: 0002 [#1] SMP 
> May  9 11:40:51 gene64 vmunix: [326817.944055] Modules linked in: udf 
> nvidia_uvm(PO) cp210x usbserial joydev nvidia(PO) ohci_pci ohci_hcd
> May  9 11:40:51 gene64 vmunix: [326817.944373] CPU: 2 PID: 16969 Comm: mount 
> Tainted: P   O  3.16.7-ckt9-5 #5
> May  9 11:40:51 gene64 vmunix: [326817.944423] Hardware name: BIOSTAR Group 
> TA970/TA970, BIOS 4.6.4 01/14/2013
> May  9 11:40:51 gene64 vmunix: [326817.944465] task: 8802250e1890 ti: 
> 8800c012 task.ti: 8800c012
> May  9 11:40:51 gene64 vmunix: [326817.944515] RIP: 0010:[] 
>  [] udf_get_last_session+0x0/0x40 [udf]
> May  9 11:40:51 gene64 vmunix: [326817.944596] RSP: 0018:8800c0123d70  
> EFLAGS: 00010246
> May  9 11:40:51 gene64 vmunix: [326817.944637] RAX:  RBX: 
> 8801e97a0580 RCX: 0428
> May  9 11:40:51 gene64 vmunix: [326817.944686] RDX:  RSI: 
>  RDI: 880209cc2000
> May  9 11:40:51 gene64 vmunix: [326817.944735] RBP: 880209cc2000 R08: 
>  R09: 8801e97a0580
> May  9 11:40:51 gene64 vmunix: [326817.944784] R10: 5540 R11: 
> 01ea R12: 
> May  9 11:40:51 gene64 vmunix: [326817.944833] R13: 0001 R14: 
> a0867e50 R15: 880226049a40
> May  9 11:40:51 gene64 vmunix: [326817.944882] FS:  7f65bf9a6840() 
> GS:88022ed0() knlGS:f7707740
> May  9 11:40:51 gene64 vmunix: [326817.944931] CS:  0010 DS:  ES:  
> CR0: 8005003b
> May  9 11:40:51 gene64 vmunix: [326817.944972] CR2:  CR3: 
> 16fab000 CR4: 000407a0
> May  9 11:40:51 gene64 vmunix: [326817.945021] Stack:
> May  9 11:40:51 gene64 vmunix: [326817.945059]  a0868238 
> 880226049b08 a0867e50 880226049a40
> May  9 11:40:51 gene64 vmunix: [326817.945226]  811c95e9 
> 8802 8800c0123df0 8800c0123d00
> May  9 11:40:51 gene64 vmunix: [326817.945396]   
>   0428
> May  9 11:40:51 gene64 vmunix: [326817.945563] Call Trace:
> May  9 11:40:51 gene64 vmunix: [326817.945605]  [] ? 
> udf_fill_super+0x3e8/0x630 [udf]
> May  9 11:40:51 gene64 vmunix: [326817.945648]  [] ? 
> udf_load_vrs+0x3c0/0x3c0 [udf]
> May  9 11:40:51 gene64 vmunix: [326817.945692]  [] ? 
> snprintf+0x39/0x40
> May  9 11:40:51 gene64 vmunix: [326817.945735]  [] ? 
> udf_load_vrs+0x3c0/0x3c0 [udf]
> May  9 11:40:51 gene64 vmunix: [326817.945778]  [] ? 
> mount_bdev+0x1a9/0x1e0
> May  9 11:40:51 gene64 vmunix: [326817.945820]  [] ? 
> mount_fs+0xc/0xc0
> May  9 11:40:51 gene64 vmunix: [326817.945863]  [] ? 
> vfs_kern_mount+0x5d/0x110
> May  9 11:40:51 gene64 vmunix: [326817.945905]  [] ? 
> do_mount+0x1df/0xab0
> May  9 11:40:51 gene64 vmunix: [326817.945947]  [] ? 
> memdup_user+0x33/0x60
> May  9 11:40:51 gene64 vmunix: [326817.945989]  [] ? 
> SyS_mount+0x9b/0x110
> May  9 11:40:51 gene64 vmunix: [326817.946031]  [] ? 
> system_call_fastpath+0x16/0x1b
> May  9 11:40:51 gene64 vmunix: 

Bug#818555: did anybody else see how scim no longer shows character choices?

[積丹尼 Dan Jacobson]

Tz-Huan so how is it going?

Bug#823894: please detect hard float for non-linux or non-glibc arm-*-*eabihf builds (e.g. musl)

[Helmut Grohne]

Source: gcc-6
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

This is my second patch for musl. This time it is about musl-linux-armhf
only. The gcc packaging has some matching logic for setting make
variables such as $(float_abi). Since they currently match for armhf,
they do not cover non-linux or non-glibc arm-*-*eabihf configurations.
This causes hard to diagnose build failures down the road (thanks to
Waldemar Brodkorb for explaining the cause).  The attached patch
broadens the matching logic to cover these cases and should also address
uclibc-linux-armhf and kfreebsd-armhf if they ever materialize. Do you
agree with the proposed change?

Helmut
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -376,7 +376,7 @@
 endif

 # check if we're building for armel or armhf
-ifeq ($(DEB_TARGET_ARCH),armhf)
+ifneq (,$(filter %eabihf,$(DEB_TARGET_GNU_SYSTEM)))
   float_abi := hard
 else ifneq (,$(filter $(distribution)-$(DEB_TARGET_ARCH), Ubuntu-armel))
   ifneq (,$(filter $(distrelease),lucid maverick natty oneiric precise))
--- a/debian/rules2
+++ b/debian/rules2
@@ -483,7 +483,7 @@
   CONFARGS += --disable-sjlj-exceptions
   # FIXME: libjava is not ported for thumb, this hack only works for
   # separate gcj builds
-  ifneq (,$(filter armhf,$(DEB_TARGET_ARCH)))
+  ifneq (,$(filter %armhf,$(DEB_TARGET_ARCH)))
 ifeq ($(distribution),Raspbian)
   with_arm_arch = armv6
   with_arm_fpu = vfp

Bug#823893: libarchive: CVE-2016-1541

[Salvatore Bonaccorso]

Source: libarchive
Version: 3.1.2-11
Severity: grave
Tags: security upstream fixed-upstream
Justification: user security hole
Control: fixed -1 3.2.0-1

Hi,

the following vulnerability was published for libarchive.

CVE-2016-1541[0]:
| Heap-based buffer overflow in the zip_read_mac_metadata function in
| archive_read_support_format_zip.c in libarchive before 3.2.0 allows
| remote attackers to execute arbitrary code via crafted entry-size
| values in a ZIP archive.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-1541
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1541
[1] https://www.kb.cert.org/vuls/id/862384

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#823471: [pkg-go] Bug#823471: golang-github-miekg-pkcs11: please update to latest upstream snapshot

[Tianon Gravi]

On 4 May 2016 at 19:00, Potter, Tim (HPE Linux Support)
 wrote:
> I've already packaged this in the repo on alioth.

Once you've got a bug number assigned, be sure to update
"debian/changelog" to include "(Closes: #xxx)" as appropriate -- I've
done so here while reviewing your changes (which I'm preparing to
upload shortly), but as a note for the future. :)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#823217: libmouse-perl: Mouse generates a 'No package name defined' under ModPerl::Registry

[Xavier]

On 08/05/2016 12:53, Niko Tyni wrote:
> Control: tag -1 moreinfo
> 
> On Tue, May 03, 2016 at 06:00:08AM +0200, Xavier wrote:
>> On 02/05/2016 13:51, Xavier Guimard wrote:
>>> Package: libmouse-perl
>>> Version: 2.4.5-1+b1
>>> Severity: normal
> 
>>> When "use Mouse" is called under ModPerl::Registry, it provides a strange 
>>> "No
>>> package name defined" error. This bug affects only Debian testing, and is 
>>> not
>>> found under Ubuntu 15.10 and Debian stable. No such error using Moose.
> 
>> Here is a simple CGI test that fails :
> 
> Hi, thanks for the report. I can't reproduce your issue on current
> unstable with your example and this Apache configuration:
> 
>  
>  SetHandler perl-script
>  PerlHandler ModPerl::Registry
>  Options ExecCGI
>  
> 
> I just get the 'OK' output with this.
> 
> Can you please provide a simple Apache configuration that triggers it?

Hello,


it's a bit more complex (some Perl code was loaded). Here is an example
that reproduce the problem (the key is to load Mouse in a PerlModule
parameter and launch another Mouse code with ModPerl::Registry):

Apache.conf:

PerlModule My

ServerName test.example.com
# DocumentRoot
DocumentRoot /var/www/test

Require all granted
Options +ExecCGI +FollowSymLinks

# Perl script

SetHandler perl-script
PerlResponseHandler ModPerl::Registry



test.pl:

package main;
use CGI;
use My2;
my $q = CGI->new();
print $q->header( -type => 'text/html' );
print 'OK';

My.pm:

package My;
use strict;
use Mouse;
has a => ( is => 'rw' );
1;

My2.pm:

package My2;
use strict;
use Mouse;
has b => ( is => 'rw' );
1;

Bug#823892: fail2ban: Very slow startup time at boot

[Nelson A. de Oliveira]

Package: fail2ban
Version: 0.9.4-1
Severity: normal

I was seeing that fail2ban takes a long time to start when booting:

=
$ systemd-analyze blame
 10.775s fail2ban.service
(...)
=
(it's the top one)

=
$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @22.067s
└─multi-user.target @22.067s
  └─fail2ban.service @11.291s +10.775s
└─network.target @11.290s
  └─networking.service @7.942s +3.344s
└─local-fs.target @7.908s
  └─run-user-109.mount @21.426s
└─local-fs-pre.target @4.374s
  └─keyboard-setup.service @2.493s +1.880s
└─system.slice @2.445s
  └─-.slice @2.280s
=

Sometimes it takes 11 or 12 seconds.

Is there anything that I can do to gather more information or debug
this, please?

Thank you!

Best regards,
Nelson

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

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

Versions of packages fail2ban depends on:
ii  init-system-helpers  1.33
ii  lsb-base 9.20160110
pn  python3:any  

Versions of packages fail2ban recommends:
ii  iptables   1.6.0-2
ii  python 2.7.11-1
ii  python3-pyinotify  0.9.5-1
pn  python3-systemd
ii  whois  5.2.12

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-3
pn  monit
ii  rsyslog [system-log-daemon]  8.16.0-1+b3

-- Configuration Files:
/etc/fail2ban/jail.conf changed [not included]

-- debconf-show failed

Bug#823891: wget: segmentation fault when terminal width is small

[Shengjing Zhu]

Package: wget
Version: 1.17.1-1+b1
Severity: important

Dear Maintainer,

I find wget will segmentation fault when the terminal width is very
small.

For example, the terminal width is 27.

```
$ echo $COLUMNS
27
```

Then you try `wget www.debian.org `

You will get segmentation fault. I think the bug is related to the wget
progress bar. Becuase when you try `wget www.debian.org --quiet`, it's
OK.

Thanks

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

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

Versions of packages wget depends on:
ii  libc62.22-7
ii  libgnutls30  3.4.11-4
ii  libidn11 1.32-3
ii  libnettle6   3.2-1
ii  libpcre3 2:8.38-3.1
ii  libpsl0  0.11.0-2
ii  libuuid1 2.28-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages wget recommends:
ii  ca-certificates  20160104

wget suggests no packages.

-- no debconf information

Bug#822693: (no subject)

[bancfc]

Sorry my mailbox was overloaded with backlog.

You're right firecfg does everything I hoped for and survives package 
upgrades :)


However Iceweasel did not get symlinked because it was not recognized 
somehow so I asked netblue about it on Github.

Bug#823890: python-openbabel: doc-base error: openbabel and pybel already define html format

[Drew Parsons]

Package: python-openbabel
Version: 2.3.2+dfsg-2.2+b1
Severity: normal

Whenever a doc-base update is triggered (by any package), the
following error is thrown:

Processing triggers for doc-base (0.10.7) ...
Processing 2 changed doc-base files, 2 added doc-base files...
Error while merging /usr/share/doc-base/python-openbabel-openbabel with 
/usr/share/doc-base/python-openbabel-pybel: format html already defined.

The two files
  /usr/share/doc-base/python-openbabel-openbabel 
  /usr/share/doc-base/python-openbabel-pybel 
both come from python-openbabel.  

Apparently some field is not correct in these files.


-- 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.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-openbabel depends on:
ii  libc62.22-7
ii  libgcc1  1:6.1.1-1
ii  libopenbabel4v5  2.3.2+dfsg-2.2+b1
ii  libstdc++6   6.1.1-1
ii  python   2.7.11-1

python-openbabel recommends no packages.

python-openbabel suggests no packages.

-- no debconf information

Bug#823889: ITP: ws-butler -- unobtrusively remove trailing whitespace in Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: ws-butler
  Version : 0.3+git.a998a23
  Upstream Author : Le Wang
* URL : https://github.com/lewang/ws-butler/
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : unobtrusively remove trailing whitespace in Emacs

This package provides ws-butler-mode and ws-butler-global-mode.  Upon
saving a file in Emacs, these modes delete trailing whitespace on lines
of the buffer that have been edited.

As compared with simply calling delete-trailing-whitespace in your
before-save-hook, ws-butler has the advantage of not cluttering up
version control commits with whitespace cleanup outside of the part of
the file you have edited.

I am packaging version 0.3+git.a998a23 because since version 0.3
upstream has refactored ws-butler's code quite significantly.  I intend
to test it throughly on my own machine before fulfilling this ITP.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#823888: ITP: smex -- enhanced M-x interface for Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: smex
  Version : 3.0
  Upstream Author : Cornelius Mika  and contributors
* URL : https://github.com/nonsequitur/smex/
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : enhanced M-x interface for Emacs

> Smex is a M-x enhancement for Emacs. Built on top of Ido, it provides
> a convenient interface to your recently and most frequently used
> commands.

Smex is a very widely used Emacs addon that it would be nice to have in Debian.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#823887: ITP: parsebib -- Emacs Lisp library for parsing .bib files

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: parsebib
  Version : 1.0.5
  Upstream Author : Joost Kremers 
* URL : https://github.com/joostkremers/parsebib
* License : BSD-3-clause
  Programming Lang: Emacs Lisp
  Description : Emacs Lisp library for parsing .bib files

I am packaging this library as a dependency of ebib, another ITP of mine.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#823886: ITP: ebib -- BibTeX database manager for Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: ebib
  Version : 2.5.4
  Upstream Author : Joost Kremers 
* URL : http://joostkremers.github.io/ebib/
* License : BSD-2-clause
  Programming Lang: Emacs Lisp
  Description : BibTeX database manager for Emacs

A useful editor of .bib files for Emacs.  Integrates with LaTeX-mode.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#823689: hlibrary.mk: libghc-*-doc.links files not respected

[Sean Whitton]

Sorry, that last patch was idiotic.  Here's a better one.

This needs to be tested against a package for which DEB_ENABLE_HOOGLE is
significant.  I'm not familiar with how Hoogle organises its files, but
perhaps you have such a package in mind.

-- 
Sean Whitton
From 326cc49097ffcf9b8ff7683fac3eb19eaba57368 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Mon, 9 May 2016 18:47:22 -0700
Subject: [PATCH] Respect the user's debian/libghc-*-doc.links

---
 Dh_Haskell.sh| 6 +++---
 debian/changelog | 5 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/Dh_Haskell.sh b/Dh_Haskell.sh
index 1c187fd..5887aa8 100644
--- a/Dh_Haskell.sh
+++ b/Dh_Haskell.sh
@@ -351,7 +351,6 @@ clean_recipe(){
 run rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
 run rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
 run rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
-run rm -f debian/libghc-${CABAL_PACKAGE}-doc.links debian/libghcjs-${CABAL_PACKAGE}-doc.links
 if [ -f ${DEB_LINTIAN_OVERRIDES_FILE} ] ; then
   run sed -i '/binary-or-shlib-defines-rpath/ d' ${DEB_LINTIAN_OVERRIDES_FILE}
   run find ${DEB_LINTIAN_OVERRIDES_FILE} -empty -delete;
@@ -506,8 +505,9 @@ install_doc_recipe(){
 if [ "${DEB_ENABLE_HOOGLE}" = "yes" ]
 then
 run find debian/${PKG}/${htmldir} -name "*.txt" \
--printf "%p ${hoogle}/${PKG}.txt\n" >> debian/lib${hc}-${CABAL_PACKAGE}-doc.links
-run sed -i s,^debian/lib${hc}-${CABAL_PACKAGE}-doc,, debian/lib${hc}-${CABAL_PACKAGE}-doc.links
+-printf "%p ${hoogle}/${PKG}.txt" \
+| sed -i s,^debian/lib${hc}-${CABAL_PACKAGE}-doc,, debian/lib${hc}-${CABAL_PACKAGE}-doc.links \
+xargs dh_link
 fi
 run dh_haskell_depends -p${PKG}
 # PS4=$PS5
diff --git a/debian/changelog b/debian/changelog
index ef23643..f1b342f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,12 @@
 haskell-devscripts (0.10.2.4) UNRELEASED; urgency=medium
 
+  [ James McCoy ]
   * Fix “Unescaped left brace in regex” warnings in dh_haskell_blurbs.
 
+  [ Sean Whitton ]
+  * Respect user's debian/libghc-*-doc.links.  (Closes: #823689)
+Call dh_link rather than just overwriting debian/libghc-*-doc.links.
+
  -- James McCoy   Sun, 01 May 2016 11:01:02 -0400
 
 haskell-devscripts (0.10.2.3) unstable; urgency=medium
-- 
2.8.1



signature.asc
Description: PGP signature

Bug#823193: how-can-i-help: option to return failure on network errors

[Tomasz Nitecki]

tags 823193 + pending
thanks


Hey,

I've added a new option to ignore errors that is accessible by using
'--apt' option. From now on, it is the default option for the apt hook.
When running without this option, almost every ([1]) error will return
appropriate exit code.

[1] Import errors and option parse errors will still return 0, so that
we don't break apt (we don't know yet if we are getting called by apt
hook or not).


Regards and thanks for the report,
T.



signature.asc
Description: OpenPGP digital signature

Bug#807724: freedombox-setup: macchanger does not work

[James Valleroy]

On Wed, 20 Jan 2016 19:19:57 +0100 Petter Reinholdtsen 
wrote:
> While it sound like a good idea, it depend on when it is expected to
> show up in Debian if it is something we should wait for or not. Any
> idea when NM 1.2 will show up in Debian unstable? So far we have
> 1.0.10.

NM 1.2 is now in Debian testing and unstable.




signature.asc
Description: OpenPGP digital signature

Bug#817865: [Letsencrypt-devel] RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

Hi Harlan,

On Mon, May 09, 2016 at 08:24:55PM -0400, Harlan Lieberman-Berg wrote:
> It seems that there's a new upstream version that's a couple newer --
> .51.  Is that something worth updating to before you get sponsored?

You can upload the current git HEAD as is; as I wrote earlier the
Debian package already contains all security and important bug fixes
backported from version 0.0.51. Thanks!

Regards,
Peter

Bug#807580: [jstjohn/KentLib] Four files do contain old licensing statement (#2)

[Jim Kent]

Hmm, the license statements are like so on these 4:

/* hmmstats.h - Stuff for doing statistical analysis in general and

 * hidden Markov models in particular.

 *

 * This file is copyright 2000 Jim Kent, but license is hereby

 * granted for all use - public, private or commercial. */

not what is in the github note:

* Copyright (C) 2000 Jim Kent. This source code may be freely used *
* for personal, academic, and non-profit purposes. Commercial use *
* permitted only by explicit agreement with Jim Kent (jim_k...@pacbell.net)
*





On Mon, May 9, 2016 at 11:09 AM, Andreas Tille  wrote:

> Hi Jim,
>
> you probably remember my constant nagging abou the licensing of your
> library code.  Inside the bug report in Debian BTS[1] you mentioned MPL
> yourself.  Since I did not received any definitive answer stronger than
>
>"looking at Mozilla Public LIcense, ... I can release it under
> that as well."
>
> I was searching the web for potential new releases of the code.  I found
> something at Github which has only four files left with a non-free
> license and I mentioned this in the according bug report there[2].  From
> what I can see when inspecting the whole directory it looks pretty much
> like an unwanted leftover since all other files have later copyright and
> a free license.
>
> It would be really great if you could clarify this.
>
> Thanks a lot for your cooperation
>
> Andreas.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807580#112
> [2] https://github.com/jstjohn/KentLib/issues/2
>
> On Mon, May 09, 2016 at 08:56:16AM -0700, John St. John wrote:
> > Hi Andreas, this issue should be taken up directly with Jim Kent. If he
> gives the OK I am more than happy to update those problematic headers. This
> is not my code, so I am not sure what was intended between the conflicting
> statement in the README that was part of the Kent source tree at the time,
> and header comments in the individual libraries you mentioned.
> >
> > ---
> > You are receiving this because you authored the thread.
> > Reply to this email directly or view it on GitHub:
> > https://github.com/jstjohn/KentLib/issues/2#issuecomment-217906316
>
> --
> http://fam-tille.de
>

Bug#823885: [parley] Download new collections dialog fails

[Enrique Garcia]

Package: parley
Version: 4:15.08.3-1
Severity: normal



 The "Download new collections" dialog reports an error.
 Instead of displaying the list of available vocabularies there is an error 
message at the bottom reporting that "Loading of providers from file: 
http://edu.kde.org/parley/newstuff/providers44.xml failed"

 This is properly working with Parley 4:4.14.2-1in Debian Jessie.


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

Debian Release: stretch/sid
  500 testing ftp.de.debian.org 

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

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#823884: mount crashes via fstab entry

[Gene S]

Package: mount
Version: 2.25.2-6
Severity: important

Dear Maintainer,

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

Kernel: Linux 3.16.7-ckt9-5 (SMP w/4 CPU cores)
Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mount depends on:
ii  libc6  2.19-18+deb8u4
ii  libmount1  2.25.2-6
ii  libselinux12.3-2
ii  libsmartcols1  2.25.2-6

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common  

-- no debconf information

"mount /dvd" crashes, with the following line in /etc/fstab
  /dev/sr0  /dvd  udf,iso9660  user,noauto  0  0
where /dev/sr0 is a cd/dvd drive.

A command of the form "mount /dev/sr0 /mnt" works O.K.

Debug output to /var/log/kernlog follows, see below...

After the mount error exit, an attempt to "mount /dev/sr0 /mnt"
fails with "/dev/sr0 already mounted" message.  A "umount /dev/sr0"
fails with "/dev/sr0 not mounted" message.  The sr0 device is now
unreachable/unusable until after a system reboot.

kernlog (relevant lines) >>>

May  9 11:40:51 gene64 vmunix: [326817.943679] BUG: unable to handle kernel 
paging request at 
May  9 11:40:51 gene64 vmunix: [326817.943785] IP: [] 
udf_get_last_session+0x0/0x40 [udf]
May  9 11:40:51 gene64 vmunix: [326817.943860] PGD c01ef067 PUD 0 
May  9 11:40:51 gene64 vmunix: [326817.943958] Oops: 0002 [#1] SMP 
May  9 11:40:51 gene64 vmunix: [326817.944055] Modules linked in: udf 
nvidia_uvm(PO) cp210x usbserial joydev nvidia(PO) ohci_pci ohci_hcd
May  9 11:40:51 gene64 vmunix: [326817.944373] CPU: 2 PID: 16969 Comm: mount 
Tainted: P   O  3.16.7-ckt9-5 #5
May  9 11:40:51 gene64 vmunix: [326817.944423] Hardware name: BIOSTAR Group 
TA970/TA970, BIOS 4.6.4 01/14/2013
May  9 11:40:51 gene64 vmunix: [326817.944465] task: 8802250e1890 ti: 
8800c012 task.ti: 8800c012
May  9 11:40:51 gene64 vmunix: [326817.944515] RIP: 0010:[]  
[] udf_get_last_session+0x0/0x40 [udf]
May  9 11:40:51 gene64 vmunix: [326817.944596] RSP: 0018:8800c0123d70  
EFLAGS: 00010246
May  9 11:40:51 gene64 vmunix: [326817.944637] RAX:  RBX: 
8801e97a0580 RCX: 0428
May  9 11:40:51 gene64 vmunix: [326817.944686] RDX:  RSI: 
 RDI: 880209cc2000
May  9 11:40:51 gene64 vmunix: [326817.944735] RBP: 880209cc2000 R08: 
 R09: 8801e97a0580
May  9 11:40:51 gene64 vmunix: [326817.944784] R10: 5540 R11: 
01ea R12: 
May  9 11:40:51 gene64 vmunix: [326817.944833] R13: 0001 R14: 
a0867e50 R15: 880226049a40
May  9 11:40:51 gene64 vmunix: [326817.944882] FS:  7f65bf9a6840() 
GS:88022ed0() knlGS:f7707740
May  9 11:40:51 gene64 vmunix: [326817.944931] CS:  0010 DS:  ES:  CR0: 
8005003b
May  9 11:40:51 gene64 vmunix: [326817.944972] CR2:  CR3: 
16fab000 CR4: 000407a0
May  9 11:40:51 gene64 vmunix: [326817.945021] Stack:
May  9 11:40:51 gene64 vmunix: [326817.945059]  a0868238 
880226049b08 a0867e50 880226049a40
May  9 11:40:51 gene64 vmunix: [326817.945226]  811c95e9 
8802 8800c0123df0 8800c0123d00
May  9 11:40:51 gene64 vmunix: [326817.945396]   
  0428
May  9 11:40:51 gene64 vmunix: [326817.945563] Call Trace:
May  9 11:40:51 gene64 vmunix: [326817.945605]  [] ? 
udf_fill_super+0x3e8/0x630 [udf]
May  9 11:40:51 gene64 vmunix: [326817.945648]  [] ? 
udf_load_vrs+0x3c0/0x3c0 [udf]
May  9 11:40:51 gene64 vmunix: [326817.945692]  [] ? 
snprintf+0x39/0x40
May  9 11:40:51 gene64 vmunix: [326817.945735]  [] ? 
udf_load_vrs+0x3c0/0x3c0 [udf]
May  9 11:40:51 gene64 vmunix: [326817.945778]  [] ? 
mount_bdev+0x1a9/0x1e0
May  9 11:40:51 gene64 vmunix: [326817.945820]  [] ? 
mount_fs+0xc/0xc0
May  9 11:40:51 gene64 vmunix: [326817.945863]  [] ? 
vfs_kern_mount+0x5d/0x110
May  9 11:40:51 gene64 vmunix: [326817.945905]  [] ? 
do_mount+0x1df/0xab0
May  9 11:40:51 gene64 vmunix: [326817.945947]  [] ? 
memdup_user+0x33/0x60
May  9 11:40:51 gene64 vmunix: [326817.945989]  [] ? 
SyS_mount+0x9b/0x110
May  9 11:40:51 gene64 vmunix: [326817.946031]  [] ? 
system_call_fastpath+0x16/0x1b
May  9 11:40:51 gene64 vmunix: [326817.946073] Code: 00 00 00 00 00 00 00 50 2e 
8b e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 98 34 8b e0 
00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 
May  9 11:40:51 gene64 vmunix: [326817.948043] RIP  [] 
udf_get_last_session+0x0/0x40 [udf]
May  9 11:40:51 gene64 vmunix: [326817.948116]  RSP 
May  9 11:40:51 gene64 vmunix: [326817.948156] CR2: 
May  9 11:40:51 gene64 vmunix: [326817.948202] ---[ end trace 

Bug#823689: hlibrary.mk: libghc-*-doc.links files not respected

[Sean Whitton]

control: tag -1 +patch

Hello,

On Mon, May 09, 2016 at 04:59:33PM +0200, Joachim Breitner wrote:
> it runs
>     run rm -f debian/libghc-${CABAL_PACKAGE}-doc.links 
> debian/libghcjs-${CABAL_PACKAGE}-doc.links
> which in clean, which explains the problem, and writes to the file in
> the install target for the -dev package.
> 
>     if [ "${DEB_ENABLE_HOOGLE}" = "yes" ]
> then
> run find debian/${PKG}/${htmldir} -name "*.txt" \
> -printf "%p ${hoogle}/${PKG}.txt\n" >> 
> debian/lib${hc}-${CABAL_PACKAGE}-doc.links
> run sed -i s,^debian/lib${hc}-${CABAL_PACKAGE}-doc,, 
> debian/lib${hc}-${CABAL_PACKAGE}-doc.links
> fi
> 
> What is a saner way of doing this? Calling dh_link directly with all
> required links as arguments?

Thanks for tracking this down.  The attached patch seems to work (I've
tested it with my propellor package).

-- 
Sean Whitton
From a9c906582dbd572423059f9f1ea920d481e7fdec Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Mon, 9 May 2016 17:22:23 -0700
Subject: [PATCH] Respect the user's debian/libghc-*-doc.links

---
 Dh_Haskell.sh| 8 
 debian/changelog | 5 +
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/Dh_Haskell.sh b/Dh_Haskell.sh
index 1c187fd..beaf372 100644
--- a/Dh_Haskell.sh
+++ b/Dh_Haskell.sh
@@ -351,7 +351,6 @@ clean_recipe(){
 run rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
 run rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
 run rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
-run rm -f debian/libghc-${CABAL_PACKAGE}-doc.links debian/libghcjs-${CABAL_PACKAGE}-doc.links
 if [ -f ${DEB_LINTIAN_OVERRIDES_FILE} ] ; then
   run sed -i '/binary-or-shlib-defines-rpath/ d' ${DEB_LINTIAN_OVERRIDES_FILE}
   run find ${DEB_LINTIAN_OVERRIDES_FILE} -empty -delete;
@@ -505,9 +504,10 @@ install_doc_recipe(){
 run cp -r debian/tmp-inst-${hc}/${docdir}/*.haddock debian/${PKG}/${docdir}
 if [ "${DEB_ENABLE_HOOGLE}" = "yes" ]
 then
-run find debian/${PKG}/${htmldir} -name "*.txt" \
--printf "%p ${hoogle}/${PKG}.txt\n" >> debian/lib${hc}-${CABAL_PACKAGE}-doc.links
-run sed -i s,^debian/lib${hc}-${CABAL_PACKAGE}-doc,, debian/lib${hc}-${CABAL_PACKAGE}-doc.links
+links=`run find debian/${PKG}/${htmldir} -name "*.txt" \
+  -printf "%p ${hoogle}/${PKG}.txt\n" >> debian/lib${hc}-${CABAL_PACKAGE}-doc.links \
+  | sed -i s,^debian/lib${hc}-${CABAL_PACKAGE}-doc,, debian/lib${hc}-${CABAL_PACKAGE}-doc.links`
+run dh_link $links
 fi
 run dh_haskell_depends -p${PKG}
 # PS4=$PS5
diff --git a/debian/changelog b/debian/changelog
index ef23643..f1b342f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,12 @@
 haskell-devscripts (0.10.2.4) UNRELEASED; urgency=medium
 
+  [ James McCoy ]
   * Fix “Unescaped left brace in regex” warnings in dh_haskell_blurbs.
 
+  [ Sean Whitton ]
+  * Respect user's debian/libghc-*-doc.links.  (Closes: #823689)
+Call dh_link rather than just overwriting debian/libghc-*-doc.links.
+
  -- James McCoy   Sun, 01 May 2016 11:01:02 -0400
 
 haskell-devscripts (0.10.2.3) unstable; urgency=medium
-- 
2.8.1



signature.asc
Description: PGP signature

Bug#817865: [Letsencrypt-devel] RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Harlan Lieberman-Berg]

Peter Colberg  writes:
> Is there anybody among you who would have time to sponsor acmetool?

Hi Peter!

It seems that there's a new upstream version that's a couple newer --
.51.  Is that something worth updating to before you get sponsored?

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#823883: autodep8: Support PyPy packages

[Barry Warsaw]

Package: autodep8
Version: 0.5.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Currently autodep8 does a great job of adding simple import tests for
Python 2 and Python 3 packages.  It doesn't yet support PyPy though,
and as we add more support for PyPy in the archive, it would be nice
to get PyPy tests for free too.

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

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

Versions of packages autodep8 depends on:
ii  dctrl-tools  2.24-2
ii  python3  3.5.1-3

autodep8 recommends no packages.

autodep8 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXMSfFAAoJEBJutWOnSwa/ojIQALXBcswEuxWRRKo8KWv/8QUu
0x6EXLxOVNhd+u2km+8YGaQx3rB8wcg1mKpEWVfmncNHVXp3VTW0GkcLzTi0CFHV
rqDXiFeMjbcO9xOxfGoVVMZMB1tYRlPNahv58yc/ePYuaouWamxj3CeQ/KiW6fZU
h81galucUL7/1pkLXpkum3nQx/7D5X51J5MK35sF8XylP3+ozpIH7VuklA5Whu52
Jcxgos121XN1zuP93ZMgiGCjjpXIl9UdBnK30n0CNWtQgbcKwcgrOt/KXUddLn5Q
5NuH0dJc7Fd8oO3O9T2D4dyHSXCtbCllLXqyvOGovi3acNZuLB1GfNRrCop1ZiWd
bGWTbp8GnV/kRoYW+hYnzJI/2LlJi/qtRwboJcu9DipBQgQDu1bCf0tUPfzMzRhX
iaFCX+O20mcE71V1hhIYImpboQrtydxkurO+yuwdbAHda3alsK95CvABDtRPO14f
FR5ebMBJh2RDgLr6IECA6Y1/Gku8ndGezh34lqnNGxZ+b4cO4USZJ4GaJVEmdql8
wwNXJL/qdIsvxsz0Aoyeog4lC1brfnBWI7CSlzAGiY+O6Mhz1Lvp9RvolByVLlcI
1fTtxwd4PD5Nu6OTV4tiAAw7zl8Rz9fEVczHIhnNz8ZtduISWYPoksnu+VlSSPBa
w3xWFcS8MTpaIgJL8/Cr
=8DFJ
-END PGP SIGNATURE-

Bug#823882: bonnie++ -s 0 -n 1:-2:0:32 doesn't work

[sacrificial-spam-address]

Package: bonnie++
Version: 1.97.1+b1

If you ask for symlinks and subdirectories, bonnie++ creates
dangling symlinks and fails:

$ /usr/sbin/bonnie++ -d /tmp -s 0 -n 1:-2:0:32
Create files in sequential order...done.
Stat files in sequential order...Can't stat file 20P
Cleaning up test directory after error.

The criticial operations are:

22368 chdir("/tmp") = 0
22368 mkdir("./Bonnie.22368", 0700) = 0
22368 chdir("./Bonnie.22368")   = 0
22368 mkdir("0", 0700)  = 0
...
22368 mkdir("00031", 0700)  = 0
22368 open("0/00D", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
22368 symlink("0/00D", "0/01d6l5hxs") = 0
...
22368 symlink("0/00D", "0/20P") = 0
...
22368 symlink("0/00D", "00031/0003ffPO") = 0
22368 chdir("0")= 0
22368 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
22368 stat64("20P", 0xffb551b0) = -1 ENOENT (No such file or directory)

The problem is that /tmp/Bonnie.22368/0/20P is a symlink to
/tmp/Bonnie.22368/0/0/00D, which doesn't exist.


There are two obvious fixes, but I'm not sure which is preferred:
1) add "../" to the front of the symlink targets
2) create one real file per directory and remove the directory
   name from the symlink targets.

Bug#814770: pvm: FTBFS on sparc64 - Unknown architecture!

[James Clarke]

On Mon, Feb 15, 2016 at 10:41:37AM +0100, John Paul Adrian Glaubitz wrote:
> Looks like pvmgetarch [1] needs to be patched, although at first sight it 
> looks that
> $(uname -m) == sparc64 should be properly matched and therefore detected.

The Debian package overwrites lib/pvmgetarch to call debian/getpvmarch, which
doesn’t currently handle sparc64.

> Anyone wants to have a go at this, I can NMU the package if necessary.

Please see the (tiny!) attached debdiff (built successfully on u164.east.ru).

Regards,
James


pvm-sparc64.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#823881: dosfstools: mmd fails right after mkfs.msdos (sectors/tracks mismatch)

[Cyril Brulebois]

Package: dosfstools
Version: 4.0-1
Severity: serious
Tags: d-i
Justification: d-i build failure/regression, without blatant misusage from 
d-i's side

Control: affects -1 src:debian-installer

(Please keep debian-b...@lists.debian.org and debian-...@lists.debian.org
in the loop when replying.)

Hi,

The version bump from 3.0.28-2 to 4.0-1 led to a new FTBFS on all EFI
archs for debian-installer (amd64, arm64, i386), where the following
operations are happening:
| + mkfs.msdos -C ./tmp/netboot-gtk/grub_efi/efi.img 416
| mkfs.fat 4.0 (2016-05-06)
| + mmd -i ./tmp/netboot-gtk/grub_efi/efi.img ::efi
| Total number of sectors (832) not a multiple of sectors per track (63)!
| Add mtools_skip_check=1 to your .mtoolsrc file to skip this test
| + cleanup
| + [ -z efi-image.7vXUPq ]
| + rm -f efi-image.7vXUPq
| + [ -z efi-image.u4utfz ]
| + rm -rf efi-image.u4utfz
| config/x86.cfg:38: recipe for target 'x86_grub_efi' failed

This can be reproduced with:
| make -C build build_netboot-gtk USE_UDEBS_FROM=sid

after having added "set -x" at the top of build/util/efi-image in
src:debian-installer.

After a quick look, it seems the d-i build system is only passing a
number of blocks to mkfs.{msdos,fat}, without specifying strange
parameters for sectors or trackers, so it looks to me that mkfs's
or mmd's behaviour is buggy.

Incidently, 832 isn't a multiple of 63, but is a multiple of 64. Could
there be some off-by-one somewhere?

Switching on verbose mode (adding -v):
| + mkfs.msdos -v -C ./tmp/netboot-gtk/grub_efi/efi.img 416
| mkfs.fat 4.0 (2016-05-06)
| ./tmp/netboot-gtk/grub_efi/efi.img has 255 heads and 63 sectors per track,

| hidden sectors 0x;
| logical sector size is 512,
| using 0xf8 media descriptor, with 832 sectors;
| drive number 0x80;
| filesystem has 2 12-bit FATs and 4 sectors per cluster.
| FAT size is 1 sector, and provides 199 clusters.
| There is 1 reserved sector.
| Root directory contains 512 slots and uses 32 sectors.
| Volume ID is 0da76041, no volume label.
| + mmd -i ./tmp/netboot-gtk/grub_efi/efi.img ::efi
| Total number of sectors (832) not a multiple of sectors per track (63)!
| Add mtools_skip_check=1 to your .mtoolsrc file to skip this test
| + cleanup
| + [ -z efi-image.AQOJ9R ]
| + rm -f efi-image.AQOJ9R
| + [ -z efi-image.dShhUx ]
| + rm -rf efi-image.dShhUx
| config/x86.cfg:38: recipe for target 'x86_grub_efi' failed

Comparing with the previous version (downgrading to 3.0.28-2):
| + mkfs.msdos -v -C ./tmp/netboot-gtk/grub_efi/efi.img 416
| mkfs.fat 3.0.28 (2015-05-16)
| ./tmp/netboot-gtk/grub_efi/efi.img has 64 heads and 32 sectors per track,
^^^
| hidden sectors 0x;
| logical sector size is 512,
| using 0xf8 media descriptor, with 832 sectors;
| drive number 0x80;
| filesystem has 2 12-bit FATs and 4 sectors per cluster.
| FAT size is 1 sector, and provides 199 clusters.
| There is 1 reserved sector.
| Root directory contains 512 slots and uses 32 sectors.
| Volume ID is 1666ec2f, no volume label.
| + mmd -i ./tmp/netboot-gtk/grub_efi/efi.img ::efi
| + mmd -i ./tmp/netboot-gtk/grub_efi/efi.img ::efi/boot
| + mcopy -i ./tmp/netboot-gtk/grub_efi/efi.img efi-image.qksN5Q/bootx64.efi 
::efi/boot/bootx64.efi
| + grub-cpmodules ./tmp/netboot-gtk/grub_efi x86_64-efi
| + exit 0

It would be great if this could be investigated shortly, as I'd like to
prepare a new d-i release soon:
  https://lists.debian.org/debian-boot/2016/05/msg00055.html


KiBi.

Bug#823880: libsvm : binary files in source package

[Dominique Belhachemi]

Package: libsvm
Version: 3.12-1.1
Severity: serious

The source package contains binary files, see

https://sources.debian.net/src/libsvm/3.12-1.1/windows/
https://sources.debian.net/src/libsvm/3.12-1.1/java/


v3.12 is from 2012, please consider an update to a recent version (
https://github.com/cjlin1/libsvm/releases )

Bug#823879: allegro4.4: please make the build reproducible (locale)

[Daniel Shahaf]

Source: allegro4.4
Version: 2:4.4.2-5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that allegro4.4 could not be built reproducibly [2]: the members of
examples/source.tar.gz are sorted in a locale-dependent manner.

The following patch sorts that tarball's members in a fixed
(locale-independent) order:

[[[
diff --git a/debian/rules b/debian/rules
index a9ba95b..c1f9880 100755
--- a/debian/rules
+++ b/debian/rules
@@ -58,7 +58,9 @@ override_dh_auto_install:
 # Create examples source tar.gz
rm -rf build/tmp; mkdir build/tmp
cp examples/*.c examples/*.h examples/*.dat examples/*.pcx 
examples/*.txt examples/*.ini tests/*.c build/tmp/
-   cd build/tmp; GZIP="-9n" tar zcvf source.tar.gz --mtime="$(BUILD_DATE)" 
--mode=go=rX,u+rw,a-s *
+   # Glob expansions are sorted in a locale-sensitive manner; set the
+   # locale to make the order reproducible.
+   cd build/tmp && (LC_ALL=C; export LC_ALL; GZIP="-9n" tar zcvf 
source.tar.gz --mtime="$(BUILD_DATE)" --mode=go=rX,u+rw,a-s *)
cp build/tmp/source.tar.gz $(CURDIR)/debian/tmp/$(DOC_EXAMPLES_DIR)
 
 override_dh_makeshlibs:
]]]

I believe this patch should make allegro4.4 fully reproducible.

Thanks,

Daniel

 [1]: https://wiki.debian.org/ReproducibleBuilds
 [2]: 
https://tests.reproducible-builds.org/dbdtxt/unstable/amd64/allegro4.4_4.4.2-7.diffoscope.txt

Bug#823878: boinc-app-seti: change build dependency to libgsl-dev

[James Cowgill]

Source: boinc-app-seti
Version: 8.00~svn3363-2
Severity: normal

Hi,

The libgsl0-dev package has been renamed to libgsl-dev and has a
Provides field on the old package name to ease the transition. This
package should switch to use the new package name at some point.

Having said that, boinc-app-seti doesn't depend on gsl at runtime, and
I tried building it without libgsl-dev installed and it built fine.
Maybe gsl isn't needed at all?

Thanks,
James

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

Bug#823164: (no subject)

[Roland Hieber]

Inspired by [0] I tried to build gobject-introspection with the
following patch:

Index: gobject-introspection-1.48.0/gir/gobject-2.0.c
===
--- gobject-introspection-1.48.0.orig/gir/gobject-2.0.c
+++ gobject-introspection-1.48.0/gir/gobject-2.0.c
@@ -1947,7 +1947,7 @@
 /**
  * g_closure_invoke:
  * @closure: a #GClosure
- * @return_value: (optional) (out): a #GValue to store the return
+ * @return_value: (optional) (in): a #GValue to store the return
  *value. May be %NULL if the callback of @closure
  *doesn't return a value.
  * @n_param_values: the length of the @param_values array


... but this doesn't fix the problem with lua-lgi. So there must be
something else here.

[0]: https://github.com/pavouk/lgi/issues/132#issuecomment-202408015


 - Roland

Bug#823873: gnome-software: missing dependencies or setup for non-gnome desktops

[Matthias Klumpp]

2016-05-09 22:55 GMT+02:00 Stephen Liebbe :
> [...]
> wanted to try using gnome-software to replace aptitude as it draws in few 
> dependencies on non-gnome desktop (I use an Openbox-session started from 
> console
> with startx.) After install, program UI starts successfully. However, the 
> Software Sources menu item cannot change settings. To me it appears to have 
> something
> to do with gaining root permissions. The error output follows

Hi!
This output is super-weird:

> (gnome-software:16722): Gs-WARNING **: failed to open plugin 
> /usr/lib/gs-plugins-9/libgs_plugin_packagekit-origin.so: 
> /usr/lib/gs-plugins-9/libgs_plugin_packagekit-origin.so: undefined symbol: 
> gs_plugin_packagekit_results_valid

This indicates a version mismatch between GS and the plugins. This can
only happen if you did install GS from sources other than Debian. Did
you maybe have an Ubuntu package in there, or did compile and make
install the software manually in the past? If so, you would need to
clean up the remnants of that old installation.

> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
> transmission: Icon 'transmission' not present in theme (null)
>
> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
> scribus: Icon 'scribus' not present in theme (null)
>
> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
> transmission: Icon 'transmission' not present in theme (null)
>
> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
> mypaint: Icon 'mypaint' not present in theme (null)
>
> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon gimp: 
> Icon 'gimp' not present in theme (null)
>
> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
> mypaint: Icon 'mypaint' not present in theme (null)
>
> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
> blender: Icon 'blender' not present in theme (null)
>
> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon gimp: 
> Icon 'gimp' not present in theme (null)
>
> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
> blender: Icon 'blender' not present in theme (null)
>
> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
> scribus: Icon 'scribus' not present in theme (null)
>
> (gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
> gnucash-icon: Icon 'gnucash-icon' not present in theme (null)
>
> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'scribus' not present in theme (null)
>
> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'mypaint' not present in theme (null)
>
> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'gimp' not present in theme (null)
>
> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'blender' not present in theme (null)

These are harmless and can be ignored.

> (gnome-software:16722): Gs-WARNING **: hiding recommended applications: found 
> only 4 to show, need at least 8

This indicates an issue with the AppStream metadata - does running
`sudo appstreamcli refresh --force` help?

> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'transmission' not present in theme (null)
>
> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'mypaint' not present in theme (null)
>
> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'gimp' not present in theme (null)
>
> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'blender' not present in theme (null)
>
> (gnome-software:16722): Gtk-WARNING **: Theme parsing error: :5:28: The 
> style property GtkWidget:focus-padding is deprecated and shouldn't be used 
> anymore. It will be removed in a future version
>
> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'transmission' not present in theme (null)
>
> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'scribus' not present in theme (null)
>
> (gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
> icons: Icon 'gnucash-icon' not present in theme (null)

These issues can be ignored.

> (gnome-software:16722): GLib-CRITICAL **: g_hash_table_get_values: assertion 
> 'hash_table != NULL' failed

This looks very strange, likely a bug.

> ERROR:root:Cannot import UbuntuDrivers: No module named 'UbuntuDrivers'
> ERROR:root:Authentication canceled, changes have not been saved

This is a message from software-properties-gtk, which is independent
from GS. We should likely make GS recommend it though, since s-p is
the superior dialog for editing software sources over what GS 

Bug#790801: txt2man: please support timestamps from environment

[Mattia Rizzolo]

On Mon, May 09, 2016 at 07:33:22PM -0300, Eriberto wrote:
> I am reviewing all my packages gradually. I will review txt2man soon
> (I will give priority to txt2man).

Thanks in advance! :)

-- 
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#790801: txt2man: please support timestamps from environment

[Eriberto]

Hi Mattia,

I am reviewing all my packages gradually. I will review txt2man soon
(I will give priority to txt2man).

Regards,

Eriberto


2016-05-09 19:25 GMT-03:00 Mattia Rizzolo :
> On Wed, Jul 01, 2015 at 10:30:32PM +0200, Reiner Herrmann wrote:
>> When no explicit date is specified on the command line, txt2man currently 
>> embeds
>> the current time into generated manpages.
>> For the Reproducible Builds effort we are proposing an environment variable 
>> [1],
>> that will contain a deterministic epoch timestamp (based on the latest 
>> debian/changelog
>> entry) that could be used.
>> We hope that it will soon be automatically exported by debhelper.
>> With the attached patch packages using txt2man would then automatically 
>> generate
>> reproducible manpages (instead of having to adapt each package to 
>> explicitely pass a
>> timestamp).
>
> Since several months debhelper exports this variable, and it's gaining a
> lot of adoptions.
> Currently we are keeping this package patched in our custom repository,
> but that's clearly sub-optimal.
>
> I wonder, would you mind doing an upload with this patch applied? :)
>
> Note that it has been also "applied" upstream (if you can say that for a
> git repository not updated in years and then this...).
>
> --
> 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  `-

Bug#823877: dpkg-buildflags: please allow PIE on kfreebsd

[Steven Chamberlain]

Package: dpkg-dev
Version: 1.18.6
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd

Hi Guillem,

Please allow dpkg-buildflags to use PIE on kfreebsd.  Due to an ancient
bug (#430455) it remains disabled.  But kfreebsd-10, -9 and probably -8
support PIE binaries.

kfreebsd (upstream kernel) doesn't implement ASLR yet, but when it does,
I'd like as many binaries as possible to be already compiled as PIE.

Thanks a lot!

--- a/scripts/Dpkg/Vendor/Debian.pm 2016-05-09 08:56:46.0 +
+++ b/scripts/Dpkg/Vendor/Debian.pm 2016-05-09 22:06:52.743169571 +
@@ -271,9 +271,8 @@
 $self->_parse_feature_area('hardening', \%use_feature);
 
 # Mask features that are not available on certain architectures.
-if ($os !~ /^(?:linux|knetbsd|hurd)$/ or
+if ($os !~ /^(?:linux|kfreebsd|knetbsd|hurd)$/ or
$cpu =~ /^(?:hppa|avr32)$/) {
-   # Disabled on non-linux/knetbsd/hurd (see #430455 and #586215).
# Disabled on hppa, avr32
#  (#574716).
$use_feature{pie} = 0;

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#794933: Info received ()

[Sami Abbessi]

Le 9 mai 2016 23:27, "Debian Bug Tracking System"  a
écrit :

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Apache Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 794...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 794933: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794933
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#790801: txt2man: please support timestamps from environment

[Mattia Rizzolo]

On Wed, Jul 01, 2015 at 10:30:32PM +0200, Reiner Herrmann wrote:
> When no explicit date is specified on the command line, txt2man currently 
> embeds
> the current time into generated manpages.
> For the Reproducible Builds effort we are proposing an environment variable 
> [1],
> that will contain a deterministic epoch timestamp (based on the latest 
> debian/changelog
> entry) that could be used.
> We hope that it will soon be automatically exported by debhelper.
> With the attached patch packages using txt2man would then automatically 
> generate
> reproducible manpages (instead of having to adapt each package to explicitely 
> pass a
> timestamp).

Since several months debhelper exports this variable, and it's gaining a
lot of adoptions.
Currently we are keeping this package patched in our custom repository,
but that's clearly sub-optimal.

I wonder, would you mind doing an upload with this patch applied? :)

Note that it has been also "applied" upstream (if you can say that for a
git repository not updated in years and then this...).

-- 
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#794933:

[Sami Abbessi]

Bug#823876: atlc: change build dependency to libgsl-dev

[James Cowgill]

Source: atlc
Version: 4.6.1-1
Severity: normal
Tags: sid stretch

Hi,

The libgsl0-dev package has been renamed to libgsl-dev and has a
Provides field on the old package name to ease the transition. This
package should switch to use the new package name at some point.

Having said that, atlc doesn't depend on gsl at runtime, and I tried
building it without libgsl-dev installed and it built fine. Maybe gsl
isn't needed at all?

Thanks,
James

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

Bug#804531: eagle: cannot be rebuilt against libssl1.0.2

[Sebastian Andrzej Siewior]

On 2016-04-22 00:19:58 [+0200], Andreas Beckmann wrote:
> Since the only API/ABI difference between libssl1.0.0 and libssl1.0.2 is
> the removal of some symbols, you could try the following:
…

| $ readelf -a bin/eagle|grep -i SSLv3
|09aa3640  00019607 R_386_JUMP_SLOT      SSLv3_client_method
|09aa36ec  0001c207 R_386_JUMP_SLOT      SSLv3_server_method
|   406:  0 FUNCGLOBAL DEFAULT  UND SSLv3_client_method
|   450:  0 FUNCGLOBAL DEFAULT  UND SSLv3_server_method

Haven't tried it but it seems that the binary uses the removed symbols.

Besides I looked at the license [0]:
- 2.1.b says "not to … vary or modify the Software" so I think the
  change of libssl1.0.0 -> .2 is not permitted.
- 2.1.c says "… nor permit the Software or any part of it to be  combined
  with, or become incorporated in, any other programs;" which sounds
  like redistribution is not allowed
- 2.1.i puts it this way: "not to provide or otherwise make available
  the Software in whole or in part … in any form to any person … without
  prior written consent from the Licensor.".

Redistributing may be allowed due to the chapter in debian/copyright. It
is not the latest [1] available document which might be "recent" and the
license seems to have change a little, too.

[0] https://sources.debian.net/src/eagle/7.5.0-1/doc/license_en.txt/
[1] 
http://www.cadsoftusa.com/fileadmin/journalist/Documents/redistribute-eagle-freeware-letter.odt

> Andreas

Sebastian

Bug#799953: gcc-4.9: incorrect double to integer conversion on i386

[Uoti Urpala]

On Tue, 17 Nov 2015 13:47:29 +0100 Miroslav Urbanek  
wrote:
> > What's the result type of float * int ? Definitively not double, but
> > float. (Just the intermediate result in the x87 fpu has extended
> > precision.)
> 
> True, according to C11 standard, section 6.3.1.8, the result type of
> float * int is float.

You seem to misunderstand the consequences of this fact.


> > So I don't think the compiler is wrong considering d and g to
> > contain the same information, since the same *float* value was

> I think the compiler is wrong. C11 standard, section 6.5.1, says:
> 
> "The type of an assignment expression is the type the left operand
> would have after lvalue conversion."

This is true, but you don't seem to understand what it actually means.
Yes, the type of the assignment expression is double. But it's a value
converted from float, and the calculation in floats may already have or
have not lost precision prior to that conversion.

 
> I couldn't find any GNU extensions that change arithmetic conversion
> rules.

The switch you failed to find is likely -fexcess-precision ("enabled by
default for C if a strict conformance option such as -std=c99 is
used").


> The bug PR323 is caused by excess precision of some
> values. Here, it's the opposite case. Value in d is double, but in the
> expression "int i = d", GCC uses a floating approximation to this
> value, which has obviously lower precision. I think it's clearly a
> bug.

No, it is not in any sense "opposite". Your test code calculates
"f*atoi(argv[1])" at float precision. That any following calculation
based on that value may use more precision than a standard float is an
example of excess precision, exactly the known issue in PR323.

In summary: I don't think there is anything new or unexpected here.
Overall this behavior is just another example of the well-known excess
precision issue. This bug report should likely be closed without any
other action.

Bug#820149: [#820149] Fixed by uploading newer upstream version

[Potter, Tim (HPE Linux Support)]

This FTBFS should be fixed by the upload of the newer version in #812838.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822617: Missing symlinks to match locales

[Gunnar Hjalmarsson]

Time goes by, and I have now sought sponsorship in Ubuntu for my
proposed changes, including dropping the hunspell-gl binary.

Can't help wondering, though, if a better long-term solution would be
possible.

Rene, you called my attention to the fact that LO ships its own set of
locale data, and that it does not include any el_CY locale. I then
noticed that if I start LO with the el_CY.UTF-8 locale, el_GR.{aff,dic}
and hyph_el_GR.dic are recognized. LO notices that it's a "Greek" locale
without bothering about the country code.

However, if I start LO with the it_CH.UTF-8 locale, it_IT.{aff,dic} and
hyph_it_IT.dic are not recognized. In this case LO does care about the
country code, and look for (the non-existing) it_CH.{aff,dic} and
hyph_it_CH.dic.

So, what's the difference?

$ ls -1 i18npool/source/localedata/data/el_*
i18npool/source/localedata/data/el_GR.xml
$ ls -1 i18npool/source/localedata/data/it_*
i18npool/source/localedata/data/it_CH.xml
i18npool/source/localedata/data/it_IT.xml

While there is only one Greek LO locale, there are two Italian LO
locales. Is that the simple explanation? If it is, would it be possible
to patch LO somehow to behave differently?

-- 
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#823849: RFS: opengrm-ngram/1.2.2-1 -- opengrm n-gram library

[Jakub Wilk]

* Giulio Paci , 2016-05-09, 17:40:

git://anonscm.debian.org/collab-maint/opengrm-ngram.git


Let me see:


+  * Import Upstream version 1.2.2.
+(Closes: #707826)


This sounds as if #707826 was a request to package new upstream release.


+- replace automake1.13 with automake


This is inaccurate: the previous version has build-depends on 
automake1.11.


+  * Refresh 1005_fix_libraries_linking.patch and 
+1002_remove_bashisms.patch.


I wouldn't call changes to 1002_remove_bashisms.patch a "refresh". The 
content of the patch is now radically different.



+  * Drop 1003_fix_spelling.patch and 1004_fix_ngram_h_file.patch.


If you are dropping them because they were applied upstream, then please 
say so explicitly.



+  * Change Section from text to science.


Note that updating d/control is not enough to convince dak that the 
package is in the new section. After the upload, you'll have to file a 
bug against ftp.d.o to update it. (Use "reportbug ftp.debian.org", then 
choose "override".)



+ Running tests in parallel with make resulted in many tests
+ failure, due to several file access race conditions. This


Typo: failure -> failures

Typo in NEWS:
Compatability -> Compatibility

--
Jakub Wilk

Bug#823875: maven-repo-helper: POMReader does not expand parent properties

[Christopher Hoskin]

Package: maven-repo-helper
Version: 1.8.12
Severity: wishlist

Dear Maintainer,

POMReader contains a function expandProperties which expands any properties 
infered or specified in the POM into GroupId, ArtifactId, Type and Version for 
each dependancy. However, POMReader does not appear to expand properties 
defined in parent or grandparent POMs. For example, in qpid-java, 
broker-core/pom.xml contains the fragments

  
org.apache.qpid
qpid-java-build
6.0.2
  

  ...


  com.fasterxml.jackson.core
  jackson-core
  ${fasterxml-jackson-version}


But the property fasterxml-jackson-version is defined in the parent POM.

Ideally POMReader would be able to handle this situation.

Thanks.

Christopher Hoskin

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

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

Versions of packages maven-repo-helper depends on:
ii  default-jre-headless [java2-runtime-headless]2:1.8-57
ii  libstax-java 1.2.0-3
ii  openjdk-8-jre-headless [java2-runtime-headless]  8u91-b14-2

Versions of packages maven-repo-helper recommends:
ii  debhelper  9.20160403

Versions of packages maven-repo-helper suggests:
ii  maven-debian-helper  2.0.7

-- no debconf information

Bug#797999: tested today with qt 5.6 : bug is still there (balck scree, when docked on external monotor with lid closed)

[Eric Valette]

Still no fix with qt 5.6 or sddm...

-- eric

Bug#813316: pstoedit: output formats no longer include plot-svg

[James Cowgill]

Control: tags -1 patch pending

Hi Roland,

Since this bug is rather annoying and has contributed to the calligra
FTBFS situation, I intend to NMU it.

I have uploaded the attached NMU to DELAYED/5, based on Peter Green's
patch. Please tell me if you want me to cancel it.

Thanks,
Jamesdiff -Nru pstoedit-3.70/debian/changelog pstoedit-3.70/debian/changelog
--- pstoedit-3.70/debian/changelog	2016-01-22 12:50:20.0 +
+++ pstoedit-3.70/debian/changelog	2016-05-09 22:32:43.0 +0100
@@ -1,3 +1,13 @@
+pstoedit (3.70-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Peter Michael Green ]
+  * Disable broken if-check in plugin load code so that plugins can be
+successfully loaded from PSTOEDITLIBDIR. (Closes: #813316)
+
+ -- James Cowgill   Mon, 09 May 2016 22:31:45 +0100
+
 pstoedit (3.70-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru pstoedit-3.70/debian/patches/05-fix-plugin-loading.patch pstoedit-3.70/debian/patches/05-fix-plugin-loading.patch
--- pstoedit-3.70/debian/patches/05-fix-plugin-loading.patch	1970-01-01 01:00:00.0 +0100
+++ pstoedit-3.70/debian/patches/05-fix-plugin-loading.patch	2016-04-23 15:09:25.0 +0100
@@ -0,0 +1,22 @@
+Description:  Disable broken if-check in plugin load code so that plugins  can be successfully loaded from PSTOEDITLIBDIR.
+ The plugin load code was checking pluginsloaded before trying to load plugins from PSTOEDITLIBDIR
+ Unfortunately code further up in the method sets pluginsloaded even if no plugins were found in
+ previous places. This patch restores the old 3.62 behaviour of not checking pluginsloaded before
+ searching for plugins in PSTOEDITLIBDIR.
+Bug-Debian: http://bugs.debian.org/813316
+--- a/src/pstoedit.cpp
 b/src/pstoedit.cpp
+@@ -282,11 +282,11 @@ static void loadpstoeditplugins(const ch
+ 	}
+ 
+ #ifdef PSTOEDITLIBDIR
+-	if (!pluginsloaded) {
++	//if (!pluginsloaded) {
+   	  // also try to load drivers from the PSTOEDITLIBDIR
+ 	  loadPlugInDrivers(PSTOEDITLIBDIR, errstream,verbose);
+ 	  pluginsloaded = true;
+-	}
++	//}
+ #endif
+ 
+ 	// delete[]plugindir;
diff -Nru pstoedit-3.70/debian/patches/series pstoedit-3.70/debian/patches/series
--- pstoedit-3.70/debian/patches/series	2016-01-22 15:03:54.0 +
+++ pstoedit-3.70/debian/patches/series	2016-04-23 15:08:44.0 +0100
@@ -2,3 +2,4 @@
 02-errors-to-stderr.patch
 03-doc-remove-nonfree-options.patch
 04-fix-obsolete-LIBPNG_LDFLAGS.patch
+05-fix-plugin-loading.patch


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

Bug#822755: Tested on two more computers with identical pkg selection criteria : bug is everywhere

[Eric Valette]

So I hardly think this is not widely reproducible provided you have 
unstable + experimental up-to-date combination.


-- eric

Bug#820860: Fun with co-existing mutually conflicting Essential packages, again

[Thorsten Glaser]

Hi *, (XTaran and Klaus informed in separate German mail)

just got pointed to this by XTaran. David, sorry that this pops up
in your domain again, but doing it right i̲s̲ hard, even though it
“should” work, from just the .deb package format anyway.

@all: this is related to #806422 which is just the opposite problem.

Last time I tried, Important (instead of Essential) was not enough
to make dash-mksh installable in the first place and/or it got
removed in the next apt run. But that was before we had the workaround
from #806422 (the preferences.d file) in place.

I’ll retry whether using Important instead of Essential can work
in both jessie and sid, with apt (not aptitude).

David, if you have an idea how this can be achieved with less
trouble, be sure to share ;-)

Thanks,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#823812: netbeans: non-free files

[Markus Koschany]

Hi,

Am 09.05.2016 um 12:11 schrieb Dmitry Smirnov:
> Source: netbeans
> Version: 8.1+dfsg2-3
> Severity: serious
> Usertags: dfsg
> 
> Files:
> cnd/javahelp/org/netbeans/modules/cnd/help/legal_notice.htm
> 
> javacard.project/javahelp/org/netbeans/modules/javacard/project/docs/help/docinfo.html
> 
> Contain fairly restrictive license:
> 
> 
> Except as expressly permitted in your
> license agreement or allowed by law, you may not use, copy, reproduce,
> translate, broadcast, modify, license, transmit, distribute, exhibit,
> perform, publish, or display any part, in any form, or by any means.
> Reverse engineering, disassembly, or decompilation of this software, unless
> required by law for interoperability, is prohibited.

It sounds scary but the first part of the sentence is important:

"Except as expressly permitted in your license agreement..."

The license agreement is GPL-2+-with-classpath-exception or CDDL-1

> 
> Those terms seems to apply to other files in respective directories.
> 
> File:
> 
> java.sourceui/test/unit/src/org/netbeans/api/java/source/ui/FileChooser.html
> 
> is explicitly licensed under those terms.

FileChooser.html does not contain a specific license grant. There are
more files under ui but those contain the standard license headers,
GPL-2+-with-classpath-exception or CDDL-1

> 
> 
> 
> File:
> 
> javascript2.extjs/test/unit/data/testfiles/completion/applyMethod/ClassManager.js
> 
> contains the following:
> 
> 
> Licensees holding valid commercial licenses may use this file in accordance 
> with the Commercial
> Software License Agreement provided with the Software or, alternatively, in 
> accordance with the
> terms contained in a written agreement between you and Sencha.
> 
> 
> However no other license is mentioned.

That's true and I wished upstream would be more careful about this.
However this file is part of the ExtJS framework from Sencha and is also
licensed under the GPL-3. I will update debian/copyright accordingly.



> 
> 
> 
> Files:
> j2ee.dd/src/org/netbeans/modules/j2ee/dd/impl/resources/web-app_2_3.dtd
> 
> j2ee.ddloaders/src/org/netbeans/modules/j2ee/ddloaders/catalog/resources/web-app_2_3.dtd
> 
> j2ee.sun.dd/src/org/netbeans/modules/j2ee/sun/dd/impl/resources/static-verification_1_4.dtd
> 
> j2ee.weblogic9/src/org/netbeans/modules/j2ee/weblogic9/resources/ejb-jar_2_1.xsd
> 
> j2ee.weblogic9/src/org/netbeans/modules/j2ee/weblogic9/resources/j2ee_1_4.xsd
> 
> j2ee.weblogic9/src/org/netbeans/modules/j2ee/weblogic9/resources/j2ee_web_services_client_1_1.xsd
> 
> j2ee.weblogic9/src/org/netbeans/modules/j2ee/weblogic9/resources/jsp_2_0.xsd
> 
> j2ee.weblogic9/src/org/netbeans/modules/j2ee/weblogic9/resources/web-app_2_4.xsd
> schema2beans/test/unit/data/TestApplication1_4.xsd
> schema2beans/test/unit/data/TestFinalWebApp.xsd
> schema2beans/test/unit/data/TestWebApp.xsd
> schema2beans/test/unit/data/TestWebAppDelegator.xsd
> schema2beans/test/unit/data/TestWebAppDelegatorBaseBean.xsd
> schema2beans/test/unit/data/final_j2ee_1_4.xsd
> schema2beans/test/unit/data/final_jsp_2_0.xsd
> schema2beans/test/unit/data/j2ee_1_4.xsd
> schema2beans/test/unit/data/j2ee_web_services_client_1_1.xsd
> schema2beans/test/unit/data/jsp_2_0.xsd
> web.core/src/org/netbeans/modules/web/taglib/resources/j2ee_1_4.xsd
> 
> web.core/src/org/netbeans/modules/web/taglib/resources/j2ee_web_services_client_1_1.xsd
> 
> web.core/src/org/netbeans/modules/web/taglib/resources/web-jsptaglibrary_2_0.xsd
> 
> 
>  This document and the technology which it describes are
>  distributed under licenses restricting their use, copying,
>  distribution, and decompilation. No part of this document
>  may be reproduced in any form by any means without prior
>  written authorization of Sun and its licensors, if any.
> 

Sun Microsystems was bought by Oracle a few years ago. The schema
resources / specifications are licensed under the standard license now. See

http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html

and download some of the files to verify this statement.


> 
> Same terms are also present in the following files, under
> "CDDL or GPL-2 and exception-GPL-Classpath" header:
> 
> Files:
> web.jsf/src/org/netbeans/modules/web/jsf/resources/javaee_5.xsd
> 
> web.jsf/src/org/netbeans/modules/web/jsf/resources/javaee_web_services_client_1_2.xsd
> web.jsf/src/org/netbeans/modules/web/jsf/resources/web-facesconfig_1_2.xsd
> web.jsf/src/org/netbeans/modules/web/jsf/resources/web-facesconfig_2_0.xsd
> 
> 

See above

> 
> File:
> php.editor/test/unit/data/testfiles/parser/performance/performance.php
> 
> is from "SMF 1.1" which is non-free according to
> 
> http://www.simplemachines.org/about/opensource.php
> 
> 
>  The license used for SMF 1.0 and SMF 1.1 is more restrictive than OSI
>  approved licenses. That 

Bug#787279: d-i screen blanking (more info)

[Philip Hands]

Hi,

I bumped into this issue when doing install tests under jenkins, and can
confirm that the dpms=false setting does not disable the screen blanking
on e.g. debian-8.4.0-amd64-netinst.iso

It seems that Xorg now has a -s option:

  -s #   screen-saver timeout (minutes)

setting this to 0 appears to have solved the problem, by disabling
screen-blanking for the graphical install.

It's possible to work around this problem (in a somewhat kludgy manner)
by NOT setting dpms, and instead adding this to the command
line/preseed:

  preseed/early_command="echo DPMS=-s 0 > 
/lib/debian-installer.d/S61Xnoblank"

(the  is probably an artefact of the way that I'm specifying this in
a ruby script, inside single quotes, so you probably only need a couple
of backslashes -- whatever it takes to get '-s\ 0' into the file.  This
works because it sets the DPMS environment variable which then gets used
as is in the Xorg command line as long as dpms is not also set on the
kernel command line.

In order to make the dpms stuff work again in future versions I'd think
that screen-blanking is really not helpful during install, so would set
DPMS="-s 0" or perhaps DPMS="-s 0 -dpms", by default, and also make it
so that is what's set when dpms=false is specified.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#823474: RFS: btrfs-progs/4.5.2-0.1~exp1

[Nicholas D Steeves]

On 9 May 2016 at 13:18, Gianfranco Costamagna  wrote:
>>Per https://wiki.debian.org/ftpmaster_Removals , I filed Bug #823848
>>"as an RC bug on the package".
>
> I have reassigned it to ftpmasters, I don't think there is need to wait for
> the maintainer opinion, this is a binary without source.

Thank you.

>>I did two runs of license-reconsile, after fixing the MIT/X11 license
>>issue for config/install-sh.  In the first run I kept the existing
>>GPL-2+ designations; wc -l returned 212 lines.  For the second run I
>>changed most instances of GPL-2+ to GPL-2; wc -l returned 126.  Based
>>on this, and the fact that the official btrfs-progs*/COPYING file
>>states:
>
> I see README.md saying this is GPL-2, so you might want to change to GPL-2
> and list all the GPL-2+ files explicitly.

Done.  I did a couple of nme runs in a sid chroot, and then fixed
lintian errors.  It might be possible to compact the debian/copying
stanza, but my goal was maximum correctness so I didn't take any
risks.  Lintian said that copyright entries for config/* weren't
necessary.  Is this true?  I removed them on the assumption that they
were.

>>Thank you for notifying me of this Gianfranco.  It also affects>oldstable and
>>stable.  Is this an RC/serious level bug for all affected versions?
>
> BTW this might be RC, but I'm not sure it is worth fixing it in stable.
>
> I'll wait for some more appropriate answer here maybe :)

Ok, I'll wait too. :-)

Updated package has been uploaded to the same location.  If
successfully completing a license review/update isn't on a
debian-mentorship checklist, then it really ought to be!  Thank you
for the opportunity to learn something of fundamental importance to
the Debian-way of doing things.

One more concern:  E - Package closes bugs in a wrong way.  Bug
#801192 does not belong to this package.  I know this is a "teaching
moment."  What is the correct way to tag #801192 (owned by
btrfs-tools) so that it can be closed by btrfs-progs?  I'd like to
send the email to control@ myself, and I suspect this needs to be done
before you upload this package. ;-)

Cheers,
Nicholas

Bug#823874: diffoscope: UnicodeDecodeError

[Mattia Rizzolo]

Source: diffoscope
Version: 52

Seen on rb.d.n with:
 - openocd/0.9.0-1 (all suites/archs)
 - psychtoolbox-3/3.0.12.20160414.dfsg1-1 (unstable/armhf)
 - publican/4.3.2-1 (all suites/archs)

Fri May  6 07:44:58 UTC 2016 - diffoscope 52 will be used to compare the two 
builds:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/diffoscope/__main__.py", line 177, in 
main
sys.exit(run_diffoscope(parsed_args))
  File "/usr/lib/python3/dist-packages/diffoscope/__main__.py", line 148, in 
run_diffoscope
parsed_args.file1, parsed_args.file2)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", 
line 97, in compare_root_paths
return compare_files(file1, file2)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", 
line 113, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 
199, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 
174, in _compare_using_details
details.extend(filter(None, self.as_container.compare(other.as_container)))
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", 
line 116, in compare_commented_files
difference = compare_files(file1, file2, source=source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", 
line 113, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 
199, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 
174, in _compare_using_details
details.extend(filter(None, self.as_container.compare(other.as_container)))
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", 
line 116, in compare_commented_files
difference = compare_files(file1, file2, source=source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", 
line 113, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 
199, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 
174, in _compare_using_details
details.extend(filter(None, self.as_container.compare(other.as_container)))
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", 
line 116, in compare_commented_files
difference = compare_files(file1, file2, source=source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", 
line 113, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 
199, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 
174, in _compare_using_details
details.extend(filter(None, self.as_container.compare(other.as_container)))
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", 
line 116, in compare_commented_files
difference = compare_files(file1, file2, source=source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", 
line 113, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 
199, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 
172, in _compare_using_details
details.extend(filter(None, self.compare_details(other, source)))
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line 
128, in compare_details
self.path, other.path, source="line order")]
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 330, in 
from_text_readers
*args, **kwargs)
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 303, in 
from_feeder
unified_diff = diff(feeder1, feeder2)
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 272, in 
diff
return run_diff(fd1, fd2, end_nl_q1, end_nl_q2)
  File "/usr/lib/python3.5/contextlib.py", line 66, in __exit__
next(self.gen)
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 207, in 
fd_from_feeder
t.join()
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 185, in 
join
raise ex
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 171, in 
run
super().run(*args, **kwargs)
  File "/usr/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 192, in 
feed

Bug#806377: debirf : libfakechroot version 2.18-1 from sid is needed - even on jessie

[Daniel Kahn Gillmor]

On Thu 2016-01-21 17:59:45 -0500, Daniel Kahn Gillmor  
wrote:
> On Thu 2016-01-21 16:14:30 -0500, jhcha54008 wrote:
>> The current version 2.17.2-1 of libfakechroot in jessie is unusable with 
>> debootstrap
>> (#745082). This may be one of the causes of #809410 too.
>>
>> You may try debirf with fakechroot and libfakechroot version 2.18-1 from 
>> stretch or
>> sid installed.
>
> I've tried this in the past and it worked for me.  I've been meaning to
> set up the debirf autobuilder to work that way.
>
>> Would it make sense to have version 2.18-1 backported to jessie - or
>> included in a coming jessie point release ?
>
> I think getting it in backports at least would be nice, but i dunno
> about the getting into a point release.  That might not be something
> that the release team would be OK with.  If you wanted to start with a
> backport, that would be a good demonstration, i think.

I've just gone ahead with a fakechroot upload to debian-backports
(2.18-1~bpo8+1), which is about as simple as a backport can be.  It also
works for me on amd64, i'm hoping it will work as well on other
architectures.

I've published the debian packaging for the fakechroot jessie-backports
branch over in my personal vcs space on alioth:
 
 git://anonscm.debian.org/git/users/dkg/fakechroot.git
 
   (and should be visible in an hour or so at:)
 https://anonscm.debian.org/git/users/dkg/fakechroot.git

i'm happy to use a branch on the main alioth repo if you like, but
that'd mean i'd need permissions in scm_fakechroot, which i don't have
yet (i've just requested membership in case you want me to do that,
Piotr).

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#823868: (no subject)

[Roland Hieber]

Additionally, when starting gnome-calculator from the terminal, there
are a lot of warning messages about "Theme parsing error:
gtk-widgets.css:3782:31: The :insensitive pseudo-class is deprecated.
Use :disabled instead." which were not there before. Also see attached log.

 - Roland
$ gnome-calculator 

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:20:33: The style property GtkMenu:horizontal-padding is deprecated and shouldn't be used anymore. It will be removed in a future version

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:21:31: The style property GtkMenu:vertical-padding is deprecated and shouldn't be used anymore. It will be removed in a future version

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:22:30: The style property GtkNotebook:initial-gap is deprecated and shouldn't be used anymore. It will be removed in a future version

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:23:30: The style property GtkNotebook:tab-overlap is deprecated and shouldn't be used anymore. It will be removed in a future version

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:41:33: The style property GtkWidget:focus-line-width is deprecated and shouldn't be used anymore. It will be removed in a future version

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:42:30: The style property GtkWidget:focus-padding is deprecated and shouldn't be used anymore. It will be removed in a future version

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:43:27: The style property GtkWidget:link-color is deprecated and shouldn't be used anymore. It will be removed in a future version

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:44:35: The style property GtkWidget:visited-link-color is deprecated and shouldn't be used anymore. It will be removed in a future version

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:70:13: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:71:13: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:71:25: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:76:13: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:77:21: The '-gtk-image-effect' property has been renamed to '-gtk-icon-effect'

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:81:21: The '-gtk-image-effect' property has been renamed to '-gtk-icon-effect'

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:89:27: The :prelight pseudo-class is deprecated. Use :hover instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:99:30: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:110:20: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:112:20: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:114:18: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:116:19: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:172:19: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:173:44: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:174:43: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:175:28: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:176:31: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:177:28: The :insensitive pseudo-class is deprecated. Use :disabled instead.

(gnome-calculator:16381): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:217:30: The style property GtkWidget:focus-padding is deprecated and shouldn't be used 

Bug#815327: O: volti

[James Cowgill]

Control: merge -1 823338

Hi,

> Package: wnpp
> Severity: normal
> > Hello
> > I am interested to maintain this package.

Great!

You're supposed to modify the existing orphan bug instead of filing a
new bug when claiming a package.

This page details how to claim (and eventually fix) a WNPP bug:
https://www.debian.org/devel/wnpp/#l3

This page has lots of useful information about packaging which you
should probably read:
https://mentors.debian.net/intro-maintainers

Thanks,
James


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

Bug#821485: Bumping severity of PHP 7.0 transition bugs to serious

[Benoit Mortier]

On Thu, 5 May 2016 10:20:55 +0200 =?utf-8?B?T25kxZllaiBTdXLDvQ==?=
 wrote:
> Dear maintainer(s),

Hello,

> I am bumping the severity of this bug to serious, as we are going to
> remove src:php5 from Debian and your package is blocking the first
> step which is removal of php5 from testing.  Please either update your
> package to support PHP 7.0 or remove the package from Debian unstable
> alltogether.

Yes it should be removed from debian as the actual version in debian is
not compatible with php7.

The future version 1.0.13 will be fully compatible php5 and php7 and
should be uploaded to debian after this release

Cheers
-- 
Benoit Mortier
CEO
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Promouvoir et défendre le Logiciel Libre http://www.april.org/
Main developper in FusionDirectory : http://www.fusiondirectory.org/
Official French representative for OPSI : http://opsi.org/



signature.asc
Description: OpenPGP digital signature

Bug#822069: mousepad: CPU/disk usage may reflect extensive GLib/GTK* errors

[Cindy Sue Causey]

Package: mousepad
Version: 0.4.0-3
Followup-For: Bug #822069

Dear Maintainer,

Hi again! Did not occur to me to look at ~/.xsession-errors one more time 
before submitting my own observations regarding these combined Mousepad bugs. 
That file, ~/.xsession-errors, was already in the 3,300,000 lines range by the 
time I submitted my report to you all.

THEN I noticed that file was actively growing there in Thunar even as I sat 
there staring at its size (~200 MB). It was ticking upward a tenth (1/10th) of 
a megabyte every few seconds as I sat there watching.

As noted in one or more of the related bugs, I had multiple windows open so I 
started closing them down. It was still ticking which caused me to notice I 
still had one more extra window open. The errors stopped replicating *the* 
second that last extra window was closed. The original single window is still 
open, but all is now quiet on the Mousepad front. :)

Thank you again *so much*. Hope this was able to help somehow.

Peace and best wishes from Talking Rock, Georgia!

Cindy (Sue) :)


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

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

Versions of packages mousepad depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libc62.22-7
ii  libglib2.0-0 2.48.0-1
ii  libgtk2.0-0  2.24.30-1.1
ii  libgtksourceview2.0-02.10.5-2
ii  libpango-1.0-0   1.40.1-1

mousepad recommends no packages.

mousepad suggests no packages.

-- no debconf information

Bug#823873: gnome-software: missing dependencies or setup for non-gnome desktops

[Stephen Liebbe]

Package: gnome-software
Version: 3.20.2-2
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

wanted to try using gnome-software to replace aptitude as it draws in few 
dependencies on non-gnome desktop (I use an Openbox-session started from 
console 
with startx.) After install, program UI starts successfully. However, the 
Software Sources menu item cannot change settings. To me it appears to have 
something 
to do with gaining root permissions. The error output follows

(gnome-software:16722): Gs-WARNING **: failed to open plugin 
/usr/lib/gs-plugins-9/libgs_plugin_packagekit-origin.so: 
/usr/lib/gs-plugins-9/libgs_plugin_packagekit-origin.so: undefined symbol: 
gs_plugin_packagekit_results_valid

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
transmission: Icon 'transmission' not present in theme (null)

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon scribus: 
Icon 'scribus' not present in theme (null)

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
transmission: Icon 'transmission' not present in theme (null)

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon mypaint: 
Icon 'mypaint' not present in theme (null)

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon gimp: 
Icon 'gimp' not present in theme (null)

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon mypaint: 
Icon 'mypaint' not present in theme (null)

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon blender: 
Icon 'blender' not present in theme (null)

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon gimp: 
Icon 'gimp' not present in theme (null)

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon blender: 
Icon 'blender' not present in theme (null)

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon scribus: 
Icon 'scribus' not present in theme (null)

(gnome-software:16722): GsPlugin-WARNING **: failed to load stock icon 
gnucash-icon: Icon 'gnucash-icon' not present in theme (null)

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'scribus' not present in theme (null)

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'mypaint' not present in theme (null)

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'gimp' not present in theme (null)

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'blender' not present in theme (null)

(gnome-software:16722): Gs-WARNING **: hiding recommended applications: found 
only 4 to show, need at least 8

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'transmission' not present in theme (null)

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'mypaint' not present in theme (null)

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'gimp' not present in theme (null)

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'blender' not present in theme (null)

(gnome-software:16722): Gtk-WARNING **: Theme parsing error: :5:28: The 
style property GtkWidget:focus-padding is deprecated and shouldn't be used 
anymore. It will be removed in a future version

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'transmission' not present in theme (null)

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'scribus' not present in theme (null)

(gnome-software:16722): Gs-WARNING **: failed to call gs_plugin_refine_app on 
icons: Icon 'gnucash-icon' not present in theme (null)

(gnome-software:16722): GLib-CRITICAL **: g_hash_table_get_values: assertion 
'hash_table != NULL' failed
ERROR:root:Cannot import UbuntuDrivers: No module named 'UbuntuDrivers'
ERROR:root:Authentication canceled, changes have not been saved

+
I do have gnupg installed but have not done any setup of it. The ERROR reports 
happen when I try to enable the "main" software category in the first 
Software Sources window.

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

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

Versions of packages gnome-software depends on:
ii  

Bug#823872: nmu: aster_11.5.0+dfsg2-4

[Graham Inggs]

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

Hi

It seems petsc was transitioned on the quiet.
Fortunately, its other reverse-deps; slepc, dolfin and getdp have all
had sourceful uploads and only aster needs a binNMU.

Regards
Graham

nmu aster_11.5.0+dfsg2-4 . ANY . -m 'Rebuild against petsc 3.6.3'

Bug#813603: RFS: libcxl/1.3-1 [ITP] -- libcxl -- Coherent accelerator shared library

[Gianfranco Costamagna]

Hi, the package is already in Ubuntu, did you try to look at the packaging and 
see if it was similar?

Gianfranco

On Fri, 1 Apr 2016 19:53:47 + (UTC) Gianfranco Costamagna 
 wrote:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> Hi,
> 
> control: std-version 3.9.7
> copyright: please don't mix GPL and Apache, or other people won't be able to 
> forward patches upstream.
> 
> outfile <-- remove?
> 
> rules:
> 
> make --> $(MAKE) please
> 
> mkdir -p $(CURDIR)/debian/tmp/usr/$(LIBDIR) $(CURDIR)/debian/tmp/usr/include
> cp libcxl.a libcxl.so.$(VERS_LIB) $(CURDIR)/debian/tmp/usr/$(LIBDIR)
> cp libcxl.h $(CURDIR)/debian/tmp/usr/include
> cd $(CURDIR)/debian/tmp/usr/$(LIBDIR) && ln -sf libcxl.so.$(VERS_LIB) 
> libcxl.so.1
> cd $(CURDIR)/debian/tmp/usr/$(LIBDIR) && ln -sf libcxl.so.1 libcxl.so
> 
> 
> this should be handled by upstream makefile, there is no good reason for 
> doing it
> in rules (and other linux distro won't benefit from it)
> 
> check-all-the-things:
> $ flawfinder -Q -c .
> $ codespell --quiet-level=3
> 
> the other stuff looks good to me, but I didn't try to build it yet.
> 
> 
> 
> Il Mercoledì 3 Febbraio 2016 16:15, Frederic Bonnard 
>  ha scritto:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libcxl"
> 
> Package name: libcxl
> Version : 1.3-1
> Upstream Author : CAPI team
> URL : https://github.com/ibm-capi/libcxl
> License : Apache-2.0
> Section : libs
> 
> It builds those binary packages:
> 
>   libcxl-dev - Coherent accelerator shared library development files
>   libcxl1- Coherent accelerator shared library
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   http://mentors.debian.net/package/libcxl
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> http://mentors.debian.net/debian/pool/main/libc/libcxl/libcxl_1.3-1.dsc



signature.asc
Description: OpenPGP digital signature

Bug#823871: linux-image-4.5.0-2-amd64: Cannot access TV-ATSC Digital Card

[Stephen]

Package: src:linux
Version: 4.5.1-1
Severity: grave
Justification: renders package affected(TV Card) unusable

Dear Maintainer,


This bug applies to 'linux-image-4.5.0-2-amd64' I'm presently booted
into the ...01 version which works OK.

Anyway my Hauppauge internal ATSC card doesn't function with kernel
4.5.0.2, it's OK with 4.5.0.1 hence maybe a kernel driver regression?
I'll leave it in your teams capable hands. Any further information
needed, please shoot me an email.

Regards.

-- Package-specific info:
** Version:
Linux version 4.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160409 (Debian 5.3.1-14) ) #1 SMP Debian 4.5.1-1 (2016-04-14)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.5.0-1-amd64 
root=UUID=7351ef5d-fc61-4e47-8d8a-e1c5b697aa91 ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded (currently expected).

** Kernel log:
[   69.905084] tveeprom 5-0050: decoder processor is CX23888 (idx 34)
[   69.905086] tveeprom 5-0050: has no radio, has IR receiver, has no IR 
transmitter
[   69.905087] cx23885[0]: hauppauge eeprom: model=22111
[   69.908463] cx25840 7-0044: cx23888 A/V decoder found @ 0x88 (cx23885[0])
[   69.915338] cx25840 7-0044: firmware: direct-loading firmware 
v4l-cx23885-avcore-01.fw
[   70.007180] [drm] ring test on 5 succeeded in 1 usecs
[   70.007188] [drm] UVD initialized successfully.
[   70.007391] [drm] ib test on ring 0 succeeded in 0 usecs
[   70.007430] [drm] ib test on ring 3 succeeded in 0 usecs
[   70.177409] [drm] ib test on ring 5 succeeded
[   70.178772] [drm] Radeon Display Connectors
[   70.178777] [drm] Connector 0:
[   70.178780] [drm]   DP-1
[   70.178782] [drm]   HPD4
[   70.178787] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 
0x644c
[   70.178789] [drm]   Encoders:
[   70.178791] [drm] DFP1: INTERNAL_UNIPHY2
[   70.178793] [drm] Connector 1:
[   70.178795] [drm]   HDMI-A-1
[   70.178797] [drm]   HPD5
[   70.178801] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 
0x643c
[   70.178802] [drm]   Encoders:
[   70.178804] [drm] DFP2: INTERNAL_UNIPHY2
[   70.178806] [drm] Connector 2:
[   70.178808] [drm]   DVI-I-1
[   70.178810] [drm]   HPD1
[   70.178813] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 
0x646c
[   70.178815] [drm]   Encoders:
[   70.178817] [drm] DFP3: INTERNAL_UNIPHY1
[   70.178819] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[   70.178821] [drm] Connector 3:
[   70.178823] [drm]   DVI-I-2
[   70.178824] [drm]   HPD6
[   70.178827] [drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 
0x645c
[   70.178829] [drm]   Encoders:
[   70.178831] [drm] DFP4: INTERNAL_UNIPHY
[   70.178833] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[   70.190001] Adding 9920508k swap on /dev/sdb5.  Priority:-1 extents:1 
across:9920508k SSFS
[   70.261914] [drm] fb mappable at 0xC045F000
[   70.261917] [drm] vram apper at 0xC000
[   70.261918] [drm] size 8294400
[   70.261920] [drm] fb depth is 24
[   70.261921] [drm]pitch is 7680
[   70.262240] fbcon: radeondrmfb (fb0) is primary device
[   70.295787] Console: switching to colour frame buffer device 240x67
[   70.23] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   70.23] Bluetooth: BNEP filters: protocol multicast
[   70.28] Bluetooth: BNEP socket layer initialized
[   70.312299] radeon :06:00.0: fb0: radeondrmfb frame buffer device
[   70.339588] [drm] Initialized radeon 2.43.0 20080528 for :06:00.0 on 
minor 0
[   70.541016] vboxdrv: Found 6 processor cores
[   70.551711] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[   70.552517] r8169 :02:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168f-1.fw
[   70.559552] vboxdrv: TSC mode is Invariant, tentative frequency 3311099466 Hz
[   70.559556] vboxdrv: Successfully loaded version 5.0.20_Debian (interface 
0x0024)
[   70.567516] VBoxNetFlt: Successfully started.
[   70.569740] cx25840 7-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 
bytes)
[   70.573842] VBoxNetAdp: Successfully started.
[   70.580112] VBoxPciLinuxInit
[   70.581621] vboxpci: IOMMU not found (not registered)
[   70.647702] cx23885[0]: registered device video0 [v4l2]
[   70.647741] cx23885[0]: registered device vbi0
[   70.647850] cx23885[0]: registered ALSA audio device
[   70.647852] cx23885_dvb_register() allocating 1 frontend(s)
[   70.647854] cx23885[0]: cx23885 based dvb card
[   70.654160] r8169 :02:00.0 enp2s0: link down
[   70.654229] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[   70.697267] tda18271 6-0060: creating new instance
[   70.699298] TDA18271HD/C2 detected @ 6-0060
[   70.936310] tda18271 6-0060: attaching existing instance
[   70.936326] DVB: registering new adapter (cx23885[0])
[   70.936335] cx23885 :04:00.0: DVB: registering adapter 0 frontend 0 
(Samsung S5H1411 QAM/8VSB Frontend)...
[   70.936841] cx23885_dev_checkrevision() Hardware revision = 0xd0
[   70.936847] 

Bug#823069: RE: Bug#823069: live-boot-initramfs-tools: Kernel panic while booting live with Debian stretch busybox/live packages

[Arjen Balfoort]

That did not change a thing: output the same as in OP.

Arjen


On Mon, 9 May 2016 20:24:12 +0200 Kristian Klausen 
 wrote:

> Arjen could you try removing:
> 
PATH="/root/usr/bin:/root/usr/sbin:/root/bin:/root/sbin:/usr/bin:/usr/sbin:/bin:/sbin"

> export PATH
>
> from /lib/live/boot/9990-aaa-fixme.sh and see if it works?
>
> - Kristian
>
> 
> > Subject: Bug#823069: live-boot-initramfs-tools: Kernel panic while 
booting live with Debian stretch busybox/live packages

> > From: b...@decadent.org.uk
> > To: 823...@bugs.debian.org
> > CC: util-li...@packages.debian.org
> > Date: Mon, 9 May 2016 17:55:55 +0100
> >
> > Control: clone -1 -2
> > Control: reassign -2 util-linux
> > Control: severity -2 important
> > Control: affects -2 live-boot-initramfs-tools
> > Control: retitle -1 live-boot-initramfs-tools: wrongly adds 
directories in /root to the PATH
> > Control: retitle -2 util-linux: 'mount -o move' does not work with 
virtual filesystems

> >
> > On Sat, 30 Apr 2016 16:07:25 +0200 Arjen Balfoort 
 wrote:

> > [...]
> >> mount: /dev is write-protected, mounting read-only
> >> mount: /dev is not a block device
> >>
> >> The error is caused in 
/usr/share/initramfs-tools/scripts/init-bottom/udev

> >> Line: mount -n -o move /dev ${rootmnt}/dev
> > [...]
> >
> > This is a side-effect of my change in busybox 1.22.0-19, but I don't
> > think that change was wrong.
> >
> > live-boot-initramfs-tools adds directories under /root to $PATH, which
> > was formerly harmelss but now actually does result in some commands
> > being loaded from there. You must stop doing this; it is not
> > supportable and I will not support it.
> >
> > In particular, this mount command now invokes util-linux's mount. That
> > refuses to perform a move if the source filesystem was not mounted from
> > a block device. There is no good reason for this and obviously it
> > works with busybox and klibc's implementations of mount.
> >
> > Ben.
> >
> > --
> > Ben Hutchings
> > If you seem to know what you are doing, you'll be given more to do.
>
>

Bug#823788: [buildd-tools-devel] Bug#823788: sbuild: non-error on stderr: "There are no foreign architectures configured"

[Adam Borowski]

On Mon, May 09, 2016 at 08:37:13AM +0200, Johannes Schauer wrote:
> Quoting Adam Borowski (2016-05-09 04:19:23)
> > I'm afraid that today's update introduced a spurious message, emitted both
> > on package build and on chroot update:
> > "There are no foreign architectures configured".

Correction: turns out this happens with sbuild-update but _not_ sbuild
itself.  I have no idea how I got the impression it's the case, sorry for
wasting your time with this part.

> > Putting aside the question whether this message fits places it's emitted, it
> > definitely shouldn't be written to stderr.  This breaks scripts that assume
> > stderr output means errors.  This includes for example cronjobs to update
> > chroots.
> 
> I want to better understand what scripts using sbuild expect from it.
>
> I don't think it has been the case before that sbuild only writes error
> messages to stderr. I see lots of output done to stderr which is merely status
> display. For example:
> 
>  | Checking available source versions...
> 
> or
> 
>  | Not removing foreign architectures: cloned chroot in use

Nope, nothing of these goes to stderr:

Good package:
[/tmp]$ sbuild tran >/dev/null;echo $?
0

Unknown package:
[/tmp]$ sbuild kjdgndfkjgh >/dev/null;echo $?
E: Failed to fetch source files
3

Invalid version:
[/tmp]$ sbuild tran_2 >/dev/null;echo $?
E: Failed to fetch source files
3

FTBFS ("failed"):
[/tmp]$ sbuild proll >/dev/null;echo $?
E: Package build dependencies not satisfied; skipping
3

FTBFS ("attempted"):
[/tmp]$ sbuild debdry >/dev/null; echo $?
2

In the last case sbuild is even too unchatty.

> As far as I understand the codebase, errors are differentiated by warnings and
> informational messages by their prefix. Errors start with "E: ". So it is true
> that many informational messages (see above) are not prefixed with a "I: " as
> they should.

It'd be nice if you could prefix "There are no foreign architectures configured"
with an "I: ", it currently sounds like a warning of some kind.

> But I do not see that this situation is actually a regression because as I
> showed above, sbuild already outputs lots of information of merely
> informational value on stderr.

Neither sbuild nor sbuild-update put information to stderr, except for this
new message in sbuild-update.

> So I need to understand:
> 
>  - which scripts break?
>  - what to scripts expect?
>  - how was the situation before any different than the one now?

In my case, crontab with:

5 3,15 * * *sbuild-update -udcar jessie stretch unstable >/dev/null

I'd think a good part of sbuild users run sbuild-update from cron like this,
at least this seems a natural thing to do.
 
> It would also be helpful if you could write me a command for me to try out 
> such
> that I see what exactly what breaks.

sbuild-update -udcar unstable >/dev/null
which should say nothing unless there's an error, but currently emits this
line.


Meow!
-- 
How to exploit the Bible for weight loss:
Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.

Bug#821665: Bumping severity of PHP 7.0 transition bugs to serious

[Antonio Ospite]

On Thu, 5 May 2016 10:20:58 +0200
Ondřej Surý  wrote:

> Dear maintainer(s),
> 
> I am bumping the severity of this bug to serious, as we are going to
> remove src:php5 from Debian and your package is blocking the first
> step which is removal of php5 from testing.  Please either update your
> package to support PHP 7.0 or remove the package from Debian unstable
> alltogether.
> 

Hi Ondřej,

I will update the package this week.

However my package depends on php-xml-serializer which is going to be
removed from Debian:
https://packages.qa.debian.org/p/php-xml-serializer/news/20160502T014739Z.html

So I think I will have to explore other serializers, like
php-symfony-serializer.

Also, is there any news about bug #818962? My package is going to give
the error as per the bug report.

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#759403: lintian: Please publish machine-readable report for all packages

[intrigeri]

Niels Thykier wrote (22 Jan 2016 19:42:12 GMT) :
> I believe it is has been easier to hack on html_reports now,

Confirmed, thanks to your helpful hints I could build reports locally!

> in case you are still interested in working on this.

I am. Now, we'll see if/when I find time to actually get to it.

Cheers,
-- 
intrigeri

Bug#823813: netbeans: non-DFSG .xsd files (no modification?)

[Markus Koschany]

Am 09.05.2016 um 12:11 schrieb Dmitry Smirnov:
> Source: netbeans
> Version: 8.1+dfsg2-3
> Severity: serious
> Usertags: dfsg
> 
> Files:
> 
> websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/wsrm-policy-200502.xsd
> 
> websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/WS-Trust.xsd
> 
> websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/metadata-exchange.xsd
> 
> websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/optimizedmimeserialization-policy.xsd
> 
> websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/ws-policy-10.xsd
> 
> websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/wsat.xsd
> 
> are licensed under terms allowing only distribution (i.e. "copy and display")
> while explicitly prohibiting everything else:
> 
>"No other rights are granted by implication, estoppel or otherwise."
> 
> I'm particularly concerned about modification rights that appears to be 
> prohibited.
> 
> Please investigate.

Hi,

these are W3C specifications like
https://en.wikipedia.org/wiki/WS-Policy and
https://www.w3.org/TR/ws-metadata-exchange/. Nowadays they are either
licensed under the W3C document license
https://www.w3.org/Consortium/Legal/2015/doc-license or W3C software
license
https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document. The
latter is dfsg-free but the former does not allow modifications of W3C
documents except under the following conditions:

"No right to create modifications or derivatives of W3C documents is
granted pursuant to this license, except as follows: To facilitate
implementation of the technical specifications set forth in this
document, anyone may prepare and distribute derivative works and
portions of this document in software, in supporting materials
accompanying software, and in documentation of software, PROVIDED that
all such works include the notice below. HOWEVER, the publication of
derivative works of this document for use as a technical specification
is expressly prohibited.

In addition, "Code Components" —Web IDL in sections clearly marked as
Web IDL; and W3C-defined markup (HTML, CSS, etc.) and computer
programming language code clearly marked as code examples— are licensed
under the W3C Software License."

I think most people will agree that it makes no sense to modify a
specification because it would be extremely confusing and harmful for
the internet if there was more than one HTML 5 spec for example.

However I don't intend to argue about this matter because the websvc
module is not used by us. I will just remove it from the tarball.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#822069: mousepad: CPU/disk usage may reflect extensive GLib/GTK+ errors

[Cindy Sue Causey]

Package: mousepad
Version: 0.4.0-3
Followup-For: Bug #822069

Dear Maintainer,

Hi! Thank you for your time and dedication that helps #Debian make computing a 
possiblity for poverty level individuals! Additionally, my apologies that I've 
known about this for an extended period. This is the first chance available to 
pull together a cognitively comprehensible bug report.

While cosidering opening a new bug, reportbug offered bugs #797306 and #797307. 
Those 2 bugs are *not* why I'm filing my report, but that is only because I 
don't go to that extent in monitoring my system 99% of the time. Ever since 
stumbling on this bug, there's been no doubt in my mind that it's likely 
affecting my computer's processing efficiency.

My system's version of whatever is going on was found when my rsync backups 
started hanging up. Rsync turned out to be choking on the hidden file, 
~/.xsession-errors, because it was... *1GB* LARGE! :D

Mousepad was present in line after line of that output so I threw it into a 
terminal. Flicker rate was off the charts because the error messages were 
racing off the terminal screen.

Someone over at Xfce marked a similar issue as solved [1] after referencing 
fonts so I played with those. I decided a scientific approach would be to test 
some other user variable so I played with theme settings.

In that 2 minutes of playing with alternating theme settings, my *latest* 
~./xsession-errors file went from 111914 lines of error messages to a 
tremendous 1148486 lines. TWO MINUTES! :)

A sampling of the errors generated is as follows:

+++ BEGIN MOUSEPAD ERRORS +++

(mousepad:1034): GLib-CRITICAL **: g_variant_new_string: assertion 'string != 
NULL' failed

(mousepad:1034): GtkSourceView-CRITICAL **: gtk_source_style_scheme_get_id: 
assertion 'GTK_IS_SOURCE_STYLE_SCHEME (scheme)' failed

(mousepad:1034): GtkSourceView-CRITICAL **: 
gtk_source_style_scheme_manager_get_scheme: assertion 'scheme_id != NULL' failed

+++ END MOUSEPAD ERRORS +++

With respect to root getting a hat tip in one of the related bugs, that's 
actually where I initially observed the "flicker rate" effect of so many lines 
of errors flashing by. Because it's basically the same errors repeated, that 
flicker rate is easy to miss because the repetitious errors keep replacing each 
other on the screen. My terminal window just happened to be sized differently 
at that moment the flicker rate became visible.

Lastly, I chose to addend to bug #822069 since it's the newest number and the 
others were merged to it.

In conclusion, thank you again *so much*. Mousepad is one of the packages left 
open here all day every day! Well, except for a brief period of time where it 
was a conscious *_CHOICE_* based on the assumption that this bug surely had to 
be direly affecting CPU efficiency somehow, no joke. :)

Peace and best wishes from Talking Rock, Georgia!

Cindy (Sue) :)

[1] https://forum.xfce.org/viewtopic.php?id=9518


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

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

Versions of packages mousepad depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libc62.22-7
ii  libglib2.0-0 2.48.0-1
ii  libgtk2.0-0  2.24.30-1.1
ii  libgtksourceview2.0-02.10.5-2
ii  libpango-1.0-0   1.40.1-1

mousepad recommends no packages.

mousepad suggests no packages.

-- no debconf information

Bug#735134: perl: rename(1) is ancient

[Dominic Hargreaves]

On Mon, May 09, 2016 at 08:18:50PM +0300, Niko Tyni wrote:
> On Sun, May 08, 2016 at 10:29:30PM +0100, Dominic Hargreaves wrote:
> > On Mon, May 02, 2016 at 10:04:03PM +0100, Dominic Hargreaves wrote:
> > > On Mon, Aug 24, 2015 at 11:53:26PM +0200, Dominic Hargreaves wrote:
> > > > On Fri, Aug 21, 2015 at 06:54:01PM +0200, Axel Beckert wrote:
> > > 
> > > > > JFYI: I feel that this search wasn't sufficient. I miss at least two
> > > > > packages co-maintained by myself and missing in that list: xymon and
> > > > > hobbit-plugins:
> > > 
> > > > Okay. I think I put too much faith in codesearch.debian.org giving me
> > > > complete results. I'll look again.
> > > 
> > > Given that codesearch wasn't reliable enough, I had a look at a lintian
> > > check; but I think it's going to be almost impossible to come up with
> > > a check which is accurate; it's either going to end up with too many
> > > false negatives, or too many false positives. As an alternative, how
> > > would people feel about just patching the current rename with a
> > > deprecation warning for one release cycle, and removing it from the perl
> > > package in stretch + 1?
> > 
> > Trivial patch attached for discussion.
> 
> > +warn "Deprecated program in use: rename as shipped with the Debian perl 
> > package will be removed after the release of stretch. Please install the 
> > separate 'rename' package which will provide the same command.\n";
> 
> Thanks for pushing this forward.
> 
> I'd be fine with the deprecation warning strategy FWIW. Do we need
> to run this by debian-devel too?

Good plan, I've just posted a summary.

Bug#823870: Upgrade to v1.1.7

[djcj]

Package: gmsl
Version: 1.1.5-1

Version 1.1.7 has been released quite a while ago:
https://sourceforge.net/projects/gmsl/files/GNU%20Make%20Standard%20Library/v1.1.7/

Can you upgrade the package?

Bug#735134: perl: rename(1) is ancient

[Dominic Hargreaves]

On Mon, May 05, 2014 at 03:51:06PM +0100, Dominic Hargreaves wrote:
> On Sun, Feb 02, 2014 at 03:12:32PM +, Dominic Hargreaves wrote:
> > [CCing debian-devel to get feedback on a de facto 'standard' tool].

> > So to summarise: for many years the perl package has provided
> > /usr/bin/rename, a stanalone utility implemented in perl. The issue is we
> > don't want to provide the utility from the perl package any more because
> > it's been added locally inside debian/ and is not being maintained. A
> > maintained version is available as a separate package, libfile-rename-perl.
> > 
> > The proposals on the table are:
> > 
> > 1) Have perl Depend on libfile-rename-perl (and therefore have the
> >latter become Priority: standard)
> > 2) Make libfile-rename-perl be Standard, to match perl, without adding
> >any dependencies.
> > 3) Have perl Recommend libfile-rename-perl for one release cycle and then
> >drop it
> >- optionally with a warning being emitted by the built-in script
> > 4) 2) + 3) combined.
> > 
> > Option 1 would imply that the utility is fundamentally a part of 
> > using perl, which since it's a standalone command line program which
> > happens to be written in perl, seems wrong.
> > 
> > Option 2 is my preferred option because it seems like the 'least surprise'
> > option. 4) can be considered a mostly-harmless enhancement to that,
> > although adding warnings could be irritating or harmful in some
> > circumstances.
> 
> Based on all the comments, I am proceeding to:
> 
> 1) Make 'rename' (as it has now been renamed, from libfile-rename-perl)
>Priority: standard

This was done.

> 2) Add a Recommends on rename to the perl package for a transitional period

This was done.

> 3) Submit a new lintian check for things which use rename or prename in
>build scripts, advising of changes needed.

This was... shall we say delayed. I attempted to identify packages
to fix through codesearch.debian.net and through lintian, but the
number of different ways one could call such a generic-named command
made this impractical and/or unreliable.

My new plan is to add a deprecation message to the built-in rename
(printing a message to standard error as soon as it runs) advising
people to install the separate 'rename' package.

> 4) Wait until vitually all packages have been fixed and then remove
>prename from the perl package

My new plan is to then remove prename from the perl package after the
release of stretch (and to also drop the Recommends from the perl
package at about the same time).

There is always the chance that people won't read their build logs
to see this being used in Debian packaging scripts, but I don't believe
the number of instances is so high as to make the breakage intolerable.

Thanks,
Dominic.

Bug#823757: closed by Joachim Breitner <nome...@debian.org> (Bug#823757: fixed in screen-message 0.24-1)

[Francesco Poli]

On Mon, 09 May 2016 11:24:04 + Debian Bug Tracking System wrote:

> #823757: sm: fails to set background color with the -b option
> 
> It has been closed by Joachim Breitner .

I've just upgraded to screen-message/0.24-1 from unstable and
everything looks fine again.
Thanks a lot for fixing the issue.   :-)

This probably wins the Quickest Bug Resolution Award™, at least for the
current edition of the award!   ;-)

Thanks again.
Bye!

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


pgpZZUzIaio2W.pgp
Description: PGP signature

Bug#823706: Lazarus 1.6 source files are missing

[Paul Gevers]

Hi Denis,

On 09-05-16 18:05, Denis Kozlov wrote:
> Instead, why not just take the official sources in full and as is? 
> https://sourceforge.net/projects/lazarus/files/Lazarus Zip _ 
> GZip/Lazarus 1.6/ 
> 

Because the upstream sources don't meet the quality requirements of
Debian. So we need to massage the source into the right shape.
Unfortunately, apparently we made a mistake there. And I agree with Abou
that we should have a check on new components (we missed several in the
past as well).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#823711: cpputest: non-free files

[Raphael Hertzog]

Control: forwarded -1 https://github.com/cpputest/cpputest/issues/961

On Sun, 08 May 2016, Dmitry Smirnov wrote:
>  This software may only be used under the terms of a valid, current,
>  end user licence from KEIL for a compatible version of KEIL software
>  development tools. Nothing else gives you the right to use this software.

Thanks for this report. I forwarded this to the upstream developers.

I think that I will just exclude all the platforms_* directories
in my next upload.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#823853: lintian: False positive for source-is-missing on misc/farbtastic/farbtastic.js

[Gunnar Wolf]

Jakub Wilk dijo [Mon, May 09, 2016 at 09:16:43PM +0200]:
> >Oh, right!
> >
> >Fixed it in the repository;
> 
> Shall we close this bug?

It can be closed. It could also be made into a more general "be less
picky" wishlist. Your call :)

Bug#702030: [DSE-Dev] Bug#702030: Bug#754744: forbid most packages to depend on or recommend apparmor

[intrigeri]

Hi,

Russell Coker wrote (14 Dec 2014 05:55:23 GMT) :
> On Mon, 14 Jul 2014 19:13:29 intrigeri wrote:
>> @SELinux maintainers: is this behavior on purpose, or is it due to the
>> historical lack of a facility (recently added by the
>> /etc/default/grub.d support) to easily have a package append arguments
>> to the kernel command-line?

> The SE Linux support predates the /etc/default/grub.d support.  But even if 
> it 
> had been there I still probably wouldn't have done it automatically.  There 
> are situations where you want to install things without activating them and 
> there are situations where things get dragged in by dependencies but you 
> don't 
> want to use them.

Got it, thanks for the insight!

>> Indeed, I think we should. I see several ways of keeping things
>> consistent while reaching the aforementioned AppArmor usability goal:
>> 
>> a) Having the SELinux equivalent of the apparmor package enable it by
>>default too (and then, we'll need conflicts); I've no idea if this
>>is feasible; one would need to look at the SELinux packages and
>>their chain of reverse-dependencies.

> This doesn't sound like a good option.

Even taking into account Mika's note that "the SELinux equivalent of
the apparmor package" does not exist yet, and should be a new binary
package called e.g. selinux?

(I don't mean to insist, I just want to understand better why this
wouldn't be one of the options on the table :)

I've thought a bit about it, and here's the simplest solution I can
find, that can possibly suit everyone's use case, without any postinst
or dh tricks:

 * each package that adds support for a LSM, and is meant to enable it
   by default, ships a /etc/default/grub.d/50_$lsm file, that adjusts
   GRUB_CMDLINE_LINUX if, and only if, no other LSM is enabled via
   GRUB_CMDLINE_LINUX already;

 * each such package conflicts with all others;

 * for AppArmor, said package is the existing "apparmor" one, to
   achieve the usability goal that triggered this discussion;

 * for SELinux, said package would be a new binary one, called e.g.
   "selinux" as suggested by Mika;

 * at least on the AppArmor side, we'll want a Lintian check to ensure
   that no package mistakenly depends on the "apparmor" one.

The only problem I see with this KISS approach is that the code
snippet in /etc/default/grub.d/50_$lsm would be duplicated in various
$lsm_package:s, and any bugfix in it would require several uploads;
this is a downside compared to the dh_enable_lsm idea; arguably, that
code would be super simple, and would rarely have to change, so
perhaps it's no big deal?

One advantage of this plan is that it can be implemented
incrementally, with very little coordination; for example, this should
work:

1. we add this GRUB config snippet in the apparmor package
2. selinux-activate starts checking for other LSMs and warns the user,
   as proposed by Russell
3. whenever/if SELinux maintainers feel like it, they can switch to
   the GRUB approach and drop selinux-activate; and then, we can add
   the Conflicts on both sides

Another advantage of this plan is: it's compatible with existing or
future manual configuration, that is the snippets in
/etc/default/grub.d/50_$lsm will do nothing if the user decided to
configure their prefered LSM in a different way.

>> c) A new package whose job is to select and enable a LSM (or none).
>>Likely "none" would be the default for now. It's tempting to take
>>benefit from debconf here.

> That would work.  The current selinux-activate is a hack that should go away.

OK, so that's one valid option. Let's describe a bit more precisely
how it could work, and then we can compare it to (a) adjusted by u.'s
and Mika's input.

We would need one new binary package (let's call it select-lsm), and
likely the corresponding source package. Ideally, it would be
collaboratively maintained by members of the SELinux and
AppArmor teams.

select-lsm would manage a debconf setting, whose default value would
be "none".

The set of available values for this debconf setting would be
determined by what installed packages add support for a LSM: e.g.
if I have the apparmor package installed, but not selinux-utils, then
I would have to choose between "none" and "AppArmor"; and if I have
both apparmor and selinux-utils installed, then I get to choose
between "none", "AppArmor" and "SELinux".

Each package $lsm_package that adds support for a LSM, and that's
supported by select-lsm, should depend on select-lsm, and somehow we
need the select-lsm's debconf question to be asked again when a new
$lsm_package is installed, or when the $lsm_package corresponding to
the currently selected LSM is de-installed. [Can we do that at all
with debconf? Maybe with a dpkg trigger?]

The outcome of using select-lsm to pick a LSM (or none) is:

 * in the general case: adjust GRUB_CMDLINE_LINUX via
   /etc/default/grub.d/50_select-lsm, run update-grub

 * if a LSM is already enabled in /etc/default/grub:
  

Bug#802651: [Pkg-alsa-devel] Bug#802651: [libasound2] SIG11 on 'aplay -L'

[Michał Mirosław]

On Mon, May 09, 2016 at 02:31:11PM +0200, Elimar Riesebieter wrote:
> * Michał Mirosław  [2016-05-09 12:07 +0200]:
> 
> > On Sun, May 08, 2016 at 05:14:30PM +0200, Elimar Riesebieter
> > wrote:
> > > * Michał Mirosław  [2015-10-22 08:46
> > > +0200]:
> > > 
> > > > Package: libasound2 Version: 1.0.28 Severity: normal Tags:
> > > > patch
> > > > 
> > > > --- Please enter the report below this line. ---
> > > > 
> > > > 'aplay -L' segfaults with ALSA configuration containing
> > > > multiple "@hooks" entries. This happens, eg. with
> > > > libasound2-plugins installed and having one @hooks in
> > > > /etc/asound.conf like following:
> > > > 
> > > > @hooks [ { func load files [ "/usr/share/alsa/bluetooth.conf"
> > > > ] errors false } ]
> > > 
> > > I can reproduce this segfault. Well,
> > > /usr/share/alsa/bluetooth.conf isn't distributed by any Debian
> > > package and is not available in my default installation. Do you
> > > installed that file? Anyway, what is your goal with that hook?
> > 
> > Hmm. This comes from bluez-alsa package - it seems this was left
> > after an upgrade from wheezy (the file is from bluez-alsa
> > package). This seems irrelevant, though, as you should be able to
> > trigger the bug with any two files.
> 
> Wrong, if I use the existing /usr/share/alsa/smixer.conf instead of
> /usr/share/alsa/bluetooth.conf there is no segfault.
> 
> Could you please provide your bluetooth.conf?

That's the one from wheezy's bluez-alsa (version 4.99-2). Attached.

Best Regards,
Michał Mirosław
# Please note that this ALSA configuration file fragment needs be enabled in
# /etc/asound.conf or a similar configuration file with directives similar to
# the following:
#
#@hooks [
#   {
#   func load
#   files [
#   "/etc/alsa/bluetooth.conf"
#   ]
#   errors false
#   }
#]

pcm.rawbluetooth {
@args [ ADDRESS ]
@args.ADDRESS {
type string
}
type bluetooth
device $ADDRESS
}

pcm.bluetooth {
@args [ ADDRESS ]
@args.ADDRESS {
type string
}
type plug
slave {
pcm {
type bluetooth
device $ADDRESS
}
}
}

Bug#823869: please set build flags to expicit values, don't assume defaults

[Matthias Klose]

Package: dpkg,hardening-wrapper

With GCC 6 (and backported to GCC 5), GCC can be configured with 
--enable-default-pie.  DEB_BUILD_*OPTIONS allows explicit disabling of some 
features, however with changed defaults, all these settings are a no-op. 
Therefore please don't assume any defaults settings, but set these flags explicitly.


For this example, when seeing -pie, add -fno-PIE to C*FLAGS, -no-pie to LDFLAGS. 
 But also consider explicitly adding -O0 to C*FLAGS when noopt is passed.  This 
should apply to any feature are settable by DEB_BUILD_*OPTIONS.

Bug#823868: murrine-themes: Greybird theme seems broken

[Karagkiaouris Diamantis]

Package: murrine-themes
Version: 0.98.10
Severity: normal

Dear Maintainer,

When i enable greybird theme on my XFCE desktop every menu seems to be broken. 
On mosts cases menus do not have frames and buttons are vanished. Also 
checkboxes are missplaced on the best case.

Kind Regards

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

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

Versions of packages murrine-themes depends on:
ii  gtk2-engines-murrine  0.98.1.1-5

murrine-themes recommends no packages.

murrine-themes suggests no packages.

-- no debconf information

Bug#823867: ucblogo: Crashes on amd64 when drawing lots of lines

[Peter De Wachter]

Package: ucblogo
Version: 6.0+dfsg-1
Severity: normal

This statement causes the amd64 version of ucblogo to crash:

  repeat 1 [forward 10. right 90]

The i386 version doesn't crash.

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

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

Versions of packages ucblogo depends on:
ii  libc6 2.22-7
ii  libgcc1   1:6.1.1-1
ii  libice6   2:1.0.9-1+b1
ii  libsm62:1.2.2-1+b1
ii  libstdc++66.1.1-1
ii  libtinfo5 6.0+20160319-1
ii  libwxbase3.0-0v5  3.0.2+dfsg-1.3+b1
ii  libwxgtk3.0-0v5   3.0.2+dfsg-1.3+b1
ii  libx11-6  2:1.6.3-1

ucblogo recommends no packages.

ucblogo suggests no packages.

-- no debconf information

Bug#823866: Acknowledgement (kexi-plugin-kspread: not installable in sid or testing)

[Ralf Treinen]

The same applies to the packages

kexi-plugin-mysql
kexi-plugin-postgresql
kexi-xbase-driver

from the same source package. -Ralf.

Bug#759604: Any problem with making auditd log readable by the adm group?

[Steve Grubb]

On Monday, May 09, 2016 09:07:11 PM intrigeri wrote:
> in Debian, the convention for many log files is to make them readable
> by members of the adm group. We're considering doing the same for the
> auditd logs, in order to make apparmor-notify work out-of-the-box.
> 
> The maintainer of auditd in Debian would like to know what's your take
> on it. What kind of problem could be created if we did that?

I can't think of any problems. Just set the log_group = adm in auditd.conf and 
fixup the packaging to have that as the group owner. Auditd should create the 
logs with 0640 permissions.

-Steve

Bug#823811: [Pkg-lyx-devel] Bug#823811: LyX: missing out-of-the box support for Hebrew

[Georg Baum]

Hi Tzafrir,

thank you very much for the report.

Am 09.05.2016 um 12:05 schrieb Tzafrir Cohen:

Package: lyx
Version: 2.1.4-2
Severity: minor

Dear Maintainer,

I'm not much of a LaTeX / LyX user myself anymore, but decided to report
this following a discussion I had in a community forum recently.

When I try to use Hebrew with LyX and can either:


Use the default (pdflatex):
In that case Hebrew support is through babel. The fonts it points to are
a set of fonts not really available anywhere. At the time I packaged
Hebrew support for babel that included usage of the culmus fonts.

I guess some extra effort could be put into making the Culmus fonts the
default ones (the originals were a set of low quality fonts of dubious
legal status).


That would need to be solved at LaTeX level, or did I misunderstand 
something? To my knowledge, LyX does not load any special hebrew fonts.



Use xelatex:
In that case Hebrew support is through polyglossia (and implicitly:
bidi). Works generally better. However:

* The LyX user interface still fails to "reverse" Hebrew. I would have
   expected a QT-based program to do that. This is an issue I would
   probably take upstream.


Yes, this is definitely upstream. Some work has been done for RTL 
support for the upcoming 2.2.0 release. It would be nice if you could 
test whether the situation has improved in this version: 
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0rc1


Unfortunately there is a lack of RTL languages upstream, so your testing 
would be very valuable. RTL bugs in the 2.1.x line will mot likely not 
being fixed anymore, the 2.2 line is the one where all work goes ATM.



* Debian comes with several good font sets that have a good coverage of
   Hebrew, as well as many other scripts (for instance: Deja-Vu). Yet, I
   need to explicitly set the serif font of the document in order for
   documents with Hebrew texts to render. Can't the default be changed?
This would probbaly be a debian specific default, to be made by the 
packager, and would require that the LyX package depends on some font 
packages. Upstream cannot assume anything about installed fonts. 
Unfortunately LyX does not have a proper debian maintainer at the moment.



Georg

Bug#823748: tar: illegal hardware instruction breaks apt-get upgrade

[Diego Gomez]

Like Lee, me neither can reproduce it on my AMD Athlon(tm) II X4 640 processor.
I think it is safe to upgrade.

Regards.

--
Diego.-

Bug#823866: kexi-plugin-kspread: not installable in sid or testing

[Ralf Treinen]

Package: kexi-plugin-kspread
Version: 1:2.4.3+3
User: trei...@debian.org
Usertags: edos-uninstallable

Hi,

kexi-plugin-kspread is not installable in sid or testing since it depends
on kexi-calligrasheets-driver, which exists only in stable and older.
Since it is just a transitional package it should probably be removed.

-Ralf.

Bug#823853: lintian: False positive for source-is-missing on misc/farbtastic/farbtastic.js

[Jakub Wilk]

* Gunnar Wolf , 2016-05-09, 12:26:

Apparently Lintian expects the source to be in:

debian/missing-sources/misc/farbtastic/farbtastic.js

(Note the "misc" part.)


Oh, right!

Fixed it in the repository;


Shall we close this bug?

--
Jakub Wilk

Bug#807805: vlc: Crash upon startup

[Dmitry Shachnev]

Control: reassign -1 libkf5notifications5 5.16.0-1
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=362863

Hi Noah,

On Mon, May 09, 2016 at 11:16:17AM -0700, Noah Meyerhans wrote:
> Here's a more complete stack trace, including the missing symbols:
>
> [...]

Thanks a lot! Now I am sure that it's a bug in knotifications, and I have
created an upstream bug for this. Hope it'll be taken care of.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#823626: gscan2pdf: Date in file name off by one day when saving

[Jeffrey Ratcliffe]

Fixed in the next version

Bug#821874: RE: RM faumachine -- RoQA, unmaintained, RC-Buggy, Depends on to be removed packages

[Tobias Frost]

Hi Stefan,

On Fri, 6 May 2016 21:49:34 +0200 Stefan Potyra 
wrote:
> Hi,
> 
> as promised a short status update:
> 
> There have been quite some changes upstream-wise, but unfortunately
it still
> doesn't build with current gcc version found in unstable(see TLDR
about the
> reason).

> Amd I've been once again accounted to do the upstream release...
> 
> So with my upstream hat on: I'd very much like to stay FAUmachine in
the
> archive, however with my DM hat, I think it's best to remove the
binary
> packages for now to not block anything.
> 
> Are you OK with this plan and/or do you have good advice for me?
> 
> Cheers,
>   Stefan.
>
> 
> TLDR:
> FAUmachine uses a forked version of qemu to build a just-in-time
compiler. The
> idea from Fabrice Bellard is brilliant: Code the emulation of
assembly
> instructions in C and let gcc produce binary code for it. Then use a
script to
> mange this binary code to be usable as input as basic blocks for the
> jut-in-time-compiler.
> 
> Unfortunately, at this script is highly dependent on the produced
assembly code
> (e.g. just one return instruction per function) and this usually
breaks with
> every new gcc version :(.
> 
> This results in the current build breakage, and while this has been
fixed for
> the gcc version in stable, breakage occurs with the current gcc
version in
> unstable.
> 
> 

Thanks for your explanation.
That story seems to be like a maintainance
hell, it defintily makes it not easier, especially as there is already
gcc 6 on the horizon...
Frankly, IMHO this is very close to a case of
FTBFSIASW..
Sorry to be direct, but such an model will only fly with
distributions if upstream is following closely the gcc development.

As short-term measure, you can also force an older gcc version -- 
gcc4.9 is still in the archives: One successful upload will buy you time as 
then the libpng depdendency will be gone. However, be prepared to be nagged by 
then next developers as a bird told me gcc-4.9 is to be removed too. But 
targeting experimental maybe would be an compromise?

I'd be ok with binary only removal, but there is no guarantee that it works 
out: The binaryless-source might be accidentially de-crufted by our 
ftp-masters...
I'll retitle the bug accordingly; (Note: You should tag this "moreinfo" if you 
want to make sure that removal is not executed)


--
tobi

Bug#759604: Any problem with making auditd log readable by the adm group?

[intrigeri]

Hi,

in Debian, the convention for many log files is to make them readable
by members of the adm group. We're considering doing the same for the
auditd logs, in order to make apparmor-notify work out-of-the-box.

The maintainer of auditd in Debian would like to know what's your take
on it. What kind of problem could be created if we did that?

Cheers,
-- 
intrigeri

Bug#774415: srebuild wrapper needs hashes in buildinfo files to query snapshot.d.o

[Johannes Schauer]

Control: block -1 by 802241

The main disadvantage of the current srebuild implementation is, that it will
only make use of a single snapshot.d.o timestamp. This makes it impossible to
reproduce situations where packages are not built in a clean chroot, in a
partially updated chroot or in a chroot mixing different suites. To assemble a
chroot with the right package versions, sbuild could retrieve the exact right
debs from snapshot.d.o.

Snapshot.d.o provides the
/mr/package///binfiles// API to retrieve
hashes of .deb packages of the right architecture. With that hash, srebuild can
retrieve the right dependencies.

It would be simpler if the .buildinfo files would already contain the right
hashes such that less API queries would be necessary.

Thus, blocking this bug by #802241.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

Dear Debian Let’s Encrypt team,

Is there anybody among you who would have time to sponsor acmetool?

The package has already been reviewed by Harlan Lieberman-Berg,
so all that is left to do for now is the actual upload.

https://bugs.debian.org/817091#47

Thanks,
Peter

Bug#823460: [Pkg-xfce-devel] Bug#823460: lightdm: SIGPIPE ignored in session

[Yves-Alexis Perez]

control: forwarded -1 https://bugs.launchpad.net/lightdm/+bug/1579867

On lun., 2016-05-09 at 18:17 +0100, Ian Jackson wrote:
> Yves-Alexis Perez writes ("Re: [Pkg-xfce-devel] Bug#823460: lightdm: SIGPIPE
> ignored in session"):
> > 
> > Thanks for the investigation and the patch, I'll forward this upstream for
> > comments/integration.
> Thanks.  Can you post a reference to the upstream discussion here in
> the Debian bug, as appropriate ?  I'd like to take an interest in the
> upstream conversation.

Here it is: https://bugs.launchpad.net/lightdm/+bug/1579867
-- 
Yves-Alexis



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

Bug#815168: log

[intrigeri]

Hi,

37q7q6+5wppyou2n9...@guerrillamail.com wrote (22 Feb 2016 10:58:29 GMT) :
> it goes a little something like this:

> 23:12:09 host kernel: [   54.884450] audit_printk_skb: 135 callbacks 
> suppressed
> 23:12:09 host kernel: [ 54.884463] audit: type=1400 audit(1456135929.924:57):
> apparmor="DENIED" operation="open" profile="/usr/bin/pidgin"
> name="/run/NetworkManager/resolv.conf" pid=905 comm="pidgin" 
> requested_mask="r"
> denied_mask="r" fsuid=1000 ouid=0

Thank you. I believe this problem was actually in
/etc/apparmor.d/abstractions/nameservice, and has been fixed when we
uploaded apparmor 2.10-4 a while ago. Can you please try and confirm?

Cheers,
-- 
intrigeri

Bug#820824: libapache2-mod-perl2: FTBFS: t/protocol/pseudo_http.t failure

[Niko Tyni]

On Thu, Apr 14, 2016 at 07:48:47AM +0200, Stefan Fritsch wrote:
> reassign 820824 apache2

> On Tuesday 12 April 2016 23:04:42, Niko Tyni wrote:
> > Looking at the CI results at
> >  
> > https://ci.debian.net/packages/liba/libapache2-mod-perl2/unstable/a
> > md64/ this started happening between 2016-04-09 and 2016-04-10,
> > probably with the apache2 2.4.18 -> 2.4.20 upgrade.
> > 
> > I can get this to happen with just
> > # ./t/TEST -verbose -httpd_conf $(pwd)/debian/apache2.conf
> > t/protocol/pseudo_http.t
> > 
> > and I see the Apache server process dies with SIGSEGV. Backtrace
> > below.
> > 
> > Cc'ing the Apache maintainers, seems to be a regression there?
> 
> Seems likely. Reassigning to keep 2.4.20-1 from migrating to testing 
> for now.

This is also

 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201604.mbox/%3CCACsi250G0azcA-XyJHGLxacpDEg_ezJ=taus31pyb7g_8-x...@mail.gmail.com%3E

which says that while apache2 shouldn't crash, the mod_perl2 test is
buggy and should be fixed. Unfortunately mod_perl2 upstream is very
quiet these days, so nothing has happened so far on this front.

I intend to disable the test in libapache2-mod-perl2 for now until
a better solution is found.  Do you want to track the apache2 crash
with this bug, or should we reassign it back?

Thanks,
-- 
Niko Tyni   nt...@debian.org

Bug#823865: d/copyright is missing licenses for many files

[Ondřej Surý]

Package: phpsysinfo
Version: 3.2.1-1
Severity: serious

Dear maintainer,

d/copyright doesn't list all license holders and has wrong copyright
for at least some files:

Please convert to machine-readable copyright file and add missing copyrights:
 + Files: * is GPLv2+, e.g. any later version and not just GPL-2
 + Files: debian/* copyright is missing (is that also GPL-2), could you try 
contacting previous maintainers and make this clear?
 + Files: js/jQuery/* licenses are missing
 + Files: js/vendor/* licenses are missing
 + Files: templates/plugin/* licenses are missing, see the originals 
https://github.com/ludo/jquery-treetable/tree/master/css
 + Files: templates/vendor/* licenses are missing

Then there's a lot of pictures in gfx/, could you please contact
upstream and clarify the licenses for the images there?  At least
gfx/images/ looks suspicious, but there are lot of other images all
around.

The rest look okay(ish), but double check it anyway please.

Cheers,
Ondrej

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

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