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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#850819: unblock: heat/1:7.0.0-2

[Andreas Beckmann]

On Tue, 10 Jan 2017 16:42:00 + Niels Thykier  wrote:
> Thomas Goirand:
> > unblock heat/1:7.0.0-2

> Already aged to 5 days.

That will also need a

ignore-piuparts heat/1:7.0.0-2

thanks to python-sqlalchemy making python-heat uninstallable in sid ...
https://piuparts.debian.org/sid/source/h/heat.html


Andreas

Bug#846779: xserver-xorg-core: chrome freezes with xorg-server 1.19.0

[Andreas Boll]

Hi,

could you try this patch [1]?

Thanks,
Andreas

[1] https://patchwork.freedesktop.org/patch/132089/

On Mon, Dec 12, 2016 at 03:28:33PM +0900, Michel Dänzer wrote:
> On 12/12/16 05:39 AM, Frédéric Brière wrote:
> > On Sat, Dec 10, 2016 at 10:07:51PM -0500, Frédéric Brière wrote:
> >> Otherwise, I guess I'll have to muster up the courage to try to bisect
> >> this.  (gulp!)
> > 
> > It wasn't exactly a nice leisurely stroll through the park, but I did
> > manage to bisect and pinpoint f993091 as the guilty commit.
> 
> Thanks for that!
> 
> 
> > At this point, I guess there's not much left to do, apart from filing a
> > bug upstream?  (Oh, great, Bugzilla.  )
> 
> Yeah, that's the logical next step.
> 
> 
> -- 
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer


signature.asc
Description: Digital signature

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

[Vincent Lefevre]

Control: clone -1 -2
Control: reassign -2 systemd 232-8
Control: retitle -2 systemd: power off without always a normal shutdown when 
resuming after suspend with the power button
Control: severity -2 grave

as the lack of shutdown yields visible file corruption and potentially
data loss.

On 2017-01-11 16:20:35 +0100, Vincent Lefevre wrote:
> On 2017-01-11 15:09:49 +, Ben Hutchings wrote:
> > Unless you can show that some data had been written *and flushed* to
> > disk by the application, but was not readable afterward - this does not
> > count.  Writes are buffered, and user space has to deal with that.
> 
> If I understand the journalctl log correctly, the system does
> a power off without a clean shutdown:
> 
> [...]
> Dec 23 10:51:01 zira systemd-logind[803]: Powering Off...
> Dec 23 10:51:01 zira systemd-logind[803]: System is powering down.
> Dec 23 10:51:01 zira systemd[1]: Stopping Manage, Install and Generate Color 
> Pro
> 
> then nothing after that!!! This is where the problem is, not in the
> application, which cannot know when the machine will power off.

Well, there are two problems:

1. The fact that the system powers down instead of just resuming.
   systemd-logind reports "Power key pressed." but the power key
   was used to resume, so that I suppose that systemd-logind
   should have never seen this.

2. The fact that the system is powered off immediately without a
   clean shutdown. When I use the power button to power off the
   laptop, I get:

Sep 17 19:36:13 zira systemd-logind[17281]: Power key pressed.
Sep 17 19:36:13 zira systemd-logind[17281]: Powering Off...
Sep 17 19:36:13 zira systemd-logind[17281]: System is powering down.
Sep 17 19:36:13 zira systemd[1]: Stopped target Bluetooth.
Sep 17 19:36:13 zira systemd[1]: Stopping Session 2041 of user vinc17.
Sep 17 19:36:13 zira systemd[1]: Deactivating swap /dev/disk/by-id/dm-uuid-LVM-K
Sep 17 19:36:13 zira systemd[1]: Stopping Disk Manager...
[...]

i.e. a normal shutdown, but when this is used just after a suspend
in order to resume, I *occasionally* get (well, this occurred only
twice):

Jul 25 17:15:17 zira systemd-logind[769]: Power key pressed.
Jul 25 17:15:17 zira systemd-logind[769]: Powering Off...
Jul 25 17:15:17 zira systemd-logind[769]: System is powering down.
-- Reboot --

Dec 23 10:51:01 zira systemd-logind[803]: Power key pressed.
Dec 23 10:51:01 zira systemd-logind[803]: Powering Off...
Dec 23 10:51:01 zira systemd-logind[803]: System is powering down.
Dec 23 10:51:01 zira systemd[1]: Stopping Manage, Install and Generate Color Pro
-- Reboot --

No normal shutdown!

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

Bug#850958: terminix: FTBFS on ppc64el: segmentation fault

[Emilio Pozuelo Monfort]

Source: terminix
Version: 1.4.0-1
Severity: serious

Your package failed to build on ppc64el, preventing testing migration:

make[3]: Entering directory '/«PKGBUILDDIR»'
ldmd2 -O -inline -release -g -version=StdLoggerDisableTrace 
-I/usr/include/d/gtkd-3/ -L-lvted-3 -L-L/usr/lib/powerpc64le-linux-gnu/ 
-L-lgtkd-3 -L-ldl -c source/app.d source/gx/gtk/actions.d source/gx/gtk/cairo.d 
source/gx/gtk/clipboard.d source/gx/gtk/dialog.d source/gx/gtk/resource.d 
source/gx/gtk/settings.d source/gx/gtk/threads.d source/gx/gtk/util.d 
source/gx/gtk/vte.d source/gx/gtk/x11.d source/gx/i18n/l10n.d 
source/gx/terminix/application.d source/gx/terminix/appwindow.d 
source/gx/terminix/closedialog.d source/gx/terminix/cmdparams.d 
source/gx/terminix/colorschemes.d source/gx/terminix/common.d 
source/gx/terminix/constants.d source/gx/terminix/encoding.d 
source/gx/terminix/prefdialog.d source/gx/terminix/preferences.d 
source/gx/terminix/profileeditor.d source/gx/terminix/session.d 
source/gx/terminix/sessionswitcher.d source/gx/terminix/shortcuts.d 
source/gx/terminix/sidebar.d source/gx/terminix/terminal/actions.d 
source/gx/terminix/terminal/advpaste.d source/gx/terminix/terminal/exvte.d 
source/gx/terminix/terminal/layout.d source/gx/terminix/terminal/password.d 
source/gx/terminix/terminal/search.d source/gx/terminix/terminal/terminal.d 
source/gx/util/array.d source/gx/util/string.d source/secret/Collection.d 
source/secret/Item.d source/secret/Prompt.d source/secret/Schema.d 
source/secret/SchemaAttribute.d source/secret/Secret.d source/secret/Service.d 
source/secret/Value.d source/secretc/secret.d source/secretc/secrettypes.d 
source/x11/X.d source/x11/Xlib.d -ofterminix.o
Makefile:1034: recipe for target 'terminix.o' failed
make[3]: *** [terminix.o] Segmentation fault

Full logs at:

https://buildd.debian.org/status/package.php?p=terminix=sid

Emilio

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

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)

Bug#850657: [pkg-gnupg-maint] Bug#850657: gnupg: Please find gpg-agent on PATH

[Daniel Kahn Gillmor]

Hi Ian--

On Wed 2017-01-11 06:56:19 -0500, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#850657: gnupg: Please 
> find gpg-agent on PATH"):
>> On Sun 2017-01-08 17:35:13 -0500, Ian Jackson wrote:
>> > gpg executes /usr/bin/gpg-agent, rather than fetching it from the
>> > PATH.
>> >
>> > This is contrary to Debian policy.
>> 
>> Can you point to the specific part of debian policy that this violates?
>
> I looked for the appropriate part.  debian-policy fails to specify
> many aspects of behaviour of programs other than maintainer scripts,
> but about maintainer scripts it has this to say:
>
> | Programs called from maintainer scripts should not normally have a
> | path prepended to them.
> (policy 6.1)

This is clearly not relevant, since we're not talking about maintainer
scripts.  Why cite Policy if this isn't actually a request related to
Policy?

>> If you want to pass exciting options to gpg-agent, you can pass them
>> directly by launching the agent by hand.  there aren't many contortions
>> involved, afaict.  Can you explain what you're trying to do?
>
> I don't think it is fruitful in this bug report to speculate about
> other ways of achieving my objective at the time I noticed the bug.
> (I disagree that this is a wishlist request.  Absolute paths are a
> bug.)

It is certainly fruitful to try to find other means to an end; but
reports of "i want to do Y, but i can't do X, which i see as a necessary
precondition" can be legitimately answered with "If you want Y, do Z".
I'm pretty sure you know this, and have probably helped many people
solve their problems with this kind of alternate solution proposal in
the past.

I'm not convinced that absolute paths are a bug full stop. There are
certainly circumstances where they're a bug, but it's not all of them.
Let's be sensible about invoking absolute rules.

> Putting a stunt wrapper of a program on PATH is a well-established
> technique for debugging, and for users interfering with and modifying
> the behaviour of their systems, and for thingse like test suites.
>
> Of course the system administrator can move the program aside (perhaps
> also using dpkg-divert), but that has global effect on the whole
> system, while setting PATH has only local impact and requires no
> privilege.

Again, there are lots of other ways to achieve local debugging tools
that do not involve the kind of divergence from upstream that you're
proposing here.

>> > Please change the package to execute all its programs from PATH.
>> 
>> this almost certainly won't be done.  for example, if a smarcard is
>> present, scdaemon is currently invoked from /usr/lib/gnupg/scdaemon ,
>> which isn't even in the path.
>
> Sorry, I was unclear.  I meant to limit my request to those programs
> which are already on PATH directories, like gpg-agent.

If you're OK with full paths for an auto-launched scdaemon built from
the same source package, why are you not ok with full paths for an
auto-launched gpg-agent built from the same source package?  What if i
shipped gpg-agent in /usr/lib/gnupg/, and included a symlink to it in
/usr/bin -- would it be ok then for gpg to invoke gpg-agent from
/usr/lib/gnupg/ ?  (for clarity: i'm not going to do this, because i'm
uninterested in diverging from upstream on this point; this is a thought
experiment to ask why one situation might be OK and another is not)

>> > Ideally upstream would change too but my experience is that upstreams
>> > often don't like this kind of change.
>> 
>> indeed, they don't like changes that make it more difficult to track
>> down problems, [...]
>
> I don't want to have this argument with upstream.  IMO this is just
> how we do things in Debian.

sorry, Ian, but it's clearly *not* "just how we do things in debian".
There are lots of things in debian that embed full paths.  For one
simple example, /usr/bin/pager is listed in 10 programs on my running
system:

0 dkg@alice:~$ find /bin /usr/bin -type f -print0 | xargs -0 grep -l 
/usr/bin/pager
/usr/bin/sort-dctrl
/usr/bin/tbl-dctrl
/usr/bin/join-dctrl
/usr/bin/elinks
/usr/bin/grep-dctrl
/usr/bin/wdiff
/usr/bin/ucf
/usr/bin/units
/usr/bin/smbclient
/usr/bin/update-alternatives
0 dkg@alice:~$ 

