date:20161102

Bug#814110: (no subject)

2016-11-02 Thread Stijn Tintel

Reported upstream: https://bugzilla.kernel.org/show_bug.cgi?id=186701

Bug#843017: add support for npm dist tarballs

2016-11-02 Thread Pirate Praveen

package: qa.debian.org
severity: wishlist
Control: block 840967 by -1

Most npm modules tag their github repos, but many does not have tags.
When an npm module's github repo is missing tags, npm2deb creates a
watch file pointing to http://qa.debian.org/cgi-bin/fakeupstream.cgi

It would be good to have such an option. Steps to get tarball from npm
registry is here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840967



signature.asc
Description: OpenPGP digital signature

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

2016-11-02 Thread Andreas Henriksson

Hello Kurt Roeckx.

On Sun, Jun 26, 2016 at 12:21:39PM +0200, Kurt Roeckx wrote:
> Source: fetchmail
> Version: 6.3.26-2
> Severity: important
> Control: block 827061 by -1
> 
> Hi,
> 
> OpenSSL 1.1.0 is about to released.
[...]
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/fetchmail_6.3.26-2_amd64-20160529-1418
[...]

The failure in this build log didn't look like it was really openssl related.
I've tried rebuilding the package which succeded for me.

Could you please double-check here and possibly close this bug report
if there's no issue?

Regards,
Andreas Henriksson

Bug#843014: Apache2: ServerTokens Minimal

2016-11-02 Thread Heinrich Schuchardt

Package: apache2
Version: 2.4.23-5
Severity: wishlist

Dear maintainer,

/etc/apache2/conf-available/security.conf currently defaults to
ServerTokens OS

This results in a header like:
Server: Apache/2.4.10 (Debian)

Sending the Apache and OS version is a waste of bandwidth.
Unfortunately Apache does not allow to completely suppress this
superfluous header.

Furthermore the current setting exposes valuable information to a
possible intruder:
Why should any HTTP client care which OS my server is using?

Please, change the default to
ServerTokens Minimal

Best regards

Heinrich Schuchardt

Bug#841877: Don't recommend contacting base-passwd maintainer for dynamic UIDs

2016-11-02 Thread Didier 'OdyX' Raboud

Le lundi, 24 octobre 2016, 07.23:30 h CET Colin Watson a écrit :
> Control: tag -1 patch
> 
> On Sun, Oct 23, 2016 at 08:00:23PM -0700, Sean Whitton wrote:
> > Policy section "Permissions and owners" probably shouldn't recommend
> > contacting the base-passwd maintainer when selecting a username for a
> > dynamically-allocated UID created by a postinst maintscript.  It should
> > continue to recommend contacting the base-passwd maintainer when the
> > postinst script needs to create a static UID.
> 
> I (obviously) agree.  How about this patch?  I'm seeking seconds for
> this proposal.
> 
> diff --git a/policy.sgml b/policy.sgml
> index 9cd182b..ab4f736 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -9610,9 +9610,7 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
> that a dynamically allocated id can be used.  In this case
> you should choose an appropriate user or group name,
> discussing this on debian-devel and checking
> -   with the  -   they do not wish you to use a statically allocated id
> -   instead.  When this has been checked you must arrange for
> +   that it is unique.  When this has been checked you must arrange for
> your package to create the user or group if necessary using
> adduser in the preinst or
> postinst script (again, the latter is to be

Seconded.

-- 
Cheers,
OdyX

Bug#843015: Heavy swapping and OOM without visible cause

2016-11-02 Thread Spock

Package: linux-image-3.16.0-4-amd64
Version: 3.16.36-1+deb8u1

I am running Debian 8.6 Linux 3.16.0-4-amd64 #1 SMP Debian
3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux under KVM or XEN on
several servers.
The VM is 4cpu with 4G mem, running transparent squid proxying with
netfilter redirection and some custom squid url rewrite

>From time to time system comes into memory pressure mode without any
visible reasons for it. Swap gets exausted, and OOM killler is
invoked.
Taking "ps axu" snapshot and summing all the RSS values with file
pages and slab pages does not come even close to the memory limit.
The sum of numbers from /proc/zoneinfo - anon + file + slab + free -
does not correlate with the total pages counter for both normal and
dma32 zones

On another VM, which does not show the problem atm, zone numbers are
fine and sum up nicely


/proc/meminfo:
MemTotal:4060648 kB
MemFree:  219024 kB
MemAvailable: 188900 kB
Buffers:1216 kB
Cached:75408 kB
SwapCached: 7096 kB
Active:   679800 kB
Inactive: 412424 kB
Active(anon): 649008 kB
Inactive(anon):   398848 kB
Active(file):  30792 kB
Inactive(file):13576 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:   1355772 kB
SwapFree: 511084 kB
Dirty:   116 kB
Writeback: 0 kB
AnonPages:   1008660 kB
Mapped:22724 kB
Shmem: 32256 kB
Slab: 373140 kB
SReclaimable:  64320 kB
SUnreclaim:   308820 kB
KernelStack:2320 kB
PageTables: 8820 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 3386096 kB
Committed_AS:2194392 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   13252 kB
VmallocChunk:   34359651740 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:   61308 kB
DirectMap2M: 4132864 kB


/proc/zoneinfo:
Node 0, zone  DMA
  pages free 3972
min  66
low  82
high 99
scanned  0
spanned  4095
present  3998
managed  3977
nr_free_pages 3972
nr_alloc_batch 17
nr_inactive_anon 0
nr_active_anon 0
nr_inactive_file 0
nr_active_file 0
nr_unevictable 0
nr_mlock 0
nr_anon_pages 0
nr_mapped0
nr_file_pages 0
nr_dirty 0
nr_writeback 0
nr_slab_reclaimable 1
nr_slab_unreclaimable 0
nr_page_table_pages 0
nr_kernel_stack 0
nr_unstable  0
nr_bounce0
nr_vmscan_write 0
nr_vmscan_immediate_reclaim 0
nr_writeback_temp 0
nr_isolated_anon 0
nr_isolated_file 0
nr_shmem 0
nr_dirtied   0
nr_written   0
numa_hit 107
numa_miss0
numa_foreign 0
numa_interleave 0
numa_local   107
numa_other   0
workingset_refault 0
workingset_activate 0
workingset_nodereclaim 0
nr_anon_transparent_hugepages 0
nr_free_cma  0
protection: (0, 2980, 3947, 3947)
  pagesets
cpu: 0
  count: 0
  high:  0
  batch: 1
  vm stats threshold: 4
cpu: 1
  count: 0
  high:  0
  batch: 1
  vm stats threshold: 4
cpu: 2
  count: 0
  high:  0
  batch: 1
  vm stats threshold: 4
cpu: 3
  count: 0
  high:  0
  batch: 1
  vm stats threshold: 4
  all_unreclaimable: 1
  start_pfn: 1
  inactive_ratio:1
Node 0, zoneDMA32
  pages free 44315
min  12710
low  15887
high 19065
scanned  0
spanned  1044480
present  782303
managed  763684
nr_free_pages 44315
nr_alloc_batch 3178
nr_inactive_anon 31650
nr_active_anon 126489
nr_inactive_file 60
nr_active_file 605
nr_unevictable 0
nr_mlock 0
nr_anon_pages 151875
nr_mapped324
nr_file_pages 6936
nr_dirty 8
nr_writeback 0
nr_slab_reclaimable 10322
nr_slab_unreclaimable 45149
nr_page_table_pages 1198
nr_kernel_stack 80
nr_unstable  0
nr_bounce0
nr_vmscan_write 325108
nr_vmscan_immediate_reclaim 143
nr_writeback_temp 0
nr_isolated_anon 0
nr_isolated_file 0
nr_shmem 5629
nr_dirtied   8576779
nr_written   8609273
numa_hit 7100373882
numa_miss0
numa_foreign 0
numa_interleave 0
numa_local   7100373882
numa_other   0
workingset_refault 131027
workingset_activate 21359
workingset_nodereclaim 0
nr_anon_transparent_hugepages 0
nr_free_cma  0
protection: (0, 0, 966, 966)
  pagesets
cpu: 0
  count: 6
  high:  186
  batch: 31
  vm stats threshold: 36
cpu: 1
  count: 0
  h

Bug#843016: ITP: node-meow -- Command-line interface app helper

2016-11-02 Thread Sruthi Chandran

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-meow
  Version : 3.7.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/meow#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Command-line interface app helper

Bug#840470: Pending fixes for bugs in the libimage-info-perl package

2016-11-02 Thread pkg-perl-maintainers

tag 840470 + pending
thanks

Some bugs in the libimage-info-perl package are closed in revision
2064f64d3117b1cdecc12ccc452de7cee4346a31 in branch 'master' by
Salvatore Bonaccorso

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libimage-info-perl.git/commit/?id=2064f64

Commit message:

Remove deprecation note in long description

Closes: #840470

Bug#842239: Arbitrary document metadata date chosen

2016-11-02 Thread martin f krafft

also sprach Jeffrey Ratcliffe  [2016-11-02 21:59 
+0100]:
> As of v1.5.0, the document date metadata field defaults to the
> previous date used. I made this change to fix time zone problems
> people near the international date line were having.

Weird. Does the concept of NOW() or TODAY() fade near the dateline?

> For the next version, I have gone back to storing an date offset,
> using a new dependency to calculate them. I hope that this will
> make everyone happier.

Ok. Thanks for all your help!

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"mein gott, selbst ein huhn kann debian installieren, wenn du genug
 koerner auf die enter-taste legst."
   -- thomas koehler in de.alt.sysadmin.recovery


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#842928: [pkg-boost-devel] Bug#842928: libboost-python1.62.0 exports Python 2 symbols for Python 3

2016-11-02 Thread Steve M. Robbins

On Wednesday, November 2, 2016 12:46:41 PM CDT Khoyo wrote:
> Package: libboost-python1.62.0
> 
> Version: 1.62.0+dfsg-2
> 
> This fails with libboost-python 1.62, but works with 1.61:
> 
>  % g++ -I/usr/include/python3.5m/ conftest.cc -lboost_python-py35
> -lpython3.5m /tmp/cc6JvhrE.o: In function `PyInit_empty':


Can you send "conftest.cc" -- or some other file -- so we can reproduce?

Thanks,
-Steve


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

Bug#843013: xorg: Switching from VT console disables keyboard

2016-11-02 Thread Rob Browning


Package: xorg
Version: 1:7.7+16

So for some months now, I think, I've found that given two X sessions on
different VTs, occasionally when switching between them, the session I
switched to would become unresponsive to the external (USB) keyboard and
mouse, and the only way I was able to restore access was to log
completely out of X completely and back in.  The consoles themselves
appeared to be unaffected.  So I poked at the problem a a bit, and
looked around for similar reports, but hadn't found anything I thought
might be useful until now.  Now I suspect this might describe the issue,
and a fix:

  https://bugs.freedesktop.org/show_bug.cgi?id=97880

I don't know if it'd be plausible to include that in Debian right now,
nor if it actually addresses my problem, but I'd certainly be happy to
stop having to log out regularly.

And I'm not sure I've built xorg in a long time (if ever), but if I
manage to to try the patches myself, I'll post an update.

(Possibly also related: https://bugs.freedesktop.org/show_bug.cgi?id=97928)

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#843012: libcsp: CVE-2016-8596 CVE-2016-8597 CVE-2016-8598

2016-11-02 Thread Salvatore Bonaccorso

Source: libcsp
Version: 1.4+fdd49b7+dfsg-3
Severity: grave
Tags: security upstream patch

Hi,

the following vulnerabilities were published for libcsp.

CVE-2016-8596[0]:
| Buffer overflow in the csp_can_process_frame in csp_if_can.c in the
| libcsp library v1.4 and earlier allows hostile components connected to
| the canbus to execute arbitrary code via a long csp packet.

CVE-2016-8597[1]:
| Buffer overflow in the csp_sfp_recv_fp in csp_sfp.c in the libcsp
| library v1.4 and earlier allows hostile components with network access
| to the SFP underlying network layers to execute arbitrary code via
| specially crafted SFP packets.

CVE-2016-8598[2]:
| Buffer overflow in the zmq interface in csp_if_zmqhub.c in the libcsp
| library v1.4 and earlier allows hostile computers connected via a zmq
| interface to execute arbitrary code via a long packet.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-8596
[1] https://security-tracker.debian.org/tracker/CVE-2016-8597
[2] https://security-tracker.debian.org/tracker/CVE-2016-8598

Regards,
Salvatore

Bug#842015: [pkg-gnupg-maint] Bug#842015: Bug#842015: Similar issue, no emacs

2016-11-02 Thread Vincent Lefevre

On 2016-11-02 23:52:43 -0400, Daniel Kahn Gillmor wrote:
> I think we ought to take the "systemd" meme out of discussion here.  I
> think it's being used by conflation with "d-bus", and that confusion is
> unlikely to be helpful in resolving these issues.
[...]

Thanks for the explanations. So, the problem seems to be related
to d-bus (which itself may be related to systemd). When I ssh
to my machine with sysvinit (for which there are no problems),
DBUS_SESSION_BUS_ADDRESS is unset, while when I ssh to my
machine with systemd, DBUS_SESSION_BUS_ADDRESS is set to
"unix:path=/run/user/1000/bus" (i.e. the same as in the physical
X session, so I'm wondering whether this is correct!).

When I ssh to my machine where DBUS_SESSION_BUS_ADDRESS is set,
if I run "gpg -d file.gpg", it doesn't work. If I unset this
environment variable and try again, it still doesn't work, but
that's probably because the gpg-agent that is running (due to
the previous test) has DBUS_SESSION_BUS_ADDRESS set in its
environment. So, if I try again after killing the running
gpg-agent, it works, i.e. I can type my passphrase from the
curses UI.

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

Bug#842939: WOT found guilty to sell user data

2016-11-02 Thread kpcyrd

I've had a look at the source and I can confirm the tracking code is present in 
debian.

Please read this blog post first:
https://www.kuketz-blog.de/wot-addon-wie-ein-browser-addon-seine-nutzer-ausspaeht/
 (German)
https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fwww.kuketz-blog.de%2Fwot-addon-wie-ein-browser-addon-seine-nutzer-ausspaeht%2F
 (English)

It's worth a read, the tl;dr is: the author discovered the addon is
sending your browser history together with a unique identifier to mywot
servers. The author then setup a virtual machine with linux, firefox and
no addons besides WOT. Later, the canary dataset was found inside the
data dump that was acquired by the NDR.

This is the version >= stretch:

There's an event handler for `onLocationChange` that is passing the tab
location to `wot_stats.loc`:

```
if (tabUrl && wot_stats.isWebURL(tabUrl)) {
var ref = browser.contentDocument.referrer;
if (request && request.referrer && 
typeof(request.referrer) != undefined) {
ref = request.referrer.asciiSpec;
}

wot_stats.loc(tabUrl, ref);
}
```
https://sources.debian.net/src/wot/20151208-2/content/core.js/#L81

`wot_stats.loc` is then calling `wot_stats.query`, which is sending the
data to a server (https://secure.mywot.com at the point of writing. The
endpoint is remotely configurable, I'll cover that later). I've marked
the comments that are added by myself.

```
data = {
"s":WOT_STATS.SID,
"md":21,
"pid":wot_stats.getUserId(),
"sess":wot_stats.getSession()['id'],
"q":encodeURIComponent(url), //(kpcyrd): this is the current url
"prev":encodeURIComponent(wot_stats.last_prev), //(kpcyrd): this is 
the previously seen url
"link":0,
"sub": "ff",
"tmv": WOT_STATS.VER,
"hreferer" : encodeURIComponent(ref), //(kpcyrd): this seems to be 
a referer, but I didn't investigate further
"ts" : wot_stats.utils.getCurrentTime()
};

var requestDataInfo = this.utils.serialize(data);
var requestData = requestDataInfo.data;
var requestLength = requestDataInfo.length;

var encoded = btoa(btoa(requestData)); //(kpcyrd): base64 encode twice
if (encoded != "") {
var data = "e=" + encodeURIComponent(encoded);
var statsUrl = settings[this.urlKey] + "/valid"; //(kpcyrd): get 
the endpoint from the config
this.utils.postRequest(statsUrl, data, requestLength); //(kpcyrd): 
send data to the server, there's a unique identifier in the cookies
}
this.last_prev = url; //(kpcyrd): set the current url as previous url 
for the next request

```
https://sources.debian.net/src/wot/20151208-2/content/stats.js/#L280

After decoding the base64, the resulting request looks like this:
https://media.kuketz.de/blog/artikel/2016/wot-addon/unmaskiert2.jpg

As far as I can tell, this is happening for every page load.

The endpoint for that data is dynamic, it's fetched from
https://secure.mywot.com/config when you provide the correct parameters:

```
$ curl 'https://secure.mywot.com/config?s=241&ins=1478145149&ver=1.0'
{"ok":1,"url":"https://secure.mywot.com"}
```

Not sure why it's working like this, I assume it's to obfuscate the
endpoint they're sending data to. The code between this fetch and the
usage quoted above is unnecessary complicated. It could also be used to
bypass firewalls trying to block this.

The data that is sent with this tracking script has huge implications on
privacy, but since these are full urls (hostname, path, querystring,
anchor/fragment) this causes significant implications on security,
especially for applications that store sensitive information in query
strings.

I've also had a quick look at the version in jessie and it looks like
it's "only" operating on hostnames, but when you actually look into some
of the util functions, this doesn't seem to be the case.

```
onLocationChange: function(progress, request, location)
{
if (progress.DOMWindow != this.browser.contentWindow) {
return;
}

if (location) {
wot_core.block(this, request, location.spec); 
//(kpcyrd): this sends data to the server
}
wot_core.update();
},

```
https://sources.debian.net/src/wot/20131118-1/chrome/wot.jar%21/content/core.js/#L62


```
block: function(pl, request, url)
{
try {
if (!wot_util.isenabled() || !pl || !pl.browser || 
!url) {
return;
}

if (!wot_warning.isblocking())

Bug#828309: getdns: FTBFS with openssl 1.1.0

2016-11-02 Thread Scott Kitterman

On Sun, 26 Jun 2016 12:21:45 +0200 Kurt Roeckx  wrote:
> Source: getdns
> Version: 0.9.0-1
> Severity: important
> Control: block 827061 by -1
> 
> Hi,
> 
> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> OpenSSL this package fail to build.  A log of that build can be found at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/getdns_0.9.0-1_amd64-20160530-2108
> 
> On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of 
the
> reasons why it might fail.  There are also updated man pages at
> https://www.openssl.org/docs/manmaster/ that should contain useful 
information.
> 
> There is a libssl-dev package available in experimental that contains a 
recent
> snapshot, I suggest you try building against that to see if everything 
works.
> 
> If you have problems making things work, feel free to contact us.

getdns v1.1.0-a2, which was released two weeks ago supports openssl 1.1.0.  I 
haven't tested it yet.

Scott K

Bug#842814: memcached: CVE-2016-8706

2016-11-02 Thread Salvatore Bonaccorso

Hi Guillaume,

On Thu, Nov 03, 2016 at 03:17:27AM +0100, Guillaume Delacour wrote:
> Please see attached the debdiff.
> Also, please note that i can't upload myself to security-master as i'm
> not a DD nor DM.

I actually did already earlier this week, but I have not released yet
the DSA text. Sorry for not notifying the bug.

Are you working on an unstable upload?

Regards,
Salvatore

Bug#813658: virglrenderer support before the freeze?

2016-11-02 Thread Michael Tokarev

03.11.2016 01:24, Hillel Lubman wrote:
> Hi.
> 
> Do you plan to add --enable-virglrenderer to the qemu build? Freeze is
> very close, and it would be good to have this feature in before it.

The prob is that currently, with sdl1, virglrenderer doesn't quite
work. It works with sdl2 or gtk frontends, sdl1 support is very
limited.

So in order for virglrenderer to be useful, other changes are needed.
Which I'm currently evaluating.  The prob is that I tried to switch
to sdl2 before already, users complained about missing features which
were found in sdl1 support. Now it's probably best to switch to gtk
as it is the default since upstream 2.7 version (or 2.7+, I'm not sure).
Which brings up other libraries, and users already complained about
too much graphics dependencies in qemu.

The best would be to enable modular display support, the same way as
we did for block devices.  But unfortunately this fails now for sdl1,
which tends to replace main() function.  I tried to implement it, and
it almost works, except of the sdl1 issue.

Thanks,

/mjt

Bug#802303: #802303: libpetsc3.6.2-dev: arch-dependent file in "Multi-Arch: same" package

2016-11-02 Thread Drew Parsons

I see what's going on a little better. The filepatch
/usr/share/python/runtime.d/libpetsc3.6.2-dev.rtupdate is common to all
arches, but its contents are architecture specific, which breaks Multi-
Arch:same.

Since that file was generated by dh_python2, it indicates that
dh_python2 is not [sufficiently] multiarch aware.  Perhaps related to
bug#798491.

But the actual python scripts themselves (.py in
/usr/lib/petscdir/3.7.4/x86_64-linux-gnu-real/bin) don't seem to be
architecture specific.  I wonder if it makes sense to split them off to
a common /usr/lib/petscdir/3.7.4/python dir.

Bug#843011: git: git.maintscript dir_to_symlink commands are missing 2nd path

2016-11-02 Thread Justin Geibel

Package: git
Version: 1:2.10.2-1
Severity: important

Dear Maintainer,

Lines 3 and 4 in the git.maintscript file are missing the second path
(new-target).

dir_to_symlink /usr/share/doc/git/contrib/hooks 1:1.7.7-1
dir_to_symlink /usr/share/doc/git/contrib/emacs 1:1.7.4~rc1-0.1

The format as specified by `man dpkg-maintscript-helper`:

dir_to_symlink pathname new-target [prior-version [package]]

I believe these lines should be changed to:

dir_to_symlink /usr/share/doc/git/contrib/hooks
../../../git-core/contrib/hooks 1:1.7.7-1
dir_to_symlink /usr/share/doc/git/contrib/emacs
../../../git-core/contrib/emacs 1:1.7.4~rc1-0.1

Finally, I believe that this is related to bug #676316 (wishlist bug to use
dpkg-mainter-helper scripts) which can probably now be closed.

Thanks,
Justin

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

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

Bug#761177: python-sparqlwrapper: New version [...] available

2016-11-02 Thread chrysn

Bonjour, Olivier,

On Mon, Oct 31, 2016 at 06:15:45PM +0100, chrysn wrote:
> There seem not to be too big stoppers on the road; just updating the
> package with uscan and a version bump in dch produced a package good
> enough for rdflib package updates to continue (at least the built-time
> test suite which depends on sparqlwrapper runs through now).

the rdflib update this is blocking (and which aff4 and python-prov are
waiting for) is almost ready for upload, but is locally built only
against a quick-and-dirty version of the new sparqlwrapper.

Apart from the required uscan run, all the package needs AFAICT is
updating the copyright file with the new fourth author from AUTHORS.md,
bumping compat and standards-version (without further changes) and
`s/(Python \(.\))/\1/` on the package description lines just if you want
to make lintian very happy.

I'm unfamiliar with the SVN workflows, so I could only offer to prepare
an NMU, but that might cause more work later in SVN than doing it right
the first time.

Can you spare some time to update it, shall I turn to DPMT for
assistance with the SVN for a team upload, or would you prefer me to
prepare an NMU (which I'd still need a sponsor for)?

All the best
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

signature.asc
Description: PGP signature

Bug#843010: elmerfem: hypre headers in /usr/include/hypre

2016-11-02 Thread Drew Parsons

Source: elmerfem
Version: 6.1.0.svn.5396.dfsg2-4
Severity: normal

hypre is now updated to 2.11.1.

The main impact that effects elmer is that the hypre header files have
been moved from the common directory to /usr/include/hypre.

Depending on how the elmer build scripts search for hypre, it's
possible they may need to be patched to look in the hypre subdir (if
they use something like "find /usr/include -name HYPRE.h" then no
patch would be needed).  Or there may be a place to add to CFLAGS
-I/usr/include/hypre.

Alternatively client files could be patched from
#include 
to
#include 

Cheers,
Drew



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

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

Bug#842015: [pkg-gnupg-maint] Bug#842015: Bug#842015: Similar issue, no emacs

2016-11-02 Thread Daniel Kahn Gillmor

On Wed 2016-11-02 06:25:25 -0400, Vincent Lefevre wrote:
> I think that this might be related with systemd. I have reported
> another bug (bug 842908) as actually gnupg does not work *at all*
> via SSH without $DISPLAY on one of my machines with systemd, even
> when there isn't a running gpg-agent (the problem is different:
> I just get an obscure error message). On another machine without
> systemd, there is no such problem.

I think we ought to take the "systemd" meme out of discussion here.  I
think it's being used by conflation with "d-bus", and that confusion is
unlikely to be helpful in resolving these issues.

a bit of background:

 * there are at least three different mechanisms that the GnuPG suite
   can communicate with the current user when needed:

0) via a terminal (or pseudoterminal, terminal emulator, etc)

1) via X11

2) via d-bus

 * all of these mechanisms are potentially available in multiple ways on
   a standard GNU/Linux system.  That is, there is (or can be) multiple
   terminals, X11 sessions, or dbus sessions running concurrently.

 * for each mechanism, there are specific environment variables that are
   used to select which communications pathway to use.  For terminals,
   we use $GPG_TTY; for X11, we use $DISPLAY and $XAUTHORITY; and for
   d-bus we use $DBUS_SESSION_BUS_ADDRESS

 * gpg no longer handles secret key material at all.  Instead, it talks
   to gpg-agent, which handles secret key material for it.

 * if gpg-agent isn't currently running, gpg will auto-launch a copy of
   the agent, which then persists.

 * When an invocation of gpg needs to use secret key material, it will
   ask gpg-agent to do the secret key operation.  gpg-agent knows
   whether it has permission to unlock the secret key material or not.
   If it does, it uses it without interaction.  If it does not, it must
   prompt the user, either for simple confirmation, or for a passphrase.

 * when gpg-agent needs to talk to the user, it invokes pinentry.

 * gpg passes its current best guess of relevant env vars to gpg-agent,
   which in turn sets them up appropriately for pinentry if pinentry is
   invoked.

