Bug#824799: youtube-dl: please package youtube release 2016.05.16 which upstream released some days ago.

[shirish शिरीष]

Package: youtube-dl
Version: 2016.02.22-1
Severity: wishlist

Dear Maintainer,
Please package release 2016.05.16 which were released by upstream few days.

Looking forward to it.

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

Kernel: Linux 4.5.0-2-amd64 (SMP w/2 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 youtube-dl depends on:
ii  python-pkg-resources  20.10.1-1
pn  python:any

Versions of packages youtube-dl recommends:
ii  aria2 1.21.0-1
ii  curl  7.47.0-1
ii  ffmpeg7:3.0.2-2
ii  mpv   0.14.0-1+b2
ii  rtmpdump  2.4+20151223.gitfa8646d.1-1
ii  wget  1.17.1-2

youtube-dl suggests no packages.

-- no debconf information


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

Bug#824081: Debian bug report

[Raphaël Halimi]

Le 13/05/2016 11:55, Santiago Ruano Rincón a écrit :
> El 13/05/16 a las 10:16, Raphael Hertzog escribió:
>> I don't think that any of this is required... the problem is that we run
>> the hook from the current directory which is not accessible to the
>> "debian-security-support" user. We should probably just "cd /" at the
>> start of the hook script...
>>
>> Or "cd $TEMPDIR" before running check-support-status.
> 
> Try this package then:
> https://people.debian.org/~santiago/debian/santiago-unstable/debian-security-support_2016.05.13~1_all.deb

It seems that this package fixed the issue, I didn't see the error
message since I installed it.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#824806: golang: random_build_path_by_golang_compiler is #824806

[Geert Stappers]

Hello reproducible-builds team

Please add #824806 to 
https://tests.reproducible-builds.org/issues/unstable/random_build_path_by_golang_compiler_issue.html


Thanks
Regards
Geert Stappers

Bug#824792: new upstream release: 0.8.0

[Ondřej Surý]

Package: src:librabbitmq
Version: 0.7.1-1
Severity: wishlist

Hi folks,

looks like there's a new upstream version (since Apr 10).  Let me know
if you don't have time, I could prepare NMU (and fix the missing .a in
one go).

Cheers,
Ondrej

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

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

Bug#824707: systemd: I get fsck's every other boot: due to systemd-timesyncd not updating hwclock?

[Michael Biebl]

Am 19.05.2016 um 21:30 schrieb Manuel Bilderbeek:
> 
> -- Logs begin at ma 2028-05-22 12:37:10 CEST, end at do 2016-05-19
> 21:22:23 CEST. --
> 
> Looks like I need to have systemd-timesync run *before* systemd-fsck!?

If your hwclock drifts that much, maybe
/etc/e2fsck.conf:
[options]
broken_system_clock=1

(as referenced in my earlier reply) is an option.
Can you try that?


Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#824730: u-boot: Please add a package for DRA7xx systems

[Vagrant Cascadian]

Control: tags 824730 pending

On 2016-05-19, Ben Hutchings wrote:
> On Thu, 2016-05-19 at 11:05 -0700, Vagrant Cascadian wrote:
>> On 2016-05-19, Ben Hutchings wrote:
>> > u-boot 2016.03 works for me on a DRA74 EVM (aka Vayu) board.  Please
>> > apply the attached patch to add a package for this platform.
>> 
>> Thanks for the patch!
>> 
>> Would you be ok with adding it to the u-boot-omap package?
> [...]
>
> That seems reasonable - the DRA7xx platform is quite similar to OMAP5.

Ok, added to both master and the experimental-2016.05 branches in git.

Also fixed the FTBFS with master by pulling in a couple more patches
From upstream, thanks for the reminder on that!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#824806: golang: random_build_path_by_golang_compiler

[Geert Stappers]

Source: golang
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Moin fellow DDs,

At 
https://tests.reproducible-builds.org/issues/unstable/random_build_path_by_golang_compiler_issue.html
are a few packages listed that are effected. However there are more golang 
packages.

Those few effected packages are either the last or the first packages
which are unreproducible due random build path by golang compiler.

The above URL of https://tests.reproducible-builds.org/issues/ has no bugreport
about identifier random_build_path_by_golang_compiler listed yet.

This BR is for filling that "gap".


Cheers
Geert Stappers

Bug#824808: gdal: please make the build reproducible (fileordering)

[Alexis Bienvenüe]

Source: gdal
Version: 2.1.0+dfsg-2
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

While working on the “reproducible builds” effort [1], we have noticed
that 'gdal' could not be built reproducibly.

Either one of the two attached patches fixes the order files are passed
to libtool — but I don't know if one of them could be an acceptable
solution.
One applied, gdal can be built reproducibly in our current experimental
framework.

Regards,
Alexis Bienvenüe.

[1]: https://wiki.debian.org/ReproducibleBuilds
Description: Sort files
 Sort files passed as arguments to make the build reproducible.
Author: Alexis Bienvenüe 

Index: gdal-2.1.0+dfsg/GNUmakefile
===
--- gdal-2.1.0+dfsg.orig/GNUmakefile
+++ gdal-2.1.0+dfsg/GNUmakefile
@@ -53,7 +53,7 @@ $(GDAL_SLIB): $(GDAL_OBJ) $(GDAL_LIB)
-o $(GDAL_SLIB)
 
 $(LIBGDAL):$(GDAL_OBJ:.o=.lo)
-   $(LD) $(LDFLAGS) $(LIBS) -o $@ $(GDAL_OBJ:.o=.lo) \
+   $(LD) $(LDFLAGS) $(LIBS) -o $@ `LC_ALL=C ls $(GDAL_OBJ:.o=.lo) 
2>/dev/null` \
-rpath $(INST_LIB) \
-no-undefined \
-version-info $(LIBGDAL_CURRENT):$(LIBGDAL_REVISION):$(LIBGDAL_AGE)
Description: Sort files
 Sort files passed as arguments to make the build reproducible.
Author: Alexis Bienvenüe 

Index: gdal-2.1.0+dfsg/GNUmakefile
===
--- gdal-2.1.0+dfsg.orig/GNUmakefile
+++ gdal-2.1.0+dfsg/GNUmakefile
@@ -53,7 +53,11 @@ $(GDAL_SLIB):$(GDAL_OBJ) $(GDAL_LIB)
-o $(GDAL_SLIB)
 
 $(LIBGDAL):$(GDAL_OBJ:.o=.lo)
-   $(LD) $(LDFLAGS) $(LIBS) -o $@ $(GDAL_OBJ:.o=.lo) \
+   $(MAKE) $(LIBGDAL).buildit
+
+.PHONY: $(LIBGDAL).buildit
+$(LIBGDAL).buildit:
+   $(LD) $(LDFLAGS) $(LIBS) -o $(LIBGDAL) $(sort $(wildcard 
$(GDAL_OBJ:.o=.lo))) \
-rpath $(INST_LIB) \
-no-undefined \
-version-info $(LIBGDAL_CURRENT):$(LIBGDAL_REVISION):$(LIBGDAL_AGE)

Bug#824809: nmu: libpng1.6, gdal transition in experimental

[Andreas Beckmann]

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

Let's finish the libpng1.6 and gdal transitions in experimental:

nmu weston_1.9.92-2 . ANY . experimental . -m "Rebuild against libpng1.6."
nmu wesnoth-1.13_1:1.13.4-1 . ANY . experimental . -m "Rebuild against 
libpng1.6."
nmu libharu_2.3.0+dfsg-1~exp1 . ANY . experimental . -m "Rebuild against 
libpng1.6."
nmu flightgear_3.6.0~git20151105+1d36b4-1~exp1 . ANY . experimental . -m 
"Rebuild against libpng1.6."
nmu opencv_3.0.0+dfsg-1~exp2 . ANY . experimental . -m "Rebuild against 
libpng1.6."
nmu qtbase-opensource-src_5.6.0+dfsg-2 . ANY . experimental . -m "Rebuild 
against libpng1.6."
nmu qtwebkit-opensource-src_5.6.0+dfsg-1 . ANY . experimental . -m "Rebuild 
against libpng1.6."

nmu vtk6_6.3.0+dfsg1-1~exp2 . ANY . experimental . -m "Rebuild against gdal 
2.1.0."


Andreas

Bug#824794: python-snuggs: FTBFS: ../../../test_snuggs.py:154: AssertionError

[Chris Lamb]

Source: python-snuggs
Version: 1.3.1-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-snuggs fails to build from source in unstable/amd64:

  [..]

  dh_testdir
  dh_testroot
  dh_prep
  dh_testdir
  dh_testroot
  dh_install
  dh_installdocs
  dh_installchangelogs
  dh_compress
  dh_fixperms
  dh_installdeb
  dh_gencontrol
  dh_md5sums
  dh_builddeb
  dpkg-deb: building package 'python-snuggs-build-deps' in 
'../python-snuggs-build-deps_1.3.1-2_all.deb'.
  
  The package has been created.
  Attention, the package has been created in the current directory,
  not in ".." as indicated by the message above!
  Selecting previously unselected package python-snuggs-build-deps.
  (Reading database ... 23081 files and directories currently installed.)
  Preparing to unpack python-snuggs-build-deps_1.3.1-2_all.deb ...
  Unpacking python-snuggs-build-deps (1.3.1-2) ...
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Correcting dependencies... Done
  The following additional packages will be installed:
libblas-common libblas3 libgfortran3 liblapack3 python-all python-click
python-colorama python-numpy python-py python-pyparsing python-pytest
python-setuptools python3-all python3-click python3-colorama python3-numpy
python3-pkg-resources python3-py python3-pyparsing python3-pytest
python3-setuptools
  Suggested packages:
gfortran python-dev python-nose python-numpy-dbg python-numpy-doc subversion
python-pytest-xdist python-pyparsing-doc python-mock python-setuptools-doc
python3-dev python3-nose python3-numpy-dbg
  The following NEW packages will be installed:
libblas-common libblas3 libgfortran3 liblapack3 python-all python-click
python-colorama python-numpy python-py python-pyparsing python-pytest
python-setuptools python3-all python3-click python3-colorama python3-numpy
python3-pkg-resources python3-py python3-pyparsing python3-pytest
python3-setuptools
  0 upgraded, 21 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  Need to get 7155 kB of archives.
  After this operation, 31.7 MB of additional disk space will be used.
  Get:1 http://httpredir.debian.org/debian sid/main amd64 python-setuptools all 
20.10.1-1 [203 kB]
  Get:2 http://httpredir.debian.org/debian sid/main amd64 python-all amd64 
2.7.11-1 [936 B]
  Get:3 http://httpredir.debian.org/debian sid/main amd64 libgfortran3 amd64 
6.1.1-3 [265 kB]
  Get:4 http://httpredir.debian.org/debian sid/main amd64 libblas-common amd64 
3.6.0-2 [13.5 kB]
  Get:5 http://httpredir.debian.org/debian sid/main amd64 libblas3 amd64 
3.6.0-2 [158 kB]
  Get:6 http://httpredir.debian.org/debian sid/main amd64 liblapack3 amd64 
3.6.0-2 [1949 kB]
  Get:7 http://httpredir.debian.org/debian sid/main amd64 python-numpy amd64 
1:1.11.0-1 [1770 kB]
  Get:8 http://httpredir.debian.org/debian sid/main amd64 python3-all amd64 
3.5.1-3 [936 B]
  Get:9 http://httpredir.debian.org/debian sid/main amd64 python3-numpy amd64 
1:1.11.0-1 [1769 kB]
  Get:10 http://httpredir.debian.org/debian sid/main amd64 
python3-pkg-resources all 20.10.1-1 [112 kB]
  Get:11 http://httpredir.debian.org/debian sid/main amd64 python3-setuptools 
all 20.10.1-1 [122 kB]
  Get:12 http://httpredir.debian.org/debian sid/main amd64 python-py all 
1.4.31-1 [81.8 kB]
  Get:13 http://httpredir.debian.org/debian sid/main amd64 python-pytest all 
2.9.1-1 [166 kB]
  Get:14 http://httpredir.debian.org/debian sid/main amd64 python3-py all 
1.4.31-1 [81.9 kB]
  Get:15 http://httpredir.debian.org/debian sid/main amd64 python3-pytest all 
2.9.1-1 [166 kB]
  Get:16 http://httpredir.debian.org/debian sid/main amd64 python-colorama all 
0.3.7-1 [25.7 kB]
  Get:17 http://httpredir.debian.org/debian sid/main amd64 python-click all 
6.6-1 [56.1 kB]
  Get:18 http://httpredir.debian.org/debian sid/main amd64 python3-colorama all 
0.3.7-1 [18.1 kB]
  Get:19 http://httpredir.debian.org/debian sid/main amd64 python3-click all 
6.6-1 [56.2 kB]
  Get:20 http://httpredir.debian.org/debian sid/main amd64 python-pyparsing all 
2.1.4+dfsg1-1 [70.4 kB]
  Get:21 http://httpredir.debian.org/debian sid/main amd64 python3-pyparsing 
all 2.1.4+dfsg1-1 [70.5 kB]
  Fetched 7155 kB in 0s (108 MB/s)
  Selecting previously unselected package python-setuptools.
  (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%

Bug#821259: libjpeg-progs: jpegtran -drop patch missing

[Bill Allombert]

On Sun, Apr 17, 2016 at 05:54:44AM +0200, Ram Kromberg wrote:
> Package: libjpeg-progs
> Version: 1:9b-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Bug #160390 either regressed or was erroneously closed to begin with.
> The -drop patch, as released in http://jpegclub.org/jpegtran/ under
> http://jpegclub.org/droppatch.v9b.tar.gz is not merged into the
> package.

Hello Ram,

Someone (not me) closed this bug by mistake. Sorry about that.

> It is quite trivial to patch and compile the package following the
> usual "sudo apt-get build-dep libjpeg-progs", "apt-get source
> libjpeg-progs" and simply overriding the three source files to apply
> the patch. "configure" and "make install" compile and deploy to
> /usr/local/ successfully. Once deployed, The -drop lossless merging
> functionality works as expected.

As I understand the issue is that the resulting image is not displayed
correctly when using the non-patched libjpeg.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#824797: unattended-upgrades: does not recover from (temporarily) broken packages (Cache has broken packages, exiting)

[Jens Thiele]

Package: unattended-upgrades
Version: 0.83.3.2+deb8u1
Severity: normal

Dear Maintainer,

Recently the samba packages in jessie had a problem with a file
conflict and the unattended upgrade failed:

>From the logs (sorry for the german):
2016-04-15 07:39:11,224 INFO Packages that will be upgraded: libsmbclient 
libwbclient0 python-samba samba samba-common samba-common-bin 
samba-dsdb-modules samba-libs
2016-04-15 07:39:11,227 INFO Dpkg-Protokoll wird nach 
»/var/log/unattended-upgrades/unattended-upgrades-dpkg.log« geschrieben
2016-04-15 07:40:19,320 ERROR Installation der Upgrades fehlgeschlagen!
2016-04-15 07:40:19,323 ERROR Fehlermeldung: »installArchives() failed«
2016-04-15 07:40:19,325 ERROR Dpkg gab einen Fehler zurück. Siehe 
»/var/log/unattended-upgrades/unattended-upgrades-dpkg.log« für Einzelheiten

Entpacken von samba-libs:armhf (2:4.2.10+dfsg-0+deb8u2) über 
(2:4.2.10+dfsg-0+deb8u1) ...
dpkg: Fehler beim Bearbeiten des Archivs 
/var/cache/apt/archives/samba-libs_2%3a4.2.10+dfsg-0+deb8u2_armhf.deb 
(--unpack):
Versuch, »/usr/lib/arm-linux-gnueabihf/samba/libsmbd-base.so.0« zu 
überschreiben, welches auch in Paket samba 2:4.2.10+dfsg-0+deb8u1 ist
dpkg-deb: Fehler: Unterprozess einfügen wurde durch Signal (Datenübergabe 
unterbrochen (broken pipe)) getötet

Afterwards unattended-upgrades stopped updating the system, reporting
"Cache has broken packages, exiting":

# LC_ALL=C unattended-upgrade -v --apt-debug -d
Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: ['origin=Debian,n=jessie', 'origin=karme.de,n=jessie']
ignoring ver '' with 
priority < 0
adjusting candidate version: ''
Cache has broken packages, exiting
Cache has broken packages, exiting

In the meantime the samba packages were fixed and I would expect
unattended-upgrade to install the new versions.
Unfortunately one has to run apt-get update && apt-get -f upgrade
first, to get it going again.

-- System Information:
Debian Release: 8.4
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages unattended-upgrades depends on:
ii  apt1.0.9.8.3
ii  apt-utils  1.0.9.8.3
ii  debconf [debconf-2.0]  1.5.56
ii  init-system-helpers1.22
ii  lsb-base   4.1+Debian13+nmu1
ii  lsb-release4.1+Debian13+nmu1
ii  python33.4.2-2
ii  python3-apt0.9.3.12
ii  ucf3.0030
ii  xz-utils   5.1.1alpha+20120614-2+b3

unattended-upgrades recommends no packages.

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20141216cvs-2
ii  exim4-daemon-light [mail-transport-agent]  4.84.2-1

-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed:
// Unattended-Upgrade::Origins-Pattern controls which packages are
// upgraded.
//
// Lines below have the format format is "keyword=value,...".  A
// package will be upgraded only if the values in its metadata match
// all the supplied keywords in a line.  (In other words, omitted
// keywords are wild cards.) The keywords originate from the Release
// file, but several aliases are accepted.  The accepted keywords are:
//   a,archive,suite (eg, "stable")
//   c,component (eg, "main", "crontrib", "non-free")
//   l,label (eg, "Debian", "Debian-Security")
//   o,origin(eg, "Debian", "Unofficial Multimedia Packages")
//   n,codename  (eg, "jessie", "jessie-updates")
// site  (eg, "http.debian.net")
// The available values on the system are printed by the command
// "apt-cache policy", and can be debugged by running
// "unattended-upgrades -d" and looking at the log file.
//
// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}Installed origin.
//   ${distro_codename}  Installed codename (eg, "jessie")
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
//  "o=Debian,n=jessie";
//  "o=Debian,n=jessie-updates";
//  "o=Debian,n=jessie-proposed-updates";
//  "o=Debian,n=jessie,l=Debian-Security";
// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
//  "o=Debian,a=stable";
//  "o=Debian,a=stable-updates";
//  "o=Debian,a=proposed-updates";
"origin=Debian,n=${distro_codename}";
"origin=karme.de,n=${distro_codename}";
};
// List of packages to not update (regexp are 

Bug#824800: hunspell-es: fails to upgrade from 'jessie' - trying to overwrite /usr/share/hunspell/es_ES.aff

[Andreas Beckmann]