For a closer analogy with what GnuPG is doing, you'll see that
/usr/bin/ssh-askpass is embedded in ssh-agent, ssh-keygen, ssh, and
ssh-add binaries.  This is true in jessie, and in stretch/sid.  I
haven't checked older versions, but i'd bet a tasty sandwich that it's
been true since the dawn of OpenSSH (or at least since the idea of
ssh-askpass):

0 dkg@alice:~$ strings /usr/bin/ssh-add | grep ssh-askpass
/usr/bin/ssh-askpass
0 dkg@alice:~$ 

Note that i'm not saying that we *should* use embedded paths everywhere,
just that there are legitimate use cases where that's the right thing to
do, and we don't avoid them out of vague notions of "that's not how we
do things in debian".

> In Debian we have reportbug, which is the right place to address the
> kind of bug 

Bug#850855: [rtkit] rtkit daemon fails to start

[Bogdan Vatra]

On miercuri, 11 ianuarie 2017 12:40:23 EET Felipe Sateler wrote:
> On 11 January 2017 at 12:37, Bogdan Vatra  wrote:
> > On miercuri, 11 ianuarie 2017 10:12:00 EET Felipe Sateler wrote:
> >> Control: tags -1 moreinfo unreproducible
> >> 
> >> On 11 January 2017 at 04:59, Bogdan Vatra  wrote:
> >> > On miercuri, 11 ianuarie 2017 09:48:16 EET Bogdan Vatra wrote:
> >> >> On marți, 10 ianuarie 2017 17:20:28 EET Felipe Sateler wrote:
> >> >> > Hi,
> >> >> > 
> >> >> > On 10 January 2017 at 16:05, Bogdan Vatra 
> > 
> > wrote:
> >> >> > > Package: rtkit
> >> >> > > Version: 0.11-4
> >> >> > > Severity: important
> >> >> > > 
> >> >> > > --- Please enter the report below this line. ---
> >> >> > > 
> >> >> > > This bug is pretty annoying because it makes pulseaudio unusable
> >> >> > > (see
> >> >> > > #850806).
> >> >> > 
> >> >> > > Here are the logs:
> >> >> > 
> >> >> > 
> >> >> > > -- Unit rtkit-daemon.service has begun starting up.
> >> >> > > ian 10 21:00:32 zmeu rtkit-daemon[19342]: Failed to connect to
> >> >> > > system
> >> >> > > bus:
> >> >> > > Failed to connect to socket /var/run/dbus/system_bus_socket: No su
> >> >> > 
> >> >> > This suggests that dbus is not running. Could that be the case? Do
> >> >> > other dbus-interacting apps misbehave?
> >> >> 
> >> >> I think that's a wrong message ... because :
> >> >> 
> >> >> $ ls -l /var/run/dbus/system_bus_socket
> >> >> srw-rw-rw- 1 root root 0 ian 10 09:42 /var/run/dbus/system_bus_socket
> >> >> 
> >> >> That file exists and dbus works fine (all my KDE/Qt apps works ok).
> >> > 
> >> > If I manually run "/usr/lib/rtkit/rtkit-daemon" it works just fine...
> >> > The only problem is when I start it with "systemctl start rtkit-
> >> > daemon.service".
> >> 
> >> Weird. Could you repeat the same with the daemon as started by systemd?
> >> 
> >> Use `systemctl edit --full rtkit-daemon` to edit the ExecStart line.
> > 
> > It is the same thing ... :
> > [...]
> > ExecStart=/usr/lib/rtkit/rtkit-daemon
> > [...]
> > Actually I was inspired from that file to exec
> > "/usr/lib/rtkit/rtkit-daemon" manually :).
> 
> Sorry, I was not clear. I meant stracing the daemon.

Attached the log.

