Bug#792144: RFS: cunit/2.1-2.dfsg-3 -- Unit Testing Library for C [ITA]

[Gianfranco Costamagna]

Another issue you should address:


I duplicate-long-description
libcunit1-dev libcunit1 libcunit1-ncurses-dev libcunit1-ncurses libcunit1-doc

(you might append something like "this is the development package" "this is the 
common
documentation" or so)

feel free to steal from python-pyqtgraph or boinc packages :)
(the former has a doc package, the latter has many library packages and dev)

you also have this issue:
https://lintian.debian.org/tags/license-problem-gfdl-non-official-text.html


please try to fix it or report upstream if possible!

cheers,

Gianfranco

Bug#798412: [pkg-fgfs-crew] Bug#798412: flightgear: fgfs always segfaults on exit

[Rebecca N. Palmer]

This is probably the bug fixed upstream (from 3.5) by 
http://sourceforge.net/p/flightgear/flightgear/ci/033957003f4be52ea554a4260b70f1f97440dca0/ 
, which occurs after settings are saved and is hence a harmless annoyance.


(Note that 3.5+ also enable the launcher by default, which causes a 
different crash on exit, but that one is also harmless.)

Bug#796030: tablesnap

[Gianfranco Costamagna]

Hi Jeremy,


did you have time to look at my last review?

let me know if you need help

cheers,

G.

Bug#796731: freecontact: FTBFS on mips (test suite failure)

[Aron Xu]

On Wed, Sep 9, 2015 at 3:44 PM, Andreas Tille  wrote:
> Hi mips porters,
>
> could anybody please find a more powerful machine to build the rdepends
> libfreecontact-perl and python-freecontact.
>
> Alternatively I would decide to exclude mips architecture for
> libfreecontact and its Perl and Python interfaces since I see no point
> in delivering a package that does not pass its build time check.
>

Would be nice if you can keep it as-is for a while, new machines are
being purchased with FPU (estimation is probably the end of year?),
that will solve the compilation stuck.

Thanks,
Aron

Bug#788653: RFS: ktap/0.4-1 [ITP] -- lightweight script-based dynamic tracing tool for Linux

[Gianfranco Costamagna]

Hi,


>You are correct, I've put debian/ktap.manpages statically.


wonderful

>s/dh_installmanpages/dh_installman/


yes, sure

maybe something like
override_dh_installman:

help2man --no-discard-stderr -h-h --version-string $(VERSION) -n 
"$(DESCRIPTION)" ./ktap > debian/ktap.1

dh_installman

the same for doc and examples.


>So, is there anything that I need/can to do to ship it to debian

>repository?

sure, the package is almost ready, just the tweaks above, and to make it build 
on a clean environment.
http://debomatic-amd64.debian.net/distribution#unstable/ktap/0.4-1/buildlog

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

cheers,

G.

P.S. you have some build warnings:
CC [M] ktap-0.4/runtime/amalg.o
In file included from ktap-0.4/runtime/amalg.c:28:0:
ktap-0.4/runtime/kp_transport.c: In function ‘kp_printf’:
ktap-0.4/runtime/kp_transport.c:574:1: warning: the frame size of 1056 bytes is 
larger than 1024 bytes [-Wframe-larger-than=]
}
^


userspace/kp_reader.c: In function ‘reader_thread’:
userspace/kp_reader.c:87:3: warning: ignoring return value of ‘write’, declared 
with attribute warn_unused_result [-Wunused-result]
write(out_fd, buf, len);
^

you might want to fix them too :)

Bug#796118: Should djbdns be removed?

[Gerrit Pape]

reassign 796118 djbdns
retitle 796118 Should djbdns be removed?
quit

On Tue, Sep 08, 2015 at 08:29:18PM +0200, Moritz Mühlenhoff wrote:
> On Wed, Aug 19, 2015 at 05:45:30PM +0200, Moritz Muehlenhoff wrote:
> > djbdns is RC-buggy for many years now and was out of testing since 2009.
> > Should we remove it from unstable?

No, I don't think so.

Bug#792144: RFS: cunit/2.1-2.dfsg-3 -- Unit Testing Library for C [ITA]

[a3at.m...@gmail.com]

On Wed, Sep 09, 2015 at 06:30:27AM +, Gianfranco Costamagna wrote:
> Another issue you should address:
> 
> 
> I duplicate-long-description
> libcunit1-dev libcunit1 libcunit1-ncurses-dev libcunit1-ncurses libcunit1-doc
> 
> (you might append something like "this is the development package" "this is 
> the common
> documentation" or so)
> 
> feel free to steal from python-pyqtgraph or boinc packages :)
> (the former has a doc package, the latter has many library packages and dev)

Hm, I saw this, but I thought that if title (the first line of
description) is differs it is okay, but sure I can add few words at the
end of description.

> you also have this issue:
> https://lintian.debian.org/tags/license-problem-gfdl-non-official-text.html
> 
> 
> please try to fix it or report upstream if possible!

Fixed, no need in report upstream since this was in debian/copyright,
and I get this text here:
https://sources.debian.net/src/speech-dispatcher/0.8-7/debian/copyright/?hl=113#L113
(as Riley Baird suggested)

Bug#798341: [inkscape] impossible to install inkscape

[Marco Righi]

/etc/apt/sources.list contains:

#

# deb cdrom:[Debian GNU/Linux testing _Jessie_ - Official Snapshot
amd64 CD Binary-1 20140707-06:24]/ jessie main

# deb cdrom:[Debian GNU/Linux testing _Jessie_ - Official Snapshot
amd64 CD Binary-1 20140707-06:24]/ jessie main

deb http://ftp.it.debian.org/debian/ jessie main
deb-src http://ftp.it.debian.org/debian/ jessie main

deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

# jessie-updates, previously known as 'volatile'
deb http://ftp.it.debian.org/debian/ jessie-updates main
deb-src http://ftp.it.debian.org/debian/ jessie-updates main

# jessie-backports, previously on backports.debian.org
deb http://ftp.it.debian.org/debian/ jessie-backports main
deb-src http://ftp.it.debian.org/debian/ jessie-backports main

/etc/apt/sources.list.d/contains:


#

deb http://ftp.fr.debian.org/debian/ testing main non-free contrib
deb-src http://ftp.fr.debian.org/debian/ testing main non-free contrib

deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free

# jessie-updates, previously known as 'volatile'
deb http://ftp.fr.debian.org/debian/ testing-updates main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ testing-updates main contrib
non-free

Date:mer set 09 Time:09:47:32
User:root Computer:pc-thesaurus1 Base:sources.list.d
Current:/etc/apt/sources.list.d
Command 83 of 18 #LC_ALL=C.UTF-8 apt-get update
Ign http://ftp.it.debian.org jessie InRelease
Hit http://ftp.it.debian.org jessie-updates InRelease
Hit http://security.debian.org jessie/updates InRelease
Hit http://ftp.fr.debian.org testing InRelease
Hit http://ftp.it.debian.org jessie-backports InRelease

Hit http://security.debian.org testing/updates InRelease

Hit http://ftp.it.debian.org jessie Release.gpg

Hit http://ftp.fr.debian.org testing-updates InRelease
Hit http://ftp.it.debian.org jessie-updates/main Sources
Hit http://security.debian.org jessie/updates/main Sources
Get:1 http://ftp.it.debian.org jessie-updates/main amd64
Packages/DiffIndex [643 B]
Get:2 http://ftp.it.debian.org jessie-updates/main i386
Packages/DiffIndex [643 B]
Hit http://security.debian.org jessie/updates/main amd64 Packages

Get:3 http://ftp.it.debian.org jessie-updates/main
Translation-en/DiffIndex [229 B]
Get:4 http://ftp.fr.debian.org testing/main Sources/DiffIndex [7876 B]

Hit http://security.debian.org jessie/updates/main i386 Packages

Hit http://ftp.it.debian.org jessie Release

Get:5 http://ftp.it.debian.org jessie-backports/main Sources/DiffIndex
[7819 B]
Get:6 http://ftp.it.debian.org jessie-backports/main amd64
Packages/DiffIndex [7819 B]
Get:7 http://ftp.it.debian.org jessie-backports/main i386
Packages/DiffIndex [7819 B]
Get:8 http://ftp.it.debian.org jessie-backports/main
Translation-en/DiffIndex [6577 B]
Hit http://security.debian.org jessie/updates/main Translation-en
Hit http://security.debian.org testing/updates/main Sources
Hit http://security.debian.org testing/updates/contrib Sources
Hit http://security.debian.org testing/updates/non-free Sources
Hit http://security.debian.org testing/updates/main amd64 Packages
Hit http://security.debian.org testing/updates/contrib amd64 Packages
Hit http://security.debian.org testing/updates/non-free amd64 Packages
Hit http://security.debian.org testing/updates/main i386 Packages
Hit http://security.debian.org testing/updates/contrib i386 Packages
Hit http://security.debian.org testing/updates/non-free i386 Packages
Hit http://security.debian.org testing/updates/contrib Translation-en

Hit http://ftp.it.debian.org jessie/main Sources

Hit http://ftp.it.debian.org jessie/main amd64 Packages

Get:9 http://ftp.fr.debian.org testing/non-free Sources/DiffIndex
[7819 B]
Hit http://security.debian.org testing/updates/main Translation-en

Hit http://ftp.it.debian.org jessie/main i386 Packages

Hit http://security.debian.org testing/updates/non-free Translation-en

Hit http://ftp.it.debian.org jessie/main Translation-en

Hit http://ftp.it.debian.org jessie/main Translation-it
Get:10 http://ftp.fr.debian.org testing/contrib Sources/DiffIndex [7405 B]
Hit http://ftp.it.debian.org jessie-backports/main i386 Packages

Get:11 http://ftp.fr.debian.org testing/main amd64 Packages/DiffIndex
[7876 B]
Get:12 http://ftp.fr.debian.org testing/non-free amd64
Packages/DiffIndex [7819 B]
Get:13 http://ftp.fr.debian.org testing/contrib amd64
Packages/DiffIndex [7819 B]
Get:14 http://ftp.fr.debian.org testing/main i386 Packages/DiffIndex
[7876 B]
Get:15 http://ftp.fr.debian.org testing/non-free i386
Packages/DiffIndex [7819 B]
Get:16 http://ftp.fr.debian.org testing/contrib i386
Packages/DiffIndex [7819 B]
Get:17 http://ftp.fr.debian.org testing/contrib
Translation-en/DiffIndex [4783 B]
Get:18 http://ftp.fr.debian.org testing/main Translation-en/DiffIndex
[7876 B]
Get:19 http://ftp.fr.debian.org testing/non-free
Translation-en/DiffIndex [6163 B]
Hit 

Bug#798261: [Pkg-fonts-devel] Bug#798261: ITP: fonts-roboto-fontface -- largely geometric, friendly and open curves font

[Jonas Smedegaard]

Quoting Thomas Goirand (2015-09-09 09:20:51)
> On 09/08/2015 10:11 AM, Jonas Smedegaard wrote:
>> Quoting Thomas Goirand (2015-09-08 09:28:15)
>>> On 09/07/2015 08:42 PM, Jonas Smedegaard wrote:
> If you wish to drop the generation of fonts-roboto from the 
> fonts-android package, then good.

 I think the better approach is to keep the fonts-roboto package, have 
 your package exclude fonts, depend on the fonts-roboto package, and 
 symlink font files from there as needed.
>>>
>>> I don't think so. The fonts-roboto package currently only provides 
>>> .tff files, which are useless for the web. The sources aren't the 
>>> same.
>> 
>> What are the sources, then?
>
> git://github.com/choffmeister/roboto-fontface-bower.git

I do understand that above is the URL you intend to fetch the project 
from.  What I meant by my question is what is the source of the material 
you are fetching?  What is the source of WOFF and SVG files?

Or do you mean to tell me that WOFF and SVG files are _forks_ of the TTF 
files, developed independently onwards?  I find that highly unlikely.


> Do you think I should join the pkg-fonts group to maintain these 
> fonts under the group?

 We can always use more helping hands in the fonts team :-)

 But if your focus is on OpenStack then perhaps just coordinate with 
 the font team on tuning the fonts-roboto package to provide what is 
 needed for reuse with OpenStack - i.e. those web representations of 
 the font (CSS/Sass/Less sounds like OpenStack-specific glue so 
 probably makes best sense to package separately).
>>>
>>> They aren't OpenStack specific, it's just modern Javascript stuff, 
>>> which can be reused by any project.
>> 
>> Great - then suggest maintainers of the existing package to adopt 
>> those tiny files too.
>
> Well, we just talked about dropping the generation of fonts-roboto 
> from the old source package... Or am I missing something?

Yes, that is a suggestion you brought up, but which it seems neither 
Vasudev nor me agree with.

Looking at recent posts from Paul Wise on the fonts team list, it seems 
he also do not agree with packaging fonts known to have their actual 
source - even if our tools to rebuild from that canonical source is 
currently lacking in Debian.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#798341: [inkscape] impossible to install inkscape

[Debian/GNU]

On 2015-09-09 09:52, Marco Righi wrote:
[...]
>  inkscape : Depends: libatkmm-1.6-1 (>= 2.22.1) but it is not going to
> be installed

in the past few weeks, Debian has seen a major transition (of the core
components for any C++-related software in Debian) that affected *many*
packages and included the renaming of some dependencies of inkscape.
only within the last days, this big change started migrating from
"unstable" to "testing".

this basically means big disruption which should eventually go away
"automatically", once all packages have been transitioned from unstable
to testing.

in the meantime you could try using a better dependency resolver, e.g.
by intalling the packages with aptitude:

# aptitude udpate
# LC_ALL=C.UTF-8 aptitude install inkscape


i also see that you are running a mixed jessie/stretch (aka
"stable/testing") system, which i don't think is supported at all (i
think that one of the reasons for this is exactly because it is
impossible to support working systems that depend on a state both
*before* and *after* such big transitions we are currently seeing).

fgmasdr
IOhannes

Bug#752783: [pkg-uWSGI-devel] Bug#752783: libapache2-mod-proxy-uwsgi still not working properly

[Jonas Smedegaard]

Hi Attila-Mihaly,

Quoting Attila-Mihaly Balazs (2015-09-09 10:29:18)
> - If I specify "ProxyPass unix:/run/uwsgi/app/site/socket|uwsgi://" 
> [...] I will get "error parsing URL //: Invalid host/port"

Which Debian package release of uWSGI do you use?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#798283: clvmd: stack smashing detected -- solved

[Adi Kriegisch]

Tags: patch
Severity: important

Hey!

I finally found the source of the problem: During cluster initialization an
int is casted to a uint64_t which triggered the stack protection in gcc-4.9:
  | int select_fd;
  | (...)
  | saLckSelectionObjectGet(lck_handle, (SaSelectionObjectT *)_fd);

I fixed the issue by declaring select_fd as uint64_t, as SaSelectionObjectT
defined in /usr/include/openais/saAis.h is:
  | typedef uint64_t SaUint64T;
  | typedef SaUint64T SaSelectionObjectT;

To make the issue more explicit I casted it back to an int. Patch is
attached.

-- Adi

PS: What I do not understand is why gcc-4.9 does not raise this issue at
compile time: all type information is already there...
--- a/daemons/clvmd/clvmd-openais.c	2015-09-09 08:15:24.036478491 +
+++ b/daemons/clvmd/clvmd-openais.c	2015-09-09 08:15:56.609011149 +
@@ -309,7 +309,7 @@
 {
 	SaAisErrorT err;
 	SaVersionT  ver = { 'B', 1, 1 };
-	int select_fd;
+	uint64_t select_fd;
 
 	node_hash = dm_hash_create(100);
 	lock_hash = dm_hash_create(10);
@@ -357,7 +357,7 @@
 	DEBUGLOG("Our local node id is %d\n", our_nodeid);
 
 	saLckSelectionObjectGet(lck_handle, (SaSelectionObjectT *)_fd);
-	add_internal_client(select_fd, lck_dispatch);
+	add_internal_client((int)select_fd, lck_dispatch);
 
 	DEBUGLOG("Connected to OpenAIS\n");
 


signature.asc
Description: Digital signature

Bug#798373: netcfg: Change default wireless networking type from WEP to WPA

[Chris Lamb]

Hey,

> However, Default: should match the choice you want, but in Choices-C,
> therefore it should be "wpa" alone.

Thanks :)

So, I was curious about Choices-C but the only documentation I could
easily find about it was in debconf-devel(7) which states that if
DEBCONF_C_VALUES is set, the frontend will display  the values from this
field. Whilst I've got your attention - what's the purpose of it?

Updated patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/netcfg-common.templates b/debian/netcfg-common.templates
index 4525305..2b77936 100644
--- a/debian/netcfg-common.templates
+++ b/debian/netcfg-common.templates
@@ -65,6 +65,7 @@ _Description: Wireless ESSID for ${iface}:
 
 Template: netcfg/wireless_security_type
 Type: select
+Default: wpa
 Choices-C: wep/open, wpa
 __Choices: WEP/Open Network, WPA/WPA2 PSK
 # :sl2:

Bug#797866: libtorrent: ABI transition needed for libstdc++ v5

[Simon McVittie]

On 09/09/15 07:00, Jose-Luis Rivas wrote:
> On 08/09/15, 10:24pm, Jose-Luis Rivas wrote:
>> Just to be clear, if I rebuild this with the source packages from
>> unstable with a new upstream version the rename is not necessary?
>
> Nevermind, upstream bumped soname anyway.

A new upstream SONAME makes the v5 transition rename unnecessary; but if
upstream have bumped SONAME, then they've broken API/ABI (or are doing
it wrong), which increases the risk that reverse-dependencies of
libtorrent will fail to compile or fail to work.

A new upstream release that does not bump the SONAME does not have any
effect on the need for a transition/rename.

