Bug#814316: Confirming bug

[Christopher Schramm]

09.06.2016 06:49 Chris Dellin:
> If anyone knows a functional workaround, please let me know!  (My
> understanding is that Debian 7 should have security support until May
> 2018 [2].)

Put the libflashplayer.so file contained in the .tar.gz from
https://get.adobe.com/de/flashplayer/ at
/usr/lib/flashplugin-nonfree/libflashplayer.so.

Bug#822494: Time to remove? Unusable since 2014.

[Petter Reinholdtsen]

[Ryan Kavanagh]
> I've fixed a bunch of lintian warnings and other small things. Operating
> on the assumption that the database of streams will be brought to
> date/cleaned up, I'll upload the package after giving it a final look
> over with fresh eyes tomorrow.

Very good.  It work for me in Jessie, at least.

If you, like me, struggle to find a working stream, I am happy to report
that the TV channel I am involved in, Frikanalen, is in the database now
and its stream is currently working.
-- 
Happy hacking
Petter Reinholdtsen

Bug#826790: libset-scalar-perl: Package doesn't support multi-arch

[Aexander]

Package: libset-scalar-perl
Version: 1.29-1
Severity: normal

Dear Maintainer,
Package libva-dev (1.7.0-2) has as a new dependency libset-scalar-perl. Can't 
install libva-dev:i386 as libset-scalar-perl:i386 is unavailable.

Updating debian/compat and adding "Multi-Arch: foreign" to debian/control 
appears sufficient to install it & satisfy libva-dev:i386.


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

Kernel: Linux 4.5.0-2-amd64 (SMP w/3 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 libset-scalar-perl depends on:
ii  perl  5.22.2-1

libset-scalar-perl recommends no packages.

libset-scalar-perl suggests no packages.

-- no debconf information

Bug#826789: ncal still reports wrong week number

[Morten Werner Forsbring]

Package: bsdmainutils
Version: 9.0.10

Hi.

ncal still reports the incorrect week number:

  $ date
  Thu Jun  9 06:42:48 CEST 2016
  $ date +%V
  23
  $ ncal -w
  June 2016 
  Su 5 12 19 26   
  Mo 6 13 20 27   
  Tu 7 14 21 28   
  We  1  8 15 22 29   
  Th  2  9 16 23 30   
  Fr  3 10 17 24  
  Sa  4 11 18 25  
 23 24 25 26 27   
  $ locale
  LANG=en_US.utf8
  LANGUAGE=
  LC_CTYPE="en_US.utf8"
  LC_NUMERIC="en_US.utf8"
  LC_TIME="en_US.utf8"
  LC_COLLATE="en_US.utf8"
  LC_MONETARY="en_US.utf8"
  LC_MESSAGES="en_US.utf8"
  LC_PAPER="en_US.utf8"
  LC_NAME="en_US.utf8"
  LC_ADDRESS="en_US.utf8"
  LC_TELEPHONE="en_US.utf8"
  LC_MEASUREMENT="en_US.utf8"
  LC_IDENTIFICATION="en_US.utf8"
  LC_ALL=
  $ dpkg -l |grep bsdmain
  ii  bsdmainutils   9.0.10

Please let me know if you need more information?

A very similar issue was reported (and maybe fixed) here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676426


- Werner

Bug#814316: Confirming bug

[Chris Dellin]

I'm still having this issue on my system.

As a summary, the security update to version 11.2.202.621 published by
Adobe on May 12 [0] fixes the following 31 CVEs:

CVE-2016-1096, CVE-2016-1097, CVE-2016-1098, CVE-2016-1099, CVE-2016-1100,
CVE-2016-1101, CVE-2016-1102, CVE-2016-1103, CVE-2016-1104, CVE-2016-1105,
CVE-2016-1106, CVE-2016-1107, CVE-2016-1108, CVE-2016-1109, CVE-2016-1110,
CVE-2016-4108, CVE-2016-4109, CVE-2016-4110, CVE-2016-4111, CVE-2016-4112,
CVE-2016-4113, CVE-2016-4114, CVE-2016-4115, CVE-2016-4116, CVE-2016-4117,
CVE-2016-4120, CVE-2016-4121, CVE-2016-4160, CVE-2016-4161, CVE-2016-4162,
CVE-2016-4163

Each of the 31 vulnerabilities is reported to possibly lead to code
execution, including via buffer overflow, use-after-free, and memory
corruption bugs.  The update is given the highest severity by Adobe:

Critical - A vulnerability, which, if exploited would allow malicious
native-code to execute, potentially without a user being aware. [1]

If anyone knows a functional workaround, please let me know!  (My
understanding is that Debian 7 should have security support until May 2018
[2].)

Cheers,
- Chris

[0] https://helpx.adobe.com/security/products/flash-player/apsb16-15.html
[1] https://helpx.adobe.com/security/severity-ratings.html
[2] https://wiki.debian.org/LTS/

Bug#824928: letsencrypt.sh: move the default position of the domains file to /etc/letsencrypt.sh/

[Daniel Beyer]

Hi Mattia,

sorry for the very late response.

On Thu, 2016-06-02 at 11:14 +, Mattia Rizzolo wrote:
> On Sat, May 21, 2016 at 06:07:34PM +, Mattia Rizzolo wrote:
> > On Sat, May 21, 2016 at 07:14:05PM +0200, Daniel Beyer wrote:
> > > I opened a PR for upstream [1], based on the initial work you gave me.
>
> (...)
> 
> In the meantime a new release happened, and our patch has been merged
> the commit right after the release one, useful.

That's bad luck. Let's stick with the patch for now.

> Anyway, I imported the new upstream release, and pulled your changes in
> debian/master.

Okay, thanks.


> > > But I have the feeling, that mentioning the
> > > change in d/NEWS is not enough.
> > 
> > I'd also keep in mind that this package is very young while considering
> > this.

That's true, hence I think it's worth the extra work - at least for the
jessie-backports version.


> > > So i came up with the following idea (not implemented, yet):
> > > (...)
> > > Do you have an other idea or opinion how to deal with this?
> > 
> > That's a nice idea, even if I usually try to avoid having to deal with
> > maintainer scripts.
> > Anyway doing this also requires:
> > * checking that /etc/letsencrypt.sh/config.sh actually has DOMAINS_TXT
> >   set to the new location (if the user modified it, dpkg won't overwrite
> >   it with our new copy with our new conf)
> > * also adding a prerm to remove that file in case of purge

Thanks for the input, I'll keep this in mind.


> > Also, I'd like to not keep that thing forever, e.g. drop this
> > transitional measure before stretch: I'm usually happier if my packages
> > don't have maintainer scripts.

I fully agree. Let's keep it some time and drop it out before the
stretch freeze.


> Are you willing to do this?
> I'm now running current debian/master, after having moved files around.

Definitely, I work on this today and tomorrow.


> With 0.2.0 there is also another incompatible change: the PRIVATE_KEY =>
> ACCOUNT_KEY rename which actually bit me even if I was aware of it; do
> we want to provide a backward compatible thing and carry on some kind of
> deprecation procedure (like: using something like
> ACCOUNT_KEY=${ACCOUNT_KEY:-${PRIVATE_KEY}} somewhere and keeping it for
> a while)

It would be a nice service for our users (just like the domains.txt
stuff). So I would say: Yes and drop it before the stretch freeze.


> > > An other question is whether or not we should start shipping
> > > a /etc/letsencrypt.sh/domains.txt. (...) What do you think?
> > 
> > Yes :)

Okay, let's ship it.

> > Also notice the relative file in the new docs/ directory in the upstream
> > repo (I'd like to ship all that documentation when a new release will
> > happen).

I saw you already took care about the docs, thanks.

> In the new package there is a
> /usr/share/doc/letsencrypt.sh/docs/domains_txt.md which imho contains
> everything needed.

Great, so we can simply point to it in /etc/letsencrypt.sh/domains.txt.

> And if we provide an empty domains.txt, we should also first patch the
> script to return a useful message instead of saying nothing and just
> exit 0.

That's true. It might be worth to forward this upstream (once
implemented).


I'll get back to you as soon I have implemented something useful here.

Greetings
Daniel


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

Bug#826788: fsck run before unmounting?; failed unmounting /home.

[積丹尼 Dan Jacobson]

Package: systemd
Version: 230-2

Here we see fsck is apparently run _before_ unmounting file systems.

And maybe that is why we see
Failed unmounting /home?

Also there is a Failed unmounting /tmp I can send if you are interested.

# ls -lR /dev/disk/|grep 9405199517
lrwxrwxrwx 1 root root 10 06-09 11:45 355d426a-cbfc-4faf-91d6-4f9405199517 -> 
../../sda6
# mount|grep sda6
/dev/sda6 on /home type ext4 (rw,relatime,commit=111,data=ordered)
# egrep /home\|4f9405199517 /shutdown-log.txt
[ 2283.119012] systemd[1]: 
systemd-fsck@dev-disk-by\x2duuid-355d426a\x2dcbfc\x2d4faf\x2d91d6\x2d4f9405199517.service:
 Installed new job 
systemd-fsck@dev-disk-by\x2duuid-355d426a\x2dcbfc\x2d4faf\x2d91d6\x2d4f9405199517.service/stop
 as 293
[ 2284.362447] systemd[1]: home.mount: About to execute: /bin/umount /home
[ 2284.363088] systemd[1]: Unmounting /home...
[ 2284.368330] systemd[1846]: home.mount: Executing: /bin/umount /home
[ 2284.422580] systemd[1]: Failed unmounting /home.
[ 2284.451706] systemd[1]: Got cgroup empty notification for: 
/system.slice/home.mount
[ 2284.451805] systemd[1]: Got cgroup empty notification for: 
/system.slice/home.mount
[ 2284.468145] systemd[1]: 
systemd-fsck@dev-disk-by\x2duuid-355d426a\x2dcbfc\x2d4faf\x2d91d6\x2d4f9405199517.service:
 Changed exited -> dead
[ 2284.468175] systemd[1]: 
systemd-fsck@dev-disk-by\x2duuid-355d426a\x2dcbfc\x2d4faf\x2d91d6\x2d4f9405199517.service:
 Job 
systemd-fsck@dev-disk-by\x2duuid-355d426a\x2dcbfc\x2d4faf\x2d91d6\x2d4f9405199517.service/stop
 finished, result=done
[ 2284.468199] systemd[1]: Stopped File System Check on 
/dev/disk/by-uuid/355d426a-cbfc-4faf-91d6-4f9405199517.
[ 2284.786804] systemd[1]: 
dev-disk-by\x2duuid-355d426a\x2dcbfc\x2d4faf\x2d91d6\x2d4f9405199517.device: 
Failed to send unit remove signal for 
dev-disk-by\x2duuid-355d426a\x2dcbfc\x2d4faf\x2d91d6\x2d4f9405199517.device: 
Transport endpoint is not connected
[ 2284.793669] systemd[1]: 
systemd-fsck@dev-disk-by\x2duuid-355d426a\x2dcbfc\x2d4faf\x2d91d6\x2d4f9405199517.service:
 Failed to send unit remove signal for 
systemd-fsck@dev-disk-by\x2duuid-355d426a\x2dcbfc\x2d4faf\x2d91d6\x2d4f9405199517.service:
 Transport endpoint is not connected
[ 2284.888398] systemd-shutdown[1]: Remounting '/home' read-only with options 
'commit=111,data=ordered'.
[ 2285.086788] systemd-shutdown[1]: Unmounting /home.


/var is also on its own partition, but umount succeeds.

# mount|grep /dev/sda
/dev/sda8 on / type ext4 (rw,relatime,errors=remount-ro,commit=111,data=ordered)
/dev/sda7 on /var type ext4 (rw,relatime,commit=111,data=ordered)
/dev/sda6 on /home type ext4 (rw,relatime,commit=111,data=ordered)
# mount|grep /tmp
tmpfs on /tmp type tmpfs (rw,relatime)

I made the log via
# set /lib/systemd/system-shutdown/debug.sh; ls -l $@; cat $@
-rwxr-xr-x 1 root root 80 06-07 21:24 /lib/systemd/system-shutdown/debug.sh
#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /
# sed s/.*sys/sys/ /proc/cmdline
systemd.log_target=kmsg log_buf_len=10M enforcing=0

Bug#826787: bubblewrap: Fails to build from source on Ubuntu

[Jeremy Bicha]

Package: bubblewrap
Version: 0.1.0-1
Tags: patch


bubblewrap doesn't build in Ubuntu:

https://launchpad.net/ubuntu/+source/bubblewrap/0.1.0-1/+build/9877262

The below patch works for me. I don't know a lot about SELinux on
Ubuntu except that most Ubuntu users don't use it.

Thanks,
Jeremy Bicha

=== modified file 'debian/rules'
--- debian/rules 2016-06-09 03:36:01 +
+++ debian/rules 2016-06-09 04:04:03 +
@@ -6,8 +6,14 @@

 PKGDIR=$(CURDIR)/debian/bubblewrap

+configure_flags += --with-priv-mode=setuid
+
+ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
+ configure_flags += --disable-selinux
+endif
+
 override_dh_auto_configure:
- dh_auto_configure -- --with-priv-mode=setuid
+ dh_auto_configure -- $(configure_flags)

 override_dh_fixperms:
  chmod a+x $(PKGDIR)/usr/share/bash-completion/completions/bwrap

Bug#821723: Fwd: zeroc-ice_3.6.2-stretch+git1+6f49504-1_amd64.changes ACCEPTED into unstable, unstable

[Logan Rosen]

Hi,

On Wed, 08 Jun 2016 16:30:40 +0200 Ondřej Surý  wrote:
> Version: 3.6.2-stretch+git1+6f49504-1
>
> Hey all,
>
> I have just uploaded 3.6.2 with php7 support. So this is the last
> non-swig package blocking PHP 7.0 transition.

This upload appears to have had the side effect of removing the
appropriate dependencies on PHP. The php5* dependencies should have
been changed to php* dependencies, not removed.

Thanks for your work on transitioning this package!

Logan

Bug#826730: puppet: conffiles not removed

[Paul Wise]

On Wed, 2016-06-08 at 20:29 +0800, Paul Wise wrote:

> I upgraded from puppet 3.8.5-2 to 4.5.0-4 and purged version 3.8.5-2
> of puppet-common at the same time.

In case you want to see it, here is the log of the puppet parts of the
upgrade where the init script was not removed/transitioned:

dpkg: puppet-common: dependency problems, but removing anyway as you requested:
 puppet depends on puppet-common (= 3.8.5-2).

(Reading database ... 386499 files and directories currently installed.)
Removing puppet-common (3.8.5-2) ...
Purging configuration files for puppet-common (3.8.5-2) ...
dpkg: warning: while removing puppet-common, directory '/etc/puppet' not empty 
so not removed
Processing triggers for man-db (2.7.5-1) ...
(Reading database ... 385203 files and directories currently installed.)
Preparing to unpack .../puppet_4.5.0-4_all.deb ...
Unpacking puppet (4.5.0-4) over (3.8.5-2) ...

...

Setting up puppet (4.5.0-4) ...

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#824930: [Android-tools-devel] Bug#824930: Bug#824930: Bug#824930: Bug#824930: apktool: creates directories and an empty 1.apk file in $HOME contain

[Paul Wise]

On Thu, 2016-06-09 at 00:32 +0530, Chirayu Desai wrote:

> This was discussed on IRC, and since we already need to build
> framework-res.apk for android.jar (it is extracted and the contents
> are included as-is in the jar), we can also have a separate package
> for it, which I have ready at:

Excellent, perfect resolution to this issue!

It sounds like the package that will contain android.jar should have
Built-Using set to android-framework-res (= $version) so that the
Debian archive will keep the right version available.

> https://gitlab.com/cde/debian_android-tools_android-platform-frameworks-base/commit/1ea978033eb92e0c7c14f1ca40c61d84b2a2e7f1

Nitpicks:

You don't need dh-exec for android-framework-res.install

The android-framework-res package description needs filling out.

I would have put the contents of debian/framework-res.mk into
debian/rules and debian/clean instead.

> I have a patch locally that makes it use ~/.local/share/apktool, can
> update it / push it as preferred.