$ sudo strace /usr/lib/rtkit/rtkit-daemon
[sudo] password for bogdan: 
execve("/usr/lib/rtkit/rtkit-daemon", ["/usr/lib/rtkit/rtkit-daemon"], [/* 18 vars */]) = 0
brk(NULL)   = 0x1cc3000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f156c6be000
access("/etc/ld.so.preload", R_OK)  = 0
open("/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)= 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=245391, ...}) = 0
mmap(NULL, 245391, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f156c682000
close(3)= 0  
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)  
open("/lib/x86_64-linux-gnu/libdbus-1.so.3", O_RDONLY|O_CLOEXEC) = 3 
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\323\0\0\0\0\0\0"..., 832) = 832  
fstat(3, {st_mode=S_IFREG|0644, st_size=321680, ...}) = 0
mmap(NULL, 2417328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f156c25   
mprotect(0x7f156c29d000, 2093056, PROT_NONE) = 0 
mmap(0x7f156c49c000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4c000) = 0x7f156c49c000  
close(3)= 0  
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)  
open("/lib/x86_64-linux-gnu/libcap.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\30\0\0\0\0\0\0"..., 832) = 832   
fstat(3, {st_mode=S_IFREG|0644, st_size=22768, ...}) = 0 
mmap(NULL, 2117976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 

Bug#850945: ant: exec task fails with error 127 on kfreebsd-i386

[Emmanuel Bourg]

Hi Gilles,

Le 11/01/2017 à 14:54, Gilles Filippini a écrit :

> Moreover, ant reports BUILD SUCCESSFUL while it is obviously unsuccessful.

The  task doesn't fail the build by default when an error occurs.
The failonerror="true" attribute has to be specified.


> BTW I don't understand why kfreebsd-i386/unstable still has ant 1.9.6-1 :/

Good question. ant/1.9.8 failed to build on kfreebsd-i386, the 
task is called during the build and fails, probably for the same reason
 fails with jxgrabkey (the  task extends ).

Emmanuel Bourg

Bug#773057: Dependency problem

[Bruce Weirdan]

Control: reopen -1 =

There's a dependency problem that renders the fix unusable:
terminology 0.9.1-1 depends on libeina1 >=1.8.0 (available 1.8.6-2.5+b1)
libemotion-players 1.18.4-1 depends on libeina1a >=1.18.4-1 (available
1.18.4-1) which conflicts with libeina1

Bug#850949: icedove does not sync google calendars, claiming item.recurrenceInfo is null

[Boyan Penkov]

Package: icedove
Version: 1:45.5.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I have icedove and the google calendar provider installed.  I have three
calendars: a work one tied to a work google account, and a personal and one
shared with my partner tied to my personal gmail.

Both the work one and the partner one sync fine, my personal one (which is
the oldest, and contains the most events), failes to update with the
following error (pulled off the icedove error console):

Timestamp: 01/06/2017 09:18:47 PM
Error: [calCachedCalendar] replay action failed: null, uri=googleapi://
boyan.pen...@gmail.com/?calendar=boyan.penkov%40gmail.com,
result=item.recurrenceInfo is null, op=[xpconnect wrapped calIOperation]
Source File: file:///usr/lib/icedove/extensions/%7Be2fda1a4-762b-4020-
b5ad-a41df1933103%7D/calendar-js/calCachedCalendar.js
Line: 327

I have tried using both debian's "calendar-google-provider" package and the
addon installed through the icedove extensions menu, and the effect is the
same with both.

Cheers!

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

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

Versions of packages icedove depends on:
ii  debianutils   4.8.1
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-8
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.14-1
ii  libdbus-glib-1-2  0.108-1
ii  libevent-2.0-52.0.21-stable-2.1
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.2.1-5
ii  libgdk-pixbuf2.0-02.36.2-1
ii  libglib2.0-0  2.50.2-2
ii  libgtk2.0-0   2.24.31-1
ii  libhunspell-1.4-0 1.4.1-2+b1
ii  libicu57  57.1-5
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libpangoft2-1.0-0 1.40.3-3
ii  libpixman-1-0 0.34.0-1
ii  libsqlite3-0  3.15.2-2
ii  libstartup-notification0  0.12-4
ii  libstdc++66.2.1-5
ii  libvpx4   1.6.0-3
ii  libx11-6  2:1.6.4-2
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b1
ii  zlib1g1:1.2.8.dfsg-4

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

Versions of packages icedove suggests:
pn  apparmor  
ii  fonts-lyx 2.2.2-1
ii  libgssapi-krb5-2  1.15-1

-- no debconf information


-- 
Boyan Penkov

Bug#850887: TC Involvement: MIPS and binutils

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 11 de enero de 2017 09:39:25 ART Sam Hartman wrote:
> Hi.
> 
> As you are probably aware, the question of what to do about linking on
> mips and stretch has been referred to the TC.
> There's a reasonable probability that we're going to want to move very
> quickly on this issue, and I wanted to reach out to you and see how we
> could best work with you to collect your input.
> 
> I'd be happy to set up an IRC discussion, to set up a phone call, etc.
> I think that might work better than an email discussion, because the
> email discussion might involve a number of round trips.
> I'd be happy to work one-on-one and summarize results/provide logs back
> to the entire TC, or to set up something open to as many people as we
> can.
> Also if there's a TC member you'd rather work with than me, I'm sure
> we'd be happy to facilitate this.
> 
> I'm hoping that you will be able to quickly work with us to understand
> this issue and your position.

Hi Sam! I think an IRC discussion will be the best choice here as my phone 
lines are really not reliable at all :-(

I'll be online from 17:30 UTC onwards, nick lisandro on freenode.

I can ping you if I get to IRC sooner.

Kinds regards, Lisandro.

-- 
Why should I care about posterity?
What's posterity ever done for me?
  -- Groucho Marx

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


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

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

[Eric Scheibler]

Samuel Thibault  schrieb am 10.01.2017, 22:18 +0100:
>Eric Scheibler, on Sun 08 Jan 2017 09:05:09 +0100, wrote:
>> 1. The monotonous speech output persists.
>
>I dug a bit and found the issue, reported upstream, and have uploaded a fixed 
>version.

Confirmed.

>> 2. The delay after muting the screen reader is still there too (used the 
>> shift key for brltty)
>
>Err, but is shift really supposed to shut brltty up?  Without using the
>keycapture feature, brltty can't detect shift presses.  This is the same
>with espeak and espeak-ng.

By default, brltty maps "MUTE" to the control keys. I've also mapped it to the 
shift keys (better to
reach). Both keys work as expected, except the delay on espeak-ng. But anyway, 
the mute function
was just an example. I thought, that it would be easy to reproduce.

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

For mute, this results in a noticeable delay, in which espeak still talks, 
although it should be
canceled already. And the overlapping occurs, cause thread 2 already speaks the 
new line while
thread 1 is still talking.

Eric

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

[Ben Hutchings]

Control: severity -1 important

On Wed, 2017-01-11 at 15:52 +0100, Vincent Lefevre wrote:
> Control: severity -1 grave
> 
> because it can corrupt files.
>
> When this occurred on December 23, the log file of monit got
> corrupted:
> 
> [CET Dec 22 07:35:07] info : 'zira' Monit reloaded
> [CET Dec 22 07:35:07] error: Queued event file: unable to read event size 
> -- end of file
> [CET Dec 23 10:51:01] error: 'eth0' link down
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@[CET
>  Dec 23 10:52:10] info : Starting Monit 5.20.0 daemon
> [CET Dec 23 10:52:10] info : 'zira' Monit 5.20.0 started
> [...]

Unless you can show that some data had been written *and flushed* to
disk by the application, but was not readable afterward - this does not
count.  Writes are buffered, and user space has to deal with that.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert
Coveyou



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

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 15:09:49 +, Ben Hutchings wrote:
> Unless you can show that some data had been written *and flushed* to
> disk by the application, but was not readable afterward - this does not
> count.  Writes are buffered, and user space has to deal with that.

If I understand the journalctl log correctly, the system does
a power off without a clean shutdown:

[...]
Dec 23 10:51:01 zira systemd-logind[803]: Powering Off...
Dec 23 10:51:01 zira systemd-logind[803]: System is powering down.
Dec 23 10:51:01 zira systemd[1]: Stopping Manage, Install and Generate Color Pro

then nothing after that!!! This is were the problem is, not in the
application, which cannot know when the machine will power off.

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

Bug#850339: [PATCH 2/3] initramfs-tools: Add script for loading EVM key

[Stefan Berger]

From: Stefan Berger 

Add a script for loading the EVM (extended verification module) key.
Either a symmetric key or an x.509 certificate can be loaded using the
scripts.

A config file /etc/default/evm allows to configure parameters of the
key.

Signed-off-by: Stefan Berger 
---
 hooks/evm|  20 ++
 scripts/init-top/evm | 176 +++
 2 files changed, 196 insertions(+)
 create mode 100755 hooks/evm
 create mode 100755 scripts/init-top/evm

diff --git a/hooks/evm b/hooks/evm
new file mode 100755
index 000..0961bab
--- /dev/null
+++ b/hooks/evm
@@ -0,0 +1,20 @@
+#!/bin/sh
+
+PREREQ="masterkey"
+
+prereqs()
+{
+   echo "$PREREQ"
+}
+
+case $1 in
+prereqs)
+   prereqs
+   exit 0
+   ;;
+esac
+
+. /usr/share/initramfs-tools/hook-functions
+copy_exec /bin/findmnt
+copy_exec /bin/keyctl
+copy_exec /usr/bin/evmctl
diff --git a/scripts/init-top/evm b/scripts/init-top/evm
new file mode 100755
index 000..236139b
--- /dev/null
+++ b/scripts/init-top/evm
@@ -0,0 +1,176 @@
+#!/bin/sh
+
+# Licensed under the GPLv2
+#
+# Copyright (C) 2011 Politecnico di Torino, Italy
+#TORSEC group -- http://security.polito.it
+# Roberto Sassu 
+#
+#
+# (c) Copyright IBM Corporation 2016,2017
+#
+# Stefan Berger 
+#
+# This file has been derived from Dracut's 98integrity/evm-enable.sh
+#
+
+PREREQ="masterkey"
+
+prereqs()
+{
+   echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+   prereqs
+   exit 0
+   ;;
+esac
+
+. /scripts/functions
+
+SECURITYFSDIR=`findmnt -t securityfs -n -o TARGET`
+if  [ ! $SECURITYFSDIR ]; then
+   SECURITYFSDIR="/sys/kernel/security"
+   mount -t securityfs -o nosuid,noexec,nodev securityfs ${SECURITYFSDIR} 
>/dev/null 2>&1
+fi
+
+NEWROOT="${rootmnt}"
+EVMSECFILE="${SECURITYFSDIR}/evm"
+EVMCONFIG="${NEWROOT}/etc/default/evm"
+EVMKEYDESC="evm-key"
+EVMKEYTYPE="encrypted"
+EVMKEYID=""
+
+getarg()
+{
+   att=$1
+
+   sed -n 's/.*'${att}'\([^ ]\+\).*/\1/p' /proc/cmdline
+}
+
+load_evm_key()
+{
+   # read the configuration from the config file
+   [ -f "${EVMCONFIG}" ] && \
+   . ${EVMCONFIG}
+
+   # override the EVM key path name from the 'evmkey=' parameter in the 
kernel
+   # command line
+   EVMKEYARG=$(getarg evmkey=)
+   [ -n "${EVMKEYARG}" ] && \
+   EVMKEY=${EVMKEYARG}
+
+   # set the default value
+   [ -z "${EVMKEY}" ] && \
+   EVMKEY="/etc/keys/evm-trusted.blob";
+
+   # set the EVM key path name
+   EVMKEYPATH="${NEWROOT}${EVMKEY}"
+
+   # check for EVM encrypted key's existence
+   if [ ! -f "${EVMKEYPATH}" ]; then
+   [ "$quiet" != "y" ] && _log_msg "integrity: EVM encrypted key 
file not found: ${EVMKEYPATH}\n"
+   return 1
+   fi
+
+   # read the EVM encrypted key blob
+   KEYBLOB=$(cat ${EVMKEYPATH})
+
+   # load the EVM encrypted key
+   EVMKEYID=$(keyctl add ${EVMKEYTYPE} ${EVMKEYDESC} "load ${KEYBLOB}" @u)
+   [ $? -eq 0 ] || {
+   _log_msg "integrity: failed to load the EVM encrypted key: 
${EVMKEYDESC}\n";
+   return 1;
+   }
+
+   _log_msg "integrity: Loaded EVM key ${EVMKEYPATH}\n"
+
+   return 0
+}
+
+load_evm_x509()
+{
+   [ "$quiet" != "y" ] && _log_msg "integrity: Load EVM IMA X509\n"
+
+   # override the EVM key path name from the 'evmx509=' parameter in
+   # the kernel command line
+   EVMX509ARG=$(getarg evmx509=)
+   [ -n "${EVMX509ARG}" ] && \
+   EVMX509=${EVMX509ARG}
+
+   # set the default value
+   [ -z "${EVMX509}" ] && \
+   EVMX509="/etc/keys/x509_evm.der";
+
+   # set the EVM public key path name
+   EVMX509PATH="${NEWROOT}${EVMX509}"
+
+   # check for EVM public key's existence
+   if [ ! -f "${EVMX509PATH}" ]; then
+   [ "$quiet" != "y" ] && _log_msg "integrity: EVM x509 cert file 
not found: ${EVMX509PATH}\n"
+   return 1
+   fi
+
+   # load the EVM public key onto the EVM keyring
+   line="$(sed -n 's/\([^ ]\+\).*keyring\s\+\.evm:.*/\1/p' /proc/keys)"
+   if [ -n "$line" ]; then
+   evm_pubid=$(printf "%d" "0x$line")
+   else
+   evm_pubid=`keyctl search $u keyring _evm`
+   if [ -z "${evm_pubid}" ]; then
+   evm_pubid=`keyctl newring _evm @u`
+   fi
+   fi
+   EVMX509ID=$(evmctl import ${EVMX509PATH} ${evm_pubid} 2>/dev/null)
+   if [ $? -ne 0 ]; then
+   [ "$quiet" != "y" ] && _log_msg "integrity: failed to load the 
EVM X509 cert ${EVMX509PATH}\n"
+   return 1
+   fi
+
+   _log_msg "integrity: Loaded EVM x509 cert ${EVMX509PATH}\n"
+
+   [ "$quiet" != "y" ] && keyctl show @u
+
+   return 0
+}
+
+unload_evm_key()
+{
+   # 

Bug#850339: [PATCH 3/3] initramfs-tools: Add scripts for loading IMA keys and policy

[Stefan Berger]

From: Stefan Berger 

Add a script for loading certificates used by the Linux Integrity
Measurement Architecture (IMA) for verifying file signatures. The
script will first look for the availability of the .ima keyring
and load all keys it finds on it. If the .ima keyring is not
available, it will try using _ima. The difference between .ima and
_ima is that certificates loaded onto the .ima keyring must have
been signed by a CA known to the kernel, whereas _ima accepts plain
public keys.

Add a script for loading the IMA policy. A configuration file
can be provided in /etc/default/ima where the location of the
policy can be set. The default location is /etc/default/ima-policy.

Signed-off-by: Stefan Berger 
---
 hooks/ima| 22 +++
 scripts/init-top/ima-keys-load   | 80 
 scripts/init-top/ima-policy-load | 70 +++
 3 files changed, 172 insertions(+)
 create mode 100755 hooks/ima
 create mode 100755 scripts/init-top/ima-keys-load
 create mode 100755 scripts/init-top/ima-policy-load

diff --git a/hooks/ima b/hooks/ima
new file mode 100755
index 000..3284707
--- /dev/null
+++ b/hooks/ima
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+PREREQ=""
+
+prereqs()
+{
+   echo "$PREREQ"
+}
+
+case $1 in
+prereqs)
+   prereqs
+   exit 0
+   ;;
+esac
+
+. /usr/share/initramfs-tools/hook-functions
+copy_exec /usr/bin/evmctl
+copy_exec /bin/findmnt
+copy_exec /bin/keyctl
+copy_exec /bin/mount
+copy_exec /bin/ls
diff --git a/scripts/init-top/ima-keys-load b/scripts/init-top/ima-keys-load
new file mode 100755
index 000..e007d57
--- /dev/null
+++ b/scripts/init-top/ima-keys-load
@@ -0,0 +1,80 @@
+#!/bin/sh
+
+# (c) Copyright IBM Corporation 2015, 2016, 2017
+#
+# Mimi Zohar 
+# Stefan Berger 
+#
+# This file has been derived from Dracut's 98integrity/ima-keys-load.sh
+#
+
+PREREQ=""
+
+prereqs()
+{
+   echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+   prereqs
+   exit 0
+   ;;
+esac
+
+. /scripts/functions
+
+SECURITYFSDIR=`findmnt -t securityfs -n -o TARGET`
+if  [ ! $SECURITYFSDIR ]; then
+   SECURITYFSDIR="/sys/kernel/security"
+   mount -t securityfs -o nosuid,noexec,nodev securityfs ${SECURITYFSDIR} 
>/dev/null 2>&1
+fi
+
+NEWROOT="${rootmnt}"
+IMASECDIR="${SECURITYFSDIR}/ima"
+IMACONFIG="${NEWROOT}/etc/default/ima"
+
+load_x509_keys()
+{
+   KEYRING_ID=$1
+
+   # override the default configuration
+   if [ -f "${IMACONFIG}" ]; then
+   . ${IMACONFIG}
+   fi
+
+   if [ -z "${IMAKEYDIR}" ]; then
+   IMAKEYSDIR="/etc/keys/ima"
+   fi
+
+   PUBKEY_LIST=`ls ${NEWROOT}${IMAKEYSDIR}/*`
+   for PUBKEY in ${PUBKEY_LIST}; do
+   X509ID=$(evmctl import ${PUBKEY} ${KEYRING_ID} 2>/dev/null)
+   [ $? -ne 0 ] && _log_msg "integrity: IMA x509 cert not loaded 
on keyring: ${PUBKEY}\n"
+   done
+
+   [ "$quiet" != "y" ] && keyctl show  ${KEYRING_ID}
+
+   return 0
+}
+
+# check kernel support for IMA
+if [ ! -e "${IMASECDIR}" ]; then
+   [ "$quiet" != "y" ] && _log_msg "integrity: IMA kernel support is 
disabled\n"
+   return 0
+fi
+
+# get the .ima keyring id
+line="$(sed -n 's/\([^ ]\+\).*keyring\s\+\.ima:.*/\1/p' /proc/keys)"
+if [ -n "$line" ]; then
+   _ima_id=$(printf "%d" "0x$line")
+else
+   _ima_id=`keyctl search @u keyring _ima`
+   if [ -z "${_ima_id}" ]; then
+   _ima_id=`keyctl newring _ima @u`
+   fi
+fi
+
+# load the IMA public key(s)
+load_x509_keys ${_ima_id}
diff --git a/scripts/init-top/ima-policy-load b/scripts/init-top/ima-policy-load
new file mode 100755
index 000..4965db4
--- /dev/null
+++ b/scripts/init-top/ima-policy-load
@@ -0,0 +1,70 @@
+#!/bin/sh
+#
+# Licensed under the GPLv2
+#
+# Copyright (C) 2010 Politecnico di Torino, Italy
+#TORSEC group -- http://security.polito.it
+# Roberto Sassu 
+#
+# (c) Copyright IBM Corporation 2016, 2017
+#
+# Stefan Berger 
+#
+# This file has been derived from Dracut's 98integrity/ima-policy-load.sh
+#
+
+PREREQ=""
+
+prereqs()
+{
+   echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+   prereqs
+   exit 0
+   ;;
+esac
+
+. /scripts/functions
+
+SECURITYFSDIR=`findmnt -t securityfs -n -o TARGET`
+if  [ ! $SECURITYFSDIR ]; then
+   SECURITYFSDIR="/sys/kernel/security"
+   mount -t securityfs -o nosuid,noexec,nodev securityfs ${SECURITYFSDIR} 
>/dev/null 2>&1
+fi
+
+NEWROOT="${rootmnt}"
+IMASECDIR="${SECURITYFSDIR}/ima"
+IMACONFIG="${NEWROOT}/etc/default/ima"
+IMAPOLICY="/etc/default/ima-policy"
+
+load_ima_policy()
+{
+   # check kernel support for IMA
+   if [ ! -e "${IMASECDIR}" ]; then
+   [ "$quiet" != "y" ] && _log_msg "integrity: IMA kernel support 
is disabled\n"

Bug#850951: CVE-2016-9962

[Moritz Muehlenhoff]

Source: runc
Severity: grave
Tags: security

Please see:
https://bugzilla.suse.com/show_bug.cgi?id=1012568
https://github.com/docker/docker/compare/v1.12.5...v1.12.6
https://github.com/opencontainers/runc/commit/50a19c6ff828c58e5dab13830bd3dacde268afe5

Cheers,
Moritz
 

Bug#850339: [PATCH 1/3] initramfs-tools: add script for loading kernel masterkey

[Stefan Berger]

From: Stefan Berger 

We are adding a script for loading the kernel master key,
which is a symmetric key that is used to decrypt other keys
in the system. The kernel master key can either be a trusted
or a user key.

A config file /etc/default/masterkey allows to configure
the type of key and its location. By default it is expected
to be found under /etc/keys/kmk-trusted.blob.

Signed-off-by: Stefan Berger 
---
 hooks/masterkey|  19 
 scripts/init-top/masterkey | 105 +
 2 files changed, 124 insertions(+)
 create mode 100755 hooks/masterkey
 create mode 100755 scripts/init-top/masterkey

diff --git a/hooks/masterkey b/hooks/masterkey
new file mode 100755
index 000..b32a936
--- /dev/null
+++ b/hooks/masterkey
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+PREREQ=""
+
+prereqs()
+{
+   echo "$PREREQ"
+}
+
+case $1 in
+prereqs)
+   prereqs
+   exit 0
+   ;;
+esac
+
+. /usr/share/initramfs-tools/hook-functions
+copy_exec /bin/keyctl
+copy_exec /bin/uname
diff --git a/scripts/init-top/masterkey b/scripts/init-top/masterkey
new file mode 100755
index 000..62f4cdf
--- /dev/null
+++ b/scripts/init-top/masterkey
@@ -0,0 +1,105 @@
+#!/bin/sh
+
+# Licensed under the GPLv2
+#
+# Copyright (C) 2011 Politecnico di Torino, Italy
+#TORSEC group -- http://security.polito.it
+# Roberto Sassu 
+#
+# (c) Copyright IBM Corporation 2016,2017
+#
+# Stefan Berger 
+#
+# This file has been derived from Dracut's 97masterkey/masterkey.sh
+#
+PREREQ=""
+
+prereqs()
+{
+   echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+   prereqs
+   exit 0
+   ;;
+esac
+
+. /scripts/functions
+
+NEWROOT="${rootmnt}"
+MASTERKEYSCONFIG="${NEWROOT}/etc/default/masterkey"
+MULTIKERNELMODE="NO"
+PCRLOCKNUM=11
+
+getarg()
+{
+   att=$1
+
+   sed -n 's/.*'${att}'\([^ ]\+\).*/\1/p' /proc/cmdline
+}
+
+load_masterkey()
+{
+   # read the configuration from the config file
+   [ -f "${MASTERKEYSCONFIG}" ] && \
+   . ${MASTERKEYSCONFIG}
+
+   # override the kernel master key path name from the 'masterkey=' 
parameter
+   # in the kernel command line
+   MASTERKEYARG=$(getarg masterkey=)
+   [ -n "${MASTERKEYARG}" ] && \
+   MASTERKEY=${MASTERKEYARG}
+
+   # override the kernel master key type from the 'masterkeytype=' 
parameter
+   # in the kernel command line
+   MASTERKEYTYPEARG=$(getarg masterkeytype=)
+   [ -n "${MASTERKEYTYPEARG}" ] &&  \
+   MASTERKEYTYPE=${MASTERKEYTYPEARG}
+
+   # set default values
+   [ -z "${MASTERKEYTYPE}" ] && \
+   MASTERKEYTYPE="trusted"
+
+   if [ -z "${MASTERKEY}" ]; then
+   # append the kernel version to the default masterkey path name
+   # if MULTIKERNELMODE is set to YES
+   if [ "${MULTIKERNELMODE}" = "YES" ]; then
+   MASTERKEY="/etc/keys/kmk-${MASTERKEYTYPE}-$(uname 
-r).blob"
+   else
+   MASTERKEY="/etc/keys/kmk-${MASTERKEYTYPE}.blob"
+   fi
+   fi
+
+   # set the kernel master key path name
+   MASTERKEYPATH="${NEWROOT}${MASTERKEY}"
+
+   # check for kernel master key's existence
+   if [ ! -f "${MASTERKEYPATH}" ]; then
+   [ "$quiet" != "y" ] && _log_msg "masterkey: kernel master key 
file not found: ${MASTERKEYPATH}\n"
+   return 1
+   fi
+
+   # read the kernel master key blob
+   KEYBLOB=$(cat ${MASTERKEYPATH})
+
+   # add the 'load' prefix if the key type is 'trusted'
+   [ "${MASTERKEYTYPE}" = "trusted" ] && \
+   KEYBLOB="load ${KEYBLOB} pcrlock=${PCRLOCKNUM}"
+
+   # load the kernel master key
+   _log_msg "masterkey: Loading the kernel master key\n"
+   keyctl add "${MASTERKEYTYPE}" "kmk-${MASTERKEYTYPE}" "${KEYBLOB}" @u 
>/dev/null
+   if [ $? -ne 0 ]; then
+   _log_msg "masterkey: failed to load the kernel master key: 
kmk-${MASTERKEYTYPE}\n"
+   return 1
+   fi
+
+   _log_msg "masterkey: Loaded masterkey ${MASTERKEYPATH}\n"
+
+   return 0
+}
+
+load_masterkey
-- 
2.8.3

Bug#850955: libapache2-request-perl: description should include the names of the libraries

[Steinar H. Gunderson]

On Wed, Jan 11, 2017 at 04:41:00PM +0100, Seb wrote:
> It would be useful if the names of the libraries included in the package 
> could 
> be found with Debian's usual tools.

Hi!

Thanks for your bug report. It is certainly a valid concern, but I will add
that if you're looking for a specific Perl module, apt-file is great and
certainly a standard tool :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#850918: RFS: rear/2.00+dfsg-1 ITP: rear -- Bare metal disaster recovery and system migration framework

[Andreas Henriksson]

Hello Frederic Bonnard,

On Wed, Jan 11, 2017 at 09:28:19AM +0100, Frederic Bonnard wrote:
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors, Gianfranco,
> first best wishes to you all for this new year, health, success ;
> especially in you Debian area :) .
> 
> I am looking for a sponsor for my package "rear".
> This is an upgrade to previous 1.19 and it fixes a FTBFS bug. Extract from 
> d/changelog :
> 
> rear (2.00+dfsg-1) unstable; urgency=medium
> 
>   * New upstream release
>   * d/control : move asciidoc to Build-Depends (Closes: #849303)
> 
>  -- Frédéric Bonnard   Tue, 10 Jan 2017 15:12:34 
> +0100
[...]

Given asciidoc was recently restructured with a new package split and
the asciidoc package itself became a meta-package shouldn't you also
take this opportunity to switch your build-dep to something else, like
possibly asciidoc-base?

(Not sure exactly what your needs are and which one of the asciidoc
packages is suitable for you. The rear-doc package only seems to contain
html files though and the asciidoc-base package description makes me
think that's the suitable one.)

Regards,
Andreas Henriksson

Bug#850946: pinentry-curses: does not quit on Ctrl-C (SIGINT), still grabs keys, takes 100% CPU time

[Vincent Lefevre]

Package: pinentry-curses
Version: 1.0.0-1
Severity: important

When I use

pinentry-program /usr/bin/pinentry-curses

in ~/.gnupg/gpg-agent.conf and I do:

$ gpg -d file.gpg

I get:

┌──┐
│ Enter passphrase │
│  │
│  │
│ Passphrase:  │
│  │
│  │
└──┘

Then if I type Ctrl-C, I get back to the shell, but pinentry-curses
is still running and grab keys, making the terminal and the shell
unusable: some keys go to the shell (I've tried with both bash and
zsh), other keys go to pinentry-curses, randomly. If I quit the
terminal, then pinentry-curses takes 100% CPU time until I manually
kill it.

-- 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 pinentry-curses depends on:
ii  libassuan0 2.4.3-2
ii  libc6  2.24-8
ii  libgpg-error0  1.26-1
ii  libncursesw5   6.0+20161126-1
ii  libtinfo5  6.0+20161126-1

pinentry-curses recommends no packages.

Versions of packages pinentry-curses suggests:
pn  pinentry-doc  

-- no debconf information

Bug#850950: unblock: debian-design/3.0.4

[Andreas Beckmann]

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

Please unblock package debian-design

(I'm speaking with my piuparts hat on, I have no interest in
debian-design (nor do I know what that package is good for ...))

debian-design seems to be the only package that missed the Jan 5
migration deadline (at age 14) solely due to being blocked by a
piuparts failure (piuparts test is killed after a timeout). That issue
is not trivially reproducible outside of piuparts, seems to be related
to a problem in needsrestart (#826044) and is now tracked in piuparts
as #850948. It does not seem to be a problem in debian-design itself.
Since evaluating piuparts results in britney is a quite new feature,
please let that new package still into stretch.

unblock debian-design/3.0.4
ignore-piuparts debian-design/3.0.4


Andreas

PS: there were more packages rightfully being blocked by piuparts
failures and regressions, those now have corresponding RC bugs :-)

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

[Wolfgang Schweer]

Package: gosa-plugin-netgroups
Version: 0.1~svn652-4
Severity: normal
User: debian-...@lists.debian.org
User-tags: debian-edu

Hi,

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();
 }


Please test.

Wolfgang


signature.asc
Description: Digital signature

Bug#850955: libapache2-request-perl: description should include the names of the libraries

[Seb]

Package: libapache2-request-perl
Version: 2.13-4+b1
Severity: minor

Dear Maintainer,


I needed to use Apache2::Cookie on a server. I tried locating this Perl 
library with apt-cache search, then with apt-file, mais couldn't find a result 
with Debian's tools. 

Because the library was used on another server running Debian, I knew it had 
to be available in some package somewhere. It is only through Google that I 
found libapache2-request-perl, after a frustrating quarter of an hour.

It would be useful if the names of the libraries included in the package could 
be found with Debian's usual tools.


Thanks!
Seb.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to 
en_US.iso88591)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libapache2-request-perl depends on:
ii  libapache2-mod-apreq2   2.13-4+b1
ii  libapache2-mod-perl22.0.9~1624218-2+deb8u1
ii  libapr1 1.5.1-3
ii  libapreq2-3 2.13-4+b1
ii  libaprutil1 1.5.4-1
ii  libc6   2.19-18+deb8u6
ii  perl5.20.2-3+deb8u6
ii  perl-base [perlapi-5.20.0]  5.20.2-3+deb8u6

libapache2-request-perl recommends no packages.

libapache2-request-perl suggests no packages.

-- no debconf information

Bug#850855: [rtkit] rtkit daemon fails to start

[Felipe Sateler]

On 11 January 2017 at 12:37, Bogdan Vatra  wrote:
> On miercuri, 11 ianuarie 2017 10:12:00 EET Felipe Sateler wrote:
>> Control: tags -1 moreinfo unreproducible
>>
>> On 11 January 2017 at 04:59, Bogdan Vatra  wrote:
>> > On miercuri, 11 ianuarie 2017 09:48:16 EET Bogdan Vatra wrote:
>> >> On marți, 10 ianuarie 2017 17:20:28 EET Felipe Sateler wrote:
>> >> > Hi,
>> >> >
>> >> > On 10 January 2017 at 16:05, Bogdan Vatra 
> wrote:
>> >> > > Package: rtkit
>> >> > > Version: 0.11-4
>> >> > > Severity: important
>> >> > >
>> >> > > --- Please enter the report below this line. ---
>> >> > >
>> >> > > This bug is pretty annoying because it makes pulseaudio unusable (see
>> >> > > #850806).
>> >> >
>> >> > > Here are the logs:
>> >> > 
>> >> >
>> >> > > -- Unit rtkit-daemon.service has begun starting up.
>> >> > > ian 10 21:00:32 zmeu rtkit-daemon[19342]: Failed to connect to system
>> >> > > bus:
>> >> > > Failed to connect to socket /var/run/dbus/system_bus_socket: No su
>> >> >
>> >> > This suggests that dbus is not running. Could that be the case? Do
>> >> > other dbus-interacting apps misbehave?
>> >>
>> >> I think that's a wrong message ... because :
>> >>
>> >> $ ls -l /var/run/dbus/system_bus_socket
>> >> srw-rw-rw- 1 root root 0 ian 10 09:42 /var/run/dbus/system_bus_socket
>> >>
>> >> That file exists and dbus works fine (all my KDE/Qt apps works ok).
>> >
>> > If I manually run "/usr/lib/rtkit/rtkit-daemon" it works just fine...
>> > The only problem is when I start it with "systemctl start rtkit-
>> > daemon.service".
>>
>> Weird. Could you repeat the same with the daemon as started by systemd?
>>
>> Use `systemctl edit --full rtkit-daemon` to edit the ExecStart line.
>
> It is the same thing ... :
> [...]
> ExecStart=/usr/lib/rtkit/rtkit-daemon
> [...]
> Actually I was inspired from that file to exec "/usr/lib/rtkit/rtkit-daemon"
> manually :).

Sorry, I was not clear. I meant stracing the daemon.

-- 

Saludos,
Felipe Sateler

Bug#625203:

[Presley Bathini]

Hi,
I do not if you received my previous email.
I sent you an email previously requesting you to assist in receiving $15.7M
left in our bank for several years. Reply if you are interested.Thanks,
Presley.

Bug#850948: needrestart,piuparts: needrestart hangs -> piupart fails -> debian-design blocked

[Jonas Smedegaard]

Package: needrestart,piuparts
Severity: serious

This bugreport is tracking debian-design not entering testing.

Background:

 a) needrestart sometimes hangs during install.
 b) Needrestart hanging is caught by piuparts and treated as a failure.
 c) debian-design depends on needrestart and is blocked from testing.

Issue a) is tracked as bug#826044, but as severity important.

