Bug#849348: chrome-gnome-shell: Install Firefox extension

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2017-01-11 at 19:16 -0500, Jeremy Bicha wrote:
> I think I was wordy and unclear in this bug report. I am requesting
> that the Firefox extension be shipped in this package too. Currently
> in 8-2, the Firefox system helper is installed but each user needs to
> manually visit https://addons.mozilla.org/en-US/firefox/addon/gnome-shell-inte
> gration/
> to install the extension for https://extensions.gnome.org/ to work
> with Firefox 52 as well as it does with older Firefox versions.
> 

I don't understand your request here. The firefox policy is being shipped with
the package. For the extension, the homepage says that users need to install it
manually. Even for Chromium, where the policy is present, the extension will be
auto-installed in a near future version of Chromium.

https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome/Installation


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

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlh3MpsACgkQpjpYo/Lh
dWlBbg/9ELXCWkUWRg8bvV7auYERcS16Z+kMcnibPp6lSq4MMb/v+yyEkPjRmLYr
Oefy8VAs1d8WWEs/9sDOAYTg0OhKCYZgHqRE3ieV1mnn+F/SX6kk0nrifSmi9CWW
TkBroHR0J3bzm56LnA0t2mC9wA6nHcqyv6r81ffU8J8hdJWmxfFX3auB1Q+pXYYK
Y1PgITy0o5bLipo8G8QyqtMq+xwHw1SlSBXDc71YpzfKhUWqB+0gFO4wgA2VizyK
D9WdAMt+LmEte41ic9Xa+42cACq2eRyAUDfqheAhgqza1b8yYzOQW1VqelJilmvt
wUSKZIJWw5ek3A89wKt4Un0m2fIRqnziyB5ZQlwop2J7XkTpRH+UMBEFVDWxT33j
BThg9Hytl0fg/AL7uZO2S7x7491cUg180EG1z3fk5+YO7xJ+6RE6K1NpmVYyWLby
nVs97jnf7jH5EpM/aBg0dHj1FviOT47jHwMM65vMQBplzmw4bX4GfJ/pUpyJSebr
4Xz98lQzNlrGo3JR4FE05jkNjnSPF3qEz0KtGO3YxSYstiNUB/AgXijQ7Alb6YQf
NHloG1qcVBSg0KQal5SM2u9IPF8XGpoqdcUJiZz6/hA+sG2XmCOc3Ituw39xjw/E
dNK/j5wRPeKTPOV11R1iQLNugd0KxpZFUVfPUL6CtSfbNF95zmA=
=MMR7
-END PGP SIGNATURE-

Bug#851118: apparmor-docs: Don't include AppArmor_Developer*.pdf

[intrigeri]

Package: apparmor-docs
Version: 2.11.0-1
Severity: normal

In apparmor-docs 2.11.0-1 I've started including
/usr/share/doc/apparmor-docs/AppArmor_Developer_*.pdf.gz; since then,
one of the upstream lead developers (John Johansen) told me: "I just
don't think the docs are ready for consumption and are probably more
confusing for users than helpful".

So let's revert this (r1618 in our Vcs-Bzr). It would be nice to do it
in time for Stretch, but getting 2.11.0-1 in Stretch is higher
priority to me, so I want to wait for it to migrate to testing before
uploading -2.

Cheers,
-- 
intrigeri

Bug#851117: [apper] after upgrading from jessie to stretch, systray icon not working: module "QtQuick" version 1.1 is not installed

[Laura Arjona Reina]

Package: apper
Version: 0.9.2+git20161222-1
Severity: normal

Dear maintainer

Thank you very much for your work in Apper.

I use KDE Plasma but GNOME is also installed in my system.

I upgraded from Debian jessie to stretch some weeks ago. The upgrade 
automatically installed Plasma-discover and I've been using it since 
then (I thought that Plasma-discover had superseeded Apper when I saw 
"Discover" in my new stretch system).


Since some days ago, I noticed a different systray icon, similar to the 
one of discover, but yellow, announcing updates available.
I just learned that this icon corresponds to Apper, which is still 
installed in my system. Is this because of the GNOME desktop? If yes, I 
guess in KDE Plasma the Apper icon should not be shown by default in the 
systray (given Plasma-discover is installed and used too).


When I click on the apper icon, it says:

Error loading the file QML: 
file:///usr/share/plasma/plasmoids/org.packagekit.updater/contents/ui/main.qml:19:1: 
module "QtQuick" version 1.1 is not installed



(and Apper is not opened).


