Bug#766430: bind9 nmu

[Michael Gilbert]

control: tag -1 patch, pending

Hi, I've uploaded an nmu to delayed/3 fixing these two issues in bind.
Please let me know if I should delay longer.

Best wishes,
Mike
diff -u bind9-9.9.5.dfsg/configure.in bind9-9.9.5.dfsg/configure.in
--- bind9-9.9.5.dfsg/configure.in
+++ bind9-9.9.5.dfsg/configure.in
@@ -1655,7 +1655,6 @@
 		;;
 	*)
 		AC_CHECK_LIB(socket, socket)
-		AC_CHECK_LIB(nsl, inet_addr)
 		;;
 esac
 
diff -u bind9-9.9.5.dfsg/debian/changelog bind9-9.9.5.dfsg/debian/changelog
--- bind9-9.9.5.dfsg/debian/changelog
+++ bind9-9.9.5.dfsg/debian/changelog
@@ -1,3 +1,11 @@
+bind9 (1:9.9.5.dfsg-4.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Avoid libnsl dependency on non-linux architectures.  Closes: #766430
+  * Install export libraries to /lib instead of /usr/lib.  Closes: #766544
+
+ -- Michael Gilbert   Tue, 28 Oct 2014 03:37:48 +
+
 bind9 (1:9.9.5.dfsg-4.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u bind9-9.9.5.dfsg/debian/control bind9-9.9.5.dfsg/debian/control
--- bind9-9.9.5.dfsg/debian/control
+++ bind9-9.9.5.dfsg/debian/control
@@ -185,6 +185,7 @@
 Package: libdns-export100
 Section: libs
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Exported DNS Shared Library
  ${Description}
@@ -201,6 +202,7 @@
 Package: libisc-export95
 Section: libs
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Exported ISC Shared Library 
  ${Description}
@@ -217,6 +219,7 @@
 Package: libisccfg-export90
 Section: libs
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Exported ISC CFG Shared Library
  ${Description}
@@ -233,6 +236,7 @@
 Package: libirs-export91
 Section: libs
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Exported IRS Shared Library
  ${Description}
diff -u bind9-9.9.5.dfsg/debian/libbind-export-dev.install bind9-9.9.5.dfsg/debian/libbind-export-dev.install
--- bind9-9.9.5.dfsg/debian/libbind-export-dev.install
+++ bind9-9.9.5.dfsg/debian/libbind-export-dev.install
@@ -1,3 +1,3 @@
-usr/lib/*-export.a
-usr/lib/*-export.so
+usr/lib/*/*.a
+usr/lib/*/*.so
 usr/include/bind-export
diff -u bind9-9.9.5.dfsg/debian/libdns-export100-udeb.install bind9-9.9.5.dfsg/debian/libdns-export100-udeb.install
--- bind9-9.9.5.dfsg/debian/libdns-export100-udeb.install
+++ bind9-9.9.5.dfsg/debian/libdns-export100-udeb.install
@@ -1 +1 @@
-usr/lib/libdns-export*.so.*
+lib/*/libdns-export.so.*
diff -u bind9-9.9.5.dfsg/debian/libdns-export100.install bind9-9.9.5.dfsg/debian/libdns-export100.install
--- bind9-9.9.5.dfsg/debian/libdns-export100.install
+++ bind9-9.9.5.dfsg/debian/libdns-export100.install
@@ -1 +1 @@
-usr/lib/libdns-export.so.*
+lib/*/libdns-export.so.*
diff -u bind9-9.9.5.dfsg/debian/libirs-export91-udeb.install bind9-9.9.5.dfsg/debian/libirs-export91-udeb.install
--- bind9-9.9.5.dfsg/debian/libirs-export91-udeb.install
+++ bind9-9.9.5.dfsg/debian/libirs-export91-udeb.install
@@ -1 +1 @@
-usr/lib/libirs-export*.so.*
+lib/*/libirs-export.so.*
diff -u bind9-9.9.5.dfsg/debian/libirs-export91.install bind9-9.9.5.dfsg/debian/libirs-export91.install
--- bind9-9.9.5.dfsg/debian/libirs-export91.install
+++ bind9-9.9.5.dfsg/debian/libirs-export91.install
@@ -1 +1 @@
-usr/lib/libirs-export.so.*
+lib/*/libirs-export.so.*
diff -u bind9-9.9.5.dfsg/debian/libisc-export95-udeb.install bind9-9.9.5.dfsg/debian/libisc-export95-udeb.install
--- bind9-9.9.5.dfsg/debian/libisc-export95-udeb.install
+++ bind9-9.9.5.dfsg/debian/libisc-export95-udeb.install
@@ -1 +1 @@
-usr/lib/libisc-export*.so.*
+lib/*/libisc-export.so.*
diff -u bind9-9.9.5.dfsg/debian/libisc-export95.install bind9-9.9.5.dfsg/debian/libisc-export95.install
--- bind9-9.9.5.dfsg/debian/libisc-export95.install
+++ bind9-9.9.5.dfsg/debian/libisc-export95.install
@@ -1 +1 @@
-usr/lib/libisc-export.so.*
+lib/*/libisc-export.so.*
diff -u bind9-9.9.5.dfsg/debian/libisccfg-export90-udeb.install bind9-9.9.5.dfsg/debian/libisccfg-export90-udeb.install
--- bind9-9.9.5.dfsg/debian/libisccfg-export90-udeb.install
+++ bind9-9.9.5.dfsg/debian/libisccfg-export90-udeb.install
@@ -1 +1 @@
-usr/lib/libisccfg-export*.so.*
+lib/*/libisccfg-export.so.*
diff -u bind9-9.9.5.dfsg/debian/libisccfg-export90.install bind9-9.9.5.dfsg/debian/libisccfg-export90.install
--- bind9-9.9.5.dfsg/debian/libisccfg-export90.install
+++ bind9-9.9.5.dfsg/debian/libisccfg-export90.install
@@ -1 +1 @@
-usr/lib/libisccfg-export.so.*
+lib/*/libisccfg-export.so.*
diff -u bind9-9.9.5.dfsg/debian/rules bind9-9.9.5.dfsg/debian/rules
--- bind9-9.9.5.dfsg/debian/rules
+++ bind9-9.9.5.dfsg/debian/rules
@@ -54,7 +54,7 @@
 		--enable-exportlib \
 		--with-libtool \
 		--with-gssapi=no \
-		--with-export-libdir=\$${prefix}/lib \
+		--with-export-libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
 		--with-export-includedir=\$${prefix}/i

Bug#767009: cyphesis-cpp: FTBFS: B-D on old libreadline5-dev

[Olek]

Hey Aaron!

On 10/27/2014 10:41 AM, Aaron M. Ucko wrote:

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

Automatic builds of cyphesis-cpp have been failng:

   The following packages have unmet dependencies:
sbuild-build-depends-cyphesis-cpp-dummy : Depends: libreadline5-dev but it 
is not installable
   E: Unable to correct problems, you have held broken packages.

The alternative build dependency on libreadline-dev makes no
difference because, for the sake of maximum reproducibility, Debian's
autobuilders are configured to consider alternatives only when forced
to by explicit architecture restrictions.

Could you please change that term to just libreadline-dev, which is
now a (non-virtual) dummy package depending on the current real
package (libreadline6-dev)?

Thanks!



Thanks for bringing this to my attention! I'll take care of it right 
away. Hope things are going well for you and I hope the warmer weather 
this summer was a pleasant change. :) Take care.


-Olek


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

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

[Helmut Grohne]

On Mon, Oct 27, 2014 at 09:41:59PM +, Ian Jackson wrote:
> > The most obvious bug is the one mentioned in the patch: #760770
> > It is about a bug in the implementation of with_deps_on_target_arch (the
> > contended feature).
> 
> I think I may not understand what's going on here.  In your mail to
> the TC, you say:
> 
>it was possible to build a gcc cross compiler with different
>properties from the default build by setting
>with_deps_on_target_arch_pkgs=yes and DEB_CROSS_NO_BIARCH=yes.
> 
> You mean setting these as environment variables ?  If so then it would
> seem that this feature has no direct effect on anyone who is not
> trying to use it.  Is that correct ?

It is correct, that builds that do not set these variables are not
affected by it beyond also carrying it as dead code in the gcc
packaging.

> Of course it does have a maintenance burden on the package maintainer,
> which is what Don is asking about.

I have to admit that the code is not exactly lightweight. I do
understand the desire to get rid it and asked that a ctte ruling does
not apply beyond jessie for that reason.

> #760770 shows an element of that but it is immediately obvious from
> the initial report that something odd is going on and it contains a
> link to #720363 which mentions

Oh, my previous bug research has missed gcc-4.8 bugs.

> https://wiki.debian.org/MultiarchCrossToolchainBuild which talks
> abouit the with_deps_on_target_arch_pkgs feature.  It doesn't appear
> that #760770 has taken a great deal of Matthias's time, although it
> did necessitate some bug triage.

One of the issues here is that the submitter wasn't explicit about using
the non-default build here. It only surfaced in message 19 and can be
spotted from looking at the patch. When being asked to do a
self-contained cross build (and the self-contained kinda implies not
using with_deps_on_target_arch_pkgs), a log with the alternative build
method is sent back.

> Are the maintainers of the disputed features subscribed to the
> appropriate packages in the PTS ?  Does Matthias welcome help triaging

I am not subscribed yet. The major reason is that I did not perceive the
maintenance of the feature as a problem until Matthias stated it in this
bug. It is certainly fixable.

> these bugs ?  It seems to me that it would be easy to come up with a
> workflow that allowed Matthias to usertag these kind of bugs and hand
> them over to the cross teams.

Sounds reasonable to me. Asking Wookey whether he would like to share
that work.

> What are the cross-gcc-4.9-armhf packages that are referred to ?

It is a source package that uses the gcc-4.9-source binary package from
the gcc-4.9 source package to build a cross compiler targeting armhf. In
GNU terminology that is build=host=amd64, target=armhf. The packaging is
thin compared to the gcc-4.9 packaging and its goal is to enable people
to just apt-get install cross toolchains rather than building them each
time they need them. (I am not a maintainer of cross-gcc-4.9-*.)

Judging from the replies, I would like to repeat the timing argument
here:

The mechanism being discussed was disabled in gcc-4.9 without any
advance notice or discussion[1]. The code for supporting the default
method in glibc has not yet arrived in the Debian glibc package or the
BTS, but Matthias indicated that he would be working on that and he
seems to make progress outside Debian. I am not opposed to using the
default build method for bootstrapping new Debian architectures in
principle, but in my experience it takes a long time to merge patches
into the glibc packaging and the freeze is certainly not accelerating
that process. I am not opposed to disabled with_deps_on_target_arch_pkgs
in general, just now is the wrong time, because it is impossible to get
the corresponding functionality to gcc's default cross build into glibc.
Most of the changes necessary to make the alternative method work with
glibc have been merged however: #743676 #754350 #756095 #742640 #745380
#752480 #755580 #756473 (but most of these changes are also necessary
for the default method)

Helmut

[1] It is worth noting here that the upload of cross-gcc-4.9-* similarly
lacked discussion. An advance notice to the gcc list or targeting
experimental would have been better here.


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

Bug#761939: solaar: General update after the debconf review process

[Christian PERRIER]

Dear Debian maintainer,

On Sunday, September 21, 2014, I sent you a notification about the beginning of 
a review
action on debconf templates for solaar.

Then, I sent you a bug report with rewritten templates and announcing
the beginning of the second phase of this action: call for translation
updates.

Translators have been working hard and here is now the result of their efforts.

Please consider using it EVEN if you committed files to your
development tree as long as they were reported.

The attached tarball contains:

- debian/changelog with the list of changes
- debian/control with rewrites of packages' descriptions
- debian/ with all the rewritten templates file(s)
- debian/po/*.po with all PO files (existing ones and new ones)

As said, please use *at least* the PO files as provided here,
preferrably over those sent by translators in their bug reports. All
of them have been checked and reformatted. In some cases, formatting
errors have been corrected.

The patch.rfr file contains a patch for the templates and control
file(s) alone.

Please note that this patch applies to the templates and control
file(s) of your package as of Sunday, September 21, 2014. If your package was 
updated
in the meantime, I may have updated my reference copybut I also
may have missed that. This is indeed why I suggested you do not
modified such files while the review process was running,
remember..:-)

It is now safe to upload a new package version with these changes.

Please notify me of your intents with regards to this. 

There is of course no hurry to update your package but feel free to
contact me in case you would need sponsoring or any other action to
fix this.



-- 




patch.tar.gz
Description: application/gzip
--- solaar.old/debian/solaar.templates  2014-09-17 06:57:04.472944105 +0200
+++ solaar/debian/solaar.templates  2014-10-06 08:12:04.322369173 +0200
@@ -1,21 +1,32 @@
+# These templates have been reviewed by the debian-l10n-english
+# team
+#
+# If modifications/additions/rewording are needed, please ask
+# debian-l10n-engl...@lists.debian.org for advice.
+#
+# Even minor modifications require translation updates and such
+# changes should be coordinated with translators and reviewers.
+
 Template: solaar/use_plugdev_group
 Type: boolean
 Default: false
+#flag:comment:3
+# Translators : DO NOT TRANSLATE the ${SEAT_DAEMON_STATUS} variable name
 _Description: Use plugdev group?
- By default, the Logitech receiver devices are only accessible by the root 
user.
+ Please specify how non-root users should be given access to the Logitech
+ receiver devices.
  .
- To allow access to regular users (through solaar), the needed ACLs can be
- applied, either by the ConsoleKit or systemd daemon, to the current seat
- (logged-in user).
- Right now, ${SEAT_DAEMON_STATUS} daemon is running.
+ If systemd or consolekit are in use, they can apply ACLs to make them
+ accessible via Solaar for the user logged in on the current seat. Right
+ now, ${SEAT_DAEMON_STATUS} daemon is running.
  .
- If neither of these daemons is installed on your system, or you want to make
- the receiver accessible to ssh logged-in through ssh, members of the 'plugdev'
- system group can be given access to the receiver devices.
+ If neither of these daemons is in use, or if the receiver should also be
+ accessible for remotely logged in users, it is possible to grant access
+ for members of the "plugdev" system group.
  .
- If you do use the 'plugdev' group, don't forget to make sure all your desktop
- users are members of the plugdev system group. You can add new members to the
- group by running, as root:
- gpasswd --add  plugdev
- For the group membership to take effect, the affected users have to log-out
- and log-in again.
+ If you do use the "plugdev" group, don't forget to make sure all the
+ appropriate users are members of that group. You can add new members to
+ the group by running, as root:
+ adduser  plugdev
+ For the group membership to take effect, the affected users need to log
+ out and back in again.
--- solaar.old/debian/control   2014-09-17 06:57:04.476944171 +0200
+++ solaar/debian/control   2014-09-22 06:47:00.883782102 +0200
@@ -20,9 +20,9 @@
  python-dbus (>= 1.1.0), upower
 Suggests: gir1.2-appindicator3-0.1, solaar-gnome3 (= ${source:Version})
 Description: Logitech Unifying Receiver peripherals manager for Linux
- Solaar is a Linux device manager for Logitech's Unifying Receiver peripherals.
- It is able to pair/unpair devices to the receiver, and for some devices read
- battery status.
+ Solaar is a Linux device manager for Logitech's Unifying Receiver wireless
+ peripherals. It is able to pair/unpair devices to the receiver, and for
+ some devices to read battery status.
 
 Package: solaar-gnome3
 Architecture: all
@@ -31,9 +31,9 @@
  gir1.2-appindicator3-0.1, gnome-shell (>= 3.4) | unity (>= 5.10),
  ${solaar:Gnome-Icon-Theme}
 Enhances: solaar
-Description: gnome-shell/Unity integration for Solaar

Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime

[Mike Gabriel]

Hi Paul,

On  Di 28 Okt 2014 00:17:55 CET, paul.szabo wrote:


Dear Mike,


I test your patch and it results in several nxproxy crashes ...


You have the new, patched nxproxy on both ends of the connection?
The encoding of the data has changed.

Cheers, Paul


Ah... Good point. No. And this would also be a very rare use case. In  
my test case, I had a new nxproxy on the client-side, but tested  
against a non-patched nxagent (which has libxcomp compiled-in).


nxagent and nxproxy are installed onto different systems from  
different sources (official distro archives, X2Go Client for Windows,  
etc.).


Only nxagent comes from packages.x2go.org, but people might upgrade  
the client-side, but not the server-side and vice versa.


So, this should be handled by your code then, I guess.

Glad we are about to narrow that down, actually.

Greets,
Mike

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgphOo9j7Jt3_.pgp
Description: Digitale PGP-Signatur

Bug#743255: Can not use with Gnus (emacs24)

[Takeshi Soejima]

Dear mainainer,

>   Wrong number of arguments: (lambda (group &optional server fast)
> (nnheader-report (quote nnmhc) "Selected group %s" group)
> (nnheader-insert "211 1 1 1 %s
> " group)), 4

Following patch seems to fix the problem for Gnus in emacs24.
It may also works for other emacsen.

--- /usr/share/emacs/site-lisp/mhc/nnmhc.el 2014-08-20 19:46:25.0 
+0900
+++ nnmhc.el2014-10-28 13:26:10.068187080 +0900
@@ -102,7 +102,7 @@
 (nnheader-report 'nnmhc "Article %s retrieved" id)
 (cons group id))
 
-(deffoo nnmhc-request-group (group &optional server fast)
+(deffoo nnmhc-request-group (group &optional server dont-check info)
   (nnheader-report 'nnmhc "Selected group %s" group)
   (nnheader-insert "211 1 1 1 %s\n" group))


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

Bug#766883: chromium: crashes at startup with "Illegal instruction"

[Michael Gilbert]

On Sun, Oct 26, 2014 at 11:27 AM, Robert Luberda wrote:
> I'm suspecting clang bug #665499 is the cause (however I cannot confirm
> it - even though the code using std::stack still crashes as I described
> in #665499, the code using emplace_back() to vector of int pairs seems
> to work).

Unfortunately chromium upstream decided to no longer support non-sse2
systems, so this isn't a clang bug.

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#767056: Upgrading to openafs-client 1.6.10-1 on systemd fails

[Anders Kaseorg]

Package: openafs-client
Version: 1.6.10-1

# apt-get upgrade openafs-client
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  openafs-client
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,890 kB of archives.
After this operation, 126 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Preconfiguring packages ...
(Reading database ... 253490 files and directories currently installed.)
Preparing to unpack .../openafs-client_1.6.10-1_amd64.deb ...
Unpacking openafs-client (1.6.10-1) over (1.6.9-2) ...
Processing triggers for man-db (2.7.0.2-2) ...
Processing triggers for ureadahead (0.100.0-16) ...
E: Sub-process /usr/bin/dpkg returned an error code (1)

# systemctl status openafs-client -l
● openafs-client.service - OpenAFS client
   Loaded: loaded (/lib/systemd/system/openafs-client.service; enabled)
   Active: active (running) since Tue 2014-10-28 01:00:02 EDT; 35s ago
   CGroup: /system.slice/openafs-client.service
   └─6434 /sbin/afsd -stat 1 -daemons 6 -volumes 200 -afsd-dynroot 
-fakestat

Oct 28 01:00:02 file-control openafs-client[6410]: Starting AFS services: 
openafs afsd.
Oct 28 01:00:02 file-control openafs-client[6410]: afsd: All AFS daemons 
started.
Oct 28 01:00:02 file-control openafs-client[6410]: afsd: All AFS daemons 
started.
Oct 28 01:00:02 file-control openafs-client[6410]: fs: new sysname list set.

# dpkg --configure -a
Setting up openafs-client (1.6.10-1) ...
6441 6434
afsd is already running?
dpkg: error processing package openafs-client (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 openafs-client

# systemctl stop openafs-client

# systemctl status openafs-client -l
● openafs-client.service - OpenAFS client
   Loaded: loaded (/lib/systemd/system/openafs-client.service; enabled)
   Active: failed (Result: resources) since Tue 2014-10-28 01:02:30 EDT; 2s ago

Oct 28 01:00:02 file-control openafs-client[6410]: Starting AFS services: 
openafs afsd.
Oct 28 01:00:02 file-control openafs-client[6410]: afsd: All AFS daemons 
started.
Oct 28 01:00:02 file-control openafs-client[6410]: afsd: All AFS daemons 
started.
Oct 28 01:00:02 file-control openafs-client[6410]: fs: new sysname list set.
Oct 28 01:02:30 file-control systemd[1]: Failed to load environment files: No 
such file or directory
Oct 28 01:02:30 file-control systemd[1]: openafs-client.service failed to run 
'stop' task: No such file or directory
Oct 28 01:02:30 file-control systemd[1]: Failed to load environment files: No 
such file or directory
Oct 28 01:02:30 file-control systemd[1]: openafs-client.service failed to run 
'stop-post' task: No such file or directory
Oct 28 01:02:30 file-control systemd[1]: Unit openafs-client.service entered 
failed state.

# dpkg --configure -a
Setting up openafs-client (1.6.10-1) ...
6441 6434
afsd is already running?
dpkg: error processing package openafs-client (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 openafs-client

# systemctl start openafs-client
Job for openafs-client.service failed. See 'systemctl status 
openafs-client.service' and 'journalctl -xn' for details.

# systemctl status openafs-client -l
● openafs-client.service - OpenAFS client
   Loaded: loaded (/lib/systemd/system/openafs-client.service; enabled)
   Active: failed (Result: resources) since Tue 2014-10-28 01:02:30 EDT; 1min 
27s ago

Oct 28 01:00:02 file-control openafs-client[6410]: Starting AFS services: 
openafs afsd.
Oct 28 01:00:02 file-control openafs-client[6410]: afsd: All AFS daemons 
started.
Oct 28 01:00:02 file-control openafs-client[6410]: afsd: All AFS daemons 
started.
Oct 28 01:00:02 file-control openafs-client[6410]: fs: new sysname list set.
Oct 28 01:02:30 file-control systemd[1]: Failed to load environment files: No 
such file or directory
Oct 28 01:02:30 file-control systemd[1]: openafs-client.service failed to run 
'stop' task: No such file or directory
Oct 28 01:02:30 file-control systemd[1]: Failed to load environment files: No 
such file or directory
Oct 28 01:02:30 file-control systemd[1]: openafs-client.service failed to run 
'stop-post' task: No such file or directory
Oct 28 01:02:30 file-control systemd[1]: Unit openafs-client.service entered 
failed state.
Oct 28 01:03:40 file-control systemd[1]: Failed to load environment files: No 
such file or directory
Oct 28 01:03:40 file-control systemd[1]: openafs-client.service failed to run 
'start-pre' task: No such file or directory
Oct 28 01:03:40 file-control systemd[1]: Failed to start OpenAFS client.

# dpkg --configure -a
Setting up openafs-client (1.6.10-1) ...
6441 6434
afsd is already running?
dpkg: error processing package openafs-client (--configure):
 subprocess installed post-i

Bug#765964: gtk3.14 systray applets have awkward mouse click behaviour (was: Re: Bug#765964: mate-panel: Some notification menus hide on mouse up in notification area)

[Mike Gabriel]

Control: clone -1 -2
Control: reassign -2 libgtk-3-0
Control: retitle -2 gtk3.14 systray applets have awkward mouse click behaviour
Control: severity -2 important

Dear maintainers of GTK3,

we received notification about a change in mouse click behaviour with  
GTK3 applets in mate-panel after upload of GTK3.14 to unstable.


Details, see inline below.

On  So 26 Okt 2014 00:35:42 CEST, Mike Gabriel wrote:


[...]


It seems that only GTK-3 systray applets are affected by the below:

vvv


On  So 19 Okt 2014 19:06:08 CEST, Matthew Horan wrote:



After a recent system update, clicking certain (redshift-gtk,
NetworkManager Applet) notification icons requires a persistent click in
order for the menu to remain open. Previously, all notification menus
remained open on mouse up.



Confusingly, some icons now remain open on mouse up, for example Steam
and MATE's PulseAudio volume control applet.

I would expect all icons to behave the same -- either remain open on
click (right or left click), or close on mouse up.





I observe this, too.

However, my feeling is that it is related to the recent GTK3 version  
bump in Debian (to 3.14). Several GKT3 applets changed their mouse  
interaction behaviour...


The changed occurred within the last two weeks or so. The issue is  
not mate-panel related, but depends on other things I currently lack  
to oversee.


Any idea, what this bug can be reassigned to?


I carried this around for another day or two and came to the  
conclusion, that this needs to be discussed with the libgtk-3  
maintainers.


Obviously, there has been a change in how systray applets get handled  
(mouse-wise) in GTK3.14. This change results in two classes of system  
tray applets. From a usability point of view, we as Debian maintainers  
should avoid this.


Unfortunately, with the GNOMEv3 desktop shell, the systray applets  
have been squeezed into some non-usable widget thing (it could be  
accessed at the right-bottom part of the desktop with wheezy, not  
tested with jessie, so far) in favour of appindicator implementations.


However, libgtk-3 is not GNOMEv3, so I would love to work together on  
a fix that provides some legacy systray applet mouse behaviour for  
non-GNOME desktop shells (I guess LXDE, XFCE, etc. are also affected  
by this, so I have Cc:ed them).


Thanks,
Mike


--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpW9T_ve3700.pgp
Description: Digitale PGP-Signatur

Bug#766758: ekiga is half-installed

[Guillem Jover]

Hi!

On Mon, 2014-10-27 at 04:11:33 +0100, Vincent Lefevre wrote:
> On 2014-10-27 02:44:38 +0100, Guillem Jover wrote:
> > Let's lower this for now, as this is certainly not critical in any
> > way, and I don't think it's serious for now, too many unknowns, but
> > I'll bump it again if it happens to be so.
> 
> IMHO, it would be bad if it affected stable.

It would be an undesirable regression sure, I want to understand
what's going on first. It could be an issue in how apt invokes dpkg,
that only showed up now that triggers are only processed when they
have their dependencies satisfied.

In any case, I want to see 1.17.21 migrate first, and then if this is
a regression in dpkg I'll be immediately uploading .22 with a fix for
it, and requesting an unblock for just .22 to the release team. I don't
want to have to deal with a request to unblock 1.17.13..1.17.22 at all,
TBH.

> > On Mon, 2014-10-27 at 02:14:32 +0100, Vincent Lefevre wrote:
> > > I've just upgraded another machine, and:
> [...]
> > > So, this is similar to the other one.
> > 
> > Ok, I know you set the version affecting the other system to 1.17.21,
> > but is this one too that version? was it upgraded to that on the same
> > upgrade run?
> 
> 1.17.21 too, because I had upgraded dpkg first, then upgraded
> everything else later.

Yes, I've got now a reliable reproducer on my kfreebsd-amd64 system.
It's not processing the man-db triggers because libpipeline1 is not
configured yet, but I don't know yet why it's not marked as being
configured in that run. I'll be checking how apt is calling dpkg
tomorrow, so see where this fails.

> > Just installing and reinstalling ekiga here does not reproduce that.
> > Could you backup that dpkg status file anyway, and check if
> > «dpkg --configure -a» fixes it for you?
> 
> # dpkg --configure -a
> Setting up gconf2 (3.2.6-3) ...
> Setting up man-db (2.7.0.2-2) ...
> Building database of manual pages ...
> Setting up ekiga (4.0.1-5) ...
> Processing triggers for menu (2.1.47) ...
> 
> which fixes the problem.

Yeah, so while quite annoying, this is actually just self-healing,
which is good.

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#766819: [pkg-cinnamon] Bug#766819: cinnamon freezes for a minute or so, when opening images or text with gnome/gtk apps and when closing them later on

[Christoph Anton Mitterer]

I was still busy today with the #766943 so I've only had limited time
for this.

What I just tried now was re-enabling openafs-client,... rebooting and
then opening these images/text again.

The issue doesn't re-appear as extreme as it did last time (where the
system froze for 30s-1m)... but even now it still happens,... e.g. I
open an image then I see that the change from the clock applet from
one to the next second takes too long (roughly 2 secs than 1)... but it
continues counting for 3-5 seconds then and then it jumps over one
second (i.e. the one that was lost).

The same happens again reproducibly with eog, evince, gedit and
friends

Since I suspsect gvfs is somehow involved, I've tried killing it, but as
soon as I start eog/evince/etc, a new gvfsd is spawned (any way to
prevent this?)


Next (with a gvfsd running again) I've umounted /afs... after that, no
delay in the clock occurs anymore, when I start eog/evince/etc.


So wildly guessing,... gvfs or something like that tries to be smart and
listens/polls/queries on places where it shouldn't (in this case AFS)...
when something goes wrong there,... gvfs freezes,... and this in turn
lead eog/cinnamon and friends to freeze?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#766901: patch to get fail2ban reports back

[Yaroslav Halchenko]

Package: logwatch
Version: 7.4.1-1
Followup-For: Bug #766901

Please find attached the patch for making logwatch catching again fail2ban
reports on bans/unbans.  I also pushed corresponding changes (as an NMU) to the
collab git repository under tent/fail2ban-0.9  branch.  Willi, would you be
kind to push them through or bless me for doing so?

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

Kernel: Linux 3.16-3-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/bash
From: Yaroslav Halchenko 
Subject: Make compatible with Fail2ban 0.9.x series

also includes some white-spaces (non-functional) changes to harmonize
indentation

Forwarded:   not yet -- please do!
Last-Update: 2014-10-28

--- a/scripts/services/fail2ban
+++ b/scripts/services/fail2ban
@@ -1,7 +1,14 @@
+#!/usr/bin/perl
 ##
-# $Id: fail2ban 226 2014-09-09 11:07:27Z stefjakobs $
+# $Id: fail2ban 150 2013-06-18 22:19:38Z mtremaine $
 ##
 # $Log: fail2ban,v $
+#
+# Revision 1.6  2014/08/11 16:07:46  yoh
+# Patches from Yaroslav Halchenko to match adjusted in 0.9.x lines.
+# Also reports now total number of hits (matches) along with Ban:Unban
+# and relaxed regular expressions for matching any log level
+#
 # Revision 1.5  2008/08/18 16:07:46  mike
 # Patches from Paul Gear  -mgt
 #
@@ -45,132 +52,150 @@ my $Detail = $ENV{'LOGWATCH_DETAIL_LEVEL
 my $IgnoreHost = $ENV{'sshd_ignore_host'} || "";
 my $DebugCounter = 0;
 my $ReInitializations = 0;
-my @IptablesErrors = ();
-my @ActionErrors = ();
-my $NotValidIP = 0;		# reported invalid IPs number
+my @ActionsErrors = ();
+my @CommandsErrors = ();
+my $NotValidIP = 0; # reported invalid IPs number
 my @OtherList = ();
 
 my %ServicesBans = ();
 
 if ( $Debug >= 5 ) {
-	print STDERR "\n\nDEBUG: Inside Fail2Ban Filter \n\n";
-	$DebugCounter = 1;
+   print STDERR "\n\nDEBUG: Inside Fail2Ban Filter \n\n";
+   $DebugCounter = 1;
 }
 
 while (defined(my $ThisLine = )) {
-if ( $Debug >= 5 ) {
-	print STDERR "DEBUG($DebugCounter): $ThisLine";
-	$DebugCounter++;
-}
-chomp($ThisLine);
-if ( ($ThisLine =~ /..,... DEBUG: /) or
-	 ($ThisLine =~ /..,... \S*\s*: DEBUG /) or # syntax of 0.7.? fail2ban
-	 ($ThisLine =~ /..,... INFO: (Fail2Ban v.* is running|Exiting|Enabled sections:)/) or
-	 ($ThisLine =~ /INFO\s+Log rotation detected for/) or
-	 ($ThisLine =~ /INFO\s+Jail.+(?:stopped|started|uses poller|uses pyinotify)/) or
-	 ($ThisLine =~ /INFO\s+Changed logging target to/) or
-	 ($ThisLine =~ /INFO\s+Creating new jail/) or
-	 ($ThisLine =~ /..,... \S+\s*: INFO\s+(Set |Socket|Exiting|Gamin|Created|Added|Using)/) or # syntax of 0.7.? fail2ban
-	 ($ThisLine =~ /..,... WARNING: Verbose level is /) or
-	 ($ThisLine =~ /..,... WARNING: Restoring firewall rules/) or
-	 ($ThisLine =~ /WARNING Determined IP using DNS Lookup: [^ ]+ = \['[^']+'\]/) or
-	 ($ThisLine =~ /INFO\s+(Stopping all jails|Exiting Fail2ban)/) or
-	 ($ThisLine =~ /INFO\s+Initiated 'pyinotify' backend/) or
-	 ($ThisLine =~ /INFO\s+(Added logfile = .*|Set maxRetry = \d+|Set findtime = \d+|Set banTime = \d+)/)
+   if ( $Debug >= 5 ) {
+  print STDERR "DEBUG($DebugCounter): $ThisLine";
+  $DebugCounter++;
+   }
+   chomp($ThisLine);
+   if ( ($ThisLine =~ /..,... DEBUG: /) or
+($ThisLine =~ /..,... \S*\s*: DEBUG /) or # syntax of 0.7.? fail2ban
+($ThisLine =~ /..,... \S+: (Fail2Ban v.* is running|Exiting|Enabled sections:)/) or
+($ThisLine =~ /\S+\s+rollover performed on/) or
+($ThisLine =~ /\S+\s+Connected to .* persistent database/) or
+($ThisLine =~ /\S+\s+Jail '.*' uses .*/) or
+($ThisLine =~ /\S+\s+Initiated '.*' backend/) or
+($ThisLine =~ /\S+\s+Jail .* is not a JournalFilter instance/) or
+($ThisLine =~ /\S+\s+Log rotation detected for/) or
+($ThisLine =~ /\S+\s+Jail.+(?:stopped|started|uses poller)/) or
+($ThisLine =~ /\S+\s+Changed logging target to/) or
+($ThisLine =~ /\S+\s+Creating new jail/) or
+($ThisLine =~ /..,... \S+\s*: INFO\s+(Set |Socket|Exiting|Gamin|Created|Added|Using)/) or # syntax of 0.7.? fail2ban
+($ThisLine =~ /..,... \S+: Verbose level is /) or
+($ThisLine =~ /..,... \S+: Restoring firewall rules/)
)
-{
-	if ( $Debug >= 6 ) {
-	print STDERR "DEBUG($DebugCounter): line ignored\n";
-	}
-} elsif ( my ($Service,$Action,$Host) = ($ThisLine =~ m/(?:WARNING|NOTICE):?\s\[?(.*?)[]:]?\s(Ban|Unban)[^\.]* (\S+)/)) {
-	if ( $Debug >= 6 ) {
-	print STDERR "DEBUG($DebugCounter): Found $Action for $Service from $Host\n";
-	}
-	$ServicesBans{$Service}{$Host}{$Action}++;
-	$ServicesBans{$Service}{"(all)"}{$Action}++;
-} elsif ( my ($Service,$H

Bug#744114: with-session-tracking=systemd vs with-session-tracking=consolekit

[Carlos Alberto Lopez Perez]

Probably those of you that don't want to install systemd but want a
working network manager would find this information useful:

* I rebuilt network-manager with the following patch:
http://paste.debian.net/plain/128994

* Also followed the following howto:
http://jeffhoogland.blogspot.com.es/2012/05/howto-give-network-manager-sufficient.html

After that I was able to successfully run network-manager without
systemd, libpam-systemd, logind or anythingd


I think the following upstream bug is relevant:
https://bugzilla.gnome.org/show_bug.cgi?id=686997



signature.asc
Description: OpenPGP digital signature

Bug#298362: xqf: Please include higher-resolution icons

[Thomas DEBESSE]

Hi, this bug can be closed since XQF 1.0.6 ship a scalable SVG icon.

-- 
Thomas DEBESSE

Bug#766982: RFS: plowshare4/1.0.6-1

[Paul Wise]

On Tue, 2014-10-28 at 14:01 +1100, Carl Suster wrote:

> I'm not sure what you're referring to here - `licensecheck
> --copyright` and grep both seem to agree with the information in
> d/copyright with only two differences: (1) I changed the aliases in
> the copyright headers to the contributors' full names from the vcs 

I guess (1) is what I was seeing. In that case plowshare4 is probably
ready for upload, I would encourage your previous sponsor (CCed) to
upload the package.

Since we are now less than 10 days until the freeze, your upload should
be targeted at experimental not unstable. Once jessie is released then
you can get it uploaded to unstable again.

> The tests as far as I can see are intended to check for changes in the
> APIs of the various file hosts rather than to test if the code has
> installed properly. It seems like more of a developers' diagnostic
> than something which should be run automatically so I didn't include
> it.

Those are exactly the kind of tests one would want to run with DEP-8 for
packages that interface with Internet services.

> > You might want to add some debtags:
> > 
> > http://debtags.debian.net/edit/plowshare4
> 
> Done.

I'd suggest going through the all tags section and adding anything
appropriate. For example use::downloading seems appropriate.

> I didn't realise that this was relevant to CLI applications. I'll add
> a screenshot.

Anything with a human-facing interface is relevant to screenshots.d.n.

> > P: plowshare4: no-upstream-changelog
> 
> I wasn't sure what to do about this, any my previous sponsor said to
> ignore it. Upstream has a wiki page summarising significant changes
> (https://code.google.com/p/plowshare/wiki/PlowshareChanges) but that's
> currently sorted by month rather than version and not contained in the
> source at all. Should I maintain a separate upstream changelog even
> though they don't include one? Or just try and ask upstream to add it
> to the source?

Fair enough if you prefer to ignore it, other options:

Convince upstream to add a NEWS file containing releases and the
user-visible changes in each of them.

https://www.gnu.org/prep/standards/html_node/NEWS-File.html#NEWS-File

Convert the git history to a ChangeLog file using git2cl or git log.

https://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs
https://packages.debian.org/sid/git2cl

> Thanks for pointing me to this tool. I'll prepare and forward a patch.

codespell can auto-fix spelling errors BTW (-w/--write-changes).

> I'm not sure that this check is relevant since all of the output is
> about perl and this project is pure bash shell script.

Hmm, true. That would seem to be a bug in perlcritic, it shouldn't
assume that the tests/*.t files are perl tests. Not sure if there is a
way to fix this though.

> I'll check through this output, but there is the fact that these shell
> scripts depend on bash behaviour rather than POSIX shell so perhaps
> much of this is not relevant or overly defensive.

I believe shellcheck understands that there are different variants of
the shell language, at least the upstream website has some things that
are bash-only syntax that it checks for.

> Is this necessarily an issue? The project is being actively developed
> and these are just notes that will be addressed in the future but are
> not critical for the time being.

Not necessarily but it would be good to review them to make sure that
none are indicative of serious issues.

> I'll address all of these points properly in the package in the coming
> days when I get a chance. Thanks again for your review.

Great, no worries.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#766827: dlz_dlopen.h missing from libbind-dev

[Michael Gilbert]

control: severity -1 important

On Sun, Oct 26, 2014 at 2:25 AM, Daniel Pocock wrote:
> Users are complaining that dlz-ldap-enum is not working again
>
>http://list.resiprocate.org/archive/repro-users/msg00780.html
>
> I had a quick look and I notice that dlz_dlopen.h is still not installed
> by the libbind-dev package.

I think --with-dlz-ldap=yes is probably a currently missing configure
flag that would support that  Can you try and see if it is a solution?

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#767054: ifconfig: doesn't show secondary v4 addresses (but shows secondary v6)

[Christoph Anton Mitterer]

Package: net-tools
Version: 1.60-26
Severity: normal


Hey.

Not sure if this is intended/expected, but it seems that while ifconfig
shows secondary IPv6 addresses, it doesn't show secondary v4 addresses:

e.g.:
# ip addr show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 00:19:db:32:06:7f brd ff:ff:ff:ff:ff:ff
inet 11.22.33.199/27 brd 11.22.33.223 scope global eth0
   valid_lft forever preferred_lft forever
inet 11.22.33.204/27 brd 11.22.33.223 scope global secondary eth0
   valid_lft forever preferred_lft forever
inet 11.22.33.211/27 brd 11.22.33.223 scope global secondary eth0
   valid_lft forever preferred_lft forever
inet 11.22.33.214/27 brd 11.22.33.223 scope global secondary eth0
   valid_lft forever preferred_lft forever
inet6 aa:bb:cc:dd::c:1000/64 scope global deprecated 
   valid_lft forever preferred_lft 0sec
inet6 aa:bb:cc:dd::c:0/64 scope global deprecated 
   valid_lft forever preferred_lft 0sec
inet6 aa:bb:cc:dd::b:0/64 scope global deprecated 
   valid_lft forever preferred_lft 0sec
inet6 aa:bb:cc:dd::a:0/64 scope global deprecated 
   valid_lft forever preferred_lft 0sec
inet6 aa:bb:cc:dd::2:2/64 scope global deprecated 
   valid_lft forever preferred_lft 0sec
inet6 aa:bb:cc:dd::2:0/64 scope global deprecated 
   valid_lft forever preferred_lft 0sec
inet6 aa:bb:cc:dd::1:0/64 scope global 
   valid_lft forever preferred_lft forever
inet6 fe80::219:dbff:fe32:67f/64 scope link 
   valid_lft forever preferred_lft forever




# ifconfig 
eth0  Link encap:Ethernet  HWaddr 00:19:db:32:06:7f  
  inet addr:11.22.33.199  Bcast:11.22.33.223  Mask:255.255.255.224
  inet6 addr: aa:bb:cc:dd::1:0/64 Scope:Global
  inet6 addr: aa:bb:cc:dd::b:0/64 Scope:Global
  inet6 addr: fe80::219:dbff:fe32:67f/64 Scope:Link
  inet6 addr: aa:bb:cc:dd::a:0/64 Scope:Global
  inet6 addr: aa:bb:cc:dd::2:2/64 Scope:Global
  inet6 addr: aa:bb:cc:dd::2:0/64 Scope:Global
  inet6 addr: aa:bb:cc:dd::c:1000/64 Scope:Global
  inet6 addr: aa:bb:cc:dd::c:0/64 Scope:Global
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:4237 errors:0 dropped:0 overruns:0 frame:0
  TX packets:5063 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:1132860 (1.0 MiB)  TX bytes:3513622 (3.3 MiB)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:1905 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1905 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:1782284 (1.6 MiB)  TX bytes:1782284 (1.6 MiB)





The above uses this /e/n/interfaces:
allow-auto  lo
allow-auto  eth0


iface lo inet loopback

iface eth0 inet static
address 11.22.33.199
netmask 255.255.255.224
gateway 11.22.33.193

iface eth0 inet static
address 11.22.33.204
netmask 255.255.255.224
iface eth0 inet static
address 11.22.33.211
netmask 255.255.255.224
iface eth0 inet static
address 11.22.33.214
netmask 255.255.255.224

iface eth0 inet6 static
address aa:bb:cc:dd::1:0
netmask 64
gateway fe80::1

iface eth0 inet6 static
address aa:bb:cc:dd::2:0
netmask 64
preferred-lifetime  0
iface eth0 inet6 static
address aa:bb:cc:dd::2:2
netmask 64
preferred-lifetime  0
iface eth0 inet6 static
address aa:bb:cc:dd::A:0
netmask 64
preferred-lifetime  0
iface eth0 inet6 static
address aa:bb:cc:dd::B:0
netmask 64
preferred-lifetime  0
iface eth0 inet6 static
address aa:bb:cc:dd::C:0
netmask 64
preferred-lifetime  0
iface eth0 inet6 static
address aa:bb:cc:dd::C:1000
netmask 64
preferred-lifetime  0


(I changed the addresses for privacy reasons).


Cheers,
Chris.


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

Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores)
Locale:

Bug#766943: systemd: server no longer gets networking after switching to systemd

[Christoph Anton Mitterer]

Oh and I should perhaps add:

With allow-auto AND the sleep: all services find their addresses and
start up correctly.

With allow-auto WITHOUT the sleep,... well when waiting for my script to
restart the networking, then of course no service (but ssh, which I've
restarted from the script) was running correctly.
But before I had my script in place, I got back access to the machine by
simply n-times rebooting it via Ctrl-Alt-Del signal from the hosters
web-interfaces... and after a so 5-15 reboots it usually worked once to
at least have ssh back... but even then only *some* services (luckily
including ssh) were running... others (especially bind and apache)
always failed then too (probably because IPv6 was still not yet in place
but only IPv4, which explains why sks started up, as it doesn't fail
when it cannot bind to all addresses).

With allow-hotplug (and without the sleep) I also had some services not
staring up (as I wrote already last night).


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#750011: gnome-tweak-tool: Windows Scaling Not Undoable

[Raphael]

I accidently changed the setting too and was unable, in the first place, to 
revert my change However I found a workaround: 

In the tweak-tool window, click the magnifier icon (search option), then input 
’scaling’ in the text field. That will display only options for which the name 
matches the word ‘scaling’. Now click the entry Windows from the menu... then 
the option Window Scaling will be located up the content pane and I could edit 
it back to 1.

 

I search for that option in dconf-editor but didn’t see it does someone 
know whether this option is accessible from dconf?

 

Cheers

Raphael

 

On Tue, 07 Oct 2014 21:58:10 -0500 Alex Robbins  
wrote:
> I did the exact same thing on a recently-upgraded Jessie installation 
> and got the exact same results.  I agree that there should be some kind 
> of timeout like the one for changing display resolution, and for the 
> same reason: unwittingly changing the setting to something inappropriate 
> can make it very difficult to change it back to something sane.
> 
> For anyone else who ends up in this situation, I bet there's a gsettings 
> command that could be run via a virtual terminal, but I don't know the 
> schema or key.  Something like:
> > DISPLAY=':0.0' gsettings reset org.gnome.desktop.interface scaling-factor
> 
> but replace "org.gnome.desktop.interface scaling-factor" with the right 
> schema and key (because I'm pretty sure that isn't it, although it may 
> look like it).  Perhaps someone more knowledgeable can elaborate (or fix 
> the bug)...
> 
> Thanks,
> Alex Robbins
> 
>

Bug#758747: silly: autoreconf to update config.{sub, guess} and aclocal.m4 to fix FTBFS for new arches

[Wookey]

Package: src:silly
Followup-For: Bug #758747

silly is also FTBFS on arm64:
https://buildd.debian.org/status/fetch.php?pkg=silly&arch=arm64&ver=0.1.0-3&stamp=1408660002

I have updated this patch a little to not need automake1.11 or the
NEWS & README creation just to keep autofoo happy. It tests fine on
arm64 and is almost certainly fine on ppc64el too.

The package could use some more updating of configure.ac to modern
macros to remove warnings and future-proof, but the packages come out
correctly so it'll do as it is.

As this bug has been around for a couple of months and the freeze
approaches fast I have NMUed this to delayed/4. Hope that's OK.
diff -Nru silly-0.1.0/debian/changelog silly-0.1.0/debian/changelog
--- silly-0.1.0/debian/changelog	2012-04-10 12:22:59.0 +
+++ silly-0.1.0/debian/changelog	2014-10-28 03:19:49.0 +
@@ -1,3 +1,10 @@
+silly (0.1.0-3.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Use dh-autoreconf on build for new architectures (Closes: 758747)
+
+ -- Wookey   Tue, 28 Oct 2014 01:54:16 +
+
 silly (0.1.0-3) unstable; urgency=low
 
   * debian/control:
diff -Nru silly-0.1.0/debian/control silly-0.1.0/debian/control
--- silly-0.1.0/debian/control	2012-04-10 11:21:56.0 +
+++ silly-0.1.0/debian/control	2014-10-28 03:20:36.0 +
@@ -2,7 +2,7 @@
 Priority: extra
 Maintainer: Muammar El Khatib 
 Build-Depends: debhelper (>= 7), autotools-dev, libpng-dev, libjpeg-dev,
-   doxygen, pkg-config
+   doxygen, pkg-config, dh-autoreconf
 Standards-Version: 3.9.3
 Section: libs
 Homepage: http://www.cegui.org.uk
diff -Nru silly-0.1.0/debian/patches/autoreconf-fixups.patch silly-0.1.0/debian/patches/autoreconf-fixups.patch
--- silly-0.1.0/debian/patches/autoreconf-fixups.patch	1970-01-01 00:00:00.0 +
+++ silly-0.1.0/debian/patches/autoreconf-fixups.patch	2014-10-28 03:19:49.0 +
@@ -0,0 +1,13 @@
+Index: silly-0.1.0/configure.ac
+===
+--- silly-0.1.0.orig/configure.ac	2006-11-05 14:03:06.0 +
 silly-0.1.0/configure.ac	2014-10-28 02:42:15.251984601 +
+@@ -22,7 +22,7 @@
+ AC_CANONICAL_BUILD
+ AC_CANONICAL_HOST
+ AC_CANONICAL_TARGET
+-AM_INIT_AUTOMAKE([pkg_name], [pkg_version])
++AM_INIT_AUTOMAKE([foreign])
+ AC_CONFIG_HEADERS([config.h])
+ AC_CONFIG_HEADERS([include/SILLYOptions.h])
+ AC_CONFIG_SRCDIR([src/SILLYImage.cpp])
diff -Nru silly-0.1.0/debian/patches/series silly-0.1.0/debian/patches/series
--- silly-0.1.0/debian/patches/series	2012-04-10 11:07:25.0 +
+++ silly-0.1.0/debian/patches/series	2014-10-28 03:19:49.0 +
@@ -1 +1,2 @@
 01_SILLYPNGImageLoader.patch
+autoreconf-fixups.patch
diff -Nru silly-0.1.0/debian/rules silly-0.1.0/debian/rules
--- silly-0.1.0/debian/rules	2011-07-23 19:12:32.0 +
+++ silly-0.1.0/debian/rules	2014-10-28 03:19:49.0 +
@@ -19,7 +19,8 @@
 CFLAGS += -O2
 endif
 
-config.status: configure
+config.status:
+	dh_autoreconf 
 	dh_testdir
 	# Add here commands to configure the package.
 	./configure --prefix=/usr --libdir=/usr/lib --includedir=/usr/include 
@@ -36,6 +37,7 @@
 	touch build-stamp
 
 clean:
+	dh_autoreconf_clean
 	dh_testdir
 	dh_testroot
 	rm -f build-stamp
@@ -57,7 +59,7 @@
 
 	# Add here commands to install the package into debian/
 	$(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
-	
+
 
 # Build architecture-independent files here.
 binary-indep: build install

Bug#767053: RM: liblwjgl-java-jni [sparc] -- ROM; no openjdk-7 on sparc

[Michael Gilbert]

package: ftp.debian.org
severity: normal

Please remove liblwjgl-java-jni from sparc.  It's openjdk-7-jdk
build-dependency is no longer available for that architecture.

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#767051: libjinput-java: uninstallable on kfreebsd

[Michael Gilbert]

package: libjinput-java
severity: serious
version: 20100502+dfsg-7

This package currently depends on libjinput-jni, which is currently
not build on the kfreebsds (#657771), so the libjinput-java is
uninstallable on those architectures.

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#767050: ITP: tachyon-doc-extra -- Parallel/Multiprocessor Ray Tracing Software -- extra documents

[Jerome Benoit]

Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: tachyon-doc-extra
  Version : 0.0.1
  Upstream Author : Jerome Benoit 
* URL : none
* License : Public Domain
  Programming Lang: raw data
  Description : Parallel/Multiprocessor Ray Tracing Software -- extra 
documents

 Tachyon is a portable, high performance parallel ray tracing system
 supporting MPI and multithreaded implementations.  Tachyon is built
 as a C callable library, which can be used with the included demo
 programs or within your own application.  The distribution also
 includes a simple scene file parser front-end which reads a few
 different formats.
 .
 Tachyon implements all of the basic geometric primitives such as
 triangles, planes, spheres, cylinders, etc.  Some of the goals in
 developing Tachyon were to make it fast and for it to parallelize
 well.  These are what set it apart from more full-featured programs
 like POV-Ray, Rayshade, and others.  Tachyon supports enough features
 to be an excellent alternative to slower programs for demanding
 animation and scientific visualization tasks.  As time goes on,
 Tachyon will indeed incorporate more features, but with a continued
 emphasis on rendering performance.
 .
 This package provides extra (large) documents needed by some scene or
 C source examples provided in the tachyon-doc package.


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

Bug#754377: not visible with systemd

[Holger Levsen]

control: severity -1 important

Hi,

i've rescheduled eeepc-acpi-scripts for re-testing in a current sid and 
installation was successfully:
https://piuparts.debian.org/sid/pass/eeepc-acpi-scripts_1.1.12.log

Keeping the bug open as I suppose it still happens if one chooses sysv as init 
system and then installs eeepc-acpi-scripts...


cheers,
Holger


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

Bug#766982: RFS: plowshare4/1.0.6-1

[Carl Suster]

Control: tags -1 + pending

Hi Paul,

Thanks very much for the thorough review.


> This looks like the only thing that would block the upload:
> 
> Some of the copyright holders are missing from debian/copyright.

I'm not sure what you're referring to here - `licensecheck --copyright` and 
grep both seem to agree with the information in d/copyright with only two 
differences: (1) I changed the aliases in the copyright headers to the 
contributors' full names from the vcs and (2) the year range for the copyrights 
attributed to Plowshare Team vary somewhat between headers where upstream 
hasn't updated those files in a while. Everyone seems to be attributed though 
as far as I can tell.


> Whoa that is a lot of shell. shellcheck says it is probably
> buggy/insecure shell too. Personally Python seems a better choice for
> writing this sort of software but I guess upstream wouldn't want to
> rewrite everything...

Yeah, the 4 in plowshare4 refers to a rewrite based on bash 4 that happened not 
too long ago. They're unlikely to want to rewrite the whole thing for the 
moment but it may happen in the future, I suppose.


> Upstream might want to switch from their homebrew version stuff to 
> autorevision:
> 
> https://packages.debian.org/sid/autorevision
> 
> Is there any reason for not using the upstream `make install` target?
> It seems to be very much correct. The only issue might be the git
> version stuff but you can override that with GIT_VERSION until
> upstream switches to autorevision (or if they do not want to).

Thanks, I didn't know about autorevision so I'll have a go with it and talk to 
upstream. I had problems getting the upstream makefile to pick up the correct 
version string from the vcs and eventually found it much simpler to use d/rules 
overrides instead. I'll see if upstream is willing to accept some changes to 
tidy up the makefile so that I can use it in the package unchanged.


> I would suggest running `wrap-and-sort -sa` so that diffs of the
> source package are easier to read.

I had used wrap-and-sort but without the -sa. I'll change that.


> The README, plowup manual page and Makefile use of /tmp in various
> examples. Using /tmp can cause vulnerabilities on multi-user systems
> or systems where an attacker has a shell and is looking to escalate
> that access. It would be better for the examples to use a path in the
> home directory using ~/ or $HOME depending on the example.

Thanks, I'll add a patch and forward it upstream.


> Upstream has some tests but the build does not run them. Is that
> because they require network to work? Network can't be used on the
> buildds but you could run them using DEP-8:
> 
> http://dep.debian.net/deps/dep8/
> http://ci.debian.net/

The tests as far as I can see are intended to check for changes in the APIs of 
the various file hosts rather than to test if the code has installed properly. 
It seems like more of a developers' diagnostic than something which should be 
run automatically so I didn't include it.


> You might want to add some upstream metadata:
> 
> https://wiki.debian.org/UpstreamMetadata

Thanks, I'll look into this.

 
> You might want to add a watch file:
> 
> https://wiki.debian.org/debian/watch
> https://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=vcs/git/google/plowshare

Thanks! I tried for ages to get uscan to interact properly with googlecode but 
it didn't play nicely since the version information was only in the vcs tags. I 
didn't know about this fakeupstream.cgi so it should be easy now.


> You might want to add some debtags:
> 
> http://debtags.debian.net/edit/plowshare4

Done.


> You might want to add some screenshots of typical usage:
> 
> https://screenshots.debian.net/upload/plowshare4

I didn't realise that this was relevant to CLI applications. I'll add a 
screenshot.


> P: plowshare4: no-upstream-changelog

I wasn't sure what to do about this, any my previous sponsor said to ignore it. 
Upstream has a wiki page summarising significant changes 
(https://code.google.com/p/plowshare/wiki/PlowshareChanges) but that's 
currently sorted by month rather than version and not contained in the source 
at all. Should I maintain a separate upstream changelog even though they don't 
include one? Or just try and ask upstream to add it to the source?


> $ cme check dpkg
> ...
> Warning in 'control binary:plowshare4 Depends:0' value 'bash (>=4.1)':
> unnecessary versioned dependency: bash >= 4.1. Debian has squeeze ->
> 4.1-3; squeeze-lts -> 4.1-3+deb6u2; wheezy-security ->
> 4.2+dfsg-0.1+deb7u3; wheezy -> 4.2+dfsg-0.1+deb7u3; jessie -> 4.3-11;
> sid -> 4.3-11;

Done. 


> $ codespell --quiet-level=3
> ./src/probe.sh:25: HELPFULL  ==> HELPFUL
> ./src/probe.sh:279: HELPFULL  ==> HELPFUL
> ./src/download.sh:25: HELPFULL  ==> HELPFUL
> ./src/download.sh:758: HELPFULL  ==> HELPFUL
> ./src/download.sh:865: sucessive  ==> successive
> ./src/list.sh:25: HELPFULL  ==> HELPFUL
> ./src/list.sh:182: HELPFULL  ==> HELPFUL
> ./s

Bug#738848: osc: refuses to communicate with API server over IPv6

[Paavo Hartikainen]

Test I just described was performed with "osc 0.149.0-1".


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

Bug#766943: systemd: server no longer gets networking after switching to systemd

[Christoph Anton Mitterer]

On Mon, 2014-10-27 at 13:55 +0100, Andrew Shadura wrote: 
> /etc/init.d/networking doesn't check for systemd or anything, and it
> works fine with sysv-rc, so this probably not a bug in ifupdown, but
> in systemd.
Well... I still suspect that something *is* fishy here... I mean the
other two bugs against ifupdown that I've reported before, imply
that... 
- IPv6 not ready for services (but IPv4 is) when allow-hotplug is used
- DHCP not working when allow-auto is used

That's all a bit strange... :/


But from the log output that I've sent before it rather looks, that with
allow-auto (+systemd) there is no eth0 brought up at all (and not only
too late), cause in the first "ifconfig before stage 1" it only has lo
up.

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#766943: systemd: server no longer gets networking after switching to systemd

[Christoph Anton Mitterer]

On Mon, 2014-10-27 at 13:51 +0100, Michael Biebl wrote: 
> allow-auto is a synonym for auto.
Sure, I know,... I just do it for cosmetic reasons ^^

> The ifup@.service unit, as shipped by systemd, only deals with
> "allow-hotplug" interfaces.
Ah? Okay... interesting,... didn't know that...

This is probably unrelated to this bug, but the whole networking stuff
seems to be kinda mess right now (at least to people not deeper involved
in both (ifupdown + systemd)... we still have networking.service, we
have network.target, we have the ifup@.service... and I'm sure NM also
has some service file (though I couldn't find it too hook in before
network.target...

Shouldn't the legacy sysvinit scripts go away,... and everything
(including allow-auto/auto) be handled by a unit file proper?


> "auto" interfaces are handled by /etc/init.d/networking, which is
> shipped by ifupdown. Therefore re-assigning to ifupdown.
Well as I've noted in my mails from yesterday... even with allow-hotplug
there are still several things that don't work (i.e. services are being
started before they can bind to the addresses)...
Isn't this then something in systemd? Or is it rather a problem in the
respective service's unit files? But at least apache and sks still use
sysvinit legacy mode... so it probably cannot be their fault.



Yesterday I've told you that I placed some cron job which is meant to
restart the network+ssh every 10 minutes or so... and if this doesn't
work he changes /e/n/interfaces to allow-hotplug and reboots.

Attached is that script + it's logs, so that you can see what happens
from that side.
It's basically doing this:
network-restarter.log is the main log, here with entries from two runs:
1st run: when the system was up and I connected to it and changed to
allow-auto, but networking was still ok

then I rebooted, the system did boot, but networking didn't come up
again

2nd run: the script found that networking is down, and tried several
things to bring it up again,... the output from these things and from
ifconfig is in network-restarter.log.2.



> Regarding logs: It would probably be helpful to boot with
> systemd.log_level=debug and attach the output of journalctl -alb
all attached + syslog from the last n runs... not sure if all the
previous tries are helpful though,..
I did replace some privacy related stuff (ip addresses, domain names)...
hopefully I didn't miss some private keys in my logs ;)

>  and
> specifically the output of systemctl status networking.service.
this is in the network-restarter.log.2


Cheers,
Chris.


network-restarter
Description: application/shellscript

cron run Tue Oct 28 03:35:55 CET 2014
stage 1: OK
stage 2: OK

cron run Tue Oct 28 03:40:01 CET 2014
ifdown:0
ifup:0
networking restart:0
ssh:0
stage 2: OK
Tue Oct 28 03:40:01 CET 2014
*** ifconfig before stage 1 **
loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:672 errors:0 dropped:0 overruns:0 frame:0
  TX packets:672 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:55584 (54.2 KiB)  TX bytes:55584 (54.2 KiB)

*** networking.service status before stage 1 *
● networking.service - LSB: Raise network interfaces.
   Loaded: loaded (/etc/init.d/networking)
  Drop-In: /run/systemd/generator/networking.service.d
   └─50-insserv.conf-$network.conf
   Active: active (exited) since Tue 2014-10-28 03:38:15 CET; 1min 46s ago
  Process: 366 ExecStart=/etc/init.d/networking start (code=exited, 
status=0/SUCCESS)

Oct 28 03:38:15 kronecker systemd[1]: networking.service got final SIGCHLD for 
state start
Oct 28 03:38:15 kronecker systemd[1]: networking.service changed start -> 
running
Oct 28 03:38:15 kronecker systemd[1]: Job networking.service/start finished, 
result=done
Oct 28 03:38:15 kronecker systemd[1]: Started LSB: Raise network interfaces..
Oct 28 03:38:15 kronecker ntpdate[629]: Can't find host ptbtime1.ptb.de: Name 
or service not known (-2)
Oct 28 03:38:15 kronecker ntpdate[629]: Can't find host ptbtime2.ptb.de: Name 
or service not known (-2)
Oct 28 03:38:15 kronecker systemd[1]: Child 607 belongs to networking.service
Oct 28 03:38:15 kronecker systemd[1]: Child 628 belongs to networking.service
Oct 28 03:38:15 kronecker systemd[1]: networking.service: cgroup is empty
Oct 28 03:38:15 kronecker systemd[1]: networking.service changed running -> 
exited
 ifdown output ***
ifdown: interface eth0 not configured
*** ifconfig after ifdown 
loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:672 errors:0 dropped:0 overruns:0 frame:0

Bug#738848: osc: refuses to communicate with API server over IPv6

[Paavo Hartikainen]

On 2014-10-06 09:40:15 +0200, Michal Čihař wrote:

> Can you please check whether you can still reproduce this?

Yes, still same problem on IPv6 -only host: 

  "Failed to reach a server: [Errno 229] Network is unreachable: [...]"

Meanwhile, from same host to same API URL with "wget":

  "HTTP request sent, awaiting response... 401 Unauthorized"

This is expect as I did not attempt to authenticate, just demonstrated 
that it is reachable.


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

Bug#767049: wine: unknown key signed

[kfreebsd]

Package: wine
Version: 1.6.2-14
Severity: important

Dear Maintainer,

after finding wine broken I decided to build it,
apt-get build-dep wine
apt-get -b source wine
gpgv: Signature made Sun 26 Oct 2014 08:02:00 PM CDT using RSA key ID 02D6F473
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./wine_1.6.2-14.dsc
there was a time when Debian was really Debian where it would refuse to install 
things like this, it would say NO WAY and that was it,these days it will 
download and build the shit, 

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


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

Kernel: kFreeBSD 10.1-0-amd64
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 depends on:
ii  file1:5.20-1
ii  wine64  1.6.2-14

wine recommends no packages.

Versions of packages wine suggests:
pn  avscan | klamav | clamav   
ii  binfmt-support 2.1.5-1
pn  ttf-mscorefonts-installer  
pn  winbind

-- 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#767011: wine-development: WINELOADER from script is not passed (strange)

[jre]

control: notfound -1 1.7.27-1
control: found -1 1.7.28-1
control: found -1 1.7.28-2
control: found -1 1.7.28-3


It seems to be /some/ change made in 1.7.28-1.

It still works in 1.7.27-1, but fails in 1.7.28-3.

1.7.28-2 just fixed an FTBFS due to an incorrect manpage path and
1.7.28-3 just added a missing fi (I verified that in the git
repository). So although these two don't work at all, I think it is safe
to assume that they already contained the bug.



Further information:

1.)
Immediately after a failed attempt the wine (stable) wineserver is
running (/usr/lib/i386-linux-gnu/wine/bin/wineserver).


2.)
This package combination works:
$ dpkg -l "*wine*"|grep ii|sed "s|Windows.*||g"|sort
ii  libwine-development:amd641.7.27-1 amd64
ii  libwine-development:i386 1.7.27-1 i386
ii  libwine-gecko-2.21   2.21+dfsg2-1 all
ii  libwine-gecko-2.24   2.24+dfsg-1  all
ii  libwine:i386 1.6.2-14 i386
ii  wine 1.6.2-14 amd64
ii  wine32   1.6.2-14 i386
ii  wine32-development   1.7.27-1 i386
ii  wine64-development   1.7.27-1 amd64
ii  wine-development 1.7.27-1 amd64


3.)
The line wrapping in my first mail was unfortunate. E.g. this should
have been one line:

~
WINELOADER=/usr/lib/wine-development/wine WINEDEBUG=fixme+all,err+all
/usr/lib/wine-development/wine notepad
~


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

Bug#767048: wine doesnt run at all

[kfreebsd]

Package: wine
Version: 1.6.2-14
Severity: important

Dear Maintainer,

/usr/share/doc/wine/README.Debian 
Also note that Wine for Debian is set up to use a wrapper script,
where /usr/bin/wine
ii  binfmt-support 2.1.5-1
pn  ttf-mscorefonts-installer  
pn  winbind

-- 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#757539: Debian: apertium language pairs broken in jessie due to pcre3 update

[Paul Wise]

On Wed, 2014-08-13 at 09:29 +0800, Paul Wise wrote:

> I don't think a proper fix is going to happen before the freeze so can
> we have the binNMUs so that apertium works in jessie?

So it is now too late to easily fix this issue for jessie. In addition
some language pairs got removed due to RC bugs being filed and the
automatic removal process removing them. There are three ways forward:

Have Kartik/Francis/Tino upload the latest upstream code and language
pairs to unstable and unblock them for jessie. This seems unlikely.

binNMU all of the relevant language pairs as initially requested, close
the relevant RC bugs and unblock the binNMUed and removed packages.

Remove apertium related packages from jessie entirely. It is fairly
pointless to have apertium in Debian without working language pairs.

Any thoughts from the Debian release team?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#766359: gnome-shell: gdm shows a black screen when upgrading to 3.14.1-1

[Mert Dirik]

On Thu, 23 Oct 2014 23:18:09 -0400 Matthew Gabeler-Lee 
 wrote:



I too encountered this problem.  By checking syslog, I eventually tracked it
down to a missing dependency on the 3.14.1 version of libmutter0e:

gnome-session[22789]: (gnome-shell:22822): Gjs-WARNING **: JS ERROR: GLib.Error 
g-invoke-error-quark: Could not locate meta_get_feedback_group_for_screen: 
'meta_get_feedback_group_for_screen': /usr/lib/libmutter.so.0: undefined 
symbol: meta_get_feedback_group_for_screen

Upgrading libmutter0e to the 3.14.1 version fixed he problem for me, though
I also upgraded several other gnome packages to 3.14.1 in an attempt to find
the problem, so gnome-shell may not be the only component with this missing
dependency issue.



Would it be a problem if this bug can be marked as DONE, so that the 
package can migrate to testing, since libmutter0e is in testing now?



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

Bug#668001: debootstrap: cant install systemd instead of sysvinit

[Woody Suwalski]

On Fri, 17 Oct 2014 05:57:30 +0200 Cyril Brulebois  wrote:
> Kenshi Muto  (2014-10-17):
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Hi,
> >
> > I made a patch to see each Depends:/Pre-Depends: and
> > respect exclude parameter.
> >
> > If init Pre-Depends: systemd-sysv | sysvinit-core | upstart,
> > exclude= gets systemd-sysv.
> > exclude=systemd-sysv gets sysvinit-core.
> > exclude=systemd-sysv,sysvinit-core gets upstart.
> >
> > (exclude=systemd-sysv,sysvinit-core,upstart gets nothing, but
> > systemd-sysv will be installed later by apt-get.)
>
> Thanks for the patch but…
>
> I'm really uncomfortable adding that kind of patch this late in the
> release cycle, especially since the “I don't want systemd” “problem”
> is trivially solved with a late_command.
>
> Mraw,
> KiBi.

Cyril, Kenshi's debootstrap patch has worked for me. I was able to build 
a nosystemd debootstrap base and then a full custom Debian distro image. 
I had some problems with talking to X, but still managed to make it work.


You have mentioned that there is a trivial late_command workaround for 
systemd. Could you please point to the how-to?


Thanks, Woody


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

Bug#767043: ESS should not depend on R

[Juliusz Chroboczek]

> | Package ess depends on r-base-core, which is a 19MB download, and rather
> | useless for people programming in Julia.  Please downgrade this to
> | a Recommends.

> I disagree.

May I most humbly request a slightly more verbose expression of your opinion?

-- Juliusz


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

Bug#767043: ESS should not depend on R

[Dirk Eddelbuettel]

On 28 October 2014 at 01:54, Juliusz Chroboczek wrote:
| > | Package ess depends on r-base-core, which is a 19MB download, and rather
| > | useless for people programming in Julia.  Please downgrade this to
| > | a Recommends.
| 
| > I disagree.
| 
| May I most humbly request a slightly more verbose expression of your opinion?

The vast majority of users of ESS deploy it with R, and expect M-x R to work.

That is worth more (due to the number of potential users) than the minor
inconvenience you experience via the forced install of r-base-core.  

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@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#766936: [pkg-otr-team] Bug#766936: Bug#766936: [libotr5] Extended description: "Deniability" is not a feature per se

[Ximin Luo]

On 27/10/14 03:08, Harlan Lieberman-Berg wrote:
> On Sun, 2014-10-26 at 21:22 -0400, Filipus Klutiero wrote:
>> Rather than advertising 2 independant items, these could be merged in a
>> "Deniable authentication" item which would contain both sublists.
> 
> One reason why I think "deniability" is important as a separate feature
> is that it is differentiating in the face of other, similar kinds of
> programs.  Most encryption systems are not deniable; in fact, many
> systems are not deniable /by design/.  This message, for example, is PGP
> signed and is not deniable at all.  Anyone who gets a copy of the
> message can verify that I, or someone with control over my private key,
> composed and sent this message.  The Pidgin-Encryption plugin similarly
> doesn't have deniability built into its threat model at all.
> 
> In that context, I think it might be deserving of being listed as its
> own feature.
> 

Both of you are right in some degree. Deniability is indeed a secondary 
property of the underlying authentication system (note: *not* encryption system 
as Harlan said). It makes no sense without authentication. However, I'm neutral 
as to merging the two points.

A related point is that "forward secrecy" is a secondary property of the 
underlying encryption system. It makes no sense without encryption (i.e. 
confidentiality).

Personally, I like to introduce these concepts as "forward-secure 
confidentiality" and "deniable authentication".

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature

Bug#766991: acpid: does not process events

[Norbert Preining]

Hi Ted, hi Systemd maintainers

SHort description for systemd maintainers: acpid seems not to be
started anymore automatically, thus custom events defined in 
/etc/acpid/... are not processed anymore. In my case the touchpad
toggle key is a specific event and I have written an action that
should actually toggle the touchpad, but it is never processed,
since acpid is not started.

On Mon, 27 Oct 2014, Ted Felix wrote:
>   I've not used systemd yet, but I'm pretty sure acpid works fine
> when the socket is sent in as the stdin fd (or something along those

[what follows is my interpretation - systemd maintainers, please correct!]

It is not a problem of working or not, the problem is that
acpid is *not* started
but only the socket kept open by systemd.

That means that events that should trigger actions are not processed.


I took a look into the acpid.service and acpid.socket files, but
I don't understand systemd.

It seems that systemd decides by itself that acpid needs no
starting, but only an open socket. systemd then opens the socket,
and listens, and in case someone wants something over the socket,
it starts acpid.

THat explains why each one of the following actions actually start
the acpid:
* /etc/init.d/acpid - of course
* acpi_listener - it pulls the socket, thus systemd starts acpid

But the point is that there are events generated from kbd that are
not coming over the socket, and thus are completely lost.

All the best

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



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

Bug#765429: Fwd: scantailor: Needs libtiff 3.9, fails to run without libtiff4

[Veronica Brandt]

I have updated Jessie and still get the same messages:

scantailor: error while loading shared libraries: libtiff.so.4: cannot
open shared object file: No such file or directory

or, with a symlink from libtiff 5 as before:

scantailor: /usr/lib/i386-linux-gnu/libtiff.so.4: version `LIBTIFF_3.9'
not found (required by scantailor)

I tried installing scantailor on another Jessie computer and it works
fine and there is no libtiff.so.4 there, so a bit of a mystery what is
going wrong.

I'm happy to reduce the severity of the bug as it looks like it is
something peculiar to my system.

Veronica

On Sun, 26 Oct 2014 09:05:29 +0100 Daniel Stender
 wrote:
>  Forwarded Message 
> Subject: scantailor: Needs libtiff 3.9, fails to run without libtiff4
> Date: Tue, 21 Oct 2014 11:23:12 +0200
> From: Daniel Stender 
> To: 765...@bugs.debian.org
> 
> Control: severity -1 important
> 
> Thanks for reporting this bug.
> 
> I've contacted the Upstream developer with this and I'll get this
> fixed, but this behavior isn't reproducible on a standard Jessie.
> 
> Could you please try to update your Jessie to install the latest build
> of Scantailor (0.9.11.1-2+b1) and pass the results of running this?
> 
> I've discussed this with my sponsor and we want to lower the severity
> of this bug to a non-RC state for the moment.
> 
> Greetings,
> Daniel Stender
> 
> -- 
> http://qa.debian.org/developer.php?login=debian%40danielstender.com
> GPG key: 4096R/DF5182C8
> 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
> 
> 
> 
> 
> 
> 


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

Bug#767047: menu icon not in xpm format

[dann frazier]

Package: lshw-gtk
Version: 02.17-1
Severity: important

According to the Debian Menu System manual, section 3.7, menu icons
should be in xpm format:

https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.7

Version 02.17-1 switched to an svg. Lintian has a test for this, but
it is masked because the menu file that gets installed still points to
a (non-existant) xpm file (#767046). When the path is corrected,
lintian will emit the following error:

E: lshw-gtk: menu-icon-not-in-xpm-format usr/share/pixmaps/lshw-gtk.svg
N: 
N:Icons in the Debian menu system should be in XPM format.
N:
N:While other image types (e.g. png images) appears to "just work", window
N:managers are not "required to support them". Accordingly using non-XPM
N:icons could break interoperability.
N:
N:Refer to Debian Menu System section 3.7 (The icon field) and
N:http://bugs.debian.org/591812 for details.
N:
N:Severity: important, Certainty: certain
N:
N:Check: menu-format, Type: binary
N: 


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

Bug#767046: icon path in menu file incorrect

[dann frazier]

Package: lshw-gtk
Version: 02.17-1

The menu file still points to a .xpm file, whereas lshw-gtk is now
landing a .svg file:

dannf@fluid:~$ tr ' ' '\n' <  /usr/share/menu/lshw-gtk | grep icon
icon="/usr/share/pixmaps/lshw-gtk.xpm"
dannf@fluid:~$ file /usr/share/pixmaps/lshw-gtk.xpm
/usr/share/pixmaps/lshw-gtk.xpm: cannot open `/usr/share/pixmaps/lshw-gtk.xpm' 
(No such file or directory)
dannf@fluid:~$ dpkg -L lshw-gtk | grep /usr/share/pixmaps
/usr/share/pixmaps
/usr/share/pixmaps/lshw-gtk.svg
dannf@fluid:~$ 


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

Bug#767045: git submodule foreach --recursive: please provide envvars for toplevel and sub-submodule path

[Jonathan Nieder]

Package: git
Version: 1:2.1.0-1
Severity: wishlist
Tags: upstream

"git submodule foreach" provides helpful variables $toplevel and $path,
with semantics

 - $toplevel is the absolute path to the top-level of the superproject
 - $path is the name of the submodule directory relative to the
   superproject

When dealing with nested submodules, those refer to the absolute path
of the parent of the current project and the name of the submodule
directory relative to the parent of the current project.

It would be convenient to have similar variables referring to the
absolute path of the toplevel project and the name of the current
submodule directory relative to that toplevel project.

This can be emulated using

 top=$(git rev-parse --show-toplevel) \
 git submodule foreach --recursive '
cwd=$(pwd)
fullpath=${cwd#$top/}

...
 '


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

Bug#767044: 'git submodule foreach --recursive' prints progress info to stdout

[Jonathan Nieder]

Package: git
Version: 1:2.1.1-1
Tags: upstream patch

Most git commands write progress info to stderr, but 'git submodule
foreach --recursive' writes its progress info "Entering '[submodule]'"
to stdout.  This makes git submodule foreach --recursive harder to
use than it should be in a pipeline.

How about something like this patch?

Signed-off-by: Jonathan Nieder 
---
diff --git i/git-submodule.sh w/git-submodule.sh
index 9245abf..aabe567 100755
--- i/git-submodule.sh
+++ w/git-submodule.sh
@@ -154,7 +154,7 @@ module_list()
eval "set $(git rev-parse --sq --prefix "$wt_prefix" -- "$@")"
(
git ls-files -z --error-unmatch --stage -- "$@" ||
-   echo "unmatched pathspec exists"
+   echo >&2 "unmatched pathspec exists"
) |
@@PERL@@ -e '
my %unmerged = ();
@@ -469,7 +469,7 @@ Use -f if you really want to add it." >&2
echo >&2 "$(eval_gettext "use the '--force' 
option. If the local git directory is not the correct repo")"
die "$(eval_gettext "or you are unsure what 
this means choose another name with the '--name' option.")"
else
-   echo "$(eval_gettext "Reactivating local git 
directory for submodule '\$sm_name'.")"
+   say >&2 "$(eval_gettext "Reactivating local git 
directory for submodule '\$sm_name'.")"
fi
fi
module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" 
"$depth" || exit
@@ -539,7 +539,7 @@ cmd_foreach()
if test -e "$sm_path"/.git
then
displaypath=$(relative_path "$sm_path")
-   say "$(eval_gettext "Entering '\$prefix\$displaypath'")"
+   say >&2 "$(eval_gettext "Entering 
'\$prefix\$displaypath'")"
name=$(module_name "$sm_path")
(
prefix="$prefix$sm_path/"
@@ -616,7 +616,7 @@ cmd_init()
git config submodule."$name".url "$url" ||
die "$(eval_gettext "Failed to register url for 
submodule path '\$displaypath'")"
 
-   say "$(eval_gettext "Submodule '\$name' (\$url) 
registered for path '\$displaypath'")"
+   say >&2 "$(eval_gettext "Submodule '\$name' (\$url) 
registered for path '\$displaypath'")"
fi
 
# Copy "update" setting when it is not set yet
@@ -698,8 +698,8 @@ cmd_deinit()
die "$(eval_gettext "Submodule work tree 
'\$displaypath' contains local modifications; use '-f' to discard them")"
fi
rm -rf "$sm_path" &&
-   say "$(eval_gettext "Cleared directory 
'\$displaypath'")" ||
-   say "$(eval_gettext "Could not remove submodule work 
tree '\$displaypath'")"
+   say >&2 "$(eval_gettext "Cleared directory 
'\$displaypath'")" ||
+   say >&2 "$(eval_gettext "Could not remove submodule 
work tree '\$displaypath'")"
fi
 
mkdir "$sm_path" || say "$(eval_gettext "Could not create empty 
submodule directory '\$displaypath'")"
@@ -711,7 +711,7 @@ cmd_deinit()
# the user later decides to init this submodule again
url=$(git config submodule."$name".url)
git config --remove-section submodule."$name" 
2>/dev/null &&
-   say "$(eval_gettext "Submodule '\$name' (\$url) 
unregistered for path '\$displaypath'")"
+   say >&2 "$(eval_gettext "Submodule '\$name' (\$url) 
unregistered for path '\$displaypath'")"
fi
done
 }
@@ -818,7 +818,7 @@ cmd_update()
 
if test "$update_module" = "none"
then
-   echo "Skipping submodule '$displaypath'"
+   echo >&2 "Skipping submodule '$displaypath'"
continue
fi
 
@@ -827,7 +827,7 @@ cmd_update()
# Only mention uninitialized submodules when its
# path have been specified
test "$#" != "0" &&
-   say "$(eval_gettext "Submodule path '\$displaypath' not 
initialized
+   say >&2 "$(eval_gettext "Submodule path '\$displaypath' 
not initialized
 Maybe you want to use 'update --init'?")"
continue
fi
@@ -914,7 +914,7 @@ Maybe you want to use 'update --init'?")"
 
if (clear_local_git_env; cd "$sm_path" && $command 
"$sha1")
then
-   say "$say_msg"
+   say >&2 "$say_msg"
elif test -n "$must_die_on_failure"
  

Bug#765487: fontypython not starting up (memory access error)

[Guillermo Espertino]

I'm affected too. I think I found the cause of the segfault, or at least
a hint to take a look.

The new version of Fonty Python is compiled against python-wxgtk3.0.
Since the problem apparently started since the upgrade to that version
of the library I tried installing the old from wheezy (depends on
wxgtk2.8), but it crashed too.

Then I tried uninstalling python-wxgtk3.0. The current version from
jessie can't be installed since it depends on wxgtk3.0, so I tried with
fonty python from wheezy, and it worked.
Fonty python from wheezy with python-wxgtk 2.8 works fine, but it
crashes with 3.0, which leads me to think that there is something wrong
with wxgtk 3.0

Trying to find further information I bumped with this old bug report:
https://savannah.nongnu.org/bugs/index.php?23528
I'm not sure if this is helpful, but the reporter claims that building
wxGTK with --enable-debug produced a similar crash.

Is it possible that python-wxgtk3.0 was compiled with that flag?

Hth,
Gez.


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

Bug#737399: metoo

[Pádraig Brady]

On 10/27/2014 03:12 PM, Harald Dunkel wrote:
> On 10/27/14 12:54, Pádraig Brady wrote:
>>
>> Good point about the man page.
>>
>> I've submitted a patch to mention that -a includes duplicate file systems.
>>
> 
> Thats exactly the point of this bug report: /home and
> /data are not "duplicates". The server has a common
> partition providing both exports, but I doubt that this
> special case should matter on the client.

To the client they're both the same file system (device ID).
(If you fill up one, you fill up the other).

> By "df" showing /data and hiding /home it seems that
> /data is somehow superior to /home.

df uses the path lengths to chose the most appropriate mount point.
In this edge case since the lengths are the same it went
with the last mounted entry as that's the most appropriate one
in some other edge cases.

thanks,
Pádraig.


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

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Ben Hutchings]

On Tue, 2014-10-28 at 00:18 +0100, Cyril Brulebois wrote:
> Cc+=debian-kernel@ for input since I seem to recall having seen PHY
> drivers (including in a realtek context) being mentioned lately, at
> least on IRC, maybe on list as well.

I don't understand this.

> Karsten Merker  (2014-10-27):
[...]
> > [   73.104782] libphy: stmmac: probed
> > [   73.104812] eth0: No PHY found
> > 
> > i.e. the correct ethernet MAC driver (stmmac) gets loaded
> > automatically, but the necessary PHY driver (realtek) does not.
[...]
> > [  499.392561] libphy: stmmac: probed
> > [  499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
> > [  499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
> > 
> > and the ethernet interface works. The kernel version used in this
> > installer build is 3.16.5-1.

$ modinfo -F alias realtek
mdio:???111001100100100010101
mdio:???111001100100100010010

In hex those are 1cc915 and 1cc912.  (The 11 most significant bits are
unspecified.)  So modprobe certainly should find this module when
requested by phylib.

As udev is *not* involved in loading MDIO PHY drivers (NIC drivers
expect them to be bound synchronously) it isn't easy to monitor what's
going on.  You could replace modprobe with a script that logs its
arguments to a file before calling the real modprobe.  That should tell
us whether the bug is in the kernel or userland.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers


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

Bug#737399: metoo

[Pádraig Brady]

On 10/27/2014 05:21 PM, Michael Stone wrote:
> On Mon, Oct 27, 2014 at 11:54:57AM +, Pádraig Brady wrote:
>> On 10/27/2014 08:36 AM, Harald Dunkel wrote:
>>> On 10/24/14 18:24, Pádraig Brady wrote:

 Note /home doesn't seem to be accessible above
 which is another reason to prefer /data here.

>>>
>>> What do you mean by "not accessible"? Both /home and
>>> /data work fine.
>>
>> I was referring to the fact that "-" was shown for the /home entry:
>>
>>  nfs-home:/space/home  -   -  -- /home
>>  nfs-home:/space/data13390666752 10768854016 1941581824  85% /data
> 
> That's df's doing. Potentially something like this would get the suggested 
> behavior:
> 
> --- src/df.c.orig   2014-10-27 12:14:39.633167418 -0400
> +++ src/df.c2014-10-27 13:16:54.524752800 -0400
> @@ -631,6 +631,10 @@
>/* Stat failed - add ME to be able to complain about it later.  */
>buf.st_dev = me->me_dev;
>  }
> +  else if (me->me_remote)
> +{
> +  /* ignore duplicate network mounts */
> +}
>else
>  {
>/* If we've already seen this device...  */

Still not convinced about that hunk.

> @@ -928,7 +932,7 @@
>if (stat (stat_file, &sb) == 0)
>  {
>char const * devname = devname_for_dev (sb.st_dev);
> -  if (devname && ! STREQ (devname, disk))
> +  if (devname && ! STREQ (devname, disk) && !me_remote)
>  {
>fstype = "-";
>fsu.fsu_blocksize = fsu.fsu_blocks = fsu.fsu_bfree =
> 
> 
> The question then being whether making this case work breaks other cases, and 
> whether making it that much harder to explain the logic of what df displays 
> is worth it to avoid explaining why a particular set of mounts is captured by 
> the current logic. :)

I agree that the "-" placeholders above should not have been output.
The attached patch is just a more general version of the hunk above.

thanks!
Pádraig.

>From 19c3646e1fd2964539fbb4240710e2262582c8d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Mon, 27 Oct 2014 23:37:08 +
Subject: [PATCH] df: ensure -a shows all remote file system entries

commit v8.22-125-g9d736f8 printed placeholder "-" values
for device names that didn't match the preferred device name
for a particular mount point.  However that was seen to erroneously
suppress values for aliased host names or exports, common with
remote file systems.

* src/df.c (me_for_dev): Rename from devname_for_dev() so that
we can determine the remoteness as well as the name for the
preferred mount entry.
(get_dev): Don't output place holder values when both
current and preferred mount entries are remote.

Reported in http://bugs.debian.org/737399
---
 src/df.c |   17 ++---
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/src/df.c b/src/df.c
index 5231676..a52afc4 100644
--- a/src/df.c
+++ b/src/df.c
@@ -703,17 +703,17 @@ filter_mount_list (bool devices_only)
 }
 
 /* Search a mount entry list for device id DEV.
-   Return the corresponding device name if found or NULL if not.  */
+   Return the corresponding mount entry if found or NULL if not.  */
 
-static char const * _GL_ATTRIBUTE_PURE
-devname_for_dev (dev_t dev)
+static struct mount_entry const * _GL_ATTRIBUTE_PURE
+me_for_dev (dev_t dev)
 {
   struct devlist *dl = device_list;
 
   while (dl)
 {
   if (dl->dev_num == dev)
-return dl->me->me_devname;
+return dl->me;
   dl = dl->next;
 }
 
@@ -928,12 +928,15 @@ get_dev (char const *disk, char const *mount_point, char const* file,
   else if (process_all && show_all_fs)
 {
   /* Ensure we don't output incorrect stats for over-mounted directories.
- Discard stats when the device name doesn't match.  */
+ Discard stats when the device name doesn't match.  Though don't
+ discard when used and current mount entries are both remote due
+ to the possibility of aliased host names or exports.  */
   struct stat sb;
   if (stat (stat_file, &sb) == 0)
 {
-  char const * devname = devname_for_dev (sb.st_dev);
-  if (devname && ! STREQ (devname, disk))
+  struct mount_entry const * dev_me = me_for_dev (sb.st_dev);
+  if (dev_me && ! STREQ (dev_me->me_devname, disk)
+  && (! dev_me->me_remote || ! me_remote))
 {
   fstype = "-";
   fsu.fsu_blocksize = fsu.fsu_blocks = fsu.fsu_bfree =
-- 
1.7.7.6

Bug#767043: ESS should not depend on R

[Dirk Eddelbuettel]

On 28 October 2014 at 00:33, Juliusz Chroboczek wrote:
| Package: ess
| Version: 14.09-1
| 
| Package ess depends on r-base-core, which is a 19MB download, and rather
| useless for people programming in Julia.  Please downgrade this to
| a Recommends.

I disagree.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@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#765622: Dracut, systemd and base-files

[Krzysztof A. Sobiecki]

>So, which package is to blame for not booting? dracut or systemd?
Dracut uses Systemd as initial init system. Systemd should switch
to real / using /lib/systemd/system/initrd-switch-root.service

It calls "/bin/systemctl --no-block --force switch-root /sysroot"
During this it checks /sysroot for /etc/os-release.
Because thanks to base-files /etc/os-release is a link to
../usr/lib/os-release it fails on systems with separate /usr.

Applying one of my patches to base-files fixes boot problem with dracut
and systemd. I think that patching systemd to not search for
/etc/os-release would also fix it.

-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


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

Bug#767043: ESS should not depend on R

[Juliusz Chroboczek]

Package: ess
Version: 14.09-1

Package ess depends on r-base-core, which is a 19MB download, and rather
useless for people programming in Julia.  Please downgrade this to
a Recommends.

-- Juliusz


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

Bug#766708: set correct title

[Matthias Klose]

Control: retitle -1 Request to override gcc maintainer changes breaking
unsupported way of cross-building

cross builds supporting multiarch exists and works. claiming otherwise is just
populistic and/or marketing.


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

Bug#752734: can't reproduce anymore

[nodiscc]

I tried this again with twidge today (1.1.2 on an i386 machine) and I 
can't reproduce this anymore. I think it's safe to close.

Bug#767037: installation-reports: jessie on HP EliteBook 820

[Julien Cristau]

On Mon, Oct 27, 2014 at 23:16:24 +0100, Cyril Brulebois wrote:

> Hi Claire!
> 
> Claire David  (2014-10-27):
> > 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:[E]
> > Overall install:[ ]
> > 
> > Comments/Problems:
> > 
> > On reboot the system cannot find grub. After reinstalling the boot
> > loader using the rescue mode of the installer, it is possible to
> > manually select grubx64.efi from the firmware but it still does not boot
> > on its own.
> 
> Thanks for the report; Steve, can you please have a look at this EFI thingy?
> 
Steve suggested copying grubx64.efi to /boot/efi/EFI/boot/bootx64.efi,
which worked.  Not exactly ideal, but better than having to navigate
through the ESP at each boot.

Thanks,
Julien


signature.asc
Description: Digital signature

Bug#766784: libjson-pp-perl: can neither remove nor install newer version of this package: possible cause

[brian m. carlson]

On Mon, Oct 27, 2014 at 01:51:15PM +0100, Dominique Dumont wrote:
> Could you:
> - purge libjson-pp-perl

Not without removing the diversion first.  The original bug report
demonstrates that I can't remove the package.  Whether
/usr/share/man/man1/json_pp.1.bundled.gz exists or not doesn't affect
that.  (It did not exist originally.)

I managed to fix it by doing "dpkg-divert --remove
/usr/share/man/man1/json_pp.1.gz", which allowed the package to be
removed.  Whatever the underlying issue was should probably still be
fixed, although this allows me to get aptitude working again.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#766466: php-guzzle: ftbfs and (sometimes) after built attempt in pbuilder, nodejs still runs server.js

[David Prévot]

Hi Holger,

On Sat, Oct 25, 2014 at 11:57:34AM +0200, Holger Levsen wrote:
> On Donnerstag, 23. Oktober 2014, David Prévot wrote:

> > Seems like the segfault is reproducible with the jenkins setup, but I
> > still don’t know what is causing it.
> 
> yeah. Just tell me if you have something for me to try...

> >   running phpunit
> >   with the --debug switch should help pointing to the test actually
> >   causing the segfault.
> 
> how do I run that exactly?

Either by running directly, in the source package directory (with
patches applied):

phpunit --debug

or by adding “--debug” to phpunit in the override_dh_auto_test target of
debian/rules (so it will be used during the build).

> > A local server (with nodejs) is run for the purpose of these tests, and
> > some other tests use http://127.0.0.1:123/ to test failure to connect to
> > a server.

> > - in a normal sid (as pointed in your initial message), some tests are
> >   failing, and some other error out.

Seems to be related to the proxy: if I run the test with http_proxy set
to use a local Squid, I manage to get failing tests (albeit without
segfault). I just uploaded 3.9.2+dfsg-5 that unsets http_proxy for
running the tests, please let me know if that’s enough for Jenkins (and
if the segfault vanished ;).

> yes, those are two bugs. I'll leave the cloning to you though. You have a 
> better grasp whats happening.

Let’s see first if we’re able to kill two birds with one stone ;).

Regards

David


signature.asc
Description: Digital signature

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Cyril Brulebois]

Cc+=debian-kernel@ for input since I seem to recall having seen PHY
drivers (including in a realtek context) being mentioned lately, at
least on IRC, maybe on list as well.

Karsten Merker  (2014-10-27):
> Package: installation-reports
> 
> Boot method: hd-media (installer booted from USB stick)
> Image version:
>   http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz
>   (dated 27-Oct-2014 05:17) together with
>   
> http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo
>   (dated 2014-10-27 11:58)
> Date: 2014-10-27
> U-Boot: 2014.10+dfsg1-1
> 
> Machine: LeMaker Banana Pi
> Processor: Allwinner A20 (2x Cortex A7)
> Memory: 1GB
> Mass Storage: 16GB SD card
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[E] (see comments below, getting this to work 
>  requires manual loading of the proper
>  ethernet PHY driver module)
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Install tasks:  [O]
> Install boot loader:[O]
> Overall install:[O]
> 
> Comments/Problems:
> The "detect network hardware" step fails with
> "No Ethernet card was detected. If you know the name of the driver
>  needed by your Ethernet card, you can select it from the list."
> 
> dmesg shows:
> [   73.100072] stmmaceth 1c5.ethernet: no reset control found
> [   73.100103]  Ring mode enabled
> [   73.100112]  No HW DMA feature register supported
> [   73.100120]  Normal descriptors
> [   73.100127]  TX Checksum insertion supported
> [   73.104782] libphy: stmmac: probed
> [   73.104812] eth0: No PHY found
> 
> i.e. the correct ethernet MAC driver (stmmac) gets loaded
> automatically, but the necessary PHY driver (realtek) does not.
> Loading the realtek module after the stmmac driver has probed
> for a PHY does not change anything; the stmmac driver does not
> re-probe for a PHY upon later loading of the PHY driver.
> Manually unloading the stmmac module, loading the PHY driver
> and then loading the stmmac module again from a shell by
> running
> 
> ~ # rmmod stmmac
> ~ # modprobe realtek
> ~ # modprobe stmmac
> 
> results in
> 
> [  499.364044] stmmaceth 1c5.ethernet: no reset control found
> [  499.364076]  Ring mode enabled
> [  499.364084]  No HW DMA feature register supported
> [  499.364090]  Normal descriptors
> [  499.364097]  TX Checksum insertion supported
> [  499.392561] libphy: stmmac: probed
> [  499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
> [  499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
> 
> and the ethernet interface works. The kernel version used in this
> installer build is 3.16.5-1.
> 
> Regards,
> Karsten

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime

[paul . szabo]

Dear Mike,

> I test your patch and it results in several nxproxy crashes ...

You have the new, patched nxproxy on both ends of the connection?
The encoding of the data has changed.

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia


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

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Karsten Merker]

Package: installation-reports

Boot method: hd-media (installer booted from USB stick)
Image version:
  http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz
  (dated 27-Oct-2014 05:17) together with
  
http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo
  (dated 2014-10-27 11:58)
Date: 2014-10-27
U-Boot: 2014.10+dfsg1-1

Machine: LeMaker Banana Pi
Processor: Allwinner A20 (2x Cortex A7)
Memory: 1GB
Mass Storage: 16GB SD card

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

Initial boot:   [O]
Detect network card:[E] (see comments below, getting this to work 
 requires manual loading of the proper
 ethernet PHY driver module)
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:
The "detect network hardware" step fails with
"No Ethernet card was detected. If you know the name of the driver
 needed by your Ethernet card, you can select it from the list."

dmesg shows:
[   73.100072] stmmaceth 1c5.ethernet: no reset control found
[   73.100103]  Ring mode enabled
[   73.100112]  No HW DMA feature register supported
[   73.100120]  Normal descriptors
[   73.100127]  TX Checksum insertion supported
[   73.104782] libphy: stmmac: probed
[   73.104812] eth0: No PHY found

i.e. the correct ethernet MAC driver (stmmac) gets loaded
automatically, but the necessary PHY driver (realtek) does not.
Loading the realtek module after the stmmac driver has probed
for a PHY does not change anything; the stmmac driver does not
re-probe for a PHY upon later loading of the PHY driver.
Manually unloading the stmmac module, loading the PHY driver
and then loading the stmmac module again from a shell by
running

~ # rmmod stmmac
~ # modprobe realtek
~ # modprobe stmmac

results in

[  499.364044] stmmaceth 1c5.ethernet: no reset control found
[  499.364076]  Ring mode enabled
[  499.364084]  No HW DMA feature register supported
[  499.364090]  Normal descriptors
[  499.364097]  TX Checksum insertion supported
[  499.392561] libphy: stmmac: probed
[  499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
[  499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)

and the ethernet interface works. The kernel version used in this
installer build is 3.16.5-1.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


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

Bug#767041: kephra: Fails with "You did not specify a file name"

[Jonas Smedegaard]

Package: kephra
Version: 0.4.3.34+dfsg-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Just installed and it seems it is completely broken:

Invoking "kephra" on a commandline, just get this:

You did not specify a file name at /usr/share/perl5/Kephra/Config/Interface.pm 
line 61.

Instead invoking "kephra foo" (i.e. an existing file) makes same error.


 - Jonas


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

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

Versions of packages kephra depends on:
ii  libconfig-general-perl 2.56-1
ii  libfile-userconfig-perl0.06-2
ii  libwx-perl 1:0.9923-4
ii  libwx-perl-processstream-perl  0.32-1
ii  libyaml-tiny-perl  1.64-1
ii  perl   5.20.1-2

kephra recommends no packages.

kephra suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJUTs2gXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWJc0IAKEpDplKbgkRm4qdnNT0oWve
b4RHd1z6nIBRJ9ZXutl5D+W9BxRCHLW1iHFb9xRlciE++LCOAs7a7bfwoZz+4KF/
o3ZO14QgwBVS7/IVESTWwSCioPGutQEexikB4rB9NAmAbr9EaR1+6CzrVe2ILX9/
NhKZdr9ex8jiwtVqumNidiVXjsFl2exOLC2D3m4u7z9afsCMnRV+Jz0S8AZ4Djut
c2qxqt9yYQVskB+LY+B6dSNfvRNnMnvtH2OHeNe77GQuL97ChaLlkKdyEVKZFhc+
/jlTBXMvY2tcemzw5Tjeq2mreckndxHohcmGkyRbBla7tUzxdhDMcIQKhyi3Z5o=
=sCJ7
-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#767040: Superblock time check causes problems for fsck in initramfs

[Ben Hutchings]

Package: e2fsprogs
Version: 1.42.12-1
Severity: important
Tags: upstream

We discussed this previously in person, but unfortunately the proposed
solution doesn't work.

The plan for jessie (yes I know it's late) is to mount and fsck the
root and (if separate) /usr filesystems from initramfs code, before
handing over to the real init system.

e2fsck complains if the superblock write time is in the future, and
because the RTC is set to local time on some systems, we are doing the
necessary correction of system time in the initramfs.  This is
undesirable because changing the time zone may now require an
initramfs rebuild.

You said that this check could be disabled in a configuration file,
e2fsck.conf, and we can create that in the initramfs.  This works in
so far as it suppresses warnings while the initramfs code is running.
Unfortunately, every init system currently still checks the root
file-system again.  If the RTC is set to local time and that is east
of UTC, the first fsck sets the write time in the future, and the
second fsck warns.

Please disable this warning by default.

Ben.

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

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

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.42.12-1
ii  libblkid1   2.25.1-5
ii  libc6   2.19-12
ii  libcomerr2  1.42.12-1
ii  libss2  1.42.12-1
ii  libuuid12.25.1-5
ii  util-linux  2.25.1-5

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  gpart  
ii  parted 3.2-6

-- 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#766868: haml-elisp: Fails to install with Emacs 24.4

[Rob Browning]

Axel Beckert  writes:

> It's though not possible that easily as it has hard reverse
> dependencies: html-helper-mode depends on it. Then again,
> html-helper-mode has seen the last upload in 2006 and there's no new
> upstream release since then, too. So maybe I should check Emacs's own
> HTML mode(s?) once again.

...or perhaps html-helper-mode works with 24.4's css-mode?  If so then
html-helper-mode can just adjust its dependencies.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4


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

Bug#764384: man-db: man fails to run from deleted dicrectory

[Colin Watson]

Control: tag -1 fixed-upstream

On Tue, Oct 07, 2014 at 08:35:52PM +0200, Pavel Machek wrote:
> man fails to run from deleted directory.

Thanks for your report.  I've fixed this upstream for the next release:

  
http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=f2912ab654b190b8b26906603780de2cd0faa78b

-- 
Colin Watson   [cjwat...@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#766637: powerline: Missing POWERLINE_COMMAND environment variable

[Jerome Charaoui]

Le 2014-10-27 12:21, Sébastien NOBILI a écrit :
> 
> I'm not sure your patch fixes the issue.
> 
> File /usr/share/powerline/bindings/tmux/powerline.conf references
> $POWERLINE_COMMAND variable.
> 
> I can't find this variable definition anywhere…

This variable is normally set by running $POWERLINE_CONFIG_COMMAND,
which the binding script does run. So this variable definition isn't
needed there. See https://github.com/Lokaltog/powerline/pull/1130


> I've upgraded my powerline package (from Sid source) and don't have any right
> segment contents unless I define it.
> 
> Is there something I've missed ?

Make sure you don't have any other instance of powerline installed on
this system, such as a previous version installed using pip.

Also, after upgrading this package you should restart any application
using powerline, including tmux.

Lastly, see this upstream bug report for troubleshooting info regarding
tmux :
https://github.com/Lokaltog/powerline/issues/1121


-- Jerome



signature.asc
Description: OpenPGP digital signature

Bug#767039: FTBFS on GNU/Hurd

[Guillaume Delacour]

Package: memcached
Version: 1.4.21-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Just for the record, i tried to fix the FTBFS on GNU/Hurd:
* Temp-declare MAXPATHLEN memcached.c, just to continue the build
* Build finish well but upstream test suite t/stats-conns.t fail on call of
  getpeername(2) on a UNIX domain socket as they're not supported on Hurd
  (pflocal/pf.c, S_socket_whatis_address). Maybe same problem in
  t/unixsocket.t.
  I don't really understand why getpeername is called line 415, as tcp_transport
  is not tcp (need further investigations).

Help (and patches) welcome, work started on 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUTsjcAAoJEJmGUYuaqqClOuYP/jQ575e+Y5jitFvFFLurZ5bC
88Tf11z2/PbguDZF7Q8ZPtc9/yKBBP2/vPyxUHF3RGPjFlV6lsbfPWFPSKAuxAF7
0bzOdjoWEByp68KfjiTImukaRukBPfNxUkOJLdSOAABHxtdPo19XDk4hPt0JU+53
FgM8uYolXNz3hcT7Uphs4+Jnu3G9lpl5i3YrdfnaaqoGi6t1xyDSxdH9mJW7/59U
DuAFKd9bfkKfiD2dFj/D3hDT8sj4FRd+vpdVNZljhwrkvwkT/vx9a5QgrI/r7C1v
f2jqEuwv6ywaImB/QfFLcG/Cj+puc0WwP0bB3qcG3Ig+qu1HP0HW6iydjoQf+wub
s4FOh8p+M9/D2F35WAgY9pAI3zvQJLokCIgo7w49cFtVCvs8/ZQ8P+S/hrdcy3ni
xkyWyI3ADHVG7xufwPp6Zq39BJCGNU0pVb1GGLpILYpi65gKVuiMvvsM4NC/fADF
Rpn7K8YK4rM6nLEorVhlmLUqjhv2uLiMaQFWl1VuNhTcIpDsTf3Bg/DLtD9H04Hg
ikJl4obM2CrSf7jlRaIjxHqiwSvQjChrATNkJozcyEcRODiN5q0luwneKXrSiKjd
GRDBaM4VDnYD/Rr+hmQL49FQTTate2kZa1RlTYj+ge0SNsJGhEitOgLeUIjGf69S
KUojWJB8GQdvi6FS+pk9
=daPC
-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#767030: css-mode: may not be compatible with emacs24 24.4

[Rob Browning]

 Rob Browning  writes:

> I'm not sure how it compares, but 24.4 has its own css-mode.el.  If
> that's a newer version of the same code, then it might make sense to
[ 3 more citation lines. Click/Enter to show. ]
> rework the css-mode package to ignore emacs24 (>> 24.4+1) or similar.
>
> Otherwise, if css-mode is still appropriate, then perhaps this is
> relevant:
>
>   https://stackoverflow.com/questions/20135194/emacs-css-mode-not-loading

Oh, and since html-helper-mode depends on css-mode, we'll need to
remeber to make any appropriate adjustments there too.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4


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

Bug#765782: nginx: The sample TLS config should recommend a better cipher list

[Michael Lustfield]

Linking to some third party site in hopes that their documentation will always
be there and be the best option seems to be in bad taste, in my opinion.

To me, it seems better practice to assume that an admin looking into changing
cipher lists will know how to locate relevant information (including their
list) and then tailor it to suite their needs.

If we were to include a link to mozilla recommendations, then it would seem to
make sense to also link to ssllabs as well as cipherli.st.

-- 
Michael Lustfield


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

Bug#766788: libreoffice-writer: Crashes with "stack smashing detected"

[Rene Engelhard]

On Mon, Oct 27, 2014 at 11:24:43AM +0100, Michal Sojka wrote:
> >> I can reproduce this in both unstable and testing
> >> (1:4.3.3~rc2~git20141011-1). I cannot reproduce this in the version
> >
> > And why are you then not marking it as such?
> 
> How can I do that next time? https://www.debian.org/Bugs/Reporting does
> not mention how to mark multiple version.

You add 1:4.3.3~rc2~git20141011-1 in Version: and the BTS then knows
it also affect 1:4.3.3~rc2-1 (see [1])

> >> from libreoffice.org (LibreOffice_4.3.2_Linux_x86-64_deb.tar.gz).
> >
> > And with 4.3.3 rc1? (Or rc2 which would be in the next days)
> > You right now compare a 4.3.2 with a -between-4.3.3-rc1-and-rc2
> > or 4.3.3 rc2 ;)
> >
> >> After the crash the following information appears on the terminal:
> >> 
> >> *** stack smashing detected ***: /usr/lib/libreoffice/program/soffice.bin 
> >> terminated
> >> === Backtrace: =
> >> /lib/x86_64-linux-gnu/libc.so.6(+0x72faf)[0x7fdd44a1ffaf]
> >> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7fdd44aa30a7]
> >> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7fdd44aa3070]
> >
> > But given it runs into the fortify functions it probably won't appear
> > in 4.3.3 rc1 upstream until it's a real crash also there; upstream doesn't
> > use those hardening flags.
> 
> I was able to reproduce this in my own build of libreoffice. Any hint

But probably without hardening or with? Same backtrace or something else?

> how to best debug this with gdb?

I've so far sucessfully avoided this except getting a bt - which we already
have ;) Job for upstream :)

Regards,

Rene

[1] 
https://bugs.debian.org/cgi-bin/version.cgi?info=1;absolute=0;collapse=1;found=libreoffice%2F1%3A4.3.3~rc2~git20141011-1;found=libreoffice%2F1%3A4.3.3~rc2-1;package=libreoffice-writer


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

Bug#766799: resizing root partition with resize2fs makes system unbootable

[Theodore Ts'o]

On Mon, Oct 27, 2014 at 11:37:47PM +0200, Dmitry Borisyuk wrote:
> Thank you for the detailed explanation,
> 
> Indeed, I intentionally created the filesystem with that features removed 
> (because something didn't work with the defaults, sadly it was long ago and I 
> don't remember the details).
> 
> I'm a bit surprised that you have closed the bug. Though my initial 
> filesystem was non-standard, it was not broken, right? Then, I suppose, 
> resize2fs should not break the system silently. It might
> display some warning, at least...

It didn't break the file system; it's a perfectly valid file system to
ext4 and e2fsprogs.

The fact that grub doesn't support file systems with the meta_bg
feature enabled is unfortunate, but that's a grub bug.  It wouldn't be
that hard to support meta_bg, actually; it's a relatively minor change
to the file system format, but grub is GPLv3, and e2fsprogs (because
it has kernel code it in it) is GPL-v2 only, and so grub couldn't just
use libext2fs from e2fsprogs directly.  If they did, then aside from
needing to link against a newer version of libext2fs, it would have
Just Worked.

So you can blame the FSF and GPLv3 for this bug, as well.  :-)

- Ted


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

Bug#767037: installation-reports: jessie on HP EliteBook 820

[Cyril Brulebois]

Hi Claire!

Claire David  (2014-10-27):
> 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:[E]
> Overall install:[ ]
> 
> Comments/Problems:
> 
> On reboot the system cannot find grub. After reinstalling the boot
> loader using the rescue mode of the installer, it is possible to
> manually select grubx64.efi from the firmware but it still does not boot
> on its own.

Thanks for the report; Steve, can you please have a look at this EFI thingy?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#767038: [virtualbricks] error to maintain binary path

[Paride Desimone]

Package: virtualbricks
Version: 0.6.352-1
Severity: normal

--- Please enter the report below this line. ---
Virtualbricks start  with wrong path for binary qemu/kvm and vde and 
when set correct path seems don't maintain configuration.


Furthermore, if I change x-terminal name, when open gui, vb, open always 
gnome-terminal.


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

Debian Release: jessie/sid
  500 unstablehttp.debian.net
  500 testing security.debian.org
  500 stable  deb.opera.com

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


--
http://keyserver.linux.it/pks/lookup?op=get&search=0xCC6CA35C690431D3

Chi e' pronto a rinunciare alle proprie liberta' fondamentali per 
comprarsi briciole di temporanea sicurezza non merita ne' la liberta' 
ne' la sicurezza.(Benjamin Franklin - dalla Risposta al Governatore, 
Assemblea della Pennsylvania, 11 novembre 1755)



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

Bug#722269: Please drop recommends on ffmpeg

[Maxime Chatelle]

tag 722269 + confirmed pending
thanks


Will be done in the next upload.

--
Maxime Chatelle (xakz)
gpg: 5111 3F15 362E 13C6 CCDE  03BE BFBA B6E3 24AE 0C5B


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

Bug#697519: pacpl: Use of uninitialized value $outdir when using -p and a dir

[Maxime Chatelle]

tag 697519 + confirmed
thanks


Hi,

I can add a check during option parsing that report error in command
line parameters. This avoid the printing of `Use of uninitialized value ..'.

A solution like that can be satisfactory ?

--
Maxime Chatelle (xakz)
gpg: 5111 3F15 362E 13C6 CCDE  03BE BFBA B6E3 24AE 0C5B


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

Bug#766316: [Python-apps-team] Bug#766316: Unable to reproduce

[Emilien Klein]

Just confirming that:
- there is an issue with locating the compiled translation files, as it
looks in the relative folder "locale" instead of "/usr/share/locale".
Reported in bug #767036.
- forcing the *language* (not the locale) to French through the settings
didn't change the result: the file downloaded just fine in the folder
containing the accent.

+Emilien



signature.asc
Description: OpenPGP digital signature

Bug#767036: subdownloader: Translation files not loaded correctly

[Emilien Klein]

Package: subdownloader
Version: 2.0.18-1
Severity: important

The subdownloader package in Debian seems to not properly locate the compiled 
.mo translations files:

$ subdownloader -d
[22:15] DEBUG::subdownloader.gui.main # Scanning translation files .mo in 
folder: locale
[22:15] DEBUG::subdownloader.gui.main # Found these translations languages: []
[22:15] DEBUG::subdownloader.gui.main # Interface language: en

The code in question lives in gui/main.py:

def SetupInterfaceLang(self):
if platform.system() == "Linux":
if self.programFolder == '/usr/share/subdownloader':
localedir = '/usr/share/locale/'
else:
localedir = 'locale'
else:
localedir = 'locale'
#Get the local directory since we are not installing anything
#local_path = os.path.realpath(os.path.dirname(sys.argv[0]))
#print local_path


Since in Debian self.programFolder is not /usr/share/subdownloader but 
/usr/share/pyshared/subdownloader, it defaults back to the relative "locale" 
folder.
The Debian package should patch the 3rd line to adapt for the correct value of 
self.programFolder.



Marking the bug as important, as non-English users might have problems using 
the program.
(note that even after patching this, it looks like part of the UI is still in 
English. another issue might be causing that)

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

Kernel: Linux 3.16-3-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages subdownloader depends on:
ii  python   2.7.8-1
ii  python-crypto2.6.1-5+b1
ii  python-kaa-metadata  0.7.7+svn4596-4
pn  python:any   

Versions of packages subdownloader recommends:
ii  python-qt4  4.11.2+dfsg-1

subdownloader 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#767035: [virtualbricks] wrong png icon path

[Paride Desimone]

Package: virtualbricks
Version: 0.6.352-1
Severity: normal

--- Please enter the report below this line. ---
Virtualbricks search png icon in /usr/local/share/pixmaps, but the 
pixmaps directory is under the /usr/share/ directory


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

Debian Release: jessie/sid
  500 unstablehttp.debian.net
  500 testing security.debian.org
  500 stable  deb.opera.com

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


--
http://keyserver.linux.it/pks/lookup?op=get&search=0xCC6CA35C690431D3

Chi e' pronto a rinunciare alle proprie liberta' fondamentali per 
comprarsi briciole di temporanea sicurezza non merita ne' la liberta' 
ne' la sicurezza.(Benjamin Franklin - dalla Risposta al Governatore, 
Assemblea della Pennsylvania, 11 novembre 1755)



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

Bug#747256: Chocolate Doom should be split into separate packages

[Simon Howard]

Late reply so apologies for not responding sooner.

On 8 May 2014 03:16, Fabian Greffrath  wrote:

> With the split approach I would also have to separate -server and -setup
> into different packages and introduce rather complex inter-package
> dependencies.


Chocolate Doom's 'make install' rule installs separate copies of
chocolate-setup as chocolate-doom-setup, chocolate-heretic-setup, etc.
There isn't actually need to make a common package and use symlinks.

As for chocolate-server, I've actually stopped distributing binaries of
this for other platforms because I think it's misleading. People get the
mistaken impression that they need to run a dedicated server if they want
to play a network game and most of the time this isn't the case. Usually
one of the clients acts as a server; if necessary it's possible to run a
dedicated server as chocolate-doom -dedicated.

The only situation in which you'd want to use chocolate-server is if you
were running it as a permanent dedicated server (the one that appear on
master.chocolate-doom.org). Very few people do that. If you want Debian to
support that use case it should probably be a separate package anyway, as
chocolate-server is a smaller binary that doesn't have all the dependencies
of the main client binaries.

-- 
Simon Howard
https://soulsphere.org/

Bug#671796: pacpl: Error when creating ogg tag

[Maxime Chatelle]

tag 671796 + confirmed
thanks


Hi,

New upstream release (5.0.1) fixes this problem but I'm late to hope an
integration into Jessie :/ But it will be available into experimental
when done.

I can try to import patch from 5.0.1 but that can be a non trivial task
(and somewhere pointless because when possible, the package will be
upgraded to 5.0.1). If the upstream git history is clear, maybe. I will
look at that.

Or add some code to ensure .wav deletion (but the ogg tags will missing).


--
Maxime Chatelle (xakz)
gpg: 5111 3F15 362E 13C6 CCDE  03BE BFBA B6E3 24AE 0C5B


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

Bug#767029: chirp: diff for NMU version 0.4.1-1.0

[anarcat]

Control: tags 767029 + patch
Control: tags 767029 + pending

Dear maintainer,

I've prepared an NMU for chirp (versioned as 0.4.1-1.0) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
diff -Nru chirp-0.4.0/chirp/__init__.py chirp-0.4.1/chirp/__init__.py
--- chirp-0.4.0/chirp/__init__.py	2014-03-25 14:57:18.0 -0400
+++ chirp-0.4.1/chirp/__init__.py	2014-10-27 16:56:15.0 -0400
@@ -13,7 +13,7 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
 
-CHIRP_VERSION="0.4.0"
+CHIRP_VERSION="0.4.1"
 
 import os
 import sys
diff -Nru chirp-0.4.0/chirp/uv5r.py chirp-0.4.1/chirp/uv5r.py
--- chirp-0.4.0/chirp/uv5r.py	2014-03-17 03:01:31.0 -0400
+++ chirp-0.4.1/chirp/uv5r.py	2014-10-27 16:56:15.0 -0400
@@ -360,6 +360,16 @@
 print "_firmware_version_from_image: " + util.hexprint(version)
 return version
 
+def _special_block_from_data(data, special_block_start, special_block_stop):
+special_block_tag = data[special_block_start:special_block_stop]
+return special_block_tag
+
+def _special_block_from_image(radio):
+special_block = _special_block_from_data(radio.get_mmap(), 0x0CFA, 0x0D01)
+if CHIRP_DEBUG:
+print "_special_block_from_image: " + util.hexprint(special_block)
+return special_block
+
 def _do_ident(radio, magic):
 serial = radio.pipe
 serial.setTimeout(1)
@@ -427,6 +437,11 @@
 version = block[48:64]
 return version
 
+def _get_radio_special_block(radio):
+block = _read_block(radio, 0xCF0, 0x40)
+special_block = block[2:9]
+return special_block
+
 def _ident_radio(radio):
 for magic in radio._idents:
 error = None
@@ -479,13 +494,22 @@
 
 image_version = _firmware_version_from_image(radio)
 radio_version = _get_radio_firmware_version(radio)
-print "Image is %s" % repr(image_version)
-print "Radio is %s" % repr(radio_version)
+print "Image Version is %s" % repr(image_version)
+print "Radio Version is %s" % repr(radio_version)
 
 if not any(type in radio_version for type in BASETYPE_LIST):
 raise errors.RadioError("Unsupported firmware version: `%s'" %
 radio_version)
 
+image_special_block = _special_block_from_image(radio)
+radio_special_block = _get_radio_special_block(radio)
+print "Image Special Block is " + util.hexprint(image_special_block)
+print "Radio Special Block is " + util.hexprint(radio_special_block)
+
+if image_special_block != radio_special_block:
+raise errors.RadioError("Image not supported by radio: `%s'" %
+radio_special_block)
+
 # Main block
 for i in range(0x08, 0x1808, 0x10):
 _send_block(radio, i - 0x08, radio.get_mmap()[i:i + 0x10])
diff -Nru chirp-0.4.0/debian/changelog chirp-0.4.1/debian/changelog
--- chirp-0.4.0/debian/changelog	2014-06-26 14:59:21.0 -0400
+++ chirp-0.4.1/debian/changelog	2014-10-27 17:42:34.0 -0400
@@ -1,3 +1,11 @@
+chirp (0.4.1-1.0) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * new upstream version fixing critical issue with some Baofeng radios
+(Closes: #767029)
+
+ -- Antoine Beaupré   Mon, 27 Oct 2014 17:08:43 -0400
+
 chirp (0.4.0-1) unstable; urgency=low
 
   * new upstream version, thanks to Christopher Knadle for his help with it
diff -Nru chirp-0.4.0/PKG-INFO chirp-0.4.1/PKG-INFO
--- chirp-0.4.0/PKG-INFO	2014-03-25 14:57:20.0 -0400
+++ chirp-0.4.1/PKG-INFO	2014-10-27 16:56:15.0 -0400
@@ -1,6 +1,6 @@
 Metadata-Version: 1.0
 Name: chirp
-Version: 0.4.0
+Version: 0.4.1
 Summary: UNKNOWN
 Home-page: UNKNOWN
 Author: UNKNOWN


signature.asc
Description: Digital signature

Bug#767034: sslh has USELIBWRAP off by default

[Guillaume Delacour]

fixed 767034 1.16-1
thanks

Le lundi 27 octobre 2014 à 22:36 +0100, Christian Weinberger a écrit :
> Package: sslh
> Version: 1.13b-3.2
> Severity: important
> 
> Dear Maintainer,

Hi,

> 
> sslh has USELIBWRAP off by default while openssh-server has libwrap support 
> enabled by default in Debian.
> So sslh default is not in line with the openssh-server default, which is in 
> my eyes not what I expected and therefore a security risk.
> 
> Recommendation: Activate USELIBWRAP by default.

USELIBWRAP will be used in the next stable release 1.16-1 (and with
LIBCAP for GNU/Linux):

http://anonscm.debian.org/cgit/collab-maint/sslh.git/tree/debian/rules#n20

> 
> 
> Best regards,
> Christian
> 
> -- System Information:
> Debian Release: 7.7
>   APT prefers stable
>   APT policy: (600, 'stable'), (500, 'testing'), (50, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16-0.bpo.2-amd64 (SMP w/2 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to de_DE.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages sslh depends on:
> ii  adduser   3.113+nmu3
> ii  debconf   1.5.49
> ii  libc6 2.19-11
> ii  libconfig91.4.8-5
> ii  lsb-base  4.1+Debian8+deb7u1
> ii  update-inetd  4.43
> 
> Versions of packages sslh recommends:
> ii  apache2  2.2.22-13+deb7u3
> ii  apache2-mpm-prefork [httpd]  2.2.22-13+deb7u3
> ii  dropbear [ssh-server]2012.55-1.3
> ii  openssh-server [ssh-server]  1:6.0p1-4+deb7u2
> 
> Versions of packages sslh suggests:
> ii  xinetd [inet-superserver]  1:2.3.14-7.1+deb7u1
> 
> -- Configuration Files:
> /etc/default/sslh changed [not included]
> 
> -- debconf information excluded



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

Bug#766195: [PATCH] ipv6: reuse ip6_frag_id from ip6_ufo_append_data

[Ben Hutchings]

On Mon, 2014-10-27 at 21:10 +0100, Julien Cristau wrote:
> On Mon, Oct 27, 2014 at 13:40:44 +, Ben Hutchings wrote:
> 
> > I've now written and tested patches for that remaining regression.
> > 
> > Source at:
> > https://people.debian.org/~benh/packages/linux_3.2.63-2+deb7u1.dsc
> > https://people.debian.org/~benh/packages/linux_3.2.63-2+deb7u1.debian.tar.xz
> > 
> > Binary at:
> > https://people.debian.org/~benh/packages/linux-image-3.2.0-4-amd64_3.2.63-2+deb7u1_amd64.deb
> > 
> > There's a signed .changes file there as well, for verification
> > (distribution=UNRELEASED in case you are wondering).
> > 
> > Additional testing would be appreciated.
> > 
> Installed your package on salieri.debian.org now.  Anything we should
> look out for?

1. It shouldn't crash, obviously.

2. You may see a one-time warning about using UFO when we don't claim to
support it, until you also upgrade the guest kernels.  I found that
libvirt+QEMU tells guests they can use UFO even if the host tap device
refuses to support it.

3. UDP packets from the guest that require fragmentation should each get
a different fragmentation ID, and if they are sent at a low rate, the
IDs should not be consecutive (that was the purpose of the change in
3.2.63).  You can check this by capturing and dumping IPv6 fragments on
a *remote* machine:

tcpdump -i eth0 -v 'ip6[6]==44'

Example output:

21:33:12.57 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag (0x0276214b:0|1448) 
32794 > discard: UDP, length 10240
21:33:12.522271 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276214b:1448|1448)
21:33:12.522282 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276214b:2896|1448)
21:33:12.522293 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276214b:4344|1448)
21:33:12.522301 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276214b:5792|1448)
21:33:12.522312 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276214b:7240|1448)
21:33:12.522322 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276214b:8688|1448)
21:33:12.522334 IP6 (hlim 64, next-header Fragment (44) payload length: 120) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276214b:10136|112)
21:33:13.231373 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag (0x0276218f:0|1448) 
59424 > discard: UDP, length 10240
21:33:13.231414 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276218f:1448|1448)
21:33:13.231424 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276218f:2896|1448)
21:33:13.231432 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276218f:4344|1448)
21:33:13.231441 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276218f:5792|1448)
21:33:13.231450 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276218f:7240|1448)
21:33:13.231460 IP6 (hlim 64, next-header Fragment (44) payload length: 1456) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276218f:8688|1448)
21:33:13.231472 IP6 (hlim 64, next-header Fragment (44) payload length: 120) 
fe80::5604:a6ff:fec4:8ddd > fe80::2a92:4aff:fe2f:b2d: frag 
(0x0276218f:10136|112)