This bugreport is tracking the combined issue of a) + b) + c).

Please therefore reassign and/or merge as appropriate, but only as long
as the severity reflects the actual treatment of debian-design.


 - Jonas

Bug#850887: TC Involvement: MIPS and binutils

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 11 de enero de 2017 11:49:48 ART Lisandro Damián Nicanor Pérez 
Meyer wrote:
[snip] 
> I'll be online from 17:30 UTC onwards, nick lisandro on freenode.

And also oftc, of course.

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


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

Bug#754339: Bug confirmation...

[Marco Gaiarin]

I've just upgraded to jessie, (samba/winbind 2:4.2.14+dfsg-0+deb8u2),
and i can confirm the bug.

Directory (on TMPFS) /run/samba/winbindd_privileged have correct
permission but is empty:

 root@rita:~# ls -la /run/samba/winbindd_privileged/
 totale 0
 drwxr-x--- 2 root winbindd_priv  40 gen  3 12:43 .
 drwxr-xr-x 6 root root  480 gen  5 15:15 ..

while directory /var/lib/samba/winbindd_privileged have incorrect
permission, and the pipe get created within:

 root@rita:~# ls -la /var/lib/samba/winbindd_privileged/
 totale 8
 drwxr-x--- 2 root root 4096 gen  5 15:15 .
 drwxr-xr-x 7 root root 4096 gen 11 15:18 ..
 srwxrwxrwx 1 root root0 gen  5 15:15 pipe


