Bug#695757: Greeting ! I Am Mrs Samirah Abd er Rahman From Syria

[Samirah Abd er Rahman]

Greeting !
How are you? My name is Mrs Samirah Abd er Rahman, a Citizen of Syria 
lived in Aleppo- Syria., I'm one of the former senior inspector for 
Syria National Petroleum Company(Kawkab Oil Company). I have Business 
investment transaction worth $8.2 Million.  I will like to relocate out 
from Syria, Because here in Syria is serious war here. I wait to hear 
from you as soon as you see this message

regards,
Mrs Samirah Abd er Rahman

Bug#808420: [debian-mysql] Bug#808420: Implemented systemd scripts for MariaDB

[Otto Kekäläinen]

2017-01-24 17:05 GMT+02:00 Johannes Kliemann :
> I have tested it and it works good for me.
> It only seems there is no reload job for systemd. Is this intended?

Thanks!

It seems there is no reload support. We are now using the upstream
systemd script, and to keep maintenance work reasonable, I'd rather
not fork it in Debian.

Please consider contributing directly upstream to get reload support.
https://github.com/MariaDB/server/blob/10.2/support-files/mariadb.service.in

Bug#851132: [debian-mysql] Bug#851132: /usr/sbin/mysqld: ssl_ciphers not working; mariadb built without TLS support?

[Otto Kekäläinen]

Ok, this is now figured out.

To activate YaSSL you must have 'ssl=on' in the config and no
ssl_cipher defined.


50-server.cnf: ssl=on

=>

MariaDB [(none)]> SHOW VARIABLES LIKE '%ssl%';
+-+-+
| Variable_name   | Value   |
+-+-+
| have_openssl| NO  |
| have_ssl| YES |
| ssl_ca  | |
| ssl_capath  | |
| ssl_cert| |
| ssl_cipher  | |
| ssl_crl | |
| ssl_crlpath | |
| ssl_key | |
| version_ssl_library | YaSSL 2.4.2 |
+-+-+


YaSSL does not support TLS v1.2 for sure and when I tried 1.1 and 1.0
it didn't work either. Apparently you cannot define a cipher, as it
seems to disable YaSSL.

The solution here is to fix the documentation part:
https://anonscm.debian.org/git/pkg-mysql/mariadb-10.1.git/commit/?id=a27f5ace9786032a5d97d40964dcf8f1a6829a40

Props Vicentiu!

Bug#852529: chromium puts password in plain sight

[Harald Dunkel]

Package: chromium
Version: 55.0.2883.75-1~deb8u1

Chromium 55 shows the complete password in a login dialog
while it has input focus (see attachment for a sample
using https://heise.de/). *Highly* annoying, esp. when
you are not alone at your desktop.

This is a regression. How comes that Chromium did a major
version upgrade in Jessie at all?


Regards
Harri

Bug#849845: seems fixed in 2.1.18-1 (was: Bug#849845: Info received (dirmngr: Can't resolve keyserver hostname anymore))

[Gijs Hillenius]

The update to dirmngr (et al) 2.1.18-1 fixes the resolve problem in
dirmngr - at least for me.

It required a bit of fiddling: at first

gpg2   --search-keys  somekey

would fail similarly as before, except that there is one more line in
the output:

"dirmngr is older than us" (2.1.17 < 2.1.18)

Which, by the way, is not in the dirmngr log.

I then did

gpgconf --kill gpg-agent

After which dirmngr and gpg2 seems to have resolved their version
differences, since

gpg2   --search-keys somekey

returned the requested key.

Thanks

Bug#850427: Suggestions (inoperative desktop files)

[Fabian Greffrath]

Jonathan Dowland wrote:
> Perhaps, at least for the freeze deadline, this is a better approach. I
> couldn't remember which package we did this for, maybe it was rott; and
> zenity
> sounds familiar. Perhaps I should switch focus to a PoC of this approach.

It was ROTT, this is the relevant patch:

https://anonscm.debian.org/cgit/pkg-games/rott.git/tree/debian/patches/no-files-found-dialog.patch

> (P.S.: it occurred to me whilst doing this that we could put hacx in
> non-free
> post-freeze, and possibly chex too)

Yes, good idea! HACX should definitely be suitable for non-free. Not sure
about Chex Quest, though, I am not sure if this even comes with a proper
license.

> If we were already using sdl2, we could have looked at using that for the
> dialog. Alas!

Yes, native dialog windows will make things a lot easier.

Bug#851750: kpatch: module FTBFS for Linux 4.9

[Sam McLeod]

Interestingly I have a similar problem on CentOS 7 when trying to
compile kpatch for kernel 4.9:




```

~/git/kpatch # uname -aLinux nas 4.9.0-1.el7.elrepo.x86_64 #1 SMP Sun
Dec 11 15:43:54 EST 2016 x86_64 x86_64 x86_64 GNU/Linux


~/git/kpatch # make

make -C kpatch-build

make[1]: Entering directory `/root/git/kpatch/kpatch-build'

make[1]: Nothing to be done for `all'.

make[1]: Leaving directory `/root/git/kpatch/kpatch-build'

make -C kpatch

make[1]: Entering directory `/root/git/kpatch/kpatch'

make[1]: Nothing to be done for `all'.

make[1]: Leaving directory `/root/git/kpatch/kpatch'

make -C kmod

make[1]: Entering directory `/root/git/kpatch/kmod'

make -C core clean

make[2]: Entering directory `/root/git/kpatch/kmod/core'

rm -f -Rf .*.o.cmd .*.ko.cmd .tmp_versions *.o *.ko *.mod.c \

Module.symvers

make[2]: Leaving directory `/root/git/kpatch/kmod/core'

make -C core

make[2]: Entering directory `/root/git/kpatch/kmod/core'

make -C /lib/modules/4.9.0-1.el7.elrepo.x86_64/build
M=/root/git/kpatch/kmod/core kpatch.ko
make[3]: Entering directory `/usr/src/kernels/4.9.0-1.el7.elrepo.x86_64'
  CC [M]  /root/git/kpatch/kmod/core/core.o

/root/git/kpatch/kmod/core/core.c:273:21: error: variable
‘kpatch_backtrace_ops’ has initializer but incomplete type
static const struct stacktrace_ops kpatch_backtrace_ops = {

 ^

/root/git/kpatch/kmod/core/core.c:274:2: error: unknown field ‘address’
specified in initializer
  .address = kpatch_backtrace_address_verify,

  ^

/root/git/kpatch/kmod/core/core.c:274:2: warning: excess elements in
struct initializer [enabled by default]
/root/git/kpatch/kmod/core/core.c:274:2: warning: (near initialization
for ‘kpatch_backtrace_ops’) [enabled by default]
/root/git/kpatch/kmod/core/core.c:275:2: error: unknown field ‘stack’
specified in initializer
  .stack  = kpatch_backtrace_stack,

  ^

/root/git/kpatch/kmod/core/core.c:275:2: warning: excess elements in
struct initializer [enabled by default]
/root/git/kpatch/kmod/core/core.c:275:2: warning: (near initialization
for ‘kpatch_backtrace_ops’) [enabled by default]
/root/git/kpatch/kmod/core/core.c:276:2: error: unknown field
‘walk_stack’ specified in initializer
  .walk_stack = print_context_stack_bp,

  ^

/root/git/kpatch/kmod/core/core.c:276:16: error:
‘print_context_stack_bp’ undeclared here (not in a function)
  .walk_stack = print_context_stack_bp,

^

/root/git/kpatch/kmod/core/core.c:276:2: warning: excess elements in
struct initializer [enabled by default]
  .walk_stack = print_context_stack_bp,

  ^

/root/git/kpatch/kmod/core/core.c:276:2: warning: (near initialization
for ‘kpatch_backtrace_ops’) [enabled by default]
/root/git/kpatch/kmod/core/core.c:303:21: error: variable
‘kpatch_print_trace_ops’ has initializer but incomplete type
static const struct stacktrace_ops kpatch_print_trace_ops = {

 ^

/root/git/kpatch/kmod/core/core.c:304:2: error: unknown field ‘stack’
specified in initializer
  .stack  = kpatch_print_trace_stack,

  ^

/root/git/kpatch/kmod/core/core.c:304:2: warning: excess elements in
struct initializer [enabled by default]
/root/git/kpatch/kmod/core/core.c:304:2: warning: (near initialization
for ‘kpatch_print_trace_ops’) [enabled by default]
/root/git/kpatch/kmod/core/core.c:305:2: error: unknown field ‘address’
specified in initializer
  .address = kpatch_print_trace_address,

  ^

/root/git/kpatch/kmod/core/core.c:305:2: warning: excess elements in
struct initializer [enabled by default]
/root/git/kpatch/kmod/core/core.c:305:2: warning: (near initialization
for ‘kpatch_print_trace_ops’) [enabled by default]
/root/git/kpatch/kmod/core/core.c:306:2: error: unknown field
‘walk_stack’ specified in initializer
  .walk_stack = print_context_stack,

  ^

/root/git/kpatch/kmod/core/core.c:306:16: error: ‘print_context_stack’
undeclared here (not in a function)
  .walk_stack = print_context_stack,

^

/root/git/kpatch/kmod/core/core.c:306:2: warning: excess elements in
struct initializer [enabled by default]
  .walk_stack = print_context_stack,

  ^

/root/git/kpatch/kmod/core/core.c:306:2: warning: (near initialization
for ‘kpatch_print_trace_ops’) [enabled by default]
/root/git/kpatch/kmod/core/core.c: In function
‘kpatch_verify_activeness_safety’:
/root/git/kpatch/kmod/core/core.c:327:3: error: implicit declaration of
function ‘dump_trace’ [-Werror=implicit-function-declaration]
   dump_trace(t, NULL, NULL, 0, _backtrace_ops, );

   ^

cc1: some warnings being treated as errors

make[4]: *** [/root/git/kpatch/kmod/core/core.o] Error 1

make[3]: *** [kpatch.ko] Error 2

make[3]: Leaving directory `/usr/src/kernels/4.9.0-1.el7.elrepo.x86_64'
make[2]: *** [kpatch.ko] Error 2

make[2]: Leaving directory `/root/git/kpatch/kmod/core'

make[1]: *** [all] Error 2

make[1]: Leaving directory `/root/git/kpatch/kmod'

make: *** [build-kmod] Error 2

```

Bug#852528: liferea: crashes when the database isn't readable instead of notifying the user

[Paul Wise]

Package: liferea
Version: 1.12~rc2-2
Severity: normal
Usertags: crash

liferea crashes when the database isn't readable and does not attempt
to fix the issue nor notify the user about the issue. This sort of
thing can happen accidentally when restoring backups or running cleanup
tools so it would be nice to handle it more elegantly.

pabs@chianamo ~ $ chmod 000 .local/share/liferea/liferea.db 
pabs@chianamo ~ $ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 
'thread apply all bt full' --args liferea
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe11e0700 (LWP 23808)]
[New Thread 0x7fffe03fa700 (LWP 23809)]
[New Thread 0x7fffdfbf9700 (LWP 23810)]
[New Thread 0x7fffddafe700 (LWP 23812)]

** (liferea:22341): ERROR **: Data base file 
/home/pabs/.local/share/liferea/liferea.db could not be opened (error code 14: 
unable to open database file)...

Thread 1 "liferea" received signal SIGTRAP, Trace/breakpoint trap.
_g_log_abort (breakpoint=1) at ././glib/gmessages.c:487
487 ././glib/gmessages.c: No such file or directory.
#0  0x72979261 in _g_log_abort (breakpoint=1) at 
././glib/gmessages.c:487
#1  0x7297a2b7 in g_log_default_handler 
(log_domain=log_domain@entry=0x0, log_level=log_level@entry=6, 
message=message@entry=0x5592e260 "Data base file 
/home/pabs/.local/share/liferea/liferea.db could not be opened (error code 14: 
unable to open database file)...", unused_data=unused_data@entry=0x0) at 
././glib/gmessages.c:2816
#2  0x7297a5c4 in g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, 
format=, args=args@entry=0x7fffd380) at 
././glib/gmessages.c:1275
#3  0x7297a7cf in g_log (log_domain=log_domain@entry=0x0, 
log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x555afbe8 
"Data base file %s could not be opened (error code %d: %s)...") at 
././glib/gmessages.c:1337
#4  0x555747da in db_open () at db.c:242
#5  0x555747da in db_init () at db.c:262
#6  0x55580c0f in on_app_startup (gapp=, 
user_data=) at liferea_application.c:139
#10 0x72c67faf in  (instance=instance@entry=0x558210e0, 
signal_id=, detail=detail@entry=0) at ././gobject/gsignal.c:3447
#7  0x72c4cf75 in g_closure_invoke (closure=0x55822e60, 
return_value=return_value@entry=0x0, n_param_values=1, 
param_values=param_values@entry=0x7fffd670, 
invocation_hint=invocation_hint@entry=0x7fffd5f0) at 
././gobject/gclosure.c:804
#8  0x72c5ef82 in signal_emit_unlocked_R 
(node=node@entry=0x5581ea00, detail=detail@entry=0, 
instance=instance@entry=0x558210e0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffd670) at 
././gobject/gsignal.c:3635
#9  0x72c67bcc in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffd820) at ././gobject/gsignal.c:3391
#11 0x73162ae2 in g_application_register 
(application=application@entry=0x558210e0 [LifereaApplication], 
cancellable=cancellable@entry=0x0, error=error@entry=0x7fffd958) at 
././gio/gapplication.c:2049
#12 0x7316330f in g_application_real_local_command_line 
(application=0x558210e0 [LifereaApplication], arguments=0x7fffda58, 
exit_status=0x7fffda54) at ././gio/gapplication.c:1012
#13 0x73163672 in g_application_run (application=0x558210e0 
[LifereaApplication], argc=1, argv=0x7fffdba8) at 
././gio/gapplication.c:2350
#14 0x55570f77 in main (argc=1, argv=0x7fffdba8) at main.c:82

