Bug#851828: oclgrind FTBFS on armhf: test failures

[Adrian Bunk]

Source: oclgrind
Version: 16.10-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=oclgrind=armhf=16.10-1=1484675768=0

...
  Start 75: uninitialized/uninitialized_local_array
  Start 76: uninitialized/uninitialized_local_ptr
73/86 Test #76: uninitialized/uninitialized_local_ptr 
.***Failed0.15 sec
Running test with optimisations
Test returned non-zero value (-7)
FAILED

74/86 Test #74: uninitialized/uninitialized_address ...   
Passed0.36 sec
  Start 77: uninitialized/uninitialized_local_variable
  Start 78: uninitialized/uninitialized_packed_struct_memcpy
75/86 Test #75: uninitialized/uninitialized_local_array 
...***Failed0.27 sec
Running test with optimisations
Test returned non-zero value (-7)
FAILED

  Start 79: uninitialized/uninitialized_padded_struct_memcpy
76/86 Test #77: uninitialized/uninitialized_local_variable    
Passed0.42 sec
77/86 Test #78: uninitialized/uninitialized_packed_struct_memcpy ..   
Passed0.41 sec
  Start 80: uninitialized/uninitialized_padded_nested_struct_memcpy
  Start 81: uninitialized/uninitialized_private_array
78/86 Test #79: uninitialized/uninitialized_padded_struct_memcpy ..   
Passed0.31 sec
79/86 Test #81: uninitialized/uninitialized_private_array 
.***Failed0.17 sec
Running test with optimisations
Test returned non-zero value (-7)
FAILED

  Start 82: wait_event/wait_event_chained
  Start 83: wait_event/wait_event_divergent
80/86 Test #80: uninitialized/uninitialized_padded_nested_struct_memcpy ...   
Passed0.28 sec
  Start 84: wait_event/wait_event_duplicates
81/86 Test #83: wait_event/wait_event_divergent ...   
Passed0.31 sec
82/86 Test #82: wait_event/wait_event_chained .   
Passed0.41 sec
  Start 85: wait_event/wait_event_invalid
  Start 86: rt_map_buffer
83/86 Test #84: wait_event/wait_event_duplicates ..   
Passed0.31 sec
84/86 Test #86: rt_map_buffer .   
Passed0.31 sec
85/86 Test #85: wait_event/wait_event_invalid .   
Passed0.31 sec
86/86 Test #32: bugs/many_alloca ..   
Passed   30.88 sec

97% tests passed, 3 tests failed out of 86

Total Test time (real) =  34.03 sec

The following tests FAILED:
 75 - uninitialized/uninitialized_local_array (Failed)
 76 - uninitialized/uninitialized_local_ptr (Failed)
 81 - uninitialized/uninitialized_private_array (Failed)
Errors while running CTest
Makefile:109: recipe for target 'test' failed
make[1]: *** [test] Error 8

Bug#851640: --debbuildopts not propagated anymore to cowbuilder

[Vincent Bernat]

 ❦ 17 janvier 2017 22:22 +0100, Vincent Bernat  :

>> Actually, breaking it completely wasn't my intention, I'll reinstate
>> support for it, sorry for the disruption.
>
> The pbuilder from git works fine for me. Thanks!

Well, using "-nc" from gbp buildpackage doesn't work. Is it related or
should I investigate more?
-- 
The very ink with which all history is written is merely fluid prejudice.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#851818: [pkg-go] Bug#851818: golang-glide: Collision in binary vs source package namespaces

[Vincent Bernat]

 ❦ 19 janvier 2017 02:23 +0100, Guillem Jover  :