Fixing the permission solves the trouble, of course.


Thanks.

Bug#850954: CVE-2016-10040

[Moritz Muehlenhoff]

Source: qtbase-opensource-src
Severity: important
Tags: security

Hi QT maintainers,
there was the following report on QXmlSimpleReader:
http://www.openwall.com/lists/oss-security/2016/12/24/2

Which upstream later later on labels as deprecated:
http://www.openwall.com/lists/oss-security/2017/01/09/1

There's probably not much we can do here, but I'd
be interested in QT maintainers opinion.

Maybe the next QT upload should simply add a note to the
changelog that it's unsupported. Do we have any notable
users of QXmlSimpleReader in stretch? Probably not.

Cheers,
Moritz

Bug#850957: succesful installation on Intel NUC6i3SYB

[Antoine Beaupre]

Package: installation-reports
Severity: wishlist

No problems with this install, just a "everything is good" report,
thanks!

-- Package-specific info:

Boot method: USB
Image version: debian-stretch-DI-alpha8-amd64-netinst.iso downloaded
from cdimage.debian.org mirrors SHA256:
ba813e38d5863580f7e987faae1757f402d0f3129a03b8411e1e42ac833c28a6b0a87e63ebcce583d64d786463a8c5eac8beb6fb2d2f0ad5c4778c2b680d3104
Date: 2017-01-04T19:40:00

Machine: Intel NUC6i3SYB
Partitions: 

Filesystem Type  1K-blocks   Used  Available Use% 
Mounted on
udev   devtmpfs   8150368K 0K   8150368K   0% /dev
tmpfs  tmpfs  1632420K 50584K   1581836K   4% /run
/dev/mapper/curie--vg-root ext4  28703652K  11519504K  15703036K  43% /
tmpfs  tmpfs  8162100K 14688K   8147412K   1% 
/dev/shm
tmpfs  tmpfs 5120K 4K  5116K   1% 
/run/lock
tmpfs  tmpfs  8162100K 0K   8162100K   0% 
/sys/fs/cgroup
/dev/mapper/curie--vg-home ext4 433665920K 133400984K 278166200K  33% /home
tmpfs  tmpfs  1632420K20K   1632400K   1% 
/run/user/1000
/dev/sda2  ext4241965K 68469K161004K  30% /boot
/dev/sda1  vfat523248K   132K523116K   1% 
/boot/efi

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

I had problems with my screen, because the NUC requires a digital
display. I had previously used a HDMI/DVI connector to connect my
laptop and the screen, but this failed on the NUC, presumably because
it wasn't sending analog signals through the HDMI cable. I found a
miniDP to VGA adapter, and everything worked smoothly after that.

I never got the wifi card to work, and never bothered to either: I am
fine with the wired connection. I *believe* it requires a binary
firmware blob, because it is not detected correctly otherwise.

One oddity I have found after install is that I couldn't run
memtest86+ (or memtest86) from grub. I installed it after the first
boot, rebooted, but then the memtest86 never comes up when I select it
from the dropdown.

In an image I custom-build with vmdebootstrap that includes
memtest86+, I was able to select the menu option, so I am not sure
what is going on here.

Otherwise this is a "two thumbs up" for running Debian strech on a
recent Intel NUC platform. It's awesome.

