Bug#837218: lv: breaks systemctl display status

[Hideki Yamane]

Hi,

 Other solution from some people.
 Kenshi Muto suggests set "LV=-c" to /etc/profile.d/somefile and bash can
 read such setting.

 Yoshihito Yoshino suggests set systemd to detect lv and set in it as
 git does as below (pager.c file).

> void prepare_pager_args(struct child_process *pager_process, const char 
> *pager)
> {
> argv_array_push(_process->args, pager);
> pager_process->use_shell = 1;
> if (!getenv("LESS"))
> argv_array_push(_process->env_array, "LESS=FRX");
> if (!getenv("LV"))
> argv_array_push(_process->env_array, "LV=-c");
> }


-- 
Regards,

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

Bug#838544: ext4: ext4_iget:4476: inode #8: comm mount: checksum invalid

[Stefan Fritsch]

Package: src:linux
Version: 4.7.4-2
Severity: grave
Justification: renders package unusable

When booting with linux-image-4.7.0-1-amd64 4.7.4-2, one of my
filesystems fails to mount with:

ext4_iget:4476: inode #8: comm mount: checksum invalid

A fsck does not find any errors, though, and the mount problem persists.
After rebooting with 4.6, it works.

It seems this is a known problem:

http://www.spinics.net/lists/linux-fsdevel/msg101888.html


Not sure about the severity, but I thought I should prevent it from
migrating to testing until you have looked at it.

Bug#838543: quilt: 'quilt applied' shells out to less, but quilt does not Depend on or Recommend less

[Sebastian Kuzminsky]

Package: quilt
Version: 0.63-5
Severity: normal

Dear Maintainer,

I ran "pbuilder login" to debug a build problem with a package on sid,
so i was in a minimal sid chroot.  After some bumbling around I ran
"quilt applied", and was greeted by this error message:

root@bifrost:/tmp/yosys# quilt applied
/usr/share/quilt/scripts/patchfns: line 1040: less: command not found

The package build-depends on quilt, but quilt does not Depend on or
Recommend less, even though it calls out to it.  Probably quilt should
at least Recommend less.


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/24 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages quilt depends on:
ii  bsdmainutils  9.0.10
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  gettext   0.19.8.1-1
ii  patch 2.7.5-1
ii  perl  5.22.2-5

Versions of packages quilt recommends:
pn  less  

Versions of packages quilt suggests:
pn  default-mta | mail-transport-agent  
ii  graphviz2.38.0-15
pn  procmail

-- no debconf information

Bug#838538: dh_installdocs: look for README.foo

[Niels Thykier]

Control: tags -1 moreinfo

On Wed, 21 Sep 2016 17:40:03 -0700 Sean Whitton
 wrote:
> Package: debhelper
> Version: 10
> Severity: wishlist
> 
> Dear maintainers,
> 
> Lots of upstreams include a readme called 'README.md', 'README.rst',
> 'README.markdown' etc., rather than just 'README'.  It would be nice if
> dh_installdocs would install these automatically, as it currently
> installs plain 'README'.
> 
> Markdown and reStructuredText are designed to be readable without
> knowledge of the markup language, so these files are equally suitable
> for installation to /usr/share/doc/*/.
> 
> Thanks.
> 
> [...]
> 

Hi,

Thanks for the report.

I am a bit confused that your report suggests that dh_installdocs
install "README" by default.  I cannot find any evidence in the
dh_installdocs(1) manpage nor in the code that it does this.  The best I
can find is that the "debian/package.docs" example includes the README file.

This proposal is based on the assumption that the READMEs are generally
of interest.  However, as I recall, the upstream READMEs were often not
always relevant (e.g. focused on build/install instructions), which is
why they were previously not installed by default.

Thanks,
~Niels

Bug#838542: android-platform-system-core: profile build does not actually work

[Wookey]

Source: android-platform-system-core
Version: 6.0.1+r55
Severity: normal

Dear Maintainer,

I was very pleased to see that this package had build-profile info for
untangling the bootstrap of this and android-platform-system-extras.

However when I tried using it I found that it didn't build.

android-libunwind-dev is needed (by libbacktrace), which is needed by libutils.

I don't know if it could be removed, but it seemed tricky, and as
android-libunwind-dev comes from a separate source with minimal
build-deps there seems to be no need to skip this build-dep. So I put it back.

Similarly libsafe-iop-dev is needed too and is not obvisoulypart of a
loop so I put that back.

Now it builds but tries to use pango for the manpages and so fails.

not using pango should use the 'nodoc' build profile rather than the
'stage1' profile as that is more specific. So I changed that and fixed
up the rules files not to run those rules. And use dh-exec to avoid
dh_installman trying to install non-existent manpages.

Now it works. 

You can test it with 
apt-get -P stage1,nodoc build-dep android-platform-system-core
cd android-platform-system-core-*
dpkg-buildpackage -Pstage1,nodoc

Hope this is useful.

There is still a bootstrapping issue with the self-dependency on 
android-platform-system-core-headers

not sure if there is any build magic to generate those, or build without them?

-- 
Wookey
diff -Nru android-platform-system-core-6.0.1+r55/debian/adb.manpages android-platform-system-core-6.0.1+r55/debian/adb.manpages
--- android-platform-system-core-6.0.1+r55/debian/adb.manpages	2016-07-21 19:07:25.0 +
+++ android-platform-system-core-6.0.1+r55/debian/adb.manpages	2016-09-22 04:50:10.0 +
@@ -1 +1 @@
-debian/adb.1
\ No newline at end of file
+#!/usr/bin/dh-exec\n debian/adb.1\n
\ No newline at end of file
diff -Nru android-platform-system-core-6.0.1+r55/debian/changelog android-platform-system-core-6.0.1+r55/debian/changelog
--- android-platform-system-core-6.0.1+r55/debian/changelog	2016-07-21 19:07:25.0 +
+++ android-platform-system-core-6.0.1+r55/debian/changelog	2016-09-22 04:37:09.0 +
@@ -1,3 +1,10 @@
+android-platform-system-core (1:6.0.1+r55-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix stage1 build so it works
+
+ -- Wookey   Thu, 22 Sep 2016 04:36:58 +
+
 android-platform-system-core (1:6.0.1+r55-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru android-platform-system-core-6.0.1+r55/debian/control android-platform-system-core-6.0.1+r55/debian/control
--- android-platform-system-core-6.0.1+r55/debian/control	2016-07-21 19:07:25.0 +
+++ android-platform-system-core-6.0.1+r55/debian/control	2016-09-22 04:39:22.0 +
@@ -7,14 +7,14 @@
Chirayu Desai 
 Build-Depends: android-libext4-utils-dev (>= 6.0.1+r16-2) [amd64 i386] ,
android-libf2fs-utils-dev (>= 6.0.1+r16-2) [amd64 i386]  ,
-   android-libunwind-dev (>= 6.0.1+r55~) [amd64 i386] ,
+   android-libunwind-dev (>= 6.0.1+r55~) [amd64 i386],
android-platform-build-headers (>= 1:6.0.1+r16-4),
debhelper (>= 9.20141010),
dh-exec,
dpkg-dev (>= 1.17.14),
-   libsafe-iop-dev [amd64 i386] ,
+   libsafe-iop-dev [amd64 i386],
libssl-dev [amd64 i386] ,
-   pandoc [amd64 i386] ,
+   pandoc [amd64 i386] ,
zlib1g-dev [amd64 i386] 
 Standards-Version: 3.9.8
 Homepage: https://android.googlesource.com/platform/system/core
diff -Nru android-platform-system-core-6.0.1+r55/debian/fastboot.manpages android-platform-system-core-6.0.1+r55/debian/fastboot.manpages
--- android-platform-system-core-6.0.1+r55/debian/fastboot.manpages	2016-07-21 19:07:25.0 +
+++ android-platform-system-core-6.0.1+r55/debian/fastboot.manpages	2016-09-22 04:50:30.0 +
@@ -1 +1 @@
-debian/fastboot.1
\ No newline at end of file
+#!/usr/bin/dh-exec\n debian/fastboot.1\n
\ No newline at end of file
diff -Nru android-platform-system-core-6.0.1+r55/debian/rules android-platform-system-core-6.0.1+r55/debian/rules
--- android-platform-system-core-6.0.1+r55/debian/rules	2016-07-21 19:07:25.0 +
+++ android-platform-system-core-6.0.1+r55/debian/rules	2016-09-22 04:40:10.0 +
@@ -58,8 +58,11 @@
 	dh $@
 
 override_dh_auto_build: $(COMPONENTS)
+#skip pango usage in stage1
+ifeq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
 	pandoc -s -o debian/adb.1 debian/adb.1.md
 	pandoc -s -o debian/fastboot.1 debian/fastboot.1.md
+endif
 
 override_dh_auto_clean:
 	dh_auto_clean

Bug#838541: ITP: cupp -- Common User Passwords Profiler

[Marcio de Souza Oliveira]

Package: wnpp
Severity: wishlist
Owner: Marcio de Souza Oliveira 

* Package name: cupp
  Version : 0.0+20160624.git07f9b8-1
  Upstream Author :  Mebus, Muris Kurgas, Abhro, Andrea Giacomo, Bosko Petrovic
* URL : https://github.com/Mebus/cupp
* License : GPL-3+
  Programming Lang: Python
  Description : Common User Passwords Profiler

CUPP is a wordlist generator tool that can generator wordlists from
information such as a birthday, nickname, address, name of a pet or
relative, or a common word such as God, love, money or password.

CUPP main features:

 * Interactive questions for user password profiling;

 * Download huge wordlist from repository;

Bug#837964: 95a05b3 broke mdadm --add on my superblock 1.0 array

[Guoqing Jiang]

On 09/21/2016 02:45 AM, Guoqing Jiang wrote:



On 09/20/2016 02:31 PM, Anthony DeRobertis wrote:
Sorry for the amount of emails I'm sending, but I noticed something 
that's probably important. I'm also appending some gdb log from 
tracing through the function (trying to answer why it's doing cluster 
mode stuff at all).


While tracing through, I noticed that *before* the write-bitmap loop, 
mdadm -E considers the superblock valid. That agrees with what I saw 
from strace, I suppose. To my first glance, it figures out how much 
to write by calling this function:


static unsigned int calc_bitmap_size(bitmap_super_t *bms, unsigned 
int boundary)

{
unsigned long long bits, bytes;

bits = __le64_to_cpu(bms->sync_size) / 
(__le32_to_cpu(bms->chunksize)>>9);

bytes = (bits+7) >> 3;
bytes += sizeof(bitmap_super_t);
bytes = ROUND_UP(bytes, boundary);

return bytes;
}

That code looked familiar, and I figured out where—it's also in 
95a05b37e8eb2bc0803b1a0298fce6adc60eff16, the commit that I found 
originally broke it. But that commit is making a change to it: it 
changed the ROUND_UP line from 512 to 4096 (and from the gdb trace, 
boundary==4096).


I tested changing that line to "bytes = ROUND_UP(bytes, 512);", and 
it works. Adds the new disk to the array and produces no warnings or 
errors.


I think it is is a coincidence that above change works,  4a3d29e 
commit made

the change but it didn't change the logic at all.


Hmm, seems bitmap is aligned to 512 in previous mdadm, but with commit 
95a05b3
we made it aligned to 4k, so it causes the latest mdadm can't work with 
previous

created array.

Does the below change work? Thanks.

diff --git a/super1.c b/super1.c
index 9f62d23..6a0b075 100644
--- a/super1.c
+++ b/super1.c
@@ -2433,7 +2433,10 @@ static int write_bitmap1(struct supertype *st, 
int fd, enum bitmap_update update

memset(buf, 0xff, 4096);
memcpy(buf, (char *)bms, sizeof(bitmap_super_t));

-   towrite = calc_bitmap_size(bms, 4096);
+   if (__le32_to_cpu(bms->nodes) == 0)
+   towrite = calc_bitmap_size(bms, 512);
+   else
+   towrite = calc_bitmap_size(bms, 4096);
while (towrite > 0) {

Regards,
Guoqing

Bug#829520: RFS: mbpfan/1.9.1-1 ITP

[Sean Whitton]

Dear Herminio,

On Sun, Sep 18, 2016 at 01:13:48AM -0700, Herminio Hernandez Jr wrote:
> On 08/31, Herminio Hernandez, Jr. wrote:
> I am trying to convert my package using git. I am running into the lintian 
> error
> 
> gbp:error: Can't determine upstream version from changelog

Are you running gbp from the root of your source package?

> I am trying to convert my package using git. I am running into the lintian 
> error
> 
> W: mbpfan source: source-nmu-has-incorrect-version-number 1.9.1-1
> 
> Based on what I read here: 
> https://lintian.debian.org/tags/source-nmu-has-incorrect-version-number.html 
> I tried to change the version to -0.1 in the changelog. Now I am getting this 
> error
> 
> gbp:error: upstream/0 is not a valid treeish

This probably means that the Maintainer: field does not match your
DEBEMAIL and DEBFULLNAME environment variables.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

[Sean Whitton]

Hello Boyuan,

A few new things:

1. You dropped --parallel from d/rules without explaining why in the commit
message.  Does it break the build?  Certainly not essential, but it's
nice to enable it since our buildds are so overworked.

2. Some grammatical errors in package descriptions:

s/documentations/documentation/

s/on Evernote site/on the Evernote site/

Since 'complete' is an extreme adjective, it is odd to qualify it as
'rather complete'.  I would s/rather //.

3. I observed this:

hephaestus ~ % objdump -p /usr/bin/nixnote2 | grep NEEDED
  NEEDED   libhunspell-1.4.so.0
  NEEDED   libcurl.so.4
  NEEDED   libpoppler-qt5.so.1
  NEEDED   libqt5qevercloud.so.3
  NEEDED   libQt5PrintSupport.so.5
  NEEDED   libQt5WebKitWidgets.so.5
  [...]

Maybe the SONAME of qevercloud should be libQt5qevercloud, not
libqt5evercloud, to match this convention?  Since we can't change this
in the future, it would be good to get it right now.  Maybe this is
documented somewhere...

On Sun, Sep 18, 2016 at 09:02:42PM +0800, Boyuan Yang wrote:
> > 2. We need to test building something against your new shared library,
> > and we'll need to confirm that the right dependencies get generated for
> > it by dpkg-shlibdeps.  If you haven't done so already, could you update
> > your nixnote packaging to use your new qevercloud shlib, please?
> 
> The new version (2.0~beta9+dfsg-1) was pushed to GitHub, mentors
> and debomatic-amd64.
> Source package changed (ds -> dfsg) due to unclear license status (as
> discussed previously in nixnote2 RFS).

Your `dch -r` is behind HEAD again, and your debian/3.0.2+ds-1 isn't on
the HEAD of master.

> > 3. In a recent commit you renamed debian/{*.symbols =>
> > *.symbols.amd64}.  So now you are not providing any symbols files
> > for other architectures.  But for a shared library, you need to
> > provide a symbols or shlibs file for all the reasons described in
> > ch. 8 of the Debian Policy Manual.
> >
> > I assume that you did this rename because the symbols files is
> > architecture-dependent.  That probably means it's very fragile: changes
> > which don't break the ABI might change the symbols file.  This is a
> > known issue with C++ shared libs.[1]
> 
> It was indeed because of architecture-dependent symbols of C++.
> 
> >
> > You need to make the symbols file less fragile (some suggestions
> > involving sed(1) here[2]) so that it will work for all archs, or switch
> > to a shlibs file instead.  README.md suggests that upstream is aware of
> > the issue of ABI compatibility, so shlibs files might be enough.
> 
> Anyway I switched to shlibs using dh_makeshlibs. It is reasonable for
> this package to depend on upstream to keep ABI comaptibility, but I
> will also try to test symbol files on each release (even it is not included
> in the tarball, it can be stored in the git history).

Okay, sounds reasonable.

> The new qevercloud-doc added.
> 
> I dropped the tex / pdf / postscript files in the -doc package because
> they are not that
> useful when html files are provided as well.

Although HTML is considered the primary format for documentation in
Debian packages, I would suggest including the PDFs and PS files anyway.
Someone might want to print the documentation, or they might just prefer
reading PDFs.  Since it's in a separate -doc package, we don't have to
worry about cluttering up anyone's system.

If you agree, and install the PDFs and PSs, it would also be a good idea
to move the html docs into /usr/share/doc/qevercloud-doc/html.

Whether or not you build the PDFs, it would be good to handle this
error, which could be worrying to someone:

sh: 1: epstopdf: not found
error: Problems running epstopdf. Check your TeX installation!

If you don't want to install the PDFs, maybe you can instruct doxygen
not to try to run epstopdf, so that the error is not emitted.

> > 7. In your rules file you make a lot of explicit calls to dh_auto_*.
> > When you do something like this
> >
> > override_dh_auto_clean:
> > dh_auto_clean
> > rm -rf $(_QEVERCLOUD_QT5_BUILDDIR)
> >
> > it's fine, because it's clear to a reader that you are appending to an
> > automatic command.  However, when you do this:
> >
> > custom_regenerate_source_code:
> > (cd $(_QEVERCLOUD_GENERATOR_DIR); cmake .;)
> > dh_auto_build --buildsystem=makefile -- -C 
> > $(_QEVERCLOUD_GENERATOR_DIR)
> > mkdir -p QEverCloud/src/generated
> > etc.
> >
> > the dh_auto_build line is quite hard to understand -- someone would need
> > to look up the makefile buildsystem.  It would be better to replace that
> > with an explicit call to $(MAKE).  In dh_auto_build(1) it says "If it
> > doesn't work, you're encouraged to skip using dh_auto_build at all, and
> > just run the build process manually."
> 
> That is reasonable indeed. Switched to call $(MAKE).

Where you have

Bug#832704: RFS: nixnote2

[Sean Whitton]

Hello Boyuan,

I just reviewed the latest changes in your nixnote2 git repo, as part of
confirming that nixnote2 works with the new qevercloud shlib.

I have the following remaining suggestions (none are "must fix"):

1. I suggested adding something to README.source explaining why the
package does not depend on openoffice, despite having some references to
openoffice dictionaries.  You have written:

Upstream code contains some legacy instructions, including the
attempt of calling components of old OpenOffice(in spellchecker.cpp)
and behaviors that do not follow RFC 6068, etc. Those code are
examined and considered harmless.

This doesn't really give the issue.  I think you should explain
"harmless".  Say explicitly that the function/code path never gets
executed.

2. nixnote2 is failing piuparts :(

Could not install nixnote2-dbgsym nixnote2.

I successfully installed nixnote2-dbgsym on my machine, so while it
would be good to diagnose what's going on with piuparts, I don't think
it should block an upload.

3. I saw a build of beta10 on deb-o-matic.  Are you planning to update
the git repo/mentors package, too, or do you not consider beta10 stable
enough yet?  Your decision.

4. Don't forget `dch -r` to update the timestamp!

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#799571: Release of libcwd version 1.0.6

[Carlo Wood]

Hi,

I just released libcwd version 1.0.6
(http://downloads.sourceforge.net/project/libcwd/libcwd/1.0.6/libcwd-1.0.6.tar.gz)
which adds support for g++ 6.2.0 and lower (tested 5.4.0, 4.9.4, 4.8.5,
etc).

I think that should solve this bug.

-- 
Carlo Wood 

Bug#838516: FTBFS: conflicts between build dependencies

[Paul Wise]

On Wed, 2016-09-21 at 21:38 +0200, Joachim Reichel wrote:

> Build-Depends: [...] libglew-dev, libglewmx-dev, [...]

Why does it build-depend against both variants?
                 
> but libglewmx-dev 1.13.0-3 has
>   
> Conflicts: libglew-dev

The background here is that glew 2.0.0 removed MX support but things
like quesoglc and chromium-browser use the MX variant so I uploaded the
old version of glew as glewmx and dropped the non-MX variants of it.

There are a few possibilities here:

The k3d maintainer can try to figure out the reason for it using both
variants and switch to just one of them if possible.

I can temporarily re-add the non-MX variant to the glew 1.3 package and
have k3d switch from libglew-dev to that instead.

Upstream plans to release some MX support for 2.0.0:

https://github.com/nigels-com/glew/issues/38

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#829752: lower the severity

[gustavo panizzo (gfa)]

Control: severity -1 whislist

Hello

I don't want to start a severity war, but I count on having
netfilter-persistent when I install new systems using stretch.

From the bts documentation [1]


grave
makes the package in question unusable or mostly so, or causes data
loss, or introduces a security hole allowing access to the accounts
of users who use the package.

important
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.

normal
the default value, applicable to most bugs.

wishlist
for any feature request, and also for any bugs that are very
difficult to fix due to major design considerations.


This bug is far from grave. It does not causes data loss,  it does
not allow access to accounts of users that use it
(it won't protect other services but that's a bug on the services
itself or plain misconfiguration)


Therefore, I'm downgrading this bug severity to whislist.

I think it would be a good idea to have a debconf question asking if
the user wants the behavior requested in this bug report.
If the user says YES then create the file
/lib/systemd/system/networking.service.d/30_netfilter-persistent.conf
effectively disabling the network if the firewall fails to load.
The default answer for that debconf question should be NO.


[1] https://www.debian.org/Bugs/Developer#severities

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: https://keybase.io/gfa


signature.asc
Description: PGP signature

Bug#838540: open-iscsi logout-all.sh script fails to log out iscsi target

[Colby Ross]

Package: open-iscsi
Version: 2.0.873+git1.4c1f2d90-2

I am running debian stretch/sid with virt-manager, dkms, open-iscsi, 
virtualbox guest additions, and openssh installed.


I have an iscsi session opened with a local box on my lan, running 
FreeNAS. I have virt-manager and its dependencies installed, and have 
connected to the iSCSI share with virt-manager. I have no issues 
connecting, and no issues starting the machine back up. The issue comes 
during reboot or shutdown.


It looks like the script to log out all sessions (logout-all.sh) is 
being called at reboot/shutdown, but it is not finding any sessions to 
disconnect from, even though when I issue iscsiadm -m session, I get 
this output:


root@debscsi:~# iscsiadm -m session
tcp: [1] 172.16.5.30:3260,257 iqn.2015-12.org.cokenet.ctl:iscsi (non-flash)
root@debscsi:~#


The session is still connected, and I can access it. When I manually 
invoke logout-all.sh, I get this:


root@debscsi:/lib/open-iscsi# ./logout-all.sh
iscsiadm: No matching sessions found
root@debscsi:/lib/open-iscsi#


When I try to debug the script with bash -x, I get the following output:
root@debscsi:/lib/open-iscsi# bash -x logout-all.sh
+ ISCSIADM=/sbin/iscsiadm
+ PIDFILE=/run/iscsid.pid
+ ISCSI_ROOT_KEEP_ALL_SESSIONS_AT_SHUTDOWN=0
+ '[' -f /etc/default/open-iscsi ']'
+ . /etc/default/open-iscsi
++ LVMGROUPS=
++ HANDLE_NETDEV=1
++ EXCLUDE_MOUNTS_AT_SHUTDOWN=
++ ISCSI_ROOT_KEEP_ALL_SESSIONS_AT_SHUTDOWN=0
+ '[' -f /etc/iscsi/iscsi.initramfs ']'
+ '[' '!' -s /run/iscsid.pid ']'
++ sed -n 1p /run/iscsid.pid
+ kill -0 1703
+ EXCLUDED_SESSIONS=
+ '[' -f /run/open-iscsi/shutdown-keep-sessions ']'
+ '[' -z '' ']'
+ /sbin/iscsiadm -m node --logoutall=all
iscsiadm: No matching sessions found
+ exit 21
root@debscsi:/lib/open-iscsi#

So, it appears the command being issued is /bin/iscsiadm -m node 
--logoutall=all. When I try that command, I get the same error as when I 
try to run the script. The logout-all.sh script contains this function 
that invokes that command:

# trivial case
if [ -z "$EXCLUDED_SESSIONS" ] ; then
$ISCSIADM -m node --logoutall=all
exit $?
fi

I don't know scripting language very well at all, but it is apparently 
not finding the session to terminate correctly. When I manually log out 
of the session, it reboots and shuts down normally with no issues. Maybe 
this part of the script is being called in error, I'm not sure.  When I 
replace the command with $ISCSIADM -m node -u, it reboots and shuts down 
fine, but I consider this more of a hack than a true fix.


I previously tried to determine the cause of the hang on 
reboot/shutdown.  What happens is the system tries to ping the iscsi 
target, but fails because the network interface has already been brought 
down, and the system hangs indefinitely.  I get the error connection1:0: 
ping timeout of 5 secs expired, recv timeout 5, last rx 4294927718, last 
ping 4294928970, now 4294930224. However, I think the error is just an 
indication the target was not logged out properly and the system thinks 
its still connected.


I previously reported this under the systemd package, as I thought it 
was an issue with systemd and its ordering of shutdown scripts (possibly 
killing the interface before the logout of iscsi session). That was 
reported in bug# 838028 and I have updated this bug to reflect my 
additional troubleshooting and findings. Any help with the appropriate 
fix for this would be appreciated.


Colby Ross

Bug#838028: update to bug report

[Colby Ross]

I believe this bug is actually in the open-iscsi package, with the 
logout-all.sh script called at shutdown. I have submitted a bug report 
for that package. I do not believe systemd is the cause of this, so I 
feel confident this bug can be closed.  Thank you!

Bug#838414: gpick: colors.txt is non-free

[Ben Finney]

Elías Alejandro  writes:

> Could you review this issue?

What kind of review are you asking for? What new information has
appeared that prompts a review?

For what it's worth, I agree with the earlier assessment that the
restriction on usage violates DFSG §6.

Further, the term “use” is hopelessly vague and AFAIK null in copyright.
There are various common interpretations of what actions “use” could
mean in a copyright license text, that are incompatible with each other.
Better to change the conditions to be specific about what actions are
permitted.

-- 
 \   “[W]hoever is able to make you absurd is able to make you |
  `\unjust.” —Voltaire |
_o__)  |
Ben Finney

Bug#837332: plinth: Automatically add essential dependencies

[James Valleroy]

I have committed this patch.



signature.asc
Description: OpenPGP digital signature

Bug#838539: apt-get gives confusing error message when -P or --build-profile is used with unknown operation

[Wookey]

Package: apt
Version: 1.3
Severity: normal

If you do:
apt-get build-depends -P stage1 android-platform-system-core
you get:
E: Command line option 'P' [from -P] is not understood in combination with the 
other options.

If you do: 
apt-get --build-profiles=stage1 build-depends android-platform-system-core
you get:
E: Command line option --build-profiles=stage1 is not understood in combination 
with the other options

If you do:
apt-get -o Apt::Build-Profiles=stage1 build-depends android-platform-system-core
you get:
E: Invalid operation build-depends


In all three cases the issue is actually misspelling 'build-dep' as
'build-depends'. But only in the 3rd case does the user get an
indication of this. In the other two they are led to think that there
is something wrong with the -P/--build-profile option, when it is in
fact fine.

Can the parsing be fixed to give the same error in all three cases? Or
is there some good reason for this rather confusing behaviour?

If 'build-dep' is spelled correctly then all 3 flavours work as expected.

-- 
Wookey

Bug#838538: dh_installdocs: look for README.foo

[Sean Whitton]

Package: debhelper
Version: 10
Severity: wishlist

Dear maintainers,

Lots of upstreams include a readme called 'README.md', 'README.rst',
'README.markdown' etc., rather than just 'README'.  It would be nice if
dh_installdocs would install these automatically, as it currently
installs plain 'README'.

Markdown and reStructuredText are designed to be readable without
knowledge of the markup language, so these files are equally suitable
for installation to /usr/share/doc/*/.

