Bug#818913: pulseaudio: Have to restart pulseaudio after (re)connecting bluetooth speaker

[Felipe Sateler]

Control: tags -1 moreinfo

On 21 March 2016 at 13:52, Tony Houghton  wrote:
> Package: pulseaudio
> Version: 8.0-1
> Severity: normal
>
> I have a Multitech The Block 4.0 bluetooth speaker. I've followed
> , including adding
> 'load-module module-switch-on-connect' to /etc/pulse/default.pa and it
> basically now works.
>
> However, if I turn the speaker off and then back on later, I have to
> restart pulseaudio (killall pulseaudio) to be able to use it. It shows
> up in pavucontrol's Configuration tab, but its Profile is "Off" there.
> If I change it (to A2DP Sink) it still doesnt show up in Output Devices,
> and if I reload pavucontrol I find the profile has changed back to Off.
> After pulseaudio is killed and restarted the speaker chimes (presumably
> to indicate the laptop has just connected) and becomes available as an
> output device.

Does it work if you restart bluetooth daemon instead?

Also, please attach verbose logs of pulseaudio[1].


[1] https://wiki.ubuntu.com/PulseAudio/Log

-- 

Saludos,
Felipe Sateler

Bug#818914: adwaita-icon-theme: Missing icon for bluetooth speaker

[Tony Houghton]

Package: adwaita-icon-theme
Version: 3.18.0-2
Severity: normal

Both GNOME Settings and pavucontrol show the "missing" icon for my
bluetooth speaker. I added a little logging to pavucontrol and it
appears the icon name it requests is "audio-handsfree-bluetooth".

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

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

Versions of packages adwaita-icon-theme depends on:
ii  hicolor-icon-theme  0.13-1
ii  libgtk-3-bin3.18.9-1
ii  librsvg2-common 2.40.13-3

adwaita-icon-theme recommends no packages.

adwaita-icon-theme suggests no packages.

-- no debconf information

Bug#818913: pulseaudio: Have to restart pulseaudio after (re)connecting bluetooth speaker

[Tony Houghton]

Package: pulseaudio
Version: 8.0-1
Severity: normal

I have a Multitech The Block 4.0 bluetooth speaker. I've followed
, including adding
'load-module module-switch-on-connect' to /etc/pulse/default.pa and it
basically now works.

However, if I turn the speaker off and then back on later, I have to
restart pulseaudio (killall pulseaudio) to be able to use it. It shows
up in pavucontrol's Configuration tab, but its Profile is "Off" there.
If I change it (to A2DP Sink) it still doesnt show up in Output Devices,
and if I reload pavucontrol I find the profile has changed back to Off.
After pulseaudio is killed and restarted the speaker chimes (presumably
to indicate the laptop has just connected) and becomes available as an
output device.

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser   3.114
ii  libasound21.1.0-1
ii  libasound2-plugins1.1.0-1
ii  libc6 2.22-3
ii  libcap2   1:2.24-12
ii  libdbus-1-3   1.10.8-1
ii  libfftw3-single3  3.3.4-2+b1
ii  libgcc1   1:5.3.1-11
ii  libice6   2:1.0.9-1+b1
ii  libltdl7  2.4.6-0.1
ii  liborc-0.4-0  1:0.4.25-1
ii  libpulse0 8.0-1
ii  libsm62:1.2.2-1+b1
ii  libsndfile1   1.0.25-10
ii  libsoxr0  0.1.2-1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libstdc++65.3.1-11
ii  libsystemd0   229-2
ii  libtdb1   1.3.8-2
ii  libudev1  229-2
ii  libwebrtc-audio-processing-0  0.1-3
ii  libx11-6  2:1.6.3-1
ii  libx11-xcb1   2:1.6.3-1
ii  libxcb1   1.11.1-1
ii  libxtst6  2:1.2.2-1+b1
ii  lsb-base  9.20160110
ii  pulseaudio-utils  8.0-1
ii  udev  229-2

Versions of packages pulseaudio recommends:
ii  pulseaudio-module-x11  8.0-1
ii  rtkit  0.11-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-3+b2
pn  pavumeter

-- Configuration Files:
/etc/pulse/default.pa changed:
.nofail
.fail
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-augment-properties
load-module module-switch-on-port-available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
load-module module-detect
.endif
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif
.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix
.endif
load-module module-native-protocol-unix
.ifexists module-gconf.so
.nofail
load-module module-gconf
.fail
.endif
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-always-sink
load-module module-intended-roles
load-module module-suspend-on-idle
.ifexists module-console-kit.so
load-module module-console-kit
.endif
.ifexists module-systemd-login.so
load-module module-systemd-login
.endif
load-module module-position-event-sounds
load-module module-role-cork
load-module module-filter-heuristics
load-module module-filter-apply
load-module module-switch-on-connect


-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; 

Bug#818912: apt-cudf shouldn't exit non-zero if it isn't crashing

[David Kalnischkies]

Package: apt-cudf
Version: 4.1-4
Severity: minor

Hi,

$ apt install exim4 postfix -s --solver aspcud
[… busy working for a while …]
[ currently a useless apt unmet dependency error ]
E: Sub-process aspcud returned an error code (1)

That isn't what is supposed to happen, the spec says:

"When the external solver is *unable to find a solution* (and is aware
of that), it will write an error to standard output and then exit with
an exit code of 0. An exit code other than 0 will be interpreted as
a solver crash […]"

Correct would be to exit 0 so that apt shows the error message of the
solver rather than a useless own error (= useless as it will report all
unmet dependencies which will be plenty as nothing was resolved
– I would like to change that to something describing that this is a bug
in the resolver and should be reported, but doing that for unsatisfiable
requests would be wrong).

The difference for the user is a bit dubious at the moment so its at
best minor even if its a spec violation as all aspcud has to say for
itself in this case is:
Message: (UNSAT) No Solutions according to the given preferences

And people complain about apt having unhelpful errors in unsat cases… ;)


I am reporting against apt-cudf instead of aspcud as the 'Message:'
indicates that this could actually be formatted as a proper EDSP error
by apt-cudf.


I tried the other solvers in debian ATM as well:
* packup receives signal 13 (SIGPIPE), so exit 1 is "correct" I guess,
  but it does it also on requests which could be satisfied…
* mccs-lpsolve and mccs-cbc both exit 1 with a message suggesting a more
  general problem with them/apt-cudf:
  Message: The solver does not recognize the MISC 2012 optimization language.
  Please specifify the optimization criteria using --criteria-plain


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#818124: easymp3gain: FTBFS in stretch

[Matthias Klumpp]

Hi!
I really wonder if this is still worth fixing... This package is dead
upstream (upstream vanished, every attempt to contact him again
failed), and I am essentially keeping it on life-support here. It also
has a relatively low popcon index, and I announced that it is
threatened to be removed about a year ago, unless maybe someone take
over upstream maintenance or forks it.
Additionally, mp3gain isn't present in Debian anymore, only
vorbisgain, which makes this package even less useful.

So tl;dr, I think removing the package from Debian is sadly the better
option than fixing yet another FTBFS. If there are still users, maybe
a different maintainer who actually still uses this package and can
fix functional issues can take it over.

I will leave this issue open for a while, maybe wait for the package
to be removed from testing and wait for feedback - if there is
sufficint interest, I might revive the package even. Otherwise, I
intend to drop it from Debian in a month.

Cheers,
Matthias

Bug#814921: RFS: sphde/1.1.0-1 [ITP] -- sphde -- Shared Persistent Heap Data Environment library

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi,
control: std-version is now 3.9.7