I suspect that the lowest-risk approach to getting this transition
finished in a finite time is to do the v5 rename, then ask the release
team for a separate transition slot for the new upstream SONAME.

S

Bug#787148: gambatte ping

[Gianfranco Costamagna]

Hi Sergio, did you had time to look at the gambatte review?

cheers,

G.

Bug#792144: RFS: cunit/2.1-2.dfsg-3 -- Unit Testing Library for C [ITA]

[a3at.m...@gmail.com]

On Wed, Sep 09, 2015 at 06:26:03AM +, Gianfranco Costamagna wrote:
> (please also address issues from other emails)

I look through emails again, and couldn't find any non addressed issues,
could please duplicate it?

> http://mentors.debian.net/debian/pool/main/c/cunit/cunit_2.1-3-dfsg1.dsc 
> 
> 
> quoting changelog:
> 
> +  * Bump to 2.1-3
> +  * Fix versions
> 
> I see two patches dropped
> and the watch file updated (diff between this version and your previous one, 
> not complete
> diff between the version in unstable and this one)
> 
> please mention changes in changelog.

Updated and uploaded to mentors (with addressed previous two issues:
gfdl and duplicated descriptions).

Bug#747094: Updated Patch

[Stefano Zacchiroli]

On Wed, Sep 09, 2015 at 10:56:21AM +0200, Stefano Zacchiroli wrote:
> Thanks for your patch! I've now rebuilt a local bash-completion that
> uses it, and it's just great.

BTW, why is this patch number 14 in the series rather than 13?

I thought that was because another patch numbered 13 was in the series
on the Ubuntu side, but according to
https://patches.ubuntu.com/b/bash-completion/bash-completion_1:2.1-4.1ubuntu2.patch
that doesn't seem to be the case.

Not that I care *that* much :), I'm just trying to figure out whether
some other patches from Ubuntu should be integrated or not.

TIA,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#762804: yapps: please add python3 support

[Julien Cristau]

Control: tag -1 patch

On Thu, Sep 25, 2014 at 12:17:33 +0200, Julien Cristau wrote:

> Source: yapps2
> Version: 2.1.1-17.2
> Severity: wishlist
> 
> Hi,
> 
> upstream yapps (2.2.0) supports python3, it'd be nice to get a
> python3-yapps package in Debian.
> 
Here's a patch for the debian package, based on the 2.2.0 upstream
version, adding a python3 package and reworking the packaging to more
modern style.

Cheers,
Julien

diff --git a/debian/changelog b/debian/changelog
index 97e3334..d99aca9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+yapps2 (2.2.0-0.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+  * Build for python3 (closes: #762804), switching debian/rules to dh with the
+pybuild build system.
+  * Bump Standards-Version to 3.9.6.
+
+ -- Julien Cristau   Wed, 09 Sep 2015 10:30:57 +0200
+
 yapps2 (2.1.1-17.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/clean b/debian/clean
new file mode 100644
index 000..5f9a740
--- /dev/null
+++ b/debian/clean
@@ -0,0 +1,3 @@
+doc/yapps2.haux
+doc/yapps2.html
+doc/yapps2.htoc
diff --git a/debian/compat b/debian/compat
index b8626c4..ec63514 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-4
+9
diff --git a/debian/control b/debian/control
index 3713aaa..6c04beb 100644
--- a/debian/control
+++ b/debian/control
@@ -2,13 +2,23 @@ Source: yapps2
 Section: python
 Priority: optional
 Maintainer: Matthias Urlichs 
-Build-Depends: debhelper (>= 4.1)
-Build-Depends-Indep: python-dev (>= 2.5.4-1~), hevea, dh-python
-Standards-Version: 3.7.2
+Build-Depends:
+ debhelper (>= 9),
+ python-all (>= 2.6.5),
+ python3-all,
+ dh-python,
+Build-Depends-Indep:
+ hevea,
+Standards-Version: 3.9.6
+X-Python-Version: >= 2.6
+X-Python3-Version: >= 3.3
 
 Package: yapps2
 Architecture: all
-Depends: ${python:Depends}, yapps2-runtime (= ${Source-Version})
+Depends:
+ ${python3:Depends},
+ ${misc:Depends},
+ python3-yapps2-runtime (= ${source:Version}),
 Description: Yet Another Python Parser System
  YAPPS is an easy to use parser generator that is written in Python and
  generates Python code.  There are several parser generator systems
@@ -29,13 +39,28 @@ Description: Yet Another Python Parser System
 
 Package: yapps2-runtime
 Architecture: all
-Depends: ${python:Depends}
-Description: Yet Another Python Parser System
+Depends:
+ ${python:Depends},
+ ${misc:Depends},
+Description: Yet Another Python Parser System - Python 2 runtime
  YAPPS is an easy to use parser generator that is written in Python and
  generates Python code.  There are several parser generator systems
  already available for Python, but this parser has different goals:
  Yapps is simple, very easy to use, and produces human-readable parsers.
  .
- This package contains the Python runtime support for parsers generated
+ This package contains the Python 2 runtime support for parsers generated
  with yapps2.
 
+Package: python3-yapps2-runtime
+Architecture: all
+Depends:
+ ${python3:Depends},
+ ${misc:Depends},
+Description: Yet Another Python Parser System - Python 3 runtime
+ YAPPS is an easy to use parser generator that is written in Python and
+ generates Python code.  There are several parser generator systems
+ already available for Python, but this parser has different goals:
+ Yapps is simple, very easy to use, and produces human-readable parsers.
+ .
+ This package contains the Python 3 runtime support for parsers generated
+ with yapps2.
diff --git a/debian/python3-yapps2-runtime.install 
b/debian/python3-yapps2-runtime.install
new file mode 100644
index 000..d7180cc
--- /dev/null
+++ b/debian/python3-yapps2-runtime.install
@@ -0,0 +1,3 @@
+usr/lib/python3*/*-packages/yapps/__init__.py
+usr/lib/python3*/*-packages/yapps/runtime.py
+usr/lib/python3*/*-packages/*.egg-info
diff --git a/debian/pyversions b/debian/pyversions
deleted file mode 100644
index 9091367..000
--- a/debian/pyversions
+++ /dev/null
@@ -1 +0,0 @@
-2.2-
diff --git a/debian/rules b/debian/rules
index e5c895e..7abea4f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,95 +6,14 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-include /usr/share/python/python.mk
+%:
+   dh $@ --with python2,python3 --buildsystem=pybuild
 
-PWD=$(shell pwd)
-PYVER=$(shell pyversions -d)
-
-CFLAGS = -Wall -g
-
-ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
-   CFLAGS += -O0
-else
-   CFLAGS += -O2
-endif
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   INSTALL_PROGRAM += -s
-endif
-
-configure: configure-stamp
-configure-stamp:
-   dh_testdir
-   # Add here commands to configure the package.
-
-   touch configure-stamp
-
-
-build: build-stamp
-
-build-stamp: configure-stamp 
-   dh_testdir
-
-   # Add here commands to compile the package.
-   python setup.py build
-   #/usr/bin/docbook-to-man debian/yapps2.sgml > yapps.1
-

Bug#792144: RFS: cunit/2.1-2.dfsg-3 -- Unit Testing Library for C [ITA]

[Gianfranco Costamagna]

Hi, I'm referring to:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792144#54


and (sorry for that I forgot to send the mail)
to the need to mark the package as multiarch where needed
https://wiki.debian.org/Multiarch/Implementation


also, please rebase the changelog into one entry.
(I mean, there is no need to have
+cunit (2.1-3-dfsg1) unstable; urgency=medium

+cunit (2.1-2.dfsg-3) unstable; urgency=medium


the first one is enough, since the second never appeared on Debian.

cheers,

G.

Bug#792144: RFS: cunit/2.1-2.dfsg-3 -- Unit Testing Library for C [ITA]

[Gianfranco Costamagna]

(please also address issues from other emails)

http://mentors.debian.net/debian/pool/main/c/cunit/cunit_2.1-3-dfsg1.dsc 


quoting changelog:

+  * Bump to 2.1-3
+  * Fix versions

I see two patches dropped
and the watch file updated (diff between this version and your previous one, 
not complete
diff between the version in unstable and this one)

please mention changes in changelog.

cheers,

G.

Bug#786795: dhcp-probe review

[Gianfranco Costamagna]

Hi Laurent, I'm pinging you because I think you missed my review on #786795

Let me know if you intend to address the issue I raised here :)


cheers,


G.

Bug#752783: libapache2-mod-proxy-uwsgi still not working properly

[Attila-Mihaly Balazs]

Problems:

- If I specify "ProxyPass unix:/run/uwsgi/app/site/socket|uwsgi://" (this
is inside of a location block, so need for the initial path) I will get
"error parsing URL //: Invalid host/port" in the apache logs when I try to
access that URL. If I try to change the final part (ie. "|uwsgi://" to
"|uwsgi://localhost/"), it just tries to connect through TCP. I would
really prefer unix sockets to TCP since they can be secured better.

- I tried to change over to TCP, however it seems that mod_proxy_uwsgi
doesn't parse the port number from the URL. Ie. even if I specify
"ProxyPass uwsgi://127.1.0.1:3001/", it will try to connect on port 3031
which seems to be the default port [1]. A quick glance at the code seems to
indicate that that ie *does* parse the port part [2], so I'm not sure what
goes wrong there. Using multiple ports would be essential (or getting unix
sockets working) since I want to run multiple apps / domains on the server
with uwsgi (I also tried putting the proxy pass outside of the Location
block and adding the path as shown in the documentation - ie. "ProxyPass /
uwsgi://127.1.0.1:3032/") but it still doesn't seem to parse the port
number and uses the default port.

Regards,

Attila Balazs (Grey Panther)


[1] https://github.com/unbit/uwsgi/blob/master/apache2/mod_proxy_uwsgi.c#L54
[2] https://github.com/unbit/uwsgi/blob/master/apache2/mod_proxy_uwsgi.c#L75

Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default

[Roberto C . Sánchez]

Of course.  The upload is meant for experimental like -3.  Correct?

Regards,

-Roberto

On Wed, Sep 09, 2015 at 09:33:03AM +0100, Daniel Glassey wrote:
> On Wed, Sep 09, 2015 at 04:08:25AM -0400, Roberto C. Sánchez wrote:
> > Do you want me to go ahead with uploading -3 as is then?
> 
> No need, could you just git-buildpackage build and tag -4 ?
> 
> Thanks,
> Daniel
> 

-- 
Roberto C. Sánchez


signature.asc
Description: Digital signature

Bug#798427: jessie-backports FTBFS: missing build-dep on bison

[Daniel Baumann]

Package: octave
Version: 4.0.0-4
Severity: minor

Hi,

when building octave from sid in a jessie chroot in order to do a
jessie-backport, octave FTBFS within configure that bison is not installed.

Would you mind adding a direct build-depends on bison to ease backports?
 Since octave doesn't FTBFS on sid, i presume that bison is pulled
indirectly, so a direct build-depends wouldn't hurt either.

Regards,
Daniel

Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default

[Roberto C . Sánchez]

Do you want me to go ahead with uploading -3 as is then?

Regards,

-Roberto

On Wed, Sep 09, 2015 at 07:48:32AM +0100, Daniel Glassey wrote:
> On Tue, Sep 08, 2015 at 09:35:14PM -0400, Roberto C. Sánchez wrote:
> > Daniel,
> > 
> > I just built this and was going to upload for you, but I noticed that
> > lintian complained of two errors:
> > 
> > E: sword source: license-problem-undefined-license unknown (paragraph at 
> > line 25)
> > E: libsword-dev: pkg-config-multi-arch-wrong-dir usr/lib/pkgconfig/sword.pc 
> > full text contains architecture specific dir x86_64-linux-gnu
> > 
> > I don't have time to dig into the lintian errors tonight, but I may be
> > able to in the next day or so.
> > 
> > Also, if you could push the tags for the various 1.7.3 versions that
> > would be helpful.  I was going to check out on the debian/1.7.3+dfsg-3
> > and build from Git, but there was no tag, so I did an 'apt-get source'
> > and applied the patch you attached to the bug instead.
> 
> Ah, indeed, I forgot to tag 1.7.3+dfsg-3.
> 
> The fixes for lintian inc enabling multiarch are all in git in 1.7.3+dfsg-4 
> ready to be tagged and released.
> I only did the 1.7.3+dfsg-3 to keep the patch simple for transition team to 
> apply if necessary.
> 
> Thanks :)
> Daniel
> 
> > On Mon, Sep 07, 2015 at 11:55:36AM +0100, Daniel Glassey wrote:
> > > user release.debian@packages.debian.org
> > > usertag 796711 + transition
> > > usertag 796711 + patch
> > > block 796711 by 790756
> > > reassign 796711 release.debian.org
> > > thanks
> > > 
> > > patch attached for the transition.
> > > 
> > > I need to wait for a keyring update before I can upload myself.
> > > 
> > > Thanks,
> > > Daniel
> > 
> > > diff --git a/debian/changelog b/debian/changelog
> > > index b62945f..7fa2648 100644
> > > --- a/debian/changelog
> > > +++ b/debian/changelog
> > > @@ -1,3 +1,13 @@
> > > +sword (1.7.3+dfsg-3) unstable; urgency=low
> > > +
> > > +  * c++ transition
> > > +  rename library to libsword11v5
> > > +  blocked by ICU c++ transition
> > > +  * add patch abicompare.patch to allow libsword to work with 
> > > +  abi-compliance-checker for future transitions
> > > +
> > > + -- Daniel Glassey   Wed, 02 Sep 2015 14:15:09 +0100
> > > +
> > >  sword (1.7.3+dfsg-2.1) unstable; urgency=medium
> > >  
> > >* Non maintainer upload.
> > > diff --git a/debian/control b/debian/control
> > > index 53dbebe..9f59bf3 100644
> > > --- a/debian/control
> > > +++ b/debian/control
> > > @@ -17,7 +17,7 @@ Uploaders: Daniel Glassey ,
> > >  Standards-Version: 3.9.3
> > >  Homepage: http://www.crosswire.org/sword/
> > >  
> > > -Package: libsword11
> > > +Package: libsword11v5
> > >  Architecture: any
> > >  Depends: libsword-common, ${shlibs:Depends}, ${misc:Depends}
> > >  Recommends: sword-frontend
> > > @@ -36,7 +36,7 @@ Description: API/library for bible software
> > >  Package: libsword-dev
> > >  Architecture: any
> > >  Section: libdevel
> > > -Depends: libsword11 (= ${binary:Version}), ${misc:Depends}
> > > +Depends: libsword11v5 (= ${binary:Version}), ${misc:Depends}
> > >  Recommends: libsword-utils
> > >  Description: Development files for libsword
> > >   The SWORD Project is an open source, cross-platform (Linux, Windows, 
> > > Solaris,
> > > @@ -80,7 +80,7 @@ Package: libsword-dbg
> > >  Architecture: any
> > >  Section: debug
> > >  Priority: extra
> > > -Depends: libsword11 (= ${binary:Version}), ${misc:Depends}
> > > +Depends: libsword11v5 (= ${binary:Version}), ${misc:Depends}
> > >  Description: API/library for bible software - Debug Files
> > >   The SWORD Project is an open source, cross-platform (Linux, Windows, 
> > > Solaris,
> > >   MacOSX etc.) API/library for Bible software with a constantly growing 
> > > list 
> > > diff --git a/debian/libsword11.docs b/debian/libsword11.docs
> > > deleted file mode 100644
> > > index 546a37e..000
> > > --- a/debian/libsword11.docs
> > > +++ /dev/null
> > > @@ -1 +0,0 @@
> > > -doc/translation-template.conf
> > > diff --git a/debian/libsword11.install b/debian/libsword11.install
> > > deleted file mode 100644
> > > index 79e4168..000
> > > --- a/debian/libsword11.install
> > > +++ /dev/null
> > > @@ -1 +0,0 @@
> > > -usr/lib/libsword.so.11
> > > diff --git a/debian/libsword11v5.docs b/debian/libsword11v5.docs
> > > new file mode 100644
> > > index 000..546a37e
> > > --- /dev/null
> > > +++ b/debian/libsword11v5.docs
> > > @@ -0,0 +1 @@
> > > +doc/translation-template.conf
> > > diff --git a/debian/libsword11v5.install b/debian/libsword11v5.install
> > > new file mode 100644
> > > index 000..79e4168
> > > --- /dev/null
> > > +++ b/debian/libsword11v5.install
> > > @@ -0,0 +1 @@
> > > +usr/lib/libsword.so.11
> > > diff --git a/debian/patches/abicompare.patch 
> > > b/debian/patches/abicompare.patch
> > > new file mode 100644
> > > index 000..cdf3109
> > > --- /dev/null
> > > +++ b/debian/patches/abicompare.patch
> > > @@ -0,0 

Bug#798428: new upstream (1.2.4)

[Daniel Baumann]

Package: octave-statistics
Severity: wishlist

Hi,

it would be nice if you could upgrade to the current upstream version
(1.2.4).

Regards,
Daniel

Bug#798413: ftp.debian.org: Source-only uploads which FTBFS on Arch: all buildd require NEW processing in next upload

[Santiago Vila]

On Wed, 9 Sep 2015, Ansgar Burchardt wrote:
> Santiago Vila  writes:
> > When a source-only upload fails to build from source in the
> > "Arch: all" autobuilder [1], the system seems to think that the source
> > does no longer provide such Arch: all packages.
> 
> The cruft report does think so after some time (meh, heuristics are bad)
> and packages are then removed by the ftp team after some time.

In this case, "after some time" seems to be less than 24 hours (!).

That's completely insane for both the person having to fix the FTBFS
bug and for the ftpmasters who have to process NEW again.

Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default

[Daniel Glassey]

On Tue, Sep 08, 2015 at 09:35:14PM -0400, Roberto C. Sánchez wrote:
> Daniel,
> 
> I just built this and was going to upload for you, but I noticed that
> lintian complained of two errors:
> 
> E: sword source: license-problem-undefined-license unknown (paragraph at line 
> 25)
> E: libsword-dev: pkg-config-multi-arch-wrong-dir usr/lib/pkgconfig/sword.pc 
> full text contains architecture specific dir x86_64-linux-gnu
> 
> I don't have time to dig into the lintian errors tonight, but I may be
> able to in the next day or so.
> 
> Also, if you could push the tags for the various 1.7.3 versions that
> would be helpful.  I was going to check out on the debian/1.7.3+dfsg-3
> and build from Git, but there was no tag, so I did an 'apt-get source'
> and applied the patch you attached to the bug instead.

Ah, indeed, I forgot to tag 1.7.3+dfsg-3.

The fixes for lintian inc enabling multiarch are all in git in 1.7.3+dfsg-4 
ready to be tagged and released.
I only did the 1.7.3+dfsg-3 to keep the patch simple for transition team to 
apply if necessary.

Thanks :)
Daniel

> On Mon, Sep 07, 2015 at 11:55:36AM +0100, Daniel Glassey wrote:
> > user release.debian@packages.debian.org
> > usertag 796711 + transition
> > usertag 796711 + patch
> > block 796711 by 790756
> > reassign 796711 release.debian.org
> > thanks
> > 
> > patch attached for the transition.
> > 
> > I need to wait for a keyring update before I can upload myself.
> > 
> > Thanks,
> > Daniel
> 
> > diff --git a/debian/changelog b/debian/changelog
> > index b62945f..7fa2648 100644
> > --- a/debian/changelog
> > +++ b/debian/changelog
> > @@ -1,3 +1,13 @@
> > +sword (1.7.3+dfsg-3) unstable; urgency=low
> > +
> > +  * c++ transition
> > +  rename library to libsword11v5
> > +  blocked by ICU c++ transition
> > +  * add patch abicompare.patch to allow libsword to work with 
> > +  abi-compliance-checker for future transitions
> > +
> > + -- Daniel Glassey   Wed, 02 Sep 2015 14:15:09 +0100
> > +
> >  sword (1.7.3+dfsg-2.1) unstable; urgency=medium
> >  
> >* Non maintainer upload.
> > diff --git a/debian/control b/debian/control
> > index 53dbebe..9f59bf3 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -17,7 +17,7 @@ Uploaders: Daniel Glassey ,
> >  Standards-Version: 3.9.3
> >  Homepage: http://www.crosswire.org/sword/
> >  
> > -Package: libsword11
> > +Package: libsword11v5
> >  Architecture: any
> >  Depends: libsword-common, ${shlibs:Depends}, ${misc:Depends}
> >  Recommends: sword-frontend
> > @@ -36,7 +36,7 @@ Description: API/library for bible software
> >  Package: libsword-dev
> >  Architecture: any
> >  Section: libdevel
> > -Depends: libsword11 (= ${binary:Version}), ${misc:Depends}
> > +Depends: libsword11v5 (= ${binary:Version}), ${misc:Depends}
> >  Recommends: libsword-utils
> >  Description: Development files for libsword
> >   The SWORD Project is an open source, cross-platform (Linux, Windows, 
> > Solaris,
> > @@ -80,7 +80,7 @@ Package: libsword-dbg
> >  Architecture: any
> >  Section: debug
> >  Priority: extra
> > -Depends: libsword11 (= ${binary:Version}), ${misc:Depends}
> > +Depends: libsword11v5 (= ${binary:Version}), ${misc:Depends}
> >  Description: API/library for bible software - Debug Files
> >   The SWORD Project is an open source, cross-platform (Linux, Windows, 
> > Solaris,
> >   MacOSX etc.) API/library for Bible software with a constantly growing 
> > list 
> > diff --git a/debian/libsword11.docs b/debian/libsword11.docs
> > deleted file mode 100644
> > index 546a37e..000
> > --- a/debian/libsword11.docs
> > +++ /dev/null
> > @@ -1 +0,0 @@
> > -doc/translation-template.conf
> > diff --git a/debian/libsword11.install b/debian/libsword11.install
> > deleted file mode 100644
> > index 79e4168..000
> > --- a/debian/libsword11.install
> > +++ /dev/null
> > @@ -1 +0,0 @@
> > -usr/lib/libsword.so.11
> > diff --git a/debian/libsword11v5.docs b/debian/libsword11v5.docs
> > new file mode 100644
> > index 000..546a37e
> > --- /dev/null
> > +++ b/debian/libsword11v5.docs
> > @@ -0,0 +1 @@
> > +doc/translation-template.conf
> > diff --git a/debian/libsword11v5.install b/debian/libsword11v5.install
> > new file mode 100644
> > index 000..79e4168
> > --- /dev/null
> > +++ b/debian/libsword11v5.install
> > @@ -0,0 +1 @@
> > +usr/lib/libsword.so.11
> > diff --git a/debian/patches/abicompare.patch 
> > b/debian/patches/abicompare.patch
> > new file mode 100644
> > index 000..cdf3109
> > --- /dev/null
> > +++ b/debian/patches/abicompare.patch
> > @@ -0,0 +1,81 @@
> > +Index: sword-1.7.3+dfsg/include/canon_abbrevs.h
> > +===
> > +--- sword-1.7.3+dfsg.orig/include/canon_abbrevs.h  2013-08-22 
> > 08:03:11.0 +0100
> >  sword-1.7.3+dfsg/include/canon_abbrevs.h   2015-09-03 
> > 07:00:52.709829136 +0100
> > +@@ -24,6 +24,8 @@
> > + #ifndef CANON_ABBREVS_H
> > + #define 

Bug#787396: mupen64plus-qt ping

[Gianfranco Costamagna]

Hi Sergio,

did you have time to look to my package review?

cheers,

G.

Bug#797766: pac is not really ready yet

[Gianfranco Costamagna]

Control: noowner -1

Since for now pac has an autogenerated Debian directory I guess it isn't ready 
for
inclusion.

Feel free to ping me as soon as you have a debian packaging, and I'll reassing 
myself back to this task.

cheers,

G.

Bug#788418: nfft

[Gianfranco Costamagna]

Hi Ghislain,

with the gcc-5 transition almost done, how do you feel about looking at the 
nfft review?

cheers,

G.

Bug#798261: [Pkg-fonts-devel] Bug#798261: ITP: fonts-roboto-fontface -- largely geometric, friendly and open curves font

[Thomas Goirand]

On 09/08/2015 10:11 AM, Jonas Smedegaard wrote:
> Quoting Thomas Goirand (2015-09-08 09:28:15)
>> On 09/07/2015 08:42 PM, Jonas Smedegaard wrote:
 If you wish to drop the generation of fonts-roboto from the 
 fonts-android package, then good.
>>>
>>> I think the better approach is to keep the fonts-roboto package, have 
>>> your package exclude fonts, depend on the fonts-roboto package, and 
>>> symlink font files from there as needed.
>>
>> I don't think so. The fonts-roboto package currently only provides 
>> .tff files, which are useless for the web. The sources aren't the 
>> same.
> 
> What are the sources, then?

git://github.com/choffmeister/roboto-fontface-bower.git

 Do you think I should join the pkg-fonts group to maintain these 
 fonts under the group?
>>>
>>> We can always use more helping hands in the fonts team :-)
>>>
>>> But if your focus is on OpenStack then perhaps just coordinate with 
>>> the font team on tuning the fonts-roboto package to provide what is 
>>> needed for reuse with OpenStack - i.e. those web representations of 
>>> the font (CSS/Sass/Less sounds like OpenStack-specific glue so 
>>> probably makes best sense to package separately).
>>
>> They aren't OpenStack specific, it's just modern Javascript stuff, 
>> which can be reused by any project.
> 
> Great - then suggest maintainers of the existing package to adopt those 
> tiny files too.

Well, we just talked about dropping the generation of fonts-roboto from
the old source package... Or am I missing something?

Cheers,

Thomas

Bug#788653: RFS: ktap/0.4-1 [ITP] -- lightweight script-based dynamic tracing tool for Linux

[Azat Khuzhin]

On Wed, Sep 09, 2015 at 06:42:29AM +, Gianfranco Costamagna wrote:
> >You are correct, there is no need in "linux-headers-amd64", however there
> 
> >is second option just "linux-headers", and I don't understand why it
> >doesn't work for you.
> 
> 
> it does work for *me*, it doesn't for buildd system.
> 
> IIRC they are configured to pick only the first version...

Okay, thanks for the information.

> >I've updated package at mentors.debian.net, can you take a look one more
> >time?
> 
> 
> sure :)
> 
> there is an issue I don't understand:
> help2man --no-discard-stderr -h-h --version-string $(VERSION) -n 
> "$(DESCRIPTION)" ./ktap > debian/ktap.1
> echo "debian/ktap.1" >> debian/ktap.manpages
> 
> 
> this way if you rebuild the package twice
> $ cat debian/ktap.manpages 
> debian/ktap.1
> debian/ktap.1
> 
> 
> 
> 
> I guess this isn't what you want to achieve.
> 
> I'm fine with generating the documentation at build time, but I don't 
> understand why to do the echo, instead
> of having the file there.
> debian/ktap.manpages doesn't change at build time, so why autogenerate it?

You are correct, I've put debian/ktap.manpages statically.

> also, if you create a "ktab.manpages" it is picked by dh_installmanpages, so 
> the 

s/dh_installmanpages/dh_installman/

Otherwise there is an error about missing man page, since it is
generated at build time.

> dh_installdocs debian/doc/tutorial.html debian/ktap.1

Yep, thanks, I corrected. this.

> line is simply wrong (or duplicate)
> 
> I guess you want to override dh_installmanpages and dh_instaldocs separately
> 
> 
> 
> (the build was fine, so I guess the package is mostly ready now)

So, is there anything that I need/can to do to ship it to debian
repository?

Bug#798329: ifconfig: changed output format breaks scripts

[Thorsten Glaser]

On Tue, 8 Sep 2015, Guillem Jover wrote:

> Well, the ifconfig implementation in inetutils provides selectable

Oh, there’s another one? I’ve not looked at that one (yet)…

… but then, I really need something that works even with CentOS,
though it (even in version 6, which is way younger than 2003)
has the same output format as jessie.

> > Finally, I have no intentions on maintaining a fork of net-tools to
> > support the 14 years old output format of ifconfig, so I am closing this
> > as wontfix.
> 
> This is quite reasonable IMO.

Mh okay. I’m using code similar to the following to catch both
the old and new format (some day I’m going to test inetutils’):


export LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin
unset LANGUAGE

hn=$(hostname -f || echo $(hostname).invalid.fqdn)
[[ $hn = *.* ]] || hn=$hn.no.fqdn

lladdr=
test -s /etc/tarent/primary.mac && lladdr=$(cat /etc/tarent/primary.mac)
test -n "$lladdr" || lladdr=$(tgetif | \
sed -ne '/^ *ether 
\([0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]\)\(
 .*\)$/s//\1/p' -e '2,$d' -e '/^.* HWaddr 
\([0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]\)\(
 .*\)$/s//\1/p' | head -n 1)
ipaddr=$(tgetif | sed -n '/^ *inet \(addr:\)*\([0-9.]*\) .*$/s//\2/p')
netconf=$(/sbin/ip a | tr '\n' '~' | sed 's/~ /= /g' | tr '~' '\n' | fgrep -v 
vnet | tr '=' '\n' | sed -ne '/^[0-9]*: 
\([^:@]*\)\(@NONE\)*\([^:]*\):.*$/s//\1\3/p' -e '/inet/s/ scope.*//p' -e '/ 
link/s/ brd.*$//p'
) || netconf=


Maybe this helps others.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#796931: gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file

[Thorsten Glaser]

On Sun, 30 Aug 2015, Michael Gold wrote:

> > > Trying to support gpg2.0 and 2.1 in one startup script is still annoying
> > 
> > This is a requirement, though.
> 
> I've attached the script I'm using as an example.  I didn't test this

Hmm, really complex stuff there. I guess whatever I cobbled together
in 2009 isn’t as sophisticated.

https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=posix/sysadmin/agents.sh;h=485f025a5171a0721bb0cb10c3676f96393715f3;hb=HEAD

Anyway, at first glance, the new script (ignore the first part about
removing old gpg configs and running ssh-agent) appears to work,
although I’ve not yet tested after reboot. Thanks for the information!

Besides some logic changes (to avoid nesting ifs) I now set the
GPG_AGENT_INFO myself if not set, and write the “PID” file manually
instead of telling gpg-agent to do it. This appears to make pickup
from another session work, too.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#798390: setup-storage Failing, throwing "Command had non-zero exit code" after sfdisk command

[Thomas Lange]

In FAI 4.4 we will replace the sfdisk call with a parted call to set
the the bootable flag. Here's the commit:
https://github.com/faiproject/fai/commit/ced06d6c1909369c6108045a1b87fd31f5c87c91
-- 
regards Thomas

Bug#789699: ping :)

[Gianfranco Costamagna]

Hi Daniel,
the packaging looks good, however I'm not sure the package works correctly

vulture /home/locutus/branches/python-esmre/
Traceback (most recent call last):
File "/usr/bin/vulture", line 9, in 
load_entry_point('vulture==0.6', 'console_scripts', 'vulture')()
File "/usr/lib/python3/dist-packages/vulture.py", line 268, in main
vulture.scavenge(args)
File "/usr/lib/python3/dist-packages/vulture.py", line 108, in scavenge
self.scan(module_string)
File "/usr/lib/python3/dist-packages/vulture.py", line 77, in scan
node = ast.parse(node_string, filename=self.file)
File "/usr/lib/python3.4/ast.py", line 35, in parse
return compile(source, filename, mode, PyCF_ONLY_AST)
File "/home/locutus/branches/python-esmre/src/esmre.py", line 249
raise TypeError, "enter() cannot be called after query()"
^
SyntaxError: invalid syntax



is it normal?

cheers,

G.





Il Mercoledì 9 Settembre 2015 10:44, Daniel Stender <deb...@danielstender.com> 
ha scritto:
On 09.09.2015 08:55, Daniel Stender wrote:
> On 09.09.2015 08:50, Gianfranco Costamagna wrote:
>> Hi, Ping about 789699 (vulture)
>>
>> :)
>> cheers!
>>
>> G.
> 
> Yes yes yes :-) I was busy with with other stuff. It's coming up! Soon.
> 
> Dan

