date:20141222

Bug#773327: debian-efi mailing list

2014-12-22 Thread Raphael Hertzog

Hi,

On Tue, 16 Dec 2014, Steve McIntyre wrote:
 OK, I think we have enough to get started. I've opened #773327 to ask
 for the new list - please follow up there too?

I believe such a list would be useful as EFI support is important
and hard to get right. I have been working on bring UEFI support to
live-build and I would have appreciated having this list to seek feedback
and help while trying to implement this (and this is not over yet,
we know that the current implementation does not work everywhere).

+1 from me.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751498: closed by Laszlo Boszormenyi (GCS) g...@debian.org (Bug#751498: fixed in python-greenlet 0.4.5-1)

2014-12-22 Thread GCS

Hi Bálint,

On Fri, Dec 19, 2014 at 10:21 PM, Balint Reczey bal...@balintreczey.hu wrote:
 On Sat, 15 Nov 2014 13:49:10 +0100 Ivo De Decker iv...@debian.org wrote:
 The arm* build failure is fixed by this patch from ubuntu (tested on abel):

 http://patches.ubuntu.com/p/python-greenlet/python-greenlet_0.4.2-1ubuntu1.patch

 T-p-u sounds a bit better, do you plan going this way?
 If you don't have time now I would happily fix this in an NMU.
 I've updated the package[1]. Can someone test it on any ARM
architecture to see if it builds correctly? Will ask the Release Team
for a t-p-u upload.

Thanks,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/python-greenlet_0.4.2-2.dsc


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#611141: Error: /undefined in ff

2014-12-22 Thread Yuriy M. Kaminskiy

Problem was lack of proper handling for EXTRASAMPLE_UNASSOCALPHA in tiff2ps.
Attached patch should fix this and related issues (should be applicable to
3.9.latest and 4.0.latest)
Warning: only minimal testing passed, likely should be forwarded to and handled
by upstream.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
NotDashEscaped: You need GnuPG to verify this message

From: Yuriy M. Kaminskiy yum...@gmail.com
Subject: [PATCH] tiff2ps: fix unassociated alpha and other extrasamples != 0

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

Index: tiff-3.9.4/tools/tiff2ps.c
===
--- tiff-3.9.4.orig/tools/tiff2ps.c	2014-12-22 08:55:32.344597548 +0300
+++ tiff-3.9.4/tools/tiff2ps.c	2014-12-22 10:49:54.632097174 +0300
@@ -1553,7 +1553,15 @@ PS_Lvl2page(FILE* fd, TIFF* tif, uint32 
 		break;
 }
 			}
-			byte_count -= j;
+			byte_count = j;
+		} else if (extrasamples != 0) {
+			int i, j = 0;
+			int ncomps = samplesperpixel - extrasamples;
+			for (i = 0; i  byte_count; i+=samplesperpixel) {
+memmove(buf_data + j, buf_data + i, ncomps);
+j += ncomps;
+			}
+			byte_count = j;
 		}
 
 		if (ascii85) {
@@ -1881,6 +1889,8 @@ PSDataBW(FILE* fd, TIFF* tif, uint32 w, 
 	unsigned char* cp;
 	tsize_t stripsize = TIFFStripSize(tif);
 	tstrip_t s;
+	int sp = planarconfiguration == PLANARCONFIG_SEPARATE ? 1 : samplesperpixel;
+	int nc = samplesperpixel - extrasamples;
 
 #if defined( EXP_ASCII85ENCODER )
 	int	ascii85_l;		/* Length, in bytes, of ascii85_p[] data */
@@ -1932,6 +1942,10 @@ PSDataBW(FILE* fd, TIFF* tif, uint32 w, 
 *cp = ~*cp;
 			cp++;
 		}
+		if(planarconfiguration == PLANARCONFIG_SEPARATE) {
+		cc /= samplesperpixel;
+		nc = cc * (samplesperpixel - extrasamples);
+		}
 		/*
 		 * for 16 bits, the two bytes must be most significant
 		 * byte first
@@ -1942,12 +1956,18 @@ PSDataBW(FILE* fd, TIFF* tif, uint32 w, 
 		if (ascii85) {
 #if defined( EXP_ASCII85ENCODER )
 			if (alpha) {
-int adjust, i;
-for (i = 0; i  cc; i+=2) {
-	adjust = 255 - cp[i + 1];
-cp[i / 2] = cp[i] + adjust;
+int adjust, i, j = 0;
+for (i = 0; i  cc; i += sp) {
+	adjust = 255 - cp[i + nc];
+cp[j++] = cp[i] + adjust;
 }
-cc /= 2;
+cc = j;
+			} else if (sp != 1) {
+int i, j = 0;
+for (i = 0; i  cc; i += sp) {
+cp[j++] = cp[i];
+}
+cc = j;
 			}
 
 			ascii85_l = Ascii85EncodeBlock( ascii85_p, 1, cp, cc );
@@ -1955,15 +1975,15 @@ PSDataBW(FILE* fd, TIFF* tif, uint32 w, 
 			if ( ascii85_l  0 )
 			fwrite( ascii85_p, ascii85_l, 1, fd );
 #else
-			while (cc--  0)
-Ascii85Put(*cp++, fd);
+			for (; cc  0; cc -= sp, cp += sp)
+Ascii85Put(*cp, fd);
 #endif /* EXP_ASCII85_ENCODER */
 		} else {
 			unsigned char c;
 
 			if (alpha) {
 int adjust;
-while (cc--  0) {
+for ( ; cc = sp; cc -= sp, cp += sp) {
 	DOBREAK(breaklen, 1, fd);
 	/*
 	 * For images with alpha, matte against
@@ -1971,13 +1991,12 @@ PSDataBW(FILE* fd, TIFF* tif, uint32 w, 
 	 *Cback * (1 - Aimage)
 	 * where Cback = 1.
 	 */
-	adjust = 255 - cp[1];
-	c = *cp++ + adjust; PUTHEX(c,fd);
-	cp++, cc--;
+	adjust = 255 - cp[nc];
+	c = *cp + adjust; PUTHEX(c,fd);
 }
 			} else {
-while (cc--  0) {
-	c = *cp++;
+for (; cc = sp; cc -= sp, cp += sp) {
+	c = *cp;
 	DOBREAK(breaklen, 1, fd);
 	PUTHEX(c, fd);
 }
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlSX0T8ACgkQKZn9iF16KMOOrAD+OF914uqGQSFAtgZvlud5MnXX
ZMmlThUokSBRsr2tZvwBAIx5VJmrvhWMKf0JWePZLBv6uyH/C7Kzr7VAKYG+Eur2
=zt2i
-END PGP SIGNATURE-

Bug#773697: network-manager: Wi-Fi not connected after computer restart if the Lan cable is disconnected

2014-12-22 Thread otas.pe

Package: network-manager
Version: 0.9.10.0-4
Severity: important

Dear Maintainer,

So far the problem with network-manager is not solved. Every time if I restart
my laptop with disconnected Lan cable then Wi-Fi is connected to favorite
network but internet connection does not work. If during computer restart Lan
cable is connected then after Lan cable disconnecting Wi-Fi works well and
internet connection as well.

My laptop is Lenovo Ideapad B560

03:00.0 Ethernet controller: Qualcomm Atheros AR8131 Gigabit Ethernet (rev c0)
04:00.0 Network controller: Broadcom Corporation BCM4313 802.11bgn Wireless
Network Adapter (rev 01)

Broadcom firmware firmware-brcm80211 is installed. Used kernel version does not
have any effect for this issue.

Thanks

Ota



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (980, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)

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

Versions of packages network-manager depends on:
ii  adduser3.113+nmu3
ii  dbus   1.8.12-1
ii  init-system-helpers1.22
ii  isc-dhcp-client4.3.1-5
ii  libc6  2.19-13
ii  libdbus-1-31.8.12-1
ii  libdbus-glib-1-2   0.102-1
ii  libgcrypt201.6.2-4+b1
ii  libglib2.0-0   2.42.1-1
ii  libgnutls-deb0-28  3.3.8-5
ii  libgudev-1.0-0 215-8
ii  libmm-glib01.4.0-1
ii  libndp01.4-2
ii  libnewt0.520.52.17-1+b1
ii  libnl-3-2003.2.24-2
ii  libnl-genl-3-200   3.2.24-2
ii  libnl-route-3-200  3.2.24-2
ii  libnm-glib40.9.10.0-4
ii  libnm-util20.9.10.0-4
ii  libpam-systemd 215-8
ii  libpolkit-gobject-1-0  0.105-8
ii  libreadline6   6.3-8+b2
ii  libsoup2.4-1   2.48.0-1
ii  libsystemd0215-8
ii  libteamdctl0   1.12-1
ii  libuuid1   2.25.2-4
ii  lsb-base   4.1+Debian13+nmu1
ii  policykit-10.105-8
ii  udev   215-8
ii  wpasupplicant  2.3-1

Versions of packages network-manager recommends:
ii  crda3.13-1
ii  dnsmasq-base2.72-2
ii  iptables1.4.21-2+b1
ii  iputils-arping  3:20121221-5+b2
ii  modemmanager1.4.0-1
ii  ppp 2.4.6-3

Versions of packages network-manager suggests:
ii  avahi-autoipd  0.6.31-4+b2
pn  libteam-utils  none

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=true


-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765109: fglrx-driver: Black screen after xorg startup

2014-12-22 Thread Mathieu Pourcel

I thought the blacklist of radeon was done in /etc/modprobe.d/ by fglrx 
driver installation .. I will retry and check ;)
Maybe my problem is also that I don't success in disabling hybrid 
graphic (it's unchecked in BIOS, but ... ), so the i915 intel vga 
driver is also used. :(


--
---
Mathieu POURCEL
Technicien systèmes et réseaux
LEGOS - UMR 5566
Bureau 41 / D033
Observatoire Midi-Pyrénées
14, avenue Edouard Belin 31400 Toulouse
tel : : +33 (0)5 61 33 29 41
fax : : +33 (0)5 61 25 32 05


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771154: plink: New major upstream version of plink

2014-12-22 Thread Dylan

Hi Andreas,

2014-12-16 15:35 GMT+01:00 Andreas Tille andr...@an3as.eu:

 For this actual case I wonder whether plink2 would be a drop in
 replacement we can provide instead of the old pling (which means the
 interface is compatible and the test suite if there is any creates the
 same results) or whether you think plink and plink2 should be provided
 in parallel.


I recommend to provide both versions of plink for the moment as the first
version is always widely used and the interface is not completely
compatible, some flags are not supported by the new version. The upstream
recommends to use the old plink for these flags. Moreover, the new version
is a major update (i.e. many algorithms changes) which could be problematic
for replicate some previous results for those using old plink.

I will push the new plink on git.debian.


Best regards,
Dylan

Bug#715892: [Mayhem] Bug report on libtiff-tools: fax2tiff crashes with exit status 139

2014-12-22 Thread Yuriy M. Kaminskiy

Attached patch fixes issue (improper getopt invocation, -r option requires 
argument)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
NotDashEscaped: You need GnuPG to verify this message

From: Yuriy M. Kaminskiy yum...@gmail.com
Subject: fax2tiff: option -r requires argument

Fixes SIGSEGV, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715892

Index: tiff-4.0.x-20141215/tools/fax2tiff.c
===
--- tiff-4.0.x-20141215.orig/tools/fax2tiff.c	2014-12-22 11:45:45.744096012 +0300
+++ tiff-4.0.x-20141215/tools/fax2tiff.c	2014-12-22 11:46:15.472596500 +0300
@@ -99,7 +99,7 @@ main(int argc, char* argv[])
 	extern char* optarg;
 
 
-	while ((c = getopt(argc, argv, R:X:o:1234ABLMPUW5678abcflmprsuvwz?)) != -1)
+	while ((c = getopt(argc, argv, R:X:o:r:1234ABLMPUW5678abcflmpsuvwz?)) != -1)
 		switch (c) {
 			/* input-related options */
 		case '3':		/* input is g3-encoded */
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlSX21EACgkQKZn9iF16KMM2jQD+K/bz529ghh9r51nd1f8aGNgb
KZ7T3ELyj99ZFrR2EUMA/2xZjurDz8Ac9ByszIBbL0+2wzB1vDJO1w4L2zVr/Hhp
=C2BG
-END PGP SIGNATURE-

Bug#772740: xserver-xorg-video-nvidia-legacy-304xx: No glXSwapIntervalSGI despite reported GLX_SGI_swap_control in socket-based connections

2014-12-22 Thread Ilya Anfimov

On Fri, Dec 19, 2014 at 12:33:34PM +0100, Andreas Beckmann wrote:

[skipped]

  connecting to the nvidia-driven X-server from machine  with  mesa
  or ATI libGL drivers.
 
 Can you run the X-server machine with the supported configuration from
 update-alternatives  --set  glx /usr/lib/nvidia
 
 also /usr/lib/xorg/modules/extensions/libglx.so, libnvglx.so are manual
 symlinks, get rid of them, too
 reinstall xserver-xorg-core to get back the xorg libglx.so
 
 and maybe try a minimal xorg.conf as describd in the README.Debian

 OK, tested on fresh Debian/testing install from DVD

 After fresh install of base system:

2) apt-get install nvidia-legacy-304xx-driver
 (rebooted, as recommended due to nouveau driver)

root@glt2:~# apt-cache policy nvidia-legacy-304xx-driver
nvidia-legacy-304xx-driver:
  Installed: 304.123-4
  Candidate: 304.123-4
  Version table:
 *** 304.123-4 0
500 http://cdn.debian.net/debian/ jessie/non-free amd64 Packages
100 /var/lib/dpkg/status

apt-get install xinit twm

Created minimal working xorg.conf:

Section Device
Identifier  My GPU
Driver  nvidia
Option  NoPowerConnectorCheck True
EndSection

(yes,  I know, that I've forgotten power connector.  All I needed
from this fanless videoadapter works fine without it, even games,
and  it  hardly will break support of setting of buffer swap con-
trol frquency)

ssh -X to wheezy virtual machine with glx
alternative set to libgl1-mesa:

root@trzbase:~# /tmp/swabsgi
X Error of failed request:  GLXUnsupportedPrivateRequest
  Major opcode of failed request:  156 (GLX)
  Minor opcode of failed request:  16 (X_GLXVendorPrivate)
  Serial number of failed request:  40
  Current serial number in output stream:  41
root@trzbase:~# echo $?
1
root@trzbase:~#

ssh -X to wheezy host with fglrx:

root@trzbase:~# /tmp/swabsgi
X Error of failed request:  GLXUnsupportedPrivateRequest
  Major opcode of failed request:  156 (GLX)
  Minor opcode of failed request:  16 (X_GLXVendorPrivate)
  Serial number of failed request:  34
  Current serial number in output stream:  35
root@trzbase:~# echo $?
1

ssh -X to wheezy host with nvidia-glx, 304.117 (it works mostly as expected):
root@trzbase:~# /tmp/swabsgi
ERROR: could not insert 'nvidia': No such device
NVIDIA: failed to load the NVIDIA kernel module.
root@trzbase:~# echo $?
0

ssh -X to wheezy host with nvidia-glx-legacy71xx (works
good, the same as 304.117):

root@trzbase:~# /tmp/swabsgi
ERROR: could not insert 'nvidia': No such device
NVIDIA: failed to load the NVIDIA kernel module.
root@trzbase:~# echo $?
0

local test with glx set to nvidia, which is
nvidia-legacy-304xx driver -- all is fine,
no error messages, in both indirect (__GL_FORCE_INDIRECT=1 )
and direct modes.


Tryed installation of 304.125 drivers:
sudo dpkg -i libgl1-nvidia-legacy-304xx-glx_304.125-1_amd64.deb \
libgl1-nvidia-legacy-304xx-glx_304.125-1_i386.deb \
libgl1-nvidia-legacy-304xx-glx-i386_304.125-1_i386.deb  \
nvidia-legacy-304xx-alternative_304.125-1_amd64.deb \
nvidia-legacy-304xx-alternative_304.125-1_i386.deb \
nvidia-legacy-304xx-driver_304.125-1_amd64.deb   \
xserver-xorg-video-nvidia-legacy-304xx_304.125-1_amd64.deb  \
nvidia-legacy-304xx-kernel-dkms_304.125-1_amd64.deb

The nvidia-legacy-304xx-alternative:i386 caused some dependency error,
just removed it immediately.

All attempt to use glx fail, in any app, even with nvidia libs:

root@glt2:~# __GL_FORCE_INDIRECT=1 glxinfo
name of display: :0.0
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  156 (GLX)
  Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  Value in failed request:  0x0
  Serial number of failed request:  33
  Current serial number in output stream:  34
root@glt2:~#

(it is working nvidia libs with the same version, as direct rendering works 
fine)

I'm not sure, wheter should I post new bug about this
or it is OK to continue with that here. However, it is definitely
a different bug.

Taken tcpdump with direct and indirect glxinfo at 304.125, nvidia glx
(all indirect ones -- failed on X_GLXCreateNewContext),
and glxinfo and swabsgi at 304.123  -- with
nvidia glx -- glxinfo worked, swabsgi worked in both direct and indirect
modes, swabsgi failed with mesa (indirect) glx.

Example of Mesa glx drivers output:

root@glt2:~# ./swabsgi
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  GLXUnsupportedPrivateRequest
  Major opcode of failed request:  156 (GLX)
  Minor opcode of failed request:  16 (X_GLXVendorPrivate)
  Serial number of failed request:  48
  Current serial number in output stream:  49

I'm not sure I should fill debian bug tracker with this
dumps, so putting it separately:

304.125 X Server driver:

glxinfo, working, glx 304.125 direct mode:
http://tzirechnoy.com/dl/dumps/304.125-glx.dump

Bug#773698: chef-server-api: Error 500 returned by Chef Server

2014-12-22 Thread Piotr Pańczyk

Package: chef-server-api
Version: 10.12.0-1
Severity: normal

Dear Maintainer,
I'm getting error 500 (Net::HTTPFatalError: 500 Internal Server Error) from
Chef Server when running the client, probably due to big amount of data returned
by Ohai. I tried connecting the same node to newer version of Chef Server (Open
Source Chef Server 11.1.6-1 downloaded from Chef's website) and it returned
Net::HTTPServerException: 413 Request Entity Too Large. The workaround is to
disable passwd plugin in Ohai, but I'd prefer to store all data on the server.
Please consider extending the data limit.


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

Kernel: Linux 2.6.32.bsd54h0 (SMP w/24 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages chef-server-api depends on:
ii  adduser   3.113+nmu3
ii  chef  10.12.0-3
ii  chef-solr 10.12.0+dfsg-2
ii  couchdb   1.2.0-5
ii  merb-core 1.1.3+dfsg-2
ii  rabbitmq-server   3.4.2-1
ii  ruby  1:1.9.3
ii  ruby-dep-selector 0.0.8-1
ii  ruby-json 1.7.3-3
ii  ruby-merb-assets  1.1.3-1
ii  ruby-merb-core [merb-core]1.1.3+dfsg-2
ii  ruby-merb-haml1.1.3-2
ii  ruby-merb-helpers 1.1.3-1
ii  ruby-merb-param-protection1.1.3-1
ii  ruby-mixlib-authentication1.1.4-2
ii  ruby-treetop  1.4.10-5
ii  ruby-uuidtools2.1.2-2
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.194-8.1+deb7u2
ii  thin  1.3.1-3
ii  ucf   3.0025+nmu3

chef-server-api recommends no packages.

chef-server-api suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771154: plink: New major upstream version of plink

2014-12-22 Thread Andreas Tille

Hi Dylan,

On Mon, Dec 22, 2014 at 09:51:06AM +0100, Dylan wrote:
 
 I recommend to provide both versions of plink for the moment as the first
 version is always widely used and the interface is not completely
 compatible, some flags are not supported by the new version. The upstream
 recommends to use the old plink for these flags. Moreover, the new version
 is a major update (i.e. many algorithms changes) which could be problematic
 for replicate some previous results for those using old plink.
 
 I will push the new plink on git.debian.

Fine.  Just post on the list once it is ready for sponsering.

Please keep on with your good work to package software for Debian Med

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771154: [Debian-med-packaging] Bug#771154: plink: New major upstream version of plink

2014-12-22 Thread Steffen Möller

Much in support of Dylan, please also think about the binary filename of the executable. We had the unfortunate p-link for Version 1 to avoid a clash with one of the putty tools. This was a mistake at the time imho. Shall we correct for that? Or is upstream already defaulting to plink2? This would then give us p-link and plink2 as executables. Hurts.
Cheers,
Steffen
--
Sent from my Android phone with GMX Mail. Please excuse my brevity.Dylan bob.dyb...@gmail.com wrote:

Hi Andreas,

2014-12-16 15:35 GMT+01:00 Andreas Tille andr...@an3as.eu:

For this actual case I wonder whether plink2 would be a drop in
replacement we can provide instead of the old pling (which means the
interface is compatible and the test suite if there is any creates the
same results) or whether you think plink and plink2 should be provided
in parallel.

I recommend to provide both versions of plink for the moment as the first version is always widely used and the interface is not completely compatible, some flags are not supported by the new version. The upstream recommends to use the old plink for these flags. Moreover, the new version is a major update (i.e. many algorithms changes) which could be problematic for replicate some previous results for those using old plink.

I will push the new plink on git.debian.

Best regards,

Dylan

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

1 2 3 >

1 - 100 of 208 matches

Mail list logo