So the path to the user's prompt is:

  gpg → gpg-agent → pinentry

And note that gpg-agent may or may not have been started using the same
session information that the current run of gpg has access to.  And some
gpg instances don't have access to some of the communications channels,
even if gpg-agent itself did have that access.

Furthermore, the choice of pinentry also constrains what kind of user
communication is possible.  Different pinentry programs can take
advantage of different user communication details:

 * pinentry-curses, pinentry-tty: terminal only.  If gpg isn't directly
   connected to a terminal, or doesn't know $GPG_TTY, then gpg-agent
   simply has to guess what terminal to use.

 * pinentry-gtk-2, pinentry-qt: X11, fallback to terminal if $DISPLAY
   isn't available

 * pinentry-gnome3: d-bus, fallback to terminal if d-bus connectivity
   fails (this is actually somehow mixed at the moment; it's not clear
   whether pinentry should fall back to the terminal only if
   $DBUS_SESSION_BUS_ADDRESS is unset, or whether it should *also*
   fallback to the terminal if the prompting agent itself is
   unavailable; i lean toward the latter, but Werner has declined a
   patch that makes that happen)

I note that we have no pinentry program that is capable of taking
advantage of all three possible messaging routes.

So there are a few places where this can fall down:

 0) gpg can not know the locations to recommend for prompting (e.g. when
run with no tty attached at all and a clean environment) -- in this
case, it cannot launch an effective gpg-agent, or communicate with
an existing gpg-agent to instruct it where the pinentry should
appear.

 1) a running gpg-agent process may or may not be attached to the same
communications callback mechanisms that a communicating gpg process
has.

 2) under an ssh connection, only a terminal-based pinentry will work
unless the ssh session has forwarded X11 (which is itself a risky
thing to do).  ssh has no built-in, well-supported mechanism for
forwarding d-bus connections.  Also, note that it's possible (and
even likely on some machines) to have a dbus session running
associated with an ssh login, but a non-X11 dbus session will be
unable to display a graphical (GNOME3) prompt.

Of course, regular users shouldn't have to know about any of this, i'm
just trying to clarify the inter-process communications for people who
want to help resolve the issue.  Is this analysis missing anything?

Does anyone have any suggestions for what the right next steps are?

 --dkg

signature.asc
Description: PGP signature

Bug#843009: djvulibre-bin: any2djvu fails, as server location has changed

2016-11-02 Thread Dylan Thurston

Package: djvulibre-bin
Version: 3.5.27.1-6
Severity: normal

The 'any2djvu' binary has the URL http://any2djvu.djvuzone.org
hard-coded, but that URL doesn't work any more. Output below, but it
doesn't say much. The service appears to have moved to the djvu.org
domain.


dpt@tulip:/tmp$ touch t.pdf
dpt@tulip:/tmp$ any2djvu t.pdf
/-- Started Thu Nov  3 02:36:42 UTC 2016: dpt@tulip, pid 11222: 
/usr/bin/any2djvu (cwd /tmp)
WARNING!

any2djvu uses an external server which is willing to perform the
conversion and requires the document transfer over to that server.
There is a security issue in operating on documents not intended for
widespread distribution, which could be partially although not
completely ameliorated by using a secure web connection.

Do you acknowledge and allow the transmission of the document?
(Type 'yes' to acknowledge. You can define non-empty environment
 variable DJVU_ONLINE_ACK to avoid seeing this dialog, or use -a
 command line parameter to any2djvu).
[yes/no]:yes
Thu Nov 3 02:36:44 UTC 2016 Processing t ...
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  1837  100  1147  100   690750451  0:00:01  0:00:01 --:--:--   749


 301 Moved Permanently


 
301
Moved Permanently

The document has been permanently moved.

Proudly powered by  http://www.litespeedtech.com/error-page";>LiteSpeed Web 
ServerPlease be advised that LiteSpeed Technologies Inc. is not a web 
hosting company and, as such, has no control over content found on this 
site.
error: something got wrong. check log file


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

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

Versions of packages djvulibre-bin depends on:
ii  curl7.50.1-1
ii  libc6   2.24-5
ii  libdjvulibre21  3.5.27.1-6
ii  libgcc1 1:6.2.0-10
ii  libstdc++6  6.2.0-10
ii  libtiff54.0.6-3

Versions of packages djvulibre-bin recommends:
pn  pdf2djvu  

Versions of packages djvulibre-bin suggests:
ii  djview4 [djvu-viewer]4.10.6-1
ii  djvulibre-desktop3.5.27.1-6
ii  evince [djvu-viewer] 3.22.1-2
ii  okular-extra-backends [djvu-viewer]  4:16.08.2-1

-- no debconf information

Bug#842778: Acknowledgement (option to turn of "forget new" dialog?)

2016-11-02 Thread Harald Dunkel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sorry, I lost focus on #833310. Thanx for merging

Harri

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYGq2JAAoJEAqeKp5m04HLDnUH/0EAbd5r1UdYzLCpEStIk8tH
TxITM439A6ZkC2j4hWYl7BkVfHmu/xanQEKaV5xFQYIxbkwCX37svh8TSFJ48DS6
IWL9pk+h43dFqE75e+sGtVDLwRZKKrYizWdaY8ZVdixx4Mi4OrgGP7SZRImJguHa
qgCTUYaEYJqHgFM8uyDM4Rj2ar+RLR1gsb3utNHvEV7sPXdrLFiqST4PO3I0kimd
Y+v0TPqvC9We5lz1g0G0sKuVGJ+fFIvO5ZwNVjuvErkCvITct2RD5N0dzSlZZKsQ
9zVngfeOas8BzTALOgr7cRhSrzlmSiiaZTbmNRF7d0/r7snv44HD2LtpG/Y1F8Q=
=yfON
-END PGP SIGNATURE-

Bug#843007: RFS: golang-github-hlandau-buildinfo/0.0~git20160722.0.b25d4b0-1~bpo8+1

2016-11-02 Thread Peter Colberg

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-github-hlandau-buildinfo" to jessie-backports. The package is
a prerequisite for acmetool, a client for Let’s Encrypt. I have been
added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-hlandau-buildinfo.git

Regards,
Peter

Bug#843008: RFS: golang-github-hlandau-dexlogconfig/0.0~git20160722.0.055e2e3-1~bpo8+1

2016-11-02 Thread Peter Colberg

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-github-hlandau-dexlogconfig" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-hlandau-dexlogconfig.git