> Source: golang-glide
> Version: 0.12.3-1
> Severity: important
>
> Hi!
>
> This source package generates a binary package named glide. But there
> was already a source package in the archive named glide. This creates
> great confusion in our infrastructure. For starters the bugs
> previously assigned to the glide source package are now "owned" by the
> glide binary package. :( Notifications and similar are now sent to both
> source and binary glide packages.
>
> Although the namespaces are in principle somewhat independent, creating
> cross-collisions has been frowned upon for a long time. So I'd like to
> ask that you rename the glide binary package to something else.

Sorry for that. I don't have a clear path to solve this. If I use a new
binary package name, I should do a transition package with the old name,
but this would defeat the purpose. But as we are close to the freeze,
it's now or never.
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#849836: zekr: Missing dependency on libwebkitgtk-1.0-0

[Christoph Biedl]

Christoph Biedl wrote...

> That's indeed a no-brainer. I've prepared an NMU as below and will
> upload it to DELAYED/2 tomorrow.

Now uploaded, with a small fix:

> +  * Add install dependency on xserver-xorg-input-all. Closes: #849836

s/xserver-xorg-input-all/libwebkitgtk-1.0-0/

Christoph


signature.asc
Description: Digital signature

Bug#848236: Remaining issue with gbrowse - any help (Was: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: ...)

[Andreas Tille]

On Wed, Jan 18, 2017 at 02:21:04PM -0500, Lincoln Stein wrote:
> Yes, I'll remove it immediately and apply the patches to bio::graphics as
> well.

Fine.  Do you intend to do a micro release (say 2.56.1) after this change
or should I remove the file here locally for the time beeing?  Both would
be fine but I want to know in advance.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#851827: scim-qt-immodule seems to be not working with Qt5 apps

[Artem]

Package: scim-qt-immodule
Version: 1.4.17-1
Severity: normal

Dear Maintainer,

here are my answers to the following questions
   * What led up to the situation?
noticed Qupzilla v1.8.9 did not react to the scim-triggers (ctrl+space)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
debian testing net install with only standard utilities by default. up-to date.
xorg is started by startx. 
scim, scim-pinyin, scim-gtk-immodule, scim-qt-immodule, scim-modules-table, 
scim-tables-additional are both installed. 
Smart pinyin and russian traditional input methods are added to the default one.
scim -d is on my .xinitrc right before exec wmaker.
export GTK_IM_MODULE=scim, export QT_IM_MODULE=scim are on my .bashrc file.
keepasx (Qt4 app) seems to change input methods just fine.
GTK apps (leafpad, firefox, libreoffice) all seem to react just fine on 
scim-triggers
   * What was the outcome of this action?
No input change was recorded. Journalctl | tail -n 20 or journalctl | grep scim 
both don't seem to record any errors.
for example 
user2@debian:~$ sudo journalctl | grep scim
[sudo] password for user2: 
Jan 19 15:22:45 debian scim-bridge[717]: Cleanup, done. Exitting...
Jan 19 15:23:34 debian scim-bridge[730]: Cleanup, done. Exitting...
Jan 19 15:25:47 debian scim-bridge[843]: Cleanup, done. Exitting...
Jan 19 15:26:46 debian sudo[858]:user2 : TTY=pts/0 ; PWD=/home/user2 ; 
USER=root ; COMMAND=/usr/bin/apt-cache search scim
Jan 19 15:29:45 debian scim-bridge[977]: Cleanup, done. Exitting...
Jan 19 15:30:22 debian scim-bridge[998]: Cleanup, done. Exitting...
Jan 19 15:58:48 debian scim-bridge[1471]: Cleanup, done. Exitting...
Jan 19 15:59:21 debian scim-bridge[1482]: Cleanup, done. Exitting...
Jan 19 16:03:25 debian scim-bridge[1734]: Cleanup, done. Exitting...
Jan 19 16:19:06 debian scim-bridge[2046]: Cleanup, done. Exitting...
Jan 19 16:19:32 debian scim-bridge[2060]: Cleanup, done. Exitting...
Jan 19 16:20:05 debian scim-bridge[2115]: Cleanup, done. Exitting...
   * What outcome did you expect instead?
Input method would change, would start the additional panel stating the current 
input mode

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

Kernel: Linux 4.8.0-2-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 scim-qt-immodule depends on:
ii  libc6  2.24-8
ii  libgcc11:6.2.1-5
ii  libqtcore4 4:4.8.7+dfsg-11
ii  libqtgui4  4:4.8.7+dfsg-11
ii  libstdc++6 6.2.1-5
ii  scim   1.4.17-1
ii  scim-im-agent  1.4.17-1

scim-qt-immodule recommends no packages.

scim-qt-immodule suggests no packages.

-- no debconf information

best wishes,

Bug#851726: liggghts: FTBFS on single-CPU machines (not enough slots available)

[Graham Inggs]

See #850229.

Bug#851825: ethtool: ifdown/ifup sequence fails if offload_tx off is set in iface stanza

[Daniel Reichelt]

> 8<-
> pre-up ethtool --offload $IFACE tx off
> >8-



Copy/paste error. The workaround should have read:

8<-
pre-up ethtool --offload $IFACE tx on
>8-




signature.asc
Description: OpenPGP digital signature

Bug#847289: xsane-common: xsane can no longer find USB scanner HP OfficeJet 6310

[Jörg Frings-Fürst]

Hello,

no answer since more the 6 weeks.

Closed.


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#851826: pulseaudio: USB headset detected, but no sound

[MH]

Package: pulseaudio
Version: 9.0-5
Severity: important

Dear Maintainer,

Pulseaudio correctly detects USB headset (headphones and microphone) but sound
is only output through external speakers.

*** 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:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 4.8.0-2-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pulseaudio depends on:
ii  adduser  3.115
ii  libasound2   1.1.2-1
ii  libasound2-plugins   1.1.1-1
ii  libc62.24-8
ii  libcap2  1:2.25-1
ii  libdbus-1-3  1.10.14-1
ii  libgcc1  1:6.2.1-5
ii  libice6  2:1.0.9-1+b1
ii  libltdl7 2.4.6-2
ii  liborc-0.4-0 1:0.4.26-2
ii  libpulse09.0-5
ii  libsm6   2:1.2.2-1+b1
ii  libsndfile1  1.0.27-1
ii  libsoxr0 0.1.2-2
ii  libspeexdsp1 1.2~rc1.2-1
ii  libstdc++6   6.2.1-5
ii  libsystemd0  232-8
ii  libtdb1  1.3.11-2
ii  libudev1 232-8
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.4-2
ii  libx11-xcb1  2:1.6.4-2
ii  libxcb1  1.12-1
ii  libxtst6 2:1.2.3-1
ii  lsb-base 9.20161125
ii  pulseaudio-utils 9.0-5

Versions of packages pulseaudio recommends:
ii  rtkit  0.11-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
pn  pavucontrol  
pn  pavumeter
ii  udev 232-8

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

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

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

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

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

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; 

Bug#851825: ethtool: ifdown/ifup sequence fails if offload_tx off is set in iface stanza

[Daniel Reichelt]

found 851825 ethtool/1:3.16-1
found 851825 ethtool/1:3.16-1


jessie is also affected



signature.asc
Description: OpenPGP digital signature

Bug#851777: Remmina and RDGateway issue 851...@bugs.debian.org.

[Jörg Frings-Fürst]

Hello Duncan,

thank you for spending your time helping to make Debian better with
this bug report. 

First please use reportbug to file a new bug.

The error was here:

[quote]
tcp_connect: getaddrinfo (Name or service not known)
Error: protocol security negotiation or connection failure
[/quote]

I think that in this moment the URL DEMO-RDS-01.iventuredemo.local
can't translate to the IP.

Thats is an error from your system and/or your network and not from
remmina.

So I close this bug.

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#851825: ethtool: ifdown/ifup sequence fails if offload_tx off is set in iface stanza

[Daniel Reichelt]

Package: ethtool
Version: 1:4.8-1
Severity: normal

Hi,

in network/interfaces I have set the option "offload_tx off" for eth0. This
causes `ifdown eth0 ; ifup eth0` to fail when offloading already
was set to off.

The culprit is ethtool, which inconsistently exits 0 or 1 when offloading is
enabled/disabled repeatedly:


8<-
# offloading initially off
# ethtool --offload eth0 tx on ; echo $?
Actual changes:
tx-checksum-ipv6: on
tcp-segmentation-offload: on
tx-tcp6-segmentation: on
0
# ethtool --offload eth0 tx on ; echo $?
0
# ethtool --offload eth0 tx on ; echo $?
0

# ^--- repeated enabling returns no error


# ethtool --offload eth0 tx off ; echo $?
Actual changes:
tx-checksum-ipv6: off
tcp-segmentation-offload: off
tx-tcp6-segmentation: off [requested on]
0

# ^--- initial disabling is ok

# ethtool --offload eth0 tx off ; echo $?
Could not change any device features
1
# ethtool --offload eth0 tx off ; echo $?
Could not change any device features
1

# ^--- repeated disabling returns 1
>8-





For now I'm using this workaround in the eth0 stanza:

8<-
pre-up ethtool --offload $IFACE tx off
>8-



Cheers

Daniel


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ethtool depends on:
ii  libc6  2.24-9

ethtool recommends no packages.

ethtool suggests no packages.

-- Configuration Files:
/etc/network/if-up.d/ethtool changed [not included]

-- no debconf information

Bug#851824: ITP: python-humanfriendly -- Python library to make user friendly text interfaces

[Gaurav Juvekar]

Package: wnpp
Severity: wishlist
Owner: Gaurav Juvekar 

* Package name: python-humanfriendly
  Version : 2.3.2
  Upstream Author : Peter Odding 
* URL : https://humanfriendly.readthedocs.io
* License : MIT/X
  Programming Lang: Python
  Description : Python library to make user friendly text interfaces

The functions and classes in the `humanfriendly` package can be used to make
text interfaces more user friendly. Some example features:

- Parsing and formatting numbers, file sizes, pathnames and timespans in
  simple, human friendly formats.

- Easy to use timers for long running operations, with human friendly
  formatting of the resulting timespans.

- Prompting the user to select a choice from a list of options by typing the
  option's number or a unique substring of the option.

- Terminal interaction including text styling (ANSI escape sequences), user
  friendly rendering of usage messages and querying the terminal for its
  size.

This package is also a dependency for python-coloredlogs (RFP #780187)

This module will be maintained within Python Modules team. I will also
need a sponsor for uploading.



signature.asc
Description: OpenPGP digital signature

Bug#851618: [Pkg-lirc-maint] Bug#851618: lirc: adequate reports multiple obsolete-conffiles for lirc Package: lirc

[Paul Wise]

On Thu, 2017-01-19 at 06:15 +0100, Alec Leamas wrote:

> Question is still *why* adequate flagged these files as obsolete...

It is dpkg that flagged them as obsolete, adequate just relays that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#851618: [Pkg-lirc-maint] Bug#851618: lirc: adequate reports multiple obsolete-conffiles for lirc Package: lirc

[Alec Leamas]

On 19/01/17 01:44, Paul Wise wrote:

dpkg doesn't handle removal of conffiles when they disappear from
packages, so the package postinst files need to handle removing
obsolete unmodified conffiles from user systems to avoid cruft
building up.


Thanks fpr reply. Since none of the files flagged  by adequate are 
actually obsolete I will close this bug shortly.


Question is still *why* adequate flagged these files as obsolete...

Cheers!

--aled

Bug#790492: zbar-tools: zbarimg segfault on bad URL

[Kyanos]

On Mon, 29 Jun 2015 14:49:20 -0400 Daniel Kahn Gillmor
 wrote:
> Package: zbar-tools
> Version: 0.10+doc-10
> Severity: normal
> 
> 0 dkg@alice:~$ $ zbarimg http://no-such-domain./
> error : No such file or directory
> error : Unknown IO error
> error : Unknown IO error
> error : Unknown IO error
>  [ ... dozens more Unknown IO error messages ...]
> error : Unknown IO error
> Segmentation fault
> 139 dkg@alice:~$ 
> 
> This appears to be reproducible with any HTTP 404 response or dns not
> found.
> 
> --dkg
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.0.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 zbar-tools depends on:
> ii  libc6  2.19-18
> ii  libgomp1   5.1.1-12
> ii  libjpeg62-turbo1:1.4.0-7
> ii  libmagickcore-6.q16-2  8:6.8.9.9-5
> ii  libmagickwand-6.q16-2  8:6.8.9.9-5
> ii  libv4l-0   1.6.3-1
> ii  libzbar0   0.10+doc-10
> 
> zbar-tools recommends no packages.
> 
> zbar-tools suggests no packages.
> 
> -- debconf-show failed
> 
> 

On 06/08/2016 05:04 PM, Kyanos wrote:
> Package: zbar-tools
> Version: 0.10+doc-10+b1
> Followup-For: Bug #790492
>
> The backtrace from GDB suggests that this is a bug in ImageMagick.
> Using the "convert" command from ImageMagick gives the same result.
>
>
> $ convert http://test.test/ out.png
> error : No such file or directory
> error : Unknown IO error
> error : Unknown IO error
> error : Unknown IO error
> [...]
> error : Unknown IO error
> Segmentation fault
>

Several versions of ImageMagick have been uploaded since this bug was
reported, and during that time it seems that the bug has been fixed. The
command no longer segfaults.

$ zbarimg http://no-such-domain./
error : No such file or directory
ERROR: no data returned `http://no-such-domain./' @
error/url.c/ReadURLImage/247


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'stable-updates'), (300,
'oldstable-updates'), (300, 'stable'), (300, 'oldstable')
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages zbar-tools depends on:
ii  libc6  2.24-8
ii  libgomp1   6.2.1-5
ii  libjpeg62-turbo1:1.5.1-2
ii  libmagickcore-6.q16-3  8:6.9.7.0+dfsg-2
ii  libmagickwand-6.q16-3  8:6.9.7.0+dfsg-2
ii  libv4l-0   1.10.1-1
ii  libzbar0   0.10+doc-10.1

zbar-tools recommends no packages.

zbar-tools suggests no packages.

-- no debconf information

Bug#851823: Changing default emacs to 25 to allow emacs24 removal -- RoM

[Rob Browning]

Package: release.debian.org

We want to remove emacs24 from stretch, and we think we've managed to
fix all of the affected packages[1].  We're consulting you because we
thought this might be considered a transition, though perhaps a minor
one relative to others.

At this point, we believe we only need to upload a version of
emacs-defaults that switches the emacs and emacs-nox metapackages from
24 to 25.

Would that be acceptable?  If so, we'll upload, and then file the
ftp.debian.org RM emacs24 bug.

According to "dak rm -Rn emacs24", the emacs and emacs-nox metapackages
are indeed the only broken depends.

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

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

Bug#851630: beets: UnicodeDecodeError: 'utf8' codec can't decode

[Carl Suster]

Control: forwarded -1 https://github.com/beetbox/beets/issues/2168

The problem with decoding errors in broken utf8 filenames was fixed upstream and 
the fix seems to have made it into releases starting from 1.4.1

Bug#789684: libgpg-error: cross compilation error gpgrt_lock_t not found

[Deepak Gaur]

Hello Daniel,

I tired to compile the latest version of libgpg-error (1.26) with powerpc 
toochain but still got the same error. Please
see attached compile log and make environment

The problem comes with powerpc toolchain it seems. With MIPS toolchain it is 
getting cross - compiled easily. I don't
have a native compiler on-board target hence won't be able to provide 
lock-obj-pub.powerpc-*.h

regards,

Deepak Gaur

On Wed, 18 Jan 2017 11:37:14 -0500, Daniel Kahn Gillmor wrote 
Hi Deepak--

 On Tue 2015-06-23 07:20:57 -0400, Deepak wrote: 
 > While trying to cross compile libgpg-error 1.19 for powerpc target GCC 4.7.4 
 > glibc 2.19 got following error 
 […] 
 >         Platform: powerpc-83xx-linux-gnu 
 […] 
 > if test -f lock-obj-pub.native.h; then rm lock-obj-pub.native.h; fi 
 > ../mkheader linux-gnu powerpc-83xx-linux-gnu  ./gpg-error.h.in \ 
 >                     ../config.h 1.19 0x011300 >gpg-error.h 
 > ../gpg-error.h.in:320: error including `./syscfg/lock-obj-pub.linux-gnu.h': 
 > No such file or directory 
 > make[2]: *** [gpg-error.h] Error 1 
 > make[2]: Leaving directory `/home/temp/libgpg-error-1.19/src' 
 > make[1]: *** [all-recursive] Error 1 
 > make[1]: Leaving directory `/home/temp/libgpg-error-1.19' 
 > make: *** [all] Error 2

 Can you try this rebuild again?  sorry for the blast from the past :)

 If it fails, is it possible to do a native build once on that platform 
 and send a copy of src/syscfg/lock-obj-pub.powerpc-*.h to this bug 
 report?

 Regards,

        --dkg

Deepak Gaur 
 

 
 ::Disclaimer:: 
 

 
 The contents of this email and any attachment(s) are confidential and intended 
 for the named recipient(s) only. It shall not attach any liability on C-DOT. 
 Any views or opinions presented in this email are solely those of the author 
 and  may  not  necessarily  reflect  the  opinions  of  C-DOT.  Any  form of 
 reproduction, dissemination, copying, disclosure, modification, distribution 
 and / or publication of this message without the prior written consent of the 
 author of this e-mail is strictly prohibited. If you have received this email 
 in error please delete it and notify the sender immediately.

 




CROSS_COMPILE.sh
Description: application/shellscript
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for powerpc-83xx-linux-gnu-strip... powerpc-83xx-linux-gnu-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports nested variables... (cached) yes
checking build system type... i686-pc-linux-gnu
checking host system type... powerpc-83xx-linux-gnu
configure: autobuild project... libgpg-error
configure: autobuild revision... 1.26
configure: autobuild hostname... Maverick
configure: autobuild timestamp... 20170119-095407
checking for powerpc-83xx-linux-gnu-gcc... powerpc-83xx-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether powerpc-83xx-linux-gnu-gcc accepts -g... yes
checking for powerpc-83xx-linux-gnu-gcc option to accept ISO C89... none needed
checking whether powerpc-83xx-linux-gnu-gcc understands -c and -o together... 
yes
checking for style of include used by make... GNU
checking dependency style of powerpc-83xx-linux-gnu-gcc... gcc3
checking how to run the C preprocessor... powerpc-83xx-linux-gnu-cpp
checking for gawk... (cached) gawk
checking for powerpc-83xx-linux-gnu-ar... powerpc-83xx-linux-gnu-ar
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by 

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

[Jason Heeris]

Thanks to everyone who pointed me to the Snapshot repo. I've managed to
narrow down the problem now.

I updated the makefile to only do up to the bootstrap stage, because that's
where it fails. I changed the version of the live-build package that was
installed, and *only* live-build, and tested it each time. For each test, I
changed only the "--archive-areas" flag to be either "main" or "main
firmware non-free". The results were:

live-build_20151215_all.deb
WORKS - with main only
WORKS - with main + firmware + non-free

live-build_20161202_all.deb
WORKS - with main only
FAILS - with main + firmware + non-free

live-build_20161216_all.deb
WORKS - with main only
FAILS - with main + firmware + non-free

So even though "firmware" is a valid archive area for Raspbian, somewhere
between 20151215 and 20161202 it stopped working.

I've attached the makefile and a log of a failed build.

- Jason Heeris


Makefile
Description: Binary data
[2017-01-19 11:57:22] lb bootstrap 
P: Setting up cleanup function
[2017-01-19 11:57:22] lb bootstrap_cache restore
[2017-01-19 11:57:22] lb bootstrap_debootstrap 
P: Begin bootstrapping system...
P: If the following stage fails, the most likely cause of the problem is with your mirror configuration or a caching proxy.
P: Running debootstrap (download-only)... 
I: Retrieving InRelease 
I: Retrieving Packages 
I: Validating Packages 
I: Retrieving Packages 
I: Validating Packages 
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: acl adduser cpio dmsetup init-system-helpers initramfs-tools insserv klibc-utils kmod libaudit-common libaudit1 libbz2-1.0 libcap2 libcap2-bin libcryptsetup4 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper1.02.1 libdrm2 libgcrypt20 libgpg-error0 libklibc libkmod2 libncursesw5 libnih-dbus1 libnih1 libpcre3 libpng12-0 libprocps3 libsemanage-common libsemanage1 libslang2 libsystemd0 libudev1 libustr-1.0-1 makedev plymouth procps systemd systemd-sysv udev 
I: Found additional base dependencies: libbsd0 libcwidget3 libdns-export100 libestr0 libffi6 libgmp10 libgnutls-deb0-28 libgnutls-openssl27 libhogweed2 libicu52 libidn11 libirs-export91 libisc-export95 libisccfg-export90 libjson-c2 liblogging-stdlog0 liblognorm1 libnettle4 libnfnetlink0 libp11-kit0 libpsl0 libsigc++-2.0-0c2a libsqlite3-0 libtasn1-6 
I: Checking component main on http://archive.raspbian.org/raspbian...
I: Retrieving acl 2.2.52-2
I: Validating acl 2.2.52-2
I: Retrieving adduser 3.113+nmu3
I: Validating adduser 3.113+nmu3
I: Retrieving apt 1.0.9.8.4
I: Validating apt 1.0.9.8.4
I: Retrieving apt-utils 1.0.9.8.4
I: Validating apt-utils 1.0.9.8.4
I: Retrieving aptitude 0.6.11-1
I: Validating aptitude 0.6.11-1
I: Retrieving aptitude-common 0.6.11-1
I: Validating aptitude-common 0.6.11-1
I: Retrieving base-files 8+rpi1
I: Validating base-files 8+rpi1
I: Retrieving base-passwd 3.5.37
I: Validating base-passwd 3.5.37
I: Retrieving bash 4.3-11+deb8u1
I: Validating bash 4.3-11+deb8u1
I: Retrieving bsdmainutils 9.0.6
I: Validating bsdmainutils 9.0.6
I: Retrieving bsdutils 1:2.25.2-6
I: Validating bsdutils 1:2.25.2-6
I: Retrieving coreutils 8.23-4
I: Validating coreutils 8.23-4
I: Retrieving cpio 2.11+dfsg-4.1+deb8u1
I: Validating cpio 2.11+dfsg-4.1+deb8u1
I: Retrieving cron 3.0pl1-127+deb8u1
I: Validating cron 3.0pl1-127+deb8u1
I: Retrieving dash 0.5.7-4
I: Validating dash 0.5.7-4
I: Retrieving debconf 1.5.56
I: Validating debconf 1.5.56
I: Retrieving debconf-i18n 1.5.56
I: Validating debconf-i18n 1.5.56
I: Retrieving debianutils 4.4
I: Validating debianutils 4.4
I: Retrieving diffutils 1:3.3-1
I: Validating diffutils 1:3.3-1
I: Retrieving dmidecode 2.12-3
I: Validating dmidecode 2.12-3
I: Retrieving dmsetup 2:1.02.90-2.2+deb8u1
I: Validating dmsetup 2:1.02.90-2.2+deb8u1
I: Retrieving dpkg 1.17.27
I: Validating dpkg 1.17.27
I: Retrieving e2fslibs 1.42.12-2
I: Validating e2fslibs 1.42.12-2
I: Retrieving e2fsprogs 1.42.12-2
I: Validating e2fsprogs 1.42.12-2
I: Retrieving findutils 4.4.2-9
I: Validating findutils 4.4.2-9
I: Retrieving gcc-4.6-base 4.6.4-5+rpi1
I: Validating gcc-4.6-base 4.6.4-5+rpi1
I: Retrieving gcc-4.7-base 4.7.3-11+rpi1
I: Validating gcc-4.7-base 4.7.3-11+rpi1
I: Retrieving gcc-4.8-base 4.8.4-1
I: Validating gcc-4.8-base 4.8.4-1
I: Retrieving gcc-4.9-base 4.9.2-10
I: Validating gcc-4.9-base 4.9.2-10
I: Retrieving gnupg 1.4.18-7+deb8u3
I: Validating gnupg 1.4.18-7+deb8u3
I: Retrieving gpgv 1.4.18-7+deb8u3
I: Validating gpgv 1.4.18-7+deb8u3
I: Retrieving grep 2.20-4.1
I: Validating grep 2.20-4.1
I: Retrieving groff-base 1.22.2-8
I: Validating groff-base 1.22.2-8
I: Retrieving gzip 1.6-4
I: Validating gzip 1.6-4
I: Retrieving hostname 3.15
I: Validating hostname 3.15
I: Retrieving ifupdown 0.7.53.1
I: Validating ifupdown 0.7.53.1
I: Retrieving info 5.2.0.dfsg.1-6
I: Validating info 5.2.0.dfsg.1-6
I: Retrieving init 1.22
I: 

Bug#829533: kdenlive: Track effects are broken

[Kyanos]

fixed 829533 16.12.0-1
thanks

On 07/03/2016 10:37 PM, Kyanos wrote:
> Package: kdenlive
> Version: 16.04.2-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Effects on tracks are not working. I tried this with multiple effects
> and they are all broken when applied to tracks (as opposed to clips).
> 
> Audio effects are ignored, while video clips cause a crash upon trying
> to preview the video in the Project Monitor. GDB session follows:
> 
> [snip]

This bug seems to be fixed in version 16.12.0-1, which I downloaded from
unstable.

Kyanos

Bug#851016: beets: FTBFS: Test failures

[Carl Suster]

This looks like https://github.com/beetbox/beets/issues/2153 i.e. that the 
current version of mutagen that we have in Debian (1.36) is incompatible with 
the version of beets (1.3.19). Quoting from that issue:


 > when beets 1.3.19 was released, Mutagen 1.33 didn't exist yet.
 > When that was released, it changed the way exceptions work, which
 > broke those tests. We've since fixed compatibility with the
 > latest version, but we can't go back in time and change the
 > version specifier for 1.3.19.

So the easiest way to fix this will be to update to the latest upstream beets in 
Debian.

Bug#851822: gnome-terminal: is unreachable via Alt+Tab in Gnome Wayland session

[Rene van Bevern]

Package: gnome-terminal
Version: 3.22.1-1
Severity: normal

Dear Maintainer,

when starting gnome-terminal in a Gnome Wayland session, its menu bar
is all grayed out (like in unfocused windows) although the window has
the focus (and the menu works).  While the window is focused, the top
bar of the Gnome shell shows a spinning wheel next to its name, as if
the Gnome Shell was still waiting for Gnome Terminal to be started.

All of this is cosmetic, but What is worse: gnome terminal does not
appear in the alt-tab list and therefore cannot be switched to using
alt+tab.

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

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

Versions of packages gnome-terminal depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gconf-service3.2.6-4
ii  gnome-terminal-data  3.22.1-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-8
ii  libdconf10.26.0-2
ii  libgconf-2-4 3.2.6-4
ii  libglib2.0-0 2.50.2-2
ii  libgtk-3-0   3.22.5-1
ii  libnautilus-extension1a  3.22.2-1
ii  libpango-1.0-0   1.40.3-3
ii  libuuid1 2.29-1
ii  libvte-2.91-00.46.1-1
ii  libx11-6 2:1.6.4-2

Versions of packages gnome-terminal recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.10.14-1
ii  dbus-x11 [dbus-session-bus]   1.10.14-1
ii  gvfs  1.30.3-1
ii  yelp  3.22.0-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#729200: [xserver-xorg-input-synaptics] Resting thumb or click not working

[Cihan Altinay]

The issue is still present in sid with
xserver-xorg-input-synaptics 1.9.0-1+b1

However, I just found that using the libinput driver makes the touchpad 
work perfectly.

All I did was:

# mkdir /etc/X11/xorg.conf.d
# cp /usr/share/X11/xorg.conf.d/40-libinput.conf 
/etc/X11/xorg.conf.d/90-libinput.conf


and restarted X.

Bug#851821: linux: Please enable CONFIG_TOUCHSCREEN_GOODIX

[russm-debian-bugs]

Source: linux
Version: 4.9.2-2
Severity: wishlist
Tags: patch

Dear Maintainer,

Please enable CONFIG_TOUCHSCREEN_GOODIX, for use on devices that have
this touchscreen hardware installed.

Thank you!



diff --git a/debian/config/config b/debian/config/config
index bd87c7f32..9dabf1feb 100644
--- a/debian/config/config
+++ b/debian/config/config
@@ -1423,7 +1423,7 @@ CONFIG_TOUCHSCREEN_HAMPSHIRE=m
 CONFIG_TOUCHSCREEN_EETI=m
 # CONFIG_TOUCHSCREEN_EGALAX is not set
 CONFIG_TOUCHSCREEN_FUJITSU=m
-# CONFIG_TOUCHSCREEN_GOODIX is not set
+CONFIG_TOUCHSCREEN_GOODIX=m
 # CONFIG_TOUCHSCREEN_ILI210X is not set
 CONFIG_TOUCHSCREEN_GUNZE=m
 # CONFIG_TOUCHSCREEN_ELAN is not set



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#850230: fabric: FTBFS (sbuild hangs)

[Andrew Starr-Bochicchio]

On Thu, Jan 5, 2017 at 5:05 AM, Santiago Vila  wrote:
> The bug should be reproducible with sbuild on a single CPU virtual machine.
> It always fail for me (I tried 10 times in different autobuilders), and
> it also fails here:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fabric.html

Hi Santiago,

Thanks for the report. I had been unable to reproduce this. I tried
locally with both sbuild and pbuilder with no issues. So I spun up a
single CPU VM with an sbuild environment and was able to reproduce
this issue there. Adding another core to the VM, it built successfully
again. After some further debugging, I seem to have tracked the issue
down to a specific test:

https://github.com/fabric/fabric/blob/1.13.1/tests/test_tasks.py#L420

It's going to require some more detective work to find the root cause,
but for now I'm going to disable it as part of the package build.

Thanks,

-- Andrew Starr-Bochicchio

   Debian Developer 
   Ubuntu Developer 
   PGP/GPG Key ID: 3B56E2BBD53FDCB1

Bug#851820: libmojolicious-plugin-assetpack-perl: FTBFS: Failed 6/36 test programs. 20/242 subtests failed.

[Chris Lamb]

Source: libmojolicious-plugin-assetpack-perl
Version: 1.30-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

libmojolicious-plugin-assetpack-perl fails to build from source in 
unstable/amd64:

  […]

  Failed 2/10 subtests 
  t/reloader-process.t . skipped: cpanm CSS::Sass
  Mojo::Home::parse is DEPRECATED at t/Helper.pm line 22.
  Mojo::Home::rel_dir is DEPRECATED in favor of Mojo::Home::rel_file at 
«BUILDDIR»/blib/lib/Mojolicious/Plugin/AssetPack.pm line 28.
  Mojo::Home::parts is DEPRECATED at 
«BUILDDIR»/blib/lib/Mojolicious/Plugin/AssetPack.pm line 28.
  [Thu Jan 19 14:02:26 2017] [debug] GET "/"
  [Thu Jan 19 14:02:26 2017] [debug] Rendering template "index.html.ep" from 
DATA section
  [Thu Jan 19 14:02:26 2017] [debug] Processed asset "app.css". [36b3e7b800]
  [Thu Jan 19 14:02:26 2017] [debug] 200 OK (0.00268s, 373.134/s)
  [Thu Jan 19 14:02:26 2017] [debug] GET "/asset/36b3e7b800/t-reloader.css"
  [Thu Jan 19 14:02:26 2017] [debug] Routing to a callback
  [Thu Jan 19 14:02:26 2017] [debug] 200 OK (0.00057s, 1754.386/s)
  [Thu Jan 19 14:02:26 2017] [debug] GET "/mojo-assetpack-reloader-ws"
  [Thu Jan 19 14:02:26 2017] [debug] Routing to a callback
  [Thu Jan 19 14:02:26 2017] [debug] 101 Switching Protocols (0.000358s, 
2793.296/s)
  [Thu Jan 19 14:02:26 2017] [debug] GET "/"
  [Thu Jan 19 14:02:26 2017] [debug] Rendering cached template "index.html.ep" 
from DATA section
  [Thu Jan 19 14:02:26 2017] [debug] Processed asset "app.css". [5958b3a722]
  [Thu Jan 19 14:02:26 2017] [debug] 200 OK (0.001898s, 526.870/s)
  [Thu Jan 19 14:02:26 2017] [debug] GET "/asset/5958b3a722/t-reloader.css"
  [Thu Jan 19 14:02:26 2017] [debug] Routing to a callback
  [Thu Jan 19 14:02:26 2017] [debug] 200 OK (0.00088s, 1136.364/s)
  t/reloader.t . 
  ok 1 - GET /
  ok 2 - 200 OK
  ok 3 - element for selector "link[href="/asset/36b3e7b800/t-reloader.css"]" 
exists
  ok 4 - GET /asset/36b3e7b800/t-reloader.css
  ok 5 - exact match for content
  ok 6 - WebSocket handshake with /mojo-assetpack-reloader-ws
  ok 7 - WebSocket closed with status 1005
  ok 8 - GET /
  ok 9 - 200 OK
  ok 10 - element for selector "link[href="/asset/5958b3a722/t-reloader.css"]" 
exists
  ok 11 - GET /asset/5958b3a722/t-reloader.css
  ok 12 - exact match for content
  1..12
  ok
  Mojo::Home::parse is DEPRECATED at t/Helper.pm line 22.
  Mojo::Home::rel_dir is DEPRECATED in favor of Mojo::Home::rel_file at 
«BUILDDIR»/blib/lib/Mojolicious/Plugin/AssetPack.pm line 28.
  Mojo::Home::parts is DEPRECATED at 
«BUILDDIR»/blib/lib/Mojolicious/Plugin/AssetPack.pm line 28.
  [Thu Jan 19 14:02:26 2017] [debug] Processed asset "app.js". [7373328564]
  [Thu Jan 19 14:02:26 2017] [debug] GET "/"
  [Thu Jan 19 14:02:26 2017] [debug] Rendering template "index.html.ep" from 
DATA section
  [Thu Jan 19 14:02:26 2017] [debug] 200 OK (0.002382s, 419.815/s)
  [Thu Jan 19 14:02:26 2017] [debug] GET "/asset/7373328564/r1.tag"
  [Thu Jan 19 14:02:26 2017] [debug] Routing to a callback
  [Thu Jan 19 14:02:26 2017] [debug] 200 OK (0.000522s, 1915.709/s)
  t/riotjs-not-loaded.t  
  ok 1 - GET /
  ok 2 - 200 OK
  ok 3 - element for selector "link[href="/asset/7373328564/r1.tag"]" exists
  ok 4 - GET /asset/7373328564/r1.tag
  ok 5 - 200 OK
  ok 6 - Content-Type: text/css
  ok 7 - content is similar
  1..7
  ok
  t/riotjs.t ... skipped: TEST_RIOTJS=1
  Mojo::Home::parse is DEPRECATED at t/Helper.pm line 22.
  Mojo::Home::rel_dir is DEPRECATED in favor of Mojo::Home::rel_file at 
«BUILDDIR»/blib/lib/Mojolicious/Plugin/AssetPack.pm line 28.
  Mojo::Home::parts is DEPRECATED at 
«BUILDDIR»/blib/lib/Mojolicious/Plugin/AssetPack.pm line 28.
  [Thu Jan 19 14:02:27 2017] [debug] Processed asset "app.css". [681090d69b]
  t/route.t  
  ok 1 - one route
  ok 2 - two routes
  1..2
  ok
  t/sass-bin.t . skipped: TEST_SASS=1
  t/sass-dynamic-include.t . skipped: cpanm CSS::Sass
  t/sass-functions.t ... skipped: cpanm CSS::Sass
  t/sass-unable-to-download.t .. skipped: TEST_ONLINE=1
  t/sass-utf8.t  skipped: cpanm CSS::Sass
  t/sass.t . skipped: cpanm CSS::Sass
  t/typescript.t ... skipped: TEST_TYPESCRIPT=1
  t/util.t . 
  ok 1 - no_builder read-only
  ok 2 - no_builder
  ok 3 - no_builder with value
  ok 4 - with_builder read-only
  ok 5 - with_builder
  ok 6 - diag foo
  ok 7 - diag foo bar
  ok 8 - chdir
  ok 9 - back on track
  ok 10 - _install_gem
  ok 11 - _install_node
  ok 12 - _install_ruby
  1..12
  ok
  Mojo::Home::parse is DEPRECATED at t/Helper.pm line 22.
  Mojo::Home::rel_dir is DEPRECATED in favor of Mojo::Home::rel_file at 
«BUILDDIR»/blib/lib/Mojolicious/Plugin/AssetPack.pm line 28.
  Mojo::Home::parts is DEPRECATED at 

Bug#851756: RFS: telegram-desktop/1.0.0-2

[Коля Гурьев]

19.01.2017 00:23, Gianfranco Costamagna пишет:

I see tag for 1.0.1 pushed on github [1]


This is alpha version. It is not in upstream changelog on [1].

To be noted upstream author does not always publish the tags in time.

P.S.: I don't know how to put this remote changelog into the package.

[1] https://desktop.telegram.org/changelog

Bug#851179: chromium: dependency conflict

[Michael Gilbert]

> it appears that there isn't a version of virtualbox from debian-testing.

It got kicked out of testing because of an RC bug [0].  You can still
install the package from unstable, or just stick to stable for
everything.

Best wishes,
Mike

[0] http://tracker.debian.org/news/822936

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

[積丹尼 Dan Jacobson]

Package: flashplugin-nonfree

/usr/sbin/update-flashplugin-nonfree --install
ERROR: wget failed to download 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.24.0.0.194.sha512.i386.pgp.asc

Bug#851737: wmaker: Appearance-->Preference utility error (could not exec /usr/local/GNUStep/Applications/WPrefs.app/WPrefs

[Doug Torrance]

On 01/18/2017 03:51 AM, Artem wrote:

* What led up to the situation?
Noticed similiar behaviour of this package in other distros.
The latest package usually builds just fine from the upstream source by the 
default procedure of configure , make sudo make install with  no additional 
flags (though not tested on this particular install)
* What exactly did you do (or not do) that was effective (or ineffective)?
Cleanest fresh install of Debian Testing w/o DE, just standard utilities. only 
xorg and wmaker installed on top
   * What was the outcome of this action?
resulted error states Could not execute command: exec 
/usr/local/GNUStep/Applications/WPrefs.app/Wprefs
* What outcome did you expect instead?
It should've opened the exact same window as the top-right icon in dock (which 
states its path as /usr/bin/WPrefs)


