Bug#833937: [icedove] regression: Very frequent segfaults

[Carsten Schoenert]

Am 10.08.2016 um 18:18 schrieb Philipp Klaus Krause:
[...]
>> 833532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833532
>> 833591: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833591
>> 833635: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833635
> 
> These bug reports are about a segfault on startup. My segfaul thappens
> later.
> 
>> 833698: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833698
> 
> This bug report is about a segfault on the first read from IMAP folders.
> My segfaul thappens later.
> 
>> 833864: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833864
>>
> 
> This bug report is about a segfault that happens deterministically upon
> some user action. My segfault seems to happens independent of user action.
[...]

And there is no other report that fits your regression? I won't believe
this.

I count 8 bugs with segfaults about Icedove >= 45.1.0

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=id-crash-45.1.0;users=c.schoen...@t-online.de

If all those reports don't correlate your issue than reopen this report
and please create a gdb log with some explanation why other bug reports
aren't the same.
Try to take make a look from my/our side. We have over 200 bug reports
with various things. Every new report with a existing issue is just
taking times from real fixing issues as we need to go to every single
report and collect identical reports and prepare merging and fixing.
There is reason why reportbug is showing existing bug reports right
after the start.

-- 
Regards
Carsten Schoenert

Bug#833653: ITP: r-cran-gsl -- GNU R package to interface the GNU GSL

[Bart Martens]

noowner 833653
retitle 833653 r-cran-gsl: suggested switch to different upstream
reassign 833653 r-cran-gsl
severity 833653 wishlist
stop


Hi Dirk,

There is already a package named r-cran-gsl in Debian.
https://packages.qa.debian.org/r/r-cran-gsl.html

So I'm reassigning your ITP to the existing package in Debian so the current
maintainer can consider a switch to your implementation.

Regards,

Bart Martens

Bug#827506:

[Erika D Glaub]

Hope you got my Letter

Bug#820434: About #820434

[Peter Spiess-Knafl]

Thank you!

On 08/07/2016 06:51 PM, Stephen Kitt wrote:
> On Sat, 6 Aug 2016 21:32:43 +0200, Stephen Kitt  wrote:
>> The attached symbols file should do the trick. (I've included symbols for
>> 1.6.5 and 1.7.2.) Simply save it in the debian directory of the libjsoncpp
>> source package, it will be picked up during the build. In the future, if the
>> symbols change the build will fail and produce a diff for you to apply to
>> the symbols file.
> 
> Better yet, the attached version is built with g++-6; some virtual symbols
> are no longer generated (see the #MISSING# entries).
> 
> Regards,
> 
> Stephen
> 



signature.asc
Description: OpenPGP digital signature

Bug#832704: RFS: nixnote2/2.0~beta8+20160727+ds-1 [ITP] -- Open Source Evernote client

[Boyuan Yang]

> I can't sponsor the upload, but I hope the following review is useful to
> you.

Thank you very much for your detailed review. I would like to explain
those problems here for you and anyone who might be interested:

> Since I am not familiar with Java packaging, it would be advisable to
> ask on the Debian java packaging group mailing list for someone to
> review those parts of the package.

OK,  I will take a try.

> Must-fixes
> --
>
> Is the GitHub repo that this package is based on a fork of Nevernote?  I
> think you should change the Homepage: field to point at the GitHub
> repo.  Or are they controlled by the same person?

They are controlled by the same person and actually they are the *same
project*. Actually the author is still using nevernote page on
Sourceforge to distribute pre-built nixnote2 packages.

> Your version number indicates that you are packaging a beta release.
> Generally, only full upstream releases are uploaded to Debian unstable,
> rather than testing releases/release candidates.  Is there some good
> reason for using this version?

Upstream is keeping "beta" string in version for several years and
there is no sign that he/she will make a "non-beta" release in near
future. However the function of nixnote2 is complete and everything
works well now. Personally I think it is suitable for the release.

> The description of the "exclude opencv linking" doesn't explain why
> opencv support is disabled "for now".  Please explain.

In upstream trunk the opencv-related functions are disabled and
removed. The developer intends to make it into a plugin, so I disabled
related builds. What's more, I noticed that Debian is preparing
opencv2-3 transition, so my personal preference is to pack the
opencv-related plugin after the transition is completed.

> Vcs-* should point at your packaging repository, not the upstream git
> repository.

Yes. I am pointing to my packaging repository.

> You should remove the "ignore-branch" and "builder" settings from
> gbp.conf.  Those should only be set in ~/.gbp.conf or /etc/gbp.conf.

Thanks. I will fix it later.

> I can't try building and installing this package because I can't get a
> correct orig tarball.  The version on mentors seems to be out-of-date,
> and the version the watch file downloads conflicts with your
>  repo (which is what I'm looking
> at).  How can I get the correct orig tarball?

Really sorry I did not try to build from mentors. I will look into it
afterwards.

> Suggested improvements
> --
>
> There are a lot of build-dependencies.  It would be nice to run
> `wrap-and-sort -abst`.

Sure I will fix it.

> README.Debian is meant for users, but what you have written in there is
> only really relevant to Debian contributors.  Perhaps rename it to
> README.source, or just remove it.  You could also cite the relevant
> section of policy (and the version of policy in which the section had
> that number).

Thanks, I will try.

> The watch file looks like it will only work for the current version,
> because the repack suffix contains a part of the current version
> string.  Could it be made more general?

Sure. Will be fixed after next upstream release.

> Could you explain why you Recommends: mimetex and Suggests: cups?

Mimetex is used for latex support of evernote notes, as described by the author.
Cups is needed for note printing, but it is totally fine not to
install it if the user do not need to print.

> You're installing README.md but this file contains no useful
> information.  The README.txt file looks more useful.  Does that get
> installed to the help/ dir?  I couldn't tell without building the
> package, sorry!

I did not install README.txt, since this file mainly describes the situation
of source (not the binary). Should I install it anyway?

> I'm not sure you need to override dh_installchangelogs.  It usually
> detects filenames like 'changelog.txt'.  But I might be wrong.
>
> At debhelper compat 9, I think that you could remove a lot of lines from
> your rules file.  For example, you probably don't need these lines:
>
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/default.mk
> include /usr/share/dpkg/buildflags.mk

Thanks for these advices, I will try it out.

Bug#833698: Icedove 1:45.2.0-2+b1 (Debian Testing) SegFault

[John Talbut]

On Tue, 09 Aug 2016 22:48:00 + =?UTF-8?B?VmlrdG9yIErDpGdlcnNrw7xwcGVy?=
  wrote:

Everybody who reads only this bug report, please consider my workaround
mentioned in bug 833532:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833532#50

Thanks Viktor.  I have set "javascript.options.baselinejit" to "false" 
and icedove is now working.

Bug#828976: krb5kdc: segfault

[Benjamin Kaduk]

On Sun, 31 Jul 2016, Benjamin Kaduk wrote:

> In particular, upstream developer Greg Hudson notes that when you set the
> string attribute by hand in that fashion, the double quotes are eaten by
> the parser, so in fact the string that is set is invalid JSON.  (You could
> confirm with the 'getstrs' kadmin command.)

Just to note it here, the example in the documentation has been fixed in
the master branch as of
https://github.com/krb5/krb5/commit/3e319b1f93f75a3bab86425221f2bcbf5603f3f9
and the updated documentation should appear in the next 1.14 release.

-Ben

Bug#822438: a hint at the source of the problem

[Zenaan Harkness]

> Here's a hint at the source of the problem:
> http://www.in-ulm.de/~mascheck/locale/
> "
> XFree86 Xlib calls setlocale(3), but with values in
> /usr/X11R6/lib/X11/locale/. If you - particularly after an upgrade - get
> a "Warning: locale not supported by Xlib, locale set to C", then have a
> look into locale.alias in that directory and adjust it, in case.
> (Details from Olav Kvittem.)
> "
> 
> ...
> 
> The /usr/share/X11/locale dir contains these files:
> compose.dir
> locale.alias
> locale.dir

adding the requisite/ corresponding lines for my custom chosen locale
into each of the above 3 files, namely
/usr/share/X11/locale/compose.dir
/usr/share/X11/locale/locale.alias
/usr/share/X11/locale/locale.dir

handles the X/X11/xterm etc problem - I think in particular it is the
/usr/share/X11/locale/locale.alias
file which must be updated for xlib to not spew out its error.

Works for me.

Conclusion for me: these files either need to be auto updated by
/usr/sbin/locale-gen , or a big command line WARNING ought be displayed
suggesting to the end user who has changed (customized) their locale, to
update those files to ensure X can find the specifics/ overridden data
thingies that it needs. Would be nice to have.

Bug#833955: atop: /etc/init.d/atop* assume that /var/lock/subsys exists

[Marc Haber]

On Thu, Aug 11, 2016 at 04:10:54AM +0200, Vincent Lefevre wrote:
> On 2016-08-10 22:38:27 +0200, Marc Haber wrote:
> > On Wed, Aug 10, 2016 at 10:17:07PM +0200, Vincent Lefevre wrote:
> > > Here the /var/lock/subsys directory doesn't exist, yielding an error
> > > message, and the file is not created.
> > 
> > Can you try changing that to /run/lock/subsys/atop{acctd} respectively
> > and re-check? If so, I'm going to patch the init scripts accordingly.
> 
> I have not tried, but I don't see how this would solve the problem
> since these are equivalent paths: /var/lock is a symbolic link to
> /run/lock. And indeed there is no /run/lock/subsys directory.
> 
> Replacing /var/lock by /run/lock would be better but would not solve
> the problem here.

Then we're going to go to the least common denominator and
/run/lock/atop{acctd}. No need to discuss this.

> What is the goal of theses .../subsys commands in /etc/init.d/atop*?

No idea. Those scripts are upstream's.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#833981: needrestart: --verbose option to complement -v

[Paul Wise]

Package: needrestart
Severity: wishlist

I often use --verbose out of habit because it is more standard than -v,
which can do different things in different programs, while --verbose is
more likely to mean the same thing everywhere. Unfortunately
needrestart doesn't support --verbose, it would be nice to have it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#833419: crashes computer

[Sergio Durigan Junior]

On Wednesday, August 10 2016, 積丹尼 Dan Jacobson wrote:

> OK I installed
> https://wiki.debian.org/NvidiaGraphicsDrivers
> # nvidia-detect
> Detected NVIDIA GPUs:
> 00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51G [GeForce 
> 6100] [10de:0242] (rev a2)
> Checking card:  NVIDIA Corporation C51G [GeForce 6100] (rev a2)
> Your card is only supported up to the 304 legacy drivers series.
> It is recommended to install the
> nvidia-legacy-304xx-driver
> package.
>
> and now everything is OK for my machine with the NVIDIA card. But that
> still leaves my Thinkpad r50e with the problem.

Oh, so you see the black screen on a computer without an NVIDIA card?
Could you send the logs for that computer, please?

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#833934: workaround

[Kyle Bentley]

>From the other merged threads, setting

javascript.options.baselinejit = false

seems to be a useful workaround until the patch comes out.

Bug#832704: RFS: nixnote2/2.0~beta8+20160727+ds-1 [ITP] -- Open Source Evernote client

[Sean Whitton]

control: tag -1 +moreinfo
control: owner -1 !

Hello,

Thanks for packaging this.  Org-mode >> Evernote but enabling people to
use the latter on Debian might be a useful gateway drug ... and a lot of
people say that Org-mode is the gateway drug for Emacs proper ;)

I can't sponsor the upload, but I hope the following review is useful to
you.  I've split it into two sections: things that I would consider
must-fixes before an upload to Debian, and suggested improvements.  The
latter aren't strictly necessary, but they would help demonstrate to a
potential sponsor that you are committed to maintaining this package in
Debian.

Since I am not familiar with Java packaging, it would be advisable to
ask on the Debian java packaging group mailing list for someone to
review those parts of the package.

Must-fixes
--

Is the GitHub repo that this package is based on a fork of Nevernote?  I
think you should change the Homepage: field to point at the GitHub
repo.  Or are they controlled by the same person?

Your version number indicates that you are packaging a beta release.
Generally, only full upstream releases are uploaded to Debian unstable,
rather than testing releases/release candidates.  Is there some good
reason for using this version?

The description of the "exclude opencv linking" doesn't explain why
opencv support is disabled "for now".  Please explain.

Vcs-* should point at your packaging repository, not the upstream git
repository.

You should remove the "ignore-branch" and "builder" settings from
gbp.conf.  Those should only be set in ~/.gbp.conf or /etc/gbp.conf.

I can't try building and installing this package because I can't get a
correct orig tarball.  The version on mentors seems to be out-of-date,
and the version the watch file downloads conflicts with your
 repo (which is what I'm looking
at).  How can I get the correct orig tarball?

Suggested improvements
--

There are a lot of build-dependencies.  It would be nice to run
`wrap-and-sort -abst`.

README.Debian is meant for users, but what you have written in there is
only really relevant to Debian contributors.  Perhaps rename it to
README.source, or just remove it.  You could also cite the relevant
section of policy (and the version of policy in which the section had
that number).

The watch file looks like it will only work for the current version,
because the repack suffix contains a part of the current version
string.  Could it be made more general?

Could you explain why you Recommends: mimetex and Suggests: cups?

You're installing README.md but this file contains no useful
information.  The README.txt file looks more useful.  Does that get
installed to the help/ dir?  I couldn't tell without building the
package, sorry!

I'm not sure you need to override dh_installchangelogs.  It usually
detects filenames like 'changelog.txt'.  But I might be wrong.

At debhelper compat 9, I think that you could remove a lot of lines from
your rules file.  For example, you probably don't need these lines:

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk
include /usr/share/dpkg/buildflags.mk

Since I couldn't actually build the package, that's all for now!

--
Sean Whitton


signature.asc
Description: PGP signature

Bug#826718: Fwknop 2.6.9 packaged

[Michael Rash]

On Wed, Aug 10, 2016 at 1:52 PM, Franck Joncourt 
wrote:

> Hi Santiago,
>
> Thanks for your quick reply. I did add the deb files to the bug report to
> provide them to users since it has been a while since the last real update
> of fwknop on Debian.
>
> I am almost ready to push new files to debian mentor (updated package with
> QA upload + patches + lintian fixes) - I have just detected a minor problem
> with hardening flags. I hoped I could achieve this before going on holidays
> but I currently run out of time. I will continue at the end of August and I
> would be delighted if you or Gregor could sponsor the upload if you have
> time.
>
> I would like to maintain the fwknop package again but with my family and
> my job it is sometimes difficult to find the time to do it correctly. I may
> be unavailable for weeks and that is why I resigned.
>

Hello Franck,

Just wanted to thank you for putting together the new package...

--Mike



>
> Best regards,
>
> --
> Franck Joncourt
>

Bug#833419: crashes computer

[積丹尼 Dan Jacobson]

severity 833419 normal
retitle 833419 midori gives black screen on one of my couputers
thanks

OK I installed
https://wiki.debian.org/NvidiaGraphicsDrivers
# nvidia-detect
Detected NVIDIA GPUs:
00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51G [GeForce 
6100] [10de:0242] (rev a2)
Checking card:  NVIDIA Corporation C51G [GeForce 6100] (rev a2)
Your card is only supported up to the 304 legacy drivers series.
It is recommended to install the
nvidia-legacy-304xx-driver
package.

and now everything is OK for my machine with the NVIDIA card. But that
still leaves my Thinkpad r50e with the problem.

Bug#822438: a hint at the source of the problem

[Zenaan Harkness]

Here's a hint at the source of the problem:
http://www.in-ulm.de/~mascheck/locale/
"
XFree86 Xlib calls setlocale(3), but with values in
/usr/X11R6/lib/X11/locale/. If you - particularly after an upgrade - get
a "Warning: locale not supported by Xlib, locale set to C", then have a
look into locale.alias in that directory and adjust it, in case.
(Details from Olav Kvittem.)
"

...

The /usr/share/X11/locale dir contains these files:
compose.dir
locale.alias
locale.dir

Which may also need to be updated if/when one creates a custom locale.

Note also:
/etc/locale.gen
/etc/locale.conf
/etc/locale.alias
/etc/environment


At the end of this tutorial:
http://askubuntu.com/questions/21316/how-can-i-customize-a-system-locale

is the suggestion to add your custom locale (or make sure the locale you
wish to use is found in there I guess) to this file:
/usr/share/i18n/SUPPORTED


Yet, after all the above have been updated, still no go starting a new
xterm, still the error:
"Warning: locale not supported by Xlib, locale set to C"

I guess next step is to try logout/login, or reboot.

Bug#833587: xmonad-contrib: XMonad.Hooks.ManageDocks buggy in release 0.12

[Sean Whitton]

control: tag -1 +moreinfo

Hello,

On Sat, Aug 06, 2016 at 04:23:02PM +0200, Jonas Smedegaard wrote:
> According to
> https://wiki.haskell.org/Xmonad/Notable_changes_since_0.11#.2AURGENT.2A_Bug_in_0.12_ManageDocks
> there is a bug in release 0.12 needing cherry-picking from git.

I can't reproduce this bug locally.  However, the attached patch is all
of upstream's recent commits that look to concern ManageDocks.

If anyone is seeing this bug, please apply this patch to the source
package and let us know if it fixes the problem.

To examine the individual commits I cherry-picked, see branch
fix-managedocks of repo ,
from which I generated the patch.