Thread 5 (Thread 0x7fffddafe700 (LWP 23812)):
#0  0x7214954d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x729739f6 in g_main_context_poll (priority=, 
n_fds=1, fds=0x55875380, timeout=, context=0x5591cec0) 
at ././glib/gmain.c:4228
poll_func = 0x72983840 
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 1
allocated_nfds = 1
fds = 0x55875380
#2  0x729739f6 in g_main_context_iterate 
(context=context@entry=0x5591cec0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3924
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 1
allocated_nfds = 1
fds = 0x55875380
#3  0x72973b0c in g_main_context_iteration 
(context=context@entry=0x5591cec0, may_block=may_block@entry=1) at 
././glib/gmain.c:3990
retval = 
#4  0x7fffddb0646d in dconf_gdbus_worker_thread (user_data=0x5591cec0) 
at dconf-gdbus-thread.c:82
context = 0x5591cec0
#5  0x7299b345 in g_thread_proxy (data=0x55a0a800) at 
././glib/gthread.c:784
thread = 0x55a0a800
#6  0x7240f424 in start_thread (arg=0x7fffddafe700) at 
pthread_create.c:333
__res = 
pd = 0x7fffddafe700
now = 

Bug#852258: rt-authen-externalauth: FTBFS: Your installed version of RT (4.4.1-2) is too new

[Tom Jampen]

Hi Chris

Thanks for reporting this bug.

request-tracker as of version 4.4 includes rt-authen-externalauth's
functionality. So let's see whether rt 4.4 makes it into stretch.

Regards
Tom

Bug#852526: O: gkdebconf -- Helper to reconfigure packages with Debconf

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of gkdebconf, Agney Lopes Roth Ferraz ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: gkdebconf
Binary: gkdebconf
Version: 1.2.68
Maintainer: Agney Lopes Roth Ferraz 
Build-Depends: debhelper (>= 9.0.0), libgtk2.0-dev, gettext (>= 0.12), 
libgconf2-dev
Architecture: any
Standards-Version: 3.9.3.0
Format: 1.0
Files:
 7bf77b54aaeb06a66b25d35052fa8c25 819 gkdebconf_1.2.68.dsc
 fdae47921d29e17d7352fc458da1a312 457435 gkdebconf_1.2.68.tar.gz
Checksums-Sha1:
 8a1256683751531cc465f4ed3512ab77395ec93e 819 gkdebconf_1.2.68.dsc
 c1be625eff200cedc0008dd47b69b423b3359e17 457435 gkdebconf_1.2.68.tar.gz
Checksums-Sha256:
 31000192beae709713a4ce649d2c7206fab3c2d6796a00ce6bbd982862f5ab6e 819 
gkdebconf_1.2.68.dsc
 24c6dd3d0bf5a5f8ff976f01d55a05aad85434392ee9e87d4093107b8d3db41b 457435 
gkdebconf_1.2.68.tar.gz
Package-List: 
 gkdebconf deb admin optional
Directory: pool/main/g/gkdebconf
Priority: source
Section: admin

Package: gkdebconf
Binary: gkdebconf
Version: 1.2.68
Maintainer: Agney Lopes Roth Ferraz 
Build-Depends: debhelper (>= 9.0.0), libgtk2.0-dev, gettext (>= 0.12), 
libgconf2-dev
Architecture: any
Standards-Version: 3.9.3.0
Format: 1.0
Files:
 7bf77b54aaeb06a66b25d35052fa8c25 819 gkdebconf_1.2.68.dsc
 fdae47921d29e17d7352fc458da1a312 457435 gkdebconf_1.2.68.tar.gz
Checksums-Sha256:
 31000192beae709713a4ce649d2c7206fab3c2d6796a00ce6bbd982862f5ab6e 819 
gkdebconf_1.2.68.dsc
 24c6dd3d0bf5a5f8ff976f01d55a05aad85434392ee9e87d4093107b8d3db41b 457435 
gkdebconf_1.2.68.tar.gz
Package-List: 
 gkdebconf deb admin optional
Directory: pool/main/g/gkdebconf
Priority: source
Section: admin

Package: gkdebconf
Version: 1.2.68
Installed-Size: 314
Maintainer: Agney Lopes Roth Ferraz 
Architecture: amd64
Depends: gconf-service, libatk1.0-0 (>= 1.12.4), libc6 (>= 2.4), libcairo2 (>= 
1.2.4), libfontconfig1 (>= 2.9.0), libfreetype6 (>= 2.2.1), libgconf-2-4 (>= 
2.31.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 
(>= 2.8.0), libpango1.0-0 (>= 1.14.0), xterm | x-terminal-emulator, debconf (>= 
1.4.58) | debconf-2.0, gettext-base, gksu (>= 1.3.5)
Suggests: whiptail | dialog | gnome-utils, liblocale-gettext-perl, 
libterm-readline-gnu-perl, libgtk2-perl (>= 1:1.130), libqt-perl
Description-en: Helper to reconfigure packages with Debconf
 This is a program that helps one using the "dpkg-reconfigure" tool.
 It is basically a graphical frontend. It makes life easier showing
 a simple menu of packages which can be reconfigured with Debconf and
 the Debconf frontends that can be used for the reconfiguration.
Description-md5: fb90f5c2f8aecab41e9466d02bd9f0b3
Tag: admin::configuring, interface::x11, role::program, suite::debian,
 uitoolkit::gtk, use::configuring, x11::application
Section: admin
Priority: optional
Filename: pool/main/g/gkdebconf/gkdebconf_1.2.68_amd64.deb
Size: 112532
MD5sum: 6c640720a09a72d91de481e142ff586d
SHA1: 8dc5013a3d85e31de00ca496f4ad852a333f890a
SHA256: 7b6616281938731ff0602ec067c97a3534a51ba701694dac0d1412a7e42df432

Package: gkdebconf
Version: 1.2.68
Installed-Size: 314
Maintainer: Agney Lopes Roth Ferraz 
Architecture: amd64
Depends: gconf-service, libatk1.0-0 (>= 1.12.4), libc6 (>= 2.4), libcairo2 (>= 
1.2.4), libfontconfig1 (>= 2.9.0), libfreetype6 (>= 2.2.1), libgconf-2-4 (>= 
2.31.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 
(>= 2.8.0), libpango1.0-0 (>= 1.14.0), xterm | x-terminal-emulator, debconf (>= 
1.4.58) | debconf-2.0, gettext-base, gksu (>= 1.3.5)
Suggests: whiptail | dialog | gnome-utils, liblocale-gettext-perl, 
libterm-readline-gnu-perl, libgtk2-perl (>= 1:1.130), libqt-perl
Description-en: Helper to reconfigure packages with Debconf
 This is a program that helps one using the "dpkg-reconfigure" tool.
 It is basically a graphical frontend. It makes life easier showing
 a simple menu of packages which can be reconfigured with Debconf and
 the Debconf frontends that can be used for the reconfiguration.
Description-md5: fb90f5c2f8aecab41e9466d02bd9f0b3
Tag: admin::configuring, interface::x11, role::program, suite::debian,
 uitoolkit::gtk, use::configuring, x11::application
Section: admin
Priority: optional
Filename: pool/main/g/gkdebconf/gkdebconf_1.2.68_amd64.deb
Size: 112532
MD5sum: 6c640720a09a72d91de481e142ff586d
SHA1: 8dc5013a3d85e31de00ca496f4ad852a333f890a
SHA256: 7b6616281938731ff0602ec067c97a3534a51ba701694dac0d1412a7e42df432



signature.asc
Description: PGP signature

Bug#852525: O: hardinfo -- Displays system information

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of hardinfo, Agney Lopes Roth Ferraz ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: hardinfo
Binary: hardinfo
Version: 0.5.1-1.4
Maintainer: Agney Lopes Roth Ferraz 
Build-Depends: debhelper (>> 5.0.0), libgtk2.0-dev, pciutils (>= 1:2.1.11-10), 
libsoup2.4-dev, libffi-dev, liblzma-dev, libselinux1-dev [!kfreebsd-i386 
!kfreebsd-amd64 !hurd-i386]
Architecture: any
Standards-Version: 3.8.3.0
Format: 1.0
Files:
 537f13946dca58b3178244bac1c43358 1791 hardinfo_0.5.1-1.4.dsc
 6de865911b4155d11ed7567b0e47686e 265361 hardinfo_0.5.1.orig.tar.gz
 0a194b720e1fff6c437e972d098c76fe 9707 hardinfo_0.5.1-1.4.diff.gz
Checksums-Sha1:
 d9652cc81660aa77b94fe087f4abe184c235d9f0 1791 hardinfo_0.5.1-1.4.dsc
 efda5ae7e6e8ced9fbf592980661e2746d013c05 265361 hardinfo_0.5.1.orig.tar.gz
 60f88c5c75f86c0fed3324d83567421183fd6f61 9707 hardinfo_0.5.1-1.4.diff.gz
Checksums-Sha256:
 d3ae13c5f3be321e55cda17700838d0485661cbda08e4539b808bbb9b8b9005f 1791 
hardinfo_0.5.1-1.4.dsc
 e22161aaf508e4775eab39f778f1f1f7492a73adf067dffdc00bf80a11b1b9a4 265361 
hardinfo_0.5.1.orig.tar.gz
 2ae3f3f54f8c5c2a2f9b25fcb5ded5b8f861d52a0aacc192a5e9181a05a9e578 9707 
hardinfo_0.5.1-1.4.diff.gz
Package-List: 
 hardinfo deb x11 optional arch=any
Directory: pool/main/h/hardinfo
Priority: source
Section: x11

Package: hardinfo
Binary: hardinfo
Version: 0.5.1-1.5
Maintainer: Agney Lopes Roth Ferraz 
Build-Depends: debhelper (>> 5.0.0), libgtk2.0-dev, pciutils (>= 1:2.1.11-10), 
libsoup2.4-dev, libffi-dev, liblzma-dev, libselinux1-dev [!kfreebsd-i386 
!kfreebsd-amd64 !hurd-i386]
Architecture: any
Standards-Version: 3.8.3.0
Format: 1.0
Files:
 4f745f6039a8b8c49408db3b513b7f42 1917 hardinfo_0.5.1-1.5.dsc
 6de865911b4155d11ed7567b0e47686e 265361 hardinfo_0.5.1.orig.tar.gz
 44af25128d6656c0fbd8121cef972d30 9871 hardinfo_0.5.1-1.5.diff.gz
Checksums-Sha256:
 d9032c4f8b8f94fa39abaacb2193f72fdb5035a086b25a7d1373fd9960672823 1917 
hardinfo_0.5.1-1.5.dsc
 e22161aaf508e4775eab39f778f1f1f7492a73adf067dffdc00bf80a11b1b9a4 265361 
hardinfo_0.5.1.orig.tar.gz
 a570d0606889633dadcea76cee2b96aafd3c3317910cd4e77e4c3e5de8c2f665 9871 
hardinfo_0.5.1-1.5.diff.gz
Package-List: 
 hardinfo deb x11 optional arch=any
Directory: pool/main/h/hardinfo
Priority: source
Section: x11

Package: hardinfo
Source: hardinfo (0.5.1-1.5)
Version: 0.5.1-1.5+b2
Installed-Size: 508
Maintainer: Agney Lopes Roth Ferraz 
Architecture: amd64
Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo2 (>= 1.2.4), 
libffi6 (>= 3.0.4), libfontconfig1 (>= 2.11), libfreetype6 (>= 2.2.1), 
libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.35.9), libgtk2.0-0 (>= 
2.12.0), libicu57 (>= 57.1-1~), liblzma5 (>= 5.1.1alpha+20110809), 
libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 
(>= 1.14.0), libpcre3, libselinux1 (>= 1.32), libsoup2.4-1 (>= 2.4.0), libxml2 
(>= 2.6.27), zlib1g (>= 1:1.1.4), pciutils (>= 1:2.1.11-10)
Suggests: mesa-utils
Description-en: Displays system information
 HardInfo is a small application that displays information about your
 hardware and operating system. Currently it knows about PCI, ISA PnP, USB,
 IDE, SCSI, Serial and parallel port devices.
Description-md5: 19d3763ccb20f95253134c924f126657
Tag: hardware::detection, interface::graphical, interface::x11,
 role::program, scope::utility, uitoolkit::gtk, use::scanning,
 use::viewing, x11::application
Section: x11
Priority: optional
Filename: pool/main/h/hardinfo/hardinfo_0.5.1-1.5+b2_amd64.deb
Size: 225482
MD5sum: fb138d7c725879488fdc615752694d14
SHA256: e19f3024e4bf7763572f09f63a1e8623287ea7bfb28cc7a08f07a5d7dcc26d2d

Package: hardinfo
Version: 0.5.1-1.4
Installed-Size: 456
Maintainer: Agney Lopes Roth Ferraz 
Architecture: amd64
Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo2 (>= 1.2.4), 
libffi6 (>= 3.0.4), libfontconfig1 (>= 2.11), libfreetype6 (>= 2.2.1), 
libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.35.9), libgtk2.0-0 (>= 
2.12.0), liblzma5 (>= 5.1.1alpha+20110809), libpango-1.0-0 (>= 1.14.0), 
libpangocairo-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 (>= 1.14.0), libpcre3 (>= 
8.10), libselinux1 (>= 1.32), libsoup2.4-1 (>= 2.4.0), libxml2 (>= 2.6.27), 
zlib1g (>= 1:1.1.4), pciutils (>= 1:2.1.11-10)
Suggests: mesa-utils
Description-en: Displays system information
 HardInfo is a small application that displays information about your
 hardware and operating system. Currently it knows about PCI, ISA PnP, USB,
 IDE, SCSI, Serial and parallel port devices.
Description-md5: 19d3763ccb20f95253134c924f126657
Tag: hardware::detection, 

Bug#852527: O: fnfx -- ACPI and hotkey daemon for Toshiba laptops

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of fnfx, Agney Lopes Roth Ferraz ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: fnfx
Binary: fnfxd, fnfx-client
Version: 0.3-14
Maintainer: Agney Lopes Roth Ferraz 
Build-Depends: debhelper (>= 4.0.0), autotools-dev (>= 20040719.1)
Architecture: i386
Standards-Version: 3.8.0.0
Format: 1.0
Files:
 373a4843bd07358a6c9666a86e0cc11a 968 fnfx_0.3-14.dsc
 2487730494a8ff86d83d9cf7e6a67325 98430 fnfx_0.3.orig.tar.gz
 dd91693add79bdfb093b2b7dfdfcd155 27580 fnfx_0.3-14.diff.gz
Checksums-Sha1:
 c42c97ed72c01a84661c14b1330d73725a1d49d8 968 fnfx_0.3-14.dsc
 33cb4ed921f45022bd1c0ea550ee2d9e40f03d27 98430 fnfx_0.3.orig.tar.gz
 ed304c5d1028a35776c5d1ff7f4097b66203e973 27580 fnfx_0.3-14.diff.gz
Checksums-Sha256:
 b93744a0791006603a97180d0b01675cd23de3b53abb4e1fb26c55aabdde3c95 968 
fnfx_0.3-14.dsc
 c21a5611d4cc5d2170ec3bd05cb3dc805f5542cba260938e47614ed472812dbf 98430 
fnfx_0.3.orig.tar.gz
 aeb53b653a665ad8f558d86f0c9e234171103e5580108ea592fc154b35b2e26f 27580 
fnfx_0.3-14.diff.gz
Directory: pool/main/f/fnfx
Priority: source
Section: utils

Package: fnfx
Binary: fnfxd, fnfx-client
Version: 0.3-14
Maintainer: Agney Lopes Roth Ferraz 
Build-Depends: debhelper (>= 4.0.0), autotools-dev (>= 20040719.1)
Architecture: i386
Standards-Version: 3.8.0.0
Format: 1.0
Files:
 373a4843bd07358a6c9666a86e0cc11a 968 fnfx_0.3-14.dsc
 2487730494a8ff86d83d9cf7e6a67325 98430 fnfx_0.3.orig.tar.gz
 dd91693add79bdfb093b2b7dfdfcd155 27580 fnfx_0.3-14.diff.gz
Checksums-Sha256:
 b93744a0791006603a97180d0b01675cd23de3b53abb4e1fb26c55aabdde3c95 968 
fnfx_0.3-14.dsc
 c21a5611d4cc5d2170ec3bd05cb3dc805f5542cba260938e47614ed472812dbf 98430 
fnfx_0.3.orig.tar.gz
 aeb53b653a665ad8f558d86f0c9e234171103e5580108ea592fc154b35b2e26f 27580 
fnfx_0.3-14.diff.gz
Directory: pool/main/f/fnfx
Priority: source
Section: utils

Package: fnfxd
Source: fnfx
Version: 0.3-14
Installed-Size: 72
Maintainer: Agney Lopes Roth Ferraz 
Architecture: i386
Replaces: fnfx
Depends: libc6 (>= 2.7-1)
Suggests: fnfx-client
Conflicts: fnfx
Description-en: ACPI and hotkey daemon for Toshiba laptops
 fnfx enables owners of Toshiba laptops to change the LCD brightness,
 control, the internal fan and use the special keys on their keyboard
 (Fn-x combinations, hot-keys). The internal functions will give the
 possibility to map the Fn-Keys to functions like volume up/down, mute,
 suspend to disk, suspend to ram and switch LCD/CRT/TV-out. These
 functions heavily depend on the system and/or kernel configuration.
 You will need at least a kernel (v2.4.x, v2.5.x, v2.6.x) with ACPI and
 Toshiba support (CONFIG_ACPI and CONFIG_ACPI_TOSHIBA).
Description-md5: b4f6680513b9de0cc55876832083
Tag: hardware::input:keyboard, hardware::laptop, hardware::power,
 hardware::power:acpi, interface::daemon, network::server,
 role::program, use::driver
Section: utils
Priority: optional
Filename: pool/main/f/fnfx/fnfxd_0.3-14_i386.deb
Size: 19572
MD5sum: 912557217495e6878c7ed0e4d25d5b43
SHA1: f88567e98f36a43ab49fe5cb2202a477c285e030
SHA256: 6a2e13117421c4cb432cf677122b5f4d6964521f331a818b4b6095f86b6f

Package: fnfx-client
Source: fnfx
Version: 0.3-14
Installed-Size: 16
Maintainer: Agney Lopes Roth Ferraz 
Architecture: i386
Depends: fnfxd (>= 0.3-14), libc6 (>= 2.7-1)
Description-en: Client for customize fnfxd hot-keys
 fnfx is a client for fnfxd, that makes possible to customize your hotkeys.
 It can also define hot-keys to start arbitrary programs.
Description-md5: 5c44c67a0d6015b810ee55f91552b5f8
Tag: hardware::input, hardware::laptop, interface::commandline,
 network::client, role::program, use::driver
Section: utils
Priority: optional
Filename: pool/main/f/fnfx/fnfx-client_0.3-14_i386.deb
Size: 7518
MD5sum: cade5cf51ada631b64ec748ad7e50bd7
SHA1: bf1a66c109bdd8d7942a3549fdc36d35d670a323
SHA256: 149fdc5598bdf3c2acc18044757e80e548d5f02323d0953f535b24e1c1a67578

Package: fnfxd
Source: fnfx
Version: 0.3-14
Installed-Size: 72
Maintainer: Agney Lopes Roth Ferraz 
Architecture: i386
Replaces: fnfx
Depends: libc6 (>= 2.7-1)
Suggests: fnfx-client
Conflicts: fnfx
Description-en: ACPI and hotkey daemon for Toshiba laptops
 fnfx enables owners of Toshiba laptops to change the LCD brightness,
 control, the internal fan and use the special keys on their keyboard
 (Fn-x combinations, hot-keys). The internal functions will give the
 possibility to map the Fn-Keys to functions like volume up/down, mute,
 suspend to disk, suspend to ram and switch LCD/CRT/TV-out. These
 functions heavily depend on the system and/or kernel configuration.
 

Bug#852436: cups-browsed uses 100% CPU

[Didier 'OdyX' Raboud]

Control: tags -1 +patch +moreinfo

olsen, 

This would be the package built with Till's patch included:


https://people.debian.org/~odyx/tmp/eiRa3quooCai4ju0/cups-browsed_1.11.6-4~test852436_amd64.deb

Can you test and confirm that it fixes that bug for you?

Cheers,
-- 
OdyX

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

Bug#852524: qt3d5-dev ships broken symlinks

[Johannes Schauer]

Package: qt3d5-dev
Version: 5.7.1+dfsg-1
Severity: important

Hi,

after installing the package, I'm left with this situation:

$ file /usr/lib/x86_64-linux-gnu/libQt53D* | grep broken
/usr/lib/x86_64-linux-gnu/libQt53DExtras.so:broken symbolic link to 
libQt53DExtras.so.5.7.1
/usr/lib/x86_64-linux-gnu/libQt53DLogic.so: broken symbolic link to 
libQt53DLogic.so.5.7.1
/usr/lib/x86_64-linux-gnu/libQt53DQuickExtras.so:   broken symbolic link to 
libQt53DQuickExtras.so.5.7.1

I guess some Depends are missing from the package?

Thanks!

cheers, josch

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

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 qt3d5-dev depends on:
ii  libqt53dcore5 5.7.1+dfsg-1
ii  libqt53dinput55.7.1+dfsg-1
ii  libqt53dquick55.7.1+dfsg-1
ii  libqt53dquickinput5   5.7.1+dfsg-1
ii  libqt53dquickrender5  5.7.1+dfsg-1
ii  libqt53drender5   5.7.1+dfsg-1
ii  qtbase5-dev   5.7.1+dfsg-2

qt3d5-dev recommends no packages.

qt3d5-dev suggests no packages.

-- no debconf information

Bug#852523: Central section commont to (old)stable and (old)stable-security regarding versioning recommendations

[Salvatore Bonaccorso]

Package: developers-reference
Version: 3.4.18

Hi

Since I failed to come up with a proper proposal for a formulation
let's open a bug for it. Part of the versioning recommendation is
already present in the developers-reference.

On Fri, Dec 02, 2016 at 08:57:14AM +0100, Emilio Pozuelo Monfort wrote:
> On 02/12/16 06:40, Salvatore Bonaccorso wrote:
> > Hi Emilio, Jonas, Antoine,
> > 
> > Thanks for all feedback.
> > 
> > On Thu, Dec 01, 2016 at 04:44:22PM +0100, Emilio Pozuelo Monfort wrote:
> >> On 01/12/16 16:25, Jonas Meurer wrote:
> >>> Hi Security and LTS folks,
> >>>
> >>> Am 01.12.2016 um 15:54 schrieb Salvatore Bonaccorso:
>  On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote:
> > +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high
> > +
> > +  * Non-maintainer upload by the LTS Security Team.
> > +  * New upstream release to fix CVE-2016-9074
> 
>  Depending on what is done this should be either 2:3.26.2-0+debu7u1 or
>  2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1.
> 
>  The former if you import new orig source on top of the previous
>  packaging to indicate the new import and have a version which is
>  before any possible such ones uploaded to unstable (which is even true
>  in this case because 2:3.26.2-1 is currently in unstable). The later
>  is often prefered if the package is mostly are build of :3.26.2-1 for
>  Wheezy. (The later proposed version works obviously as well in the
>  case of just a new upstream import, but Release team has often as well
>  done that distinction for the ~debXuY suffix).
> >>>
> >>> With this topic being discussed again and again recently, I suggest that
> >>> we should agree on a defined standard regarding the versioning of new
> >>> upstream releases uploaded to (old)?stable(-security)? and document it
> >>> somewhere. What do you think?
> >>>
> >>> I don't have particular strong feelings on the exact versioning but I
> >>> think that the following should be considered:
> >>>
> >>> *) New upstream releases in (old)?stable should use lover version
> >>>numbers than their equivalent uploaded to unstable. This because
> >>>packages uploaded to unstable are built using more recent versions
> >>>of the build toolchain and libraries.
> >>
> >> Moreover, New upstream releases should use lower versions than the next 
> >> suite.
> >> That means oldstable < stable < testing < sid. Not just oldstable < sid and
> >> stable < sid, as you worded it.
> >>
> >> That's why 2:3.26.2-1+debu7u1 would be bad even if unstable had 2:3.26.3-1 
> >> by
> >> now, if stable had 2:3.26.2-1~debu8u1.
> >>
> >> When doing an update in oldstable, we need to see if it has happened or is
> >> happening in stable to avoid having a higher version in oldstable.
> >>
> >>> *) The versioning should make it obvious whether the new release is
> >>>based on a similar upload to unstable or whether it's packaged
> >>>solely for (old)?stable.
> >>>
> >>> Consequently, the following (as already done for most uploads of new
> >>> releases to (old)?stable) is my suggestion:
> >>>
> >>> *) Uploads of new upstream releases to (old)?stable that were packaged
> >>>for unstable before should use the '~debXu1' suffix to the version
> >>>number from unstable as they're basically backports of the package
> >>>from unstable.
> >>> *) Uploads of new upstream releases that were not packaged for unstable
> >>>yet or will never be, should use the '1.2.3-0+debXu1' format (given
> >>>that '1.2.3' is the upstream version.
> >>
> >> That's the current practice, yes. As Salvatore pointed out, that's also 
> >> what the
> >> SRMs require for (old)stable uploads.
> >>
> >>> If we can agree on this, what would be the proper place to document it
> >>> for the future? Ideally, this should be mandatory for any uploads of new
> >>> upstream releases to the (old)?stable suites, be it to
> >>> (old)?stable-security, to stable-proposed-updates or to stable-updates.
> >>
> >> Probably the developers-reference, which already mentions the +debXuY 
> >> syntax in
> >> various places (including the security updates section, 5.8.5.4 [1]), but
> >> doesn't mention ~debXuY for the case of backports.
> > 
> > Right it is spread around on various sections both for stable updates
> > and as well for security updates. Would it make sense to maybe add a
> > new section for handling versioning for (old)?stable(-securit)?
> > udpates, and then reference from both the security bug handling and
> > the stable-updates handling to it?
> 
> Yes, I think that would make sense.
> 
> > I do not have a wording right now for dev-ref, but I can look if I can
> > come up with something during the weekend (keep in mind though that it
> > will in any case need review, I'm not a native english speaker).
> 
> Great! I'm not a native speaker either, but I'll happy to look at it.
> 
> Maybe cc debian-release@ with the patch 

Bug#852522: request-tracker4: contains conflicts/replaces with wrong package name rt4-authen-externalauth

[Tom Jampen]

Package: request-tracker4
Version: 4.4.1-2


Hi

rt4 version 4.4.1-2 contains a conflicts/replaces entry for
rt4-authen-externalauth

This is correct, but the package name is wrong, it should be
rt4-extension-authenexternalauth

The extension's source package:
rt-authen-externalauth

Regards,
Tom

Bug#852521: unicode-math now unable to process $\widetilde{\mathbf{a}}$

[Norbert Preining]

Hi Will,

(please keep Cc, thanks!)

Norbert here. Downstream at Debian, but it is the same in upstream TeX Live,
I got a bug report that the latest version of unicode-math does not work
properly with xelatex. The following minimal working example breaks
under xelatex:

\documentclass{article}
\usepackage{unicode-math}

\begin{document}
  $\widetilde{\mathbf{a}}$
\end{document}

With the following error:
Error message:
! Internal error: bad native font flag in `map_char_to_glyph'


Do you have an idea what might have triggered this?

All the best

Norbert

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

Bug#851946: Depending on libssl1.0-dev breaks PHP builds

[Paul Gevers]

Hi

On 01/24/17 23:39, Niels Thykier wrote:
>  * cacti-spine => Paul said he would fix that, so I assuming he got this

Done.

> I will file bugs for the above (cacti-spine being a possible exception)
> tomorrow - feel free to beat me to it. :)

So indeed not needed for cacti-spine.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#852521: texlive-latex-recommended: unicode-math now unable to process $\widetilde{\mathbf{a}}$

[James Tocknell]

Package: texlive-latex-recommended
Version: 2016.20170123-1
Severity: important

Something has changed in the latest version, such that the following MWE fails
to build:

\documentclass{article}
\usepackage{unicode-math}

\begin{document}
  $\widetilde{\mathbf{a}}$
\end{document}

Note that switching the order of the expression ($\mathbf{\widetilde{a}}$),
builds, but is missing the tilde.

Error message:
! Internal error: bad native font flag in `map_char_to_glyph'

Build log:
This is XeTeX, Version 3.14159265-2.6-0.6 (TeX Live 2016/Debian) (preloaded 
format=xelatex)
 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2016/03/31> patch level 3
Babel <3.9r> and hyphenation patterns for 5 language(s) loaded.
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/unicode-math/unicode-math.sty
(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty)
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex)
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def))
(/usr/share/texlive/texmf-dist/tex/latex/ucharcat/ucharcat.sty)
(/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty)
(/usr/share/texlive/texmf-dist/tex/latex/l3packages/l3keys2e/l3keys2e.sty)
(/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty
(/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
*
* fontspec warning: "tu-clash"
* 
* I have found the tuenc.def encoding definition file but the TU encoding is
* not defined by the LaTeX2e kernel; attempting to correct but you really
* should update to the latest version of LaTeX2e.
*
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
(/usr/share/texlive/texmf-dist/tex/latex/fontspec/tuenc.def)
(/usr/share/texlive/texmf-dist/tex/latex/fontspec/tulmr.fd)

LaTeX Font Warning: Font shape `TU/cmr/m/n' undefined
(Font)  using `TU/lmr/m/n' instead on input line 105.

) (/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
(/usr/share/texlive/texmf-dist/tex/latex/base/fix-cm.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.def))
(/usr/share/texlive/texmf-dist/tex/latex/filehook/filehook.sty)
(/usr/share/texlive/texmf-dist/tex/latex/unicode-math/unicode-math-xetex.sty
(/usr/share/texlive/texmf-dist/tex/latex/unicode-math/unicode-math-table.tex)))
(./test.aux)