Thanks.

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20160430.1
ii  binutils 2.26.1-1
ii  dh-autoreconf12
ii  dh-strip-nondeterminism  0.023-2
ii  dpkg 1.18.10
ii  dpkg-dev 1.18.10
ii  file 1:5.28-4
ii  libdpkg-perl 1.18.10
ii  man-db   2.7.5-1
ii  perl 5.22.2-5
ii  po-debconf   1.0.19

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

-- 
Sean Whitton

Bug#814676: Bug#824358: ITP: freerdp2 -- RDP client/server for Windows Terminal Services

[Michael Biebl]

On Tue, 17 May 2016 14:40:24 + Mike Gabriel
 wrote:
> I just heard back from Bernhard, that FreeRDP upstream discussed some  
> sort of a release schedule for 2.0.
> 
> There will be an ABI/API freeze around end of June / beginning of July  
> 2016 for FreeRDP 2.0 and then there will also be a 2.0~rc1 upstream  
> release.


Any news here?

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



signature.asc
Description: OpenPGP digital signature

Bug#838537: O: dia -- Diagram editor

[W. Martin Borgert]

Package: wnpp
Severity: normal

I intend to orphan the dia package.

There seems to be few upstream activity other than translation
updates. I will upload a new version soon and also put
everything in collab-maint git to ease future maintenance.

The package description is:
 Dia is an editor for diagrams, graphs, charts etc. There is support for UML
 static structure diagrams (class diagrams), Entity-Relationship diagrams,
 network diagrams and much more. Diagrams can be exported to postscript and
 many other formats.

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

I forgot one thing:
- libArcus carries the same version as the rest of the packages, but it 
actually uses a different versioning scheme. The shared library is named 
libArcus.so.1.0.0, with the SONAME = libArcus.so.2. This may or may not be 
correct. A bug report was filed upstream: https://github.com/Ultimaker/
libArcus/issues/43

Bug#838536: kicad still depends on obsolete glew packages

[peter green]

Package: kicad
Version: 4.0.4+dfsg1-1
Severity: serious

The latest kicad successfully built against the new glew but the 
resulting binary package still has a dependency on "libglew1.13 | 
libglew1.10" in addition to the dependency on "libglew2.0 (>= 1.12.0)"


The dependency on "libglew1.13 | libglew1.10" appears to be set manually.

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

Package: wnpp
Followup-For: Bug #706656
Owner: Gregor Riepl 

Hello, I've been using Cura (new Cura, not the legacy one) for a while, and
decided that it would be a good idea to package it up for Debian.

Upstream does not make this particularly easy, but thanks to the use of
standard build tools, it wasn't very hard either.

Therefore, I present debianized forks of the upstream Cura git repository and
its dependencies:
https://github.com/onitake/libArcus
https://github.com/onitake/Uranium
https://github.com/onitake/CuraEngine
https://github.com/onitake/Cura

Each of these repositories has a branch "debian" that contains a debian/
directory with all relevant build files. The dependencies are taken care of -
at least to the best of my knowledge. Please note that I am not an experienced
Debian maintainer, so there may be mistakes.

A few notes:
- All code is released under Affero GPLv3. I believe this is not one of the
preferred Debian package licenses, but it was deemed compatible with the DFSG
previously.
- libArcus is built into multiple packages: a shared library, development
files/headers, and a python3 library. The python library is named
python3-libarcus to reflect the relationship/dependency with libarcus itself.
- The CuraEngine package was named cura-engine2 to avoid conflicts with old
Cura, which used a very different and incompatible versioning scheme. A
"Breaks: cura-engine" was added, because both executables install under the
same name.
- The debian branch is currently tied to the 2.1.3 release, I will try to keep
it in sync with upstream releases.
- Building the packages pollutes the source tree. I have not found a way to
address this, any hints are appreciated.
- libArcus should be built first, as the other packages depend on it.

Please test it and give me feedback, I will apply corrections and improvements
as needed.

If the packages are accepted into Debian, I would like to request sponsorship
from a Debian maintainer, as I do not have commit access.

Bug#831153: openjdk-8-jre-dcevm: FTBFS with GCC 6: os.hpp:28:30: fatal error: jvmtifiles/jvmti.h: No such file or directory

[Emmanuel Bourg]