libjs-query can be left as-is, because using the internal debian jquery might 
result in a bad documentation
package (look e.g. https://lists.debian.org/debian-devel/2014/10/msg00774.html;)

this can simplify rules, control and so on

debian/*.manpages, you can remove the "debian/tmp" prepending path I think

copyright: is the debian directory under the same author as upstream?
so you can avoid mentioning it.


package FTBFS on i386 and probably everywhere except amd64 (tested amd64, arm64 
and i386 for now).


check-all-the-things:
flawfinder -Q -c .

[lots]
codespell --quiet-level=3
[lots]
some stuff autogenerated seems to be GPL-2 (check-all-the-things output)

the other stuff LGTM.

cheers,

G.



Il Martedì 16 Febbraio 2016 17:03, Frederic Bonnard  
ha scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sphde"

Package name: sphde
Version : 1.1.0-1
Upstream Author : SPHDE team
URL : https://github.com/sphde/sphde
License : EPL-1
Section : devel

It builds those binary packages:

  libsphde-dev - Shared Persistent Heap Data Environment library development 
files
  libsphde-doc - Shared Persistent Heap Data Environment library documentation 
files
  libsphde1  - Shared Persistent Heap Data Environment library

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

  https://mentors.debian.net/package/sphde


Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/s/sphde/sphde_1.1.0-1.dsc

More information about sphde can be obtained from https://github.com/sphde/sphde

Regards,
Frederic Bonnard

Bug#818915: sdformat: test dep on non-existent libsdformat-dev package

[Steve Langasek]

Package: sdformat
Version: 4.0.0-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Your package has a test dependency (debian/tests/control) on
libsdformat-dev.  However, no package by this name is being generated by
your package.

It's simpler to declare a dependency on '@', which translates as 'all the
binary packages produced by this source'; then you don't have to keep it
up to date as your package names change.

Please see the attached patch.
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru sdformat-4.0.0/debian/tests/control sdformat-4.0.0/debian/tests/control
--- sdformat-4.0.0/debian/tests/control	2016-01-20 13:20:11.0 -0800
+++ sdformat-4.0.0/debian/tests/control	2016-03-21 10:31:29.0 -0700
@@ -1,2 +1,2 @@
 Tests: build
-Depends: libsdformat-dev, pkg-config, build-essential
+Depends: @, pkg-config, build-essential

Bug#818917: Replaced by ruby2.3

[Christian Hofstaedtler]

Package: ruby2.2

We're not going to maintain ruby2.2 for the entire stretch cycle, as
such it should go now. ruby2.3 is already in stretch.

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

Bug#813237: transition: ruby2.3 / followup with -rm transition?

[Christian Hofstaedtler]

Hello,

I think we're done with the ruby2.3 transition now (apart from
libguestfs/mips).

It'd be good if we could do the followup ruby2.2-rm transition
soonish. What does -release think about that?

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

Bug#773425: please increase default logrotate duration for /var/log/dpkg.log

[Guillem Jover]

Hi!

On Thu, 2014-12-18 at 10:12:27 +0100, Stefano Zacchiroli wrote:
> Package: dpkg
> Version: 1.17.21
> Severity: normal
> 
> The default logrotate settings for /var/log/dpkg.log (from
> /etc/logrotate.d/dpkg) have "monthly 12", which grants a 1-year long history 
> of
> dpkg operations.
> 
> It would be desirable to have a longer history than that by default, ideally a
> *complete* history, dating back to the original installation.

Given that the default logrotate config sets both weekly and rotate, not
setting the intervals will make the entries use the defaults instead of
unlimited, and I don't see a way to reset those values.

> Considering how small dpkg.log usually is in comparison to other log files in
> /var/log, doing so looks feasible. The disk usage would cap at few megabytes
> for routinely updated stable machines over a 10-year period.
> 
> If you don't want to go unlimited history, bumping to a max of 10 years (maybe
> increasing rotation period as well to 1 year) would be nice. Anything in
> between would be nicer tha a 1-year long history only.

This would diverge greatly from other log files, some of which might
also be very tiny on normal installations. I also discussed this briefly
with the apt maintainers and they didn't see the point in changing the
apt log settings to have unified values across package manager software.
And lastly if not for simple historical reasons, such long term data
tends to be useless for stuff like bug tracking or reporting. Given all
the above, I'm rather uncomfortable with changing the defaults

I think that if something like this needs to be done, it needs to be
within a wider discussion on the default log rotation settings.
Otherwise I'm inclined to just close this request.

Regards,
Guillem

Bug#818920: bluez-tools: bt-agent segfault on pin-entry

[Andreas Metzler]

Package: bluez-tools
Version: 0.2.0~20140808-5
Severity: important

bt-agent segfaults on pin-entry:


ametzler@argenau:~$ gdb bt-agent
[...]
(gdb) run
Starting program: /usr/bin/bt-agent
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x75e0e700 (LWP 13039)]
[New Thread 0x7560d700 (LWP 13040)]
Agent registered
Default agent requested
Device: foobarfoobar (xx:xx:xx:xx:xx:xx)
Enter passkey: 123456789

Program received signal SIGSEGV, Segmentation fault.
0x77b467e0 in g_utf8_validate ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt full
#0  0x77b467e0 in g_utf8_validate ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#1  0x77b4a117 in g_variant_new_string ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x00403de0 in ?? ()
No symbol table info available.
#3  0x7781baec in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
No symbol table info available.
#4  0x77b15e8a in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#5  0x77b16230 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#6  0x77b16552 in g_main_loop_run ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#7  0x00403120 in ?? ()
No symbol table info available.
#8  0x77174610 in __libc_start_main ()
   from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#9  0x004031f9 in ?? ()
No symbol table info available.
(gdb) set pagination 0
(gdb) info registers
rax0x2  2
rbx0x3837363534333231   4050765991979987505
rcx0xa  10
rdx0x0  0
rsi0x   -1
rdi0x3837363534333231   4050765991979987505
rbp0x648ce0 0x648ce0
rsp0x7fffe0a8   0x7fffe0a8
r8 0x0  0
r9 0x77fdd800   140737353996288
r100x27c636
r110x77b4a100   140737349198080
r120x0  0
r130x7fffe8005c80   140737085725824
r140x7fffe8006a40   140737085729344
r150x7fffe8006be0   140737085729760
rip0x77b467e0   0x77b467e0 
eflags 0x10286  [ PF SF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0
(gdb) x/16i $pc
=> 0x77b467e0 :movzbl (%rdi),%eax
   0x77b467e3 :test   %al,%al
   0x77b467e5 :jne0x77b467fc 

   0x77b467e7 :jmp0x77b46816 

   0x77b467e9 :nopl   0x0(%rax)
   0x77b467f0 :movzbl 0x1(%rcx),%eax
   0x77b467f4 :lea0x1(%rcx),%rdi
   0x77b467f8 :test   %al,%al
   0x77b467fa :je 0x77b46816 

   0x77b467fc :test   %al,%al
   0x77b467fe :mov%rdi,%rcx
   0x77b46801 :jns0x77b467f0 

   0x77b46803 :cmp$0xdf,%al
   0x77b46805 :ja 0x77b46830 

   0x77b46807 :cmp$0xc1,%al
   0x77b46809 :jbe0x77b46816 

(gdb) thread apply all backtrace

Thread 3 (Thread 0x7560d700 (LWP 13040)):
#0  0x77233e4d in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x77b161cc in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77b16552 in g_main_loop_run () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7782b396 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x77b3c9c5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x76cce454 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7723cedd in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x75e0e700 (LWP 13039)):
#0  0x77233e4d in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x77b161cc in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77b162dc in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77b16319 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77b3c9c5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x76cce454 in start_thread () from 

Bug#818916: live-build: Wrong version extracted from os-release in binary-syslinux

[adrian15]

Package: live-build
Version: 5.0~a11-1
Severity: minor

Dear Maintainer,

   * What led up to the situation?

I was trying to use @VERSION@ string in splash.svg.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I used @VERSION@ string in splash.svg.
   * What was the outcome of this action?
@VERSION@ was replaced by: 5.0~a11-1 which it's the live-build package 
version.

   * What outcome did you expect instead?
@VERSION@ should have been replaced by: 8 (The version read from 
os-release for

my build) which it's the distro, in this case Debian, version.

Additional information. I attach a trivial patch which solves the problem.


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From b516d2defaeda72a03400dbd1a17b91d6bca7e31 Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Mon, 21 Mar 2016 18:44:38 +0100
Subject: [PATCH] @VERSION@ now its equal to VERSION_ID variable. Fixes a typo.

---
 scripts/build/binary_syslinux | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/build/binary_syslinux b/scripts/build/binary_syslinux
index 024b563..66c14a0 100755
--- a/scripts/build/binary_syslinux
+++ b/scripts/build/binary_syslinux
@@ -248,7 +248,7 @@ then
 	_VERSION="$(. chroot/etc/os-release && echo ${VERSION_ID})"
 fi
 
-_VERSION="${VERSION:-none}"
+_VERSION="${_VERSION:-none}"
 
 _DISTRIBUTION="${LB_DISTRIBUTION}"
 _ARCHITECTURE="${LB_ARCHITECTURES}"
-- 
2.1.4

Bug#818896: [Pkg-sass-devel] Bug#818896: libsass: upgrade welcome to fix FTBFS/autoremoval for libsass-python

[Jonas Smedegaard]

Hi Fred,

Quoting Frederic Bonnard (2016-03-21 15:04:23)
> I see that libsass 3.3.4 is out. If you have some time for it, could 
> you upgrade the version in Sid to that last one ?

Thanks for the notice.

Sure - I will try make time for looking into this later tonight.

 - Jonas

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

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


signature.asc
Description: signature

Bug#818349: exim4-base: Still warns about purging the environment, even with add_environment set

[Andreas Metzler]

On 2016-03-21 Matthew Vernon  wrote:
> On 16/03/16 16:41, Andreas Metzler wrote:

>> So, this is documented behavior, pulling an enhancement for  the issue
>> from upstream.

> It's also not what is done in the version in testing - 4.86.2-2 is happy
> with add_environment (and no keep_environment set), which is consistent
> with the upstream announcement.

That is going to change.

And just for clarification: This is not Debian making evil changes to
exim, diverging from upstream behavior. The respective patch
originates from upstream GIT, both master and exim-4_84_2+fixes branch.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#818919: aptitude markauto runs wild, if package does not exist

[ziegler]

Package: aptitude
Version: 0.7.8-1
Severity: normal
Tags: upstream

Dear Maintainer,

If PATTERN does not match a package, the command

   aptitude markauto PATTERN

does not stop, using 100% CPU. Example

 aptitude markauto 1234

The same is true for "aptitude forbid-version".

Regards,

Martin

-- Package-specific info:
Terminal: linux
$DISPLAY not set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.8
Compiler: g++ 5.3.1 20160224
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.6.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20160213
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffe82493000)
libapt-pkg.so.5.0 =3D> /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x00=
007f304c83a000)
libncursesw.so.5 =3D> /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f30=
4c60a000)
libtinfo.so.5 =3D> /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f304c3df0=
00)
libsigc-2.0.so.0 =3D> /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x=
7f304c1d9000)
libcwidget.so.3 =3D> /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f=
304bedc000)
libsqlite3.so.0 =3D> /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f=
304bbe4000)
libboost_iostreams.so.1.58.0 =3D> 
/usr/lib/x86_64-linux-gnu/libboost_ios=
treams.so.1.58.0 (0x7f304b9ca000)
libboost_filesystem.so.1.58.0 =3D> 
/usr/lib/x86_64-linux-gnu/libboost_fi=
lesystem.so.1.58.0 (0x7f304b7b1000)
libboost_system.so.1.58.0 =3D> 
/usr/lib/x86_64-linux-gnu/libboost_system=
.so.1.58.0 (0x7f304b5ac000)
libxapian.so.22 =3D> /usr/lib/x86_64-linux-gnu/libxapian.so.22 
(0x7f=
304b1a8000)
libpthread.so.0 =3D> /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f304a=
f8b000)
libstdc++.so.6 =3D> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f30=
4ac0f000)
libm.so.6 =3D> /lib/x86_64-linux-gnu/libm.so.6 (0x7f304a911000)
libgcc_s.so.1 =3D> /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f304a6fb0=
00)
libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 (0x7f304a356000)
libutil.so.1 =3D> /lib/x86_64-linux-gnu/libutil.so.1 
(0x7f304a153000=
)
libdl.so.2 =3D> /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3049f4f000)
libresolv.so.2 =3D> /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f3049d3=
7000)
libz.so.1 =3D> /lib/x86_64-linux-gnu/libz.so.1 (0x7f3049b1c000)
libbz2.so.1.0 =3D> /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f304990c0=
00)
liblzma.so.5 =3D> /lib/x86_64-linux-gnu/liblzma.so.5 
(0x7f30496e8000=
)
liblz4.so.1 =3D> /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f30494d60=
00)
librt.so.1 =3D> /lib/x86_64-linux-gnu/librt.so.1 (0x7f30492cd000)
libuuid.so.1 =3D> /lib/x86_64-linux-gnu/libuuid.so.1 
(0x7f30490c8000=
)
/lib64/ld-linux-x86-64.so.2 (0x55e066e92000)

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

Kernel: Linux 4.5.0-00038-gafaea24 (SMP w/4 CPU cores)
Locale: LANG=3Dde_DE, LC_CTYPE=3Dde_DE (charmap=3DISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages aptitude depends on:
ii  aptitude-common0.7.8-1
ii  libapt-pkg5.0  1.2.6
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5+b1
ii  libboost-iostreams1.58.0   1.58.0+dfsg-5+b1
ii  libboost-system1.58.0  1.58.0+dfsg-5+b1
ii  libc6  2.22-3
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:5.3.1-11
ii  libncursesw5   6.0+20160213-1
ii  libsigc++-2.0-0v5  2.6.2-1
ii  libsqlite3-0   3.11.1-1
ii  libstdc++6 5.3.1-11
ii  libtinfo5  6.0+20160213-1
ii  libxapian22v5  1.2.22-3

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.7.5-3
ii  libparse-debianchangelog-perl   1.2.0-8
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index  
pn  debtags   
pn  tasksel   

-- no debconf information

Bug#814456: RFS: libpam-ufpidentity/1.0-1 [ITP] -- UFP Identity PAM Module

[Richard Levenberg]

The test credentials (example.com) are provided to allow for testing
with the services without having to register. The test credentials only
allow a username 'guest.' The test credentials are only used in the main
method which is only enabled in the static compilation when PIC is NOT
enabled. The main method is not compiled into the library.

The remote service requires registration of a client key/CSR which is
described here:

https://www.ufp.com/identity/integration.html#getting_started

Then send the CSR to i...@ufp.com.

Did you do that?

On 3/21/16 10:45 AM, Gianfranco Costamagna wrote:
> Hi, some questions about the identity4c package:
> why there is an example.com hardcoded in the sources?
> I see also some pem certificates provided here.
> 
> 
> how does it interface with the libpam-ufpidentity?
> I guess in no ways, because it is in the main, right?
> 
> second question: is the remote pam service something under a fee?
> I tried to register on ufp.com or whatever was written on readme, but I got 
> no confirmation email.
> 

Bug#818918: seqprep: missing test dependency: python

[Steve Langasek]

Package: seqprep
Version: 1.1-4
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

The seqprep package has a test-time dependency on /usr/bin/python; but
neither the seqprep binary package nor debian/tests/control declares the
dependency on it.

The attached short patch adds python to debian/tests/control, so that the
package is testable in environments where python is not pre-installed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru seqprep-1.1/debian/tests/control seqprep-1.1/debian/tests/control
--- seqprep-1.1/debian/tests/control	2015-01-19 06:22:46.0 -0800
+++ seqprep-1.1/debian/tests/control	2016-03-21 11:15:50.0 -0700
@@ -1,3 +1,3 @@
 Tests: run-unit-test
-Depends: @
+Depends: @, python
 Restrictions: allow-stderr

Bug#818929: ethstatus: Some (imho) improvements

[Sven-Haegar Koch]

Package: ethstatus
Version: 0.4.5
Severity: wishlist
Tags: patch

Dear Maintainer,

I am using ethtool since years, but a slightly modified version - with the
latest update to Debian Unstable I was reminded what the original is
missing, and thought that I should submit my changes.

1.
Allow longer network interface names (bug #803663):

diff -ur ethstatus-0.4.5/ethstatus.c ethstatus-0.4.5+sdinetH1/ethstatus.c
--- ethstatus-0.4.5/ethstatus.c 2006-10-20 00:09:56.0 +0200
+++ ethstatus-0.4.5+sdinetH1/ethstatus.c2016-03-21 20:16:05.983431525 
+0100
@@ -636,7 +644,7 @@
break;
 
case 'i':
-   if(strlen(optarg) > 5)
+   if(strlen(optarg) > IFNAMSIZ)
{
show_usage(argv[0]);
exit(10);


2.
ethstatus needs a huge amount of CPU, and especially required lots of
bandwidth when used over ssh - restrict the screen updates to every
1/2 second:

diff -ur ethstatus-0.4.5/ethstatus.c ethstatus-0.4.5+sdinetH1/ethstatus.c
--- ethstatus-0.4.5/ethstatus.c 2006-10-20 00:09:56.0 +0200
+++ ethstatus-0.4.5+sdinetH1/ethstatus.c2016-03-21 20:16:05.983431525 
+0100
@@ -813,10 +821,10 @@
  update_stat(0);
  sec_value = localt.tm_sec;
   }
-usleep(10L); 
+usleep(50L);
   }
   else
-   usleep(10L);
+sleep(1);
   
   key_pressed = getch();
   if(key_pressed != ERR && tolower(key_pressed) == 'q')


3.
Show the currently used RX and TX bandwidth separately, not only the
summary:

diff -ur ethstatus-0.4.5/ethstatus.c ethstatus-0.4.5+sdinetH1/ethstatus.c
--- ethstatus-0.4.5/ethstatus.c 2006-10-20 00:09:56.0 +0200
+++ ethstatus-0.4.5+sdinetH1/ethstatus.c2016-03-21 20:16:05.983431525 
+0100
@@ -76,7 +76,7 @@
if(display)
  {
chcolor(colors.data[0], colors.data[1]);
-   mvprintw(17, 27, "%s", stats.ip_addr_rtrn);
+   mvprintw(18, 27, "%s", stats.ip_addr_rtrn);
refresh();
  }
 }
@@ -107,16 +107,16 @@
  stats.email++; 
 }
   if(stats.email < 10)
-mvprintw(17, 65, "0%d ", stats.email);
+mvprintw(18, 65, "0%d ", stats.email);
   else
-mvprintw(17, 65, "%d   ", stats.email);
+mvprintw(18, 65, "%d   ", stats.email);
   fclose(email_box);
}
   else
-   mvprintw(17, 65, "Can't check");
+   mvprintw(18, 65, "Can't check");
}
else
- mvprintw(17, 65, "00 ");
+ mvprintw(18, 65, "00 ");
refresh();
 }
 
@@ -216,23 +216,23 @@
 void update_info(void)
 {
chcolor(colors.data[0] ,colors.data[1]);
-   mvprintw(20, 27, "%.0f", stats.rx_packets[0]);
-   mvprintw(20, 65, "%.0f", stats.tx_packets[0]);
-   mvprintw(22, 27, "%ld", stats.rx_errors[0]);
-   mvprintw(22, 65, "%ld", stats.tx_errors[0]);
+   mvprintw(21, 27, "%.0f", stats.rx_packets[0]);
+   mvprintw(21, 65, "%.0f", stats.tx_packets[0]);
+   mvprintw(23, 27, "%ld", stats.rx_errors[0]);
+   mvprintw(23, 65, "%ld", stats.tx_errors[0]);
 
/* Calculate the measures automagically */
chcolor(colors.labels[0], colors.labels[1]);
autoscale(autoscalebytes, stats.rx_bytes[0]);
-   mvprintw(21, 6, "Received:");
+   mvprintw(22, 6, "Received:");
chcolor(colors.data[0], colors.data[1]);
-   mvprintw(21, 27, "%sB", autoscalebytes);
+   mvprintw(22, 27, "%sB", autoscalebytes);
 
chcolor(colors.labels[0], colors.labels[1]);
autoscale(autoscalebytes, stats.tx_bytes[0]);
-   mvprintw(21,41, "Transmitted:");
+   mvprintw(22,41, "Transmitted:");
chcolor(colors.data[0], colors.data[1]);
-   mvprintw(21, 65, "%sB", autoscalebytes);
+   mvprintw(22, 65, "%sB", autoscalebytes);
 }
 
 /*-*
@@ -241,16 +241,16 @@
 void clear_info(void)
 {
chcolor(colors.background ,0);
-   mvprintw(19, 65, "   ");
-   mvprintw(19, 27, "");
+   mvprintw(20, 65, "   ");
mvprintw(20, 27, "");
-   mvprintw(20, 65, "  ");
-   mvprintw(22, 27, "");
-   mvprintw(22, 65, "  ");
mvprintw(21, 27, "");
mvprintw(21, 65, "  ");
-   mvprintw(16, 22, "   ");
-   mvprintw(17, 27, "");
+   mvprintw(23, 27, "");
+   mvprintw(23, 65, "  ");
+   mvprintw(22, 27, "");
+   mvprintw(22, 65, "  ");
+   mvprintw(17, 22, "   ");
+   mvprintw(18, 27, "");
 }
 
 
@@ -391,27 +391,35 @@
pps[1] = (stats.tx_packets[0] - stats.tx_packets_comp[1]);

/* ks variable 

Bug#818873: gcc-5-cross: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Matthias Klose]

Control: tags -1 + help

On 21.03.2016 10:02, Santiago Vila wrote:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


A patch would be welcome.

Bug#815838: linux-image-3.16.0-4-amd64: Boot randomly fails with "Initramfs unpacking failed"

[Blake Miner]

This problem is also confirmed using Debian Linux
kernel 3.16.7-ckt20-1+deb8u4.

Any thoughts on how to fix?  Again, this only occurs about 10% of the time
on boot ups, sometimes less frequently depending on which PC I am using.

For now, as a workaround, I am using the "panic" kernel parameter to
trigger an automatic reboot when this problem occurs.
-- 
Blake Miner
miner.bl...@gmail.com

Bug#818930: knot-resolver: trust_anchors.config does not check its argument

[Stephane Bortzmeyer]

Package: knot-resolver
Version: 1.0.0~beta3-1
Severity: normal

Dear Maintainer,

When calling:

trust_anchors.config('/etc/knot-resolver/yeti-root.key')

I discovered that Knot does not check that the file exists. If it
doesn't, there is no error and no warning, but Knot falls back to a
root anchor bootstrapped

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

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

Versions of packages knot-resolver depends on:
ii  dns-root-data2015052300+h+1
ii  init-system-helpers  1.29
ii  libc62.22-3
ii  libdnssec0   2.1.1-1
ii  libgeoip11.6.9-1
ii  libhiredis0.13   0.13.3-2
ii  libjs-d3 3.5.16-1
ii  libjs-jquery 1.11.3+dfsg-4
ii  libknot1 2.1.1-1
ii  libluajit-5.1-2  2.0.4+dfsg-1
ii  libmemcached11   1.0.18-4.1
ii  libmemcachedutil21.0.18-4.1
ii  libuv1   1.8.0-1
ii  libzscanner0 2.1.1-1
ii  lua-sec  0.5.1-1
ii  lua-socket   3.0~rc1+git+321c0c9-1

knot-resolver recommends no packages.

knot-resolver suggests no packages.

-- Configuration Files:
/etc/knot-resolver/kresd.conf changed [not included]

-- no debconf information

Bug#818931: ejabberd: mod_shared_roster_ldap stopped working in 16.02

[Dominik George]

Package: ejabberd
Version: 16.02-2~bpo8+1
Severity: important
Tags: upstream

mod_shared_roster_ldap stopped working in 16.02.

It errors out with:

<0.419.0>@ejabberd_hooks:run_fold1:368 
{{case_clause,false},[{mod_shared_roster_ldap,'-get_user_roster/2-fun-0-',2,[{file,"src/mod_shared_roster_ldap.erl"},{line,144}]},{lists,mapfoldl,3,[{file,"lists.erl"},{line,1353}]},{mod_shared_roster_ldap,get_user_roster,2,[{file,"src/mod_shared_roster_ldap.erl"},{line,140}]},{ejabberd_hooks,safe_apply,3,[{file,"src/ejabberd_hooks.erl"},{line,382}]},{ejabberd_hooks,run_fold1,4,[{file,"src/ejabberd_hooks.erl"},{line,365}]},{mod_roster,process_iq_get,3,[{file,"src/mod_roster.erl"},{line,302}]},{gen_iq_handler,process_iq,6,[{file,"src/gen_iq_handler.erl"},{line,128}]},{gen_iq_handler,handle_info,2,[{file,"src/gen_iq_handler.erl"},{line,172}]}]}

The problem seems to be documented in EJAB-1480 and was allegedly fixed
here:
https://github.com/processone/ejabberd/commit/4013629e5deecf3336b6ae97bf769852dc29c40e

However, this patch did not fix it for me. The error vanished, but the
roster didn't show up.

Blindly copying back mod_shared_roster_ldap.beam from 16.01 served as a
workaround.

-- System Information:
Debian Release: 8.3
  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=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ejabberd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  erlang-asn11:18.0-dfsg-1
ii  erlang-base [erlang-abi-17.0]  1:18.0-dfsg-1
ii  erlang-crypto  1:18.0-dfsg-1
ii  erlang-inets   1:18.0-dfsg-1
ii  erlang-lager   2.0.3-1
ii  erlang-mnesia  1:18.0-dfsg-1
ii  erlang-odbc1:18.0-dfsg-1
ii  erlang-p1-cache-tab1.0.2-2~bpo8+1
ii  erlang-p1-iconv1.0.0-1~bpo8+1
ii  erlang-p1-stringprep   1.0.2-2~bpo8+1
ii  erlang-p1-tls  1.0.1-1~bpo8+1
ii  erlang-p1-utils1.0.3-2~bpo8+1
ii  erlang-p1-xml  1.1.3-1~bpo8+1
ii  erlang-p1-yaml 1.0.2-1~bpo8+1
ii  erlang-p1-zlib 1.0.1-1~bpo8+1
ii  erlang-public-key  1:18.0-dfsg-1
ii  erlang-ssl 1:18.0-dfsg-1
ii  erlang-syntax-tools1:18.0-dfsg-1
ii  erlang-xmerl   1:18.0-dfsg-1
ii  init-system-helpers1.22
ii  openssl1.0.1k-3+deb8u4
ii  ucf3.0030

ejabberd recommends no packages.

Versions of packages ejabberd suggests:
pn  apparmor 
pn  apparmor-utils   
ii  ejabberd-contrib 0.2016.03.02~dfsg0-1~bpo8+1
pn  erlang-luerl 
ii  erlang-oauth20.2015.09.28-1~bpo8+1
ii  erlang-p1-mysql  1.0.1-1~bpo8+1
ii  erlang-p1-pam1.0.0-2~bpo8+1
ii  erlang-p1-pgsql  1.0.1-1~bpo8+1
ii  erlang-p1-sip1.0.2-1~bpo8+1
ii  erlang-p1-stun   1.0.1-1~bpo8+1
ii  erlang-redis-client  1.0.8-1
ii  erlang-sqlite3   1.1.4~dfsg0-1~bpo8+1
ii  imagemagick  8:6.8.9.9-5
ii  libunix-syslog-perl  1.1-2+b4

-- Configuration Files:
/etc/ejabberd/inetrc [Errno 13] Keine Berechtigung: u'/etc/ejabberd/inetrc'
/etc/ejabberd/modules.d/README.modules [Errno 13] Keine Berechtigung: 
u'/etc/ejabberd/modules.d/README.modules'

-- debconf information excluded

Bug#818873: gcc-5-cross: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

On Mon, Mar 21, 2016 at 08:56:27PM +0100, Matthias Klose wrote:
> Control: tags -1 + help
> 
> On 21.03.2016 10:02, Santiago Vila wrote:
> >I tried to build this package with "dpkg-buildpackage -A"
> >(i.e. only architecture-independent packages), and it failed:
> 
> A patch would be welcome.

I don't have a patch, but in case it helps: This bug was introduced
somewhere between version 12 and 20, i.e. version 12 was ok,
version 20 (this report) is not anymore.

Bug#818932: [gnome-online-accounts] Can't add new online accounts

[David Glover-Aoki]

Package: gnome-online-accounts
Version: 3.18.4-1
Severity: serious

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

The "+" and "Add an online account" buttons are always greyed out, so
it is currently impossible to add new online accounts in GNOME.

# dpkg-query -f '${binary:Package}\n' -W | grep telepathy
gir1.2-telepathyglib-0.12
gir1.2-telepathylogger-0.2
libfolks-telepathy25:amd64
libtelepathy-farstream3:amd64
libtelepathy-glib0:amd64
libtelepathy-logger3:amd64
telepathy-accounts-signon
telepathy-gabble
telepathy-haze
telepathy-idle
telepathy-logger
telepathy-mission-control-5
telepathy-rakia
telepathy-salut
telepathy-sofiasip
telepathy-specification

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

Debian Release: stretch/sid
  500 testing-updates ftp.us.debian.org 
  500 testing security.debian.org 
  500 testing ftp.us.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#818876: follow up, kfreebsd

[contact smxi]

I remembered my kfreebsd vm password, this is inxi 2.2.35, but there's no real difference here in 
output from the debian pool version:


inxi -Sx

System: Host: deb-kfreebsd Kernel 8.1-1-amd64 x86_64 (64 bit gcc: 4.3.5))
Console: tty 0 OS: GNU/KFreeBSD 8.1-1-amd64

Note it's an older kfreebsd install, don't remember the date, 2 years ago maybe?

I know, I know, actually testing/validating an issue, a wild concept, really extreme, but there you 
have it, call me old school.


For the record, I ran an inxi -v7 on the kfreebsd vm, and at least on this kfreebsd version, it's 
all groovy.


Upgrade of this kfreebsd failed, so can't test on current release, no big deal.

Harald Hope, inxi primary author/developer.

Bug#818921: RFS: python-neovim-gui/0.1.1-1 [ITP]

[Víctor Cuadrado Juan]

I messed up and used Cc instead of X-Debbugs-Cc, please remove
the Cc if answering to this e-mail. Sorry for the noise.

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.

Bug#818924: Pending fixes for bugs in the libjson-webtoken-perl package

[pkg-perl-maintainers]

tag 818924 + pending
thanks

Some bugs in the libjson-webtoken-perl package are closed in revision
b3ba617f53844ea7910ed41d9f1f0bd6a77fae56 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libjson-webtoken-perl.git/commit/?id=b3ba617

Commit message:

Add (build) dependency on libmodule-runtime-perl.

Closes: #818924

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[adrian15]

This is my updated set of patches.

Changes since last set of patches:

* Renamed primary and secondary to first and extra terms.
* Forced insmod all_video command in grub.cfg to avoid problems in UEFI 
mode.

* Minor changes

Rescatux 0.40b6 which I will release soon will feature this branch which 
include these changes:


https://github.com/rescatux/live-build/tree/rescatux-0.40b6

.

The branch which include specifically the commits I attach here as 
patches is:


https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5

.

About the variable names issue: I think the new terms: first and extra 
are ok because they are not implying some sort of rank while explaining 
what's the difference between them. Also, notice, that these are 
internal variables which final user of live-build does not see. I think 
we should focus on other aspects of my patch if there are more problems 
for it.


If you think that the way bootloaders is currently managed by live-build 
is wrong please file up a new bug and send there your patch with your 
improvements so that it's get discussed.


Then, if it gets approved I can improve my patch over yours.

My patch tries to make the minimum improvements so that other live-build 
functionality does not get affected by it.


Let's please focus on getting this set of patches accepted. Don't get me 
wrong I'm not asking for a carte blanche but, let's focus on other 
aspects from the patch. (E.g. please test it on actual hardware, in your 
distro builds, even if you don't use UEFI does the ISO boot as always in 
BIOS mode?) And give us feedback on it.


Thank you.

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>From ff8206aea1985760dfea9ec94b93686a242f137e Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Mon, 18 Jan 2016 03:04:00 +
Subject: [PATCH 01/10] functions/default.sh : Define LB_PRIMARY_BOOTLOADER at
 the Set_defaults function which it's the right place where to do it

---
 functions/defaults.sh | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/functions/defaults.sh b/functions/defaults.sh
index ddf4b19..334984f 100755
--- a/functions/defaults.sh
+++ b/functions/defaults.sh
@@ -537,6 +537,8 @@ Set_defaults ()
 		esac
 	fi
 
+	LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }')
+
 	# Setting checksums
 	case "${LB_MODE}" in
 		progress-linux)
@@ -845,9 +847,6 @@ Check_defaults ()
 		fi
 	fi
 
-
-	LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }')
-
 	if [ "${LB_PRIMARY_BOOTLOADER}" = "syslinux" ]
 	then
 		# syslinux + fat or ntfs, or extlinux + ext[234] or btrfs
-- 
2.1.4

>From f895f653dffb614639fa37a318e62c51104a4b2d Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Wed, 20 Jan 2016 00:53:53 +0100
Subject: [PATCH 02/10] Remove repeated LB_PRIMARY_BOOTLOADER definition

---
 scripts/build/binary_hdd | 2 --
 scripts/build/binary_iso | 2 --
 2 files changed, 4 deletions(-)

diff --git a/scripts/build/binary_hdd b/scripts/build/binary_hdd
index d0db382..0c9c5af 100755
--- a/scripts/build/binary_hdd
+++ b/scripts/build/binary_hdd
@@ -67,8 +67,6 @@ do
 	esac
 done
 
-LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }')
-
 case ${LB_PRIMARY_BOOTLOADER} in
 		syslinux)
 			case ${LB_BINARY_FILESYSTEM} in
diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso
index d8b1553..67dfc85 100755
--- a/scripts/build/binary_iso
+++ b/scripts/build/binary_iso
@@ -107,8 +107,6 @@ then
 	XORRISO_OPTIONS="${XORRISO_OPTIONS} -V \"${LB_ISO_VOLUME}\""
 fi
 
-LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }')
-
 # Handle xorriso architecture specific options
 case "${LB_PRIMARY_BOOTLOADER}" in
 	grub)
-- 
2.1.4

>From 9175a624b7d88bfea80448a5a1e6ac1b11d651aa Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Mon, 18 Jan 2016 03:07:48 +
Subject: [PATCH 03/10] * Added: functions/bootloaders.sh . It has new
 bootloader functions that are heavily used in efi scenarios where a
 bootloader can act as a primary or a secondary bootloader.

Since the introduction of the new switch:

--bootloaders

you can setup it like this:

--bootloaders=syslinux,grub-efi

.

This means that syslinux is the primary bootloader and grub-efi is the secondary bootloader.

* Added new bootloader functions: Check_Non_Primary_Bootloader and Check_Non_Secondary_Bootloader.

These functions let each one of the bootloaders abort the build because
they cannot perform a role either as a primary bootloader or as a secondary bootloader.

* Added bootloader functions: Check_Primary_Bootloader_Role, Check_Secondary_Bootloader_Role and Check_Any_Bootloader_Role

These functions let bootloaders to force their default role in a single line.
---
 functions/bootloaders.sh | 

Bug#818872: gcc-5-cross-ports: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

On Mon, Mar 21, 2016 at 09:02:48AM +, Santiago Vila wrote:
> Package: src:gcc-5-cross-ports
> Version: 7

For the record: Version 3 was ok (in case it helps).

[ I usually build every version as they reach testing, but this package
  was excluded on purpose because it was too big. I have now a bigger
  machine and will try to build everything no matter the size ].

Bug#815838: linux-image-3.16.0-4-amd64: Boot randomly fails with "Initramfs unpacking failed"

[Blake Miner]

I should also mention that this problem seems to be occurring for the 16 GB
SanDisk USB disks, as well (part SDCZ33-016G-B35)... just appears to be
slightly more rare.
-- 
Blake Miner
miner.bl...@gmail.com

Bug#783670: www.debian.org: Update w.d.o/misc/children-distros web page

[Caleb Webber]

I've been updating the info on the children-distros.wml. However, I just
came across previous entries for this bug report. Would it be better to
migrate to the wiki page or should I continue updating the wml?

Bug#818597: libcpprest2.7: libcpprest.so.2.7 not installed

[Daniele Scasciafratte]

any news for that fix?

Bug#818921: RFS: python-neovim-gui/0.1.1-1 [ITP]

[Víctor Cuadrado Juan]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-neovim-gui"

* Package name: python-neovim-gui
  Version : 0.1.1
  Upstream Author : Thiago de Arruda 
* URL : https://github.com/neovim/python-gui
* License : Apache 2.0
  Section : editors
  Description : Simple nvim gui implemented using Gtk

It builds this binary package:
   python3-neovim-gui - Simple nvim gui implemented using Gtk (Python 3)

I intend to maintain it under the DPMT umbrella, which I am part of.

To access further information about this package, please visit the following 
URL:
   https://anonscm.debian.org/cgit/python-modules/packages/python-neovim-gui.git


Regards,


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


signature.asc
Description: PGP signature

Bug#803663: ethstatus: cannot use interface name with a length greather than 5

[Sven-Haegar Koch]

Hallo,

The following patch should fix this:

(I had the exact same problems with the OpenVPN interface names in use 
here, for example vhamburg for a link to hamburg)

diff -ur ethstatus-0.4.5/ethstatus.c ethstatus-0.4.5+sdinetH1/ethstatus.c
--- ethstatus-0.4.5/ethstatus.c 2006-10-20 00:09:56.0 +0200
+++ ethstatus-0.4.5+sdinetH1/ethstatus.c2016-03-21 20:16:05.983431525 
+0100
@@ -636,7 +644,7 @@
break;
 
case 'i':
-   if(strlen(optarg) > 5)
+   if(strlen(optarg) > IFNAMSIZ)
{
show_usage(argv[0]);
exit(10);

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.

Bug#818928: terminology: fails to start terminology

[Denys]

Package: terminology
Version: 0.7.0-1
Severity: important

Dear Maintainer, terminology fails to start on debian sid.

ERR<8080>:terminology main.c:3001 elm_main() Could not initialize key bindings.
ERR<8080>:efreet_cache lib/efreet/efreet_cache.c:1108 on_send_register()
org.enlightenment.DBus.Canceled Canceled by user.
CRI: lib/eet/eet_lib.c:626 eet_shutdown() eina_log_print() unknown domain -1,
original message format 'Init count not greater than 0 in shutdown.'



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

Versions of packages terminology depends on:
ii  libc6 2.22-3
ii  libecore-con1 1.8.6-2.5
ii  libecore-evas11.8.6-2.5
ii  libecore-file11.8.6-2.5
ii  libecore-imf1 1.8.6-2.5
ii  libecore-input1   1.8.6-2.5
ii  libecore-ipc1 1.8.6-2.5
ii  libecore1 1.8.6-2.5
ii  libedje1  1.8.6-2.5
ii  libeet1   1.8.6-2.5
ii  libefreet-bin 1.8.6-2.5
ii  libefreet1a   1.8.6-2.5
ii  libeina1  1.8.6-2.5
ii  libeio1   1.8.6-2.5
ii  libelementary21.8.5-2
ii  libemotion1   1.8.6-2.5
ii  libethumb-client-bin  1.8.6-2.5
ii  libethumb-client1 1.8.6-2.5
ii  libevas1  1.8.6-2.5
ii  libevas1-engines-x1.8.6-2.5
ii  liblz4-1  0.0~r131-2
ii  terminology-data  0.7.0-1

terminology recommends no packages.

Versions of packages terminology suggests:
pn  libelementary-bin  

-- no debconf information

Bug#818187: zeromq3 migrated without any transition being done

[Luca Boccassi]

On Tue, 15 Mar 2016 10:26:15 +0100 Emilio Pozuelo Monfort  
wrote:
> On 14/03/16 22:03, Emilio Pozuelo Monfort wrote:
> > On 14/03/16 21:55, László Böszörményi (GCS) wrote:
> >> On Mon, Mar 14, 2016 at 8:58 PM, Emilio Pozuelo Monfort
> >>  wrote:
> >>> Renaming a -dev package because the soname changed is bad. The only reason
> >>> to do it in this case is so that things don't look "odd".
> >>   The main reason the soname is in the -dev package name is that the
> >> simple 'libzmq-dev' is part of the zeromq package. But yes, it could
> >> have remain as libzmq3-dev even if it looks inconsistent with libzm5.
> >  >
> >>> What I think should happen here is:
> >>>
> >>> The package is renamed back to libzmq3-dev, so rdeps can be binNMUed.
> >>>
> >>> A provides can be added for the packages that changed, since their
> >>> build-deps are not versioned. After libzmq5-dev is decrufted, they will be
> >>> fine.
> >>>
> >>> Then the transition can complete.
> >>>
> >>> How does that sound?
> >>   I see and agree. Attached the next upload just to be sure. Please ACK
> >> it and I'll upload it.
> >>
> >> Sorry for the extra round,
> >
> > Looks good. No problem and thanks for reacting that fast!
> 
> I scheduled the binNMUs last night and things are going well. The only issue 
> seems to be pyzmq, see #818265.

Hi,

I am the maintainer of libczmq, a dependent of libzmq.

I have bumped the build-dep to libzmq5-dev after being asked (#815784).

The library and its dependents build fine, and it has migrated to testing.

Given the change of the -dev package name here, should I roll back and b-d 
again on libzmq3-dev? I don't mind doing another upload if it's the right thing.

Thank you!

Kind regards,
Luca Boccassi


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

Bug#818923: kde-l10n-de: Wrong Translation in Softwareverwaltung

[J. S.]

Package: kde-l10n-de
Version: 4:4.14.0-1
Severity: normal
Tags: l10n

Dear Maintainer,

im using Debian 8.3 kde, kde-l10n-de (4:4.14.0-1). In Softwareveraltung ->
einstellungen -> software quellen -> Quellen bearbeiten are three translations
wrong. You can see it in the Appix (picture).



-- System Information:
Debian Release: 8.3
  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=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kde-l10n-de depends on:
ii  libkdecore5  4:4.14.2-5

kde-l10n-de recommends no packages.

Versions of packages kde-l10n-de suggests:
ii  kde-standard  5:84

-- no debconf information

Bug#818837: nmu: libdbi-drivers_0.9.0-3

[Julien Cristau]

Control: tag -1 moreinfo

On Sun, Mar 20, 2016 at 21:35:43 +0100, Ruben Undheim wrote:

> There are some memory issues when running the test suite for the package
> openbsc. These disappears if libdbi-drivers is first rebuilt with GCC 5. It is
> hard to track down exactly what the problem is, but rebuilding it seems to 
> make
> the test suite pass for openbsc..
> 
We (well, at least I) don't like to schedule binNMUs without knowing why.

Cheers,
Julien

Bug#818922: Please explain firefox v. firefox-esr in package long description

[Anthony DeRobertis]

Package: firefox-esr
Version: 45.0esr-2
Severity: wishlist

It'd be nice if the package long description explained the difference
between firefox and firefox-esr. I don't think the average user should
be assumed to know what ESR is.

I believe the plan is to only have ESR in stable.

Maybe something along the lines of:

This is the Extended Support Release (ESR). It receives security and
major bug fixes, but not new features. The most recent non-ESR
release is available in the firefox package; see README.Debian for
instructions.

and

This is the most recent release of Firefox. The Extended Support
Release, which receives only security and major bug fixes but not
new features, is availabe in the firefox-esr package.

obviously, README.Debian would need to gain a paragraph explaining that
stable users can get the firefox package by visiting
http://mozilla.debian.net/ and following the instructions there.
(Alternatively, I guess that could go in the description).

Bug#814165: jcc: diff for NMU version 2.21-1.1

[Markus Koschany]

Dear maintainer,

I've prepared an NMU for jcc (versioned as 2.21-1.1) and
uploaded it to unstable. Please find attached the debdiff.

Regards,

Markus
diff -Nru jcc-2.21/debian/changelog jcc-2.21/debian/changelog
--- jcc-2.21/debian/changelog	2015-09-21 00:31:09.0 +0200
+++ jcc-2.21/debian/changelog	2016-03-21 20:02:27.0 +0100
@@ -1,3 +1,19 @@
+jcc (2.21-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/rules: Fix build on ppc64el by changing JAVAARCH variable to ppc64le.
+Thanks to Fernando Seiti Furusato for the report and patch.
+(Closes: #799713)
+  * Build-depend on default-jdk instead of openjdk-7-jdk.
+Depend on default-jdk | java7-sdk for jcc binary package.
+Thanks to Matthias Klose for the report. (Closes: #814165)
+  * d/rules: Use default-java instead of a specific JDK version.
+  * d/control: Use https and cgit.
+  * Ensure that the package can be built twice in a row by removing
+JCC.egg-info/SOURCES.txt in dh_auto_clean override too.
+
+ -- Markus Koschany   Mon, 21 Mar 2016 19:53:15 +0100
+
 jcc (2.21-1) unstable; urgency=low
 
   [ Fernando Seiti Furusato ]
diff -Nru jcc-2.21/debian/control jcc-2.21/debian/control
--- jcc-2.21/debian/control	2014-09-21 21:48:55.0 +0200
+++ jcc-2.21/debian/control	2016-03-21 20:02:27.0 +0100
@@ -3,16 +3,16 @@
 Priority: extra
 Maintainer: Ludovico Cavedon 
 Build-Depends: debhelper (>= 9), python-setuptools (>= 0.6a9),
-  openjdk-7-jdk, python-all-dev
+  default-jdk, python-all-dev
 Standards-Version: 3.9.6
 Homepage: http://lucene.apache.org/pylucene/jcc/
-Vcs-Git: git://anonscm.debian.org/collab-maint/jcc.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/jcc.git
+Vcs-Git: https://anonscm.debian.org/git/collab-maint/jcc.git
+Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/jcc.git
 X-Python-Version: >= 2.3
 
 Package: jcc
 Architecture: any
-Depends: openjdk-7-jdk, ${shlibs:Depends}, ${python:Depends},
+Depends: default-jdk | java7-sdk, ${shlibs:Depends}, ${python:Depends},
  ${misc:Depends}
 Breaks: ${python:Breaks}
 Description: code generator producing a Python extension from Java classes
diff -Nru jcc-2.21/debian/rules jcc-2.21/debian/rules
--- jcc-2.21/debian/rules	2014-09-21 21:27:42.0 +0200
+++ jcc-2.21/debian/rules	2016-03-21 20:02:27.0 +0100
@@ -18,16 +18,16 @@
 endif
 
 ifeq ($(DEB_HOST_ARCH_CPU),ppc64el)
-  JAVAARCH :=ppc64
+  JAVAARCH :=ppc64le
 endif
 
-JAVA_LIB_PATH := /usr/lib/jvm/java-7-openjdk-$(DEB_HOST_ARCH)/jre/lib/$(JAVAARCH)
+JAVA_LIB_PATH := /usr/lib/jvm/default-java/jre/lib/$(JAVAARCH)
 
 export JCC_ARGSEP=;
 export JCC_LFLAGS := -L$(JAVA_LIB_PATH);-ljava;-L$(JAVA_LIB_PATH)/server;-ljvm;-Wl,-rpath=$(JAVA_LIB_PATH):$(JAVA_LIB_PATH)/server
 
 export JCC_CFLAGS := -fdollars-in-identifiers
-export JCC_JDK := /usr/lib/jvm/java-7-openjdk-$(DEB_HOST_ARCH)
+export JCC_JDK := /usr/lib/jvm/default-java
 
 # For shared mode we need patch http://bugs.python.org/setuptools/issue43 for setuptools to be applied
 export NO_SHARED=1
@@ -43,3 +43,4 @@
 	dh_auto_clean
 	rm -rf build/*
 	rm -f jcc/config.py
+	$(RM) JCC.egg-info/SOURCES.txt

Bug#818925: [wine-development] Glitches in Windows window systemmenu (minimize, windowed/fullscreen, close)

[Joerg Schiermeier, Bielefeld/Germany]

Package: wine-development
Version: 1.9.6-1
Severity: normal

Hello!
I got glitches e.g. strange symboles instead ot the symbols for minimize, 
windowed or maximized and close. See attachment/note.
This was tested also against the original compiled source code from winehq.org. 
There was no error. So I suspect one of the patches here for the last version 
of wine-development.

Thanks a lot!

-- 
Yours sincerely
Joerg Schiermeier

-- System Information:
LSB Version:
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: SolydXK
Description:SolydK 8 64-bit
Release:8
Codename:   solydxk
Architecture: x86_64

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

Versions of packages wine-development depends on:
ii  wine32-development  1.9.6-1
ii  wine64-development  1.9.6-1

wine-development recommends no packages.

Versions of packages wine-development suggests:
ii  dosbox   0.74-4
ii  playonlinux  4.2.10-1
pn  wine-binfmt  
ii  winetricks   0.0+20151116-1

Versions of packages wine-development is related to:
ii  fonts-wine  1.8.1-2
ii  wine-development1.9.6-1
ii  wine32-development  1.9.6-1
ii  wine64-development  1.9.6-1

-- no debconf information

Bug#818924: libjson-webtoken-perl: missing dependency on libmodule-runtime-perl

[Niko Tyni]

Package: libjson-webtoken-perl
Version: 0.10-1 
Severity: serious
User: debian-p...@lists.debian.org
Usertags: autopkgtest

This package is missing a runtime dependency on libmodule-runtime-perl.

 https://ci.debian.net/packages/libj/libjson-webtoken-perl/unstable/amd64/


#   Failed test '/usr/bin/perl -w -M"JSON::WebToken" -e 1 2>&1 exited 
successfully'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 74.

#   Failed test '/usr/bin/perl -w -M"JSON::WebToken" -e 1 2>&1 produced no 
output'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 75.
# Looks like you failed 2 tests of 2.
/usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 
1..2
# Can't locate Module/Runtime.pm in @INC (you may need to install the 
Module::Runtime module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 
/usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at 
/usr/share/perl5/JSON/WebToken.pm line 14.
# BEGIN failed--compilation aborted at /usr/share/perl5/JSON/WebToken.pm line 
14.

-- 
Niko Tyni   nt...@debian.org

Bug#818926: perl6-panda: panda doesn't start up / find needed libraries

[gregor herrmann]

Package: perl6-panda
Version: 2016.02-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

panda simply doesn't work:

% panda --help
===SORRY!===
Could not find Shell::Command in:
/home/gregoa/.perl6/2016.02
/usr/share/perl6/site
/usr/share/perl6/vendor
/usr/share/perl6
CompUnit::Repository::AbsolutePath<139839414999752>
CompUnit::Repository::NQP<139839414997224>
CompUnit::Repository::Perl5<139839414994856>


% PERL6LIB=/usr/share/perl6/lib panda --help
===SORRY!=== 
Failed to create directory '/usr/share/perl6/lib/.precomp' with mode '0o777': 
Failed to mkdir: 13



No material for testing yet :)


Cheers,
gregor

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJW8EnAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoG9HsP+wamdKSxAsHP/GUcjIQ8rCtX
E+1HF5rxgZ82BDmSHhD4TIY9KbQ45Tv8957+vjsyzJpBKqUspQBTqMJCbdWRtnE9
VhCKMgwoiF4A982fdXQ0kEr5xvIDN5Um05zKTz2g/w61AzS/aEke0+HqdLbmlU+5
NyVQGEMok5E248+UREi3ZJzwsXdra0+Kmf+avKBv6VjQ0WhtsmIbukOpjNpbuWff
sKfMPkvfIcmMsm/K9qP9KvhgAoVOUrHKaR0NLVwA80+yEXbreIMtIISHUgYtSnbf
PXZdWA11d+QxDJuoPIlYzK2OOhE4OtOr8+DLD0r4abwhvQm5DleahJ7AxRZalLim
uJe2YRjxy0CWu+3KMWYUj5HPIdqaBRJjWhYot5JX6tqpezoM94r8tX1rt4eIxG0t
AvxhWraZmQxmRCkTCrW3Djrt93mB3G3s80agT7g5ZU3olHf5oa71RepPtjBwz6+x
y2dvJYMn+6oDUce5H/CCSKdXDR7lKZV0H5bU0O9btOANexjxhFV509De3QTgs/+a
0r7bRn1hFJb1qL7+dUO799RpmmCb9idw9Rv+zTUPvlteo3qm1SoK9wwC4hDhx4EN
QNGtNnIrWv8gMwj6AoJwTvxJ7rj1BUfPfxEt47ZX8wd1zAZ4MQRSiaV/lVW4p55k
piLYoF0RcxSWp3RIxb0u
=uQUt
-END PGP SIGNATURE-

Bug#818927: Fw: broken links, German Debian handbook 'Das Debian Administrationshandbuch'

[Holger Wansing]

Package: debian-handbook


turning this into a bugreport


Beginning of forwarded mail:


Date: Fri, 18 Mar 2016 19:10:36 +0100
From: Mirko Kaltschmidt 
To: debian-...@lists.debian.org
Subject: broken links, German Debian handbook 'Das Debian 
Administrationshandbuch'


Dear Sir or Madam,

this message is made short (especially because the current state
regarding quality and correctness of my usage of the English language
has been unproven for many years).

Because of this I beg Your pardon, but hopefully You will be able to
get the message correctly.

Your website 'www.debian.org' has been visited from a German location.
Visiting 'https://www.debian.org/doc/manuals/debian-handbook/' to read
the manual, that is in German translation titled 'Das Debian
Administrationshandbuch', there has been some seemingly broken links
identified.

The seemingly broken links of the contents are '6.6. Von einer Stable
Distribution auf die nächste
aktualisieren'/'https://www.debian.org/doc/manuals/debian-handbook/sect.dist-upgrade.de.html',
'6.6.1. Empfohlene
Vorgehensweise'/'https://www.debian.org/doc/manuals/debian-handbook/sect.dist-upgrade.de.html#idm139675552654432',
and '6.6.2. Problembehandlung nach einer
Aktualisierung'/'https://www.debian.org/doc/manuals/debian-handbook/sect.dist-upgrade.de.html#idm139675552632176'.

A similiar problem is occurring also regarding the links refering to
'6.6.' from '6.5.' while visiting '6.5.' and the links refering to
'6.6.2.' from '6.7.' while visiting '6.7.'.

Maybe this mail is not written and send to You in vain, because You
find yourself able to understand this mail, that was written in the
best interest und empowered with the best will to actually communicate
something to You to make it understandable for You.

If not and if You are still not able to understand this text because
You might find it to cryptic, I do write a phrase for a second time,
because I am quite certain and convinced, that this it might be
definitely correct and understandable, hoping to meat Your
understanding and hoping to soothe You:

I beg Your pardon!  Sorry!  I am sorry!

To assure You of the sincerity of the whole mail, I also might write,
that I am not joking at all.

I do hope, that this might be of some kind of help to You.

Best regards
Mirko Kaltschmidt

Bug#818927: Fw: broken links, German Debian handbook 'Das Debian Administrationshandbuch'

[Raphael Hertzog]

Control: reassign -1 www.debian.org

On Mon, 21 Mar 2016, Holger Wansing wrote:
> turning this into a bugreport

Thanks, but Mirko was correct in contacting debian-www in the first
place. The Debian package contains the German translation:

$ apt-file show debian-handbook|grep dist-upgrade.html
[...]
debian-handbook: 
/usr/share/doc/debian-handbook/html/de-DE/sect.dist-upgrade.html

There's some cron job setup by Osamu that extracts the files and renames them to
follow the foo..html scheme. It looks like that script is failing (or has
failed last time only, I don't know) to create sect.dist-upgrade.de.html for 
some
reason.

(Leaving the rest of the mail for Osamu)

> Date: Fri, 18 Mar 2016 19:10:36 +0100
> From: Mirko Kaltschmidt 
> To: debian-...@lists.debian.org
> Subject: broken links, German Debian handbook 'Das Debian 
> Administrationshandbuch'
> 
> 
> Dear Sir or Madam,
> 
> this message is made short (especially because the current state
> regarding quality and correctness of my usage of the English language
> has been unproven for many years).
> 
> Because of this I beg Your pardon, but hopefully You will be able to
> get the message correctly.
> 
> Your website 'www.debian.org' has been visited from a German location.
> Visiting 'https://www.debian.org/doc/manuals/debian-handbook/' to read
> the manual, that is in German translation titled 'Das Debian
> Administrationshandbuch', there has been some seemingly broken links
> identified.
> 
> The seemingly broken links of the contents are '6.6. Von einer Stable
> Distribution auf die nächste
> aktualisieren'/'https://www.debian.org/doc/manuals/debian-handbook/sect.dist-upgrade.de.html',
> '6.6.1. Empfohlene
> Vorgehensweise'/'https://www.debian.org/doc/manuals/debian-handbook/sect.dist-upgrade.de.html#idm139675552654432',
> and '6.6.2. Problembehandlung nach einer
> Aktualisierung'/'https://www.debian.org/doc/manuals/debian-handbook/sect.dist-upgrade.de.html#idm139675552632176'.
> 
> A similiar problem is occurring also regarding the links refering to
> '6.6.' from '6.5.' while visiting '6.5.' and the links refering to
> '6.6.2.' from '6.7.' while visiting '6.7.'.
> 
> Maybe this mail is not written and send to You in vain, because You
> find yourself able to understand this mail, that was written in the
> best interest und empowered with the best will to actually communicate
> something to You to make it understandable for You.
> 
> If not and if You are still not able to understand this text because
> You might find it to cryptic, I do write a phrase for a second time,
> because I am quite certain and convinced, that this it might be
> definitely correct and understandable, hoping to meat Your
> understanding and hoping to soothe You:
> 
> I beg Your pardon!  Sorry!  I am sorry!
> 
> To assure You of the sincerity of the whole mail, I also might write,
> that I am not joking at all.
> 
> I do hope, that this might be of some kind of help to You.
> 
> Best regards
> Mirko Kaltschmidt
> 

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#818876: 818876 issues

[contact smxi]

As bug reports go, this one has about as many things wrong as you can possibly 
get in a short statement.

Note that there is constant churn in distro ID methods, unfortunately, a situation that does not 
look like it will ever stabilize, so these methods, while quite reliable, do have to be revisited 
now and then. inxi supports them all, or tries to.


Normally I don't accept any issues on older inxi releases that are not current stable branch, but in 
this case, the distro id logic hasn't changed in a long time so nothing would make it not work in 
the debian pool version that isn't the same in the current master branch version.


Let's start at the most obscure.

1. kfreebsd handler.

Line 824 of current release (2.2.35)

BSD_TYPE explicitly set. In fact, inxi is probably one of the very few system information programs 
that actually pays complete attention to the reality of kfreebsd. Kfreebsd was actually initially 
tested during the bsd development phase of inxi bsd support, which would make me one of the few 
people on the planet to actually have tested/run kfreebsd. Note that I no longer spend time on any 
bsd issues for inxi because it's too time consuming, so if users of bsds of any type have patches 
for inxi on their bsd flavor of choice, then: https://github.com/smxi/inxi is where to file those 
patch/issue reports. I'm happy to improve inxi bsd support, always, but only with complete, tested 
patches.


get_distro_data is where you'd be looking for logic errors, a logic error manifesting when you run 
inxi on the platform of choice and it reports the wrong distro/os type.


So a bug report that says inxi is wrong that does not even bother to test if inxi is wrong... well, 
that's an invalid bug report.


Note that things change, and as noted, I don't do constant checks of the bsd handlers, it takes too 
much time.


So the alleged kfreebsd issue isn't an issue until verified by someone who has actually tested inxi 
on kfreebsd. I've lost my vm kfreebsd login info so I can't test it without reinstalling the vm, and 
since the bug reporter didn't bother doing checking if there even is an issue, there is no issue to 
debug. Note that all BSDs do not give much release data, so inxi gives what they give.


So if there is an bug in inxi kfreebsd handling, create a bug report on it, but not one based on 
what you believe may happen, it has to be based on what IS happening, including output that shows it 
happening.


All BSD type detection in inxi, including kfreebsd, default to using uname -sr for their distro id. 
In other words, kfreebsd never even gets to the point of testing /etc/issue or /etc/debian_version, 
it's already exited the logic.


2. Now let's move on to the: Distro: /etc/ corrupted, use -% to override

How does this one happen?

It's useful to read the code, but I'll make it easy.

The FIRST thing inxi checks is /etc/debian_version based on the glob of /etc:
cd /etc
a_distro_glob=(*[-_]{release,version})

That gives us:

cat /etc/debian_version | wc -c
12
(stretch/sid)

So it's not using that file information.

A possible thing that could be happening is that there is another file in /etc that matches the 
globbing pattern, ie, it's /etc/*_-version|release


Worth checking, if it exists, I'll blacklist that file name in inxi, but it would be literally the 
first such in all the years I've done inxi to appear.


the only time /etc/issue is used is if ALL the distro id tests have failed, including lsb-release, 
os-release, and anything else. Because I develop on debian, inxi has more robust testing for debian 
than anything else. But even there, inxi is going to first test for lsb / os release to confirm that 
no other distro id has been found. /etc/issue is the absolute last test attempted, it means all 
other tests have failed to come up with anything. And the only time /etc/issue would have triggered 
the corrupted error would be if its contents were > 80 characters long. So the /etc/issue thing is 
wrong, obviously.


Which now gets us to the very end, the actual issue the person is experiencing.

What triggers the issue of corrupted data? It's if the specific distro id data was > 80 characters, 
whichever file it came from, makes no difference.


So to know what triggered this, we'd need to know which ID file was actually 
used.

echo -n 'Debian GNU/Linux stretch/sid \n \l' | wc -c
34

So the current stretch /etc/issue is 34 characters. The default debian /etc/issue did not cause this 
issue. If the user modified /etc/issue, and if no other distro id file was found, and if they 
entered a short essay in the contents of /etc/issue, then yes, you'd see that corrupted error. Then 
you'd start inxi with what it says: inxi -b -% and it would show you what was not printed.


I'd need to see the full debugger output to see what did cause it.

inxi considers that to be corrupted when > 80 characters first because it's unlikely any real distro 
info is going to be that long, second 

Bug#818902: RFS: arrayfire/3.3.1+dfsg1-1~exp1

[Ghislain Vaillant]

Indeed, I did not update d/copyright accordingly since the 3.3.x series
of releases. I have just rectified this and uploaded the new version on
mentors.

Thanks,
Ghislain


On 21/03/16 17:20, Gianfranco Costamagna wrote:

control: tags -1 moreinfo
control: owner -1 !

+ * Site:http://NadeauSoftware.com/
+ * License: Creative Commons Attribution 3.0 Unported License
+ *  http://creativecommons.org/licenses/by/3.0/deed.en_US
+ * Source:  
http://nadeausoftware.com/sites/NadeauSoftware.com/files/getMemorySize.c


not listed in copyright file.

the other stuff looks good, but please check carefully all the CC licenses :)

(this is a regression in 3.3.0 to be honest I think)

cheers!

G.





Il Lunedì 21 Marzo 2016 15:57, Ghislain Vaillant  ha 
scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "arrayfire"

* Package name: arrayfire
Version : 3.3.1+dfsg1-1~exp1
Upstream Author : ArrayFire Development Group
* URL : http://arrayfire.com/
* License : BSD
Section : science

It builds those binary packages:

libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend)
libarrayfire-cpu3 - High performance library for parallel computing
(CPU backend)
libarrayfire-cpu3-dbg - Debugging symbols for ArrayFire (CPU backend)
libarrayfire-dev - Common development files for ArrayFire
libarrayfire-doc - Common documentation and examples for ArrayFire
libarrayfire-opencl-dev - Development files for ArrayFire (OpenCL
backend)
libarrayfire-opencl3 - High performance library for parallel
computing (OpenCL backend)
libarrayfire-opencl3-dbg - Debugging symbols for ArrayFire (OpenCL
backend)
libarrayfire-unified-dev - Development files for ArrayFire (unified
backend)
libarrayfire-unified3 - High performance library for parallel
computing (unified backend)
libarrayfire-unified3-dbg - Debugging symbols for ArrayFire (unified
backend)

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

   http://mentors.debian.net/package/arrayfire

Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.3.1+dfsg1-1~exp1.dsc

Successful build logs on debomatic:

[amd64]
http://debomatic-amd64.debian.net/distribution#experimental/arrayfire/3.3.1+dfsg1-1~exp1/buildlog
[i386]
http://debomatic-i386.debian.net/distribution#experimental/arrayfire/3.3.1+dfsg1-1~exp1/buildlog

Changes since the last upload:

* New upstream release.
* Refresh patch Fix-LAPACKE-detection.patch.

Regards,
Ghislain Vaillant

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[adrian15]

El 21/03/16 a las 22:19, Michal Suchanek escribió:

Hello,

On 21 March 2016 at 21:09, adrian15  wrote:



The branch which include specifically the commits I attach here as patches
is:

https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5

.

About the variable names issue: I think the new terms: first and extra are
ok because they are not implying some sort of rank while explaining what's
the difference between them. Also, notice, that these are internal variables
which final user of live-build does not see. I think we should focus on
other aspects of my patch if there are more problems for it.


The problem is not with the name of the variable.

The problem is that you use it at all. In most places when you check
for primary or secondary bootloader you should just loop all
bootloaders and check each. In fact, in the previous batch of patches
I found no place where checking for primary or secondary bootloader
made any sense.



If you think that the way bootloaders is currently managed by live-build is
wrong please file up a new bug and send there your patch with your
improvements so that it's get discussed.


The bootloader support in live-build is limited. With your patches it
becomes wrong. eg. compatibility of bootloader with selected
filesystem and image type is only checked for first bootloader and EFI
support is added only when grub-efi extra bootloader but not when it
is the first bootloader.

This is not fixed by renaming the variables.


Ok. So I recognise that my patch:

* Adds a limited support of UEFI only available when it's used as an 
extra bootloader
* Does not check compatibility with selected filesystem in the extra 
bootloader because it blindly relies on selected filesystem selected in 
first bootloader being compatible with the extra bootloader too.

* It does not work for hdd binaries (only iso binaries)

and it does in addition to what live-build already did.

I also think that my patch does not remove the current live-build 
functionality and if that happens I want to know about it.


Yes, my patch does not bring UEFI complete support, but a minimal one. 
So according to you the many changes I make on the bootloader functions 
do not compensate the minimal UEFI support I add to live-build?


Thank you.

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#818934: binutils: Please re-enable gold on sparc/sparc64

[Matthias Klose]

On 21.03.2016 22:25, John Paul Adrian Glaubitz wrote:


According to binutils upstream, this issue has now been resolved [2] and I think
we can therefore give it a try to re-enable gold on sparc/sparc64 again.


not on the 2.26 branch.

Bug#818437: Nearly same behaviour

[Raphaël Beamonte]

2016-03-21 17:59 GMT-04:00 surf :
> Sorry, my bad. This was the last update that fixed the issue for me:
> mutter-common:amd64 (3.18.3-1 -> 3.18.3-2)

Oh, right! After upgrading (apt upgrade && apt full-upgrade) and
rebooting my system, it now seem to work again like expected (it
didn't just after upgrading, reboot was necessary).
For a thorough report, please find below the new packages versions
after upgrading (note that kernel version changed too).

Package: gnome-shell
Version: 3.18.1-1

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  evolution-data-server3.18.5-1
ii  gir1.2-accountsservice-1.0   0.6.40-3
ii  gir1.2-atspi-2.0 2.18.3-4
ii  gir1.2-caribou-1.0   0.4.20-1
ii  gir1.2-clutter-1.0   1.24.2-1
ii  gir1.2-freedesktop   1.46.0-4
ii  gir1.2-gcr-3 3.18.0-1
ii  gir1.2-gdesktopenums-3.0 3.18.1-1
ii  gir1.2-gdm3  3.18.0-2
ii  gir1.2-gkbd-3.0  3.6.0-1
ii  gir1.2-glib-2.0  1.46.0-4
ii  gir1.2-gnomebluetooth-1.03.18.2-1
ii  gir1.2-gnomedesktop-3.0  3.18.2-1
ii  gir1.2-gtk-3.0   3.18.9-1
ii  gir1.2-gweather-3.0  3.18.1-1
ii  gir1.2-ibus-1.0  1.5.11-1
ii  gir1.2-mutter-3.03.18.3-2
ii  gir1.2-networkmanager-1.01.1.91-3
ii  gir1.2-nmgtk-1.0 1.1.90-3
ii  gir1.2-pango-1.0 1.38.1-1
ii  gir1.2-polkit-1.00.105-14.1
ii  gir1.2-soup-2.4  2.52.2-1
ii  gir1.2-telepathyglib-0.120.24.1-1.1
ii  gir1.2-telepathylogger-0.2   0.8.2-1
ii  gir1.2-upowerglib-1.00.99.4-2
ii  gjs  1.43.3-2
ii  gnome-backgrounds3.18.0-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  gnome-settings-daemon3.18.2-1
ii  gnome-shell-common   3.18.1-1
ii  gsettings-desktop-schemas3.18.1-1
ii  libatk-bridge2.0-0   2.18.1-3
ii  libatk1.0-0  2.18.0-1
ii  libc62.22-3
ii  libcairo21.14.6-1
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libclutter-1.0-0 1.24.2-1
ii  libcogl-pango20  1.22.0-2
ii  libcogl201.22.0-2
ii  libcroco30.6.11-1
ii  libdbus-glib-1-2 0.106-1
ii  libecal-1.2-19   3.18.5-1
ii  libedataserver-1.2-213.18.5-1
ii  libgcr-base-3-1  3.18.0-1
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libgirepository-1.0-11.46.0-4
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.43.3-2
ii  libglib2.0-0 2.46.2-3
ii  libgstreamer1.0-01.6.3-1
ii  libgtk-3-0   3.18.9-1
ii  libical1a1.0.1-0.1
ii  libjson-glib-1.0-0   1.0.4-2
ii  libmozjs-24-024.2.0-3
ii  libmutter0g  3.18.3-2
ii  libnm-glib4  1.1.91-3
ii  libnm-util2  1.1.91-3
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpolkit-agent-1-0  0.105-14.1
ii  libpolkit-gobject-1-00.105-14.1
ii  libpulse-mainloop-glib0  8.0-1
ii  libpulse08.0-1
ii  libsecret-1-00.18.3-1
ii  libstartup-notification0 0.12-4
ii  libsystemd0  229-2
ii  libtelepathy-glib0   0.24.1-1.1
ii  libx11-6 2:1.6.3-1
ii  libxfixes3   

Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Le mercredi 27 janvier 2016 à 18:13:29+, Martin Read a écrit :
> On 26/01/16 15:52, Pierre-Elliott Bécue wrote:
> >Bump.
> >
> >It's been more than 10 months and still nothing (even a simple ack).
> >
> >Could you consider adding a stable version of grub in a partial release of 
> >Jessie?
> 
> A cursory inspection of the public browsing interface[1] to the relevant git
> repo makes it clear that there is no newer *version*, despite 2.02 beta 2
> being two years old and there having been significant numbers of git commits
> since then.
> 
> [1] http://git.savannah.gnu.org/cgit/grub.git/

Right, 2.02 beta 3 is out now, maybe it's worth a try.

Anyway, I was more concerned by the non-ack of my report.

Cheers,

-- 
PEB

Bug#818943: possibly add -openssl-linked ./conifugre option for building Qt (issue with Mumble)

[Lisandro Damián Nicanor Pérez Meyer]

First of all sorry for the formatting, I'm on the phone right now.

Second: thanks for digging this issue that much! I have now a quite clear
(although I might need to re read something) idea of the issue.

Let's start with the configure option: the problem it's not a technical
one. If we forget about possible licensing problems then using the
necessary switch is just one upload away.

Now I can't decide whether it's safe or not to use this option
license-wide. As I understand this the RT is not the authoritative source
for this, but the FTP team.

Even if I'm wrong wrt team's  responsabilities, I'm still uncertain wrt the
licensing issue. As far as I understand nothing has changed license-wide,
so Modestas' reply is still valid.

Sadly I can't also think of a way of marking qt to be rebuilt with some
libssl upload without linking to it...

I'm afraid the only suitable fix would be to fix ssl's licensing terms.

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

Bug#818947: 7.0 not reproducible

[Antoine Beaupré]

Package: atheme-services
Version: 7.0.7-1~exp0
Severity: normal
Tags: upstream

7.0 introduced some ugly build-ids and timestamps, i reported this upstream:

https://github.com/atheme/atheme/issues/473

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (500, 'oldstable'), (1, 'testing')
Architecture: amd64 (x86_64)

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

Bug#807455: golang-src: includes race detector runtime files not built from source in the source package

[Michael Hudson-Doyle]

On 3 February 2016 at 21:04, Michael Hudson-Doyle
 wrote:
> On 3 February 2016 at 19:08, Tianon Gravi  wrote:
>> On 8 December 2015 at 18:24, Michael Hudson-Doyle
>>  wrote:
>>> The files installed as /usr/share/go/src/runtime/race/*.syso are not built
>>> during package build, but rather come directly from the Go source 
>>> distribution.
>>> To ensure that they are built from what they claim to be, in Ubuntu we do 
>>> not
>>> distribute these files in the golang-src package but rather build them in a
>>> separate golang-race-detector-runtime package which golang-go Recommends:. 
>>> It
>>> would be nice if Debian could steal this work :-)
>>
>> I'm definitely keen on this one!
>
> Yay.
>
>> I think my issue with making it happen (last I looked into it) was
>> that the files in question needed to come from a separate source (LLVM
>> was it? [1]), and the exact versioning necessary was a little strange,
>> and it was sources that already exist in the Debian archive for
>> another package so I wasn't really clear on whether that's kosher or
>> whether we should be talking to the existing package maintainer to
>> keep things sane.  Am I remembering this correctly?
>
> Yes, your memory is pretty accurate. The source in question is the
> "compiler-rt" runtime libraries: http://compiler-rt.llvm.org/. The
> compiler-rt source is copied into the gcc and llvm trees -- although
> on checking, the copy in the gcc source lacks the go integration bits.
> The one in llvm-toolchain appears to have everything (in fact it's a
> multi orig source package, and one of the orig tarballs is the
> compiler-rt stuff), so the golang-race-detector-runtime could be built
> from the llvm-toolchain source package. The only question is around
> versioning then -- I don't have any intuition as to how much
> difference there is between the revisions go builds they're objects
> from and the revision for the compiler-rt that's part of the current
> llvm package at all. I've just wussed out of thinking about that so
> far. I guess I could ask upstream...

I've finally gotten around to asking on golang-dev:
https://groups.google.com/d/msg/golang-dev/7tmyNA9Dx6s/j_j3b7SKBQAJ

Cheers,
mwh

Bug#818948: RFS: gap-grape/4r7+ds-1 [ITP] -- GRaph Algorithms using PErmutation groups for GAP

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Mentors,

I am looking for a sponsor for the new Debian package gap-grape, a 
package
for the Computer Algebra System (CAS) GAP. This package brings nauty to 
GAP.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/git/debian-science/packages/gap-grape.git

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

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)