All right ...

let's do it this way with Vulture: a single new binary, build on Python 3 
instead on Python 2
(like the Python policy says it).

The one big thing in the archive with is going to employ is Prospector, which 
is currently running
on py2. But, transferring Prospector and its requirements to py3 is one of the 
next tasks to do.
Vulture is going to be in NEW for a time, anyway, and is then readily waiting 
for Prospector to
come right after.

To build two binaries, vulture{,3} or python{,3}-vulture is no good alternative 
to that,
alternatives (maint scripts) are rather complex, needs duplicating the same man 
page into two
files with different names, confusing for the end user, and next to 
Prospector-being-transferred
nothing really needs the main module in both public paths (and even not at the 
same time). 

So, here we go with:

committed changes:
http://anonscm.debian.org/viewvc/python-apps/packages/vulture/trunk/

Buildlog:
http://www.danielstender.com/buildlogs/vulture_0.6-1_amd64-20150909-1033.build

fresh Mentors upload:
http://mentors.debian.net/package/vulture
http://mentors.debian.net/debian/pool/main/v/vulture/vulture_0.6-1.dsc

Cheers,
Daniel


-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#747094: Updated Patch

[Stefano Zacchiroli]

On Thu, Aug 13, 2015 at 09:31:57AM -0700, Brian Murray wrote:
> Michael's patch was actually incomplete, I'm attaching an updated
> version which completely adds apt support and is now in Ubuntu.

Thanks for your patch! I've now rebuilt a local bash-completion that
uses it, and it's just great.

Small feature request: "apt install" can now (with the version of apt in
experimental, at least) install local .deb packages, and resolve
dependencies as needed. So it'd be nice if "apt install " would
also complete with local *.deb files on the filesystem. Do you think you
can add that?

FWIW, I'm considering NMU-ing to DELAYED/XX bash-completion to fix this
specific bug, as I think it'd help quite a bit with the adoption of the
new apt command. (But, anyone, feel free to beat me at it!)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#710587: [Aptitude-devel] Bug#710587: aptitude: unable to purge a package

[David Kalnischkies]

On Tue, Sep 08, 2015 at 03:40:20PM +0100, Manuel A. Fernandez Montecelo wrote:
> Is this with multi-arch enabled?  gnotski is now a transitional package,
> arch all, added on 25 May 2013 (very close to when the bug report
> happened), it must have been arch-dependent before.
[…]
> So I am not sure about what was wrong at the time, but I think that this
> bug is not present anymore.

This sounds like this bug:
https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=016bea8214e1826b289025f03890f70a5805db87
Note that it is only in /experimental, so with /unstable it should be
reproducible if its really this issue.


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Bug#798413: ftp.debian.org: Source-only uploads which FTBFS on Arch: all buildd require NEW processing in next upload

[Ansgar Burchardt]

Control: retitle -1 dak cruft-report should check Package-List field
Control: severity -1 normal

Santiago Vila  writes:
> When a source-only upload fails to build from source in the
> "Arch: all" autobuilder [1], the system seems to think that the source
> does no longer provide such Arch: all packages.

The cruft report does think so after some time (meh, heuristics are bad)
and packages are then removed by the ftp team after some time.

The proper solution is probably to have the cruft-report check the
source package's Package-List field that lists all packages built (and
on which architecture they are built).

Ansgar