-- 
Sean Whitton
From 6646f5944d945284106cef1d8d811ca0496d434e Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sun, 3 Jan 2016 12:37:16 +0300
Subject: [PATCH] fix xmonad/xmonad#21

The following commits, from various authors in the upstream git
repository, are squashed into this commit:

fix build with older ghc

never query all the tree in X.H.ManageHook

minor fixes in X.H.ManageDocks

fix X.H.PositionStoreHooks for new signature of calcGaps

add calcGapForAll for other modules

typo

add new dock if it hasn't strut properties

handle PropertyNotify events on docks

add docksStartupHook for handling docks when restarted

handle docks remove correctly

fix slowdown when removing docks

some minor fixes in X.H.ManageDocks

send all docks messages only from event hook

Update XMonad.Config.Desktop for 0.12 ManageDocks
---
 XMonad/Actions/FloatSnap.hs|   4 +-
 XMonad/Config/Desktop.hs   |   5 +-
 XMonad/Config/Gnome.hs |   3 +-
 XMonad/Config/Kde.hs   |   3 +-
 XMonad/Config/Mate.hs  |   3 +-
 XMonad/Config/Xfce.hs  |   3 +-
 XMonad/Hooks/ManageDocks.hs| 122 +
 XMonad/Hooks/PositionStoreHooks.hs |   8 ++-
 XMonad/Layout/DecorationAddons.hs  |   4 +-
 9 files changed, 116 insertions(+), 39 deletions(-)

diff --git a/XMonad/Actions/FloatSnap.hs b/XMonad/Actions/FloatSnap.hs
index baf511f..2d04fd3 100644
--- a/XMonad/Actions/FloatSnap.hs
+++ b/XMonad/Actions/FloatSnap.hs
@@ -33,7 +33,7 @@ import Data.Maybe (listToMaybe,fromJust,isNothing)
 import qualified XMonad.StackSet as W
 import qualified Data.Set as S
 
-import XMonad.Hooks.ManageDocks (calcGap)
+import XMonad.Hooks.ManageDocks (calcGapForAll)
 import XMonad.Util.Types (Direction2D(..))
 import XMonad.Actions.AfterDrag
 
@@ -291,7 +291,7 @@ getSnap horiz collidedist d w = do
 screen <- W.current <$> gets windowset
 let sr = screenRect $ W.screenDetail screen
 wl = W.integrate' . W.stack $ W.workspace screen