test.fls:
PWD /home/aragilar/Scratch/test_latex
INPUT /home/aragilar/.tex/tex-config/web2c/texmf.cnf
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/xetex/xelatex.fmt
INPUT test.tex
OUTPUT test.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/unicode-math/unicode-math.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/unicode-math/unicode-math.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/UnicodeData.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/CaseFolding.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/SpecialCasing.txt
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/ucharcat/ucharcat.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/ucharcat/ucharcat.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3packages/l3keys2e/l3keys2e.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3packages/l3keys2e/l3keys2e.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty
INPUT 

Bug#818372: tex-common: Trigger fails on initial install of tex-common

[Martin Michlmayr]

* Norbert Preining  [2017-01-25 09:30]:
> Hmm, sounds not correct. The errors mentioned below can only happen
> with rather recent TeX Live as this was changed in TeX Live on Jan 14.

/var/log/dpkg.log suggests my last update was on 2016-11-10.

> > I haven't touched the chroot since then, so I can run further tests
> > for you.
> 
> I have a suspicion: My guess is that you have an *old* version of
> texlive-base installed, with a new version of texlive-lang-japanese.
> 
> Can you send me please:
> * versions of texlive-base and texlive-lang-japanese

texlive-base 2016.20161103-1
texlive-lang-japanese: 2016.20170123-1

> * output of 
>   updmap --version
>   (this should be
>   updmap version r42939 (2017-01-13 15:32:10 +0100)
>   )

updmap version r41566 (2016-06-29 18:04:35 +0200)

> I forgot to mention - I cannot reproduce this in a clean chroot,
> and from your list it seems that it was not clean, but
> texlive-base installed.

Correct, it was not a clean chroot.  It has a lot of stuff installed.

Note that this is different to Wookey's original report in which he
can a clean chroot.  Maybe I should have opened a new bug.  Feel free
to clone.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#851819: ERROR: wget failed to download http://people.debian.org/~bartm/...

[Matteo]

Package: flashplugin-nonfree
Version: 1:3.7
Followup-For: Bug #851819

Dear Maintainer,
When i try to update this package the system reply with an error!
*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
Debian version: 9.0
Architecture: amd64
Package version: 1:3.7
MD5 checksums:
29c85bc8504422120cf89702986ff8e1  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
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: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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.51.20161220-1
ii  ca-certificates20161130
ii  debconf [debconf-2.0]  1.5.59
ii  gnupg  2.1.17-2
ii  libatk1.0-02.22.0-1
ii  libcairo2  1.14.8-1
ii  libcurl3-gnutls7.52.1-1
ii  libfontconfig1 2.11.0-6.7
ii  libfreetype6   2.6.3-3+b1
ii  libgcc11:6.2.1-5
ii  libglib2.0-0   2.50.2-2
ii  libgtk2.0-02.24.31-1
ii  libnspr4   2:4.12-6
ii  libnss32:3.26.2-1
ii  libpango1.0-0  1.40.3-3
ii  libstdc++6 6.2.1-5
ii  libx11-6   2:1.6.4-2
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.5-1
ii  wget   1.18-4

flashplugin-nonfree recommends no packages.

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

-- no debconf information

Bug#852513: grub-efi-amd64: during configuration: "No space left on device"

[Norbert Preining]

Ok, here is the analysis:

> > Could not delete variable: No space left on device

The problem is with efibootmgr that cannot add new entries.

It turns out that there were incredible many entries in
/sys/fs/pstore
related to some dumps. I have removed all of them.

Also, the strace of efibootmgr gives:

open("/sys/firmware/efi/efivars/Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c", 
O_WRONLY|O_CREAT, 0644) = 3
ioctl(3, FS_IOC_GETFLAGS, 0x7ffc3470bba4) = 0
write(3, "\7\0\0\0\1\0\0\0h\0r\0E\0F\0I\0n\0d\0 \0B\0o\0o\0t\0"..., 
154) = -1 ENOSPC (No space left on device)
so I deleted also some very strange things "...dump..." (or so) in
that directory.

After a reboot efibootmgr now can add entries it seems and the installation
runs smoothly.

grub should/must detect whether the installation via efibootmgr
failed, otherwise it is completely useless.

Thanks

Norbert

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

Bug#815170: love: New upstream version available

[Markus Koschany]

By the way what happened with the demos and documentation of love? They
were once provided in separate tarballs but are apparently missing now.

Will love 0.10.2 work with mrrescue?




signature.asc
Description: OpenPGP digital signature

Bug#815170: love: New upstream version available

[Markus Koschany]

On 24.01.2017 09:06, Alexandre Detiste wrote:
> 2017-01-24 1:32 GMT+01:00 Markus Koschany :
>> Hi Alexandre,
>>
>> thanks for working on this package. I intend to sponsor it provided that
>> you push your upstream and pristine-tar branches as well!
> 
> I've pushed the upstream branch.
> I didn't used pristine-tar, as it wasn't used previously.
> 
> I've got the vague feeling the "dh_buildinfo" is something
> in statis not usefull anymore in regards to Reproducible Builds;
> but for now I left it there.

Hi,

I have pushed some minor changes to the Git repository but
debian/copyright is the major blocker and severely outdated. Several
licenses and copyright holders are missing. For instance see
src/libraries, Lintian will give you more hints. The package also cannot
be built twice in a row because the clean target is incomplete but that
could be fixed later. It is also rather suboptimal that love embeds so
many libraries like box2d or enet which are available in Debian. This
should be documented [1] and improved but it is not critical for Stretch.

If you can fix d/copyright today, we can still get 0.10.2 into Stretch
(provided that there are no other show-stoppers) but it would be too
late tomorrow.

Regards,

Markus


[1] https://wiki.debian.org/EmbeddedCodeCopies




signature.asc
Description: OpenPGP digital signature

Bug#852519: dms-core: fails to install: NZST FATAL: configuration file "/etc/postgresql/9.4/dms/postgresql.conf" contains errors

[Andreas Beckmann]

Package: dms-core
Version: 1.0.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

0m49.1s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpMPjZir', 
'apt-get', '-y', 'install', 'dms-core=1.0.2-1']
0m54.7s DUMP: 
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Suggested packages:
vim-nox vim nano
  Recommended packages:
less colordiff haveged netscript-ipfilter netscript-2.4 iptables-persistent
ntp strongswan racoon ike-server bind9-host dnsutils
  The following NEW packages will be installed:
dms-core
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 171 kB of archives.
  After this operation, 1238 kB of additional disk space will be used.
  Get:1 http://ftp.de.debian.org/debian/ jessie/main dms-core amd64 1.0.2-1 