If the android-framework-res package is installed (should be in the
apktool Depends), I don't think apktool should create any directories
or files in ~/ until the user manually installs another framework.

I don't know enough about which of ~/.local or ~/.cache should be
preferred but it definitely should use one of them instead of what the
upstream developers have chosen.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#826737: Please package paramiko >= 2.0 in Experimental

[Jeremy T. Bouse]

If my assessment isn't acceptable... We can take the upstreams
(http://www.paramiko.org/changelog.html) which states:

Warning

*This is a backwards incompatible change.*

However, *it should only affect installation* requirements; *no API
changes are intended or expected*. Please report any such breakages as bugs.

Which is exactly as I stated... installation requirement change but no
API change.

On 6/8/2016 9:02 PM, Jeremy T. Bouse wrote:
> I've looked at the paramiko.RSAKey code for 1.16, 1.17 and 2.0 ... Aside
> from changing from python-crypto to python-cryptography I see no
> evidence to support that the API is incompatible as they have same
> exposed calls and parameters. Those functions simply use the different
> library calls under the hood. Unless other packages are making calls to
> internal functions they shouldn't be, which would be a bug in and of
> itself, there shouldn't be any issues. The paramiko package will pull in
> python-cryptography instead of python-crypto and there is no Conflicts
> in place to hinder their package still maintaining python-crypto in
> their dependencies.
>
>
> On 6/8/2016 8:12 PM, Thomas Goirand wrote:
>> On 06/08/2016 03:33 PM, Jeremy T. Bouse wrote:
>>> Thank you for the report Thomas; however, if you'd taken a beat to check
>>> or even contact the maintainer (ie- me) you would have found that this
>>> is already being worked on... That said I'm not bothering with
>>> experimental as it's a released version of Paramiko.
>>>
>>> https://github.com/jbouse-debian/paramiko/tree/upstream/2.0.0
>> IMO, you should bother indeed, because the paramiko.RSAKey API is
>> incompatible with what was in 1.x, so you should let other maintainers
>> fix their packages, and give them enough time to do so (ie: transition).
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>

Bug#528407: (no subject)

[Fernando Seiti Furusato]

Source: dancer-xml
Followup-For: Bug #528407

Hello.

Not sure if this package is still actively maintained, but since it
still fails on ppc64el et al, here is a debdiff adding usage of 
dh-autoreconf.

It is similiar to the one above, but uses autoreconf for a more
complete autotools files update during build, and its usage is
approached here https://wiki.debian.org/Autoreconf.

Regards.

Fernando
diff -u dancer-xml-0.8.2.1/debian/changelog dancer-xml-0.8.2.1/debian/changelog
--- dancer-xml-0.8.2.1/debian/changelog
+++ dancer-xml-0.8.2.1/debian/changelog
@@ -1,3 +1,13 @@
+dancer-xml (0.8.2.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Adding dh_autoreconf to update autotools files.
+  * debian/control: dh-autoreconf to build-dep.
+  * debian/patches/autoreconf.patch: added AM_INIT_AUTOMAKE([foreign])
+to configure.ac in order to create missing files.
+
+ -- Fernando Seiti Furusato   Wed, 08 Jun 2016 16:31:50 -0400
+
 dancer-xml (0.8.2.1-3) unstable; urgency=low
 
   * Bug fix: "dxml-db2latex doesn't start, missing dependency on
diff -u dancer-xml-0.8.2.1/debian/control dancer-xml-0.8.2.1/debian/control
--- dancer-xml-0.8.2.1/debian/control
+++ dancer-xml-0.8.2.1/debian/control
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Junichi Uekawa 
-Build-Depends: debhelper (>> 4.0.0), libtool, d-shlibs (>= 0.4), doxygen
+Build-Depends: debhelper (>> 4.0.0), libtool, d-shlibs (>= 0.4), doxygen, dh-autoreconf
 Standards-Version: 3.6.2
 
 Package: libdancer-xml0
diff -u dancer-xml-0.8.2.1/debian/rules dancer-xml-0.8.2.1/debian/rules
--- dancer-xml-0.8.2.1/debian/rules
+++ dancer-xml-0.8.2.1/debian/rules
@@ -14,6 +14,7 @@
 configure-stamp:
 	dh_testdir
 	# Add here commands to configure the package.
+	dh_autoreconf
 	./configure -prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc
 	touch configure-stamp
 
@@ -31,6 +32,7 @@
 	rm -f build-stamp configure-stamp
 	rm -rf $(PACKAGETMP)
 	-$(MAKE) distclean
+	dh_autoreconf_clean
 	dh_clean
 
 install: build
--- dancer-xml-0.8.2.1.orig/configure.ac
+++ dancer-xml-0.8.2.1/configure.ac
@@ -2,6 +2,7 @@
 m4_define(DXMLVERSION,0.8.2.1)
 AC_INIT(dancer-xml,DXMLVERSION)
 AM_INIT_AUTOMAKE(dancer-xml,DXMLVERSION)
+AM_INIT_AUTOMAKE([foreign])
 AM_CONFIG_HEADER(config.h)
 AM_MAINTAINER_MODE
 
--- dancer-xml-0.8.2.1.orig/patches/autoreconf.patch
+++ dancer-xml-0.8.2.1/patches/autoreconf.patch
@@ -0,0 +1,12 @@
+Index: dancer-xml-0.8.2.1/configure.ac
+===
+--- dancer-xml-0.8.2.1.orig/configure.ac
 dancer-xml-0.8.2.1/configure.ac
+@@ -2,6 +2,7 @@ dnl Process this file with autoconf to p
+ m4_define(DXMLVERSION,0.8.2.1)
+ AC_INIT(dancer-xml,DXMLVERSION)
+ AM_INIT_AUTOMAKE(dancer-xml,DXMLVERSION)
++AM_INIT_AUTOMAKE([foreign])
+ AM_CONFIG_HEADER(config.h)
+ AM_MAINTAINER_MODE
+ 
--- dancer-xml-0.8.2.1.orig/patches/series
+++ dancer-xml-0.8.2.1/patches/series
@@ -0,0 +1 @@
+autoreconf.patch

Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1

[Joe Stringer]

On 8 June 2016 at 16:40, Ben Pfaff  wrote:
> On Thu, Jun 09, 2016 at 01:23:12AM +0200, Thomas Goirand wrote:
>> Source: openvswitch
>> Version: 2.3.0+git20140819-4
>> Severity: normal
>>
>> Hi,
>>
>> OpenStack Neutron currently has:
>>
>> ovs>=2.5.0;python_version=='2.7' # Apache-2.0
>> ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0
>>
>> in its requirements.txt. Please package this at least to Debian Experimental,
>> so that I can package Neutron Newton Beta 1.
>
> I can package 2.5.x, though there are reports that there's one testsuite
> failure on big-endian architectures.
>
> OVS 2.6.0 doesn't exist yet, so it can't be packaged.  When Neutron asks
> for 2.6.0 what does it mean?

It would appear that someone has uploaded an OVS 2.5.90 development
version of the OVS python libraries to pypi as 2.6.0.dev1:
https://pypi.python.org/pypi/ovs/2.6.0.dev1

This probably has the latest python3 fixes that were applied since OVS
2.5, so is required if someone wants to run neutron under python3.

Russell, do you know much about this? I'd CC otherwiseguy, but I don't
know who that is off-hand.

Bug#826774: ITP: genwqe-user -- A hardware accelerated version of zLib using PCIe with FPGA

[Paul Wise]

n Thu, Jun 9, 2016 at 4:52 AM, Breno Leitao wrote:

>   Description : A hardware accelerated version of zLib using PCIe with 
> FPGA
...
> This package dependes on a specific PCIe3 FPGA Accelerator Adapter.

FPGA devices usually require proprietary software to be able to create
a bitstream for and upload to the device. Is that the case here?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#826381: [uscan] exits non-zero if already on newest upstream version

[James McCoy]

On Sun, Jun 05, 2016 at 08:39:27AM +0200, Daniel Baumann wrote:
> if a debian source package is already at the newest upstream version, uscan
> ends with exit code 1. Why? There's no error in that.

>From uscan(1):

  EXIT STATUS
 The exit status gives some indication of whether a newer
 version was found or not; one is advised to read the output to
 determine exactly what happened and whether there were any
 warnings to be noted.

 0   Either --help or --version was used, or for some watch file
 which was examined, a newer upstream version was located.

 1   No newer upstream versions were located for any of the
 watch files examined.

It's been like this for years.

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

Bug#826786: gcc-6-cross: No gcc plugin headers for cross compilers

[Fengguang Wu]

Source: gcc-6-cross
Severity: wishlist

Dear Maintainer,

Currently there are no gcc cross compiler packages that provide gcc
plugin headers, which will become necessary for cross building Linux
kernels:

[LKML] Introduce GCC plugin infrastructure
https://lwn.net/Articles/679073/

It's not a problem for native gcc thanks to the gcc-6-plugin-dev
package.

It'll help if cross versions of the gcc-6-plugin-dev package being
added, or adding gcc plugin headers to the cross gcc packages directly.

Thanks,
Fengguang
---

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

Kernel: Linux 4.2.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)

Bug#826785: forked-daapd: B-D libinotifytools0-dev is only available on Linux

[Andreas Beckmann]

Source: forked-daapd
Version: 24.1-1
Severity: important

Hi,

the recently added 

  Build-Depends: libinotifytools0-dev [kfreebsd-any]

seems to be missing a negation, since that package is available on Linux
only, so either [linux-any] or [!kfreebsd-any].

But since the configure script seems to require inotify, there is no
point in restricting the architecture at all. so let the non-linux
architectures go into BD-Uninstallable state instead of trying and
failing the build.


Andreas

Bug#826784: RM: forked-daapd [kfreebsd-amd64 kfreebsd-i386] -- RoQA; new version requires support for (linux-only) inotify

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

new build-dependency inotify is only available on linux-any.

Andreas

Bug#822494: Time to remove? Unusable since 2014.

[Ryan Kavanagh]

On Tue, Jun 07, 2016 at 07:27:07PM +0200, Petter Reinholdtsen wrote:
> [Eric Beuque]
> > For the database, all stream have to be cleaned from
> > http://database.freetuxtv.net/. I don't have enough time to do it
> > but i will try to do it.
> 
> I did not quite understand what you mean.  The streams seem to still
> be included in the freetuxtv database.

I've fixed a bunch of lintian warnings and other small things. Operating
on the assumption that the database of streams will be brought to
date/cleaned up, I'll upload the package after giving it a final look
over with fresh eyes tomorrow.

Best wishes,
Ryan

-- 
|_)|_/  Ryan Kavanagh   | Debian Developer
| \| \  https://ryanak.ca/  | GPG Key 4A11C97A


signature.asc
Description: PGP signature

Bug#821811: samba: badlock patch breaks trust relationship

[Vincent McIntyre]

I can confirm that after downgrading these packages

   samba samba-common samba-common-bin libwbclient0 
 smbclient samba-tools

to version 2:3.6.6-6+deb7u7 and then upgrading with

   apt-get -t santiago-wheezy install samba samba-common \
samba-common-bin libwbclient0 smbclient samba-tools

the system continued to work without issue; it remained joined to
the domain and users could connect as normal.

Note that this system was not running winbind, it was not installed.

Vince

Bug#826783: libapt-pkg5.0: aptitude aborts due to a fd leak

[Jiri Palecek]

Package: libapt-pkg5.0
Version: 1.2.12
Severity: normal

Dear Maintainer,

after trying to upgrade several packages from the KDE suite in aptitude, I got a
strange SIGABRT when trying to download them. Via gdb, I obtained
backtrace:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xab40 (LWP 8710)]
0xb773cdad in __kernel_vsyscall ()
(gdb) bt
#0  0xb773cdad in __kernel_vsyscall ()
#1  0xb6d5de26 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#2  0xb6d5f3f7 in __GI_abort () at abort.c:89
#3  0xb6d9b2a0 in __libc_message (do_abort=2, fmt=0xb6e90ff3 "*** %s ***: %s 
terminated\n") at ../sysdeps/posix/libc_fatal.c:175
#4  0xb6e2aeb7 in __GI___fortify_fail (msg=0xb6e90f8a "buffer overflow 
detected") at fortify_fail.c:31
#5  0xb6e290b8 in __GI___chk_fail () at chk_fail.c:28
#6  0xb6e2adda in __fdelt_chk (d=1083) at fdelt_chk.c:25
#7  0xb75eeafe in pkgAcquire::SetFds(int&, fd_set*, fd_set*) () from 
/usr/lib/i386-linux-gnu/libapt-pkg.so.5.0
#8  0xb75f418f in pkgAcquire::Run(int) () from 
/usr/lib/i386-linux-gnu/libapt-pkg.so.5.0
#9  0x8045f2a9 in download_manager::do_download (this=0x84f96cd4) at 
../../../../src/generic/apt/download_manager.cc:35
#10 0x8012b8db in download_thread::operator() (this=0x84ff0df8) at 
../../src/download_thread.cc:226
#11 0x801fee7f in 
cwidget::threads::noncopy_bootstrap::operator() 
(this=0xa318) at /usr/include/cwidget/generic/threads/threads.h:279
#12 0x801febfd in 
cwidget::threads::thread::bootstrap (p=0x84f771e0) at /usr/include/cwidget/generic/threads/threads.h:117
#13 0xb70cc2ce in start_thread (arg=0xab40) at pthread_create.c:334
#14 0xb6e1a23e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:122

After googling the __fdelt_chk function, it seems to check that the
passed fd is less than FD_SETSIZE and abort otherwise. Fair enough, 1083
seems pretty high.

Then I looked at the file descriptors that were open:

debian:/mnt/extras/src# lsof -p $(pidof aptitude)
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
  Output information may be incomplete.
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFFNODE NAME
aptitude 2856 root  cwdDIR8,628672 2113538 /home/jirka  


   
aptitude 2856 root  rtdDIR8,6 4096   2 /


   
aptitude 2856 root  txtREG8,6  6610336 1770506 /usr/bin/aptitude-curses 


   
aptitude 2856 root  memREG8,6   149869 4096209 
/usr/share/locale/cs/LC_MESSAGES/libc.mo


aptitude 2856 root  memREG8,6 31813113 2080784 
/var/cache/apt/pkgcache.bin 


aptitude 2856 root  memREG8,646736  230569 
/lib/i386-linux-gnu/libnss_files-2.22.so


aptitude 2856 root  memREG8,696128  230332 
/lib/i386-linux-gnu/libnsl-2.22.so  


aptitude 2856 root  memREG8,626992 4096400 
/usr/share/locale/cs/LC_MESSAGES/libapt-pkg5.0.mo   


aptitude 2856 root  memREG8,6   144168 4096084 
/usr/share/locale/cs/LC_MESSAGES/aptitude.mo


aptitude 2856 root  memREG8,6  2543120 1277970 
/usr/lib/locale/locale-archive  


aptitude 2856 root  memREG8,618092  231838 

Bug#797641: tshark: "tshark -r" output badly formatted

[Balint Reczey]

Control: tags -1 confirmed upstream
Control: forwarded -1 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12502
Control: severity -1 wishlist

Hi,