Thanks for your report!

This is because the default menu file (/usr/share/WindowMaker/menu) 
hardcodes the location of WPrefs, which is definitely a bug.  I'll take 
a look at it and send a patch upstream in the near future.


Note that if the menu package (in wmaker's "Suggests") is installed, 
then the menu put together specifically for the Debian Window Maker 
package should appear.  It does correctly open WPrefs.


Doug

Bug#851772: nmu: madplay_0.15.2b-8.1

[Andreas Beckmann]

On 2017-01-18 18:54, Emilio Pozuelo Monfort wrote:
> On 18/01/17 17:38, Andreas Beckmann wrote:
>> Package: release.debian.org

>> nmu madplay_0.15.2b-8.1 . ANY . unstable . -m "Rebuild against libid3tag 
>> 0.15.1b-12"
>>
>> adequate reports:
>>
>>   madplay: symbol-size-mismatch /usr/bin/madplay => id3_build
>>
>> madplay was built against libid3tag 0.15.1b-11 (which was itself built
>> in 2014), while 0.15.1b-12 was built two years later with a newer
>> toolchain ...
> 
> If libid3tag's ABI changed, then it needs to rename it's binary package.

It's a const char[] that changed content (and length) between builds,
not sure whether this qualifies for an ABI break. But I agree that such
symbols should not be used.

char const id3_build[] = ""
# if defined(DEBUG)
  "DEBUG "
# elif defined(NDEBUG)
  "NDEBUG "
# endif

# if defined(EXPERIMENTAL)
  "EXPERIMENTAL "
# endif
;

> Also have you checked that no other rdeps are affected?

It's the only package in sid and stretch where adequate (called via
piuparts) reports this mismatch.


in jessie (0.15.1b-11):

$ nm -D -S /usr/lib/libid3tag.so.0.3.0 | grep id3_build
00010490 0008 R id3_build

$ hd -n 8 -s 0x10490 /usr/lib/libid3tag.so.0.3.0
00010490  4e 44 45 42 55 47 20 00   |NDEBUG .|

in sid (0.15.1b-12):

$ nm -D -S /usr/lib/x86_64-linux-gnu/libid3tag.so.0.3.0 | grep id3_build
00010b10 0001 R id3_build

$ hd -n 1 -s 0x10b10 /usr/lib/x86_64-linux-gnu/libid3tag.so.0.3.0
00010b10  00|.|


Andreas

Bug#851818: golang-glide: Collision in binary vs source package namespaces

[Guillem Jover]

Source: golang-glide
Version: 0.12.3-1
Severity: important

Hi!