Package: hunspell-es
Version: 1:5.1.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'stretch' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package hunspell-es.
  Preparing to unpack .../hunspell-es_1%3a5.1.3-1_all.deb ...
  Unpacking hunspell-es (1:5.1.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/hunspell-es_1%3a5.1.3-1_all.deb (--unpack):
   trying to overwrite '/usr/share/hunspell/es_ES.aff', which is also in 
package myspell-es 1.11-9
  Errors were encountered while processing:
   /var/cache/apt/archives/hunspell-es_1%3a5.1.3-1_all.deb


cheers,

Andreas


myspell-es=1.11-9_hunspell-es=1%5.1.3-1.log.gz
Description: application/gzip

Bug#824804: update-rc.d: may invoke insserv without -f flag when initscripts is installed but not configured

[Felipe Sateler]

X-Debbugs-Cc: andr...@fatal.se
Package: init-system-helpers
Version: 1.33
Severity: normal

Filing so that this is tracked somewhere.

update-rc.d currently has support for invoking insserv with the -f flag,
to allow initscripts-less installations. This should allow packages to drop
dependencies on the initscripts package. However, this does not work if the
dependency is dropped, because now apt/dpkg can choose to configure the
package before it configures initscripts. This leads to the situation that
/etc/init.d/mountkernfs.sh exists (and thus invoke-rc.d does not pass -f flag),
but the links in /etc/rc?.d/S??mountkernfs.sh are not created yet, and then
insserv fails.

A practical example of this happened when util-linux dropped the initscripts
dependency on #823665.

Possible solutions:

1. Unconditionally pass -f to insserv. This has some appeal to me as I don't
   think packaging bugs should in general abort installations, but I can see
   the argument for preserving the check.
2. Extend the check to the links (ie, check if
   `glob /etc/rc?.d/S??mountkernfs.sh` is not empty.
3. Consult the dpkg database via dpkg-query to determine if initscripts has been
   configured
4. Have dpkg/apt support ordering without dependencies (not likely to
   happen soon).


I think (2) is the easiest and fastest way out of this problem, but
(4) would be the real fix.

-- 

Saludos,
Felipe Sateler

Bug#812948: libbson-doc: contains manpages with generic names: index(3), installing(3), errors(3)

[Andreas Beckmann]

Followup-For: Bug #812948
Control: retitle -1 libbson-doc: contains manpages with generic names: 
index(3), installing(3), errors(3)

Another very generic name is errors.3.gz, clashing with libcoin80-doc
from jessie.

Several packages are shipping $PKG_errors.3.gz to avoid such
collisions.


Andreas

Bug#824802: debian-edu-config: fails to upgrade from 'jessie' - trying to overwrite /etc/default/ldap2zone

[Wolfgang Schweer]

On Thu, May 19, 2016 at 11:43:21PM +0200, Andreas Beckmann wrote:
> >From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package debian-edu-config.
>   Preparing to unpack .../debian-edu-config_1.901_all.deb ...
>   Unpacking debian-edu-config (1.901) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/debian-edu-config_1.901_all.deb (--unpack):
>trying to overwrite '/etc/default/ldap2zone', which is also in package 
> ldap2zone 0.2-5

Thanks for your work, Andreas.

ldap2zone 0.2-8 dropped shipping /etc/default/ldap2zone. Debian Edu 
Stretch needs this file to configure the DNS service and now has to 
provide it. I guess a solution will be possible.

Wolfgang


signature.asc
Description: Digital signature

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

[Bjørn Mork]

Package: smartmontools
Version: 6.4+svn4214-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Looks like this was left over when removing the update-smart-drivedb
script:

 bjorn@nemi:~$  dpkg -L smartmontools|grep update
 /usr/share/man/man8/update-smart-drivedb.8.gz


Bjørn

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

Kernel: Linux 4.6.0+ (SMP w/2 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: sysvinit (via /sbin/init)

Versions of packages smartmontools depends on:
ii  debianutils  4.4+b1
ii  init-system-helpers  1.33
ii  libc62.22-9
ii  libcap-ng0   0.7.4-2
ii  libgcc1  1:6.1.1-3
ii  libselinux1  2.3-2
ii  libstdc++6   6.1.1-3
ii  lsb-base 4.1+Debian13+nmu1

Versions of packages smartmontools recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20141216cvs-2

Versions of packages smartmontools suggests:
pn  gsmartcontrol   
pn  smart-notifier  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlc+I88ACgkQ10rqkowbIsm3cwCfS6Uh14dLM3/Aht695SmfprEv
uEwAnA4WU+Pbyg5QbCvKkL1h1gOt/wiP
=G+re
-END PGP SIGNATURE-

Bug#824801: option to force native build

[Eduard Bloch]

Package: git-buildpackage
Version: 0.7.4
Severity: wishlist

Hi,

I remember having reported a similar issue a couple of years ago and
back then it was closed with a useless coment. This time I stumbled upon
it again and still cannot find a SANE solution. With SANE, I mean
user-friendly. I, as user, wish to have an option to make a test build.
Without having an upstream tarball!
(that is the key point. The debian branch is a fork of the upstream
branch after all, it should just work).

WRT dpkg-buildpackage itself, I can easily force it to act like on a
native package and just build me my binary packages. But with gbp, this
simple task becomes PITA: it wants me to have some upstream reference or
else... (see below).

Sorry, there really should be an easy and user-friendly way to let me
just build it, no matter whether there is an upstream tag or not. I
did RTFM and nothing ringed a bell there. If there is an easy way,
please document it properly.



dh_clean
rm -rf debian/apt-cacher-ng.service debian/apt-cacher-ng.tmpfile 
dbgen/dbgenerator.* dbgen/dbupdate
debconf-updatepo
...
gbp:info: Orig tarball 'apt-cacher-ng_0.9.3.orig.tar.xz' not found at 
'../tarballs/'
gbp:error: Pristine-tar couldn't checkout "apt-cacher-ng_0.9.3.orig.tar.xz": 
fatal: Path 'apt-cacher-ng_0.9.3.orig.tar.xz.delta' does not exist in 
'refs/heads/pristine-tar'
pristine-tar: git show 
refs/heads/pristine-tar:apt-cacher-ng_0.9.3.orig.tar.xz.delta failed

Regards,
Eduard.

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts2.16.4
ii  git   1:2.8.1-1
ii  man-db2.7.5-1
ii  python-dateutil   2.4.2-1
ii  python-pkg-resources  20.10.1-1
ii  python-six1.10.0-3
pn  python:any

Versions of packages git-buildpackage recommends:
ii  cowbuilder   0.79
ii  pbuilder 0.224
ii  pristine-tar 1.33
ii  python-requests  2.9.1-3

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-4
ii  sudo   1.8.15-1.1
ii  unzip  6.0-20

-- no debconf information

-- 
 Verdammte Toffifee-Kacke. Die untere Schale aus 'ner 48er-Packung
rauswuehlen ist scheisse.
 towo: ich enthalte mich mal eines kommentars
 Mh?
 Toffifee-Dev, oder was?

Bug#824802: debian-edu-config: fails to upgrade from 'jessie' - trying to overwrite /etc/default/ldap2zone

[Andreas Beckmann]

Package: debian-edu-config
Version: 1.901
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package debian-edu-config.
  Preparing to unpack .../debian-edu-config_1.901_all.deb ...
  Unpacking debian-edu-config (1.901) ...
  dpkg: error processing archive 
/var/cache/apt/archives/debian-edu-config_1.901_all.deb (--unpack):
   trying to overwrite '/etc/default/ldap2zone', which is also in package 
ldap2zone 0.2-5


cheers,

Andreas


ldap2zone=0.2-5_debian-edu-config=1.901.log.gz
Description: application/gzip

Bug#804623: osptoolkit: SSLv3 method

[Sebastian Andrzej Siewior]

On 2015-11-14 14:10:27 [+0100], Kurt Roeckx wrote:
> You should change the call from SSLv3_client_method() to
> SSLv23_client_method().
> 
> The SSLv3_* call only talks SSLv3 while the SSLv23_* call is the
> only one supporting multiple protocol version.
> 
> I suggest you also get that fixed in the stable branches.

Dear maintainer, do you plan to update the package? I see that upstream
is currently at 4.11.1 and is using TLSv1 version. This works while
SSLv23 is the prefered method.

However, in stable (and unstable) you have the SSLv3 version and since
openssl 1.0.1j-1 v3 has been disabled which means you package stopped
working with SSL since then.

> Kurt

Sebastian

Bug#824802: debian-edu-config: fails to upgrade from 'jessie' - trying to overwrite /etc/default/ldap2zone

[Holger Levsen]

control: tags -1 + pending

On Fri, May 20, 2016 at 12:19:13AM +0200, Andreas Beckmann wrote:
> On 2016-05-20 00:15, Wolfgang Schweer wrote:
> > ldap2zone 0.2-8 dropped shipping /etc/default/ldap2zone. Debian Edu 
> > Stretch needs this file to configure the DNS service and now has to 
> > provide it. I guess a solution will be possible.
> Breaks+Replaces: ldap2zone (<< 0.2-8~)
 
Thanks Andreas & Wolfgang, fixed in git!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#824805: ITP: r-bioc-go.db -- annotation maps describing the entire Gene Ontology

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-bioc-go.db
  Version : 3.3.0
  Upstream Author : Marc Carlson
* URL : 
http://bioconductor.org/packages/release/data/annotation/html/GO.db.html
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : annotation maps describing the entire Gene Ontology
 This package is part of BioConductor and provides a set of annotation
 maps describing the entire Gene Ontology assembled using data from GO.


Remark: This package is needed for some unit tests of BioConductor packages.
It will be maintained by the Debian Med team at
svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-go.db/trunk/

Bug#824765: apt-listbugs: segfault on stretch

[Francesco Poli]

Control: severity -1 important
Control: tags -1 + moreinfo


On Thu, 19 May 2016 16:13:59 +0200 Nicolas Braud-Santoni wrote:

> Package: apt-listbugs
> Version: 0.1.17
> Severity: serious
> 
> Dear Maintainer,
> 
> I encountered an apt-listbugs segfault when it was run
>   as part of an apt invocation.

Hello Nicolas,
thanks for your bug report.

Please do not inflate the severity, though: I use apt-listbugs/0.1.17
on a number of machines, and I have never experienced any segfault.

> 
> Please find enclosed a log of what was displayed on the terminal,
>   along with the resulting coredump.

Thanks for all this information, I will soon try to understand what's
going on.

In the meanwhile, could you please do the following test?

Please invoke the interactive Ruby interpreter and issue the following
commands:

  $ irb
  irb(main):001:0> require 'unicode'
  => true
  irb(main):002:0> Unicode.width("that is")
  => 7
  irb(main):003:0> Unicode.width("cioè")
  => 4
  irb(main):004:0> exit


Please let me know, thanks.


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


pgpNmJdSG0Kxa.pgp
Description: PGP signature

Bug#824211: swh-plugins: Package new upstream version

[Javier Serrano Polo]

El dj 19 de 05 de 2016 a les 19:41 +0200, Jaromír Mikeš va escriure:
> Yes, that would be definitely possible, but I would to to know where
> next releases will be published to tune watch file accordingly.

Nine years have passed without a release. I think a watch file is
obsolete. I would rely on "New upstream release" bugs from users.


smime.p7s
Description: S/MIME cryptographic signature

Bug#824796: hunspell-lt: should break older myspell-lt (not conflict against it)

[Jonas Smedegaard]

Package: hunspell-lt
Version: 1:5.1.3-1
Severity: serious
Tags: l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

myspell-lt is now (since 1.2.1-7 and possibly 1.2.1-6 too) a transitional
package depending on hunspell-lt. Consequently hunspell-lt need to change
from conflicting against myspell-lt to breaking older versions.

Severity set to serious because currently it is not possible to install
these packages: icedove-l10n-lt firefox-l10n-lt firefox-esr-l10n-lt 
iceowl-l10n-lt.

Arguably all those packages should instead be fixed, but fixing one
package is likely faster to do at first.  Or reassign if you disagree...

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPib4AAoJECx8MUbBoAEh+wUP/3KVuK/13Xqkn0jWyeCbY6NF
3vht+vpgAhGT0Vp1DBTM16k0mHDwd+T0v7GAb2Pv1rvsK0ZJ7tXZ3WaObRWSfR35
o+Otu1/rCeqonbxb3MdenHc1OJ4bjUfZ4ZqQ+XYAHJLp4ywTa2EBJ84L2xMIJUXQ
BDP26dKjW4SHWB7oWa29oGRA9hJBITYG2pF+aYKHDejoqGb/CqpWEMxPHrN7UJzB
Hi2hFfJ6Yyd6JNabHOIZovgroQqL961JRxJRj3xG6UNpfkckgBzPeLSRZp+Yn/mD
x7/dVFthXKvzMPwDUqUMCyCMoLbLpZ7i+deVGqDGxiQ2y4HbbPfHDHsVofHfzOs4
gtRcEvPAYrX5kn5APK326hKckKYTr+1qNeHKhFs78uLYJIC3ylXiOb4JZmf14BDx
YRGkLXTuUXSMFseZUfuN007picOUfmfx4k5mpwAWL9XIDrons3JezRrpG0Z2xHlI
8kWQ+qYrwWcTgzGno7YFCR1q2Rn3tYcPUTVYwPlqdr7a2TOfpUkNR5Yjn19+T/Vs
mOYksh5zWQP5IXZi+k0ZkBjjkkZrRdLN6phPcxQlLXU8Uypu63i6g3/SKi1XUisP
v+zvPvaL/UujzCtTVKGdm/lHbT1fgYI0IxLp+HmNcwPenszOwv4i/5ECEoI6X5QD
o0p0v1jmYMOb26Kokx0d
=l1jQ
-END PGP SIGNATURE-

Bug#824796: hunspell-lt: should break older myspell-lt (not conflict against it)

[Mattia Rizzolo]

control: tag -1 sid

On Thu, May 19, 2016 at 10:50:04PM +0200, Jonas Smedegaard wrote:
> myspell-lt is now (since 1.2.1-7 and possibly 1.2.1-6 too) a transitional
> package depending on hunspell-lt. Consequently hunspell-lt need to change
> from conflicting against myspell-lt to breaking older versions.

Actually, I had already done that when I uploaded myspell-lt as
transitional, but I was waiting on some other changes for lo-dicts.
https://anonscm.debian.org/git/pkg-openoffice/libreoffice-dictionaries.git/commit/?id=fd810ac171afc94a2ae66d37e99f4998526fc6b7

> Severity set to serious because currently it is not possible to install
> these packages: icedove-l10n-lt firefox-l10n-lt firefox-esr-l10n-lt 
> iceowl-l10n-lt.

yeah, guess serious is fine... It's gonna be closed soon enough :P
That said, I expect src:ispell-lt (which builds myspell-lt) to not
migrate to testing until the fixed lo-dicts without the conflict will
migrate too, so this situation should be restricted in unstable no
matter what.

> Arguably all those packages should instead be fixed, but fixing one
> package is likely faster to do at first.  Or reassign if you disagree...

yeah, well... I'm not planning on removing myspell-lt before stretch
anyway, so I'm not going to file bugs right now, but feel free to, if
you want.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#824803: trying to overwrite '/usr/share/texlive/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-de-1901.tex', which is also in package texlive-base 2015.20160320-1

[Julian Andres Klode]

On Thu, May 19, 2016 at 11:55:08PM +0200, Julian Andres Klode wrote:
> Package: texlive-lang-german
> Version: 2015.20160320-1
> Severity: serious

You cannot really conflict with texlive-lang-german from texlive-base.
You need to Conflict with the old base from lang-german.

But Maybe you can have both, I'm not sure (like Conflict from base,
and Breaks + Replaces from lang-german).

The current way definitely does not work, because it tells us to upgrade
lang-german to 2016 before upgrading base from 2015 to 2016 which
fails because base 2015 and german 2016 contain the same file.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#824800: hunspell-es: fails to upgrade from 'jessie' - trying to overwrite /usr/share/hunspell/es_ES.aff

[Andreas Beckmann]

On 2016-05-19 23:52, Mattia Rizzolo wrote:
> The question is: shouldn't the update have tried to update both?  Do we
> actually try support partial upgrades?

Even if a "regular" upgrade would upgrade both packages, there is no
guarantee on ordering. So I'm trying to exercise worst-case upgrade
paths that are valid (i.e. not violating package relationships).

I'm not even sure that this falls under "partial" upgrade. If myspell-es
would get removed from testing (it has no rdepends), this bug (in
huspell-es) would get more exposure.


Andreas

Bug#824807: RM: xfce4-mixer/experimental -- RoQA; depends on gstreamer 0.10

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

xfce4-mixer was already removed from unstable (804261), the same applies
to experimental.


Andreas

Bug#824810: jq: Package description "lies" about runtime dependencies

[Olaf Meeuwissen]

Package: jq
Version: 1.5+dfsg-1
Severity: minor

Despite the package description claiming jq has zero runtime
dependencies, it Depends: on libonig2.

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

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

Versions of packages jq depends on:
ii  libc6 2.22-7
ii  libonig2  5.9.6-1

jq recommends no packages.

jq suggests no packages.

-- no debconf information

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- EPSON AVASYS CORPORATION
   Free Software Foundation Associate Member since 2004-01-27
Support Free Software  https://my.fsf.org/donate
Join the Free Software Foundationhttps://my.fsf.org/join

Bug#824811: firmware-realtek: rtl8192ce doesn't transfer data

[koczis]

Package: firmware-realtek
Version: 20160110-1~bpo8+1 & 0.43
Severity: important

Dear Maintainer,

   * What led up to the situation?
Trying to connect to my WiFi LAN and access Internet.

   * What exactly did you do (or not do) that was effective (or ineffective)?
Effective: network scan, connection itself
Ineffective: data transfer (router ping, Internet access)

Additionally:
- please see "Networking> No Internet through WiFi" SolydX board
- assume my router setup is OK - works through eth0
- notice rtl8192cu is working with my "Asus USB N-10 Nano" dongle

- "lspci -nn" line for my PCI WiFi device:
02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8192CE 
PCIe Wireless Network Adapter [10ec:8178] (rev 01)

- "lsusb" line for my "Asus USB N-10 Nano"
Bus 001 Device 005: ID 0b05:17ba ASUSTek Computer, Inc.


-- System Information:
Distributor ID: SolydXK
Description:SolydX 8 64-bit
Release:8
Codename:   solydxk
Architecture: x86_64

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.120+deb8u1

-- no debconf information

Bug#824798: coreutils: ls still adding single quotes (in error messages)

[Ken McDonell]

Package: coreutils
Version: 8.25-2
Severity: normal

Dear Maintainer,

This is related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810295
that has (thankfully) been fixed by reverting the coreutils quoting change.

This is fixed ...
kenj@vm07:/tmp$ touch foo 'foo bar'
kenj@vm07:/tmp$ ls foo*
foo  foo bar

But this remains broken (with respect to 30+ years of history)
kenj@vm07:/tmp$ ls foo-bar
ls: cannot access 'foo-bar': No such file or directory

The quotes around the filename just should not be there.

This is a big deal because it breaks a very large number of QA tests
that we have that compare actual versus expected output for PCP
(www.pcp.io) ... and many of these tests use sh and ls and some
expect files to be not found ... these tests fail on Debian stretch
while passing on hundreds of other platforms.

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

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

Versions of packages coreutils depends on:
ii  libacl12.2.52-3
ii  libattr1   1:2.4.47-2
ii  libc6  2.22-7
ii  libselinux12.5-2
ii  multiarch-support  2.22-7

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#824802: debian-edu-config: fails to upgrade from 'jessie' - trying to overwrite /etc/default/ldap2zone

[Andreas Beckmann]

On 2016-05-20 00:15, Wolfgang Schweer wrote:
> ldap2zone 0.2-8 dropped shipping /etc/default/ldap2zone. Debian Edu 
> Stretch needs this file to configure the DNS service and now has to 
> provide it. I guess a solution will be possible.

Breaks+Replaces: ldap2zone (<< 0.2-8~)


Andreas

Bug#819096: Frequent hangs/crashes when changing network configuration

[Ben Hutchings]

On Tue, 2016-05-17 at 18:55 +0200, Michael Biebl wrote:
> Control: severity -1 important
> 
> Hi Ben
> 
> On Fri, 25 Mar 2016 08:50:04 + Simon McVittie  wrote:
> > 
> > On Wed, 23 Mar 2016 at 15:48:33 +, Ben Hutchings wrote:
> > > 
> > > If I change the network configuration through the right hand menu in
> > > GNOME Shell it may hang for 10 seconds or (apparently) indefinitely.
> > Do you get the same thing in 3.18.1-1 from testing? If you do, please
> > mark this bug as found there so it doesn't have to block migration.
> > 
> > If you can provide some more specific steps-to-reproduce (something like
> > "be on wifi, switch to mobile broadband, switch back to wifi"), or a
> > rough idea of what proportion of the time those steps will trigger this
> > bug, that would probably also be useful information.
> Since we didn't have any further feedback and I can't seem to reproduce
> the issue, I'm downgrading the severity (for now).
> Otherwise this bug blocks gnome-shell and other important updates to
> enter testing.

Sorry about that, I haven't yet found a reliable reproducer and I
should have let you know sooner.  I agree this should be downgraded.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.

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

Bug#824766: armory: New home for armory and new upstream release

[Joseph Bisch]

On Thu, May 19, 2016 at 09:33:17AM -0600, Joseph Bisch wrote:
> On Thu, May 19, 2016 at 04:15:02PM +0200, Diederik de Haas wrote:
> > As can be read in the links from this issue
> > https://github.com/etotheipi/BitcoinArmory/issues/325 Armory
> > Technologies has stopped working on armory, at least for the time being.
> > As can be read in the linked threads, there is now a fork which seemed
> > to be (somewhat) official, namely
> > https://github.com/goatpig/BitcoinArmory and there have been several
> > releases there, the latest being 0.94.1.
> > 
> > Maybe it's a good idea to switch the Debian package to the fork?
> 
> Yes, I would say that Goatpig's fork is the most official version of
> Armory in development currently. He was the defacto maintainer of the
> open source version of Armory at Armory Technologies up until the
> company stopped development.
> 
> I won't be able to get to this myself before the weekend at the
> earliest (just moved and going to be starting a new job). Patches to
> package 0.94.1 are welcome from anyone. Just be sure to base the
> packaging off of the pkg-bitcoin repo[0].

I actually got to take a look at this. I decided not to package new
versions of Armory until the git tags are signed to verify the integrity
of the source code (e.g. so GitHub or someone with access to GitHub's
servers cannot modify the code). I have filed a bug[0] upstream asking
for Goatpig to sign tags. I hope to be able to package 0.94.1 and future
versions of Armory soon, but without signed tags, I think it would be
irresponsible of me to package financial software. I just filed the bug
upstream, so it might be a while before I hear back from Goatpig.

[0] - https://github.com/goatpig/BitcoinArmory/issues/40

Joseph

Bug#824800: hunspell-es: fails to upgrade from 'jessie' - trying to overwrite /usr/share/hunspell/es_ES.aff

[Mattia Rizzolo]

On Thu, May 19, 2016 at 11:35:47PM +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.
> It installed fine in 'jessie', then the upgrade to 'stretch' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 
> >From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package hunspell-es.
>   Preparing to unpack .../hunspell-es_1%3a5.1.3-1_all.deb ...
>   Unpacking hunspell-es (1:5.1.3-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/hunspell-es_1%3a5.1.3-1_all.deb (--unpack):
>trying to overwrite '/usr/share/hunspell/es_ES.aff', which is also in 
> package myspell-es 1.11-9

Guess I can add something here too.  That would be a conflicts, though.
myspell-es in stretch has a "Conflicts: hunspell-es" that clearly
prevents this situation in stretch.

The question is: shouldn't the update have tried to update both?  Do we
actually try support partial upgrades?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#824794: python-snuggs: FTBFS: ../../../test_snuggs.py:154: AssertionError

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Chris,

Thanks for reporting this issue.

It seems the recent update to NumPy 1.11.0 has changed a couple of
exceptions. I've added a patch to support the new exceptions in the
tests in question and forwarded it upstream.

The new python-snuggs revision is on its way to unstable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#823775: installation failure, file overwritting

[Hideki Yamane]

On Sun, 8 May 2016 22:30:51 +0200
Eduard Bloch  wrote:
> Preparing to unpack .../ubuntu-archive-keyring_2012.05.19-5_all.deb ...
> Unpacking ubuntu-archive-keyring (2012.05.19-5) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/ubuntu-archive-keyring_2012.05.19-5_all.deb 
> (--unpack):
>  trying to overwrite '/usr/share/keyrings/ubuntu-archive-keyring.gpg', which 
> is also in package ubuntu-keyring 2010.11.09

 ubuntu-keyring is not in Debian repository.
 But okay to add it to Conflicts: .

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Bug#824793: mount.8: refers to package nfs-utils

[Greg Wooledge]

Package: mount
Version: 2.25.2-6
Severity: normal

In the "Mount options for nfs and nfs4" section, the mount(8) man page
says "nfs-utils package must be installed".  It should say nfs-common
instead.

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

Kernel: Linux 3.16.0-4-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 mount depends on:
ii  libc6  2.19-18+deb8u4
ii  libmount1  2.25.2-6
ii  libselinux12.3-2
ii  libsmartcols1  2.25.2-6

mount recommends no packages.

Versions of packages mount suggests:
ii  nfs-common  1:1.2.8-9

-- debconf-show failed

Bug#824707: systemd: I get fsck's every other boot: due to systemd-timesyncd not updating hwclock?

[Manuel Bilderbeek]

Hi,

On 19-05-16 23:04, Michael Biebl wrote:

Looks like I need to have systemd-timesync run *before* systemd-fsck!?


If your hwclock drifts that much, maybe
/etc/e2fsck.conf:
 [options]
 broken_system_clock=1

(as referenced in my earlier reply) is an option.
Can you try that?


Sure, but won't that effectively disable fsck'ing based on 'time since 
last check'?


Also, is it normal that that config file doesn't exist yet?

--
Kind regards,

Manuel

Bug#824706: RM: pepperflashplugin-nonfree [i386] -- RoQA; ANAIS

[Gianfranco Costamagna]

Hi ftpmasters

>you could please remove i386 from unstable.

>I'm not aware of any reverse dependencies.


yes please.

Gianfranco

Bug#824723: rhythmbox: after one minute skips the song

[Lawrence Nuyts]

Package: rhythmbox
Version: 3.1-1
Severity: normal

Dear Maintainer,

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

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

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



-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages rhythmbox depends on:
ii  dbus1.8.20-0+deb8u1
ii  gnome-icon-theme3.12.0-1
ii  gstreamer1.0-plugins-base   1.4.4-2
ii  gstreamer1.0-plugins-good   1.4.4-2
ii  gstreamer1.0-x  1.4.4-2
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18+deb8u4
ii  libcairo-gobject2   1.14.0-2.1+deb8u1
ii  libcairo2   1.14.0-2.1+deb8u1
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u4
ii  libgirepository-1.0-1   1.42.0-2.2
ii  libglib2.0-02.42.1-1+b1
ii  libgstreamer-plugins-base1.0-0  1.4.4-2
ii  libgstreamer1.0-0   1.4.4-2
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libgudev-1.0-0  215-17+deb8u4
ii  libjavascriptcoregtk-3.0-0  2.4.9-1~deb8u1
ii  libjson-glib-1.0-0  1.0.2-1
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libpeas-1.0-0   1.12.1-2
ii  librhythmbox-core8  3.1-1
ii  libsoup2.4-12.48.0-1
ii  libtdb1 1.3.6-0+deb8u1
ii  libtotem-plparser18 3.10.3-1
ii  libwebkitgtk-3.0-0  2.4.9-1~deb8u1
ii  libx11-62:1.6.2-3
ii  libxml2 2.9.1+dfsg1-5+deb8u1
ii  media-player-info   22-2
ii  rhythmbox-data  3.1-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages rhythmbox recommends:
ii  avahi-daemon0.6.31-5
ii  cinnamon [notification-daemon]  2.2.16-5
ii  gstreamer1.0-plugins-ugly   1.4.4-2+b1
ii  gstreamer1.0-pulseaudio 1.4.4-2
ii  gvfs-backends   1.22.2-1
ii  rhythmbox-plugins   3.1-1
ii  yelp3.14.1-1

Versions of packages rhythmbox suggests:
pn  gnome-codec-install  
ii  gnome-control-center 1:3.14.2-3
ii  gstreamer1.0-plugins-bad 1.4.4-2.1+b1
ii  rhythmbox-plugin-cdrecorder  3.1-1

-- no debconf information

Bug#800654: patch ready?

[Holger Levsen]

Hi Wolfgang,

I'm slightly surprised to "only" find a patch in the BTS (hurra
actually!), but not in git. Was that because you weren't that confident
in commiting to git master at that time or do you think there are any
issues with that patch?

Or, to rephrase in a more relevant way: is the patch from #800654 ready?
If so, could you please commit it to the master branch of d-e-config?!

Thanks!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#821532: mlmmj-php-web, mlmmj-php-web-admin: PHP 7.0 Transition

[Ondřej Surý]

The code is postinst is correct. This should switch to prefork when
a2query -M returns anything else then prefork or itk:

mpm=$(a2query -M)
case "$(a2query -M)" in
prefork|itk) return 0;;
*) if apache2_switch_mpm prefork; then return 0; fi;;
esac

