Bug#828105: mv2120-recovery-image doesn't work with marvell kernels

[Martin Michlmayr]

Package: mv2120-utils
Version: 0.4

mv2120-recovery-image assumes the kernel ends with -orion5x but
nowadays we use the -marvell kernel.

root@debian:~# mv2120-recovery-image
Can't find kernel /boot/vmlinuz-4.6.0-1-marvell-orion5x

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

Hello Jerome,

> You are right.
> Meanwhile I added an entry in my TODO list concerning this package.
> I also noticed that there is two flag-file on my box: I would say that one is 
> enough,
> but I cannot say more right now because I am not familiar with this part of 
> the code.
> (In the past, I mainly add new key types support)

I downloaded the pam-ssh module and gave it a quick look: it would
seem that there is one general flag-file per user, _plus_ one
flag-file per login (so if you log in in two ttys you'd have three
flag files).

Also I see that the flag files to store the information about the
agent PID and socket location, so it should be relatively easy for
pam-ssh to check if the agent in question is actually running.

Thanks again for your time,

-- 
Giuseppe "Oblomov" Bilotta

Bug#828043: Sparc and "Invalid Release file, no entry for main/binary-sparc/Packages"

[Michael Tokarev]

24.06.2016 13:50, Jeffrey Walton wrote:
[sparc architecture]

> Why does the Ports page (https://www.debian.org/ports/) list it as an
> official port if its not supported?

I don't know.  Sparc architecture has been dropped in jessie, maybe
even in wheezy, I don't remember already, and dropped in a way that
it didn't land in ports.debian.org.  Sparc64 hasn't been a release
architecture for a few releases too, but it is still present and
kind of supported in ports.d.o.  You can file a bug against
www.debian.org pseudo-package to sort this out, but this obviously
have nothing to do with debootstrap or qemu.

> Why is there an interpreter for it when `update-binfmts --display`?

There are many interpreters registered by qemu.  In there, there are
multiple architectures which has never been supported by debian at
all.  This does not mean there's no need or way to run binaries for
these platrorms.

> Its kind of a waste of time then (q.v.). Sorry about the extra noise.

Well, everything is a waste of time in the end.. or not. :)

Thanks,

/mjt

Bug#828104: RFS: sollya/5.0+ds-1 [ITP] -- library for safe floating-point code development

[Jerome Benoit]

Package: sponsorship-requests
Severity: wishlist

Dear Sponsors,

I am looking for sponsorship for the Debian package sollya [1], an
advanced numnerical tool which comes with an interactive interface
and a library. It targets floatting-point code development.
This package was packaged on behalf of the Debian Science Team.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/sollya.git


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

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#828103: needrestart: false positive: pulseaudio: orcexec files in /run

[Paul Wise]

Package: needrestart
Version: 2.8-1
Severity: normal

There is a false positive with pulseaudio and files in /run:

needrestart output:
# needrestart -v
...
[main] #1976 uses deleted /run/user/1000/orcexec.nXwDNz
[main] #1976 is not a child
...
[main] #1976 exe => /usr/bin/pulseaudio
[main] #1976 part of user session: uid=1000 sess=2
...
User sessions running outdated binaries:
 pabs @ session #2: pulseaudio[1976]
...

checkrestart output:
# checkrestart -v
Found 0 processes using old versions of upgraded files

lsof output:
# lsof -p 1976 | grep -i del
pulseaudi 1976 pabs  DEL   REG   0,41 28098 
/run/user/1000/orcexec.nXwDNz

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages needrestart depends on:
ii  dpkg   1.18.7
ii  gettext-base   0.19.8.1-1
ii  libintl-perl   1.24-1
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.21-1
ii  libproc-processtable-perl  0.53-1+b1
ii  libsort-naturally-perl 1.03-1
ii  libterm-readkey-perl   2.33-1+b1
ii  perl   5.22.2-1
ii  xz-utils   5.1.1alpha+20120614-2.1

needrestart recommends no packages.

Versions of packages needrestart suggests:
ii  libnotify-bin0.7.6-2
ii  needrestart-session  0.3-2

-- no debconf information

-- 

bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#828102: tgt: password exposed as command line parameter

[Brett Wuth]

Package: tgt
Version: 1:1.0.51-1
Severity: normal
Tags: upstream

Dear Maintainer,

The "tgtadm" requires that a password, if set, be provided on the
command line such as:

 tgtadm --lld iscsi --op new --mode account --user ronnie --password password

Command line paramaters are not normally secure.  They can be seen by
any other user on the system using ps.  This could result in an unintended
user gaining access to the iSCSI device.

The password should be read from a file instead.  E.g. 

 tgtadm --lld iscsi --op new --mode account --user ronnie --passwordfile 
~/password

Passwords that are stored in /etc/tgt are read by tgt-admin but still
processed using tgtadm, so are also vulnerable.


A work-around is to disable the ability for other users to see command
line parameters.  See:

https://debian-administration.org/article/702/Hiding_processes_from_other_users

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=0499680a42141d86417a8fbaa8c8db806bea1201

Cheers,
-- Brett


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

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

Versions of packages tgt depends on:
ii  init-system-helpers 1.22
ii  libc6   2.19-18+deb8u4
ii  libconfig-general-perl  2.56-1
ii  libibverbs1 1.1.8-1.1
ii  librdmacm1  1.0.19.1-1
ii  libsystemd0 215-17+deb8u4
ii  lsb-base4.1+Debian13+nmu1
ii  sg3-utils   1.39-1

tgt recommends no packages.

Versions of packages tgt suggests:
pn  tgt-glusterfs  
pn  tgt-rbd

-- no debconf information

Bug#828100: ITP: apertium-tat -- Apertium single language data for Tatar

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: apertium-tat
  Version : 0.1.0
  Upstream Author : Röstäm Battal,
Francis M. Tyers ,
Ilnar Salimzyan ,
Jonathan N. Washington ,
Aglimzan ,
Kevin Brubeck Unhammer ,
Beknazar Abdikamalov ,
Trond Trosterud .
* URL : http://www.apertium.org/
* License : GPL-3
  Programming Lang: 
  Description : Apertium single language data for Tatar