On Tue, 1 Sep 2015 09:12:02 +0200 "Ph. Marek"  wrote:
> Package: tshark
> Version: 1.12.7+g7fc8978-1
> Severity: normal
> 
> Running "tshark -r" on some pcap file gives badly formatted output; while some
> columns have a sane width, others are simply wrong.
> 
> Here's a shortened output:
> 
> |  8 66 03:14:31.106506   0.047926 192.168.72.206 -> 192.168.72.38
> |  9 85 03:14:34.624295   3.565715 192.168.72.38 -> 192.168.72.61
> | 10 95 03:14:34.626556   3.567976 192.168.72.61 -> 192.168.72.38
> | 11 66 03:14:34.626576   3.567996 192.168.72.38 -> 192.168.72.61
> 
> This would look good so far ... but as soon as the number of bytes in a packet
> isn't 2 digits long, or we get more than 999 packets, the output gets
> unreadable:
> 
> | 12 85 03:14:34.628704   3.570124 192.168.72.38 -> 192.168.72.61 
> | 18 4410 03:14:40.900369   9.841789 192.168.72.206 -> 192.168.72.38 
> |994 1514 03:14:42.639231  11.580651 192.168.72.206 -> 192.168.72.38 
> |995 78 03:14:42.639237  11.580657 192.168.72.38 -> 192.168.72.206 
> |996 1514 03:14:42.639240  11.580660 192.168.72.206 -> 192.168.72.38 
> |997 66 03:14:42.639247  11.580667 192.168.72.38 -> 192.168.72.206 
> |998 1514 03:14:42.639249  11.580669 192.168.72.206 -> 192.168.72.38 
> |999 1514 03:14:42.639252  11.580672 192.168.72.206 -> 192.168.72.38 
> |1000 2962 03:14:42.639255  11.580675 192.168.72.206 -> 192.168.72.38 
> |1001 78 03:14:42.639255  11.580675 192.168.72.38 -> 192.168.72.206 
> |1002 1514 03:14:42.639258  11.580678 192.168.72.206 -> 192.168.72.38 
> |1003 1514 03:14:42.639260  11.580680 192.168.72.206 -> 192.168.72.38 
> 
> IMO the packet numbers should be formatted as %5d, and the number of bytes %4d
> or %5d. The IP addresses might make sense to be given as %-15s; for IPv4 this
> would be the maximum length, and IPv6 addresses' lengths are too widely
> variable (and can get too long) to reserve all space.
> 
> I'm aware that I could pass my own format options as well; but the default
> output should already by useable. For comparision, here's "tcpdump -r":
> 
> |03:14:40.900965 IP 192.168.72.206.59036 > 192.168.72.38.7798: Flags [.],
> |03:14:40.900972 IP 192.168.72.38.7798 > 192.168.72.206.59036: Flags [.], 
> |03:14:40.900976 IP 192.168.72.206.59036 > 192.168.72.38.7798: Flags [.], 
> |03:14:40.900982 IP 192.168.72.38.7798 > 192.168.72.206.59036: Flags [.], 
> |03:14:40.901235 IP 192.168.72.206.59036 > 192.168.72.38.7798: Flags [.], 
> |03:14:40.901243 IP 192.168.72.38.7798 > 192.168.72.206.59036: Flags [.], 
> |03:14:40.901245 IP 192.168.72.206.59036 > 192.168.72.38.7798: Flags [.], 
> 
> (Yes, completely different output, yadda yadda yadda. That's why I want to use
> tshark and not tcpdump. But the output is much easier to navigate, as eg. the
> time is aligned.)

I'd like to add that during capturing the IP addresses are aligned to some 
extent but not perfectly:
$ tshark -i eth0
...
 31 17.719239387 17.0.2.9 -> 74.125.276.189 TLSv1.2 112  Application Data
 32 17.746877469 17.0.2.9 -> 74.125.276.189 TLSv1.2 338  Application Data
 33 17.762580156 74.125.276.189 -> 17.0.2.9 TCP 68  https → 41898 [ACK] ...
 34 17.790731320 74.125.276.189 -> 17.0.2.9 TCP 68  https → 41898 [ACK] ...
...

Cheers,
Balint

Bug#826782: systemd.automount fails to mount filesystem after unmount do to a timeout, then crashes

[Erik Haller]

Yes. I agree that #826782 is a duplicate of #826512.

This exactly fits: https://github.com/systemd/systemd/issues/3332

Please close.

On Wed, Jun 8, 2016 at 6:07 PM, Michael Biebl  wrote:

> Am 09.06.2016 um 02:51 schrieb Erik:
> > Package: systemd
> > Version: 230-2
> > Severity: important
> >
> > Performed a btrfs snapshot and upgraded. systemd upgraded from 229-6
> > to 230-2. systemd.automount no longer
> > remounts a path after the timeout. systemd crashes. Here is the journal
> > output:
>
> Looks like a duplicate of #826512
>
> Please checked the referenced upstream bug report there.
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

Bug#826782: systemd.automount fails to mount filesystem after unmount do to a timeout, then crashes

[Michael Biebl]

Am 09.06.2016 um 02:51 schrieb Erik:
> Package: systemd
> Version: 230-2
> Severity: important
> 
> Performed a btrfs snapshot and upgraded. systemd upgraded from 229-6
> to 230-2. systemd.automount no longer
> remounts a path after the timeout. systemd crashes. Here is the journal
> output:

Looks like a duplicate of #826512

Please checked the referenced upstream bug report there.


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



signature.asc
Description: OpenPGP digital signature

Bug#826755: [PATCH] Add Lua 5.3 support

[Jon Bernard]

* Asbjørn Sloth Tønnesen  wrote:
> Hi Jon,
> 
> On Wed, 8 Jun 2016 14:11:42 -0400, Jon Bernard  wrote:
> > Can you try building this?
> 
> Builds fine with dh-lua 23, based on the changelog I guess 21+ should do.
> http://metadata.ftp-master.debian.org/changelogs/main/d/dh-lua/dh-lua_23_changelog

Yeah, you're right.  Thanks for the patches, I've got a few packaging
cleanups to do and I'll get a new version up as soon as I can.

Cheers,

-- 
Jon

Bug#826737: Please package paramiko >= 2.0 in Experimental

[Jeremy T. Bouse]

I've looked at the paramiko.RSAKey code for 1.16, 1.17 and 2.0 ... Aside
from changing from python-crypto to python-cryptography I see no
evidence to support that the API is incompatible as they have same
exposed calls and parameters. Those functions simply use the different
library calls under the hood. Unless other packages are making calls to
internal functions they shouldn't be, which would be a bug in and of
itself, there shouldn't be any issues. The paramiko package will pull in
python-cryptography instead of python-crypto and there is no Conflicts
in place to hinder their package still maintaining python-crypto in
their dependencies.


On 6/8/2016 8:12 PM, Thomas Goirand wrote:
> On 06/08/2016 03:33 PM, Jeremy T. Bouse wrote:
>> Thank you for the report Thomas; however, if you'd taken a beat to check
>> or even contact the maintainer (ie- me) you would have found that this
>> is already being worked on... That said I'm not bothering with
>> experimental as it's a released version of Paramiko.
>>
>> https://github.com/jbouse-debian/paramiko/tree/upstream/2.0.0
> IMO, you should bother indeed, because the paramiko.RSAKey API is
> incompatible with what was in 1.x, so you should let other maintainers
> fix their packages, and give them enough time to do so (ie: transition).
>
> Cheers,
>
> Thomas Goirand (zigo)
>

Bug#826782: systemd.automount fails to mount filesystem after unmount do to a timeout, then crashes

[Erik]

Package: systemd
Version: 230-2
Severity: important

Performed a btrfs snapshot and upgraded. systemd upgraded from 229-6
to 230-2. systemd.automount no longer
remounts a path after the timeout. systemd crashes. Here is the journal
output:

Jun 08 17:29:51 incense systemd[1]: opt-erik-auto-p.automount: Got
automount request for /opt/erik/auto/p, triggered by 1724 (go)
Jun 08 17:29:51 incense systemd[1]: Mounting /opt/erik/auto/p...
Jun 08 17:29:52 incense systemd[1]: Mounted /opt/erik/auto/p.
Jun 08 17:30:16 incense systemd[1]: Unmounting /opt/erik/auto/p...
Jun 08 17:30:16 incense systemd[1]: Unmounted /opt/erik/auto/p.
Jun 08 17:32:55 incense ksu[3074]: 'ksu root' authenticated
e...@broadlux.com for erik on /dev/pts/1
Jun 08 17:32:55 incense ksu[3074]: Account root: authorization for
e...@broadlux.com for execution of /bin/bash successful
Jun 08 17:35:48 incense kernel: INFO: task go:2524 blocked for more than
120 seconds.
Jun 08 17:35:48 incense kernel:   Tainted: P   OE
4.5.0-2-686-pae #1
Jun 08 17:35:48 incense kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jun 08 17:35:48 incense kernel: go  D e44b2f40 0  2524
2421 0x0004
Jun 08 17:35:48 incense kernel:  e44b2f40 0086 efdcfe00 e44b2f40
c1561fa6 f77c6d00 f711c940 efdcfe00
Jun 08 17:35:48 incense kernel:  f77c6d00 f711c100 efdcfe00 e4722000
 7fff e4721c7c c156267d
Jun 08 17:35:48 incense kernel:  f69dd3d0 e4721ce0 c1565025 eaece540
e4721d10 f83eb778 eb7c3900 f83ee89a
Jun 08 17:35:48 incense kernel: Call Trace:
Jun 08 17:35:48 incense kernel:  [] ? __schedule+0x2b6/0x960
Jun 08 17:35:48 incense kernel:  [] ? schedule+0x2d/0x80
Jun 08 17:35:48 incense kernel:  [] ?
schedule_timeout+0x185/0x210
Jun 08 17:35:48 incense kernel:  [] ? autofs4_wait+0x438/0x840
[autofs4]
Jun 08 17:35:48 incense kernel:  [] ?
wait_for_completion+0xc2/0xf0
Jun 08 17:35:48 incense kernel:  [] ? wake_up_q+0x70/0x70
Jun 08 17:35:48 incense kernel:  [] ?
autofs4_expire_wait+0x73/0x140 [autofs4]
Jun 08 17:35:48 incense kernel:  [] ?
autofs4_d_manage+0x66/0x190 [autofs4]
Jun 08 17:35:48 incense kernel:  [] ?
lockref_put_or_lock+0x8/0x30
Jun 08 17:35:48 incense kernel:  [] ? dput+0xa5/0x210
Jun 08 17:35:48 incense kernel:  [] ?
autofs4_dir_unlink+0x130/0x130 [autofs4]
Jun 08 17:35:48 incense kernel:  [] ?
follow_managed+0x8d/0x2e0
Jun 08 17:35:48 incense kernel:  [] ?
autofs4_dir_unlink+0x130/0x130 [autofs4]
Jun 08 17:35:48 incense kernel:  [] ? lookup_fast+0x113/0x300
Jun 08 17:35:48 incense kernel:  [] ?
walk_component+0x3b/0x480
Jun 08 17:35:48 incense kernel:  [] ?
link_path_walk+0x141/0x490
Jun 08 17:35:48 incense kernel:  [] ?
trailing_symlink+0x1b8/0x220
Jun 08 17:35:48 incense kernel:  [] ?
generic_readlink+0x90/0x90
Jun 08 17:35:48 incense kernel:  [] ? path_lookupat+0x6e/0xe0
Jun 08 17:35:48 incense kernel:  [] ?
filename_lookup+0x97/0x190
Jun 08 17:35:48 incense kernel:  [] ?
lookup_one_len+0x120/0x120
Jun 08 17:35:48 incense kernel:  [] ? getname_flags+0x51/0x1a0
Jun 08 17:35:48 incense kernel:  [] ? vfs_fstatat+0x60/0xb0
Jun 08 17:35:48 incense kernel:  [] ? SyS_stat64+0x31/0x60
Jun 08 17:35:48 incense kernel:  [] ?
__do_page_fault+0x1a0/0x460
Jun 08 17:35:48 incense kernel:  [] ?
do_fast_syscall_32+0x8d/0x150
Jun 08 17:35:48 incense kernel:  [] ?
sysenter_past_esp+0x40/0x61


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.114
ii  libacl1 2.2.52-3
ii  libapparmor12.10-4
ii  libaudit1   1:2.5.2-1
ii  libblkid1   2.28-5
ii  libc6   2.22-9
ii  libcap2 1:2.25-1
ii  libcap2-bin 1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcc1 1:6.1.1-4
ii  libgcrypt20 1.7.0-2
ii  libgpg-error0   1.22-2
ii  libkmod222-1.1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.28-5
ii  libpam0g1.1.8-3.3
ii  libseccomp2 2.3.1-2
ii  libselinux1 2.5-3
ii  libsystemd0 230-2
ii  mount   2.28-5
ii  util-linux  2.28-5

Versions of packages systemd recommends:
ii  dbus1.10.8-1
ii  libpam-systemd  230-2

Versions of packages systemd suggests:
ii  systemd-container  230-2
pn  systemd-ui 

Versions of packages systemd is related to:
ii  udev  230-2

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/system.conf changed [not included]
/etc/systemd/timesyncd.conf changed [not included]

-- no debconf information

Bug#816764: zfsutils: Could be switched to use system libmd

[Guillem Jover]

Control: tags -1 patch

Hi!

On Sat, 2016-03-05 at 00:30:23 +0100, Guillem Jover wrote:
> Source: zfsutils
> Source-Version: 10.1~svn272500-1
> Severity: wishlist

> I noticed that this package contains an embedded version of libmd from
> FreeBSD. This package could be switched to use the now packaged libmd
> from the system.

I've implemented this now, but not build-tested it, just made sure the
patch applies. Attached.

Alos next time an upstream source is pulled the lib/libmd should
disappear from the source tarball, didn't consider it worth it to
remove that in a patch.

Thanks,
Guillem
Index: debian/control
===
--- debian/control	(revision 6065)
+++ debian/control	(working copy)
@@ -10,6 +10,7 @@
 Build-Depends: debhelper (>= 7.0.50~),
  freebsd-buildutils (>= 9.0-5~),
  libbsd-dev (>= 0.3.0),
+ libmd-dev,
  libc0.1-dev (>= 2.10),
  kfreebsd-kernel-headers (>= 10.1~4~),
  libgeom-dev,
Index: debian/patches/disable_libjail.diff
===
--- debian/patches/disable_libjail.diff	(revision 6065)
+++ debian/patches/disable_libjail.diff	(working copy)
@@ -1,7 +1,7 @@
 --- a/cddl/sbin/zfs/Makefile
 +++ b/cddl/sbin/zfs/Makefile
 @@ -1,5 +1,7 @@
- # $FreeBSD$
+ # $FreeBSD: releng/10.1/cddl/sbin/zfs/Makefile 248571 2013-03-21 08:38:03Z mm $
  
 +.include 
 +
Index: debian/patches/makefile.diff
===
--- debian/patches/makefile.diff	(revision 6065)
+++ debian/patches/makefile.diff	(working copy)
@@ -16,7 +16,7 @@
  DPADD=	${LIBMD} ${LIBPTHREAD} ${LIBUMEM} ${LIBUTIL} ${LIBM} ${LIBNVPAIR} \
  	${LIBAVL} ${LIBZFS_CORE}
 -LDADD=	-lmd -lpthread -lumem -lutil -lavl -lzfs_core
-+LDADD=	${.CURDIR}/../../../lib/libmd/libmd.a -lpthread -lumem -lzfs_core
++LDADD=	-lmd -lpthread -lumem -lzfs_core
 +
 +LDADD+= -lbsd -lm -luutil -lnvpair -lgeom
 +LDADD+= -L${.CURDIR}/../../../cddl/lib/libzfs_core
@@ -26,28 +26,18 @@
  
  SRCS=	deviceid.c \
  	fsshare.c \
-@@ -58,5 +64,6 @@
- CFLAGS+= -I${.CURDIR}/../../../cddl/contrib/opensolaris/lib/libuutil/common
- CFLAGS+= -I${.CURDIR}/../../../cddl/contrib/opensolaris/lib/libzfs/common
- CFLAGS+= -I${.CURDIR}/../../../cddl/contrib/opensolaris/lib/libzfs_core/common
-+CFLAGS+= -I${.CURDIR}/../../../lib/libmd
- 
- .include 
 --- a/cddl/lib/libzpool/Makefile
 +++ b/cddl/lib/libzpool/Makefile
-@@ -57,7 +57,14 @@
+@@ -57,7 +57,11 @@
  CFLAGS+=	-I${.CURDIR}/../../../lib/libthr/arch/${MACHINE_CPUARCH}/include
  
  DPADD=		${LIBMD} ${LIBPTHREAD} ${LIBZ}
 -LDADD=		-lmd -lpthread -lz -lumem -lnvpair -lavl
-+LDADD=		 -lpthread -lz -lumem -lnvpair -lavl-illumos -lbsd -lrt
++LDADD=		-lmd -lpthread -lz -lumem -lnvpair -lavl-illumos -lbsd -lrt
 +
 +LDADD+= -L${.CURDIR}/../../../cddl/lib/libumem
 +LDADD+= -L${.CURDIR}/../../../cddl/lib/libnvpair
 +LDADD+= -L${.CURDIR}/../../../cddl/lib/libavl