Could you check your apt.log for:

ERROR: $PHP_MODULE module already enabled, not enabling PHP
@PHP_VERSION@

or

ERROR: Could not switch to prefork MPM, not enabling PHP @PHP_VERSION@

?

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Potřeby pro pečení chleba
všeho druhu

On Thu, May 19, 2016, at 04:47, Chris Knadle wrote:
> I have a patch to switch mlmmj to use PHP 7.0 instead of PHP 5 (that
> change
> is trivial -- literally php5 -> php), but I'm running into a snag testing
> the resulting binary packages: trying to load Apache2 with PHP 7.0 fails
> to
> start with the error message:
> 
>   "Apache is running as threaded MPM, but your PHP module is not compiled
>to be threadsafe.  You need to recompile PHP."
> 
> and looking at the README.Debian.gz for libapache2-mod-php7.0, the
> document
> only discusses PHP 5.  :-/  I'm having a look at the php7.0 source
> package... libapache2-mod-php.postinst.extra seems to test for mpm but
> I'm
> suspecting that this needs tweaking for how Apache2 is currently packaged
> in
> Sid.  ('a2query -M' returns 'event' which is not a case that's being
> looked
> for, and Apache2 isn't split into mpm/prefork packages anymore.)
> 
>-- Chris
> 
> -- 
> Chris Knadle
> chris.kna...@coredump.us
> 
> 
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

Bug#824657: libpam-abl: Fatal system lockout with libpam-abl installed

[Alex Mestiashvili]

Thank you for the report! the upload of the fixed version is in progress.

Best regards,
Alex

Bug#824724: ninja-build: Please package the new upstream release (1.7.1)

[Sylvestre Ledru]

Package: ninja-build
Version: 1.6.0-1
Severity: wishlist

Hello,

The title says all. It would be great to have ninja 1.7.1 in Debian!

Thanks,
Sylvestre

Bug#824683: [PKG-Openstack-devel] Bug#824683: keystone: CVE-2016-4911: Incorrect Audit IDs in Keystone Fernet Tokens can result in revocation bypass

[Thomas Goirand]

On 05/19/2016 06:18 AM, Salvatore Bonaccorso wrote:
> Hi Thomas,
> 
> On Thu, May 19, 2016 at 12:21:28AM +0200, Thomas Goirand wrote:
>> On 05/18/2016 06:55 PM, Salvatore Bonaccorso wrote:
>>> Source: keystone
>>> Version: 2:9.0.0-1
>>> Severity: grave
>>> Tags: security patch upstream
>>>
>>> Hi,
>>>
>>> the following vulnerability was published for keystone.
>>>
>>> CVE-2016-4911[0]:
>>> Incorrect Audit IDs in Keystone Fernet Tokens can result in revocation 
>>> bypass
>>>
>>> If you fix the vulnerability please also make sure to include the
>>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>>>
>>> For further information see:
>>>
>>> [0] https://security-tracker.debian.org/tracker/CVE-2016-4911
>>> [1] https://bugs.launchpad.net/keystone/+bug/1577558
>>>
>>> Regards,
>>> Salvatore
>>
>> Hi Salvatore,
>>
>> It is my view that this bug doesn't deserve Severity: grave, as Fernet
>> Tokens aren't the default in Keystone (it defaults to UUID tokens, and
>> Fernet Tokens are a very new thing).
>>
>> Your thoughts?
> 
> Thanks for your feedback. Wanted to be rather safe than sorry.
> 
>> Anyway, Keystone in Stable isn't affected (it doesn't have the feature),
>> and never the less, I'll update the package in Sid/Testing.
> 
> I can confirm that it should only affect 9.0.0, so sid. Could you
> upload the isolated fix? I will then update the tracker information
> once it enters the archive.
> 
> Thanks!
> 
> Regards,
> Salvatore

Hi Salvatore,

I have uploaded Keystone 9.0.0-2 with the upstream patch. Upstream also
confirmed that previous version, currently in jessie-backports, isn't
affected by this issue. So, once Keystone migrates to Testing, we're
good to go.

Cheers,

Thomas Goirand (zigo)




signature.asc
Description: OpenPGP digital signature

Bug#824766: armory: New home for armory and new upstream release

[Diederik de Haas]

Package: armory
Version: 0.92.3-1+b2
Severity: normal

As can be read in the links from this issue
https://github.com/etotheipi/BitcoinArmory/issues/325 Armory
Technologies has stopped working on armory, at least for the time being.
As can be read in the linked threads, there is now a fork which seemed
to be (somewhat) official, namely
https://github.com/goatpig/BitcoinArmory and there have been several
releases there, the latest being 0.94.1.

Maybe it's a good idea to switch the Debian package to the fork?

Cheers,
  Diederik


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

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 armory depends on:
ii  bittornado 0.3.18-10.2
ii  libc6  2.22-9
ii  libcrypto++6   5.6.3-6
ii  libgcc11:6.1.1-3
ii  libleveldb1v5  1.18-5
ii  libstdc++6 6.1.1-3
ii  python-psutil  4.1.0-1
ii  python-qt4 4.11.4+dfsg-1+b3
ii  python-qt4reactor  1.0-1
ii  python-twisted 16.1.1-1
ii  python2.7  2.7.11-9
pn  python:any 
ii  xdg-utils  1.1.1-1

Versions of packages armory recommends:
ii  bitcoind  0.11.2-1

armory suggests no packages.

-- no debconf information

Bug#824657: libpam-abl: Fatal system lockout with libpam-abl installed

[Sunil Mohan Adapa]

On 05/19/2016 02:07 PM, Alex Mestiashvili wrote:
> Thank you for the report! the upload of the fixed version is in progress.
> 

Thank you for a speedy resolution.

-- 
Sunil




signature.asc
Description: OpenPGP digital signature

Bug#824211: swh-plugins: Package new upstream version

[Jonas Smedegaard]

Quoting Jaromír Mikeš (2016-05-19 15:45:28)
> 2016-05-13 20:40 GMT+02:00 Javier Serrano Polo :
> > Package: swh-plugins
> > Version: 0.4.15+1-8
> > Severity: wishlist
> >
> > The upstream project is maintained at https://github.com/swh/ladspa . It
> > includes a vocoder plug-in that is shipped with the lmms package. To
> > reuse this plug-in, lmms could put it under /usr/lib/ladspa, but that
> > would conflict with a new version of swh-plugins. Could you tell if you
> > will package a new upstream version, which is preferable, or if lmms can
> > publish this plug-in in the meantime?
> 
> I don't see any release here yet :(
> https://github.com/swh/ladspa/releases

Then perhaps consider release a snapshot of upstream development - to me 
that feels more sensible (without having looked closer at the code) than 
us indirectly doing the same via a snapshot created by another upstream 
(the lmms project).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#822870: libiscsi2: Please update to new upstream release 1.15.0

[Michael Tokarev]

28.04.2016 18:31, David Mohr wrote:
> Package: libiscsi2
> Version: 1.12.0-2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> 1.15.0 was released a couple of months ago [1], and it would be nice to
> get it added to Debian. In particular it's used for qemu's iSCSI support
> which needs that version for proper handling of timeouts.
> 
> Overall there don't seem to be any packaging changes necessary, although
> I am not sure how the soname changes should be evaluated.

The problem isn't the packaging itself, the problem is...

> I can share my updated packaging but the changes are so minimal that I doubt 
> it's worth the effort (I just removed the patches and updated the package 
> name to reflect the new so version).

.. here: about every release, this lib breaks ABI and needs
new soname.  This requires recompilation of all executables
linked with it.

I'll try to push it to debian this time once again, but
this becomes rather painful.

Thanks,

/mjt

Bug#823521: RFS: irstlm/6.00.05-1 -- IRST Language Modeling Toolkit

[Giulio Paci]

Hi Balint and all,

On 16/05/2016 16:50, Bálint Réczey wrote:
> Hi Giulio,
> 
> 2016-05-08 14:32 GMT+02:00 Giulio Paci :
>> Hi Balint and all,
>>
>> Il 08/mag/2016 14:15, "Bálint Réczey"  ha scritto:
>>>
>>> Control: owner -1 bal...@balintreczey.hu
>>>
>>> 2016-05-06 23:44 GMT+02:00 Gianfranco Costamagna
>>> :
 Hi Balint, so I presume you want to set yourself as owner of this bug,
 right?