Thanks!

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20161031"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux curie 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Sky Lake Host 
Bridge/DRAM Registers [8086:1904] (rev 08)
lspci -knn: DeviceName:  WIFI
lspci -knn: Subsystem: Intel Corporation Device [8086:2063]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Sky 
Lake Integrated Graphics [8086:1916] (rev 07)
lspci -knn: DeviceName:  CPU
lspci -knn: Subsystem: Intel Corporation Device [8086:2063]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:9d2f] 
(rev 21)
lspci -knn: Subsystem: Intel Corporation Device [8086:2063]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Device [8086:9d31] (rev 21)
lspci -knn: Subsystem: Intel Corporation Device [8086:2063]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Device 
[8086:9d3a] (rev 21)
lspci -knn: Subsystem: Intel Corporation Device [8086:2063]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Device 
[8086:9d03] (rev 21)
lspci -knn: Subsystem: Intel Corporation Device [8086:2063]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d14] 
(rev f1)
lspci -knn: 

Bug#850949: icedove does not sync google calendars, claiming item.recurrenceInfo is null

[Carsten Schoenert]

severity 850949 important
thanks

Lowering down to important. Please see 
https://www.debian.org/Bugs/Developer#severities

Regards
Carsten

On Wed, Jan 11, 2017 at 09:35:36AM -0500, Boyan Penkov wrote:
> Package: icedove
> Version: 1:45.5.1-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I have icedove and the google calendar provider installed.  I have three
> calendars: a work one tied to a work google account, and a personal and one
> shared with my partner tied to my personal gmail.
> 
> Both the work one and the partner one sync fine, my personal one (which is
> the oldest, and contains the most events), failes to update with the
> following error (pulled off the icedove error console):
> 
> Timestamp: 01/06/2017 09:18:47 PM
> Error: [calCachedCalendar] replay action failed: null, uri=googleapi://
> boyan.pen...@gmail.com/?calendar=boyan.penkov%40gmail.com,
> result=item.recurrenceInfo is null, op=[xpconnect wrapped calIOperation]
> Source File: file:///usr/lib/icedove/extensions/%7Be2fda1a4-762b-4020-
> b5ad-a41df1933103%7D/calendar-js/calCachedCalendar.js
> Line: 327
> 
> I have tried using both debian's "calendar-google-provider" package and the
> addon installed through the icedove extensions menu, and the effect is the
> same with both.

Bug#850869: git-buildpackage: command-line arguments not quoted correctly

[Guido Günther]

