Bug#734471: libjs-slimbox: Please update the package to the newest upstream version

[Louis-David Mitterrand]

Package: libjs-slimbox
Version: 2.04-1
Followup-For: Bug #734471

Actually this bug should no longer be wishlist as there are
compatibility issues between slimbox 2.04 and jquery 1.9+: dark overlay
in front of images for examle.

We need 2.05 in debian please!

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

Kernel: Linux 4.0.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

libjs-slimbox depends on no packages.

Versions of packages libjs-slimbox recommends:
ii  javascript-common  11

libjs-slimbox suggests no packages.

-- no debconf information

Bug#787724: Confirmed

[Paolo Cavallini]

Confirmed here, with several different repos:
Ign http://ftp.no.debian.org jessie
InRelease/partial/ftp.no.debian.org_debian_dists_jessie_InRelease into
data and signature failed
Fetched 2,823 B in 9s (307 B/s)
E: GPG error: http://ftp.no.debian.org jessie InRelease: Clearsigned
file isn't valid, got 'NODATA' (does the network require authentication?)
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

Bug#798004: xletters: Non-standard charset makes some characters untypeable and wrongly displayed.

[chill3]

Package: xletters
Version: 1.1.1-4.1
Severity: important
Tags: l10n

Dear Maintainer,

I've installed xletters in Spanish, but, due to an incorrect charset probably
on the translation, the characters on the upper half of the ASCII character
table don't display correctly.

For each character on that half, the program displayed two characters, so I
suppose the translation table was encoded in UTF-8 but displayed as it was ANSI
or another similar charset. Changing the font didn't work.

The words come from /usr/share/dict/spanish at the 'wspanish' package. Please
patch the program so it supports UTF-8 encoding.

Thank you for your attention.


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

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

Versions of packages xletters depends on:
ii  libc62.19-18
ii  libice6  2:1.0.9-1+b1
ii  libsm6   2:1.2.2-1+b1
ii  libx11-6 2:1.6.2-3
ii  libxaw7  2:1.0.12-2+b1
ii  libxext6 2:1.3.3-1
ii  libxt6   1:1.1.4-1+b1
ii  netcat-traditional [netcat]  1.10-41
ii  wamerican [wordlist] 7.1-1
ii  wspanish [wordlist]  1.0.27

xletters recommends no packages.

xletters suggests no packages.

-- no debconf information

Bug#597172: ITP: panda3d -- Panda3D is a game engine, a framework for 3D rendering and game development for Python and C++ programs.

[Jörn Schönyan]

Owner: joern.schoen...@web.de

Bug#798011: bugs.debian.org: Please add severity in a new X-Debian-PR-Severity mail header field

[Raphaël Hertzog]

Package: bugs.debian.org
Severity: wishlist

Hello Don,

I would like to work on a new feature for tracker.debian.org so that
people can subscribe only to RC bugs of packages they care about (that
they don't want to see removed from testing/Debian)... but to implement
this I need to know the severity of each bug.

I could rely on the SOAP interface and maintain a copy of this information
on my side but I believe that it would be much more effective if the BTS
did inject that information as a new mail header. It already has this for
"tags" and it would seem natural to add the severity in the same way...

Example:

X-Debian-PR-Message: closed 784766
X-Debian-PR-Package: libadios-dev
X-Debian-PR-Keywords: sid stretch
X-Debian-PR-Source: adios
X-Debian-PR-Severity: serious

Thank you in advance for your help!

Raphaël Hertzog,
  tracker.debian.org maintainer.

Bug#754659: Some actions destroy backlite on Lenovo X61s

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Do den  3. Sep 2015 um 23:35 schrieb Santiago Vila:
> luakit is just a web browser and has no direct access to hardware by itself.

That might be. But I never ever seen that problem with other software.

It seems to be an only problem of luakit. And will not start it again on
my laptop as this is destroying the hardware(!)

Regards
   Klaus
- -- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQGcBAEBCgAGBQJV6VYeAAoJEKZ8CrGAGfasu60MAJWJZqSv75WQxWoN8H+T8Wxf
8glCrYYyoztNk+XhcOX9EOBjS8+JyaAhvzMPUDXcbAErav/X2/94DRkq8PcWWQL2
zO56gtASm8YTQJ1cF1/Nvnta3EfYq3apUPVpt+CGtS6p3h083RxytgX/+JiXbJ1b
7hnz0nRQbm3axdmEyLHxslyIbs+v+s0aMX6EdQdYhXqtvUvF9GMe8gQrrPYb9skQ
RffecjouvJ2ymK9UNWMbWmpkyNI5qJWNttxA5V866oWl7u4oaTpsgYiWHHW2mIiH
I8p4cnlTMfbTWGLo8YhrFQVk5YqH/p83Bqxp/ceABs1/J+sVLtrs4810zUN6DCFV
HFjqPn6MJ3rcgsVLtCpnha6E1MQn6yqU1lvD4REhBZpDQzczJEPrtWDctMC2v53k
l+fP9JTKIKn/JcEU0Wj4yeTjWSb/ALeTaRJc4GLXFdlkMquPVsmftDNuPRXhbPcC
qUeFAQ/HbnZENQTNjxHXoZ3wYe5woKrkwkDbgMGOAQ==
=ISGG
-END PGP SIGNATURE-

Bug#797994: synfig: ABI transition needed for libstdc++ v5

[Simon McVittie]

Source: synfig
Version: 1.0-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 synfig, std::string appears in functions in public
headers, so it seems very likely that a transition is needed.
The transition normally consists of renaming the
affected library packages, adding a v5 suffix (libsynfig0v5).
The actual 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. However, please avoid doing this unless the new upstream version
is very low-risk: the libstdc++ transition has stalled development in
unstable for long enough already.

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

* boost has already been renamed
* etl seems to be header-only so does not need a transition
* libmagick++ has already been renamed
* libmlt++ is not believed to need a transition (but please check)

so I think this sub-transition may be ready.

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

Bug#795288: nmu: libsigc++-2.0_2.4.1-2

[Edmund Grimley Evans]

To reproduce the problem:

wget 
https://sources.debian.net/data/main/s/synfigstudio/1.0-1/images/animate_mode_icons.sif
synfig -q animate_mode_icons.sif -o animate_mode_off_iconxx.png --time 0

Replacing /usr/lib/aarch64-linux-gnu/libsigc-2.0.so.0.0.0 with file
from rebuilt libsigc++-2.0 fixes it.

Bug#798001: FOTAQ: please provide French,German,Hebrew & Italian versions

[Alexandre Detiste]

Package: flight-of-the-amazon-queen
Version: 1.0.0-8
Severity: wishlist

FOTAQ - like the other free games BASS, Dracula & Lure
of the Temptress - has been dubbed in various languages;
but only the English version is shipped in Debian.

I thought of adding it as a definition to game-data-packager
( #783925 ) but I now realize this is a bad idea for
various reasons:
- the English version would be in main; but the
  other versions that are licensed the same way
  would require some tool in contrib.
- even after installing the correct dubbed packages;
  "queen --de" or "queen --fr" wouldn't work
- this whole setup would have poor usability and
  would require a lot of documentation


I propose this:

A small 'flight-of-the-amazon-queen' packages that only hold
the .desktop file, launcher & man pages and that depends
on "flight-of-the-amazon-queen-en | flight-of-the-amazon-queen-de
 | flight-of-the-amazon-queen-fr | flight-of-the-amazon-queen-he
 | flight-of-the-amazon-queen-it".

Each of flight-of-the-amazon-queen-## would only
hold a diffrente 'queen.1c' file.

The launcher woudl then pick the best fitting language;
in a way similar to /usr/games/drascula:

http://anonscm.debian.org/cgit/pkg-games/drascula.git/tree/debian/bin/drascula#n32

If you agree with these changes; I can provide a patch.


Cheers,


Game assets:
http://scummvm.org/games/


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux testing/unstable
Release:testing/unstable
Codename:   n/a
Architecture: armv7l

Kernel: Linux 3.18.11-v7+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#766884: libxml2 broken in sid for months already

[Aron Xu]

Control: severity 766884 serious

Please don't change the severity level and no ping-pong game please.

On Thu, Sep 3, 2015 at 3:47 PM, Raphael Hertzog  wrote:
> Control: severity 766884 important
>
> Hi Aron,
>
> please keep me in copy as I'm not subscribed to
> debian-xml-sgml-p...@lists.alioth.debian.org... I just discovered your
> reply by chance.
>
> On Mon, 31 Aug 2015, Aron Xu wrote:
>> Let's reopen #766884 for tracking, it's not really fixed, but just
>> avoided. Unfortunately #781232 is opened. I would like to block this
>> version to testing as it's not the proper way of fixing the problem
>> (but it is indeed the most straightforward way of avoiding it).
>
> Why don't you want to let this version in testing?
>
> The release team has made it clear that they prefer to have the same
> version in unstable and in testing... and the version in unstable is not
> worse than the version in testing.
>

It's not a reason that you just revert back to an older version
because it's easy to do so. If you want to make it the same version,
choose the harder but more correct way as libxml2 is not a trivial
package with low impact.

>> The proper way of working this bug around would be bisecting and
>> patching which is quite time consuming. I haven't yet managed to get
>> it done and help is welcomed, but if no one step up I'll do it
>> eventually (or cross finger for finding a proper fix, :D).
>
> Someone already did this that in the upstream bug tracker:
> https://bugzilla.gnome.org/show_bug.cgi?id=737840
>
> So if you want you can try to revert this commit:
> https://git.gnome.org/browse/libxml2/commit/?id=a16eb968075a82ec33b2c1e77db8909a35b44620
>
> But Daniel Veillard made it clear that this commit
> was not at fault, it was only making the problem visible:
> https://bugzilla.gnome.org/show_bug.cgi?id=737840#c2
>
> So yes, maybe switching to 1.9.2 and reverting this
> one would be better until a proper fix is available.
>

Yep.

> But this bug should not prevent the migration of the package to testing
> since the package in sid does not exhibit the problem currently. So
> I'm reducing its severity to important in particular since you do not seem
> to want to close it until a proper fix is available upstream.
>

I don't want to close it, nor I want make this version to testing, so
please don't lower the severity, as said above.

> I just added another commit on request of Julien Cristau.  Whatever you
> decide, you need to make a new upload so that the "icu" migration can be
> completed in unstable.
>

Thanks for that, :)

Cheers,
Aron

> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get/

Bug#798000: ftp.debian.org: please allow discarding maintainer-built binaries after NEW

[Simon McVittie]

Package: ftp.debian.org
Severity: wishlist

In general we have been able to make all+source uploads for a while, and
pure source uploads are now also allowed (a huge step in the right
direction - thanks for doing that). However, the ftp team have indicated
that they still want to see maintainer-built binaries in NEW uploads, so
that they can see whether the new packages make sense.

By the time NEW binary or source packages are approved, the built binaries
are reasonably likely to be out of date, which can disrupt transitions.
For example, osrm was built against untransitioned libstxxl, uploaded
to NEW, and later accepted ; if it had
been rebuilt on all architectures, it would have been built with the
new libstxxl everywhere.

It would be great if uploads accepted from NEW could discard the
maintainer-built binaries and build the package on the buildds instead,
at least optionally. There might need to be an "escape hatch" by which
maintainers *can* provide binaries that will be kept, if the package is
difficult to build, or legally or technically incompatible with buildds
(like some contrib and non-free packages). In particular, some packages
FTBFS with dpkg-buildpackage -A (arch-indep only) but work with -b
(arch-dep + arch-indep), so retaining _all binaries might be useful
for those, until all such packages have been fixed.

I think this should perhaps be a slightly higher priority than discarding
maintainer-built binaries for non-NEW uploads, because the delay
inherent in NEW review makes it more likely that the maintainer's
binaries do not closely resemble the buildds' binaries.

S

Bug#766884: libxml2 broken in sid for months already

[Raphael Hertzog]

Hello,

On Fri, 04 Sep 2015, Aron Xu wrote:
> It's not a reason that you just revert back to an older version
> because it's easy to do so. If you want to make it the same version,
> choose the harder but more correct way as libxml2 is not a trivial
> package with low impact.

Hey, don't give me lessons. I'm not the libxml2 maintainer who left
#766884 unattended since october last year...

And I announced my plans in the bug report and I had no response from
you until a few days ago.

I did not pick an easy solution, mind you, I spent multiple hours to
prepare the upload as I had to re-introduce patches that you did
push through via a testing-proposed-updades upload.

I did that because I believe that this was the correct course of action
given the lack of proper fix upsream, not because it was an easy solution.

Adding a single patch to revert the change that triggered the bug would
have been easier and in retrospect, it's probably what I should have done.
But even then it's just hiding the bug under the carpet. The real bug
is still waiting to be fixed...

> > But this bug should not prevent the migration of the package to testing
> > since the package in sid does not exhibit the problem currently. So
> > I'm reducing its severity to important in particular since you do not seem
> > to want to close it until a proper fix is available upstream.
> 
> I don't want to close it, nor I want make this version to testing, so
> please don't lower the severity, as said above.

Why don't you want this version into testing?

That doesn't forbid you to push 2.9.2 with the problematic commit reverted
later on. And have this one reach testing too.

Anything that is in unstable should go into testing, otherwise you should
use experimental.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#797980: kdevelop: Missing .so file in kdevelop.install

[张敬强]

> usr/lib/libkdevcompilerprovider.so should be added to kdevelop.install file,
> without which KDevDefinesAndIncludesManager won't work.
This plugin crash kdevelop now, but it did work before the gcc 5 transition.
I will test latest official 4.7 branch. 
  

Bug#796827: mothur: watch file is outdated, new releases are missed

[Andreas Tille]

Just a quick note since I'm close to offline the next 24h:

   http://debian-med.alioth.debian.org/docs/policy.html

Should explain what to do.  Please ask for membership in
Debian Med team on alioth.

Kind regards

  Andreas.

On Fri, Sep 04, 2015 at 10:42:51AM +0200, Tomasz Buchert wrote:
> Hi Andreas,
> this is what I got:
> 
>https://anonscm.debian.org/cgit/users/tomasz/mothur.git
> 
> I didn't know how to use the current packaging repo, so I recreated
> gbp repo from the scratch. Please point me to how I should reapply my
> changes in the official repo.
> 
> Anyway, it seems to build fine, I fixed/improved many things, hopefully
> without breaking anything. It takes ages to compile (since two builds
> are necessary!), so I also documented the use of ccache.
> 
> There are 11 patches in the queue now: we should really push at least
> some of them upstream.
> 
> Please review/comment.
> 
> Cheers,
> Tomasz



-- 
http://fam-tille.de

Bug#782054: mbsync: New version cannot open Maildir boxes

[Ian Campbell]

On Tue, 2015-07-28 at 09:21 +0100, Ian Campbell wrote:
> I'm suffering from a similar issue to Guillem,

Guillem,

I had a realisation which might be useful to you as well: The trailing "/"
on a store:mailbox is (or can be) significant, e.g. the following diff
against my previous redacted mbsyncrc appears (on first glance) to work and
to do what I desire:

@@ -8,7 +8,7 @@
 Account XXX
 
 MaildirStore XXX-local
-Path ~/Maildir/..
+Path ~/Maildir/
 Inbox ~/Maildir/
 #AltMap yes
 Flatten .
@@ -22,9 +22,9 @@
 SyncState *
 
 Channel XXX-folders
-Master :XXX-remote:INBOX/
+Master :XXX-remote:INBOX
 Slave :XXX-local:
-Patterns * !INBOX
+Patterns * !
 Create Slave
 Expunge Both
 SyncState *

The change to Master being the primary thing. This results in the:

[Account]
|-INBOX
|- PATCHES
|  |- WIP
|  `- FOO
`- Cronspam

maildir hierarchy which I noted in Message #75 I'd be happy to switch to if
necessary.

NB: I'm still tinkering with things, so I'm not 100% sure this is correct,
but on first glance it looks so and I'm also not sure if it is applicable
to the issue in your context but I hope it turns out to be helpful!

Cheers,
Ian.

Bug#797996: libtool: missing end-of-line in error message in wrapper script generated by libtool

[Vincent Lefevre]

On 2015-09-04 12:20:18 +0200, Vincent Lefevre wrote:
> The problem here is not the error itself (which is normal), but the
> error message, where a "\n" has been substituted by "n".
> 
> The script contains:
> 
> printf %s\n "$relink_command_output" >&2
> 
> The quotes around %s\n are missing. Or perhaps the bug is somewhere
> else and one should have got "$ECHO" instead of "printf %s\n".

This is either Debian specific or fixed upstream in libtool 2.4.6,
where I get $ECHO.

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

Bug#797917: Actually this bug makes clang not so useful

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Danny,

> If we could make those "Dual-ABI compile flags" the default on 
> gcc-compiled libraries, clang upstream should have enough time 
> implementing [abi:cxx11] and remain usable in Debian.


gcc had the dual ABI enabled.

but it got disable in the experimental/unstable uploads:
https://packages.qa.debian.org/g/gcc-5/news/20150616T170514Z.html

I guess clang is not useful for cxx11 projects until llvm folks finds
a way to make it use the new ABI.

sorry, but I don't see how to fix this, for sure enabling again the
dual ABI in gcc (not even sure if it will work), is a no-go, because
I'm pretty sure it will trigger another painful transition.

I'm sorry but we should live with this, until llvm folks implemtents
the new code.

Sylvestre, doko, what is your opinion?

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV6WL+AAoJEPNPCXROn13ZLSwP/jKdByzGcE69N6tMFqRcnrfE
cX4HsZl/ctH+s2++Gf/ViHTOJT96Zearw8IQ3+Z8582YMjw+240fxaRsGJfX4CFr
7zjA9sd3Otk+hailJm67qh6zW58Jw5v/izG5mGQUf6wA4ZSVZ9yqNVOE/9fKuI1x
2lyAt3KELt6wIjgZgjLkwCqndiP8JTpERqNHn+1D2G3FjDAfppWQfiScUu6WfBsC
WPGFl6BzfUWKoXBjBfhcpDEO4HbQ7RUz5AoNK55YVjemU1oy+gqWwXC2alUA6jVt
QOEeq00/iDVptH1E2UCYraUp6bd8ebKlxmWOhmQfW1ubQRTrYFlFM9Fs5SBLnqoT
GnsUHaW/GbPTY+eRtbI3WUiAwsDCdhDAVL3ROXmGN/quPZwYp7YsdB3U70sOd3H+
Kj/PXT/w8FpVeK4ak1LrQB6xCxeG49KPHFJ1KYD04OCsVHugtTdzy1WzRbbHvofV
MPdbbAFGAbI9MGux81+w0HSfZKbkK2DyXjYG4IfYMUpczlyL/4gN4VVJabVB3LNP
6tApQjJf3OivtJBESMUuWwf3TXziUce/GpUvulCVGcEsHJWYiJy7aU22/rl0ZGDw
CceAM6gjNI14XU+ejTF6Xcs2obVK3VPbleHeDG5jNN86F9P4Osy3clYZLMAJwRks
ai/12PvO7FQpYeAb89or
=L2mz
-END PGP SIGNATURE-

Bug#797883: release-notes: Wheezy to Jessie: in Squid helper name changes break configuration

[Niels Thykier]

On 2015-09-04 09:36, Bernard Massot wrote:
> Thank you for the quick action, Niels.
> 
> On Thu, Sep 03, 2015 at 05:37:52PM +0200, Niels Thykier wrote:
>> [...]
>>
>> If you have any remarks to the wording, please let me know and I will
>> look into it. :)
> I think the note is so obvious that it's not necessary. I guess the
> first sentence should read "The configuration of squid has changed in an
> incompatible way.".