Bug#788653: RFS: ktap/0.4-1 [ITP] -- lightweight script-based dynamic tracing tool for Linux

[Gianfranco Costamagna]

>Hm, there is linux-headers package, why build bot can't install it?
>vms?


don't know, it doesn't install in a clean sid environment.



maybe you want to deal with the module with some runtime build, like it is done 
with virtualbox-dkms package

otherwise you need to force the module rebuild at each kernel update, right?

I'm not sure kernel modules can be ship separately in a pre-built state
(what happens if the user has a custom kernel?)

cheers,

G.

Bug#798341: [inkscape] impossible to install inkscape

[Fabian Greffrath]

Am Mittwoch, den 09.09.2015, 09:52 +0200 schrieb Marco Righi:
> The following packages have unmet dependencies:
>  inkscape : Depends: libatkmm-1.6-1 (>= 2.22.1) but it is not going to
> be installed

This is most likely because of the libatkmm-1.6-1 -> libatkmm-1.6-1v5
transition. You better wait until inkscape 0.91-5+b2 has arrived at
testing.

 - Fabian


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

Bug#797866: libtorrent: ABI transition needed for libstdc++ v5

[Jose-Luis Rivas]

Nevermind, upstream bumped soname anyway.

On 08/09/15, 10:24pm, Jose-Luis Rivas wrote:
> Just to be clear, if I rebuild this with the source packages from
> unstable with a new upstream version the rename is not necessary?
> 
> On 03/09/15, 08:21am, Simon McVittie wrote:
> > Source: libtorrent
> > Version: 0.13.2-1
> > Severity: serious
> > Justification: breaks ABI without a package rename
> > Tags: sid stretch
> > User: debian-...@lists.debian.org
> > Usertags: libstdc++-cxx11
> > 
> > Background[1]: libstdc++6 introduces a new ABI to conform to the
> > C++11 standard, but keeps the old ABI to not break existing binaries.
> > Packages which are built with g++-5 from experimental (not the one
> > from testing/unstable) are using the new ABI.  Libraries built from
> > this source package export some of the new __cxx11 or B5cxx11 symbols,
> > dropping other symbols.  If these symbols are part of the API of
> > the library, then this rebuild with g++-5 will trigger a transition
> > for the library.
> > 
> > In the case of libtorrent, std::string appears in functions that are
> > explicitly exported, so it seems very likely that a transition is needed.
> > The transition normally consists of renaming the
> > affected library packages, adding a v5 suffix (libtorrent14v5).
> > The SONAME should not be changed when doing this.
> > 
> > If an upgrade to a new upstream SONAME is already planned, and that
> > SONAME has never been available in Debian compiled with g++-4, then an
> > alternative way to carry out the transition would be to bump the
> > SONAME. Please avoid doing this unless the new upstream version
> > is very low-risk.
> > 
> > These follow-up transitions for libstdc++ are not going through exactly
> > the normal transition procedure, because many entangled transitions are
> > going on at the same time, and the usual ordered transition procedure
> > does not scale that far. When all the C++ libraries on which this library
> > depends have started their transitions in unstable if required, this
> > library should do the same, closing this bug; the release team will deal
> > with binNMUs as needed.
> > 
> > Looking at the build-dependencies of libtorrent, the C++ libraries
> > are libcppunit and libsigc++, which have both had their renames
> > already; so this sub-transition is ready to start.
> > 
> > The package might be NMU'd if there is no maintainer response. The
> > release team have declared a 2 day NMU delay[2] for packages involved
> > in the libstdc++ transition, in order to get unstable back to a usable
> > state in a finite time.
> > 
> > Regards,
> > S
> > 
> > [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
> > [2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html
> 
> -- 
> ⨳ PGP 0x13EC43EEB9AC8C43 ⨳ https://ghostbar.co



-- 
⨳ PGP 0x13EC43EEB9AC8C43 ⨳ https://ghostbar.co


signature.asc
Description: Digital signature

Bug#798179: openconnect: Link to Juniper VPN will not be established without reconnect

[David Woodhouse]

On Tue, 2015-09-08 at 18:58 -0400, Mike Miller wrote:
> But this is only to eliminate or implicate NM. If we already think NM 
> is implicated, then nevermind.

And if the only thing that NM is accused of is not working well when
you try to set network devices up behind its back, then nevermind
indeed.

It would be nice to have Juniper support which *does* work properly
with NetworkManager. It's possible for now just by building
libopenconnect with Juniper as the default, instead of AnyConnect.

Before I support it for real, I really want to sort out the HTML
authentication forms (letting the UI render real HTML instead of the
hack I currently have to parse the known forms and fail on anything non
-standard).

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature

Bug#792882: /bin/machinectl: machinectl fails to login to container

[Ritesh Raj Sarraf]

On Tue, 2015-09-08 at 19:34 +0200, Michael Biebl wrote:
> Have you added /dev/pts/0 to /etc/securetty?
> That's currently necessary in Debian.
> Also, installing dbus inside the container is mandatory as well.


Yes. That was the conclusion we made in the last conversation from
July.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#797281: ompl ftbfs because boost

[Leopold Palomo-Avellaneda]

Dear reporter,

the problem with this bug is a problem of boost 1.58 and gcc5. Ompl builds 
without any problem with boost 1.59 and gcc5. 

798021 has a patch. Just need that boost maintainers upload a new version of 
boost 1.58 of upgrade boost-defaults to 1.59.

Thanks

Leopold

Bug#798423: RFS: alien/8.95 [QA] -- convert and install rpm and other packages

[Gianfranco Costamagna]

Control: owner -1 !
Control: tags -1 moreinfo

Hi Fabiano,

+++ alien-8.95/alien.spec   2015-09-09 02:28:26.0 +0200
@@ -1,12 +1,12 @@
Summary: Install Debian, Slackware, and Stampede packages with rpm.
Name: alien
Packager: Joey Hess 
-Version: 8.93
+Version: 8.95
Release: 1
-Source: ftp://kitenet.net/pub/code/debian/alien_8.93.tar.gz
+Source: ftp://kitenet.net/pub/code/debian/alien_8.95.tar.gz
License: GPL
Group: Utilities/File
-Buildroot: /tmp/alien-8.93.build
+Buildroot: /tmp/alien-8.95.build
Requires: perl
BuildArchitectures: noarch


I don't see the tarball there...
maybe you want to ask Joey to upload it?





control/rules file: why do you b-d on quilt?

vcs-git
git clone git://git.kitenet.net/alien
Cloning into 'alien'...
fatal: remote error: access denied or repository not exported: /alien


alien-8.94/debian/.pc/.quilt_patches1970-01-01 01:00:00.0 +0100

can you please strip the .pc directory? I guess it is useless.

please also if you have a native package consider to patch it directly instead 
of having separate patches.
(or a mix, like in this case)

BTW what about start maintaining it upstream too? :)

cheers,

G.

Bug#788653: RFS: ktap/0.4-1 [ITP] -- lightweight script-based dynamic tracing tool for Linux

[Azat Khuzhin]

On Wed, Sep 09, 2015 at 07:48:12AM +, Gianfranco Costamagna wrote:
> Hi,
> 
> 
> >You are correct, I've put debian/ktap.manpages statically.
> 
> 
> wonderful
> 
> >s/dh_installmanpages/dh_installman/
> 
> 
> yes, sure
> 
> maybe something like
> override_dh_installman:
> 
> help2man --no-discard-stderr -h-h --version-string $(VERSION) -n 
> "$(DESCRIPTION)" ./ktap > debian/ktap.1
> 
> dh_installman
> 
> the same for doc and examples.

Done already.

> >So, is there anything that I need/can to do to ship it to debian
> 
> >repository?
> 
> sure, the package is almost ready, just the tweaks above, and to make it 
> build on a clean environment.
> http://debomatic-amd64.debian.net/distribution#unstable/ktap/0.4-1/buildlog
> 
> The following packages have unmet dependencies:
> sbuild-build-depends-ktap-dummy : Depends: linux-headers but it is not 
> installable
> E: Unable to correct problems, you have held broken packages.

Hm, there is linux-headers package, why build bot can't install it?
vms?

> P.S. you have some build warnings:
> CC [M] ktap-0.4/runtime/amalg.o
> In file included from ktap-0.4/runtime/amalg.c:28:0:
> ktap-0.4/runtime/kp_transport.c: In function ‘kp_printf’:
> ktap-0.4/runtime/kp_transport.c:574:1: warning: the frame size of 1056 bytes 
> is larger than 1024 bytes [-Wframe-larger-than=]
> }
> ^
> 
> 
> userspace/kp_reader.c: In function ‘reader_thread’:
> userspace/kp_reader.c:87:3: warning: ignoring return value of ‘write’, 
> declared with attribute warn_unused_result [-Wunused-result]
> write(out_fd, buf, len);
> ^

This two issues are not critical, I will fix this later and send
upstream.

Bug#792548: [DRE-maint] Bug#792548: ruby-hashie, ruby-rash: error when trying to install together

[Matthias Klose]

> Since ruby-rash has no reverse dependencies, I propose we remove it and
> add a Conflicts: to ruby-hashie.

$ reverse-depends -b src:ruby-rash
Reverse-Build-Depends
=
* ruby-faraday-middleware   (for ruby-rash)

Bug#788653: RFS: ktap/0.4-1 [ITP] -- lightweight script-based dynamic tracing tool for Linux

[Gianfranco Costamagna]

>You are correct, there is no need in "linux-headers-amd64", however there

>is second option just "linux-headers", and I don't understand why it
>doesn't work for you.


it does work for *me*, it doesn't for buildd system.

IIRC they are configured to pick only the first version...
>Anyway I dropped "linux-headers-amd64" frop B-D.
>


wonderful

>fixed this and one other.

wonderful

>I've updated package at mentors.debian.net, can you take a look one more
>time?


sure :)

there is an issue I don't understand:
help2man --no-discard-stderr -h-h --version-string $(VERSION) -n 
"$(DESCRIPTION)" ./ktap > debian/ktap.1
echo "debian/ktap.1" >> debian/ktap.manpages


this way if you rebuild the package twice
$ cat debian/ktap.manpages 
debian/ktap.1
debian/ktap.1




I guess this isn't what you want to achieve.

I'm fine with generating the documentation at build time, but I don't 
understand why to do the echo, instead
of having the file there.
debian/ktap.manpages doesn't change at build time, so why autogenerate it?

also, if you create a "ktab.manpages" it is picked by dh_installmanpages, so 
the 

dh_installdocs debian/doc/tutorial.html debian/ktap.1


line is simply wrong (or duplicate)

I guess you want to override dh_installmanpages and dh_instaldocs separately



(the build was fine, so I guess the package is mostly ready now)

cheers,

G.

Bug#796731: freecontact: FTBFS on mips (test suite failure)

[Andreas Tille]

Hi mips porters,

could anybody please find a more powerful machine to build the rdepends
libfreecontact-perl and python-freecontact.

Alternatively I would decide to exclude mips architecture for
libfreecontact and its Perl and Python interfaces since I see no point
in delivering a package that does not pass its build time check.

Thanks

   Andreas.

On Tue, Sep 08, 2015 at 10:26:58PM +0200, Julien Cristau wrote:
> Control: reopen -1
> 
> On Fri, Aug 28, 2015 at 17:42:10 +0200, Andreas Tille wrote:
> 
> > Hi Julien,
> > 
> > On Fri, Aug 28, 2015 at 05:20:55PM +0200, Julien Cristau wrote:
> > > On Wed, Aug 26, 2015 at 17:05:39 +0200, Andreas Tille wrote:
> > > 
> > > > Any chance to do a manual build on a more powerfull MIPS box which might
> > > > not run into this problem? 
> > > > 
> > > NAK.  We need packages to build reliably on our buildds.
> > 
> > The reliability of a build can be proven by passing the test suite.  So
> > in this case we need buildds that can reliably build the package.
> > Otherwise the package should probably be excluded from this architecture
> > at all.  BTW, the package is now available for mips since some kind soul
> > managed to build it.
> > 
> > Thanks to whomever the work did finally
> > 
> Nope, no sugar.  Now instead we have
> https://buildd.debian.org/status/fetch.php?pkg=libfreecontact-perl=mips=0.08-4=1441643884
> and
> https://buildd.debian.org/status/fetch.php?pkg=python-freecontact=mips=1.1-2=1441644922
> 
> That's not an improvement.
> 
> Cheers,
> Julien



-- 
http://fam-tille.de

Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default

[Daniel Glassey]

On Wed, Sep 09, 2015 at 04:08:25AM -0400, Roberto C. Sánchez wrote:
> Do you want me to go ahead with uploading -3 as is then?

No need, could you just git-buildpackage build and tag -4 ?

Thanks,
Daniel

> On Wed, Sep 09, 2015 at 07:48:32AM +0100, Daniel Glassey wrote:
> > On Tue, Sep 08, 2015 at 09:35:14PM -0400, Roberto C. Sánchez wrote:
> > > Daniel,
> > > 
> > > I just built this and was going to upload for you, but I noticed that
> > > lintian complained of two errors:
> > > 
> > > E: sword source: license-problem-undefined-license unknown (paragraph at 
> > > line 25)
> > > E: libsword-dev: pkg-config-multi-arch-wrong-dir 
> > > usr/lib/pkgconfig/sword.pc full text contains architecture specific dir 
> > > x86_64-linux-gnu
> > > 
> > > I don't have time to dig into the lintian errors tonight, but I may be
> > > able to in the next day or so.
> > > 
> > > Also, if you could push the tags for the various 1.7.3 versions that
> > > would be helpful.  I was going to check out on the debian/1.7.3+dfsg-3
> > > and build from Git, but there was no tag, so I did an 'apt-get source'
> > > and applied the patch you attached to the bug instead.
> > 
> > Ah, indeed, I forgot to tag 1.7.3+dfsg-3.
> > 
> > The fixes for lintian inc enabling multiarch are all in git in 1.7.3+dfsg-4 
> > ready to be tagged and released.
> > I only did the 1.7.3+dfsg-3 to keep the patch simple for transition team to 
> > apply if necessary.
> > 
> > Thanks :)
> > Daniel
> > 
> > > On Mon, Sep 07, 2015 at 11:55:36AM +0100, Daniel Glassey wrote:
> > > > user release.debian@packages.debian.org
> > > > usertag 796711 + transition
> > > > usertag 796711 + patch
> > > > block 796711 by 790756
> > > > reassign 796711 release.debian.org
> > > > thanks
> > > > 
> > > > patch attached for the transition.
> > > > 
> > > > I need to wait for a keyring update before I can upload myself.
> > > > 
> > > > Thanks,
> > > > Daniel
> > > 
> > > > diff --git a/debian/changelog b/debian/changelog
> > > > index b62945f..7fa2648 100644
> > > > --- a/debian/changelog
> > > > +++ b/debian/changelog
> > > > @@ -1,3 +1,13 @@
> > > > +sword (1.7.3+dfsg-3) unstable; urgency=low
> > > > +
> > > > +  * c++ transition
> > > > +  rename library to libsword11v5
> > > > +  blocked by ICU c++ transition
> > > > +  * add patch abicompare.patch to allow libsword to work with 
> > > > +  abi-compliance-checker for future transitions
> > > > +
> > > > + -- Daniel Glassey   Wed, 02 Sep 2015 14:15:09 +0100
> > > > +
> > > >  sword (1.7.3+dfsg-2.1) unstable; urgency=medium
> > > >  
> > > >* Non maintainer upload.
> > > > diff --git a/debian/control b/debian/control
> > > > index 53dbebe..9f59bf3 100644
> > > > --- a/debian/control
> > > > +++ b/debian/control
> > > > @@ -17,7 +17,7 @@ Uploaders: Daniel Glassey ,
> > > >  Standards-Version: 3.9.3
> > > >  Homepage: http://www.crosswire.org/sword/
> > > >  
> > > > -Package: libsword11
> > > > +Package: libsword11v5
> > > >  Architecture: any
> > > >  Depends: libsword-common, ${shlibs:Depends}, ${misc:Depends}
> > > >  Recommends: sword-frontend
> > > > @@ -36,7 +36,7 @@ Description: API/library for bible software
> > > >  Package: libsword-dev
> > > >  Architecture: any
> > > >  Section: libdevel
> > > > -Depends: libsword11 (= ${binary:Version}), ${misc:Depends}
> > > > +Depends: libsword11v5 (= ${binary:Version}), ${misc:Depends}
> > > >  Recommends: libsword-utils
> > > >  Description: Development files for libsword
> > > >   The SWORD Project is an open source, cross-platform (Linux, Windows, 
> > > > Solaris,
> > > > @@ -80,7 +80,7 @@ Package: libsword-dbg
> > > >  Architecture: any
> > > >  Section: debug
> > > >  Priority: extra
> > > > -Depends: libsword11 (= ${binary:Version}), ${misc:Depends}
> > > > +Depends: libsword11v5 (= ${binary:Version}), ${misc:Depends}
> > > >  Description: API/library for bible software - Debug Files
> > > >   The SWORD Project is an open source, cross-platform (Linux, Windows, 
> > > > Solaris,
> > > >   MacOSX etc.) API/library for Bible software with a constantly growing 
> > > > list 
> > > > diff --git a/debian/libsword11.docs b/debian/libsword11.docs
> > > > deleted file mode 100644
> > > > index 546a37e..000
> > > > --- a/debian/libsword11.docs
> > > > +++ /dev/null
> > > > @@ -1 +0,0 @@
> > > > -doc/translation-template.conf
> > > > diff --git a/debian/libsword11.install b/debian/libsword11.install
> > > > deleted file mode 100644
> > > > index 79e4168..000
> > > > --- a/debian/libsword11.install
> > > > +++ /dev/null
> > > > @@ -1 +0,0 @@
> > > > -usr/lib/libsword.so.11
> > > > diff --git a/debian/libsword11v5.docs b/debian/libsword11v5.docs
> > > > new file mode 100644
> > > > index 000..546a37e
> > > > --- /dev/null
> > > > +++ b/debian/libsword11v5.docs
> > > > @@ -0,0 +1 @@
> > > > +doc/translation-template.conf
> > > > diff --git a/debian/libsword11v5.install b/debian/libsword11v5.install
> > > > new file 

Bug#789699: ping :)

[Daniel Stender]

On 09.09.2015 08:55, Daniel Stender wrote:
> On 09.09.2015 08:50, Gianfranco Costamagna wrote:
>> Hi, Ping about 789699 (vulture)
>>
>> :)
>> cheers!
>>
>> G.
> 
> Yes yes yes :-) I was busy with with other stuff. It's coming up! Soon.
> 
> Dan