The error "jvmtifiles/jvmti.h: No such file or directory" isn't the
cause of the build failure. This error has been fixed upstream (see
https://bugs.openjdk.java.net/browse/JDK-8152067) and it can be avoided
by setting the USE_PRECOMPILED_HEADER=0 environment variable.

The fatal errors are the ones listed after and related to C++11 syntax
changes. Adding the --std=gnu++98 and -fpermissive options to CFLAGS
helps a bit, but the build still fails due to missing type definitions
for jint, jlong, size_t and uint64_t. This is odd, because jint and
jlong are defined in jni.h which should be in the include path.

Bug#838535: chromium: failed to start

[user]

Package: chromium
Version: 53.0.2785.113-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
starting chromium as root in weston
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
start chromium from a terminal in weston
   * What was the outcome of this action?
chromium failed to start


   * What outcome did you expect instead?

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


-- 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/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages chromium depends on:
ii  libasound2   1.1.2-1
ii  libatk1.0-0  2.21.90-2
ii  libavcodec57 7:3.1.3-1+b3
ii  libavformat577:3.1.3-1+b3
ii  libavutil55  7:3.1.3-1+b3
ii  libc62.23-5
ii  libcairo21.14.6-1+b1
ii  libcups2 2.1.4-4
ii  libdbus-1-3  1.10.10-1
ii  libexpat12.2.0-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.1.1-11
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.49.6-1
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk-3-0   3.21.5-3
ii  libharfbuzz0b1.2.7-1+b1
ii  libjpeg62-turbo  1:1.5.0-1
ii  libnettle6   3.2-1
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.25-1
ii  libpango-1.0-0   1.40.2-1
ii  libpangocairo-1.0-0  1.40.2-1
ii  libpci3  1:3.3.1-1.1
ii  libpulse09.0-3
ii  libspeechd2  0.8.5-1
ii  libstdc++6   6.1.1-11
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxi6   2:1.7.6-1
ii  libxml2  2.9.4+dfsg1-2
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxslt1.1   1.1.29-1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-l10n  

-- no debconf information

Bug#838534: chromium: ::MoveToNewUserNS().

[root]

Package: chromium
Version: 53.0.2785.113-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
running chromium from a terminal in weston as root
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action? 
[1:1:0921/182457:FATAL:sandbox_linux.cc(180)] Check failed: 
sandbox::Credentials
::MoveToNewUserNS().  * What outcome did you expect instead?


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


-- 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/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages chromium depends on:
ii  libasound2   1.1.2-1
ii  libatk1.0-0  2.21.90-2
ii  libavcodec57 7:3.1.3-1+b3
ii  libavformat577:3.1.3-1+b3
ii  libavutil55  7:3.1.3-1+b3
ii  libc62.23-5
ii  libcairo21.14.6-1+b1
ii  libcups2 2.1.4-4
ii  libdbus-1-3  1.10.10-1
ii  libexpat12.2.0-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.1.1-11
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.49.6-1
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk-3-0   3.21.5-3
ii  libharfbuzz0b1.2.7-1+b1
ii  libjpeg62-turbo  1:1.5.0-1
ii  libnettle6   3.2-1
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.25-1
ii  libpango-1.0-0   1.40.2-1
ii  libpangocairo-1.0-0  1.40.2-1
ii  libpci3  1:3.3.1-1.1
ii  libpulse09.0-3
ii  libspeechd2  0.8.5-1
ii  libstdc++6   6.1.1-11
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxi6   2:1.7.6-1
ii  libxml2  2.9.4+dfsg1-2
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxslt1.1   1.1.29-1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-l10n  

-- no debconf information

Bug#838310: keyboard-configuration: user configuration lost + error message from setupcon

[Anton Zinoviev]

On Mon, Sep 19, 2016 at 07:31:12PM +0200, Vincent Lefevre wrote:
> 
> Just after the upgrade of keyboard-configuration from 1.148 to 1.149,
> I could see that my previous configuration was lost. More precisely,
> config.dat changed in the following way:

When /etc/default/keyboard is ok, config.dat is ignored by console-setup 
(default values are set before asking questions).

> and /etc/default/keyboard changed in the following way:

If this file becomes corrupted during upgrade, then this is certainly a 
bad thing.
 
> -XKBMODEL="pc105"
> +XKBMODEL=""
>  XKBLAYOUT="gb"
>  XKBVARIANT=""
>  XKBOPTIONS=""

This doesn't look as a file created by console-setup.  Because of the 
missing XKBMODEL, it looks like a file created by systemd-localed.service.

Would you experiment with the command

# localectl set-keymap 

and

# localectl set-x11-keymap ...

and see if it corrupts /etc/default/keyboard.
 
> I don't know the possible consequences, though. The
> /usr/share/doc/keyboard-configuration/changelog.gz file just says:
> 
> console-setup (1.149) unstable; urgency=medium
> 
>   [ Updated translations ]
>   * Danish (da.po) by Joe Hansen

If I am right that the file was corrupted by systemd-localed, then 
/etc/default/keyboard must have been corrupted after the upgrade of 
console-setup.  If this file was corrupted before the upgrade, then 
console-setup would have repaired it.

> Note: I have
> 
> -rw-r--r-- 1 root root 145 2016-09-19 19:03:19 /etc/default/keyboard
> 
> Thus this file was modified when keyboard-configuration was upgraded
> (and before this upgrade of the Linux kernel and the nvidia packages).

Do you know what other packages were upgraded after console-setup and 
before the Linux kernel and nvidia?

> This error message is just a consequence of this bug.

Yes.  The error message was added in version 1.138 after I became aware 
that other packages modify the configuration file of console-setup.

Anton Zinoviev

Bug#838533: [vagrant] vagrant cannot connect via ssh to the virtual machine

[Enrique Garcia]

Package: vagrant
Version: 1.8.5+dfsg-2
Severity: important

--- Please enter the report below this line. ---
 
 Using vagrant with the virtualbox backend is unable to connect to the machine 
via ssh when using vagrant up.

 How to reproduce:
 # vagrant box add http://opscode-vm-bento.s3.amazonaws.com/vagrant/
virtualbox/opscode_fedora-23_chef-provisionerless.box --name fedora23_bento
 # vagrant init fedora23_bento
 # vagrant up

 The output looks like this (some lines omitted):

default: SSH address: 127.0.0.1:
default: SSH username: vagrant
default: SSH auth method: private key
default: 
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default: 
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.





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

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

--- Package information. ---
Depends  (Version) | Installed
==-+-=
bsdtar | 3.2.1-2
curl   | 7.50.1-1
openssh-client | 1:7.3p1-1
ruby-bundler   (>= 1.12.5) | 1.12.5-3
ruby-childprocess   (>= 0.3.7) | 0.5.9-1
ruby-erubis (>= 2.7.0) | 2.7.0-3
ruby-i18n   (>= 0.6.0) | 0.7.0-2
ruby-listen| 3.0.3-3
ruby-log4r  (>= 1.1.9) | 1.1.10-4
ruby-net-scp(>= 1.1.0) | 1.2.1-4
ruby-net-sftp  | 1:2.1.2-3
ruby-net-ssh  (>= 1:2.6.6) | 1:3.2.0-1
ruby-rest-client   | 1.8.0-3
ruby-nokogiri  | 1.6.8-2
ruby-rb-inotify| 0.9.7-1
ruby   | 1:2.3.0+4


Package's Recommends field is empty.

Suggests(Version) | Installed
=-+-===
virtualbox   (>= 4.0) | 5.1.6-dfsg-2

Bug#838414: gpick: colors.txt is non-free

[Elías Alejandro]

Dear Debian-legal team,

On Tue, Sep 20, 2016 at 6:46 PM, Francesco Poli (wintermute)
 wrote:
> Package: gpick
> Version: 0.2.5-2
> Severity: serious
> Justification: Policy 2.2.1
>
>
> Hello and thanks for maintaining this little tool in Debian!
>
> I noticed that the license for file share/gpick/colors.txt fails
> to meet the DFSG, as it includes at least one non-free restriction.
> Clause 5 states:
>
> |  5. These RGB colour formulations may not be used to the detriment of
> |  Resene Paints Ltd.
>
> This is a non-free restriction on use, which does not comply with
> DFSG#6 (No Discrimination Against Fields of Endeavor).
>
> This file is therefore unfit for the main Debian archive.
>
> Possible solutions I can think of:
>
>  A) get in touch with the colors.txt copyright holders (Resene Paints
> Ltd.) and persuade them to drop the troublesome clause or, even
> better, to re-license the file under well-known and widely used
> DFSG-free terms (such as, for instance, the 3-clause BSD license
> adopted by the rest of gpick)
>
>  B) find a DFSG-free replacement for share/gpick/colors.txt and use it
> in stead of the non-free one
>
>  C) drop share/gpick/colors.txt from the package, if possible
>
>  D) move the gpick package to the non-free archive (I hope this will
> *not* happen!)
>
> I hope solution A may be persued soon.
> Solution B (or C) may be chosen as a temporary quick fix, while trying
> to achieve solution A.
>

Could you review this issue?
This bug is reach the the old-stable version of gpick too.

Best regards,

Elías Alejandro

Bug#837799: libphonenumber.so.7: undefined symbol

[Michael Biebl]

On Wed, 14 Sep 2016 20:39:45 +0200 Jonas  wrote:
> Package: evolution
> Version: 3.20.5-1
> Severity: important
> 
> Dear Maintainer,
> 
> evolution don't work in testing, from a terminal :
> 
> $ evolution
> evolution: symbol lookup error: /usr/lib/x86_64-linux-gnu/libphonenumber.so.7:
> undefined symbol:
> _ZNK6google8protobuf11MessageLite39InternalSerializeWithCachedSizesToArrayEbPh

Can you send me the output of

ldd /usr/lib/x86_64-linux-gnu/libphonenumber.so.7

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



signature.asc
Description: OpenPGP digital signature

Bug#817626: src:poppassd: Co-maintain poppassd

[Peter Colberg]

On Wed, Sep 21, 2016 at 05:46:09PM -0400, Peter Colberg wrote:
> Please clone the updated package using
> 
>   gbp clone ssh://git.debian.org/git/collab-maint/poppassd.git

For verification, these are the current branch heads:

  git show-ref --heads

  6e26c876530625d4cdc3451bef921ce635887658 refs/heads/master
  db27d6addd476baf420d49f362b79b373462063e refs/heads/pristine-tar
  79da3cf634ebe761d494fcbbcf36a4da71379383 refs/heads/upstream

Please note that debian/copyright includes the following line:

  Files-Excluded: m4/* auto.sh

When you download a new tarball using uscan or gbp import-orig --uscan
in the future, this will automatically repack the orig tarball while
excluding the embedded files from the package autoconf-archive.

Peter

Bug#838532: transition: cgal

[Joachim Reichel]

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

Hi,

cgal 4.9-1 changed the SONAME and needs a transition. I have to apologize since
the new package is already in unstable because I completely forgot that such a
change consitutes a transition and needs approval from the release team first.

Rebuilding the reverse dependencies worked fine with the exception of:

crrcsim: FTBFS #811818, 8 months old, package not in testing
k3d: FTBFS #838516, unrelated, will follow up with maintainer

Ben file:

title = "cgal";
is_affected = .depends ~ "libcgal11v5" | .depends ~ "libcgal-qt5-11" | .depends 
~ "libcgal12" | .depends ~ "libcgal-qt5-12";
is_good = .depends ~ "libcgal12" | .depends ~ "libcgal-qt5-12";
is_bad = .depends ~ "libcgal11v5" | .depends ~ "libcgal-qt5-11";

Joachim

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (810, 'stable-updates'), (800, 'stable'), (700, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#817626: src:poppassd: Co-maintain poppassd

[Peter Colberg]

Hi Adam,

With the stretch freeze getting close, I have imported the poppassd
history into a collab-maint git repository and updated the packaging
to fix #817626 and conform to Debian policy. Please note that I have
*not* added myself to Uploaders. If you wish to continue to maintain
the package on your own, that is perfectly fine with me.

This is the summary of the proposed changes:

  * New upstream version 1.8.7
  * Switch source format to 3.0 (quilt)
  * Use dh with autoreconf in debian/rules (Closes: #817626)
  * Build with hardening flags
  * Add machine-readable debian/copyright
  * Update Homepage field
  * Add Vcs-Git and Vcs-Browser fields
  * Update debian/watch
  * Run wrap-and-sort
  * Update Standards-Version to 3.9.8

Please clone the updated package using

  gbp clone ssh://git.debian.org/git/collab-maint/poppassd.git

Please inspect the changes to the previous version using, e.g.,

  git log -p --stat --decorate --reverse debian/1.8.5-4..master

I have compared the upstream source line-by-line with the former
patched Debian source. The patch for #287820 has been included
upstream, otherwise the upstream changes are cosmetic.

All you would need to do now is update the changelog with

  gbp dch --commit --release

and prepare a source-only upload and tag a new release with

  gbp buildpackage -S --git-tag

In case this is the first time you are using git-buildpackage, it is
good practice to push the debian/* git tag only after the upload has
been accepted. This allows further changes if the upload is rejected.

Thanks,
Peter

Bug#834572: ci.debian.net: Please run dkms tests automatically

[Martin Pitt]

Hey Antonio,

Antonio Terceiro [2016-09-21 14:20 -0300]:
> the fact that Ubuntu runs tests on KVM and we run on LXC makes all the
> difference.
>
> however making the package have their tests executed is trivial; what's
> not trivial will be moving to KVM so that their tests have any chance of
> working.

Do you have enough EC2 quota to run tests in (ephemeral) nova
instances? In Ubuntu we do that, i. e. I have a permanent "controller"
instance that has the cloud credentials and an autopkgtest checkout,
and worker instances [1] which take AMQP test requests and call autopkgtest with
the ssh runner and the "nova" setup script [2] -- i. e. the actual
test is being run in an ephemeral instance, with full
"isolation-machine"/KVM capabilities like mucking around with kernel
stuff.

I can talk you through this if you are interested.

Martin

[1] 
https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/worker/worker
[2] 
https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/ssh-setup/nova

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#828554: spice-gtk: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2016-06-26 12:24:11 [+0200], Kurt Roeckx wrote:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/spice-gtk_0.30-1_amd64-20160529-1539

The patch attached has been sent upstream. It is untested and I kindly
asked them to test it. I don't tag it patched until someone confirms
that this works.

> Kurt

Sebastian
>From 0bd3b308f964f52db02b20b5db3a6f9a45c35072 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Wed, 21 Sep 2016 19:54:04 +
Subject: [PATCH] spice-gtk: get it compiled against openssl 1.1.0

and also 1.0.2h

Signed-off-by: Sebastian Andrzej Siewior 
---
 src/bio-gio.c   | 114 
 src/spice-channel.c |  24 ++-
 2 files changed, 103 insertions(+), 35 deletions(-)

diff --git a/src/bio-gio.c b/src/bio-gio.c
index b310c97..aa8ddac 100644
--- a/src/bio-gio.c
+++ b/src/bio-gio.c
@@ -23,21 +23,74 @@
 #include "spice-util.h"
 #include "bio-gio.h"
 
-typedef struct bio_gsocket_method {
-BIO_METHOD method;
-GIOStream *stream;
-} bio_gsocket_method;
+#if OPENSSL_VERSION_NUMBER < 0x1010
+static BIO_METHOD one_static_bio;
 
-#define BIO_GET_GSOCKET(bio)  (((bio_gsocket_method*)bio->method)->gsocket)
-#define BIO_GET_ISTREAM(bio)  (g_io_stream_get_input_stream(((bio_gsocket_method*)bio->method)->stream))
-#define BIO_GET_OSTREAM(bio)  (g_io_stream_get_output_stream(((bio_gsocket_method*)bio->method)->stream))
+static int BIO_meth_set_read(BIO_METHOD *biom,
+ int (*bread) (BIO *, char *, int))
+{
+biom->bread = bread;
+return 1;
+}
+
+static int BIO_meth_set_write(BIO_METHOD *biom,
+  int (*bwrite) (BIO *, const char *, int))
+{
+biom->bwrite = bwrite;
+return 1;
+}
+
+static int BIO_meth_set_puts(BIO_METHOD *biom,
+ int (*bputs) (BIO *, const char *))
+{
+biom->bputs = bputs;
+return 1;
+}
+
+static int BIO_meth_set_destroy(BIO_METHOD *biom, int (*destroy) (BIO *))
+{
+biom->destroy = destroy;
+return 1;
+}
+
+static int BIO_get_new_index()
+{
+return 128;
+}
+
+static void BIO_set_data(BIO *a, void *ptr)
+{
+a->ptr = ptr;
+}
+
+static void *BIO_get_data(BIO *a)
+{
+return a->ptr;
+}
+
+static BIO_METHOD *BIO_meth_new(int type, const char *name)
+{
+BIO_METHOD *biom = _static_bio;
+
+biom->type = type;
+biom->name = name;
+return biom;
+}
+
+void BIO_meth_free(BIO_METHOD *biom)
+{
+}
+
+#endif
 
 static int bio_gio_write(BIO *bio, const char *in, int inl)
 {
+GIOStream *stream;
 gssize ret;
 GError *error = NULL;
 
-ret = g_pollable_output_stream_write_nonblocking(G_POLLABLE_OUTPUT_STREAM(BIO_GET_OSTREAM(bio)),
+stream = BIO_get_data(bio);
+ret = g_pollable_output_stream_write_nonblocking(G_POLLABLE_OUTPUT_STREAM(stream),
  in, inl, NULL, );
 BIO_clear_retry_flags(bio);
 
@@ -53,10 +106,12 @@ static int bio_gio_write(BIO *bio, const char *in, int inl)
 
 static int bio_gio_read(BIO *bio, char *out, int outl)
 {
+GIOStream *stream;
 gssize ret;
 GError *error = NULL;
 
-ret = g_pollable_input_stream_read_nonblocking(G_POLLABLE_INPUT_STREAM(BIO_GET_ISTREAM(bio)),
+stream = BIO_get_data(bio);
+ret = g_pollable_input_stream_read_nonblocking(G_POLLABLE_INPUT_STREAM(stream),
out, outl, NULL, );
 BIO_clear_retry_flags(bio);
 
@@ -72,12 +127,14 @@ static int bio_gio_read(BIO *bio, char *out, int outl)
 
 static int bio_gio_destroy(BIO *bio)
 {
-if (bio == NULL || bio->method == NULL)
+if (bio == NULL )
 return 0;
 
 SPICE_DEBUG("bio gsocket destroy");
-g_clear_pointer(>method, g_free);
 
+/* XXX DO WE NEED to free GIOStream *stream ? */
+
+BIO_set_data(bio, NULL);
 return 1;
 }
 