-gr <- fmap ($sr) $ calcGap $ S.fromList [minBound .. maxBound]
+gr <- fmap ($sr) $ calcGapForAll $ S.fromList [minBound .. maxBound]
 wla <- filter (collides wa) `fmap` (io $ mapM (getWindowAttributes d) $ filter (/=w) wl)
 
 return ( neighbours (back wa sr gr wla) (wpos wa)
diff --git a/XMonad/Config/Desktop.hs b/XMonad/Config/Desktop.hs
index add5548..088aef8 100644
--- a/XMonad/Config/Desktop.hs
+++ b/XMonad/Config/Desktop.hs
@@ -165,9 +165,10 @@ import qualified Data.Map as M
 --
 
 desktopConfig = ewmh def
-{ startupHook = setDefaultCursor xC_left_ptr
+{ startupHook = setDefaultCursor xC_left_ptr <+> docksStartupHook <+> startupHook def
 , layoutHook  = desktopLayoutModifiers $ layoutHook def
-, manageHook  = manageHook def <+> manageDocks
+, manageHook  = manageDocks <+> manageHook def
+, handleEventHook = docksEventHook <+> handleEventHook def
 , keys= desktopKeys <+> keys def }
 
 desktopKeys (XConfig {modMask = modm}) = M.fromList $
diff --git a/XMonad/Config/Gnome.hs b/XMonad/Config/Gnome.hs
index 3ab7270..aa506e1 100644
--- a/XMonad/Config/Gnome.hs
+++ b/XMonad/Config/Gnome.hs
@@ -18,7 +18,8 @@ module XMonad.Config.Gnome (
 -- $usage
 gnomeConfig,
 gnomeRun,
-gnomeRegister
+gnomeRegister,
+desktopLayoutModifiers
 ) where
 
 import XMonad
diff --git a/XMonad/Config/Kde.hs b/XMonad/Config/Kde.hs
index bda58a4..8046804 100644
--- a/XMonad/Config/Kde.hs
+++ b/XMonad/Config/Kde.hs
@@ -17,7 +17,8 @@ module XMonad.Config.Kde (
 -- * Usage
 -- $usage
 kdeConfig,
-kde4Config
+kde4Config,
+desktopLayoutModifiers
 ) where
 
 import XMonad
diff --git a/XMonad/Config/Mate.hs b/XMonad/Config/Mate.hs
index d54f03c..16b1cce 100644
--- a/XMonad/Config/Mate.hs
+++ b/XMonad/Config/Mate.hs
@@ -20,7 +20,8 @@ module XMonad.Config.Mate (
 -- $usage
 mateConfig,
 mateRun,
-mateRegister
+mateRegister,
+desktopLayoutModifiers
 ) where
 
 import XMonad
diff --git a/XMonad/Config/Xfce.hs b/XMonad/Config/Xfce.hs
index c6bca4c..713b975 100644
--- a/XMonad/Config/Xfce.hs
+++ b/XMonad/Config/Xfce.hs
@@ -16,7 +16,8 @@
 module XMonad.Config.Xfce (
 -- * Usage
 -- $usage

Bug#833508: xbacklight reports "No outputs have backlight property"

[Sebastien Delafond]

Package: xbacklight
Version: 1.2.1-1
Followup-For: Bug #833508

Dear Maintainer,

same problem here. I can manually write to
/sys/class/backlight/intel_backlight/brightness fine.

I use xserver-xorg-video-intel 2:2.99.917+git20160706-1.

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

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

Versions of packages xbacklight depends on:
ii  libc6  2.23-4
ii  libxcb-randr0  1.11.1-1
ii  libxcb-util0   0.3.8-3
ii  libxcb11.11.1-1

xbacklight recommends no packages.

xbacklight suggests no packages.

-- no debconf information

Bug#822438: debian locales - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822438

[Zenaan Harkness]

Hi Michael, I just tried to subscribe to this bug, it affects custom
locales too, see e.g.:
http://askubuntu.com/questions/21316/how-can-i-customize-a-system-locale

Have you solved this yet?

In my case, I create a custom locale, as per instructions above, set
locale to my custom locale:

# cat /etc/locale.conf  /etc/environment 
LANG=zen.UTF-8
LC_TIME="zen.UTF-8"

Bug#833967: texlive-bibtex-extra should conflict with biblatex and biblatex-dw

[Norbert Preining]

tags 833967 + pending
thanks

> least conflict with them to prevent having two different versions
> installed in parallel.

Thanks, fixed in git repo.

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#833536: pkg-haskell-tools: dht should allow uploading by FTP

[Sean Whitton]

control: tag -1 +patch
control: owner -1 !

Hello,

On Wed, Aug 10, 2016 at 09:36:37PM +0200, Sven Bartscher wrote:
> I can't remember saying dht should default to SSH and rather think that
> dht should honour the default set in dput.cf (see my other post for a
> brief description of how to do that).

I just read your message again; sorry for misrepresenting your view.

I've implemented a fix for this bug on the dput branch of the
pkg-haskell-tools repository.  I would be grateful if some DD making
some uploads would test it.  I don't have any uploads to make for the
packages I have DM rights for.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833887: vlc: Does not install app icon

[Matthias Klumpp]

2016-08-11 3:20 GMT+02:00 Jeremy Bicha :
> On Wed, Aug 10, 2016 at 8:55 PM, Matthias Klumpp  wrote:
>> It's definitely showing up in Debian Testing, I just checked that. It
>> is visible in GNOME Software and has all the data when I run
>> `appstreamcli get vlc.desktop --details` too.
>> (the only difference here might be that I am running GNOME Software
>> git master, but that really shouldn't have an impact).
>
> Could you please check with the gnome-software that's in testing?
> Although this bug was noticed on Ubuntu, I did confirm that vlc is
> missing in Debian Testing before filing this bug.

I shows up with all data using GNOME Software from testing here...
Can you find it with appstreamcli?
Does running `apt update` help?

> And how about getting gnome-software updated in Debian? 3.20.4 has
> quite a few bug fixes.

It's slightly outdated because I only have limited time and a lot of
projects and packages to care for - updating GS will happen
eventually, as soon as I find the time.

>> A short-term fix will be having someone (Laney) reprocess the vlc
>> package and checking that Ubuntu's Contents.gz file is up-to-date.
>
> I assume you'll be following up with Laney about that.

Jup, there are some Ubuntu-specific things missing in asgen still
(langpacks support), as soon as that is in place Ubuntu can use the
new solution.
I am working with Laney on that (or rather, Laney is working on that ^^)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#833955: atop: /etc/init.d/atop* assume that /var/lock/subsys exists

[Vincent Lefevre]

On 2016-08-10 22:38:27 +0200, Marc Haber wrote:
> On Wed, Aug 10, 2016 at 10:17:07PM +0200, Vincent Lefevre wrote:
> > Here the /var/lock/subsys directory doesn't exist, yielding an error
> > message, and the file is not created.
> 
> Can you try changing that to /run/lock/subsys/atop{acctd} respectively
> and re-check? If so, I'm going to patch the init scripts accordingly.

I have not tried, but I don't see how this would solve the problem
since these are equivalent paths: /var/lock is a symbolic link to
/run/lock. And indeed there is no /run/lock/subsys directory.

Replacing /var/lock by /run/lock would be better but would not solve
the problem here.

> As all my systems are systemd, the init scripts are kind of
> undertested. Your efforts are appreciated.

FYI, I have an Ubuntu 14.04 machine, thus with upstart, and there is
no /run/lock/subsys either.

It seems that /run/lock/subsys is specific to systemd and created
via /usr/lib/tmpfiles.d/legacy.conf (part of systemd), which
contains in particular:


# /run/lock/subsys is used for serializing SysV service execution, and
# hence without use on SysV-less systems.

d /run/lock/subsys 0755 root root -


See the tmpfiles.d(5) man page for details.

What is the goal of theses .../subsys commands in /etc/init.d/atop*?
If systemd specific, shouldn't they run only if the /run/lock/subsys
directory exists?

  if [ -d /run/lock/subsys ]; then
...
  fi

Note also that the following searches return no results:

  https://codesearch.debian.net/search?q=run+lock+subsys
  https://codesearch.debian.net/search?q=var+lock+subsys

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

Bug#833944: [/master] remove-msse4.2.patch: Backport upstream commit removing -msse4.2 commandline option from configure script (Closes: #833944)

[Andrew Starr-Bochicchio]

tag 833944 pending
thanks

Date: Wed Aug 10 20:23:24 2016 -0400
Author: Andrew Starr-Bochicchio 
Commit ID: 4f361f8226d2169596de53fbc37c173f361bdf03
Commit URL: 
http://anonscm.debian.org/gitweb/?p=collab-maint/libtorrent-rasterbar.git;a=commitdiff;h=4f361f8226d2169596de53fbc37c173f361bdf03
Patch URL: 
http://anonscm.debian.org/gitweb/?p=collab-maint/libtorrent-rasterbar.git;a=commitdiff_plain;h=4f361f8226d2169596de53fbc37c173f361bdf03

remove-msse4.2.patch: Backport upstream commit removing -msse4.2 
commandline option from configure script (Closes: #833944)

  

Bug#833944: [/master] Fix builds on arches where the multiarch tuple (i386-*) and the GNU tuple (i686-*) differ (Closes: #833944).

[Andrew Starr-Bochicchio]

tag 833944 pending
thanks

Date: Wed Aug 10 20:12:37 2016 -0400
Author: Andrew Starr-Bochicchio 
Commit ID: bbcec1e57452e40864b6300644d04ae56c25f752
Commit URL: 
http://anonscm.debian.org/gitweb/?p=collab-maint/libtorrent-rasterbar.git;a=commitdiff;h=bbcec1e57452e40864b6300644d04ae56c25f752
Patch URL: 
http://anonscm.debian.org/gitweb/?p=collab-maint/libtorrent-rasterbar.git;a=commitdiff_plain;h=bbcec1e57452e40864b6300644d04ae56c25f752

Fix builds on arches where the multiarch tuple (i386-*) and the GNU tuple 
(i686-*) differ (Closes: #833944).

  

Bug#801080: Double->float->int

[T. Joseph Carter]

It may be a bug in gcc that is causing the problem, but code that is 
sloppy about types is never good coding practice.  If the scale 
values are calculated as doubles, then double should be the type for 
the variable.  That's an upstream issue, but it's affecting Debian 
users and there's a single line patch for it.


Just my $0.02, unasked for but offered anyway.  :)

Joseph

Bug#833647: [Letsencrypt-devel] Bug#833647: acme-tiny: Agreement URL does not match the current one

[Jeremías Casteglione]

Hi Elena:

On Sun, 07 Aug 2016 15:42:22 +0200
Elena ``of Valhalla''  wrote:

> Package: acme-tiny
> Version: 20160326-1
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> Trying to run acme-tiny today resulted in:
> 
> ValueError: Error registering: 400 b'{\n  "type":
> "urn:acme:error:malformed",\n  "detail": "Provided agreement URL
> [https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf] does
> not match current agreement URL
> [https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]",\n
> "status": 400\n}'
> 
> This has already been fixed upstream with the following commit:
> https://github.com/diafygi/acme-tiny/commit/ecd26b1e784973e5b52d5a308964a8e29a6cf207

Thanks for reporting this!

> so updating the package to the current version should fix the issue (if
> I understood correctly upstream isn't doing releases, right?)

That's correct, upstream is not doing releases, there are some issues
talking about setuptools integration and such, but none of them was merged
by upstream, not yet at least.

We use YearMonthDay from the latest commit for the Debian version. Until
there's an upstream release, when we're planning to use something like
epoch:upstream-version (this is also documented in debian/watch file).

> 
> For reference, I've found the above commit via this upstream issue:
> https://github.com/diafygi/acme-tiny/issues/135
> 

Cheers,


-- 
Jeremías

Bug#833887: vlc: Does not install app icon

[Jeremy Bicha]

On Wed, Aug 10, 2016 at 8:55 PM, Matthias Klumpp  wrote:
> It's definitely showing up in Debian Testing, I just checked that. It
> is visible in GNOME Software and has all the data when I run
> `appstreamcli get vlc.desktop --details` too.
> (the only difference here might be that I am running GNOME Software
> git master, but that really shouldn't have an impact).

Could you please check with the gnome-software that's in testing?
Although this bug was noticed on Ubuntu, I did confirm that vlc is
missing in Debian Testing before filing this bug.

And how about getting gnome-software updated in Debian? 3.20.4 has
quite a few bug fixes.

> A short-term fix will be having someone (Laney) reprocess the vlc
> package and checking that Ubuntu's Contents.gz file is up-to-date.

I assume you'll be following up with Laney about that.

Thanks,
Jeremy

Bug#833979: O: pidgin-privacy-please -- plugin for enhanced privacy in pidgin

[Stefan Ott]

Package: wnpp
Severity: normal

Since I am no longer using Debian as my primary operating system I am
not in a position to look after this package anymore.

Bug#833977: O: episoder -- TV show episode reminder

[Stefan Ott]

Package: wnpp
Severity: normal

Since I am no longer using Debian as my primary operating system I am
not in a position to look after this package anymore.

Bug#833978: O: fookebox -- web-based jukebox frontend to mpd

[Stefan Ott]

Package: wnpp
Severity: normal

Since I am no longer using Debian as my primary operating system I am
not in a position to look after this package anymore.

Bug#784493: [libqt4pas] Qt4's WebKit removal

[Matthias Klumpp]

2016-08-11 2:46 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer
:
> On miércoles, 10 de agosto de 2016 9:22:48 P. M. ART Paul Gevers wrote:
>> Hi Matthias,
>>
>> On Wed, 6 May 2015 15:25:22 +0200 Ana Guerrero Lopez  wrote:
>> > - if there is a Qt5 port that is not yet packaged, consider packaging it
>>
>> Do you think it may be a good idea to package the 2.6 alpha (which dates
>> already from dec 2013)? In experimental to begin with? Once webkit gets
>> removed I guess this is the only alternative.
>
> Is it possible to coinstall both versions? It should be since they are
> targetted at different Qt versions, but...

It should be, but if there is any chance that we can throw out the Qt4
version, I would be very happy with that :-)
Biggest question is: Is Lazarus ready for that? Are there known issues
with the Qt5 lcl?

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Bug#833887: vlc: Does not install app icon

[Matthias Klumpp]

2016-08-11 1:09 GMT+02:00 Jeremy Bicha :
> [...]
>
> Matthias,
>
> Do you know why vlc is not showing up in the GNOME Software app in
> Debian testing or Ubuntu yakkety, and what we can do to fix it?

It's definitely showing up in Debian Testing, I just checked that. It
is visible in GNOME Software and has all the data when I run
`appstreamcli get vlc.desktop --details` too.
(the only difference here might be that I am running GNOME Software
git master, but that really shouldn't have an impact).

2016-08-11 1:09 GMT+02:00 Jeremy Bicha :
> On Wed, Aug 10, 2016 at 3:57 AM, Sebastian Ramacher
>  wrote:
>> On 2016-08-09 18:15:05, Jeremy Bicha wrote:
>>> 1. From Debian "testing" with gnome, open the Software app.
>>> 2. Search for 'vlc'
>>>
>>> What happens:
>>> --
>>> No results for vlc
>>>
>>> What should happen:
>>> --
>>> vlc should be in the results
>>>
>>> Suggested fix
>>> --
>>> http://appstream.ubuntu.com/yakkety/universe/issues/vlc.html
>>
>> This looks buggy, see below.

Jup, this issue is preventing VLC from showing up in the results. It
likely happens due to Ubuntu's Contents file being not up-to-date,
which the old dep11-generator tool Ubuntu uses still relies on.

>>> Debian also has an appstream issues page but maybe the generator needs
>>> updating: https://appstream.debian.org/sid/main/issues/vlc.html

Debian looks fine - no error means the data is included, hints are
just informations on how to improve data.

>>> I think this could be fixed if vlc depended on vlc-data. vlc provides
>>> the binary and the .desktop but vlc-data is needed for the app icons.
>> It already does: vlc -> libvlccore8 -> vlc-data. So whenever the desktop 
>> file is
>> installed, the icon is available.

The long-term solution for this problem is to use appstream-generator,
the same tool Debian uses, which is a rewrite of the old tool Ubuntu
is still using. Iain Lane is working on that, and I hope this will
become ready in the Yakkety cycle.
A short-term fix will be having someone (Laney) reprocess the vlc
package and checking that Ubuntu's Contents.gz file is up-to-date.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#833976: ITP: libjs-jquery-dotdotdot -- jQuery plugin for ellipsis on multiple line content

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: libjs-jquery-dotdotdot
  Version : 1.8.3
  Upstream Author : Fred Heusschen
* URL : https://github.com/FrDH/jQuery.dotdotdot
* License : Expat
  Programming Lang: JavaScript
  Description : jQuery plugin for ellipsis on multiple line content

 A jQuery plugin for advanced cross-browser ellipsis which handles
 multiple line contents depending on whether the text will overlap an
 element.
 .
 You can also add one or several CSS classes to HTML elements to
 automatically invoke the plugin's functionality and some extra
 features.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#784493: [libqt4pas] Qt4's WebKit removal

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 10 de agosto de 2016 9:22:48 P. M. ART Paul Gevers wrote:
> Hi Matthias,
> 
> On Wed, 6 May 2015 15:25:22 +0200 Ana Guerrero Lopez  wrote:
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> 
> Do you think it may be a good idea to package the 2.6 alpha (which dates
> already from dec 2013)? In experimental to begin with? Once webkit gets
> removed I guess this is the only alternative.

Is it possible to coinstall both versions? It should be since they are 
targetted at different Qt versions, but...


-- 
Why should I care about my chatter from yesterday?
Nothing prevents me from becoming wiser.
  Konrad Adenauer, former German chancellor.
  http://lwn.net/SubscriberLink/397422/60a270d48f933c67/

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#833975: ITP: libjs-jquery-stupidtable -- jQuery table sorting plugin

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: libjs-jquery-stupidtable
  Version : 1.0.1
  Upstream Author : Joseph McCullough
* URL : https://github.com/joequery/Stupid-Table-Plugin
* License : Expat
  Programming Lang: JavaScript
  Description : jQuery table sorting plugin

 Most table sorting plugins try to account for a limitless number of
 data types and their limitless ways of being presented. This leads to
 an extremely bloated code base with only a tiny portion of the code
 ever used by your project.
 .
 This plugin avoids that issue by letting you define your own ways of
 sorting table columns. The plugin internally recognizes "int",
 "string", "string-ins" (case-insensitive) and "float", so simple data
 tables will take very little effort on your part.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#793214: openocd: OpenRD Ultimate unsupported since removal of ft2232 (so >=0.8.0)

[Andreas Fritiofson]

Looking into it. The failure is on a really low level because the scan
chain discovery just finds garbage. I suspect a problem with the reset
signals because the I/O initialization seems to otherwise match the legacy
driver. Looking at the old driver it seems the adapter has fully
tristate-buffered reset signals even though they are not used as such. Not
sure why that should be a problem but can you anyway try the following
config file patch?

diff --git a/tcl/interface/ftdi/sheevaplug.cfg
b/tcl/interface/ftdi/sheevaplug.cfg
index f299f27..5e3f369 100644
--- a/tcl/interface/ftdi/sheevaplug.cfg
+++ b/tcl/interface/ftdi/sheevaplug.cfg
@@ -10,5 +10,5 @@ ftdi_vid_pid 0x9e88 0x9e8f
 ftdi_channel 1

 ftdi_layout_init 0x0608 0x0f1b
-ftdi_layout_signal nTRST -data 0x0200
-ftdi_layout_signal nSRST -noe 0x0400
+ftdi_layout_signal nTRST -data 0x0200 -noe 0x0100
+ftdi_layout_signal nSRST -data 0x0800 -noe 0x0400

On Wed, Aug 10, 2016 at 11:23 PM, Benjamin Rodgers <
benjamin.rodg...@verizondigitalmedia.com> wrote:
>
> On Wed, Aug 10, 2016 at 3:24 AM, Andreas Fritiofson  fritiof...@gmail.com> wrote:
>>
>> On Wed, Aug 10, 2016 at 4:55 AM, Benjamin Rodgers > zondigitalmedia.com> wrote:
>>>
>>> On Thu, 23 Jul 2015 00:57:21 +0200 Andreas Fritiofson <
>>> andr...@fritiofson.net> wrote:
>>>
 On Wed, 22 Jul 2015 14:17:31 +0100 Philip Hands  wrote:

> I notice that running openocd causes the /dev/ttyUSB0 device to
> disapear,
> so it's certainly doing something, even if it's not very useful.


 OpenOCD detaches the kernel driver on the selected interface (FTDI
 channel)
 which might serve a serial port if so configured. Do you really have a
 tty
 on the same interface/channel as the JTAG circuitry? Channel A *should*
 be
 unaffected by OpenOCD if "ftdi_channel 1" is selected.
>>>
>>>
>>> With the legacy driver "/dev/ttyUSB0" is no longer disappearing upon
>>> running OpenOCD.  It was disappearing with the FTDI driver.
>>>
>>
>> Can you send the output of "lsusb -v -d 0x9e88:0x9e8f" and whatever adds
>> to "dmesg" after plugging in the adapter and starting openocd (beginning
>> with the line "new full-speed USB device number...")?
>>
>
> I've attached the output of both (lsusb.txt, dmesg.txt).
>
>
Nothing in dmesg when openocd starts and ttyUSB0 goes missing? I just want
to confirm that openocd actually opens the correct interface, otherwise
that could be the problem (talking JTAG with the serial port circuitry).
The "ftdi_channel 1" option is not used a lot and I've never tested it
myself. A disappearing serial port might indicate that the interface is
actually wrong, but it could also be some quirk of
libusb/ftdi_sio/virtualbox.

Regards,
Andreas Fritiofson

Bug#833973: [kamailio-tls-modules] fails to start because of different openssl versions

[Ben Sartor]

Package: kamailio-tls-modules
Version: 4.2.0-2+deb8u1
Severity: normal

--- Please enter the report below this line. ---
Hi,

recently I noticed kamailio does not start anymore. Here is the error message:

tls [tls_init.c:515]: init_tls_h(): ERROR: tls: init_tls_h: installed openssl 
library version is too different from the library the ser tls module was 
compiled with: installed "OpenSSL 1.0.1t  3 May 2016" (0x1000114f), compiled 
"OpenSSL 1.0.1k 8 Jan 2015" (0x100010bf).
Please make sure a compatible version is used (tls_force_run in ser.cfg will 
override this check)
CRITICAL:  [main.c:2521]: main(): could not initialize tls, exiting...


However a simple recompile fixed the problem for me. As suggested in the log 
message you may workaround this by putting the following line in your 
kamailio.cfg:
modparam("tls", "tls_force_run", 1)

Thanks a lot for maintaining the kamailio package. It runs great on my server 
since a couple of years now.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.5
  500 stable-updates  ftp.debian.org 
  500 stable-updates  ftp.de.debian.org 
  500 stable  security.debian.org 
  500 stable  ftp.de.debian.org 
  100 jessie-backports ftp.de.debian.org 

Bug#811965: libqt4pas: FTBFS with GCC 6: symbol changes

[Matthias Klumpp]

2016-08-10 21:26 GMT+02:00 Paul Gevers :
> Control: owner -1 !
>
> Just so it is known, I started on updating the symbols file. However I
> need my access to debomatic renewed to be able to check what I did for
> amd64 and armhf and to learn what to update for the other archs.

Oh damn, sorry, I just read your mail...
I was already working on this thing - thy way I usually do it (and
which is also the way the symbols stuff is handled with KDE
libraries)[1] is to upload a dummy package containing the
locally-fixed symbols file, and then use the build output to fix up
the symbols file for all architectures the package builds on.
I am currently waiting for the package to get built on all
architectures (both the archive and builders are really slow at
time...), then the next upload will close this bug report.

Sorry for not stating that I am working on this way earlier (that's
probably the sideeffect of just recently moving this over to Pascal
team maintenance).

Cheers,
Matthias

[1]: https://pkg-kde.alioth.debian.org/symbolfiles.html

Bug#833972: socks4-server

[Aurelien Jarno]

Source: socks4-server
Version: 4.3.beta2-19
Severity: important
Tags: patch upstream

Dear Maintainer,

glibc 2.24 has removed the deprecated BSD union wait type if favor of
the POSIX.1 interface using W* macros from  (such as
WEXITSTATUS) [1].

glibc 2.24 is already available in experimental and will plan to upload
it to sid in the next days/weeks. This will cause socks4-server to fail
to build from source. You will find attached a patch to fix the issue.
It unconditionally uses the "new" interface as the GNU libc supports it
since at least 1995, probably even earlier.
 
Please also note that this will not break the existing binaries, just
building the package from source.

Thanks,
Aurelien

[1] https://sourceware.org/ml/libc-alpha/2016-02/msg00342.html

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u socks4-server-4.3.beta2/rftp/cmds.c socks4-server-4.3.beta2/rftp/cmds.c
--- socks4-server-4.3.beta2/rftp/cmds.c
+++ socks4-server-4.3.beta2/rftp/cmds.c
@@ -1262,7 +1262,7 @@
 	int pid;
 	sig_t old1, old2;
 	char shellnam[40], *shell, *namep; 
-#if defined(SOLARIS) || defined(__alpha) || defined(SCO) || defined(ISC)
+#if defined(SOLARIS) || defined(__alpha) || defined(SCO) || defined(ISC) || defined (__GLIBC__)
 int status;
 #else
 union wait status;

Bug#827928: [pkg-go] Bug#827928: Bug#827928: golang-github-coreos-go-systemd-dev: circular dependency with golang-github-coreos-pkg-dev

[Michael Hudson-Doyle]

Thanks to upstream changes we can fix this by packaging
golang-github-coreos-pkg-capnslog separately from the rest of
golang-github-coreos-pkg. It's a bit of a hack, it'd be better to wait
until upstream splits out capnslog into a separate repo but that seems
to be taking a while. I'll do this in Ubuntu first an propose it for
fixing in Debian if it works out :-)

Bug#774534: closed by Laszlo Boszormenyi (GCS) <g...@debian.org> (Bug#774534: fixed in neon27 0.30.1-4)

[Samuel Thibault]

László Böszörményi (GCS), on Thu 11 Aug 2016 01:21:00 +0200, wrote:
> On Thu, Aug 11, 2016 at 1:07 AM, Samuel Thibault  wrote:
> > Debian Bug Tracking System, on Wed 10 Aug 2016 22:57:18 +, wrote:
> >>* Make self tests non-fatal on kFreeBSD architectures (closes: #774534).
> >
> > Well, that doesn't actually fix the original bug report: the racy test
> > will still fail, and be fatal on hurd-i386.
>  Sure, just realized it. :( Are you sure that the patch you proposed
> will make the self-tests working on kFreeBSD and on Hurd as well?

Cristoph posted the patch, not me :)

I've just tested it, it fixes the build indeed.

> Otherwise I plan to ignore test failures on non-Linux architectures.

Well, ignoring the whole testsuite just for one small case which is
known to be racy, it looks like burying potential future bugs for a
wrong reason. Christoph's patch should be burying only the test which is
known to be racy.

Samuel

Bug#833957: btrfs-progs: btrfs ERROR send ioctl failed with -2: No such file or directory

[Jakobus Schürz]

Here the output of strace


# strace /bin/btrfs send -e -p 
/var/cache/btrfs_pool_SYSTEM/@debian-testing.2016-08-10_10:00:26.daily 
/var/cache/btrfs_pool_SYSTEM/@debian-testing.2016-08-11_00:30:42.manual
ly.part 
-f trans.btrfs -v --no-data
execve("/bin/btrfs", ["/bin/btrfs", "send", "-e", "-p", 
"/var/cache/btrfs_pool_SYSTEM/@de"..., 
"/var/cache/btrfs_pool_SYSTEM/@de"..., "-f", "trans.btrfs", "-v", 
"--no-data"], [/* 24 vars */]) = 0
brk(NULL)   = 0x1efc000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) 
= 0x7f22ab18f000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=148788, ...}) = 0
mmap(NULL, 148788, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f22ab16a000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
open("/lib/x86_64-linux-gnu/libuuid.so.1", 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\260\25\0\0\0\0\0\0"...,
 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=19008, ...}) = 0
mmap(NULL, 2113936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x7f22aad69000
mprotect(0x7f22aad6d000, 2093056, PROT_NONE) = 0
mmap(0x7f22aaf6c000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f22aaf6c000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
open("/lib/x86_64-linux-gnu/libblkid.so.1", 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\\215\0\0\0\0\0\0"...,
 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=271112, ...}) = 0
mmap(NULL, 2370272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x7f22aab26000
mprotect(0x7f22aab63000, 2097152, PROT_NONE) = 0
mmap(0x7f22aad63000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3d000) = 0x7f22aad63000
mmap(0x7f22aad68000, 2784, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f22aad68000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
open("/lib/x86_64-linux-gnu/libz.so.1", 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 
\"\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=109144, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) 
= 0x7f22ab169000
mmap(NULL, 2204200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x7f22aa90b000
mprotect(0x7f22aa925000, 2093056, PROT_NONE) = 0
mmap(0x7f22aab24000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7f22aab24000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
open("/lib/x86_64-linux-gnu/liblzo2.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\0&\0\0\0\0\0\0"...,
832) 
= 832
fstat(3, {st_mode=S_IFREG|0644, st_size=137296, ...}) = 0
mmap(NULL, 2232560, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x7f22aa6e9000
mprotect(0x7f22aa70a000, 2093056, PROT_NONE) = 0
mmap(0x7f22aa909000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0x7f22aa909000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
open("/lib/x86_64-linux-gnu/libpthread.so.0", 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\0a\0\0\0\0\0\0"...,
832) 
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=135744, ...}) = 0
mmap(NULL, 2212904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x7f22aa4cc000
mprotect(0x7f22aa4e4000, 2093056, PROT_NONE) = 0
mmap(0x7f22aa6e3000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f22aa6e3000
mmap(0x7f22aa6e5000, 13352, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f22aa6e5000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\10\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1697504, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) 
= 0x7f22ab168000
mmap(NULL, 3803552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x7f22aa12b000
mprotect(0x7f22aa2c2000, 2097152, PROT_NONE) = 0
mmap(0x7f22aa4c2000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x7f22aa4c2000
mmap(0x7f22aa4c8000, 14752, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 

Bug#833971: xautolock: uses deprecated BSD union wait type

[Aurelien Jarno]

Package: xautolock
Version: 1:2.2-5
Severity: important
Tags: patch upstream

Dear Maintainer,

glibc 2.24 has removed the deprecated BSD union wait type if favor of
the POSIX.1 interface using W* macros from  (such as
WEXITSTATUS) [1].

glibc 2.24 is already available in experimental and will plan to upload
it to sid in the next days/weeks. This will cause xautolock to fail to
build from source. You will find attached a patch to fix the issue. It
unconditionally uses the "new" interface as the GNU libc supports it
since at least 1995, probably even earlier.
 
Please also note that this will not break the existing binaries, just
building the package from source.

Thanks,
Aurelien

[1] https://sourceware.org/ml/libc-alpha/2016-02/msg00342.html

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- xautolock-2.2.orig/src/engine.c
+++ xautolock-2.2/src/engine.c
@@ -240,7 +240,7 @@ evaluateTriggers (Display* d)
 #else /* VMS */
   if (lockerPid)
   {
-#if !defined (UTEKV) && !defined (SYSV) && !defined (SVR4)
+#if !defined (UTEKV) && !defined (SYSV) && !defined (SVR4) && !defined (__GLIBC__)
 union wait  status;  /* childs process status */
 #else /* !UTEKV && !SYSV && !SVR4 */
 int status = 0;  /* childs process status */
@@ -251,7 +251,7 @@ evaluateTriggers (Display* d)
   (void) kill (lockerPid, SIGTERM);
 }
 
-#if !defined (UTEKV) && !defined (SYSV) && !defined (SVR4)
+#if !defined (UTEKV) && !defined (SYSV) && !defined (SVR4) && !defined (__GLIBC__)
 if (wait3 (, WNOHANG, 0))
 #else /* !UTEKV && !SYSV && !SVR4 */
 if (waitpid (-1, , WNOHANG)) 

Bug#774534: closed by Laszlo Boszormenyi (GCS) <g...@debian.org> (Bug#774534: fixed in neon27 0.30.1-4)

[GCS]

On Thu, Aug 11, 2016 at 1:07 AM, Samuel Thibault  wrote:
> Debian Bug Tracking System, on Wed 10 Aug 2016 22:57:18 +, wrote:
>>* Make self tests non-fatal on kFreeBSD architectures (closes: #774534).
>
> Well, that doesn't actually fix the original bug report: the racy test
> will still fail, and be fatal on hurd-i386.
 Sure, just realized it. :( Are you sure that the patch you proposed
will make the self-tests working on kFreeBSD and on Hurd as well?
Otherwise I plan to ignore test failures on non-Linux architectures.

Laszlo/GCS

Bug#833970: netkit-rsh: uses deprecated BSD union wait type

[Aurelien Jarno]

Source: netkit-rsh
Version: 0.17-15
Severity: important
Tags: patch upstream

Dear Maintainer,

glibc 2.24 has removed the deprecated BSD union wait type if favor of
the POSIX.1 interface using W* macros from  (such as
WEXITSTATUS) [1].

glibc 2.24 is already available in experimental and will plan to upload
it to sid in the next days/weeks. This will cause netkit-rsh to fail to
build from source. You will find attached a patch to fix the issue. It
unconditionally uses the "new" interface, but it should be available on
all recent UNIXes including the BSDs, given POSIX.1 dates back from
1988. The GNU libc has it since at least 1995, probably even earlier.

Please also note that this will not break the existing binaries, just
building the package from source.

Thanks,
Aurelien

[1] https://sourceware.org/ml/libc-alpha/2016-02/msg00342.html

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u netkit-rsh-0.17/rlogin/rlogin.c netkit-rsh-0.17/rlogin/rlogin.c
--- netkit-rsh-0.17/rlogin/rlogin.c
+++ netkit-rsh-0.17/rlogin/rlogin.c
@@ -460,7 +460,7 @@
 void
 catch_child(int ignore)
 {
-	union wait status;
+	int status;
 	int pid;
 
 	(void)ignore;
@@ -471,7 +471,7 @@
 			return;
 		/* if the child (reader) dies, just quit */
 		if (pid < 0 || (pid == childpid && !WIFSTOPPED(status)))
-			done((int)(status.w_termsig | status.w_retcode));
+			done((int)(WTERMSIG(status) | WEXITSTATUS(status)));
 	}
 	/* NOTREACHED */
 }

Bug#833887: vlc: Does not install app icon

[Jeremy Bicha]

On Wed, Aug 10, 2016 at 3:57 AM, Sebastian Ramacher
 wrote:
> On 2016-08-09 18:15:05, Jeremy Bicha wrote:
>> 1. From Debian "testing" with gnome, open the Software app.
>> 2. Search for 'vlc'
>>
>> What happens:
>> --
>> No results for vlc
>>
>> What should happen:
>> --
>> vlc should be in the results
>>
>> Suggested fix
>> --
>> http://appstream.ubuntu.com/yakkety/universe/issues/vlc.html
>
> This looks buggy, see below.
>
>> Debian also has an appstream issues page but maybe the generator needs
>> updating: https://appstream.debian.org/sid/main/issues/vlc.html
>>
>> I think this could be fixed if vlc depended on vlc-data. vlc provides
>> the binary and the .desktop but vlc-data is needed for the app icons.
>
> It already does: vlc -> libvlccore8 -> vlc-data. So whenever the desktop file 
> is
> installed, the icon is available.
>
> So maybe ask the Gnome maintainers why vlc is not listed first.
>
> Cheers
> --
> Sebastian Ramacher

Matthias,

Do you know why vlc is not showing up in the GNOME Software app in
Debian testing or Ubuntu yakkety, and what we can do to fix it?

Thanks,
Jeremy Bicha

Bug#774534: closed by Laszlo Boszormenyi (GCS) <g...@debian.org> (Bug#774534: fixed in neon27 0.30.1-4)

[Samuel Thibault]

Hello,

Debian Bug Tracking System, on Wed 10 Aug 2016 22:57:18 +, wrote:
>* Make self tests non-fatal on kFreeBSD architectures (closes: #774534).

Well, that doesn't actually fix the original bug report: the racy test
will still fail, and be fatal on hurd-i386.

Samuel

Bug#833967: texlive-bibtex-extra should conflict with biblatex and biblatex-dw

[Adrian Bunk]

Package: texlive-bibtex-extra
Version: 2014.20141024-1
Severity: important

I just discovered that I still have the biblatex and biblatex-dw
packages from wheezy installed.

The files are in different locations, so it didn't break in the
usual obvious way when having both installed.

The proper solution would have been to provide transitional packages
for them in jessie, but for stretch texlive-bibtex-extra should at
least conflict with them to prevent having two different versions
installed in parallel.

Bug#833562: mumble: Looses settings at crash

[Jean-Philippe MENGUAL]

No problem to merge, I thought it was 2 issues: one related to c!ash;
another to loss of conf data. I'm not sure it is to be handled the same
way. Typically, you may be able to reproduce this one with killall
mumble or killall mumble -9. Or, as you say, poweroff the computer
leaving mumble on.

For the crash, when you say you don't reproduce, have you tried with
Orca and qt-at-spi installed? Is master/daily release the same than
testing one?

Regards,


Le 10/08/2016 à 23:45, Chris Knadle a écrit :
> 
> 
> Jean-Philippe MENGUAL:
>> Package: mumble
>> Version: 1.2.16-1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>>
>>* What led up to the situation?
>>
>> Well, various crashes, cf bug 793340
> 
> I haven't been able to reproduce #793340 and haven't had the Mumble
> client crash on me.  (I use the Mumble client daily.)
> 
> This is essentially a duplicate bug of #793340 so it would have been
> better to respond to #793340 if there was new information about it.  It
> probably makes sense to merge this bug with #793340 AFAICT.
> 
>> Mumble crashed trying joining a server, changing settings, etc. 
> 
> Crashed trying to join a server?  The only time I know where Mumble
> really gets screwed up trying to connect to a server is when there are
> multiple versions of OpenSSL loaded, which happens due to Qt4 not being
> compiled with the new version of OpenSSL, so both load.  /That/ will
> lead to some very strange behavior.  See #804487.
> 
>> It also happens I close the session, letting mumble be stopped by Systemd.
> 
> So if I understand correctly: you leave the client open and then
> shutdown, and that causes mumble to crash?
> 
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>>
>> After crash, restart. It's not systematic, but very often: audio settings 
>> have
>> disappear. I need to set them again.
>>
>> Besides, today, I lost my certificate! It needed to be renewed fully on 
>> mumble,
>> and I couldn't connect to my server.
> 
> The only time I've seen this (so far) is with #804487 during OpenSSL
> transitions on Sid.  I recall an OpenSSL transition was pending -- did
> that occur, and Qt4 not get binNMUed yet?
> 
>>* What was the outcome of this action?
>>
>> Settings should be saved. Loosing privacy is really a problem I think, beyond
>> loss of audio settings (which is boring).
> 
> I totally agree re: loosing the mumble certificate.  :(  At the moment
> the best I can suggest is to make a copy of the certificate in
> ~/Documents rather than relying solely on the automatically-made backup,
> because during OpenSSL transitions there is some strange behavior:
> 
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804487#62
> 
> There's also more about this at bug #1876 upstream:
> 
>https://github.com/mumble-voip/mumble/issues/1876
> 
> That's my best guess as to what might be going on here.
> 
>-- Chris
> 

-- 
Jean-Philippe MENGUAL

HYPRA, progressons ensemble

Tél.: 01 84 73 06 61

Mail: cont...@hypra.fr

Site Web: http://hypra.fr

Bug#833968: csh: uses deprecated BSD union wait type

[Aurelien Jarno]

Package: csh
Version: 20110502-2.1
Severity: important
Tags: patch upstream

Dear Maintainer,

glibc 2.24 has removed the deprecated BSD union wait type if favor of
the POSIX.1 interface using W* macros from  (such as
WEXITSTATUS).

glibc 2.24 is already available in experimental and will plan to upload
it to sid in the next days/weeks. This will cause csh to fail to build
from source. You will find attached a patch to fix the issue. It
unconditionally uses the "new" interface, but it should be available on
all recent UNIXes including the BSDs given POSIX.1 dates back from 1988.
The GNU libc has it since at least 1995, probably even earlier.

Please also note that this will not break the existing binaries, just
building the package from source.

Thanks,
Aurelien

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- csh-20110502.orig/proc.c
+++ csh-20110502/proc.c
@@ -81,13 +81,13 @@ pchild(int notused)
 int pid;
 extern int insource;
 int save_errno = errno;
-union wait w;
+int w;
 int jobflags;
 struct rusage ru;
 
 loop:
 errno = 0;			/* reset, just in case */
-pid = wait3(_status,
+pid = wait3(,
(setintr && (intty || insource) ? WNOHANG | WUNTRACED : WNOHANG), );
 
 if (pid <= 0) {
@@ -109,7 +109,7 @@ found:
 pp->p_flags &= ~(PRUNNING | PSTOPPED | PREPORTED);
 if (WIFSTOPPED(w)) {
 	pp->p_flags |= PSTOPPED;
-	pp->p_reason = w.w_stopsig;
+	pp->p_reason = WSTOPSIG(w);
 }
 else {
 	if (pp->p_flags & (PTIME | PPTIME) || adrof(STRtime))
@@ -117,16 +117,16 @@ found:
 
 	pp->p_rusage = ru;
 	if (WIFSIGNALED(w)) {
-	if (w.w_termsig == SIGINT)
+	if (WTERMSIG(w) == SIGINT)
 		pp->p_flags |= PINTERRUPTED;
 	else
 		pp->p_flags |= PSIGNALED;
-	if (w.w_coredump)
+	if (WCOREDUMP(w))
 		pp->p_flags |= PDUMPED;
-	pp->p_reason = w.w_termsig;
+	pp->p_reason = WTERMSIG(w);
 	}
 	else {
-	pp->p_reason = w.w_retcode;
+	pp->p_reason = WEXITSTATUS(w);
 	if (pp->p_reason != 0)
 		pp->p_flags |= PAEXITED;
 	else

Bug#833965: tcsh: uses deprecated BSD union wait type

[Aurelien Jarno]

On 2016-08-11 00:43, Aurelien Jarno wrote:
> Package: tcsh
> Version: 6.18.01-5
> Severity: important
> Tags: patch upstream fixed-upstream
> 
> Dear Maintainer,
> 
> glibc 2.24 has removed the deprecated BSD union wait type if favor of
> the POSIX 1 interface using W* macros from  (such as
> WEXITSTATUS).
> 
> glibc 2.24 is already available in experimental and will plan to upload
> it to sid in the next days/weeks. This will cause tcsh to fail to build
> from source. You will find attached a patch taken from upstream to fix
> the issue. I had to backport the muslc patch to make the glibc 2.24
> patch apply without any change.

Of course I forgot it. Please find it attached.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -u tcsh-6.18.01/debian/patches/series tcsh-6.18.01/debian/patches/series
--- tcsh-6.18.01/debian/patches/series
+++ tcsh-6.18.01/debian/patches/series
@@ -10,0 +11,2 @@
+muslc.patch
+glibc-2.24.patch
--- tcsh-6.18.01.orig/debian/patches/glibc-2.24.patch
+++ tcsh-6.18.01/debian/patches/glibc-2.24.patch
@@ -0,0 +1,25 @@
+commit eab72f9797ec4faaf1fb4de491c357f194b84dd6
+Author: christos 
+Date:   Thu Apr 14 11:09:09 2016 +
+
+GLIBC is getting rid of union wait.
+
+diff --git a/sh.proc.c b/sh.proc.c
+index ad07250..5c68409 100644
+--- a/sh.proc.c
 b/sh.proc.c
+@@ -47,11 +47,11 @@ RCSID("$tcsh$")
+ # define HZ 16
+ #endif /* aiws */
+ 
+-#if defined(_BSD) || (defined(IRIS4D) && __STDC__) || defined(__lucid) || defined(__GLIBC__)
+-# if !defined(__ANDROID__)
++#if defined(_BSD) || (defined(IRIS4D) && __STDC__) || defined(__lucid) || defined(__linux__) || defined(__GNU__)
++# if !defined(__ANDROID__) && !defined(__GLIBC__)
+ #  define BSDWAIT
+ # endif
+-#endif /* _BSD || (IRIS4D && __STDC__) || __lucid || glibc */
++#endif /* _BSD || (IRIS4D && __STDC__) || __lucid || gnu-linux */
+ #ifndef WTERMSIG
+ # define WTERMSIG(w)	(((union wait *) &(w))->w_termsig)
+ # ifndef BSDWAIT
--- tcsh-6.18.01.orig/debian/patches/muslc.patch
+++ tcsh-6.18.01/debian/patches/muslc.patch
@@ -0,0 +1,20 @@
+commit c43b072b89f19e9b41d45bdf3946593ae9bc6e5e
+Author: christos 
+Date:   Mon Aug 24 07:08:42 2015 +
+
+restrict BSDWAIT to __GLIBC__ because other linux libraries (muslc) don't
+have the macros.
+
+diff --git a/sh.proc.c b/sh.proc.c
+index 76eca3b..ad07250 100644
+--- a/sh.proc.c
 b/sh.proc.c
+@@ -47,7 +47,7 @@ RCSID("$tcsh$")
+ # define HZ 16
+ #endif /* aiws */
+ 
+-#if defined(_BSD) || (defined(IRIS4D) && __STDC__) || defined(__lucid) || defined(__linux__) || defined(__GNU__) || defined(__GLIBC__)
++#if defined(_BSD) || (defined(IRIS4D) && __STDC__) || defined(__lucid) || defined(__GLIBC__)
+ # if !defined(__ANDROID__)
+ #  define BSDWAIT
+ # endif

Bug#833966: fake-hwclock ignores settings in parameter file (/etc/default/fake-hwclock)

[Duncan Stokes]

Package: fake-hwclock
Version: 0.8
Severity: normal
Tags: patch

Any configuration settings added to /etc/default/fake-hwclock are not utilised 
by the primary fake-hwclock script.

The problem appears to be two-fold.  Firstly, the environment variable present 
in the parameter file are loaded but not passed to the fake-hwclock script by 
the /etc/init.d script,
as the "bin" script is not called with "source" (or ".").  Secondly, the 
fake-hwclock "binary" call made by cron.hourly does not call the parameter file 
at all.

We've solved this issue by moving the parameter file call from the init.d 
script into the "binary" script.

We discovered this issue whilst attempting to use a data file other than 
/etc/fake-hwclock.data (and yes, we've read bug #782314 and note the 
recommendations against doing so).

-- System Information:
Debian Release: 7.8
Architecture: armhf (armv7l)

Kernel: Linux 4.4.11-v7+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages fake-hwclock depends on:
ii  init-system-helpers  1.18~bpo70+1

fake-hwclock recommends no packages.

Versions of packages fake-hwclock suggests:
ii  cron [cron-daemon]  3.0pl1-124
ii  ntp 1:4.2.6.p5+dfsg-2+deb7u3

-- Configuration Files:
/etc/default/fake-hwclock changed [not included]
/etc/init.d/fake-hwclock changed [not included]

-- no debconf information
--- etc/init.d/fake-hwclock.orig	2016-08-11 07:57:12.0 +1000
+++ etc/init.d/fake-hwclock	2016-08-11 07:20:04.0 +1000
@@ -17,11 +17,6 @@ set -e
 # Include core init functions if needed
 . /lib/lsb/init-functions
 
-PARAM=/etc/default/fake-hwclock
-if [ -f $PARAM ]; then
-. "$PARAM"
-fi
-
 case "${1:-}" in
   stop|reload|restart|force-reload)
 echo "Stopping fake hwclock: saving system time."
--- sbin/fake-hwclock.orig	2016-08-11 07:56:28.0 +1000
+++ sbin/fake-hwclock	2016-08-11 07:19:37.0 +1000
@@ -10,6 +10,11 @@
 #
 # License: GPLv2, see COPYING
 
+PARAM=/etc/default/fake-hwclock
+if [ -f $PARAM ]; then
+. "$PARAM"
+fi
+
 if [ "$FILE"x = ""x ] ; then
 FILE=/etc/fake-hwclock.data
 fi

Bug#833965: tcsh: uses deprecated BSD union wait type

[Aurelien Jarno]

Package: tcsh
Version: 6.18.01-5
Severity: important
Tags: patch upstream fixed-upstream

Dear Maintainer,

glibc 2.24 has removed the deprecated BSD union wait type if favor of
the POSIX 1 interface using W* macros from  (such as
WEXITSTATUS).

glibc 2.24 is already available in experimental and will plan to upload
it to sid in the next days/weeks. This will cause tcsh to fail to build
from source. You will find attached a patch taken from upstream to fix
the issue. I had to backport the muslc patch to make the glibc 2.24
patch apply without any change.

Please also note that this will not break the existing binaries, just
building the package from source.

Thanks,
Aurelien

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

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

Bug#833964: dpkg-dev: Allow dpkg-scanpackages to scan single files

[Javier Serrano Polo]

Package: dpkg-dev
Version: 1.18.10
Severity: wishlist
Tags: patch

It would be nice if dpkg-scanpackages could scan a single file without
scanning all files in the containing directory.
diff -Nru dpkg-1.18.10.orig/man/dpkg-scanpackages.1 dpkg-1.18.10/man/dpkg-scanpackages.1
--- dpkg-1.18.10.orig/man/dpkg-scanpackages.1	2016-07-05 03:55:13.0 +0200
+++ dpkg-1.18.10/man/dpkg-scanpackages.1	2016-08-11 00:04:27.0 +0200
@@ -24,7 +24,7 @@
 .
 .SH SYNOPSIS
 .B dpkg\-scanpackages
-.RI [ option "...] " binary-dir
+.RI [ option "...] " binary-path
 .RI [ override-file
 .RI [ path-prefix ]]
 .B >
@@ -57,7 +57,7 @@
 .B file://
 sources).
 .PP
-.I binary-dir
+.I binary-path
 is the name of the tree of the binary packages to process (for example,
 .BR contrib/binary\-i386 ).
 It is best to make this relative to the root of the Debian archive,
diff -Nru dpkg-1.18.10.orig/scripts/dpkg-scanpackages.pl dpkg-1.18.10/scripts/dpkg-scanpackages.pl
--- dpkg-1.18.10.orig/scripts/dpkg-scanpackages.pl	2016-07-05 03:55:14.0 +0200
+++ dpkg-1.18.10/scripts/dpkg-scanpackages.pl	2016-08-11 00:04:48.0 +0200
@@ -231,10 +231,10 @@
 }
 }
 
-my ($binarydir, $override, $pathprefix) = @ARGV;
+my ($binarypath, $override, $pathprefix) = @ARGV;
 
-if (not -d $binarydir) {
-error(g_('binary directory %s not found'), $binarydir);
+if (not -e $binarypath) {
+error(g_('binary path %s not found'), $binarypath);
 }
 if (defined $override and not -e $override) {
 error(g_('override file %s not found'), $override);
@@ -253,7 +253,7 @@
 push @archives, $File::Find::name if m/$find_filter/;
 };
 
-find({ follow => 1, follow_skip => 2, wanted => $scan_archives}, $binarydir);
+find({ follow => 1, follow_skip => 2, wanted => $scan_archives}, $binarypath);
 foreach my $fn (@archives) {
 process_deb($pathprefix, $fn);
 }


smime.p7s
Description: S/MIME cryptographic signature

Bug#833956: wine-development: FTBFS on hurd-i386 and kfreebsd-i386

[Jens Reyer]

control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=41117

On 10.08.2016 22:41, Pino Toscano wrote:
[...]
> sysinfo(2) is strictly specific to Linux.
[...]
> Headers in sys/ and bits/ usually are implementations for the platform;
> since sys/sysinfo.h is not standard, you cannot assume that it exists
> only on a platform, nor what it provides.  In this case, the upstream
> check is wrong: it should not check for sys/sysinfo.h and assume it's
> a Linux-ish implementation, but either:
> a) just limit the implementation to Linux unconditionally (as in the
>busybox code
> b) check for sys/sysinfo.h *and* sysinfo() in it
> Considering sysinfo() is not portable anyway, (b) might fail one day
> if a platform provide a different implementation with the same name
> (it's not standard after all).
> 
> Hope it helps -- feel free to ask more.

Thanks a lot, it helped indeed.

I forwarded the issue to upstream for now.

Greets
jre

Bug#833326: pulseaudio: Lenovo Ideapad 300 - volume of the internal microphone is very low

[Felipe Sateler]

Control: reassign -1 linux-image-4.6.0-1-amd64


On 10 August 2016 at 14:16, Florent Mazzone  wrote:
>
> Hello Felipe,
>
> Thanks for your answer. I'm currently  using pavucontrol, as soon as I
> disable one channel from the microphone (for example the left chanel level
> is 0%), the microphone will work normally. I've found on the Ubuntu an issue
> that looks similar to the one I've noticed with this laptop (
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978 ). Maybe
> the problem is specific to this type of microphone ?

So, it looks like that problem indeed. Reassigning to the kernel then,
as the problem is there.

Please attach the alsa-info as documented at
https://wiki.ubuntu.com/Audio/AlsaInfo

-- 

Saludos,
Felipe Sateler

Bug#833963: dosbox: CTRL + F11/F12 doesn't modify the emulated cpu speed

[diego]

Package: dosbox
Version: 0.74-4.2+b1
Severity: important

The subject describes the problem. XD



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

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

Versions of packages dosbox depends on:
ii  libasound21.1.2-1
ii  libc6 2.23-4
ii  libgcc1   1:6.1.1-10
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libpng16-16   1.6.23-1
ii  libsdl-net1.2 1.2.8-4
ii  libsdl-sound1.2   1.0.3-7+b1
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libstdc++66.1.1-10
ii  libx11-6  2:1.6.3-1
ii  zlib1g1:1.2.8.dfsg-2+b1

dosbox recommends no packages.

dosbox suggests no packages.

-- no debconf information

Bug#833562: mumble: Looses settings at crash

[Chris Knadle]

Jean-Philippe MENGUAL:
> Package: mumble
> Version: 1.2.16-1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> Well, various crashes, cf bug 793340

I haven't been able to reproduce #793340 and haven't had the Mumble
client crash on me.  (I use the Mumble client daily.)

This is essentially a duplicate bug of #793340 so it would have been
better to respond to #793340 if there was new information about it.  It
probably makes sense to merge this bug with #793340 AFAICT.

> Mumble crashed trying joining a server, changing settings, etc. 

Crashed trying to join a server?  The only time I know where Mumble
really gets screwed up trying to connect to a server is when there are
multiple versions of OpenSSL loaded, which happens due to Qt4 not being
compiled with the new version of OpenSSL, so both load.  /That/ will
lead to some very strange behavior.  See #804487.

> It also happens I close the session, letting mumble be stopped by Systemd.

So if I understand correctly: you leave the client open and then
shutdown, and that causes mumble to crash?

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> After crash, restart. It's not systematic, but very often: audio settings have
> disappear. I need to set them again.
> 
> Besides, today, I lost my certificate! It needed to be renewed fully on 
> mumble,
> and I couldn't connect to my server.

The only time I've seen this (so far) is with #804487 during OpenSSL
transitions on Sid.  I recall an OpenSSL transition was pending -- did
that occur, and Qt4 not get binNMUed yet?

>* What was the outcome of this action?
> 
> Settings should be saved. Loosing privacy is really a problem I think, beyond
> loss of audio settings (which is boring).

I totally agree re: loosing the mumble certificate.  :(  At the moment
the best I can suggest is to make a copy of the certificate in
~/Documents rather than relying solely on the automatically-made backup,
because during OpenSSL transitions there is some strange behavior:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804487#62

There's also more about this at bug #1876 upstream:

   https://github.com/mumble-voip/mumble/issues/1876

That's my best guess as to what might be going on here.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#833962: blender: Doesn't work input with russian characters into text editor.

[Vladislav]

Package: blender
Version: 2.77.a+dfsg0-7+b1
Severity: important

Dear Maintainer,

   * What led up to the situation?
-command: "sudo aptitude update" than "sudo aptitude upgrade"
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
-added several layouts of keyboard.
   * What was the outcome of this action?
-Layouts with Latin characters work properly (Japanese, Czech, English)
- text succsesfully writes into Blender's text editor;
 layouts with other characters (partially - Cyrrilic (more partially -
Russian)) doesn't make any input into Blender's text editor.
   * What outcome did you expect instead?
-When I type with Russian layout, proper character are written into the
Blender's text editor.



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

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

Versions of packages blender depends on:
ii  blender-data  2.77.a+dfsg0-7
ii  fonts-dejavu  2.36-1
ii  libavcodec57  7:3.1.1-4
ii  libavdevice57 7:3.1.1-4
ii  libavformat57 7:3.1.1-4
ii  libavutil55   7:3.1.1-4
ii  libboost-atomic1.61.0 1.61.0+dfsg-2.1
ii  libboost-chrono1.61.0 1.61.0+dfsg-2.1
ii  libboost-date-time1.61.0  1.61.0+dfsg-2.1
ii  libboost-filesystem1.61.0 1.61.0+dfsg-2.1
ii  libboost-iostreams1.61.0  1.61.0+dfsg-2.1
ii  libboost-locale1.61.0 1.61.0+dfsg-2.1
ii  libboost-regex1.61.0  1.61.0+dfsg-2.1
ii  libboost-system1.61.0 1.61.0+dfsg-2.1
ii  libboost-thread1.61.0 1.61.0+dfsg-2.1
ii  libc6 2.23-4
ii  libfftw3-double3  3.3.4-2+b1
ii  libfontconfig12.11.0-6.5
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-11
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libglew1.13   1.13.0-2
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgomp1  6.1.1-11
ii  libilmbase12  2.2.0-11
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20150825git1ed50c92~dfsg-2
ii  libjemalloc1  3.6.0-9
ii  libjpeg62-turbo   1:1.5.0-1
ii  libopenal11:1.17.2-1
ii  libopencolorio1v5 1.0.9~dfsg0-6
ii  libopenexr22  2.2.0-11
ii  libopenimageio1.6 1.6.16~dfsg0-1
ii  libopenjp2-7  2.1.1-1
ii  libopenvdb3.1 3.1.0-4+b1
ii  libpcre3  2:8.39-1
ii  libpng16-16   1.6.23-1
ii  libpython3.5  3.5.2-3
ii  libsndfile1   1.0.25-10
ii  libspnav0 0.2.3-1
ii  libstdc++66.1.1-11
ii  libswscale4   7:3.1.1-4
ii  libtbb2   4.3~20150611-2
ii  libtiff5  4.0.6-2
ii  libx11-6  2:1.6.3-1
ii  libxi62:1.7.6-1
ii  libxml2   2.9.4+dfsg1-1+b1
ii  libxxf86vm1   1:1.1.4-1
ii  zlib1g1:1.2.8.dfsg-2+b1

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#833958: Building Dindel 1.01 with newer Boost (1.61)

[Sascha Steinbiss]

Hello,

I am writing on behalf of the Debian Med Project, which maintains a Dindel 
package for the Debian operating system. In our next Debian release, we are 
preparing to switch to Boost 1.61 as the default version. However, this caused 
various problems when trying to build the source of Dindel 1.01.  

In particular, I was wondering how to make BOOST_FOREACH work with the 
std::sets in this version. Unfortunately I don’t have much Boost experience 
myself, being more of a plain C developer. I hope you can be of a little help, 
or — in case you are still maintaining Dindel — provide a version compatible 
with Boost 1.61 (and GCC 6, if possible).

Many thanks in advance, and best regards
Sascha

P.S. Here’s an example build error:

DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
  BOOST_FOREACH(int r, selReads) {
  ^
foreach.hpp:644:96: error: no matching function for call to 
‘encode_type(std::set&, boost::is_const*)’
(true ? 0 : boost::foreach_detail_::encode_type(COL, 
boost::foreach_detail_::is_const_(COL)))

^
foreach.hpp:768:9: note: in expansion of macro ‘BOOST_FOREACH_TYPEOF’
  , BOOST_FOREACH_TYPEOF(COL))
^~~~
foreach.hpp:808:35: note: in expansion of macro ‘BOOST_FOREACH_NEXT’
  _foreach_continue ? BOOST_FOREACH_NEXT(COL) : (void)0)
\
  ^~
DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
  BOOST_FOREACH(int r, selReads) {
  ^
foreach.hpp:309:22: note: candidate: template 
boost::foreach_detail_::type2type* boost::foreach_detail_::encode_type(T&, 
mpl_::false_*)
inline type2type *encode_type(T &, boost::mpl::false_ *) { return 0; }
 ^~~
foreach.hpp:309:22: note:   template argument deduction/substitution failed:
foreach.hpp:644:91: note:   cannot convert 
‘boost::foreach_detail_::is_const_(selReads)’ (type 
‘boost::is_const*’) to type ‘mpl_::false_* {aka 
mpl_::bool_*}’
(true ? 0 : boost::foreach_detail_::encode_type(COL, 
boost::foreach_detail_::is_const_(COL)))
 
~^
foreach.hpp:768:9: note: in expansion of macro ‘BOOST_FOREACH_TYPEOF’
  , BOOST_FOREACH_TYPEOF(COL))
^~~~
foreach.hpp:808:35: note: in expansion of macro ‘BOOST_FOREACH_NEXT’
  _foreach_continue ? BOOST_FOREACH_NEXT(COL) : (void)0)
\
  ^~
DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
  BOOST_FOREACH(int r, selReads) {
  ^
foreach.hpp:312:30: note: candidate: template 
boost::foreach_detail_::type2type* 
boost::foreach_detail_::encode_type(const T&, mpl_::true_*)
inline type2type *encode_type(T const &, boost::mpl::true_ *) { 
return 0; }
 ^~~
foreach.hpp:312:30: note:   template argument deduction/substitution failed:
foreach.hpp:644:91: note:   cannot convert 
‘boost::foreach_detail_::is_const_(selReads)’ (type 
‘boost::is_const*’) to type ‘mpl_::true_* {aka 
mpl_::bool_*}’
(true ? 0 : boost::foreach_detail_::encode_type(COL, 
boost::foreach_detail_::is_const_(COL)))
 
~^
foreach.hpp:768:9: note: in expansion of macro ‘BOOST_FOREACH_TYPEOF’
  , BOOST_FOREACH_TYPEOF(COL))
^~~~
foreach.hpp:808:35: note: in expansion of macro ‘BOOST_FOREACH_NEXT’
  _foreach_continue ? BOOST_FOREACH_NEXT(COL) : (void)0)
\
  ^~
DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
  BOOST_FOREACH(int r, selReads) {

Bug#833958: Building Dindel 1.01 with newer Boost (1.61)

[Sascha Steinbiss]

Hello,

I am writing on behalf of the Debian Med Project, which maintains a Dindel 
package for the Debian operating system. In our next Debian release, we are 
preparing to switch to Boost 1.61 as the default version. However, this caused 
various problems when trying to build the source of Dindel 1.01.

In particular, I was wondering how to make BOOST_FOREACH work with the 
std::sets in this version. Unfortunately I don’t have much Boost experience 
myself, being more of a plain C developer. I hope you can be of a little help, 
or — in case you are still maintaining Dindel — provide a version compatible 
with Boost 1.61 (and GCC 6, if possible).

Many thanks in advance, and best regards
Sascha

P.S. Here’s an example build error:

DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
 BOOST_FOREACH(int r, selReads) {
 ^
foreach.hpp:644:96: error: no matching function for call to 
‘encode_type(std::set&, boost::is_const*)’
   (true ? 0 : boost::foreach_detail_::encode_type(COL, 
boost::foreach_detail_::is_const_(COL)))

   ^
foreach.hpp:768:9: note: in expansion of macro ‘BOOST_FOREACH_TYPEOF’
 , BOOST_FOREACH_TYPEOF(COL))
   ^~~~
foreach.hpp:808:35: note: in expansion of macro ‘BOOST_FOREACH_NEXT’
 _foreach_continue ? BOOST_FOREACH_NEXT(COL) : (void)0) 
   \
 ^~
DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
 BOOST_FOREACH(int r, selReads) {
 ^
foreach.hpp:309:22: note: candidate: template 
boost::foreach_detail_::type2type* boost::foreach_detail_::encode_type(T&, 
mpl_::false_*)
inline type2type *encode_type(T &, boost::mpl::false_ *) { return 0; }
^~~
foreach.hpp:309:22: note:   template argument deduction/substitution failed:
foreach.hpp:644:91: note:   cannot convert 
‘boost::foreach_detail_::is_const_(selReads)’ (type 
‘boost::is_const*’) to type ‘mpl_::false_* {aka 
mpl_::bool_*}’
   (true ? 0 : boost::foreach_detail_::encode_type(COL, 
boost::foreach_detail_::is_const_(COL)))

~^
foreach.hpp:768:9: note: in expansion of macro ‘BOOST_FOREACH_TYPEOF’
 , BOOST_FOREACH_TYPEOF(COL))
   ^~~~
foreach.hpp:808:35: note: in expansion of macro ‘BOOST_FOREACH_NEXT’
 _foreach_continue ? BOOST_FOREACH_NEXT(COL) : (void)0) 
   \
 ^~
DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
 BOOST_FOREACH(int r, selReads) {
 ^
foreach.hpp:312:30: note: candidate: template 
boost::foreach_detail_::type2type* 
boost::foreach_detail_::encode_type(const T&, mpl_::true_*)
inline type2type *encode_type(T const &, boost::mpl::true_ *) { 
return 0; }
^~~
foreach.hpp:312:30: note:   template argument deduction/substitution failed:
foreach.hpp:644:91: note:   cannot convert 
‘boost::foreach_detail_::is_const_(selReads)’ (type 
‘boost::is_const*’) to type ‘mpl_::true_* {aka 
mpl_::bool_*}’
   (true ? 0 : boost::foreach_detail_::encode_type(COL, 
boost::foreach_detail_::is_const_(COL)))

~^
foreach.hpp:768:9: note: in expansion of macro ‘BOOST_FOREACH_TYPEOF’
 , BOOST_FOREACH_TYPEOF(COL))
   ^~~~
foreach.hpp:808:35: note: in expansion of macro ‘BOOST_FOREACH_NEXT’
 _foreach_continue ? BOOST_FOREACH_NEXT(COL) : (void)0) 
   \
 ^~
DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
 BOOST_FOREACH(int r, selReads) {

Bug#833958: dindel: please use default boost

[Sascha Steinbiss]

Control: tag -1 + help

Hi Mattia,

> We would like to ship only one boost in stretch, therefore¹
> https://anonscm.debian.org/cgit/debian-med/dindel.git/commit/?id=7fbf620a559dbac03aa56e7eec27d94cf225c8ea
> is not something nice for that :)

Point taken ;)
However, when switching back to Boost 1.61 I have no idea of how to make 
BOOST_FOREACH work with the std::sets in there; I don’t have much Boost 
experience. Maybe someone more knowledgeable in C++ could help - thanks!

Example:

DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
   BOOST_FOREACH(int r, selReads) {
   ^
foreach.hpp:644:96: error: no matching function for call to 
‘encode_type(std::set&, boost::is_const*)’
 (true ? 0 : boost::foreach_detail_::encode_type(COL, 
boost::foreach_detail_::is_const_(COL)))

^
foreach.hpp:768:9: note: in expansion of macro ‘BOOST_FOREACH_TYPEOF’
   , BOOST_FOREACH_TYPEOF(COL))
 ^~~~
foreach.hpp:808:35: note: in expansion of macro ‘BOOST_FOREACH_NEXT’
   _foreach_continue ? BOOST_FOREACH_NEXT(COL) : (void)0)   
 \
   ^~
DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
   BOOST_FOREACH(int r, selReads) {
   ^
foreach.hpp:309:22: note: candidate: template 
boost::foreach_detail_::type2type* boost::foreach_detail_::encode_type(T&, 
mpl_::false_*)
 inline type2type *encode_type(T &, boost::mpl::false_ *) { return 0; }
  ^~~
foreach.hpp:309:22: note:   template argument deduction/substitution failed:
foreach.hpp:644:91: note:   cannot convert 
‘boost::foreach_detail_::is_const_(selReads)’ (type 
‘boost::is_const*’) to type ‘mpl_::false_* {aka 
mpl_::bool_*}’
 (true ? 0 : boost::foreach_detail_::encode_type(COL, 
boost::foreach_detail_::is_const_(COL)))
  
~^
foreach.hpp:768:9: note: in expansion of macro ‘BOOST_FOREACH_TYPEOF’
   , BOOST_FOREACH_TYPEOF(COL))
 ^~~~
foreach.hpp:808:35: note: in expansion of macro ‘BOOST_FOREACH_NEXT’
   _foreach_continue ? BOOST_FOREACH_NEXT(COL) : (void)0)   
 \
   ^~
DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
   BOOST_FOREACH(int r, selReads) {
   ^
foreach.hpp:312:30: note: candidate: template 
boost::foreach_detail_::type2type* 
boost::foreach_detail_::encode_type(const T&, mpl_::true_*)
 inline type2type *encode_type(T const &, boost::mpl::true_ *) { 
return 0; }
  ^~~
foreach.hpp:312:30: note:   template argument deduction/substitution failed:
foreach.hpp:644:91: note:   cannot convert 
‘boost::foreach_detail_::is_const_(selReads)’ (type 
‘boost::is_const*’) to type ‘mpl_::true_* {aka 
mpl_::bool_*}’
 (true ? 0 : boost::foreach_detail_::encode_type(COL, 
boost::foreach_detail_::is_const_(COL)))
  
~^
foreach.hpp:768:9: note: in expansion of macro ‘BOOST_FOREACH_TYPEOF’
   , BOOST_FOREACH_TYPEOF(COL))
 ^~~~
foreach.hpp:808:35: note: in expansion of macro ‘BOOST_FOREACH_NEXT’
   _foreach_continue ? BOOST_FOREACH_NEXT(COL) : (void)0)   
 \
   ^~
DInDel.cpp:1985:7: note: in expansion of macro ‘BOOST_FOREACH’
   BOOST_FOREACH(int r, selReads) {
   ^

Cheers
Sascha

Bug#833961: wireguard-dkms: kernel module fails to build

[Robert Edmonds]

Package: wireguard-dkms
Version: 0.0.20160808-experimental1
Severity: important

Hi!

It looks like the kernel module in wireguard-dkms is failing to build on
an up-to-date sid system.

root@debian:~# apt install wireguard-dkms
Reading package lists... Done
Building dependency tree
Reading state information... Done
Recommended packages:
   wireguard-tools (0.0.20160808-experimental1)
The following NEW packages will be installed:
   wireguard-dkms (0.0.20160808-experimental1)
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 85.5 kB of archives.
After this operation, 464 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian experimental/main amd64 wireguard-dkms all 
0.0.20160808-experimental1 [85.5 kB]
Fetched 85.5 kB in 0s (1,073 kB/s)
Selecting previously unselected package wireguard-dkms.
(Reading database ... 66002 files and directories currently installed.)
Preparing to unpack .../wireguard-dkms_0.0.20160808-experimental1_all.deb ...
Unpacking wireguard-dkms (0.0.20160808-experimental1) ...
Setting up wireguard-dkms (0.0.20160808-experimental1) ...
Loading new wireguard-0.0.20160808 DKMS files...
First Installation: checking all kernels...
Building only for 4.6.0-1-amd64
Building initial module for 4.6.0-1-amd64
Error! Bad return status for module build on kernel: 4.6.0-1-amd64 (x86_64)
Consult /var/lib/dkms/wireguard/0.0.20160808/build/make.log for more 
information.
root@debian:~# cat /var/lib/dkms/wireguard/0.0.20160808/build/make.log
DKMS make.log for wireguard-0.0.20160808 for kernel 4.6.0-1-amd64 (x86_64)
Wed Aug 10 14:58:42 PDT 2016
make: Entering directory '/usr/src/linux-headers-4.6.0-1-amd64'
  LD  /var/lib/dkms/wireguard/0.0.20160808/build/built-in.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20160808/build/main.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20160808/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20160808/build/device.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20160808/build/peer.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20160808/build/timers.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20160808/build/data.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20160808/build/send.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20160808/build/receive.o
/var/lib/dkms/wireguard/0.0.20160808/build/data.c:47:30: fatal error: 
selftest/counter.h: No such file or directory
compilation terminated.
/usr/src/linux-headers-4.6.0-1-common/scripts/Makefile.build:296: recipe for 
target '/var/lib/dkms/wireguard/0.0.20160808/build/data.o' failed
make[3]: *** [/var/lib/dkms/wireguard/0.0.20160808/build/data.o] Error 1
make[3]: *** Waiting for unfinished jobs
/usr/src/linux-headers-4.6.0-1-common/Makefile:1446: recipe for target 
'_module_/var/lib/dkms/wireguard/0.0.20160808/build' failed
make[2]: *** [_module_/var/lib/dkms/wireguard/0.0.20160808/build] Error 2
Makefile:146: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make: *** [all] Error 2
make: Leaving directory '/usr/src/linux-headers-4.6.0-1-amd64'
root@debian:~# 

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

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

Versions of packages wireguard-dkms depends on:
ii  dkms  2.2.0.3-5

Versions of packages wireguard-dkms recommends:
pn  wireguard-tools  

wireguard-dkms suggests no packages.

-- no debconf information

-- 
Robert Edmonds
edmo...@debian.org

Bug#821181: jruby: FTBFS due to PsychParser class error

[Emmanuel Bourg]

Le 23/04/2016 à 15:17, Miguel Landaeta a écrit :

> It turns out I was responsible for the second bug. When I updated yecht
> 1.1-1, the updated .jar file is now dropping a class in the default package
> (YechtService.class).
> 
> That doesn't work with maven-bundle-plugin.

I got a look at the maven-bundle-plugin issue. I haven't been able to
find a plugin configuration that works, but I tested different versions
of the bundle plugin and the versions > 3 do not fail with the error
"The default package '.' is not permitted by the Import-Package syntax".

I was a bit reluctant to upgrade again bnd and maven-bundle-plugin for
stretch but we have a good reason to do it now.

Emmanuel Bourg

Bug#833960: simple-tpm-pk11: Segfault when using as pkcs11 module for strongswan

[Willem Mulder]

Package: simple-tpm-pk11
Version: 0.04-1
Severity: normal

Dear Maintainer,

I was attempting to use a TPM as a secure device for storing a private key for
IPSec, through the strongswan pkcs11 plugin from libstrongswan-extra-plugins. I
specified /usr/lib/x86_64-linux-gnu/libsimple-tpm-pk11.so as the module path.

However, when restarting strongswan, its IKEv2 daemon fails to start due to a
segfault in libsimple-tpm-pk11:

Aug 10 20:12:05 debian charon[24644]: 00[DMN] Starting IKE charon daemon 
(strongSwan 5.2.1, Linux 3.16.0-4-amd64, x86_64)
Aug 10 20:12:05 debian charon[24644]: 00[CFG] loaded PKCS#11 v0.1 library 
'simple-tpm-pk11' (/usr/lib/x86_64-linux-gnu/libsimple-tpm-pk11.so)
Aug 10 20:12:05 debian charon[24644]: 00[CFG]   simple-tpm-pk11 manufacture: 
simple-tpm-pk11 librar v0.1
Aug 10 20:12:05 debian ipsec_starter[24424]: charon has died -- restart 
scheduled (5sec)
Aug 10 20:12:05 debian ipsec_starter[24424]: charon refused to be started
Aug 10 20:12:05 debian ipsec[24424]: charon has died -- restart scheduled (5sec)
Aug 10 20:12:05 debian ipsec[24424]: charon refused to be started
Aug 10 20:12:05 debian kernel: charon[24644]: segfault at 0 ip 7fa33ac3bee3 
sp 7fff54ff19f8 error 6 in libsimple-tpm-pk11.so.0.0.0[7fa33ac34000+22000]

If it's not possible to use this module for this, I'd at least expect a proper
error message. 

I hope this is all the information you need.

Kind regards,
Willem Mulder

P.S. I used simple-tpm-pk11 from testing as that is the newest version
available; the same problems are exhibited with version 0.03-1 from stable.

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable'), (450, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages simple-tpm-pk11 depends on:
ii  libc62.19-18+deb8u1
ii  libgcc1  1:4.9.2-10
ii  libssl1.0.2  1.0.2h-1
ii  libstdc++6   6.1.1-10
ii  libtspi1 0.3.13-3
ii  trousers 0.3.13-3

Versions of packages simple-tpm-pk11 recommends:
ii  openssh-client  1:6.7p1-5

simple-tpm-pk11 suggests no packages.

-- no debconf information

Bug#827909: [Pkg-clamav-devel] Bug#827909: clamav-freshclam and clamav-daemon not starting after install

[Sebastian Andrzej Siewior]

On 2016-06-22 14:39:50 [+0200], Christian Ehrhardt wrote:
> ## The case ##
> 1. "sudo apt-get install clamav-daemon clamav-freshclam"
> 2. ClamAV doesn't start even though it should.
> 
> $ systemctl status clamav-daemon
> ● clamav-daemon.service - Clam AntiVirus userspace daemon
>Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled;
> vendor preset: enabled)
>Active: inactive (dead)
> Condition: start condition failed at Thu 2016-06-09 11:58:19 EEST; 7min ago
>  Docs: man:clamd(8)
>man:clamd.conf(5)
>http://www.clamav.net/lang/en/doc/
this is okay.

> $ systemctl status clamav-freshclam.service
> ● clamav-freshclam.service - ClamAV virus database updater
>Loaded: loaded (/lib/systemd/system/clamav-freshclam.service; enabled;
> vendor preset: enabled)
>Active: inactive (dead)
>  Docs: man:freshclam(1)
>man:freshclam.conf(5)
>http://www.clamav.net/lang/en/doc/
this is not.

> ## The issues ##
> #1 - freshclam not starting after install anymore (works in jessie)
>   => That part is a regression.

why did freshclam not start? An up to date sid:
|root@debsidamd64:/home/bigeasy/deb-clamav# dpkg -i 
clamav-freshclam_0.99.2+dfsg-2_amd64.deb
|Selecting previously unselected package clamav-freshclam.
|(Reading database ... 47039 files and directories currently installed.)
|Preparing to unpack clamav-freshclam_0.99.2+dfsg-2_amd64.deb ...
|Unpacking clamav-freshclam (0.99.2+dfsg-2) ...
|Setting up clamav-freshclam (0.99.2+dfsg-2) ...
|Created symlink 
/etc/systemd/system/multi-user.target.wants/clamav-freshclam.service → 
/lib/systemd/system/clamav-freshclam.service.
|Processing triggers for systemd (231-1) ...
|Processing triggers for man-db (2.7.5-1) ...
|root@debsidamd64:/home/bigeasy/deb-clamav# systemctl status 
clamav-freshclam.service
|● clamav-freshclam.service - ClamAV virus database updater
|   Loaded: loaded (/lib/systemd/system/clamav-freshclam.service; enabled; 
vendor preset: enabled)
|   Active: active (running) since Wed 2016-08-10 23:53:22 CEST; 5s ago
| Docs: man:freshclam(1)
|   man:freshclam.conf(5)
|   http://www.clamav.net/lang/en/doc/
| Main PID: 20697 (freshclam)
|   CGroup: /system.slice/clamav-freshclam.service
|   ├─20697 /usr/bin/freshclam -d --foreground=true
|   └─20897 /usr/bin/freshclam -d --foreground=true
|
|Aug 10 23:53:22 debsidamd64 systemd[1]: Started ClamAV virus database updater.
|Aug 10 23:53:22 debsidamd64 freshclam[20697]: ClamAV update process started at 
Wed Aug 10 23:53:22 2016
|Aug 10 23:53:24 debsidamd64 freshclam[20697]: Downloading main.cvd [100%]

Sebastian

Bug#809611: d-i fails to boot on HP mv2120

[Baptiste Jammet]

Control: tags -1 patch

Hi

Dixit Martin Michlmayr, le 08/08/2016 :

>Please add the following to the release-notes on armel in the upgrade
>section:
>
>HP mv2120
[...]

I used copy and formatting to put this in the Upgrading chapter.
I choose the integral doc, as it's not so long and clearer that linking
to Martin's webpage.
Please comment and correct.

Baptiste
Index: upgrading.dbk
===
--- upgrading.dbk	(révision 11269)
+++ upgrading.dbk	(copie de travail)
@@ -1105,6 +1105,53 @@
 
 
 
+
+Special care for specific packages
+
+In most cases, packages should upgrade smoothly between 
+and .  There are a small number of cases where some intervention
+may be required, either before or during the upgrade; these are detailed
+below on a per-package basis.
+
+
+
+  HP mv2120
+  
+The default u-boot settings from HP no longer work with  .
+Before you can upgrade to  , you have to change some settings
+in the u-boot configuration. 
+The new settings are compatible with   and  , so it's
+recommended to make the changes before the upgrade.
+If you have serial console access to the mv2120, you can run some
+commands in u-boot. Simply interrupt the boot process by pressing a
+key and type the following:
+  
+  
+setenv loadAddr 0x060
+setenv bootcmd 'bootext2 0,1:1,2 0x060 /boot/uImage /dev/sda /dev/sdb'
+saveenv
+  
+  
+If you don't have a serial console, you can make the changes from
+  within Debian. Run the following commands:
+  
+  
+cat  /etc/fw_env.config EOF
+/dev/mtd0   0x0 0x1000 0x2
+   EOF
+
+   fw_setenv loadAddr 0x060
+   fw_setenv bootcmd "bootext2 0,1:1,2 0x060 /boot/uImage /dev/sda /dev/sdb"
+  
+  
+This creates a config file so the u-boot environment can be modified
+and uses fw_setenv to update two boot variables.
+  
+  
+Please note that   will be the last release to support the HP mv2120.
+  
+
+
 
 
 


pgpkuWsM2_DVc.pgp
Description: OpenPGP digital signature

Bug#830719: Document the removal of upstart, suggest switch to supported init

[Baptiste Jammet]

Control: tags -1 patch

Hi, 

Dixit Michael Biebl, le 10/07/2016 :

>The upstart init system has been removed from unstable/testing, so it
>looks like it won't be part of the upcoming stretch release.
>I raised this issue on debian-devel [1] and one recommendation was,
>that this fact should be mentioned in the release notes. We should
>suggest that users switch to a supported alternative because
>post-stretch it's likely that maintainers start removing native
>upstart jobs.

I write a section about it and I put it in the end of the Issues
chapter.
Please comment and correct. 
(I could commit in some weeks if nobody disagree)

Baptiste
Index: issues.dbk
===
--- issues.dbk	(révision 11269)
+++ issues.dbk	(copie de travail)
@@ -347,6 +347,20 @@
 
   
 
+  
+Upstart removed
+Due to the lack of upstream maintainers,
+  the Upstart init system has been removed from .
+  If your system relies on this package, you should note that it will not be updated
+  during the lifetime of  , 
+  and starting from   (),
+  upstart jobs could be removed from packages.
+
+
+  You should also consider a switch to a supported init system, like systemd or openrc.
+
+  
+
 
 
 


pgpU8qRL0k7zt.pgp
Description: OpenPGP digital signature

Bug#833959: xserver-xorg-video-intel: Rendering Performance Impacted

[Leo L. Schwab]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20160706-1
Severity: important

Dear Maintainer,

Since updating to the latest Intel driver, I've noted rendering
performance has suffered in some applications.  I've finally identified a
program that reliably exhibits the issue -- 'phosphor' from the xscreensaver
package.

To reproduce:
- Run phosphor by hand:
  /usr/lib/xscreensaver/phosphor
- Wait for the cursor to arrive at the bottom of the window.  When
  the "terminal" scrolls, rendering performance tanks immediately.
  This is doubtless due to the full-window fade effect being
  applied, which has now become very slow.  This slowness was not
  present in previous driver versions.

The system is a Thinkpad X1 Carbon (Gen.3), 1440p display.
'glxinfo' reports the GPU as Intel HD Graphics 5500 (Broadwell GT2).  I have
xscreensaver v5.34-2 installed.

I used to write graphics drivers back in the day, so I can probably
answer obscure questions and run tests.

Thanks,
Schwab


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U 
Integrated Graphics [8086:1616] (rev 09)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 
20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.4-1 (2016-07-18)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 31415 Aug  4 16:48 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 4.376] 
X.Org X Server 1.18.4
Release Date: 2016-07-19
[ 4.376] X Protocol Version 11, Revision 0
[ 4.376] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[ 4.376] Current Operating System: Linux walkies 4.6.0-1-amd64 #1 SMP 
Debian 4.6.4-1 (2016-07-18) x86_64
[ 4.376] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.6.0-1-amd64 
root=UUID=c83db6d8-15bf-493f-9339-a9d6129a7992 ro quiet
[ 4.376] Build Date: 20 July 2016  05:14:41AM
[ 4.376] xorg-server 2:1.18.4-1 (http://www.debian.org/support) 
[ 4.376] Current version of pixman: 0.33.6
[ 4.376]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 4.376] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 4.377] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Aug  4 16:48:23 
2016
[ 4.377] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 4.378] (==) No Layout section.  Using the first Screen section.
[ 4.378] (==) No screen section available. Using defaults.
[ 4.378] (**) |-->Screen "Default Screen Section" (0)
[ 4.378] (**) |   |-->Monitor ""
[ 4.379] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 4.379] (==) Automatically adding devices
[ 4.379] (==) Automatically enabling devices
[ 4.379] (==) Automatically adding GPU devices
[ 4.379] (==) Max clients allowed: 256, resource mask: 0x1f
[ 4.380] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 4.380]Entry deleted from font path.
[ 4.381] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 4.381] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 4.381] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 4.381] (II) Loader magic: 0x55b2597b7dc0
[ 4.381] (II) Module ABI versions:
[ 4.381]X.Org ANSI C Emulation: 0.4
[ 4.381]X.Org Video Driver: 20.0
[ 4.381]X.Org XInput driver : 22.1
[ 4.381]X.Org Server Extension : 9.0
[ 4.382] (++) using VT number 7

[ 4.382] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[ 4.382] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 4.383] (--) PCI:*(0:0:2:0) 8086:1616:17aa:2227 rev 9, Mem @ 
0xe000/16777216, 0xc000/536870912, I/O @ 0x3000/64, BIOS @ 

Bug#793214: openocd: OpenRD Ultimate unsupported since removal of ft2232 (so >=0.8.0)

[Benjamin Rodgers]

On Wed, Aug 10, 2016 at 3:24 AM, Andreas Fritiofson <
andreas.fritiof...@gmail.com> wrote:
>
> On Wed, Aug 10, 2016 at 4:55 AM, Benjamin Rodgers  verizondigitalmedia.com> wrote:
>
>> I compiled OpenOCD 0.9.0 from source first without
>> "--enable-legacy-ft2232_libftdi" to confirm no change in behavior, and
>> then with "--enable-legacy-ft2232_libftdi".  With a couple caveats, it's
>> actually working now.
>>
>
>>
>
>>
>> Caveat 2:  When I don't have a serial connection open (screen
>> /dev/ttyUSB0 115200), everything works great.  When I do, OpenOCD
>> periodically chokes.  This may be related to my hardware configuration
>> (Debian Jessie as set up by Vagrant debian/jessie64 running on VirtualBox
>> on a Mac), but I'm mentioning it just in case others experience similar
>> behavior.
>>
>> Error: ftdi_write_data: usb bulk write failed
>>> Error: couldn't write MPSSE commands to FT2232
>>> Polling target feroceon.cpu failed, trying to reexamine
>>> Info : Embedded ICE version 0
>>> Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit
>>> For reference, the telltale
>>
>>
> This symptom was common with the ft2232 adapter driver (for several
> reasons) and was part of the motivation for the full rewrite. We will not
> fix issues with the deprecated ft2232 driver upstream, in fact we have a
> patch pending to purge it completely. Now that we know that the same setup
> works with ft2232 but not with ftdi, let's focus on getting the latter
> working.
>

Makes sense to me.  Glad I mentioned it.



On Wed, Aug 10, 2016 at 3:24 AM, Andreas Fritiofson <
andreas.fritiof...@gmail.com> wrote:
>
> On Wed, Aug 10, 2016 at 4:55 AM, Benjamin Rodgers  verizondigitalmedia.com> wrote:
>>
>> On Thu, 23 Jul 2015 00:57:21 +0200 Andreas Fritiofson <
>> andr...@fritiofson.net> wrote:
>>
>>> On Wed, 22 Jul 2015 14:17:31 +0100 Philip Hands  wrote:
>>>
 I notice that running openocd causes the /dev/ttyUSB0 device to
 disapear,
 so it's certainly doing something, even if it's not very useful.
>>>
>>>
>>> OpenOCD detaches the kernel driver on the selected interface (FTDI
>>> channel)
>>> which might serve a serial port if so configured. Do you really have a
>>> tty
>>> on the same interface/channel as the JTAG circuitry? Channel A *should*
>>> be
>>> unaffected by OpenOCD if "ftdi_channel 1" is selected.
>>
>>
>> With the legacy driver "/dev/ttyUSB0" is no longer disappearing upon
>> running OpenOCD.  It was disappearing with the FTDI driver.
>>
>
> Can you send the output of "lsusb -v -d 0x9e88:0x9e8f" and whatever adds
> to "dmesg" after plugging in the adapter and starting openocd (beginning
> with the line "new full-speed USB device number...")?
>

I've attached the output of both (lsusb.txt, dmesg.txt).



On Wed, Aug 10, 2016 at 3:24 AM, Andreas Fritiofson <
andreas.fritiof...@gmail.com> wrote:
>
> On Wed, Aug 10, 2016 at 4:55 AM, Benjamin Rodgers  verizondigitalmedia.com> wrote:
>
For reference, here is the output of OpenOCD with the FTDI driver.
>>
>
>> vagrant@jessie:~/a/openocd-0.9.0$ src/openocd -f
>>> tcl/board/sheevaplug.cfg -s tcl
>>
>>
> Please add "-d" to get a verbose log. Also, if you compile from source
> anyway, use the git master if possible (for easier matching the log to the
> code).
>

Rebuilt from git master and ran with "-d".  I've attached the Vagrantfile
for reference and logged output (debug.txt).


Cheers!

Benjamin Rodgers
...
[6.811545] PM: Hibernation image not present or could not be loaded.
[6.844175] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[6.863399] usb 1-1: new full-speed USB device number 2 using ohci-pci
[6.943184] tsc: Refined TSC clocksource calibration: 2495.109 MHz
[6.950286] systemd[1]: Cannot add dependency job for unit 
display-manager.service, ignoring: Unit display-manager.service failed to load: 
No such file or directory.
...
[7.146478] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[7.147695] alg: No test for crc32 (crc32-pclmul)
[7.148380] usb 1-1: New USB device found, idVendor=9e88, idProduct=9e8f
[7.148382] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[7.148383] usb 1-1: Product: SheevaPlug JTAGKey FT2232D B
[7.148384] usb 1-1: Manufacturer: FTDI
[7.148385] usb 1-1: SerialNumber: FTJRNOPX
[7.160143] Adding 473084k swap on /dev/sda5.  Priority:-1 extents:1 
across:473084k FS
[7.194573] usbcore: registered new interface driver usbserial
[7.194665] usbcore: registered new interface driver usbserial_generic
[7.194731] usbserial: USB Serial support registered for generic
[7.195806] usbcore: registered new interface driver ftdi_sio
[7.195815] usbserial: USB Serial support registered for FTDI USB Serial 
Device
[7.195837] usb 1-1: Ignoring serial port reserved for JTAG
[7.195853] ftdi_sio 1-1:1.1: FTDI USB Serial Device converter detected
[

Bug#774534: [neon27] racy testsuite

[Christoph Egger]

Hi!

"László Böszörményi (GCS)"  writes:
>  Just uploaded the package, making the tests non-fatal before your email. :-/

Thanks!

  Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Bug#833958: dindel: please use default boost

[Mattia Rizzolo]

source: dindel
version: 1.01+dfsg-3
severity: important

We would like to ship only one boost in stretch, therefore¹
https://anonscm.debian.org/cgit/debian-med/dindel.git/commit/?id=7fbf620a559dbac03aa56e7eec27d94cf225c8ea
is not something nice for that :)

This is not yet release critical, but I assume it'll soon be.


¹ credits to ginggs to notify me of this.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#831935: libjs-swfobject: FTBFS with dpkg-buildpackage -A: dh_install: missing files, aborting

[Christian Welzel]

Am 23.07.2016 um 13:15 schrieb Santiago Vila:


Patch attached.


I prepared a new package. This can be found on mentors, because i cannot
upload myself. You can find it here:

https://mentors.debian.net/debian/pool/main/libj/libjs-swfobject/libjs-swfobject_2.2+dfsg-2.dsc

--
 MfG, Christian Welzel

  GPG-Key: pub 4096R/5117E119 2011-09-19
  Fingerprint: 3688 337C 0D3E 3725 94EC  E401 8D52 CDE9 5117 E119

Bug#774534: [neon27] racy testsuite

[GCS]

On Wed, Aug 10, 2016 at 11:03 PM, Christoph Egger  wrote:
> Christoph Egger  writes:
>>   Would you mind making the testsuite non-fatal until this race is
>> fixed? I can prepare a NMU as well if you want me to. The failure's
>> currently blocking also libreoffice to build on !linux
>
> FWIW I'd apply the below patch from James Clarke and am probably doing a
> NMU tomorrow (it's quite non-intrusive and for a important bug open for
> more than a year, also I need that build!)
 Just uploaded the package, making the tests non-fatal before your email. :-/

Cheers,
Laszlo/GCS

Bug#774534: [neon27] racy testsuite

[Christoph Egger]

Hi!

Christoph Egger  writes:
>   Would you mind making the testsuite non-fatal until this race is
> fixed? I can prepare a NMU as well if you want me to. The failure's
> currently blocking also libreoffice to build on !linux

FWIW I'd apply the below patch from James Clarke and am probably doing a
NMU tomorrow (it's quite non-intrusive and for a important bug open for
more than a year, also I need that build!)

  Christoph

--- a/test/redirect.c
+++ b/test/redirect.c
@@ -181,7 +181,7 @@ static int no_redirect(void)
 
 ONN("redirect non-NULL after non-redir req", ne_redirect_location(sess));
 
-CALL(process_redir(sess, "/foo", ));
+PRECOND(process_redir(sess, "/foo", ) == OK);
 CALL(await_server());
 
 ne_session_destroy(sess);


-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Bug#819448: Steps to reproduce

[Tomasz Rybak]

Hello.
Have you found any code that would allow to reproduce this issue?
I was not able to get such behavior. Your trace would suggest
that this is related to some OpenCL objects keeping references
to other objects - or not checking when those objects are None.

I intend to upload new PyOpenCL version soon (hopefully next week).
It'd be great if you could check this issue with new version.
There is already one issue fixed in upstream repository (#826025),
maybe this one is also fixed.

Best regards.

-- 
Tomasz Rybak, Debian Maintainer 
GPG: A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak

Bug#826718: Fwknop 2.6.9 packaged

[Franck Joncourt]

Hi Santiago,

Thanks for your quick reply. I did add the deb files to the bug report to
provide them to users since it has been a while since the last real update
of fwknop on Debian.

I am almost ready to push new files to debian mentor (updated package with
QA upload + patches + lintian fixes) - I have just detected a minor problem
with hardening flags. I hoped I could achieve this before going on holidays
but I currently run out of time. I will continue at the end of August and I
would be delighted if you or Gregor could sponsor the upload if you have
time.

I would like to maintain the fwknop package again but with my family and my
job it is sometimes difficult to find the time to do it correctly. I may be
unavailable for weeks and that is why I resigned.

Best regards,

--
Franck Joncourt

Bug#740280: [L10N,DE] devede: updated german program translation

[James Cowgill]

Control: tags -1 moreinfo

Hi,

On 27/02/14 19:58, Holger Wansing wrote:
> Hi,
> attached you get the updated, fully translated german program translation
> for devede, version 3.23.0.
> Please include it in your package.

Sorry it's taken some time to get a reply to this bug report. While I
could include your translation in the package, it's now a bit out of
date (were on version 4.7.1 now). Is it possible for you to update it?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#833956: wine-development: FTBFS on hurd-i386 and kfreebsd-i386

[Pino Toscano]

Hi,

In data mercoledì 10 agosto 2016 22:20:10 CEST, Jens Reyer ha scritto:
> ~
> gcc -c -o virtual.o virtual.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_ 
> -D_REENTRANT -fPIC -Wall \
>   -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body 
> -Wignored-qualifiers \
>   -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla 
> -Wwrite-strings -Wpointer-arith \
>   -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -Werror 
> -Wdate-time -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -Wno-error
> virtual.c: In function 'virtual_get_system_info':
> virtual.c:1363:20: error: storage size of 'sinfo' isn't known
>  struct sysinfo sinfo;
> ^
> virtual.c:1372:10: warning: implicit declaration of function 'sysinfo' 
> [-Wimplicit-function-declaration]
>  if (!sysinfo())
>   ^
> virtual.c:1363:20: warning: unused variable 'sinfo' [-Wunused-variable]
>  struct sysinfo sinfo;
> ^
> Makefile:711: recipe for target 'virtual.o' failed
> ~

sysinfo(2) is strictly specific to Linux.

> The code is only called conditionally (ifdef HAVE_SYS_SYSINFO_H).
> 
> It has "include ", which is provided in:
> /usr/include/i386-gnu/sys/sysinfo.h   libc0.3-dev [hurd-i386] 
> /usr/include/i386-kfreebsd-gnu/sys/sysinfo.h  libc0.1-dev [kfreebsd-i386] 
> 
> However "totalram" and "mem_unit" are only in:
> /usr/include/linux/sysinfo.h  linux-libc-dev
> 
> So sysinfo.h exists on hurd/kfreebsd, but doesn't provide everything
> necessary!? Is there a fix for this, or should we disable this code
> on hurd/kfreebsd explicitly? Or am I on a completely wrong track here?

Headers in sys/ and bits/ usually are implementations for the platform;
since sys/sysinfo.h is not standard, you cannot assume that it exists
only on a platform, nor what it provides.  In this case, the upstream
check is wrong: it should not check for sys/sysinfo.h and assume it's
a Linux-ish implementation, but either:
a) just limit the implementation to Linux unconditionally (as in the
   busybox code
b) check for sys/sysinfo.h *and* sysinfo() in it
Considering sysinfo() is not portable anyway, (b) might fail one day
if a platform provide a different implementation with the same name
(it's not standard after all).

Hope it helps -- feel free to ask more.

Thanks,
-- 
Pino Toscano

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

Bug#833957: btrfs-progs: btrfs ERROR send ioctl failed with -2: No such file or directory

[Jakobus Schürz]

Package: btrfs-progs
Version: 4.6.1-1
Severity: important

Dear Maintainer,

Since the last upgrade btrfs send fails with the error-message from the
subject.

It occurs on a "normal" 
btrfs send -p snapshot-older snapshot-newer -f transferfile


Maybe it is the same problem as described here: 
https://patchwork.kernel.org/patch/4238131/

greez

Jakob


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

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

Versions of packages btrfs-progs depends on:
ii  e2fslibs1.43.1-1
ii  libblkid1   2.28-6
ii  libc6   2.23-4
ii  libcomerr2  1.43.1-1
ii  liblzo2-2   2.08-1.2
ii  libuuid12.28-6
ii  zlib1g  1:1.2.8.dfsg-2+b1

btrfs-progs recommends no packages.

btrfs-progs suggests no packages.

-- no debconf information

Bug#825954: ITP on hold due to licensing issue

[Ghislain Vaillant]

This ITP is now on hold due to a licensing problem discovered during
the copyright audit.

The issue is currently being discussed with upstream at:

  https://github.com/obspy/obspy/issues/1492

Best regards,
Ghis

Bug#833955: atop: /etc/init.d/atop* assume that /var/lock/subsys exists

[Marc Haber]

tags #833955 confirmed
thanks

On Wed, Aug 10, 2016 at 10:17:07PM +0200, Vincent Lefevre wrote:
> /etc/init.d/atop and /etc/init.d/atopacct scripts have:
> 
>   touch /var/lock/subsys/atop
>   rm /var/lock/subsys/atop
> 
> and
> 
>   touch /var/lock/subsys/atopacctd
>   rm /var/lock/subsys/atopacctd
> 
> respectively.
> 
> Here the /var/lock/subsys directory doesn't exist, yielding an error
> message, and the file is not created.

Can you try changing that to /run/lock/subsys/atop{acctd} respectively
and re-check? If so, I'm going to patch the init scripts accordingly.

As all my systems are systemd, the init scripts are kind of
undertested. Your efforts are appreciated.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#833954: libfuzzer-3.9-dev: Please provide a programmatic method of finding

[Chris Lamb]

> >It feels a bit ugly and unwieldy to hardcode:
> >
> >  /usr/lib/llvm-3.9/lib/libFuzzer.a
> >
> >.. in my scripts
> 
> What are you expecting? 

I'm not sure. Some kind of "which libfuzzer.a". I'm probably missing something
fundamental about using/finding static libraries; it's not something I regularly
do.


Regards,

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

Bug#833956: wine-development: FTBFS on hurd-i386 and kfreebsd-i386

[Jens Reyer]

Package: wine-development
Version: 1.9.15-1
Severity: normal
User: debian-...@lists.debian.org
Usertags: kfreebsd
User: debian-h...@lists.debian.org
Usertags: hurd


[ I hope I got the CC and tags right, first time I look into a
  portability issue. ]


Hi,

src:wine-development since 1.9.15-1 fails to build on hurd-i386
and kfreebsd-i386. It built successfully before.

The later uploaded src:wine 1.8.3-3 still builds successfully.

Build log for hurd-i386:
https://buildd.debian.org/status/fetch.php?pkg=wine-development=hurd-i386=1.9.15-1=1469253468

Build log kfreebsd-i386:
https://buildd.debian.org/status/fetch.php?pkg=wine-development=kfreebsd-i386=1.9.15-1=1469253097
~
gcc -c -o virtual.o virtual.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_ 
-D_REENTRANT -fPIC -Wall \
  -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body 
-Wignored-qualifiers \
  -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla 
-Wwrite-strings -Wpointer-arith \
  -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -Werror 
-Wdate-time -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-Wno-error
virtual.c: In function 'virtual_get_system_info':
virtual.c:1363:20: error: storage size of 'sinfo' isn't known
 struct sysinfo sinfo;
^
virtual.c:1372:10: warning: implicit declaration of function 'sysinfo' 
[-Wimplicit-function-declaration]
 if (!sysinfo())
  ^
virtual.c:1363:20: warning: unused variable 'sinfo' [-Wunused-variable]
 struct sysinfo sinfo;
^
Makefile:711: recipe for target 'virtual.o' failed
~



I assume (not tested) this is because of:

commit d0832cdf428696e2c08b1aa27382baad4d1e376f
Author: Michael Müller 
Date:   Fri Jul 8 05:40:22 2016 +0200

ntdll: Use sysinfo to report correct number of physical pages.

Signed-off-by: Michael Müller 
Signed-off-by: Sebastian Lackner 
Signed-off-by: Alexandre Julliard 

http://source.winehq.org/git/wine.git/commitdiff/d0832cdf428696e2c08b1aa27382baad4d1e376f



The code is only called conditionally (ifdef HAVE_SYS_SYSINFO_H).

It has "include ", which is provided in:
/usr/include/i386-gnu/sys/sysinfo.h   libc0.3-dev [hurd-i386] 
/usr/include/i386-kfreebsd-gnu/sys/sysinfo.h  libc0.1-dev [kfreebsd-i386] 

However "totalram" and "mem_unit" are only in:
/usr/include/linux/sysinfo.h  linux-libc-dev

So sysinfo.h exists on hurd/kfreebsd, but doesn't provide everything
necessary!? Is there a fix for this, or should we disable this code
on hurd/kfreebsd explicitly? Or am I on a completely wrong track here?
Patches welcome, otherwise I'll ask upstream.

I found a similar (not identical) issue in busybox:
https://bugs.debian.org/677254.
Fix:
https://git.busybox.net/busybox/commit/?id=ac42e3de90ebf4b921035893e3670da63cad882c

Greets
jre

Bug#654918: splix: The printer dosn't print the 2nd and all further pages correct. The 1st is correct.

[Håkan Kvist]

Santiago Vila wrote on 08/08/16 18:33:
> On Fri, 6 Jan 2012, Håkan Kvist wrote:
> 
>> Package: splix
>> Version: 2.0.0+svn293-1
>> Severity: important
>>
>>
>> When printing on a samsun CLP510n, the first page looks ok. The following 
>> pages contains parts of the first page repeated all over the following 
>> page(s)
>> together with black horizontal lines.
>>
>> I belive this is fixed in upstream, identical error have been fixed in 
>> ubuntu:
>> https://bugs.launchpad.net/ubuntu/+source/splix/+bug/714259
>>
>> -- System Information:
>> Debian Release: 6.0.3
> 
> That's Debian 6 (squeeze), and I see that splix had a few more
> releases following SVN since then.
> 
> Can you still reproduce that with Debian 8 (jessie), the current stable?
> 
> Thanks.
> 

Hi,

I haven't got a clue. I got rid of the printer three years ago.

best regards
Håkan

Bug#833955: atop: /etc/init.d/atop* assume that /var/lock/subsys exists

[Vincent Lefevre]

Package: atop
Version: 2.2.3-1~exp1
Severity: minor

/etc/init.d/atop and /etc/init.d/atopacct scripts have:

  touch /var/lock/subsys/atop
  rm /var/lock/subsys/atop

and

  touch /var/lock/subsys/atopacctd
  rm /var/lock/subsys/atopacctd

respectively.

Here the /var/lock/subsys directory doesn't exist, yielding an error
message, and the file is not created.

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

Kernel: Linux 4.6.0-1-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: sysvinit (via /sbin/init)

Versions of packages atop depends on:
ii  init-system-helpers  1.42
ii  initscripts  2.88dsf-59.8
ii  libc62.23-4
ii  libncurses5  6.0+20160625-1
ii  libtinfo56.0+20160625-1
ii  lsb-base 9.20160629
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages atop recommends:
ii  cron [cron-daemon]  3.0pl1-128

atop suggests no packages.

-- no debconf information

Bug#833923: gb cython_0.24.1-1 . s390x .

[Yaroslav Halchenko]

On Wed, 10 Aug 2016, Jakub Wilk wrote:

> * Andreas Tille , 2016-08-10, 14:15:
> >Failed example:
> >   long_double_to_float_int(4.1)
> >Expected:
> >   4.0
> >Got:
> >   0.0

> I couldn't reproduce this on zelenka.d.o. The package built successfully.

> Also, the code this test exercises is pretty straightforward, so I don't
> know what could go wrong here. Perhaps it was a toolchain bug that was fixed
> in the mean time?

Thanks Jakub, let's try to build it again I guess (thus this email to
give back). Dear wb-team, please

gb cython_0.24.1-1 . s390x .

in the hope that it would build fine this time.

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: Digital signature

Bug#833563: libfuzzer-3.8-dev: illegal hardware instruction

[Sylvestre Ledru]

Upstream says that is this the normal behavior and 3.9 is better in signal 
mgmt. 

Le 10 août 2016 21:34:59 GMT+02:00, Chris Lamb  a écrit :
>> zsh: illegal hardware instruction  ./a.out
>
>I don't see this when using libfuzzer-3.9-dev 1:3.9~+rc1-1~exp1. NB.
>3.9, not 3.8.
>
>(Not sure what you want to do with this bug. I mean, it still affects
>libfuzzer-3.8-dev.)
>
>
>Regards,
>
>-- 
>  ,''`.
> : :'  : Chris Lamb
> `. `'`  la...@debian.org / chris-lamb.co.uk
>   `-
>
>___
>Pkg-llvm-team mailing list
>pkg-llvm-t...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team

Bug#820159: llvm: libfuzzer

[Sylvestre Ledru]

Thanks for pushing for that, it is great! 

Le 10 août 2016 21:35:17 GMT+02:00, Chris Lamb  a écrit :
>> > 3.9~+rc1-1~exp1 ? Someone beat me to it!
>>
>> Yes :)
>
>Thanks for uploading!
>
>
>Regards,
>
>-- 
>  ,''`.
> : :'  : Chris Lamb
> `. `'`  la...@debian.org / chris-lamb.co.uk
>   `-

Bug#833954: libfuzzer-3.9-dev: Please provide a programmatic method of finding

[Sylvestre Ledru]

What are you expecting? 

Le 10 août 2016 21:41:39 GMT+02:00, Chris Lamb  a écrit :
>Package: libfuzzer-3.9-dev
>Version: 1:3.9~+rc1-1~exp1
>Severity: wishlist
>
>Hi,
>
>It feels a bit ugly and unwieldy to hardcode:
>
>  /usr/lib/llvm-3.9/lib/libFuzzer.a
>
>.. in my scripts. Can you provide some mechanism for finding it
>programatically? (Is there an existing mechanism that I am missing?)
>
>
>Regards,
>
>-- 
>  ,''`.
> : :'  : Chris Lamb
> `. `'`  la...@debian.org / chris-lamb.co.uk
>   `-
>
>___
>Pkg-llvm-team mailing list
>pkg-llvm-t...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team

Bug#833383: ros-std-msgs: split headers and message definitions

[Jochen Sprickerhof]

Hi Daniele,

* Daniele E. Domenichelli  [2016-08-10 15:19]:
> Thanks! I replied to the comments on github, anyway I'm reporting the
> everything here:

Great, let's move it all over here.

> It would be useful to be able to do something similar anyway, perhaps
> find_package(std_msgs COMPONENTS messages), but I think the CMake files
> are generated and are supposed to be used with catkin and I don't know
> much about it. Suggestions?
> 
> Perhaps I'll just add a Findstd_msgs.cmake to my projects...

(old comment)
Why would you use cmake to find the messages? I would propose to just
keep them in the canonical directory. Otherwise +1.

* Daniele E. Domenichelli  [2016-08-10 08:45]:
> In my CMake project, I would like to do something like this:
> 
> ```cmake
>  find_package(std_msgs REQUIRED)
>  generate_bindings("${std_msgs_MSG_DIR}/std_msgs/String.msg")
> ```

Why not use $CMAKE_INSTALL_DATAROOTDIR or
$CATKIN_GLOBAL_SHARE_DESTINATION? I don't think we need an extra
find*.cmake.

> Attached you will find the 2nd version of the patch.
> I moved the CMake files and the package.xml files back to the original
> package, removed the dependencies, and reverted the changes to the
> changelog file.

Looking great from my side. Maybe we will need some more dependencies
(or recommends) on this package, like for rosmsg for example and we
should add it to the ros-core-dev meta package. What do you think?

> Actually I'm already registered and member of the debian-science group,
> I'm not sure of which permissions I have on the repositories though.
> perhaps when the patch is ready I can try pushing it...

That's great, you should be able to push this, feel free do go ahead :).

Cheers Jochen


signature.asc
Description: PGP signature

Bug#774534: [neon27] racy testsuite

[Christoph Egger]

Hi!

  Would you mind making the testsuite non-fatal until this race is
fixed? I can prepare a NMU as well if you want me to. The failure's
currently blocking also libreoffice to build on !linux

  Christoph
  
-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Bug#798106: suggested patch

[Dieter Adriaenssens]

Control: tags -1 patch

Dear maintainer,

Please find a suggestion for a patch in attachment that solves this bug.

This patch changes the text suggesting that a 2048 bit key (or longer,
preferably 4096 bit) should be used and changes the link to the reference
that explains why this should be done.

-- 
Kind regards,

Dieter Adriaenssens
diff --git a/common.ent b/common.ent
index 812a800..eeaab54 100644
--- a/common.ent
+++ b/common.ent
@@ -97,6 +97,7 @@
 https:///devel/join/nm-step2;>
 https:///doc/maint-guide/;>
 https://wiki.debian.org/Keysigning;>
+https:///debian-devel-announce/2010/09/msg3.html;>
 https:///security/;>
 https:///devel/tech-ctte;>
 https://qa.debian.org/developer.php;>
diff --git a/new-maintainer.dbk b/new-maintainer.dbk
index 5ee79ab..79d0817 100644
--- a/new-maintainer.dbk
+++ b/new-maintainer.dbk
@@ -150,8 +150,9 @@ url="">RFC 2440.
 
 
 You need a version 4 key for use in Debian Development. https://lists.debian.org/20090520092534.gg22...@earth.li;>Your key length must
-be greater than 1024 bits; there is no reason to use a smaller key, and doing so
+url="">Your key length must
+be greater than 2048 bits (4096 bits is preferred);
+there is no reason to use a smaller key, and doing so
 would be much less secure. Version 4 keys are keys conforming
 to the OpenPGP standard as defined in RFC 2440.  Version 4 is the key type that
 has always been created when using GnuPG.  PGP versions since 5.x also could

Bug#833954: libfuzzer-3.9-dev: Please provide a programmatic method of finding

[Chris Lamb]

Package: libfuzzer-3.9-dev
Version: 1:3.9~+rc1-1~exp1
Severity: wishlist

Hi,

It feels a bit ugly and unwieldy to hardcode:

  /usr/lib/llvm-3.9/lib/libFuzzer.a

.. in my scripts. Can you provide some mechanism for finding it
programatically? (Is there an existing mechanism that I am missing?)


Regards,

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

Bug#820159: llvm: libfuzzer

[Chris Lamb]

> > 3.9~+rc1-1~exp1 ? Someone beat me to it!
>
> Yes :)

Thanks for uploading!


Regards,

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

Bug#833563: libfuzzer-3.8-dev: illegal hardware instruction

[Chris Lamb]

> zsh: illegal hardware instruction  ./a.out

I don't see this when using libfuzzer-3.9-dev 1:3.9~+rc1-1~exp1. NB.
3.9, not 3.8.

(Not sure what you want to do with this bug. I mean, it still affects
libfuzzer-3.8-dev.)


Regards,

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

Bug#833536: pkg-haskell-tools: dht should allow uploading by FTP

[Sven Bartscher]

On Mon, 8 Aug 2016 22:23:36 +
Sean Whitton  wrote:

> On Fri, Aug 05, 2016 at 07:19:47PM -0400, Joachim Breitner wrote:
> > With "someone" I meant me, not you: "dht upload" should just call dput,
> > and I should be able to tell dput to use ssh-upload by default.  
> 
> Oh, I see.
> 
> I'm inclined to agree with Sven that dht should default to SSH because
> DDs often use it to make huge numbers of uploads, and it would be a pain
> to sort it out if some of them failed.

I can't remember saying dht should default to SSH and rather think that
dht should honour the default set in dput.cf (see my other post for a
brief description of how to do that).

Regards
Sven


pgplN5uOuxeKo.pgp
Description: Digitale Signatur von OpenPGP

Bug#811965: libqt4pas: FTBFS with GCC 6: symbol changes

[Paul Gevers]

Control: owner -1 !

Just so it is known, I started on updating the symbols file. However I
need my access to debomatic renewed to be able to check what I did for
amd64 and armhf and to learn what to update for the other archs.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#833953: chromium: immediately crashes with signal 8 (FPE_INTDIV)

[Johannes Berg]

Package: chromium
Version: 52.0.2743.116-2
Severity: important

I can't seem to find a match debug symbol package, so the stack trace is pretty 
useless:

Received signal 8 FPE_INTDIV 7fbca198104f
#0 0x564dc961a12e 
#1 0x564dc961a4e9 
#2 0x7fbc9b21ded0 
#3 0x7fbca198104f 
#4 0x7fbca19a20db 
#5 0x7fbca198530a hb_shape_plan_execute
#6 0x7fbca1984831 hb_shape_full
[...]
  r8: 564dd1de9630  r9:  r10: 7fbca1bd0660 r11: 
fffaacdf
 r12: 564dd1de9700 r13: 564dd1e12470 r14: 7ffc51167f5c r15: 
564dd1de9700
  di:   si: 0011  bp: 7ffc51167f58  bx: 
7ffc51167f5c
  dx:   ax:   cx: 0001  sp: 
7ffc51167ee0
  ip: 7fbca198104f efl: 00010206 cgf: 002b0033 erf: 

 trp:  msk:  cr2: 
[end of stack trace]

Symptom is that I can't load any page (not even chrome://version or similar)
but just get "Aw, Snap!" instead.

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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.2-1
ii  libatk1.0-0  2.20.0-1
ii  libavcodec57 7:3.1.1-4
ii  libavformat577:3.1.1-4
ii  libavutil55  7:3.1.1-4
ii  libc62.23-4
ii  libcairo21.14.6-1+b1
ii  libcups2 2.1.4-4
ii  libdbus-1-3  1.10.8-1
ii  libexpat12.2.0-1
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.1.1-10
ii  libgdk-pixbuf2.0-0   2.32.3-2
ii  libglib2.0-0 2.48.1-2
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk-3-0   3.20.7-1
ii  libharfbuzz0b1.0.1-1+b1
ii  libjpeg62-turbo  1:1.5.0-1
ii  libnettle6   3.2-1
ii  libnspr4 2:4.12-2
ii  libnspr4-0d  2:4.12-2
ii  libnss3  2:3.25-1
ii  libnss3-1d   2:3.25-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpci3  1:3.3.1-1.1
ii  libpulse08.0-2+b2
ii  libspeechd2  0.8.4-2
ii  libstdc++6   6.1.1-10
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxi6   2:1.7.6-1
ii  libxml2  2.9.4+dfsg1-1+b1
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxslt1.1   1.1.28-4
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1

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

Versions of packages chromium suggests:
pn  chromium-l10n  

-- no debconf information