All right ...

let's do it this way with Vulture: a single new binary, build on Python 3 
instead on Python 2
(like the Python policy says it).

The one big thing in the archive with is going to employ is Prospector, which 
is currently running
on py2. But, transferring Prospector and its requirements to py3 is one of the 
next tasks to do.
Vulture is going to be in NEW for a time, anyway, and is then readily waiting 
for Prospector to
come right after.

To build two binaries, vulture{,3} or python{,3}-vulture is no good alternative 
to that,
alternatives (maint scripts) are rather complex, needs duplicating the same man 
page into two
files with different names, confusing for the end user, and next to 
Prospector-being-transferred
nothing really needs the main module in both public paths (and even not at the 
same time). 

So, here we go with:

committed changes:
http://anonscm.debian.org/viewvc/python-apps/packages/vulture/trunk/

Buildlog:
http://www.danielstender.com/buildlogs/vulture_0.6-1_amd64-20150909-1033.build

fresh Mentors upload:
http://mentors.debian.net/package/vulture
http://mentors.debian.net/debian/pool/main/v/vulture/vulture_0.6-1.dsc

Cheers,
Daniel

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#798430: apache2: please add systemd service file

[Arturo Borrero Gonzalez]

Package: apache2
Severity: wishlist

Dear maintainers,

thanks for your work on this important pacakge. It's really appreciated.

Current apache2 package lacks of systemd service file (though is well
integrated with systemd due to glue scripts)

I would like to have a native systemd service file. Among other things,
we can benefit of:
 * systemd security features (i.e ProtectHome= and ProtectSystem= and more)
 * watchdog capabilities by systemd

There are lot of basic apache2 systemd service files in the net to get ideas for
debian one, for example (needs to be debianized, of course):

= 8< =
[Unit]
Description=Apache 2 HTTP Web Server
After=network.target

[Service]
Type=forking
EnvironmentFile=/etc/conf.d/apache2
ExecStart=/usr/sbin/apache2 -k start $APACHE2_OPTS
ExecStop=/usr/sbin/apache2 -k graceful-stop $APACHE2_OPTS
ExecReload=/usr/sbin/apache2 -k graceful $APACHE2_OPTS
PIDFile=/var/run/apache2.pid
StandardOutput=syslog
StandardError=syslog
Restart=always
ProtectHome=yes
ProtectSystem=full

[Install]
WantedBy=multi-user.target
WantedBy=http-daemon.target
= 8< =

best regards.

Bug#798435: gosa-sync breaks password changes on non-Kerberized accounts

[Mike Gabriel]

Package: debian-edu-config
Severity: important
Version: 1.818
Tags: patch

Hi all,

we have started creating non-POSIX / non-Kerberos accounts on a Debian  
Edu main server and stumble over a slight flaw debian-edu-config's  
gosa-sync script (password change hook).


The hook scripts tries to change the password of the underlying  
Kerberos principal. It does this always, even if the account  
to-be-updated is not a Kerberos account.


By default, we only turn POSIX accounts into Kerberos accounts (which  
is a sensible default). This should be honoured by the gosa-sync  
script as seen in the below patch (also attached to this mail):


"""
--- gosa-sync.orig  2015-09-09 11:41:11.0 +0200
+++ gosa-sync   2015-09-09 12:19:36.703718246 +0200
@@ -17,6 +17,15 @@
 USERDN="$1"
 USERID=`echo "$USERDN" | sed "s/^uid=\([^,]*\),.*$/\1/"`

+# check if the given user account has the Kerberos principal  
objectClass set...
+is_krbprincipal=`ldapsearch -LLL -x  
"(&(uid=${USERID})(objectClass=krbPrincipalAux))"`

+if [ -z "$is_krbprincipal" ]; then
+
+   # if not, simply bail out here without noise...
+exit 0
+
+fi
+
 ## The new user password is in environment, $USERPASSWORD.
 ## Check if provided password corresponds to hash saved in ldap database:

"""

It would be nice to get this fixed in Debian Edu jessie...

Mike
--

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

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

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
--- gosa-sync.orig  2015-09-09 11:41:11.0 +0200
+++ gosa-sync   2015-09-09 12:19:36.703718246 +0200
@@ -17,6 +17,15 @@
 USERDN="$1"
 USERID=`echo "$USERDN" | sed "s/^uid=\([^,]*\),.*$/\1/"`
 
+# check if the given user account is has the Kerberos principal objectClass 
set...
+is_krbprincipal=`ldapsearch -LLL -x 
"(&(uid=${USERID})(objectClass=krbPrincipalAux))"`
+if [ -z "$is_krbprincipal" ]; then
+
+   # if not, simply bail out here without noise...
+exit 0
+
+fi
+
 ## The new user password is in environment, $USERPASSWORD.
 ## Check if provided password corresponds to hash saved in ldap database:
 



pgptqsTG79eMs.pgp
Description: Digitale PGP-Signatur

Bug#798446: eclipse-wtp-xsl: no option to run XSL transformation; no XSL configurations

[Mark Carroll]

Package: eclipse-wtp-xsl
Version: 3.6.0-1
Severity: important

Dear Maintainer,

I am following https://wiki.eclipse.org/XSLT_Project/UserGuide/Launching which
may somehow be wrong. After restarting Eclipse, in the Package Explorer if I
right-click an XSL file (or also select an XML file, and right-click either)
then Run As offers no interesting options, and leads me to the Run
Configurations menu which also has nothing relating to XML or XSL. Ought I
have installed some other processor or somesuch to activate these options?
It would be great to be able to run and debug style sheets.

Cheers,

Mark

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

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

Versions of packages eclipse-wtp-xsl depends on:
ii  eclipse-wtp  3.6.0-1
ii  eclipse-wtp-xmltools 3.6.0-1
ii  libcommons-logging-java  1.2-1
ii  liblog4j1.2-java 1.2.17-5
ii  libxalan2-java   2.7.1-9
ii  libxerces2-java  2.11.0-7
ii  w3c-xsd-xslt 3.6.0-1

eclipse-wtp-xsl recommends no packages.

eclipse-wtp-xsl suggests no packages.

-- no debconf information

Other packages that might matter are,

ii  default-jre [java6-runtime]   2:1.7-52
ii  eclipse-platform-data 3.8.1-7
ii  eclipse-rcp   3.8.1-7
ii  java-common   0.52
ii  openjdk-7-jre [java6-runtime] 7u79-2.5.6-1~deb8u1
ii  oracle-java8-jdk [java6-runtime]  8u51

Bug#798077: minidlna: segfault libc-2.19

[Alexander Gerasiov]

fixed 798077 1.1.4+dfsg-1
thanks

Hello fhobbies,

On Tue, 8 Sep 2015 21:34:36 +0200
fhobbies  wrote:

> Hello and thank for your reply (and sorry for my english)
> 
> i modify my configuration for keep stable version of system and keep
> jessie-backports for only minidlna package.
> 
> after an update of packages without minidlna backport and rebooting
> (and update of libc), the running is the same … crash. But
> effectively after migration of minidlna to jessie-backports, the
> process running without crash (segfault).
Ok, then I mark this bug as fixed in 1.1.4+dfsg-1 and put the problem
on hold until someone prove this is really critical and patch should be
backported (security etc).

> 
> Thanks a lot
> 
> > Le 7 sept. 2015 à 14:02, Alexander Gerasiov  a écrit :
> > 
> > severity 798077 normal
> > tags 798077 + moreinfo 
> > 
> > 
> > Hello fhobbies,
> > 
> > On Sat, 05 Sep 2015 10:58:21 +0200
> > fhobbies  wrote:
> > 
> >> Package: minidlna
> >> Version: 1.1.2+dfsg-1.1+b3
> >> Severity: important
> >> 
> >> Dear Maintainer,
> >> 
> >> *** Reporter, please consider answering these
> >> questions, where appropriate ***
> >> 
> >> Sep  5 09:40:30 office kernel: [ 1424.466305] minidlnad[4600]:
> >> segfault at 8 ip 7f19819f1c8a sp 7ffe6af7b628 error 4 in
> >> libc-2.19.so[7f198197+19f000]
> > 
> > Dear reporter, please consider _answering_ these questions:
> >>   * 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?
> >> 
> > 
> > Could you reproduce this bug with 1.1.4+dfsg-4 (from testing or
> > backports)?
> > 
> > -- 
> > Best regards,
> > Alexander Gerasiov
> > 
> > Contacts:
> > e-mail: g...@cs.msu.su  Homepage: http://gerasiov.net  Skype: gerasiov
> > PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1



-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  Homepage: http://gerasiov.net  Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#798423: RFS: alien/8.95 [QA] -- convert and install rpm and other packages

[Gianfranco Costamagna]

>Somehow, dch --qa automatically pushes the minor version up.  I have 

>realized it just now,
>by testing is again in a new directory.  Is there a way I could do the 
>QA work without changing
>the tarball version?


I guess this is because the package is native

>Having two separate patches to perform two (very) distinct fixes sounded 
>a good idea to me.
>I'm not really sure about how to handle native packages, so I thought 
>I'd better not touch it,
>so that I wouldn't introduce any new bugs.  Anyways, note taken! Thank 
>you! ;-)


the problem is that you can leave the tarball as it was before, and add quilt 
patches,
but I'm not sure this is the right thing to do...

anyway please run a debdiff between the two dsc files and add them as quilt 
patches, lets
see how it goes :)

(it might be the best way to deal with future bugs)

cheers,

G.

(not a problem if you mispell my name, no need to be sorry! :) )

Bug#773915: Why not upstream?

[Raphaël Halimi]

Le 09/09/2015 11:21, Andreas Henriksson a écrit :
> Hello Raphaël Halimi.
> 
> Thanks for your bug report and patch!
> 
> I'd like to question a conflict I see in the reasoning around
> "Forwarded: not-needed".
> 
> Why should this not be forwarded upstream?

You're welcome to try, but frankly, I seriously doubt that upstream
could be convinced to include even those two lines of code (let alone a
test for each known xterm-compatible terminal or wrapper, for distros
not using an alternative system) just to accommodate the (many) users of
non-GNOME desktops which rely on Glib to launch applications in a terminal.

> What harm would this change do upstream?

None, aside of a less-than-a-microsecond delay due to the added test.

> If it's not suitable for upstream, why would it be suitable for debian?

Because it would allow to close bug reports in various BTS (see provided
links) in addition to this one, which would provide a great service to a
lot of Debian (and derivatives) users; isn't that what the Debian Social
Contract's clause #4 is all about ?

[1] https://bugs.launchpad.net/linuxmint/+bug/1238964
[2] https://bugs.launchpad.net/ubuntu-mate/+bug/1415048
[3] https://github.com/mate-desktop/mate-panel/issues/57

> glib is a critical component which atleast me (which is not the
> one deciding this) would like to avoid patching at all.
> In general I also think that adding patches which will have
> to be carried *forever* is something you never want to add
> (unless absolutely necessary).

I agree, but as I said, you're welcome to try.

> I think it's important to atleast have answers to these
> questions on the record for the future

I hope I did.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#795971: contributors.debian.org: list of inactive developers

[Orestis Ioannou]

Heya,

On Tue, 18 Aug 2015 14:27:52 +0200 Enrico Zini  wrote:

> in view of making contributors.debian.org a useful tool for the MIA
> team, I'd like to experiment with having a view that shows a list of all
> people with a debian.org account who have not had any visible
> contributions in the last X years.

I am interested in implementing this. I have two questions before starting:

- this should only be visible for DDs ?
- have you thought of caching this information somewhere since doing the
query at each request might be costly (performance wise)? And maybe
running the query once a day or so?

Cheers,

Orestis






signature.asc
Description: OpenPGP digital signature

Bug#798441: python-bleach: Non-determistically FTBFS due to unreliable tests

[Chris Lamb]

Source: python-bleach
Version: 1.4-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-bleach's testsuite can non-deterministically fail, causing the
package
to FTBFS:

  [..]
  nosetests3
  
...F
  ==
  FAIL: Make sure that applying the filter twice doesn't change
  anything.
  --
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in
runTest
  self.test(*self.arg)
File "/tmp/buildd/python-bleach-1.4/bleach/tests/test_basics.py",
line 156, in test_idempotent
  eq_(linked, bleach.linkify(linked))
  AssertionError: 'invalidextra http://link.com;>http://link.com' !=
  'invalidextra http://link.com;
  rel="nofollow">http://link.com'
  
  --
  Ran 128 tests in 1.007s
  
  FAILED (failures=1)
  debian/rules:13: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 1
  make[1]: Leaving directory '/tmp/buildd/python-bleach-1.4'
  debian/rules:6: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

  [..]

You can see demonstrate this by leaving this to run for a minute or so:

  $ while nosetests3 bleach.tests.test_basics:test_idempotent; do :;
  done

Curiously, I cannot reproduce when running the tests under Python 2.X
which may help track down the underlying issue.

The full build log is attached or can be viewed here:


https://reproducible.debian.net/logs/unstable/amd64/python-bleach_1.4-1.build2.log.gz


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: dimanche 6 septembre 2015, 16:34:15 (UTC+1400)
I: pbuilder-time-stamp: 1441506855
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/unstable-reproducible-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /dev/shm
I: Mounting /sys
I: policy-rc.d already exists
I: Installing the build-deps
I: user script 
/var/cache/pbuilder/build//24789/tmp/hooks/D01_modify_environment starting
I: Changing host+domainname to test build reproducibility
I: Adding a custom variable just for the fun of it...
I: user script 
/var/cache/pbuilder/build//24789/tmp/hooks/D01_modify_environment finished
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 8), dh-python, python-docutils, python3-all, 
python3-nose, python3-setuptools, python3-sphinx (>= 1.0.7+dfsg-1~), python-all 
(>= 2.6.6-3~), python-nose, python-setuptools, python-sphinx (>= 
1.0.7+dfsg-1~), python3-html5lib, python3-six, python-html5lib, python-six
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 20262 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on dh-python; however:
  Package dh-python is not installed.
 pbuilder-satisfydepends-dummy depends on python-docutils; however:
  Package python-docutils is not installed.
 pbuilder-satisfydepends-dummy depends on python3-all; however:
  Package python3-all is not installed.
 pbuilder-satisfydepends-dummy depends on python3-nose; however:
  Package python3-nose is not installed.
 pbuilder-satisfydepends-dummy depends on python3-setuptools; however:
  Package python3-setuptools is not installed.
 pbuilder-satisfydepends-dummy depends on python3-sphinx (>= 1.0.7+dfsg-1~); 
however:
  Package python3-sphinx is not installed.
 pbuilder-satisfydepends-dummy depends on python-all (>= 2.6.6-3~); however:
  Package python-all is 

Bug#798438: procps: FTBFS: Makefile:526: recipe for target 'check-DEJAGNU' failed

[Chris Lamb]

On Wed, 9 Sep 2015, at 12:45 PM, Craig Small wrote:

> Any chance of getting testsuite/ps.log out of the buildds? It will give
> me exactly what the tester is unhappy about.

Sure - I can always reproduce locally outside all of the, uhh,
reproducible stuff.