-+
-+CFLAGS+= -I${.CURDIR}/../../../lib/libmd
-+LDADD+= ${.CURDIR}/../../../lib/libmd/libmd.a
  
  # atomic.S doesn't like profiling.
  NO_PROFILE=
Index: debian/rules
===
--- debian/rules	(revision 6065)
+++ debian/rules	(working copy)
@@ -71,7 +71,6 @@
 		 cddl/contrib/opensolaris/cmd/stat/common/ \
 	 sys/cddl/compat/opensolaris \
 	 sys/cddl/contrib/opensolaris \
-		lib/libmd \
 	 cddl/lib/libavl \
 	 cddl/lib/libnvpair \
 	 cddl/lib/libuutil \
@@ -92,7 +91,7 @@
 
 build: build-arch build-indep
 
-build-arch: build-libmd build-libuutil build-libnvpair build-libzfs build-libumem build-libzpool build-zfsutils build-libavl
+build-arch: build-libuutil build-libnvpair build-libzfs build-libumem build-libzpool build-zfsutils build-libavl
 
 build-indep:
 # We have nothing to do by default.
@@ -115,7 +114,7 @@
 
 
 build-libzpool: build-libzpool-stamp
-build-libzpool-stamp: build-libavl build-libnvpair-stamp build-libumem build-libmd
+build-libzpool-stamp: build-libavl build-libnvpair-stamp build-libumem
 	$(PMAKE) -C $(CURDIR)/cddl/lib/libzpool
 	touch $@
 
@@ -134,11 +133,6 @@
 	$(PMAKE) -C $(CURDIR)/cddl/lib/libzfs_core
 	touch $@
 
-build-libmd: build-libmd-stamp
-build-libmd-stamp:
-	$(PMAKE) -C $(CURDIR)/lib/libmd
-	touch $@
-
 build-libavl: build-libavl-stamp
 build-libavl-stamp:
 	$(PMAKE) -C $(CURDIR)/cddl/lib/libavl
@@ -176,7 +170,6 @@
 	$(PMAKE) -C $(CURDIR)/cddl/usr.sbin/zdb clean
 	$(PMAKE) -C $(CURDIR)/cddl/usr.bin/ztest clean
 	$(PMAKE) -C $(CURDIR)/cddl/usr.bin/zinject clean
-	$(PMAKE) -C $(CURDIR)/lib/libmd clean
 
 	rm -f *stamp
 	dh_clean

Bug#811315: getdns: FTBFS[kfreebsd]: needs getentropy implementation

[Guillem Jover]

Control: forwarded -1 https://github.com/getdnsapi/getdns/pull/182

On Mon, 2016-01-18 at 13:59:00 +, Steven Chamberlain wrote:
> Guillem Jover wrote:
> > Steven Chamberlain wrote:
> > > getdns FTBFS on kfreebsd because it lacks a getentropy implementation
> > > for the FreeBSD kernel.  But there is one already in LibreSSL Portable
> > > we can use, and works fine here.
> > 
> > BTW, libbsd has also a getentropy(3) implementation (lifted too from
> > LibreSSL), which is currently not exposed but if people want to use it
> > I could make it public, instead of embedding this in all sorts of
> > places. The difference being that libbsd is already in Debian, while
> > LibreSSL is not.
> > 
> >   