@@ -91,23 +148,30 @@ static int bio_gio_puts(BIO *bio, const char *str)
 return ret;
 }
 
+static BIO_METHOD *bio_gio_method;
+
 G_GNUC_INTERNAL
 BIO* bio_new_giostream(GIOStream *stream)
 {
-// TODO: make an actual new BIO type, or just switch to GTls already...
-BIO *bio = BIO_new_socket(-1, BIO_NOCLOSE);
-
-bio_gsocket_method *bio_method = g_new(bio_gsocket_method, 1);
-bio_method->method = *bio->method;
-bio_method->stream = stream;
-
-bio->method->destroy(bio);
-bio->method = (BIO_METHOD*)bio_method;
-
-bio->method->bwrite = bio_gio_write;
-bio->method->bread = bio_gio_read;
-bio->method->bputs = bio_gio_puts;
-bio->method->destroy = bio_gio_destroy;
+BIO *bio;
+
+if (!bio_gio_method) {
+bio_gio_method = BIO_meth_new(BIO_get_new_index(), "gio stream");
+if (!bio_gio_method)
+return NULL;
+if (!BIO_meth_set_write(bio_gio_method, bio_gio_write)
+|| !BIO_meth_set_read(bio_gio_method, bio_gio_read)
+|| !BIO_meth_set_puts(bio_gio_method, 

Bug#838531: nose2: FTBFS in testing (failing tests)

[Santiago Vila]

Package: src:nose2
Version: 0.6.5-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed.

I'm attaching a single build log, but it fails every time I try, and it
also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nose2.html

which is also an indication that the error seems completely unrelated
to using "dpkg-buildpackage -A".

Thanks.

nose2_0.6.5-1_amd64-20160921T202215Z.gz
Description: application/gzip

Bug#838530: libgdata: accesses the internet during build

[Chris Lamb]

Source: libgdata
Version: 0.17.6-1
Severity: important
Justification: Policy 4.9
User: la...@debian.org
Usertags: network-access

Dear Maintainer,

Whilst libgdata builds successfully on unstable/amd64, according to
Debian Policy 4.9 packages may not attempt network access during
a build.

  00:00:00.00 IP 9e0da3628109.59095 > OpenWrt.lan.domain: 56215+ A? 
thisshouldnotexist.invalid. (44)
  00:00:00.61 IP 9e0da3628109.59095 > OpenWrt.lan.domain: 11504+ ? 
thisshouldnotexist.invalid. (44)
  00:00:00.105619 IP OpenWrt.lan.domain > 9e0da3628109.59095: 56215 NXDomain 
0/1/0 (119)
  00:00:01.513956 IP OpenWrt.lan.domain > 9e0da3628109.59095: 11504 NXDomain 
0/1/0 (119)
  00:00:01.514205 IP 9e0da3628109.49612 > OpenWrt.lan.domain: 32293+ A? 
thisshouldnotexist.invalid.lan. (48)
  00:00:01.514291 IP 9e0da3628109.49612 > OpenWrt.lan.domain: 40566+ ? 
thisshouldnotexist.invalid.lan. (48)
  00:00:01.516018 IP OpenWrt.lan.domain > 9e0da3628109.49612: 32293 NXDomain 
0/0/0 (48)
  00:00:01.516577 IP OpenWrt.lan.domain > 9e0da3628109.49612: 40566 NXDomain 
0/0/0 (48)
  00:00:01.516778 IP 9e0da3628109.40656 > OpenWrt.lan.domain: 34419+ A? 
thisshouldnotexist.invalid.chris-lamb.co.uk. (61)
  00:00:01.516866 IP 9e0da3628109.40656 > OpenWrt.lan.domain: 6282+ ? 
thisshouldnotexist.invalid.chris-lamb.co.uk. (61)

  [..]

The full build log (including tcpdump output) is attached.


Regards,

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


libgdata.0.17.6-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#695345: Please add a check for gobject-introspection packages

[Simon McVittie]

Patch version 2 attached, now passes `debian/rules runtests`.

On Wed, 21 Sep 2016 at 18:45:00 +, Niels Thykier wrote:
> In checks/gir.desc:
> +Reference: file:///usr/share/doc/gobject-introspection/policy.txt
>  ^
> 
> The field is "Ref" (consistent error)

Fixed in v2, and I removed file:// as Jakub requested.

> Can give undef warnings if someone was "evil" enough to make the paths a
> file or a symlink.  Trivial work-around is to change the path end with a
> slash (e.g. 'usr/share/gir-1.0/').

Fixed as suggested in v2.

I also hardened it against missing fields (debs::fields-general-missing),
and adjusted the expected result for tests::fields-wrong-section because
typelib-missing-gir-depends is now reported for that test's package
gir1.2-fields-wrong-section-0.1 (this check correctly guesses that it
was meant to be GIR but lacks ${gir:Depends}).

S
>From db1c11b68bea95eec09b3d9398ff7b6ec8774925 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 21 Sep 2016 21:49:57 +0100
Subject: [PATCH] Add checks for GObject-Introspection

---
 checks/gir.desc|  89 ++
 checks/gir.pm  | 135 +
 profiles/debian/main.profile   |   2 +-
 t/tests/gir/debian/Makefile|   7 ++
 t/tests/gir/debian/debian/control.in   |  81 +
 t/tests/gir/debian/debian/gir1.2-bad.install   |   2 +
 t/tests/gir/debian/debian/gir1.2-good-42.install   |   1 +
 .../gir/debian/debian/gir1.2-perfect-42.install|   1 +
 t/tests/gir/debian/debian/libgood-42-0.install |   1 +
 t/tests/gir/debian/debian/libgood-42-dev.install   |   2 +
 t/tests/gir/debian/debian/libperfect-42-0.install  |   1 +
 .../gir/debian/debian/libperfect-42-dev.install|   2 +
 .../debian/usr/lib/girepository-1.0/Bad-23.typelib |   1 +
 .../usr/lib/girepository-1.0/Good-42.typelib   |   1 +
 t/tests/gir/debian/usr/lib/libgood-42-0-dummy  |   0
 t/tests/gir/debian/usr/lib/libgood-42-dev-dummy|   0
 t/tests/gir/debian/usr/share/gir-1.0/Bad-23.gir|   1 +
 t/tests/gir/debian/usr/share/gir-1.0/Good-42.gir   |   1 +
 .../gir/debian/usr/share/gir-1.0/Perfect-42.gir|   1 +
 t/tests/gir/desc   |  12 ++
 t/tests/gir/post_test  |   1 +
 t/tests/gir/tags   |   9 ++
 22 files changed, 350 insertions(+), 1 deletion(-)
 create mode 100644 checks/gir.desc
 create mode 100644 checks/gir.pm
 create mode 100644 t/tests/gir/debian/Makefile
 create mode 100644 t/tests/gir/debian/debian/control.in
 create mode 100644 t/tests/gir/debian/debian/gir1.2-bad.install
 create mode 100644 t/tests/gir/debian/debian/gir1.2-good-42.install
 create mode 100644 t/tests/gir/debian/debian/gir1.2-perfect-42.install
 create mode 100644 t/tests/gir/debian/debian/libgood-42-0.install
 create mode 100644 t/tests/gir/debian/debian/libgood-42-dev.install
 create mode 100644 t/tests/gir/debian/debian/libperfect-42-0.install
 create mode 100644 t/tests/gir/debian/debian/libperfect-42-dev.install
 create mode 100644 t/tests/gir/debian/usr/lib/girepository-1.0/Bad-23.typelib
 create mode 100644 t/tests/gir/debian/usr/lib/girepository-1.0/Good-42.typelib
 create mode 100644 t/tests/gir/debian/usr/lib/libgood-42-0-dummy
 create mode 100644 t/tests/gir/debian/usr/lib/libgood-42-dev-dummy
 create mode 100644 t/tests/gir/debian/usr/share/gir-1.0/Bad-23.gir
 create mode 100644 t/tests/gir/debian/usr/share/gir-1.0/Good-42.gir
 create mode 100644 t/tests/gir/debian/usr/share/gir-1.0/Perfect-42.gir
 create mode 100644 t/tests/gir/desc
 create mode 100644 t/tests/gir/post_test
 create mode 100644 t/tests/gir/tags

diff --git a/checks/gir.desc b/checks/gir.desc
new file mode 100644
index 000..611b4ac
--- /dev/null
+++ b/checks/gir.desc
@@ -0,0 +1,89 @@
+Check-Script: gir
+Author: Simon McVittie 
+Type: binary, source
+Info: Checks for GObject-Introspection mini-policy compliance
+Needs-Info: unpacked, bin-pkg-control
+
+Tag: gir-section-not-libdevel
+Severity: normal
+Certainty: certain
+Info: GObject-Introspection XML files
+ (/usr/share/gir-1.0/Foo-23.gir) must be made available in
+ a development package in the libdevel section of the archive.
+ This is normally the same libfoo-dev package that contains
+ other development files.
+Ref: /usr/share/doc/gobject-introspection/policy.txt
+
+Tag: gir-in-arch-all-package
+Severity: normal
+Certainty: certain
+Info: GObject-Introspection XML files
+ (/usr/share/gir-1.0/Foo-23.gir) must be made available in
+ an architecture-dependent package of the same source.
+Ref: /usr/share/doc/gobject-introspection/policy.txt
+
+Tag: gir-missing-typelib-dependency
+Severity: normal
+Certainty: possible
+Info: Development packages that contain GObject-Introspection XML files
+ (/usr/share/gir-1.0/Foo-23.gir) must depend on the package
+ containing the 

Bug#838529: override: kdevelop-php-docs:oldlibs/extra

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please change section & priority of kdevelop-php-docs as oldlibs/extra,
as its content has been merged into kdevelop-php, and this package is
left as transitional.

Thanks,
-- 
Pino

Bug#770652: initscript: status command always exits with code 1

[Franck Joncourt]

Hello Sven,

Once I have fixed why psad does not start/stop correctly with the
initscript it should be fixed.

Regards,

--
Franck



signature.asc
Description: OpenPGP digital signature

Bug#838200: (gnome-software:15001): Gs-ERROR **: CSS parsing error: not a number

[Mike Miller]

Package: gnome-software
Version: 3.20.2-2
Followup-For: Bug #838200
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=771126

Bug affects me also after upgrading all gnome packages.

I see this has been reported upstream at

https://bugzilla.gnome.org/show_bug.cgi?id=771126

-- 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 gnome-software depends on:
ii  appstream0.10.1-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gnome-software-common3.20.2-2
ii  gsettings-desktop-schemas3.22.0-1
ii  libappstream-glib8   0.6.2-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-3
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libenchant1c2a   1.6.0-11+b1
ii  libfwupd10.7.3-1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.0-1
ii  libgnome-desktop-3-123.22.0-1
ii  libgtk-3-0   3.22.0-1
ii  libgtkspell3-3-0 3.0.9-1
ii  libjson-glib-1.0-0   1.2.2-1
ii  liblimba00.5.6-2
ii  libpackagekit-glib2-18   1.1.4-1
ii  libpango-1.0-0   1.40.2-1
ii  libpangocairo-1.0-0  1.40.2-1
ii  libpolkit-gobject-1-00.105-16
ii  libsoup2.4-1 2.56.0-1
ii  libsqlite3-0 3.14.1-1
ii  packagekit   1.1.4-1

gnome-software recommends no packages.

Versions of packages gnome-software suggests:
pn  fwupd  
pn  limba  

-- no debconf information

Bug#838528: postmulti-script: fatal: Missing main.cf prototype: /etc/postfix/main.cf.proto

[Jon Grimm]

Package: postfix
Version: 3.1.0-5+b1
Severity: important

Dear Maintainer,

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

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

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

Testing multi-instance configuration postfix on sid.

Fresh installation (of sid and of postfix).

root@sid1:~# postmulti -e init
root@sid1:~# postmulti -I postfix-example -G mta -e create
postfix/postmulti-script: fatal: Missing main.cf prototype: 
/etc/postfix/main.cf.proto


root@sid1:~# dpkg-query -l postfix

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=-===-===
ii postfix 3.1.0-5+b1 amd64 High-performance mail transport agent



main.cf.proto and master.cf.proto need to exist in the metadirectory.

>From the postmulti manpage (http://www.postfix.org/postmulti.1.html):

FILES
   $meta_directory/main.cf.proto, stock configuration file
   $meta_directory/master.cf.proto, stock configuration file
  

I can work around by hand creating, but should really be created as part of 
installation, IMO, so this all works out of the box.

Originally opened in Ubuntu. LP: #1595096



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

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

Versions of packages postfix depends on:
ii  adduser3.115
ii  cpio   2.11+dfsg-5
ii  debconf [debconf-2.0]  1.5.59
ii  dpkg   1.18.10
ii  init-system-helpers1.45
ii  libc6  2.24-3
ii  libdb5.3   5.3.28-12
ii  libicu57   57.1-4
ii  libsasl2-2 2.1.26.dfsg1-15
ii  libsqlite3-0   3.14.2-1
ii  libssl1.0.21.0.2h-1
ii  lsb-base   9.20160629
ii  netbase5.3
ii  ssl-cert   1.0.38

Versions of packages postfix recommends:
ii  python3  3.5.1-4

Versions of packages postfix suggests:
pn  dovecot-common 
ii  emacs24 [mail-reader]  24.5+1-7
ii  libsasl2-modules   2.1.26.dfsg1-15
pn  postfix-cdb
pn  postfix-doc
pn  postfix-ldap   
pn  postfix-mysql  
pn  postfix-pcre   
pn  postfix-pgsql  
pn  procmail   
pn  resolvconf 
pn  sasl2-bin  
pn  ufw

-- debconf information:
  postfix/tlsmgr_upgrade_warning:
  postfix/sqlite_warning:
* postfix/mailname: sid1
  postfix/retry_upgrade_warning:
  postfix/kernel_version_warning:
  postfix/mydomain_warning:
  postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
  postfix/bad_recipient_delimiter:
  postfix/protocols: all
  postfix/root_address:
  postfix/not_configured:
* postfix/main_mailer_type: Internet Site
  postfix/destinations: $myhostname, sid1, localhost.localdomain, , localhost
  postfix/procmail: false
  postfix/main_cf_conversion_warning: true
  postfix/compat_conversion_warning: true
  postfix/rfc1035_violation: false
  postfix/mailbox_limit: 0
  postfix/relay_restrictions_warning:
  postfix/recipient_delim: +
  postfix/relayhost:
  postfix/dynamicmaps_conversion_warning:
  postfix/chattr: false

Bug#817363: asterisk-prompt-es: Removal of debhelper compat 4

[Petter Reinholdtsen]

Control: tags -1 + patch

[Niels Thykier]
> The package asterisk-prompt-es uses debhelper with a compat level of 4,
> which is deprecated and scheduled for removal.

Here is a patch to fix this RC issue.

diff -u asterisk-prompt-es-1.4/debian/rules asterisk-prompt-es-1.4/debian/rules
--- asterisk-prompt-es-1.4/debian/rules
+++ asterisk-prompt-es-1.4/debian/rules
@@ -37,7 +37,7 @@
 install-indep:
dh_testdir
dh_testroot
-   dh_clean -k
+   dh_prep
dh_install
 install-arch:
 
diff -u asterisk-prompt-es-1.4/debian/compat 
asterisk-prompt-es-1.4/debian/compat
--- asterisk-prompt-es-1.4/debian/compat
+++ asterisk-prompt-es-1.4/debian/compat
@@ -1 +1 @@
-4
+9
diff -u asterisk-prompt-es-1.4/debian/control 
asterisk-prompt-es-1.4/debian/control
--- asterisk-prompt-es-1.4/debian/control
+++ asterisk-prompt-es-1.4/debian/control
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Debian VoIP Team 
 Uploaders: Victor Seva , Faidon Liambotis 
, Mark Purcell 
-Build-Depends: debhelper (>= 4.0.0)
+Build-Depends: debhelper (>= 9)
 Standards-Version: 3.7.3
 Homepage: http://www.voipnovatos.es/voces/
 Vcs-Svn: svn://svn.debian.org/pkg-voip/asterisk-prompt-es/trunk/
@@ -11,7 +11,7 @@
 
 Package: asterisk-prompt-es
 Architecture: all
-Depends: asterisk (>= 1:1.4 )
+Depends: ${misc:Depends}, asterisk (>= 1:1.4 )
 Enhances: asterisk
 Description: Spanish prompts for the Asterisk PBX
  These are Spanish voicemail prompts for use with the Asterisk PBX,
-- 
Happy hacking
Petter Reinholdtsen

Bug#838527: letsencrypt.sh: Ship nginx snippet

[Elrond]

Package: letsencrypt.sh
Version: 0.2.0-4
Severity: wishlist

Hi,

This bug has two purposes:

1. Provide a config snippet for nginx to integrate better
   with the challenges of letsencrypt.sh

   Wether the admin has to fully manually activate it or
   wether we can automate this, ... see point 2.

2. Serve as yet another example for #822792

   I am undecided, wether we want this (new) bug to be
   blocked by #822792 or not.


Okay, to the content:

The attached snippet does the basic configuration for the
challenges.

Until #822792 is fixed, we only have one option where to
put this file:
/etc/nginx/snippets/
The admin then can manually activate it, by adding a
"include snippets/letsencrypt.sh-challenge.conf;" in his
site's config file.

When #822792 is fixed, we will hopefully have a new
directory for this and some way on how to activate it.


Cheers

Elrond
location /.well-known/acme-challenge/ {
  alias /var/lib/letsencrypt.sh/acme-challenges/;
  disable_symlinks off;
  autoindex off;
}

Bug#838526: cinnamon: Adwaita icons not used right

[John Kirk]

Package: cinnamon
Version: 3.0.7-1
Severity: important

Dear Maintainer,

The Adwaita icon theme not used right. As an example look at the icon
/etc/adduser.conf in Cinnamon and Gnome. In the first case it is a blank sheet,
in the second it is a texted sheet.

I think it is a Cinnamon bug, not an Adwaita icon theme bug.

Best wishes,
John



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

Versions of packages cinnamon depends on:
ii  adwaita-icon-theme [gnome-icon-theme-symbolic]  3.21.91-1
ii  caribou 0.4.21-1
ii  cinnamon-common 3.0.7-1
ii  cinnamon-control-center 3.0.1-1
ii  cinnamon-desktop-data   3.0.2-2
ii  cinnamon-screensaver3.0.1-1
ii  cinnamon-session3.0.1-1
ii  cinnamon-settings-daemon3.0.1-2
ii  cjs 3.0.1-3
ii  cups-pk-helper  0.2.6-1
ii  dconf-gsettings-backend [gsettings-backend] 0.26.0-1
ii  gir1.2-accountsservice-1.0  0.6.40-3
ii  gir1.2-caribou-1.0  0.4.21-1
ii  gir1.2-clutter-1.0  1.26.0-2
ii  gir1.2-cmenu-3.03.0.2-1
ii  gir1.2-cogl-1.0 1.22.2-2
ii  gir1.2-gconf-2.03.2.6-3
ii  gir1.2-gdkpixbuf-2.02.34.0-1
ii  gir1.2-gkbd-3.0 3.6.0-1
ii  gir1.2-glib-2.0 1.49.1-2
ii  gir1.2-gnomedesktop-3.0 3.21.92-1
ii  gir1.2-gtk-3.0  3.21.5-3
ii  gir1.2-gtkclutter-1.0   1.8.0-2
ii  gir1.2-javascriptcoregtk-3.02.4.11-3
ii  gir1.2-keybinder-3.00.3.1-1
ii  gir1.2-meta-muffin-0.0  3.0.5-1
ii  gir1.2-networkmanager-1.0   1.2.4-2
ii  gir1.2-notify-0.7   0.7.6-2
ii  gir1.2-pango-1.01.40.2-1
ii  gir1.2-polkit-1.0   0.105-16
ii  gir1.2-soup-2.4 2.55.90-1
ii  gir1.2-upowerglib-1.0   0.99.4-3
ii  gir1.2-webkit-3.0   2.4.11-3
ii  gkbd-capplet3.6.0-1
ii  gnome-backgrounds   3.21.91-1
ii  gnome-icon-theme-symbolic   3.12.0-2
ii  gnome-themes-standard   3.20.2-3
ii  gsettings-desktop-schemas   3.21.4-2
ii  libatk-bridge2.0-0  2.20.1-4
ii  libatk1.0-0 2.21.90-2
ii  libc6   2.23-5
ii  libcairo2   1.14.6-1+b1
ii  libcinnamon-menu-3-03.0.2-1
ii  libcjs0 3.0.1-3
ii  libclutter-1.0-01.26.0-2
ii  libcogl-pango20 1.22.2-2
ii  libcogl-path20  1.22.2-2
ii  libcogl20   1.22.2-2
ii  libcroco3   0.6.11-1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libgirepository-1.0-1   1.49.1-2
ii  libgl1-mesa-glx [libgl1]12.0.3-1
ii  libglib2.0-02.49.6-1
ii  libglib2.0-bin  2.49.6-1
ii  libgstreamer1.0-0   1.8.3-1
ii  libgtk-3-0  3.21.5-3
ii  libjs-jquery1.12.4-1
ii  libmozjs-24-0   24.2.0-3.1
ii  libmuffin0  3.0.5-1
ii  libpango-1.0-0  1.40.2-1
ii  libpangocairo-1.0-0 1.40.2-1
ii  libstartup-notification00.12-4
ii  libx11-62:1.6.3-1
ii  libxfixes3  1:5.0.2-1
ii  libxml2 2.9.4+dfsg1-2
ii  mesa-utils  8.3.0-2+b1
ii  nemo3.0.6-2
ii  policykit-1-gnome   0.105-3
ii  python-dbus 1.2.4-1
ii  python-gconf2.28.1+dfsg-1.1
ii  python-gi-cairo 

Bug#838525: systemd-shim error prevents login to desktop on ppc

[Casey C]

Package:  systemd-shim

Version:  10-2


If systemd-shim and sysvinit-core are installed on PPC970MP (PPC64) system 
running Stretch Alpha 7 (bug also appears in Jessie 8.6 with systemd-shim 9-1), 
the system will not boot to desktop and the below error message is generated 
after logging in via TTY:


[ 646.474008] systemd-logind(2208): Failed to start user service, ignoring: 
Unknown Unit: user@1000.service

Bug#838520: found bug fixed and closed already => #807707

[Jordan]

It was closed for ddclient 3.8.2-3.
I am using 3.8.2-2 which is the latest available on Raspbian/Jessie.

Sorry for reporting a dup.
Jordan

Bug#838524: dahdi-firmware-nonfree: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Package: dahdi-firmware-nonfree
Version: 2.11.1-1
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The dahdi-firmware-nonfree package is one of the packages in the Debian archive
that should be proposed for installation when a given hardware dongle is
inserted or available.  Thanks to the appstream system, this can now be
announced in a way other tools can use and act on.  I've written the
isenkram system to ask the current user if hardware specific packages
should be installed when a new dongle is installed or already present on
a machine, and isenkram now uses appstream as one source for hardware to
package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
dahdi-firmware-nonfree package, with content similar to this:

  
  
   [...]
   
pci:ve159d0001sv*
lkmodule:dahdi

  

If there are other hardware ids also supported by the package, please
add those too. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#838242: transition: imagemagick

[Emilio Pozuelo Monfort]

user release.debian@packages.debian.org
usertags 838242 transition
thanks

On 18/09/16 23:08, Bastien ROUCARIÈS wrote:
> Package: release.debian.org
> Severity: normal

Please use reportbug next time, you missed the appropriate usertags.

> 
> Hi,
> 
> imagemagick waiting in NEWs (8:6.9.5.9+dfsg-1) will need a transition to 
> experimental to unstable;
> 
> Next stable version need to be based on this version from a security point of 
> view. It fix more than 50 securities bugs..;
> 
> Moreover this version use autopkg test improving the quality of testing.

Did you try to rebuild all the rdeps?

Cheers,
Emilio

Bug#838522: dahdi-linux: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Package: dahdi-linux
Version: 2.11.1-1
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The dahdi-linux package is one of the packages in the Debian archive
that should be proposed for installation when a given hardware dongle is
inserted or available.  Thanks to the appstream system, this can now be
announced in a way other tools can use and act on.  I've written the
isenkram system to ask the current user if hardware specific packages
should be installed when a new dongle is installed or already present on
a machine, and isenkram now uses appstream as one source for hardware to
package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
dahdi-linux package, with content similar to this:

  
  
   [...]
   
pci:ve159d0001sv*
lkmodule:dahdi

  

If there are other hardware ids also supported by the package, please
add those too. :)

-- 
Happy hacking
Petter Reinholdtsen

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

[Franck Joncourt]

Package: iptables-persistent
Version: 1.0.4+nmu1

Hi,

Installing the package netfilter-persistent I get the following warning:

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

Regards,

--
Franck



signature.asc
Description: OpenPGP digital signature

Bug#838521: gnome-shell: [Wayland] Segfault during VT switching

[Simon McVittie]

Package: gnome-shell
Version: 3.22.0-1
Severity: important

Steps to reproduce:

* Have the gdm login screen on tty1
* Have a Wayland session on tty2
* Have an X11 session on tty3
* Switch to the X11 session with Ctrl+Alt+F3
* Switch back to the Wayland session with Ctrl+Alt+F2

Expected result: VT-switching works without crashes

Actual result: the Wayland session segfaults:

Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7faf54e99db9 in wl_resource_post_event 
(resource=resource@entry=0xffe0, 
opcode=opcode@entry=2) at ../src/wayland-server.c:158
158 ../src/wayland-server.c: No such file or directory.
[Current thread is 1 (Thread 0x7faf621d6a80 (LWP 7944))]
(gdb) bt
#0  0x7faf54e99db9 in wl_resource_post_event 
(resource=resource@entry=0xffe0, opcode=opcode@entry=2) at 
../src/wayland-server.c:158
#1  0x7faf60a8a667 in meta_wayland_pointer_send_motion 
(surface_y=, surface_x=, time=55634554, 
resource_=0xffe0)
at /usr/include/wayland-server-protocol.h:2921
#2  0x7faf60a8a667 in meta_wayland_pointer_send_motion (pointer=0x291a9b0 
[MetaWaylandPointer], event=0x49d6030) at wayland/meta-wayland-pointer.c:339
#3  0x7faf60a8ae5a in meta_wayland_pointer_handle_event (event=0x49d6030, 
pointer=0x291a9b0 [MetaWaylandPointer]) at wayland/meta-wayland-pointer.c:557
#4  0x7faf60a8ae5a in meta_wayland_pointer_handle_event (event=0x49d6030, 
pointer=0x291a9b0 [MetaWaylandPointer]) at wayland/meta-wayland-pointer.c:564
#5  0x7faf60a8ae5a in meta_wayland_pointer_handle_event (pointer=0x291a9b0 
[MetaWaylandPointer], event=event@entry=0x49d6030) at 
wayland/meta-wayland-pointer.c:710
#6  0x7faf60a8e6aa in meta_wayland_seat_handle_event (seat=, 
event=event@entry=0x49d6030) at wayland/meta-wayland-seat.c:360
#7  0x7faf60a81dca in meta_wayland_compositor_handle_event 
(compositor=compositor@entry=0x7faf60d04320 <_meta_wayland_compositor>, 
event=event@entry=0x49d6030) at wayland/meta-wayland.c:208
#8  0x7faf60a4d20f in event_callback (event=0x49d6030, display=0x2af0930 
[MetaDisplay])
at core/events.c:386
#9  0x7faf60a4d20f in event_callback (event=0x49d6030, data=0x2af0930) at 
core/events.c:401
#10 0x7faf5fde42dd in _clutter_event_process_filters 
(event=event@entry=0x49d6030)
at clutter-event.c:1913
#11 0x7faf5fdf6bb3 in _clutter_process_event (device=0x2984070 
[ClutterInputDeviceEvdev], event=0x49d6030) at clutter-main.c:2011
#12 0x7faf5fdf6bb3 in _clutter_process_event (context=0x2871750, 
event=0x49d6030, stage=) at clutter-main.c:2372
#13 0x7faf5fdf6bb3 in _clutter_process_event (event=event@entry=0x49d6030)
at clutter-main.c:2548
#14 0x7faf5fe0d039 in _clutter_stage_process_queued_events (stage=0x2981040 
[MetaStage])
at clutter-stage.c:1026
#15 0x7faf5fdf8d39 in clutter_clock_dispatch (master_clock=0x299f300 
[ClutterMasterClockDefault], stages=) at 
clutter-master-clock-default.c:364
#16 0x7faf5fdf8d39 in clutter_clock_dispatch (source=, 
callback=, user_data=) at 
clutter-master-clock-default.c:561
#17 0x7faf5f2a57d7 in g_main_context_dispatch (context=0x25d2b20) at 
././glib/gmain.c:3201
#18 0x7faf5f2a57d7 in g_main_context_dispatch 
(context=context@entry=0x25d2b20)
at ././glib/gmain.c:3854
#19 0x7faf5f2a5a40 in g_main_context_iterate (context=0x25d2b20, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
././glib/gmain.c:3927
#20 0x7faf5f2a5d62 in g_main_loop_run (loop=0x29a8a60) at 
././glib/gmain.c:4123
#21 0x7faf60a540dc in meta_run () at core/main.c:572
#22 0x004021a7 in main ()