[171 kB]
  debconf: delaying package configuration, since apt-utils is not installed
  Fetched 171 kB in 0s (9282 kB/s)
  Selecting previously unselected package dms-core.
  (Reading database ... 
(Reading database ... 11408 files and directories currently installed.)
  Preparing to unpack .../dms-core_1.0.2-1_amd64.deb ...
  Unpacking dms-core (1.0.2-1) ...
  Processing triggers for systemd (215-17+deb8u5) ...
  Setting up dms-core (1.0.2-1) ...
  Adding user `dmsdmd' to group `bind' ...
  Adding user dmsdmd to group bind
  Done.
  Adding user `dmsdmd' to group `dms' ...
  Adding user dmsdmd to group dms
  Done.
  Setting kernel variables ...done.
  Creating new cluster 9.4/dms ...
config /etc/postgresql/9.4/dms
data   /var/lib/postgresql/9.4/dms
locale C
port   5433
  dms_createdb: copying PG config files - DB admin is 'root'...
  dms_createdb: starting DB cluster dms...
  The PostgreSQL server failed to start. Please check the log output:
  2016-09-18 21:54:32 NZST LOG:  invalid value for parameter "lc_messages": 
"en_NZ.UTF-8"
  2016-09-18 21:54:32 NZST LOG:  invalid value for parameter "lc_monetary": 
"en_NZ.UTF-8"
  2016-09-18 21:54:32 NZST LOG:  invalid value for parameter "lc_numeric": 
"en_NZ.UTF-8"
  2016-09-18 21:54:32 NZST LOG:  invalid value for parameter "lc_time": 
"en_NZ.UTF-8"
  2016-09-18 21:54:32 NZST FATAL:  configuration file 
"/etc/postgresql/9.4/dms/postgresql.conf" contains errors
  Error: could not create dms cluster. Please create it manually with
  
  dms_createdb
  
  using the -f switch if required.
  grep: /etc/postgresql/9.3/dms/start.conf: No such file or directory
  invoke-rc.d: policy-rc.d denied execution of start.
  Processing triggers for systemd (215-17+deb8u5) ...
0m54.7s DEBUG: Command ok: ['chroot', '/tmp/piupartss/tmpMPjZir', 'apt-get', 
'-y', 'install', 'dms-core=1.0.2-1']


Despite this error no problem was signaled by the postinst script and
the apt command succeeded. I only noticed this problem now while
analyzing jessie->stretch upgrade failure tests.

Looks a bit like your package expects certain locales to be configured
which is not the case in a default installation. You'll have en_US.UTF-8
only. (BTW, there is a locales-all package ...)


cheers,

Andreas


dms-core_1.0.2-1.log.gz
Description: application/gzip

Bug#852518: python-mne: bootstrap.min.js corrupted when built with dash as /bin/sh

[Chris Lamb]

Source: python-mne
Version: 0.13.1+dfsg-1
Severity: serious
Tags: patch
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that python-mne generates an invalid bootstrap.min.js when built
with dash as /bin/sh.

With dash you get an extra "-e". Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index fa02162..4e5ac91 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,7 +19,7 @@ override_dh_clean:
 override_dh_auto_build:
dh_auto_build
yui-compressor debian/JS/bootstrap/bootstrap.js > 
$(CURDIR)/mne/html/bootstrap.min.js
-   echo -e "\n" >> $(CURDIR)/mne/html/bootstrap.min.js
+   printf "\n\n" >> $(CURDIR)/mne/html/bootstrap.min.js
 
 override_dh_auto_test:
mkdir -p build

Bug#852207: libfile-stripnondeterminism-perl: Breaks .zip with encrypted files

[Chris Lamb]

Hi Christoph,

> Here we go (I thought the instructions very straightforward).

Thanks! To make it easier for someone to have a go at this, check out
the "lamby/852207-encrypted-zip" branch where the testsuite is (now)
failing with this example.


Regards,

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

Bug#852493: Please enable Thunder NIC virtual function driver

[Ben Hutchings]

Control: tag -1 moreinfo

On Tue, 2017-01-24 at 22:13 +, Punit Agrawal wrote:
> Source: linux
> Severity: wishlist
> Tags: patch
> 
> While testing device passthrough with a debian guest on a Cavium
> Thunder, I found that the virtual function(VF) driver for the built in
> nic is not available.
> 
> Please enable CONFIG_THUNDER_NIC_VF in the debian kernel config.

So long as this hardware is part of specific SoCs, we should only
enable it for the CPU architectures used in those SoCs.  That's arm64,
right?  (Possibly also mips64, but we don't support Cavium MIPS SoCs at
all yet.)

Shouldn't we also enable CONFIG_THUNDER_NIC_{PF,BGX,RGX} along with
this?

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program than to understand a correct
one.


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

Bug#852517: strip-nondeterminism: Not running full testsuite on ci.debian.net

[Chris Lamb]

Package: strip-nondeterminism
Version: 0.029-2
Severity: normal

Hi,

It looks like the autopkgtests are misconfigured so we are not running
the full testsuite on ci.debian.net. See, for example:

  
https://ci.debian.net/data/packages/unstable/amd64/s/strip-nondeterminism/20170121_202634.autopkgtest.log.gz

Whilst we see:

  ok 1 - bin/dh_strip_nondeterminism --help returns 1
  ok 2 - bin/strip-nondeterminism --help returns 0

 … notice it is not running the (far more important!) fixture tests such
as t/fixtures/png/tEXt.png.in etc. etc.


Regards,

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

Bug#838441: Any update ?

[Julian Andres Klode]

On Sun, Jan 15, 2017 at 10:56:03AM +0100, Julian Andres Klode wrote:
> Control: severity -1 normal
> 
> On Sun, Jan 15, 2017 at 09:57:44AM +0100, Guillaume Betous wrote:
> > Hi, any update on this issue ? I'm still facing it since months now.
> 
> First of all: Write a useful email with some context, this one is about
> 
>  apt-get update fails with "Hash Sum mismatch", mixes hashes between tar.gz 
> and tar file
> 
> And no, there is no update on this. I certainly run proxies a lot
> of the time and I have not seen this issue once. This really is a tiny
> corner case somewhere.

Reproducer attached. Extract and run
  APT_CONFIG=rootdir/apt.conf apt update
in the directory you extracted it to.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.


rootdir.tar.gz
Description: application/gzip

Bug#852516: request-tracker4: prompting due to modified conffiles which were not modified by the user: /etc/request-tracker4/RT_SiteConfig.pm

[Andreas Beckmann]

Package: request-tracker4
Version: 4.4.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

This was observed during an upgrade from stretch to sid.

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

  Setting up request-tracker4 (4.4.1-2) ...
  
  Configuration file '/etc/request-tracker4/RT_SiteConfig.pm'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** RT_SiteConfig.pm (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing 
package request-tracker4 (--configure):
   end of file on stdin at conffile prompt
  Processing triggers for libc-bin (2.24-9) ...
  Errors were encountered while processing:
   request-tracker4


cheers,

Andreas


request-tracker4_4.4.1-2.log.gz
Description: application/gzip

Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Jason Heeris]

I'm going to try to dig into this and see if I can fix it. But if anyone
knows off the top of their head where a likely place to start looking would
be, please let me know. Otherwise I'll start with the bootstrap scripts.

- Jason

Bug#852515: python-flask-limiter-doc: overwrites files from python-limits-doc: /usr/share/doc/python-limits-doc/html/_modules/index.html

[Andreas Beckmann]

Package: python-flask-limiter-doc
Version: 0.9.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

My guess is a copy+paste error while copying the packaging from
python-limits-doc.

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

  Selecting previously unselected package python-flask-limiter-doc.
  Preparing to unpack .../python-flask-limiter-doc_0.9.3-1_all.deb ...
  Unpacking python-flask-limiter-doc (0.9.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-flask-limiter-doc_0.9.3-1_all.deb (--unpack):
   trying to overwrite 
'/usr/share/doc/python-limits-doc/html/_modules/index.html', which is also in 
package python-limits-doc 1.2.1-1
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python-flask-limiter-doc_0.9.3-1_all.deb


cheers,

Andreas


python-limits-doc=1.2.1-1_python-flask-limiter-doc=0.9.3-1.log.gz
Description: application/gzip

Bug#852514: libpetsc3.7-dev: leaves alternatives after purge: /usr/lib/petscdir/{3.7, 3.7-real}

[Andreas Beckmann]

Package: libpetsc3.7-dev
Version: 3.7.5+dfsg1-3
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

The leftover files are actually alternatives that were installed by the
package but have not been properly removed.

This was observed after a stretch->sid upgrade, the packages in stretch
and sid itself work fine. Therefore I assume you obsoleted some
alternative in the sid package. To clean this up, you should unregister
the obsolete alternative in the postinst script.

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

2m18.4s INFO: Warning: Package purging left files on system:
  /etc/alternatives/petsc3.7 -> /usr/lib/petscdir/3.7.4/x86_64-linux-gnu-real   
 not owned
  /etc/alternatives/petsc3.7-real -> 
/usr/lib/petscdir/3.7.4/x86_64-linux-gnu-real   not owned
  /usr/lib/petscdir/ owned by: libpetsc3.7.5-dev:amd64, 
libpetsc3.7.4-dev:amd64
  /usr/lib/petscdir/3.7 -> /etc/alternatives/petsc3.7not owned
  /usr/lib/petscdir/3.7-real -> /etc/alternatives/petsc3.7-real  not owned


cheers,

Andreas


libpetsc3.7-dev_3.7.5+dfsg1-3.log.gz
Description: application/gzip

Bug#852513: grub-efi-amd64: during configuration: "No space left on device"

[Norbert Preining]

severity 852513 grave
retitle 852513 updated renders system unbootable
thanks

On Wed, 25 Jan 2017, Norbert Preining wrote:
> on today's upgrade to grub 2.02~beta3-4 I was greeted with the following
> scary output:
>   Setting up grub-efi-amd64 (2.02~beta3-4) ...
>   Installing for x86_64-efi platform.
>   Could not delete variable: No space left on device
>   Could not prepare Boot variable: No space left on device
>   Installation finished. No error reported.
> which does not sound inviting.

And indeed, the system boots directly into Windows and everything 
is messed up.

That is very unfortunate.

Norbert

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

Bug#852513: grub-efi-amd64: during configuration: "No space left on device"

[Norbert Preining]

Package: grub-efi-amd64
Version: 2.02~beta3-4
Severity: important


Hi all,

on today's upgrade to grub 2.02~beta3-4 I was greeted with the following
scary output:
Setting up grub-efi-amd64 (2.02~beta3-4) ...
Installing for x86_64-efi platform.
Could not delete variable: No space left on device
Could not prepare Boot variable: No space left on device
Installation finished. No error reported.
which does not sound inviting.

My file systems are at max 70% filled, so that cannot be a real problem.

All the best

Norbert


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/main-root / btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
/dev/sda5 /boot ext4 rw,relatime,stripe=4,data=ordered 0 0
/dev/sda3 /xp fuseblk 
rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 
--hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  
9d770d9e-e9fc-4aa9-8682-20d84acb56ab
else
  search --no-floppy --fs-uuid --set=root 9d770d9e-e9fc-4aa9-8682-20d84acb56ab
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 
--hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  
9d770d9e-e9fc-4aa9-8682-20d84acb56ab
else
  search --no-floppy --fs-uuid --set=root 9d770d9e-e9fc-4aa9-8682-20d84acb56ab
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-8c7c2c12-3c0f-487e-96cb-aca13bf54115' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 
--hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  
9d770d9e-e9fc-4aa9-8682-20d84acb56ab
else
  search --no-floppy --fs-uuid --set=root 
9d770d9e-e9fc-4aa9-8682-20d84acb56ab
fi
echo'Loading Linux 4.10.0-rc5+ ...'
linux   /vmlinuz-4.10.0-rc5+ root=/dev/mapper/main-root ro  
echo'Loading initial ramdisk ...'
initrd  /initrd.img-4.10.0-rc5+
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-8c7c2c12-3c0f-487e-96cb-aca13bf54115' {
menuentry 'Debian GNU/Linux, with Linux 4.10.0-rc5+' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 

Bug#852512: python-django: Please avoid accessing the internet for intersphinx mapping

[Chris Lamb]

Package: python-django
Version: 1:1.10.5-1
Severity: wishlist
User: la...@debian.org
Usertags: network-access

Hi,

  $ grep "loading intersphinx" python-django_1.11\~alpha1-1_amd64.build
  loading intersphinx inventory from https://docs.python.org/3/objects.inv...
  loading intersphinx inventory from 
http://initd.org/psycopg/docs/objects.inv...
  loading intersphinx inventory from 
https://django-formtools.readthedocs.io/en/latest/objects.inv...
  loading intersphinx inventory from https://pythonhosted.org/six/objects.inv...
  loading intersphinx inventory from http://sphinx-doc.org/objects.inv...

(Okay, that's technically from 1.11~alpha1 (awaiting upload) rather than
1:1.10.5-1, but it's likely the same)

This is caused by:

   intersphinx_mapping = {
  'python': ('https://docs.python.org/3/', None),
  'sphinx': ('http://sphinx-doc.org/', None),
  'six': ('https://pythonhosted.org/six/', None),
  'formtools': ('https://django-formtools.readthedocs.io/en/latest/', None),
  'psycopg2': ('http://initd.org/psycopg/docs/', None),
  }

in docs/conf.py. To fix, see #830186, especially something like:

  http://sources.debian.net/src/psycopg2/2.6.2-1/debian/patches/local_inventory/

Regards,

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

Bug#852511: duply: FutureWarnings from python-crypto in stderr

[wxcafe]

Package: duply
Version: 1.9.1-1
Severity: normal

Hey,
In debian stable, python-crypto complains in stderr that duply is not
using it correctly :

/usr/lib/python2.7/dist-packages/Crypto/Cipher/blockalgo.py:141:
FutureWarning: CTR mode needs counter parameter, not IV

This is problematic for multiple reasons: first, if duply is supplying
an IV to a CTR mode cypher, something is clearly wrong. Secondly, it
writes a line for every duply job in stderr. I (like many others, I
guess) happen to be running duply in cron, on multiple machines. This
means for each cron run I get 4 emails from cron for each machine
telling me this error.

This is not ideal. The obvious fix would be to redirect stderr to stdout
and be done with it, except that if duply fails a backup I don't get an
email then.

I haven't checked if newer versions still do this, but I can try it on
testing if you want.

Thank you in advance for your help,

Clément Hertling


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, 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 duply depends on:
ii  duplicity  0.6.24-1
ii  gnupg  1.4.18-7+deb8u3

duply recommends no packages.

Versions of packages duply suggests:
ii  openssh-client  1:6.7p1-5+deb8u3

-- no debconf information

Bug#816781: aptitude: Can not cancel pending upgrade actions

[Drew Parsons]

On Sat, 5 Mar 2016 14:36:00 + "Manuel A. Fernandez Montecelo"  wrote:
> 
> I think that it's better to leave it open for a while in the case
that
> people find the same problem.
> 


It certainly confused and frustrated me.  I vote for changing the text
of the option in some way, in order to signal that there's been a
change in behaviour.


Drew

Bug#818372: tex-common: Trigger fails on initial install of tex-common

[Norbert Preining]

> (sid-armel)root@m400-c2n1:/# apt-get build-dep debian-history

I forgot to mention - I cannot reproduce this in a clean chroot,
and from your list it seems that it was not clean, but 
texlive-base installed.

Norbert

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

Bug#852510: transmission-remote-gtk: auto-resize columns at every restart

[Sandro Tosi]

Package: transmission-remote-gtk
Version: 1.3.1-2
Severity: important

This is has changed between 1.1.1 and 1.3.1 - now every time you start t-r-g it
resizes the columns witdh even if they were adjusted at the previous executions.

this is a really irritating behavior as if i have a very long torrent name, that
takes up all the display space.

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

Versions of packages transmission-remote-gtk depends on:
ii  libc6   2.23-4
ii  libcurl37.45.0-1+b1
ii  libgdk-pixbuf2.0-0  2.32.2-1
ii  libglib2.0-02.46.2-1
ii  libgtk-3-0  3.20.5-4
ii  libjson-glib-1.0-0  1.0.4-2
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.38.1-1
ii  libproxy1v5 0.4.11-4.2

transmission-remote-gtk recommends no packages.

transmission-remote-gtk suggests no packages.

-- no debconf information

Bug#852502: openslide-python: FTBFS (failing tests)

[Benjamin Gilbert]

The problem is in Pillow, 3.4.0 through 3.4.2.  I have a workaround for the
OpenSlide Python test suite that I'll get committed and then post here.

Bug#818372: tex-common: Trigger fails on initial install of tex-common

[Norbert Preining]

Hi Martin,

> I just ran into a similar problem.  I tried to install the
> build-depends for debian-history in an armel chroot.  The chroot is
> unstable but probably out-of-date by a few weeks.

Hmm, sounds not correct. The errors mentioned below can only happen
with rather recent TeX Live as this was changed in TeX Live on Jan 14.

> I haven't touched the chroot since then, so I can run further tests
> for you.

I have a suspicion: My guess is that you have an *old* version of
texlive-base installed, with a new version of texlive-lang-japanese.

Can you send me please:
* versions of texlive-base and texlive-lang-japanese
* output of 
updmap --version
  (this should be
updmap version r42939 (2017-01-13 15:32:10 +0100)
  )

My guess is that I need stricter dependencies on texlive-base from
texlive-lang-japanese.

This is only a problem for upgrades sid -> sid, but not from
stable -> sid/testing as the deps are basically 
"use anything 2016 like".

Thanks

Norbert

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

Bug#852509: tightvncserver: much reduced performance and wrong colours since tigervnc switch

[Thorsten Glaser]

Package: tightvncserver
Version: 1.3.9+t-1
Severity: important

Hi,

ever since the switch to the tigervnc server implementation, when
accessing a VNC server over the network (client is TightVNC viewer
version 1.2.7 on MirBSD), I’m observing wrong colours (for example,
Firefox® menu bar has a blue background, scroll bar is also all
wrong where it previously was Motif themed grey) and *much* reduced
performance (not only in Firefox®, also, PDF scrolling in mupdf is
so laggy it’s virtually unusable).

The client has a roughly 5000/700 kbit/s line, the server has much
better network access; vncviewer’s -via (SSH tunnel) is used, and
one VPN and two IPv6 tunnels are in use, although this was never a
problem before, so I don’t see why a worse implementation should be
shoved down my throat now (especially not short before the freeze).


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

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages tightvncserver depends on:
ii  tigervnc-standalone-server  1.7.0+dfsg-2

tightvncserver recommends no packages.

tightvncserver suggests no packages.

-- no debconf information

Bug#850060: Boot from iSCSI patches

[Andrew Patterson]

Here is another set of patches to get boot from iSCSI working on
debian with bnx2x devices. They are:

* Revert "Don't ignore offloading NICs in iscsistart."
* Check for the presence of /sbin/iscsiuio before using hardware
  offload for bnx2x devices.
* Move iscsistart offload discovery/setup to fw_get_targets()
* Fix broken long command-line options in iscsiuio.

I have tested these patches using bnx2x devices configured as both
software initiators and using hardware offload.

-- 
Andrew Patterson
Hewlett-Packard Enterprise
>From 17b79c2a25a9ba5a105661f49bf435148ff30277 Mon Sep 17 00:00:00 2001
From: Andrew Patterson 
Date: Tue, 17 Jan 2017 10:25:37 -0700
Subject: [PATCH 4/7] Revert "Don't ignore offloading NICs in iscsistart."

This reverts commit 02c3051a7718dc26c71bd682da1f8d44358ffa96.
---
 .../iscsistart-offloading-interfaces.patch | 24 --
 debian/patches/series  |  1 -
 2 files changed, 25 deletions(-)
 delete mode 100644 debian/patches/bugfixes/iscsistart-offloading-interfaces.patch

diff --git a/debian/patches/bugfixes/iscsistart-offloading-interfaces.patch b/debian/patches/bugfixes/iscsistart-offloading-interfaces.patch
deleted file mode 100644
index d9a383c..000
--- a/debian/patches/bugfixes/iscsistart-offloading-interfaces.patch
+++ /dev/null
@@ -1,24 +0,0 @@
-Description: Don't ignore offloading NICs in iscsistart
-Author: Christian Seiler 
-Bug: https://groups.google.com/forum/?_escaped_fragment_=msg/open-iscsi/PsT65Z4Gx3I/GUObdlVvCQAJ#!msg/open-iscsi/PsT65Z4Gx3I/GUObdlVvCQAJ
-Bug-Debian: https://bugs.debian.org/850057
-Last-Update: 2017-01-04

-This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 a/utils/fwparam_ibft/fw_entry.c
-+++ b/utils/fwparam_ibft/fw_entry.c
-@@ -65,10 +65,14 @@ int fw_setup_nics(void)
- 	 * to force iSCSI traffic through correct NIC
- 	 */
- 	list_for_each_entry(context, , list) {			
-+		/* Debian: don't ignore offload NICs here, see Debian
-+		 * bug #850057 for details. */
-+#if 0
- 		/* if it is a offload nic ignore it */
- 		if (!net_get_transport_name_from_netdev(context->iface,
- 			transport))
- 			continue;
-+#endif
- 
- 		if (iface_prev == NULL || strcmp(context->iface, iface_prev)) {
- 			/* Note: test above works because there is a
diff --git a/debian/patches/series b/debian/patches/series
index a109715..6a2a532 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,4 +2,3 @@ bugfixes/no-make-clean-kernel.patch
 debian/var-run-lock.patch
 debian/dont-link-against-openssl.patch
 debian/udeb-without-libmount.patch
-bugfixes/iscsistart-offloading-interfaces.patch
-- 
2.8.0.rc3

>From 1f6a5beb286a03fbba82da053f648f9c52c721c5 Mon Sep 17 00:00:00 2001
From: Andrew Patterson 
Date: Thu, 19 Jan 2017 15:26:48 -0700
Subject: [PATCH 5/7] iscsiuio must be present to use hardware offload for
 bnx2x

Check for the presence of /sbin/iscsiuio before using hardware offload
for bnx2x devices.
---
 .../need_iscsiuio_for_hardware_offload.patch   | 48 ++
 debian/patches/series  |  1 +
 2 files changed, 49 insertions(+)
 create mode 100644 debian/patches/bugfixes/need_iscsiuio_for_hardware_offload.patch

diff --git a/debian/patches/bugfixes/need_iscsiuio_for_hardware_offload.patch b/debian/patches/bugfixes/need_iscsiuio_for_hardware_offload.patch
new file mode 100644
index 000..0bb0d57
--- /dev/null
+++ b/debian/patches/bugfixes/need_iscsiuio_for_hardware_offload.patch
@@ -0,0 +1,48 @@
+Description: iscsiuio must be present to use hardware offload for bnx2x
+Author: Andrew Patterson 
+Bug: https://groups.google.com/forum/?_escaped_fragment_=msg/open-iscsi/PsT65Z4Gx3I/GUObdlVvCQAJ#!msg/open-iscsi/PsT65Z4Gx3I/GUObdlVvCQAJ
+Bug-Debian: https://bugs.debian.org/850057
+Last-Update: 2017-01-24
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/include/iscsi_net_util.h
 b/include/iscsi_net_util.h
+@@ -2,6 +2,7 @@
+ #define __ISCSI_NET_UTIL_h__
+ 
+ #define ISCSI_HWADDRESS_BUF_SIZE 18
++#define ISCSIUIO_PATH "/sbin/iscsiuio"
+ 
+ extern int net_get_transport_name_from_netdev(char *netdev, char *transport);
+ extern int net_get_netdev_from_hwaddress(char *hwaddress, char *netdev);
+--- a/usr/iscsi_net_util.c
 b/usr/iscsi_net_util.c
+@@ -27,6 +27,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -81,6 +82,20 @@
+ 		goto close_sock;
+ 	}
+ 
++	/*
++	 * iSCSI hardware offload for bnx2x is only supported if the
++	 * iscsiuio executable is available.
++	 */
++	if (!strcmp(drvinfo.driver, "bnx2x")) {
++		struct stat buf;
++
++		if (stat(ISCSIUIO_PATH, )) {
++			log_debug(1, "ISCSI offload not supported.");
++			err = ENODEV;
++			goto close_sock;
++		}
++	}
++
+ 	for (i = 0; net_drivers[i].net_drv_name != NULL; i++) {
+ 		struct iscsi_net_driver *net_driver = 

Bug#850828: New .symbols file

[Eriberto]

Hi Hilko,

Sorry for my delay. I had some problems in my work.


2017-01-19 9:37 GMT-02:00 Hilko Bengen :
> Hi Eriberto,
>
> I see that you have simply marked many symbols optional instead of
> splitting the .symbols file. Please reconsider that decision.
>
> You approach works in the sense that the package no longer fails to
> build on architectures where not all defined symbols aren't present.
> However, there are few subtle problems with this. On 32bit
> architectures, many symbols that are not defined in the .symbols file
> get added automatically. Those symbols are then annotated with the wrong
> default version number.
>
> Example from the current i386 build log[1]:
>
> While a symbol is removed without causing an error because it has been
> declared optional, another symbol for the equivalent function is added,
> but with a different version number:
>
> - (optional|c++)"TskDbSqlite::getFsInfos(long, std::vector<_TSK_DB_FS_INFO, 
> std::allocator<_TSK_DB_FS_INFO> >&)@Base" 4.3.0
>   [...]
> + _ZN11TskDbSqlite10getFsInfosExRSt6vectorI15_TSK_DB_FS_INFOSaIS1_EE@Base 
> 4.3.1
>
> This is the demangled version of the added symbol:
>
> TskDbSqlite::getFsInfos(long long, std::vector<_TSK_DB_FS_INFO, 
> std::allocator<_TSK_DB_FS_INFO> >&)@Base
>
> The second symbol represents the same function as the first; on 32bit
> architectures the C++ compiler (or rather the preprocessor) replaces the
> first argument type "int64_t" with "long long" instead of "long" ... and
> thus name mangling produces a different symbol.


Ok. I can see the problem here. However, I can't have time (because
the freeze stage) to do tests (I need tests to understand better the
process to split these symbols, uploading to experimental before
unstable). So, I think that the best way is remove all optional
entries and improve it after freeze. I will start to package the 4.4
upstream version now.


> The version number is important because dpkg-shlibdeps uses it to infer
> the automatic dependencies it generates for ${shlibs:Depends}. Building
> a different package that uses only a subset of the libtsk functions
> would get a "libtsk13 (>= 4.3.0)" dependency on some architectures while
> the same package might get a "libtsk13 (>= 4.3.1)" dependency on other
> architectures. This is clearly broken.
>
> Normally, the added version number would even contain the Debian
> revision which would get marked as an error by Lintian for half of the
> architectures. This does not happen because you added an override for
> the version number (override_dh_makeshlibs), thereby hiding the actual
> problem.

Ok. I can change version to 4.3.0 instead of use the
dpkg-parsechangelog command. I will do it.


> Cheers,
> -Hilko
>
> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=sleuthkit=i386=4.3.1-5=1484596774=0


Cheers,

Eriberto

Bug#852451: ITP: rname -- invoke a program under a different name

[Clint Adams]

On Tue, Jan 24, 2017 at 05:24:37PM +0100, Christian Seiler wrote:
> (The shell needs to be bash, mksh, zsh or similar to work; dash and
> others don't support -a for exec.)

In zsh you can just use the built-in functionality, f.ex.

ARGV0=arp busybox

Bug#852266: also mention APT::AutoRemove::RecommendsImportant

[積丹尼 Dan Jacobson]

MAFM> APT::AutoRemove::RecommendsImportant is not appropriate in this
MAFM> explanation, unless one wants to be exhaustive and list all of the
MAFM> possible situations in which the autoremoval is considered, which is not

You do. You say "More precisely":
"More precisely: they will be removed when there is no path via Depends,
PreDepends, or Recommends to them from a manually installed package."

So the user thinks they have finally got the whole picture.

Bug#852436: cups-browsed uses 100% CPU

[Till Kamppeter]

Thank you for the log file.

The high load was probably caused by cups-browsed repeatedly creating 
local queues for the discovered remote queues as it did not recognize 
that the queues were already successfully generated.


I have corrected the error checking now to interpret the resulting IPP 
status codes correctly as success or error. This I have done on the 
upstream BZR repository, rev. 7601.


The lines in the log file leading to this assumptions are:

Tue Jan 24 14:49:52 2017 Unable to create/modify CUPS queue (Success)!

which appear several times. cups-browsed considered the operation having 
errored, therefore outputting this line. In the parantheses the last 
error string of the operating system is inserted, which is "Success" 
meaning that the system did not see any error here.


   Till

Bug#852271: aptitude --without-recommends documentation correction

[積丹尼 Dan Jacobson]

That my new version looks like an older version is just a coincidence.
I want you to change it to say

>> The man page needs to be changed to say
>>
>> -R, --without-recommends
>> Do not treat recommendations as dependencies when installing new
>> packages (this overrides settings in /etc/apt/apt.conf and
>> ~/.aptitude/config). Packages previously installed due to
>> recommendations will not be removed unless
>> APT::AutoRemove::RecommendsImportant is false.
>>
>> This corresponds to the configuration option
>> APT::Install-Recommends.

-R doesn't "correspond" to two things. You need to separate them as I do.

Bug#851520: not fixed yet, patch provided

[Ghislain Vaillant]

control: reopen -1 =

Hi Pietro,

This issue is not fixed yet.

I am providing a patch which should fix this for good. The version
number is normalized to 1.2.0 (dropping the .dev suffix), which matches
the version number found in version.py from the PyPI tarball.

Please consider applying it.

Thanks,
GhisFrom 09f7d483dacfd03c5acc14fe2a0bb318a6832b9b Mon Sep 17 00:00:00 2001
From: Ghislain Antony Vaillant 
Date: Tue, 24 Jan 2017 23:44:41 +
Subject: [PATCH] Fix normalization of version number

Update patch 0001_normalize_version.patch

Gbp-Dch: full
---
 debian/patches/0001_normalize_version.patch | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/patches/0001_normalize_version.patch b/debian/patches/0001_normalize_version.patch
index d259d26..1c6fff3 100644
--- a/debian/patches/0001_normalize_version.patch
+++ b/debian/patches/0001_normalize_version.patch
@@ -7,11 +7,11 @@ Bug-Ubuntu: https://launchpad.net/bugs/
 Forwarded: not-needed
 Last-Update: 2017-01-18
 
 bottleneck-1.2.0.orig/bottleneck/version.py
-+++ bottleneck-1.2.0/bottleneck/version.py
+--- a/bottleneck/version.py
 b/bottleneck/version.py
 @@ -1,4 +1,4 @@
  "Bottleneck version"
  
  # Format expected by setup.py and doc/source/conf.py: string of form "X.Y.Z"
 -__version__ = "1.2.0dev"
-+__version__ = "1.2.0.dev"
++__version__ = "1.2.0"
-- 
2.11.0

Bug#852508: lolcat: Please package lolcat v42.24.0 which was released about a month back.

[shirish शिरीष]

Package: lolcat
Version: 42.0.99-1
Severity: wishlist

Dear Maintainer,
Please package the latest release of lolcat released approx. a month
ago. See https://github.com/busyloop/lolcat/releases for more. Diff.
would be from August 11, 2011 when v42.0.99 was released to v42.24.0
which was released approx. a month ago.

https://github.com/busyloop/lolcat/archive/v42.24.0.tar.gz for the actual file.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (1, 'experimental-debug'), (1, 'experimental'), (1,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-1-amd64 (SMP w/2 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 lolcat depends on:
ii  ruby  1:2.3.3
ii  ruby-paint0.8.6-2
ii  ruby-trollop  2.0-2

lolcat recommends no packages.

lolcat suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#852507: mame: FTBFS[kfreebsd]: wrong path for dirent.h

[Steven Chamberlain]

Source: mame
Version: 0.181-1
Tags: upstream patch
X-Debbugs-Cc: debian-...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: kfreebsd

Hi!

mame/0.181-1 FTBFS on kfreebsd-* because:

| Compiling 3rdparty/bgfx/3rdparty/ocornut-imgui/imgui.cpp...
| In file included from 
../../../../../3rdparty/bgfx/3rdparty/ocornut-imgui/widgets/file_list.inl:2:0,
|  from 
../../../../../3rdparty/bgfx/3rdparty/ocornut-imgui/imgui_user.inl:75,
|  from 
../../../../../3rdparty/bgfx/3rdparty/ocornut-imgui/imgui.cpp:9799:
| ../../../../../3rdparty/bx/include/compat/freebsd/dirent.h:1:24: fatal error: 
sys/dirent.h: No such file or directory

Attached is a simple patch for this.  It is similar to two other fixes
already applied upstream.  I'll take responsibility for upstreaming this
(in "bx" and then in mame).

My patch fixes only the issue described above.  I don't know yet if this
is the *only* reason for FTBFS because I'm still building it on falla.

Thanks!
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/3rdparty/bx/include/compat/freebsd/dirent.h b/3rdparty/bx/include/compat/freebsd/dirent.h
index b4f586b..5f52d2d 100644
--- a/3rdparty/bx/include/compat/freebsd/dirent.h
+++ b/3rdparty/bx/include/compat/freebsd/dirent.h
@@ -1 +1,5 @@
-#include 
+#if defined(__GLIBC__)
+#   include_next 
+#else
+#   include 
+#endif


signature.asc
Description: Digital signature

Bug#852506: Command-line option to import file

[martin f krafft]

Package: gscan2pdf
Version: 1.6.0-3
Severity: wishlist

I'm aware that gscan2pdf is not a PDF editor per se, but it does an
amazing job, splitting out pages, allowing me easy access to
per-page manipulation tools like unpaper and Gimp, and providing
a means to save subsets of pages into PDFs. I use it for scanning
all the time, but sometimes I get PDFs in the mail and I'd *really*
love to be able to just import them directly into gscan2pdf and
process them like I would with a scan.

Please consider adding a command-line option such as --import-all
that takes a PDF file and then simply imports all the pages therein
into a new gscan2pdf session. Another option --import could first
display the dialog to select the page range.

Thanks!

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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.7.0+dfsg-2
ii  imagemagick-6.q16 [imagemagick]8:6.9.7.0+dfsg-2
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1
ii  libfilesys-df-perl 0.92-6+b1
ii  libgoo-canvas-perl 0.06-2+b3
ii  libgtk2-ex-simple-list-perl0.50-2
ii  libgtk2-imageview-perl 0.05-2+b3
ii  libhtml-parser-perl3.72-3
ii  libimage-magick-perl   8:6.9.7.0+dfsg-2
ii  liblist-moreutils-perl 0.416-1+b1
ii  liblocale-gettext-perl 1.07-3+b1
ii  liblog-log4perl-perl   1.48-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b3
ii  libpdf-api2-perl   2.030-1
ii  libproc-processtable-perl  0.53-2
ii  libreadonly-perl   2.050-1
ii  librsvg2-common2.40.16-1
ii  libsane-perl   0.05-2+b4
ii  libset-intspan-perl1.19-1
ii  libtiff-tools  4.0.7-4
ii  libtry-tiny-perl   0.27-1
ii  sane-utils 1.0.26~git20151121-1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin  3.5.27.1-7
ii  gocr   0.49-2
pn  libgtk2-ex-podviewer-perl  
ii  sane   1.0.14-11
ii  tesseract-ocr  3.04.01-5
ii  unpaper6.1-2
ii  xdg-utils  1.1.1-1

gscan2pdf suggests no packages.

-- debconf-show failed


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


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

Bug#852505: linux-image-4.8.0-2-amd64: Realtek Ethernet controller vanishes on reboot

[Andrea Zuccherelli]

Package: src:linux
Version: 4.8.15-2
Severity: normal
Tags: upstream

Dear Maintainer,

The Ethernet controller RTL8105e in my Toshiba C660 notebook had a very strange 
behaviour.
It worked once but not after, being not even seen by BIOS for LAN boot on next 
reboot.
A hardware issue?

I disabled the controller in Debian "interfaces" file so that it was not 
configured.
Doing this the problem was solved: the device appeared on every boot, but it 
was unusable as it was down.
Then after boot up I manually configured the device, used and then disabled it:

root@zbox:~# ip addr add 192.168.0.2/24 dev lan0
root@zbox:~# ip link set dev lan0 up
root@zbox:~# ping 192.168.69.254
PING 192.168.69.254 (192.168.69.254) 56(84) bytes of data.
64 bytes from 192.168.69.254: icmp_seq=1 ttl=64 time=1.37 ms
64 bytes from 192.168.69.254: icmp_seq=2 ttl=64 time=1.04 ms
^C
--- 192.168.69.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.044/1.210/1.376/0.166 ms

root@zbox:~# ip link set dev lan0 down
root@zbox:~# modprobe -r r8169

But after a reboot/poweroff the controller again was not there.
Enabling/disabling WOL in BIOS, disabling link auto-negotiation and WOL using 
ethtool... There was no way.
Searching for a solution I found that only a PCI reset, after unloading the 
driver could help:

root@zbox:~# echo 1 >/sys/bus/pci/devices/:01:00.0/reset

So I added this to my "post-down" interface configuration.

Obviously this is just a workaround: so what is happening here?
Is my hardware not resetting the PCI bus on an ACPI poweroff event?
Should the kernel or driver do it?
Where is the best place to force a device PCI reset so that no problem could 
arise on hibernate/suspend?


Best regards

Andrea Zuccherelli



-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20161202 (Debian 5.4.1-4) ) #1 SMP Debian 4.8.15-2 (2017-01-04)

** Command line:
BOOT_IMAGE=/vmlinuz-4.8.0-2-amd64 
root=UUID=5a0b32cc-2aaf-4c3f-a33a-425168aab3e7 ro intel_pstate=disable 
pcie_aspm=force "acpi_osi=Windows 2009" "acpi_os_name=Windows 2009"

** Not tainted

** Kernel log:
[0.00] microcode: microcode updated early to revision 0x4, date = 
2013-06-28
[0.00] Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org) 
(gcc version 5.4.1 20161202 (Debian 5.4.1-4) ) #1 SMP Debian 4.8.15-2 
(2017-01-04)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.8.0-2-amd64 
root=UUID=5a0b32cc-2aaf-4c3f-a33a-425168aab3e7 ro intel_pstate=disable 
pcie_aspm=force "acpi_osi=Windows 2009" "acpi_os_name=Windows 2009"
[0.00] Disabled fast string operations
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbb30efff] usable
[0.00] BIOS-e820: [mem 0xbb30f000-0xbb690fff] reserved
[0.00] BIOS-e820: [mem 0xbb691000-0xbb69efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbb69f000-0xbb6a1fff] reserved
[0.00] BIOS-e820: [mem 0xbb6a2000-0xbb6a4fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbb6a5000-0xbb6acfff] reserved
[0.00] BIOS-e820: [mem 0xbb6ad000-0xbb6ccfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbb6cd000-0xbb70efff] reserved
[0.00] BIOS-e820: [mem 0xbb70f000-0xbb70] ACPI NVS
[0.00] BIOS-e820: [mem 0xbb71-0xbb714fff] reserved
[0.00] BIOS-e820: [mem 0xbb715000-0xbb718fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbb719000-0xbb719fff] reserved
[0.00] BIOS-e820: [mem 0xbb71a000-0xbb71afff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbb71b000-0xbb71efff] reserved
[0.00] BIOS-e820: [mem 0xbb71f000-0xbb79efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbb79f000-0xbb7fefff] ACPI data
[0.00] BIOS-e820: [mem 0xbb7ff000-0xbb7f] usable
[0.00] BIOS-e820: [mem 0xbb80-0xbbff] reserved
[0.00] BIOS-e820: [mem 0xbde0-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed13fff] reserved
[0.00] BIOS-e820: [mem 0xfed16000-0xfed16fff] reserved
[0.00] BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved
[

Bug#852019: [pkg-gnupg-maint] Bug#852019: gpgv: unknown type of key resource 'trustedkeys.kbx'

[Daniel Kahn Gillmor]

On Tue 2017-01-24 15:13:29 -0500, Antoine Beaupré wrote:
>> I suspect that the problem with the listed file is that it doesn't
>> exist.  i don't have that file either, and i don't plan to -- that file
>> is treated by gpgv as a curated keyring; if you put something in it,
>> gpgv will decide that that key can be relied on to make signatures in
>> general.
>
> If no one ise going to use that file on a regular basis - maybe its
> absence shouldn't generate a worrisome "General error"...

I agree, it would be better to have clearer error messages.  I've just
recorded this upstream with:

   https://bugs.gnupg.org/gnupg/issue2932

> Maybe this is simply a usability bug in devscripts/dget/dscverify.

It sounds to me like there are several usability improvements that could
be added to that toolchain for this purpose.  Maybe you want to reopen
this bug and reassign it there as a wishlist?

>> I was considering whether to mark it as "normal" and tag it with
>> "moreinfo", but i think this report just describes confusion about what
>> the tools are supposed to do, so i'm going ahead and closing the report
>> directly.  The tools are all behaving as documented, from what i can
>> tell.  Please feel free to reopen if i've misunderstood, or if there are
>> specific changes that you think should be made that don't involve
>> breaking existing API.
>
> Well, I don't want to get into a reopening argument. If this is just me,
> we can move on.

It's not a "reopening argument" -- if there are existing tools that can
behave better without breaking their other use cases, it's not an
unreasonable request.  I just don't see what you're asking for from
gpgv.  gpgv's goal is to provide a very clearly defined interface for
programmatic tools that do signature verification.  It shouldn't give
different results just because some key got added to your keyring
sometime, it expects an explicitly curated keyring.

That said, if you *want* to point gpgv explicitly to your pubring.kbx,
you can also do that without a problem, but you'll need to do that
explicitly.

> But it seems that one of the key issues in crypto is usability, and the
> messages here are mixed, at best, and utterly confusing for me, in this
> use case.
>
> I often try to sponsor packages for new people, and this confuses the
> hell out of me every time. ;)

maybe it'd be worthwhile to document what you think the workflow
*should* be and open wishlist reports against the relevant tools.  If
it's confusing to you, it's very likely confusing to many other people
too.

 --dkg


signature.asc
Description: PGP signature

Bug#852502: openslide-python: FTBFS (failing tests)

[Santiago Vila]

On Tue, Jan 24, 2017 at 10:53:05PM +, Santiago Vila wrote:
 
> If this is really a bug in one of the build-depends, please use reassign and 
> affects,
> so that this is still visible in the page for this package.

Note: It builds ok in unstable, so it is very likely that some
build-dependency is to blame for this.

Thanks.

Bug#852504: RFS: udfclient/0.8.7-1

[Pali Rohár]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: udfclient
   Version : 0.8.7-1
   Upstream Author : Reinoud Zandijk 
 * URL : http://www.13thmonkey.org/udfclient/
 * License : Clarified Artistic License
   Section : otherosfs

It builds those binary packages:

  udfclient  - userland implementation of the UDF filesystem

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/udfclient/udfclient_0.8.7-1.dsc

More information about udfclient can be obtained from 
http://www.13thmonkey.org/udfclient/.

Changes since the last upload:

 * New upstream release.

Regards,
 Pali Rohár


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

Bug#851955: Document 'verify'

[Tomasz Buchert]

Hey Guido,

heh, actually, we have this in git repo :). However, I've just noticed
that we missed the top mention of the command so I've added it. This will
be in the next release.

Thanks!
Tomasz


signature.asc
Description: PGP signature

Bug#269097: [Aptitude-devel] Processed: found 269097 in 0.8.4

[Axel Beckert]

Control: notfound -1 0.8.4
Control: found -1 0.8.4-1

Dear Jidanni,

Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > found 269097 0.8.4
[...]
> There is no source info for the package 'aptitude' at version '0.8.4' with 
> architecture ''
> Unable to make a source version for version '0.8.4'

the Debian BTS thinks in Debian uploads, not in upstream versions.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#852503: gthumb: Slideshow option from command line does nothing

[Frank McCormick]

Package: gthumb
Version: 3:3.3.1-2+b2
Severity: important

Dear Maintainer,

Running gthumb from the command line with -s for a slideshow does
nothing except spew a variety op GTK errors.

A slideshow is available when running full screen



-- System Information:
Debian Release: 8.7
  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_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 gthumb depends on:
ii  gsettings-desktop-schemas   3.14.1-1
ii  gthumb-data 3:3.3.1-2
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18+deb8u7
ii  libcairo-gobject2   1.14.0-2.1+deb8u2
ii  libcairo2   1.14.0-2.1+deb8u2
ii  libexiv2-13 0.24-4.1
ii  libgcc1 1:4.9.2-10
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u5
ii  libglib2.0-02.42.1-1+b1
ii  libgstreamer-plugins-base1.0-0  1.4.4-2
ii  libgstreamer1.0-0   1.4.4-2
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libjavascriptcoregtk-3.0-0  2.4.9-1~deb8u1
ii  libjpeg62-turbo 1:1.3.1-12
ii  libjson-glib-1.0-0  1.0.2-1
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libpng12-0  1.2.50-2+deb8u3
ii  librsvg2-2  2.40.5-1+deb8u2
ii  libsecret-1-0   0.18-1+b1
ii  libsoup2.4-12.48.0-1
ii  libstdc++6  4.9.2-10
ii  libtiff54.0.3-12.3+deb8u2
ii  libwebkit2gtk-3.0-252.4.9-1~deb8u1
ii  libwebp50.4.1-1.2+b2
ii  multiarch-support   2.19-18+deb8u7
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages gthumb recommends:
ii  bison   2:3.0.2.dfsg-2
ii  flex2.5.39-8+deb8u2
ii  gstreamer0.10-gnomevfs  0.10.36-2
ii  gvfs-bin1.22.2-1

gthumb suggests no packages.

-- no debconf information

Bug#808429: systemd: Please add logcheck rules

[Michael Biebl]

control: reassign -1 logcheck-database

Am 20.12.2015 um 02:32 schrieb Kevin Locke:
> Hi Michael,
> 
> Thanks for the very fast response!
> 
> On 12/19/2015 06:24 PM, Michael Biebl wrote:
>> Am 20.12.2015 um 02:11 schrieb Kevin Locke:
>>> systemd currently logs many informational messages to the system log and
>>> does not exclude any of these messages from logcheck, which results in
>>> an overwhelming number of systemd log messages being reported.
>>>
>>> The logcheck maintainers recommend that packages maintain their own
>>> logcheck rules.[1]
>>
>> Speaking for myself, as one of the systemd maintainers, I don't use and
>> have never used logcheck. So it's unlikely that I'll do a proper job at
>> maintaining the logcheck rules. I therefor feel uneasy to accept this
>> patch and I think it would probably be better added to the logcheck
>> package, where people that actually use it, maintain it.
> 
> I can understand that.  Keep in mind, the rules are just regular
> expressions which match log messages that can be ignored under normal
> conditions, so understanding the internals of logcheck is not required.
>  But without using logcheck, it's likely they will become out of date
> and result in bugs from users (which offloads the logcheck work, but
> requires more bug handling work).
> 
> I think part of the reasoning of the logcheck maintainers, other than
> reducing their own burden, is that the rules are often version-specific
> (as log messages change across versions) so putting them in the
> logcheck-database package would require matching against any possible
> version of the other packages.  Additionally, package maintainers are
> more likely to know when messages (or message formatting) changes
> significantly.
> 
> However, if you and the other systemd maintainers are uncomfortable
> including the rules in the systemd package, feel free to reassign this
> bug to the logcheck-database package.
> 

Doing so.


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



signature.asc
Description: OpenPGP digital signature

Bug#852502: openslide-python: FTBFS (failing tests)

[Santiago Vila]

Package: src:openslide-python
Version: 1.1.1-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3 --buildsystem=pybuild
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config 
running config
I: pybuild base:184: python3.5 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python setup.py build 
running build
running build_py
creating /<>/.pybuild/pythonX.Y_2.7/build/openslide

[... snipped ...]

test_read_bad_associated_image (tests.test_openslide.TestUnreadableSlide) ... 
JPEGLib: Bogus marker length.
ok
test_read_bad_region (tests.test_openslide.TestUnreadableSlide) ... ok

==
ERROR: test_read_region_size_dimension_zero (tests.test_imageslide.TestImage)
--
Traceback (most recent call last):
  File "/<>/tests/test_imageslide.py", line 108, in 
test_read_region_size_dimension_zero
self.assertEqual(self.osr.read_region((0, 0), 0, (400, 0)).size,
  File "/<>/openslide/__init__.py", line 363, in read_region
tile = Image.new("RGBA", size, (0,) * 4)
  File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2021, in new
_check_size(size)
  File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2001, in 
_check_size
raise ValueError("Width and Height must be > 0")
ValueError: Width and Height must be > 0

==
ERROR: test_read_region_size_dimension_zero (tests.test_openslide.TestSlide)
--
Traceback (most recent call last):
  File "/<>/tests/test_openslide.py", line 114, in 
test_read_region_size_dimension_zero
self.assertEqual(self.osr.read_region((0, 0), 1, (400, 0)).size,
  File "/<>/openslide/__init__.py", line 223, in read_region
level, size[0], size[1])
  File "/<>/openslide/lowlevel.py", line 257, in read_region
return PIL.Image.new('RGBA', (w, h))
  File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2021, in new
_check_size(size)
  File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2001, in 
_check_size
raise ValueError("Width and Height must be > 0")
ValueError: Width and Height must be > 0

--
Ran 46 tests in 0.087s

FAILED (errors=2, skipped=1)
Test failed: 
error: Test failed: 
E: pybuild pybuild:276: test: plugin distutils failed with: exit code=1: 
python2.7 setup.py test 
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
debian/rules:8: recipe for target 'build-indep' failed
make: *** [build-indep] Error 25
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


It also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/openslide-python.html

so it should be easy to reproduce.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

Thanks.

Bug#852476: file: /etc/magic no longer searched by default

[Olly Betts]

On Tue, Jan 24, 2017 at 10:05:28PM +0100, Christoph Biedl wrote:
> Olly Betts wrote...
> > The documentation seems to not exactly match either behaviour - "man
> > file" says:
> > 
> > | The information identifying these files is read from /etc/magic and
> > | the compiled magic file /usr/share/misc/magic.mgc, or the files in the
> > | directory /usr/share/misc/magic if the compiled file does not exist.
> > | In addition, if $HOME/.magic.mgc or $HOME/.magic exists, it will be
> > | used in preference to the system magic files.
> > 
> > The wording could perhaps be clearer, but that seems to imply that the
> > default should actually be to search:
> > 
> > $HOME/.magic:/etc/magic:/usr/share/misc/magic
> 
> Um, are you saying the wording short rather be in the order of actual
> probing so it was clearer - or is there something plain wrong?

Mostly that it would be clearer if the orders matched.

But I'm also not sure how to interpret "in preference" there - it could
mean "~/.magic is used if it exists, otherwise the system magic files are",
but as you say strace shows that's not what actually happens.  So it seems
"will be used in preference to" really just means "will be read before".

Cheers,
Olly

Bug#852501: gridsite: FTBFS (zlib.h: No such file or directory)

[Santiago Vila]

Package: src:gridsite
Version: 2.3.2-2
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh_testdir
touch configure-stamp
dh_testdir
cd src && \
/usr/bin/make build prefix=/usr libdir=lib/x86_64-linux-gnu \
CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro"
make[1]: Entering directory '/<>/src'
date
Tue Jan 24 03:48:03 UTC 2017
doxygen Doxyfile
warning: Tag `DETAILS_AT_TOP' at line 197 of file `Doxyfile' has become 
obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag `HTML_ALIGN_MEMBERS' at line 507 of file `Doxyfile' has become 
obsolete.

[... snipped ...]

grst-delegation.c:220:3: warning: ignoring return value of 'asprintf', declared 
with attribute warn_unused_result [-Wunused-result]
   asprintf(, "%s/%s", docroot, GRST_PROXYCACHE);
   ^~
grst-delegation.c: In function 'ns__getTerminationTime':
grst-delegation.c:254:3: warning: ignoring return value of 'asprintf', declared 
with attribute warn_unused_result [-Wunused-result]
   asprintf(, "%s/%s", docroot, GRST_PROXYCACHE);
   ^~
grst-delegation.c: In function 'ns__destroy':
grst-delegation.c:288:3: warning: ignoring return value of 'asprintf', declared 
with attribute warn_unused_result [-Wunused-result]
   asprintf(, "%s/%s", docroot, GRST_PROXYCACHE);
   ^~
gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I. 
-I../interface -DPIC -fPIC -DLINUX=2 -D_REENTRANT -D_LARGEFILE64_SOURCE 
-I/usr/include/httpd -I/usr/include/apache2 -I/usr/include/apr-0 
-I/usr/include/apr-1 -I/usr/include/apr-1.0 -Wl,-z,relro -L. -o htproxyput \
htproxyput.c \
-I/usr/kerberos/include -I. \
-DVERSION=\"2.3.2\" \
`pkg-config gsoapssl --cflags` \
-L./.libs \
 \
soapC.c soapClient.c `pkg-config gsoapssl --libs` \
-lgridsite -lssl -lcrypto
In file included from htproxyput.c:66:0:
/usr/include/stdsoap2.h:902:19: fatal error: zlib.h: No such file or directory
 # include 
   ^
compilation terminated.
In file included from soapStub.h:17:0,
 from soapH.h:16,
 from soapC.c:19:
/usr/include/stdsoap2.h:902:19: fatal error: zlib.h: No such file or directory
 # include 
   ^
compilation terminated.
In file included from soapStub.h:17:0,
 from soapH.h:16,
 from soapClient.c:18:
/usr/include/stdsoap2.h:902:19: fatal error: zlib.h: No such file or directory
 # include 
   ^
compilation terminated.
Makefile:326: recipe for target 'htproxyput' failed
make[1]: *** [htproxyput] Error 1
make[1]: Leaving directory '/<>/src'
debian/rules:38: recipe for target 'build-stamp' failed
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


It also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gridsite.html

so it should be easy to reproduce.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

Thanks.

Bug#852470: Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr

[Andreas Beckmann]

Please continue discussion in this *NEW* bug.

On 2017-01-24 23:25, Maarten van Gompel wrote:
> Hi Andreas, Mattia,
> 
> Quoting Andreas Beckmann (2017-01-24 19:04:24)
>>>
>>> Oops... Well spotted, I just fixed it in git, but it is probably overkill 
>>> to prepare/upload a new release just
>>> for that now I guess?
>>
>> Correct. But let me see what else I found:
>>
>> jessie-> sid upgrades:
>>
>> ucto.maintscript is missing, doing rm_conffile on the conffiles shipped
>> in jessie (use 0.9.6-2~ as prior version, if this gets fixed in -2).
>> If there was a post-jessie version shipping more conffiles in /etc,
>> clean them up as well.
>>
>>   ucto: obsolete-conffile /etc/ucto/exotic-eos.eos
>>   ucto: obsolete-conffile /etc/ucto/nl_afk.abr
>>   ucto: obsolete-conffile /etc/ucto/tokconfig-nl
>>   ucto: obsolete-conffile /etc/ucto/smiley.rule
>>   ucto: obsolete-conffile /etc/ucto/tokconfig-it
>>   ucto: obsolete-conffile /etc/ucto/standard-eos.eos
>>   ucto: obsolete-conffile /etc/ucto/tokconfig-sv
>>   ucto: obsolete-conffile /etc/ucto/tokconfig-fr
>>   ucto: obsolete-conffile /etc/ucto/exotic-quotes.quote
>>   ucto: obsolete-conffile /etc/ucto/tokconfig-nl-twitter
>>   ucto: obsolete-conffile /etc/ucto/tokconfig-es
>>   ucto: obsolete-conffile /etc/ucto/url.rule
>>   ucto: obsolete-conffile /etc/ucto/e-mail.rule
>>   ucto: obsolete-conffile /etc/ucto/tokconfig-nl-sonarchat
>>   ucto: obsolete-conffile /etc/ucto/es.abr
>>   ucto: obsolete-conffile /etc/ucto/tokconfig-fy
>>   ucto: obsolete-conffile /etc/ucto/tokconfig-de
>>   ucto: obsolete-conffile /etc/ucto/tokconfig-en
>>   ucto: obsolete-conffile /etc/ucto/ligatures.filter
>>   ucto: obsolete-conffile /etc/ucto/standard-quotes.quote
> 
> I think I get it. Because these moved to uctodata, which did not exist yet for
> jessie (before the split), the config files are owned by ucto and uctodata 
> can't clean
> it. Hadn't thought of that yet. I added an ucto.maintscript now for 0.9.6-2 
> (in
> git).

Theoretically making uctodata cleaning them up, too, is possible, but
the tasks in uctodata are already "interesting" enough. And ucto is not
going to be removed on the jessie->stretch upgrade.

>> frog looks fine
>>
>> stretch -> sid upgrades:
>>
>>   libucto2:amd64: obsolete-conffile /etc/ucto/textcat.cfg
> 
> added
> 
>>
>>   uctodata: obsolete-conffile /etc/ucto/spa.abr
>>   uctodata: obsolete-conffile /etc/ucto/por.abr
>>   uctodata: obsolete-conffile /etc/ucto/nld_afk.abr
>>
> 
> added
> 
>> frog looks fine, too
>>
>>
>> That's not RC, the upgrades went smooth, but it would still be great to
>> get this cleaned up properly.
> 
> I'm glad it went smooth in spite of this. Hopefully the next releases will
> clean it up for good.
> 
>>
>> But lets take a detailed look what happened here:
>>
>>   Unpacking uctodata (0.4-1) over (0.3.1-1) ...
>>   dpkg: warning: unable to delete old directory '/etc/ucto': Directory
>> not empty
>>   Setting up uctodata (0.4-1) ...
>>   Obsolete conffile /etc/ucto/es.abr has been modified by you.
>>   Saving as /etc/ucto/es.abr.dpkg-bak ...
>>   Removing obsolete conffile /etc/ucto/exotic-eos.eos ...
>>   Removing obsolete conffile /etc/ucto/exotic-quotes.quote ...
>>   Removing obsolete conffile /etc/ucto/ligatures.filter ...
>>   Obsolete conffile /etc/ucto/nl_afk.abr has been modified by you.
>>   Saving as /etc/ucto/nl_afk.abr.dpkg-bak ...
>>   Obsolete conffile /etc/ucto/pt.abr has been modified by you.
>>   Saving as /etc/ucto/pt.abr.dpkg-bak ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-deu ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-eng ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-spa ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-fra ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-fry ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-ita ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-nld ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-nld-sonarchat ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-nld-twitter ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-nld-withplaceholder ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-por ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-rus ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-swe ...
>>   Removing obsolete conffile /etc/ucto/tokconfig-tur ...
>>   Processing triggers for libc-bin (2.24-9) ...
>>
>> You probably shouldn't call rm_conffile on the symlinks owned by
>> uctodata - these are no conffiles, but you seem to confuse dpkg by doing
>> this. Removing the conffiles from jessie is better left to
>> ucto.maintscript.
> 
> But before these were symlinks in uctodata, they were normal files in
> uctodata...  Only the 0.3.1 release introduced the symlinks (for a very short
> while since it was only accepted not so long ago).. Not sure how to make the
> distinction.

Hmm, interesting ... how many (and which) conffiles in uctodata (not the
ones from ucto) have 

Bug#852500: ksh: First install of ksh fails on Stretch due to update-alternatives

[Zed Pobre]

Package: ksh
Version: 93u+20120801-2
Severity: normal

There's something wrong with the update-alternatives handling in the
postinst.  You can see this failure consistently on a stretch system
by purging and reinstalling the package.  The first install always
fails, but it will correct itself with a 'dpkg --configure -a'
afterwards.

The problem does not occur in Jessie, nor does it occur in upgrades
from the Jessie version to the Stretch version.

A log of an attempted install follows:


# apt-get install ksh
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  ksh
0 upgraded, 1 newly installed, 0 to remove and 10 not upgraded.
Need to get 0 B/876 kB of archives.
After this operation, 3,314 kB of additional disk space will be used.
Selecting previously unselected package ksh.
(Reading database ... 316301 files and directories currently installed.)
Preparing to unpack .../ksh_93u+20120801-2_amd64.deb ...
Unpacking ksh (93u+20120801-2) ...
Setting up ksh (93u+20120801-2) ...
update-alternatives: using /bin/ksh93 to provide /bin/ksh (ksh) in auto mode
update-alternatives: error: unable to install '/usr/bin/ksh.dpkg-tmp' as 
'/usr/bin/ksh': No such file or directory
dpkg: error processing package ksh (--configure):
 subprocess installed post-installation script returned error exit status 2
Processing triggers for man-db (2.7.6.1-2) ...
Errors were encountered while processing:
  ksh
E: Sub-process /usr/bin/dpkg returned an error code (1)

# dpkg --configure -a
Setting up ksh (93u+20120801-2) ...
update-alternatives: warning: forcing reinstallation of alternative /bin/ksh93 
because link group ksh is broken


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

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

Versions of packages ksh depends on:
ii  binfmt-support  2.1.6-2
ii  libc6   2.24-8

ksh recommends no packages.

ksh suggests no packages.

-- no debconf information

Bug#852346: kdenlive: crash on startup

[Luca Boccassi]

On Mon, 23 Jan 2017 18:10:00 + "George B."  wrote:
> Package: kdenlive
> Version: 16.12.1-1
> Severity: important
>
> Hello,
>
> Kdenlive crashes on startup:
>
> ```
> OpenGL vendor:  "NVIDIA Corporation"
> OpenGL renderer:  "Quadro M1000M/PCIe/SSE2"
> OpenGL Threaded:  true
> OpenGL ARG_SYNC:  true
> OpenGL OpenGLES:  false
> OpenGL vendor:  "NVIDIA Corporation"
> OpenGL renderer:  "Quadro M1000M/PCIe/SSE2"
> OpenGL Threaded:  true
> OpenGL ARG_SYNC:  true
> OpenGL OpenGLES:  false
> QOpenGLFunctions created with non-current context
> Segmentation fault (core dumped)
> ```
>
> syslog has
> ```
> [95683.085432] FrameRenderer[9753]: segfault at a8 ip 55d95179c919 sp 
> 7f3f30c51650 error 4 in kdenlive[55d951452000+5f5000]
> ```
>
> Backtrace attached.
>
>
> Best regards,
>
> George


Please run:

reportbug -N 852346

to attach the full system information and logs

Kind regards,
Luca Boccassi

Bug#851946: Depending on libssl1.0-dev breaks PHP builds

[Niels Thykier]

Sebastian Andrzej Siewior:
> On 2017-01-24 06:34:00 [+], Niels Thykier wrote:
>> The guard, you proposed, is using 1.0.2, so this patch will be
>> unnecessary (guess I misunderstood your original intention).  But the
>> end result should be the same. :)
> 
> [...]
> The point is to ensure that nobody tries to use that header file and
> link against net-snmp whith an incompatible libssl.
> 

Indeed. I have decided to go with 1.0.2 to minimize the changes. :)