(Attached.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
Test Run By lamby on Wed Sep  9 12:54:05 2015
Native configuration is x86_64-pc-linux-gnu

		=== ps tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./ps.test/ps_output.exp ...
spawn /home/lamby/temp/cdt.20150909125319.AgFh6XRwrb/procps-3.3.10/ps/pscommand -o %cpu,pcpu,%mem,pmem
%CPU %CPU %MEM %MEM
 0.0  0.0  0.0  0.0
PASS: ps with output flag %cpu,pcpu,%mem,pmem
spawn /home/lamby/temp/cdt.20150909125319.AgFh6XRwrb/procps-3.3.10/ps/pscommand -o blocked,sig_block,sigmask,caught,sigcatch,sig_catch
 BLOCKED  BLOCKED  BLOCKED   CAUGHT   CAUGHT  CATCHED
   0001f3d1fef9 0001f3d1fef9 0001f3d1fef9
PASS: ps with output flag blocked,sig_block,sigmask,caught,sigcatch,sig_catch
spawn /home/lamby/temp/cdt.20150909125319.AgFh6XRwrb/procps-3.3.10/ps/pscommand -o bsdstart,start,lstart
 START  STARTED  STARTED
 12:54 12:54:05 Wed Sep  9 12:54:05 2015
PASS: ps with output flag bsdstart,start,lstart
spawn /home/lamby/temp/cdt.20150909125319.AgFh6XRwrb/procps-3.3.10/ps/pscommand -o bsdtime,cputime,etime,etimes
  TIME TIME ELAPSED ELAPSED
  0:00 00:00:00   00:00   0
PASS: ps with output flag bsdtime,cputime,etime,etimes
spawn /home/lamby/temp/cdt.20150909125319.AgFh6XRwrb/procps-3.3.10/ps/pscommand -o user,ruser,group,rgroup,uid,ruid,gid,rgid
USER RUSERGROUPRGROUP UID  RUID   GID  RGID
lambylambylambylamby 1000  1000  1000  1000
PASS: ps with output flag user,ruser,group,rgroup,uid,ruid,gid,rgid
testcase ./ps.test/ps_output.exp completed in 0 seconds
Running ./ps.test/ps_personality.exp ...
spawn /home/lamby/temp/cdt.20150909125319.AgFh6XRwrb/procps-3.3.10/ps/pscommand
  PID TTY  STAT   TIME COMMAND
1 pts/5Ss 0:00 /bin/zsh
PASS: ps with bsd personality
spawn /home/lamby/temp/cdt.20150909125319.AgFh6XRwrb/procps-3.3.10/ps/pscommand
  PID TTY  TIME CMD
10500 pts/600:00:00 lt-pscommand
PASS: ps with linux personality
spawn /home/lamby/temp/cdt.20150909125319.AgFh6XRwrb/procps-3.3.10/ps/pscommand
  PID TTY  STAT   TIME COMMAND
1 pts/5Ss 0:00 /bin/zsh
PASS: ps with old personality
testcase ./ps.test/ps_personality.exp completed in 0 seconds
Running ./ps.test/ps_sched_batch.exp ...
spawn /home/lamby/temp/cdt.20150909125319.AgFh6XRwrb/procps-3.3.10/testsuite/test-schedbatch 18
spawn /home/lamby/temp/cdt.20150909125319.AgFh6XRwrb/procps-3.3.10/ps/pscommand --no-header -o comm,cls,nice -a
zsh  TS   0
debuild  TS   0
tee  TS   0
dpkg-buildpacka  TS   0
rulesTS   0
dh   TS   0
dh_auto_test TS   0
make TS   0
make TS   0
bash TS   0
bash TS   0
make TS   0
make TS   0
bash TS   0
expect   TS   0
test-schedbatch   B  18
PASS: ps SCHED_BATCH scheduler
UNTESTED: ps SCHED_BATCH scheduler
testcase ./ps.test/ps_sched_batch.exp completed in 0 seconds

		=== ps Summary ===

# of expected passes		9
# of untested testcases		1
runtest completed at Wed Sep  9 12:54:05 2015

Bug#798445: O: spice-xpi

[Petter Reinholdtsen]

Package: wnpp
Severity: normal

The need I had for a SPICE browser plugin have passed, and I believe it
is best if someone using SPICE on a regular basis take over maintaining
this package.

As can be seen on
https://tracker.debian.org/pkg/spice-xpi >, the package is bug
free, and its biggest flaw is missing architectures, because its build
dependency is missing on several architectures.

The debian build setup is in collab-maint,
http://anonscm.debian.org/gitweb/?p=collab-maint/spice-xpi.git;a=summary 
>.

-- 
Vennlig hilsen
Petter Reinholdtsen

Bug#777087: klibc-utils-floppy-udeb: please build the floppy udeb on x32

[Thorsten Glaser]

Adam Borowski dixit:

>While I did not test whether it works (how do you use floppies these days?),

By placing the floppy disc into a floppy drive. Easy. :þ

bye,
//mirabilos

PS: Qemu can do it, too…
-- 
I want one of these. They cost 720 € though… good they don’t have the HD hole,
which indicates 3½″ floppies with double capacity… still. A tad too much, atm.
‣ http://www.floppytable.com/floppytable-images-1.html

Bug#796711: sword: library transition is needed with GCC 5 as default

[Daniel Glassey]

On Tue, Sep 08, 2015 at 10:51:43PM +0100, Jonathan Wiltshire wrote:
> On Mon, Sep 07, 2015 at 11:55:36AM +0100, Daniel Glassey wrote:
> > user release.debian@packages.debian.org
> > usertag 796711 + transition
> > usertag 796711 + patch
> > block 796711 by 790756
> > reassign 796711 release.debian.org
> > thanks
> > 
> > patch attached for the transition.
> > 
> > I need to wait for a keyring update before I can upload myself.
> 
> I don't mind sponsoring this if you would find that helpful.

Thanks Jonathan. Roberto Sanchez (another member of pkg-crosswire) is now 
taking care of the upload to unstable (I 
had experimental in the changelog of the patch by mistake) of the next version 
that also fixes lintian errors and 
enables multiarch.

Regards,
Daniel


signature.asc
Description: Digital signature

Bug#798447: xfce4-panel: Desktop-Applications in .local/share/applications disappear and return after restart.

[Andreas Schröter]

Package: xfce4-panel
Version: 4.12.0-3
Severity: normal
Tags: newcomer

Dear Maintainer,

i have created a file in .local/share/applications with this content:

[Desktop Entry]
Name=SeleniumServer
Icon=/home/asc/bin/selenium/icon.png
Exec=xfce4-terminal -e 'sh /home/asc/bin/selenium_start.sh'

After a restart, the menuentry was in the menubar and i added it to my
favorites. Then (i dont know the timespan or what i have done during) the
menuentry was lost in the favorites and in the whole menu. So I had restart my
XFCE and it was in the menu.
This phenomen happened since I noticed it 3 times.

Greetings A. Schröter



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

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

Versions of packages xfce4-panel depends on:
ii  exo-utils0.10.6-1
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-19
ii  libcairo21.14.2-2
ii  libdbus-1-3  1.8.20-1
ii  libdbus-glib-1-2 0.102-1
ii  libexo-1-0   0.10.6-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-4
ii  libgarcon-1-00.4.0-2
ii  libgdk-pixbuf2.0-0   2.31.5-1
ii  libglib2.0-0 2.44.1-1.1
ii  libgtk2.0-0  2.24.28-1
ii  libice6  2:1.0.9-1+b1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libsm6   2:1.2.2-1+b1
ii  libwnck222.30.7-2
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-2
ii  libxfconf-0-24.12.0-2+b1

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#798442: ITP: kraken -- assigning taxonomic labels to short DNA sequences

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: kraken
  Version : 0.10.5~beta
  Upstream Author : Derrick Wood 
* URL : http://ccb.jhu.edu/software/kraken/
* License : GPL
  Programming Lang: C++, Perl
  Description : assigning taxonomic labels to short DNA sequences
 Kraken is a system for assigning taxonomic labels to short DNA
 sequences, usually obtained through metagenomic studies. Previous
 attempts by other bioinformatics software to accomplish this task have
 often used sequence alignment or machine learning techniques that were
 quite slow, leading to the development of less sensitive but much faster
 abundance estimation programs. Kraken aims to achieve high sensitivity
 and high speed by utilizing exact alignments of k-mers and a novel
 classification algorithm.
 .
 In its fastest mode of operation, for a simulated metagenome of 100 bp
 reads, Kraken processed over 4 million reads per minute on a single
 core, over 900 times faster than Megablast and over 11 times faster than
 the abundance estimation program MetaPhlAn. Kraken's accuracy is
 comparable with Megablast, with slightly lower sensitivity and very high
 precision.


This package is maintained by the Debian Med team at
   git://anonscm.debian.org/debian-med/kraken.git

Bug#798443: new upstream (2.8.4)

[Daniel Baumann]

Package: octave-control
Severity: wishlist

Hi,

it would be nice if you could upgrade to the current upstream release
(2.8.4).

Regards,
Daniel

Bug#798341: [inkscape] impossible to install inkscape

[Mattia Rizzolo]

On Wed, Sep 09, 2015 at 10:24:28AM +0200, IOhannes m zmölnig wrote:
> On 2015-09-09 09:52, Marco Righi wrote:
> [...]
> >  inkscape : Depends: libatkmm-1.6-1 (>= 2.22.1) but it is not going to
> > be installed
> 
> in the past few weeks, Debian has seen a major transition (of the core
> components for any C++-related software in Debian) that affected *many*
> packages and included the renaming of some dependencies of inkscape.
> only within the last days, this big change started migrating from
> "unstable" to "testing".
> 
> this basically means big disruption which should eventually go away
> "automatically", once all packages have been transitioned from unstable
> to testing.

Though in a clean stretch chroot it does install.

> i also see that you are running a mixed jessie/stretch (aka
> "stable/testing") system, which i don't think is supported at all (i
> think that one of the reasons for this is exactly because it is
> impossible to support working systems that depend on a state both
> *before* and *after* such big transitions we are currently seeing).

This could very well be the cause, if it's not only the reposiotory
precence but the system is actually hibryd.

Also try with something like

# apt-get install inkscape -t testing
or
# apt-get install inkscape -t stretch

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: Digital signature

Bug#798438: procps: FTBFS: Makefile:526: recipe for target 'check-DEJAGNU' failed

[Craig Small]

On Wed, Sep 09, 2015 at 11:42:51AM +0100, Chris Lamb wrote:
> The full build log is attached or can be viewed here:
> 
> 
> https://reproducible.debian.net/logs/unstable/amd64/procps_3.3.10-4.build1.log.gz
Doesn't really help, its the ps sched test which means its something to
do with the build environment that isn't quite right.

>   === ps tests ===
> 
> Schedule of variations:
> unix
> 
> Running target unix
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
> target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
> Using ./config/unix.exp as tool-and-target-specific interface file.
> Running ./ps.test/ps_output.exp ...
> Running ./ps.test/ps_personality.exp ...
> Running ./ps.test/ps_sched_batch.exp ...
> FAIL: ps SCHED_BATCH scheduler
Any chance of getting testsuite/ps.log out of the buildds? It will give
me exactly what the tester is unhappy about.

A good run will look like this:

Running ./ps.test/ps_sched_batch.exp ...
spawn /home/csmall/Projects/procps/procps/testsuite/test-schedbatch 18
spawn /home/csmall/Projects/procps/procps/ps/pscommand --no-header -o
comm,cls,nice -a
agetty   TS   0
Xorg TS   0
make TS   0
make TS   0
bash TS   0
bash TS   0
make TS   0
make TS   0
bash TS   0
expect   TS   0
test-schedbatch   B  18
PASS: ps SCHED_BATCH scheduler
testcase ./ps.test/ps_sched_batch.exp completed in 0 seconds

-- 
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

Bug#561763: Fw: news

[Aaron Gomes]

Hello!

 

Important message, visit http://cuwide.com/speech.php?l0gl

 

Aaron Gomes

Bug#796731: freecontact: FTBFS on mips (test suite failure)

[Julien Cristau]

On Wed, Sep  9, 2015 at 09:44:30 +0200, Andreas Tille wrote:

> Hi mips porters,
> 
> could anybody please find a more powerful machine to build the rdepends
> libfreecontact-perl and python-freecontact.
> 
No, as I already said that is not acceptable.  Packages should be built
on buildds.  Reliably.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#773915: Why not upstream?

[Andreas Henriksson]

Hello Raphaël Halimi.

Thanks for your bug report and patch!

I'd like to question a conflict I see in the reasoning around
"Forwarded: not-needed".

Why should this not be forwarded upstream?
What harm would this change do upstream?
If it's not suitable for upstream, why would it be suitable for debian?

glib is a critical component which atleast me (which is not the
one deciding this) would like to avoid patching at all.
In general I also think that adding patches which will have
to be carried *forever* is something you never want to add
(unless absolutely necessary).

I think it's important to atleast have answers to these
questions on the record for the future

Regards,
Andreas Henriksson

Bug#796930: pyzmq: FTBFS with several tests error

[Andreas Beckmann]

Followup-For: Bug #796930

This problem is also reproducible in jessie.


Andreas

Bug#798432: nagios-plugins-contrib: FTBFS on arm64

[Edmund Grimley Evans]

Source: nagios-plugins-contrib
Version: 15.20150818
Tags: patch

It failed to build on arm64:

https://buildd.debian.org/status/package.php?p=nagios-plugins-contrib=sid

Just remove "!arm64" from debian/control.
--- nagios-plugins-contrib-15.20150818.orig/debian/control
+++ nagios-plugins-contrib-15.20150818/debian/control
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Debian Nagios Maintainer Group 
 Uploaders: Bernd Zeimetz , Jan Wagner , Petter Reinholdtsen 
-Build-Depends: debhelper (>= 8.0.0), python, python-debian, quilt (>= 0.46-7), dh-autoreconf, autotools-dev, flex, libmemcached-dev [!hurd-i386 !arm64], libvarnishapi-dev [!hurd-i386 !m68k], pkg-config
+Build-Depends: debhelper (>= 8.0.0), python, python-debian, quilt (>= 0.46-7), dh-autoreconf, autotools-dev, flex, libmemcached-dev [!hurd-i386], libvarnishapi-dev [!hurd-i386 !m68k], pkg-config
 Standards-Version: 3.9.6
 Vcs-Git: git://anonscm.debian.org/pkg-nagios/pkg-nagios-plugins-contrib.git
 Vcs-Browser: http://anonscm.debian.org/cgit/pkg-nagios/pkg-nagios-plugins-contrib.git

Bug#798433: qemu-system-x86: kvm's std graphical interface broken for greater one than SVGA

[Thomas Schlegel]

Package: qemu-system-x86
Version: 1:2.3+dfsg-6a
Severity: minor



-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (380, 'testing'), (110, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-20141004.86285d1-1
ii  libaio1 0.3.110-1
ii  libasound2  1.0.28-1
ii  libbluetooth3   5.23-2+b1
ii  libbrlapi0.65.2~20141018-5
ii  libc6   2.19-18+deb8u1
ii  libfdt1 1.4.0+dfsg-1
ii  libgcc1 1:4.9.2-10
ii  libglib2.0-02.42.1-1
ii  libgnutls-deb0-28   3.3.8-6+deb8u3
ii  libjpeg62-turbo 1:1.3.1-12
ii  libncurses5 5.9+20140913-1+b1
ii  libnspr42:4.10.7-1
ii  libnss3 2:3.17.2-1.1+deb8u2
ii  libnss3-1d  2:3.17.2-1.1+deb8u2
ii  libpixman-1-0   0.32.6-3
ii  libpng12-0  1.2.50-2+b2
ii  libpulse0   5.0-13
ii  libsasl2-2  2.1.26.dfsg1-13
ii  libsdl1.2debian 1.2.15-10+b1
ii  libseccomp2 2.1.1-1
ii  libspice-server10.12.5-1+b1
ii  libtinfo5   5.9+20140913-1+b1
ii  libusb-1.0-02:1.0.19-1
ii  libusbredirparser1  0.7-1
ii  libuuid12.25.2-6
ii  libvdeplug2 2.3.2+r586-1
ii  libx11-62:1.6.2-3
ii  libxen-4.4  4.4.1-9+deb8u1
ii  libxenstore3.0  4.4.1-9+deb8u1
ii  qemu-system-common  1:2.4+dfsg-1a
ii  seabios 1.7.5-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  1:2.4+dfsg-1a

Versions of packages qemu-system-x86 suggests:
ii  kmod  18-3
pn  ovmf  
pn  qemu-block-extra  
pn  samba 
pn  sgabios   
ii  vde2  2.3.2+r586-1

-- no debconf information

Desktop: xfce window-manager:  xfwm4


Since the upgrade to jessie 8.2 kvm's standard graphical Interface for > 
1024x768 broken. This package is not upgraded, but I report this error here, 
because I
have no Idea, where is the cause for this Error.

Virtual Machines (old or new installed) switch the Display not, when Display 
mode is modified to be higher.
The graphical Output contain a lot of mirror stripes.

Starting with option  " -vga vmware " shows the old behaviour. So I do that.

Thanks  Thomas

Bug#798436: odin: please make it build with vtk6 (or at least vtk-5.10)

[Gianfranco Costamagna]

Source: odin
Severity: serious
Version: 1.8.8-1
Tags: patch

Hi, I just uploaded vtk-5.10 on unstable, so your package will fail to rebuild.

rules
---with-extra-build-cxxflags="-I/usr/include/vtk-5.4 -I/usr/include/vtk-5.6 
-I/usr/include/vtk-5.8"
+--with-extra-build-cxxflags="-I/usr/include/vtk-5.4 -I/usr/include/vtk-5.6 
-I/usr/include/vtk-5.8 -I/usr/include/vtk-5.10"

vtk is also going to disappear, so if you want to keep the package for Stretch 
you will be likely need
to switch to vtk6.

cheers,

G.

Bug#798441: python-bleach: Non-determistically FTBFS due to unreliable tests

[Chris Lamb]

forwarded 798441 https://github.com/jsocol/bleach/issues/161
thanks


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#798434: ruby-sigar misbuilt with GCC 5

[Matthias Klose]

Package: ruby-sigar
Version: 0.7.2-3.1
Severity: serious
Tags: sid stretch

rebuilding ruby-sigar with GCC 5 leaves some symbols undefined, caused by the
c99 inline semantics. check with

objdump -T /usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.1.0/sigar.so |grep
sigar_skip_token

patch at
http://launchpadlibrarian.net/216747641/ruby-sigar_0.7.2-3.1build2_0.7.2-3.1ubuntu1.diff.gz

Bug#798440: New Upstream Version 2.7

[Jonas Genannt]

Package: pound
Severity: wishlist


Hello,

could you please package pound version 2.7 into debian?

If you have no time, I could help.

Thanks,
Jonas

Bug#788062: os-prober corrupts LVs/partitions while being mounted inside a VM

[Andreas Thalhammer (AIFB)]

We can confirm this Bug (Debian 8.0 Jessie on VM host and guests).

os-prober version: 1.65 amd64

VM host
=

Sep  7 14:43:19 vm-host os-prober: debug: running 
/usr/lib/os-probes/50mounted-tests on /dev/mapper/vm1-disk


Inside VM1
=
Sep  7 14:43:20 vm1 kernel: [4552906.712287] end_request: I/O error, dev 
vda, sector 5125812120



We had two out of five EXT4 VM filesystems corrupted in a single run of 
"apt-get upgrade". The filesystems automatically switched to read-only 
mode shortly after the first errors and we rebooted both VMs (fsck 
automatically enabled: orphaned inodes and some inodes had to be removed).


We regard this bug as highly critical.

Bug#798423: RFS: alien/8.95 [QA] -- convert and install rpm and other packages

[Fabiano Antunes]

Hi Giancarlo,

This is my first attempt to help on QA and it seems I couldn't have 
picked up a worse package.

I beg your pardon for the newbish mistakes.

On 09/09/2015 04:58 AM, Gianfranco Costamagna wrote:

I don't see the tarball there...
maybe you want to ask Joey to upload it?
Somehow, dch --qa automatically pushes the minor version up.  I have 
realized it just now,
by testing is again in a new directory.  Is there a way I could do the 
QA work without changing

the tarball version?

Joey has, unfortunately, stopped maintaining alien, as stated here [1].

control/rules file: why do you b-d on quilt?
I'll check it again, as it was probably a mistake made by me, but 
debuild only got _satistied_

once I did that.

vcs-git
git clone git://git.kitenet.net/alien
Cloning into 'alien'...
fatal: remote error: access denied or repository not exported: /alien


alien-8.94/debian/.pc/.quilt_patches1970-01-01 01:00:00.0 +0100

can you please strip the .pc directory? I guess it is useless.

Sure, I can.

please also if you have a native package consider to patch it directly instead 
of having separate patches.
(or a mix, like in this case)
Having two separate patches to perform two (very) distinct fixes sounded 
a good idea to me.
I'm not really sure about how to handle native packages, so I thought 
I'd better not touch it,
so that I wouldn't introduce any new bugs.  Anyways, note taken! Thank 
you! ;-)