This appears to be an invalid @resource found in @pointer_resources here:

  wl_resource_for_each (resource, >focus_client->pointer_resources)
{
  wl_pointer_send_motion (resource, time, // <--- here
  wl_fixed_from_double (sx),
  wl_fixed_from_double (sy));
}

I don't really understand the Wayland client library, but this looks
as though it ought to be iterating through an empty list and so should
not call wl_resource_post_event() at all?

(gdb) frame 2
#2  meta_wayland_pointer_send_motion (pointer=0x291a9b0 [MetaWaylandPointer], 
event=0x49d6030)
at wayland/meta-wayland-pointer.c:339
339 in wayland/meta-wayland-pointer.c
(gdb) p *pointer
$2 = {parent = {parent_instance = {g_type_instance = {g_class = 0x29a79d0}, 
ref_count = 1, 
  qdata = 0x0}}, focus_client = 0x4b986c0, pointer_clients = 0x6120e40, 
  focus_surface = 0x47ea5e0 [MetaWaylandSurface], focus_surface_listener = 
{link = {
  prev = 0x25ea190, next = 0x5537a00}, 
notify = 0x7faf60a8b700 }, 
focus_serial = 1784, 
  click_serial = 0, cursor_surface = 0x0, cursor_surface_destroy_id = 64859, 
grab = 0x291aa18, 
  default_grab = {interface = 0x7faf60cf6ea0 , 
pointer = 0x291a9b0 [MetaWaylandPointer]}, grab_button = 2, grab_serial 

Bug#618900: Loan Offer

[Cashland Financial]

Loan Offer at 3%, Feel Free to REPLY back to us for more info

Bug#838520: ddclient: /etc/dhcp/dhclient-exit-hooks.d/ddclient uses explicit "exit" directives

[jordan]

Package: ddclient
Version: 3.8.2-2
Severity: important

Dear Maintainer

The hook scripts in the dhclient-exit-hooks.d directory are included (using the
dot command) in the /sbin/dhclient-script. Using explicit "exit" in a hook
script leads to immediate stop so that other hook scripts will be missed.

Using round brackets (..) around the executable part in the ddclient hook
script renders the "exit" directive into a stop/break statement while
preserving the exit code which is interpreted in /sbin/dhclient-script.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

Kernel: Linux 4.4.13-v7+ (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 ddclient depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  initscripts2.88dsf-59
ii  lsb-base   4.1+Debian13+rpi1+nmu1
ii  perl [perl5]   5.20.2-3+deb8u6

Versions of packages ddclient recommends:
ii  libio-socket-ssl-perl  2.002-2+deb8u1

ddclient suggests no packages.

-- Configuration Files:
/etc/dhcp/dhclient-exit-hooks.d/ddclient changed:

( # -- fixed

[ -x /usr/sbin/ddclient ] || exit 0
[ -f /etc/default/ddclient ] || exit 0
.. /etc/default/ddclient
[ $run_dhclient = "true" ] || exit 0
case $reason in
BOUND | RENEW | REBIND)
/usr/bin/logger -t dhclient $reason, updating IP address with ddclient
/usr/sbin/ddclient -daemon=0 -syslog > /dev/null 2>&1
;;
*)
;;
esac

) # -- fixed