This source package generates a binary package named glide. But there
was already a source package in the archive named glide. This creates
great confusion in our infrastructure. For starters the bugs
previously assigned to the glide source package are now "owned" by the
glide binary package. :( Notifications and similar are now sent to both
source and binary glide packages.

Although the namespaces are in principle somewhat independent, creating
cross-collisions has been frowned upon for a long time. So I'd like to
ask that you rename the glide binary package to something else.

Thanks,
Guillem

Bug#851816: O: git2cl -- simple tool to convert git logs to GNU ChangeLog format

[Paul Wise]

On Thu, 19 Jan 2017 12:08:29 +1100 Dmitry Smirnov wrote:

> Alternatively we could remove "git2cl" as it could be replaced with the 
> following command:
> 
> git log --pretty="format:%ad  %aN  <%aE>%n%n%x09* %s%n" --date=short

That command does not do the same thing, so git2cl should not be removed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#851817: Vendoring libraries

[Haruki TSURUMOTO]

Package: prometheus
Version: 1.2.3+ds2-5
Severity: serious
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org

Dear maintainers,
Prometheus depends on many libraries, including source codes located
into vendor directory.
Is this a violation for Debian Policy 4.13 ?
"4.13 Convenience copies of code"
https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

Some libraries of vendor/*  had already packaged in Debian,
 (ex: golang-github-hashicorp-go-cleanhttp-dev,
golang-github-hashicorp-consul-dev)
Can't we use these instead of vendoring method ?

Regards,

-- 
Haruki TSURUMOTO
PGP Fingerprint:3718 C84E 4EDA 1B5C 4F26 8639 9D3D EE3F 63A6 000E

Bug#851816: O: git2cl -- simple tool to convert git logs to GNU ChangeLog format

[Dmitry Smirnov]

Package: wnpp
Severity: normal

"git2cl" needs new maintainer...

Alternatively we could remove "git2cl" as it could be replaced with the 
following command:

git log --pretty="format:%ad  %aN  <%aE>%n%n%x09* %s%n" --date=short

-- 
Regards,
 Dmitry Smirnov.


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

Bug#851815: efivar: Bogus output for MBR partitions (disk signature)

[Dwayne Litzenberger]

Source: efivar
Version: 30-1
Severity: normal
Tags: patch upstream

format_media_dn() produces bogus media device paths for MBR partitions.  
Instead of displaying the MBR disk signature, the current logic 
apparently sign-extends its least-significant byte and returns a decimal 
number, still prefixed with "0x".  The result is nonsense like this:


   # blkid -o value -s PTUUID /dev/sdb
   927a7490
   # efibootmgr -v | grep debian
   Boot0002* debian
HD(3,MBR,0x4294967184,0xe89c,0x10)/File(\EFI\debian\grubx64.efi)

The "0x4294967184" returned by efibootmgr is really *decimal* 
4294967184, which is just 0xff90.  The correct output for this field 
would be "0x927a7490":


   # blkid -o value -s PTUUID /dev/sdb
   927a7490
   # efibootmgr -v | grep debian
   Boot0002* debian
HD(3,MBR,0x927a7490,0xe89c,0x10)/File(\EFI\debian\grubx64.efi)

Upstream pull request: https://github.com/rhinstaller/efivar/pull/79

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From e5dd44155fd91d9c3e8b31f897b0dc6ac4635742 Mon Sep 17 00:00:00 2001
From: Dwayne Litzenberger 
Date: Wed, 18 Jan 2017 16:35:46 -0800
Subject: [PATCH] format_media_dn: Fix formatting of disk signature for MBR
 partitions

The previous logic sign-extended the least-significant byte of the disk
signature and returned a decimal number prefixed with "0x", producing
nonsense like this:

# blkid -o value -s PTUUID /dev/sdb
927a7490
# efibootmgr -v | grep debian
Boot0002* debian 
HD(3,MBR,0x4294967184,0xe89c,0x10)/File(\EFI\debian\grubx64.efi)
# python -c 'print hex(4294967184)'
0xff90

With this change, it works properly:

Boot0002* debian 
HD(3,MBR,0x927a7490,0xe89c,0x10)/File(\EFI\debian\grubx64.efi)

Signed-off-by: Dwayne Litzenberger 
---
 src/dp-media.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/dp-media.c b/src/dp-media.c
index cde2ad8..6fd8dcf 100644
--- a/src/dp-media.c
+++ b/src/dp-media.c
@@ -36,8 +36,11 @@ _format_media_dn(char *buf, size_t size, const_efidp dp)
switch (dp->hd.signature_type) {
case EFIDP_HD_SIGNATURE_MBR:
format(buf, size, off, "HD",
-  "MBR,0x%"PRIu32",0x%"PRIx64",0x%"PRIx64")",
-  *(char *)dp->hd.signature,
+  "MBR,0x%"PRIx32",0x%"PRIx64",0x%"PRIx64")",
+  (uint32_t)dp->hd.signature[0] |
+  ((uint32_t)dp->hd.signature[1] << 8) |
+  ((uint32_t)dp->hd.signature[2] << 16) |
+  ((uint32_t)dp->hd.signature[3] << 24),
   dp->hd.start, dp->hd.size);
break;
case EFIDP_HD_SIGNATURE_GUID:
-- 
2.11.0

Bug#851790: installation-reports: DNS not working

[Cyril Brulebois]

Cyril Brulebois  (2017-01-19):
> Summing up things from IRC:
>  - in an uptodate sid chroot (both development version and minimal one
>with daily-build script): no DNS issues with the generated mini.iso
>(amd64, tested within stable's kvm on amd64). My image was also
>tested successfully by Steve, so not a setup issue.
> 
>  - I can reproduce the issue with dailies from 2017-01-18, and from
>2017-01-19 (I picked it in advance during its build on barriere).
> 
>  - I can reproduce the issue in the above mentioned sid chroot if
>I downgrade these packages to testing's version (-9 → -8):
>  sudo apt-get install libc6:amd64=2.24-8 libc6-dev:amd64=2.24-8 
> libc-dev-bin=2.24-8
> 
>  - The older set of libc* packages is installed in barriere's current
>amd64 sid chroot, too.
> 
>  - Steve could only produce broken images when building locally, until
>he upgraded his libc* packages as well.

And since Steve was wondering how we could release something for Stretch
RC 1 with that… I've just confirmed that using -8 .deb with a -8 .udeb
(reversioned as -9+hack so that its being dropped under localudebs makes
it take precedence over sid's .udeb) leads to an image that's working
fine. And AFAICT that's the combination we had at the time.

I suspect the implementation change through the following patch in -9:
glibc-2.24/debian/patches/any/cvs-resolv-internal-qtype.diff

plus 283e7a294275a7da53258600deaaafbbec6b96c1 in debian-installer.git is
what is triggering the issue? (Explaining why host's libc .deb have an
impact on the built images.)

It's been a while since I last looked at/understood mklibs stuff though,
feel free to fix my suspicions/conclusions.


KiBi.


signature.asc
Description: Digital signature

Bug#851814: apt-build: Broken postinst by less permissive sed

[Santiago Vila]

Package: apt-build
Version: 0.12.45
Severity: serious
Tags: patch

Dear QA Group:

Installing apt-build results in this error:

Setting up apt-build (0.12.45) ...
sed: character class syntax is [[:space:]], not [:space:]
dpkg: error processing package apt-build (--configure):
 subprocess installed post-installation script returned error exit
status 4
Processing triggers for man-db (2.7.6.1-2) ...
Errors were encountered while processing:
 apt-build

Discovered by Antonio Trujillo here:

https://lists.debian.org/msgid-search/dd7864af-d235-217c-74dc-bd1b5a086...@juntadeandalucia.es

I think the following trivial patch should fix it, but I'm not
confident enough to push it to git because version in Debian archives
does not exactly match HEAD in git.

Thanks.

--- a/debian/postinst
+++ b/debian/postinst
@@ -75,7 +75,7 @@ if [ "$1" = "configure" ] ; then
 if [ -e "$source" ] ; then
# comment in all sources lists if asked
if [ "$add_to_sourceslist" = "false" ] ; then
-sed -i -e "s|^[:space:]*$debline.*|#$debline|" "$source"
+sed -i -e "s|^[[:space:]]*$debline.*|#$debline|" "$source"
   
   # check if source entry is already enabled
   elif grep -Eq "^[[:space:]]*$debline" "$source" ; then
@@ -149,12 +149,12 @@ if [ "$1" = "configure" ] ; then
   test -z "make_options" || grep -Eq '^[[:space:]]*make_options =' $CONFFILE 
|| \
 echo "make_options =" >> $CONFFILE
   
-  sed -e "s|^[:space:]*build-dir =.*|build-dir = $build_dir|" \
-  -e "s|^[:space:]*repository-dir =.*|repository-dir = $repository_dir|" \
-  -e "s|^[:space:]*Olevel =.*|Olevel = $Olevel|" \
-  -e "s|^[:space:]*mtune =.*|mtune = $mtune|" \
-  -e "s|^[:space:]*options =.*|options = \" $options\"|" \
-  -e "s|^[:space:]*make_options =.*|make_options = \" $make_options\"|" \
+  sed -e "s|^[[:space:]]*build-dir =.*|build-dir = $build_dir|" \
+  -e "s|^[[:space:]]*repository-dir =.*|repository-dir = $repository_dir|" 
\
+  -e "s|^[[:space:]]*Olevel =.*|Olevel = $Olevel|" \
+  -e "s|^[[:space:]]*mtune =.*|mtune = $mtune|" \
+  -e "s|^[[:space:]]*options =.*|options = \" $options\"|" \
+  -e "s|^[[:space:]]*make_options =.*|make_options = \" $make_options\"|" \
   < $CONFFILE > $CONFFILE.tmp
   
   mv -f $CONFFILE.tmp $CONFFILE

Bug#851776: [www.debian.org] submit_vendor.pl fails when checking URLs with HTTPS (e.g. LetsEncrypt Certs)

[Paul Wise]

On Thu, Jan 19, 2017 at 1:05 AM, Laura Arjona Reina wrote:

> And forward to DSA for deployment, I guess, but how? Creating an RT
> ticket and pointing to this bug? or are the usertags enough?

DSA doesn't need to be involved, anyone in the debwww group should
just be able to update /srv/cgi.debian.org on www-master.d.o (aka
wolkenstein.d.o).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#851618: lirc: adequate reports multiple obsolete-conffiles for lirc Package: lirc

[Paul Wise]

dpkg doesn't handle removal of conffiles when they disappear from
packages, so the package postinst files need to handle removing
obsolete unmodified conffiles from user systems to avoid cruft
building up.

On Thu, Jan 19, 2017 at 12:49 AM, shirish शिरीष wrote:

> If there are any simple commands or something which I should have used
> to dig more please share those as well so I could use them the next
> time something similar comes around.

I use this in my template for conffile handling bugs:

pkg=lirc
adequate $pkg
dpkg-query -W -f='${Conffiles}\n' $pkg | grep obsolete

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#851813: lighttpd-mod-webdav: WebDAV crashes constantly when accessed from Windows client (unusable)

[Matthew Gabeler-Lee]

Package: lighttpd-mod-webdav
Version: 1.4.44-1
Severity: important

I'm trying to setup a webdav share for windows (10) clients to access.

One of the basic commands they send causes lighttpd to segfault with a
"double free or corruption" error in syslog.  Constantly.  It's barely
possible to get Windows to "mount" the webdav location, and totally
impossible to copy a file into it.

The only commands the Windows client gets to issue before it crashes are
PROPFIND and LOCK, so it's one of those two triggering the error.  Given the
propensity of the file copy to trigger the crash, I suspect it is the LOCK
call.

The stack trace logged along with the segfault is:

=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7fb1d6d57bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7fb1d6d5dfa6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7fb1d6d5e79e]
/usr/lib/lighttpd/mod_webdav.so(+0x257c)[0x7fb1d4bd957c]
/usr/sbin/lighttpd(plugins_call_connection_reset+0x56)[0x560858e464f6]
/usr/sbin/lighttpd(connection_reset+0x11)[0x560858e31e71]
/usr/sbin/lighttpd(connection_state_machine+0x6e6)[0x560858e32d46]
/usr/sbin/lighttpd(main+0x172d)[0x560858e2e1ed]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fb1d6d072b1]
/usr/sbin/lighttpd(_start+0x2a)[0x560858e2f13a]

This is 100% reproducible across multiple systems for me :(

Note: I had the testing release installed when reporting this bug, but I did
test it with the sid release and it fails in the same way.

Note 2: I also tried the same basic configuration using the stable (jessie)
version of lighttpd, and it does not crash, but it also doesn't work with
the Windows clients due to missing support for some arguments Windows sends
in the LOCK command.

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

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

Versions of packages lighttpd-mod-webdav depends on:
ii  libc6 2.24-8
ii  libsqlite3-0  3.15.2-2
ii  libuuid1  2.29-1
ii  libxml2   2.9.4+dfsg1-2.1
ii  lighttpd  1.4.43+git20161216-1

lighttpd-mod-webdav recommends no packages.

lighttpd-mod-webdav suggests no packages.

-- no debconf information

Bug#850033: libepoxy: diff for NMU version 1.3.1-1.1

[Jeremy Lal]

Control: tags 850033 + patch
Control: tags 850033 + pending

Dear maintainer,

I've prepared an NMU for libepoxy (versioned as 1.3.1-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru libepoxy-1.3.1/debian/changelog libepoxy-1.3.1/debian/changelog
--- libepoxy-1.3.1/debian/changelog 2015-08-29 16:10:12.0 +0200
+++ libepoxy-1.3.1/debian/changelog 2017-01-19 01:19:17.0 +0100
@@ -1,3 +1,10 @@
+libepoxy (1.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport three upstream commits. (Closes: #850033) 
+
+ -- Jérémy Lal   Thu, 19 Jan 2017 01:19:17 +0100
+
 libepoxy (1.3.1-1) unstable; urgency=low
 
   * Upgrade to upstream v1.3.1 release and make the -dev package multi-arch.
diff -Nru libepoxy-1.3.1/debian/patches/series 
libepoxy-1.3.1/debian/patches/series
--- libepoxy-1.3.1/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ libepoxy-1.3.1/debian/patches/series2017-01-19 00:40:06.0 
+0100
@@ -0,0 +1,3 @@
+upstream/b3b8bd9af7bf1fcfe544fd131f4d4f0d117ae7bc.patch
+upstream/8d58c890646fc1f43bcab702bb9ed6bae94daefe.patch
+upstream/b8d609e8f9fc1f9c4ff359adb2c1c44619a9e7cf.patch
diff -Nru 
libepoxy-1.3.1/debian/patches/upstream/8d58c890646fc1f43bcab702bb9ed6bae94daefe.patch
 
libepoxy-1.3.1/debian/patches/upstream/8d58c890646fc1f43bcab702bb9ed6bae94daefe.patch
--- 
libepoxy-1.3.1/debian/patches/upstream/8d58c890646fc1f43bcab702bb9ed6bae94daefe.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libepoxy-1.3.1/debian/patches/upstream/8d58c890646fc1f43bcab702bb9ed6bae94daefe.patch
   2017-01-19 00:41:22.0 +0100
@@ -0,0 +1,50 @@
+From: Yaron Cohen-Tal 
+Date: Mon, 21 Sep 2015 19:58:03 +0300
+Subject: [PATCH] Fix "epoxy_egl_get_current_gl_context_api" to use
+ "eglQueryContext" with "EGL_CONTEXT_CLIENT_TYPE" as "attribute".
+
+---
+ src/dispatch_common.c | 32 +++-
+ 1 file changed, 7 insertions(+), 25 deletions(-)
+
+--- a/src/dispatch_common.c
 b/src/dispatch_common.c
+@@ -569,31 +569,13 @@
+ static EGLenum
+ epoxy_egl_get_current_gl_context_api(void)
+ {
+-EGLenum save_api = eglQueryAPI();
+-EGLContext ctx;
+-
+-if (eglBindAPI(EGL_OPENGL_API)) {
+-ctx = eglGetCurrentContext();
+-if (ctx) {
+-eglBindAPI(save_api);
+-return EGL_OPENGL_API;
+-}
+-} else {
+-(void)eglGetError();
+-}
+-
+-if (eglBindAPI(EGL_OPENGL_ES_API)) {
+-ctx = eglGetCurrentContext();
+-eglBindAPI(save_api);
+-if (ctx) {
+-eglBindAPI(save_api);
+-return EGL_OPENGL_ES_API;
+-}
+-} else {
+-(void)eglGetError();
+-}
+-
+-return EGL_NONE;
++EGLDisplay eglDisplay = eglGetCurrentDisplay();
++EGLContext eglContext = eglGetCurrentContext();
++EGLint eglContextClientType = EGL_NONE;
++return  eglQueryContext(eglDisplay, eglContext, 
EGL_CONTEXT_CLIENT_TYPE,
++) == EGL_TRUE
++   ?(EGLenum)eglContextClientType
++   :EGL_NONE;
+ }
+ #endif /* PLATFORM_HAS_EGL */
+ 
diff -Nru 
libepoxy-1.3.1/debian/patches/upstream/b3b8bd9af7bf1fcfe544fd131f4d4f0d117ae7bc.patch
 
libepoxy-1.3.1/debian/patches/upstream/b3b8bd9af7bf1fcfe544fd131f4d4f0d117ae7bc.patch
--- 
libepoxy-1.3.1/debian/patches/upstream/b3b8bd9af7bf1fcfe544fd131f4d4f0d117ae7bc.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libepoxy-1.3.1/debian/patches/upstream/b3b8bd9af7bf1fcfe544fd131f4d4f0d117ae7bc.patch
   2017-01-19 00:41:15.0 +0100
@@ -0,0 +1,51 @@
+From: Yaron Cohen-Tal 
+Date: Tue, 29 Sep 2015 11:57:55 +0300
+Subject: [PATCH] Fix "epoxy_glx_version" to handle the case when GLX is not
+ active on the display.
+
+---
+ src/dispatch_glx.c | 29 +++--
+ 1 file changed, 15 insertions(+), 14 deletions(-)
+
+diff --git a/src/dispatch_glx.c b/src/dispatch_glx.c
+index f1ff447..36d513a 100644
+--- a/src/dispatch_glx.c
 b/src/dispatch_glx.c
+@@ -54,22 +54,23 @@ epoxy_glx_version(Display *dpy, int screen)
+ int client_major, client_minor;
+ int server, client;
+ const char *version_string;
+-int ret;
++int ret=0, sscanf_ret;
+ 
+-version_string = glXQueryServerString(dpy, screen, GLX_VERSION);
+-ret = sscanf(version_string, "%d.%d", _major, _minor);
+-assert(ret == 2);
+-server = server_major * 10 + server_minor;
++if ((version_string = glXQueryServerString(dpy, screen, GLX_VERSION)))
++{
++sscanf_ret = sscanf(version_string, "%d.%d", _major, 
_minor);
++assert(sscanf_ret == 2);
++server = server_major * 10 + server_minor;
++if ((version_string = glXGetClientString(dpy, GLX_VERSION)))
++{
++sscanf_ret = sscanf(version_string, "%d.%d", _major, 
_minor);
++assert(sscanf_ret == 2);
++ 

Bug#851790: installation-reports: DNS not working

[Cyril Brulebois]

Cyril Brulebois  (2017-01-19):
> You can try downgrading the kernel, but I'd usually look at glibc first
> for DNS related issues.

Summing up things from IRC:
 - in an uptodate sid chroot (both development version and minimal one
   with daily-build script): no DNS issues with the generated mini.iso
   (amd64, tested within stable's kvm on amd64). My image was also
   tested successfully by Steve, so not a setup issue.

 - I can reproduce the issue with dailies from 2017-01-18, and from
   2017-01-19 (I picked it in advance during its build on barriere).

 - I can reproduce the issue in the above mentioned sid chroot if
   I downgrade these packages to testing's version (-9 → -8):
 sudo apt-get install libc6:amd64=2.24-8 libc6-dev:amd64=2.24-8 
libc-dev-bin=2.24-8

 - The older set of libc* packages is installed in barriere's current
   amd64 sid chroot, too.

 - Steve could only produce broken images when building locally, until
   he upgraded his libc* packages as well.


→ Copying glibc@packages for the time being, even I suspect this will
  likely disappear entirely once -9 propagates…


KiBi.


signature.asc
Description: Digital signature

Bug#851136: dh-make-perl: docs of where available modules -> debs found

[Kevin Ryde]

gregor herrmann  writes:
>
> /var/lib/dpkg/available isn't updated for me either, unless I do some
> magic manually.

I did "dpkg --update-avail" and "dpkg --merge-avail" to bring in each
Packages file.

> That may or may not be the the case but dh-make-perl doesn't call the
> apt-file binary, it parses the Contents files (and caches them).

Ah, it must come the available file way etc instead.  The docs can
include what is demanded or what might work near enough ... :)


-- 
The International Journal of Haruspicy is the world's premier journal of
rigorous peer-reviewed evidence-based haruspicy.  Authors with work
achieving statistical significance p<0.05 are encouraged to submit.

Bug#851812: seed-webkit2 autoreconf FTBFS

[Adrian Bunk]

Source: seed-webkit2
Version: 4.0.0+20161014+6c77960+dfsg1-3
Severity: serious

https://buildd.debian.org/status/package.php?p=seed-webkit2=sid

...
set -e; LC_ALL=C.UTF-8 /usr/bin/licensecheck --check '.*' --recursive 
--copyright --deb-fmt --ignore 
'^(debian/(changelog|copyright(|_hints|_newhints)))$' --lines 0 * | 
/usr/lib/cdbs/licensecheck2dep5 > debian/copyright_newhints
/bin/sh: 1: /usr/bin/licensecheck: not found
0 combinations of copyright and licensing found.
diff: debian/copyright_hints: No such file or directory
No new copyright notices found - assuming no news is good news...
touch debian/stamp-copyright-check
touch debian/stamp-upstream-cruft
dh_autoreconf debian/rules -- autoreconf
make[1]: Entering directory 
'/«BUILDDIR»/seed-webkit2-4.0.0+20161014+6c77960+dfsg1'
CDBS WARNING:  copyright-check disabled - touch debian/copyright_hints to 
enable.
./autogen.sh
You need to install gnome-common from GNOME SVN and make
sure the gnome-autogen.sh script is in your $PATH.
debian/rules:15: recipe for target 'autoreconf' failed
make[1]: *** [autoreconf] Error 1

Bug#851697: Cannot push when archive access method is `aptget'

[Ian Jackson]

peter green writes ("Bug#851697: Cannot push when archive access method is 
`aptget'"):
> here is a debdiff adding the stub implementation

Thanks.  I will apply it.

I don't think there a better solution is easy.  To find out whether
anna archive like this had a particular .orig, it would be necessary
to find all the suites and download all of their Sources files.  I
think that would usually be prohibitively time- and
bandwidth-consuming.

It would be possible, I suppose, if you could guarantee that the
archive a particular `pool'-style layout, to simply probe for the
expected location of the .orig.  (That guarantee could be provided
in the form of a config option.)

I probably won't implement that soon I'm afraid.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#851811: docker-engine: Upgrading from 12.6-0 to 1.13.0-0~debian-stretch killed are running containers without any notice or confirmation.

[Witold Baryluk]

Package: docker-engine
Version: 1.13.0-0~debian-stretch
Severity: important

Dear Maintainer,

I just performed an dist-upgrade as I usually do from time to time, and
it upgraded docker.

Upgrading from 1.12.6-0~debian-stretch to 1.13.0-0~debian-stretch
And all my containers suddenly dissapread without any notice, warning,
confirmation, anything during upgrade.

Thanks.

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

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

Versions of packages docker-engine depends on:
ii  init-system-helpers  1.46
ii  iptables 1.6.0+snapshot20161117-4
ii  libapparmor1 2.10.95-8
ii  libc62.24-8
ii  libdevmapper1.02.1   2:1.02.137-1
ii  libltdl7 2.4.6-2
ii  libseccomp2  2.3.1-2.1
ii  libsystemd0  232-8

Versions of packages docker-engine recommends:
ii  aufs-tools   1:4.1+20161219-1
ii  ca-certificates  20161130
ii  cgroupfs-mount   1.3
ii  git  1:2.11.0-2
ii  xz-utils 5.2.2-1.2

docker-engine suggests no packages.

-- no debconf information

Bug#811377: Bug#851747: sysvinit-utils: unmaintained package should not be Essential

[Ian Jackson]

Petter Reinholdtsen writes ("Bug#851747: sysvinit-utils: unmaintained package 
should not be Essential"):
> [Ian Jackson]
> > I don't want to do an upload of this package just to change the
> > Uploaders - particularly at this stage of the release.
> 
> Why not?  I would guess particularly at this stage in the release, it is
> smart to trim the list of maintainers down to those that plan to spend
> time on the sysvinit package for the next stable release cycle.

FYI right now in sid, no people at all are named in debian/control -
just the pkg-sysvinit-devel list.

> > But, for the avoidance of any doubt, I hereby re-express my intent to
> > help adopt this package.  I would like the next upload to name me in
> > Uploaders.  I'm happy to share this role with the people who have
> > written to #811377.
> 
> Did you commit your name to git?  If not, why not?

I didn't think of it.  I'm not very used to team maintenance, so
please forgive me if I make obvious mistakes like this.

I have done this now, with a changelog entry that closes these two
bugs.  I think that is appropriate but I'm sure someone will complain
if not.

I see that we have offers of help from various people in #811377.

I have also added Benda Xu, based on
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811377#25
I see that Benda doesn't seem to be a DD.  Needless to say I am happy
to sponsor uploads and/or review and push git branches.

With sysvinit being maintained in collab-maint, I think Benda won't be
able to push to it directly.  Benda, I suggest that if you want to
contribute you make a git branch in a tree of your own on alioth, and
use git-request-pull.

Simon Richter's message was more ambiguous.  Simon, would you like to
be listed in Uploaders ?  If so please do that in the collab-maint
repo,   git.debian.org:/git/collab-maint/sysvinit.git

Benda, and Simon, are you subscribed to pkg-sysvinit-devel ?

We should have a conversation on the devel list about what changes we
want to see in stretch (and what bugs we want and/or need to fix).

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#851539: Stretch RC1 netinst installer prompts for additional CDs

[Josh Triplett]

On Wed, Jan 18, 2017 at 02:53:29PM +, Steve McIntyre wrote:
> On Tue, Jan 17, 2017 at 10:24:31AM +0100, Julien Cristau wrote:
> >On 01/16/2017 07:56 PM, Josh Triplett wrote:
> >> 
> >> How does it help for the firmware-included images?
> >> 
> >It makes it possible to use them to install from CD rather than from the
> >network.
> 
> Exactly.
> 
> When we first came up with the idea of the firmware-included images,
> an explicit use case was meant to be "boot off firmware netinst, add
> other discs as apt sources" to make things work well. I'd not
> understood why that wasn't working for quite a while, and then took a
> long time to get around to fixing this.

That seems entirely reasonable.  However, does the prompt make sense for
the non-firmware-included images?  Or could it go away for those, to
reduce the number of questions asked?

- Josh Triplett

Bug#851581: apt: Reading package lists...Bus error

[Andreas Beckmann]

Hi David,

thanks for your input.

On 2017-01-18 23:48, David Kalnischkies wrote:
> - "Non-existent address". Kinda possible, althrough the insistence on
>   "physical" vs "virtual" (which would be a Segfault) is telling.

> - "Unaligned access". Certainly possible, expect that I guess piuparts
>   runs on amd64/i386 which makes this impossible as this class does not

correct, it's an amd64 host with both amd64 and i386 chroots

> - "Paging errors". Quoting wikipedia: "[…] or because a just-created
>   memory-mapped file cannot be physically allocated, because the disk is
>   full." That sounds for me like the most likely scenario actually as
>   our binary caches are 'just-created memory-mapped files' which
>   depending on your sources can have a non-trivial amount of size so
>   perhaps that is really a run out of free space (mine are both >= 100
>   MB).

That one sounds most likely, with about a dozen of piuparts tests
running in parallel in a big tmpfs I sometimes run out of space
(something like testing texlive-full several times in parallel), and
this could be just a different way of saying "disk full".

If this happens more often, I'll add it to the list of "disk full"
strings being grepped for, that filter out bogus failures and trigger
retesting.


Andreas

Bug#851026: ffmpeg: FTBFS: ffconf.bVIjAhhQ.c:2: undefined reference to `dlopen'

[Bálint Réczey]

Hi,

2017-01-14 23:54 GMT+01:00 Adrian Bunk :
> Control: retitle -1 ffmpeg: ChromaprintContext FTBFS
> Control: forwarded -1 https://trac.ffmpeg.org/ticket/5997
> Control: tags -1 fixed-upstream
>
> On Sat, Jan 14, 2017 at 06:47:02AM +0100, Carl Eugen Hoyos wrote:
>> The relevant lines in the build log are afaict:
>>
>> src/libavformat/chromaprint.c: In function 'write_packet':
>> src/libavformat/chromaprint.c:113:1: error: control reaches end of non-void
>> function [-Werror=return-type]
>>  }
>>  ^
>>
>> The function looks like this:
>>
>> static int write_packet(AVFormatContext *s, AVPacket *pkt)
>> {
>> ChromaprintMuxContext *cpr = s->priv_data;
>> return chromaprint_feed(cpr->ctx, pkt->data, pkt->size / 2) ? 0 :
>> AVERROR(EINVAL);
>> }
>>
>> I guess this is a compiler bug.
>
> No, you should only look at the first compile error in that file:
>
> src/libavformat/chromaprint.c:42:24: error: field 'ctx' has incomplete type
>  ChromaprintContext ctx;
> ^~~
> This is the actual error.
>
> Whatever the compiler comes up with for cpr->ctx in the place you quoted
> might be garbage, but at that point it is already game over.
>
> Upstream fix:
>   
> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=581f93f37ef2e7a00662828ed0348d1edb9041fe
>
>> Carl Eugen

Is there a new FFmpeg upstream release on the horizon or I should just
update the package with a cherry-picked patch?

Cheers,
Balint

Bug#845606: The Bytecode Should Not Be Targeting Java 1.2

[Miguel Landaeta]

On Wed, Jan 18, 2017 at 11:43:04AM +0100, Emmanuel Bourg wrote:
> 
> I got another look and I think the root issue is the change I made in
> asm/5.1-1 when I replaced asm-all.jar by a symlink to asm-debug-all.jar.
> I assumed that asm-all was simply a version of the jar stripped from its
> debug symbols, and since our policy recommends to keep these symbols I
> decided to remove the jar and save a few kilobytes in the package.
> 

Hi Emmanuel,

Thanks for the clear explanation of the issue and the quick solution.

I'll keep an eye at the issue you reported in jitescript project.

Cheers,

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#851790: installation-reports: DNS not working

[Cyril Brulebois]

Steve McIntyre  (2017-01-18):
> For the sake of completeness, I can confirm that the same problem
> shows up when running on a different network too. I also see this
> using the oldest amd64 daily I can grab (from 2017-01-17) which has
> the 4.9 kernel too.
> 
> I'll see if I can debug this, but I'm not sure where to look straight
> away.

You can try downgrading the kernel, but I'd usually look at glibc first
for DNS related issues.


KiBi.


signature.asc
Description: Digital signature

Bug#851810: xcalib: "Error - unsupported ramp size 0" when trying to invert screen

[Chris Lamb]

Package: xcalib
Version: 0.8.dfsg1-2
Severity: normal

Hi,

During summer months I use xcalib to invert colours so I can work on
free software despite the sun reflecting on my laptop's display.

This was working as late as August in Europe but not only do I find
myself in thesouthern hemisphere at the moment, xcalib does not appear
to be working:

 $ xcalib -i
 Error - unsupported ramp size 0

 $ echo $?
 255


Regards,

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

Bug#694394: Bug #694394: Both lists have been available for a while.

[shirish शिरीष]

Control: reopen 694394

at bottom :-

On 19/01/2017, Adam D. Barratt  wrote:
> On Thu, 2017-01-19 at 03:59 +0530, shirish शिरीष wrote:
>> Hi all,
>>
>> Both the lists are functional for a while. See
>> https://lists.debconf.org/mailman/listinfo and specifically
>>
>> https://lists.debconf.org/mailman/listinfo and specifically
>> https://lists.debconf.org/mailman/listinfo/debconf-discuss and
>> https://lists.debconf.org/mailman/listinfo/debconf-team
>>
>> So this should be closed.
>
> Errr... the opening mail to this bug says "can you please create
> debconf-team and debconf-discuss lists on *lists.debian.org*" (my
> emphasis). Has that happened? I don't think anyone's disputing that the
> debconf.org lists exist...
>
> Regards,
>
> Adam
>
>

Oops...my bad. Somehow missed/didn't read that it should be UNDER
lists.debian.org .

Re-reading that bug again now it makes much more sense, sorry for
pre-emptively closing, re-opening it.

-- 
  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#851809: mono: please make the output of dh_makeclilibs reproducible

[Chris Lamb]

Source: mono
Version: 4.6.2.7+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that dh_makeclilibs generates "clilibs" files with a non-deterministic
order.

This affects packages such as gtk-sharp-beans. For example:

│ -gtk-sharp-beans 2.14.0.0__97a95fb57b03c03a libgtk-sharp-beans-cil
│  gio-sharp 2.14.0.0__35e10195dab3c99f libgtk-sharp-beans-cil
│ +gtk-sharp-beans 2.14.0.0__97a95fb57b03c03a libgtk-sharp-beans-cil

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/dh_makeclilibs b/debian/dh_makeclilibs
index 976fd75..17cfa88 100755
--- a/debian/dh_makeclilibs
+++ b/debian/dh_makeclilibs
@@ -297,6 +297,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 if (-e "$tmp/DEBIAN/clilibs") {
 doit("chmod", 644,   "$tmp/DEBIAN/clilibs");
 doit("chown", "0:0", "$tmp/DEBIAN/clilibs");
+complex_doit("LC_ALL=C sort $tmp/DEBIAN/clilibs -o 
$tmp/DEBIAN/clilibs");
 }
 }
 

Bug#851808: lists.debian.org: Would it be possible to have alias URL's for debconf-team and debconf-discuss

[Don Armstrong]

On Thu, 19 Jan 2017, shirish शिरीष wrote:
> Package: lists.debian.org
> Severity: wishlist
> 
> Dear Maintainer,
> Currently both debconf-discuss and debconf-team page URL's are
> https://lists.debconf.org/mailman/listinfo/debconf-team and
> https://lists.debconf.org/mailman/listinfo/debconf-discuss
> 
> Can they be minimized or aliased to
> https://lists.debconf.org/debconf-team and
> https://lists.debconf.org/debconf-discuss.
> 
> This would be in-line with the lists being hosted at lists.debian.org.
> Would it be possible, and if possible what do people think of doing it

listmas...@lists.debian.org don't have anything to do with the
lists.debconf.org infrastructure.


-- 
Don Armstrong  https://www.donarmstrong.com

[A] theory is falsifiable [(and therefore scientific) only] if the
class of its potential falsifiers is not empty.
 -- Sir Karl Popper _The Logic of Scientific Discovery_ §21

Bug#851003: Can't reproduce FTBFS

[Lucas Nussbaum]

Hi,

On 18/01/17 at 00:32 +0200, Adrian Bunk wrote:
> Adding Lucas, the BTS does not Cc the submitter.
> 
> On Tue, Jan 17, 2017 at 02:42:36PM +0100, Ondřej Kobližek wrote:
> > Hi,
> > I can't reproduce FTBFS.
> > My building environment builds package fine.
> > 
> > Debian reproducible-builds are OK for amd64:
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django-pyscss.html
> > 
> > Lowered severity to normal level.

Maybe pypi was down at the time of the test. Feel free to close if you
prefer.

Lucas

Bug#850998: [Pkg-leofs-devel] Bug#850998: erlang-ranch: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

[Bálint Réczey]

Hi Nobuhiro,

I have uploaded the fix but the packaging repo does not contain your
latest upload.
In case you have it offline please upload it or we can import the
history from the .dsc

Cheers,
Balint

2017-01-11 20:07 GMT+01:00 Lucas Nussbaum :
> Source: erlang-ranch
> Version: 1.2.1-2
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20170111 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
>> make[2]: Entering directory '/<>'
>>  GENdistclean-asciidoc
>> a2x -v -f pdf doc/src/guide/book.asciidoc && mv doc/src/guide/book.pdf 
>> doc/guide.pdf
>> a2x: ERROR: missing configuration file: 
>> /etc/asciidoc/dblatex/asciidoc-dblatex.xsl
>> a2x: args: ['--dblatex-opts', '-P latex.output.revhistory=0 -P 
>> doc.publisher.show=0 -P index.numbered=0', '-d', 'book', '--attribute', 
>> 'tabsize=4', '-v', '-f', 'pdf', 'doc/src/guide/book.asciidoc']
>> a2x: resource files: []
>> a2x: resource directories: ['/etc/asciidoc/images', 
>> '/etc/asciidoc/stylesheets']
>> a2x: executing: "/usr/bin/asciidoc" --backend docbook -a "a2x-format=pdf"  
>> --doctype book --attribute "tabsize=4" --verbose  --out-file 
>> "/<>/doc/src/guide/book.xml" 
>> "/<>/doc/src/guide/book.asciidoc"
>>
>> asciidoc: reading: /etc/asciidoc/asciidoc.conf
>> asciidoc: reading: /<>/doc/src/guide/book.asciidoc
>> asciidoc: reading: /etc/asciidoc/docbook45.conf
>> asciidoc: reading: /etc/asciidoc/filters/source/source-highlight-filter.conf
>> asciidoc: reading: /etc/asciidoc/filters/graphviz/graphviz-filter.conf
>> asciidoc: reading: /etc/asciidoc/filters/music/music-filter.conf
>> asciidoc: reading: /etc/asciidoc/filters/latex/latex-filter.conf
>> asciidoc: reading: /etc/asciidoc/filters/code/code-filter.conf
>> asciidoc: reading: /etc/asciidoc/lang-en.conf
>> asciidoc: writing: /<>/doc/src/guide/book.xml
>> asciidoc: include: /<>/doc/src/guide/introduction.asciidoc
>> asciidoc: book.asciidoc: line 6: reading: 
>> /<>/doc/src/guide/introduction.asciidoc
>> asciidoc: include: /<>/doc/src/guide/listeners.asciidoc
>> asciidoc: book.asciidoc: line 8: reading: 
>> /<>/doc/src/guide/listeners.asciidoc
>> asciidoc: include: /<>/doc/src/guide/transports.asciidoc
>> asciidoc: book.asciidoc: line 10: reading: 
>> /<>/doc/src/guide/transports.asciidoc
>> asciidoc: include: /<>/doc/src/guide/protocols.asciidoc
>> asciidoc: book.asciidoc: line 12: reading: 
>> /<>/doc/src/guide/protocols.asciidoc
>> asciidoc: include: /<>/doc/src/guide/embedded.asciidoc
>> asciidoc: book.asciidoc: line 14: reading: 
>> /<>/doc/src/guide/embedded.asciidoc
>> asciidoc: include: /<>/doc/src/guide/parsers.asciidoc
>> asciidoc: book.asciidoc: line 16: reading: 
>> /<>/doc/src/guide/parsers.asciidoc
>> asciidoc: include: /<>/doc/src/guide/ssl_auth.asciidoc
>> asciidoc: book.asciidoc: line 18: reading: 
>> /<>/doc/src/guide/ssl_auth.asciidoc
>> asciidoc: include: /<>/doc/src/guide/internals.asciidoc
>> asciidoc: book.asciidoc: line 20: reading: 
>> /<>/doc/src/guide/internals.asciidoc
>>
>> a2x: executing: "xmllint" --nonet --noout --valid 
>> "/<>/doc/src/guide/book.xml"
>>
>>
>> erlang.mk:5062: recipe for target 'asciidoc-guide' failed
>> make[2]: *** [asciidoc-guide] Error 1
>
> The full build log is available from:
>http://aws-logs.debian.net/2017/01/11/erlang-ranch_1.2.1-2_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
>
> ___
> Pkg-leofs-devel mailing list
> pkg-leofs-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-leofs-devel

Bug#782390: udev: time between USB-stick connection and device notification takes up to a minute

[Bernhard Übelacker]

Hello Michael,
I am sorry, but my old address got shut down.


On Wed, 21 Dec 2016 19:30:10 +0100 Michael Biebl  wrote:
> just wanted to ask, if you still run into this issue with a newer kernel
> (from testing). If so, I think it would probably best to re-assign this.
> 
> Regards,
> Michael

Unfortunately this hardware was not my own.
Probably on upgrading to Stretch on his system ...

But I am fine with closing the bug too, because this stick is of rather
small capacity and no other user noticed the same behaviour.

Kind regards,
Bernhard

Bug#851581: apt: Reading package lists...Bus error

[David Kalnischkies]

Control: tags -1 + unreproducible moreinfo

Hi

On Mon, Jan 16, 2017 at 04:52:09PM +0100, Andreas Beckmann wrote:
>   Installing mysql-server ...
>   Reading package lists...Bus error

The actual command run can be pretty much ignored as we fail generating
the binary caches in this step (which is pretty much the first one) and
is not specific to a command.

Reading up on "Bus error" (on wikipedia [1]) I see 3 possible reasons:

- "Non-existent address". Kinda possible, althrough the insistence on
  "physical" vs "virtual" (which would be a Segfault) is telling.
  Cachebuilding is complicated (as its supposed to be done quick and at
  the same time general enough so we can work with it later) and I can't
  rule out a bug there. We sometimes even fix them if found – althrough
  all I have seen and fixed in the last 7 years so far were segfaults.

- "Unaligned access". Certainly possible, expect that I guess piuparts
  runs on amd64/i386 which makes this impossible as this class does not
  exist on them then. Also, someone would have likely noticed as our
  segfault causing issues tend to be addresses not rewritten on
  remapping/moving – that doesn't make them magically unaligned – so the
  unaligned access would happen in "normal" runs as well.

- "Paging errors". Quoting wikipedia: "[…] or because a just-created
  memory-mapped file cannot be physically allocated, because the disk is
  full." That sounds for me like the most likely scenario actually as
  our binary caches are 'just-created memory-mapped files' which
  depending on your sources can have a non-trivial amount of size so
  perhaps that is really a run out of free space (mine are both >= 100
  MB).

So, with that in mind and given that even the reporter can't reproduce
it the bugreport as such seems rather unactionable - tagging as such.


Best regards

David Kalnischkies

[1] https://en.wikipedia.org/wiki/Bus_error


signature.asc
Description: PGP signature

Bug#694394: Bug #694394: Both lists have been available for a while.

[Adam D. Barratt]

On Thu, 2017-01-19 at 03:59 +0530, shirish शिरीष wrote:
> Hi all,
> 
> Both the lists are functional for a while. See
> https://lists.debconf.org/mailman/listinfo and specifically
> 
> https://lists.debconf.org/mailman/listinfo and specifically
> https://lists.debconf.org/mailman/listinfo/debconf-discuss and
> https://lists.debconf.org/mailman/listinfo/debconf-team
> 
> So this should be closed.

Errr... the opening mail to this bug says "can you please create
debconf-team and debconf-discuss lists on *lists.debian.org*" (my
emphasis). Has that happened? I don't think anyone's disputing that the
debconf.org lists exist...

Regards,

Adam

Bug#851753: gdm always starts as x-session

[Heiko Lechner]

Here are the logs when autologin is disabled

Jan 18 22:49:11 debian mtp-probe: checking bus 1, device 3: "/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1"
Jan 18 22:49:11 debian mtp-probe: bus: 1, device: 3 was not an MTP device
Jan 18 22:49:11 debian mtp-probe: checking bus 2, device 3: "/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.2"
Jan 18 22:49:11 debian mtp-probe: bus: 2, device: 3 was not an MTP device
Jan 18 22:49:30 debian gdm3: Enabling debugging
Jan 18 22:49:30 debian gdm3: Changing user:group to Debian-gdm:Debian-gdm
Jan 18 22:49:30 debian gdm3: Successfully connected to D-Bus
Jan 18 22:49:30 debian gdm3: GdmManager: GDM starting to manage displays
Jan 18 22:49:30 debian gdm3: Could not ping plymouth: Kindprozess »/bin/plymouth« konnte nicht ausgeführt werden (Datei oder Verzeichnis nicht gefunden)
Jan 18 22:49:30 debian gdm3: GdmLocalDisplayFactory: Adding display on seat seat0
Jan 18 22:49:30 debian gdm3: GdmDisplay: id: (null)
Jan 18 22:49:30 debian gdm3: GdmDisplay: seat id: (null)
Jan 18 22:49:30 debian gdm3: GdmDisplay: session class: greeter
Jan 18 22:49:30 debian gdm3: GdmDisplay: initial: no
Jan 18 22:49:30 debian gdm3: GdmDisplay: allow timed login: yes
Jan 18 22:49:30 debian gdm3: GdmDisplay: local: yes
Jan 18 22:49:30 debian gdm3: GdmDisplay: session type: wayland
Jan 18 22:49:30 debian gdm3: GdmDisplay: seat id: seat0
Jan 18 22:49:30 debian gdm3: GdmDisplay: initial: yes
Jan 18 22:49:30 debian gdm3: GdmDisplayStore: Adding display /org/gnome/DisplayManager/Displays/30274336 to store
Jan 18 22:49:30 debian gdm3: GdmDisplay: Managing display: /org/gnome/DisplayManager/Displays/30274336
Jan 18 22:49:30 debian gdm3: GdmDisplay: Preparing display: /org/gnome/DisplayManager/Displays/30274336
Jan 18 22:49:30 debian gdm3: doing initial setup? no
Jan 18 22:49:30 debian gdm3: GdmDisplay: prepare display
Jan 18 22:49:30 debian gdm3: GdmDisplay: Got automatic login details for display: 0
Jan 18 22:49:30 debian gdm3: GdmSession: Creating D-Bus server for worker for session
Jan 18 22:49:30 debian gdm3: GdmSession: D-Bus server for workers listening on unix:abstract=/tmp/dbus-eG0rcwAQ
Jan 18 22:49:30 debian gdm3: GdmSession: Creating D-Bus server for greeters and such
Jan 18 22:49:30 debian gdm3: GdmSession: D-Bus server for greeters listening on unix:abstract=/tmp/dbus-BoXXwNhE
Jan 18 22:49:30 debian gdm3: GdmSession: Setting display device: (null)
Jan 18 22:49:30 debian gdm3: GdmDisplay: Running greeter
Jan 18 22:49:30 debian gdm3: GdmDisplay: Creating greeter for (null) (null)
Jan 18 22:49:30 debian gdm3: GdmLaunchEnvironment: Starting...
Jan 18 22:49:30 debian gdm3: GdmLaunchEnvironment: Setting up run time dir /var/run/gdm3/greeter
Jan 18 22:49:30 debian gdm3: GdmSession: Creating D-Bus server for worker for session
Jan 18 22:49:30 debian gdm3: GdmSession: D-Bus server for workers listening on unix:abstract=/tmp/dbus-H8U4nkcg
Jan 18 22:49:30 debian gdm3: GdmSession: Creating D-Bus server for greeters and such
Jan 18 22:49:30 debian gdm3: GdmSession: D-Bus server for greeters listening on unix:abstract=/tmp/dbus-IOa0s4OB
Jan 18 22:49:30 debian gdm3: GdmSession: Setting display device: (null)
Jan 18 22:49:30 debian gdm3: GdmSession: starting conversation gdm-launch-environment
Jan 18 22:49:30 debian gdm3: GdmSessionWorkerJob: Starting worker...
Jan 18 22:49:30 debian gdm3: GdmSessionWorkerJob: Running session_worker_job process: gdm-session-worker [pam/gdm-launch-environment] /usr/lib/gdm3/gdm-session-worker
Jan 18 22:49:30 debian gdm3: GdmSessionWorkerJob: : SessionWorkerJob on pid 756
Jan 18 22:49:30 debian gdm3: GdmSession: setting session to type 'wayland'
Jan 18 22:49:30 debian gdm3: GdmLocalDisplayFactory: display status changed: 1
Jan 18 22:49:30 debian gdm-launch-environment]: Enabling debugging
Jan 18 22:49:30 debian gdm-launch-environment]: GdmSessionWorker: connecting to address: unix:abstract=/tmp/dbus-H8U4nkcg
Jan 18 22:49:30 debian gdm3: GdmDBusServer: new connection 0x1cdf650
Jan 18 22:49:30 debian gdm3: GdmSession: Handling new connection from worker
Jan 18 22:49:30 debian gdm3: GdmSession: Authenticating new connection
Jan 18 22:49:30 debian gdm-launch-environment]: AccountsService: ActUserManager: calling 'ListCachedUsers'
Jan 18 22:49:30 debian gdm3: GdmSession: worker connection is 0x1cdf650
Jan 18 22:49:30 debian gdm3: GdmSession: Emitting conversation-started signal
Jan 18 22:49:30 debian gdm3: GdmSession: Beginning setup for session for program using PAM service gdm-launch-environment
Jan 18 22:49:30 debian gdm3: GdmSession: Conversation started
Jan 18 22:49:30 debian gdm-launch-environment]: AccountsService: Failed to identify the current session: Kein passendes Gerät bzw. keine passende Adresse gefunden
Jan 18 22:49:30 debian gdm-launch-environment]: AccountsService: ActUserManager: seat unloaded, so trying to set loaded property
Jan 18 22:49:30 debian gdm-launch-environment]: AccountsService: ActUserManager: Listing cached users, so not setting loaded 

