Bug#819703: fork the code to alioth, and point all reference/email to there

[Marc Haber]

On Wed, Apr 06, 2016 at 01:04:59AM +0800, Sharuzzaman Ahmat Raslan wrote:
> Maybe debian-screensaver is a good choice of name.

I disagree. That would suggest that we endorse this and consider this
the canonical screensaver to use in Debian, while the opposite is
actually the case.

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#782171: Benchmark of linux and chromium

[Orestis Ioannou]

Heya,

So here are also some benchmarks, running sloccount and cloc on linux
and chromium.
(I had to run latest cloc from github because the one in testing has an
older release that affects chromium :D )

- time sloccount --addlangall linux-4.4.6

Totals grouped by language (dominant language first):
ansic: 13550489 (96.81%)
asm: 283173 (2.02%)
xml:  49474 (0.35%)
perl: 46694 (0.33%)
makefile: 33142 (0.24%)
sh:   10942 (0.08%)
python:9705 (0.07%)
cpp:   5289 (0.04%)
yacc:  4357 (0.03%)
lex:   2340 (0.02%)
awk:   1128 (0.01%)
pascal: 231 (0.00%)
lisp:   218 (0.00%)

19.34s user 
16.49s system 
49% cpu 
1:12.70 total


- time cloc-1.66.pl --by-file-by-lang -csv linux-4.4.6

files,language,blank,comment,code
22558,C,2217923,2064183,11330129
17092,C/C++ Header,416288,713217,2673966
1412,Assembly,47490,110738,242086
175,XML,3419,242,49467
202,Perl,9200,7412,46189
2105,make,8945,8950,41290
173,Bourne Shell,1769,3161,9650
55,Python,1765,1532,9606
8,yacc,649,355,4357
8,lex,292,289,1823
51,Bourne Again Shell,338,261,1580
1,C++,231,58,1579
10,awk,132,129,1130
3,NAnt script,130,0,462
2,HTML,58,0,378
3,Pascal,49,0,231
1,Lisp,63,0,218
1,Objective C++,55,0,189
1,m4,15,1,95
6,XSLT,13,27,71
1,vim script,3,12,27
1,Windows Module Definition,0,0,8

159.95s user 
21.10s system 
81% cpu 
3:40.93 total

- sloccount --addlangall chromium-browser-49.0.2623.108

Totals grouped by language (dominant language first):
cpp:   11192924 (61.48%)
ansic:  3524388 (19.36%)
xml:1209320 (6.64%)
python: 1063920 (5.84%)
asm: 605129 (3.32%)
java:368846 (2.03%)
sh:   89957 (0.49%)
perl: 73187 (0.40%)
makefile: 31024 (0.17%)
objc: 14698 (0.08%)
tcl:  11315 (0.06%)
yacc:  9847 (0.05%)
sql:   2765 (0.02%)
cs:2696 (0.01%)
lex:   2259 (0.01%)
pascal:1288 (0.01%)
lisp:  1247 (0.01%)
awk:497 (0.00%)
ruby:   141 (0.00%)
sed: 37 (0.00%)
php: 15 (0.00%)
exp: 11 (0.00%)

38.30s user 
51.66s system 
48% cpu 
3:04.32 total


- time cloc-1.66.pl --by-file-by-lang -csv chromium-browser-49.0.2623.108

files,language,blank,comment,code
38879,C++,1557112,1181535,9426443
7805,C,470331,567084,2890280
34270,C/C++ Header,762796,1223172,2851525
891,XML,23141,9541,1208785
3607,JavaScript,138882,305771,1044159
7693,Python,282771,400973,1027855
7577,HTML,121950,56773,973780
1878,JSON,1660,0,931914
790,Assembly,46770,43471,628908
2789,Java,71969,112496,368684
1620,Objective C++,51254,40610,237545
630,Bourne Shell,28007,29811,166525
1338,IDL,9829,0,79835
854,CSS,14833,7664,75294
131,Perl,11888,12271,73313
91,MSBuild script,0,35,59338
102,m4,5389,946,49070
371,make,5047,5361,24735
33,Go,2316,1788,15386
46,Tcl/Tk,1393,2597,11335
240,Protocol Buffers,4128,9532,11180
113,Objective C,2588,2162,10431
177,CMake,1798,1215,8558
7,yacc,1170,955,8068
45,Windows Module Definition,82,126,5960
24,XSLT,895,1191,4092
106,Bourne Again Shell,776,1453,3987
60,DOS Batch,519,467,2894
97,SQL,111,171,2740
35,C#,474,1079,2677
29,Lua,458,259,2386
45,Windows Resource File,553,1200,2078
4,XSD,184,1133,1898
19,diff,73,400,1745
52,YAML,256,332,1724
9,Cython,459,220,1657
4,lex,262,116,1394
16,MATLAB,218,188,1031
10,Lisp,147,165,1025
21,XHTML,13,14,944
10,HLSL,161,138,690
38,Jam,231,513,682
8,Expect,21,87,652
12,Ant,114,290,635
8,Pascal,167,1575,602
1,WiX source,80,59,515
8,awk,70,131,503
14,Ruby,59,81,309
8,vim script,75,112,264
2,Racket,17,51,255
4,DTD,44,166,245
1,Korn Shell,39,46,223
4,XAML,30,50,90
4,Standard ML,9,0,61
4,Groovy,17,96,57
4,PHP,9,0,54
9,Verilog-SystemVerilog,0,0,52
4,sed,12,21,38
1,R,5,5,37
1,Prolog,1,-1,32
1,Swift,2,0,7

297.78s user 
100.08s system 
69% cpu 
9:34.93 total


signature.asc
Description: PGP signature

Bug#820169: python-reportlab: please honour SOURCE_DATE_EPOCH

[boyska]

Package: python-reportlab
Version: 3.3.0-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain timestamps

Hi,
While working on the “reproducible builds” effort [1], we have noticed that
reportlab embeds current timestamp in the generated PDF. This behavior make
packages whose documentation is generated with reportlab unreproducible.

The attached patch fixes this behavior honoring the SOURCE_DATE_EPOCH [2]
environment variable.

[1] https://wiki.debian.org/ReproducibleBuilds
[2] https://reproducible-builds.org/specs/source-date-epoch/
Description: Honour SOURCE_DATE_EPOCH environment variable
 If the SOURCE_DATE_EPOCH environment variable is set, reportlab will use
 it instead of the current timestamp.
 See https://reproducible-builds.org/specs/source-date-epoch/
 .
 python-reportlab (3.3.0-1.0~reproducible1) UNRELEASED; urgency=medium
 .
   * Honour SOURCE_DATE_EPOCH, to generate PDFs reproducibly
Author: boyska 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 

--- python-reportlab-3.3.0.orig/src/reportlab/pdfbase/pdfdoc.py
+++ python-reportlab-3.3.0/src/reportlab/pdfbase/pdfdoc.py
@@ -1730,8 +1730,12 @@ _NOWT=None
 def _getTimeStamp():
 global _NOWT
 if not _NOWT:
-import time
-_NOWT = time.time()
+import os
+if 'SOURCE_DATE_EPOCH' in os.environ:
+_NOWT = float(os.environ['SOURCE_DATE_EPOCH'])
+else:
+import time
+_NOWT = time.time()
 return _NOWT
 
 class PDFDate(PDFObject):

Bug#800278: sawfish-merlin-ugliness: Please migrate a supported debhelper compat level

[Logan Rosen]

Package: sawfish-merlin-ugliness
Version: 1.3.1-1
Followup-For: Bug #800278
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

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

  * debian/compat: Change compatibility level to 9.
  * debian/control:
- Build-depend on debhelper (>= 9).
- Depend on ${misc:Depends}.
  * debian/rules: Use dh_prep instead of dh_clean -k.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.4.0-16-generic (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)
diff -u sawfish-merlin-ugliness-1.3.1/debian/control sawfish-merlin-ugliness-1.3.1/debian/control
--- sawfish-merlin-ugliness-1.3.1/debian/control
+++ sawfish-merlin-ugliness-1.3.1/debian/control
@@ -3,11 +3,11 @@
 Priority: extra
 Maintainer: Christian Marillat 
 Standards-Version: 3.6.1
-Build-Depends: debhelper (>= 3.4.4)
+Build-Depends: debhelper (>= 9)
 
 Package: sawfish-merlin-ugliness
 Architecture: all
-Depends: sawfish
+Depends: ${misc:Depends}, sawfish
 Conflicts: sawfish (<= 0.37.2-1), sawfish-gnome (<= 0.37.2-1)
 Description: More flexible functions for sawfish
  Gives flexibility over the appearance of the popup window when you
diff -u sawfish-merlin-ugliness-1.3.1/debian/rules sawfish-merlin-ugliness-1.3.1/debian/rules
--- sawfish-merlin-ugliness-1.3.1/debian/rules
+++ sawfish-merlin-ugliness-1.3.1/debian/rules
@@ -14,7 +14,7 @@
 install:
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs usr/share/sawfish/site-lisp/merlin etc/X11/sawfish/site-init.d
 
 	cp ugli*.jl debian/sawfish-merlin-ugliness/usr/share/sawfish/site-lisp/merlin
diff -u sawfish-merlin-ugliness-1.3.1/debian/compat sawfish-merlin-ugliness-1.3.1/debian/compat
--- sawfish-merlin-ugliness-1.3.1/debian/compat
+++ sawfish-merlin-ugliness-1.3.1/debian/compat
@@ -1 +1 @@
-3
+9

Bug#800304: libproc-syncexec-perl: Please migrate a supported debhelper compat level

[Logan Rosen]

Package: libproc-syncexec-perl
Version: 1.01-1.1
Followup-For: Bug #800304
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

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

  * debian/rules:
- Remove legacy DH_COMPAT export.
- Use dh_prep instead of dh_clean -k.
- Add recommended build-arch and build-indep targets.
  * debian/compat: Indicate compatibility level of 9.
  * debian/control:
- Build-depend on debhelper (>= 9).
- Depend on ${misc:Depends}.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.4.0-16-generic (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)
diff -u libproc-syncexec-perl-1.01/debian/control libproc-syncexec-perl-1.01/debian/control
--- libproc-syncexec-perl-1.01/debian/control
+++ libproc-syncexec-perl-1.01/debian/control
@@ -3,11 +3,11 @@
 Priority: optional
 Maintainer: Roderick Schertler 
 Standards-Version: 3.5.2
-Build-Depends: debhelper (>= 3.0.5), perl (>= 5.6.0-16)
+Build-Depends: debhelper (>= 9), perl (>= 5.6.0-16)
 
 Package: libproc-syncexec-perl
 Architecture: all
-Depends: ${perl:Depends}
+Depends: ${misc:Depends}, ${perl:Depends}
 Description: spawn processes but report exec() errors properly
  This Perl module contains functions for synchronized process spawning
  with full error return.  If the child's exec() call fails the reason
diff -u libproc-syncexec-perl-1.01/debian/rules libproc-syncexec-perl-1.01/debian/rules
--- libproc-syncexec-perl-1.01/debian/rules
+++ libproc-syncexec-perl-1.01/debian/rules
@@ -11,10 +11,11 @@
 ifneq "" "$(findstring debug,$(DEB_BUILD_OPTIONS))"
 CFLAGS		+= -g
 endif
-export DH_COMPAT	:= 3
 PERL			?= perl
 
-build: $(stamp_build)
+build: build-arch build-indep
+build-arch: $(stamp_build)
+build-indep: $(stamp_build)
 $(stamp_build):
 	dh_testdir
 	$(PERL) Makefile.PL INSTALLDIRS=vendor
@@ -26,7 +27,7 @@
 $(stamp_install): $(stamp_build)
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 	$(MAKE) install DESTDIR=$(prefix)
 	find $(prefix) -depth -type d -print0 | \
only in patch2:
unchanged:
--- libproc-syncexec-perl-1.01.orig/debian/compat
+++ libproc-syncexec-perl-1.01/debian/compat
@@ -0,0 +1 @@
+9

Bug#812652: horae: FTBFS - Can't locate Module/Build.pm

[Logan Rosen]

Package: horae
Version: 071~svn537-2
Followup-For: Bug #812652
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

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

  * Build-depend on libmodule-build-perl to fix FTBFS.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.4.0-16-generic (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)
diff -Nru horae-071~svn537/debian/control horae-071~svn537/debian/control
--- horae-071~svn537/debian/control	2015-01-10 20:53:03.0 +
+++ horae-071~svn537/debian/control	2016-04-06 05:19:01.0 +
@@ -4,7 +4,8 @@
 Maintainer: Carlo Segre 
 Build-Depends: debhelper (>= 7)
 Build-Depends-Indep: perl (>= 5.6.0-16), libchemistry-elements-perl, 
- perl-tk (>= 804), libifeffit-perl, libpod-latex-perl
+ perl-tk (>= 804), libifeffit-perl, libpod-latex-perl,
+ libmodule-build-perl
 Homepage: http://cars9.uchicago.edu/~ravel/software/Welcome.html
 Standards-Version: 3.9.6
 

Bug#820168: debian-installer: The Grub installation step in Debian Testing Installer fails on Gigabyte MP30-AR0

[Ronald Maas]

Package: debian-installer
Version: Debian Testing
Severity: important
Tags: d-i

Description of problem:

The Grub installation step in Debian Installer failed on TianoCore
UEFI firmware. The /target/boot/efi directory is empty and the
following error is displayed:

GRUB installation failed
The 'grub-efi-arm64' package failed to install into /target/

Version-Release number of selected component (if applicable):

Debian Testing DVD ISO dated 28-03-2016

How reproducible:

Every time.

Steps to Reproduce:

1. Download 
http://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-dvd/debian-testing-arm64-DVD-1.iso
2. Verify checksum
3. Copy to USB drive using Windows Win32DiskImager
4. Insert drive in X-Gene system
5. Boot X-Gene system
6. Navigate to UEFI Shell
7. Enter the following command to start the Fedora installer:
   FS1:\EFI\BOOT\BOOTAA64.EFI
8. In the Grub boot menu select the first menu option and hit enter
9. Proceed through the remaining steps of the setup procedure. Selecting 
default options where applicable. Note on the MP30-AR0 the network is not 
function (see bug report 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820022. So skip this step to 
continue
10. After the GRUB installation step fails, continue without bootloader and 
reboot
11. System fails to boot Debian Testing and starts the UEFI Shell instead

Actual results:

No GRUB bootloader is installed. After restarting the system, no 'debian' menu 
entry is visible in UEFI and the /boot/efi directory is empty

Expected results:

To be able to boot Debian Testing after selecting the 'debian' menu entry in 
UEFI. Also /boot/efi should contain EFI/debian/grubaa64.efi

Additional info:

Hardware
Gigabyte MP30-AR0 motherboard with APM X-Gene 1 processor flashed with 
TianoCore UEFI
Kingston KVR16LE11S8/4HB 16 GB ECC DDR3 DRAM
HGST Deskstar NAS 6 TB hard drive
Logitech USB keyboard

The standard U-Boot firmware has been replaced by TianoCore UEFI using the 
steps described in: 
https://rwmj.wordpress.com/2016/03/08/gigabyte-mp30-ar0-flashing-uefi/

Bug#531885: No longer present

[Paul Wise]

Control: fixed -1 0.203

On Tue, 2016-04-05 at 18:42 +0100, James Clarke wrote:

> Since pbuilder 0.203,

Please do a versioned close next time, I set fixed with this mail.

Thanks for the fix :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#820167: syslinux-efi: Kernel does not boot on Gigabyte MP30-AR0 system (APM X-Gene 1)

[Ronald Maas]

Package: syslinux-efi
Version: 8.4
Severity: grave
Tags: d-i
Justification: renders package unusable

Description of problem:

The Kernel does not boot after I select applicable option in the Debian 
Installer Grub boot menu.

Version-Release number of selected component (if applicable):

Debian 8.4 arm64

How reproducible:

Every time.

Steps to Reproduce:

1. Download 
http://cdimage.debian.org/debian-cd/8.4.0/arm64/iso-cd/debian-8.4.0-arm64-netinst.iso
2. Verify checksum
3. Copy to USB drive using Windows Win32DiskImager
4. Insert drive in X-Gene system
5. Boot X-Gene system
6. Navigate to UEFI Shell
7. Enter the following command to start the Fedora installer:
   FS1:\EFI\BOOT\BOOTAA64.EFI
8. In the Grub boot menu select the first menu option and hit enter
9. System hangs

The boot issue was not resolved after I restarted the system and added the 
following kernel parameter: console=ttyS0,115200

Actual results:

The following is displayed on the serial console:

EFI stub: Booting Linux Kernel...
L3c Cache: 8MB

Systems hangs and needs to be rebooted.

Expected results:

First screen of Debian Installer on either VGA or serial console.

Additional info:

Hardware
Gigabyte MP30-AR0 motherboard with APM X-Gene 1 processor flashed with 
TianoCore UEFI
Kingston KVR16LE11S8/4HB 16 GB ECC DDR3 DRAM
HGST Deskstar NAS 6 TB hard drive
Logitech USB keyboard

The standard U-Boot firmware has been replaced by TianoCore UEFI using the 
steps described in: 
https://rwmj.wordpress.com/2016/03/08/gigabyte-mp30-ar0-flashing-uefi/

Both Centos 7.2 and Debian Testing were successfully installed on this system 
and running stable.


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

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

Bug#816440: openjdk-9-jdk: file conflict jawt.h

[Tianon Gravi]

On Tue, 1 Mar 2016 12:44:41 -0800 Joseph Ferguson  wrote:
> Here is the truncated output of "apt-get install openjdk-9-jdk":
> Unpacking openjdk-9-jdk:amd64 (9~b107-1) ...
> dpkg: error processing archive
> /var/cache/apt/archives/openjdk-9-jdk_9~b107-1_amd64.deb (--unpack):
> trying to overwrite
> '/usr/lib/jvm/java-9-openjdk-amd64/include/jawt.h', which is also in
> package openjdk-9-jdk-headless:amd64 9~b107-1

It looks like the conflict on "jawt.h" is fixed, but a new one on
"jawt_md.h" is being hit:

| Unpacking openjdk-9-jdk:amd64 (9~b112-2) ...
| dpkg: error processing archive
/var/cache/apt/archives/openjdk-9-jdk_9~b112-2_amd64.deb (--unpack):
|  trying to overwrite
'/usr/lib/jvm/java-9-openjdk-amd64/include/linux/jawt_md.h', which is
also in package openjdk-9-jdk-headless:amd64 9~b112-2

It looks like 
https://sources.debian.net/src/openjdk-9/9~b107-1/debian/rules/#L1809
needs something like "|*/jawt_md.h" added to the case in order to
account for "echo '$(basedir)/include/*/jawt_md.h'; \" in the section
below.

I've attached a patch against 9~b112-2 (current version in
experimental) which is a more concrete explanation of what I think
will fix the issue, but I haven't had a chance to test it.

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
diff --git a/debian/rules b/debian/rules
index 854ddc6..8aff450 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1806,7 +1806,7 @@ endif
 	  done; \
 	  cd $(d); \
 	  for i in $(basedir)/include/*.h; do \
-	case $$i in */jawt.h) continue; esac; \
+	case $$i in */jawt.h|*/jawt_md.h) continue; esac; \
 	[ -h $$i ] && continue; \
 	echo $$i; \
 	  done; \

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Juho]