> [...]
> 
> I am not sure what we should about the package that will now fail to
> build due to missing libssl-dev. Two of them (as it looks) could be
> fixed if we tell libesmtp not to export the ssl flags.
> 
> Sebastian
> 

 * collected upstream *explicitly* adds a -lssl -lcrypto in an
   Makefile.am, so the package should B-D on it as necessary (or
   patch those -l statements out if they are unnecessary).

 * cacti-spine => Paul said he would fix that, so I assuming he got this

 * hplip => source suggests that there should be some from of
   build-dependency[1]

 * pacemaker => Ideally, libesmtp-dev would either depend on libssl-dev
   (or not include -lcrypto -lssl in its libesmtp-config script)

I will file bugs for the above (cacti-spine being a possible exception)
tomorrow - feel free to beat me to it. :)

Thanks,
~Niels

[1]
https://sources.debian.net/src/hplip/3.16.11%2Brepack0-1/installer/core_install.py/?hl=370#L370

Bug#852499: O: wbxml2 -- WBXML parsing and encoding library

[Michael Banck]

Package: wnpp
Severity: normal

I intend to orphan the wbxml2 package.

The package description is:
 The WBXML Library (aka libwbxml) contains a library and its associated
 tools to Parse, Encode and Handle WBXML documents.  The WBXML format
 is a binary representation of XML, defined by the Wap Forum, and used
 to reduce bandwidth in mobile communications.
 .
 This package contains the dynamic library needed by applications
 using libwbxml2.

Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr

[Andreas Beckmann]

On 2017-01-24 23:25, Maarten van Gompel wrote:

I'll reply to 852...@bugs.debian.org


Andreas

Bug#849756: sssd-ldap fails to connect to ldaps:// due to problem with non-blocking socket

[Petter Reinholdtsen]

[Timo Aaltonen]
> Do you still have upload rights? My laptop is messed up and I'm far away
> from my desktop, so an nmu is in order.

Yes.  I'm preparing a NMU now.  Tried updating the git repo, but did not find
the tags needed for gbp buildpackage to work, so I went with an NMU instead.
-- 
Happy hacking
Petter Reinholdtsen

Bug#852498: O: libsyncml -- SyncML protocol library

[Michael Banck]

Package: wnpp
Severity: normal

I intend to orphan the scmxx package.

The package description is:
 Libsyncml implement the SyncML protocol. It supports SyncML version
 1.0, 1.1 and 1.2. The available transport are Obex and HTTP. This
 library can be used as a client or as a server. 

Bug#852497: O: scmxx -- Exchange data with Siemens mobile phones

[Michael Banck]

Package: wnpp
Severity: normal

I intend to orphan the scmxx package.

The package description is:
 SCMxx is a console program that allows you to exchange certain types of
 data with mobile phones made by Siemens. Some of the data types that can
 be exchanged are logos, ring tones, vCalendars, phonebook entries, and
 SMS messages. It works with the S25, S35i, M35i and C35i, SL45, S45 and
 ME45 and probably others.
 .
 You need a serial connection (either cable or infrared) to your mobile
 phone in order to use SCMxx.
 .
 It basically uses the AT command set published by Siemens
 (with some other, additional resources).

