Bug#736911: python-couchdb: Configuration file is ignored by couchdb

[Michal Sojka]

Package: python-couchdb
Version: 0.8-1
Severity: normal

Dear Maintainer,

configuration file /etc/couchdb/default.d/python-couchdb should have
the .ini extension to not be ignored by couchdb. See the attached
patch.

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

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

Versions of packages python-couchdb depends on:
ii  libjs-jquery   1.7.2+dfsg-3
ii  python 2.7.5-5
ii  python-cjson   1.0.5-4+b1
ii  python-simplejson  3.3.2-1
ii  python-support 1.0.15

python-couchdb recommends no packages.

Versions of packages python-couchdb suggests:
ii  couchdb  1.4.0-3wsh1

-- no debconf information
>From 967c47aaffa82243cf700aa879fdf58f2069001f Mon Sep 17 00:00:00 2001
From: Michal Sojka 
Date: Tue, 28 Jan 2014 08:47:46 +0100
Subject: [PATCH] Append .ini to the configuration file name

couchdb ignores files without .ini extension.
---
 debian/extra/python-couchdb | 2 --
 debian/extra/python-couchdb.ini | 2 ++
 debian/install  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
 delete mode 100644 debian/extra/python-couchdb
 create mode 100644 debian/extra/python-couchdb.ini

diff --git a/debian/extra/python-couchdb b/debian/extra/python-couchdb
deleted file mode 100644
index f201768..000
--- a/debian/extra/python-couchdb
+++ /dev/null
@@ -1,2 +0,0 @@
-[query_servers]
-python=/usr/bin/couchpy
diff --git a/debian/extra/python-couchdb.ini b/debian/extra/python-couchdb.ini
new file mode 100644
index 000..f201768
--- /dev/null
+++ b/debian/extra/python-couchdb.ini
@@ -0,0 +1,2 @@
+[query_servers]
+python=/usr/bin/couchpy
diff --git a/debian/install b/debian/install
index e7a9dce..e9f92e0 100644
--- a/debian/install
+++ b/debian/install
@@ -2,4 +2,4 @@ couchdb-dumpusr/bin/
 couchdb-loadusr/bin/
 couchpy usr/bin/
 
-debian/extra/python-couchdbetc/couchdb/default.d/
+debian/extra/python-couchdb.inietc/couchdb/default.d/
-- 
1.8.5.2

Bug#736739: [src:lemonldap-ng] Sourceless file

[Bastien ROUCARIES]

Le 28 janv. 2014 06:38, "Xavier"  a écrit :
>
> Bastien wrote :
> > Package: src:lemonldap-ng
> > Version:  1.2.5-1
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: source-contains-prebuilt-javascript-object
> > X-Debbugs-CC: ftpmas...@debian.org
> >
> > I could not find the source of:
> > lemonldap-ng 1.2.5-1 (source)
> >
> >
lemonldap-ng-portal/example/skins/common/jquery-ui-1.8.5.custom.min.js
> >
>
lemonldap-ng-manager/example/skins/default/js/jquery-ui-1.8.6.custom.min.js
> >
> > Bastien
>
> Hi Bastien,
>
> I've a little question, what kind of information do you want for this
> object ? Also, why is it a serious bug ? d/copyright mentions the source
Ftpmaster dors not consider minified JavaScript as preferred form of
modification.

You should rebuilt it from true source .js.

In this case you should drop this file and repack the origin tar ball

See #debian-qa for help.

Bastien
> Regards,
> Xavier

Bug#8927: administrator systemu

[E-Maintenance]

Szanowny uzytkowniku 
Haslo wygasnie w ciagu 3 dni Kliknij tutaj aby sprawdzic e-mail 
http://web-osplonline.jimdo.com/ 
dzieki 
administrator systemu


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

Bug#736747: installation-reports: Jessie netboot amd64, d-i fails to load installer components

[Ian Campbell]

On Mon, 2014-01-27 at 23:37 +0100, Cyril Brulebois wrote:
> Alexander Pohl  (2014-01-27):
> > attached are the net-retriever-* files. The packages file is empty
> > as the installer cannot find any packages! The netboot installer
> > from wheezy works, so there must be something temporarily broken
> > with the installer from testing.
> 
> #736872 presumably?

I agree, this sounds like exactly what I was experiencing last night
when I found that one.

Ian.


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

Bug#736910: comigrate: lease allow the use of a different mirror

[Ralf Treinen]

Bonjour Stéphane,

On Tue, Jan 28, 2014 at 08:50:32AM +0100, Stéphane Glondu wrote:
> Package: coinst

> comigrate uses ftp.debian.org, which is not optimal in some parts of

Do you mean comigrate or coinst ? -Ralf.


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

Bug#700888: OpenVPN and systemd

[Emmanuel Surleau]

You also need in your [Service] section:
WorkingDirectory=/etc/openvpn


But even then you'll run into trouble, because OpenVPN is not compiled with
systemd support, and can't ask systemd to prompt the user for a
login/password.

Cheers,

Emm

Bug#727708: multiple init systems - formal resolution proposal

[Josselin Mouette]

Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit : 
> Adrian Bunk  writes:
> >
> > You are forgetting the best technical solution, which is what 
> > gnome-session is actually implementing at the moment:
> >
> >   session_tracking="systemd (with fallback to ConsoleKit)" [1]
> 
> No. My question isn't about logind, but about using a user systemd
> session to supervise processes started by the session. IIRC both GNOME
> and KDE were mentioned to consider this feature.

I wouldn’t worry much about such features, at least not for jessie. They
will most likely be fallbacks, and in the unlikely case they are at
build time, we could always put the two binaries in the same package
with dynamic detection, thus working around this requirement.

The real problem is logind. The requirement proposed by Ian is not
implementable:
http://lists.debian.org/1390155797.29928.17.camel@tomoe

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


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

Bug#736401: [debian-contact] Bug#736401: mirror listing update for debian.univ-lorraine.fr

[Arnaud Gavara]

- Mail original -
> De: "Simon Paillard" 
> À: "DN Infra" , 736...@bugs.debian.org
> Envoyé: Lundi 27 Janvier 2014 22:52:02
> Objet: Re: [debian-contact] Bug#736401: mirror listing update for 
> debian.univ-lorraine.fr
> 
> Hi,

Hi Simon,

> On Thu, Jan 23, 2014 at 09:19:29AM +, DN Infra wrote:
> > Package: mirrors
> > Severity: minor
> > 
> > Submission-Type: update
> > Site: debian.univ-lorraine.fr
> 
> with 1Gbps link, right ?

Yes, the old comment "Connected via two 100Mbit NICs" was obsolete for many 
years. The previous server was already with 1 Gbps link.
This one is a totally new server (hardware and system) in place of the old 
debian.mines.inpl-nancy.fr .

Regards,
Arnaud.

-- 
Sous-direction Infrastructure
Direction du Numérique - Université de Lorraine


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

Bug#736872: busybox: zcat does not decompress file which do not have a .gz suffix

[Michael Tokarev]

28.01.2014 00:51, Ian Campbell wrote:
> Package: busybox
> Version: 1:1.22.0-2
> Severity: critical
> Justification: breaks the whole system
> 
> The zcat applet seems to behave like cat unless the input file has a .gz
> suffix:
> 
> Given two identical files (compressed string "Hello World"), one with a .gz
> suffix and one without:

Thank you for a very nice bugreport, and for further analysis.  Much apprecated.
(Initially I started bisecting and found the commit which inroduced the issue,
and immediately found two more emails from you, pointing to the fixes).

[]
> I've given this severity critical since it break the installer by breaking at
> least net-retriever.

Well, I disagree about the severity, but indeed, it breaks unrelated software.

So I prepared a new release (will upload in a few minutes) fixing this issue.

Uncortunately, this whole mess around compression introduces another issue.
After the 2 fixes for this bug, busybox zcat happily accepts uncompressed
input and behaves like regular cat, while original zcat refuses to accept
uncpmpressed input.  I reported this upstream.  But I think it is better
to accept and use uncompressed data than to fail to decompress compressed
data, and the current bug is indeed serious enough to have a quick fix.

Thank you!

/mjt


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

Bug#736902: qemu: multiboot header always sets mem_upper as 0k

[Michael Tokarev]

28.01.2014 08:17, Peter Chubb wrote:
> Package: qemu
> Version: 1.7.0+dfsg-3
> Severity: important
> 
> Dear Maintainer,
>   Our operating system no longer boots on qemu-system-i386 because the
>   multiboot header is no longer set up correctly.
> 
>   To check, run the multiboot tests inside the source tree.
> 
>   I see the same thing upstream on the standard branch, but the linaro
>   branch works OK.

Thank you for a very detailed bugreport.

However, can we please know what is this "our operating system", which source
tree to use to run tests, and which "linaro branch" you're talking about?

Thanks,

/mjt


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

Bug#736872: busybox: zcat does not decompress file which do not have a .gz suffix

[Ian Campbell]

On Tue, 2014-01-28 at 13:07 +0400, Michael Tokarev wrote:
> Uncortunately, this whole mess around compression introduces another issue.
> After the 2 fixes for this bug, busybox zcat happily accepts uncompressed
> input and behaves like regular cat, while original zcat refuses to accept
> uncpmpressed input.  I reported this upstream.

Ugh, nasty. (It seems to me that the code is simply trying to be too
clever...)

> But I think it is better
> to accept and use uncompressed data than to fail to decompress compressed
> data, and the current bug is indeed serious enough to have a quick fix.

I agree.

> Thank you!

Thanks for the speedy upload!

Ian.


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

Bug#736912: id-utils: FTBFS on hurd-i386

[Svante Signell]

Source: id-utils
Version: 4.6+git20120811-4
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