-- debconf information excluded

Bug#771337: init-scripts: iptables-persistent initialized after psad

[Franck Joncourt]

Hello Sven,

I am packaging the latest psad release and I found your issue (long long
time ago).

I have added a LSB dependency on netfilter-persistent as Should-Start.

This will fix your problem.

Regards,

-
Franck



signature.asc
Description: OpenPGP digital signature

Bug#838519: jack-audio-connection-kit: new upstream release

[Jaromír Mikeš]

Package: jack-audio-connection-kit
Version: 1:0.124.1+20140122git5013bed0-3
Severity: normal

Dear Maintainer,

There is new upstream release 0.125.0 ... please update.
https://github.com/jackaudio/jack1

best regards

mira

Bug#838516: FTBFS: conflicts between build dependencies

[Manuel A. Fernandez Montecelo]

Hi Joachim,

2016-09-21 21:38 GMT+02:00 Joachim Reichel :
> Source: k3d
> Version: 0.8.0.5-4
> Severity: serious
>
> Hi,
>
> k3d 0.8.0.5-4 has
>
> Build-Depends: [...] libglew-dev, libglewmx-dev, [...]
>
> but libglewmx-dev 1.13.0-3 has
>
> Conflicts: libglew-dev
>
> (I want to rebuild k3d against the new cgal package which changed SONAMEs.)

Thanks for the report and the analysis.  I have to upload the new
upstream release which fixes the glew 2 problems, will do it in the
next few days.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#838497: [Pkg-clamav-devel] Bug#838497: libtfm1: Please add basic test coverage to build process

[Sebastian Andrzej Siewior]

On 2016-09-21 15:35:31 [+], Louis Bouchard wrote:
> A very basic test is available :
> make -f makefile.shared stest 
> 
>   ./stest 
>   
> Could you please consider adding the following test to the 
> debian/rules's override so some level of library testing
> is performed during the build process ?

this test is _very_ simple. It is so simple that I am not brave enough
to enable the asm optimisation just based on this.

Do you have time to work on a proper test (which would involve to get a
few changes to mtest) or do you just want stest to be enabled and be done
with it?

Sebastian

Bug#838518: vulkan: Wayland WSI support not built

[Philipp Zabel]

Source: vulkan
Severity: wishlist
Tags: patch

Hi,

the Wayland WSI support works now, it can be enabled with the
BUILD_WSI_WAYLAND_SUPPORT CMake option after adding libwayland-dev to
Build-Depends.

regards
Philipp
From 3dbbdadea7e6930fd130200ca23a62834987aab8 Mon Sep 17 00:00:00 2001
From: Philipp Zabel 
Date: Mon, 5 Sep 2016 07:19:28 +0200
Subject: [PATCH] enable wayland support

---
 debian/control |  1 +
 debian/patches/enable-wayland.diff | 13 +
 debian/patches/series  |  1 +
 3 files changed, 15 insertions(+)
 create mode 100644 debian/patches/enable-wayland.diff

diff --git a/debian/control b/debian/control
index afceef3..db10b2e 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Maintainer: Debian X Strike Force 
 Uploaders: Timo Aaltonen 
 Build-Depends: debhelper (>= 9),
  cmake,
+ libwayland-dev,
  libx11-dev,
  libxcb1-dev,
  pkg-config,
diff --git a/debian/patches/enable-wayland.diff b/debian/patches/enable-wayland.diff
new file mode 100644
index 000..2858c68
--- /dev/null
+++ b/debian/patches/enable-wayland.diff
@@ -0,0 +1,13 @@
+Index: vulkan/CMakeLists.txt
+===
+--- vulkan.orig/CMakeLists.txt
 vulkan/CMakeLists.txt
+@@ -22,7 +22,7 @@ elseif(CMAKE_SYSTEM_NAME STREQUAL "Linux")
+ # MIR is stubbed and untested 
+ option(BUILD_WSI_XCB_SUPPORT "Build XCB WSI support" ON)
+ option(BUILD_WSI_XLIB_SUPPORT "Build Xlib WSI support" ON)
+-option(BUILD_WSI_WAYLAND_SUPPORT "Build Wayland WSI support" OFF)
++option(BUILD_WSI_WAYLAND_SUPPORT "Build Wayland WSI support" ON)
+ option(BUILD_WSI_MIR_SUPPORT "Build Mir WSI support" OFF)
+ 
+ if (BUILD_WSI_XCB_SUPPORT)
diff --git a/debian/patches/series b/debian/patches/series
index d8cfb66..fd2300a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ loader-add-install-rule.diff
 demos-add-install-rule.diff
 layers-install-to-cmake-install-libdir.diff
 use-mxgot-for-mips64.patch
+enable-wayland.diff
-- 
2.9.3

Bug#838517: lxc-alpine template broken

[Alexander Schier]

Package: lxc
Version: 1:1.0.6-6+deb8u3
Severity: normal

Dear Maintainer,
the alpine template for lxc seem to be broken:

$ LANG=C lxc-create -n mycontainer -t alpine
Determining the latest release... v3.4
Using static apk from
http://wiki.alpinelinux.org/cgi-bin/dl.cgi/v3.4/main/x86_64
Downloading alpine-mirrors-3.4.2-r0.apk
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
Downloading apk-tools-static-2.6.7-r0.apk
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
Downloading alpine-keys-1.1-r0.apk
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
alpine-de...@lists.alpinelinux.org-4a6a0840.rsa.pub: OK
Verification Failure
Failed to download a valid static apk
lxc_container: container creation template for mycontainer failed
lxc_container: Error creating container mycontainer


-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (900, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages lxc depends on:
ii  init-system-helpers  1.22
ii  libapparmor1 2.9.0-3
ii  libc62.19-18+deb8u6
ii  libcap2  1:2.24-8
ii  libseccomp2  2.1.1-1
ii  libselinux1  2.3-2
ii  multiarch-support2.22-0experimental1
ii  python3  3.4.2-2

Versions of packages lxc recommends:
ii  debootstrap  1.0.67
ii  openssl  1.0.1t-1+deb8u3
ii  rsync3.1.1-3

Versions of packages lxc suggests:
pn  lua5.2  


-- debconf information:
  lxc/title:
  lxc/shutdown: /usr/bin/lxc-halt
  lxc/directory: /var/lib/lxc
  lxc/auto:

Bug#832637: More info

[Till Kamppeter]

Should be fixed in cups-filters 1.11.3 (in Debian GIT repo but package 
not released yet).


Make also sure you have cups 2.2.0-2 installed.

Bug#837988: Info received (testing older version 3.18.0-1:2b:b1)

[Petr Vanek]

Issue not appearing in gnome-screenshot 3.22.0-1, must have been
transitional thing.
Problem solved, please close :)
cheers
P.



On Fri, Sep 16, 2016 at 11:03 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

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

Bug#834928: This is fixed in ifupdown 0.8.11

[Dan Streetman]

This is a bug in ifupdown, not isc-dhcp-client.  It's fixed in 0.8.11
by the change to ifupdown's wait-for-ll6.sh:

--- ifupdown-0.8.10/wait-for-ll6.sh 2015-12-01 16:50:26.0 -0500
+++ ifupdown-0.8.11/wait-for-ll6.sh 2016-04-20 08:57:37.0 -0400
@@ -4,7 +4,7 @@
 delay=${IF_LL_INTERVAL:-0.1}

 for attempt in $(seq 1 $attempts); do
- lladdress=$(ip -6 -o a s dev "$IFACE" scope link)
+ lladdress=$(ip -6 -o a s dev "$IFACE" scope link -tentative)
  if [ -n "$lladdress" ]; then
  attempt=0
  break

Bug#838516: FTBFS: conflicts between build dependencies

[Joachim Reichel]

Source: k3d
Version: 0.8.0.5-4
Severity: serious

Hi,
   
k3d 0.8.0.5-4 has
 
Build-Depends: [...] libglew-dev, libglewmx-dev, [...]
  
but libglewmx-dev 1.13.0-3 has
  
Conflicts: libglew-dev
  
(I want to rebuild k3d against the new cgal package which changed SONAMEs.)
   
Regards,
  Joachim

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (810, 'stable-updates'), (800, 'stable'), (700, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#838486: inkscape: Segmentation fault in 0-48.5 src/display/nr-arena-image.cpp

[Alessandro Vesely]

Hi Mattia,

On Wed 21/Sep/2016 16:54:02 +0200 Mattia Rizzolo wrote:

On Wed, Sep 21, 2016 at 02:13:24PM +0200, Alessandro Vesely wrote:

$ gdb -q --args /usr/bin/inkscape test-pdf.svg
Reading symbols from /usr/bin/inkscape...done.
(gdb) run
Starting program: /usr/bin/inkscape test-pdf.svg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe66dd700 (LWP 14025)]
[New Thread 0x7fff5442f700 (LWP 14030)]
[New Thread 0x7fff53bce700 (LWP 14033)]

Program received signal SIGSEGV, Segmentation fault.
nr_arena_image_pick (item=0x29f5e00, p=..., delta=) at display
/nr-arena-image.cpp:318
318 return (pix_ptr[3] > 0) ? item : NULL;


nasty crash.

Now, that's the stable release, though.  And most of the development
efforts are concentrated in unstable.
Can you please check whether the crash happens with 0.91?  you can just
use what you find in jessie-backports for that.


I got a crash at a different point:

$ gdb -q --args /usr/bin/inkscape test-pdf.svg
Reading symbols from /usr/bin/inkscape...done.
(gdb) run
Starting program: /usr/bin/inkscape test-pdf.svg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe3026700 (LWP 21884)]
[New Thread 0x7fff4c92b700 (LWP 21885)]
[New Thread 0x7fff47f9f700 (LWP 21886)]

Program received signal SIGSEGV, Segmentation fault.
bits_image_fetch_separable_convolution_affine (repeat_mode=PIXMAN_REPEAT_NONE, 
format=PIXMAN_a8r8g8b8, convert_pixel=, mask=0x0, 
buffer=0x7fff4090,
width=, line=, offset=, 
image=0x61e82e80) at ../../pixman/pixman-fast-path.c:2813

2813../../pixman/pixman-fast-path.c: No such file or directory.
(gdb)


This looks similar to an older bug I reported in July:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832579

I'll try and reapply the latter patch tomorrow, and see how it goes.

Ale

Bug#816203: #816203: Out-of-date website regarding non-uploading contributors

[Holger Wansing]

Hi,

half a year ago I filed this bugreport, but I got no answer since.

What's the opinion of nm.debian.org on this?

As already said, I would volunteer to create some patches, but I don't want
to waste time on this, if no one wants such changings.


Regards
Holger

-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


pgpjki0jrs8Q2.pgp
Description: PGP signature

Bug#798430: apache2: please add systemd service file

[Stefan Fritsch]

Thanks for the patch. I will take a look next week-end.

Cheers,
Stefan

Bug#837254: @pytest.skip outside test gives error

[Sebastian Ramacher]

Control: reassign -1 src:python-llfuse 1.1.1+dfsg-2

Please CC $pack...@packages.debian.org when you reassign bugs. Otherwise I have
to find your mail with the explanation manually.

On 2016-09-13 10:07:41, Nikolaus Rath wrote:
> Control: reassign 837254 pytest
> 
> On Sep 10 2016, Lucas Nussbaum  wrote:
> >> collecting ... 
> >>  ERRORS 
> >> 
> >> __ ERROR collecting test_examples.py 
> >> ___
> >> Using @pytest.skip outside of a test (e.g. as a test function decorator) 
> >> is not allowed. Use @pytest.mark.skip or @pytest.mark.skipif instead.
> >>  Interrupted: stopping after 1 failures 
> >> 
> >> === 1 error in 0.23 seconds
> >> 
> 
> This (still) is a bug in pytest. I think it has already been fixed
> upstream (I remember getting a message about that).

Since it still fails to build with the pytest version which fixed the issues
with the decoractor, this seems to be a bug in python-llfuse instead and I
incorrectly merged the "FTBFS with pytest 3.0.0" bug with the other ones.

Hence I'm reassigning this issue back to python-llfuse.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#838515: chromium: Please enable widevine

[Felix Geyer]

Package: chromium
Version: 53.0.2785.113-1
Severity: wishlist

Hi,

Please enable the Widevine CDM adapter.
This allows users to fetch Google’s Widevine CDM plugin and use it with 
chromium.

A tested debdiff is attached.
When enable_widevine=1 is set, chromium builds libwidevinecdmadapter.so and 
libwidevinecdm.so.
libwidevinecdm.so is just a dummy plugin so there is no need to include it in 
the binary package.
Defining WIDEVINE_CDM_VERSION_STRING is necessary to make it build. The value 
doesn't seem to
matter as far as I can tell.

