date:20161231

Ben Finney  writes:
> On 20-Apr-2016, Ben Finney wrote:

>> We intend to use the ‘adventure’ virtual package name, to declare
>> providing an implementation of the classic game Adventure.

> An announcement of this at ‘debian-devel’ on 2016-04-20 with Message-Id
> <85zispp4gn@benfinney.id.au> attracted no feedback, so this name
> evidently is uncontroversial.

> Please add this virtual package to the Games section:

> adventurethe classic Colossal Cave Adventure game

Seconded (needs one more second).

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

Bug#759492: File conflicts between /bin and /usr/bin

Ansgar Burchardt  writes:

> Seconded.

> Though shouldn't this be worded a bit more generic? There are also
> /lib32 vs /usr/lib32 and /lib64 vs /usr/lib64 (and possibly other
> suffixes like libx32).

> Also I don't think Policy should require maintainer scripts for the
> implementation of compatibility symlinks. I would prefer an
> implementation-neutral wording that would allow switching to dpkg
> handling these in some declarative way without having to change Policy.

>   To support merged-/usr systems, packages must not
>   install files in both {path} and
>   /usr/{path}.

>   In case a file gets moved between {path} and 
>   /usr/{path} and a compatibility symlinks is needed,
>   the symlink must be managed in such a way that it will not
>   break when, for example, /bin and /usr/bin
>   are the same directory.

I took the liberty of tweaking this a bit when applying this patch, and
came up with the following:

--- a/policy.sgml
+++ b/policy.sgml
@@ -8634,6 +8634,22 @@ fi
  programs must be renamed.


+ To support merged-/usr systems, packages must not
+ install files in both path
+ and /usr/path.  For example, a package
+ may not install both /bin/example
+ and /usr/bin/example.
+   
+   
+ If a file is moved between path
+ and /usr/path in revisions of a Debian
+ package, and a compatibility symlink at the old path is needed,
+ the symlink must be managed in a way that will not break
+ when path
+ and /usr/path are the same underlying
+ directory due to symlinks or other mechanisms.
+   
+   
   Binary executables must not be statically linked with the GNU C
   library, since this prevents the binary from benefiting from
   fixes and improvements to the C library without being rebuilt

Now committed for the next Policy release.

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

Bug#849830: [Pkg-kde-extras] Bug#849830: [src:digikam] Some sources are not included in your package

2016-12-31 Thread Scott Kitterman

On Sunday, January 01, 2017 12:59:08 AM Steve Robbins wrote:
> On Saturday, December 31, 2016 10:06:37 PM CST you wrote:
> > your package includes some files that seem to lack sources
> > in preferred forms of modification (even if removed during clean target).
> 
> No part of the resulting binary package comes from files that are not in
> their intended form of modification.  I acknowledge there are extra
> non-source files in the source tarball *that are not used* to create the
> binary.

Speaking as a member of the FTP team, the source needs to be DFSG free to be 
in Main.  Regardless of if it's used in the binary.

> > According to Debian Free Software Guidelines [1] (DFSG) #2:
> >  "The program must include source code, and must allow distribution
> >  
> >   in source code as well as compiled form."
> 
> Digikam meets this test.

Binaries yes, source no.

> > In some cases this could also constitute a license violation for some
> > copyleft licenses such as the GNU GPL. (While sometimes the licence
> > allows not to ship the source, the DFSG always mandates source code.)
> 
> It requires all sources required to create the binary.  Digikam meets this
> test.

No.  It doesn't.  This is a valid bug and one that's not hard to fix.

Scott K

Bug#849705: unrtf: Stack buffer overflow

2016-12-31 Thread Salvatore Bonaccorso

Hi Willi,

On Sat, Dec 31, 2016 at 09:15:09PM +0100, Willi Mann wrote:
> Hi,
> 
> > Not sure yet if that would warrant a DSA, possibly it could be updated
> > via the upcoming point release as well.
> 
> I pushed a jessie branch to the git repository with the patch from
> upstream (some hunks had to be ignored). I also uploaded a patched
> version to unstable.
> 
> https://anonscm.debian.org/cgit/collab-maint/unrtf.git/log/?h=jessie
> 
> Let me know how I should proceed for jessie.

Thanks, seen the unstable upload and updated the tracker information.
For jessie, can you schedule a fix via the upcoming point release? Cf.
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable

Regards,
Salvatore

Bug#849830: [src:digikam] Some sources are not included in your package

2016-12-31 Thread Steve Robbins

On Saturday, December 31, 2016 10:06:37 PM CST you wrote:

> your package includes some files that seem to lack sources
> in preferred forms of modification (even if removed during clean target).

No part of the resulting binary package comes from files that are not in their 
intended form of modification.  I acknowledge there are extra non-source files 
in the source tarball *that are not used* to create the binary.

> According to Debian Free Software Guidelines [1] (DFSG) #2:
>  "The program must include source code, and must allow distribution
>   in source code as well as compiled form."

Digikam meets this test.

> In some cases this could also constitute a license violation for some
> copyleft licenses such as the GNU GPL. (While sometimes the licence
> allows not to ship the source, the DFSG always mandates source code.)

It requires all sources required to create the binary.  Digikam meets this 
test.

-Steve

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

Bug#829367: Please add virtual-mysql-* packages to the official list of virtual packages

> From: Otto Kekäläinen 
> Subject: Re: Please add virtual-mysql-* pacakges to the official list of 
> virtual packages
> To: Bill Allombert 
> Cc: debian-pol...@lists.debian.org, Paul Gevers 

> 2016-07-02 20:12 GMT+01:00 Bill Allombert 
> :
>> Could you provide the list of the new virtual packages together with their
>> description ?
>>
>> The page you link provide the list but no description.

> The list and descriptions:

> virtual-mysql-client - A MySQL database compatible client package
> virtual-mysql-client-core- A MySQL database compatible client core package
> virtual-mysql-server - A MySQL database compatible server package
> virtual-mysql-server-core- A MySQL database compatible server core package
> virtual-mysql-testsuite  - A MySQL database compatible test suite package

I second adding these virtual packages (so we need another second to apply
them to Policy).

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

Bug#769739: vlc: Can't play videos in webm format on YouTube

2016-12-31 Thread Pierre Ynard

> lua info: youtube.lua: debug: parse(): js_url before 
> //s.ytimg.com/yts/jsbin/html5player-ro_RO-vflJ1gY7_/html5player.js
> lua info: youtube.lua: debug: parse(): js_url fixed (added "http:") 
> http://s.ytimg.com/yts/jsbin/html5player-ro_RO-vflJ1gY7_/html5player.js
> lua error: youtube.lua: pick_url(): Couldn't locate video signature, YouTube 
> won't work without it.

These logs were never in the mainline youtube.lua script, it seems you
were using an alternate version. Please make sure that an old stray
version isn't installed in ~/.local/share/vlc/lua/playlist/ Please try
after installing/updating in ~/.local/share/vlc/lua/playlist/ the most
recent youtube.lua from the master branch:
http://git.videolan.org/?p=vlc.git;a=blob_plain;f=share/lua/playlist/youtube.lua;hb=HEAD

If the problem still persists (which I'm quite confident it won't),
please resubmit full logs (the links to full logs have unfortunately
expired) and/or contact me directly, I will see it through.

Best regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Bug#841295: closed by Lars Wirzenius <l...@liw.fi> (Bug#841295: fixed in obnam 1.20-1)

2016-12-31 Thread Clayton

On Sat, 29 Oct 2016 15:27:22 +
ow...@bugs.debian.org (Debian Bug Tracking System) wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the obnam package:
> 
> #841295: ERROR: RD5FA4X: System
> error: /tmp/tmpZmTUlC/S.gpg-agent.rstrd: 2: No such file or directory
> 
> It has been closed by Lars Wirzenius .

It just came down and is working for me. Thanks much!

Bug#842422: Automatic device renaming seems to cause the issue

2016-12-31 Thread Pete Miller

Hi,

I had similar issues with a RT5572 based USB dongle. I tried renaming
using 70-persistent-net.rules, but, since the mac address kept changing
this did not work.

I finally found this post - https://askubuntu.com/questions/689070/netw
ork-interface-name-changes-after-update-to-15-10-udev-
changes/732638#732638, specifically the part:

Edit your /etc/default/grub. Change the line from

GRUB_CMDLINE_LINUX=""

to

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

and, finally run:

# update-grub

as root, and reboot your system.

And that worked.

So, turning off automatic renaming allowed NM (1.4.4-1 daemon and
1.4.2-1 gnome) to connect.

Thanks, Pete Miller

Bug#781779: xdm and kdm work

2016-12-31 Thread Russell Coker

xdm (the original display manager) and kdm (which is only in Jessie but still 
works if you never uninstalled it) are supported in the current policy.

I'm working on sddm and gdm3, I don't know if I will get them both going 
before stretch is frozen.

Anyway xdm is supported and does everything you need for GUI logins.  Even if 
we end up with xdm being the only supported display manager that works with SE 
Linux I don't think that's a big deal.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#657277: git-pbuilder: please respect configured build result directory

2016-12-31 Thread Carl Suster

Seems the fix was released some time ago but the corresponding changelog didn't 
close this bug.

Bug#824922: debian-policy: d/copyright examples give dep5-copyright-license-name-not-unique lintian warning

Stefan  writes:

> while updating my package I followed the examples under

>   https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

> however those generate the linintian warning

>   dep5-copyright-license-name-not-unique.

> Attached are two patches that should fix this warning:

>   simple.patch, using the current copyright file from xsol.
>   complex.patch, updating the second example

Thanks, I've fixed the examples to avoid this problem and added some notes
that these examples won't be accurate for those packages in the archive.
(I fixed the simple version a bit differently to make it even simpler.)

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

Bug#792594: libqt5qml5 requires SSE2 on i386

2016-12-31 Thread Guillem Jover

On Wed, 2015-11-04 at 16:44:00 +0100, Guillem Jover wrote:
> On Sun, 2015-11-01 at 14:31:37 -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > We are definitely not taken this as a distro delta because the code changes 
> > too much between versions and we really lack the manpower to do it, plus 
> > that 
> > we do our best to avoid distro deltas. So removing the patch tag.
> 
> I've found that the changes required for each minor version are rather
> minimal.

This still is the case up to now. Well, with latest patches, the changes
required were even more trivial.

> In any case, because I need a patched Qt on my systems to be
> able to run many Qt applications at all, I'll have to rebase the patches
> and build local packages anyway. I'll try to send the rebased patches
> here for whoever else needs them, if I remember.

As I had to upgrade all the systems involved, I needed to update
the patches, which I did against 5.7.x and 5.8.x (git HEAD).

> If someone else wants access to the Qt Declaratives packages I'm
> building please say so, and I'll publish them on some repository.

This still stands.

> Attached all current patches against 5.4.x, 5.5.x and 5.6.x (git HEAD).

I've only build and run tested the one for 5.7.x.

Regards,
Guillem
From 22648824a351bfec8e01979257c24e3ba440104a Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 12 Oct 2015 01:45:37 +0200
Subject: [PATCH] Do not make lack of SSE2 support on x86-32 fatal

When an x86-32 CPU does not have SSE2 support (which is the case for
all AMD CPUs, and older Intel CPUs), fallback to use the interpreter,
otherwise use the JIT engine.

Even then, make the lack of SSE2 support on x86-32 fatal when trying
to instantiate a JIT engine, which does require it.

Refactor the required CPU support check into a new privately exported
function to avoid duplicating the logic, and do so in a function
instead of a class member to avoid changing the class signatures.

Version: 5.7.x
Bug-Debian: https://bugs.debian.org/792594
---
 src/qml/jit/qv4isel_masm.cpp|  3 +++
 src/qml/jit/qv4isel_masm_p.h| 10 ++
 src/qml/jsruntime/qv4engine.cpp |  1 +
 src/qml/qml/v8/qv8engine.cpp|  7 ---
 tools/qmljs/qmljs.cpp   |  7 +++
 5 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/src/qml/jit/qv4isel_masm.cpp b/src/qml/jit/qv4isel_masm.cpp