Regards,
Peter

Bug#843006: RFS: golang-gopkg-hlandau-service.v2/2.0.16-1~bpo8+1

2016-11-02 Thread Peter Colberg

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-gopkg-hlandau-service.v2" to jessie-backports. The package is
a prerequisite for acmetool, a client for Let’s Encrypt. I have been
added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-hlandau-service.v2.git

Regards,
Peter

Bug#843005: RFS: golang-gopkg-hlandau-easyconfig.v1/1.0.15-1~bpo8+1

2016-11-02 Thread Peter Colberg

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-gopkg-hlandau-easyconfig.v1" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-hlandau-easyconfig.v1.git

Regards,
Peter

Bug#843004: RFS: golang-gopkg-alecthomas-kingpin.v2/2.2.3-1~bpo8+1

2016-11-02 Thread Peter Colberg

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-gopkg-alecthomas-kingpin.v2" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-alecthomas-kingpin.v2.git

Regards,
Peter

Bug#842939: xul-ext-wot: WOT find guilty to sell user data

2016-11-02 Thread Paul Wise

Control: severity -1 serious

On Wed, 02 Nov 2016 13:44:07 +0100 Andreas Tille wrote:

> I'm setting this bug only to important even if it should be probably be
> RC.  However, I have no technical proof for my claim

This screenshot of the addon was mentioned on #debian-security:

https://media.kuketz.de/blog/artikel/2016/wot-addon/unmaskiert2.jpg

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#843003: fritzing: fails to build on all architectures except i386 and amd64

2016-11-02 Thread Jeremy Bicha

Package: fritzing
Version: 0.9.3b+dfsg-1
Severity: serious

debian/patches/system-libgit2.patch is written so that only amd64 and
i386 will build.

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

libgit2 is available though on every Linux architecture:
https://buildd.debian.org/status/package.php?p=libgit2

Thanks,
Jeremy Bicha

Bug#842812: memcached: CVE-2016-8705

2016-11-02 Thread Guillaume Delacour

Fix is the same as #842814.

On Tue, 01 Nov 2016 14:05:19 +0100 Salvatore Bonaccorso
 wrote:
> Source: memcached
> Version: 1.4.31-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> the following vulnerability was published for memcached.
> 
> CVE-2016-8705[0]:
> Memcached Server Update Remote Code Execution Vulnerability
> 
> It is reproducible with the (fixed) reproducer on the TALOS site, when
> running under valgrind easily.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2016-8705
> [1] http://www.talosintelligence.com/reports/TALOS-2016-0220/
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore
> 
> 

-- 
Guillaume Delacour



signature.asc
Description: OpenPGP digital signature

Bug#842811: memcached: CVE-2016-8704

2016-11-02 Thread Guillaume Delacour

Fix is the same as for #842814.

On Tue, 01 Nov 2016 14:00:07 +0100 Salvatore Bonaccorso
 wrote:
> Source: memcached
> Version: 1.4.31-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> the following vulnerability was published for memcached.
> 
> CVE-2016-8704[0]:
> Memcached Server Append/Prepend Remote Code Execution Vulnerability
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2016-8704
> [1] http://www.talosintelligence.com/reports/TALOS-2016-0219/
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore
> 
> 

-- 
Guillaume Delacour



signature.asc
Description: OpenPGP digital signature

Bug#842814: memcached: CVE-2016-8706

2016-11-02 Thread Guillaume Delacour

Please see attached the debdiff.
Also, please note that i can't upload myself to security-master as i'm
not a DD nor DM.

On Tue, 01 Nov 2016 14:08:44 +0100 Salvatore Bonaccorso
 wrote:
> Source: memcached
> Version: 1.4.31-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> the following vulnerability was published for memcached.
> 
> CVE-2016-8706[0]:
> |Memcached Server SASL Autentication Remote Code Execution
> |Vulnerability
> 
> It is easily reproducible with the TALOS reproducer when memcached
> enabled SASL authentication and running under valgrind to see the
> crash.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2016-8706
> [1] http://www.talosintelligence.com/reports/TALOS-2016-0221/
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore
> 
> 

