date:20160501

Am 01.05.2016 um 23:11 schrieb Emmanuel Bourg:
> Le 1/05/2016 à 21:05, Markus Koschany a écrit :
> 
>> I will wait for feedback from other team members but I think we can
>> remove this package. It has no reverse dependencies and since
>> JColorChooser is part of OpenJDK now, it doesn't seem to be that useful
>> anymore.
> 
> This color chooser is quite different from the one in the JDK, it's
> easier and faster to use. But it hasn't been really used since its
> introduction in Debian 5 years ago.

Ok, I have never used this library, so I can't really say if it is
faster or better than the one in the JDK. Since it's not broken either,
we can keep it, although it doesn't seem to be very popular.

Markus






signature.asc
Description: OpenPGP digital signature

Bug#819282: wheezy-pu: package openldap/2.4.31-2+deb7u2

On Sun, 2016-04-17 at 21:49 +0100, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Sun, 2016-04-17 at 13:22 -0700, Ryan Tandy wrote:
> > On Wed, Apr 13, 2016 at 09:30:13PM +0100, Adam D. Barratt wrote:
> > >Does a significant portion of the testsuite fail, or only a small part?
> > 
> > Exactly one third of it: the same suite is run once for each of the 
> > backends built, namely bdb, hdb, and mdb. The page size issue renders mdb 
> > totally non-functional under the newer kernel.
> > 
> > >If the latter, is it possible to only disable the affected tests?
> > 
> > Actually, yes. Improved debdiff below; and sorry for not thinking of this 
> > myself.
> 
> Thanks; that looks fine to me.

Any news on the upload?

Regards,

Adam

Bug#822853: wheezy-pu: package libdatetime-timezone-perl/1:1.58-1+2016d

Control: tags -1 + pending

On Thu, 2016-04-28 at 13:35 +0200, gregor herrmann wrote:
> On Thu, 28 Apr 2016 12:21:59 +0100, Adam D. Barratt wrote:
> 
> > On 2016-04-28 12:11, gregor herrmann wrote:
> > >I've prepared an update for libdatetime-timezone-perl for
> > >wheezy(-updates) to incorporate the olson db 2016d release as a quilt
> > >patch.
> > With a finalised changelog, please go ahead.
> 
> Thanks, uploaded.

Flagged for acceptance.

Regards,

Adam

Bug#822854: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2016d

Control: tags -1 + pending

On Thu, 2016-04-28 at 13:33 +0200, gregor herrmann wrote:
> On Thu, 28 Apr 2016 12:24:21 +0100, Adam D. Barratt wrote:
> 
> > On 2016-04-28 12:11, gregor herrmann wrote:
> > >I've prepared an update for libdatetime-timezone-perl for
> > >jessie(-updates) to incorporate the olson db 2016d release as a quilt
> > >patch.
> > With a finalised changelog, please go ahead.
> 
> Thanks; uploaded.

Flagged for acceptance, thanks.

Regards,

Adam

Bug#815088: cron: sysv init script has "Required-Start: $remote_fs" but systemd service does not

Control: tag -1 confirmed pending

Hi Sandro,

On 2016-02-18 16:45, Sandro Tosi wrote:
> i just noticed the systemd service for cron doesnt define a depencency on
> remote-fs.target , while the sysv init script have the "Required-Start:
> $remote_fs". I think that dependency should be added.

Thank you for spotting this, I have committed a fix.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#823147: libinput10: AlpsPS/2 ALPS DualPoint TouchPad middle mouse button emulation stopped working

2016-05-01 Thread Julien Cristau

On Sun, May  1, 2016 at 08:43:59 -0500, Mark Nipper wrote:

> Package: libinput10
> Version: 1.2.4-1
> Severity: normal
> 
>   This looks like an upstream bug.  I have the following devices
> on my Dell Latitude E6540:

Probably best to file this upstream.  Let us know the bug number for
tracking.  Either
https://bugs.freedesktop.org/enter_bug.cgi?product=wayland=libinput
or
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg=Input/libinput
I guess.

Cheers,
Julien

Bug#808794: VESA video driver fails when Xorg is executing as non-root

2016-05-01 Thread Julien Cristau

On Sun, May  1, 2016 at 01:38:31 -0700, Sunny Sachanandani wrote:

> I also faced this problem after installing GNOME on Debian stretch running
> on Virtualbox which uses the vesa driver unless you install the guest
> additions. I came across this page describing how rootless X11 is supposed
> to work: http://hansdegoede.livejournal.com/14268.html
> 
> Here's the important bit:
> 
> > When the Xorg binary is no longer suid root, UMS drivers will not work.
> To solve this there is a new suid-wrapper called Xorg.wrap which is suid
> root, when installed this wrapper will get called in stead of the real X
> server, and it will check if there are KMS capable cards in the system, if
> KMS capable cards are found it will drop all elevated rights and execute
> the X server as a normal user. If no KMS capable cards are found it will
> execute the X server with root rights, allowing old UMS drivers, such as
> the proprietary drivers for some cards, or the vesa driver to work.
> 
> Can the X11 maintainers please implement something like this? Or borrow
> from upstream if it already exists?
> 
It exists, it's in the xserver-xorg-legacy package.

Cheers,
Julien

Bug#811126: cron: MIME-Version header not set thus Content-Type and other MIME headers may be ignored

Control: tag -1 moreinfo

Hi,

On 2016-01-15 22:18, Vincent Caron wrote:
> Package: cron
> Version: 3.0pl1-127+deb8u1
   ^^^

This version already contains this fix; it first included in
3.0pl1-125.

Is it possible that you got your versions mixed up?

> when sending command outputs via email, cron will use at least one MIME
> header(Content-Type, wether the user configured CONTENT_TYPE or not),
> but will not set the "MIME-Version" header as required by the MIME RFC.