index d047623ac..4d65fbb62 100644
--- a/src/qml/jit/qv4isel_masm.cpp
+++ b/src/qml/jit/qv4isel_masm.cpp
@@ -265,6 +265,9 @@ InstructionSelection::InstructionSelection(QQmlEnginePrivate *qmlEngine, QV4::Ex
 , compilationUnit(new CompilationUnit)
 , qmlEngine(qmlEngine)
 {
+if (!hasRequiredCpuSupport())
+qFatal("This program requires an X86 processor that supports SSE2 extension, at least a Pentium 4 or newer");
+
 compilationUnit->codeRefs.resize(module->functions.size());
 }
 
diff --git a/src/qml/jit/qv4isel_masm_p.h b/src/qml/jit/qv4isel_masm_p.h
index 1e6ac1f51..8bd7313a7 100644
--- a/src/qml/jit/qv4isel_masm_p.h
+++ b/src/qml/jit/qv4isel_masm_p.h
@@ -59,6 +59,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -71,6 +72,15 @@ QT_BEGIN_NAMESPACE
 namespace QV4 {
 namespace JIT {
 
+inline bool Q_QML_PRIVATE_EXPORT hasRequiredCpuSupport()
+{
+#ifdef Q_PROCESSOR_X86_32
+return qCpuHasFeature(SSE2);
+#else
+return true;
+#endif
+}
+
 class Q_QML_EXPORT InstructionSelection:
 protected IR::IRDecoder,
 public EvalInstructionSelection
diff --git a/src/qml/jsruntime/qv4engine.cpp b/src/qml/jsruntime/qv4engine.cpp
index 26f473a7a..5e4100ac0 100644
--- a/src/qml/jsruntime/qv4engine.cpp
+++ b/src/qml/jsruntime/qv4engine.cpp
@@ -162,6 +162,7 @@ ExecutionEngine::ExecutionEngine(EvalISelFactory *factory)
 
 #ifdef V4_ENABLE_JIT
 static const bool forceMoth = !qEnvironmentVariableIsEmpty("QV4_FORCE_INTERPRETER") ||
+  !JIT::hasRequiredCpuSupport() ||
   !OSAllocator::canAllocateExecutableMemory();
 if (forceMoth) {
 factory = new Moth::ISelFactory;
diff --git a/src/qml/qml/v8/qv8engine.cpp b/src/qml/qml/v8/qv8engine.cpp
index 46fd4fbbe..20ed1ddb4 100644
--- a/src/qml/qml/v8/qv8engine.cpp
+++ b/src/qml/qml/v8/qv8engine.cpp
@@ -65,7 +65,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -130,12 +129,6 @@ QV8Engine::QV8Engine(QJSEngine* qq)
 , m_xmlHttpRequestData(0)
 , m_listModelData(0)
 {
-#ifdef Q_PROCESSOR_X86_32
-if (!qCpuHasFeature(SSE2)) {
-qFatal("This program requires an X86 processor that supports SSE2 extension, at least a Pentium 4 or newer");
-}
-#endif
-
 QML_MEMORY_SCOPE_STRING("QV8Engine::QV8Engine");
 qMetaTypeId();
 qMetaTypeId();
diff --git a/tools/qmljs/qmljs.cpp b/tools/qmljs/qmljs.cpp
index 68aa52ce9..94b10f2b3 100644
--- a/tools/qmljs/qmljs.cpp
+++ b/tools/qmljs/qmljs.cpp
@@ -135,11 +135,10 @@ int main(int argc, char

Bug#816515: Disallow (< ...) and (> ...) package relations

"Paul R. Tagliamonte"  writes:

> The language is not clear - I think Jakub covered my concerns clearly.

> Open to wording changes?

I consider this all non-normative, so I've just applied the following
change that will hopefully make it completely clear that the < and >
relations are no longer allowed.

diff --git a/policy.sgml b/policy.sgml
index e086321..ba8ce9b 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -4775,11 +4775,13 @@ fi
  The relations allowed are , =,
  =, = and  for strictly
  earlier, earlier or equal, exactly equal, later or equal and
- strictly later, respectively.  The deprecated
- forms  and  were confusingly used to
- mean earlier/later or equal, rather than strictly earlier/later,
- and must not appear in new packages (though dpkg
- still supports them with a warning).
+ strictly later, respectively.
+   The relations  and  were previously
+   allowed, but they were confusingly defined to mean
+   earlier/later or equal rather than strictly
+   earlier/later.  dpkg still supports them with a
+   warning, but they are no longer allowed by Debian Policy.
+ 

 


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

Bug#798309: perl: multi-arch packages don't comply with perl policy

Dominic Hargreaves  writes:
> On Sun, Sep 20, 2015 at 05:46:50PM +0100, Dominic Hargreaves wrote:
>> On Fri, Sep 11, 2015 at 02:05:14PM +0300, Niko Tyni wrote:
>> > On Mon, Sep 07, 2015 at 11:24:03PM +0100, Dominic Hargreaves wrote:

 The perl policy should be updated to reflect the new implementation
 details of paths. The patch I sent in May is, IIRC, out of date now;
 Niko, would you be able to review/update this?

>>> I think the only outdated part was archlib+privlib, which ended up
>>> with shortversion after all (see #787158).

>>> Updated patch attached. I've also amended the patch description
>>> to explain the reasoning behind versioned directories. Eyeballs
>>> welcome.

>> Thanks, this looks good. I guess we will move this to debian-policy
>> once perl 5.22 has migrated to unstable, so setting blocks
>> appropriately.

> This has now happened, so reassigning accordingly.

Thanks, seconded and applied for the next release.

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

Bug#849417: [Pkg-nagios-devel] Bug#849417: nagios-nrpe-server: segfault during SSL negotiation with older NRPE 2.15 plugin

2016-12-31 Thread Adam Di Carlo

Sebastiaan Couwenberg  writes:

> The debug symbols are already available, no need to a rebuild. Just
> install the nagios-nrpe-server-dbgsym package.
[...]

Thanks, that system is new to me!

>>> Due to the signal handler in NRPE you won't easily get a backtrace since
>>> SIGSEGV is caught too and NRPE just continues instead of terminating. If
>>> you can get a backtrace (with debug symbols installed) that would be
>>> helpful.

It didn't really give me too much trouble.  I think gdb replaces all the
signal handlers anyhow.

To recap my current behavior, in case things maybe changed subtly here,
here's the logging I get in daemon.log with ssl_debug set to 0x0f:

Dec 31 21:37:22 salsa nrpe[24931]: Allowing connections from: 
127.0.0.1,192.168.1.5
Dec 31 21:37:27 salsa nrpe[24935]: Connection from 192.168.1.5 port 42463
Dec 31 21:37:27 salsa nrpe[24935]: Host address is in allowed_hosts
Dec 31 21:37:27 salsa nrpe[24935]: Error: Could not complete SSL handshake with 
192.168.1.5: 1
Dec 31 21:37:27 salsa nrpe[24935]: Connection from 192.168.1.5 closed.


Whereas if I set it to 0xff:
Dec 31 21:36:23 salsa nrpe[24897]: Allowing connections from: 
127.0.0.1,192.168.1.5
Dec 31 21:36:30 salsa nrpe[24899]: Connection from 192.168.1.5 port 41951
Dec 31 21:36:30 salsa nrpe[24899]: Host address is in allowed_hosts

and then in kernl.log:
Dec 31 21:36:30 salsa kernel: [632644.965865] nrpe[24899]: segfault at
b0935335 ip 7f3fafd3d496 sp 7ffee43c9dc8 error 4 in
libc-2.24.so[7f3fafcbd000+195000]


Here's my gdb session and the best backtrace I was able to get out:

# gdb /usr/sbin/nrpe 24967
(gdb) set follow-fork-mode child
(gdb) c
Continuing.
[New process 25047]
[New process 25048]

Thread 3.1 "nrpe" received signal SIGSEGV, Segmentation fault.
[Switching to process 25048]
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x7fc8e3c34da3 in _IO_vfprintf_internal (s=s@entry=0x561cf790d280, 
format=, format@entry=0x561cf6be9eb8 "Error: Could not complete 
SSL handshake with %s: %s", 
ap=0x7fff6996e188) at vfprintf.c:1637
#2  0x7fc8e3ce2f66 in ___vfprintf_chk (fp=fp@entry=0x561cf790d280, 
flag=flag@entry=1, format=format@entry=0x561cf6be9eb8 "Error: Could not 
complete SSL handshake with %s: %s", 
ap=ap@entry=0x7fff6996e188) at vfprintf_chk.c:33
#3  0x7fc8e3ccfad8 in __GI___vsyslog_chk (pri=, flag=1, 
fmt=0x561cf6be9eb8 "Error: Could not complete SSL handshake with %s: %s", 
ap=ap@entry=0x7fff6996e188)
at ../misc/syslog.c:222
#4  0x7fc8e3ccffd2 in __syslog_chk (pri=, flag=, fmt=) at ../misc/syslog.c:129
#5  0x561cf6be51ba in syslog (__fmt=0x561cf6be9eb8 "Error: Could not 
complete SSL handshake with %s: %s", __pri=3) at 
/usr/include/x86_64-linux-gnu/bits/syslog.h:31
#6  handle_conn_ssl (sock=, ssl_ptr=0x561cf78f7b70) at 
./nrpe.c:1753
#7  0x561cf6be6a53 in handle_connection (sock=6) at ./nrpe.c:1491
#8  0x561cf6be7085 in wait_for_connections () at ./nrpe.c:1198
#9  0x561cf6be71c3 in run_src () at ./nrpe.c:506
#10 0x561cf6be288c in main (argc=, argv=) at 
./nrpe.c:198

(gdb) frame 6
#6  handle_conn_ssl (sock=, ssl_ptr=0x561cf78f7b70) at 
./nrpe.c:1753
1753./nrpe.c: No such file or directory.
nerrs = 0
c = 
buffer = 
"\000\000\000\000\000\000\000\000\324\006\000\000\000\000\000\000\250\310\311\344\310\177\000\000\220\375\276\343\310\177\000\000\070п\343\310\177\000\000SI\250\344\310\177\000\000\324\006\000\000\000\000\000\000\070п\343\310\177\000\000\250\310\311\344\310\177\000\000\070\343\226i\377\177\000\000\064\343\226i\377\177\000\000\313B\250\344\310\177\000\000\020\265\370\343\310\177\000\000(\252\370\343\310\177\000\000\070\343\226i\377\177\000\000\066\025\025e\000\000\000\000TT\224\001\000\000\000\000\070п\343\310\177\000\000\020\344\226i\377\177\000\000\220\375\276\343\310\177\000\000\064\343\226i\377\177\000\000\000\344\226i\377\177\000\000PF\306\344\310\177\000\000\b",
 '\000' ...
ssl = 0x561cf78f7b70
peer = 
rc = 
x = 


Let me know if you're still stumped.   I think my next step would be to
have to try to hack sources and come up with a diff which fixes matters.

Also, I'm clearly missing some debug symbols, covering
.../sysdeps/x86_64/strlen.S, but not sure what package I need to install
to cover that.

-- 
...Adam Di Carlo......

Bug#796660: Binaries in binary packages match the architecture

Florian Weimer  writes:

> It seems to me that a requirement is missing from the policy that
> binaries (DSOs and executables) which are intended to run on the host
> must be located in a binary package, and the architecture of the
> binary package must match the DSO/executable architecture.

> For example, shipping i386 binaries instead of amd64 binaries is not
> acceptable, even though these programs might run with the default
> Debian kernel.

This is a little tricky to phrase, since there are entirely legitimate
cases where you do want to ship foreign binaries (packages that set up
cross-compiler environments, for instance, or packages meant to install
binaries onto auxiliary devices).

But yes, saying that amd64 packages should generally have amd64 binaries
and that i386 binaries should be installed on amd64 systems using
foreign-arch packages, not by putting i386 binaries into an amd64 package,
seems reasonable to say at this point.  (Have we entirely eliminated the
various pre-multiarch workarounds for this from the archive?)

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

Bug#770440: debian-policy: policy should mention systemd timers

Alexandre Detiste  writes:

> I've seen that util-linux was the first package that started providing a
> native systemd timer for fstrim, but this change got reverted.

>> util-linux (2.25.2-3) unstable; urgency=medium
>>  * Ship fstrim timer/service units as examples only (Closes: #767194)
>>  - this works around #757891 and #767429 / #760168
>> -- Andreas Henriksson   Thu, 06 Nov 2014 13:54:04 +0100

> The policy should mention how to handle systemd native timers
> to avoid these kind of bugs in the future;
> when other packages will start shipping native timers.

> Here is the spirit of this change:

> +To maintaint compatability with SysV Init;
> +packages that ships native timers must also ship corresponding
> +crontabs. (/etc/cron.daily|weekly|monthly/) would remain unaffected.
> +
> +These cron jobs must then also ensure that systemd is not
> +currently running to avoid duplicate execution.
> +
> +A canonical way to both ensure that systemd is not currently running
> +and that package hasn't be removed would be:
> +m h d m w user test -e /run/systemd/system || test -e 
> /usr/bin/pkg && /usr/bin/pkg

> Here is a more elaborate draft:

> https://github.com/ajtowns/debian-init-policy/pull/6/files

This proposal seems reasonable, but the above is a pull request against
some other document that wasn't ever merged with Policy (and is something
of a separate issue).

Could you formulate this as a patch against the debian-policy package?

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

Bug#768117: debian-policy: WSGI API must distinguish between Python 2 and 3

Bill Allombert  writes:
> On Sun, Nov 23, 2014 at 07:08:31PM +0100, Bill Allombert wrote:

>> Thanks for your clarification.  Is the attached patch OK ?

>> diff --git a/virtual-package-names-list.txt b/virtual-package-names-list.txt
>> index f52ddba..f68133f 100644
>> --- a/virtual-package-names-list.txt
>> +++ b/virtual-package-names-list.txt
>> @@ -106,7 +106,8 @@ Network
>>   ftp-server  a FTP server
>>   httpd   a HTTP server
>>   httpd-cgi   A CGI capable HTTP server
>> - httpd-wsgi  A WSGI capable HTTP server
>> + httpd-wsgi  A WSGI capable HTTP server (python 2 API)
>> + httpd-wsgi3 A WSGI capable HTTP server (python 3 API)
>>   ident-serveran identd daemon
>>   inet-superserveran inetd server
>>   lambdamoo-core  a lambdamoo-compatible database package  
>> @@ -343,3 +344,4 @@ Bill Allombert:
>>16 Jul 2014 Added java{5,6,7,8,9}-runtime{,-headless}
>>Removed java1-runtime, java2-runtime
>>30 Jul 2014 Added httpd-wsgi
>> +  23 Nov 2014 Added httpd-wsgi3

> Someone else willing to review and second this ?

Seconded and applied for the next release.

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

Bug#849842: ITP: ykush-control -- control application for Yepkit YKUSH Switchable USB Hub board

2016-12-31 Thread Christoph Biedl

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 

* Package name: ykush-control
  Version : 1.0.0
  Upstream Author : 2015-2016 Yepkit Lda
* URL : https://github.com/Yepkit/ykush
* License : MIT
  Programming Lang: C++
  Description : control application for Yepkit YKUSH Switchable USB Hub 
board

 The Yepkit USB Switchable Hub (YKUSH) boards allow the user to
 selectively switch ON and OFF each of the USB devices connected to the
 hub downstream ports. This package provides the ykushcmd program to
 control the switches of all connected boards.



signature.asc
Description: Digital signature

Bug#835876: debian-policy: please suggest dbus-run-session to run tests

Simon McVittie  writes:

> As described in
>  I'm trying
> to reduce how much dbus-launch is used in Debian.

> The autopkgtest document in debian-policy currently mentions dbus-launch
> as a possible wrapper around test commands. Please mention
> dbus-run-session instead. Pseudo-patch:

>   existing upstream test executable and just need to wrap it with some command
> - like `dbus-launch` or `env`, you can use this field to specify the shell
> + like `dbus-run-session` or `env`, you can use this field to specify the 
> shell
>   command directly. It will be run under `bash -e`. This is mutually exclusive

Thanks, applied.

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

Bug#849815: closed by Peter Colberg <pe...@colberg.org> (Bug#849815: fixed in julia 0.4.7-3)

2016-12-31 Thread Tony Kelman

Thank you Peter! That looks like it should do the trick.

Bug#808850: xfonts-wqy: FTBFS: Type of arg 1 to shift must be array (not constant item) at ./bdfmerge.pl line 35, near "ARGV)"

2016-12-31 Thread Paul Hardy

tags 808850 patch
--

This is a patch so that the Makefile will not invoke bdfmerge.pl.
Thus the bug in bdfmerge.pl can be downgraded to "Normal" (so it is no
longer RC) once this patch is applied.

The invocations to bdfmerge.pl specify a range of code points, so that
only code points in that range are included in the output.  But the
Makefile specifies ranges of 0--0x.  In other words, it specifies
using every glyph that can exist in the BDF source files, removing no
code points from them.  Thus it is a null operation in this instance,
and can be bypassed with no side effects (except for postponing fixing
the bug in bdfmerge.pl).

With this patch, bdftopcf is invoked directly on the original BDF font
files.  The resulting PCF files are identical to those produced by the
original Makefile, minus the bdfmerge.pl warning.

Because the Makefile has not changed in years, this should be a
relatively stable solution.

Patch follows.


Paul Hardy

-cut here---
--- Makefile2016-12-31 17:49:57.0 -0800
+++ Makefile-new2016-12-31 17:49:57.0 -0800
@@ -39,8 +39,7 @@
 all_pcf:= $(all_range:%=%.pcf)

 %.pcf: %.bdf
-$(SLICE) $(RANGE) $*.bdf > $*_cjk.bdf
-$(B2P) $*_cjk.bdf > $*.pcf
+$(B2P) $*.bdf > $*.pcf

 all: b2p $(all_pcf)
 cjk:  RANGE=$(CJKALL)

Bug#816249: debian-policy: C.2.4 does not reflect current practises

Niels Thykier  writes:

> The section C.2.4 seems to be a bit outdated.  Quote:

> """
> C.2.4 debian/tmp

> This is the canonical temporary location for the construction of
> binary packages by the binary target. The directory tmp serves as the
> root of the file system tree as it is being constructed (for example,
> by using the package's upstream makefiles install targets and
> redirecting the output there), and it also contains the DEBIAN
> subdirectory. [...]

> If several binary packages are generated from the same source tree it
> is usual to use several debian/tmpsomething directories, for example
> tmp-a or tmp-doc.

> [...]
> """

> However, the default used by debhelper is "debian/", which covers
> up to 99% of all packages.

Thanks for pointing this out.  The (non-normative) appendices have not
gotten a lot of love.  I've applied the following patch to update this at
least somewhat:

diff --git a/policy.sgml b/policy.sgml
index aacf0cd..e086321 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -11167,12 +11167,13 @@ END-INFO-DIR-ENTRY

 

- In order to create a binary package you must make a
- directory tree which contains all the files and directories
- you want to have in the file system data part of the package.
- In Debian-format source packages this directory is usually
- debian/tmp, relative to the top of the package's
- source tree.
+ In order to create a binary package, you must make a directory
+ tree which contains all the files and directories you want to
+ have in the file system data part of the package.  In
+ Debian-format source packages, this directory is usually
+ either debian/tmp
+ or debian/pkg, relative to the top of
+ the package's source tree.

 

@@ -11506,7 +11507,7 @@ END-INFO-DIR-ENTRY
Sources which build several binaries will typically need
something like:

-  dpkg-gencontrol -Pdebian/tmp-pkg -ppackage
+  dpkg-gencontrol -Pdebian/pkg -ppackage
 The -P tells
dpkg-gencontrol that the package is being
built in a non-default directory, and the -p
@@ -11653,27 +11654,39 @@ END-INFO-DIR-ENTRY
  
 
  
-   This is the canonical temporary location for the
-   construction of binary packages by the binary
-   target.  The directory tmp serves as the root of
-   the file system tree as it is being constructed (for
-   example, by using the package's upstream makefiles install
-   targets and redirecting the output there), and it also
-   contains the DEBIAN subdirectory.  See .
+   This is the default temporary location for the construction of
+   binary packages by the binary target.  The
+   directory tmp serves as the root of the file
+   system tree as it is being constructed (for example, by using
+   the package's upstream makefiles install targets and
+   redirecting the output there), and it also contains
+   the DEBIAN subdirectory.
+   See .
  
 
  
-   If several binary packages are generated from the same
-   source tree it is usual to use several
-   debian/tmpsomething directories, for
-   example tmp-a or tmp-doc.
+   This is only a default and can be easily overridden.  Most
+   packaging tools no longer use debian/tmp, instead
+   preferring debian/pkg for the common
+   case of a source package building only one binary package.
+   Such tools usually only use debian/tmp as a
+   temporary staging area for built files and do not construct
+   packages from it.
  
 
  
-   Whatever tmp directories are created and used by
-   binary must of course be removed by the
-   clean target.
+   If several binary packages are generated from the same source
+   tree, it is usual to use a separate
+   debian/pkg directory for each binary
+   package as the temporary construction locations.
+ 
+
+ 
+   Whatever temporary directories are created and used by the
+   binary target must of course be removed by the
+   clean target.
+ 
+   
   
 
-- 
Russ Allbery (r...@debian.org)

Bug#794902: debian-policy: obsolete footnote about liblockfile1 dependency

Jakub Wilk  writes:

> A footnote in §11.6 reads:

> “You will need to depend on `liblockfile1 (>>1.01)' to use these [maillock
> and mailunlock] functions.”

> This seems to suggest hardcoding shared library dependency in debian/control,
> which is a bad idea. Anyway, liblockfile 1.01 was released in 1999, so no
> version constraint is necessary.

> Let's remove this footnote.

Indeed.  Thanks, removed for the next release.

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

Bug#821365: debian-policy: Clarify which characters constitute the syntax of control files

Ben Finney  writes:

> Package: debian-policy
> Severity: minor
> Control: tags -1 + patch

> The description of control file syntax in §5.1 references numerous
> characters, some by number and some as simple display of the
> character, and some as informal names. Some of these mentions are
> confusing.

> The section also specifies that all control files are encoded as
> UTF-8, so knowledge of Unicode is (IMO correctly) assumed of the
> reader.

> This patch standardises the mention of characters in §5.1 to
> explicitly give Unicode code point references and (where appropriate)
> the literal character unambiguously quoted.

Thanks, applied (without the Unicode double quotes, since DebianDoc-SGML
probably can't cope).

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

Bug#849838: firefox: Fix broken hppa build support

2016-12-31 Thread John David Anglin

Hi Adrian,

On 2016-12-31, at 8:11 PM, John Paul Adrian Glaubitz wrote:

> Source: firefox
> Version: 50.1.0-1
> Severity: normal
> Tags: patch
> User: debian-h...@lists.debian.org
> Usertags: hppa
> 
> The attached patch fixes the problem by fixing the hppa-specific xpcom
> code. Furthermore, it enables the PowerPC atomic operations for hppa
> as these are generic enough to be used on other targets as well.


The attached patch fixes the compile issues and includes the comment that I 
had.  My icedove
build still isn't complete yet but it's well past the point where the compile 
breakage occurred.

Dave
--
John David Anglin   dave.ang...@bell.net


Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 icedove (1:45.5.1-1) unstable; urgency=medium
 .

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2016-12-30

Index: icedove-45.5.1/mozilla/js/src/jit/AtomicOperations.h
===
--- icedove-45.5.1.orig/mozilla/js/src/jit/AtomicOperations.h
+++ icedove-45.5.1/mozilla/js/src/jit/AtomicOperations.h
@@ -298,6 +298,8 @@ AtomicOperations::isLockfree(int32_t siz
 # include "jit/arm/AtomicOperations-arm.h"
 #elif defined(JS_CODEGEN_ARM64)
 # include "jit/arm64/AtomicOperations-arm64.h"
+#elif defined(__hppa__)
+# include "jit/none/AtomicOperations-ppc.h"
 #elif defined(JS_CODEGEN_MIPS32) || defined(JS_CODEGEN_MIPS64)
 # include "jit/mips-shared/AtomicOperations-mips-shared.h"
 #elif defined(__ppc64__) || defined(__PPC64_)   \
Index: icedove-45.5.1/mozilla/xpcom/reflect/xptcall/md/unix/xptcstubs_pa32.cpp
===
--- icedove-45.5.1.orig/mozilla/xpcom/reflect/xptcall/md/unix/xptcstubs_pa32.cpp
+++ icedove-45.5.1/mozilla/xpcom/reflect/xptcall/md/unix/xptcstubs_pa32.cpp
@@ -126,11 +126,21 @@ PrepareAndDispatch(nsXPTCStubBase* self,
 
 extern "C" nsresult SharedStub(int);
 
+#ifdef __GNUC__
 #define STUB_ENTRY(n)   \
 nsresult nsXPTCStubBase::Stub##n()  \
 {   \
+/* Save arg0 in its stack slot.  This assumes frame size is 64. */ \
+__asm__ __volatile__("stw %r26,-36-64(%sp)"); \
 return SharedStub(n);   \
 }
+#else
+#define STUB_ENTRY(n)   \
+nsresult nsXPTCStubBase::Stub##n()  \
+{   \
+return SharedStub(n);   \
+}
+#endif
 
 #define SENTINEL_ENTRY(n) \
 nsresult nsXPTCStubBase::Sentinel##n() \

Bug#793999: debian-policy: description of binary* targets suggests that build-{arch,indep} are optional

Charles Plessy  writes:

> thanks for the report.  In addition, I found a footnote that was
> similarly inaccurate.

> Here is a patch that would correct both.  This patch differs from your
> suggestion in that it does remove "should depend on the ‘build’ target":
> packages were binary-arch depends on build, which depends on build-arch
> are not buggy, isn't it ?

Thanks!  This didn't apply as-is, since the footnote had subsequently been
removed, but I've applied a version of this for the next release.

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

Bug#849841: [src:linux] bpfcc-tools don't work on 4.8 signed kernels

2016-12-31 Thread Liang Guo

Package: src:linux
Version: linux-image-4.8.0-2-amd64
Severity: serious

Hi, I found bpfcc-tools don't work on linux-image-4.8.0-2-amd64 and 
linux-image-4.8.0-2-rt-amd64, for these kernels are signed kernel, I think
bpfcc-tools don't work on all signed kernels on x86_64 platform. bpfcc-tools 
works on linux-image-4.8.0-2-amd64-unsigned, 
linux-image-4.8.0-2-rt-amd64-unsigned and linux-image-4.7.0-1-amd64, following
is my detailed test log:

##linux-image-4.8.0-2-amd64
root@bcat:~# python /usr/share/doc/bpfcc-tools/examples/hello_world.py  
bpf: Invalid argument 

Traceback (most recent call last): 
 File "/usr/share/doc/bpfcc-tools/examples/hello_world.py", line 11, in 
 
   BPF(text='int kprobe__sys_clone(void *ctx) { bpf_trace_printk("Hello, 
World!\\n"); return 0; }').trace_print() 
 File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 203, in __init__ 
   self._trace_autoload() 
 File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 679, in 
_trace_autoload 
   fn = self.load_func(func_name, BPF.KPROBE) 
 File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 243, in 
load_func 
   raise Exception("Failed to load BPF program %s" % func_name) 
Exception: Failed to load BPF program kprobe__sys_clone 
root@bcat:~# uname -a  
Linux bcat 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 GNU/Linux 
root@bcat:~# dpkg -l |grep linux-image 
ic  linux-image-4.7.0-1-amd64 4.7.8-1   
  amd64Linux 4.7 for 64-bit PCs (signed) 
ii  linux-image-4.8.0-1-amd64 4.8.7-1   
  amd64Linux 4.8 for 64-bit PCs (signed) 
ii  linux-image-4.8.0-2-amd64 4.8.11-1  
  amd64Linux 4.8 for 64-bit PCs (signed) 
ii  linux-image-amd64 4.8+77
  amd64Linux for 64-bit PCs (meta-package)

## linux-image-4.8.0-2-rt-amd64-unsigned
root@bcat:~# python /usr/share/doc/bpfcc-tools/examples/hello_world.py   
   sshd-1225  [001] d...2..86.931062: : Hello, World! 
   sshd-2855  [007] d...2..86.937056: : Hello, World! 
   sshd-1225  [002] d...2..92.551224: : Hello, World! 
   sshd-2869  [004] d...2..92.557394: : Hello, World! 
  systemd-udevd-454   [003] d...2..92.721318: : Hello, World! 
^Croot@bcat:~ 
root@bcat:~# uname -a 
Linux bcat 4.8.0-2-rt-amd64 #1 SMP PREEMPT RT Debian 4.8.15-1 (2016-12-19) 
x86_64 GNU/Linux 
root@bcat:~# dpkg -l |grep linux-image 
ic  linux-image-4.7.0-1-amd64 4.7.8-1   
  amd64Linux 4.7 for 64-bit PCs (signed) 
rc  linux-image-4.8.0-1-amd64 4.8.7-1   
  amd64Linux 4.8 for 64-bit PCs (signed) 
ii  linux-image-4.8.0-2-amd64 4.8.11-1  
  amd64Linux 4.8 for 64-bit PCs (signed) 
ii  linux-image-4.8.0-2-rt-amd64-unsigned 4.8.15-1  
  amd64Linux 4.8 for 64-bit PCs, PREEMPT_RT 
ii  linux-image-amd64 4.8+77
  amd64Linux for 64-bit PCs (meta-package)

##linux-image-4.8.0-2-amd64-unsigned 
root@bcat:~# python /usr/share/doc/bpfcc-tools/examples/hello_world.py   
   sshd-1108  [005] d...   218.666546: : Hello, World! 
   sshd-2701  [007] d...   218.672187: : Hello, World! 
   sshd-1108  [005] d...   223.546367: : Hello, World! 
   sshd-2707  [007] d...   223.551765: : Hello, World! 
console-kit-dae-2622  [002] d...   223.723321: : Hello, World! 
console-kit-dae-2622  [002] d...   223.726497: : Hello, World! 
console-kit-dae-2622  [002] d...   223.729037: : Hello, World! 
   sshd-2707  [000] d...   223.771321: : Hello, World! 
   bash-2712  [003] d...   223.773793: : Hello, World! 
   bash-2713  [004] d...   223.774088: : Hello, World! 
   bash-2712  [003] d...   223.792414: : Hello, World! 
   bash-2715  [004] d...   223.792811: : Hello, World! 
^Croot@bcat:~# uname -a 
Linux bcat 4.8.0-2-amd64 #1 SMP Debian 4.8.15-1 (2016-12-19) x86_64 GNU/Linux 
root@bcat:~# dpkg -l |grep linux-image 
ic  linux-image-4.7.0-1-amd64 4.7.8-1   
  amd64Linux 4.7 for 64-bit PCs (signed) 
rc  linux-image-4.8.0-1-amd64 4.8.7-1   
  amd64Linux 4.8 for 64-bit PCs (signed) 
rc  linux-image-4.8.0-2-amd64 4.8.11-1  
  amd64Linux 4.8 for 64-bit PCs (signed) 
ii  linux-image-4.8.0-2-amd64-unsigned4.8.15-1  
  amd64Linux 4.8 for 64-bit PCs 
ii  linux-image-4.8.0-2-rt-amd64-unsigned 4.8.15-1  
  amd64

Bug#849839: gitg: crashes Xwayland way too often

2016-12-31 Thread Jérémy Lal

Package: gitg
Version: 3.22.0-1
Severity: important

I run gitg from a terminal, and last week it's
been crashing the whole user session.
It wasn't doing that before.

Jérémy


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

Kernel: Linux 4.8.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 gitg depends on:
ii  dbus-x11 1.10.14-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gir1.2-peas-1.0  1.20.0-1
ii  git  1:2.11.0-2
ii  gsettings-desktop-schemas3.22.0-1
ii  libc62.24-8
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.2-1
ii  libgee-0.8-2 0.18.1-1
ii  libgirepository-1.0-11.50.0-1
ii  libgit2-glib-1.0-0   0.24.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk-3-0   3.22.5-1.1
ii  libgtksourceview-3.0-1   3.22.1-1
ii  libgtkspell3-3-0 3.0.9-1
ii  libpango-1.0-0   1.40.3-3
ii  libpeas-1.0-01.20.0-1
ii  libsecret-1-00.18.5-2
ii  libsoup2.4-1 2.56.0-2
ii  libxml2  2.9.4+dfsg1-2.1

gitg recommends no packages.

gitg suggests no packages.

-- no debconf information

Bug#849838: firefox: Fix broken hppa build support

2016-12-31 Thread John Paul Adrian Glaubitz

Source: firefox
Version: 50.1.0-1
Severity: normal
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hppa

Hi!

Firefox currently fails to build from source on hppa due to a bug
in the xpcom code. The resulting crash happens during 'make install':

resource://gre/components/Push.js
resource://gre/components/PushComponents.js
resource://gre/components/PushServiceHandler.js
Traceback (most recent call last):
  File "/<>/toolkit/mozapps/installer/packager.py", line 415, in 

main()
  File "/<>/toolkit/mozapps/installer/packager.py", line 409, in 
main
args.source, gre_path, base)
  File "/<>/toolkit/mozapps/installer/packager.py", line 166, in 
precompile_cache
errors.fatal('Error while running startup cache precompilation')
  File "/<>/python/mozbuild/mozpack/errors.py", line 103, in fatal
self._handle(self.FATAL, msg)
  File "/<>/python/mozbuild/mozpack/errors.py", line 98, in _handle
raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error while running startup cache 
precompilation

The attached patch fixes the problem by fixing the hppa-specific xpcom
code. Furthermore, it enables the PowerPC atomic operations for hppa
as these are generic enough to be used on other targets as well.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Fix build on hppa
Author: John Paul Adrian Glaubitz 
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1325495
Last-Update: 2017-01-01

Index: firefox-50.1.0/js/src/jit/AtomicOperations.h
===
--- firefox-50.1.0.orig/js/src/jit/AtomicOperations.h
+++ firefox-50.1.0/js/src/jit/AtomicOperations.h
@@ -324,6 +324,8 @@ AtomicOperations::isLockfree(int32_t siz
 # include "jit/arm/AtomicOperations-arm.h"
 #elif defined(JS_CODEGEN_ARM64)
 # include "jit/arm64/AtomicOperations-arm64.h"
+#elif defined(__hppa__)
+# include "jit/none/AtomicOperations-ppc.h"
 #elif defined(JS_CODEGEN_MIPS32) || defined(JS_CODEGEN_MIPS64)
 # include "jit/mips-shared/AtomicOperations-mips-shared.h"
 #elif defined(__ppc__) || defined(__PPC__)
Index: firefox-50.1.0/xpcom/reflect/xptcall/md/unix/xptcstubs_pa32.cpp
===
--- firefox-50.1.0.orig/xpcom/reflect/xptcall/md/unix/xptcstubs_pa32.cpp
+++ firefox-50.1.0/xpcom/reflect/xptcall/md/unix/xptcstubs_pa32.cpp
@@ -126,11 +126,20 @@ PrepareAndDispatch(nsXPTCStubBase* self,
 
 extern "C" nsresult SharedStub(int);
 
+#ifdef __GNUC__
 #define STUB_ENTRY(n)   \
 nsresult nsXPTCStubBase::Stub##n()  \
 {   \
+__asm__ __volatile__ ("STW %r26, -36-64(%sp)"); \
 return SharedStub(n);   \
 }
+#else
+#define STUB_ENTRY(n)   \
+nsresult nsXPTCStubBase::Stub##n()  \
+{   \
+return SharedStub(n);   \
+}
+#endif
 
 #define SENTINEL_ENTRY(n) \
 nsresult nsXPTCStubBase::Sentinel##n() \

Bug#849840: libavformat57: enable libopenmpt support

2016-12-31 Thread James Cowgill

Package: libavformat57
Version: 7:3.2.2-1
Severity: wishlist

Hi,

I think that libopenmpt should be enabled in the Debian ffmpeg package.
libopenmpt-dev is in the archive right now.

libopenmpt is designed to be a replacement for libmodplug as it handles
the same types of files. There is an FAQ documenting the differences
here: https://lib.openmpt.org/libopenmpt/#sec_faq. The major advantage
is that it has a fairly active upstream compared to libmodplug and
certain modules play better with it.

I don't know if libmodplug has to be disabled, but presumably ffmpeg
will choose one over the other for the vast majority of cases so I'm not
sure it's worth it having both enabled.

Thanks,
James




signature.asc
Description: OpenPGP digital signature

Bug#830989: debian-policy: Typos "the the" in "4.4 Debian changelog: debian/changelog" and "8.6.3.2 The symbols File Format"

Valentin Samir  writes:

> Reading the debian policy for the first time, I notice two minor typos
> where 'the' is repeated.

> The first time in §4.4:
> "+ or - is the the time zone offset from Coordinated Universal 
> Time (UTC)."

> The second time in §8.6.3.2
> "To explain this format, we'll use the the zlib1g package as an example, 
> […]"

Thanks!  Patch applied for the next release.

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

Bug#822059: Wrong date in upgrading-checklist

Reiner Herrmann  writes:

> Source: debian-policy
> Version: 3.9.8
> Tags: patch
> Severity: minor

> the upgrading-checklist contains an incorrect date for version 3.9.8.0.
> It was released in April, not in February.

> 3.9.8 is also not yet pushed to git.

Thanks, this will be fixed in the next release.

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

Bug#823910: debian-policy: document Build-Depends-Arch/Build-Conflicts-Arch and when it's safe to use them

Johannes Schauer  writes:

> Instead, I'd like to make a case for inclusion of Build-Depends-Arch and
> Build-Conflicts-Arch here:

>  - the fields add symmetry to the existing Build-Depends-Indep and
>Build-Conflicts-Indep fields
>  - the mapping of Build-*-Indep to the build-indep target makes one expect
>there to also be a Build-*-Arch field
>  - this mapping also makes the proposed fields logical and well fitted without
>surprised
>  - it will avoid installing useless dependencies for architecture dependent
>builds
>  - it allows separation of build dependencies needed for build-indep and
>build-arch builds from those that are needed for (for example) the clean
>target
>  - it is already supported by much software in the archive, most
>importantly it is supported by package builders and installability
>testers

> Please find attached a patch that documents Build-Depends-Arch and
> Build-Conflicts-Arch.

Thanks, seconded, and this has now been applied for the next upload.

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

Bug#849837: /usr/bin/sfill: malloc assertion failure

2016-12-31 Thread Rob Leslie

Package: secure-delete
Version: 3.1-5
Severity: important
File: /usr/bin/sfill

Dear Maintainer,

I have some filesystems on which sfill repeatably fails with:

% sfill -fllz $dir
sfill: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) 
&((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd 
&& old_size == 0) || ((unsigned long) (old_size) >= (unsigned 
long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
(sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 
0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

After this failure, the root directory of the filesystem is littered with
numerous empty files.


-- System Information:
Debian Release: 7.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (x86_64)

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

Versions of packages secure-delete depends on:
ii  libc6  2.13-38+deb7u11

secure-delete recommends no packages.

secure-delete suggests no packages.

-- no debconf information

Bug#823348: Limit the strongest dependencies on supplemental -doc packages

Josh Triplett  writes:

> Based on a thread on debian-devel about Recommends, I'd like to propose
> the attached change to policy, which limits the strongest dependency a
> package should declare on its supplemental -doc package.

> This mostly documents existing practice.  Packages don't tend to declare
> Depends on their -doc packages at all.  Packages primarily used for
> development don't tend to declare Recommends on their -doc packages to
> avoid installing them by default on the systems of developers who just
> want the package installed to support development of some other package.
> Likewise, command-line tools that already provide a manpage or a text
> manual don't tend to declare Recommends on a -doc package providing an
> HTML manual for that tool.

> The phrasing of "at most" avoids mandating any minimum dependency
> relationship, leaving it up to the maintainer's discretion how much the
> prospective user of a package will want the corresponding -doc package.

[...]

Looks reasonable to me.  Seconded.

> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..421e0d1 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -10699,6 +10699,18 @@ END-INFO-DIR-ENTRY
>   
>  
>   
> +   If package is a build tool, development tool,
> +   command-line tool, or library development package,
> +   package (or package-dev in the case of a
> +   library development package) already provides documentation in
> +   man, info, or plain text format, and package-doc
> +   provides HTML or other formats, package should declare
> +   at most a Suggests on package-doc. Otherwise,
> +   package should declare at most a Recommends on
> +   package-doc.
> + 
> +
> + 
> Additional documentation included in the package should be
> installed under /usr/share/doc/package.
> If the documentation is packaged separately,

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

Bug#849836: zekr: Missing dependency on libwebkitgtk-1.0-0

2016-12-31 Thread Awtul

Package: zekr
Version: 1.1.0+repack-2
Severity: important

Dear Maintainers,

Zekr crashes after displaying the logo with the following message:

"org.eclipse.swt.SWTError: No more handles [Unknown Mozilla path 
(MOZILLA_FIVE_HOME not set)]
at org.eclipse.swt.SWT.error(SWT.java:4387)
at org.eclipse.swt.browser.Mozilla.initMozilla(Mozilla.java:1936)
at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:699)
at org.eclipse.swt.browser.Browser.(Browser.java:99)
at net.sf.zekr.ui.QuranForm.makeFrame(QuranForm.java:628)
at net.sf.zekr.ui.QuranForm.init(QuranForm.java:340)
at net.sf.zekr.ui.QuranForm.(QuranForm.java:319)
at net.sf.zekr.ZekrMain.startZekr(ZekrMain.java:51)
at net.sf.zekr.ZekrMain.main(ZekrMain.java:94)"

Installing "libwebkitgtk-1.0-0" solves the problem. I thought it may be a 
dependency missing issue.

Salam,

Awtul

--

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

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

Versions of packages zekr depends on:
ii  default-jre [java7-runtime]2:1.8-57
ii  fonts-sil-scheherazade [ttf-sil-scheherazade]  2.100-1
ii  libbasicplayer-java3.0-6
ii  libcommons-codec-java  1.10-1
ii  libcommons-collections3-java   3.2.2-1
ii  libcommons-configuration-java  1.10-4
ii  libcommons-io-java 2.5-1
ii  libcommons-lang-java   2.6-6
ii  libcommons-logging-java1.2-1
ii  libjs-jquery   3.1.1-2
ii  liblog4j1.2-java   1.2.17-7
ii  liblucene2-java2.9.4+ds1-6
ii  libswt-cairo-gtk-3-jni 3.8.2-3
ii  libswt-gnome-gtk-3-jni 3.8.2-3
ii  libswt-gtk-3-java  3.8.2-3
ii  libswt-webkit-gtk-3-jni3.8.2-3
ii  libtritonus-java   20070428-12
ii  openjdk-8-jre [java7-runtime]  8u111-b14-3
ii  velocity   1.7-5
ii  zenity 3.22.0-1

Versions of packages zekr recommends:
ii  fonts-freefont-ttf [ttf-freefont]  20120503-6
ii  islamic-menus  1.0.5-1
ii  libjlayer-java 1.0.1-2
ii  libjorbis-java 0.0.17-2
ii  libjspeex-java 0.9.7-4
ii  libmp3spi-java 1.9.5-1
ii  libvorbisspi-java  1.0.3-3

Versions of packages zekr suggests:
pn  ttf-me-quran
pn  zekr-quran-recitation   
pn  zekr-quran-translation  

-- no debconf information

Bug#849759: duperemove: programs should be in /usr/bin rather than /usr/sbin

2016-12-31 Thread Adam Borowski

On Sat, Dec 31, 2016 at 02:56:14PM +, Peter Zahradnik wrote:
> On 12/30/2016 08:11 PM, Peter Zahradnik wrote:
> > On 12/30/2016 07:56 PM, Adam Borowski wrote:
> > > For some reason you've put the executables in /usr/sbin.  All of
> > > programs shipped by duperemove are fully functional as non-root, and
> > > often useful: an user may want to dedupe their data files,
> > > unprivileged containers, etc.

> I've uploaded new version to mentors:
> 
> https://mentors.debian.net/debian/pool/main/d/duperemove/duperemove_0.11-1.dsc
> 
> I've bumped the code to latest 0.11-branch (not beta anymore), updated
> package description so it matches yours (found it in ftp-new html [1].
> I've also added debian/patches for sbin->bin + cherry-picked your's O_RDONLY
> commit.

Awesome, looks good.

I won't upload it immediately, though.  The version in NEW has been uploaded
on 2016-12-24 5:41am.  Alas, testing migration checks the time since
ACCEPTED (which still hasn't happened), so most likely the package won't
make it to Stretch, but there's still a chance for a migration bug like we
just had with RC bug counts, the Release Team getting swayed by promises of
beer for allowing packages by upload date, etc.  It's far easier to argue if
the date is 2¾ days before the deadline than over 5 days after it.

I'd put your update into DELAYED/25 but that works only up to 15; I'll be
_very_ careful about getting run over by a bus before then :)
(Or sooner if things straighten out earlier.)

> Is there a way how to download full package from debian ftp-new ?)

Unfortunately no.  As far as I know, in the past the reason was some weird
demand by the US authorities to have Debian send them notification of every
new piece of software before it's published, not sure what's the current
explanation.  I doubt it's unchecked copyright status, as mentors.d.n nor
Github/etc have such issues.  Perhaps just inertia?

Anyway, I see you already duplicated picking that patch so there's no need
for further action.  Upstream cares about the long run rather than 4.9, but
for Debian 4.9 will stay relevant for a long time.

As for the real fix, I still haven't figured out how to get patches past Al
Viro, it's nowhere as simple as through Greg KH :/

Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#734662: Please add an example of arch-specific dependency with more than one architecture

Martin Quinson  writes:

> Hello, an example of architecture-restricted dependency with more than
> one arch should probably be added to the section 7.1 "Syntax of
> relationship fields" of the policy. The document already specify that
> the list is space-separated, but an example would still be welcome (at
> least to me).

> I propose the following chunk:

> ->8-

> If the architecture-restricted dependency should apply to more than
> one architecture, simply list all architectures between braces,
> separated with spaces. Example:

> Build-Depends:
>  libluajit5.1-dev [i386 amd64 kfreebsd-i386 armel armhf powerpc mips mipsel],
>  liblua5.1-dev [hurd-i386 ia64 kfreebsd-amd64 s390x sparc],
>   
> 8<---

Sure, sounds good to me.  I've added an example like this for the next
upload.

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

Bug#819660: explicitly allow building automatic debug symbols packages not listed in control

Tanguy Ortolo  writes:

> The Policy implicitly indicates a source package should only build
> binary packages listed in debian/control. At least, this is how
> ftpmaster interprets §5.2, 5.4 and 5.6.19, when you look at the Reject
> FAQ  (search for
> “debian/control breakage #2”).

> Now, this is quite not compatible with the new debug symbol packages
>  that are now
> automatically created.

> Since explicit is better than implicit, I think §5.2:

>>The debian/control file contains the most vital (and
>>version-independent) information about the source package and about the
>>binary packages it creates.
>>
>>The first paragraph of the control file contains information about the
>>source package in general. The subsequent sets each describe a binary
>>package that the source tree builds.

> could be completed by:

>>[…]
>>
>>The first paragraph of the control file contains information about the
>>source package in general. The subsequent sets each describe a binary
>>package that the source tree builds. All the binary packages have a
>>corresponding paragraph, except for the possible automatic debug
>>packages that do not require one.

> There may be better ways to phrase this, but I think there is still a
> need for some clarification about this.

Seems reasonable to me.  Seconded.

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

Bug#793493: debian-policy: Update dpkg-architecture flags information

Guillem Jover  writes:

> Here's a partial update to match the current dpkg-architecture output.
> I've left the MULTIARCH variable alone, because that's supposedly
> tracked on another bug.

> The wording might be a bit unnatural, review by a native speaker
> advised. :)

These all look good to me.  Seconded (and quoted below for the convenience
of others who may want to review and second).

> From 0bc030c417adfa7ca50944c918101dd9ce62bebb Mon Sep 17 00:00:00 2001
> From: Guillem Jover 
> Date: Fri, 24 Jul 2015 17:17:58 +0200
> Subject: [PATCH 1/2] Update information about DEB_TARGET_* variables

> These are used to support building cross-compilers. Introduced in
> dpkg 1.17.14.
> ---
>  policy.sgml | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)

> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..72a2505 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2175,9 +2175,16 @@ zope.
> the architecture on which debian/rules is run and
> the package build is performed.  The host architecture is the
> architecture on which the resulting package will be installed
> -   and run.  These are normally the same, but may be different in
> +   and run.  The target architecture is the architecture of the
> +   packages that the compiler currently being built will generate.
> +   These are normally the same, but may be different in
> the case of cross-compilation (building packages for one
> -   architecture on machines of a different architecture).
> +   architecture on machines of a different architecture), building a
> +   cross-compiler (a compiler package that will generate objects for
> +   one architecture, built on a machine of a different architecture)
> +   or a Canadian cross-compiler (a compiler that will generate
> +   objects for one architecture, built on a machine of a different
> +   architecture, that will run on yet a different architecture).
>   
>  
>   
> @@ -2205,8 +2212,9 @@ zope.
>   DEB_*_GNU_TYPE)
> 
> where * is either BUILD for specification of
> -   the build architecture or HOST for specification of the
> -   host architecture.
> +   the build architecture, HOST for specification of the
> +   host architecture or TARGET for specification of the
> +   target architecture.
>   
>  
>   
> -- 
> 2.5.0.rc2.392.g76e840b


> From 70aaad841a5067db2737ea658532eb92d9376888 Mon Sep 17 00:00:00 2001
> From: Guillem Jover 
> Date: Fri, 24 Jul 2015 17:19:06 +0200
> Subject: [PATCH 2/2] Update information about DEB_*_ARCH_* variables

> Mention DEB_*_ARCH_BITS and DEB_*_ARCH_ENDIAN. Introduced in dpkg 1.15.4.
> ---
>  policy.sgml | 6 ++
>  1 file changed, 6 insertions(+)

> diff --git a/policy.sgml b/policy.sgml
> index 72a2505..b7f0464 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2197,6 +2197,12 @@ zope.
>   DEB_*_ARCH_CPU (the Debian CPU name)
>   
>   
> + DEB_*_ARCH_BITS (the Debian CPU pointer size in bits)
> + 
> + 
> + DEB_*_ARCH_ENDIAN (the Debian CPU endianness)
> + 
> + 
>   DEB_*_ARCH_OS (the Debian System name)
>   
>   
> -- 
> 2.5.0.rc2.392.g76e840b

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

Bug#849835: Include MPL-1.1 and MPL-2.0 in common-licenses

Santiago Vila  writes:
> On Sat, Dec 31, 2016 at 03:21:18PM -0800, Russ Allbery wrote:

>> Debian Policy decided, in Bug#768292, to include MPL-1.1 and MPL-2.0
>> in common-licenses.  This change was made and uploaded to the archive
>> in debian-policy release 3.9.7.0.

As noted in a follow-up note, this is thankfully not true.  Someone
commited a bunch of changes to the Debian Policy Git repository adding
changelog entries under the 3.9.7.0 heading, but those changes weren't
included in the upload.  I then got confused.

This change will be in the forthcoming 3.9.9.0.

> Side comment: A binary package does not seem very canonical to me.  Is
> there an official URL for this? (I'm trying to avoid anybody nitpicking
> with formatting, extra spaces and the like, as it happened at least once
> in the past with some GPL license).

Yes, good point.

These appear to be the canonical plain text versions of the licenses from
Mozilla:

https://www.mozilla.org/media/MPL/1.1/index.0c5913925d40.txt
https://www.mozilla.org/media/MPL/2.0/index.815ca599c9df.txt

as linked from here: https://www.mozilla.org/en-US/MPL/

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

Bug#849835: Include MPL-1.1 and MPL-2.0 in common-licenses

2016-12-31 Thread Santiago Vila

On Sat, Dec 31, 2016 at 03:21:18PM -0800, Russ Allbery wrote:
> Package: base-files
> Version: 9.7
> Severity: normal
> 
> Debian Policy decided, in Bug#768292, to include MPL-1.1 and MPL-2.0
> in common-licenses.  This change was made and uploaded to the archive
> in debian-policy release 3.9.7.0.
> 
> Could you include those two files in common-licenses in base-files?
> 
> You can find canonical copies of those files in, among other places,
> /usr/share/doc/firefox in the current (5.1.0-1) firefox package in
> unstable.
> 
> (Sent with my Policy Editor hat on.)

Ok, will be done in the next upload, whenever that will be.

Side comment: A binary package does not seem very canonical to me.
Is there an official URL for this? (I'm trying to avoid anybody
nitpicking with formatting, extra spaces and the like, as it happened
at least once in the past with some GPL license).

Thanks a lot.

Bug#768292: Add the MPL licenses to common-licenses

Control: reopen -1

> It looks like there was a breakdown of communication from Policy
> maintenance to you with an addition to common-licenses.  Following
> discussion in Bug#768292, we decided to add MPL-1.1 and MPL-2.0 to
> common-licenses, and the relevant Policy change landed in 3.9.7.0.  But
> something went wrong and the Policy bug was never closed, and I don't
> think you were ever told for inclusion of those files in base-files.

> I'll go ahead and file a bug against base-files for your tracking, and am
> closing out the Policy bug with this message.  Policy says to include:

> /usr/share/common-licenses/MPL-1.1
> /usr/share/common-licenses/MPL-2.0

> You can find canonical copies of those files in, among other places,
> /usr/share/doc/firefox in the current (5.1.0-1) firefox package in
> unstable.

Oh, gah, this was *not* included in 3.9.7.0.  Instead, a bunch of really
weird things happend to the Policy Git repository.

That does make me feel better about the communication, though.  :)

This change *will* be included in the upcoming 3.9.9.0 upload, so the
request to include them in base-files still applies, but base-files is not
out of sync with current Policy.  I'm now fixing up the Policy Git
repository.

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

Bug#849835: Include MPL-1.1 and MPL-2.0 in common-licenses

Package: base-files
Version: 9.7
Severity: normal

Debian Policy decided, in Bug#768292, to include MPL-1.1 and MPL-2.0
in common-licenses.  This change was made and uploaded to the archive
in debian-policy release 3.9.7.0.

Could you include those two files in common-licenses in base-files?

You can find canonical copies of those files in, among other places,
/usr/share/doc/firefox in the current (5.1.0-1) firefox package in
unstable.

(Sent with my Policy Editor hat on.)

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

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

Versions of packages base-files depends on:
ii  mawk [awk]  1.3.3-17

base-files recommends no packages.

base-files suggests no packages.

-- no debconf information

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8

2016-12-31 Thread Jason Pyeron

> -Original Message-
> From: Klaus Ethgen
> Sent: Saturday, December 31, 2016 08:48
> To: Willi Mann
> Cc: Jason Pyeron; 849...@bugs.debian.org; logwatch-de...@lists.sourceforge.net
> 
> Hi,
> 
> Am Sa den 31. Dez 2016 um 14:28 schrieb Willi Mann:
> > thanks for your test cases. However, I don't think that 
> binmode provides
> > an acceptable solution, at least not alone. While it 
> ensures that the
> > strings are valid utf-8 strings, it will convert any valid utf-8
> > character to two "garbage" characters. Try

Not exactly a valid test, besides it works for me. The issue is internal ascii 
data being written as ascii but instructing consumers
it is uft8. 

$ cat utf8_test.pl
#!/usr/bin/perl
#
use strict;
use File::Slurp;

my $inputfile = @ARGV[0];
my $logfilecontent = read_file($inputfile);
binmode(STDOUT, ":utf8");
print $logfilecontent;

$ ./utf8_test.pl testlog.txt
übersät

$ ./utf8_test.pl testlog.txt | hexdump -C
  c3 bc 62 65 72 73 c3 a4  74 0a|..bers..t.|
000a

$ hexdump.exe -C testlog.txt
  fc 62 65 72 73 e4 74 0a   |.bers.t.|
0008

> 
> Well, that "garbage" is by design for UTF-8. If you don't want that,
> stay on latin1.
> 
> It is a no-go to set the mime type to UTF-8 but still send latin1. (As
> it does the current version.) Setting header to UTF-8 doesn't 
> change the
> content of the mail. It just open up for troubles.
> 
> Regards
>Klaus
> - -- 
> Klaus Ethgen   
> http://www.ethgen.ch/
> pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
> 
> Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
> -BEGIN PGP SIGNATURE-
> Comment: Charset: ISO-8859-1
> 
> iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhntxMACgkQpnwKsYAZ
> 9qyD4gv/ThmNQDCI9QeXYGvwafNDzcDtaHUpeGhOqJI4NjE/UxvPDGIJsMAmS3fI
> w69zDuHmy9d1AsCm4I8ipF9l1LD1GHo8Fh9g2Uiv4l6d5e4jYmMi/L/pJxqbAqIt
> A1LjNQUNGMLk97OHLqR5/9lnfOzahdzgEVNP/Fi5ygVXi3vJFdwfFFbWk39CfYUy
> jcKQUdDzbQUzyFLl7I+1pZm19HCDH4v5fIzqwQW8bz4VXpTIUZjXJSV2n5gN1Lo9
> 99utKdR1b1UQScdGs2zV/QhVN/IJJsNNzK4Zylisdjw0ZgvnSW3gt461d62FAH1o
> R4UwerUZYWzCGLZHpGwPw/1/s7YOAlPlO46UzSslqC0J0mmcCPG5eBz4iX2F03U3
> uoz3gscPsjFAf/eqlkp6MHXeNqSV2cCwQLnqZ17/py5DiMUxS61dFXRmcrLOotC0
> KmDBRC7Gft8dcr4bjqYG3jIv0ppOEdvA1izQQ+q2WNQ4E7AprDPJ94MgibQ8BBYX
> iGbaxnj2
> =af5+
> -END PGP SIGNATURE-
>

Bug#849696: libogre-1.9.0v5: Ogre games abort on startup with “basic_string::_M_construct null not valid” / freeimage API issues

2016-12-31 Thread James Cowgill

Hi,

On 31/12/16 17:49, Manuel A. Fernandez Montecelo wrote:
> 2016-12-30 02:33 James Cowgill:
>> On 29/12/16 21:52, Thibaut Girka wrote:
>>> This started happening since upgrading libfreeimage3, so this might
>>> be a bug in
>>> it rather than in Ogre itself, but I haven't investigated any further
>>> yet.
>>
>> This appears to be a regression in the Debian patch applied in
>> libfreeimage3 3.17.0+ds1-4.
>>
>> Ogre contains this (OgreMain/src/OgreFreeImageCodec.cpp:98):
>>> for (int i = 0; i < FreeImage_GetFIFCount(); ++i)
>>> {
>>> // Skip DDS codec since FreeImage does not have the option
>>> // to keep DXT data compressed, we'll use our own codec
>>> if ((FREE_IMAGE_FORMAT)i == FIF_DDS)
>>> continue;
>>>
>>> String exts(FreeImage_GetFIFExtensionList((FREE_IMAGE_FORMAT)i));
>> [loop body continues]
>> [String is typedefed to std::string]
>>
>> This code assumes that FreeImage_GetFIFExtensionList will never return
>> NULL for values of i between 0 and FreeImage_GetFIFCount(). However in
>> the most recent Debian version of freeimage,
>> FreeImage_GetFIFExtensionList(27 / FIF_FAXG3) does return NULL.
>>
>> It is unclear to me who is wrong here. The documentation does not
>> suggest anything about when FreeImage_GetFIFExtensionList can fail,
>> although the examples always check FreeImage_FIFSupportsReading before
>> calling it. Can any freeimage maintainer suggest the best way to fix
>> this?
> 
> Thanks for the analysis.
> 
> The comment on the patch seems to add some light as to the cause of this
> breakage:
> 
>  
> https://anonscm.debian.org/cgit/debian-science/packages/freeimage.git/commit/?id=a67fe8c111d0de919b7a6710d4dd5efe05fbf380
> 
> 
>  ++//allows adding a NULL node in order to not mess up plugin
>  ++//numbering when some are disabled. Otherwise there will be a
>  ++//discrepancy between FREE_IMAGE_FORMAT enumerator values and the
>  ++//actual format.
>  ++m_plugin_map[(const int)m_plugin_map.size()] = 0;
> 
> 
> If freeimage plans to ship with this change and not revert it somehow,
> the OGRE plugin for freeimage needs to check for the possibility of
> having null nodes in this structure.
vvt
Yes, but my question is whether the freeimage API allows for this
patch. Either the patch is correct according to the API and OGRE should
be patched in both Debian and upstream, or the patch is wrong and an
alternate solution in freeimage should be found which doesn't return
NULLs. It seems like a bit of an unmaintainable hack to patch OGRE in
Debian only.

Also, I just did a search of the archive and cegui-mk2 is probably
broken by this bug as well:
http://sources.debian.net/src/cegui-mk2/0.8.7-1.3/cegui/src/ImageCodecModules/FreeImage/ImageCodec.cpp/?hl=58#L58

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#849834: keychain: diff for NMU version 2.8.2-0.1

2016-12-31 Thread Niels Thykier

Package: keychain
Version: 2.8.1-0.1
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared an NMU for keychain (versioned as 2.8.2-0.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru keychain-2.8.1/ChangeLog keychain-2.8.2/ChangeLog
--- keychain-2.8.1/ChangeLog2015-05-29 16:48:32.0 +
+++ keychain-2.8.2/ChangeLog2015-11-07 00:11:24.0 +
@@ -2,7 +2,7 @@
 #
 # Copyright 2002-2006 Gentoo Foundation http://www.gentoo.org/
 # Copyright 2007 Aron Griffis 
-# Copyright 2009-2015 Funtoo Technolgies, LLC.
+# Copyright 2009-2015 Funtoo Solutions, Inc.
 # lockfile() Copyright 2009 Parallels, Inc.
 
 # Distributed under the GNU General Public License version 2
@@ -12,6 +12,21 @@
 # Maintained and rewritten April 2004 - July 2007 by Aron Griffis 

 # Maintained July 2009 - present by Daniel Robbins 
 
+* keychain 2.8.2 (06 Nov 2015)
+
+  Summary: Support new ssh features, bug fix release.
+
+  Support for new hash algorithms (Ben Boeckel)
+
+  Remove bashisms (Daniel Hertz)
+
+  Various optimizations (Daniel Hahler)
+
+  --timeout option now gets passed to agent, doc fixes (Andrew Bezella, Emil
+  Lundberg)
+
+  RPM, Makefile fixes (Mike Frysinger)
+
 * keychain 2.8.1 (29 May 2015)
 
   Summary: POSIX compatibility and bug fix release.
diff -Nru keychain-2.8.1/debian/changelog keychain-2.8.2/debian/changelog
--- keychain-2.8.1/debian/changelog 2015-09-05 07:04:43.0 +
+++ keychain-2.8.2/debian/changelog 2016-12-31 22:35:22.0 +
@@ -1,3 +1,17 @@
+keychain (2.8.2-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.  (Closes: #847445)
+- Fixes bashisms causing syntax errors.  (Closes: #815510)
+- Cleanly separates the --help output for --stop and
+  --systemd.  (Closes: #800555)
+  * Convert to 3.0 (quilt) source format to avoid making this
+a native package again.  (see #800555)
+  * Convert d/rules to dh7-style given that upstream removed
+its build system.
+
+ -- Niels Thykier   Sat, 31 Dec 2016 22:35:22 +
+
 keychain (2.8.1-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru keychain-2.8.1/debian/docs keychain-2.8.2/debian/docs
--- keychain-2.8.1/debian/docs  1970-01-01 00:00:00.0 +
+++ keychain-2.8.2/debian/docs  2016-12-31 22:29:05.0 +
@@ -0,0 +1 @@
+keychain.pod
diff -Nru keychain-2.8.1/debian/install keychain-2.8.2/debian/install
--- keychain-2.8.1/debian/install   1970-01-01 00:00:00.0 +
+++ keychain-2.8.2/debian/install   2016-12-31 22:26:40.0 +
@@ -0,0 +1 @@
+keychain usr/bin/
diff -Nru keychain-2.8.1/debian/keychain.docs 
keychain-2.8.2/debian/keychain.docs
--- keychain-2.8.1/debian/keychain.docs 2015-09-05 06:51:25.0 +
+++ keychain-2.8.2/debian/keychain.docs 1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-README.md
diff -Nru keychain-2.8.1/debian/manpages keychain-2.8.2/debian/manpages
--- keychain-2.8.1/debian/manpages  1970-01-01 00:00:00.0 +
+++ keychain-2.8.2/debian/manpages  2016-12-31 22:29:10.0 +
@@ -0,0 +1 @@
+keychain.1
diff -Nru keychain-2.8.1/debian/rules keychain-2.8.2/debian/rules
--- keychain-2.8.1/debian/rules 2015-09-05 06:59:17.0 +
+++ keychain-2.8.2/debian/rules 2016-12-31 22:26:55.0 +
@@ -1,90 +1,3 @@
 #!/usr/bin/make -f
-# Sample debian/rules that uses debhelper.
-# GNU copyright 1997 to 1999 by Joey Hess.
-
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
-
-configure: configure-stamp
-configure-stamp:
-   dh_testdir
-   # Add here commands to configure the package.
-
-
-   touch configure-stamp
-
-build-arch:
-# We have nothing to do by default.
-
-build-indep build: configure-stamp build-stamp
-build-stamp:
-   dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE) keychain keychain.1
-
-   touch build-stamp
-
-clean:
-   dh_testdir
-   dh_testroot
-   rm -f build-stamp configure-stamp
-
-   # Add here commands to clean up after the build process.
-   $(MAKE) clean
-
-   dh_clean
-
-install: install-indep install-arch
-
-install-arch: build-arch
-# We have nothing to do by default.
-
-install-indep: build-indep
-   dh_testdir
-   dh_testroot
-   dh_prep
-   dh_installdirs
-
-   # Add here commands to install the package into debian/keychain.
-   #$(MAKE) install DESTDIR=$(CURDIR)/debian/keychain
-   install -m0755 keychain $(CURDIR)/debian/keychain/usr/bin
-
-
-# Build architecture-independent files here.
-binary-indep: build-indep install-indep
-   dh_testdir
-   dh_testroot
-#  dh_installdebconf   
-   dh_installdocs keychain.pod
-   dh_installexamples
-#  dh_installmenu
-#  dh_installlogrotate
-#  dh_installemacsen
-#

Bug#781654: copyright-format: "IBM CPL" -> "CPL" in license short names table

Charles Plessy  writes:
> Stefano Zacchiroli  writes:

>>   in the short name license tables, shipped as part of the machine readable
>> copyright format specification and available online at
>> 
>>   
>> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name
>> 
>> the long name of the Common Public License (CPL) is incorrect.

> Since the long names from the license table are not formally used in the
> specification, I think that the issue is non-normative and can be
> corrected without changing the revision number in the Format string of
> the Copyright files.

> I am wondering if it would be better to mark the corrected version of
> the specification as 1.0.1 in the text, but keep distributing the files
> as 1.0, or to just correct the version 1.0 without incrementing any
> revision number anywyere.

I vote for just fixing it without changing the revision number for this
sort of minor thing, on the grounds that we shouldn't put too many
obstacles in the way of fixing minor issues.

I've gone ahead and made this fix for the next upload.

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

Bug#849370: Re%3A aptitude%3A Aptitude crashes with SIGABRT on install command

2016-12-31 Thread Jonathan Seeley

Here's a backtrace from my attempt. In my case, I attempted using 'g' in
the ncurses UI vs installing on the CLI as I had mixed results getting it
to repeat on the normal CLI.
method: gdb aptitude
type: run
press 'g' after aptitude loads.

Similarly, I had the issue occur if I tried shift+U to select all
upgradeable packages for upgrade.


#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
set = {__val = {134217728, 140737309744532, 64, 1024,
140737488338600, 140737338622695, 140737488338432,
0, 140737488338464, 0, 140737488338592, 140737488338344,
140737488338312, 140737339102045,
140737488338616, 140737488339104}}
pid = 
tid = 
#1  0x7556340a in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x57b1f4a0,
sa_sigaction = 0x57b1f4a0}, sa_mask = {
__val = {140737349022755, 1024, 140737228880889,
140737228880891, 140737349023252, 140737201600631,
  140737228880891, 140737228880886, 140737201600633,
140737228880893, 140737349023978, 93825000266448,
  1, 9382479264, 140737488338960, 140737488338960}},
sa_flags = 7, sa_restorer = 0x42}
sigs = {__val = {32, 0 }}
#2  0x55732a45 in ?? ()
No symbol table info available.
#3  0x55734b5f in ?? ()
No symbol table info available.
#4  0x557564e0 in ?? ()
No symbol table info available.
#5  0x557509ad in ?? ()
No symbol table info available.
#6  0x55750a98 in ?? ()
No symbol table info available.
#7  0x55751c5a in ?? ()
No symbol table info available.
#8  0x558286c6 in ?? ()
No symbol table info available.
#9  0x558187d4 in ?? ()
No symbol table info available.
#10 0x557a0066 in ?? ()
No symbol table info available.
#11 0x557a1c71 in ?? ()
No symbol table info available.
#12 0x556918d0 in ?? ()
No symbol table info available.
#13 0x771a2338 in
cwidget::widgets::widget::handle_key(cwidget::config::key const&) ()
   from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
No symbol table info available.
#14 0x77179406 in
cwidget::widgets::passthrough::handle_key(cwidget::config::key const&) ()
   from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
No symbol table info available.
#15 0x771a5ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) ()
   from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
No symbol table info available.
#16 0x7715a1f1 in
cwidget::widgets::menubar::handle_key(cwidget::config::key const&) ()
   from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
No symbol table info available.
#17 0x771a5ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) ()
   from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
No symbol table info available.
#18 0x77127dc9 in
cwidget::toplevel::input_thread::get_input_event::dispatch() ()
   from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
No symbol table info available.
#19 0x7711f6b5 in cwidget::toplevel::mainloop(int) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
No symbol table info available.
#20 0x55691a9a in ?? ()
No symbol table info available.
#21 0x555b45cd in ?? ()
No symbol table info available.
#22 0x7554f2b1 in __libc_start_main (main=0x555b2ec0, argc=1,
argv=0x7fffe6d8,
init=, fini=, rtld_fini=,
stack_end=0x7fffe6c8)
at ../csu/libc-start.c:291
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0,
-2077195343954987300, 93824992664080, 140737488348880, 0,
0, -5298197743595440420, -5298185417430550820},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0,
  0x7fffe6e8, 0x77ffe168}, data = {prev = 0x0, cleanup
= 0x0, canceltype = -6424}}}
not_first_call = 
#23 0x555bda3a in ?? ()
No symbol table info available.


On Sat, Dec 31, 2016 at 4:59 PM, Jonathan Seeley 
wrote:

> I'm having the same issue, both with 0.8.3-1+b2 and 0.8.4-1.
>

Bug#849827: Fwd: Re: Bug#849827: live-build fails to build amd64 target

2016-12-31 Thread Ben Armstrong

User error. This bug should be closed.

--- Forwarded message ---
From: Ben Armstrong 
Date: December 31, 2016 5:45:12 PM
Subject: Re: Bug#849827: live-build fails to build amd64 target
To: Peter.Stein , sub...@bugs.debian.org

You are misusing the --linux-packages option which is only to specify 
kernel and kernel modules. See live-manual and use package lists instead.

Ben

On December 31, 2016 4:45:26 PM "Peter.Stein"  wrote:

Package: live-build
Version: 1:20161216

I configure with:

lb config --debian-installer live -d stretch --archive-areas main
contrib non-free upstream restricted --linux-packages `dpkg-query -f
'${binary:Package}\n' -W`

This configures the target for the same packages as those installed on
the build host. It seems to correctly configure:

P: Creating config tree for a debian/stretch/amd64 system
P: Symlinking hooks...

Now whenever a build (lb build) is attempted it fails in the same way.
The build chugs along retrieving/verifying/unpacking packages. So far so
good.
But the build eventually fails with:

Reading package lists... Done
Building dependency tree
Reading state information... Done
[2016-12-31 14:30:15] lb chroot_install-packages install
P: Begin installing packages (install pass)...
Reading package lists... Done
Building dependency tree
Reading state information... Done
*E: Unable to locate package a2ps-amd64*
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists... Done
Building dependency tree
Reading state information... Done

Note *E: Unable to locate package a2ps-amd64

*a2ps happens to be the first package in my package list. It doesn't
matter which package is first - the build appends the suffix "-amd64" to
create an illegal package name (no such package exists). As there are no
options for either "lb config" or "lb build" which affect this behavior
I'm concluding this is a bug. I've scoured all the documentation such as
https://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html
and spent hours googling for answers or workarounds without success.
Please advise.

Build host:
uname -a
Linux nehalem 4.1.17 #2 SMP Sun Feb 14 22:42:14 CST 2016 x86_64 GNU/Linux

Bug#849827: live-build fails to build amd64 target

2016-12-31 Thread Ben Armstrong

You are misusing the --linux-packages option which is only to specify 
kernel and kernel modules. See live-manual and use package lists instead.


Ben


On December 31, 2016 4:45:26 PM "Peter.Stein"  wrote:


Package: live-build
Version: 1:20161216

I configure with:

lb config --debian-installer live -d stretch --archive-areas main
contrib non-free upstream restricted --linux-packages `dpkg-query -f
'${binary:Package}\n' -W`

This configures the target for the same packages as those installed on
the build host. It seems to correctly configure:

P: Creating config tree for a debian/stretch/amd64 system
P: Symlinking hooks...

Now whenever a build (lb build) is attempted it fails in the same way.
The build chugs along retrieving/verifying/unpacking packages. So far so
good.
But the build eventually fails with:

Reading package lists... Done
Building dependency tree
Reading state information... Done
[2016-12-31 14:30:15] lb chroot_install-packages install
P: Begin installing packages (install pass)...
Reading package lists... Done
Building dependency tree
Reading state information... Done
*E: Unable to locate package a2ps-amd64*
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists... Done
Building dependency tree
Reading state information... Done

Note *E: Unable to locate package a2ps-amd64

*a2ps happens to be the first package in my package list. It doesn't
matter which package is first - the build appends the suffix "-amd64" to
create an illegal package name (no such package exists). As there are no
options for either "lb config" or "lb build" which affect this behavior
I'm concluding this is a bug. I've scoured all the documentation such as
https://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html
and spent hours googling for answers or workarounds without success.
Please advise.

Build host:
uname -a
Linux nehalem 4.1.17 #2 SMP Sun Feb 14 22:42:14 CST 2016 x86_64 GNU/Linux

Bug#849827: live-build fails to build amd64 target

2016-12-31 Thread Ben Armstrong


On December 31, 2016 6:10:55 PM "Peter.Stein"  wrote:

I'm only seeing --linux-packages as a possible option for specifying
configuration PACKAGES. Is there another option in this list that's
appropriate?



No. You use package lists instead.


As for what's in that manual - it's nearly incomprehensible. Is there a
step-by-step HOWTO available somewhere?


Read the section on using package lists. If you don't understand something 
there, ask here, making reference to the part of the manual you don't 
understand so we can improve it.


Ben

Bug#849827: live-build fails to build amd64 target

2016-12-31 Thread Amilton Jesus

Em sáb,
 31 de dez de 2016 às 20:06, Peter.Stein  escreveu:

>
>
>
>
>
>
>
>
>
>
> Ok, my bad. But there are plenty of
>
> examples oqn the web of specifying pacmgkages via the "lb config"
>
> command such as:
>
>
>
>
>
> http://www.debianuserforums.orrg/viewtopic.php?f=9=185
> 
>
>
>
>
>
> The --packages option shown there and in other examples isn't
>
> available in my version of live-build:
>
>
>
>
>
> lb config   [--apt apt|aptitude]
>
>
> [--apt-ftp-proxy URL]
>
>
> [--apt-http-proxy URL]
>
>
> [--apt-indices true|false]
>
>
> [--apt-options OPTION|"OPTIONS"]
>
>
> [--aptitude-options OPTION|"OPTIONS"]
>
>
> [--apt-pipeline DEPTH]
>
>
> [--apt-recommends true|false]
>
>
> [--apt-secure true|false]
>
>
> [--apt-source-archives true|false]
>
>
> [-a|--architectures ARCHITECTURE]
>
>
> [-b|--binary-images iso|iso-hybrid|netboot|tar|hdd]
>
>
> [--binary-filesystem fat16|fat32|ext2|ext3|ext4|ntfs]
>
>
> [--bootappend-install PARAMETER|"PARAMETERS"]
>
>
> [--bootappend-live PARAMETER|"PARAMETERS"]
>
>
> [--bootappend-live-failsafe PARAMETER|"PARAMETERS"]
>
>
> [--bootloaders grub-legacy|grub-pc|syslinux|grub-efi]
>
>
> [--cache true|false]
>
>
> [--cache-indices true|false]
>
>
> [--cache-packages true|false]
>
>
> [--cache-stages STAGE|"STAGES"]
>
>
> [--checksums md5|sha1|sha256|sha512|none]
>
>
> [--compression bzip2|gzip|lzip|xz|none]
>
>
> [--config GIT_URL::GIT_BRANCH]
>
>
> [--zsync true|false]
>
>
> [--build-with-chroot true|false]
>
>
> [--chroot-filesystem
>
> ext2|ext3|ext4|squashfs|jffs2|none]
>
>
> [--clean
>
>
> [-c|--conffile FILE]
>
>
> [--debconf-frontend
>
> dialog|editor|noninteractive|readline]
>
>
> [--debconf-priority low|medium|high|critical]
>
>
> [--debian-installer
>
> true|cdrom|netinst|netboot|businesscard|live|false]
>
>
> [--debian-installer-distribution daily|CODENAME]
>
>
> [--debian-installer-preseedfile FILE|URL]
>
>
> [--debian-installer-gui true|false]
>
>
> [--debootstrap-options OPTIONS]
>
>
> [--debootstrap-script SCRIPT]
>
>
> [--debug]
>
>
> [-d|--distribution CODENAME]
>
>
> [--parent-distribution CODENAME]
>
>
> [--parent-debian-installer-distribution CODENAME]
>
>
> [--dump]
>
>
> [--fdisk fdisk|fdisk.dist]
>
>
> [--force]
>
>
> [--grub-splash FILE]
>
>
> [--gzip-options OPTION|"OPTIONS"]
>
>
> [--ignore-system-defaults]
>
>
> [--initramfs auto|none|live-boot]
>
>
> [--initramfs-compression bzip2|gzip|lzma]
>
>
> [--initsystem sysvinit|systemd|none]
>
>
> [--image-name [NAME]
>
>
> [--interactive shell]
>
>
> [--isohybrid-options OPTION|"OPTIONS"]
>
>
> [--hdd-label LABEL]
>
>
> [--hdd-size MB]
>
>
> [--hdd-partition-start [parted unit, e.g. 63s]
>
>
> [--iso-application NAME]
>
>
> [--iso-preparer NAME]
>
>
> [--iso-publisher NAME]
>
>
> [--iso-volume NAME]
>
>
> [--jffs2-eraseblock SIZE]
>
>
> [--keyring-packages PACKAGE|"PACKAGES"]
>
>
> [-k|--linux-flavours FLAVOUR|"FLAVOURS"]
>
>
> [--linux-packages "PACKAGES"]
>
>
> [--losetup losetup|losetup.orig]
>
>
> [--memtest memtest86+|memtest86|none]
>
>
> [-m|--parent-mirror-bootstrap URL]
>
>
> [--parent-mirror-chroot URL]
>
>
> [--parent-mirror-chroot-security URL]
>
>
> [--parent-mirror-binary URL]
>
>
> [--parent-mirror-binary-security URL]
>
>
> [--parent-mirror-debian-installer URL]
>
>
> [--mirror-bootstrap URL]
>
>
> [--mirror-chroot URL]
>
>
> [--mirror-chroot-security URL]
>
>
> [--mirror-binary URL]
>
>
> [--mirror-binary-security URL]
>
>
> [--mirror-debian-installer URL]
>
>
> [--mode debian]
>
>
> [--system live|normal]
>
>
> [--net-root-filesystem nfs|cfs]
>
>
> [--net-root-mountoptions OPTIONS]
>
>
> [--net-root-path PATH]
>
>
> [--net-root-server IP|HOSTNAME]
>
>
> [--net-cow-filesystem nfs|cfs]
>
>
> [--net-cow-mountoptions OPTIONS]
>
>
> [--net-cow-path PATH]
>
>
> [--net-cow-server IP|HOSTNAME]
>
>
> [--net-tarball true|false]
>
>
> [--quiet]
>
>
>

Bug#831391: [Pkg-fonts-devel] Bug#831391: [Pkg-ime-devel] Bug#831391: U+2601 CLOUD 反而像電信桿而非雲

2016-12-31 Thread Paul Hardy

On Sat, Dec 31, 2016 at 2:09 AM, Paul Wise  wrote:

> On Sat, Dec 31, 2016 at 12:46 PM, Paul Hardy wrote:
>
> > I will notify upstream (where the fix should be made), but of course
> > it is too late to change before the stretch freeze.
>
> You have until Feb 5th to update packages that are already in testing:
>
> https://lists.debian.org/debian-devel-announce/2016/12/msg0.html
>
> These two RC bugs would need to be fixed in addition: #737167 and #808850.
>

If anyone reading this is able to modify the Wen Quan Yi sources upstream,
let me know and I can send you patches.  I emailed the upstream maintainer,
Qianqian Fang, about this yesterday, but I know he is extremely busy.

The RC bugs both have to do with Debian packaging, so I am hoping the team
maintaining this package can fix those.

I also am not certain that debian/watch is pointing to the right location.
It might be (so I am not filing a bug about this right now), but I have
always gotten the latest Wen Quan Yi font files from
http://wenq.org/daily/east/.  That is where Qianqian told me to download
them from years ago for the latest daily builds, and that link still works.

Paul Hardy

Bug#849827: live-build fails to build amd64 target

2016-12-31 Thread Peter.Stein

Ok, my bad. But there are plenty of examples on the web of specifying 
packages via the "lb config" command such as:


http://www.debianuserforums.org/viewtopic.php?f=9=185

The --packages option shown there and in other examples isn't available 
in my version of live-build:


lb config   [--apt apt|aptitude]
[--apt-ftp-proxy URL]
[--apt-http-proxy URL]
[--apt-indices true|false]
[--apt-options OPTION|"OPTIONS"]
[--aptitude-options OPTION|"OPTIONS"]
[--apt-pipeline DEPTH]
[--apt-recommends true|false]
[--apt-secure true|false]
[--apt-source-archives true|false]
[-a|--architectures ARCHITECTURE]
[-b|--binary-images iso|iso-hybrid|netboot|tar|hdd]
[--binary-filesystem fat16|fat32|ext2|ext3|ext4|ntfs]
[--bootappend-install PARAMETER|"PARAMETERS"]
[--bootappend-live PARAMETER|"PARAMETERS"]
[--bootappend-live-failsafe PARAMETER|"PARAMETERS"]
[--bootloaders grub-legacy|grub-pc|syslinux|grub-efi]
[--cache true|false]
[--cache-indices true|false]
[--cache-packages true|false]
[--cache-stages STAGE|"STAGES"]
[--checksums md5|sha1|sha256|sha512|none]
[--compression bzip2|gzip|lzip|xz|none]
[--config GIT_URL::GIT_BRANCH]
[--zsync true|false]
[--build-with-chroot true|false]
[--chroot-filesystem ext2|ext3|ext4|squashfs|jffs2|none]
[--clean
[-c|--conffile FILE]
[--debconf-frontend dialog|editor|noninteractive|readline]
[--debconf-priority low|medium|high|critical]
[--debian-installer 
true|cdrom|netinst|netboot|businesscard|live|false]

[--debian-installer-distribution daily|CODENAME]
[--debian-installer-preseedfile FILE|URL]
[--debian-installer-gui true|false]
[--debootstrap-options OPTIONS]
[--debootstrap-script SCRIPT]
[--debug]
[-d|--distribution CODENAME]
[--parent-distribution CODENAME]
[--parent-debian-installer-distribution CODENAME]
[--dump]
[--fdisk fdisk|fdisk.dist]
[--force]
[--grub-splash FILE]
[--gzip-options OPTION|"OPTIONS"]
[--ignore-system-defaults]
[--initramfs auto|none|live-boot]
[--initramfs-compression bzip2|gzip|lzma]
[--initsystem sysvinit|systemd|none]
[--image-name [NAME]
[--interactive shell]
[--isohybrid-options OPTION|"OPTIONS"]
[--hdd-label LABEL]
[--hdd-size MB]
[--hdd-partition-start [parted unit, e.g. 63s]
[--iso-application NAME]
[--iso-preparer NAME]
[--iso-publisher NAME]
[--iso-volume NAME]
[--jffs2-eraseblock SIZE]
[--keyring-packages PACKAGE|"PACKAGES"]
[-k|--linux-flavours FLAVOUR|"FLAVOURS"]
[--linux-packages "PACKAGES"]
[--losetup losetup|losetup.orig]
[--memtest memtest86+|memtest86|none]
[-m|--parent-mirror-bootstrap URL]
[--parent-mirror-chroot URL]
[--parent-mirror-chroot-security URL]
[--parent-mirror-binary URL]
[--parent-mirror-binary-security URL]
[--parent-mirror-debian-installer URL]
[--mirror-bootstrap URL]
[--mirror-chroot URL]
[--mirror-chroot-security URL]
[--mirror-binary URL]
[--mirror-binary-security URL]
[--mirror-debian-installer URL]
[--mode debian]
[--system live|normal]
[--net-root-filesystem nfs|cfs]
[--net-root-mountoptions OPTIONS]
[--net-root-path PATH]
[--net-root-server IP|HOSTNAME]
[--net-cow-filesystem nfs|cfs]
[--net-cow-mountoptions OPTIONS]
[--net-cow-path PATH]
[--net-cow-server IP|HOSTNAME]
[--net-tarball true|false]
[--quiet]
[--archive-areas ARCHIVE_AREA|"ARCHIVE_AREAS"]
[--parent-archive-areas ARCHIVE_AREA|"ARCHIVE_AREAS"]
[--security true|false]
[--source true|false]
[-s|--source-images iso|netboot|tar|hdd]
[--firmware-binary true|false]
[--firmware-chroot true|false]
[--swap-file-path PATH]
[--swap-file-size MB]
[--tasksel apt|aptitude|tasksel]
[--updates true|false]
[--backports true|false]
[--verbose]
[--loadlin true|false]
[--win32-loader true|false]
[--bootstrap-qemu-exclude PACKAGES]
[--bootstrap-qemu-static PATH]
[--bootstrap-qemu-arch ARCH]

I'm only seeing

Bug#849370: Re%3A aptitude%3A Aptitude crashes with SIGABRT on install command

2016-12-31 Thread Jonathan Seeley

I'm having the same issue, both with 0.8.3-1+b2 and 0.8.4-1.

Bug#849827: live-build fails to build amd64 target

2016-12-31 Thread Ozi Traveller

I didn't find a package named a2ps-amd64, but there is on named a2ps.

Also maybe try
--debian-installer daily
instead of
--debian-installer live

Just my 2cents

Ozi

On Sun, Jan 1, 2017 at 7:42 AM, Peter.Stein  wrote:

> Package: live-build
> Version: 1:20161216
>
> I configure with:
>
> lb config --debian-installer live -d stretch --archive-areas main contrib
> non-free upstream restricted --linux-packages `dpkg-query -f
> '${binary:Package}\n' -W`
>
> This configures the target for the same packages as those installed on the
> build host. It seems to correctly configure:
>
> P: Creating config tree for a debian/stretch/amd64 system
> P: Symlinking hooks...
>
> Now whenever a build (lb build) is attempted it fails in the same way.
> The build chugs along retrieving/verifying/unpacking packages. So far so
> good.
> But the build eventually fails with:
>
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> [2016-12-31 14:30:15] lb chroot_install-packages install
> P: Begin installing packages (install pass)...
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> *E: Unable to locate package a2ps-amd64*
> P: Begin unmounting filesystems...
> P: Saving caches...
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
>
> Note
>
> *E: Unable to locate package a2ps-amd64 *a2ps happens to be the first
> package in my package list. It doesn't matter which package is first - the
> build appends the suffix "-amd64" to create an illegal package name (no
> such package exists). As there are no options for either "lb config" or "lb
> build" which affect this behavior I'm concluding this is a bug. I've
> scoured all the documentation such as
> https://debian-live.alioth.debian.org/live-manual/stable/
> manual/html/live-manual.en.html
> and spent hours googling for answers or workarounds without success.
> Please advise.
>
> Build host:
> uname -a
> Linux nehalem 4.1.17 #2 SMP Sun Feb 14 22:42:14 CST 2016 x86_64 GNU/Linux
>

Bug#849800: [debhelper-devel] Bug#849800: debhelper: dh_systemd_start --no-start has no effect

2016-12-31 Thread Peter Colberg

Hi Niels,

Will you upload debhelper 10.2.3 soon? This would give sufficient time
for dependent packages to migrate to testing before the full freeze.

Thanks,
Peter

Bug#849826: Update: works correctly if month starts on Saturday

2016-12-31 Thread rdgreenlaw

I just ran 
   ccal --con=1 --f --appts=50 10 2016
and discovered that it works as expected if the month starts on Saturday.

Bug#849830: [src:digikam] Some sources are not included in your package

2016-12-31 Thread Bastien ROUCARIÈS

Package: src:digikam
Version: 4:5.3.0-1
user: lintian-ma...@debian.org
usertags: source-is-missing
severity: serious
X-Debbugs-CC: ftpmas...@debian.org

Hi,

your package includes some files that seem to lack sources
in preferred forms of modification (even if removed during clean target).
I have copied the lintian override that is bogus

# The following two files are removed in clean target, so not part of the 
build.
digikam source: source-is-missing core/data/about/js/bootstrap.min.js
digikam source: source-is-missing core/data/about/js/jquery.min.js


According to Debian Free Software Guidelines [1] (DFSG) #2:
 "The program must include source code, and must allow distribution 
  in source code as well as compiled form."

In some cases this could also constitute a license violation for some
copyleft licenses such as the GNU GPL. (While sometimes the licence
allows not to ship the source, the DFSG always mandates source code.)

In order to solve this problem, you could:
1.  add the source files to "debian/missing-sources" directory.
2. repack the origin tarball and add the missing source files to it.

Both way satisfy the requirement to ship all source code. The second option
might be preferable due to the following reasons [2]:
 - Upstream can do it too and you could even supply a patch to them, thus
   full filling our social contract [3], see particularly §2.
 - If source and non-source are in different locations, ftpmasters may
   miss the source and (needlessly) reject the package.
 - The source isn't duplicated in every .diff.gz/.debian.tar.* (though
   this only really matters for larger sources).

You could also ask debian...@lists.debian.org or #debian-qa for more
guidance.

[1] https://www.debian.org/social_contract.en.html#guidelines
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736873#8
[3] https://www.debian.org/social_contract


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

Bug#849829: [arc-gui-clients] Some sources are not included in your package

2016-12-31 Thread Bastien ROUCARIÈS

Package: arc-gui-clients
Version:  0.4.6-3 
user: lintian-ma...@debian.org
usertags: source-is-missing
severity: serious
X-Debbugs-CC: ftpmas...@debian.org

Hi,

your package includes some files that seem to lack sources
in preferred forms of modification:


 *   docs/users_guide/build/html/_static/jquery.js line length is 517 
characters (>512)
*docs/users_guide/build/html/_static/underscore.js line length is 530 
characters (>512)


According to Debian Free Software Guidelines [1] (DFSG) #2:
 "The program must include source code, and must allow distribution 
  in source code as well as compiled form."

In some cases this could also constitute a license violation for some
copyleft licenses such as the GNU GPL. (While sometimes the licence
allows not to ship the source, the DFSG always mandates source code.)

In order to solve this problem, you could:
1.  add the source files to "debian/missing-sources" directory.
2. repack the origin tarball and add the missing source files to it.

Both way satisfy the requirement to ship all source code. The second option
might be preferable due to the following reasons [2]:
 - Upstream can do it too and you could even supply a patch to them, thus
   full filling our social contract [3], see particularly §2.
 - If source and non-source are in different locations, ftpmasters may
   miss the source and (needlessly) reject the package.
 - The source isn't duplicated in every .diff.gz/.debian.tar.* (though
   this only really matters for larger sources).

You could also ask debian...@lists.debian.org or #debian-qa for more
guidance.

[1] https://www.debian.org/social_contract.en.html#guidelines
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736873#8
[3] https://www.debian.org/social_contract

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

Bug#849795: mgba: new upstream version available (0.5.1)

2016-12-31 Thread Sérgio Benjamim


Package updated: https://mentors.debian.net/package/mgba

cheers
sergio-br2


On 31/12/2016 15:48, Ryan Tandy wrote:

Control: retitle -1 mgba: new upstream version available (0.5.2)

On Sat, Dec 31, 2016 at 01:36:25PM -0200, Sérgio Benjamim wrote:

0.5.2 will release soon, isn't it better to wait that?


In fact, it looks like it has just been released!

https://github.com/mgba-emu/mgba/releases/tag/0.5.2

Bug#849827: live-build fails to build amd64 target

2016-12-31 Thread Peter.Stein


Package: live-build
Version: 1:20161216

I configure with:

lb config --debian-installer live -d stretch --archive-areas main 
contrib non-free upstream restricted --linux-packages `dpkg-query -f 
'${binary:Package}\n' -W`


This configures the target for the same packages as those installed on 
the build host. It seems to correctly configure:


P: Creating config tree for a debian/stretch/amd64 system
P: Symlinking hooks...

Now whenever a build (lb build) is attempted it fails in the same way.
The build chugs along retrieving/verifying/unpacking packages. So far so 
good.

But the build eventually fails with:

Reading package lists... Done
Building dependency tree
Reading state information... Done
[2016-12-31 14:30:15] lb chroot_install-packages install
P: Begin installing packages (install pass)...
Reading package lists... Done
Building dependency tree
Reading state information... Done
*E: Unable to locate package a2ps-amd64*
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists... Done
Building dependency tree
Reading state information... Done

Note *E: Unable to locate package a2ps-amd64

*a2ps happens to be the first package in my package list. It doesn't 
matter which package is first - the build appends the suffix "-amd64" to 
create an illegal package name (no such package exists). As there are no 
options for either "lb config" or "lb build" which affect this behavior 
I'm concluding this is a bug. I've scoured all the documentation such as

https://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html
and spent hours googling for answers or workarounds without success. 
Please advise.


Build host:
uname -a
Linux nehalem 4.1.17 #2 SMP Sun Feb 14 22:42:14 CST 2016 x86_64 GNU/Linux

Bug#849828: xpad: [text] changed to /text/

2016-12-31 Thread Mike Kupfer

Package: xpad
Version: 4.8.0-1
Severity: normal

Dear Maintainer,

I have a pad that contains some notes about a bug that I wanted to
file a report on.  After filing the bug report, I added the following
text to the pad:

[bug filed 31dec16]

The next time I started xpad, the text appeared as

/bug filed 31dec16/

Looking at the saved text in $HOME/.config/xpad/, I see that the text
was saved as

u+e000[u+e000/bug filed 31dec16u+e000]u+e000/

(where "u+e000" represents a single unicode character with the value
0xe000).

When I originally entered the text, the matching square brackets got
highlighted.  Perhaps the u+e000 and "/" have something to do with the
highlighting?

What I expect is that when I start xpad, it shows me the text that I
had typed in.  I don't care whether the brackets are highlighted.


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

Kernel: Linux 4.8.0-2-amd64 (SMP w/1 CPU core)
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 xpad depends on:
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-8
ii  libcairo-gobject2   1.14.8-1
ii  libcairo2   1.14.8-1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.2-2
ii  libgtk-3-0  3.22.5-1
ii  libgtksourceview-3.0-1  3.22.1-1
ii  libice6 2:1.0.9-1+b1
ii  libpango-1.0-0  1.40.3-3
ii  libpangocairo-1.0-0 1.40.3-3
ii  libsm6  2:1.2.2-1+b1

xpad recommends no packages.

xpad suggests no packages.

-- no debconf information

Bug#849825: openocd: fails to program Intel flash on MIPS target

2016-12-31 Thread Paul Fertser

Hello,

Thank you for the report.

Regarding the first issue, it was fixed in v0.9.0-94-g27a1125 , that's
included in 0.10.0-rc1. The second was fixed with v0.9.0-227-g144f96c
and it's present in the current release candidate as well.

Please feel free to contribute your board config file (along with an
approriate entry to tcl/tools/firmware-recovery.tcl) upstream, see
HACKING for the reference.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#847173: [Pkg-shadow-devel] Bug#847173: passwd: "usermod -l" don't change "suguid" and "subgid"

2016-12-31 Thread Serge E. Hallyn

in fairness the manpage does say:

   -l, --login NEW_LOGIN
   The name of the user will be changed from LOGIN to NEW_LOGIN. 
Nothing else is
   changed. In particular, the user's home directory or mail spool 
should probably
   be renamed manually to reflect the new login name.

so I'm not sure what the best action here is, but we should at least add
this to the manpage, if we don't change it.

Quoting Ф И (f_i_2...@list.ru):
> Subject: passwd: "usermod -l" don't change "suguid" and "subgid"
> Package: passwd
> Version: 1:4.2-3.1ubuntu5
> Command
> 
> usermod old_login --login new_login
> 
> does not change old_login
> in files "/etc/suguid" and "/etc/subgid".
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#849826: ccal: Appointments scheduled for first week of month does not display.

2016-12-31 Thread Roger Greenlaw

Package: ccal
Version: 4.0-3
Severity: normal

Dear Maintainer,


After installing ccal I created events in ~/.cal.dat including entries for
first and third Thursday of every month.

I created a calendar data file ~/.cal.dat and added the following lines to it.

-999 -9 00 15 First Thursday of every month
-999 -9 00 35 Third Thursday of every month
-999 -9 00 -7 Weekly reminder on Saturday

Then I executed the command
roger@RDGdebian880:~$ ccal --noc

Which displayed the following:

 December 2016   1: First Thursday of every month
 Su Mo Tu We Th Fr Sa   10: Weekly reminder on Saturday
  1  2  3   15: Third Thursday of every month
  4  5  6  7  8  9 10   17: Weekly reminder on Saturday
 11 12 13 14 15 16 17   24: Weekly reminder on Saturday
 18 19 20 21 22 23 24  *31: Weekly reminder on Saturday
 25 26 27 28 29 30<31>

I expected to see an entry
3: Weekly reminder on Saturday
which did not display.

To check the results I tried

roger@RDGdebian880:~$ ccal --noc --con=1

Which resulted in

 December 2016   1: First Thursday of every month
 Su Mo Tu We Th Fr Sa   10: Weekly reminder on Saturday
  1  2  3   15: Third Thursday of every month
  4  5  6  7  8  9 10   17: Weekly reminder on Saturday
 11 12 13 14 15 16 17   24: Weekly reminder on Saturday
 18 19 20 21 22 23 24  *31: Weekly reminder on Saturday
 25 26 27 28 29 30<31>

 January 2017   14: Weekly reminder on Saturday
 Su Mo Tu We Th Fr Sa   19: Third Thursday of every month
  1  2  3  4  5  6  7   21: Weekly reminder on Saturday
  8  9 10 11 12 13 14   28: Weekly reminder on Saturday
 15 16 17 18 19 20 21
 22 23 24 25 26 27 28
 29 30 31

Here I noticed that the December entry
 3: Weekly reminder on Saturday
 is still missing, also the following are missing in January
 5: First Thursday of every month
 7: Weekly reminder on Saturday

To confirm that I'm not trying to display more data than the program expects, I
added the --f flag
December displayed only the *31: entry (as expected) and January displayed
exactly the same as without the --f flag.

I was hoping that ccal data would be easier to maintain and more useful than
other options for quickly displaying reminders, but will not be using it unless
the bug which prevents the first week data from displaying correctly is fixed.

It does look like it could be useful, and like it's handling of birthdays and
anniversaries, but floating appointments need to work correctly for it to be
useful to me.



-- System Information:
Debian Release: 8.6
  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=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 ccal depends on:
ii  dpkg   1.17.27
ii  libc6  2.19-18+deb8u6

ccal recommends no packages.

ccal suggests no packages.

-- no debconf information

Bug#849705: unrtf: Stack buffer overflow

2016-12-31 Thread Willi Mann

Hi,

> Not sure yet if that would warrant a DSA, possibly it could be updated
> via the upcoming point release as well.

I pushed a jessie branch to the git repository with the patch from
upstream (some hunks had to be ignored). I also uploaded a patched
version to unstable.

https://anonscm.debian.org/cgit/collab-maint/unrtf.git/log/?h=jessie

Let me know how I should proceed for jessie.

Bye
Willi

Bug#848610: jessie-pu: package pgpdump/0.28-1+deb8u1

Control: tags -1 + pending

On Tue, 2016-12-20 at 22:00 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2016-12-18 at 23:42 +0100, Christoph Biedl wrote:
> > CVE-2016-4021[1] hasn't been handled in jessie yet. The security team
> > suggested to use an upcoming point release for this, this got ACKed
> > by the stable security team. The pgpdump maintainer Jose Luis Rivas
> > (CC'd) has agreed to this procedure.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#848908: jessie-pu: package shutter/0.92-0.1+deb8u1

Control: tags -1 + pending

On Tue, 2016-12-20 at 21:58 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2016-12-20 at 19:12 +0100, Christoph Biedl wrote:
> > CVE-2015-0854[1] hasn't been handled in jessie yet. The security team
> > ACKed to use an upcoming point release for this. The shutter maintainer
> > Ryan Niebur is in Cc:.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#849175: jessie-pu: package ganeti-instance-debootstrap/0.14-2

Control: tags -1 + pending

On Sat, 2016-12-24 at 20:26 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2016-12-23 at 11:00 +0200, Apollon Oikonomopoulos wrote:
> > I would like to update ganeti-instance-debootstrap in Jessie to fix 
> > #834404. In particular, the proposed update includes an upstream commit 
> > that replaces all instances of `losetup -s' with `losetup --show', as 
> > the former is no longer supported since util-linux 2.21.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#848942: jessie-pu: package most/5.0.0a-2.3

Control: tags -1 + pending

On Sat, 2016-12-24 at 20:34 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2016-12-20 at 17:52 -0800, Benjamin Mako Hill wrote:
> > There was a recent non-critical CVE issued for most:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848132
> > https://security-tracker.debian.org/tracker/CVE-2016-1253
> > 
> > The fix (a debdiff is attached) is this on-liner that changes single quotes 
> > to
> > double quotes.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#849578: task-xfce-desktop: Why you use the vlc player in the task-xfce-desktop meta package?

2016-12-31 Thread Jürgen Göricke

Dear Maintainer,

see all the dependencies from package vlc in Debian Sid.

https://packages.debian.org/sid/vlc

http://paste.debian.net/905778

Vlc needs Qt dependencies by default.

What is the problem with parole to add the task-xfce-desktop respectively
tasksel meta packages?

Why you wan't change the packages? I can't understand it.

Parole is the default media player from xfce project and not so bloated
as the vlc player.

Regards


Jürgen

_
Free-Mail Postfach (bis zu 10 GB E-Mail-Speicher)
SMS, MMS, Fax und vieles mehr - http://www.smart-mail.de

Bug#849800: [debhelper-devel] Bug#849800: debhelper: dh_systemd_start --no-start has no effect

2016-12-31 Thread Peter Colberg

Control: forcemerge 805878 849800

Hi Niels,

On Sat, Dec 31, 2016 at 09:34:00AM +, Niels Thykier wrote:
> From a quick glance, this looks like a duplicate of #805878. Agreed?

Thanks, that’s the bug.

Peter

Bug#849725: jessie-pu cairo/1.14.0-2.1+deb8u2

2016-12-31 Thread Salvatore Bonaccorso

Hi Adam,

On Sat, Dec 31, 2016 at 04:58:46PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2016-12-30 at 07:52 +0100, Salvatore Bonaccorso wrote:
> > src:cairo in jessie is affected by CVE-2016-9082 which would not
> > warrant a DSA. A while back in october the issue was already fixed in
> > unstable, cf. #842289. I would like to propose the attached debdiff
> > for the upcoming point release.
> 
> Please go ahead.

Thanks uploaded.

> > Note: in the 1.14.0-2.1 -> 1.14.0-2.1+deb8u1 the binary package
> > binary-cairo-perf-utils got one more binary added
> > (/usr/bin/cairo-perf-graph-files). Whit this update that goes back to
> > the 1.14.0-2.1 situation.
> 
> Do we know why that happened?

I do not know. Cc'ing Moritz. But I guess the build environment might
have had an addtional package installed. Because it is not the case
for the binary packages built by the buildd's, e.g. i386:

$ debdiff cairo-perf-utils_1.14.0-2.1_i386.deb 
cairo-perf-utils_1.14.0-2.1+deb8u1_i386.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Version: [-1.14.0-2.1-] {+1.14.0-2.1+deb8u1+}

Regards,
Salvatore

Bug#815840: Pending fixes for bugs in the libfcgi-perl package

2016-12-31 Thread pkg-perl-maintainers

tag 815840 + pending
thanks

Some bugs in the libfcgi-perl package are closed in revision
c7f207595fbba0f8bc45c569e07266cdf82f1fc9 in branch '  jessie' by
Salvatore Bonaccorso

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libfcgi-perl.git/commit/?id=c7f2075

Commit message:

CVE-2012-6687: numerous connections cause segfault DoS

Closes: #815840

Bug#849438: jessie-pu: package libfcgi-perl/0.77-1+deb8u1

2016-12-31 Thread Salvatore Bonaccorso

Hi Adam,

On Sat, Dec 31, 2016 at 05:11:25PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2016-12-27 at 08:17 +0100, Salvatore Bonaccorso wrote:
> > Moritz Mühlenhoff suggested to fix CVE-2012-6687 for libfcgi-perl via
> > a point release (since it does not warrant a DSA). Attached is a
> > debdiff for libfcgi-perl as in stable.
> > 
> > Could you consider to have it included in the upcoming point release?
> 
> Please go ahead.

Thank you, uploaded.

Regards,
Salvatore

Bug#849825: openocd: fails to program Intel flash on MIPS target

2016-12-31 Thread Pigeon

Package: openocd
Version: 0.9.0
Tags: patch

openocd fails to program the Intel TE28F160 flash memory attached to
the AR7 (MIPS core) in a Solwise SAR600E router (the AR7 is also used
in many other routers) with the error "Unknown architecture". There
are two reasons for the failure.

The first reason is that the architecture problem only prevents block
writing. It does not prevent word-at-a-time writing (granted this is
horrendously slow, but it is a lot better than nothing). The openocd
code does in fact contain a fallback to word-at-a-time writing for the
case that block writing is not possible, but with a MIPS target it
fails to trigger the fallback.

The second reason is that the code for word-at-a-time writing doesn't
actually work as supplied, because part of the logic is scrambled
(although that same logic appears correct and unscrambled in several
other places, including just a few lines further on from the error).

Attached is a patch to (a) ensure that the fallback does get
triggered, and (b) unscramble the scrambled bit of code.

-- 
Pigeon

Be kind to pigeons   - -   Pigeon's Nest: http://pigeonsnest.co.uk/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x21C61F7F
diff -Naur openocd-0.9.0.orig/src/flash/nor/cfi.c openocd-0.9.0/src/flash/nor/cfi.c
--- openocd-0.9.0.orig/src/flash/nor/cfi.c	2014-03-29 17:55:12.0 +0100
+++ openocd-0.9.0/src/flash/nor/cfi.c	2016-12-31 18:48:48.884400377 +0100
@@ -1212,8 +1212,12 @@
 		arm_algo.core_mode = ARM_MODE_SVC;
 		arm_algo.core_state = ARM_STATE_ARM;
 	} else {
-		LOG_ERROR("Unknown architecture");
-		return ERROR_FAIL;
+		if (strncmp(target_type_name(target), "mips_m4k", 8) == 0) {
+			return (ERROR_TARGET_RESOURCE_NOT_AVAILABLE);
+		} else {
+			LOG_ERROR("Unknown architecture");
+			return ERROR_FAIL;
+		}
 	}
 
 	cfi_intel_clear_status_register(bank);
@@ -1989,7 +1993,9 @@
 
 	uint8_t status;
 	retval = cfi_intel_wait_status_busy(bank, cfi_info->word_write_timeout, );
-	if (retval != 0x80) {
+	if (retval != ERROR_OK)
+		return retval;
+	if (status != 0x80) {
 		retval = cfi_send_command(bank, 0xff, flash_address(bank, 0, 0x0));
 		if (retval != ERROR_OK)
 			return retval;


signature.asc
Description: Digital signature

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

2016-12-31 Thread Harlan Lieberman-Berg

"W. Martin Borgert"  writes:
> Then why not make an additional binary package from the same
> source package? This way ansible and its documentation would
> not get out of sync.

Unfortunately, we don't build ansible off of the git repository, but
rather from the released tarballs.  (The version in upstream's git
requires much more extensive dfsg cleanup, and would until recently have
required the bundling of multiple upstream repositories together.)

It's been a while since we made the decision not to pull from upstream's
git; Toni, I'd be happy to work with you on seeing if it's doable now.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#849696: libogre-1.9.0v5: Ogre games abort on startup with “basic_string::_M_construct null not valid” / freeimage API issues

Hi,

2016-12-30 02:33 James Cowgill:

Control: severity -1 grave

Hi,

This is RC because nothing using ogre will start anymore.

On 29/12/16 21:52, Thibaut Girka wrote:

Package: libogre-1.9.0v5
Version: 1.9.0+dfsg1-7+b2
Severity: important

Any Ogre game/application (for instance, funguloids, available in Debian)
crashes with the following output:

Creating resource group General
Creating resource group Internal
Creating resource group Autodetect
SceneManagerFactory for type 'DefaultSceneManager' registered.
Registering ResourceManager for type Material
Registering ResourceManager for type Mesh
Registering ResourceManager for type Skeleton
MovableObjectFactory for type 'ParticleSystem' registered.
ArchiveFactory for archive type FileSystem registered.
ArchiveFactory for archive type Zip registered.
ArchiveFactory for archive type EmbeddedZip registered.
DDS codec registering
FreeImage version: 3.17.0
This program uses FreeImage, a free, open source image library supporting all
common bitmap formats. See http://freeimage.sourceforge.net for details
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Abandon

This started happening since upgrading libfreeimage3, so this might be a bug in
it rather than in Ogre itself, but I haven't investigated any further yet.

This appears to be a regression in the Debian patch applied in
libfreeimage3 3.17.0+ds1-4.

Ogre contains this (OgreMain/src/OgreFreeImageCodec.cpp:98):

for (int i = 0; i < FreeImage_GetFIFCount(); ++i)
{
// Skip DDS codec since FreeImage does not have the option
// to keep DXT data compressed, we'll use our own codec
if ((FREE_IMAGE_FORMAT)i == FIF_DDS)
continue;

String exts(FreeImage_GetFIFExtensionList((FREE_IMAGE_FORMAT)i));

[loop body continues]
[String is typedefed to std::string]

This code assumes that FreeImage_GetFIFExtensionList will never return
NULL for values of i between 0 and FreeImage_GetFIFCount(). However in
the most recent Debian version of freeimage,
FreeImage_GetFIFExtensionList(27 / FIF_FAXG3) does return NULL.

It is unclear to me who is wrong here. The documentation does not
suggest anything about when FreeImage_GetFIFExtensionList can fail,
although the examples always check FreeImage_FIFSupportsReading before
calling it. Can any freeimage maintainer suggest the best way to fix this?

Thanks for the analysis.

The comment on the patch seems to add some light as to the cause of this
breakage:

https://anonscm.debian.org/cgit/debian-science/packages/freeimage.git/commit/?id=a67fe8c111d0de919b7a6710d4dd5efe05fbf380

++//allows adding a NULL node in order to not mess up plugin
++//numbering when some are disabled. Otherwise there will be a
++//discrepancy between FREE_IMAGE_FORMAT enumerator values and the
++//actual format.
++m_plugin_map[(const int)m_plugin_map.size()] = 0;

If freeimage plans to ship with this change and not revert it somehow,
the OGRE plugin for freeimage needs to check for the possibility of
having null nodes in this structure.

Cheers.
--
Manuel A. Fernandez Montecelo

Bug#849795: mgba: new upstream version available (0.5.1)

2016-12-31 Thread Ryan Tandy


Control: retitle -1 mgba: new upstream version available (0.5.2)

On Sat, Dec 31, 2016 at 01:36:25PM -0200, Sérgio Benjamim wrote:

0.5.2 will release soon, isn't it better to wait that?


In fact, it looks like it has just been released!

https://github.com/mgba-emu/mgba/releases/tag/0.5.2

Bug#846352: jessie-pu: package nvidia-graphics-drivers/340.98-1

Control: tags -1 + confirmed

On Wed, 2016-11-30 at 15:53 +0100, Andreas Beckmann wrote:
> again we have some CVEs in the proprietary nvidia driver:
> CVE-2016-7382, CVE-2016-7389: #846331
> 
> This requires updatiung to a new upstream release. Such updates always
> happened via -pu instead of -security.
> 
> Since keeping the nvidia-graphics-drivers,
> nvidia-graphics-drivers-legacy-340xx and
> nvidia-graphics-drivers-legacy-304xx packages in sync is quite some bit
> of work (and therefore the packaging is quite generic with a lot of
> substitutions at build time), this jessie update also contains quite a
> lot of small fixes backported from unstable as well as some bigger
> changes:

Please go ahead; apologies for the delay.

Regards,

Adam

Bug#848829: jessie-pu: package nvidia-graphics-drivers-legacy-304xx/304.134-0~deb8u1

Control: tags -1 + confirmed

On Tue, 2016-12-20 at 03:09 +0100, Andreas Beckmann wrote:
> for fixing CVE-2016-8826, CVE-2016-7382, CVE-2016-7389 in
> nvidia-graphics-drivers-legacy-304xx we need to update to a new upstream
> version.
> 
> The packaging contains further changes to
> * switch from our manually maintained conftest.h (that had to be updated
>   for each new upstream release) to using upstream's conftest.sh script
>   instead. This required backporting several build system fixes for the
>   kernel module.
> * switch the source layout to have one .orig-$ARCH.tar.gz per
>   architecture
> * backport minor fixes and description updates from sid

Please go ahead.

Regards,

Adam

Bug#849761: aptitude: new russian translation

Hi,

2016-12-31 17:43 GMT+01:00 Lev Lamberov :
> Hi Manuel and Michael,
>
> On Sat, 31 Dec 2016 17:23:01 +0100 "Manuel A. Fernandez Montecelo" wrote:
>> 2016-12-30 19:22 Ulyanich Michael:
>> >It is new russian translation.
>> >A lot of changes concern the punctuation and amount of spaces. :(
>>
>> Thanks for the contribution.
>
> Yes, Michael, thanks for your contribution!
>
> Next time could you contact Russian l10n team in the first place
> (debian-l10n-russian@l.d.o)? It is quite possible that someone already
> worked on updating that translation. Moreover, in any case any
> translation needs proofreading. Quick glance showed some minor
> shortcomings of your translation.
>
>> Did you get in contact with the russian translation team, or are part of
>> it? Copying Lev, which I think that it's the last person who updated
>> the translation.
>
> Manuel, I'll proofread the translation next week or something and will
> send it through the bug report.

I commited it already (thanks again, Ulyanich), since at first glance
it was adding new strings and fixing format for things that changed...
but I'll gladly accept revised versions... and there shouldn't be many
changes before the freeze/release, so now it's a good time for this.



-- 
Manuel A. Fernandez Montecelo

Bug#849438: jessie-pu: package libfcgi-perl/0.77-1+deb8u1

Control: tags -1 + confirmed

On Tue, 2016-12-27 at 08:17 +0100, Salvatore Bonaccorso wrote:
> Moritz Mühlenhoff suggested to fix CVE-2012-6687 for libfcgi-perl via
> a point release (since it does not warrant a DSA). Attached is a
> debdiff for libfcgi-perl as in stable.
> 
> Could you consider to have it included in the upcoming point release?

Please go ahead.

Regards,

Adam

Bug#849823: xfdesktop4: can't click to select a folder with background images

2016-12-31 Thread Mike Kupfer

Package: xfdesktop4
Version: 4.12.3-3
Severity: normal

Dear Maintainer,

Suppose I want to use a background image that is in a different folder
than my current background image.  I bring up the Desktop Settings
window (right-click on the desktop), click on the Folder
chooser in the Background tab, then click "other...".  This brings up
a chooser, with a pathbar at the top.

The buttons in the pathbar work.  For example, if my current
background is in /usr/share/backgrounds/xfce, I can click on
"backgrounds" in the pathbar, and the chooser shows other folders in
/usr/share/backgrounds.  The problem is that these other folders are
grayed out; clicking on them has no effect.

Workaround: click on the icon in the upper left of the chooser.  This
creates a Location text field in the chooser window.  Type the path of
the desired folder there.

This might be the same as #822761, but I'm not sure, so I'm filing
this as a new bug.  Part of why I'm not sure is that I'm confused by
the title of the chooser.  It says "Select a File".  But is it really
used to select an image file, or is it just supposed to be used to
select a folder?

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/1 CPU core)
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 xfdesktop4 depends on:
ii  exo-utils0.10.7-1
ii  libc62.24-8
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.14-1
ii  libdbus-glib-1-2 0.108-1
ii  libexo-1-0   0.10.7-1
ii  libgarcon-1-00.4.0-2
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-1
ii  libnotify4   0.7.7-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libthunarx-2-0   1.6.10-4
ii  libwnck222.30.7-5.1
ii  libx11-6 2:1.6.4-2
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1
ii  xfdesktop4-data  4.12.3-3

Versions of packages xfdesktop4 recommends:
ii  dbus-x11 [dbus-session-bus]  1.10.14-1
ii  librsvg2-common  2.40.16-1
ii  tumbler  0.1.31-2+b3
ii  xdg-user-dirs0.15-2

Versions of packages xfdesktop4 suggests:
ii  menu  2.1.47

-- no debconf information

Bug#834073: [Aptitude-devel] Bug#834073: aptitude search gives less results than apt-cache search


Control: severity -1 wishlist
Control: tags -1 + wontfix


(It's unlikely that we change this in aptitude or add new config options
to that effect, so setting the bug priority and tags accordingly... but
read on)


Hi,

2016-08-13 15:10 shirish शिरीष:

in-line :-

On 11/08/2016, Axel Beckert  wrote:

Hi shirish,


Hi Axel,




So unless you want to change aptitude's default, I don't see any bug
here and would like to close this bug report again.


Could you tell/share/remind why does aptitude do it differently than
apt-cache or axi-cache .  I do find using apt-cache or axi-cache
search to be better in this aspect rather than plain aptitude :(

I have always been telling friends that aptitude is better than other
package managers, more powerful and yet pretty convenient.

Is there some reason that we do not use the description wildcard when
searching for packages. ? And I know this will be a big change and
probably not welcomed by most/many sys-admins so not saying that.

If I were to change the behavior in my aptitude installation, where or
how I could do the change so the above behavior that you shared could
be simulated.

I forgot to share that I had seen both man apt.conf and the examples
given at /usr/share/doc/examples and specifically the
configure-index.gz but didn't become any wiser.

I would like to make changes and keep it at /etc/apt/apt.conf so when
the searches happen, it happens both for name as well as description .
Even doing it ~/.aptitude is ok but didn't see any possibilities in
either the aptitude or apt-conf man page.

Look forward to knowing more.


As Axel said, a more-or-less equivalent in bash would be:

 aptitude search {~d,~n}marathi

It's easy to add a function or an alias in bash to get the results:

 $ function aptitude_enhanced_search() { aptitude search {~d,~n}$1; }

 $ aptitude_enhanced_search marathi
 p   aspell-mr  - Marathi (mr) dictionary for GNU aspell
 p   festival-mr- festival text to speech synthesizer for Marathi 
language
 p   festvox-mr-nsk - Marathi male speaker for festival
 p   firefox-esr-l10n-mr- Marathi language package for Firefox ESR
 p   firefox-l10n-mr- Marathi language package for Firefox
 p   fonts-deva-extra   - Free fonts for Devanagari script
 i   fonts-gargi- OpenType Devanagari font
 p   fonts-lohit-deva   - Lohit TrueType font for Devanagari script
 p   fonts-nakula   - Free Unicode compliant Devanagari font
 p   fonts-sahadeva - Free Unicode compliant Devanagari font
 p   fonts-samyak-deva  - Samyak TrueType font for Devanagari script
 p   fonts-sarai- truetype font for devanagari script
 p   gcompris-sound-mr  - Indian Marathi sound files for GCompris
 p   hyphen-mr  - Marathi hyphenation patterns for LibreOffice
 p   iceweasel-l10n-mr  - Marathi language package for Iceweasel - 
Transitional package
 p   iok- Indic Onscreen Keyboard
 p   iok:i386   - Indic Onscreen Keyboard
 p   kde-l10n-mr- Marathi (mr) localization files for KDE
 p   libreoffice-l10n-mr- office productivity suite -- Marathi language 
package
 p   task-marathi   - Marathi environment
 p   task-marathi-desktop   - Marathi desktop
 p   tesseract-ocr-mar  - tesseract-ocr language files for Marathi


--
Manuel A. Fernandez Montecelo

Bug#849467: jessie-pu: package hplip/3.14.6-1+deb8u1

Control: tags -1 + confirmed

On Tue, 2016-12-27 at 14:18 +0100, Didier 'OdyX' Raboud wrote:
> I'd like to get CVE-2015-0839 fixed in jessie, it's a no-DSA issue, and
> security team members suggested to get it fixed through stable updates.
> 
> This bug is a simple 'fetching gpg key from keyservers with a short
> keyid' problem, and upstream's fix is to use the full fingerprint.

Please go ahead.

Regards,

Adam

Bug#849538: jessie-pu: package ceph/0.80.7-2+deb8u2

Control: tags -1 + confirmed

On Wed, 2016-12-28 at 11:38 +0100, Gaudenz Steinlin wrote:
> I would like to update ceph with the next stable point release to fix
> the 4 security issues listed below. These are all minor issues which did
> not warrant a DSA on their own, but are still worth fixing.
> 
> https://security-tracker.debian.org/tracker/CVE-2016-9579
> https://security-tracker.debian.org/tracker/CVE-2016-5009
> https://security-tracker.debian.org/tracker/CVE-2016-7031
> https://security-tracker.debian.org/tracker/CVE-2016-8626

Please go ahead.

Regards,

Adam

Bug#848184: Processed: reassign 848184 to bugs.debian.org

2016-12-31 Thread Holger Levsen

Control: tag -1 - moreinfo
thanks

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#848184: Processed: reassign 848184 to bugs.debian.org

2016-12-31 Thread Holger Levsen

On Sat, Dec 31, 2016 at 01:52:42PM +0100, Mattia Rizzolo wrote:
> >   "Issues with the jenkins.debian.org service."
> +1

+1

> > > the e-mail address that the bugs should be sent to
> qa-jenkins-...@lists.alioth.debian.org

+1

& thank you all!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#849698: jessie-pu: package python-crypto/2.6.1-5+deb8u1

Control: tags -1 + moreinfo

On Thu, 2016-12-29 at 23:15 +0100, Sebastian Ramacher wrote:
> I'd like to fix CVE-2013-7459 (#849495) in jessie via the next point release.
> The issue was marked as no-dsa.
> 
> The proposed debdiff is attached. The same patch was applied to the package in
> unstable.

+  * Throw exception when IV is used with ECB or CTR (CVE-2013-7459)

Do we know if any packages currently in Debian misuse the functions in
that way? (I realise that any that do are broken, but I'd prefer to find
that out /before/ releasing an point release that makes them explode if
possible.)

Regards,

Adam

Bug#832150: xmacro adoption

2016-12-31 Thread Eduard Bloch

On Wed, 7 Dec 2016 21:05:24 +0100 Vincent Carluer  wrote:
> Hello,
> 
> I would be glad to adopt this package if it is OK with you.
> I am a senior dev newbie with Debian dev/packaging but motivated :D
> 
> I've talked about the idea to adopt this package to debian-mentors and it
> seems they agree it could be a good idea.
> 
> They said to me there is a RC bug (Fails To Build From Source) I should
> start to fix and than the stretch freeze is close.
> 
> So do you agree than I adopt xmacro?
> Can you help me a little to start?
> What is the next step?
> Do you have any other advice?

Hello,

no special advice. You can take it if you want but I really hope that
you actually use it and don't take it as a sandbox for practicing.

You can find the diff attached. This is something I wanted to upload
today (in the hope that it will make it before freeze) since I forgot
about your mail (and I cannot find it anymore in my mailbox, sorry).

It's not perfect way of solving this in terms of best packaging
practices (inline patch instead of patch series, installed as
auto-generated single-debian-patch). But I wouldn't mess with patch
series maintenance for such trivial changes.

Regards,
Eduard.
diff --git a/debian/changelog b/debian/changelog
index a400044..c19da21 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+xmacro (0.3pre-2911-7) unstable; urgency=medium
+
+  * Fixing build failure with GCC-6 via rearanging the header order
+(closes: #831195)
+  * Align DH compat level and build dependency, require 9+
+
+ -- Eduard Bloch   Fri, 22 Jul 2016 22:26:14 +0200
+
 xmacro (0.3pre-2911-6) unstable; urgency=low
 
   * Proper build with original tarball
diff --git a/debian/compat b/debian/compat
index f599e28..ec63514 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-10
+9
diff --git a/debian/control b/debian/control
index 9263595..3945804 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: xmacro
 Section: utils
 Priority: optional
 Maintainer: Eduard Bloch 
-Build-Depends: debhelper (>> 5.0), libx11-dev, libxtst-dev
+Build-Depends: debhelper (>> 9), libx11-dev, libxtst-dev
 Standards-Version: 3.9.2
 
 Package: xmacro
diff --git a/debian/rules b/debian/rules
index 84df31e..cd9d3c8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,87 +1,16 @@
 #!/usr/bin/make -f
-# Sample debian/rules that uses debhelper.
-# GNU copyright 1997 to 1999 by Joey Hess.
 
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+-include /usr/share/quilt/quilt.make
 
-ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
-   CFLAGS += -g
-endif
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   INSTALL_PROGRAM += -s
-endif
+%:
+   dh $@ --parallel --with quilt
 
-CXXFLAGS=-g -O2
-export CXXFLAGS
-
-configure: configure-stamp
-configure-stamp:
-   dh_testdir
-   # Add here commands to configure the package.
-
-   touch configure-stamp
-
-
-build: build-stamp
-
-build-stamp: configure-stamp 
-   dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE)
-   #/usr/bin/docbook-to-man debian/xmacro-0.3pre.sgml > xmacro-0.3pre.1
-
-   touch build-stamp
-
-clean:
+override_dh_install:
dh_testdir
dh_testroot
-   rm -f build-stamp configure-stamp
-
-   # Add here commands to clean up after the build process.
-   $(MAKE) clean
-
-   dh_clean
-
-install: build
-   dh_testdir
-   dh_testroot
-   dh_clean -k
+   dh_prep  
dh_installdirs
-
-   # Add here commands to install the package into debian/xmacro-0.3pre.
-   install -Dpv xmacroplay-keys xmacroplay xmacrorec xmacrorec2 
$(CURDIR)/debian/xmacro/usr/bin
-
-build-arch: build
-
-build-indep: build
-
-# Build architecture-independent files here.
-binary-indep: build install
-# We have nothing to do by default.
-
-# Build architecture-dependent files here.
-binary-arch: build install
-   dh_testdir
-   dh_testroot
-   dh_installdocs
-   dh_installexamples
-   dh_installmenu
-   dh_installcron
-   dh_installman
-   dh_installinfo
-   dh_installchangelogs 
-   dh_link
-   dh_strip
-   dh_compress
-   dh_fixperms
-   chmod -x $(CURDIR)/debian/xmacro/usr/share/doc/xmacro/examples/*
-   dh_installdeb
-   dh_shlibdeps
-   dh_gencontrol
-   dh_md5sums
-   dh_builddeb -- -Zxz
-
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+   install -Dpv xmacroplay-keys xmacroplay xmacrorec xmacrorec2 
debian/xmacro/usr/bin
diff --git a/debian/source/format b/debian/source/format
new file mode 100644
index 000..163aaf8
--- /dev/null
+++ b/debian/source/format
@@ -0,0 +1 @@
+3.0 (quilt)
diff --git a/debian/source/options

Bug#837366: aptitude: #839792 (Segfaults when typing (into aptitude) during or maybe shortly before package download) and #837366 (Crash when typing while saying "Updating ... and quitting") might be


Control: tags -1 + moreinfo


Hi,

2016-10-10 23:13 Axel Beckert:

Hi,

JFTR: in case this is actually an issue inside cwidget or in the way
cwidget is used by aptitude, the two bug reports 839792 (Segfaults
when typing (into aptitude) during or maybe shortly before package
download) and #837366 (Crash when typing while saying "Updating ...
and quitting") might be the same issue or at least related.


With an up-to-date unstable and 0.8.4-1, I cannot reproduce this
(neither of them).  Can you still reproduce it?


It seems to me that these recurrent problems involving cwidget, events,
typing and threads have something to do either with the specific locale
settings (mine are the ones below) or temporary ABI incompatibilities,
perhaps due to binNMU recompilations and different order of compilation
of boost, sigc++, cwidget and aptitude.  Something similar to what
happened with the Big GCC5 C++11 ABI break, just at a smaller scale.


# env | grep LANG
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en


Another idea would be a difference between using the minibuffer and not
using it.


Cheers.
--
Manuel A. Fernandez Montecelo

Bug#849725: jessie-pu cairo/1.14.0-2.1+deb8u2