>>>
>>> Sure, and I'm also about to upload the package in the current state.
>>> Feel free to continue the discussion about bringing irstlm under Debian
>>> Science
>>> in this bug or or on the team's mailing list.
>>
>> I currently do not need this version (I am using the old one in production,
>> so I think we can wait a few days before uploading this package and upload
>> it under Debian science).
>>
>> If I understand correctly, given its current state, the only things that I
>> need to do are:
>> 1) ensure that I am part of Debian Science team;
>> 2) change maintainer and uploaders;
>> 3) move git repository under Debian Science and update Vcs fields in the
>> package;
>> 4) update changelog.
>>
>> Is that all?
> 
> I think so.
> 
>>
>> In order to move the repository, is it fine if I setup a new repository in
>> Debian Science, change my remote url and push there? Or will I cause
>> troubles  acting in this way (eg.: too many commits emails)?
>> Do you have a better migration workflow?
> 
> I think pushing is OK.

As you probably noticed I moved the package under Debian Science and Mattia 
already uploaded the new version. :-)

> Since I have uploaded the package and FTP Masters already accepted it
> I close this bug.
> 
> Regarding the package, providing a symbols file would be nice. :-)

Given my previous attempt at providing symbols files for C++ packages I am 
reluctant to do so.
If possible I will avoid adding that file for a while:
upstream is not answering my emails since a while and I still have to instruct 
them about SONAMEs and many other things (e.g., binary name conflicts, scripts 
extensions,
...); I would like to have better interaction with them, before trying to keep 
track of symbols.

> Feel free to ping me on ask for sponsorship on debian-science in the
> future, there is no
> need to file formal RFS-s to BTS if there are people who regularly
> sponsor upload for you. :-)

Fine, thank you. :-)

Cheers,
Giulio

Bug#824768: iceowl-l10n-et: should recommend myspell-et

[Jonas Smedegaard]

Package: iceowl-l10n-et
Version: 4.0.0.1-1
Severity: normal
Tags: l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As subject says, please have iceowl-l10n-et recommend myspell-et.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPc1sAAoJECx8MUbBoAEhMAoP/juKYG7fW7secRbQnftZyuAy
5XMGDFJRGfisarosuw1HSsUTtxFRny85ytCnyltP4I5sGCGf7YLEeOs9ygwxxDuA
CkDuCFaCFriRi/kqo3szR7DIB1wrKm4fue8gTID1W1iMfpBYkFZIeclmlzS6wUyL
Xkcz/ZFRI0QAMcDr0lU+yzsKMi49S3DWxnOWREj8i3qaSHVl+Zy8F14cct+kkFt6
7NvvSu5aYuFVili/lhe8j0i8Avqyamr2qUHgbdJUFfcnpLMyD5/c5C9slqoPDn/3
RCL16KF9cEKFh7fLWKmgfnm9PSYbvuhiLt+xcAsNZ83MkYar5aFS7LlPUn6PdoPe
R7VS4xWIamjoRSbjTGpP8mwtNnftxanc+BLzFVihm01ZQr3moO/LrURFHFZb8acI
9fARPATRfl3pXjrFSmKlsuhNQDIsZuQ+G1huCEjt7PP+BNGanTapg7d4/+VJAGOy
lryxMwn/Dvpbn2ZM4xw8c+xPcOJ7RhL0sFcjs0UJjwJp0Ww8c8n1SxafESWN6WnB
t28q7L+CMtGiLCaYPynszmI7Z1EmrFB5IikA2+1yjpVd4HHuHv2U2468+86oI9pn
zvZkA7Ml0bSjDCrBllzkAXeocVF4ZhOWDCgkF627fC+M486+5d7DKdODu/puSudz
Qm2lL3+0EFk/zf9cl9zH
=/aJc
-END PGP SIGNATURE-

Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction

[Santiago Vila]

On Thu, May 19, 2016 at 03:19:24PM +0200, Pierre Ynard wrote:

> Is that kind of downgrade supposed to be supported?

No, it is not supposed to be supported.

> I encountered configuration migration problems for apt and postfix,
> shall I file bugs for these?

Probably not.

This is a seldom used feature which may or may not work.

For this to be supported, we would probably need a high number of
people doing it as a "normal thing", because implementing a feature
for only 0,001% of people is usually not a good idea.

However, if a great number of people felt the need to downgrade their
systems this way, that would mean that either we completely failed at
writing the release notes, or we completely failed at making a stable
release, in which case supporting downgrades would probably be the
lesser of our problems.

Bug#824812: out-of-date backport

[Nicholas D Steeves]

Package: diskscan
Version:0.18-1~bpo8+1

Hi Joao,

Diskscan-0.19-1 is in testing.  I'm presently testing it on a
SAT-supported USB drive.  Please backport, or let me know if you'd
like me to maintain one.  I can either upload packages, or if you'd
prefer push my local jessie-backports branch of diskscan--with tagged
releases, courtesy of gbp.  Mattia Rizzolo from the debian-multimedia
team helped get me up to speed with maintaining packages in git.

Kind regards,
Nicholas

Bug#691843: Package Adoption

[Jason Crain]

On Thu, May 19, 2016 at 09:08:34PM -0400, Javier Prats wrote:
> I'm interested in picking up this package.  How may I proceed?

These adoption and orphan bugs tend to not be monitored by anyone, so if
you want to contact the maintainer, you need to cc them on the email.

If you're new to packaging, I suggest you start with the debian-mentors
FAQ (https://wiki.debian.org/DebianMentorsFaq) and various documents it
links to.  If after reading that you still have questions, ask on the
#debian-mentors IRC channel or the debian-mentors mailing list.

Bug#824816: dh-systemd: systemd2init doesn't convert exec fields with arguments correctly

[Phil]

Package: dh-systemd
Version: 1.33
Severity: normal

Dear Maintainer,

Running systemd2init on a systemd unit file that has arguments on exec fields
will create incorrect values in the output file.

As an example, when the unit file contains:
ExecStartPre=/bin/foo -z bar -y baz -x qux

The .init file produced has:
/bin/fooqux



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

Versions of packages dh-systemd depends on:
ii  debhelper  9.20160403
ii  perl   5.22.2-1

dh-systemd recommends no packages.

Versions of packages dh-systemd suggests:
ii  augeas-tools  1.2.0-0.3

-- no debconf information

Bug#792894: systemd unit files for isc-dhcp-server

[Terry Burton]

Hi Marc, et al.

As you know from discussions on the dhcp-users mailing list I've been
threatening to do some systemd packaging work for ISC DHCP so I'm
taking your contributions as a starting point.

I can't speak for the Debian packaging team so maybe Michael Gilbert
can review this and let us know whether this is on track.

I've taken a look at your unit files and taken the liberty to create
some new ones based on them that I've added to my repo here [2].

I've used the latest Debian sys-v init script from the packaging
repository [3] as my reference for what's sane.

Compared to the originals units:

(1) I've added "Wants" to isc-dhcp-server.target which ensures that
subordinate services are started. Therefore you only need "enable" the
.target file to ensure that the v4 and v6 daemons are started assuming
they are configured.
(2) In the -v4 service file I've replaced references to dhcpd4.conf
with dhcpd.conf since this provides compatibility across upgrades.
(3) I've added an EnvironmentFile option that reads the user provided
settings from /etc/default/isc-dhcp-server. I think only INTERFACES,
INTERFACESv4, INTERFACESv6 and possibly OPTIONS remain relevant for
reasons given in (8) and (9) below.
(4) You use ConditionPathExists=/etc/dhcp/{dhcpd.conf,dhcpd6.conf} to
determine whether to start the units. I like this approach and have
kept it as it provides nice semantics in (5) and (6) below for whether
to start the v4 and v6 subcomponent services.
(5) Since a dhcpd6.conf file isn't currently installed by the package
(and probably shouldn't be, at least not yet) there is no attempt to
start a IPv6 instance - following the principle of least surprise. You
can simply add a dhcpd6.conf file and restart isc-dhcp-server.target
to enable the v6 instance.
(6) You can correspondingly disable the v4 instance by moving
dhcpd.conf out of the way.
(7) I note that this is a different condition for deciding whether or
not to start the daemon than the sys-v script which us whether or not
INTERFACESv{4,6} is defined in /etc/default/isc-dhcp-server. Such a
condition can't be done cleanly in systemd, i.e. you cannot have an
enabled service (or component of a compound target) that simply
decides not to start based on an arbitrary test). Perhaps the sys-v
init script can be aligned to the dhcpd{,6}.conf exists approach?
(8) Since you can't expand environment variables in the
ConditionPathExists and therefore refer directly to the config files
you may as well also hardcode the the values for DHCPDv{4,6}_CONF in
the ExecStart/ExecStartPre lines, i.e. don't read these from
/etc/default/isc-dhcp-server.
(9) I've dropped support for extracting OPTIONS (and OPTIONSv4,
OPTIONSv6)  from /etc/default/isc-dhcp-server since it isn't honoured
by the most recent sysv-init script [3]. If this is accidental then
its trivial to add this back into both systemd and sys-v.
(10) Support for changing the PID file location in
/etc/default/isc-dhcp-server now seems a little odd given that we no
longer take the conf file from here so I've dropped it. This could
alternatively be passed in OPTIONSv{4,6} if we were to enable these.

A general problem that I've noticed which might cause us to modify the
isc-dhcp-server.target approach is that the following commands will
not have the expected effect:

service isc-dhcp-server {start,stop,restart}
systemctl {start,stop,restart} isc-dhcp-server

(1) It doesn't appear as though you can invoke .target unit files
using /usr/sbin/service. This'll drive some purists nuts!
(2) Additionally, these commands as-is will actually invoke LSB
compatibility and trigger the sys-v init script rather than the native
isc-dhcp-server.target unit file.
(3) The packaging would need to do something ensure that the
isc-dhcp-server init script (via LSB) and isc-dhcp-server.target unit
are not both started at boot.

This could spoil an otherwise neat approach. Any suggestions welcome...

I'm not intending to wire up the maintainer scripts until we have an
agreed approach so you'll have to hand-pick the unit files from my
repo [2] into {/etc,/lib}/systemd/system for the time being.

Would you mind taking a look to make sure these work for you, caveats
aside, and let me have any feedback.


[1] https://lists.isc.org/pipermail/dhcp-users/2016-May/020093.html
[2] 
https://github.com/terryburton/isc-dhcp-debian/commit/26d3a94e00853f17141a6f748169dc2a26366b15
[3] 
http://anonscm.debian.org/cgit/pkg-dhcp/isc-dhcp.git/tree/debian/isc-dhcp-server.init.d


Thanks.

Bug#811033: Workaround

[Adam McKenna]

So to save everyone else the hour and a half I spent figuring out how to
fix this, here's what you need to do:

# lvconvert --mirrors -1  
# vgchange -ay
# lvconvert -m 1 

Where lv_device is the device that's having issues, and  is the
SECONDARY device on the RAID1 mierror.

This will throw a warning, but will remove the secondary device.

vgchange should then be able to bring up the (now un-mirrored) volumes.

 After vgchange, run lvconvert again to add the mirror back.  This requires
a resync.

The above has to be done after every reboot.

Bug#824673: wine32-development-tools:i386 cannot be installed on amd64

[Javier Serrano Polo]

El dj 19 de 05 de 2016 a les 15:47 +0200, Jens Reyer va escriure:
> So for winegcc there is no reason to install wine32-tools on amd64?

An extra -L flag needs to be specified with wine64-tools.

> What about the other tools in that package?

No idea.

> So you have wine64-tools with libwine-dev:i386 installed, but no
> libwine-dev:amd64?

Correct.

> And you're sure that this is necessary and works?

It works. I do not install libwine-dev:amd64 to avoid a lot of
dependencies.

> libwine-dev's *.h and *.idl files in /usr/include/wine/ are arch
> independent, only the *.def files in /usr/lib//wine/ are arch
> specific.
> So for the former it doesn't matter which package is installed, and for
> the latter I don't see how the 64-bit winegcc is able to find the 32-bit
> files.

The -L/usr/lib/i386-linux-gnu/wine flag is needed.


smime.p7s
Description: S/MIME cryptographic signature

Bug#824806: [pkg-golang-devel] Bug#824806: golang: random_build_path_by_golang_compiler is #824806

[Michael Hudson-Doyle]

FWIW my impression is that this issue has been addressed upstream and will
be fixed in the 1.7 release, but maybe someone should check?

Bug#824815: Bootloader burning verification error

[Milan Kupcevic]

Package: arduino
Version: 2:1.0.5+dfsg2-4
Severity: important
Control: tags -1 patch


Since avrdude version 6.2 efuse bitmask has been changed for ATmega168
and ATmega328, arduino has not been able to burn bootloaders to the
boards with the mentioned microcontrollers.

Please update arduino efuse values accordingly.

A patch with necessary updates is attached.

Milan
diff --git a/hardware/arduino/boards.txt b/hardware/arduino/boards.txt
index de9f4ef..0769116 100644
--- a/hardware/arduino/boards.txt
+++ b/hardware/arduino/boards.txt
@@ -8,7 +8,7 @@ uno.upload.maximum_size=32256
 uno.upload.speed=115200
 uno.bootloader.low_fuses=0xff
 uno.bootloader.high_fuses=0xde
-uno.bootloader.extended_fuses=0x05
+uno.bootloader.extended_fuses=0xfd
 uno.bootloader.path=optiboot
 uno.bootloader.file=optiboot_atmega328.hex
 uno.bootloader.unlock_bits=0x3F
@@ -28,7 +28,7 @@ atmega328.upload.speed=57600
 
 atmega328.bootloader.low_fuses=0xFF
 atmega328.bootloader.high_fuses=0xDA
-atmega328.bootloader.extended_fuses=0x05
+atmega328.bootloader.extended_fuses=0xfd
 atmega328.bootloader.path=atmega
 atmega328.bootloader.file=ATmegaBOOT_168_atmega328.hex
 atmega328.bootloader.unlock_bits=0x3F
@@ -49,7 +49,7 @@ diecimila.upload.speed=19200
 
 diecimila.bootloader.low_fuses=0xff
 diecimila.bootloader.high_fuses=0xdd
-diecimila.bootloader.extended_fuses=0x00
+diecimila.bootloader.extended_fuses=0xf8
 diecimila.bootloader.path=atmega
 diecimila.bootloader.file=ATmegaBOOT_168_diecimila.hex
 diecimila.bootloader.unlock_bits=0x3F
@@ -70,7 +70,7 @@ nano328.upload.speed=57600
 
 nano328.bootloader.low_fuses=0xFF
 nano328.bootloader.high_fuses=0xDA
-nano328.bootloader.extended_fuses=0x05
+nano328.bootloader.extended_fuses=0xfd
 nano328.bootloader.path=atmega
 nano328.bootloader.file=ATmegaBOOT_168_atmega328.hex
 nano328.bootloader.unlock_bits=0x3F
@@ -91,7 +91,7 @@ nano.upload.speed=19200
 
 nano.bootloader.low_fuses=0xff
 nano.bootloader.high_fuses=0xdd
-nano.bootloader.extended_fuses=0x00
+nano.bootloader.extended_fuses=0xf8
 nano.bootloader.path=atmega
 nano.bootloader.file=ATmegaBOOT_168_diecimila.hex
 nano.bootloader.unlock_bits=0x3F
@@ -217,7 +217,7 @@ mini328.upload.speed=115200
 
 mini328.bootloader.low_fuses=0xff
 mini328.bootloader.high_fuses=0xd8
-mini328.bootloader.extended_fuses=0x05
+mini328.bootloader.extended_fuses=0xfd
 mini328.bootloader.path=optiboot
 mini328.bootloader.file=optiboot_atmega328-Mini.hex
 mini328.bootloader.unlock_bits=0x3F
@@ -238,7 +238,7 @@ mini.upload.speed=19200
 
 mini.bootloader.low_fuses=0xff
 mini.bootloader.high_fuses=0xdd
-mini.bootloader.extended_fuses=0x00
+mini.bootloader.extended_fuses=0xf8
 mini.bootloader.path=atmega
 mini.bootloader.file=ATmegaBOOT_168_ng.hex
 mini.bootloader.unlock_bits=0x3F
@@ -259,7 +259,7 @@ ethernet.upload.speed=115200
 
 ethernet.bootloader.low_fuses=0xff
 ethernet.bootloader.high_fuses=0xde
-ethernet.bootloader.extended_fuses=0x05
+ethernet.bootloader.extended_fuses=0xfd
 ethernet.bootloader.path=optiboot
 ethernet.bootloader.file=optiboot_atmega328.hex
 ethernet.bootloader.unlock_bits=0x3F
@@ -280,7 +280,7 @@ fio.upload.speed=57600
 
 fio.bootloader.low_fuses=0xFF
 fio.bootloader.high_fuses=0xDA
-fio.bootloader.extended_fuses=0x05
+fio.bootloader.extended_fuses=0xfd
 fio.bootloader.path=arduino:atmega
 fio.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
 fio.bootloader.unlock_bits=0x3F
@@ -302,7 +302,7 @@ bt328.upload.disable_flushing=true
 
 bt328.bootloader.low_fuses=0xff
 bt328.bootloader.high_fuses=0xd8
-bt328.bootloader.extended_fuses=0x05
+bt328.bootloader.extended_fuses=0xfd
 bt328.bootloader.path=bt
 bt328.bootloader.file=ATmegaBOOT_168_atmega328_bt.hex
 bt328.bootloader.unlock_bits=0x3F
@@ -324,7 +324,7 @@ bt.upload.disable_flushing=true
 
 bt.bootloader.low_fuses=0xff
 bt.bootloader.high_fuses=0xdd
-bt.bootloader.extended_fuses=0x00
+bt.bootloader.extended_fuses=0xf8
 bt.bootloader.path=bt
 bt.bootloader.file=ATmegaBOOT_168.hex
 bt.bootloader.unlock_bits=0x3F
@@ -366,7 +366,7 @@ lilypad328.upload.speed=57600
 
 lilypad328.bootloader.low_fuses=0xFF
 lilypad328.bootloader.high_fuses=0xDA
-lilypad328.bootloader.extended_fuses=0x05
+lilypad328.bootloader.extended_fuses=0xfd
 lilypad328.bootloader.path=atmega
 lilypad328.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
 lilypad328.bootloader.unlock_bits=0x3F
@@ -387,7 +387,7 @@ lilypad.upload.speed=19200
 
 lilypad.bootloader.low_fuses=0xe2
 lilypad.bootloader.high_fuses=0xdd
-lilypad.bootloader.extended_fuses=0x00
+lilypad.bootloader.extended_fuses=0xf8
 lilypad.bootloader.path=lilypad
 lilypad.bootloader.file=LilyPadBOOT_168.hex
 lilypad.bootloader.unlock_bits=0x3F
@@ -408,7 +408,7 @@ pro5v328.upload.speed=57600
 
 pro5v328.bootloader.low_fuses=0xFF
 pro5v328.bootloader.high_fuses=0xDA
-pro5v328.bootloader.extended_fuses=0x05
+pro5v328.bootloader.extended_fuses=0xfd
 pro5v328.bootloader.path=atmega
 pro5v328.bootloader.file=ATmegaBOOT_168_atmega328.hex
 pro5v328.bootloader.unlock_bits=0x3F
