date:20170802

Bug#863266: [Pkg-libvirt-maintainers] Bug#863266: libvirt-daemon: spice port conflict - multiple VMs want Port 5900

2017-08-02 Thread bob-debian-bugtracker

I forgot to update libvirt while testing earlier. Updated libvirt-daemon-system 
(libvirt-daemon) from 3.0.0-4 to 3.5.0-1 from Buster and can no longer 
reproduce the issue.

-- 
Bob

Bug#870589: ITP: golang-github-matryer-try -- Simple idiomatic retry package for Go

2017-08-02 Thread Anthony Fok

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-matryer-try
  Version : 1+git20161228.6.9ac251b-1
  Upstream Author : Mat Ryer
* URL : https://github.com/matryer/try
* License : Expat (MIT)
  Programming Lang: Go
  Description : Simple idiomatic retry package for Go

 Idiomatic Go retry package.
 Thanks to @rowland (https://github.com/rowland) for code review.
 .
 Usage: Just call try.Do with the function you want to retry
 in the event of an error.

Reason for packaging:
 Needed by github.com/tdewolff/minify,
 which in turn is likely needed by Hugo in the near future.

Bug#867486: Issue with the audit subsystem

2017-08-02 Thread Salvatore Bonaccorso

Hi Laurent,

Sorry for the lack of time and no reply to this.

On Fri, Jul 14, 2017 at 02:40:02PM +0200, Laurent Bigonville wrote:
> Le 09/07/17 à 21:58, Salvatore Bonaccorso a écrit :
> > Hi
> Hi,
> 
> > Unconfirmed, but the behaviour you are seen might be related to the
> > changes which went in in 4.11 around
> > 264d509637d95f9404e52ced5003ad352e0f6a26 .
> > 
> > https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26
> > 
> 
> I posted on the linux-audit mailing list and I get the following reply from
> Paul Moore:
> 
> > On Mon, Jul 10, 2017 at 10:59 AM, Laurent Bigonville  
> > wrote:
> > > Hi,
> > > 
> > > With 4.11.6 (that has been uploaded in debian unstable) I get a lot of
> > > messages in dmesg like
> > > 
> > > [100052.120468] audit: audit_lost=66041 audit_rate_limit=0
> > > audit_backlog_limit=8192
> > > [100052.120470] audit: kauditd hold queue overflow
> > > 
> > > And it also seems that the messages are not stored in auditd logs anymore.
> > > 
> > > https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26  
> > > seems
> > > to be included in this release
> > > 
> > > An idea?
> > I'm going to assume that your backlog limit is set to a sane value for
> > your system's configuration, so that leaves me with two commits that
> > may be of interest:
> > 
> > * 1df30f8264b8 ("audit: fix the RCU locking for the auditd_connection
> > structure")
> > 
> > This was a manual backport of a v4.12 patch to v4.11, looking now, I
> > see it should be in +v4.11.5 so that probably isn't your problem ...
> > 
> > * c81be52a3ac0 ("audit: fix a race condition with the auditd tracking code")
> > 
> > This patch is relatively new and was just sent up to Linus during the
> > next merge window; it's a race condition fix so reproducing it can be
> > tricky, although it may be easily reproducible on your system at the
> > moment (luck you!).  If you aren't in a position to apply the patch,
> > the workaround is rather simple: restart auditd.
> > 
> > If none of the above works, let me know, but I strongly suspect you're
> > tripping over the race condition fixed in that last patch.
> 
> I still should test the last patch he mentioned

Did you manage to test the last patch he mentioned? And does it
resolve the issue?

Regards,
Salvatore

Bug#870588: abcde: edit CD entry prompts only accept lowercase y/n

2017-08-02 Thread Arthur Marsh

Package: abcde
Version: 2.8.1-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Trying to rip a CD for which no database entry was found, hit Y to edit
and abcde skipped to is the CD multi-artist question.

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

lowercase y worked

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.13.0-rc3+ (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages abcde depends on:
ii  cd-discid   1.4-1+b1
ii  cdparanoia  3.10.2+debian-11+b2
ii  flac1.3.2-1
ii  icedax  9:1.1.11-3+b2
ii  lame1:3.99.5-dmo1
ii  musepack-tools  2:0.1~r495-1+b1
ii  vorbis-tools1.4.0-10+b1
ii  wget1.19.1-4

Versions of packages abcde recommends:
ii  bsd-mailx 8.1.2-0.20160123cvs-4
ii  glyrc 1.0.9-1
ii  imagemagick   8:6.9.7.4+dfsg-15
ii  imagemagick-6.q16 [imagemagick]   8:6.9.7.4+dfsg-15
ii  libdigest-sha-perl5.96-1+b3
ii  libmusicbrainz-discid-perl0.03-6+b4
ii  libperl5.26 [libdigest-sha-perl]  5.26.0-5
ii  libwebservice-musicbrainz-perl0.93-1.1
ii  vorbis-tools  1.4.0-10+b1

Versions of packages abcde suggests:
ii  atomicparsley0.9.6-1+b1
pn  distmp3  
ii  eject2.1.5+deb1+cvs20081104-13.2
pn  eyed3
pn  id3  
pn  id3v2
pn  mkcue
pn  mp3gain  
ii  normalize-audio  0.7.7-14+b1
ii  vorbisgain   0.37-2+b1

-- debconf-show failed

Bug#867211: What about stable?

2017-08-02 Thread Florian Fischer

Will this bug be fixed in stable too?
It is very annoying for me (thunar freezes several times per day during normal 
usage, which involves compiling a lot in my case). The upstream patch is very 
simple, too.
https://bugzilla.xfce.org/attachment.cgi?id=7074
Please consider applying it.

Best regards,
  Florian

Bug#870587: ITP: golang-github-cheekybits-is -- A mini testing helper for Go

2017-08-02 Thread Anthony Fok

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-cheekybits-is
  Version : 0.0~git20150225.0.68e9c06-1
  Upstream Author : cheekybits (Mat Ryer and Tyler Bunnell)
* URL : https://github.com/cheekybits/is
* License : Expat (MIT)
  Programming Lang: Go
  Description : A mini testing helper for Go

 A mini testing helper for Go.
  * Simple interface (is.OK and is.Equal)
  * Plugs into existing Go toolchain (uses testing.T)
  * Obvious for newcomers and newbs
  * Also gives you is.Panic and is.PanicWith helpers - because testing
panics is ugly

Reason for packaging:
 Needed by github.com/tdewolff/minify,
 which in turn is likely needed by Hugo in the near future.

Bug#870586: behave: FTBFS with Python 3.6 (ValueError: cannot use LOCALE flag with a str pattern)

2017-08-02 Thread Logan Rosen

Package: behave
Version: 1.2.5-1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Dear Maintainer,

Currently, behave fails to build from source in unstable due to the
tests failing with Python 3.6.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/0002-Python-3.6-compatibility.patch: Apply patch from
upstream to provide compatibility with Python 3.6 and fix FTBFS.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.10.0-28-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru behave-1.2.5/debian/patches/0002-Python-3.6-compatibility.patch 
behave-1.2.5/debian/patches/0002-Python-3.6-compatibility.patch
--- behave-1.2.5/debian/patches/0002-Python-3.6-compatibility.patch 
1969-12-31 16:00:00.0 -0800
+++ behave-1.2.5/debian/patches/0002-Python-3.6-compatibility.patch 
2017-08-02 21:50:23.0 -0700
@@ -0,0 +1,23 @@
+From f52cc2f59df8e21a5caf21b268bbd9ca6fa3e1e1 Mon Sep 17 00:00:00 2001
+From: jenisys 
+Date: Sat, 1 Oct 2016 12:42:11 +0200
+Subject: [PATCH] PREPARE for Python 3.6: re.LOCALE was removed
+
+---
+ behave/configuration.py | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/behave/configuration.py
 b/behave/configuration.py
+@@ -661,8 +661,10 @@
+ :param names: List of name parts or regular expressions (as text).
+ :return: Compiled regular expression to use.
+ """
++# -- NOTE: re.LOCALE is removed in Python 3.6 (deprecated in Python 
3.5)
++# flags = (re.UNICODE | re.LOCALE)
+ pattern = u"|".join(names)
+-return re.compile(pattern, flags=(re.UNICODE | re.LOCALE))
++return re.compile(pattern, flags=re.UNICODE)
+ 
+ def exclude(self, filename):
+ if isinstance(filename, FileLocation):
diff -Nru behave-1.2.5/debian/patches/series behave-1.2.5/debian/patches/series
--- behave-1.2.5/debian/patches/series  2017-06-12 22:01:28.0 -0700
+++ behave-1.2.5/debian/patches/series  2017-08-02 21:50:17.0 -0700
@@ -1 +1,2 @@
 0001-docs-disable-use-of-sphincontrib.cheeseshop.patch
+0002-Python-3.6-compatibility.patch

Bug#869586: botch: Fails ADT tests with python3.6

2017-08-02 Thread Johannes Schauer

Control: tag -1 + moreinfo

Hi,

On Mon, 24 Jul 2017 16:01:58 +0100 Dimitri John Ledkov  wrote:
> botch fails ADT tests with python3.6. On the surface the output looks sane,
> and it's not just the ordering differences as there are new things reported
> in the cycle output and some things missing.
> 
> Please see the attached log.

I saw attached log but I cannot reproduce your findings in Debian. The package
builds fine and passes its autopkgtests.

But I made a new upload to unstable. Using your setup, you might want to check
if the problem you saw persists with version 0.21-4.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#870585: hevea: Please support SOURCE_DATE_EPOCH

2017-08-02 Thread Johannes Schauer

Package: hevea
Version: 2.29-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps toolchain

Hi,

currently, latex sources which include statements like \today and thus
have to be built with '-exec xxdate.exe' do not respect the timestamp
set via the environment variable SOURCE_DATE_EPOCH. Thus, source
packages using hevea in this way are currently not reproducible. A quick
check revealed that this affects at least src:dose3 and src:whizzytex.

Since xxdate.exe is just a shell script, the fix is simple. Please
consider applying the patch at the bottom of this email to make packages
using hevea build reproducibly.

Thanks!

cheers, josch

diff --git a/xxdate.exe b/xxdate.exe
index 31e48a4..2b86087 100755
--- a/xxdate.exe
+++ b/xxdate.exe
@@ -1,17 +1,18 @@
 #! /bin/sh
+SDE="@${SOURCE_DATE_EPOCH:-$(date +%s)}"
 cat < /dev/null || date | awk 
'{print $NF}'`}
-\newcounter{month}\setcounter{month}{`date +"%m"`}
-\newcounter{day}\setcounter{day}{`date +"%d"`}
-\newcounter{time}\setcounter{time}{60 * `date +"%H"` + `date +"%M"`}
+\newcounter{year}\setcounter{year}{`date --utc --date=$SDE +"%Y" 2> /dev/null 
|| date --utc --date=$SDE | awk '{print $NF}'`}
+\newcounter{month}\setcounter{month}{`date --utc --date=$SDE +"%m"`}
+\newcounter{day}\setcounter{day}{`date --utc --date=$SDE +"%d"`}
+\newcounter{time}\setcounter{time}{60 * `date --utc --date=$SDE +"%H"` + `date 
--utc --date=$SDE +"%M"`}
 %% Extras
-\newcounter{hour}\setcounter{hour}{`date +"%H"`}
+\newcounter{hour}\setcounter{hour}{`date --utc --date=$SDE +"%H"`}
 \newcounter{Hour}\setcounter{Hour}{\value{hour}-(\value{hour}/12)*12}
-\newcounter{weekday}\setcounter{weekday}{`date +"%w"`}
-\newcounter{minute}\setcounter{minute}{`date +"%M"`}
-\newcounter{second}\setcounter{second}{`date +"%S"`}
+\newcounter{weekday}\setcounter{weekday}{`date --utc --date=$SDE +"%w"`}
+\newcounter{minute}\setcounter{minute}{`date --utc --date=$SDE +"%M"`}
+\newcounter{second}\setcounter{second}{`date --utc --date=$SDE +"%S"`}
 \def\ampm{\ifthenelse{\value{hour}>12}{PM}{AM}}
-\def\timezone{`date +"%Z" 2> /dev/null || date | awk '{print $5}'`}
-\def\heveadate{`date`}
+\def\timezone{`date --utc --date=$SDE +"%Z" 2> /dev/null || date --utc 
--date=$SDE | awk '{print $5}'`}
+\def\heveadate{`date --utc --date=$SDE`}
 EOF
\ No newline at end of file

Bug#863266: [Pkg-libvirt-maintainers] Bug#863266: libvirt-daemon: spice port conflict - multiple VMs want Port 5900

2017-08-02 Thread bob-debian-bugtracker

This appears to be related to kernel changes? At least on my end.
 
I have no issues starting multiple VMs while running 4.9.0-3 on Stretch.
 
However, I get the Spice error on 4.11.0-1, installed from Buster on top of a 
mostly-Stretch system.

It works again after downgrading the kernel, and breaks again after upgrading.

Changing the port allows the VM to start, so probably the same issue.

--
 
Working:

4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)
 
Broken:

4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19)

--
 
error: internal error: process exited while connecting to monitor: 
annel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice 
port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2
 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device 
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev 
spicevmc,id=charredir0,name=usbredir -device 
usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev 
spicevmc,id=charredir1,name=usbredir -device 
usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on
Domain id=5 is tainted: host-cpu
((null):4168): Spice-Warning **: reds.c:2530:reds_init_socket: listen: Address 
already in use
2017-08-03T04:27:44.895321Z qemu-system-x86_64: failed to initialize spice 
server

--

Incidentally, I upgraded the kernel to test nested Hyper-V within KVM, which 
requires 4.10 at a minimum[1]. Backports were not suitable since the updated 
zfs-dkms package is not available in stretch-backports, but the backports 
kernel is 4.11.0-0 anyway.
  
[1]: https://ladipro.wordpress.com/2017/07/21/hyperv-in-kvm-known-issues/

-- 
Bob

Bug#870584: surf FTCBFS: uses the build architecture pkg-config

2017-08-02 Thread Helmut Grohne

Source: surf
Version: 2.0-2
Tags: upstream patch
User: helm...@debian.org
Usertags: rebootstrap

surf fails to cross build from source, because it hard codes usage of
the build architecture pkg-config. After making it substitutable,
debhelper's passing of the right PKG_CONFIG works and makes cross builds
succeed. Please consider applying the attached patch.

Helmut
diff --minimal -Nru surf-2.0/debian/changelog surf-2.0/debian/changelog
--- surf-2.0/debian/changelog   2017-06-18 13:53:10.0 +0200
+++ surf-2.0/debian/changelog   2017-08-02 22:46:10.0 +0200
@@ -1,3 +1,10 @@
+surf (2.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add cross.patch (Closes: #-1).
+
+ -- Helmut Grohne   Wed, 02 Aug 2017 22:46:10 +0200
+
 surf (2.0-2) unstable; urgency=low
 
   * Upload to unstable.
diff --minimal -Nru surf-2.0/debian/patches/cross.patch 
surf-2.0/debian/patches/cross.patch
--- surf-2.0/debian/patches/cross.patch 1970-01-01 01:00:00.0 +0100
+++ surf-2.0/debian/patches/cross.patch 2017-08-02 22:46:07.0 +0200
@@ -0,0 +1,20 @@
+From: Helmut Grohne 
+Subject: make pkg-config substitutable for cross compilation
+
+Index: surf-2.0/config.mk
+===
+--- surf-2.0.orig/config.mk
 surf-2.0/config.mk
+@@ -11,8 +11,10 @@
+ X11INC = /usr/X11R6/include
+ X11LIB = /usr/X11R6/lib
+ 
+-GTKINC = $(shell pkg-config --cflags gtk+-3.0 webkit2gtk-4.0)
+-GTKLIB = $(shell pkg-config --libs gtk+-3.0 webkit2gtk-4.0)
++PKG_CONFIG ?= pkg-config
++
++GTKINC = $(shell $(PKG_CONFIG) --cflags gtk+-3.0 webkit2gtk-4.0)
++GTKLIB = $(shell $(PKG_CONFIG) --libs gtk+-3.0 webkit2gtk-4.0)
+ 
+ # includes and libs
+ INCS = -I. -I/usr/include -I${X11INC} ${GTKINC}
diff --minimal -Nru surf-2.0/debian/patches/series 
surf-2.0/debian/patches/series
--- surf-2.0/debian/patches/series  2017-04-14 20:23:45.0 +0200
+++ surf-2.0/debian/patches/series  2017-08-02 22:45:27.0 +0200
@@ -2,3 +2,4 @@
 2002_hardening_portability_fix.patch
 2003_replace_st_with_stterm.patch
 strict_ssl.patch
+cross.patch

Bug#863089: [Piuparts-devel] Bug#863089: Bug#863089: Bug#863089: Bug#863089: Please provide post-processed logs output for manpages.d.o

2017-08-02 Thread Holger Levsen

Hey,

adding go-lang any to the build-depends also 
https://jenkins.debian.net/job/piuparts_testsuite_jessie/266/
not yet sure how to fix this, probably maybe by making it depend on
golang-any >= $bpo_version, so that it's obvious what needs to be
done - both on jenkins and when backporting piuparts.

(just a bit too tired to decide this now…)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#863089: [Piuparts-devel] Bug#863089: Bug#863089: Bug#863089: Bug#863089: Please provide post-processed logs output for manpages.d.o

2017-08-02 Thread Holger Levsen

Hi again,

your change broke deployment on the slaves, please provide a fix:


holger@piu-slave-ubc-01:~$ sudo -u piupartss -i 
/srv/piuparts.debian.org/src/piuparts/update-piuparts-slave-setup develop origin
[...]
make python-syntax-check
make[1]: Entering directory '/srv/piuparts.debian.org/src/piuparts'
+ python -m py_compile piuparts.py
+ python -m py_compile piuparts-analyze.py
+ python -m py_compile piuparts-master-backend.py
+ python -m py_compile piuparts-slave.py
+ python -m py_compile piuparts-report.py
+ python -m py_compile piupartslib/dependencyparser.py
+ python -m py_compile piupartslib/__init__.py
+ python -m py_compile piupartslib/packagesdb.py
+ python -m py_compile piupartslib/conf.py
+ python -m py_compile piupartslib/pkgsummary.py
+ python -m py_compile piupartslib/dwke.py
+ python -m py_compile master-bin/detect_well_known_errors.py
rm -f piuparts.pyc piuparts-analyze.pyc piuparts-master-backend.pyc 
piuparts-slave.pyc piuparts-report.pyc piupartslib/dependencyparser.pyc 
piupartslib/__init__.pyc piupartslib/packagesdb.pyc piupartslib/conf.pyc 
piupartslib/pkgsummary.pyc piupartslib/dwke.pyc 
master-bin/detect_well_known_errors.pyc
make[1]: Leaving directory '/srv/piuparts.debian.org/src/piuparts'
(cd debiman-piuparts-distill && go build)
/bin/sh: 1: go: not found
Makefile:52: recipe for target 'build-stamp' failed
make: *** [build-stamp] Error 127


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#863089: [Piuparts-devel] Bug#863089: Bug#863089: Bug#863089: Please provide post-processed logs output for manpages.d.o

2017-08-02 Thread Holger Levsen

On Tue, Aug 01, 2017 at 11:30:11AM +0200, Michael Stapelberg wrote:
> Sure: https://github.com/stapelberg/piuparts/commits/distill

cool, thanks, merged and deployed on pejacevic!
 
> As previously, this is untested, so just let me know if any changes are
> required, or — probably faster — just perform the changes yourself if you
> want :).

piupartsm@pejacevic:~$ distill_alternatives_log 
/home/piupartsm/bin/distill_alternatives_log: Zeile 10: 
debiman-piuparts-distill: Kommando nicht gefunden.
piupartsm@pejacevic:~$ 

I guess you'll need to fix this up…

I've deployed this using 

sudo -u piupartsm -i 
/srv/piuparts.debian.org/src/piuparts/update-piuparts-master-setup develop 
origin


Finally, please do provide a debian/changelog entry for your work, you 
can much better describe it than I and I'm lazy ;-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#870318: mate-polkit: MATE polkit built against GTK 3 displays a corrupted icon.

2017-08-02 Thread Mike Gabriel


Hi,

On  Do 03 Aug 2017 04:32:11 CEST, Omar Jair Purata Funes wrote:


Package build was successful, and the package is now working properly :D

I will also attach the proper built packages, these DO NOT follow the
Debian guidelines, I just added the patch & the changelog entry, they are
not signed by me since I'm not the maintainer, I will also include the
build .dsc & change files.



Good. No need to send binary blobs. More information can be provided  
by comparing to .dsc files (and their set of source package files)  
using the "debdiff  " tool.


I'll commit the necessary changes to mate-polkit's  
debian/stretch/updates branch. I will propose an upload to the release  
team, but the issue might be to minor. If is to minor, we will include  
it once there is another issue with mate-polkit with more weight.


Thanks for testing!
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgptZ5gKzPxdh.pgp
Description: Digitale PGP-Signatur

Bug#54988: Daily Mail

2017-08-02 Thread Ramon, Shulamit

Dònàtion was màde to you. Reply for details.

Bug#870583: libgrib-api0: unhandled symlink to directory conversion: /usr/share/grib_api -> eccodes

2017-08-02 Thread Andreas Beckmann

Package: libgrib-api0
Version: 1.23.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  testing -> sid

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


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

0m25.1s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/grib_api/definitions (libgrib-api0) != 
/usr/share/eccodes/definitions (libeccodes-data)
/usr/share/grib_api -> eccodes
  /usr/share/grib_api/definitions/boot.def (libgrib-api0) != 
/usr/share/eccodes/definitions/boot.def (libeccodes-data)
/usr/share/grib_api -> eccodes
  /usr/share/grib_api/definitions/budg (libgrib-api0) != 
/usr/share/eccodes/definitions/budg (libeccodes-data)
/usr/share/grib_api -> eccodes
  /usr/share/grib_api/definitions/budg/boot.def (libgrib-api0) != 
/usr/share/eccodes/definitions/budg/boot.def (libeccodes-data)
/usr/share/grib_api -> eccodes
  /usr/share/grib_api/definitions/budg/mars_labeling.def (libgrib-api0) != 
/usr/share/eccodes/definitions/budg/mars_labeling.def (libeccodes-data)
/usr/share/grib_api -> eccodes
[..]/usr/share/grib_api -> eccodes
  /usr/share/grib_api/samples/sh_pl_grib1.tmpl (libgrib-api0) != 
/usr/share/eccodes/samples/sh_pl_grib1.tmpl (libeccodes-data)
/usr/share/grib_api -> eccodes
  /usr/share/grib_api/samples/sh_pl_grib2.tmpl (libgrib-api0) != 
/usr/share/eccodes/samples/sh_pl_grib2.tmpl (libeccodes-data)
/usr/share/grib_api -> eccodes
  /usr/share/grib_api/samples/sh_sfc_grib1.tmpl (libgrib-api0) != 
/usr/share/eccodes/samples/sh_sfc_grib1.tmpl (libeccodes-data)
/usr/share/grib_api -> eccodes
  /usr/share/grib_api/samples/sh_sfc_grib2.tmpl (libgrib-api0) != 
/usr/share/eccodes/samples/sh_sfc_grib2.tmpl (libeccodes-data)
/usr/share/grib_api -> eccodes


cheers,

Andreas


libgrib-api0_1.23.0-1.log.gz
Description: application/gzip

Bug#870582: libscalapack-openmpi-dev: fails to upgrade from 'sid' - trying to overwrite /usr/lib/x86_64-linux-gnu/libscalapack-openmpi.so

2017-08-02 Thread Andreas Beckmann

Package: libscalapack-openmpi-dev
Version: 2.0.2-1exp3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libscalapack-mpi-dev

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

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

  Selecting previously unselected package libscalapack-openmpi2.0.
  (Reading database ... 
(Reading database ... 7455 files and directories currently installed.)
  Preparing to unpack .../libscalapack-openmpi2.0_2.0.2-1exp3_amd64.deb ...
  Unpacking libscalapack-openmpi2.0 (2.0.2-1exp3) ...
  Selecting previously unselected package libscalapack-openmpi-dev.
  Preparing to unpack .../libscalapack-openmpi-dev_2.0.2-1exp3_amd64.deb ...
  Unpacking libscalapack-openmpi-dev (2.0.2-1exp3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libscalapack-openmpi-dev_2.0.2-1exp3_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libscalapack-openmpi.so', 
which is also in package libscalapack-mpi-dev 1.8.0-14
  Preparing to unpack .../libscalapack-mpi-dev_2.0.2-1exp3_amd64.deb ...
  Unpacking libscalapack-mpi-dev (2.0.2-1exp3) over (1.8.0-14) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/libscalapack-openmpi-dev_2.0.2-1exp3_amd64.deb

cheers,

Andreas


libscalapack-mpi-dev_2.0.2-1exp3.log.gz
Description: application/gzip

Bug#862309: Don't install /etc/sudoers.dist sample file

2017-08-02 Thread Bdale Garbee

tags 862309 +pending
thanks

Michael Biebl  writes:

> the latest update installed a new conffile /etc/sudoers.dist.

Thanks for catching this.  I didn't notice when the upstream Makefile
changed to deliver this by default.  Fixed in my revision control system
for the next upload.

Bdale


signature.asc
Description: PGP signature

Bug#865428: tar-scripts: make tar-scripts package depend on tar package

2017-08-02 Thread Bdale Garbee

tags 865428 +pending
thanks

Alexander Lazarević  writes:

> The tar-scripts package got extracted out of the tar package with
> version 1.26+dfsg-9 and should depend on any newer tar package version
> from there on. It should also be in conflict with older tar packages,
> that still contain what is now in the tar-scripts package.

Thanks for the suggestion, I've made this change in my revision control
system for the next upload.

Bdale


signature.asc
Description: PGP signature

Bug#862309: Don't install /etc/sudoers.dist sample file

2017-08-02 Thread Bdale Garbee

Paul Wise  writes:

> it might be useful to install it as an example instead.

Sure, makes sense, and easy to do.

Bdale


signature.asc
Description: PGP signature

Bug#870581: ITP: deepin-movie -- Deepin Desktop Environment Movie Player

2017-08-02 Thread Yanhao Mo

Package: wnpp
Severity: wishlist
Owner: Yanhao Mo 

 * Package name: deepin-movie
   Version : 2.9.1
   Upstream Author : Deepin Technology Co., Ltd.
 * URL : https://www.deepin.org/
 * License : GPLv3
   Programming Lang: C, C++
   Description : Deepin Desktop Environment Movie Player

Deepin Movie provides an intuitive easy to user operation interface
and rich complete shortcuts. One can complete all play opearations
by keyboard, which will make you thoroughly get rid of the
constriaint of mouse click. Video files in various formats can be
played through Deepin Movie.

I intend to co-maintain this package inside pkg-deepin team.


signature.asc
Description: PGP signature

Bug#870580: perl: broken symlink: /usr/share/man/man1/pstruct.1.gz -> c2ph.1.gz

2017-08-02 Thread Andreas Beckmann

Package: perl
Version: 5.26.0-5
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m37.6s ERROR: FAIL: Broken symlinks:
  /usr/share/man/man1/pstruct.1.gz -> c2ph.1.gz

There is no c2ph.1.gz manpage (nor a c2ph binary) in sid.


cheers,

Andreas


perl-modules-5.26_5.26.0-5.log.gz
Description: application/gzip

Bug#650425: Please add options to set the port range for nfs clients

2017-08-02 Thread Martin Dorey

Christoph Anton Mitterer wrote, regarding rpcbind, some four years ago:

> It seems to always reserve one random (not 873) port in addition... why 
> does it do so at all? 

I think it's used to make remote "callit" requests, to receive their 
asynchronous replies and to forward those replies onto the original requester.  
Portmap used to fork() to do this synchronously.  More at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870579: rpcbind callit 
replies from a random reserved udp port, making firewalling hard

Sorry for dredging up this old news but perhaps someone's still interested.

Bug#870018: [Pkg-openssl-devel] Bug#870018: openssl: SIGSEGV/coredump on process stop when TLS is enabled in kamailio

2017-08-02 Thread Kurt Roeckx

reassign 870018 kamailio
thanks

On Wed, Aug 02, 2017 at 05:01:01PM +0200, Guillem Jover wrote:
> Control: tags -1 patch
> 
> Hi!
> 
> On Sat, 2017-07-29 at 09:11:53 +0200, Kurt Roeckx wrote:
> > On Sat, Jul 29, 2017 at 12:12:16AM +0200, Michael Prokop wrote:
> > > Kurt, do you have any ideas what might go wrong in OPENSSL_cleanup
> > > here and how this could be fixed? We'd appreciate any hints. Thanks!
> 
> > I don't see anything obvious wrong. From what I understand it
> > calls exit(0) from a SIGTERM handler.
> > 
> > The only suggestion I have is that you try to run this under
> > valgrind or something.
> > 
> > Also feel free to open a github issue about this.
> 
> I was checking this, and my initial hypothesis which I've not yet
> confirmed, but seems completely spot on, given the documentation I've
> just read about OPENSSL_cleanup() is that something within the pthreads
> library is releasing the memory pool for the affected variable that is
> segfaulting in OpenSSL, and when the OpenSSL atexit() handler gets
> called the pthreads variable is already gone.
> 
> The attached patch fixes the segfault for me, and seems to be in line
> with the recommendations in the OPENSSL_cleanup() docs. I should
> probably update the comment further. And I guess this report should be
> reassigned to the kamailio package then.
> 
> I'm not sure whether calling OPENSSL_thread_stop() would be more
> correct here, as I don't know how threads are being used, and how the
> TLS module interacts with the rest of the codebase, etc.

>From reading the documentation, I think OPENSSL_thread_stop()
should have been called because otherwise it doesn't know it's
variable already got removed. So I'm reassigning it.


Kurt

Bug#864755: Bash completion missing in 2.15

2017-08-02 Thread Apollon Oikonomopoulos

Control: severity -1 wishlist
Control: tags -1 unreproducible moreinfo

Hi,

On 12:40 Wed 14 Jun , Christian Balzer wrote:
> Unlike with 2.12 there is no longer a /etc/bash_completion.d/ganeti
> provided by this package.

Thanks for the report. Bash completions are now being installed under 
/usr/share/bash-completion/completion and should work out of the box.  
Can you please check if this is the case?

Regards,
Apollon

Bug#870579: rpcbind callit replies from a random reserved udp port, making firewalling hard

2017-08-02 Thread Martin Dorey

Package: rpcbind
Version: 0.2.0-8
Severity: normal

Dear Maintainer,

I just upgraded a NIS server from Squeeze to Wheezy, hence from portmap to
rpcbind.
Yes, I know it's 2017 and there's Jessie, if not Stretch :).
Some of that server's clients stopped being able to find it with ypbind's
broadcast.
ypbind appears to send a subnet broadcast CALLIT request to port 111
for the YPSERV program's DOMAIN_NON_ACK procedure.
These clients were firewalled.
They had a hole allowing udp traffic from port 111.
portmap's replies were coming from port 111.
All was good.
rpcbind's replies come from another reserved udp port.
That doesn't have a firewall hole.
All is no longer good.
This port is picked at seeming random when rpcbind starts.
The variation makes firewalling difficult.
I've looked at the source and I'm confident that it's behaving as designed.
The design just seems... a little unfortunate.
It seems to predate the current upstream, which started with:

http://git.linux-nfs.org/?p=steved/rpcbind.git;a=blob;f=src/rpcb_svc_com.c;hb=f4aea95069461d06bd8a13e189e1a77e9ca03d75

Indeed, I see the problem looks to be there in Wietse Venema's
rpcbind_2.1.tar.gz at:

http://ftp.porcupine.org/pub/security/index.html

But not in his portmap_5beta.tar.gz.
I conclude that Sun bequeathed it to us like this.
I wonder if the reason for all that extra code was
to remove the fork() that the portmap implementation used.

I doubt I could persuade anyone to change the design even if I tried.
I raise this, then, just to document the issue for the next poor sap to be
tripped up by it.
Upstream's bug database:

https://sourceforge.net/p/rpcbind/bugs/?source=navbar

... seemed more moribund than Debian's.

The extra open udp and udp6 ports might have caused the intermittent failures
culminating in an expression of security concern at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650425#25

... and the puzzlement at:

https://stackoverflow.com/questions/35783145/why-is-rpcbind-opening-a-new-and-different-port-anytime-its-restarted

When I found:

https://www.illumos.org/issues/4483: rpcbind: Reply for remote calls comes from
incorrect UDP port

I thought someone else had already fixed it.
But having plowed through the large patch there, I don't see how it would fix
that.
Perhaps I missed something.

Our ref: D131248.

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

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

Versions of packages rpcbind depends on:
ii initscripts 2.88dsf-41+deb7u1
ii insserv 1.14.0-5
ii libc62.13-38+deb7u11
ii libtirpc10.2.2-5
ii libwrap0 7.6.q-24
ii lsb-base 4.1+Debian8+deb7u1

rpcbind recommends no packages.

rpcbind suggests no packages.

-- debconf-show failed

Bug#870578: nmu: logol_1.7.5-1 ppl_1:1.2-2

2017-08-02 Thread Andreas Beckmann

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu logol_1.7.5-1 . ANY . unstable . -m "Rebuild against swi-prolog 7.4.2"
nmu ppl_1:1.2-2 . ANY . unstable . -m "Rebuild against swi-prolog 7.4.2"

This is kind of a "hidden" transition. Not sure if I caught all affected
packages.
The binary packages have a strict dependency on the upstream version of
swi-prolog that was used at build time.


Andreas

Bug#870577: libapache2-mod-wsgi: after install of libapache2-mod-wsgi-py3, purge of this package disables wsgi module

2017-08-02 Thread Luca Filipozzi

Package: libapache2-mod-wsgi
Version: 4.5.11-1
Severity: normal

Dear Maintainer,

Installing libapache2-mod-wsgi-py3 leaves libapache2-mod-wsgi in 'rc'
state. Subsequent purge of libapache2-mod-wsgi causes 'wsgi' Apache2
module to be disabled (symlinks removed).

Resolved with 'a2enmod wsgi'.

postrm of libapache2-mod-wsgi might need tweaking.

Luca

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

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

Versions of packages libapache2-mod-wsgi depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.25-3+deb9u2
ii  libc6   2.24-11+deb9u1
pn  libpython2.7
ii  python  2.7.13-2

libapache2-mod-wsgi recommends no packages.

libapache2-mod-wsgi suggests no packages.

Bug#825246: page parsing bug fixed

2017-08-02 Thread Jay Berkenbilt

There was an off-by-one error in the parsing command. This will be fixed
in 7.0.0. As a workaround, just put out.pdf at the end, so run

qpdf --empty --pages *.pdf -- out.pdf

instead of

qpdf --empty out.pdf --pages *.pdf --

I always do it the second way, which is why I missed this. I didn't even
have any test cases for it. Anyway, it's fixed now in master and will be
in the next release. Sorry for taking sooo long to get to it.

-- 
Jay Berkenbilt

Bug#870576: Configure Emacs --without-pop or (in Emacs 26) --with-mailutils

2017-08-02 Thread Paul Eggert


Package: emacs25
Version: 25.1+1-4

Debian ships Emacs with the default configuration, which means it installs a 
separate program 'movemail' that retrieves email via the POP3 protocol. When it 
uses POP3, 'movemail' supports only unencrypted mail transfer, which is a 
significant security problem for people reading their email.


To avoid this problem, I suggest that Debian build emacs via './configure 
--without-pop', as this disables POP in movemail. Although this will remove a 
feature, the feature is so insecure that it cannot be recommended.


When Emacs 26 comes out, its ./configure program will have an option 
--with-mailutils, and I suggest that Debian use this option and make the 
'mailutils' package a prerequisite for Emacs. This will add support for 
encrypted POP3 email, thus restoring the POP3 capability lost by using 
--without-pop.


Thanks.

Bug#600915: support multiple debsrc tarballs

2017-08-02 Thread Guido Günther

Hi,
On Thu, Oct 21, 2010 at 11:25:09AM -0400, Joey Hess wrote:
> Daniel Baumann wrote:
> > I've no idea if that's actually doable in a generic and sane way, but it
> > would be great if pristine-tar would have a way to deal with multiple
> > orig tarballs (which newer debsrc format allows), so that all the delta
> > files would be in one commit and against their respective directory, e.g.:
> > 
> > if the tarballs of a debian source package would consist of:
> > 
> >   foo_1.2.3.orig.tar.gz
> >   foo_1.2.3.orig-bar.tar.gz
> >   foo_1.2.3.orig-baz.tar.gz
> > 
> > the diff for foo_1.2.3.orig.tar.gz would need to be done against the
> > root of the repository directory as usual, but with excluding bar/ and baz/.
> > 
> > the diff for foo_1.2.3.orig-bar.tar.gz would be done only against the
> > bar directory only, foo_1.2.3.orig-baz.tar.gz only against baz/ etc.
> > 
> > ...and ideally, this alltogether in one single pristine-tar commit :)
> 
> pristine-tar does not know about source package formats. This could be
> done at the git-buildpackage layer.
> 
> It does not matter if the tree pristine-tar is pointed at contains extra
> files or directories. It does need to have files with the same names as
> the ones in the tarball (not in a subdir). I suppose an option could be
> added to specify a subdir for it to change to.
> 
> Not sure I see the point of having pristine-tar make it all in one
> commit. It's not as if the history of the pristine-tar branch is
> something that is often, or ever, relevant.

gbp handles this since some time (creating one commit each per
tarball) so maybe this can be closes?
Cheers,
 -- Guido

Bug#870567: date: day sequence modifiers of month appear to be wrong

2017-08-02 Thread Bob Proulx

Dale Harris wrote:
> Package: coreutils
> Version: 8.26-3
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> 
> Just trying to figure out what the first, second, third days are of a month.
> 
> So for August 2017:
> 
> 
> August 2017
> Su Mo Tu We Th Fr Sa
>1 _2  34  5
>  6  7  8  9 10 11 12
> 13 14 15 16 17 18 19
> 20 21 22 23 24 25 26
> 27 28 29 30 31
> 
> 
> This is relative to:  Wed Aug  2 17:33:10 EDT 2017
> 
> If do:
> 
> date -d 'first monday', I get: Mon Aug  7 00:00:00 EDT 2017

The docs say:

The explicit mention of a day of the week will forward the date (only if
necessary) to reach that day of the week in the future.

   Days of the week may be spelled out in full: ‘Sunday’, ‘Monday’,
‘Tuesday’, ‘Wednesday’, ‘Thursday’, ‘Friday’ or ‘Saturday’.  Days may be
abbreviated to their first three letters, optionally followed by a
period.  The special abbreviations ‘Tues’ for ‘Tuesday’, ‘Wednes’ for
‘Wednesday’ and ‘Thur’ or ‘Thurs’ for ‘Thursday’ are also allowed.

   A number may precede a day of the week item to move forward
supplementary weeks.  It is best used in expression like ‘third monday’.
In this context, ‘last DAY’ or ‘next DAY’ is also acceptable; they move
one week before or after the day that DAY by itself would represent.

Therefore mentioning "1 Monday" (which is what "first monday" is
mapped to) will forward to one Monday in the future.  Okay.

> date -d 'second monday', I get: Mon Aug  7 00:00:01 EDT 2017

The word "second" is problematic.  The documentation says:

   A few ordinal numbers may be written out in words in some contexts.
This is most useful for specifying day of the week items or relative
items (see below).  Among the most commonly used ordinal numbers, the
word ‘last’ stands for -1, ‘this’ stands for 0, and ‘first’ and ‘next’
both stand for 1.  Because the word ‘second’ stands for the unit of time
there is no way to write the ordinal number 2, but for convenience
‘third’ stands for 3, ‘fourth’ for 4, ‘fifth’ for 5, ‘sixth’ for 6,
‘seventh’ for 7, ‘eighth’ for 8, ‘ninth’ for 9, ‘tenth’ for 10,
‘eleventh’ for 11 and ‘twelfth’ for 12.

The important part is:

Because the word ‘second’ stands for the unit of time
there is no way to write the ordinal number 2

That is why you can't say "second monday".  You can only use the
numbers and say "2 Monday".  (Don't shoot me.  I am only the
messenger.)

> date -d 'third monday', I get: Mon Aug 21 00:00:00 EDT 2017
> date -d 'fourth monday', I get: Mon Aug 28 00:00:00 EDT 2017
> date -d 'fifth monday', I get: Mon Sep  4 00:00:00 EDT 2017

All okay.

I want to note that the default date format for legacy reasons is
ambiguous.  It is better to use an unambiguous format such as date -R
which will specify the timezone in a standard format.

> So I'm a bit confused, if it's relative from the day, I could unstand the 
> first Monday being the 7th, but the second Monday should be the 14th. If it
> is inside the month, then this doesn't make any sense because the 7th is the
> first Monday of the month, and 14th the second. What am I missing?

If doing date calculations it is highly recommended to do them around
12:00 noon instead of midnight to avoid daylight saving time changes.
Let me specify a timezone explicitly here for the archive and
reproducibility of the case.

env TZ=US/Mountain date -R -d '1 monday 12:00'
Mon, 07 Aug 2017 12:00:00 -0600

env TZ=US/Mountain date -R -d '2 monday 12:00'
Mon, 14 Aug 2017 12:00:00 -0600

env TZ=US/Mountain date -R -d '3 monday 12:00'
Mon, 21 Aug 2017 12:00:00 -0600

env TZ=US/Mountain date -R -d '4 monday 12:00'
Mon, 28 Aug 2017 12:00:00 -0600

Or with with UTC instead.  Working with UTC is always recommended.

date -u -R -d '1 monday'
Mon, 07 Aug 2017 00:00:00 +

date -u -R -d '2 monday'
Mon, 14 Aug 2017 00:00:00 +

date -u -R -d '3 monday'
Mon, 21 Aug 2017 00:00:00 +

date -u -R -d '4 monday'
Mon, 28 Aug 2017 00:00:00 +

A reference to some of these problem areas.

https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

Hopefully this explains the problem.
Bob

Bug#870575: robotfindskitten: New upstream version: 2.7182818.701

2017-08-02 Thread Steve Pomeroy

Package: robotfindskitten
Version: 1.7320508.406-5+b1
Severity: normal

Dearest Esteemed Maintainer,

A new version of robotfindskitten awaits you in the off-world colonies.
Please send a self-addressed, stamped envelope to:

https://sourceforge.net/projects/rfk/

to retrieve a free game piece. Your mileage may vary. Please enter
2.7182818.701 at the prompt followed by the pound key. Past performance
is not indicative of future results.

Thank you and goodnight.

-Steve

Bug#870574: lowmem: naming of main-menu.d item

2017-08-02 Thread Vincent McIntyre

Package: lowmem
Version: 1.45
Severity: normal

Poking around an install environment I looked in /lib/main-menu.d
and found these files:
10rescue
5lowmem

Then I found the original commit message:

commit b9741a97a349f9ed4364b3411c3ab8afc590e385
Author: Joey Hess 
Date:   Fri May 6 01:30:00 2005

- Set a "low memory mode" info message (rescue mode comes after and
  beats this message). Requires cdebconf-udeb 0.75 and main-menu 1.03.

So the file lowmem/main-menu.d/5lowmem
should be   lowmem/main-menu.d/05lowmem

should it not?

Vince

Bug#870573: grap: please make the build reproducible

2017-08-02 Thread Chris Lamb

Source: grap
Version: 1.45-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: uname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that grap could not be built reproducibly as it includes the output
of `uname -sr` in the binary.

This results in a different checksum when built on, say i386 with
running a 686 kernel and running an an amd64 kernel (again, on
i386).

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb, Debian Project Leader
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build.patch   1969-12-31 19:00:00.0 
-0500
--- b/debian/patches/reproducible_build.patch   2017-08-02 20:05:34.337104563 
-0400
@@ -0,0 +1,16 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-08-02
+
+--- grap-1.45.orig/grap_parse.cc
 grap-1.45/grap_parse.cc
+@@ -877,8 +877,7 @@ void usage() {
+ }
+ 
+ inline void version() {
+-cout << "grap " << PACKAGE_VERSION << " compiled under " 
+-   << OS_VERSION << endl;
++cout << "grap " << PACKAGE_VERSION << endl;
+ cerr << "Fine comparsion limit: " << FINE_EPSILON << endl;
+ cerr << "Fine minimum value: " << FINE_MIN_DOUBLE << endl;
+ cerr << "Coarse comparsion limit: " << COARSE_EPSILON << endl;
--- a/debian/patches/series 1969-12-31 19:00:00.0 -0500
--- b/debian/patches/series 2017-08-02 20:05:33.233096268 -0400
@@ -0,0 +1 @@
+reproducible_build.patch

Bug#870448: hw-detect - stop using modprobe -l

2017-08-02 Thread Vincent McIntyre

On Wed, Aug 02, 2017 at 07:58:05PM +0100, Ben Hutchings wrote:
> 
> But this still prints error messages for missing modules.  I think the
> function should be implemented as:
> 
> is_available () {
>   modprobe -qn "$1"
> }
> 

I agreee, much better!

Bug#798476: Returning to the requirement that Uploaders: contain humans

2017-08-02 Thread Russ Allbery

Bill Allombert  writes:
> On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:

>> I've also included a purely informative change which emphasises that
>> packages that are team maintained in name only should be orphaned
>> properly, with their maintainer field set to the QA team.  This is
>> already current best practice, but it's worth emphasising, because one
>> might fail to orphan a package on the grounds that "someone else on the
>> team might fix it", which is not true of a lot of teams.

> You are omitting the case of a team which get reduced to a single
> member, in which case the package need not be orphaned. Yet it is
> important the fact is mentionned in the package.

I don't think I understand the objection.  Sean's proposed wording seems
fine for that case -- it just says that the package should be orphaned if
the team is not maintaining it, which shouldn't depend on the size of the
team.

-- 
Russ Allbery (r...@debian.org)

Bug#870522: [pkg-gnupg-maint] Bug#870522: gnupg1: Consider setting use-agent by default

2017-08-02 Thread Jeremy Bicha

On Wed, Aug 2, 2017 at 7:08 PM, Daniel Kahn Gillmor
 wrote:
> What do you think about this patch instead of your proposed patch?
> +opt.use_agent = 1;

Sure, that sounds great.

> The trouble, of course, is that now the gnupg1 package now effectively
> Depends: gpg-agent, which brings with it a bunch of other dependencies,
> which has historically caused a lot of grumbling.  Is it worthwhile to
> pay that price?

Since gnupg(2) already depends on gnupg-agent and we don't want to
give people a good reason to use gnupg1, I'm hoping it won't be a
problem.

> I don't want to spend a ton of time on gnupg1

Me either; that's why I filed this bug report so it will just autosync
to Ubuntu in the future. :)

Thanks,
Jeremy Bicha

Bug#870572: nvidia-legacy-340xx-driver: Trying to start xserver gives undefined symbol: miEmptyData

2017-08-02 Thread debian-bugs

Package: nvidia-legacy-340xx-driver
Version: 340.102-1
Severity: important

Hello,

xserver fails to start with the following in the log:
[ 16261.012] (II) Module glx: vendor="NVIDIA Corporation"
[ 16261.013]compiled for 4.0.2, module version = 1.0.0
[ 16261.013]Module class: X.Org Server Extension
[ 16261.013] (II) NVIDIA GLX Module  340.102  Mon Jan 16 12:37:38 PST 2017
[ 16261.013] (II) LoadModule: "nvidia"
[ 16261.013] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[ 16261.013] (EE) Failed to load /usr/lib/xorg/modules/drivers/nvidia_drv.so: 
/usr/lib/xorg/modules/drivers/nvidia_drv.so: undefined symbol: miEmptyData
[ 16261.013] (II) UnloadModule: "nvidia"
[ 16261.013] (II) Unloading nvidia
[ 16261.013] (EE) Failed to load module "nvidia" (loader failed, 7)

Recently upgraded to Debian Stretch, used the proprietary nvidia installer in 
the past.  If I remember correctly there was not a Debian package that worked 
for my card in the past.  I am pretty sure I removed all the prior Debian 
installer stuff, the cleanup had an issue but I re-ran the install --uninstall 
and it seemed to work, purged all my nvidia related packaged and installed 
nvidia-legacy-340xx-driver.  Now I get this error.

-- Package-specific info:
uname -a:
Linux speedy 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 
GNU/Linux

/proc/version:
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.102  Mon Jan 16 13:06:29 
PST 2017
GCC version:  gcc version 6.3.0 20170516 (Debian 6.3.0-18) 

lspci 'VGA compatible controller [0300]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 8600 
GTS] [10de:0400] (rev a1) (prog-if 00 [VGA controller])
Subsystem: eVga.com. Corp. G84 [GeForce 8600 GTS] [3842:c773]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw 1 root video 226, 0 Aug  2 17:47 /dev/dri/card0
video:x:44:gokee2,mythtv,guest

OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 2313 Jun 11  2015 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root   15 Aug  2 17:39 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   42 Aug  2 17:39 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   44 Aug  2 17:39 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   48 Aug  2 17:39 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Aug  2 17:39 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   41 Aug  2 17:39 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Aug  2 17:39 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Aug  2 17:39 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Aug  2 17:39 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   48 Aug  2 17:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   48 Aug  2 17:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Aug  2 17:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Aug  2 17:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   45 Aug  2 17:39 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   45 Aug  2 17:39 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   47 Aug  2 17:39 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   47 Aug  2 17:39 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   49 Aug  2 17:39

Bug#870522: [pkg-gnupg-maint] Bug#870522: gnupg1: Consider setting use-agent by default

2017-08-02 Thread Daniel Kahn Gillmor

Hi Jeremy--

On Wed 2017-08-02 15:29:06 -0400, Jeremy Bicha wrote:
> I believe Ubuntu's gnupg1 packaging has only one change from Debian:
> uncomment 'use-agent' in g10/options.skel. I believe using the agent
> is the default in gnupg2 anyway. Please consider applying the change.

options.skel is a bad habit in general, and the default on the
actively-maintained upstream branch (2.1) is to not ship options.skel at
all and to just have sensible defaults that work for people.

https://dev.gnupg.org/T3086

So while the proposed patch below is probably not wrong, a better patch
would change the default itself.

And even better would be to continue deprecating gnupg1 and make sure
it's not in use anywhere so that people don't get confused by an
options.skel that they don't need.

What do you think about this patch instead of your proposed patch?

diff --git a/g10/gpg.c b/g10/gpg.c
index 416d44e98..639503f9c 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -1917,6 +1917,7 @@ main (int argc, char **argv )
 set_homedir ( default_homedir () );
 opt.passwd_repeat=1;
 opt.emit_version = 0;
+opt.use_agent = 1;

 #ifdef ENABLE_CARD_SUPPORT
 #if defined(_WIN32) || defined(__CYGWIN__)

and now if people want to avoid that setting, they need to add
no-use-agent to their gpg.conf

The trouble, of course, is that now the gnupg1 package now effectively
Depends: gpg-agent, which brings with it a bunch of other dependencies,
which has historically caused a lot of grumbling.  Is it worthwhile to
pay that price?

I don't want to spend a ton of time on gnupg1, so i'm not going to spin
this into a drawn out discussion, but i'm just laying out some of the
potential issues in making this decision.

Regards,

--dkg

signature.asc
Description: PGP signature

Bug#870388: closed by Niels Thykier <ni...@thykier.net> (Bug#870339: fixed in debhelper 10.7.2)

2017-08-02 Thread Andreas Beckmann

Is there an easy way to request give-back for all the corresponding
failed builds?


Andreas

Bug#865855: [PKG-Openstack-devel] Bug#865855: Bug#865855: Any news on python3 support for tablib?

2017-08-02 Thread Ondrej Novy

Hi,

2017-07-27 18:37 GMT-04:00 Thomas Goirand :

> Not only you should NMU the package, but you should as well take it
> over. It is indeed not used by OpenStack anymore, and therefore, the
> team has no interest in it anymore. Ondrej, can you confirm this fact?
>

as Thomas wrote. Feel free to adopt this package and move it to other team
(DPMT, collab, ...).

Thanks.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#258392: #258392 lftp should support encrypted passwords in bookmarks

2017-08-02 Thread Noël Köthe

tags 258392 + upstream
forwarded 258392 https://github.com/lavv17/lftp/issues/373
thanks

Hello,

it was forwarded and discussed on the mailinglist

https://www.mail-archive.com/lftp-devel@uniyar.ac.ru/msg01403.html 

but in the bugtracker it will not get lost.;)

Regards

Noel

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

Bug#870571: ITP: avro-c -- Apache Avro C

2017-08-02 Thread Robert Edmonds

Package: wnpp
Severity: wishlist
Owner: Robert Edmonds 

* Package name: avro-c
  Version : 1.8.2
  Upstream Author : The Apache Software Foundation
* URL : http://avro.apache.org/
* License : Apache-2.0
  Programming Lang: C
  Description : Apache Avro C (avro-c) library

 Apache Avro is a data serialization system. Avro provides rich data
 structures; a binary data format; and a container file format, to store
 Avro-encoded data persistently.
 .
 This package provides the "avro-c" implementation of Apache Avro in C.
 The C implementation supports:
 .
  * binary encoding/decoding of all primitive and complex data types
  * storage to an Avro Object Container File
  * schema resolution, promotion and projection
  * validating and non-validating mode for writing Avro data
 .
 The C implementation of Avro lacks RPC support.

-- 
Robert Edmonds
edmo...@debian.org


signature.asc
Description: PGP signature

1 2 3 >

1 - 100 of 272 matches

Mail list logo