Thanks,
Felix
diff -Nru chromium-browser-53.0.2785.92/debian/chromium.install chromium-browser-53.0.2785.92/debian/chromium.install
--- chromium-browser-53.0.2785.92/debian/chromium.install	2016-02-12 03:52:44.0 +0100
+++ chromium-browser-53.0.2785.92/debian/chromium.install	2016-09-11 12:56:47.0 +0200
@@ -3,6 +3,7 @@
 
 out/Release/*.bin usr/lib/chromium
 out/Release/*.pak usr/lib/chromium
+out/Release/libwidevinecdmadapter.so usr/lib/chromium
 out/Release/icudtl.dat usr/lib/chromium
 
 out/Release/resources/en-US.pak usr/lib/chromium/locales
diff -Nru chromium-browser-53.0.2785.92/debian/patches/series chromium-browser-53.0.2785.92/debian/patches/series
--- chromium-browser-53.0.2785.92/debian/patches/series	2016-09-06 00:08:29.0 +0200
+++ chromium-browser-53.0.2785.92/debian/patches/series	2016-09-11 12:56:56.0 +0200
@@ -18,6 +18,7 @@
 gpu-timeout.patch
 master-preferences.patch
 chromedriver-revision.patch
+widevine.patch
 
 # system/jpeg.patch
 system/nspr.patch
diff -Nru chromium-browser-53.0.2785.92/debian/patches/widevine.patch chromium-browser-53.0.2785.92/debian/patches/widevine.patch
--- chromium-browser-53.0.2785.92/debian/patches/widevine.patch	1970-01-01 01:00:00.0 +0100
+++ chromium-browser-53.0.2785.92/debian/patches/widevine.patch	2016-09-11 12:56:56.0 +0200
@@ -0,0 +1,10 @@
+--- a/third_party/widevine/cdm/stub/widevine_cdm_version.h
 b/third_party/widevine/cdm/stub/widevine_cdm_version.h
+@@ -10,6 +10,7 @@
+ 
+ #include "third_party/widevine/cdm/widevine_cdm_common.h"
+ 
++#define WIDEVINE_CDM_VERSION_STRING "unknown"
+ #define WIDEVINE_CDM_AVAILABLE
+ 
+ #endif  // WIDEVINE_CDM_VERSION_H_
diff -Nru chromium-browser-53.0.2785.92/debian/rules chromium-browser-53.0.2785.92/debian/rules
--- chromium-browser-53.0.2785.92/debian/rules	2016-09-06 02:53:14.0 +0200
+++ chromium-browser-53.0.2785.92/debian/rules	2016-09-11 12:56:56.0 +0200
@@ -92,6 +95,8 @@
 #  can't use system nss since net/third_party/nss is heavily patched
 #  can't use system ots (open text *summarizer*) since that's not google's ots (open text *sanitizer*)
 
+defines+=enable_widevine=1
+
 # make gyp a little more informative
 options+=--check \
  --debug=includes \

Bug#838514: britney: patch to speed up loop performance

[Robert Bruce Park]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney, patch

Hi,

In Britney.write_excuses, there's a number of for loops doing slow operations 
redundantly. I've created a small patch that optimizes those loops with a good 
performance improvement. Here's some python profiling that proves the concept:

http://paste.ubuntu.com/23212621/

-- 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-36-generic (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From daf514d526d47646bb15f5b0a91cd9b8abe69820 Mon Sep 17 00:00:00 2001
From: Robert Bruce Park 
Date: Tue, 20 Sep 2016 14:03:02 -0700
Subject: [PATCH] Python loop performance enhancements.

---
 britney.py | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/britney.py b/britney.py
index b28c62f..79ad49c 100755
--- a/britney.py
+++ b/britney.py
@@ -1751,59 +1751,63 @@ class Britney(object):
 should_upgrade_srcarch = self.should_upgrade_srcarch
 should_upgrade_src = self.should_upgrade_src
 
+unstable = sources['unstable']
+testing = sources['testing']
+
 # this list will contain the packages which are valid candidates;
 # if a package is going to be removed, it will have a "-" prefix
 upgrade_me = []
+upgrade_me_append = upgrade_me.append  # Every . in a loop slows it down
 
 excuses = self.excuses = {}
 
 # for every source package in testing, check if it should be removed
-for pkg in sources['testing']:
+for pkg in testing:
 if should_remove_source(pkg):
-upgrade_me.append("-" + pkg)
+upgrade_me_append("-" + pkg)
 
 # for every source package in unstable check if it should be upgraded
-for pkg in sources['unstable']:
-if sources['unstable'][pkg][FAKESRC]: continue
+for pkg in unstable:
+if unstable[pkg][FAKESRC]: continue
 # if the source package is already present in testing,
 # check if it should be upgraded for every binary package
-if pkg in sources['testing'] and not sources['testing'][pkg][FAKESRC]:
+if pkg in testing and not testing[pkg][FAKESRC]:
 for arch in architectures:
 if should_upgrade_srcarch(pkg, arch, 'unstable'):
-upgrade_me.append("%s/%s" % (pkg, arch))
+upgrade_me_append("%s/%s" % (pkg, arch))
 
 # check if the source package should be upgraded
 if should_upgrade_src(pkg, 'unstable'):
-upgrade_me.append(pkg)
+upgrade_me_append(pkg)
 
 # for every source package in *-proposed-updates, check if it should be upgraded
 for suite in ['pu', 'tpu']:
 for pkg in sources[suite]:
 # if the source package is already present in testing,
 # check if it should be upgraded for every binary package
-if pkg in sources['testing']:
+if pkg in testing:
 for arch in architectures:
 if should_upgrade_srcarch(pkg, arch, suite):
-upgrade_me.append("%s/%s_%s" % (pkg, arch, suite))
+upgrade_me_append("%s/%s_%s" % (pkg, arch, suite))
 
 # check if the source package should be upgraded
 if should_upgrade_src(pkg, suite):
-upgrade_me.append("%s_%s" % (pkg, suite))
+upgrade_me_append("%s_%s" % (pkg, suite))
 
 # process the `remove' hints, if the given package is not yet in upgrade_me
 for hint in self.hints['remove']:
 src = hint.package
 if src in upgrade_me: continue
 if ("-"+src) in upgrade_me: continue
-if src not in sources['testing']: continue
+if src not in testing: continue
 
 # check if the version specified in the hint is the same as the considered package
-tsrcv = sources['testing'][src][VERSION]
+tsrcv = testing[src][VERSION]
 if tsrcv != hint.version:
 continue
 
 # add the removal of the package to upgrade_me and build a new excuse
-upgrade_me.append("-%s" % (src))
+upgrade_me_append("-%s" % (src))
 excuse = Excuse("-%s" % (src))
 excuse.set_vers(tsrcv, None)
 excuse.addhtml("Removal request by %s" % (hint.user))
-- 
2.7.4

Bug#695345: Please add a check for gobject-introspection packages

[Jakub Wilk]

* Niels Thykier , 2016-09-21, 18:45:

In checks/gir.desc:
+Reference: file:///usr/share/doc/gobject-introspection/policy.txt
^

The field is "Ref" (consistent error)


Also, our reference parser[*] knows about absolute pathnames, but not about 
file URLs, so let's make it:

s,file://,,


[*] See _format_reference in lib/Lintian/Tag/Info.pm.

--
Jakub Wilk

Bug#838513: libvcflib: FTBFS: (embedded) SSW requires amd64 or x32

[Aaron M. Ucko]

Source: libvcflib
Version: 1.0.0~rc1+dfsg-1
Severity: important
Justification: fails to build from source

Builds of libvcflib for most architectures failed as in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828209.  Since this
library has a broader scope than libssw, it should ideally fall back
to a portable Smith-Waterman implementation on these architectures.
Also, per Policy 4.13, libvcflib should build against separately
packaged libssw-dev (on those architectures on which it exists!)
rather than using its embedded convenience copy.

Could you please take a look?

Thanks!

Bug#798430: apache2: please add systemd service file

[Raphael Hertzog]

Hi,

On Wed, 21 Sep 2016, Mathieu Parent (Debian) wrote:
> can you improve it a bit to use Type=notify.

I saw they backported mod_systemd to Apache 2.4 but I don't know
if we should do the same or just wait until we have Apache 2.5.

I opted to not do it in this patchset but the Apache maintainers can
certainly include it if they think it's a good idea.

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#838512: manila: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: manila
Severity: wishlist
Tags: l10n patch

Hi!

Please find attached the Italian translation of manila debconf messages
proofread by the Italian localization team.

Please include it in your next upload.

Thanks,
Beatrice
# Italian description of manila debconf messages.
# Copyright (C) 2016, manila package copyright holder.
# This file is distributed under the same license as the manila package.
# Beatrice Torracca , 2012, 2013, 2014, 2016.
msgid ""
msgstr ""
"Project-Id-Version: manila\n"
"Report-Msgid-Bugs-To: man...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 13:41+\n"
"PO-Revision-Date: 2016-09-21 18:31+0200\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Virtaal 0.7.1\n"

#. Type: boolean
#. Description
#: ../manila-common.templates:2001
msgid "Set up a database for Manila?"
msgstr "Impostare un database per Manila?"

#. Type: boolean
#. Description
#: ../manila-common.templates:2001
#| msgid ""
#| "No database has been set up for manila-registry or glance-api to use. "
#| "Before continuing, you should make sure you have the following "
#| "information:"
msgid ""
"No database has been set up for Manila to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Non è stato impostato alcun database per l'uso da parte di Manila. Prima di "
"continuare, assicurarsi di avere le seguenti informazioni:"

#. Type: boolean
#. Description
#: ../manila-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * il tipo di database che si desidera usare;\n"
" * il nome host del server di database (che deve permettere le connessioni\n"
"   TCP da questa macchina);\n"
" * un nome utente e una password per accedere al database."

#. Type: boolean
#. Description
#: ../manila-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se non si ha uno o più di questi requisiti, non scegliere questa opzione ed "
"eseguire con il regolare supporto per SQLite."

#. Type: boolean
#. Description
#: ../manila-common.templates:2001
#| msgid ""
#| "You can change this setting later on by running \"dpkg-reconfigure -plow "
#| "manila-common\"."
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"manila\"."
msgstr ""
"È possibile cambiare questa impostazione successivamente eseguendo «dpkg-"
"reconfigure -plow manila»."

#. Type: string
#. Description
#: ../manila-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome host del server di autenticazione:"

#. Type: string
#. Description
#: ../manila-common.templates:3001
#| msgid ""
#| "Please specify the hostname of the authentication server for Manila. "
#| "Typically this is also the hostname of the OpenStack Identity Service "
#| "(Keystone)."
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Specificare il nome host del server di autenticazione. Tipicamente, è anche "
"il nome host dell'OpenStack Identity Service (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../manila-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome del locatario («tenant») per il server di autenticazione:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../manila-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr ""
"Inserire il nome del locatario («tenant») per il server di autenticazione."

#. Type: string
#. Description
#: ../manila-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome utente per il server di autenticazione:"

Bug#695345: Please add a check for gobject-introspection packages

[Niels Thykier]

Simon McVittie:
> After getting this wrong in Flatpak, I have attached a proposed patch
> for a new "gir" family of checks.
> 
> [...]
> 
> S
> 

Thanks for creating a patch for this. :)

At first glance, I only have a few minor tweaks/recommendations. :)


In checks/gir.desc:
+Reference: file:///usr/share/doc/gobject-introspection/policy.txt
 ^

The field is "Ref" (consistent error)

checks/gir.pm:
+if (my $xmldir = $info->index_resolved_path('usr/share/gir-1.0')) {
+push @girs, $xmldir->children;
+}
+
+if (my $dir = $info->index_resolved_path('usr/lib/girepository-1.0')) {
+push @typelibs, $dir->children;

Can give undef warnings if someone was "evil" enough to make the paths a
file or a symlink.  Trivial work-around is to change the path end with a
slash (e.g. 'usr/share/gir-1.0/'). This makes index_resolved_path return
undef if the path is not a directory.

Thanks,
~Niels

Bug#837786: mutter: Issues repainting the display on mouse movement

[Olivier Bitsch]

I confirm, same problem for me;

- Even with Gnome 3.22.0
- Nvidia Graphic 

Bug#692763:

[pa oh kg lay]

Bug#837786: mutter: Issues repainting the display on mouse movement

[Olivier Bitsch]

I confirm, same problem for me;

- Even with Gnome 3.22.0
- Nvidia Graphic GTX660 with proprietary drivers

Bug#838511: RM: kdevelop [armel] -- ROM; requires llvm 3.8

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove kdevelop from armel, as it build-depends on llvm 3.8
which is not available there.
Unfortunately, the non-llvm cpp support plugin does not build
currently, so there is no alternative.

Thanks,
-- 
Pino

Bug#838509: proftpd-mod-clamav: please drop the build dependency on hardening-wrapper

[Hilmar Preuße]

Package: proftpd-mod-clamav
Version: 0.10-1
Severity: important
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: hardening-wrapper

This package builds using the hardening-wrapper package, which
is now replaced by dpkg-dev's DEB_BUILD_MAINT_OPTIONS settings.

Please consider dropping the build dependency of hardening-includes
and use the DEB_BUILD_MAINT_OPTIONS settings.

The goal is to remove hardening-wrapper for the stretch release.
Discussion about the removal is tracked in https://bugs.debian.org/836162

H.
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.7.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#838510: ITP: elpa-epc -- RPC stack for the Emacs Lisp

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: elpa-epc
  Version : 0.1.1
  Upstream Author : Masashi Sakurai 
* URL : https://github.com/kiwanami/emacs-epc
* License : GPL-3+
  Programming Lang: Emacs Lisp, Perl
  Description : RPC stack for Emacs Lisp

This is an asynchronous RPC stack for Emacs. Using this  RPC stack, the
Emacs can communicate with the peer process. Because the protocol is
S-expression encoding and consists of asynchronous communications, the RPC

Bug#838508: proftpd-mod-case: please drop the build dependency on hardening-wrapper

[Hilmar Preuße]

Package: proftpd-mod-case
Version: 0.7-1
Severity: important
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: hardening-wrapper

Dear Maintainer,

This package builds using the hardening-wrapper package, which
is now replaced by dpkg-dev's DEB_BUILD_MAINT_OPTIONS settings.

Please consider dropping the build dependency of hardening-includes
and use the DEB_BUILD_MAINT_OPTIONS settings.

The goal is to remove hardening-wrapper for the stretch release.
Discussion about the removal is tracked in https://bugs.debian.org/836162

H.
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.7.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#838507: RM: kdevelop-php [armel] -- ROM; requires kdevelop (which needs llvm 3.8)

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove kdevelop-php from armel, as it build-depends on kdevelop,
which cannot be built as it requires llvm 3.8.

Thanks,
-- 
Pino

Bug#695345: Please add a check for gobject-introspection packages

[Michael Biebl]

Am 21.09.2016 um 20:00 schrieb Simon McVittie:
> After getting this wrong in Flatpak, I have attached a proposed patch
> for a new "gir" family of checks.


Nice co-incidence. I've just uploaded a new version of
gobject-introspection with a small update to policy.txt, mentioning that
multiarch paths are nowadays supported and preferred. And then I thought
to myself that having a lintian check for that would be great :-)

Michael




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



signature.asc
Description: OpenPGP digital signature

Bug#838506: RM: kdevelop-python [armel] -- ROM; requires kdevelop (which needs llvm 3.8)

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove kdevelop-python from armel, as it build-depends on
kdevelop, which cannot be built as it requires llvm 3.8.

Thanks,
-- 
Pino

Bug#793824: plasma-nm: plasma-widget-networkmanager has totally disappeared with plasma-nm 4:5.3.2-1

[Jan Klötzke]

For the record: I have moved away ~/.kde and the problem disappeared. I
guess some old state in there caused the problem. Obviously KDE5 does
not make much use of it anymore as I lost only some settings...

Bug#695345: Please add a check for gobject-introspection packages

[Simon McVittie]

After getting this wrong in Flatpak, I have attached a proposed patch
for a new "gir" family of checks.

On Fri, 07 Dec 2012 at 12:10:54 +0100, Michael Biebl wrote:
> 1/ Warn if the gir1.2-foo-X.Y package is not in section "introspection".

W: gir1.2-bad: typelib-section-not-introspection 
usr/lib/girepository-1.0/Bad-23.typelib misc

(This is done for any package that contains a public typelib)

> 2/ Warn if a package installs a .typelib file in the system path without
> using a separate gir1.2 package.

W: gir1.2-bad: typelib-package-name-does-not-match 
usr/lib/girepository-1.0/Bad-23.typelib gir1.2-bad-23

> 3/ Warn if the gir1.2-foo-X.Y package has no ${gir:Depends}

W: gir source: typelib-missing-gir-depends gir1.2-bad

> 4/ Warn if the -dev package has no
> Depends: gir1.2-foo-X.Y (= ${binary:Version}). This one is probably
> tricky for src packages which build multiple -dev packages.

W: gir1.2-bad: gir-missing-typelib-dependency usr/share/gir-1.0/Bad-23.gir 
gir1.2-bad-23

I made this check assume that the correct dependency is based on the
standard naming convention, rather than inspecting the other packages
from the same source and looking for the one that contains the typelib.
Packages that don't follow the standard naming convention (mostly those
that combine multiple typelibs into one package, like GLib) can override
the check, unless someone particularly wants to rewrite this logic.

The new checks also assert that GIR XML and typelibs are both in
architecture-dependent packages and GIR XML is in Section: libdevel,
and emit an "info"-level tag for typelibs that are in the pre-multiarch
directory.

S
>From 0353c27e0eafa9eabca8d8a0e7e356d21e6efa6a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 21 Sep 2016 18:35:21 +0100
Subject: [PATCH] Add checks for GObject-Introspection

---
 checks/gir.desc|  89 ++
 checks/gir.pm  | 135 +
 profiles/debian/main.profile   |   2 +-
 t/tests/gir/debian/Makefile|   7 ++
 t/tests/gir/debian/debian/control.in   |  81 +
 t/tests/gir/debian/debian/gir1.2-bad.install   |   2 +
 t/tests/gir/debian/debian/gir1.2-good-42.install   |   1 +
 .../gir/debian/debian/gir1.2-perfect-42.install|   1 +
 t/tests/gir/debian/debian/libgood-42-0.install |   1 +
 t/tests/gir/debian/debian/libgood-42-dev.install   |   2 +
 t/tests/gir/debian/debian/libperfect-42-0.install  |   1 +
 .../gir/debian/debian/libperfect-42-dev.install|   2 +
 .../debian/usr/lib/girepository-1.0/Bad-23.typelib |   1 +
 .../usr/lib/girepository-1.0/Good-42.typelib   |   1 +
 t/tests/gir/debian/usr/lib/libgood-42-0-dummy  |   0
 t/tests/gir/debian/usr/lib/libgood-42-dev-dummy|   0
 t/tests/gir/debian/usr/share/gir-1.0/Bad-23.gir|   1 +
 t/tests/gir/debian/usr/share/gir-1.0/Good-42.gir   |   1 +
 .../gir/debian/usr/share/gir-1.0/Perfect-42.gir|   1 +
 t/tests/gir/desc   |  12 ++
 t/tests/gir/post_test  |   1 +
 t/tests/gir/tags   |   9 ++
 22 files changed, 350 insertions(+), 1 deletion(-)
 create mode 100644 checks/gir.desc
 create mode 100644 checks/gir.pm
 create mode 100644 t/tests/gir/debian/Makefile
 create mode 100644 t/tests/gir/debian/debian/control.in
 create mode 100644 t/tests/gir/debian/debian/gir1.2-bad.install
 create mode 100644 t/tests/gir/debian/debian/gir1.2-good-42.install
 create mode 100644 t/tests/gir/debian/debian/gir1.2-perfect-42.install
 create mode 100644 t/tests/gir/debian/debian/libgood-42-0.install
 create mode 100644 t/tests/gir/debian/debian/libgood-42-dev.install
 create mode 100644 t/tests/gir/debian/debian/libperfect-42-0.install
 create mode 100644 t/tests/gir/debian/debian/libperfect-42-dev.install
 create mode 100644 t/tests/gir/debian/usr/lib/girepository-1.0/Bad-23.typelib
 create mode 100644 t/tests/gir/debian/usr/lib/girepository-1.0/Good-42.typelib
 create mode 100644 t/tests/gir/debian/usr/lib/libgood-42-0-dummy
 create mode 100644 t/tests/gir/debian/usr/lib/libgood-42-dev-dummy
 create mode 100644 t/tests/gir/debian/usr/share/gir-1.0/Bad-23.gir
 create mode 100644 t/tests/gir/debian/usr/share/gir-1.0/Good-42.gir
 create mode 100644 t/tests/gir/debian/usr/share/gir-1.0/Perfect-42.gir
 create mode 100644 t/tests/gir/desc
 create mode 100644 t/tests/gir/post_test
 create mode 100644 t/tests/gir/tags

diff --git a/checks/gir.desc b/checks/gir.desc
new file mode 100644
index 000..64e70e7
--- /dev/null
+++ b/checks/gir.desc
@@ -0,0 +1,89 @@
+Check-Script: gir
+Author: Simon McVittie 
+Type: binary, source
+Info: Checks for GObject-Introspection mini-policy compliance
+Needs-Info: unpacked, bin-pkg-control
+
+Tag: gir-section-not-libdevel
+Severity: normal
+Certainty: certain
+Info: GObject-Introspection XML files
+ 

Bug#838386: moreinfo

[Paul Tagliamonte]

I had a second to poke around a bit more, so I looked a bit more at
what other error messages I could have it give me. Here's some followup:

I opened nm-connection-editor again and tried to edit the VPN I have
already set up. I clicked on 'edit', and the UI showed me this:

http://i.imgur.com/Ty3sLCi.png

Seeing as how that looked like a dbus name, I checked d-feet to see if
such a service was riding the bus.

Seems like yes: http://i.imgur.com/ikklOhq.png

When I hit the dbus interface as root, I could introspect it. Seems like
it's on the bus and responding to requests. This is funny to me. So, I
looked for where this came from, and saw it was defined in
/etc/NetworkManager/VPN/nm-strongswan-service.name

I opened it and double checked the paths. They seem good, except one
file needed a `.so` appenended to it. This seems sane enough for a path
you'd expect to be a .so, so I don't think it's a likely lead. Here's
shell output:

| [paultag@cassiel:~][⌚ 01:39 PM] ♥  cat 
/etc/NetworkManager/VPN/nm-strongswan-service.name 
| [VPN Connection]
| name=strongswan
| service=org.freedesktop.NetworkManager.strongswan
| program=/usr/lib/ipsec/charon-nm
| 
| [GNOME]
| auth-dialog=/usr/lib/NetworkManager/nm-strongswan-auth-dialog
| properties=/usr/lib/NetworkManager/libnm-strongswan-properties
| [paultag@cassiel:~][⌚ 01:39 PM] ♥  ls -l /usr/lib/ipsec/charon-nm
| -rwxr-xr-x 1 root root 30896 Jul 16 09:32 /usr/lib/ipsec/charon-nm
| [paultag@cassiel:~][⌚ 01:39 PM] ♥  ls -l 
/usr/lib/NetworkManager/nm-strongswan-auth-dialog
| -rwxr-xr-x 1 root root 14816 Aug 28 04:47 
/usr/lib/NetworkManager/nm-strongswan-auth-dialog
| [paultag@cassiel:~][⌚ 01:40 PM] ♥  ls -l 
/usr/lib/NetworkManager/libnm-strongswan-properties
| ls: cannot access '/usr/lib/NetworkManager/libnm-strongswan-properties': No 
such file or directory
| [paultag@cassiel:~][⌚ 01:40 PM] ♥  ls -l 
/usr/lib/NetworkManager/libnm-strongswan-properties.so 
| -rw-r--r-- 1 root root 23128 Aug 28 04:47 
/usr/lib/NetworkManager/libnm-strongswan-properties.so

Nothing totally broken. Not sure why it isn't talking with this service.
Maybe the API of the dbus service changed? Could this be a strongswan-nm
bug?

Not sure where to look next,
   Paul


signature.asc
Description: PGP signature

Bug#817656: root-tail: Removal of debhelper compat 4

[Francesco Poli]

On Wed, 21 Sep 2016 01:40:41 +0200 Axel Beckert wrote:

> Hi Francesco,

Hello Axel,
thanks a lot for stepping in!

[...]
> root-tail has just been orphaned by the MIA team on behalf of Stephen
> Gran, see https://bugs.debian.org/838406.
> 
> I'm preparing a QA upload of root-tail fixing this bug and updating
> the packaging to the current state of the art.

This is really appreciated, thank you so much!  :-)

> 
> I also created a packaging git repository at
> https://anonscm.debian.org/cgit/collab-maint/root-tail.git/ (will be
> visibile in about an hour or so) for future root-tail maintenance.

This is also awesome!

Now I hope that someone will soon volunteer to adopt this package and
maintain it properly.
Thanks to anyone willing to do so!


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


pgp7F6Sa2o9mZ.pgp
Description: PGP signature

Bug#838352: mutt: after the switch to GPGME, I could no longer decrypt my sent PGP mail

[Antonio Radici]

On Tue, Sep 20, 2016 at 10:51:01AM +0200, Christian Pietsch wrote:
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> Version 1.7.0-5 enabled GPGME for PGP handling by default.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> After updating to version 1.7.0-5, when I sent an encrypted e-mail to
> somebody else, I was surprised that I was unable to decrypt this
> message afterwards.
> 
> Before the upgrade, I was able to decrypt all PGP/MIME messages I had
> sent.
> 
>* My analysis:
> 
> It turns out I did not have `set pgp_encrypt_self=yes` in my
> configuration. Instead, I relied on the following settings which seem
> to be ignored by GPGME:
> 
> set pgp_encrypt_only_command="/usr/lib/mutt/pgpewrap gpg --batch --quiet 
> --no-verbose --output - --encrypt --textmode --armor --always-trust 
> --encrypt-to 0x
> set pgp_encrypt_sign_command="/usr/lib/mutt/pgpewrap gpg --passphrase-fd 0 
> --batch --quiet --no-verbose --textmode --output - --encrypt --sign %?a?-u 
> %a? --armor --always-trust --encrypt-to 0x -- -r %r -- %f"
> 
> Would it be possible to honour these settings with GPGME, or to parse
> the `--encrypt-to` argument to make the transition to GPGME a smoother
> experience?
> 

Just to clarify this to myself, pgp_encrypt_self=true is going to solve this,
the bug itself is for a smoother transition if --encrypt-to is set in the pgp_
commands

Bug#838260: diffoscope: Reduce noise from offsets deltas in readelf(1) diffs

[Chris Lamb]

> I was thinking of something like the HTML  tag.  In my browser,
> foo renders «foo» with a dotted underline
> whose raison d'être is your concern (a)

Even so, you can't search the page with CTRL+F and, of course, it makes the
output too different between --text and --html :)

Anyway, small issue ...


Regards,

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

Bug#834572: ci.debian.net: Please run dkms tests automatically

[Antonio Terceiro]

On Wed, Sep 21, 2016 at 04:35:33PM +0200, Petter Reinholdtsen wrote:
> Is there some code we can lift from Ubuntu to enable the dkms tests
> automatically?

I don't think so.

the fact that Ubuntu runs tests on KVM and we run on LXC makes all the
difference. I just tried a random DMKS package (openafs), and it fails trying
to do thins you usually cannot do in containers.

Setting up openafs-client (1.6.18.3-2) ...
update-alternatives: using /usr/bin/pagsh.openafs to provide /usr/bin/pagsh 
(pagsh) in auto mode
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open 
moddep file '/lib/modules/4.7.0-1-amd64/modules.dep.bin'
modprobe: FATAL: Module openafs not found in directory 
/lib/modules/4.7.0-1-amd64
Failed to load openafs.ko.  Does it need to be built?
grep: /lib/modules/4.7.0-1-amd64/modules.dep: No such file or directory

> Where are the set of automatic tests defined?

https://anonscm.debian.org/cgit/collab-maint/debian-ci-config.git
cookbooks/debci/files/default/whitelist*

however making the package have their tests executed is trivial; what's
not trivial will be moving to KVM so that their tests have any chance of
working.


signature.asc
Description: PGP signature

Bug#838505: RM: kdevelop-php-docs -- ROM; merged into src:kdevelop-php

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove the separate kdevelop-php-docs source and its binaries:
its content was merged together with kdevelop-php, which now builds
everything, and provides transitional packages for the older binaries
of src:kdevelop-php-docs.

Thanks,
-- 
Pino

Bug#825488: ci.debian.net: Please run tests for contrib packages too

[Antonio Terceiro]

On Wed, Sep 21, 2016 at 04:33:07PM +0200, Petter Reinholdtsen wrote:
> [Antonio Terceiro 2016-07-07]
> > debci needs code changes to make the automatically generated testbeds
> > actually include contrib in sources.list. I have the beginnings of
> > that stashed locally, but it's not ready yet. If you want to work on
> > it I can send you the current patch.
> 
> Did you get any further?  As I mentioned earlier, I would love to see
> the current draft.

no; the last state of what I had is attached. it is not tested, and
probably does not work yet.

> We have recently had problems with the zfs packages in Debian (kernel
> version build issues) which I suspect would have been discovered earlier
> if ci.debian.org was running the zfs test. :)

sure, however testing anything other than main is not high on my
priority list, so if you can come up with a tested and working patch it
will make things faster.
diff --git a/backends/lxc/create-testbed b/backends/lxc/create-testbed
index ce307c8..243a2a1 100755
--- a/backends/lxc/create-testbed
+++ b/backends/lxc/create-testbed
@@ -87,9 +87,12 @@ if [ "$distro" = debian ]; then
   else
 buildd_suite="buildd-$debci_suite-proposed-updates"
   fi
+  if ! grep -q contrib "${rootfs}/etc/apt/sources.list"; then
+sed -i -e 's/main/main contrib/' "${rootfs}/etc/apt/sources.list"
+  fi
   cat > "${rootfs}/etc/apt/sources.list.d/buildd.list"  "${debci_chroot_path}/etc/apt/sources.list.d/sources.list"
 
+  # add contrib
+  if ! grep -q contrib "${debci_chroot_path}/etc/apt/sources.list"; then
+sed -i -e 's/main/main contrib/' "${debci_chroot_path}/etc/apt/sources.list"
+  fi
+
   # FIXME duplicates logic in bin/debci-setup-chdist
   if grep -q debian "${debci_chroot_path}/etc/apt/sources.list"; then
 if [ "$debci_suite" = unstable ]; then
@@ -56,8 +61,8 @@ create_chroot() {
   buildd_suite="buildd-$debci_suite-proposed-updates"
 fi
 cat > "${debci_chroot_path}/etc/apt/sources.list.d/buildd.list"  "$TARGET/etc/apt/sources.list"
   buildd_suite=buildd-$SUITE-proposed-updates
 fi
 cat >> "$TARGET/etc/apt/sources.list" 

Bug#838200: (gnome-software:15001): Gs-ERROR **: CSS parsing error: not a number

[Pascal Obry]

Same for me. I'm on Debian/unstable with gnome-software 3.20.2.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Bug#644240: bat: ASSERT failure in QList::operator[]: "index out of range"

[Teodor MICU]

Hi,

2016-09-21 0:58 GMT+03:00 Carsten Leonhardt :
> do you still have this problem with a current bacula version?

I cannot test this anymore, from what I know they (old job) still use
the old bacula version. I suppose you can close this bug.

Thanks

Bug#838503: debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation

[Baptiste Jonglez]

Package: debian-installer
Version: 20160630

When creating a RAID1 array in the debian-installer and using it for the
installation, mdadm immediately starts syncing the disks of the RAID
array.

This is a bad idea, because the subsequent install will be really slow on
rotational disks (linear disk access by mdadm and random disk access by
dpkg).  On a fairly recent computer with 2 SATA disks, the installation
took around 20 minutes before even arriving to the tasksel step.

I can see two solutions:

1) lower the speed of the syncing operation, by setting the
   "dev.raid.speed_limit_max" sysctl setting to e.g. 1000;

2) disable syncing altogether, by passing "--assume-clean" to mdadm when
   creating the array.


This second solution does not seem to be recommended by the mdadm
developers, here is an excerpt of the mdadm man page:

--assume-clean

Tell mdadm that the array pre-existed and is known to be clean.  It
can be useful when trying to recover from a major failure as you can
be sure that no data will be affected unless you actually write to the
array.  It can also be used when creating a RAID1 or RAID10 if you
want to avoid the initial resync, however this practice — while
normally safe — is not recommended.  Use this only if you really know
what you are doing.

When the devices that will be part of a new array were filled with
zeros before creation the operator knows the array is actually
clean. If that is the case, such as after running badblocks, this
argument can be used to tell mdadm the facts the operator knows.


Regards,

Bug#838504: debian-installer: debconf-apt-progress fails to parse localized numbers and spams tty4

[Baptiste Jonglez]

Package: debian-installer
Version: 20160630
Tags: l10n
Severity: minor

When installing a new Debian system using debian-installer and setting a
French locale, a large number of warning messages related to debconf are
visible in tty4 throughout the installation.  The messages are similar to
the following:

in-target: Argument "27,2727" isn't numeric in multiplication (*) at 
/usr/bin/debconf-apt-progress line 168,  line 29.

It looks like the French locale causes decimal numbers to be formatted as
"42,1337" instead of "42.1337" when passing data to debconf-apt-progress.
This seems incorrect: format localisation should only be used when
presenting text to humans, not when feeding data to other programs.

These messages are merely annoying, because it's almost impossible to read
the other kind of (more interesting) messages displayed in tty4.  On the
other hand, progress bars on the dialog frontend in tty1 do seem to work
normally, despite these messages.

This is using the Debian-installer Stretch Alpha 7 release (which
presumably uses debconf 1.5.59).  I was installing with the regular
text-based install, not the graphical one.

This bug looks a bit similar to #729699.

Regards,

Bug#838393: PCA on a repository insufficient to update uploaders

[Sam Hartman]

So, I can see a couple of easy fixes:

1) have _uploaders be a class variable rather than an instance variable

or

2) store a list ofweakrefs to extant demon objects

then provide a class method to invalidate all the uploaders caches.