> I think the only use case for getentropy is arc4random, so perhaps don't
> export getentropy(3), but lets try to standardise on one implementation
> of arc4random (in libbsd?) and try to get more people using that?
> 
> It would be nice to have the kernel-specific parts (getentropy) confined
> to libbsd, and that may become even more important if applications start
> sandboxing (e.g. can't read /dev/urandom any more, have to use sysctls).
> Or if getrandom(2) becomes standard, we'd only need to implement it in
> one place (as a supplement / eventual replacement to getentropy(3)).

Sure, I've now implemented this and sent a pull request to upstream,
plus the required packaging bits, attached here both for convenience.

Thanks,
Guillem
diff --git i/debian/control w/debian/control
index 8b27205..ffa1c40 100644
--- i/debian/control
+++ w/debian/control
@@ -8,6 +8,7 @@ Build-Depends: autotools-dev,
check,
debhelper (>= 9),
dh-autoreconf,
+   libbsd-dev,
libev-dev,
libevent-dev,
libexpat-dev,
From 1fb763761b90c3269d818a736a6c81469b89629d Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 9 Jun 2016 01:55:07 +0200
Subject: [PATCH] Use libbsd when available

Use the libbsd (https://libbsd.freedesktop.org/) overlay to transparently
use the bsd compatibility layer without needing any actual code changes.

Remove now unnecessary direct access to libbsd includes. And remove
checks for unused functions.
---
 configure.ac | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index a471327..0807f01 100644
--- a/configure.ac
+++ b/configure.ac
@@ -238,7 +238,7 @@ if grep VERSION_TEXT $ssldir/include/openssl/opensslv.h | grep "LibreSSL" >/dev/
 	AC_DEFINE([HAVE_LIBRESSL], [1], [Define if we have LibreSSL])
 	# libressl provides these compat functions, but they may also be
 	# declared by the OS in libc.  See if they have been declared.
-	AC_CHECK_DECLS([strlcpy,strlcat,arc4random,arc4random_uniform,reallocarray])
+	AC_CHECK_DECLS([strlcpy,arc4random,arc4random_uniform])
 else
 	AC_MSG_RESULT([no])
 fi
@@ -928,7 +928,7 @@ dnl - Start of "Things needed for gldns" section
 dnl -
 dnl ---
 
-AC_CHECK_HEADERS([stdarg.h stdint.h netinet/in.h arpa/inet.h netdb.h sys/socket.h time.h sys/time.h bsd/string.h sys/select.h],,, [AC_INCLUDES_DEFAULT])
+AC_CHECK_HEADERS([stdarg.h stdint.h netinet/in.h arpa/inet.h netdb.h sys/socket.h time.h sys/time.h sys/select.h],,, [AC_INCLUDES_DEFAULT])
 
 dnl Check the printf-format attribute (if any)
 dnl result in HAVE_ATTR_FORMAT.  
@@ -967,6 +967,14 @@ AC_MSG_RESULT($ac_cv_c_unused_attribute)
 if test $ac_cv_c_unused_attribute = yes; then
   AC_DEFINE(HAVE_ATTR_UNUSED, 1, [Whether the C compiler accepts the "unused" attribute])
 fi
+# Check for libbsd, so that the next function checks pick it as their
+# system implementation.
+PKG_CHECK_MODULES([LIBBSD],[libbsd-overlay],[
+LIBS="$LIBS $LIBBSD_LIBS"
+CFLAGS="$CFLAGS $LIBBSD_CFLAGS"
+],[
+AC_MSG_WARN([libbsd not found or usable; using embedded code instead])
+])
 AC_CHECK_DECLS([strlcpy,arc4random,arc4random_uniform])
 AC_REPLACE_FUNCS(inet_pton)
 AC_REPLACE_FUNCS(inet_ntop)
@@ -1050,10 +1058,6 @@ AH_BOTTOM([
 #include 
 #include 
 
-#ifdef HAVE_BSD_STRING_H
-#include 
-#endif
-
 /* the version of the windows API enabled */
 #ifndef WINVER
 #define WINVER 0x0600 // 0x0502
-- 
2.8.1

Bug#826685: glances-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc-base/glances-manual

[Daniel Echeverry]

tags 826685 + pending
thanks

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#787480: Ping?

[Michael Biebl]

Am 09.06.2016 um 01:56 schrieb Michael Biebl:
> Am 09.06.2016 um 01:44 schrieb Mario Lang:
>> It would be nice if we could get this bug fixed before the release.
>> Preferably by enabling iptable support in systemd.
> 
> I guess this would need someone asking the iptables maintainer to split
> out /lib/libip(4|6)tc.so into a separate library package, so we don't
> need to pull in all of iptables into every installed system (as
> mentioned before this increases the footprint by 4M).
> 
> Someone willing to ask the iptables maintainers if this would be feasible?

I've just checked out the iptables sources and apparently this is in the
works:
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-netfilter/pkg-netfilter.git;a=commitdiff;h=001e02b30dbe8fc2dba820abae4f710de2114133

Hasn't been uploaded yet, though.

The maintainer has decided to move the libraries back to /usr/lib.
This means our current check in debian/rules which tests if binaries
have been linked against libs from /usr will fail.

We could either ask the iptables maintainer to keep the libs in /lib or
exclude systemd-networkd from the check in debian/rules.

At some point, shuffling the libraries around becomes a nuisance. Maybe
we should only do that for /lib/systemd/systemd and eventually
/lib/systemd/systemd-udevd.

Thoughts?

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#826781: jigdo-file: Use bigger filesPerFetch, or at least allow to configure it

[Samuel Thibault]

Package: jigdo-file
Version: 0.7.3-3+b2
Severity: normal

Hello,

My ISP has a Debian mirror, and thus over my fiber Internet connexion I
have 100Mbps access to it.

However, jigdo is not really benefitting from it, because it does not
pipeline file downloading enough: filesPerFetch is only 10 by default,
and since most files are not that big, the TCP connexion does not have
enough to download to reach a big download rate.

For instance, downloading the netinst image takes about one minute to
download with the default parameter. Raising the filesPerFetch parameter
by hand in /usr/bin/jigdo-lite to 100 reduces the download time to about
35s. Raising it further does not improve the time. Even just raising to
30 reduces to a bit less than 40s. Perhaps the default value should be
increased too?  It'll still be useful to be able to tune it.

Samuel

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

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

Versions of packages jigdo-file depends on:
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.22-9
ii  libdb5.35.3.28-11
ii  libgcc1 1:6.1.1-4
ii  libstdc++6  6.1.1-4
ii  wget1.17.1-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

jigdo-file recommends no packages.

jigdo-file suggests no packages.

-- no debconf information

-- 
Samuel
>   dvips -o $@ $< 
Faut faire gffe de pas te couper avec ton truc, t'as mis des ciseaux ($<)
partout :))
-+- Dom in Guide du linuxien pervers - "J'aime pas les Makefile !" -+-

Bug#826737: Please package paramiko >= 2.0 in Experimental

[Thomas Goirand]

On 06/08/2016 03:33 PM, Jeremy T. Bouse wrote:
> Thank you for the report Thomas; however, if you'd taken a beat to check
> or even contact the maintainer (ie- me) you would have found that this
> is already being worked on... That said I'm not bothering with
> experimental as it's a released version of Paramiko.
> 
> https://github.com/jbouse-debian/paramiko/tree/upstream/2.0.0

IMO, you should bother indeed, because the paramiko.RSAKey API is
incompatible with what was in 1.x, so you should let other maintainers
fix their packages, and give them enough time to do so (ie: transition).

Cheers,

Thomas Goirand (zigo)

Bug#790492: zbar-tools: zbarimg segfault on bad URL

[Kyanos]

On 06/08/2016 05:04 PM, Kyanos wrote:
> I believe this bug should be reassigned to MagickWand
> (libmagickwand-6.q16-2).

Actually, it should probably be MagickCore (libmagickcore-6.q16-2) based
on the backtrace.

Bug#790492: zbar-tools: zbarimg segfault on bad URL

[Kyanos]

Package: zbar-tools
Version: 0.10+doc-10+b1
Followup-For: Bug #790492

The backtrace from GDB suggests that this is a bug in ImageMagick. Using
the "convert" command from ImageMagick gives the same result.


$ convert http://test.test/ out.png
error : No such file or directory
error : Unknown IO error
error : Unknown IO error
error : Unknown IO error
[...]
error : Unknown IO error
Segmentation fault


What's interesting is that it only fails on such URLs when there is no
file extension. Adding a file extension (even an invalid one!) gives:

$ zbarimg http://test.test/image.png
error : No such file or directory
ERROR: no data returned `http://test.test/image.png' @
error/url.c/ReadURLImage/263

$ zbarimg http://test.test/image.
error : No such file or directory
ERROR: no data returned `http://test.test/image.' @
error/url.c/ReadURLImage/263

$ convert http://test.test/image.png image.jpg
error : No such file or directory
convert: improper image header `/tmp/magick-10658RpyovmhF6oer' @
error/png.c/ReadPNGImage/3930.
convert: no data returned `http://test.test/image.png' @
error/url.c/ReadURLImage/263.
convert: no images defined `image.jpg' @
error/convert.c/ConvertImageCommand/3210.

$ convert http://test.test/image. image.jpg
error : No such file or directory
convert: no decode delegate for this image format `' @
error/constitute.c/ReadImage/501.
convert: no data returned `http://test.test/image.' @
error/url.c/ReadURLImage/263.
convert: no images defined `image.jpg' @
error/convert.c/ConvertImageCommand/3210.


I believe this bug should be reassigned to MagickWand
(libmagickwand-6.q16-2).

Kyanos

P.S. Information from Reportbug is provided in case it is useful.

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

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

Versions of packages zbar-tools depends on:
ii  libc6  2.22-9
ii  libgomp1   6.1.1-4
ii  libjpeg62-turbo1:1.4.2-2
ii  libmagickcore-6.q16-2  8:6.8.9.9-7.1
ii  libmagickwand-6.q16-2  8:6.8.9.9-7.1
ii  libv4l-0   1.10.0-2
ii  libzbar0   0.10+doc-10+b1

zbar-tools recommends no packages.

zbar-tools suggests no packages.

-- no debconf information

Bug#787480: Ping?

[Michael Biebl]

Am 09.06.2016 um 01:44 schrieb Mario Lang:
> It would be nice if we could get this bug fixed before the release.
> Preferably by enabling iptable support in systemd.

I guess this would need someone asking the iptables maintainer to split
out /lib/libip(4|6)tc.so into a separate library package, so we don't
need to pull in all of iptables into every installed system (as
mentioned before this increases the footprint by 4M).

Someone willing to ask the iptables maintainers if this would be feasible?

Michael



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



signature.asc
Description: OpenPGP digital signature

Bug#787480: Ping?

[Mario Lang]

Hi.

I just discovered IPMasquerade= in systemd.network(5) which is exactly
what I need to set up a Bluetooth PAN Access Point.  The config
*would* be straight forward via systemd-networkd (bt-pan related setup
not included):

/etc/systemd/network/pan.netdev:
[NetDev]
Name=pan
Kind=bridge
ForwardDelaySec=0

/etc/systemd/network/pan.network:
[Match]
Name=pan

[Network]
Address=10.2.1.1/24
DHCPServer=yes
IPMasquerade=yes


However, during testing I realized that while IPMasquerade= is
documented in systemd.network(5), it is a noop on Debian.

It would be nice if we could get this bug fixed before the release.
Preferably by enabling iptable support in systemd.

If this is not possible (which would be quite sad, given how convenient
this feature actually is), I suggest we at least remove IPMasquerade=
From the manpage (or augment it with a note that this feature is not
available) to avoid confusing users (like me).

-- 
CYa,
  ⡍⠁⠗⠊⠕


signature.asc
Description: PGP signature

Bug#826780: Please package OVS >= 2.6.0.dev1

[Ben Pfaff]

On Thu, Jun 09, 2016 at 01:23:12AM +0200, Thomas Goirand wrote:
> Source: openvswitch
> Version: 2.3.0+git20140819-4
> Severity: normal
> 
> Hi,
> 
> OpenStack Neutron currently has:
> 
> ovs>=2.5.0;python_version=='2.7' # Apache-2.0
> ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0
> 
> in its requirements.txt. Please package this at least to Debian Experimental,
> so that I can package Neutron Newton Beta 1.

I can package 2.5.x, though there are reports that there's one testsuite
failure on big-endian architectures.

OVS 2.6.0 doesn't exist yet, so it can't be packaged.  When Neutron asks
for 2.6.0 what does it mean?

Bug#826737: Pull request available

[Jeremy T Bouse]

If you has contacted me you would have found I had the work pretty much done 9 
hours before your first commit in your Alioth repository and I was just 
finishing my testing which had to wait until I got done with my work day for my 
job that pays the bills.

Sent from my Verizon Wireless 4G LTE DROID
On Jun 8, 2016 6:43 PM, Thomas Goirand  wrote:
>
> On 06/08/2016 08:11 PM, Jeremy T. Bouse wrote: 
> > Yes I already got the dependency switch from python-crypto to 
> > python-cryptography addressed as well... Will you let the package 
> > maintainer do his job and you take care of your own? Thank you. 
>
> Great, thanks! 
>
> FYI, I had to do the work as I couldn't wait anyway, so that I could 
> progress in the packaging of the rest of OpenStack (using non-official 
> repository), so I just though I could share... 
>
> Cheers, 
>
> Thomas Goirand (zigo) 
>

Bug#826780: Please package OVS >= 2.6.0.dev1

[Thomas Goirand]

Source: openvswitch
Version: 2.3.0+git20140819-4
Severity: normal

Hi,

OpenStack Neutron currently has:

ovs>=2.5.0;python_version=='2.7' # Apache-2.0
ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0

in its requirements.txt. Please package this at least to Debian Experimental,
so that I can package Neutron Newton Beta 1.

Cheers,

Thomas Goirand (zigo)

Bug#826764: Co-maintaining cgit

[Peter Colberg]

On Thu, Jun 09, 2016 at 12:29:02AM +0200, Alexander Wirt wrote:
> I really prefer the pkg- prefix, since this is not about cgit (as source),
> but about debian packaging. That matches the layout on my disk where I have
> upstream checkouts beside of packaging checkouts.

Ok, that’s a perfect reason to have the -pkg prefix.

Peter


signature.asc
Description: PGP signature

Bug#826737: Pull request available

[Thomas Goirand]

On 06/08/2016 08:11 PM, Jeremy T. Bouse wrote:
> Yes I already got the dependency switch from python-crypto to
> python-cryptography addressed as well... Will you let the package
> maintainer do his job and you take care of your own? Thank you.

Great, thanks!

FYI, I had to do the work as I couldn't wait anyway, so that I could
progress in the packaging of the rest of OpenStack (using non-official
repository), so I just though I could share...

Cheers,

Thomas Goirand (zigo)

Bug#826723: surf: download file pdfmyurl.com

[Reiner Herrmann]

Hi Fulano,

On Wed, Jun 08, 2016 at 09:20:35PM +1000, Fulano Diego Perez wrote:
> can you ?
> 
> i cant find it if it does - not in runtime DIR..

thanks for the report.
It looks like it downloads index.php instead of the offered PDF
to its working directory.
I need to investigate a bit more why it does this.

Regards,
  Reiner


signature.asc
Description: Digital signature

Bug#826661: RFS: groonga/6.0.4-1

[Gianfranco Costamagna]

control: owner -1 !

control: tags -1 moreinfo

Hi


>I am looking for a sponsor for my package "groonga"



Hi, I did a debdiff between them, and I see some changes that might be ABI 
breaking the library:

-GRN_API grn_rc grn_timeval_now(grn_ctx *ctx, grn_timeval *tv);
-GRN_API grn_rc grn_timeval2str(grn_ctx *ctx, grn_timeval *tv, char *buf, 
size_t buf_size);
-struct tm *grn_timeval2tm(grn_ctx *ctx, grn_timeval *tv, struct tm *tm_buffer);
-grn_rc grn_str2timeval(const char *str, uint32_t str_len, grn_timeval *tv);


removing symbols might be an ABI break

also adding a field to a struct
+  grn_bool is_dirty;

(not always)

as well as adding them in the middle of a struct
-  uint32_t reserved[1003];
+  uint32_t n_dirty_opens;
+  uint32_t reserved[1002];
grn_pat_delinfo delinfos[GRN_PAT_NDELINFOS];
grn_id garbages[GRN_PAT_MAX_KEY_SIZE + 1];


also, before sponsoring please consider adding something to copyrights for the 
next upload.

e.g.

+ Copyright (C) 2016 Kouhei Sutou 

(this isn't a blocker because license is fine)

so, please answer wrt ABI/API breakage.

(there seem to be only one reverse dependency

groonga-normalizer-mysql)

Gianfranco

Bug#826764: Co-maintaining cgit

[Alexander Wirt]

On Wed, 08 Jun 2016, Peter Colberg wrote:

> On Wed, Jun 08, 2016 at 11:28:32PM +0200, Alexander Wirt wrote:
> > I added pkg-cgit-devel and pkg-cgit-commits
> 
> Thanks, I subscribed to pkg-cgit-devel.
> 
> Would you mind if we rename the repository from pkg-cgit/pkg-cgit.git
> to pkg-cgit/cgit.git matching the source package name?
I really prefer the pkg- prefix, since this is not about cgit (as source),
but about debian packaging. That matches the layout on my disk where I have
upstream checkouts beside of packaging checkouts. 

Alex


signature.asc
Description: PGP signature

Bug#826764: Co-maintaining cgit

[Peter Colberg]

On Wed, Jun 08, 2016 at 11:28:32PM +0200, Alexander Wirt wrote:
> I added pkg-cgit-devel and pkg-cgit-commits

Thanks, I subscribed to pkg-cgit-devel.

Would you mind if we rename the repository from pkg-cgit/pkg-cgit.git
to pkg-cgit/cgit.git matching the source package name?

Peter


signature.asc
Description: PGP signature

Bug#826779: linux-base: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: linux-base
Version: 4.3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for linux-base's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

linux-base_4.3_pt.po.gz
Description: application/gzip

Bug#825109: FTBFS: mv: cannot stat './config.guess': No such file or directory

[Debian/GNU]

Control: reassign -1 cdbs
thanks

This is really a regression in CDBS.

mgfsar
IOhannes



signature.asc
Description: OpenPGP digital signature

Bug#825370: unicap: FTBFS: mv: cannot stat './config.guess': No such file or directory

[IOhannes m zmoelnig]

Package: src:unicap
Followup-For: Bug #825370
Control: reassign -1 cdbs

This is really a regression in CDBS.

-- 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=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#826778: O: ora2pg -- Oracle to PostgreSQL database schema converter

[Julián Moreno Patiño]

Package: wnpp
Severity: normal

I intend to orphan the ora2pg package, I am not managing
Oracle Databases at the moment, so I can't give it some love.

Maintaining a package requires time and skills.
Please only adopt this package if you will have
enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

King regards,

-- 
Julián Moreno Patiño
Debian Developer
 .''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `'  http://debian.org/
  `-   GPG Fingerprint:
C2C8 904E 314C D8FA 041D 9B00 D5FD FC15 6168 BF60
Registered GNU Linux User ID 488513


signature.asc
Description: PGP signature

Bug#826764: Co-maintaining cgit

[Alexander Wirt]

On Wed, 08 Jun 2016, Peter Colberg wrote:

> On Wed, Jun 08, 2016 at 10:29:18PM +0200, Alexander Wirt wrote:
> > Here we are: https://alioth.debian.org/scm/?group_id=101009
> > 
> > I already pushed the existing repo to the new git repo.
> > Please request to get added to the project and I will add you. 
> 
> Done. Could you add a mailing list pkg-cgit?
I added pkg-cgit-devel and pkg-cgit-commits

Alex



signature.asc
Description: PGP signature

Bug#826777: flashplugin-nonfree: latest security release missing from hash

[Marc J. Driftmeyer]

Package: flashplugin-nonfree
Version: 1:3.6.1+b1
Severity: normal

Dear Maintainer,

Fix the service to get .626 to avoid all the annoying Flash Plugin errors 
across all web site.

Sincerely,

Marc J. Driftmeyer

-- Package-specific info:
Debian version: stretch/sid
Architecture: amd64
Package version: 1:3.6.1+b1
Adobe Flash Player version: LNX 11,2,202,616
MD5 checksums:
160a01dd00527304e5291e65eb0c65e2  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
18271ef4389464f5236e415a8f140872  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz
cb4968ab3f52b73a05590ecd87a83bd5  
/usr/lib/flashplugin-nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
  link best version is /usr/lib/flashplugin-nonfree/libflashplayer.so
  link currently points to 
/usr/lib/flashplugin-nonfree/libflashplayer.so
  link flash-mozilla.so is /usr/lib/mozilla/plugins/flash-mozilla.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
lrwxrwxrwx 1 root root 34 Aug 17  2015 
/usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to 
/etc/alternatives/flash-mozilla.so

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

Kernel: Linux 4.5.0-2-amd64 (SMP w/8 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 flashplugin-nonfree depends on:
ii  binutils   2.26-10
ii  ca-certificates20160104
ii  debconf [debconf-2.0]  1.5.59
ii  gnupg  2.1.12-1
ii  libatk1.0-02.20.0-1
ii  libcairo2  1.14.6-1+b1
ii  libcurl3-gnutls7.47.0-1
ii  libfontconfig1 2.11.0-6.4
ii  libfreetype6   2.6.3-3+b1
ii  libgcc11:6.1.1-5
ii  libglib2.0-0   2.48.1-1
ii  libgtk2.0-02.24.30-2
ii  libnspr4   2:4.12-2
ii  libnss32:3.23-2
ii  libpango1.0-0  1.40.1-1
ii  libstdc++6 6.1.1-5
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.5-1
ii  wget   1.17.1-2

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
ii  fonts-dejavu   2.35-1
pn  hal
pn  iceweasel  
ii  konqueror-nsplugins4:16.04.1-1
ii  ttf-mscorefonts-installer  3.6
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#826713: The keys in the keyrings don't fall under any copyright.

[Daniel Kahn Gillmor]

On Wed 2016-06-08 04:57:21 -0400, Mathieu Malaterre wrote:
> Package: debian-keyring
> Version: 2016.04.22
>
> Currently the package copyright file states:
>
> [...]
> The keys in the keyrings don't fall under any copyright.
> [...]
>
> this is inaccurate as key(s) can have JPEG copyright strings attached.

fwiw, the copyrights in the JPEGs are often embedded color profiles.
The fact that the color profiles are copyrighted doesn't mean they are
not DFSG-free, though; it just means we need to figure out what the
licenses are for those copyrights.

have you scanned other JPEGs in the debian archive for these embedded
profiles?  if those color profiles are actually not considered
DFSG-free, this may turn out to be a larger project than expected.

fwiw, i suppose one could argue that the images in the user attributes
(the attached keys) themselves (regardless of embedded color profile)
are under some form of copyright protection that could make them not
dfsg-free unless they have an appropriately-stated license.

See for example:

   https://commons.wikimedia.org/wiki/Commons:Exif#ExifTool_how-to

This seems a bit silly, but hey, copyright law might actually turn out
to be silly sometimes.

I see a few possible options:

 0) stop distributing User Attributes in debian-keyring entirely (this
would avoid dealing with any questions about embedded color profiles
or jpeg copyright)

 1) stop distributing User Attributes with embedded copyrighted color
profiles that are not explicitly licensed with a DFSG-free license.

 2) stop distributing User Attributes that contain JPEGs that do not
have a DFSG-friendly Copyright tag.  (licensing ≠ copyright, so
putting licensing information in a Copyright tag is also silly; but
it's no sillier than putting licensing information in a file named
debian/copyright… oh well)


(0) is certainly the easiest approach for the maintainers of
debian-keyring.

   --dkg

Bug#826764: Co-maintaining cgit

[Peter Colberg]

On Wed, Jun 08, 2016 at 10:29:18PM +0200, Alexander Wirt wrote:
> Here we are: https://alioth.debian.org/scm/?group_id=101009
> 
> I already pushed the existing repo to the new git repo.
> Please request to get added to the project and I will add you. 

Done. Could you add a mailing list pkg-cgit?

Peter


signature.asc
Description: PGP signature

Bug#821946: systemd: Something (systemd?) keeps changing my /etc/vconsole.conf away from Dvorak

[Ævar Arnfjörð Bjarmason]

On Mon, Jun 6, 2016 at 3:22 PM, Michael Biebl  wrote:
> Control: tags -1 moreinfo unreproducible
>
> On Wed, 20 Apr 2016 19:04:01 +0200
> =?utf-8?b?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?=  wrote:
>> Package: systemd
>> Version: 215-17+deb8u4
>> Severity: important
>>
>> [I filed this before, but I saw I set my E-Mail to avar@localhost, so
>>  it was probably auto-rejected, can't find it in the BTS]
>>
>> I'm not even sure if this is a systemd bug, especially given
>> #803970. If you know about something that automatically edits
>> /etc/vconsole.conf that isn't systemd please forward this report to
>> that package.
>
> Can you pinpoint the change of /etc/vconsole.conf to a specific action
> you do?

I *think* in the past it was related to upgrading some packages, but I
could never figure out what package exactly.

I was hoping to file a bug and someone who could grep the install
scripts could check for vconsole.conf and say whether it was systemd
or not

I filed it with systemd since it owns localectl, which is as close as I got.

For what it's worth I've recentlry done apt upgrades where the
keyboard is reset to QWERTY but the vconsole.conf is *not* changed,
instead I need to run "dpkg-reconfigure keyboard-configuration" again
and re-select the exact same options I have selected already, and
somehow the kernel then gets the hint that I want the Dvorak layout.

So probably in the absence of other evidence this bug should be
reassigned to the keyboard-configuration package.

Bug#824650: ostree: consider separating all boot integration into ostree-boot

[Simon McVittie]

Control: retitle 824650 ostree: reinstate boot integration as new ostree-boot 
package

On Wed, 18 May 2016 at 13:21:53 +0100, Simon McVittie wrote:
> Developers from Endless have suggested packaging the bootloader,
> initramfs and systemd integration into an ostree-boot package, so that
> the core parts of ostree (as used in xdg-app/flatpak and when committing
> OSTree-deployed OS images) can be installed without the boot parts
> on development/deployment systems that will never actually boot using
> OSTree. This seems like a sensible plan.

I have now removed the bootloader, initramfs and systemd integration,
leaving only the command-line tool, library and tests.

This is enough to compose OSTree filesystem trees, either whole-OS or
for Flatpak. However, some of the code that needs to go into an OSTree
filesystem tree to make it bootable is now missing. This is because I
was unable to work out how to get a bootable system using that
integration stuff, so I can't test or support it.

When someone (perhaps from Endless?) documents how we can test the OS
integration layer (#824649), we can easily bring it back:

* stop deleting the relevant files in debian/rules
* move the ostree-boot stanza from debian/ostree-boot.control
  back into to debian/control
* apply any fixes that might be needed to make it work in practice

Because it will need to go through the NEW queue, this should probably
be done via experimental.

S

Bug#826776: libgl2ps1 has wrong Breaks/Replaces against libgl2ps0

[Steve Langasek]

Package: libgl2ps1
Version: 1.3.9-1
Severity: important

With the latest gl2ps package being synced to Ubuntu, I've noticed that the
libgl2ps1 package has a Breaks/Replaces against libgl2ps0 (<< 1.3.9-1~exp1). 
These package relationships are unnecessary, as the two packages contain no
overlapping files.  Furthermore, package relationships of this type make
partial upgrades more difficult, which both unnecessarily complicates
calculation of upgrade paths between releases, and inconveniences users with
locally-installed software that uses the soname from the old stable release.

As far as I can see, the only version of libgl2ps0 that was ever in the
archive that had a conflicting filepath was version 1.3.8-2 (bug #824882). 
A Breaks/Replaces against this exact version would address any upgrade
problems there, without impacting users of stable releases.

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


signature.asc
Description: PGP signature

Bug#825694: System doesn't hibernate when no battery is installed

[Santiago Garcia Mantinan]

Hi!

> Right.  Can you run the commands
> 'bash -x /usr/share/battery-stats/collect-csv' and

bash -x /usr/share/battery-stats/collect-csv
+ logfile=/var/log/battery-stats.csv
+ files='manufacturer model_name technology serial_number 
status cycle_count energy_now energy_full energy_full_design
 charge_now charge_full charge_full_design '
++ getopt --name collect-csv --options o: --longoptions output: --
+ TEMP=' --'
+ eval set -- ' --'
++ set -- --
+ true
+ case "$1" in
+ break
+ '[' '!' -e /var/log/battery-stats.csv ']'
+ cd /sys/class/power_supply
++ find -L . -maxdepth 1 -name 'BAT*' -type d

> 'sh -x /usr/sbin/battery-stats-collector -1' as root when there is no

sh -x /usr/sbin/battery-stats-collector -1
+ set -e
++ basename /usr/sbin/battery-stats-collector
+ PROGRAM_NAME=battery-stats-collector
+ logfile=/var/log/battery-stats
+ sample_interval_secs=600
+ syslog=false
++ getopt -n battery-stats-collector --options o:i:V1hsF:Ib: --longoptions 
output:,interval:,version,once,help,syslog,flush:,ignore-missing-battery,battery-num:
 -- -1
+ TEMP=' -1 --'
+ eval set -- ' -1 --'
++ set -- -1 --
+ true
+ case "$1" in
+ sample_interval_secs=0
+ shift
+ continue
+ true
+ case "$1" in
+ break
+ true
+ '[' /var/log/battery-stats ']'
+ get_logline
++ date +%s
+ secstamp=1465419530
++ date '+%Y/%m/%d %H:%M:%S'
+ stamp='2016/06/08 22:58:50'
+ '[' -f /sys/class/power_supply/AC/online ']'
+ '[' -f /sys/class/power_supply/ACAD/online ']'
+ echo 'No power supply found'
+ '[' 1 = '' ']'
+ state=1
+ now=energy_now
+ full=energy_full
+ for f in '/sys/class/power_supply/BAT*'
+ '[' '!' -e '/sys/class/power_supply/BAT*/energy_now' ']'
+ now=charge_now
+ '[' '!' -e '/sys/class/power_supply/BAT*/energy_full' ']'
+ full=charge_full
++ cat '/sys/class/power_supply/BAT*/charge_now'
cat: '/sys/class/power_supply/BAT*/charge_now': Non hai tal ficheiro ou 
directorio
+ energy_now=


> battery, and send me the output?  It would be useful to know exactly how
> it fail for you.

There you have, do you need any other info?

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#769080: new Evince without title

[Jason Crain]

On Tue, Jun 07, 2016 at 11:08:29AM +0200, Harald Dunkel wrote:
> On 06/07/16 10:53, Harald Dunkel wrote:
> > Which .fvwm2rc did you use?
> > 
> PPS: Would you mind to try
> 
>   /usr/share/doc/fvwm/examples/system.fvwm2rc.gz

Using that .fvwm2rc evince acts weird.  It has a window border, so it
doesn't look like your screenshots, but it's not resizable.  Looks like
evince doesn't do well with fvwm2's MWMDecor option.

Bug#796689: pidentd nmu uploaded to delayed/5

[Andreas Henriksson]

Hello!

The attached diff was just uploaded as an NMU to delayed/5
given the lack of response on this bug report.

HTH

Regards,
Andreas Henriksson
diff -Nru pidentd-3.0.19.ds1/debian/changelog pidentd-3.0.19.ds1/debian/changelog
--- pidentd-3.0.19.ds1/debian/changelog	2011-12-08 03:03:44.0 +0100
+++ pidentd-3.0.19.ds1/debian/changelog	2016-06-08 22:51:36.0 +0200
@@ -1,3 +1,19 @@
+pidentd (3.0.19.ds1-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/pidentd.tmpfile and debian/pidentd.links (Closes: #796689)
+- create runtimedirectory using tmpfiles.d instead of via init-script.
+  * Source LSB init-functions in pidentd init script
+- this allows systemd LSB hook to redirect direct init script
+  invocations to use systemctl instead. Caught by lintian.
+  * Drop explicit bzip2 compression in debian/rules and use default
+- these days default (xz for source format > 1.0) is better
+  and this avoids lintian error about bzip2 being deprecated.
+  * Include dpkg buildflags.mk to export hardening flags
+- fixes missing hardening options in built binaries as caught by lintian.
+
+ -- Andreas Henriksson   Wed, 08 Jun 2016 22:39:15 +0200
+
 pidentd (3.0.19.ds1-7) unstable; urgency=low
 
   * Fix update-rc.d error
diff -Nru pidentd-3.0.19.ds1/debian/pidentd.init pidentd-3.0.19.ds1/debian/pidentd.init
--- pidentd-3.0.19.ds1/debian/pidentd.init	2011-12-02 23:05:10.0 +0100
+++ pidentd-3.0.19.ds1/debian/pidentd.init	2016-06-08 22:42:57.0 +0200
@@ -11,6 +11,8 @@
 
 [ -x /usr/sbin/identd ] || exit 0
 
+. /lib/lsb/init-functions
+
 case "$1" in
 	start|restart|reload|force-reload)
 		mkdir -p /var/run/identd
diff -Nru pidentd-3.0.19.ds1/debian/pidentd.links pidentd-3.0.19.ds1/debian/pidentd.links
--- pidentd-3.0.19.ds1/debian/pidentd.links	1970-01-01 01:00:00.0 +0100
+++ pidentd-3.0.19.ds1/debian/pidentd.links	2016-06-08 22:39:12.0 +0200
@@ -0,0 +1 @@
+/dev/null /lib/systemd/system/pidentd.service
diff -Nru pidentd-3.0.19.ds1/debian/pidentd.tmpfile pidentd-3.0.19.ds1/debian/pidentd.tmpfile
--- pidentd-3.0.19.ds1/debian/pidentd.tmpfile	1970-01-01 01:00:00.0 +0100
+++ pidentd-3.0.19.ds1/debian/pidentd.tmpfile	2016-06-08 22:39:12.0 +0200
@@ -0,0 +1 @@
+d /var/run/identd 0755 identd nogroup - -
diff -Nru pidentd-3.0.19.ds1/debian/rules pidentd-3.0.19.ds1/debian/rules
--- pidentd-3.0.19.ds1/debian/rules	2011-12-08 03:01:29.0 +0100
+++ pidentd-3.0.19.ds1/debian/rules	2016-06-08 22:50:52.0 +0200
@@ -10,6 +10,10 @@
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
 
+# export hardening flags
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+
 package := pidentd
 
 configure: configure-stamp
@@ -103,7 +107,7 @@
 	dh_shlibdeps
 	dh_gencontrol
 	dh_md5sums
-	dh_builddeb -- -Zbzip2 -z9
+	dh_builddeb
 
 # Build architecture-independent files here.
 binary-indep: install

Bug#826775: RFP: texttop -- A fully interactive X Linux desktop rendered in TTY and streamable over SSH

[Luciano Bello]

Package: wnpp
Severity: wishlist

* Package name : texttop
Version : 0.0
Upstream Author : Thomas Buckley-Houston 
* URL : https://github.com/tombh/texttop
* License : GPLv3
Description :
  Texttop is simply a way to have the power of a remote server running a 
desktop, but interfaced through the simplicity of a terminal and very low 
bandwidth.
  It uses MoSH to further reduce the bandwidth and stability requirements of 
the connection. Mosh offers features like automatic reconnection of dropped 
connections and diff-only screen updates. Also, other than SSH or MoSH, 
Texttop doesn't require a client like VNC. But of course another big reason 
for Texttop is that it's just very cool geekery.

Bug#745615: dcraw maintenance

[Ole Streicher]

Uploaded, and pushed to the git repo.

Hopefully, until the next upload you (Filip) will get collab-maint rights.

Best regards

Ole

Am 08.06.2016 um 22:51 schrieb Ole Streicher:
> Hi Filip and Tobias,
> 
> I am just about to upload the package. I also created the pristine-tar.
> Just a second...
> 
> Cheers
> 
> Ole
> 
> Am 08.06.2016 um 22:49 schrieb Tobias Frost:
>> Am Mittwoch, den 08.06.2016, 20:32 +0200 schrieb Filip Hroch:
>>> Dear collegues,
>>>
  Plan C: you push your Git tree to a public place where I can
 review
 it; then I merge your changes to collab-maint and sponsor the
 upload.
 What do you think?

>>>
>>> the repository 
>>>
>>>   /srv/home/users/hroch-guest/dcraw.git
>>>
>>> on alioth provides my updates of dcraw.
>>>
>>> Thank you very much for help!
>>> FH
>>
>> master seems have to been pushed already to collab-maint :)
>>
>> however, can you please also push pristine-tar to yours?
>>

Bug#745615: dcraw maintenance

[Ole Streicher]

Hi Filip and Tobias,

I am just about to upload the package. I also created the pristine-tar.
Just a second...

Cheers

Ole

Am 08.06.2016 um 22:49 schrieb Tobias Frost:
> Am Mittwoch, den 08.06.2016, 20:32 +0200 schrieb Filip Hroch:
>> Dear collegues,
>>
>>>  Plan C: you push your Git tree to a public place where I can
>>> review
>>> it; then I merge your changes to collab-maint and sponsor the
>>> upload.
>>> What do you think?
>>>
>>
>> the repository 
>>
>>   /srv/home/users/hroch-guest/dcraw.git
>>
>> on alioth provides my updates of dcraw.
>>
>> Thank you very much for help!
>> FH
> 
> master seems have to been pushed already to collab-maint :)
> 
> however, can you please also push pristine-tar to yours?
> 

Bug#826774: ITP: genwqe-user -- A hardware accelerated version of zLib using PCIe with FPGA

[Breno Leitao]

Package: wnpp
Severity: wishlist
Owner: Breno Leitao 

* Package name: genwqe-user
  Version : 4.0.17
  Upstream Author : Frank Haverkamp
* URL : https://github.com/ibm-genwqe/genwqe-user
* License : Apache Version 2.0
  Programming Lang: C
  Description : A hardware accelerated version of zLib using PCIe with FPGA

GenWQE (Generic Work Queue Engine) is a PCIe acceleration card. This repository
contains the source code to test, maintain and update the GenWQE PCIe card.
Furthermore a zlib version with hardware acceleration is provided to do zlib
style compression/decompression according to RFC1950, RFC1951 and RFC1952. This
can be used as alternative to the traditional software zlib.

This package dependes on a specific PCIe3 FPGA Accelerator Adapter. You can
find them at:

http://www.ibm.com/support/knowledgecenter/POWER8/p8hcd/fcej12.htm
http://www.ibm.com/support/knowledgecenter/en/POWER8/p8hcd/fcej13.htm

I want to maintain this package as I am one of the main ppc64el porters, and I
am in the DD process to become one.

Bug#745615: dcraw maintenance

[Tobias Frost]

Am Mittwoch, den 08.06.2016, 20:32 +0200 schrieb Filip Hroch:
> Dear collegues,
> 
> >  Plan C: you push your Git tree to a public place where I can
> > review
> > it; then I merge your changes to collab-maint and sponsor the
> > upload.
> > What do you think?
> > 
> 
> the repository 
> 
>   /srv/home/users/hroch-guest/dcraw.git
> 
> on alioth provides my updates of dcraw.
> 
> Thank you very much for help!
> FH

master seems have to been pushed already to collab-maint :)

however, can you please also push pristine-tar to yours?

Bug#826773: RM: mboxcheck -- ROM

[Ola Lundqvist]

Package: ftp.debian.org
Severity: normal

Hi

I'm the maintainer of mboxcheck that I wrote myself many years ago to
check the number of new, read and old mails in a mbox file or a set of
mbox files.

However I do not use it anymore (and therefore do not really want to
maintain it) and according to popcon it does not look like anyone else
is using it either. I guess most people have switched to maildir now.

Considering the very low number of users I think it is better to
remove it from the archives than to let someone to take it over.

Best regards,

// Ola

-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#826771: ITP: dh-runit -- debhelper add-on to handle runit runscripts

[Dmitry Bogatov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Bogatov 

* Package Name : dh-runit
  Version  : 0.1
  Upstream Author  : None
  Url  : 
https://anonscm.debian.org/cgit/users/kaction-guest/dh-runit.git
  License  : GPL-3+
  Programming Lang : 
  Description  : debhelper add-on to handle runit runscripts

 dh-runit provides a debhelper sequence addon named 'runit' and the
 dh_runit command.
 .
 The dh_runit command installs runscripts and adds the appropriate code to
 the postinst, prerm and postrm maint scripts to properly enable/disable
 runscripts.

I plan to maintain this package myself, keeping debianization
in following Git repository:

https://anonscm.debian.org/cgit/users/kaction-guest/dh-runit.git

Bug#826772: arcanist: Arcanist package missing (except 'sid')

[Rob Earhart]

Package: arcanist
Version: 0~git20160124-1
Severity: important

Dear Maintainer,

The arcanist package appears to only be available on Debian 'sid'.
I believe it was previously available on at least 'stretch', since
I installed it on a stretch-based Docker image last week.

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

Kernel: Linux 4.4.12-boot2docker (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages arcanist depends on:
ii  libphutil  0~git20160124-1
ii  php5-cli   5.6.22+dfsg-1
ii  php5-curl  5.6.22+dfsg-1

arcanist recommends no packages.

Versions of packages arcanist suggests:
ii  python  2.7.11-1

-- no debconf information

Bug#825702: python-pypy.sandbox: Upgrading past 4.0.1 causes pypy-sandbox to crash on startup

[Stefano Rivera]

Hi raylu (2016.05.29_01:02:42_+0200)
> $ pypy-sandbox
> 'import site' failed
> debug: OperationError:
> debug:  operror-type: RuntimeError
> debug:  operror-value: None
> [Subprocess exit code: 1]

Running it with --verbose showed that the problem was an un-handled
mkdir call. It's trying to create __pycache__ directories. Those don't
exist when the pypy package isn't installed.

This is easy enough to fix.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#824795: smartmontools: remove obsolete /usr/share/man/man8/update-smart-drivedb.8.gz man page

[Christian Franke]

Smartmontools 6.5 provides a new ./configure option 
'--without-update-smart-drivedb'. It removes the update script, its man 
page and all references from the other man pages.


See: https://www.smartmontools.org/changeset/4299

Please consider to provide drivedb.h updates as a separate package which 
is updated more frequently.


Christian
smartmontools.org

Bug#826770: libqt5network5: Backport fix for bug QTBUG-47011 in Qt 5.5.1

[Matthieu Gallien]

Package: libqt5network5
Version: 5.5.1+dfsg-17
Severity: wishlist

Hello Dear maintainers,

Could you please include fix for bug QTBUG-47011 in qtbase 5.5.1 in case you
upload another package of version 5.5.1 ?

Can you please close my bug report in case you only plan to upload 5.6.y >= 0 ?
The fix is already in 5.6.0.

Thanks in advance

Best regards

PS: Thanks for your work, I appreciate it.



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

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

Versions of packages libqt5network5 depends on:
ii  libc62.22-11
ii  libproxy1v5  0.4.11-5
ii  libqt5core5a [qtbase-abi-5-5-1]  5.5.1+dfsg-17
ii  libqt5dbus5  5.5.1+dfsg-17
ii  libstdc++6   6.1.1-5
ii  zlib1g   1:1.2.8.dfsg-2+b1

libqt5network5 recommends no packages.

libqt5network5 suggests no packages.

-- no debconf information

Bug#826764: Co-maintaining cgit

[Alexander Wirt]

On Wed, 08 Jun 2016, Peter Colberg wrote:

> On Wed, Jun 08, 2016 at 09:53:00PM +0200, Alexander Wirt wrote:
> > I would be happy to accept you as co-maintainer,
> 
> Great!
> 
> > but I am not a big fan of collab-maint. Is github ok for you?
> > Otherwise I would create an alioth project.
> 
> I would prefer to have the repository on Debian infrastructure,
> so I like your last proposal best; that also provides us with
> a public mailing list to put as Maintainer.
> 
> Looking forward to work with you!
Here we are: https://alioth.debian.org/scm/?group_id=101009

I already pushed the existing repo to the new git repo.
Please request to get added to the project and I will add you. 

Alex

Bug#825124: debarchiver: allow to configure which crypto algos are accepted for uploads

[Ola Lundqvist]

Hi Christoph

Good suggestions. I'll see what I can do. Patches are as always welcome.

// Ola

On Mon, May 23, 2016 at 10:06 PM, Christoph Anton Mitterer
 wrote:
> Package: debarchiver
> Version: 0.10.5
> Severity: normal
> Tags: security
>
>
> Hi.
>
> Not sure how easy this can be done, but debarchiver should allow to reject
> weak crypto alog uploads, including:
> - signatures on the dsc/etc. files being uploaded that use a too weak
>   digest-algo for the signture itself
> - a too weak certificate signature algos, i.e. the algo used for the key/uid
>   and subkey binding signatures of the keys that are being trusted as
>   uploaders
> - .dsc/etc. files that contain too weak Cheksum entries, e.g. MD5 os SHA1 
> only.
>
>
> Thanks,
> Chris.



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#822621: xscreensaver-data-extra and xscreensaver-gl-extra should Enhance cinnamon-screensaver

[Christoph Anton Mitterer]

Thanks a lot :-)

Best wishes,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#822621: xscreensaver-data-extra and xscreensaver-gl-extra should Enhance cinnamon-screensaver

[Tormod Volden]

On Mon, May 30, 2016 at 11:08 PM, Christoph Anton Mitterer wrote:
> On Tue, 2016-04-26 at 17:56 +0200, Tormod Volden wrote:
>> > Well it's the same case as with gnome-screensaver, I thought.
>> > Both can use the screensaver modules provided by xscreensaver
>> I should probably remove the Enhance for gnome-screensaver.
>
> Or that... and tell the gnome-screensaver guys, that they should
> Recommend/Suggest your packages directly.

Yes, I think it would be correct to remove the Enhance's. I don't have
the full overview of all alternative screensaver engines and whether
they make use of the xscreensaver hacks, so I should leave that to
these other packages to figure it out for themselves.

> In any case however, I think that the dependencies(i.e. Enhances), at
> least on the xscreensaver packages) should be the same for all possible
> users (at least, cinnamon-screensaver, gnome-screensaver and mate-
> screensaver)

And that will not be a problem any longer :)

>
> btw: I just noticed, that you also mention gnome-screensaver in the
> package descriptions... I think that should also go away then, since
> gnome-screensaver is in no way more special than e.g. cinnamon-
> screensaver (or possible others like mate-screensaver).

I have already generalized the text some (in my own tree at least) but
I'll go over it and make it consistent, just mention "other
screensaver engines" or so.

Cheers,
Tormod


>
>
>> > > Wouldn't it be better to have cinnamon-screensaver Suggest these
>> > > packages? I guess cinnamon-screensaver Recommends xscreensaver-
>> > > data
>> > > and xscreensaver-gl already.
>> > Well they recommend it already... so no need for a Suggests.
>> Note that I was talking about two other packages here. I would think
>> all 4 should be Suggested.
>
> At least in the current version they recommend all 4... I personally
> have no strong opinion on whether the -extra packages should only be
> suggested...
>
>
> Cheers,
> Chris.

Bug#826769: RFS: arc-theme/20160605-1 ITP

[foss.freedom]

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "arc-theme"

 * Package name: arc-theme
   Version : 20160605-1
   Upstream Author : horst3180 
 * URL : https://github.com/horst3180/arc-theme
 * License : GPL-3+
   Section : misc

  It builds those binary packages:

arc-theme  - A flat theme with transparent elements

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

  https://mentors.debian.net/package/arc-theme


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

dget -x 
https://mentors.debian.net/debian/pool/main/a/arc-theme/arc-theme_20160605-1.dsc

  More information about hello can be obtained from https://www.example.com.
Notes:

I am the maintainer of a Ubuntu based distro called budgie-remix which

uses arc-theme as its key theme - hence why I'm excited to maintain
this package for the wider

Debian community. budgie-remix uses the new desktop environment called
budgie-desktop which I have also packaged here

 - https://lists.debian.org/debian-mentors/2016/05/msg00551.html

arc-theme is a highly popular theme used by several distros.  It is
installed currently

by users through the upstream maintainer OBS repository or via manual
compilation.

I'm providing this package to allow all Debian users and Debian
derivatives a native

package rather than depending upon a third-party non-native Debian repo.


I've asked the question here as to whether upstream will sign future
tag releases:

 - https://github.com/horst3180/arc-theme/issues/571


 Regards,

 David Mohammed

Bug#826764: Co-maintaining cgit

[Peter Colberg]

On Wed, Jun 08, 2016 at 09:53:00PM +0200, Alexander Wirt wrote:
> I would be happy to accept you as co-maintainer,

Great!

> but I am not a big fan of collab-maint. Is github ok for you?
> Otherwise I would create an alioth project.

I would prefer to have the repository on Debian infrastructure,
so I like your last proposal best; that also provides us with
a public mailing list to put as Maintainer.

Looking forward to work with you!

Peter

Bug#826767: gnome-shell: unable to use empathy chat pop up on Wayland

[Roberto De Oliveira]

Package: gnome-shell
Version: 3.20.2-1
Severity: normal

Hello dear mantainer,

On my Debian Testing box I switched to Wayland and everything works
fine except empathy popup menu to answer a chat, it is impossible
to focus on text entry to write message.

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

Kernel: Linux 4.5.0-2-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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  evolution-data-server3.20.2-2
ii  gir1.2-accountsservice-1.0   0.6.40-3
ii  gir1.2-atspi-2.0 2.20.2-1
ii  gir1.2-caribou-1.0   0.4.20-1
ii  gir1.2-clutter-1.0   1.26.0-2
ii  gir1.2-freedesktop   1.48.0-2
ii  gir1.2-gcr-3 3.20.0-2
ii  gir1.2-gdesktopenums-3.0 3.20.0-3
ii  gir1.2-gdm-1.0   3.20.1-1
ii  gir1.2-gkbd-3.0  3.6.0-1
ii  gir1.2-glib-2.0  1.48.0-2
ii  gir1.2-gnomebluetooth-1.03.18.3-1
ii  gir1.2-gnomedesktop-3.0  3.20.2-1
ii  gir1.2-gtk-3.0   3.20.6-1
ii  gir1.2-gweather-3.0  3.20.1-1
ii  gir1.2-ibus-1.0  1.5.11-1
ii  gir1.2-mutter-3.03.20.2-1
ii  gir1.2-networkmanager-1.01.2.2-2
ii  gir1.2-nmgtk-1.0 1.2.2-1
ii  gir1.2-pango-1.0 1.40.1-1
ii  gir1.2-polkit-1.00.105-15
ii  gir1.2-soup-2.4  2.54.1-1
ii  gir1.2-telepathyglib-0.120.24.1-1.1
ii  gir1.2-telepathylogger-0.2   0.8.2-1
ii  gir1.2-upowerglib-1.00.99.4-2
ii  gjs  1.45.3-2
ii  gnome-backgrounds3.20-1
ii  gnome-icon-theme-symbolic3.12.0-2
ii  gnome-settings-daemon3.20.1-1
ii  gnome-shell-common   3.20.2-1
ii  gsettings-desktop-schemas3.20.0-3
ii  libatk-bridge2.0-0   2.20.1-2
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-9
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libclutter-1.0-0 1.26.0-2
ii  libcogl-pango20  1.22.0-2
ii  libcogl201.22.0-2
ii  libcroco30.6.11-1
ii  libdbus-glib-1-2 0.106-1
ii  libecal-1.2-19   3.20.2-2
ii  libedataserver-1.2-213.20.2-2
ii  libgcr-base-3-1  3.20.0-2
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libgirepository-1.0-11.48.0-2
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.45.3-2
ii  libglib2.0-0 2.48.1-1
ii  libgstreamer1.0-01.8.1-1
ii  libgtk-3-0   3.20.6-1
ii  libical2 2.0.0-0.4
ii  libicu55 55.1-7
ii  libjson-glib-1.0-0   1.2.0-1
ii  libmozjs-24-024.2.0-3
ii  libmutter0h  3.20.2-1
ii  libnm-glib4  1.2.2-2
ii  libnm-util2  1.2.2-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpolkit-agent-1-0  0.105-15
ii  libpolkit-gobject-1-00.105-15
ii  libpulse-mainloop-glib0  8.0-2+b2
ii  libpulse08.0-2+b2
ii  libsecret-1-00.18.3-1
ii  libstartup-notification0 0.12-4
ii  libsystemd0  230-2
ii  libtelepathy-glib0   0.24.1-1.1
ii  libx11-6 2:1.6.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  mutter   3.20.2-1
ii  python3  3.5.1-3
ii  telepathy-mission-control-5  1:5.16.3-2

Versions of packages gnome-shell recommends:
ii  gdm3 

Bug#826768: RM: gnuplot5 -- ROM; v.5 was uploaded to gnuplot package

[Anton Gladky]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear FTP team,

please remove the package gnuplot5. The version 5 of
this program was uploaded to the package gnuplot. That
is why, gnuplot5 is not needed as a transitional package
(to keep v.4 and v.5 together) any more.

Thank you

Anton

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXWHo6AAoJENPhc4PPp/8Gc4IP/jh7YjbormUsQ8dsiUehgcrB
7X+bUUE9LC5GAF+q2sVdp3Hy/Mb+K9aoa+ktrfIicVlfx5o/UkybpZE1Eg4kQDXl
MB2ZG1qkUxgpJMQX6tHhCOEy5f6IF4Pr4WrCPLctzZi+x7MLH24MOVcxHAmoMuMq
OpxoH0o1b23SzHGAQXVJlSW03ttJQMoSjM0gSEimdcp0HXNLQPORfz4lP3tscoK+
ORJfbWEkEtks/Z/nCOpHJRTaglbpSGoDoHHr63gquWEF2cGteYVG2/cEdNKViLn3
LweiT0Dl70TmN8emamLjhNcaXnJOWOW5W8ws1C4hRWzvPqKZu71OXEnB/FPhiUQU
YdDPay6UbNVXzmbaYVXA07ELpuc8C/6rQFIj3jpe+VBnrmhCIamV4gNly1lM3q1i
7kD9B/Iq0nwhSPKmvgYYQMKtvoihKgBdAWeakH5933/QRgoqbY9ZzSRao+aC1iee
cVAHkJhy7qFRPITQ6cU+d8nupnWDbEYuJ6ZIxcMfISjA4loNp5m6vP+pKoAW7T2T
QKqlY33j5XwWEIIJ48aiAguNKU0+gsb+swbodmBTDYvt4bfkLYGKlcAbqoh+HnBx
qijEH6WdpihWNlJJxuUfvq7YZliuq81CYYIn6RjV3+THpvH6zfTJt0j48xjlHSKJ
BhdSRReAk9XQM8DE6ucw
=jG+V
-END PGP SIGNATURE-

Bug#826509: xscreensaver: Please hide xscreensaver-properties.desktop in GNOME

[Tormod Volden]

On Sun, Jun 5, 2016 at 9:49 PM, Laurent Bigonville wrote:
> I would be nice if xscreensaver-properties.desktop was not displayed by
> default in GNOME (and probably others).

It seems there are many GNOME users who still want to use
xscreensaver. They expect to find the preference panel if they have
installed this package.

For single-user systems there is no problem. The GNOME purist can just
remove the xscreensaver package.

For multi-user, multi-DE systems I think the administrator can just
customize the desktop file as wanted, or let the users disable it
themselves if they want. See also
https://anonscm.debian.org/cgit/collab-maint/xscreensaver.git/commit/?id=ca4381e9a0fda1779f84386236155a56e289826d

>
> GNOME is providing its owned screensaver implementation and in a near

Users should have the freedom to choose an alternative even if GNOME
offers its own screensaver, IMO.

> future we are planning to switch to wayland, that would mean that
> xscreensaver will not work anyway.

Why will it not work? Will X applications not work in general? In this
case are you going to manually add Noshow=Gnome to all these
applications, or is some smarter mechanism planned?

Regards,
Tormod

Bug#826766: alljoyn-core-1504: Incorrect fix for armel/armhf (patch attached)

[Adam Conrad]

Package: alljoyn-core-1504
Version: 15.04b-3
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch



In Ubuntu, the attached patch was applied to achieve the following: 


  * Use same logic as alljoyn-services for x86 and ARM.

This patch makes more sense in the context of Bug#826765, which has a
dependency on this one (due to building with 'arm' as a target, which
only works with the 'rm -rf' in this patch).

It also simplifies and corrects the x86 bits to match what I did in
the other bug's patch, as all i*86 should be considered x86, not just
i686.

... Adam

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

Kernel: Linux 4.4.0-21-lowlatency (SMP w/4 CPU cores; PREEMPT)
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)
diff -Nru alljoyn-core-1504-15.04b/debian/rules alljoyn-core-1504-15.04b/debian/rules
--- alljoyn-core-1504-15.04b/debian/rules	2016-06-03 00:23:49.0 -0600
+++ alljoyn-core-1504-15.04b/debian/rules	2016-06-07 09:20:45.0 -0600
@@ -10,17 +10,7 @@
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
-CPU=$(shell dpkg-architecture -qDEB_HOST_GNU_CPU)
-# mapping i386 to x86 for Alljoyn
-ifeq ($(CPU),i686) 
-  export CPU = "x86"
-endif
-# we need to check the CPU and do not conflict with
-# the already existing "arm" for cross compiling
-# TODO: check whether this is ok for armel and armhf
-ifeq ($(CPU),arm) 
-  export CPU = "armhf"
-endif
+CPU=$(shell dpkg-architecture -qDEB_HOST_GNU_CPU | sed -e 's/i.86/x86/')
 OS=linux
 
 export VERSION := 15.04b