@@ 

Bug#824441: [Aptitude-devel] Bug#824441: aptitude segfaults when marking texlive-generic-extra as auto-installed

[James Tocknell]

Found a different case where aptitude segfaults, this time I marked a few
packages as auto-installed, and after holding the up arrow for a few
seconds, aptitude segfaulted. A backtrace from this is below:
Program received signal SIGSEGV, Segmentation fault.
0x77b3feed in debVersioningSystem::CheckDep(char const*, int, char
const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#0  0x77b3feed in debVersioningSystem::CheckDep(char const*, int,
char const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#1  0x557767c1 in infer_reason (pkg=..., reasons=std::set with 1
elements = {...}) at ../../../../src/generic/apt/infer_reason.cc:178
#2  0x55650418 in reason_fragment (pkg=...,
breakage=@0x7fffcece: false) at ../../src/reason_fragment.cc:447
#3  0x5564abcc in info_area_multiplex::set_package
(this=0x56b436e0, pkg=..., ver=...) at ../../src/pkg_view.cc:454
#4  0x556227e0 in sigc::internal::signal_emit2::emit (_A_a2=..., _A_a1=..., impl=0x5604f970)
at /usr/include/sigc++-2.0/sigc++/signal.h:1266
#5  sigc::signal2::emit (this=, _A_a2=..., _A_a1=...) at
/usr/include/sigc++-2.0/sigc++/signal.h:2989
#6  sigc::signal2::operator() (_A_a2=..., _A_a1=..., this=)
at /usr/include/sigc++-2.0/sigc++/signal.h:2997
#7  pkg_item::do_highlighted_changed (this=0x592d43a0,
highlighted=) at ../../src/pkg_item.cc:115
#8  0x771d5b8d in sigc::internal::signal_emit1::emit(sigc::internal::signal_impl*,
cwidget::widgets::treeitem* const&) ()
   from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#9  0x771cee93 in cwidget::widgets::tree::line_up() () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#10 0x771d3e41 in
cwidget::widgets::tree::handle_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#11 0x5561641d in menu_tree::handle_key
(this=this@entry=0x55c98cf0,
k=...) at ../../src/menu_tree.cc:430
#12 0x55633973 in pkg_tree::handle_key (this=0x55c98cf0, k=...)
at ../../src/pkg_tree.cc:363
#13 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#14 0x771c1da7 in
cwidget::widgets::table::handle_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#15 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#16 0x771ad4bb in
cwidget::widgets::passthrough::handle_key(cwidget::config::key const&) ()
from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#17 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#18 0x771c1da7 in
cwidget::widgets::table::handle_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#19 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#20 0x771ad4bb in
cwidget::widgets::passthrough::handle_key(cwidget::config::key const&) ()
from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#21 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#22 0x7718e1f1 in
cwidget::widgets::menubar::handle_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#23 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#24 0x7715bdc9 in
cwidget::toplevel::input_thread::get_input_event::dispatch() () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#25 0x771536b5 in cwidget::toplevel::mainloop(int) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#26 0x5568c64a in ui_main () at ../../src/ui.cc:3075
#27 0x555b50e0 in main (argc=, argv=)
at ../../src/main.cc:1398
quit


On 17 May 2016 at 13:16, James Tocknell  wrote:

> amd64 is missing aptitude-dbgsym (which is why I asked), but it appears to
> be created by gbp, so I've used that to build a debug package, which gives
> the following backtrace:
> Program received signal SIGSEGV, Segmentation fault.
> 0x77b3feed in debVersioningSystem::CheckDep(char const*, int, char
> const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
> #0  0x77b3feed in debVersioningSystem::CheckDep(char const*, int,
> char const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
> #1  0x557767c1 in infer_reason (pkg=..., reasons=std::set with 0
> elements) at 

Bug#824211: swh-plugins: Package new upstream version

[Jaromír Mikeš]

2016-05-20 0:51 GMT+02:00 Javier Serrano Polo :
> El dj 19 de 05 de 2016 a les 19:41 +0200, Jaromír Mikeš va escriure:
>> Yes, that would be definitely possible, but I would to to know where
>> next releases will be published to tune watch file accordingly.
>
> Nine years have passed without a release. I think a watch file is
> obsolete. I would rely on "New upstream release" bugs from users.

Hi Javier,

I would rather hear from upstream what is planned than just wild guess
of user ;)
Did you asked upstream author if new releases is planned?
He is active and for lv2 version doing releases ...

https://github.com/swh/lv2/releases

So I would guess there could be also for ladspa version soon ... new
plugin is good reason for it.

Please ask him and let me know.

mira

Bug#824640: shadowsocks: Shadowsocks upstream has removed available public source code

[Shell Xu]

About the version thing. I asked author which release should I used. He
said anyone you want. I said "even the lastest one?". Yes, that's good.
So I took the lastest commit as a release. Because it contains some feature
I need.

On Thu, May 19, 2016 at 11:26 PM, u  wrote:

> Hi!
>
> thanks for your quick answer.
>
> Shell Xu:
> > Hi, u:
> >
> > That's very interesting. Let's see what happened one by one.
> >
> > First of all, source code are not been "deleted". It's just a branch
> > called "rm". If you switch branch to master, code is still been there (
> > https://github.com/shadowsocks/shadowsocks/tree/master).
>
> You're correct. My mistake. However this branch has been set as main
> branch.
>
> > Next thing is really interesting. You can find my commit in
> repository (
> >
> https://github.com/shadowsocks/shadowsocks/commit/3b242bee5eb191599a0d051497003127986ea290
> ).
> > But if you click "Browse files", and pull to the end. It tunes out at the
> > time I did the packaging job, the repository address is "
> > https://github.com/clowwindy/shadowsocks/wiki; (its wiki), and License
> is
> > MIT.
> > Yes, I did the right job at that time. The repository is modified,
> > translated to someone else, and license changed.
>
> ack. Thanks for clarifying this. I actually did not see a release of
> this version at all.
>
> > I followed commit logs, and here is the log which license changed. (
> >
> https://github.com/shadowsocks/shadowsocks/commit/ce805f0aeaea03646e01b623c4e2185f63a3562f
> ).
> > The whole project are re-licensed to Apache to protect the name of
> > contributors. It's happened far after my work, even after Debian accept
> it.
> > (according here: https://packages.qa.debian.org/s/shadowsocks.html, it's
> > 2014-09-16) In this situation, I think the old code still can be used
> under
> > MIT, and new code can only be used under Apache. So I should use new
> > license if package new one. But I don't have to update package to follow
> > the new license.
>
> Correct.
>
> > As you might noticed, shadowsocks is a software which designed to
> > broken the GFW. So it's not weird that government wanna erase this whole
> > project. The main author (clowwindy) was found by police, and have a
> little
> > conversation. (which we call it "drink tea") He is forbidden to maintain
> > the project, even talk about it. So I don't trust any commit after that
> > time. (just before 2015-08-20) Because government might inject something
> in
> > it after that time.
>
> Thanks for clarifying this.
>
> > Here is the thing I wanna do.
> >
> > I'll update the package to version 2.8.2 in stretch. (of course, it's
> > not a "release", because the author never planed to release at the time
> > been called for "tea". and of course, under Apache License) That will be
> > the final version. Any "new" version after that time should been review
> > carefully.
>
> Fair enough.
>
> > And, I'll remove this project from Debian in next release (after
> > stretch). Because we should had something new at that time. (Or
> hopefully,
> > we can finally get ride of GFW at that time)
>
> Let's hope so!
>
> I'll retitle this bug report accordingly then.
>
> Cheers!
>



-- 
彼節者有間，而刀刃者無厚；以無厚入有間，恢恢乎其於游刃必有餘地矣。
blog: http://shell909090.org/blog/
twitter: @shell909090 
about.me: http://about.me/shell909090

Bug#824154: mupen64plus-qt: Crash when useing: File → Open ROM directly after clicking

[Dan Hasting]

On Fri, 13 May 2016 01:07:01 +0200 Kevin Bradenstein 
 wrote:

Package: mupen64plus-qt
Version: 1.8-2
Severity: normal

Dear Maintainer,

I freshly installed mupen64plus-qt but I am unable to open a ROM file.

I start mupen64plus-qt via my console.
Directly after clicking File → Open ROM... in the menu the programm
ended with following message:

zsh: segmentation fault  mupen64plus-qt

I started gdb and got the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x76cddc6a in QUrl::fromLocalFile(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
(gdb) bt
#0  0x76cddc6a in QUrl::fromLocalFile(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x7788479e in QFileDialog::getOpenFileName(QWidget*, QString const&, QString 
const&, QString const&, QString*, QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#2  0x004162ea in ?? ()
#3  0x0045980d in ?? ()
#4  0x76db2f8a in QMetaObject::activate(QObject*, int, int, void**) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7766d3b2 in QAction::triggered(bool) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#6  0x7766f838 in QAction::activate(QAction::ActionEvent) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x777f1cd2 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x777f7f6c in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x777fbee0 in QMenu::mouseReleaseEvent(QMouseEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x776b9f28 in QWidget::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x777fc933 in QMenu::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x77676ffc in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x7767cbb9 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x76d845ab in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x7767bad2 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, 
QWidget*, QWidget*, QWidget**, QPointer&, bool) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x776d47dd in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x776d6a3b in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x77676ffc in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x7767c4b6 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#20 0x76d845ab in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x770c6171 in 
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*)
 ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#22 0x770c7e35 in 
QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
 ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#23 0x770abe68 in 
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
 ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#24 0x7fffee8fe0b0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#25 0x755741a7 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x75574400 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x755744ac in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x76ddaa3f in 
QEventDispatcherGlib::processEvents(QFlags) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#29 0x76d81d6a in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x76d89e0c in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#31 0x004102ea in ?? ()
#32 0x761e45f0 in __libc_start_main (main=0x40ff50, argc=1, argv=0x7fffe068, 
init=, fini=,
rtld_fini=, stack_end=0x7fffe058) at libc-start.c:291
#33 0x00410af9 in ?? ()




Let me know if this patch fixes it:
https://github.com/dh4/mupen64plus-qt/commit/e294d147a2140510d98cddce1c4855f0eedb496e

You can download the development build off the README or clone and compile it 
yourself (instructions for that are in the README as well).

Bug#824803: trying to overwrite '/usr/share/texlive/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-de-1901.tex', which is also in package texlive-base 2015.20160320-1

[Norbert Preining]

tag 824803 + pending
thanks

Hi Julian,

thanks for the report. Yes indeed, not only lang-german, but all
the lang-* packages as hyphenation patterns have moved out
into the separate packages.

I have added replaces/breaks for all the lang packages.

> You cannot really conflict with texlive-lang-german from texlive-base.
> You need to Conflict with the old base from lang-german.

Not conflict, but break, but yes. What you have seen is an additional
safety net so that we start installing tl-base only when all others
are available.

> The current way definitely does not work, because it tells us to upgrade
> lang-german to 2016 before upgrading base from 2015 to 2016 which
> fails because base 2015 and german 2016 contain the same file.

With the added replaces/breaks it will deconfigure base, then replaces
the files, and install everything. At least that is the theory ;-)

TL 2016 is in freeze, so I am uploading the current state soon.

All the best

Norbert


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

Bug#691843: Package Adoption

[Javier Prats]

Hello,

I'm interested in picking up this package.  How may I proceed?

Javier Prats

Bug#824813: dh-systemd: systemd2init always falls back to default values

[Phil]

Package: dh-systemd
Version: 1.33
Severity: normal
Tags: patch

Dear Maintainer,

The .init file produced by systemd2init always has default values for every
field, EG. DESC= and DAEMON=/usr/sbin/\$NAME

This appears to be caused by the script (via augtool) checking 2 non-existing
locations for the systemd unit file.

The attached patch fixes the issue for me, but I haven't tested it on a Redhat
machine (which the script also accommodates).



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

Versions of packages dh-systemd depends on:
ii  debhelper  9.20160403
ii  perl   5.22.2-1

dh-systemd recommends no packages.

Versions of packages dh-systemd suggests:
ii  augeas-tools  1.2.0-0.3

-- no debconf information
--- a/systemd2init/systemd2init
+++ b/systemd2init/systemd2init
@@ -19,16 +19,14 @@
 
 lsconf() {
 RET=
-	aug_path="/files/lib/systemd/system//${SYSTEMD_SERVICE}${1}"
-	[ -f "$SYSTEMD_SERVICE" ] && aug_path="/files$(pwd)//${SYSTEMD_SERVICE}${1}"
-	augtool -r "$WORKINGDIR" -t "Systemd incl $(pwd)/$SYSTEMD_SERVICE" ls "$aug_path"
+	aug_path="/files/${SYSTEMD_SERVICE}${1}"
+	augtool -r "$WORKINGDIR" -t "Systemd incl $SYSTEMD_SERVICE" ls "$aug_path"
 }
 
 getconf() {
 RET=
-	aug_path="/files/lib/systemd/system/${SYSTEMD_SERVICE}${1}"
-	[ -f "$SYSTEMD_SERVICE" ] && aug_path="/files$(pwd)/${SYSTEMD_SERVICE}${1}"
-	augtool -r "$WORKINGDIR" -t "Systemd incl $(pwd)/$SYSTEMD_SERVICE" get "$aug_path" | \
+	aug_path="/files/${SYSTEMD_SERVICE}${1}"
+	augtool -r "$WORKINGDIR" -t "Systemd incl $SYSTEMD_SERVICE" get "$aug_path" | \
 		sed -e "s;^${aug_path}[[:space:]]*\((none)\|(o)\|= \)[[:space:]]*;;"
 }
 

Bug#824814: FTBFS: Missing Build-Dependencies

[Jörg Frings-Fürst]

Package: jq
Version: 1.5+dfsg-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

by build with pbuilder (DIST=sid pdebuild) I get the warning:

checking for Ruby dependencies... configure: WARNING:
*
*  Ruby dependencies for building jq documentation not found.   *
*  You can still build, install and hack on jq, but the manpage *
*  will not be rebuilt and some of the tests won't run. *
*  See docs/README.md for how to install the docs dependencies. *
*
no
checking for size_t... yes


and then a the tests:

PASS: tests/mantest
PASS: tests/jqtest
PASS: tests/onigtest
FAIL: tests/shtest

   jq 1.5-1-a5b5cbe: ./test-suite.log


# TOTAL: 4
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/shtest
==


I attach the build- and the test-log later.

CU
Jörg



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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXPob2AAoJEAn4nzyModJdbFAP/j1Vpe2rNgj/FR+Hberkau5m
zBWSjC3BRTAA7kw8upWGQEVkyLStvkFwPO9/WHEOktJebXxiMTJXVO0gMcLRni/l
9jrWLGGwFkZ+bkAqmmbTqe0SemftOlnpjV5Ta3vjm151bYKfpBXxhPBuYHLOIksv
0tztAbe6HQvuJNNpAaIlhKYqJIcYFDLK2kDLonJ9ghsUkHgdmgy9TqjEpa3+5AyH
nBCGXAGZE8QW2vXPbkuE0R92+gQTQ/25QbUJTuaBTnh86I76dnSAxZ46EU1WMJG+
6dkWGWiol9ssCuwTNG3rUx0ypLy5bMC/SiZMxEgu7/VJcIlJ9ATk1WGlRWHQu0Vr
AzEZfm5DZslnrV4NHgVfoELnjfK9tL3hjL4ZzW7o434/bL0v+PLxK7V1a3btUxMI
aaLWj2xB+QgN9hKnD7v2mHxOGUWmHnLNFUSZAPymaCegaGh8Aa3iVRfzvEeKxx60
RAT9NidR0CujFDsENelSjJoDkhwbE1YWyH6Wd3/sWpCk4yUTEpZvsKKY3jGQphOC
W+4vuzJY+g6aUAXQTPEtOucQ8kfgiAgz9qSzufa8f3yCHrHasRCQv5D7pDaX8d84
Cc1CsUdq51/3dPLDZQEXk0LS+D3gcHW5cT3jZKbkUsa8+AuNH/T7QdIEJoAd0Wpd
GcegNlM/6pBO5kDK3wQX
=Tlyw
-END PGP SIGNATURE-

Bug#824078: libdvd-pkg: fails to report "apt-get check" errors (and others) correctly

[Austin English]

On Mon, 16 May 2016 00:10:35 +1000 Dmitry Smirnov 
wrote:
> On Sunday, 15 May 2016 3:15:50 PM AEST Cyril Brulebois wrote:
> > instead of being told again and again how much of a snow flake
> > your package is, and how OK it is for it to behave like it currently does.
> 
> You seems to imply that everything is terribly wrong with the package that 
> sounds like exadderation. Design may not be perfect but I'm not aware of 
> better one...
> 
> I'm all for improvements. But on this instance it is hard to safely improve 
> on problems that you highlighted. It is more difficult than just propagate 
> error codes or I would have already fixed it... I hope you understand...

I don't understand. I understand that there's a *potential* problem. But
here we have an *actual* problem, where the script is silently ignoring
errors which is causing problems in downstream, and as far as I can
tell, the current solution is to ignore actual errors in favor of
preventing *potential* solutions?

What exactly needs to be tested in the current packaging scheme so that
behavior could be changed? I volunteer to help with that, if it's made
clear what needs to be done.



signature.asc
Description: OpenPGP digital signature

Bug#823325: mariadb-10.0: Various security fixes from 10.0.25 release

[Salvatore Bonaccorso]

Hello Otto,

On Wed, May 04, 2016 at 09:39:12AM +0300, Otto Kekäläinen wrote:
> Acknowledged. I started working on the updates on Saturday but my
> build/test machine broke down and I haven't yet successfully rescued
> the btrfs file system on it. I intend to to the upgrades ASAP but
> right now I cannot promise a schedule, sorry.

Were you able to recover already from that build machine failure?

Bug#824817: Please include bytecode.cvd in one .deb

[Mathieu Parent]

Package: clamav-testfiles
Version: 0.99.2+dfsg-2
Severity: wishlist

Hi,

There is no offline way to test clamav. I need this to ensure c-icap is
working properly using autopkgtest.

I propose that you include bytecode.cvd in clamav-testfiles.

Thanks

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

-- no debconf information

Bug#824111: ExpatError: syntax error

[Ritesh Raj Sarraf]

On Mon, 2016-05-16 at 17:06 +0200, Gaetano Guerriero wrote:
> 
> There are reproducible errors when calling get_bug_log() on same bug reports
> (799939, 818360).
> 
> This is not thread related, it happens even with on thread.
> 
> Server is responding with 500, pysimplesoap tries to parse response body
> anyway
> and it breaks. We can't fix this at debianbts level, except maybe by raising a
> generic "DebianBtsError".

Thanks Gaetano. I'm doing the same accordingly in my application now. In apt-
offline, now, if the bug reports fail we'll not term it a fatal error.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#824712: RFH: smokeping

[Iain R. Learmonth]

Hi,