If I launch Apper from the menu, it works well. It's just the icon which 
is not working (well, hovering also works, it says "Software updater. It 
shows and updates software" in Spanish). Is there any dependency in 
transition and I just need to wait?


I like both Apper and Plasma-discover, and they look like similar to me 
(I mean, should I probably choose and keep only one? I don't know if I 
can safely uninstall apper or discover in my KDE Plasma system, or any 
of them is "tied" to the desktop).


Thanks!

--- System information. ---
Architecture:
Kernel: Linux 4.8.0-2-amd64

Debian Release: stretch/sid
500 testing httpredir.debian.org

--- Package information. ---
Depends (Version) | Installed
-+-=
apper-data (>= 0.9.2+git20161222-1) | 0.9.2+git20161222-1
packagekit (>= 0.8.6) | 1.1.4-3
polkit-kde-1 | 4:5.8.4-1
OR policykit-1-gnome |
software-properties-kde | 0.96.20.2-1
kio | 5.27.0-2
libappstream4 (>= 0.10.0) | 0.10.5-1
libc6 (>= 2.14) |
libdebconf-kde1 (>= 0.1+git20101209) |
libgcc1 (>= 1:3.0) |
libglib2.0-0 (>= 2.16.0) |
libkf5auth5 (>= 4.96.0) |
libkf5bookmarks5 (>= 4.96.0) |
libkf5codecs5 (>= 4.96.0) |
libkf5completion5 (>= 4.97.0) |
libkf5configcore5 (>= 4.97.0) |
libkf5configgui5 (>= 4.97.0) |
libkf5configwidgets5 (>= 4.96.0) |
libkf5coreaddons5 (>= 4.100.0) |
libkf5crash5 (>= 4.96.0) |
libkf5dbusaddons5 (>= 4.99.0) |
libkf5emoticons-bin |
libkf5emoticons5 (>= 4.96.0) |
libkf5guiaddons5 (>= 4.96.0) |
libkf5i18n5 (>= 4.97.0) |
libkf5iconthemes5 (>= 4.96.0) |
libkf5itemmodels5 (>= 4.96.0) |
libkf5itemviews5 (>= 4.96.0) |
libkf5jobwidgets5 (>= 4.96.0) |
libkf5kcmutils5 (>= 5.2.0+git20141003) |
libkf5kdelibs4support5 (>= 4.99.0) |
libkf5kiocore5 (>= 4.96.0) |
libkf5kiofilewidgets5 (>= 4.96.0) |
libkf5kiowidgets5 (>= 4.96.0) |
libkf5notifications5 (>= 4.96.0) |
libkf5parts5 (>= 4.96.0) |
libkf5service-bin |
libkf5service5 (>= 4.96.0) |
libkf5solid5 (>= 4.97.0) |
libkf5sonnetui5 (>= 4.96.0) |
libkf5textwidgets5 (>= 4.96.0) |
libkf5unitconversion5 (>= 4.96.0) |
libkf5widgetsaddons5 (>= 4.96.0) |
libkf5windowsystem5 (>= 4.97.0) |
libkf5xmlgui5 (>= 4.96.0) |
libkworkspace5-5 (>= 4:5.8.1) |
liblimba0 |
libpackagekitqt5-0 |
libqt5core5a (>= 5.7.0) |
libqt5dbus5 (>= 5.0.2) |
libqt5gui5 (>= 5.7.0) |
libqt5network5 (>= 5.0.2) |
libqt5printsupport5 (>= 5.0.2) |
libqt5qml5 (>= 5.0.2) |
libqt5quick5 (>= 5.0.2) |
libqt5sql5 (>= 5.0.2) |
libqt5widgets5 (>= 5.6.0~beta) |
libqt5xml5 (>= 5.0.2) |
libqt5xmlpatterns5 (>= 5.0.2) |
libstdc++6 (>= 4.1.1) |


Recommends (Version) | Installed
=-+-===
appstream | 0.10.5-1
debconf-kde-helper | 1.0.2-1


Suggests (Version) | Installed
===-+-===
limba |





--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#850773: xul-ext-kwallet5: Doesn't work with firefox "non-ESR"

[Gregor Riepl]

Package: xul-ext-kwallet5
Version: 1.0-2
Followup-For: Bug #850773

It doesn't look like manually updating to the current version
of the addon (1.3) helps either.

Have you tried that?

Bug#850772: multipath-tools-boot: fails to upgrade from 'jessie' - trying to overwrite /etc/init.d/multipath-tools-boot

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2017-01-12 at 02:47 +0100, Andreas Beckmann wrote:
> > Preparing to unpack .../multipath-tools_0.6.4-1_amd64.deb ...
> > Unpacking multipath-tools (0.6.4-1) over (0.5.0-6+deb8u2) ...
> > Preparing to unpack .../multipath-tools-boot_0.6.4-1_all.deb ...
> > Unpacking multipath-tools-boot (0.6.4-1) over (0.5.0-6+deb8u2) ...
> 
> how did you do your upgrade test? with apt? aptitude?
> in your case the problematic packages were upgraded in the opposite
> order compared to my test, so the overwritten file was already gone - no
> conflict

I simply used apt to upgrade. Why should it matter what tool is used ?

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

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlh3L4AACgkQpjpYo/Lh
dWn/cw/9HHcDYXModaPUDpEYptC/e7U4VKwTcwVEjXAvzdUX3J4Jn8ccHsQ02Arq
/raL+CHRQ53IUXErSIZI/bl3q4kO35srjDCIMBXJOvphy94bXL+qsGV63Xt5lp8W
1ylR9Pm8Tsw5eQQ+z9wEWoW9o5hu59jwqiQ8duA0tCKjDh2AwUO2Dn7Q9yS2nyAg
lT60UqcMleDGFFHpREbeBEPp6let13brN7PMYCgDvn+oCy6LCrWajA31VVZVQU6y
mdoVGTb674Dy5+4U/96xAxCpjg4YMi5EG4PrT7Evne0uubvY4GE9JSVnov5OCvhn
nokrZLQ3TfJKenpJFmjFeNQ7Ktxo14ViQO6EJz04G3LFx9Ep3F4pRfPDGkPTK17C
+Ou+yo5doZm/B6hUaOiTkiZ0OxguNVjdo1ekHtmaSuXSAnQruoYfd6YhU0DNSZoX
qAAbigc0NIUFaNeEwc98E84606CzRrSgMx5cX5Ugo9liXhGPB4iHpMrAlYST6M4Y
pPwDYlcZtW+OxF1endMYvAVvzc7m6KjjvkXEpT1GGeCcbCeE49soDH1FWKsI0N4m
LCqAiDVCOdkYAfEx8EhppDeoalLGd8aSwmNbs7OPkQndw7ivZpQOEC8wzZKEZ3it
sr9orPKFpj9dT7gkuzDyySFL4I50tOTIb5h+Z3y/tF5VDgJfHqY=
=a9Dc
-END PGP SIGNATURE-

Bug#851028: composite: FTBFS: lrdf.h:8:20: fatal error: raptor.h: No such file or directory

[Jaromír Mikeš]

2017-01-12 1:09 GMT+01:00 Jonas Smedegaard :

> Quoting Jaromír Mikeš (2017-01-11 23:29:24)
> > 2017-01-11 19:55 GMT+01:00 Lucas Nussbaum :
> >
> > >
> > > During a rebuild of all packages in sid, your package failed to build
> on
> > > amd64.
> > >
> > > Relevant part (hopefully):
> > > >^~~
> > > > In file included from /<>/composite-0.006.
> > > 2+dfsg0/src/Tritium/src/fx/Effects.cpp:36:0:
> > > > /usr/include/lrdf.h:8:20: fatal error: raptor.h: No such file or
> > > directory
> > > >  #include 
> > > > ^
> > > > compilation terminated.
> > > > src/Tritium/CMakeFiles/Tritium.dir/build.make:1025: recipe for
> target
> > > 'src/Tritium/CMakeFiles/Tritium.dir/src/fx/Effects.o' failed
> > > > make[3]: *** [src/Tritium/CMakeFiles/Tritium.dir/src/fx/Effects.o]
> > > Error 1
> > >
> > > The full build log is available from:
> > >http://aws-logs.debian.net/2017/01/11/composite_0.006.2+
> > > dfsg0-6_unstable.log
> > >
> > >  pkg-multimedia-maintainers>
> > >
> >
> > Hi Jonas,
> >
> > isn't it this bug rather bug in ldrf and the line in /usr/include/lrdf.h
> > file should be:
> > #include 
> > as ldrf now B-D on libraptor2-dev?
>
> Well, that would be one way to solve it, but the more correct one, I
> believe, is for composite to use pkg-config.
>
> Something like this:
>
>   pkg-config --cflags liblrdf
>
> should correctly provide this:
>
>   -I/usr/include/raptor2 -I/usr/include
>
>
> Seems to me that composite build fails to properly set build flags, but
> happened to work anyway in the past because back then no custom path was
> needed.


Thank you Jonas,

I will have a look on this latter ... now I am short on time ... just
leaving :(

mira

Bug#851021: nikola: FTBFS: pkg_resources.DistributionNotFound: The 'olefile' distribution was not found and is required by Pillow

[Christoph Biedl]

Control: tags 851021 patch

Lucas Nussbaum wrote...

> During a rebuild of all packages in sid, your package failed to build on
> amd64.

> > pkg_resources.DistributionNotFound: The 'olefile' distribution was not 
> > found and is required by Pillow

This was fixed in the build dependency on python-pil 4.0.0-3 which
(re-)includes a dependency on python*-olefile needed to build nikola.
That's also the reason why it's not that easy to reproduce the issue.

nikola maintainer: Adding a build dependency on python-pil (>= 4.0.0-3)
should fix the issue. Yes, including the Debian revision.

Christoph


signature.asc
Description: Digital signature

Bug#850846: Additional patches required; reopen

[Harlan Lieberman-Berg]

found 850846 2.2.0.0-2
reopen 850846
thanks

Ansible had to release 2.2.1.0-0.4-rc4 with more security fixes.  Seems
the patch from earlier missed a couple of corner cases.  I'll
need to update, but also shouldn't be doing a release at 0200.  Will get
to it ASAP tomorrow.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#850848: RM: pgrouting [mips mips64el mipsel] -- ROM; unsatisfiable Depends on mips* (outdated postgis packages)

[Sebastiaan Couwenberg]

reopen 850848
thanks

Hi Scott,

On Tue, 10 Jan 2017 14:11:45 -0500 Scott Kitterman wrote:
> On Tuesday, January 10, 2017 07:58:13 PM Sebastiaan Couwenberg wrote:
> > On 01/10/2017 07:23 PM, Bas Couwenberg wrote:
> > > Please remove pgrouting from mips*, the latest builds picked up outdated
> > > postgis dependencies which should have been removed (#847756).
> > 
> > The outdated dependencies were not strictly picked up, the pgrouting
> > packages only depend on postgis packages, not build depend. I've added
> > postgis to the build dependencies to force the pgrouting package to
> > BD-Uninstallable state on architectures where postgis is not available.
> > 
> > The old postgis packages were correctly removed from mips*, only old
> > revisions of arch:all packages remain in the mips* Packages files.
> 
> That makes more sense (I was in the middle of writing an email saying that 
> the 
> old mips* binaries were in fact removed).
> 
> In this case, I think that once you upload the new revision those should be 
> automatically decrufted and no bug is needed.  I'm going to close this on 
> that 
> basis.  If you find otherwise after the upload, please reopen.

Unfortunately I don't see pgrouting in the cruft-report, and the testing
migration will be prevented due to missing binaries on mips*.

Please remove the pgrouting binaries from mips*

Kind Regards,

Bas

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

Bug#781987: Regarding bug #781987 - dwww: All links are broken after clean install

[Arjan Opmeer]

I ran into the same problem and started investigating.

On Fri, 6 Jan 2017 22:44:49 +0100 Jerome  wrote:
> 
> [Fri Jan 06 21:34:53.830541 2017] [http:error] [pid 6785:tid 
> 140419151554304] [client ::1:45220] AH02429: Response header name 'Last 
> modified' contains invalid characters, aborting request, referer: 
> http://localhost/dwww/
> 
> This generated what looks like proper output, the header is:
>   Content-type: text/html
>   Last modified: Tue Dec 13 14:16:35 2016
>   Content-Disposition: inline; filename="index.html"
> 
> The 'Last modified' looks ok to me...

Actually the header should read "Last-Modified" (note spelling). After
patching the dwww script to emit the correct header the error no longer
occurs with Apache.

This incorrect header is output by the script /usr/sbin/dwww-convert. I made
the following change to it:

--- dwww-convert.OLD2017-01-12 06:24:58.208140587 +0100
+++ dwww-convert2017-01-12 06:25:13.900487551 +0100
@@ -327,7 +327,7 @@
 print "Content-type: $mime_type" . (defined $mime_charset ? "; 
charset=$mime_charset\n" : "\n");
 my @stat = stat( $filename );
 my $mtime = $stat[9];
-print "Last modified: " . gmtime($mtime) . "\n";
+print "Last-Modified: " . gmtime($mtime) . "\n";
 print "Content-Disposition: inline; filename=\"$base_name\"\n";
 print "\n";
 } # }}}

Although the date string is technically in an obsolete format, conforming
clients (like Apache) are required to be able to parse it. So this poses no
further problem.


Arjan

Bug#851115: pcs: violates font license

[Paul Wise]

Source: pcs
Version: 0.9.155-3
Severity: serious
User: pkg-fonts-de...@lists.alioth.debian.org
Usertags: license-violation
X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org

Your source package contains an GPL/LGPL font:

pcsd/public/css/LiberationSans-BoldItalic.ttf
pcsd/public/css/LiberationSans-Italic.ttf
pcsd/public/css/LiberationSans-Regular.ttf
pcsd/public/css/LiberationSans-Bold.ttf

This looks to be from here:

https://fedorahosted.org/liberation-fonts/

The font's source code appears to be here:

https://git.fedorahosted.org/cgit/liberation-fonts.git/tree/src

Your source package does not contain the font source code, therefore
your distribution of the font constitutes a violation of the license.

Please notify your upstream that they are violating the font license.

Please remove the font from the source package and build-depend or
depend on the fonts-liberation binary font package instead.

Please contact your upstream and ask them to use fontconfig or similar
to get fonts for use by the software instead of using a specific font.

This message is brought to you by the Debian Fonts Task Force:

http://wiki.debian.org/Fonts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#851116: zygrib: violates font license

[Paul Wise]

Source: zygrib
Version: 8.0.1-1
Severity: serious
User: pkg-fonts-de...@lists.alioth.debian.org
Usertags: license-violation
X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org

Your source package contains an GPL/LGPL font:

data/fonts/liberation-fonts/LiberationSans-BoldItalic.ttf
data/fonts/liberation-fonts/LiberationMono-BoldItalic.ttf
data/fonts/liberation-fonts/LiberationSerif-BoldItalic.ttf
data/fonts/liberation-fonts/LiberationSans-Italic.ttf
data/fonts/liberation-fonts/LiberationSerif-Bold.ttf
data/fonts/liberation-fonts/LiberationMono-Bold.ttf
data/fonts/liberation-fonts/LiberationSans-Regular.ttf
data/fonts/liberation-fonts/LiberationMono-Regular.ttf
data/fonts/liberation-fonts/LiberationSerif-Regular.ttf
data/fonts/liberation-fonts/LiberationSans-Bold.ttf
data/fonts/liberation-fonts/LiberationSerif-Italic.ttf
data/fonts/liberation-fonts/LiberationMono-Italic.ttf

This looks to be from here:

https://fedorahosted.org/liberation-fonts/

The font's source code appears to be here:

https://git.fedorahosted.org/cgit/liberation-fonts.git/tree/src

Your source package does not contain the font source code, therefore
your distribution of the font constitutes a violation of the license.

Please notify your upstream that they are violating the font license.

Please remove the font from the source package and build-depend or
depend on the fonts-liberation binary font package instead.

Please contact your upstream and ask them to use fontconfig or similar
to get fonts for use by the software instead of using a specific font.

This message is brought to you by the Debian Fonts Task Force:

http://wiki.debian.org/Fonts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#851113: manaplus: violates font license

[Paul Wise]

Source: manaplus
Version: 1.7.1.7-1
Severity: serious
User: pkg-fonts-de...@lists.alioth.debian.org
Usertags: license-violation
X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org

Your source package contains an GPL/LGPL font:

data/fonts/liberationsans.ttf
data/fonts/liberationsansmono.ttf
data/fonts/liberationsans-bold.ttf
data/fonts/liberationsansmono-bold.ttf

This looks to be from here:

https://fedorahosted.org/liberation-fonts/

The font's source code appears to be here:

https://git.fedorahosted.org/cgit/liberation-fonts.git/tree/src

Your source package does not contain the font source code, therefore
your distribution of the font constitutes a violation of the license.

Please notify your upstream that they are violating the font license.

Please remove the font from the source package and build-depend or
depend on the fonts-liberation binary font package instead.

Please contact your upstream and ask them to use fontconfig or similar
to get fonts for use by the software instead of using a specific font.

This message is brought to you by the Debian Fonts Task Force:

http://wiki.debian.org/Fonts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#851114: minetest: violates font license

[Paul Wise]

Source: minetest
Version: 0.4.15+repack-1
Severity: serious
User: pkg-fonts-de...@lists.alioth.debian.org
Usertags: license-violation
X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org

Your source package contains an GPL/LGPL font:

fonts/liberationsans.ttf

This looks to be from here:

https://fedorahosted.org/liberation-fonts/

The font's source code appears to be here:

https://git.fedorahosted.org/cgit/liberation-fonts.git/tree/src

Your source package does not contain the font source code, therefore
your distribution of the font constitutes a violation of the license.

Please notify your upstream that they are violating the font license.

Please remove the font from the source package and build-depend or
depend on the fonts-liberation binary font package instead.

Please contact your upstream and ask them to use fontconfig or similar
to get fonts for use by the software instead of using a specific font.

This message is brought to you by the Debian Fonts Task Force:

http://wiki.debian.org/Fonts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#851112: gcstar: violates font license

[Paul Wise]

Source: gcstar
Version: 1.7.1-1
Severity: serious
User: pkg-fonts-de...@lists.alioth.debian.org
Usertags: license-violation
X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org

Your source package contains an GPL/LGPL font:

share/gcstar/fonts/LiberationSans-Regular.ttf

This looks to be from here:

https://fedorahosted.org/liberation-fonts/

The font's source code appears to be here:

https://git.fedorahosted.org/cgit/liberation-fonts.git/tree/src

Your source package does not contain the font source code, therefore
your distribution of the font constitutes a violation of the license.

Please notify your upstream that they are violating the font license.

Please remove the font from the source package and build-depend or
depend on the fonts-liberation binary font package instead.

Please contact your upstream and ask them to use fontconfig or similar
to get fonts for use by the software instead of using a specific font.

This message is brought to you by the Debian Fonts Task Force:

http://wiki.debian.org/Fonts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#851111: gargoyle-free: violates font license

[Paul Wise]

Source: gargoyle-free
Version: 2011.1a-3.1
Severity: serious
User: pkg-fonts-de...@lists.alioth.debian.org
Usertags: license-violation
X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org

Your source package contains an GPL/LGPL font:

fonts/LiberationMono-BoldItalic.ttf
fonts/LiberationMono-Bold.ttf
fonts/LiberationMono-Regular.ttf
fonts/LiberationMono-Italic.ttf

This looks to be from here:

https://fedorahosted.org/liberation-fonts/

The font's source code appears to be here:

https://git.fedorahosted.org/cgit/liberation-fonts.git/tree/src

Your source package does not contain the font source code, therefore
your distribution of the font constitutes a violation of the license.

Please notify your upstream that they are violating the font license.

Please remove the font from the source package and build-depend or
depend on the fonts-liberation binary font package instead.

Please contact your upstream and ask them to use fontconfig or similar
to get fonts for use by the software instead of using a specific font.

This message is brought to you by the Debian Fonts Task Force:

http://wiki.debian.org/Fonts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#851110: freedink: violates font license

[Paul Wise]

Source: freedink
Version: 108.4-1
Severity: serious
User: pkg-fonts-de...@lists.alioth.debian.org
Usertags: license-violation
X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org

Your source package contains an GPL/LGPL font:

share/freedink/LiberationSans-Regular.ttf

This looks to be from here:

https://fedorahosted.org/liberation-fonts/

The font's source code appears to be here:

https://git.fedorahosted.org/cgit/liberation-fonts.git/tree/src

Your source package does not contain the font source code, therefore
your distribution of the font constitutes a violation of the license.

Please notify your upstream that they are violating the font license.

Please remove the font from the source package and depend on the
fonts-liberation binary font package instead.

Please contact your upstream and ask them to use fontconfig or similar
to get fonts for use by the software instead of using a specific font.

This message is brought to you by the Debian Fonts Task Force:

http://wiki.debian.org/Fonts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#850885: apache2: Using dwww, fails with internal server error when trying to access /usr/share/doc

[Arjan Opmeer]

I ran into the same problem and started investigating.

On Tue, 10 Jan 2017 22:01:45 +0100 Jerome  wrote:
> 
> When looking at the Apache log, the following entry can be found:
> 
> [Fri Jan 06 21:34:53.830541 2017] [http:error] [pid 6785:tid
> 140419151554304] [client ::1:45220] AH02429: Response header name
> 'Last modified' contains invalid characters, aborting request,
> referer: http://localhost/dwww/
> 
> When calling the dwww CGI script manually, the 'Last modified' field
> is correct however, here's the HTTP header part:
> 
> Content-type: text/html
> Last modified: Tue Dec 13 14:16:35 2016
> Content-Disposition: inline; filename="index.html"

Actually the header should read "Last-Modified" (note spelling). After
patching the dwww script to emit the correct header the error no longer
occurs with Apache. Therefore I believe the bug should be reassigned to
dwww.

I will reply to the corresponding dwww bug report (#781987) with the fix I
applied to the dwww script.


Arjan

Bug#851109: emscripten: violates font license

[Paul Wise]

Source: emscripten
Version: 1.22.1-1
Severity: serious
User: pkg-fonts-de...@lists.alioth.debian.org
Usertags: license-violation
X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org

Your source package contains an GPL/LGPL font:

tests/freetype/LiberationSansBold.ttf

This looks to be from here:

https://fedorahosted.org/liberation-fonts/

The font's source code appears to be here:

https://git.fedorahosted.org/cgit/liberation-fonts.git/tree/src

Your source package does not contain the font source code, therefore
your distribution of the font constitutes a violation of the license.

Please notify your upstream that they are violating the font license.

Please remove the font from the the source package and build-depend on
the fonts-liberation font package instead.

Please contact your upstream and ask them to use fontconfig or similar
to get fonts for use by the software instead of using a specific font.

This message is brought to you by the Debian Fonts Task Force:

http://wiki.debian.org/Fonts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Stuart Prescott]

Nikolaus Rath wrote:

>>> Policy 6.1 says
>>> | Programs called from maintainer scripts should not normally have a
>>> | path prepended to them.
>>>
>>> Ie, programs that are on PATH should be found via the PATH rather than
>>> by hardcoding /usr/bin/foo or whatever.  In general, I think we
>>> normally, at least in software written specifically for Debian, apply
>>> this not just to maintainer scripts but to all program execution.
>>
>> I agree that it's a common practice for software written specifically
>> for Debian.  I'm not convinced it's a common practice elsewhere, and i'm
>> definitely not convinced that we should mandate divergence from upstream
>> for this purpose.
> 
> Just as a datapoint, in other communities there is actually a trend in
> the opposite direction. For example, for the Python ecosystem there is
> an increasing drive to establish a "system Python" that ignores Python
> modules in /usr/local and $PYTHONPATH, specifically to avoid potential
> interference of user installed modules with distribution Python scripts.
> 
> I have a lot of sympathie for this idea, and I think it would be good to
> keep this in mind when discussing potential clarifications of policy.

Nikolaus highlights two failure modes that we see sufficiently often that 
#debian even has boilerplate help text to deal with them:

* user installs their own version of python in /usr/local and then packaged 
python programs start failing (missing modules, incompatible interpreter 
etc), possibly even to the point of breaking package installs/updates such 
that the user can no longer use apt until they work out that is the problem 
and rectify it.

* user installs their own versions of python modules in /usr/local and then 
packaged python programs/modules start failing because the new versions are 
incompatible; this can also easily break maintainer scripts and so break 
package installs/upgrades.

By giving the local admin the ability to override tools using their PATH we 
give them great power and flexibility at the expense of robustness. We give 
the user a loaded gun, help them aim it at their foot and then stand back. 
Shouldn't we be trying to engineer robust solutions rather than footguns? Is 
helping people to accidentally break apt a good thing? Is opening the door 
to subvert gnupg¹ where we want to go? The principle should be one of 
isolation not accidental, unwanted and detrimental coupling.

cheers
Stuart


¹ wild (but fitting) hyperbole; then again, let me quietly add something as 
group:staff to /usr/local/bin...


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#850911: [PATCH] fsharp REPL mangles Unicode characters U+0080 through U+00FF

[Robin Munn]

Looks like Gmail mangled that patch by wrapping lines that shouldn't have
been wrapped. Let's try again, this time turning OFF Gmail's "Plain Text
mode" so that it won't wrap lines longer than 72 characters.


diff --git a/src/fsharp/fsi/console.fs b/src/fsharp/fsi/console.fs
index 3dc5b28..0f6c3ca 100755
--- a/src/fsharp/fsi/console.fs
+++ b/src/fsharp/fsi/console.fs
@@ -13,8 +13,8 @@ open Internal.Utilities
 /// Fixes to System.Console.ReadKey may break this code around, hence the
option here.
 module internal ConsoleOptions =

-  // Bug 4254 was fixed in Dev11 (Net4.5), so this flag tracks making this
fix up version specific.
-  let fixupRequired = not FSharpEnvironment.IsRunningOnNetFx45OrAbove
+  // This fixup for a Windows-only bug causes problems in Debian
+  let fixupRequired = false

   let fixNonUnicodeSystemConsoleReadKey = ref fixupRequired
   let readKeyFixup (c:char) =

Bug#808454: ***SPAM*** Courier was not able to deliver your parcel (ID0000377409, FedEx)

[FedEx Support]

Dear Customer,

Your item has arrived at January 09, but our courier was not able to deliver 
the parcel.

You can download the shipment label attached!

Thanks,
Lester Mcgrath,
Senior Support Manager.


The WatchGuard Firebox that protects your network has detected a message that 
may not be safe.

Cause : The file type may not be safe.
Content type : application/zip
File name: Delivery-Details-377409.doc.wsf
Status   : File Name violation
Action   : The Firebox deleted Delivery-Details-377409.doc.wsf.

Your network administrator can not restore this attachment.

Bug#850487: RFS: terminaltables/3.1.0-1 [ITP]

[Carl Suster]

I have uploaded a new package to mentors and git which now builds successfully 
in a sid chroot with sbuild when given colorclass as an --extra-package.


I would ideally like this in unstable, but since colorclass is already in NEW 
targeting experimental, and this package depends on that one, my understanding 
is that this also needs to go into experimental for now.

Bug#850093: ITP: terminaltables -- Python library for printing tables to the console

[Carl Suster]

I have uploaded a new package to mentors and git which now builds successfully 
in a sid chroot with sbuild when given colorclass as an --extra-package.


I would ideally like this in unstable, but since colorclass is already in NEW 
targeting experimental, and this package depends on that one, my understanding 
is that this also needs to go into experimental for now.

Bug#850911: [PATCH] fsharp REPL mangles Unicode characters U+0080 through U+00FF

[Robin Munn]

Patch for console.fs to take the second, more conservative, option to
fixing this bug. Applying this patch does NOT require updating the
fsharp package to later upstream versions, and once the package is
updated from upstream, this patch can be removed. Patch should apply
cleanly on current master *and* master-experimental branches of the
git://git.debian.org/pkg-cli-apps/packages/fsharp repo.


diff --git a/src/fsharp/fsi/console.fs b/src/fsharp/fsi/console.fs
index 3dc5b28..0f6c3ca 100755
--- a/src/fsharp/fsi/console.fs
+++ b/src/fsharp/fsi/console.fs
@@ -13,8 +13,8 @@ open Internal.Utilities
 /// Fixes to System.Console.ReadKey may break this code around, hence
the option here.
 module internal ConsoleOptions =

-  // Bug 4254 was fixed in Dev11 (Net4.5), so this flag tracks making
this fix up version specific.
-  let fixupRequired = not FSharpEnvironment.IsRunningOnNetFx45OrAbove
+  // This fixup for a Windows-only bug causes problems in Debian
+  let fixupRequired = false

   let fixNonUnicodeSystemConsoleReadKey = ref fixupRequired
   let readKeyFixup (c:char) =

Bug#688295: debsums: incorrectly reports diverted file as missing

[Andreas Beckmann]

Followup-For: Bug #688295
Control: tag -1 patch

Hi,

the attached patch should work around at least some of these missing
diverted foreign files, I'm now testing this with my piuparts instance.


Andreas
>From d138b73f9026624566b3229d0e0934b07450dbee Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Thu, 12 Jan 2017 04:46:05 +0100
Subject: [PATCH] compare diversion owner against unqualified package name, too

Work around dpkg bug #825385: inconsistent arch qualification when
--admindir points to a foreign arch chroot.
dpkg may return arch-qualified package names in foreign chroots while
diversions are 'owned' by an unqualified package.
Compare the diversion owner against the package name and the (possibly)
unqualified package name to avoid false positives like
  debsums: missing file /chroot/usr/bin/foo.diverted (from foo:i386 package)
with
  $pack = foo:i386
  $path = usr/bin/foo
  $diversions{$path} = [ usr/bin/foo.diverted, foo ]

Closes: #688295
---
 debsums | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debsums b/debsums
index b32b3ba..beed62c 100755
--- a/debsums
+++ b/debsums
@@ -462,7 +462,8 @@ sub resolve_path {
 my ($pack, $path, $sum) = @_;
 
 $path = $diversion{$path}[0] if exists $diversion{$path}
-and $diversion{$path}[1] ne $pack;
+and $diversion{$path}[1] ne $pack
+and $diversion{$path}[1] ne $pack =~ s/:.*//r;
 
 my $resolved = resolve_path($path,$pack);
 if ((!sysopen F, "$root/$resolved", O_RDONLY|O_NONBLOCK|$my_noatime) &&
-- 
2.11.0

Bug#850911: fsharp REPL mangles Unicode characters U+0080 through U+00FF

[Robin Munn]

Further information:

The source of the readKeyFixup function which is causing this bug can
be read here:

https://github.com/fsharp/fsharp/blob/de709b30d9b5fdb620ff4e1d439122cdac11ffa1/src/fsharp/fsi/console.fs#L24-L42

In addition to using the NO_SERVERCODEPAGES compilation flag (which I
believe to be the best approach for the Debian package, for reasons
explained below), another possible approach would be to add a patch to
the Debian package that would change line 20 of console.fs from:

  let fixupRequired = not FSharpEnvironment.IsRunningOnNetFx45OrAbove

to:

  let fixupRequired = false

(That's line 20 of console.fs in the current master branch of the
upstream Git repo, which I linked to above. In the code that currently
exists in the Debian package repo, it's line 18, not line 20, of
console.fs).

The reason for making this change in a patch rather than submitting it
upstream is because upstream would need to care about producing
Windows builds of fsi.exe as well, whereas the Debian package of
fsharp will never be used to build anything but Linux builds.

Now, why do I believe that using the NO_SERVERCODEPAGES compilation
flag is the best long-term approach? Because that disables precisely
three bits of code:

1) The readKeyFixup function, which is trying to fix a Windows-only
bug and thereby *introducing* a bug on Linux;

2) The SetServerCodePages function in fsi.fs (see
https://github.com/fsharp/fsharp/blob/de709b30d9b5fdb620ff4e1d439122cdac11ffa1/src/fsharp/fsi/fsi.fs#L629-L657
for source code), which handles two command-line options to set
*numeric* code pages. Those are a Windows-only feature (I'd argue that
they're a misfeature, but I can't change Microsoft's decisions), and
those options *should* be disabled on Linux. Disabling the code that
handles these options won't cause an error if someone passes those
options on the command line (say, because they're writing a
cross-platform script); it will simply cause fsi.exe to silently
ignore those options.

3) A small bit of code later in fsi.fs
(https://github.com/fsharp/fsharp/blob/de709b30d9b5fdb620ff4e1d439122cdac11ffa1/src/fsharp/fsi/fsi.fs#L2293)
that calls SetServerCodePages.

That's it. Using the NO_SERVERCODEPAGES compile flag will disable
precisely those three bits of code, and nothing else. Furthermore,
using that compile flag will not cause any problems even if someone
has written a cross-platform script that uses the undocumented
--fsi-server-input-codepage and --fsi-server-output-codepage options
that this compile flag disables, because when compiled with
NO_SERVERCODEPAGES, fsi.exe still accepts those command-line options
(they just do nothing).

So there are two options to solve this bug:

1) (The better approach). Pull in a more recent tag from the upstream
Git repo (https://github.com/fsharp/fsharp). The NO_SERVERCODEPAGES
was added in between tags 4.0.1.1 (tagged on 2015-12-05) and 4.0.1.2
(tagged on 2016-07-16). The most recent upstream tag is 4.0.1.20
(tagged on 2016-11-14), but any version from 4.0.1.2 onwards will
include the NO_SERVERCODEPAGES compilation flag and will allow you to
fix this bug. This is definitely the right choice for the unstable
distribution, and probably for testing as well. This will, however,
bring in other upstream code changes at the same time, so for any
distributions that are in stable-release mode and don't want to bring
in new upstream code, it might be best to go with the second, more
conservative approach.

2) (The more conservative approach). For any distro that wants to
stick with fsharp 4.0.0.4 and make only minor changes, a single-line
patch to console.fs (to change the "fixupRequired" variable to be
unconditionally false, as I described above) is the most conservative
approach. This will fix this bug on all Debian releases, without
needing to bring in any extra upstream code that may not be desired.

I'll prepare a patch that takes the #2 approach, and I suggest taking
the #1 approach for the version of the fsharp package that's uploaded
to unstable. (Which will need to be bumped again pretty soon anyway,
once F# 4.1 is released).


Sincerely,

Robin Munn

Bug#851108: piuparts should check for leftover binfmts

[Christoph Anton Mitterer]

Package: piuparts
Version: 0.73
Severity: wishlist
Tags: upstream

Hey.

Quite a number of packages over and over leave back their
binfmt registrations (i.e. what one manages via the binfmt-support
package).

openjdk and LLVM are just some notorious examples which do it (despite
of bug reports) basically always again.

Would be nice if a check for that could be added to piuparts.


Cheers,
Chris.


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

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

Versions of packages piuparts depends on:
ii  debootstrap  1.0.87
ii  debsums  2.1.3
ii  dpkg 1.18.18
ii  lsb-release  9.20161125
ii  lsof 4.89+dfsg-0.1
ii  piuparts-common  0.73
ii  python-debian0.1.29
pn  python:any   

Versions of packages piuparts recommends:
pn  adequate  

Versions of packages piuparts suggests:
pn  schroot  

-- no debconf information

Bug#850607: Re: Bug#850607: RFS: flask-login/0.4.0-1 [ITA]

[Sean Whitton]

On Thu, Jan 12, 2017 at 12:48:18PM +1100, Carl Suster wrote:
> Ok I added these headers in git under a new unreleased changelog entry so
> they'll be picked up next time there's a release.

Great work :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851107: xfce: Xfce 4.10 in synaptic for Debian 8.3.0 debugging application.

[Torquato de Rezende]

Package: xfce
Version: 4.10
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 ***
d-i

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

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

Bug#850887: [TIMELY for TC members] Interim Ballot Proposal: #850887 binutils mips

[Sam Hartman]

I heard back from doko today.  We can expect a reply tomorrow.  We also
talked briefly about the issue.

Realistically, i cannot imagine the TC coming to any final decision on
something like this in under three weeks.  That timeline seems fairly
aggressive actually.

However, I think the TC could act much more quickly in an interim
capacity.
I personally believe that having packages building is a better interim
state than the status quo.  There are risks to an interim measure.  We
could have packages in the archive that build but fail to function
correctly.  Depending on what we do long term, we could end up replacing
packges currently in Stretch with packages we can no longer rebuild.
I personally think that when I weigh those risks against my estimate of
their probability, I think it makes sense to adopt an interim measure.

Roughly I propose to override the maintainer and permit an NMU to be
made for this issue.
The decision stands until the maintainer fixes the bug or Stretch
releases, or another resolution is passed (presumably with a more
permanent decision).
Yes, that means that the maintainer could reintroduce the bug and revert
the NMU immediately on the release of Stretch.
First, I hope even the TC can act quickly enough that we're not using an
interim measure then.
Second, I think that's actually appropriate.  The justification for an
interim measure is the impending freeze.  Once we get Stretch out, this
issue is still important, TC involvement may be necessary, but there is
no reason to cut process corners.


I propose to be very agressive in calling for a vote on the following
ballot.
I plan to call for a vote in 24 hours if I get support from at least one
TC member and no objections from within the TC or release team.
In that assumption is a belief that I'll have a chance to review the
patch and the upstream bugzilla discussion prior to calling for a vote.
If I don't have time to do that, I will delay, although I would not
object to someone else who has done the review calling for a vote.
Also, within that time, we should hear from doko.  His input may change
my thinking even for an interim measure.

I want to stress this is only my interim thinking.
This is in the TC git; feel free to fix/amend as necessary.


In #850887, the Debian Technical Committee was asked to choose a
solution for #840227, a bug that prevents a significant number of
packages from building on the mips architecture.  Given the upcoming
Stretch freeze, this issue is urgent.

As an interim measure, using its powers under section 6.1.4 of the
Debian Constitution, the Technical Committee overrules Matthias
Klose's decision to revert the NMU of binutils fixing #840227.  The
committee requests Lisandro Damián Nicanor Pérez Meyer to make a new
NMU fixing #840227.

The committee requests the release team to support the interim nature of this 
solution and if a permanent solution is adopted before the release of Stretch, 
to consider including that solution in Stretch even if the freeze criteria 
would not normally permit such consideration.

In addition, the committee requests the stable release managers for Stretch to 
consider including the eventual upstream solution for this issue into a stretch 
update.

This interim decision stands until the release of Stretch, until it is replaced 
by resolution, or until the binutils maintainer fixes #840227 in some other 
manner.



Choice 1:  Approve the Resolution (3:1 majority)

Choice 2: Reject this Interim Measure

Choice 3: Further Discussion



I've included a separate reject and FD choice to distinguish "we need
more info for deciding on an interm solution even" from "we have enough
info and this approach is bad."


signature.asc
Description: PGP signature

Bug#849348: chrome-gnome-shell: Install Firefox extension

[Yuri Konotopov]

12.01.2017 04:16, Jeremy Bicha пишет:
> On 11 January 2017 at 03:28, Ritesh Raj Sarraf  wrote:
>
> Currently
> in 8-2, the Firefox system helper is installed but each user needs to
> manually visit 
> https://addons.mozilla.org/en-US/firefox/addon/gnome-shell-integration/
> to install the extension for https://extensions.gnome.org/ to work
> with Firefox 52 as well as it does with older Firefox versions.
FYI I'm plan to add inline installation of browser extensions at
https://extensions.gnome.org

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


-- 
Best regards, Yuri Konotopov

Bug#850760: nixstatsagent: modifies conffiles (policy 10.7.3): /etc/nixstats.ini

[Andreas Beckmann]

Followup-For: Bug #850760

and this happens on upgrades from stretch to sid:

  Setting up nixstatsagent (1.1.2-1) ...
  
...
  Preparing to unpack .../4-nixstatsagent_1.1.2-1_amd64.deb ...
  Unpacking nixstatsagent (1.1.2-1) over (1.1.0-1) ...
  Setting up libexpat1:amd64 (2.2.0-2) ...
  Setting up python-pkg-resources (32.3.1-1) ...
  Processing triggers for libc-bin (2.24-8) ...
  Setting up python-psutil (5.0.1-1) ...
  Setting up libsqlite3-0:amd64 (3.16.2-1) ...
  Configuration file '/etc/nixstats.ini'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** nixstats.ini (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
nixstatsagent (--configure):
   end of file on stdin at conffile prompt
...


Andreas

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Samuel Thibault, on Thu 12 Jan 2017 03:27:24 +0100, wrote:
> I'm very surprised to see this 200 value, which means 200ms, while
> studies have shown that "interactivity" is usually seen bad by humans
> beyond 100ms.
> 
> One thing we can do for Stretch is to reduce this value to something
> acceptable. A low value make espeak-ng more CPU-intensive, but that
> shouldn't be too harmful.

I have uploaded a -6 version with 50ms as default. I couldn't notice
a difference between 50ms and 20ms or 10ms, while being much less
CPU-intensive, and that seems coherent with the result of the studies :)

Samuel

Bug#851106: RM: golang-github-geertjohan-go.rice [s390x] -- RoQA; golang is no longer available on s390x

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

another leftover golang binary package on s390x ...


Andreas

Bug#850703: systemd: incorrect LSB support with monit's init script

[Vincent Lefevre]

On 2017-01-11 18:20:14 +0100, Michael Biebl wrote:
> Given that we only have a handful of packages left which use $all, our
> time is better spent if those few packages add native service files.
> 
> Please consider filing a bug report against monit for that.

I've reported:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851101

suggesting to replace

# Should-Start:  $all

by

# Should-Start:  $all mail-transport-agent

as I suppose that the $all is not really useful with systemd since
systemd can monitor its services (unlike SysV), at least in a better
way than monit.

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

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Hello,

Eric Scheibler, on Wed 11 Jan 2017 15:48:39 +0100, wrote:
> I think, that the mute delay and overlapping belong to the same problem. It 
> seems, that the
> espeak-ng module needs too long to clean the current speech buffer. Or in 
> other words: the time
> between the call to cancel speaking and the actual stop of speech is much 
> higher then before.

It seems that by trying various sound setup cases, I eventually found
one where audio output isn't actually asynchronous (using ALSA with
snd_pcm_mmap_writei), and thus pcaudiolib gets stuck while pushing
it. It seems to get better by reducing espeak-ng's buffering.

Could you try to rebuild espeak-ng after modifying file
src/libespeak-ng/speech.c in the espeak_ng_InitializeOutput function,
the line

buffer_length = 200;

into for instance

buffer_length = 20;

or some value between e.g. 10 and 200.

I'm very surprised to see this 200 value, which means 200ms, while
studies have shown that "interactivity" is usually seen bad by humans
beyond 100ms.

One thing we can do for Stretch is to reduce this value to something
acceptable. A low value make espeak-ng more CPU-intensive, but that
shouldn't be too harmful.

Samuel

Bug#851105: jessie-pu: package ndoutils/1.4b9-1.1+deb8u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

ndoutils is one of two packages remaining in the archive that use ucf
unconditionally during postrm purge, causing piuparts failures.
Since the package has been removed after jessie, I propose to finally
fix this bug in jessie-pu.

Andreas
diff -u ndoutils-1.4b9/debian/changelog ndoutils-1.4b9/debian/changelog
--- ndoutils-1.4b9/debian/changelog
+++ ndoutils-1.4b9/debian/changelog
@@ -1,3 +1,10 @@
+ndoutils (1.4b9-1.1+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * postrm purge: Check for ucf before calling it.  (Closes: #677065)
+
+ -- Andreas Beckmann   Thu, 12 Jan 2017 03:10:01 +0100
+
 ndoutils (1.4b9-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u ndoutils-1.4b9/debian/ndoutils-NG-DB.postrm.in ndoutils-1.4b9/debian/ndoutils-NG-DB.postrm.in
--- ndoutils-1.4b9/debian/ndoutils-NG-DB.postrm.in
+++ ndoutils-1.4b9/debian/ndoutils-NG-DB.postrm.in
@@ -18,7 +18,9 @@
 	db_purge
 	for f in ndomod.cfg ndo2db.cfg; do
 		rm -f /etc/@@NG@@/$f
+	  if [ -x /usr/bin/ucf ]; then
 		ucf --purge /etc/@@NG@@/$f
+	  fi
 	done
 fi
 

Bug#841712: systemd: Display black on resume from suspend

[Michael Biebl]

On Sat, 22 Oct 2016 22:59:25 +0200 Michael Biebl  wrote:
> Am 22.10.2016 um 22:46 schrieb Bill Gribble:
> > On 10/22/2016 02:13 PM, Michael Biebl wrote:
> >>
> >> Does /lib/systemd/systemd-sleep hibernate
> >> work?
> > 
> > Ah, interesting!  That works fine, display resumes as expected. Works
> > only as root.
> 
> This is exactly the command that is used by systemd-hibernate.service.
> The only difference afaics is, that systemctl hibernate will signal
> systemd-logind and logind sends out signals to other programs via D-Bus.
> Those then can react on the suspend/hibernate request.
> 
> So, my guess is, that it's not actually systemd which causes this, but
> some other program that reacts on that logind signal.
> 
> Those would typically be X itself and programs listed by systemd-inhibit.
> 
> I assume if you boot into a non-graphical login (say via single on the
> grub command line), then systemctl hibernate works as well?
> 
> I would try a minimal X session next, where systemd-inhibit does not
> list any programs. If that fails, then it sounds like an X problem.
> 
> Check the X related log messages in journal (if you have ssh access,
> that should be no problem)

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#845187: systemd: pressing ctrl-alt-delete repeatedly to force immediate reboot leads to systemd getting stuck with something

[Michael Biebl]

On Fri, 16 Dec 2016 06:15:43 +0100 Michael Biebl  wrote:
> Control: tags -1 + moreinfo
> 
> On Mon, 21 Nov 2016 10:07:53 +0100 Martin Steigerwald
>  wrote:
> > Package: systemd
> > Version: 232-5
> > Severity: normal
> > 
> > Dear Martin, dear Michael, dear Maintainers-
> > 
> > I noticed by pressing Ctrl-Alt-Delete repeatedly quickly at the 90 seconds
> > timeout for stopping a service that didn´t seem to agree with being 
> > stopped
> > at shutdown that systemd did initiate an immediate reboot.
> > 
> > This does no longer work. Systemd still says it triggers an immediate reboot
> > but then seems to be stuck. I waited for a while but there was not output.
> > 
> > I could let it sit for a little more and also provide a screenshot of what
> > is displayed on screen, what I have seen so far didn´t give me a hint 
> > what is
> > getting stuck there.
> > 
> > Maybe there is some debugging stuff I can activate before doing so? If so,
> > can I also tell systemd to store the debugging stuff in a while before
> > actually shutting down the laptop? Otherwise important information may have
> > been scrolled out of the visible screen already.
> > 
> 
> Is this problem reproducible?
> Hitting ctrl+alt+del 7times quickly in a row does reliably reboot here.

Closing due to lack of feedback and with the given information it's not
possible to reproduce the issue.

If you still run into this issue and you are available for further
debugging, please reopen.

Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#850073: dvbcut: FTBFS on hppa -- --with-ffmpeg=/usr not passed to configure

[John David Anglin]

On 2017-01-11, at 8:38 PM, Bernhard Übelacker wrote:

> notfound 850073 0.73.0
> found 850073 0.7.0-1
> thanks
> 
> 
> Hello Dave,
> sorry for the delay.
> I got a little distracted by creating a hppa chroot ...
> 
> I assumed version 0.73.0 was just mixed up from the sbuild version,
> so I am trying to change it to 0.7.0.
> 
> 
> Due to [2] there is currently a version 0.7.1-1 built for hppa.
> I assume this build is overriding dh_auto_configure as you
> suggested, comparing with the last failed log [1].

Yes.
> 
> 
> Before 0.7.0 dh_auto_configure was already overriden, but I
> moved it into the DEB_CONFIGURE_EXTRA_FLAGS [4]. Probably due to
> a warning or lintian message that I cannot reproduce now.
> 
> Always setting the configure parameter seems to be also a leftover
> from the time where dvbcut delivered its own source copy of ffmpeg.
> 
> After that got removed the following line in configure.ac is
> reached without ffmpeg_lib being set and therefore leaving the '-L' alone.
> 
>LDFLAGS="-L$ffmpeg_lib $LDFLAGS"

Yes.

> 
> On the other architectures this seem to work because the '-L' is followed by
>x86_64: gcc ... -L -Wl,-z,relro -Wl,-z,now conftest.c ...

-z relro was broken on hppa.  Probably, this is why the same ld options were 
not set on hppa.
Alan Modra recently fixed this in binutils but the fix is not yet in Debian 
binutils as far as I know.

>hppa:   gcc ... -L  conftest.c ...
> 
> 
> So I am going to plan to move the LDFLAGS line to the two places where
> ffmpeg_lib gets set and remove DEB_CONFIGURE_EXTRA_FLAGS altogether.

Okay.
> 
> Is it ok if we postpone this after the stretch freeze period?

Sure.

Regards,
Dave
--
John David Anglin   dave.ang...@bell.net

Bug#850942: RFS: pydbus/0.6.0-1

[Giovani Ferreira]

control: tags -1 moreinfo

Hi Alberto,

On 11-01-2017 10:12, Alberto Caso wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "pydbus"
> 

I just did a quick review on your package and below are some details that 
could be adjusted:

d/changelog:

- Even the transition to testing is 10 days, you can keep urgency=medium, 
this is the default.

- Please specify the files that have changed or removed (eg: debian/copyright).

d/control e d/compat:

- Please update debhelper to version 10.

- Still in d/control you can update in the Vcs-Browser address from "cgit" 
to "git".

d/copyright:

- What do you think about aligning the copyright years in the 
doc/tutorial.rst block? You could add the email Linus in this block too.

d/rules:

- Remove the first lines of comments, this is not necessary.

d/watch:

- Please, update to version 4.


cheers,

Giovani





signature.asc
Description: OpenPGP digital signature

Bug#850772: multipath-tools-boot: fails to upgrade from 'jessie' - trying to overwrite /etc/init.d/multipath-tools-boot

[Andreas Beckmann]

Control: tag -1 - moreinfo

On 2017-01-10 12:00, Ritesh Raj Sarraf wrote:
> On Tue, 2017-01-10 at 02:17 +0100, Andreas Beckmann wrote:
>>   Preparing to unpack .../multipath-tools-boot_0.6.4-1_all.deb ...
>>   Unpacking multipath-tools-boot (0.6.4-1) over (0.5.0-6+deb8u2) ...
>>   dpkg: error processing archive /var/cache/apt/archives/multipath-tools-
>> boot_0.6.4-1_all.deb (--unpack):
>>trying to overwrite '/etc/init.d/multipath-tools-boot', which is also in
>> package multipath-tools 0.5.0-6+deb8u2
>>   Preparing to unpack .../multipath-tools_0.6.4-1_amd64.deb ...
>>   Unpacking multipath-tools (0.6.4-1) over (0.5.0-6+deb8u2) ...

> I am surprised that I'm not able to reproduce this locally.
> Please see the terminal log.

> Preparing to unpack .../multipath-tools_0.6.4-1_amd64.deb ...
> Unpacking multipath-tools (0.6.4-1) over (0.5.0-6+deb8u2) ...
> Preparing to unpack .../multipath-tools-boot_0.6.4-1_all.deb ...
> Unpacking multipath-tools-boot (0.6.4-1) over (0.5.0-6+deb8u2) ...

how did you do your upgrade test? with apt? aptitude?
in your case the problematic packages were upgraded in the opposite
order compared to my test, so the overwritten file was already gone - no
conflict


Andreas

Bug#850959: Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Vincent Lefevre]

On 2017-01-11 19:37:37 +0100, Michael Biebl wrote:
> [moving this over to #850959]
> Am 11.01.2017 um 19:13 schrieb Michael Biebl:
> > Am 11.01.2017 um 19:12 schrieb Michael Biebl:
> >> Am 11.01.2017 um 18:55 schrieb Vincent Lefevre:
> >>> What info do you need?
> >>
> >> A verbose debug log from shutdown would be helpful.
> > 
> > /usr/share/doc/systemd/README.Debian.gz →
> > Debugging boot/shutdown problems

This is not helpful:

  For shutdown problems, run "systemctl start debug-shell" as root,
  then shut down.

I recall that the problem occurs at the same time as resuming, i.e.
I can't do anything. In particular, the screen remains off.

Also, the problem has only occurred twice over 117 "Lid opened."
messages in 18 months. So, the verbose debug log from shutdown should
be permanently enabled, but without drawbacks for normal usage.

> If you had an unclean power off and a file corruption, please provide
> the fsck log for this incident.
> For / (and /usr) the logs are in /run/initramfs/, for other file systems
> the result is in the journal.

Unfortunately I have only the one corresponding to the last boot
there. No automatic backup of the previous ones?

In the journal, for the problem that occurred on 2015-07-25, in the
next reboot:

Jul 25 17:15:51 zira systemd-fsck[509]: /dev/sda1 was not cleanly unmounted, 
check forced.
Jul 25 17:15:51 zira systemd-fsck[509]: /dev/sda1: 333/62248 files (24.3% 
non-contiguous), 68102/248832 blocks
Jul 25 17:15:51 zira systemd[1]: Started File System Check on 
/dev/disk/by-uuid/7b3de7fd-236a-47f6-bb85-64831a06ca1f.

(/dev/sda1 is mounted on /boot). But also two days later:

Jul 27 16:47:46 zira systemd-fsck[512]: /dev/sda1 was not cleanly unmounted, 
check forced.

Here, it seems that the shutdown was aborted by a bug in the
nouveau driver, which I no longer use, BTW. I've got a few other
ones for known reasons (i.e. no shutdown or shutdown aborted due
to bugs).

Then, on December 23, in the next reboot:

Dec 23 10:52:09 zira systemd-fsck[511]: /dev/sda1 was not cleanly unmounted, 
check forced.
Dec 23 10:52:09 zira systemd-fsck[511]: /dev/sda1: 354/62248 files (26.8% 
non-contiguous), 150547/248832 blocks
Dec 23 10:52:09 zira systemd[1]: Started File System Check on 
/dev/disk/by-uuid/7b3de7fd-236a-47f6-bb85-64831a06ca1f.

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

Bug#850073: dvbcut: FTBFS on hppa -- --with-ffmpeg=/usr not passed to configure

[Bernhard Übelacker]

notfound 850073 0.73.0
found 850073 0.7.0-1
thanks


Hello Dave,
sorry for the delay.
I got a little distracted by creating a hppa chroot ...

I assumed version 0.73.0 was just mixed up from the sbuild version,
so I am trying to change it to 0.7.0.


Due to [2] there is currently a version 0.7.1-1 built for hppa.
I assume this build is overriding dh_auto_configure as you
suggested, comparing with the last failed log [1].


Before 0.7.0 dh_auto_configure was already overriden, but I
moved it into the DEB_CONFIGURE_EXTRA_FLAGS [4]. Probably due to
a warning or lintian message that I cannot reproduce now.

Always setting the configure parameter seems to be also a leftover
from the time where dvbcut delivered its own source copy of ffmpeg.

After that got removed the following line in configure.ac is
reached without ffmpeg_lib being set and therefore leaving the '-L' alone.

LDFLAGS="-L$ffmpeg_lib $LDFLAGS"

On the other architectures this seem to work because the '-L' is followed by
x86_64: gcc ... -L -Wl,-z,relro -Wl,-z,now conftest.c ...
hppa:   gcc ... -L  conftest.c ...


So I am going to plan to move the LDFLAGS line to the two places where
ffmpeg_lib gets set and remove DEB_CONFIGURE_EXTRA_FLAGS altogether.

Is it ok if we postpone this after the stretch freeze period?


Kind regards,
Bernhard



[1] 
https://buildd.debian.org/status/fetch.php?pkg=dvbcut=hppa=0.7.1-1=1483470185
[2] 
https://buildd.debian.org/status/fetch.php?pkg=dvbcut=hppa=0.7.1-1=1483473648
[3] https://buildd.debian.org/status/logs.php?pkg=dvbcut=hppa
[4] 
https://github.com/bernhardu/dvbcut-deb/commit/fec8b06e6b8a2f04b0f61c398e177d1a95ebfb0d

Bug#851104: frama-c: fails to upgrade from 'jessie' - trying to overwrite /usr/lib/frama-c/analyses_manager.cmi

[Andreas Beckmann]

Package: frama-c
Version: 20161101+silicon+dfsg-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 20161101+silicon+dfsg-2

Hi,

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

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

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

  Preparing to unpack .../frama-c_20161101+silicon+dfsg-4_amd64.deb ...
  Unpacking frama-c (20161101+silicon+dfsg-4) over (20140301+neon+dfsg-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/frama-c_20161101+silicon+dfsg-4_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/frama-c/analyses_manager.cmi', which is also 
in package frama-c-base 20140301+neon+dfsg-3
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Preparing to unpack .../frama-c-base_20161101+silicon+dfsg-4_amd64.deb ...
  Unpacking frama-c-base (20161101+silicon+dfsg-4) over (20140301+neon+dfsg-3) 
...


cheers,

Andreas


frama-c_20161101+silicon+dfsg-4.log.gz
Description: application/gzip

Bug#850664: RFS: python-pynzb/0.1.0-3

[Carl Suster]

Control: tag -1 -moreinfo

Hi Sean,



I think you forgot to `git push` :)


Oops! Done.



Also, it would be good if you could use the Forwarded: header to
indicate whether your patches have been sent upstream or not.  This is
especially useful in team-maintained packages.  If you add this now,
don't forget `dch -r` and `git push` ;)


I added the Forwarded headers to point to pull requests I made upstream.


Thanks again,
Carl

Bug#851103: slurm account's UID conflicts with a user -- Allow setting a different ID at install time

[Karl Kornel]

Source: slurm-llnl
Version: 16.05.8-1
Severity: wishlist
Tags: patch

Hello!

We are in the process of setting up a new cluster, which will be available to 
many Stanford people.  As part of setting it up, I discovered that UID 64030 
(which is normally used for SLURM) is already in use by a previous student!  
The student has graduated, so the UID is no longer active, but if the student 
ever comes back, then he will get that UID again, which will cause problems.

(By the way, I say that because the cluster uses central LDAP for account 
information, so giving him a new UID would be difficult.)

The easiest thing to do would be to make a local modification to the existing 
preinst script, replacing “64030” with a different UID (I already have one 
allocated).  But, I think the better way to do it is to make the preinst script 
prompt the user for an ID, and then use that!  This also means that I can offer 
the script for you to take upstream, which is what I’m doing now!

Here’s how things work:

1) If an account called “slurm” already exists, and a group called “slurm” 
already exists, then the package install takes place.  This is actually a break 
from previous behavior.
2) Ask the user to provide an ID.  If no ID is provided (because the user 
cleared the field, because a noninteractive install is happening, etc.), then 
default to ID 64030.
3) Check for non-numeric characters in the response.  If any are found, notify 
the user and mark an error.
4) Check if the ID is already in use, either for a user or a group.  If the ID 
is in use, notify the user and mark an error.
5) If no errors were found, go to the next step.  If there have been three 
failed attempts, then error out the install/upgrade.  Otherwise, increase the 
priority of the query, and go back to Step 2.
6) Add the user/group, as a system account, and without a home directory.

As I mentioned, the biggest change between the original script, and my 
proposal, is that two previous checks have been removed:

* There was a check to see if the slurm account had a home directory; if it 
did, then (under certain conditions) the home directory is changed to 
“/nonexistent”.
* There was a check to see if the existing slurm account had UID and GID 64030.

Both of those checks were removed under the idea that, if an account already 
exists, it should not be messed with.

I would really appreciate it if people could try out this change.  I have tried 
this many times on the new cluster (which runs Ubuntu Xenial), but this patch 
adds a lot of complexity, so I think other people should try it before it gets 
applied (assuming you are willing to take the patch).

NOTE: This patch requires that you have already applied the patches from bug 
850891.  I definitely think bug 850891 should be resolved before this one, 
because that bug moves the same code from three preinst scripts into one.

Finally, it is possible for the text to be translated!  If anyone is interested 
in making translations, information is available here: 
http://www.fifi.org/doc/debconf-doc/tutorial.html#AEN34 (see the section called 
“Localizing the templates file”).

I look forward to any comments that you have.  Thank you very much!

--
A. Karl Kornel | System Administrator
Research Computing | Stanford University
+1 (650) 736-9327
 



0001-Allow-custom-ID-for-slurm-user.patch
Description: 0001-Allow-custom-ID-for-slurm-user.patch

Bug#837081: netbeans: Crashes due to assertion failure in GLib

[Green 7]

On Mon, 9 Jan 2017 17:28:00 +0100 Markus Koschany  wrote:
> On Thu, 8 Sep 2016 11:00:21 -0500 David McMackins
>  wrote:
> > Package: netbeans
> > Version: 8.1+dfsg3-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > Intermittently (but not rarely), NetBeans will crash during editing.
> > Here is the log:
> >
> > GLib:ERROR:/build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/
ghash.c:373:g_hash_table_lookup_node:
> > assertion failed: (hash_table->ref_count > 0)
> > /usr/share/netbeans/8.1/platform/lib/nbexec: line 474: 27016 Aborted
>
> [...]
>
> Hello,
>
> first of all thanks for your reports and sorry for the late reply. I
> could never reproduce these crashes with Netbeans 8.1 but the error
> message indicates Netbeans is probably not to blame for it. I found
>
> http://www.gratifiant.com/chromium-plante-des-quon-appuie-sur-t1013607
>
> The exact same error message was triggered by running chromium, so
> everything points to a bug "outside" Netbeans.
>
> In the meantime glib2.0 and OpenJDK 8 were updated. Can you still
> reproduce the crashes? If yes, please attach your compressed log file
> from ~/.netbeans/8.1/var/log to this bug report. You can also try
> Netbeans 8.2 from experimental and see if it makes any difference.
>
> Regards,
>
> Markus
>

NetBeans 8.1+dfsg3-1 on Debian Stretch also crashes for me and produces the
same terminal output when I enable the Auto Popup on Typing Any Java
Identifier Part and Subword completion options for java code completion.
Running with them disabled does not seem to produce any errors or crashing.

Bug#851101: monit: should better support systemd

[Vincent Lefevre]

Package: monit
Version: 1:5.20.0-6
Severity: minor

/etc/init.d/monit has:

# Should-Start:  $all
# Should-Stop:   $all

but systemd does not support $all in its LSB compatibility support,
and there's no easy way to fix cleanly (see bug 850703).

BTW, according to :
"This only work for start ordering, not stop ordering."

Since systemd has its own monitoring system of daemons, I don't think
that the equivalent of $all would really be needed. The only problem
I can notice is that monit starts before the MTA, so that it can't
immediately send mail. Perhaps

# Should-Start:  $all mail-transport-agent

would be better.

-- Package-specific info:

Monit config file /etc/monit/monitrc is *NOT* readable by reportbug.
Please, consider to rerun reportbug as root and *carefully* examine
reportbug's output (e.g., monitrc content), before sending it out.

Contents of /etc/monit/ directory:
/etc/monit:
total 36
drwxr-xr-x 2 root root  4096 2017-01-12 01:42:24 conf-available
drwxr-xr-x 2 root root  4096 2015-12-05 21:19:30 conf-enabled
drwxr-xr-x 2 root root  4096 2015-07-07 14:43:58 conf.d
-rw--- 1 root root 12449 2016-10-23 02:13:50 monitrc
drwxr-xr-x 2 root root  4096 2016-12-11 18:22:40 monitrc.d
drwxr-xr-x 2 root root  4096 2017-01-12 01:42:24 templates

/etc/monit/conf-available:
total 60
-rw-r--r-- 1 root root  481 2015-12-05 21:13:49 acpid
-rw-r--r-- 1 root root  640 2015-12-05 21:13:49 apache2
-rw-r--r-- 1 root root  455 2015-12-05 21:13:49 at
-rw-r--r-- 1 root root  691 2015-12-05 21:13:49 cron
-rw-r--r-- 1 root root  602 2015-12-05 21:13:49 mdadm
-rw-r--r-- 1 root root  669 2015-12-05 21:13:49 memcached
-rw-r--r-- 1 root root  703 2015-12-05 21:13:49 mysql
-rw-r--r-- 1 root root  521 2015-12-05 21:13:49 nginx
-rw-r--r-- 1 root root  471 2015-12-05 21:13:49 openntpd
-rw-r--r-- 1 root root  950 2015-12-05 21:13:49 openssh-server
-rw-r--r-- 1 root root  683 2015-12-05 21:13:49 pdns-recursor
-rw-r--r-- 1 root root 1421 2015-12-05 21:13:49 postfix
-rw-r--r-- 1 root root  869 2016-03-22 16:43:44 rsyslog
-rw-r--r-- 1 root root  501 2015-12-05 21:13:49 smartmontools
-rw-r--r-- 1 root root  306 2016-02-04 15:03:50 snmpd

/etc/monit/conf-enabled:
total 0

/etc/monit/conf.d:
total 4
-rw-r--r-- 1 root root 357 2015-07-07 14:43:58 eth0

/etc/monit/monitrc.d:
total 64
-rw-r--r-- 1 root root  481 2015-06-09 15:52:48 acpid
-rw-r--r-- 1 root root  640 2015-06-09 15:52:48 apache2
-rw-r--r-- 1 root root  455 2015-06-09 15:52:48 at
-rw-r--r-- 1 root root  691 2015-06-09 15:52:48 cron
-rw-r--r-- 1 root root  403 2016-12-09 15:37:54 fail2ban
-rw-r--r-- 1 root root  602 2015-06-09 15:52:48 mdadm
-rw-r--r-- 1 root root  669 2015-06-09 15:52:48 memcached
-rw-r--r-- 1 root root  703 2015-06-09 15:52:48 mysql
-rw-r--r-- 1 root root  521 2015-06-09 15:52:48 nginx
-rw-r--r-- 1 root root  471 2015-06-09 15:52:48 openntpd
-rw-r--r-- 1 root root  950 2015-06-09 15:52:48 openssh-server
-rw-r--r-- 1 root root  683 2015-06-09 15:52:48 pdns-recursor
-rw-r--r-- 1 root root 1421 2015-06-09 15:52:48 postfix
-rw-r--r-- 1 root root  867 2015-06-09 15:52:48 rsyslog
-rw-r--r-- 1 root root  501 2015-06-09 15:52:48 smartmontools
-rw-r--r-- 1 root root  310 2015-06-09 15:52:48 snmpd

/etc/monit/templates:
total 12
-rw-r--r-- 1 root root 164 2015-06-09 15:52:48 rootbin
-rw-r--r-- 1 root root 160 2015-06-09 15:52:48 rootrc
-rw-r--r-- 1 root root 164 2015-06-09 15:52:48 rootstrict


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

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

Versions of packages monit depends on:
ii  libc6  2.24-8
ii  libpam0g   1.1.8-3.5
ii  libssl1.1  1.1.0c-2
ii  lsb-base   9.20161125
ii  zlib1g 1:1.2.8.dfsg-4

monit recommends no packages.

Versions of packages monit suggests:
ii  postfix [mail-transport-agent]  3.1.4-3
pn  sysvinit-core   

-- Configuration Files:
/etc/monit/monitrc [Errno 13] Permission denied: '/etc/monit/monitrc'

-- no debconf information

Bug#851102: unblock: petsc/3.7.5+dfsg1-2

[Drew Parsons]

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

Please unblock package petsc

Upstream has just released patch version 3.7.5, fixing various bugs.
The ABI remains the same 3.7 (SONAMEs libpetsc_real.so.3.7 and
libpetsc_complex.so.3.7) but ew packages libpetsc3.7.5, etc are
introduced. This is because the debian packaging reflects the upstream
installation structure which provides parallel installation of patch
versions.

Only a small number of packages are involved:
  slepc
  dolfin
  deal.ii
  getdp
  
slepc, deal.ii and getdp will require rebuild. dolfin should be
unaffected since it depend on the virtual ABI version libpetsc3.7
provided by libpetsc3.7.5

3.7.5+dfsg1-1 is already uploaded to experimental, ready to be
dropped into unstable as petsc/3.7.5+dfsg1-2 with your agreement

It would be a good service for the users of stretch if they had access
to the bug fixes provided in this release.

unblock petsc/3.7.5+dfsg1-2

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

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

Bug#851100: base: Network access becomes limited after going to sleep.

[Bodaboom Bodabing]

Package: base
Severity: important
Tags: ipv6

Dear Maintainer,

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

   * What led up to the situation?
   I have two computers with 32 bit Debian Jessie Mate installed. It does not 
happen every time, but some times when either of them goes to sleep, the 
network access becomes severely limited. For example, I will not be able to 
access www.duckduckgo.com or perform necessary updates with apt. However, there 
are some websites that I can still visit (usually any and all "Google" sites 
such as google.com or youtube.com.) I have screen shots showing this from one 
of the computers if you are interested. To me this is more of an annoyance, but 
if anyone else is experiencing this, this could be a critical problem. I 
thought that it was just a fluke when I only had one Debian system doing this, 
but now that I have experienced the problem on two Debian Jessie systems I 
believe it to be a bug.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Rebooting the system takes care of the problem. All network access is 
normal after reboot. Posting this to linuxquestions.org did not prove to be 
fruitful to attain a solution. 
   * What was the outcome of this action?
   Rebooting provides a solution.
   * What outcome did you expect instead?
   To be able to have normal network access without having to reboot.

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


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

Kernel: Linux 3.16.0-4-686-pae (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: systemd (via /run/systemd/system)

Bug#851034: projectreactor: FTBFS: Could not resolve all dependencies for configuration ':reactor-core:compileClasspath'.

[Emmanuel Bourg]

control: reassign -1 libminlog-java

The groupId of minlog changed in libminlog-java/1.3.0, the pom in
libkryo-java must be updated.

Emmanuel Bourg

Bug#851037: kryo-serializers: FTBFS: find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar': No such file or directory

[Emmanuel Bourg]

control: reassign -1 libminlog-java

Thank you for the report Lucas.

The groupId of minlog changed in libminlog-java/1.3.0, the pom in
libkryo-java must be updated.

Emmanuel Bourg

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Nikolaus Rath]

>> Policy 6.1 says
>> | Programs called from maintainer scripts should not normally have a
>> | path prepended to them.
>>
>> Ie, programs that are on PATH should be found via the PATH rather than
>> by hardcoding /usr/bin/foo or whatever.  In general, I think we
>> normally, at least in software written specifically for Debian, apply
>> this not just to maintainer scripts but to all program execution.
>
> I agree that it's a common practice for software written specifically
> for Debian.  I'm not convinced it's a common practice elsewhere, and i'm
> definitely not convinced that we should mandate divergence from upstream
> for this purpose.

Just as a datapoint, in other communities there is actually a trend in
the opposite direction. For example, for the Python ecosystem there is
an increasing drive to establish a "system Python" that ignores Python
modules in /usr/local and $PYTHONPATH, specifically to avoid potential
interference of user installed modules with distribution Python scripts.

I have a lot of sympathie for this idea, and I think it would be good to
keep this in mind when discussing potential clarifications of policy.


Best,
Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#851099: "auto-apt update" tries to fetch wrong URL

[Phil Endecott]

Package: auto-apt
Version: 0.3.24

I believe that the first thing I must do after installing auto-apt is
"auto-apt update", right?

# auto-apt update
Downloading http://ftp.debian.org/debian/dists/stretch 
Contents-arm64.gz ...

2017-01-11 23:47:13 ERROR 404: Not Found.


My /etc/apt/sources.list contains:
deb http://ftp.debian.org/debian stretch main contrib non-free


It seems that auto-apt invokes wget to fetch 
/debian/dists/stretch/Contents-arm64.gz
rather than /debian/dists/stretch/main/Contents-arm64.gz .

Bug#846612: Subj

[Askar Safin]

reassign 846612 lldb-3.9 1:3.9.1-2
thanks

The bug is still present in sid in lldb-3.9 1:3.9.1-2 and possibly in lldb-4.0. 
Steps to reproduce in lldb-3.9:

root@ideal-os:/# cat o.cpp
#include 

int
main (void)
{
  std::vector a;
  a.push_back (0);
}
root@ideal-os:/# clang++-3.9 -g -o o o.cpp 
root@ideal-os:/# lldb-3.9 ./o
(lldb) target create "./o"
Current executable set to './o' (x86_64).
(lldb) b main
Breakpoint 1: where = o`main + 12 at //o.cpp:6, address = 0x0040091c
(lldb) r
Process 527 launched: './o' (x86_64)
Process 527 stopped
* thread #1: tid = 527, 0x0040091c o`main + 12 at //o.cpp:6, name = 
'o', stop reason = breakpoint 1.1
frame #0: 0x0040091c o`main + 12 at //o.cpp:6
   3int
   4main (void)
   5{
-> 6  std::vector a;
   7  a.push_back (0);
   8}
(lldb) n
Process 527 stopped
* thread #1: tid = 527, 0x00400928 o`main + 24 at //o.cpp:7, name = 
'o', stop reason = step over
frame #0: 0x00400928 o`main + 24 at //o.cpp:7
   4main (void)
   5{
   6  std::vector a;
-> 7  a.push_back (0);
   8}
(lldb) 
Process 527 stopped
* thread #1: tid = 527, 0x00400945 o`main + 53 at //o.cpp:8, name = 
'o', stop reason = step over
frame #0: 0x00400945 o`main + 53 at //o.cpp:8
   5{
   6  std::vector a;
   7  a.push_back (0);
-> 8}
(lldb) p a
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named lldb.embedded_interpreter
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'run_one_line' is not defined
(std::vector) $0 = size=1 {
  std::_Vector_base = {
_M_impl = {
  _M_start = 0x00615c20
  _M_finish = 0x00615c24
  _M_end_of_storage = 0x00615c24
}
  }
}
(lldb)

==
Askar Safin
http://vk.com/safinaskar

Bug#849348: chrome-gnome-shell: Install Firefox extension

[Jeremy Bicha]

On 11 January 2017 at 03:28, Ritesh Raj Sarraf  wrote:
> This was completed yesterday with the 8-1 build.

I think I was wordy and unclear in this bug report. I am requesting
that the Firefox extension be shipped in this package too. Currently
in 8-2, the Firefox system helper is installed but each user needs to
manually visit 
https://addons.mozilla.org/en-US/firefox/addon/gnome-shell-integration/
to install the extension for https://extensions.gnome.org/ to work
with Firefox 52 as well as it does with older Firefox versions.

Do you want a new bug report or can we reopen this one?

Jeremy

Bug#851098: Adding Google account fails with "The session wrapping the secret does not exist"

[Luke Faraone]

Package: gnome-online-accounts
Version: 3.22.3-2
Severity: normal
File: goa-daemon

When adding a new Google account to goa, the account is immediately marked
"Credentials have expired" -- this is for an account that has 2FA enabled and
was successfully linked to this computer in the past. (<6 months)

Syslog records the following:

```
Jan 12 00:07:14 argon dbus-daemon[1642]: Activating service 
name='org.freedesktop.Telepathy.ConnectionManager.sofiasip'
Jan 12 00:07:14 argon dbus-daemon[1642]: Activating service 
name='org.freedesktop.Telepathy.ConnectionManager.haze'
Jan 12 00:07:14 argon dbus-daemon[1642]: Successfully activated service 
'org.freedesktop.Telepathy.ConnectionManager.sofiasip'
Jan 12 00:07:14 argon dbus-daemon[1642]: Successfully activated service 
'org.freedesktop.Telepathy.ConnectionManager.haze'
Jan 12 00:07:14 argon goa-daemon[1781]: Remote error from secret service: 
org.freedesktop.Secret.Error.NoSession: The session wrapping the secret does 
not exist
Jan 12 00:07:14 argon goa-daemon[1781]: secret_password_store_sync() failed: 
The session wrapping the secret does not exist
Jan 12 00:07:14 argon goa-daemon[1781]: Remote error from secret service: 
org.freedesktop.DBus.Error.ServiceUnknown: The name :1.15 was not provided by 
any .service files
Jan 12 00:07:14 argon goa-daemon[1781]: secret_password_lookup_sync() failed: 
The name :1.15 was not provided by any .service files
Jan 12 00:07:14 argon goa-daemon[1781]: 
/org/gnome/OnlineAccounts/Accounts/account_1484179634_4: Setting 
AttentionNeeded to TRUE because EnsureCredentials() failed with: Failed to 
retrieve credentials from the keyring (goa-error-quark, 4)
```


Immediately attempting to remove the account errors with a dialog:
> **Error removing account**
> GDBus.Error:org.freedesktop.Goa.Error.Failed: Failed to delete credentials 
> from the keyring

and the following in syslog:
```
Jan 12 00:12:18 argon goa-daemon[1781]: Remote error from secret service: 
org.freedesktop.DBus.Error.ServiceUnknown: The name :1.15 was not provided by 
any .service files
Jan 12 00:12:18 argon goa-daemon[1781]: secret_password_clear_sync() failed: 
The name :1.15 was not provided by any .service files
```


I'm running my session under with Wayland, in case that's part of the issue.


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

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

Versions of packages gnome-online-accounts depends on:
ii  libc6 2.24-8
ii  libgcr-base-3-1   3.20.0-3
ii  libglib2.0-0  2.50.2-2
ii  libgoa-1.0-0b 3.22.3-2
ii  libgoa-backend-1.0-1  3.22.3-2
ii  libkrb5-3 1.15-1
ii  librest-0.7-0 0.8.0-2
ii  libsoup2.4-1  2.56.0-2
ii  libwebkit2gtk-4.0-37  2.14.2-1

Versions of packages gnome-online-accounts recommends:
ii  dleyna-server 0.4.0-1.1
ii  gnome-control-center  1:3.22.1-1
ii  realmd0.16.3-1

gnome-online-accounts suggests no packages.

-- no debconf information

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Eric Scheibler, on Wed 11 Jan 2017 15:48:39 +0100, wrote:
> I thought, that it would be easy to reproduce.

Never assume that something is easy to reproduce.  When a bug is not
fixed, it means the maintainer doesn't have it :)

> >> Instead the speech output overlaps during fast cursor navigation. 
> >> Therefore a fast line-by-line
> >> navigation still is not possible. I even think, that it's a bit worse now.
> >
> >Mmm, when I try espeak and espeak-ng I don't really see a difference
> >here.
> 
> This still happens with espeak version 1.49.0+dfsg-5.
> 
> I think, that the mute delay and overlapping belong to the same problem. It 
> seems, that the
> espeak-ng module needs too long to clean the current speech buffer. Or in 
> other words: the time
> between the call to cancel speaking and the actual stop of speech is much 
> higher then before.

Can you estimate much "too long" it is?  1s? 0.1s? less?  On my box I
don't really see much difference between espeak and espeak-ng.  Do you
have the pulseaudio package installed?

Samuel

Bug#851028: composite: FTBFS: lrdf.h:8:20: fatal error: raptor.h: No such file or directory

[Jonas Smedegaard]

Quoting Jaromír Mikeš (2017-01-11 23:29:24)
> 2017-01-11 19:55 GMT+01:00 Lucas Nussbaum :
> 
> >
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> >
> > Relevant part (hopefully):
> > >^~~
> > > In file included from /<>/composite-0.006.
> > 2+dfsg0/src/Tritium/src/fx/Effects.cpp:36:0:
> > > /usr/include/lrdf.h:8:20: fatal error: raptor.h: No such file or
> > directory
> > >  #include 
> > > ^
> > > compilation terminated.
> > > src/Tritium/CMakeFiles/Tritium.dir/build.make:1025: recipe for target
> > 'src/Tritium/CMakeFiles/Tritium.dir/src/fx/Effects.o' failed
> > > make[3]: *** [src/Tritium/CMakeFiles/Tritium.dir/src/fx/Effects.o]
> > Error 1
> >
> > The full build log is available from:
> >http://aws-logs.debian.net/2017/01/11/composite_0.006.2+
> > dfsg0-6_unstable.log
> >
> > 
> >
> 
> Hi Jonas,
> 
> isn't it this bug rather bug in ldrf and the line in /usr/include/lrdf.h
> file should be:
> #include 
> as ldrf now B-D on libraptor2-dev?

Well, that would be one way to solve it, but the more correct one, I 
believe, is for composite to use pkg-config.

Something like this:

  pkg-config --cflags liblrdf

should correctly provide this:

  -I/usr/include/raptor2 -I/usr/include


Seems to me that composite build fails to properly set build flags, but 
happened to work anyway in the past because back then no custom path was 
needed.


 - Jonas

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

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


signature.asc
Description: signature

Bug#851097: RFS: par2cmdline/0.6.14-2 -- PAR 2.0 compatible file verification and repair tool

[JCF Ploemen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for "par2cmdline":
  Package name: par2cmdline
  Version : 0.6.14-2
  Upstream Author : Ike Devolder et al.
  URL : https://github.com/Parchive/par2cmdline
  License : GPL-2+
  Section : utils

It builds a single binary package:
  par2  - PAR 2.0 compatible file verification and repair tool

Mentors URL:
  https://mentors.debian.net/package/par2cmdline

Download:
dget -x 
https://mentors.debian.net/debian/pool/main/p/par2cmdline/par2cmdline_0.6.14-2.dsc

Changes since the last upload:
  * Control: switch git url to https.
  * Rules: enable all hardening options.
  * Patches:
+ add 02: restore the examples section from the previous manpage,
  written by Andres Salomon. (Closes: #827720)
+ add 03: avoid unconditional use of PATH_MAX which isn't defined on
  hurd. Fixes build failure on that platform.
  * Bump Standards-Version to 3.9.8 (from 3.9.6, no further changes).


Thanks.


pgpw0mbfEALB2.pgp
Description: OpenPGP digital signature

Bug#851056: python-evtx: missing dependency

[Hilko Bengen]

control: severity -1 grave

Damn, now it's too late for adding python-hexdump to stretch. Since this
is just about one function, I should just add that to the package for
the time being.

Cheers,
-Hilko

Bug#805988: aboot : dpkg-buildpackage -A on alpha

[Steve Langasek]

On Wed, Jan 11, 2017 at 12:29:54AM +0100, Santiago Vila wrote:
> On Wed, Jan 11, 2017 at 12:27:00AM +0100, jhcha54008 wrote:

> > How could we keep a working bootloader for our alpha workstations ?

> Can you figure out what changes would be required in the package so
> that the Arch:all package becomes really Arch:alpha?

> I would start by modifying debian/control to read like this:

> Package: aboot-base
> Architecture: alpha

> then debian/rules may need some adjustment, but I can't test that.

> I think that would be the orthodox thing to do for a package which is
> really alpha-specific.

But then the package containing the bootloader-bits-as-data would not be
available to people running on !alpha architectures for purposes of building
installer images.

> The Arch:all thing I admit that it's a clever trick, but it is against
> the release goal (or current setup, depending on how you look at it)
> that every Arch:all package must be buildable in the Arch:all
> autobuilder (which runs amd64).

Well, alpha hasn't been a release architecture for quite some time, so I
don't think that's the most important thing, either.

But it's possible that a better option nowadays would be to use the
gcc-alpha-linux-gnu cross-compiler package.

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


signature.asc
Description: PGP signature

Bug#851096: update-leap tries to fetch https:// using a module without HTTPS support

[Anthony DeRobertis]

Package: ntp
Version: 1:4.2.8p9+dfsg-2
Severity: normal
File: /usr/bin/update-leap

It seems update-leap is just broken, with the default options, because
it attempts to use File::Fetch to grab an https:// URL, but File::Fetch
doesn't support https:// URLs.

Note that newer version of File::Fetch (apparently, starting in 0.50,
from August 2016) supports https:// but Debian doesn't have that
version, at least in testing.

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

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

Versions of packages ntp depends on:
ii  adduser3.115
ii  dpkg   1.18.18
ii  libc6  2.24-8
ii  libcap21:2.25-1
ii  libedit2   3.1-20160903-2
ii  libopts25  1:5.18.12-3
ii  libssl1.1  1.1.0c-2
ii  lsb-base   9.20161125
ii  netbase5.4

Versions of packages ntp recommends:
pn  perl:any  

Versions of packages ntp suggests:
pn  ntp-doc  

-- Configuration Files:
/etc/ntp.conf changed [not included]

-- no debconf information

Bug#850982: [pkg-gnupg-maint] Bug#850982: Add instructions to disable gpg-agent user service in README.Debian

[Daniel Kahn Gillmor]

hi Yuri--

On Wed 2017-01-11 13:33:20 -0500, Yuri D'Elia wrote:
> The gpg-agent and dirmngr services are now auto-enabled for user sessions,
> which is actually a nice improvement.

thanks, i'm glad you like it.

> Can we tweak the instructions present in the README.Debian to include the
> commands required to disable this for a single user, and also globally?

yes, this is probably a good idea.  Patches to the docs are welcome, if
you can get around to writing them before i get to it :)

> I do not want to auto-start these services for the root user. I also want to
> disable auto-start completely in servers I'm logging into. I think both are
> pretty common scenarios and deserve special mention, as systemctl --user
> disable won't work some might expect.

fwiw, nothing is auto-started at all -- the systemd user session opens
the sockets, but doesn't launch any daemons if the sockets are never
used.

Put in more systemd-ish terms: it's the .socket units which are
automatically enabled, not the .service units.

does that change what you want to happen?

Regardless, i agree with you that README.Debian should be improved as
you describe.

--dkg


signature.asc
Description: PGP signature

Bug#851095: override: ofx:utils/optional

[Dylan]

Package: ftp.debian.org
Severity: normal

The package "ofx" should be in the section "utils" instead of the
section "libs".

Thanks.

Best regards,
Dylan

Bug#841208: fixed in monkeysphere 0.41-1

[Daniel Kahn Gillmor]

Hi Santiago--

On Wed 2017-01-11 14:36:16 -0500, Santiago Vila wrote:
> On Wed, Jan 11, 2017 at 02:06:21PM -0500, Daniel Kahn Gillmor wrote:
>
>> (b) it's not actually an issue on the debian buildd infrastructure
>
> While I understand the downgrade of this bug in particular, I'm
> worried about this rationale being used over and over again, when it's
> clearly flawed (and not just simply flawed, but seriously flawed).

fwiw, i agree with you fully here, which is why i didn't close the bug,
and kept the severity as high as "important".  I didn't mean to imply
that the bug was not valid because it builds on the buildd's -- just
that we have a workaround for now because it builds on the buildd's

> We can't just rely on specific and accidental features of
> buildd.debian.org to be present in any autobuilder, we can only rely
> on those who are expressed in build-depends.
>
> We don't have a Build-CPU-MHz: control field to ask for a fast
> autobuilder, but we should probably never have such control field.
>
> We don't have a Build-CPU: control field to ask for a multi-core
> autobuilder, but we should probably never have such control field.

These are qualitatively different from "a builder which has system
entropy available in order to run the test suite".

If we believe that no test suites or build processes should need system
entropy at all (not implausible in these days of reproducible builds and
hopefully-deterministic test suites), another approach would be to
symlink /dev/random to /dev/urandom on all buildd's, and then the
builders just get what they get, rather than starving the system of
entropy.

thanks for continuing to push on this stuff.  If you have any better
suggestions for resolution, i'd be happy to hear them.

I probably need to open an upstream bug with gnupg about subkey
generation when there is limited system entropy too, but i tend to
actually have system entropy on my own hardware and haven't had the time
to set up a deliberately-starved machine for the test process.

--dkg


signature.asc
Description: PGP signature

Bug#851072: gdm3: barfs if x-x-i-evdev|mouse|synaptics is installed on Linux 4.x kernel host

[Martin-Éric Racine]

Package: gdm3
Version: 3.22.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

If xserver-xorg-input-[evdev|mouse|synaptics] are installed on an host running 
current X, GDM3 fails to start. Removing those allows GDM to start again.

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

Kernel: Linux 3.16.0-4-586
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.43-1
ii  adduser   3.115
ii  dconf-cli 0.26.0-2
ii  dconf-gsettings-backend   0.26.0-2
ii  debconf [debconf-2.0] 1.5.59
ii  gir1.2-gdm-1.03.22.1-1
ii  gnome-session [x-session-manager] 3.22.2-1
ii  gnome-session-bin 3.22.2-1
ii  gnome-settings-daemon 3.22.1-1
ii  gnome-shell   3.22.2-1
ii  gnome-terminal [x-terminal-emulator]  3.22.1-1
ii  gsettings-desktop-schemas 3.22.0-1
ii  icewm [x-window-manager]  1.3.8+mod+20161220-1
ii  libaccountsservice0   0.6.43-1
ii  libaudit1 1:2.6.7-1
ii  libc6 2.24-8
ii  libcanberra-gtk3-00.30-3
ii  libcanberra0  0.30-3
ii  libgdk-pixbuf2.0-02.36.2-1
ii  libgdm1   3.22.1-1
ii  libglib2.0-0  2.50.2-2
ii  libglib2.0-bin2.50.2-2
ii  libgtk-3-03.22.5-1
ii  libkeyutils1  1.5.9-9
ii  libpam-modules1.1.8-3.4
ii  libpam-runtime1.1.8-3.4
ii  libpam-systemd232-8
ii  libpam0g  1.1.8-3.4
ii  librsvg2-common   2.40.16-1
ii  libselinux1   2.6-3
ii  libsystemd0   232-8
ii  libwrap0  7.6.q-26
ii  libx11-6  2:1.6.4-2
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.2-1.1
ii  lsb-base  9.20161125
ii  mutter [x-window-manager] 3.22.2-2
ii  policykit-1   0.105-17
ii  ucf   3.0036
ii  x11-common1:7.7+18
ii  x11-xserver-utils 7.7+7
ii  xterm [x-terminal-emulator]   327-2

Versions of packages gdm3 recommends:
ii  at-spi2-core2.22.0-5
ii  desktop-base8.0.2
ii  x11-xkb-utils   7.7+3
ii  xserver-xephyr  2:1.19.0-3
ii  xserver-xorg1:7.7+18
ii  zenity  3.22.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.22.2-1
ii  libpam-gnome-keyring  3.20.0-3

- -- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAlh2uCAACgkQrh+Cd8S0
17amEw//SCT1kfvE4uABRCpl4wu3W5HS/WaoS1ceOpMVOvICfjxpsGO/bjBRXAen
/+wNWOvmZ++NQlmaXIA+7+v7CeSiLWxGbwBAneCkb9bT2epCmS4ScJ5YHsFmDMkx
DRDrMAT0BpxgfEeraivDivt8hpYfPJdWqLjgiXWXIGOKVQjbTHy7nS8+fG8Lzrp1
yAWA4Vvk+NWfmGOyg+ofEus/Y8Zrqi3g0+MXuNhjLzsaG4kndHsPGy0sa0cr5Xpj
B5v3ocofjWt+CoYS4yWKYSJCUtdPys/JSvfXtcfqEX6lagIyYUbs1R0RQe+AHOQp
XHSozrPZ5bwmaf4oMzR4Yi8yb+tZh40Vbxzh+IldaP0F91GCH0NVvLJ5K9zDhD24
Q2/JvM2A3Cf4omXAowZIWW7xBmpYj171O8b2Rl+0ce4qj/ajrrJpOmK+IFRJi2xq
hZUmkuAdalXMk+FB2Jyiq4P9UdQQJUuhClNp4zRDk1diG7lv0/3tOWmjoV1hGsHQ
H2Wd3U+VfTWYT83RR67X36I9ZeZlVygvqtFSNio3h5zQr/i3svTIK3Yr7txBBZA7
Az1/ud2I0jQKkLYt9wEz7nQ0Jpcgiecp8HOH9Y19F6VoguzOPoKG7etC4xSOWmTe
R4rVma3oO2CIICkpaiPUVgtAQcksD+5kKqXLolkQZ1iIJR9GhJ0=
=GIre
-END PGP SIGNATURE-

Bug#851071: debhelper: dh_auto_test now run twice, once under fakeroot

[Sean Whitton]

Package: debhelper
Version: 10.2.3
Severity: important
Control: block 851041 by -1
Control: fixed -1 10.2.2
Control: affects -1 dh-elpa

Dear maintainer,

dh-elpa's dh sequencer file does this:

insert_after("dh_auto_test", "dh_elpa_test");
remove_command("dh_auto_test");

At compat 10 and with debhelper 10.2.2, this caused dh_elpa_test to be
executed once, during the `dh build` sequence.

However, with debhelper 10.2.3, there is an additional call to
dh_elpa_test during the `dh binary` sequence.  Upstream test suites are
often unprepared to deal with fakeroot, and at least one package using
dh-elpa is FTBFSing as a result.

Is there a good reason why package test suites are now run under
fakeroot?  More generally, is there some reason why they are now run
twice?  When designing dh_elpa_test, we chose to require compat 10
precisely to avoid any test suites being run under fakeroot, because we
already knew that at least one of our packages couldn't handle it.  So
this seems like a regression to the behaviour we observed at compat 9.

Thank you for your attention!

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

Kernel: Linux 4.8.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-dev20161112.1
ii  binutils 2.27.51.20161212-1
ii  dh-autoreconf12
ii  dh-strip-nondeterminism  0.028-1
ii  dpkg 1.18.10
ii  dpkg-dev 1.18.10
ii  file 1:5.29-1
ii  libdpkg-perl 1.18.10
ii  man-db   2.7.5-2
ii  perl 5.24.1~rc4-1
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201608

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849762: mutt: complains about GPGME

[Muammar El Khatib]

Package: mutt
Version: 1.7.1-5
Followup-For: Bug #849762

Hi,

Mutt is printing this warning for me as well, but unlike OP, I do have gpg
configured inside my mutt.rc for having my password encrypted.

In my case, I have to enter passwords when launching mutt to enter my GMail
Imap account, and when sending messages to connect to the SMTP.


Thanks,

-- Package-specific info:
NeoMutt 20161126 (1.7.1)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.9.0-rc8-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.1-5' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.1 20161124 (Debian 6.2.1-5)

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-Uun1o_/mutt-1.7.1=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-Uun1o_/mutt-1.7.1=. -fstack-protector-strong 
-Wformat -Werror=format-security -fno-delete-null-pointer-checks

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK
-SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_GETADDRINFO
+HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR
+HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM +HAVE_START_COLOR
+HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS +USE_COMPRESSED +USE_DOTLOCK
+USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX +USE_GSS +USE_HCACHE
+USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL +USE_SETGID +USE_SIDEBAR
+USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL
-DOMAIN
MIXMASTER="mixmaster"
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"

patch-attach-headers-color-neomutt
patch-compose-to-sender-neomutt
patch-compress-neomutt
patch-cond-date-neomutt
patch-encrypt-to-self-neomutt
patch-fmemopen-neomutt
patch-forgotten-attachments-neomutt
patch-forwref-neomutt
patch-ifdef-neomutt
patch-index-color-neomutt
patch-initials-neomutt
patch-keywords-neomutt
patch-kyoto-neomutt
patch-limit-current-thread-neomutt
patch-lmdb-neomutt
patch-multiple-fcc-neomutt
patch-nested-if-neomutt
patch-new-mail-neomutt
patch-nntp-neomutt
patch-notmuch-neomutt
patch-progress-neomutt
patch-quasi-delete-neomutt
patch-reply-with-xorig-neomutt
patch-sensible-browser-neomutt
patch-sidebar-neomutt
patch-skip-quoted-neomutt
patch-status-color-neomutt
patch-timeout-neomutt
patch-tls-sni-neomutt

Bug#851070: ccnet: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

Package: ccnet
Version: 6.0.2-1
Severity: important
Tags: sid buster

This package build-depends on libssl1.0-dev. Please migrate to
libssl-dev in the buster cycle.

Sebastian

Bug#850928: RFS[ITP]: minetest-mod-3d-armor/0.4.5-1

[Julien Puydt]

Hi,

On 11/01/2017 11:41, Mattia Rizzolo wrote:



  IMPORTANT NOTICE: d/copyright doesn't correspond to what you find in
0.4.5's LICENSE.md and README.md files (notice the plural) : it corresponds
to the clarifications I obtained from upstream, which have been committed to
their repository but haven't found their way in an official release yet:
https://github.com/stujones11/minetest-3d_armor/issues/75


uh.

please apply that patch, and add a Comment: field somewhere in
d/copyright ; ftpmasters are not going to read this email.



Upstream was kind enough to release 0.4.7 which has everything settled 
-- I updated both the git repository and mentor's.


Back to RFS-ing :-)

Snark on #debian-games

Bug#851069: cjose: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

Package: cjose
Version: 0.4.1-2
Severity: important
Tags: sid buster

This package build-depends on libssl1.0-dev. Please migrate to
libssl-dev in the buster cycle.

Sebastian

Bug#850956: gosa-plugin-netgroups: fails to show the content of netgroup list entry (e.g. workstation-hosts)

[Mike Gabriel]

On  Mi 11 Jan 2017 23:32:05 CET, Wolfgang Schweer wrote:


On Wed, Jan 11, 2017 at 08:53:57PM +, Mike Gabriel wrote:

On  Mi 11 Jan 2017 16:47:51 CET, Wolfgang Schweer wrote:


[..]


> while testing Debian Edu stretch another PHP7 issue (constructor name)
> showed up.
>
> Please note that for some reason replacing the function name with
> '__constructor' doesn't work in this case.
>
> This patch seems to fix it:
>
> --- a/tabs_netgroup.inc2017-01-11 16:20:32.203632303 +0100
> +++ b/tabs_netgroup.inc2017-01-11 16:13:58.399201779 +0100
> @@ -23,7 +23,7 @@
>
>  class netgrouptabs extends tabs {
>
> -function netgrouptabs($config, $data, $dn, $cat = "", $hide_refs =
> FALSE, $hide_acls = FALSE) {
> +function __netgrouptabs($config, $data, $dn, $cat = "", $hide_refs
> = FALSE, $hide_acls = FALSE) {
>  tabs::__plugin($config, $data, $dn, "netgroups", $hide_refs,
> $hide_acls);
>  $this->addSpecialTabs();
>  }


[..]


Sorry, I doubt this, but are you sure about this?


While the above mentioned '__constructor' has been a typo this exact
replacement actually works; but, '__construct' (like used elswhere in
gosa to fix this PHP7 issue) does not. So yes, I'm pretty much sure.


Can you second it with some official PHP7 porting document or such?


No, but I guess that '__construct' fails as class netgrouptabs extends
tabs which already uses '__construct' - so anything different has to be
used.

Wolfgang


Ok. On my list then... Will also coordinate with GONICUS / upstream on this.

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpYP7C3Fu_d5.pgp
Description: Digitale PGP-Signatur

Bug#850917: Please export /var/lib/dpkg/alternatives content after installation

[Michael Stapelberg]

On Wed, Jan 11, 2017 at 12:55 PM, Andreas Beckmann  wrote:
> On 2017-01-11 12:44, Michael Stapelberg wrote:
>> Thanks for the suggestion. I considered this, but I’m worried this
>> might blow up the logfiles quite a bit for some packages.
>
> How much "logfile" data would that be? Installing texlive-full in sid
> with --install-recommends produces 460 kb, distupgrading it from stable
> (without recommends) 700 kb, and there are some packages producing more
> output than that.

I don’t expect the output to be more than a few kilobytes, so size is
probably indeed not a concern. Making the files available under a
clean URL that is independent of the test result remains a concern of
mine, though.

Attached you can find a first stab at implementing this feature. I
introduced a new protocol message to transfer base64-encoded arbitrary
binary data. This can easily be used to transfer other files in the
same spirit, should that become necessary in the future (it also seems
like the clean thing to do, even if we’re just talking about a single
file). The files are then made available at
//aux/_/, e.g.
/sid/aux/libva1_1.7.3-2/alternatives.tar.gz.

Looking forward to your feedback,

-- 
Best regards,
Michael
From db76ac889047d26d103caf2b3380417134964b67 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg 
Date: Wed, 11 Jan 2017 23:24:00 +0100
Subject: [PATCH] Export /var/lib/dpkg/alternatives tarball as aux file

---
 README_server.txt  | 11 +++
 piuparts-master-backend.py | 13 +
 piuparts-slave.py  | 20 +++-
 piuparts.py| 21 +
 4 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/README_server.txt b/README_server.txt
index 506d5149..f82450cb 100644
--- a/README_server.txt
+++ b/README_server.txt
@@ -242,6 +242,17 @@ Success: ok
 Slave informs master it cannot test the desired version of a
 package (perhaps it went away from the mirror?).
 
+
+Command: aux   
+  base64-encoded file contents
+ .
+Success: ok
+
+
+Slave transfers an auxiliary file (e.g. the /var/lib/dpkg/alternatives
+tarball) to the master.
+
+
 
 Command: status
 Success: ok = =...
diff --git a/piuparts-master-backend.py b/piuparts-master-backend.py
index 3e87c412..69b86786 100644
--- a/piuparts-master-backend.py
+++ b/piuparts-master-backend.py
@@ -32,6 +32,7 @@ import os
 import fcntl
 import time
 import random
+import base64
 from urllib2 import URLError
 
 import piupartslib
@@ -142,6 +143,7 @@ class Master(Protocol):
 "pass": self._pass,
 "fail": self._fail,
 "untestable": self._untestable,
+"aux": self._aux,
 
 # debug commands, unstable and undocumented interface
 "_state": self._state,
@@ -367,6 +369,17 @@ class Master(Protocol):
  % ("untestable", args[0], args[1]))
 self._short_response("ok")
 
+def _aux(self, command, args):
+self._check_args(3, command, args)
+encoded = self._read_long_part()
+decoded = base64.b64decode(encoded)
+destdir = os.path.join(self._section, "aux", args[0] + "_" + args[1])
+if not os.path.isdir(destdir):
+os.makedirs(destdir)
+with open(os.path.join(destdir, args[2]), "wb") as f:
+f.write(decoded)
+self._short_response("ok")
+
 # debug command
 def _state(self, command, args):
 self._check_args(1, command, args)
diff --git a/piuparts-slave.py b/piuparts-slave.py
index 9b147529..642ff30b 100644
--- a/piuparts-slave.py
+++ b/piuparts-slave.py
@@ -36,6 +36,7 @@ import fcntl
 import random
 import ConfigParser
 import apt_pkg
+import base64
 
 import piupartslib.conf
 import piupartslib.packagesdb
@@ -270,6 +271,20 @@ class Slave:
 if line != "ok\n":
 raise MasterNotOK()
 
+def send_aux(self, section, filename):
+logging.info("Sending aux data for %s/%s" % (section, filename))
+basename = os.path.basename(filename)
+package, rest = basename.split("_", 1)
+version = rest[:-len(".log")]
+for filename in os.listdir("aux"):
+self._writeline("aux", package, version, filename)
+with open(os.path.join("aux", filename), "r") as f:
+self._writeline(" " + base64.b64encode(f.self()))
+writeline._read(".")
+line = self._readline()
+if line != "ok\n":
+raise MasterNotOK()
+
 def get_status(self, section):
 self._writeline("status")
 line = self._readline()
@@ -576,6 +591,9 @@ class Section:
 self._slave.send_log(self._config.section, logdir, fullname)
 os.remove(fullname)
 
+if os.path.exists("aux"):
+self._slave.send_aux(self._config.section, fullname)
+
 if 

Bug#844086: lxc: On "sysv-init", fail to initialize cgroup since "cgmanager" support dropped.

[Thibaut Chèze]

Hi,

I reopen this because I have seen another side effect.
The LXC containers fail to start automatically during boot.

I attach a patch to fix this.
I haven't tested with "systemd" as "init", but I think it's not a
problem ("systemd" doesn't use /etc/init.d/lxc script, right ?).

Best regards,

--- /etc/init.d/lxc.orig	2017-01-11 11:47:00.0 +0100
+++ /etc/init.d/lxc	2017-01-11 11:48:00.0 +0100
@@ -7,8 +7,8 @@
 #
 ### BEGIN INIT INFO
 # Provides: lxc
-# Required-Start: $syslog $remote_fs
-# Required-Stop: $syslog $remote_fs
+# Required-Start: $syslog $remote_fs cgroupfs-mount
+# Required-Stop: $syslog $remote_fs cgroupfs-mount
 # Should-Start:
 # Should-Stop:
 # Default-Start: 2 3 4 5



signature.asc
Description: OpenPGP digital signature

Bug#850956: gosa-plugin-netgroups: fails to show the content of netgroup list entry (e.g. workstation-hosts)

[Wolfgang Schweer]

On Wed, Jan 11, 2017 at 08:53:57PM +, Mike Gabriel wrote:
> On  Mi 11 Jan 2017 16:47:51 CET, Wolfgang Schweer wrote:

[..]

> > while testing Debian Edu stretch another PHP7 issue (constructor name)
> > showed up.
> > 
> > Please note that for some reason replacing the function name with
> > '__constructor' doesn't work in this case.
> > 
> > This patch seems to fix it:
> > 
> > --- a/tabs_netgroup.inc 2017-01-11 16:20:32.203632303 +0100
> > +++ b/tabs_netgroup.inc 2017-01-11 16:13:58.399201779 +0100
> > @@ -23,7 +23,7 @@
> > 
> >  class netgrouptabs extends tabs {
> > 
> > -function netgrouptabs($config, $data, $dn, $cat = "", $hide_refs =
> > FALSE, $hide_acls = FALSE) {
> > +function __netgrouptabs($config, $data, $dn, $cat = "", $hide_refs
> > = FALSE, $hide_acls = FALSE) {
> >  tabs::__plugin($config, $data, $dn, "netgroups", $hide_refs,
> > $hide_acls);
> >  $this->addSpecialTabs();
> >  }

[..]

> Sorry, I doubt this, but are you sure about this?

While the above mentioned '__constructor' has been a typo this exact 
replacement actually works; but, '__construct' (like used elswhere in 
gosa to fix this PHP7 issue) does not. So yes, I'm pretty much sure.
 
> Can you second it with some official PHP7 porting document or such?

No, but I guess that '__construct' fails as class netgrouptabs extends 
tabs which already uses '__construct' - so anything different has to be 
used.

Wolfgang


signature.asc
Description: PGP signature

Bug#850799: italc: please make it multiarch ready

[Mike Gabriel]

On  Mi 11 Jan 2017 22:07:56 CET, Gianfranco Costamagna wrote:


Hello Mike,




For italc, multi-arch does not make sense, because libitalccore is not
a real shared library. The library gets dynamically linked in via an
RPATH and there is no point in make multi-arch installation possible.

So, why do you think italc should be multi-arch'ified?



because:


1) it does not harm, and seems more "clean" the installation directory
(FHS-wise)
2) the Ubuntu cmake is more picky about automatic multiarchify of packages,
and I would like to avoid an Ubuntu delta for italc.

I'm also thinking about removing that Ubuntu patch, but more multiarch
is better :)

what is your opinion?

G.


ACK. I will incorporate that patch with upcoming 3.0.3 release of iTALC.

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpkAiJ_T2Eh_.pgp
Description: Digitale PGP-Signatur

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts [and 2 more messages]

[Ian Jackson]

I see that I am Wrong On The Internet and my efforts not to distract
the TC have been futile.  Sorry.  Now I am falling subject to the same
problem but I really cannot let all of this go unchallenged.

Daniel Kahn Gillmor writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be 
hardcoded even in upstream parts"):
> On Wed 2017-01-11 12:13:44 -0500, Ian Jackson 
>  wrote:
> > I think this argument is utterly wrong in principle.  It is contrary
> > to the whole point of Debian.
> 
> We clearly disagree here, though i think Ian might be overstating his
> case for rhetorical effect.

Certainly not.  Our primary priority should be to make it easy for
users to make their own choices.  The argument being made here is that
it should be made harder for users to make certain modifications
because that produces confusing bug reports.  Outrageous!

If there were a significant risk of *users* being troubled by their
own old locally-built stuff in /usr/local, then that would be a good
argument.  (For example, this might be true in the case of a program
which has an unstable command line API which means that it is not
compatible with other versions of its callers.  But of course such a
thing probably wouldn't be on PATH at all.)


Sam Hartman writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be 
hardcoded even in upstream parts"):
> I'll note that the practice of hard-coding paths is fairly common.

It is a common bug.  There are many common bugs.  That does not stop
them being bugs.

Of course upstream projects often do this because they need their
software to be installable in nonstandard locations and still find all
of their pieces.  So such a thing is not necessarily a bug in an
upstream package.  But this is not necessary in Debian packages, and
then the restriction serves no purpose.

> One common cause for this is programs that don't want to rely on PATH
> for calling exec.  Systemd is a particularly interesting example.
> ExecStart and related arguments in systemd units are required to include
> full paths.

Do you really think that bringing utterly broken systemd behaviours
into this conversation would help ?  It's certainly raised my blood
pressure.


Didier 'OdyX' Raboud writes ("Re: Bug#850967: Clarify /usr/bin/foo should not 
be hardcoded even in upstream parts"):
> Dear Ian,
> >  * Say that this applies even when the program needs to find pieces of
> >the same (or closely related) package.
> 
> Reading this literally (which is what the Debian Policy is for),
> this would ask the Debian project to patch literally all its
> archive. For instance, that covers literally all shebang lines.

That shebang lines don't work this way is unfortunate but I'm not
suggesting it should be changed.

> I went and read #850657, and found myself agreeing with all points
> made by Daniel: if you want a gnupg that runs your custom gpg-agent
> for debugging purposes, building a patched src:gnupg is there for
> you; we provide source for a reason.

Have you ever talked some non-Debian person through the process of
building their own patched version of some program on their
Debian-derived system ?  This is not entirely straightforward, even if
they are an experienced software developer.  You will find yourself
making apologies (and also missing steps out, and making false
assumptions about the reasonableness of Debian source packages).

If you think this is so easy, I would welcome patches to this tutorial
manpage:
  
https://manpages.debian.org/cgi-bin/man.cgi?query=dgit-user=0=0=Debian+unstable+sid=html=en

Even though we can probably improve this (and we certainly should,
where we can), it's never going to be as easy as putting a wrapper
script on the path that invokes the subprogram with strace, or
whatever.

And it's complete overkill if what you wanted was to strace something
to see where it was going wrong (often you can't strace the parent for
some reason), or apply a ulimit, or pass a command line option that
the developers have for some reason decided shouldn't have a
corresponding config file option, or replace the program with a copy
of "true" or "false" to test the error handling, or whatever.

> All-in-all, I think that the decisions you would like the TC to
> issue would be against the project's consensus, and (which is more
> important for TC decisions) wouldn't be technically sound.

In many cases there is no way of ascertaining project consensus other
than a GR.  What you see in the mailing lists is the views of those
who are loud, stubborn and thick-skinned.  (FAOD a GR for this issue
would be ridiculous.)

But in this case, we can see fairly easily.  We have a large body of
software written specifically by Debian contributors to be part of
Debian.  We could see what that software does.

My experience is that in software writen specifically for Debian:
programs are almost universally launched from the PATH rather than by
absolute path; users are expected to put 

Bug#851028: composite: FTBFS: lrdf.h:8:20: fatal error: raptor.h: No such file or directory

[Jaromír Mikeš]

2017-01-11 19:55 GMT+01:00 Lucas Nussbaum :

>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
> >^~~
> > In file included from /<>/composite-0.006.
> 2+dfsg0/src/Tritium/src/fx/Effects.cpp:36:0:
> > /usr/include/lrdf.h:8:20: fatal error: raptor.h: No such file or
> directory
> >  #include 
> > ^
> > compilation terminated.
> > src/Tritium/CMakeFiles/Tritium.dir/build.make:1025: recipe for target
> 'src/Tritium/CMakeFiles/Tritium.dir/src/fx/Effects.o' failed
> > make[3]: *** [src/Tritium/CMakeFiles/Tritium.dir/src/fx/Effects.o]
> Error 1
>
> The full build log is available from:
>http://aws-logs.debian.net/2017/01/11/composite_0.006.2+
> dfsg0-6_unstable.log
>
> 
>

Hi Jonas,

isn't it this bug rather bug in ldrf and the line in /usr/include/lrdf.h
file should be:
#include 
as ldrf now B-D on libraptor2-dev?

best regards

mira

Bug#850113: vim-youcompleteme: 'KeyError's on every key press flooding vim

[luke]

Package: vim-youcompleteme
Version: 0+20160327+git1b76af4-2
Followup-For: Bug #850113

Dear Maintainer,

It looks like this error is actually coming from ycmd and the `KeyError`
is a side effect.

I've run wireshark and filtered for youcompleteme HTTP requests, and it
looks like the server is returning an error for all requests. (It's
possibly related to #849239)

Here is a relevant request and response from a wireshark capture of
localhost

```
GET /healthy HTTP/1.1
Host: 127.0.0.1:55763
User-Agent: python-requests/2.12.4
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
content-type: application/json
x-ycm-hmac: QeYZNi/+l9FJz3y2KX2cx7Kk7I6mSbLPqRpR2SBgHRU=

HTTP/1.1 500 INTERNAL SERVER ERROR
Content-Length: 58
Content-Type: text/html; charset=UTF-8
Date: Wed, 11 Jan 2017 22:15:50 GMT
Server: waitress

Critical error while processing request: /healthy

```

As you can see, the error response has no ycm-x-hmac header (probably as
a side effect of a crash in  ycmd (corresponding log from
`/tmp/ycm_temp/stderr_$PID.log`:

```
2017-01-11 22:20:07,522 - INFO - Received event notification
2017-01-11 22:20:07,523 - INFO - Received event notification
2017-01-11 22:20:07,524 - INFO - Adding buffer identifiers for file:
/home/luke/test.c
Critical error while processing request:
/event_notificationCritical error while processing request:
/event_notification2017-01-11 22:20:07,903 - INFO - Received health
request
Critical error while processing request: /healthy2017-01-11
22:20:07,911 - INFO - Received filetype completion available request
```

I remember seeing some recent updates to python-waitress, but I was
unable to check with an older version:

```
sudo apt-get install python-waitress=0.8.10-1
[sudo] password for luke:
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '0.8.10-1' for 'python-waitress' was not found
```

Happy to dig deeper if it will help

Best

Luke


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

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

Versions of packages vim-youcompleteme depends on:
ii  python3-future0.15.2-4
ii  python3-requests  2.12.4-1
ii  python3-requests-futures  0.9.7-1
pn  python3:any   
ii  vim-nox [vim-python]  2:8.0.0134-1
ii  ycmd  0+20160327+gitc3e6904-1+b1

Versions of packages vim-youcompleteme recommends:
ii  vim-addon-manager  0.5.6

vim-youcompleteme suggests no packages.

-- no debconf information

Bug#849401: restart silently fails

[Christian Hofstaedtler]

* Francesco Poli  [170111 22:51]:
> However, I glanced over the diff between
> apcupsd_3.14.14-0.2.debian.tar.xz and the proposed
> apcupsd_3.14.14-0.3.debian.tar.xz: the only thing that looks suspicious
> is that the apcupsd.service file seems to lack any check for the
> ISCONFIGURED variable in /etc/default/apcupsd (unlike apcupsd.init,
> which aborts whenever that variable is not set to "yes").
> 
> Is this intentional?
> I think that the check should be implemented somehow...

It's intentional for the test packages. I did not want to spend time
on implementing that if the proposed change doesn't work in the
first place.

Suggestions on the actual implementation also welcome ;-)
(TBH, if I did this package anew today, I'd probably just install
with the service disabled/masked and not do the ISCONFIGURED dance,
but it's not a new package and it's not my package...)

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

Bug#850986: keyboard focus stays in main window when opening compose window

[Carsten Schoenert]

forwarded 850986 https://bugzilla.mozilla.org/show_bug.cgi?id=942610
thanks

Thibaut,

On Wed, Jan 11, 2017 at 10:39:02PM +0100, Thibaut Paumard wrote:
 
> I won't fight about the severity as I said, it's up to the maintainer in
> my opinion. Yet I disagree with one of your points:

there is no need for fighting anything and I don't want ride on some
sublety. We just maintaining this piece of software very often we need
to explain reporters that their bug isn't grave in the terms of the
bugtracking system and in the view on the workflow how packages are
handled.

> Le 11/01/2017 à 21:37, Carsten Schoenert a écrit :
> > Well, loosing a email wouldn't I call data loss in the meaning of the
> > severities.
> 
> I would: a lot of my work e-mails are mission-critical.

Then I would need to rethink if my workflow is correct if I can loose
critical data due some flipping fingers.
Thunderbird has some easy to use possibilties to create a copy of
incomming email for example.

I know such argumentations from my day job. But people expecting mostly
to much from using email for real critical things. For the important
data there are other machanism needed like a ticket system. But anyay ...
no need to find a agreement on this. You reported a clearly issue.

> And for really deleting a email you would need to press
> > SHIFT + DEL. It's very unlikely that this is happen by full control in
> > case you will write up a new email.
> 
> Backspace and shift-e will also do it.

No, it won't if you use the default. Then you must have done some
special setup elsethere. Those shortcuts doing nothing here on my
Icedove.

https://support.mozilla.org/en-US/kb/keyboard-shortcuts

> Remember that this bug occurs for
> me dozens of time a day, so something that happens with a 1 per mille
> probability will happen to me about once a week... I often realize that
> I don't have focus only after I have typed several keys. Other users
> (see below) report that the main window can actually steal the focus
> while they are typing, not only when the window is first created.
> 
> I realize that we are in a freeze, that it may impact only few people
> and that it's not an easy bug (I actually wanted to try various versions
> of icedove/thunderbird and DEs, that's why I didn't report it earlier).

That's also a important information. It's significant for us to know
much as possible to readjusting the issue if possible. Without such
things it's worthless to search a problem.

> However I can assure you that is is an icedove/tunderbird bug that
> affects several people, whether they are running Windows or Debian:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=942610
> in particular
> https://bugzilla.mozilla.org/show_bug.cgi?id=942610#c3

That's the info that is needed.

> There are other similar bug reports, some old, some very recent. I have
> just tagged this bug "upstream" accordingly.

Ack.

> > If we would mark this issue grave or serious the bug report became
> > release critical, that means we need to fix such problems first.
> 
> Or have it tagged stretch-ignore, as you see fit.

This doesn't really help in detail here. As this bug is known a upstream
issue it's also affecting testing/stretch of course.

> > Otherwise no new version can go into testing.
> 
> I have filed the bug against the jessie version so that it does not
> appear like a new bug (it's actually a quite old one). So it should not
> prevent transitions, although it would trigger an autoremoval if not
> tagged stretch-ignore.

We will, or better we can probably doing nothing about solving this
issues. Best is trying to communicate with upstream about the problems
you have.

Regards
Carsten

Bug#851068: RFS: mathicgb/1.0~git20170104-1

[Doug Torrance]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mathicgb":

 * Package name: mathicgb
   Version : 1.0~git20170104
   Upstream Author : Bjarke Hammersholt Roune and Mike Stillman
 * URL : https://github.com/Macaulay2/mathicgb
 * License : GPL-2+
   Section : math/libs

  It builds those binary packages:

mathicgb - Compute Groebner bases (command line tool)
libmathicgb-dev - Compute Groebner bases (developer tools)
libmathicgb0 - Compute Groebner bases (runtime library)

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

  https://anonscm.debian.org/git/debian-science/packages/mathicgb.git

  Changes since the last upload:

mathicgb (1.0~git20170104-1) unstable; urgency=medium

  * New upstream release (git snapshot).
  * debian/control
- Bump to Standards-Version 3.9.8.
- Remove libmathicgb-dbg package in favor of new automatically
  generated *-dbgsym packages.
  * debian/mathicgb.install
- Move installation of manpage to dh_install.
  * debian/{mathicgb.manpages,mgb.1}
- Remove files; manpage added upstream.
  * debian/rules
- Add --dbgsym-migration option to dh_strip.
  * debian/tests/unittest
- Use upstream unit tests for continuous integration.

 -- Doug Torrance   Wed, 11 Jan 2017 16:46:27 -0500


  Regards,
  Doug Torrance

Bug#850891: Additional patch, to cover slurmdbd's duplicate code

[Karl Kornel]

Hi Rémi, (I hope the é comes through the email properly!)

If I would play devil’s advocate, then I would say this: “An action like this 
seems inappropriate to place into a package that does not clearly indicate why 
it is needed.  Instead, you should create a slurm-common package, and have the 
user creation happen there.”

I would be OK with that: I am fine putting together a patch to create a 
“slurm-common” package that does the user creation.  Some common documentation 
could also be moved to that package.  But, I did not know if that was 
appropriate, so I submitted the simpler change first!

~ Karl

On 1/11/17, 1:21 AM, "Rémi Palancher"  wrote:

FWIW, we took the same approach in our EDF-specific packages:

https://github.com/edf-hpc/slurm-llnl

It works fine for us so far!

I just don't remember why we didn't propose the patch back into Debian 
official packages though :(

Best,
Rémi

Bug#849401: restart silently fails

[Francesco Poli]

On Tue, 10 Jan 2017 23:49:43 +0100 Christian Hofstaedtler wrote:

> Hi,

Hello Christian!   :-)

First off, many thanks for stepping in.

I really appreciate that you're proposing a longer term solution than
what I was thinking about (I was planning to propose a little patch for
the apcupsd.init file, but writing a dedicated apcupsd.service file is
clearly cleaner and better).

> 
> * Daniel Pocock  [170106 11:06]:
> > > Is anyone able to reproduce the issue on current Debian testing?
> > > 
> > 
> > How long does it take for your apcupsd daemon to shutdown?
> > 
> > My UPS uses SNMP signalling, I wonder if that makes the daemon shut
> > down more slowly.
> 
> Likely.
> 
> I can't test this (my UPS is broken and it'd be a serial one
> anyway), but here are some test packages with a systemd service
> file:
> 
> https://people.debian.org/~zeha/apcupsd/
> 
> Please report back if those work for you and if the restart issue
> is fixed.

I haven't had a chance to actually test the package, but, as far as
tests are concerned, let's primarily wait for Daniel's feedback (that
will hopefully arrive real soon now!).

However, I glanced over the diff between
apcupsd_3.14.14-0.2.debian.tar.xz and the proposed
apcupsd_3.14.14-0.3.debian.tar.xz: the only thing that looks suspicious
is that the apcupsd.service file seems to lack any check for the
ISCONFIGURED variable in /etc/default/apcupsd (unlike apcupsd.init,
which aborts whenever that variable is not set to "yes").

Is this intentional?
I think that the check should be implemented somehow...

Please let me know.
Thanks a lot for your time!


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


pgp3PiWHryNrL.pgp
Description: PGP signature

Bug#849530: Rancid: clogin fails on fortigate devices with read-only users

[Roland Rosenfeld]

Hi Héctor!

On Wed, 28 Dec 2016, Héctor Sánchez wrote:

> Many thanks for the advise!, I'll try fnlogin then.

Did this solve your issue, so we can close this bug report now?

Greetings
Roland

> > > Package:rancid
> > > Version:2.3.8-6
> >
> > > Clogin fails to connect to our fortigate devices (300D & 600D) using
> > > read-only users, no issue using admin ones (except having to force an
> > > specific cypher for newer fortigate firmware):
> >
> > Please try using fnlogin for Fortigate devices instead of clogin.
> > This should work around your problems, since it is optimized for
> > Fortigate.
> >
> > > root@rancid[PRO]:~# diff /usr/bin/clogin{,_bk}
> > >
> > > 788c788
> > >
> > > < set prompt "(\\$|>|#| \\(enable\\))"
> > >
> > > ---
> > >
> > > > set prompt "(>|#| \\(enable\\))"
> >
> > That's why you should use fnlogin:
> >
> > # FortiOS 2.x prompts can end in either '#' or '$'
> > set prompt "\[#\\$] "

Bug#851067: linux-image-4.8.0-0.bpo.2-amd64: X display corruptions with kernels 4.4 - 4.8 (Broadwell Intel graphics, Intel driver)

[Wirawan Purwanto]

Package: src:linux
Version: 4.8.11-1~bpo8+1
Severity: important

Dear Maintainer,


Screen corruption was randomly (but consistently) observed on several
programs: LibreOffice 5, xpdf, iSilo under wine.
I do not know which precise piece of the software stack is causing this
error, but I want to start from the kernel-level driver, since I noticed
the problem for the first time when I upgraded my kernel version
from 4.3 to 4.6.
The problem was observed also on the newer kernel releases (4.7, 4.8).
And I tested today, and found that some of the problems also appeared
using the old kernel 4.3.

This is a problem that I began to observe since July 2016, when I upgraded
the backport kernel in my computer to version 4.6 onward, and the
xserver-xorg-video-intel driver to version 2.99.917+git20160522-1~bpo8+1 .

Some of these problems happen consistently; the others happen somewhat
intermittently, but frequently enough to be annoying.

This problem happens on the following hardware platform:

* Lenovo Thinkpad T450s

* CPU: Intel i5-5200U (Broadwell)

* OS: Debian 8 (Jessie) 64-bit

* Kernel versions affected: 4.3, 4.6, 4.7, 4.8  as provided by
  "jessie-backports" repository

* Xorg driver: intel with "sna" acceleration.
  I used the newest Intel driver software provided by jessie-backports,
  since the official release (kernel 3.16) have a lot of issues with
  Broadwell hardware.

* Kernel command line: (UUID erased)
 BOOT_IMAGE=/boot/vmlinuz-4.3.0-0.bpo.1-amd64 root=UUID=xxx ro 
intel_iommu=igfx_off



Additional comments:

* This corruption was observed on both the physical screen, as well as
  the virtual screen when viewed via x11vnc.

* I tried "modesetting" X11 DDX to replace the "intel" driver.
  It came with its own set of problems, see
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835123

I am a long-time user of Linux/GNU systems, but I am not a Linux kernel
expert. If you need me to gather some information from my running system,
I should be able to help.



Here are some account of the real cases:


LibreOffice 5 (concretely: 5.2; other versions could be affected too)
-

I noticed the following actions were conducive to triggering the bug:

1) editing a spreadsheet cell that already has a content
2) editing text document
3) page up/page down in a text document
4) pasting a moderate length of a paragraph onto a text document (say,
the length of the paragraph is about half a screen's height)

Here is an example of a consistent problem.
Easy step to reproduce bug in the worksheet in LibreOffice 5.2:

* Open this sample document: "Video-training-sheet.ods"
* Go to the cell B29 with content:
  "Lord's table on 1/15 and 1/22 will begin at 9:30am"
* Press F2
* Move the cursor to somewhere in the middle, say to the beginning of the
  word "will"
* insert some text -- then the text to the right of the cursor will be
  corrupted because of overwriting of old pixels with new pixels without
  erasing the old ones.

I did several tests with other version of LibreOffice, as well as a
different host. Here is the summary table:

Hostname Host OS metal?   software   Corruption?
compsci-wp   Linux 3.16  docker   LO-5.2.4 official buildNo
wirawan2 Linux 4.3   docker   LO-5.2.4 official buildYes
wirawan2 Linux 4.3   docker   LO-4.3.3 debian official   No
wirawan2 Linux 4.7   direct   LO-5.2.4 debian backports  Yes

"Corruption" refers to whether the screen corruption occured when I edited
the sample document "Video-training-sheet.ods" above.



Xpdf


Please view the enclosed file, "sunway-report-2016.pdf", which
can be downloaded from: 
http://www.netlib.org/utk/people/JackDongarra/PAPERS/sunway-report-2016.pdf
(md5:f8bf0f6f7859987714d1df66de016e6c).

On page 8, as the picture was being composed, the top left corner of
the document blinks with with "animating" images until that picture is
fully composed.
This problem occurs with Kernel backport version 4.3 and 4.8.

The following problem (the picture shown as xpdf-screen-5.png) seems to
only occur on newer kernels (4.6, 4.7, 4.8):
When one nagivates with Page-Up and Page-Down keys, at some (seemingly)
random moments, the displayed picture was corrupt.
See that attached picture file.



iSilo under Wine


This is a more complex setup. It is a 32-bit wine running under Docker
container (with 32-bit Ubuntu-14 base image), which is used to run
Windows version of "iSilo" software (a electronic document reader).
Other than the iSilo itself, I used software provided by Ubuntu
14.04.3 repository.

Often the document is drawn with corruption, see file isilo-screen-1.png .


(Attachments will be included in a subsequent email.)



In summary: I think this is an important problem to address, as I have
been having a lot of pains with graphics issues on this Intel Broadwell

Bug#743824: digikam: Digikam no longer displays any album thumbnails

[Simon Frei]

Hi Ryan,

Thanks for the heads up regarding the frankly weird mailing distribution.

Are any of the images grouped or were edited with the digikam editor
(i.e. versioning is used)?
When you say missing, it's just the actual thumbnail missing, meaning
file infos are there, but just some kind of empty frame or is there no
trace at all of those images?

Cheers,
Simon



signature.asc
Description: OpenPGP digital signature

Bug#850993: osmosis: FTBFS: PGHStore.java:36: error: package org.postgresql.util does not exist

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 01/11/2017 09:20 PM, Sebastiaan Couwenberg wrote:
> The recent update of libpgjava to 9.4.1212-1 is the cause, it removed
> the PGObject class. I've asked on debian-java if Emmanuel can provide a
> patch to make osmosis work with the libpgjava.

The PGObject class wasn't actually removed, the groupId just changed as
pointed out by Emmanuel on the debian-java list.

> Help from others is greatly appreciated too.

The package has been fixed, no further help is required.

Kind Regards,

Bas

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

Bug#850986: keyboard focus stays in main window when opening compose window

[Thibaut Paumard]

Control: tag -1 upstream

Dear Carsten,

I won't fight about the severity as I said, it's up to the maintainer in
my opinion. Yet I disagree with one of your points:

Le 11/01/2017 à 21:37, Carsten Schoenert a écrit :
> Well, loosing a email wouldn't I call data loss in the meaning of the
> severities.

I would: a lot of my work e-mails are mission-critical.

And for really deleting a email you would need to press
> SHIFT + DEL. It's very unlikely that this is happen by full control in
> case you will write up a new email.

Backspace and shift-e will also do it. Remember that this bug occurs for
me dozens of time a day, so something that happens with a 1 per mille
probability will happen to me about once a week... I often realize that
I don't have focus only after I have typed several keys. Other users
(see below) report that the main window can actually steal the focus
while they are typing, not only when the window is first created.

I realize that we are in a freeze, that it may impact only few people
and that it's not an easy bug (I actually wanted to try various versions
of icedove/thunderbird and DEs, that's why I didn't report it earlier).