Bug#851788: closed by Mike Hommey <m...@glandium.org> (Re: Bug#851788: nspr: Enable Thumb2 for armel/armhf)

[Jon Grimm]

Thank you for the info Mike!

On Wed, Jan 18, 2017 at 4:42 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the src:nspr package:
>
> #851788: nspr: Enable Thumb2 for armel/armhf
>
> It has been closed by Mike Hommey .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Mike Hommey <
> m...@glandium.org> by
> replying to this email.
>
>
> --
> 851788: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851788
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Mike Hommey 
> To: Jon Grimm , 851788-d...@bugs.debian.org
> Cc:
> Date: Thu, 19 Jan 2017 07:28:30 +0900
> Subject: Re: Bug#851788: nspr: Enable Thumb2 for armel/armhf
> On Wed, Jan 18, 2017 at 12:38:54PM -0600, Jon Grimm wrote:
> > Source: nspr
> > Severity: wishlist
> > Tags: patch
> >
> > Dear Maintainer,
> >
> > Hi there,
> >
> > Forwarding along an Ubuntu patch in hopes of dropping some more delta.
> >
> > >From what I've quickly googled armhf is Thumb2 for you as well.  I'm
> > less certain about armel for debian, so maybe that's not needed for you.
> > FWIW, Ubuntu has dropped armel as an architecture, so we could drop
> > that out of the patch (but its harmless if you do keep it).
>
> Armel is set to run on armv5, which doesn't have thumb2. Armhf defaults
> to thumb2.
>
> So all in all this patch is not necessary.
>
> Mike
>
> -- Forwarded message --
> From: Jon Grimm 
> To: Debian Bug Tracking System 
> Cc:
> Date: Wed, 18 Jan 2017 12:38:54 -0600
> Subject: nspr: Enable Thumb2 for armel/armhf
> Source: nspr
> Severity: wishlist
> Tags: patch
>
> Dear Maintainer,
>
> Hi there,
>
> Forwarding along an Ubuntu patch in hopes of dropping some more delta.
>
> >From what I've quickly googled armhf is Thumb2 for you as well.  I'm
> less certain about armel for debian, so maybe that's not needed for you.
> FWIW, Ubuntu has dropped armel as an architecture, so we could drop
> that out of the patch (but its harmless if you do keep it).
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers yakkety-updates
>   APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500,
> 'yakkety'), (400, 'yakkety-proposed')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.8.0-34-generic (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)
>
>