The first number after 'frag' is the fragmentation ID; here there are
two sets of fragments from two original 10K packets.

This should work whether or not the guest kernel is upgraded.

Ben. 

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers


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

Bug#626111:

[Augustine Coronado]

I want to know if somebody was buying my phone

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

[Ian Jackson]

Helmut Grohne writes ("Bug#766708: Processed: Re: Bug#766708: breaks multiarch 
cross building"):
> Since it is my interest to not cause more work on Matthias, I will try
> to summarize his POV.

Thanks.

> The most obvious bug is the one mentioned in the patch: #760770
> It is about a bug in the implementation of with_deps_on_target_arch (the
> contended feature).

I think I may not understand what's going on here.  In your mail to
the TC, you say:

   it was possible to build a gcc cross compiler with different
   properties from the default build by setting
   with_deps_on_target_arch_pkgs=yes and DEB_CROSS_NO_BIARCH=yes.

You mean setting these as environment variables ?  If so then it would
seem that this feature has no direct effect on anyone who is not
trying to use it.  Is that correct ?

Of course it does have a maintenance burden on the package maintainer,
which is what Don is asking about.

#760770 shows an element of that but it is immediately obvious from
the initial report that something odd is going on and it contains a
link to #720363 which mentions
https://wiki.debian.org/MultiarchCrossToolchainBuild which talks
abouit the with_deps_on_target_arch_pkgs feature.  It doesn't appear
that #760770 has taken a great deal of Matthias's time, although it
did necessitate some bug triage.

Are the maintainers of the disputed features subscribed to the
appropriate packages in the PTS ?  Does Matthias welcome help triaging
these bugs ?  It seems to me that it would be easy to come up with a
workflow that allowed Matthias to usertag these kind of bugs and hand
them over to the cross teams.

> Other bugs that may be relevant here are the ones that Matthias filed
> against cross-gcc-4.9-* (packages that make use of
> with_deps_on_target_arch). These are:
...
>  armhf: #766619 #766626

What are the cross-gcc-4.9-armhf packages that are referred to ?

Ian.


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

Bug#767032: better patch attached

[Holger Levsen]

Hi,

see attached.


cheers,
Holger
From bf5592a73c4d0352c3b24e52a40d0af729d88677 Mon Sep 17 00:00:00 2001
From: Holger Levsen 
Date: Mon, 27 Oct 2014 22:19:38 +0100
Subject: [PATCH] munin_stats plugin: only graph munin-graph if
 graph_strategy=cron (Closes: #767032)

---
 plugins/node.d/munin_stats.in | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/plugins/node.d/munin_stats.in b/plugins/node.d/munin_stats.in
index d85a2cb..dcc5b23 100644
--- a/plugins/node.d/munin_stats.in
+++ b/plugins/node.d/munin_stats.in
@@ -27,9 +27,14 @@ use strict;
 use warnings;
 
 use Munin::Plugin;
+use Munin::Master::GraphOld;
 
-my @logs = qw/update graph html limits/;
+my @logs = qw/update html limits/;
 my $logdir = ($ENV{'logdir'} || $ENV{'MUNIN_LOGDIR'} || '@@LOGDIR@@');
+my $conffile = "$Munin::Common::Defaults::MUNIN_CONFDIR/munin.conf";
+if (! graph_check_cron() ) {
+ push  (@logs, "graph");
+}
 
 if ($ARGV[0] and $ARGV[0] eq 'autoconf') {
 my $munin_update_location = 
@@ -51,9 +56,13 @@ if ($ARGV[0] and $ARGV[0] eq 'autoconf') {
 }
 
 if ($ARGV[0] and $ARGV[0] eq "config") {
-print "graph_title Munin processing time\n",
-  "graph_info This graph shows the run time of the four different processes making up a munin-master run.  Munin-master is run from cron every 5 minutes and we want each of the programmes in munin-master to complete before the next instance starts.  Especially munin-update and munin-graph are time consuming and their run time bears watching. If munin-update uses too long time to run please see the munin-update graph to determine which host is slowing it down.  If munin-graph is running too slow you need to get clever (email the munin-users mailing list) unless you can buy a faster computer with better disks to run munin on.\n",
-  "graph_args --base 1000 -l 0\n",
+print "graph_title Munin processing time\n";
+if (! graph_check_cron() ) {
+print  "graph_info This graph shows the run time of the four different processes making up a munin-master run.  Munin-master is run from cron every 5 minutes and we want each of the programmes in munin-master to complete before the next instance starts.  Especially munin-update and munin-graph are time consuming and their run time bears watching. If munin-update uses too long time to run please see the munin-update graph to determine which host is slowing it down.  If munin-graph is running too slow you need to get clever (email the munin-users mailing list) unless you can buy a faster computer with better disks to run munin on.\n";
+} else {
+print  "graph_info This graph shows the run time of the thre different processes making up a munin-master run.  Munin-master is run from cron every 5 minutes and we want each of the programmes in munin-master to complete before the next instance starts.  Especially munin-update is time consuming and its run time bears watching. If munin-update uses too long time to run please see the munin-update graph to determine which host is slowing it down.\n";
+}
+print "graph_args --base 1000 -l 0\n",
   "graph_scale yes\n",
   "graph_vlabel seconds\n",
   "graph_category munin\n";
@@ -63,8 +72,10 @@ if ($ARGV[0] and $ARGV[0] eq "config") {
 }
 print "update.warning 240\n";
 print "update.critical 285\n";
-print "graph.warning 240\n";
-print "graph.critical 285\n";
+if (! graph_check_cron() ) {
+print "graph.warning 240\n";
+print "graph.critical 285\n";
+}
 exit 0;
 }
 
-- 
1.9.1



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

Bug#766870: podget: MOST_RECENT=1 and "-r 1" or "--recent 1" not working in 0.7.3

[Dave Vehrs]

On Sun, 2014-10-26 at 13:22 +0100, Martintxo wrote:
> Package: podget
> Version: 0.7.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I'm using podget 0.5.8-1 in a server with Debian stable for a small FM radio.
> It's working fine. Many thanks for it.
> 
> In that server I have this setting in podgetrc (I repeat, is podget 0.5.8):
>  most_recent=1
> It is working fine, it only downloads the last (mor new) episode of the 
> podcast,
> and this is what I need in this case :-D
> 
> Now, I'm testing podget in Debian testing for know if it is working in the 
> same
> way. I need to stay ready for the new version when Debian testing will be
> stable.
> 
> So, in my home computer, with Debian testing and podget 0.7.3-1, I create a 
> new
> config: delete the full ~/.podget dir, and run podget -vv. It says that it 
> will
> donwload one episode from one podcast to test it. In my case it download some
> episodes, not one.
> 
> Well, I need to check my config like in the radio server. I change the 
> podgetrc
> in my home computer (for podget 0.7.3) and put:
>  MOST_RECENT=1
> and serverlist for put one of my podcast:
>  http://www.democracynow.org/podcast-es.xml DemocracyNow
> and test it. And the same, It downloads all the podcast in this URL (in this
> moment it have 11 "enclosure", and I get 11 mp3 in the download dir...)
> 
> So I test the "-r 1" and the "--recent 1" comand line options, and I get the
> same result.
> 
> I don't know what happens, I check the source code of both scripts (0.5.8 and
> 0.7.3) and look pretty the same in this case. In any way, the line at 1495
> (0.7.3):
>  INDEXFILE=$(echo "${INDEXFILE}" | cut -d \  -f -"${MOST_RECENT}")
> look wrong, it isn't the "-d" option of cut must be surrounded with quotes?
> (and there are 2 spaces later)...
> 
> Well. That is my report. Sorry for my bad english, I'm and spanish speaker.
> Greetings. Martintxo.

Excellent timing.  I had an Arch user report the same issue and it took
me a little while to track the issue down.  Initially I tracked it down
to the exact line you found but changing that only fixed some of the
feeds that were having issues.  However I was able to follow it upstream
from there and found the issue was not being filtered by the sed
statements at the initial INDEXFILE generation.  I've released an
updated version on Sourceforge, and submitted it to Debian Mentors where
I hope it will be soon accepted.  This is a relatively small update and
so I don't anticipate any issues.

Thank you for the report and I must say your English is much better than
my Spanish.  

-- 
Dave Vehrsdve...@gmail.com


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

Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime

[paul . szabo]

Dear Mike,

Thanks for the various infos, will follow up sometime.

> ... I decided not to package MDM for Debian ... [conflict] GDMv3 ...

Pity, I would be happy to ditch the buggy GDM3. On wheezy I still use
GDM2 from squeeze (replacing GDM3), unfortunately that does not work on
jessie anymore.

I have my "own" LTSP-lookalike, a PXE-booted Linux environment, that
runs "Xorg -query server", and is where I am looking to improve X
traffic.

(Now to get on with some coding/patching in nxproxy...)

Thanks, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia


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

Bug#767034: sslh has USELIBWRAP off by default

[Christian Weinberger]

Package: sslh
Version: 1.13b-3.2
Severity: important

Dear Maintainer,

sslh has USELIBWRAP off by default while openssh-server has libwrap support 
enabled by default in Debian.
So sslh default is not in line with the openssh-server default, which is in my 
eyes not what I expected and therefore a security risk.

Recommendation: Activate USELIBWRAP by default.


Best regards,
Christian

-- System Information:
Debian Release: 7.7
  APT prefers stable
  APT policy: (600, 'stable'), (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-0.bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sslh depends on:
ii  adduser   3.113+nmu3
ii  debconf   1.5.49
ii  libc6 2.19-11
ii  libconfig91.4.8-5
ii  lsb-base  4.1+Debian8+deb7u1
ii  update-inetd  4.43

Versions of packages sslh recommends:
ii  apache2  2.2.22-13+deb7u3
ii  apache2-mpm-prefork [httpd]  2.2.22-13+deb7u3
ii  dropbear [ssh-server]2012.55-1.3
ii  openssh-server [ssh-server]  1:6.0p1-4+deb7u2

Versions of packages sslh suggests:
ii  xinetd [inet-superserver]  1:2.3.14-7.1+deb7u1

-- Configuration Files:
/etc/default/sslh changed [not included]

-- 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#762753: moreinfo

[Bastien ROUCARIES]

control: tags -1 + moreinfo

Do you have some normative element about this tag?

Bastien


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

Bug#746466: proofgeneral hijacks the emacs icon identity

[Hendrik Tews]

> Incidentally, after removing that entry, the ProofGeneral icon does
> still appear in the Application menu even though its not used for

Yes, I believe I also saw this. I attributed this to some caching
and hope that this goes away when we solve the other problem.

Hendrik


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

Bug#766316: Unable to reproduce

[Emilien Klein]

Running a en_US locale (see below), I have created a folder called
~/Téléchargements/ and symlinked a file in that folder. The subtitle is
downloaded correctly without the mentioned Exception.

This is the relevant extract when running subdownloader in debug mode:

$ subdownloader -d
[snip]
[22:08] DEBUG::subdownloader.gui.main # Downloading to:
u'/home/emilien/T\xe9l\xe9chargements/DDLValley.rocks_The.Rise.and.Rise.of.Bitcoin.2014.HDRip.XviD.AC3-EVO.srt'
[22:08] DEBUG::subdownloader.gui.main # Trying to download subtitle
'/home/emilien/Téléchargements/DDLValley.rocks_The.Rise.and.Rise.of.Bitcoin.2014.HDRip.XviD.AC3-EVO.srt'
[22:08] DEBUG::subdownloader.gui.main # Downloading subtitle
'/home/emilien/Téléchargements/DDLValley.rocks_The.Rise.and.Rise.of.Bitcoin.2014.HDRip.XviD.AC3-EVO.srt'
[22:08] DEBUG::subdownloader.httpsearch.OSHttpSearch # Downloading
subtitle from url:
http://www.opensubtitles.org/en/download/file/1954435660.gz
[22:08] DEBUG::subdownloader.httpsearch.OSHttpSearch # Unpacking and
savinng to:
/home/emilien/Téléchargements/DDLValley.rocks_The.Rise.and.Rise.of.Bitcoin.2014.HDRip.XviD.AC3-EVO.srt




Sylvestre, do you have any idea how to reproduce this bug?
Could you try to run the program with the English locale and that folder
with an accent in its name, and tell us if the same Traceback occurs?

$ LANG=en_US.UTF-8 subdownloader -d



See below for further tests I've tried.



Note that when running the program as previously mentioned, I do see the
é character nicely in the folder tree structure on the left side of the
user interface.




I have performed a new test, this time "forcing" the locale to French
(while not having it installed on my dev system):

emilien@debiansid:~/Téléchargements$ LANG=fr_FR.UTF-8 subdownloader -d
[22:15] DEBUG::subdownloader.gui.main # Building main dialog
[22:15] DEBUG::subdownloader.gui.main # Showing main dialog
[22:15] DEBUG::subdownloader.gui.main # Scanning translation files .mo
in folder: locale
[22:15] DEBUG::subdownloader.gui.main # Found these translations
languages: []
[22:15] DEBUG::subdownloader.gui.main # Interface language: en
[22:15] DEBUG::subdownloader.gui.main # Current directory:
/home/emilien/Tlchargements
[22:15] DEBUG::subdownloader.SDService.SDService # Creating Server with
server = None and proxy = None
[22:15] DEBUG::subdownloader.SDService.SDService # Creating XMLRPC
server connection... to server http://api.opensubtitles.org/xml-rpc with
proxy None
[22:15] DEBUG::subdownloader.SDService.SDService # Connecting with
parameters ('http://api.opensubtitles.org/xml-rpc', None)
[22:15] DEBUG::subdownloader.WebService # successfully tested connection
[22:15] DEBUG::subdownloader.SDService.SDService # Trying direct
connection...
[22:15] DEBUG::subdownloader.SDService.SDService # ...connected
[22:15] DEBUG::subdownloader.SDService.SDService # connection connected

[22:15] DEBUG::subdownloader.SDService.SDService # Creating Server with
server = None and proxy = None
[22:15] DEBUG::subdownloader.SDService.SDService # Creating XMLRPC
server connection... to server http://sddb.subdownloader.net/xmlrpc/
with proxy None
[22:15] DEBUG::subdownloader.SDService.SDService # Connecting with
parameters ('http://sddb.subdownloader.net/xmlrpc/', None)
[22:15] DEBUG::subdownloader.WebService # successfully tested connection
[22:15] DEBUG::subdownloader.SDService.SDService # Trying direct
connection...
[22:15] DEBUG::subdownloader.SDService.SDService # ...connected
[22:15] DEBUG::subdownloader.SDService.SDService # connection connected

[22:15] DEBUG::subdownloader.SDService.SDService # 
[22:15] DEBUG::subdownloader.SDService.SDService # Logging in (username:
)...
[22:15] DEBUG::subdownloader.SDService.SDService # Login ended in 0.035
with status: 200 OK
[22:15] DEBUG::subdownloader.SDService.SDService # Session ID:
vlpf67sdhldsunvmumo1loqm26
[22:15] DEBUG::subdownloader.SDService.SDService # 



The program starts correctly, connects to the server, but:
- The user interface is in English
- The folder that is supposed to have the accent is displayed as
"Tlchargement" in the folder structure.


When clicking on that folder, an exception occurs:

[22:17] DEBUG::subdownloader.FileManagement.FileScan # Scanning:
/home/emilien/Tlchargements
Traceback (most recent call last):
  File "/usr/share/pyshared/subdownloader/gui/main.py", line 944, in
onFolderTreeClicked
self.SearchVideos(folder_path)
  File "/usr/share/pyshared/subdownloader/gui/main.py", line 781, in
SearchVideos
videos_found,subs_found = FileScan.ScanFilesFolders(path,recursively
= True,report_progress = self.progress)
  File "/usr/share/pyshared/subdownloader/FileManagement/FileScan.py",
line 50, in ScanFilesFolders
all_subs_found +=
ScanSubtitlesFolder(os.path.dirname(path),recursively =
False,report_progress=report_progress, progress_end=progress_end)
  File "/usr/share/pyshared/subdownloader/FileManagement/FileScan.py",
line 124, in ScanSubtitlesFolder

Bug#766148: RFS: sleepenh/1.3.2 [ITA]

[Tobias Frost]

Am Montag, den 27.10.2014, 10:52 +0100 schrieb Nicolas Schier:
> Dear Tobi,
> 
> thanks for reviewing and sponsoring!  Especially the 
> native-vs-non-native link was quite enlightening.
> 
> A few minutes ago I uploaded the new files
> 
>   http://mentors.debian.net/debian/pool/main/s/sleepenh/sleepenh_1.3-2.dsc
> 
> including the following changes:
> 
>  * Fixed changelog for non-native package version
> 
>  * debian/compat is now 9 (was 5) and updated build-dependencies 
>appropriately (debhelper >= 9)
> 
>  * git-Repository moved to gitorious, updated Vcs-* fields;
>(obs: cleaned up repo history, non-ff-compatible)
> 
>  * Fixed debian/copyright:
>- Removed dead link in debian/copyright to upstream homepage (there 
>  is no upstream homepage anymore)
>- Mention original author also for debian/* files
>- Same license for debian/* as for upstream files
> 
>  * Removed obsolete postinst script
> 
> As far as I understood, these should fix all your remarks.
> 
> Thanks again and kind regards,
> Nicolas


d/copyright: The years for debian/* are wrong. Pedro was maintaining the
packgage  until 2008,
and for Files* the years are 2003-2008 (2008 is the year of the manpage)
(Sorry, I missed that before, please ping me again.)

Please remove the template text from d/rules, so lines 3-12
I think you don't need to export DH_OPTIONS.

--
tobi


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

Bug#746957: pacpl: Please update to newer upstream release

[Maxime Chatelle]

tag 746957 + confirmed
thanks

Hi,

Yes, I'm working on it but it will not ready for Jessie
(Nov 5). BTW, I will make it available in experimental.

--
Maxime Chatelle (xakz)
gpg: 5111 3F15 362E 13C6 CCDE  03BE BFBA B6E3 24AE 0C5B


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

Bug#767033: ITP: python-affine -- Python library for handling affine planar transformations

[Johan Van de Wauw]

Package: wnpp
Severity: wishlist
Owner: Johan Van de Wauw 

* Package name: python-affine
  Version : 1.0.1
  Upstream Author : Sean Gillies
* URL : https://github.com/sgillies/affine
* License : BSD-3 clause
  Programming Lang: Python
  Description : Python library for handling affine planar transformations

This library contains functions for handling affine transformations of the 
plane.
It can be used in georeferenced datasets to transfer image to world coordinates.


This (tiny) library is a prerequisite for rasterio for which I filed an ITP 
(#767027)
earlier today.

I intent to maintain this package in Debian GIS.


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

Bug#766113: man-db: "man -a" sends a (interactive) message to standard error

[Colin Watson]

Control: tag -1 fixed-upstream

On Mon, Oct 20, 2014 at 10:19:13PM +, Bjarni Ingi Gislason wrote:
>   "man -a man" send the message (if connected to a terminal)
> 
> --Man-- next: man(1posix) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]
> 
> to the standard error instead of standard output (or /dev/tty).  This
> message is not of type warning or error!

Thanks for your report.  I've fixed this upstream for the next release:

  
http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=5e42848130972ae70d1c0154abf39c5add0f6c43

-- 
Colin Watson   [cjwat...@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#765166: Wontfix ?

[Bastien ROUCARIES]

Hi,

I have two possibilities:
- avoid to run this test for patch (but it will not check header)
- wontfix this kind of bug and override

Bastien


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

Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime

[Mike Gabriel]

Hi Paul,

On  Mo 27 Okt 2014 22:02:02 CET, paul.szabo wrote:


Dear Mike,


A MATE session is a session running the MATE desktop environment.
It is available in Debian jessie. MATE is GNOME desktop environment
(version 2) continued. It is _the_ recommended desktop environment for
remote desktop usage on Linux at the moment. ...


Where is that recommendation documented?


https://ubuntu-mate.org/about/ (search the page for "X2Go" or "LTSP").


Does MATE contain a replacement for GDM, with XDMCP support?
Or, how else to provide for remote thin clients?


The X2Go (and the LTSP) project provides their own thinclient PXE chroots.

In X2Go, I am currently working on X2Go Thinclient Environment 1.5  
[1]. The thinclient launches a minimal desktop locally on the thin  
client (also a MATE desktop, with iceweasel and flashplugin  
installed). On that minimal thinclient desktop (session comes up with  
autologin feature of lightdm), you find a desktop icon "X2Go Client".  
With X2Go Client you can connect to other X2Go Servers on your network.


X2Go also supports connecting to a display/login manager (like  
GDM/KDM) that supports the XDMCP protocol. MATE is not tied to any  
display/login manager per-se (neither is GNOME tied to GDM, nor KDE  
tied to KDM).


When using LTSP, you run the LTSP Display Manager on the LTSP Servers  
and hook the LTSP thinclient onto them.


Back to your question, if MATE has a display manager of its own: The  
old GDMv2 code has been forked by the Linux Mint project (MDM -> Mint  
Display Manager). However, the fork was not done cleanly and there are  
many files that cannot be installed in parallel with GDMv3. :-(


Also, the efforts of two MATE developers of providing MDM patches that  
makes the fork a real fork (using a completely different file  
namespace compared to its origin GDMv2) had been rejected by the Linux  
Mint maintainers a year back or so. Thus, in terms of Debian, I  
decided not to package MDM for Debian (as we would get in trouble with  
the GDMv3 package and I personally like having an cooperative partner  
on the upstream side).



Thanks, Paul


Greets,
Mike

[1] http://code.x2go.org/gitweb?p=x2gothinclient.git;a=summary

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpC5uvTuz4Mu.pgp
Description: Digitale PGP-Signatur

Bug#767029: possible fix

[Antoine Beaupré]

hello

the diff for the package is trivial, so I'm preparing a NMU.

I have used dgit to inject the 0.4.0 release from the archive into the
git repo, it worked well. it would be probably better to get the real
0.4.0 git history from the actual release instead of this however, so
I'll refrain from pushing the git history until this is accepted as an
NMU or other instructions are given.

I'll send the diff and upload to delayed/7 shortly, hopefully this will
make it to the jessie freeze, but I am not sure it will since the 10
days delay is already passed. :(

A.

-- 
A man is none the less a slave because he is allowed to choose a new
master once in a term of years.
 - Lysander Spooner


pgpuQWv_hDcVh.pgp
Description: PGP signature

Bug#767032: munin-plugins-core: munin_stats should not try to graph munin-graph if graph_strategy=cgi

[Holger Levsen]

package: munin-plugins-core
tags: patch upstream
version: 2.1.9-1
severity: minor
found: 2.0.24-1

Hi,

the munin_stats plugin should not try to graph munin-graph if graph_strategy 
is set to cgi. Patch attached, though I'm not sure this is the best way to do 
this... it's certainly a working way ;-)


cheers,
Holger
From 579610962834ef99bb3e85da0de76507ca11e493 Mon Sep 17 00:00:00 2001
From: Holger Levsen 
Date: Mon, 27 Oct 2014 22:19:38 +0100
Subject: [PATCH] munin_stats plugin: only graph munin-graph if
 graph_strategy=cron

---
 plugins/node.d/munin_stats.in | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/plugins/node.d/munin_stats.in b/plugins/node.d/munin_stats.in
index d85a2cb..2653ce1 100644
--- a/plugins/node.d/munin_stats.in
+++ b/plugins/node.d/munin_stats.in
@@ -27,9 +27,14 @@ use strict;
 use warnings;
 
 use Munin::Plugin;
+use Munin::Master::GraphOld;
 
-my @logs = qw/update graph html limits/;
+my @logs = qw/update html limits/;
 my $logdir = ($ENV{'logdir'} || $ENV{'MUNIN_LOGDIR'} || '@@LOGDIR@@');
+my $conffile = "$Munin::Common::Defaults::MUNIN_CONFDIR/munin.conf";
+if (! graph_check_cron() ) {
+ push  (@logs, "graph");
+}
 
 if ($ARGV[0] and $ARGV[0] eq 'autoconf') {
 my $munin_update_location = 
-- 
1.9.1



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

Bug#690973: Still interested in packaging it with proper patches?

[Lisandro Damián Nicanor Pérez Meyer]

Markus: I have just asked upstream if he would take some patches to fix the 
environment variables issues, and I think that I could handle some other 
packaging issues too.

If upstream accepts the patches, would you reconsider packaging it for Debian?

Kinds regards, Lisandro.

-- 
http://mx.grulic.org.ar/lurker/message/20081108.174208.4f42e55c.es.html
Así se corrobora el software legal en Argentina

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


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

Bug#766703: openafs-krb5: sparc build of aklog crashes

[Russ Allbery]

Benjamin Kaduk  writes:

> The longjump error is going to be coming from src/lwp/process.o, which
> is compiled from either verious assembly files or a C file depending on
> the architecture.  I don't have any sparc-linux systems, so I won't be
> able to do any direct diagnosis of this issue (which is almost certainly
> sparc-linux-specific).  From the build log, it looks like the C version
> is being used here; there haven't been any changes to that file in
> upstream between 1.6.1 and 1.6.9.  We don't have any Debian-specific
> patches to that file, either.  (In fact, we didn't have any Debian
> patches at all for 1.6.10~pre1.)

Another possibility is glibc changing something about what it expects.  It
wouldn't be the first time that LWP has been broken by changes to glibc
even when there was no source changes to LWP itself.

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


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