However I can assure you that is is an icedove/tunderbird bug that
affects several people, whether they are running Windows or Debian:

https://bugzilla.mozilla.org/show_bug.cgi?id=942610
in particular
https://bugzilla.mozilla.org/show_bug.cgi?id=942610#c3

There are other similar bug reports, some old, some very recent. I have
just tagged this bug "upstream" accordingly.

> If we would mark this issue grave or serious the bug report became
> release critical, that means we need to fix such problems first.

Or have it tagged stretch-ignore, as you see fit.

> Otherwise no new version can go into testing.

I have filed the bug against the jessie version so that it does not
appear like a new bug (it's actually a quite old one). So it should not
prevent transitions, although it would trigger an autoremoval if not
tagged stretch-ignore.

Regards, Thibaut.

Bug#851066: flashplugin-nonfree: Mismatch between detected and available versions (Download file not available at people.debian.org)

[Peter Denison]

Package: flashplugin-nonfree
Version: 1:3.7
Severity: important

Dear Maintainer,
Now Adobe has once again started releasing updates to the Linux version 
of the flash plugin, the updater recognises the version number of the latest 
version, but it is not yet available at people.debian.org.
In addition, the documentation states that the player will be downloaded from 
www.adobe.com, where it is clearly going there for the version information, but 
to poeple.debian.org for the actual file.

   * What led up to the situation?

Running 'update-flashplugin-nonfree --install'

   * What was the outcome of this action?

# update-flashplugin-nonfree --install
ERROR: wget failed to download 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.24.0.0.194.sha512.amd64.pgp.asc
More information might be available at:
  http://wiki.debian.org/FlashPlayer

   * What outcome did you expect instead?

A proper update of the flash installer


-- Package-specific info:
Debian version: stretch/sid
Architecture: amd64
Package version: 1:3.7
Adobe Flash Player version: LNX 11,2,202,632
MD5 checksums:
29c85bc8504422120cf89702986ff8e1  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
ace1a0801f00a25fd90172f63e98e101  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz
e3a1280f91b278b8832500f362d0546b  
/usr/lib/flashplugin-nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
  link best version is /usr/lib/flashplugin-nonfree/libflashplayer.so
  link currently points to 
/usr/lib/flashplugin-nonfree/libflashplayer.so
  link flash-mozilla.so is /usr/lib/mozilla/plugins/flash-mozilla.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
/usr/lib/gnash/libgnashplugin.so - priority 10
/usr/lib/lightspark/liblightsparkplugin.so - priority 0
lrwxrwxrwx 1 root root 34 Jul 22  2014 
/usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to 
/etc/alternatives/flash-mozilla.so

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

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

Versions of packages flashplugin-nonfree depends on:
ii  binutils   2.27.51.20161220-1
ii  ca-certificates20161130
ii  debconf [debconf-2.0]  1.5.59
ii  gnupg  2.1.17-2
ii  gnupg2 2.1.17-2
ii  libatk1.0-02.22.0-1
ii  libcairo2  1.14.8-1
ii  libcurl3-gnutls7.51.0-1
ii  libfontconfig1 2.11.0-6.7
ii  libfreetype6   2.6.3-3+b1
ii  libgcc11:6.2.1-5
ii  libglib2.0-0   2.50.2-2
ii  libgtk2.0-02.24.31-1
ii  libnspr4   2:4.12-6
ii  libnss32:3.26.2-1
ii  libpango1.0-0  1.40.3-3
ii  libstdc++6 6.2.1-5
ii  libx11-6   2:1.6.4-2
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.5-1
ii  wget   1.18-4

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
ii  firefox-esr45.6.0esr-1
ii  fonts-dejavu   2.37-1
pn  hal-flash  
ii  iceweasel  45.6.0esr-1
pn  konqueror-nsplugins
pn  ttf-mscorefonts-installer  
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#851065: bind9: CVE-2016-9131: A malformed response to an ANY query can cause an assertion failure during recursion

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.9.5.dfsg-4
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

the following vulnerability was published for bind9.

CVE-2016-9131[0]:
|A malformed response to an ANY query can cause an assertion failure
|during recursion

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9131
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9131
[1] https://kb.isc.org/article/AA-01439/0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#851064: RFA: mcu8051ide -- Graphical Integrated Development Environment for 8051

[Fabricio Alcalde]

Package: wnpp
Severity: normal

I request an adopter for the mcu8051ide package. I'm not interested in 
maintaining it anymore.

The package description is:
 MCU 8051 IDE is an integrated development environment for
microcontrollers
 based on 8051. Supported programming languages are C and assembly. It
has
 its own assembler and it supports two other external assemblers. For C
 language it uses the SDCC compiler.

Bug#851063: bind9: CVE-2016-9147: An error handling a query response containing inconsistent DNSSEC information could cause an assertion failure

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.9.5.dfsg-4
Severity: grave
Tags: upstream security
Justification: user security hole

Hi,

the following vulnerability was published for bind9.

CVE-2016-9147[0]:
|An error handling a query response containing inconsistent DNSSEC
|information could cause an assertion failure

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9147
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9147
[1] https://kb.isc.org/article/AA-01440/0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#851062: bind9: CVE-2016-9444: An unusually-formed DS record response could cause an assertion failure

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.9.5.dfsg-4
Severity: grave
Tags: upstream security
Justification: user security hole

Hi,

the following vulnerability was published for bind9.

CVE-2016-9444[0]:
|An unusually-formed DS record response could cause an assertion
|failure

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9444
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9444
[1] https://kb.isc.org/article/AA-01441/0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#851061: Collections don't work at all, do they?

[Richard B. Kreckel]

Package: gnome-documents
Version: 3.22.0-1

I've reproduced this on three accounts on two computers running
Debian/testing:

I successfully followed the help to create a collection of some related
documents.

Now, if I click on the Collections button on the top, I see the
collection, with its name and an icon built from thumbnails of four of
the documents I placed into the collection. But then, what?
- Nothing happens when I click on the collection item.
- I can select the collection with the ✓ button, but nothing more: at
the bottom, buttons for Open, share, print, delete, Collections, and
Properties appear, but they are all disabled.
- The collection does not appear in the Documents view.
- The collection does not seem to appear elsewhere.
To summarize: It seems to be as useless as teats on a boar.  :-/

While there's a help page explaining how to create collections it is
silent about what to do with it.

If there is some use, then it should be documented, so people can find out.
-- 
Richard B. Kreckel

Bug#741422: git-buildpackage: breaks bash tab completion for filenames in git checkouts

[Edward Betts]

Hi Guido,

This isn't happening any more, I can't reproduce it. You can close this bug.

Thanks,
-- 
Edward.

Bug#851060: libnids1.21: can't assemble TCP streams on armhf

[guenther]

Package: libnids1.21
Version: 1.23-2
Control: affects -1 + dsniff

At least on armhf (on both Debian Unstable as well as on Raspbian
Jessie), libnids1.21 can't assemble TCP streams correctly. This
affects software relying on libnids, such as dsniff.

Compiling the library myself, I could reproduce that gcc's strict
aliasing assumptions don't hold for this code.  Turning off
optimizations relying on strict aliasing fixed the issue for me.  The
compiler flag is -fno-strict-aliasing.

My proposal would be to add this flag, as the library itself is mostly
unmaintained.

Steps to reproduce:
- Run dsniff (which is based on libnids; package maintainers Cc'ed)
- curl -v --basic --user foo:bar http://neverssl.com/

Expected results:
- dsniff should report the observed credentials

Observed results:
- dsniff returns nothing


signature.asc
Description: PGP signature