-- 
Jon Grimm
Engineering Manager, Ubuntu Server
Canonical Ltd

Bug#851808: lists.debian.org: Would it be possible to have alias URL's for debconf-team and debconf-discuss

[shirish शिरीष]

Package: lists.debian.org
Severity: wishlist

Dear Maintainer,
Currently both debconf-discuss and debconf-team page URL's are
https://lists.debconf.org/mailman/listinfo/debconf-team and
https://lists.debconf.org/mailman/listinfo/debconf-discuss

Can they be minimized or aliased to
https://lists.debconf.org/debconf-team and
https://lists.debconf.org/debconf-discuss.

This would be in-line with the lists being hosted at lists.debian.org.
Would it be possible, and if possible what do people think of doing it
?

-- 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.8.0-2-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)

-- 
  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#849836: zekr: Missing dependency on libwebkitgtk-1.0-0

[Christoph Biedl]

Control: tags 849836 confirmed patch pending

Awtul wrote...

> Installing "libwebkitgtk-1.0-0" solves the problem. I thought it may
> be a dependency missing issue.

That's indeed a no-brainer. I've prepared an NMU as below and will
upload it to DELAYED/2 tomorrow.

Regards,

Christoph

diff -Nru zekr-1.1.0+repack/debian/changelog zekr-1.1.0+repack/debian/changelog
--- zekr-1.1.0+repack/debian/changelog  2015-07-30 18:07:11.0 +0200
+++ zekr-1.1.0+repack/debian/changelog  2017-01-18 23:13:43.0 +0100
@@ -1,3 +1,10 @@
+zekr (1.1.0+repack-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Add install dependency on xserver-xorg-input-all. Closes: #849836
+
+ -- Christoph Biedl   Wed, 18 Jan 2017 
23:13:43 +0100
+
 zekr (1.1.0+repack-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru zekr-1.1.0+repack/debian/control zekr-1.1.0+repack/debian/control
--- zekr-1.1.0+repack/debian/control2015-07-30 18:07:11.0 +0200
+++ zekr-1.1.0+repack/debian/control2017-01-18 23:13:13.0 +0100
@@ -41,6 +41,7 @@
  libswt-cairo-gtk-3-jni,
  libswt-gnome-gtk-3-jni,
  libswt-webkit-gtk-3-jni | libswt-mozilla-gtk-3-jni,
+ libwebkitgtk-1.0-0,
  zenity,
  libjs-jquery,
  ttf-sil-scheherazade | ttf-kacst (>= 1.6.2+mry-1) | ttf-farsiweb


signature.asc
Description: Digital signature

Bug#851717: packaging-tutorial: [INTL:pt] Updated Portuguese translation of documentation.

[Lucas Nussbaum]

On 17/01/17 at 22:46 +, Américo Monteiro wrote:
> Package: packaging-tutorial
> Version: 0.19
> Tags: l10n, patch
> Severity: wishlist
> 
> Updated Portuguese translation for packaging-tutorial's documentation.
> Translator: Américo Monteiro 
> Feel free to use it.
> 
> For translation updates please contact 'Last Translator'

Thanks!

L.

Bug#850396: xymon-client: ifstat graph appears to not recognize new net-tools output

[Axel Beckert]

Control: notfound -1 4.3.27-3+b1
Control: notfound -1 4.3.27-3
Control: found -1 4.3.17-6
Control: fixed -1 4.3.22~beta-1
Control: close -1

Hi David,

david wrote:
> I suppose your findings are both good and bad.

Definitely

> Good that things work for you, bad they aren't for me.

Nope. That's only my test server. I also have Xymon servers running on
Debian Stable.

> > Which version of Xymon do you have running on the server side?
> >
> > Is the server side also running Xymon 4.3.27? Or is it running an
> > earlier version than the client, e.g. 4.3.17 from Debian 8 Jessie?
> 
> I suspect this is where the issue lies as I am running Debian 8 with
> only the kernel upgraded via backports to 4.7 at this time. The
> version of Xymon is *4.3.17-6+deb8u1* which is listed as most
> current without using backports.

That's correct. I hence close this bug report as fixed with
xymon 4.3.22~beta-1.

> I'm somewhat loathe to have a mixed system for my daily workhorse,

I prefer Debian stable for servers, too.

> so maybe I'll just live with things as they are now, and just have
> to keep the interface rename using udev .link files.
> 
> Other thoughts are appreciated, but I think the problem problem lies
> with the age of the server side application as you seem to indicate.

Well, I actually plan to do an official backport of Xymon after the
freeze. Did that in the past locally, but since others (not only you)
need that, too, I can also put in some more effort and do that
officially.

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#851805: nspr: testcase 'errcodes' fails with new-dtags: libnspr4.so => not found

[Jon Grimm]

On Wed, Jan 18, 2017 at 4:08 PM, Jon Grimm  wrote:

>
>
>
> 3 quick and dirty ways to address this:
> 1) LD_PRELOAD
>

Bah!! Meant LD_LIBRARY_PATH



> 2) --disable-new-dtags (old rpath behavior)
> 3) --no-as-needed  (force the lookup)
>
> ,or of course other ideas by folks more knowledgeable.
>


-- 
Jon Grimm
Engineering Manager, Ubuntu Server
Canonical Ltd

Bug#851807: amarok: Librivox service query returns nothing (patched upstream)

[Hormet Yiltiz]

Package: amarok
Version: 2.8.0-8
Severity: normal
Tags: newcomer patch

Dear Maintainer,

The currently packaged amarok contains *very old* amarok scripting
engine along with old versions of scripts. This also effects downstream
packages in other distributions, including Ubuntu (and possibly others).

Librivox.org updated their API several years ago, and the original
maintainer of the librivox script for amarok updated the script at 2014,
which went into upstream master breanch of amarok. Amarok also updated
their scripting engine to version 2.0 since amarok version 2.8. However,
Debian still ships with old script engine and librivox script that is
about 3 years old. The upstream librivox script was updated three years
ago (2014) to version 2.0 (X-KDE-PluginInfo-Version=2.0) [1], which
happened well before upstream Amarok version v2.8.0 tag, and that
librivox script still remains in the Amarok master branch as of now [2].

I compiled the amarok upsteam master branch on Debian testing, and the
librivox service works fine. I do have some more ideas to add some
features to it (currently the search API for librivox.org is
cumbersome, and am discussing with their developers). But before doing
those, we should at least include the already well tested working
script (and the engine).

I assume there was some bug that was holding the update for the
scripting engine, which then holded the update to the librivox script.
If so, could one of the maintainers please point out such bug report? If
not, a simple explanation for why the new engine and scripts haven't
been packaged would be nice. But sure, we are all volunteering our life
and love, and I am making, in no way, any accusations. 

I can volunteer joining the maintainer team if necessary.

For more information, please refer to the forum [1].


[1]: https://forum.kde.org/viewtopic.php?f=115=138283
[2]: 
https://cgit.kde.org/amarok.git/commit/?id=658cddec28b26120bddd390273245f7686b27cf3
[3]: 
https://cgit.kde.org/amarok.git/commit/?id=1ccf0a34d2411a951d9d1bed1afc3b3f01d35457

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

   * What led up to the situation?
   Using old version of the script while the corresponding service API
   has been updated.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Start Amarok. Go into Internet / Libvivox Service. Search "Doyle".

   * What was the outcome of this action?
 Find nothing on one of Conan Doyle's great works.

   * What outcome did you expect instead?
 Find "A Study of Scarlett", among many others as the output of the
 query. Using an updated version of the script as well as the
 scripting engine fixes the problem. Compiling the source from
 upsteam master breanch confirms this.

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


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

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

Versions of packages amarok depends on:
ii  amarok-common 2.8.0-8
ii  amarok-utils  2.8.0-8
ii  kde-runtime   4:16.08.2-1
ii  libavcodec57  7:3.2.2-1
ii  libavformat57 7:3.2.2-1
ii  libavutil55   7:3.2.2-1
ii  libc6 2.24-5
ii  libcurl3-gnutls   7.50.1-1
ii  libgcrypt20   1.7.3-2
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libgl1-mesa-glx [libgl1]  13.0.2-1
ii  libglib2.0-0  2.50.1-1
ii  libgpod4-nogtk0.8.3-8
ii  libkcmutils4  4:4.14.25-1
ii  libkdecore5   4:4.14.25-1
ii  libkdeui5 4:4.14.25-1
ii  libkdewebkit5 4:4.14.25-1
ii  libkdnssd44:4.14.25-1
ii  libkfile4 4:4.14.25-1
ii  libkio5   4:4.14.25-1
ii  libknewstuff3-4   4:4.14.25-1
ii  liblastfm11.0.9-1
ii  libloudmouth1-0   1.5.3-2
ii  libmariadbclient1810.0.28-2
ii  libmariadbd18 10.1.20-3
ii  libmtp9   1.1.12-1
ii  libmygpo-qt1  1.0.9-2
ii  libofa0   0.9.3-12
ii  libphonon44:4.9.0-4
ii  libplasma34:4.14.25-1
ii  libqjson0 0.8.1-3
ii  libqt4-dbus   4:4.8.7+dfsg-9
ii  libqt4-network4:4.8.7+dfsg-9
ii  libqt4-opengl 4:4.8.7+dfsg-9
ii  libqt4-script 4:4.8.7+dfsg-9
ii  libqt4-sql4:4.8.7+dfsg-9
ii  libqt4-svg4:4.8.7+dfsg-9
ii  libqt4-xml4:4.8.7+dfsg-9
ii  libqtcore44:4.8.7+dfsg-9
ii  libqtgui4 4:4.8.7+dfsg-9
ii  libqtscript4-core 0.2.0-1
ii  libqtscript4-gui  0.2.0-1
ii  

Bug#851806: ITP: libmseed2 -- seed (Standard for the Exchange of Earthquake Data) data records manipulation library

[Pierre Duperray]

Package: wnpp
Severity: wishlist
Owner: Pierre Duperray 

* Package name: libmseed2
  Version : 2.18
  Upstream Author : Chad Trabant 
* URL : http://ds.iris.edu/ds/nodes/dmc/software/downloads/libmseed/
* License : LGPL3
  Programming Lang: C
  Description : seed data records manipulation library

Provides a framework for manipulation of SEED (Standard for the Exchange
 of Earthquake Data) data records.

I think this package is relevant because it is a reference implementation of
the SEED format manipulation. It will be a dependency on other packages 
allowing,
for instance, realtime exchange of seismic data around the world.
I use these tools on a daily basis, no other package provide this functionality
(as far as I know).
I plan to maintain this package and create other sismological related package,
as a maintainer beginner, I definitively need a sponsor.
My work on this package basically consisted in learning packaging, autotoolizing
the upstream source distribution. I plan to submit autotoolizing patch and man 
page
typos patch upstream. I will also ask the upstream author if he his interested
in co-maintaining this package.

Bug#851166: nmu: forge_0.9.2-2 [RC]

[Ghislain Vaillant]

Yes, because glm is fixed now.

Le 18 janv. 2017 9:54 PM, "Emilio Pozuelo Monfort"  a
écrit :

On 14/01/17 20:32, Ghislain Vaillant wrote:
> I forgot to mention that this NMU would fix the current RC affecting
> forge. The FTBFS was due to a bug in the CMake detection of the glm
> library, which I have fixed since.

I'm not sure I understand. If there is a FTBFS, wouldn't the binNMU fail to
build? If not, why not?

Do you actually want us to retry the failed builds in [1] ?

[1] https://buildd.debian.org/status/package.php?p=forge

Cheers,
Emilio

Bug#851794: regression: fails doing ikiwiki --setup existing.setup --dumpsetup new.setup

[Simon McVittie]

On Wed, 18 Jan 2017 at 15:09:19 +0100, Jonas Smedegaard wrote:
> Ikiwiki supports setting (some) options from commandline, loading an
> existing configfile, and dumping settings as a configfile.
> 
> In the past (not certain but I believe worked fine 6 months ago).
> ikiwiki support all three in concert, which I rely on to bootstrap a new
> site from scratch.
> 
> Essentially, this used to work:
> 
>   ikiwiki --setup existing.setup --dumpsetup new.setup

Works for me...

$ cp ~/src/ikiwiki/docwiki.setup ~/tmp
$ ikiwiki --setup docwiki.setup --set wikiname=hello --dumpsetup other.setup
shortcut plugin will not work without shortcuts.mdwn
shortcut plugin will not work without shortcuts.mdwn
shortcut plugin will not work without shortcuts.mdwn
$ file other.setup
other.setup: Perl script text executable

A similar command works for ikiwiki.info's YAML-formatted setup file (which
you can get from the 'setup' branch of ikiwiki's git repository), producing
YAML output.

Perhaps there is something specific to the setup file you are working
with that doesn't work, or some incompatible older version of ikiwiki
in /usr/local (or similar) on the system where it doesn't work?

> Now that command fails.

Fails in what way?

S

Bug#816724: php-imagick: update d/tests/control

[Jeremy Bicha]

Here's an updated version of the patch.

Thanks,
Jeremy Bicha
From 9f1ac3cb2f25bcd9ac6409088e1135bb30622efa Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Wed, 18 Jan 2017 17:09:14 -0500
Subject: [PATCH] Update debian/tests/control (from Ubuntu)

Closes: #816724
---
 debian/tests/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index 61ae920..e3316a0 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,2 @@
-Test-Command: cd imagick-*/tests && MAGICK_THREAD_LIMIT=1 phpunit --verbose .
-Depends: php-cli, php-imagick, gsfonts, libmagickcore-6.q16-2-extra, phpunit
+Test-Command: cd imagick-*/tests && phpunit --verbose .
+Depends: php-cli, php-imagick, gsfonts, imagemagick-6.q16, phpunit
-- 
2.10.2

Bug#851195: [debian-mysql] Bug#851195: Bug#851195: mariadb-server-10.1: Time Zone system tables are empty

[Otto Kekäläinen]

Hello!

Your patch was committed in
https://anonscm.debian.org/gitweb/?p=pkg-mysql/mariadb-10.1.git;a=commit;h=c840b371166afd05b96a94e2056bf8c65a5a8589

In addition to the official git.debian.org mariadb-10.1 repository
there is also a Github mirror if you are able to produce a patch and
want to open a pull request: https://github.com/ottok/mariadb-10.1

As it makes the package uninstallable, I am considering reverting the
change unless somebody quickly finds out a way how to implement this
properly. I tried prepending the command with "USE mysql;" and other
tricks, but I didn't figure out how to get it succeeding.

Bug#851803: ntp: FTBFS (mv: cannot stat 'debian/tmp/usr/bin/ntpdate': No such file or directory)

[Santiago Vila]

Package: src:ntp
Version: 1:4.2.8p9+dfsg-2
Severity: serious
Tags: patch

Dear maintainer:

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


[...]

Installing stand-alone HTML documentation
make[4]: Leaving directory '/<>/ntp-4.2.8p9+dfsg'
make[3]: Leaving directory '/<>/ntp-4.2.8p9+dfsg'
make[2]: Leaving directory '/<>/ntp-4.2.8p9+dfsg'
make[1]: Leaving directory '/<>/ntp-4.2.8p9+dfsg'
# move the administrator programs from /usr/bin to /usr/sbin
for file in ntpdate ntp-wait ntpd ntptime ntp-keygen; do \
mv debian/tmp/usr/bin/$file debian/tmp/usr/sbin/$file || exit; \
done
mv: cannot stat 'debian/tmp/usr/bin/ntpdate': No such file or directory
debian/rules:50: recipe for target 'install' failed
make: *** [install] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


The same failure happens in the reproducible builds autobuilders:

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

so I guess this should be easy to reproduce on a current stretch chroot.

Apparently ntpdate is already installed into usr/sbin and that's
why it does not exist in usr/bin anymore.

If that's the case, the trivial but untested patch below
would probably fix the problem (unless more binaries
are also in usr/sbin).

Because the same package version of ntp used to build in the past,
this is surely caused by a build-dependency that changed
behaviour.

So you might want to contact the maintainer of such build-dependency
that broke this and get a promise that the behaviour will not
change again between now and the release of stretch.

Thanks.

--- a/debian/rules
+++ b/debian/rules
@@ -55,7 +55,7 @@ install: build-stamp
$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp
 
# move the administrator programs from /usr/bin to /usr/sbin
-   for file in ntpdate ntp-wait ntpd ntptime ntp-keygen; do \
+   for file in ntp-wait ntpd ntptime ntp-keygen; do \
mv debian/tmp/usr/bin/$$file debian/tmp/usr/sbin/$$file || 
exit; \
done
 

Bug#851804: O: bmon -- portable bandwidth monitor and rate estimator

[Dmitry Smirnov]

Package: wnpp
Severity: normal

"bmon" needs new maintainer...

-- 
Regards,
 Dmitry Smirnov.


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

Bug#851805: nspr: testcase 'errcodes' fails with new-dtags: libnspr4.so => not found

[Jon Grimm]

Source: nspr
Severity: normal

Dear Maintainer,

ubuntu-zesty linker behavior has changed to --enable-new-dtags,
whereby -rpath now emits DT_RUNPATH instead of -DT_RPATH, which includes
some with respect to searching for dependent libraries.

The 'errcodes' testcase fails with:

./errcodes: error while loading shared libraries: libnspr4.so: cannot open 
shared object file: No such file or directory

Inspecting the binary:

$ ldd errcodes
linux-vdso.so.1 =>  (0x7ffcf5d71000)
libplc4.so => 
/build/nspr-f9K1qE/nspr-4.12/nspr/pr/tests/../../dist/lib/libplc4.so 
(0x7f95c6fe)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f95c6c15000)
/lib64/ld-linux-x86-64.so.2 (0x557b797dc000)
libnspr4.so => not found

The 'errcodes' test case is unique in that while it declares:

'-L../../dist/lib -lplc4 -L../../dist/lib -lnspr4' it only has a direct
dependency on plc4.  However, plc4 itself has a dependency on nspr4.

RUNPATH (unlike RPATH) does not attempt to find indirect library
dependencies, so errcodes fails.  

If using a linker that still defaults to RPATH, the --enable-new-dtags flag
should be able to uncover this issue (possibly needs --as-needed on the
library builds too?) I haven't attempted to reproduce elsewhere.

3 quick and dirty ways to address this:
1) LD_PRELOAD
2) --disable-new-dtags (old rpath behavior)
3) --no-as-needed  (force the lookup)

,or of course other ideas by folks more knowledgeable.

I can patch in Ubuntu, but I'd like to avoid carrying a delta,
so thought I'd open a bug to explore. Its not an issue for Debian (yet)
as far as I know unless linker defaults have changed too. 

I'm leaning towards --disable-new-tags in pr/tests/Makefile.in just to
force the old rpath behavior (patch attached). With this errcodes (and
all of the rest of the pr/tests) pass.  Very open to a more proper fix.

$ ldd errcodes
linux-vdso.so.1 =>  (0x7fffd23d9000)
libplc4.so => 
/build/nspr-CbIx53/nspr-4.12/nspr/pr/tests/../../dist/lib/libplc4.so 
(0x7f9029c4f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9029884000)
libnspr4.so => 
/build/nspr-CbIx53/nspr-4.12/nspr/pr/tests/../../dist/lib/libnspr4.so 
(0x7f9029645000)
/lib64/ld-linux-x86-64.so.2 (0x5559770dc000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f9029427000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9029223000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f9029019000)



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

Kernel: Linux 4.8.0-34-generic (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)
--- a/nspr/pr/tests/Makefile.in
+++ b/nspr/pr/tests/Makefile.in
@@ -315,7 +315,7 @@ ifeq ($(OS_ARCH), SunOS)
 endif # SunOS
 
 ifeq (,$(filter-out Linux GNU GNU_%,$(OS_ARCH)))
-LDOPTS += -Xlinker -rpath $(ABSOLUTE_LIB_DIR)
+LDOPTS += -Xlinker -rpath $(ABSOLUTE_LIB_DIR) -Xlinker --disable-new-dtags
 ifeq ($(USE_PTHREADS),1)
 EXTRA_LIBS = -lpthread
 endif

Bug#851802: xfce4-settings: xfce4-mouse-settings speed no effect for TPPS/2 IBM TrackPoint, tracks slower to right

[Mark Hedges]

Package: xfce4-settings
Version: 4.12.1-1
Severity: normal

Dear Maintainer,

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

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

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

I have a ThinkPad X1 Carbon 4th Gen with a "SynPS/2 Synaptics Touchpad" and 
"TPPS/2 IBM TrackPoint" selectable in xfce4-mouse-settings.  I disabled the 
Touchpad because I don't like it.  I use the TrackPoint, the tiny red joystick 
between the G, H and B keys.  The Acceleration and Sensitivity settings in 
xfce4-mouse-settings seem to have no effect on the TrackPoint.  Also, it seems 
to move slower when I go to the right.  It takes a long time to move the 
pointer from one side of the screen to the other.  It doesn't seem to behave 
this way when I boot Windows 10.  Thanks.  -Mark


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

Kernel: Linux 4.8.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
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 xfce4-settings depends on:
ii  libc62.24-8
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.14-1
ii  libdbus-glib-1-2 0.108-1
ii  libexo-1-0   0.10.7-1
ii  libfontconfig1   2.11.0-6.7
ii  libgarcon-1-00.4.0-2
ii  libgarcon-common 0.4.0-2
ii  libgdk-pixbuf2.0-0   2.36.3-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-1
ii  libnotify4   0.7.7-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libupower-glib3  0.99.4-4
ii  libx11-6 2:1.6.4-2
ii  libxcursor1  1:1.1.14-1+b1
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1
ii  libxi6   2:1.7.8-2
ii  libxklavier165.4-2
ii  libxrandr2   2:1.5.1-1
ii  xfconf   4.12.1-1

Versions of packages xfce4-settings recommends:
ii  x11-utils  7.7+3

xfce4-settings suggests no packages.

-- no debconf information

Bug#851801: fonts-wqy-zenhei: Provides wrong glyph for U+10000

[Anthony Fok]

Package: fonts-wqy-zenhei
Version: 0.9.45-6
Severity: normal
Tags: l10n upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

For some unknown reasons, WenQuanYi Zen Hei, a primarily Chinese font,
somehow provides a Tofu-like white-square glyph for U+1,
named "hu1" in the font.

However, U+1 is actually "LINEAR B SYLLABLE B008 A", a very ancient
form of Greek, provided by proper Linear B fonts such as the
"Noto Sans Linear B" in
/usr/share/fonts/truetype/noto/NotoSansLinearB-Regular.ttf
in the fonts-noto-unhinted package.

And, somewhat unfortunately, maybe due to the fontconfig files that come
with fonts-wqy-zenhei, the wrong "Tofu" glyph in WQY ZenHei trumps
the correct glyph in "Noto Sans Linear B".

So, in summary, three issues:

 1. Find a way to contact the upstream author?  :-)
 2. Fix the actual "WenQuanYi Zen Hei" TrueType font to remove U+1.
 3. Check its fontconfig file, say, 64-wqy-zenhei.conf, and see if
we can stop WenQuanYi Zen Hei's erroneous U+1 from trumping
others?

Cheers,

Anthony

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

Kernel: Linux 4.8.0-2-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 fonts-wqy-zenhei depends on:
ii  dpkg1.18.18
ii  fontconfig  2.11.0-6.7

fonts-wqy-zenhei recommends no packages.

fonts-wqy-zenhei suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAlh/5MIACgkQ6iUAtBLF
ms8f3A//YrKD6NhgectANgzXmuHtIxp41XLBjlikI9ibFsX6lY+kXhAdAOyU4FM6
7Pvid290qmbFzyrqZoX6uvl2kFHEVfeIESFuaeHLjhyxFnUKrHBVusyODgGydD4N
ZjCBxHowH2dZXKXfEZ+546NNGVEmM0mPLRE4Rw3BhdZUDITXI8rmFTR9itt1vE+g
ntzhdvQSocvyMW9ssQJDfM7UwLXp3fogo33mdajHy1lQIYlRtuvcOb+rl/nfMzvx
lQsOa7wvsN3RaV6YpNGpLaZYT0PnGNDTMMky6Fcbrsv9yFtQoQB3czIDompVqKCY
jgIOmUXfIzu3NqUGiVjDKPgeZ1Sg1a9JpexqdDd5/K+ugCzMX9rXDSbIzRQNTSht
Zrj5RzAdZs6GLjol8xOOMTl9R5XS+5vBM3Jprr0hFE2ZwfkaOuEJYdlB7Ca45TAJ
Qb+BI6pMtMxrUmkn6LpllSC4DI6fc4Geth3hVKaTSNyiH14fJbGy1bbheoIsgZeC
cG0+7flVp0I6xn2RZW4sf6zcjmKj4G+Ah8ZWgzLuyBCFFCJqs3EfnB3+nv5RSJRU
V+C+uBPzC/1aK7Wl+V2KlErZkqdVOWFhT7bs86yQsVsUE47ekCnLI4K1eCLFYiWf
OYXhz87BWgMmN53S35+4d++9GjPbE/KTcx5k8jG+Jx084/Xvrzc=
=ttTw
-END PGP SIGNATURE-

Bug#851757: [Pkg-nagios-devel] Bug#851757: nagios-nrpe-plugin: Segmentation fault when specifying the host with an IP address

[Sebastiaan Couwenberg]

Control: tags -1 unreproducible moreinfo

Hi Stephane,

Thanks for reporting this issue, unfortunately I cannot reproduce it.

On 01/18/2017 01:28 PM, Stephane Bortzmeyer wrote:
> % /usr/lib/nagios/plugins/check_nrpe -H 198.0.2.153  -c 'check_disks' 
> zsh: segmentation fault  /usr/lib/nagios/plugins/check_nrpe -H 198.0.2.153 -c 
> 'check_disks'
> 
> % /usr/lib/nagios/plugins/check_nrpe -H my.machine.example -c 'check_disks'  
> zsh: segmentation fault  /usr/lib/nagios/plugins/check_nrpe -H 
> my.machine.example -c 'check_disks'
> 
> But if I use -4 or -6, and a host name, everything works:
> 
> % /usr/lib/nagios/plugins/check_nrpe -H my.machine.example -6 -c 
> 'check_disks'  
> DISK OK - free space: / 6113 MB (32% inode=79%);| 
> /=12973MB;16100;18113;0;20126

Running check_nrpe on Debian unstable and checking a Debian jessie and
Debian unstable host works fine on my test system both with a bash & zsh
shell.

How can I reproduce the issue?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#851166: nmu: forge_0.9.2-2 [RC]

[Emilio Pozuelo Monfort]

On 14/01/17 20:32, Ghislain Vaillant wrote:
> I forgot to mention that this NMU would fix the current RC affecting
> forge. The FTBFS was due to a bug in the CMake detection of the glm
> library, which I have fixed since.

I'm not sure I understand. If there is a FTBFS, wouldn't the binNMU fail to
build? If not, why not?

Do you actually want us to retry the failed builds in [1] ?

[1] https://buildd.debian.org/status/package.php?p=forge

Cheers,
Emilio

Bug#783615: "update-ca-certificates --fresh" doesn't correctly re-add certificates in /usr/local/share/ca-certificates

[Michael Shuler]

On 01/18/2017 03:25 PM, Adrian Bunk wrote:
> after a discussion with someone who ran into this bug in stable I have 
> set the severity to serious, since this should IMHO also be fixed in 
> stable.

This does look like a good patch to backport to stable. I'll get this
commited to git and work on a stable update. Thanks, Adrian!

-- 
Kind regards,
Michael

Bug#811377: Bug#851747: sysvinit-utils: unmaintained package should not be Essential

[Petter Reinholdtsen]

[Ian Jackson]
> I don't want to do an upload of this package just to change the
> Uploaders - particularly at this stage of the release.

Why not?  I would guess particularly at this stage in the release, it is
smart to trim the list of maintainers down to those that plan to spend
time on the sysvinit package for the next stable release cycle.

> But, for the avoidance of any doubt, I hereby re-express my intent to
> help adopt this package.  I would like the next upload to name me in
> Uploaders.  I'm happy to share this role with the people who have
> written to #811377.

Did you commit your name to git?  If not, why not?
-- 
Happy hacking
Petter Reinholdtsen

Bug#819811: ITP: leiningen -- simple build system for Clojure

[Tom Marble]

Based on the fabulous work of ehashman and the help of technomancy
I've made some minor reformatting of the "state of packaging leiningen"
below. The biggest change is that I'm not calling out transitive
deps (on leiningen missing deps).

In terms of next steps

1. technomancy is already addressing the
   'deps with unstable-version > leiningen 2.7.2-SNAPSHOT'
   issues upstream.

2. We should probably start with 
   'deps with unstable-version < leiningen 2.7.2-SNAPSHOT'

3. Then the big work is on missing deps (which will be recursive :)
   NOTE: I had some packaging on alioth for some of these
   which probably can be reprised.

Question on java/clojure policy.. should names with a dot
be converted to a dash?
  Does [org.clojure/tools.nrepl "0.2.12"]
  want to be libtools.nrepl-clojure or libtools-nrepl-clojure ?
 (my guess is the latter)???

Regards,

--Tom

** deps with unstable-version == leiningen 2.7.2-SNAPSHOT
*** [org.clojure/data.xml "0.0.8"]
unstable: https://packages.debian.org/sid/libdata-xml-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L10
*** [commons-io "2.5"]
unstable: https://packages.debian.org/sid/libcommons-io-java 
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L11 
 
*** [clojure-complete "0.2.4"]
unstable: https://packages.debian.org/sid/libcomplete-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L17
NOTE: check for old packaging on alioth
*** [robert/hooke "1.3.0"]
unstable: https://packages.debian.org/sid/librobert-hooke-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L9
 