Data package providing Apertium language resources for Tatar

 - how do you plan to maintain it? inside a packaging team
   (check list at https://wiki.debian.org/Teams)? are you
   looking for co-maintainers? do you need a sponsor?

 A: Debian-science team + upstream support.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#828101: ITP: apertium-kaz -- Apertium single language data for Kazakh

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: apertium-kaz
  Version : 0.1.0
  Upstream Author : Nathan Maxson,
Francis M. Tyers ,
Jonathan N. Washington ,
Ilnar Salimzyan ,
Aizhan Aitkulova ,
Trond Trosterud ,
Aida ,
Kevin Brubeck Unhammer ,
Mikel L. Forcada ,
Kantoro Erkulov ,
Aidana ,
Assem ,
Beknazar Abdikamalov ,
Inari Listenmaa ,
Sjurum ,
Zhenisbek Assylbekov .
* URL : http://www.apertium.org/
* License : GPL-3
  Programming Lang: 
  Description : Apertium single language data for Kazakh

Data package providing Apertium language resources for Kazakh

 - how do you plan to maintain it? inside a packaging team
   (check list at https://wiki.debian.org/Teams)? are you
   looking for co-maintainers? do you need a sponsor?

 A: Debian-science team + upstream support.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#828099: ITP: apertium-urd -- Apertium single language data for Urdu

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: apertium-urd
  Version : 0.1.0
  Upstream Author : Francis M. Tyers ,
Kevin Brubeck Unhammer ,
Sudarsh Rathi 
* URL : http://www.apertium.org/
* License : GPL-3
  Programming Lang: 
  Description : Apertium single language data for Urdu

Data package providing Apertium language resources for Urdu

 - how do you plan to maintain it? inside a packaging team
   (check list at https://wiki.debian.org/Teams)? are you
   looking for co-maintainers? do you need a sponsor?

 A: Debian-science team + upstream support.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#828098: ITP: apertium-hin -- Apertium single language data for Hindi

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: apertium-hin
  Version : 0.1.0
  Upstream Author : Francis M. Tyers ,
Kevin Brubeck Unhammer ,
Sudarsh Rathi ,
Raveesh Motlani 
* URL : http://www.apertium.org/
* License : GPL-3
  Programming Lang: 
  Description : Apertium single language data for Hindi

Data package providing Apertium language resources for Hindi

 - how do you plan to maintain it? inside a packaging team
   (check list at https://wiki.debian.org/Teams)? are you
   looking for co-maintainers? do you need a sponsor?

 A: Debian-science team + upstream support.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#828097: transition: tidy

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: t...@packages.debian.org
X-Debbugs-CC: tidy-ht...@packages.debian.org
X-Debbugs-CC: rouss...@debian.org

This week's upload of tidy-html5 to unstable started an unannounced
library transition. Next time, please read this wiki page especially
the Transitions subpage.

https://wiki.debian.org/Teams/ReleaseTeam

Also, I think it was an unnecessary clobber of the already existing
tidy source package because I don't think we need both source packages
in Debian.


Here's my guess at the ben syntax:

title = "tidy";
is_affected = .depends ~ /tidy/ | .build-depends ~ /libtidy-dev/;
is_good = .depends ~ "libtidy5";
is_bad = .depends ~ "libtidy-0.99-0";


Thanks,
Jeremy Bicha

Bug#828030: RFS: gdbm/1.12-3

[Dmitry Bogatov]

> On 2016-06-24 00:19 -0400, Dmitry Bogatov wrote:
> 
> > I am looking for a sponsor for my package "gdbm"
> >
> > Changes since last upload:
> >
> >   * Separate translation files (/usr/share/locale/*) into new binary
> > package 'libgdbm-l10n' to comply with Policy =A78.2 (Closes: #828005)
> Thanks for the fast reaction to that bug report. :-)  There seem to be a
> few minor problems.
>
> Since you are moving files between packages, libgdbm-l10n needs a
> versioned Replaces on libgdbm4 to avoid file conflicts on upgrades.
> Actually the same holds for libgdbm-dev, in 1.12-2 you moved files from
> libgdbm4 to it.

Fixed. But please review carefully.

> The libgdbm-l10n package is "Architecture: all", but libgdbm4 has a
> "Suggests: libgdbm-l10n (=3D ${binary:Version})".  If you want to specify
> a version at all, it should be ${source:Version} instead.

Fixed.

> The package description of libgdbm-l10n says "This package provides
> translations for error messages, generated by library routines".  This
> does not seem to be accurate, it also contains messages from gdbmtool.
> That's why I suggested the package name gdbm-l10n in #828005.

Reworded. Native speaker review is welcome.

New version is on mentors.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#828095: petitboot: needs autoreconf to build on ppc64el

[Logan Rosen]

Package: petitboot
Version: 13.05.29.14.00-g4dc604b-1
Severity: serious
Tags: patch
Justification: fails to build from source
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

petitboot currently fails to build from source on ppc64el due to outdated
libtool files. I had to grab a patch from upstream to fix a build problem
when invoking autoreconf, but now it builds properly on ppc64el in Ubuntu.

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

  * Build with dh-autoreconf to fix FTBFS on ppc64el.
  * debian/patches/fix-automake-warnings.patch: Grab patch from upstream Git
to fix warnings/errors during autoreconf.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru petitboot-13.05.29.14.00-g4dc604b/debian/control petitboot-13.05.29.14.00-g4dc604b/debian/control
--- petitboot-13.05.29.14.00-g4dc604b/debian/control	2013-05-28 19:53:29.0 -0400
+++ petitboot-13.05.29.14.00-g4dc604b/debian/control	2016-06-24 20:39:12.0 -0400
@@ -9,7 +9,8 @@
  libtinfo-dev,
  libtwin-dev,
  libudev-dev,
- pkg-config
+ pkg-config,
+ dh-autoreconf
 Standards-Version: 3.9.4
 Homepage: https://www.kernel.org/pub/linux/kernel/people/geoff/petitboot/petitboot.html
 Vcs-Git: git://git.kernel.org/pub/scm/linux/kernel/git/geoff/petitboot.git
diff -Nru petitboot-13.05.29.14.00-g4dc604b/debian/patches/fix-automake-warnings.patch petitboot-13.05.29.14.00-g4dc604b/debian/patches/fix-automake-warnings.patch
--- petitboot-13.05.29.14.00-g4dc604b/debian/patches/fix-automake-warnings.patch	1969-12-31 19:00:00.0 -0500
+++ petitboot-13.05.29.14.00-g4dc604b/debian/patches/fix-automake-warnings.patch	2016-06-24 15:57:32.0 -0400
@@ -0,0 +1,75 @@
+From 434a6c9c100bc8daca1e6c41137f993d88f20fe3 Mon Sep 17 00:00:00 2001
+From: Geoff Levand 
+Date: Sun, 30 Jun 2013 13:45:58 -0700
+Subject: discover: Fix automake warnings
+
+Change the Makfile.am relocatable output files from automake _LIBRARIES
+to automake _PROGRAMS.  Also, change the output file name extension
+from .o to .ro to better show these are relocatable files.
+
+Fixes automake warnings like these:
+
+  discover/Makefile.am: `libparser.o' is not a standard library name
+  discover/Makefile.am: did you mean `libparser.a'?
+
+Signed-off-by: Geoff Levand 
+---
+ discover/Makefile.am| 8 
+ test/parser/Makefile.am | 9 -
+ 2 files changed, 8 insertions(+), 9 deletions(-)
+
+--- a/discover/Makefile.am
 b/discover/Makefile.am
+@@ -19,9 +19,9 @@
+ 	-DPKG_SHARE_DIR='"$(pkgdatadir)"' \
+ 	-DLOCAL_STATE_DIR='"$(localstatedir)"'
+ 
+-noinst_LIBRARIES = libparser.o
++noinst_PROGRAMS = libparser.ro
+ 
+-libparser_o_SOURCES = \
++libparser_ro_SOURCES = \
+ 	parser.c \
+ 	parser.h \
+ 	parser-conf.c \
+@@ -35,7 +35,7 @@
+ 	yaboot-parser.c \
+ 	pxe-parser.c
+ 
+-libparser.o: $(libparser_o_OBJECTS)
++libparser.ro: $(libparser_ro_OBJECTS)
+ 	$(LD) -r -o $@ $^
+ 
+ EXTRA_DIST = native-parser.c
+@@ -63,7 +63,7 @@
+ 	user-event.c \
+ 	user-event.h
+ 
+-pb_discover_LDADD = libparser.o $(top_builddir)/lib/libpbcore.la
++pb_discover_LDADD = libparser.ro $(top_builddir)/lib/libpbcore.la
+ 
+ pb_discover_LDFLAGS = -ludev
+ 
+--- a/test/parser/Makefile.am
 b/test/parser/Makefile.am
+@@ -41,9 +41,9 @@
+ 	 data/yaboot-rh8-ppc64.conf
+ 
+ common_libs = $(top_builddir)/lib/libpbcore.la
+-test_libs = libtest.o
++test_libs = libtest.ro
+ 
+-libtest.o: $(libtest_o_OBJECTS)
++libtest.ro: $(libtest_ro_OBJECTS)
+ 	$(LD) -o $@ -r $^
+ 
+ # objects under test
+@@ -58,7 +58,7 @@
+ 
+ LDADD = $(common_libs) $(test_libs)
+ 
+-libtest_o_SOURCES = utils.c parser-test.h handler.c main.c $(parser_test_objs)
++libtest_ro_SOURCES = utils.c parser-test.h handler.c main.c $(parser_test_objs)
+ 
+ $(check_PROGRAMS): %: %.embedded-config.o
+ $(check_PROGRAMS): LDADD += $@.embedded-config.o
diff -Nru petitboot-13.05.29.14.00-g4dc604b/debian/patches/series petitboot-13.05.29.14.00-g4dc604b/debian/patches/series
--- petitboot-13.05.29.14.00-g4dc604b/debian/patches/series	1969-12-31 19:00:00.0 -0500
+++ petitboot-13.05.29.14.00-g4dc604b/debian/patches/series	2016-06-24 16:40:30.0 -0400
@@ -0,0 +1 @@
+fix-automake-warnings.patch
diff -Nru petitboot-13.05.29.14.00-g4dc604b/debian/rules petitboot-13.05.29.14.00-g4dc604b/debian/rules
--- petitboot-13.05.29.14.00-g4dc604b/debian/rules	2012-02-15 18:16:23.0 -0500
+++ petitboot-13.05.29.14.00-g4dc604b/debian/rules	2016-06-24 16:28:16.0 -0400
@@ -18,7 +18,10 @@
 
 
 %:
-	

Bug#128745: libstroke0-dev: aclocal is confused by libstroke .m4 files

[Vincent Lefevre]

Control: found -1 0.5.1-7
Control: severity -1 serious

This bug breaks the build of other software when --warnings=error
is used (which may be needed to ensure a correct build).

zira:~/software/mpfr> autoreconf --warnings=error
aclocal: warnings are treated as errors
/usr/share/aclocal/libstroke.m4:29: warning: underquoted definition of 
smr_ARG_WITHLIB
/usr/share/aclocal/libstroke.m4:29:   run info Automake 'Extending aclocal'
/usr/share/aclocal/libstroke.m4:29:   or see 
http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
autoreconf: aclocal failed with exit status: 1
zsh: exit 1 autoreconf --warnings=error

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#828093: commons-javaflow: FTBFS: Could not resolve dependencies for project org.apache.commons:commons-javaflow:jar

[Emmanuel Bourg]

Thank you for the report Chris. Other packages like sisu-guice are
affected by the same issue. It seems to be caused by the optional
dependency on ant in cglib, but I don't understand why Maven fails to
resolve the dependency. It fails even when ant is installed.

Emmanuel Bourg

Bug#828094: python3-coverage: Missing JavaScript dependency: jquery.debounce.min.js

[Barry Warsaw]

Package: python3-coverage
Version: 4.1+dfsg.1-2
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Apparently python-coverage has gained a dependency on
jquery.debounce.min.js but this isn't available in the archive afaict.
The closest thing apt-file tells me is

% apt-file search jquery.debounce
phpmyadmin: /usr/share/phpmyadmin/js/jquery/jquery.debounce-1.0.5.js

See the reference in coverage/html.py.

This missing js file breaks html reporting.  E.g. in a tox
environment using system site packages:

coverage runtests: commands[1] | python -m coverage combine
- --rcfile=/home/barry/projects/ubuntu/allsnappy/ubuntu-image/coverage.ini
coverage runtests: commands[2] | python -m coverage html
- --rcfile=/home/barry/projects/ubuntu/allsnappy/ubuntu-image/coverage.ini
Couldn't find static file 'jquery.debounce.min.js' from
'/home/barry/projects/ubuntu/allsnappy/ubuntu-image', tried:
['/usr/share/javascript/jquery.debounce.min.js',
'/usr/share/javascript/jquery-debounce/jquery.debounce.min.js',
'/usr/lib/python3/dist-packages/coverage/htmlfiles/jquery.debounce.min.js',
'/usr/lib/python3/dist-packages/coverage/htmlfiles/jquery-debounce/jquery.debounce.min.js']
ERROR: InvocationError:
'/home/barry/projects/ubuntu/allsnappy/ubuntu-image/.tox/coverage/bin/python
- -m coverage html
- --rcfile=/home/barry/projects/ubuntu/allsnappy/ubuntu-image/coverage.ini'


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

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

Versions of packages python3-coverage depends on:
ii  libc6  2.23-0ubuntu3
ii  python33.5.1-4
ii  python3-pkg-resources  20.10.1-1

Versions of packages python3-coverage recommends:
ii  libjs-jquery  1.12.3-1
ii  libjs-jquery-hotkeys  0~20130707+git2d51e3a9+dfsg-2ubuntu1
ii  libjs-jquery-isonscreen   1.2.0-1
ii  libjs-jquery-tablesorter  10-2ubuntu2

python3-coverage suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXbbpCAAoJEBJutWOnSwa/L4IQAJa1TXw6WmfwoT6aX82Qv6x8
0+Jk0aNE3aHP5DSaJTBhVP4i1WciKt6mvrubM/+uARpsGFFR9Rz61YDtkk59NwGL
gcU7wpmhN/d9yhn7l3XcUTpx3aiqq6l86/HQg45dLNL7LK23Ntsq+fNTrbtw+6qp
0FCFC0ZT6qN9LtV+dpV7MbW3rTuYFrqo98G7xSlOZrWkA2V8gO5mTbDUkq+y1e/O
kk3mft9XUu5j8JI87i1SgjdXrcLJGchKW2Z2MkqhuFPOCbg2PY/FlJZNLnQEqwhd
JDsDYV+4Qh7n3QwDmotpkR98GEZecHkI6kVRcP2j3/UDxojmeMfr2Zw3k5PJnhMf
ETqy7a9w8medl9qPNCR+EIf/f+akuk0m5IEJJT9MjagifEg0bZtUomame619r63d
aQY5beJnpIldg+N0x4q7R1tXx5tTrnGipBjRQrZPRC2m5acHMQZzm58uQ3ASAeXE
JTl4o4P00q4t7nEX7mjWiUI1AFjwITGKDoGrzBOPTzikH3tVakNM/o2yG4DkUUtD
U0M9nhycdiEw/5pBs2MhJ70ZJ40v7sG2RQ8Jxv7eQcwTuyXlSNAe7cIOVHPrB/kz
jtRc3fniGaWX0yVHtuMIDa1BvrhvagDuihGNmveVNBVS4OPCoxvRyGgjSqm9Sbx7
wccdJBWySpvfr/BYs7m3
=QNgz
-END PGP SIGNATURE-

Bug#827733: BusyBox Init + OpenRC

[Jon Boden]

Hi

I think it's better if this is provided by openrc package. Then openrc will 
immediately become usable on Ubuntu where sysvinit-core is not available, and 
it could be included again in universe.

Here's a new patch, this time for openrc package.

-- 
Jon Boden

ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!

http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD
diff -Nur -x '*~' -x changelog ../debian/control debian/control
--- ../debian/control	2016-06-23 05:25:51.0 +0200
+++ debian/control	2016-06-25 00:12:06.0 +0200
@@ -16,7 +16,7 @@
 Conflicts: file-rc, sysv-rc
 Replaces: sysv-rc
 Provides: sysv-rc
-Depends: insserv, ${misc:Depends}, ${shlibs:Depends}
+Depends: insserv, ${misc:Depends}, ${shlibs:Depends}, sysvinit-core | openrc-busybox
 Recommends: init-system-helpers (>=1.29)
 Suggests: policycoreutils [linux-any] 
 Description: dependency based init system (runlevel change mechanism)
@@ -32,6 +32,24 @@
  .
  This package provides the runlevel change mechanism.
 
+Package: openrc-busybox
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, busybox, openrc
+Conflicts: sysvinit (<< 2.88dsf-44), sysvinit-core, upstart [linux-any], systemd-sysv [linux-any]
+Description: dependency based init system (runlevel change mechanism)
+ OpenRC is a dependency based init system. It provides support for System V
+ init, for booting, changing runlevels, starting and stopping services, and
+ shutting down.
+ .
+ Originally written as a Gentoo project, OpenRC aims at being
+ platform-agnostic.  It works equally well on Linux, BSD and Hurd.
+ It supports the traditional init system in Debian in addition to many
+ alternatives.  OpenRC is implemented in C in a small, simple and
+ efficient way, making it easy to understand, extend and reuse.
+ .
+ This package sets up the BusyBox implementation of /sbin/init for use with
+ OpenRC.
+
 Package: librc1
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
diff -Nur -x '*~' -x changelog ../debian/init/hurd/inittab debian/init/hurd/inittab
--- ../debian/init/hurd/inittab	1970-01-01 01:00:00.0 +0100
+++ debian/init/hurd/inittab	2016-06-25 00:08:31.0 +0200
@@ -0,0 +1,28 @@
+# /etc/inittab: init(8) configuration.
+
+# Launch OpenRC for system initialization
+::sysinit:/sbin/openrc sysinit
+::wait:/sbin/openrc boot
+::wait:/sbin/openrc default
+
+# What to do when CTRL-ALT-DEL is pressed.
+::ctrlaltdel:/sbin/reboot
+
+# /sbin/getty invocations for the runlevels.
+#
+::respawn:/sbin/getty 38400 tty1
+::respawn:/sbin/getty 38400 tty2
+::respawn:/sbin/getty 38400 tty3
+::respawn:/sbin/getty 38400 tty4
+::respawn:/sbin/getty 38400 tty5
+::respawn:/sbin/getty 38400 tty6
+::respawn:/sbin/getty 38400 console
+
+# Example how to put a getty on a serial line (for a terminal)
+#
+#::respawn:/sbin/getty -L ttyS0 9600 vt100
+#::respawn:/sbin/getty -L ttyS1 9600 vt100
+
+# Example how to put a getty on a modem line.
+#
+#::respawn:/sbin/mgetty -x0 -s 57600 ttyS3
diff -Nur -x '*~' -x changelog ../debian/init/kfreebsd/inittab debian/init/kfreebsd/inittab
--- ../debian/init/kfreebsd/inittab	1970-01-01 01:00:00.0 +0100
+++ debian/init/kfreebsd/inittab	2016-06-25 00:08:31.0 +0200
@@ -0,0 +1,27 @@
+# /etc/inittab: init(8) configuration.
+
+# Launch OpenRC for system initialization
+::sysinit:/sbin/openrc sysinit
+::wait:/sbin/openrc boot
+::wait:/sbin/openrc default
+
+# What to do when CTRL-ALT-DEL is pressed.
+::ctrlaltdel:/sbin/reboot
+
+# /sbin/getty invocations for the runlevels.
+#
+::respawn:/sbin/getty 38400 ttyv0 xterm
+::respawn:/sbin/getty 38400 ttyv1 xterm
+::respawn:/sbin/getty 38400 ttyv2 xterm
+::respawn:/sbin/getty 38400 ttyv3 xterm
+::respawn:/sbin/getty 38400 ttyv4 xterm
+::respawn:/sbin/getty 38400 ttyv5 xterm
+
+# Example how to put a getty on a serial line (for a terminal)
+#
+#::respawn:/sbin/getty -L cuau0 9600 vt100
+#::respawn:/sbin/getty -L cuau1 9600 vt100
+
+# Example how to put a getty on a modem line.
+#
+#::respawn:/sbin/mgetty -x0 -s 57600 ttyd3
diff -Nur -x '*~' -x changelog ../debian/init/linux/inittab debian/init/linux/inittab
--- ../debian/init/linux/inittab	1970-01-01 01:00:00.0 +0100
+++ debian/init/linux/inittab	2016-06-25 00:08:31.0 +0200
@@ -0,0 +1,27 @@
+# /etc/inittab: init(8) configuration.
+
+# Launch OpenRC for system initialization
+::sysinit:/sbin/openrc sysinit
+::wait:/sbin/openrc boot
+::wait:/sbin/openrc default
+
+# What to do when CTRL-ALT-DEL is pressed.
+::ctrlaltdel:/sbin/reboot
+
+# /sbin/getty invocations for the runlevels.
+#
+::respawn:/sbin/getty 38400 tty1
+::respawn:/sbin/getty 38400 tty2
+::respawn:/sbin/getty 38400 tty3
+::respawn:/sbin/getty 38400 tty4
+::respawn:/sbin/getty 38400 tty5
+::respawn:/sbin/getty 38400 tty6
+
+# Example how to put a getty on a serial line (for a terminal)
+#
+#::respawn:/sbin/getty -L ttyS0 9600 vt100
+#::respawn:/sbin/getty -L ttyS1 9600 vt100
+
+# Example how to put a getty on a mod

Bug#818774: Upstream

[Yurii Kolesnykov]

I had reported similar bug in upstream a year ago[1]. And I had the
following answer:


>You need to use an older version of GNAT in order to bootstrap GNAT, and
not the other way around which isn't guaranteed to work (and indeed often
won't).


[1]https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66692

Bug#828093: commons-javaflow: FTBFS: Could not resolve dependencies for project org.apache.commons:commons-javaflow:jar

[Chris Lamb]

Source: commons-javaflow
Version: 0.0~svn20151101-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,

commons-javaflow fails to build from source in unstable/amd64:

  [..]

  Adding debian:Entrust_Root_Certification_Authority_-_G2.pem
  Adding debian:Equifax_Secure_CA.pem
  Adding debian:Equifax_Secure_Global_eBusiness_CA.pem
  Adding debian:Equifax_Secure_eBusiness_CA_1.pem
  Adding debian:GeoTrust_Global_CA.pem
  Adding debian:GeoTrust_Global_CA_2.pem
  Adding debian:GeoTrust_Primary_Certification_Authority.pem
  Adding debian:GeoTrust_Primary_Certification_Authority_-_G2.pem
  Adding debian:GeoTrust_Primary_Certification_Authority_-_G3.pem
  Adding debian:GeoTrust_Universal_CA.pem
  Adding debian:GeoTrust_Universal_CA_2.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R4.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R5.pem
  Adding debian:GlobalSign_Root_CA.pem
  Adding debian:GlobalSign_Root_CA_-_R2.pem
  Adding debian:GlobalSign_Root_CA_-_R3.pem
  Adding debian:Global_Chambersign_Root_-_2008.pem
  Adding debian:Go_Daddy_Class_2_CA.pem
  Adding debian:Go_Daddy_Root_Certificate_Authority_-_G2.pem
  Adding debian:Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem
  Adding debian:Hongkong_Post_Root_CA_1.pem
  Adding debian:IGC_A.pem
  Adding debian:IdenTrust_Commercial_Root_CA_1.pem
  Adding debian:IdenTrust_Public_Sector_Root_CA_1.pem
  Adding debian:Izenpe.com.pem
  Adding debian:Juur-SK.pem
  Adding debian:Microsec_e-Szigno_Root_CA.pem
  Adding debian:Microsec_e-Szigno_Root_CA_2009.pem
  Adding debian:NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem
  Adding debian:NetLock_Business_=Class_B=_Root.pem
  Adding debian:NetLock_Express_=Class_C=_Root.pem
  Adding debian:NetLock_Notary_=Class_A=_Root.pem
  Adding debian:NetLock_Qualified_=Class_QA=_Root.pem
  Adding debian:Network_Solutions_Certificate_Authority.pem
  Adding debian:OISTE_WISeKey_Global_Root_GA_CA.pem
  Adding debian:OISTE_WISeKey_Global_Root_GB_CA.pem
  Adding debian:PSCProcert.pem
  Adding debian:QuoVadis_Root_CA.pem
  Adding debian:QuoVadis_Root_CA_1_G3.pem
  Adding debian:QuoVadis_Root_CA_2.pem
  Adding debian:QuoVadis_Root_CA_2_G3.pem
  Adding debian:QuoVadis_Root_CA_3.pem
  Adding debian:QuoVadis_Root_CA_3_G3.pem
  Adding debian:RSA_Security_2048_v3.pem
  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

Bug#828092: cmake: FTBFS: The following tests FAILED: 255 - CMakeOnly.AllFindModules (Failed)

[Chris Lamb]

Source: cmake
Version: 3.5.2-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,

cmake fails to build from source in unstable/amd64:

  [..]

  279/421 Test #286: RunCMake.CMP0057 ...   
Passed0.62 sec
  Start 287: RunCMake.CMP0059
  Start 288: RunCMake.CMP0060
  Start 289: RunCMake.CMP0064
  280/421 Test #284: RunCMake.CMP0054 ...   
Passed0.65 sec
  281/421 Test #283: RunCMake.CMP0053 ...   
Passed3.36 sec
  282/421 Test #287: RunCMake.CMP0059 ...   
Passed0.41 sec
  283/421 Test #289: RunCMake.CMP0064 ...   
Passed0.50 sec
  Start 290: RunCMake.CMP0065
  Start 291: RunCMake.Make
  Start 292: RunCMake.CTest
  Start 293: RunCMake.ctest_memcheck
  284/421 Test #220: CTestLimitDashJ    
Passed   35.22 sec
  285/421 Test #292: RunCMake.CTest .   
Passed0.62 sec
  286/421 Test #224: CTestTestScheduler .   
Passed   34.27 sec
  Start 225: CTestTestCostSerial
  Start 294: RunCMake.BuildDepends
  Start 295: RunCMake.CompilerChange
  287/421 Test #291: RunCMake.Make ..   
Passed0.65 sec
  Start 296: RunCMake.CompilerNotFound
  288/421 Test #279: RunCMake.CMP0046 ...   
Passed7.62 sec
  Start 297: RunCMake.Configure
  289/421 Test #296: RunCMake.CompilerNotFound ..   
Passed0.83 sec
  Start 298: RunCMake.DisallowedCommands
  290/421 Test #268: RunCMake.CMP0022 ...   
Passed   23.82 sec
  291/421 Test #295: RunCMake.CompilerChange    
Passed4.05 sec
  Start 299: RunCMake.ExternalData
  Start 300: RunCMake.FeatureSummary
  292/421 Test #298: RunCMake.DisallowedCommands    
Passed1.61 sec
  293/421 Test #297: RunCMake.Configure .   
Passed2.42 sec
  294/421 Test #288: RunCMake.CMP0060 ...   
Passed5.22 sec
  295/421 Test #293: RunCMake.ctest_memcheck    
Passed4.90 sec
  296/421 Test #300: RunCMake.FeatureSummary    
Passed0.40 sec
  Start 301: RunCMake.FPHSA
  Start 302: RunCMake.GeneratorExpression
  Start 303: RunCMake.GeneratorPlatform
  Start 304: RunCMake.GeneratorToolset
  Start 305: RunCMake.GNUInstallDirs
  297/421 Test #305: RunCMake.GNUInstallDirs    
Passed0.20 sec
  298/421 Test #303: RunCMake.GeneratorPlatform .   
Passed0.62 sec
  299/421 Test #304: RunCMake.GeneratorToolset ..   
Passed0.61 sec
  300/421 Test #301: RunCMake.FPHSA .   
Passed0.62 sec
  Start 306: RunCMake.TargetPropertyGeneratorExpressions
  Start 307: RunCMake.Languages
  Start 308: RunCMake.LinkStatic
  Start 309: RunCMake.ObjectLibrary
  301/421 Test #290: RunCMake.CMP0065 ...   
Passed5.95 sec
  302/421 Test #299: RunCMake.ExternalData ..   
Passed1.25 sec
  Start 310: RunCMake.Swift
  Start 311: RunCMake.TargetObjects
  303/421 Test #308: RunCMake.LinkStatic    
Passed0.89 sec
  304/421 Test #310: RunCMake.Swift .   
Passed0.68 sec
  305/421 Test #307: RunCMake.Languages .   
Passed1.40 sec
  Start 312: RunCMake.TargetSources
  Start 313: RunCMake.find_dependency
  Start 314: RunCMake.CompileDefinitions
  306/421 Test #314: RunCMake.CompileDefinitions    
Passed0.21 sec
  307/421 Test #313: RunCMake.find_dependency ...   
Passed0.71 sec
  Start 315: RunCMake.CompileFeatures
  Start 316: RunCMake.PolicyScope
  308/421 Test #311: RunCMake.TargetObjects .   
Passed2.60 sec
  309/421 Test #294: RunCMake.BuildDepends ..   
Passed8.72 sec
  Start 317: RunCMake.WriteCompilerDetectionHeader
  Start 318: RunCMake.PositionIndependentCode
  310/421 Test #225: CTestTestCostSerial    
Passed9.55 sec
  Start 319: RunCMake.VisibilityPreset

Bug#826063: RFS: libu2f-host/1.0.0-2 [NMU] [RC] -- U2F host communication library

[Adam Borowski]

On Fri, Jun 24, 2016 at 04:06:28PM +0200, Nicolas Braud-Santoni wrote:
> Note that the version number changed: it was following a previous
> UNRELEASED version, which could have led to it being preferred to
> a later release from the maintainer.

I'm afraid that your upload removes data about an upload from the changelog:

.--
libu2f-host (1.0.0-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Switch from libjson0-dev to libjson-c-dev (Closes: #815413)

 -- Neil Williams   Sun, 21 Feb 2016 11:52:27 +
`

which you overwrite with:

.--
libu2f-host (1.0.0-1+nmu1) unstable; urgency=medium

  * Non-maintainer upload.
  * Fix dependencies (libjson & glib2.0) (Closes: #820686).

 -- Nicolas Braud-Santoni   Wed, 01 Jun 2016 23:55:05 
+0200
`

Your only actual change is adding libglib2.0-dev to Build-Depends.

Also, your version number is bad for a non-native package: it should be
1.0.0-1.2.

Last but not least:
$ dpkg --compare-versions 1.0.0-1.1 lt 1.0.0-1+nmu1;echo $?
1
ie, your version number is actually less than what's in the archive.


Otherwise, it builds correctly now.


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#828091: icedove: Icedove segfault when deleting imap messages

[Brandon Mitchell]

Package: icedove
Version: 1:45.1.0-1~deb8u1
Severity: important

Dear Maintainer,

While reading/deleting messages in icedove, I'm getting random segfaults. My
mail is running on an imap server, messages are configured to only be marked
as deleted on the server and not to purge them. I did not experience this
issue in previous versions.

I've gathered the following backtrace from the segfault:

Core was generated by `icedove'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fe1178cc79b in raise (sig=11)
at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
37  ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
(gdb) bt full
#0  0x7fe1178cc79b in raise (sig=11)
at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
resultvar = 0
pid = 
#1  0x7fe111e95959 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#2  0x7fe112772586 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#3  
No locals.
#4  0x7fe11226fd7f in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#5  0x7fe11259b0bb in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#6  0x7fe11259baca in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#7  0x7fe11259be33 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#8  0x7fe1125a2007 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#9  0x7fe1125adf5f in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#10 0x7fe1125ae207 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#11 0x7fe1125aeaed in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#12 0x7fe112503ff5 in js::DirectProxyHandler::call(JSContext*, 
JS::Handle, JS::CallArgs const&) const () from 
/usr/lib/icedove/libxul.so
No symbol table info available.
#13 0x7fe112507269 in js::CrossCompartmentWrapper::call(JSContext*, 
JS::Handle, JS::CallArgs const&) const () from 
/usr/lib/icedove/libxul.so
No symbol table info available.
#14 0x7fe11250969a in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#15 0x7fe11250a03f in js::proxy_Call(JSContext*, unsigned int, JS::Value*)
() from /usr/lib/icedove/libxul.so
No symbol table info available.
#16 0x7fe1125ae3e5 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#17 0x7fe1125a0810 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#18 0x7fe1125adf5f in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#19 0x7fe1125ae207 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#20 0x7fe1125aeaed in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#21 0x7fe112503ff5 in js::DirectProxyHandler::call(JSContext*, 
JS::Handle, JS::CallArgs const&) const () from 
/usr/lib/icedove/libxul.so
No symbol table info available.
#22 0x7fe112507269 in js::CrossCompartmentWrapper::call(JSContext*, 
JS::Handle, JS::CallArgs const&) const () from 
/usr/lib/icedove/libxul.so
No symbol table info available.
#23 0x7fe11250969a in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#24 0x7fe11250a03f in js::proxy_Call(JSContext*, unsigned int, JS::Value*)
() from /usr/lib/icedove/libxul.so
No symbol table info available.
#25 0x7fe1125ae3e5 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#26 0x7fe1125aeaed in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#27 0x7fe11227bef6 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#28 0x7fe117b45280 in ?? ()
No symbol table info available.
#29 0xfffc7fe0eae6c880 in ?? ()
No symbol table info available.
#30 0x7fff1e8865c0 in ?? ()
No symbol table info available.
#31 0xfff9 in ?? ()
No symbol table info available.
#32 0x7fe114aca480 in ?? () from /usr/lib/icedove/libxul.so
No symbol table info available.
#33 0x7fe0fcb586a0 in ?? ()
No symbol table info available.
#34 0x7fe0ff88ff23 in ?? ()
No symbol table info available.
#35 0x0902 in ?? ()
No symbol table info available.
#36 0x7fff1e886658 in ?? ()
No symbol table info available.
#37 0x7fe0df4bf0c8 in ?? ()
No symbol table info available.
#38 0x0001 in ?? ()
No symbol table info available.
#39 0x7fff1e886608 in ?? ()
No symbol table info available.
#40 0xfffc7fe0f6541980 in ?? ()
No symbol table info available.
#41 0xfffc7fe0f6541a60 in ?? ()
No symbol table info available.
#42 0xfffc7fe0ea77e8c0 in ?? ()
No symbol table info available.
#43 0x7fff1e886698 in ?? ()
No symbol table info available.
#44 0x7fe0df4bf0c8 in ?? ()
No symbol table info available.
#45 0x7fe0ff875ef6 in ?? ()
No symbol table info available.
#46 0x0c01 in ?? ()
No symbol table info availab

Bug#828090: ruby-font-awesome-rails: Unsatisfiable dependency on fonts-font-awesome

[Jeremy Bicha]

Package: ruby-font-awesome-rails
Version: 4.6.3.0-1
Severity: serious

Hi, this doesn't work:

https://anonscm.debian.org/cgit/pkg-ruby-extras/ruby-font-awesome-rails.git/commit/?id=799b55141cda57fabe077b3df3c9f215208bfa06

because fonts-font-awesome in Debian is 4.6.3~dfsg-1 which is lower than 4.6.3

I think you could just change the dependency to >= 4.6.3~

Thanks,
Jeremy

Bug#828089: [pkg-golang-devel] Bug#828089: consul fails to build on arm64 due to missing poll

[Tianon Gravi]

reassign 828089 golang-golang-x-sys-dev
thanks

On 24 June 2016 at 14:00, Peter Michael Green  wrote:
> src/golang.org/x/sys/unix/zsyscall_linux_arm64.go:57: undefined: SYS_POLL

"golang.org/x/sys" is a separate package now specifically to avoid the
need to get a revbump on the core compiler/stdlib for changes like
this, so I've retargeted this bug appropriately (to the provider of
the "golang.org/x/sys" Go package).

Looks like it probably just needs a new snapshot packaged.

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

Bug#761083: #761083 - debsources: inject binary packages metadata into the DB

[Luciano Bello]

On Friday 24 June 2016 16.41.57 Raphael Hertzog wrote:
> I thought the same when I saw this report... and the reason is likely that
> the tracker has almost no REST API at all right now and that it thus looked
> harder to implement there.

Indeed. That's the reason :)

/l

Bug#828022: e2fsprogs: Unable to tune2fs -O ^metadata_csum

[Theodore Ts'o]

On Thu, Jun 23, 2016 at 04:58:30PM -0700, J Mo wrote:
> Package: e2fsprogs
> Version: 1.43.1-1
> Severity: normal
> 
> I have an ext4 filesystem where I wanted to remove the metadata_csum feature, 
> but tune2fs doesn't seem to support this, even though the man page seems to 
> indicate that it should.
> 
> The command I am using is: sudo tune2fs -O ^metadata_csum /dev/sde1
> 
> But every time I run it, I am told I need to check the filesystem, even 
> though it's clean and I literally just checked it.
> 
> 
> user@host-->sudo fsck.ext4 -y /dev/sde1 
> e2fsck 1.43.1 (08-Jun-2016)
> /dev/sde1: clean, 5312/1949696 files, 3994069/7791488 blocks

I'll adjust the help message to make it clear what needs to be done,
but when the file system is "clean", e2fsck doesn't actually do a check.
You'll note that it was very fast.  That's why it didn't work.

Try running "sudo fsck.ext4 -fy /dev/sde1", and you will notice that
it takes a longer; because it's actually doing a real check.

> Since I now have to replace the whole filesystem anyway, I figured
> I'd test removing some other feature like huge_file, and that worked
> as-expected.

There are certain tune2fs operations that are riskiers than others.
Removing the metadata checksum requires rewriting pretty much all of
the metadata blcoks, so tune2fs wants to make sure the file system is
completely consistent before starting the operation.

For similar reasons, resize2fs requires that you do a full file system
check, first, but it also gives a much more explicit error message:

# resize2fs /dev/closure/scratch
resize2fs 1.43.1 (08-Jun-2016)
Please run 'e2fsck -f /dev/closure/scratch' first.

We need to change tune2fs to give a similar message.

Cheers,

- Ted

Bug#828054: NTLM apache2 auth broken in samba

[Andrew Bartlett]

On Fri, 2016-06-24 at 11:10 +, Секретёв Дмитрий Александрович
wrote:
> Package: winbind, samba
> Version: 2:4.2.10+dfsg-0+deb8u3

What is the client?  Does Samba 4.4 work any better?

The most likely issue here is that our stricter NTLM server code is not
happy, but a proper network trace (.pcap format) uploaded as a private
attachment to a bug in Samba's bugzilla is the next step we need to
move this forward.

You should also change the password used in this log (it isn't
plaintext, but no NTLM mech is very strong). 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett   http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT  http://catalyst.net.nz/services/samba

Bug#828089: consul fails to build on arm64 due to missing poll

[Peter Michael Green]

Package: golang-1.6
Severity: serious

consul failed to build on arm64 with

src/golang.org/x/sys/unix/zsyscall_linux_arm64.go:57: undefined: SYS_POLL


Googling this error finds https://github.com/golang/go/issues/16052 
which links to a commit fixing the issue. 
https://github.com/golang/sys/commit/5a8c7f28c1853e998847117cf1f3fe96ce88a59f 
can we get this fix in the Debian golang-1.6 package so that consul can 
be built successfully and migrate to testing. There is already at least 
one package in testing that build-depends on the new consul.

Bug#828088: licensecheck invokes find with -follow

[Sandro Mani]

Package: devscripts
Version: devscripts-2.16.5

Following is a trimmed version of the downstream bug at 
https://bugzilla.redhat.com/show_bug.cgi?id=1350021 :

Description of problem:
When licensecheck ran, it reported:

find: File system loop detected; ‘./src/giac’ is part of the same file system 
loop as ‘./src’.
Can't close(GLOB(0x668db0)) filehandle: '' at /usr/bin/licensecheck line 387

There are two bugs here: licensecheck tries to close a file handle on line 387 
even when the handle is already closed due to find exiting with an error, and 
licensecheck invokes find with the -follow option.

The find man page says that -follow is deprecated and -L should be used 
instead, by the way.  But I can't conceive of any situation where using 
-follow/-L is the right thing to do.  I think it should be removed, for three 
reasons.  Reason 1: self loops like the one in giac make find, and therefore 
licensecheck, fail.  Reason 2: symlinks can point anywhere.  Do you really want 
to let licensecheck run over arbitrary parts of the filesystem?  Reason 3: 
every file in a package *should* be reachable without traversing symlinks at 
all.  (If fedora-review doesn't have a check for that, it probably should.)

Steps to Reproduce:
1. mkdir loop
2. ln -s . loop/loop
3. licensecheck -r -v loop

Actual results:
The error messages reported above, and no license output.

Expected results:
A report on licenses.

Additional info:
The filesystem type might have something to do with this.  I do NOT see this 
behavior if I create the loop under /tmp (tmpfs), but I do see it if the loop 
is under my /home directory (ext4).

Bug#828087: Kernel 4.6 causes X session freezes with Intel NUCs

[Julien Aubin]

Package: linux-image-amd64
Version: 4.6+74~bpo8+1
Severity: important

Hi,

I have an Intel Nuc BOXNUC5PPYH Barebone PC and upgraded to kernel 4.6.
Since
then I've seen that within the X session I get many freezes, which did not
occur with kernel 4.5. Is there a regression around ?

To reproduce the issue :
DO : start KDM
DO : open a KDE session with graphic effects enabled (like transparency)
EXPECT : the session is usable
ACTUAL : the session freezes while the mouse is still operational

Note :
I can see the following message in the logs :
Jun 24 22:20:06 pccore2duo kernel: [  217.909567]
[drm:intel_check_cpu_fifo_underruns [i915]] *ERROR* pipe A underrun

The computer then becomes frozen under an X session but it can be reached
through SSH.

The issue did not appear with kernel 4.5.x

Workaround :
Add the following parameter to kernel command line :  i915.enable_fbc=0

Rgds

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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.6.0-0.bpo.1-amd64  4.6.1-1~bpo8+1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#828086: icedove: filter newly created disappear

[Karagkiaouris Diamantis]

Package: icedove
Version: 1:45.1.0-1
Severity: important

Dear Maintainer,

I created a new filter based on a email address by right clicking on the CC 
fiedld of an email. After i enter a name and set the folder where the email 
where transferred, i clicked ok but my filter do not appear on the list. After 
i closed the filter popup and reopened filters, everything seem to be working.

Kind Regards

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

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

Versions of packages icedove depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.4
ii  libasound21.1.1-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.22-11
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-4
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libglib2.0-0  2.48.1-1
ii  libgtk2.0-0   2.24.30-2
ii  libhunspell-1.4-0 1.4.1-2
ii  libicu55  55.1-7
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.23-2
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpangoft2-1.0-0 1.40.1-1
ii  libpixman-1-0 0.33.6-1
ii  libsqlite3-0  3.13.0-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-4
ii  libvpx3   1.5.0-3
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-de-at [hunspell-dictionary]  20160407-1
ii  hunspell-de-ch [hunspell-dictionary]  20160407-1
ii  hunspell-de-de [hunspell-dictionary]  20160407-1
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.1.0-1

Versions of packages icedove suggests:
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.14.2+dfsg-1

-- no debconf information

Bug#828085: When running monkeysphere against Clint's key, monkeysphere fails to do anything useful due to a GPG bug maybe

[Jameson Graef Rollins]

On Fri, Jun 24 2016, Asheesh Laroia  wrote:
> Package: monkeysphere
> Version: 0.37-2
>
> I am trying to learn how to use monkeysphere. I figured one good first-step
> would be to get the SSH key corresponding to Clint Adams .
>
> So I ran:
>
> $ monkeysphere u "Clint Adams "
>
> in an attempt to get a "ssh-rsa..." line out, which would demonstrate to me
> that monkeysphere generally works.
>
> Instead, I got this output:
>
> paulproteus@slittingmill:~$ monkeysphere u "Clint Adams "
> ms: Failure (2) receiving keyids (0x2100A32C46F895AF3A08783AF6D3495BB0AE9A02
> ms: 0x2806F67A363A1F9C3EBFD274C3A844D76AE3B737
> ms: 0x995314085A0EC967941DCE9DE66D2EEBAB963370
> ms: 0x5DB29C847F07FD4F60A8728070AEBD21B13DEAF7
> ms: 0xA3B4A1C6DBED847F
> ms: 0xF88942139018FAD6EB7EC4735EDBAE5BB98FC0C8
> ms: 0x91A285AE301B7D6B
> ms: 0x1927D3053E30A739) from keyserver pool.sks-keyservers.net

I think this is the issue:

servo:~ 0$ gpg --recv-key 0x91A285AE301B7D6B
gpg: requesting key 0x91A285AE301B7D6B from hkpms server keys.mayfirst.org
gpg: Note: signatures using the MD5 algorithm are rejected
gpg: key 0x91A285AE301B7D6B: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg:   w/o user IDs: 1
servo:~ 2$ 

Note the return code is the same as what monkeysphere is reporting.  So
gpg is failing inside of monkeysphere because it refuses to import that
key.

I'm not sure what should be done about that.  Presumably monkeysphere
should just reject this key, and continue with the other ones it finds.
Not sure what should be reported to the user in this case, though.  In
any case I don't think monkeysphere should fail in this case, and it
should continue with processing of the keys that it can import.

On a side note, I don't think this key should be included in the first
place, and may indicate an issue with gpg itself.  If I do a search for
the exact user id, which is what should happen when I search for
"=$userid", why is gpg returns keys that do not include an exact match
to that user id?

servo:~ 2$ gpg --search ='Clint Adams '
gpg: searching for "=Clint Adams " from hkpms server 
keys.mayfirst.org
(1) Clint Adams 
Clint Adams 
Clint Adams 
Clint Adams 
Clint Adams 
Clint Adams 
Clint Adams 
Clint Adams 
Clint Adams (GNU) 
Clint Adams (Debian) 
  4096 bit RSA key 0xF6D3495BB0AE9A02, created: 2009-05-08
(2) Clint Adams (Debian) 
  2048 bit RSA key 0xC3A844D76AE3B737, created: 2009-05-07 (revoked)
(3) Clint Adams (Debian) 
  1024 bit DSA key 0xE66D2EEBAB963370, created: 1999-09-16
(4) Clint Adams (DSA) 
  1024 bit DSA key 0x70AEBD21B13DEAF7, created: 1998-05-18
(5) Clint Adams (ElG) 
  2048 bit ELG key 0xA3B4A1C6DBED847F, created: 1998-05-18
(6) Clint Adams 
Clint Adams 
Clint Adams 
  1024 bit DSA key 0x5EDBAE5BB98FC0C8, created: 1998-03-26
Keys 1-6 of 8 for "=Clint Adams ".  Enter number(s), N)ext, 
or Q)uit > 

Keys (2), (3), (4), and (5) all do not match the user id I searched for.
gpg seems to be ignoring the comment field, and matching on all other
fields, which it seems to me it obviously shouldn't be doing.  I guess
this should be a separate bug reported against gpg.

jamie.


signature.asc
Description: PGP signature

Bug#827309: linux-image-3.16.0-4-kirkwood: latest upgrade made WiFi unstable

[Paul Gevers]

Hi,

On 19-06-16 19:08, Paul Gevers wrote:
> I reverted to version 3.16.7-ckt25-1 on Thursday, and haven't seen the
> issue since.

Still true, no issues so far.

> But just to be honest and complete, also not all traffic for this NAS is
> going via the dongle anymore, as it is now also connect via UTP wire.
> Furthermore, due to its location, it is also missing the audio USB.

Do you think it is worth while and/or needed to check with the old setup
and the old kernel?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#828084: Proposed patch to dak/debianqueued

[Mathieu Parent]

See attached patch.

This actually ignore files:
- starting with a dot
- containing a colon (See: #828084)

Regards
-- 
Mathieu Parent
From 1f5b0f6bf7dafb7816f7e1ad4f38ec8335215395 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Fri, 24 Jun 2016 22:10:52 +0200
Subject: [PATCH] Be more restrictive in accepted files

to match daklib/regexes.py (re_file_safe).

This actually ignore files:
- starting with a dot
- containing a colon (See: #828084)
---
 tools/debianqueued-0.9/debianqueued | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/debianqueued-0.9/debianqueued b/tools/debianqueued-0.9/debianqueued
index 7b02551..34b62b9 100755
--- a/tools/debianqueued-0.9/debianqueued
+++ b/tools/debianqueued-0.9/debianqueued
@@ -67,7 +67,7 @@ package main;
 ($main::hostname, undef, undef, undef, undef) = gethostbyname(hostname());
 
 my %packages = ();
-my $re_file_safe_prefix = qr/\A([a-zA-Z0-9.][a-zA-Z0-9_.:~+-]*)/s;
+my $re_file_safe_prefix = qr/\A([a-zA-Z0-9][a-zA-Z0-9_.~+-]*)/s;
 my $re_file_safe = qr/$re_file_safe_prefix\z/s;
 
 # extract -r and -k args
-- 
2.8.1

Bug#828085: When running monkeysphere against Clint's key, monkeysphere fails to do anything useful due to a GPG bug maybe

[Asheesh Laroia]

Package: monkeysphere
Version: 0.37-2

I am trying to learn how to use monkeysphere. I figured one good first-step
would be to get the SSH key corresponding to Clint Adams .

So I ran:

$ monkeysphere u "Clint Adams "

in an attempt to get a "ssh-rsa..." line out, which would demonstrate to me
that monkeysphere generally works.

Instead, I got this output:

paulproteus@slittingmill:~$ monkeysphere u "Clint Adams "
ms: Failure (2) receiving keyids (0x2100A32C46F895AF3A08783AF6D3495BB0AE9A02
ms: 0x2806F67A363A1F9C3EBFD274C3A844D76AE3B737
ms: 0x995314085A0EC967941DCE9DE66D2EEBAB963370
ms: 0x5DB29C847F07FD4F60A8728070AEBD21B13DEAF7
ms: 0xA3B4A1C6DBED847F
ms: 0xF88942139018FAD6EB7EC4735EDBAE5BB98FC0C8
ms: 0x91A285AE301B7D6B
ms: 0x1927D3053E30A739) from keyserver pool.sks-keyservers.net

However, I can seemingly download at least of those keys A-OK from the key
server:

paulproteus@slittingmill:~$ echo | gpg --quiet --batch --with-colons
--command-fd 0 --keyserver pool.sks-keyservers.net --recv-keys
0x2100A32C46F895AF3A08783AF6D3495BB0AE9A02 ; echo $?
gpg: requesting key B0AE9A02 from hkp server pool.sks-keyservers.net
0

Discussion with jrollins on #monkeysphere suggests that the fact that GPG
refuses to accept some of the keys, or maybe downloads too much, or prints
too many warnings, is part of the problem:

19:41 < jrollins> hrm
19:41 < jrollins> gpg: key 0x: rejected by import filter
19:41 < jrollins> gpg: Note: signatures using the MD5 algorithm are rejected

19:45 < jrollins> Clint: check out this key: 0x91A285AE301B7D6B
19:45 < jrollins> what's up with that?
19:46 < jrollins> dkg: we seem to have a gpg issue that i'm not sure how to
deal with.  gpg won't import all of the
  key ids that monkeysphere is trying to retrieve, which
causes monkeysphere to fail

19:50 < jrollins> gpg --search ="Clint Adams "
19:50 < jrollins> returns:
19:50 < jrollins> (5)IClint Adams (ElG)  2048 bit ELG
key 0xA3B4A1C6DBED847F, created: 1998-05-1

Some strace output follows. Thanks for reading this bug report!

paulproteus@slittingmill:~$ MONKEYSPHERE_LOG_LEVEL=DEBUG strace -ff -e
execve monkeysphere u "Clint Adams "
execve("/usr/bin/monkeysphere", ["monkeysphere", "u", "Clint Adams <
sch...@debian.org>"], [/* 38 vars */]) = 0
execve("/home/paulproteus/dnlds/google-cloud-sdk/bin/bash", ["bash",
"/usr/bin/monkeysphere", "u", "Clint Adams "], [/* 38
vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/local/bin/bash", ["bash", "/usr/bin/monkeysphere", "u", "Clint
Adams "], [/* 38 vars */]) = -1 ENOENT (No such file or
directory)
execve("/usr/bin/bash", ["bash", "/usr/bin/monkeysphere", "u", "Clint Adams
"], [/* 38 vars */]) = -1 ENOENT (No such file or
directory)
execve("/bin/bash", ["bash", "/usr/bin/monkeysphere", "u", "Clint Adams <
sch...@debian.org>"], [/* 38 vars */]) = 0
Process 1 attached
[pid 1] execve("/usr/bin/basename", ["basename",
"/usr/bin/monkeysphere"], [/* 38 vars */]) = 0
[pid 1] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13334 attached
[pid 13334] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13334,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13335 attached
[pid 13335] execve("/bin/date", ["date", "-u", "+%FT%T"], [/* 41 vars */])
= 0
[pid 13335] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13335,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13336 attached
[pid 13336] execve("/bin/mkdir", ["mkdir", "-p", "-m", "0700",
"/home/paulproteus/.monkeysphere"], [/* 41 vars */]) = 0
[pid 13336] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13336,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13337 attached
[pid 13337] execve("/bin/mkdir", ["mkdir", "-p", "-m", "0700",
"/home/paulproteus/.gnupg"], [/* 42 vars */]) = 0
[pid 13337] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13337,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13338 attached
Process 13339 attached
[pid 13338] +++ exited with 0 +++
[pid 13339] execve("/bin/sed", ["sed", "s/^/ms: /"], [/* 45 vars */]) = 0
ms: processing: Clint Adams 
[pid 13339] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13338,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13340 attached
Process 13341 attached
[pid 13340] +++ exited with 0 +++
[pid 13341] execve("/bin/sed", ["sed", "s/^/ms: /"], [/* 45 vars */]) = 0
ms: key file: -
[pid 13341] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13340,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13342 attached
Process 13343 attached
Process 13344 attached
[pid 13343] +++ exited with 0 +++
[pid 13344] execve("/bin/sed", ["sed", "s/^/ms: /"], [/* 45 vars */]) = 0
ms:  checking keyserver

Bug#827949: libpam-ssh does not launch an ssh-agent

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Giueppe,

On 24/06/16 19:50, Giuseppe Bilotta wrote:
> Hello Jerome,
> 
> On Fri, Jun 24, 2016 at 4:43 PM, Jerome BENOIT  wrote:
>> On 24/06/16 15:21, Giuseppe Bilotta wrote:
>>> So the problem is that one of the leftover files prevented the agent
>>> from starting.
>>
>> This is not a problem, this mechanism is meant to allow several sessions
>> to use the same agent.
> 
> Indeed, and that makes perfect sense. However it does cause issues if
> the agent is not actually running, either because it crashed or
> because the control file was left over from a previous run.

You are right.
Meanwhile I added an entry in my TODO list concerning this package.
I also noticed that there is two flag-file on my box: I would say that one is 
enough,
but I cannot say more right now because I am not familiar with this part of the 
code.
(In the past, I mainly add new key types support)

> 
>> What is not normal is that the flag file was not removed: I suspect an 
>> accident
>> and/or any confusions as it happens at migration time.
> 
> In my case, this is probably due to an unclean shutdown. I have two
> issues on my machine: one is due to the system never closing down
> properly if an NFS mount is active when using systemd as init. The
> other is that sometimes my video driver acts up in multi-monitor
> setups, especially when switching consoles and running rootless X. I
> think that what happened in this case is that my machine went
> completely dead after a switch from a rootless X on tty1 to
> (framebuffer) console on tty2 and then back, so I was forced to do a
> hard reset of the machine without logging off properly. Due to me not
> logging off, the control files were still there and were never cleaned
> up.
> 
>>> May I suggest adding a few more debug outputs centered around starting
>>> up the agent? I don't know how it's done in pam_ssh, but if it does
>>> some checks before then actually printing on debug "checking for
>>> running agents" and maybe "found agent from X file, not starting"?
>>
>> I am agree that the DEBUG message policy must be revisited.
> 
> Indeed, It should be fine to be quite verbose with what's happening,
> since it's debug-only output.

Added en entry to.

> 
>>> This would at least hint at the reason why the agent is not being started.
>>>
>>> (Bonus points: making sure that the agent is actually running and not
>>> just some lefover file?)
>>
>> The leftover file is a flag file (see above).
>> How do you suggest to decide whether or not an agent was indeed launched by 
>> pam_ssh but not any other process ?
> 
> If the flag file contains the PID of the agent it launches, it could
> be used to check if the agent is actually running before deciding to
> not launch one.
> 
>>> (Anyway, the issue is solved for me; maybe demote it to wishlist for
>>> the improved checks?)
>>
>> I guess that we can close it.
> 
> Sure.
> 
>> Note that you may want to launch the pam_tmpdir module before pam_ssh as 
>> pam_ssh honours TMPDIR.
> 
> I have not altered the order of the modules myself, so probably the
> pam-auth-update configuration file for pam_ssh should specify that it
> needs to go after pam_tmpdir?

I filled a bug report a long time ago concerning this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711100

Because I do not like the idea to have the socket agent folder in /tmp ,
I manage the pam_ssh module by hand rather through pam-auth-update .

Cheers,
Jerome

> 

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

iQQcBAEBCgAGBQJXbY+3AAoJED+SGaZ/NsaLwZcf/0u4eAAzdFFdPHM7JsWIgkb9
8drtqZGjitxkqDS5HoTsRg2gOpfuVeQwMgkxInQnsHzsA+j1gCD+FCriwF+f/RN3
4Q/Ydl9pTv/oc5Zsw36qJOaTSuPUKpQfmLI2NGGgU/YGbE72Rxeuj2mJ5nj6d6Wa
aS0ydafdFZonlLMhlGG2qWbZqwaQT2VxcEmsd7uAHB3Ux/6NbTV3Q7XnXPoZw+Hx
zDP48wRoKGIlwNYufDfQ+4HNP5EqBJca34hPgjaEbkKlShVCHP55oRn6hU8tu0Fz
gV0O8sTfOrlUvj2PMXb3ABvlQSOpBDq8lz4AzhiyM+iA9OLl31O2OvikCcRbP1jg
gmvH49oNpHBRRSBHqZv0wDdNFvG1bOugL7y5irEIujTEbYeZxQfIaiBhX+EpLt0A
Kqi1vjhSy1/aB2uUerxNuVM4+YYekhNUCw5lbRwc0r7RH+woYYWPz35bdU8jSFGs
OnJIBuHQw05f/cl0oWrjTJtsHhpKTwDN6xPP8c5MjmzP+sjNlWywTRMNRaNeLYnG
7xkyD1KHvdZpa7A8A1XEwBKOzfmNKnWcs/4NOl2iDUHvhHQVyYNNOM04s2SF3UG+
TcfvoQf/nB4S75KlaGDRifuZ1gUqXZH4uWpG9ZLvNAz8ULr2EjiTr8V7zq3inN2j
GIJAq0+rhngSeor4JZjTtP1Nu5fLCqWYuQtne/ha2+Rop7LPuet+W14yzGVi+jqF
PBSpq9p771527wAMmp/7f/noeOQU66psOr5HacLTRU+0lNDo5KiXynfk2rmdyDeD
atS/d805NQoEfi+91YF6ahE3ZhSOhh6iJkJxtrPUom7nww+/DnEBFMSatu6xrLGH
135yV2B9uHhUV2mL0YzuQEz+Hpa+NxW7BN4eUZlnPZXwu1ef73R42O4OV4noy89k
LeiANSIVq/7doxMmnPVwK8EIdF4bZp7EpcO9Qh7wWtUQkqywaaqLpPiNP0/zCc/x
2RO/f56OUoLWbRluU+EiHYCa5HMrXojHi0JibQZYqyQO2ZTskt4+Dox+ue4dqxha
J9UzZQbKIywhE5DxWM0UPCYyIrzSobwSfAxID+jsrUGIA9waDgqmYjRZTiUfZUux
gJAFeecV1j/WkzMblf6avPlFHSYkVTvPBs98Hx+FpoQdscnMYiIUcJ/Zh3Do5eAF
fvjxIK2qQ5yMQ8kBAK/EV2784gx4vWxumlgGf5WLWEZtC3ieQH3CigLaztKPbvCw
G

Bug#828084: Please remove samba 4.4.4 from FTP queue

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Dear ftp masters,

I'm stuck uploading samba 4.4.4+dfsg-1.

When, I use dput, the response is:
/samba_4.4.4+dfsg-1_amd64.changes is already present on target host:
samba_4.4.4+dfsg-1.debian.tar.xz
Either you already uploaded it, or someone else came first.
Job samba_4.4.4+dfsg-1_amd64.changes removed.

The reason is:  waldi: 
20160624191820|process-upload|dak|samba_2:4.4.4+dfsg-1_source.changes|Error 
while loading changes: samba_2:4.4.4+dfsg-1_source.changes: unsafe filename

When I use dcut:
sathieu_home:  dcut:> rm --searchdirs samba_4.4.4+dfsg-1.debian.tar.xz
samba_4.4.4+dfsg-1.debian.tar.xz did not match anything
No files to delete

The reason is I tried source-only upload, after a full build, following
 and the epoch is kept the file
name (2:4.4.4...).

My understanding: franck.debian.org accepted this file, which is rejected on 
the next hop.

This was discussed in IRC (#debian-ftp) some minutes ago.

Can you please remove all this cruft?

Next time, I'll use one of those methods (on IRC):
jcristau:  or use mergechanges -S -f foo.changes
mapreri: debuild -S && pbuilder b ../*dsc && dput ../*_source.changes  ?
sathieu_home:  mapreri: yes. This is another answer
sathieu_home:  or use https://www.corsac.net/?rub=blog&post=1579, but stripping 
epoch

Fixing queued to behave the same would help too:
jcristau:  feel free to send patches
sathieu_home:  where is the code?
sathieu_home:  in the dak repo?
jcristau:  https://ftp-master.debian.org/#dak
jcristau:  in tools/debianqueued-0.9/

Regards

Mathieu Parent

Bug#806862: ntpd[xxxx] receive: Unexpected origin timestamp xxxxx.xxxxx does not match aorg 00000.00000 from xx

[積丹尼 Dan Jacobson]

I see
ntpd[] receive: Unexpected origin timestamp x.x does not match aorg 
0.0 from xx
which https://www.novell.com/support/kb/doc.php?id=7017645
says should be fixed already in an older version (?)

Bug#828011: requested traces attached

[Eric Valette]

--   eric
Starting method '/usr/lib/apt/methods/ftp'
 <- ftp:100%20Capabilities%0aVersion:%201.0%0aSend-Config:%20true
Configured access method ftp
Version:1.0 SingleInstance:0 Pipeline:0 SendConfig:1 LocalOnly: 0 NeedsCleanup: 
0 Removable: 0
Starting method '/usr/lib/apt/methods/http'
 <- 
http:100%20Capabilities%0aVersion:%201.2%0aPipeline:%20true%0aSend-Config:%20true
Configured access method http
Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 
0 Removable: 0
Starting method '/usr/lib/apt/methods/http'
 <- 
http:100%20Capabilities%0aVersion:%201.2%0aPipeline:%20true%0aSend-Config:%20true
Configured access method http
Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 
0 Removable: 0
 -> 
http:601%20Configuration%0aConfig-Item:%20APT::Architecture=amd64%0aConfig-Item:%20APT::Build-Essential::=build-essential%0aConfig-Item:%20APT::Install-Recommends=true%0aConfig-Item:%20APT::Install-Suggests=0%0aConfig-Item:%20APT::Sandbox::User=_apt%0aConfig-Item:%20APT::Authentication::TrustCDROM=true%0aConfig-Item:%20APT::NeverAutoRemove::=^firmware-linux.*%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-firmware$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-image-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-image-4\.4\.13$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-headers-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-headers-4\.4\.13$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-image-extra-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-image-extra-4\.4\.13$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-signed-image-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-signed-image-4\.4\.13$%0aConfig-Item:%20APT::NeverAutoRemove::=^kfreebsd-image-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^kfreebsd-image-4\.4\.13$%0aConfig-Item:%20APT::NeverAutoRemove::=^kfreebsd-headers-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^kfreebsd-headers-4\.4\.13$%0aConfig-Item:%20APT::NeverAutoRemove::=^gnumach-image-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^gnumach-image-4\.4\.13$%0aConfig-Item:%20APT::NeverAutoRemove::=^.*-modules-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^.*-modules-4\.4\.13$%0aConfig-Item:%20APT::NeverAutoRemove::=^.*-kernel-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^.*-kernel-4\.4\.13$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-backports-modules-.*-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-backports-modules-.*-4\.4\.13$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-tools-4\.4\.12$%0aConfig-Item:%20APT::NeverAutoRemove::=^linux-tools-4\.4\.13$%0aConfig-Item:%20APT::VersionedKernelPackages::=linux-image%0aConfig-Item:%20APT::VersionedKernelPackages::=linux-headers%0aConfig-Item:%20APT::VersionedKernelPackages::=linux-image-extra%0aConfig-Item:%20APT::VersionedKernelPackages::=linux-signed-image%0aConfig-Item:%20APT::VersionedKernelPackages::=kfreebsd-image%0aConfig-Item:%20APT::VersionedKernelPackages::=kfreebsd-headers%0aConfig-Item:%20APT::VersionedKernelPackages::=gnumach-image%0aConfig-Item:%20APT::VersionedKernelPackages::=.*-modules%0aConfig-Item:%20APT::VersionedKernelPackages::=.*-kernel%0aConfig-Item:%20APT::VersionedKernelPackages::=linux-backports-modules-.*%0aConfig-Item:%20APT::VersionedKernelPackages::=linux-tools%0aConfig-Item:%20APT::Never-MarkAuto-Sections::=metapackages%0aConfig-Item:%20APT::Never-MarkAuto-Sections::=contrib/metapackages%0aConfig-Item:%20APT::Never-MarkAuto-Sections::=non-free/metapackages%0aConfig-Item:%20APT::Never-MarkAuto-Sections::=restricted/metapackages%0aConfig-Item:%20APT::Never-MarkAuto-Sections::=universe/metapackages%0aConfig-Item:%20APT::Never-MarkAuto-Sections::=multiverse/metapackages%0aConfig-Item:%20APT::Move-Autobit-Sections::=oldlibs%0aConfig-Item:%20APT::Move-Autobit-Sections::=contrib/oldlibs%0aConfig-Item:%20APT::Move-Autobit-Sections::=non-free/oldlibs%0aConfig-Item:%20APT::Move-Autobit-Sections::=restricted/oldlibs%0aConfig-Item:%20APT::Move-Autobit-Sections::=universe/oldlibs%0aConfig-Item:%20APT::Move-Autobit-Sections::=multiverse/oldlibs%0aConfig-Item:%20APT::Periodic::Update-Package-Lists=1%0aConfig-Item:%20APT::Periodic::Unattended-Upgrade=1%0aConfig-Item:%20APT::Update::Post-Invoke-Success::=/usr/bin/test%2520-e%2520/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service%2520&&%2520/usr/bin/test%2520-S%2520/var/run/dbus/system_bus_socket%2520&&%2520/usr/bin/gdbus%2520call%2520--system%2520--dest%2520org.freedesktop.PackageKit%2520--object-path%2520/org/freedesktop/PackageKit%2520--timeout%25204%2520--method%2520org.freedesktop.PackageKit.StateHasChanged%2520cache-update%2520>%2520/dev/null;%2520/bin/echo%2520>%2520/dev/null%0aConfig-Item:%20APT::Update::Post-Invoke-Success::=if%2520/usr/bin/test%2520-w%2520/var/cache/app-info%2520-a%2520-e%2520/usr/bin/appstreamcli;%2520then%2520appstreamcli%2520refresh%2520>%2520/dev/null;%2520fi%0aConfig-Item:%20APT::Color=false%0aConfig-Item

Bug#828083: bind9: clamav with openssl 1.1: Doesn't find openssl

[Kurt Roeckx]

Source: clamav
Version: 0.99.2+dfsg-2
Severity: important
Control: block 827061 by -1

Hi,

Your package is FTBFS with openssl 1.1:
checking for OpenSSL installation... /usr
checking for SSL_library_init in -lssl... no
configure: error: Your OpenSSL installation is misconfigured or missing
[...]
onfigure:17911: Compiling and linking with libxml2 from /usr
configure:17937: checking for OpenSSL installation
configure:17955: result: /usr
configure:17985: checking for SSL_library_init in -lssl
configure:18010: gcc -o conftest -g -O2 -fPIE -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -D_FILE_OFFSET_BITS=64 -fno-strict-aliasing 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -pie -Wl,-z,relro -Wl,-z,now 
-Wl,--as-needed conftest.c -lssl -lcrypto -lz  >&5
/tmp/ccZwB9kv.o: In function `main':
/<>/clamav-0.99.2+dfsg/conftest.c:124: undefined reference to 
`SSL_library_init'
collect2: error: ld returned 1 exit status
configure:18010: $? = 1
configure: failed program was:
[...]
|builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char SSL_library_init ();
| int
| main ()
| {
| return SSL_library_init ();
|   ;
|   return 0;
| }
configure:18019: result: no
configure:18024: error: Your OpenSSL installation is misconfigured or missing

>From the current manpage:
 The SSL_library_init() and OpenSSL_add_ssl_algorithms() functions
 were deprecated in OpenSSL 1.1.0 by OPENSSL_init_ssl().

There is a compatibity define in ssl.h:
# define SSL_library_init() OPENSSL_init_ssl(0, NULL)


Kurt

Bug#650394: ITP: tigervnc -- High-speed Virtual Network Computing (VNC)

[James Lu]

Control: block 814959 by 650394

Hi everyone,

I managed to compile tigervnc on Jessie by switching to xserver116.patch
and dropping the X 1.18 compat patch. The standalone server works great,
and I can probably do some similar tests too on sid.

TigerVNC is very modern! It supports screen resizing and fixes my
XKEYBOARD issues under Qt5, so I'm really looking forward to seeing it
in Debian!

Best,
James



signature.asc
Description: OpenPGP digital signature

Bug#828082: bind9: FTBFS with openssl 1.1

[Kurt Roeckx]

Source: bind9
Version: 9.10.3.dfsg.P4-10
Severity: important
Control: block 827061 by -1

Hi,

Your package is failing to build with openss 1.1:
checking for OpenSSL library... no
yes
checking for using OpenSSL for hash functions... no
[...]
checking for OpenSSL library... using OpenSSL from /usr/lib and /usr/include
checking whether linking with OpenSSL works... yes
[...]
configure: error: OpenSSL has unsupported dynamic loading
no
[...]
BIND 9 is being built without cryptography support. This means it will
not have DNSSEC support. Use --with-openssl, or --with-pkcs11 and
--enable-native-pkcs11 to enable cryptography.


Kurt

Bug#828081: libfltk1.3-dev: fltk-config imposes internal build flags on the user

[Mike Miller]

Package: libfltk1.3-dev
Version: 1.3.3-8+b1
Severity: normal
Tags: upstream

Dear maintainer,

Please consider fixing or working with upstream to fix how fltk-config
exports compiler flags via --cflags and --cxxflags.

On my system, fltk-config gives the following:

$(fltk-config --cflags).strip().split()
['-I/usr/include/cairo',
 '-I/usr/include/glib-2.0',
 '-I/usr/lib/x86_64-linux-gnu/glib-2.0/include',
 '-I/usr/include/pixman-1',
 '-I/usr/include/freetype2',
 '-I/usr/include/libpng16',
 '-I/usr/include/freetype2',
 '-DCP936',
 '-D_LARGEFILE_SOURCE',
 '-D_LARGEFILE64_SOURCE',
 '-D_THREAD_SAFE',
 '-D_REENTRANT']

$(fltk-config --cxxflags).strip().split()
['-I/usr/include/cairo',
 '-I/usr/include/glib-2.0',
 '-I/usr/lib/x86_64-linux-gnu/glib-2.0/include',
 '-I/usr/include/pixman-1',
 '-I/usr/include/freetype2',
 '-I/usr/include/libpng16',
 '-I/usr/include/freetype2',
 '-I/usr/include/cairo',
 '-I/usr/include/glib-2.0',
 '-I/usr/lib/x86_64-linux-gnu/glib-2.0/include',
 '-I/usr/include/pixman-1',
 '-I/usr/include/freetype2',
 '-I/usr/include/libpng16',
 '-fvisibility-inlines-hidden',
 '-D_LARGEFILE_SOURCE',
 '-D_LARGEFILE64_SOURCE',
 '-D_THREAD_SAFE',
 '-D_REENTRANT']

The -D options should probably not be imposed on users as part of the
fltk API. These should really be up to users and projects to select if
needed/desired.

The -fvisibility-inlines-hidden option should *definitely* not be
imposed on users of fltk just because fltk chose to build itself with
that option.

Basically fltk-config should be much more conservative in what options
it exports to users of the library, and only present the absolute
minimum set of flags needed to build against fltk.

Looks related to earlier bugs #677705, #809825. Ideally can be fixed
upstream as this affects all distributions.


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

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

Versions of packages libfltk1.3-dev depends on:
ii  libfltk-cairo1.3   1.3.3-8+b1
ii  libfltk-forms1.3   1.3.3-8+b1
ii  libfltk-gl1.3  1.3.3-8+b1
ii  libfltk-images1.3  1.3.3-8+b1
ii  libfltk1.3 1.3.3-8+b1
ii  libx11-dev 2:1.6.3-1

Versions of packages libfltk1.3-dev recommends:
ii  fluid  1.3.3-8+b1
ii  libgl1-mesa-dev [libgl-dev]11.2.2-1
ii  libglu1-mesa-dev [libglu-dev]  9.0.0-2.1

Versions of packages libfltk1.3-dev suggests:
ii  fltk1.3-doc1.3.3-8
ii  libcairo2-dev  1.14.6-1+b1
ii  libjpeg-dev1:1.5.0-1
ii  libjpeg62-turbo-dev [libjpeg-dev]  1:1.5.0-1
ii  libpng-dev 1.6.23-1
ii  libxext-dev2:1.3.3-1
ii  libxft-dev 2.3.2-1
ii  libxinerama-dev2:1.1.3-1+b1
ii  zlib1g-dev [libz-dev]  1:1.2.8.dfsg-2+b1

-- no debconf information

Bug#819751:

[Michael Lustfield]

Control: tags 819751 + wontfix

I'm marking this as wontfix with the intention of closing it in the future
if no further discussion is received.

I understand these settings may cause some issues with Apparmor, but this
is an issue that will need to be addressed there and not in nginx. These
current settings allow nginx to handle log file create, rotation, and
writing while maintaining secure defaults.

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

Hello Jerome,

On Fri, Jun 24, 2016 at 4:43 PM, Jerome BENOIT  wrote:
> On 24/06/16 15:21, Giuseppe Bilotta wrote:
>> So the problem is that one of the leftover files prevented the agent
>> from starting.
>
> This is not a problem, this mechanism is meant to allow several sessions
> to use the same agent.

Indeed, and that makes perfect sense. However it does cause issues if
the agent is not actually running, either because it crashed or
because the control file was left over from a previous run.

> What is not normal is that the flag file was not removed: I suspect an 
> accident
> and/or any confusions as it happens at migration time.

In my case, this is probably due to an unclean shutdown. I have two
issues on my machine: one is due to the system never closing down
properly if an NFS mount is active when using systemd as init. The
other is that sometimes my video driver acts up in multi-monitor
setups, especially when switching consoles and running rootless X. I
think that what happened in this case is that my machine went
completely dead after a switch from a rootless X on tty1 to
(framebuffer) console on tty2 and then back, so I was forced to do a
hard reset of the machine without logging off properly. Due to me not
logging off, the control files were still there and were never cleaned
up.

>> May I suggest adding a few more debug outputs centered around starting
>> up the agent? I don't know how it's done in pam_ssh, but if it does
>> some checks before then actually printing on debug "checking for
>> running agents" and maybe "found agent from X file, not starting"?
>
> I am agree that the DEBUG message policy must be revisited.

Indeed, It should be fine to be quite verbose with what's happening,
since it's debug-only output.

>> This would at least hint at the reason why the agent is not being started.
>>
>> (Bonus points: making sure that the agent is actually running and not
>> just some lefover file?)
>
> The leftover file is a flag file (see above).
> How do you suggest to decide whether or not an agent was indeed launched by 
> pam_ssh but not any other process ?

If the flag file contains the PID of the agent it launches, it could
be used to check if the agent is actually running before deciding to
not launch one.

>> (Anyway, the issue is solved for me; maybe demote it to wishlist for
>> the improved checks?)
>
> I guess that we can close it.

Sure.

> Note that you may want to launch the pam_tmpdir module before pam_ssh as 
> pam_ssh honours TMPDIR.

I have not altered the order of the modules myself, so probably the
pam-auth-update configuration file for pam_ssh should specify that it
needs to go after pam_tmpdir?

-- 
Giuseppe "Oblomov" Bilotta

Bug#828080: pyroma: please update pyroma

[Daniel Stender]

Source: pyroma
Severity: wishlist

Hi Federico,

could you please update Pyroma, Prospector 0.12 needs 2.0.2.

Thanks in advance,
Daniel

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

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

Bug#828079: Should not be in "ruby" section

[Josh Triplett]

Package: mkalias
Version: 1.0.10-1
Severity: normal

Applications written in ruby but not providing a ruby library or
development tool shouldn't use the "ruby" section; they should use a
section appropriate to their function.

I would suggest the "utils" section.

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

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

Bug#828078: please backport git-import-orig --merge-mode=[merge|replace] feature

[Nicholas D Steeves]

Package: git-buildpackage
Version: 0.6.22
Severity: wishlist

Dear maintainer,

I've investigated a possible jessie-backport of
git-buildpackage-0.7.5, but I'm not sure if backporting stretch's
bash-completion is allowed or desired.  I looked into this because I'd
really appreciate having the --merge-mode=replace feature for
git-import-orig, which I'd like to use in combination with --uscan.
If it's not too much work, would you please consider backporting this
feature?  Alternatively, please let me know if a backport of 0.7.5 and
associated dependencies is more desirable.

Kind regards,
Nicholas

Bug#822792:

[Michael Lustfield]

Control: tags 822792 +wontfix

We already include conf.d/*.conf which can be used exactly as you
described. In my personal deployments, I remove sites-enabled/default and
only use conf.d/*.conf files.

Is there any reason this doesn't meet your needs?

Bug#828006: systemd: "quiet" kernel boot parameter overrides LogLevel= in /etc/systemd/system.conf

[Brian Kroth]

Michael Biebl  2016-06-23 23:41:

Control: tags -1 + moreinfo

Hi Brian

Am 23.06.2016 um 19:09 schrieb Brian Kroth:
> Per [1], the current version of systemd in Debian Jessie (v215) has an

issue that makes the "quiet" kernel boot parameter override values of
LogLevel= in the /etc/systemd/system.conf file (mine has LogLevel=info
explicitly set) and explicitly sets it to "notice" instead of the
documented default of "info".

There's a simple patch [2] that fixes this that I'd like to suggest
backporting.



That commit seem okayish for a jessie backport



[2]



A simple cherry-pick of 5e07a79e on top of v215 fails.
Have you backported this commit for v215 and given it some testing?
If so, can you attach the (tested) patch to this bug report.

Regards,
Michael


Hi, sorry, I ran out of time before the weekend.  I'll try and finish 
testing that and get back to you sometime on Monday.


I'll note that I had to use the following to cherrypick the patch from 
git since the changes to src/shared/log.c (just comments) failed to 
match anything nearby:


# git format-patch -1 5e07a79e84ab8b045b9df1a2719f14fc84471a1d -- 
src/core/main.c

Cheers,
Brian


signature.asc
Description: Digital signature

Bug#828011: apt 1.3~exp3 is broken

[Eric Valette]

On 24/06/2016 17:18, Eric Valette wrote:

On 24/06/2016 13:47, Eric Valette wrote:


NB: I have the same package installed at work, behind a proxy this time
and it indeed works correctly. Will try to reinstall when back home and
see if it happens again and try to debug it if needed then...


It does not work again. Downgrading immediately restore normal behavior


installed on a second machine at home : idem exp3 is broken.

--eric

Bug#828048: httping: build with TFO support

[Abhijith]

forwarded 828048  https://github.com/flok99/httping/issues/12
thanks Emanuele
-- 
Abhijith PA

Bug#826922: openafs-modules-dkms: FTBFS against linux 4.6: errors in function afs_linux_read_cache: PAGE_CACHE_SIZE undeclared

[Benjamin Kaduk]

Sorry for the delayed reply; this came in while I was on vacation, and I
haven't quite caught up with that chunk of mail yet.

On Fri, 10 Jun 2016, Carl Suster wrote:

> Package: openafs-modules-dkms
> Version: 1.6.18-1
> Severity: important
>
> Dear Maintainer,
>
> Trying to build the openafs dkms module against kernel 4.6.0-1-amd64 results 
> in
> the following errors taken from the attached log:

This is an issue with upstream openafs;
https://gerrit.openafs.org/#/c/12297 has a candidate patch, but it needs
more review and testing.

-Ben

Bug#828077: mate-panel: Mouse focus problem with stack of applications

[Frederic MASSOT]

Package: mate-panel
Version: 1.14.1-1
Severity: normal

Dear Maintainer,

I do not know if it comes from mate-panel.

I have several applications open on my workspaces, application windows are open 
to the maximum, I click on the panel at the bottom of the screen to move from 
one application to another.

After a few hours of use, I have not found a trigger, the application that is 
visible in a workspace is no longer clickable.
It seems that this is an application that is below that is clickable.
To find which application is clickable, I have to click one by one on all the 
buttons on the panel.

I do not know if it's related, but it appears the same time, the libreoffice 
main menu which is normally written in black is written in white.


Regards.


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

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

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-11
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libdbus-1-3  1.10.8-1
ii  libdbus-glib-1-2 0.106-1
ii  libdconf10.26.0-1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgtk-3-0   3.20.6-1
ii  libice6  2:1.0.9-1+b1
ii  libmate-desktop-2-17 1.14.1-1
ii  libmate-menu21.14.0-1
ii  libmate-panel-applet-4-1 1.14.1-1
ii  libmateweather1  1.14.0-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  librsvg2-2   2.40.15-1
ii  libsm6   2:1.2.2-1+b1
ii  libstartup-notification0 0.12-4
ii  libwnck-3-0  3.14.1-2
ii  libx11-6 2:1.6.3-1
ii  libxau6  1:1.0.8-1
ii  libxrandr2   2:1.5.0-1
ii  mate-desktop 1.14.1-1
ii  mate-menus   1.14.0-1
ii  mate-panel-common1.14.1-1
ii  mate-polkit  1.14.0-1
ii  menu-xdg 0.5

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#828076: ruby-saml: CVE-2016-5697

[Salvatore Bonaccorso]

Source: ruby-saml
Version: 1.1.2-1
Severity: grave
Tags: security upstream patch fixed-upstream

Hi,

the following vulnerability was published for ruby-saml.

CVE-2016-5697[0]:
signature wrapping attack vulnerability

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-5697

Regards,
Salvatore

Bug#828075: RM: mysql-mmm-agent -- ROM; Software is not maintained for years and should not be used anymore as there are way better alternatives around.

[Pascal Hofmann]

Package: ftp.debian.org
Severity: normal

Bug#827915:

[Jordi Pujol Palomer]

El Fri, 24 Jun 2016 10:58:09 +0200
David Kalnischkies  escrigué:

> I don't know how I could look any closer at this, so you will have to
> be more specific – 
Yes, I agree,

> and you have to realize that if we find a bug in
> which apt is storing a package without an epoch which has one, the
> fix will be to store it with an epoch, not change all other places to
> not store it with an epoch.

Obviously, now I see that it's the right way to do.

> 
> 
> Is there perhaps some silly "download accelerator" like apt-fast
> involved? (Wich we STRONGLY advise against using!)
> 

I have done a clean install of another system including only the basic
apt-related utilities, This new system does it well, so the problem is
gone.

When having more time will try to isolate the problem, but for now I
consider that this bug report may be closed,

Thanks and sorry for the noise,

Jordi Pujol i Palomer

Bug#828074: gcin: please make the build reproducible

[Chris Lamb]

Source: gcin
Version: 2.8.4+dfsg1-6
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that gcin 
could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


gcin.diff.txt
Description: Binary data

Bug#826684: /usr/bin/spin in "staden" and /usr/bin/spin in "spin"

[Andreas Tille]

Hi,

I'm not a staden user - just packaging it.  Could somebody please
comment on the considerations below?

Thanks

  Andreas.

On Sat, Jun 11, 2016 at 04:47:56PM -0700, tony mancill wrote:
> Hello,
> 
> I'm not familiar with staden, but am taking a look at it and see that
> /usr/bin/spin is symlinked -> /usr/bin/gap4, and that is essentially a
> wrapper script that run things from /usr/lib/staden/bin/ (or BINDIR).
> 
> I also noticed that invoking "staden" returns a list of those file in
> the BINDIR, so invoking "staden spin" would still work without a
> /usr/bin/spin file shipped with the staden package.  Of course, there's
> still the question of the manpage.
> 
> For the "spin" binary in the "spin" package, there isn't such a
> mechanism available, so it would be more of a "think of a suitable name
> and update the Debian documentation and README appropriately" exercise.
> 
> I assume "spin" has been called "spin" since its inception in staden
> [1], and it's the same for the spin package [2].  Both projects appear
> active and viable, so I see this as a question of trying to make a
> sensible choice for our users (which I see as the choice that causes the
> least confusion and disruption).  However, I don't pretend to know what
> that is, I'm just hoping to start the conversation around this bug.  It
> seems like the packages aren't likely to be co-installed, but my
> understanding is that policy frowns upon simply having them conflict
> with each other.
> 
> Is there any chance the staden maintainers would consider renaming the
> wrapper in /usr/bin to "spin-gui" or something similar?  Or perhaps spin
> (software verification) might become spin-verify?
> 
> Thank you,
> tony
> 
> [1] http://staden.sourceforge.net/
> [2] http://spinroot.com/spin/whatispin.html
> 




> ___
> 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#828073: ITP: prometheus-alertmanager -- Handle and deliver alerts created by Prometheus

[Martín Ferrari]

Package: wnpp
Severity: wishlist
Owner: "Martín Ferrari" 

* Package name: prometheus-alertmanager
  Version : 0.2.1
  Upstream Author : The Prometheus Authors
* URL : https://prometheus.io/
* License : Apache-2
  Programming Lang: Go
  Description : Handle and deliver alerts created by Prometheus

 The Alertmanager handles alerts sent by client applications such as the
 Prometheus server. It takes care of deduplicating, grouping, and routing them
 to the correct receiver integration such as email, PagerDuty, or OpsGenie. It
 also takes care of silencing and inhibition of alerts.

Bug#828009: Typo in package description

[Martin Michlmayr]

* Marc Dietrich  [2016-06-24 09:57]:
> > Package: cbootimage
> > Version: 1.4-1
> > Severity: minor
> > 
> > | bootloader (e.g. u-boot) read to be flashed to a storage device.
> > 
> > read -> ready ?
> 
> yes. Does this require a re-submisson?

Sorry, I noticed this after I uploaded the package.

It requires a new upload but it's not urgent, so you can wait for
other fixes/change if you want.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#828072: golang-gopkg-ini.v1: please make the build reproducible

[Chris Lamb]

Source: golang-gopkg-ini.v1
Version: 1.8.5-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that 
golang-gopkg-ini.v1 could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


golang-gopkg-ini.v1.diff.txt
Description: Binary data

Bug#828071: gnome-contacts: Can't add a note to a contact

[FERREC Romain]

Package: gnome-contacts
Version: 3.20.0-1
Severity: normal

Dear Maintainer,

When I create a contact and I populates the field "note"; after saving, the
note was not added to the contact.
This issue only affects gnome-contact (evolution does not have this problem).

Cordialy.



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

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

Versions of packages gnome-contacts depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-12
ii  libcairo21.14.6-1+b1
ii  libchamplain-0.12-0  0.12.13-1
ii  libcheese-gtk25  3.20.2-2
ii  libcheese8   3.20.2-2
ii  libclutter-1.0-0 1.26.0-2
ii  libclutter-gtk-1.0-0 1.8.0-1
ii  libedataserver-1.2-213.20.3-1
ii  libedataserverui-1.2-1   3.20.3-1
ii  libfolks-eds25   0.11.2-1
ii  libfolks-telepathy25 0.11.2-1
ii  libfolks25   0.11.2-1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libgee-0.8-2 0.18.0-2
ii  libgeocode-glib0 3.20.1-1
ii  libglib2.0-0 2.48.1-1
ii  libgnome-desktop-3-123.20.2-1
ii  libgoa-1.0-0b3.20.1-1
ii  libgtk-3-0   3.20.6-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libtelepathy-glib0   0.24.1-1.1

gnome-contacts recommends no packages.

gnome-contacts suggests no packages.

-- no debconf information

Bug#827082: RFS: libredjackipset/1.1.1+20150311-1 [ITP] -- C library to store sets/maps of IP address

[Gianfranco Costamagna]

Hi,

>I think you build on ubuntu, so without "--builddirectory stuff" the
>build directory is
>build-*/
>When I tested in Debian, the build directory is obj-*/
>That's why I insist keeping "--builddirectory stuff" to make same
>install file for both Debian and Ubuntu.


nope, Ubuntu calls it obj-*
for some reasons the package was built, but empty.

So, just changing to obj-* is fine (tested on unstable/yakkety)

Mine was just a stupid typo, and the package was building fine, so I didn't
pay attention to the built deb file.
dpkg -c of it is correct now.

>Already posted to https://github.com/redjack/ipset/issues/41
>But I don't think there will be a clear reply.


sad, lets hope for the best

somebody accepted my pull request
https://github.com/redjack/ipset

so, whoever has write access is still around

>I think the upstream (the original author and redjack) know what we're
>doing here, and if they aren't against here, we can just upload.


seems an acceptable solution

>Explained before you asked me. No reply yet.


yep

>Thanks for your patch, applied well.

wonderful


>Applied.

ok

>Thanks for your suggestion!

lets hope a little more for upstream, and then I guess we are good.

G.

Bug#761083: #761083 - debsources: inject binary packages metadata into the DB

[Matthieu Caneill]

On Fri, Jun 24, 2016 at 04:41:57PM +0200, Raphael Hertzog wrote:
> > I don't mind at all you using sources.d.n for that purpose, but why
> > not tracker.d.o?
> 
> I thought the same when I saw this report... and the reason is likely that
> the tracker has almost no REST API at all right now and that it thus looked
> harder to implement there.

Thanks for the clarification Raphael!
Makes sense indeed to use debsources for that purpose.

Cheers,
--
Matthieu

Bug#827082: RFS: libredjackipset/1.1.1+20150311-1 [ITP] -- C library to store sets/maps of IP address

[Roger Shimizu]

Sorry, the subject of this email thread should be changed to:
Re: Bug#827082: RFS: libcorkipset/1.1.1+20150311-1 [ITP] -- C library
to store sets/maps of IP address
 

It was not because I want to keep the shape of the thread :-P

Bug#807880: apparmor-profiles-extra: AppArmor profile prevents evince from starting under wayland

[intrigeri]

Control: reassign -1 apparmor
Control: retitle -1 Missing/incomplete abstractions for starting Evince under 
Wayland
Control: affects -1 + evince
Control: notfound -1 apparmor-profiles-extra/1.6
Control: found -1 apparmor/2.10.95-2

The evince profile moved to the evince package, so that's not an
apparmor-profiles-extra bug anymore. Still, IMO this should be
resolved in an abstraction, not in the evince profile itself, so
reassigning to the apparmor package, that ships the most
common abstractions.

Bug#828070: me-tv task persists on application exit

[Evangelos Skarmoutsos]

Package: me-tv
Version: 1.3.7-1+b2
Severity: normal

Dear Maintainer,

When a user exits me-tv application using either the top-right application
window button or the top screen menu (me-tv)-exit, then a task called me-tv-
player is killed but a task called me-tv persists.

If the application is terminated using menu File-Quit, then both tasks are
killed as expected.

This behavior was noticed when trying to pgrep me-tv after application was
closed.



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

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

Versions of packages me-tv depends on:
ii  gconf2  3.2.6-3
ii  libatkmm-1.6-1v52.24.2-1
ii  libc6   2.22-11
ii  libdbus-1-3 1.10.8-1
ii  libdbus-glib-1-20.106-1
ii  libgcc1 1:6.1.1-4
ii  libgconfmm-2.6-1v5  2.28.0-2
ii  libglib2.0-02.48.1-1
ii  libglibmm-2.4-1v5   2.48.1-1
ii  libgtk2.0-0 2.24.30-2
ii  libgtkmm-2.4-1v51:2.24.4-2+b1
ii  libsigc++-2.0-0v5   2.8.0-1
ii  libsqlite3-03.13.0-1
ii  libstdc++6  6.1.1-4
ii  libunique-1.0-0 1.1.6-5
ii  libx11-62:1.6.3-1
ii  libxine21.2.6-1.1+b1
ii  libxine2-ffmpeg 1.2.6-1.1+b1
ii  libxine2-x  1.2.6-1.1+b1

Versions of packages me-tv recommends:
ii  dvb-apps  1.1.1+rev1500-1.1

me-tv suggests no packages.

-- no debconf information

Bug#827082: RFS: libredjackipset/1.1.1+20150311-1 [ITP] -- C library to store sets/maps of IP address

[Roger Shimizu]

[CC upstream]
[Douglas & John are original author of this library, and Greg
currently has write permission to git repo on github]

Dear G,

Thanks for your time to review again!

On Thu, Jun 23, 2016 at 1:00 AM, Gianfranco Costamagna
 wrote:
> Hi Roger
>
>>> cat debian/libcorkipset-doc.docs
>
>>> build-*/docs/html
>>
>>Debian builds obj- by default.
>>So it seems to specify "--builddirectory=build" safe for both debian and 
>>ubuntu.
>
>
> yes, but useless...
> maybe you didn't get completely the hint, but my guess was:
>
> remove the --builddirectory stuff
> and change
>
> build/docs/html
>
> to
> build-*/docs/html
>
> probably this sounds stupid/nitpick to you, but allows
> people to easily cross-compile stuff, or to compile the library for
> both amd64 and i386 without having to choose one or the other.
> that triplet is trivial, and makes less confusion to porters
> or even developer, who might want to build it on their own laptop
> and use on different architectures.
>
>
> (note: this isn't a blocker)

I think you build on ubuntu, so without "--builddirectory stuff" the
build directory is
build-*/
When I tested in Debian, the build directory is obj-*/
That's why I insist keeping "--builddirectory stuff" to make same
install file for both Debian and Ubuntu.

>>Yes, upstream just don't like calling it libredjackipset.
>>They seems fine with libcorkipset, but proposed another option: libipaddrset
>
> I'll wait for them make a decision then

Already posted to https://github.com/redjack/ipset/issues/41
But I don't think there will be a clear reply.

> so, please consider applying my above fixes, and ask me to 
> sponsor&upload&review
> when upstream releases a new fixed renamed tarball
> (this should even avoid your dh_install override if I'm correctly 
> understanding it)

The original author (in CC list) left redjack, so now they don't have
write access to that repo, and cannot release a new version with new
name.

I think the upstream (the original author and redjack) know what we're
doing here, and if they aren't against here, we can just upload.


>>I don't like the latter one because the header will be installed to
>>/usr/include/libipaddrset/ipset.h
>>and user need to "#include "
>>
>>I think "#include " makes more sense.
>
>
> just explain that upstream :)
>
> I honestly don't care too much, but I want to use the name that upstream 
> choose
> to avoid overcomplicate things in the long run

Explained before you asked me. No reply yet.

>>"LIB_SUFFIX" is added to patch.
>
>
> bad me, it didn't work :(
> the patch wasn't correct, because the variable gets overridden anyway on the 
> following line.
>
> I tweaked the patch, to do something like
> +if(NOT CMAKE_INSTALL_LIBDIR)
> +set(CMAKE_INSTALL_LIBDIR lib CACHE STRING
> + "The base name of the installation directory for libraries")
> +endif(NOT CMAKE_INSTALL_LIBDIR)
>
>
> otherwise no matter who sets it, it gets defaulted to what upstream thinks it 
> is better for everybody.

Thanks for your patch, applied well.


> BTW I can't run dpkg-buildpackage twice, because a "RELEASE-VERSION" file is 
> added to the source
> tree
>
> echo RELEASE-VERSION > debian/clean might just fix that

Applied.
Thanks for your suggestion!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#827936: po4a: please implement support for Ruby document format

[Francesco Poli]

On Fri, 24 Jun 2016 11:36:46 +0200 Martin Quinson wrote:

> Hello,

Hello Martin, thanks for your prompt reply.

> 
> the truth is that the development of po4a is kinda stopped since a few
> years. We do the basic maintainance, like reviewing and applying
> proposed patches (with some delays), but I don't manage to devote any
> time to the new wanted features myself. I'm sorry about that, but this
> is a fact.

OK, I assume the same holds for the other upstream authors of po4a
(or do you just speak for yourself?).

> 
> As a result, I think that you should develop this module yourself.

I can try, with some help from you and the other po4a upstream
developers.

> I
> understand that Perl will make your brain burn as a Ruby programmer,

My brain is probably already burnt, due to overexposure to Fortran, but
I digress...;-)

The fact is that I haven't programmed in Perl for about 14 years and my
Perl knowledge was just a smattering anyway, so bear with me!

> but at the end, developping a new module for po4a is very easy. And I
> can guide you in this process if you go that way.

Your guidance will be much appreciated, thanks a lot!

> 
> Check the doc on writing a new module, here:
>   man Locale::Po4a::TransTractor

I will study this soon, thanks for pointing it out.
In the meanwhile, I have to study the Ruby document format description
in more detail.

> 
> I think that this is a good idea to keep both the upstream list and
> the debian bug in CC while discussing it. It will ensure both a good
> diffusion and a good archiving of the discussions.

OK, I am replying to both the bug address and the po4a-devel mailing
list.
Please keep me in Cc, when replying (as I am not subscribed to the
mailing list or to the bug). Thanks.

Bye.

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


pgpoQhLZj5zQk.pgp
Description: PGP signature

Bug#827939: Please consider marking mesa-utils as Multi-Arch: allowed

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 24 de junio de 2016 11:08:32 A. M. ART Julien Cristau wrote:
> On Thu, Jun 23, 2016 at 10:11:45 -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > Question: if a user has a video card wich is OpenGL2 or more capable but
> > does not has libgl1-mesa-dri installed: does glxinfo informs "OpenGL
> > version string:" with value 2 or more?
> 
> They could be using a non-mesa driver.

OK, now I'm beggining to understand how this works. Depending on each video 
card implementation it might require an associated -dri package.

Also glxutils will output the current OpenGL version supported depending 
wether the video card supports it and the required software is installed.

If this is the case then this bug is indeed still valid, and now a more 
important as before, as we can warn users wether they video card with their 
current setup does supports OepnGL2+ or not.

Of course, if I missinterpreted something then please do not hasitate in 
remarking it :)

Thanks in advance, Lisandro.


-- 
16: De quien es Internet
* De DIOS dado que todas las cosas del mundo le pertenecen
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#805546: apparmor-profiles-extra: AppArmor profile prevents pidgin from starting

[intrigeri]

Hi pidgin-sipe maintainers!

intrigeri wrote (30 Dec 2015 11:32:19 GMT) :
> Guido Günther wrote (19 Nov 2015 13:29:13 GMT) :
>> $ dpkg -S  /usr/bin/pidgin.orig 
>> diversion by pidgin-sipe from: /usr/bin/pidgin
>> diversion by pidgin-sipe to: /usr/bin/pidgin.orig

>> It's a shell wrapper:

>> 
>> #!/bin/bash

>> CONF=/etc/default/pidgin-sipe

>> if [[ -r $CONF ]]
>> then
>> . $CONF 
>> fi

>> /usr/bin/pidgin.orig $*
>> 

> OK, got it, thanks! I had a quick look.

> It seems that this wrapper [1] and the corresponding 'default' file
> [2] were introduced three years ago in pidgin-sipe 1.13.1-2.1, as
> a way to make it slightly easier for users of to communicate with
> Microsoft OCS/Lync servers that had not got the fixes for the BEAST
> attack (CVE-2011-3389) yet. This workaround that apparently was meant
> to be temporary [3]. My understanding is that Microsoft published the
> fixes needed server-side on 2012-01-10 ([4], [5]). I would hope that
> the server-side situation has evolved a bit in four years, wrt.
> supporting BEAST fixes.

> With this in mind, I'm not super excited at the idea of modifying the
> Pidgin profile to support this possibly obsolete workaround: I'd like
> to first see its relevance reconsidered among pidgin-sipe maintainers.
> Was it done recently?

> If they decide it's worth keeping the workaround in testing/sid, then
> yay, why not, let's check what exact modifications the dpkg-divert
> + wrapper technique requires on our side, and consider adding them to
> the profile somehow (possibly #include'ing a file that could be
> shipped by pidgin-sipe?).

> Fair enough?

> [1] https://sources.debian.net/src/pidgin-sipe/1.20.0-2/debian/extra/pidgin/
> [2] 
> https://sources.debian.net/src/pidgin-sipe/1.20.0-2/debian/extra/pidgin-sipe/
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642199#76
> [4] https://technet.microsoft.com/library/security/ms12-006
> [5] https://support.microsoft.com/en-us/kb/2643584

Ping?

Cheers,
--
intrigeri

Bug#828069: Acknowledgement (icedove: random crashes after latest security update)

[Paul Hayes]

backtrace is attached here


On 24/06/16 16:39, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
   p...@polog40.co.uk
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
  Christoph Goehre 

If you wish to submit further information on this problem, please
send it to 828...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.



MOZILLA_FIVE_HOME=/usr/lib/icedove
  LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
DISPLAY=:0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
 LIBRARY_PATH=
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
  LIBPATH=/usr/lib/icedove:/usr/lib/icedove
   ADDON_PATH=
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
moz_debugger_args=
/usr/bin/gdb  --args /usr/lib/icedove/icedove-bin
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from /usr/lib/debug//usr/lib/icedove/icedove-bin...done.
done.
(gdb) run
Starting program: /usr/lib/icedove/icedove-bin 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe7f23700 (LWP 27358)]
[Thread 0x7fffe7f23700 (LWP 27358) exited]
Gtk-Message: Failed to load module "canberra-gtk-module"
[New Thread 0x7fffe7f23700 (LWP 27361)]
[New Thread 0x7fffe0bff700 (LWP 27362)]
[New Thread 0x77fee700 (LWP 27363)]
[New Thread 0x7fffe03fe700 (LWP 27364)]
[New Thread 0x7fffdf8ff700 (LWP 27365)]
[New Thread 0x7fffdf6fe700 (LWP 27366)]
[New Thread 0x7fffdf4fd700 (LWP 27367)]
[New Thread 0x7fffdf2fc700 (LWP 27368)]
[New Thread 0x7fffdf0fb700 (LWP 27369)]
[New Thread 0x7fffdeefa700 (LWP 27370)]
[New Thread 0x7fffdecf9700 (LWP 27371)]
[New Thread 0x7fffdeaf8700 (LWP 27372)]
[New Thread 0x7fffdd7ff700 (LWP 27373)]
[New Thread 0x7fffdcbff700 (LWP 27374)]
[New Thread 0x7fffdc3fe700 (LWP 27375)]
[New Thread 0x76ddd700 (LWP 27376)]
[New Thread 0x7fffdb7ff700 (LWP 27377)]
[New Thread 0x7fffda491700 (LWP 27378)]
[New Thread 0x7fffd9c90700 (LWP 27379)]
[New Thread 0x7fffd74ff700 (LWP 27380)]
[calBackendLoader] Using libical backend at /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
[New Thread 0x7fffd5eff700 (LWP 27381)]
[New Thread 0x7fffd4b41700 (LWP 27382)]
[New Thread 0x7fffd36ff700 (LWP 27383)]
[New Thread 0x7fffd2efe700 (LWP 27384)]
[New Thread 0x7fffd26fd700 (LWP 27385)]
[New Thread 0x7fffd1efc700 (LWP 27386)]
[New Thread 0x7fffd16fb700 (LWP 27387)]
[New Thread 0x7fffd0efa700 (LWP 27388)]
[New Thread 0x7fffd06f9700 (LWP 27389)]
[New Thread 0x7fffcfcff700 (LWP 27390)]
[New Thread 0x7fffcf4fe700 (LWP 27391)]
[New Thread 0x7fffcecfd700 (LWP 27392)]
[New Thread 0x7fffce4fc700 (LWP 27393)]
[New Thread 0x7fffcdcfb700 (LWP 27394)]
[Thread 0x7fffd74ff700 (LWP 27380) exited]
[New Thread 0x7fffcd2ff700 (LWP 27395)]
[Thread 0x7fffcecfd700 (LWP 27392) exited]
[Thread 0x7fffce4fc700 (LWP 27393) exited]
[New Thread 0x7fffcc8ff700 (LWP 27396)]
[Thread 0x7fffcdcfb700 (LWP 27394) exited]
[New Thread 0x7fffcdcfb700 (LWP 27397)]
[New Thread 0x7fffce4fc700 (LWP 27398)]
[Thread 0x7fffcd2ff700 (LWP 27395) exited]
[New Thread 0x7fffcd2ff700 (LWP 27399)]
[New Thread 0x7fffcecfd700 (LWP 27400)]
[Thread 0x7fffce4fc700 (LWP 27398) exited]
[Thread 0x7fffcd2ff700 (LWP 27399) exited]
[New Thread 0x7fffce4fc700 (LWP 27401)]
[Thread 0x7fffcecfd700 (LWP 27400) exited]
[New Thread 0x7fffcecfd700 (LWP 27402)]
[Thread 0x7fffce4fc700 (LWP 27401) exited]
[New Thread 0x7fffce4fc700 (LWP 27403)]
[New Thread 0x7fffcd2ff700 (LWP 27404)]
[Thread 0x7fffcd2ff700 (LWP 27404) exited]
[Thread 0x7fffce4fc700 (LWP 27403) exited]
[New Thread 0x7fffce4fc700 (LWP 27406)]
[New Thread 0x7fffcd2ff700 (LWP 27407)]
[Thread 0x7fffcecfd700 (LWP 27402) exited]
[Threa

Bug#828069: icedove: random crashes after latest security update

[Paul Hayes]

Package: icedove
Version: 1:45.1.0-1~deb8u1
Severity: important

Dear Maintainer,

we have around ten users here using the latest icedove version from 
security.debian.net as above.  Since this latest update we have been 
experiencing random crashes, every one is using a similar Debian configuration 
(controlled with Ansible).

Some users have a custom made plugin, some do not.  The issue affects all users.



-- System Information:
Debian Release: 8.5
  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_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 icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u4
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpixman-1-0 0.32.6-3
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.1.0-1~deb8u1

Versions of packages icedove suggests:
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.12.1+dfsg-19+deb8u2

-- no debconf information

Bug#828068: mixxx: Compile Mixxx for jessie-backports

[diogo]

Package: mixxx
Version: 2.0.0~dfsg-4
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation? Old version on stable
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Compiled 2.0.0 for jessie without lib problems
   * What was the outcome of this action? I could use mixxx without problems
   * What outcome did you expect instead? That someone could compile and send 
to jessie-backports

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


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

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

Versions of packages mixxx depends on:
ii  libc6 2.19-18+deb8u4
ii  libchromaprint0   1.2-1
ii  libflac8  1.3.0-3
ii  libgcc1   1:4.9.2-10
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libhidapi-libusb0 0.8.0~rc1+git20140201.3a66d4e+dfsg-3
ii  libid3tag00.15.1b-11
ii  libmad0   0.15.1b-8
ii  libogg0   1.3.2-1
ii  libopusfile0  0.6-1
ii  libportaudio2 19+svn20140130-1
ii  libportmidi0  1:184-2.2
ii  libprotobuf-lite9 2.6.1-1
ii  libqt4-network4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-script 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-scripttools4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-sql4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-sql-sqlite 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-svg4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-xml4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  librubberband21.8.1-6
ii  libshout3 2.3.1-3
ii  libsndfile1   1.0.25-9.1+deb8u1
ii  libsoundtouch01.8.0-1
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstdc++64.9.2-10
ii  libtag1c2a1.9.1-2.1
ii  libusb-1.0-0  2:1.0.19-1
ii  libvamp-hostsdk3  2.5+repack0-2
ii  libvamp-sdk2  2.5+repack0-2
ii  libvorbis0a   1.3.4-2
ii  libvorbisenc2 1.3.4-2
ii  libvorbisfile31.3.4-2
ii  libx11-6  2:1.6.2-3
ii  mixxx-data2.0.0~dfsg-4

mixxx recommends no packages.

Versions of packages mixxx suggests:
ii  evince [pdf-viewer]  3.14.1-2+deb8u1

-- no debconf information

Bug#828067: grib-api: please make the build reproducible

[Chris Lamb]

Source: grib-api
Version: 1.15.0-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that 
grib-api could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2016-06-24 10:33:19.912495679 +0200
--- b/debian/rules  2016-06-24 17:01:02.304538721 +0200
@@ -100,6 +100,9 @@
  tests/statistics.out tests/x.grib \
  data/change_scanning_rotated_ll.filter examples/F90/index.idx
 
+override_dh_installexamples:
+   dh_installexamples -X.pyc
+
 override_dh_fixperms-arch:
dh_fixperms
chmod +x 
debian/libgrib-api0/usr/share/grib_api/definitions/installDefinitions.sh

Bug#828011: apt 1.3~exp3 is broken

[Eric Valette]

On 24/06/2016 13:47, Eric Valette wrote:


NB: I have the same package installed at work, behind a proxy this time
and it indeed works correctly. Will try to reinstall when back home and
see if it happens again and try to debug it if needed then...


It does not work again. Downgrading immediately restore normal behavior

 -install ~exp3 
apt-get -t experimental install apt apt-utils libapt-inst2.0 libapt-pkg5.0
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Le paquet suivant a été installé automatiquement et n'est plus nécessaire :
  libgl2ps1
Veuillez utiliser « apt autoremove » pour le supprimer.
Paquets suggérés :
  apt-doc
Les paquets suivants seront mis à jour :
  apt apt-utils libapt-inst2.0 libapt-pkg5.0
4 mis à jour, 0 nouvellement installés, 0 à enlever et 47 non mis à jour.
Il est nécessaire de prendre 2 573 ko dans les archives.
Après cette opération, 21,5 ko d'espace disque supplémentaires seront 
utilisés.
Réception de:1 ftp://ftp.fr.debian.org/debian experimental/main amd64 
libapt-pkg5.0 amd64 1.3~exp3 [842 kB]
Réception de:2 ftp://ftp.fr.debian.org/debian experimental/main amd64 
libapt-inst2.0 amd64 1.3~exp3 [184 kB]
Réception de:3 ftp://ftp.fr.debian.org/debian experimental/main amd64 
apt amd64 1.3~exp3 [1 157 kB]
Réception de:4 ftp://ftp.fr.debian.org/debian experimental/main amd64 
apt-utils amd64 1.3~exp3 [390 kB]

apt apt-utils libapt-inst2.0 libapt-pkg5.0
4 mis à jour, 0 nouvellement installés, 0 à enlever et 47 non mis à jour.
Il est nécessaire de prendre 2 573 ko dans les archives.
Après cette opération, 21,5 ko d'espace disque supplémentaires seront 
utilisés.
Réception de:1 ftp://ftp.fr.debian.org/debian experimental/main amd64 
libapt-pkg5.0 amd64 1.3~exp3 [842 kB]
Réception de:2 ftp://ftp.fr.debian.org/debian experimental/main amd64 
libapt-inst2.0 amd64 1.3~exp3 [184 kB]
Réception de:3 ftp://ftp.fr.debian.org/debian experimental/main amd64 
apt amd64 1.3~exp3 [1 157 kB]
Réception de:4 ftp://ftp.fr.debian.org/debian experimental/main amd64 
apt-utils amd64 1.3~exp3 [390 kB]

2 573 ko réceptionnés en 2s (966 ko/s)
(Lecture de la base de données... 397078 fichiers et répertoires déjà 
installés.)

Préparation du dépaquetage de .../libapt-pkg5.0_1.3~exp3_amd64.deb ...
Dépaquetage de libapt-pkg5.0:amd64 (1.3~exp3) sur (1.3~exp2) ...
Traitement des actions différées (« triggers ») pour libc-bin 
(2.23-0experimental2) ...

Paramétrage de libapt-pkg5.0:amd64 (1.3~exp3) ...
Traitement des actions différées (« triggers ») pour libc-bin 
(2.23-0experimental2) ...
(Lecture de la base de données... 397078 fichiers et répertoires déjà 
installés.)

Préparation du dépaquetage de .../libapt-inst2.0_1.3~exp3_amd64.deb ...
Dépaquetage de libapt-inst2.0:amd64 (1.3~exp3) sur (1.3~exp2) ...
Préparation du dépaquetage de .../apt_1.3~exp3_amd64.deb ...
Dépaquetage de apt (1.3~exp3) sur (1.3~exp2) ...
Traitement des actions différées (« triggers ») pour libc-bin 
(2.23-0experimental2) ...

Traitement des actions différées (« triggers ») pour man-db (2.7.5-1) ...
Paramétrage de apt (1.3~exp3) ...
Traitement des actions différées (« triggers ») pour libc-bin 
(2.23-0experimental2) ...
(Lecture de la base de données... 397078 fichiers et répertoires déjà 
installés.)

Préparation du dépaquetage de .../apt-utils_1.3~exp3_amd64.deb ...
Dépaquetage de apt-utils (1.3~exp3) sur (1.3~exp2) ...
Traitement des actions différées (« triggers ») pour man-db (2.7.5-1) ...
Paramétrage de libapt-inst2.0:amd64 (1.3~exp3) ...
Paramétrage de apt-utils (1.3~exp3) ...
Traitement des actions différées (« triggers ») pour libc-bin 
(2.23-0experimental2) ...


--- failure immediately after install ---

tri-yann4:/home/valette# apt-get update
Ign:1 http://www.deb-multimedia.org unstable InRelease
Ign:2 http://www.deb-multimedia.org experimental InRelease 

Ign:3 http://dl.google.com/linux/chrome/deb stable InRelease 

Err:4 http://www.deb-multimedia.org unstable Release 


  Mauvaise ligne d'en-tête
Err:5 http://www.deb-multimedia.org experimental Release 


  Mauvaise ligne d'en-tête
Ign:6 http://download.virtualbox.org/virtualbox/debian jessie InRelease 

Err:7 http://download.virtualbox.org/virtualbox/debian jessie Release 


  0  OK [IP : 2.18.245.43 80]
Err:8 http://dl.google.com/linux/chrome/deb stable Release
  Format de date inconnu
Réception de:9 ftp://ftp.fr.debian.org/debian unstable InRelease [205 kB]
Réception de:10 ftp://ftp.fr.debian.org/debian experimental InRelease 
[107 kB]

Lecture des listes de paquets... Fait
E: The repository 'http://www.deb-multimedia.org unstable Release' does 
no longer have a Release file.
N: Updating from such a repository can't be done securely, and is 
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user 
configuration details.
E: The repository 'http://www.deb-multimedia.org experimental Release' 
does no lon

Bug#828066: gsmlib: please make the build reproducible

[Chris Lamb]

Source: gsmlib
Version: 1.10+20120414.gita5e5ae9a-0.3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that gsmlib 
could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


gsmlib.diff.txt
Description: Binary data

Bug#828065: hmmer2: please make the build reproducible

[Chris Lamb]

Source: hmmer2
Version: 2.3.2-10
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that hmmer2 
could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


hmmer2.diff.txt
Description: Binary data

Bug#827500: Adopting pyzor

[Hugo Lefeuvre]

Hi Carl,

I'll adopt pyzor. 

Thanks for your work on this package.

Cheers,
 Hugo

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Bug#828062: murano: CVE-2016-4972: RCE vulnerability in Openstack Murano using insecure YAML tags

[Salvatore Bonaccorso]

Source: murano
Version: 1:2.0.0-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

the following vulnerability was published for murano.

CVE-2016-4972[0]:
RCE vulnerability in Openstack Murano using insecure YAML tags

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-4972
[1] http://seclists.org/oss-sec/2016/q2/593

Regards,
Salvatore

Bug#828061: libdvdnav4: breaks mplayer2 from wheezy

[Hartmut Buhrmester]

Package: libdvdnav4
Version: 5.0.1-1~bpo70+1

libdvdnav4 version 5.0.1 from Debian 7 wheezy-backports is not 
compatible with mplayer2 from Debian 7 wheezy. mplayer2 shows the error 
message:


mplayer: error while loading shared libraries: libdvdnavmini.so.4: 
cannot open shared object file: No such file or directory


Tested versions:

libdvdnav4  5.0.1-1~bpo70+1 wheezy-backports
mplayer22.0-554-gf63dbad-1+deb7u1   oldstable

This bug has been discussed before 
, and it was 
solved by adding a rule to prevent installing an incompatible version of 
libdvdnav4.


For unknown reasons, this rule was deleted later, and only the rules 
"breaks mplayer/mencoder" are still there. These rules were introduced 
in bug report #759199.


But recently libdvdnav4 5.0.1 was released in wheezy-backports, and it 
still is incompatible with mplayer2 from wheezy.


libdvdnav4 version 5 does work with mplayer2 from Debian 8 Jessie.

Fortunately, the old workaround of creating a symbolic link still works:

~# cd /usr/lib/i386-linux-gnu/
/usr/lib/i386-linux-gnu# ln -s libdvdnav.so.4 libdvdnavmini.so.4

--
Hartmut Buhrmester

Bug#828059: ITP: google-android-m2repository-installer -- This is a packaged script that automatically downloads Google's Android support m2 repository package and unpacks it into Debian-friendly path

[Mouaad Aallam]

> Just to avoid any doubt (and since you didn't mention): Due to the
> nature of the package, I assume it will be targeted contrib (not the
> main archive), right?

Yes, exactly.

Regards,
*Mouaad Aallam*

Bug#828059: ITP: google-android-m2repository-installer -- This is a packaged script that automatically downloads Google's Android support m2 repository package and unpacks it into Debian-friendly path

[Jonas Smedegaard]

Quoting Mouaad Aallam (2016-06-24 16:17:18)
> Package: wnpp
> Severity: wishlist
> Owner: Mouaad Aallam 
> 
> * Package name: google-android-m2repository-installer
>   Version : 33.0.0
>   Upstream Author : Google, Inc.
> * URL : 
> https://developer.android.com/topic/libraries/support-library/index.html
> * License : Apache 2.0
>   Programming Lang: C, Java, Bash
>   Description : Google Android Support m2 repository
> 
> This package will download the Google Android Support Libary 
> repository and create a Debian package.

Just to avoid any doubt (and since you didn't mention): Due to the 
nature of the package, I assume it will be targeted contrib (not the 
main archive), right?


 - 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#761083: #761083 - debsources: inject binary packages metadata into the DB

[Raphael Hertzog]

Hi,

On Fri, 24 Jun 2016, Matthieu Caneill wrote:
> On Thu, Jun 09, 2016 at 12:01:09PM +0200, Luciano Bello wrote:
> > In the security team we would like to give information about which packages 
> > you should update when we release a DSA (currently, we give to the user the 
> > source package name). It would be easier for us if we have a way to get the 
> > binaries for packages in (old)stable. Sources.d.n is the way to go, I 
> > think. 
> > For that, this bug needs to be done :)
> 
> I don't mind at all you using sources.d.n for that purpose, but why
> not tracker.d.o?

I thought the same when I saw this report... and the reason is likely that
the tracker has almost no REST API at all right now and that it thus looked
harder to implement there.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#827949: libpam-ssh does not launch an ssh-agent

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Again,

On 24/06/16 15:21, Giuseppe Bilotta wrote:
> OK, I think I found a solution!

Glad to hear.

> 
> When I checked the permissions of my .ssh folder and all the files
> within, I noticed there were a lot of leftover agent-* files in it. I
> killed my manually-started ssh-agent session, removed all the leftover
> files, logged out, and now the agent starts correctly when I log in.
> 
> So the problem is that one of the leftover files prevented the agent
> from starting.

This is not a problem, this mechanism is meant to allow several sessions
to use the same agent.
What is not normal is that the flag file was not removed: I suspect an accident
and/or any confusions as it happens at migration time.

> 
> May I suggest adding a few more debug outputs centered around starting
> up the agent? I don't know how it's done in pam_ssh, but if it does
> some checks before then actually printing on debug "checking for
> running agents" and maybe "found agent from X file, not starting"?

I am agree that the DEBUG message policy must be revisited.

> 
> This would at least hint at the reason why the agent is not being started.
> 
> (Bonus points: making sure that the agent is actually running and not
> just some lefover file?)

The leftover file is a flag file (see above).
How do you suggest to decide whether or not an agent was indeed launched by 
pam_ssh but not any other process ?
> 
> (Anyway, the issue is solved for me; maybe demote it to wishlist for
> the improved checks?)

I guess that we can close it.

Note that you may want to launch the pam_tmpdir module before pam_ssh as 
pam_ssh honours TMPDIR.

> 
> Thanks a lot for your time,
> 

Cheers,
Jerome


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

iQQcBAEBCgAGBQJXbUb6AAoJED+SGaZ/NsaLmikf/jllFGWubF0q/pt/RhGoQImO
WEd+dgaOwgJPIGJZMGheBNh0Qs5QwivNdX+y6vzmEsvoG6d18rzi44Z8oC5DPm38
TT++4wwHekbrJ/fhYgf6MRFZ13bWRapz7mqyc0kG6vYQtRHcbkGnRoQuhPRBbQiB
4DtyPrV5g2kM4uyG8H9OGv9TGdAcTcyzmnvapJJeYA8s59c57wV8n1Xlpb6lYXlM
reRsl13DuVEfcThi0jGPiYgma1D5/q+fP2B6I0qAZfLf6c/0lP3eYgFbb5/jSVaG
l5WLeOcxEMdj8XsKoGzzHL5s5hb86j35zQ015wl7YU6g+Ao763chI652ZI4XIf2k
6UkXkaQDX3vuJq0haBOpAsmfrUwBmPtvYmSK20GhuRJc8iJ47qFow1l7fVL3h6yw
Uhy1g7keJuIMOYHPkbhSGsqdipo9jnMYapEj9OYQbFgywEyQQkyjLVUSCzk96CoF
1oVdV5TlzLnh2oas3Jv0+u9mA05cQ3aoExTbYVh3otB8XzHVXQBODblCMvWNcFm4
+lPtdjZhNlCYvtiCTsbN3F8XoSQHLIYbSnmz2U044lTiJS8gz4SiTyHncLqwGDrl
IBdnGE15ctkNqZfUDAzfO+wagYDwQfw7OMYEEYYstPjeElY4GhydLZAoP25kWZdP
+MjjRcb4tSKLmLeTXXLg4GRI7smOrXfJGi4qPzaza03oJkdciBmQeISdJGftk9Xh
c20fXXrtnLbMXe3OqvET4uEEYIShU+bD0ZEOwb8L4R1TzqbXTaDQ3PxvFufeX7TD
g7U4aKKZxV+essWLuVC8SzFGXwOZGdINcWXd6uZHAvIi1+MtJsXrr0dphAXd5uFt
Kyf0hg19YMTtRqk2eB2bgcUXvHrCh8OnnuogCLn5UzB6KZTkoRzaE5Q+zbSJ0CV8
Ij1je8dpGNnMT6QkrSX5llbsaeKuMaSwrryZzUr5UJk4ST8nFQPxLXDx91iSSszH
IxC54EBHEo2ZLWBY9pp/+eINoAHn8wtg4ZM0s8kxRc8tMUei3uiZrQzrvKZXPWRL
8prLcTIxetzgDPZKndBmLlvjkPLMSUTbnOq+pmlg/TiGwPZW4ONg3hDk/BsC3HFV
0VqKNGQkbWP8pnCU3bivGkx68d4TdSbLS1o+DzFf7Dn71G8Pg66OUsXpGoUUnXww
ba7P+QIvOM+OUjPCbA0WceARkYsMpZjgdYgyPcDZ0JwdyI62cnsRARTrVSQ4wb0C
+p0i69Yp426w4BC8zjgNVTAzmxYXJh1PV81Hr1rHDfGK1JZ+cc8daX4ovI5/2pzi
4FjlazpktKiH5zJKAWANi0FIuncA/vD1HgkZ3OOBfgxQFg02i8bZNt3LTSq3YKg=
=wxBw
-END PGP SIGNATURE-

Bug#828060: libffado: please make the build reproducible

[Chris Lamb]

Source: libffado
Version: 2.2.1-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that 
libffado could not be built reproducibly. A file contains (rather useless) 
locale-specific test output.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2016-06-24 10:45:45.783185973 +0200
--- b/debian/rules  2016-06-24 16:01:33.444526839 +0200
@@ -84,4 +84,5 @@
dh_python2 -pffado-mixer-qt4
 
 binary-install/ffado-tools::
+   find debian/tmp -type f -name "static_info.txt" -delete
dh_python2 -pffado-tools

Bug#828030: RFS: gdbm/1.12-3

[Sven Joachim]

On 2016-06-24 00:19 -0400, Dmitry Bogatov wrote:

> I am looking for a sponsor for my package "gdbm"
>
> Changes since last upload:
>
>   * Separate translation files (/usr/share/locale/*) into new binary
> package 'libgdbm-l10n' to comply with Policy §8.2 (Closes: #828005)

Thanks for the fast reaction to that bug report. :-)  There seem to be a
few minor problems.

Since you are moving files between packages, libgdbm-l10n needs a
versioned Replaces on libgdbm4 to avoid file conflicts on upgrades.
Actually the same holds for libgdbm-dev, in 1.12-2 you moved files from
libgdbm4 to it.

The libgdbm-l10n package is "Architecture: all", but libgdbm4 has a
"Suggests: libgdbm-l10n (= ${binary:Version})".  If you want to specify
a version at all, it should be ${source:Version} instead.

The package description of libgdbm-l10n says "This package provides
translations for error messages, generated by library routines".  This
does not seem to be accurate, it also contains messages from gdbmtool.
That's why I suggested the package name gdbm-l10n in #828005.

Thanks for maintaining gdbm!

Cheers,
   Sven

Bug#827499: libtfbs-perl: Patches for misc packaging improvements

[Andreas Tille]

Hi Bas,

I moved the package to Git and importet your patches.


Tanya, since this seems to be the right moment and you have gathered experience
with testst in Perl packages:  Would you mind adding a test to

https://anonscm.debian.org/git/debian-med/libtfbs-perl.git

to have a soon upload after moving VCS with sensible changes?

Kind regards

   Andreas.

On Fri, Jun 24, 2016 at 02:09:19PM +0200, Sebastiaan Couwenberg wrote:
> On Fri, 17 Jun 2016 02:45:14 +0200 Bas Couwenberg wrote:
> > As part of the PDL update to 2.016 [0], all its reverse dependencies have
> > been rebuilt in preparation of the transition (from pdlapi-10 to pdlapi-12).
> > 
> > While libtfbs-perl doesn't require changes for the upcoming pdl
> > transition, I couldn't resist updating the package to incorporate some
> > best practices.
> > 
> > Please condider applying the attached patches. 
> > 
> > [0] 
> > https://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/2016-June/100093.html
> 
> A couple additional patches have been applied in todays NMU.
> 
> Kind Regards,
> 
> Bas



> ___
> 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#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

OK, I think I found a solution!

When I checked the permissions of my .ssh folder and all the files
within, I noticed there were a lot of leftover agent-* files in it. I
killed my manually-started ssh-agent session, removed all the leftover
files, logged out, and now the agent starts correctly when I log in.

So the problem is that one of the leftover files prevented the agent
from starting.

May I suggest adding a few more debug outputs centered around starting
up the agent? I don't know how it's done in pam_ssh, but if it does
some checks before then actually printing on debug "checking for
running agents" and maybe "found agent from X file, not starting"?

This would at least hint at the reason why the agent is not being started.

(Bonus points: making sure that the agent is actually running and not
just some lefover file?)

(Anyway, the issue is solved for me; maybe demote it to wishlist for
the improved checks?)

Thanks a lot for your time,

-- 
Giuseppe "Oblomov" Bilotta

Bug#801224: torsocks: [syscall] Unsupported syscall number 250

[intrigeri]

Version: 2.1.0-2

Hi,

Niels Thykier wrote (23 Jun 2016 21:30:52 GMT) :
> intrigeri:
>> syscall numbers are architecture dependent, so: what architecture did
>> you experience this on?

> amd64.

Thanks. So, that would be the keyctl syscall:
https://sources.debian.net/src/linux/3.16.7-ckt11-1%2Bdeb8u6~bpo70%2B1/arch/x86/syscalls/syscall_64.tbl/#L259

I don't see it allowed in torsocks source tree.

>> (I can't reproduce this here with torsocks 2.1.0-2 on sid.)

> True, the particular system call seem to have been fixed.

Cool :)

Now, I see no relevant difference before 2.1.0-1 and 2.1.0-2, so
I don't understand why this problem has disappeared in the meantime.

Do you mind if I close this bug report anyway, until someone
reproduces it again, maybe, some day?

> However, I can reproduce it with syscall "204" (sched_getaffinity).  A 
> particularly
> exciting case would be "torsocks mplayer"  because mplayer apparently
> does not give up making it an infinite fprintf loop of warnings.

That's https://bugs.debian.org/805741, which has been fixed in
upstream Git yesterday, so it'll be fixed in 2.2 final.

Cheers,
-- 
intrigeri

Bug#827984: assertion failure with multiple GPUs and Xinerama enabled

[Christopher Cramer]

On Fri, Jun 24, 2016 at 11:15:05AM +0900, Michel Dänzer wrote:
> Does the attached patch fix this?

Well, it doesn't die with an assertion failure anymore.

But the behavior is not what I would expect - the screens are all
mirrored. Maybe that is a separate issue, though.

Bug#828059: ITP: google-android-m2repository-installer -- This is a packaged script that automatically downloads Google's Android support m2 repository package and unpacks it into Debian-friendly path

[Mouaad Aallam]

Package: wnpp
Severity: wishlist
Owner: Mouaad Aallam 

* Package name: google-android-m2repository-installer
  Version : 33.0.0
  Upstream Author : Google, Inc.
* URL : 
https://developer.android.com/topic/libraries/support-library/index.html
* License : Apache 2.0
  Programming Lang: C, Java, Bash
  Description : Google Android Support m2 repository

This package will download the Google Android Support Libary repository and 
create a Debian package. This is structured as a maven m2 repository of all the 
versions of the library.
The Android Support Library offers a number of features that are not built into 
the framework. These libraries offer backward-compatible versions of new 
features, provide useful UI elements that are not included in the framework, 
and provide a range of utilities that apps can draw on.

WARNING: Installing this Debian package causes android_m2repository_r33.zip to 
be downloaded from dl-ssl.google.com. The End User License Agreement of this 
binary package is available at developer.android.com.

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

Hello Jerome,

>> I'm using ssh 1:7.2p2-5
>
> Now I am also using ssh 1:7.2p2-5 , but I cannot still reproduce the issue.

8-/

> I suspect a bad interference with some pam_module present on your box but 
> absent on mine
> and/or a privilege issue.

I will try disabling some of the less used modules and see if I can at
least find which one it's interacting with.

> Can you confirm that pam_ssh emits not `start ssh-agent' message in 
> /var/log/auth.log ?
> What are the permission of your $HOME/.ssh folder ? (ls -ld $HOME/.ssh folder 
> )

The only lines in auth.log that contain the word 'agent' are in the form:

/tmp/ssh-/agent.: No such file or
directory, the last of which was from yesterday morning, before the
reboot that first exhibited the issue (lack of agent startup). There
are plenty more before that (mostly due to the system not shutting
down cleanly with active NFS mounts and systemd), so they don't seem
to be related. Maybe there's some leftover that makes pam_ssh think
the agent is running already? Where could I look for?

The permission for ~/.ssh are rwx--, and rw--- are the
permissions for all private keys, the known_hosts, the authorized_keys
and config files.

Bug#507817: screen -r still sometimes fails with "WriteMessage: Bad file descriptor"

[Axel Beckert]

Hi Vincent,

Vincent Lefevre wrote:
> On 2016-06-24 15:23:52 +0200, Vincent Lefevre wrote:
> > Now this occurs very often:
> [...]
> 
> But I cannot reproduce the failure with strace.
> A race condition somewhere?

Thanks for that hint. That is a possible explaination why I have
issues reproducing it as well as why users see it with some versions
more often than with others despite the accused patch hasn't seen a
change for quite a while.

I'll check the patch for a potential race condition. But I do also
consider disabling it as there nowadays are enough evidentiary facts
that it's really the cause for this issue.

My preference is neverthelesss to keep the patch -- especially if the
patch can be fixed.

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

Bug#812050: #812050: ipsec-tools: FTBFS with GCC 6: dereferencing type-punned pointer

[Christian Hofstaedtler]

Control: tags -1 + unreproducible

Martin,

thank you for submitting this bug report, unfortunately I can't
reproduce the build failure locally (on amd64).

$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 6.1.1-7) 6.1.1 20160620
Copyright (C) 2016 Free Software Foundation, Inc.

ii  cpp  4:6-20160101-3   amd64  GNU C preprocessor (cpp)
ii  cpp-66.1.1-7  amd64  GNU C preprocessor
ii  gcc  4:6-20160101-3   amd64  GNU C compiler
ii  gcc-66.1.1-7  amd64  GNU C compiler

Given your report is from January, maybe this has been fixed in gcc
instead?

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

Bug#826063: RFS: libu2f-host/1.0.0-2 [NMU] [RC] -- U2F host communication library

[Nicolas Braud-Santoni]

Control: tags -1 - moreinfo

Hi Adam,

Sorry for having been kept away from this bug for the last few weeks;
life happened  :(

On Thu, Jun 02, 2016 at 06:48:41AM +0200, Adam Borowski wrote:
> control: tags -1 moreinfo
> 
> On Thu, Jun 02, 2016 at 01:31:02AM +0200, Nicolas Braud-Santoni wrote:
> > 
> > The dsc and build artifacts can be found in
> >   https://nicolas.braud-santoni.eu/tmp/deb/
> 
> The dsc there doesn't unpack -- filenames nor checksums don't match.

I'm not entirely sure what you mean there about a filename mismatch.

In anycase, it turns out I was building on a machine with faulty memory,
so the checksums mismatch might have been caused by this.

> Only one of four commits atop of debian/1.0.0-1 looks relevant:
> 40d4511 has the following changes:
> + updated build-dependencies (ie, the meat of the NMU)
> + standards version bump
> + a changelog entry (with an error: you need # after "Closes: " before the
>   number)
>
> e12e613 adds an UNRELEASED changelog entry and some gbp junk.

Indeed.  I failed to clean this up while removing so-far-unreleased
versions.

> 3d0722a tries to invent a way of generating "orig" tarballs.
> + this is bad as those don't match upstream.  Besides details like losing
>   timestamps or degrading xz to gz, you really should use what upstream
>   provides, unless this is impossible because of git-only releases or a
>   need to repack.
> + not using upstream tarballs ie especially bad as these are signed

Yes, I didn't realise that the upstream packages were not from
https://github.com/Yubico/libu2f-host/releases but from
https://developers.yubico.com/libu2f-host/Releases/

(The rule that was added did reproduce the packages in
 https://github.com/Yubico/libu2f-host/releases)

> 4e6802c tries to ignore changes in a generated file instead of properly
>   cleaning it (deletion would suffice)
> 
> On the other hand, something in clean-up after build does happen to break
> the package.  If you try to package the source from a fresh repository, it
> succeeds.  After a build, newly repacked source won't build anymore:

I'm not entirely sure what goes wrong there.
Is it even within the scope of this NMU, given that it is a
pre-existing problem unrelated to the RC bug I am fixing?


I uploaded a new set of files to the same directory:
https://nicolas.braud-santoni.eu/tmp/deb/

Note that the version number changed: it was following a previous
UNRELEASED version, which could have led to it being preferred to
a later release from the maintainer.


Best,

  nicoo


PS: Sorry for the double-sending:
the first mail was sent to you but not to the BTS...

Bug#819116: [Pkg-xfce-devel] Bug#819116: Bug#819116: light-locker: Mouse Pointer goes invisible after login with xfce4

[Yves-Alexis Perez]

On jeu., 2016-06-23 at 16:27 -0700, tony mancill wrote:
> I am running Intel integrated graphics, so that's a commonality.
> However, I don't have logout and then back in again.  The disappearing
> pointer happens consistently every time I unlock my machine. 

Yes it's unrelated to logging out, it's related to the vt switch, somehow.

>  To resolve
> it, I hit Ctrl-Alt-F1 to switch to a console and then Alt-F7 to get back
> into X, and the pointer is visible again.

> BTW, is the referenced bug correct?  I get an HTTP 500 when I try to
> access that bug via this URL [3].

Yes, unfortunately that bugs apparently messes with debbugs or so.

In any case, it definitely look like the same bug, which needs to be fixed in
xserver-xorg-video-intel. In the meantime , you can also remove the package
and use the modesetting driver (which is included in the xserver-xorg-core
package).

Regards,
-- 

Yves-Alexis

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

Bug#815599: [debian-mysql] Bug#815599: mariadb-server-10.0: Postinstall script does not clear the mysql-server/root_password_again field

[Otto Kekäläinen]

Owen,

Would you like to cook up at patch for this?

Bug#796589: apparmor: Has init script in runlevel S but no matching service file

[intrigeri]

Felipe Sateler wrote (24 Jun 2016 13:38:17 GMT) :
> On 24 Jun 2016 5:00 a.m., "intrigeri"  wrote:
>> Felipe Sateler wrote (06 Jun 2016 23:49:46 GMT) :
>> > Also, apparmor init script is not stopped on shutdown (and thus I did
>> > not add a Conflicts on shutdown.target), you might want to consider
>> > dropping the ExecStop in that case.
>>
>> What would it buy us to drop ExecStop? Even though the service is not
>> stopped on shutdown (that's on purpose), it may be useful to support
>> manual "systemctl stop apparmor.service".

> Mostly to prevent user errors. If the stop functionality is useful for
> debugging purposes, maybe it is safer to ship in a helper script.

OK, got it. Thanks!

I'll file a bug report right away so that we do this once there's such
a helper script (Seth agreed it would be great to have on
https://bugs.launchpad.net/apparmor/+bug/1503762/comments/2).

Cheers,
-- 
intrigeri