@@ -62,6 +52,7 @@
 	dh_auto_build
 
 override_dh_auto_clean:
+	rm -rf build_core/conf/linux/arm
 	rm -f .sconsign.dblite
 	rm -rf .sconf_temp
 	rm -f config.log

Bug#826764: Co-maintaining cgit

[Alexander Wirt]

On Wed, 08 Jun 2016, Peter Colberg wrote:

> Source: cgit
> Severity: wishlist
> 
> Hi Alexander,
> 
> I have been using cgit on a personal server for the better part of a
> decade. Now that I have applied to become Debian maintainer [1–3], I
> am interested in helping maintain cgit. I closely follow the upstream
> mailing list and contributed two minor commits [4].
> 
> [1] https://bugs.debian.org/825586
> [2] https://lists.debian.org/debian-newmaint/2016/06/msg4.html
> [3] https://lists.debian.org/debian-newmaint/2016/05/msg00037.html
> [4] http://thread.gmane.org/gmane.comp.version-control.cgit/2756
> 
> Would you be interested in having me as a co-maintainer for cgit?
> 
> I noticed that debian/changelog contains git commit ids. What do you
> think of creating a collab-maint repository to which you push your
> current packaging? I would begin by updating the package to the
> latest version (v1.0) and processing the outstanding bug reports.
I would be happy to accept you as co-maintainer, but I am not a big fan of
collab-maint. Is github ok for you? Otherwise I would create an alioth
project. 