Bug#852496: RM: libgcal -- ROM; obsolete and unmaintained upstream

[Michael Banck]

Package: ftp.debian.org
Severity: normal

Hi,

please remove src:libgcal and its binary packages libgcal-dev and
libgcal0. AFAIK those haven't worked in a long time and are unmaintained
upstream.


Thanks,

Michael

Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr

[Maarten van Gompel]

Hi Andreas, Mattia,

Quoting Andreas Beckmann (2017-01-24 19:04:24)
> > 
> > Oops... Well spotted, I just fixed it in git, but it is probably overkill 
> > to prepare/upload a new release just
> > for that now I guess?
> 
> Correct. But let me see what else I found:
> 
> jessie-> sid upgrades:
> 
> ucto.maintscript is missing, doing rm_conffile on the conffiles shipped
> in jessie (use 0.9.6-2~ as prior version, if this gets fixed in -2).
> If there was a post-jessie version shipping more conffiles in /etc,
> clean them up as well.
> 
>   ucto: obsolete-conffile /etc/ucto/exotic-eos.eos
>   ucto: obsolete-conffile /etc/ucto/nl_afk.abr
>   ucto: obsolete-conffile /etc/ucto/tokconfig-nl
>   ucto: obsolete-conffile /etc/ucto/smiley.rule
>   ucto: obsolete-conffile /etc/ucto/tokconfig-it
>   ucto: obsolete-conffile /etc/ucto/standard-eos.eos
>   ucto: obsolete-conffile /etc/ucto/tokconfig-sv
>   ucto: obsolete-conffile /etc/ucto/tokconfig-fr
>   ucto: obsolete-conffile /etc/ucto/exotic-quotes.quote
>   ucto: obsolete-conffile /etc/ucto/tokconfig-nl-twitter
>   ucto: obsolete-conffile /etc/ucto/tokconfig-es
>   ucto: obsolete-conffile /etc/ucto/url.rule
>   ucto: obsolete-conffile /etc/ucto/e-mail.rule
>   ucto: obsolete-conffile /etc/ucto/tokconfig-nl-sonarchat
>   ucto: obsolete-conffile /etc/ucto/es.abr
>   ucto: obsolete-conffile /etc/ucto/tokconfig-fy
>   ucto: obsolete-conffile /etc/ucto/tokconfig-de
>   ucto: obsolete-conffile /etc/ucto/tokconfig-en
>   ucto: obsolete-conffile /etc/ucto/ligatures.filter
>   ucto: obsolete-conffile /etc/ucto/standard-quotes.quote

I think I get it. Because these moved to uctodata, which did not exist yet for
jessie (before the split), the config files are owned by ucto and uctodata 
can't clean
it. Hadn't thought of that yet. I added an ucto.maintscript now for 0.9.6-2 (in
git).

> 
> frog looks fine
> 
> stretch -> sid upgrades:
> 
>   libucto2:amd64: obsolete-conffile /etc/ucto/textcat.cfg

added

> 
>   uctodata: obsolete-conffile /etc/ucto/spa.abr
>   uctodata: obsolete-conffile /etc/ucto/por.abr
>   uctodata: obsolete-conffile /etc/ucto/nld_afk.abr
> 

added

> frog looks fine, too
> 
> 
> That's not RC, the upgrades went smooth, but it would still be great to
> get this cleaned up properly.

I'm glad it went smooth in spite of this. Hopefully the next releases will
clean it up for good.

> 
> But lets take a detailed look what happened here:
> 
>   Unpacking uctodata (0.4-1) over (0.3.1-1) ...
>   dpkg: warning: unable to delete old directory '/etc/ucto': Directory
> not empty
>   Setting up uctodata (0.4-1) ...
>   Obsolete conffile /etc/ucto/es.abr has been modified by you.
>   Saving as /etc/ucto/es.abr.dpkg-bak ...
>   Removing obsolete conffile /etc/ucto/exotic-eos.eos ...
>   Removing obsolete conffile /etc/ucto/exotic-quotes.quote ...
>   Removing obsolete conffile /etc/ucto/ligatures.filter ...
>   Obsolete conffile /etc/ucto/nl_afk.abr has been modified by you.
>   Saving as /etc/ucto/nl_afk.abr.dpkg-bak ...
>   Obsolete conffile /etc/ucto/pt.abr has been modified by you.
>   Saving as /etc/ucto/pt.abr.dpkg-bak ...
>   Removing obsolete conffile /etc/ucto/tokconfig-deu ...
>   Removing obsolete conffile /etc/ucto/tokconfig-eng ...
>   Removing obsolete conffile /etc/ucto/tokconfig-spa ...
>   Removing obsolete conffile /etc/ucto/tokconfig-fra ...
>   Removing obsolete conffile /etc/ucto/tokconfig-fry ...
>   Removing obsolete conffile /etc/ucto/tokconfig-ita ...
>   Removing obsolete conffile /etc/ucto/tokconfig-nld ...
>   Removing obsolete conffile /etc/ucto/tokconfig-nld-sonarchat ...
>   Removing obsolete conffile /etc/ucto/tokconfig-nld-twitter ...
>   Removing obsolete conffile /etc/ucto/tokconfig-nld-withplaceholder ...
>   Removing obsolete conffile /etc/ucto/tokconfig-por ...
>   Removing obsolete conffile /etc/ucto/tokconfig-rus ...
>   Removing obsolete conffile /etc/ucto/tokconfig-swe ...
>   Removing obsolete conffile /etc/ucto/tokconfig-tur ...
>   Processing triggers for libc-bin (2.24-9) ...
> 
> You probably shouldn't call rm_conffile on the symlinks owned by
> uctodata - these are no conffiles, but you seem to confuse dpkg by doing
> this. Removing the conffiles from jessie is better left to
> ucto.maintscript.

But before these were symlinks in uctodata, they were normal files in
uctodata...  Only the 0.3.1 release introduced the symlinks (for a very short
while since it was only accepted not so long ago).. Not sure how to make the
distinction.

> I think you found a bug in dpkg here :-)

> 
>   Preparing to unpack .../libucto2_0.9.6-1_amd64.deb ...
>   Unpacking libucto2:amd64 (0.9.6-1) over (0.9.5-1) ...
>   dpkg: warning: unable to delete old directory '/etc/ucto': Directory
> not empty
>   Setting up libgomp1:amd64 (6.3.0-4) ...
>   Setting up libxml2:amd64 (2.9.4+dfsg1-2.2) ...
>   Processing triggers for libc-bin (2.24-9) ...
>   Setting up libucto2:amd64 (0.9.6-1) ...
>   Removing obsolete conffile /etc/ucto/e-mail.rule ...
>   

Bug#852493: [PATCH] Enable CONFIG_THUNDER_NIC_VF in the debian kernel config

[Punit Agrawal]

NIC virtual function (VF) driver is required when using a passed
through NIC to a guest on the Thunder platform.

Enable this driver as a module in the debian config. Closes: #852493
---
 debian/config/config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/config/config b/debian/config/config
index c744073f9..c40bb15c5 100644
--- a/debian/config/config
+++ b/debian/config/config
@@ -2852,7 +2852,7 @@ CONFIG_NET_CADENCE=y
 ##
 CONFIG_NET_VENDOR_CAVIUM=y
 # CONFIG_THUNDER_NIC_PF is not set
-# CONFIG_THUNDER_NIC_VF is not set
+CONFIG_THUNDER_NIC_VF=m
 # CONFIG_THUNDER_NIC_BGX is not set
 # CONFIG_THUNDER_NIC_RGX is not set
 CONFIG_LIQUIDIO=m
-- 
2.11.0

Bug#852495: mariadb-server-10.[01]: purging old mariadb-server shuts down mariadb-server and removes init.d links

[Julian Gilbey]

Package: mariadb-server-10.1
Version: 10.1.21-1
Severity: normal

After upgrading to 10.1 from 10.0, I purged the old
mariadb-server-10.0 package, but this had two quite unpleasant
effects: it shut down the server and it removed the init.d links.
This is because:

(a) In the purge|remove|upgrade|... case, stop_server is executed
unconditionally.  It is not obvious to me under what conditions
the server should be stopped, but I would presume that at the very
least, it should only be stopped if the running server is the same
version as the package.  This could be tested (somewhat slowly but
quite safely) by running:

if [ -x /usr/sbin/mysqld ]
then
serverpackage=$(dpkg -S /usr/sbin/mysqld | cut -d: -f1)
if [ $serverpackage = mariadb-server-core-$this_version ]
then
stop_server
sleep 2
fi
fi

The whole server-stopping is probably also in general somewhat
unnecessary, as the server will have been stopped in the prerm
anyway by the dh_installinit snippet.  And this may suffer from
the same issue (though I am less convinced about this), and should
probably be replaced by your stop_server script anyway.

Oh, and for stretch, you don't need to test for the existence of
invoke-rc.d, as it is now in the essential init-system-helpers
package, so you can just do invoke-rc.d mysql stop
unconditionally.

(b) The dh_installinit snippet unconditionally runs update-rc.d mysql
remove.

The only way I can think to fix this is to run dh_installinit with
--no-scripts and then manually insert the necessary snippets into
the postinst/postrm/prerm scripts.  In the postrm script, it
should be protected by the same checks as in (a).

Best wishes,

   Julian

Bug#852485: apt: [INTL:fr] French man pages translation updated typo

[jean-pierre giraud]

Hi,
I discovered a typo in the file updated, line 10500 :
s /apt-get -fix-broken/apt-get --fix-broken
I attach a diff file with the patch.
If you prefer, I can send a new file.
best regards
jepege
--- l10n/a_c/apt/apt_doc_2017/frjpg.po	2017-01-24 23:08:03.385265775 +0100
+++ Documents/traductions/l10n/a_c/apt/apt_doc_2017/fr.po	2017-01-24 22:56:09.311309448 +0100
@@ -10500,7 +10500,7 @@
 "# apt-get check\n"
 "Lecture de la liste des paquets... Fait\n"
 "Construction de l'arbre des dépendances... Fait\n"
-"Vous pouvez lancer « apt-get -fix-broken install » pour corriger ces "
+"Vous pouvez lancer « apt-get --fix-broken install » pour corriger ces "
 "problèmes.\n"
 "Les paquets suivants contiennent des dépendances non satisfaites :\n"
 "  9fonts: Depends: xlib6g mais il n'est pas installé\n"

Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives

[Javier Serrano Polo]

Source: wine
Version: 1.8.6-3
Severity: wishlist

Please add a libwine.so.1 alternative to libwine packages, and
libwine.so to libwine-dev ones. These alternatives should be placed
under /usr/lib/MULTIARCH so that applications depending on libwine avoid
the use of RUNPATH and the binary-or-shlib-defines-rpath lintian error.

The alternatives should not be slaves in the wine package. I suggest to
move the slave alternatives from wine package to their respective
packages (wine32-tools and such), and to depend on an
update-wine-alternatives script (in libwine) that runs
update-alternatives for the installed packages.


smime.p7s
Description: S/MIME cryptographic signature

Bug#848256: Info received (Bug#848256: lastpass-cli: lpass segfaults attempting to log in)

[Rann Bar-On]

Here you go.

Starting program: /usr/bin/lpass login 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-
gnu/libthread_db.so.1".
[New Thread 0x7fffef67d700 (LWP 30685)]
[Thread 0x7fffef67d700 (LWP 30685) exited]

Thread 1 "lpass" received signal SIGSEGV, Segmentation fault.
0x0001 in ?? ()
(gdb) bt
#0  0x0001 in ?? ()
#1  0x7601f27a in ssl23_client_hello (s=0x557d8560) at
s23_clnt.c:606
#2  ssl23_connect (s=0x557d8560) at s23_clnt.c:218
#3  0x77bb788a in ossl_connect_step2 (conn=conn@entry=0x557
d4d70, sockindex=sockindex@entry=0) at vtls/openssl.c:2215
#4  0x77bb7e0a in ossl_connect_common (conn=conn@entry=0x55
7d4d70, sockindex=0, nonblocking=nonblocking@entry=true, done=done@entr
y=0x7fffdb07) at vtls/openssl.c:3060
#5  0x77bbb8dd in Curl_ossl_connect_nonblocking (conn=conn@entr
y=0x557d4d70, sockindex=, done=done@entry=0x7fff
db07) at vtls/openssl.c:3094
#6  0x77bbc1e2 in Curl_ssl_connect_nonblocking (conn=conn@entry
=0x557d4d70, sockindex=sockindex@entry=0, done=0x7fffdb07) at
vtls/vtls.c:243
#7  0x77b6d5d2 in https_connecting (conn=0x557d4d70,
done=) at http.c:1400
#8  0x77b80417 in Curl_protocol_connect (conn=0x557d4d70, p
rotocol_done=protocol_done@entry=0x7fffdb07) at url.c:3956
#9  0x77b95716 in multi_runsingle (multi=multi@entry=0x557c
b620, now=..., data=data@entry=0x557c25b0) at multi.c:1594
#10 0x77b96641 in curl_multi_perform (multi=multi@entry=0x5
57cb620, running_handles=running_handles@entry=0x7fffdc98) at
multi.c:2149
#11 0x77b8c5c0 in easy_transfer (multi=0x557cb620) at
easy.c:700
#12 easy_perform (events=false, data=0x557c25b0) at easy.c:787
#13 curl_easy_perform (data=data@entry=0x557c25b0) at easy.c:806
#14 0x5556d19c in http_post_lastpass_v_noexit (server=server@en
try=0x0, page=page@entry=0x55570cdb "iterations.php", session=sessi
on@entry=0x0, final_len=final_len@entry=0x0, argv=, curl
_ret=curl_ret@entry=0x7fffde4c, http_code=0x7fffde50) at
http.c:307
#15 0x5556d334 in http_post_lastpass_v (server=server@entry=0x0
, page=page@entry=0x55570cdb "iterations.php", session=session@entr
y=0x0, final_len=final_len@entry=0x0, argv=) at
http.c:332
#16 0x5556d44a in http_post_lastpass_param_set
(param_set=0x7fffde70, final_len=0x0, session=0x0,
page=0x55570cdb "iterations.php") at http.c:343
#17 http_post_lastpass (page=page@entry=0x55570cdb
"iterations.php", session=session@entry=0x0, final_len=final_len@entry=
0x0) at http.c:224
#18 0x5556749d in lastpass_iterations (username=username@entry=
0x7fffe4b8 "r...@duke.edu") at endpoints.c:53
#19 0x5556d8b1 in cmd_login (argc=,
argv=0x7fffe1b0) at cmd-login.c:98
#20 0x9b4d in process_command (argv=0x7fffe1b0, argc=2)
at lpass.c:161
#21 main (argc=3, argv=) at lpass.c:202

Bug#852491: RM: arden [amd64 i386 arm64 armel armhf mips mipsel mips64el ppc64el s390x] -- ANAIS; package is now binary-all

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal


arden (1.0-3) unstable; urgency=medium

  * Architecture: all
Closes: #852313

 -- Andreas Tille   Mon, 23 Jan 2017 17:45:52 +0100