BTW what about start maintaining it upstream too? :)
I'll think about that when I find an orphan package written in a 
programming language I'm more used to.  I promise! :)

cheers,

G.


[1] http://joeyh.name/code/alien/


Best regards,
  Fabiano Antunes.

Bug#794205: closed by Eriberto Mota <eribe...@debian.org> (reply to eribe...@debian.org) (Re: vokoscreen: does not work with ffmpeg Permission denied error)

[Eriberto]

Hi Dominik,

Do you have any news on this?

I will wait for you more 30 days...

Thanks,

Eriberto


2015-08-08 16:50 GMT-03:00 Eriberto Mota :
> reopen 794205
> severity 794205 important
> tags 794205 moreinfo
> thanks
>
>
> Done, as you wish. I look forward to receive news from you soon.
>
> Regards,
>
> Eriberto
>
>
> 2015-08-08 16:41 GMT-03:00 Dominik George :
>>>As I said, the bug was closed to avoid an unnecessary remove from
>>>testing.
>>
>> This is entirely wrong.
>>
>> Marking a bug as done is a clear statement that it was fixed. This is not 
>> true in this case.
>>
>> You could have set...
>>
>> severity -1 important
>> tags -1 + moreinfo
>>
>> ...to achieve what you claim you wanted to achieve without getting rude 
>> towards a contributor.
>>
>> -nik

Bug#798431: lvm2: OriginLV lost if CacheLV failed

[Benoit Friry]

Package: lvm2
Version: 2.02.127-1
Severity: normal

Dear Maintainer,

Context and issue
-
I want to use lvmcache to speedup access to data on RAID1.

Configuration is essentially:
 - 2 HDD in software raid1 with md -> one pv -> one VG
 - 1 SSD (/dev/sda1) is put in same VG
 - 1 of the LV is for /
 - I created a lvm cache for /

It happenned /dev/sda1 failed.  Boot failed.  I booted from Debian Live
CD, but I did not manage to repair.  lvtools and cache_check refused to
repair cmeta LV, and I did not find how to access it to try any manual
repairing.

I had to reinstall/restore. 

Reproduction

sda1 is the only partition on SSD
sde1 is the only partition on a USB key

*** LV creation
# vgcreate vgtest /dev/sda1 /dev/sde1
# lvcreate -n test -L 10G vgtest /dev/sda1
# lvcreate -n testcache -L 1G vgtest /dev/sde1
# lvcreate -n testcachemeta -L 8M vgtest /dev/sde1
# lvconvert --type cache-pool --poolmetadata vgtest/testcachemeta\
--cachemode writethrough vgtest/testcache
# lvconvert --type cache --cachepool vgtest/testcache vgtest/test

*** LV failure
# lvs -a
# lvchange -an vgtest/test
# pvremove /dev/sde1 --force --force

*** LV recovery tentatives
# lvchange -ay vgtest/test
  WARNING: Device for PV NubIyb-joYP-9Jei-Fhy3-xUuz-5SVf-3NSI0I not found or 
rejected by a filter.
  Refusing activation of partial LV vgtest/test.  Use '--activationmode 
partial' to override.
# lvchange -ay vgtest/test --activationmode partial
  PARTIAL MODE. Incomplete logical volumes will be processed.
  WARNING: Device for PV NubIyb-joYP-9Jei-Fhy3-xUuz-5SVf-3NSI0I not found or 
rejected by a filter.
  Check of pool vgtest/testcache failed (status:1). Manual repair required!
# lvchange -ay vgtest/test_corig --force --activationmode partial
  PARTIAL MODE. Incomplete logical volumes will be processed.
  WARNING: Device for PV NubIyb-joYP-9Jei-Fhy3-xUuz-5SVf-3NSI0I not found or 
rejected by a filter.
  Unable to change internal LV test_corig directly
# lvconvert -v --force --uncache vgtest/test
  WARNING: Device for PV NubIyb-joYP-9Jei-Fhy3-xUuz-5SVf-3NSI0I not found or 
rejected by a filter.
There are 1 physical volumes missing.
  Cannot change VG vgtest while PVs are missing.
  Consider vgreduce --removemissing.
There are 1 physical volumes missing.
# vgreduce -v --force --removemissing vgtest
   Finding volume group "vgtest"
  WARNING: Device for PV NubIyb-joYP-9Jei-Fhy3-xUuz-5SVf-3NSI0I not found or 
rejected by a filter.
There are 1 physical volumes missing.
There are 1 physical volumes missing.
Trying to open VG vgtest for recovery...
Found same device /dev/sda1 with same pvid SFN1I61m6AOWxnMG5YjWvjVpPuQpNLAc
  WARNING: Device for PV NubIyb-joYP-9Jei-Fhy3-xUuz-5SVf-3NSI0I not found or 
rejected by a filter.
There are 1 physical volumes missing.
There are 1 physical volumes missing.
Archiving volume group "vgtest" metadata (seqno 7).
  Removing partial LV test.
Releasing logical volume "testcache"
There are 1 physical volumes missing.
Creating volume group backup "/etc/lvm/backup/vgtest" (seqno 8).
  Logical volume "testcache" successfully removed
Releasing logical volume "test"
There are 1 physical volumes missing.
Creating volume group backup "/etc/lvm/backup/vgtest" (seqno 9).
  Logical volume "test" successfully removed
Removing PV with UUID NubIyb-joYP-9Jei-Fhy3-xUuz-5SVf-3NSI0I from VG vgtest
Creating volume group backup "/etc/lvm/backup/vgtest" (seqno 10).
  Wrote out consistent volume group vgtest

All LV is gone!

Using a cachethrough mode, OriginLV (/dev/sda1) was intact.
There must be some way to access it!


I did not find much clues on Internet. 
Best hit: https://www.redhat.com/archives/linux-lvm/2015-August/msg8.html


Best regards,
Benoit

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

Kernel: Linux 4.1.0-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
Init: systemd (via /run/systemd/system)

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.104-1
ii  dmsetup   2:1.02.104-1
ii  init-system-helpers   1.23
ii  initscripts   2.88dsf-59.2
ii  libc6 2.19-19
ii  libdevmapper-event1.02.1  2:1.02.104-1
ii  libdevmapper1.02.12:1.02.104-1
ii  liblvm2app2.2 2.02.127-1
ii  libreadline5  5.2+dfsg-3
ii  libudev1  225-1
ii  lsb-base  4.1+Debian14

lvm2 recommends no packages.

Versions of packages lvm2 suggests:
ii  thin-provisioning-tools  0.3.2-1

-- no debconf information

Bug#792096: RFP: borgbackup -- deduplicating and compressing backup program)

[Danny Edel]

On Tue, 08 Sep 2015 09:23:51 -0400 Antoine Beaupré wrote:
> 
> How does it differ from the package that Gianfranco and Marc have been
> working on? (In cc.)
> 
> A.

It doesn't necessarily "differ" in the sense that it would be a
different from-scratch packaging.  It is 95% their package, plus a few
lines in d/rules and one patch in d/patches to accomodate for the
differences between upstream git and upstream tarball.  My Idea was that
instead of just saying "regenerate those files" I wanted to add a stance
saying "and it could work somewhat like this", in order to have a
discussion on whether my Idea makes sense, and not on the basis of
whether it even works.


The only differences are:


(1) Repository layout "branch off the main repo"

I didn't use upstream tarball, but rather depended only on the git tag
(which doesn't contain the generated files I spoke of earlier, but it
contains the code to re-generate them)

Basically I followed this:

http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL


(2) Rebuilding .c and .rst.inc files

By using the upstream git directly, we can use the upstream build system
(which already calls cython and sphinx) to generate the .c sources and
the .rst.inc for the html manual.  Some environment-variable-setting in
d/rules was necessary to call the upstream docs/Makefile, to make sure
it can call "borg help COMMAND --usage-only" during the generation of
the .rst.inc files.


(3) Patch to remove travis and codecov badges

README.rst in git contains images that say "code coverage xyz%" and
"travis build [passing/failing]". I didn't think they are of relevance
to a Debian user (since they reflect current git status, not the version
installed) plus it may be a privacy concern to load external resources
when browsing the local copy of the manual.


I also think that by using upstream git directly, we get the advantage
of directly being able to use git-bisect/git-cherry-pick for identifying
and backporting fixes to the stable version, which may come in handy
later on.


Danny

Bug#788653: RFS: ktap/0.4-1 [ITP] -- lightweight script-based dynamic tracing tool for Linux

[Azat Khuzhin]

On Wed, Sep 09, 2015 at 08:07:18AM +, Gianfranco Costamagna wrote:
> 
> 
> >Hm, there is linux-headers package, why build bot can't install it?
> >vms?
> 
> 
> don't know, it doesn't install in a clean sid environment.

I think that this is because of vms.

> maybe you want to deal with the module with some runtime build, like it is 
> done with virtualbox-dkms package
> 
> otherwise you need to force the module rebuild at each kernel update, right?
> 
> I'm not sure kernel modules can be ship separately in a pre-built state
> (what happens if the user has a custom kernel?)

dkms is good idea, thanks! (I was skeptic about linux-headers at the
very beginning).
Converted and uploaded to mentors.

Cheers,
Azat.

Bug#798444: new upstream (2.4.1)

[Daniel Baumann]

Package: octave-image
Severity: wishlist

Hi,

it would be nice if you could upgrade to the current upstream release
(2.4.1).

Regards,
Daniel

Bug#790760: libreoffice: Writer becomes sluggish after pasting the filename, copied from its filesave dialog (xfce desktop)

[Chris Halls]

Hello

On 01/07/15 17:08, Daniel Thomae wrote:
> I wanted to copy the filename of one libreoffice draw-file into another.

> To reproduce the problem you can generate a new text document with 
> LibreOffice.
> After that you open the file save dialog (Strg + S) and just copy the proposed
> file name from the file save dialog. Then you close the file save dialog, you
> don't have to save the file. If you paste that copied filename into the new
> text document LibreOffice gets very sluggish and displays new written text 
> only
> with considerably delay. (At least on an 1,6 GHz AMD K8 @ AMD64)

Thanks for your description of the bug. In addition to the above steps
as mentioned, it is also necessary to have the libreoffice-gtk package
installed. I was not able to reproduce on a KDE desktop, but could
reproduce on an XFCE desktop. I've attached a backtrace.

I was able to reproduce the problem on stable and unstable (1:5.0.1-1).
But on a current build from git master, I am no longer able to reproduce
the problem. So hopefully the problem will no longer be present when 5.1
is released and packaged.

Next step: Test on 5.1 branch when packaged.

Thanks
Chris
#0  0x7fe557de653d in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fe552d84ebc in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fe552d84fcc in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fe5432cf687 in GtkData::Yield (this=0x2127650, bWait=, bHandleAllCurrentEvents=)
at 
/build/libreoffice-qBdtu7/libreoffice-5.0.1/vcl/unx/gtk/app/gtkdata.cxx:596
#4  0x7fe55b0083a3 in ImplYield (i_bAllEvents=false, i_bWait=true) at 
/build/libreoffice-qBdtu7/libreoffice-5.0.1/vcl/source/app/svapp.cxx:353
#5  Application::Yield () at 
/build/libreoffice-qBdtu7/libreoffice-5.0.1/vcl/source/app/svapp.cxx:382
#6  0x7fe55b008425 in Application::Execute () at 
/build/libreoffice-qBdtu7/libreoffice-5.0.1/vcl/source/app/svapp.cxx:336
#7  0x7fe55a11a04b in desktop::Desktop::Main (this=0x7ffd98c59c30) at 
/build/libreoffice-qBdtu7/libreoffice-5.0.1/desktop/source/app/app.cxx:1605
#8  0x7fe55b00d7b1 in ImplSVMain () at 
/build/libreoffice-qBdtu7/libreoffice-5.0.1/vcl/source/app/svmain.cxx:162
#9  0x7fe55b00d802 in SVMain () at 
/build/libreoffice-qBdtu7/libreoffice-5.0.1/vcl/source/app/svmain.cxx:196
#10 0x7fe55a137b72 in soffice_main () at 
/build/libreoffice-qBdtu7/libreoffice-5.0.1/desktop/source/app/sofficemain.cxx:96
#11 0x004006fb in sal_main () at 
/build/libreoffice-qBdtu7/libreoffice-5.0.1/desktop/source/app/main.c:48
#12 main (argc=, argv=) at 
/build/libreoffice-qBdtu7/libreoffice-5.0.1/desktop/source/app/main.c:47

Bug#795396: [Aptitude-devel] Bug#795396: Bug#795396: aptitude: DEBIAN_FRONTEND does not affect the debconf invoked by "aptitude

[Manuel A. Fernandez Montecelo]

Control: reassign -1 debconf

Note for debconf maintainers: I am reassigning because this doesn't
seem to have anything to do with aptitude, so hopefully you will know
if this is a matter concerning debconf or hopefully could point in the
right direction.


2015-09-09 3:25 GMT+01:00 Karl O. Pinc :
> On Mon, 7 Sep 2015 22:23:16 +0100
> "Manuel A. Fernandez Montecelo"  wrote:
>
>> 2015-09-06 20:12 Karl O. Pinc:
>> >On Sun, 6 Sep 2015 16:15:56 +0100
>> >"Manuel A. Fernandez Montecelo"  wrote:
>> >
>> >> Also, what does happen if you use apt-get instead?
>> >
>> >I don't know.  It's not clear to me how to create
>> >a test environment to reproduce the problem.  It requires
>> >that an installed package get an update put into a repo
>> >and that the update makes changes to a user-modifed
>> >config file (right?) so that debconf is invoked when
>> >the update is installed.
>>
>> Perhaps it also work installing some package that you don't need, but
>> it is harmless, and know for sure that uses debconf?
>
> I don't think that installing is going to reproduce the
> problem -- it's on upgrade that debconf really wants
> to ask questions when a new config is incompatible with
> a user-modified config.

I see, I thought that it was happening with any debconf question,
that's why I thuoght that installing any new package would do.


> Per a suggestion on IRC #debian I tried (because I saw
> the problem with apache2):
>
> dpkg-i \
>  /var/cache/apt/archives/apache2_2.4.10-10+deb8u1_i386.deb \
>  /var/cache/apt/archives/apache2-bin_2.4.10-10+deb8u1_i386.deb \
>  /var/cache/apt/archives ^M/apache2-data_2.4.10-10+deb8u1_all.deb
>
> I believe this would get me back to the version which, on upgrade,
> I saw the problem.  But I could not reproduce the problem.
>
> My current apache2 version is: 2.4.10-10+deb8u3
>
> Note that the apache2 changelog says:
>
> apache2 (2.4.10-10+deb8u2) jessie; urgency=medium
>
>   [ Stefan Fritsch ]
>   * Fix upgrade logic: When upgrading from wheezy with apache2.2-common
> but without apache2 installed to jessie, part of the conffile
>   handling logic would not run, causing outdated conffile content to be
>   kept. This is part of the solution for bug #794933. The other part
>   will be included in the upgrade to Debian 9 (stretch).
> 
>  -- Stefan Fritsch   Thu, 27 Aug 2015 19:52:37 +0200
>
> Seems to me that whatever fix was made to the upgrade logic
> is what triggered the problem, but that's a guess.
>
>
>> If you cannot test with the suggestion above, I think that it's better
>> to reassign to debconf package itself, let me know if you want me to
>> do this.
>
> Since I'm kinda stuck reproducing the problem I think you'd
> better reassign this to the debconf package.  Maybe they'll
> be able to help.

As I said above, reassigned now.


> For the sake of completeness I've found the log output
> which prompted this report.  It
> dates to: Sun,  2 Aug 2015 06:26:00 -0500 (CDT)
>
> (Now you know what the problem looks like.  :-)
>
> (FYI: Although aptitude is being invoked with --quiet=2
> it's outputting it's dynamic progress report.  A change
> from Wheezy and something I should put into another
> bug report.)

"Reading database" is a message from dpkg, not aptitude, and although
in some cases aptitude calls dpkg directly, I think that in this case
this call is made from apt (so the chain is aptitude->apt->dpkg).  We
do not have facilities to pass "verboseness/quietness" down the chain.

So to report this, dpkg is a better place, I think; I suppose that it
would better not print the progress when the terminal cannot handle
updating lines.