Hi Simon,
On Tue, Jan 10, 2017 at 07:53:48PM +, Simon McVittie wrote:
> I'm currently using git-buildpackage with a custom --builder command
> (vectis, https://github.com/smcv/vectis) that among other things accepts
> a command-line option of the form:
> 
> --extra-repository='deb [trusted=yes] http://localhost/path suite 
> component'
> 
> With git-buildpackage, I have to backslash-escape the spaces:
> 
> --extra-repository='deb\ [trusted=yes]\ ...'
> 
> or it will treat "--extra-repository=deb", "[trusted=yes]", etc. as
> separate command-line arguments for vectis. This is because
> gbp.command_wrappers.Command(..., shell=True) just joins the command
> to the arguments with " ".join() rather than doing proper shell quoting.
> That's correct for the --builder as currently documented, but not for
> its arguments.
> 
> It would be easy to run into this with debuild if you're using something
> like gbp buildpackage --set-envvar=DEBFULLNAME="Simon McVittie"
> (a debuild option) or gbp buildpackage --check-command="lintian -Ii"
> (a dpkg-buildpackage option).

Thanks for the detailed description. Interesting that this went
unnoticed for so long. I've added a test so we hopefully don't regress
there.

> 
> Doing proper shell quoting in Python 3 is trival (shlex.quote, which
> I use a lot in vectis) but Python 2 doesn't have that function. However,
> there is another way to get the --builder interpreted as a shell
> one-liner and still pass it arguments: you can invoke
> 
> ["sh", "-c", ('%s "$@"' % builder), "sh"] + arguments

I went for using pipes.quote which is python2's equivalent of
shlex.quote and fixed up buildpackage-rpm as well so we're consistent.

Decided to leave quoting to the caller rather than doing it in Command
itself to be consistent between shell=True and cases where command
itself is already a script with arguments from e.g. gbp.conf like
hooks.

Cheers,
 -- Guido

> 
> with shell=False, and it will do the right thing. The first "sh" in
> that monster is argv[0] for the subprocess, and the second is $0 for
> the shell one-liner.
> 
> I attach a possible patch.
> 
> S

> From a088aef91ffa9de60c6d7ac3278360ce0ee571e1 Mon Sep 17 00:00:00 2001
> From: Simon McVittie 
> Date: Tue, 10 Jan 2017 19:49:08 +
> Subject: [PATCH] buildpackage: don't treat dpkg arguments as shell input
> 
> If one of gbp buildpackage's command-line arguments (after processing
> by the calling shell if applicable) includes spaces or shell
> metacharacters, it's unexpected to subject it to a layer of shell
> interpretation. Conversely, the builder option is documented to be
> a shell command and so must go through one layer of shell
> interpretation.
> 
> This makes an invocation like
> 
> gbp buildpackage --check-command="lintian -Ii"
> 
> work the way it was presumably intended.
> ---
>  gbp/scripts/buildpackage.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/gbp/scripts/buildpackage.py b/gbp/scripts/buildpackage.py
> index 6524f01..c7ad903 100755
> --- a/gbp/scripts/buildpackage.py
> +++ b/gbp/scripts/buildpackage.py
> @@ -727,7 +727,11 @@ def main(argv):
>   )(dir=build_dir)
>  
>  # Finally build the package:
> -RunAtCommand(options.builder, dpkg_args, shell=True,
> +RunAtCommand('sh',
> + ['-c', options.builder + ' "$@"',
> +  'sh'] +   # $0 for the shell one-liner
> + dpkg_args, # $@ for the shell one-liner
> + shell=False,   # we start the shell explicitly
>   extra_env=Hook.md(build_env,
> {'GBP_BUILD_DIR': build_dir})
>   )(dir=build_dir)
> -- 
> 2.11.0
> 

Bug#850948: needrestart, piuparts: needrestart hangs -> piupart fails -> debian-design blocked

[Andreas Beckmann]

On 2017-01-11 15:25, Jonas Smedegaard wrote:

> This bugreport is tracking debian-design not entering testing.

I filed an unblock request for you, since that seems to be
fallout from britney evaluationg piuparts results, #850950

I now managed to get the piuparts test to finish after removing
timeout from the command line ... strange ...

after installing all the dependencies, we are finally installing
design-desktop:

...
  Selecting previously unselected package design-desktop.
  Preparing to unpack .../design-desktop_3.0.4_all.deb ...
  Unpacking design-desktop (3.0.4) ...
  Setting up design-desktop (3.0.4) ...
  Failed to retrieve available kernel versions.
  Restarting services...
   telinit u
  Can't exec "telinit": No such file or directory at /usr/sbin/needrestart line 
899,  line 11.
  Services being skipped:
   service dbus restart
   service network-manager restart
  No containers need to be restarted.
  User sessions running outdated binaries:
   998 @ /dev/pts/10: bash[2218]
   998 @ /dev/pts/11: bash[11844]
...
   998 @ /dev/pts/20: bash[3350], python[9688]
...
   998 @ /dev/pts/9: bash[1938]
   999 @ /dev/pts/6: bash[1848]
   dummy1000 @ /dev/pts/0: bash[1319]
   dummy1000 @ /dev/pts/1: bash[6400]
   dummy1000 @ /dev/pts/14: bash[10579]
...
   dummy1000 @ /dev/pts/42: bash[12017]
   dummy1000 @ /dev/pts/5: bash[8979]
   root @ /dev/pts/1: bash[6440]
   root @ /dev/pts/11: apt-get[12657]
   root @ /dev/pts/13: apt-get[19639]
   root @ /dev/pts/25: bash[16006], schroot[15820]
   root @ /dev/pts/30: bash[16012]
...


I'm not sure whether needrestart does the right thing here ...
* it should adhere to policy-rc.d
* it should not run missing binaries
* it should be aware of being run in a chroot
  (right now it enumerates all shells running in the host system ...)


Andreas

Bug#850887: TC Involvement: MIPS and binutils

[Sam Hartman]

> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer  
> writes:

Lisandro> On miércoles, 11 de enero de 2017 09:39:25 ART Sam Hartman wrote:
>> Hi.
>> 
>> As you are probably aware, the question of what to do about
>> linking on mips and stretch has been referred to the TC.  There's
>> a reasonable probability that we're going to want to move very
>> quickly on this issue, and I wanted to reach out to you and see
>> how we could best work with you to collect your input.
>> 
>> I'd be happy to set up an IRC discussion, to set up a phone call,
>> etc.  I think that might work better than an email discussion,
>> because the email discussion might involve a number of round
>> trips.  I'd be happy to work one-on-one and summarize
>> results/provide logs back to the entire TC, or to set up
>> something open to as many people as we can.  Also if there's a TC
>> member you'd rather work with than me, I'm sure we'd be happy to
>> facilitate this.
>> 
>> I'm hoping that you will be able to quickly work with us to
>> understand this issue and your position.

Lisandro> Hi Sam! I think an IRC discussion will be the best choice
Lisandro> here as my phone lines are really not reliable at all :-(

Lisandro> I'll be online from 17:30 UTC onwards, nick lisandro on
Lisandro> freenode.

that was to doko not you.
I'd be happy to chat, but you've articulated your position fairly well.
If there's stuff not in the bug you'd like me to know about I'd be happy
to set things up, but from the bug logs, your position seems fairly
simple.
Let's see if my summary is accurate:

* This bug is creating a number of ftbfses, particularly for
  larger//more complex libraries on mips.

* You have a preferred minimal work-around you tried to upload

* Doko requested you not upload something until it was patched upstream.

* You want a solution sooner than that.

Is that approximately correct?

Bug#850953: dgit-maint-merge(7): Use git-deborig(1)

[Sean Whitton]

Package: dgit
Version: 3.1
Severity: minor
Tags: patch

`git deborig` has made its way into a release of devscripts, which
permits various simplifications to dgit-maint-merge(7).

Thanks.

-- 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 dgit depends on:
ii  apt   1.4~beta2
ii  ca-certificates   20161102
ii  coreutils 8.25-2
ii  curl  7.50.1-1
ii  devscripts2.17.0
ii  dpkg-dev  1.18.10
ii  dput-ng [dput]1.11
ii  git [git-core]1:2.11.0-1
ii  git-buildpackage  0.8.7
ii  libdpkg-perl  1.18.10
ii  libjson-perl  2.90-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc4-1
ii  libtext-glob-perl 0.10-1
ii  libtext-iconv-perl1.7-5+b4
ii  libwww-perl   6.15-1
ii  perl  5.24.1~rc4-1

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.3p1-5

Versions of packages dgit suggests:
ii  sbuild  0.72.0-2

-- no debconf information

-- 
Sean Whitton
From 4270f64a2f2def463b1df431ae8333f0f4fef097 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Wed, 11 Jan 2017 08:31:54 -0700
Subject: [PATCH] dgit-maint-merge(7): Use git-deborig(1)

Signed-off-by: Sean Whitton 
---
 dgit-maint-merge.7.pod | 28 +---
 1 file changed, 5 insertions(+), 23 deletions(-)

diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index 245be4c..0d8b2da 100644
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -34,20 +34,6 @@ that upstream makes available for download.
 
 =back
 
-=head1 GIT CONFIGURATION
-
-Add the following to your ~/.gitconfig to teach git-archive(1) how to
-compress orig tarballs:
-
-=over 4
-
-[tar "tar.xz"]
-	command = xz -c
-[tar "tar.gz"]
-	command = gzip -c
-
-=back
-
 =head1 INITIAL DEBIANISATION
 
 This section explains how to start using this workflow with a new
@@ -94,16 +80,15 @@ unless you also happen to be involved in upstream development.  We
 work with upstream tags rather than any branches, except when
 forwarding patches (see FORWARDING PATCHES UPSTREAM, below).
 
-Finally, you need an orig tarball.  Generate one with git-archive(1):
+Finally, you need an orig tarball:
 
 =over 4
 
-% git archive -o ../foo_1.2.2.orig.tar.xz 1.2.2
+% git deborig
 
 =back
 
-If you are using the version 1.0 source package format, replace 'xz'
-with 'gz'.
+See git-deborig(1) if this fails.
 
 This tarball is ephemeral and easily regenerated, so we don't commit
 it anywhere (e.g. with tools like pristine-tar(1)).
@@ -121,7 +106,7 @@ A convenient way to perform this check is to import the tarball as
 described in the following section, using a different value for
 'upstream-tag', and then use git-diff(1) to compare the imported
 tarball to the release tag.  If they are the same, you can use
-upstream's tarball instead of running git-archive(1).
+upstream's tarball instead of running git-deborig(1).
 
 =back
 
@@ -313,18 +298,15 @@ Once you're satisfied with what will be merged, update your package:
 
 =over 4
 
-% git archive -o ../foo_1.2.3.orig.tar.xz 1.2.3
 % git merge 1.2.3
 % dch -v1.2.3-1 New upstream release.
 % git add debian/changelog && git commit -m changelog
+% git deborig
 
 =back
 
 and you are ready to try a build.
 
-Again, if you are using the version 1.0 source package format, replace
-'xz' with 'gz'.
-
 =head2 When upstream releases only tarballs
 
 You will need the I from "When upstream releases only
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#850855: [rtkit] rtkit daemon fails to start

[Bogdan Vatra]

On miercuri, 11 ianuarie 2017 10:12:00 EET Felipe Sateler wrote:
> Control: tags -1 moreinfo unreproducible
> 
> On 11 January 2017 at 04:59, Bogdan Vatra  wrote:
> > On miercuri, 11 ianuarie 2017 09:48:16 EET Bogdan Vatra wrote:
> >> On marți, 10 ianuarie 2017 17:20:28 EET Felipe Sateler wrote:
> >> > Hi,
> >> > 
> >> > On 10 January 2017 at 16:05, Bogdan Vatra  
wrote:
> >> > > Package: rtkit
> >> > > Version: 0.11-4
> >> > > Severity: important
> >> > > 
> >> > > --- Please enter the report below this line. ---
> >> > > 
> >> > > This bug is pretty annoying because it makes pulseaudio unusable (see
> >> > > #850806).
> >> > 
> >> > > Here are the logs:
> >> > 
> >> > 
> >> > > -- Unit rtkit-daemon.service has begun starting up.
> >> > > ian 10 21:00:32 zmeu rtkit-daemon[19342]: Failed to connect to system
> >> > > bus:
> >> > > Failed to connect to socket /var/run/dbus/system_bus_socket: No su
> >> > 
> >> > This suggests that dbus is not running. Could that be the case? Do
> >> > other dbus-interacting apps misbehave?
> >> 
> >> I think that's a wrong message ... because :
> >> 
> >> $ ls -l /var/run/dbus/system_bus_socket
> >> srw-rw-rw- 1 root root 0 ian 10 09:42 /var/run/dbus/system_bus_socket
> >> 
> >> That file exists and dbus works fine (all my KDE/Qt apps works ok).
> > 
> > If I manually run "/usr/lib/rtkit/rtkit-daemon" it works just fine...
> > The only problem is when I start it with "systemctl start rtkit-
> > daemon.service".
> 
> Weird. Could you repeat the same with the daemon as started by systemd?
> 
> Use `systemctl edit --full rtkit-daemon` to edit the ExecStart line.

It is the same thing ... :
[...]
ExecStart=/usr/lib/rtkit/rtkit-daemon
[...]
Actually I was inspired from that file to exec "/usr/lib/rtkit/rtkit-daemon" 
manually :).

It there any way to debug it ?

Bug#850937: git-buildpackage: Default config file installed as /etc/git-buildpackage/gbp.conf/gbp.conf

[Guido Günther]

control: severity -1 grave

On Wed, Jan 11, 2017 at 11:15:22AM +, Luca Boccassi wrote:
> Package: git-buildpackage
> Version: 0.8.9
> Severity: normal
> 
> Dear Maintainer,
> 
> I just installed gbp 0.8.9 and I noticed that the default gbp.conf has
> moved
> from /etc/git-buildpackage to a subdirectory:
> 
> https://packages.debian.org/sid/all/git-buildpackage/filelist
> 
> $ ls /etc/git-buildpackage/gbp.conf/gbp.conf
> /etc/git-buildpackage/gbp.conf/gbp.conf
> $ dpkg -S /etc/git-buildpackage/gbp.conf/gbp.conf
> git-buildpackage: /etc/git-buildpackage/gbp.conf/gbp.conf
> 
> Probably a result of commit:
> 
> https://git.sigxcpu.org/cgit/git-
> buildpackage/commit/?id=9cbb9df7d8e05ce9c356216e3c4ac190141c0d02
> 
> -etc/git-buildpackage/gbp.conf
> +usr/share/git-buildpackage/gbp.conf etc/git-buildpackage/gbp.conf
> 
> I think dh_install interprets etc/git-buildpackage/gbp.conf as a
> directory.
> 
> Was this an intended change?

That's an error and it even wipes out existing gbp.confs too so lets bump
the severity accordingly.

Cheers,
 -- Guido

> 
> Thank you!
> 
> Kind regards,
> Luca Boccassi

Bug#850937: [git-buildpackage/master] Move default gbp.conf back to the right location

[Guido Günther]

tag 850937 pending
thanks

Date:   Wed Jan 11 13:04:37 2017 +0100
Author: Guido Günther 
Commit ID: 67d8b9f44b089eb04ae4ce54c03a0e06d751de30
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff;h=67d8b9f44b089eb04ae4ce54c03a0e06d751de30
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff_plain;h=67d8b9f44b089eb04ae4ce54c03a0e06d751de30

Move default gbp.conf back to the right location

0.8.9 placed gbp.conf at /etc/git-buildpackage/gbp.conf/gbp.conf. Move
the file back to the correct location.

Closes: #850937
Thanks: Luca Boccassi

A snapshot build including this change will be available at
http://honk.sigxcpu.org:8001/job/git-buildpackage/
  

Bug#826044: needrestart: Hangs in apt hook with a zombie

[Jonas Smedegaard]

Hi,

It seems I have another instance of this issue: piuparts hangs (as I 
understand it) during cleanup after an initial install of design-desktop 
which pulls in ńeedrestart.

Discussion starting at 
http://lists.alioth.debian.org/pipermail/piuparts-devel/2017-January/006734.html
 
has more details - an interesting part is this extracted when piuparts 
hangs:

30803 root   30  10  117M 63804  9816 T  0.0  0.2  0:11.84 │  │└─ 
/usr/bin/python /srv/piuparts/sbin/piuparts --skip-logrotatefiles-test 
--warn-on-others --no-eatmydata --scriptsdir /etc/piuparts/script
29515 root   30  10 84340 46992 32864 T  0.0  0.1  0:00.67 │  │   
└─ apt-get -y install design-desktop=3.0.4
30238 root   30  10 84340 14128 0 T  0.0  0.0  0:00.00 │  │ 
 └─ apt-get -y install design-desktop=3.0.4
30240 root   30  10  4288   752   676 T  0.0  0.0  0:00.00 │  │ 
└─ sh -c test -x /usr/lib/needrestart/apt-pinvoke && 
/usr/lib/needrestart/apt-pinvoke || true
30241 root   30  10 55276 1  4324 T  0.0  0.0  0:00.23 │  │ 
   └─ /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart
30331 root   30  10 50124 17516  4148 T  0.0  0.1  0:00.40 │  │ 
  └─ /usr/bin/perl /usr/sbin/needrestart
 2846 root   30  10  4288   740   668 T  0.0  0.0  0:00.00 │  │ 
 ├─ sh -c resize 2>/dev/null
 2847 root   30  10  4188   704   632 T  0.0  0.0  0:00.00 │  │ 
 │  └─ resize
 2838 root   30  10 0 0 0 Z  0.0  0.0  0:00.00 │  │ 
 └─ 90-none


 - 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#850052: Bug#850005: dgit push without dgit build-source

[Ian Jackson]

Control: tags -1 confirmed
Control: severity -1 normal

I wrote:
> I will try to repro this that way.  Anwyay, for now the bug should
> clearly be reopened.

I have repro'd this and the bug is more serious: it's due to a forked
child also running the cleanup handlers.

Thanks for your tenacity !

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#685344: devscripts: "bts show --mbox" cannot resume after a Ctrl-Z

[Vincent Lefevre]

Control: found -1 2.16.13
Control: found -1 2.17.0

On 2017-01-11 19:23:38 +1100, Ben Finney wrote:
> This does not happen for me when I try (using ‘devscripts/2.16.13’).

Note that the problem does not always occur. But when it occurs,
in general, Mutt no longer gets the keys from the keyboard.

> The ‘fg’ command simply resumes the MUA (in my case, ‘mutt’) as expected.

I also use mutt.

> Can you try reproducing this:
> 
> * With the current ‘devscripts’ version?

Same problem with 2.16.13 and 2.17.0.

> * Using each of Zsh and Bash?

Same problem from bash and zsh.

I've also tried from dash, but after Ctrl-Z, dash no longer receives
any key from the keyboard.

> * Using a different MUA?

No problems if I use:

  bts show --mailreader="less %s" --mbox 622231

or

  bts show --mailreader="lynx -force_html %s" --mbox 622231

Something interesting: when I type Ctrl-Z after running Mutt, zsh
mentions a STOP signal instead of the usual TSTP. This is due to:

case SIGTSTP: /* user requested a suspend */
  if (!option (OPTSUSPEND))
break;
  IsEndwin = isendwin ();
  curs_set (1);
  if (!IsEndwin)
endwin ();
  kill (0, SIGSTOP);

But lynx also needs to restore the terminal state, and zsh shows
TSTP, though lynx has:

kill(getpid(), SIGSTOP);

Well, this may not matter. But I wonder whether the "kill (0, SIGSTOP);"
(i.e. SIGSTOP sent to the progress group) is the problem with Mutt.
Doesn't this mean that the parent processes "sh" and "perl bts",
which don't trap SIGTSTP, can get stopped twice? Since Mutt is
presumably the only process to trap SIGTSTP, it should use getpid()
like lynx, IMHO. Now, I've rebuilt mutt with getpid() instead of 0,
and this doesn't make the problem disappear.

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

Bug#839804: monit: errors every 2 minutes in the log file: "Queued event file: unable to read event size -- end of file"

[Sergey B Kirpichev]

tags 839804 -moreinfo +unreproducible
thanks

On Mon, Jan 09, 2017 at 04:09:47PM +0100, Vincent Lefevre wrote:
> Yes, it seems so... unless the problem is not always reproducible
> (e.g. if there's some race condition).
> 
> I also wonder whether suspending the laptop can also yield the
> issue.
> 
> > If this is correct, problem seems to be solved in the new
> > version.  If not - please try to reproduce situation, when
> > event-files are created.
> 
> I'll try to reproduce the problem by rebooting the machine
> (not before Wednesday, though).

I'll wait for your reply till the end of week.  Then, I'll
close bug as unreproducible, if nothing happens.

Bug#850944: RM: google-sitemapgen -- ROM; no longer required

[Kumar Appaiah]

Package: ftp.debian.org
Severity: normal

Given that the landscape of the internet has changed significantly
over the past five years, this tool is not really that relevant
anymore. I propose that this be removed.

Thanks.

Kumar
-- 
Kumar Appaiah

Bug#685344: devscripts: "bts show --mbox" cannot resume after a Ctrl-Z

[Vincent Lefevre]

Control: retitle -1 devscripts: "bts show --mbox" cannot resume after a Ctrl-Z 
with mutt
Control: tags -1 - moreinfo

On 2017-01-11 14:44:38 +0100, Vincent Lefevre wrote:
> On 2017-01-11 19:23:38 +1100, Ben Finney wrote:
> > The ‘fg’ command simply resumes the MUA (in my case, ‘mutt’) as expected.
> 
> I also use mutt.

To make sure not to depend on a specific configuration:

  bts show --mailreader="/usr/bin/mutt -F /dev/null -f %s" --mbox 622231

yields the problem from both bash and zsh. Note also that I have
/bin/sh -> dash.

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

Bug#850945: ant: exec task fails with error 127 on kfreebsd-i386

[Gilles Filippini]

Package: ant
Version: 1.9.6-1
Severity: important

Hi,

This simple build.xml file fails with error 127 on kfreebsd-i386:

$ cat build.xml 








$ ant test
Buildfile: /home/pini/debian/jxgrabkey-0.3.2/misc/Ant/build.xml

test:
 [exec] Result: 127

BUILD SUCCESSFUL
Total time: 0 seconds

Moreover, ant reports BUILD SUCCESSFUL while it is obviously unsuccessful.

This bug causes jxgrabkey to FTBFS on kfreebsd-i386. Full log at [1].

[1] 
https://buildd.debian.org/status/fetch.php?pkg=jxgrabkey=kfreebsd-i386=0.3.2-9=1484086920=log

BTW I don't understand why kfreebsd-i386/unstable still has ant 1.9.6-1 :/

Thanks,

_g.

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#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#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#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#850799: italc: please make it multiarch ready

[Mike Gabriel]

Hi Gianfranco,

On  Di 10 Jan 2017 10:17:48 CET, Gianfranco Costamagna wrote:


source: italc
version: 1:3.0.2.90+dfsg1-1
severity: wishlist
tags: patch

Hello, the following patch should make the package multiarch ready

can you please apply/test the package?
Note: I don't know if the change in rules file is needed or not, I don't get
why you override shlibdeps that way :)

G.


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?

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



pgpEHqTBuxgFt.pgp
Description: Digitale PGP-Signatur

Bug#851059: Please provide instructions to use with current opennssl version

[Yvan Masson]

Package: easy-rsa
Version: 2.2.2-2

Dear maintainer,

easy-rsa currently does not provide openssl configuration file for the
openssl version available in testing (1.1.*).

This makes the "whichopensslcnf" script to fail on Stretch, except if
the file openssl.cnf is manually created. It seems it can be a copy of
openssl-1.0.0.cnf but I can not tell if the settings are appropriated
for openssl 1.1.*.

Could you either:
- at least modify /usr/share/doc/easy-rsa/README.Debian to give
instructions for users
- or best provide a configuration file for openssl 1.1.*, adapt
whichopensslcnf script, and update /usr/share/doc/easy-rsa/README-
2.0.gz

Thanks for your work,
Yvan

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

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#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#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#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#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#850855: [rtkit] rtkit daemon fails to start

[Felipe Sateler]

On 11 January 2017 at 13:05, Bogdan Vatra  wrote:
> On miercuri, 11 ianuarie 2017 12:40:23 EET Felipe Sateler wrote:
>> On 11 January 2017 at 12:37, Bogdan Vatra  wrote:
>> > On miercuri, 11 ianuarie 2017 10:12:00 EET Felipe Sateler wrote:
>> >> Control: tags -1 moreinfo unreproducible
>> >>
>> >> On 11 January 2017 at 04:59, Bogdan Vatra  wrote:
>> >> > On miercuri, 11 ianuarie 2017 09:48:16 EET Bogdan Vatra wrote:
>> >> >> On marți, 10 ianuarie 2017 17:20:28 EET Felipe Sateler wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On 10 January 2017 at 16:05, Bogdan Vatra 
>> >
>> > wrote:
>> >> >> > > Package: rtkit
>> >> >> > > Version: 0.11-4
>> >> >> > > Severity: important
>> >> >> > >
>> >> >> > > --- Please enter the report below this line. ---
>> >> >> > >
>> >> >> > > This bug is pretty annoying because it makes pulseaudio unusable
>> >> >> > > (see
>> >> >> > > #850806).
>> >> >> >
>> >> >> > > Here are the logs:
>> >> >> > 
>> >> >> >
>> >> >> > > -- Unit rtkit-daemon.service has begun starting up.
>> >> >> > > ian 10 21:00:32 zmeu rtkit-daemon[19342]: Failed to connect to
>> >> >> > > system
>> >> >> > > bus:
>> >> >> > > Failed to connect to socket /var/run/dbus/system_bus_socket: No su
>> >> >> >
>> >> >> > This suggests that dbus is not running. Could that be the case? Do
>> >> >> > other dbus-interacting apps misbehave?
>> >> >>
>> >> >> I think that's a wrong message ... because :
>> >> >>
>> >> >> $ ls -l /var/run/dbus/system_bus_socket
>> >> >> srw-rw-rw- 1 root root 0 ian 10 09:42 /var/run/dbus/system_bus_socket
>> >> >>
>> >> >> That file exists and dbus works fine (all my KDE/Qt apps works ok).
>> >> >
>> >> > If I manually run "/usr/lib/rtkit/rtkit-daemon" it works just fine...
>> >> > The only problem is when I start it with "systemctl start rtkit-
>> >> > daemon.service".
>> >>
>> >> Weird. Could you repeat the same with the daemon as started by systemd?
>> >>
>> >> Use `systemctl edit --full rtkit-daemon` to edit the ExecStart line.
>> >
>> > It is the same thing ... :
>> > [...]
>> > ExecStart=/usr/lib/rtkit/rtkit-daemon
>> > [...]
>> > Actually I was inspired from that file to exec
>> > "/usr/lib/rtkit/rtkit-daemon" manually :).
>>
>> Sorry, I was not clear. I meant stracing the daemon.
>
> Attached the log.

Hmm. I guess it's not my day, I can't explain myself :(

Please run the rtkit-daemon under strace, with systemd: edit the
systemd service like so:

ExecStart=/usr/bin/strace -o /tmp/strace.log -ff /usr/lib/rtkit/rtkit-daemon

then do a `systemctl daemon-reload` and a restart of the rtkit-daemon.
Then please attach the /tmp/strace.log.$PID file.



-- 

Saludos,
Felipe Sateler

Bug#850948: [Piuparts-devel] Bug#850948: needrestart, piuparts: needrestart hangs -> piupart fails -> debian-design blocked

[Holger Levsen]

control: reassign -1 needrestart
control: merge -1 826044
thanks

On Wed, Jan 11, 2017 at 03:25:10PM +0100, Jonas Smedegaard wrote:
> Package: needrestart,piuparts
> Severity: serious
 
no. this is definitly not a serious bug in piuparts.

> This bugreport is tracking debian-design not entering testing.

then this bug report would be more appropriate against release.d.o but
Andreas already filed this bug :)
 

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#850446: handbrake: New upstream release 1.0.1

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Dienstag, den 10.01.2017, 20:30 +0100 schrieb Sebastian Ramacher:
> Please push the changes if possible.

Just pushed.

 - Fabian
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAlh2YJ4ACgkQy+qOlwzN
Wd8Nhw/+LLk4Vk8ocl5V03oE0V3lccyzV9wWy4EortadLk6wfXNQFPshWUkqmeZI
1uKJejQCOB3BM+fm7jgS5Ipe9brvSNui3uQIQMwrwuDw5kefHrjwentYwbxOgpet
UL8Y/01KMjPvUhiWrh/t3vAj91StBkXrvAoofbRl4mTOAbF/KZQjvT0MrHJ5nVf2
B33o8Xs8ayvYuv1pUm0B1MfRopKYZAYFyE05OZX1+AOSsUaFyde64FLLaV3b8Ssd
ZdBgTHQ3fNMfp6y2l09JA5LrQ8ecta1YpuBvB6PRw2Wge2uz04CEFMnx3qSnFAPD
giQQzEFrbUvPjwlifPTaKMdKIAvydz3NBG4iOCrkgyO24zipITmOd6guS7WFZ+oE
7Jw6CfswVbfTkzPfdhZuI7i0SMkyMqqWCNGcBJoTpNyC4FA1EyaJPATdFqp88fa1
tc+7Mt1VmljMoLvevA4ALX0Xw0oJZuC8rk4Np7VAIoI1xUxzVV2Zqoliy34fynLm
p5aSIWN3crz0CJJRihZmIrNJofkd9pZJlEKofin41fucIx4RhoZPP45Xsv/N/Ue1
a9NMM00q8Fi7v0sX82R2Oba3UeskFYULkHcmtqVoT0Cf93zK9ZlU8b/E7/GejlMS
T+cBqS9flJLgPbRgiDi3Owx+vvnPmSL3coUh5XR7jmd294i0sIw=
=VIj2
-END PGP SIGNATURE-