Most likely the kernel.  However, I can't see any obviously relevant
changes.  What does this command show:

    ls -l /sys/class/input/mouse*/device/device/driver


-- $ ls -l /sys/class/input/mouse*/device/device/driver
lrwxrwxrwx 1 root root 0 Apr  6 06:34 
/sys/class/input/mouse0/device/device/driver -> 
../../../../bus/serio/drivers/psmouse
lrwxrwxrwx 1 root root 0 Apr  6 06:34 
/sys/class/input/mouse1/device/device/driver -> 
../../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx 1 root root 0 Apr  6 06:34 
/sys/class/input/mouse2/device/device/driver -> 
../../../../../../../../bus/hid/drivers/hid-multitouch



$ sudo modprobe -r psmouse
$ sudo modprobe psmouse

Makes it "work" again. ...


I also confirm that
sudo modprobe -r psmouse && sudo modprobe psmouse
works and after that command the touch-pad is working.


Magic key-codes, send a key code every 2s or some such to indicate
laptop unfold angle, such that when it's beyond 180 open the keycodes
spam stops and thus OS should turn off keyboard and touchpad because
it's now in "tablet" mode. It folds all the way out.


I also have magic codes:
[  386.645269] atkbd serio0: Unknown key released (translated set 2, 
code 0xbe on isa0060/serio0).
[  386.645281] atkbd serio0: Use 'setkeycodes e03e ' to make it 
known.


But these magic codes did appear also pre 8.4 time.

I also tried reverting back to linux-image-3.16.0-4-amd64 ckt20-1+deb8u4 
but that did not help.


I have Yoga 13 non-Pro model.

--
Juho

Bug#819703: Please fix stable version 5.30-1

[Jamil Said Jr .]

Dear Tormod,

I read your email and my understanding is that only the unstable version
5.34 and beyond will be fixed? What about the stable version 5.30? Can you
also fix that?

I would be very disappointed if the stable version is not fixed. I work a
lot with people with low computer skills, most of which are also in the
lower income brackets. Many depend on Debian stable on a day by day basis. I
spent an innumerable amount of hours educating people about stable branches,
and how to update via a conservative apt-get update. Those people will stay
with their computers for a large number of years, and they don't have a clue
about backports. 

I think it would be a very bad decision to leave people being pestered for
years by this rude, disruptive and disingenuous warning. Yes, it is
disingenuous, because it says "If this is the latest version that your
distro ships, then your distro is doing you a disservice." - this statement
is false, because using old versions (stable branches) have pros and cons,
and may be ideal to many people and situations (I almost always use and
recommend stable, and in 2013 NASA chose stable of Debian 6 instead of
stable Debian 7 for the ISS astronaut's laptops, tell me about using older
versions for stability). Also, this warning unjustly denigrates Debian and
will confuse and scare many.

I thus ask you to reconsider and fix this issue on the stable version as
well. It could be done as a security fix, perhaps? The rationale is that the
warning is disingenuous and contains inaccurate information (i.e.: that
using older versions is a disservice). Please don't let this thing hanging
out there, I know that many people will have to deal with this annoyance for
years, and that really undermines the trust and goodwill that this people
have on Debian (and Linux in general). 

I hope you will reconsider, in case there are no plans to fix stable.

Respectfully,
Jamil Said

PS: Santiago, gracias amigo! I will look into the info you provided me.

Bug#818244: Request to close

[Erik Haller]

This bug is caused by xfce4. I removed the config files under ~/.config and
the desktop images appeared and the dimming went away. The dimming was
probably caused by a lack of a desktop image on the second monitor.

The missing desktop images was caused by a change in the
/home//.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml.
Before the upgrade, xfce4 was using the monitorDVI-0 and monitorDVI-1
sections. After the xserver-xorg package upgraded, xfce4 started using the
monitor0 and monitor1 sections. These sections did not use my desktop
background images. For some reason, xfce4 is working differently after the
xserver-xorg upgrade.

The xrandr shows two monitors DVI-0/DVI-1 before and after the upgraded. I
do not understand why xfce4 switched from monitorDVI-0|1 to monitor0|1.

Perhaps this bug should be moved to xfce4?

I am using the latest xfce4 at 4.12.2.

Bug#820166: RFP: librejs-cli -- command line tool for GNU LibreJS

[Paul Wise]

Package: wnpp
Severity: wishlist
User: check-all-the-thi...@packages.debian.org
Usertags: new-check
Control: affects -1 check-all-the-things

* Package name: librejs-cli
  Upstream Author : Nik Nyby
* URL : https://github.com/nikolas/librejs-cli
* License : GPL-3.0+
  Programming Lang: JavaScript
  Description : command line tool for GNU LibreJS

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#820165: RFS: libretro-genesisplusgx/1.7.4+git20160330 [ITP]

[Sérgio Benjamim]

Package: sponsorship-requests
Severity: wishlist

Hey dear mentors!

I'm looking for a sponsor for my package "libretro-genesisplusgx"

Genesis Plus GX is a Sega 8/16-bit emulator focused on accuracy
and portability.

The source code, originally based on Genesis Plus 1.3 by Charles MacDonald,
has been heavily modified & enhanced, with respect to initial goals
and design, in order to improve the accuracy of emulation, implementing
new features and adding support for extra peripherals,cartridge & systems
hardware.

The result is that Genesis Plus GX is now more a continuation of the
original project than a simple port, providing very accurate emulation
and 100% compatibility with Genesis / Mega Drive, Sega/Mega CD,
Master System, Game Gear & SG-1000 released software (including all
unlicensed or pirate known dumps), also emulating backwards compatibility
modes when available.


* Package name : libretro-genesisplusgx
  Version  : 1.7.4+git20160330

  Upstream Author  : Charles MacDonald / Eke-Eke 

* URL  : https://github.com/ekeeke/Genesis-Plus-GX
* License  : non-commercial/MAME
  Programming Lang : C
  Description  : Genesis/Mega Drive, Sega/Mega CD, Master System, Game Gear 
and SG-1000 emulator


It builds those binary packages:

libretro-genesisplusgx - Libretro wrapper for Genesis Plus GX



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

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


More information about RetroArch and the libretro API can be obtained from 
http://www.libretro.com/index.php/api/

--
Sérgio Benjamim

Bug#820163: mh_resolve_dependencies exception when run with --non-interactive

[Christopher Hoskin]

Package: maven-debian-helper
Version: 2.0.6
Severity: normal

Dear Maintainer,

mh_resolve_dependencies throws an exception when run with the --non-interactive 
option, unless --no-parent has been set for the pom in debian/.poms

e.g.

~/java/drools-6.3.0$ mh_resolve_dependencies --non-interactive --verbose
dh_listpackages: cannot read debian/control: No such file or directory

Analysing pom.xml...
> dpkg --search /usr/share/maven-repo/org/kie/kie-parent-with-dependencies/*/* 
dpkg failed to execute successfully
> apt-file search /usr/share/maven-repo/org/kie/kie-parent-with-dependencies 
Apr 06, 2016 3:30:12 AM org.debian.maven.packager.DependenciesSolver 
resolveDependencies
SEVERE: Error while resolving ./pom.xml: Dependency not found 
org.kie:kie-parent-with-dependencies:pom:6.3.0.Final
Apr 06, 2016 3:30:12 AM org.debian.maven.packager.DependenciesSolver 
resolveDependencies
SEVERE: 
org.debian.maven.repo.DependencyNotFoundException: Dependency not found 
org.kie:kie-parent-with-dependencies:pom:6.3.0.Final
at 
org.debian.maven.packager.DependenciesSolver.resolveDependency(DependenciesSolver.java:760)
at 
org.debian.maven.packager.DependenciesSolver.resolveDependencies(DependenciesSolver.java:306)
at 
org.debian.maven.packager.DependenciesSolver.solveDependencies(DependenciesSolver.java:261)
at 
org.debian.maven.packager.DependenciesSolver.main(DependenciesSolver.java:960)

(Similar behaviour has been seen running mh_resolve_dependencies in 
non-interactive mode on other packages)

The underlying problem appears to be that the askIgnoreDependency in 
maven-packager-utils/src/main/java/org/debian/maven/packager/util/IgnoreDependencyQuestions.java
 will always return false in non-interactive mode.

My suggested fix would be that askIgnoreDependency should return 
defaultToIgnore in non-interactive mode (i.e. true in this case) which is what 
I would consider to be the expected behaviour.

Thanks.

Christopher Hoskin

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

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

Versions of packages maven-debian-helper depends on:
ii  default-jdk 2:1.8-57
ii  libmaven-clean-plugin-java  2.5-1
ii  libmaven-compiler-plugin-java   3.2-5
ii  libmaven-jar-plugin-java2.4-1
ii  libmaven-resources-plugin-java  2.6-1
ii  libmaven-site-plugin-java   2.1-4
ii  libplexus-velocity-java 1.1.8-1
ii  libsurefire-java2.17-2
ii  libxml2-utils   2.9.3+dfsg1-1
ii  maven   3.3.9-3
ii  maven-repo-helper   1.8.12
ii  unzip   6.0-20
ii  velocity1.7-4

maven-debian-helper recommends no packages.

Versions of packages maven-debian-helper suggests:
ii  apt-file  2.5.5
ii  devscripts2.16.2
pn  libmaven-javadoc-plugin-java  
ii  subversion1.9.3-3

-- no debconf information

Bug#820162: w3m: SEGFAULT on bogus HTML

[Steve Kemp]

Package: w3m
Version: 0.5.3-19
Severity: important
Tags: security

Dear Maintainer,

Please find attached a tarball which contains two files, a generated
one, and one which has been reduced to the smallest possible test-case.
Each of those files causes w3m to segfault when run as follows:

   cat $file | w3m -dump

The crash is a segfault, which is probably not exploitable but may
be to somebody who puts in more effort than I did!

On the face of it this is a minor/normal bug, until you consider
the case of users who run mutt and use w3m to convert HTML emails
to plaintext, that situation is common and as such I've raised the severity.

The crash is in some horrible code which is converting the file
to UTF-8, as the following backtrace shows:

(gdb) bt
#0  wc_any_to_ucs (cc=...) at ucs.c:274
#1  0x0070d73a in wc_push_to_utf8 (os=os@entry=0xed8940, cc=...,
st=st@entry=0x7fff11c174c0) at utf8.c:276
#2  0x006d4b9b in wc_conv_to_ces (ces=0, is=0xed8960) at conv.c:93
#3  wc_Str_conv (is=is@entry=0xed8960, f_ces=,
t_ces=t_ces@entry=3178565) at conv.c:23
#4  0x004ba1ea in _saveBuffer (buf=buf@entry=0xed9e00, l=0xeddf60,
f=0x7efc1c5ce2a0 <_IO_2_1_stdout_>, cont=cont@entry=0) at file.c:7595
#5  0x004ba726 in saveBuffer (buf=buf@entry=0xed9e00,
f=, cont=cont@entry=0) at file.c:7613
#6  0x00414ec2 in do_dump (buf=0xed9e00) at main.c:1337
#7  0x00407b25 in main (argc=-1, argv=0xed8a00, envp=0x8800)
at main.c:1043


Mitigating factors?  Interestingly the following does NOT crash:

   w3m -dump $file

Steve
--
https://www.steve.org.uk/


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

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

Versions of packages w3m depends on:
ii  libc62.19-18+deb8u3
ii  libgc1c2 1:7.2d-6.4
ii  libgpm2  1.20.4-6.1+b2
ii  libssl1.0.0  1.0.1k-3+deb8u4
ii  libtinfo55.9+20140913-1+b1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages w3m recommends:
ii  ca-certificates  20141019+deb8u1

Versions of packages w3m suggests:
pn  cmigemo   
ii  man-db2.7.0.2-5
ii  mime-support  3.58
pn  w3m-el
pn  w3m-img   

-- no debconf information


crash.tar.gz
Description: application/gzip

Bug#820164: RFS: libretro-mupen64plus/2.0+git20160207+dfsg.1 [ITP]

[Sérgio Benjamim]

Package: sponsorship-requests
Severity: wishlist

Hey dear mentors!

I'm looking for a sponsor for my package "libretro-mupen64plus"

This is the libretro port of Mupen64Plus, the Nintendo 64 emulator. It's a
fork of the original project to fit better with the libretro API, so
it's not possible to use the same source code of Mupen64Plus & plugins packages.


* Package name : libretro-mupen64plus
  Version  : 2.0+git20160207+dfsg.1

  Upstream Author  : Mupen64Plus Team / The RetroArch Team

* URL  :https://github.com/libretro/mupen64plus-libretro
* License  : GPL-2+
  Programming Lang : C
  Description  : port of Mupen64Plus to libretro API


It builds those binary packages:

libretro-mupen64plus - Libretro wrapper for Mupen64Plus



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

http://mentors.debian.net/package/libretro-mupen64plus


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

dget -x 
http://mentors.debian.net/debian/pool/main/libr/libretro-mupen64plus/libretro-mupen64plus_2.0+git20160207+dfsg.1-1.dsc


More information about RetroArch and the libretro API can be obtained from 
http://www.libretro.com/index.php/api/

--
Sérgio Benjamim

Bug#820161: maven-debian-helper: mh_resolve_dependencies fails to honour --verbose option

[Christopher Hoskin]

Package: maven-debian-helper
Version: 2.0.6
Severity: minor

Dear Maintainer,

mh_resolve_dependencies doesn't honour the --verbose option, e.g.

mh_resolve_dependencies --verbose

produces the same output as 

mh_resolve_dependencies

This appears to be due to a missing "${VERBOSE:+--verbose}" in the options 
passed to org.debian.maven.packager.DependenciesSolver in 
/usr/bin/mh_resolve_dependencies.

Thanks.

Christopher Hoskin


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

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

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


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

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

Versions of packages maven-debian-helper depends on:
ii  default-jdk 2:1.8-57
ii  libmaven-clean-plugin-java  2.5-1
ii  libmaven-compiler-plugin-java   3.2-5
ii  libmaven-jar-plugin-java2.4-1
ii  libmaven-resources-plugin-java  2.6-1
ii  libmaven-site-plugin-java   2.1-4
ii  libplexus-velocity-java 1.1.8-1
ii  libsurefire-java2.17-2
ii  libxml2-utils   2.9.3+dfsg1-1
ii  maven   3.3.9-3
ii  maven-repo-helper   1.8.12
ii  unzip   6.0-20
ii  velocity1.7-4

maven-debian-helper recommends no packages.

Versions of packages maven-debian-helper suggests:
ii  apt-file  2.5.5
ii  devscripts2.16.2
pn  libmaven-javadoc-plugin-java  
ii  subversion1.9.3-3

-- no debconf information

Bug#820160: texlive-binaries: tex vs. kpsewhich - inconsistent paths are found

[Igor Liferenko]

Package: texlive-binaries
Version: 2015.20160222.37495-1
Severity: important

Dear Maintainer,

"kpsewhich" shows one path, and "tex" uses another.

Steps to reproduce:

1) Create /usr/local/share/texmf/web2c/texmf.cnf with the following content:

TEXMFHOME = /home/user/some-dir
TEXMFVAR = $TEXMFLOCAL

2) Check path in pdftex:

$ mkdir -p ~/some-dir/tex/
$ cp /usr/share/texlive/texmf-dist/tex/plain/cweb/cwebmac.tex 
~/some-dir/tex/
$ pdftex -rec -jobname test '\input cwebmac.tex \end'
$ grep cwebmac.tex test.fls
INPUT /usr/share/texlive/texmf-dist/tex/plain/cweb/cwebmac.tex

3) Check path in kpsewhich:

$ kpsewhich cwebmac.tex
/home/user/some-dir/tex/cwebmac.tex

4) Compare results of step 2) and 3).

I'm invoking the Debian kpsewhich and the Debian pdftex, both from /usr/bin

Attached are pdftex.log and kpsewhich.log, produced by the following commands:

pdftex --kpathsea-debug=-1 -jobname test '\input cwebmac.tex \end' 2> 
pdftex.log
kpsewhich -debug=-1 cwebmac.tex 2> kpsewhich.log


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

Kernel: Linux 4.3.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 texlive-binaries depends on:
ii  dpkg  1.18.4
ii  libc6 2.21-9
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3
ii  libgcc1   1:5.3.1-11
ii  libgmp10  2:6.1.0+dfsg-2
ii  libgraphite2-31.3.6-1
ii  libgs99.18~dfsg-4
ii  libharfbuzz-icu0  1.0.1-1+b1
ii  libharfbuzz0b 1.0.1-1+b1
ii  libice6   2:1.0.9-1+b1
ii  libicu55  55.1-7
ii  libkpathsea6  2015.20160222.37495-1
ii  libmpfr4  3.1.4~rc1-1
ii  libpaper1 1.1.24+nmu4
ii  libpixman-1-0 0.33.6-1
ii  libpoppler57  0.38.0-2
ii  libpotrace0   1.13-2
ii  libptexenc1   2015.20160222.37495-1
ii  libsm62:1.2.2-1+b1
ii  libstdc++65.3.1-11
ii  libsynctex1   2015.20160222.37495-1
ii  libtexlua52   2015.20160222.37495-1
ii  libtexluajit2 2015.20160222.37495-1
ii  libx11-6  2:1.6.3-1
ii  libxaw7   2:1.0.13-1
ii  libxext6  2:1.3.3-1
ii  libxi62:1.7.6-1
ii  libxmu6   2:1.1.2-2
ii  libxpm4   1:3.5.11-1+b1
ii  libxt61:1.1.5-1
ii  libzzip-0-13  0.13.62-3
ii  perl  5.22.1-8
ii  t1utils   1.39-2
ii  tex-common6.04
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages texlive-binaries recommends:
ii  python2.7.11-1
ii  ruby  1:2.3.0+1
ii  texlive-base  2015.20160223-1
ii  tk [wish] 8.6.0+9

texlive-binaries suggests no packages.

-- no debconf information
kdebug:Search path for cnf files (from compile-time paths.h)
kdebug:  = 
/etc/texmf/web2c:/usr/local/share/texmf/web2c:/usr/share/texmf/web2c:/usr/share/texlive/texmf-dist/web2c://share/texmf/web2c
kdebug:  before expansion = 
{/etc/texmf/web2c,/usr/local/share/texmf/web2c,/usr/share/texmf/web2c,/usr/share/texlive/texmf-dist/web2c,$SELFAUTOPARENT/share/texmf/web2c}
kdebug:  application override path = (none)
kdebug:  application config file path = (none)
kdebug:  texmf.cnf path = (none)
kdebug:  compile-time path = 
{/etc/texmf/web2c,/usr/local/share/texmf/web2c,/usr/share/texmf/web2c,/usr/share/texlive/texmf-dist/web2c,$SELFAUTOPARENT/share/texmf/web2c}
kdebug:  environment variables = TEXMFCNF
kdebug:  default suffixes = .cnf
kdebug:  other suffixes = (none)
kdebug:  search only with suffix = 0
kdebug:  runtime generation program = (none)
kdebug:  runtime generation command = (none)
kdebug:  program enabled = 0
kdebug:  program enable level = 0
kdebug:  open files in binary mode = 0
kdebug:  numeric format value = 8
kdebug:start search(file=texmf.cnf, must_exist=1, find_all=1, 
path=/etc/texmf/web2c:/usr/local/share/texmf/web2c:/usr/share/texmf/web2c:/usr/share/texlive/texmf-dist/web2c://share/texmf/web2c).
kdebug:path element /etc/texmf/web2c => /etc/texmf/web2c/
kdebug:path element /usr/local/share/texmf/web2c => 
/usr/local/share/texmf/web2c/
kdebug:path element /usr/share/texmf/web2c => /usr/share/texmf/web2c/
kdebug:path element /usr/share/texlive/texmf-dist/web2c => 
/usr/share/texlive/texmf-dist/web2c/
kdebug:kpse_normalize_path (//share/texmf/web2c) => 0
kdebug:path element /share/texmf/web2c =>
kdebug:Search path for ls-R files (from texmf.cnf)
kdebug:  = 
/var/lib/texmf:/usr/local/share/texmf:/usr/share/texmf:/usr/share/texlive/texmf-dist
kdebug:  before expansion = 
{!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFDEBIAN,!!$TEXMFDIST}
kdebug:  application override path = (none)
kdebug:  application config file path = (none)
kdebug:  texmf.cnf path = 
{!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFDEBIAN,!!$TEXMFDIST}
kdebug:  compile-time path = /nonesuch
kdebug:  environment variables = TEXMFDBS

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Hi Mattia,

As the new version of "python-responses" has hit unstable, the test
were enabled with the following patch:

http://paste.debian.net/424537/

The "--ignore=tests/test_cli.py" argument was added because this file
consists of functional tests (DEP-8) that should not run on build
time. The problem now is the following error:

http://paste.debian.net/424538/

Adding an "import pdb; pdb.set_trace()" in the test that is failing, I
could see that it is looking for this README file in
"/vagrant/grip/deb-grip/.pybuild/pythonX.Y_3.5/build/tests/input/default".
This file exists on the upstream source[1] and the tests doesn't fail
when I run them locally. My guess is that it is not being copied by
"pybuild" (actually, looks like the entire "tests/" directory isn't),
thus causing the test to fail during build.

What should I do in this case? Would be sensible to skip this test?

Regards,
Tiago.

[1]: https://github.com/joeyespo/grip/blob/v4.1.0/tests/input/default/README.md

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#819924: uploaders.mk breaks clean target under dh

[Michael Biebl]

On Mon, 4 Apr 2016 01:13:27 +0200 Michael Biebl  wrote:
> Am 04.04.2016 um 01:03 schrieb Michael Biebl:
> ekiga
> gcr
> gfbgraph
> gnome-builder
> gnome-calendar
> gnome-characters
> gnome-clocks
> gnome-logs
> gnome-maps
> gnome-music
> gnome-online-miners
> gnome-photos
> gnome-software
> gnome-taquin
> gsound
> libproxy
> libpwquality
> libsecret
> polari
> pygobject
> 
> which are affected by this.
> 

I've updated those in pkg-gnome's SVN.


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



signature.asc
Description: OpenPGP digital signature

Bug#820159: llvm: libfuzzer

[Kurt Roeckx]

Source: llvm-toolchain-3.8
Severity: wishlist

Hi,

As part of llvm there is a libfuzzer, see
http://llvm.org/docs/LibFuzzer.html.  

You actually have the sources of it as part of the various llvm
toolchain packages, but it doesn't seem like it's build.

The library doesn't really depend on llvm, and is useful for
writing the fuzzers.

Could you consider shipping a static version of the library in a
package?  Or do you prefer a package that's not part of the llvm
toolchain source packages?


Kurt

Bug#639414: libimlib2: divide-by-zero on 2x1 ellipse

[Simon Lees]

Hi

Attached is a better patch, dx / dy are slowly decrementing so cutting
them of at 1 seems reasonable. These variables combined with xx and yy
are only used to work out if x or y has changed since the last iteration
then increment or decrement the other variables and continue the loop.
From looking at the first loop In the case where b == 0, dx and dy will
always be 0 as well in which case the loop won't run due to dy < dx. As
dy is incremented by b*b and dx is decremented by a*a to replicate this
issue a*a*b - a*a == 0, in other words when b == 1. Presuming this is
implementing 1 of 2 common ellipse drawing algorithms we are probably
talking about drawing ellipses that are either 1 or 2 pixels high and
were probably never going to draw that well anyway.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Index: imlib2-1.4.2/src/lib/ellipse.c
===
--- imlib2-1.4.2.orig/src/lib/ellipse.c
+++ imlib2-1.4.2/src/lib/ellipse.c
@@ -71,6 +71,9 @@ __imlib_Ellipse_DrawToData(int xc, int y
 if (IN_RANGE(rx, by, clw, clh))
pfunc(color, bp + len);
 
+if (dx < 1)
+   dx = 1;
+
 dy += b2;
 yy -= ((dy << 16) / dx);
 lx--;
@@ -123,6 +126,9 @@ __imlib_Ellipse_DrawToData(int xc, int y
 if (IN_RANGE(rx, by, clw, clh))
pfunc(color, bp + len);
 
+if (dy < 1)
+   dy = 1;
+
 dx -= a2;
 xx += ((dx << 16) / dy);
 ty++;
@@ -222,6 +228,9 @@ __imlib_Ellipse_DrawToData_AA(int xc, in
 if (IN_RANGE(rx, by, clw, clh))
pfunc(col1, bp + len);
 
+if (dx < 1)
+   dx = 1;
+
 dy += b2;
 yy -= ((dy << 16) / dx);
 lx--;
@@ -295,6 +304,9 @@ __imlib_Ellipse_DrawToData_AA(int xc, in
 if (IN_RANGE(rx, by, clw, clh))
pfunc(col1, bp + len);
 
+if (dy < 1)
+   dy = 1;
+
 dx -= a2;
 xx += ((dx << 16) / dy);
 ty++;
@@ -395,6 +407,9 @@ __imlib_Ellipse_FillToData(int xc, int y
 if (IN_RANGE(rx, by, clw, clh))
pfunc(color, bp + len);
 
+if (dx < 1)
+   dx = 1;
+
 dy += b2;
 yy -= ((dy << 16) / dx);
 lx--;
@@ -453,6 +468,9 @@ __imlib_Ellipse_FillToData(int xc, int y
 if (((unsigned)(by) < clh) && (len > 0))
sfunc(color, bpp, len);
 
+if (dy < 1)
+   dy = 1;
+
 dx -= a2;
 xx += ((dx << 16) / dy);
 ty++;
@@ -556,6 +574,9 @@ __imlib_Ellipse_FillToData_AA(int xc, in
 if (IN_RANGE(rx, by, clw, clh))
pfunc(col1, bp + len);
 
+if (dx < 1)
+   dx = 1;
+
 dy += b2;
 yy -= ((dy << 16) / dx);
 lx--;
@@ -629,6 +650,9 @@ __imlib_Ellipse_FillToData_AA(int xc, in
 if (IN_RANGE(rx, by, clw, clh))
pfunc(col1, bp + len);
 
+if (dy < 1)
+   dy = 1;
+
 dx -= a2;
 xx += ((dx << 16) / dy);
 ty++;


signature.asc
Description: OpenPGP digital signature

Bug#819859: sawfish: Sawfish quits immediately after shown up

[王晓林]

Great, installing sawfish-lisp-source does work, though with some errors.
In the center of the root window, there is a message box popped up
immediately after sawfish started up, saying "No such file or directory,
gnome". I don't have gnome installed, this shouldn't be treated as an
error, right?

And in the .xsession-errors file, I found the following lines. Hope these
can help finding the bug.

>
dbus-update-activation-environment: warning: error sending to systemd:
org.freedesktop.DBus.Error.Spawn.ChildExited: Process
org.freedesktop.systemd1 exited with status 1
Sawfish error:
File error: No such file or directory, gnome
--
Sawfish error:
Unbound variable: expert
--
Sawfish error:
Unbound variable: uglicon-reset
--
Sawfish error:
Unbound variable: uglicon-reset
[1750:1750:0406/083845:ERROR:background_mode_manager_aura.cc(13)] Not
implemented reached in virtual void
BackgroundModeManager::EnableLaunchOnStartup(bool)
[1750:1750:0406/083845:ERROR:logging.h(813)] Failed to call method:
org.freedesktop.DBus.ObjectManager.GetManagedObjects: object_path= /:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not
provided by any .service files
[1750:1750:0406/083846:ERROR:logging.h(813)] Failed to call method:
org.freedesktop.DBus.ObjectManager.GetManagedObjects: object_path= /:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not
provided by any .service files
[1750:1863:0406/083851:ERROR:connection_factory_impl.cc(367)] Failed to
connect to MCS endpoint with error -130
[1750:1863:0406/083913:ERROR:connection_factory_impl.cc(367)] Failed to
connect to MCS endpoint with error -130
[1750:1750:0406/083921:ERROR:account_tracker.cc(357)] OnGetTokenFailure:
Connection failed (-130).
[1750:1750:0406/083921:ERROR:account_tracker.cc(357)] OnGetTokenFailure:
Connection failed (-130).
[1750:1863:0406/083951:ERROR:connection_factory_impl.cc(367)] Failed to
connect to MCS endpoint with error -130
[1750:1863:0406/084002:ERROR:connection_factory_impl.cc(367)] Failed to
connect to MCS endpoint with error -130
[1750:1863:0406/085337:ERROR:socket_stream.cc(210)] Closing stream with
result -100
>>

On Wed, Apr 6, 2016 at 12:38 AM Jose M Calhariz  wrote:

> On 05/04/16 12:53, David Riley wrote:
> > I tried copying the wallpaper.jl from
> > https://github.com/SawfishWM/sawfish/tree/master/lisp/sawfish/wm/ext
> > into /usr/share/sawfish/lisp/sawfish/wm/ext/ and with that it starts up.
> >
> > I don't know if anything else is missing but it looks ok from a very
> > quick test.
> Xiaolin, the best workaround is to install the package sawfish-lisp-source.
>
> I will work on a fix.
>
> Kind regards
> Jose M Calhariz
>
>
> --

王晓林

Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits

[Ben Hutchings]

Control: severity -1 wishlist

On Tue, 2016-04-05 at 19:13 -0400, Stephen Powell wrote:
> Package: initramfs-tools-core
> Version: 0.123
> Severity: minor
> Tags: patch
> 
> Congratulations on initramfs-tools version 0.123!  Many bugs in version 0.120
> have been fixed in this version.  However, it appears that the parse_numeric
> function, while improved over the 0.120 version, still doesn't handle the
> general case of a composite device number.  It seems it will only handle 8 hex
> digits or less correctly.
> 
> I have submitted a patch for your consideration.  The patch will accommodate 
> the
> general case of a composite device number of up to 16 hex digits (the limit).
> It also tightens up some other error checking corner cases.

I'm not applying this until the kernel actually supports device numbers
that large.  Currently it defines (in include/linux/kdev_t.h):

static inline u32 new_encode_dev(dev_t dev) { ... }
static inline dev_t new_decode_dev(u32 dev) { ... }

static inline u64 huge_encode_dev(dev_t dev)
{
return new_encode_dev(dev);
}

static inline dev_t huge_decode_dev(u64 dev)
{
return new_decode_dev(dev);
}

i.e. anything above bit 31 is zeroed.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.

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

Bug#819840: [Aptitude-devel] Bug#819840: aptitude: Segfaults if suspended and foregrounded on virtual linux console

[Axel Beckert]

Hi again,

> It's possibly the first time I did this with an aptitude version
> released after Jessie. So I can't tell when it started, except that it
> didn't happen with Debian Jessie on armhf nor with Raspian Jessie. I'm
> not sure about Raspbian Stretch, but I may have used aptitude (0.7.5)
> there on the vt console once or twice, too. Can and will check,
> though.

For that I need to boot my Raspberry Pi with a different SD card which
I haven't done yet.

But I found out some more stuff:

1) I first recognized with the state before the dinstall run of
   2016-04-04 20:54.

2) It also happens inside a screen session when the screen session
   initally was started on the Linux vt console and hence had
   TERM=screen.linux.

3) It even happens remotely inside such a screen session despite it's
   connected to an xterm via ssh. So I now can also check stuff
   remotely.

4) It still happens with apt 1.2.10 installed.

5) The backtrace on armhf is unusable:

Reading symbols from /usr/bin/aptitude-curses...Reading symbols from 
/usr/lib/debug/.build-id/d1/1cf88a5f126adb6c2781dfc207e3a039441afa.debug...done.
done.
[New LWP 28093]
[New LWP 28100]
[New LWP 28094]
[New LWP 28096]
[New LWP 28095]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `aptitude'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x763fdcf0 in ?? ()
[Current thread is 1 (Thread 0x7647d000 (LWP 28093))]
(gdb) bt
#0  0x763fdcf0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit

:-(

Not sure if it's gdb which is broken on armhf or something else.

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#820060: Debian Bug#820060: python-biom-format: broken on big-endian architectures

[Daniel McDonald]

Thanks, Greg.

Andreas, my read of the bug report suggests that the issue across
architectures is h5py or hdf5. The access being made is to an attribute of
an h5py object which happens within python and is a valid API operation;
testing locally I'd expect a different KeyError to be thrown under normal
operation.

Looking closer at one of the failing tests (offending call linked below),
you can see that this is on read of a hdf5 table that ships with the
biom-format project.

https://github.com/biocore/biom-format/blob/master/tests/test_table.py#L527-528

The implication is that this is happening when reading a table that ships
as part of the test code, suggesting that h5py or hdf5 are unable to
interact with the file as expected. My take is that the failure we're
observing is a manifestation of a bug at a lower level.

The failure observed on mipsel is a stochastic one.

Best,
Daniel

On Tue, Apr 5, 2016 at 4:40 PM, Greg Caporaso 
wrote:

> Thanks for sharing this.
>
> Daniel, Yoshiki - any ideas about this?
>
> Greg
> -- Forwarded message --
> From: Andreas Tille 
> Date: Mon, Apr 4, 2016 at 11:18 PM
> Subject: Debian Bug#820060: python-biom-format: broken on big-endian
> architectures
> To: Greg Caporaso , 820...@bugs.debian.org
>
>
> Hi Greg,
>
> I'm hereby forwarding a bug report against the Debian packaged
> biom-format.  It would be great if you can either fix the issue (which
> would be the prefered solution) or explain that for some reason
> big-endian is not supported and we need to exclude these architectures
> from the build.
>
> Kind regards
>
>Andreas.
>
> On Mon, Apr 04, 2016 at 10:44:51PM -0700, Steve Langasek wrote:
> > Package: python-biom-format
> > Version: 2.1.4+dfsg-1
> > Severity: serious
> >
> > As seen at http://buildd.debian.org/python-biom-format, this package
> fails
> > to build on all big-endian architectures in the archive (mips, powerpc,
> > s390x).  While this build failure has only appeared with the upload of
> > 2.1.5+dfsg-1, this is not a regression in that version of the upstream
> > source; instead, the package was already broken, but what has changed
> now is
> > that a new version of dh-python correctly finds the tests and runs them
> at
> > build time where before dh_auto_test was silently passing.
> >
> > I'm not sure if this points to breakage in python-biom-format, or in
> > something lower down the stack that it depends on.  I've confirmed that
> > python-numpy autopkgtests run ok on powerpc (except for openblas - and
> the
> > tests can't be run on s390x because openblas is not built for that
> > architecture), and h5py autopkgtests run ok on s390x.  python-scipy's
> > autopkgtests fail with SIGABRT on both powerpc and s390x, maybe related,
> > maybe not (test_random_complex_exact (test_basic.TestLstsq) ... ***
> Error in
> > `python3.5': free(): invalid pointer: 0x1172c2a8 ***).
> >
> > And hdf5 itself doesn't have any autopkgtests, and any build-time tests
> > pass; and h5py in any case should catch any bugs with its own testsuite
> > before python-biom-format.
> >
> > So it seems most likely that this is a bug in python-biom-format itself
> > rather than any of its dependencies, thus assigning here.
> >
> > --
> > Steve Langasek   Give me a lever long enough and a Free
> OS
> > Debian Developer   to set it on, and I can move the
> world.
> > Ubuntu Developer
> http://www.debian.org/
> > slanga...@ubuntu.com
> vor...@debian.org
>
>
>
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@lists.alioth.debian.org
> >
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>
>
> --
> http://fam-tille.de
>
>

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Dimitri John Ledkov]

On 6 April 2016 at 00:32, Ben Hutchings  wrote:
> On Wed, 2016-04-06 at 00:22 +0100, Ben Hutchings wrote:
> [...]
>> But I also found this commit in 3.17:
>>
>> commit f79a901331a823ae370584b15cd39dd110b95a0a
>> Author: Hans de Goede 
>> Date:   Fri Jul 18 12:21:47 2014 +0200
>>
>> ideapad-laptop: Disable touchpad interface on Yoga models
>>
>> Although it says 'disable touchpad interface', what it means is the
>> ideapad-laptop driver will ignore firmware events sayigng the touchpad
>> should be turned on or off (maybe based on rotation sensors in other
>> Ideapad models?).  It started handling those events in 3.6, which fits
>> the earlier report.
>>
>> Have either of you tried a kernel version newer than 3.16?
>
> Sorry, that won't help - this commit was reverted as the feature was
> previously working properly for some Yoga models.
>
> Dmitri, can you test whether that cherry-picking that commit fixes this
> for you?

I can try that yes.

So yoga 13 non-pro, has a few things
- normal touchpad which with up to date kernels doesn't come up on
boot, until psmouse is reloaded
- touchscreen which appears as a tablet input interface or some such
- and magic key-codes

Magic key-codes, send a key code every 2s or some such to indicate
laptop unfold angle, such that when it's beyond 180 open the keycodes
spam stops and thus OS should turn off keyboard and touchpad because
it's now in "tablet" mode. It folds all the way out.

Stuff has changed in yoga 13 pro models, cause things did stop working
on non-pro after pro-specific model/quick/modules things were merged.
But i believe pro revision did things differently.

-- 
Regards,

Dimitri.

Bug#819943: really should add an unforbid-version command

[積丹尼 Dan Jacobson]

I see. Please add the @()@:

   To revert the action, "aptitude install " will remove the
   ban. To remove the forbidden version without installing the
   candidate version, the current @(installed, not candidate)@
   version should be appended: "install =".

else people will think you mean Debian's current version, not my
computer's current version. Thanks.

Bug#820158: lilyterm: Non-switchable transparency with vte-2.91

[Charles Malaheenee]

Package: lilyterm
Version: 0.9.9.4-4
Severity: important
Tags: upstream

Dear Maintainer,

Since update to vte-2.91 the window opacity became non-switchable – even if
it set ‘transparent_background = 0’ or ‘transparent_window = 0’, the
opacity is always active (at least with openbox & compton) or give black
background.
Also, icons in the right-click menu had vanished.

Best regards,
Malaheenee



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

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

Versions of packages lilyterm depends on:
ii  libc6   2.22-5
ii  libgdk-pixbuf2.0-0  2.32.3-1.2
ii  libglib2.0-02.48.0-1
ii  libgtk2.0-0 2.24.30-1.1
ii  libpango-1.0-0  1.38.1-1
ii  libvte9 1:0.28.2-5+b1
ii  libx11-62:1.6.3-1

lilyterm recommends no packages.

lilyterm suggests no packages.

Bug#763720: Please enable the vst plugin on i386 and amd64

[Javier Serrano Polo]

(Previous message was lost.)
This patch should enable the plugin on i386. To work around #820033:
cd /usr/lib/i386-linux-gnu
ln -s wine/libwine.so.1

Patch: http://pastebin.com/R8KkEzBJ

amd64 still needs some work.


smime.p7s
Description: S/MIME cryptographic signature

Bug#816924: GNU GLOBAL 6.5.2 available

[Pierre-Elliott Bécue]

Hey,

I also would like to see a newer version of global in debian. Some very
useful options of global/gtags are missing, and it's a bit sad as global is
mostly necessary fo swim in any big code project.

Please, ron, think about us. :)

-- 
PEB

Bug#820060: Debian Bug#820060: python-biom-format: broken on big-endian architectures

[Greg Caporaso]

Thanks for sharing this.

Daniel, Yoshiki - any ideas about this?

Greg
-- Forwarded message --
From: Andreas Tille 
Date: Mon, Apr 4, 2016 at 11:18 PM
Subject: Debian Bug#820060: python-biom-format: broken on big-endian
architectures
To: Greg Caporaso , 820...@bugs.debian.org


Hi Greg,

I'm hereby forwarding a bug report against the Debian packaged
biom-format.  It would be great if you can either fix the issue (which
would be the prefered solution) or explain that for some reason
big-endian is not supported and we need to exclude these architectures
from the build.

Kind regards

   Andreas.

On Mon, Apr 04, 2016 at 10:44:51PM -0700, Steve Langasek wrote:
> Package: python-biom-format
> Version: 2.1.4+dfsg-1
> Severity: serious
>
> As seen at http://buildd.debian.org/python-biom-format, this package fails
> to build on all big-endian architectures in the archive (mips, powerpc,
> s390x).  While this build failure has only appeared with the upload of
> 2.1.5+dfsg-1, this is not a regression in that version of the upstream
> source; instead, the package was already broken, but what has changed now
is
> that a new version of dh-python correctly finds the tests and runs them at
> build time where before dh_auto_test was silently passing.
>
> I'm not sure if this points to breakage in python-biom-format, or in
> something lower down the stack that it depends on.  I've confirmed that
> python-numpy autopkgtests run ok on powerpc (except for openblas - and the
> tests can't be run on s390x because openblas is not built for that
> architecture), and h5py autopkgtests run ok on s390x.  python-scipy's
> autopkgtests fail with SIGABRT on both powerpc and s390x, maybe related,
> maybe not (test_random_complex_exact (test_basic.TestLstsq) ... *** Error
in
> `python3.5': free(): invalid pointer: 0x1172c2a8 ***).
>
> And hdf5 itself doesn't have any autopkgtests, and any build-time tests
> pass; and h5py in any case should catch any bugs with its own testsuite
> before python-biom-format.
>
> So it seems most likely that this is a bug in python-biom-format itself
> rather than any of its dependencies, thus assigning here.
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developerhttp://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org



> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
>
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging


--
http://fam-tille.de

Bug#815202: packages: machines and sponsors information is outdated

[Stéphane Blondon]

Le 05/04/2016 07:06, Paul Wise a écrit :
> On Tue, Apr 5, 2016 at 9:05 AM, Stéphane Blondon wrote:
> 
>> There are no commit since two years, so I'm not sure it's still alive.
> 
> Nevertheless, it is the way forward.
> 
>> I tried to extract the useful code from the script. It depends on the
>> libnet-ldapapi-perl package and the configuration of the machine which
>> is running the LDAP.
> 
> The Debian LDAP can be accessed from any machine, anonymous access
> will only return the public data (including hostname stuff). So you
> shouldn't need to run on db.d.o nor read the config file at all.

Thank you for these infos, I ignored them. :-)

I attached 2 scripts (one in Perl, one in Python) allowing to get the
names of the machines providing packages.debian.org service. I think
some checks about LDAP errors could be added but it's a start.

I guess the perl script could be included in order to fix the current
bug report.

-- 
Stéphane


packagemachines.pl
Description: Perl program
#! /usr/bin/python
#
# package python-ldap must be installed

import ldap


def get_packages_machines():
machines = _request_machines_on_ldap()
packages_machines = []

for machine in machines:
details = machine[1]
try:
   if "packages.debian.org" in details["purpose"][0]:
   packages_machines.append(details["host"][0])
except KeyError:
   pass

return packages_machines

def _request_machines_on_ldap():
l = ldap.initialize("ldap://db.debian.org;)
l.simple_bind_s("", "")
ldap_result_id = l.search("dc=debian,dc=org", ldap.SCOPE_SUBTREE, "host=*")
result_type, result_data = l.result(ldap_result_id, 1)
l.unbind_s()
return result_data


if __name__ == "__main__":
print(get_packages_machines())



signature.asc
Description: OpenPGP digital signature

Bug#819703: Question

[Santiago Vila]

On Wed, Apr 06, 2016 at 04:18:17PM -0700, Jamil Said Jr. wrote:
> I have a question and would appreciate if someone can point me to the right
> direction.
> 
> I would like to fix this warning on my own. I code in bash and other
> languages. My difficulty here is that I cannot find the offending code
> anywhere on my installations.
> 
> I know that grep and sed can work on binary files... but where's this code?
> I looked all over the place and could not find it.

The source code is not "installed" by default.

If you have a suitable deb-src line in /etc/apt/sources.list, try

apt-get source xscreensaver

After that, the steps to build a package from source are the same
regardless of the package you want to build, i.e. it's not specific to
xscreensaver, and it's widely documented.

Thanks.

Bug#791934: cloud-init: rsyslog deprecation warnings

[Tobias Wolter]

Bump.

~ needs to be replaced with stop.

-towo


signature.asc
Description: Digital signature

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Ben Hutchings]

On Wed, 2016-04-06 at 00:22 +0100, Ben Hutchings wrote:
[...]
> But I also found this commit in 3.17:
> 
> commit f79a901331a823ae370584b15cd39dd110b95a0a
> Author: Hans de Goede 
> Date:   Fri Jul 18 12:21:47 2014 +0200
> 
> ideapad-laptop: Disable touchpad interface on Yoga models
> 
> Although it says 'disable touchpad interface', what it means is the
> ideapad-laptop driver will ignore firmware events sayigng the touchpad
> should be turned on or off (maybe based on rotation sensors in other
> Ideapad models?).  It started handling those events in 3.6, which fits
> the earlier report.
> 
> Have either of you tried a kernel version newer than 3.16?

Sorry, that won't help - this commit was reverted as the feature was
previously working properly for some Yoga models.

Dmitri, can you test whether that cherry-picking that commit fixes this
for you?

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.

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

Bug#820157: Move xfce4-panel from Depends to Recommends?

[Stephen Paul Weber]

Package: osmo
Version: 4.10.0-1

Currently osmo depends on xfce4-panel, however the program runs very nicely 
on other desktop environments without running xfce4-panel at all.  Of course 
you do not get the panel integration the same way, but a tray icon does 
appear and all other features work.


Would it be possible to downgrade the dependency to Reccomend or similar?

Thanks,

--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Ben Hutchings]

On Tue, 2016-04-05 at 23:18 +0100, Dimitri John Ledkov wrote:
> On 5 April 2016 at 22:49, Ben Hutchings  wrote:
> > 
> > Control: reassign -1 src:linux 3.16.7-ckt25-1
> > Control: tag -1 moreinfo
> > 
> > On Mon, 2016-04-04 at 22:11 +0300, Juho wrote:
> > > 
> > > Package: general
> > > Severity: important
> > > 
> > > After running "apt-get update && apt-get dist-upgrade" on 2016-04-03
> > > touchpad of IdeaPad Yoga 13 stopped working. Both touch plate and
> > > buttons are not working.
> > > This laptop also has a touch screen and it is still working without
> > > problems.
> > > I'm not sure which package included this 8.4 update might be the faulty
> > > one.
> > [...]
> > 
> > Most likely the kernel.  However, I can't see any obviously relevant
> > changes.  What does this command show:
> > 
> > ls -l /sys/class/input/mouse*/device/device/driver
> 
> I have such a Yoga, for me it's the older yoga-13, pre-highdpi pro version.
> 
> $ sudo modprobe -r psmouse
> $ sudo modprobe psmouse

Right, I suspected this was psmouse.  And there have been no changes
there.  So this probably isn't a regression, just an ongoing problem
that showed up on the first boot after the upgrade.

> Makes it "work" again. I have no idea what happens during the boot, or
> how come post-boot psmouse module loading results in working
> behaviour.
> Possibly something is racy in the kernel and initializes differently
> "post-boot".
> 
> It broke around 3.13 following upstream kernels for me or some such.
> And bisecting this using master/vanilla/.0 kernels ended up being
> fruitless, at least for me.
> So i'm reloading psmouse on my IdeaPad

According to this report it was earlier, between 3.4 and 3.8:
http://thread.gmane.org/gmane.linux.kernel.input/30222/

But I also found this commit in 3.17:

commit f79a901331a823ae370584b15cd39dd110b95a0a
Author: Hans de Goede 
Date:   Fri Jul 18 12:21:47 2014 +0200

ideapad-laptop: Disable touchpad interface on Yoga models

Although it says 'disable touchpad interface', what it means is the
ideapad-laptop driver will ignore firmware events sayigng the touchpad
should be turned on or off (maybe based on rotation sensors in other
Ideapad models?).  It started handling those events in 3.6, which fits
the earlier report.

Have either of you tried a kernel version newer than 3.16?

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot

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

Bug#819703: Question

[Jamil Said Jr .]

I have a question and would appreciate if someone can point me to the right
direction.

I would like to fix this warning on my own. I code in bash and other
languages. My difficulty here is that I cannot find the offending code
anywhere on my installations.

I know that grep and sed can work on binary files... but where's this code?
I looked all over the place and could not find it.

What am I missing here? Any help is very appreciated.

Cheers,
Jamil

Bug#820154: (no subject)

[Manuel Lanctot]

As far as I know, this bug can be closed, it was a mistake on our side:
The script /etc/xen/scripts/block-iscsi had been modified from the
package version and it was outputting some debug values, which
seem to be what caused migrations to now fail.

Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits

[Stephen Powell]

Package: initramfs-tools-core
Version: 0.123
Severity: minor
Tags: patch

Congratulations on initramfs-tools version 0.123!  Many bugs in version 0.120
have been fixed in this version.  However, it appears that the parse_numeric
function, while improved over the 0.120 version, still doesn't handle the
general case of a composite device number.  It seems it will only handle 8 hex
digits or less correctly.

I have submitted a patch for your consideration.  The patch will accommodate the
general case of a composite device number of up to 16 hex digits (the limit).
It also tightens up some other error checking corner cases.

Respectfully submitted,

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-
--- a/functions	2016-01-21 18:33:59.0 -0500
+++ b/functions	2016-03-24 08:09:11.0 -0400
@@ -128,14 +128,28 @@
 
 # lilo compatibility
 parse_numeric() {
-	case $1 in
+	case "$1" in
 	*:*)
 		# Does it match /[0-9]*:[0-9]*/?
-		minor=${1#*:}
-		major=${1%:*}
-		case $major$minor in
+		minor="${1#*:}"   # Everything after the first colon.
+		major="${1%%:*}"  # Everything before the first colon.
+		[ X"$major" = X ] && return   # major is null.
+		[ X"$minor" = X ] && return   # minor is null.
+		case "$major$minor" in
 		*[!0-9]*)
-			# No.
+			# major or minor contains a non-numeric character.
+			return
+			;;
+		esac
+		case "$major" in
+		0?*)
+			# major has a leading zero.
+			return
+			;;
+		esac
+		case "$minor" in
+		0?*)
+			# minor has a leading zero.
 			return
 			;;
 		esac
@@ -146,9 +160,56 @@
 		;;
 	*)
 		# [A-Fa-f0-9]*
-		value=$(( 0x${1} ))
-		minor=$(( (${value} & 0xff) | (${value} >> 12) & 0xfff00 ))
-		major=$(( (${value} >> 8) & 0xfff ))
+		case "$1" in
+		0?*)
+			# Composite device number has a leading zero.
+			return
+			;;
+		esac
+		[ ${#1} -gt 16 ] && return   # More than 16 hex digits.
+		#
+		# 16 hex digits, with leading zeros suppressed.
+		# Format is MmmMMMmm, where the "M"s are the hex
+		# digits of the major device number and the "m"s are the
+		# hex digits of the minor device number.
+		#
+		# Note: the shell uses 64-bit two's complement signed binary
+		# integer arithmetic internally when evaluating arithmetic
+		# expressions, even on 32-bit platforms such as i386.  Bitwise
+		# shift operations are arithmetic shifts, not logical shifts.
+		# Only the right-most 63 bits participate in a shift operation.
+		# The left-most bit, the sign bit, does not participate in
+		# the shift operation and remains unchanged.  For a shift
+		# left operation, bits shifted out of the left-most bit
+		# position which participates in the shift are lost; and zeros
+		# are shifted in on the right.  Arithmetic overflow occurs
+		# if any bits unlike the sign bit are shifted out of the
+		# left-most bit position which participates in the shift.
+		# (However, arithmetic overflow is ignored.)  For a shift
+		# right operation, bits shifted out of the right-most bit
+		# position are lost; and copies of the sign bit are shifted
+		# in on the left.  All 64 bit positions, including the sign
+		# bit, participate in bitwise "and" and bitwise "or"
+		# operations.
+		#
+		# Hexadecimal constants are treated as padded on the left
+		# with zeros, if needed, or truncated on the left, if needed,
+		# to make 16 digits.  If the left-most digit, after padding
+		# or truncating if needed, is in the range 8-f, inclusive,
+		# then the number is treated as negative, in two's complement
+		# form.  Otherwise, the number is treated as positive (or zero
+		# if all digits are zero).
+		#
+		# For the three operators used in the expressions below,
+		# the bitwise shift right operator (>>) has the highest
+		# priority, followed by the bitwise "and" operator (&),
+		# followed by the bitwise "or" operator (|).  Therefore, the
+		# default order of operations is correct; and no parentheses
+		# are needed in the expressions themselves.
+		#
+		devno=$(( 0x$1 ))
+		major=$(( devno >> 8 & 0xfff | devno >> 32 & 0xf000 ))
+		minor=$(( devno & 0xff | devno >> 12 & 0xff00 ))
 		;;
 	esac
 

Bug#819868: qtwebkit: Make determineNumberOfCPUs work on kfreebsd

[Lisandro Damián Nicanor Pérez Meyer]

On Tuesday 05 April 2016 23:09:41 Jon Boden wrote:
> On Mon, Apr 04, 2016 at 05:07:09PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > On Monday 04 April 2016 20:57:08 Jon Boden wrote:
> > [snip]
> > 
> > > > - What about Qt5's qtwebkit? Dos it suffer from the same problem? If
> > > > so,
> > > > can you provide a patch too?
> > > 
> > > I can check. What's the package name? Is it in Debian sid?
> > 
> > qtwebkit-opensource-src, it's on stable already :)
> 
> Hi Lisandro
> 
> I just checked qtwebkit-opensource-src, and the patch it needs is exactly
> the same I sent for qtwebkit.
> 
> Should I file a new bug report?

Please do so we can track it.

-- 
Ponga su mano en una estufa caliente por un minuto, y le parecerá como una
hora. Siéntese con una muchacha bonita por una hora, y le parecerá un minuto.
¡Eso es relatividad!.
 Albert Einstein (1879-1955)

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


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

Bug#819897: kobodeluxe segfault on startup

[Markus Koschany]

Control: tags -1 confirmed
Control: severity -1 grave

On Sun, 03 Apr 2016 18:45:34 +0200 Emile CARRY
 wrote:
> Package: kobodeluxe
> Version: 0.5.1-7
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> I recently launched my favorite game and unfortunately he made a 
> segmentation fault at startup .
> After rebuilding the package whith the -g flag, i found that the problem was 
> in
>  the file kobodeluxe-0.5.1/sound/a_midicon.c
> 
> My patch is very simple... I swap the lines 123 and 124 in file 
> kobodeluxe-0.5.1/sound/a_midicon.c

Hello,

thank you for reporting this issue and providing a patch. I can confirm
that kobodeluxe is rather unusable at the moment and that your patch
appears to fix the segfault on startup.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#644886: logcheck-database: snmpd ruleset needs update

[Michael Steele]

Package: logcheck
Followup-For: Bug #644886

Dear Maintainer,

One of two rules in the snmpd rule set is as follows:

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ snmpd\[[0-9]+\]: Connection from UDP: 
\[[.0-9]{7,15}\]:[0-9]{4,5}(->\[[.0-9]{7,15}\])?$

It is not the final IP address that is optional, but a port number appended to 
the end. I changed this line as follows on my local system:

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ snmpd\[[0-9]+\]: Connection from UDP: 
\[[.0-9]{7,15}\]:[0-9]{4,5}(->\[[.0-9]{7,15}\])(:[0-9]{1,5})?$

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

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

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


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

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

Versions of packages logcheck depends on:
ii  adduser 3.113+nmu3ubuntu4
ii  cron3.0pl1-127ubuntu1
ii  lockfile-progs  0.1.17
ii  logtail 1.3.17
ii  mime-construct  1.11
ii  postfix [mail-transport-agent]  2.11.3-1ubuntu2
ii  rsyslog [system-log-daemon] 8.12.0-1ubuntu2

Versions of packages logcheck recommends:
ii  logcheck-database  1.3.17

Versions of packages logcheck suggests:
ii  syslog-summary  1.14-2

-- Configuration Files:
/etc/logcheck/logcheck.conf [Errno 13] Permission denied: 
u'/etc/logcheck/logcheck.conf'
/etc/logcheck/logcheck.logfiles [Errno 13] Permission denied: 
u'/etc/logcheck/logcheck.logfiles'

-- no debconf information

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Peter Nowee]

On Tue, Apr 05, 2016 at 08:31:46PM +0200, Tormod Volden wrote:
> Debian users should always report bugs to Debian and not directly
> upstream. So the author being spammed by Debian users on old versions
> should in principle not happen. If the current software encourages
> people to send bug reports to the author we will look into and fix
> this.

Thanks for your reply.

Here is a patch I was working on to add links to the Debian BTS in the 
several places where bug reporting is encouraged (man pages, dialog 
boxes). Perhaps it can be of use. Note that I did not have a chance to 
test the change I made to the Motif dialog box (driver/demo-Xm.c) yet.

Good luck, thanks,
Peter Nowee
Index: xscreensaver-5.30/driver/demo-Gtk.c
===
--- xscreensaver-5.30.orig/driver/demo-Gtk.c
+++ xscreensaver-5.30/driver/demo-Gtk.c
@@ -824,7 +824,10 @@ about_menu_cb (GtkMenuItem *menuitem, gp
   sprintf(copy, ("Copyright \251 1991-%s %s"), year, s);
 #endif /* !HAVE_GTK2 */
 
-  sprintf (msg, "%s\n\n%s", copy, desc);
+  sprintf (msg, "%s\n\n%s\n"
+"Please report bugs for this Debian version at\n"
+"https://bugs.debian.org/xscreensaver;,
+copy, desc);
 
   /* I can't make gnome_about_new() work here -- it starts dying in
  gdk_imlib_get_visual() under gnome_about_new().  If this worked,
Index: xscreensaver-5.30/driver/demo-Xm.c
===
--- xscreensaver-5.30.orig/driver/demo-Xm.c
+++ xscreensaver-5.30/driver/demo-Xm.c
@@ -360,7 +360,9 @@ about_menu_cb (Widget button, XtPointer
"version is no longer maintained.  Please use the GTK version\n"
"instead, which has many more features.\n"
"\n"
-   "For xscreensaver updates, check http://www.jwz.org/xscreensaver/;,
+   "For xscreensaver updates, check http://www.jwz.org/xscreensaver/\n;
+   "Please report bugs for this Debian version at\n"
+   "https://bugs.debian.org/xscreensaver;,
s, s2);
   free (s);
 
Index: xscreensaver-5.30/driver/xscreensaver-command.c
===
--- xscreensaver-5.30.orig/driver/xscreensaver-command.c
+++ xscreensaver-5.30/driver/xscreensaver-command.c
@@ -135,6 +135,8 @@ usage: %s -\n\
 \n\
   See the man page for more details.\n\
   For updates, check http://www.jwz.org/xscreensaver/\n\
+  Please report bugs for this Debian version at\n\
+  https://bugs.debian.org/xscreensaver\n\
 \n";
 
 /* Note: The "-throttle" command is deprecated -- it predates the XDPMS
Index: xscreensaver-5.30/driver/xscreensaver-command.man
===
--- xscreensaver-5.30.orig/driver/xscreensaver-command.man
+++ xscreensaver-5.30/driver/xscreensaver-command.man
@@ -261,3 +261,5 @@ without express or implied warranty.
 Jamie Zawinski , 13-aug-1992.
 
 Please let me know if you find any bugs or make any improvements.
+.SH BUGS
+Please report bugs for this Debian version at https://bugs.debian.org/xscreensaver
\ No newline at end of file
Index: xscreensaver-5.30/driver/xscreensaver-demo.man
===
--- xscreensaver-5.30.orig/driver/xscreensaver-demo.man
+++ xscreensaver-5.30/driver/xscreensaver-demo.man
@@ -396,3 +396,5 @@ without express or implied warranty.
 Jamie Zawinski , 13-aug-92.
 
 Please let me know if you find any bugs or make any improvements.
+.SH BUGS
+Please report bugs for this Debian version at https://bugs.debian.org/xscreensaver
\ No newline at end of file
Index: xscreensaver-5.30/driver/xscreensaver-getimage-desktop.man
===
--- xscreensaver-5.30.orig/driver/xscreensaver-getimage-desktop.man
+++ xscreensaver-5.30/driver/xscreensaver-getimage-desktop.man
@@ -53,3 +53,5 @@ any purpose.  It is provided "as is" wit
 warranty.
 .SH AUTHOR
 Jamie Zawinski , 20-Oct-03.
+.SH BUGS
+Please report bugs for this Debian version at https://bugs.debian.org/xscreensaver
Index: xscreensaver-5.30/driver/xscreensaver-getimage-file.man
===
--- xscreensaver-5.30.orig/driver/xscreensaver-getimage-file.man
+++ xscreensaver-5.30/driver/xscreensaver-getimage-file.man
@@ -64,3 +64,5 @@ any purpose.  It is provided "as is" wit
 warranty.
 .SH AUTHOR
 Jamie Zawinski , 14-Apr-01
+.SH BUGS
+Please report bugs for this Debian version at https://bugs.debian.org/xscreensaver
Index: xscreensaver-5.30/driver/xscreensaver-getimage-video.man
===
--- xscreensaver-5.30.orig/driver/xscreensaver-getimage-video.man
+++ xscreensaver-5.30/driver/xscreensaver-getimage-video.man
@@ -49,3 +49,5 @@ any purpose.  It is provided "as is" wit
 warranty.
 

Bug#820007: ipmitool: FTBFS on !linux: usb.c:43:21: fatal error: scsi/sg.h: No such file or directory

[Steven Chamberlain]

tags 820007 + patch
user debian-...@lists.debian.org
usertags 820007 + kfreebsd
thanks

Hi,

Andreas Beckmann wrote:
> ipmitool FTBFS on non-linux architectures due to a missing scsi/sg.h:

Apart from the USB plugin, the rest of ipmitool seems like portable
code.  Please consider disabling the USB plugin on non-Linux arches.

A patch is attached for this.  I've tested it builds again on
kfreebsd-amd64 with this;  maybe it fixes hurd also?

Thanks,
-- 
Steven Chamberlain
ste...@pyro.eu.org
--- debian/rules.orig	2016-03-13 07:31:31.0 +
+++ debian/rules	2016-04-05 23:46:41.519210465 +0100
@@ -10,6 +10,14 @@
 #
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+# Platform-specific features
+DEB_HOST_ARCH_OS	?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
+
+ifneq ($(DEB_HOST_ARCH_OS),linux)
+	# USB implementation is Linux-specific
+	extra_config_opts += --disable-intf-usb
+endif
+
 %:
 	dh $@ --with systemd,autoreconf
 
@@ -31,4 +39,4 @@
 	dh_systemd_enable --no-enable ipmievd.service
 
 override_dh_auto_configure:
-	dh_auto_configure -- --prefix=/usr --with-kerneldir --mandir=/usr/share/man
+	dh_auto_configure -- --prefix=/usr --with-kerneldir --mandir=/usr/share/man $(extra_config_opts)


signature.asc
Description: Digital signature

Bug#816314: Fix patch for 816314.

[Fenix]

Dear maintainer:

As the new version didn't fix this bug, I looked to the code and I find 
the problem (at least for me, but I really don't know how this error has 
been hidden just now. Maybe the old libusb masked the error in the code?).


The problem is in protocol.c

In the code:

--
case Tag_Appl_Prot_Id:
memset(datatypes,0,size * sizeof(uint16));
for ( j = i+1; p.packet.data[3*j] == Tag_Data_Type_Id; j++ ) {
datatypes[j-i-1] = get_uint16(p.packet.data + 3*j + 1);
}
--


The outing condition for the FOR loop throws the segmentation because 
didn't check the limit of j.



I fixed it checking first the counter 'j' and adjust it to the limit of 
the data.



--
case Tag_Appl_Prot_Id:
memset(datatypes,0,size * sizeof(uint16));
for ( j = i+1; (j<=size) && (p.packet.data[3*j] == Tag_Data_Type_Id); 
j++ ) {

datatypes[j-i-1] = get_uint16(p.packet.data + 3*j + 1);
}
--


I attach the patch file that fix this bug.

This is my first time I send a patch, so maybe it doesn't correct. If 
you need more information or anything else feel free to ask.



Thanks.
commit da9c57e496f5b88d875329e57fb7d47b3b5e84a9
Author: Fenix 
Date:   Wed Apr 6 00:25:15 2016 +0200

Fix #816314 error Segmentation Fault

diff --git a/src/protocol.c b/src/protocol.c
index 37f66b4..a0c0b36 100644
--- a/src/protocol.c
+++ b/src/protocol.c
@@ -583,7 +583,7 @@ garmin_read_a000_a001 ( garmin_unit * garmin )
 	  break;
 	case Tag_Appl_Prot_Id:
 	  memset(datatypes,0,size * sizeof(uint16));
-	  for ( j = i+1; p.packet.data[3*j] == Tag_Data_Type_Id; j++ ) {
+	  for ( j = i+1; (j<=size) && (p.packet.data[3*j] == Tag_Data_Type_Id); j++ ) {
 	datatypes[j-i-1] = get_uint16(p.packet.data + 3*j + 1);
 	  }
 	  garmin_assign_protocol(garmin,data,datatypes);

Bug#814644: [lvm2] Stupid changes in /etc/lvm/lvm.conf again and again

[Iván Baldo]

Hello. 
Isn't UCF designed to solve this issue? 
Thanks. 

-- 
Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ 
Freelance C++/PHP programmer and GNU/Linux systems administrator. 
The sky is not the limit! 

Bug#778794: Updated 2.3.8 Upstream

[Rob McAninch]

There is a 2.3.8 upstream package that addresses the mariadb-client.

Looks like a minor update separate from the 2.93 or whatever that is the 
rewritten beta. 

Bug#819625: [Pkg-utopia-maintainers] Bug#819625: network-manager-gnome: Wireless networks unaccessible

[Michael Biebl]

Am 05.04.2016 um 23:33 schrieb Hynek Vychodil:
> Package: network-manager-gnome
> Version: 1.1.92-1
> Reopen
> 
> It is still broken in 1.1.92-1. Unrelated to the network-manager.
> network-manager-gnome 1.1.90-3 with network-manager 1.1.92-1
> works. network-manager-gnome 1.1.92-1 with network-manager 1.1.92-1
> doesn't. Please don't close unless fixed and verified.

Please report this issue upstream at
https://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager

Thanks


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



signature.asc
Description: OpenPGP digital signature

Bug#819190:

[Bernat Arlandis]

El lun., 4 abr. 2016 a las 12:10, Luca Boccassi ()
escribió:

> Thanks, this is useful info. If you run
> /usr/lib/nvidia/check-for-mismatching-nvidia-module manually now (with
> the current version as the parameter, eg: "340.96"), does it still
> hang? If so, could you please add "set -x" at the top and run again,
> to see where it hangs exactly?
>

It's not hanging anymore. I'm sorry I didn't think about this myself. I
hope someone having this problem can try it since this could certainly
help. I've tried reproducing with a few steps but it didn't happen again.


> When you installed the legacy and removed the current, do you still
> have the logs? Which packages exactly did you remove? Did you issue a
> --purge?  There might be a log in /var/log/apt/history.log
>

I'm attaching the logs.


> Not all packages are duplicated between -current and -legacy, one of
> the possibilities is that one of those got removed and that's what
> might have caused the issue.


I don't know exactly what I did. I don't use this computer very much and
there were some time lapses between the actions that led to this situation.
I didn't have a clear idea of the actions to take to upgrade to the legacy
driver, and I like to fiddle with packages plus the upgrades in testing, so
it's very possible that I broke something but I didn't ever force the
package manager to do anything.

By looking at the logs it seems I installed the legacy packages while the
current driver was installed, then tried to remove the current driver by
purging nvidia-driver and nvidia-driver-bin, after that some package
upgrading and installing.

Regards.
-- 
Bernat Arlandis


history.log.1.gz
Description: application/gzip


history.log.2.gz
Description: application/gzip


history.log.gz
Description: application/gzip

Bug#820154: Additional information

[Manuel Lanctot]

Some additional information. I have run an strace of the "xl
migrate-receive"
process on servers with xen-utils-4.4 4.4.1-9+deb8u4 (which fails) and
4.4.1-9+deb8u3 (which works).

On systems with 4.4.1-9+deb8u4 installed, strace shows exactly 395 lines
like
this one:
  ioctl(5, SNDCTL_DSP_RESET, 0x7ffeb47b44b0) = -1 EAGAIN (Resource
temporarily unavailable)

On systems with 4.4.1-9+deb8u3 installed, these hundreds of lines do not
appear
at all - on servers that have identical hardware as those running
4.4.1-9+deb8u4.

I can provide the entire strace output if needed.

Bug#743625: aptitude: internal error

[Manuel A. Fernandez Montecelo]

Control: forcemerge 587087 743625

--
Manuel A. Fernandez Montecelo 

Bug#807149: infinipath-psm: FTBFS: Unsupported architecture i686

[Ana Guerrero Lopez]

tags 807149 pending
thanks

On Sat, Dec 05, 2015 at 10:27:05PM -0500, Aaron M. Ucko wrote:
> Source: infinipath-psm
> Version: 3.3+7.g05f6f14.open-1
> Severity: important
> Justification: fails to build from source
> 
> infinipath-psm's debian/control file claims
> 
> Architecture: amd64 i386
> 
> but the i386 build fails:
> 
> make[1]: Entering directory '/«BUILDDIR»/infinipath-psm-3.3+7.g05f6f14.open'
> /usr/bin/make INSTALL_PREFIX=/usr libdir=/usr/lib/i386-linux-gnu 
> PSM_HAVE_SCIF=0 USE_PSM_UUID=0 arch=i686  distclean
> make[2]: Entering directory '/«BUILDDIR»/infinipath-psm-3.3+7.g05f6f14.open'
> Makefile:97: *** Unsupported architecture i686.  Stop.
> 
> Please address this discrepancy one way or another.

Fixed in:
http://anonscm.debian.org/cgit/pkg-ofed/infinipath-psm.git/commit/?id=3f5642435bf1e0eeb7c84d95e63845baddfe4d21

Bug#487887: Aptitude command line "remove" no longer respects packages marked to keep

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


(I haven't looked in detail at the problems described in the merged bug
report #693144 and long messages following it, but keeping in the loop
because of the findings and considerations regarding #487887)


Hi,

2008-06-27 04:50 Daniel Burrows:

On Wed, Jun 25, 2008 at 05:16:05AM +0800, Telemachus  was 
heard to say:

On the command line, I can no longer remove a package but keep one of
the auto-installed dependencies. I could swear that I used to be able
to do this:

aptitude purge mpd libshout3+


Maybe it depends on the specific examples, but this works for me with
the following example.

I cannot try with libshout3, because it has other rdeps in my system so
it doesn't get removed anyway, but with libnfs8:

 # aptitude -s purge mpd
 The following packages will be REMOVED:
   libadplug-2.2.1-0v5{u} libbinio1v5{u} libnfs8{u} libwildmidi-config{u} 
libwildmidi1{u} mpd{p}
 0 packages upgraded, 0 newly installed, 6 to remove and 184 not upgraded.
 Need to get 0 B of archives. After unpacking 2,160 kB will be freed.

 Note: Using 'Simulate' mode.
 Do you want to continue? [Y/n/?] n
 Abort.

 # aptitude -s purge mpd libnfs8+
 libnfs8 is already installed at the requested version (1.9.8-1)
 libnfs8 is already installed at the requested version (1.9.8-1)
 The following packages will be REMOVED:
   libadplug-2.2.1-0v5{u} libbinio1v5{u} libwildmidi-config{u} libwildmidi1{u} 
mpd{p}
 0 packages upgraded, 0 newly installed, 5 to remove and 184 not upgraded.
 Need to get 0 B of archives. After unpacking 1,905 kB will be freed.

 Note: Using 'Simulate' mode.
 Do you want to continue? [Y/n/?] n
 Abort.



 I thought this used to work as well.  But I think I've found the
problem in the code, and it goes back to at least 2002.  Can you verify
that this was working before?  (because I could swear I remember using
it)  This may be due to the changes last year in how automatic packages
are handled (although I can't see how).  For my own future reference,
the problem is that I use an action group to defer computation of, e.g.,
unused packages, until I'm done applying all the command-line actions.
That's probably good overall, but it does mean that install commands
won't cancel unused-removals since the unused-removal hasn't taken
effect yet.

 Oh, the other thing that I can see that might have affected this is
the change that caused the "install" operation on a package to not
affect its automatic flag unless the package was already installed.


I don't know if Daniel Burrows had changed something to make this work
at the time without closing the bug (doesn't look like it, due to the
bug merged later), if something has changed later on fixing this problem
(e.g. in the 0.7 series), if it's an unknown change in libapt that now
causes this to work (e.g. the many changes of apt 1.1), or if it's
erratic and not really fixed.

But in any case...


 Your suggestion seems like a good idea, but I'm not sure what the
follow-on consequences would be if I just slapped it in right now.
However, you can get a similar effect by doing:

# aptitude remove mpd "libshout3"


I think that this is the best way to solve the situation -- to mark the
packages as manually installed, either within the same action or, if it
doesn't work for some reason (tries to be removed before being marked as
manually installed), in a previous action.

If the package that one wants to preserved is (kept) installed but
marked as automatically installed, it can be removed as a result of the
next run, for example.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#820014: ITP: openscenegraph-3.4 -- Portable, high level graphics toolkit for the development high performance graphics applications.

[Sebastiaan Couwenberg]

Hi Alberto,

On 04/05/2016 10:37 PM, Alberto Luaces wrote:
> Sebastiaan Couwenberg writes:
>>
>> Is packaging 3.4 separately really wise?
>>
>> Having two versions of VTK in the distribution is not very fun, I'm not
>> sure if the Release Team will be more appreciative of two versions of
>> OpenSceneGraph.
>>
> 
> Of course maintaining one package is easier than two, but...
>
>>
>> As maintainer of several packages that build depend on
>> libopen{scenegraph,threads}-dev I'm strongly in favour of a single
>> openscenegraph source package. Let's just prepare the transition to 3.4
>> in experimental.
>>
> 
> Currently, upstream *actively* updates 3.2 and 3.4 series.  You can
> watch from their downloads page that latest releases (3.2.3 and 3.4.0)
> were released the same day; if you go to upstream's repo at github you
> can see that any patch not changing the ABI is back-ported to both: 3.2
> branch was updated just 5 days ago, the same time as their trunk.

It great that upstream still supports the 3.2 branch, it reduces the
pressure to upgrade to 3.4. Although I can't find the release schedule
for OSG to determine how long 3.2 will be maintained alongside 3.4. Do
you have more information from OSG upstream about their plans for 3.2 & 3.4?

> Many of the questions on the user mailing list are about 3.2 series,so
> it is still widely popular, even if we chose to simply disregard Debian
> packages that currently do not work with 3.4, dropping them without any
> warning.

3.2 has been around for a while and is included in most distributions,
very few have 3.4 already (Gentoo, Arch & MacPorts), so everybody not
building from source themselves is still using 3.2.

I don't understand what you're trying to say about dropping packages
without warning. Are you concerned that if Debian switches to 3.4 along
with all reverse dependencies, that OSG users will be inconvenienced by
not having 3.2 in Debian any more?

Dropping reverse dependencies that don't work with 3.4 is an option to
not block the transition for too long, but that shouldn't happen without
warning when properly handling a transition.

AFAIK only Markus Wanner has tested his packages with OSG >= 3.3 and the
results were not encouraging. That just means that his upstreams need to
work on their OSG 3.4 support so we can incorporate those changes in
Debian to keep everything working.

I expect that qgis, osgearth, sfcgal, ossim & otb will all need changes
to support OSG 3.4 too. Once the 3.4 packages are in experimental the
reverse dependencies can be tested and bugs filed.

> I think that your OSG-dependent work is not going to be harder —quite
> the opposite, since you can choose whichever stable version works or
> benefits into your packages, but if that were not the case, I'm of
> course open to suggestions.

Because of the interdependencies of the various GIS packages, I don't
want them to use different OSG versions. That is asking for trouble.

OSG is a reverse dependency of GDAL, which requires rebuilds of its
rdeps every new upstream release. Having another OSG version in the
distribution means at least another reasonably big package that needs to
be tested every time including its rdeps that also depend on gdal. The
VTK5/VTK6 unpleasantness was a constant pain in the gdal transitions
too, I'd rather not have OSG take its place now that we're almost rid of
VTK5.

Please talk to the Release Team about your plans to maintain two OSG
branches, if they don't share the concerns I expect them to have there
is nothing stopping your from packaging 3.4 separately. If they do, it
may save you some work on the separate package.

Kind Regards,

Bas

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

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Dimitri John Ledkov]

On 5 April 2016 at 22:49, Ben Hutchings  wrote:
> Control: reassign -1 src:linux 3.16.7-ckt25-1
> Control: tag -1 moreinfo
>
> On Mon, 2016-04-04 at 22:11 +0300, Juho wrote:
>> Package: general
>> Severity: important
>>
>> After running "apt-get update && apt-get dist-upgrade" on 2016-04-03
>> touchpad of IdeaPad Yoga 13 stopped working. Both touch plate and
>> buttons are not working.
>> This laptop also has a touch screen and it is still working without
>> problems.
>> I'm not sure which package included this 8.4 update might be the faulty
>> one.
> [...]
>
> Most likely the kernel.  However, I can't see any obviously relevant
> changes.  What does this command show:
>
> ls -l /sys/class/input/mouse*/device/device/driver


I have such a Yoga, for me it's the older yoga-13, pre-highdpi pro version.

$ sudo modprobe -r psmouse
$ sudo modprobe psmouse

Makes it "work" again. I have no idea what happens during the boot, or
how come post-boot psmouse module loading results in working
behaviour.
Possibly something is racy in the kernel and initializes differently
"post-boot".

It broke around 3.13 following upstream kernels for me or some such.
And bisecting this using master/vanilla/.0 kernels ended up being
fruitless, at least for me.
So i'm reloading psmouse on my IdeaPad

-- 
Regards,

Dimitri.

Bug#820155: kannel: FTBFS[!linux]: FTW_PHYS undeclared, etc.

[Steven Chamberlain]

Package: kannel
Version: 1.4.4-2
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd

Hi,

kannel stopped building on kfreebsd, and one of the problems is:

utils/start-stop-daemon.c:94:2: error: #error Unknown architecture - cannot 
build start-stop-daemon

The attached 35_kfreebsd.patch uses the __FreeBSD_kernel__ macro to
detect platforms based on the FreeBSD kernel, besides FreeBSD itself.


The next problem is the same as seen on hurd-i386:

| gcc -D_REENTRANT=1 -I. -Igw -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -D_LARGE_FILES= -I/usr/include/libxml2  -Wall 
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wformat 
-Wformat-security -Wmissing-format-attribute -I/usr/include 
-I/usr/include/mysql -I/usr/include/postgresql -I/usr/include/hiredis 
-I/usr/include -o gw/dlr_spool.o -c gw/dlr_spool.c
| ...
| gw/dlr_spool.c:254:86: error: ‘FTW_PHYS’ undeclared (first use in this 
function)

To get that definition (from ftw.h) requires _XOPEN_SOURCE>=500 and
_XOPEN_SOURCE_EXTENDED.  Later, to get pthread_rwlock_t requires
_POSIX_C_SOURCE >= 200112L...

test/test_file_traversal.c has the same bug and requires
_XOPEN_SOURCE>=500 and __USE_MISC...

A nice shorthand might be to define _GNU_SOURCE which includes all of
those and its presence shouldn't break any non-GNU platforms.

Finally there is this warning in gw/smsc/http/clickatell.c:

| gcc -D_REENTRANT=1 -I. -Igw -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -D_LARGE_FILES= -I/usr/include/libxml2  -Wall 
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wformat 
-Wformat-security -Wmissing-format-attribute -I/usr/include 
-I/usr/include/mysql -I/usr/include/postgresql -I/usr/include/hiredis 
-I/usr/include -o gw/smsc/smsc_http.o -c gw/smsc/smsc_http.c
| In file included from gw/smsc/smsc_http.c:864:0:
| gw/smsc/http/clickatell.c: In function ‘clickatell_receive_sms’:
| gw/smsc/http/clickatell.c:235:9: warning: implicit declaration of function 
‘strptime’ [-Wimplicit-function-declaration]

which can also be fixed by defining _GNU_SOURCE.

The attached 36_nonlinux.patch has all of that.  I tested only that it
builds on kfreebsd-amd64 sid, but hopefully it fixes hurd builds too.

Thanks!

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Date: Tue, 05 Apr 2016 22:00:19 +0100
From: Steven Chamberlain 
Subject: support GNU/kFreeBSD using FreeBSD code

--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
@@ -88,7 +88,7 @@
 #define OSHURD
 #elif defined(SunOS)
 #elif defined(__CYGWIN__)
-#elif defined(__FreeBSD__) || defined(__APPLE__)
+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__APPLE__)
 #define FreeBSD
 #else
 #error Unknown architecture - cannot build start-stop-daemon
--- a/gw/smsc/http/clickatell.c
+++ b/gw/smsc/http/clickatell.c
@@ -61,6 +61,8 @@
  * Stipe Tolj , 
  */
 
+#define _GNU_SOURCE
+
 #include "gwlib/gwlib.h"
 
 
Date: Tue, 05 Apr 2016 23:08:31 +0100
From: Steven Chamberlain 
Subject: Define _GNU_SOURCE to use X/Open features

Define _GNU_SOURCE to get nftw() macros (XOPEN_SOURCE_EXTENDED)
strptime() (XOPEN_SOURCE), pthread_lock_t (POSIX.1-2001) and others.

--- a/gw/dlr_spool.c
+++ b/gw/dlr_spool.c
@@ -64,6 +64,8 @@
  * Stipe Tolj 
  */
 
+#define _GNU_SOURCE
+
 #include 
 #include 
 #include 
--- a/gw/smsc/smsc_http.c
+++ b/gw/smsc/smsc_http.c
@@ -111,6 +111,8 @@
  * Tobias Weber 
  */
 
+#define _GNU_SOURCE
+
 #include 
 #include 
 #include 
--- a/test/test_file_traversal.c
+++ b/test/test_file_traversal.c
@@ -58,6 +58,8 @@
  * test_file_traversal.c - simple file traversal testing
  */
 
+#define _GNU_SOURCE
+
 #include 
 #include 
 #include 

Bug#504804: forwarded

[Santiago Ruano Rincón]

Control: forwarded -1 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23227
thanks

Bug#820091: [pkg-horde] Bug#820091: Switch from php-mongo to php-mongodb is needed

[Ondřej Surý]

Hi Mathieu,

On Tue, Apr 5, 2016, at 21:42, Mathieu Parent wrote:
> Just for my information, is there any plan to ship php-mongodb?

Yes, I am just waiting for libbson and libmongoc to leave experimental.
And to the upstream release that won't bundle libbson and libmongoc and
use external libraries without using private symbols. That should happen
quite soon - the extension should be already packaged in git...

> Is the API compatible?

I don't think so, as there this:
https://github.com/mongodb/mongo-php-library to provide a similar
compatible layer on top of mongodb.

-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

Bug#818397: salmon: FTBFS: 'MEM_F_SELF_OVLP' was not declared in this scope

[Sascha Steinbiss]

Hi,

I have pushed a fix for this to git. I would be glad if someone could take a 
look.

Thanks
Sascha

On Wed, 16 Mar 2016 13:36:46 -0700 Martin Michlmayr  wrote:
> Package: salmon
> Version: 0.4.2+ds1-2
> Severity: serious
> 
> This package fails to build in unstable:
> 
> > sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux
> ...
> > /<>/salmon-0.4.2+ds1/src/CollapsedGibbsSampler.cpp: In function 
> > 'void sampleRound_(std::vector > >&, std::vector&, std::vector&, double, std::vector&, 
> > MultinomialSampler&)':
> > /<>/salmon-0.4.2+ds1/src/CollapsedGibbsSampler.cpp:119:18: 
> > warning: unused variable 'classCount' [-Wunused-variable]
> >  uint64_t classCount = eqClass.second.count;
> >   ^
> > /<>/salmon-0.4.2+ds1/src/SalmonQuantify.cpp: In function 'void 
> > mem_collect_intv(const SalmonOpts&, const mem_opt_t*, const bwt_t*, int, 
> > const uint8_t*, smem_aux_t*)':
> > /<>/salmon-0.4.2+ds1/src/SalmonQuantify.cpp:159:36: error: 
> > 'MEM_F_SELF_OVLP' was not declared in this scope
> >  int start_width = (opt->flag & MEM_F_SELF_OVLP)? 2 : 1;
> 
> -- 
> Martin Michlmayr
> Linux for HPE Helion, Hewlett Packard Enterprise
> 
> 

Bug#433568: [PATCH] Add vlan support, based on YunQiang Su patch and Phillip Kern's rewrite, with own additions. Closes: #433568

[Dimitri John Ledkov]

---

 Squished all the patches, and hopefully did the multi-sided merge of
 Yun's, Pkern's, mine and extra debug stuff. This starts to look
 reasonable. Successfully tested this on s390x, and I'm glad I did it
 there, as I had to fix up the s390x specific code path too.

 I do believe it should be possible to interractively set
 vlan. Currently I am asking this question a "medium" priority, but I
 am open to changing to "low". E.g. I find it acceptable that a user
 needs to return to the main menu and change debconf priority.

 Or for example, should we show it in the static-config by default,
 and offer "configure vlan" as an option when automatic network
 detection fails? E.g. alongside the retry-dhcp,
 retry-dhcp-with-hostname, do-wifi, etc. options?

 Preseeding should be trivial - simply preseed netcfg/vlan_id=2654 and
 that's it.

 Updated template texts a bit. Given that the state-machine, templates
 and all of this patch is still under development, I have not sent
 these off to l10n-en for review.

 Any further comments about this update patch?

 Makefile   |  2 +-
 debian/changelog   |  7 +++
 debian/netcfg-common.templates | 28 +++-
 dhcp.c |  2 +-
 netcfg-common.c| 32 --
 netcfg.c   | 20 ++---
 netcfg.h   | 11 +
 static.c   | 12 +++---
 vlan.c | 97 ++
 wireless.c |  4 +-
 write_interface.c  | 19 -
 11 files changed, 213 insertions(+), 21 deletions(-)
 create mode 100644 vlan.c

diff --git a/Makefile b/Makefile
index a15d476..03343c9 100644
--- a/Makefile
+++ b/Makefile
@@ -7,7 +7,7 @@ TARGETS ?= netcfg-static netcfg
 
 LDOPTS = -ldebconfclient -ldebian-installer
 CFLAGS = -W -Wall -Werror -DNDEBUG 
-DNETCFG_VERSION="\"$(NETCFG_VERSION)\"" -I.
-COMMON_OBJS= netcfg-common.o wireless.o write_interface.o ipv6.o
+COMMON_OBJS= netcfg-common.o wireless.o write_interface.o ipv6.o vlan.o
 NETCFG_O   = netcfg.o dhcp.o static.o ethtool-lite.o wpa.o wpa_ctrl.o 
rdnssd.o autoconfig.o
 NETCFG_STATIC_O= netcfg-static.o static.o ethtool-lite.o
 
diff --git a/debian/changelog b/debian/changelog
index f3dd40c..c2dae40 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+netcfg (1.139) UNRELEASED; urgency=medium
+
+  * Add vlan support, based on YunQiang Su patch and Phillip Kern's
+rewrite, with own additions. Closes: #433568
+
+ -- Dimitri John Ledkov   Mon, 04 Apr 2016 12:18:08 +0100
+
 netcfg (1.138) unstable; urgency=medium
 
   [ Hendrik Brueckner ]
diff --git a/debian/netcfg-common.templates b/debian/netcfg-common.templates
index 2b77936..bffded9 100644
--- a/debian/netcfg-common.templates
+++ b/debian/netcfg-common.templates
@@ -26,6 +26,33 @@ _Description: Domain name:
  If you are setting up a home network, you can make something up, but make
  sure you use the same domain name on all your computers.
 
+Template: netcfg/use_vlan
+Type: boolean
+Default: false
+# :sl6:
+_Description: Are you connected to an IEEE 802.1Q VLAN trunk port?
+ Virtual LAN (VLAN) is a concept of partitioning a physical network to create
+ distinct broadcast domains. Packets can be marked for different IDs by
+ tagging, so that a single interconnect (trunk) may be used to transport
+ data for various VLANs.
+ .
+ If your network interface is directly connected to a VLAN trunk port,
+ specifying a VLAN ID may be necessary to get a working connection.
+
+Template: netcfg/vlan_id
+Type: string
+# :sl6:
+_Description: VLAN ID (1-4094):
+ If your network interface is directly connected to a VLAN trunk port,
+ specifying a VLAN ID may be necessary to get a working connection.
+
+Template: netcfg/vlan_failed
+Type: error
+# :sl6:
+_Description: Error setting up VLAN
+ The command used to set up VLAN during the installation returned an
+ error, please go back and try again.
+
 Template: netcfg/get_nameservers
 Type: string
 # :sl1:
@@ -371,4 +398,3 @@ _Choices: ${essid_list} Enter ESSID manually
 # :sl1:
 _Description: Wireless network:
  Select the wireless network to use during the installation process.
-
diff --git a/dhcp.c b/dhcp.c
index fe06950..9476bac 100644
--- a/dhcp.c
+++ b/dhcp.c
@@ -459,7 +459,7 @@ int netcfg_activate_dhcp (struct debconfclient *client, 
struct netcfg_interface
 kill_dhcp_client();
 loop_setup();
 
-interface_up(interface->name);
+netcfg_interface_up(interface);
 
 for (;;) {
 di_debug("State is now %i", state);
diff --git a/netcfg-common.c b/netcfg-common.c
index c6d1d8d..ac2c6df 100644
--- a/netcfg-common.c
+++ b/netcfg-common.c
@@ -267,7 +267,7 @@ int is_raw_80211(const char *iface)
 
 #if defined(__s390__)
 // Layer 3 qeth on s390(x) cannot do arping to test gateway reachability.
-int is_layer3_qeth(const char *iface)
+int 

Bug#820154: 4.4.1-9+deb8u4: impossible to 'lv migrate' with latest stable version

[Manuel Lanctot]

Package: xen-utils-4.4
Version: 4.4.1-9+deb8u4
Severity: important

Dear Maintainer,

   * What led up to the situation?

Upgrading to Debian 8.4. 

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

Doing a live migration to a host running Xen 4.4.1-9+deb8u4, 
from a host running 4.4.1-9+deb8u3 fails every time.

Doing a live migration to a host running Xen 4.4.1-9+deb8u3, 
from a host running 4.4.1-9+deb8u4 works every time.

   * What was the outcome of this action?

A migration to a host with 4.4.1-9+deb8u4 results in this:

~ # xl migrate app01 host01
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x0/0x0/1076)
Loading new save file  (new xl fmt info 0x0/0x0/1076)
 Savefile contains xl domain config
xc: progress: Reloading memory pages: 53248/10485765%
xc: progress: Reloading memory pages: 105472/1048576   10%

xc: progress: Reloading memory pages: 996352/1048576   95%
xc: progress: Reloading memory pages: 1048810/1048576  100%
migration target: Transfer complete, requesting permission to start domain.
migration receiver stream contained unexpected data instead of ready message
(command run was: exec ssh host01 xl migrate-receive )
libxl: error: libxl_utils.c:396:libxl_read_exactly: file/stream truncated 
reading GO message from migration stream
migration target: Failure, destroying our copy.
migration target: Cleanup OK, granting sender permission to resume.
Migration failed, resuming at sender.

   * What outcome did you expect instead?

Doing a migration to a host that is still on Debian 8.3 (Xen 4.4.1-9+deb8u3):

~ # xl migrate app01 host02
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x0/0x0/1076)
Loading new save file  (new xl fmt info 0x0/0x0/1076)
 Savefile contains xl domain config
xc: progress: Reloading memory pages: 53248/10485765%
xc: progress: Reloading memory pages: 105472/1048576   10%

xc: progress: Reloading memory pages: 996352/1048576   95%
xc: progress: Reloading memory pages: 1048919/1048576  100%
migration target: Transfer complete, requesting permission to start domain.
migration sender: Target has acknowledged transfer.
migration sender: Giving target permission to start.
migration target: Got permission, starting domain.
migration target: Domain started successsfully.
migration sender: Target reports successful startup.
Migration successful.


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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 xen-utils-4.4 depends on:
ii  e2fslibs  1.42.12-1.1
ii  libc6 2.19-18+deb8u4
ii  libncurses5   5.9+20140913-1+b1
ii  libtinfo5 5.9+20140913-1+b1
ii  libxen-4.44.4.1-9+deb8u4
ii  libxenstore3.04.4.1-9+deb8u4
ii  libyajl2  2.1.0-2
ii  python2.7 2.7.9-2
pn  python:any
ii  xen-utils-common  4.4.1-9+deb8u4

Versions of packages xen-utils-4.4 recommends:
ii  bridge-utils   1.5-9
ii  grub-xen-host  2.02~beta2-22+deb8u1
ii  qemu-system-x861:2.1+dfsg-12+deb8u5a
ii  xen-hypervisor-4.4-amd64 [xen-hypervisor-4.4]  4.4.1-9+deb8u4

xen-utils-4.4 suggests no packages.

-- no debconf information

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Ben Hutchings]

Control: reassign -1 src:linux 3.16.7-ckt25-1
Control: tag -1 moreinfo

On Mon, 2016-04-04 at 22:11 +0300, Juho wrote:
> Package: general
> Severity: important
> 
> After running "apt-get update && apt-get dist-upgrade" on 2016-04-03 
> touchpad of IdeaPad Yoga 13 stopped working. Both touch plate and 
> buttons are not working.
> This laptop also has a touch screen and it is still working without 
> problems.
> I'm not sure which package included this 8.4 update might be the faulty 
> one.
[...]

Most likely the kernel.  However, I can't see any obviously relevant
changes.  What does this command show:

    ls -l /sys/class/input/mouse*/device/device/driver

?

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot


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

Bug#651410: aptitude: in dependency resolutions, aptitude should favor library removal

[Vincent Lefevre]

On 2016-04-01 19:58:20 +0100, Manuel A. Fernandez Montecelo wrote:
> 2016-03-22 13:27 Vincent Lefevre:
> > A single removal is bad if it is an application.
> 
> That's strange coming from you, who use the resolver costs of minimizing
> removals ;-)

Not really. What I want is:
  * no removals = good
  * any number of removals = bad

Minimizing removals seems to be the best choice to do that. I would
prefer something like "removals ? 1 : 0", but that's not possible.

Now, the "removals" solution cost guarantees that the first solution
doesn't contain any removal. So, that's OK. I can do a clean upgrade
first (without removals at all), then inspect what to do about the
removals. Without the "removals" solution cost, this is not possible.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#816548: krb5: [INTL:de] Initial German translation

[Chris Leick]

Hi Sam,

now, I've attached the recent version of the German translation.

Kind regards,
Chris


de.po.gz
Description: application/gzip

Bug#819724: Please find a second maintainer

[Tormod Volden]

severity wishlist

On Fri, Apr 1, 2016 at 3:29 PM, Goswin von Brederlow  wrote:
> Package: xscreensaver
> Severity: important
>
> The xscreensaver package has 120 bugs going back over 9 years that are
> just rotting in the BTS without attention. Some of them are tagged
> security, some tagged patch. A lot of bugs have not been modified
> since shortly after they were reported.

Hi Goswin,

The BTW can probably need some triaging. I am aware of (hopefully) all
bugs there though, and there is nothing that really demands attention.
There are a lot of wishes, patches that should go upstream or down the
drain - we don't want to carry the support burden for them - and some
are graphic drivers issues.

>
> I sad to say but you are not doing as good a job maintaining the
> package as you should. Maybe you aren't that interested in
> xscreensaver anymore or you don't have the time or any number of other
> valid reasons. But fact is that bugs are being left to rot in the BTS.

I am maintaining the package as I have been doing over many, many
years. Security problems are taken care of immediately and upstream
releases are packaged in due time. The number of bugs have been very
stable over the years. I don't have any strong motivation to work much
more intensive on it than I have done, that's for sure.

Some bugs can sure be closed, but why is that important to you? They
are there mainly to help the maintainers, and people contributing.
Granted, I am sure many bugs can be closed though, or moved to
wishlist. It is just not the highest of my priorities, and nobody else
has stepped up to do it. Hey wait - one guy mentioned some willingness
a few weeks ago - maybe we are lucky, I will follow that up.

> For example #403557 should have been tagged more-info and eventually
> closed as unreproducible 9 years ago and is still there tagged
> security.

Are you not able to tag it as more-info? If you are unable to help
because of technical issues, we can probably figure that out. It is
not like the maintainer has to do everything and nobody else can help.

>
> So I urge you to please find a new maintainer to either take over (in
> the worst case) or simply work alongside yourself to help clean up the
> backlog of bugs in this package.

This is not how it works in practice. Anyone interested in the package
will help to maintain the package, sending patches against the VCS
etc. I don't see why nobody can just help out triaging bugs. People
helping out over time can become co-maintainers. If I don't do much
useful any longer, I can pull out and the other people will remain
maintainers. This is how I got into this. If they are not genuinely
interested (and pop up by themselves) there are small changes they
will stick around.

>
> If it is just that you left bugs open for so long (or inherited them
> from a revious maintainer) that now you are swamped and can't catch up
> then you could also contact the front desk to get some prospective new
> DDs assigned to look over and triage bugs. It's good experience for
> them and the package would hopefully get back on track.

Yes, it might be a good idea to get some people working on this. But
it won't help me to get someone to just close bugs for the sake of
closing bugs for then to disappear again. We need someone with long
time commitment. Do you have a link to this "front desk"? I am
optimistically imagining a long line of people longing to help out
maintaining 8-)

>
> MfG
> Goswin
>
> PS: This is not a personal attack on you but an encouragement to make
> the package the best it can be.

Thanks! All contributions are welcome.

Best regards,
Tormod

Bug#820153: ITP: rfcmarkup -- add HTML markup and links to internet-drafts and RFCs

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 

* Package name: rfcmarkup
  Version : 1.118
  Upstream Author : Henrik Levkowetz 
* URL : https://tools.ietf.org/tools/rfcmarkup
* License : GPL
  Programming Lang: Python
  Description : add HTML markup and links to internet-drafts and RFCs

Add markup to text documents so that any references to Internet-Drafts
or RFCs are changed into hyperlinks, for document authoring.

This is relevant for people who build RFCs within the IETF.  It is a
dependency of pandoc2rfc (see #803892).

Bug#819985: gap-dev: unusable headers (missing config.h)o

[Bill Allombert]

On Mon, Apr 04, 2016 at 05:11:01PM +0200, Julien Cristau wrote:
> Package: gap-dev
> Version: 4r7p9-1
> Severity: serious
> 
> $ echo '#include ' | cpp 
> # 1 ""
> # 1 ""
> # 1 ""
> # 1 "/usr/include/stdc-predef.h" 1 3 4
> # 1 "" 2
> # 1 ""
> # 1 "/usr/include/gap/system.h" 1 3 4
> In file included from :1:0:
> /usr/include/gap/system.h:29:20: fatal error: config.h: No such file or 
> directory
> compilation terminated.
> 
> config.h seems to be shipped in /usr/include/x86_64-linux-gnu/gap, but
> #include "config.h"
> doesn't work...

Maybe the best fix is to add a file
/usr/include/gap/config.h
with
#include 
or
#include 
(and in this case rename 
/usr/include/x86_64-linux-gnu/gap/config.h to
/usr/include/x86_64-linux-gnu/gap/config-arch.h
)

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#819625: network-manager-gnome: Wireless networks unaccessible

[Hynek Vychodil]

Package: network-manager-gnome
Version: 1.1.92-1
Reopen

It is still broken in 1.1.92-1. Unrelated to the network-manager.
network-manager-gnome 1.1.90-3 with network-manager 1.1.92-1
works. network-manager-gnome 1.1.92-1 with network-manager 1.1.92-1
doesn't. Please don't close unless fixed and verified.

thanks

Bug#820152: anope: please make the build reproducible (timestamps)

[Alexis Bienvenüe]

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

Dear Maintainer,

While working on the “reproducible builds” effort [1], we have noticed
that 'anope' could not be built reproducibly.

The attached patch removes build date from the version string. Once
applied, anope can be built reproducibly in our current experimental
framework.

Regards,
Alexis Bienvenüe.

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

diff -Nru anope-2.0.3/debian/patches/series anope-2.0.3/debian/patches/series
--- anope-2.0.3/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ anope-2.0.3/debian/patches/series	2016-04-05 22:53:41.0 +0200
@@ -0,0 +1 @@
+strip_build_date.patch
diff -Nru anope-2.0.3/debian/patches/strip_build_date.patch anope-2.0.3/debian/patches/strip_build_date.patch
--- anope-2.0.3/debian/patches/strip_build_date.patch	1970-01-01 01:00:00.0 +0100
+++ anope-2.0.3/debian/patches/strip_build_date.patch	2016-04-05 22:54:46.0 +0200
@@ -0,0 +1,26 @@
+Description: Strip build date
+ Strip build date from version string, to get reproducible build.
+Author: Alexis Bienvenüe 
+
+--- anope-2.0.3.orig/include/anope.h
 anope-2.0.3/include/anope.h
+@@ -336,8 +336,6 @@ namespace Anope
+ 	template class multimap : public std::multimap { };
+ 	template class hash_map : public TR1NS::unordered_map { };
+ 
+-	static const char *const compiled = __TIME__ " " __DATE__;
+-
+ 	/** The time Anope started.
+ 	 */
+ 	extern CoreExport time_t StartTime;
+--- anope-2.0.3.orig/src/misc.cpp
 anope-2.0.3/src/misc.cpp
+@@ -632,7 +632,7 @@ Anope::string Anope::VersionShort()
+ 
+ Anope::string Anope::VersionBuildString()
+ {
+-	Anope::string s = "build #" + stringify(BUILD) + ", compiled " + Anope::compiled;
++	Anope::string s = "build #" + stringify(BUILD);
+ 	Anope::string flags;
+ 
+ #ifdef DEBUG_BUILD

Bug#363496: Hi

[Michael]

--
Good day

I am Michael, from United States. I browsed through the internet and 
came across your mail.


I would like us to be friends. Do you mind being my friend?

Regards,
Michael.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#819625: network-manager-gnome: Wireless networks unaccessible

[Hynek Vychodil]

Hi,
The bug is still persist there in version 1.1.92-1. Downgrading all three
packages to the 1.1.90-3 still keeps working.

Hynek Vychodil

Bug#820151: kfreebsd-10: non-DFSG mode (for ubuntuBSD)

[Jon Boden]

Package: kfreebsd-10
Version: 10.1~svn274115-4+kbsd8u3
Severity: wishlist
Tags: patch

Hi

This patch has no effect on Debian but it enables "non-DFSG mode" when 
compiling kfreebsd-10 on ubuntuBSD. Please could you apply it to make it easier 
for us to resync with kfreebsd-10?

It also makes it easier for Debian users if they want to build a custom package 
with sourceless bits (by just changing one line in debian/rules).

Thanks a lot

-- 
Jon Boden

ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!

http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD
Index: debian/control.in
===
--- debian/control.in	(revision 5986)
+++ debian/control.in	(working copy)
@@ -23,6 +23,7 @@
  pkg-config,
  libsbuf-dev (>= 9.0+ds1-2),
  kernel-wedge (>= 2.79) [kfreebsd-any],
+ lsb-release,
 Standards-Version: 3.9.2
 
 Package: kfreebsd-source-@version@
Index: debian/local/ar9300_devid.h
===
--- debian/local/ar9300_devid.h	(revision 0)
+++ debian/local/ar9300_devid.h	(working copy)
@@ -0,0 +1,79 @@
+/*
+ * Copyright (c) 2008-2011 Atheros Communications Inc.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifndef __AR9300_DEVID_H__
+#define __AR9300_DEVID_H__
+
+/* Atheros chipsets */
+#define AR_SREV_VERSION_AR5416_PCI	0xD
+#define AR_SREV_VERSION_AR5416_PCIE	0xC
+#define AR_SREV_REVISION_AR5416_10	0
+#define AR_SREV_REVISION_AR5416_20	1
+#define AR_SREV_REVISION_AR5416_22	2
+#define AR_SREV_VERSION_AR9100		0x14
+#define AR_SREV_VERSION_AR9160		0x40
+#define AR_SREV_REVISION_AR9160_10	0
+#define AR_SREV_REVISION_AR9160_11	1
+#define AR_SREV_VERSION_AR9280		0x80
+#define AR_SREV_REVISION_AR9280_10	0
+#define AR_SREV_REVISION_AR9280_20	1
+#define AR_SREV_REVISION_AR9280_21	2
+#define AR_SREV_VERSION_AR9285		0xC0
+#define AR_SREV_REVISION_AR9285_10	0
+#define AR_SREV_REVISION_AR9285_11	1
+#define AR_SREV_REVISION_AR9285_12	2
+#define AR_SREV_VERSION_AR9287		0x180
+#define AR_SREV_REVISION_AR9287_10	0
+#define AR_SREV_REVISION_AR9287_11	1
+#define AR_SREV_REVISION_AR9287_12	2
+#define AR_SREV_REVISION_AR9287_13	3
+#define AR_SREV_VERSION_AR9271		0x140
+#define AR_SREV_REVISION_AR9271_10	0
+#define AR_SREV_REVISION_AR9271_11	1
+#define AR_SREV_VERSION_AR9300		0x1c0
+#define AR_SREV_REVISION_AR9300_20	2 /* 2.0 and 2.1 */
+#define AR_SREV_REVISION_AR9300_22	3
+#define AR_SREV_VERSION_AR9330		0x200
+#define AR_SREV_REVISION_AR9330_10	0
+#define AR_SREV_REVISION_AR9330_11	1
+#define AR_SREV_REVISION_AR9330_12	2
+#define AR_SREV_VERSION_AR9485		0x240
+#define AR_SREV_REVISION_AR9485_10	0
+#define AR_SREV_REVISION_AR9485_11	1
+#define AR_SREV_VERSION_AR9340		0x300
+#define AR_SREV_REVISION_AR9340_10	0
+#define AR_SREV_REVISION_AR9340_11	1
+#define AR_SREV_REVISION_AR9340_12	2
+#define AR_SREV_REVISION_AR9340_13	3
+#define AR_SREV_VERSION_AR9380		0x1C0
+#define AR_SREV_VERSION_AR9580		0x1C0
+#define AR_SREV_REVISION_AR9580_10	4 /* AR9580 1.0 */
+#define AR_SREV_VERSION_AR9460		0x280
+#define AR_SREV_VERSION_AR9462		0x280
+#define AR_SREV_REVISION_AR9462_20	2
+#define AR_SREV_REVISION_AR9462_21	3
+
+/* Qualcomm Atheros chipsets */
+#define AR_SREV_VERSION_QCA9565		0x2C0
+#define AR_SREV_REVISION_QCA9565_10	0
+#define AR_SREV_REVISION_QCA9565_101	1
+#define AR_SREV_REVISION_QCA9565_11	2
+#define AR_SREV_VERSION_QCA9550		0x400
+#define AR_SREV_VERSION_QCA9531		0x500
+#define AR_SREV_REVISION_QCA9531_10	0
+#define AR_SREV_REVISION_QCA9531_11	1
+
+#endif
Index: debian/patches/999_config.diff
===
--- debian/patches/999_config.diff	(revision 5986)
+++ debian/patches/999_config.diff	(working copy)
@@ -48,7 +48,7 @@
  options 	SYSVSHM			# SYSV-style shared memory
 --- /dev/null
 +++ b/sys/conf/DEBIAN
-@@ -0,0 +1,52 @@
+@@ -0,0 +1,49 @@
 +# Common options to all Debian GNU/kFreeBSD kernels
 +
 +options		LINPROCFS
@@ -87,9 +87,6 @@
 +options		ALTQ_HFSC	# Hierarchical Packet Scheduler (HFSC)
 +options		ALTQ_PRIQ	# Priority Queuing (PRIQ)
 +
-+# Disable binary blobs
-+include		WITHOUT_SOURCELESS
-+
 +# In order to enable IPSEC you MUST also add device crypto to
 +# your kernel configuration
 +device  crypto  # core crypto 

Bug#812174: ITP: letsencrypt-sh -- ACME client implemented in Bash

[Mattia Rizzolo]

On Tue, Mar 29, 2016 at 05:45:44PM +0200, Daniel Beyer wrote:
> Hi Mattia,
> 
> Am Montag, den 28.03.2016, 21:44 + schrieb Mattia Rizzolo:
> > Hi Daniel :)
> > 
> > On Sun, Mar 27, 2016 at 01:01:18PM +0200, Daniel Beyer wrote:
> > (...)
> > 
> > I think your apache snippet is cool, actually.
> > I improved it a bit the thing, by moving it to be a config snippet,
> > instead of being treated as a virtualhost, and by using dh_apache2
> > instead of manually try (and fail, e.g. you forgot to remove the thing
> > when removing the package) to get it right :)
> > 
> 
> The infrastructure I needed letsencrypt.sh for enables the proxy module
> in a virtualhost, rather doing it the debian-"mods-enabled"-way. That's
> why it was a virtualhost (it had to be loaded at the very end to work).
> But this is a rather uncommon setup and providing a config snippet is
> definitely the way to go here. Thanks for changing it and switching to
> dh_apache2.

Umh, now, I haven't checked as atm I don't have anything handy to check
this, and I'm not and apache2 master, but it really ought to work
anyway; unless you explicitly allow it again it should really work.

On the bright side, I've made changes to my little deployment and now
I'm using the -apache2 package too.
I've made some changes to it, I think the most "difficult" change is
commit 365c3380ccab44b611d7a3edd6a9c4d6cf8ccabe please tell me what you
think of that.  I wrote my reasons in the commit msg, but tell me :)

> > I've already installed the resulting .deb on one of my servers, but I
> > have to admit that I already have some infrastructure around LE, so I
> > won't use the packaged configuration, nor the apache snippet by myself
> > (at least not yet).
> > 
> 
> I have quite some infrastructure that I would like to use it for. I
> check if I can migrate one candidate to fully make use of the packaging
> later this week.

How did it went?

> > Something I need help/suggestion for: I quite dislike the name
> > letsencrypt.sh-challenge-response-apache2, I find it way too long :\
> > Can we think of something more nice? :)
> > 
> 
> Yeah, you're right - pretty unhandy. I renamed it to simply
> letsencrypt.sh-apache2 in debian/master - but feel free to propose an
> other name.

that name's cool for me! :)

> I would like to see the following features added to the packaging:
> - Ship some automatism, so the renews do not need to be done manually

I don't know.  I've yet to enable automatic renewals.  Given that I'm
still doing stuff and playing with it I run so often anyway.

Also, automatic renewals implies cron: that means deciding how often you
want to do that.  And considering that letsencrypt.sh does not have a
silent mode really useful for cron (I wouldn't want to be "constantly"
emailed just to know that nothing has been done).

And also means we need to install a letsencrypt.sh user or something to
run it with, and then IMHO it'll become a really complicated package for
a shell scrip...

> - Add ngnix support (similar to the apache2 one)

I'm not a ngnix person, I wouldn't know how to do it.
What about leaving it for somebody else to supply a patch?

> Besides that, it would be wise to deny execution by user root per
> default, but this should better be implemented upstream. I'll try to
> work on this later this week - or more likely on the weekend.

Yes, this should be done upstream.


What do think is it needed after all of this?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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#819868: qtwebkit: Make determineNumberOfCPUs work on kfreebsd

[Jon Boden]

On Mon, Apr 04, 2016 at 05:07:09PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Monday 04 April 2016 20:57:08 Jon Boden wrote:
> [snip]
> > > - What about Qt5's qtwebkit? Dos it suffer from the same problem? If so,
> > > can you provide a patch too?
> > 
> > I can check. What's the package name? Is it in Debian sid?
> 
> qtwebkit-opensource-src, it's on stable already :)

Hi Lisandro

I just checked qtwebkit-opensource-src, and the patch it needs is exactly the 
same I sent for qtwebkit.

Should I file a new bug report?

-- 
Jon Boden

ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!

http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD

Bug#820058: mirror submission for mirror.wlg.tmnetwork.co.nz

[Alex Smith (Platform)]

Hi,

For the time being just /debian/ - we are finding the sync for /debian-cd/ 
quite slow (still in progress as of just now) so I'll need to find a better 
upstream for use from here before I submit that.

/debian-security/ is one we use ourselves as the official ones are very slow 
from here in New Zealand unfortunately. If there was any interest in one in 
this area we would be interested to know if it was an area we could help with.

Alex Smith
Systems Engineer – Trade Me


-Original Message-
From: Donald Norwood [mailto:dnorw...@portalus.com] 
Sent: Wednesday, 6 April 2016 8:18 AM
To: 820...@bugs.debian.org
Cc: Email System Engineers 
Subject: Re: mirror submission for mirror.wlg.tmnetwork.co.nz

control: tag -1 +moreinfo

Hi,

The mirror submission looks good. I have a question on what you are offering or 
plan to offer. On your top level directory the mirror shows:
/debian/, /debian-cd/, and /debian-security/.

There is no real need to carry /debian-security/ as the security mirrors are 
official mirrors that are aliased from our top level mirrors. We do not 
encourage or announce unofficial security mirrors. That being said, if you 
mirror security for your own network and clients that you do so with that 
understanding.

The /debian-cd/ directory is incomplete, particularly the /project/ directory. 
Do you plan on carrying /debian-cd/ ?

Looking forward to your response.

Best regards,

Donald Norwood
-Debian Mirrors Team



On Tue, 05 Apr 2016 04:56:44 + "Systems Team"  wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirror.wlg.tmnetwork.co.nz
> Type: leaf
> Archive-architecture: amd64 i386
> Archive-http: /debian/
> Archive-rsync: debian/
> IPv6: no
> Archive-upstream: mirrors.kernel.org
> Updates: four
> Maintainer: Systems Team 
> Country: NZ New Zealand
> Location: Wellington, New Zealand
> Sponsor: Trade Me Limited http://www.trademe.co.nz/
> 
> 

Bug#819595: xscreensaver: please make the build reproducible

[Tormod Volden]

tags 802914 pending
thanks

On Thu, Mar 31, 2016 at 1:01 AM, Sascha Steinbiss wrote:
>
> I have attached a patch to use a fixed, sorted order for these files.
> This makes the build reproducible for me in my local test environment.

Thanks for the patch, I have applied it.

Tormod

Bug#745027: Missing dependencies

[Stephen Paul Weber]

Debian stable users will start reporting bugs for really old releases of 
vdirsyncer on my issue tracker. And while Debian's documentation may have 
made this situation extremely clear, apparently nobody reads it. This is 
already happening with other software.


Hmm.  That is very inconsiderate of such users.  I would expect users who 
know how to report bugs to be better educated about where to report them 
(that is, not to report to upstreams, for example).


Because of this I think having vdirsyncer in Debian Sid only would be 
a better idea.


That is very sad.  Hopefully I will be able to use the sid package as 
a basis for a backport for my users.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

Bug#820148: autopkgtest: please make the build reproducible (environment)

[Martin Pitt]

Control: tag -1 pending

Hello Alexis,

Alexis Bienvenüe [2016-04-05 22:29 +0200]:
> Depending on the locale (LC_COLLATE I think), [a-z] can include or not
> capitals, so that in the Makefile, [a-z]* can match SKELETON or not.

Urgh, thanks for spotting this! I think it's a bit academic as
reliable Debian build environments should not use random locales but C
or C.UTF-8, but fixing this is nice anyway.

Applied:
http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=7b1ed33b

Thanks!

Martin

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

Bug#820150: zam-plugins: FTBFS[!linux]: Unsupported platform

[Steven Chamberlain]

Package: zam-plugins
Version: 3.6~repack2-3
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd

Hi,

zam-plugins stopped building on kfreebsd and hurd due to some
platform-detection code that doesn't know about GNU/kFreeBSD or Hurd.

I suggest it treats those as Linux because the macros don't enable
kernel-specific features anyway, just decide whether to include certain
headers.

Please see attached patch fixing this.  Thanks!

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Date: Tue, 05 Apr 2016 21:37:17 +0100
From: Steven Chamberlain 
Subject: distrho: support GNU platforms other than Linux

Treat all glibc-based platforms as DISTRHO_OS_LINUX, even those not
based on Linux such as GNU/kFreeBSD or GNU/Hurd.

Also, wrap ifdefs around sa_restorer which really is specific to (some)
Linux platforms.  (A feature-test macro would be better, though it is
obsolete and maybe should be removed altogether...)

--- a/dpf/distrho/src/DistrhoDefines.h
+++ b/dpf/distrho/src/DistrhoDefines.h
@@ -37,7 +37,7 @@
 #  define DISTRHO_DLL_EXTENSION "dylib"
 # elif defined(__HAIKU__)
 #  define DISTRHO_OS_HAIKU  1
-# elif defined(__linux__)
+# elif defined(__linux__) || defined(__GLIBC__)
 #  define DISTRHO_OS_LINUX  1
 # endif
 #endif
--- a/dpf/distrho/src/DistrhoPluginJack.cpp
+++ b/dpf/distrho/src/DistrhoPluginJack.cpp
@@ -75,13 +75,17 @@
 
 sint.sa_handler  = closeSignalHandler;
 sint.sa_flags= SA_RESTART;
+#if defined(__linux__)
 sint.sa_restorer = nullptr;
+#endif
 sigemptyset(_mask);
 sigaction(SIGINT, , nullptr);
 
 sterm.sa_handler  = closeSignalHandler;
 sterm.sa_flags= SA_RESTART;
+#if defined(__linux__)
 sterm.sa_restorer = nullptr;
+#endif
 sigemptyset(_mask);
 sigaction(SIGTERM, , nullptr);
 }

Bug#745027: Missing dependencies

[Markus Unterwaditzer]

On Tue, Apr 05, 2016 at 03:08:44PM -0500, Stephen Paul Weber wrote:
> To be clear: this is only true if you are the Debian maintainer for
> vdirsyncer.  If someone else is the maintainer (as, reading this thread, it
> seems is the intent) then it is *their* job to backport any relevant bugfixes
> and provide any support to Debian stable users.  As upstream, you only ever
> have to support official versions that you provide, of course, and not Debian
> versions.

Security backports are not at all what I'm talking about. I mean that Debian
stable users will start reporting bugs for really old releases of vdirsyncer on
my issue tracker. And while Debian's documentation may have made this situation
extremely clear, apparently nobody reads it. This is already happening with
other software.

And while I do apprechiate packagers of all operating systems caring about my
software (and don't want to dismiss the work they're doing), I'm completely
opposed to Debian's model of patching older releases of deprecated software
just for their platform. It essentially forks that older release into a
completely new project, but keeps the name and contact information from the
original project intact. I would call it phishing, except this is probably
well-documented.

Because of this I think having vdirsyncer in Debian Sid only would be a better
idea.

Bug#820014: ITP: openscenegraph-3.4 -- Portable, high level graphics toolkit for the development high performance graphics applications.

[Alberto Luaces]

Hi Sebastiaan,

Sebastiaan Couwenberg writes:

>
> Is packaging 3.4 separately really wise?
>
> Having two versions of VTK in the distribution is not very fun, I'm not
> sure if the Release Team will be more appreciative of two versions of
> OpenSceneGraph.
>

Of course maintaining one package is easier than two, but...

>
> As maintainer of several packages that build depend on
> libopen{scenegraph,threads}-dev I'm strongly in favour of a single
> openscenegraph source package. Let's just prepare the transition to 3.4
> in experimental.
>

Currently, upstream *actively* updates 3.2 and 3.4 series.  You can
watch from their downloads page that latest releases (3.2.3 and 3.4.0)
were released the same day; if you go to upstream's repo at github you
can see that any patch not changing the ABI is back-ported to both: 3.2
branch was updated just 5 days ago, the same time as their trunk.

Many of the questions on the user mailing list are about 3.2 series,so
it is still widely popular, even if we chose to simply disregard Debian
packages that currently do not work with 3.4, dropping them without any
warning.

I think that your OSG-dependent work is not going to be harder —quite
the opposite, since you can choose whichever stable version works or
benefits into your packages, but if that were not the case, I'm of
course open to suggestions.

Regards,

Alberto

Bug#819831: [Pkg-rust-maintainers] Bug#819831: Bug#819831: cargo: FTBFS: unable to satisfy build-depends

[Luca BRUNO]

On Monday, April 04, 2016 11:14:00 PM Luca BRUNO wrote:

> I think we may align cargo on that and just build with libcurl4-gnutls-dev
> instead. Upstream prefers building with libcurl+openssl,
> but I guess switching to gnutls shouldn't cause any issue here.

I've just uploaded 0.8.0-2 with this change, with a low urgency
(just to be sure it didn't break anything).

Cheers, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.| lucab (AT) debian.org
`. `'`  | GPG: 0xBB1A3A854F3BBEBF
  `- http://www.debian.org  | Debian GNU/Linux Developer


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

Bug#820149: docker.io: FTBFS in stretch

[Santiago Vila]

Package: src:docker.io
Version: 1.8.3~ds1-2
Severity: serious

Dear maintainers: As you righly pointed out in Bug#818122, docker.io
still FTBFS in stretch (but for other reasons), so I'm filing a new bug.

-
# WARNING! I don't seem to be running in the Docker container.
# The result of this command might be an incorrect build, and will not be
#   officially supported.
#
# Try this instead: make all
#

---> Making bundle: dynbinary (in bundles/1.8.3/dynbinary)
# github.com/docker/docker/daemon/execdriver/native/template
.gopath/src/github.com/docker/docker/daemon/execdriver/native/template/default_template.go:40:
 unknown configs.Cgroup fie
ld 'AllowAllDevices' in struct literal
.gopath/src/github.com/docker/docker/daemon/execdriver/native/template/default_template.go:41:
 unknown configs.Cgroup fie
ld 'MemorySwappiness' in struct literal
debian/rules:59: recipe for target 'override_dh_auto_build' failed
-

I usually check "dpkg-buildpackage -A" only, but you can get full
build logs here:

https://reproducible.debian.net/rb-pkg/unstable/amd64/docker.io.html

Thanks.

Bug#819650: mirror submission for mirror.ba

[Donald Norwood]

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
be included and is only a minor fix.

The /debian-cd/ directory has not updated yet. Please check your
upstream provider if you are syncing and it has not updated.

The rsync mechanism fails:
rsync rsync://mirror.ba/debian-cd
@ERROR: chroot failed

It would be ideal to remove the /debian/ directory to avoid user
confusion as it appears on your http and ftp listings.

Best regards,

Donald Norwood
-Debian Mirrors Team



On Tue, 05 Apr 2016 11:59:58 + Emir Beganovic
 wrote:
> Hi Donald,
> 
> Our application might have been mistaken a little bit - we're applying only
> for Debian CD archive, not the Debian packages archive. We'd like to appear
> only on the debian-cd archives list: https://www.debian.org/CD/http-ftp/
> 
> The /debian-cd/ directory should now be current and updating, please
> re-check. I've also reconfigured it so it syncs twice a day. :-)
> 
> The available bandwidth of the mirror is 100 Mbit/s.
> 
> Regards,
> Emir Beganovic
> 
> On Mon, Apr 4, 2016 at 7:01 PM Donald Norwood  wrote:
> 
> > control: tag -1 +moreinfo
> >
> > Hello Emir,
> >
> > Thank you for your interest in mirroring Debian.
> >
> > There are a few items that need resolution for your mirror entry.
> >
> > The /debian/ directory need not hold /debian-cd/. The archive is served
> > as /debian/ for the Debian archive and /debian-cd/ for the Debian CD
> > archive. I.E.  /debian/ and /debian-cd/
> >
> > The /debian-cd/ directory is not current, please update.
> >
> > Archive mirrors need to update 4 times per 24 hours, the CD mirrors do
> > not need to as the images don't change that often. :) Twice a day is fine.
> >
> > What is the available bandwidth of the mirror?
> >
> >
> > Looking forward to hearing from you.
> >
> > Best regards,
> >
> > Donald Norwood
> > -Debian Mirrors team
> >



signature.asc
Description: OpenPGP digital signature

Bug#301100: aptitude: 'justification' field

[Manuel A. Fernandez Montecelo]

Control: tags -1 - moreinfo
Control: close -1


2016-04-05 20:50 Manuel A. Fernandez Montecelo:

So in principle I think that this request is basically fulfilled, not
closing yet in the case that there's some comment.


Failure to deliver the message, so closing now.


--
Manuel A. Fernandez Montecelo 

Bug#820148: autopkgtest: please make the build reproducible (environment)

[Alexis Bienvenüe]

Source: autopkgtest
Version: 3.20.2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

While working on the “reproducible builds” effort [1], we have noticed
that 'autopkgtest' could not be built reproducibly.

Depending on the locale (LC_COLLATE I think), [a-z] can include or not
capitals, so that in the Makefile, [a-z]* can match SKELETON or not.
Thus, depending on the locale, SKELETON will be installed with mode 0644
or 0755.

The (very simple) attached patch can solve this issue, so that
autopkgtest can be built reproducibly in our current experimental framework.

Regards,
Alexis Bienvenüe.

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



diff -Nru autopkgtest-3.20.1/Makefile autopkgtest-3.20.1.0~reproducible1/Makefile
--- autopkgtest-3.20.1/Makefile	2016-03-14 22:36:00.0 +0100
+++ autopkgtest-3.20.1.0~reproducible1/Makefile	2016-04-05 21:51:05.0 +0200
@@ -72,8 +72,8 @@
 	$(INSTALL_DATA) CREDITS $(docdir)
 	$(INSTALL_DATA) $(rstfiles) $(htmlfiles) $(docdir)
 	$(INSTALL_PROG) setup-commands/*[!~] $(datadir)/setup-commands
-	$(INSTALL_DATA) ssh-setup/SKELETON $(datadir)/ssh-setup
 	$(INSTALL_PROG) ssh-setup/[a-z]*[!~] $(datadir)/ssh-setup
+	$(INSTALL_DATA) ssh-setup/SKELETON $(datadir)/ssh-setup
 
 clean:
 	rm -f */*.pyc

Bug#819766: pesign: new upstream release out

[D. Jared Dominguez]

On Sat, Apr 02, 2016 at 01:29:04AM +0200, Tollef Fog Heen wrote:

Package: pesign
Version: 0.110-2
Severity: wishlist

0.111 seems to be out, can this be packaged please?


Hi Tollef,

Yes, it's on my to-do list.

--Jared


--
Jared Domínguez
OS Architect
Linux Engineering
Dell | Client Software Group

Bug#797999: sddm fails to start whereas kdm works correctly

[Diederik de Haas]

On Tuesday 05 April 2016 13:55:37 Hans-J. Ullrich wrote:
> the nvidia proprietrary drivers are installed by the installer from nvidia.
> As my card is no more supperted by the debian packages (GeForce 8600M GS), I
> had to do that way.

I highly doubt that that is true.
Install the 'nvidia-detect' package and run it and it should tell you which 
driver is appropriate for your card. 
My guess is that it will tell you to install 'nvidia-legacy-340xx-driver'

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

Bug#820147: openocd: FTBFS[kfreebsd]: doesn't find libusb-1.0

[Steven Chamberlain]

Package: src:openocd
Version: 0.9.0-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd

Hi!

openocd stopped building on kfreebsd when it was switched to
libusb-1.0 API.  This can be easily fixed though, as kfreebsd has a
libusb2-dev that Provides: libusb-1.0-0-dev.

The patch below changes the Build-Depends appropriately, and changes to
libftdi1 while here - I tested that this builds in kfreebsd-amd64 sid:

--- debian/control.orig 2016-04-05 21:15:49.870835961 +0100
+++ debian/control  2016-04-05 21:20:52.222814737 +0100
@@ -3,8 +3,8 @@
 Priority: extra
 Maintainer: Uwe Hermann 
 Uploaders: Luca Bruno 
-Build-Depends: cdbs, debhelper (>= 7), autotools-dev, libftdi-dev,
-   libusb-1.0-0-dev [linux-any], libusb-dev [kfreebsd-any 
hurd-any],
+Build-Depends: cdbs, debhelper (>= 7), autotools-dev, libftdi1-dev,
+   libusb-1.0-0-dev,
texinfo, texlive, 
autotools-dev, autoconf,
libhidapi-dev,

This change also removes the hurd-* Build-Depends on libusb-dev (that's
libusb-0.1, which is going to be removed soon from sid).

Thanks!

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#820121: New upstream version

[Andreas Tille]

Hi Alba,

I noticed this new version as well for a while but did not act since I
assumed you would commit to this package.  Please also feel free to
update r-cran-igraph as well.  Please let me know if you prefer if I
move igraph from svn to git if you might prefer this.  If you do not
intend to contribute to this package I'll do the upgrade simply in SVN.
Just let me know.

Kind regards

 Andreas.

On Tue, Apr 05, 2016 at 05:15:27PM +0100, Moray Allan wrote:
> Package: r-cran-phangorn
> Version: 1.99.14-1
> Severity: wishlist
> 
> Please consider packaging the new upstream version of r-cran-phangorn
> (2.0.2 is available).  I think this may require a new igraph package
> version (>= 1.0) first.
> 
> Thanks,
> 
> Moray
> 
> -- System Information:
> Debian Release: 8.3
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#820058: mirror submission for mirror.wlg.tmnetwork.co.nz

[Donald Norwood]

control: tag -1 +moreinfo

Hi,

The mirror submission looks good. I have a question on what you are
offering or plan to offer. On your top level directory the mirror shows:
/debian/, /debian-cd/, and /debian-security/.

There is no real need to carry /debian-security/ as the security mirrors
are official mirrors that are aliased from our top level mirrors. We do
not encourage or announce unofficial security mirrors. That being said,
if you mirror security for your own network and clients that you do so
with that understanding.

The /debian-cd/ directory is incomplete, particularly the /project/
directory. Do you plan on carrying /debian-cd/ ?

Looking forward to your response.

Best regards,

Donald Norwood
-Debian Mirrors Team



On Tue, 05 Apr 2016 04:56:44 + "Systems Team"  wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirror.wlg.tmnetwork.co.nz
> Type: leaf
> Archive-architecture: amd64 i386 
> Archive-http: /debian/
> Archive-rsync: debian/
> IPv6: no
> Archive-upstream: mirrors.kernel.org
> Updates: four
> Maintainer: Systems Team 
> Country: NZ New Zealand
> Location: Wellington, New Zealand
> Sponsor: Trade Me Limited http://www.trademe.co.nz/
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#814795:

[Santiago Vila]

reassign 814795 src:pandas
found 814795 0.17.1-3
thanks

Tidy up, please ignore.

[ If there is a FTBFS, then it's more a bug in the source package than
  a bug in the generated binary package ].

Bug#820025: python-pskc-doc: missing Breaks+Replaces: python-pskc (<< 0.4)

[Arthur de Jong]

On Mon, 2016-04-04 at 22:35 +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade
> from 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring
> a Breaks+Replaces relation.

Thanks for pointing this out and thanks for the testing. I'll upload a
fix shortly.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



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

Bug#816396: RFS: vizigrep/1.3-1 ITP

[Gianfranco Costamagna]

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

hi, lets review:

please use the new dh call sequencer (rules)
std-version is 3.9.7
no need probably to force python as runtime dependency
having a setup.py might be better

check-all-the-things

$ find -type f -iname '*.desktop' -exec desktop-file-validate {} \;

$ licensecheck --check=. --recursive --copyright . | grep -F 'with incorrect 
FSF address'
./ut/test-data/c-source/xpad.c: GPL (v2 or later) (with incorrect FSF address)

$ flawfinder -Q -c .

$ pep8 --ignore W191 .

$ pyflakes3 .

$ pyflakes.


debian/dirs, please remove and install -d in Makefile.

the other stuff LGTM, even if I didn't run lintian and test the package yet.

cheers,

G.

Il Martedì 1 Marzo 2016 15:33, Jason J. Herne  ha scritto:



Package: sponsorship-requests
Severity: wishlist Dear mentors, I am looking for a sponsor for my package 
"vizigrep" * Package name   : vizigrep Version  : 1.3-1 Upstream Author : 
Jason J. Herne 
* URL : https://github.com/hernejj/vizigrep * License  : GPL 
Section  : utils It builds those binary packages: vizigrep  - graphical 
file contents search tool using regular expressions To access further 
information about this package, please visit the following URL: 
http://mentors.debian.net/package/vizigrep Alternatively, one can download the 
package with dget using this command: dget -x 
http://mentors.debian.net/debian/pool/main/v/vizigrep/vizigrep_1.3-1.dsc More 
information about Vizigrep can be obtained from 
https://github.com/hernejj/vizigrep. Changes since the last upload: * Initial 
Upload of Vizigrep v1.3 Regards, Jason J. Herne

Bug#745027: Missing dependencies

[Stephen Paul Weber]

I suspect that if vdirsyncer makes its way into stable before 1.0, it
essentially means I'm forced into long-term support of whichever release is in
stable. However, ideally I'd like to only support the latest release of
vdirsyncer.


To be clear: this is only true if you are the Debian maintainer for 
vdirsyncer.  If someone else is the maintainer (as, reading this thread, it 
seems is the intent) then it is *their* job to backport any relevant 
bugfixes and provide any support to Debian stable users.  As upstream, you 
only ever have to support official versions that you provide, of course, and 
not Debian versions.


I'm really excited to see this packaged!  This is a very useful tool that 
I would like to deploy on more of my systems.

Bug#670135: Closing the bug

[Anton Gladky]

fixed 670135 5.0.0+dfsg1-2
thanks

Hi,

it seems the bug is not relevant any more.
That is why I'm closing the bug. Please, feel
free to reopen it if you think the bug is still there, or
fill a new bug.

Kind regards

Anton