Alex



signature.asc
Description: PGP signature

Bug#794109: ITP: python-pypandoc -- Python wrapper for pandoc

[Elena ``of Valhalla'']

On 2016-05-11 at 15:08:24 +0200, Gianfranco Costamagna wrote:
> Hi Elena, what is the status of this ITP?
> do you have some work done, or do you need a sponsor?

I talked with Gianfranco on IRC and forgot to update the ITP, sorry

Yes, I have an almost-ready package, I still had to give a look at the
code of the new upstream release, which I've just done (and updated the
copyright file accordingly).

Now in the repo there is still an issue caused by me using git-dpm
wrong, which Gianfranco already afaik solved locally, and that's the
last thing significantly preventing an upload.

-- 
Elena ``of Valhalla''

Bug#826765: alljoyn-services-1504: FTBFS on arm and i386, patch attached

[Adam Conrad]

Package: alljoyn-services-1504
Version: 15.04-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch



In Ubuntu, the attached patch was applied to achieve the following:

  * Set CPU to x86 when dpkg-architecture -qDEB_HOST_GNU_CPU reports i?86
  * Drop build_core/conf/linux/arm to stop misconfiguration on arm{el,hf}

The arm target in the upstream source has no relevance at all to the
arm ports in Debian (not only does it require cross-compiling, but it
also targets the raspberry pi specifically).  Given that, it's not
reasonable to even ship those bits in Debian, so I took a different
approach than you did in fixing this in Ubuntu.

My fix depends on the same fix being made to alljoyn-core first, which
I will submit as another bug and reference this one.

... Adam


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

