Bug#825701: should osptoolkit be removed from Debian?

['Mattia Rizzolo']

On Mon, Jun 27, 2016 at 09:07:31AM +0800, Di-Shi Sun wrote:
> Hi Mattia,
> 
> We went through the list and met one issue,
> 
> dpkg-genchanges: warning: package osptoolkit-dbgsym listed in files list but
> not in control info
> dpkg-genchanges: warning: package libosptk4-dbgsym listed in files list but
> not in control info

this one is a red herring.  FYI this is already fixed in dpkg's git (not
publically).

> All others look fine.

yep indeed)

> The updated packages have been uploaded to mentors.

I tweaked d/changelog to keep only one paragraph, as the others refers
to non-uploaded versions, see the attached diff.
And uploaded :)
I'll make sure to close this bug by myself once accepted (as it has to
go through NEW

> BTW, we believe #555877 have been fixed in 3.4.2-1.1 by explicitly linking
> external libraries.

ok, I'm closing it, then.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#790269: ser2net: missing tcp wrapper / hosts_access support

[Marc Haber]

tags #790269 confirmed pending
thanks

On Sat, Jun 27, 2015 at 07:30:38PM +, Vit Cepela (DHL IT Services) wrote:
> current stable (jessie) version is probably build without --with-tcp-wrappers 
> option enabled.

Thanks for spotting this. It was probably lost in the debhelper 7
conversion. Re-added.

Greetings
Marc

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

Bug#828606: xmlsec1: FTBFS with openssl 1.1.0

[John Belmonte]

I'll have to upgrade to a newer upstream version.  Looks like this was
addressed in 1.2.21.

On Sun, Jun 26, 2016 at 3:24 AM, Kurt Roeckx  wrote:

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

Bug#828624: [Pkg-samba-maint] Bug#828624: samba: Service fails to install and start

[Christian PERRIER]

Quoting Marc J. Driftmeyer (m...@reanimality.com):

> Gotta love when testing isn't thorough.


What exactly was your intention when adding this information to this
already reported bug?




signature.asc
Description: PGP signature

Bug#828710: RFS: apvlv/0.1.5+dfsg-1 [QA] -- PDF viewer with Vim-like behaviour