Bug#852492: pastebinit does not handle proxy connections to https correctly

[Julian Andres Klode]

Package: pastebinit
Version: 1.5-1
Severity: normal

When using an http proxy, and a https pastebinit, like paste.d.n,
pastebinit sends the following request to the proxy:

POST https://paste.debian.net HTTP/...
... data ...

This does not work: The proxy would have to decrypt the connection
itself - so the encryption would be broken.

What it should do is
CONNECT paste.debian.net:443
and then talk normal http to the server once the CONNECT request
has been acknowledged by a 200 responses.

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

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

Versions of packages pastebinit depends on:
ii  python3  3.5.1-4

pastebinit recommends no packages.

pastebinit suggests no packages.

-- no debconf information

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#852493: Please enable Thunder NIC virtual function driver

[Punit Agrawal]

Source: linux
Severity: wishlist
Tags: patch

While testing device passthrough with a debian guest on a Cavium
Thunder, I found that the virtual function(VF) driver for the built in
nic is not available.

Please enable CONFIG_THUNDER_NIC_VF in the debian kernel config.

Bug#852490: RM: ea-utils [armel] -- RoQA; hmisc is no longer available on armel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal
Control: block 852339 by -1
Control: block -1 by 852487

hmisc is no longer available on armel (see #852339).

Bug#852487: RM: qiime [armel] -- RoQA; hmisc is no longer available on armel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

hmisc is no longer available on armel (see #852339).

Bug#852488: RM: r-bioc-biovizbase [armel] -- RoQA; hmisc is no longer available on armel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal
Control: block 852339 by -1

hmisc is no longer available on armel (see #852339).

Bug#852489: RM: rcmdr [armel] -- RoQA; hmisc is no longer available on armel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal
Control: block 852339 by -1

hmisc is no longer available on armel (see #852339).

Bug#852081: Great news!

[alberto fuentes]

So many people stepping up. This is great news!

Synergy was in a great need of a new maintainer for a very long time :)

Due to many bugs, Ive been using upstream git without encryption over an
ssh tunnel for a time now.

I will test the new package as soon as is available :)

Bug#852486: libxml2: Parsing xxxyyy uses too much memory

[Christophe Troestler]

Package: libxml2
Version: 2.9.4+dfsg1-2.1
Severity: normal

Dear Maintainer,

When parsing the attached HTML file (which uses 25  tags), libxml 
starts to use inordinate amounts of memory.


See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25210#8 for the 
original bug against Emacs.


Best,
C.


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
  




-- System Information:
Debian Release: 9.0
 APT prefers testing
 APT policy: (900, 'testing'), (400, 'unstable'), (300, 'stable'), 
 (100, 'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 4.9.4 (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 libxml2 depends on:
ii  libc6 2.24-8
ii  libicu57  57.1-5
ii  liblzma5  5.2.2-1.2
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages libxml2 recommends:
ii  xml-core  0.17

libxml2 suggests no packages.

-- no debconf information

Bug#773245: git-p4 package?

[Sean Whitton]

On Tue, Jan 24, 2017 at 11:48:24AM +, Luke Diamand wrote:
> Is that normal for a package maintainer's email address?

It's not, but Gerrit Pape hasn't made an upload of the package since
2013.  I guess that those in the Uploaders field are the de facto
maintainers.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#852477: [Pkg-pascal-devel] Bug#852477: lazarus-1.6: Broken dependencies for lazarus-1.6

[peter green]

On 24/01/17 21:07, Paul Gevers wrote:

Control: severity -1 normal

Hi Roby,

You reported the issue with the backported package. I just tried to
reproduce this in stretch and without the back ported archive it works
as intended. Can you please tell us with what command you installed
lazarus-1.6? And can you maybe also add the full log such that I can see
where things go wrong?

My educated guess would be that he has tried to install a package that is only 
in backports (lazarus-1.6) but has not specified -t backports on the command 
line.


Paul



___
Pkg-pascal-devel mailing list
pkg-pascal-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-pascal-devel

Bug#852324: [Xen-devel] Is: EPT violations. Was:Re: Problems with pci/vga passthrough

[Boris Ostrovsky]

On 01/24/2017 01:51 PM, Boris Ostrovsky wrote:
> On 01/24/2017 01:44 PM, Diederik de Haas wrote:
>> On dinsdag 24 januari 2017 13:28:28 CET Boris Ostrovsky wrote:
> Reported it at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852324
> but  given Ben Hutchings' reaction it seems to be a Xen problem after
> all.
>
> Relevant part of earlier attached dmesg:
>
> [   13.588386] WARNING: CPU: 18 PID: 1 at 
> /build/linux-zDY19G/linux-4.8.15/arch/x86/mm/dump_pagetables.c:225
> note_page+0x5e8/0x790 [   13.588388] x86/mm: Found insecure W+X mapping
> at address 8800/0x8800 ...
> [   13.608867] x86/mm: Checked W+X mappings: FAILED, 4602 W+X pages
> found.
 Now this is a know issue, but I'm pretty convinced one that's entirely
 unrelated to your problem.
>>> I thought we fixed this. That's what is_hypervisor_range() was
>>> introduced for, and I haven't seen this warning since then.


Actually, I do see the warnings (I usually don't set CONFIG_DEBUG_WX).
They are not for the hypervisor range though, so the commit below is not
relevant.

Nevertheless, as Jan said, it's unlikely to cause your problem.

-boris


>> When? Which commit?
>> Maybe it isn't (yet) in the Debian tree and/or I am using a kernel which 
>> doesn't contain that fix.
>
> Commit f4e342c87776884f0309942a3880ca7e835239f9.
>
> All it did was to prevent the walker from trying to verify pages in the
> hypervisor range so it doesn't really fix anything. It's just that I am
> surprised to see this warning again.




signature.asc
Description: OpenPGP digital signature

Bug#852484: screen: Privilege escalation in Screen 4.5.0

[Axel Beckert]

Package: screen
Version: 4.5.0-1
Severity: grave
Control: forwarded -1 https://savannah.gnu.org/bugs/?50142

A potential root exploit was reported upstream at
https://savannah.gnu.org/bugs/?50142 (currently private) but also
forwarded to a publically archived mailing list at
https://lists.gnu.org/archive/html/screen-devel/2017-01/msg00025.html

In Debian with default configuration of the screen package, only access
to the utmp group can be gained -- which has very little privileges. See
https://lists.gnu.org/archive/html/screen-devel/2017-01/msg00027.html
for the impact in Debian.

Neverless the Debian screen package also supports different permissions
and hence some setups might be affected by the root exploit.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages screen depends on:
ii  libc6  2.24-9
ii  libpam0g   1.1.8-3.5
ii  libtinfo5  6.0+20161126-1

screen recommends no packages.

Versions of packages screen suggests:
ii  byobu 5.112-1
ii  iselect   1.4.0-2+b1
ii  ncurses-term  6.0+20161126-1
ii  screenie  20120406-1

-- no debconf information

Bug#818372: tex-common: Trigger fails on initial install of tex-common

[Martin Michlmayr]

I just ran into a similar problem.  I tried to install the
build-depends for debian-history in an armel chroot.  The chroot is
unstable but probably out-of-date by a few weeks.

I've attached the log of my initial apt-get run.  I then tried to do
"unset LANG" but that didn't change anything.

There's a message about old conffile updates in /etc/texmf/updmap.d.
This directory does not exist at all.

Here's the output of /tmp/updmap.O7laxdyO

updmap [WARNING]: resetting $HOME value (was /home/tbm) to root's actual home 
(/root).
updmap will read the following updmap.cfg files (in precedence order):
  /usr/share/texmf/web2c/updmap.cfg
  /usr/share/texlive/texmf-dist/web2c/updmap.cfg
updmap may write changes to the following updmap.cfg file:
  /etc/texmf/web2c/updmap.cfg
dvips output dir: "/var/lib/texmf/fonts/map/dvips/updmap"
pdftex output dir: "/var/lib/texmf/fonts/map/pdftex/updmap"
dvipdfmx output dir: "/var/lib/texmf/fonts/map/dvipdfmx/updmap"
updmap [ERROR]: The following map file(s) couldn't be found:
updmap [ERROR]: otf-@jaEmbed@.map (in 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg)
updmap [ERROR]: otf-ko-@koEmbed@.map (in 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg)
updmap [ERROR]: otf-sc-@scEmbed@.map (in 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg)
updmap [ERROR]: otf-tc-@tcEmbed@.map (in 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg)
updmap [ERROR]: otf-up-@jaEmbed@.map (in 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg)
updmap [ERROR]: ptex-@jaEmbed@@jaVariant@.map (in 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg)
updmap [ERROR]: uptex-@jaEmbed@@jaVariant@.map (in 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg)
updmap [ERROR]: uptex-ko-@koEmbed@.map (in 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg)
updmap [ERROR]: uptex-sc-@scEmbed@.map (in 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg)
updmap [ERROR]: uptex-tc-@tcEmbed@.map (in 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg)
updmap [ERROR]: Did you run mktexlsr?

You can disable non-existent map entries using the option
  --syncwithtrees.

I haven't touched the chroot since then, so I can run further tests
for you.

-- 
Martin Michlmayr
http://www.cyrius.com/
(sid-armel)root@m400-c2n1:/# apt-get build-dep debian-history
Reading package lists... Done
Reading package lists... 0%
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  cmake cmake-data dh-exec doxygen g++-5 hardening-includes 
libalgorithm-c3-perl libarchive-extract-perl libarchive13 libboost-dev 
libboost-filesystem1.58.0
  libboost-iostreams-dev libboost-iostreams1.62-dev libboost-iostreams1.62.0 
libboost-program-options-dev libboost-program-options1.58.0
  libboost-program-options1.62-dev libboost-program-options1.62.0 
libboost-regex-dev libboost-regex1.58.0 libboost-regex1.62-dev 
libboost-regex1.62.0
  libboost-system1.58.0 libboost1.62-dev libclang1-3.6 libclass-c3-perl 
libclass-c3-xs-perl libcloog-isl4 libcommon-sense-perl libcpan-changes-perl
  libcpan-meta-perl libcppunit-1.13-0v5 libcppunit-dev libcurl3 
libdata-perl-perl libdata-section-perl libdevel-caller-perl 
libdevel-lexalias-perl
  libfile-slurp-perl libintl-perl libintl-xs-perl libjson-perl libjson-xs-perl 
libkadm5clnt-mit10 libkadm5clnt-mit9 libkadm5srv-mit10 libkadm5srv-mit9
  libllvm3.5v5 libllvm3.6v5 liblog-message-perl liblog-message-simple-perl 
liblzo2-2 libmodule-build-perl libmodule-load-conditional-perl
  libmodule-pluggable-perl libmodule-signature-perl libmoox-handlesvia-perl 
libmro-compat-perl libnamespace-autoclean-perl libobjc-5-dev libobjc4
  libopenjpeg5 libpackage-constants-perl libpadwalker-perl libperl5.22 
libpng12-0 libpod-latex-perl libpod-markdown-perl libpod-readme-perl 
libpoppler57
  libpoppler61 libprocps5 libpython3.4-minimal libpython3.4-stdlib 
libsoftware-license-perl libterm-ui-perl libtext-soundex-perl libtrio2 
libtype-tiny-perl
  libtype-tiny-xs-perl libtypes-serialiser-perl libvpx2 libvpx3 libwebp5 
libxcb-randr0 libxcb-xfixes0 llvm-3.5 llvm-3.5-dev llvm-3.5-runtime
  perl-modules-5.22 python3.4 python3.4-minimal tex4ht uuid-dev
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  emacsen-common fonts-arphic-bkai00mp fonts-arphic-bsmi00lp 
fonts-arphic-gbsn00lp fonts-arphic-gkai00mp fonts-baekmuk fonts-gfs-baskerville 
fonts-gfs-porson
  fonts-hosny-amiri fonts-ipaexfont-gothic fonts-ipaexfont-mincho 
fonts-ipafont-gothic fonts-ipafont-mincho fonts-sil-padauk fonts-unfonts-core
  fonts-unfonts-extra latex-cjk-all latex-cjk-chinese 
latex-cjk-chinese-arphic-bkai00mp latex-cjk-chinese-arphic-bsmi00lp 
latex-cjk-chinese-arphic-gbsn00lp
  latex-cjk-chinese-arphic-gkai00mp latex-cjk-common latex-cjk-japanese 
latex-cjk-japanese-wadalab latex-cjk-korean latex-cjk-thai texlive-lang-african
  texlive-lang-all 

Bug#836785: sympa: wws outputs the right webpage, but into /var/log/apache2/errors.log

[Sebastian]

I can confirm this bug after the upgrade from 6.1.23~dfsg-2 to
6.1.23~dfsg-2+deb8u1

-- 
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers





signature.asc
Description: OpenPGP digital signature

Bug#852483: RM: mpqc3 [armel armhf mips mipsel] -- RoQA; FTBFS due to virtual memory exhaustion

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

There are only 2 GB (mips/mipsel) resp. 3 GB (armel/armhf)
address space available for userspace, and in mpqc3 there
is one source file where gcc would need more for compiling.

armel is additionally affected by #852481 (tbb FTBFS on armel).

Bug#852482: flask-limiter: please make the build reproducible

[Chris Lamb]

Source: flask-limiter
Version: 0.9.3-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that flask-limiter could not be built reproducibly.

It was previously using the current build path to parse its own
version number. There might be a cleaner, more general, solution
so this could be considered a WIP patch.


Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/versioneer.py b/versioneer.py
index 3b03c13..59acbb7 100644
--- a/versioneer.py
+++ b/versioneer.py
@@ -491,6 +491,12 @@ def write_to_version_file(filename, versions):
 
 
 def get_versions(default=DEFAULT, verbose=False):
+import subprocess
+debian_version = subprocess.check_output(('dpkg-parsechangelog', 
'-SVersion'))
+return {
+'full': '', 
+'version': debian_version.split('-', 1)[0],
+}
 # returns dict with two keys: 'version' and 'full'
 assert versionfile_source is not None, "please set 
versioneer.versionfile_source"
 assert tag_prefix is not None, "please set versioneer.tag_prefix"

Bug#852481: tbb FTBFS on armel

[Adrian Bunk]

Source: tbb
Version: 4.3~20150611-2
Severity: important

https://buildd.debian.org/status/logs.php?pkg=tbb=armel

...
g++ -c -MMD -DTBB_USE_DEBUG  -g -O0 -DUSE_PTHREAD -Wa,-mimplicit-it=thumb   -g 
-O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fno-rtti -fno-exceptions -D__TBBMALLOC_BUILD=1 
-Wno-parentheses -Wno-non-virtual-dtor -fPIC -I../../src 
-I../../src/rml/include -I../../include -I../../src/tbbmalloc 
-I../../src/tbbmalloc -I. ../../src/tbbmalloc/frontend.cpp
echo "INPUT (libtbbmalloc_debug.so.2)" > libtbbmalloc_debug.so
g++ -E -x c++ ../../src/tbbmalloc/lin32-tbbmalloc-export.def -DTBB_USE_DEBUG  
-g -O0 -DUSE_PTHREAD -Wa,-mimplicit-it=thumb   -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-rtti 
-fno-exceptions -D__TBBMALLOC_BUILD=1 -Wno-parentheses -Wno-non-virtual-dtor 
-I../../src -I../../src/rml/include -I../../include > tbbmalloc.def
g++ -c -MMD -DTBB_USE_DEBUG  -g -O0 -DUSE_PTHREAD -Wa,-mimplicit-it=thumb  
-Wall -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wno-parentheses -Wno-non-virtual-dtor -fPIC 
-D__TBBMALLOC_BUILD=1 -I../../src -I../../src/rml/include -I../../include 
-I../../src/tbbmalloc -I../../src/tbbmalloc ../../src/tbbmalloc/proxy.cpp
g++ -c -MMD -DTBB_USE_DEBUG  -g -O0 -DUSE_PTHREAD -Wa,-mimplicit-it=thumb  
-Wall -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wno-parentheses -Wno-non-virtual-dtor -fPIC 
-D__TBBMALLOC_BUILD=1 -I../../src -I../../src/rml/include -I../../include 
-I../../src/tbbmalloc -I../../src/tbbmalloc 
../../src/tbbmalloc/tbb_function_replacement.cpp
echo "INPUT (libtbbmalloc_proxy_debug.so.2)" > libtbbmalloc_proxy_debug.so
g++ -E -x c++ ../../src/tbbmalloc/lin32-proxy-export.def -DTBB_USE_DEBUG  -g 
-O0 -DUSE_PTHREAD -Wa,-mimplicit-it=thumb  -Wall -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wno-parentheses -Wno-non-virtual-dtor -I../../src 
-I../../src/rml/include -I../../include > tbbmallocproxy.def
/tmp/ccI0Gvmd.s: Assembler messages:
/tmp/ccI0Gvmd.s:117: Error: selected processor does not support `clz r4,r5' in 
ARM mode
/tmp/ccI0Gvmd.s:506: Error: selected processor does not support `clz r5,r4' in 
ARM mode
../../build/Makefile.tbbmalloc:63: recipe for target 'frontend.o' failed
make[3]: *** [frontend.o] Error 1
make[3]: Leaving directory 
'/«PKGBUILDDIR»/build/linux_armv7_gcc_cc5.3.1_libc2.22_kernel3.16.0_debug'
Makefile:36: recipe for target 'tbbmalloc' failed
make[2]: *** [tbbmalloc] Error 2

Bug#838712: dvipng command line seems messed up

[Jeroen Gremmen]

the dvipng command line (as shown in the logging below) does not seem to 
be correct.

please analyse and fix.


+---+
|mathTeX vers 1.03, Copyright(c) 2007-2009, John Forkosh Associates, Inc|
+---+
| mathTeX is free software, licensed to you under terms of the GNU/GPL  |
|   and comes with absolutely no warranty whatsoever.   |
| See http://www.forkosh.com/mathtex.html for complete details. |
+---+

mathTeX> running image: /var/htdocs/supper.de/cgi-bin/mathtex.cgi

mathTeX> input expression: \msglevel{9}\png x

mathTeX> Built-in timelimit: warn/killtime=-1/10, path=none

mathTeX> working directory: 1ef3d4270d67e874df07cea6c37d3596

mathTeX> latex command executed:
 /usr/bin/latex latex.tex < reply.txt >latex.out 2>latex.err

mathTeX> system() return status: 0

mathTeX> output image file: mathtex/1ef3d4270d67e874df07cea6c37d3596.png

mathTeX> dvipng command executed:
 /usr/bin/dvipng --png% - 120amma %%ga2.5 ansparansparent -T
 tight -v -o
 ../mathtex/1ef3d4270d67e874df07cea6c37d3596.png
 latex.dvi >dvipng.out 2>dvipng.err

mathTeX> message#10 succeeded:
 (10) dvipng ran but failed: