Bug#737395: Emacs Funny Manpages Copyright

[Riley Baird]

On 15/08/14 11:03, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> Okay, but as it stands, there is not even the right to distribute.
> 
> Indeed, they ought to have a sharable license.
> 
> In fact, the next Emacs release won't have these files any more.

Okay, thanks. I'll contact the maintainer of the package. They should be
removed from Debian soon.


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

Bug#758179: autofs: automount regularly unmounts unrelated local filesystems

[Marc Lehmann]

Package: autofs
Version: 5.0.7-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Likely the cause was me reducing the TIMEOUT in /etc/default/autofs, but I
haven't verified this.

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

Not sure what to answer here - I am using autofs.

   * What was the outcome of this action?

automount regualrly tries (and sometimes succeeds) to unmount local
filesystems that are completely unrelated to its own mountpoint.

   * What outcome did you expect instead?

automount should leave filesystems alone that it didn't mount itself.

The reason I don't know exactly what caused it (I am suffering^Wusing
autofs for many years now) is that it took me more than a month to
find out that automount is responsible for the magically disappearing
filesystems.

My auto.master looks like this:

/fs /etc/auto.fs

and auto.fs looks like this (this is an excerpt, full version available on
request, but I don't think any relevant lines are missing):

   # yama
   yama_wd -symlink:/fs/yama/wd
   yama-vers=3,intr,tcp,rsize=1048576,wsize=1048576 \
  /yama:/ \
  /wd  yama:/wd \

   # doom
   doom_archiv_001 -symlink:/fs/doom/archiv_001
   doom_archiv_002 -symlink:/fs/doom/archiv_002
   doom_db -symlink:/fs/doom/db
   doom_localvol2  -symlink:/fs/doom/localvol2
   doom_localvol3  -symlink:/fs/doom/localvol3
   doom_localvol4  -symlink:/fs/doom/localvol4
   doom_localvol5  -symlink:/fs/doom/localvol5
   doom-vers=3,intr,tcp,rsize=1048576,wsize=1048576 \
  /doom:/ \
  /archiv_001  doom:/archiv_001 \
  /archiv_002  doom:/archiv_002 \
  /db  doom:/db \
  /localvol2   doom:/localvol2 \
  /localvol3   doom:/localvol3 \
  /localvol4   doom:/localvol4 \
  /localvol5   doom:/localvol5 \

   # rain
   rain_localvol   -symlink:/fs/rain/localvol
   rain_localvol2  -symlink:/fs/rain/localvol2
   rain-vers=3,intr,tcp,rsize=1048576,wsize=1048576 \
   /rain:/ \
   /localvolrain:/localvol \
   /localvol2   rain:/localvol2 \


   # cerebro
   cerebro_bp  -symlink:/fs/cerebro/bp
   cerebro_localvol-symlink:/fs/cerebro/localvol
   cerebro_temp-symlink:/fs/cerebro/temp
   cerebro_wd  -symlink:/fs/cerebro/wd
   cerebro -symlink:/

   wd  -symlink:/wd/
   db  -symlink:/db/
   bp  -symlink:/bp/

All of these, obviously, should be managed in /fs, and this more or less
works.

However, for some time now, /wd was "magically" being unmounted from time
to time. This also happene dto other mounted filesystems, but it was hard
to see a pattern.

After long time I decided to strace -f automount, to see if that is
responsible. And lo and behold, it is:

   [pid  5814] open("/proc/mounts", O_RDONLY 
   ...
   [pid  5814] read(12, "rootfs / rootfs rw 0 0\nsysfs /sy"..., 1024) = 1024
   [pid  5814] read(12, " binfmt_misc rw,nosuid,nodev,noe"..., 1024) = 1024
   [pid  5814] read(12, "to=5,offset 0 0\ndoom:/localvol5 "..., 1024) = 251
   [pid  5814] read(12, "", 1024)  = 0

   ...

   [pid  5807] umount("/wd", 0)= 0

   [pid  5817] execve("/bin/umount", ["/bin/umount", "/fs/bp"], [/* 20 vars 
*/]) = 0

   [pid  5817] umount("/bp", 0)= -1 EBUSY (Device or resource busy)

   [pid  5817] umount("/bp", 0)= -1 EBUSY (Device or resource busy)

   [pid  5819] execve("/bin/umount", ["/bin/umount", "/fs/cerebro_localvol"], 
[/* 20 vars */]) = 0

   [pid  5819] umount("/localvol", 0)  = -1 EBUSY (Device or resource busy)

   [pid  5826] umount("/fs/doom/localvol5", 0) = -1 EBUSY (Device or resource 
busy)

So basically, it read /etc/fstab and then tried to umount basically every
local filesystem. Looking at the strace output more closely reveals that
it simply calls umount on the entries in /fs, which are symlinks.

I guess the fix would be to not umount symlinks, as umount follows
symlinks.

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

Kernel: Linux 3.16.1-031601-generic (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages autofs depends on:
ii  libc6  2.19-1
ii  libxml22.9.1+dfsg1-4
ii  multiarch-support  2.13-38+deb7u3
ii  ucf3.0025+nmu3

Versions of packages autofs recommends:
ii  kmod   9-3
ii  module-init-tools  9-3
ii  nfs-common 1:1.2.6-4

autofs suggests no packages.


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

Bug#758178: general: screen resolution reverts to minimum when not selected by KVM

[Bob Michael]

Package: general
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
I have 3 or 4 debian machines attached to a Zonet KVM3304 4 port KVM switch.  I
usually keep at least 2 of them on most of the time.  Thus only one is selected
at any one time.  I try to keep separate projects for clients on separate
machines.  When I select a machine that has not been selected for a while, say
2 hours or longer, the screen resolution has been set to the minimum.  It is
almost like some process goes out and queries about the display resolution and
when the machine is not selected it either does not get an answer or the answer
it gets is 600x480.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I went to the System Settings -> Displays to try to reset the resolution.  I
have done this both with Gnome Classic and the new Gnome.  I am rather sure
that the problem is somewhere in Gnome, but I have no idea which subsystem.
   * What was the outcome of this action?
In every case, the display goes black and the computer becomes unresponsive.  I
have to reboot.  I have tried this with fresh installs of debian 7.1, 7.2, 7.3,
and now 7.6.  This makes debian 7 unusable because when I am working on a
project, I usually leave multiple GVIM editor sessions open (sometimes a dozen
or more sessions) and sometimes for days at a time.
   * What outcome did you expect instead?
This never happened under debian 6 or debian 5 or debian 4.  The resolution
stays the same no matter how long the machine has
been unselected by the KVM.  I have had to revert to debian 6 in order to get
any work done on any machine that I need to leave on for more than a few hours.
Last week I installed openSUSE just to see what it did.  I left its machine
unselected overnight and when I reselected it, it came back with the screen
resolution unchanged.  So openSUSE seems to have fixed this bug.

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



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

Kernel: Linux 3.2.0-4-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


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

Bug#725714:

[Adam Baxter]

Any updates on this bug?

Bug#757697: RFE: Autodetection of architecture at boot time to load appropiate kernel

[adrian15]

El 10/08/14 18:31, Adrian Gibanel Lopez escribió:

Source: live-config
Severity: wishlist
** With Isolinux / Syslinux you should use the ifcpu64.c32 comboot module as
seen in tails:

https://git-tails.immerda.ch/tails/tree/config/binary_local-
hooks/20-syslinux_detect_cpu?id=deb15c765e2b34fe587c96ca590981a59a278922

Upstream documentation: http://www.syslinux.org/wiki/index.php/Ifcpu64.c32

Thank you!


I attach a patch for Isolinux / Syslinux implementation for cpu detection.

Please advise how to improve the implementation so that it can be 
accepted upstream.


Thank you.

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
diff -urN original/usr/lib/live/build/binary_syslinux 
fork_cpu64bit_detection/usr/lib/live/build/binary_syslinux
--- original/usr/lib/live/build/binary_syslinux 2014-08-14 02:42:20.007666770 
+
+++ fork_cpu64bit_detection/usr/lib/live/build/binary_syslinux  2014-08-15 
05:08:58.701948081 +
@@ -161,6 +161,12 @@
;;
 esac
 
+# Copy necessary syslinux modules
+for module in ifcpu64.c32
+do
+   cp "chroot/usr/lib/syslinux/${module}" "${_TARGET}/"
+done
+
 # Configuring files
 if [ -e "${_TARGET}/live.cfg.in" ]
 then
@@ -183,6 +189,22 @@
;;
 
*)
+   _AMD64_486_NUMBER="0"
+
+   for _FLAVOUR in ${LB_LINUX_FLAVOURS}
+   do
+   if [ "${_FLAVOUR}" = "amd64" -o "${_FLAVOUR}" = 
"486" ] ; then
+   
_AMD64_486_NUMBER="$((${_AMD64_486_NUMBER} + 1))"
+   fi
+   done
+
+   if [ "${_AMD64_486_NUMBER}" -ge 2 ] ; then
+   _AMD64_LABEL=$(cat "${_TARGET}/live.cfg.in" | 
grep "^label" | grep -v "failsafe" | sed 's/label //g' | sed -e 
"s|@FLAVOUR@|""amd64""|g")
+   _486_LABEL=$(cat "${_TARGET}/live.cfg.in" | 
grep "^label" | grep -v "failsafe" | sed 's/label //g' | sed -e 
"s|@FLAVOUR@|""486""|g")
+   _AUTO_LABEL=$(cat "${_TARGET}/live.cfg.in" | 
grep "^label" | grep -v "failsafe" | sed 's/label //g' | sed -e 
"s|@FLAVOUR@|""autodetect""|g")
+   _AUTO_MENU_LABEL=$(cat "${_TARGET}/live.cfg.in" 
| grep "menu label" | grep -v "failsafe" | sed 's/.*menu label //g' | sed -e 
"s|@FLAVOUR@|""auto""|g")
+   fi
+
_NUMBER="0"
 
for _FLAVOUR in ${LB_LINUX_FLAVOURS}
@@ -197,7 +219,22 @@
echo "" >> "${_TARGET}/live.cfg"
grep -v 'menu default' 
"${_TARGET}/live.cfg.in" >> "${_TARGET}/live.cfg"
else
-   cat "${_TARGET}/live.cfg.in" >> 
"${_TARGET}/live.cfg"
+   if [ "${_AMD64_486_NUMBER}" -ge 2 ] ; 
then
+   cat << EOF >> 
"${_TARGET}/live.cfg"
+label ${_AUTO_LABEL}
+   menu label ${_AUTO_MENU_LABEL}
+   com32 ifcpu64.c32
+   append ${_AMD64_LABEL} -- ${_486_LABEL} -- ${_486_LABEL}
+
+EOF
+   fi
+
+
+   if [ "${_AMD64_486_NUMBER}" -ge 2 ] ; 
then
+   grep -v 'menu default' 
"${_TARGET}/live.cfg.in" >> "${_TARGET}/live.cfg"
+   else
+   cat "${_TARGET}/live.cfg.in" >> 
"${_TARGET}/live.cfg"
+   fi
fi
 
sed -i -e "s|@FLAVOUR@|${_FLAVOUR}|g" \

Bug#749974: new maitreya push

[Olly Betts]

On Thu, Aug 14, 2014 at 03:43:55AM -0500, Paul Elliott wrote:
> Please find the new push on 
> http://anonscm.debian.org/gitweb/?p=collab-maint/maitreya.git
> it upgrades to the upstream's 7.0.7 and does not have the bugs
> the previous version had.
> 
> It can be uploaded to unstable as soon as wxsqlite3_3.1.0
> is released from experimental. Since I was told that maitreya
> was the last program that needed to be setup to work with wx 3.0
> I believe that can be done immeatiately. Since maitreya has been
> removed from testing, I hope this will happen as soon as possible.

Everything else is ready - we just need a "go" from the release team.

If NMUs are required, I'm happy to do them.

Cheers,
Olly


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

Bug#528992: mtr doesn't work when /etc/resolv.conf contains only ipv6 servers

[Haw Loeung (hloeung)]

Package: mtr
Version: 0.85-2.1
Followup-For: Bug #528992
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu utopic ubuntu-patch

Dear Maintainer,

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

My attempt at getting a patch I submitted upstream applied to the mtr
package.

It basically fixes LP: #752583 where IPv6 nameservers specified in
/etc/resolv.conf aren't counted and therefore mtr aborts when there
are *only* IPv6 nameservers specified.

Example /etc/resolv.conf:

| nameserver ::1
| domain local
| options timeout:3 no-check-names

Output from mtr without the fix:

| Start: Fri Aug 15 14:01:25 2014
| No nameservers defined.

A pull request has been submitted on GitHub to have this change
merged upstream[1].

[1]https://github.com/traviscross/mtr/pull/56

  * Non-maintainer upload.
  * Added patch to include count of IPv6 nameservers fixing
LP:#752583.


Thanks for considering the patch.


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

Kernel: Linux 3.16.0-7-generic (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u mtr-0.85/debian/changelog mtr-0.85/debian/changelog
only in patch2:
unchanged:
--- mtr-0.85.orig/dns.c
+++ mtr-0.85/dns.c
@@ -510,10 +510,15 @@
 
 void dns_open(void)
 {
-  int option,i;
+  int option,i,nscount;
 
   if (!dns) return;
   MY_RES_INIT();
+#ifdef ENABLE_IPV6
+  nscount = myres.nscount + myres._u._ext.nscount6;
+# else
+  nscount = myres.nscount
+#endif
   if (!myres.nscount) {
 fprintf(stderr,"No nameservers defined.\n");
 exit(-1);

Bug#750914: freqtweak: diff for NMU version 0.7.2-4.1

[Olly Betts]

Control: tags 750914 + patch
Control: tags 750914 + pending

Dear maintainer,

I've uploaded an NMU for freqtweak (versioned as 0.7.2-4.1).  A debdiff
for the NMU is attached.

I just noticed (after uploading I'm afraid) that I left a stray line in
debian/rules:

export MAKEFLAGS := -k

This isn't useful, and should be removed when you incorporate the NMU -
I added it so I'd get errors for all files in a single build, though it
seemed not to get through to make for some reason, so it doesn't seem
worth reuploading just to remove it.

Cheers,
Olly
diff -Nru freqtweak-0.7.2/debian/changelog freqtweak-0.7.2/debian/changelog
--- freqtweak-0.7.2/debian/changelog	2014-08-15 15:40:29.0 +1200
+++ freqtweak-0.7.2/debian/changelog	2014-08-15 14:43:09.0 +1200
@@ -1,3 +1,12 @@
+freqtweak (0.7.2-4.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Switch from deprecated simple-patchsys.mk to source format "3.0 (quilt)".
+  * Update to use wxWidgets 3.0 (Closes: #750914):
++ New patch: 06-wx3.0-compat.patch
+
+ -- Olly Betts   Fri, 15 Aug 2014 14:42:45 +1200
+
 freqtweak (0.7.2-4) unstable; urgency=low
 
   * New Maintainer Closes: #456176
diff -Nru freqtweak-0.7.2/debian/control freqtweak-0.7.2/debian/control
--- freqtweak-0.7.2/debian/control	2014-08-15 15:40:29.0 +1200
+++ freqtweak-0.7.2/debian/control	2014-04-09 10:21:47.0 +1200
@@ -2,7 +2,7 @@
 Section: sound
 Priority: optional
 Maintainer: Bhavani Shankar 
-Build-Depends: cdbs, debhelper (>= 5), automake1.11, fftw3-dev, libwxgtk2.8-dev, libjack-dev, libxml2-dev, libsigc++-1.2-dev, imagemagick
+Build-Depends: cdbs, debhelper (>= 5), automake1.11, fftw3-dev, libwxgtk3.0-dev, libjack-dev, libxml2-dev, libsigc++-1.2-dev, imagemagick
 Standards-Version: 3.8.3
 Homepage: http://freqtweak.sourceforge.net/
 
diff -Nru freqtweak-0.7.2/debian/patches/06-wx3.0-compat.patch freqtweak-0.7.2/debian/patches/06-wx3.0-compat.patch
--- freqtweak-0.7.2/debian/patches/06-wx3.0-compat.patch	1970-01-01 12:00:00.0 +1200
+++ freqtweak-0.7.2/debian/patches/06-wx3.0-compat.patch	2014-08-15 15:30:01.0 +1200
@@ -0,0 +1,206 @@
+Description: Fix to work with wxwidgets3.0
+Author: Olly Betts 
+Bug-Debian: https://bugs.debian.org/750914
+Forwarded: no
+Last-Update: 2014-08-15
+
+--- a/src/FTapp.cpp
 b/src/FTapp.cpp
+@@ -67,18 +67,18 @@
+ 
+ static const wxCmdLineEntryDesc cmdLineDesc[] =
+ {
+-	{ wxCMD_LINE_SWITCH, wxT("h"), wxT("help"), wxT("show this help"), wxCMD_LINE_VAL_NONE, wxCMD_LINE_OPTION_HELP },
+-	{ wxCMD_LINE_OPTION, wxT("c"), wxT("channels"), wxT("# processing channels (1-4) default is 2"), wxCMD_LINE_VAL_NUMBER },
+-	{ wxCMD_LINE_OPTION, wxT("i"), wxT("inputs"),
+-	  wxT("connect inputs from these jack ports (separate each channel with commas).\n")
++	{ wxCMD_LINE_SWITCH, wxT_2("h"), wxT_2("help"), wxT_2("show this help"), wxCMD_LINE_VAL_NONE, wxCMD_LINE_OPTION_HELP },
++	{ wxCMD_LINE_OPTION, wxT_2("c"), wxT_2("channels"), wxT_2("# processing channels (1-4) default is 2"), wxCMD_LINE_VAL_NUMBER },
++	{ wxCMD_LINE_OPTION, wxT_2("i"), wxT_2("inputs"),
++	  wxT_2("connect inputs from these jack ports (separate each channel with commas).\n")
+ 	  "\t\t\tDefaults to 'alsa_pcm:capture_1,..." },
+-	{ wxCMD_LINE_OPTION, wxT("o"), wxT("outputs"),
+-	  wxT("connect outputs to these jack ports (separate each channel with commas).\n")
++	{ wxCMD_LINE_OPTION, wxT_2("o"), wxT_2("outputs"),
++	  wxT_2("connect outputs to these jack ports (separate each channel with commas).\n")
+ 	  "\t\t\tDefaults to 'alsa_pcm:playback_1,...'" },
+-	{ wxCMD_LINE_OPTION, wxT("n"), wxT("jack-name"), wxT("jack name.   default is freqtweak_1")},
+-	{ wxCMD_LINE_OPTION, wxT("S"), wxT("jack-server"), wxT("jack server name")},
+-	{ wxCMD_LINE_OPTION, wxT("p"), wxT("preset"), wxT("load given preset initially")},
+-	{ wxCMD_LINE_OPTION, wxT("r"), wxT("rc-dir"), wxT("what directory to use for run-control state. default is ~/.freqtweak")},
++	{ wxCMD_LINE_OPTION, wxT_2("n"), wxT_2("jack-name"), wxT_2("jack name.   default is freqtweak_1")},
++	{ wxCMD_LINE_OPTION, wxT_2("S"), wxT_2("jack-server"), wxT_2("jack server name")},
++	{ wxCMD_LINE_OPTION, wxT_2("p"), wxT_2("preset"), wxT_2("load given preset initially")},
++	{ wxCMD_LINE_OPTION, wxT_2("r"), wxT_2("rc-dir"), wxT_2("what directory to use for run-control state. default is ~/.freqtweak")},
+ 	{ wxCMD_LINE_NONE }
+ };	
+ 
+@@ -221,7 +221,7 @@
+ 	
+ 	// use stderr as log
+ 	wxLog *logger=new wxLogStderr();
+-	logger->SetTimestamp(NULL);
++	logger->SetTimestamp(wxEmptyString);
+ 	wxLog::SetActiveTarget(logger);
+ 	
+ 	wxCmdLineParser parser(argc, argv);
+--- a/src/FTmainwin.cpp
 b/src/FTmainwin.cpp
+@@ -524,7 +524,6 @@
+ 	_inspecPanel = new wxPanel(_inspecSash, -1);
+ 	_inspecPanel->SetBackgroundColour(*wxBLACK);
+ 	_inspecPanel->SetThemeEnabled(false);
+-	_inspecSash->SetSashBorder(wxSASH_BOTTOM, true);
+ 	_inspecSash->SetSashVisible(wxSASH_BOTTOM, true);
+ 	_rowItems.push_back( _inspec

Bug#758177: blue: "hcitool dev" yields no device although the Laptop has 2 bluetooth apadpters.

[Kumar Abhishek]

Package: bluetooth
Version: 4.101-4.1
Severity: grave
File: blue
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
==> Wanted to use the bluetooth to pair my laptop to my phone and a portable 
bluetooth speaker.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
==> I had restarted bluetooth service from init.d.
   * What was the outcome of this action?
==> The service restarted successfully without any error, but the adapters 
still could not be detected.
   * What outcome did you expect instead?
==> Expected that the service restart could start the bluetooth adapter

-
root@debiantesting:/var/log# /etc/init.d/bluetooth restart
[ ok ] Stopping bluetooth: rfcomm /usr/sbin/bluetoothd.
[ ok ] Starting bluetooth: bluetoothd rfcomm.
 
root@debiantesting:/var/log# dmesg | grep -i blue
[6.562242] usb 8-4: Product: Bluetooth USB Host Controller
[   10.738355] Bluetooth: Core ver 2.17
[   10.738389] Bluetooth: HCI device and connection manager initialized
[   10.738402] Bluetooth: HCI socket layer initialized
[   10.738407] Bluetooth: L2CAP socket layer initialized
[   10.738415] Bluetooth: SCO socket layer initialized
[   12.000574] Bluetooth: Loading patch file failed
[   24.963833] Bluetooth: RFCOMM TTY layer initialized
[   24.963850] Bluetooth: RFCOMM socket layer initialized
[   24.963863] Bluetooth: RFCOMM ver 1.11
[   25.043101] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   25.043107] Bluetooth: BNEP filters: protocol multicast
[   25.043121] Bluetooth: BNEP socket layer initialized
root@debiantesting:/var/log# 

hp-pavillion g6 2010ax : AMD APU A8(4500m) Dual Graphic Card


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

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN.utf8, LC_CTYPE=en_IN.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bluetooth depends on:
ii  bluez  4.101-4.1

Versions of packages bluetooth recommends:
ii  bluez-alsa   4.101-4.1
ii  bluez-gstreamer  4.101-4.1

Versions of packages bluetooth suggests:
pn  bluez-cups  

-- 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#737198: behavior of multiple inputs; was: maxima doesn't honour *prompt-prefix* ...

[Robert Dodier]

About multiple inputs on one line, I can't reproduce the behavior
you've observed. There is some logic in the prompt-printing code to
suppress the input prompt when there are multiple inputs; I can't tell
why it apparently isn't acting as expected in the case you observed.
It is possible that the behavior depends on the Lisp implementation,
although I cannot reproduce it with GCL 2.6.10. Maybe you can try the
same thing again with the latest versions of Maxima and GCL. Also,
when you make these observations, are you working with Maxima directly
or through Cantor?

Maybe you can use the --very-quiet command line option for Maxima, so
that input and output labels are entirely suppressed, and instead
outputs are demarcated by  ...  as
specified by cantor-initmaxima.lisp.


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

Bug#739850: Watch file does not take account of the new location of clamtk source

[Scott Kitterman]

On Sun, 23 Feb 2014 09:24:06 +0100 Bob Dybian  wrote:
> Package: clamtk
> Version: 4.45-1
> Severity: minor
> Tags: patch
> 
> Hi,
> Please find below a new watch file which take account of the new location
> of clamtk source (i.e. from sf.net to bitbucket.org ) and which is more
> flexible on the file extension.
> 
> Best.
> 
> version=3
> >
> https://bitbucket.org/dave_theunsub/clamtk/downloads.*/clamtk-(\d\S*)\.
(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))

This is fixed in the version that's in New, but I forgot to close the bug in 
the changelog.

Scott K


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

Bug#758176: [wine-development] wine-development breaks autogenerated Desktop launchers

[jre]

Package: wine-development
Version: 1.7.24-2
Severity: normal

--- Please enter the report below this line. ---

I just installed Origin
(download.dm.origin.com/origin/live/OriginSetup.exe) with wine-development.
This creates ~/Desktop/Origin.desktop, which tries to execute "wine"
instead of "wine-development". Obviously this fails.
I made sure that the desktop file was not from an old installation.

Thanks
jre



--- ~/Desktop/Origin.desktop ---
[Desktop Entry]
Name=Origin
Exec=env WINEPREFIX="/home/jens/.wine" wine
C:windowscommandstart.exe /Unix
/home/jens/.wine/dosdevices/c:/users/Public/Desktop/Origin.lnk
Type=Application
StartupNotify=true
Path=/home/jens/.wine/dosdevices/c:/Program Files/Origin


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.14-2-amd64

Debian Release: jessie/sid
  900 testing http.debian.net
  300 unstablehttp.debian.net

--- Package information. ---
Depends (Version) | Installed
=-+-===
wine64-development (>= 1.7.24-2)  | 1.7.24-2
 OR wine32-development  (>= 1.7.24-2) | 1.7.24-2


Package's Recommends field is empty.

Suggests   (Version) | Installed
-+-===
wine-doc |
binfmt-support   | 2.1.4-1
ttf-mscorefonts-installer| 3.5


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

Bug#758175: blist: FTBFS: Python.h: No such file or directory

[Aaron M. Ucko]

Source: blist
Version: 1.3.6-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of blist in minimal environments (as on the autobuilders) have
been failing:

  blist/_blist.c:38:20: fatal error: Python.h: No such file or directory

Please substitute python(3)-all-dev for python(3)-all in Build-Depends
to account for the fact that blist builds a binary extension, not just
a module.

Thanks!


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

Bug#758013: s3ql autopkg test regression

[Nikolaus Rath]

On 08/13/2014 03:18 AM, Matthias Klose wrote:

> http://ci.debian.net/data/packages/unstable/amd64/s/s3ql/20140811_044901.autopkgtest.log
> 
> === FAILURES 
> ===
> __ NewerMetadataTest.test_all 
> __
> Traceback (most recent call last):
>   File "/tmp/adt-run.ZCEVkj/build.2re/s3ql-2.10.1+dfsg/tests/t4_fuse.py", line
> 161, in test_all
> return self.runTest()
>   File "/tmp/adt-run.ZCEVkj/build.2re/s3ql-2.10.1+dfsg/tests/t5_failsafe.py",
> line 131, in runTest
> fh.write('foobar')
>   File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1054, in 
> __exit__
> pytest.fail("DID NOT RAISE")
>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 467, in fail
> raise Failed(msg=msg, pytrace=pytrace)
> Failed: DID NOT RAISE


That's a bug in the test (race condition) rather than in the program.
It's fixed upstream.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


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

Bug#758162: python-powerline: Zsh plugin doesn't work at all: ERROR:shell:powerline:Failed to render: coercing to Unicode: need string or buffer, instancemethod found

[Jerome Charaoui]

tags fixed-upstream
thanks

Hi Axel,

The problem you are reporting seems to be related to the following
upstream issue :
https://github.com/Lokaltog/powerline/issues/835

I tested the referenced commit and it seems to fix it.

-- Jerome


Le 2014-08-14 18:01, Axel Beckert a écrit :
> Hi,
> 
> Axel Beckert wrote:
>> To test powerline before adding it to my .zshrc, I sourced
>> /usr/share/pyshared/powerline/bindings/zsh/powerline.zsh in a running zsh.
> [...]
>> The above happened with uxterm from Wheezy and zsh running on Sid via
>> SSH.
> 
> Also happens locally without SSH, uxterm from Sid and sourcing
> /usr/lib/python2.7/dist-packages/powerline/bindings/zsh/powerline.zsh
> 
> (Not sure which of the both files is the one meant to be sourced
> according to the docs.)
> 
>   Regards, Axel
> 



signature.asc
Description: OpenPGP digital signature

Bug#758173: [wine-development] Please keep the default WINEDEBUG instead of -all

[jre]

Minor correction, my workaround doesn't work. But I get back the old
behavior when I remove "-all" in /usr/bin/wine-development

Sorry for the noise
jre


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

Bug#758174: cacti: Error in /usr/share/cacti/site/scripts/loadavg_multi.pl script

[Noel David Torres Taño]

Package: cacti
Version: 0.8.8a+dfsg-5+deb7u3
Severity: normal
Tags: patch l10n

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
fresh install of cacti on new machine, Spanish locale
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
no data from load average plugin
   * What outcome did you expect instead?
correct data

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

I have noticed that no data were being graphed. Cacti's perl script expects 
this:
9:36pm  up 15 days, 11:37,  2 users,  load average: 0.14, 0.13, 0.10
but 'uptime' gives this:
02:44:06 up  7:06,  1 user,  load average: 0,00, 0,01, 0,05

Please note the differences in the decimal dot/comma.

patch is very simple:

4c4
< open(PROCESS, "LANG=C uptime |");
---
> open(PROCESS, "uptime |");

Thanks


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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#758173: [wine-development] Please keep the default WINEDEBUG instead of -all

[jre]

Package: wine-development
Version: 1.7.24-2
Severity: normal

--- Please enter the report below this line. ---

Hi


/usr/bin/wine-development (debian/scripts/wine) sets "WINEDEBUG=-all" by
default since 1.7.16-2. I found no reason for this change.

When I try to figure out problems with wine, my first step is to run in
a terminal "wine program.exe". This helps a lot since AFAIK the FIXME
and ERR classes are enabled by default in upstream wine.

But now I have to use "WINEDEBUG= wine-development program.exe" to get
the same result. I think shutting down these messages (contrary to
upstream's default) is no good idea for a program like wine.

Thanks again
jre




--- System information. ---
Architecture: amd64
Kernel:   Linux 3.14-2-amd64

Debian Release: jessie/sid
  900 testing http.debian.net
  300 unstablehttp.debian.net

--- Package information. ---
Depends (Version) | Installed
=-+-===
wine64-development (>= 1.7.24-2)  | 1.7.24-2
 OR wine32-development  (>= 1.7.24-2) | 1.7.24-2


Package's Recommends field is empty.

Suggests   (Version) | Installed
-+-===
wine-doc |
binfmt-support   | 2.1.4-1
ttf-mscorefonts-installer| 3.5


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

Bug#758137: lxc: Divertion created by lxc-stuff not removed when the package is removed/purged

[Daniel Baumann]

On 08/14/2014 05:38 PM, Laurent Bigonville wrote:
> After purging lxc-stuff (which is not shipped anymore), I can see that
> the diversion it has added is not removed:

bin:lxc-stuff doesn't carry the divertion since 1.0.0-1 (February 2014)
anymore.

therfore, and since there's no bin:lxc-stuff anymore anyway (so it's not
that i could add a divertion-removal in lxc-stuff), and given that the
divertion (and bin:lxc-stuff) was not part of wheezy and will not be
part of jessie, and given that the removal of the divertion already
happened in February, i see no reasonable/worthwile way to fix this.

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


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

Bug#758115: Disabled wait state X'32EE' on IPL of zIPL

[Stephen Powell]

On Thu, 14 Aug 2014 10:32:42 -0400 (EDT), Philipp Kern wrote:
> 
> Hrm.  Odd.  It shouldn't be because the brokeness relates to the C
> library, not to the C compiler itself and zipl does not use the C
> library.

Again, we must distinguish between zipl, the Linux command which
runs at a Linux shell prompt, and zIPL, the boot loader proper,
a customized version of which is written out by zipl when zipl gets
run.  zipl, the command which runs at a Linux shell prompt, most
certainly does use the C library.  It is written in C, it is compiled
by the C compiler, and, at execution time, it uses the C run-time
library, just like any other C program.  zIPL, which is written
out by zipl, does not use the C library.  Or does it?  Well, not
the regular C library, no.  But it does use a minimalist run-time
library.  In the source package, look at zipl/boot/libc.c.  Yes, even
zIPL, the boot loader proper, does use a C library of sorts.
> 
> That being said, I had to recompile s390-tools on sid,

Therein lies the problem.
> 
> and I do not run sid due to the C breakage.

You should.  You may not be able to directly install jessie or
sid, but you can install wheezy and then do an upgrade to jessie
or sid.  Of course, you will likely experience problems during
the upgrade, as I did, most likely with the upgrade of package
perl-base.  But there are posts to debian-s390 by me that explain
how I worked around it.  If you had a sid system to test with,
you would have realized that this package is unusable and you
never would have uploaded it.
> 
> It worked before the recompilation, hence there might be
> a change in sid vs. wheezy that caused this.

Oh, absolutely.  I downloaded the new source package, built
it on a wheezy system, transferred the binary package to
my jessie system, installed the binary package on my jessie
system, ran zipl, shutdown my system, and IPLed.  It IPLed
just fine.  I then took the exact same source package, compiled
it on a jessie system, installed the binary package, ran zipl,
shutdown, and IPLed.  Kaboom! disabled wait state code X'32EE'.
The C compiler and run-time library used is the only difference.
I think I've proven pretty conclusively that this is C breakage
causing this problem.
> 
> You are talking about Hercules, right?

It doesn't matter.  I get the exact same results on Hercules
as I do on a real mainframe, and vice versa.  I have found
Hercules to be a deadly accurate emulation of real mainframe
hardware, when properly configured.

In my opinion, everyone who maintains a package which is
mainframe-specific, such as s390-tools, and anyone responsible,
in whole or in part, for the s390x port needs their own mainframe
system that they can play around with in a totally unrestricted
manner, without fear of messing someone else up.  And if you
don't have access to a real mainframe, a Hercules emulation of
one is the next best thing.  It's slower than a real mainframe;
but architecturally, it is virtually indistinguishable from a
real mainframe to the software.  And that's what an emulator is
all about, right?

You need a jessie/sid system to play around with.

I must say that the C breakage on s390x is the biggest mess that
I have ever seen, and in the case of this package, has produced
the worst error yet: a totally unbootable system.

By the way, when version 1.17.1 of the package is compiled on
a jessie system, it runs fine.  To me, the most significant
difference between the two packages is that the zIPL portion of
the 1.17.1 package, the boot loader proper, is all written in
assembly language (zipl/boot/sclp.S, zipl/boot/menu.S, etc.),
whereas the zIPL portion of the 1.24.1 package has been rewritten
in C (zipl/boot/sclp.c, zipl/boot/menu.c, etc.).  Since it's
written in C, it needs that minimalist C run-time library
(zipl/boot/libc.c), which the 1.17.1 version doesn't need.

Yes, this bug has C breakage written all over it.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


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

Bug#754129: Lutris package

[Pierre Rudloff]

Hello,

I have built the package for unstable here: 
http://mentors.debian.net/package/lutris


Regards,


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

Bug#756337: Maxima segfaults when calculating determinant

[Robert Dodier]

The segfault is due to the Lisp implementation (namely GCL)
incorrectly handling the attempt to allocate an array which is too
large for available memory. The behavior shown in the 49 by 49 case is
correct: if the array can't be allocated, the Lisp implementation
should print an error message. Crashing with a segmentation fault, as
in the 50 by 50 case, is incorrect behavior.


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

Bug#754973: fixed in blueman 1.23-git201407171232-2

[Dean Hamstead]

This new version seems to change blueman from being a gtk-only piece of 
software to something bound inseparably to gnome.


Which is a real shame as it used to be excellent for use with xfce (or 
other) when a user wants to avoid gnome-bloat.



On Tue, 05 Aug 2014 21:35:04 + Christopher Schramm 
 wrote:

Source: blueman
Source-Version: 1.23-git201407171232-2

We believe that the bug you reported is fixed in the latest version of
blueman, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 754...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christopher Schramm  (supplier of updated blueman 
package)


(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 05 Aug 2014 10:35:00 +0200
Source: blueman
Binary: blueman
Architecture: source amd64
Version: 1.23-git201407171232-2
Distribution: unstable
Urgency: low
Maintainer: Christopher Schramm 
Changed-By: Christopher Schramm 
Description:
blueman - Graphical bluetooth manager
Closes: 741961 754973
Changes:
blueman (1.23-git201407171232-2) unstable; urgency=low
.
* Upstream snapshot for unstable (Closes: #754973, #741961)
Checksums-Sha1:
9e9b5b339b4ebe80550b7a56aef5129e6c144098 2016 
blueman_1.23-git201407171232-2.dsc
e6af770daf16c061cfc8524aaad2dc7e9e190fe2 4324 
blueman_1.23-git201407171232-2.debian.tar.xz
4b3ba5fb7b25e5694048aea28bc00643648b9ff4 449576 
blueman_1.23-git201407171232-2_amd64.deb

Checksums-Sha256:
6fe5fcbef0386cf170d6641058ee585da4b01a27fd4044f6ed8a7b03f8afa3cb 2016 
blueman_1.23-git201407171232-2.dsc
874af5e9a5644260f03cff285bfad0689dbb0dae0fe99491c29745fa97d1ba6d 4324 
blueman_1.23-git201407171232-2.debian.tar.xz
a2228cf2992c773b36896f85f690a51d66e189adf09fa3956f252bd2dc58cd22 449576 
blueman_1.23-git201407171232-2_amd64.deb

Files:
30588c3972ad4111acf62045f1044bfb 449576 x11 optional 
blueman_1.23-git201407171232-2_amd64.deb
932b4abcc7157d85ebf5f9e5b7159095 2016 x11 optional 
blueman_1.23-git201407171232-2.dsc
0af19f3d7fe6fd0581d94f97080bec10 4324 x11 optional 
blueman_1.23-git201407171232-2.debian.tar.xz


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT4TT7AAoJEDIkf7tArR+m244P/0lDD69DCk8QQOlHGSfKd5FP
eIstilM+mZ/G6nMksyUsy2X3oYywDGEr91mkZVBh4IHhCpaTCL1238b7UV7R/a8v



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

Bug#758172: isync: Adds . to Maildir directory names

[Mark Brown]

Package: isync
Version: 1.1.1-1
Severity: important

When I run mbsync -V -l -a against my dovecot server I see folders
listed like:

   linux/alsa/devel <=> sirena/linux/alsa/devel

(left is server, right is local Maildirs) as I expect but when I look at
the Maildirs I see that the local folder is actually

   sirena/.linux/.alsa/.devel/

which is very much not expected and quite unhelpful for many operations
(especailly with clients like mutt).  I would expect instead

   sirena/linux/alsa/devel

as above.  I do note that my IMAP server uses . as a namespace delimiter
which I suspect is the source of the error though I've not yet traced
far enough to identify the problem.

Google suggests that I might want to use the Flatten option but this is
surprising and I do want to see a folder heirachy, just without the
added .s in there.

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

Kernel: Linux 3.14-2-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

Versions of packages isync depends on:
ii  libc62.19-7
ii  libdb5.3 5.3.28-5
ii  libssl1.0.0  1.0.1i-1

isync recommends no packages.

Versions of packages isync suggests:
ii  mutt  1.5.23-1

-- 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#617357: incorrect handling of UTF8 characters

[Robert Dodier]

This behavior is due to the underlying Lisp implementation (namely
GCL) incorrectly handling UTF-8 characters. (You are working with
Maxima as compiled by GCL, right? If I am not mistaken, that is the
default for Debian.)

You can work around this behavior by compiling Maxima with a
UTF-8-aware Lisp implementation such as SBCL or Clisp. There are
probably others as well.


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

Bug#737395: Emacs Funny Manpages Copyright

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Okay, but as it stands, there is not even the right to distribute.

Indeed, they ought to have a sharable license.

In fact, the next Emacs release won't have these files any more.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.


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

Bug#758168: Another missing "wine-development" in the new wine-development packages

[Jens Reyer]

I hope this is the last one. I guess no separate bug report necessary:

/usr/bin/wine-development (debian/scripts/wine) recommends to install
wine32. I guess this should be wine32-development instead:

--- snip ---
elif test -x $wine64; then
wine=$wine64
if [ "$(dpkg --print-architecture)" = "amd64" -a "$(dpkg
--print-foreign-architectures)" != "i386" ]; then
echo "it looks like multiarch needs to be enabled.  as root, please"
echo "execute \"dpkg --add-architecture i386 && apt-get install
wine32\""
fi
else
--- snap ---


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

Bug#615468: plotting leaves temporary file (maxout.gnuplot_pipes) in $HOME

[Robert Dodier]

Temporary files are written into the directory named by
maxima_tempdir. You can set maxima_tempdir to "/tmp" or something like
that.

My advice is to close this report, as it isn't a bug from the Maxima
developers point of view.


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

Bug#704624: Build fails to use -ffreestanding

[Aurelien Jarno]

Control: tag -1 + moreinfo

On Wed, Apr 03, 2013 at 06:53:09PM +0100, Robie Basak wrote:
> Package: openhackware
> Version: 0.4.1-6
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu raring ubuntu-patch
> 
> In Ubuntu, we're getting a build failure like this:
> 
> /build/buildd/openhackware-0.4.1/src/bootinfos.c:282: undefined reference 
> to `__stack_chk_fail'
> 
> The fix is to build with -ffreestanding to tell the compiler that this
> will be standalone object code.
> 
> I can't easily test on Debian since it doesn't have a cross-compiler
> package for powerpc, but if you can use -ffreestanding I think it may
> make sense to do so. Thank you for your consideration.

I have not been able to reproduce the issue, neither with 0.4.1-6 nor
with version 0.4.1+git-20140423.c559da7c-1 I have just uploaded. Are you
sure it is not related to your cross-compiler?

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


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

Bug#758168: [pkg-wine-party] Bug#758168: wineapploader looks for wine-unstable

[jre]

Yes, changing this in /usr/lib/wine-development/wineapploader fixes it.

So debian/patches/wineapploader.patch needs to be changed:
<+exec wine-unstable "$appname" "$@"
>+exec wine-development "$appname" "$@"



While looking at this I spotted another use of "wine-unstable" in
debian/scripts/import in wine-developmeent 1.7.24-2 (the git repository
is out of date).
Since I don't use this script, I don't know if this is actually wrong:

--- snip ---
case "$upstream_version" in
  1.0.*|1.2|1.2.*|1.4|1.4.*|1.6|1.6.*)
package=wine
;;
  1.1.*|1.3.*|1.5.*|1.7.*)
package=wine-unstable
;;
  *)
echo "Unknown version series: $upstream_version"
exit 1
;;
esac
--- snap ---


shouldn't this be something like:

--- snip ---
[...]
  1.7.2[2-9]|1.7.3[0-9]|1.7.4[0-9])
package=wine-development
;;
  1.1.*|1.3.*|1.5.*|1.7.*)
package=wine-unstable
;;
[...]
--- snap ---


Hope I helped.
jre


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

Bug#754850: upower 0.99 drops support for non-systemd

[Adam Borowski]

On Fri, Aug 15, 2014 at 12:33:35AM +0200, Andreas Henriksson wrote:
> I fail to see any argument on why this is not already resolved.

Suspend and hibernate don't work if upower is upgraded, duh.

> On Mon, Aug 11, 2014 at 12:00:16AM +0200, Adam Borowski wrote:
> [...]
> > It would be a wishlist issue if:
> > 1. it was a request for new functionality, or
> > 2. the issue was cosmetic
> > 
> > What we have here is something that:
> > 1. is a regression, and
> > 2. makes the computer as a whole seriously less usable
> 
> Please don't make things up yourself, point to the relevant
> parts of the policy for justification! If you can't find anything
> in policy, then well it's not a policy violation

# The severity levels are:
[...]
# grave
#makes the package in question unusable or mostly so, or causes data
#loss, or introduces a security hole allowing access to the accounts of
#users who use the package.

The package "upower" fails to fulfill any of its functionality on any system
without systemd-sysv.

I do not understand why Michael Biebl reassigned this bug against
xfce4-session, as 1. it's upower that's the culprit, and 2. same applies to
other desktop environments.

> > > Once you've provided a patch the maintainers should (note should, not
> > > must!) consider your suggested solution 
> > 
> > Yes, at least one solution is simple: revert upower to the last functional
> > version.
> > 
> > There are other ways, like using pm-utils directly, but that would require
> > actual work that, per your own words, we cannot force the maintainer to do.
> 
> That work has already been done.
> 
> https://alioth.debian.org/scm/loggerhead/collab-maint/systemd-shim/trunk/view/head:/src/power-unit.c#L34
> 
> As already discussed, systemd-shim is already part of xfce4-power-manager
> recommends so you should already have it installed.

Have you actually tried installing systemd + systemd-shim?

You lose the following functionality:
* suspend
* hibernate
* shutdown
* reboot
* mounting removable devices
* etc, etc...
In other words, basically the whole utopia stack stops working (compared to
using their last version without a systemd dependency).

So no, systemd-shim does not fix the problem.

> > > -- to be in line with the
> > > tech-cttes wishes to support multiple init systems when possible.
> > 
> > Which clearly states that dropping support for other init systems must not
> > be done without a good reason.  Here, we have:
> > * upower 0.9: works with systemd, sysvinit, openrc, upstart
> > * upower 0.99: works with systemd only
> > So it's a straight regression, without even giving any new functionality in
> > return.
> 
> This is not true. See above.

Please explain.  upower 0.9 did work correctly, and continues to do so if
you keep it held.  upower 0.99 does not.

> > Apologies for participating in a BTS ping pong, but as the severity has been
> > changed by someone involved in Gnome3 rather than XFCE, I consider this
> > action to have been anything but unbiased.  The Gnome3 team is quite known
> > for its zeal towards systemd, to the exclusion of any other init system.
> 
> http://en.wikipedia.org/wiki/Association_fallacy

Uhm... from the page you quote:

# An association fallacy is an inductive informal fallacy of the type hasty
# generalization or red herring which asserts that qualities of one thing
# are inherently qualities of another, merely by an irrelevant association. 

What I claimed in the paragraph above is not that the Gnome3 team is
associated with the systemd team (which would be possibly irrelevant), but
that they do actively seek to make systemd the only supported init system
-- ie, that the association _is_ relevant.  Their reason is understandable:
less work required to make Gnome3 work, but I do claim it is harmful for the
rest of Debian outside Gnome3.  Including xfce, the default desktop
environment.

Among five computers in the room I'm currently in, three can not run systemd
due to various reasons, so I'd call Debian continuing to support non-systemd
to be pretty vital.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


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

Bug#758171: RM: wine-unstable -- ROM; source package renamed

[Michael Gilbert]

package: ftp.debian.org
severity: normal

Please remove src:wine-unstable.  It's been renamed to src:wine-development.

Best wishes,
Mike


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

Bug#758170: linux-image-3.14-1-amd64: read() cannot return more than 0x7ffff000, even on a regular file, breaking POSIX compliance

[Vincent Lefevre]

Package: src:linux
Version: 3.14.12-1
Severity: normal

Consider the following program:


#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main (void)
{
  size_t count = (size_t) 3 << 30;
  ssize_t ret;
  void *buf;
  int fd;

  printf ("SSIZE_MAX   = 0x%zx\n", (ssize_t) SSIZE_MAX);
  printf ("count   = 0x%zx\n", count);

  if (count > SSIZE_MAX)
{
  fprintf (stderr, "count is too large\n");
  return 1;
}

  buf = malloc (count);
  if (buf == NULL)
{
  fprintf (stderr, "malloc() failed\n");
  return 1;
}

  fd = open ("text", O_RDONLY);
  if (fd == -1)
{
  fprintf (stderr, "open() failed\n");
  return 1;
}

  ret = read (fd, buf, count);
  printf ("#bytes read = 0x%zx\n", ret);

  return 0;
}


When I create a regular 6GB file "text" and run this program, I get:

SSIZE_MAX   = 0x7fff
count   = 0xc000
#bytes read = 0x7000

i.e. read() has returned a value less than the byte count provided
in argument (nbyte in POSIX).

http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html
says:

  The value returned may be less than nbyte if the number of bytes left
  in the file is less than nbyte, if the read() request was interrupted
  by a signal, or if the file is a pipe or FIFO or special file and has
  fewer than nbyte bytes immediately available for reading.

Here, the file has more than nbyte bytes, there wasn't any signal,
and the file is a regular file. Therefore nbyte bytes should have
been read, not less!

-- Package-specific info:
** Version:
Linux version 3.14-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 
(Debian 4.8.3-4) ) #1 SMP Debian 3.14.12-1 (2014-07-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.14-1-amd64 
root=UUID=e3631277-c4d0-460e-a2a3-6de16013e050 ro quiet

** Tainted: I (2048)
 * Working around severe firmware bug.

** Kernel log:
[1085538.208727] do_general_protection: 1 callbacks suppressed
[1085538.208731] traps: ld-linux-x32.so[29225] general protection ip:f7743cbd 
sp:ffa28668 error:0 in ld-2.19.so[f772d000+2]
[1085538.248454] traps: ld-linux-x32.so[29248] general protection ip:f7752cbd 
sp:ffc98e98 error:0 in ld-2.19.so[f773c000+2]
[1085538.274748] traps: ld-linux-x32.so[29261] general protection ip:f7731cbd 
sp:ffebc708 error:0 in ld-2.19.so[f771b000+2]
[1085538.295996] traps: ld-linux-x32.so[29274] general protection ip:f77bccbd 
sp:ffe1c6f8 error:0 in ld-2.19.so[f77a6000+2]
[1085538.350689] traps: ld-linux-x32.so[29321] general protection ip:f76f9cbd 
sp:fff96ce8 error:0 in ld-2.19.so[f76e3000+2]
[1085538.396411] traps: ld-linux-x32.so[29342] general protection ip:f778ecbd 
sp:ffd1ba48 error:0 in ld-2.19.so[f7778000+2]
[1085538.418265] traps: ld-linux-x32.so[29355] general protection ip:f7710cbd 
sp:ffe24cd8 error:0 in ld-2.19.so[f76fa000+2]
[1085538.436837] traps: ld-linux-x32.so[29368] general protection ip:f7744cbd 
sp:ffa14e08 error:0 in ld-2.19.so[f772e000+2]
[1085538.452914] traps: ld-linux-x32.so[29381] general protection ip:f7738cbd 
sp:ffde6f88 error:0 in ld-2.19.so[f7722000+2]
[1085538.474307] traps: ld-linux-x32.so[29394] general protection ip:f7725cbd 
sp:ff90b3a8 error:0 in ld-2.19.so[f770f000+2]
[1085640.462287] do_general_protection: 25 callbacks suppressed
[1085640.462290] traps: ld-linux-x32.so[7040] general protection ip:f7734cbd 
sp:ffe6ed88 error:0 in ld-2.19.so[f771e000+2]
[1085640.496890] traps: ld-linux-x32.so[7063] general protection ip:f77d1cbd 
sp:ff8b6a48 error:0 in ld-2.19.so[f77bb000+2]
[1085640.514538] traps: ld-linux-x32.so[7076] general protection ip:f77efcbd 
sp:ffe47ca8 error:0 in ld-2.19.so[f77d9000+2]
[1085640.540271] traps: ld-linux-x32.so[7089] general protection ip:f7741cbd 
sp:ffeaecc8 error:0 in ld-2.19.so[f772b000+2]
[1085640.592556] traps: ld-linux-x32.so[7136] general protection ip:f7728cbd 
sp:fffc4e88 error:0 in ld-2.19.so[f7712000+2]
[1085640.615378] traps: ld-linux-x32.so[7157] general protection ip:f77aacbd 
sp:ff9d81c8 error:0 in ld-2.19.so[f7794000+2]
[1085640.632819] traps: ld-linux-x32.so[7170] general protection ip:f7703cbd 
sp:ff9bf198 error:0 in ld-2.19.so[f76ed000+2]
[1085640.650620] traps: ld-linux-x32.so[7183] general protection ip:f7712cbd 
sp:ff9b0f28 error:0 in ld-2.19.so[f76fc000+2]
[1085640.670911] traps: ld-linux-x32.so[7196] general protection ip:f77a0cbd 
sp:ffa1e588 error:0 in ld-2.19.so[f778a000+2]
[1085640.690412] traps: ld-linux-x32.so[7209] general protection ip:f77eccbd 
sp:ffafa798 error:0 in ld-2.19.so[f77d6000+2]
[1086096.441814] systemd-logind[18002]: Removed session 508.
[1086096.863394] systemd-logind[18002]: New session 508 of user vlefevre.
[1086097.741744] systemd-logind[18002]: Removed session 508.
[1086111.433394] systemd-logind[18002]: New session 508 of user vlefevre.
[118593

Bug#758169: dh-acc: allow debian/package.abi (without the .tar.gz)

[Andrew Kelley]

Package: dh-acc
Version: 1.99.9-2
Severity: wishlist


abi-compliance-checker already supports untarred *.abi files as the
input to -d1. Please make dh_acc support this too.

This prevents having to put an entry in debian/source/include-binaries
The compression is not actually helpful.

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

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

Versions of packages dh-acc depends on:
ii  abi-compliance-checker  1.99.9-2
ii  debhelper   9.20140809
ii  perl5.18.2-7

dh-acc recommends no packages.

dh-acc 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#758068: libapr1: mmap allocator severely limites apache scalability

[Nelson Elhage]

On Thu, Aug 14, 2014 at 12:22 AM, Stefan Fritsch  wrote:
> Can you please try if increasing MaxMemFree to a larger value fixes your
> problem, too? 2048 (KB) is the default.
>

Unfortunately setting that higher (we tried 100MB) doesn't seem to
noticeably improve the situation in our environment.


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

Bug#756947: unble to re-enable wifi/bt after hardware or software disable

[Tomasz Nitecki]

tags 756947 - moreinfo
reassign 756947 firmware-ipw2x00
found 756947 0.36+wheezy.1
thanks


Hey,

A quick summary of the problem:

Alan is using '02:04.0 Network controller: Intel Corporation
PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)' with
ipw2200 driver and correctly loaded non-free firmware blob
'ipw2200-bss.fw'. After he disables the wifi radio via hardware button
or via network manager he is unable to re-enable it. The only way to fix
it is to reset BIOS settings to default configuration (after such a
reset wifi is automatically back on). Rfkill is also unable to re-enable
wifi but after using 'unblock' option and resetting BIOS the wifi is
still disabled (but can be re-enabled by normal means - once).

The only suspicious dmesg message is 'ipw2200: Failed to send
CARD_DISABLE: Command timed out.'

All logs are available in older messages attached to #756947.


Regards and thanks,
T.



signature.asc
Description: OpenPGP digital signature

Bug#758168: wineapploader looks for wine-unstable

[jre]

Package: wine-development
Version: 1.7.24-2
Severity: normal


Hi,

the wrappers /usr/bin/wine* (wineboot, winecfg, ...) don't work:

>winecfg
/usr/bin/winecfg: 52: exec: wine-unstable: not found


I guess this results from /usr/lib/wine-development/wineapploader:

--- snip ---
[...]
# finally look in PATH
exec wine-unstable "$appname" "$@"
--- snap ---


Thanks again, looking forward to use wine-development in Debian
jre


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

Bug#758045: parted: can not delete partition on usb stick: physical block size wrong ?

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please dump the first 64k of the disk and attach it:

dd if=/dev/sdf count=128 | gzip -c > dump.gz

On 08/13/2014 01:19 PM, Lars Cebulla wrote:
> Package: parted Version: 3.2-4 Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
> * What led up to the situation?
> 
> Connect a USB stick. Open a terminal and type "parted --script
> "/dev/sdf" "rm 1""
> 
> * What was the outcome of this action? Warning: The driver
> descriptor says the physical block size is 2048 bytes, but Linux
> says it is 512 bytes.
> 
> * What outcome did you expect instead? Partition should be
> deleted.
> 
> Tried deleting this partition with gnome-disks but internally it
> seems to use parted so I tried it directly as mentioned above.
> 
> This stick works without problems in Wheezy !
> 
> 
> 
> -- System Information: Debian Release: jessie/sid APT prefers
> testing-updates APT policy: (500, 'testing-updates'), (500,
> 'testing') Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale:
> LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell:
> /bin/sh linked to /bin/dash
> 
> Versions of packages parted depends on: ii  libc6 2.19-7 ii
> libparted23.2-4 ii  libreadline6  6.3-8 ii  libtinfo5
> 5.9+20140712-2
> 
> parted recommends no packages.
> 
> Versions of packages parted suggests: pn  parted-doc  
> 
> -- no debconf information
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJT7URUAAoJEI5FoCIzSKrwvaYH/R1cVFtzRXAaf6H7bjZZlqjh
jGz20rsJhIVhTPuRVzQFuw5JN1i3lnwlNwq3hzTFYQhs7CdAqfmmS4Z5Il6N7w8M
7NwhcqmVPxVJ168idXsucQGoiu/f3+e5RFoXMXAHN7ivrHGPLylR8aKpDm2s+l4H
lFHsA07W6tQngzlrNQyWRTiBPchlqG69WZ2fMKJ+IlGsvgKRyx5NdAg1oi5eGkZB
TAqEnz3OU8oP01oBX1pmnK+gsG/ghDemT84WbMh7UtJlTp9Se3W8JQv5mRx6vcoT
likgQ89Ws4MZQx6no+WmNOS98BnBDHxeMJPpQ11cmMD5CkyKVkhNa50HvHB7YfY=
=MEo7
-END PGP SIGNATURE-


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

Bug#758167: installation-reports: System does not reboot automatically after install is finished

[Tony Rowe]

Package: installation-reports
Severity: minor
Tags: d-i

Dear Maintainer,

-- Package-specific info:

Boot method: usb stick
Image version: daily-images/i386/daily/netboot/mini.iso
Date: 13-Aug-2014 
Time of Installation: 13-Aug 1:PM ADT
Machine: IBM Thinkpad T60
Partitions: 
tony@slice:~$ sudo fdisk -l

Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders, total 117210240 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x25418b2e

   Device Boot  Start End  Blocks   Id  System
/dev/sda1   *2048   11236351956180736   83  Linux
/dev/sda2   112365566   117209087 24217615  Extended
/dev/sda5   112365568   117209087 2421760   82  Linux swap / Solaris


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [o]
Detect network card:[o]
Configure network:  [o]
Detect CD:  [ ]
Load installer modules: [o]
Clock/timezone setup:   [o]
User/password setup:[o]
Detect hard drives: [o]
Partition hard drives:  [o]
Install base system:[o]
Install tasks:  [o]
Install boot loader:[o]
Overall install:[o]


This is great everyone.  Thanks for all the good work!  I was surprised when I 
saw systemd getting installed.  I 
didn't expect that.  It all worked very well with only the one minor problem at 
the end of the install.

I selected LXDE desktop for this install. The 
remove-install-media-and-boot-into-the-new-system step left the 
machine hanging with a blank screen, except for a blinking cursor in the upper 
left corner.

Now, "shutdown" and "reboot" from the LXDE desktop-menu at the bottom right 
corner of the screen (which 
announces itself with the question, "Logout LXDE testing session?") also fail: 
clicking on them just does 
nothing at all (which is not exactly the same thing as hanging the system).  
Still, could the hang at the end of 
my install be a LXDE/systemd problem?

# shutdown -h now  
# systemctl poweroff   both work as expected

There are no clues in syslog, ACPI seems happy enough there.  I don't know if 
systemd's journald keeps tabs on 
acpi elsewhere?  Let me know if there is anything I can send on.  I need to 
stop for today.  Just wanted to get 
this out the door.  

Tony

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="8 (jessie) - installer build 20140813-00:10"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux slice 3.14-2-486 #1 Debian 3.14.15-2 (2014-08-09) i686 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 
943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
lspci -knn: Subsystem: Lenovo Device [17aa:2017]
lspci -knn: Kernel driver in use: agpgart-intel
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 
945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 
03)
lspci -knn: Subsystem: Lenovo Device [17aa:201a]
lspci -knn: 00:02.1 Display controller [0380]: Intel Corporation Mobile 
945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] 
(rev 03)
lspci -knn: Subsystem: Lenovo Device [17aa:201a]
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family 
High Definition Audio Controller [8086:27d8] (rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:2010]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 1 [8086:27d0] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 2 [8086:27d2] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 3 [8086:27d4] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 4 [8086:27d6] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #1 [8086:27c8] (rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:200a]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation NM1

Bug#634995: www.debian.org: please add a link to the Debian Constitution in the front page

[David Prévot]

Hi,

On Thu, Jul 21, 2011 at 05:02:54PM +0200, Luca Capello wrote:

> I could not find a link to the Debian Constitution [1] in the front
> page.
[…]
> IMHO given the importance of this document, especially WRT to money
> Debian owns (actually, it does not as per §9 [4], see also #634986 [5]),
> we should give it more visibility.

On the contrary, given this document is really technical and related to
the project’s internals, adding it to the mainpage, mainly targeted to
the widest audience, seems like a bad idea to me.

I thus believe that advertising such document in the devel page is
enough for its purpose, and propose to close this bug as wontfix.

> [1] 
[…]
> [4] 
> [5] 

Regards

David


signature.asc
Description: Digital signature

Bug#757735: Backtrace for gtk-gnutella 1.1.0

[brian m. carlson]

GNU gdb (Debian 7.7.1-2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gtk-gnutella...done.
(gdb) run
Starting program: /usr/bin/gtk-gnutella 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
14-08-14 22:48:33.340 (FATAL): Assertion failure at src/lib/xmalloc.c:1295: 
"size_is_positive(len)"
14-08-14 22:48:33.340 (WARNING): disabling locks, now in thread-unsafe mode (2 
threads)
14-08-14 22:48:33.340 WARNING: crashing before any crash_init() call
Locks owned by thread "main", most recent first:
  #2 0xbab458 mutex from src/lib/xmalloc.c:2513 (depth=1)
  #1 0xadccb0 spinlock from src/lib/zalloc.c:1681
  #0 0xadcb80 spinlock from src/lib/walloc.c:209

Program received signal SIGSEGV, Segmentation fault.
sig_compute_pc_index () at signal.c:462
462 *p = 1; /* We expect 
this to raise a SIGSEGV */
(gdb) c
Continuing.
14-08-14 22:48:33.340 (WARNING): thread "main" releases spinlock 0xadc6a0 at 
inner position 4/6
Locks owned by thread "main", most recent first:
  #5 0xc38cc8 mutex DESTROYED
  #4 0xc37a50 mutex DESTROYED
  #3 0xadc6a0 spinlock UNLOCKED from src/lib/stacktrace.c:552
  #2 0xbab458 mutex from src/lib/xmalloc.c:2513 (depth=1)
  #1 0xadccb0 spinlock from src/lib/zalloc.c:1681
  #0 0xadcb80 spinlock from src/lib/walloc.c:209
assertion_failure() "lib/fast_assert.c:269"
xfl_find_freelist_index() "lib/xmalloc.c:1295"
xmalloc_freelist_add() "lib/xmalloc.c:3376"
xfl_extend() "lib/xmalloc.c:1918"
xfl_insert() "lib/xmalloc.c:2269"
xfl_insert_careful() "lib/xmalloc.c:2533"
xmalloc_freelist_insert() "lib/xmalloc.c:3197"
xallocate() "lib/xmalloc.c:4609"
malloc() "lib/xmalloc.c:4667"
hash_table_new_full() "lib/hashtable.c:460"
zget() "lib/zalloc.c:1684"
wzone_get() "lib/walloc.c:184"
walloc_raw() "lib/walloc.c:248"
thread_launch() "lib/thread.c:7023"
tm_thread_start() "lib/tm.c:461"
tm_time_exact() "lib/tm.c:668"
evq_init_once() "lib/evq.c:279"
once_flag_run_internal() "lib/once.c:144"
evq_init() "lib/evq.c:311"
once_flag_run_internal() "lib/once.c:144"
vmm_init_once() "lib/vmm.c:5209"
once_flag_run_internal() "lib/once.c:144"
vmm_alloc_internal() "lib/vmm.c:3772"
omalloc_allocate() "lib/omalloc.c:647"
omalloc0() "lib/omalloc.c:790"
thread_preallocate_element() "lib/thread.c:1688"
thread_main_element() "lib/thread.c:1873"
thread_small_id() "lib/thread.c:2932"
xmalloc_thread_free() "lib/xmalloc.c:4347"
selinuxfs_exists() : libselinux.so.1
init() : libselinux.so.1
call_init() "dl-init.c:78" : ld-linux-x86-64.so.2
call_init() "dl-init.c:36" : ld-linux-x86-64.so.2
0x77ddd1ca : ld-linux-x86-64.so.2

Program received signal SIGABRT, Aborted.
0x74064407 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0  0x74064407 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 23380
selftid = 23380
#1  0x740657e8 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0, 0, 140737351949831, 1, 0, 0, 140737287249192, 8657008, 
0, 0, 140737351975717, 0, 0, 0, 
  140737488344112, 1}}, sa_flags = 11388416, sa_restorer = 
0x7fffd280}
sigs = {__val = {32, 0 }}
#2  0x0062f783 in crash_abort () at crash.c:3031
No locals.
#3  0x00443dfc in assertion_abort () at fast_assert.c:178
seen_fatal = 1
#4  0x00444035 in assertion_failure (data=data@entry=0x841870 
) at fast_assert.c:269
No locals.
#5  0x006c3d9a in xfl_find_freelist_index (len=0) at xmalloc.c:1295
assertion_data_ = {file = 0x83c748 "src/lib/xmalloc.c", expr = 0x70357b 
"size_is_positive(len)", line = 1295}
#6  xfl_find_freelist (len=0) at xmalloc.c:1314
No locals.
#7  xmalloc

Bug#758060: [Pkg-acpi-devel] Bug#758060: acpi-fakekey: fails to install

[Keith Lee]

On 14 August 2014 10:48, Michael Meskes  wrote:

> On Wed, Aug 13, 2014 at 09:34:32PM +0100, Keith Lee wrote:
> > I purged acpi-fakekey and acpi-support then reinstalled.
>
> Does the same happen if you install other packages that have init scripts?
>

You are correct the same results with other init packages.

>
> > -- Output from dpkg
> > Selecting previously unselected package acpi-fakekey.
> > (Reading database ... 90664 files and directories currently installed.)
> > Unpacking acpi-fakekey (from .../acpi-fakekey_0.140-5+deb7u2_amd64.deb)
> ...
> > Selecting previously unselected package acpi-support.
> > Unpacking acpi-support (from .../acpi-support_0.140-5+deb7u2_all.deb) ...
> > Processing triggers for man-db ...
> > Setting up acpi-fakekey (0.140-5+deb7u2) ...
> > insserv: warning: script 'K10runmbbservice' missing LSB tags and
> overrides
> > insserv: warning: script 'runmbbservice' missing LSB tags and overrides
> > insserv: There is a loop at service rc.local if started
> > insserv: There is a loop between service rc.local and mountnfs if started
> > insserv:  loop involving service mountnfs at depth 7
> > insserv:  loop involving service nfs-common at depth 6
> > insserv: Starting runmbbservice depends on rc.local and therefore on
> system facility `$all' which can not be true!
> > 
> > ..
>
> Frankly I cannot see anything related to acpi-fakekey here, other than it's
> installation triggering the insserv run. What is runmbbservice? Could it be
> that you have third party software installed?
>

I agree,  it looks like runmbbservice was something I installed from a
Mobile Broadband device a few days earlier.

The update I performed was the first after the runmbbservice install and it
looks like acpi-fakekey was the first package to get caught up in the mess
caused by the runmbbservice package.

My apologies Michael, for missing the mark with the bugrep and thank you
very much for spotting the real culprit, helping me resolve the issue I had.

With the init scripts for runmbbservice removed the install of acpi-fakekey
and acpi-support completed perfectly.



> Michael
>
> --
> Michael Meskes
> Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
> Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
> Jabber: michael.meskes at gmail dot com
> VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
>

Bug#688760: please enable upstream crash reporting

[Mike Hommey]

On Thu, Aug 14, 2014 at 04:15:57PM +0200, Sylvestre Ledru wrote:
> Hello,
> 
> On 25/07/2014 12:05, Sylvestre Ledru wrote:
> > Hello,
> >
> > The attached patch enables the crash reporting tool.
> >
> > It would be nice if that could be implemented in a future upload. Crash
> > report is a critical part of the Firefox upstream release team workflow.
> > Having Debian/Linux packages reporting would help to improve the overall
> > quality of the software.
> >
> Mike, how can I help here?

By figuring out a way to have significant symbol dumps for consumption
by Mozilla from the -dbg package, cf. our irc conversation a few weeks ago.

Mike


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

Bug#746378: Twisted Python breaks Flumotion

[Jeff Sereno]

Twisted Python no longer has "listenWith" in it. Until Flumotion is 
updated to not use this function, you need to downgrade to to Twisted 
Python 11.1.0.


Probably the same as it is on Ubuntu, but I got it running by 
downgrading the following packages:


python-twisted-bin
python-twisted-core
python-twisted-web

Install Flumotion as normal then force the uninstallation of the above 
packages using dpkg (which will temporarily break dependencies) and then 
reinstall the older debs using dpkg. For Ubuntu, I got the debs from the 
12.04 repository here:


http://au.archive.ubuntu.com/ubuntu/pool/main/t/twisted/python-twisted-bin_11.1.0-1ubuntu2_amd64.deb
http://au.archive.ubuntu.com/ubuntu/pool/main/t/twisted/python-twisted-core_11.1.0-1ubuntu2_all.deb
http://au.archive.ubuntu.com/ubuntu/pool/main/t/twisted-web/python-twisted-web_11.1.0-1_all.deb

Note however that while Flumotion now runs, this appears to disrupt the 
Flumotion UI somewhat and you might not be able to use the Flumotion 
Assistant (some fields for entering data like framerate are missing and 
cause the config to go belly-up), but you should be able to get around 
that by generating the XML config file elsewhere and then importing that 
into Flumotion via the Admin UI. I'm still testing this under Ubuntu 14.04.


This of course may break things elsewhere that depend on Twisted Python too.

Cheers,

Jeff.

Bug#754850: upower 0.99 drops support for non-systemd

[Andreas Henriksson]

Hello Adam Borowski!

I see you've yet again made the top of my Debian Maintainer Dashboard.

I fail to see any argument on why this is not already resolved.
Please see inline answers below.

On Mon, Aug 11, 2014 at 12:00:16AM +0200, Adam Borowski wrote:
[...]
> It would be a wishlist issue if:
> 1. it was a request for new functionality, or
> 2. the issue was cosmetic
> 
> What we have here is something that:
> 1. is a regression, and
> 2. makes the computer as a whole seriously less usable

Please don't make things up yourself, point to the relevant
parts of the policy for justification! If you can't find anything
in policy, then well it's not a policy violation

> 
> > Once you've provided a patch the maintainers should (note should, not
> > must!) consider your suggested solution 
> 
> Yes, at least one solution is simple: revert upower to the last functional
> version.
> 
> There are other ways, like using pm-utils directly, but that would require
> actual work that, per your own words, we cannot force the maintainer to do.

That work has already been done.

https://alioth.debian.org/scm/loggerhead/collab-maint/systemd-shim/trunk/view/head:/src/power-unit.c#L34

As already discussed, systemd-shim is already part of xfce4-power-manager
recommends so you should already have it installed.

What part of this does not already please your wishes? Feel free to
describe them in a wishlist bug (against systemd-shim?). ;P

> 
> > -- to be in line with the
> > tech-cttes wishes to support multiple init systems when possible.
> 
> Which clearly states that dropping support for other init systems must not
> be done without a good reason.  Here, we have:
> * upower 0.9: works with systemd, sysvinit, openrc, upstart
> * upower 0.99: works with systemd only
> So it's a straight regression, without even giving any new functionality in
> return.

This is not true. See above.

(Fwiw, D-Bus is a general IPC mechanism. It was not invented in/for systemd.)

> 
> > and since it seems every project
> > out there are now standardising on the logind D-Bus abstraction, with
> > different backends implementations, using another API is probably not
> > worth investing time in.
> 
> If so, the burden lies solely in the upower land, and it's that package that
> has regressed here.
> 
> > Now that we've cleared up the confusion here, I'm adjusting the title
> > and severity of this bug report accordingly as you can see above.
> 
> I'm restoring the title to a reasonable value (as it's a regression rather
> than a wish).  The severity was wrong (grave vs serious), but that's a
> pretty minor distinction.  It's certainly not "wishlist".
> 
> I do think, though, that this bug should be reassigned back to upower as
> it's not the fault of xfce4-session, but I'm leaving this up to the
> maintainer.

Please feel free to do so if you want me to handle it the way 
Yves-Alexis Perez suggested. (eg. wontfix + close)

> 
> 
> Apologies for participating in a BTS ping pong, but as the severity has been
> changed by someone involved in Gnome3 rather than XFCE, I consider this
> action to have been anything but unbiased.  The Gnome3 team is quite known
> for its zeal towards systemd, to the exclusion of any other init system.

http://en.wikipedia.org/wiki/Association_fallacy


Regards,
Andreas Henriksson


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

Bug#758090: ltspfs: lbmount use of "mount --move" incompatible with systemd

[Vagrant Cascadian]

On 2014-08-14, Vagrant Cascadian wrote:
> Honestly, I'd rather figure out a way to safely mount the ltspfs mount
> directly without "mount --move". We could have a setuid wrapper that instead
> creates the mountpoint directly as /media/USERNAME/MOUNT 

Patch below which basically implements this part...


> and ensures it actually mounts, and some way of ensuring that it
> unmounts and removes the /media/USERNAME/MOUNT directory when
> done... possibly with a mount.helper and/or umount.helper

It doesn't include a mount/umount helper, or prevent the user from using
lbmount to create arbitrary /media/USERNAME/* dirs owned by them.

It is a huge reduction in setuid root code:

 scripts/ltspfsmounter | 37 +++--
 src/lbmount.c | 68 

 2 files changed, 11 insertions(+), 94 deletions(-)

diff --git a/scripts/ltspfsmounter b/scripts/ltspfsmounter
index 5322b23..97b45ff 100644
--- a/scripts/ltspfsmounter
+++ b/scripts/ltspfsmounter
@@ -28,47 +28,35 @@ def run_hooks(mode, mountpoint):
 def get_var(name):
 return os.environ.get(name)
 
-def add_ltspfsmount(conn, path, root, dev, mediaroot):
-hidden_mount = '%s/%s' % (root, dev)
+def add_ltspfsmount(conn, path, dev, mediaroot):
 lbmount_command = ['lbmount', dev]
-ltspfs_mount = ['ltspfs', conn+':'+path, root+'/'+dev]
-ltspfs_umount=['fusermount', '-uzq', hidden_mount]
-
-if not os.access(root, 0):
-os.mkdir(root)
-if not os.access(hidden_mount, 0):
-os.mkdir(hidden_mount)
+ltspfs_mount = ['ltspfs', conn+':'+path, mediaroot+'/'+dev]
 
 env = os.environ.copy()
 
 try:
-call(ltspfs_mount, env=env)
-except OSError, e:
-print >>sys.stderr, "mount failed:", e
-try:
 call(lbmount_command)
-if os.access(hidden_mount, 0):
-call(ltspfs_umount)
-os.rmdir(hidden_mount)
-if os.access(root, 0):
-os.rmdir(root)
 run_hooks('add', os.path.join(mediaroot, dev))
 except OSError, e:
 print >>sys.stderr, "suid mount failed:", e
+try:
+call(ltspfs_mount, env=env)
+except OSError, e:
+print >>sys.stderr, "mount failed:", e
 
 def remove_ltspfsmount(root, dev):
 lbumount_command=['lbmount', '--umount', dev]
 ltspfs_umount=['fusermount', '-uzq', root+'/'+dev]
 
 try:
-call(lbumount_command)
-except OSError, e:
-print >>sys.stderr, "suid umount failed:", e
-try:
 call(ltspfs_umount)
 run_hooks('remove', os.path.join(root, dev))
 except OSError, e:
 print >>sys.stderr, "umount failed:", e
+try:
+call(lbumount_command)
+except OSError, e:
+print >>sys.stderr, "suid umount failed:", e
 
 def cleanup(user):
 known_mounts = open( '/proc/mounts', 'r' ).readlines()
@@ -78,8 +66,6 @@ def cleanup(user):
 mountpoint=mount.split()[1]
 device=mountpoint.split('/')[-1]
 if dir=='/media' and mountpoint.startswith(dir):
-call(['lbmount', '--umount', device])
-elif dir=='/tmp' and mountpoint.startswith(dir):
 call(['fusermount', '-uzq', mountpoint])
 if os.access(mountpoint, 0):
 os.rmdir(mountpoint)
@@ -104,7 +90,6 @@ def main():
 path = sys.argv[1]
 command = sys.argv[2]
 username = get_var('USER')
-root = "/tmp/.%s-ltspfs" % username
 mediaroot = "/media/%s" % username
 
 if not get_var('SSH_CONNECTION'):
@@ -116,7 +101,7 @@ def main():
 dev = path.split('/')[-1]
 
 if command=='add':
-add_ltspfsmount(conn, path, root, dev, mediaroot)
+add_ltspfsmount(conn, path, dev, mediaroot)
 elif command=='remove':
 remove_ltspfsmount(mediaroot, dev)
 elif command=='cleanup':
diff --git a/src/lbmount.c b/src/lbmount.c
index 61152f5..dea7bd6 100644
--- a/src/lbmount.c
+++ b/src/lbmount.c
@@ -53,8 +53,6 @@ static uid_t uidReal;   /* Users real userid */
  */
 
 static char *mediadir = "/media";
-static char *ltspfsdir1 = "/tmp/.";
-static char *ltspfsdir2 = "-ltspfs/";
 static char *mountprog = "/bin/mount";  /* system mount program */
 static char *umountprog = "/bin/umount";/* system umount program */
 
@@ -135,52 +133,6 @@ void mkdir_safe(char *dir)
 }
 
 /*
- * domount: actually bindmounts path1 onto path2.
- */
-
-int root_mounter(const char *path1, const char *path2)
-{
-int status;
-pid_t child;
-char *program;
-char *null_env[] = { NULL };
-
-child = fork();
-
-if (child == 0) {
-if (setreuid(0, -1)) {
-/* Couldn't become root */
-perror("Couldn't obtain root privs");
-exit(1);
-}
-/* Statically build command line to prevent monkey business */
-if (path2)
-execle(mountprog, mountprog, "--bind", path1, path2,

Bug#596527: #596527 - yelp: spawns a neverending sequence of new windows

[Eliad Bagherzadegan]

Hi,

> Could you please still reproduce this issue with newer yelp version like
3.12.0-1 ?

I do not use gnome anymore. But, as I recall it was a conflict with another
package that was causing it. Did you try that?

Eliad

--
Eliad Bagherzadegan

Bug#758166: dia: Invalid arc in .dia crashes amd64 (but not i386)

[Sander Brandenburg]

Package: dia
Version: 0.97.2-8
Severity: normal
Tags: patch


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

Kernel: Linux 3.11.0-19-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages dia depends on:
ii  dia-common  0.97.2-8
ii  dia-libs0.97.2-8
ii  libart-2.0-22.3.21-2
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-38+deb7u2
ii  libcairo2   1.12.2-3
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgtk2.0-0 2.24.10-2
ii  libpango1.0-0   1.30.0-1
ii  libpng12-0  1.2.49-1
ii  libxml2 2.8.0+dfsg1-7+nmu3
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages dia recommends:
ii  gsfonts-x11  0.22

dia suggests no packages.

-- no debconf information

On a wheezy i386 I ended up with the following arc definition:
which originated from the following arc:

  

  
  

  
  


  
  

  
  

  


(note curve_distance is 0). This makes dia instances on amd64 platforms crash, 
but not on i386 platforms:
curve_distance == 0 causes center and radius members to contain +/- inf.

This eventually creates a segfault at:
#0  text_get_line_width (text=0x85292a0, line_no=-2147483648) at 
../../lib/text.c:126
in the indexing of lines:
126   return text_line_get_width(text->lines[line_no]);
(which get multiplied by 4, shifting off all bits off line_no on the i386 
platform, but wreaking havoc on amd64)

The fix consist of overriding the supposedly illegal value of 0 to 0.01. I've 
never modified the dia file 
directly - I don't know how that 0 ended up there. Possibly it's a rounding 
issue at serialization?

Index: dia-0.97.2/objects/standard/arc.c
===
--- dia-0.97.2.orig/objects/standard/arc.c  2014-08-14 18:57:31.0 
+
+++ dia-0.97.2/objects/standard/arc.c   2014-08-14 22:05:56.234221798 +
@@ -878,7 +878,7 @@
   arc->curve_distance = 0.1;
   attr = object_find_attribute(obj_node, "curve_distance");
   if (attr != NULL)
-arc->curve_distance = data_real(attribute_first_data(attr));
+arc->curve_distance = MAX(0.01, data_real(attribute_first_data(attr)));
 
   arc->line_width = 0.1;
   attr = object_find_attribute(obj_node, PROP_STDNAME_LINE_WIDTH);


crashdia.dia
Description: GNU Zip compressed data

Bug#758127: libwx-perl: FTBFS on arm*

[Niko Tyni]

clone 758127 -1
reassign -1 wxwidgets3.0 3.0.1-3
retitle -1 wxwidgets3.0: libwx_gtk2u_propgrid-3.0.so.0.1.0  is broken on arm*
block 758127 with -1
thanks

On Thu, Aug 14, 2014 at 11:55:11PM +0300, Damyan Ivanov wrote:

> Program received signal SIGSEGV, Segmentation fault.
> 0xb68e2614 in wxDynamicLibrary::GetLibHandle (this=0x0)
> at /usr/include/wx-3.0/wx/dynlib.h:270
> 270 wxDllType GetLibHandle() const { return m_handle; }
> (gdb) bt
> #0  0xb68e2614 in wxDynamicLibrary::GetLibHandle (this=0x0)
> at /usr/include/wx-3.0/wx/dynlib.h:270
> #1  0xb6857824 in XS_Wx__load_plugin (my_perl=0x12008, cv=0x1c3d60) at 
> Wx.c:646

This can be triggered with just

 % xvfb-run perl -Iblib/lib -Iblib/arch -e 'use Wx; use Wx::PropertyGrid'   
 

The problem seems to be in the wxwidgets3.0 package, whose build logs
on armel and armhf have this:

 dpkg-shlibdeps: warning: symbol _ZNK14wxCommandEvent5CloneEv used by 
debian/libwxgtk3.0-0/usr/lib/arm-linux-gnueabi/libwx_gtk2u_propgrid-3.0.so.0.1.0
 found in none of the libraries

Olly says this is probably related to #752733 but he's not certain.
I'm cloning a separate bug against wxwidgets3.0 at this point.

The current plan for libwx-perl is to fix the test suite not to crash
but skip the failing tests, and then downgrade this to 'important'. The
attached patches are a first stab at this. I ran out of time tonight and
haven't even run a full 'make test' with these yet, but I don't really
expect problems.
-- 
Niko Tyni   nt...@debian.org
>From 95be329c6f7eaefda58edf4db4180a59f44ae9aa Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Thu, 14 Aug 2014 21:50:00 +
Subject: [PATCH 1/2] Fix Wx::_load_plugin() segfaulting when
 wxPluginManager::LoadLibrary fails

FIXME: _load_plugin() is aliased to *DynaLoader::dl_load_file
in Wx::Mini, should this return undef somehow or does 0 work?

Bug-Debian: https://bugs.debian.org/758127
---
 Wx.xs | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Wx.xs b/Wx.xs
index 01029fc..3f5dede 100644
--- a/Wx.xs
+++ b/Wx.xs
@@ -422,7 +422,10 @@ _load_plugin( string, int flags = 0 /* to be compatible with dl_load_file */ )
 #endif
 #endif
 wxDynamicLibrary *lib = wxPluginManager::LoadLibrary( string, wxDL_VERBATIM );
-RETVAL = PTR2IV( lib->GetLibHandle() );
+if (lib)
+RETVAL = PTR2IV( lib->GetLibHandle() );
+else
+RETVAL = 0;
   OUTPUT:
 RETVAL
 
-- 
2.1.0.rc1

>From 6f28d00f4ad9db47f3c8df876e97154f07bdb206 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Thu, 14 Aug 2014 22:02:18 +
Subject: [PATCH 2/2] Temporarily skip tests when the 'use Wx qw(...)' fails

This is a workaround for wxwidgets3.0 breakage, see
https://bugs.debian.org/758127
---
 t/01_load.t | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/t/01_load.t b/t/01_load.t
index 2237a97..c4042c9 100755
--- a/t/01_load.t
+++ b/t/01_load.t
@@ -11,7 +11,8 @@ my $x = wxYES;
 ok( 1, "Exported constant" );
 
 SKIP: {
-  use Wx qw(:frame :allclasses wxNO_3D wxTAB_TRAVERSAL);
+  eval "use Wx qw(:frame :allclasses wxNO_3D wxTAB_TRAVERSAL)";
+  skip("loading :allclasses et al. failed: $@", 2) if $@;
 
   $x = wxTAB_TRAVERSAL();
   $x = wxCAPTION();
-- 
2.1.0.rc1

Bug#758162: python-powerline: Zsh plugin doesn't work at all: ERROR:shell:powerline:Failed to render: coercing to Unicode: need string or buffer, instancemethod found

[Axel Beckert]

Hi,

Axel Beckert wrote:
> To test powerline before adding it to my .zshrc, I sourced
> /usr/share/pyshared/powerline/bindings/zsh/powerline.zsh in a running zsh.
[...]
> The above happened with uxterm from Wheezy and zsh running on Sid via
> SSH.

Also happens locally without SSH, uxterm from Sid and sourcing
/usr/lib/python2.7/dist-packages/powerline/bindings/zsh/powerline.zsh

(Not sure which of the both files is the one meant to be sourced
according to the docs.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


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

Bug#758164: openvpn: OpenVPN in wheezy-backports depends on non-existent "easy-rsa" package

[James Hannah]

Package: openvpn
Version: 2.3.2-7~bpo70+1
Severity: normal

Dear Maintainer,

The OpenVPN package in wheezy-backports depends on the "easy-rsa"
package, which is in Jessie but not in Wheezy.

The normal Wheezy package includes easy-rsa inside the OpenVPN
package itself.

This means that it's not easy to get easy-rsa if you're using
the -backports version of OpenVPN.

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

Kernel: Linux 3.14-0.bpo.2-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

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  initscripts2.88dsf-41+deb7u1
ii  iproute1:3.15.0-2~bpo70+1
ii  libc6  2.13-38+deb7u3
ii  liblzo2-2  2.06-1+deb7u1
ii  libpam0g   1.1.3-7.1
ii  libpkcs11-helper1  1.09-1
ii  libssl1.0.01.0.1e-2+deb7u12

Versions of packages openvpn recommends:
pn  easy-rsa  

Versions of packages openvpn suggests:
ii  openssl 1.0.1e-2+deb7u12
pn  resolvconf  

-- debconf information excluded


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

Bug#758163: Subject: RFS: kcm-ufw/0.4.3-1 ITP

[Shawn Sörbom]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package "kcm-ufw"

* Package name: kcm-ufw
  Version : 0.4.3-1
* Upstream Author : Craig Drummond 
  URL : 
http://kde-apps.org/content/show.php/UFW+KControl+Module?content=137789
* License : GPL-3
  Section : KDE

It builds those binary packages:

kcm-ufw- A KDE Control Center module for the Uncomplicated Firewall

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

  http://mentors.debian.net/package/kcm-ufw


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

dget -x 
http://mentors.debian.net/debian/pool/main/k/kcm-ufw/kcm-ufw_0.4.3-1.dsc

  More information about hello can be obtained from 
http://kde-apps.org/content/show.php/UFW+KControl+Module?content=137789.

  Changes since the last upload:

  remove templates, fix some lintian errors.


  Regards,
   Shawn Sörbom


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

Bug#758145: installation-reports: Missing dbus; logind service fails

[Brian Potkin]

merge 758111
thanks



On Thu 14 Aug 2014 at 15:05:30 -0400, Mel Davis wrote:

> What led to situation...
> Fresh install of OS on new SD card. Basic default installation. No custom 
> drivers. No errors or problems reported during the install. 
> 
> Booting into OS reported the following error: 
> "Failed to start Login Service".
> 
> What I did that was effective...
> Running "systemctl status systemd-login.service -l" indicated that it 
> failed to find the dbus.socket.
> 
> Installed dbus via apt-get.   
> Rebooted. Problem solved.

Doesn't seem much different from #758111, so merging.


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

Bug#758162: python-powerline: Zsh plugin doesn't work at all: ERROR:shell:powerline:Failed to render: coercing to Unicode: need string or buffer, instancemethod found

[Axel Beckert]

Package: python-powerline
Version: 0~20140216-1

Dear Maintainer,

I tried to follow the instructions on
https://powerline.readthedocs.org/en/latest/usage/shell-prompts.html#zsh-prompt

To test powerline before adding it to my .zshrc, I sourced
/usr/share/pyshared/powerline/bindings/zsh/powerline.zsh in a running
zsh. What I always got instead of the prompt is the following python
traceback, even with a completely unconfigured zsh:

~ → exec zsh -f
nemo2% . /usr/share/pyshared/powerline/bindings/zsh/powerline.zsh
2014-08-14 23:40:36,841:ERROR:shell:powerline:Failed to render: coercing to 
Unicode: need string or buffer, instancemethod found
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/powerline/__init__.py", line 435, in 
render
return self.renderer.render(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/powerline/renderers/zsh_prompt.py", 
line 38, in render
*args, **kwargs
  File "/usr/lib/python2.7/dist-packages/powerline/renderer.py", line 208, in 
render
segments = [self._get_highlighting(segment, mode) for segment in segments
  File "/usr/lib/python2.7/dist-packages/powerline/theme.py", line 120, in 
get_segments
segment['contents'] = segment['before'] + u(segment['contents'] if 
segment['contents'] is not None else '') + segment['after']
  File "/usr/lib/python2.7/dist-packages/powerline/lib/unicode.py", line 13, in 
u
return unicode(s, 'utf-8')
TypeError: coercing to Unicode: need string or buffer, instancemethod found
coercing to Unicode: need string or buffer, instancemethod found

My terminal is an uxterm with the following additional characteristics:

TERM=xterm-256color
COLORTERM=yes
LANG=en_DK.UTF-8
LANGUAGE=en_GB:en

The above happened with uxterm from Wheezy and zsh running on Sid via
SSH.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (900, 'testing'), (899, 
'testing-proposed-updates'), (600, 'stable'), (500, 'proposed-updates'), (200, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.15-trunk-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-powerline depends on:
ii  python-psutil  2.1.1-1+b1
pn  python:any 

python-powerline recommends no packages.

Versions of packages python-powerline suggests:
pn  python-powerline-doc  

-- 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#758161: FTBFS with clang instead of gcc

[Alexander]

Source: freedroidrpg
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs

Hello,

Using the rebuild infrastructure, your package fails to build with clang 
(instead of gcc).

We detected this kinf of error:
http://clang.debian.net/status.php?version=3.5.0rc1&key=NOT_ALLOWED_HERE

Full build log is available here:
http://clang.debian.net/logs/2014-08-05/freedroidrpg_0.15.1-1_unstable_clang.log

Thanks,
Alexander

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

Kernel: Linux 3.2.0-4-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
--- ./src/quest_browser_ui.c	2012-03-16 17:42:18.0 +0400
+++ ../freedroidrpg-0.15.1-my/./src/quest_browser_ui.c	2014-08-15 01:33:37.900056646 +0400
@@ -534,6 +534,12 @@
 	draw_rectangle(&w->rect, 0, 0, 0, 150);
 }
 
+WIDGET_UPDATE_FLAG_ON_DATA(open_quests, WIDGET_BUTTON, active, current_quest_browser_mode == QUEST_BROWSER_SHOW_OPEN_MISSIONS)
+WIDGET_UPDATE_FLAG_ON_DATA(done_quests, WIDGET_BUTTON, active, current_quest_browser_mode == QUEST_BROWSER_SHOW_DONE_MISSIONS)
+WIDGET_UPDATE_FLAG_ON_DATA(notes, WIDGET_BUTTON, active, current_quest_browser_mode == QUEST_BROWSER_SHOW_NOTES)
+WIDGET_UPDATE_FLAG_ON_DATA(scroll_up, WIDGET_BUTTON, active, can_scroll_up())
+WIDGET_UPDATE_FLAG_ON_DATA(scroll_down, WIDGET_BUTTON, active, can_scroll_down())
+
 /**
  * This function returns the quest log top level widget and creates it if necessary.
  */
@@ -606,21 +612,21 @@
 			{"widgets/quest_open_off.png", NULL, "widgets/quest_open.png"},
 			{right_side_buttons_x, quest_browser_y + 37, 126, 29},
 			toggle_open_quests,
-			WIDGET_UPDATE_FLAG_ON_DATA(WIDGET_BUTTON, active, current_quest_browser_mode == QUEST_BROWSER_SHOW_OPEN_MISSIONS)
+anonymous_func_open_quests,
 		},
 		// Done quests
 		{
 			{"widgets/quest_done_off.png", NULL, "widgets/quest_done.png"},
 			{right_side_buttons_x, quest_browser_y + 76, 126, 29},
 			toggle_done_quests,
-			WIDGET_UPDATE_FLAG_ON_DATA(WIDGET_BUTTON, active, current_quest_browser_mode == QUEST_BROWSER_SHOW_DONE_MISSIONS)
+anonymous_func_done_quests,
 		},
 		// Notes
 		{
 			{"widgets/quest_notes_off.png", NULL, "widgets/quest_notes.png"},
 			{right_side_buttons_x, quest_browser_y + 115, 126, 29},
 			toggle_notes,
-			WIDGET_UPDATE_FLAG_ON_DATA(WIDGET_BUTTON, active, current_quest_browser_mode == QUEST_BROWSER_SHOW_NOTES)
+anonymous_func_notes,
 		},
 		// Exit button
 		{
@@ -634,14 +640,14 @@
 			{"widgets/scroll_up_off.png", NULL, "widgets/scroll_up.png"},
 			{quest_browser_x + quest_browser_w / 2 - 59, quest_browser_y - 14, 118, 17},
 			scroll_up,
-			WIDGET_UPDATE_FLAG_ON_DATA(WIDGET_BUTTON, active, can_scroll_up())
+anonymous_func_scroll_up,
 		},
 		// Scroll down
 		{
 			{"widgets/scroll_down_off.png", NULL, "widgets/scroll_down.png"},
 			{quest_browser_x + quest_browser_w / 2 - 59, quest_browser_y + quest_browser_h, 118, 17}, 
 			scroll_down,
-			WIDGET_UPDATE_FLAG_ON_DATA(WIDGET_BUTTON, active, can_scroll_down())
+anonymous_func_scroll_down,
 		}
 	};
 
--- ./src/game_ui.c	2012-03-16 17:42:18.0 +0400
+++ ../freedroidrpg-0.15.1-my/./src/game_ui.c	2014-08-15 01:43:47.097224088 +0400
@@ -377,6 +377,9 @@
 	}
 }
 
+WIDGET_UPDATE_FLAG_ON_DATA(log_button, WIDGET_BUTTON, active, Me.quest_browser_changed)
+WIDGET_UPDATE_FLAG_ON_DATA(character_button, WIDGET_BUTTON, active,(Me.points_to_distribute > 0))
+
 /**
  * This function builds the hud bar widgets.
  */
@@ -471,7 +474,7 @@
 			NULL,
 			(void *)toggle_quest_browser,
 			NULL,
-			WIDGET_UPDATE_FLAG_ON_DATA(WIDGET_BUTTON, active, Me.quest_browser_changed)
+anonymous_func_log_button,
 		},
 		// Inventory button
 		{
@@ -491,7 +494,7 @@
 			NULL,
 			toggle_character_screen,
 			NULL,
-			WIDGET_UPDATE_FLAG_ON_DATA(WIDGET_BUTTON, active,(Me.points_to_distribute > 0))
+anonymous_func_character_button,
 		},
 		// Skill button
 		{
@@ -584,6 +587,14 @@
 	return hud_bar;
 }
 
+WIDGET_UPDATE_FLAG_ON_DATA(first, WIDGET, enabled, GameConfig.skill_explanation_screen_visible)
+WIDGET_UPDATE_FLAG_ON_DATA(second, WIDGET, enabled, GameConfig.CharacterScreen_Visible)
+WIDGET_UPDATE_FLAG_ON_DATA(third, WIDGET, enabled, GameConfig.SkillScreen_Visible)
+WIDGET_UPDATE_FLAG_ON_DATA(fourth, WIDGET, enabled, (addon_crafting_ui_visible() || item_upgrade_ui_visible()))
+WIDGET_UPDATE_FLAG_ON_DATA(fifth, WIDGET, enabled, addon_crafting_ui_visible())
+WIDGET_UPDATE_FLAG_ON_DATA(sixth, WIDGET, enabled, item_upgrade_ui_visible())
+WIDGET_UPDATE_FLAG_ON_DATA(seventh, WIDGET, enabled, GameConfig.Inventory_Visible)
+WIDGET_UPDATE_FLAG_ON_DATA(create_quest_browser, WIDGET, enabled, quest_browser_activated);
 /**
  * This function returns the game top level widget and creates it if n

Bug#434599: [PATCH/RFC] git-imap-send: use libcurl for implementation

[Bernhard Reiter]

Use libcurl's high-level API functions to implement git-imap-send
instead of the previous low-level OpenSSL-based functions.

Since version 7.30.0, libcurl's API has been able to communicate with
IMAP servers. Using those high-level functions instead of the current
ones would reduce imap-send.c by some 1200 lines of code. For now,
the old ones are wrapped in #ifdefs, and the new functions are enabled
by make if curl's version is >= 7.35.0, from which version on curl's
CURLOPT_LOGIN_OPTIONS (enabling IMAP authentication) parameter has been
available.

As I don't have access to that many IMAP servers, I haven't been able to
test the new code with a wide variety of parameter combinations. I did
test both secure and insecure (imaps:// and imap://) connections and
values of "PLAIN" and "LOGIN" for the authMethod.

Signed-off-by: Bernhard Reiter 
---
Am 2014-08-13 um 03:59 schrieb Jonathan Nieder:
> Bernhard Reiter wrote:
>> [...]
>
> Wow!  This sounds lovely.  Thanks for working on this.

Well thanks for the friendly welcome and the helpful comments!

I'm attaching a patch where I've applied the fixes you suggested, plus:

* I added the lf_to_crlf conversion to the curl codepath as
communication with another IMAP server I tried was broken without it.

* I added STARTTLS. (That's just the
curl_easy_setopt(curl, CURLOPT_USE_SSL, (long)CURLUSESSL_ALL);
line)

* I tested (and fixed) authentication, i.e. the auth_method stuff. As
the corresponding CURLOPT_LOGIN_OPTIONS flag has only been available
starting with curl 7.35.0, I've bumped the required version to that.
(Apparently it was possible to achieve the same effect with a different
option in between versions 7.31.0 and 7.34.0 [1], but I haven't found
yet how. Is it worth the effort?)

* I made that file scope imap_folder a member of struct imap_server_conf
(named folder), which makes some things easier.

>> @@ -1417,31 +269,89 @@ int main(int argc, char **argv)
>>  return 1;
>>  }
>>
>> +curl_global_init(CURL_GLOBAL_ALL);
>
> http.c seems to make the same mistake,

Patch at http://permalink.gmane.org/gmane.comp.version-control.git/255221

> [...]
>> +if (server.tunnel) {
>> +const char *argv[] = { server.tunnel, NULL };
>> +struct child_process tunnel = {NULL};
>
> (not about this patch) Could use the child_proccess's internal
> argv_array:
>
>   struct child_process tunnel = {NULL};
>   argv_array_push(&tunnel.args, server.tunnel);

Patch at
http://permalink.gmane.org/gmane.comp.version-control.git/255220 (The
patch attached to this mail depends on that one.)

No comments on those patches yet, though.

> (about this patch) Would there be a way to make this part reuse the
> existing code?  The only difference I see is that *srvc has been
> renamed to server, which doesn't seem to be related to the change of
> transport API from OpenSSL to libcurl.
>
> [...]
>> +curl_socket_t sockfd = tunnel.out; // what about tunnel.in ?
>
> Hmm.  curl expects to get a socket it can send(), recv(), setsockopt(),
> etc on instead of a pair of fds to read() and write().
>
> I wonder why someone would want to use SSL through a tunnel, though.
> Currently it's impossible to get to the SSL codepath when a tunnel
> is active (it's in the 'else' block an 'if (srvc->tunnel)').  If that
> property is preserved, then we should be safe.

Now this turns out to be the one major annoyance left, because we only
have those two fds (actually pipes, right?), and not a socket that we
could pass to curl, so we can't use it to talk to the IMAP server. So if
the tunnel parameter is set, we're stuck with the old hand-written IMAP
handling routines, even with USE_CURL_FOR_IMAP set, meaning I can't wrap
as much in #ifdef...#endif blocks as I'd like. :-( BTW, due to two of
the blocks that I do add I get a compiler warning about the curl handle
remaining possibly unitialized :-/
I've removed the curl specific socket handling routines, as we can't use
them anyway for now.

I've asked about passing two pipes instead of a socket to curl on their
ML [1] as this has even been discussed before [2], but unfortunately,
there doesn't seem to be a solution as of yet. I've also asked on SO
[3], but no answers yet.

> To summarize:
> [...]
>
>  * As soon as you're ready to roll this out to a wider audience of
>testers, let me know, and we can try to get it into shape for
>Junio's "next" branch (and hence Debian experimental).

Is this one good enough already?

Bernhard

[1] http://sourceforge.net/p/curl/bugs/1372/
[2] http://curl.haxx.se/mail/lib-2014-08/0102.html
[3] http://curl.haxx.se/mail/lib-2011-05/0102.html
[4]
http://stackoverflow.com/questions/25306264/connect-in-and-out-pipes-to-network-socket

 Documentation/git-imap-send.txt |   3 +-
 INSTALL |  15 +++---
 Makefile|  16 +-
 git.spec.in |   5 +-
 imap-send.c | 109
++

Bug#758086: CVE-2012-6153: Apache HttpComponents client: Hostname verification susceptible to MITM attack

[Emmanuel Bourg]

Hi Henri,

Thank you for the report.

Is there an example available somewhere of a subject improperly parsed
by commons-httpclient/3.1-10.2? This would help backporting the fix to
this version.

Emmanuel Bourg



signature.asc
Description: OpenPGP digital signature

Bug#758160: gcc-4.9: Please don't run testsuite on sh4

[John Paul Adrian Glaubitz]

Package: src:gcc-4.9
Version: 4.9.1-5
Severity: normal

Hello!

Like m68k, our buildds for the sh4 architecture are rather underpowered
and complex source packages may take very long to build.

I am currently building gcc-4.9 manually on one of the sh4 builds which
has been going on for more than a week now, mainly due the testsuite
runs taking very long to finish. Coincidentally I saw gcc-4.9 building
on one of the m68k buildds I am hosting and noticed that the testsuite
isn't run on m68k at all, dramatically reducing the build time.

Thus, I would like to ask to have the testsuite disabled on sh4 as
well in order to avoid build delays for gcc packages on this architecture
in the future.

According to Thorsten Glaser, the necessary changes involve setting the
Build-Dependency dejagnu to [!sh4] in debian/control and adding
check_no_cpus := sh4 to debian/rules.defs, but I assume you know much
better.

I would be great to have this changed soon!

Thanks,
Adrian


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

Bug#737395: Emacs Funny Manpages Copyright

[Riley Baird]

> I believe Debian rules provide for an exception for some sorts of
> files that serve no functional purpose.  I don't remember the details,
> but I suggest you take a look.

I'm not sure, but afaik, they don't (that's why there was the whole GFDL
issue a while ago).

> Anyway, it isn't my problem, it's Debian's problem.  It's GNU Project
> policy to follow our own license policy, rather than the policy of
> some other project, especially a project that distributes nonfree
> software.

Okay, but as it stands, there is not even the right to distribute. If I
buy a copy of emacs and then give a copy to my friend, you could sue me
over the manpages, saying that I should have removed them before making
the copy.

Also, you've previously stated that you think that copyright should be
limited to 10 years. You wrote the manpages more than 10 years ago, so
by your standard, they should be free now.


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

Bug#758157: systemd make shutdown hang at “Stopped Getty on tty1”

[Michael Biebl]

Am 14.08.2014 23:30, schrieb M G Berberich:
> Package: systemd
> Version: 208-6
> Severity: normal
> 
> Dear Maintainer,
> 
> since systemd has been installed instead of sysvinit, shutdown does no
> longer work. it stops at “Stopped Getty on tty1” and the system does
> not power down.

What exact command did you use to shutdown the system?
Did you wait at least 90 secs?

Michael


-- 
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#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

[Paul Eggert]

Vincent Lefevre wrote:

On input, using null bytes may be better if one wants to be able to
match real replacement characters without false positives.


Maybe, though this is no place to get fancy.  It's simple to tell users 
"an invalid byte acts like '?'".  Simple is good.


Anyway, this is a matter for the implementing volunteer to decide, 
whoever that happens to be.



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

Bug#758158: Alx AR8161 - ifdown eth - hard crash

[T]

Package: linux-image-3.2.0-4-amd64
Version: 3.2.57-3+deb7u2

Mainboard: Gigabyte Z77X-D3H
07:00.0 Ethernet controller: Atheros Communications Inc. AR8161 Gigabit
Ethernet (rev 10)

The interface stopped  working(frequent disconnects, and finally no dhcp to
my laptop)
Command: ifdown eth1 crashed the entire server(auto reboot)

Below relevant information.

But this line explains everything:
Aug 14 21:43:03 wheezy kernel: [7.104842] alx: module is from the
staging directory, the quality is unknown, you have been warned.


Aug 14 21:44:38 wheezy kernel: [7937009.592436] ADDRCONF(NETDEV_UP): eth1:
link is not ready
Aug 14 21:44:38 wheezy kernel: [7937009.594091] ADDRCONF(NETDEV_CHANGE):
eth1: link becomes ready
Aug 14 21:44:38 wheezy kernel: [7937009.726247] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:39 wheezy kernel: [7937009.860467] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:39 wheezy kernel: [7937009.994634] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:39 wheezy kernel: [7937010.128886] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:39 wheezy kernel: [7937010.263073] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:39 wheezy kernel: [7937010.397328] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:39 wheezy kernel: [7937010.531504] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:39 wheezy kernel: [7937010.665710] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:39 wheezy kernel: [7937010.799936] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:40 wheezy kernel: [7937010.934108] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:40 wheezy kernel: [7937011.068379] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:40 wheezy kernel: [7937011.202533] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:40 wheezy kernel: [7937011.336795] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:40 wheezy kernel: [7937011.470995] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:40 wheezy kernel: [7937011.605212] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:40 wheezy kernel: [7937011.739382] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:41 wheezy kernel: [7937011.873612] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:41 wheezy kernel: [7937012.007794] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:41 wheezy kernel: [7937012.142028] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:41 wheezy kernel: [7937012.276232] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:41 wheezy kernel: [7937012.410433] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:41 wheezy kernel: [7937012.544678] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:41 wheezy kernel: [7937012.678881] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:41 wheezy kernel: [7937012.813068] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:42 wheezy kernel: [7937012.947262] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:42 wheezy kernel: [7937013.081468] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:42 wheezy kernel: [7937013.215708] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:42 wheezy kernel: [7937013.349935] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:42 wheezy kernel: [7937013.484139] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:42 wheezy kernel: [7937013.618368] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:42 wheezy kernel: [7937013.752569] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:43 wheezy kernel: [7937013.886767] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:43 wheezy kernel: [7937014.021028] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:43 wheezy kernel: [7937014.155165] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:43 wheezy kernel: [7937014.289387] alx :07:00.0: eth1:
error when reset mac
Aug 14 21:44:43 wheezy kernel: [7937014.423621]Aug 14 21:43:03 wheezy
kernel: imklog 5.8.11, log source = /proc/kmsg started.
Aug 14 21:43:03 wheezy kernel: [0.00] Initializing cgroup subsys
cpuset
Aug 14 21:43:03 wheezy kernel: [0.00] Initializing cgroup subsys cpu

Bug#758088: pspp failed to run test on mips64el

[Friedrich Beckmann]

Dear YunQiang Su,

you are refering to version 0.7.9. It might be that the problem you report is 
the same as 
that one described here:

http://savannah.gnu.org/patch/index.php?8508

The patch has been introduced in upstream pspp here:

http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=9f3aceccf7a1f7c08312be6cb34aa688bd958677

Regards

Friedrich 

Am 14.08.2014 um 09:41 schrieb YunQiang Su :

> Package: pspp
> Version: 0.7.9+git20120620-1.2
> 
> --- -   2033-12-08 08:27:16.958411009 +0800
> +++ /tmp/pspp/pspp-0.7.9+git20120620/tests/testsuite.dir/at-groups/951/stdout
>  2033-12-08 08:27:16.940752178 +0800
> @@ -1,15 +1,15 @@
> Variable 0 is "string", label is "A Short String Variable"
> Value Labels:
>  => threes
> - => ones
>  => twos
> + => ones
> Variable 1 is "longstring", label is "A Long String Variable"
> Value Labels:
> Variable 2 is "numeric", label is "A Numeric Variable"
> Value Labels:
> 1 => Unity
> -3 => Thripality
> 2 => Duality
> +3 => Thripality
> Variable 3 is "date", label is "A Date Variable"
> Value Labels:
> Variable 4 is "dollar", label is "A Dollar Variable"
> 951. perl-module.at:335: 951. Perl read system file
> (perl-module.at:335): FAILED (perl-module.at:370)
> 
> # -*- compilation -*-
> 957. perl-module.at:703: testing Perl Pspp.t ...
> ./perl-module.at:706: perl -MText::Diff -e '' || exit 77
> ./perl-module.at:707: LD_LIBRARY_PATH=$abs_top_builddir/src/.libs \
>   DYLD_LIBRARY_PATH=$abs_top_builddir/src/.libs \
>   $PERL -I$abs_top_builddir/perl-module/blib/arch \
> -I$abs_top_builddir/perl-module/blib/lib
> $abs_top_builddir/perl-module/t/Pspp.t
> 
> 
> --- -   2033-12-08 08:27:26.272479944 +0800
> +++ /tmp/pspp/pspp-0.7.9+git20120620/tests/testsuite.dir/at-groups/957/stdout
>  2033-12-08 08:27:26.257159156 +0800
> @@ -23,7 +23,7 @@
> ok 22 - Value label for long string
> ok 23 - Check output 2
> ok 24 - Dictionary survives sysfile
> -ok 25 - Basic reader operation
> +not ok 25 - Basic reader operation
> ok 26 - Streaming of files
> Formatted string is "11-SEP-2001 08:20"
> ok 27 - format_value function
> @@ -35,6 +35,6 @@
> ok 33 - Missing Value Positive
> ok 34 - Missing Value Positive SYS
> ok 35 - Missing Value Positive Num
> -ok 36 - Custom Attributes
> +not ok 36 - Custom Attributes
> ok 37 - Case count
> 
> 
> 
> -- 
> YunQiang Su
> 

Bug#758156: ITP: maven-replacer-plugin

[Timo Aaltonen]

Package: wnpp
Severity: wishlist

Package name: maven-replacer-plugin
Version : 1.5.3
Upstream Author : Steven Baker
URL : https://code.google.com/p/maven-replacer-plugin/
License : MIT
Programming Lang: java
Description : Maven plugin to replace tokens in a given file with a value

This plugin is typically used to change database or network configuration 
within a
project during a maven build. It also can perform some advanced text replacement
functions, such as providing a separate token/value file to keep your build 
script
concise, writing resulting text after replacement to a separate file and token
matching with regular expressions. There is even support for making exact 
document
node replacements via X-Path.


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

Bug#758155: freerdp: FTFBFS allmost everywhere

[Sebastian Ramacher]

Source: freerdp
Version: 1.1.0~git20140809.1.b07a5c1+dfsg-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

freerdp failed to build everwhere except for amd64, i386 and
kfreebsd-i386. On armhf it failed with
| cd 
"/«BUILDDIR»/freerdp-1.1.0~git20140809.1.b07a5c1+dfsg/obj-arm-linux-gnueabihf/libfreerdp/primitives"
 && /usr/bin/cc  -DCMAKE_BUILD_TYPE=None -DHAVE_CONFIG_H 
-Dfreerdp_primitives_EXPORTS -g -O2 -fstack-protector --param=ssp-buffer-size=4 
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2  -Wall -Wno-unused-result 
-Wno-unused-but-set-variable -Wno-deprecated-declarations -g -DWINPR_EXPORTS 
-DFREERDP_EXPORTS -fPIC 
-I"/«BUILDDIR»/freerdp-1.1.0~git20140809.1.b07a5c1+dfsg/obj-arm-linux-gnueabihf"
 
-I"/«BUILDDIR»/freerdp-1.1.0~git20140809.1.b07a5c1+dfsg/obj-arm-linux-gnueabihf/include"
 -I"/«BUILDDIR»/freerdp-1.1.0~git20140809.1.b07a5c1+dfsg/include" 
-I"/«BUILDDIR»/freerdp-1.1.0~git20140809.1.b07a5c1+dfsg/winpr/include" 
-I"/«BUILDDIR»/freerdp-1.1.0~git20140809.1.b07a5c1+dfsg/obj-arm-linux-gnueabihf/winpr/include"
 -mfpu=neon -mfloat-abi=softfp -o 
CMakeFiles/freerdp-primitives.dir/prim_add_opt.c.o   -c 
"/«BUILDDIR»/freerdp-1.1.0~git20140809.1.b07a5c1+dfsg/libfreerdp/primitives/prim_add_opt.c"
| In file included from /usr/include/features.h:398:0,
|  from /usr/include/wchar.h:27,
|  from 
/«BUILDDIR»/freerdp-1.1.0~git20140809.1.b07a5c1+dfsg/winpr/include/winpr/wtypes.h:26,
|  from 
/«BUILDDIR»/freerdp-1.1.0~git20140809.1.b07a5c1+dfsg/include/freerdp/types.h:24,
|  from 
/«BUILDDIR»/freerdp-1.1.0~git20140809.1.b07a5c1+dfsg/libfreerdp/primitives/prim_add_opt.c:21:
| /usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:29: fatal error: 
gnu/stubs-soft.h: No such file or directory
|  # include 
|  ^
| compilation terminated.
| make[3]: *** 
[libfreerdp/primitives/CMakeFiles/freerdp-primitives.dir/prim_add_opt.c.o] 
Error 1

On other architectures it failed with symbol errors. armel:
| --- debian/libfreerdp1.symbols 
(libfreerdp1_1.1.0~git20140809.1.b07a5c1+dfsg-2_armel)
| +++ dpkg-gensymbolsMX0zDO 2014-08-11 23:30:57.059574519 +
| @@ -328,7 +328,7 @@
|   nsc_context_new@Base 1.1.0~beta1+git20130629
|   nsc_context_set_pixel_format@Base 1.1.0~beta1+git20130629
|   nsc_encode@Base 1.1.0~beta1+git20130629
| - (arch=!ppc64el)nsc_init_sse2@Base 1.1.0~beta1+git20130629
| +#MISSING: 1.1.0~git20140809.1.b07a5c1+dfsg-2# 
(arch=!ppc64el)nsc_init_sse2@Base 1.1.0~beta1+git20130629
|   nsc_process_message@Base 1.1.0~beta1+git20130629
|   rdpsnd_compute_audio_time_length@Base 1.1.0~beta1+git20130629
|   rdpsnd_free_audio_formats@Base 1.1.0~beta1+git20130629
| @@ -347,9 +347,11 @@
|   rfx_differential_decode@Base 1.1.0~beta1+git20130629
|   rfx_differential_encode@Base 1.1.0~beta1+git20130629
|   rfx_dwt_2d_decode@Base 1.1.0~beta1+git20130629
| + rfx_dwt_2d_decode_NEON@Base 1.1.0~git20140809.1.b07a5c1+dfsg-2
|   rfx_dwt_2d_encode@Base 1.1.0~beta1+git20130629
|   rfx_encode_rgb@Base 1.1.0~beta1+git20130629
| - (arch=!ppc64el)rfx_init_sse2@Base 1.1.0~beta1+git20130629
| + rfx_init_neon@Base 1.1.0~git20140809.1.b07a5c1+dfsg-2
| +#MISSING: 1.1.0~git20140809.1.b07a5c1+dfsg-2# 
(arch=!ppc64el)rfx_init_sse2@Base 1.1.0~beta1+git20130629
|   rfx_message_free@Base 1.1.0~beta1+git20130629
|   rfx_message_get_rect@Base 1.1.0~beta1+git20130629
|   rfx_message_get_rect_count@Base 1.1.0~beta1+git20130629
| @@ -358,6 +360,7 @@
|   rfx_process_message@Base 1.1.0~beta1+git20130629
|   rfx_process_message_tile_work_callback@Base 1.1.0~beta1+git20130629
|   rfx_quantization_decode@Base 1.1.0~beta1+git20130629
| + rfx_quantization_decode_NEON@Base 1.1.0~git20140809.1.b07a5c1+dfsg-2
|   rfx_quantization_encode@Base 1.1.0~beta1+git20130629
|   rfx_rlgr_decode@Base 1.1.0~beta1+git20130629
|   rfx_rlgr_encode@Base 1.1.0~beta1+git20130629
| @@ -1751,6 +1754,7 @@
|   general_sign_16s@Base 1.1.0~beta1+git20130629
|   general_yCbCrToRGB_16s16s_P3P3@Base 1.1.0~beta1+git20130629
|   general_zero@Base 1.1.0~beta1+git20130629
| + neon_yCbCrToRGB_16s16s_P3P3@Base 1.1.0~git20140809.1.b07a5c1+dfsg-2
|   primitives_deinit@Base 1.1.0~beta1+git20130629
|   primitives_deinit_add@Base 1.1.0~beta1+git20130629
|   primitives_deinit_alphaComp@Base 1.1.0~beta1+git20130629
| @@ -1777,21 +1781,21 @@
|   primitives_init_shift_opt@Base 1.1.0~beta1+git20130629
|   primitives_init_sign@Base 1.1.0~beta1+git20130629
|   primitives_init_sign_opt@Base 1.1.0~beta1+git20130629
| - (arch=!ppc64el)sse2_RGBToRGB_16s8u_P3AC4R@Base 1.1.0~beta1+git20130629
| - (arch=!ppc64el)sse2_RGBToYCbCr_16s16s_P3P3@Base 1.1.0~beta1+git20130629
| - (arch=!ppc64el)sse2_alphaComp_argb@Base 1.1.0~beta1+git20130629
| - (arch=!ppc64el)sse2_lShiftC_16s@Base 1.1.0~beta1+git20130629
| - (arch=!ppc64el)sse2_lShiftC_16u@Base 1.1.0~beta1+git20130629
| - (arch=!ppc64el)sse2_rShiftC_16s@Base 1.1.0~beta1+git20130629
| - (arch=!ppc64el)sse2_rShiftC_16u@Bas

Bug#757740: libkeyutils1: Cannot allocate memory while decompressing [mips]

[Christian Kastner]

Hi Guillem,

On 2014-08-13 12:54, Guillem Jover wrote:
> On Mon, 2014-08-11 at 23:19:45 +0200, Christian Kastner wrote:
>> On 2014-08-11 22:05, Guillem Jover wrote:
>>> This is rather unwise, for no apparent reason. The -z9 seems to be a
>>> common pattern in most (if not all) of Daniel's packages, and I think
>>> should be reverted, if absent of a good rationale.
>>
>> Oh, I forgot that this is still present in wheezy's version. I already
>> removed it in unstable.
>>
 Anyhoo, reassigning to dpkg in case the have seen something similar before.
>>>
>>> Reassigning back, this would need fixing in a stable release.
>>
>> I'm a bit confused - could you elaborate on what you mean by that?
> 
> Given that the -z9 setting makes the package unextractable on some
> systems (which from my PoV makes it an RC bug) and is Priority:standard,
> which means it will be pulled in on most systems, IMO it deserves to be
> fixed in the affected Debian release, which in this case is stable
> (wheezy). Hope that clarifies?

Yes, thanks. My mistake was to conclude that there was no use case for this.

A fix in stable would probably have no effect on a system already
running stable, as that would imply that unpacking of the current -z9
version had already succeeded. What I didn't think of were the use cases
of upgrading from oldstable, and new installations.

>>> But given that this is a Priority:standard package, I'd say it makes
>>> sense to do so.

Thanks,
Christian


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

Bug#757329: apt-dater: Multi-Arch updates are not detected

[Thomas Liske]

tags 757329 fixed-upstream

thanks


Hi Patrick,

On 08/07/2014 10:25 AM, Patrick Matthäi wrote:

If you are e.g. on amd64 and also have installed i386 multiarch libs, apt-dater
does not detect and install updates for it.


upgrading works but foreign arch upgrades were discarded within the 
package status listing. I've patched it upstream by appending the 
foreign arch as usual.



Thx & HTH,
Thomas

--
supp...@ibh.de  Tel. +49 351 477 77 30
www.ibh.de  Fax  +49 351 477 77 39

---
Dipl.-Ing. Thomas Liske
Netzwerk- und System-Design


IBH IT-Service GmbH Amtsgericht Dresden
Gostritzer Str. 67a HRB 13626
D-01217 Dresden GF: Prof. Dr. Thomas Horn
Germany VAT DE182302907
---
Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV
---
   professioneller IT-Service - kompetent und zuverlässig
---


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

Bug#754120: ITP: python-gnupg-ng -- A Python wrapper for GnuPG

[micah anderson]

> Why exactly should shell=True be necessary?

It turns out that shell=True (basically what started the fork) is not
needed now. Vinay changed it in the latest release of the "original"
python gnupg, which came after a bunch of CVEs and some comments in this
thread as a result of python-gnupg-ng:
http://seclists.org/oss-sec/2014/q1/303

The original reason for doing shell=True is/was commented on
python-gnupg (original) code: without that, it didn't work in windows.

So while it is true that Shell=True is not needed, python-gnupg-ng has
other advantages: its more community based (it has a bugtracker and
public repo, to begin with), the code has diverged from the original a
bit in adding various gnupg functionality to the module, re-reading of
the original having security and documentation in minde and improving
the overall code quality. 

I'd argue that including this in Debian is a win because this one has:

 * Better gnupg options parsing
 * Better code structure.
 * Better documentation.
 * Open repo and bugtracker.

Also - we have a package ready to upload for it.


pgp61lMNubroM.pgp
Description: PGP signature

Bug#758105: bug#18266: grep -P and invalid exits with error

[Vincent Lefevre]

On 2014-08-14 13:13:45 -0700, Paul Eggert wrote:
> Vincent Lefevre wrote:
> >The problem with this solution is that it would change the length
> >of the text, while replacing invalid bytes by zero bytes could be
> >done in place (if allowed), with very little change of the code,
> >I think.
> 
> True. Though it might be more user-friendly to use '?' as the
> replacement byte.

On output, yes (though in most cases, non-printable characters are
probably seen as garbage and don't really matter); and when the lines
are not printed, this doesn't matter.

On input, using null bytes may be better if one wants to be able to
match real replacement characters without false positives. Matching
null bytes is not common, AFAIK.

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


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

Bug#758154: ITP: jackson-module-jaxb-annotations

[Timo Aaltonen]

Package: wnpp
Severity: wishlist

Package name: jackson-module-jaxb-annotations
Version : 2.4.1
Upstream Author : Tatu Saloranta
URL : http://wiki.fasterxml.com/JacksonJAXBAnnotations
License : MIT
Programming Lang: java
Description : Fast and powerful JSON library for Java -- JAXB annotations

This Jackson extension module provides support for using JAXB (javax.xml.bind) 
annotations as an alternative to native Jackson annotations. It is most often 
used 
to make it easier to reuse existing data beans that used with JAXB framework to 
read 
and write XML.


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

Bug#758100: perl: adopt versioned provides

[Niko Tyni]

block 758100 with 758153
thanks

On Thu, Aug 14, 2014 at 12:10:34PM +0200, Ansgar Burchardt wrote:
> On 08/14/2014 11:18, Niko Tyni wrote:
> > dpkg (1.17.11) unstable; urgency=low
> > [...]
> > * Add versioned Provides support:

> > Assuming dpkg in wheezy already accepts the versioned provides when
> > parsing, I suppose we could put them in the perl package straight away
> > and start cleaning the dependencies after jessie.
> 
> Does APT support this already?

Heh, judging by the changelog it probably doesn't. 
I've filed #758153 about that.

I suppose I got a bit carried away in my excitement. Thanks for the
reality check.
-- 
Niko Tyni   nt...@debian.org


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

Bug#758127: libwx-perl: FTBFS on arm*

[Damyan Ivanov]

-=| gregor herrmann, 14.08.2014 18:46:12 +0200 |=-
> On Thu, 14 Aug 2014 17:21:03 +0300, Damyan Ivanov wrote:
> 
> > > libwx-perl has test failures on arm{el,hf}:
> > > https://buildd.debian.org/status/logs.php?pkg=libwx-perl&ver=1%3A0.9923-2
> > 
> 
> CPAN RT has something which looks similar:
> https://rt.cpan.org/Public/Bug/Display.html?id=90835
> with no response.
> 
> svn diff svn://svn.code.sf.net/p/wxperl/code/wxPerl/tags/release-0.9923/ 
> svn://svn.code.sf.net/p/wxperl/code/wxPerl/trunk
> shows a new feature but nothing else.
> 
> And I can reproduce the bug in a raspbian jessie armhf cowbuilder chroot :)
> 
> > Oddly, a oneliner passes fine:
> > 
> > $ xvfb-run perl -Iblib/lib -Iblib/arch -we'use strict; use Test::More tests 
> > => 6; BEGIN { use_ok "Wx"; } use Wx "wxYES"; my $x = wxYES; ok(1, "export 
> > ok");'
> > 1..6
> > Xlib:  extension "RANDR" missing on display ":99".
> > ok 1 - use Wx;
> > ok 2 - export ok
> > # Looks like you planned 6 tests but ran 2.
> 
> Same here.
> That's really -- strange. 
> 
> 
> This works:
> 
> … lots of details …
> 
> 
> This is a bit mysterious ...
> 
> 
> Building with DEB_BUILD_OPTIONS=noopt leads to the same result.

Tried on able too, same result. The backtrace is a bit different, 
perhaps die to mission compiler optimizations:

Program received signal SIGSEGV, Segmentation fault.
0xb68e2614 in wxDynamicLibrary::GetLibHandle (this=0x0)
at /usr/include/wx-3.0/wx/dynlib.h:270
270 wxDllType GetLibHandle() const { return m_handle; }
(gdb) bt
#0  0xb68e2614 in wxDynamicLibrary::GetLibHandle (this=0x0)
at /usr/include/wx-3.0/wx/dynlib.h:270
#1  0xb6857824 in XS_Wx__load_plugin (my_perl=0x12008, cv=0x1c3d60) at Wx.c:646
#2  0xb6f1e8b4 in Perl_pp_entersub (my_perl=0x12008) at pp_hot.c:2888
#3  0xb6f170ac in Perl_runops_standard (my_perl=0x12008) at run.c:42
#4  0xb6ea58c0 in Perl_call_sv (my_perl=my_perl@entry=0x12008, sv=0x42baa8, 
sv@entry=0xd, flags=flags@entry=13) at perl.c:2766
#5  0xb6ea76e8 in Perl_call_list (my_perl=0x156c28, my_perl@entry=0x12008, 
oldscope=215644, oldscope@entry=13, paramList=0x12008) at perl.c:4921
#6  0xb6e8b7a8 in S_process_special_blocks (my_perl=my_perl@entry=0x12008, 
floor=175, floor@entry=0, fullname=fullname@entry=0x34a5c "BEGIN", 
gv=gv@entry=0x156c28, cv=cv@entry=0x42baa8) at op.c:7717
#7  0xb6e9eaf4 in Perl_newATTRSUB_flags (my_perl=my_perl@entry=0x12008, 
floor=floor@entry=175, o=o@entry=0x68909c, proto=proto@entry=0x0, 
attrs=0x0, attrs@entry=0x12008, block=0xb6e9f75c , 
block@entry=0xb6ea1ddc , flags=flags@entry=0)
at op.c:7681
#8  0xb6e9f75c in Perl_newATTRSUB (my_perl=my_perl@entry=0x12008, 
floor=floor@entry=175, o=o@entry=0x68909c, proto=proto@entry=0x0, 
attrs=attrs@entry=0x0, block=0x689050) at op.c:7354
#9  0xb6ea1ddc in Perl_utilize (my_perl=my_perl@entry=0x12008, 
aver=, floor=175, version=, idop=0x5007bc, 
arg=) at op.c:5139
#10 0xb6ed1834 in Perl_yyparse (my_perl=my_perl@entry=0x12008, 
gramtype=gramtype@entry=258) at perly.y:397
#11 0xb6f4e398 in S_doeval (my_perl=my_perl@entry=0x12008, gimme=1, 
gimme@entry=0, outside=outside@entry=0xbeffed84, seq=, 
hh=hh@entry=0x0) at pp_ctl.c:3494
#12 0xb6f5a810 in Perl_pp_entereval (my_perl=0x12008) at pp_ctl.c:4205
#13 0xb6f170ac in Perl_runops_standard (my_perl=0x12008) at run.c:42
#14 0xb6ea58c0 in Perl_call_sv (my_perl=my_perl@entry=0x12008, sv=0x39678, 
sv@entry=0x2, flags=flags@entry=13) at perl.c:2766
#15 0xb6ea76e8 in Perl_call_list (my_perl=0x2d610, my_perl@entry=0x12008, 
oldscope=215644, oldscope@entry=2, paramList=0x12008) at perl.c:4921
#16 0xb6e8b7a8 in S_process_special_blocks (my_perl=my_perl@entry=0x12008, 
floor=52, floor@entry=0, fullname=fullname@entry=0x34a5c "BEGIN", 
gv=gv@entry=0x2d610, cv=cv@entry=0x39678) at op.c:7717
#17 0xb6e9eaf4 in Perl_newATTRSUB_flags (my_perl=my_perl@entry=0x12008, 
floor=floor@entry=52, o=o@entry=0x4ff5ac, proto=proto@entry=0x0, 
attrs=0x0, attrs@entry=0x12008, block=0xb6e9f75c , 
block@entry=0xb6ea1ddc , flags=flags@entry=0)
at op.c:7681
#18 0xb6e9f75c in Perl_newATTRSUB (my_perl=my_perl@entry=0x12008, 
floor=floor@entry=52, o=o@entry=0x4ff5ac, proto=proto@entry=0x0, 
attrs=attrs@entry=0x0, block=0x4ff530) at op.c:7354
#19 0xb6ea1ddc in Perl_utilize (my_perl=my_perl@entry=0x12008, 
aver=, floor=52, version=, idop=0x4ff148, 
arg=) at op.c:5139
#20 0xb6ed1834 in Perl_yyparse (my_perl=0x12008, my_perl@entry=0xa, 
gramtype=gramtype@entry=258) at perly.y:397
#21 0xb6eaaf94 in S_parse_body (xsinit=0x1, env=0xb6fcc000, 
my_perl=) at perl.c:2309
#22 perl_parse (my_perl=, xsinit=0x1, argc=, 
argv=, env=env@entry=0x0) at perl.c:1626
#23 0x8aa0 in main (argc=-1090521136, argv=0x8c78 , 
env=0xb6ffed90 <_rtld_global_ro>) at perlmain.c:112

Looks like stack corruption which triggers a segfault in Wx. Hmm.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject

Bug#758153: apt: support for versioned Provides

[Niko Tyni]

Package: apt
Version: 1.0.6
Severity: wishlist

Hi,

dpkg (1.17.11) unstable; urgency=low
[...]
* Add versioned Provides support:
- Add a new dpkg --assert-versioned-provides command.
- Packages can provide a specific version, “virtual (= 1.0)” which will
  be honored, previously it would just be accepted when parsing.   
- Non-versioned virtual packages will not satisfy versioned dependencies.
- Versioned virtual packages will satisfy non-versioned dependencies.
Based on skeletal code by Ben Collins . 
Closes: #7330, #24934, #112131, #134582, #180316

I assume that this is not supported by apt yet, as I didn't find any
mention of it in the changelogs. It would be great if such support could
be added.

We've had to implement a big bunch of workarounds in the perl package
over the years due to the lack of versioned provides and would certainly
switch over as soon as it would be practical.

Thanks for your work on apt,
-- 
Niko Tyni   nt...@debian.org


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

Bug#757711: Bug#757988: kfreebsd: troubles with dhcp (configuration going away)

[Philipp Kern]

Hi,

On Thu, Aug 14, 2014 at 07:32:22PM +0200, Cyril Brulebois wrote:
> Now, I think there are several questions to answer:
>  1. What were the reasons for having arch-dependent dhcp clients?
>  2. Are those reasons still valid?
> 
> => Maybe think about moving to a single client if possible, at least for
>consistency's sake (and probably maintenance costs).
> 
> The answer to the first question is likely answered by looking at some
> git history, and possible links to bug reports. As for the second, we'll
> likely need porter input.

as I guessed from memory, here's one:

commit 75b4faa11bda438e34b5140934f6b812d1a69040
Author: Samuel Thibault 
Date:   Thu Mar 3 18:10:31 2011 +0100

Make netcfg depend on isc-dhcp-client-udeb on hurd-any too

for the same reason as kfreebsd: no support for udhcp in busybox.

If this is still true I don't know.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Bug#754314: systemd support for kdm

[Moritz Mühlenhoff]

On Tue, Aug 12, 2014 at 10:43:11AM +0200, Michael Biebl wrote:
> Hi,
> 
> On Thu, Jul 17, 2014 at 05:17:23PM +0200, Moritz Muehlenhoff wrote:
> > On Mon, Jul 14, 2014 at 06:34:40PM +0200, Moritz Mühlenhoff wrote:
> > > On Wed, Jul 09, 2014 at 10:16:07PM +0200, Moritz Muehlenhoff wrote:
> > > > Source: kde-workspace
> > > > Severity: wishlist
> > > > Tags: patch
> > > > 
> > > > activation of the service
> > > > -
> > > > 
> > > > After installation of the updated package the service isn't enabled
> > > > by default. You'll need to run "systemctl enable kdm.service" for
> > > > that. I'm not sure how the default display manager is handled if
> > > > several systemd units are installed, so it's probably for the best 
> > > > right now.
> > > 
> > > Michael Stapelberg explained to me that the unit file needs an additional
> > > WantedBy=multi-user.target which would resolve this.
> > 
> > This doesn't seem to be sufficient, I still need to enable the service 
> > manually
> > ATM.
> > 
> 
> This issue was discussed during the systemd/GNOME sprint this spring.
> I.e. how the display-manager.service symlink is supposed to be managed
> when multiple display managers are installed.
> 
> lightdm and gdm3 are already updated to support this scheme, so I'm bringing
> their maintainers into the loop here.
> Please coordinate with them when adding systemd support to kdm.

We should really wrap this into some common code, which is included from
the respective display managers! I've looked into lightdm amd gdm3 and 
they already diverge (lightdm misses the removal code present for gdm3). 
After all, this affects wdm and xdm as well.

Cheers,
Moritz


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

Bug#758152: ITP: ruby-timeline-setter -- TimelineSetter is a tool to create HTML timelines from spreadsheets of events.

[Balasankar C]

package: wnpp
Severity: wishlist
Owner: 'Balasankar C' 

*Package Name : ruby-timeline-setter
 Version : 0.3.2
  Upstream Author : ProPublica
  *URL :  https://github.com/propublica/timeline-setter#
  *License : Expat
  *Description :  TimelineSetter is a tool to create HTML timelines from 
spreadsheets of events. 



signature.asc
Description: Digital signature

Bug#753755: Big lock approach not correct. Will change it.

[Rafael David Tinoco]

Comments:

Suggestion to fix race condition present on this bug.
Testing this approach and will get back to this soon.
(Will run previous test cases for some hours).

I have also other change to put together lock and stage
file on different files for each interface but the change
is big and not suitable for a "SRU" (stable release update).

I'd like you to consider this first, saying if this looks
good enough for me to send you the final patch. 

Thank you.

-Rafael

---
This patch introduces a temporary per interface lock file to avoid
race conditions on parallel ifupdown executions.

This fixes race conditions like this:

(a)ifup bond0 (b)ifup -a
- ---
1. Update statefile about bond0.
  1. Does nothing about bond0
 because statefile is already
 updated about it.
2. ifenslave::setup_master()
   sysfs_change_down mode 1
   and link down bond0.
  2. Link up bond0 by the vlan
 script on the processing
 for linking up bond0.201(*1).
3. "echo 1 > .../mode" fails.

This is meant to be a stable release fix because the final approach
should be to use the te lockfile as an independent state file.
---
header.h |   5 +++
main.c   | 127 +++
2 files changed, 132 insertions(+)

diff --git a/header.h b/header.h
index a10a240..233bb9f 100644
--- a/header.h
+++ b/header.h
@@ -60,6 +60,8 @@ struct interface_defn
{
interface_defn *next;

+int lock;
+
char *logical_iface;
char *real_iface;

@@ -99,6 +101,9 @@ struct mapping_defn
#ifndef RUN_DIR
#define RUN_DIR "/run/network/"
#endif
+#ifndef TMP_DIR
+#define TMP_DIR "/tmp/"
+#endif

#ifndef LO_IFACE
#define LO_IFACE "lo"
diff --git a/main.c b/main.c
index 9f1aac1..09a33d3 100644
--- a/main.c
+++ b/main.c
@@ -420,6 +420,126 @@ bool make_pidfile_name(char *name, size_t size,
return true;
}

+//
+// functions to avoid race conditions: BEGIN
+//
+
+int
+string_compare(const void *p1, const void *p2)
+{
+   return strcmp(* (char * const *) p1, * (char * const *) p2);
+}
+
+int 
+lock_iface(struct interface_defn *intf, bool tolock)
+{
+// (un)lock a given interface 
+
+struct flock fl;
+char tobelocked[80];
+struct interface_defn *currif;
+
+fl.l_type = F_WRLCK;
+fl.l_whence = SEEK_SET;
+fl.l_start = 0;
+fl.l_len = 1;
+
+memset(&tobelocked, 0, 80);
+sprintf(&tobelocked, TMP_DIR ".ifupdown-%s.lock", intf->logical_iface);
+
+if(tolock)
+{
+intf->lock = -1;
+intf->lock  = open(tobelocked, O_RDWR | O_CREAT, 0666);
+}
+
+if (intf->lock == -1)
+fprintf(stderr, "cannot open/create lock file\n"), exit(1);
+
+if(tolock)
+{
+if((fcntl(intf->lock, F_SETLK, &fl)) == -1)
+{
+usleep(25);
+return 1;
+}
+}
+else
+{
+if(fcntl(intf->lock, F_UNLCK, &fl) == -1)
+fprintf(stderr, "cannot unlock file\n"), exit(1);
+
+/* sometimes lock file can be removed twice (testcase 7), no problem */
+if(remove(&tobelocked) == -1) { }
+
+close(intf->lock);
+}
+
+return 0;
+}
+
+void
+lock_ifaces(char **ifaces, int ifacesn, bool tolock)
+{
+// (un)lock target interfaces 
+
+int i;
+char *ptr, *end;
+char *tifaces[ifacesn], *sifaces[ifacesn];
+struct interface_defn *currif;
+
+// mapping or interface name ?
+
+for (i = 0; i < ifacesn; i++)
+{
+tifaces[i] = strchr(*(ifaces + i), '=');
+
+if(!tifaces[i])
+{
+tifaces[i] = *(ifaces +i);
+continue;
+}
+else
+tifaces[i]++;
+}
+
+// new target iface pointers 
+
+for (i = 0; i < ifacesn; i++)
+sifaces[i] = *(tifaces + i);
+
+// sort new target iface pointers so locking will avoid race conditions
+
+qsort(sifaces, ifacesn, sizeof(char *), string_compare);
+
+if(tolock)
+{
+// original order 
+for(i = 0; i < ifacesn; i++)
+for (currif = defn->ifaces; currif; currif = currif->next)
+if(strcmp(currif->logical_iface, sifaces[i]) == 0)
+{
+while(lock_iface(currif, 1))
+continue;
+}
+}
+
+else
+{
+// reverse order 
+for(i = ifacesn-1; i >= 0; i--)
+for (currif = defn->ifaces; currif; currif = currif->next)
+if(strcmp(currif->logical_iface, sifaces[i]) == 0) 
+{
+lock_iface(currif, 0);
+}
+}
+}
+
+//
+// functions to avoid race conditions: END
+//
+
int main(int argc, char **argv)
{
int (*cmds) (interface_defn *) = NULL;
@@ -658,6 +778,10

Bug#750741: built DLL depending on libgcc_s_sjlj-1.dll and libwinpthread-1.dll

[Bill Allombert]

On Tue, Aug 12, 2014 at 11:12:25PM +0200, Stephen Kitt wrote:
> Hi Bill,
> 
> On Mon, 11 Aug 2014 22:25:18 +0200, Bill Allombert 
> wrote:
> > On Tue, Jun 17, 2014 at 04:32:07PM +0200, Bill Allombert wrote:
> > > > If you do try this, could you let me know if it also drops the
> > > > libgcc_s_sjlj-1.dll dependency?
> > > 
> > > I did it but it does not change the dependencies:
> > 
> > I checked with your new package, and I still get a libgcc_s_sjlj-1.dll
> > dependency. However, it seems to be linked with the use of gettimeofday().
> > If I use ftime() instead of gettimeofday, the dependency disappears.
> > 
> > Do you know something about it ?
> 
> Is this when building PARI? I suppose not, at least I didn't see
> gettimeofday() being used there... (I'm asking because my libpari.dll doesn't
> need libgcc.)

This is in the GIT repository. I found this issue by doing a bisection.

> Anyway, regarding gettimeofday(), I don't see anything which would end up
> requiring libgcc. Building the following program
> 
> #include 
> #include 
> 
> int main(int argc, char **argv) {
>   struct timeval tv;
>   struct timezone tz;
>   if (!gettimeofday(&tv, &tz)) {
> printf("%d\n", tv.tv_sec);
>   }
> }
> 
> 
> for both 32-bit and 64-bit targets produces a working executable which
> doesn't require libgcc.

Indeed, but you are not building a DLL there. Only the dynamic libpari.dll is
affected. I join an archive that should allow you to reproduce this.
But this is not an urgent issue.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


gtod.tgz
Description: application/gtar-compressed

Bug#758105: bug#18266: grep -P and invalid exits with error

[Vincent Lefevre]

On 2014-08-14 11:19:28 -0700, Paul Eggert wrote:
> grep should work correctly even if the input contains NUL bytes, so perhaps
> it would be better to replace an invalid byte by the UTF-8 sequence for
> U+FFFD REPLACEMENT CHARACTER, as that's one standard way to deal with this
> problem.  Or perhaps the volunteer will have a better idea.

The problem with this solution is that it would change the length
of the text, while replacing invalid bytes by zero bytes could be
done in place (if allowed), with very little change of the code,
I think.

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


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

Bug#758105: bug#18266: grep -P and invalid exits with error

[Paul Eggert]

Vincent Lefevre wrote:

The problem with this solution is that it would change the length
of the text, while replacing invalid bytes by zero bytes could be
done in place (if allowed), with very little change of the code,
I think.


True.  Though it might be more user-friendly to use '?' as the 
replacement byte.



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

Bug#757761: [ovs-dev] [PATCH] test-controller: Rename to ovs-testcontroller, again install.

[Justin Pettit]

On August 14, 2014 at 11:16:51 AM, Ben Pfaff (b...@nicira.com) wrote:

> diff --git a/FAQ b/FAQ
> index 3470983..7fbf9a9 100644
> --- a/FAQ
> +++ b/FAQ
> @@ -89,9 +89,10 @@ A: Distributed vswitch applications (e.g., VMware vNetwork 
> distributed  
> environments: OpenFlow, which exposes flow-based forwarding state,
> and the OVSDB management protocol, which exposes switch port state.
> In addition to the switch implementation itself, Open vSwitch
> - includes tools (ovs-ofctl, ovs-vsctl) that developers can script and
> - extend to provide distributed vswitch capabilities that are closely
> - integrated with their virtualization management platform.
> + includes tools (ovs-ofctl, ovs-vsctl, ovs-appctl) that developers

Did you mean to introduce "ovs-appctl" in this patch?  It seems unrelated.


> +# Short-Description: Simple OpenFLow controller for testing

The "L" in "OpenFlow" is mistakenly capitalized.


> diff --git a/lib/ssl-bootstrap.man b/lib/ssl-bootstrap.man
> index c112f9a..37ed791 100644
> --- a/lib/ssl-bootstrap.man
> +++ b/lib/ssl-bootstrap.man
> @@ -14,7 +14,9 @@ for bootstrapping.
> .IP
> This option is only useful if the SSL peer sends its CA certificate as
> part of the SSL certificate chain. The SSL protocol does not require
> -the server to send the CA certificate.
> +the server to send the CA certificate, but
> +\fB\*(SN\fR(8) can be configured to do so with the
> +\fB\-\-peer\-ca\-cert\fR option.
> .IP
> This option is mutually exclusive with \fB\-C\fR and
> \fB\-\-ca\-cert\fR.

Did you mean to include this patch?  It also seems unrelated.


> +utilities/ovs-controller.8: \
> + utilities/ovs-controller.8.in \

Should these references to ovs-controller be here?


> diff --git a/ovsdb/ovsdb-client.1.in b/ovsdb/ovsdb-client.1.in
> index fbb7148..5704127 100644
> --- a/ovsdb/ovsdb-client.1.in
> +++ b/ovsdb/ovsdb-client.1.in
> @@ -8,6 +8,8 @@
> .TH ovsdb\-client 1 "@VERSION@" "Open vSwitch" "Open vSwitch Manual"
> .\" This program's name:
> .ds PN ovsdb\-client
> +.\" SSL peer program's name:
> +.ds SN ovsdb\-server
> .
> .SH NAME
> ovsdb\-client \- command-line interface to \fBovsdb-server\fR(1)
> diff --git a/ovsdb/ovsdb-server.1.in b/ovsdb/ovsdb-server.1.in
> index ec408a6..db0c216 100644
> --- a/ovsdb/ovsdb-server.1.in
> +++ b/ovsdb/ovsdb-server.1.in
> @@ -7,6 +7,8 @@
> .TH ovsdb\-server 1 "@VERSION@" "Open vSwitch" "Open vSwitch Manual"
> .\" This program's name:
> .ds PN ovsdb\-server
> +.\" SSL peer program's name:
> +.ds SN ovsdb\-client
> .
> .SH NAME
> ovsdb\-server \- Open vSwitch database server
> diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in

These changes also seem unrelated.


> --- a/utilities/bugtool/ovs-bugtool.in
> +++ b/utilities/bugtool/ovs-bugtool.in
> @@ -13,8 +13,8 @@
> # License along with this library; if not, write to the Free Software
> # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> #
> -# Copyright (c) 2005, 2007 XenSource Ltd.
> -# Copyright (c) 2010, 2011, 2012, 2013 Nicira, Inc.
> +# Copyright (c) 2005, 2007, 2014 XenSource Ltd.
> +# Copyright (c) 2010, 2011, 2012 Nicira, Inc.

This removes 2013 from our copyright.


> diff --git a/utilities/ovs-ofctl.8.in b/utilities/ovs-ofctl.8.in
> index aafda23..989eca4 100644
> --- a/utilities/ovs-ofctl.8.in
> +++ b/utilities/ovs-ofctl.8.in
> @@ -2162,5 +2162,6 @@ Prints the flow entries in the switch.
> .SH "SEE ALSO"
> .
> .BR ovs\-appctl (8),
> +.BR ovs\-controller (8),

I assume this should be "ovs\-testcontroller".


> .BR ovs\-vswitchd (8)
> .BR ovs\-vswitchd.conf.db (8)
> diff --git a/utilities/ovs-pki.8.in b/utilities/ovs-pki.8.in
> index 9c3019b..6d042b4 100644
> --- a/utilities/ovs-pki.8.in
> +++ b/utilities/ovs-pki.8.in
> @@ -236,3 +236,7 @@ Sets the log file to \fIfile\fR. Default:
> .IP "\fB\-h\fR"
> .IQ "\fB\-\^\-help\fR"
> Prints a help usage message and exits.
> +
> +.SH "SEE ALSO"
> +
> +.BR ovs\-controller (8).

Again, I assume this should be "ovs\-testcontroller".


> .SH NAME
> -test\-controller \- simple OpenFlow controller for testing
> +ovs\-testcontroller \- simple OpenFlow controller for

"for"...testing?


> \fB% ovs\-vsctl \-t0 \-\-db=pssl: \-\-certificate=cert.pem
> \-\-ca\-cert=none \-\-private\-key=privkey.pem
> -\-\-peer\-ca\-cert=cacert.pem set\-controller ssl:\fIip\fR
> +\-\-peer\-ca\-cert=cacert.pem set\-testcontroller ssl:\fIip\fR

I think this should stay as "set\-controller".


> diff --git a/utilities/ovs-vsctl.8.in b/utilities/ovs-vsctl.8.in
> index d397721..66a501e 100644
> --- a/utilities/ovs-vsctl.8.in
> +++ b/utilities/ovs-vsctl.8.in
> @@ -13,6 +13,8 @@
> .TH ovs\-vsctl 8 "@VERSION@" "Open vSwitch" "Open vSwitch Manual"
> .\" This program's name:
> .ds PN ovs\-vsctl
> +.\" SSL peer program's name:
> +.ds SN ovsdb\-server

I don't think you intended to introduce this change in this patch.


> @@ -467,7 +469,9 @@ for bootstrapping.
> .PP
> This option is only useful if the controller sends its CA certificate
> as part 

Bug#757761: [ovs-dev] [PATCH] test-controller: Rename to ovs-testcontroller, again install.

[Justin Pettit]

On August 14, 2014 at 12:59:07 PM, Justin Pettit (jpet...@nicira.com) wrote:
> On August 14, 2014 at 11:16:51 AM, Ben Pfaff (b...@nicira.com) wrote:
> 
> I assume this should be "ovs-\testcontroller".

Obviously, I meant that this should be "ovs\-testcontroller".

--Justin


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

Bug#758150: ASP.NET: Parser error for databindings inside attribute values

[Stefan Kadow]

Package: monodevelop
Version: 4.0.12+dfsg-4
Severity: important
Tags: upstream

This bug is fixed in an upstream version, see
https://bugzilla.xamarin.com/show_bug.cgi?id=12832
Comment 10 of this bugzilla report is presenting a patch, see
https://github.com/mono/monodevelop/commit/a13f9ac4a898c0d63008113ddc343f15a79c6f67

This bug prevents successful compiling of ASP.NET WebApplications using the
aspx view engine.
The compiler does not compile server-controls, which are using databindings to
render the value of a server-control attribute.



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

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

Versions of packages monodevelop depends on:
ii  gnome-icon-theme3.12.0-1
ii  gnome-terminal [x-terminal-emulator]3.12.3-2
ii  libc6   2.19-7
ii  libcairo2   1.12.16-2
ii  libgconf2.0-cil 2.24.2-3
ii  libglade2.0-cil 2.12.10-5
ii  libglib2.0-02.40.0-3
ii  libglib2.0-cil  2.12.10-5
ii  libgnome-vfs2.0-cil 2.24.2-3
ii  libgnome2.24-cil2.24.2-3
ii  libgtk2.0-0 2.24.24-1
ii  libgtk2.0-cil   2.12.10-5
ii  libgtkspell02.0.16-1
ii  libmono-addins-gui0.2-cil   1.0+git20130406.adcd75b-3
ii  libmono-addins0.2-cil   1.0+git20130406.adcd75b-3
ii  libmono-cairo4.0-cil3.2.8+dfsg-7
ii  libmono-corlib2.0-cil   3.2.8+dfsg-7
ii  libmono-corlib4.5-cil   3.2.8+dfsg-7
ii  libmono-microsoft-build-engine4.0-cil   3.2.8+dfsg-7
ii  libmono-microsoft-build-framework4.0-cil3.2.8+dfsg-7
ii  libmono-microsoft-build-utilities-v4.0-4.0-cil  3.2.8+dfsg-7
ii  libmono-microsoft-build2.0-cil  3.2.8+dfsg-7
ii  libmono-posix4.0-cil3.2.8+dfsg-7
ii  libmono-sharpzip4.84-cil3.2.8+dfsg-7
ii  libmono-system-configuration4.0-cil 3.2.8+dfsg-7
ii  libmono-system-core4.0-cil  3.2.8+dfsg-7
ii  libmono-system-data4.0-cil  3.2.8+dfsg-7
ii  libmono-system-design4.0-cil3.2.8+dfsg-7
ii  libmono-system-drawing4.0-cil   3.2.8+dfsg-7
ii  libmono-system-runtime-serialization4.0-cil 3.2.8+dfsg-7
ii  libmono-system-runtime2.0-cil   3.2.8+dfsg-7
ii  libmono-system-runtime4.0-cil   3.2.8+dfsg-7
ii  libmono-system-servicemodel4.0a-cil 3.2.8+dfsg-7
ii  libmono-system-web-mvc3.0-cil   3.2.8+dfsg-7
ii  libmono-system-web-razor2.0-cil 3.2.8+dfsg-7
ii  libmono-system-web-services4.0-cil  3.2.8+dfsg-7
ii  libmono-system-web-webpages-razor2.0-cil3.2.8+dfsg-7
ii  libmono-system-web-webpages2.0-cil  3.2.8+dfsg-7
ii  libmono-system-web4.0-cil   3.2.8+dfsg-7
ii  libmono-system-xaml4.0-cil  3.2.8+dfsg-7
ii  libmono-system-xml-linq4.0-cil  3.2.8+dfsg-7
ii  libmono-system-xml4.0-cil   3.2.8+dfsg-7
ii  libmono-system2.0-cil   3.2.8+dfsg-7
ii  libmono-system4.0-cil   3.2.8+dfsg-7
ii  libpango-1.0-0  1.36.3-1
ii  libpangocairo-1.0-0 1.36.3-1
ii  mono-runtime3.2.8+dfsg-7
ii  mono-runtime-sgen   3.2.8+dfsg-7
ii  monodoc-base3.2.8+dfsg-7
ii  monodoc-manual  3.2.8+dfsg-7
ii  pkg-config  0.28-1
ii  xfce4-terminal [x-terminal-emulator]0.6.3-1
ii  xterm [x-terminal-emulator] 308-1

Versions of packages monodevelop recommends:
ii  libglade2.0-cil-dev  2.12.10-5
ii  libgtk2.0-cil-dev2.12.10-5
ii  mono-devel   3.2.8+dfsg-7

Versions of packages monodevelop suggests:
pn  exuberant-ctags 
ii  gcc 4:4.9.1-1
pn  gettext 
ii  make-guile [make]   4.0-8
pn  mono-vbnc   
ii  mono-xsp4   3.0.11-1
pn  monodevelop-database
pn  monodevelop-debugger-gdb
pn  monodevelop-nunit   
pn  monodevelop-versioncontrol  
pn  monodoc-browser 
pn  zip 

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject 

Bug#758149: FTBFS with clang instead of gcc

[Alexander]

Source: ffindex
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs

Hello,

Using the rebuild infrastructure, your package fails to build with clang 
(instead of gcc).

We detected this kinf of error:
http://clang.debian.net/status.php?version=3.5.0rc1&key=NOT_ALLOWED_HERE

Full build log is available here:
http://clang.debian.net/logs/2014-06-16/ffindex_0.9.9.3-1_unstable_clang.log

Thanks,
Alexander

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

Kernel: Linux 3.2.0-4-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
--- ./src/ffindex.c	2014-08-14 23:34:44.0 +0400
+++ ../ffindex-0.9.9.3-my/./src/ffindex.c	2014-08-14 23:27:02.894501997 +0400
@@ -510,11 +510,10 @@
   return index;
 }
 
+static FILE* index_file_action = NULL;
+static int ret_action = EXIT_SUCCESS;
 
-int ffindex_tree_write(ffindex_index_t* index, FILE* index_file)
-{
-  int ret = EXIT_SUCCESS;
-  void action(const void *node, const VISIT which, const int depth)
+static void action(const void *node, const VISIT which, const int depth)
   {
 ffindex_entry_t *entry;
 switch (which)
@@ -526,13 +525,17 @@
   case postorder:
   case leaf:
 entry = *(ffindex_entry_t **) node;
-if(fprintf(index_file, "%s\t%zd\t%zd\n", entry->name, entry->offset, entry->length) < 0)
-  ret = EXIT_FAILURE;
+  if(fprintf(index_file_action, "%s\t%zd\t%zd\n", entry->name, entry->offset, entry->length) < 0)
+ret_action = EXIT_FAILURE;
 break;
 }
   }
+
+int ffindex_tree_write(ffindex_index_t* index, FILE* index_file)
+{
+  index_file_action = index_file;
   twalk(index->tree_root, action);
-  return ret;
+  return ret_action;
 }
 
 /* vim: ts=2 sw=2 et

Bug#758148: remote X applications not refreshing screen properly until forced

[Brent S. Elmer]

Package: metacity
Version: 1:3.12.0-2
Severity: normal

I am running an up to date jessie desktop using gnome-shell.  I have recently
noticed when I ssh to a remote server and start an xterm or emacs from the
remote server, the xterm or emacs windows fail to refresh properly until I
force a refresh on the window.  For example if I do an ls in the xterm, I will
see only part of the response until I force the window to refresh by moving my
cursor out of the window and then back into the window.  When the cursor comes
back into the window the screen will refresh.  The same will happen when
editing files in emacs.  Moving the cursor out of the window into the desktop
and back is not good enough to force the refresh.  I have to move the cursor
onto another open window and then back into the window I want to refresh.  I
have focus mode set to Mouse.

The problem appears to only happen with applications started on another
computer and tunneled back to my desktop through ssh.



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.14.4.140521 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages metacity depends on:
ii  gnome-icon-theme   3.12.0-1
ii  gsettings-desktop-schemas  3.12.2-1
ii  libatk1.0-02.12.0-1
ii  libc6  2.19-7
ii  libcairo2  1.12.16-2
ii  libcanberra-gtk3-0 0.30-2
ii  libcanberra0   0.30-2
ii  libgdk-pixbuf2.0-0 2.30.7-1
ii  libglib2.0-0   2.40.0-3
ii  libgtk-3-0 3.12.2-1+b1
ii  libgtop2-7 2.28.5-2
ii  libice62:1.0.9-1
ii  libmetacity-private1   1:3.12.0-2
ii  libpango-1.0-0 1.36.3-1
ii  libpangocairo-1.0-01.36.3-1
ii  libsm6 2:1.2.2-1
ii  libstartup-notification0   0.12-3
ii  libx11-6   2:1.6.2-2
ii  libxcomposite1 1:0.4.4-1
ii  libxcursor11:1.1.14-1
ii  libxdamage11:1.1.4-2
ii  libxext6   2:1.3.2-1
ii  libxfixes3 1:5.0.1-2
ii  libxinerama1   2:1.1.3-1
ii  libxrandr2 2:1.4.2-1
ii  libxrender11:0.9.8-1
ii  metacity-common1:3.12.0-2
ii  zenity 3.12.1-1.1

Versions of packages metacity recommends:
ii  gnome-session [x-session-manager]3.12.1-3
ii  gnome-session-flashback [x-session-manager]  3.8.0-3
ii  gnome-themes-standard3.12.0-1
ii  xfce4-session [x-session-manager]4.10.1-7

Versions of packages metacity suggests:
ii  gnome-control-center  1:3.12.1-4
pn  xdg-user-dirs 

-- 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#758147: wine-development: conflicts with wine

[jre]

Package: wine-development
Version: 1.7.24-2
Severity: normal


Hi,

--- snip ---
Unpacking wine (1.6.2-8) ...
dpkg: error processing archive
/var/cache/apt/archives/wine_1.6.2-8_amd64.deb (--unpack):
 trying to overwrite '/usr/bin/regedit', which is also in package
wine-development 1.7.24-2
Processing triggers for man-db (2.6.7.1-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/wine_1.6.2-8_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
--- snap ---


I guess for the time being wine-development should have the same
conflicts/replaces like wine-unstable to wine and vice-versa.
Or you just have to take care of regedit.

Related to the solution that you choose for this bug, I wonder whether
you consider wine and wine-development to be coinstallable and whether
you are basically done with the "big changes" for the wine packages (see
#741702 wine-unstable: not yet ready for stable release).

Personally I'd hope for a single /usr/bin/wine for wine and
wine-development, managed with Debian's alternatives system, instead of
the 3rd-party-(own scripts, winetricks, playonlinux, ...)-breaking
/usr/bin/wine-development.

Still, a huge Thank You for your efforts and I hope you get wine in
shape before the freeze.
jre



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

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

Versions of packages wine-development depends on:
ii  wine32-development  1.7.24-2
ii  wine64-development  1.7.24-2

wine-development recommends no packages.

Versions of packages wine-development suggests:
ii  binfmt-support 2.1.4-1
ii  ttf-mscorefonts-installer  3.5
pn  wine-doc   

-- 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#567395: unixcw: truncated CW dah's on some audio devices

[Colin Tuckley]

Kamal,

Looking at the NEWS file in the upstream sources it would appear that
this bug was fixed by version 3.0 / 2011.12.13

Can you please try to reproduce it and confirm it's status please.

Colin

-- 
Colin Tuckley  |  +44(0)1223 830814  |  PGP/GnuPG Key Id
Debian Developer   |  +44(0)7799 143369  | 0x38C9D903


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

Bug#758146: gdb: FTBFS on ppc64el due to missing run.1

[Edjunior Barbosa Machado]

Package: src:gdb
Version: 7.7.1+dfsg-1
Severity: important
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el

Hi maintainers,

I've noticed a couple of failures when building gdb 7.7.1+dfsg-1 from src on 
ppc64el. One of them was already fixed on upstream git repo (fix FTBFS on 
non-x86 trying to install unbuilt libinproctrace.so 
)
 but there was another issue with run.1 manpage, that was recently removed from 
Debian src:

...
/bin/bash /home/debian/gdb/debian/gdb.git/sim/common/../../mkinstalldirs 
/home/debian/gdb/debian/gdb.git/debian/tmp/usr/share/man/man1
mkdir -p -- /home/debian/gdb/debian/gdb.git/debian/tmp/usr/share/man/man1
n=`echo run | sed 's,y,y,'`; \
/usr/bin/install -p -m 644 
/home/debian/gdb/debian/gdb.git/sim/common/run.1 
/home/debian/gdb/debian/gdb.git/debian/tmp/usr/share/man/man1/$n.1
/usr/bin/install: cannot stat 
‘/home/debian/gdb/debian/gdb.git/sim/common/run.1’: No such file or directory
make[4]: *** [install-man] Error 1
make[4]: Leaving directory 
`/home/debian/gdb/debian/gdb.git/build/objdir/sim/common'
make[3]: *** [install] Error 1
make[3]: Leaving directory `/home/debian/gdb/debian/gdb.git/build/objdir/sim'
make[2]: *** [install-sim] Error 2
make[2]: Leaving directory `/home/debian/gdb/debian/gdb.git/build/objdir'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/debian/gdb/debian/gdb.git/build/objdir'
make: *** [debian/stamp-makefile-install] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

It seems this was also happening in other archs, such as armel and mipsel 
(https://buildd.debian.org/status/logs.php?pkg=gdb&ver=7.7.1%2Bdfsg-2)

Please consider the attached patch (against git HEAD commit id a0095d) that 
intends to fix this issue.

Thanks and regards,
--
Edjunior
diff --git a/debian/patches/fix-run.1-install.patch b/debian/patches/fix-run.1-install.patch
new file mode 100644
index 000..3575afa
--- /dev/null
+++ b/debian/patches/fix-run.1-install.patch
@@ -0,0 +1,18 @@
+--- a/sim/common/Makefile.in	2014-08-13 13:14:35.632343417 -0500
 b/sim/common/Makefile.in	2014-08-13 13:14:49.802243957 -0500
+@@ -116,14 +116,7 @@ distclean mostlyclean maintainer-clean r
+ force:
+ 
+ # Copy the files into directories where they will be run.
+-install: install-man
+-
+-install-man: installdirs
+-	n=`echo run | sed '$(program_transform_name)'`; \
+-	$(INSTALL_DATA) $(srcdir)/run.1 $(DESTDIR)$(man1dir)/$$n.1
+-
+-installdirs:
+-	$(SHELL) $(srcdir)/../../mkinstalldirs $(DESTDIR)$(man1dir)
++install:
+ 
+ Makefile: Makefile.in config.status
+ 	$(SHELL) ./config.status
diff --git a/debian/patches/series b/debian/patches/series
index 17707fe..6c1e086 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+fix-run.1-install.patch
 gdb-fortran-main.patch
 linuxthreads_signal_handling.patch
 solve_PATH_MAX_issue.patch
diff --git a/debian/rules b/debian/rules
index 3a526c2..e1a907e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -255,8 +255,6 @@ binary-post-install/gdb$(TS) ::
 	if [ -x debian/tmp/usr/bin/run ]; then\
 		mv debian/tmp/usr/bin/run	\
 		  debian/gdb$(TS)/usr/bin/$(DEB_TARGET_ALIAS)-run;		\
-		mv debian/tmp/usr/share/man/man1/run.1			\
-		  debian/gdb$(TS)/usr/share/man/man1/$(DEB_TARGET_ALIAS)-run.1;	\
 	fi
 ifeq ($(run_tests),yes)
 	install -d debian/gdb$(TS)/usr/share/doc/gdb

Bug#757637: dpkg: Fails to build on non-Linux systems

[Guillem Jover]

Hi!

On Thu, 2014-08-14 at 20:07:14 +0200, Aurelien Jarno wrote:
> On Sun, Aug 10, 2014 at 03:41:16AM +0200, Guillem Jover wrote:
> > Source: dpkg
> > Source-Version: 1.17.11
> > Severity: serious

> > Ok so it's failing to build on all non-Linux ports. I've a fix queued
> > locally, which I'll be pushing tomorrow in case there's anything else
> > to fix.
> 
> This new version change the triplet name on *i386, and thus some
> packages need to be adapted for the change. Could you please do the
> change so that the naming is consistent on all *i386 architectures?

Was caught by surprise first, because the change was done for all
systems, and then recalled that the cputable is shipped in the dpkg
package which is arch:any. Anyway, yeah I was planning to do the
release later today, as there's not been anything else popping up,
so that should fix it. Sorry for the trouble.

Thanks,
Guillem


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

Bug#758144: [claws-mail] shouldn't used translated headers internally

[Manolo Díaz]

Package: claws-mail
Version: 3.10.1-3
Severity: normal
Tags: l10n

Hi,

In a normal use, i.e. replying a message, nothing strange happens, but
replying from a web browser, a compose windows will be raised with the
En-Respuesta-A header automatically added. The problem is that that
header will be internally used instead of In-Reply-To, broking the
message thread.

Best Regards,
Manolo Díaz


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.1

Debian Release: jessie/sid
  500 testing ftp.debian.org 
  500 stable  security.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-==
libarchive13  | 3.1.2-8
libassuan0 (>= 2.0.1) | 2.1.1-1
libatk1.0-0   (>= 1.12.4) | 2.12.0-1
libc6   (>= 2.15) | 2.19-7
libcairo2  (>= 1.2.4) | 1.12.16-2
libcompfaceg1 | 1:1.5.2-5
libdb5.3  | 5.3.28-5
libdbus-1-3(>= 1.0.2) | 1.8.6-1
libdbus-glib-1-2(>= 0.78) | 0.102-1
libenchant1c2a (>= 1.6.0) | 1.6.0-10
libetpan17   (>= 1.4) | 1.5-1
libfontconfig1  (>= 2.11) | 2.11.0-5
libfreetype6   (>= 2.2.1) | 2.5.2-1.1
libgdk-pixbuf2.0-0(>= 2.22.0) | 2.30.7-1
libglib2.0-0  (>= 2.37.3) | 2.40.0-3
libgnutls-deb0-28   (>= 3.2.10-0) | 3.2.16-1
libgpg-error0   (>= 1.10) | 1.13-3
libgpgme11 (>= 1.1.2) | 1.5.1-1
libgtk2.0-0   (>= 2.24.0) | 2.24.24-1
libice6  (>= 1:1.0.0) | 2:1.0.9-1
libldap-2.4-2  (>= 2.4.7) | 2.4.39-1
liblockfile1 (>= 1.0) | 1.09-6
libpango-1.0-0(>= 1.14.0) | 1.36.3-1
libpangocairo-1.0-0   (>= 1.14.0) | 1.36.3-1
libpangoft2-1.0-0 (>= 1.14.0) | 1.36.3-1
libpisock9| 0.12.5-dfsg-1
libsasl2-2| 2.1.26.dfsg1-11
libsm6| 2:1.2.2-1
zlib1g   (>= 1:1.1.4) | 1:1.2.8.dfsg-1
xdg-utils | 1.1.0~rc1+git20111210-7.1


Recommends(Version) | Installed
===-+-===
claws-mail-i18n | 3.10.1-3
xfonts-100dpi   | 
 OR xfonts-75dpi| 
 OR xfonts-100dpi-transcoded| 
 OR xfonts-75dpi-transcoded | 
aspell-en   | 7.1-0-1
 OR aspell-dictionary   | 


Suggests(Version) | Installed
=-+-=
claws-mail-doc   (= 3.10.1-3) | 
www-browser   | 
gedit | 
 OR kwrite| 
 OR mousepad  | 0.3.0-2
 OR nedit | 
claws-mail-tools  | 3.10.1-3


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

Bug#758145: installation-reports: Missing dbus; logind service fails

[Mel Davis]

Package: installation-reports
Severity: normal

Dear Maintainer,

What led to situation...
Fresh install of OS on new SD card. Basic default installation. No custom 
drivers. No errors or problems reported during the install. 

Booting into OS reported the following error: 
"Failed to start Login Service".

What I did that was effective...
Running "systemctl status systemd-login.service -l" indicated that it 
failed to find the dbus.socket.

Installed dbus via apt-get.   
Rebooted. Problem solved.

-- Package-specific info:

Boot method: network
Image version: 
http://ftp.nl.debian.org/debian/dists/wheezy/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/uImage
Date: 2014 Aug 14 around noon.

Machine: SheevaPlug
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [o ]
Detect network card:[o ]
Configure network:  [o ]
Detect CD:  [o ]
Load installer modules: [o ]
Clock/timezone setup:   [o ]
User/password setup:[o ]
Detect hard drives: [o ]
Partition hard drives:  [o ]
Install base system:[o ]
Install tasks:  [o ]
Install boot loader:[o ]
Overall install:[o ]



==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="7 (wheezy) - installer build 20130613+deb7u2+b1"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux sheeva 3.2.0-4-kirkwood #1 Debian 3.2.57-3 armv5tel GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: Marvell Orion EHCI [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 3.2.0-4-kirkwood ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 01 Device 02: v125w [03f0:3307]
usb-list:Level 01 Parent 01 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: HP
usb-list:Interface 00: Class 08(mstor) Subclass 06 Protocol 50 Driver 
usb-storage
lsmod: Module  Size  Used by
lsmod: dm_mod 63319  0 
lsmod: md_mod 94840  0 
lsmod: jfs   152953  0 
lsmod: ext4  377557  1 
lsmod: jbd2   65925  1 ext4
lsmod: ext3  163483  0 
lsmod: jbd57469  1 ext3
lsmod: btrfs 705702  0 
lsmod: crc32c  2534  1 
lsmod: libcrc32c876  1 btrfs
lsmod: vfat8381  0 
lsmod: fat42493  1 vfat
lsmod: ext2   54932  1 
lsmod: mbcache 4464  3 ext2,ext3,ext4
lsmod: sd_mod 30932  0 
lsmod: crc_t10dif  1110  1 sd_mod
lsmod: usb_storage35237  0 
lsmod: scsi_mod  149401  2 usb_storage,sd_mod
lsmod: mmc_block  16108  4 
lsmod: ehci_hcd   38151  0 
lsmod: usbcore   122576  3 ehci_hcd,usb_storage
lsmod: mvsdio  5162  0 
lsmod: mmc_core   77612  2 mvsdio,mmc_block
lsmod: usb_common   648  1 usbcore
lsmod: mv643xx_eth22806  0 
lsmod: inet_lro4272  1 mv643xx_eth
lsmod: libphy 14472  1 mv643xx_eth
df: Filesystem   1K-blocks  Used Available Use% Mounted on
df: none 5151236 51476   0% /run
df: tmpfs   257560 0257560   0% /dev
df: /dev/mmcblk0p229093876987556  26628432   4% /target
df: /dev/mmcblk0p1  233191 23195197555  11% /target/boot
df: /dev/mmcblk0p229093876987556  26628432   4% /dev/.static/dev
df: tmpfs   257560 0257560   0% /target/dev
free:  total used free   shared  buffers
free: Mem:515120   406128   108992052416
free: -/+ buffers: 353712   161408
free: Swap:  1357820   56  1357764
/proc/cmdline: console=ttyS0,115200n8 
base-installer/initramfs-tools/driver-policy=most priority=low
/proc/cpuinfo: Processor: Feroceon 88FR131 rev 1 (v5l)
/proc/cpuinfo: BogoMIPS : 1191.11
/proc/cpuinfo: Features : swp half thumb fastmult edsp 
/proc/cpuinfo: CPU implementer  : 0x56
/proc/cpuinfo: CPU architecture: 5TE
/proc/cpuinfo: CPU variant  : 0x2
/proc/cpuinfo: CPU part : 0x131
/proc/cpuinfo: CPU revision : 1
/proc/cpuinfo: 
/proc/cpuinfo: Hardware : Marvell SheevaPlug Reference Board
/proc/cpuinfo: Revision : 
/proc/cpuinfo: Serial   : 
/proc/iomem: -1fff : System RAM
/proc/iomem:   8000-003e75cb : Kernel text
/proc/iomem:   0040c000-004a9f57 : Kernel data
/proc

Bug#758050: [systemd-devel] Bug#758050: udev: ID_VENDOR_FROM_DATABASE, ID_MODEL_FROM_DATABASE for unrecognised USB device are taken from USB hub

[Kay Sievers]

On Thu, Aug 14, 2014 at 3:07 PM, Simon McVittie
 wrote:
> I recently opened this Debian bug, for which I attach a
> patch that seems to work. Bug report quoted in full below.
>
> I would appreciate udev maintainers' opinions on whether this is
> likely to break non-USB devices, or whether there is a better way
> to do it.

Maybe replace streq(dsubsys, "usb") with a specific match on " devtype
== usb_device" (sysfs hierarchy is usb_interface -> usb_device) and if
we hit that, we make sure we stop looking at any of the parents?

Thanks,
Kay


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

Bug#758090: ltspfs: lbmount use of "mount --move" incompatible with systemd

[Vagrant Cascadian]

Control: tags -1 +patch

On 2014-08-14, Vagrant Cascadian wrote:
> A quick workaround is to use "mount --bind" instead of "mount --move",
> but this has the undesired side-effect of leaving two mounts in place,
> one in /tmp/.USERNAME-ltspfs/MOUNT and one in /media/USERNAME/MOUNT.
> Though some brief experiments show that unmounting the /tmp mount left
> the /media mount in place when i tried it... that might make it a viable
> workaround.

Patch that implements this, including the umounting:

diff --git a/scripts/ltspfsmounter b/scripts/ltspfsmounter
index 642202f..5322b23 100644
--- a/scripts/ltspfsmounter
+++ b/scripts/ltspfsmounter
@@ -32,6 +32,7 @@ def add_ltspfsmount(conn, path, root, dev, mediaroot):
 hidden_mount = '%s/%s' % (root, dev)
 lbmount_command = ['lbmount', dev]
 ltspfs_mount = ['ltspfs', conn+':'+path, root+'/'+dev]
+ltspfs_umount=['fusermount', '-uzq', hidden_mount]
 
 if not os.access(root, 0):
 os.mkdir(root)
@@ -47,6 +48,7 @@ def add_ltspfsmount(conn, path, root, dev, mediaroot):
 try:
 call(lbmount_command)
 if os.access(hidden_mount, 0):
+call(ltspfs_umount)
 os.rmdir(hidden_mount)
 if os.access(root, 0):
 os.rmdir(root)
diff --git a/src/lbmount.c b/src/lbmount.c
index 8421e25..c1a8067 100644
--- a/src/lbmount.c
+++ b/src/lbmount.c
@@ -155,7 +155,7 @@ int root_mounter(const char *path1, const char *path2)
 }
 /* Statically build command line to prevent monkey business */
 if (path2)
-execle(mountprog, mountprog, "--move", path1, path2, NULL,
+execle(mountprog, mountprog, "--bind", path1, path2, NULL,
null_env);
 else
 execle(umountprog, umountprog, "-l", path1, NULL, null_env);


live well,
  vagrant


pgpEWEzWxml1_.pgp
Description: PGP signature

Bug#757581: pytables: FTBFS on s390x

[Gilles Filippini]

Antonio Valentino a écrit , Le 14/08/2014 20:21:
> Hi Gilles,
> 
> Il 14/08/2014 19:28, Gilles Filippini ha scritto:
>> Control: usertag -1 HDF5-transition
> 
>> Hi Antonio,
> 
>> On Sun, 10 Aug 2014 08:09:54 +0200 Antonio Valentino 
>>  wrote:
>>> The problem seems to be related to the lz4 compressor.
>>>
>>> I am investigating it.
> 
>> Any news about this bug? This is the last blocker for the upcoming
>> HDF5 transition.
> 
>> Thanks, in advance,
> 
>> _g.
> 
> 
> I'm pretty sure that the issue is in the lz4 compression library
> rather then in pytables.
> 
> pytables 3.1.1-1 has been built successfully using
> liblz4-1_0.0~r114-2_s390x [1] while pytables 3.1.1-2, the one that
> fails, has ben built using liblz4-1_0.0~r119-2_s390x [2].
> 
> In the last release of the lz4 package (lz4_0.0~r119-2) tests have
> been disabled on s390x and sparc so my clue is that there is actually
> a problem with liblz4 on s380x.
> 
> I tried to contact the maintainer of lz4 but I still had no reply
> (vacations probably).
> 
> IMO the only thing I can do on my part is to disable tests using the
> lz4 compressor on s390x but this is not a real solution.
> 
> 
> Probably this bug should be re-assigned to liblz4.

Then I'd propose to re-assign to liblz4 and temporarily disable lz4
related tests to enable the HDF5 transition. Would it be acceptable for you?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#758106: ploop ftbfs on mips64el

[Ola Lundqvist]

Hi

Thanks for the report. As the kernel that ploop depend on is not supported
for mipsel it does not really matter.

Thanks anyway.

// Ola


On Thu, Aug 14, 2014 at 12:16 PM, YunQiang Su  wrote:

> Package: ploop
> Version: 1.11-1
>
> On mips64el, long long and long has the same 64bit width, while
> they are totally different type.
>
> Not very sure about why.
>
> --
> YunQiang Su
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comAnnebergsslingan 37\
|  o...@debian.org   654 65 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#743588: mirror submission for debian.mirror.utn.edu.ar

[Fernando Diez]

Hi Simon, wanted to know if they could process my form to add the server to
the mirror list.

Thank you very much!


2014-08-07 14:39 GMT-03:00 Fernando Diez :

> Hi,
>
> On Wed, Aug 06, 2014 at 10:52:37AM -0300, Fernando Diez wrote:
> > On Tue, Aug 05, 2014 at 2:32:29 PM -0300, Fernando Diez wrote:
> > > On Fri, May 02, 2014 at 2:35:27 PM +0200, Simon Paillard wrote:
> > >>> On Fri, April 4, 2014 at 1:10:48 AM +0200, Simon Paillard wrote:
> >  On Thu, April 3rd, 2014 at 10:58:35 PM +, Fernando Gabriel Diez
> > >> Wrote:
> > >> [..]
> > > Archive-architecture: i386
> > >>>
> > >>> Could you please do excludes sources from the mirror?
> > >>
> > >> Could you please fix that?
> > >> I.e. remove sources from ARCH_EXCLUDE.
> > >
> > > Excuse me but I do not understand, I'm not mirror the source of where I
> > > Should fix?
> >
> > Sources must be provided, to mirror Debian Recognized by Shall not
> exclude
> > sources.
> > In etc / ftpsync.conf, make sure 'sources' is * NOT * in ARCH_EXCLUDE.
> >
> > *Ok, this already solved. *
>
> Then, can you sync the mirror again with sources please ?
> *
> http://debian.mirror.utn.edu.ar/debian/project/trace/debian.mirror.utn.edu.ar
>   should mention sources in Architectures
> * Your mirror should provide sources, for exemple see *dsc and *tar.gz in
>   http://debian.mirror.utn.edu.ar/debian/pool/main/b/base-files/
>
> Already solved!
>
> Given your upstream ftp.br.debian.org has sources, there is something in
> your
> configuration that drops sources.
> Ok
>
> > [..]
> > *Could you please give me an estimated time to join the list of secondary
> > mirror? *
>
> Once all criteria are met, this is pretty fast.
> Ok, can you please tell me when i can see the soluction?
>
> Fer
> El 06/08/2014 12:43, "Simon Paillard"  escribió:
>
> Hi,
>>
>> On Wed, Aug 06, 2014 at 10:52:37AM -0300, Fernando Diez wrote:
>> > On Tue, Aug 05, 2014 at 2:32:29 PM -0300, Fernando Diez wrote:
>> > > On Fri, May 02, 2014 at 2:35:27 PM +0200, Simon Paillard wrote:
>> > >>> On Fri, April 4, 2014 at 1:10:48 AM +0200, Simon Paillard wrote:
>> >  On Thu, April 3rd, 2014 at 10:58:35 PM +, Fernando Gabriel Diez
>> > >> Wrote:
>> > >> [..]
>> > > Archive-architecture: i386
>> > >>>
>> > >>> Could you please do excludes sources from the mirror?
>> > >>
>> > >> Could you please fix that?
>> > >> I.e. remove sources from ARCH_EXCLUDE.
>> > >
>> > > Excuse me but I do not understand, I'm not mirror the source of where
>> I
>> > > Should fix?
>> >
>> > Sources must be provided, to mirror Debian Recognized by Shall not
>> exclude
>> > sources.
>> > In etc / ftpsync.conf, make sure 'sources' is * NOT * in ARCH_EXCLUDE.
>> >
>> > *Ok, this already solved. *
>>
>> Then, can you sync the mirror again with sources please ?
>> *
>> http://debian.mirror.utn.edu.ar/debian/project/trace/debian.mirror.utn.edu.ar
>>   should mention sources in Architectures
>> * Your mirror should provide sources, for exemple see *dsc and *tar.gz in
>>   http://debian.mirror.utn.edu.ar/debian/pool/main/b/base-files/
>>
>> Given your upstream ftp.br.debian.org has sources, there is something in
>> your
>> configuration that drops sources.
>>
>> > [..]
>> > *Could you please give me an estimated time to join the list of
>> secondary
>> > mirror? *
>>
>> Once all criteria are met, this is pretty fast.
>>
>> --
>> Simon Paillard
>>
>

Bug#758134: Updated information

[Darryl L. Pierce]

* Upstream Author : Qpid Development Team 
* URL : http://qpid.apache.org
* License : Apache 2.0

-- 
Darryl L. Pierce 
http://mcpierce.blogspot.com/
Famous last words:
   "I wonder what happens if we do it this way?"


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

Bug#750884: Pending fixes for bugs in the fonts-android package

[Gunnar Hjalmarsson]

Thanks Vasudev and Christan!

I feared that someone was questioning the fix which was just uploaded.
Now I know that's not the case.

-- 
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj


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

Bug#758134: RFS: qpid-cpp/0.28-1 [ITA]

[Daniel Lintott]

Hi Darryl,

On 14/08/14 19:15, Darryl L. Pierce wrote:
> On Thu, Aug 14, 2014 at 10:48:31AM -0400, Darryl L. Pierce wrote:
>> Package: sponsorship-requests
>> Severity: normal
>>
>> Dear Maintainer,
>>  I am looking for a sponsor for my package "qpid-cpp"
>>
>>  * Package name: qpid-cpp
>>Version : 0.28-1
>>Upstream Author : [fill in name and email of upstream]
>>  * URL : [fill in URL of upstreams web site]
>>  * License : [fill in]
> 
> Slipped and didn't fill in these fields. Is there a way to update the
> fields, or should I resubmit the RFS?
> 

Just send an email to the bug report (758...@bugs.debian.org) with the
information you missed.

No need to resubmit the RFS. Also when you send a followup to the RFS
(or any bug), there's no need to include the submit@b.d.o address.

Regards

Daniel



signature.asc
Description: OpenPGP digital signature

Bug#757581: pytables: FTBFS on s390x

[Antonio Valentino]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gilles,

Il 14/08/2014 19:28, Gilles Filippini ha scritto:
> Control: usertag -1 HDF5-transition
> 
> Hi Antonio,
> 
> On Sun, 10 Aug 2014 08:09:54 +0200 Antonio Valentino 
>  wrote:
>> The problem seems to be related to the lz4 compressor.
>> 
>> I am investigating it.
> 
> Any news about this bug? This is the last blocker for the upcoming
> HDF5 transition.
> 
> Thanks, in advance,
> 
> _g.
> 

I'm pretty sure that the issue is in the lz4 compression library
rather then in pytables.

pytables 3.1.1-1 has been built successfully using
liblz4-1_0.0~r114-2_s390x [1] while pytables 3.1.1-2, the one that
fails, has ben built using liblz4-1_0.0~r119-2_s390x [2].

In the last release of the lz4 package (lz4_0.0~r119-2) tests have
been disabled on s390x and sparc so my clue is that there is actually
a problem with liblz4 on s380x.

I tried to contact the maintainer of lz4 but I still had no reply
(vacations probably).

IMO the only thing I can do on my part is to disable tests using the
lz4 compressor on s390x but this is not a real solution.


Probably this bug should be re-assigned to liblz4.


[1]
https://buildd.debian.org/status/fetch.php?pkg=pytables&arch=s390x&ver=3.1.1-1%2Bb1&stamp=1401996113
[2]
https://buildd.debian.org/status/fetch.php?pkg=pytables&arch=s390x&ver=3.1.1-2&stamp=1407372229
[3] https://tracker.debian.org/media/packages/l/lz4/changelog-0.0~r119-2


cheers

- -- 
Antonio Valentino
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlPs/jQACgkQ1JUs2CS3bP4KfgCgvDSNsaKaQZdy+xhEPUgcgldB
Z0EAnRMYq02yDqmqct4q63BXuj/JssWI
=X+Z2
-END PGP SIGNATURE-


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