[Sean Whitton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a QA upload of apvlv.

* Package name: apvlv
  Version : 0.1.5+dfsg-1
  Upstream Author : Alf 
* URL : http://naihe2010.github.io/apvlv/
* License : GPL-2+
  Section : text

Changes since the last upload:

  * QA upload.
  * Set maintainer to QA team (see #798945).
  * New upstream release.  (Closes: #662806)
- New build dependency: libpoppler-private-dev
- Build dependency change libgtk2.0-dev -> libgtk-3-dev
- Drop d/copyright paragraph for autoconf files that are no longer present.
- Drop obsolete d/desktop.
  Upstream now provides a desktop file.
  * Enable build flags to view HTML and text files.
- New build dependency: libwebkitgtk-3.0-dev
  * Modernise d/rules:
- Use dh sequencer
- Use --parallel
- Add d/install
- Append to d/dirs
- Bump debhelper compat & dependency to 9
- Enable all hardening
  * Convert d/copyright to DEP-5.
- Correct upstream license GPL-2 -> GPL-2+.
  See the headers of the source files.
- Add paragraph for icons, using the copyright file of src:gnome-icon-theme.
  * Update homepage, d/copyright & d/watch for upstream's move to GitHub
(Closes: #651635, #738772).
Thanks to Andreas Moog and Matanya Moses for reporting this.
  * Update upstream author's e-mail address in d/copyright.
  * Add myself to copyright paragraph for debian/ subdir.
  * Add gbp.conf to filter 15M of library source code and DLLs without
source code that are needed only for the Windows build of apvlv.
- Add Debian version mangle to d/watch.
  * Bump standards version to 3.9.8.
- Drop obsolete d/menu.
  * Add upstream metadata file.
  * Add doc-base registration for Startup.pdf.
  * Switch to source format 3.0 (quilt).
  * Add 0001-manpage-spelling.patch
  * Add 0002-desktop-file-keywords.patch
  * Add 0003-add-Icon-to-desktop-file.patch
  * Add 0004-debian-paths.patch
  * Add 0005-fix-build-with-GCC-6.patch (Closes: #811839)
  * Add 0006-restore-Debian-CXXFLAGS.patch
  * Add Vcs-* fields.
  * Run wrap-and-sort -abst.

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/a/apvlv/apvlv_0.1.5+dfsg-1.dsc

Or build it with gbp:

gbp clone --pristine-tar 
https://anonscm.debian.org/git/collab-maint/apvlv.git
cd apvlv
git checkout debian/0.1.5+dfsg-1
git verify-tag debian/0.1.5+dfsg-1 # if you have my key
gbp buildpackage

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[brazilofmux]

Regarding tinymux: Removal of debhelper compat 4, the 2.6.5.34-1.1 version of 
TinyMUX in testing is at compact level 9. It should be not be flagged for 
autoremoval.


Thanks,

Stephen Dennis

Bug#828709: /usr/sbin/invoke-rc.d: uses non-essential /sbin/runlevel

[Helmut Grohne]

Package: init-system-helpers
Version: 1.35
File: /usr/sbin/invoke-rc.d
Severity: minor
User: helm...@debian.org
Usertags: rebootstrap

While removing e.g. x11-common, I saw the following message scrolling
by:

| /usr/sbin/invoke-rc.d: 1: /usr/sbin/invoke-rc.d: /sbin/runlevel: not found
| invoke-rc.d: could not determine current runlevel
| invoke-rc.d: policy-rc.d denied execution of stop.

You can trigger it by debootstrapping a --variant=minbase sid chroot and
using invoke-rc.d. In this case, it was removing x11-common.

Given that invoke-rc.d does the right thing in the absence of an init
system, I mark this bug minor, but it could still explicitly check for
that condition. What do you think about the attached patch?

Having init non-essential is otherwise pretty nice. :)

Helmut
--- init-system-helpers-1.35/script/invoke-rc.d
+++ init-system-helpers-1.35+nmu1/script/invoke-rc.d
@@ -295,7 +295,8 @@
 fi
 
 ## Queries sysvinit for the current runlevel
-if ! RL=`${RUNLEVELHELPER}`; then
+RL=
+if ! { test -x "$RUNLEVELHELPER" && RL=`${RUNLEVELHELPER}`; }; then
 if [ -n "$is_systemd" ] && systemctl is-active --quiet sysinit.target; then
 # under systemd, the [2345] runlevels are only set upon reaching them;
 # if we are past sysinit.target (roughly equivalent to rcS), consider

Bug#825948: fix

[Serge E. Hallyn]

A package with the fix is uploaded to

https://mentors.debian.net/debian/pool/main/e/edbrowse/edbrowse_3.6.0.1-2.dsc

Bug#510589: Info received (icedove: segmentation fault)

[Jamesc Netvalue]

icedove

(icedove:13604): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data:
assertion 'targets != NULL' failed

(icedove:13604): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data:
assertion 'targets != NULL' failed

(icedove:13604): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data:
assertion 'targets != NULL' failed

(icedove:13604): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data:
assertion 'targets != NULL' failed

(icedove:13604): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data:
assertion 'targets != NULL' failed

(icedove:13604): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data:
assertion 'targets != NULL' failed
Segmentation fault

On Mon, Jun 27, 2016 at 1:45 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Christoph Goehre 
>
> If you wish to submit further information on this problem, please
> send it to 510...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 510589: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510589
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#828708: xserver-xorg: incorrect keycodes sent by X after upgrade

[Dan Forest-Barbier]

Package: xserver-xorg
Version: 1:7.7+15
Severity: important

Dear Maintainer,

I use Debian sid/unstable on an ASUS UX301LA laptop, my main environment is
SLIM + XFCE + AWESOME, and I use the French bépo (dvorak-like) alternative
mapping (pc105, fr, bepo).
After a recent dist-upgrade some non-character keys have been mixed (e.g.
pagedown is now mapped to menu, altgr is now mapped to return, ...).

Since the problem had not appeared until recently, I believe it was caused by a
dist-upgrade I ran on the 21st (the previous ones were on the 8th and 19th, and
contained no Xorg-related packages).
Here is are the X-related upgrades that took place (according to etckeeper):
-xserver-xorg-input-all 1:7.7+14 amd64
+xserver-xorg-input-all 1:7.7+15 amd64
+xserver-xorg-input-libinput 0.19.0-1 amd64
-xserver-xorg-video-nouveau 1:1.0.12-1+b1 amd64
+xserver-xorg-video-nouveau 1:1.0.12-2 amd64


I have tried using the mixed keys on both my display manager (slim) and a blank
user's startx (default XFCE session), and the problem was present.
The problem being present even outside of my personal session's settings
suggests it is not caused by my settings/environment.

I have tried using an external keyboard and using the mixed keys on it, and the
problem was present.
The problem being present even on an external keyboard suggests it is not input
device specific.


Here is the output from 'sudo evtest' on my laptop's keyboard, while inputting
LEFTMETA, ALTGR, and PAGEDOWN:

No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  AT Translated Set 2 keyboard
/dev/input/event1:  Lid Switch
/dev/input/event2:  Sleep Button
/dev/input/event3:  Power Button
/dev/input/event4:  Video Bus
/dev/input/event5:  PFU Limited  HHKB Professional JP
/dev/input/event6:  ETPS/2 Elantech Touchpad
/dev/input/event7:  Asus Wireless Radio Control
/dev/input/event8:  PC Speaker
/dev/input/event9:  Atmel Atmel maXTouch Digitizer
/dev/input/event10: HDA Intel HDMI HDMI/DP,pcm=3
/dev/input/event11: HDA Intel HDMI HDMI/DP,pcm=7
/dev/input/event12: HDA Intel HDMI HDMI/DP,pcm=8
/dev/input/event13: HDA Intel PCH Headphone
/dev/input/event14: HD WebCam
Select the device event number [0-14]: 0
Input driver version is 1.0.1
Input device ID: bus 0x11 vendor 0x1 product 0x1 version 0xab41
Input device name: "AT Translated Set 2 keyboard"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 1 (KEY_ESC)
Event code 2 (KEY_1)
Event code 3 (KEY_2)
Event code 4 (KEY_3)
Event code 5 (KEY_4)
Event code 6 (KEY_5)
Event code 7 (KEY_6)
Event code 8 (KEY_7)
Event code 9 (KEY_8)
Event code 10 (KEY_9)
Event code 11 (KEY_0)
Event code 12 (KEY_MINUS)
Event code 13 (KEY_EQUAL)
Event code 14 (KEY_BACKSPACE)
Event code 15 (KEY_TAB)
Event code 16 (KEY_Q)
Event code 17 (KEY_W)
Event code 18 (KEY_E)
Event code 19 (KEY_R)
Event code 20 (KEY_T)
Event code 21 (KEY_Y)
Event code 22 (KEY_U)
Event code 23 (KEY_I)
Event code 24 (KEY_O)
Event code 25 (KEY_P)
Event code 26 (KEY_LEFTBRACE)
Event code 27 (KEY_RIGHTBRACE)
Event code 28 (KEY_ENTER)
Event code 29 (KEY_LEFTCTRL)
Event code 30 (KEY_A)
Event code 31 (KEY_S)
Event code 32 (KEY_D)
Event code 33 (KEY_F)
Event code 34 (KEY_G)
Event code 35 (KEY_H)
Event code 36 (KEY_J)
Event code 37 (KEY_K)
Event code 38 (KEY_L)
Event code 39 (KEY_SEMICOLON)
Event code 40 (KEY_APOSTROPHE)
Event code 41 (KEY_GRAVE)
Event code 42 (KEY_LEFTSHIFT)
Event code 43 (KEY_BACKSLASH)
Event code 44 (KEY_Z)
Event code 45 (KEY_X)
Event code 46 (KEY_C)
Event code 47 (KEY_V)
Event code 48 (KEY_B)
Event code 49 (KEY_N)
Event code 50 (KEY_M)
Event code 51 (KEY_COMMA)
Event code 52 (KEY_DOT)
Event code 53 (KEY_SLASH)
Event code 54 (KEY_RIGHTSHIFT)
Event code 55 (KEY_KPASTERISK)
Event code 56 (KEY_LEFTALT)
Event code 57 (KEY_SPACE)
Event code 58 (KEY_CAPSLOCK)
Event code 59 (KEY_F1)
Event code 60 (KEY_F2)
Event code 61 (KEY_F3)
Event code 62 (KEY_F4)
Event code 63 (KEY_F5)
Event code 64 (KEY_F6)
Event code 65 (KEY_F7)
Event code 66 (KEY_F8)
Event code 67 (KEY_F9)
Event code 68 (KEY_F10)
Event code 69 (KEY_NUMLOCK)
Event code 70 (KEY_SCROLLLOCK)
Event code 71 (KEY_KP7)
Event code 72 (KEY_KP8)
Event code 73 (KEY_KP9)
Event code 74 (KEY_KPMINUS)
Event code 75 (KEY_KP4)
Event code 76 (KEY_KP5)
Event code 77 (KEY_KP6)
Event code 78 (KEY_KPPLUS)
Event code 79 (KEY_KP1)
Event code 80 (KEY_KP2)
Event code 81 (KEY_KP3)
Event code 82 (KEY_KP0)
Event code 83 (KEY_KPDOT)
Event code 85 (KEY_ZENKAKUHANKAKU)
Event code 86 (KEY_102ND)
Event code 87 (KEY_F11)
Event code 88 (KEY_F12)
Event code 89 

Bug#790969: [Pkg-lirc-maint] Bug#790969: Same here...

[Alec Leamas]

On 26/06/16 17:01, Andreas Heinlein wrote:

I came acrosss this bug since it describes exactly my problem - except
that I can rule out any hardware fault.

My setup is working fine under Ubuntu 12.04 with Kernel 3.13 and LIRC
0.9.0. I installed Debian 8.5 on the same machine on another partition,
using the same lircd.conf and getting exactly the problems that are
describe above. I am using kernel 4.6 from jessie-backports.

I too have a One4All remote, namely URC-6440.

I would be glad to help solve this problem, as it is a real show-stopper.


So, it's not about the hardware. The culprit is then most likely the 
kernel, there are changes made  in the IR subsystem.


Unfortunately, the 0.9.0 version is really old. The current version is 
0.9.4, but this is not officially yet packaged for Debian. If you want 
to help tracking down this the first step would be to update to 0.9.4 so 
we have some fresh code to start with. The upstream release [1] contains 
a debian source package which hopefully can be used to update.


However, be aware the 0.9.4 is quite a different beast than 0.9.0. In 
particular, the configuration has changed. Please read the 
debian/README.Debian file as a starter after unpacking the tarball as 
described in README.md.


If you can reproduce the bug on 0.9.4 we have a reasonable start to 
track this down. If we are lucky, the update might even solve the 
problem. Don't hold your breath, though.


Cheers!

--alec


[1] 
https://sourceforge.net/projects/lirc/files/LIRC/0.9.4/lirc-debian-src-0.9.4-1.1.tar.gz

Bug#826780: Please package OVS >= 2.6.0.dev1

[Ben Pfaff]

On Thu, Jun 09, 2016 at 01:23:12AM +0200, Thomas Goirand wrote:
> Source: openvswitch
> Version: 2.3.0+git20140819-4
> Severity: normal
> 
> Hi,
> 
> OpenStack Neutron currently has:
> 
> ovs>=2.5.0;python_version=='2.7' # Apache-2.0
> ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0
> 
> in its requirements.txt. Please package this at least to Debian Experimental,
> so that I can package Neutron Newton Beta 1.

I uploaded openvswitch_2.5.1~pre+git20160626-1 a couple of hours ago.
It's going through NEW processing.  I suspect that it will take a couple
of trial uploads to get the tests to pass reliably and on all
architectures.  I'm going to be traveling Monday through Thursday, with
limited time for computers, so absent helpful NMUs (which are welcome)
there will probably be at least limited breakage until Friday.

I honestly meant to upload this to experimental for the first one or two
tries but screwed up so it's destined for unstable.

Bug#828707: Nautilus window stuck after remote drag & drop

[Stephen Chadfield]

Package: nautilus
Version: 3.14.1-2

Problem: Nautilus window cannot be moved with a mouse click on the title
bar. Right-click menu fails to appear on title bar.

How to trigger: Use the nautilus "Connect to Server" function to
establish a remote connection via sftp. Middle-click a remote file and
drag it to the nautilus tab of a local directory. After that tab's
window is shown drop the file and choose "Copy here". The nautilus
window will become stuck as described above.

Sometimes it takes one or two attempts to trigger the problem.

Only restarting nautilus allows the window to be moved again/

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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.22-1
ii  gsettings-desktop-schemas  3.14.1-1
ii  gvfs   1.22.2-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u4
ii  libcairo-gobject2  1.14.0-2.1+deb8u1
ii  libcairo2  1.14.0-2.1+deb8u1
ii  libexempi3 2.2.1-2
ii  libexif12  0.6.21-2
ii  libgail-3-03.14.5-1+deb8u1
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u5
ii  libglib2.0-0   2.42.1-1+b1
ii  libglib2.0-data2.42.1-1
ii  libgnome-desktop-3-10  3.14.1-1
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libnautilus-extension1a3.14.1-2
ii  libnotify4 0.7.6-2
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libselinux12.3-2
ii  libtracker-sparql-1.0-01.2.4-2
ii  libx11-6   2:1.6.2-3
ii  libxml22.9.1+dfsg1-5+deb8u2
ii  nautilus-data  3.14.1-2
ii  shared-mime-info   1.3-1

Versions of packages nautilus recommends:
ii  eject  2.1.5+deb1+cvs20081104-13.1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  gnome-sushi3.12.0-2+b1
ii  gvfs-backends  1.22.2-1
ii  librsvg2-common2.40.5-1+deb8u2

Versions of packages nautilus suggests:
ii  brasero  3.11.4-1.1
ii  eog  3.14.1-1
ii  evince [pdf-viewer]  3.14.1-2+deb8u1
ii  totem3.14.0-2
ii  tracker  1.2.4-2
ii  xdg-user-dirs0.15-2

-- no debconf information

Bug#826113: [Pkg-gridengine-devel] Bug#826113: bugfix

[Afif Elghraoui]

Control: tag -1 + pending

Hello,

على الأحد 26 حزيران 2016 ‫19:45، كتب Carl Pupa:
> 
> When I applied your patch, did debuild, and then ran piuparts -d stretch 
> on the gridengine-common*.deb, I got the following, indicating that it 
> was still looking for the gridengine.default file:

Yeah, I noticed that while running piuparts earlier today. Fortunately,
I fixed it before upload.

> 
>update-alternatives: using /bin/tcsh to provide /bin/csh (csh) in 
> auto mode
>Setting up gridengine-common (8.1.8+dfsg-6) ...
>ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be 
> preloaded (cannot open shared object file): ignored.
>sed: can't read /usr/share/gridengine-common/gridengine.default: No 
> such file or directory

I needed to have /usr/share/gridengine/..., instead of
/usr/share/gridengine-common/... here

[...]

Anyway, thanks for taking a look! I uploaded the package earlier today
with the corrected patch. The latest changes should already be in git,
but the package itself needs ftpmaster approval before it can enter the
archive because I added a new binary package (gridengine-dev).


Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#826113: [Pkg-gridengine-devel] Bug#826113: bugfix

[Carl Pupa]

Hello Afif,

When I applied your patch, did debuild, and then ran piuparts -d stretch 
on the gridengine-common*.deb, I got the following, indicating that it 
was still looking for the gridengine.default file:


  update-alternatives: using /bin/tcsh to provide /bin/csh (csh) in 
auto mode

  Setting up gridengine-common (8.1.8+dfsg-6) ...
  ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be 
preloaded (cannot open shared object file): ignored.
  sed: can't read /usr/share/gridengine-common/gridengine.default: No 
such file or directory

  dpkg: error processing package gridengine-common (--configure):
   subprocess installed post-installation script returned error exit 
status 2

  Processing triggers for libc-bin (2.22-11) ...
  Errors were encountered while processing:
   gridengine-common
  E: Sub-process /usr/bin/dpkg returned an error code (1)

--Carl

On 6/25/16 8:25 PM, Afif Elghraoui wrote:


على السبت 25 حزيران 2016 ‫16:35، كتب Carl Pupa:

In that case I agree it doesn't really matter whether gridengine.default
is in examples or not.  I've attached a patch that simply change the
postinst script so that it takes the copy from
/usr/share/gridengine-common/ instead of /usr/share/doc/gridengine-common/.

This is close. Attached is what I had in mind as a complete solution. It
installs gridengine.default into /usr/share/gridengine-common/, does not
install it into /usr/share/doc/gridengine-common/examples/, and adjusts
the postinst script (like your patch did).

The debian/*examples and debian/*install files are used by
dh_installexamples(1) and dh_install(1), respectively, during the
package build. debhelper(7) has a list of similar commands.

Does this look good to you? I haven't tested it, but it looks ok to me.

Many thanks and regards
Afif

Bug#827939: Please consider marking mesa-utils as Multi-Arch: allowed

[Michel Dänzer]

On 25.06.2016 00:59, Lisandro Damián Nicanor Pérez Meyer wrote:
> On viernes, 24 de junio de 2016 11:08:32 A. M. ART Julien Cristau wrote:
>> On Thu, Jun 23, 2016 at 10:11:45 -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>>> Question: if a user has a video card wich is OpenGL2 or more capable but
>>> does not has libgl1-mesa-dri installed: does glxinfo informs "OpenGL
>>> version string:" with value 2 or more?
>>
>> They could be using a non-mesa driver.
> 
> OK, now I'm beggining to understand how this works. Depending on each video 
> card implementation it might require an associated -dri package.
> 
> Also glxutils will output the current OpenGL version supported depending 
> wether the video card supports it and the required software is installed.
> 
> If this is the case then this bug is indeed still valid, and now a more 
> important as before, as we can warn users wether they video card with their 
> current setup does supports OepnGL2+ or not.
> 
> Of course, if I missinterpreted something then please do not hasitate in 
> remarking it :)

As Julien pointed out, libqt5gui5 should really just check itself if it
can get a GLX context with the needed properties, instead of relying on
glxinfo for that.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature

Bug#827984: assertion failure with multiple GPUs and Xinerama enabled

[Michel Dänzer]

On 24.06.2016 23:16, Christopher Cramer wrote:
> On Fri, Jun 24, 2016 at 11:15:05AM +0900, Michel Dänzer wrote:
>> Does the attached patch fix this?
> 
> Well, it doesn't die with an assertion failure anymore.

Thanks for testing the fix, submitting it for upstream inclusion.


> But the behavior is not what I would expect - the screens are all
> mirrored. Maybe that is a separate issue, though.

That's expected with the Section "ServerLayout" in the
/etc/X11/xorg.conf file included in the bug report. See the xorg.conf
manpage chapter about the ServerLayout section for how to position screens.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#825317: bash-completion: Un-escaped "~*" leads to spurious NSS lookups

[Nathan Stratton Treadway]

00-fix_quote_readline_by_ref.patch was introduced in
bash-completion v1:2.1-3 as a fix for bug 739835 "filename completion
broken with bash 4.3".
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739835

The patch file was originally pulled from Ubuntu, where it was created
to fix two LP bugs: 
* avoid escaping 1st '~' (LP: #1288314)
* avoid quoting if empty, else expansion without args only shows
  dirs (LP: #1288031)

Interestingly, LP: #1288031 includes a comment (#9) saying that this
Ubuntu/Debian patch was no longer needed due to upstream Bash fixes, but
it's not clear to me whether the same is true for the "unescaped ~*"
bug.
  https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031


Meanwhile, Ubuntu has just released new versions of the bash-completion
package, with a patch (15-add_backslash_for_tilde.patch) to the
00-fix_quote_readline_by_ref.patch file to fix the Un-escaped "~*" bug;
see:
  https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1390061

Nathan

Bug#510589: icedove: segmentation fault

[Jamesc Netvalue]

Dear Maintainer,

After the recent security update icedove segmentation faults randomly and
often.  Today I was running icedove in safe-mode to try avoid it seg
faulting.  This is a "me too" report.

$ icedove --safe-mode
(icedove:12075): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data:
assertion 'targets != NULL' failed
(icedove:12075): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data:
assertion 'targets != NULL' failed
(icedove:12075): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data:
assertion 'targets != NULL' failed
Segmentation fault


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

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

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u4
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpixman-1-0 0.32.6-3
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.1.0-1~deb8u1

Versions of packages icedove suggests:
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.12.1+dfsg-19+deb8u2

-- no debconf information

Bug#828706: vagrant: autopkgtest fails if dependency has newer upstream version

[Jeremy Bicha]

Source: vagrant
Version: 1.8.1+dfsg-2

A new version of ruby-nokogiri (1.6.8) was released June 6. The
version of ruby-nokogiri packaged in Debian is 1.6.7.2-3.

Immediately, this caused vagrant's autopkgtests to begin failing:

"An error occurred while installing nokogiri (1.6.8), and Bundler
cannot continue."

https://ci.debian.net/packages/v/vagrant/unstable/amd64/

A test should not fail just because a dependency isn't the latest available.


Thanks,
Jeremy Bicha

Bug#825701: should osptoolkit be removed from Debian?

[Di-Shi Sun]

Hi Mattia,

We went through the list and met one issue,

dpkg-genchanges: warning: package osptoolkit-dbgsym listed in files list but
not in control info
dpkg-genchanges: warning: package libosptk4-dbgsym listed in files list but
not in control info

All others look fine. 

The updated packages have been uploaded to mentors.

BTW, we believe #555877 have been fixed in 3.4.2-1.1 by explicitly linking
external libraries.

Thanks,

Di-Shi Sun.

-Original Message-
From: 'Mattia Rizzolo' [mailto:mat...@debian.org] 
Sent: Thursday, June 23, 2016 6:47 PM
To: Di-Shi Sun
Cc: 825...@bugs.debian.org; 'Support of Transnexus'
Subject: Re: Bug#825701: should osptoolkit be removed from Debian?

On Thu, Jun 23, 2016 at 05:26:12PM +0800, Di-Shi Sun wrote:
> Sorry for the delay. We just fixed the upload issues on 
> mentors.debian.net. You can find it at 
> https://mentors.debian.net/package/osptoolkit
> 
> There are several thing about the warning messages on 
> mentors.debian.net 1. no-upstream-changelog. The upstream source package
includes RELNOTES.txt for its changes. I am not sure if we must put all the
change info into debian/changelog.

https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs
There is a dh_installchangelog utility, you should use it to install
RELNOTES.txt
*but* that file clearly has not been updated in a long time, so it's
probably more harmful than anything to ship it, so ignore that message.

> 3. A watch file is present but doesn't work. We tested the watch file on
our boxes. I do not know why mentors.debian.net thought it does not work.

Because mentors.d.n runs on wheezy, and there uscan is not newer enough to
work with version=4 files.

> BTW, we did not see any of these warning when we run lintian on our boxes.

Depends on level of "pendicness" you ask lintian.

> Please let us know if there is anything should be modified.

I'd like to ask you a few things, following newer best practise in debian
packaging:

* drop the -dbg package: nowdays debhelper automatically builds -dbgsym
  packages (though they are not installed in the main debian archive,
  but in a separate "debug archive")
  https://wiki.debian.org/AutomaticDebugPackages
* try dropping all the debian/*dirs files: they are usually useless, as
  debhelper tools take care of creating needed directories before
  installing files; is my personal belief that if you need such files
  thare are good chances your build system is buggy.  I tried and it
  fails to build, so I suggest you to put on your todo to make your
  build system more clever and create the needed directories.
* d/patches/test_app.c.patch: I can't think why that would be
  'Forwarded: not-needed', why can't you apply that upstream?
* please rename d/docs to d/osptoolkit.docs: d/docs is a very confusing
  file name because it makes you think that it install the docs in all
  produced binaries, while instead it only install them in the first
  package list in d/control... (I had a lot of people thinking it wrong,
  so I now advocate for renaming)
* versioned -dev packages usually bring only pain during transitions, as
  they require source changes to all reverse-dependency to change
  build-depends.  I appreciate that you don't have this problem as you
  don't have reverse-depends, but I wonder if you can take this occasion
  to rename the -dev package to just 'libosptk-dev'.  BTW, in both cases
  you should add a Conflicts: against the old -dev package, as both ship
  the same files, and so can't be installed toghether (I prefer a
  Conflicts (or Conflicts+Replace) in this occasion, rather than a
  Breaks+Replaces, since you should prefer the removal of the old binary
  before installing this).  See
  https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
  (and §7.6).
* do you think you can close #555877 too?
* in d/rules:
  + that `ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))`... is not
 needed: with a new enough dpkg and if you obeys dpkg-buildflags
 (which you do) is obsolete
  + can you convert your d/rules to use the dh sequencer instead?
  + please just remove the .la file.  I'm sure it's not used inside
debian.  Do you instead have any use for it?  (as a OS developer I
dislike static libraries by a great deal)
* d/*.install: they are all useless: thanks to that different sequence
  of `make install` in d/rules files are already installed in their
  final location, so dh_install (the program that reads those files)
  has nothing to do.  So, they can go away.

I appreciate that's quite some list of things, so I've done some of them,
attached a debdiff.


Please ping me as soon as you have an updated package, following my
suggestions :)

--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA 

Bug#828705: Linux kernel update creates redundant symlinks

[Evgeny Kapun]

Package: linux-image-4.6.0-1-amd64
Version: 4.6.2-2

When updating the package linux-image-4.6.0-1-amd64 from version 4.6.2-1 to 
version 4.6.2-2, post-install script printed this:

I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.6.0-1-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.6.0-1-amd64

After that, both /{vmlinuz,initrd.img} and /{vmlinuz,initrd.img}.old point to 
the same kernel version, 4.6.0-1-amd64. Aren't these .old symlinks supposed to 
point to the previous version?

Bug#828640: conky: Segmentation fault at start (conky 10.10.2)

[Vincent Cheng]

Control: tags -1 + moreinfo unreproducible

Hi,

On Sun, Jun 26, 2016 at 9:03 AM, markus  wrote:
> Package: conky
> Version: 1.10.2-1
> Severity: important
>
> Dear Maintainer,
>
> when I start conky, I imediately get a segmentation fault error.
> - standard configuration, nothing changed
>
> ___
>
> $conky --version
> conky 1.10.2 compiled Wed May  4 00:32:04 UTC 2016 for Linux 
> 3.16.0-4-powerpc64
> ppc

This must be the first powerpc-specific bug report I've ever received. :)

Please get a backtrace with gdb (see [1] for step by step instructions
if you're not familiar with the process) and report this bug upstream
at [2]. Thanks!

Regards,
Vincent

[1] https://wiki.debian.org/HowToGetABacktrace
[2] https://github.com/brndnmtthws/conky/issues/new

Bug#828704: Issue in Bash; causing failures in Sparc64 and S/390x Chroots

[Jeffrey Walton]

Package: bash
Source: bash (4.3-14)
Version: 4.3-14+b1

This is a crummy bug report. I've been having some trouble with Bash
in some QEMU/Chroot environments. I'm guessing the Bash maintainers
don't know about the issues.

I use quite a few Debian Ports (https://www.debian.org/ports/) because
Debian carries our package, and our package maintainer, László
Böszörményi, manages to find issues despite our sincerest efforts.



First issue: in a Sparc64 QEMU/Chroot guest, the lightweight VM fails
to start. The corresponding Debian bug report is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828041:

# chroot debian-sparc64
*** longjmp causes uninitialized stack frame ***: /bin/bash terminated
Unhandled trap: 0x34
pc: 00163860  npc: 00163864
%g0-3:  8004  
%g4-7: 0002 0008 476574434641 004000ee2700
...
%f48:     
%f56:  0001   
pstate: 0092 ccr: 44 (icc: -Z-- xcc: -Z--) asi: f0 tl: 0 pil: 0
cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 2
fsr:  y:  fprs: 0004



Second issue: in a S/390x QEMU/Chroot guest, bash crashes when
attempting to run Emacs self tests (Emacs 24.5 built from sources):

# make
...

make[2]: Leaving directory '/root/emacs-24.5/lisp'
if test "no" = "yes"; then \
  rm -f bootstrap-emacs; \
  ln temacs bootstrap-emacs; \
else \
  ./temacs --batch --load loadup bootstrap || exit 1; \
  test "X" = X ||  -zex emacs; \
  mv -f emacs bootstrap-emacs; \
fi
Loading loadup.el (source)...
Using load-path (/root/emacs-24.5/lisp
/root/emacs-24.5/lisp/emacs-lisp /root/emacs-24.5/lisp/language
/root/emacs-24.5/lisp/international /root/emacs-24.5/lisp/textmodes
/root/emacs-24.5/lisp/vc)
Loading emacs-lisp/byte-run...
/bin/bash: line 7: 17256 Segmentation fault  ./temacs --batch
--load loadup bootstrap
Makefile:815: recipe for target 'bootstrap-emacs' failed
make[1]: *** [bootstrap-emacs] Error 1
make[1]: Leaving directory '/root/emacs-24.5/src'
Makefile:387: recipe for target 'src' failed
make: *** [src] Error 2



The following was taken from the S/390x machine:

# /bin/bash --version
GNU bash, version 4.3.46(1)-release (s390x-ibm-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.

# apt-cache show bash
Package: bash
Essential: yes
Status: install ok installed
Priority: required
Section: shells
Installed-Size: 5283
Maintainer: Matthias Klose 
Architecture: s390x
Multi-Arch: foreign
Version: 4.3-15
Replaces: bash-completion (<< 20060301-0), bash-doc (<= 2.05-1)
Depends: base-files (>= 2.1.12), debianutils (>= 2.15)
Pre-Depends: dash (>= 0.5.5.1-2.2), libc6 (>= 2.15), libncurses5 (>=
6), libtinfo5 (>= 6)
Recommends: bash-completion (>= 20060301-0)
Suggests: bash-doc
Conflicts: bash-completion (<< 20060301-0)
Conffiles:
 /etc/bash.bashrc 87b895cef45b8090d628a1d9a0f4bfb8
 /etc/skel/.bash_logout 22bfb8c1dd94b5f3813a2b25da67463f
 /etc/skel/.bashrc ee35a240758f374832e809ae0ea4883a
 /etc/skel/.profile 905f748ceda81747600e9a593b42f3e4
Description-en: GNU Bourne Again SHell
 Bash is an sh-compatible command language interpreter that executes
 commands read from the standard input or from a file.  Bash also
 incorporates useful features from the Korn and C shells (ksh and csh).
 .
 Bash is ultimately intended to be a conformant implementation of the
 IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2).
 .
 The Programmable Completion Code, by Ian Macdonald, is now found in
 the bash-completion package.
Description-md5: 3522aa7b4374048d6450e348a5bb45d9
Homepage: http://tiswww.case.edu/php/chet/bash/bashtop.html
Package: bash
Source: bash (4.3-14)
Version: 4.3-14+b1
Essential: yes
Installed-Size: 5280
Maintainer: Matthias Klose 
Architecture: s390x
Replaces: bash-completion (<< 20060301-0), bash-doc (<= 2.05-1)
Depends: base-files (>= 2.1.12), debianutils (>= 2.15)
Pre-Depends: dash (>= 0.5.5.1-2.2), libc6 (>= 2.15), libncurses5 (>=
6), libtinfo5 (>= 6)
Recommends: bash-completion (>= 20060301-0)
Suggests: bash-doc
Conflicts: bash-completion (<< 20060301-0)
Description-en: GNU Bourne Again SHell
 Bash is an sh-compatible command language interpreter that executes
 commands read from the standard input or from a file.  Bash also
 incorporates useful features from the Korn and C shells (ksh and csh).
 .
 Bash is ultimately intended to be a conformant implementation of the
 IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2).
 .
 The Programmable Completion Code, by Ian Macdonald, is now found in
 the bash-completion package.
Description-md5: 3522aa7b4374048d6450e348a5bb45d9
Multi-Arch: foreign
Homepage: 

Bug#828703: git-buildpackage: Inconsistency in the “Configuration files” section of the gbp-buildpackage(1) manpage

[Nicolas Braud-Santoni]

Package: git-buildpackage
Version: 0.7.5
Severity: minor

Dear Maintainer,

In the gbp-buildpackage(1) manpage, I can read the following:

> All  options  in the config files must be specified without the 'git-'
> prefix. So e.g. --git-debian-branch=debian/sid becomes in gbp.conf:
> 
>   [buildpackage]
>   debian-dir  = debian/sid

It seems the “debian-dir” option should be “debian-branch”.


Best,

  nicoo


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

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

Versions of packages git-buildpackage depends on:
ii  devscripts2.16.5
ii  git   1:2.8.1-1
ii  man-db2.7.5-1
ii  python-dateutil   2.4.2-1
ii  python-pkg-resources  20.10.1-1.1
ii  python-six1.10.0-3
pn  python:any

Versions of packages git-buildpackage recommends:
ii  cowbuilder   0.80
ii  pbuilder 0.224
ii  pristine-tar 1.34
ii  python-requests  2.10.0-2

Versions of packages git-buildpackage suggests:
pn  python-notify  
ii  sudo   1.8.15-1.1
ii  unzip  6.0-20

-- no debconf information

Bug#828171: [Reportbug-maint] Bug#828171: /usr/bin/querybts: IndexError race condition soon after filing a (first) bug against a package

[Daniel Shahaf]

Sandro Tosi wrote on Sat, Jun 25, 2016 at 18:50:44 +0100:
> > Version: 6.6.3
> 
> please try to replicate it with 6.6.6, available in testing/unstable
> as well as jessie-backports

How would I do that?  I cannot replicate the entire "package P has no
bugs, submit a bug against P, run 'querybts -s $P'" situation without
setting up my own debbugs instance.

I did run 'querybts -s x42-plugins' again — both 6.6.3 and 6.6.6 now
give the same results as in Step (6) — but there are two possible
explanations to this: either (a) v6.6.6 doesn't have the bug, or (b)
both v6.6.3 and v6.6.6 have the bug and the bug involves a race
condition.

Cheers,

Daniel

Bug#828702: Emacs bloat; emacs-nox includes windowing components

[Jeffrey Walton]

Package: emacs-nox
Version: 46.1

The emacs-nox installation appears to be suffering from bloat. Its
over 125 MB even though a minimum build is usually less than 25 MB.

The 25 MB minimum build can be achieved with the following Configure using 24.5:

./configure --with-xml2 --with-zlib --without-x --without-sound --without-xpm \
  --without-jpeg --without-tiff --without-gif --without-png --without-rsvg \
  --without-imagemagick --without-xft --without-libotf --without-m17n-flt \
  --without-xaw3d --without-toolkit-scroll-bars --without-gpm --without-dbus \
  --without-gconf --without-gsettings

-

# apt-get install emacs-nox
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  dbus emacs24-bin-common emacs24-common emacs24-el emacs24-nox emacsen-common
  libasound2 libasound2-data libcap-ng0 libdbus-1-3 libglib2.0-0
  libglib2.0-data libgpm2 liblockfile-bin liblockfile1 libxml2 sgml-base
  shared-mime-info xdg-user-dirs xml-core
Suggested packages:
  dbus-user-session | dbus-x11 emacs24-common-non-dfsg ncurses-term
  libasound2-plugins alsa-utils gpm sgml-base-doc debhelper
The following NEW packages will be installed:
  dbus emacs-nox emacs24-bin-common emacs24-common emacs24-el emacs24-nox
  emacsen-common libasound2 libasound2-data libcap-ng0 libdbus-1-3
  libglib2.0-0 libglib2.0-data libgpm2 liblockfile-bin liblockfile1 libxml2
  sgml-base shared-mime-info xdg-user-dirs xml-core
0 upgraded, 21 newly installed, 0 to remove and 0 not upgraded.
Need to get 39.6 MB of archives.
After this operation, 125 MB of additional disk space will be used.
Do you want to continue? [Y/n]

-

# apt-cache show emacs24-nox
Package: emacs24-nox
Source: emacs24 (24.5+1-6)
Version: 24.5+1-6+b2
Installed-Size: 16384
Maintainer: Rob Browning 
Architecture: s390x
Replaces: emacs24, emacs24-lucid
Provides: editor, emacs24, emacsen, info-browser, mail-reader, news-reader
Depends: emacs24-bin-common (= 24.5+1-6+b2), libacl1 (>= 2.2.51-8),
libasound2 (>= 1.0.16), libc6 (>= 2.16), libdbus-1-3 (>= 1.9.14),
libglib2.0-0 (>= 2.18.0), libgnutls30 (>= 3.4.2), libgpm2 (>= 1.20.4),
libselinux1 (>= 1.32), libtinfo5 (>= 6), libxml2 (>= 2.7.4), zlib1g
(>= 1:1.1.4)
Suggests: emacs24-common-non-dfsg
Conflicts: emacs24, emacs24-lucid
Description-en: GNU Emacs editor (without GUI support)
 GNU Emacs is the extensible self-documenting text editor.  This
 package contains a version of Emacs compiled without support for X,
 and provides only a text terminal interface.
Description-md5: d7627aff9867f2ba95f2b9dcfc399d6a
Homepage: http://www.gnu.org/software/emacs/
Section: editors
Priority: optional
Filename: pool/main/e/emacs24/emacs24-nox_24.5+1-6+b2_s390x.deb
Size: 3099814
MD5sum: a71d7536020950e53d01c780527f0b3e
SHA1: 69d6880851b4c6624d2930217336a5b971ba874e
SHA256: a0d5da36853bec5e455f702cc8d44d603e4b396f55ff9c4e03656fa03d50c4f8

-

# apt-cache show emacs-nox
Package: emacs-nox
Source: emacs-defaults
Version: 46.1
Installed-Size: 25
Maintainer: Rob Browning 
Architecture: all
Depends: emacs24-nox
Description-en: GNU Emacs editor (metapackage, without X support)
 GNU Emacs is the extensible self-documenting text editor.
 This is a metapackage that will always depend on the latest
 recommended Emacs release, without support for X.
Description-md5: 948b6cf34c11bb622035c56f70f707e2
Section: editors
Priority: optional
Filename: pool/main/e/emacs-defaults/emacs-nox_46.1_all.deb
Size: 1652
MD5sum: 6373e38178b404a66b30cb3efb9ee6b8
SHA1: d938c9bcdb3332a54cfbf7acc4981a209680ca4f
SHA256: 80e14e492f704c5c24e9e80b4624dc472b9864edc6cc1b202a12ec2ff5613176

Bug#827577: cronometer: cannot select text in cronometer

[koanhead]

On 06/18/2016 03:04 PM, tony mancill wrote:
> On 06/17/2016 07:23 PM, koanhead wrote:
>> Package: cronometer
>> Version: 0.9.9+dfsg-1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> When attempting to select text in Recipe Editor, Nutrients tab, General tab,
>> all the data in the table is 'grayed out' and not selectable. This makes it
>> impossible to copy-paste this data and share it.
> 
> Hi,
> 
> Thank you for the bug report.  Is this new behavior, or are you
> reporting a general (upstream) bug with the software?

I'm not sure, in that I've never tried it before so I can't say
definitively that it's new behavior in the program. It's certainly new
behavior *to me*, but that doesn't mean much.

> 
> Perhaps someone will fork the project and continue development on the
> standalone client.

Unfortunately I don't know Java, so that person is unlikely to be me-
but since Cronometer stores its data in XML I might be able to work
something up either to import that data into another program or make
another program that uses the data.

Bug#828701: libfm4: Crashes (SIGABRT) on invalid paths

[Alf Gaida]

Package: libfm4
Version: 1.2.4-1
Severity: important
Tags: patch

Dear Maintainer,
pcmanfm and pcmanfm-qt crashes when one try to navigate to an non existent 
folder.
Steps to reproduce and discussion one will find here: 
https://github.com/lxde/pcmanfm-qt/issues/368

Patch is attached.

Cheers Alf

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

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

Versions of packages libfm4 depends on:
ii  libc6 2.22-12
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libexif12 0.6.21-2
ii  libfm-data1.2.4-1
ii  libglib2.0-0  2.48.1-1
ii  libmenu-cache31.0.1-1
ii  lxmenu-data   0.1.5-1

Versions of packages libfm4 recommends:
ii  libfm-modules  1.2.4-1

libfm4 suggests no packages.

-- no debconf information
diff --git a/debian/rules b/debian/rules
index 928848f..b899c45 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,13 +2,14 @@
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
+export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
 	dh ${@} --parallel --with autoreconf
 
 override_dh_auto_configure:
-	dh_auto_configure -- --enable-debug --enable-gtk-doc --enable-udisks --disable-silent-rules
+	dh_auto_configure -- --enable-gtk-doc --enable-udisks
 
 override_dh_auto_install:
 	dh_auto_install

Bug#828700: RFS: twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

On Sun, Jun 26, 2016 at 07:28:12PM -0400, Peter Colberg wrote:
> It builds these binary packages:

twinkle - Voice over Internet Protocol (VoIP) SIP Phone (GUI)
twinkle-console - Voice over Internet Protocol (VoIP) SIP Phone (console)
twinkle-common - Voice over Internet Protocol (VoIP) SIP Phone (common files)


signature.asc
Description: PGP signature

Bug#805711: Keyboard unresponsive

[Sean Whitton]

Dear Amir,

What exactly do you mean by "unresponsive"?  And do you login twice to
the same login dialogue?

In my case, I have to login twice because I have xscreensaver installed
and haven't yet figured out how to disable light-locker.  More
significantly, after unlocking twice, X11 ignores keyboard input.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#828700: RFS: twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "twinkle":

  git clone https://anonscm.debian.org/git/pkg-voip/twinkle.git
  cd twinkle && pristine-tar checkout 
../twinkle_1.9.0+git20160520.0.be8b8df+dfsg.orig.tar.xz

For verification, these are the current branch heads:

  git show-ref --heads
  40d6c98b0a34ca0b331e1e9a05351b66a3d09df4 refs/heads/master
  9b3e492fbc6e923b7fddd9a320abfc8eba57eb03 refs/heads/pristine-tar
  ef9654f270da62ba87a112e2a9724ca3fe5466a4 refs/heads/upstream

It builds these binary packages:

  twinkle - Voice over Internet Protocol (VoIP) SIP Phone

Changes since the last upload:

twinkle (1:1.9.0+git20160520.0.be8b8df+dfsg-1) unstable; urgency=medium

  * New upstream snapshot
  * Rewrite Description in a succinct style
  * Move twinkle-console to separate package
  * Install upstream man page
  * Add debian/gbp.conf for pristine-tar

 -- Peter Colberg   Sun, 26 Jun 2016 19:13:17 -0400

If you decide to sponsor this package, please upload the source only
so that buildd logs are available for all archs. I will push a release
tag to the git repository after the package has been uploaded.

Regards,
Peter


signature.asc
Description: PGP signature

Bug#828211: e2fsprogs: resize2fs dumps reading inodes

[Theodore Ts'o]

On Sun, Jun 26, 2016 at 07:55:39AM +0200, Ulrich Möhrke wrote:
> Package: e2fsprogs
> Version: 1.43.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> call of resize2fs -p /dev/sda6 162336768K as root to reduce size of file 
> system by 4G 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
> 
> I've got german output:
> resize2fs 1.43.1 (08-Jun-2016)
> Die Größe des Dateisystems auf /dev/sda6 wird auf 40584192 (4k) Blöcke 
> geändert.
> Start von Durchgang 3 (max = 1271)
> Die Inode-Tabelle wird 
> gelesenXXSpeicherzugriffsfehler
> 
> should be something like the following in english:
> resize2fs 1.43.1 (08-Jun-2016)
> The size of the file system at /dev/sda6 will be changed to 40584192 (4k) 
> blocks.
> Start of run/track 3 (max = 1271)
> Reading inode table XXsegmentation fault

OK, first of all, please run fsck on the /dev/sda6 to make sure it's
consistent.  Please save the output of fsck and attach it to the bug.

Next, run dumpe2fs on the output, and attach it to the bug as well.

What I would suggest doing next is to use e2image -r to create a raw
image dump of the file system metadata blocks, and then try running
resize2fs on the raw image dump.  If it crases, then we've got a
reproduction case, and this would be most helpful.  Ideally I'd like
to get a compressed copy of the raw image file.  If you don't want me
seeing the filenames, you can create the image dump using e2image -rs,
which will scramble the file names.  (Either way, this omits the data
blocks, both for size and privacy reasons.)

If you don't want to send me the image file, it would be great if you
could enable core dumps, and get a stack trace.  Or you can install
the dbgsym package and then run resize2fs under gdb, and get the stack
trace that way.

- Ted

Bug#819617: bcftools i386 - update on compiling with -msse2

[Afif Elghraoui]

For the record here, building with -msse2 doesn't help on i386 (build
log attached). According to upstream discussion, the problem has to do
with NaNs.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


bcftools_1.3.1-2_i386.build.gz
Description: application/gzip

Bug#828699: libunbound2: please compile against libnettle

[brian m. carlson]

Package: libunbound2
Version: 1.5.9-1
Severity: wishlist

Currently, GnuTLS cannot be compiled with DANE support as that would
require linking against libunbound2; that is unsuitable since
libunbound2 links against OpenSSL.  As of unbound 1.5.7, compiling
against libnettle is supported for libunbound2.  Doing so would allow
GnuTLS (and other GPL-licensed software) to make use of libunbound2.
Could you please do so?

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

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

Versions of packages libunbound2 depends on:
ii  libc62.22-12
ii  libssl1.0.2  1.0.2h-1

libunbound2 recommends no packages.

libunbound2 suggests no packages.

-- no debconf information

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#828614: yara: FTBFS with openssl 1.1.0

[Hilko Bengen]

control: tag -1 moreinfo

Hi Kurt,

I was able to get the yara build fixed by applying this simple patch:

-  const char* sig_alg = OBJ_nid2ln(OBJ_obj2nid(cert->sig_alg->algorithm));
+  const char* sig_alg = OBJ_nid2ln(X509_get_signature_nid(cert));

However, since I don't really know a lot about OpenSSL's internals, I'm
not sure if the fix is actually correct. I have found neither the
OpenSSL manpages nor upstream's wiki page about the API changes to be
particularly helpful.

A document describing to Debian maintainers how they need to change
specific struct accesses would be very helpful.

Cheers,
-Hilko

Bug#824451: libarchive: FTBFS on kFreeBSD: tar/test/test_option_older_than.c:70: File should exist

[Petter Reinholdtsen]

[Steven Chamberlain]
> It may take some time to produce a test case for upstream FreeBSD, fix
> it, and get our buildds running a fixed kernel.

The code in 
http://anonscm.debian.org/cgit/collab-maint/libarchive.git/tree/tar/test/test_option_older_than.c
 >
combined with the functions in main.c should give you the test code.

It is simply open/write/close/access called in sequence.  I could
reproduce the problem on falla.debian.org.

--
Happy hacking
Petter Reinholdtsen

Bug#828698: mate-tweak: make compton optional

[Denis Danilov]

Package: mate-tweak
Version: 16.10.2-1
Severity: normal

I think that the compton can be moved from "Depends" to "Suggests".
Please consired this option.

Best
Denis

Bug#828457: nodejs: FTBFS with openssl 1.1.0

[Jérémy Lal]

2016-06-26 20:24 GMT+02:00 Kurt Roeckx :

> On Sun, Jun 26, 2016 at 06:53:42PM +0200, Jérémy Lal wrote:
> >
> > I'm on it, and after a couple things i could solve, i need a "gentle
> push"
> > to continue solving these:
>
> They all seem to be about the same problem.  The structure has
> become opaque and you can't have it directly on the stack or in an
> other struct.  Instead you need to allocate it with TYPE_new(),
> which will give you a pointer back.  This will ensure that the
> allocated size is the correct one, since we might change the
> structure to add new fields and thing like that.  When you do
> things like sizeof(TYPE) you would get the size at compile time
> which might be a different one than the one at runtime.
>

These changes seem quite easy and doable for a novice like me.
However the whole part about BIO seems to be much harder to fix:
https://github.com/nodejs/node/blob/v4.x/src/node_crypto_bio.h
https://github.com/nodejs/node/blob/v4.x/src/node_crypto_bio.cc

Sadly, upstream is not considering moving soon to openssl 1.1.
https://github.com/nodejs/node/issues/4270

Jérémy.

Bug#828697: lxqt-powermanagement: lxqt-powermanagement doesn't find battery due to missing dependency

[Martin Küttler]

Package: lxqt-powermanagement
Version: 0.10.0-3
Severity: normal

Hi,

on a new installation of lxqt on debian testing lxqt-powermanagement
complains "LXQt could not find data about any battery - monitoring
disabled" whenever I want to enable battery monitoring.  It uses
libkf5solid5 to detect hardware.  Trying to investigate the issue I
installed libkf5solid-bin, which recommands upower.  With the later
installed, solid finds my battery and lxqt-powermanagement works as
expected.  I think either libkf5solid5 or lxqt-powermanagement should
also recommand upower, so that battery detection works by default.

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

Kernel: Linux 4.5.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 lxqt-powermanagement depends on:
ii  libc6   2.22-11
ii  libkf5solid55.23.0-1
ii  liblxqt0 [lxqt-abi-0-10-0]  0.10.0-5
ii  libqt5core5a5.6.1+dfsg-2
ii  libqt5dbus5 5.6.1+dfsg-2
ii  libqt5gui5  5.6.1+dfsg-2
ii  libqt5svg5  5.6.1-2
ii  libqt5widgets5  5.6.1+dfsg-2
ii  libqt5xdg1  1.3.0-3+b1
ii  libstdc++6  6.1.1-4
ii  libxcb-dpms01.11.1-1
ii  libxcb-screensaver0 1.11.1-1
ii  libxcb1 1.11.1-1

lxqt-powermanagement recommends no packages.

lxqt-powermanagement suggests no packages.

-- no debconf information

Bug#828158: Mate 1.14.1 (Gtk 3.20.6-1) no colors in Home folder

[John Paul Adrian Glaubitz]

On 06/26/2016 04:33 PM, Nitko Bitan wrote:
> This is broken for caja GTK3.
> And this is the wrong package and already reported.

See and that's why you should always do some research *before* reporting a bug.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#828636: Pending fixes for bugs in the libembperl-perl package

[pkg-perl-maintainers]

tag 828636 + pending
thanks

Some bugs in the libembperl-perl package are closed in revision
3dcf43540b36ba5036c6eb6b05e23dd936515dfc in branch 'master' by Axel
Beckert

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

Commit message:

Use "find" to ensure case-sensitivity in [a-z] wildcards

Properly closes: #828636

Bug#828696: NMU diff for sbsigntool 0.6-3.1

[Ben Hutchings]

Package: sbsigntool
Version: 0.6-3
Severity: normal
Tags: patch

Here's the diff for version 0.6-3.1, which fixed the two open bugs
and some other minor issues I found along the way.

I tested building the new version on arm64 on armhf.  It failed on
armhf, but this appears to be a toolchain issue: the linker reported
various symbols in libc as undefined, but only when linking sbkeysync
and not any of the other programs.  This build failure won't prevent
propagation to testing, and I assume that it will be resolved later
by an update to the toolchain.

The test suite assumes an x86 multilib compiler, so I stopped it
running on anything but amd64, i386 and kfreebsd-amd64.  I did some
basic manual tests of sbsign, sbattach and sbverify on arm64 and
armhf, successfully.

Ben.

---
diff -Nru sbsigntool-0.6/debian/changelog sbsigntool-0.6/debian/changelog
--- sbsigntool-0.6/debian/changelog 2016-04-20 09:34:30.0 +0200
+++ sbsigntool-0.6/debian/changelog 2016-06-26 23:39:15.0 +0200
@@ -1,3 +1,14 @@
+sbsigntool (0.6-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload with approval of maintainer
+  * Limit build-dependency on gcc-multilib to the architectures where it
+is available, and disable tests where it is not
+  * Enable building on arm64 and armhf (Closes: #821144)
+  * Update OpenSSL API usage to support OpenSSL 1.1 (Closes: #828539)
+  * Remove incorrect Vcs-Bzr field
+
+ -- Ben Hutchings   Sun, 26 Jun 2016 23:39:15 +0200
+
 sbsigntool (0.6-3) unstable; urgency=medium
 
   * Add sbsign_check_write_return.patch: check return when writing
diff -Nru sbsigntool-0.6/debian/control sbsigntool-0.6/debian/control
--- sbsigntool-0.6/debian/control   2016-04-19 08:06:55.0 +0200
+++ sbsigntool-0.6/debian/control   2016-06-26 22:45:44.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Pierre Chifflier 
 Build-Depends: debhelper (>= 9.0.0),
   dh-autoreconf,
-  gcc-multilib,
+  gcc-multilib [amd64 i386 kfreebsd-amd64],
   binutils-dev,
   libssl-dev,
   openssl,
@@ -14,13 +14,11 @@
   help2man,
   gnu-efi
 Standards-Version: 3.9.7
-Vcs-Bzr: lp:ubuntu/sbsigntool
 
 Package: sbsigntool
-Architecture: any-amd64 any-i386
+Architecture: any-amd64 any-i386 arm64 armhf
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Multi-Arch: foreign
 Description: Tools to manipulate signatures on UEFI binaries and drivers
  This package installs tools which can cryptographically sign EFI binaries and
  drivers.
- Currently it can only sign x86_64 EFI binaries and drivers.
diff -Nru sbsigntool-0.6/debian/patches/fix-efi-arch-detection.patch 
sbsigntool-0.6/debian/patches/fix-efi-arch-detection.patch
--- sbsigntool-0.6/debian/patches/fix-efi-arch-detection.patch  1970-01-01 
02:00:00.0 +0200
+++ sbsigntool-0.6/debian/patches/fix-efi-arch-detection.patch  2016-06-26 
22:59:28.0 +0200
@@ -0,0 +1,19 @@
+Author: Ben Hutchings 
+Date: Sun, 26 Jun 2016 22:56:18 +0200
+Description: Fix EFI architecture detection
+ Currently we use 'uname -m', which tells us the build architecture.
+ In a cross-building environment or compat environment, this is not the
+ same as the host architecture.  Use  AC_CANONICAL_HOST instead.
+
+--- a/configure.ac
 b/configure.ac
+@@ -64,7 +64,8 @@ PKG_CHECK_MODULES(uuid, uuid,
+ AC_MSG_ERROR([libuuid (from the uuid package) is required]))
+ 
+ dnl gnu-efi headers require extra include dirs
+-EFI_ARCH=$(uname -m)
++AC_CANONICAL_HOST
++EFI_ARCH=$host_cpu
+ case $EFI_ARCH in
+   i*86)
+   EFI_ARCH="ia32"
diff -Nru sbsigntool-0.6/debian/patches/series 
sbsigntool-0.6/debian/patches/series
--- sbsigntool-0.6/debian/patches/series2016-04-18 22:56:08.0 
+0200
+++ sbsigntool-0.6/debian/patches/series2016-06-26 22:55:38.0 
+0200
@@ -11,3 +11,5 @@
 0001-Support-openssl-1.0.2b-and-above.patch
 sbverify_clear_out_cert_content.patch
 sbsign_check_write_return.patch
+update-openssl-api-usage-to-support-openssl-1.1.patch
+fix-efi-arch-detection.patch
diff -Nru 
sbsigntool-0.6/debian/patches/update-openssl-api-usage-to-support-openssl-1.1.patch
 
sbsigntool-0.6/debian/patches/update-openssl-api-usage-to-support-openssl-1.1.patch
--- 
sbsigntool-0.6/debian/patches/update-openssl-api-usage-to-support-openssl-1.1.patch
 1970-01-01 02:00:00.0 +0200
+++ 
sbsigntool-0.6/debian/patches/update-openssl-api-usage-to-support-openssl-1.1.patch
 2016-06-26 22:20:59.0 +0200
@@ -0,0 +1,143 @@
+Author: Ben Hutchings 
+Date: Sun, 26 Jun 2016 22:04:29 +0200
+Description: Update OpenSSL API usage to support OpenSSL 1.1
+ Most structure definitions in OpenSSL are now opaque and we must call
+ the appropriate accessor functions to get information from them.
+ Not all the accessors are available in older versions, so define the
+ missing accessors as macros.
+ .
+ The X509_retrieve_match() function is no longer usable, as we cannot
+ initialise 

Bug#734237: btrfs-tools: btrfs lockup with 3.12 RT kernel

[Nicholas D Steeves]

The reason I ask is at the time of linux-3.12, there were a number of
bugs caused by the interaction of btrfs and the RT patches.  Some of
them were btrfs, some of them the RT patches fault, and from what I've
read it's better now, but there are still probably issues.

Cheers,
Nicholas

Bug#828695: xbomb interacts badly with i3

[Henrik Christian Grove]

Package: xbomb
Version: 2.2b-1
Severity: normal

This is without any xbomb specific configuration of i3.

When I start i3 on a desktop where only my i3bar is present, it starts
in a window that takes up the entire desktop (that is as i3 is supposed to
make it).

xbomb starts in easy/squares mode but the individual fields of the
playing board are scaled so badly that I can only see the first 5½
row, that makes the game impossible. Changing to medium/squares I can
see the first 11 rows (and a tiny fraction of the 12th), in
hard/squares I can actually see the entire board. Changing game type
just leaves a white area where the menu was (after changing desktops =
redrawing windows) the entire playing area is white, and changing
level doesn't change that, but it is remembered if I change back to
squares.

When i3 splits the desktop horisontally between xbomb and another
window, the hexagons and triangles mode still doesn't work, but
easy/squares is scaled better, I can see all 8 rows and 7½ columns
(the window is wide enough that the rest of the eight column could
have been there, but it's cut. Similarily medium/squares is scaled so
that the 16'th column is needlessly cut, the numbers that appear in
(some of) the squares in that column is also cut, but you can see
enough to tell them apart. In hard/squares only the first 20 columns
are visible.

Other configurations of additional windows and thereby other sizes for
the xbomb window is possible, but I don't see any value in testing
more.

It doesn't seem to make a difference whether I make the window
floating after starting the program, or by putting 'for_window
[class="XBomb"] floating enable' in i3's config. 

When trying to resize the window (in floating mode, the only option is
using the keybindings) the window size doesn't change, probably
because xbomb refuses the new size (that is probably the same issue
as reported with ratpoison in #456031). It's possible that defining
other keybindings to resize the window in both directions
simultaneously and other increments might give other results, but that
seems like a poor strategy (I can't define keybindings for every
program that might need special behaviour).

At first, when xbomb starts in easy/squares, everything looks good,
and the game is playable. Changing to medium/squares, the window
becomes significantly smaller (not what is expected), it becomes so
narrow that the "Hi-Scores" button is cut with the first column (or
two) of the second "s" visible, and the "Quit" button is not in the
window. If I start playing, the numbers that appear in the squares are
higher than the squares giving a rather confusing look, but the game
is playable. Changing back to easy/squares, the window does not change
size, but the smaller number of squares means everything looks fine,
but the button bar is still cut, in particular the "Quit" button is
missing from view. Changing to hard/squares (it seems not to matter
whether the change was from easy or medium), the window is resized to
a wider variant to accomodate the number of squares, but the
individual squares are too small for the numbers inside (the same as
described above), changing from hard to easy, gives the window the
initial size where the "Quit" button is visible.

In hexagon iand triable modes it's much the same, except that going
from medium to easy make the window smaller than it was from the
start, and going from difficult to easy make it a larger than it was
from the start.

Going from floating to tiled mode, you can continue the game in both
hexagon and triangle modes, but the fields of the board is not scaled,
just placed with lots of space between them, and in triangle modes the
numbers appear outside the fields. Trying to go from traibles to
hexagons or vice versa in a tiled window, produces some strange
graphic effects.

-
Some conclusions:

Basically only squares modes work when the window is tiled, but
scaling is weird and means only some levels are playable.

When the window is floating, all modes work, but on medium or hard
levels scaling is very poor. 

-

I would suggest making xbomb allow any window size, with some minimums
based on game mode and the width of all the buttons. And then just
scale the area that is actually used for the playing field. That might
results in windows with quite a lot of whitespace, but I guess it will
make it work better with window managers that try to affect the size
of the window.

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

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

Versions of packages xbomb depends on:
ii  libc6 2.19-18+deb8u4
ii  libx11-6  2:1.6.2-3
ii  libxaw7   2:1.0.12-2+b1
ii  libxt61:1.1.4-1+b1

xbomb 

Bug#828694: O: gnome-shell-extension-weather -- weather extension for GNOME Shell

[Sébastien Villemot]

Package: wnpp
Severity: normal
X-Debbugs-Cc: pkg-gnome-maintain...@lists.alioth.debian.org

I am orphaning the gnome-shell-extension-weather package.

The package description is:
 gnome-shell-extension-weather is a simple extension for displaying weather
 conditions and forecasts in GNOME Shell, featuring support for multiple
 locations, an easy way of selecting locations, and a settings panel through
 gnome-shell-extension-prefs. The weather data are fetched from Yahoo! Weather,
 and include forecasts for up to five days.

The prospective maintainer should be aware of the history of the package:

 * initially it was following the upstream version by Neroth
   (https://github.com/Neroth/gnome-shell-extension-weather), which was at that
   time fetching data from Yahoo! weather.

 * then Neroth decided to move to libgweather. But that change meant a
   significant restriction of the number of cities for which weather forecast
   was available (see #726977)

 * therefore the package started tracking another upstream, from jenslody
   (https://github.com/jenslody/gnome-shell-extension-openweather), which
   continued maintaining the Yahoo! weather version.

 * then jenslody changed the weather provided to openweathermap.org, and later
   added forecast.io as an alternative source. This is the point where we are
   now.

 * in the meantime, my understanding is that libgweather was improved, and that
   it provides forecasts for many more cities. So it may make sense to move
   back to the Neroth version of the extension, for better integration with the
   rest of Gnome. It's up to the new maintainer to assess the situation and
   make a decision.

Cheers,

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594


signature.asc
Description: PGP signature

Bug#828636: [Reproducible-builds] Bug#828636: libembperl-perl: please make the build reproducible

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> > It's actually related to the shell...
> >
> > $ touch aD bD cD dD eD AD BD
> > $ dash -c "ls *[a-z]D"
> > aD  bD  cD  dD  eD
> > $ bash -c "ls *[a-z]D"
> > aD  AD  bD  BD  cD  dD  eD
> > 
> > With bash POD.3pm also matches *[a-z]D.3pm.
> 
> Yay, thanks for that. I actually also suspected capitalization during
> matching as culprit, but suspected different locales as reason for
> that.

It's actually both:

→ env LC_ALL=C bash -c 'ls -l D[a-z]*'
-rw-r--r-- 1 abe abe 32420 May  9 18:51 Doxyfile
→ env LC_ALL=de_DE.utf-8 bash -c 'ls -l D[a-z]*'
-rwxr-xr-x 1 abe abe 13752 Mai  9 18:51 DOM.xs
-rw-r--r-- 1 abe abe 32420 Mai  9 18:51 Doxyfile
→ env LC_ALL=C dash -c 'ls -l D[a-z]*'
-rw-r--r-- 1 abe abe 32420 May  9 18:51 Doxyfile
→ env LC_ALL=de_DE.utf-8 dash -c 'ls -l D[a-z]*'
-rw-r--r-- 1 abe abe 32420 Mai  9 18:51 Doxyfile

> Will do an upload which re-includes the man page, but with proper
> matching.

My plan is to use something like "find . -name '*[a-z]D.*'" which
seems to be resistent to the above mentioned problem:

→ env LC_ALL=C find . -name '*[a-z]D.*'
./eg/web/indexD.htm
./FeaturesD.pod
→ env LC_ALL=de_DE.utf-8 find . -name '*[a-z]D.*'
./eg/web/indexD.htm
./FeaturesD.pod
→ switchsh env LC_ALL=de_DE.utf-8 find . -name '*[a-z]D.*'
./eg/web/indexD.htm
./FeaturesD.pod

None of the cases above find the POD.pm file:

→ find . -name '*[A-Z]D.*'
./Embperl/Syntax/POD.pm

And just to show what switchsh indeed works and replaces /bin/sh with
bash for a single command (via bind mount):

→ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Mar 12 10:05 /bin/sh -> dash*
→ env LC_ALL=de_DE.utf-8 sh -c 'ls -l D[a-z]*'
-rw-r--r-- 1 abe abe 32420 Mai  9 18:51 Doxyfile
→ switchsh env LC_ALL=de_DE.utf-8 sh -c 'ls -l D[a-z]*'
-rwxr-xr-x 1 abe abe 13752 Mai  9 18:51 DOM.xs
-rw-r--r-- 1 abe abe 32420 Mai  9 18:51 Doxyfile

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#828250: (no subject)

[Gianfranco Costamagna]

control: forwarded -1 https://github.com/BOINC/boinc/issues/1565
thanks



signature.asc
Description: OpenPGP digital signature

Bug#824451: libarchive: FTBFS on kFreeBSD: tar/test/test_option_older_than.c:70: File should exist

[Steven Chamberlain]

Hello!

Thanks for looking into this.  It is probably specific to UFS (not ZFS)
and maybe only when soft-updates are enabled (which is default, and I
think enabled on the buildds).  It defers writing of some metadata to
disk until the next sync or after some time has elapsed.

> [Andreas Henriksson]
> > a/ working around a really serious potential data loss bug in kfreebsd
> > b/ hiding a race in the testsuite by making it less likely to trigger

I think this is a kernel bug, but shouldn't cause data loss.

I wouldn't suggest working around it in libarchive, unless you are in a
hurry to have it built again and don't mind carying that patch.  It may
take some time to produce a test case for upstream FreeBSD, fix it, and
get our buildds running a fixed kernel.

> > Neither really sounds like we're getting the correct fix, but maybe
> > I'm wrong.
> 
> Would be useful if some kFreeBSD expert would comment on this. :)

If stat or access system calls return old data, instead of what's in a
cache to be written out, that certainly sounds like a bug.

> suspect posix require that open/write/close should cause a following
> access() to see the freshly created file, but can not quite which
> requirement that would be. :)

Sanity?  Common sense?  POLA?

It should be even quicker to return from the cache than read some
outdated metadata from disk...

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#828689: qa.debian.org: manpages not listed on missing manpage page

[Aaron Delaney]

Heya Muri,

Perhaps there was a Lintian change that isn't reflected in qa.debian,
though I'm not really
familiar with the systems involved.

I'm sure there are people on this list with a better idea though.

On 26 June 2016 at 20:26, Muri Nicanor  wrote:

> Package: qa.debian.org
> Severity: normal
>
> Dear Maintainer,
>
>* I opened the page https://qa.debian.org/man-pages.html
>* On the bottom of the page it says: "In total 0 man pages in 0
>  packages are missing at the moment. This listing was generated from
>  a Lintian report published on Sat, 25 Jun 2016."
>* I expected the number of missing manpages to be higher than 0
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (650, 'testing'), (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>

Bug#828693: Frequent Mirror Problems - httpredir

[Donald Norwood]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: httpredir
Control: submitter -1  Martin Scharm 



 Forwarded Message 
Subject: Frequent Mirror Problems
Date: Fri, 24 Jun 2016 09:01:16 +0200
From: Martin Scharm 
To: mirr...@debian.org

Hi mirrors team,

I am having a few problems with mirrors in the httpredir.debian.org
pool. If I try to install a lot of packages certain mirrors (or maybe it
is the httpredir service?) sometimes/often respond with an error after
downloading about 200 to 350 packages. The number of successful
downloads differs from time to time, but the problem occurs quite frequent.
That's especially annoying, as I'm developing a Docker image. So
downloaded packages won't be cached and I cannot (cleanly) run a second
apt-get call to get the remaining packages, which would still be a dirty
workaround.
In my case it's texlive-full that I'm trying to install. It feels like I
can run the same command a hundred times and it will fail in 85 cases. I
figured out that it helps to decrease the number of packages to be
downloaded. If I replace

> apt-get install -y texlive-full

with two apt-get calls

> apt-get install -y texlive-base
> apt-get install -y texlive-full

I've never seen any problems, which leads to my first hypothesis that
some mirrors seem to have problems with a lot of requests.

I first suspected that there is an issue with my network/dns settings,
but I'm developing that stuff from a university network and the Docker
servers do have the same issues building the image. Here you'll find
some automated builds of the image:
https://hub.docker.com/r/binfalse/texpile/builds/
As you see, two versions failed to build. Both did have a problem
downloading Debian packages:

* In case of
https://hub.docker.com/r/binfalse/texpile/builds/b8pvbtx94kn55jqundfcrwg/ the
mirror 128.31.0.66 didn't serve
http://httpredir.debian.org/debian/pool/main/g/gsfonts/gsfonts_8.11+urwcyr1.0.7~pre44-4.2_all.deb
* In case of
https://hub.docker.com/r/binfalse/texpile/builds/bjsdjeu8k6rbbcgsecxpkyz/ the
mirror 5.153.231.35 didn't deliver
http://httpredir.debian.org/debian/pool/main/t/texlive-extra/texlive-publishers-doc_2014.20141024-1_all.deb

Both links to the packages do work fine for me when accessed using a
browser or curl. However, that probably means nothing as I'm getting
redirected somewhere else.
If I try to download texlive-publishers-doc_2014.20141024-1_all.deb from
one of the failing servers above (naively assuming that it is supposed
to be in
/debian/pool/main/t/texlive-extra/texlive-publishers-doc_2014.20141024-1_all.deb)
I also get an error in my browser. Thus, my second hypothesis is that
there are simply some black sheep in the pool? And every once in a while
I unfortunately get redirected to a bad server? And the probability that
this happens just increases with the number of packages to be installed.

Or am I doing something wrong? It would be super cool if you could help
me with this issue. Please let me know if you need more information!

Thanks a lot for your efforts! You're doing a great thing! :)


Best wishes from Rostock,
Martin







signature.asc
Description: OpenPGP digital signature

Bug#826166: [Pkg-phototools-devel] Bug#826166: Bug#826166: libgphoto2-dev: location of gphoto2-config is not in PATH

[Steve M. Robbins]

On June 26, 2016 02:12:06 PM Herbert Fortes wrote:

> I tried to stop packaging these scripts months 
> ago. But maybe KDE team only was aware about
> that. I am sorry. Digikam uses pkg-config and 
> libgphoto2 has a .pc file for long time.

OK, that's great!  I'm packaging a new upstream digikam and it fails to detect 
libgphoto2 out of the box, because it is looking for gphoto2-config.  

I'll look into fixing digikam to use the pkg-config instead.

> If you need the old-style-config-script and has to
> use the old path, I can manage it for you.

No, that's not necessary.  

Thanks,
-Steve


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

Bug#804971: ser2net: Please drop versioned dependency on initscripts package

[Marc Haber]

tags #804971 confirmed pending
thanks

committed to git, thanks.

Bug#783116: (fwd) Bug#783116: ser2net: parsing portnumbers on the form "host,port" is broken [bj...@mork.no]

[Marc Haber]

tags 783116 fixed-upstream pending
thanks

new upstream version committed to git, thanks.

Greetings
Marc

Bug#803031: patch: support serial serial dev/serial/by-path names

[Marc Haber]

tags #803031 patch upstream
forwarded #803031 upstream
thanks

Hi Riko

On Mon, Oct 26, 2015 at 10:10:35AM +0200, Riku Voipio wrote:
> ser2net uses : as field separator in ser2net.conf. Udev creates by-path and
> by-id paths to identify unique serial ports. These paths are highly
> useful as ttyUSB* might end up shuffling around.

I have forwarded this upstream.

> Github seems to carry severaly useful forks of ser2net, all in having
> useful features yet not beeing very actively maintained :(
> 
> https://github.com/longshine/ser2nets
> https://github.com/Lingku/mser2net

I am aware of that. I'd like to stay with upstream though.

Greetings
Marc

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

Bug#828483: osslsigncode: FTBFS with openssl 1.1.0

[Kurt Roeckx]

On Sun, Jun 26, 2016 at 10:15:44PM +0200, Stephen Kitt wrote:
> On Sun, 26 Jun 2016 22:07:28 +0200, Stephen Kitt  wrote:
> > On Sun, 26 Jun 2016 12:23:30 +0200, Kurt Roeckx  wrote:
> > > If you have problems making things work, feel free to contact us.  
> > 
> > I've managed to fix most of the build issues, the remaining issue I'm faced
> > with is the apparent disappearance of the STACK API (DECLARE_STACK_OF())
> > etc. What should I be using instead?
> 
> Duh, it's DEFINE_STACK_OF()...

This seems to be the relevant commit:
commit 858857157290dd35145b14044ae96be9cd8eb0df
Author: Dr. Stephen Henson 
Date:   Mon Dec 28 00:04:33 2015 +

Rename DECLARE*STACK_OF to DEFINE*STACK_OF

Applications wishing to include their own stacks now just need to include

DEFINE_STACK_OF(foo)

in a header file.


I'm wondering if we should either document that somewhere or add
some backward compatible defines.


Kurt

Bug#828539: sbsigntool: FTBFS with openssl 1.1.0

[Ben Hutchings]

Control: tag -1 patch

With this patch applied, sbsigntool builds against either libssl-
dev/unstable or libssl-dev/experimental.

Ben.

-- 

Ben Hutchings
compatible: Gracefully accepts erroneous data from any source
Author: Ben Hutchings 
Date: Sun, 26 Jun 2016 22:04:29 +0200
Description: Update OpenSSL API usage to support OpenSSL 1.1
 Most structure definitions in OpenSSL are now opaque and we must call
 the appropriate accessor functions to get information from them.
 Not all the accessors are available in older versions, so define the
 missing accessors as macros.
 .
 The X509_retrieve_match() function is no longer usable, as we cannot
 initialise an X509_OBJECT ourselves.  Instead, iterate over the
 certificate store and use X509_OBJECT_get_type and X509_cmp to
 compare certificates.

--- a/src/sbverify.c
+++ b/src/sbverify.c
@@ -55,6 +55,14 @@
 #include 
 #include 
 
+#if OPENSSL_VERSION_NUMBER < 0x1010L
+#define X509_OBJECT_get0_X509(obj) ((obj)->data.x509)
+#define X509_OBJECT_get_type(obj) ((obj)->type)
+#define X509_STORE_CTX_get0_cert(ctx) ((ctx)->cert)
+#define X509_STORE_get0_objects(certs) ((certs)->objs)
+#define X509_get_extended_key_usage(cert) ((cert)->ex_xkusage)
+#endif
+
 static const char *toolname = "sbverify";
 static const int cert_name_len = 160;
 
@@ -123,9 +131,9 @@ static void print_signature_info(PKCS7 *
 
 	for (i = 0; i < sk_X509_num(p7->d.sign->cert); i++) {
 		cert = sk_X509_value(p7->d.sign->cert, i);
-		X509_NAME_oneline(cert->cert_info->subject,
+		X509_NAME_oneline(X509_get_subject_name(cert),
 subject_name, cert_name_len);
-		X509_NAME_oneline(cert->cert_info->issuer,
+		X509_NAME_oneline(X509_get_issuer_name(cert),
 issuer_name, cert_name_len);
 
 		printf(" - subject: %s\n", subject_name);
@@ -136,20 +144,26 @@ static void print_signature_info(PKCS7 *
 static void print_certificate_store_certs(X509_STORE *certs)
 {
 	char subject_name[cert_name_len + 1], issuer_name[cert_name_len + 1];
+	STACK_OF(X509_OBJECT) *objs;
 	X509_OBJECT *obj;
+	X509 *cert;
 	int i;
 
 	printf("certificate store:\n");
 
-	for (i = 0; i < sk_X509_OBJECT_num(certs->objs); i++) {
-		obj = sk_X509_OBJECT_value(certs->objs, i);
+	objs = X509_STORE_get0_objects(certs);
+
+	for (i = 0; i < sk_X509_OBJECT_num(objs); i++) {
+		obj = sk_X509_OBJECT_value(objs, i);
 
-		if (obj->type != X509_LU_X509)
+		if (X509_OBJECT_get_type(obj) != X509_LU_X509)
 			continue;
 
-		X509_NAME_oneline(obj->data.x509->cert_info->subject,
+		cert = X509_OBJECT_get0_X509(obj);
+
+		X509_NAME_oneline(X509_get_subject_name(cert),
 subject_name, cert_name_len);
-		X509_NAME_oneline(obj->data.x509->cert_info->issuer,
+		X509_NAME_oneline(X509_get_issuer_name(cert),
 issuer_name, cert_name_len);
 
 		printf(" - subject: %s\n", subject_name);
@@ -182,12 +196,21 @@ static int load_detached_signature_data(
 
 static int cert_in_store(X509 *cert, X509_STORE_CTX *ctx)
 {
-	X509_OBJECT obj;
+	STACK_OF(X509_OBJECT) *objs;
+	X509_OBJECT *obj;
+	int i;
+
+	objs = X509_STORE_get0_objects(X509_STORE_CTX_get0_store(ctx));
 
-	obj.type = X509_LU_X509;
-	obj.data.x509 = cert;
+	for (i = 0; i < sk_X509_OBJECT_num(objs); i++) {
+		obj = sk_X509_OBJECT_value(objs, i);
 
-	return X509_OBJECT_retrieve_match(ctx->ctx->objs, ) != NULL;
+		if (X509_OBJECT_get_type(obj) == X509_LU_X509 &&
+		!X509_cmp(X509_OBJECT_get0_X509(obj), cert))
+			return 1;
+	}
+
+	return 0;
 }
 
 static int x509_verify_cb(int status, X509_STORE_CTX *ctx)
@@ -195,8 +218,9 @@ static int x509_verify_cb(int status, X5
 	int err = X509_STORE_CTX_get_error(ctx);
 
 	/* also accept code-signing keys */
-	if (err == X509_V_ERR_INVALID_PURPOSE
-			&& ctx->cert->ex_xkusage == XKU_CODE_SIGN)
+	if (err == X509_V_ERR_INVALID_PURPOSE &&
+			X509_get_extended_key_usage(X509_STORE_CTX_get0_cert(ctx))
+			== XKU_CODE_SIGN)
 		status = 1;
 
 	/* all certs given with the --cert argument are trusted */
@@ -204,7 +228,7 @@ static int x509_verify_cb(int status, X5
 			err == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT ||
 			err == X509_V_ERR_CERT_UNTRUSTED) {
 
-		if (cert_in_store(ctx->current_cert, ctx))
+		if (cert_in_store(X509_STORE_CTX_get_current_cert(ctx), ctx))
 			status = 1;
 	}
 	/* UEFI doesn't care about expired signatures, so we shouldn't either. */
--- a/src/sbkeysync.c
+++ b/src/sbkeysync.c
@@ -204,16 +204,15 @@ static int x509_key_parse(struct key *ke
 		return -1;
 
 	/* we use the X509 serial number as the key ID */
-	if (!x509->cert_info || !x509->cert_info->serialNumber)
+	serial = X509_get_serialNumber(x509);
+	if (!serial)
 		goto out;
 
-	serial = x509->cert_info->serialNumber;
-
 	key->id_len = ASN1_STRING_length(serial);
 	key->id = talloc_memdup(key, ASN1_STRING_data(serial), key->id_len);
 
 	key->description = talloc_array(key, char, description_len);
-	X509_NAME_oneline(x509->cert_info->subject,
+	X509_NAME_oneline(X509_get_subject_name(x509),
 			key->description, description_len);
 
 	rc = 0;


signature.asc

Bug#828683: [Pkg-mc-devel] Bug#828683: mc: please make the build reproducible

[Yury V. Zaytsev]

On Sun, 26 Jun 2016, Reiner Herrmann wrote:

While working on the "reproducible builds" effort [1], we have noticed 
that mc could not be built reproducibly. It embeds the current date into 
the mcedit manpage during build.


Ok, I think that I can now see what went wrong here: Debian used to patch 
mcedit manpage, and so, mtime of the manpage file was set to the current 
time during the build. Our build system faithfully hardcoded this into the 
resulting man file.


Since then, however, I've upstreamed the patch and it was removed from 
3:4.8.17-1, so I'm really wondering why it is still not working for you...


--
Sincerely yours,
Yury V. Zaytsev

Bug#825317: Bug #825317: bash-completion: Un-escaped "~*" leads to spurious NSS lookups

[ge...@riseup.net]

found 825317 1:2.1-4
thanks

Hi Daniel,

Thanks for reporting this. Actually, this issue is quite old; [1] points
to the corresponding Ubuntu bug. According to this, just removing the
patch fixes this issue, but I'm unsure about the potential downside(s)
doing so and lacking time to check.

All the best,
Georg


[1] https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1390061


signature.asc
Description: Digital signature

Bug#828686: ITP: no-new-privs -- Set PR_NO_NEW_PRIVS before executing another program

[Christian Seiler]

Hi,
(cc'ing mentors since you already filed an RFS [1])

> It builds a single, eponymous, binary package.
> 
> I think it is a useful, though extremely simple, utility:
> system administrators may use it to starts processes as a non-privileged
> user and ensure that they cannot attempt to exploit local setuid binaries.

I don't mean to discourage you, but doesn't setpriv --no-new-privs
already do that? It's available in Stretch and sid, in the package
setpriv, built from src:util-linux.

Regards,
Christian

[1] Also, weirdly, I didn't see your ITP on debian-devel for some
reason.



signature.asc
Description: OpenPGP digital signature

Bug#825573: [kde-runtime] Compose key not working or not correctly

[Aeris]

> I don't have a guillemotleft guillemotright key in my keyboard, and as 
> mentioned I'm generating it through Compose with Multikey < <. But the 
> generated guillemotleft/right is not being processed again by Compose, so
> the  rules:
> Are unreachable for me (in X/gtk/qt4 and qt5 apps), so I wanted to know how
> you manage to send a  event to Compose. Do you have a
> guillemot key in your keyboard?

I’m using Bepo layout, so I have direct « and » access
https://bepo.fr/

Regards,
-- 
Aeris
Individual crypto-terrorist group self-radicalized on the digital Internet
https://imirhil.fr/

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

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

Bug#828483: osslsigncode: FTBFS with openssl 1.1.0

[Stephen Kitt]

On Sun, 26 Jun 2016 22:07:28 +0200, Stephen Kitt  wrote:
> On Sun, 26 Jun 2016 12:23:30 +0200, Kurt Roeckx  wrote:
> > If you have problems making things work, feel free to contact us.  
> 
> I've managed to fix most of the build issues, the remaining issue I'm faced
> with is the apparent disappearance of the STACK API (DECLARE_STACK_OF())
> etc. What should I be using instead?

Duh, it's DEFINE_STACK_OF()...

Regards,

Stephen


pgprVs0eYphDg.pgp
Description: OpenPGP digital signature

Bug#828683: [Pkg-mc-devel] Bug#828683: mc: please make the build reproducible

[Yury V. Zaytsev]

Hi Reiner,

On Sun, 26 Jun 2016, Reiner Herrmann wrote:

Yes, it is standardized [1] and already supported by a lot of build 
tools [2], e.g. even by gcc. Other distributions and FreeBSD are 
currently also in the process of adopting it.


Thank you for the clarifications! Maybe you could consider including these 
links in the original reports to mitigate such follow-up questions...


I've had a look at our build system, and my impression is that your patch 
should not be necessary. Please have a look at


doc/man/date-of-man-include.am

and in particular at MAN_DATE_CMD variable and following targets.

It encodes mtime of the source man file in the output, rather than the 
build date, so, as long as the source date is not modified, the build 
should be reproducible.


I believe that the lines that you have patched are currently unused and 
should be simply removed.


Am I missing something?

--
Sincerely yours,
Yury V. Zaytsev

Bug#828204: [Pkg-xfce-devel] Bug#828204: light-locker: Without chrome running, obeys xfce4-power-manager. With chrome, usually doesn't.

[Fred Korz]

On 06/26/2016 03:07 PM, Yves-Alexis Perez wrote:

On sam., 2016-06-25 at 22:05 -0400, Fred Korz wrote:

Since then, if google chrome (stable) is not running, power management on the
display works just as set.

However, if google chrome is running, for a while display blanking and turndown
works as configured, but eventually blanking doesn't work.

My first guess would be that google chrome uses inhibition to prevent screen
blanking/locking. Does it matter which tabs are open in google chrome?

Regards,


I had thought that too, that perhaps vlc were using inhibition, but 
shutting down vlc or not starting it had no effect.


As to chrome, not that I can tell if a particular tab is causing it.  
With 20 windows averaging 10 tabs/window, and a minimum of 3 minutes 
wait per sample to tell the outcome, that's not really practical.  That 
would be O(10) hours worst case, O(5) hours if found half way through.  
(Yes, I could use binary rather than linear search, but I'd have to 
figure out a way to store and restore the serious amount of state held 
in those windows and tabs.)


I suspect that there is a combination of (1) inhibition, which I don't 
know a practical way of finding, but hoped the package maintainers could 
suggest so I could chase it down, and (2) an assumption in light-locker 
of an installed screen locking which is violated when there's no 
screensaver installed (which seems to run counter to the 
self-containment goal of light-locker and the lack of a package 
dependency on any screensaver).


To that second point:

   If I run 'light-locker-command --lock', I get blanking, light off, 
power minimization and locking.


   If I run 'light-locker-command --activate', which I believe the man 
page suggests will do all the above except lock, instead it goes through 
as if it expected to rely on a screen locker as a barrier but it comes 
back with the complaint, previously cited above, about locker failure.  
I tried all the permutations on xfce4-power-manager-setting of 
"Automatically lock the session" in {"Never", "When screensaver is 
activated",
"When screensaver is deactivated"} crossed with "Lock screen when system 
is going for sleep" in {checked, unchecked}.


Fred

Bug#828692: ITP: tasksh -- a shell that wraps Taskwarrior commands

[Iain R. Learmonth]

Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: tasksh
  Version : 1.0.0
  Upstream Author : Paul Beckingham and Federico Hernandez
* URL : http://tasktools.org/projects/tasksh.html
* License : MIT
  Programming Lang: C++
  Description : a shell that wraps Taskwarrior commands

Tasksh is a shell command that wraps Taskwarrior commands. It is
intended to provide simpler Taskwarrior access, and add a few new
features of its own. The project is new, bear with us please.

Tasksh replaces the built-in shell command of older releases, and the
bundled tasksh program of version 2.3.0. The former was very limited
and the latter unsupported, buggy and flawed.

There has been discussion of a Taskwarrior packaging team in #827819. I
would be open to adding this package to the team along with bugwarrior
in #810629.

-- 

Bug#821347: libsecret porting for s390x

[Andreas Henriksson]

Hello Debian s390x porters!

I'd like to ask for your help with looking at the problems building
libsecret on s390x. It's currently the only (release-)architecture
not building and blocking testing migration for a long time. :(

It seems the testsuite somehow gets stuck on your arch/buildd

https://buildd.debian.org/status/fetch.php?pkg=libsecret=s390x=0.18.5-1=1462961523
https://tracker.debian.org/pkg/libsecret
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821347

Regards,
Andreas Henriksson

Bug#828691: ITP: golang-github-oleiade-reflections -- Golang high level abstractions over reflect library

[Andrew Starr-Bochicchio]

Package: wnpp
Severity: wishlist
Owner: Andrew Starr-Bochicchio 

* Package name: golang-github-oleiade-reflections
  Version : 0.1.2+git20131121.2.632977f-1
  Upstream Author : Théo Crevon
* URL : https://github.com/oleiade/reflections
* License : Expat
  Programming Lang: Go
  Description : Golang high level abstractions over reflect library

 Reflections Package reflections provides high level abstractions above
 the golang reflect library.
 .
 Reflect library is very low-level and can be quite complex when it comes
 to do simple things like accessing a structure field value, a field tag...
 .
 The purpose of reflections package is to make developers life easier when
 it comes to introspect structures at runtime.  Its API is inspired from
 python language (getattr, setattr, hasattr...) and provides a simplified
 access to structure fields and tags.

This is required for goss: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804202

Bug#823647: sshuttle package in stretch/sid builds only documentation, no executable

[Axel Beckert]

Control: notfound -1 sshuttle/0.78.0-1
Control: tags -1 - moreinfo
Control: close -1

Hi Robert,

Robert Lange wrote:
> You are correct. I have Python 3.4 installed. Rebuilding on a system
> with Python 3.5 worked as expected.

Thanks for the confirmation.

> Apparently if the X-Python-Version is not satisfied, the build gives
> no fatal errors and appears to work, while not actually building the
> package properly. But that's a bug for the build system, not this
> package.

Indeed. Not sure which part of the buildsystem is the culprit here.
Maybe it's also partially wanted if e.g. multiple python versions are
listed, but it shouldn't bail out if not all of them can be found.

Anyways, closing this bug report against sshuttle now.

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#828483: osslsigncode: FTBFS with openssl 1.1.0

[Stephen Kitt]

Hi Kurt,

On Sun, 26 Jun 2016 12:23:30 +0200, Kurt Roeckx  wrote:
> If you have problems making things work, feel free to contact us.

I've managed to fix most of the build issues, the remaining issue I'm faced
with is the apparent disappearance of the STACK API (DECLARE_STACK_OF()) etc.
What should I be using instead?

Regards,

Stephen


pgpFiKNSSABBl.pgp
Description: OpenPGP digital signature

Bug#758291: [pkg-wine-party] Bug#758291: Final preparations for Wine alternatives - design decisions

[Michael Gilbert]

On Thu, Jun 16, 2016 at 7:58 PM, Jens Reyer wrote:
> Proposed roadmap:
> - Release wine 1.8.3-1 (with the changes I've pushed to git today,
>   needs a sponsor).
> - Release wine-development 1.9.13 (next week) with these or similar
>   changes.
> - Implement alternatives system in wine (1.8.3-2) once both above
>   are in testing. Details later.

All seems reasonable. I am reviewing/sponsoring now.

Best wishes,
Mike

Bug#825573: [kde-runtime] Compose key not working or not correctly

[Maximiliano Curia]

Control: retitle -1 "Compose key can't generate multiple characters"
Control: reassign -1 src:qtbase-opensource-src

On Saturday, 25 June 2016 21:53:49 CEST Aeris wrote:
> On Sat, 28 May 2016 11:27:22 +0200 Maximiliano Curia
>  wrote:
> > How do you produce the  so that Compose processes it again?

> "«" and "»" alone never exist in French, always with non breaking space
> before or after, so no need to produce them.

I don't have a guillemotleft guillemotright key in my keyboard, and as 
mentioned I'm generating it through Compose with Multikey < <. But the 
generated guillemotleft/right is not being processed again by Compose, so the 
rules:
 : "« "
 : " »"

Are unreachable for me (in X/gtk/qt4 and qt5 apps), so I wanted to know how 
you manage to send a  event to Compose. Do you have a guillemot 
key in your keyboard?

In any case a simpler version:
   : "Blah"

Produces "Blah" in xterm, but "B" in qt applications, so I guess that's the 
same issue.

> > > Environments variables set :
> > >   QT_IM_MODULE=xim
> > >   GTK_IM_MODULE=xim
> > >   QT4_IM_MODULE=xim

> > I think these variables play no role here.

> Seems xim is involved somewhere in compose process.

Sure, only that the behavior for this particular issue is the same having 
these variable set or not.

Happy hacking,
-- 
"Don't let what you cannot do interfere with what you can do."
-- Wooden's Rule
Saludos /\/\ /\ >< `/


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

Bug#828025: autopkgtest cmd sensitive to PWD when passed an absolute path to a .changes file

[Martin Pitt]

Control: tag -1 moreinfo

Hello Sean,

Sean Whitton [2016-06-24  9:48 +0900]:
> 
> When passing an absolute path to a changes file to autopkgtest, e.g.
> 
> $ autopkgtest /home/spwhitton/src/foo_1.0.0_i386.changes -- schroot 
> unstable-i386-sbuild
> 
> autopkgtest fails and prints a usage message unless the PWD is
> /home/spwhitton/src/foo.  If the PWD is /home/spwhitton/src or anywhere
> else:
> 
> usage: autopkgtest [options] [testbinary ...] testsrc -- virt-server 
> [options]
> autopkgtest: error: You must specify source or click package to test

I strongly suspect your .changes file only contains binaries, not a
source. So normally it would print this error, unless you are *in* the
root dir of a source package, which is used in case you don't specify
any source package as argument.

Please confirm that this is the case.

> autopkgtest should look for the .dsc mentioned in the .changes file in
> the directory containing the .changes file.

It already does that.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#828690: ITP: r-cran-pscbs -- R package: Analysis of Parent-Specific DNA Copy Numbers

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-cran-pscbs
  Version : 0.61.0
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/PSCBS
* License : GPL-2+
  Programming Lang: R
  Description : R package: Analysis of Parent-Specific DNA Copy Numbers

Segmentation of allele-specific DNA copy number data and detection of regions
 with abnormal copy number within each parental chromosome. Both tumor-normal
 paired and tumoronly analyses are supported.

Prerequisite for cnvkit, to be maintained by Debian Med

Bug#731634: libarchive 3.2.1 needs newer (non-alpha) xz-utils to compile

[Andreas Henriksson]

Hello!

Sorry to be adding another "me too", but you asked "Is there a package
depending on this behavior, ..." so I have to add that the new
upstream release of libarchive 3.2.1 fixes several security related
issues and other critical fixes, but unfortunately it doesn't build
with the alpha-releases of xz-utils. An update would be appreciated
or atleast a status update on what the maintenance status is.
Should this package be orphaned so others can take care of it?
I might get some time to look at this during debconf so would
appreciate feedback ASAP.

Regards,
Andreas Henriksson

Bug#828160: kwallet-kf5: FTBFS on hppa - blowfishtest (Failed)

[John David Anglin]

On 2016-06-26, at 3:11 PM, Maximiliano Curia wrote:

> Yes, apparently the blowfish backend has never worked in big endian archs, 
> the 
> new test reveals that. I've added a patch in the Debian repository to fix 
> this, 
> and Pino is working in fixing this upstream.

Excellent!

Dave
--
John David Anglin   dave.ang...@bell.net

Bug#827948: Debian Testing Cannot be installed on Hyper-V 2012 R2

[Cyril Brulebois]

Hi,

Larry Sevilla  (2016-06-23):
> Package: debian-installer
> Version: debian-testing-i386-netinst.iso  dated 2016-06-20 07:33 391Mb
> 
> I'm trying to install Debian Testing under Hyper-V Windows Server 2012 R2.
> 
> mem: Start-up 1024Mb Dynamic Min 512Mb Max 3584
> proc: 2
> vhdx: 10Gb
> 
> Install it using non-GUI.
> 
> Then It freezes during:
>Partitions formatting at 33%
>Creating ext4 file system for / in partition #1 of SCSI3 (0,0,0) (sda)...
> 
> Note: I have installed Debian 7/Wheezy 7.11 and 8/Jessie 8.5 on Hyper-V;
>   so far no problem on installation with the two versions...

Please check syslog output on the console and see whether there's
something about kernel/module mismatch (symbol-related errors),
or something else.


KiBi.


signature.asc
Description: Digital signature

Bug#826229: Final withdrawal of bug report

[enno]

Dear Manoj & Co,

I finally withdraw this bug report, I've realised it was my fault.
I wasn't aware that I was trying to cross-compile ;(

With added options `--arch amd64 --cross-compile - ' the compile went fine.

Sorry for cluttering your mailbox, brgds, e.

-- 
  //   enno@gmx.net
/\\\   Mag. Enno Deimel
  .\o
 \\  \ _  \Wisely and slow; they stumble that run fast.
\\\ \_/
gpg-fp: eefe b049 6fe6 fc0b 0ec4  f39e af6a c178 eb98 909a

Bug#828689: qa.debian.org: manpages not listed on missing manpage page

[Muri Nicanor]

Package: qa.debian.org
Severity: normal

Dear Maintainer,

   * I opened the page https://qa.debian.org/man-pages.html
   * On the bottom of the page it says: "In total 0 man pages in 0
 packages are missing at the moment. This listing was generated from
 a Lintian report published on Sat, 25 Jun 2016."
   * I expected the number of missing manpages to be higher than 0


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

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


signature.asc
Description: PGP signature

Bug#828687: RFS: no-new-privs/0.0.2 [ITP] -- sets PR_NO_NEW_PRIVS and execute a program

[Nicolas Braud-Santoni]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "no-new-privs":

 * Package name: no-new-privs
   Version : 0.0.2-1
   Upstream Author : Nicolas Braud-Santoni 
 * URL : https://github.com/whawty/no_new_privs
 * License : ISC
   Section : utils


It builds a single, eponymous, binary package.

I think it is a useful, though extremely simple, utility:
system administrators may use it to starts processes as a non-privileged
user and ensure that they cannot attempt to exploit local setuid binaries.

The package I built is available in the following directory:

  https://nicolas.braud-santoni.eu/tmp/deb/

The packaging repository is available in collab-maint:

  https://anonscm.debian.org/gitweb/?p=collab-maint/no-new-privs.git

The ITP bug is there:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828686


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#828624: samba: Service fails to install and start

[Marc J. Driftmeyer]

Package: samba
Version: 2:4.4.4+dfsg-1
Followup-For: Bug #828624

Dear Maintainer,

Selecting previously unselected package samba.
(Reading database ... 704294 files and directories currently installed.)
Preparing to unpack .../samba_2%3a4.4.4+dfsg-1_amd64.deb ...
Unpacking samba (2:4.4.4+dfsg-1) ...
Processing triggers for libc-bin (2.23-0experimental2) ...
Processing triggers for systemd (230-3) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up samba (2:4.4.4+dfsg-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/nmbd.service → 
/lib/systemd/system/nmbd.service.
Created symlink /etc/systemd/system/multi-user.target.wants/samba-ad-dc.service 
→ /lib/systemd/system/samba-ad-dc.service.
Created symlink /etc/systemd/system/multi-user.target.wants/smbd.service → 
/lib/systemd/system/smbd.service.
Job for samba-ad-dc.service failed because the control process exited with 
error code.
See "systemctl status samba-ad-dc.service" and "journalctl -xe" for details.
invoke-rc.d: initscript samba-ad-dc, action "start" failed.
dpkg: error processing package samba (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.23-0experimental2) ...
Processing triggers for systemd (230-3) ...
Errors were encountered while processing:
 samba
E: Sub-process /usr/bin/dpkg returned an error code (1)

Gotta love when testing isn't thorough.

 Marc J. Driftmeyer

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

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

Versions of packages samba depends on:
ii  adduser  3.114
ii  dpkg 1.18.7
ii  init-system-helpers  1.35
ii  libbsd0  0.8.3-1
ii  libc62.23-0experimental2
ii  libldb1  2:1.1.26-1
ii  libpam-modules   1.1.8-3.3
ii  libpam-runtime   1.1.8-3.3
ii  libpopt0 1.16-10
ii  libpython2.7 2.7.12~rc1-2
ii  libtalloc2   2.1.6-1
ii  libtdb1  1.3.9-1
ii  libtevent0   0.9.28-1
ii  libwbclient0 2:4.4.4+dfsg-1
ii  lsb-base 9.20160601
ii  procps   2:3.3.11-3
ii  python   2.7.11-2
ii  python-dnspython 1.14.0-1
ii  python-samba 2:4.4.4+dfsg-1
pn  python2.7:any
ii  samba-common 2:4.4.4+dfsg-1
ii  samba-common-bin 2:4.4.4+dfsg-1
ii  samba-libs   2:4.4.4+dfsg-1
ii  tdb-tools1.3.9-1
ii  update-inetd 4.43

Versions of packages samba recommends:
ii  attr1:2.4.47-2
ii  logrotate   3.8.7-2
ii  samba-dsdb-modules  2:4.4.4+dfsg-1
ii  samba-vfs-modules   2:4.4.4+dfsg-1

Versions of packages samba suggests:
ii  bind9  1:9.10.3.dfsg.P4-10
ii  bind9utils 1:9.10.3.dfsg.P4-10
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p8+dfsg-1
ii  smbldap-tools  0.9.9-1
pn  ufw
ii  winbind2:4.4.4+dfsg-1

-- no debconf information

Bug#828688: gvfs-backends: thunar is unable to mount network places (windows machines)

[Karagkiaouris Diamantis]

Package: gvfs-backends
Version: 1.28.2-1
Severity: important

Dear Maintainer,

When i try to mount a Windows Shared folder with smbclient in thunar, the
folder is not mounted and i cannot navigate in a specific Windows Workgroup. I
must pass smb:// to find it. There must be a dependency on gvfs-backends on
default

Kind Regards



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

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

Versions of packages gvfs-backends depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  gvfs 1.28.2-1
ii  gvfs-common  1.28.2-1
ii  gvfs-daemons 1.28.2-1
ii  gvfs-libs1.28.2-1
ii  libarchive13 3.1.2-11.1
ii  libatk1.0-0  2.20.0-1
ii  libavahi-client3 0.6.32~rc+dfsg-1
ii  libavahi-common3 0.6.32~rc+dfsg-1
ii  libavahi-glib1   0.6.32~rc+dfsg-1
ii  libc62.22-11
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcdio-cdda10.83-4.2+b1
ii  libcdio-paranoia10.83-4.2+b1
ii  libcdio130.83-4.2+b1
ii  libgcrypt20  1.7.1-2
ii  libgdata22   0.17.4-1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgoa-1.0-0b3.20.1-1
ii  libgphoto2-6 2.5.10-3
ii  libgphoto2-port122.5.10-3
ii  libgtk-3-0   3.20.6-1
ii  libgudev-1.0-0   230-3
ii  libimobiledevice61.2.0+dfsg-3
ii  libjson-glib-1.0-0   1.2.0-1
ii  libmtp9  1.1.11-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libplist31.12-3.1
ii  libsecret-1-00.18.3-1
ii  libsmbclient 2:4.4.3+dfsg-4
ii  libsoup2.4-1 2.54.1-1
ii  libxml2  2.9.3+dfsg1-1.2
ii  psmisc   22.21-2.1+b1

Versions of packages gvfs-backends recommends:
ii  gnome-keyring  3.20.0-1

Versions of packages gvfs-backends suggests:
pn  bluez-obexd   
ii  samba-common  2:4.4.3+dfsg-4

-- no debconf information

Bug#828685: tasksel: characters when trying to install ssh server

[Karagkiaouris Diamantis]

Package: tasksel
Version: 3.35
Severity: important

Dear Maintainer,

When i try to install ssh server metapackage from tasksel, it renders some
strings like stdin, stdout and other that i cannot identify them. After the
procedure is finished these strings disappear and the ssh server is properly
installed.

Kind Regards



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

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

Versions of packages tasksel depends on:
ii  apt 1.2.13
ii  debconf [debconf-2.0]   1.5.59
ii  liblocale-gettext-perl  1.07-2
ii  perl-base   5.22.2-1
ii  tasksel-data3.35

tasksel recommends no packages.

tasksel suggests no packages.

-- debconf information:
* tasksel/desktop: xfce
  tasksel/title:
  tasksel/first: desktop, xfce-desktop, standard
  tasksel/tasks: desktop, xfce-desktop, ssh-server, laptop

Bug#828686: ITP: no-new-privs -- Set PR_NO_NEW_PRIVS before executing another program

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: no-new-privs
  Version : 0.0.2
  Upstream Author : Nicolas Braud-Santoni 
* URL : https://github.com/whawty/no_new_privs
* License : ISC
  Programming Lang: C
  Description : Set PR_NO_NEW_PRIVS before executing another command

This is a trivial program to set NO_NEW_PRIVS
before execvp(3)-ing another program.


signature.asc
Description: PGP signature

Bug#828639: [Reproducible-builds] Bug#828639: libmarpa-r2-perl: please make the build reproducible

[Reiner Herrmann]

On Sun, Jun 26, 2016 at 05:58:37PM +0200, Reiner Herrmann wrote:
> The attached patch makes it honour SOURCE_DATE_EPOCH, if it is
> available, to get a deterministic timestamp.

The patch has an issue when SOURCE_DATE_EPOCH is not defined.
An updated patch is attached which handles this case correctly.
Thanks to intrigeri for spotting it, and sorry for the noise!
diff --git a/debian/patches/reproducible_build.patch b/debian/patches/reproducible_build.patch
new file mode 100644
index 000..62b76f4
--- /dev/null
+++ b/debian/patches/reproducible_build.patch
@@ -0,0 +1,30 @@
+Author: Reiner Herrmann 
+Description: Honour SOURCE_DATE_EPOCH for embedded timestamp
+ When the environment variable SOURCE_DATE_EPOCH is set, use it instead of the
+ current time for the embedded build timestamp.
+ .
+ The specification of SOURCE_DATE_EPOCH is available here:
+ https://reproducible-builds.org/specs/source-date-epoch/
+ .
+ In the case it is not defined, fall back to current time in UTC.
+
+--- a/inc/Marpa/R2/Build_Me.pm
 b/inc/Marpa/R2/Build_Me.pm
+@@ -83,7 +83,7 @@
+ 
+ ##no critic(ValuesAndExpressions::RequireInterpolationOfMetachars)
+ $text .= q{use vars qw($TIMESTAMP)} . qq{;\n};
+-$text .= q{$TIMESTAMP='} . localtime()->datetime . qq{';\n};
++$text .= q{$TIMESTAMP='} . (gmtime($ENV{SOURCE_DATE_EPOCH} || time()))->datetime . qq{';\n};
+ ##use critic
+ 
+ for my $package (@use_packages) {
+@@ -104,7 +104,7 @@
+ 
+ ##no critic(ValuesAndExpressions::RequireInterpolationOfMetachars)
+ $text .= q{use vars qw($TIMESTAMP)} . qq{;\n};
+-$text .= q{$TIMESTAMP='} . localtime()->datetime . qq{';\n};
++$text .= q{$TIMESTAMP='} . (gmtime($ENV{SOURCE_DATE_EPOCH} || time()))->datetime . qq{';\n};
+ ##use critic
+ 
+ for my $package (@use_packages) {
diff --git a/debian/patches/series b/debian/patches/series
index f8d2256..b4a3780 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 1001_xs_boot_workaround.patch
 2001_libmarpa_external_linkage.patch
+reproducible_build.patch


signature.asc
Description: Digital signature

Bug#828160: kwallet-kf5: FTBFS on hppa - blowfishtest (Failed)

[Maximiliano Curia]

Control: tag -1 + pending upstream
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=362805

On Saturday, 25 June 2016 10:50:41 CEST John David Anglin wrote:
> Source: kwallet-kf5
> Version: 5.23.0-1
> Severity: normal
  
> Build fails on hppa and other big endian systems due to failure of
> TestBlowfishCipher:

Yes, apparently the blowfish backend has never worked in big endian archs, the 
new test reveals that. I've added a patch in the Debian repository to fix this, 
and Pino is working in fixing this upstream.

See last message in https://bugs.kde.org/show_bug.cgi?id=362805 and the last 
message in https://git.reviewboard.kde.org/r/127833/

Happy hacking,
-- 
"Any change looks terrible at first." -- Principle of Design Inertia
Saludos /\/\ /\ >< `/

Bug#828684: python-fuse: please add Homepage field

[Jakub Wilk]

Source: python-fuse
Version: 2:0.2.1-12
Severity: wishlist

Please add

Homepage: https://github.com/libfuse/python-fuse

to debian/control.

--
Jakub Wilk

Bug#828628: media-player-info: please make the build reproducible

[Martin Pitt]

Control: tag -1 pending

Hallo Reiner,

Reiner Herrmann [2016-06-26 14:28 +0200]:
> While working on the "reproducible builds" effort [1], we have noticed
> that media-player-info could not be built reproducibly.
> It searches for .mpi files without sorting them.
> This leads to an unsorted order in .hwdb and .rules files.

Thanks for this! I applied this upstream:

  https://cgit.freedesktop.org/media-player-info/commit/?id=c77201d

and uploaded to unstable.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#828040: gnss-sdr: FTBFS for mips, mipsel, ppc*, s390x: Cannot find gflags

[Carles Fernandez]

This has been applied in upstream at 
https://github.com/gnss-sdr/gnss-sdr/commit/642c37c09fb79fe36d0194285c969ea47b531269
 


Can't’ test it, though.

Thanks for the report.

Regards,
Carles

> El 24 jun 2016, a las 11:04, Dejan Latinovic  
> escribió:
> 
> 
> Package: gnss-sdr
> Version: 0.0.7-1
> Severity: important
> Tags: sid, patch
> Justification: FTBFS
> User: debian-m...@lists.debian.org
> Usertags: mips-patch
> 
> 
> Package gnss-sdr FTBFS for mips and mipsel on configure with the following 
> error:
> 
>> -- Cannot find gflags
>> --  gflags library has not been found.
>> --  gflags will be downloaded and built automatically
>> --  when doing 'make'.
>> CMake Error at /usr/share/cmake-3.5/Modules/ExternalProject.cmake:1757 
>> (message):
>>  error: could not find git for clone of gflags-2.1.2
>> Call Stack (most recent call first):
>>  /usr/share/cmake-3.5/Modules/ExternalProject.cmake:2459 
>> (_ep_add_download_command)
>>  CMakeLists.txt:480 (ExternalProject_Add)
>> 
>> 
>> -- Configuring incomplete, errors occurred!
> 
> The reason for this error is missing library path for mips architectures in 
> FindGFlags.cmake.
> 
> The patch that adds library path for mips is attached.
> After applying this patch build fails with issue reported issue:
> https://bugs.debian.org/828034
> 
> The same issue with gflags appears on powerpc, ppc64, ppc64el and s390x.
> I believe that similar fix could  be created for mentioned architectures as 
> well but unfortunately I am not able to test it.
> 
> 
> Regards,
> Dejan

--

Dr. Carles Fernández Prades
Communication Systems Division
Senior Researcher

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Address: Parc Mediterrani de la Tecnologia
  Av. Carl Friedrich Gauss, 7
  08860 Castelldefels, Barcelona, Spain.
Phone: +34 936452909Fax: +34 936452901
http://www.cttc.es/people/cfernandez/ 







signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#828683: [Pkg-mc-devel] Bug#828683: mc: please make the build reproducible

[Yury V. Zaytsev]

Hi Reiner,

On Sun, 26 Jun 2016, Reiner Herrmann wrote:

While working on the "reproducible builds" effort [1], we have noticed 
that mc could not be built reproducibly. It embeds the current date into 
the mcedit manpage during build.


That's my fault: the dates were originally entered by hand, which, of 
course, soon enough resulted in that they were no longer current, so I 
campaigned for them to be set automatically during the build.


The attached patch uses SOURCE_DATE_EPOCH as a deterministic timestamp 
instead.


I wouldn't mind upstreaming this patch as long as SOURCE_DATE_EPOCH is at 
least halfway standardized. Could you please tell me whether this is 
Debian-specific, or other distros are also adopting this convention?


Many thanks!

--
Sincerely yours,
Yury V. Zaytsev

Bug#828204: [Pkg-xfce-devel] Bug#828204: light-locker: Without chrome running, obeys xfce4-power-manager. With chrome, usually doesn't.

[Yves-Alexis Perez]

On sam., 2016-06-25 at 22:05 -0400, Fred Korz wrote:
> Since then, if google chrome (stable) is not running, power management on the
> display works just as set.
> 
> However, if google chrome is running, for a while display blanking and 
> turndown
> works as configured, but eventually blanking doesn't work.

My first guess would be that google chrome uses inhibition to prevent screen
blanking/locking. Does it matter which tabs are open in google chrome?

Regards,
-- 

Yves-Alexis

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

Bug#828683: [Pkg-mc-devel] Bug#828683: mc: please make the build reproducible

[Reiner Herrmann]

On Sun, Jun 26, 2016 at 09:00:50PM +0200, Yury V. Zaytsev wrote:
> >The attached patch uses SOURCE_DATE_EPOCH as a deterministic timestamp
> >instead.
> 
> I wouldn't mind upstreaming this patch as long as SOURCE_DATE_EPOCH is at
> least halfway standardized. Could you please tell me whether this is
> Debian-specific, or other distros are also adopting this convention?

Thanks for intending to upstream it!
Yes, it is standardized [1] and already supported by a lot of build
tools [2], e.g. even by gcc.
Other distributions and FreeBSD are currently also in the process of
adopting it.

[1]: https://reproducible-builds.org/specs/source-date-epoch/
[2]: 
https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Reading_the_variable


signature.asc
Description: Digital signature

Bug#828478: [PATCH] ovs-pki: Use SHA-512 message digest when available.

[Kurt Roeckx]

On Sun, Jun 26, 2016 at 11:05:35AM -0700, Ben Pfaff wrote:
> The upcoming OpenSSL 1.1.0 release disables use of SHA-1, which breaks the
> OVS unit tests, which use SHA-1.  We last tried to switch to SHA-512 in
> 2014 with commit 9ff33ca75e9fcc ("ovs-pki: Use SHA-512 instead of MD5 as
> message digest."), but we had to downgrade to SHA-1 in commit 4a1f9610682d
> ("ovs-pki: Use SHA-1 instead of SHA-512 as message digest.") because
> XenServer did not support SHA-512.
> 
> This commit detects support for SHA-512 and uses it if available, so it
> should avoid the problem encountered previously.

Note that openssl has supported SHA-512 for a while.  It's been
supported since 0.9.8 which was released in 2005.  So that support
detection doesn't look like a good idea.

You indicated that XenServer didn't support it.  Did that change?

>From what I understand of the log it's that the certificate still
using a weak digest.  I guess we started to rejected SHA-1 by
default now, which is actually a good thing.  The browsers should
stop supporting it soon too.

I suggest you just switch to SHA-256 or SHA-512 by default.

> diff --git a/AUTHORS b/AUTHORS
> index 704ba40..a893330 100644
> --- a/AUTHORS
> +++ b/AUTHORS
> @@ -367,6 +367,7 @@ Konstantin Khorenko khore...@openvz.org
>  Kris zhang  zhang.k...@gmail.com
>  Krishna Miriyalakris...@nicira.com
>  Krishna Mohan Elluruelluru.kri.mo...@hpe.com
> +Kurt Roeckx k...@roeckx.be

There really is no reason to add me, it's not like I contributed
anything, someone else tried to build it and I just filed bugs
based on that.


Kurt

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

[Preuße]

forwarded 828513 http://bugs.proftpd.org/show_bug.cgi?id=4240
stop

On 26.06.2016 12:23, Kurt Roeckx wrote:

> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> OpenSSL this package fail to build.  A log of that build can be found at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/proftpd-dfsg_1.3.5a-1_amd64-20160529-1512
> 
Known in upstream.

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

Bug#828683: mc: please make the build reproducible

[Reiner Herrmann]

Source: mc
Version: 3:4.8.17-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that mc could not be built reproducibly.
It embeds the current date into the mcedit manpage during build.

The attached patch uses SOURCE_DATE_EPOCH as a deterministic
timestamp instead.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible_man_date.patch b/debian/patches/reproducible_man_date.patch
new file mode 100644
index 000..5bcac25
--- /dev/null
+++ b/debian/patches/reproducible_man_date.patch
@@ -0,0 +1,13 @@
+--- a/configure.ac
 b/configure.ac
+@@ -428,7 +428,9 @@
+ dnl Documentation
+ dnl 
+ 
+-MAN_DATE="$(LC_ALL=C date "+%B %Y")"
++DATE_FMT="%B %Y"
++SOURCE_DATE_EPOCH="${SOURCE_DATE_EPOCH:-$(date +%s)}"
++MAN_DATE=$(LC_ALL=C date -u -d "@$SOURCE_DATE_EPOCH" "+$DATE_FMT" 2>/dev/null || LC_ALL=C date -u -r "$SOURCE_DATE_EPOCH" "+$DATE_FMT" 2>/dev/null || LC_ALL=C date -u "+$DATE_FMT")
+ AC_SUBST(MAN_DATE)
+ 
+ dnl Determine which help translations we want to install.
diff --git a/debian/patches/series b/debian/patches/series
index 861e26f..81c7c50 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -14,3 +14,4 @@ mcedit_full_path.patch
 mcedit_group_undo.patch
 ext_run-mailcap.patch
 ext_use_default_editor.patch
+reproducible_man_date.patch

Bug#828633: mount in testing/unstable should conflict with old bash-completion

[Andreas Henriksson]

Control: tags -1 = moreinfo

Hello!

Apparently I'm stressing this too much as well being short on time
currently...

On Sun, Jun 26, 2016 at 08:12:26PM +0200, Sven Joachim wrote:
> On 2016-06-26 23:22 +1000, Russell Coker wrote:
> 
> > Below is the results of "apt-get dist-upgrade" to upgrade from Jessie to
> > testing.  If I manually upgrade bash-completion first then mount can be
> > upgraded without problems.
> >
> > Preparing to unpack .../mount_2.28-5_amd64.deb ...
> > Unpacking mount (2.28-5) over (2.27.1-3.1) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/mount_2.28-5_amd64.deb (--unpack):
> >  trying to overwrite '/usr/share/bash-completion/completions/mount', which 
> > is also in package bash-completion 1:2.1-4.3
> 
> How could that happen, considering that bash-completion 1:2.1-4.3 is
> precisely the version which dropped the file in question, and there is
> not even a newer version in the archive?  Did you have a local
> bash-completion package with the same version as the official one and
> different contents installed?

I also find this peculiar when looking closer at it. That version
of bash-completion should not have the mount completion file.

> 
> On 2016-06-26 19:01 +0200, Sven Joachim wrote:
> 
> > On 2016-06-26 18:42 +0200, Andreas Henriksson wrote:
> >
> >> Thanks for your bug report. I apparently forgot to bump the version
> >> of the already existing Breaks/Replaces statements in previous upload.
> >> Fixed in git, will be part of next upload.
> >
> > The fix in git is wrong (at least not sufficient), though.
> 
> Or at least unrelated, since changes to the util-linux package will not
> fix file conflicts in the mount package.

Thanks for catching my mistake. I pushed a revert

> 
> > You bumped the Breaks/Replaces combination in util-linux, but really
> > it needs to be changed in mount, removing the spurious tilde:
> >
> > --8<---cut here---start->8---
> > diff --git a/debian/control b/debian/control
> > index cef4980..61f66ba 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -78,8 +78,8 @@ Section: admin
> >  Pre-Depends: ${misc:Pre-Depends}, ${shlibs:Depends}
> >  Depends: ${misc:Depends}
> >  Suggests: nfs-common (>=1:1.1.0-13)
> > -Breaks: bash-completion (<< 1:2.1-4.3~)
> > -Replaces: bash-completion (<< 1:2.1-4.3~)
> > +Breaks: bash-completion (<< 1:2.1-4.3)
> > +Replaces: bash-completion (<< 1:2.1-4.3)

This change makes no sense to me. When declaring relationships against
specific debian revisions including a trailing tilde is recommended
to enable backports for example.

> >  Multi-Arch: foreign
> >  Description: tools for mounting and manipulating filesystems
> >   This package provides the mount(8), umount(8), swapon(8),
> > --8<---cut here---end--->8---
> 
> Scratch that, this does not make any sense.  I should not comment on bug
> reports during football half-time breaks.

I guess we agree. not sure what change is needed here really.

Russel could you please enlighten us how this could happen?

(I'll try to find time during debconf to set up a chroot and test upgrade
to verify..)

Regards,
Andreas Henriksson

Bug#828457: nodejs: FTBFS with openssl 1.1.0

[Kurt Roeckx]

On Sun, Jun 26, 2016 at 06:53:42PM +0200, Jérémy Lal wrote:
> 
> I'm on it, and after a couple things i could solve, i need a "gentle push"
> to continue solving these:

They all seem to be about the same problem.  The structure has
become opaque and you can't have it directly on the stack or in an
other struct.  Instead you need to allocate it with TYPE_new(),
which will give you a pointer back.  This will ensure that the
allocated size is the correct one, since we might change the
structure to add new fields and thing like that.  When you do
things like sizeof(TYPE) you would get the size at compile time
which might be a different one than the one at runtime.


Kurt

Bug#819650: mirror submission for mirror.ba

[Donald Norwood]

Hi Emir,

1) The alias issue seems to be resolved using: deb.mirror.ba
2) /debian-cd/ is not current. Your mirror is showing version 8.4.0. The
problem here may be your upstream: churchill.acc.umu.se has changed. Use
ftp.acc.umu.se instead and it should update and sync you to the current
state of the /debian-cd/ archive.
3) Rsync is now working fine.

-Donald

On 06/23/2016 04:03 AM, Emir Beganović wrote:
> Hi there,
> 
> It's been more than a month since your last reply. Can someone please
> take a look?
> 
> Thanks
> 
> On Wed, May 25, 2016 at 11:20 AM, Emir Beganović
> > wrote:
> 
> Can you please take a look one again?
> 
> On Sun, Apr 24, 2016 at 8:16 PM, Donald Norwood
> > wrote:
> 
> Hi Emir,
> 
> My apologies I did not see your email response.
> 
> 1) Alias issues:
> 
> The alias debian.mirror.ba  points to
> mirror.ba .
> The mirror.ba  page then links to
> debian.mirror.ba 
> 
> 2) /debian-cd/ not current:
> 
> The /debian-cd/ directory is not current, your mirror has 8.2.0 and
> 8.2.0-live and not 8.4. Which your upstream is providing. Please
> check
> your configuration. Are you using the ftpsync script[1] we suggest?
> 
> 3) Rsync does not work:
> 
> rsync rsync://mirror.ba 
> rsync: failed to connect to mirror.ba 
> (80.65.85.94): Connection refused
> (111)
> 
> Please check this configuration.
> 
> > > Also the rsync works now. How do you check if the mirror has been
> updated?
> > > I can see it has, but you say it hasn't :)
> 
> I look at the /project/trace/ directory which holds the files
> that the
> mirror script generates. The trace file tells us which upstream
> mirror
> you are using, the time your mirror updated, and what the mirror is
> carrying. Your tracefile only provides the date but a longer
> tracefile
> (option EXTENDEDTRACE="full" in the ftpsync.conf file) would provide
> information such as:
> 
> Sun Apr 24 16:17:57 UTC 2016
> Date: Sun, 24 Apr 2016 16:17:57 +
> Date-Started: Sun, 24 Apr 2016 16:04:59 +
> Archive serial: 2016042403 
> Used ftpsync version: 20160306
> Running on host: intrepid.portalus.net
> 
> Architectures: GUESSED:{ source amd64 i386}
> Upstream-mirror: ftp.halifax.rwth-aachen.de
> 
> SSL: false
> Total bytes received in rsync: 365271190
> Total time spent in stage1 rsync: 417
> Total time spent in stage2 rsync: 359
> Total time spent in rsync: 776
> Average rate: 470710 B/s
> 
> Hope that helps. :)
> 
> If you have further questions please reach out I'll do my best
> to walk
> you through the process.
> 
> 
> 
> [1]ftp://ftp.us.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz
> Best regards,
> 
> Donald Norwood
> -Debian Mirrors Team
> 
> 
> On Tue, 12 Apr 2016 08:14:48 + Emir Beganovic
> > wrote:
> > Hi,
> >
> > Any news on this?
> >
> > Thanks
> >
> > On Thu, Apr 7, 2016 at 1:55 AM Emir Beganovic
> >
> > wrote:
> >
> > > Hi Donald,
> > >
> > > I did the changes as you said.
> > >
> > > I've removed /debian and left only the /debian-cd.
> > >
> > > Also the rsync works now. How do you check if the mirror has
> been updated?
> > > I can see it has, but you say it hasn't :)
> > >
> > > I was using debian.sil.at  but it
> seems old (2 days at least). I've
> > > switched to LeaseWeb's mirror (mirror.de.leaseweb.net
> ) and updated the
> > > mirror.
> > >
> > > Hope it looks good now!
> > >
> > > Regards
> > >
> > >
> > > On Tue, Apr 5, 2016 at 10:36 PM Donald Norwood
> >
> > > wrote:
> > >
> > >> Hi Emir,
> > >>
> > >> Do you change the mirror structure? I swear I accessed this
> differently
> > >> yesterday.
> > >>
> > >> The alias listed: debian.mirror.ba
>  no longer works. It does not have to
> > 

Bug#828633: mount in testing/unstable should conflict with old bash-completion

[Sven Joachim]

On 2016-06-26 23:22 +1000, Russell Coker wrote:

> Below is the results of "apt-get dist-upgrade" to upgrade from Jessie to
> testing.  If I manually upgrade bash-completion first then mount can be
> upgraded without problems.
>
> Preparing to unpack .../mount_2.28-5_amd64.deb ...
> Unpacking mount (2.28-5) over (2.27.1-3.1) ...
> dpkg: error processing archive /var/cache/apt/archives/mount_2.28-5_amd64.deb 
> (--unpack):
>  trying to overwrite '/usr/share/bash-completion/completions/mount', which is 
> also in package bash-completion 1:2.1-4.3

How could that happen, considering that bash-completion 1:2.1-4.3 is
precisely the version which dropped the file in question, and there is
not even a newer version in the archive?  Did you have a local
bash-completion package with the same version as the official one and
different contents installed?

On 2016-06-26 19:01 +0200, Sven Joachim wrote:

> On 2016-06-26 18:42 +0200, Andreas Henriksson wrote:
>
>> Thanks for your bug report. I apparently forgot to bump the version
>> of the already existing Breaks/Replaces statements in previous upload.
>> Fixed in git, will be part of next upload.
>
> The fix in git is wrong (at least not sufficient), though.

Or at least unrelated, since changes to the util-linux package will not
fix file conflicts in the mount package.

> You bumped the Breaks/Replaces combination in util-linux, but really
> it needs to be changed in mount, removing the spurious tilde:
>
> --8<---cut here---start->8---
> diff --git a/debian/control b/debian/control
> index cef4980..61f66ba 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -78,8 +78,8 @@ Section: admin
>  Pre-Depends: ${misc:Pre-Depends}, ${shlibs:Depends}
>  Depends: ${misc:Depends}
>  Suggests: nfs-common (>=1:1.1.0-13)
> -Breaks: bash-completion (<< 1:2.1-4.3~)
> -Replaces: bash-completion (<< 1:2.1-4.3~)
> +Breaks: bash-completion (<< 1:2.1-4.3)
> +Replaces: bash-completion (<< 1:2.1-4.3)
>  Multi-Arch: foreign
>  Description: tools for mounting and manipulating filesystems
>   This package provides the mount(8), umount(8), swapon(8),
> --8<---cut here---end--->8---

Scratch that, this does not make any sense.  I should not comment on bug
reports during football half-time breaks.

Cheers,
   Sven

Bug#828509: postgis: FTBFS with openssl 1.1.0

[Kurt Roeckx]

On Sun, Jun 26, 2016 at 06:03:15PM +0200, Sebastiaan Couwenberg wrote:
> Control: tags -1 unreproducible moreinfo
> 
> Hi Kurt,
> 
> Thanks for your work on OpenSSL.
> 
> On 06/26/2016 12:23 PM, Kurt Roeckx wrote:
> > OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> > OpenSSL this package fail to build.  A log of that build can be found at:
> > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/postgis_2.2.2+dfsg-2_amd64-20160529-1510
> 
> postgis has no direct dependency on libssl nor libcrypto. There is no
> clear openssl related failure in the buildlog, but it does show that it
> only installs the custom openssl dependencies and relies on unstable for
> the rest of the packages. So none of postgis build dependencies have
> been rebuilt with the new openssl packages. I suspect this issue is
> caused by postgres still linking to the old openssl whereas the new
> openssl is installed in the build environment.
> 
> > There is a libssl-dev package available in experimental that contains a 
> > recent
> > snapshot, I suggest you try building against that to see if everything 
> > works.
> > 
> > If you have problems making things work, feel free to contact us.
> 
> postgis is not among the reverse dependencies for openssl in the
> auto-openssl transition tracker [0], so I guess postgis was only rebuilt
> for your tests because it build depends on libssl-dev.
> 
> I cannot reproduce the issue with the libssl-dev from experimental, so
> I'm starting to suspect this issue is a false positive.
> 
> Can you confirm that the openssl update to 1.1.0 only affects packaging
> linking its libssl and/or libcrypto?

Only packages linking to libssl/libcrypto should be affected.  I'm
not sure why you build depend on libssl if you don't.

Anyway, if you can't reproduce this, feel free to close it.


Kurt

Bug#828478: [PATCH] ovs-pki: Use SHA-512 message digest when available.

[Ben Pfaff]

The upcoming OpenSSL 1.1.0 release disables use of SHA-1, which breaks the
OVS unit tests, which use SHA-1.  We last tried to switch to SHA-512 in
2014 with commit 9ff33ca75e9fcc ("ovs-pki: Use SHA-512 instead of MD5 as
message digest."), but we had to downgrade to SHA-1 in commit 4a1f9610682d
("ovs-pki: Use SHA-1 instead of SHA-512 as message digest.") because
XenServer did not support SHA-512.

This commit detects support for SHA-512 and uses it if available, so it
should avoid the problem encountered previously.

CC: 828...@bugs.debian.org
Reported-at: https://bugs.debian.org/828478
Reported-by: Kurt Roeckx 
Signed-off-by: Ben Pfaff 
---
 AUTHORS  |  1 +
 utilities/ovs-pki.in | 15 +--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index 704ba40..a893330 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -367,6 +367,7 @@ Konstantin Khorenko khore...@openvz.org
 Kris zhang  zhang.k...@gmail.com
 Krishna Miriyalakris...@nicira.com
 Krishna Mohan Elluruelluru.kri.mo...@hpe.com
+Kurt Roeckx k...@roeckx.be
 Len Gao l...@vmware.com
 Logan Rosen logatron...@gmail.com
 Luca Falavigna  dktrkr...@debian.org
diff --git a/utilities/ovs-pki.in b/utilities/ovs-pki.in
index 9b2b5aa..17497a8 100755
--- a/utilities/ovs-pki.in
+++ b/utilities/ovs-pki.in
@@ -248,7 +248,18 @@ if test "$command" = "init"; then
 
 # Write CA configuration file.
 if test ! -e ca.cnf; then
-sed "s/@ca@/$ca/g;s/@curr_date@/$curr_date/g" > ca.cnf <<'EOF'
+   if echo | openssl dgst -sha512 >/dev/null 2>&1; then
+   md=sha512
+   elif echo | openssl dgst -sha1 >/dev/null 2>&1; then
+   md=sha1
+   else
+   echo "$0: openssl does not support sha512 or sha1" >&2
+   exit 1
+   fi
+sed "s/@ca@/$ca/g
+s/@curr_date@/$curr_date/g
+s/@md@/$md/g
+" > ca.cnf <<'EOF'
 [ req ]
 prompt = no
 distinguished_name = req_distinguished_name
@@ -274,7 +285,7 @@ private_key= $dir/private/cakey.pem# CA private key
 RANDFILE   = $dir/private/.rand# random number file
 default_days   = 3650  # how long to certify for
 default_crl_days= 30   # how long before next CRL
-default_md = sha1  # message digest to use
+default_md = @md@  # message digest to use
 policy = policy# default policy
 email_in_dn= no# Don't add the email into cert DN
 name_opt   = ca_default# Subject name display option
-- 
2.1.3