> The patch is pretty trivial: always add a "MIME-Version: 1.0" header.
> 
> --- do_command.c.orig   2016-01-15 13:24:09.486709632 +0100
> +++ do_command.c2016-01-15 13:07:26.594685734 +0100
> @@ -567,6 +567,7 @@
> fprintf(mail, "Date: %s\n",
> arpadate());
>  # endif /* MAIL_DATE */
> +   fprintf(mail, "MIME-Version: 1.0\n");
> if ( content_type == 0L ) {
> fprintf(mail, "Content-Type: text/plain; charset=%s\n",
> cron_default_mail_charset

Regards,
Christian




signature.asc
Description: OpenPGP digital signature

Bug#794266: Tests

2016-05-01 Thread Uwe Kleine-König

Hello Manuel,

On Sun, May 01, 2016 at 09:32:46PM +0200, Manuel Roeder wrote:
> Hello! Here is the output (this is a newer Testkernel 4.5.2 with no
> patches, only one rtc-driver is enabled rtc-s35390a the rest is debian
> kernel-config. If needed I can backup the actual kernel/initrd and
> test again.

I'm surprised that rebinding after the i2cget command fails, but I don't
think the kernel version matters here.

> bash-3150  [000]  245704.945876: i2c_read: i2c-0 #0 a=030 
> f=0001 l=1
> bash-3150  [000]  245704.945974: i2c_reply: i2c-0 #0 a=030 
> f=0001 l=1 [70]
> bash-3150  [000]  245704.945978: i2c_result: i2c-0 n=1 ret=1
> bash-3150  [000]  245704.945981: i2c_read: i2c-0 #0 a=031 
> f=0001 l=1
> bash-3150  [000]  245704.946075: i2c_reply: i2c-0 #0 a=031 
> f=0001 l=1 [00]
> bash-3150  [000]  245704.946079: i2c_result: i2c-0 n=1 ret=1
> bash-3150  [000]  245704.946082: i2c_read: i2c-0 #0 a=030 
> f=0001 l=1
> bash-3150  [000]  245704.946175: i2c_reply: i2c-0 #0 a=030 
> f=0001 l=1 [70]
> bash-3150  [000]  245704.946178: i2c_result: i2c-0 n=1 ret=1
> bash-3150  [000]  245704.946181: i2c_read: i2c-0 #0 a=032 
> f=0001 l=7
> bash-3150  [000]  245704.946467: i2c_reply: i2c-0 #0 a=032 
> f=0001 l=7 [68-a0-80-00-9a-44-98]
> bash-3150  [000]  245704.946471: i2c_result: i2c-0 n=1 ret=1
> bash-3150  [000]  245704.946505: i2c_read: i2c-0 #0 a=032 
> f=0001 l=7
> bash-3150  [000]  245704.946755: i2c_reply: i2c-0 #0 a=032 
> f=0001 l=7 [68-a0-80-00-9a-44-98]
> bash-3150  [000]  245704.946760: i2c_result: i2c-0 n=1 ret=1
> bash-3150  [000]  245704.946765: i2c_read: i2c-0 #0 a=031 
> f=0001 l=1
> bash-3150  [000]  245704.946852: i2c_reply: i2c-0 #0 a=031 
> f=0001 l=1 [00]
> bash-3150  [000]  245704.946855: i2c_result: i2c-0 n=1 ret=1

looks fine up to here.

>   i2cget-3173  [000]  245732.145408: smbus_read: i2c-0 a=030 
> f= c=1 BYTE_DATA
>   i2cget-3173  [000]  245732.145418: i2c_write: i2c-0 #0 a=030 
> f= l=1 [01]
>   i2cget-3173  [000]  245732.145420: i2c_read: i2c-0 #1 a=030 
> f=0001 l=1
>   i2cget-3173  [000]  245732.155145: i2c_result: i2c-0 n=0 ret=-5

ok, this is an operation that the rtc doesn't like. There is a one
written to a ro-bit and it responds with EIO. That's unusual ok.

>   i2cget-3173  [000]  245732.155150: smbus_reply: i2c-0 a=030 
> f= c=1 BYTE_DATA l=1 [79]
>   i2cget-3173  [000]  245732.155153: smbus_result: i2c-0 a=030 
> f= c=1 BYTE_DATA rd res=-5
> bash-3150  [000]  245744.882560: i2c_read: i2c-0 #0 a=030 
> f=0001 l=1
> bash-3150  [000]  245746.888363: i2c_result: i2c-0 n=0 
> ret=-110

Now the driver wants to bind again but the request to read the Status
Register 1 times out. I guess the chip is still angry on us.

A bad thing about the rtc chip is that the flags are cleared at read. So
if it's in a strange state this is only signaled once[1]. And additionally
i2cget isn't really usable to read out the chip because it uses a
different protocol.

Can you please report (with the machine in the broken state) the output of

echo 1 > /sys/kernel/debug/tracing/events/i2c/enable
cat /sys/class/rtc/rtc0/wakealarm
echo 0 > /sys/class/rtc/rtc0/wakealarm
cat /sys/class/rtc/rtc0/wakealarm
cat /sys/kernel/debug/tracing/trace

Is the machine after this sequence still unable to shut down?

Best regards
Uwe

[1] if you're a hardware engineer and consider implementing something
like that: Don't do it unless you want your driver authors to curse
on you. This is really stupid.


signature.asc
Description: PGP signature

Bug#822185: libcolorchooser-java - Add maven support

2016-05-01 Thread Emmanuel Bourg

Le 1/05/2016 à 21:05, Markus Koschany a écrit :

> I will wait for feedback from other team members but I think we can
> remove this package. It has no reverse dependencies and since
> JColorChooser is part of OpenJDK now, it doesn't seem to be that useful
> anymore.

This color chooser is quite different from the one in the JDK, it's
easier and faster to use. But it hasn't been really used since its
introduction in Debian 5 years ago.

Bug#823185: The supplied mk files cause overlinking

2016-05-01 Thread Philippe Grégoire

Package: bmake
Version: 20160220-2
Severity: wishlist

Hi,

Debian's bmake does not ship with the upstream mk files.

One of the most noticeable differences between the two (2) sets is the
use of libtool. As it was previously discussed in [1], this situation
forces pkg-config files to expose libraries' internal dependencies in
Libs (rather than using Libs.private). This means that Debian packages
built with bmake causes overlinking.

By extension, it is my opinion that it breaks compatibility with other
systems' bmake due to the differences between the mk files they ship.
Fedora, for example, ships bmake's mk files [2]. By extension, most
RPM-based distributions may ship them.


Suggested solution:

Treat bmake as bmake. Ship it with the upstream mk files rather than
the aging NetBSD's [3][4].


Thanks,

P. Grégoire

[1] https://lists.debian.org/debian-devel-announce/2005/11/msg00016.html
[2] http://pkgs.fedoraproject.org/cgit/rpms/bmake.git/tree/bmake.spec
[3] http://cvsweb.netbsd.org/bsdweb.cgi/src/share/mk/?only_with_tag=MAIN
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821752

Bug#823184: umount mounts /proc as a side effect

2016-05-01 Thread Yuri D'Elia


Package: mount
Version: 2.28-1
Severity: important

Amusing, right? But not too much.

It does actually happen due to a new behavior in libselinux, which mount links 
against.
The same is true for any binary in util-linux and coreutils (and so on)

See bug #822679

I consider this behavior unexpected.
[and yes, I'm doing this to raise some awareness. Close the report if needed]

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

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

Versions of packages mount depends on:
ii  libblkid1  2.28-1
ii  libc6  2.22-7
ii  libmount1  2.28-1
ii  libselinux12.4-3+b1
ii  libsmartcols1  2.28-1
ii  libudev1   229-5

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common

Bug#814678: cron: No information given about syntax error in /etc/crontab

2016-05-01 Thread Teo Tei

> The cron daemon is detecting a syntax error, it is reporting it

It is not reporting it in sufficient detail. There may be hundreds of
lines in a file.
If it was just logging a message saying "Some error occurred" (with no
indication
whatsoever that it is related to cron), would you still consider it acceptable?
I hope not, yet you could still argue that "it is reporting the error".
The level of detail that one expects from an error report might be somewhat
subjective, but I think anybody in their right mind would agree nowadays that
file:line_number is a bare minimum.

> IOW, it is functioning as designed. Even if
> the design itself is limited.

The design is wrong. And by the way I doubt that who designed it put
much thought
in leaving out the line number, as in "I really thing it's enough to
report that there was
an error. Who could possibly want to know more?"

> Nothing is preventing the administrator from locating that error manually.

Yeah right.
If it wasn't reporting the error at all, still nothing would prevent
the administrator from
finding out by himself.

> The requested feature would simply make this process somewhat more
> convenient.

The requested "feature" (at least the line number) would make this
process somewhat
acceptable.

2016-05-01 22:31 GMT+02:00 Christian Kastner :
> On 2016-05-01 22:18, Teo Tei wrote:
>> "Cosmetic issue"?? You must be kidding me.
>
> The cron daemon is detecting a syntax error, it is reporting it, and it
> is skipping that crontab -- IOW, it is functioning as designed. Even if
> the design itself is limited.
>
>> Being able to locate a syntax error is vital.
>
> Nothing is preventing the administrator from locating that error manually.
>
> The requested feature would simply make this process somewhat more
> convenient.
>

Bug#821752: Packager patch

2016-05-01 Thread Philippe Grégoire

The previous patch applies for the result of:

$ apt-get source bmake

Since Debian does not ship with the upstream mk files, the
attached patch applies to the Debian-shipped mk; and is meant
to be used by the packager.

Thanks,

P. Grégoire
diff --git a/debian/mk/bsd.lib.mk b/debian/mk/bsd.lib.mk
index 682fd82..fccea05 100644
--- a/debian/mk/bsd.lib.mk
+++ b/debian/mk/bsd.lib.mk
@@ -143,7 +143,7 @@ MKPICLIB?= yes
 .if ${OBJECT_FMT} == "ELF"
 SHLIB_TYPE=ELF
 SHLIB_SOVERSION=   ${SHLIB_MAJOR}
-SHLIB_SHFLAGS= -soname lib${LIB}.so.${SHLIB_SOVERSION}
+SHLIB_SHFLAGS=   -Wl,-soname=lib${LIB}.so.${SHLIB_SOVERSION}
 .if exists(${DESTDIR}/usr/lib/${MACHINE_MULTIARCH}/crtbeginS.o)
 SHLIB_LDSTARTFILE?=${DESTDIR}/usr/lib/${MACHINE_MULTIARCH}/crtbeginS.o
 .else

Bug#823183: xinput can't set "Device Accel Profile"

2016-05-01 Thread Ruben Herold

Package: xinput
Version: 1.6.2-1 
Severity: normal


hi,

I can't set:

xinput set-prop "AlpsPS/2 ALPS DualPoint Stick" "Device Accel Profile" 6


anymore:

property 'Device Accel Profile' doesn't exist, you need to specify its type and 
format


So my DualPoint Stick is useless..


Thx

Ruben


-- 
Ruben Herold 
ru...@insecure.pw


pgpu8A3EqN5cn.pgp
Description: PGP signature

Bug#814678: cron: No information given about syntax error in /etc/crontab

Control: severity -1 minor

On 2016-02-14 00:36, teo8...@gmail.com wrote:
> Package: cron
> Version: 3.0pl1-124
> Severity: important

I downgraded the severity as objectively speaking, this is a cosmetic issue.

>* What led up to the situation?
> 
> Have a syntax error in /etc/crontab
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> see above
>* What was the outcome of this action?
> A generic useless non-informative error message is logged 
> in /var/log/syslog whih reads more or less (quoting by memory):
> Syntax error in /etc/crontab. This file will be ignored
> 
>* What outcome did you expect instead?
> The message should at the very least include the exact row and column
>  where the syntax error is, and ideally a description of the error
> (e.g. "XXX expected" or "invalid YYY")

The built-in parser is unfortunately very basic. Implementing the above
would require significant rework.

Unfortunately, I don't think the benefit would justify the cost here.
However, I don't want to tag this wontfix, as a patch would certainly be
accepted.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#750645: update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults

Control: tag -1 + confirmed pending

On 2015-09-26 10:47, Tobias Kranz wrote:
> Setting up cron (3.0pl1-127+deb8u1) ...
> update-rc.d: warning: start and stop actions are no longer supported;
> falling back to defaults
> 
> I think this is triggered by the postinst script (in my case package
> cron_3.0pl1-127+deb8u1_amd64.deb on line 85) using update-rc.d start:
> 
> # Automatically added by dh_installinit
> if [ -x "/etc/init.d/cron" ]; then
>   update-rc.d cron start 89 2 3 4 5 . >/dev/null
>   invoke-rc.d cron start || exit $?
> fi
> 
> which is deprecated if i got it correct:
> 
> https://lists.debian.org/debian-devel/2013/05/msg01109.html

Thank you for the report, I have just committed a fix.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#823182: racket: Recommends libpng12 which is going away, please switch to libpng16

2016-05-01 Thread Mattia Rizzolo

Source: racket
Version: 6.3-3
Severity: important

Dear maintainer,

your package has a Recommends on libpng12, and we're trying to kick it
away.

Please investigate whether your package works correctly with libpng16
and switch the recommends.

I don't know why you need such weird thing, but I'm going to assume you
are aware of the weirdness of keeping a library package in Recommends,
and that we usually don't check for them when doing transitions.

-- 
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#823181: RM: web2ldap -- RoQA; unsuitable for stable release, unmaintained

2016-05-01 Thread Moritz Muehlenhoff

Package: ftp.debian.org
Severity: normal

Hi,
please remove web2ldap. Upstream requested it's removal in #771503
(acked by maintainer) and the last upload was in 2013.

Cheers,
Moritz

Bug#823179: RM: cutter-testing-framework [hurd-i386] -- RoQA; blocks gstreamer remova

2016-05-01 Thread Moritz Muehlenhoff

Package: ftp.debian.org
Severity: normal

Hi,
please remove cutter-testing-framework on hurd-i386. It failed to
build from source, so the outdated binaries on hurd block the
gstreamer 0.10 removal.

Cheers,
Moritz

Bug#822915:

2016-05-01 Thread SamuelOPH

Control: tags 822915 confirmed
Control: tags 822915 pending
Control: severity 822915 minor
thanks

Hi,

Thanks for reporting this, I've just got in charge of jwm and there's still
little things that need to be changed.

I'm lowering the severity of this bug because i believe it fits better, i
should wait for the next release of jwm to fix it, if it takes too much
time for it to happen i will fix it before, the next version of jwm will
implement various patches that the package currently uses.

Unfortunately i don't think i can fix this on stable since it's not a
serious bug, but a fix should definitely arrive to jessie-backports as soon
as to testing.

Please let me know if you have any considerations or disagreements so we
can discuss this further.

Samuel Henrique O. P. [samueloph]

Bug#823180: getting openssl error when trying to enroll my browser

2016-05-01 Thread Michael Stapelberg

Package: sso.debian.org
Severity: normal

I’m logged into sso.debian.org using my password and I’m on
https://sso.debian.org/spkac/enroll/. When clicking “Get certificate”
(not changing any of the form fields), the resulting page contains a red
message stating “/usr/bin/openssl failed”.

Is this an issue on the server side of sso.debian.org? Could someone
take a look please?

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

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

Bug#823178: ruby-bluecloth: obsolete

2016-05-01 Thread Christian Hofstaedtler

Package: ruby-bluecloth
Severity: important

Bluecloth is no longer developed or maintained upstream. While we
may keep this package around for a bit longer, dependencies on it
need to be removed over time.

New packages certainly must not depend on ruby-bluecloth.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#822679: [DSE-Dev] Bug#822679: closed by Laurent Bigonville <bi...@debian.org> (Bug#822679: fixed in libselinux 2.5-2)

2016-05-01 Thread Laurent Bigonville


Le 01/05/16 à 21:01, Yuri D'Elia a écrit :

On Sun, May 01 2016, Laurent Bigonville  wrote:

It's only doing this if /proc is not mounted, something that should
happen at early boot.

libselinux needs to determine the status of selinux on the machine. This is 
done by reading files
under /proc.

libselinux should assume selinux is disabled if there's no proc, and
just do nothing.

Why the safe default cannot be followed here?
Can't "ls" just do it's work without policy until /proc is ready?

This is going to attempt mounting /proc in containers and generally mess
with event-based system initialization in unexpected ways.

I personally experienced this while setting up a testing environment
where selinux is _disabled_ and took me a while to track down why /proc
was getting mounted over and over again.


What are the symptoms you are seeing exactly? what is broken?

Isn't /proc needed for almost anything these days anyway?

If you want to change that, see with upstream.

Do I really have to?
This seems like a *very bad* idea in the first place.


I'm not planning to carry a patch in the debian package for that.

Funny thing: unmount will now mount /proc.

Maybe I need to file a bugreport against mount.

I don't think it's needed, mount is not responsible of this.

Bug#823177: Please update to 0.44 version

2016-05-01 Thread Gabriel P

Package: gource
Version: 0.43-1+b3

Version 0.44 is released for almost a year and contains small, but very
important stability patch, please package in this version.

Bug#823176: qpdfview does not use Gtk+ style by default

2016-05-01 Thread Alejandro Carrazzoni

Package: qpdfview
Version: 0.4.14-1
Severity: normal

I am currently using a Xfce desktop, and while other Qt applications detect I
am running Xfce and use the Gtk+ style as appropiate, qpdfview does not.
Running qpdfview with -style=gtk works fine, but the application should use the
gtk style without that option under Xfce.



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

Versions of packages qpdfview depends on:
ii  hicolor-icon-theme0.13-1
ii  libc6 2.22-6
ii  libcups2  2.1.3-5
ii  libgcc1   1:5.3.1-14
ii  libgl1-mesa-glx [libgl1]  11.1.2-1
ii  libpoppler-qt5-1  0.38.0-2+b1
ii  libqt5concurrent5 5.5.1+dfsg-16+b1
ii  libqt5core5a  5.5.1+dfsg-16+b1
ii  libqt5dbus5   5.5.1+dfsg-16+b1
ii  libqt5gui55.5.1+dfsg-16+b1
ii  libqt5printsupport5   5.5.1+dfsg-16+b1
ii  libqt5sql55.5.1+dfsg-16+b1
ii  libqt5sql5-sqlite 5.5.1+dfsg-16+b1
ii  libqt5svg55.5.1-2
ii  libqt5widgets55.5.1+dfsg-16+b1
ii  libqt5xml55.5.1+dfsg-16+b1
ii  libstdc++65.3.1-14
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages qpdfview recommends:
pn  qpdfview-djvu-plugin   
pn  qpdfview-ps-plugin 
ii  qpdfview-translations  0.4.14-1

qpdfview suggests no packages.

-- no debconf information

Bug#823175: qpdfview-translations: Spanish translation incomplete

2016-05-01 Thread Alejandro Carrazzoni

Package: qpdfview-translations
Version: 0.4.14-1
Severity: important
Tags: l10n

The Spanish translation is incomplete. The Preferences dialog has a lot of
untranslated words, and the Print and Help dialogs are completely untranslated.



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

Versions of packages qpdfview-translations depends on:
ii  qpdfview  0.4.14-1

qpdfview-translations recommends no packages.

qpdfview-translations suggests no packages.

-- no debconf information

Bug#823174: ros-pluginlib: debian/rules uses non-portable shell syntax; please make the build reproducible (shell)

2016-05-01 Thread Daniel Shahaf

Source: ros-pluginlib
Version: 1.10.1-3
Severity: minor
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment

Dear Maintainer,

While working on the “reproducible builds” effort, we have noticed that
ros-pluginlib could not be built reproducibly; the diff between two
builds is:


https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/ros-pluginlib.html
│   │   │   │ 
-add_definitions(-DCMAKE_LIBRARY_ARCHITECTURE=\"${CMAKE_LIBRARY_ARCHITECTURE}\")
│   │   │   │ 
+add_definitions(-DCMAKE_LIBRARY_ARCHITECTURE=\\"${CMAKE_LIBRARY_ARCHITECTURE}\\")

This difference is down to debian/rules calling echo(1) with an argument
that contains a literal backslash.  The behaviour of echo(1) in that
case is (according to POSIX) implementation-defined.  Since debian/rules
uses echo(1) from the building user's shell, the build output differs
when the building user uses SHELL=bash v. SHELL=dash:

% s=\'foobar\'; LC_ALL=C dash -c "echo $s" 
foo\bar
% s=\'foobar\'; LC_ALL=C bash -c "echo $s" 
foo\\bar
%

The following patch removes the use of implementation-defined behaviour:

[[[
diff --git a/debian/rules b/debian/rules
index 9e5b691..c867402 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,7 @@ override_dh_auto_test:
 
 override_dh_auto_configure:
dh_auto_configure
-   echo 
'add_definitions(-DCMAKE_LIBRARY_ARCHITECTURE=\\"$${CMAKE_LIBRARY_ARCHITECTURE}\\")'
 >> build/catkin_generated/installspace/pluginlibConfig.cmake
+   printf 'add_definitions(-DCMAKE_LIBRARY_ARCHITECTURE=\\"%s\\")' 
'$${CMAKE_LIBRARY_ARCHITECTURE}' >> 
build/catkin_generated/installspace/pluginlibConfig.cmake
 
 override_dh_auto_install:
dh_auto_install --destdir=debian/tmp
]]]

This patch should also make the build reproducible, but I didn't test that.

Note that when built under bash, pluginlibConfig.cmake would contain
additional backslashes; I'm not sure what their effect would be.

Cheers,

Daniel

Bug#305622: gimp-dcraw: Cannot process filenames with single quotes

2016-05-01 Thread Tobias Frost

Control: tags -1 newcomer confirmed

Tagging newcomer; this bug should be quite easy to fix. 

-- 
Tobi

Bug#819080: #819080: ruby-augeas ships without a gemspec file

2016-05-01 Thread Christian Hofstaedtler

Control: severity -1 normal

> ruby-augeas ships without a gemspec file,

While this is true, no r-dep in Debian currently loads augeas using
rubygems. Downgrading this bug for now.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#794266: Tests

2016-05-01 Thread Manuel Roeder

Hello! Here is the output (this is a newer Testkernel 4.5.2 with no
patches, only one rtc-driver is enabled rtc-s35390a the rest is debian
kernel-config. If needed I can backup the actual kernel/initrd and
test again.

root@ts219p:~# dmesg -c > /dev/null
root@ts219p:~# echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
root@ts219p:~# echo 1 > /sys/kernel/debug/tracing/events/i2c/enable
root@ts219p:~# echo 0-0030 > /sys/bus/i2c/drivers/rtc-s35390a/bind
root@ts219p:~# echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
root@ts219p:~# i2cget 0 0x30 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x30, data address
0x01, using read byte data.
Continue? [Y/n] y
Error: Read failed
root@ts219p:~# echo 0-0030 > /sys/bus/i2c/drivers/rtc-s35390a/bind
-bash: echo: Schreibfehler: Kein passendes Gerät gefunden.
root@ts219p:~# dmesg
[245704.947084] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0
[245732.145566] i2c i2c-0: mv64xxx_i2c_fsm: Ctlr Error -- state: 0x7,
status: 0x38, addr: 0x30, flags: 0x1
[245746.881691] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[245746.888378] rtc-s35390a 0-0030: error resetting chip
[245746.902086] rtc-s35390a: probe of 0-0030 failed with error -5
root@ts219p:~# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 26/26   #P:1
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |
bash-3150  [000]  245704.945876: i2c_read: i2c-0 #0
a=030 f=0001 l=1
bash-3150  [000]  245704.945974: i2c_reply: i2c-0 #0
a=030 f=0001 l=1 [70]
bash-3150  [000]  245704.945978: i2c_result: i2c-0 n=1 ret=1
bash-3150  [000]  245704.945981: i2c_read: i2c-0 #0
a=031 f=0001 l=1
bash-3150  [000]  245704.946075: i2c_reply: i2c-0 #0
a=031 f=0001 l=1 [00]
bash-3150  [000]  245704.946079: i2c_result: i2c-0 n=1 ret=1
bash-3150  [000]  245704.946082: i2c_read: i2c-0 #0
a=030 f=0001 l=1
bash-3150  [000]  245704.946175: i2c_reply: i2c-0 #0
a=030 f=0001 l=1 [70]
bash-3150  [000]  245704.946178: i2c_result: i2c-0 n=1 ret=1
bash-3150  [000]  245704.946181: i2c_read: i2c-0 #0
a=032 f=0001 l=7
bash-3150  [000]  245704.946467: i2c_reply: i2c-0 #0
a=032 f=0001 l=7 [68-a0-80-00-9a-44-98]
bash-3150  [000]  245704.946471: i2c_result: i2c-0 n=1 ret=1
bash-3150  [000]  245704.946505: i2c_read: i2c-0 #0
a=032 f=0001 l=7
bash-3150  [000]  245704.946755: i2c_reply: i2c-0 #0
a=032 f=0001 l=7 [68-a0-80-00-9a-44-98]
bash-3150  [000]  245704.946760: i2c_result: i2c-0 n=1 ret=1
bash-3150  [000]  245704.946765: i2c_read: i2c-0 #0
a=031 f=0001 l=1
bash-3150  [000]  245704.946852: i2c_reply: i2c-0 #0
a=031 f=0001 l=1 [00]
bash-3150  [000]  245704.946855: i2c_result: i2c-0 n=1 ret=1
  i2cget-3173  [000]  245732.145408: smbus_read: i2c-0 a=030
f= c=1 BYTE_DATA
  i2cget-3173  [000]  245732.145418: i2c_write: i2c-0 #0
a=030 f= l=1 [01]
  i2cget-3173  [000]  245732.145420: i2c_read: i2c-0 #1
a=030 f=0001 l=1
  i2cget-3173  [000]  245732.155145: i2c_result: i2c-0 n=0
ret=-5
  i2cget-3173  [000]  245732.155150: smbus_reply: i2c-0
a=030 f= c=1 BYTE_DATA l=1 [79]
  i2cget-3173  [000]  245732.155153: smbus_result: i2c-0
a=030 f= c=1 BYTE_DATA rd res=-5
bash-3150  [000]  245744.882560: i2c_read: i2c-0 #0
a=030 f=0001 l=1
bash-3150  [000]  245746.888363: i2c_result: i2c-0 n=0
ret=-110
root@ts219p:~#

Bug#823170: Pending fixes for bugs in the golang-testify package

2016-05-01 Thread pkg-go-maintainers

tag 823170 + pending
tag 823170 + pending
thanks

Some bugs in the golang-testify package are closed in revision
5eb3d6fcfd1219ded43363c9a37a5778de96a8f1 in branch 'master' by
Martín Ferrari

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-testify.git/commit/?id=5eb3d6f

Commit message:

Repackage the source, removing third-party code. Closes: #823170.

* Repackage the source, removing third-party code. Closes: #823170.
* Add these dependencies to debian/control.

Bug#823173: RM: openjdk-6/experimental [mipsel] -- RoQA; FTBFS, blocks acceptance of uploads to oldstable-new

Package: ftp.debian.org
X-Debbugs-CC: openjd...@packages.debian.org, debian-rele...@lists.debian.org
User: ftp.debian@packages.debian.org
Usertags: rm
Tags: experimental

Hi,

openjdk-6's last couple of uploads to experimental have failed to build
on mipsel.

I'm not sure if anyone cares about fixing that (I have CCed the
maintainers in case) but, due to dak's requirement that uploads to
{,old}stable not have higher versions than experimental, we're currently
unable to get the last openjdk-6/mipsel package from DSA 3465-1 included
in the EOL wheezy point release.

dak rm complains about a couple of broken dependencies, but they appear
to be arch:all packages built from the same source package.

Regards,

Adam

Bug#814670: Possible fix for su - / su -l and XDG_RUNTIME_DIR

2016-05-01 Thread Vivek Das Mohapatra


The attached patch adds a pam profile for su -l (and su -),
patches su to use that profile if su - is used, and adds a
pseudo-xdg-session pam module.

It isn't possible to guarantee there's a "real" XDG session
for that user for the su - session to join, and you making logind
handle su - and similar sessions properly requires a fair bit of
surgery, so we set up a summy XDG_RUNTIME_DIR instead.
diff -Nru shadow-4.2/debian/changelog shadow-4.2/debian/changelog
--- shadow-4.2/debian/changelog	2015-11-12 14:33:56.0 +
+++ shadow-4.2/debian/changelog	2016-04-27 19:28:51.0 +0100
@@ -1,3 +1,11 @@
+shadow (1:4.2-3.2) stretch; urgency=medium
+
+  * Add su-l pam.d stack and patch su to use it
+  * pam_pseudo_session: module to make minimal dummy XDG environment
+for su - style sessions
+
+ -- Vivek DasÂ Mohapatra   Wed, 27 Apr 2016 12:00:18 +0100
+
 shadow (1:4.2-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru shadow-4.2/debian/login.install shadow-4.2/debian/login.install
--- shadow-4.2/debian/login.install	2014-11-19 20:41:19.0 +
+++ shadow-4.2/debian/login.install	2016-04-27 19:29:03.0 +0100
@@ -17,9 +17,11 @@
 usr/share/man/man8/faillog.8
 usr/share/man/man8/lastlog.8
 usr/share/man/man8/nologin.8
+usr/share/man/man8/pam_pseudo_session.8
 usr/sbin/nologin
 usr/bin/faillog
 usr/bin/lastlog
 usr/bin/newgrp
 bin/login
 bin/su
+lib/*/security/*.so
diff -Nru shadow-4.2/debian/login.su-l.pam shadow-4.2/debian/login.su-l.pam
--- shadow-4.2/debian/login.su-l.pam	1970-01-01 01:00:00.0 +0100
+++ shadow-4.2/debian/login.su-l.pam	2016-04-27 19:36:54.0 +0100
@@ -0,0 +1,9 @@
+#%PAM-1.0
+auth 		include		su
+account		include		su
+password 	include		su
+session		optional	pam_keyinit.so force revoke
+session		include		su
+session 	optional 	pam_pseudo_session.so
+
+
diff -Nru shadow-4.2/debian/patches/470_su_pam_xdg_session shadow-4.2/debian/patches/470_su_pam_xdg_session
--- shadow-4.2/debian/patches/470_su_pam_xdg_session	1970-01-01 01:00:00.0 +0100
+++ shadow-4.2/debian/patches/470_su_pam_xdg_session	2016-04-27 19:23:20.0 +0100
@@ -0,0 +1,335 @@
+--- a/src/su.c
 b/src/su.c
+@@ -960,6 +960,7 @@
+ 
+ #ifdef USE_PAM
+ 	int ret;
++	const char *pam_service = NULL;
+ #endif/* USE_PAM */
+ 
+ 	old_debian_behavior = (getenv("SU_NO_SHELL_ARGS") != NULL);
+@@ -977,7 +978,8 @@
+ 	initenv ();
+ 
+ #ifdef USE_PAM
+-	ret = pam_start ("su", name, , );
++	pam_service = fakelogin ? "su-l" : "su";
++	ret = pam_start (pam_service, name, , );
+ 	if (PAM_SUCCESS != ret) {
+ 		SYSLOG ((LOG_ERR, "pam_start: error %d", ret);
+ 		fprintf (stderr,
+--- a/Makefile.am
 b/Makefile.am
+@@ -5,4 +5,5 @@
+ AUTOMAKE_OPTIONS = 1.5 dist-bzip2 foreign
+ 
+ SUBDIRS = po man libmisc lib src \
+-	contrib doc etc
++	contrib doc etc pam
++
+--- /dev/null
 b/pam/Makefile.am
+@@ -0,0 +1,12 @@
++pamdir = $(libdir)/security
++man_MANS = pam_pseudo_session.8
++pam_pseudo_session_la_SOURCES = pam_pseudo_session.c pam_pseudo_session.sym
++pam_pseudo_session_la_CFLAGS = $(AM_CFLAGS) -shared -fPIC -DPIC
++pam_pseudo_session_la_LDFLAGS = $(AM_LDFLAGS) \
++	-module \
++	-export-dynamic \
++	-avoid-version \
++-Wl,--version-script=$(top_srcdir)/pam/pam_pseudo_session.sym
++pam_pseudo_session_la_LIBADD = $(LIBPAM)
++
++pam_LTLIBRARIES = pam_pseudo_session.la
+--- /dev/null
 b/pam/pam_pseudo_session.sym
+@@ -0,0 +1,6 @@
++{
++global:
++pam_sm_close_session;
++pam_sm_open_session;
++local: *;
++};
+--- a/configure.in
 b/configure.in
+@@ -9,7 +9,7 @@
+ 
+ AC_GNU_SOURCE
+ 
+-AM_DISABLE_SHARED
++AM_ENABLE_SHARED
+ AM_ENABLE_STATIC
+ 
+ AM_MAINTAINER_MODE
+@@ -656,6 +656,7 @@
+ 	man/zh_TW/Makefile
+ 	libmisc/Makefile
+ 	lib/Makefile
++	pam/Makefile
+ 	src/Makefile
+ 	contrib/Makefile
+ 	etc/Makefile
+--- /dev/null
 b/pam/pam_pseudo_session.c
+@@ -0,0 +1,177 @@
++/* pam_pseudo_session module */
++
++/*
++ * Written by Vivek DasÂ Mohapatra  2016-04-26
++ * Copyright Â© Collabora Ltd 2016
++ * provides a pseudo-xdg set of environment variables and directories
++ * to allow basic functionality like systemd --test to work in a
++ * su - style user session. Explicitly does _not_ join the su -
++ * to an existing user XDG environment.
++ */
++
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++
++#define PAM_SM_SESSION
++#define XDG_PSEUDOTMP "/run/user/pseudo-xdg"
++
++
++#include 
++#include 
++#include 
++#include 
++
++static void safeprintf (char *buf, size_t limit, const char *format, ...)
++{
++  int written;
++  va_list ap;
++
++  va_start(ap, format);
++  written = vsnprintf(buf, limit - 1, format, ap);
++  va_end(ap);
++
++  if (written >= limit - 1)
++buf[limit - 1] = '\0';
++}
++
++static int
++get_user_data (pam_handle_t *handle, struct passwd** user)
++{
++  int result;
++  const char *name =

Bug#802224: Going forward with node-source-map

2016-05-01 Thread Julien Puydt


Hi,

I gave another try to fixing node-source-map this evening, and things 
look better -- at least running "require('source-map')" in nodejs 
actually works! There's still the lintian warning about that big 
bench/scalajs-runtime-sourcemap.js. As it's only used for the 
benchmarks, perhaps the whole bench/ directory should be pushed out of 
the a +dfsg tarball?


The case of the libjs-source-map package is more annoying : it basically 
ships the dist/ directory content, and those look like generated 
files... some using webpack, which we don't have (and I think needs a 
more recent source-map!)


I pushed my changes to the debian-js repository, so you can review it at 
your leisure.


What's your take on the matter?

Snark on #debian-js

Bug#822910: mutt-patched: silently dropped the sidebar-dotpathsep patch in favor of sidebar-dotted

2016-05-01 Thread Gian Piero Carrubba

severity 822910 wishlist
retitle -1 mutt-patched: allow configurable delim_chars in sidebar
thanks

Hi Evgeni,

thank you for your quick response.

* [Fri, Apr 29, 2016 at 07:21:03PM +0200] Evgeni Golov:

I personally prefer the sidebar-dotpathsep patch because:

- has a summary listing # of unread/flagged/total messages instead of
only unread/total

Flagged should be supported according to docs, I never tried that,
though.

Yeah, sorry I've initially missed it.

- has configurable mailboxes separator (in my case, the newly
reintroduced patch does not correctly display maildirs containing a
dot in the name)

Did you try setting sidebar_folderindent? That worked fine here with
dotted maildirs.

Yes, this is the pseudo-diff of my config:

- set sidebar_delim_chars = '/'
+ set sidebar_shortpath= yes
+ set sidebar_folderindent = yes

Also, I'm not using dotted maildirs (dir.maildir1, dir.maildir2, ...),
but nested dirs in which the leaf dirs are actually maildirs
(dir/maildir1, dir/maildir2, ...). The name of some dirs contains a dot.

i.e., the following tree (in which ham/spam are actually maildirs):

.Junk/
├── ham
└── spam

is rendered as:

.Junk
Junk/ham
Junk/spam

instead of:

.Junk
ham
spam

More important, the following tree (again, only inner dirs are maildir):

domain.tld/
├── server1
└── server2

is rendered as:

tld
tld/server1
tld/server2

instead of:

domain.tld
server1
server2

In this particular case, I'm "losing" infos about which domain the
server belongs to.

Anyway, while I think my directory tree is legit, I totally understand
if you don't want to support this case.

'sidebar_delim_chars' is
not valid anymore and 'sidebar_shortpath' can be used instead (sort of).

I've added some details in
https://anonscm.debian.org/cgit/pkg-mutt/mutt.git/commit/?id=00fe2d19fa615e25e10f9976a937358a42cd1be7
Could you have a look if that makes sense to you?

Seems fine to me (maybe just use sidebar_delim_chars instead of
delim_chars in order to point to the right option). As this is now
documented, I'm downgrading the severity to wishlist.

Thank you,
Gian Piero.

Bug#822184: libfontchooser-java - Add maven support

2016-05-01 Thread Yadickson Soto

good,

It's a similar implementation, only for testing.
You can close the ticket too.

kind regards

Bug#823172: Location not found, but library exists !!

2016-05-01 Thread Rainer Smeykal

Package: Tcl/Tk
Version: 8.6

pi@raspberrypi:~ $ cd /home/pi
pi@raspberrypi:~ $ tar -xzf scid_vs_pc-4.16.tgz
pi@raspberrypi:~ $ cd scid_vs_pc-4.16
pi@raspberrypi:~/scid_vs_pc-4.16 $ ./configure
Scid vs. PC configure - Makefile configuration program
Tcl/Tk version: 8.6
Your operating system is: Linux 4.1.13-v7+
  PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/;
SUPPORT_URL="http://www.raspbian.org/RaspbianForums;
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs;
Location of "tcl.h": /usr/include/tcl8.6
Location of "tk.h": /usr/include/tcl8.6
Location of Tcl 8.6 library: not found
Location of Tk 8.6 library: not found
Location of X11 library: not found
Checking if your system already has zlib installed: yes.

Not all settings could be determined! See above for details.

The default Makefile was written.
You will need to edit it before you can compile Scid.




Hope you can help,
Thanks Rainer

Bug#822184: libfontchooser-java - Add maven support

On Thu, 21 Apr 2016 17:26:13 -0430 Yadickson Soto 
wrote:
> Package: libfontchooser-java
> Version: 1.0.0-1
> 
> 
> Please add maven support to use this library.
> Thanks
> 
> Best regards

Hi,

I had a look at fontchooser too. It still appears to be useful because I
couldn't find a replacement class in OpenJDK. However the library is
rather old and is no longer developed. I couldn't find a pom.xml file on
mavencentral for fontchooser either and the sources are built with Ant
anyway.

If you want to provide a Maven pom for this package, we could provide
Maven artifacts too but as it stands, no other package would really
benefit from it at the moment.

Cheers,

Markus

signature.asc
Description: OpenPGP digital signature

Bug#822185: libcolorchooser-java - Add maven support

2016-05-01 Thread Yadickson Soto

Hi,

I will do so, you can close this ticket...

Best regards

Bug#821436: libtasn1-6: missing build-dep dblatex

2016-05-01 Thread William Bonnet

Hello
> The error message is red herring, the build will fail on up-to-date sid
> no matter whether dblatex is installed. The issue is in gtk-doc-tools,
> reassiging.
I experienced several weird compilation issues when rebuilding packages
from sid on ppc64 arch. This bug was one of them (mostly issues when
building packages with -j4 flag and reusing an environnement for several
builds).

This issue no longer happen with package currently in sid and a fresh
environnement. Thus i propose to close this bug. No need to keep it open
since i can now build. I will reopen it or recreate another if it
happens again.

Kind regards,

-- 
William BONNET

CTO & Founder / The IT Makers

william.bon...@theitmakers.com
GSM +33 689 376 977 
twitter @theitmakers




signature.asc
Description: OpenPGP digital signature

Bug#822185: libcolorchooser-java - Add maven support

On Sun, 1 May 2016 14:34:21 -0300 Yadickson Soto 
wrote:
> Hi Markus,
> 
> This is only for testing.
> This packages will be deprecated on the future?
> If JColorChooser is part of the openjdk, good for me, so I need change my
> test class to use this character.
> 
> Thank you
> Best regards

I will wait for feedback from other team members but I think we can
remove this package. It has no reverse dependencies and since
JColorChooser is part of OpenJDK now, it doesn't seem to be that useful
anymore. I'd suggest to adapt your tests to use JColorChooser instead.

Regards,

Markus

signature.asc
Description: OpenPGP digital signature

Bug#822679: [DSE-Dev] Bug#822679: closed by Laurent Bigonville <bi...@debian.org> (Bug#822679: fixed in libselinux 2.5-2)

2016-05-01 Thread Yuri D'Elia

On Sun, May 01 2016, Laurent Bigonville  wrote:
> It's only doing this if /proc is not mounted, something that should
> happen at early boot.
>
> libselinux needs to determine the status of selinux on the machine. This is 
> done by reading files
> under /proc.

libselinux should assume selinux is disabled if there's no proc, and
just do nothing.

Why the safe default cannot be followed here?
Can't "ls" just do it's work without policy until /proc is ready?

This is going to attempt mounting /proc in containers and generally mess
with event-based system initialization in unexpected ways.

I personally experienced this while setting up a testing environment
where selinux is _disabled_ and took me a while to track down why /proc
was getting mounted over and over again.

> If you want to change that, see with upstream.

Do I really have to?
This seems like a *very bad* idea in the first place.

Funny thing: unmount will now mount /proc.

Maybe I need to file a bugreport against mount.

Bug#822491: influxdb: Incompatible metadata format

2016-05-01 Thread Alexandre Viau

Hello,

On 25/04/16 10:44 AM, Matijs van Zuijlen wrote:
> At the very least, I think there should be an entry in the NEWS file to give
> people the earliest possible warning.

I agree with that, I wouldn't mind uploading a new version with an entry
in the NEWS file.

> What could in fact still be an option is to create a influxdb0.10 (or
> prefereably influxdb0.11) package so the old version is still present in 
> Debian.
> The NEWS entry could then point users to the 'old' package. This will allow
> users to easily install the old version, perform the first part of the upgrade
> procedure, and then go back to the most recent version.

It would be unfortunate to have to go trough NEW to upload a package
that we don't even want to ship. Its not like upstream still supports 0.11.

In the future, I think that one good way to handle this would be to
issue a warning preinst and canceling the upgrade on user request.

-- 
Alexandre Viau
av...@debian.org

signature.asc
Description: OpenPGP digital signature

Bug#783846: Patch to enable LEDs on sunix/Cubietruck

2016-05-01 Thread Simon Glass

Hi,

On 25 April 2016 at 03:18, Prof. Dr. Gundolf Kiefer
 wrote:
> On Mon, 25 Apr 2016 08:54:35 +0200
> Hans de Goede  wrote:
>
>> Hi,
>>
>> On 23-04-16 20:09, Prof. Dr. Gundolf Kiefer wrote:
>> > I would like to pass this question upstream. As what I can see from the
>> > code (arch/arm/dts/sun7i-a20-cubietruck.dts,
>> > configs/Cubietruck_defconfig), something actually has happened towards
>> > supporting GPIOs/LEDs for that board.
>> >
>> > Can somebody from the u-boot upstream team comment on this? Are LEDs
>> > supported now on the Cubietruck? Is additional testing required?
>>
>> The cubietruck leds are supported in the kernel. unxi u-boot does not
>> have LED support for any boards.
>>
>> And TBH I don't really see much use in LED support in u-boot.
>
> The reason why I needed LED support in u-boot was to give the user a
> sufficiently quick visible feedback when the device is switched on,
> i.e. a software-controlled power-on indicator. If the LEDs can only be
> controlled by the kernel, it may take seconds during which the user of
> has no chance to see if the device actually has power or not. Perhaps
> for the same reason, the legacy u-boot-sunxi fork
> (http://linux-sunxi.org/) had LED support.
>
> I personally feel that the possibility to switch on LEDs before the
> kernel is booted is not just a useful, but an important feature. And I
> would regret seeing it disappear when moving from the legacy sunxi fork
> to mainline u-boot.
>
> But, of course, it is up to the developers and package maintainers to
> decide which features are intergrated and which are not. Feel free to
> decide if the patch I provided can improve the package or not.

There is the LED_GPIO Kconfig option if you are using the normal
device tree binding for GPIOs. You can use led_get_by_label() to get
an LED by label. The fully API is in led.h.

Regards,
Simon

>
> Regards,
>
> Gundolf
>
>>
>> Regards,
>>
>> Hans
>>
>> >
>> > Regards,
>> >
>> > Gundolf Kiefer
>> >
>> >
>> > On Sat, 16 Apr 2016 14:55:54 -0700
>> > Vagrant Cascadian  wrote:
>> >
>> >> Control: tags 783846 moreinfo upstream
>> >> Control: forwarded 783846 
>> >> http://lists.denx.de/pipermail/u-boot/2015-May/214036.html
>> >> Control: found 783846 2014.10+dfsg1-5
>> >>
>> >> On 2015-05-05, Vagrant Cascadian wrote:
>> >>> On 2015-04-30, Prof. Dr. Gundolf Kiefer wrote:
>>  It seems that the support for the onboard leds is missing for
>>  sunxi-based boards even in the latest version (Debian unstable). IMHO
>>  LEDs are very helpful for headless systems.
>> >>>
>> >>> Thanks for the patches!
>> >>>
>> >>> If you could submit these patches to u-boot upstream, that would be
>> >>> best; we're trying to minimize the patches that are not already included
>> >>> upstream.
>> >>
>> >> It looks like you attempted to get these upstream, though it doesn't
>> >> sound like they were accepted at the time. Is the bug still present in
>> >> current versions of u-boot (2016.03+ in Debian)?
>> >>
>> >> Thanks!
>> >>
>> >> live well,
>> >>vagrant
>> >
>
>
>
>
> ---
> Prof. Dr. Gundolf Kiefer
> Effiziente Eingebettete Systeme  -  Efficient Embedded Systems
> Fakultät für Informatik  -  Faculty of Computer Science
> Hochschule Augsburg - University of Applied Sciences
> http://ees.hs-augsburg.de
> ---

Bug#823162: pseudo: wrong update-alternatives call in postinst

2016-05-01 Thread Andrew Shadura

On 1 May 2016 at 18:40, Gian Piero Carrubba  wrote:
> This bug is presumably related to #805937, but I'm reporting it alone as
> it prevents a smooth installation of the package.

> The pseudo package does not contain the fakeroot-pseudo wrapper (as a
> fix for #805937 ?):

Oops, that was a mistake. I'll upload a fixed version tomorrow.

-- 
Cheers,
  Andrew

Bug#823086: virtualbox: Fix LSB init output

2016-05-01 Thread Gianfranco Costamagna

control: tags -1 pending

Hi,

thanks for the patch, applied on git!


I would upload it on the next month or so, let me know if you want a speedy 
upload!



chers,

G.

Il Sabato 30 Aprile 2016 17:06, Guillem Jover  ha scritto:
Source: virtualbox
Source-Version: 5.0.20-dfsg-1
Severity: wishlist
Tags: patch

Hi!

The attached patch fixes the LSB init script to have more consistent
output.

Thanks,
Guillem

Bug#823170: golang-testify: Vendors code without attribution

2016-05-01 Thread Martín Ferrari

Source: golang-testify
Severity: serious
Justification: Policy 12.5

This package is embedding source code for three other distributions without
attribution in debian/copyright:

vendor/github.com/davecgh/go-spew
vendor/github.com/pmezard/go-difflib
vendor/github.com/stretchr/objx


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

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

Bug#822697: general: qt5 apps in gnome do not use the gtk style as they should

2016-05-01 Thread Dmitry Shachnev

Hi Miguel,

On Sun, May 01, 2016 at 09:40:01AM +0100, Miguel Negrão wrote:
> Out of curiosity, what does gtk+ integration provide besides the style
> (sorry, newbiw here) ?

Using system settings (for fonts, icon themes, etc); using GTK+ dialogs
(file chooser, color/font dialogs).

> From user perspective, with qt 5.7 will there be the need of installing
> more additional packages ?

The package with GTK+ integration will be recommended, so automatically
installed in most cases.

> And for the style, the user will have to compile or get one from somewhere
> else, correct ?

I think we can package Adwaita-Qt. The only reason why I hadn't yet done it
is lack of time.

--
Dmitry Shachnev

signature.asc
Description: PGP signature

Bug#822617: Missing symlinks to match locales

2016-05-01 Thread Gunnar Hjalmarsson

Hi Rene,

On 2016-05-01 15:44, Rene Engelhard wrote:
> How does this affect firefox, scribus, abiword  and whoever else uses
> them?[1]
> ...
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821772

I haven't tested with all those applications, but I did some tests with
Firefox and gedit. In general both of those work in a simplistic manner;
their spellcheck menus show everything in /usr/share/hunspell. One
exception: gedit doesn't show sr-Latn.{aff,dic} but it shows
sr_Latn_RS.{aff,dic} (with the label "Unknown (sr_Latn_RS)", but still).

It should be said that the use of symlinks corresponding to available
system locales isn't new, neither in Debian nor Ubuntu. You find them in
many other source packages which build hunspell-*, hyphen-*, etc. Also
the previous lo-dicts in Ubuntu, which was introduced in Ubuntu 14.04,
has such symlinks. So possible issues in other applications should have
been reported long ago.

One thing which *is* new in the latest lo-dicts is that it does not
provide stuff in /usr/share/myspell/dicts and
/usr/share/myspell/infos/ooo. Personally I'm not aware of any
application where it would make a difference. (OTOH I haven't researched
it.) I trust that you are reasonably sure that they aren't needed.

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

Bug#811571: [Python-apps-team] Bug#811571: ocrfeeder: Unicode characters break exports

2016-05-01 Thread Alberto Garcia

Control: tags -1 fixed-upstream pending

On Sun, Apr 17, 2016 at 11:15:11AM +0200, Jean-Marc wrote:

> > I attached a PFD file I used to test ocrfeeder.

This has just been fixed upstream. I'll probably update the Debian
package with the fix for this bug one of these days, but if you want to
try it yourself here's the change:

https://git.gnome.org/browse/ocrfeeder/commit/?id=691f54618ed17a2553f154af07a6cfb4bf887e09

Berto

Bug#823169: bup: restore --sparse may corrupt data

2016-05-01 Thread Rob Browning


Package: bup
Version: 0.27-2
Severity: important

In 0.27, "restore --sparse" may produce corrupt data, so for now, it
should be avoided.

I suppose in the short term, it might even make sense to upload a
version of the package with a patch like this:

  diff --git a/cmd/restore-cmd.py b/cmd/restore-cmd.py
  index d527489..0b649a1 100755
  --- a/cmd/restore-cmd.py
  +++ b/cmd/restore-cmd.py
  @@ -290,6 +290,10 @@ handle_ctrl_c()
   o = options.Options(optspec)
   (opt, flags, extra) = o.parse(sys.argv[1:])

  +if opt.sparse:
  +log('ERROR: --sparse is currently broken (may corrupt data)')
  +sys.exit(1)
  +
   git.check_repo_or_die()
   top = vfs.RefList(None)


In any case, a 0.27.1 release should fix this *soon*.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#822679: [DSE-Dev] Bug#822679: closed by Laurent Bigonville <bi...@debian.org> (Bug#822679: fixed in libselinux 2.5-2)

2016-05-01 Thread Laurent Bigonville


Le 01/05/16 à 14:00, Yuri D'Elia a écrit :

I'm_not_  happy with the solution here.

This will*still*  cause regular userland utilities, such as ls on
Debian, to mount /proc when you least expect it to.

libselinux must just bail gracefully if /proc is not mounted.


It's only doing this if /proc is not mounted, something that should 
happen at early boot.


libselinux needs to determine the status of selinux on the machine. This 
is done by reading files under /proc.


If you want to change that, see with upstream.

Bug#806889: [pkg-wpa-devel] Bug#806889: wpasupplicant: New upstream version (2.5)

2016-05-01 Thread Faidon Liambotis

On Sun, May 01, 2016 at 07:04:56PM +0200, Stefan Lippers-Hollmann wrote:
> > Moreover, there are several open bug reports that may have been fixed by
> > a new version (e.g. #815121) or can be easily fixed or closed (e.g.
> > #729934).
> 
> #729934 will indeed by fixed by the next upload/ binNMU, thanks to the
> new dbgsym packages introduced by dh.

Indeed — but the point was that the bug queue for wpa seems to be
largely untriaged. #729934 was just an example of a 2½-year old bug
report with no response whatsoever, that's even now at a stage that
basically now needs zero effort from your side to fix, due to toolchain
changes.

> I'm still debugging the 4addr regression mentioned in my previous mail,
> given the rather unfortunate approach to reproduce it, testing takes
> about a week for each iteration (unless it fails early by chance, so
> far I've seen time to failure up to 3-4 days, even though it often 
> within hours). Replacing one bug with another doesn't sound like a good
> tradeoff to me.

Sure it does.

This regression has been reported by only you, occurs only in very
specific circumstances (both wpasupplicant and hostapd, hard to
reproduce as you yourself say), and hasn't been a blocker to the rest of
the Linux world carrying this new upstream version since it was
released, more than half a year to a year (depending on whether it's a
2.5 or 2.4 regression). It hasn't been such a big deal to upstream
either, since they haven't released an updated version fixing such a
bug. Clearly not a very important bug then, no?. (plus, are you really
working on it? it's been a month and a half since you last said anything
on this bug report; have you contacted your upstream?)

On the other hand, we have *two* major new upstream releases that will
close at least a few Debian bug reports, plus incorporate all kinds of
fixes and new features that upstream has implemented in the year between
2.3 and 2.5. Such an example would be Network Manager 1.2's MAC address
randomization while scanning, a pretty important feature from a privacy
perspective.

Thanks,
Faidon

Bug#803173: [mediatomb] Cannot start

2016-05-01 Thread Antonio Marcos López Alonso

> 
> > I always have to manually start the service and log spits:
> I think having to start the service manually is a separate bug which
> I've filed as #823153.
> As a workaround you can run "systemctl enable mediatomb".
> 

Nice. It works!

> > 2016-03-19 14:58:06INFO: Configuration check succeeded. 
> > 2016-03-19 14:58:06INFO: Initialized port: 50500 
> > 2016-03-19 14:58:06INFO: Server bound to: 192.168.1.36 
> > 2016-03-19 14:58:07INFO: MediaTomb Web UI can be reached by following
> > this link:  2016-03-19 14:58:07INFO: http://192.168.1.36:50500/
> > 2016-03-20 08:12:54   ERROR: Exception caught: Failed to stat
> > /usr/local/share/datos/tmp/Incoming/tmp/001.part.met.backup , No existe
> > el fichero o el directorio 
> [...]
> 
> I don't know what's wrong there I'm afraid (and I don't use mediatomb
> that much). Have you checked the config files to see why mediatomb is
> reading those files (/usr/local/share/datos is a strange directory
> name) and does the file actually exist?
> 
> Thanks,
> James

No, that file does not exist but that directory does as it is a custom path of 
my own. I think it could be some kind of a leftover temp file so I guess 
mediatomb somehow has kept it recorded in its database and didn't wiped it 
out. I should look for some option to flush the DB.

Thanks again for your help,
Antonio

Bug#823168: ITP: pyinfra -- state based and programmable server provisioning tool

2016-05-01 Thread Daniel Stender

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 

* Package name: pyinfra
  Version : 0.1~dev19
  Upstream Author : Nick Barrett 
* URL : https://github.com/Fizzadar/pyinfra
* License : Expat
  Programming Lang: Python
  Description : state based and programmable server provisioning tool

Pyinfra is a server provisioner written in Python. It's state based (you could 
define
states for servers like "has mysql running") and agent less (it doesn't need a 
daemon
to run on target servers) like other deployment systems, but it's fully 
programmable
in Python [1]. It's a promising new project.

I'm going to maintain this within the PAPT team, the binary is going to be 
"pyinfra".

Thanks,
DS

[1] (If reading German,) see Tim Schürmann: "Schlangenöl: automatisiertes 
Server-Deployment
mit Pyinfra". In: IT-Administrator 05/2016, S. 90-95.

Bug#822827: python3-pyqt5: qt5-5-1 abi dependencies makes install impossible against Qt5.6

2016-05-01 Thread Dmitry Shachnev

Control: notfound -1 5.6
Control: found -1 pyqt5/5.6+dfsg-1
Control: fixed -1 pyqt5/5.6+dfsg-2

Hi Marc,

On Wed, Apr 27, 2016 at 05:53:18PM -0700, Marc J. Driftmeyer wrote:
> Yet, in Debian we get this:
>
> python3-pyqt5 depends on qtbase-abi-5-5-1
> qtbase-abi-5-5-1 does not appear to be available
> python3-pyqt5 suggests python3-pyqt5-dbg
>
> I hope this is an oversight. As of now its useless against Qt 5.6.0 which 
> being in Sid.

I have uploaded a PyQt version built against Qt 5.6 to experimental.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#822185: libcolorchooser-java - Add maven support

2016-05-01 Thread Yadickson Soto

Hi Markus,

This is only for testing.
This packages will be deprecated on the future?
If JColorChooser is part of the openjdk, good for me, so I need change my
test class to use this character.

Thank you
Best regards

Bug#822185: libcolorchooser-java - Add maven support

On Thu, 21 Apr 2016 17:27:34 -0430 Yadickson Soto 
wrote:
> Package: libcolorchooser-java
> Version: 1.0+dfsg-1
> 
> 
> Please add maven support to use this library.
> Thanks
> 

Hi,

I'm not sure if this library is still useful and if we should keep it
because its functionality is now part of the JDK (class JColorChooser).
Do you need a feature that is not provided by JColorChooser ?

https://docs.oracle.com/javase/tutorial/uiswing/components/colorchooser.html

Regards,

Markus

signature.asc
Description: OpenPGP digital signature

Bug#823167: add architecture tilegx

2016-05-01 Thread Helmut Grohne

Package: dpkg
Version: 1.18.4
User: helm...@debian.org
Usertags: rebootstrap

Hi,

This is the first of a series of patches to add support for the TILE-Gx
architecture to Debian. My first target is dpkg, which needs to learn
about the architecture name.

There is already a CentOS based port available at
http://www.mellanox.com/repository/solutions/tile-scm/source.html. It
uses the GNU triplet tilegx-linux-gnu. Thus the GNU CPU name should
simply be tilegx. I believe that the Debian architecture name should
also simply be tilegx. Some tooling seems to understand about other
variants tilepro-linux-gnu and tilegxbe-linux-gnu, both of which refer
to different ABIs. Thus the config.guess regular expression should not
over-match. TILE-Gx is little endian 64 bit. Stinging this together in
the dpkg cputable format, we arrive at:

# 
tilegx  tilegx tilegx   64 little

I put Chris Metcalf into Cc, to have him review the assertions made
above.

Rationale for adding TILE-Gx to Debian:

I have a working patch stack to build a cross toolchain and to cross
build 30 source packages. The architecture is so well upstreamed, that
none of my patches (pending submission) touch any C code. The CentOS
based port covers about 5000 source packages. Basic hardware is
available below $ 1000.

Helmut

Bug#818072: warzone2100: FTBFS in stretch (new flex)