In 18/05/16 23:22, Antoine Beaupré wrote:
> I need help maintaining the smokeping package. I do not really use it
> anymore and i'd be happy to help people to sponsor it. There's a bunch
> of obscure bugs all over the place, and while I think the package
> mostly works, it's just a wild guess since well, I'm not using it
> right now.

Looks like a candidate for the Internet Measurement Packaging Team. (:

https://qa.debian.org/developer.php?login=pkg-netmeasure-disc...@lists.alioth.debian.org

Would be happy to be a co-maintainer for this package.

If this sounds good I'll add you to the team and we can update the
maintainer/uploaders fields on the next upload. (:

Thanks,
Iain.

Bug#824741: xpdf: some keysyms (0xe9 eacute and 0xdb Ucircumflex) are ignored in text input fields

[Vincent Lefevre]

Package: xpdf
Version: 3.04-1
Severity: normal

In text input fields, such as in the Find and Save As dialog boxes,
some keysyms are ignored. This is at least the case of:
  * 0xe9 eacute (é)
  * 0xdb Ucircumflex (Û)

However this is no such problem with: èêëâîôûàùïç ÉÈÊËÂÎÔÀÙÏÇ

Note: The problem is at the keysym level, as if I change my keyboard
configuration to use other keysyms for the same physical keys, the
characters appear as expected. Moreover, I can enter these characters
é and Û with dead keys (dead_acute + e and dead_circumflex + U).

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

Kernel: Linux 4.5.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, 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 xpdf depends on:
ii  libc6 2.22-9
ii  libgcc1   1:6.1.1-3
ii  libpoppler57  0.38.0-3
ii  libstdc++66.1.1-3
ii  libx11-6  2:1.6.3-1
ii  libxm42.3.4-10+b1
ii  libxt61:1.1.5-1

Versions of packages xpdf recommends:
ii  cups-bsd   2.1.3-5
ii  gsfonts-x110.24
ii  poppler-data   0.4.7-7
ii  poppler-utils  0.38.0-3

xpdf suggests no packages.

-- no debconf information

Bug#823864: [pkg-lxc-devel] Bug#823864: libpam-cgfs: installing libpam-cgfs from backport on stable prevent session from opening

[Xavier Quost]

Hi Evgeni

Sorry for this late answer.

> Strictly speaking bugs about backports should go to
> debian-backports@l.d.o and not the BTS, but I personally do not care, so
> lets keep it here for now.

Ok I will keep this in mind.


> Could you still provide stippets of auth.log and messages around that
> time? Just to crosscheck.

Here are auth.log with libpam-cgfs installed

May 19 11:37:31 pc251270 saslauthd[1938]: detach_tty  : master pid is: 1938
May 19 11:37:31 pc251270 saslauthd[1938]: ipc_init: listening on 
socket: /var/run/saslauthd/mux
May 19 11:37:31 pc251270 sshd[2371]: Server listening on 0.0.0.0 port 22.
May 19 11:37:31 pc251270 sshd[2371]: Server listening on :: port 22.
May 19 11:37:32 pc251270 sshd[2371]: Received signal 15; terminating.
May 19 11:37:32 pc251270 sshd[3058]: Server listening on 0.0.0.0 port 22.
May 19 11:37:32 pc251270 sshd[3058]: Server listening on :: port 22.
May 19 11:37:49 pc251270 kdm: :0[3246]: pam_unix(kdm:session): session opened 
for user xquost by (uid=0)
May 19 11:37:55 pc251270 login[3763]: pam_unix(login:session): session opened 
for user root by LOGIN(uid=0)
May 19 11:37:55 pc251270 login[3801]: ROOT LOGIN  on '/dev/tty1'
May 19 11:38:01 pc251270 login[3804]: pam_unix(login:session): session opened 
for user xquost by LOGIN(uid=0)
May 19 11:38:05 pc251270 login[3814]: pam_unix(login:auth): authentication 
failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost=  user=root
May 19 11:38:08 pc251270 login[3814]: FAILED LOGIN (1) on '/dev/tty1' FOR 
'root', Authentication failure
May 19 11:38:14 pc251270 login[3814]: FAILED LOGIN (2) on '/dev/tty1' FOR 
'root', Authentication failure
May 19 11:38:19 pc251270 login[3814]: pam_unix(login:session): session opened 
for user root by LOGIN(uid=0)
May 19 11:38:19 pc251270 login[3823]: ROOT LOGIN  on '/dev/tty1'
May 19 11:38:29 pc251270 saslauthd[1938]: server_exit : master exited: 1938
May 19 11:38:30 pc251270 sshd[3058]: Received signal 15; terminating.

As I was saying auth.log shows normal login (NB 2 false password as root to 
eased the research in log file)

Here are auth.log with libpam-cgfs uninstalled
May 19 11:40:00 pc251270 saslauthd[2063]: detach_tty  : master pid is: 2063
May 19 11:40:00 pc251270 saslauthd[2063]: ipc_init: listening on 
socket: /var/run/saslauthd/mux
May 19 11:40:00 pc251270 sshd[2416]: Server listening on 0.0.0.0 port 22.
May 19 11:40:00 pc251270 sshd[2416]: Server listening on :: port 22.
May 19 11:40:00 pc251270 sshd[2416]: Received signal 15; terminating.
May 19 11:40:00 pc251270 sshd[3110]: Server listening on 0.0.0.0 port 22.
May 19 11:40:00 pc251270 sshd[3110]: Server listening on :: port 22.
May 19 11:40:12 pc251270 kdm: :0[3298]: pam_unix(kdm:auth): authentication 
failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=  user=xquost
May 19 11:40:22 pc251270 kdm: :0[3298]: pam_unix(kdm:session): session opened 
for user xquost by (uid=0)
May 19 11:40:31 pc251270 polkitd(authority=local): Registered Authentication 
Agent for unix-session:1 (system bus name :1.28 
[/usr/lib/kde4/libexec/polkit-kde-authentication-agent-1], object path 
/org/kde/PolicyKit1/AuthenticationAgent, locale fr_FR.UTF-8)
May 19 11:40:39 pc251270 su[4207]: Successful su for root by xquost
May 19 11:40:39 pc251270 su[4207]: + /dev/pts/0 xquost:root
May 19 11:40:39 pc251270 su[4207]: pam_unix(su:session): session opened for 
user root by xquost(uid=1000)


> Do you mean you have other Jessie systems where libpam-cgfs does not
> trigger this behaviour?
Yes, but on those systems, there was no attempt to install lxc

> Do you by any chance have SELinux or AppArmor enabled on these boxes?
Yes, apparmor comes as a requirement of lxc



# apt-get install -t jessie-backports  lxc 
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances   
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus 
nécessaires :
 linux-headers-4.4.0-0.bpo.1-amd64 linux-headers-4.4.0-0.bpo.1-common 
linux-image-4.4.0-0.bpo.1-amd64 linux-kbuild-4.4
Veuillez utiliser « apt-get autoremove » pour les supprimer.
Les paquets supplémentaires suivants seront installés : 
 apparmor libapparmor-perl libapparmor1 liblxc1 libpam-cgfs libseccomp2 lxcfs
Paquets suggérés :
 apparmor-profiles apparmor-profiles-extra apparmor-docs apparmor-utils 
btrfs-tools lua5.2 lvm2
Les NOUVEAUX paquets suivants seront installés :
 apparmor libapparmor-perl libapparmor1 liblxc1 libpam-cgfs libseccomp2 lxc 
lxcfs
0 mis à jour, 8 nouvellement installés, 0 à enlever et 25 non mis à jour.
Il est nécessaire de prendre 37,0 ko/1 506 ko dans les archives.
Après cette opération, 4 891 ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] n

however before filling this bug report, lxc and apparmor were removed

dpkg -l |grep appar 
rc  apparmor  2.9.0-3  
amd64User-space parser 

Bug#824748: tracker.debian.org: VCS link for linux-base is outdated

[Bob Ham]

Package: tracker.debian.org
Severity: normal

Dear Maintainer,

The VCS links[0] for the linux-base source package[1] are outdated.
The Debian sources are now kept in a git repository[2].

[0] http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux-base/
[1] https://tracker.debian.org/pkg/linux-base
[2] http://anonscm.debian.org/cgit/kernel/linux.git/

Regards,

Bob Ham


--
Bob Ham 
Software Engineer
Collabora


Open First
Collabora is hiring!
Please check out our latest opportunities here:
http://bit.ly/Collabora-Careers

Bug#815409: qemu-img still segfaults

[Hilko Bengen]

Control: found -1 1:2.6+dfsg-1

I just tried with the latest qemu version, the problem still persists:

,
| (sid_mips-dchroot)bengen@minkus:~$ qemu-img --version
| qemu-img version 2.6.0 (Debian 1:2.6+dfsg-1), Copyright (c) 2004-2008 Fabrice 
Bellard
| (sid_mips-dchroot)bengen@minkus:~$ qemu-img create -f qcow2 
blank-disk-1s.qcow2 10
| Formatting 'blank-disk-1s.qcow2', fmt=qcow2 size=10 encryption=off 
cluster_size=65536 lazy_refcounts=off refcount_bits=16
| Segmentation fault
`

Cheers,
-Hilko

Bug#824594: please support DPKG_ROOT in base-files' postinst

[Santiago Vila]

On Wed, 18 May 2016, Helmut Grohne wrote:

> How about another approach to chown? Since user ids are never changed to
> base-passwd and we know that base-passwd is available during package
> build, we could do the name -> id lookup at package build time. Would
> you like a patch implementing that?

I'd like to see that the idea is useful first. That's why I suggest
to make a private repository with modified packages.

Please don't concentrate your efforts on this package alone. I said
that I would keep the bug open for reference, but I don't plan to
apply the patch very soon. Maybe I apply only to experimental, or
maybe I just add the DPKG_ROOT variable for a start so that you don't
have to modify it a lot for your private repository.

Thanks.

Bug#824732: bluez: Wishlist Package 5.39 Significant improvements for low power devices

[Mark Dickie]

Package: bluez
Version: 5.37-0ubuntu1~awe5
Severity: wishlist

Dear Maintainer,

On purchasing new low power bluetooth mouse found it not supported under 5.36
debian packages (MS 3600)

Installed Ubuntu packages 5.37 with partial success.

Reent improvements for low power devices in 5.37, 5.38 and 5.39

from www.bluez.org :  v5.39 Release notes : This is almost entirely a bug fix
release with important fixes to GATT, HoG, AVRCP & A2DP. It is recommended to
upgrade if you were previously using 5.38.

Many thanks

Mark




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

Versions of packages bluez depends on:
ii  dbus 1.10.8-1
ii  init-system-helpers  1.33
ii  kmod 22-1.1
ii  libc62.22-7
ii  libdbus-1-3  1.10.8-1
ii  libglib2.0-0 2.48.1-1
ii  libreadline6 6.3-8+b4
ii  libudev1 229-5
ii  lsb-base 9.20160110
ii  udev 229-5

bluez recommends no packages.

bluez suggests no packages.

-- no debconf information

Bug#824746: ITP: Munipack -- An astronomical photometry software package

[Filip Hroch]

Package: wnpp
Owner: Filip Hroch 
Severity: wishlist
X-Debbugs-Cc:debian-de...@lists.debian.org,debian-as...@lists.debian.org

* Package name: Munipack
  Version : 0.5.7
  Upstream Author : Filip Hroch 
* URL : http://munipack.physics.muni.cz/
* License : GPL-3
  Programming Lang: Fortran, C++
  Description : An astronomical photometry software package
   Munipack is a general astronomical photometry software package
   designed for both batch and interactive processing of large
   amount of data. One currently implements functions for image
   preprocessing, aperture and  growth-curve photometry, astrometry 
   and photometry calibration, merge of images, light-curves, 
   partial support for Virtual observatory access, FITS files tool 
   and a graphical interface.

It will be maintained within the Debian Astronomy Working Group. A git
repository will be created on alioth [1].

Best regards,
FH

---
[1] https://anonscm.debian.org/cgit/debian-astro/packages/munipack.git

-- 
F. Hroch  e-mail, jabber: hr...@physics.muni.cz, tel.: +420549494470
Dept. of theor. physics and astrophysics, MU Brno, Kotlarska 2,CZ-611 37

Bug#824615: gtk3-nocsd should nest bash completions

[Christian Seiler]

Control: tags -1 + fixed-upstream

On 05/18/2016 04:46 AM, Christoph Anton Mitterer wrote:
> Would be nice if the gtk-nocsd binary could continue with
> normal completions (if that's possible), or at least
> with binaries from the search path, e.g.:
> 
> $ gtk-nocsd nauti[TAB] => nautilus
> and if natuilus would have option completion like --help, it would
> be nice if that works as well (but as said, not sure whether
> this is easily possible in bash).

This bug is now fixed upstream:
https://github.com/PCMan/gtk3-nocsd/commit/3861bc89b4df3618b358fbc9359ddd9ddd796a9a

Regards,
Christian

Bug#824614: gtk3-nocsd: doesn't add window decorations to all windows

[Christian Seiler]

Control: tags -1 + fixed-upstream

This bug is now fixed upstream:
https://github.com/PCMan/gtk3-nocsd/commit/e9a1e5bf186f2d650ef724b3861d337b7270a400

Regards,
Christian

Bug#824620: gtk3-nocsd: ship /etc/X11/Xsession.d/01-gtk3-nocsd + debconf it?

[Christian Seiler]

Control: tags -1 + pending

On 05/18/2016 05:04 AM, Christoph Anton Mitterer wrote:
> As stated in /u/s/d/gtk3-nocsd there are several
> ways to configure gtk3-nocsd.
> 
> a) I think it would perhaps make sense to ship
>/etc/X11/Xsession.d/01-gtk3-nocsd
>(01-dont-disable-gtk-csd is a somewhat misleading name, obviously
>README.Debian should be adapted to the new name)
>with some documentation (as comments) and the respective
>options (i.e. GTK_CSD and GTK3_NOCSD_IGNORE) as a conf file.
>The advantage over letting the user create this is, that
>it get's also cleaned up when the package is purged and does't
>remain forgotten :)

This is fixed in git on collab-maint, and will be part of the next
upload:

https://anonscm.debian.org/cgit/collab-maint/gtk3-nocsd.git/commit/?id=3d6537753dabfd8eb6f6f8fea54549a795b4e398

Regards,
Christian

Bug#824727: iceowl-l10n-bg: please recommend hunspell-bg as (preferred?) alternative to myspell-bg

[Jonas Smedegaard]

Package: iceowl-l10n-bg
Version: 4.0.0.1-1
Severity: normal
Tags: l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

iceowl-l10n-bg recommends myspell-bg but not the alternative hunspell-bg.

Please recommend hunspell-bg as alternative to myspell-bg.

As I understand it, hunspell has features not in myspell (e.g. related
to combining words which is very common in danish).  If there are no
particular reason to favor myspell-bg (e.g. bigger wordlist) then
hunspell-bg should probably be listed first, i.e. be favored.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPYySAAoJECx8MUbBoAEhJR0QAIjnrPrZfDggQh9+jCW1rcb8
FtH6REQpisMtqgPvY7mnMzFCzXbNe6DV0CfVQ0dUk0VIzEqlLvNo7FJNcgzPMYCw
CqYmEQJQ87gTCjIeIy/BWn/o2cbqdvAgXolRZziD4a1tYe2jMlZ431DRi+WWS1C/
QDYwAtZPdi32+AUvItNBMqZsL/BfgOLYOrSkhc2tmi40odNCfVAcFjFM5IA2Cqi+
ox8nVSzV5LOZ4drSFK6LiPBQePf+fYGXKcbkTpfT6MwOrlwXc9q3ceFUH10Cz5fm
AOsJpB/ydfl+eW/Ew2t39dRx+oUA1Yyt1J76qK2A3g0/OUISIvnj8+Ylyu/zNicM
GO9J4GvmYPNv6B3l8tLOAwD9NwDDHXfv+ULLOvzHqg9UZ175PekhRyaqFavxxgqv
sZDN82APaN8kK5WUQHv+foS8Q7eT3400wCGANsFLQh0EEcB9Lv/XKOwT6L9nCwGH
UTmkMuhwAPephEiXMkfyazecC7inIPzTi2Ck0lGdPFi9LgV4ksd1frMumIvRHaCi
eRPn3Da/v4rFh8dGES5mKpxrNKKHhPieYL4Z/Lu0dIsN1L6ogz9gAETXiRmW9IRL
KW5L7CjNlkKlpbbQjXlOo+TWKE6LXuYhriwSGHgC7LrMTk5SrDoaznC4FuYT9Cmm
WIjhqv6BRLy0B6s1Z3Fk
=jC8p
-END PGP SIGNATURE-

Bug#824048: Any change in blastp? (Was: Bug#824048: python-biopython: FTBFS: AssertionError: 10 != 1)

[Andreas Tille]

Hi Peter,

since some time the blastp test fails when building the Debian BioPython
package.  I've got  no answer what might be wrong here.  Do you have any
idea which is better than deactivating this specific test for the monent
which would be the only poor idea I'd have?

Please let me know if you need more information.

Kind regards

   Andreas.

On Wed, May 11, 2016 at 10:08:49PM +0200, Andreas Tille wrote:
> On Wed, May 11, 2016 at 05:35:27PM +0100, Chris Lamb wrote:
> > ...
> >   Bio.PDB.Selection docstring test ... ok
> >   ==
> >   FAIL: test_blastp (test_NCBI_BLAST_tools.Pairwise)
> >   Pairwise BLASTP search
> >   --
> >   Traceback (most recent call last):
> > File 
> > "/home/lamby/temp/cdt.20160511172943.3m3eRDBdi6.python-biopython/python-biopython-1.66+dfsg/.pybuild/pythonX.Y_2.7/build/Tests/test_NCBI_BLAST_tools.py",
> >  line 103, in test_blastp
> >   self.assertEqual(10, stdoutdata.count("Query= "))
> >   AssertionError: 10 != 1
> >   
> >   --
> >   Ran 228 tests in 101.627 seconds
> >   
> >   FAILED (failures = 1)
> 
> Does any body know about a recent change in blastp?
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#823147: Fixed in 1.3.0-2

[Jonathan McDowell]

I've just upgraded libinput10 to 1.3.0-2 (from 1.3.0-1, which wasn't
working), pulling in libinput-bin and the associated udev rules. This
has fixed middle button emulation for me on my E7420 with ALPS
Glidepoint.

J.

-- 
Revd Jonathan McDowell, ULC | If they can't take a jokefuck 'em.

Bug#824736: rjava: FTBFS: Makefile.all:38: recipe for target 'libjri.so' failed

[Chris Lamb]

Source: rjava
Version: 0.9-8-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

rjava fails to build from source in unstable/amd64:

  [..]

  Adding debian:Root_CA_Generalitat_Valenciana.pem
  Adding debian:S-TRUST_Authentication_and_Encryption_Root_CA_2005_PN.pem
  Adding debian:S-TRUST_Universal_Root_CA.pem
  Adding debian:SecureSign_RootCA11.pem
  Adding debian:SecureTrust_CA.pem
  Adding debian:Secure_Global_CA.pem
  Adding debian:Security_Communication_EV_RootCA1.pem
  Adding debian:Security_Communication_RootCA2.pem
  Adding debian:Security_Communication_Root_CA.pem
  Adding debian:Sonera_Class_1_Root_CA.pem
  Adding debian:Sonera_Class_2_Root_CA.pem
  Adding debian:Staat_der_Nederlanden_EV_Root_CA.pem
  Adding debian:Staat_der_Nederlanden_Root_CA.pem
  Adding debian:Staat_der_Nederlanden_Root_CA_-_G2.pem
  Adding debian:Staat_der_Nederlanden_Root_CA_-_G3.pem
  Adding debian:Starfield_Class_2_CA.pem
  Adding debian:Starfield_Root_Certificate_Authority_-_G2.pem
  Adding debian:Starfield_Services_Root_Certificate_Authority_-_G2.pem
  Adding debian:StartCom_Certification_Authority.pem
  Adding debian:StartCom_Certification_Authority_2.pem
  Adding debian:StartCom_Certification_Authority_G2.pem
  Adding debian:SwissSign_Gold_CA_-_G2.pem
  Adding debian:SwissSign_Platinum_CA_-_G2.pem
  Adding debian:SwissSign_Silver_CA_-_G2.pem
  Adding debian:Swisscom_Root_CA_1.pem
  Adding debian:Swisscom_Root_CA_2.pem
  Adding debian:Swisscom_Root_EV_CA_2.pem
  Adding debian:T-TeleSec_GlobalRoot_Class_2.pem
  Adding debian:T-TeleSec_GlobalRoot_Class_3.pem
  Adding debian:TC_TrustCenter_Class_3_CA_II.pem
  Adding debian:TURKTRUST_Certificate_Services_Provider_Root_2007.pem
  Adding debian:TWCA_Global_Root_CA.pem
  Adding debian:TWCA_Root_Certification_Authority.pem
  Adding debian:Taiwan_GRCA.pem
  Adding debian:TeliaSonera_Root_CA_v1.pem
  Adding debian:Trustis_FPS_Root_CA.pem
  Adding debian:TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.pem
  Adding debian:TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H5.pem
  Adding debian:TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H6.pem
  Adding debian:USERTrust_ECC_Certification_Authority.pem
  Adding debian:USERTrust_RSA_Certification_Authority.pem
  Adding debian:UTN_USERFirst_Email_Root_CA.pem
  Adding debian:UTN_USERFirst_Hardware_Root_CA.pem
  Adding debian:VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.pem
  Adding debian:VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.pem
  Adding debian:VeriSign_Universal_Root_Certification_Authority.pem
  Adding debian:Verisign_Class_1_Public_Primary_Certification_Authority.pem
  Adding debian:Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.pem
  Adding debian:Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
  Adding debian:Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.pem
  Adding debian:Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority_2.pem
  Adding debian:Visa_eCommerce_Root.pem
  Adding debian:WellsSecure_Public_Root_Certificate_Authority.pem
  Adding debian:WoSign.pem
  Adding debian:WoSign_China.pem
  Adding debian:XRamp_Global_CA_Root.pem
  Adding debian:certSIGN_ROOT_CA.pem
  Adding debian:ePKI_Root_Certification_Authority.pem
  Adding debian:thawte_Primary_Root_CA.pem
  Adding debian:thawte_Primary_Root_CA_-_G2.pem
  Adding debian:thawte_Primary_Root_CA_-_G3.pem
  done.
  done.
  Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.34.0-1) ...
   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: info: source package rjava
  dpkg-buildpackage: info: source version 0.9-8-2
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Dirk Eddelbuettel 
   dpkg-source --before-build rjava-0.9-8
  dpkg-buildpackage: info: host architecture amd64
   fakeroot debian/rules clean
  CDBS WARNING:simple-patchsys.mk is deprecated since 0.4.85 - please use 
source format 3.0 (quilt) instead
  test -x debian/rules
  /usr/bin/make -f debian/rules reverse-config
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160519114259.i7R4hRYI37.rjava/rjava-0.9-8'
  CDBS WARNING:simple-patchsys.mk is deprecated since 0.4.85 - please use 
source format 3.0 (quilt) instead
  set -e;
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160519114259.i7R4hRYI37.rjava/rjava-0.9-8'
  if [ "reverse-patches" = "reverse-patches" ]; then rm -f 
debian/stamp-patched; fi
  patches: 
  if [ "reverse-patches" != 

Bug#824737: ruby-albino: FTBFS: expected to not match

[Chris Lamb]

Source: ruby-albino
Version: 1.3.3-4
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ruby-albino fails to build from source in unstable/amd64:

  [..]

  Reading state information...
  Correcting dependencies... Done
  The following additional packages will be installed:
ca-certificates gem2deb gem2deb-test-runner libgmp-dev libgmpxx4ldbl
libruby2.3 libyaml-0-2 openssl python-pygments python3-chardet
python3-debian python3-pkg-resources python3-six rake ruby ruby-all-dev
ruby-did-you-mean ruby-metaclass ruby-minitest ruby-mocha ruby-net-telnet
ruby-posix-spawn ruby-power-assert ruby-setup ruby-test-unit ruby2.3
ruby2.3-dev rubygems-integration
  Suggested packages:
gmp-doc libgmp10-doc libmpfr-dev ttf-bitstream-vera python3-setuptools ri
ruby-dev ruby-mocha-doc bundler
  Recommended packages:
apt-file python-chardet python3-apt zip fonts-lato libjs-jquery
  The following NEW packages will be installed:
ca-certificates gem2deb gem2deb-test-runner libgmp-dev libgmpxx4ldbl
libruby2.3 libyaml-0-2 openssl python-pygments python3-chardet
python3-debian python3-pkg-resources python3-six rake ruby ruby-all-dev
ruby-did-you-mean ruby-metaclass ruby-minitest ruby-mocha ruby-net-telnet
ruby-posix-spawn ruby-power-assert ruby-setup ruby-test-unit ruby2.3
ruby2.3-dev rubygems-integration
  0 upgraded, 28 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  Need to get 7249 kB of archives.
  After this operation, 28.8 MB of additional disk space will be used.
  Get:1 http://httpredir.debian.org/debian sid/main amd64 openssl amd64 
1.0.2h-1 [681 kB]
  Get:2 http://httpredir.debian.org/debian sid/main amd64 ca-certificates all 
20160104 [200 kB]
  Get:3 http://httpredir.debian.org/debian sid/main amd64 rubygems-integration 
all 1.10 [4882 B]
  Get:4 http://httpredir.debian.org/debian sid/main amd64 ruby-did-you-mean all 
1.0.0-2 [11.2 kB]
  Get:5 http://httpredir.debian.org/debian sid/main amd64 ruby-minitest all 
5.8.4-2 [50.3 kB]
  Get:6 http://httpredir.debian.org/debian sid/main amd64 ruby-net-telnet all 
0.1.1-2 [12.5 kB]
  Get:7 http://httpredir.debian.org/debian sid/main amd64 ruby-power-assert all 
0.2.7-1 [7578 B]
  Get:8 http://httpredir.debian.org/debian sid/main amd64 ruby-test-unit all 
3.1.7-2 [69.6 kB]
  Get:9 http://httpredir.debian.org/debian sid/main amd64 libyaml-0-2 amd64 
0.1.6-3 [50.4 kB]
  Get:10 http://httpredir.debian.org/debian sid/main amd64 libruby2.3 amd64 
2.3.1-1 [3098 kB]
  Get:11 http://httpredir.debian.org/debian sid/main amd64 ruby2.3 amd64 
2.3.1-1 [177 kB]
  Get:12 http://httpredir.debian.org/debian sid/main amd64 ruby amd64 1:2.3.0+4 
[10.5 kB]
  Get:13 http://httpredir.debian.org/debian sid/main amd64 rake all 10.5.0-2 
[49.4 kB]
  Get:14 http://httpredir.debian.org/debian sid/main amd64 gem2deb-test-runner 
all 0.30.1 [19.4 kB]
  Get:15 http://httpredir.debian.org/debian sid/main amd64 
python3-pkg-resources all 20.10.1-1 [112 kB]
  Get:16 http://httpredir.debian.org/debian sid/main amd64 python3-chardet all 
2.3.0-2 [96.0 kB]
  Get:17 http://httpredir.debian.org/debian sid/main amd64 python3-six all 
1.10.0-3 [14.4 kB]
  Get:18 http://httpredir.debian.org/debian sid/main amd64 python3-debian all 
0.1.27 [50.9 kB]
  Get:19 http://httpredir.debian.org/debian sid/main amd64 libgmpxx4ldbl amd64 
2:6.1.0+dfsg-2 [22.2 kB]
  Get:20 http://httpredir.debian.org/debian sid/main amd64 libgmp-dev amd64 
2:6.1.0+dfsg-2 [628 kB]
  Get:21 http://httpredir.debian.org/debian sid/main amd64 ruby2.3-dev amd64 
2.3.1-1 [1169 kB]
  Get:22 http://httpredir.debian.org/debian sid/main amd64 ruby-all-dev amd64 
1:2.3.0+4 [9996 B]
  Get:23 http://httpredir.debian.org/debian sid/main amd64 ruby-setup all 
3.4.1-9 [34.2 kB]
  Get:24 http://httpredir.debian.org/debian sid/main amd64 gem2deb all 0.30.1 
[55.3 kB]
  Get:25 http://httpredir.debian.org/debian sid/main amd64 python-pygments all 
2.1.3+dfsg-1 [535 kB]
  Get:26 http://httpredir.debian.org/debian sid/main amd64 ruby-metaclass all 
0.0.4-1 [3768 B]
  Get:27 http://httpredir.debian.org/debian sid/main amd64 ruby-mocha all 
1.1.0-2 [52.7 kB]
  Get:28 http://httpredir.debian.org/debian sid/main amd64 ruby-posix-spawn 
amd64 0.3.11-1+b2 [24.6 kB]
  Fetched 7249 kB in 0s (54.1 MB/s)
  Selecting previously unselected package openssl.
  (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 

Bug#824745: gv: segmentation fault when zooming on an empty document

[Vincent Lefevre]

Package: gv
Version: 1:3.7.4-1
Severity: normal

gv crashes (segmentation fault) when zooming on an empty document.
To reproduce:

1. Start gv with no arguments.
2. Over the white area, click with the left button.
3. Click oon any item of the zoom menu, e.g. on 2.

Debugging information:

Program received signal SIGSEGV, Segmentation fault.
0x0042e989 in ?? ()
(gdb) bt full
#0  0x0042e989 in ?? ()
No symbol table info available.
#1  0x0041b22e in ?? ()
No symbol table info available.
#2  0x7752daad in HandleActions (w=w@entry=0x6fadc0, 
event=0x7fffcda0, accelWidget=, procs=0x6fafb8, 
actions=actions@entry=0x6d0da0, stateTree=)
at ../../src/TMstate.c:644
actionHookList = 0x0
bindWidget = 
#3  0x7752df15 in HandleSimpleState (w=w@entry=0x6fadc0, 
tmRecPtr=tmRecPtr@entry=0x6fae08, 
curEventPtr=curEventPtr@entry=0x7fffc9b0) at ../../src/TMstate.c:883
bindData = 
procs = 
accelWidget = 
xlations = 0x6e79d0
stateTree = 
contextPtr = 0x6fae18
i = 1
actions = 0x6d0da0
matchExact = 1 '\001'
match = 
complexMatchState = 0x0
currIndex = -2
typeIndex = 76
modIndex = 0
matchTreeIndex = 
#4  0x7752ebdd in _XtTranslateEvent (w=w@entry=0x6fadc0, 
event=event@entry=0x7fffcda0) at ../../src/TMstate.c:1101
tmRecPtr = 0x6fae08
curEvent = {xev = 0x7fffcda0, event = {modifiers = 0, 
modifierMask = 0, lateModifiers = 0x0, eventType = 4, 
eventCode = 1, eventCodeMask = 0, matchEvent = 0x0, 
standard = 0 '\000'}}
current_state = 
#5  0x77506ef2 in XtDispatchEventToWidget (
widget=widget@entry=0x6fadc0, event=event@entry=0x7fffcda0)
at ../../src/Event.c:906
p = 
was_dispatched = 0 '\000'
call_tm = 
cont_to_disp = 1 '\001'
mask = 
app = 
#6  0x775078dd in _XtDefaultDispatcher (event=0x7fffcda0)
at ../../src/Event.c:1367
mask = 4
dspWidget = 0x6fadc0
was_filtered = 
widget = 0x6fadc0
grabType = remap
pdi = 0x676130
grabList = 0x6faf80
was_dispatched = 0 '\000'
app = 
#7  0x775079b9 in XtDispatchEvent (event=event@entry=0x7fffcda0)
at ../../src/Event.c:1423
was_dispatched = 
safe = 
dispatch_level = 1
starting_count = 0
pd = 
time = 
dispatch = 
app = 0x665550
#8  0x7751366f in XtAppProcessEvent (app=app@entry=0x665550, 
mask=mask@entry=15) at ../../src/NextEvent.c:1397
i = 
cur_time = {tv_sec = 0, tv_usec = 6706512}
d = 0
event = {type = 4, xany = {type = 4, serial = 2677, send_event = 0, 
display = 0x666a90, window = 60817846}, xkey = {type = 4, 
serial = 2677, send_event = 0, display = 0x666a90, 
window = 60817846, root = 678, subwindow = 0, time = 10226550, 
x = 47, y = 17, x_root = 1773, y_root = 320, state = 0, 
keycode = 1, same_screen = 1}, xbutton = {type = 4, serial = 2677, 
send_event = 0, display = 0x666a90, window = 60817846, root = 678, 
subwindow = 0, time = 10226550, x = 47, y = 17, x_root = 1773, 
y_root = 320, state = 0, button = 1, same_screen = 1}, xmotion = {
type = 4, serial = 2677, send_event = 0, display = 0x666a90, 
window = 60817846, root = 678, subwindow = 0, time = 10226550, 
x = 47, y = 17, x_root = 1773, y_root = 320, state = 0, 
is_hint = 1 '\001', same_screen = 1}, xcrossing = {type = 4, 
serial = 2677, send_event = 0, display = 0x666a90, 
window = 60817846, root = 678, subwindow = 0, time = 10226550, 
x = 47, y = 17, x_root = 1773, y_root = 320, mode = 0, detail = 1, 
same_screen = 1, focus = 0, state = 0}, xfocus = {type = 4, 
serial = 2677, send_event = 0, display = 0x666a90, 
window = 60817846, mode = 678, detail = 0}, xexpose = {type = 4, 
serial = 2677, send_event = 0, display = 0x666a90, 
window = 60817846, x = 678, y = 0, width = 0, height = 0, 
count = 10226550}, xgraphicsexpose = {type = 4, serial = 2677, 
send_event = 0, display = 0x666a90, drawable = 60817846, x = 678, 
y = 0, width = 0, height = 0, count = 10226550, major_code = 0, 
minor_code = 47}, xnoexpose = {type = 4, serial = 2677, 
send_event = 0, display = 0x666a90, drawable = 60817846, 
major_code = 678, minor_code = 0}, xvisibility = {type = 4, 
serial = 2677, send_event = 0, display = 0x666a90, 
window = 60817846, state = 678}, xcreatewindow = {type = 4, 
serial = 2677, send_event = 0, display = 0x666a90, 
parent = 

Bug#824276: Another one "Something has gone wrong" bug with xrdp

[Vincent Bernat]

 ❦ 18 mai 2016 04:09 +0300, Maxim K  :

> xrdp-sesman.log
>
> [20160518-03:56:32] [CORE ] starting sesman with pid 20469
> [20160518-03:56:32] [INFO ] listening...
> [20160518-03:56:41] [INFO ] scp thread on sck 7 started successfully
> [20160518-03:56:41] [INFO ] ++ created session (access granted):
> username max, ip 192.168.0.2:27048 - socket: 7
> [20160518-03:56:42] [INFO ] starting Xvnc session...
> [20160518-03:56:42] [INFO ] starting xrdp-sessvc - xpid=20504 - wmpid=20503
>
>
> Honestly I have no idia which logs to look either. According to this
> one everything is fine with xrdp itself and the problem on the gnome
> side or something.

The bug is unlikely in xrdp since it doesn't contain the string "gone
wrong". You could look at ~/.xsession which may contains more
appropriate logs.

You also need to reaffect the bug properly to an existing package as it
is currently assigned to no package due to the way the Package field was
filed.
-- 
Many pages make a thick book.


signature.asc
Description: PGP signature

Bug#823478: python3-protobuf3

[Mattia Rizzolo]

On Thu, May 19, 2016 at 02:52:27PM +1000, Jonathon Love wrote:
> so the advice i received regarding the name was that i must get it renamed
> upstream[1]. i don't think this will be possible because:
> 
>  - upstream is an established package, present in PYPI and macports
>  - the developer is MIA

this "developer is MIA" should be a good reason by itself.  It's never
great to introduce in the archive a software where the development
stopped.

> (additionally, the official Protocol Buffers 3 supports Python 3 [2] and
> should be coming to debian soon[3]. as the main point of this package was to
> allow the use of protocol buffers with Python 3, this reduces the need for
> this package).

Agree.
Also, introducing both would mean having in the archive 2 things that do
the exact same thing.

> hence, i propose to withdraw the package, the RFS and the ITP.

This seems the better solution, yes.

> also happy to
> proceed, the work is basically done, but i can't see a way to make it work.

For all the reason you exponed, I think the best way is to withdraw the
package.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#824729: task-bulgarian-desktop: please recommend hunspell-bg as (preferred?) alternative to myspell-bg

[Jonas Smedegaard]

Package: task-bulgarian-desktop
Version: 3.34
Severity: normal
Tags: l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

task-bulgarian-desktop recommends myspell-bg but not hunspell-bg.

Please recommend hunspell-bg as alternative to myspell-bg.

As I understand it, hunspell has features not in myspell (e.g. related
to combining words which is very common in danish).  If there are no
particular reason to favor myspell-bg (e.g. bigger wordlist) then
hunspell-bg should probably be listed first.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPZLXAAoJECx8MUbBoAEhJwgP/0NmbtTk8cK+dRaSDkneHMAH
uymluwe6CmgaacAylIE5yk2Cdnp4LGxFd3BeJEc96UUoj/Gflcg3DVONiFqsyQR4
2jSHZ4KrNh7gxMYbDrXZ+lh3uIboGxTw58RY9FcHTa1FPD2EqB6xxEGYPPNsEaU8
+efQ++/x2+L5jOx2OkwbNxnHV++txh7DELBrf+FBdzwi3TCbKBporUUyHhYHWWIG
BERpgsD0J58Zec7gjaXmRoNDUzqx9/0LQ5Uhi7LuJYQqH1nlo0vZ9Y2IVPneaZ9a
cwK0Cz891lAACRXzkV/qAs+tyDsyuFTHFhf4qo1hWkA4sLsytLE3xWDdaGQOZmsS
bdcDrb5gbFEDW/KbKGFsFc5zgfzcF0s+Pt+oeqlesBrtn+SG1PdbAyL8Hwi9OBs+
JGKHyS7S5bUPy1yVMPBntLBgnaIAFNEZuQybYRnZ/DeVYiB9FQGm3MntiM1cKhPX
VVjstN5iDp1130UbSXOH6e31Zuj0zZQtpUti9cv/EHgDVa3ypwbA5Sgdvtn3N6Ue
XWE9oH4aIJHCl0np5cJP3VHSMRSVOPuoSljMdVr+J26fxpuuFCmhyQcC/rlBkrT7
E6exjaA0WTq9LfZElB3yajIyqVxW1NhcBClR6p3s7qxGGWOThqr01MNeaqVOaome
96aKF3z5Vw9LtEG9jhJL
=xF4d
-END PGP SIGNATURE-

Bug#824740: telepathy-ring: FTBFS: cp: cannot stat './AUTHORS--no-act': No such file or directory

[Chris Lamb]

Source: telepathy-ring
Version: 2.1.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

telepathy-ring fails to build from source in unstable/amd64:

  [..]

  # source='ring-conference-channel.c' object='ring-conference-channel.lo' 
libtool=yes 
  /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. 
-I.. -I../tests -I..  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread 
-I/usr/include/telepathy-1.0 -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -c -o ring-conference-channel.lo 
ring-conference-channel.c
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -I.. 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wall -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread 
-I/usr/include/telepathy-1.0 -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -c ring-conference-channel.c -o 
ring-conference-channel.o
  ring-conference-channel.c: In function 'ring_mergeable_conference_merge':
  ring-conference-channel.c:208:5: warning: 'tp_errors_quark' is deprecated: 
Use 'TP_ERROR' instead [-Wdeprecated-declarations]
   error = g_error_new(TP_ERRORS, TP_ERROR_INVALID_ARGUMENT,
   ^
  In file included from /usr/include/telepathy-1.0/telepathy-glib/handle.h:31:0,
   from 
/usr/include/telepathy-1.0/telepathy-glib/handle-repo.h:36,
   from 
/usr/include/telepathy-1.0/telepathy-glib/group-mixin.h:31,
   from ring-media-channel.h:26,
   from ring-conference-channel.h:35,
   from ring-conference-channel.c:40:
  /usr/include/telepathy-1.0/telepathy-glib/errors.h:39:8: note: declared here
   GQuark tp_errors_quark (void);
  ^
  ring-conference-channel.c: In function 
'ring_conference_channel_remove_member_with_reason':
  ring-conference-channel.c:630:5: warning: 'tp_errors_quark' is deprecated: 
Use 'TP_ERROR' instead [-Wdeprecated-declarations]
   g_set_error(error, TP_ERRORS, TP_ERROR_PERMISSION_DENIED,
   ^
  In file included from /usr/include/telepathy-1.0/telepathy-glib/handle.h:31:0,
   from 
/usr/include/telepathy-1.0/telepathy-glib/handle-repo.h:36,
   from 
/usr/include/telepathy-1.0/telepathy-glib/group-mixin.h:31,
   from ring-media-channel.h:26,
   from ring-conference-channel.h:35,
   from ring-conference-channel.c:40:
  /usr/include/telepathy-1.0/telepathy-glib/errors.h:39:8: note: declared here
   GQuark tp_errors_quark (void);
  ^
  ring-conference-channel.c: In function 'ring_conference_channel_join':
  ring-conference-channel.c:921:5: warning: 'tp_errors_quark' is deprecated: 
Use 'TP_ERROR' instead [-Wdeprecated-declarations]
   g_set_error(error, TP_ERRORS, TP_ERROR_INVALID_ARGUMENT,
   ^
  In file included from /usr/include/telepathy-1.0/telepathy-glib/handle.h:31:0,
   from 
/usr/include/telepathy-1.0/telepathy-glib/handle-repo.h:36,
   from 
/usr/include/telepathy-1.0/telepathy-glib/group-mixin.h:31,
   from ring-media-channel.h:26,
   from ring-conference-channel.h:35,
   from ring-conference-channel.c:40:
  /usr/include/telepathy-1.0/telepathy-glib/errors.h:39:8: note: declared here
   GQuark tp_errors_quark (void);
  ^
  ring-conference-channel.c: In function 'ring_conference_channel_release':
  ring-conference-channel.c:1039:10: warning: variable 'details' set but not 
used [-Wunused-but-set-variable]
 int i, details;
^
  ring-conference-channel.c: In function 
'ring_conference_channel_validate_media_handle':
  ring-conference-channel.c:1150:5: warning: 'tp_errors_quark' is deprecated: 
Use 'TP_ERROR' instead [-Wdeprecated-declarations]
   g_set_error(error, TP_ERRORS, TP_ERROR_INVALID_ARGUMENT,
   ^
  In file included from /usr/include/telepathy-1.0/telepathy-glib/handle.h:31:0,
   from 
/usr/include/telepathy-1.0/telepathy-glib/handle-repo.h:36,
   from 
/usr/include/telepathy-1.0/telepathy-glib/group-mixin.h:31,
   from ring-media-channel.h:26,
   from 

Bug#824739: telepathy-haze: FTBFS: media-stream.c:1079:20: error: 'PURPLE_MEDIA_NETWORK_PROTOCOL_TCP' undeclared

[Chris Lamb]

Source: telepathy-haze
Version: 0.8.0-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

telepathy-haze fails to build from source in unstable/amd64:

  [..]

  Setting up gir1.2-telepathyglib-0.12 (0.24.1-1.1) ...
  Setting up libtelepathy-glib-dev (0.24.1-1.1) ...
  Setting up libxslt1.1:amd64 (1.1.28-3) ...
  Setting up xsltproc (1.1.28-3) ...
  Setting up libgtk-3-bin (3.20.4-1) ...
  Setting up adwaita-icon-theme (3.20-2) ...
  update-alternatives: using /usr/share/icons/Adwaita/cursor.theme to provide 
/usr/share/icons/default/index.theme (x-cursor-theme) in auto mode
  Setting up libgtk-3-common (3.20.4-1) ...
  Setting up libgtk-3-0:amd64 (3.20.4-1) ...
  Setting up gstreamer1.0-plugins-bad:amd64 (1.8.1-2) ...
  Setting up libfarstream-0.2-5:amd64 (0.2.7-1) ...
  Setting up libpurple0 (2.10.12-1) ...
  Setting up libpurple-dev (2.10.12-1) ...
  Setting up telepathy-haze-build-deps (0.8.0-2) ...
  Processing triggers for libc-bin (2.22-9) ...
  Processing triggers for systemd (229-6) ...
  Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.34.0-1) ...
   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: info: source package telepathy-haze
  dpkg-buildpackage: info: source version 0.8.0-2
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Simon McVittie 
   dpkg-source --before-build telepathy-haze-0.8.0
  dpkg-buildpackage: info: host architecture amd64
   fakeroot debian/rules clean
  dh clean --with autoreconf --parallel
 dh_testdir -O--parallel
 dh_auto_clean -O--parallel
 dh_autoreconf_clean -O--parallel
 dh_clean -O--parallel
   debian/rules build
  dh build --with autoreconf --parallel
 dh_testdir -O--parallel
 dh_update_autotools_config -O--parallel
 dh_autoreconf -O--parallel
  libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
  libtoolize: copying file 'build-aux/ltmain.sh'
  libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
  libtoolize: copying file 'm4/libtool.m4'
  libtoolize: copying file 'm4/ltoptions.m4'
  libtoolize: copying file 'm4/ltsugar.m4'
  libtoolize: copying file 'm4/ltversion.m4'
  libtoolize: copying file 'm4/lt~obsolete.m4'
  configure.ac:42: installing 'build-aux/compile'
  configure.ac:27: installing 'build-aux/missing'
  extensions/Makefile.am:13: warning: source file '_gen/signals-marshal.c' is 
in a subdirectory,
  extensions/Makefile.am:13: but option 'subdir-objects' is disabled
  automake: warning: possible forward-incompatibility.
  automake: At least a source file is in a subdirectory, but the 
'subdir-objects'
  automake: automake option hasn't been enabled.  For now, the corresponding 
output
  automake: object file(s) will be placed in the top-level directory.  However,
  automake: this behaviour will change in future Automake versions: they will
  automake: unconditionally cause object files to be placed in the same 
subdirectory
  automake: of the corresponding sources.
  automake: You are advised to start using 'subdir-objects' option throughout 
your
  automake: project, to avoid future incompatibilities.
  extensions/Makefile.am:13: warning: source file '_gen/svc.c' is in a 
subdirectory,
  extensions/Makefile.am:13: but option 'subdir-objects' is disabled
  extensions/Makefile.am: installing 'build-aux/depcomp'
 debian/rules override_dh_auto_configure
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160519114732.70HUuJxhub.telepathy-haze/telepathy-haze-0.8.0'
  dh_auto_configure -- \
--libexecdir="\${prefix}/lib/telepathy" \

./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking --libexecdir=\${prefix}/lib/telepathy
  configure: WARNING: unrecognized options: --disable-maintainer-mode
  checking for a BSD-compatible install... /usr/bin/install -c
  checking whether build environment is sane... yes
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  checking for gawk... no
  checking for mawk... mawk
  checking whether make sets $(MAKE)... yes
  checking whether make supports nested variables... yes
  checking whether make supports nested variables... (cached) yes
  checking for gcc... gcc
  checking whether the C compiler works... yes
  checking for C compiler default output file name... a.out
  checking for suffix of executables... 
  checking whether we are cross compiling... no
  checking for suffix of object files... o
  checking whether we are using the GNU C compiler... yes
  checking whether gcc accepts -g... yes
  checking 

Bug#669856: iptotal: transition towards Apache 2.4

[Jean-Michel Vourgère]

Control: tags -1 + patch

Hello Ignace

Attached is a patch for #669856

Also available  at https://github.com/ghantoos/debian-iptotal/pull/1
(Beware postrm is removed and not emptied)

Ping me if you need a sponsor.
commit 728020da9537f720cefff974d1fcb2289faec362
Author: Jean-Michel Vourgère 
Date:   Thu May 19 11:23:16 2016 +0200

Migate to apache2.4 (#669856)

diff --git a/debian/README.debian b/debian/README.debian
index 2968c93..c7ab309 100644
--- a/debian/README.debian
+++ b/debian/README.debian
@@ -1,11 +1,3 @@
-Using iptotal with Apache2:

-An apache configuration file template is shipped with this package. In order to
-use it, it should be symlinked inside apache2's configuration folder:
-  $ sudo ln -s /etc/iptotal/apache.conf /etc/apache2/conf.d/
-Then reload apache2 configuration:
-  $ sudo /etc/init.d/apache2 reload
-
 Note concerning iptotal's data directory:
 -
 Some important changes have been applied to iptotal's data directory over the
diff --git a/debian/apache.conf b/debian/apache.conf
deleted file mode 100644
index 0fd7805..000
--- a/debian/apache.conf
+++ /dev/null
@@ -1,9 +0,0 @@
-Alias /iptotal /var/lib/iptotal/
-
-
-Options +FollowSymLinks
-AllowOverride None
-order allow,deny
-allow from all
-DirectoryIndex template.html
-
diff --git a/debian/control b/debian/control
index fc81377..b8b635e 100644
--- a/debian/control
+++ b/debian/control
@@ -3,20 +3,25 @@ Section: admin
 Priority: extra
 Maintainer: Ignace Mouzannar 
 DM-Upload-Allowed: yes
-Build-Depends: debhelper (>= 7.0.50~), libpcap-dev, rrdtool, autotools-dev 
(>=20100122.1)
+Build-Depends: autotools-dev (>=20100122.1),
+   debhelper (>= 7.0.50~),
+   dh-apache2,
+   libpcap-dev,
+   rrdtool
 Standards-Version: 3.9.2
 Homepage: http://sourceforge.net/projects/iptotal
 
 Package: iptotal
 Architecture: any
-Depends: rrdtool, tcpdump, apache2 | httpd, ${shlibs:Depends}, ${misc:Depends}
+Depends: rrdtool, tcpdump, ${misc:Depends}, ${shlibs:Depends}
+Recommends: ${misc:Recommends}
 Description: monitor for IP traffic, not requiring SNMP
  iptotal is yet another IP traffic monitor. It listens to a network interface 
in
  non-promiscuous mode, and measures IP bandwidth usage. After the specified
  number of seconds, the average throughput is printed at total, input and 
output
  usage.
- . 
+ .
  The utility can be used to measure bandwidth usage without the need for an 
SNMP
  daemon.  In combination with a simple script and rrdtool it can be used to
  present the measured data in graphical format e.g. through a web interface.
- The package contains www + CGI sample files. 
+ The package contains www + CGI sample files.
diff --git a/debian/install b/debian/install
index 2344372..47e35c7 100644
--- a/debian/install
+++ b/debian/install
@@ -1,3 +1,2 @@
-debian/apache.conf /etc/iptotal/
 debian/iptotal/var/lib/iptotal/template.html /usr/share/iptotal/www/
 debian/iptotal/var/lib/iptotal/images/ /usr/share/iptotal/www/
diff --git a/debian/iptotal.apache2 b/debian/iptotal.apache2
new file mode 100644
index 000..db3cf62
--- /dev/null
+++ b/debian/iptotal.apache2
@@ -0,0 +1 @@
+conf debian/iptotal.conf
diff --git a/debian/iptotal.conf b/debian/iptotal.conf
new file mode 100644
index 000..4e2c0b8
--- /dev/null
+++ b/debian/iptotal.conf
@@ -0,0 +1,8 @@
+Alias /iptotal /var/lib/iptotal/
+
+
+Options +FollowSymLinks
+AllowOverride None
+Require all granted
+DirectoryIndex template.html
+
diff --git a/debian/postinst b/debian/postinst
index e382ae8..fb67bf7 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -47,7 +47,13 @@ case "$1" in
 done
 
 # change ownership to www-data
-   chown -R www-data:www-data /var/lib/iptotal/*
+chown -R www-data:www-data /var/lib/iptotal/*
+
+# enable cgi
+if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
+. /usr/share/apache2/apache2-maintscript-helper
+apache2_invoke enmod cgi
+fi
;;
 
abort-upgrade|abort-remove|abort-deconfigure)
diff --git a/debian/postrm b/debian/postrm
deleted file mode 100644
index 1719405..000
--- a/debian/postrm
+++ /dev/null
@@ -1,23 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   purge|remove)
-   # reload apache2 configuration
-   invoke-rc.d apache2 reload
-   ;;
-
-   upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
-
-   ;;
-
-   *) 
-   echo "postrm called with unknown argument \`$1'" >&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
-
-exit 0
diff --git a/debian/rules b/debian/rules
index dca67c1..68a0e33 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-   dh --with autotools_dev $@
+   dh $@ --with autotools_dev,apache2
 
 override_dh_auto_configure:

Bug#824743: hfsplus: Lower/Uppercase issue, remembering casing after removal

[Tim Ruehsen]

Package: hfsplus
Version: 1.0.4-13
Severity: normal

Dear Maintainer,

in freshly created directory on a HFS+ mount, I experience the following:

$ mkdir xxx && cd xxx
$ touch DUMMY.TXT
$ ls
DUMMY.TXT
$ rm DUMMY.TXT
$ touch dummy.txt
$ ls
DUMMY.TXT

This should be dummy.txt, looks like HFS+ 'remembers' old casing.
Now the other way round:

$ cd ..
$ rm -rf xxx
$ mkdir xxx && cd xxx
$ touch dummy.txt
$ ls
dummy.txt
$ rm dummy.txt
$ touch DUMMY.TXT
$ ls
dummy.txt

This issue disturbs a test suite here (Wget2 development, testing 
uppercase/lowercase stuff).
I could work around it by re-creating a new temp directory for each test, but
I find this HFS+ behaviour somewhat unexpected.

How I created my HFS+ mount:
$ sudo apt-get install hfsprogs
$ dd if=/dev/zero of=hfsimage bs=512 count=500k
$ sudo losetup /dev/loop0 hfsimage
$ sudo mkfs -t hfsplus /dev/loop0
$ sudo mount -t hfsplus /dev/loop0 /mnt
$ cd /mnt
$ sudo mkdir test
$ sudo chown tim:users test
$ cd test

(amend 'tim:users' to your environment)

Regards, Tim

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

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

Versions of packages hfsplus depends on:
ii  libc6 2.22-9
ii  libhfsp0  1.0.4-13

hfsplus recommends no packages.

hfsplus suggests no packages.

-- no debconf information

Bug#824742: dpkg: Please add arm64ilp32 to cputable

[Wookey]

Package: dpkg
Version: 1.18.7
Severity: wishlist

There is a new ABI for arm64 which is the equivalent of x32 on amd64.
It uses the armv8 instruction set for a 32-bit ABI (32-bit
instructions, longs and pointers). Generally referred-to is 'ILP32' in
comparison to the 'LP64' standard arm64 ABI.

This is only expected to be used in quite rare circumstances, but we
do want to make it possible to build in a debian or debian-derived
context, which needs dpkg support.

Attached is a patch to provide that. It also add existing arm64
big-endian so that people can 'easily' build that too if need be.

diff -Nru dpkg-1.18.1/cputable dpkg-1.18.1+nmu1/cputable
--- dpkg-1.18.1/cputable2015-05-22 01:17:44.0 +0100
+++ dpkg-1.18.1+nmu1/cputable   2015-06-18 02:12:22.0 +0100
@@ -21,6 +21,8 @@
 armeb  armeb   arm.*b  32  big
 armarm arm.*   32  little
 arm64  aarch64 aarch64 64  little
+arm64beaarch64_be  aarch64_be  64  big
+arm64ilp32 aarch64 aarch64_ilp32   32  little
+arm64ilp32be   aarch64_be  aarch64_be_ilp3232  big
 avr32  avr32   avr32   32  big
 hppa   hppahppa.*  32  big
 m32r   m32rm32r32  big

Bug#822210: sdl2-config.cmake: extra leading / trailing whitespace

[Manuel A. Fernandez Montecelo]

Hi!

2016-05-01 15:42 Manuel A. Fernandez Montecelo:


If it needs this change, I think that my solution is not very robust
and that the assumptions made don't work and can fail in other cases.


So I've been fighting with this for a while this morning and couldn't
get it to work as originally intended.  In the end, I uploaded a new
version of the package with the patch stripping only the SDL2_LIBRARIES
variable.

If other vars contain whitespace in the future it will not work, but
that's fundamentally a problem with upstream...  I submitted the patch
for their consideration in any case.

It would be great if you can verify that this works fine in your system,
but I am quite confident that it does so I published the new release to
the archive already -- lest it slips through the cracks and it's delayed
for a few more weeks.


Cheers.
--
Manuel A. Fernandez Montecelo