*** [org.tcrawley/dynapath "0.2.5"]
unstable: https://packages.debian.org/sid/libdynapath-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L11
*** [org.apache.maven.wagon/wagon-http "2.10"]
unstable: https://packages.debian.org/sid/libwagon2-java
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L12
 
*** [com.hypirion/io "0.3.1"]
unstable: https://packages.debian.org/sid/libcom-hypirion-io-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L13
NOTE: check for old packaging on alioth

** deps with unstable-version < leiningen 2.7.2-SNAPSHOT
*** [slingshot "0.12.2"]
unstable: 0.10.3 https://packages.debian.org/sid/libslingshot-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L19
NOTE: check for old packaging on alioth
*** [bultitude "0.2.8"]
unstable: 0.2.7 https://packages.debian.org/sid/libbultitude-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L7
 
*** [com.cemerick/pomegranate "0.3.1"]
unstable: 0.2.0 https://packages.debian.org/sid/libpomegranate-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L12

** deps with unstable-version > leiningen 2.7.2-SNAPSHOT
*** [org.clojure/tools.macro "0.1.2"]
unstable: 0.1.5 https://packages.debian.org/sid/libtools-macro-clojure
leiningen: 0.1.2 
https://github.com/technomancy/leiningen/blob/master/test_projects/sample-profile-meta/project.clj#L10
*** [commons-codec "1.6"]
unstable: 1.10 https://packages.debian.org/sid/libcommons-codec-java
leiningen: 
./test_projects/managed-deps-snapshot/project.clj
./test_projects/managed-deps/project.clj
*** [clj-stacktrace "0.2.4"]
unstable: 0.2.6 https://packages.debian.org/sid/libclj-stacktrace-clojure
leiningen: 
./resources/leiningen/help/project.clj: :dependencies [[clj-stacktrace 
"0.2.4"]]}
3:17 < tmarble> technomancy: we have [clj-stacktrace "0.2.6"] 
https://packages.debian.org/sid/libclj-stacktrace-clojure
13:17 < tmarble> but you have ./resources/leiningen/help/project.clj: 
:dependencies [[clj-stacktrace "0.2.4"]]}
13:17 < tmarble> ... can that be bumped?
13:22 < technomancy> tmarble: that file is help text, not an actual project.clj 
=)
13:22 < tmarble> nvm :)

** deps missing from leiningen 2.7.2-SNAPSHOT
*** [clj-http "2.0.1"]
unstable: https://packages.debian.org/sid/libclj-http-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L21
NOTE:  [clj-http "2.0.1"]
[commons-codec "1.10" :exclusions [[org.clojure/clojure]]]
[org.apache.httpcomponents/httpclient "4.5" :exclusions 
*** [org.clojure/tools.nrepl "0.2.12"]
unstable: https://packages.debian.org/sid/libtools.nrepl-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L16
*** [cheshire "5.6.3"]
unstable: https://packages.debian.org/sid/libcheshire-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L20
*** [classlojure "0.6.6"]
unstable: https://packages.debian.org/sid/libclasslojure-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L8
*** [pedantic "0.2.0"]
unstable: 

Bug#851716: dgit: commit checks may be too strict

[Ian Jackson]

Control: tags -1 confirmed
Control: clone -1 -2
Control: retitle -2 policy hook cannot in fact set NOCOMMITCHECK

peter green writes ("Bug#851716: dgit: commit checks may be too strict"):
> Github seems quite happy with the commit as does git fsck, so IMO
> this is a case of dgit being too strict.

I think you are right.

> 1. Changing bitmask=0 to bitmask=8
> 2. Adding bitmask=$(( bitmask | `policyflags 'NOCOMMITCHECK'` )) just before 
> the exit command
> 3. Adding bitmask=$(( bitmask | 8 )) just before the exit command

This is a separate bug.

-- 
Ian Jackson    These opinions are my own.

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

Bug#851799: RFS: hamlib/3.1.0-1

[Ervin Hegedüs]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name  : hamlib
 Version : 3.1.0-1
 Upstream Author : Kamal Mostafa , Colin Tuckley 

 * URL   : https://sourceforge.net/projects/hamlib/
 * License   : LGPLv2
 Section : hamradio

It builds those binary packages:

libhamlib++-dev - Development C++ library to control radio transceivers and 
receive
libhamlib-dev - Development library to control radio transceivers and receivers
libhamlib-doc - Documentation for the hamlib radio control library
libhamlib-utils - Utilities to support the hamlib radio control library
libhamlib2 - Run-time library to control radio transceivers and receivers
libhamlib2++c2 - Run-time C++ library to control radio transceivers and 
receivers
libhamlib2-perl - Run-time perl library to control radio transceivers and 
receivers
libhamlib2-tcl - Run-time Tcl library to control radio transceivers and 
receivers
lua-hamlib2 - Run-time Lua library to control radio transceivers and receivers
python-libhamlib2 - Run-time Python library to control radio transceivers and 
receive

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hamlib/hamlib_3.1.0-1.dsc

More information about hello can be obtained from
https://sourceforge.net/projects/hamlib

Changes since the last upload:

 * Team upload
 * New upstream release
 * Changed manpages directory in manpage-hyphen-fixes.patch
 * Added Lua binding
 * Fixed broken libhamlib2-tcl package
 * Bump Standards-version to 3.9.8

Regards,
 Ervin Hegedüs

-- 
I � UTF-8

Bug#824480: sphinxsearch: /usr/bin/search is missing in the package

[Jean-François Stenuit]

The CLI interface to sphinxsearch has been deprecated by upstream at 
version 0.9.9-rc2 (back in 2009).
Lots of outdated documentation still refer to it, but the official way 
of testing sphinx in version 2.2 is to use any mysql client (Sphinx has 
an API that is compatible with them).
It may be wise to add either mariadb-client-core or mysql-client-core as 
dependency or suggestion for the package. Otherwise, first installation 
and debugging of sphinxsearch may indeed be a problem.


Jef

On Wed, 26 Oct 2016 17:55:47 +0800 YunQiang Su  wrote:
> On Mon, 16 May 2016 16:45:40 +0300 Anton Avramov  wrote:
> > Package: sphinxsearch
> > Version: 2.2.9-1~bpo8+1
> > Severity: important
> >
> > The binary for testing the configuration /usr/bin/search is missing 
from the package.
> > It is used by the users to test the the index and further more it 
is mentioned in too many places

> >
>
> By reading the Makefile, I still cannot know where it is generated.
>
> >
> > -- System Information:
> > Debian Release: 8.3
> > APT prefers stable
> > APT policy: (500, 'stable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > Versions of packages sphinxsearch depends on:
> > ii adduser 3.113+nmu3
> > ii libc6 2.19-18+deb8u3
> > ii libexpat1 2.1.0-6+deb8u1
> > ii libgcc1 1:4.9.2-10
> > ii libmysqlclient18 10.0.24+maria-1~jessie
> > ii libpq5 9.4.6-0+deb8u1
> > ii libstdc++6 4.9.2-10
> > ii libstem

Bug#851195: [debian-mysql] Bug#851195: mariadb-server-10.1: Time Zone system tables are empty

[Otto Kekäläinen]

I tried multiple variations but the step always fails and looking at
/var/log/syslog and /var/log/mysql/error.log I don't understand why.

# Add 'set -x' to /var/lib/dpkg/info/mariadb-server-10.1.postinst
$ apt-get install -f
...
+ password_column_fix_query='USE mysql;
 SET sql_log_bin=0;
 ALTER TABLE user CHANGE Password Password char(41) character set
latin1 collate latin1_bin DEFAULT '\'''\'' NOT NULL;'
+ logger -p daemon.err -t mysqld_safe -i
+ /usr/sbin/mysqld --bootstrap --user=mysql --disable-log-bin
--skip-grant-tables --default-storage-engine=myisam
+ echo 'USE mysql;
 SET sql_log_bin=0;
 ALTER TABLE user CHANGE Password Password char(41) character set
latin1 collate latin1_bin DEFAULT '\'''\'' NOT NULL;'
+ /usr/sbin/mysqld --bootstrap --user=mysql --disable-log-bin
--skip-grant-tables --default-storage-engine=myisam
+ /usr/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo
2017-01-18 21:25:49 140333538371456 [Note] /usr/sbin/mysqld (mysqld
10.1.21-MariaDB-1~zesty1~1484766332.4c6cf54) starting as process 10129
...
dpkg: error processing package mariadb-server-10.1 (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mariadb-server:
 mariadb-server depends on mariadb-server-10.1 (>=
10.1.21-1~zesty1~1484766332.4c6cf54); however:
  Package mariadb-server-10.1 is not configured yet.

dpkg: error processing package mariadb-server (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a
followup error from a previous failure.

   Errors were encountered while
processing:
 mariadb-server-10.1
 mariadb-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#783615: "update-ca-certificates --fresh" doesn't correctly re-add certificates in /usr/local/share/ca-certificates

[Adrian Bunk]

Hi,

after a discussion with someone who ran into this bug in stable I have 
set the severity to serious, since this should IMHO also be fixed in 
stable.

It is a very nasty bug when something works on the first execution of
a command but not on subsequent executions, and the fix looks really
trivial.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#851756: RFS: telegram-desktop/1.0.0-2

[Gianfranco Costamagna]

Hello

>Version : 1.0.0-2~rc2

>https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-2~rc2.dsc



I see tag for 1.0.1 pushed on github [1]

Isn't it a good release? I didn't look at the code, but instead of an rc, I 
would prefer a stable
1.0.1 (even if it is just a tag and not a release, so I might be *very* wrong)

G.


[1] https://github.com/telegramdesktop/tdesktop/releases

Bug#839443: bcron: some failing test disabled for now

[Gianfranco Costamagna]

control: severity -1 important

Hi, I'm downgrading this one, to make the current bcron have chances to 
migrated.

I think tests should be fixed, but disabling a couple of them "fixed" the 
build, and
will probably make it go in Stretch

G.



signature.asc
Description: OpenPGP digital signature

Bug#850396: xymon-client: ifstat graph appears to not recognize new net-tools output

[david]

Axel,

I suppose your findings are both good and bad. Good that things work for 
you, bad they aren't for me.


On 01/18/2017 11:17 AM, Axel Beckert wrote:

I've now managed to temporarily install xymon-client on a machine
which has:

* Xymon 4.3.27-3+b1
* systemd as init system
* These interfaces:

  → ifconfig | egrep '^[^ ]'
  enp0s25: flags=4099  mtu 1500
  lo: flags=73  mtu 65536
  teredo: flags=4305  mtu 1280
  wlp3s0: flags=4163  mtu 1500

This should be close enough to your setup.


Yes, pretty close:

$ ifconfig | egrep '^[^ ]'
eth0: flags=4099  mtu 1500
lo: flags=73  mtu 65536
wlp4s0: flags=4163  mtu 1500

Same xymon-client version with systemd and udev.


On the server side I have the xymon package version 4.3.28~rc2-1 (from
Debian experimental) running on a Raspberry Pi.




Which version of Xymon do you have running on the server side?

Is the server side also running Xymon 4.3.27? Or is it running an
earlier version than the client, e.g. 4.3.17 from Debian 8 Jessie?


I suspect this is where the issue lies as I am running Debian 8 with 
only the kernel upgraded via backports to 4.7 at this time. The version 
of Xymon is *4.3.17-6+deb8u1* which is listed as most current without 
using backports.


I'm somewhat loathe to have a mixed system for my daily workhorse, so 
maybe I'll just live with things as they are now, and just have to keep 
the interface rename using udev .link files.


Other thoughts are appreciated, but I think the problem problem lies 
with the age of the server side application as you seem to indicate.


david

Bug#851777: Remmina and RDGateway issue 851...@bugs.debian.org.

[dh]

redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:0
redirectsmartcards:i:1
devicestoredirect:s:*
drivestoredirect:s:*
redirectdrives:i:1
session bpp:i:32
prompt for credentials on client:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:1
videoplaybackmode:i:1
audiocapturemode:i:1
gatewayusagemethod:i:2
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:DEMO-RDS-01.IVENTUREDEMO.LOCAL
gatewayhostname:s:rds.iventurehosted.com
workspace id:s:DEMO-RDS-01.iventuredemo.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.iVenture_RDS_Dem
use multimon:i:1
alternate full address:s:DEMO-RDS-01.IVENTUREDEMO.LOCAL
signscope:s:Full Address,Alternate Full Address,Use Redirection Server 
Name,Server 
Port,GatewayHostname,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource,PromptCredentialOnce,RedirectDrives,RedirectPrinters,RedirectCOMPorts,RedirectSmartCards,RedirectClipboard,DevicesToRedirect,DrivesToRedirect,LoadBalanceInfo
signature:s:AQABAAEAAAB/DgAAMIIOewYJKoZIhvcNAQcCoIIObDCCDmgCAQExCzAJBgUrDgMC  
GgUAMAsGCSqGSIb3DQEHAaCCDLQwggNUMIICPKADAgECAgMCNFYwDQYJKoZIhvcN  
AQEFBQAwQjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xGzAZ  
BgNVBAMTEkdlb1RydXN0IEdsb2JhbCBDQTAeFw0wMjA1MjEwNDAwMDBaFw0yMjA1  
MjEwNDAwMDBaMEIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMu  
MRswGQYDVQQDExJHZW9UcnVzdCBHbG9iYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUA  
A4IBDwAwggEKAoIBAQDazBhjMP30FyMaVn5b3zxsOORxt3iR1Lyh2Ez4qEO2A+lN  IQc$


Errors

** (remmina:20934): WARNING **: Error retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not 
provided by any .service files
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

(remmina:20934): GLib-CRITICAL **: g_str_has_prefix: assertion 'str != NULL' 
failed
loading channel cliprdr
tcp_connect: getaddrinfo (Name or service not known)
Error: protocol security negotiation or connection failure
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
.rdp file attached
 Duncan Hare

714 931 7952

cpub-iVenture_RDS_Dem-iVenture_RDS_Dem-CmsRdsh.rdp
Description: application/rdp

Bug#851798: tor: IPv6 connections through tor do not appear to work

[Daniel Kahn Gillmor]

Package: tor
Version: 0.3.0.1-alpha-1
Severity: normal
Control: block 849845 with -1
Control: affects -1 dirmgnr

consider the following two commands:

curl --socks5-hostname 127.0.0.1:9050 http://www.google.com

curl --socks5-hostname 127.0.0.1:9050 http://ipv6.google.com


www.google.com has A and  records.

ipv6.google.com has only  records.

the first command shows me the body of the 302 redirection.

the second command sends this line to stderr:

curl: (7) Can't complete SOCKS5 connection to 0.0.0.0:0. (4)

and returns error code 7.

afaict, this is true for every connection to an IPv6 address through
tor.

I'm not sure how to debug, but this appears to be what's causing the
tor+ipv6 failures for dirmngr over on https://bugs.debian.org/849845,
so i'm marking this as blocking that bug.

Any suggestions for debugging?  can you reproduce the problem?  Should
i be trying to do this some other way?

  --dkg


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

Kernel: Linux 4.8.0-2-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 tor depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  libevent-2.0-5   2.0.21-stable-2.1
ii  libseccomp2  2.3.1-2.1
ii  libssl1.11.1.0c-2
ii  libsystemd0  232-8
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-4

Versions of packages tor recommends:
pn  logrotate
ii  tor-geoipdb  0.2.9.8-2
ii  torsocks 2.2.0-1

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
pn  obfsproxy
ii  socat1.7.3.1-2
pn  tor-arm  
ii  torbrowser-launcher  0.2.6-3

-- no debconf information

Bug#495526: closed by Michael Gilbert <mgilb...@debian.org> (re: automatic fetching of domain-name-servers from resolv.conf)

[Josip Rodin]

reopen 495526
thanks

On Sat, Jan 14, 2017 at 10:51:04PM +, Debian Bug Tracking System wrote:
> From: Michael Gilbert 
> To: 495526-cl...@bugs.debian.org
> Subject: re: automatic fetching of domain-name-servers from resolv.conf
> 
> DDNS can be used to achieve your goal.

Sorry, I don't understand, what does that mean? How does Dynamic DNS factor
into this at all? Or is DDNS some new acronym for something else?

The issue was that one had to hardcode specific IP addresses of
recursive DNS servers given out to DHCP clients in the DHCP server's
domain-name-servers setting. What I was suggesting is to have a way of
telling the DHCP server to not require that, but that it relays whatever
the system resolver is currently set with.

-- 
 2. That which causes joy or happiness.

Bug#777726: joe: please make the build reproducible

[Josip Rodin]

On Mon, Jan 16, 2017 at 06:11:03AM +, Chris Lamb wrote:
> > Would you consider applying this patch and uploading?
> 
> Friendly ping on this :)

Oh I'm so sorry for apparently ignoring you with this, I just didn't get
around to it in the last upload, but I have every intention to add it in
the next one. The patch seems straightforward enough, if you wanted to
upload it yourself, there'd be absolutely no objection from me.

-- 
 2. That which causes joy or happiness.

Bug#364975: Any news about this bug?

[Jose M Calhariz]

Thank you for pointing me out this defect.  I will review it at first
opportunity.

Kind regards
Jose M Calhariz


On 17/01/17 12:47, Dmitriy Kovalkov wrote:
> Any news about this bug?
>
> Problem exist in
>
> Last in Arch:
>
> [kovalkov@localhost ~]$ at -V
> at version 3.1.19
> Please report bugs to the Debian bug tracking system (
> http://bugs.debian.org/)
> or contact the maintainers (a...@packages.debian.org).
>
> Last in Ubuntu 16.04:
>
> apt-cache policy at
> at:
>   Installed: (none)
>   Candidate: 3.1.18-2ubuntu1
>   Version table:
>  3.1.18-2ubuntu1 500
> 500 http://ru.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
>
> Last in Debian 8:
>
> root@repo:/# at -V
> at version 3.1.13
> Please report bugs to the Debian bug tracking system (
> http://bugs.debian.org/)
> or contact the maintainers (a...@packages.debian.org).
>
> ---
> Respectfully, Dmitrii Kovalkov
> FASTVPS technical department
>




signature.asc
Description: OpenPGP digital signature