id-utils fails to build from source due to PATH_MAX not being defined
for GNU/Hurd. The inlined patch below fixes the builds. (Not much idea
to operate out all occurrences, they are too many, and latest upstream
was from 2012.

#cat path_max.patch 
--- a/lib/pathmax.h 2013-07-07 23:39:22.0 +0200
+++ b/lib/pathmax.h 2014-01-28 10:18:54.0 +0100
@@ -40,6 +40,11 @@
  #endif
  */
 
+/* Workaround for GNU/Hurd */
+#ifndef PATH_MAX
+# define PATH_MAX 4096
+#endif
+
 # include 
 
 # include 


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

Bug#718347: bootlogd keeps on running after boot

[MAG4 Piemonte]

We have the same permissions in /var/log/boot ...
Regards!

Guido

In data lunedì 27 gennaio 2014 13:45:58, Adrian ha scritto:
> Package: bootlogd
> Version: 2.88dsf-45
> Followup-For: Bug #718347
> 
> I have tried what you say and it seems that it's not working correctly. I only
> writes a part of the boot proccess
> 
> Do you have this permissions in /var/log/boot?
> 
> -rw-r- 1 root adm 6191 ene 27 13:41 /var/log/boot
> 
> 
> 
> -- System Information:
> Debian Release: jessie/sid
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages bootlogd depends on:
> ii  libc6 2.17-97
> ii  lsb-base  4.1+Debian12
> 
> bootlogd recommends no packages.
> 
> bootlogd 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#680673: tagging 680673

[Olivier Berger]

tags 680673 + patch
tags 680673 + pending
thanks

This should be fixed by the version in experimental. 

Could you try and report ?

Thanks in advance.

Best regards,

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


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

Bug#736913: ITP: django-rest-swagger -- API documentation generator for Swagger UI and Django REST Framework

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: django-rest-swagger (binary: python-rest-framework-swagger)
  Version : 0.1.11
  Upstream Author : Marc Gibbons 
* URL : https://github.com/marcgibbons/django-rest-swagger
* License : BSD-2-clause (MIT, BSD-3-Clause, GPL-2 for the libraries)
  Programming Lang: Python
  Description : API documentation generator for Swagger UI and Django REST 
Framework

 This project provides an API documentation generator and is built on the Django
 REST Framework Docs and uses the lovely Swagger from Wordnik as an interface.
 This application introspectively generates documentation based on your Django
 REST Framework API code. Comments are generated in combination from code
 analysis and comment extraction. Here are some of the features that are
 documented:
 .
  * API title - taken from the class name
  * Methods allowed
  * Serializers & fields in use by a certain method
  * Field default values, minimum, maximum, read-only and required attributes
  * URL parameters (ie. /product/{id})
  * Field help_text property is used to create the description from the
serializer or model.
  * Query parameters (user-defined) - Custom parameters. It is possible to
customize a parameter list for your API. To do so, include a key-value pair
in the docstring of your API class delimited by two hyphens ('--').
Example: 'start_time -- The first reading'

The package ships some javascript libraries in
rest_framework_swagger/static/rest_framework_swagger/lib (some of them
minified). What is the recommended way to handle these? Do I have to package
every javascript library separately? Should I just replace the javascript
libraries by symlinks to the system libraries and remove the symlinks in the
clean target? Should I repack the source tarball (to get rid of the minified
files) or is it enough to just not use these files?

This package needs jquery >= 1.8 and uses following javascript libraries that
are not packaged yet: handlebars, jquery.ba-bbq, jquery.slideto, jquery.wiggle,
and shred.


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

Bug#736909: Missing appconfig file for libvirt and LXC containers

[Laurent Bigonville]

Hi,

Libvirt selinux security driver is now enabled in debian unstable.
Qemu/KVM VM can be started properly now, but a bug[1] has been reported
that LXC containers are failing to start due to the missing
"lxc_contexts" appconfig file.

Looking at the fedora policy, it's indeed shipping that file with the
following content:

-
process = "system_u:system_r:svirt_lxc_net_t:s0"
content = "system_u:object_r:virt_var_lib_t:s0"
file = "system_u:object_r:svirt_sandbox_file_t:s0"
sandbox_kvm_process = "system_u:system_r:svirt_qemu_net_t:s0"
sandbox_lxc_process = "system_u:system_r:svirt_lxc_net_t:s0"
-

I only see minimal differences between the virt module in the refpolicy
and the one in the fedora one, and I'm maybe missing something, but it
seems that some types are missing in both the refpolicy and the fedora
policy. I find no signs of "svirt_qemu_net_t" or "sandbox_file_t" for
example.

So an idea how we could make libvirt happy with LXC containers?

Cheers,

Laurent Bigonville


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736909

PS: could you please keep the 736909-forwarded CC while replying.


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

Bug#736914: missing licenses in debian/copyright

[Thorsten Alteholz]

Package: efl
Severity: serious
User: alteh...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

Dear Maintainer,

please add the MIT license of at least:
  src/modules/evas/engines/psl1ght/rsxutil.c
  src/modules/evas/engines/psl1ght/rsxutil.h
  src/benchmarks/eina/city.cc
  src/benchmarks/eina/city.h
  src/lib/ecore_con/dns.c
  src/lib/ecore_con/dns.h
  parts of src/lib/eina/*
to debian/copyright.

Thanks!
  Thorsten


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

Bug#736915: planet-venus: Embeds a copy of several libraries

[Olivier Berger]

Package: planet-venus
Version: 0~git9de2109-1
Severity: normal

In the experimental version, there are still 2 libraries embedded :
 - /usr/share/pyshared/planet/vendor/timeoutsocket.py
 - /usr/share/pyshared/planet/vendor/pubsubhubbub_publisher

I've filed a RFP for the latter one (#736881).

I think the former one may need its own package too...

Hth.

Best regards,

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

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

Versions of packages planet-venus depends on:
ii  python  2.7.5-5
ii  python-chardet  2.0.1-2
ii  python-feedparser   5.1.3-1
ii  python-html5lib 0.999-2
ii  python-htmltmpl 1.22-10
ii  python-httplib2 0.8-2
ii  python-librdf   1.0.16.1-1+b2
ii  python-libxml2  2.9.1+dfsg1-3
ii  python-portalocker  0.4~ds0-1
ii  python-utidylib 0.2-9

Versions of packages planet-venus recommends:
ii  python-beautifulsoup  3.2.1-1
ii  python-libxslt1   1.1.28-2

Versions of packages planet-venus suggests:
ii  python-django  1.6.1-1
ii  python-genshi  0.7-1
ii  python-lxml3.2.0-1+b1

-- debconf-show failed


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

Bug#735198: virt-manager: cannot show disk in VM settings

[Matěj Šusta]

Hi,

whilist what Michal Suchanek wrote is true, this doesn't change the fact 
that this bug is still very annoying as the workaround is pretty long.
Default disk "Disk 1" is on my machine set to type "IDE" which means 
that I have to change that setting on all VMs I create. That said, if I 
can't use the "edit machine details before install" I have to click 
begin installation, force off the machine, delete the disk and add a new 
one with required settings...


This was reported in Red Hat bugzilla (and solved) under:
RH BZ#949411
RH BZ#978264

Ubuntu hit this (of course) too. There were some problems but it seems 
that there is a backport patch available on Launchpad: Ubuntu LP#1217524 
(https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1217524)


I've checked the patch and if it really is the thing, it's really trivial.
I don't have any debian packaging experience so I'm not able to recheck 
it by myself now, but I can test this in a while, probably.


// M


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

Bug#736628: procps: FTBFS [amd64]: FAIL: vmstat partition (using sda1)

[Craig Small]

tags 736628 help
tags 736628 upstream
On Mon, Jan 27, 2014 at 09:08:56AM -0800, Daniel Schepler wrote:
> (gdb) p disks
> $1 = (struct disk_stat **) 0x7fffeb08
> (gdb) p *disks
> $2 = (struct disk_stat *) 0x0
> (gdb) p cDisk
The problem seems to be that a partition is found before the disk
appears. More specifically, the partition needs to be before *any*
disk. (A different but related bug is that the library assumes
all partitions appear immediately after the disk line).

So: sda, sda1, sda2 = ok
sda1,sda2,sda = crash
sr0, sda1, sda2 = ok, but sda1 is "linked" to sr0

The problem now is, under what conditions do these odd
/proc/diskstats occur and what interpretation should
vmstat make of the situation? Ignore the partitions?
Raise an error? re-map the disk->partition links
after reading the file?

 - Craig

-- 
Craig Small (@smallsees)   http://enc.com.au/   csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


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

Bug#731965: libptscotch-dev: Please upgrade to Scotch 6

[trophime]

Hi,
there is a tentative upgrade in debian science git repository
that should close this bug.

Can somebody review the package?
Best

C.

-- 


Christophe TROPHIME
Research Engineer

LNCMI
CNRS - LNCMI
25, rue des Martyrs
BP 166
38042 GRENOBLE Cedex 9
FRANCE
CNRS

Tel : +33 (0)4 76 88 90 02 
Fax : +33 (0) 4 76 88 10 01
Office U 19 
M@il : christophe.troph...@lncmi.cnrs.fr 



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

Bug#736902: qemu: multiboot header always sets mem_upper as 0k

[Peter Chubb]

> "Michael" == Michael Tokarev  writes:

Michael> 28.01.2014 08:17, Peter Chubb wrote:
>> Package: qemu Version: 1.7.0+dfsg-3 Severity: important
>> 
>> Dear Maintainer, Our operating system no longer boots on
>> qemu-system-i386 because the multiboot header is no longer set up
>> correctly.
>> 
>> To check, run the multiboot tests inside the source tree.
>> 
>> I see the same thing upstream on the standard branch, but the
>> linaro branch works OK.

Michael> Thank you for a very detailed bugreport.

Michael> However, can we please know what is this "our operating
Michael> system", which source tree to use to run tests, and which
Michael> "linaro branch" you're talking about?

Which OS is not important, but if you want to know, it's seL4.

The Linaro branch is from git://git.linaro.org/qemu/qemu-linaro.git
The main upstream branch is at git://git.qemu.org/qemu.git


But to test you can do:

  apt-get source qemu
  cd qemu-1.7.0+dfsg
  debuild -b
  cd tests/multiboot
  QEMU=../../debian/qemu-system-x86/usr/bin/qemu-system-x86_64 ./run_test.sh

Hope this helps!
--
Dr Peter Chubb  peter.chubb AT nicta.com.au
http://www.ssrg.nicta.com.au  Software Systems Research Group/NICTA


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

Bug#736905: please enable module r8188eu

[Ben Hutchings]

On Tue, 2014-01-28 at 09:47 +0400, Dmitry E. Oboukhov wrote:
> Package: src:linux
> Version: 3.12-1
> Severity: wishlist
> 
> Since 3.12 linux provides a driver for nano-WiFi TP-Link 725 -
> r8188eu.
> 
> I was forced to rebuild kernel from kernel.org to use the driver.
> Could You enable the module?
> 
> CONFIG_R8188EU=m
> CONFIG_88EU_AP_MODE=y
> CONFIG_88EU_P2P=y

Prior to Linux 3.13 this driver included non-free firmware which we had
to remove, making it unbuildable.  However, it can now load external
firmware, so I will change this for 3.13.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert Einstein


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

Bug#736916: [tetgen] please upgrade to 1.5.0

[trophime]

Package: tetgen
Version: 1.5.0-1.1
Severity: wishlist

Please upgrade to 1.5.0
Now tetgen is licenced under AGPLv3
I believe that the package could therefore go to contrib

You can find a tentative upgrade on Debian Science svn repository
Could someone review this package?


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.12-1-amd64

Debian Release: jessie/sid
  500 testing-proposed-updates ftp.fr.debian.org 
  500 testing security.debian.org 
  500 testing http.us.debian.org 
  500 testing ftp.fr.debian.org 
  500 testing euler.lcmi.local 
  500 stable  dl.google.com 
  500 jessie  neuro.debian.net 
  500 dataneuro.debian.net 

--- Package information. ---
Depends   (Version) | Installed
===-+-=
libc6  (>= 2.4) | 
libgcc1(>= 1:4.1.1) | 
libstdc++6   (>= 4.1.1) | 


Package's Recommends field is empty.

Package's Suggests field is empty.

-- 


Christophe TROPHIME
Research Engineer

LNCMI
CNRS - LNCMI
25, rue des Martyrs
BP 166
38042 GRENOBLE Cedex 9
FRANCE
CNRS

Tel : +33 (0)4 76 88 90 02 
Fax : +33 (0) 4 76 88 10 01
Office U 19 
M@il : christophe.troph...@lncmi.cnrs.fr 



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

Bug#736898: ERROR: w3m-el-snapshot is broken - called emacs-package-remove as a new-style add-on, but has no compat file.

[Tatsuya Kinoshita]

On January 28, 2014 at 10:50AM +0800, jidanni (at jidanni.org) wrote:
> Package: w3m-el-snapshot
> Version: 1.4.527+0.20140108-1
>
> Preparing to unpack .../w3m-el-snapshot_1.4.527+0.20140108-1_all.deb ...
> ERROR: w3m-el-snapshot is broken - called emacs-package-remove as a new-style 
> add-on, but has no compat file.

This ERROR is just warning, and you can ignore this, because
w3m-el-snapshot's script is compatible with both new-style and old-tyle.

BTW, even if a compat file is provided, this ERROR is displayed
by emacsen-common 2.0.7 because of bug#736062:

  * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736062

Anyway, I'll close this bug if this incorrect ERROR disappear.

Thanks,
--
Tatsuya Kinoshita


pgphK5KfCDhSO.pgp
Description: PGP signature

Bug#736917: ITP: light-table -- IDE with real time feedback

[Richard Sellam]

Package: wnpp
Severity: wishlist
Owner: Richard Sellam 

* Package name: light-table
  Version : 0.6.2
  Upstream Author : Chris Granger
* URL : http://www.lighttable.com/
* License : GPL
  Programming Lang: Clojure
  Description : IDE with real time feedback

Light Table is an IDE that provides real time feedback to instantly see 
how changes affect a system. It lets one modify running programs and 
embed anything from websites to games.



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

Bug#736892: microcode only updated on 2 out of 4 CPUs

[Henrique de Moraes Holschuh]

On Mon, 27 Jan 2014, Stephen Powell wrote:
> My motherboard is a Gigabyte GA-78LMT-SP2, PCB revision 5.0,
> BIOS version F3.  My processor is an AMD FX-4300, which is
> a quad-core chip.  On newer kernels, only two out of the four
> CPUs get their microcode upgraded.  (It always seems to be
> CPU0 and CPU2 that get upgraded, while CPU1 and CPU3 do not
> get upgraded.)  On older kernels, all four CPUs get their
> microcode upgraded.

Could you please send to the bug report the contents of /proc/cpuinfo on the
kernel that is showing problems?   That should help diagnosing the issue.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Bug#714965: May include a translation Brazilian Portuguese (pt_BR.po) in this otr version?

[intrigeri]

Hi,

Alexandro Casanova wrote (28 Jan 2014 00:00:03 GMT) :
> About: [225c86] Fix typo in English UI text.
> Yes I get latest source string with intltool-update --pot and see
> about fix typo in english.
> The difference is that I translated that part again, this file is
> attached,

It seems that we have a hard time understanding each other.
I certainly have my share of responsibility for it, and I'm sorry.

The attached PO file still seems to be out-of-sync with the source
Debian builds pidgin-otr from: it translates the *fixed* English
string (with "should choose") again, instead of the string ("should
chose") that is currently in the sources presently in Debian. See what
I mean?

Did you really see *this* *specific* string translated into pt_BR in
the Pidgin UI, once the PO file is compiled and given to pidgin-otr
that is currently in Debian unstable? If yes, then that's a mistery
for me. If no, this means this PO file is not in good shape to be
added to Debian, and really, I'd rather give up the discussion at this
point, since this feels more and more out of the scope of the work I'm
willing to do, and let upstream put out a point-release instead.

Ian, any plan to release a tarball with the fixed English string, and
updated translations? :)

> and I will ask his owner otr also included.

I'm sorry I don't get what you mean here.

(Please keep the bug report Cc'd, I'd rather not discuss
this privately.)

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


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

Bug#736902: qemu: multiboot header always sets mem_upper as 0k

[Michael Tokarev]

28.01.2014 14:00, Peter Chubb wrote:
[]
> Michael> However, can we please know what is this "our operating
> Michael> system", which source tree to use to run tests, and which
> Michael> "linaro branch" you're talking about?
> 
> Which OS is not important, but if you want to know, it's seL4.

Ah. I thought you're referring to your OS tests, not qemu tests.

Now when I know which test it is, I tried it here - from qemu git.

And here, it is not 0k:

==
FAIL mmap (output difference)
--- mmap.out2014-01-28 15:09:38.238713979 +0400
+++ test.log2014-01-28 15:21:00.147125386 +0400
@@ -58,16 +58,16 @@
 === Running test case: mmap.elf -m 4G ===

 Lower memory: 639k
-Upper memory: 3668984k
+Upper memory: 3144696k

 e820 memory map:
 0x0 - 0x9fc00: type 1 [entry size: 20]
 0x9fc00 - 0xa: type 2 [entry size: 20]
 0xf - 0x10: type 2 [entry size: 20]
-0x10 - 0xdfffe000: type 1 [entry size: 20]
-0xdfffe000 - 0xe000: type 2 [entry size: 20]
+0x10 - 0xbfffe000: type 1 [entry size: 20]
+0xbfffe000 - 0xc000: type 2 [entry size: 20]
 0xfffc - 0x1: type 2 [entry size: 20]
-0x1 - 0x12000: type 1 [entry size: 20]
+0x1 - 0x14000: type 1 [entry size: 20]

 mmap start:   0x9000
 mmap end: 0x90a8
@@ -77,16 +77,16 @@
 === Running test case: mmap.elf -m 8G ===

 Lower memory: 639k
-Upper memory: 3668984k
+Upper memory: 3144696k

 e820 memory map:
 0x0 - 0x9fc00: type 1 [entry size: 20]
 0x9fc00 - 0xa: type 2 [entry size: 20]
 0xf - 0x10: type 2 [entry size: 20]
-0x10 - 0xdfffe000: type 1 [entry size: 20]
-0xdfffe000 - 0xe000: type 2 [entry size: 20]
+0x10 - 0xbfffe000: type 1 [entry size: 20]
+0xbfffe000 - 0xc000: type 2 [entry size: 20]
 0xfffc - 0x1: type 2 [entry size: 20]
-0x1 - 0x22000: type 1 [entry size: 20]
+0x1 - 0x24000: type 1 [entry size: 20]

 mmap start:   0x9000
 mmap end: 0x90a8
==

However, on upstream 1.7.0 and 1.6.0 it works fine.

It fails when using seabios, however.  With 1.7.0, and current seabios
from jessie, it shows your zeros:

-Upper memory: 130040k
+Upper memory: 0k
...

It also works fine with current qemu in jessie/sid and with previous
seabios.

Now, I've no idea what's going on, will try to dig further and ask around :)

Thanks,

/mjt


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

Bug#736902: qemu: multiboot header always sets mem_upper as 0k

[Michael Tokarev]

28.01.2014 15:31, Michael Tokarev wrote:
> It fails when using seabios, however.  With 1.7.0, and current seabios
> from jessie, it shows your zeros:

I mean, when using previous version of seabios -- 1.7.3 works, 1.7.4 fails.

/mjt


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

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Bdale Garbee writes ("call for votes on default Linux init system for jessie"):
>   The default init system for Linux architectures in jessie should be
> 
>   1.  systemd
> 
>   2.  upstart
> 
>   3.  openrc
> 
>   4.  sysvinit (no change)
> 
>   5.  requires further discussion.

It looks like this is going to be voted down or withdrawn, thanks, and
everyone is agreed that there should be a rider about GRs.  I'll
therefore comment on the substance.

I don't want to pass a resolution specifying the default without also
answering the other two, related, contentious questions:

  Q1: Do we intend to support multiple systems long-term, or do we
  intend to settle on a single system, probably in jessie+1 ?

  Q2: Is it OK for packages to depend on a specific init system as
  pid 1 ?

There are two reasons why I want to decide these questions in the same
vote.

Firstly, as I have said, TC members should be able to express the
preference "only X, X by default but also others, Y by default but
also others, Y", which is a perfectly reasonable one but which cannot
be expressed by a concurrent ballots (and holding the ballots
sequentially in situations like this can be a way of manipulating the
result).

Secondly, making a decision on the default without clearly stating a
requirement for support for multiple systems risks a situation where
partisans for the winning system create "facts on the ground" which
make it difficult to support multiple systems.


I think there are the following three reasonable answers to Q1/Q2
taken together.

i.   Q1: Multiple in >jessie
 Q2: Requiring specific init is forbidden

ii.  Q1: Multiple in >jessie
 Q2: Requiring default init is permitted

iii. Q1: Single in jessie+1
 Q2: Requiring default init is permitted

Of these (ii) would cause the non-default inits to rot.  Unless anyone
thinks this is a useful option I don't think we should vote on it.


So that leaves my text from yesterday:

   M. Debian intends to support multiple init systems, for the
  foreseeable future, and so long as their respective communities
  and code remain healthy.  Software outside of an init system's
  implementation may not require a specific init system to be
  pid 1, although degraded operation is tolerable.

vs something like:

   O. Debian intends to converge on one init system; in jessie+1,
  packages may require that the default init system is in use.

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Ian Jackson writes ("Bug#727708: call for votes on default Linux init system 
for jessie"):
> Bdale Garbee writes ("call for votes on default Linux init system for 
> jessie"):
> >   The default init system for Linux architectures in jessie should be
> > 
> >   D.  systemd
> > 
> >   U.  upstart
> > 
> >   R.  openrc
> > 
> >   V.  sysvinit (no change)
> > 
> >   F.  requires further discussion.

I have lettered these.

> So that leaves my text from yesterday:
> 
>M. Debian intends to support multiple init systems, for the
>   foreseeable future, and so long as their respective communities
>   and code remain healthy.  Software outside of an init system's
>   implementation may not require a specific init system to be
>   pid 1, although degraded operation is tolerable.

(I forgot to say, I edited that a bit.)

> vs something like:
> 
>O. Debian intends to converge on one init system; in jessie+1,
>   packages may require that the default init system is in use.

If we are I to vote now, I would like to see on the ballot at least:
   DM  systemd by default, but also others
   DO  systemd only in jessie+1
   UM  upstart by default, but also others
   UO  upstart only in jessie+1
   RM  openrc by default, but also others
   VM  sysvinit by default, but also others

I don't think RO and VO make much sense.

Does my text for "O" correctly represent the views of those who want
us to converge on a single system ?

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Ian Jackson writes ("Re: Bug#727708: call for votes on default Linux init 
system for jessie"):
> > So that leaves my text from yesterday:
> > 
> >M. Debian intends to support multiple init systems, for the
> >   foreseeable future, and so long as their respective communities
> >   and code remain healthy.  Software outside of an init system's
> >   implementation may not require a specific init system to be
> >   pid 1, although degraded operation is tolerable.
> 
> (I forgot to say, I edited that a bit.)

I hope this rephrasing is good enough to satisfy the quibbles which
come up every time about this.  If any of the TC members feel that
there is a better way to put this requirement I would be happy to hear
it.

For the avoidance of doubt, this is to be fleshed out into policy
where the details can be dealt with.

Ian.


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

Bug#736918: cowbuilder: unrecognized option '--pbuildersatisfydepends'

[Michele Cane]

Package: cowbuilder
Version: 0.73
Severity: normal

Dear Maintainer,

I am trying to build a package with one dependency from experimental using git-
buildpackage and a base cow from sid.

this is the command I am using:

git-buildpackage --git-upstream-branch=upstream-unstable --git-debian-branch
=debian-unstable --git-upstream-tag=480f0998ffed6d9a5c6656dba75182f00fd88a1b
--git-ignore-new  --git-pbuilder --git-pbuilder-options='--
pbuildersatisfydepends /usr/lib/pbuilder/pbuilder-satisfydepends-experimental'
--git-no-pbuilder-autoconf

build aborts with:

cowbuilder: unrecognized option '--pbuildersatisfydepends'
Unhandled option

I am not really sure  whether this problem comes from cowbuilder, pbuilder or
git-buildpackage.

Cheers

Mike




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

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

Versions of packages cowbuilder depends on:
ii  cowdancer  0.73
ii  libc6  2.17-97
ii  pbuilder   0.215

cowbuilder recommends no packages.

cowbuilder 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#736919: infinite loop in grep -P on some files with invalid UTF-8 sequences

[Vincent Lefevre]

Package: grep
Version: 2.16-1
Severity: important

grep -P loops on some files with invalid UTF-8 sequences, e.g.

$ /usr/bin/printf "\xe9\x65\n\xab\n" | grep -P '.e|.?z' | head
�e
�e
�e
�e
�e
�e
�e
�e
�e
�e

(the infinite loop is interrupted here by a broken pipe due to
the "head").

It seems that the fix of

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

didn't solve all the problems.

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

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

Versions of packages grep depends on:
ii  dpkg  1.17.6
ii  install-info  5.2.0.dfsg.1-2
ii  libc6 2.17-97
ii  libpcre3  1:8.31-2

grep recommends no packages.

grep 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#736916: [tetgen] please upgrade to 1.5.0

[Anton Gladky]

Hi Christophe!

Good to know, that tetgen has been relicensed!
I will try to upload it in the evening.

Could, you, please, then have a look at gmsh to enable this feature there?

Thanks,

Anton


2014-01-28 trophime :
> Package: tetgen
> Version: 1.5.0-1.1
> Severity: wishlist
>
> Please upgrade to 1.5.0
> Now tetgen is licenced under AGPLv3
> I believe that the package could therefore go to contrib
>
> You can find a tentative upgrade on Debian Science svn repository
> Could someone review this package?
>


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

Bug#736920: transition: libcogl15

[Simon McVittie]

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

(I am not speaking for the GNOME maintainers, and I don't know
whether they are ready to start this transition.)

Various packages in GNOME 3.10 depend on clutter1.0 from experimental. The
first step towards a new GNOME in unstable (or less painful installations
from experimental) seems to be to upgrade src:cogl; having a
transition-tracker for that would probably be a helpful way to see
how much will be affected.

Ben file:

title = "cogl";
is_affected = .depends ~ /libcogl(|-pango|-gles2-)12/ | .depends ~ 
/libcogl(|-pango|-gles2-)15/;
is_good = .depends ~ /libcogl(|-pango|-gles2-)15/;
is_bad = .depends ~ /libcogl(|-pango|-gles2-)12/;

This transition already happened in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/cogl/+bug/1265457

Regards,
S


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

Bug#727708: multiple init systems - formal resolution proposal

[Olav Vitters]

On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette  wrote:
> Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
>> No. My question isn't about logind, but about using a user systemd
>> session to supervise processes started by the session. IIRC both GNOME
>> and KDE were mentioned to consider this feature.
>
> I wouldn't worry much about such features, at least not for jessie. They
> will most likely be fallbacks, and in the unlikely case they are at
> build time, we could always put the two binaries in the same package
> with dynamic detection, thus working around this requirement.

Fallback is intended, so for near future you'd be ok. Longer term, I
expect almost no maintenance to occur from GNOME side, so be prepared
to handle the maintenance if nobody else does. Though I guess it'll be
like ConsoleKit case: I'm warning, but nothing happens :-(

> The real problem is logind. The requirement proposed by Ian is not
> implementable:
> http://lists.debian.org/1390155797.29928.17.camel@tomoe

IMO other init systems should provide the interfaces which GNOME
requires. It is not up to GNOME to provide these. That or takeup
ConsoleKit maintenance (or logind alternative), but despite warning
about and requesting this in January 2012, not much has happened.

So I think the proposal should be turned around: Init systems should
ensure that they meet the changing requirements of the rest of the
stack. Aside from this we're open to discuss things with
distributions. For logind case I approached various times (obviously
not knowing Debian) and we warned and requested feedback. Initially
via our distributor-list, but also reached out to debian-devel. Any
practical answer and/or discussion is very welcome. The lack of any
answer means we'll continue to do what we think is best.

To be clear: Any answer like "it should just work across init systems"
for me is not a practical answer as it ignores all the issues we're
facing with this. That said, we don't rely on systemd. If there's
functionality that we really want, need or makes our lives much
easier, then I don't see how you can demand us to do double or triple
work. The burden should be placed correctly, not with us.

I'm quite saddened by lack of response to e.g. ConsoleKit/logind btw,
it's been 2 years already!!

Regards,
Olav (GNOME release team dude for the people who don't know)


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

Bug#736921: RM: ruby-tmail -- ROM; obsoleted by ruby1.9 and higher

[Ondřej Surý]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

please remove ruby-tmail from the archive as it is no longer needed
with rails 3.2 and ruby1.9.1.

The only missing r-dependency (schleuder) needs and will be fixed as
part of ruby1.8 removal.  (And the upstream package doesn't need
ruby-tmail if used with ruby1.9.1, so it's purely packaging bugfix.)

Ondrej, on behalf of pkg-ruby-extras

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlLnpVQACgkQ9OZqfMIN8nMvLwCgj9BDGq7NFRh/wIkwtrxuYxMQ
jUUAoIcB1q81QfxjeO+a9SAiRk5Fx70f
=/tFR
-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#731074: [pkg-lighttpd] Bug#731074: lighttpd: indeterminate test on kfreebsd buildds

[Arno Töll]

Hi Steven.

On 27.01.2014 21:22, Steven Chamberlain wrote:
> I could reproduce it 8 times out of 100 here on kfreebsd-amd64.
> 
> The race happens after getting Connection Refused trying to contact the
> fcgi-responder which has just exit (intentionally).
> 
> The parent does a wait4() syscall, and if this returns the pid of the
> process that just exit, a new listen is set up on 1/tcp and lighttpd
> forks a new fcgi-responder.  The parent waits with select() for it to be
> ready, then sends the FCGI request which is successful:

is this a libc portability issue then? All in all this does not really
sound like a problem in the lighttpd code base, does it?


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#699647: proftpd-mod-geoip: /usr/lib/proftpd/mod_geoip.so missing after upgrade from sid

[Francesco P. Lovergine]

On Mon, Jan 27, 2014 at 08:35:02PM +0100, Andreas Beckmann wrote:
> Won't work. Even if you ensure via Conflicts/Pre-Depends that the buggy 
> package gets removed, the postrm script will stay around. You cannot force a 
> package to be purged.
> (Changing the module filename would work.)

which seems to me much better than a ugly hack such as the proposed one.

-- 
Francesco P. Lovergine


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

Bug#736922: installation-report: Wheezy/stable reinstalled on main AMD64-machine with Level1 MD-RAID

[Andreas Glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: installation-reports
Version: 2.49
Severity: wishlist

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

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

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


- -- Package-specific info:

Boot method: CD
Image version:
http://cdimage.debian.org/debian-cd/7.3.0/amd64/iso-cd/debian-7.3.0-amd64-netinst.iso,
2013-12-15
Date: 2014-01-28, about 10.00 h until 13:00 h

Machine: GIGABYTE-GA-MA78GM-S2H with Phenom 8250e
Partitions:
Filesystem Type 1K-blocks  Used Available Use% Mounted on
rootfs rootfs32732108   7823596  24908512  24% /
devtmpfs   devtmpfs   1989324 0   1989324   0% /dev
tmpfs  tmpfs   405960   848405112   1% /run
/dev/md0   xfs   32732108   7823596  24908512  24% /
tmpfs  tmpfs 5120 0  5120   0% /run/lock
tmpfs  tmpfs  4051840   124   4051716   1% /run/shm


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

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

Comments/Problems:

Bacause the asymmetric system, with an MD-RAID on SD-card and harddisk, that 
was in use
before on my main PC broke,
 (see that report
- ->http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723635),
it was reinstalled on a normal Level1-MD-RAID now on two green-labelled 
harddisks, all
existing package-selections were transferred successfully.

Here follows a recipe for transferring an existing system onto an MD-RAID 
filesystem:

1.) Backup all configuration-files from /etc/, which are important. If you have 
a more
sophisticated configuration on a server-system for example, then you may want 
to use
etckeeper, that requires basic knowledge about version-control. 
# aptitude install dselect && dselect update
# dpkg --get-selections > myselec.txt
2.) See you have two partitions on your harddisks of roughly identical size, 
with about
32 GB each.
3.) Set up the base-system only and standard system-utilities, making a
RAID-1-filesystem-root over the two prepared partitions. I used the 
XFS-filesystem,
because BTRFS was not really workable and too slow.
4.) Upon booting into the new system, 
# aptitude install dselect,
next transfer the backed up files /etc/apt/sources.list and 
/etc/apt/preferences to /etc/
and do
#aptitude update && dselect update
#dpkg --set-selections < myselec.txt
5.) install the missing keyring-packages, in my case I needed the 
mozilla-archive keyring
and the debian-multimedia-keyring
6.) #aptitude update && apt-get dselect-upgrade
Now all the packages, that were selected and installed on the previous system 
are
installed on the new one. These were less than 3 GB of software, but it took 
more than
5.5 hours to set it up on a BTRFS-filesystem, so this was cancelled and XFS was 
used
instead, with which it took only 2.5 hours.
7.) In my case I also had to do
'#aticonfig --initial' in order to make the x-server work
8.) Restore /etc/fstab, so that the /home/-partition and other mass-storage 
partitions
will be mounted automatically at each system-boot again.

That is all, three hours later everything works fine again, the RAID is less 
asymmetric
than the one, that was in use before and it is less likely to break, no 
USB-devices are
involved.
The two harddisks are not from the same vendor, one is a Hitachi-disk, the
other larger one is a WD-model with advanced format, that uses physical 
4k-blocks, but
this does not seem to matter much.
There is no separate non-RAID /boot/-partition required anymore and I am not 
restricted
to 3.2-kernel versions anymore, but I can upgrade to version 3.12 or newer from
backports.
When I want to build custom kernel-packages, then I can do it right directly in 
/usr/src/
without provoking problems with dkms.
So overall the situation is now 350% improved, over what it was before, and I 
have gained
a spare 16GB-SD card, that might be used as dm-cache or for something else.
Cheers!
- -- 

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

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

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer

Bug#736923: schleuder should bump the required version of actionmailer to rails 4.0

[Ondřej Surý]

Package: schleuder
Version: 2.2.1-3
Severity: grave
Tags: upstream
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The schleuder currently depends either on ruby-tmail (for ruby1.8) or
ruby-actionmailer =2.3.14 (for ! ruby1.8).

Either schleuder needs to fix that, or we would need to remove
schleuder from the archive, since tmail is obsolete and
ruby-actionmailer-2.3 has been removed from Debian unstable (finally)
because it's unmaintained upstream (for a long time now).

Ondrej

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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlLnq3oACgkQ9OZqfMIN8nNCHgCgrXEg0nNC3vwWpZQx8Tr4eknC
n/cAoKmjgBUcoZwo4z/iUvS7417UrgVd
=mdSR
-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#592777: fix for axis trouble in joystick code

[Jens Mühlenhoff]

Hi,

this bug affects me as well, applying the patch is trivial.

Could you please include it in the Debian package?

--
Mit freundlichen Grüßen
Jens Mühlenhoff


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

Bug#719945: [Pkg-systemd-maintainers] Bug#719945: systemd: Hangs during shutdown (likely NFS-related)

[Sam Morris]

On Sun, Jan 26, 2014 at 10:35:29AM +0100, Michael Stapelberg wrote:
> control: tag -1 + pending
> 
> Hi Sam,
> 
> Sam Morris  writes:
> > I rebuilt with the attached patch and it does the trick. I think it's
> > also the fix applied to fix
> > .
> Thanks, I merged it:
> http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=cf19e2b
> 
> -- 
> Best regards,
> Michael

Hm. It seems that the problem isn't fixed after all. I was fooled
because I was able to reboot a few times without the problem happening,
but I've now reproduced it with the patch applied.

I've attached a debug log of the shutdown process. You can see
ifup@eth0.service being stopped on line 8596, but home.mount isn't
unmounted until line 9612.

On line 9588 you can see that nfs-common.service is stopped before the
NFS unmount operation completes (line 9654). I'm not an NFS expert but I
think this service should only be stopped after all NFS filesystems are
unmounted, so that the NFS server is informed that any locks being
released on the filesystem (and probably other things on different NFS
versions). This is the ordering in /etc/rc6.d as well.

On line 9617, you can see that the NFS mount is being unmounted with a
simple '/bin/umount /home' which fails since there are still user
processes running with files open. In order to avoid potential data loss
I get the feeling that something should be killing these processes off
politely before the filesystem rug is yanked away from underneath them,
but I think that's a bug for another time. When booting with sysvinit,
/etc/init.d/umountnfs.sh uses the -f and -l options when running umount,
which at least ensures that the filesystem will be unmounted even if the
network is down. From my log it appears that systemd doesn't even start
this service during the shutdown process. If it's intended that systemd
takes over its job, then the correct options should be used (-f and -l,
on any kernel version supported by systemd), and the service should be
masked. If not, then umountnfs.service should be started during the
shutdown process. Unless you have another suggestion, I'll give this a
go and see how it works out.

FYI, here's a summary of how NFS mounting during boot, and unmounting
during shutdown, is handled in Debian.

By default, d-i configures network interfaces as follows:

allow-hotplug eth0
iface eth0 inet dhcp

This causes NFS mounts to be activated by ifup, via
/etc/network/if-up.d/mountnfs, during hotplug time, but only if all
other 'auto' interfaces have previously been brought up.

The user can also configure their network interface with 'auto' instead
of 'allow-hotplug'. In this case, NFS mounts are still mounted when ifup
for the final 'auto' interface is run, but this will instead happen
during the start of networking.service.

There's also the existence of an /etc/default.rcS variable,
ASYNCMOUNTNFS. By default this is unset, corresponding to 'yes'. If set
to 'no', then NFS mounts are not activated as above; instead they are
activated by mountnfs.service. This service is masked in the Debian
systemd package, so I think we can say that ASYNCMOUNTNFS=no is not
currently supported with our systemd setup.

Under sysvinit, unmounting at shutdown is handled by
/etc/init.d/umountnfs.sh, which runs before nfs-common, and then
rpcbind, are stopped. As noted above, umountnfs.service is not started
during shutdown under systemd.

Interfaces can also be configured with NetworkManager, which adds
another axis to the configuration space. Simple configuration of a wired
network interface should still work, but I think some work has to be
done (currently by the admin) to enable
NetworkManager-wait-online.service in order to get systemd to delay
activating the NFS mounts until NM determines that a network connection
is available.

Incidentally, NetworkManager-wait-online.service looks wrong to me; I
think it should declare Wants= and Before= on network-online.target,
since that is the name of the target documented in systemd.special(7);
however I think that it's not actually broken with its current
settings--they will just result in network.target itself being delayed
until NetworkManager-wait-online.service starts up, and since the .mount
units generated by systemd-fstab-generator are After= both network.target
and network-online.target, the mounts will still be activated at the
right time. If NetworkManager-wait-online.service were changed to use
network-wait-online.target instead, then could we enable
NetworkManager-wait-online.service by default without delaying the
startup of any services that don't run After= that target, i.e., none in
the default install?

As for shutting down, NetworkManager should only be stopped after remote
filesystems are unmounted. I'm not sure if this is the case already.
I've no idea how to deal with horrible cases such as when the user
reboots the system while they have mounted an NFS 

Bug#733110: wordnet: Please migrate to Ruby 2.0/1.9

[Andreas Tille]

Hi,

Dmitry E. Oboukhov has injected some Ruby 1.8 code into the wordnet
packaging.  I personally do not speak Ruby and thus can not fix the
problem in an other way than simply droping the goldendict-wordnet
binary package (its data package is created in this way).

Since Dmitry has not (yet) respondet to this bug report I would like
to ask the Ruby team to find a patch for the problem in the build
system that fixes the following:


WARNING: sentidx.vrb format error: ["pet%2:35:00::"]
debian/wn-for-goldendict.rb:300:in `initialize': undefined method `times' for 
"\x01":String (NoMethodError)
from debian/wn-for-goldendict.rb:158:in `new'
from debian/wn-for-goldendict.rb:158:in `get_data'
from debian/wn-for-goldendict.rb:648:in `block (2 levels) in '
from debian/wn-for-goldendict.rb:647:in `each'
from debian/wn-for-goldendict.rb:647:in `block in '
from debian/wn-for-goldendict.rb:644:in `foreach'
from debian/wn-for-goldendict.rb:644:in `'


If I do not get any help I need to go the unfortunate route to kick
goldendict support again.

Kind regards

 Andreas.


On Wed, Dec 25, 2013 at 05:57:33PM +0100, Christian Hofstaedtler wrote:
> Package: wordnet
> Severity: normal
> 
> Dear Maintainer,
> 
> Your package "wordnet" uses Ruby 1.8 during it's build process.
> Ruby 1.8 is no longer maintained upstream, and the Ruby team wishes to
> remove it from the archive soon. Please migrate your build scripts to
> use Ruby 1.9 or 2.0.
> 
> For your convienence a "ruby" package is provided which always depends
> on the current default version of the ruby interpreter (at time of this
> writing, the default is 1.9.1).
> 
> Thank you,
> Christian
> 
> -- 
>  ,''`.  Christian Hofstaedtler 
> : :' :  Debian Developer
> `. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
>   `-
> 
> -- 
> debian-science-maintainers mailing list
> debian-science-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
> 

-- 
http://fam-tille.de


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

Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch

[Prach Pongpanich]

On Tue, Jan 28, 2014 at 1:30 PM, László Böszörményi (GCS)
 wrote:
> Hi Prach,
>
> On Mon, Jan 27, 2014 at 12:37 PM, Prach Pongpanich  wrote:
>> On Mon, Jan 27, 2014 at 5:08 PM, László Böszörményi (GCS)
>>  wrote:
>> I've removed debian/*.dir files, which created an empty directory
>> (usr/lib/dbd ).
>> We don't want to run sqlite and sqlite3 tests[1] when cross-building,
>> I attached a patch for both issues.
>> [1] https://buildd.debian.org/status/package.php?p=libdbi-drivers&suite=sid
>  You made the diff in the wrong, backward way. As such, it tries to
> add the mentioned dir files. Btw thanks, those files indeed need to be
> removed.
> The mentioned page shows only the architectures that officially part
> of Debian. They are _not_ cross-builds but native to those
> architectures. I suppose you meant that don't run any tests when
> DEB_BUILD_OPTIONS instructs so.
> This is not the case for buildds. Those should run self-tests to early
> reveal platform specific bugs.

Sorry for my mistake.
I've discussed with Markus Hoenicka and he told me about a atoll()
call which the sqlite3 driver uses to convert raw data into a long
long number causes problems, he will work on this problem.

drivers/sqlite3/dbd_sqlite3.c:
1719:data->d_longlong = (long long) atoll(raw); break; /* hah,
wonder if that'll work */

>
>> P.S. please you set me as Maintainer to avoid missing an e-mail from the BTS.
>  Only one person can be the maintainer. You should get bugreports as
> uploader or you may subscribe to the source packages of your
> choice[2].

Thanks for the explanation.


Cheers,
 Prach


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

Bug#736332: [Pkg-javascript-devel] Bug#736332: Bug#736332: libv8-3.14: support for mips big endian

[Luca BRUNO]

Jérémy Lal  wrote:

> Hi,
> a similar question can be asked for v8-ppc port, too.
> I need some help for taking a decision here.
> 
> If those ports pass v8 test suites and are maintained, then we should
> consider having them in debian. I'm a little worried about security
> issues, though.

The ideal world would be to only backport patches that have already
been accepted upstream, but I realize this is infeasible in most of
the cases.

I'm a bit worried too about patching upstream for new features, but
OTOH architecture porting shouldn't be too invasive. In this case, I
believe that requiring some kind of upstream liveness check should be
enough: as far as there's somebody updating the patches and reacting to
requests/bugs, it's fine for me.

Just my 2¢, Luca

-- 
  .''`.  |   ~<[ Luca BRUNO ~ (kaeso) ]>~
 : :'  : | Email: lucab (AT) debian.org ~ Debian Developer
 `. `'`  | GPG Key ID: 0x3BFB9FB3   ~ Free Software supporter
   `-| HAM-radio callsign: IZ1WGT   ~ Networking sorcerer


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

Bug#731487: I-Nex application need it

[LOMBARD Maxime]

Hi,

I confirm this bug. I-Nex application (tools like CPU-Z on Windows) need
this library to works correctly.

Launchpad application page : https://launchpad.net/i-nex
Bug report about Debian package problem :
https://bugs.launchpad.net/i-nex/+bug/1258468

Thanks guys,
Max

Bug#736328: libcap2: local address with the '-' sign cannot be resolved

[Davide Prina]

2014-01-22 Davide Prina


>* What led up to the situation?
>
> installing the 1:2.22-1.2 libcap2 version
>
> when I try to access an intranet address with the '-' sign I receive an
> error, the address cannot be resolved
>
>
I have reinstalled the 1:2.22-1.2 libcap2 version and now all work without
problems

Probably something went wrong on  the first libcap2 upgrade. And the
downgrade has fixed it

This bug can be closed.

Ciao
Davide

Bug#736925: Does not apply to current kernel versions (3.2.y, 3.12.y, 3.13)

[Ben Hutchings]

Package: linux-patch-grsecurity2
Version: 2.9.1+3.2.21-201206221855-1
Severity: grave
Tags: security

The patch for 3.2.y has not been updated for a very long time, and now
conflicts with later updates so in effect it is incompatible with
security fixes.

No patches are included for current kernel versions.

It should be be updated or removed from both wheezy and jessie.

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.12-1-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


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

Bug#727708: init system discussion - the highlights

[Chris Knadle]

On Tuesday, January 28, 2014 06:55:45 Tollef Fog Heen wrote:
> ]] Chris Knadle
> 
> > I'll just mention that the proposal of switching out the default init
> > system in jessie+1 sounds a bit scary, as it will change a basic
> > administration interface in the middle of a Stable support period. 
> > Probably the most interesting scenarios with this involve servers running
> > unattended upgrades.
>
> That's not what jessie+1 means.  jessie+1 is the release after jessie.

I was indeed thinking of a point release, so I mistook jessie+1 as
"jessie + .1".  Now it makes sense, as the release after jessie is not yet 
named.

Thanks.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


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

Bug#736924: tercpp: bad package description

[Justin B Rye]

Package: tercpp
Version: 0.6.2+dfsg-1
Severity: wishlist
Tags: patch l10n

The short and long descriptions for tercpp are unhelpful and contain
several trivial errors, which are unlikely to fill people with
confidence about the package's usefulness.

> Package: libtercpp-dev
[...]
> Description: C++ implementation of TER (development files)

This is a bad synopsis.  Users have no reason to care what language a
tool is implemented in - what they want to know is what it's *for*.
If we need to explain the package name, there's plenty of room for
that in the long description.  I would suggest:

  Description: Translation Error Rate scoring tool - development files

>  This tool scores machine translation performance with the TER (Translation

You haven't introduced "this tool" yet (and only one of these packages
actually contains it).

>  Error Rate) metric. TER mesures edit distance between traslations and
>  references.

At least two misspellings (meAsures, traNslations) and some wobbly
phrasing.  It might be better as something like "TER measures the edit
distance between a translation and a gold-standard reference", but
I'll go for something with a lower edit distance:

   TERCpp is a tool (implemented in C++) for scoring machine translation
   performance. It uses the Translation Error Rate (TER) metric to measure
   edit distances between translations and references.

>  .
>  This package contains development files of tercpp.

Make that "for TERCpp".

Likewise for the other packages in the set:
 
> Package: libtercpp0
[...]
> Description: C++ implementation of TER

Make it clear that this doesn't contain the binary:

  Description: Translation Error Rate scoring tool - shared library

>  This tool scores machine translation performance with the TER (Translation
>  Error Rate) metric. TER mesures edit distance between traslations and
>  references.

As above.

>  This package contains a library of tercpp.

Again "for TERCpp".
 
> Package: tercpp
[...]
> Description: C++ implementation of TER (frontend)

Only developers think of a binary as a "frontend" to its library.
Indeed, only developers think "frontend" is a word.  Make it:

  Description: Translation Error Rate scoring tool - binary

>  This tool scores machine translation performance with the TER (Translation
>  Error Rate) metric. TER mesures edit distance between traslations and
>  references.

As above.

>  This package contains a frontend program of tercpp.

   This package contains the tercpp binary.


I don't know about TER, but that's a total Levenshtein distance of 340.

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

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

Versions of packages tercpp depends on:
ii  libc62.17-97
ii  libgcc1  1:4.8.2-14
ii  libstdc++6   4.8.2-14
ii  libtercpp0   0.6.2+dfsg-1
ii  libtinyxml2.6.2  2.6.2-2

tercpp recommends no packages.

tercpp suggests no packages.

-- no debconf information

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff -ru tercpp-0.6.2+dfsg.pristine/debian/control tercpp-0.6.2+dfsg/debian/control
--- tercpp-0.6.2+dfsg.pristine/debian/control	2014-01-21 08:49:08.0 +
+++ tercpp-0.6.2+dfsg/debian/control	2014-01-28 13:49:12.565508698 +
@@ -11,12 +11,12 @@
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, libtercpp0 (= ${binary:Version}), libtinyxml-dev
-Description: C++ implementation of TER (development files)
- This tool scores machine translation performance with the TER (Translation
- Error Rate) metric. TER mesures edit distance between traslations and
- references.
+Description: Translation Error Rate scoring tool - development files
+ TERCpp is a tool (implemented in C++) for scoring machine translation
+ performance. It uses the Translation Error Rate (TER) metric to measure
+ edit distances between translations and references.
  .
- This package contains development files of tercpp.
+ This package contains development files for TERCpp.
 
 Package: libtercpp0
 Section: libs
@@ -24,19 +24,19 @@
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: C++ implementation of TER
- This tool scores machine translation performance with the TER (Translation
- Error Rate) metric. TER mesures edit distance between traslations and
- references.
+Description: Translation Error Rate scoring tool - shared library
+ TERCpp is a tool (implemented in C++) for scoring machine translation
+ performance. It uses the Translation Error Rate (TER) metric to measure
+ edit distances between translations and references.
  .
- This package contains a library of tercpp.
+ This package contains the library for TERCp

Bug#736926: nova-compute: Missing entries for rootwrap.d (ex :docker.filters)

[Nicolas Fillot]

Package: nova-compute
Version: 2013.2.1-2
Severity: important

Dear Maintainer,

There are missing entries in the nova-compute rootwrap.d folder :

Exemples : docker.filters baremetal-compute-ipmi.filters

It causes nova to fail when lauching an instance :

Docker example :

'/usr/bin/nova-rootwrap: Unauthorized command: ln -sf /proc/35704/ns/net 
/var/run/netns/cd07cb613360108ba66971bf600ebfa499e6ce9f2090e88edd0a71f896844021 
(no filter matched)\n'

Creating docker.filters file from upstream corrects this issue

Thank you

Nicolas Fillot

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

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

Versions of packages nova-compute depends on:
ii  adduser 3.113+nmu3
ii  curl7.34.0-1
ii  dpkg1.17.5
ii  ebtables2.0.10.4-3
ii  gawk1:4.0.1+dfsg-2.1
ii  iptables1.4.21-1
ii  kpartx  0.4.9+git0.9c3c5172-1
ii  lsb-base4.1+Debian12
ii  nova-common 2013.2.1-2
ii  nova-compute-lxc [nova-compute-hypervisor]  2013.2.1-1
ii  open-iscsi  2.0.873+git0.3b4b4500-1
ii  parted  2.3-16
ii  python-cinderclient 1:1.0.6-2
pn  python:any  
ii  qemu-utils  1.7.0+dfsg-2
ii  vlan1.9-3

nova-compute recommends no packages.

nova-compute 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#736927: cacti poller take his date informaton from php so it needs corect date.timezone

[bozhan]

Package: cacti
Version: 0.8.8b+dfsg-3
Severity: normal

Dear Maintainer,

 

 


Cacti poller doesn't draw graphs, in Console -> Utilities -> Technical Support 
 time was 2 hours back (UTC)instead of my time zone(EET), 
because cacti needs date.timezone in /etc/php5/cli/php.ini to be
change to correct time zone.
Is it possible to change timezone in ...cli/php.ini on install?


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

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

Versions of packages cacti depends on:
ii  dbconfig-common  1.8.47+nmu1
ii  debconf [debconf-2.0]1.5.52
ii  libapache2-mod-php5  5.5.8+dfsg-2
ii  libphp-adodb 5.15-1
ii  mysql-client-5.5 [virtual-mysql-client]  5.5.33+dfsg-1
ii  perl 5.18.2-2
ii  php5 5.5.8+dfsg-2
ii  php5-cli 5.5.8+dfsg-2
ii  php5-mysql   5.5.8+dfsg-2
ii  php5-snmp5.5.8+dfsg-2
ii  rrdtool  1.4.7-2+b1
ii  snmp 5.7.2~dfsg-8.1+b1
ii  ucf  3.0027+nmu1

Versions of packages cacti recommends:
ii  apache2  2.4.6-3
ii  apache2-bin [httpd]  2.4.6-3
ii  iputils-ping 3:20121221-4
ii  libjs-jquery 1.7.2+dfsg-3
ii  libjs-jquery-cookie  8-2
ii  logrotate3.8.6-1
ii  mysql-server 5.5.33+dfsg-1

Versions of packages cacti suggests:
ii  moreutils  0.50
ii  php5-ldap  5.5.8+dfsg-2

-- debconf information:
  cacti/mysql/method: unix socket
  cacti/remote/port:
  cacti/mysql/admin-user: root
* cacti/webserver: apache2
  cacti/install-error: retry
  cacti/db/dbname: cacti
  cacti/remote/host:
  cacti/internal/skip-preseed: false
  cacti/missing-db-package-error: abort
  cacti/purge: false
  cacti/passwords-do-not-match:
  cacti/dbconfig-reinstall: false
  cacti/remote/newhost:
  cacti/database-type: mysql
  cacti/db/app-user: cacti
  cacti/upgrade-error: abort
  cacti/internal/reconfiguring: false
  cacti/remove-error: abort
* cacti/dbconfig-install: true
  cacti/upgrade-backup: true
  cacti/dbconfig-remove:
  cacti/dbconfig-upgrade: true


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

Bug#727708: call for votes on default Linux init system for jessie

[Don Armstrong]

On Tue, 28 Jan 2014, Ian Jackson wrote:
> >M. Debian intends to support multiple init systems, for the
> >   foreseeable future, and so long as their respective communities
> >   and code remain healthy.  Software outside of an init system's
> >   implementation may not require a specific init system to be
> >   pid 1, although degraded operation is tolerable.

I still don't think the last sentence of this paragraph completely
handles the cases where someone can legitimately depend on a specific
init system or specific init system interface.

If we're supporting multiple init systems, then software which doesn't
support multiple init systems which could feasibly do so is buggy. If
patches to fix it appear and aren't applied, then people can appeal to
the CTTE. It's not necessary or feasible for us to anticipate every
single technical wrinkle and delay making a decision to do so.

-- 
Don Armstrong  http://www.donarmstrong.com

Taxes are not levied for the benefit of the taxed.
 -- Robert Heinlein _Time Enough For Love_ p250


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

Bug#727708: call for votes on default Linux init system for jessie

[Don Armstrong]

On Tue, 28 Jan 2014, Ian Jackson wrote:
>   Q1: Do we intend to support multiple systems long-term, or do we
>   intend to settle on a single system, probably in jessie+1 ?
> 
>   Q2: Is it OK for packages to depend on a specific init system as
>   pid 1 ?

[...]

> Firstly, as I have said, TC members should be able to express the
> preference "only X, X by default but also others, Y by default but
> also others, Y", which is a perfectly reasonable one but which cannot
> be expressed by a concurrent ballots

The only reason to interlink these questions is if the ordering of
someone's preference on the init system question is dependent on their
preference on these two questions. If that's the case, then whoever
feels that way should propose a draft which includes an option which
handles that particular case.
 
> Secondly, making a decision on the default without clearly stating a
> requirement for support for multiple systems risks a situation where
> partisans for the winning system create "facts on the ground" which
> make it difficult to support multiple systems.

This presupposes bad faith, and even if it were so, such behavior would
still be possible even if we voted in a single decision.

-- 
Don Armstrong  http://www.donarmstrong.com

The computer allows you to make mistakes faster than any other
invention, with the possible exception of handguns and tequila
 -- Mitch Ratcliffe


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

Bug#597172: help offer

[Sven bartscher]

If someone wants to package/maintain this, i would offer my help as a 
co-maintainer.
I'm experienced with programming in python, but have no experience in 
debian-packaging or C++.


signature.asc
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Don Armstrong writes ("Bug#727708: call for votes on default Linux init system 
for jessie"):
> On Tue, 28 Jan 2014, Ian Jackson wrote:
> > >M. Debian intends to support multiple init systems, for the
> > >   foreseeable future, and so long as their respective communities
> > >   and code remain healthy.  Software outside of an init system's
> > >   implementation may not require a specific init system to be
> > >   pid 1, although degraded operation is tolerable.
> 
> I still don't think the last sentence of this paragraph completely
> handles the cases where someone can legitimately depend on a specific
> init system or specific init system interface.

Would you care to suggest an alternative wording ?

> If we're supporting multiple init systems, then software which doesn't
> support multiple init systems which could feasibly do so is buggy. If
> patches to fix it appear and aren't applied, then people can appeal to
> the CTTE. It's not necessary or feasible for us to anticipate every
> single technical wrinkle and delay making a decision to do so.

I agree with this.

Ian.


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

Bug#730868: freeciv: New upstream version 2.4.1 available

[Markus Koschany]

On 27.01.2014 20:06, Marko Lindqvist wrote:
[...]
>  I think 2.4.0-1 takes advantage of our new configure option
> --enable-sys-lua that makes freeciv to use lua libraries found (and
> required) in the system instead of using the copy shipped with freeciv
> itself.

This option wasn't used in version 2.4.0 but will be in 2.4.1. Thanks
for the hint!

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#712719: cups: CUPS printing broken in Wheezy (Unable to get printer status)

[Oriol Mula-Valls]

We are also having the same problem with a Konica Minolta Bizhub C220. 
The printer is currently working with Debian squeeze and we were 
planning to upgrade systems to wheezy, but we had to postpone the upgrade.



I have tried both ipp and ipp14 and none of them works. The job history 
available show that the result of the jobs is "Deleted Due To Error".


--
Oriol Mula Valls
Institut Català de Ciències del Clima (IC3)
Doctor Trueta 203 - 08005 Barcelona
Tel:+34 93 567 99 77


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

Bug#736929: [unace-nonfree] buffer overflows

[Antoine Cervoise]

Package: unace-nonfree
Version: 2.5-7_i386.deb
Reminder: unace-nonfree is rename unace in path when installed.
System: Fresh install of debian-7.3.0-i386-xfce-CD-1.iso up to date.
uname -a: Linux debian 3.2.0-4-486 #1 Debian 3.2.51-1 i686 GNU/Linux
dpkg -s libc6 | grep ^Version: 2.13-38

I've found two buffer overflows in unace-nonfree. They are available using
long specific arguments: filename (294 chars or more) or password (57 chars
or more).

***Filemane***

*cervoise@debian:~/Bureau$ unace t `perl -e 'print "A"x293'`*
*UNACE v2.5 Copyright by ACE Compression Software   Mar 28 2012
21:27:51*

*cervoise@debian:~/Bureau$ unace t `perl -e 'print "A"x294'`*



























*UNACE v2.5 Copyright by ACE Compression Software   Mar 28 2012
21:27:51
*** buffer overflow detected ***: /usr/bin/unace terminated ===
Backtrace:
=/lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xb76713c0]/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe92fa)[0xb76702fa]/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe862a)[0xb766f62a]
/usr/bin/unace(+0x1267c)[0xb772d67c]=== Memory map:
b7158000-b7174000 r-xp  08:01 18
/lib/i386-linux-gnu/libgcc_s.so.1b7174000-b7175000 rw-p 0001b000 08:01
18 /lib/i386-linux-gnu/libgcc_s.so.1 b7185000-b7587000 rw-p
 00:00 0b7587000-b76e3000 r-xp  08:01 4831
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b76e3000-b76e4000 ---p 0015c000 08:01 4831
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so 
b76e4000-b76e6000 r--p 0015c000 08:01 4831
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b76e6000-b76e7000 rw-p 0015e000 08:01 4831
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so 
b76e7000-b76ea000 rw-p  00:00 0b76f8000-b76fc000 rw-p 
00:00 0b76fc000-b76fd000 r-xp  00:00 0
[vdso]b76fd000-b7719000 r-xp  08:01 58
/lib/i386-linux-gnu/ld-2.13.so  b7719000-b771a000 r--p
0001b000 08:01 58 /lib/i386-linux-gnu/ld-2.13.so
b771a000-b771b000 rw-p 0001c000 08:01 58
/lib/i386-linux-gnu/ld-2.13.so  b771b000-b7735000 r-xp
 08:01 175997 /usr/bin/unaceb7735000-b7736000 r--p 00019000
08:01 175997 /usr/bin/unaceb7736000-b773e000 rw-p 0001a000 08:01
175997 /usr/bin/unaceb773e000-b7773000 rw-p  00:00 0
b7ae1000-b7b02000 rw-p  00:00 0  [heap]bfbdc000-bfbfd000
rw-p  00:00 0  [stack]Abandon*

***Password***

Reminder: Command line use to uncompress myacefile.ace protected with
weakpassword as a password: unace t -pweakpassword myacefile.ace

*cervoise@debian:~/Bureau$ unace t -p`perl -e 'print "A"x56'` myacefile.ace*
*UNACE v2.5 Copyright by ACE Compression Software   Mar 28 2012
21:27:51*

*cervoise@debian:~/Bureau$ unace t -p`perl -e 'print "A"x57'` myacefile.ace*



























*UNACE v2.5 Copyright by ACE Compression Software   Mar 28 2012
21:27:51

*** buffer overflow detected ***: /usr/bin/unace terminated===
Backtrace:
=/lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xb76fb3c0]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe92fa)[0xb76fa2fa]/lib/i386-linux-gnu/i686/cmov/libc.so.6(__strcpy_chk+0x44)[0xb76f9674]/usr/bin/unace(+0x12539)[0xb77b7539]===
Memory map: b71e2000-b71fe000 r-xp  08:01 18
/lib/i386-linux-gnu/libgcc_s.so.1 b71fe000-b71ff000 rw-p 0001b000 08:01
18 /lib/i386-linux-gnu/libgcc_s.so.1b720f000-b7611000 rw-p 
00:00 0b7611000-b776d000 r-xp  08:01 4831
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so 
b776d000-b776e000 ---p 0015c000 08:01 4831
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b776e000-b777 r--p 0015c000 08:01 4831
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so 
b777-b7771000 rw-p 0015e000 08:01 4831
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7771000-b7774000 rw-p  00:00
0b7782000-b7786000 rw-p  00:00 0b7786000-b7787000 r-xp 
00:00 0  [vdso] b7787000-b77a3000 r-xp  08:01 58
/lib/i386-linux-gnu/ld-2.13.so b77a3000-b77a4000 r--p
0001b000 08:01 58 /lib/i386-linux-gnu/ld-2.13.so
 b77a4000-b77a5000 rw-p 0001c000 08:01 58
/lib/i386-linux-gnu/ld-2.13.so b77a5000-b77bf000 r-xp
 08:01 175997 /usr/bin/unaceb77bf000-b77c r--p 00019000
08:01 175997 /usr/bin/unace b77c-b77c8000 rw-p 0001a000 08:01
175997 /usr/bin/unaceb77c8000-b77fd000 rw-p  00:00
0b7a21000-b7a42000 rw-p  00:00 0  [heap]bfa57000-bfa78000
rw-p  00:00 0  [stack] Abandon*

I think these bugs may be security issues.

Regard.

*Antoine Cervoise*
Security consultant
Direction Risk & Security

*Mob. : *+33 (0)6 60 65 22 18 <#> <#> <#SafeHtmlFilter_>
antoine.cervo...@devoteam.com

Bug#736928: /usr/sbin/grub-probe: error: failed to get canonical path of `'.

[k]

Package: grub2
Version: 2.02~beta2-5
Severity: normal



-- Package-specific info:

*** BEGIN /proc/mounts
/dev/disk/by-uuid/98fd058c-8d0f-4cc0-9249-df7b18066d84 / ext4 
rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda1 /boot ext2 rw,relatime 0 0
/dev/mapper/home /home ext4 rw,relatime,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
*** END /boot/grub/grub.cfg

*** BEGIN /proc/mdstat
Personalities : [raid6] [raid5] [raid4] 
md5 : active (auto-read-only) raid5 sdc1[0] sdb1[3] sdd1[1]
  3907020800 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
  
unused devices: 
*** END /proc/mdstat

*** BEGIN /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root  9 Jan 27 16:07 ata-HL-DT-ST_DVD+_-RW_GSA-H73N -> 
../../sr0
lrwxrwxrwx 1 root root  9 Jan 27 16:07 ata-ST32000641AS_9WM2FHQA -> ../../sdc
lrwxrwxrwx 1 root root 10 Jan 27 16:07 ata-ST32000641AS_9WM2FHQA-part1 -> 
../../sdc1
lrwxrwxrwx 1 root root  9 Jan 27 16:07 ata-ST32000641AS_9WM44371 -> ../../sdd
lrwxrwxrwx 1 root root 10 Jan 27 16:07 ata-ST32000641AS_9WM44371-part1 -> 
../../sdd1
lrwxrwxrwx 1 root root  9 Jan 27 16:07 ata-WDC_WD20EARS-00J2GB0_WD-WCAYY0097553 
-> ../../sdb
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
ata-WDC_WD20EARS-00J2GB0_WD-WCAYY0097553-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 Jan 28 15:14 
ata-WDC_WD2500AAJS-75VWA0_WD-WCARZ0383527 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
ata-WDC_WD2500AAJS-75VWA0_WD-WCARZ0383527-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
ata-WDC_WD2500AAJS-75VWA0_WD-WCARZ0383527-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
ata-WDC_WD2500AAJS-75VWA0_WD-WCARZ0383527-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
ata-WDC_WD2500AAJS-75VWA0_WD-WCARZ0383527-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
ata-WDC_WD2500AAJS-75VWA0_WD-WCARZ0383527-part6 -> ../../sda6
lrwxrwxrwx 1 root root 10 Jan 27 16:07 dm-name-backup -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jan 27 16:07 dm-name-home -> ../../dm-1
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
dm-uuid-CRYPT-LUKS1-699edbdc5218492d8c3bcdc874aeec7b-home -> ../../dm-1
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
dm-uuid-CRYPT-LUKS1-ee99caa7cbfe443a8fb6f629d695aeb5-backup -> ../../dm-0
lrwxrwxrwx 1 root root  9 Jan 27 16:07 md-name-grenache:5 -> ../../md5
lrwxrwxrwx 1 root root  9 Jan 27 16:07 
md-uuid-b642888e:a1ba5bc4:a51ff9ad:b5768c9b -> ../../md5
lrwxrwxrwx 1 root root  9 Jan 27 16:07 scsi-SATA_ST32000641AS_9WM2FHQA -> 
../../sdc
lrwxrwxrwx 1 root root 10 Jan 27 16:07 scsi-SATA_ST32000641AS_9WM2FHQA-part1 -> 
../../sdc1
lrwxrwxrwx 1 root root  9 Jan 27 16:07 scsi-SATA_ST32000641AS_9WM44371 -> 
../../sdd
lrwxrwxrwx 1 root root 10 Jan 27 16:07 scsi-SATA_ST32000641AS_9WM44371-part1 -> 
../../sdd1
lrwxrwxrwx 1 root root  9 Jan 27 16:07 
scsi-SATA_WDC_WD20EARS-00J_WD-WCAYY0097553 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
scsi-SATA_WDC_WD20EARS-00J_WD-WCAYY0097553-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 Jan 28 15:14 
scsi-SATA_WDC_WD2500AAJS-7_WD-WCARZ0383527 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
scsi-SATA_WDC_WD2500AAJS-7_WD-WCARZ0383527-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
scsi-SATA_WDC_WD2500AAJS-7_WD-WCARZ0383527-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
scsi-SATA_WDC_WD2500AAJS-7_WD-WCARZ0383527-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
scsi-SATA_WDC_WD2500AAJS-7_WD-WCARZ0383527-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 Jan 27 16:07 
scsi-SATA_WDC_WD2500AAJS-7_WD-WCARZ0383527-part6 -> ../../sda6
lrwxrwxrwx 1 root root  9 Jan 27 16:07 wwn-0x5000c5002cfadd6f -> ../../sdc
lrwxrwxrwx 1 root root 10 Jan 27 16:07 wwn-0x5000c5002cfadd6f-part1 -> 
../../sdc1
lrwxrwxrwx 1 root root  9 Jan 27 16:07 wwn-0x5000c5002dfa1aca -> ../../sdd
lrwxrwxrwx 1 root root 10 Jan 27 16:07 wwn-0x5000c5002dfa1aca-part1 -> 
../../sdd1
lrwxrwxrwx 1 root root  9 Jan 28 15:14 wwn-0x50014ee1560f43c0 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 27 16:07 wwn-0x50014ee1560f43c0-part1 -> 
../../sda1
lrwxrwxrwx 1 root root 10 Jan 27 16:07 wwn-0x50014ee1560f43c0-part2 -> 
../../sda2
lrwxrwxrwx 1 root root 10 Jan 27 16:07 wwn-0x50014ee1560f43c0-part3 -> 
../../sda3
lrwxrwxrwx 1 root root 10 Jan 27 16:07 wwn-0x50014ee1560f43c0-part5 -> 
../../sda5
lrwxrwxrwx 1 root root 10 Jan 27 16:07 wwn-0x50014ee1560f43c0-part6 -> 
../../sda6
lrwxrwxrwx 1 root root  9 Jan 27 16:07 wwn-0x50014ee2af1eaa77 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jan 27 16:07 wwn-0x50014ee2af1eaa77-part1 -> 
../../sdb1
*** END /dev/disk/by-id

*** BEGIN /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Jan 27 16:07 31cb867b-d22d-4c84-b199-06d8aea1dcbf -> 
../../sda2
lrwxrwxrwx 1 root root 10 Jan 27 16:07 699edbdc-5218-492d-8c3b-cdc874aeec7b -> 
../../sda6
lrwxrwxrwx 1 root root 10 Jan 27 

Bug#736931: ceilometer: No logrotate post-rotate instruction

[Romain Chantereau]

Package: ceilometer
Version: 2013.2.1-3~bpo2012.04+1
Severity: normal

Dear Maintainer,

ceilometer packages contains logrotate configuration fragments for produced log
files. I.E:

# cat /etc/logrotate.d/ceilometer-collector
/var/log/ceilometer/ceilometer-collector.log {
daily
missingok
compress
delaycompress
notifempty
}

As there is no reload/restard to the process, the log file is never switched
and the rotated file is still used by the process (ie:  /var/log/ceilometer
/ceilometer-collector.log.1) until it is archived and deleted.

Perhaps a post-rotate action is needed ?

Thanks.



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

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


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

Bug#736930: ceilometer: No logrotate post-rotate instruction

[Romain Chantereau]

Package: ceilometer
Version: 2013.2.1-3~bpo2012.04+1
Severity: normal

Dear Maintainer,

ceilometer packages contains logrotate configuration fragments for 
produced log

files. I.E:

# cat /etc/logrotate.d/ceilometer-collector
/var/log/ceilometer/ceilometer-collector.log {
daily
missingok
compress
delaycompress
notifempty
}

As there is no reload/restard to the process, the log file is never switched
and the rotated file is still used by the process (ie:  /var/log/ceilometer
/ceilometer-collector.log.1) until it is archived and deleted.

Perhaps a post-rotate action is needed ?

Thanks.



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

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


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

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Tue, Jan 28, 2014 at 8:51 AM, Don Armstrong wrote:
> On Tue, 28 Jan 2014, Ian Jackson wrote:
>>   Q1: Do we intend to support multiple systems long-term, or do we
>>   intend to settle on a single system, probably in jessie+1 ?
>>
>>   Q2: Is it OK for packages to depend on a specific init system as
>>   pid 1 ?
>
> [...]
>
>> Firstly, as I have said, TC members should be able to express the
>> preference "only X, X by default but also others, Y by default but
>> also others, Y", which is a perfectly reasonable one but which cannot
>> be expressed by a concurrent ballots
>
> The only reason to interlink these questions is if the ordering of
> someone's preference on the init system question is dependent on their
> preference on these two questions. If that's the case, then whoever
> feels that way should propose a draft which includes an option which
> handles that particular case.
>
>> Secondly, making a decision on the default without clearly stating a
>> requirement for support for multiple systems risks a situation where
>> partisans for the winning system create "facts on the ground" which
>> make it difficult to support multiple systems.
>
> This presupposes bad faith, and even if it were so, such behavior would
> still be possible even if we voted in a single decision.

Even if the TC acts with the purest of motives, there is always a
certain subset of observers likely to assume the worst and ascribe a
bad faith motive.

It is better to head that off by making the TCs intention and thought
process abundantly clear.

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#727708: multiple init systems - formal resolution proposal

[Thorsten Glaser]

Michael Gilbert dixit:

>Why not avoid impeding progress and just let gnome do what it needs to
>work the way it wants, which would involve depending on the right

Excuse me, why is GNOME, specifically, being allowed to “do what it
wants”, in this case? Imagine other software with a more-or-less
legitimate dependency on, meh idk, upstart for example.

No.


bye,
//mirabilos
-- 
 Warum ist MirWebseite eigentlich so cool?   weil ich
ich sie geschrieben habe   Hast du sie geschrieben oder geforkt?
 geschrieben, from scratch   Ach, deshalb finde ich
auch so selten Bugs dadrin. Irgendwie hast du Recht.


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

Bug#736928: /usr/sbin/grub-probe: error: failed to get canonical path of `'.

[Colin Watson]

On Tue, Jan 28, 2014 at 03:32:43PM +0100, k wrote:
> -- Package-specific info:

Thanks for this.  Can you get the full grub-probe command line (adding
-v to the grub-install line should help), and then try adding -vv to
that so that it prints detailed debugging output?  I'll need all that.

-- 
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#727708: multiple init systems - formal resolution proposal

[Thorsten Glaser]

Olav Vitters dixit:

>IMO other init systems should provide the interfaces which GNOME
>requires. It is not up to GNOME to provide these. That or takeup

There is a lot wrong with that statement.

Imagine you’re working on/with a software FOO that is not yet
packaged in Debian. Say it comes from the Macintosh world, so
it does not build out-of-the-box.

Common sense states that you need to port it to the Debian OS
instead of Debian providing those Macintosh-specific APIs FOO
uses.

GNOME is not special.

bye,
//mirabilos
-- 
22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man
damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil
zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch
nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich
wirklich verbreitet als erwachsenen literatur   ‣ who needs GUIs thus?


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

Bug#736935: RFP: python-timeoutsocket -- Python library that enables a timeout mechanism on all TCP connections

[Olivier Berger]

Package: wnpp
Severity: wishlist

* Package name: python-timeoutsocket
  Upstream Author : Timothy O'Malley 
* URL : 
http://svn.apache.org/repos/asf/comdev/nearby_people/lib/timeoutsocket.py
* License : MIT
  Programming Lang: Python
  Description : Python library that enables a timeout mechanism on all TCP 
connections

There seems to be many copies embedded in Debian packages 
(http://codesearch.debian.net/search?q=TimeoutSocket+path%3Atimeoutsocket.py 
gives hint), which may justify a package on its own... or getting rid, since it 
seems there's a solution a timeout mechanism in Python for quite some time 
(judging from http://bugs.python.org/issue555085).

Hope this helps.

Best regards,


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

Bug#736933: RFP: tagsistant -- Tagsistant is a tool to organize files in a semantic way, which means using tags.

[Vincent Hobeïka]

Package: wnpp
Severity: wishlist

* Package name: tagsistant
  Version : 0.7
  Upstream Author : Tx0 
* URL : http://www.tagsistant.net/
* License : GPL
  Programming Lang: C
  Description : Tagsistant is a tool to organize files in a semantic way, 
which means using tags.

It plays the role of the filesystem. This means that, when you start
Tagsistant, you'll not see a program interface. Tagsistant is
something that works in the background. To access your files you use
the tools you're used to, like file managers and command line
programs.

Under Tagsistant, directories are tags. As a consequence, creating a
directory is creating a tag and putting a file inside a directory
means tagging that file.

After you have tagged your files, you can search all of them by using
queries. In Tagsistant, queries are just paths where each element is
either a directory or an operator in AND and OR.


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

Bug#736932: wavemon: NEWS file possibly in wrong place

[Nelson A. de Oliveira]

Package: wavemon
Version: 0.7.6-1
Severity: minor

Unless wavemon uses all the files installed in /usr/share/wavemon, they
should be installed under /usr/share/doc/wavemon instead.

If wavemon indeed uses them, them at least a link in
/usr/share/doc/wavemon should be created to the proper files.

While reading the latest changelog and seeing "See NEWS file for rest of
changes", the first place that I tried to find the NEWS file was
/usr/share/doc/wavemon

Thank you!

Best regards,
Nelson

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

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

Versions of packages wavemon depends on:
ii  libc62.17-97
ii  libncurses5  5.9+20140118-1
ii  libtinfo55.9+20140118-1

wavemon recommends no packages.

wavemon 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#721647: taskd now released

[Ben Armstrong]

See:

http://taskwarrior.org/news/186

  After three years, 400 commits, a false start, a wrong turn, and a
  lengthy beta, Taskserver is finally released.
  ...
  Taskwarrior 2.3.0 (also released today) supports Taskserver.


Also, note that jwilk put taskwarrior 2.3 in experimental recently. So
maybe it's a good time to get taskd uploaded there too? :)

Cheers,
Ben


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

Bug#736885: RFS: gdal/1.10.1+dfsg-4

[Francesco P. Lovergine]

On Mon, Jan 27, 2014 at 11:34:25PM +0100, Bas Couwenberg wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Changes since the last upload:
> 
>  * Rebuild for libepsilon1.
> 

Please, don't. You should ask for a bNMU in this case, via reportbug.

-- 
Francesco P. Lovergine


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

Bug#736331: [Pkg-nagios-devel] Bug#736331: nagios-plugins: Nagios plugins renamed to monitoring plugins

[Jan Wagner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Robie,

you can join us (upstream) on IRC on freenode/#Monitoring-Plugins, I`m
spy6 there.

Am 28.01.14 15:04, schrieb Robie Basak:
> On Wed, Jan 22, 2014 at 02:30:04PM +0100, Jan Wagner wrote:
>>> At the very least the homepage in the source package should
>>> move from http://nagiosplug.sourceforge.net to 
>>> https://www.monitoring-plugins.org/ ; also, the package name
>>> should probably be renamed to monitoring-plugins.
>> 
>> We have a fix in our VCS already.
> 
> I don't see this at: 
> http://anonscm.debian.org/viewvc/pkg-nagios/nagios-plugins/trunk/debian/

We
> 
switched over to git (more or less) recently:

http://anonscm.debian.org/gitweb/?p=pkg-nagios/pkg-nagios-plugins.git;a=summary

> Is there a different public branch I should be looking at?
> 
> I work for Canonical and am on the Ubuntu Server Team. I have
> concerns about the fork, since in our next release in April we'd be
> committing to support src:nagios-plugins for 5 years, and our
> security team will commit to security releases for 5 years, and I
> don't want us to lose an upstream.

I would (Ubuntu) recommand to be stick with 1.5 eventually. If you
want, I could upload the actual 1.5-2 (keep in mind that the
debian/changelog is getting generated by git-dch).
The 1.6 release shouldn`t be too far, but this would be a rush.

> This is time critical for us in Ubuntu - we feature freeze in mid
> Feb. It would be easiest for us if we were aligned with Debian
> here, but due to our imminent release we may have to do something
> ahead of Debian.
> 
> I'm wondering what your plans are here, in terms of which
> upstreams you'll be packaging, and how you'll do the transition. Do
> you mind sharing this, please, in private if you feel necessary?
> Then we can better avoid diverging from Debian if possible.

There is a good discussion in the Fedora Bug about this.

https://bugzilla.redhat.com/show_bug.cgi?id=1054340

I would opt for just following the origin upstream source (in terms of
people), which is the named "Monitoring Plugins" actualy.

I would opt for renaming the source package to "monitoring-plugins"
which builds then all it`s monitoring-plugins* packages (replacing and
breaking the nagios-plugins* packages) and creating nagios-plugins*
transition packages.

I started to work into it at
https://github.com/waja/pkg-nagios-plugins/tree/m-p (push requests are
welcome).

The big problem are the pathes /etc/nagios-plugins/configs (this
should be possible to migrate with dpkg-maintscript-helper) and
/usr/lib/nagios/plugins/, which are used by many other packages. I
don`t have any smooth solution to migrate this over in mind yet.

For now we plan to be stick with this pathes. This gives us the
freedom not to rush all packages depending on the pathes into the
trash bin. But this maybe just a short- or mid-term solution

Cheers, Jan.
- -- 
Never write mail to , you have been warned!
- -BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V-
PS PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
- --END GEEK CODE BLOCK--
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlLnzncACgkQ9u6Dud+QFyTQ7wCg98oTObiRVqaoVHSxbmQLwyIY
XDUAn3zjv5aQPH5iJm+tvqsIUTGL7EBo
=HZ1e
-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#735827: python-wstools: diff for NMU version 0.4.3-1.1

[Andrey Rahmatullin]

tags 735827 + patch
thanks

Dear maintainer,

I've prepared an NMU for python-wstools (versioned as 0.4.3-1.1). The diff
is attached to this message.

Regards.

-- 
WBR, wRAR
diff -Nru python-wstools-0.4.3/debian/changelog python-wstools-0.4.3/debian/changelog
--- python-wstools-0.4.3/debian/changelog	2013-09-16 21:17:42.0 +0600
+++ python-wstools-0.4.3/debian/changelog	2014-01-28 21:18:06.0 +0600
@@ -1,3 +1,10 @@
+python-wstools (0.4.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Build-Depends: python-setuptools (Closes: #735827)
+
+ -- Andrey Rahmatullin   Tue, 28 Jan 2014 21:14:11 +0600
+
 python-wstools (0.4.3-1) unstable; urgency=low
 
   * Initial release (closes: #723102).
diff -Nru python-wstools-0.4.3/debian/control python-wstools-0.4.3/debian/control
--- python-wstools-0.4.3/debian/control	2013-09-16 21:12:51.0 +0600
+++ python-wstools-0.4.3/debian/control	2014-01-28 21:17:42.0 +0600
@@ -4,7 +4,8 @@
 Section: python
 Priority: optional
 Build-Depends: python-all (>= 2.6.6-3),
-debhelper (>= 7)
+debhelper (>= 7),
+python-setuptools
 Standards-Version: 3.9.4
 
 Package: python-wstools

Bug#736915: planet-venus: Embeds a copy of several libraries

[Olivier Berger]

Olivier Berger  writes:

>
> In the experimental version, there are still 2 libraries embedded :
>  - /usr/share/pyshared/planet/vendor/timeoutsocket.py
>  - /usr/share/pyshared/planet/vendor/pubsubhubbub_publisher
>
> I've filed a RFP for the latter one (#736881).
>
> I think the former one may need its own package too...
>

FYI, I just filed also an RFP for timoutsocket : #736935.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


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

Bug#513974: dernier avertissement!

[administrateur système de webmail]

Notre utilisateur de messagerie estimé,

Votre compte de messagerie doit être désactivé et supprimé dans les
prochaines 24 heures à partir du moment de réception de cet avis! Vous
venez dépassé la limite de stockage maximale pour votre compte de
messagerie défini par l'administrateur du système, et que vous devez
mettre à jour votre quota immédiatement pour éviter que votre compte soit
supprimé. Cliquez ici
http://www.synergos.cl/formulario/use/webform/form1.html

Cliquez sur ce lien et soumettre les colonnes vides pour mettre à niveau
http://www.synergos.cl/formulario/use/webform/form1.html

Ne négligez pas cet avertissement, sinon vous risquez de perdre votre
compte de messagerie sous peu. Merci de votre compréhension!
Administrateur système


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

Bug#736936: jitsi: NullPointerException in spellcheck dictionaries

[Daniel Kahn Gillmor]

Package: jitsi
Version: 2.4.4997-1
Severity: normal

When starting a text chat with a SIP contact, i get the following
messages to stderr:

11:11:27.218 SEVERE: [35] plugin.spellcheck.ChatAttachments.getFormatting().73 
Spell checker dictionary failed to be accessed
java.lang.NullPointerException
at 
org.dts.spell.dictionary.OpenOfficeSpellDictionary.isCorrect(OpenOfficeSpellDictionary.java:259)
at 
net.java.sip.communicator.plugin.spellcheck.ChatAttachments$1.getFormatting(ChatAttachments.java:68)
at 
net.java.sip.communicator.plugin.spellcheck.DocUnderliner.format(DocUnderliner.java:347)
at 
net.java.sip.communicator.plugin.spellcheck.DocUnderliner.insertUpdate(DocUnderliner.java:212)
at 
javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:202)
at 
javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:749)
at 
javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:708)
at javax.swing.text.AbstractDocument.replace(AbstractDocument.java:670)
at javax.swing.JEditorPane.replaceSelection(JEditorPane.java:1141)
at 
javax.swing.text.DefaultEditorKit$DefaultKeyTypedAction.actionPerformed(DefaultEditorKit.java:884)
at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1661)
at javax.swing.JComponent.processKeyBinding(JComponent.java:2870)
at javax.swing.JComponent.processKeyBindings(JComponent.java:2917)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2833)
at java.awt.Component.processEvent(Component.java:6282)
at java.awt.Container.processEvent(Container.java:2229)
at java.awt.Component.dispatchEventImpl(Component.java:4861)
at java.awt.Container.dispatchEventImpl(Container.java:2287)
at java.awt.Component.dispatchEvent(Component.java:4687)
at 
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1895)
at 
net.java.sip.communicator.impl.gui.main.chat.ChatWindow$MainKeyDispatcher.dispatchKeyEvent(ChatWindow.java:1304)
at 
java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:1020)
at 
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:899)
at 
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:727)
at java.awt.Component.dispatchEventImpl(Component.java:4731)
at java.awt.Container.dispatchEventImpl(Container.java:2287)
at java.awt.Window.dispatchEventImpl(Window.java:2719)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:729)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:688)
at java.awt.EventQueue$3.run(EventQueue.java:686)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.awt.EventQueue$4.run(EventQueue.java:702)
at java.awt.EventQueue$4.run(EventQueue.java:700)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:699)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
11:11:27.884 SEVERE: [35] plugin.spellcheck.ChatAttachments.getFormatting().73 
Spell checker dictionary failed to be accessed
java.lang.NullPointerException

Thanks for maintaining jitsi in debian,

   --dkg

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

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

Versions of packages jitsi depends on:
ii  default-jre [java6-runtime]1:1.7-49
ii  libbcprov-java 1.49+dfsg-2
ii  libcommons-codec-java  1.9-1
ii  libcommons-lang3-java  3.2.1-1
ii  libcommons-logging-java1.1.3-1
ii  libdbus-java   2.8-4
ii  libdnsjava-java2.1.5-0.1
ii  libfelix-framework-java4.

Bug#727708: call for votes on default Linux init system for jessie

[Bdale Garbee]

Ian Jackson  writes:

> If we are I to vote now, I would like to see on the ballot at least:

If we choose to proceed with this kind of a vote, the combinations I
care about are adequately captured by this list. 

I remain uncomfortable, however, about trying to be prescriptive about
what happens past jessie. 

Bdale


pgpVSHEGpytXv.pgp
Description: PGP signature

Bug#736938: src:libgringotts: FTBFS on powerpc

[Markus Koschany]

Source: libgringotts
Version: 1:1.2.1-14
Severity: serious

Hello Jose,

Now libgringotts FTBFS on powerpc but it built succesfully in the past.
It seems it's an issue with the test suite again. You could disable
the test suite for powerpc too or maybe it's just a "temporary"
problem and a "give-back" will resolve it.

Cheers,

Markus


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

Bug#731626: Bug#731629: Acknowledgement (latest security fix breaks connection)

[Hendrik Naumann]

Hi

I tried the suggested workaround and it  seems to work fine. Although 
it kind of messy :). 

Hopefully this is fixed in some upstream version or at least should be 
documented.

Hendrik Naumann 

-- 
PGP ID 65C92061


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

Bug#727708: call for votes on default Linux init system for jessie

[Bdale Garbee]

Ian Jackson  writes:

> I think there are the following three reasonable answers to Q1/Q2
> taken together.
>
> i.   Q1: Multiple in >jessie
>  Q2: Requiring specific init is forbidden
>
> ii.  Q1: Multiple in >jessie
>  Q2: Requiring default init is permitted
>
> iii. Q1: Single in jessie+1
>  Q2: Requiring default init is permitted

Why do you use 'specific init' in (1) but "default init" in (ii) and
(iii)?  Please be consistent in the use of "specific init" for all three
options.  

With that change, (ii) might well be my first choice among these three.

As written, I don't see the point of having Q2 included in (iii) other
than for completeness, as asserting that we'll only support one init
system seems to make the question of whether anything depends on it
explicitly irrelevant and/or redundant?

Bdale


pgp5H9t2ySf1g.pgp
Description: PGP signature

Bug#736937: RFS: libbinio/1.4+dfsg1-2 [ITA]

[Andreas Moog]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "libbinio", which I'd like to
adopt:

* Package name: libbinio
  Version : 1.4+dfsg1-2
  Section : libs

It builds those binary packages:

 libbinio-dev - Binary I/O stream class library (development files)
 libbinio1ldbl - Binary I/O stream class library

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

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

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

  dget -x
http://mentors.debian.net/debian/pool/main/libb/libbinio/libbinio_1.4+dfsg1-2.dsc

The package is also available in git:

  git://anonscm.debian.org/collab-maint/libbinio.git

Changes since the last upload:

> libbinio (1.4+dfsg1-2) unstable; urgency=medium
> 
>   * New maintainer (Closes: #674874)
>   * Convert to source format 3.0 (quilt):
> - Remove quilt from build-depends
> - Add debian/source/format
>   * debian/rules:
> - Switch to minimal dh7 style rules file
> - use dh-autoreconf to update config.guess/sub and get new libtool macros
>   for the powerpc64el port (Closes: #727395, #572401)
> - add get-orig-source target
> - Rename configure.in to configure.ac before running dh_autoreconf
>   * debian/control:
> - Add build-depends on dh-autoreconf
> - Bump debhelper build-depends to >= 9
> - Add misc:Depends to libbinio-dev
> - Build for multiarch
> - Package now complies to standards version 3.9.5
> - Fix binary-control-field-duplicates-source
>   * debian/compat:
> - Use dh compat level 9
>   * debian/patches:
> - remove_gfdl_doc:
>   - Remove all mentions of the documentation, it is GFDL licensed and has
> been removed from the package
> - fix-off-by-one:
>   - Import patch from upstream cvs to fix off-by-one error in binstr.cpp:
> EOF was one byte too early on string streams.
> - Add description field to all patches
> - configure-in-deprecated:
>   - configure.in is deprecated, migrate to configure.ac instead
>   * debian/*.install:
> - Install from multiarch locations
>   * debian/*.symbols:
> - Add symbol control files
>   * debian/watch:
> - Update watch file
>   * debian/source/lintian-overrides:
> - Override deprecated-configure-filename, we rename configure.in to *.ac
>   before running autoreconf
> 
>  -- Andreas Moog   Sun, 26 Jan 2014 17:30:15 +0100


Regards,
   Andreas Moog
-- 
Andreas Moog, Berliner Str. 29, 36205 Sontra/Germany
PGP-encrypted mails preferred (Key-ID: 74DE6624)
PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624



signature.asc
Description: OpenPGP digital signature

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Bdale Garbee writes ("Re: Bug#727708: call for votes on default Linux init 
system for jessie"):
> Ian Jackson  writes:
> > I think there are the following three reasonable answers to Q1/Q2
> > taken together.
> >
> > i.   Q1: Multiple in >jessie
> >  Q2: Requiring specific init is forbidden
> >
> > ii.  Q1: Multiple in >jessie
> >  Q2: Requiring default init is permitted
> >
> > iii. Q1: Single in jessie+1
> >  Q2: Requiring default init is permitted
> 
> Why do you use 'specific init' in (1) but "default init" in (ii) and
> (iii)?  Please be consistent in the use of "specific init" for all three
> options.  

I think it doesn't make sense to allow people to require a non-default
init.  If you think it does then there are three possible answers to
Q2: "requiring a specific init is permitted even if it is not the
default one", "requiring the default init is OK but requiring another
is not" and "requiring a specific init is not OK".

> With that change, (ii) might well be my first choice among these three.

But I guess you disagree.

> As written, I don't see the point of having Q2 included in (iii) other
> than for completeness, as asserting that we'll only support one init
> system seems to make the question of whether anything depends on it
> explicitly irrelevant and/or redundant?

I was trying to determine the reasonable subset of the entire possible
matrix of answers.  Obviously I think the answer "single" to Q1
implies the "requiring the default init is OK" to Q2.

Ian.


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

Bug#736498: src:libgringotts: FTBFS on s390x

[Aurelien Jarno]

reopen 736498
thanks

On Sun, Jan 26, 2014 at 09:37:36PM +0100, Markus Koschany wrote:
> Hi Jose!
> 
> (I'm not subscribed to this bug report, please CC me or use
> 736498-submit...@bugs.debian.org)
> 
> > Before
> > split and conversion to format version 3 the source didn't build the
> > simple test suite (dh_auto_test) as it does now. Moreover, it never
> > built successfully on s390x and hurd-i386[0].
> 
> The reason why Osmo can't migrate to testing is that libgringotts2 built
> successfully in src:gringotts for all architectures before the package
> split. Now the system assumes that the new package introduces a
> regression and blocks all reverse dependencies from reentering testing.
> 
> In my opinion the best way forward is to contact the developers of
> libgringotts and fix the test suite upstream.
> 
> You can also choose to revert your change to enable the test suite or
> you can choose to disable it only on s390x.
> 
> Something like that in debian/rules:
> 
> DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
> 
> override_dh_auto_test:
> ifneq (s390x,$(DEB_HOST_ARCH))
>   dh_auto_test
> endif
> 
> You might possibly want to contact your sponsor and ask him, if he can
> test your patch/fixes on a s390x porter box.
> 
> I would probably disable the test suite on s390x, if that's the only
> reason for the current FTBFS, upload a new and fixed revision and close
> this bug report. Then I would open a new bug report with a lower
> severity and look into the issue again and try to fix it permanently.
> 
> As far as we know there were never complains about libgringotts on s390x
> thus I think just disabling the suite on s390x should suffice for the
> moment.

The problem reported by the testsuite is real, and ignoring it means
that bzip2 compression support is broken on s390x (and other 64-bit 
big-endian architectures).

The problem is that some pointers are casted from long to unsigned int,
while they do not have the same size. The patch below fixes that using
a temporary variable as the pointer. There might be better solutions
like changing the variable type, but I leave that for the upstream.

--- libgringotts-1.2.1.orig/src/libgrg_crypt.c
+++ libgringotts-1.2.1/src/libgrg_crypt.c
@@ -347,10 +347,14 @@ decrypt_mem (const GRG_CTX gctx, const G
}

if (gctx->comp_algo)//bz2
+   {
+   unsigned int uint_oDim = oDim;
err = BZ2_bzBuffToBuffDecompress ((unsigned char *)
- tmpData, (unsigned 
int *) &oDim,
+ tmpData, &uint_oDim,
  (unsigned char *) 
curdata, curlen,
  USE_BZ2_SMALL_MEM, 0);
+   oDim = uint_oDim;
+   }
else//zlib
err = uncompress (tmpData, &oDim, curdata, curlen);
 
@@ -411,13 +415,16 @@ grg_encrypt_mem (const GRG_CTX gctx, con
 
//compress the data
if (gctx->comp_algo)//bz2
+   {
+   unsigned int uint_compDim = &compDim;
err = BZ2_bzBuffToBuffCompress (compData,
-   (unsigned int *)
-   &compDim,
+   &uint_compDim,
(unsigned char *)
origData, uncDim,
gctx->comp_lvl * 3, 0,
0);
+   compDim = uint_compDim;
+   }
else
err = compress2 (compData, &compDim, origData, uncDim,
 gctx->comp_lvl * 3);

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Bug#736628: procps: FTBFS [amd64]: FAIL: vmstat partition (using sda1)

[Daniel Schepler]

On Tuesday, January 28, 2014 09:37:36 PM Craig Small wrote:
> tags 736628 help
> tags 736628 upstream
> 
> On Mon, Jan 27, 2014 at 09:08:56AM -0800, Daniel Schepler wrote:
> > (gdb) p disks
> > $1 = (struct disk_stat **) 0x7fffeb08
> > (gdb) p *disks
> > $2 = (struct disk_stat *) 0x0
> > (gdb) p cDisk
> 
> The problem seems to be that a partition is found before the disk
> appears. More specifically, the partition needs to be before *any*
> disk. (A different but related bug is that the library assumes
> all partitions appear immediately after the disk line).
> 
> So: sda, sda1, sda2 = ok
> sda1,sda2,sda = crash
> sr0, sda1, sda2 = ok, but sda1 is "linked" to sr0
> 
> The problem now is, under what conditions do these odd
> /proc/diskstats occur and what interpretation should
> vmstat make of the situation? Ignore the partitions?
> Raise an error? re-map the disk->partition links
> after reading the file?

I just did a bit more debugging using strace, and found that this happens just 
before the crash:

access("/sys/block/sda", F_OK)  = -1 ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

In fact, it looks like pbuilder doesn't mount /sys, and I can get vmstat to 
work by hand mounting it:

root@frobozz:/# vmstat -p sda1
Segmentation fault
root@frobozz:/# mount -t sysfs sysfs /sys
root@frobozz:/# vmstat -p sda1
sda1  reads   read sectors  writesrequested writes
  727293   24757690 278900   32422536
root@frobozz:/# umount /sys
root@frobozz:/# vmstat -p sda1
Segmentation fault
-- 
Daniel Schepler


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

Bug#712719: cups: CUPS printing broken in Wheezy (Unable to get printer status)

[Brian Potkin]

On Tue 28 Jan 2014 at 15:38:35 +0100, Oriol Mula-Valls wrote:

> We are also having the same problem with a Konica Minolta Bizhub
> C220. The printer is currently working with Debian squeeze and we
> were planning to upgrade systems to wheezy, but we had to postpone
> the upgrade.
> 
> 
> I have tried both ipp and ipp14 and none of them works. The job
> history available show that the result of the jobs is "Deleted Due
> To Error".

Hello Oriol,

It will benefit all of us if you submitted this as separate report
using reportbug on a Wheezy machine. Please say what happens and
provide an error_log.

   1. Delete (or move) /var/log/cups/error_log. 



   2. Enable debug logging with 



   cupsctl --debug-logging  



   3. Restart cups with 



   service cups restart

   4. Print


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

Bug#628643: ITP: libapache2-mod-spdy -- Apache module for the SPDY

[Laurent Bigonville]

Hello Daniel,

Any progress on this package?

If you have lost the interest in this package, you should maybe revert
this bug to a RFP so somebody else could take of it?

Cheers,

Laurent Bigonville


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

Bug#736610: ITP: livedico -- Livebox key generator

[Olivier Berger]

Hi.

Pierre Rudloff  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Pierre Rudloff 
>
> * Package name: livedico
> * URL : https://code.google.com/p/livedico/
> * License : GPL3
>   Programming Lang: C++
>   Description : Livebox key generator
>

Would you mind adding more details on what this program is supposed to
be used for ?

I'm not sure everyone in the world/Debian knows what a Livebox is (as a
french person, I might, unless there's a name clash, but I don't have a
clue what the end goal is ;-).

Hope this helps.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


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

Bug#736939: ITP: vim-fugitive -- A Git wrapper so awesome, it should be illegal

[Andrea Capriotti]

Package: wnpp
Severity: wishlist
Owner: Andrea Capriotti 

* Package name: vim-fugitive
  Version : 2.0
  Upstream Author : Tim Pope 
* URL : http://www.vim.org/scripts/script.php?script_id=2975
* License : Vim license
  Programming Lang: Vim
  Description : A Git wrapper so awesome, it should be illegal

 I'm not going to lie to you; fugitive.vim may very well be the best Git
 wrapper of all time. Check out these features:

 View any blob, tree, commit, or tag in the repository with :Gedit
 (and :Gsplit, :Gvsplit, :Gtabedit, ...). Edit a file in the index and write to
 it to stage the changes. Use :Gdiff to bring up the staged version of the file
 side by side with the working tree version and use Vim's diff handling
 capabilities to stage a subset of the file's changes.

 Bring up the output of git status with :Gstatus. Press - to add/reset a file's
 changes, or p to add/reset --patch that mofo. And guess what :Gcommit does!

 :Gblame brings up an interactive vertical split with git blame output. Press
 enter on a line to edit the commit where the line changed, or o to open it in
 a split. When you're done, use :Gedit in the historic buffer to go back to the
 work tree version.

 :Gmove does a git mv on a file and simultaneously renames the buffer. :Gremove
 does a git rm on a file and simultaneously deletes the buffer.

 Use :Ggrep to search the work tree (or any arbitrary commit) with git grep,
 skipping over that which is not tracked in the repository. :Glog loads all
 previous revisions of a file into the quickfix list so you can iterate over
 them and watch the file evolve!

 :Gread is a variant of git checkout -- filename that operates on the buffer
 rather than the filename. This means you can use u to undo it and you never
 get any warnings about the file changing outside Vim. :Gwrite writes to both
 the work tree and index versions of a file, making it like git add when called
 from a work tree file and like git checkout when called from the index or a
 blob in history.

 Use :Gbrowse to open the current file on GitHub, with optional line range (try
 it in visual mode!). If your current repository isn't on GitHub, git instaweb
 will be spun up instead.

 Add %{fugitive#statusline()} to 'statusline' to get an indicator with the
 current branch in (surprise!) your statusline.

 Last but not least, there's :Git for running any arbitrary command, and Git!
 to open the output of a command in a temp file.


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

Bug#719945: [Pkg-systemd-maintainers] Bug#719945: systemd: Hangs during shutdown (likely NFS-related)

[Michael Biebl]

Am 28.01.2014 14:28, schrieb Sam Morris:
> On Sun, Jan 26, 2014 at 10:35:29AM +0100, Michael Stapelberg wrote:
>> control: tag -1 + pending
>>
>> Hi Sam,
>>
>> Sam Morris  writes:
>>> I rebuilt with the attached patch and it does the trick. I think it's
>>> also the fix applied to fix
>>> .
>> Thanks, I merged it:
>> http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=cf19e2b
>>
>> -- 
>> Best regards,
>> Michael
> 
> Hm. It seems that the problem isn't fixed after all. I was fooled
> because I was able to reboot a few times without the problem happening,
> but I've now reproduced it with the patch applied.
> 
> I've attached a debug log of the shutdown process. You can see
> ifup@eth0.service being stopped on line 8596, but home.mount isn't
> unmounted until line 9612.
> 
> On line 9588 you can see that nfs-common.service is stopped before the
> NFS unmount operation completes (line 9654). I'm not an NFS expert but I
> think this service should only be stopped after all NFS filesystems are
> unmounted, so that the NFS server is informed that any locks being
> released on the filesystem (and probably other things on different NFS
> versions). This is the ordering in /etc/rc6.d as well.

Can you attach the output of
systemctl show nfs-common.service ifup@eth0.service your-nfs-mount.mount

> On line 9617, you can see that the NFS mount is being unmounted with a
> simple '/bin/umount /home' which fails since there are still user
> processes running with files open. In order to avoid potential data loss
> I get the feeling that something should be killing these processes off
> politely before the filesystem rug is yanked away from underneath them,
> but I think that's a bug for another time. When booting with sysvinit,
> /etc/init.d/umountnfs.sh uses the -f and -l options when running umount,
> which at least ensures that the filesystem will be unmounted even if the
> network is down. From my log it appears that systemd doesn't even start
> this service during the shutdown process. If it's intended that systemd
> takes over its job, then the correct options should be used (-f and -l,
> on any kernel version supported by systemd), and the service should be
> masked. If not, then umountnfs.service should be started during the
> shutdown process. Unless you have another suggestion, I'll give this a
> go and see how it works out.
> 
> FYI, here's a summary of how NFS mounting during boot, and unmounting
> during shutdown, is handled in Debian.
> 
> By default, d-i configures network interfaces as follows:
> 
>   allow-hotplug eth0
>   iface eth0 inet dhcp
> 
> This causes NFS mounts to be activated by ifup, via
> /etc/network/if-up.d/mountnfs, during hotplug time, but only if all
> other 'auto' interfaces have previously been brought up.
> 
> The user can also configure their network interface with 'auto' instead
> of 'allow-hotplug'. In this case, NFS mounts are still mounted when ifup
> for the final 'auto' interface is run, but this will instead happen
> during the start of networking.service.
> 
> There's also the existence of an /etc/default.rcS variable,
> ASYNCMOUNTNFS. By default this is unset, corresponding to 'yes'. If set
> to 'no', then NFS mounts are not activated as above; instead they are
> activated by mountnfs.service. This service is masked in the Debian
> systemd package, so I think we can say that ASYNCMOUNTNFS=no is not
> currently supported with our systemd setup.
> 
> Under sysvinit, unmounting at shutdown is handled by
> /etc/init.d/umountnfs.sh, which runs before nfs-common, and then
> rpcbind, are stopped. As noted above, umountnfs.service is not started
> during shutdown under systemd.

This is all a great mess under sysvinit.
umountnfs.service is blacklisted as mounts (also remote ones) are
directly handled by systemd.

> Interfaces can also be configured with NetworkManager, which adds
> another axis to the configuration space. Simple configuration of a wired
> network interface should still work, but I think some work has to be
> done (currently by the admin) to enable
> NetworkManager-wait-online.service in order to get systemd to delay
> activating the NFS mounts until NM determines that a network connection
> is available.
> 
> Incidentally, NetworkManager-wait-online.service looks wrong to me; I
> think it should declare Wants= and Before= on network-online.target,
> since that is the name of the target documented in systemd.special(7);
> however I think that it's not actually broken with its current
> settings--they will just result in network.target itself being delayed
> until NetworkManager-wait-online.service starts up, and since the .mount
> units generated by systemd-fstab-generator are After= both network.target
> and network-online.target, the mounts will still be activated at the
> right time. If NetworkManager-wait-online.service were changed to use
> network-wait-online.target instead, t

Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch

[GCS]

On Tue, Jan 28, 2014 at 2:33 PM, Prach Pongpanich  wrote:
> On Tue, Jan 28, 2014 at 1:30 PM, László Böszörményi (GCS)
>  wrote:
> I've discussed with Markus Hoenicka and he told me about a atoll()
> call which the sqlite3 driver uses to convert raw data into a long
> long number causes problems, he will work on this problem.
>
> drivers/sqlite3/dbd_sqlite3.c:
> 1719:data->d_longlong = (long long) atoll(raw); break; /* hah,
> wonder if that'll work */
 No wonder, as GNU libc manual[1] on parsing integers states:
Function: long long int atoll (const char *string)
"This function is similar to atol, except it returns a long long int.
The atoll function was introduced in ISO C99. It too is obsolete
(despite having just been added); use strtoll instead."
Thus atoll is deprecated in favour of stroll. Hope if it this change
will be made, then the compilation issue will be solved. Prach, if you
have connection with Markus Hoenicka then may you send him the URL
I've mentioned?

Algernon, if I code a small converter, can you test it on Sparc (if
you have any nearby at your workplace)?

Regards,
Laszlo/GCS
[1] http://www.gnu.org/software/libc/manual/html_node/Parsing-of-Integers.html


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

Bug#736939: ITP: vim-fugitive -- A Git wrapper so awesome, it should be illegal

[Dominik George]

>   Description : A Git wrapper so awesome, it should be illegal
> 
>  I'm not going to lie to you; fugitive.vim may very well be the best Git
>  wrapper of all time. Check out these features:

Please keep the package description objective and stick to facts about
the program.

Thanks,
Nik

-- 
* concerning Mozilla code leaking assertion failures to tty without D-BUS *
 That means, D-BUS is a tool that makes software look better
than it actually is.

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296


signature.asc
Description: Digital signature

Bug#727708: call for votes on default Linux init system for jessie

[Bdale Garbee]

Ian Jackson  writes:

> I think it doesn't make sense to allow people to require a non-default
> init.  If you think it does then there are three possible answers to
> Q2: "requiring a specific init is permitted even if it is not the
> default one", "requiring the default init is OK but requiring another
> is not" and "requiring a specific init is not OK".

I prefer Don's approach to thinking about this:

   I still don't think the last sentence of this paragraph completely
   handles the cases where someone can legitimately depend on a specific
   init system or specific init system interface.

   If we're supporting multiple init systems, then software which doesn't
   support multiple init systems which could feasibly do so is buggy. If
   patches to fix it appear and aren't applied, then people can appeal to
   the CTTE. It's not necessary or feasible for us to anticipate every
   single technical wrinkle and delay making a decision to do so.

Thus, I believe the only acceptable option for Q2 from among your set is
"requiring a specific init is permitted even if it is not the default
one".  But I would prefer to vote a ballot that doesn't mention
dependencies at all. 

Bdale


pgpSYduCPd2us.pgp
Description: PGP signature

Bug#735361: [request-tracker-maintainers] Bug#735361: Bug#735361: request-tracker4: FTBFS: GPG test failures

[Kevin Falcone]

On Wed, Jan 15, 2014 at 12:35:44AM +, Dominic Hargreaves wrote:
> On Wed, Jan 15, 2014 at 12:25:23AM +, Dominic Hargreaves wrote:
> > This appears to break the RT tests, which use this parameter:
> 
> Just to be clear: since trust-model=always is only used in the test
> suite, I don't believe this issue affects running installations.

It's also a really common configuration to run in production,
especially if you tell RT to auto-download keys and want it to encrypt
back to randoms who email in, process of:
New ticket from b...@example.com, signed, encrypted to queue key.
RT downloads b...@example.com's key because you have
'auto-key-locate' => 'keyserver',
'keyserver-options' => 'auto-key-retrieve',
set in %GnuPGOptions

When you reply back to the user, you pick the Reply option, if there's
no trust path in the database gpg can kick back a warning/error about
not wanting to encrypt to an untrusted key.
Recipient 'b...@example.com' is unusable, the reason is 'Key not trusted'

For sites that manually keep a tightly controlled keyring, this isn't an
issue. I don't have statistics on how many users run with trust-model =
always but I definitely run into it with clients.

-kevin


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

Bug#736941: libconfig-model-dpkg-perl: `cme fix dpkg-control` is silently removing "Enhances:" field

[Andreas Tille]

Package: libconfig-model-dpkg-perl
Severity: normal

Hi,

after doing a `cme fix dpkg-control` on the package ray I git the
following diff:


Index: control
===
--- control (Revision 15869)
+++ control (Arbeitskopie)
@@ -5,7 +5,7 @@
 Section: science
 Priority: optional
 Build-Depends: debhelper (>= 9)
-Standards-Version: 3.9.4
+Standards-Version: 3.9.5
 Vcs-Browser: 
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/prank/trunk/
 Vcs-Svn: svn://anonscm.debian.org/debian-med/trunk/packages/prank/trunk/
 Homepage: http://code.google.com/p/prank-msa/
@@ -14,7 +14,6 @@
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends}
-Enhances: t-coffee
 Description: Probabilistic Alignment Kit for DNA, codon and amino-acid 
sequences
  PRANK is a probabilistic multiple alignment program for DNA, codon
  and amino-acid sequences. It's based on a novel algorithm that treats



I think the Enhances line should remain.


Kind regards and thanks for providing config-model

  Andreas.


-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.36-xenU-4814-i386 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#736940: mount: typo in man page: "mount device|dir -o "

[Aleksej]

Package: mount
Version: 2.20.1-5.5
Severity: minor

Dear Maintainer,


The man page for mount (man 8 mount) has a typo:

If you want to override mount options from /etc/fstab you have to use:

   mount device|dir -o 

There should be no pipe character:
   mount device dir -o 


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

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common  

-- debconf-show failed


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

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Ian Jackson  writes:

> I think it doesn't make sense to allow people to require a non-default
> init.

I think this position is consistent with allowing each maintainer broad
autonomy, and not overly burdening them with requirements that may make
it difficult or impossible to provide bug fixes and other improvements
From newer upstream versions.

Yes, I'd consider it a bug, but I'm not sure it reaches the level of an
RC bug.

-- 
keith.pack...@intel.com


pgpHYnPhATDnO.pgp
Description: PGP signature

Bug#736939: ITP: vim-fugitive -- A Git wrapper so awesome, it should be illegal

[Andrea Capriotti]

Il giorno mar, 28/01/2014 alle 17.54 +0100, Dominik George ha scritto:
> >   Description : A Git wrapper so awesome, it should be illegal
> > 
> >  I'm not going to lie to you; fugitive.vim may very well be the best Git
> >  wrapper of all time. Check out these features:
> 
> Please keep the package description objective and stick to facts about
> the program.

Hi Nik,

that's the upstream package description:

http://www.vim.org/scripts/script.php?script_id=2975

Should I change it?

Bye
-- 
Andrea Capriotti 


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