> -
> The following packages will be upgraded:
>   apache2 apache2-bin apache2-data apache2-mpm-prefork apache2-utils
>   libicu52
> 6 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 8,384 kB of archives. After unpacking 7,168 B will be freed.
> (Reading database ...
> (Reading database ... 5%
> (Reading database ... 10%
> (Reading database ... 15%
> (Reading database ... 20%
> (Reading database ... 25%
> (Reading database ... 30%
> (Reading database ... 35%
> (Reading database ... 40%
> (Reading database ... 45%
> (Reading database ... 50%
> (Reading database ... 55%
> (Reading database ... 60%
> (Reading database ... 65%
> (Reading database ... 70%
> (Reading database ... 75%
> (Reading database ... 80%
> (Reading database ... 85%
> (Reading database ... 90%
> (Reading database ... 95%
> (Reading database ... 100%
> (Reading database ... 86260 files and directories currently installed.)
> Preparing to
> unpack .../apache2-mpm-prefork_2.4.10-10+deb8u1_amd64.deb ... Unpacking
> apache2-mpm-prefork (2.4.10-10+deb8u1) over (2.4.10-10) ... Preparing
> to unpack .../apache2_2.4.10-10+deb8u1_amd64.deb ... Unpacking apache2
> (2.4.10-10+deb8u1) over (2.4.10-10) ... Preparing to
> 

Bug#798392: [rt.debian.org #5965] AutoReply: Please add Mechtilde Stehmann's key to the DM keyring

[Aníbal Monsalve Salazar]

Control: package debian-maintainers
Control: tags -1 + pending

Hello Mechtilde Stehmann,

Your DM application was accepted and the corresponding RT ticket is
posted at https://rt.debian.org/Ticket/Display.html?id=5965

Currently, rt.debian.org isn't accessible for the general public. It
was sometime ago. Maybe one of your advocates will look at your RT
ticket for you, after it has been taken by a keyring maintainer. See
http://wiki.debian.org/rt.debian.org

Thank you for your contribution to the Debian Project.

Cheers,

Aníbal

On Wed, 2015-09-09 09:17:33 +, Debian Keyring requests (Incoming) via RT 
wrote:
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding
>
>   "Please add Mechtilde Stehmann's key to the DM keyring",
>
> a summary of which appears below the dashed line.
>
> There is no need to reply to this message right now.  Your ticket has
> been assigned an ID of [rt.debian.org #5965].
>
> Please include the string
>
>   [rt.debian.org #5965]
>
> in the subject line of all future correspondence about this issue. To
> do so, you may reply to this message.
>
> -
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> keyring-maint:
>   please add key ID F0E37F3DC87A4998289939E7F2877BBA141AAD7F
> to the DM keyring
>   please notify 798392-d...@bugs.debian.org
> 
> Changed-By: Anibal Monsalve Salazar 
> Date: Wed, 09 Sep 2015 08:47:40 +
> BTS: http://bugs.debian.org/798392
> Agreement: https://lists.debian.org/debian-newmaint/2015/08/msg00035.html
> Advocates: 
>   abe - https://lists.debian.org/debian-newmaint/2015/08/msg00038.html
> Comment: Add Mechtilde Stehmann  as a Debian Maintainer
> KeyCheck:
>   pub   4096R/141AAD7F 2013-09-06
> Key fingerprint = F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
>   uid  Mechtilde Stehmann 
>   sig! 2442 2013-12-15  Helmut Grohne 
>   sig! 0B86B067 2014-03-14  Joost E. van Baal (Nederland, 1970)
>   sig! 9DE23B16 2014-03-15  Alexander Wirt 
>   sig! 612616B5 2014-08-23  Axel Beckert 
>   sig! D8C19BEC 2014-10-26  Geert Stappers 
>   sig! 333961E8 2014-11-09  Evgeni Golov (Grml) 
>   sig! 4687AF4F 2014-11-09  Toni Mueller 
>   sig! D03E3E70 2014-10-13  Rene Engelhard
>   sig! 558FB8DD 2014-03-16  Jan Dittberner 
>   sig!3141AAD7F 2013-09-08  Mechtilde Stehmann 
>   sig!3141AAD7F 2014-02-09  Mechtilde Stehmann 
>   uid  Mechtilde Stehmann 
>   sig! 2442 2013-12-15  Helmut Grohne 
>   sig! 0B86B067 2014-03-14  Joost E. van Baal (Nederland, 1970)
>   sig! 9DE23B16 2014-03-15  Alexander Wirt 
>   sig! D8C19BEC 2014-10-26  Geert Stappers 
>   sig! 333961E8 2014-11-09  Evgeni Golov (Grml) 
>   sig! 4687AF4F 2014-11-09  Toni Mueller 
>   sig! D03E3E70 2014-10-13  Rene Engelhard
>   sig!3141AAD7F 2013-09-08  Mechtilde Stehmann 
>   sig!3141AAD7F 2013-09-08  Mechtilde Stehmann 
>   uid  Mechtilde Stehmann 
>   sig! 0B86B067 2014-03-14  Joost E. van Baal (Nederland, 1970)
>   sig! 9DE23B16 2014-03-15  Alexander Wirt 
>   sig! 612616B5 2014-08-23  Axel Beckert 
>   sig! D8C19BEC 2014-10-26  Geert Stappers 
>   sig! 4687AF4F 2014-11-09  Toni Mueller 
>   sig! D03E3E70 2014-10-13  Rene Engelhard
>   sig!3141AAD7F 2014-02-09  Mechtilde Stehmann 
>   sub   4096R/CC4D5253 2013-09-06
>   sig! 141AAD7F 2013-09-06  Mechtilde Stehmann 
>   .
>   Key is OpenPGP version 4 or greater.
>   Key has 4096 bits.
>   Valid "e" flag, no expiration.
>   Valid "s" flag, no expiration.
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAEBCgAGBQJV7/YkAAoJEHxWrP6UeJfYmwgP/AhnJrdksJWuV52WtWPM7LqK
> LxnpmPBOQMo/Jn5P+fZ5prWIom9QWnII3OdfTBeZ7V5631jl19NQ2CJuP/9ngGkU
> dlqh5Q4aSJJikZKTw2iFrUKWBQBGLcjxzigyOV/+lwtd+oiW7FiXe4BvoAotrpB8
> h/LGdkUnz5d3PwjnOHNTNR+PHhDOv4eKh++NUFIbl+01JuZ/y726qNBlMwhQA+8C
> 0Rqa190LD/O9/z4B65a2EXFf+8Z3S5CSJ5ybyL7Jqyqa6OZ7yxpXt9GAXdj7HtDs
> n18zpcpf1xcGWykcvyLbXmn/vqTyQRt/ZDCE4tuIjg8zB9m6qdN1YCU5LdGlrcvH
> mf9UeuZ8IeMsWS8uS8dmWiQIMcnNQutUZmGeIVCOrmw1ETpz+7TFvsGX4wmU2q5o
> ihHAq9vEczhNnwiBv1nqJqlBnoTSkxVrDDiF53U4YHn8sGE2QIj3ylTVPdv6ewlX
> 3zhtDmXFfl37JohevRfxle6hlWxp8Wqduvzs2oWaFwKIlp3JdXoVHdmk2MHqSkDZ
> 

Bug#798429: ftp.debian.org: Reject messages about source-only uploads should be more informative

[Santiago Vila]

Package: ftp.debian.org

This is related to Bug #798413 and it's also quite "kafkian".

I did a source-only upload and it was REJECTED with a message like this:


Source-only uploads to NEW are not allowed.

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


When the upload is not source-only and it's not immediately accepted
for the same reason (i.e. requiring NEW processing), the message is
like this:


binary:ekg2-api-docs is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.
[...]


Omitting long explanations about how the NEW queue works is ok, but at
the very minimum, the uploader should be told about *what* part of the
upload is considered to be NEW.

Thanks.

Bug#792144: RFS: cunit/2.1-2.dfsg-3 -- Unit Testing Library for C [ITA]

[a3at.m...@gmail.com]

On Wed, Sep 09, 2015 at 08:59:26AM +, Gianfranco Costamagna wrote:
> Hi, I'm referring to:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792144#54

Hm, I thought that I dropped autoconf from B-D, but seems that this was
in some separate branch, anyway fixed that now.

As for *.css, I think I will leave this as-is for now, since I don't
sure about html/headers.

> and (sorry for that I forgot to send the mail)
> to the need to mark the package as multiarch where needed
> https://wiki.debian.org/Multiarch/Implementation
> 
> 
> also, please rebase the changelog into one entry.
> (I mean, there is no need to have
> +cunit (2.1-3-dfsg1) unstable; urgency=medium
> 
> +cunit (2.1-2.dfsg-3) unstable; urgency=medium
> 
> 
> the first one is enough, since the second never appeared on Debian.

Yep, done (including debian/NEWS).

New package uploaded to mentors.

Thanks,
Azat.

Bug#798248: [PATCH] Fix test-suite failure on Alpha

[Michael Cree]

Pulseaudio fails to build on the Alpha architecture due to a failure
in the volume-test of the test suite.  I had reported this to the
Debian bug tracker [1] but the maintainer has asked that I forward the
patch to this mail list.  The failure in volume-test occurs because it
is compiled with -ffast-math which implies -ffinite-math-only of which
the gcc manual states that it optimizes for floating-point arithmetic
with the assumption that arguments and results are not NaNs or
+/-infinity, and futher notes that it may result in incorrect output.
On the Alpha platform that is somewhat an understatement as the use of
non-finite floating-point arithmetic with -ffinite-math-only results in
a floating-point exception and the termination of the program.

The volume-test converts volumes into decibels (so a zero volume
becomes a negative infinity) and proceeds to add two volumes (in
decibels), thus does arithmetic with non-finite floating point numbers
despite being compiled with -ffast-math!

I attach a patch that protects against the arithmetic with non-finite
numbers for your consideration.  With that patch the test-suite passes
on Alpha.

Cheers
Michael.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798248
Index: pulseaudio-6.0/src/tests/volume-test.c
===
--- pulseaudio-6.0.orig/src/tests/volume-test.c
+++ pulseaudio-6.0/src/tests/volume-test.c
@@ -114,7 +114,10 @@ START_TEST (volume_test) {
 double q, qq;
 
 p = pa_sw_volume_multiply(v, w);
-qq = db + db2;
+	if (isfinite(db) && isfinite(db2))
+		qq = db + db2;
+	else
+		qq = -INFINITY;
 p2 = pa_sw_volume_from_dB(qq);
 q = l*t;
 p1 = pa_sw_volume_from_linear(q);

Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default

[Daniel Glassey]

Oops, didn't change that before I committed. No, this is for unstable for the 
transition.

Thanks,
Daniel

On Wed, Sep 09, 2015 at 04:43:35AM -0400, Roberto C. Sánchez wrote:
> Of course.  The upload is meant for experimental like -3.  Correct?
> 
> Regards,
> 
> -Roberto
> 
> On Wed, Sep 09, 2015 at 09:33:03AM +0100, Daniel Glassey wrote:
> > On Wed, Sep 09, 2015 at 04:08:25AM -0400, Roberto C. Sánchez wrote:
> > > Do you want me to go ahead with uploading -3 as is then?
> > 
> > No need, could you just git-buildpackage build and tag -4 ?
> > 
> > Thanks,
> > Daniel
> > 
> 
> -- 
> Roberto C. Sánchez




signature.asc
Description: Digital signature

Bug#717313: lvm2: Enable issue_discards = 1 automatically on non-rotational (SSD) disks?

[Petter Reinholdtsen]

[Martin Pitt 2013-12-13]
> The documentation says that the option has no effect if the kernel or
> the drive don't support it, so I don't see why we shouldn't just
> enable this by default?

Right.  Then perhaps the Debian maintainers of lvm2 can change the
default, to make Debian better for us with SSD disks by default?

This issue received no comment from the lvm2 maintainers for more than
two years, and I wonder what can be done about it?  Anyone got any idea
about the best approach?

> I attach the Ubuntu debdiff for reference, although it's fairly
> trivial.

Right, so the change has been tested in Ubuntu for two years.  Time to
merge into Debian?

-- 
Happy hacking
Petter Reinholdtsen

Bug#710587: [Aptitude-devel] Bug#710587: aptitude: unable to purge a package

[Manuel A. Fernandez Montecelo]

2015-09-09 7:07 GMT+01:00 David Kalnischkies :
> On Tue, Sep 08, 2015 at 03:40:20PM +0100, Manuel A. Fernandez Montecelo wrote:
>> Is this with multi-arch enabled?  gnotski is now a transitional package,
>> arch all, added on 25 May 2013 (very close to when the bug report
>> happened), it must have been arch-dependent before.
> […]
>> So I am not sure about what was wrong at the time, but I think that this
>> bug is not present anymore.
>
> This sounds like this bug:
> https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=016bea8214e1826b289025f03890f70a5805db87
> Note that it is only in /experimental, so with /unstable it should be
> reproducible if its really this issue.

Thanks for the input, David.  I also think that this is the cause of
this bug report.

In experimental... do you mean that it's been only added in apt-1.1,
never released to unstable yet?  By the date I thought that it made it
to the last stable release, Jessie.  Or is it one of these changes
that you requested but weren't approved by the release team?


In any case, after this information, I don't know if we should reopen
this or not.

The original systems where this was found already changed state, and
at least in one they use unstable and experimental.  The last report
was in in 2014, more than a year ago, and the submitters didn't
consider this a problem anymore (so I assume that it got fixed in
their system somehow, possibly because they use the experimental
versions; or maybe they purged by hand by dpkg and forgot about it,
or...).

If I  try to reproduce it and confirm the behaviour, and we suppose
that it was the same as the original problem (sounds like it, with the
package converted to an arch:all meta-package), then we must conclude
that it was an apt bug and reassign... but you already know and fixed
this, so other than for neat bookeeping, it's of not much use.  (But
if you want to steal the bug report from us, fine for me :-) ).

If we suppose that it was or /could be/ a different problem, and leave
the bug open just in case, but do not get more input from the
submitters, we will never actually confirm if that was the bug that
they hit or if it was another different condition.  And in practice, I
imagine that it will happen like other bugs: not be addressed for
years until we close it anyway.

I think that it's better to leave it closed, but is is good to confirm
that this issue was very likely the cause behind it.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#798305: Old Yuandaocn N101-II table also doesn't recognised by version 1.0.31

[Oleksandr Gavenko]

  bash# adb --help
  Android Debug Bridge version 1.0.31

  bash# adb devices
  * daemon not running. starting it now on port 5037 *
  * daemon started successfully *
  List of devices attached 

  bash# pkill adb

  bash# /opt/android-sdk-linux/platform-tools/adb
  Android Debug Bridge version 1.0.32
  Revision 57224c5cff69-android

  bash# /opt/android-sdk-linux/platform-tools/adb devices
  List of devices attached
  * daemon not running. starting it now on port 5037 *
  * daemon started successfully *
  0123456789ABCDEFdevice

My device uses CyanogenMod 10.1 on Android 4.2.2 (September 2013).

Package updating is very suggested.

-- 
Best regards!

Bug#797926: transition: openssl: remove SSLv3 methods

[Kurt Roeckx]

On Thu, Sep 03, 2015 at 10:36:33PM +0100, Jonathan Wiltshire wrote:
> > So do I start with an soname change and upload that to
> > experimental?
> 
> Yes please.

So that has passed the new queue now.  Please let me know when I
can start this in unstable.


Kurt

Bug#798437: [simple-image-reducer] EXIF library not found

[Marco Righi]

Package: simple-image-reducer
Version: 1.0.2-1
Severity: grave

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

Command 504 of 8 $LC_ALL=C.UTF-8 simple-image-reducer
Traceback (most recent call last):
  File "/usr/bin/simple-image-reducer", line 29, in 
import EXIF
ImportError: No module named EXIF


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

Debian Release: stretch/sid
  500 testing-updates ftp.fr.debian.org
  500 testing www.deb-multimedia.org
  500 testing security.debian.org
  500 testing ftp.fr.debian.org
  500 testing apt.jenslody.de
  500 stable-updates  ftp.it.debian.org
  500 stable  security.debian.org
  500 stable  repo.wuala.com
  500 stable  ftp.it.debian.org
  500 stable  dl.google.com
  500 stable  apt.spideroak.com
  500 jessie  linux.dropbox.com
  500 debian  packages.linuxmint.com
  100 jessie-backports ftp.it.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-===
python| 2.7.9-1
python-exif   | 2.1.1-2
python-imaging| 2.9.0-1
python-gtk2   | 2.24.0-4


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#798433: qemu-system-x86: kvm's std graphical interface broken for greater one than SVGA

[Michael Tokarev]

Control: tag -1 + moreinfo

09.09.2015 13:16, Thomas Schlegel wrote:
> Package: qemu-system-x86
> Version: 1:2.3+dfsg-6a
> Severity: minor
> 
> Debian Release: 8.2

> Since the upgrade to jessie 8.2 kvm's standard graphical Interface for > 
> 1024x768 broken. This package is not upgraded, but I report this error here, 
> because I
> have no Idea, where is the cause for this Error.

qemu on jessie is of version 2.1.  You're reporting the bug against version 
2.3, but say
that qemu on your machine is not upgraded.  Please specify on which version of 
qemu-system-x86
you observe this behavour, and what version of seabios package do you have.

> Virtual Machines (old or new installed) switch the Display not, when Display 
> mode is modified to be higher.
> The graphical Output contain a lot of mirror stripes.

I can't confirm this behavour, on any version of qemu I have ready to install, 
which covers versions from
1.7 up to 2.4.  Tried two guests, windows7 and linux, both shows normal output 
with several screen resolutions
higher than 1024x768.

Please show details about your guest(s) which demonstrates this bad behavour.

Thanks,

/mjt