Kernel: Linux 4.4.0-21-lowlatency (SMP w/4 CPU cores; PREEMPT)
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)
diff -Nru alljoyn-services-1504-15.04/debian/rules alljoyn-services-1504-15.04/debian/rules
--- alljoyn-services-1504-15.04/debian/rules	2016-06-04 14:46:12.0 -0600
+++ alljoyn-services-1504-15.04/debian/rules	2016-06-07 09:14:40.0 -0600
@@ -10,7 +10,7 @@
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
-CPU=$(shell dpkg-architecture -qDEB_HOST_GNU_CPU)
+CPU=$(shell dpkg-architecture -qDEB_HOST_GNU_CPU | sed -e 's/i.86/x86/')
 OS=linux
 
 export VERSION := 15.04b
@@ -59,6 +59,7 @@
 	dh_auto_build
 
 override_dh_auto_clean:
+	rm -rf build_core/conf/linux/arm
 	rm -f sample_apps/.sconsign.dblite
 	rm -rf sample_apps/.sconf_temp
 	rm -f services_common/.sconsign.dblite

Bug#712564: pamassassin: Add feature to run spamassassin as debian-spamd user

[Miklos Quartus]

Package: spamassassin
Followup-For: Bug #712564

> please add the feature to run spamassassin as debian-spamd user. 
Why so? When spamassassin is running in daemon mode (spamd) as root,
the default behaviour is to setuid to the user running spamc. This lets
spamd to load and examine the per-user configuration files as the user. So
by default, the effective UID is sent to spamd from spamc.

Certainly there is a point in what you are suggesting. You are welcome
to send a patch for each configuration file where this change could be
introduced as an added feature. The alternative username could be passed
on to 'spamd' after the '-u' switch.

Regards, 
-- 
Miklos Quartus 
WWW: http://www.miklos.info 
GPG: 3C4B 1364 A379 7366 7FED  260A 2208 F2CE 3FCE A0D3


signature.asc
Description: PGP signature

Bug#826764: Co-maintaining cgit

[Peter Colberg]

Source: cgit
Severity: wishlist

Hi Alexander,

I have been using cgit on a personal server for the better part of a
decade. Now that I have applied to become Debian maintainer [1–3], I
am interested in helping maintain cgit. I closely follow the upstream
mailing list and contributed two minor commits [4].

[1] https://bugs.debian.org/825586
[2] https://lists.debian.org/debian-newmaint/2016/06/msg4.html
[3] https://lists.debian.org/debian-newmaint/2016/05/msg00037.html
[4] http://thread.gmane.org/gmane.comp.version-control.cgit/2756

Would you be interested in having me as a co-maintainer for cgit?

I noticed that debian/changelog contains git commit ids. What do you
think of creating a collab-maint repository to which you push your
current packaging? I would begin by updating the package to the
latest version (v1.0) and processing the outstanding bug reports.

Regards,
Peter


signature.asc
Description: PGP signature

Bug#826331: apt-cacher-ng (stable): Cannot cache for a testing machine (but for sid)

[Helge Kreutzmann]

Hello Eduard,
On Sun, Jun 05, 2016 at 01:09:42PM +0200, Eduard Bloch wrote:
> * Helge Kreutzmann [Sat, Jun 04 2016, 06:02:40PM]:
> > Package: apt-cacher-ng
> > Version: 0.8.0-3
> > Severity: normal
> > 
> > I set up apt-cacher-ng recently on this machine to cache an testing
> > machine[1]. It worked initially (i.e. on the first day the testing
> > machine connects). Now I can only download files which were present in
> > the archive on that day since the lists files seem to be static (i.e.
> > not updated).
> > 
> > The symptoms are like #807909. Thus I tried to implement the cure
> > mentioned there.
> 
> It was not for the stable version :-)
> 
> Please try an official backport version for stable.

I rebuild the latest version from sid on stable and so far it works as
expected.

> > And I cannot install newer versions in testing (i.e. only those which
> > are still unchanged in testing from the day the initial install was
> > done).
> > 
> > Strangely, a chroot on the same machine running sid does not show this
> > problem, i.e. works flawlessly ...
> 
> That regex was added to default settings on Sid/Testing/Backports some months 
> ago, no need for further
> changes.

Well, acng runs on stable serving a sid chroot. But still, I think
this fix would be worth for the next point release of stable.


> > [1] Actually the one we discussed in #772489, i.e. currently apt-get
> > points on the testing machine to the apt-cacher on the stable
> > machine, I tried to put apt-cacher-ng on the testing machine
> > inbetween but failed due to #772489.
> 
> I see... as workaround for 772489, could you configure "bindaddress:0.0.0.0" 
> and check what happens?

Will do later.

Also I will probably give the testing machine direct internet access
during the weekend, so if you need some additional checks please send
them to me in the next days.

Thanks agoin for your speedy and very helpful replies.

Greetings

  Helge


-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#826727: anki: Anki does not start anymore

[Andreas Bombe]

merge 826727 784612
thanks

On Wed, Jun 08, 2016 at 02:08:08PM +0200, Matthias Wimmer wrote:
> Package: anki
> Version: 2.0.32+dfsg-1
> Severity: grave
> Justification: renders package unusable
> 
> Anki does not start anymore. When called from the command line, I get the
> following traceback:
> 
> =
> Traceback (most recent call last):
>   File "/usr/bin/anki", line 7, in 
> import aqt
>   File "/usr/share/anki/aqt/__init__.py", line 12, in 
> from aqt.qt import *
>   File "/usr/share/anki/aqt/qt.py", line 22, in 
> from PyQt4.QtWebKit import QWebPage, QWebView, QWebSettings
> ImportError: No module named QtWebKit
> =

Yes, QtWebKit was removed from the Qt4 in Debian. There is no fix other
than a Qt5 port of anki.

Bug#825863: percona-xtradb-cluster-galera-2.x: should it be removed from Debian?

[Sebastian Andrzej Siewior]

retitle 825863 RM: percona-xtradb-cluster-galera-2.x -- RoQA; NPOASR; FTBFS; 
RC-buggy; unmaintained; low popcon
severity 825863 normal
reassign 825863 ftp.debian.org 
thanks

Dear FTP-Master,

please remove percona-xtradb-cluster-galera-2.x from unstable. It is
RC-buggy and FTBFS (not to mention that it is attached to libssl1.0.0).
James Page (the maintaienr) assumed it was already gone:

On 2016-05-31 14:34:24 [+], James Page wrote:
> +1 (to be honest I though I had already done this when we removed the main
> percona-xtradb-cluster-5.5 package from the archive)

His reply is part of this bug which I reassign herewith.

Sebastian

Bug#826763: ITP: xidel -- Command line tool to download and query HTML/XML/JSON with XQuery

[Benito van der Zander]

Package: wnpp
Severity: wishlist
* Package name: xidel
  Version : 0.9.4
  Upstream Author : Benito van der Zander 
* URL : http://www.videlibri.de/xidel.html
* License : GPLv3
  Programming Lang: Pascal
  Description : Command line tool to download and query 
HTML/XML/JSON with XQuery


 Xidel is a command line tool to query data from HTML/XML web pages, 
JSON-APIs

 and local files.
 .
 It implements interpreters for XPath 2, XPath 3, XQuery 1, XQuery 3, 
JSONiq,

 CSS selectors and custom pattern matching.
 .
 XPath and CSS selectors are the most efficient way to select certain 
elements

 from XML/HTML documents.
 JSONiq (with custom extensions) is an easy way to select data from JSON.
 .
 XQuery is a Turing-complete superset of XPath and allows arbitrary data
 transformations and the creation of new documents.
 .
 Pattern matching is for XML/HTML documents what regular expressions 
are for
 plaintext, i.e. pattern matching behaves like a regular expression 
over the

 space of tags, instead over the space of characters.
 .
 Xidel implements a kind of internal pipes to pipe HTTP requests from 
one query
 to the next, so there is no need to distinguish selecting links and 
downloading
 the data referenced by them. Therefore arbitrary complex queries going 
over

 arbitrary many pages can be executed with a single call of Xidel.



The deb files at 
https://sourceforge.net/projects/videlibri/files/Xidel/Xidel%200.9.4/ 
should be packagable

Bug#826762: ITP: arc-theme -- A flat theme with transparent elements

[foss.freedom]

Package: wnpp
Severity: wishlist

Owner: David Mohammed 

Package name: arc-theme
Version: 20160605
Upstream Author : horst3180
URL: https://github.com/horst3180/arc-theme
License: GPL 3+
Programming Lang: N/A
Description: A flat theme with transparent elements
 Arc is a flat theme with transparent elements for GTK 3, GTK 2 and
 Gnome-Shell which supports GTK 3 and GTK 2 based desktop environments
 like Gnome, Unity, Budgie, Pantheon, XFCE, Mate, etc.
 .
 Arc is available in three variants:
 Arc, Arc-Darker, Arc-Dark

Bug#824930: [Android-tools-devel] Bug#824930: Bug#824930: Bug#824930: Bug#824930: apktool: creates directories and an empty 1.apk file in $HOME

[Chirayu Desai]

This was discussed on IRC, and since we already need to build
framework-res.apk for android.jar (it is extracted and the contents
are included as-is in the jar), we can also have a separate package
for it, which I have ready at:
https://gitlab.com/cde/debian_android-tools_android-platform-frameworks-base/commit/1ea978033eb92e0c7c14f1ca40c61d84b2a2e7f1

i also have made changes to apktool to use that, however I need to
make some changes based on the feedback I got.

On Wed, Jun 8, 2016 at 5:37 PM, Hans-Christoph Steiner  wrote:
> I think it might be more honest to help the user fetch framework-res.apk
> from a connected device or emulator using `adb pull` rather than
> including one in Debian, since for many use cases, it'll require a
> different framework-res.apk.  Like the example in the apktool docs,
> where it talks about an HTC-specific framework-res.apk:
> https://ibotpeaches.github.io/Apktool/documentation/
>
> Perhaps `apktool install-framework` could modified to do this? Or just a
> standalone script?
>
> I think we should definitely patch apktool to set an XDG dir.  I prefer
> ~/.local/share/apktool since the file is required for apktool to work,
> but ~/.cache/apktool would be OK.
I have a patch locally that makes it use ~/.local/share/apktool, can
update it / push it as preferred.
>
> ___
> Android-tools-devel mailing list
> android-tools-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel

Bug#803405: does not properly restore console colors on exit anymore

[Javier Cantero]

I've found a way to fix this bug reverting a change in libncursesw5
(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816887 ) but note
that this is not the definitive fix but a workaround (it's not clear
that the failure is in the library or because mutt is misusing it
somehow).

Another analysis of the bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825054#15

(Also #825054 should be merged here)


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#826755: [PATCH] Add Lua 5.3 support

[Asbjørn Sloth Tønnesen]

Hi Jon,

On Wed, 8 Jun 2016 14:11:42 -0400, Jon Bernard  wrote:
> Can you try building this?

Builds fine with dh-lua 23, based on the changelog I guess 21+ should do.
http://metadata.ftp-master.debian.org/changelogs/main/d/dh-lua/dh-lua_23_changelog

diff --git a/debian/control b/debian/control
index 7d5a251..ecb98ba 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: lua-iconv
 Section: interpreters
 Priority: optional
 Maintainer: Jon Bernard 
-Build-Depends: debhelper (>= 8.1.3), dh-lua, pkg-config
+Build-Depends: debhelper (>= 8.1.3), dh-lua (>= 21), pkg-config
 Standards-Version: 3.9.3
 Vcs-Git: git://anonscm.debian.org/pkg-lua/lua-iconv.git
 Vcs-Browser: http://anonscm.debian.org/cgit/pkg-lua/lua-iconv.git/

-- 
Best regards
Asbjørn Sloth Tønnesen

Bug#826301: Needs new signature

[Elliott Mitchell]

Okay now know what is going on.  `update-flashplugin-nonfree --status`
retrieves the currently installed version from libflashplayer.so and
the available version by looking at adobe.com.

Meanwhile, `update-flashplugin-nonfree --install` retrieves a signature
from either 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.${version}.sha512.${arch}.pgp.asc
or 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.${arch}.pgp.asc
and tries to install that version.  Problem is either bartm is
unavailable or otherwise indisposed at the moment so the signatures
haven't been updated.

Thanks for the long term of service Bart Martens, but we've got a problem
here!


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

[Gianfranco Costamagna]

Hi


>I had already added it already to
>* control
>Depends: ${python:Depends}, python-tz, ${misc:Depends}

>which was mangled (with warning) to:

maybe you are installing the files in usr/lib/foo, instead of usr/lib/python*/
and then dh_python2 is not acting correctly?
I don't think installing python stuff outside that directory is a good idea...


>@@ -1,4 +1,4 @@
>-#!/usr/bin/python2 -BEsSt
>+#!/usr/bin/python2.7 -BEsSt


this should be also handled by dh_python2 AFAIK

>Everything seems to work without it also and the same package could have been
>used for python2.6 and python2.7 systems but lintian does not understand that.


well, installing into usr/lib/python* should fix that issue


I would prefer you to ask on debian-python about this issue, because I'm 
wondering
about something bad that is just hidden and will be spot when the package 
enters the
archive.

having an ack for a more python-savvy person would be great
(I could even sponsor the package as-is, but I'm not too confident with that)

>I hope this fixed all the review comments for regarding the packaging. I would 
>like to keep the deeper restructuring of upstream code + Debian packaging 
>scripts for upstream/Debian release V0.0.3. Is that OK from Debian side?


it is ok to have new uploads, don't worry about that, I just would like to have 
a feedback
from another DD before uploading/finish the review.


is it possible for you?
otherwise let me know and I'll finish the review and do the final checks+upload.

G.

Bug#826761: android-sdk: JDK missing

[Mouaad Aallam]

Package: android-sdk
Version: 24.3.3+2
Severity: normal

Hello,

While I was setting up a chroot environment to build an app using only 
android-sdk package, I noticed that Java JDK had not been installed, something 
that android-sdk package I suppose should do.


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

Kernel: Linux 4.4.0-22-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages android-sdk depends on:
ii  android-sdk-build-tools 23.0.2+2
ii  android-sdk-common  24.3.3+2
ii  android-sdk-platform-tools  23.0.0+2
ii  libgl1-mesa-glx 11.2.2-1
ii  libosmesa6  11.2.2-1
ii  libswt-gtk-3-java   3.8.2-3
ii  proguard5.2.1-4

android-sdk recommends no packages.

android-sdk suggests no packages.

-- no debconf information

Bug#816887: libncursesw5: background color of mutt's message is black

[Javier Cantero]

I've found that the bug has been happening since this change:

http://invisible-island.net/ncurses/NEWS.html#t20151017

+ remove an early-return from _nc_do_color, which can interfere with
  data needed by bkgd when ncurses is configured with extended colors
  (patch by Denis Tikhomirov).

I've applied this patch (to undo it) and now mutt is working as before:

8<8<8<8<8<8<
diff -ru ncurses-6.0+20160319/ncurses/base/lib_color.c 
ncurses-6.0+20160319.new/ncurses/base/lib_color.c
--- ncurses-6.0+20160319/ncurses/base/lib_color.c   2015-10-17 
22:39:18.0 +0200
+++ ncurses-6.0+20160319.new/ncurses/base/lib_color.c   2016-06-07 
18:21:35.366456528 +0200
@@ -858,6 +858,8 @@
}
 } else {
reset_color_pair(NCURSES_SP_ARG);
+if (old_pair < 0)
+   return;
 }
 
 #if NCURSES_EXT_FUNCS
8<8<8<8<8<8<

Other ncurses applications don't exhibit the same behaviour, so maybe something
is wrong with mutt (but it's not easy to follow due to the large amount of
calls to refresh() and endwin() present in its code).


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#745615: dcraw maintenance

[Filip Hroch]

Dear collegues,

>  Plan C: you push your Git tree to a public place where I can review
> it; then I merge your changes to collab-maint and sponsor the upload.
> What do you think?
> 

the repository 

  /srv/home/users/hroch-guest/dcraw.git

on alioth provides my updates of dcraw.

Thank you very much for help!
FH
-- 
F. Hroch  e-mail, jabber: hr...@physics.muni.cz, tel.: +420549494470
Dept. of theor. physics and astrophysics, MU Brno, Kotlarska 2,CZ-611 37