-- 
Guillaume Delacour
diff -Nru memcached-1.4.21/debian/changelog memcached-1.4.21/debian/changelog
--- memcached-1.4.21/debian/changelog   2015-03-07 13:01:25.0 +
+++ memcached-1.4.21/debian/changelog   2016-11-03 02:14:20.0 +
@@ -1,3 +1,12 @@
+memcached (1.4.21-1.1+deb8u1) jessie-security; urgency=high
+
+  * CVE-2016-8704: Fix Append/Prepend Remote Code Execution (Closes: #842811)
+  * CVE-2016-8705: Fix Update Remote Code Execution (Closes: #842812)
+  * CVE-2016-8706: Fix SASL Authentication Remote Code Execution
+(Closes: #842814)
+
+ -- Guillaume Delacour   Thu, 03 Nov 2016 02:26:55 +0100
+
 memcached (1.4.21-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru memcached-1.4.21/debian/patches/08_CVE-2016-8704_8705_8706.patch 
memcached-1.4.21/debian/patches/08_CVE-2016-8704_8705_8706.patch
--- memcached-1.4.21/debian/patches/08_CVE-2016-8704_8705_8706.patch
1970-01-01 00:00:00.0 +
+++ memcached-1.4.21/debian/patches/08_CVE-2016-8704_8705_8706.patch
2016-11-03 01:31:47.0 +
@@ -0,0 +1,50 @@
+From bd578fc34b96abe0f8d99c1409814a09f51ee71c Mon Sep 17 00:00:00 2001
+From: dormando 
+Date: Wed, 12 Oct 2016 13:50:47 -0700
+Subject: [PATCH] CVE reported by cisco talos
+Origin: upstream,
+https://github.com/memcached/memcached/commit/bd578fc34b96abe0f8d99c1409814a09f51ee71c
+Last-Update: 2016-11-03
+
+---
+ items.c |  3 +++
+ memcached.c | 10 --
+ 2 files changed, 11 insertions(+), 2 deletions(-)
+
+diff --git a/items.c b/items.c
+index 9e6d921..a1cca4a 100644
+--- a/items.c
 b/items.c
+@@ -148,6 +148,9 @@ item *do_item_alloc(char *key, const size_t nkey, const 
unsigned int flags,
+ uint8_t nsuffix;
+ item *it = NULL;
+ char suffix[40];
++if (nbytes < 2 || nkey < 0)
++return 0;
++
+ size_t ntotal = item_make_header(nkey + 1, flags, nbytes, suffix, 
&nsuffix);
+ if (settings.use_cas) {
+ ntotal += sizeof(uint64_t);
+diff --git a/memcached.c b/memcached.c
+index dc1f636..ad423a0 100644
+--- a/memcached.c
 b/memcached.c
+@@ -1997,10 +1997,16 @@ static bool authenticated(conn *c) {
+ static void dispatch_bin_command(conn *c) {
+ int protocol_error = 0;
+ 
+-int extlen = c->binary_header.request.extlen;
+-int keylen = c->binary_header.request.keylen;
++uint8_t extlen = c->binary_header.request.extlen;
++uint16_t keylen = c->binary_header.request.keylen;
+ uint32_t bodylen = c->binary_header.request.bodylen;
+ 
++if (keylen > bodylen || keylen + extlen > bodylen) {
++write_bin_error(c, PROTOCOL_BINARY_RESPONSE_UNKNOWN_COMMAND, NULL, 0);
++c->write_and_go = conn_closing;
++return;
++}
++
+ if (settings.sasl && !authenticated(c)) {
+ write_bin_error(c, PROTOCOL_BINARY_RESPONSE_AUTH_ERROR, NULL, 0);
+ c->write_and_go = conn_closing;
diff -Nru memcached-1.4.21/debian/patches/series 
memcached-1.4.21/debian/patches/series
--- memcached-1.4.21/debian/patches/series  2015-03-07 13:01:25.0 
+
+++ memcached-1.4.21/debian/patches/series  2016-11-03 01:32:38.0 
+
@@ -4,3 +4,4 @@
 04_add_init_retry.patch
 06_eol_comment_handling.patch
 07_disable_tests.patch
+08_CVE-2016-8704_8705_8706.patch


signature.asc
Description: OpenPGP digital signature

Bug#842879: [jidanni 126520274] ps dates wrong

2016-11-02 Thread DreamHost Customer Support Team

- After reading this response, please consider visiting
- the survey below to comment on its quality. Thanks!
- http://www.dreamhost.com/survey.cgi?n=126520274&m=810178
-
- If the service you received from us was exceptional, please consider
- tweeting your love for @dreamhost.  It'll warm our hearts, soothe
- our souls, and get you good karma at some point down the road.

Hello,

On Wed, 02 Nov 2016, you wrote:

> Dear DreamHost, Craig Small, the maintainer of the Ubuntu ps command,
> has asked for your assistance in solving this problem. You can read
> his
> question at http://bugs.debian.org/842879 and follow up at
> 842...@bugs.debian.org . Thanks!

Thank you for writing.

So the issue here is actually due to the virtualization in use on our VPS
servers.
We use 'linux-vserver' on our VPS servers. Please note that one of the
major disadvantages of the linux-vserver package is that many hardware
related system calls, as well as /proc and /sys nodes are left
unvirtualized.

As these nodes and /proc filesystem entries are not correctly
virtualized, calls to /proc will most likely result in an error, or
erroneous results.

If you have any further questions, please respond to this email.

Sincerely,

Erik N.

-- 
- DreamHost Abuse/Security Team
  - Terms of Service: http://www.dreamhost.com/tos.html
  - Anti-Spam Policy: http://www.dreamhost.com/spam.html
  - Abuse Center: http://abuse.dreamhost.com/
 To continue this support case, just reply to this email.
 Open a new case at: https://panel.dreamhost.com/?tab=support

Bug#842952: firefox: Things that are still bad with GTK+3 enabled

2016-11-02 Thread Jeff King

On Wed, Nov 02, 2016 at 11:00:34AM -0400, Matthew Gabeler-Lee wrote:

> Some things I've noticed going from 49.0-4 to 49.0-5 that I'm inferring are
> related to turning on GTK+3:

One thing I've noticed that you didn't mention: on my hi-dpi display the
widget fonts are tiny after the move to GTK+3 (e.g., address bar, tab
titles, anything not rendered HTML).

Setting GDK_SCALE=2 makes it better, but I'm not sure if this is a
viable long-term workaround or not.

The effect is the same whether or not I run with --safe-mode (in fact,
the problem can be seen in the "do you want to start in safe mode"
dialog).

I don't run GNOME, but I do have "dconf" installed. Tweaking
"/org/gnome/desktop/interface/scaling-factor" (and text-scaling-factor)
has no effect.

-Peff

Bug#842994: [Pkg-zsh-devel] Bug#842994: Bug#842994: zsh-syntax-highlighting: shell flooded with error messages

2016-11-02 Thread Daniel Shahaf

Daniel Shahaf wrote on Thu, Nov 03, 2016 at 01:34:52 +:
> raphael wrote on Wed, Nov 02, 2016 at 23:02:43 +0100:
> > _zsh_highlight_main__type:35: no matches found: (( 1 ))
> > _zsh_highlight_highlighter_main_paint:490: no matches found: (( 
> > already_added ))
> > 
> 
> These lines are:
> 
> if ! (( already_added )); then
>   if ! (( $+REPLY )); then
> 

As a workaround, you can try moving the «!» to inside the inner
parentheses.

  if (( ! already_added )); then
if (( ! $+REPLY )); then

> Have you aliased «!» to anything?  Can you share the output of `setopt`
> (without arguments)?
> 
> Or — instead of these two — could you provide a minimal zshrc that
> reproduces the problem?

Bug#842994: [Pkg-zsh-devel] Bug#842994: zsh-syntax-highlighting: shell flooded with error messages

2016-11-02 Thread Daniel Shahaf

raphael wrote on Wed, Nov 02, 2016 at 23:02:43 +0100:
> Package: zsh-syntax-highlighting
> Version: 0.5.0-1
> Severity: important
> 
> Hi,
> 
> Since last upgrade, after a few commands I get for every commands :
> _zsh_highlight_main__type:35: no matches found: (( 1 ))
> _zsh_highlight_highlighter_main_paint:490: no matches found: (( already_added 
> ))
> 

These lines are:

if ! (( already_added )); then
  if ! (( $+REPLY )); then

Have you aliased «!» to anything?  Can you share the output of `setopt`
(without arguments)?

Or — instead of these two — could you provide a minimal zshrc that
reproduces the problem?

Thanks,

Daniel

Bug#842646: outdated player

2016-11-02 Thread 積丹尼 Dan Jacobson

E.g., even http://www.stuffmomnevertoldyou.com/ says
Update Required To play the media you will need to either update your browser 
to a recent version or update your Flash plugin.

Bug#843002: More on the pointer error

2016-11-02 Thread Samuel Thibault

Heya,

Frank McCormick, on Wed 02 Nov 2016 20:13:06 -0400, wrote:
> Forgot to include log extract. Attached.

> Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
> /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7fa2b4cb4bcb]
> Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
> /lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7fa2b4cbafa6]
> Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
> /lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7fa2b4cbb79e]
> Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
> /usr/lib/at-spi2-core/at-spi-bus-launcher[0x40256f]
> Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
> /usr/lib/at-spi2-core/at-spi-bus-launcher[0x4025b8]
> Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
> /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0xc57f6)[0x7fa2b5b6e7f6]
> Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
> /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0xc5a38)[0x7fa2b5b6ea38]

Could you install libc6-dbg, at-spi2-core-dbgsym, and libglib2.0-0-dbg
so we get a more meaningful trace?

Thanks,
Samuel

Bug#842879: no alternate way to find how long they have been running?

2016-11-02 Thread 積丹尼 Dan Jacobson

Thanks but alas,
$ for i in t tc tu; do ls -l$i /proc/[0-9]*/stat|tail -n 1; done
-r--r--r-- 1 root root  0 11-01 17:10 /proc/6725/stat
-r--r--r-- 1 root root  0 11-01 17:10 /proc/6725/stat
-r--r--r-- 1 root root  0 11-01 17:10 /proc/6725/stat
$ w
 08:36:51 up 17 days, 10:02,  1 user,  load average: 0.00, 0.00, 0.00
USER TTY  FROM  LOGIN@   IDLE   JCPU   PCPU WHAT
jidanni1 pts/93   111.246.85.137   08:270.00s  0.19s  0.00s w

Bug#828549: SLURM OpenSSL 1.1 issue - Patch to disable OpenSSL support until upstream fixes

2016-11-02 Thread Karl Kornel

Hi Mehdi,

That’s awesome!  Changing the code is definitely preferable, as long as the 
code works with older versions of MySQL.

To check this, I tried building SLURM in a Jessie COWbuilder installation.  In 
order to test, one dependency had to be changed in the control file: Change 
“default-libmysqlclient-dev” to “libmysqlclient-dev”.  The test took place with 
OpenSSL 1.0.1 (specifically, OpenSSL source package version 1.0.1t-1+deb8u3).

I also tried building for Ubuntu Xenial (again using COWbuilder), which has 
OpenSSL package version 1.0.2g-1ubuntu4.5.  This also required changing the 
control file, as with Jessie.

I did not test in Wheezy, because there are other dependency issues (like a 
minimum debhelper version) that would need to be changed.  I also did not test 
on Ubuntu Trusty.

Both builds were able to complete.  You can download the results here:

Debian Jessie (16.05.6-2~sbp81+1, for jessie-backports): 
https://stanford.box.com/s/tehux7vh57w75k9sfjjpt0s0sjiugor1
Ubuntu Xenial (16.05.6-2~sbp16.04+1, for xenial-backports: 
https://stanford.box.com/s/opnjc8ab5dqzrwwp3qi2rutvfa1mu51l

(I’ll keep each links working until the bug is fixed upstream)

“sbp” stands for “Stanford Backport”, since this isn’t an official backport.  
Each .tar.gz has all of the stuff you would need to upload to a repository of 
your own, so you can either install the .deb files manually, or you could use 
the .changes file to upload to a repository of your own.  The versions are 
numbered so that when Gennaro releases 16.05.6-2 (or something later), that 
will take precedence over the ones I built.

Unfortunately, I don’t think your patch would be able to work directly, because 
the quilt build process requires that the original code be untouched; all of 
the changes to source have to be Quilt patches.  So, I’ve taken your patch and 
converted it into a quilt patch!  I’m attaching to this email a Git commit 
patch that creates the quilt patch, and updates the patch series list.

So, here are the next steps that I would suggest:

* Mehdi, you should go to https://bugs.schedmd.com, create an account, open bug 
3226, and attach your patch (the original one you sent me).  I’m asking you to 
do it because you are the author, so you should get the credit for it.
* Anyone who wants to test on Jessie or Xenial can use one of the builds that I 
made.
* In the meantime, if Gennaro decides to go forward with your code, he could 
use the quilt patch I’ve attached here. 

Thanks much for the patch!

~ Karl 



0001-Add-support-for-OpenSSL-1.1.patch
Description: 0001-Add-support-for-OpenSSL-1.1.patch

Bug#843002: More on the pointer error

2016-11-02 Thread Frank McCormick


Forgot to include log extract. Attached.




Nov  2 10:45:52 frank org.a11y.Bus[2805]: *** Error in 
`/usr/lib/at-spi2-core/at-spi-bus-launcher': free(): invalid pointer: 
0x006b5070 ***
Nov  2 10:45:52 frank org.a11y.Bus[2805]: === Backtrace: =
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7fa2b4cb4bcb]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7fa2b4cbafa6]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7fa2b4cbb79e]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/at-spi2-core/at-spi-bus-launcher[0x40256f]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/at-spi2-core/at-spi-bus-launcher[0x4025b8]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0xc57f6)[0x7fa2b5b6e7f6]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0xc5a38)[0x7fa2b5b6ea38]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0x8a4e3)[0x7fa2b5b334e3]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0x8ab96)[0x7fa2b5b33b96]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0xbd68a)[0x7fa2b5b6668a]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0x8a4e3)[0x7fa2b5b334e3]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0x8a519)[0x7fa2b5b33519]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x15a)[0x7fa2b558c68a]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4aa40)[0x7fa2b558ca40]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xc2)[0x7fa2b558cd62]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/at-spi2-core/at-spi-bus-launcher[0x4020e1]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fa2b4c642b1]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 
/usr/lib/at-spi2-core/at-spi-bus-launcher[0x40226a]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: === Memory map: 
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 0040-00405000 r-xp  08:04 
2097410/usr/lib/at-spi2-core/at-spi-bus-launcher
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 00604000-00605000 r--p 4000 08:04 
2097410/usr/lib/at-spi2-core/at-spi-bus-launcher
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 00605000-00606000 rw-p 5000 08:04 
2097410/usr/lib/at-spi2-core/at-spi-bus-launcher
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 0068c000-006ce000 rw-p  00:00 
0  [heap]
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa29c00-7fa29c021000 rw-p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa29c021000-7fa2a000 ---p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2a400-7fa2a4022000 rw-p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2a4022000-7fa2a800 ---p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2a800-7fa2a8022000 rw-p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2a8022000-7fa2ac00 ---p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2ac00-7fa2ac022000 rw-p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2ac022000-7fa2b000 ---p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b065-7fa2b0651000 ---p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b0651000-7fa2b0e51000 rw-p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b0e51000-7fa2b0e52000 ---p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b0e52000-7fa2b1652000 rw-p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b1652000-7fa2b1653000 ---p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b1653000-7fa2b1e53000 rw-p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b1e53000-7fa2b1e54000 ---p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b1e54000-7fa2b2654000 rw-p 
 00:00 0
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b2654000-7fa2b2655000 r-xp 
 08:04 1971655
/usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0.5000.1
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b2655000-7fa2b2854000 ---p 
1000 08:04 1971655
/usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0.5000.1
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b2854000-7fa2b2855000 r--p 
 08:04 1971655
/usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0.5000.1
Nov  2 10:45:52 frank org.a11y.Bus[2805]: 7fa2b2855000-7fa2b2856000 rw-p 
1000 08:04 1971655
/usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0.500

Bug#843002: at-spi-bus-launcher: Invalid pointer error in user.log

2016-11-02 Thread Samuel Thibault

Control: tags -1 + moreinfo unreproducible

Hello,

Frank McCormick, on Wed 02 Nov 2016 20:01:29 -0400, wrote:
> Found this error in user.log.

Which error?
Just "at-spi-bus-launcher: Invalid pointer error"?

> I don't use any of the applications this supports so it had no side effects on
> me or my machine. Reporting it only because of the pointer error.

Well, I don't see what I can do with this bug report: I have no idea how
to reproduce it, and grepping doesn't show anywhere to have a look at...

Samuel

Bug#837674: parmap: FTBFS with bindnow and PIE enabled

2016-11-02 Thread Mehdi Dogguy

Hi,

On 13/09/2016 14:12, Balint Reczey wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64 with patched GCC and dpkg.
> 
> The rebuild tested if packages are ready for a transition
> enabling PIE and bindnow for amd64.
> 

FWIW, I've tried to rebuild parmap in a clean Sid chroot and I am unable
to reproduce the build failure. You can find attached my build log.

Does it still fail for you?

Regards,

-- 
Mehdi
dpkg-buildpackage: info: source package parmap
dpkg-buildpackage: info: source version 1.0~rc7-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Mehdi Dogguy 
 dpkg-source --before-build parmap
dpkg-source: info: applying 0001-Update-version-number-in-various-places.patch
 fakeroot debian/rules clean
dh --with ocaml clean
dh: Compatibility levels before 9 are deprecated (level 7 in use)
   dh_testdir
   dh_auto_clean
dh_auto_clean: Compatibility levels before 9 are deprecated (level 7 in use)
   dh_ocamlclean
   dh_clean
dh_clean: Compatibility levels before 9 are deprecated (level 7 in use)
 dpkg-source -b parmap
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building parmap using existing ./parmap_1.0~rc7.orig.tar.gz
dpkg-source: info: building parmap in parmap_1.0~rc7-1.debian.tar.xz
dpkg-source: info: building parmap in parmap_1.0~rc7-1.dsc
 dpkg-genchanges --build=source >../parmap_1.0~rc7-1_source.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build parmap
dpkg-source: info: unapplying 0001-Update-version-number-in-various-places.patch
dpkg-buildpackage: info: full upload (original source is included)
[0mI: Copying COW directory[0m
[0mI: forking: rm -rf /var/cache/pbuilder/build/cow.3985[0m
[0mI: forking: cp -al /var/cache/pbuilder/cows/unstable-amd64/ 
/var/cache/pbuilder/build/cow.3985[0m
[0mI: unlink for ilistfile /var/cache/pbuilder/build/cow.3985/.ilist failed, 
it didn't exist?[0m
[0mI: forking: chroot /var/cache/pbuilder/build/cow.3985 cowdancer-ilistcreate 
/.ilist 'find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a 
-links +1 -print0 \) | xargs -0 stat --format '%d %i ''[0m
[0mI: Invoking pbuilder[0m
[0mI: forking: pbuilder build --debbuildopts  --debbuildopts  --buildplace 
/var/cache/pbuilder/build/cow.3985 --buildresult 
/var/cache/pbuilder/result/unstable-amd64 --no-targz --internal-chrootexec 
'chroot /var/cache/pbuilder/build/cow.3985 cow-shell' 
/home/mehdi/Debian/pkg-ocaml-maint/parmap_1.0~rc7-1.dsc[0m
[0mI: Running in no-targz mode[0m
[0mI: using fakeroot in build.[0m
[0mI: pbuilder: network access will be disabled during build[0m
[0mI: Current time: Thu Nov  3 01:03:38 CET 2016[0m
[0mI: pbuilder-time-stamp: 1478131418[0m
[0mI: copying local configuration[0m
[0mI: mounting /proc filesystem[0m
[0mI: mounting /sys filesystem[0m
[0mI: mounting /run/shm filesystem[0m
[0mI: mounting /dev/pts filesystem[0m
[0mI: Mounting /var/cache/pbuilder/result/[0m
[0mI: policy-rc.d already exists[0m
[0mI: Obtaining the cached apt archive contents[0m
[0mI: Installing the build-deps[0m
[1;33mW: execute priv not set on file D09custompool, not executing.[0m
[0mI: user script /var/cache/pbuilder/build/cow.3985/tmp/hooks/D10aptupdate 
starting[0m
Hit:1 http://debian.univ-lorraine.fr/debian unstable InRelease
Reading package lists...
[0mI: user script /var/cache/pbuilder/build/cow.3985/tmp/hooks/D10aptupdate 
finished[0m
[0mI: user script /var/cache/pbuilder/build/cow.3985/tmp/hooks/D11unsafeio 
starting[0m
Setting force-unsafe-io for dpkg
[0mI: user script /var/cache/pbuilder/build/cow.3985/tmp/hooks/D11unsafeio 
finished[0m
[1;33mW: execute priv not set on file D12aptupgrade, not executing.[0m
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 7.0.50~), ocaml-nox (>= 3.12.0~), dh-ocaml (>= 0.9~), 
ocaml-findlib, autoconf
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 11646 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on debhelper (>= 7.0.50~); however:
  Package debhelper is not installed.
 pbuilder-satisfydepends-dummy depends on ocaml-nox (>= 3.12.0~); however:
  Pa

Bug#843002: at-spi-bus-launcher: Invalid pointer error in user.log

2016-11-02 Thread Frank McCormick

Package: at-spi2-core
Version: 2.22.0-3
Severity: normal
File: at-spi-bus-launcher

Dear Maintainer,

Found this error in user.log. I don't use any of the applications this supports 
so it had no side effects on
me or my machine. Reporting it only because of the pointer error.


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

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

Versions of packages at-spi2-core depends on:
ii  libatspi2.0-0  2.22.0-3
ii  libc6  2.24-5
ii  libdbus-1-31.10.12-1
ii  libglib2.0-0   2.50.1-1
ii  libx11-6   2:1.6.3-1
ii  libxtst6   2:1.2.2-1+b1

at-spi2-core recommends no packages.

at-spi2-core suggests no packages.

-- Configuration Files:
/etc/xdg/autostart/at-spi-dbus-bus.desktop [Errno 2] No such file or directory: 
u'/etc/xdg/autostart/at-spi-dbus-bus.desktop'

-- no debconf information

Bug#822337: upgrade from libfreeradius-client to radcli

2016-11-02 Thread Jan Wagner

Am 02.11.16 um 23:38 schrieb Jan Wagner:
> it's my understanding that it's a drop in for freeradius-client
> and radiusclient-ng. So simply adding 'libradcli-dev' as the first build
> dependency alternaive should do the trick?

monitoring-plugins configure tries to detect the radius library which
can't be detected, with libradcli-dev (and libradcli4) installed:

configure: WARNING: Skipping radius plugin
configure: WARNING: install radius libs to compile this plugin (see
REQUIREMENTS).

With kind regards, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#841533: You could revert to gcc-5

2016-11-02 Thread Ron Murray

You can use this to revert to gcc-5, which still works.

Use it as:

# gcc-select  

e.g.
# gcc-select 6 5

   ... will revert to gcc 5 to allow you to compile a kernel.

# gcc-select 5 6

   ... will revert to gcc-6.

   Obviously, you need to be root for this. And while it works fine for
gcc-5 and gcc-6, I have no idea whether it'll work for previous or
future gcc versions. It depends on whether gcc, cc and other executables
are symlinked to gcc-5, cc-6 and so on.

Hope it helps.

 .Ron
 

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761

#! /bin/bash

# Select gcc version
# Assumes "gcc" etc in linked to "gcc-5" etc


BINDIR="/usr/bin"

# Array contining links to be changed
declare LINKS=("cpp" "g++" "gcc" "gcc-ar" "gcc-nm" "gcc-ranlib" \
 "gcov" "gcov-tool" "gfortran")

# Make sure it's specified
OLDVER=$1
NEWVER=$2

if [ -z "${OLDVER}" ] || [ -z "${NEWVER}" ]
then
echo "Usage: gcc-select [oldver] [newver]"
echo "Currently:"
ls -l ${BINDIR}/${LINKS[0]}
exit
fi

for LINK in ${LINKS[*]}
do
echo ${LINK}

# Check that old and new destinations exist
TARGET=${BINDIR}/${LINK}
OLDPOINT=${TARGET}-${OLDVER}
NEWPOINT=${TARGET}-${NEWVER}

if [ ! -e ${OLDPOINT} ]
then
echo "Current destination ${OLDPOINT} doesn't exist."
exit
fi

if [ ! -e ${NEWPOINT} ]
then
echo "Intended destination ${NEWPOINT} doesn't exist."
exit
fi

if ! rm -f ${TARGET}
then
echo "Error removing link ${TARGET}."
exit
fi

if ! ln -sf ${NEWPOINT} ${TARGET}
then
echo "Error creating symbolic link ${NEWPOINT} --> ${TARGET}"
exit
fi

done

echo "Done."


signature.asc
Description: OpenPGP digital signature

Bug#843001: override: vlc-nox:oldlibs/extra

2016-11-02 Thread Sebastian Ramacher

Package: ftp.debian.org
Severity: normal

vlc-nox is now a transitional package, so please change the override
accordingly.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#843000: refind: fails to install on NVMe

2016-11-02 Thread Bjørn Mork

Package: refind
Version: 0.10.4-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The refind-install script makes bogus assumptions:

  InstallDisk=`grep "$InstallDir" /etc/mtab | cut -d " " -f 1 | cut -c 1-8`
  PartNum=`grep "$InstallDir" /etc/mtab | cut -d " " -f 1 | cut -c 9-10`

This is obviously fragile. NVMe is just one example where it fails:

 bjorn@miraculix:~$ grep /boot/efi /etc/mtab | cut -d " " -f 1
 /dev/nvme0n1p1

You cannot assume that the disk device name is exactly 8 characters. There is
no such rule.  Please find a more robust way to figure out device names.


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

Kernel: Linux 4.8.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 refind depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  efibootmgr 14-1
ii  openssl1.1.0b-2
ii  parted 3.2-16+b1

Versions of packages refind recommends:
ii  python3 3.5.1-4
pn  sbsigntool  

refind suggests no packages.

- -- debconf information:
* refind/install_to_esp: true

-BEGIN PGP SIGNATURE-

iQIrBAEBCgAVBQJYGnWiDhxiam9ybkBtb3JrLm5vAAoJEOGX/BLv8F7NFXAP/3r8
vAX1BZGFvaYQhc8bbegYxMSwpl7rYY4sD6EZDMpTU6JTpGuNqbE5o/h193hjk2Sw
0m0eitzo3BbbpWn45AtRG9RvaaJrovODzeNIlFHovZtU4+IitQrqtT1eRFLyoV7A
uLt5Jc/q62e+evkU4pKMwASeXyj8JUnsHM9TOmPjPlCkzk0jSDAy9SYPnzaXeUdB
R77FVbsgNsbznrF9s1h10G0iQX/x3fONKgwPOcQEL8WkWutSB5dioH1JFUGEVzx1
dMZLTkDI9IXYLrfo3ZokWZiuX64nxR00BtM8tAA6ZGx+a545nWh/DQQfEw5IqQiq
Bc0gRtkLfsIRCBka/6oY5Kl/WsJXlub/Qtmp6csQ6y1I2poejTYOlst/0yplmbwe
mmVSopQ+Qbjlg9VO8Fj9SOv+9uZipVIYEOlLVpLu4f4dClf60VN9/vQbueUjvj52
iR5BKz/vNZO2LqJyXWPKu81jKe8OI9EWihIYgdpQCxXyFwzSGs2+B1kbPZXxD8Tw
12Ew5eHf7Bg+9JWAwdjRnA/EQYsxbWOrMfJHiNejTs0Kj8Bj7AgIDOZSBL5TBvpx
YQBnfEKA5CmxiU696tpwCj5HdSyVotyNHRQBkLi5R+Q08ycs+jA7m2GaXruATogF
TEBOHD5lHyvLUBaRg1VJJINajp9AGOrXa3DzgOyw
=GBN/
-END PGP SIGNATURE-

Bug#828589: uw-imap: FTBFS with openssl 1.1.0

2016-11-02 Thread Sebastian Andrzej Siewior

On 2016-09-12 17:00:28 [+0200], Kurt Roeckx wrote:
> > But this problem existed before 1.1.0 support (this patch).
> > What do you recommend here? The builtin usage
> > (X509_VERIFY_PARAM_set_hostflags()) looks simple. The alternative
> > X509_check_host() is 1.0.2+ and since it can not be applied to stable I
> > don't see the point. I would add this for 1.1.0 and keep the current
> > validation for < 1.1.0.
> 
> We don't want to upload this to Debian stable in any case.  But if
> it's only doing the right thing with 1.1.0 that works for me.

So I've been looking at this again. The patch attached should do what
you asked for. It is so untested that EA is already using it…
Ehm. One thing: The callback that uw-imap invokes
scq(err_str_cpy, "hostname", cert_subj)

expects to pass the hostname of the connection. I have no idea how to
obtain it at that point. I could also drop that callback, set
SSL_VERIFY_NONE instead and then check the connection after the
handshake via SSL_get_verify_result(). It is enough exercise I think.
And I haven't got any response from upstream. So I leave it to someone
that can test it and is using it. So far it seems only alpine does [0].

[0] 
http://sources.debian.net/src/alpine/2.20%2Bdfsg1-2/web/src/alpined.d/alpined.c/?hl=10831#L10831

> Kurt

Sebastian
>From b45c2495fffd431a4eee359c24a0b292c87bc33c Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Wed, 2 Nov 2016 22:21:42 +
Subject: [PATCH] uw-imap: use openssl host validation

Signed-off-by: Sebastian Andrzej Siewior 
---
 src/osdep/unix/ssl_unix.c | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/src/osdep/unix/ssl_unix.c b/src/osdep/unix/ssl_unix.c
index 836e9fa..eddf420 100644
--- a/src/osdep/unix/ssl_unix.c
+++ b/src/osdep/unix/ssl_unix.c
@@ -205,6 +205,40 @@ static SSLSTREAM *ssl_start (TCPSTREAM *tstream,char *host,unsigned long flags)
 static char *ssl_last_error = NIL;
 static char *ssl_last_host = NIL;
 
+#if OPENSSL_VERSION_NUMBER >= 0x1010
+
+static int cert_verify(int preverify, X509_STORE_CTX* x509_ctx)
+{
+  sslcertificatequery_t scq;
+  X509* cert;
+  char cert_subj[250];
+  int err;
+  char err_str_cpy[50];
+  const char *err_str;
+
+  if (preverify == 1)
+return 1;
+
+  scq = mail_parameters(NIL, GET_SSLCERTIFICATEQUERY, NIL);
+  if (!scq)
+	  return 0;
+
+  cert = X509_STORE_CTX_get_current_cert(x509_ctx);
+  if (!cert)
+	  return 0;
+  err = X509_STORE_CTX_get_error(x509_ctx);
+  err_str = X509_verify_cert_error_string(err);
+  err_str_cpy[sizeof(err_str_cpy) - 1] = '\0';
+  strncpy(err_str_cpy, err_str, sizeof(err_str_cpy) - 1);
+
+  X509_NAME_oneline(X509_get_subject_name(cert), cert_subj, sizeof(cert_subj));
+
+  if (scq(err_str_cpy, "hostname", cert_subj) == 0)
+	  return 0;
+  return 1;
+}
+#endif
+
 static char *ssl_start_work (SSLSTREAM *stream,char *host,unsigned long flags)
 {
   BIO *bio;
@@ -226,10 +260,12 @@ static char *ssl_start_work (SSLSTREAM *stream,char *host,unsigned long flags)
 return "SSL context failed";
   SSL_CTX_set_options (stream->context,0);
 /* disable certificate validation? */
+#if OPENSSL_VERSION_NUMBER < 0x1010
   if (flags & NET_NOVALIDATECERT)
 SSL_CTX_set_verify (stream->context,SSL_VERIFY_NONE,NIL);
   else SSL_CTX_set_verify (stream->context,SSL_VERIFY_PEER,ssl_open_verify);
 /* set default paths to CAs... */
+#endif
   SSL_CTX_set_default_verify_paths (stream->context);
 /* ...unless a non-standard path desired */
   if (s = (char *) mail_parameters (NIL,GET_SSLCAPATH,NIL))
@@ -259,6 +295,20 @@ static char *ssl_start_work (SSLSTREAM *stream,char *host,unsigned long flags)
 /* create connection */
   if (!(stream->con = (SSL *) SSL_new (stream->context)))
 return "SSL connection failed";
+#if OPENSSL_VERSION_NUMBER >= 0x1010
+  SSL_set_tlsext_host_name(stream->con, host);
+  if (!(flags & NET_NOVALIDATECERT)) {
+	X509_VERIFY_PARAM *param;
+
+	param = SSL_get0_param(stream->con);
+	X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
+	X509_VERIFY_PARAM_set1_host(param, host, 0);
+
+	SSL_set_verify(stream->con, SSL_VERIFY_PEER, cert_verify);
+  } else {
+	SSL_set_verify(stream->con, SSL_VERIFY_NONE, 0);
+  }
+#endif
   bio = BIO_new_socket (stream->tcpstream->tcpsi,BIO_NOCLOSE);
   SSL_set_bio (stream->con,bio,bio);
   SSL_set_connect_state (stream->con);
@@ -267,6 +317,7 @@ static char *ssl_start_work (SSLSTREAM *stream,char *host,unsigned long flags)
   if (SSL_write (stream->con,"",0) < 0)
 return ssl_last_error ? ssl_last_error : "SSL negotiation failed";
 /* need to validate host names? */
+#if OPENSSL_VERSION_NUMBER < 0x1010
   if (!(flags & NET_NOVALIDATECERT)) {
 
 	cert_subj[0] = '\0';
@@ -281,6 +332,7 @@ static char *ssl_start_work (SSLSTREAM *stream,char *host,unsigned long flags)
 	sprintf (tmp,"*%.128s: %.255s",err,cert ? cert_subj : "???");
 	return ssl_last_error = cpystr (tmp);
   }
+#endif
   retur

Bug#842999: xsane: XSane takes ages to start and do anything

2016-11-02 Thread Jack Underwood

Package: xsane
Version: 0.999-3+b1
Severity: important

Dear Maintainer,

Running xsane (I have a Canon MP280 installed, and a webcam that I have never
setup), the programme immediatly showed a dialog saying "Scanning for devices"
which then disappeared, it then takes a very long time minutes/tens of minutes
for the xsane window to appear.


A similar long wait occurred after clicking to do a scan, after a while it
timed out with a dialog titled "Warning" saying "Operation was cancelled."

After closing and restarting everything happened at a normal speed.



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

Kernel: Linux 4.7.0-1-amd64 (SMP w/2 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 xsane depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libcairo21.14.6-1+b1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgimp2.0   2.8.18-1
ii  libglib2.0-0 2.50.1-1
ii  libgtk2.0-0  2.24.31-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  liblcms2-2   2.7-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpangoft2-1.0-01.40.3-2
ii  libpng16-16  1.6.25-2
ii  libsane  1.0.25-2+b1
ii  libtiff5 4.0.6-2
ii  xsane-common 0.999-3
ii  zlib1g   1:1.2.8.dfsg-2+b3

Versions of packages xsane recommends:
ii  cups-client2.2.1-1
ii  firefox-esr [www-browser]  45.4.0esr-2
ii  iceweasel  45.4.0esr-2
ii  links [www-browser]2.13-1
ii  w3m [www-browser]  0.5.3-31

Versions of packages xsane suggests:
ii  gimp  2.8.18-1
pn  gocr | cuneiform | tesseract-ocr | ocrad  
pn  gv
pn  hylafax-client | mgetty-fax   

-- no debconf information

Bug#830178: Possible fix

2016-11-02 Thread Sandro Tosi

thanks a lot Piotr! these days i'm going thru the list of packages we
care at work for stretch so a mail-ping was super effective :)

On Wed, Nov 2, 2016 at 6:39 PM, Piotr Ożarowski  wrote:
> [Sandro Tosi, 2016-11-02]
>> thanks! i pinged that bug to see if upstream will release a new
>> version soo, if not we could just pick up that patch
>
> I uploaded -2, thanks for the reminder and sorry for the delay (RL, I
> will try to keep up a bit with Debian this weekend...)



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#842998: erlang-base-hipe: OTP / HiPE broken with GCC 6.2

2016-11-02 Thread Johannes Weißl

Package: erlang-base-hipe
Version: 1:19.1.5+dfsg-1
Severity: grave
Tags: upstream
Justification: renders package unusable

HiPE in the OTP 19.1.5 Debian package is broken (at least on amd64), because it
was built with GCC 6.2. See also upstream report:

http://erlang.org/pipermail/erlang-questions/2016-November/090753.html



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

Kernel: Linux 4.7.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 erlang-base-hipe depends on:
ii  adduser  3.115
ii  init-system-helpers  1.45
ii  libc62.24-5
ii  libsctp1 1.0.17+dfsg-1
ii  libsystemd0  231-9
ii  libtinfo56.0+20160917-1
ii  procps   2:3.3.12-2
ii  zlib1g   1:1.2.8.dfsg-2+b3

Versions of packages erlang-base-hipe recommends:
ii  erlang-crypto1:19.1.5+dfsg-1
ii  erlang-syntax-tools  1:19.1.5+dfsg-1
ii  libsctp1 1.0.17+dfsg-1

Versions of packages erlang-base-hipe suggests:
ii  erlang   1:19.1.5+dfsg-1
ii  erlang-doc   1:19.1.5+dfsg-1
ii  erlang-manpages  1:19.1.5+dfsg-1
ii  erlang-tools 1:19.1.5+dfsg-1

-- no debconf information

Bug#828523: Downgrading due to switch to libssl1.0-dev

2016-11-02 Thread Lisandro Damián Nicanor Pérez Meyer

Control: severity -1 important

We switched our build dependnecy on libssl-dev to libssl1.0-dev so I'm 
downgrading this bug.

Of course I'm keeping this open because we need to switch to 1.1 as soons as 
upstream allows us.

-- 
I wish to be cremated. One tenth of my ashes shall be given
to my agent, as written in our contract.
 -- Groucho Marx

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


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

Bug#842997: flashplugin-nonfree: Impossible to update

2016-11-02 Thread Jean-Philippe MENGUAL

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

Dear Maintainer,

Hi,

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

   * What led up to the situation?

Flash becomes deprecated in testing.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

update-flashplugin-nonfree  --install

   * What was the outcome of this action?

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


   * What outcome did you expect instead?

Should download and install the plugin.

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

Regards,


-- Package-specific info:
Debian version: stretch/sid
Architecture: amd64
Package version: 1:3.7
MD5 checksums:
29c85bc8504422120cf89702986ff8e1  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
5bb834820d1563b2df2ed52fd9986b24  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz
md5sum: /usr/lib/flashplugin-nonfree/libflashplayer.so: No such file or 
directory
Alternatives:
update-alternatives: error: no alternatives for flash-mozilla.so
ls: cannot access '/usr/lib/mozilla/plugins/flash-mozilla.so': No such 
file or directory
/usr/lib/mozilla/plugins/flash-mozilla.so: cannot open 
`/usr/lib/mozilla/plugins/flash-mozilla.so' (No such file or directory)

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

Kernel: Linux 4.7.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)

Versions of packages flashplugin-nonfree depends on:
ii  binutils   2.27-9+b1
ii  ca-certificates20160104
ii  debconf [debconf-2.0]  1.5.59
ii  gnupg  2.1.15-4
ii  gnupg2 2.1.15-4
ii  libatk1.0-02.22.0-1
ii  libcairo2  1.14.6-1+b1
ii  libcurl3-gnutls7.50.1-1
ii  libfontconfig1 2.11.0-6.7
ii  libfreetype6   2.6.3-3+b1
ii  libgcc11:6.2.0-10
ii  libglib2.0-0   2.50.1-1
ii  libgtk2.0-02.24.31-1
ii  libnspr4   2:4.12-2
ii  libnss32:3.26-2
ii  libpango1.0-0  1.40.3-2
ii  libstdc++6 6.2.0-10
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.5-1
ii  wget   1.18-4

flashplugin-nonfree recommends no packages.

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

-- no debconf information

Bug#842776: libdose3-ocaml-dev is uninstallable

2016-11-02 Thread Johannes Schauer

Hi,

Quoting Mehdi Dogguy (2016-11-02 23:46:15)
> I may have missed something... but why not requesting a rebuild of the package
> instead of opening this bug? Is there anything else to do besides doing the
> binNMU?

probably not. It was just a long time since I last filed a request for a binNMU
and at the time I reported this I was pressed for time but didn't want to
forget about this, so I just quickly filed this bug against src:dose3.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#842776: libdose3-ocaml-dev is uninstallable

2016-11-02 Thread Mehdi Dogguy

Hi Johannes,

On 01/11/2016 08:04, Johannes Schauer wrote:
> Package: libdose3-ocaml-dev
> Version: 5.0.1-6
> Severity: grave
> Justification: renders package unusable
> 
> Hi,
> 
> libdose3-ocaml-dev in unstable depends on
> libocamlgraph-ocaml-dev-i0qi0:amd64. This is provided by
> libocamlgraph-ocaml-dev 1.8.6-1+b1 but a recent binNMU introduced
> libocamlgraph-ocaml-dev 1.8.6-1+b2. Thus, dose3 needs a rebuild with the
> new ocamlgraph version to fix this problem.
> 

Thanks for detecting this issue and filing the bug!

I may have missed something... but why not requesting a rebuild of the package
instead of opening this bug? Is there anything else to do besides doing the
binNMU?

-- 
Mehdi

Bug#828404: libpam-mount: FTBFS with openssl 1.1.0

2016-11-02 Thread Philipp Huebner

Hi,

according to the upstream changelog, this is fixed in the latest release
(2.16).

Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#822337: [Pkg-nagios-devel] Bug#822337: upgrade from libfreeradius-client to radcli

2016-11-02 Thread Jan Wagner

Hi Daniel,

Am 23.04.16 um 17:43 schrieb Daniel Pocock:
> Please check the preinst for radcli to see if you are satisfied with it,
> it has to copy /etc/radiusclient/* to /etc/radcli

sorry, but the migration of configurations done by users or
radiusclient/radcli maintainers is nothing we will deal in
monitoring-plugins.
With kind regards, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#830178: Possible fix

2016-11-02 Thread Piotr Ożarowski

[Sandro Tosi, 2016-11-02]
> thanks! i pinged that bug to see if upstream will release a new
> version soo, if not we could just pick up that patch

I uploaded -2, thanks for the reminder and sorry for the delay (RL, I
will try to keep up a bit with Debian this weekend...)

Bug#822337: upgrade from libfreeradius-client to radcli

2016-11-02 Thread Jan Wagner

Hi Sandro,

Am 02.11.16 um 23:16 schrieb Sandro Tosi:
> On Sat, 23 Apr 2016 17:43:05 +0200 Daniel Pocock  wrote:
>> > monitoring-plugins-standard depends on libfreeradius-client
>> >
>> > libfreeradius-client has been deprecated in favor of radcli[1]
>> >
>> > Please update the build dependency to use radcli. The API is fully
>> > compatible, radcli is a fork of the previous library, it is actively
>> > maintained and includes many bug fixes.
>> >
>> > radcli is available in sid and jessie-backports
>> >
>> > Please check the preinst for radcli to see if you are satisfied with it,
>> > it has to copy /etc/radiusclient/* to /etc/radcli
> do you plan to make this change or do you see any issue with it? can i
> help somehow?

not being very familiar with all those radius stuff tooking into
https:github.com/radcli/radcli#1-introduction (based originally on
freeradius-client and radiusclient-ng and is source compatible with
them) it's my understanding that it's a drop in for freeradius-client
and radiusclient-ng. So simply adding 'libradcli-dev' as the first build
dependency alternaive should do the trick?

Cheers, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#813658: virglrenderer support before the freeze?

2016-11-02 Thread Hillel Lubman

Hi. 

Do you plan to add --enable-virglrenderer to the qemu build? Freeze is
very close, and it would be good to have this feature in before it. 

Thanks, 

Hillel Lubman.

Bug#837374: fixed in opendkim 2.11.0~alpha-7

2016-11-02 Thread Scott Kitterman



On November 2, 2016 2:09:54 PM EDT, Peter Colberg  wrote:
>On Fri, Oct 28, 2016 at 07:31:38AM +, Scott Kitterman wrote:
>>* Generate opendkim.service in postinst instead of shipping it in
>the
>>  package (Closes: #837374)
>
>What would you say if the package shipped a static systemd unit, and
>postinst generated an override file in /etc/systemd/system/opendkim.d/
>that carries over any non-default settings from /etc/default/opendkim?
>
>This could serve as a model for smooth upgrades of other packages, too.
>
>Peter

Seems like it might work.  I'd be willing to apply such a patch if it tests out.

Scott K

Bug#842996: [apt-listchanges] man page Spanish translation shows paragraphs in English

2016-11-02 Thread Enrique Garcia

Package: apt-listchanges
Version: 3.5
Severity: minor
Tags: l10n

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

 If the Spanish locale is used (LANG=es_ES.utf8), the man page of 
apt-listchanges shows 
half of the paragraphs in English.

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

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

--- Package information. ---
Depends   (Version) | Installed
===-+-
apt  (>= 0.5.3) | 1.3.1
debianutils  (>= 2.0.2) | 4.8
python3-apt (>= 0.7.93) | 1.1.0~beta5
ucf   (>= 0.28) | 3.0036
debconf   (>= 0.5)  | 1.5.59
 OR debconf-2.0 | 
python3:any   (>= 3.5~) | 


Package's Recommends field is empty.

Suggests  (Version) | Installed
===-+-===
default-mta | 
 OR mail-transport-agent| 
python3-gi  | 3.22.0-1
www-browser | 
x-terminal-emulator |

Bug#820519: sitecopy: fails to accept SSL certificates issued by a CA (Let's Encrypt)

2016-11-02 Thread Francesco Poli

On Wed, 02 Nov 2016 16:44:33 +0100 Christian Marillat wrote:

> On 01 nov. 2016 16:27, Francesco Poli  wrote:
> 
> > On Sun, 4 Sep 2016 11:28:15 +0200 Francesco Poli wrote:
> >
> >> On Sat, 09 Apr 2016 13:39:54 +0200 Francesco Poli (wintermute) wrote:
> >> 
> >> [...]
> >> > Please investigate and fix this bug and/or forward my bug report
> >> > upstream, as appropriate.
> >> 
> >> Hello again,
> >> is there any progress on this bug (#820519)?
> >> Have you investigated the issue? Have you forwarded the bug report
> >> upstream?
> >> 
> >> Please let me know, thanks for your time.
> >
> > Ping?
> 
> Did you read the upstream site recently ?
> 
> http://www.manyfish.co.uk/sitecopy/

Sorry, but what do you mean?

I hadn't read the upstream site recently.
I have taken a look now: I failed to find any useful information about
my issue.

Do you mean that I should notice that no new upstream version has been
released since 2008?

Please let me know.
Thanks for your time!


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


pgpgCXoqrSWW5.pgp
Description: PGP signature

Bug#828513: proftpd-dfsg: FTBFS with openssl 1.1.0

2016-11-02 Thread Hilmar Preuße

On 02.11.2016 10:49, Hilmar Preuße wrote:

Hi Kurt,

> According to [2] one could use libssl1.0-dev as BD instead. 
> Unfortunately this removes libpq-dev, which is needed by our package 
> too. Not sure if the Postgres people will change here so we can use
> the work around for stretch.
> 
OK, they did. I fixed the BD in our git. As soon as our fixed packages
has been uploaded I'll lower this bug to non-rc.

Hilmar
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#828549: SLURM OpenSSL 1.1 issue - Patch to disable OpenSSL support until upstream fixes

2016-11-02 Thread Mehdi Dogguy

Hi,

On 02/11/2016 20:06, Karl Kornel wrote:
> forwarded 828549 https://bugs.schedmd.com/show_bug.cgi?id=3226 tags 828549 +
> patch thanks
> 
> Hello!
> 
> It looks like even the latest SLURM Debian package, 16.05.6-1, still has this
> issue. I tested with OpenSSL package version 1.1.0b-2, building on a sid
> COWbuilder.
> 
> The issue is being tracked upstream at this URL:
> 
> https://bugs.schedmd.com/show_bug.cgi?id=3226
> 

Thanks for the reference!

> The bug was filed on Oct. 31, and acknowledged on Nov. 1.
> 
> SLURM only uses OpenSSL in one place: To create “job step credentials”.
> However, this is not the default: the default is to have MUNGE create those
> credentials.
> 
> Since OpenSSL is only used in one place, and that’s not even as the default,
> I have created a Quilt patch which removes OpenSSL from the build entirely.
> Unfortunately, it’s not enough to change how we run ./configure; if the
> configure script sees an OpenSSL installation, it will use it, so I have to
> completely remove the test for OpenSSL, as well as the Makefile.am file that
> would trigger the compilation of OpenSSL-using code.
> 

I think it is easier to port Slurm to use OpenSSL 1.1. Attached is a tentative
patch that makes Slurm compile against OpenSSL 1.1. I haven't tested it
thoroughly and I would appreciate some help. In short, EVP_MD_CTX became opaque
in OpenSSL 1.1 and we cannot use it directly anymore. Similar fixes have been
applied to other softs.

Another way to avoid the bug in Debian is to use OpenSSL 1.0 by choosing
libssl1.0-dev in the Build-Depends line. It doesn't fix the issue but prevents
the system from removing it from testing.

Regards,

-- 
Mehdi
From: Mehdi Dogguy 
Date: Wed, 2 Nov 2016 22:54:38 +0100
Subject: Port to OpenSSL 1.1

---
 src/plugins/crypto/openssl/crypto_openssl.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/src/plugins/crypto/openssl/crypto_openssl.c b/src/plugins/crypto/openssl/crypto_openssl.c
index 2fa9767..87c0b55 100644
--- a/src/plugins/crypto/openssl/crypto_openssl.c
+++ b/src/plugins/crypto/openssl/crypto_openssl.c
@@ -179,7 +179,7 @@ extern int
 crypto_sign(void * key, char *buffer, int buf_size, char **sig_pp,
 		unsigned int *sig_size_p)
 {
-	EVP_MD_CTXectx;
+	EVP_MD_CTX*ectx;
 	int   rc= SLURM_SUCCESS;
 	int   ksize = EVP_PKEY_size((EVP_PKEY *) key);
 
@@ -188,17 +188,18 @@ crypto_sign(void * key, char *buffer, int buf_size, char **sig_pp,
 	 */
 	*sig_pp = xmalloc(ksize * sizeof(unsigned char));
 
-	EVP_SignInit(&ectx, EVP_sha1());
-	EVP_SignUpdate(&ectx, buffer, buf_size);
+	ectx = EVP_MD_CTX_create();
+	EVP_SignInit(ectx, EVP_sha1());
+	EVP_SignUpdate(ectx, buffer, buf_size);
 
-	if (!(EVP_SignFinal(&ectx, (unsigned char *)*sig_pp, sig_size_p,
+	if (!(EVP_SignFinal(ectx, (unsigned char *)*sig_pp, sig_size_p,
 			(EVP_PKEY *) key))) {
 		rc = SLURM_ERROR;
 	}
 
 #ifdef HAVE_EVP_MD_CTX_CLEANUP
 	/* Note: Likely memory leak if this function is absent */
-	EVP_MD_CTX_cleanup(&ectx);
+	EVP_MD_CTX_destroy(ectx);
 #endif
 
 	return rc;
@@ -208,13 +209,14 @@ extern int
 crypto_verify_sign(void * key, char *buffer, unsigned int buf_size,
 		char *signature, unsigned int sig_size)
 {
-	EVP_MD_CTX ectx;
+	EVP_MD_CTX *ectx;
 	intrc;
 
-	EVP_VerifyInit(&ectx, EVP_sha1());
-	EVP_VerifyUpdate(&ectx, buffer, buf_size);
+	ectx = EVP_MD_CTX_create();
+	EVP_VerifyInit(ectx, EVP_sha1());
+	EVP_VerifyUpdate(ectx, buffer, buf_size);
 
-	rc = EVP_VerifyFinal(&ectx, (unsigned char *) signature,
+	rc = EVP_VerifyFinal(ectx, (unsigned char *) signature,
 		sig_size, (EVP_PKEY *) key);
 	if (rc <= 0)
 		rc = SLURM_ERROR;
@@ -223,7 +225,7 @@ crypto_verify_sign(void * key, char *buffer, unsigned int buf_size,
 
 #ifdef HAVE_EVP_MD_CTX_CLEANUP
 	/* Note: Likely memory leak if this function is absent */
-	EVP_MD_CTX_cleanup(&ectx);
+	EVP_MD_CTX_destroy(ectx);
 #endif
 
 	return rc;

Bug#822337: upgrade from libfreeradius-client to radcli

2016-11-02 Thread Sandro Tosi

Hello monitoring-plugin maintainers!

On Sat, 23 Apr 2016 17:43:05 +0200 Daniel Pocock  wrote:
> monitoring-plugins-standard depends on libfreeradius-client
>
> libfreeradius-client has been deprecated in favor of radcli[1]
>
> Please update the build dependency to use radcli. The API is fully
> compatible, radcli is a fork of the previous library, it is actively
> maintained and includes many bug fixes.
>
> radcli is available in sid and jessie-backports
>
> Please check the preinst for radcli to see if you are satisfied with it,
> it has to copy /etc/radiusclient/* to /etc/radcli

do you plan to make this change or do you see any issue with it? can i
help somehow?

Bug#842677: Fixed #842677

2016-11-02 Thread Santiago Vila

On Wed, Nov 02, 2016 at 11:01:26PM +0100, Ruben Undheim wrote:
> Hi Santiago!
> 
> Thanks for reporting the bug.
> 
> I've uploaded the fix, but I completely forgot to add your name to the
> changelog!

Oh, don't worry about that.

You fixed the bug very quickly, which is already a form of appreciation.

Thanks a lot.

Bug#841883: linux-image-4.7.0-1-686: cannot boot with 4.7.8-1, stuck at loading initrd

2016-11-02 Thread Francesco Poli

On Tue, 01 Nov 2016 10:28:40 -0600 Ben Hutchings wrote:

> On Tue, 2016-11-01 at 11:31 +0100, Francesco Poli wrote:
> [...]
> > I expected to find a linux-image-4.8.0-1-686 package in unstable, but
> > it seems to be only present as a virtual package, provided by
> > linux-image-4.8.0-1-686-unsigned:
> 
> Correct - the code-signed packages can't be uploaded until all the
> unsigned packages are built, and the ARM builds took a long time.

Thanks for the explanation, now everything is way clearer!  :-)

> They will be available soon.

And indeed they became available, while I was striving to find the time
to test version 4.8.5-1: here's the outcome, I installed the new linux
image from unstable (aptitude -t unstable install linux-image-686) and
rebooted.

I can confirm that version 4.8.5-1 works correctly. 
So, as far as I am *personally* concerned, this bug may be closed as
fixed in version 4.8.5-1 and/or forcemerged with #841850.

Thanks a lot for your assistance and helpfulness!
Bye.

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

pgp0QEPdVEufC.pgp
Description: PGP signature

Bug#830178: Possible fix

2016-11-02 Thread Sandro Tosi

thanks! i pinged that bug to see if upstream will release a new
version soo, if not we could just pick up that patch

On Wed, Nov 2, 2016 at 6:05 PM, Nish Aravamudan
 wrote:
> On Wed, Nov 2, 2016 at 3:00 PM, Sandro Tosi  wrote:
>> On Mon, 26 Sep 2016 17:34:47 -0700 Nish Aravamudan
>>  wrote:
>>> So I am tracking the same issue seen on Ubuntu 16.10 and I found:
>>>
>>> https://github.com/sphinx-doc/sphinx/pull/2396
>>>
>>> I tested the following patch to the sourc3, and it does seem to build,
>>> although I'm not sure I fully understand why yet (I'm completely new to
>>> sphinx, just trying to help fix these bugs :) But I think it's because
>>> upstream sphinx has changed an underlying data structure (index)?
>>>
>>> -Nish
>>>
>>> --- a/doc/build/templates/genindex.mako
>>> +++ b/doc/build/templates/genindex.mako
>>> @@ -21,7 +21,7 @@
>>>  numcols = 1
>>>  numitems = 0
>>>  %>
>>> -% for entryname, (links, subitems) in entries:
>>> +% for entryname, (links, subitems, dummy) in entries:
>>>
>>>  
>>>  % if links:
>>>
>>
>> hey Piotr, did you have a chance to look at this patch? do you think
>> it's ok to apply to the debian package or would you rather forward it
>> upstream and ask what they thnk about it?
>
> Sorry, I should have updated this bug: upstream mako has picked this
> up already: https://github.com/zzzeek/mako/pull/20
>
> -Nish



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#830178: Possible fix

2016-11-02 Thread Nish Aravamudan

On Wed, Nov 2, 2016 at 3:00 PM, Sandro Tosi  wrote:
> On Mon, 26 Sep 2016 17:34:47 -0700 Nish Aravamudan
>  wrote:
>> So I am tracking the same issue seen on Ubuntu 16.10 and I found:
>>
>> https://github.com/sphinx-doc/sphinx/pull/2396
>>
>> I tested the following patch to the sourc3, and it does seem to build,
>> although I'm not sure I fully understand why yet (I'm completely new to
>> sphinx, just trying to help fix these bugs :) But I think it's because
>> upstream sphinx has changed an underlying data structure (index)?
>>
>> -Nish
>>
>> --- a/doc/build/templates/genindex.mako
>> +++ b/doc/build/templates/genindex.mako
>> @@ -21,7 +21,7 @@
>>  numcols = 1
>>  numitems = 0
>>  %>
>> -% for entryname, (links, subitems) in entries:
>> +% for entryname, (links, subitems, dummy) in entries:
>>
>>  
>>  % if links:
>>
>
> hey Piotr, did you have a chance to look at this patch? do you think
> it's ok to apply to the debian package or would you rather forward it
> upstream and ask what they thnk about it?

Sorry, I should have updated this bug: upstream mako has picked this
up already: https://github.com/zzzeek/mako/pull/20

-Nish

Bug#842994: zsh-syntax-highlighting: shell flooded with error messages

2016-11-02 Thread raphael

Package: zsh-syntax-highlighting
Version: 0.5.0-1
Severity: important

Hi,

Since last upgrade, after a few commands I get for every commands :
_zsh_highlight_main__type:35: no matches found: (( 1 ))
_zsh_highlight_highlighter_main_paint:490: no matches found: (( already_added ))

and

_zsh_highlight_main__type:35: no matches found: (( 0 ))
_zsh_highlight_highlighter_main_paint:490: no matches found: (( already_added ))

every letter typed raises a
_zsh_highlight_highlighter_main_paint:490: no matches found: (( already_added ))
afterwards

Thanks

Raphael

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages zsh-syntax-highlighting depends on:
ii  zsh  5.2-5+b1

zsh-syntax-highlighting recommends no packages.

zsh-syntax-highlighting suggests no packages.

-- no debconf information

Bug#841662: libserver-starter-perl: test suite sometimes times out

2016-11-02 Thread Niko Tyni

On Tue, Nov 01, 2016 at 09:24:06PM +0100, gregor herrmann wrote:
> On Sun, 30 Oct 2016 20:03:49 +0200, Niko Tyni wrote:
> 
> > Given it fails somewhat regularly on both ci.debian.net and
> > tests.reproducible-builds.org, possibly a faster machine would improve
> > the chances of reproducing it.  Just getting the log of 'strace -f
> > -olog prove -l t/01-starter.t' when it locks up would help tremendously,
> > but I ran it for two hours or so like that without a single lockup.
> 
> I failed as well on Sunday but today I succeeded.
> Attached is the output of
> 
> while :; do strace -f -olog prove -l t/04-starter-dir.t t/05-killolddelay.t 
> t/06-autorestart.t || break ; done

Oh awesome, thanks! Note to self: next time ask for time stamps too
(strace -ttt or so). But this will do quite fine :)

The problem (at least the one visible in this trace) seems to be
related to Test::TCP. The test_tcp() call in t/06-autorestart.t
finds an empty port with Net::EmptyPort, then passes it to both the
client and the server code. The server starts up in a child process in
Test::TCP::start(), but gets EADDRINUSE when binding the listener socket
for some reason.  The parent process in Test::TCP::start() then hangs
in Net::Empty::wait_port(), waiting for the port to become available
before calling the client code but always getting ECONNREFUSED.

The Server::Starter tests should probably specify a max_wait parameter
to test_tcp(). That should fix at least these hangs, probably in
exchange for test failures.

However, I'm not sure what causes the EADDRINUSE value.  Either the
kernel keeps the port reserved even after it got closed (Net::EmptyPort
finds a port by binding to one and then closing it immediately), or some
unrelated process steals the port in between, possibly for a non-listener
socket (hence ECONNREFUSED).

The latter explanation feels somewhat more plausible, particularly
as the hangs seem to happen more on busy hosts. This should be
easy-ish to demonstrate but I'm out of time for tonight.

I'm not totally convinced this is the same hang I was seeing in my
earlier investigations fwiw, but it's at least a step forward :)
-- 
Niko

Bug#842995: dh-make: invalid Vcs-Git stanza

2016-11-02 Thread Debian/GNU

Package: dh-make
Version: 2.201608
Severity: normal

Dear Maintainer,

the Vcs-Git stanza generated by dh-make is simply wrong.
It reads:
   https://anonscm.debian.org/collab-maint/${PKGNAME}.git
Whereas it should read:
   https://anonscm.debian.org/git/collab-maint/${PKGNAME}.git

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
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 dh-make depends on:
ii  debhelper  10.2.2
ii  dpkg-dev   1.18.10
ii  make   4.1-9
ii  python-enum34  1.1.6-1
pn  python:any 

dh-make recommends no packages.

Versions of packages dh-make suggests:
ii  build-essential  12.2

-- no debconf information

Bug#842677: Fixed #842677

2016-11-02 Thread Ruben Undheim

Hi Santiago!

Thanks for reporting the bug.

I've uploaded the fix, but I completely forgot to add your name to the
changelog!

I'm sorry about that.


Cheers,
Ruben

Bug#830178: Possible fix

2016-11-02 Thread Sandro Tosi

On Mon, 26 Sep 2016 17:34:47 -0700 Nish Aravamudan
 wrote:
> So I am tracking the same issue seen on Ubuntu 16.10 and I found:
>
> https://github.com/sphinx-doc/sphinx/pull/2396
>
> I tested the following patch to the sourc3, and it does seem to build,
> although I'm not sure I fully understand why yet (I'm completely new to
> sphinx, just trying to help fix these bugs :) But I think it's because
> upstream sphinx has changed an underlying data structure (index)?
>
> -Nish
>
> --- a/doc/build/templates/genindex.mako
> +++ b/doc/build/templates/genindex.mako
> @@ -21,7 +21,7 @@
>  numcols = 1
>  numitems = 0
>  %>
> -% for entryname, (links, subitems) in entries:
> +% for entryname, (links, subitems, dummy) in entries:
>
>  
>  % if links:
>

hey Piotr, did you have a chance to look at this patch? do you think
it's ok to apply to the debian package or would you rather forward it
upstream and ask what they thnk about it?

thanks!!

Bug#841488: (no subject)

2016-11-02 Thread Michael Lustfield

Here's an updated version per discussions w/ some other Nginx fellers.diff --git a/debian/conf/sites-available/default b/debian/conf/sites-available/default
index 79e41e8..6d2ce85 100644
--- a/debian/conf/sites-available/default
+++ b/debian/conf/sites-available/default
@@ -35,41 +35,59 @@ server {
 
root /var/www/html;
 
-   # Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
 
server_name _;
 
location / {
-   # First attempt to serve request as file, then
-   # as directory, then fall back to displaying a 404.
+   # This represents the default try_files directive.
+   #
+   # $uri serves a static regular file, or symlink, if the root dir
+   # plus the exact requested path ($uri) exists.
+   #
+   # $uri/ has two functions, if a directory named root + $uri exists:
+   #   1. If the requested path doesn't end in /, nginx issues a 301
+   #  with a slash (/) appended.
+   #   2. If the requested path ends in /, nginx tries to serve an index
+   #  file if one exists (index directive), or a generated index if
+   #  autoindex is enabled.
+   #
+   # The final argument is a fallback and expected to always exist. The
+   # default "=404" returns a 404 response to the user.
+   #
try_files $uri $uri/ =404;
}
 
-   # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
-   #
#location ~ \.php$ {
-   #   include snippets/fastcgi-php.conf;
-   #
-   #   # With php5-cgi alone:
-   #   fastcgi_pass 127.0.0.1:9000;
-   #   # With php5-fpm:
-   #   fastcgi_pass unix:/var/run/php5-fpm.sock;
-   #}
+   # Pass the PHP scripts to a FastCGI application server
+   # in some cases, "index.php" should be added to the (above) index directive
 
-   # deny access to .htaccess files, if Apache's document root
-   # concurs with nginx's one
-   #
-   #location ~ /\.ht {
-   #   deny all;
+   # Includes default and suggested FastCGI configuration values
+   #include snippets/fastcgi-php.conf;
+
+   # If using php-fpm, this is the default socket location. If you have
+   # a different version of php-fpm installed, this may be different.
+   #fastcgi_pass unix:/var/run/php7.0-fpm.sock
#}
+
+   location ~ /\.ht {
+   # If your web application was designed to be run on apache, it likely
+   # has .htaccess and possibly a .htpasswd file embedded. It is typically
+   # recommended to remove access to these files.
+
+   # If you are using apache as your application server, we strongly
+   # recommend looking into uwsgi as an alternative.
+   #
+   deny all;
+   }
 }

Bug#841705: [lshw] lshw 02.18-0.1 hangs Stretch

2016-11-02 Thread Sandro Tosi

Hello Derek,

On Sat, 22 Oct 2016 14:56:22 +0100 Derek  wrote:
> Just executing lshw as root causes the monitor to go blank, after a few
> seconds the desktop reappears but it's unresponsive. The desktop
> disappearing and reappearing repeats for a minute or two before
> rebooting.
>
> The Magic Sys Rq key combination allows me to reboot the PC.
>
> There's nothing in /var/log/* that relates to the hang.
>
> Please ask if there's anything I can do to provide more information.

i tried on my system and on a virtual machine and they both work fine,
so it's possible it's something specific to your machine that makes
lshw unhappy. have you tried multiple times and the all end up in your
machine being unresponsive? did you dist-upgraded your machine
recently? if not, could you try to upgrade it and retry?

thanks

Bug#842841: [pkg-cinnamon] Bug#842841: cinnamon: Runing cinnamon --replace segfaults after recent update

2016-11-02 Thread William L. DeRieux IV


On Wed, 2 Nov 2016 11:42:54 +0100 Maximiliano Curia wrote:
> Control: tag -1 + moreinfo
>
> ¡Hola William!
>
> El 2016-11-01 a las 12:56 -0400, William L. DeRieux IV escribió:
> > Package: cinnamon
> > Version: 3.0.7-2
> > Severity: important
>
> > I'm running Cinnamon 3.0.7-2 everything was fine until a recent 
update.

> > Now clicking on certain items on the cinnamon-panel causes a crash and
> > when running cinnamon --replace from a tty causes a segmentation fault.
>
> Can you try to narrow down the list of upgraded packaged that caused 
this?

>
> > This is the output from the command and the backtrace generated by gdb:
>
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 20)
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 22)
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 22)
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 22)
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 22)
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 28)
> >
> > (cinnamon:9796): Cvc-CRITICAL **: gvc_mixer_card_get_index: assertion
> > 'GVC_IS_MIXER_CARD (card)' failed
> >
> > (cinnamon:9796): Cvc-CRITICAL **: gvc_mixer_card_get_index: assertion
> > 'GVC_IS_MIXER_CARD (card)' failed
> >
> > (cinnamon:9796): Cvc-CRITICAL **: gvc_mixer_card_get_index: assertion
> > 'GVC_IS_MIXER_CARD (card)' failed
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 20)
>
> I haven't seen these warnings before. I guess that something broke 
within the

> nvidia driver
>
> > Thread 1 "cinnamon" received signal SIGSEGV, Segmentation fault.
> > 0x7fffeb003010 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-
> > glcore.so.367.44
> > (gdb) bt
> > #0 0x7fffeb003010 in () at /usr/lib/x86_64-linux-gnu/libnvidia-
> > glcore.so.367.44
> > #1 0x7fffeaf1a311 in () at /usr/lib/x86_64-linux-gnu/libnvidia-
> > glcore.so.367.44
> > #2 0x7fffeaf24136 in () at /usr/lib/x86_64-linux-gnu/libnvidia-
> > glcore.so.367.44

I tried using kernel 4.7 instead of 3.16, which made no difference.
I also tried several version(s) of the nvidia-driver 367.44-3 (stretch), 
367.57-1 (sid), and 370.28-1 (experimental).


In all cases gdb generated the same backtrace.

I don't think this is an issue with the nvidia-driver, as a lot more 
should have been broken by it.

Bug#722451: Compiz team/package status.

2016-11-02 Thread Jean-Philippe MENGUAL

Hi,

1. Compiz in Debian

Yes, latest Compiz from Canonical will be in Debian 9. Upload is coming
soon, Hypra paid for a Debian dev to do it. We choosed Compiz from
Canonical because it's tested and mainstream. We don't use
Compiz-reloaded (0.8), as so few users, plugins, etc.

So yes, upload comes very soon (this month).

2. Compiz status

1st, be aware that the 1st upload will likely not work with Gnome 3.22.
Usable with MATE and other desktops, but not Gnome. Patches come.

Next, note that Canonical just maintains bugfixes now. It means that
bugs like Gnome compatibility will be fixed, but this package is about
dying for them (about 5 years). However, Hypra uses it with MATE for
low-vision features. Then, Hypra will probably be the next biggest
Compiz contributor through all features we plan. But of course, we'll
love to be helped by community and to see this project a;ive. So far, we
do pull request for Canonical and it's fine.

Best regards,


Le 02/11/2016 à 09:42, Harley Cascante a écrit :
> Guys, I'm a compiz "mere mortal" user, but I'd like to know what is the
> status of this project.
> Have your team been actively working on it lately? (late 2016).
> Any news on bringing compiz back to Debian's official repos?
> Thank you very much for your work and interest.
> I'd gladly help testing *basic* things if that helps speed the inclusion
> of the package or anything (I've got little to no programming skills sorry).
> 
> Sent from my Windows Phone

-- 
Jean-Philippe MENGUAL

HYPRA, progressons ensemble

Tél.: 01 84 73 06 61

Mail: cont...@hypra.fr

Site Web: http://hypra.fr

Bug#842993: /usr/bin/zip: Zip (or unzip) does not ALWAYS preserve the file time stamp correctly

2016-11-02 Thread Bergen A van

Package: zip
Version: 3.0-8
Severity: normal
File: /usr/bin/zip

Dear Maintainer,

BUG: Zip (or unzip) does not ALWAYS preserve the file time stamp
correctly as shown in example 1 and 2.

EXAMPLE 1:
-
$ cat >a1.txt
$ touch -t 201611021508.09 a1.txt
$ zip a1.zip a1.txt
$ mv a1.txt a2.txt
$ unzip a1.zip

time stamp of a1.txt : 201611021508.10
time stamp of a2.txt : 201611021508.09

EXAMPLE 2:
--
$ cat >b1.txt
$ touch -t 201611021508.06 b1.txt
$ zip b1.zip b1.txt
$ mv b1.txt b2.txt
$ unzip b1.zip

time stamp of b1.txt : 201611021508.06
time stamp of b2.txt : 201611021508.06

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
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 zip depends on:
ii  libbz2-1.0  1.0.6-7+b3
ii  libc6   2.19-18+deb8u6

Versions of packages zip recommends:
ii  unzip  6.0-16+deb8u2

zip suggests no packages.

-- no debconf information

Bug#842795: email-reminder: Fail to send email as release version cannot be detect

2016-11-02 Thread Jack.R

On Tue, 1 Nov 2016 09:48:41 -0700 Francois Marier 
wrote:
> On 2016-11-01 at 12:31:28, Jack.R wrote:
> > Not sure if this must be reported on email-reminder or lsb-release.
> 
> It looks like a bug in lsb-release since it's a Python backtrace and
> email-reminder is written in Perl, but if there's a way to
> work-around this bug in email-reminder, I'm happy to do it.
> 
> > In a root terminal, I got:
> > # su - email-reminder -s /bin/bash -c /usr/bin/lsb_release
> > No LSB modules are available.
> 
> I believe that's expected.
> 
> > # su - email-reminder -s /bin/bash -c `/usr/bin/lsb_release -a`
> > No LSB modules are available.
> > ID:: Distributor : commande introuvable
> 
> The problem here is the way the last parameter is escaped. Try this:
> 
>   sudo su - email-reminder -s /bin/bash -c "/usr/bin/lsb_release -a"
> 
> (with double quotes instead of backticks)
> 
> > # /usr/bin/lsb_release -a
> > No LSB modules are available.
> > Distributor ID: Debian
> > Description:Debian GNU/Linux testing (stretch)
> > Release:testing
> > Codename:   stretch
> 
> Ok, given that this works, what happens if you edit
> /usr/share/perl5/EmailReminder/Utils.pm and around line 140, change
> 
>   my $distro = `/usr/bin/lsb_release -s -d`; chomp $distro;
> 
> to this:
> 
>   my $distro = `/bin/sh -c "/usr/bin/lsb_release -s -d"`; chomp
> $distro;
> 
> Francois
> 
> -- 
> https://fmarier.org/
> 
> 

With double quotes instead of backticks
# sudo su - email-reminder -s /bin/bash -c "/usr/bin/lsb_release -a"
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux testing (stretch)
Release:testing
Codename:   stretch

# /bin/sh -c "/usr/bin/lsb_release -s -d"
Debian GNU/Linux testing (stretch)

I made the change in /usr/share/perl5/EmailReminder/Utils.pm but
still get error
# /etc/cron.daily/email-reminder 
Traceback (most recent call last):
  File "/usr/bin/lsb_release", line 95, in 
main()
  File "/usr/bin/lsb_release", line 59, in main
distinfo = lsb_release.get_distro_information()
  File "/usr/lib/python3/dist-packages/lsb_release.py", line 341, in
get_distro_information distinfo = guess_debian_release()
  File "/usr/lib/python3/dist-packages/lsb_release.py", line 283, in
guess_debian_release rinfo = guess_release_from_apt()
  File "/usr/lib/python3/dist-packages/lsb_release.py", line 188, in
guess_release_from_apt releases = parse_apt_policy()
  File "/usr/lib/python3/dist-packages/lsb_release.py", line 171, in
parse_apt_policy close_fds=True).communicate()[0].decode('utf-8')
  File "/usr/lib/python3.5/subprocess.py", line 947, in __init__
restore_signals, start_new_session)
  File "/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child
raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'apt-cache'
Error: could not mail the reminder out


-- 
Jack.R

Bug#828371: lastpass-cli openssl 1.1.0 now has PR upstream

2016-11-02 Thread Andreas Henriksson

Control: forwarded -1 https://github.com/lastpass/lastpass-cli/pull/215
Control: tags -1 + upstream patch

Hello!

I've sent a PR to upstream that fixes building against OpenSSL 1.1.0.
Same patch should apply cleanly to the packaged version.

Regards,
Andreas Henriksson

Bug#842960: git-buildpackage: Please Build-Depend on libdistro-info-perl

2016-11-02 Thread Guido Günther

On Wed, Nov 02, 2016 at 04:53:27PM -0400, Jeremy Bicha wrote:
> On Wed, Nov 2, 2016 at 4:26 PM, Guido Günther  wrote:
> > Build failures on Ubuntu are not severity important.
> 
> I'm not so sure about that. At least 'important' isn't RC.

I am sure about that. You don't need that package to build
git-buildpackage on Debian.

Bug#841919: [Letsencrypt-devel] Bug#841919: Bug#841919: Bug#841919: Bug#841919: acme-tiny: Please provide a backport for jessie

2016-11-02 Thread Jeremías Casteglione

On Wed, 2 Nov 2016 06:56:20 +
Mattia Rizzolo  wrote:

> > > * Uploads to backports don't close bugs, so even if you put a Closes:
> > >   there you'd need to close this bug manually nonetheless  
> > 
> > OK, thanks... No problem with that, but I still need to upload it to
> > backports right? Even if you are going to sponsoring it?  
> 
> Yeah, that's fine.  It just means you'll have to manually mail
> -done to close this bug once the backport is accepted.

Good, thanks for the upload!

> > > (on a related note, I also noticed only now that there is no upstream/*
> > > tags metching the upstream releases; could you please add them too?)  
> > 
> > I'm not sure about that... All the commits in the upstream branch were
> > auto done by git-dpm... And upstream didn't make any release either,
> > really. That's why we use the timestamp of last commit for the package
> > version and such.
> > 
> > So not sure about any tags, sorry, but I'm OK to adding whatever is
> > missing =)
> > 
> > There are actually 3 commits in the upstream branch, one for each
> > "release". I guess you mean to tag those commits?  
> 
> Ouch, I didn't realized you were using git-dpm u.U
> Hence my surprise, because with gbp the upstream tags are created at
> upstream import time, whilst with git-dpm that's all part of the
> `git-dpm tag` command run while uploading.
> I pushed a commit configuring git-dpm's tags to be sane, and run it
> while building the backport, and now there is also a upstream/ tag.
> *shrug* nvm for the older ones.

Great, I didn't know about the `git-dpm tag` thing...

Thanks for your help Mattia.

Cheers,


-- 
Jeremías


pgpB_fhIx26GO.pgp
Description: OpenPGP digital signature

Bug#842879: no alternate way to find how long they have been running?

2016-11-02 Thread Craig Small

stat the processes' stat file perhaps? Using a find?

$ ps -o lstart 2730
 STARTED
Mon Oct 31 16:03:54 2016

$ stat /proc/2730/stat
  File: '/proc/2730/stat'
  Size: 0 Blocks: 0  IO Block: 1024   regular empty file
Device: 4h/4d Inode: 15018747Links: 1
Access: (0444/-r--r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2016-10-31 16:03:56.476938217 +1100
Modify: 2016-10-31 16:03:56.476938217 +1100
Change: 2016-10-31 16:03:56.476938217 +1100
 Birth: -


On Thu, Nov 3, 2016 at 1:01 AM 積丹尼 Dan Jacobson  wrote:

> By the way, I wanted to set up a cronjob that would find and warn me
> about any of my processes that were running more than a day. But now
> apparently there is no way...
>

Bug#842239: Arbitrary document metadata date chosen

2016-11-02 Thread Jeffrey Ratcliffe

As of v1.5.0, the document date metadata field defaults to the
previous date used. I made this change to fix time zone problems
people near the international date line were having.

For the next version, I have gone back to storing an date offset,
using a new dependency to calculate them. I hope that this will make
everyone happier.

Bug#842960: git-buildpackage: Please Build-Depend on libdistro-info-perl

2016-11-02 Thread Jeremy Bicha

On Wed, Nov 2, 2016 at 4:26 PM, Guido Günther  wrote:
> Build failures on Ubuntu are not severity important.

I'm not so sure about that. At least 'important' isn't RC.

Ignoring Ubuntu for now, https://bugs.debian.org/807488 suggests that
having sbuild's apt not install recommends is reasonable and it is a
problem for a package to fail to build in that situation.

As long as this bug gets fixed, it doesn't really matter what its severity is.

Jeremy

Bug#842496: closed by Thomas Goirand (Re: [PKG-Openstack-devel] neutron-fwaas-common: Missing /usr/bin/neutron-fwaas-l3-agent 'binary')

2016-11-02 Thread Turbo Fredriksson

On 1 Nov 2016, at 17:42, Debian Bug Tracking System  
wrote:
> 
>  * Remove the neutron-fwaas-l3-agent init script, as this package is
> now just a plugin. Make the neutron-fwaas-l3-agent package a transition
> package.

Ok, so this was done between the "1:9.0.0~b2-1” and "1:9.0.0~rc1-1” which is 
(in) a RC
release.

   !!! You CAN NOT do major changes like this in minor releases !!!

Not without making it VERY CLEAR for the user that this HAD to be done (and a
very good explanation of why!
Such notice would be a warning, using debconf etc.

And you MUST provide an upgrade path! Just saying in a change log (which 
isn’t for the user - _NO ONE_ reads them, it’s for you as an administrator) 
isn’t
NEARLY enough!!

How do I now get my FWaaS working again?

Bug#841488: Proposal

2016-11-02 Thread Michael Lustfield

This is turning into a larger set of changes...

opinions welcome

-- 
Michael Lustfield
diff --git a/debian/conf/sites-available/default b/debian/conf/sites-available/default
index 79e41e8..d6d0d7b 100644
--- a/debian/conf/sites-available/default
+++ b/debian/conf/sites-available/default
@@ -35,41 +35,50 @@ server {
 
 	root /var/www/html;
 
-	# Add index.php to the list if you are using PHP
 	index index.html index.htm index.nginx-debian.html;
 
 	server_name _;
 
 	location / {
-		# First attempt to serve request as file, then
-		# as directory, then fall back to displaying a 404.
+		# This will first try to serve the static file requested. If this
+		# is not found, then see if the path is a directory. If it is a
+		# directory, check for the existance of index files in the order
+		# presented by the index directive and serve if a matche is found.
+		# The last parameter is a fallback and must always exist. This
+		# example will return a 404 respones if no files are found.
+		#
+		# This represents the default try_files directive:
 		try_files $uri $uri/ =404;
 	}
 
-	# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
+	# Pass the PHP scripts to a FastCGI application server
+	# in some cases, "index.php" should be added to the (above) index directive
 	#
 	#location ~ \.php$ {
 	#	include snippets/fastcgi-php.conf;
-	#
-	#	# With php5-cgi alone:
-	#	fastcgi_pass 127.0.0.1:9000;
-	#	# With php5-fpm:
-	#	fastcgi_pass unix:/var/run/php5-fpm.sock;
+	#	# If using php-fpm, this is the default socket location. If you have
+	#	# a different version of php-fpm installed, this may be different.
+	#	fastcgi_pass unix:/var/run/php7.0-fpm.sock
 	#}
 
-	# deny access to .htaccess files, if Apache's document root
-	# concurs with nginx's one
+	# If your web application was designed to be run on apache, it likely
+	# has .htaccess and possibly a .htpasswd file embedded. It is typically
+	# recommended to remove access to these files.
 	#
-	#location ~ /\.ht {
-	#	deny all;
-	#}
+	# If you are using apache as your application server, we strongly
+	# recommend looking into uwsgi as an alternative.
+	#
+	location ~ /\.ht {
+		deny all;
+	}
 }
 
 
 # Virtual Host configuration for example.com
 #
-# You can move that to a different file under sites-available/ and symlink that
-# to sites-enabled/ to enable it.
+# You can create files underneath the sites-available/ directory and symlink to
+# them from sites-enabled/. Once nginx has been reloaded, the changes will take
+# effect. (service nginx reload)
 #
 #server {
 #	listen 80;
@@ -81,6 +90,6 @@ server {
 #	index index.html;
 #
 #	location / {
-#		try_files $uri $uri/ =404;
+#		try_files $uri =404;
 #	}
 #}

Bug#842990: vim-gtk3: gvim has the smallest possible text window

2016-11-02 Thread James McCoy

Control: reassign -1 libgtk-3-0 3.22.2-1
Control: forcemerge 842070 -1

On Wed, Nov 02, 2016 at 09:11:13PM +0100, Ayke van Laethem wrote:
> When running gvim (from the vim-gtk3 package), the whole text window is
> invisible. It looks like it has shrunk so small to be unusable. See the
> attached screenshot.

Yes, this has been reported and should have showed up in the existing
bug list when you used reportbug.  It's due to a change in gtk3, and
there's ongoing discussion about where is the right place to fix the
problem.

Merging with the other bugs.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#842960: git-buildpackage: Please Build-Depend on libdistro-info-perl

2016-11-02 Thread Guido Günther

ccontrol: severity -1 wishlist

Hi Jeremy,
On Wed, Nov 02, 2016 at 12:30:58PM -0400, Jeremy Bicha wrote:
> Package: git-buildpackage
> Version: 0.8.6
> Severity: important
> 
> git-buildpackage fails to build on Ubuntu. Maybe Ubuntu's builders
> don't install recommends like Debian does? devscripts only recommends
> libdistro-info-perl. This can be fixed by adding libdistro-info-perl
> to git-buildpackage's Build-Depends.
> 
> Traceback (most recent call last):
>   File "/<>/tests/11_test_dch_main.py", line 328, in
> test_dch_main_increment_debian_version_with_auto_release
> self.assertEqual("test-package (%s) %s; urgency=%s\n" %
> (new_version_0_9, os_codename, default_urgency), lines[0])
> AssertionError: 'test-package (0.9-1ubuntu1) zesty; urgency=medium\n'
> != 'test-package (0.9-1ubuntu1) yakkety; urgency=medium\n'
>  >> begin captured stdout << -
> libdistro-info-perl is not installed, Debian release names are not known.

Build failures on Ubuntu are not severity important.
Cheers,
 -- Guido

Bug#842911: [Pkg-libvirt-maintainers] Bug#842911: please reconsider dropping libvirt-bin

2016-11-02 Thread Guido Günther

conrol: -1 wontfix

Hi,
On Wed, Nov 02, 2016 at 09:36:21AM +, Riku Voipio wrote:
> Package: libvirt
> Version: 2.3.0-3
> Severity: wishlist
> 
> Hi,
> 
> libvirt-bin is still referred to in many places, for example in openstack
> devstack. The replacement -clients and -daemon-system packages are not yet
> available in the latest ubuntu LTS. This leads to some inconvinient
> "if ubuntu then else if debian newer than then" checks if we want to support 
> both.

It's simple as:

Depends: libvirt-daemon-system | libvirt-bin, libvirt-clients | libvirt-bin

so I'd rather not readd the transitional package. I don't want to make
people's lifes harder than necessary though so if you think it's more
complex please explain.
Cheers,
 -- Guido

Bug#842991: python-axolotl-curve25519: please make the build reproducible

2016-11-02 Thread Reiner Herrmann

Source: python-axolotl-curve25519
Version: 0.1-2
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that python-axolotl-curve25519 could not be built reproducibly.
During build objects are linked in non-deterministic order.

The attached patch fixes this by sorting the list of source files.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..04ed5be
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort list of source files for deterministic linking order
+
+--- a/setup.py
 b/setup.py
+@@ -8,7 +8,7 @@
+ sources.extend(glob("curve/ed25519/nacl_sha512/*.c"))
+ #headers = ['curve25519-donna.h']
+ module_curve = Extension('axolotl_curve25519',
+-sources = sources,
++sources = sorted(sources),
+ #   headers = headers,
+ include_dirs = [
+   'curve/ed25519/nacl_includes',
diff --git a/debian/patches/series b/debian/patches/series
index c7c612c..4174e07 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 fix-unsigned-char-warnings.patch
 removes-unused-variables.patch
 add-prototype.patch
+reproducible-build.patch


signature.asc
Description: PGP signature

Bug#842992: pyephem: please make the build reproducible

2016-11-02 Thread Reiner Herrmann

Source: pyephem
Version: 3.7.6.0-6
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that pyephem could not be built reproducibly.
During build it links object files in non-deterministic order.

The attached patch fixes this by sorting the list of source files.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible_build.patch b/debian/patches/reproducible_build.patch
new file mode 100644
index 000..72e4a60
--- /dev/null
+++ b/debian/patches/reproducible_build.patch
@@ -0,0 +1,16 @@
+Author: Reiner Herrmann 
+Description: Sort source files for deterministic linking order
+
+--- a/setup.py
 b/setup.py
+@@ -13,8 +13,8 @@
+ # directory plus ...
+ 
+ libastro_version = '3.7.6'
+-libastro_files = glob('libastro-%s/*.c' % libastro_version)
+-libastro_data = glob('extensions/data/*.c')
++libastro_files = sorted(glob('libastro-%s/*.c' % libastro_version))
++libastro_data = sorted(glob('extensions/data/*.c'))
+ 
+ def read(*filenames):
+ return open(os.path.join(os.path.dirname(__file__), *filenames)).read()
diff --git a/debian/patches/series b/debian/patches/series
index 94d33e5..df14648 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ fix_tests_unicode.patch
 spellfix.patch
 disable_failing_tests.patch
 fix_string_to_double.patch
+reproducible_build.patch


signature.asc
Description: PGP signature

Bug#842978: pv FTCBFS: uses build architecture ld

2016-11-02 Thread Antoine Beaupré

On 2016-11-02 16:10:14, Helmut Grohne wrote:
> On Wed, Nov 02, 2016 at 02:37:35PM -0400, Antoine Beaupré wrote:
>> Hmm... I am not very familiar with cross-compiling, but this looks to me
>> like a toolchain issue. pv doesn't do anything particular to call "the
>> wrong LD" - why should I have to pass a specific linker here?
>
> That's a good question. I was surprised by the need as well.
>
> Crucially, when cross compiling you need to prefix each and every build
> tool with the host architecture triplet (DEB_HOST_GNU_TYPE). Typically,
> autotools does that for you by prefixing every tool with $ac_tool_prefix.
>
>> in other words, why isn't this in dh_auto_build, dh_build, or make or
>> wherever it should be down the stack?
>
> Because, normally autotools handles this. It just doesn't for pv.
>
>> Don't all gnu autoconf packages suffer from the same bug?
>
> pv's Makefiles rely on the make default value of LD instead of taking
> that value from autoconf. So no, other autoconf packages that actually
> use autoconf for determining LD, do not suffer from this issue.
>
> Quite likely, there is a more general solution to this problem than my
> patch. I just didn't figure it out. One approach could be linking with
> $CC rather than $LD as autotools supply a suitable $CC. If this change
> works natively, it'll also work for cross compilation.

Thank you for the clarifications.

I guess the next step is whether there should be a patch sent upstream,
what do you think?

A.
-- 
The greatest crimes in the world are not committed by people breaking
the rules but by people following the rules. It's people who follow
orders that drop bombs and massacre villages.
- Bansky

Bug#841247: [Calendarserver-maintainers] Bug#841247: calypso: UnicodeDecodeError when importing an .ics

2016-11-02 Thread Guido Günther

Hi Mathias,

On Wed, Nov 02, 2016 at 01:14:02PM +0100, Mathias Behrle wrote:
> control: affects -1 + tryton-modules-calendar 
> tryton-modules-calendar-classification tryton-modules-calendar-scheduling 
> tryton-modules-calendar-todo tryton-modules-party-vcarddav tryton-meta
> 
> > From: Guido Günther 
> > To: Jens Reyer , 841...@bugs.debian.org
> > Subject: Re: Bug#841247: calypso: UnicodeDecodeError when importing an .ics
> > Date: Sun, 23 Oct 2016 12:28:37 +0200
>  
> 
> Hi Guido,
> 
> > The unicode handling for python 2.7 got broken in upstream commit
> > 
> > 
> > https://github.com/eventable/vobject/commit/b3f9bbcf4cf222f0dda3ac29f96364c5d7ab5f16
> > 
> > Let's see if upstream cares at all. If not we should rather drop the
> > python2.7 version for stretch.
> 
> There are currently 6 Tryton modules affected as rdepends of python-vobject.
> There are still some bits in the Tryton framework lacking Python3 support, so
> it is currently not possible to switch the whole Tryton stuff to Python3 (and 
> I
> suppose this won't be the case for stretch). Dropping the Python2 version of
> python-vobject would seriously hurt those Tryton modules. So please let's find
> a way to keep the Python2 version in the archive (for stretch).

It breaks calyso as well which I'd rather see in the archive than
removed.

The bug is fixable. Someone needs to sit down and cook a patch. I have
it on the TODO list but work is piling up at the moment - but I hope to
get it done til the end of the year.

Somebody uploading 0.8.x for python2 would be another option.

Cheers,
 -- Guido

Bug#840516: doesn't work with django 1.10

2016-11-02 Thread Sandro Tosi

On Wed, 12 Oct 2016 13:35:14 +0200 Daniel Baumann
 wrote:
> Package: graphite-web
> Version: 0.9.15+debian-2
> Severity: serious
>
> Hi Jonas,
>
> graphite-web doesn't work with django 1.10 anymore, can you please upgrade?

Hello Daniel,
can you provide a bit more content, like for example what error you get?

Upstream latest release is what is packaged in debian so there is
nothing to upgrade to.

from the looks at
https://github.com/graphite-project/graphite-web/commit/5d139bd878afad4e63be4f50e909aff9b27c7327
it looks like graphite-web only wants to support 1.9.*

1 2 3 4 >

1 - 100 of 323 matches

Mail list logo