Thanks for catching that. :)

~Niels





signature.asc
Description: OpenPGP digital signature

Bug#797976: spice: CVE-2015-3247: memory corruption in worker_update_monitors_config()

[Salvatore Bonaccorso]

Control: tags -1 + patch

Hi,

Attached is the debdiff prepared for a jessie-security upload.

Regards,
Salvatore
diff -Nru spice-0.12.5/debian/changelog spice-0.12.5/debian/changelog
--- spice-0.12.5/debian/changelog   2014-05-23 17:56:48.0 +0200
+++ spice-0.12.5/debian/changelog   2015-09-04 09:35:09.0 +0200
@@ -1,3 +1,12 @@
+spice (0.12.5-1+deb8u1) jessie-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Add CVE-2015-3247.patch patch.
+CVE-2015-3247: memory corruption in worker_update_monitors_config().
+(Closes: #797976)
+
+ -- Salvatore Bonaccorso   Fri, 04 Sep 2015 09:34:00 +0200
+
 spice (0.12.5-1) unstable; urgency=medium
 
   * new upstream release.  Can now build without celt!
diff -Nru spice-0.12.5/debian/patches/CVE-2015-3247.patch 
spice-0.12.5/debian/patches/CVE-2015-3247.patch
--- spice-0.12.5/debian/patches/CVE-2015-3247.patch 1970-01-01 
01:00:00.0 +0100
+++ spice-0.12.5/debian/patches/CVE-2015-3247.patch 2015-09-04 
09:35:09.0 +0200
@@ -0,0 +1,115 @@
+From 524eef10c6c6c2f3f30be28c56b8f96adc7901f0 Mon Sep 17 00:00:00 2001
+From: Frediano Ziglio 
+Date: Tue, 9 Jun 2015 08:50:46 +0100
+Subject: [PATCH] Avoid race conditions reading monitor configs from guest
+
+For security reasons do not assume guest do not change structures it
+pass to Qemu.
+Guest could change count field while Qemu is copying QXLMonitorsConfig
+structure leading to heap corruption.
+This patch avoid it reading count only once.
+
+Signed-off-by: Frediano Ziglio 
+---
+ server/red_worker.c | 46 --
+ 1 file changed, 32 insertions(+), 14 deletions(-)
+
+--- a/server/red_worker.c
 b/server/red_worker.c
+@@ -11051,7 +11051,8 @@ static inline void red_monitors_config_i
+ }
+ 
+ static void worker_update_monitors_config(RedWorker *worker,
+-  QXLMonitorsConfig 
*dev_monitors_config)
++  QXLMonitorsConfig 
*dev_monitors_config,
++  uint16_t count, uint16_t 
max_allowed)
+ {
+ int heads_size;
+ MonitorsConfig *monitors_config;
+@@ -11060,22 +11061,22 @@ static void worker_update_monitors_confi
+ monitors_config_decref(worker->monitors_config);
+ 
+ spice_debug("monitors config %d(%d)",
+-dev_monitors_config->count,
+-dev_monitors_config->max_allowed);
+-for (i = 0; i < dev_monitors_config->count; i++) {
++count,
++max_allowed);
++for (i = 0; i < count; i++) {
+ spice_debug("+%d+%d %dx%d",
+ dev_monitors_config->heads[i].x,
+ dev_monitors_config->heads[i].y,
+ dev_monitors_config->heads[i].width,
+ dev_monitors_config->heads[i].height);
+ }
+-heads_size = dev_monitors_config->count * sizeof(QXLHead);
++heads_size = count * sizeof(QXLHead);
+ worker->monitors_config = monitors_config =
+ spice_malloc(sizeof(*monitors_config) + heads_size);
+ monitors_config->refs = 1;
+ monitors_config->worker = worker;
+-monitors_config->count = dev_monitors_config->count;
+-monitors_config->max_allowed = dev_monitors_config->max_allowed;
++monitors_config->count = count;
++monitors_config->max_allowed = max_allowed;
+ memcpy(monitors_config->heads, dev_monitors_config->heads, heads_size);
+ }
+ 
+@@ -11459,33 +11460,50 @@ void handle_dev_display_migrate(void *op
+ red_migrate_display(worker, rcc);
+ }
+ 
++static inline uint32_t qxl_monitors_config_size(uint32_t heads)
++{
++return sizeof(QXLMonitorsConfig) + sizeof(QXLHead) * heads;
++}
++
+ static void handle_dev_monitors_config_async(void *opaque, void *payload)
+ {
+ RedWorkerMessageMonitorsConfigAsync *msg = payload;
+ RedWorker *worker = opaque;
+-int min_size = sizeof(QXLMonitorsConfig) + sizeof(QXLHead);
+ int error;
++uint16_t count, max_allowed;
+ QXLMonitorsConfig *dev_monitors_config =
+ (QXLMonitorsConfig*)get_virt(>mem_slots, msg->monitors_config,
+- min_size, msg->group_id, );
++ qxl_monitors_config_size(1),
++ msg->group_id, );
+ 
+ if (error) {
+ /* TODO: raise guest bug (requires added QXL interface) */
+ return;
+ }
+ worker->driver_cap_monitors_config = 1;
+-if (dev_monitors_config->count == 0) {
++count = dev_monitors_config->count;
++max_allowed = dev_monitors_config->max_allowed;
++if (count == 0) {
+ spice_warning("ignoring an empty monitors config message from 
driver");
+ return;
+ }
+-if (dev_monitors_config->count > dev_monitors_config->max_allowed) {
++if (count > max_allowed) {
+ spice_warning("ignoring malformed 

Bug#797992: octave: ABI transition needed for libstdc++ v5

[Simon McVittie]

Source: octave
Version: 4.0.0-3
Severity: serious
Justification: breaks ABI without a package rename
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11
Control: block -1 by 791067

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 octave, std::string appears in functions in
installed headers, so it seems very likely that a transition is needed.
The transition normally consists of renaming the affected library
packages, adding a v5 suffix (liboctave3v5). The actual 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. However, please avoid doing this unless the new upstream version
is extremely low-risk: this transition has been going on for 1 month
already, and anything that drags it out further is bad for Debian.

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 C++ library build-dependencies of octave, it is
waiting for hdf5 (#791067) but everything else seems to be ready.
When hdf5 starts its transition, please give octave a versioned
build-dependency on the version of libhdf5-dev corresponding to
the rename.

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

Bug#797993: irqbalance: Memory Leak / Excessive Memory usage in Xen guest

[Daniel Zauner]

Package: irqbalance
Version: 1.0.6-3
Severity: normal
Tags: patch

Dear Maintainer,


I noticed that irqbalance has been consuming ~50% of my 2GB memory and
roughly the same amount of CPU on a 3-core Xen guest after 10 days
uptime, forcing the system to swap.
The symptoms sound exactly as described in the upstream issue queue:
https://github.com/Irqbalance/irqbalance/issues/5

My Xen guest does not have /sys/bus/pci either. Restarting the
irqbalance service temporarily solved it.

Please consider releasing a patched version (issue has been closed in
1.0.7):
https://github.com/Irqbalance/irqbalance/issues/5#issuecomment-40847476

Many thanks,

Dan

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

Kernel: Linux 3.18.9-x86_64-jb1 (SMP w/3 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages irqbalance depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18
ii  libcap-ng0 0.7.4-2
ii  libglib2.0-0   2.42.1-1
ii  libnuma1   2.0.10-1
ii  lsb-base   4.1+Debian13+nmu1

irqbalance recommends no packages.

irqbalance suggests no packages.

-- debconf information:
  irqbalance/enable: true
  irqbalance/oneshot: false

Bug#797997: RFP: solvespace -- SolveSpace is a parametric 2d/3d CAD

[Yuri D'Elia]

Package: wnpp
Severity: wishlist

* Package name: solvespace
  Version : 2.1
  Upstream Author : Jonathan Westhues
* URL : http://solvespace.com/
* License : GPLv3
  Programming Lang: C++
  Description : SolveSpace is a parametric 2d/3d CAD

SolveSpace is a parametric 2d/3d CAD program. Applications include: 



* modeling 3d parts — draw with extrudes, revolves, and Boolean (union /
  difference) operations;
* modeling 2d parts — draw the part as a single section, and export DXF, PDF,
  SVG; use 3d assembly  to verify fit;  
  
* 3d-printed parts — export the STL or other triangle mesh expected by most 3d
  printers;
* preparing CAM data — export 2d vector art for a waterjet machine or laser
  cutter; or generate STEP or STL, for import into third-party CAM software for
  machining;   
* mechanism design — use the constraint solver to simulate planar or spatial
  linkages, with pin,ball, or slide joints; 
   
* plane and solid geometry — replace hand-solved trigonometry and spreadsheets
  with a live dimensioned drawing.  
  

My own description here:

solvespace has a very straightforward constraint/parametric modeling system.

The interface, after learning a few basics, is far better than FreeCAD and many
other (static!) modelers currently available in Debian. It's impressive how
streamlined the GUI/modeling is, and shows how much the developer has put
thought into it. I find FreeCAD, by UI/interaction comparison, complete
garbage.

It's also very stable, and while the kernel is definitely not as sophisticated
as OCE, the current limits of solvespace allow it to build pretty impressive
models. It also hasn't failed as frequently as OCE on me yet.

solvespace is a little software gem, and I cannot thank Jonathan Westhues
enough for first making it available and then making it open source.

There's already a working PPA (and debian packaging) maintained by whitequark
 at https://github.com/whitequark/solvespace

Bug#798003: freeimage: please change FreeImage.h encoding

[Christophe Trophime]

Source: freeimage
Version: 3.15.4-4.1
Severity: normal

Dear Maintainer,

could you please change the encoding on installed FreeImage.h header?
The actual encoding is no longer ASCII since you introduced a second author 
"hervé".
This change may cause some packages to FTBS.

Trying to install salome from source FTBS because of this change.
The installer tries to recover FreeImage version by using grep VERSION in 
FreeImage.h

The non ASCII encoding somehow breaks this as the grep command no longer 
returns the 
lines including "VERSION". Instead the grep command return a message "Binary 
 matches".

Changing "hervé" to herve fix the problem.

Best regards
C. 


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

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

Bug#798008: yaml-cpp: library transition needed with GCC 5 as default

[Simon McVittie]

Control: tags 798008 + patch pending

On Fri, 04 Sep 2015 at 14:18:50 +0200, Julien Cristau wrote:
>Then reassign the issue to release.debian.org and
>properly tag it as a transition issue

This was already done,  (but I thought
you'd stopped wanting people to do this and started wanting people to
just upload and close the bug in any case).

There's a patch from a maintainer on that bug, which I have built locally
and build-tested with librime. It's ready for sponsored upload, unless you
want me to hold off because of the previous ABI break in
.

Please let me know whether I should upload or do something else.

S

Bug#798012: doc-debian: unmarked rationale

[Jakub Wilk]

Package: doc-debian
Version: 6.3

/usr/share/doc/debian/constitution.txt.gz reads:
"Text marked as a citation, such as this, is rationale and does not form 
part of the constitution."


But in this text document, rationale is not marked in any way. It's 
therefore impossible to tell which parts are rationale and which are 
proper parts of the constitution without looking at the WML source.


--
Jakub Wilk

Bug#797995: virtualbox-ext-pack: [l10n:cs] Initial Czech PO debconf translation

[Michal Simunek]

Package: virtualbox-ext-pack
Version: 5.0.2-2
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

In attachment there is initial Czech translation of PO debconf template (cs.po)
for package virtualbox-ext-pack, please include it.

Thanks



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=cs_CZ.utf8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
# Czech PO debconf template translation of virtualbox-ext-pack.
# Copyright (C) 2015 Michal Simunek 
# This file is distributed under the same license as the virtualbox-ext-pack package.
# Michal Simunek , 2015.
#
msgid ""
msgstr ""
"Project-Id-Version: virtualbox-ext-pack 5.0.2-2\n"
"Report-Msgid-Bugs-To: virtualbox-ext-p...@packages.debian.org\n"
"POT-Creation-Date: 2015-08-16 09:32+0200\n"
"PO-Revision-Date: 2015-09-04 09:15+0200\n"
"Last-Translator: Michal Simunek \n"
"Language-Team: Czech \n"
"Language: cs\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Do you accept the terms of this license?"
msgstr "Přijímáte licenční podmínky?"

Bug#797992: octave: ABI transition needed for libstdc++ v5

[Simon McVittie]

On Fri, 04 Sep 2015 at 10:00:04 +0100, Simon McVittie wrote:
> Looking at the C++ library build-dependencies of octave, it is
> waiting for hdf5 (#791067) but everything else seems to be ready.

Looking more closely at this, hdf5 has both a C and a C++ API,
and octave appears to only use the C. If this is correct, then it does
not need to wait for hdf5 after all.

Regards,
S

Bug#797996: libtool: missing end-of-line in error message in wrapper script generated by libtool

[Vincent Lefevre]

Package: libtool
Version: 2.4.2-1.11
Severity: normal

In MPFR, there is a wrapper script tools/bench/mpfrbench generated by
libtool (when doing "make mpfrbench" in this directory).

I got an error:

ypig:...-tune/tools/bench> ./mpfrbench
gcc: error: mpfrbench.o: No such file or directory
gcc: error: ../../src/.libs/libmpfr.so: No such file or directorynzsh: exit 1   
  ./mpfrbench

The problem here is not the error itself (which is normal), but the
error message, where a "\n" has been substituted by "n".

The script contains:

printf %s\n "$relink_command_output" >&2

The quotes around %s\n are missing. Or perhaps the bug is somewhere
else and one should have got "$ECHO" instead of "printf %s\n".

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

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

Versions of packages libtool depends on:
ii  autotools-dev   20140911.1
ii  clang-3.4 [c-compiler]  1:3.4.2-15
ii  clang-3.5 [c-compiler]  1:3.5.2-2
ii  clang-3.6 [c-compiler]  1:3.6.2-1
ii  clang-3.7 [c-compiler]  1:3.7-1
ii  clang-3.8 [c-compiler]  1:3.8~svn245286-1
ii  cpp 4:5.2.1-4
ii  file1:5.22+15-2
ii  gcc [c-compiler]4:5.2.1-4
ii  gcc-4.4 [c-compiler]4.4.7-8
ii  gcc-4.5 [c-compiler]4.5.4-1
ii  gcc-4.6 [c-compiler]4.6.4-7
ii  gcc-4.7 [c-compiler]4.7.4-3
ii  gcc-4.8 [c-compiler]4.8.5-1
ii  gcc-4.9 [c-compiler]4.9.3-4
ii  gcc-5 [c-compiler]  5.2.1-15
ii  libc6-dev [libc-dev]2.19-19
ii  tcc [c-compiler]0.9.27~git20140923.9d7fb33-3

Versions of packages libtool recommends:
ii  libltdl-dev  2.4.2-1.11

Versions of packages libtool suggests:
ii  autoconf   2.69-9
ii  automake [automaken]   1:1.15-3
pn  gcj-jdk
ii  gfortran   4:5.2.1-4
ii  gfortran-4.7 [fortran95-compiler]  4.7.4-3
ii  gfortran-4.8 [fortran95-compiler]  4.8.5-1
ii  gfortran-4.9 [fortran95-compiler]  4.9.3-4
ii  gfortran-5 [fortran95-compiler]5.2.1-15
ii  libtool-doc2.4.2-1.11

-- no debconf information

Bug#798005: Allow disabling Add-on signing in IceWeasel 42+

[Alexander Schlarb]

Package: iceweasel
Version: 42.0b1

As of Firefox 42 Mozilla will disallow running unsigned Add-on entirely. 
Currently (Version 41) its still possible to disable strict add-on signature 
checking by setting the preference "xpinstall.signatures.required" to false.

Please consider retaining the current (v41) behaviour for future versions of 
IceWeasel.

Some reasons why I believe that strict add-on signature verification should not 
be enforced in IceWeasel:

# Target audience #

Mozilla's official announcement of add-on signing[1] makes it pretty clear that 
they added this feature to Firefox to combat Windows Crapware that was 
installing misbehaving stuff into their browser and whose behaviour would then 
mainly be blamed on Firefox (from an inexperienced user perspective).

> Extensions that change the homepage and search settings without user consent
> have become very common, just like extensions that inject advertisements
> into Web pages or even inject malicious scripts into social media sites. To
> combat this, we created a set of add-on guidelines all add-on makers must
> follow, and we have been enforcing them via blocklisting (…). However,
> extensions that violate these guidelines are distributed almost exclusively
> outside of AMO and tracking them all down has become increasingly
> impractical. Furthermore, malicious developers have devised ways to make
> their extensions harder to discover and harder to blocklist, […].

To my knowledge there hasn't been a single piece of browser-offending Crapware 
release for Debian to this day.

# Slow signing process #

In the last year I've been releasing 2 add-ons on AMO and each of them 
required about 3 MONTHS! to be reviewed. In one case that would have been 
particularly bad since its was an add-on written specifically for a certain 
user that needed it somewhat urgently. (Background story: I've abandoned the 
maintenance of a very old add-on [no serious development in the last ~5 years] 
that would have required a major rewrite to make it work again, but I told my 
users that, if they needed some feature of this add-on that was not available 
anywhere else, I'd write them separate extensions with just these extra 
features.) How would I have given this add-on to this user if we had had 
strict add-on signing back then?

# Taking away user freedom #

Sometimes there abandoned, unsigned, self-made, … add-ons that are important 
but are just not available through AMO[2].

I don't think I need to expand on this topic though as, I think, its pretty 
obvious how having to ask somebody else which software I may run, limits my 
own freedom.



Summary: Strict add-on signing is something that Debian's browsers neither 
need nor, in my opinion, want. Debian is not haunted by Crapware vendors 
trying to install malicious add-ons and generally tries to provide a very 
flexible system that gives users the most possible freedom while still being 
stable and reliable. Strict add-on signing is not something that is in any way 
helpful in making this possible. Warning users of unverified add-ons is not a 
bad idea, nor is requiring some basic technical background (about:config) to 
use them, but there are always use-cases that neither Mozilla nor Debian can 
predict that are broken when you tell users which software they may or may not 
run.

Yours sincerely,
Alexander Schlarb


  [1]: 
https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/
  [2]: http://forums.debian.net/viewtopic.php?f=20=120409#p590937

Bug#797968: elinks: Please add support for TLS SNI

[Moritz Mühlenhoff]

On Fri, Sep 04, 2015 at 04:36:35AM +0200, Guillem Jover wrote:
> Package: elinks
> Version: 0.12~pre6-10
> Severity: wishlist
> Tags: patch
> 
> Hi!
> 
> Here's a patch implementing TLS SNI support.

Hi Guillem,
thanks for this and the other TLS patches for elinks. I'll
forward them to upstream over the weekend.

Cheers,
Moritz

Bug#797998: unknown-horizons: Crash shortly after start of single player game

[Nils Dagsson Moskopp]

Package: unknown-horizons
Version: 2014.1+ds1-2
Severity: important

Dear Maintainer,

I started Unknown Horizons and selected “single player game“.
I then chose the second map (the one that is not “tutorial”).

The game crashed before I could build the first settlement.
Reproducing that, the game just crashed after a short time.
I can play UH for approximately a minute before it crashes.


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

Kernel: Linux 3.13-1-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages unknown-horizons depends on:
ii  dpkg 1.18.1
ii  python   2.7.9-1
ii  python-enet  0.0~svn24-1+b2
ii  python-fife  0.3.5-1+b1
ii  python-yaml  3.11-2
pn  python:any   

unknown-horizons recommends no packages.

unknown-horizons suggests no packages.

-- no debconf information

Bug#797571: RM: gnome-do -- RoQA; abandoned

[Iain Lane]

tags 797571 + moreinfo
thanks

On Mon, Aug 31, 2015 at 06:12:47PM +0200, Andreas Henriksson wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Please remove this package which is a (direct or indirect) reverse
> dependency of gnome-desktop-sharp2, see #797567, which in turn is a
> reverse dependency of gtkhtml3.14, see #797441

We might want to keep this one - I just pinged RAOF to check.

Please wait a little bit before removing.

Thanks,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: Digital signature

Bug#798002: Headers do not agree with libgflags2v5 on SetUsageMessage type

[Mikhail Arefiev]

Package: libgflags-dev
Version: 2.1.2-3

I am using the following package versions from jessie/sid:

Package: libgflags2v5
Source: gflags
Version: 2.1.2-3
Installed-Size: 285

Package: libgflags-dev
Source: gflags
Version: 2.1.2-3
Installed-Size: 558

Trying to compile this program:

#include 

int main(int argc, char** argv)
{
google::SetUsageMessage("usage");
return 0;
}

I get this message:

% g++ -lgflags flags.cpp -o flags
/tmp/ccQnf2DM.o: In function `main':
flags.cpp:(.text+0x39): undefined reference to 
`google::SetUsageMessage(std::string const&)'

collect2: error: ld returned 1 exit status

It compiles with gflags 2.0-2.1 on Debian 8.1

--

С уважением,
*Михаил Арефьев*
Ведущий программист группы разработки PT SIEM
Positive Technologies
Тел.: +7 (495) 744-01-44, факс: +7 (495) 744-01-87
Эл. почта: maref...@ptsecurity.com

www.ptsecurity.ru, www.maxpatrol.ru, www.securitylab.ru

Bug#798010: ipython3: malicious dynamic python3 interpreter lookup via "/usr/bin/env python3" in main executable

[Tobias Megies]

Package: ipython3
Version: 2.3.0-2
Severity: serious
Justification: Debian Python Policy 2.4.2: Interpreter Location

Dear Maintainer,

the main executable /usr/bin/ipython3 has shebang line 1 "#!/usr/bin/env
python3" and thus uses the first python3 interpreter found in $PATH doing a
dynamic lookup at execution time.
If a local user-space Python environment is coming first in $PATH it will thus
yield the Python3 IPython prompt from user space and not from the system
python. This will result in very puzzling situation and clearly is in violation
of the Debian Python Policy which demands the hardcoded system python binary in
shebang.

See Debian Python Policy 2.4.2 Interpreter location:
https://www.debian.org/doc/packaging-manuals/python-policy/ch-
python.html#s-interpreter_loc

=== quote start
The preferred specification for the Python interpreter is /usr/bin/python or
/usr/bin/pythonX.Y. This ensures that a Debian installation of python is used
and all dependencies on additional python modules are met.
Maintainers should not override the Debian Python interpreter using
/usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it
bypasses Debian's dependency checking and makes the package vulnerable to
incomplete local installations of python.
=== quote end


best regards,
Tobias Megies



-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ipython3 depends on:
ii  python3-decorator  3.4.0-2
ii  python3-pkg-resources  5.5.1-1
ii  python3-simplegeneric  0.8.1-1
pn  python3:any

ipython3 recommends no packages.

Versions of packages ipython3 suggests:
pn  ipython3-notebook   
pn  ipython3-qtconsole  
pn  python3-zmq 

-- no debconf information

Bug#791904: [HEADS-UP] libsystemd transition

[Michael Biebl]

Hi

Am 04.09.2015 um 13:42 schrieb Alberto Gonzalez Iniesta:
> I've been fighting with this for some time, but building with recent
> libsystemd-dev (without libsystemd-daemon-dev), makes
> systemd-ask-password support fail (disappear?). 
> Please find attached the debdiff for my work in progress. I had to patch
> the configure script in order to skip the check for
> libsystemd-daemon-dev.
> 
> Any hints/help would be appreciated. I also tried with a more recent
> upstream version, with the same result.

Hm, I don't understand why you need to patch configure.ac. Looking at
configure.ac, it has:

PKG_CHECK_MODULES([libsystemd], [systemd libsystemd],
  [],
  [PKG_CHECK_MODULES([libsystemd], [libsystemd-daemon])]
  )

So, it already checks for the new libsystemd first, then falls back to
the old libsystmd-daemon name. I.e., all you need to do is to change the
Build-Depends in debian/control from libsystemd-daemon-dev to
libsystemd-dev, for which I attached a patch [1].
I did a test build with that patch applied and the resulting package had
a proper b-dep on libsystemd. Attached is the build log.

Cheers,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791904#10
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
dpkg-buildpackage: source package openvpn
dpkg-buildpackage: source version 2.3.7-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Alberto Gonzalez Iniesta 
 dpkg-source --before-build openvpn-2.3.7
 fakeroot debian/rules clean
dh clean --with systemd
   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/tmp/openvpn-2.3.7'
# These two get deleted on "make clean", but come in the tarball
# hack to keep them around after "make clean"
test -f distro/rpm/openvpn.spec.not || mv distro/rpm/openvpn.spec distro/rpm/openvpn.spec.not
test -f tests/t_client.sh.not || mv tests/t_client.sh tests/t_client.sh.not
dh_auto_clean
test -f distro/rpm/openvpn.spec.not && mv distro/rpm/openvpn.spec.not distro/rpm/openvpn.spec
test -f tests/t_client.sh.not && mv tests/t_client.sh.not tests/t_client.sh
# clean plugins
# /usr/bin/make -C plugin/auth-pam/ clean
# /usr/bin/make -C plugin/down-root/ clean
make[1]: Leaving directory '/tmp/openvpn-2.3.7'
   debian/rules override_dh_clean
make[1]: Entering directory '/tmp/openvpn-2.3.7'
dh_clean -X win/openvpn.nsi.orig
make[1]: Leaving directory '/tmp/openvpn-2.3.7'
 dpkg-source -b openvpn-2.3.7
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building openvpn using existing ./openvpn_2.3.7.orig.tar.gz
dpkg-source: info: building openvpn in openvpn_2.3.7-1.debian.tar.xz
dpkg-source: info: building openvpn in openvpn_2.3.7-1.dsc
 dpkg-genchanges -S >../openvpn_2.3.7-1_source.changes
dpkg-genchanges: including full source code in upload
 dpkg-source --after-build openvpn-2.3.7
dpkg-buildpackage: full upload (original source is included)
 -> Copying COW directory
  forking: rm -rf /var/cache/pbuilder/build//cow.1912 
  forking: cp -al /var/cache/pbuilder/sid.cow /var/cache/pbuilder/build//cow.1912 
I: removed stale ilistfile /var/cache/pbuilder/build//cow.1912/.ilist
  forking: chroot /var/cache/pbuilder/build//cow.1912 cowdancer-ilistcreate /.ilist find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ' 
 -> Invoking pbuilder
  forking: pbuilder build --debbuildopts  --debbuildopts  --buildplace /var/cache/pbuilder/build//cow.1912 --buildresult /var/cache/pbuilder/result/ --debbuildopts  --no-targz --internal-chrootexec chroot /var/cache/pbuilder/build//cow.1912 cow-shell /tmp/openvpn_2.3.7-1.dsc 
I: Running in no-targz mode
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Fri Sep  4 14:22:08 CEST 2015
I: pbuilder-time-stamp: 1441369328
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Installing the build-deps
 -> 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 (>= 7.0.50~), libssl-dev (>> 0.9.8g-9), liblzo2-dev, libpam0g-dev, libpkcs11-helper1-dev, pkg-config, dpkg-dev (>= 1.16.1), iproute2, dh-systemd (>= 1.5), libsystemd-dev
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in '/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting 

Bug#797980: kdevelop: Missing .so file in kdevelop.install

[Zhang Jingqiang]

在 2015年9月4日 星期五 12:00:22，您写道：
> > usr/lib/libkdevcompilerprovider.so should be added to kdevelop.install
> > file, without which KDevDefinesAndIncludesManager won't work.
> 
> This plugin crash kdevelop now, but it did work before the gcc 5 transition.
> I will test latest official 4.7 branch.
Still crash:
QSocketNotifier: Invalid socket 7 and type 'Read', disabling...
QSocketNotifier: Invalid socket 11 and type 'Read', disabling...
QSocketNotifier: Invalid socket 23 and type 'Read', disabling...
QSocketNotifier: Invalid socket 28 and type 'Read', disabling...
QSocketNotifier: Invalid socket 24 and type 'Read', disabling...
QSocketNotifier: Invalid socket 27 and type 'Read', disabling...
kdevelop: Fatal IO error: client killed
DUContextData::m_childContexts There were items left on destruction: 7
TopDUContextData::m_problems There were items left on destruction: 8
DUContextData::m_uses There were items left on destruction: 54
TopDUContextData::m_usedDeclarationIds There were items left on destruction: 
52
DUContextData::m_localDeclarations There were items left on destruction: 24
DUContextData::m_importers There were items left on destruction: 64
DUContextData::m_importedContexts There were items left on destruction: 65
Unable to start Dr. Konqi
Not forwarding the crash to Apport.

Bug#798009: ITP: python-editor -- programmatically open an editor, capture the result

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-editor
  Version : 0.4
  Upstream Author : Peter Ruibal 
* URL : https://github.com/fmoo/python-editor
* License : Apache-2.0
  Programming Lang: Python
  Description : programmatically open an editor, capture the result

 python-editor is a library that provides the editor module for
 programmatically interfacing with your system's $EDITOR. The user can then
 enter a commit message for example.
 .
 Editor first looks for the ${EDITOR} environment variable.  If set, it uses
 the value as-is, without fallbacks. If no $EDITOR is set, editor will search
 through a list of known editors, and use the first one that exists on the
 system. For example, on Linux, editor will look for the following editors in
 order:
  * vim
  * emacs
  * nano
 .
 When calling the edit() function, editor will open the editor in a
 subprocess, inheriting the parent process's stdin, stdout

This is a new dependency of Alembic, which already is in Sid and misses it.

Bug#797838: faac: build with mp4v2

[Fabian Greffrath]

Am Donnerstag, den 03.09.2015, 13:42 +0200 schrieb Christoph Anton Mitterer:
> On Thu, 2015-09-03 at 07:11 +0200, Fabian Greffrath wrote:
> > this is because libmp4v2 is licensed under the MPL-1.1 whereas faac
> > is
> > licensed under the GPL. Since both licenses are incompatible, the
> > resulting binaries would be unredistributable.
> Ah... I somehow missed that mp4v2 was MPL 1.1... thought it was 2.0

I have to correct myself: even the frontend code in faac is licensed
under the LGPL (I mixed this up with the gtkpod+mp4v2 situation). But
parts of libfaac are imposed with further restrictions that make it
incompatible with about any other possible open-source license.

Thanks, Carl Eugen.

 - Fabian


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

Bug#787072: openjdk-8: fix build on mips and mipsel

[James Cowgill]

Control: reopen -1

Hi,

This bug was never actually fixed since although the patch was included
in debian/patches, 'jvm-detect-32bit-archs.diff' wasn't added to the
list of patches in debian/rules.

Thanks,
James

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

Bug#797999: sddm fails to start whereas kdm works correctly

[Eric Valette]

Package: sddm
Version: 0.11.0-4
Severity: important

If I do dpkg-reconfigure sddm, select it and reboot, I just get a black
screen, with X running, no cursor, no mouse nothing in/var/log/sddm.log

Note its a docked laptop, with external monitor used, lid closed and laptop
monitor automatically desactivated.

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

Kernel: Linux 4.1.6 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages sddm depends on:
ii  adduser 3.113+nmu3
ii  debconf [debconf-2.0]   1.5.57
ii  libc6   2.21-0experimental1
ii  libgcc1 1:5.2.1-16
ii  libpam0g1.1.8-3.1
ii  libqt5core5a5.4.2+dfsg-9
ii  libqt5dbus5 5.4.2+dfsg-9
ii  libqt5gui5  5.4.2+dfsg-9
ii  libqt5network5  5.4.2+dfsg-9
ii  libqt5qml5  5.4.2-6
ii  libqt5quick55.4.2-6
ii  libstdc++6  5.2.1-16
ii  libsystemd0 225-1
ii  libxcb-xkb1 1.10-3+b1
ii  libxcb1 1.10-3+b1
ii  qml-module-qtquick2 5.4.2-6
ii  sddm-theme-breeze [sddm-theme]  4:5.3.2-4+b1

sddm recommends no packages.

Versions of packages sddm suggests:
pn  pam-kwallet5  

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: kdm

Bug#797992: [Pkg-octave-devel] Bug#797992: octave: ABI transition needed for libstdc++ v5

[Rafael Laboissiere]

* Simon McVittie  [2015-09-04 10:16]:


On Fri, 04 Sep 2015 at 10:00:04 +0100, Simon McVittie wrote:

Looking at the C++ library build-dependencies of octave, it is
waiting for hdf5 (#791067) but everything else seems to be ready.


Looking more closely at this, hdf5 has both a C and a C++ API, 
and octave appears to only use the C. If this is correct, then it does 
not need to wait for hdf5 after all.


The liboctave3 package, version 4.0.0-3 in both unstable and testing, 
depends on libstdc++6 >= 5.2.  This package does not exist in stable.  Is 
a rebuild really necessary?


Rafael

Bug#796855: gcc-5: guile-2.0 fails to build with offset problem on armel

[Matthias Klose]

On 09/04/2015 03:38 AM, Rob Browning wrote:
> Rob Browning  writes:
> 
>> You mean -O0, perhaps?
> 
> Actually, there may be a mistake in the current rules file which is
> causing it to always build without an -O flag...
> 
> Changing the rules to work correctly (to use -O2 as you mentioned)
> appears to fix the problem, though I assume that will mean
> DEB_BUILD_OPTIONS=noopt won't work on armel for now.

if the defaults work, then just rely on dpkg-buildflags.

Bug#798006: base: reboot instead of shutdown when shutdown is invoked in hp EliteBook 840

[Guillaume Bouvier]

Package: base
Severity: normal

Dear Maintainer,

When I invoke a shutdown from the gnome menu, the computer (hp EliteBook 840)
reboots instead of shutting down. However the shutdown works well when I
disable the "Wake On LAN" in the bios of my machine.

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

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

Bug#766884: libxml2 broken in sid for months already

[Vincent Lefevre]

On 2015-09-04 13:59:02 +0200, Raphael Hertzog wrote:
> On Fri, 04 Sep 2015, Aron Xu wrote:
> > I don't want to close it, nor I want make this version to testing, so
> > please don't lower the severity, as said above.
> 
> Why don't you want this version into testing?

I'm not the maintainer, but I think that it is probably cleaner to
have testing version = stable version until this bug is fixed (it
would be different if testing had already diverged from stable).

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

Bug#797778: Please package pyroute2 >= 0.3.10

[Florian Pelgrim]

Hey ho,

I will update the package soon.
Guess this will be done next week.

Cheers
Flo

Am 02.09.15 um 15:23 schrieb Thomas Goirand:
> Package: python-pyroute2
> Version: 0.3.5-1
> Severity: wishlist
> 
> Hi,
> 
> I need pyroute2 >= 0.3.10, as this is now a dependency of OpenStack. Please
> update your package in Sid. Alternatively, if you don't have time, I can
> NMU the package (in which case, please let me know).
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 



signature.asc
Description: OpenPGP digital signature

Bug#770659: WebRTC camera/microphone sharing does not work

[Paride Legovini]

Package: chromium
Version: 45.0.2454.85-1
Followup-For: Bug #770659

For the record: bug still present in Chromium 45.

Paride

Bug#791904: [HEADS-UP] libsystemd transition

[Alberto Gonzalez Iniesta]

On Thu, Aug 27, 2015 at 02:53:32AM +0200, Michael Biebl wrote:
> Hi
> 
> On Mon, 13 Jul 2015 16:30:11 +0200 Michael Biebl  wrote:
> > Control: severity -1 important
> >
> > Hi,
> >
> > this is a heads-up that we plan to drop the libsystemd-* compat
> > libraries in about two months. At that point, your package will FTBFS
> > and this bug will be raised to serious.
> 
> This is another friendly reminder that the compat libraries will be
> dropped in 2 weeks.
> Would be great if you can prepare an upload.
> 
> Michael
> 

Hi Michael,

I've been fighting with this for some time, but building with recent
libsystemd-dev (without libsystemd-daemon-dev), makes
systemd-ask-password support fail (disappear?). 
Please find attached the debdiff for my work in progress. I had to patch
the configure script in order to skip the check for
libsystemd-daemon-dev.

Any hints/help would be appreciated. I also tried with a more recent
upstream version, with the same result.


Regards,

Alberto


-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55
diff -Nru openvpn-2.3.7/debian/changelog openvpn-2.3.7/debian/changelog
--- openvpn-2.3.7/debian/changelog  2015-07-01 14:19:20.0 +0200
+++ openvpn-2.3.7/debian/changelog  2015-09-04 13:20:01.0 +0200
@@ -1,3 +1,10 @@
+openvpn (2.3.7-2) unstable; urgency=medium
+
+  * Patch configure to build without libsystemd-daemon-dev.
+(Closes: #791904). Rename debian/control Build-Dep
+
+ -- Alberto Gonzalez Iniesta   Fri, 04 Sep 2015 11:18:40 
+
+
 openvpn (2.3.7-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru openvpn-2.3.7/debian/control openvpn-2.3.7/debian/control
--- openvpn-2.3.7/debian/control2015-07-01 13:14:01.0 +0200
+++ openvpn-2.3.7/debian/control2015-09-04 13:21:16.0 +0200
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Alberto Gonzalez Iniesta 
-Build-Depends: debhelper (>= 7.0.50~), libssl-dev (>> 0.9.8g-9), liblzo2-dev, 
libpam0g-dev, libpkcs11-helper1-dev, pkg-config, dpkg-dev (>= 1.16.1), iproute2 
[linux-any], net-tools [!linux-any], dh-systemd (>= 1.5), libsystemd-daemon-dev
+Build-Depends: debhelper (>= 7.0.50~), libssl-dev (>> 0.9.8g-9), liblzo2-dev, 
libpam0g-dev, libpkcs11-helper1-dev, pkg-config, dpkg-dev (>= 1.16.1), iproute2 
[linux-any], net-tools [!linux-any], dh-systemd (>= 1.5), libsystemd-dev
 Standards-Version: 3.9.5
 Homepage: http://www.openvpn.net/
 Vcs-Git: git://anonscm.debian.org/collab-maint/openvpn.git
diff -Nru openvpn-2.3.7/debian/patches/configure_systemd-daemon.patch 
openvpn-2.3.7/debian/patches/configure_systemd-daemon.patch
--- openvpn-2.3.7/debian/patches/configure_systemd-daemon.patch 1970-01-01 
01:00:00.0 +0100
+++ openvpn-2.3.7/debian/patches/configure_systemd-daemon.patch 2015-09-04 
13:17:58.0 +0200
@@ -0,0 +1,104 @@
+Index: pp/configure
+===
+--- pp.orig/configure
 pp/configure
+@@ -16473,12 +16473,12 @@ if test -n "$libsystemd_CFLAGS"; then
+ pkg_cv_libsystemd_CFLAGS="$libsystemd_CFLAGS"
+  elif test -n "$PKG_CONFIG"; then
+ if test -n "$PKG_CONFIG" && \
+-{ { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists 
--print-errors \"libsystemd-daemon\""; } >&5
+-  ($PKG_CONFIG --exists --print-errors "libsystemd-daemon") 2>&5
++{ { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists 
--print-errors \"libsystemd\""; } >&5
++  ($PKG_CONFIG --exists --print-errors "libsystemd") 2>&5
+   ac_status=$?
+   $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+   test $ac_status = 0; }; then
+-  pkg_cv_libsystemd_CFLAGS=`$PKG_CONFIG --cflags "libsystemd-daemon" 
2>/dev/null`
++  pkg_cv_libsystemd_CFLAGS=`$PKG_CONFIG --cflags "libsystemd" 2>/dev/null`
+ test "x$?" != "x0" && pkg_failed=yes
+ else
+   pkg_failed=yes
+@@ -16490,12 +16490,12 @@ if test -n "$libsystemd_LIBS"; then
+ pkg_cv_libsystemd_LIBS="$libsystemd_LIBS"
+  elif test -n "$PKG_CONFIG"; then
+ if test -n "$PKG_CONFIG" && \
+-{ { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists 
--print-errors \"libsystemd-daemon\""; } >&5
+-  ($PKG_CONFIG --exists --print-errors "libsystemd-daemon") 2>&5
++{ { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists 
--print-errors \"libsystemd\""; } >&5
++  ($PKG_CONFIG --exists --print-errors "libsystemd") 2>&5
+   ac_status=$?
+   $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+   test $ac_status = 0; }; then
+-  pkg_cv_libsystemd_LIBS=`$PKG_CONFIG --libs "libsystemd-daemon" 2>/dev/null`
++  pkg_cv_libsystemd_LIBS=`$PKG_CONFIG --libs "libsystemd" 2>/dev/null`
+ test "x$?" != "x0" && 

Bug#797306: [Pkg-xfce-devel] Bug#797307: mousepad: Heavy cpu usage

[Yves-Alexis Perez]

On sam., 2015-08-29 at 08:10 -0400, Pascal Gervais wrote:
> Opening a file as root with mousepad leads to nearly 100% CPU usage.

Does this always happen or only when two separate mousepad windows are
opened (meaning, could it be a duplicate of #795192)?

Regards,
-- 
Yves-Alexis



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

Bug#796855: gcc-5: guile-2.0 fails to build with offset problem on armel

[Hector Oron]

Hello,

2015-09-04 3:38 GMT+02:00 Rob Browning :
> Rob Browning  writes:
>
>> You mean -O0, perhaps?
>
> Actually, there may be a mistake in the current rules file which is
> causing it to always build without an -O flag...
>
> Changing the rules to work correctly (to use -O2 as you mentioned)
> appears to fix the problem, though I assume that will mean
> DEB_BUILD_OPTIONS=noopt won't work on armel for now.
>
> In any case, if my test build finishes successfully, I'll fix the
> package and upload a new version soonish.
>
> Thanks for the help.

Yes, that's correct! Thanks!

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#798004: xletters: Non-standard charset makes some characters untypeable and wrongly displayed.

[Ben Armstrong]

Thanks for your report,

On 04/09/15 08:34 AM, chill3 wrote:
> I've installed xletters in Spanish, but, due to an incorrect charset probably
> on the translation, the characters on the upper half of the ASCII character
> table don't display correctly.
>
> For each character on that half, the program displayed two characters, so I
> suppose the translation table was encoded in UTF-8 but displayed as it was 
> ANSI
> or another similar charset. Changing the font didn't work.
>
> The words come from /usr/share/dict/spanish at the 'wspanish' package. Please
> patch the program so it supports UTF-8 encoding.
>
> Thank you for your attention.

It would probably be better to replace Debian's upstream for xletters to
this Unicode-supporting fork than try to patch around this limitation:

http://www.msc.univ-paris-diderot.fr/~daerr/progs/xletters/

Meanwhile, perhaps you could try downloading and building it from source
to see if it works fine for Spanish and report your results on this bug.

Frankly, I haven't given any attention to this package in years, and it
should really be taken over by someone with a greater interest in
packaging software for young children. My youngest turns 14 this year so
is well beyond the age to find xletters interesting. I've CC'd debian-jr
& debian-edu lists to see if there's anyone there willing to pick it up.
If there are no takers, I'll formally orphan the package, as I do agree
Unicode support is badly needed, but that's more work than I'm willing
to put into it.

Ben

Bug#798008: yaml-cpp: library transition needed with GCC 5 as default

[Julien Cristau]

Source: yaml-cpp
Version: 0.5.2-1
Severity: serious
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Hi,

your library exposes std::string or std::list in its public API, and
therefore the library package needs to be renamed.

Cheers,
Julien

The following is a form letter:

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 are using the new ABI.  Libraries built
from this source package export some of the new __cxx11 or B5cxx11 symbols, and
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.

What is needed:

 - Rebuild the library using g++/g++-5. Note that most likely all C++
   libraries within the build dependencies need a rebuild too. You can
   find the log for a rebuild in
 https://people.debian.org/~doko/logs/gcc5-20150813/
   Search for "BEGIN GCC CXX11" in the log.

 - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
   library API, and are used by the reverse dependencies of the
   library.

 - If there are no symbols matching __cxx11 or B5cxx11 in the symbols
   forming the library API, you should close this issue with a short
   explanation.
 
 - If there are no reverse dependencies, it should be the package
   maintainers decision if a transition is needed.  However this might
   break software which is not in the Debian archive, and built
   against these packages.

 - If a library transition is needed, please prepare for the change.
   Rename the library package, append "v5" to the name of the package
   (e.g. libfoo2 -> libfoo2v5). Such a change can be avoided, if you
   have a soversion bump and you upload this version instead of the
   renamed package.  Prepare a patch and attach it to this issue (mark
   this issue with patch), so that it is possible to NMU such a
   package. We'll probably have more than hundred transitions
   triggered. Then reassign the issue to release.debian.org and
   properly tag it as a transition issue, by sending an email to
   cont...@bugs.debian.org:
   
 user release.debian@packages.debian.org
 usertag  + transition
 block  by 790756
 reassign  release.debian.org
   
 - If unsure if a transition is needed, please tag the issue with help
   to ask for feedback from other Debian developers.

The libstdc++6 transition will be a large one, and it will come with a
lot of pain.  Please help it by preparing the follow-up transitions.

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition



signature.asc
Description: Digital signature

Bug#791526: [Pkg-postgresql-public] Bug#791526: Bug#791526: Bug#791526: postgresql-9.4: postgresql needs locales-all to create cluster on install

[Christoph Berg]

Re: Malte 2015-09-03 <2209952.WRhyhFcPHE@localhost>
> first off: unsetting LC_ALL ("unset LC_ALL") seems to have created a 
> disturbance in the force and de_DE.UTF-8 slipped in the locale settings. WTF? 
> The only thing that I ever tell my servers about german is the keyboard 
> layout...

If you log in via ssh, the client system will also forward some locale
settings to the server, so it's possibly not the remote system's fault
when things fall over.

> # locale
> locale: Cannot set LC_ALL to default locale: No such file or directory
> LANG=en_US.UTF-8
> LANGUAGE=
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC=de_DE.UTF-8
> LC_TIME=de_DE.UTF-8
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY=de_DE.UTF-8
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER=de_DE.UTF-8
> LC_NAME=de_DE.UTF-8
> LC_ADDRESS=de_DE.UTF-8
> LC_TELEPHONE=de_DE.UTF-8
> LC_MEASUREMENT=de_DE.UTF-8
> LC_IDENTIFICATION=de_DE.UTF-8
> LC_ALL=

All the above values that do not have any "quotes" are explicitly set
in your environment, that is LC_NUMERIC LC_TIME LC_MONETARY LC_PAPER
LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION. On
top of that you have LANG=en_US.UTF-8 set; LC_ALL used to paper over
all of these.

I've found the bug: what's happening here is that the postgresql
server postinst script tries to clean up the environment and then
import the system locale before creating the initial cluster using
pg_createcluster. But the list of environment variables purged was
incomplete, some of the above values stayed around, and then
setlocale() failed because LC_IDENTIFICATION and others were invalid.
We'll include a fix for this in the next upload.

diff --git a/debian/maintscripts-functions b/debian/maintscripts-functions
index 8693cbd..e02571a 100644
--- a/debian/maintscripts-functions
+++ b/debian/maintscripts-functions
@@ -52,7 +52,7 @@ _remove_tsearch() {
 # predictable.  /etc/default/locale overrides /etc/environment. Note that
 # /etc/environment is not a shell script, so we must be careful with parsing.
 set_system_locale() {
-loc_vars="LC_COLLATE LC_CTYPE LC_MONETARY LC_MESSAGES LC_NUMERIC LC_TIME 
LC_ALL LANG LANGUAGE"
+loc_vars="LANG LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY 
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
LC_IDENTIFICATION LC_ALL"
 unset $loc_vars
 for v in $loc_vars; do
 unset val

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#797972: add sprockets tests for rails engines

[Antonio Terceiro]

On Fri, Sep 04, 2015 at 10:18:15AM +0530, Pirate Praveen wrote:
> package: gem2deb
> version: 0.20.2
> severity: wishlist
> 
> A simple test like this can test if the asset is installed correctly
> 
> rails new foo
> cd foo
> echo "//= require asset >> app/assets/javascripts/application.js
> bundle exec rake assets:precompile

you can use sprockets directly instead of a full rails app. check
debian/tests/smoke-test in ruby-bootstrap-sass for an example.

> there should be an option --check-assets to gem2deb test runner and if
> the gem name starts with rails-assets or ends with rails it should be
> enabled by default.

assuming that deriving the asset name from the package name will
actually work, there are also quite a few details to get right, such as
adding the necessary build dependencies, and handling the paths when
running during build vs running on autopkgtest (and thus with the
package already instaled) etc.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Bug#791526: [Pkg-postgresql-public] Bug#791526: Bug#791526: Bug#791526: postgresql-9.4: postgresql needs locales-all to create cluster on install

[Malte]

On Friday 04 September 2015 14:16 Christoph Berg wrote:

> I've found the bug: what's happening here is that the postgresql
> server postinst script tries to clean up the environment and then
> import the system locale before creating the initial cluster using
> pg_createcluster. But the list of environment variables purged was
> incomplete, some of the above values stayed around, and then
> setlocale() failed because LC_IDENTIFICATION and others were invalid.
> We'll include a fix for this in the next upload.

Awesome! Thank you very much!


Malte

Bug#798015: python-botocore: Update to version >= 1.0.0 is required

[Ivan Udovichenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Source: python-botocore
Version: 1.0.0
Severity: wishlist
Tags: upstream

Hello,

Please update the package to the actual release as soon as possible.
Version >= 1.0.0 is required by OpenStack components [1].
And it is a blocker for Liberty release packaging process.

The latest version:
https://pypi.python.org/pypi/botocore/1.2.0


[1]
https://github.com/openstack/requirements/blob/master/global-requirement
s.txt#L13
botocore>=1.0.0 # Apache-2.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV6ZXhAAoJEJOJk4TcLHf00AUP/jt6Iyal9BQOjTPpbu3dA0be
wL0GvI14oZAOKU89baRhV5sqCB7hNEsD/nk/G+vtMx1lmYVuMTAMXXubfmjAGqT9
PRWMPKYVkdESH0wPKCOFuxKtBurgIvicvVOGj4VisQlYpzoKEgrVe+MoL5epoq8n
6Avdw9Rx7fLuTGvl+DTc392J1A3kDprtDxz3wnSNu6EuopyXiMi5nr8rWit4fG08
262DG3kqq1WMyLXfYK7RzvTTq4g6Af4F1zhr8su+OgFFC7+ibHlyVqbWO5Ac9akH
hK9ObB9Ct2tyHj/N+35X32mqK7JkLjIRUpTI97fFwd+fwclI1WdWy/UQEmu0yg1x
h972e5OOoSvXCcUtA343ZLciPgOMToIOmF8qEL9m1tjndNBqzlsUh1SbnerVtocL
cjsBjuh4OoigVMDKnwm3Qzlr+F1Gy5oldyS5pahwJVcYbt2py/eil7IrdOv81wf6
E/WZilbE9ViV8zLTUOf7FUeWYz6O+z5LVmHSmFXUFfmZuCIAy2kfWgx8UF6aq4c3
k18O23YLxH9YA50Y81+eluuy9G765Q0urob/lmVLdWRwjxud1dug+GnTMyDVsTYc
wkb8X9E+Uk7xsTnRXUuoSWMxdLEGim2pKYSRFNyxNvin4iUuOzHQx0dliXYkw0HT
MUdHIwlq/nXYBaD3cBSr
=68qw
-END PGP SIGNATURE-

Bug#798017: cl-sql: FTBFS on most architectures

[Edmund Grimley Evans]

Source: cl-sql
Version: 6.6.3-1

It failed to build on most architectures:

https://buildd.debian.org/status/package.php?p=cl-sql=sid

Line 74 of db-mysql/Makefile is adding "-m32" to anything that isn't
amd64, I think, while only a few architectures accept that option.
(Interestingly, ppc64el does accept it.)

The same line also contains "-fPIC", although it's linking rather than
compiling at that point, and it contains $(LDFLAGS) twice. And is the
"-lc" really required?

Here's the diff between 6.6.2-1 and 6.6.3-1:

-   ld -shared -soname=$(base) $(object) $(LDFLAGS) -o $(shared_lib)
+   gcc -m32 $(LDFLAGS) -fPIC  -shared -Wl,-soname=$(base) -lc
$(object) $(LDFLAGS) -o $(shared_lib)

Maybe what's wanted is:

gcc -shared -Wl,-soname=$(base) $(object) $(LDFLAGS) -o $(shared_lib)

Bug#798010: [Python-modules-team] Bug#798010: ipython3: malicious dynamic python3 interpreter lookup via "/usr/bin/env python3" in main executable

[Scott Kitterman]

On Friday, September 04, 2015 02:30:47 PM Tobias Megies wrote:
> Package: ipython3
> Version: 2.3.0-2
> Severity: serious
> Justification: Debian Python Policy 2.4.2: Interpreter Location
> 
> Dear Maintainer,
> 
> the main executable /usr/bin/ipython3 has shebang line 1 "#!/usr/bin/env
> python3" and thus uses the first python3 interpreter found in $PATH doing a
> dynamic lookup at execution time.
> If a local user-space Python environment is coming first in $PATH it will
> thus yield the Python3 IPython prompt from user space and not from the
> system python. This will result in very puzzling situation and clearly is
> in violation of the Debian Python Policy which demands the hardcoded system
> python binary in shebang.
> 
> See Debian Python Policy 2.4.2 Interpreter location:
> https://www.debian.org/doc/packaging-manuals/python-policy/ch-> 
> python.html#s-interpreter_loc
> 
> === quote start
> The preferred specification for the Python interpreter is /usr/bin/python or
> /usr/bin/pythonX.Y. This ensures that a Debian installation of python is
> used and all dependencies on additional python modules are met.
> Maintainers should not override the Debian Python interpreter using
> /usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it
> bypasses Debian's dependency checking and makes the package vulnerable to
> incomplete local installations of python.
> === quote end

First, Python policy is not Debian policy, so violating it doesn't 
automatically make a serious bug.  Second, the policy says preferred and 
should quite deliberately as the /usr/bin/env approach is quite common in the 
Python world and we do not want to force maintainers to patch large numbers of 
packages to avoid it.

Scott K

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

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Agustin Martin]

On Mon, Aug 31, 2015 at 08:29:19AM -0700, Josh Triplett wrote:
> On Fri, 21 Aug 2015 10:43:56 +0100 Tim-Philipp =?ISO-8859-1?Q?M=FCller?= 
>  wrote:
> > This looks at first glance like some GStreamer element(s) could not be
> > created, such as appsink, maybe others too; possibly because the
> > required GStreamer plugins are not installed. Combined with insufficient
> > error handling.
> > 
> > I note that this bug was reported against an iceweasel version that uses
> > the old and unmaintained GStreamer 0.10.x.
> > 
> > The current iceweasel version uses GStreamer 1.x, and I can't reproduce
> > this problem with 38.2.0esr-1 either.
> 
> I can reproduce this problem with 38.2.1esr-1 in unstable as well as
> 40.0.3-1 in experimental.  Vising any page embedding video (including
> YouTube or Twitter) crashes Iceweasel as soon as the video would start
> to play.
> 
> I have gstreamer1.0-plugins-base 1.4.5-2,
> gstreamer1.0-plugins-{good,bad,ugly} 1.4.5-2+b2, and gstreamer1.0-libav
> 1.4.5-3.

Hi,

This may well be the same gstreamer1.0-plugins-bad problem reported in
http://bugs.debian.org/797227.

-- 
Agustin

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Fabio Natali]

On 04/09/15 14:30, Agustin Martin wrote:
[...]
> This may well be the same gstreamer1.0-plugins-bad problem reported in
> http://bugs.debian.org/797227.

Hi,

I can confirm that removing gstreamer1.0-plugins-bad solves the issue
here. (Btw, upgrading to the 1.5.90-1 version from Experimental didn't
help.)

Thanks a lot Agustin!

Fabio

-- 
Fabio Natali
http://fabionatali.com

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Guillaume Dupuy]

Le 04/09/2015 15:30, Agustin Martin a écrit :
Hi, This may well be the same gstreamer1.0-plugins-bad problem 
reported in http://bugs.debian.org/797227. 
Indeed, updating gstreamer1.0-plugins-bad to the experimental version 
solved this problem

Bug#795330: [Xen-devel] [Pkg-xen-devel] Bug#795330: Suggests noapic but doesn't support it

[David Vrabel]

On 04/09/15 15:13, Ian Campbell wrote:
> On Fri, 2015-09-04 at 15:04 +0100, David Vrabel wrote:
>> On 04/09/15 14:38, Ian Campbell wrote:
>>> Control: tag -1 upstream 
>>>
>>> Jan/Andy & David,
>>>
>>> Is there anything we can improve here on either the Xen or kernel side 
>>> do
>>> you think?
>>>
>>> On Thu, 2015-08-13 at 00:59 +0200, Guido Günther wrote:
 Package: xen-hypervisor-4.5-amd64
 Severity: normal

 Hi,
 when running xen inside of kvm the hypervisor fails to set up the 
 proper
 IRQ routing and suggests to use noapic.
>>>
>>> FTR, it seems to say:
>>>
>>> panic("IO-APIC + timer doesn't work!  Boot with 
>>> apic_verbosity=debug "
>>>   "and send a report.  Then try booting with the 'noapic' 
>>> option");
>>
>> This is the Linux kernel making a recommendation for its command line.
> 
> I cut-n-paste that message from xen.git. Although maybe in a file which
> originates in Linux.
> 
> (So now I realised I don't really know which entity was complaining)

Oh, in which case removing (from Xen) the recommendation to try noapic
might be useful.

David

Bug#798009: ITP: python-editor -- programmatically open an editor, capture the result

[Guido Günther]

Hi,
On Fri, Sep 04, 2015 at 02:30:26PM +0200, Thomas Goirand wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Thomas Goirand 
> 
> * Package name: python-editor
>   Version : 0.4
>   Upstream Author : Peter Ruibal 
> * URL : https://github.com/fmoo/python-editor
> * License : Apache-2.0
>   Programming Lang: Python
>   Description : programmatically open an editor, capture the result
> 
>  python-editor is a library that provides the editor module for
>  programmatically interfacing with your system's $EDITOR. The user can then
>  enter a commit message for example.
>  .
>  Editor first looks for the ${EDITOR} environment variable.  If set, it uses
>  the value as-is, without fallbacks. If no $EDITOR is set, editor will search
>  through a list of known editors, and use the first one that exists on the
>  system. For example, on Linux, editor will look for the following editors in
>  order:
>   * vim
>   * emacs
>   * nano
>  .
>  When calling the edit() function, editor will open the editor in a
>  subprocess, inheriting the parent process's stdin, stdout

Given that this is on Debian should it take sensible-editor into account
form the start?
Cheers,
 -- Guido

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Diederik de Haas]

On Friday 04 September 2015 15:53:23 Guillaume Dupuy wrote:
> Le 04/09/2015 15:30, Agustin Martin a écrit :
> > Hi, This may well be the same gstreamer1.0-plugins-bad problem
> > reported in http://bugs.debian.org/797227.
> 
> Indeed, updating gstreamer1.0-plugins-bad to the experimental version
> solved this problem

Same here. Thank you very much :)


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

Bug#797992: [Pkg-octave-devel] Bug#797992: Bug#797992: octave: ABI transition needed for libstdc++ v5

[Sébastien Villemot]

Le vendredi 04 septembre 2015 à 12:57 +0200, Rafael Laboissiere a
écrit :
> * Simon McVittie  [2015-09-04 10:16]:
> 
> > On Fri, 04 Sep 2015 at 10:00:04 +0100, Simon McVittie wrote:
> >> Looking at the C++ library build-dependencies of octave, it is
> >> waiting for hdf5 (#791067) but everything else seems to be ready.
> >
> > Looking more closely at this, hdf5 has both a C and a C++ API, 
> > and octave appears to only use the C. If this is correct, then it does 
> > not need to wait for hdf5 after all.
> 
> The liboctave3 package, version 4.0.0-3 in both unstable and testing, 
> depends on libstdc++6 >= 5.2.  This package does not exist in stable.  Is 
> a rebuild really necessary?

I confirm that the problem described by Simon is real, and that a
transition is needed.

For example, using octave (4.0.0-3) and octave-optim (1.4.1-1) from
unstable, one gets:

octave:1> numhessian
error: 
/usr/lib/x86_64-linux-gnu/octave/packages/optim-1.4.1/x86_64-pc-linux-gnu-api-v50+/numhessian.oct:
 failed to load: 
/usr/lib/x86_64-linux-gnu/octave/packages/optim-1.4.1/x86_64-pc-linux-gnu-api-v50+/numhessian.oct:
 undefined symbol: _ZNK5ArrayISsE17resize_fill_valueEv

The problematic symbol is:

$ c++filt _ZNK5ArrayISsE17resize_fill_valueEv
Array >::resize_fill_value() const

It has indeed to do with std::string.

Simon: I should take care of uploading a fixed octave package this
week-end (provided that HDF5 is indeed not a blocker). But feel free to
NMU if I don't act quickly enough.

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594

Bug#798013: doc-debian: useless "Suggests: postscript-viewer, www-browser"

[Jakub Wilk]

Package: doc-debian
Version: 6.3
Severity: minor

doc-debian suggests postscript-viewer and www-browser, even though it 
doesn't ship any PostScript or HTML files.


--
Jakub Wilk

Bug#797023: Fwd: [PATCH 3.16.y-ckt 125/130] s390/sclp: fix compile error

[Stephen Powell]

Forwarding to the Debian bug log

- Forwarded Message -
From: Luis Henriques 
To: linux-ker...@vger.kernel.org, sta...@vger.kernel.org, 
kernel-t...@lists.ubuntu.com
Cc: Sebastian Ott , Martin Schwidefsky 
, Stephen Powell , Luis Henriques 

Sent: Fri, 04 Sep 2015 09:08:33 -0400 (EDT)
Subject: [PATCH 3.16.y-ckt 125/130] s390/sclp: fix compile error

3.16.7-ckt17 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Sebastian Ott 

commit a313bdc5310dd807655d3ca3eb2219cd65dfe45a upstream.

Fix this error when compiling with CONFIG_SMP=n and
CONFIG_DYNAMIC_DEBUG=y:

drivers/s390/char/sclp_early.c: In function 'sclp_read_info_early':
drivers/s390/char/sclp_early.c:87:19: error: 'EBUSY' undeclared (first use in 
this function)
   } while (rc == -EBUSY);
   ^

Signed-off-by: Sebastian Ott 
Signed-off-by: Martin Schwidefsky 
Cc: Stephen Powell 
Signed-off-by: Luis Henriques 
---
 drivers/s390/char/sclp_early.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/s390/char/sclp_early.c b/drivers/s390/char/sclp_early.c
index 1918d9dff45d..45c3d7041c81 100644
--- a/drivers/s390/char/sclp_early.c
+++ b/drivers/s390/char/sclp_early.c
@@ -7,6 +7,7 @@
 #define KMSG_COMPONENT "sclp_early"
 #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
 
+#include 
 #include 
 #include 
 #include 

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

Bug#795330: [Pkg-xen-devel] Bug#795330: Suggests noapic but doesn't support it

[Ian Campbell]

Control: tag -1 upstream 

Jan/Andy & David,

Is there anything we can improve here on either the Xen or kernel side do
you think?

On Thu, 2015-08-13 at 00:59 +0200, Guido Günther wrote:
> Package: xen-hypervisor-4.5-amd64
> Severity: normal
> 
> Hi,
> when running xen inside of kvm the hypervisor fails to set up the proper
> IRQ routing and suggests to use noapic.

FTR, it seems to say:

panic("IO-APIC + timer doesn't work!  Boot with apic_verbosity=debug "
  "and send a report.  Then try booting with the 'noapic' option");

Did you also try the first thing it suggested? What was the result?

>  If you add this via
> 
> GRUB_CMDLINE_XEN_DEFAULT
> 
> it will boot futher but then report that noapic isn't supported.

Is this the kernel saying that or Xen? Do you have full boot logs?

I think it is the kernel since I can't find such a message in Xen and 
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html says for
the noapic option: "This is not recommended with pvops type kernels."

> So please make Xen not claim to support noapic if it doesn't

I think ultimately this is down to different components being able to
support different things, e.g. Xen's advice might be fine with a FreeBSD
dom0 or some other version of Linux.

>  (the issue
> was finally resolved by removeing all virtion devices and doubling the

^virtio ?

> hypervisors RAM so the suggestion was misplaced anyways).

I can see how the virtio thing might make the KVM guest look different to
Xen, but the RAM thing seems orthogonal.

Thanks,
Ian.

Bug#787724: Confirmed

[David Kalnischkies]

Hi Paolo,

On Fri, Sep 04, 2015 at 12:13:21PM +0200, Paolo Cavallini wrote:
> Confirmed here, with several different repos:
> Ign http://ftp.no.debian.org jessie
> InRelease/partial/ftp.no.debian.org_debian_dists_jessie_InRelease into
> data and signature failed
> Fetched 2,823 B in 9s (307 B/s)
> E: GPG error: http://ftp.no.debian.org jessie InRelease: Clearsigned
> file isn't valid, got 'NODATA' (does the network require authentication?)

/var/lib/apt/lists/partial should contain the 'bad' InRelease file
(potentially with the .FAILED extension). Also, running
apt-get update -o Debug::Acquire::http=1
might reveal something interesting.

Also, what version of apt and libapt is used here?
Any configuration derivation you might want to tell us about?

But as Julian said, this is likely a temporary problem of the involved
server and not of the client.


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Bug#797227: segfault - gst_memory_unmap, libgstreamer

[Agustin Martin]

On Wed, Sep 02, 2015 at 12:18:28PM +0300, Sebastian Dröge wrote:
> On Mi, 2015-09-02 at 17:32 +0900, Changwoo Ryu wrote:
> > Yes, I just have tested the patch on faad plugin at the GNOME 
> > bugzilla 748571. And it fixes the problem.
> 
> Thanks for testing, 

Hi,

Also tested here with a personal package rebuild including that fix.
Problem seems fixed with it.

> question is if I should upload a new package with
> the fix to unstable or we just wait until 1.6.0 is released... which
> should happen in the next week or two.

I'd upload a new package with the fix. Even if upstream releases soon, new
package may need some extra work and delay the fix even more.

By the way, iceweasel's http://bugs.debian.org/788708 seems to be the same
problem.

Regards,

-- 
Agustin

Bug#781485: libeatmydata: does not seem to be working with regular binaries

[Mattia Rizzolo]

On Wed, Aug 05, 2015 at 01:41:22PM +0530, Ritesh Raj Sarraf wrote:
> Today, I noticed (when running chromium from the shell) that eatmydata
> was not into aciton.. :-(
> 
> I can go and create the symlink manually, but shouldn't the package take
> care of it ?
> 
> rrs@learner:~$ chromium --touch-devices=2
> [7722:7722:0805/133119:ERROR:nss_util.cc(856)] After loading Root Certs, 
> loaded==false: NSS error code: -8018
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> 
> 
> rrs@learner:/usr/share/doc/eatmydata$ which chromium
> /home/rrs/bin/chromium
> 2015-08-05 / 13:39:36 ♒♒♒  ☺
> 
> rrs@learner:/usr/share/doc/eatmydata$ file /home/rrs/bin/chromium
> /home/rrs/bin/chromium: symbolic link to /usr/bin/eatmydata
> 2015-08-05 / 13:39:42 ♒♒♒  ☺

I forgot to follow up here, but I investigated with rrs on IRC, and
concluded this is a chromium issue.

From #debian-devel, 2015-08-05:

[11:09:38]  RickXy: you know what? i've never used libeatmydata with 
with the symlink mode :) what do you mean by "I can go and create the symlink 
manually, but shouldn't the package take care of it ?" eatmydata does have no 
symlink to create. i think that's just another bug.
[11:10:43]  mapreri: Whatever it is complaining about.
[11:12:03]  mapreri: Earlier, when hit in the pbuilder environment, the 
workaround was to create a symlink.
[11:12:23]  RickXy: is that >= jessie?
[11:12:58]  I guess. But I'm not sure.
[11:14:29]  mapreri: Should be Jessie. Because the issues is not older 
than  a year.
[11:20:41]  mapreri: Do you have any idea why that error pops ?
[11:21:00]  RickXy: the fact that the symlink mode does not work is 
another bug. but i just tried and i think that's something chromium specific
[11:21:49]  mapreri: Hmmm... Let me verify if it is not reproducible 
with other binaries.
[11:22:41]  it might very well be that it uses a personal 
LD_LIBRARY_PATH
[11:23:47]  mapreri: Indeed.
[11:24:05]  mapreri: chromium is a shell script, and there, it has its 
own LD_LIBRARY_PATH
[11:24:40] * RickXy needs to file a new bug against chromium
[11:25:53]  RickXy: if you do you can look at the bottom of 
/usr/bin/eatmydata on a nice syntax to not overwrite the veriable content

-- 
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#798020: libgsmme1c2a: gsmsendsms stopped sending sms after upgrade to jessie

[Arne Rusek]

Package: libgsmme1c2a
Version: 1.10+20120414.gita5e5ae9a-0.2
Severity: normal

Dear Maintainer,

after upgrade to jessie gsmsendsms program, which uses this library stopped
working with my modem. Downgrade to wheezy version of gsm-utils didn't help.
Downgrade to wheezy version of gsm-utils AND libgsmme1c2a worked and sms are
being sent normally.

gsmsendsms sends following commands to my modem:
root@sith(0)bin# strace -e trace=write -f -s 1000 gsmsendsms -b 9600 --sca 
+420603052000 -d /dev/ttyS0 "+420732673195" "hello"
write(3, "ATZ\r", 4)= 4
write(3, "ATE0\r", 5)   = 5
write(3, "AT+CMEE=1\r", 10) = 10
write(3, "AT+CMGF=0\r", 10) = 10
write(3, "AT+CGMI\r", 8)= 8
write(3, "AT+CGMM\r", 8)= 8
write(3, "AT+CGMR\r", 8)= 8
write(3, "AT+CGSN\r", 8)= 8
write(3, "AT+CSMS?\r", 9)   = 9
write(3, "AT+CSCS=\"GSM\"\r", 14)   = 14
write(3, "AT+CSMS=1\r", 10) = 10
write(3, "AT+CMGS=19\0\r", 11)  = 12
write(2, "gsmsendsms", 10gsmsendsms)  = 10
write(2, "[ERROR]: ", 9[ERROR]: )= 9
write(2, "timeout when reading from TA (errno: 0/Success)", 47timeout when 
reading from TA (errno: 0/Success)) = 47
write(2, "\n", 1)   = 1
+++ exited with 1 +++

whereas wheezy's version doesn't send \0 in AT+CMGS=19 command and it
works like charm. Seems my modem doen't take \0 well in AT+CMGS=...

in wheezy, the strace ends like this:

[...]
write(3, "AT+CSMS=1\r", 10) = 10
write(3, "AT+CMGS=19\r", 11)= 11
write(3, "079124603050020015000C91247023761359A805E8329BFD06\32", 55) = 55
+++ exited with 0 +++

there's my modem info:

AT+CGMI
 WAVECOM MODEM

OK
AT+CGMM
 MULTIBAND  900E  1800 

OK
AT+CGMR
430a09gm.2C 1208244 110801 19:19

OK
AT+CGSN
332055330434650

OK
AT+CSMS?
+CSMS: 1,1,1,1

OK

Your sincerely,
Arne Rusek

-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'oldstable')
Architecture: i386 (i686)

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

Versions of packages libgsmme1c2a depends on:
ii  libc6  2.19-18
ii  libgcc11:4.9.2-10
ii  libstdc++6 4.9.2-10
ii  multiarch-support  2.19-18

libgsmme1c2a recommends no packages.

libgsmme1c2a suggests no packages.

-- no debconf information

Bug#785557: in QEMU bug tracker?

[Chad William Seys]

Hi All,
I tried to find this bug in QEMU's bug tracker, but failed.  Also, it doesn't 
look like the messages to the mailing list:
http://lists.gnu.org/archive/html/qemu-devel/2015-06/msg01295.html
are getting much attention.

Perhaps opening a bug in QEMU's bug tracker would be useful?  (Or I missed 
it.)

Thanks!
C.

Bug#732242: general: CPU fan always on (high speed)

[Pétur Viljamson]

Hi,

On a fresh install of Debian, the installation of i8kutils makes the fan
starts and stops every 5 seconds approximately. This problem is present on
Debian stable and unstable and is, of course, restricted to some DELL
laptops (mine is the latitude 6430u).

I did some research:

The problem seems to be the BIOS fan control which is not desactivated when
i8kmon is working. Both BIOS and i8kmon are trying to handle the fan and
the BIOS cancels every action from i8kmon. The consequency is the fan
start/stop/change speed for few seconds (because i8kmon commands) and the
BIOS takes again control of the fan and the fan modifications is reversed.

There are two solutions:
  1. Just delete i8kutils package and the system will handle the fan
via the BIOS. It's working but some BIOSes do a poor job. The laptop could
be noisy, the fan could be always on (it's the case on my latitude 6430u)
and you will maybe lose autonomy.
  2. There is a way to desactivate the BIOS fan control. After that
i8kmon could do this job and controlling fans. I'm using this solution and
it is working. I describre this solution below.

i8kutils should be fixed for disabling BIOS fan control out of the box.


---

Details of solution 2 :

The package i8kutils contains Disable BIOS-Fan-Control

Step 1: Compiling

# apt-get install gcc-4.6-multilib
$ cd ~
$ mkdir .bin
$ cd .bin
# apt-get source i8kutils
# apt-get build-dep i8kutils
$ tar xf i8kutils_1.41.tar.xz
$ cd i8kutils-1.41
# gcc -g -O2 -Wall -I. -o smm -m32 smm.c
# ./smm 30a3
# cp smm /usr/sbin/

After step 1, you should have access to these two commands:

# /usr/sbin/smm 30a3 # disable the BIOS fan control
# /usr/sbin/smm 31a3 # enable the BIOS fan control

i8kmon should working after launching "/usr/sbin/smm 30a3"

Step 2: setup i8kmon to stop the bios-fan-control automatically
# nano /etc/init.d/i8kmon

Find the following:
case „$1″ in
start)
log_daemon_msg „Starting $DESC“ „$NAME“

And change it into:
case „$1″ in
start)
/usr/sbin/smm 30a3
log_daemon_msg „Starting $DESC“ „$NAME“

In the same file find the following:
stop)
log_daemon_msg „Stopping $DESC“ „$NAME“

And change it into:
stop)
/usr/sbin/smm 31a3
log_daemon_msg „Stopping $DESC“ „$NAME“

This will disable Bios-Fan-Control directly while starting i8kmon. And
enable it while shutting down the service i8kmon.

Step 3: adjust the way i8kmon handle fans. i8kmon config is for 2 fans
computers. If you have only one fan, you should change it.

# nano /etc/i8kmon.conf

Change to the following:

# Automatic fan control, override with –auto option
set config(auto)1

# Automatic fan control, override with –auto option
# Adjust this for your number of fan.
set config(auto)1

set config(0)  {{-1 0}  -1  30  -1  30}
set config(1)  {{-1 0}  30  50  30  50}
set config(2)  {{-1 1}  45  60  45  60}
set config(3)  {{-1 2}  55 128  55 128}

# end of file

The last block in this file controls the fan-speed based on temperatures.
Here is how to read the block:
{{ -1 0} -1 30 -1 30}
{{ first_fan_speed second_fan_speed} low_temp_on_ac high_temp_on_ac
low_temp_on_bat high_temp_on_bat}

Because the Dell Latitude has no first fan, we can setup the first fan
always to „-1″


I find these informations here:

http://www.linux-hell.com/2015/04/11/temperature-control-on-dell-latitude-e7440-under-ubuntu-14-04-2-lts/


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

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

Versions of packages i8kutils depends on:
ii  acpi1.7-1
ii  libc6   2.19-19
ii  tcl 8.6.0+8
ii  tclx8.4 [tclx]  8.4.1-1
ii  tk  8.6.0+8

i8kutils recommends no packages.

i8kutils suggests no packages.

-- Configuration Files:
/etc/init.d/i8kmon changed:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
. /lib/lsb/init-functions
NAME=i8kmon
DAEMON=/usr/bin/i8kmon
PROC_I8K=/proc/i8k
DESC="Dell fan/cpu-temperature monitor"
I8KMON_ARGS="--daemon --nouserconfig --auto"
PIDFILE=/var/run/$NAME.pid
test -x $DAEMON || exit 5
if [ -f /etc/default/$NAME ] ; then
. /etc/default/$NAME
fi
case "$1" in
start)
 /usr/sbin/smm 30a3
log_daemon_msg "Starting $DESC" "$NAME"
modprobe i8k >/dev/null 2>&1 || true
if [ ! -f "$PROC_I8K" ]; then
log_progress_msg "Could not find $PROC_I8K."
log_end_msg 1
exit 1
fi
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--background --make-pidfile --startas $DAEMON -- $I8KMON_ARGS
log_end_msg $?
;;
stop)
/usr/sbin/smm 31a3
log_daemon_msg "Stopping $DESC" "$NAME"

Bug#795330: [Xen-devel] [Pkg-xen-devel] Bug#795330: Suggests noapic but doesn't support it

[Ian Campbell]

On Fri, 2015-09-04 at 15:04 +0100, David Vrabel wrote:
> On 04/09/15 14:38, Ian Campbell wrote:
> > Control: tag -1 upstream 
> > 
> > Jan/Andy & David,
> > 
> > Is there anything we can improve here on either the Xen or kernel side 
> > do
> > you think?
> > 
> > On Thu, 2015-08-13 at 00:59 +0200, Guido Günther wrote:
> > > Package: xen-hypervisor-4.5-amd64
> > > Severity: normal
> > > 
> > > Hi,
> > > when running xen inside of kvm the hypervisor fails to set up the 
> > > proper
> > > IRQ routing and suggests to use noapic.
> > 
> > FTR, it seems to say:
> > 
> > panic("IO-APIC + timer doesn't work!  Boot with 
> > apic_verbosity=debug "
> >   "and send a report.  Then try booting with the 'noapic' 
> > option");
> 
> This is the Linux kernel making a recommendation for its command line.

I cut-n-paste that message from xen.git. Although maybe in a file which
originates in Linux.

(So now I realised I don't really know which entity was complaining)

> > Did you also try the first thing it suggested? What was the result?
> > 
> > >  If you add this via
> > > 
> > > GRUB_CMDLINE_XEN_DEFAULT
> > > 
> > > it will boot futher but then report that noapic isn't supported.
> 
> Don't add Linux command line options to the Xen command line.
> 
> David
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> http://lists.xen.org/xen-devel

Bug#741573: Comparison of Options AB and D

[Ian Jackson]

Sam Hartman writes ("Bug#741573: Comparison of Options AB and D"):
> I agree that we should not pick an entirely new design.
> Here though, option D  does not pick an entirely new design.

Option D does something much much worse.  It

 - mandates that an new design[1] must be invented

 - explicitly says that in the meantime the people must work
to delete the data represented according to the existing design

[1] By which I mean a specification for how to represent the existing
trad menu metadata database in .desktop files.


I think the TC forcing a transition like this, off its own bat, is an
absolutely appalling idea.

Note that neither of the sides in this debate actually want this
outcome.  The trad menu's vigorous opponents simply want the trad menu
to go away.  The trad menu proponents want to keep it as it is.

There are some people on the .desktop side who find the multiplicity
of formats annoying.  For them there is a compromise possible (as I
outlined) involving generating trad menu metatdata in .debs from
.desktop files in sources.

But doing that would not need any significant policy change.  If a
maintainer of a package which has a .desktop file wants to arrange to
have their trad menu entry generated from the .desktop file there is
nothing stopping them doing so.  (It would need a tiny amount of
technical work on the existing  translator.)


At the very least, if the TC is going to force this issue in this way,
there should be:

 (a) A grace period for the new design to be worked out before the TC
 mandates that existing data should start to be deleted from
 Debian.

 (b) An explicit statement that when transitioning from trad menu
 files to .desktop files, the existing data, currently in the trad
 menu files, must be transferred to the .desktop files.  (Assuming
 that by the end of the grade period the appapriate design and
 infrastructure exists.)

 (c) A statement about who is to approve the new design, so that it is
 not possible for those who want to simply abolish the trad menu
 to block (b) by preventing (a).

I think this is an impractical way forward.  It effectively requires
the trad menu maintainers to specify an extension to the XDG desktop
file format, and to implement the necessary translation in code which
is owned by people from the XDG side.

But IMO it is the very minimum.

Ian.

Bug#794071: [Pkg-xen-devel] Bug#794071: "xenconsole: Could not open tty `': No such file or directory" during PV guest boot

[Ian Campbell]

On Thu, 2015-07-30 at 09:41 +, Andy Smith wrote:
> Package: xen-utils-common
> Version: 4.4.1-9+deb8u1
> Severity: normal
> 
> Dear Maintainer,
> 
> When booting a PV guest (xl create -c /etc/xen/foo.conf), immediately
> after pygrub has determined which kernel/initramfs it will use, the
> following error messages are logged:
> 
> xenconsole: Could not open tty `': No such file or directory
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console 
> child [0] exited with error status 2

This sounds a bit like the issue fixed by
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=39ba2989b10b6a1852e253b204eb010f8e7026f1

Are you able to run a new Xen (either 4.5.1~rc1-1 from experimental or an
upstream version would do) to confirm?

(I've also asked for that commit to be backported upstream, since it is
certainly a fix for something even if not this issue)

Thanks,
Ian.

> 
> The boot does however continue normally including all expected console
> output from the guest. The resulting console is perfectly usable once
> the guest's login prompt is reached.
> 
> Then, once the console is exited with ctrl-], the terminal settings are
> messed up such that no text is echoed and pressing return does not
> advance to the next line. Terminal usability can be restored by using
> "stty sane" or "reset" at this point.
> 
> Searching the web for the above error messages only reveals people who
> say that xenconsoled wasn't running, however in this case xenconsoled
> *is* running (and the console does work, both continuing from the "xl
> create -c …" and also if connected to with "xl console …").
> 
> Here is an example guest config:
> 
> name   = "debtest1"
> memory = 1024
> vif= [ "mac=00:16:5e:00:02:39, ip=192.168.82.225, vifname=v
> -debtest1" ]
> bootloader = "/usr/lib/xen-default/bin/pygrub"
> disk   = [ "phy:/dev/vg/debtest1_xvda,xvda,w",
>"phy:/dev/vg/debtest1_xvdb,xvdb,w", ]
> 
> The kernel command line that pygrub will extract is:
> 
> linux (kernel )(ramdisk 
> )(args "root=UUID=bb7a41e3-67f4
> -436a-8a80-07ec26573360 ro console=hvc0")
> 
> however it happens with all my guests regardless of distribution or
> version.
> 
> -- System Information:
> Debian Release: 8.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages xen-utils-common depends on:
> ii  lsb-base4.1+Debian13+nmu1
> ii  python  2.7.9-1
> ii  ucf 3.0030
> ii  udev215-17+deb8u1
> ii  xenstore-utils  4.4.1-9+deb8u1
> 
> xen-utils-common recommends no packages.
> 
> xen-utils-common suggests no packages.
> 
> -- Configuration Files:
> /etc/xen/scripts/vif-route changed [not included]
> /etc/xen/xl.conf changed [not included]
> 
> -- no debconf information
> 
> ___
> Pkg-xen-devel mailing list
> pkg-xen-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel

Bug#798018: python-taskflow: Python 3 supported upstream but not packaged

[Daniel Watkins]

Package: python-taskflow
Version: 0.7.1-0ubuntu1
Severity: wishlist

Dear Maintainer,

The upstream of python-taskflow support Python 3, but this isn't
packaged for Debian.  I would like to be able to use taskflow in Python
3 projects, but that isn't currently possible on Debian. :)

Please consider producing a python3-taskflow package.


Thanks,

Dan


P.S. I've filed a similar bug in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/python-taskflow/+bug/1492267

Bug#776096: bsdmainutils: hexdump fails if format_string contains backslash

[Rémi Rampin]

There's actually another bug in escape(): the terminating null byte
doesn't break out of the loop if the last character is a backslash.
You can't see the garbage that gets copied to the buffer because the
null byte gets copied, the the overrun does happen.

New patch that also addresses that.
--- bsdmainutils/usr.bin/hexdump/parse.c2015-09-04 09:04:57.0 
-0400
+++ bsdmainutils/usr.bin/hexdump/parse.c2015-09-04 10:12:27.705336045 
-0400
@@ -454,10 +454,6 @@
 
/* alphabetic escape sequences have to be done in place */
for (p2 = p1;; ++p1, ++p2) {
-   if (!*p1) {
-   *p2 = *p1;
-   break;
-   }
if (*p1 == '\\')
switch(*++p1) {
case 'a':
@@ -486,6 +482,10 @@
*p2 = *p1;
break;
}
+   else
+   *p2 = *p1;
+   if(!*p1)
+   break;
}
 }
 

Bug#797888: RFS: panda3d/1.9.0-1

[Jörn Schönyan]

Hi,

I did care about 1, 3, 4 and 6.

2) Tried to set myself as owner, but I'm unsure if that was correct - I 
guess not. bugs.debian.org is a bit tricky imho.


5) I did apply for membership something like a week ago, but nothing 
hapenned yet. But I really think working together with the pkg-games team 
would be beneficial.


Best regards

Bug#795330: [Pkg-xen-devel] Bug#795330: Suggests noapic but doesn't support it

[David Vrabel]

On 04/09/15 14:38, Ian Campbell wrote:
> Control: tag -1 upstream 
> 
> Jan/Andy & David,
> 
> Is there anything we can improve here on either the Xen or kernel side do
> you think?
> 
> On Thu, 2015-08-13 at 00:59 +0200, Guido Günther wrote:
>> Package: xen-hypervisor-4.5-amd64
>> Severity: normal
>>
>> Hi,
>> when running xen inside of kvm the hypervisor fails to set up the proper
>> IRQ routing and suggests to use noapic.
> 
> FTR, it seems to say:
> 
> panic("IO-APIC + timer doesn't work!  Boot with apic_verbosity=debug "
>   "and send a report.  Then try booting with the 'noapic' option");

This is the Linux kernel making a recommendation for its command line.

> Did you also try the first thing it suggested? What was the result?
> 
>>  If you add this via
>>
>> GRUB_CMDLINE_XEN_DEFAULT
>>
>> it will boot futher but then report that noapic isn't supported.

Don't add Linux command line options to the Xen command line.

David

Bug#798016: python-dateutil: Update to version 2.4.2 is required

[Ivan Udovichenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Source: python-dateutil
Version: 2.4.2
Severity: wishlist
Tags: upstream

Hello,

Please update the package to the actual release as soon as possible.
Version 2.4.2 is required by OpenStack components [1].
And it is a blocker for Liberty release packaging process.

The latest version:
https://pypi.python.org/pypi/python-dateutil/2.4.2


[1]
https://github.com/openstack/requirements/blob/master/global-requirement
s.txt#L170
python-dateutil>=2.4.2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV6Zg9AAoJEJOJk4TcLHf0ltgP/2ZC63VxmRxAFN95/pb+IMKc
WTEZnM0ZGS/BdZzCX4rhx3lcdrPsiCt4feoIw/CTtRgtIRlDcBN7ya/1AHOz7ing
uq22EXn4VVwFWox90jt8yeeIbajnMnagli7hkeEwATr/8MsLbYVr0u2fT78739It
GDCSud1/5Uh5OhW8JTkd6WCd8AsD9z8gMa/ibLCeHic5w6lscL7Q0aVhgwobKGOB
xUmio+vs7IqDvfgRlCsB1XR/EwzdZYphCpFl+iD51hbX3sH7nCxDTql27+bSejfN
f9v2A8EeLuFb3onkTNsaQ/p9ezBznbZ+y470zfq2WDEwKo5QJmJAfdzCr9HONbor
oJGWQlt6L+LaXojgv5IDaorAuADMwnvWVLjEjUap607zQH64W5FJbKbMX6lCoIYi
0aH1T3KtzaHDVlBWAEzp9I54MOpRyjNCOZZ7Ll5PafjAZzQiBjz/KeVBsGVqherh
Nqouszyfs6+wVCsaBdUAdtCITRMtqUnWn5U5q8Dgfz+0Ieh6CQHX4RTVEuThXlK+
eZbf2+gD+7qCWV5thLJ39R4n99q6ZEtHjahMQ1IAkpn5FqCZP4oPDWPcQ1ac9Nvu
DCw9zcFqmePVxEuMPc1i4ESiuve3S//99EITd2jZhICR30h2FASQEbRTccpdQrYr
3jUs1szlogMW8fyYZVqB
=JcwC
-END PGP SIGNATURE-

Bug#763102: [Pkg-xen-devel] Bug#763102: xen-utils-common: xen-init-list fails to parse xm output -> cannot shutdown domains with service xendomains

[Ian Campbell]

Control: tag -1 -moreinfo

On Sun, 2015-08-23 at 16:33 +0200, Volker Klasen wrote:
> > 
> > I've updated the feature/bug763102 with the following extra patch:
> 
> With both your patches applied, xen-init-list works.

Thanks for confirming.

Ian.

Bug#776096: bsdmainutils: hexdump fails if format_string contains backslash

[Rémi Rampin]

Nevermind, I found the bug in the source. It actually fumbles if the
backslash *isn't the last character in the format unit*.

New patch attached, fixes up escape() in hexdump/parse.c

I don't know if there is an upstream to report this to, but other
distributions are affected.
--- bsdmainutils/usr.bin/hexdump/parse.c 2015-09-04 09:04:57.0 -0400
+++ bsdmainutils/usr.bin/hexdump/parse.c 2015-09-04 09:04:57.0 -0400
@@ -454,10 +454,6 @@
 
/* alphabetic escape sequences have to be done in place */
for (p2 = p1;; ++p1, ++p2) {
-   if (!*p1) {
-   *p2 = *p1;
-   break;
-   }
if (*p1 == '\\')
switch(*++p1) {
case 'a':
@@ -486,6 +482,11 @@
*p2 = *p1;
break;
}
+else {
+*p2 = *p1;
+if(!*p1)
+break;
+}
}
 }
 

Bug#797571: RM: gnome-do -- RoQA; abandoned

[Andreas Henriksson]

Hello!

On Fri, Sep 04, 2015 at 01:39:34PM +0100, Iain Lane wrote:
> tags 797571 + moreinfo
> thanks
> 
> On Mon, Aug 31, 2015 at 06:12:47PM +0200, Andreas Henriksson wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > Please remove this package which is a (direct or indirect) reverse
> > dependency of gnome-desktop-sharp2, see #797567, which in turn is a
> > reverse dependency of gtkhtml3.14, see #797441
> 
> We might want to keep this one - I just pinged RAOF to check.
> 
> Please wait a little bit before removing.

For what it's worth

Short-term "fixing" gnome-desktop-sharp2 to not depend on gtkhtml is as
easy as dropping the bindings which is unused.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797567#19
(This would mean you still block the gnome-desktop removal though, see
#721079.)

If you're aiming at a more complete fix, then getting rid of the
gnome-desktop dependency would be useful.  I've quickly looked into
gnome-do sources and it seems the only dependency is on using the
thumbnails functionality (but I might have missed something).

See ./Do.Platform.Linux/src/Do.Universe/Desktop.cs which exposes a few
Thumbnail* functions.

The only caller of these seems to be in
./Do.Platform.Linux/src/Do.Universe/FileItem.cs
which only calls ThumbnailPathForUri.

The equivalent code for using glib/gio to look up the path for the
thumbnail should look something like this:

GLib.File fi = GLib.FileFactory.NewForUri(fileUri);
GLib.FileInfo info = fi.QueryInfo("thumbnail::path", 
GLib.FileQueryInfoFlags.None, null);
string thumbnailPath = info.GetAttributeByteString("thumbnail::path");

You might want to revamp the code here a bit further though and fully
leverage the GIcon parts provided by GLib/GIO.

HTH.

Regards,
Andreas Henriksson

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

[Simon McVittie]

On Mon, 24 Aug 2015 at 11:24:19 +0100, Daniel Glassey wrote:
> A new version of the library (1.7.5) is imminent and will require a
> transition anyway. So we'll start planning the transition to libsword12.

Please do the v5 transition anyway; the wider libstdc++ transition has
eaten a month so far, and we would really like it to be over. The
release team are more likely to kick packages out of testing than waiting
for a new SONAME. As I think I mentioned at the Debian-UK BBQ,
there are ~ 300 transitions involving ~ 3000 packages at the moment,
so the people dealing with them would really prefer to see conservative,
minimal-risk changes.

If you had 1.7.5 already staged in experimental, it had already built
on all architectures, and you had test-built its rdeps successfully,
then going directly to libsword12 might be OK; but that doesn't
appear to be the case. The libsword12 transition can still happen in the
usual way (with a transition slot and so on) after the libstdc++ horror
has finished; there aren't many packages involved, so it should be an
easy one under normal circumstances.

Vaguely related to this, a ftp team member noted that there are open
RM bugs for bibledit-gtk and xiphos, which seem to be in the same
general area (bible study), and might get processed soon. If these
are of interest to you, please reply to the removal bugs and either
say "yes, this should be removed from unstable", or say what the plan
is for fixing the issues that led to the bug.

S

Bug#798023: cssutils: FTBFS with Python 3.5

[Barry Warsaw]

Source: cssutils
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

cssutils 1.0-2 fails to build from source with Python 3.5.

The upstream bug report is here:

https://bitbucket.org/cthedot/cssutils/issues/52/bad-octal-escape-blows-up-on-python-35b3


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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJV6au9AAoJEBJutWOnSwa/RFYP/0P7uMB2KKEo7VUwc2cFhib4
7DWwpildYSUqrDBFA4olOgQGiDQvS7k8Q77pAonHCiqkK7QMZmYr+8lnPp2zD/Im
FyMeGoaTrXREddoUEUbwWdoVXMC646a4RL3upeuiAjOjn6GvXRiwX+ng6ShQGtFk
kse6fjJyo42hE0sOCitSXJ2NgzhxJ1EqtJ5wv+OgRFeRm9xTYV5E2bp5gD3VLIa0
sHOXul2+sqlBaoTr6bOrb9cvErhDMAFMRGubYJpOA3LXgpRK54vKEO8D8cWImHGc
qboCQTiLIvR46lzooGhWqAROH6oD6BryxEH7PpQqKinLUotDhAlQAPvUEyBKdli4
xuM7kkQ1JPil2bj4o0NBPyKLo8hs8kk77C8kCoFBeQN1CGxzVACJ7PWmcd2/qErl
yC3rRzA5km1phosH2aCOD7yBXoe2BikuUvOFNTDiZ5Muoi9SZ0F/B3axmZ1efaZe
B+oG1fDw7z2hpxT509bbFej5wSp4+ncHyXuaDig1/EuQzU+UUI7sk7uqdbT6f/CD
ctcEjwnFIX4sljdALDYjhRxJmol689hGIcdyfQFYvdDVyGfXwsO71x7qyJnqWizf
64wqBC9nABrB0fLdSdlE8FlfuHY+UEGqeZfsRxQ8N6P+AnRVslv+REc5pCeYMlwo
PUjzEpF/ukt9+dkdrgo/
=sEez
-END PGP SIGNATURE-

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Fabio Natali]

On Fri, 4 Sep 2015 15:53:23 +0200 Guillaume Dupuy  wrote:
[...]
> Indeed, updating gstreamer1.0-plugins-bad to the experimental version
> solved this problem

I was wrong and Guillaume right: updating to the Experimental version
worked here too.

Thanks! f

-- 
Fabio Natali
http://fabionatali.com

Bug#796305: python-oauthlib: FTBFS: plugin distutils failed with: exit code=1:

[Daniele Tricoli]

Hello Chris,

On Thursday 03 September 2015 13:55:06 Chris Lamb wrote:
> Yes, just send a new email as follows (or reply and modify this one):
> 
>   To: 796305-d...@bugs.debian.org
>   Subject: Re: python-oauthlib: FTBFS: plugin distutils failed with:
>   exit code=1:
> 
>   Version: 1.0.3-1
> 
>   (whatever you want here)

Many thanks, I did it once but I wanted to be sure!

I'm closing this with a separate email.

Regards,

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

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

Bug#798014: version tracking get's confused about about fixed versions

[Michael Biebl]

Source: debbugs
Severity: normal

Hi,

if you look at [1], you'll see that the bug graph shows, that debbugs
somehow thinks that rsyslog/8.4.2-1 is unstable and affected while at
the same time it marks rsyslog/8.12.0-1 (correctly) as fixed and
unstable.

This did prevent testing migration of rsyslog, so the RT had to force
the package in.

Not quite sure what's going on here, maybe it's the missing builds on
kfreebsd-* or other archs [2]. The last successful build of kfreebsd was
8.4.2-1+b1

Cheers,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788183
[2] https://packages.debian.org/unstable/rsyslog

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

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

Bug#767682: Bug still present in Stretch (testing) installer

[Jaime T]

Hi all. Just another "me too" - I've just been bitten by this bug
while trying to install testing (stretch) using the netboot install
method i.e.:

ftp://ftp.uk.debian.org/debian/dists/stretch/main/installer-i386/20150828/images/netboot/debian-installer/i386/linux
and
ftp://ftp.uk.debian.org/debian/dists/stretch/main/installer-i386/20150828/images/netboot/debian-installer/i386/initrd.gz

I was trying to install onto a partition which already contained a
previous debian (wheezy) installation and the installer hung while
trying to create the ext4 filesystem. I managed to get round the
problem by using dd to write zeros to the first 50MB of the
destination partition and then restarting the installation procedure.

HTH, Jaime

Bug#625847: unattended-upgrades: should not send an email if no

[Jérôme]

Hi.

On Thu, 26 Apr 2012 16:29:38 +0200 Michael Vogt  wrote:

> Maybe we could use the idea from bug #652719 and add 
> "U-A::Mail-If-Packages-on-Hold"

Yes. It could be nice to be able to get an email only in case of error
or package on hold.

Thinking of it, I would like to 

- receive all emails (they are all filtered and stored so that I can
keep a trace if anything goes wrong);
- be notified if a config file conflict holds a package without having
to read all emails.

What about also adding [package on hold] in the email subject, à la
[reboot required]?

Thanks.

-- 
Jérôme

Bug#741573: CFV: Debian Menu Systems

[Ian Jackson]

Sam Hartman writes ("Bug#741573: CFV: Debian Menu Systems"):
> OPTION D:

I see that this has won.

I am absolutely furious

livid

enraged

Ian.

Bug#791577: reportbug: trips over obsolete conffiles

[Mechtilde Stehmann]

I want to reopen this bug report.

I tested this last change and it doesn’t work. See also #797922

In the Traceback you see the latest version of line 362 of 
/usr/lib/python2.7/dist-packages/reportbug/utils.py

Kind regards

Mechtilde

Bug#625847: unattended-upgrades: should not send an email if no

[Jérôme]

On Fri, 04 Sep 2015 15:12:15 +0200 =?UTF-8?Q?J=C3=A9r=C3=B4me?=
 wrote:
>
> On Thu, 26 Apr 2012 16:29:38 +0200 Michael Vogt  wrote:
> 
> > Maybe we could use the idea from bug #652719 and add 
> > "U-A::Mail-If-Packages-on-Hold"
> 
> Yes. It could be nice to be able to get an email only in case of error
> or package on hold.

I just noticed that (from version 0.86 on) MailOnlyOnError was modified
to send an email when there is a warning in the log.

Since a package on hold triggers a warning, I guess we got this case
covered.

-- 
Jérôme

Bug#796284: #796284 ITP: golang-github-opencontainers-specs -- Open Container Specifications

[Alexandre Viau]

Hello Dimitry

On 04/09/15 04:32 AM, Dmitry Smirnov wrote:
> On Thursday 03 September 2015 18:39:02 Alexandre Viau wrote:
>> I have opened an issue upstream:
>>  - https://github.com/opencontainers/specs/issues/147
>>
>> Unless this is urgent, I suggest that we wait for their reply.
> 
> Thank you for following with upstream. As I understand from the upstream bug, 
> the copyright is
> 
> Copyright 2015 The Linux Foundation.
> 
> as per
> 
> https://github.com/opencontainers/specs/blob/master/LICENSE#L179
> 
> I shall be happy to upload once copyright is updated accordingly.
> 

I have updated the packaging. It should now be ready for upload!

It is on Alioth:
 - git.debian.org:/git/pkg-go/packages/golang-github-opencontainers-specs

Thanks,

-- 
Alexandre Viau
alexan...@alexandreviau.net



signature.asc
Description: OpenPGP digital signature

Bug#798019: icecast2 package should depends on ed package

[montuno]

Package: icecast2
Version: 2.4.0-1.1+deb8u1
Severity: important

Dear Maintainer,

icecast2 should depend on ed package.

   * What led up to the situation? 
install icecast2 on a raspberrypi2 running jessie minimal image

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
apt-get install icecast2 and follow the configuration wizard

   * What was the outcome of this action?
unconfigured icecast2.xml

   * What outcome did you expect instead?
icecast2.xml altered with wizard data


-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.18.0-trunk-rpi2 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages icecast2 depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18
ii  libcurl3-gnutls7.38.0-4+deb8u2
ii  libogg01.3.2-1
ii  libspeex1  1.2~rc1.2-1
ii  libtheora0 1.1.1+dfsg.1-6
ii  libvorbis0a1.3.4-2
ii  libxml22.9.1+dfsg1-5
ii  libxslt1.1 1.1.28-2+b2

icecast2 recommends no packages.

Versions of packages icecast2 suggests:
pn  ices2  

-- Configuration Files:
/etc/default/icecast2 changed [not included]
/etc/icecast2/icecast.xml changed [not included]

-- debconf information excluded

Bug#798022: ITP: golang-github-go-ldap-ldap -- Basic LDAP v3 functionality for the GO programming language

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-go-ldap-ldap
  Version : 0.0~git20150817.24.12f2865-1
  Upstream Author :  The Go Authors
* URL : https://github.com/go-ldap/ldap
* License : BSD-3-clause
  Programming Lang: Go
  Description : Basic LDAP v3 functionality for the GO programming
language.

I am packaging this as it is a dependency for Grafana




signature.asc
Description: OpenPGP digital signature

Bug#787724: Confirmed

[Paolo Cavallini]

Il 04/09/2015 15:40, David Kalnischkies ha scritto:

> But as Julian said, this is likely a temporary problem of the involved
> server and not of the client.

You are right. Sorry for the noise.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html



signature.asc
Description: OpenPGP digital signature

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

[Daniel Glassey]

On Fri, Sep 04, 2015 at 11:21:03AM -0400, Roberto C. Sánchez wrote:
> Daniel,
> 
> I've been meaning to help out with this for some time, but I have been
> extrememly busy the last few months.  Let me at least help by making the
> upload.  Can you point me to the source package?

Thanks Roberto, I've moved discussion about this to the bibledit-gtk bug 
#790200.

Regards,
Daniel


signature.asc
Description: Digital signature

Bug#798027: RFS: golang-github-rainycape-unidecode

[Alexandre Viau]

Hello Dimitry,

On 04/09/15 12:31 PM, Dmitry Smirnov wrote:
> Hello Alexandre,
> 
> On Friday 04 September 2015 12:10:42 Alexandre Viau wrote:
>> Can you review golang-github-rainycape-unidecode?
> 
> I had a quick look and I found a problem with copyright information.
> Upstream have absolutely nothing to suggest that it is copyrighted
> 
> 2014 Rainy Cape S.L. 
> 
> In such case you need to add comment to "debian/copyright" with a link to 
> some sort of verifiable evidence of copyright.
> 
> IMHO it will be best to open ticket with upstream asking 'em to add copyright 
> statement and include bug URL to "Comment" field once upstream reply.
> 
> Once I had a package rejected due to similar problem...
> 

I have opened an issue upstream and left a comment in debian/copyright.
The comment in debian/copyright points to the upstream issue.

-- 
Alexandre Viau
alexan...@alexandreviau.net



signature.asc
Description: OpenPGP digital signature