Bug#908037: Patch available

[Birger Schacht]

Control: severity -1 important

hi,
there is a patch for that behaviour that will be released with the next
upload, see
https://salsa.debian.org/bisco-guest/usbguard/commit/4b36e19d49def30112fc07717e40e6251fbe1c22

i'm setting the severity back to important, because the package is not
completely unusable to everone.

Bug#909643: installation-reports: doing a dist-upgrade from debian7 to debian8 ended with a non bootable system

[Stephane Tranchemer]

Hello,

Thanks for your concern.


On 27 September 2018 at 10:32, Ben Hutchings  wrote:

>
> What is the kernel command line?  (Run "cat /proc/cmdline" to show it.)
>

With the bootable kernel 3.2

# uname -a
Linux ahs-clone 3.2.0-6-686-pae #1 SMP Debian 3.2.102-1 i686 GNU/Linux
# cat /etc/debian_version
8.11
# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.2.0-6-686-pae root=/dev/mapper/vg00-root ro

In a non-bootable state in initramfs prompt with kernel 3.16

BOOT_IMAGE=/vmlinuz-3.16.0-6-686-pae root=/dev/mapper/vg00-root ro


>
> Please also send a copy of the /etc/initramfs-tools/initramfs.conf
> file.
>

Here is the file in attachment.

Thank you.
-- 
-
Tranchemer Stephane
System dept.
Asahinet, inc.
Kabukiza tower 21st Fl.
4-12-15 Ginza
Chuo-ku, Tokyo
104-0061 Japan


initramfs.conf
Description: Binary data

Bug#909705: llvm-toolchain-7: please backport D51749 for a rustc aarch64 test failure

[Ximin Luo]

Source: llvm-toolchain-7
Version: 1:7-2
Severity: normal
Tags: patch upstream

Dear Maintainer,

Please apply the attached patch, it fixes a test failure in rustc.

see https://github.com/rust-lang/rust/pull/54136 for details.

X

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 1c34cd56bc59b1540e0a814d2f80ade77daa9248 Mon Sep 17 00:00:00 2001
From: Josh Stone 
Date: Tue, 11 Sep 2018 17:52:01 +
Subject: [PATCH] [GlobalISel] Lower dbg.declare into indirect DBG_VALUE

Summary:
D31439 changed the semantics of dbg.declare to take the address of a
variable as the first argument, making it indirect.  It specifically
updated FastISel for this change here:

https://reviews.llvm.org/D31439#change-WVArzi177jPl

GlobalISel needs to follow suit, or else it will be missing a level of
indirection in the generated debuginfo.  This problem was seen in a Rust
debuginfo test on aarch64, since GlobalISel is used at -O0 for aarch64.

https://github.com/rust-lang/rust/issues/49807
https://bugzilla.redhat.com/show_bug.cgi?id=1611597
https://bugzilla.redhat.com/show_bug.cgi?id=1625768

Reviewers: dblaikie, aprantl, t.p.northover, javed.absar, rnk

Reviewed By: rnk

Subscribers: #debug-info, rovka, kristof.beyls, JDevlieghere, llvm-commits, 
tstellar

Differential Revision: https://reviews.llvm.org/D51749

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@341969 
91177308-0d34-0410-b5e6-96231b3b80d8
---
 lib/CodeGen/GlobalISel/IRTranslator.cpp   |  9 ++-
 test/CodeGen/AArch64/GlobalISel/debug-cpp.ll  | 67 +++
 .../CodeGen/AArch64/GlobalISel/debug-insts.ll |  4 +-
 3 files changed, 74 insertions(+), 6 deletions(-)
 create mode 100644 test/CodeGen/AArch64/GlobalISel/debug-cpp.ll

diff --git a/lib/CodeGen/GlobalISel/IRTranslator.cpp 
b/lib/CodeGen/GlobalISel/IRTranslator.cpp
index 974629bc4f4..f7b905c9db4 100644
--- a/lib/CodeGen/GlobalISel/IRTranslator.cpp
+++ b/lib/CodeGen/GlobalISel/IRTranslator.cpp
@@ -758,9 +758,12 @@ bool IRTranslator::translateKnownIntrinsic(const CallInst 
, Intrinsic::ID ID,
   // instructions (in fact, they get ignored if they *do* exist).
   MF->setVariableDbgInfo(DI.getVariable(), DI.getExpression(),
  getOrCreateFrameIndex(*AI), DI.getDebugLoc());
-} else
-  MIRBuilder.buildDirectDbgValue(getOrCreateVReg(*Address),
- DI.getVariable(), DI.getExpression());
+} else {
+  // A dbg.declare describes the address of a source variable, so lower it
+  // into an indirect DBG_VALUE.
+  MIRBuilder.buildIndirectDbgValue(getOrCreateVReg(*Address),
+   DI.getVariable(), DI.getExpression());
+}
 return true;
   }
   case Intrinsic::dbg_label: {
diff --git a/test/CodeGen/AArch64/GlobalISel/debug-cpp.ll 
b/test/CodeGen/AArch64/GlobalISel/debug-cpp.ll
new file mode 100644
index 000..e603af678de
--- /dev/null
+++ b/test/CodeGen/AArch64/GlobalISel/debug-cpp.ll
@@ -0,0 +1,67 @@
+; RUN: llc -global-isel -mtriple=aarch64 %s -stop-after=irtranslator -o - | 
FileCheck %s
+; RUN: llc -mtriple=aarch64 -global-isel --global-isel-abort=0 -o /dev/null
+
+; struct NTCopy {
+;   NTCopy();
+;   NTCopy(const NTCopy &);
+;   int x;
+; };
+; int foo(NTCopy o) {
+;   return o.x;
+; }
+
+; ModuleID = 'ntcopy.cpp'
+source_filename = "ntcopy.cpp"
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-unknown-linux-gnu"
+
+%struct.NTCopy = type { i32 }
+
+; CHECK-LABEL: name: _Z3foo6NTCopy
+; CHECK: DBG_VALUE debug-use %{{[0-9]+}}(p0), 0, !23, !DIExpression(), 
debug-location !24
+; Function Attrs: noinline nounwind optnone
+define dso_local i32 @_Z3foo6NTCopy(%struct.NTCopy* %o) #0 !dbg !7 {
+entry:
+  call void @llvm.dbg.declare(metadata %struct.NTCopy* %o, metadata !23, 
metadata !DIExpression()), !dbg !24
+  %x = getelementptr inbounds %struct.NTCopy, %struct.NTCopy* %o, i32 0, i32 
0, !dbg !25
+  %0 = load i32, i32* %x, align 4, !dbg !25
+  ret i32 %0, !dbg !26
+}
+
+; Function Attrs: nounwind readnone speculatable
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
+
+attributes #0 = { noinline nounwind optnone }
+attributes #1 = { nounwind readnone speculatable }
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+!llvm.ident = !{!6}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, 
producer: "clang version 8.0.0 ", isOptimized: false, runtimeVersion: 0, 
emissionKind: FullDebug, 

Bug#909704: dh --sourcdir=foo skips dh_auto_build

[Helmut Grohne]

Package: debhelper
Version: 11.4
Severity: important
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:japa

Cross building japa fails because the build does not run dh_auto_build
and when it builds in dh_auto_install, debhelper does not pass cross
tools to make. The actual bug though is not running dh_auto_build. As
can be seen on wuiet, the last archive build of japa/0.8.4-2 did run
dh_auto_build. It's a debehelper change that made it stop running
dh_auto_build. Niels identified the cause: japa passes
--sourcedir=source (an abbreviated long option) to dh. The noop promise
handling does not properly handle abbreviated long options.

Looking further, I think the overlap in options is quite unfortunate and
contributes to the confusion: dh supports --sourcedirectory and
dh_install supports --sourcedir (with a different meaning).

I estimate that around 20 packages are affected:
https://codesearch.debian.net/search?q=dh+.*--sourcedir%3D

Helmut

Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

[Ximin Luo]

Ximin Luo:
> Do you have a link to a more detailed description of the problem, so that the 
> rest of us can understand it?
> 
> For example James in message 29 gave a very detailed summary of other 
> previous problems:
> 
> [29] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881845#29
> 
> Nobody in this thread has stated what the supposed problem actually is with 
> these Cavium/Octeon machines. FYI the builds failed recently on eberlin and 
> manda-03, and has failed in the past on aql-01. These are all octeon, and the 
> other mips64el buildd sil-01 is also octeon. So it seems all our buildds are 
> affected by the bug. So the blacklist approach won't even work.
> 

Oh I take that back, it seems aql-01 and manda-01,02 are not octeon, I had 
previously assumed all the x-{01..03} machines would be the same.

Still, please give us a link to the description of the problem.

X

> Also unless I can understand the problem, I don't feel happy using the 
> blacklist as a temporary solution, even if it was going to work.
> 
> X
> 
> YunQiang Su:
>> It is still about llvm+octeon problem.
>>
>> Maybe we can ask pin rustc on Loongson machines.
>> Ximin Luo  于2018年9月24日周一 上午2:21写道：
>>>
>>> Aron Xu:
 [..]
>
> Aron, the next version 1.27.1 is already in binary-NEW so the same issue 
> will block testing migration again, when that gets accepted.
>
> Earlier you said "Binary only upload from porter is allowed [..]" but I 
> am not sure the other porters have access to a loongson-3a box. Will you 
> continue to run builds of new rustc versions on your box? I think that is 
> the key point here.
>

 Will do that and see if we can get the issue either fixed or have a
 blacklist placed at the same time.

>>>
>>> I have just uploaded 1.29.0 to unstable. It will need manual building with 
>>> a non-buggy mips machine, to unblock us for Debian Testing. The previous 
>>> build 1.29.0+dfsg1-1~exp1 failed due to hanging atomic tests:
>>>
>>> https://buildd.debian.org/status/fetch.php?pkg=rustc=mips64el=1.29.0%2Bdfsg1-1%7Eexp1=1537686627=0
>>>
>>> test sync.rs - sync::Arc (line 124) ... test sync.rs - sync::Arc (line 124) 
>>> has been running for over 60 seconds
>>> test sync.rs - sync::Arc::downgrade (line 418) ... test sync.rs - 
>>> sync::Arc::downgrade (line 418) has been running for over 60 seconds
>>> test sync.rs - sync::Arc::get_mut (line 856) ... test sync.rs - 
>>> sync::Arc::get_mut (line 856) has been running for over 60 seconds
>>> test sync.rs - sync::Arc::make_mut (line 769) ... test sync.rs - 
>>> sync::Arc::make_mut (line 769) has been running for over 60 seconds
>>> E: Build killed with signal TERM after 150 minutes of inactivity
>>>
>>> I still think we should just RM rustc on mips64el.
>>>
>>> X
>>>
>>> --
>>> GPG: ed25519/56034877E1F87C35
>>> GPG: rsa4096/1318EFAC5FBBDBCE
>>> https://github.com/infinity0/pubkeys.git
>>>
>>
>>
> 
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

[Ximin Luo]

Do you have a link to a more detailed description of the problem, so that the 
rest of us can understand it?

For example James in message 29 gave a very detailed summary of other previous 
problems:

[29] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881845#29

Nobody in this thread has stated what the supposed problem actually is with 
these Cavium/Octeon machines. FYI the builds failed recently on eberlin and 
manda-03, and has failed in the past on aql-01. These are all octeon, and the 
other mips64el buildd sil-01 is also octeon. So it seems all our buildds are 
affected by the bug. So the blacklist approach won't even work.

Also unless I can understand the problem, I don't feel happy using the 
blacklist as a temporary solution, even if it was going to work.

X

YunQiang Su:
> It is still about llvm+octeon problem.
> 
> Maybe we can ask pin rustc on Loongson machines.
> Ximin Luo  于2018年9月24日周一 上午2:21写道：
>>
>> Aron Xu:
>>> [..]

 Aron, the next version 1.27.1 is already in binary-NEW so the same issue 
 will block testing migration again, when that gets accepted.

 Earlier you said "Binary only upload from porter is allowed [..]" but I am 
 not sure the other porters have access to a loongson-3a box. Will you 
 continue to run builds of new rustc versions on your box? I think that is 
 the key point here.

>>>
>>> Will do that and see if we can get the issue either fixed or have a
>>> blacklist placed at the same time.
>>>
>>
>> I have just uploaded 1.29.0 to unstable. It will need manual building with a 
>> non-buggy mips machine, to unblock us for Debian Testing. The previous build 
>> 1.29.0+dfsg1-1~exp1 failed due to hanging atomic tests:
>>
>> https://buildd.debian.org/status/fetch.php?pkg=rustc=mips64el=1.29.0%2Bdfsg1-1%7Eexp1=1537686627=0
>>
>> test sync.rs - sync::Arc (line 124) ... test sync.rs - sync::Arc (line 124) 
>> has been running for over 60 seconds
>> test sync.rs - sync::Arc::downgrade (line 418) ... test sync.rs - 
>> sync::Arc::downgrade (line 418) has been running for over 60 seconds
>> test sync.rs - sync::Arc::get_mut (line 856) ... test sync.rs - 
>> sync::Arc::get_mut (line 856) has been running for over 60 seconds
>> test sync.rs - sync::Arc::make_mut (line 769) ... test sync.rs - 
>> sync::Arc::make_mut (line 769) has been running for over 60 seconds
>> E: Build killed with signal TERM after 150 minutes of inactivity
>>
>> I still think we should just RM rustc on mips64el.
>>
>> X
>>
>> --
>> GPG: ed25519/56034877E1F87C35
>> GPG: rsa4096/1318EFAC5FBBDBCE
>> https://github.com/infinity0/pubkeys.git
>>
> 
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#909527: [Pkg-mozext-maintainers] Bug#909527: mozilla-devscripts: dh_webext breaks on non-ascii debian/control when building with LANG=C

[Ximin Luo]

Carsten Schoenert:
> [..]
> it seems some more fencing is needed.
> Even with the fix Christoph is suggesting I get some error like the one
> above.
> 
> If I add the following additions it works better. Note, I'm not a Python
> programmer so this might done in a better way. :)
> 
> @@ -70,7 +71,7 @@ def run(cmdline, verbose=False):
>  subprocess.check_call(cmdline)
> 
>  def get_all_packages():
> -lines = open("debian/control").readlines()
> +lines = open("debian/control", encoding='utf8').readlines()
>  package_lines = [x for x in lines if x.find("Package:") >= 0]
>  packages = [p[p.find(":")+1:].strip() for p in package_lines]
>  packages = [p for p in packages if p.startswith("webext-")]
> @@ -143,7 +144,7 @@ def install_webext(*args):
>  args, unknown = parser.parse_known_args(args)
>  if unknown:
>  log("Ignored some command-line arguments: %r" % unknown)
> -packages = args.packages or get_all_packages()
> +packages = [x.decode('UTF8') for x in args.packages] or 
> [x.decode('UTF8') for x in get_all_packages()]
> 
>  home = args.home
>  name = args.name
> 

On my computer here only the first hunk is necessary. Can you try without the 
second hunk? I can't see why it should be necessary.


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#902102: hypre has underlinked libraries, causing build failures with ld --as-needed

[Drew Parsons]

Package: libhypre-dev
Version: 2.14.0-3
Followup-For: Bug #902102

The missing external library (superlu) is a simple bug that can be fixed.

The other, internal library is more subtle. hypre is designed as a
monolithic library.  Original Debian developers chose to split it into
components, hence the separate lib_HYPRE_ libraries

The problem is that there are some circular dependencies.  parcsr_ls
depends on parcsr_mv, and parcsr_mv depends on parcsr_ls.  One needs
to be built before the other.  At the moment parcsr_mv is built first
and so is not explicitly linked at build time to parcsr_ls.  parcsr_ls
gets the explicit link to parcsr_mv.  

If you try to link parcsr_mv to parcsr_ls then there is a make error,
   No rule to make target '../parcsr_ls/libHYPRE_parcsr_ls.so', needed by
   'libHYPRE_parcsr_mv.so'.  Stop.

Similar for libHYPRE_mli (circular dependency with libHYPRE_FEI)

Is there a better way to handle the circular dependency? Can the
missing link be added afterwards (after both libraries have been
compiled)?  Should we restore upstream's monolithic library?

Bug#884352: virtualenvwrapper: Python interpreter inside virtualenv breaks after system python upgrade

[Nicholas D Steeves]

On Tue, Sep 25, 2018 at 01:12:51AM +0500, Andrey Rahmatullin wrote:
> On Mon, Sep 24, 2018 at 03:46:09PM -0400, Nicholas D Steeves wrote:
> > > > after upgrading system-wide Python installation (in my case from 3.5.3 
> > > > to 3.5.4),
> > > > virtualenvs may break due to the outdated interpreter 
> > > > (somevirtualenv/bin/python3) inside the venv, trying to work with a 
> > > > newer stdlib.
> > > This is in no way specific to virtualenvwrapper which is just a wrapper.
> > 
> > Hi Andrey!  If this is the case would you please reassign this bug to
> > virtualenv?
> I don't see any real value in reassigning this bug and I don't want to
> find out the correct binary package name.

bin:virtualenv depends on python-virtualenv and python3-virtualenv so
might be a good pick, alternatively src:python-virtualenv.  As for
the value?  See below \/

> > > > The problem is that mkvirtualenv copies rather than symlinks the python 
> > > > interpreter binary, but symlinks the modules from standard library 
> > > > (e.g. /usr/lib/python3.5).
> > > This is done by virtualenv, not mkvirtualenv, and it was always that way,
> > > and it's quite well known that the breakages happen and how to fix them
> > > (by running virtualenv again). It is done because otherwise Python would
> > > not find some files using relative paths.
> > > 
> > > See also https://github.com/pypa/virtualenv/pull/1171 and note "only for
> > > Python 3.3 and higher".

If the resolution of this bug depends on [1] (see below), then
bin:python3-virtualenv would be most correct and the bug could be
marked as forwarded.  For maximal correctness I suspect the bug should
be cloned and -1 reassigned to python-virtualenv, and -2 reassigned to
python3-virtualenv (and marked forwarded with the URL you provided).

> > As a beginner to Python it seems to me that the current behaviour
> > (copied interpreter and symlinked modules) is incorrect and that there
> > are three correct solutions:
> > 
> >   1) As proposed in that PR, symlink the interpreter.
> This will fix itself when the PR is merged, not sooner.
> 
> >   2) Copy the libraries instead of symlinking them.
> Can't comment on this.
> 
> >   3) Downgrade the severity of this bug to non-RC, because this is a
> >  known and expected issue when using virtualenvs.
> Sure, but this is up to the maintainer.

src:python-virtualenv is Python Team maintained and as a member of
that team don't you have the authority to reassign this bug to a team
package.  Alternatively Jan could ACK the severity downgrade for this
bug.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#909703: python3-gi: Should not depend on python3-cairo

[Jeremy Bicha]

Package: python3-gi
Version: 3.30.1-1
Severity: important

An Ubuntu developer pointed out that python3-gi has recently gained a
dependency on python3-cairo. This is unexpected because there is a
separate python3-gi-cairo package produced by the same source package.
It also significantly increases python3-gi's dependency chain.

I cannot duplicate this bug if I revert
https://salsa.debian.org/gnome-team/pygobject/commit/b5116ffb (the
switch to pybuild)

Thanks,
Jeremy Bicha

Bug#841208: fixed in monkeysphere 0.41-1

[Antoine Beaupre]

On Wed, Jan 11, 2017 at 06:06:44PM -0500, Daniel Kahn Gillmor wrote:
> If we believe that no test suites or build processes should need system
> entropy at all (not implausible in these days of reproducible builds and
> hopefully-deterministic test suites), another approach would be to
> symlink /dev/random to /dev/urandom on all buildd's, and then the
> builders just get what they get, rather than starving the system of
> entropy.
> 
> thanks for continuing to push on this stuff.  If you have any better
> suggestions for resolution, i'd be happy to hear them.
> 
> I probably need to open an upstream bug with gnupg about subkey
> generation when there is limited system entropy too, but i tend to
> actually have system entropy on my own hardware and haven't had the time
> to set up a deliberately-starved machine for the test process.

I've been able to (more or less) reproduce this bug while working on a
bunch of other test suite failures here. Just run the test suite on a
loop and you'll exhaust any entropy pool fairly quickly. (Of course, the
test suite in Debian fails way before we reach that point right now, but
on git that's fixed so we actually hit key generation now. :)

That said, I was able to workaround the issue by installing haveged
here. I know, it's not a good general solution to entropy starvation in
production, as it relies on CPU features which might be absent on
virtual machines, for example. It might just make sense, however, to add
it as a build-dep to fix the test suite.

A.


signature.asc
Description: PGP signature

Bug#905240: RFS: golang-github-rivo-tview

[Jongmin Kim]

On Sat, Sep 08, 2018 at 04:46:03AM +0900, Jongmin Kim wrote:
> On Fri, Sep 07, 2018 at 10:05:45AM -0400, Alexandre Viau wrote:
> > What did you use to choose the branch names?
> > 
> > I don't see a "master" branch, so this is probably the new workflow?
> > 
> > However, the new workflow does not use the "debian" branch:
> >  - https://go-team.pages.debian.net/workflow-changes.html
> > 
> > Please either use a repository as created by dh-make-golang or use the
> > new workflow according to the spec on the team's website.
> 
> I will follow the new workflow for this package. Thank you!
> 
> 
> On Fri, Sep 07, 2018 at 10:07:48AM -0400, Alexandre Viau wrote:
> > I'd like to avoid repeating the same comments twice, maybe you should
> > focus on one ITP and then proceed to the next?
> 
> Great! I will focus on 'tview' first.
> 
> 
> On Fri, Sep 07, 2018 at 11:29:27AM -0700, Felix Lechner wrote:
> > On Fri, Sep 7, 2018 at 11:26 AM Alexandre Viau  wrote:
> > > On 2018-09-07 01:48 PM, Jongmin Kim wrote:
> > > > 'master' is the default for pristine-tar branches, right?
> > > > How do you think about renaming to 'debian/sid'?
> > > >
> > > > As Alexandre commented, 1.4 in our team's workflow change proposal
> > > > suggests new workflow to adopt DEP-14, which recommends 'debian/master'
> > > > or 'debian/'. And our team's proposal suggests that the 
> > > > default
> > > > branch should be named 'debian/sid'.
> > > >
> > > > I think I have to rename it to 'debian/sid'.
> > >
> > > Yes, I agree. This is what the document suggests.
> > >
> > > Note that, technically, debian/master would also work, but I think
> > > debian/sid or debian/unstable is clearer in the case of Debian.
> > >
> > > See DEP14: https://dep-team.pages.debian.net/deps/dep14/
> >
> > Yes, 'debian/sid' makes the most sense. I agree with Alex. Thank you!
> 
> Thanks a lot for all!
> 
> 
> To Alexandre,
> 
> Would you review my namespace [1] first? A bunch of mistakes might be
> came out, including which need controlling the protected branches. After
> your careful review, I will push all the things into our team's repository.
> Sorry for taking back what I said.
> 
> Or, could you please remove the 'debian' branch from our team's repo?
> I don't have a right for removing it. I will push 'debian/sid' there.
> 
> Thank you!

Hi,

During waiting for review, I made some updates:

 * Rename branch 'debian' to 'debian/sid' in our team's repo.
 * Merge upstream version 'bc39bf8d'.

I pushed all things into our team's repo [1]. Please review team repo.
Thank you!

[1] https://salsa.debian.org/go-team/packages/golang-github-rivo-tview


-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#899060: FTBFS: even if tests pass, dh_auto_test fails

[Antoine Beaupré]

On 2018-09-26 19:52:39, Antoine Beaupre wrote:

[...]

> For thre record, the above failed testsuite log fails on:
>
> 2018/05/18 14:25:50 socat[27609] E connect(5, AF=1 
> "/<>/tests/tmp/ms.cco/ssh-socket", 74): Connection refused
> ssh_exchange_identification: Connection closed by remote host
>
> ./tests/basic: line 81: kill: (27487) - No such process
> # ssh connection test FAILED. returned: 255, expected: 0
> FAILED!
> ### removing temp dir...
>
> That is strange in itself, but the "passed" one is much stranger, as
> mentioned.

I can reproduce the latter (the "failed" test) reliably. It fails at
different places, however. Here are two logfiles, for example, which
both fail, but in different tests, with the same error message:

MONKEYSPHERE_TEST_NO_EXAMINE=true ./tests/keytrans
##
### generating openpgp key...
##
### retrieving key timestamp...
##
### exporting key to ssh file...
##
### reconvert key, and compare to key in gpg keyring...
conversions look good!
Now working with key C5BE5E5ACA72DDE9 at time 1538012950
/home/anarcat/src/monkeysphere/tests/tmp/ms.enn/pubring.kbx
---
pub   rsa1024 2018-09-27 [SC]
  991716AD63038428521DFDC8C5BE5E5ACA72DDE9
uid  [  ultime ] testtest

##
### test User ID addition...
/home/anarcat/src/monkeysphere/tests/tmp/ms.enn/pubring.kbx
---
pub   rsa1024 2018-09-27 [SC]
  991716AD63038428521DFDC8C5BE5E5ACA72DDE9
uid  [  ultime ] monkeymonkey
uid  [  ultime ] testtest

##
### sleeping to avoid test suite breakage on fast
### processors (see http://bugs.debian.org/591118)
##
### test User ID revocation ... 
/home/anarcat/src/monkeysphere/tests/tmp/ms.enn/pubring.kbx
---
pub   rsa1024 2018-09-27 [SC]
  991716AD63038428521DFDC8C5BE5E5ACA72DDE9
uid  [  ultime ] monkeymonkey
uid  [ révoquée] testtest

##
### test working with two primary keys ... 
Generating public/private rsa key pair.
Your identification has been saved in 
/home/anarcat/src/monkeysphere/tests/tmp/ms.enn/newkey.
Your public key has been saved in 
/home/anarcat/src/monkeysphere/tests/tmp/ms.enn/newkey.pub.
The key fingerprint is:
SHA256:G7T9t1MGVrBMRU8FoDUqV1vQVYpRO5d0DNJwiM7YRbY anarcat@curie
The key's randomart image is:
+---[RSA 1024]+
|   o%OOX@|
|  .*o%+=*|
|o=+.E *oo|
|   ..=+   oo |
|S .  . . |
| o .o|
|.   . .o |
| ... |
|  .. |
+[SHA256]-+
test: diff expected gpg list output
test: diff expected keytrans listfpr output
##
 Monkeysphere keytrans test completed successfully!
##
### removing temp dir...
MONKEYSPHERE_TEST_NO_EXAMINE=true ./tests/basic
Permissions on temporary directory 
'/home/anarcat/src/monkeysphere/tests/tmp/ms.dsn' are OK for permissions checks.

##
### configuring testuser home...
2 blocs
gpg: le trousseau local « 
/home/anarcat/src/monkeysphere/tests/tmp/ms.dsn/testuser/.gnupg/pubring.kbx » a 
été créé
gpg: key E00B5EEEBA79B482: 1 signature not checked due to a missing key
gpg: 
/home/anarcat/src/monkeysphere/tests/tmp/ms.dsn/testuser/.gnupg/trustdb.gpg : 
base de confiance créée
gpg: clef E00B5EEEBA79B482 : clef publique « Monkeysphere Test Suite Test User 
(DO NOT USE!!!)  » importée
gpg: clef E00B5EEEBA79B482 : clef secrète importée
gpg:   Quantité totale traitée : 1
gpg: importées : 1
gpg:   clefs secrètes lues : 1
gpg:  clefs secrètes importées : 1
gpg: aucune clef de confiance ultime n'a été trouvée
gpg: key E00B5EEEBA79B482: 1 signature not checked due to a missing key
gpg: clef E00B5EEEBA79B482 : « Monkeysphere Test Suite Test User (DO NOT 
USE!!!)  » n'est pas modifiée
gpg: clef 36FF78B37005D3BE : clef publique « Monkeysphere Test Suite Fake 
Administrative User (DO NOT USE!!!)  » importée
gpg:   Quantité totale traitée : 2
gpg: importées : 1
gpg: non modifiées : 1
gpg: aucune clef de confiance ultime n'a été trouvée
gpg: inserting ownertrust of 6
gpg: inserting ownertrust of 5

##
### configuring admin home...
gpg: le trousseau local « 
/home/anarcat/src/monkeysphere/tests/tmp/ms.dsn/admin/.gnupg/pubring.kbx » a 
été créé
gpg: /home/anarcat/src/monkeysphere/tests/tmp/ms.dsn/admin/.gnupg/trustdb.gpg : 
base de confiance créée

Bug#909658: debian-installer: blank screen on install (HP Elitebook 830 G5)

[Hideki Yamane]

On Wed, 26 Sep 2018 23:20:29 +0900
Hideki Yamane  wrote:
> > Success
> > - Ubuntu18.04.1 (Linux 4.15.0-29-generic)
> > 
> > Fail
> > - Debian9.4
> > - both Debian Installer Buster Alpha 3 release and daily image

 Boot resolution is different between Ubuntu and d-i.

 Ubuntu 18.04.1
 https://photos.app.goo.gl/yWTJV6RQ7dXZDFQA8

 Debian Installer Buster Alpha 3
 https://photos.app.goo.gl/t7ASV2qZ4rZ4kPvk7


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#909702: eom: depends on transitional dummy package libgl1-mesa-glx

[Rogério Brito]

Package: eom
Version: 1.20.1-1
Severity: wishlist

Hi.

eom depends on the transitional dummy package libgl1-mesa-glx. It seems that
other packages that need the functionality have an alternative dependency of:

"libgl1-mesa-glx | libgl1"

Please, consider this for future uploads.


Thanks,

Rogério.

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

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

Versions of packages eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  eom-common   1.20.1-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo-gobject21.15.12-1
ii  libcairo21.15.12-1
ii  libdbus-1-3  1.12.10-1
ii  libdbus-glib-1-2 0.110-3
ii  libexempi3   2.4.5-2
ii  libexif120.6.21-5
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libgirepository-1.0-11.58.0-1
ii  libgl1-mesa-glx  18.1.7-1
ii  libglib2.0-0 2.58.0-4
ii  libgtk-3-0   3.24.0-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  libmate-desktop-2-17 1.20.3-2
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpeas-1.0-01.22.0-2
ii  librsvg2-2   2.40.20-3
ii  librsvg2-common  2.40.20-3
ii  libstartup-notification0 0.12-5
ii  libx11-6 2:1.6.6-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  mate-desktop-common  1.20.3-2
ii  shared-mime-info 1.9-2
ii  zlib1g   1:1.2.11.dfsg-1

eom recommends no packages.

eom suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#902367: monkeysphere: test/keytrans depends on older GnuPG format

[Antoine Beaupré]

On 2018-09-26 20:33:45, Antoine Beaupre wrote:
> Control: tags -1 +patch
>
> This is fixed in git, in patch dfab82a

... and that wasn't sufficient, so I added 438dbdc and 3c32899 on top.

For some reason, GnuPG 2.something broke spec (if you call "DETAILS" a
spec...) and the revocation "--with-colons" line is not "30x" anymore,
but "30x,20". It's out of spec because DETAILS doesn't say explicitely
it's a comma-separated list.

Other changes seem to be on spec.

A.

-- 
To understand how any society functions you must understand the
relationship between the men and the women
- Angela Davis

Bug#909700: tests/keytrans and pem2openpgp expect old-style PEM format for SSH keys

[Antoine Beaupré]

Control: tags -1 +patch

I have pushed d8fc9f2 to fix that part of the test suite at least. It
was only a matter of passing "-m PEM" to ssh-keygen in the test suite,
but we still have the problem that we can't parse the new-style OpenSSH
key formats in pem2openpgp...

A.

-- 
Brief is this existence, as a fleeting visit in a strange house.
The path to be pursued is poorly lit by a flickering consciousness.
   - Albert Einstein

Bug#909701: RFS: wxmaxima/18.10.1-1

[Gunter Königsmann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

 I am looking for a sponsor for my package "wxmaxima"

* Package name: wxmaxima
  Version : 18.10.1-1
  Upstream Author : Gunter Königsmann
* URL : http://wxmaxima-developers.github.io/wxmaxima/
* License : GPL
  Section : math

It builds those binary packages:

  wxmaxima   - GUI for the computer algebra system Maxima

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

https://mentors.debian.net/package/wxmaxima

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/wxmaxima/wxmaxima_18.10.1-1.dsc

wxMaxima is a full-featured (and quite fast) graphical user interface for 
maxima, a program 
that is specialized in symbolics math but that can do dloating-point 
calculations (either 
with native floats or arbitrary-length floating-point numbers) or with 
arbitrary-length
rational numbers. A sample session would be:

(%i2)   eq:x^3+5*x+7=4;
(eq)x^3+5*x+7=4
(%i3)   solve(eq,x);
(%o3)   
[x=(sqrt(743)/(2*3^(3/2))-3/2)^(1/3)*((-1)/2-(sqrt(3)*%i)/2)-(5*((sqrt(3)*%i)/2+(-1)/2))/(3*(sqrt(743)/(2*3^(3/2))-3/2)^(1/3)),x=(sqrt(743)/(2*3^(3/2))-3/2)^(1/3)*((sqrt(3)*%i)/2+(-1)/2)-(5*((-1)/2-(sqrt(3)*%i)/2))/(3*(sqrt(743)/(2*3^(3/2))-3/2)^(1/3)),x=(sqrt(743)/(2*3^(3/2))-3/2)^(1/3)-5/(3*(sqrt(743)/(2*3^(3/2))-3/2)^(1/3))]
(%i4)   float(%);
(%o4)   
[x=1.039395854606503*(-0.8660254037844386*%i-0.5)-1.603495587634067*(0.8660254037844386*%i-0.5),x=1.039395854606503*
(0.8660254037844386*%i-0.5)-1.603495587634067*(-0.8660254037844386*%i-0.5),x=-0.5640997330275641]


Changes since the last upload:

  * A new upstream version that comes with many bugfixes, features and
performance improvements.
  * Updated the Homepage and the main upstream contact of the program.
  * Dropped all the patches as they are incorporated in the new upstream
release.

The upstream changes are:

  * Defer any try to change Maxima's configuration until all questions are 
answered.
  * A menu item that sets the autosubscript feature for the current worksheet.
  * A menu allowing to switch floats to engineering format.
  * Maxima can now pass the values of variables to wxMaxima.
  * Autocompletion for functions from lisp-only packages and for all of 
maxima's.
built in functions.
  * A context-sensitive "draw" sidepane.
  * We now allow a packet from Maxima to end in the middle of an unicode 
codepoint.
  * If the name of a lisp function is known it now is displayed.
  * A right-click menu that copies an animation to the clipboard.
  * A new default value for the current MathJaX release.
  * A "recent packages" menu for packages loaded from load() or from the menu.
  * Advertise the current file and the file's state to the Operating System
  * Copy as Enhanced Metafile (Windows only).
  * Code simplifications.
  * A dockable panel for the debug messages.
  * A more modern theme.
  * Draw: A right-click menu allowing to open images from the current session as
interactive gnuplot sessions.
  * Migrate the config file to a XDG-compatible location if wxWidgets is new 
enough
to support it.
  * A "Tip of the day" dialogue that allows for resizing, scrollbars and work 
while
it is still open.
  * Matrices can now be displayed using round and square brackets.
  * Various High-DPI enhancements.
  * Enhancements for low-resolution screens.
  * Many bug fixes.
  * Reduced the number of autogenerated files, installed files and external
dependencies to a minimum.
  * Big performance improvements, again.

Kind Regards,
   Gunter Königsmann



pEpkey.asc
Description: application/pgp-keys

Bug#909700: tests/keytrans and pem2openpgp expect old-style PEM format for SSH keys

[Antoine Beaupre]

Package: monkeysphere
Version: 0.41-1
Severity: important

Monkeysphere's test suite currently fails with:

ms: importing key from file 
'/build/1st/monkeysphere-0.41/tests/tmp/ms.9XY/ssh_host_rsa_key'...
RSA.xs:198: OpenSSL error: no start line at 
/build/1st/monkeysphere-0.41/tests/../src/pem2openpgp line 1104,  line 1.
gpg: no valid OpenPGP data found.
FAILED!

That is because openssh 1:7.8p1-1 introduced a new format by default
for ssh-keygen.

This was first discovered on reproducible build server by kilobyte in
#899060.

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages monkeysphere depends on:
ii  adduser3.118
ii  gnupg  2.2.10-1
ii  libcrypt-openssl-rsa-perl  0.30-1
ii  lockfile-progs 0.1.18
ii  perl [libdigest-sha-perl]  5.26.2-7

Versions of packages monkeysphere recommends:
ii  agent-transfer   0.41-1
ii  cron [cron-daemon]   3.0pl1-130
ii  netcat-openbsd [netcat]  1.190-2
ii  netcat-traditional [netcat]  1.10-41.1
ii  openssh-client   1:7.8p1-1
ii  socat1.7.3.2-2
ii  ssh-askpass  1:1.2.4.1-10

Versions of packages monkeysphere suggests:
pn  monkeysphere-validation-agent  

-- debconf-show failed

Bug#909643: installation-reports: doing a dist-upgrade from debian7 to debian8 ended with a non bootable system

[Ben Hutchings]

Control: reassign -1 src:initramfs-tools 0.120+deb8u3
Control: tag -1 moreinfo

On Wed, 2018-09-26 at 17:13 +0900, stranche wrote:
> Package: installation-reports
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> doing a dist-upgrade from debian7 to debian8
> 
>* What exactly did you do (or not do) that was effective (or ineffective)?
> # apt-get upgrade
> editing  /etc/apt/sources.list changing instances of "wheezy" to "jessie"
> # apt-get update
> # apt-get upgrade
> # apt-get dist-upgrade
> # apt-get autoremove
> reboot
> 
>* What was the outcome of this action?
> system boots a newly installed 3.16.0-6-686-pae kernel but gets stuck
> on a BusyBox initramfs prompt
> 
> kernel 3.2.0-6-686-pae from previous distribution works fine
> 
> kernel/initrd files copied form a working debian8 that was installed
> from scratch with CD on an identical machine boots fine too
> 
> if update-initramfs -u is ran to update the initrd, the resulting
> initrd file makes the system in the same unbootable state
> 
> when at initramfs prompt, it is possible to
> -activate LVM with vgchange -ay
> -mount and access the root partition
> However, ussing the "exit" command ends up in a kernel panic, root
> filesystem being mounted on /root or not
[...]

What is the kernel command line?  (Run "cat /proc/cmdline" to show it.)

Please also send a copy of the /etc/initramfs-tools/initramfs.conf
file.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



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

Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

[YunQiang Su]

It is still about llvm+octeon problem.

Maybe we can ask pin rustc on Loongson machines.
Ximin Luo  于2018年9月24日周一 上午2:21写道：
>
> Aron Xu:
> > [..]
> >>
> >> Aron, the next version 1.27.1 is already in binary-NEW so the same issue 
> >> will block testing migration again, when that gets accepted.
> >>
> >> Earlier you said "Binary only upload from porter is allowed [..]" but I am 
> >> not sure the other porters have access to a loongson-3a box. Will you 
> >> continue to run builds of new rustc versions on your box? I think that is 
> >> the key point here.
> >>
> >
> > Will do that and see if we can get the issue either fixed or have a
> > blacklist placed at the same time.
> >
>
> I have just uploaded 1.29.0 to unstable. It will need manual building with a 
> non-buggy mips machine, to unblock us for Debian Testing. The previous build 
> 1.29.0+dfsg1-1~exp1 failed due to hanging atomic tests:
>
> https://buildd.debian.org/status/fetch.php?pkg=rustc=mips64el=1.29.0%2Bdfsg1-1%7Eexp1=1537686627=0
>
> test sync.rs - sync::Arc (line 124) ... test sync.rs - sync::Arc (line 124) 
> has been running for over 60 seconds
> test sync.rs - sync::Arc::downgrade (line 418) ... test sync.rs - 
> sync::Arc::downgrade (line 418) has been running for over 60 seconds
> test sync.rs - sync::Arc::get_mut (line 856) ... test sync.rs - 
> sync::Arc::get_mut (line 856) has been running for over 60 seconds
> test sync.rs - sync::Arc::make_mut (line 769) ... test sync.rs - 
> sync::Arc::make_mut (line 769) has been running for over 60 seconds
> E: Build killed with signal TERM after 150 minutes of inactivity
>
> I still think we should just RM rustc on mips64el.
>
> X
>
> --
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
> https://github.com/infinity0/pubkeys.git
>


-- 
YunQiang Su

Bug#902367: monkeysphere: test/keytrans depends on older GnuPG format

[Antoine Beaupre]

Control: tags -1 +patch

This is fixed in git, in patch dfab82a

-- 
Wire telegraph is a kind of a very, very long cat. You pull his tail
in New York and his head is meowing in Los Angeles. Radio operates
exactly the same way: you send signals here, they receive them
there. The only difference is that there is no cat.
 - Albert Einstein


signature.asc
Description: PGP signature

Bug#849308: state of wireguard mainline inclusion?

[Antoine Beaupré]

On 2018-08-22 17:56:12, Antoine Beaupre wrote:
> Since this was discussed, Wireguard was actually proposed for mainline,
> as described here:
>
> https://lwn.net/Articles/761939/
>
> It seems to me more likely that Wireguard will stabilize in a Linux
> kernel release shipped with Buster than outside.

... I'm not so sure anymore. It seems Wireguard implements a bunch of
crypto primitives outside the normal crypto API through a new module
called Zinc, which is controversial:

https://lwn.net/SubscriberLink/765965/6d509f4af482aa70/ 

This could delay inclusion of Wireguard in the kernel for a bit.

I still think this bug should be closed and we should let wireguard
migrate in testing. I'm sure the relteam would be mooore than happy to
remove it at a moment's notice before or during the freeze if we need
to.

In other words, I feel this bug was filed prematurely. :)

A.
-- 
We will create a civilization of the Mind in Cyberspace. May it be more
humane and fair than the world your governments have made before.
- John Perry Barlow, 1996
A Declaration of Independence of Cyberspace

Bug#909699: emacs-gtk: crash on rendering Kannada script

[Zack Weinberg]

Package: emacs-gtk
Version: 1:25.2+1-11
Severity: important
File: /usr/bin/emacs-gtk

If Emacs is displaying its own window (as opposed to running inside a
terminal), visiting the attached text file will cause emacs to segfault.
The file is a cut-down version of /usr/share/themes/Adwaita/index.theme
(from gnome-themes-extra-data); if you visit *that* file, emacs will
not crash until you scroll down far enough to see the line beginning
Comment[kn].  Removing either of the two lines of the test file
suppresses the crash.

A Lisp backtrace (collected with 'xbacktrace' from the Emacs source
tree's .gdbinit) is quite short:

(gdb) xbacktrace
"font-shape-gstring" (0x5900)
"auto-compose-chars" (0x5b58)
"redisplay_internal (C function)" (0x0)

The presence of auto-compose-chars in this trace points a finger at
composite.el, and indeed if you do C-u -1 M-x global-auto-composition-mode
before visiting the test file, Emacs doesn't crash.  However, it looks like
all the heavy lifting is happening in C, inside font-shape-gstring.

A C stack trace (below) points at the guts of libotf / libm17n, but I am
filing this bug against emacs anyway, because gedit, which presumably
uses the same libraries, does not crash on the test file.

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x7453fa95 in lookup_gpos (lookup_list=lookup_list@entry=0xd2ff28, 
lookup_list_index=lookup_list_index@entry=1, 
gstring=gstring@entry=0x9a7da0 , gidx=, 
gidx@entry=0, accumulate=accumulate@entry=1) at otfdrive.c:975
975 otfdrive.c: No such file or directory.
(gdb) bt
#0  0x7453fa95 in lookup_gpos (lookup_list=lookup_list@entry=0xd2ff28, 
lookup_list_index=lookup_list_index@entry=1, gstring=gstring@entry=0x9a7da0 
, gidx=, gidx@entry=0, 
accumulate=accumulate@entry=1)
at otfdrive.c:975
#1  0x74540e64 in OTF_drive_gpos_internal (otf=otf@entry=0xcb7500, 
gstring=gstring@entry=0x9a7da0 , script=, 
language=, features=, 
accumulate=accumulate@entry=1, with_log=1)
at otfdrive.c:1886
#2  0x74542a2a in OTF_drive_gpos_with_log (otf=otf@entry=0xcb7500, 
gstring=gstring@entry=0x9a7da0 , 
script=script@entry=0x7fff499e "knda", language=language@entry=0x0, 
features=features@entry=0x7fff48e0 "abvm,blwm,dist") at otfdrive.c:1935
#3  0x005c3d3a in ftfont_drive_otf (font=, 
spec=, in=, from=, to=, out=0x7fff5610, adjustment=) at 
./debian/build-src/src/ftfont.c:2035
#4  0x740f94f2 in run_otf (depth=, otf_spec=0x18281a8, 
from=from@entry=1, to=to@entry=3, ctx=0x7fff5630) at m17n-flt.c:1945
#5  0x740fcba8 in run_command (depth=depth@entry=8, id=, 
from=from@entry=1, to=to@entry=3, ctx=ctx@entry=0x7fff5630)
at m17n-flt.c:2169
#6  0x740fcf67 in run_rule (depth=8, rule=0x1828140, from=1, 
from@entry=0, to=, to@entry=4, ctx=0x7fff5630)
at m17n-flt.c:1836
#7  0x740fc75c in run_command (depth=depth@entry=7, id=, 
from=from@entry=0, to=to@entry=4, ctx=ctx@entry=0x7fff5630)
at m17n-flt.c:2165
#8  0x740fcf67 in run_rule (depth=7, rule=
0x18280d8, from=from@entry=0, to=, 
to@entry=4, ctx=0x7fff5630) at m17n-flt.c:1836
#9  0x740fc75c in run_command (depth=depth@entry=6, id=, 
from=from@entry=0, to=to@entry=4, ctx=ctx@entry=0x7fff5630)
at m17n-flt.c:2165
#10 0x740fcb53 in run_cond (cond=0x1828070, cond=0x1828070, 
ctx=0x7fff5630, to=4, from=0, depth=) at m17n-flt.c:1863
#11 0x740fcb53 in run_command (depth=depth@entry=5, id=, 
from=from@entry=0, to=to@entry=4, ctx=ctx@entry=0x7fff5630)
at m17n-flt.c:2167
#12 0x740fcf67 in run_rule (depth=5, rule=
0x1828008, from=from@entry=0, to=, ctx=0x7fff5630)
at m17n-flt.c:1836
#13 0x740fc75c in run_command (depth=depth@entry=4, 
id=id@entry=-16777232, from=from@entry=0, to=, 
ctx=ctx@entry=0x7fff5630)
at m17n-flt.c:2165
#14 0x740fdb98 in run_stages (gstring=gstring@entry=0x9a7d80 , 
from=from@entry=0, to=, 
to@entry=2, ctx=ctx@entry=0x7fff5630, flt=)
at m17n-flt.c:2359
#15 0x740fee51 in mflt_run (gstring=gstring@entry=0x9a7d80 , 
from=from@entry=0, to=, 
to@entry=2, font=font@entry=0x7fff5760, flt=, 
flt@entry=0x0) at m17n-flt.c:3050
#16 0x005c4d70 in ftfont_shape_by_flt (matrix=, 
otf=, ft_face=, font=, 
lgstring=10802589)
at ./debian/build-src/src/ftfont.c:2644
#17 0x005c4d70 in ftfont_shape (lgstring=10802589)
---Type  to continue, or q  to quit---
at ./debian/build-src/src/ftfont.c:2697
#18 0x005c875e in xftfont_shape (lgstring=10802589)
at ./debian/build-src/src/xftfont.c:672
#19 0x00573e98 in Ffont_shape_gstring (gstring=10802589)
at ./debian/build-src/src/font.c:4410
#20 0x005648d8 in Ffuncall (nargs=2, args=args@entry=0x7fff58f8)
at ./debian/build-src/src/lisp.h:1061
#21 0x00599a6b in exec_byte_code (bytestr=, 
vector=, maxdepth=, 

Bug#899060: FTBFS: even if tests pass, dh_auto_test fails

[Antoine Beaupre]

On Fri, May 18, 2018 at 08:40:56PM +0200, Adam Borowski wrote:
> If no random problem happens, the build still fails with:
> 
> .
> ##
>  Monkeysphere basic tests completed successfully!
> ##
> ### removing temp dir...
> make[1]: Leaving directory '/<>'
> dh_auto_test: make -j2 -Oline test returned exit code 2
> debian/rules:6: recipe for target 'build' failed
> make: *** [build] Error 25
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> `
> 
> To exclude a peculiarity of my test setup (btrfs, new non-Debian kernel,
> etc), official buildds of second-class archs that tried monkeysphere
> recently concur.
> 
> Build logs of two types (failed and passed testsuite) attached.

For thre record, the above failed testsuite log fails on:

2018/05/18 14:25:50 socat[27609] E connect(5, AF=1 
"/<>/tests/tmp/ms.cco/ssh-socket", 74): Connection refused
ssh_exchange_identification: Connection closed by remote host

./tests/basic: line 81: kill: (27487) - No such process
# ssh connection test FAILED. returned: 255, expected: 0
FAILED!
### removing temp dir...

That is strange in itself, but the "passed" one is much stranger, as
mentioned.

On Mon, Jun 18, 2018 at 07:56:10PM +0200, Adam Borowski wrote:
[...] 
> So does reproducible:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/monkeysphere.html
> (fails on all 4 tested: amd64 i386 armhf arm64)

That, however, seems to be a different problem, at least now. The amd64
failed with:

ms: importing key from file 
'/build/1st/monkeysphere-0.41/tests/tmp/ms.9XY/ssh_host_rsa_key'...
RSA.xs:198: OpenSSL error: no start line at 
/build/1st/monkeysphere-0.41/tests/../src/pem2openpgp line 1104,  line 1.
gpg: no valid OpenPGP data found.
FAILED!

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/monkeysphere_0.41-1.rbuild.log.gz

I wonder if that shouldn't be treated separately: I suspect this is
related to the recent changes in OpenSSH's key storage format.

So I'd propose we keep this bug for "kilobyte's weird heisenbug FTBFS"
and open a separate issue for the RSA key parser.. :/

A.


signature.asc
Description: PGP signature

Bug#909698: rakudo: perl6-tap-harness fails to configure: Could not open /usr/share/perl6/install-dist.p6. Failed to stat file: no such file or directory

[Axel Beckert]

Package: rakudo
Version: 2018.09-1
Severity: serious
Control: affects -1 perl6-tap-harness

Hi,

perl6-tap-harness fails to install for me as follows on a Raspberry Pi
with Debian Sid armhf:

[…]
Setting up perl6-tap-harness (0.20180415-1) ...
Could not open /usr/share/perl6/install-dist.p6. Failed to stat file: no such 
file or directory
module perl6-tap-harness compilation failed: 256 at 
/usr/share/perl6/rakudo-helper.pl line 44.
dpkg: error processing package perl6-tap-harness (--configure):
 installed perl6-tap-harness package post-installation script subprocess 
returned error exit status 2
[…]
Errors were encountered while processing:
 perl6-tap-harness

The file /usr/share/perl6/install-dist.p6 does not neither exist on
that installation nor does it belong to any installed package.

Also "apt-file search /usr/share/perl6/install-dist.p6" doesn't find
that file, neither on Debian Sid armhf nor on Debian Sid amd64.

Funnily I have perl6-tap-harness successfully installed on amd64
despite I can't find  /usr/share/perl6/install-dist.p6 there either.

Reason for this is probably the switch from
/usr/share/perl6/install-dist.pl to
/usr/share/perl6/tools/install-dist.p6 between 2018.06-1 and
2018.09-1. Please note that this path contains "tools" while the error
message doesn't have "tools" in the path.

Since it's /usr/share/perl6/rakudo-helper.pl which contains that
erroneous path, the issue is not in perl6-tap-harness but in rakudo.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'buildd-unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 
'buildd-experimental'), (1, 'experimental')
Architecture: armhf (armv7l)

Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages perl6-tap-harness depends on:
ii  rakudo  2018.09-1

perl6-tap-harness recommends no packages.

perl6-tap-harness suggests no packages.

-- no debconf information

Bug#909697: keepalived: Keepalived does not parse correctly brakets without space

[Daniele Palumbo]

Package: keepalived
Version: 1:1.3.2-1
Severity: normal

Hi,

The current squeeze version of keepalived is not parsing correctly the brackets 
to open a section.
This is related, but not the same, as 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656620.

This is already fixed upstream (v2.0.7 tested), therefore fixing 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900260 would fix also this 
bug.

IMO the most closer entry in the changelog is:
```
Release 1.4.2
[...]
* Allow more flexibility of layout of { and } in config files.
  keepalived was a bit fussy about where '{'s and '}'s (braces) could
  be placed in terms of after the keyword, or on a line on their own.
  It certainly was not possible to have multiple braces on one line.
  This commit now provides complete flexibility of where braces are, so 
  long as they occur in the correct order.
```

Here a reproducer:

Suppose the following vrrp_script
```
vrrp_script chk_apache{
script "/bin/true"
interval 2
timeout 4
fall 2
rise 10
}
```

Please note the "chk_apache{" without whitespace.

In case a vrrp_script is written like
`vrrp_script chk_apache{`
In place of
`vrrp_script chk_apache {`

The dump reports correctly the entry
```
 VRRP Script = chk_apache{
 VRRP process priority = 0
   Command = /usr/lib/nagios/plugins/check_http -I 127.0.0.1
   Interval = 2 sec
[...]
```
But it also report errors
```
# keepalived -dDnl -f /etc/keepalived/keepalived.conf
Opening file '/etc/keepalived/keepalived.conf'.
Unknown keyword 'script'
Unknown keyword 'interval'
Unknown keyword 'timeout'
Unknown keyword 'fall'
Unknown keyword 'rise'
Unknown keyword '}'
[...]
Opening file '/etc/keepalived/keepalived.conf'.
Missing '{' at beginning of configuration block
[...]
 chk_apache no match, ignoring...
```
Seems that the `{` is not limiting the identification of a section, but the 
section is anyway skipped.

My 2 cents,
Daniele

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

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

Versions of packages keepalived depends on:
ii  init-system-helpers  1.48
ii  iproute2 4.9.0-1+deb9u1
ii  libc62.24-11+deb9u3
ii  libip4tc01.6.0+snapshot20161117-6
ii  libip6tc01.6.0+snapshot20161117-6
ii  libnl-3-200  3.2.27-2
ii  libnl-genl-3-200 3.2.27-2
ii  libnl-route-3-2003.2.27-2
ii  libsnmp305.7.3+dfsg-1.7
ii  libssl1.11.1.0f-3+deb9u2
ii  libxtables12 1.6.0+snapshot20161117-6

Versions of packages keepalived recommends:
ii  ipvsadm  1:1.28-3+b1

keepalived suggests no packages.

-- no debconf information

Bug#909160: Still outdated example for otrs.SetPermissions.pl in README.Debian

[Stoklasa Radim]

Hi,
yesterday I was trying to get working buildin package manager in otrs
6.0.9-1~bpo9+1. I found two misleading information in README.Debian:

1) Wrong command line arguments used with otrs.SetPermissions.pl.
1a) There is no --otrs-group nor --web-user option available.
This was fixed in 6.0.11-1, thanx.

1b) Script doesn't expect path to OTRS installation folder.
However script doesn't report any errors (if directory is passed to the
command line) I think this should be fixed too.
This still remains incorrect in 6.0.11-1. 

2) Running otrs.SetPermissions.pl won't enable usage of buildin package
manager as advised in readme.
Script otrs.SetPermissions.pl refuses to follow symlinks (by design), so
content of directory /usr/share/otrs/var/ (pointing to /var/lib/otrs/) won't
get correct permissions. Therefore packages can't be correctly installed
from web interface (by www-data user). In my case, I had to change
permissions by hand on otrs/var/ tree.
Maybe providing patched version of otrs.SetPermissions.pl in Debian package
may solve this issue (I'm not familiar with perl, so I'm not able to provide
patch).

Best regards,
Radim

Bug#909696: lintian: debian-rules-should-not-use-custom-compression-settings overzealously also reports -Zgzip

[Axel Beckert]

Package: lintian
Version: 2.5.106

Hi,

according to the bugreport https://bugs.debian.org/829100 this tag was
primarily meant to catch too high xz compression settings. Also the
lintian long description seems to be targetted towards that case.

But this tag is also emitted on the rather conservative "-Zgzip" option
which is not that uncommon if you want to keep a package being able to
be installed on Debian Wheezy ELTS or Ubuntu 12.04 ESM (both are still
supported to some degree and have dpkg 1.16.x. And at least dpkg in
Wheezy has no xz support).

So IMHO this tag should not be emitted with legacy compression formats
like gzip or bzip2 (at least not with those which were default in the
past), just with too high (but not too low) xz compression settings or
more exotic (never having been default, like IIRC lzma) compression
formats.

I though see that explicitly using legacy compression formats
(especially bzip2 comes to my mind) may no more be supported in dpkg in
some future release, so it might be good to warn about that, too. But
that's by far less severe that too heavy xz compression settings.

So maybe this should be split up into two tags:

* too exotic/strong settings (warning level; current long desc.)
* conservative, maybe not future-proof settings which once were default
  (pedantic level; new long desc.)

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils   2.31.1-6
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.1
ii  file   1:5.34-2
ii  gettext0.19.8.1-7
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.39-1
ii  libdigest-sha-perl 6.02-1
ii  libdpkg-perl   1.19.1
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.74+repack-1
ii  man-db 2.8.4-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.26.2-7
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-6
ii  dpkg-dev   1.19.1
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.53-1

-- no debconf information

Bug#902981: fork-awesome

[Alexandre Viau]

> In case you didn't see it, their is a fork of font-awesome here:
> https://forkawesome.github.io/Fork-Awesome/
>
> It could perhaps solve DFSG potential problem ?

I have contacted the guys from forkawesome to ask about fontawesome v5 
compatibility:

 - https://github.com/ForkAwesome/Fork-Awesome/issues/112

Cheers,

--
Alexandre Viau
av...@debian.org

Bug#907740: webext-debianbuttons: significantly less convenient than the old xul-ext-debianbuttons

[Francesco Poli]

On Wed, 26 Sep 2018 11:17:02 + Damyan Ivanov wrote:

[...]
> -=| Francesco Poli, 02.09.2018 19:38:38 +0200 |=-
[...]
> > I cannot understand how to make the automatic paste happen.
> > 
> > If I select something and then hit [Ctrl+C], I still have to:
> > 
> >  * click on the Debian button in order to get a menu
> >  * paste the copied selection with [Ctrl+V] into the text field
> >  * click or right-click on one of the options
> 
> It is supposed to work like this (and works like this for me, under 
> GNOME/sid):
> 
>  * You select and copy e.g. a bug number
>  * Click on the Swirl in the browser (tried firefox and firefox-esr 
>from sid)
>- an automatic paste into the text input should happen

The automatic paste fails to work for me...

>  * click or middle-click (for opening in a new tab) on some of the 
>links in the window
> 
> > This looks even slower than the other, X-clipboard-based procedure
> 
> It is still slower, but at least there should not be any need to paste 
> via Ctrl+V
> 
> If the automated pasting does not work, I am not sure what the 
> extension can do - it only has access to the API, and if that works 
> here, maybe there is some difference in your environment.

Maybe this is due to the fact that I am using firefox-esr/52.9.0esr-1
on Debian testing...
I don't know, but I cannot upgrade to firefox-esr/60.2.1esr-1 from
Debian unstable, until some extensions get ported to webext and/or
replaced by webext ones included in Debian...

[...]
> > It would be great, if, at least, the extension could read the X
> > clipboard, without using the text field.
> > If this could be implemented, the text field could be completely
> > removed and the user could select some text and then:
> > 
> >  * click on the Debian button
> >  * click or right-click on one of the options
> > 
> > It would still require twice as many clicks as the pre-webext version,
> > but it could be considered acceptable...
> 
> I'd like to achieve this too :)
> I have opened a ticket in bugzilla: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1494266

Thanks a lot: I really hope the API will soon be enhanced!

Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpgACSio4czw.pgp
Description: PGP signature

Bug#907258: Bug#907259: Bug#907258: Bug#907259: Bug#907258: Bug#907259: hiredis: New upstream "release" ?

[Tom Lee]

Phew, done: https://github.com/thomaslee/hiredis-debian

Note because of the SONAME change / API & ABI breakage the binary package
name changed from libhiredis0.13 to libhiredis0.14. Can't recall exactly
how to handle that ... I was tempted to add Breaks/Replaces stanzas to
debian/control but thought better of it. Let me know if I need to take any
action there.

Otherwise it should be fine aside from a few gripes from the pedantic
lintian checks.

Cheers,
Tom

On Wed, Sep 26, 2018 at 1:21 AM Chris Lamb  wrote:

> Hi Tom,
>
> Great stuff.
>
> > Would you be willing to sponsor the upload when it's ready
>
> Gladly. Please either send me a HTTP-accessible link to a .dsc that works
> with "dget" or a pointer to a git-buildpackage repository when you are
> ready for me to have a look at this.
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#909516: cowpatty: Homepage field 404s

[Samuel Henrique]

Hello Chris,

> I just ACCEPTed cowpatty from NEW but was wondering if you could fix
> the Homepage: field which does not work for me:

Just committed the fix, will do a new upload as soon as it hits
testing, thanks for catching that.

-- 
Samuel Henrique 

Bug#909672:

[H.-Dirk Schmitt]

Using now friendly-recovers from buster via pinning.
As expected the root partition is now remounted read-write.

Bug#909180: mozjs60: Please build with -mlra on sh4

[Simon McVittie]

Control: tags -1 = patch pending

On Wed, 26 Sep 2018 at 09:15:43 +0200, John Paul Adrian Glaubitz wrote:
> On 9/26/18 8:41 AM, Simon McVittie wrote:
> >> Could you merge this change, please? mozjs60 was still built without
> >> -mlra on sh4.
> > 
> > If the resulting binaries work, I'm happy to merge it. Do they?
> 
> Yes, they do.

Thanks, patch applied in git.

smcv

Bug#886081: Patch

[Yavor Doganov]

tags 886081 + patch
thanks

This package doesn't use gconf but ends up linking with it as GNOME
libraries expose their dependencies and enforce overlinking via their
.pc files.  Attached is a simple solution; you need to bump the
debhelper compat level at least to 9 so that it works.
--- gbatnav-1.0.4cvs20051004.orig/debian/rules
+++ gbatnav-1.0.4cvs20051004/debian/rules
@@ -5,6 +5,10 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+# Trim unnecessary dependencies that result from overlinking.  Fixes
+# #886081 although this bug should be fixed by the patch for #868382.
+export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
+
 %:
dh $@ --with autoreconf
 

Bug#909695: firefox-esr-l10n-el: https://www.plaisio.gr/search.aspx?query=epson%2027 (error 500)

[ΑΘΑΝΑΣΙΟΣ]

Package: firefox-esr-l10n-el
Version: 60.2.1esr-1~deb9u1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

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

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

The tab is from the last use and when I opened it I did not finish it. This has
done almost all the tabs in the latest updates. Now the problem is less.



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

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

Versions of packages firefox-esr-l10n-el depends on:
ii  firefox-esr  60.2.1esr-1~deb9u1

Versions of packages firefox-esr-l10n-el recommends:
ii  myspell-el-gr  0.9-1

firefox-esr-l10n-el suggests no packages.

-- no debconf information

Bug#868382: gbatnav: Port to GTK+ 3

[Yavor Doganov]

tags 868382 + patch
thanks

Attached is a patch which fixes this bug.  You only have to replace
libgnome2-dev and libgnomeui-dev in Build-Depends with
libgoocanvas-2.0-dev.
Description: Port to GTK+ 3.
 Migrate from libpopt to GOption.
 Migrate frome GnomeCanvas to GooCanvas.
 Migrate from old-style ~/.gnome2 configuration files to GSettings.
Bug-Debian: https://bugs.debian.org/868382
Author: Yavor Doganov 
Forwarded: no
Last-Update: 2018-09-26
---

--- gbatnav-1.0.4cvs20051004.orig/configure.in
+++ gbatnav-1.0.4cvs20051004/configure.in
@@ -12,13 +12,14 @@
 AC_HEADER_STDC
 AC_ARG_PROGRAM
 
-PKG_CHECK_MODULES(GNOME,[libgnomeui-2.0])
+PKG_CHECK_MODULES(GNOME,[goocanvas-2.0])
 AC_SUBST(GNOME_CFLAGS)
 AC_SUBST(GNOME_LIBS)
 
 ALL_LINGUAS="es de pl ja ru fr sv"
 AM_GNU_GETTEXT
 
+GLIB_GSETTINGS
 
 dnl DATADIRNAME is generated by AM_GNU_GETTEXT; 
 dnl note this has to match the path installed by po/Makefile
--- gbatnav-1.0.4cvs20051004.orig/gbnserver/g_interface.h
+++ gbatnav-1.0.4cvs20051004/gbnserver/g_interface.h
@@ -4,7 +4,6 @@
 #define __BN_G_INTERFACE_H__
 
 #include 
-#include 
 #include "protocol.h"
 
 void init_screen();
--- gbatnav-1.0.4cvs20051004.orig/gbnserver/gbnserver.c
+++ gbatnav-1.0.4cvs20051004/gbnserver/gbnserver.c
@@ -30,7 +30,9 @@
 
 /* Includes de la interface */
 #include 
-#include 
+#include 
+#include 
+#include 
 
 #include "protocol.h"  /* definicion del protocolo */
 #include "server.h"
@@ -58,21 +60,54 @@
 extern struct { char *nombre; } st_nombres[];
 
 /* This describes all the arguments we understand.  */
-static struct poptOption options[] =
+static GOptionEntry options[] =
 {
-   { "port", 'p', POPT_ARG_INT, , 0,  N_("PORT"), N_("Port 
number. Default is 1995")},
+   { "port", 'p', G_OPTION_FLAG_NONE, G_OPTION_ARG_INT, , 
N_("Port number. Default is 1995"), N_("PORT")},
 #ifdef WITH_GGZ
-   { "ggz", 0, POPT_ARG_NONE, _ggz, 0,  NULL, N_("Enables GGZ 
mode")},
+   { "ggz", 0, G_OPTION_FLAG_NONE, G_OPTION_ARG_NONE, _ggz, 
N_("Enables GGZ mode"), NULL},
 #endif /* WITH_GGZ */
-   { NULL, '\0',  0, NULL  }
+   { NULL }
 };
 
-void init_args( void )
+
+/* Migrate old settings from ~/.gnome2/gbnserver.  */
+static void migrate_old_settings( GSettings *settings )
 {
-   usuario.port = 
gnome_config_get_int_with_default("/gbnserver/data/port=1995",NULL);
+   GKeyFile *kf;
+   gchar *file;
+
+   kf = g_key_file_new();
+   file = g_build_filename(g_get_home_dir(), ".gnome2",
+   "gbnserver", NULL);
+   if(g_key_file_load_from_file(kf, file, G_KEY_FILE_NONE, NULL)) {
+   gchar **groups;
+   gsize len;
+
+   /* File exists but if the user never changed the
+  settings it will contain only the Placement section
+  (automatically created internal Bonobo stuff).  */
+   groups = g_key_file_get_groups(kf, );
+   if(len > 1) {
+   gint i;
+
+   i = g_key_file_get_integer(kf, "data", "port", NULL);
+   g_settings_set_uint(settings, "port", i);
+   fprintf(stdout,
+   _("Sucessfully migrated old settings.\n"));
+} else
+   fprintf(stdout,
+   _("Found empty old config file; deleted.\n"));
+
+   g_strfreev(groups);
+   g_unlink(file);
+   }
+   g_free(file);
+   g_key_file_free(kf);
+}
 
-   gnome_config_set_int("/gbnserver/data/port",usuario.port);
-   gnome_config_sync();
+void init_args( GSettings *settings )
+{
+   usuario.port = g_settings_get_uint(settings, "port");
 }
 /***
funciones relacionadas con las tablas 
@@ -116,7 +151,7 @@
 void borrar_jugador( int num_jug )
 {
if( ! usuario.with_ggz )
-   gdk_input_remove( usuario.tag[num_jug] );
+   g_source_remove( usuario.tag[num_jug] );
 #ifdef WITH_GGZ
else
batnavggz_del_fd(usuario.nro_fd[num_jug]);
@@ -325,31 +360,36 @@
return BATNAV_STATUS_SUCCESS;
 }
 
-void ex_loop( gpointer data, gint que_sock, GdkInputCondition GDK_INPUT_READ)
+gboolean ex_loop( GIOChannel *src, GIOCondition cond, gpointer data )
 {
-   int i,j,k,client_len;
+   guint i;
+   int j,que_sock,client_len;
 char str[150];
 struct sockaddr client;
+GIOChannel *channel;
 
client_len = sizeof(client);
-   k = que_sock;
+   que_sock = g_io_channel_unix_get_fd(src);

if( que_sock==usuario.sock ) { /* AF_INET */
if( (que_sock=accept(usuario.sock, (struct sockaddr *) 
,_len)) < 0 ) {
perror("accept error");
-   return;
+   return FALSE;
} 
}
 
if( 

Bug#807425: gbatnav: Segmentation fault when trying to play locally against a robot

[Yavor Doganov]

tags 807425 + patch
thanks

On Wed, Dec 09, 2015 at 01:55:27AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> Andrej Mernik 於 2015年12月09日 01:18 寫道:
> > Package: gbatnav
> > Version: 1.0.4cvs20051004-5
> > Severity: important

> > gbnclient keeps crashing when trying to play a game with a robot:
> > 
> > gbnclient: Error in buscar_usr: usr=0
> > gbnrobot: robot 1: que_usrfrom: Error, aca no tendria que llegar
> > Segmentation fault

> There is a bug. Actually several bugs.

Actually, it's only one bug.  According to the C standard and the
glibc manual, the behavior of strncpy is undefined if strings
overlap.  So this worked by chance with older toolchain versions,
most probably only on certain set of architectures.
Attached is a patch which fixes the problem for me.  I also noticed
(unrelated) buffer overflow which is also addressed by the patch.

> But this bug is not a single bug.
> 1. gbnclient crashes.
> 2. gbnrobot sends weird board layout.
> 3. gbnserver non sync.

This happens because both buscar_usr and que_usrfrom perform
consistency checks but the program continues execution instead of
exiting immediately with a proper error message.
Description: Fix crash when playing locally against a robot.
 Also fix buffer overflow in gbnserver.
Bug-Debian: https://bugs.debian.org/807425
Author: Yavor Doganov 
Forwarded: no
Last-Update: 2018-09-20
---

--- gbatnav-1.0.4cvs20051004.orig/common/parser.c
+++ gbatnav-1.0.4cvs20051004/common/parser.c
@@ -85,7 +85,7 @@
 		p_in->status=TRUE;
 		return FALSE;
 	case PARSER_SEPARADOR:
-		strncpy(p_in->sig, _in->sig[k+1], sizeof(p_in->sig) );
+		memmove(p_in->sig, _in->sig[k+1], sizeof(p_in->sig) );
 		p_in->status=TRUE;
 		return TRUE;
 	case PARSER_IGUAL:
@@ -93,7 +93,7 @@
 			return FALSE;
 		if(j==PARSER_IGUAL || j==PARSER_SEPARADOR )
 			k++;
-		strncpy(p_in->sig, _in->sig[k2+k+1],sizeof(p_in->sig) );
+		memmove(p_in->sig, _in->sig[k2+k+1],sizeof(p_in->sig) );
 		if( j==PARSER_ERROR || j==PARSER_IGUAL )
 			return FALSE;
 		p_in->status=TRUE;	/* hasta aca todo fue bien leido */
--- gbatnav-1.0.4cvs20051004.orig/gbnserver/gbnserver.c
+++ gbatnav-1.0.4cvs20051004/gbnserver/gbnserver.c
@@ -366,7 +366,7 @@
  */
 void main_loop()
 {
-usuario.sock = net_listen(NULL,usuario.port);
+usuario.sock = net_listen(usuario.server_name,usuario.port);
 	
 	init_screen();
 
@@ -399,7 +399,7 @@
 	if( ! usuario.with_ggz)
 		gnome_init_with_popt_table("gbnserver", BNVERSION, argc, argv, options,0, NULL);
 
-	gethostname(usuario.server_name,PROT_MAX_LEN);
+	gethostname(usuario.server_name,50);

 	printf( "\n"
 		BNVERSION"\n" 

Bug#909694: reprotest: please export DEB_BUILD_OPTIONS=reproducible=+all

[Holger Levsen]

Package: reprotest
Version: 0.7.8
Severity: important

Dear Maintainer,

< KGB-1> | Mattia Rizzolo master 4860753 jenkins.debian.net  
bin/reproducible_build.sh * https://deb.li/v57l
< KGB-1> reproducible debian: enable all the reproducible-related build flags 
 from dpkg, by export DEB_BUILD_OPTIONS=reproducible=+all
 https://deb.li/3oWVI
[22:44] <  h01ger> | mapreri: re: 4860753: shouldt this also be done for 
reprotest?
[22:45]  | h01ger: possibly indeed yes :)


cheers,
Holger

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#909693: gpgsm: seems to be dead slow when verifying pkcs7-signatures from within Sylpheed

[Francesco Poli (wintermute)]

Package: gpgsm
Version: 2.2.10-1
Severity: important

Hello!

I installed the gpgsm package, in order to verify pkcs7-signatures
in e-mail messages from within Sylpheed.

The combination seems to work, as it is actually able to verify
a signature, as in:

[application/pkcs7-signature (Valid signature (untrusted key))]
Signature made at $DATE
Valid signature but the key for "CN=$CN,O=$O,L=$L,ST=$ST,C=$C" is not trusted
  aka ""

The problem is: it has always been dead slow in doing so.
And it still is.
I cannot understand why.

While verifying an OpenPGP signature with gpg is definitely fast,
verifying a pkcs7-signature with gpgsm is super slow.
And it is slow again *each and every* time I verify the signature
on the same message.
And it blocks Sylpheed during the wait.


Is there anything I should have configured in order to speed up
gpgsm?
I did search the man page, but nothing looks appropriate to me
(probably out of ignorance!).

Could you please help me?
Thanks for your time and patience.
Bye.


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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gpgsm depends on:
ii  gpgconf2.2.10-1
ii  libassuan0 2.5.1-2
ii  libc6  2.27-6
ii  libgcrypt201.8.3-1
ii  libgpg-error0  1.32-1
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-5

Versions of packages gpgsm recommends:
ii  gnupg  2.2.10-1

gpgsm suggests no packages.

-- no debconf information

Bug#909689: asterisk: autopkgtest regression

[Bernhard Schmidt]

Control: severity -1 serious

Am 26.09.18 um 21:51 schrieb Bernhard Schmidt:
> Am 26.09.18 um 20:48 schrieb Paul Gevers:
> 
> Hi Paul,
> 
>> With a recent upload of asterisk the autopkgtest of asterisk fails in
>> testing when that autopkgtest is run with the binary packages of
>> asterisk from unstable. It passes when run with only packages from
>> testing. In tabular form:
>>passfail
>> asterisk   from testing1:13.23.1~dfsg-1
>> all others from testingfrom testing
>>
>> I copied some of the output at the bottom of this report. It seems that
>> the test passes in the sense that the exit code is still 0 (is that
>> correct?). However, there is output on stderr which is treated as an
>> error. Ideally the output to stderr should be fixed, but otherwise
>> adding a allow-stderr restriction to the test definition will make sure
>> this output is ignored.
> 
> We're aware of this, thanks.
> 
> The autopkgtest shows a real regression. The testsuite itself appears
> fine, but when getting the results and stopping asterisk in the end we get
> 
>> Unable to connect to remote asterisk (does
>> /var/run/asterisk/asterisk.ctl exist?)
>> Unable to connect to remote asterisk (does
>> /var/run/asterisk/asterisk.ctl exist?)
> 
> Which means asterisk already quit.

So, asterisk is really segfaulting inside autopkgtest :-O

Sep 26 20:21:50 debian asterisk[2658]: radcli: rc_read_config:
rc_read_config: can't open /etc/radiusclient-ng/radiusclient.conf: No
such file or directory
Sep 26 20:21:50 debian asterisk[2658]: radcli: rc_read_config:
rc_read_config: can't open /etc/radiusclient-ng/radiusclient.conf: No
such file or directory
[...]
Sep 26 20:24:57 debian kernel: asterisk[3124]: segfault at 0 ip
7f88fff90dab sp 7f88c81a8080 error 4 in
libc-2.27.so[7f88ffeac000+146000]

I don't know how much time I'll have to check on this in the next days.
Raising severity to block testing migration for now.

Bernhard

Bug#903393: Unknown X keysym "dead_belowmacron"

[Esokrates]

I can also reproduce ths with a German keyboard (XPS 13 9360).

Bug#909692: glabels: Fails to merge data when char is unsigned

[Lisandro Damián Nicanor Pérez Meyer]

Source: glabels
Version: 3.4.0-2
Severity: important
Tags: patch upstream

Hi! glabels 3.4.0 suffers a problem with the use of chars on architectures that
consider it unsigned like armhf. In this cases if a user tries to merge data
to create labels it will start consuming memory until GLib stops it.

Upstream released 4.0.1 which fixes this and other issues. Ideally this version
should reach buster and stretch's one should be patched with the relevant 
changes.

I am considering doing 15 days NMUs in 5 days if time allows me and have no 
reply for
this bug in the meantime.

Kinds regards, Lisandro.

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#909689: asterisk: autopkgtest regression

[Bernhard Schmidt]

Am 26.09.18 um 20:48 schrieb Paul Gevers:

Hi Paul,

> With a recent upload of asterisk the autopkgtest of asterisk fails in
> testing when that autopkgtest is run with the binary packages of
> asterisk from unstable. It passes when run with only packages from
> testing. In tabular form:
>passfail
> asterisk   from testing1:13.23.1~dfsg-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. It seems that
> the test passes in the sense that the exit code is still 0 (is that
> correct?). However, there is output on stderr which is treated as an
> error. Ideally the output to stderr should be fixed, but otherwise
> adding a allow-stderr restriction to the test definition will make sure
> this output is ignored.

We're aware of this, thanks.

The autopkgtest shows a real regression. The testsuite itself appears
fine, but when getting the results and stopping asterisk in the end we get

> Unable to connect to remote asterisk (does
> /var/run/asterisk/asterisk.ctl exist?)
> Unable to connect to remote asterisk (does
> /var/run/asterisk/asterisk.ctl exist?)

Which means asterisk already quit.

Looking into it.

Bernhard

Bug#883763: Bug #883763 in python-social-auth marked as pending

[Petter Reinholdtsen]

[Chris Lamb]
> I'm still a little confused. It was surely the same effort to remove?

Nah, as the files now "excluded" (and the ones initially requested to
exclude) were already missing from the orig tarball, so I did not have
to repack.

I saw no point in repacking the tarball to get rid of files that were
not present in the current tarball.

> And, as I highlight above, a new version might contain different files
> in this directory?

Sure.  But the solution was to get rid of minimized javascript files,
and the updated rule should match any new ones if they should show up at
a later point in time.

-- 
Happy hacking
Petter Reinholdtsen

Bug#717584: /boot/initrd.img-*.old-dkms files left behind

[Eduard Bloch]

Package: dkms
Version: 2.6.1-1
Control: severity 717584 important
Followup-For: Bug #717584

Today my /boot partition once again run full because of DKMS's pile of
carbage remaining there. The issue is FIVE YEARS OLD. Is there any plan
to fix this still in this decade?

Regards,
Eduard.

Bug#909691: mcron: provide cron-daemon

[Matthew Moore]

Package: mcron
Severity: wishlist

Hi,

mcron currently does not provide cron-daemon, even though mcron can be
used to replace cron. It would be nice to have this supported so that
removing cron doesn't cause unresolved dependencies.

MM

Bug#909690: pylint breaks pylint-django autopkgtest

[Paul Gevers]

Source: pylint, pylint-django
Control: found -1 pylint/2.1.1-1
Control: found -1 pylint-django/0.11-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of pylint the autopkgtest of pylint-django fails in
testing when that autopkgtest is run with the binary packages of pylint
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
pylint from testing2.1.1-1
pylint-django  from testing0.11-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. Because of the
versioned deps that need installing, it is possible that that triggers
the failure. I have scheduled a test with only astroid from unstable.

Currently this regression is contributing to the delay of the migration
of pylint to testing [1]. Due to the nature of this issue, I filed this
bug report against both packages. Can you please investigate the
situation and reassign the bug to the right package? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
pylint/2.1.1-1. I.e. due to versioned dependencies or breaks/conflicts.
In this case it added src:astroid.
[1] https://qa.debian.org/excuses.php?package=pylint

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pylint-django/1055531/log.gz

autopkgtest [05:25:38]: test unit-tests-p3: [---
Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/pylint_django/tests/test_func.py", line
9, in 
import test_functional  # noqa: E402
ModuleNotFoundError: No module named 'test_functional'
autopkgtest [05:25:38]: test unit-tests-p3: ---]


autopkgtest [05:26:16]: test django-sample: [---
Running “django-admin startproject testproject”
Running “django-admin startapp testapp”
Running “pylint3 --version”
pylint3 2.1.1
astroid 2.0.4
Python 3.6.6 (default, Jun 27 2018, 14:44:17)
[GCC 8.1.0]
Running “pylint3 -E --load-plugins=pylint_django testapp/”
Traceback (most recent call last):
  File "/usr/bin/pylint3", line 11, in 
load_entry_point('pylint==2.1.1', 'console_scripts', 'pylint')()
  File "/usr/lib/python3/dist-packages/pylint/__init__.py", line 19, in
run_pylint
Run(sys.argv[1:])
  File "/usr/lib/python3/dist-packages/pylint/lint.py", line 1315, in
__init__
linter.load_plugin_modules(self._plugins)
  File "/usr/lib/python3/dist-packages/pylint/lint.py", line 519, in
load_plugin_modules
module = modutils.load_module_from_name(modname)
  File "/usr/lib/python3/dist-packages/astroid/modutils.py", line 196,
in load_module_from_name
return load_module_from_modpath(dotted_name.split('.'), path, use_sys)
  File "/usr/lib/python3/dist-packages/astroid/modutils.py", line 239,
in load_module_from_modpath
module = imp.load_module(curname, mp_file, mp_filename, mp_desc)
  File "/usr/lib/python3.6/imp.py", line 245, in load_module
return load_package(name, filename)
  File "/usr/lib/python3.6/imp.py", line 217, in load_package
return _load(spec)
  File "", line 684, in _load
  File "", line 665, in _load_unlocked
  File "", line 678, in exec_module
  File "", line 219, in
_call_with_frames_removed
  File "/usr/lib/python3/dist-packages/pylint_django/__init__.py", line
7, in 
from pylint_django import plugin
  File "/usr/lib/python3/dist-packages/pylint_django/plugin.py", line 9,
in 
from pylint_django import transforms  # noqa, pylint:
disable=unused-import
  File
"/usr/lib/python3/dist-packages/pylint_django/transforms/__init__.py",
line 12, in 
foreignkey.add_transform(MANAGER)
  File
"/usr/lib/python3/dist-packages/pylint_django/transforms/foreignkey.py",
line 59, in add_transform
manager.register_transform(nodes.CallFunc,
inference_tip(infer_key_classes),
AttributeError: module 'astroid.nodes' has no attribute 'CallFunc'
autopkgtest [05:26:18]: test django-sample: ---]



signature.asc
Description: OpenPGP digital signature

Bug#909689: asterisk: autopkgtest regression

[Paul Gevers]

Source: asterisk
Version: 1:13.23.1~dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of asterisk the autopkgtest of asterisk fails in
testing when that autopkgtest is run with the binary packages of
asterisk from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
asterisk   from testing1:13.23.1~dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems that
the test passes in the sense that the exit code is still 0 (is that
correct?). However, there is output on stderr which is treated as an
error. Ideally the output to stderr should be fixed, but otherwise
adding a allow-stderr restriction to the test definition will make sure
this output is ignored.

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=asterisk

https://ci.debian.net/data/autopkgtest/testing/amd64/a/asterisk/1055707/log.gz

494 Test(s) Executed  494 Passed  0 Failed
Unable to connect to remote asterisk (does
/var/run/asterisk/asterisk.ctl exist?)
Some test modules were not loaded:
0a1,69
> test_abstract_jb.so
> test_acl.so
> test_amihooks.so
> test_aoc.so
> test_app.so
> test_ari.so
> test_ari_model.so
> test_ast_format_str_reduce.so
> test_astobj2.so
> test_astobj2_thrash.so
> test_bridging.so
> test_bucket.so
> test_callerid.so
> test_cdr.so
> test_cel.so
> test_channel_feature_hooks.so
> test_config.so
> test_core_codec.so
> test_core_format.so
> test_db.so
> test_devicestate.so
> test_dlinklists.so
> test_endpoints.so
> test_event.so
> test_expr.so
> test_file.so
> test_format_cache.so
> test_format_cap.so
> test_func_file.so
> test_gosub.so
> test_hashtab_thrash.so
> test_heap.so
> test_jitterbuf.so
> test_json.so
> test_linkedlists.so
> test_locale.so
> test_logger.so
> test_message.so
> test_named_lock.so
> test_netsock2.so
> test_optional_api.so
> test_pbx.so
> test_poll.so
> test_res_pjsip_scheduler.so
> test_res_stasis.so
> test_sched.so
> test_scoped_lock.so
> test_security_events.so
> test_skel.so
> test_sorcery.so
> test_sorcery_astdb.so
> test_sorcery_memory_cache_thrash.so
> test_sorcery_realtime.so
> test_stasis.so
> test_stasis_channels.so
> test_stasis_endpoints.so
> test_stringfields.so
> test_strings.so
> test_substitution.so
> test_taskprocessor.so
> test_threadpool.so
> test_time.so
> test_uri.so
> test_utils.so
> test_uuid.so
> test_vector.so
> test_voicemail_api.so
> test_websocket_client.so
> test_xml_escape.so
Manually disabled:
test_message
test_cel

Some tests failed:

Unable to connect to remote asterisk (does
/var/run/asterisk/asterisk.ctl exist?)
Unable to connect to remote asterisk (does
/var/run/asterisk/asterisk.ctl exist?)
autopkgtest [08:34:32]: test asttestmods: ---]
autopkgtest [08:34:32]: test asttestmods:  - - - - - - - - - - results -
- - - - - - - - -
asttestmods  FAIL stderr: Unable to connect to remote asterisk
(does /var/run/asterisk/asterisk.ctl exist?)
autopkgtest [08:34:32]: test asttestmods:  - - - - - - - - - - stderr -
- - - - - - - - -
Unable to connect to remote asterisk (does
/var/run/asterisk/asterisk.ctl exist?)
Some tests failed:

Unable to connect to remote asterisk (does
/var/run/asterisk/asterisk.ctl exist?)
Unable to connect to remote asterisk (does
/var/run/asterisk/asterisk.ctl exist?)



signature.asc
Description: OpenPGP digital signature

Bug#864082: fontconfig: please make the cache files reproducible

[Chris Lamb]

Hi Sven,

> It does:

Mea culpa; I was looking at 2.13.0-1, not 2.13.1-1. Thanks!


Regards,

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

Bug#864082: fontconfig: please make the cache files reproducible

[Sven Joachim]

On 2018-09-26 19:24 +0100, Chris Lamb wrote:

> Hi Sven,
>
>> It seems that 2.13.1-1 was that release, can you confirm that?
>
> Thanks for chiming in.
>
> Given that this version does not contain the string SOURCE_DATE_EPOCH,

It does:

,
| $ grep -n SOURCE_DATE_EPOCH **/*
| doc/fontconfig-user.html:1549:>SOURCE_DATE_EPOCHSOURCE_DATE_EPOCHSOURCE_DATE_EPOCHSOURCE_DATE_EPOCH
| doc/fontconfig-user.sgml:807:is used to ensure fc-cache(1) 
generates files in a deterministic manner in order to support reproducible 
builds. When set to a numeric representation of UNIX timestamp, fontconfig will 
prefer this value over using the modification timestamps of the input files in 
order to identify which cache files require regeneration. If 
SOURCE_DATE_EPOCH is not set (or is newer than the mtime of 
the directory), the existing behaviour is unchanged.
| doc/fontconfig-user.sgml:812:fc-cat(1), fc-cache(1), fc-list(1), fc-match(1), 
fc-query(1), https://reproducible-builds.org/specs/source-date-epoch/;>SOURCE_DATE_EPOCH.
| doc/fontconfig-user.txt:790:   SOURCE_DATE_EPOCH is used to ensure 
fc-cache(1) generates files in a
| doc/fontconfig-user.txt:794:   to identify which cache files require 
regeneration. If SOURCE_DATE_EPOCH
| doc/fontconfig-user.txt:801:   [3]SOURCE_DATE_EPOCH.
| doc/fonts-conf.5:756:\fBSOURCE_DATE_EPOCH\fR
| doc/fonts-conf.5:757:is used to ensure fc-cache(1) generates files in a 
deterministic manner in order to support reproducible builds. When set to a 
numeric representation of UNIX timestamp, fontconfig will prefer this value 
over using the modification timestamps of the input files in order to identify 
which cache files require regeneration. If SOURCE_DATE_EPOCH is not set (or is 
newer than the mtime of the directory), the existing behaviour is unchanged.
| doc/fonts-conf.5:760:fc-cat(1), fc-cache(1), fc-list(1), fc-match(1), 
fc-query(1), SOURCE_DATE_EPOCH 
https://reproducible-builds.org/specs/source-date-epoch/>\&.
| src/fccache.c:1079:source_date_epoch = getenv("SOURCE_DATE_EPOCH");
| src/fccache.c:1086:  "Fontconfig: SOURCE_DATE_EPOCH 
invalid\n");
| src/fccache.c:1090:  "Fontconfig: SOURCE_DATE_EPOCH: 
strtoull: %s: %llu\n",
| src/fccache.c:1094:  "Fontconfig: SOURCE_DATE_EPOCH has 
trailing garbage\n");
| src/fccache.c:1097:  "Fontconfig: SOURCE_DATE_EPOCH must be 
<= %lu but saw: %llu\n",
| src/fccache.c:1112:if (getenv("SOURCE_DATE_EPOCH"))
`

Did you look at the git repository on salsa.debian.org?  It only
contains the debian/ directory, so SOURCE_DATE_EPOCH does indeed not
show up there…

Cheers,
   Sven

Bug#909602: mailmanclient causes python3-mailman-hyperkitty and mailman3-web to fail to install in buster

[Paul Gevers]

Hi

On Tue, 25 Sep 2018 21:33:18 +0200 Paul Gevers  wrote:
> If the right binary package(s) from mailmanclient would have had a
> versioned Breaks on the broken versions of mailman3-web and
> python3-mailman-hyperkitty this could have been prevented.

I forgot, and thus forgot to mention, that it is possible that a (test)
dependency is missing that is pulled in via dependencies. I couldn't
spot yet which package that would be. If the dependency is available in
buster, the bug can quickly and simply be fixed by a new upload of
mailmanclient.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#909688: s-nail: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: s-nail 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of s-nail debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#909687: aptitude: [INTL:nl] Dutch po file for the aptitude package

[Frans Spiesschaert]

 
 
Package: aptitude 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the aptitude
package. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#909686: wxhexeditor FTCBFS: *** No rule to make target '-ldisasm'

[Helmut Grohne]

Source: wxhexeditor
Version: 0.23+repack-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

wxhexeditor fails to cross build from source, because it cannot resolve
-ldisasm as a Makefile dependency. This is due to a make feature that is
not that widely known: When you put -lfoo into a dependency, make will
try to resolve that using its built-in library search path. That search
path is for the build architecture and -ldisasm is only installed for
the host architecture, thus it fails. It doesn't make much sense to have
that dependency in the first place though, since there is no rule to
create or update it. Simply dropping it fixes the cross build. Please
consider applying the attached patch.

Helmut
From: Helmut Grohne 
Subject: fix makefile dependencies for cross building

When putting -lsomething on a makefile dependency, make will search for that
library in the system library search path. For cross compilation, that library
will generally not be present. Since the builder is responsible for ensuring
its presence, we simply remove such libraries from dependencies.

Index: wxhexeditor-0.23+repack/Makefile
===
--- wxhexeditor-0.23+repack.orig/Makefile
+++ wxhexeditor-0.23+repack/Makefile
@@ -41,14 +41,14 @@
 
 all:$(EXECUTABLE) langs
 
-$(OBJECTS): $(LIBS) $(SOURCES)
+$(OBJECTS): $(SOURCES)
 
 MOBJECTS=$(LANGUAGES:.po=.mo)
 
 $(EXECUTABLE): $(OBJECTS)
 	$(CXX) ${CXXFLAGS} ${CPPFLAGS} $(OBJECTS) $(LIBS) $(WXLDFLAGS) ${LDFLAGS} -o $@
 
-.cpp.o: $(LIBS)
+.cpp.o:
 	$(CXX) -c $(CXXFLAGS) $(CPPFLAGS) $(WXCXXFLAGS) $< -o $@
 
 %.o : %.rc

Bug#909684: dump1090-mutability: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: dump1090-mutability 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of dump1090-
mutability debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#909685: openstack-pkg-tools: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: openstack-pkg-tools 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of openstack-pkg-
tools debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#864082: fontconfig: please make the cache files reproducible

[Chris Lamb]

Hi Sven,

> It seems that 2.13.1-1 was that release, can you confirm that?

Thanks for chiming in.

Given that this version does not contain the string SOURCE_DATE_EPOCH,
this was probably another release and/or this should remain open.


Regards,

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

Bug#909683: fusiondirectory: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: fusiondirectory 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of fusiondirectory
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#864082: fontconfig: please make the cache files reproducible

[Sven Joachim]

On 2018-05-18 08:42 +0100, Chris Lamb wrote:

> Hi,
>
>> fontconfig: please make the cache files reproducible
>
> This was merged into the upstream Git repository - would it be
> possible to make another Debian release with this change? :)

It seems that 2.13.1-1 was that release, can you confirm that?

Just flying by - apparently the new fontconfig upstream release has
fixed several bugs in the BTS, but the Debian changelog did not mention
any.

Cheers,
   Sven

Bug#901221: closed by Patrick Matthäi (Bug#901221: fixed in manaplus 1.8.9.1-1)

[Helmut Grohne]

Control: reopen -1

On Thu, Sep 20, 2018 at 10:54:03AM +, Debian Bug Tracking System wrote:
>* New upstream release.
>  - Fixes FTCBFS: uses the build architecture pkg-config.
>Closes: #901221

The issue is still present. The patch still applies.

Helmut

Bug#897040: bug 897040 is forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=106632

[Sven Joachim]

On 2018-05-23 16:43 +0200, Laurent Bigonville wrote:

> forwarded 897040 https://bugs.freedesktop.org/show_bug.cgi?id=106632

That upstream bug has been fixed in commit f5dd851[1] which is included
in fontconfig 2.13.1, so I think the Debian bug should be closed too.
Haven't tested whether the fix works, though.

Cheers,
   Sven


1. 
https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/f5dd8512bdf9fd8e01c30ae36f593758b29385cf

Bug#909682: Memory leak with gst_tag_list_add_id3_image

[Anthony DeRobertis]

Package: clementine
Version: 1.3.1+git565-gd20c2244a+dfsg-1
Severity: normal

I'm not sure if this is a Clementine bug or a Gstreamer bug, but I've
noticed that when I leave Clementine running for a bit, its memory usage
grows massive (many GiB). I'm playing almost exlusively FLAC files,
which all have (fairly large) embedded artwork, multiple images per
file.

I used heaptrack to attempt to track down where the memory leak is. This
is after only a day or two of use:

MEMORY LEAKS
857.27MB leaked over 2418654 calls from
g_malloc
  in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
826.58MB leaked over 1941 calls from:
g_slice_alloc
  in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0x7fe9ca6e49d0
  in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
gst_buffer_new_allocate
  in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
gst_tag_image_data_to_image_sample
  in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0
gst_tag_list_add_id3_image
  in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0
0x7fe994f1ca1f
  in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstaudioparsers.so
0x7fe9ca8116b1
  in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
0x7fe9ca811d8e
  in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
0x7fe9ca815301
  in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
0x7fe9ca75df40
  in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
0x7fe9ca8ddad2
  in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0x7fe9ca8dd134
  in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
start_thread
  in /lib/x86_64-linux-gnu/libpthread.so.0
__clone
  in /lib/x86_64-linux-gnu/libc.so.6

I have no idea why that backtrace doesn't show any Clementine code in
it. I tried installing some more -dbg/-dbgsym packages, but maybe I had
to do it before starting Clementine.

Note this is the main clementine process, not the tagreader processes:

$ ps u | sed -e '1p;/[c]lementine/!d'
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
anthony  15944  0.5  6.6 4407604 1650488 pts/4 Sl+  Sep24  16:30 clementine
anthony  15956  0.0  0.1 276992 37368 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-631367825
anthony  15958  0.0  0.1 276992 39392 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-792921086
anthony  15959  0.0  0.1 276992 37676 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1767394138
anthony  15963  0.0  0.1 276988 37340 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1468073315
anthony  15967  0.0  0.1 276988 37492 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1581559023
anthony  15968  0.0  0.1 276992 37624 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1038521661
anthony  15969  0.0  0.1 276992 39180 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1682697807
anthony  15970  0.0  0.1 276992 37908 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-391160903


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

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

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.14.3-2
ii  gstreamer1.0-plugins-good   1.14.3-1
ii  gstreamer1.0-plugins-ugly   1.14.3-1
ii  libc6   2.27-6
ii  libcdio18   1:2.0.0-dmo2
ii  libchromaprint1 1.4.3-2+b1
ii  libcrypto++65.6.4-8
ii  libfftw3-double33.3.8-2
ii  libgcc1 1:8.2.0-7
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgpod40.8.3-13
ii  libgstreamer-plugins-base1.0-0  1.14.3-2
ii  libgstreamer1.0-0   1.14.3-1
ii  libimobiledevice6   1.2.1~git20180302.3a37a4e-1
ii  liblastfm5-11.0.9-1
ii  libmtp9 1.1.13-1
ii  libmygpo-qt5-1  1.1.0-2
ii  libplist3   2.0.0-5
ii  libprojectm2v5  2.1.0+dfsg-4+b3
ii  libprotobuf10   3.0.0-9.1
ii  libpulse0   12.2-2
ii  libqt5concurrent5   5.11.1+dfsg-8
ii  libqt5core5a5.11.1+dfsg-8
ii  libqt5dbus5 5.11.1+dfsg-8
ii  libqt5gui5  5.11.1+dfsg-8
ii  libqt5network5  5.11.1+dfsg-8
ii  libqt5opengl5   

Bug#894074: uscan is failing to repack gitlab from last 2 versions

[Xavier]

Le 26/09/2018 à 18:26, Emmanuel Bourg a écrit :
> I got the same issue with some big eclipse packages. I worked around it
> by watching and repacking the .zip archive instead of the .tar.gz

Hello,

I think this bug is similar to #831870 (tar bug probably). Could we
merge them ?

Bug#909681: gnome-builder: git plugin not working in a submodule

[Jérémy Lal]

Package: gnome-builder
Version: 3.30.1-2
Severity: normal

Typically, project A tracked by git, has submodule A/B/ tracked by another git 
repo as well,
setup by `git submodule update --init --recursive` or similar.

Note that A/B/.git is a file containing `gitdir: ../.git/modules/B`.

In this case, when opening the submodule as a project, the git plugin does not 
work at all.

The bug might be in libgit2, or even libgit2-glib.

Jérémy.


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

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

Versions of packages gnome-builder depends on:
ii  clang1:6.0-43
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  exuberant-ctags  1:5.9~svn20110310-12
ii  gir1.2-dazzle-1.03.30.1-1
ii  gir1.2-ggit-1.0  0.26.4-1+b1
ii  gir1.2-glib-2.0  1.58.0-1
ii  gir1.2-gtk-3.0   3.24.1-1
ii  gir1.2-gtksource-3.0 3.24.9-1
ii  gir1.2-gtksource-4   4.0.3-1
ii  gir1.2-json-1.0  1.4.2-4
ii  gir1.2-peas-1.0  1.22.0-2
ii  gir1.2-template-1.0  3.30.0-1
ii  gir1.2-vte-2.91  0.54.0-1
ii  gir1.2-webkit2-4.0   2.22.2-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo-gobject21.15.12-1
ii  libcairo21.15.12-1
ii  libclang1-6.01:6.0.1-9
ii  libdazzle-1.0-0  3.30.1-1
ii  libdevhelp-3-5   3.28.1-1
ii  libenchant1c2a   1.6.0-11.1
ii  libflatpak0  1.0.2-1
ii  libfontconfig1   2.13.0-5
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libgirepository-1.0-11.58.0-1
ii  libgit2-glib-1.0-0   0.26.4-1+b1
ii  libglib2.0-0 2.58.1-2
ii  libgspell-1-11.6.1-1
ii  libgtk-3-0   3.24.1-1
ii  libgtksourceview-4-0 4.0.3-1
ii  libjson-glib-1.0-0   1.4.2-4
ii  libjsonrpc-glib-1.0-13.30.0-1
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpangoft2-1.0-01.42.4-3
ii  libpcre3 2:8.39-11
ii  libpeas-1.0-01.22.0-2
ii  libsoup2.4-1 2.64.1-1
ii  libtemplate-glib-1.0-0   3.30.0-1
ii  libvala-0.42-0   0.42.1-1
ii  libvala-0.42-dev [libvala-dev]   0.42.1-1
ii  libvte-2.91-00.54.0-1
ii  libwebkit2gtk-4.0-37 2.22.2-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  python3  3.6.6-1
ii  python3-gi   3.30.1-1
ii  sysprof  3.30.1-1
ii  valac-0.42-vapi [valac-vapi] 0.42.1-1

Versions of packages gnome-builder recommends:
ii  autoconf  2.69-11
ii  autoconf-archive  20170928-2
ii  automake  1:1.16.1-1.1
ii  autopoint 0.19.8.1-7
ii  build-essential   12.5
ii  flatpak-builder   1.0.0-1
ii  gettext   0.19.8.1-7
ii  intltool  0.51.0-5
ii  libtool   2.4.6-4
ii  meson 0.48.0-2
ii  pkg-config0.29-4+b1
ii  python3-jedi  0.12.0-1
ii  python3-lxml  4.2.5-1
pn  valgrind  

gnome-builder suggests no packages.

-- no debconf information

Bug#909679: fbterm FTCBFS: falls back to broken select code

[Helmut Grohne]

Source: fbterm
Version: 1.7-4
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

fbterm fails to cross build from source, because it falls back to using
select rather than epoll when cross compiling. The select support is
broken (see my other bug), so the build fails. The check for epoll uses
AC_RUN_IFELSE, but it would be sufficient to use AC_COMPILE_IFELSE here.
With the attached patch, cross builds will also use epoll and thus
succeed. Please consider applying it.

Helmut
--- fbterm-1.7.orig/configure.ac
+++ fbterm-1.7/configure.ac
@@ -83,16 +83,16 @@
 	fi
 fi
 
-if test x"$EPOLL" = xauto -a x"$cross_compiling" = xno; then
-  AC_RUN_IFELSE(
+if test x"$EPOLL" = xauto; then
+  AC_COMPILE_IFELSE(
 AC_LANG_PROGRAM([[#include ]],
   [[if (epoll_create(10) >= 0) return 0; return 1;]]),
 [EPOLL=yes]
   )
 fi
 
-if test x"$SIGNALFD" = xauto -a x"$cross_compiling" = xno; then
-  AC_RUN_IFELSE(
+if test x"$SIGNALFD" = xauto; then
+  AC_COMPILE_IFELSE(
 AC_LANG_PROGRAM([[#include ]],
   [[sigset_t mask; if (signalfd(-1, , 0) >= 0) return 0; return 1;]]),
 [SIGNALFD=yes]

Bug#909680: fbterms FTBFS for architectures without epoll support

[Helmut Grohne]

Source: fbterm
Version: 1.7-4
Severity: minor
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

fbio.cpp does not #include  before using fd_set and
friends. That's a bug. The attached patch fixes that. On all release
architectures, this is irrelevant as they use epoll.

Helmut
--- fbterm-1.7.orig/src/fbio.cpp
+++ fbterm-1.7/src/fbio.cpp
@@ -30,6 +30,7 @@
 #define NR_EPOLL_FDS 10
 s32 epollFd;
 #else
+#include 
 static fd_set fds;
 static u32 maxfd = 0;
 #endif

Bug#828475: openssh and OpenSSL 1.1

[Sebastian Andrzej Siewior]

On 2018-09-26 11:44:14 [+0100], Colin Watson wrote:
> 
> Upstream committed the necessary changes to switch to the 1.1 API
> earlier this month, so that should be in OpenSSH 7.9.  There's usually a
> release every few months, so I think we should be OK to just wait for
> that now.

okay, thanks for the update.

Sebastian

Bug#906868: xul-ext-toggle-proxy no longer works with firefox-esr 60

[Sascha Girrulat]

Hi,

would be ok for me.

Regards
Sascha

On 9/25/18 9:58 PM, Moritz Mühlenhoff wrote:
> On Tue, Aug 21, 2018 at 09:25:02PM +0300, Adrian Bunk wrote:
>> Package: xul-ext-toggle-proxy
>> Version: 1.9-2
>> Severity: serious
>>
>> XUL addons are no longer supported.
>>
>> If it is confirmed that this package works with thunderbird 60,
>> it might be an option to change the dependency to only thunderbird.
> 
> This addon is dead upstream and also incompatible with Thunderbird
> 60 (in the addon manager using TB60 it's greyed out as an incompatible
> version), let's remove it from the archive?
> 
> Cheers,
> Moritz
> 



signature.asc
Description: OpenPGP digital signature

Bug#909678: ITS: xcircuit -- missing upstream versions etc.

[Ruben Undheim]

Package: xcircuit
Version: 3.8.78.dfsg-1+b2
Severity: important


The package 'xcircuit' appears to be unmaintained. The last upload by the
listed Maintainer seems to have been done in 2008. After that it was for a long
time maintained by the listed "Uploader", but he has retired from Debian. There
is a 2-year old bug reported by the MIA team to remove him from the uploaders
list (#843374), which remains unanswered.

The newest upstream version is 3.10.10, while the newest stable version is
"3.9.73" - both of them released less than a few months ago. The current Debian
version, 3.8.78 is 3.5 years old (Feb 2015).

Note that the watch file for the package is outdated (#909515), such that it is
not straightforward to see that there are new upstream releases.

I am maintaining several other packages from the same upstream developer
(qflow, qrouter, magic, ...) in the Debian Electronics team. I intend to
salvage this package by adopting it into the Electronics team.


Best regards
Ruben Undheim

Bug#894074: uscan is failing to repack gitlab from last 2 versions

[Emmanuel Bourg]

I got the same issue with some big eclipse packages. I worked around it
by watching and repacking the .zip archive instead of the .tar.gz

Bug#909677: aisleriot: Consider temporarily removing aisleriot/armel to deal with testing migration blocking

[Jeremy Bicha]

On Wed, Sep 26, 2018 at 11:51 AM Boyuan Yang  wrote:
> As discussed at https://lists.debian.org/debian-arm/2018/09/msg00058.html , it
> seems that one of aisleriot's build dependency, guile-2.2-dev, will not be
> available in Debian on armel for quite a while. To prevent from blocking
> package from migrating to testing, is it okay that a RM bug could be submitted
> to have aisleriot/armel removed for now so that the current testing migration
> block could be circumvented? [1]

Yes, I'm fine with that. What should we do with the arch:all
gnome-games metapackage that depends on aisleriot? Do we need to make
that dependency [!armel] ?

For background, see https://bugs.debian.org/883778

Thanks,
Jeremy Bicha

Bug#902981: #902981 : upstream fork

[Xavier]

Hi all,

In case you didn't see it, their is a fork of font-awesome here:
https://forkawesome.github.io/Fork-Awesome/

It could perhaps solve DFSG potential problem ?

Cheers,
Xavier

Bug#909590: gerbera: Gerbera fails on start and every 5 sec

[Jean-Louis Mounier]

Hello James,

I did consider the questions you asked and I solved the problem by 
reinstalling package 'file' and then its dependencies : libc6 libmagic1 
zlib1g . Maybe only one was faulty but it is so quick and painless to do...


It was a system wide problem and not a gerbera bug. Maybe one file from 
libmagic1 was corrupted...


You can close the bug now !

Thank you for your help and for your contribution to Debian. We use 
Gerbera almost every day to watch educationnal TV shows on our TV. It is 
a great piece of software !


Best regards

Jean-Louis



Le 26/09/2018 à 11:38, James Cowgill a écrit :

Control: tags -1 moreinfo

Hi,

On 25/09/2018 19:14, Jean-Louis wrote:

Package: gerbera
Version: 1.1.0+dfsg-2+b2
Severity: important

Dear Maintainer,

Hello, I use gerbera for a long time and recently, the server failed and fails  
to restart every 5 seconds.
No valuable information in log file. The package is fully unusable.

Same problem after purge and reinstall. I guess the best information is the 
following line that apperas once in the log file at machine startup :

Sep 25 19:21:51 mercury gerbera[1178]: /usr/bin/gerbera: 
/lib/arm-linux-gnueabihf/libc.so.6: version `' not found (required by 
/lib/arm-linux-gnueabihf/libmagic.so.1)

That is a very strange error indicating that ld.so failed to load
gerbera before any code was executed.

Does running "gerbera --version" outside systemd work?
Does running "file" on something work?

Are you running a system with usrmerge enabled (ie is /lib a symlink to
/usr/lib)?

James

Bug#909617: radicale

[Jonas Smedegaard]

Control: retitle -1 redicale: emits non-fatal errors during upgrade/removal
Control: severity -1 minor
Control: tag -1 help


Quoting Michael Rasmussen (2018-09-26 17:29:58)
> On Wed, 26 Sep 2018 01:29:16 +0200
> Jonas Smedegaard  wrote:
> > What is the issue you are reporting above, with no real subject?
> > 
> > Are you perhaps reporting that bug#909466 is now fixed?
> > 
> I thought the error messages was indicating the bug was not fixed.

Thanks for clarifying.

For future sake, I dearly recommend to use the tool "reportbug", which 
guides you through reporting bugreports - including asking for a 
sensible title.


> If it is fixed why output those messages,

I believe bug#909466 is fixed, and that you quoted output from the 
non-fixed version.

That said, some arguably similar messages may still be emitted now, just 
should no longer be fatal...


> and if output should be done why then not lower the error level from 
> error to info?

...so let's treat this as a bugreport about the unneeded noise.

Reason for the noise is that I have not yet figured out a way to silence 
it without risking silencing useful output (and implementing the 
mechanism is more important, the output is harmless).


Help imporving the output is much appreciated.


 - Jonas

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

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


signature.asc
Description: signature

Bug#909661: [DRE-maint] Bug#909661: Bug#909661: unicorn won't start: "Could not find rbpdf-font-1.19.0"

[Hashem Nasarat]

And including the Gemfile.lock would help too

On Wed, Sep 26, 2018 at 11:33 AM Hashem Nasarat  wrote:

> Thanks for filling a bug report! I'll try to reproduce this later today.
> Have you done any customization to your redmine install, or are you merely
> using the plain redmine debian package?
>
> In addition, can you provide the Gemfile corresponding to this redmine
> install?
>
> On Wed, Sep 26, 2018 at 8:57 AM Jörg-Volker Peetz  wrote:
>
>> Package: ruby-rbpdf
>> Version: 1.19.5+ds.1-1
>> Severity: normal
>>
>> Dear Maintainer(s),
>>
>> a redmine installation served by unicorn won't start after upgrading
>> ruby-rbpdf from version 1.19.0-1.
>> The unicorn log file contains the following messages:
>>
>> I, [2018-09-26T13:20:54.028668 #6578]  INFO -- : Refreshing Gem list
>> /usr/lib/ruby/vendor_ruby/bundler/spec_set.rb:88:in `block in
>> materialize':
>> Could not find rbpdf-font-1.19.0 in any of the sources
>> (Bundler::GemNotFound)
>> from /usr/lib/ruby/vendor_ruby/bundler/spec_set.rb:82:in `map!'
>> from /usr/lib/ruby/vendor_ruby/bundler/spec_set.rb:82:in
>> `materialize'
>> from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:170:in
>> `specs'
>> from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:237:in
>> `specs_for'
>> from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:226:in
>> `requested_specs'
>> from /usr/lib/ruby/vendor_ruby/bundler/runtime.rb:108:in `block in
>> definition_method'
>> from /usr/lib/ruby/vendor_ruby/bundler/runtime.rb:20:in `setup'
>> from /usr/lib/ruby/vendor_ruby/bundler.rb:107:in `setup'
>> from /usr/lib/ruby/vendor_ruby/bundler/setup.rb:20:in `> (required)>'
>> from
>> /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
>> from
>> /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
>> from /usr/share/redmine/config/boot.rb:6:in `'
>> from
>> /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
>> from
>> /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
>> from /usr/share/redmine/config/application.rb:1:in `> (required)>'
>> from
>> /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
>> from
>> /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
>> from /usr/share/redmine/config/environment.rb:2:in `> (required)>'
>> from
>> /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
>> from
>> /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
>> from config.ru:4:in `block in '
>> from /usr/lib/ruby/vendor_ruby/rack/builder.rb:55:in
>> `instance_eval'
>> from /usr/lib/ruby/vendor_ruby/rack/builder.rb:55:in `initialize'
>> from config.ru:1:in `new'
>> from config.ru:1:in `'
>> from /usr/lib/ruby/vendor_ruby/unicorn.rb:56:in `eval'
>> from /usr/lib/ruby/vendor_ruby/unicorn.rb:56:in `block in builder'
>> from /usr/lib/ruby/vendor_ruby/unicorn/http_server.rb:795:in
>> `build_app!'
>> from /usr/lib/ruby/vendor_ruby/unicorn/http_server.rb:139:in
>> `start'
>> from /usr/bin/unicorn:126:in `'
>>
>> Any idea?
>>
>> Regards,
>> Jörg.
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers testing
>>   APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.18.8 (SMP w/8 CPU cores)
>> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
>> (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: sysvinit (via /sbin/init)
>>
>> Versions of packages ruby-rbpdf depends on:
>> ii  ruby   1:2.5.1
>> ii  ruby-htmlentities  4.3.3-1
>> ii  ruby-rbpdf-font1.19.5+ds.1-1
>>
>> ruby-rbpdf recommends no packages.
>>
>> ruby-rbpdf suggests no packages.
>>
>> -- no debconf information
>>
>> ___
>> Pkg-ruby-extras-maintainers mailing list
>> pkg-ruby-extras-maintain...@alioth-lists.debian.net
>>
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
>
> ___
> Pkg-ruby-extras-maintainers mailing list
> pkg-ruby-extras-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers

Bug#909590: gerbera: Gerbera fails on start and every 5 sec

[Jean-Louis Mounier]

Hi James,

here is what you ask for :

root@mercury:~# gerbera --version
gerbera: /lib/arm-linux-gnueabihf/libc.so.6: version `' not found 
(required by /lib/arm-linux-gnueabihf/libmagic.so.1)


root@mercury:~# file /etc/group
Erreur de segmentation

root@mercury:~# ls -l /lib
lrwxrwxrwx 1 root root 7 juin  13 19:23 /lib -> usr/lib

It seems to be a system wide problem...

Thank you in advance

Regards

Bug#909668: [Pkg-xen-devel] Bug#909668: Acknowledgement (FTBFS in buster and sid (probably, due to gcc-8))

[Hans van Kranenburg]

Hi,

On 09/26/2018 05:37 PM, Ian Jackson wrote:
> On my 4.11-based rework branch I found that the following upstream
> commits were needed:
> 
> 437e00fea04becc91c1b6bc1c0baa636b067a5cc
> tools/kdd: mute spurious gcc warning
> 
> e1b7eb92d3ec6ce3ca68cffb36a148eb59f59613
> tools: Move ARRAY_SIZE() into xen-tools/libs.h
> [ this is needed for BUILD_BUG_ON, which is used by the next patch ]
> 
> b8f33431f3dd23fb43a879f4bdb4283fdc9465ad
> libxl/arm: Fix build on arm64 + acpi w/ gcc 8.2
> 
> 
> For Xen 4.8 based packages, it may also be necessary to have
> 
> 5f28de0b0e474e01931b719fa27ca30b8aa446e0
> libxl: compilation warning fix for arm & aarch64
> 
> but that fix is in the upstream 4.11 branch.
> 
> Ian.
> 

Note that I also added this one from master branch to the 4.11 patches
earlier, to make it compile with gcc-8:

tools/xentop : replace use of deprecated vwprintw

Hans

Bug#909677: aisleriot: Consider temporarily removing aisleriot/armel to deal with testing migration blocking

[Boyuan Yang]

Package: aisleriot
Version: 1:3.22.6-1
Severity: important

Dear Debian GNOME Maintainers,

As discussed at https://lists.debian.org/debian-arm/2018/09/msg00058.html , it 
seems that one of aisleriot's build dependency, guile-2.2-dev, will not be 
available in Debian on armel for quite a while. To prevent from blocking 
package from migrating to testing, is it okay that a RM bug could be submitted 
to have aisleriot/armel removed for now so that the current testing migration 
block could be circumvented? [1]

Thanks,
Boyuan Yang

[1] https://qa.debian.org/excuses.php?package=aisleriot

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

Bug#909674: lintian: please don't show changelog-empty-entry warning if distribution is UNRELEASED

[Chris Lamb]

tags 909674 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/ae5a73dc42d9c8cde36501202362cfeabfae3140

  checks/changelog-file.desc   |  3 ++-
  checks/changelog-file.pm |  3 ++-
  debian/changelog |  4 
  .../debian/debian/changelog.in   | 12 
  t/tests/changelog-file-empty-entry-unrel/desc|  4 
  t/tests/changelog-file-empty-entry-unrel/tags|  0
  6 files changed, 24 insertions(+), 2 deletions(-)


Regards,

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

Bug#909676: Ability to disable modifier latching when enabling sticky keys

[Colomban Wendling]

Package: mate-settings-daemon
Version: 1.20.3-1
Tags: a11y upstream patch
Owner: b...@hypra.fr
User: b...@hypra.fr
Usertags: hypra colomban
Severity: whishlist
Forwarded: https://github.com/mate-desktop/mate-settings-daemon/pull/237

Currently when enabling sticky keys, modifiers latching is enabled
unconditionally.  This can however be confusing for users not used to
this feature, and give them the feeling that their input is broken.

Please add a way to disable modifier latching.

Regards,
Colomban

Bug#884887: chromium: rejects access to microphone without prompt

[Rodrigo Aguilera]

This is really annoying. Please fix it.

Take into account that you also need to have chromium turned off before
editing the preferences file so it doesn't get overwritten.

Bug#909617: radicale

[Michael Rasmussen]

Hi Jonas,

On Wed, 26 Sep 2018 01:29:16 +0200
Jonas Smedegaard  wrote:

> 
> What is the issue you are reporting above, with no real subject?
> 
> Are you perhaps reporting that bug#909466 is now fixed?
> 
I thought the error messages was indicating the bug was not fixed.
If it is fixed why output those messages, and if output should be done
why then not lower the error level from error to info?


-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
--
/usr/games/fortune -es says:
Cats are smarter than dogs.  You can't make eight cats pull a sled
through the snow.


pgpw8jcwedXCx.pgp
Description: OpenPGP digital signature

Bug#909668: Acknowledgement (FTBFS in buster and sid (probably, due to gcc-8))

[Ian Jackson]

On my 4.11-based rework branch I found that the following upstream
commits were needed:

437e00fea04becc91c1b6bc1c0baa636b067a5cc
tools/kdd: mute spurious gcc warning

e1b7eb92d3ec6ce3ca68cffb36a148eb59f59613
tools: Move ARRAY_SIZE() into xen-tools/libs.h
[ this is needed for BUILD_BUG_ON, which is used by the next patch ]

b8f33431f3dd23fb43a879f4bdb4283fdc9465ad
libxl/arm: Fix build on arm64 + acpi w/ gcc 8.2


For Xen 4.8 based packages, it may also be necessary to have

5f28de0b0e474e01931b719fa27ca30b8aa446e0
libxl: compilation warning fix for arm & aarch64

but that fix is in the upstream 4.11 branch.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#909675: ITP: equinox-p2 -- Provisioning technology for OSGi-based applications

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: equinox-p2
  Version : 4.7.3
  Upstream Author : Eclipse Foundation, Inc.
* URL : http://www.eclipse.org/equinox/p2/
* License : EPL-1.0
  Programming Lang: Java
  Description : Provisioning technology for OSGi-based applications

The Eclipse Equinox p2 project focuses on provisioning technology for
OSGi-based applications. Although p2 has specific support for installing
Eclipse and Equinox-based applications, it includes a general-purpose
provisioning infrastructure that can be used as the basis for provisioning
solutions for a wide variety of software applications.

This package will be maintained by the Java Team. It's required
to transition away from the old src:eclipse package.

Bug#909674: lintian: please don't show changelog-empty-entry warning if distribution is UNRELEASED

[Holger Levsen]

Package: lintian
Version: 2.5.105
Severity: normal

Dear Maintainer,

subject says it all: please don't show changelog-empty-entry warning if
distribution is UNRELEASED.

Thanks for maintaining lintian!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#909661: [DRE-maint] Bug#909661: unicorn won't start: "Could not find rbpdf-font-1.19.0"

[Hashem Nasarat]

Thanks for filling a bug report! I'll try to reproduce this later today.
Have you done any customization to your redmine install, or are you merely
using the plain redmine debian package?

In addition, can you provide the Gemfile corresponding to this redmine
install?

On Wed, Sep 26, 2018 at 8:57 AM Jörg-Volker Peetz  wrote:

> Package: ruby-rbpdf
> Version: 1.19.5+ds.1-1
> Severity: normal
>
> Dear Maintainer(s),
>
> a redmine installation served by unicorn won't start after upgrading
> ruby-rbpdf from version 1.19.0-1.
> The unicorn log file contains the following messages:
>
> I, [2018-09-26T13:20:54.028668 #6578]  INFO -- : Refreshing Gem list
> /usr/lib/ruby/vendor_ruby/bundler/spec_set.rb:88:in `block in materialize':
> Could not find rbpdf-font-1.19.0 in any of the sources
> (Bundler::GemNotFound)
> from /usr/lib/ruby/vendor_ruby/bundler/spec_set.rb:82:in `map!'
> from /usr/lib/ruby/vendor_ruby/bundler/spec_set.rb:82:in
> `materialize'
> from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:170:in `specs'
> from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:237:in
> `specs_for'
> from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:226:in
> `requested_specs'
> from /usr/lib/ruby/vendor_ruby/bundler/runtime.rb:108:in `block in
> definition_method'
> from /usr/lib/ruby/vendor_ruby/bundler/runtime.rb:20:in `setup'
> from /usr/lib/ruby/vendor_ruby/bundler.rb:107:in `setup'
> from /usr/lib/ruby/vendor_ruby/bundler/setup.rb:20:in ` (required)>'
> from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require'
> from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require'
> from /usr/share/redmine/config/boot.rb:6:in `'
> from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require'
> from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require'
> from /usr/share/redmine/config/application.rb:1:in ` (required)>'
> from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require'
> from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require'
> from /usr/share/redmine/config/environment.rb:2:in ` (required)>'
> from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require'
> from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require'
> from config.ru:4:in `block in '
> from /usr/lib/ruby/vendor_ruby/rack/builder.rb:55:in
> `instance_eval'
> from /usr/lib/ruby/vendor_ruby/rack/builder.rb:55:in `initialize'
> from config.ru:1:in `new'
> from config.ru:1:in `'
> from /usr/lib/ruby/vendor_ruby/unicorn.rb:56:in `eval'
> from /usr/lib/ruby/vendor_ruby/unicorn.rb:56:in `block in builder'
> from /usr/lib/ruby/vendor_ruby/unicorn/http_server.rb:795:in
> `build_app!'
> from /usr/lib/ruby/vendor_ruby/unicorn/http_server.rb:139:in
> `start'
> from /usr/bin/unicorn:126:in `'
>
> Any idea?
>
> Regards,
> Jörg.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.8 (SMP w/8 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages ruby-rbpdf depends on:
> ii  ruby   1:2.5.1
> ii  ruby-htmlentities  4.3.3-1
> ii  ruby-rbpdf-font1.19.5+ds.1-1
>
> ruby-rbpdf recommends no packages.
>
> ruby-rbpdf suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-ruby-extras-maintainers mailing list
> pkg-ruby-extras-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers

Bug#909642: mmdebstrap: missing dependency on apt

[Johannes Schauer]

Hi Sven,

Quoting Sven Joachim (2018-09-26 09:49:56)
> According to the package description and the manpage, mmdebstrap cannot
> operate without apt, so it ought to depend on apt.
> 
> While apt considers itself essential, the admin is free to torture
> themselves by running "dpkg --purge apt" and use one of dselect's
> alternative access methods, at least in theory.

whoops. XD

I was indeed relying on the autopkgtest discovering any missing dependencies
but of course the autopkgtest chroot has apt installed so it didn't discover
this oversight.

Thanks! For finding it!! :D

cheers, josch


signature.asc
Description: signature

Bug#909673: python2.7: CVE-2018-1000802

[Antoine Beaupre]

Package: python2.7
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security
Control: fixed -1 2.7.9-2+deb8u2

Hi,

The following vulnerability was published for python2.7.

CVE-2018-1000802[0]:
| Python Software Foundation Python (CPython) version 2.7 contains a
| CWE-77: Improper Neutralization of Special Elements used in a Command
| ('Command Injection') vulnerability in shutil module (make_archive
| function) that can result in Denial of service, Information gain via
| injection of arbitrary files on the system or entire drive. This
| attack appear to be exploitable via Passage of unfiltered user input
| to the function. This vulnerability appears to have been fixed in
| after commit add531a1e55b0a739b0f42582f1c9747e5649ace.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1000802
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000802

Please adjust the affected versions in the BTS as needed.

==

The patches upstream are straightforward to apply and have been shipped
in Debian LTS (jessie):

https://github.com/python/cpython/pull/8985/commits/add531a1e55b0a739b0f42582f1c9747e5649ace

They are not part of a 2.7.x release just yet however but considering
the impact, I think it might be worth fixing before the upstream point
release.

A.


signature.asc
Description: PGP signature

Bug#888320: Valgrind Supressions

[Karl Semich]

Hi,

For me the python-2.7.13-2 packages provides
/usr/lib/valgrind/python.supp and it seems this bug could be closed.

Unfortunately, that file appears to be outdated.  It mentions that
python2.7-dbg is compiled with pymalloc disabled, which is false for
me !

It seems python2.7-dbg should be updated to be compiled for valgrind.

Bug#909663: ITS: stterm -- missing upstream versions, neglected bugs, unresponsive maintainer

[Paride Legovini]

X-Debbugs-CC: jari.aa...@cante.net

[Second mailing due to the previous improper usage of X-Debbugs-CC.]

I believe that the 'stterm' package is currently unmaintained. I filed
at least a couple of bugs in the last years, reporting problems, sending
patches and asking for new upstream versions to be packaged:

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

but no action has been taken. The latest reply from the current
maintainer dates back to 2016:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838439#23

and although the maintainer wrote "I'll see what changes are needed", no
work has been done so far. The package is buggy and outdated, and as you
can see from those threads I'm not the only one who is concerned.

Several months ago I volunteered to co-maintain the package in a private
email, but I've got no reply. On May 7 2018 I wrote again, offering to
carry on the packaging work on my own, Cc: m...@qa.debian.org; again I've
got no reply. In general, I think that stterm's maintainer is MIA.

For these reasons, I intend to salvage stterm. I reiterate that I am
fine with co-maintaining it, provided that I'm left with enough freedom
to refactor the current packaging.

Paride



signature.asc
Description: OpenPGP digital signature

Bug#909672: friendly-recovery breaks systemd-remount-fs (ro root partition)

[H.-Dirk Schmitt]

Package: friendly-recovery
Version: 0.2.34
Severity: normal

Here systemd-remount-fs is not started.

In the journal I found the following:
Sep 26 13:53:57 dilbert systemd[1]: systemd-hwdb-update.service: Found ordering
cycle on systemd-remount-fs.service/start
Sep 26 13:53:57 dilbert systemd[1]: systemd-hwdb-update.service: Found
dependency on systemd-fsck-root.service/start
Sep 26 13:53:57 dilbert systemd[1]: systemd-hwdb-update.service: Found
dependency on friendly-recovery.service/start
Sep 26 13:53:57 dilbert systemd[1]: systemd-hwdb-update.service: Found
dependency on systemd-udevd.service/start
Sep 26 13:53:57 dilbert systemd[1]: systemd-hwdb-update.service: Found
dependency on systemd-hwdb-update.service/start

See the changelog:
--
friendly-recovery (0.2.37) unstable; urgency=medium

  * friendly-recovery.service: do not order after systemd-udevd.service as
this leads to a boot dependency cycle. Instead order after the
systemd-udevd-control.socket only.

 -- Dimitri John Ledkov   Wed, 08 Nov 2017 11:23:14 +


I suggest to „backport“ this change to the stretch version of the friendly-
revovery.



-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (600, 'stable-updates'), (600, 'stable'), (200, 'testing'), (101, 
'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=de_DE:de:en_US:en (charmap=UTF-8) (ignored: 
LC_ALL set to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages friendly-recovery depends on:
ii  init-system-helpers  1.48
ii  systemd-sysv 237-3~bpo9+1
ii  whiptail 0.52.19-1+b1

Versions of packages friendly-recovery recommends:
ii  gettext-base  0.19.8.1-2

friendly-recovery suggests no packages.

-- no debconf information

Bug#909671: openjdk-7-jdk: Missing sunec.jar

[Simon Bernard]

Package: openjdk-7-jdk
Version: 7u161-2.6.12-1
Severity: normal

Dear Maintainer,

I faced some :
java.security.NoSuchProviderException: no such provider: SunEC

using openjdk-7.

I didn't have this kind of error when openjdk-7 was available in stable.

I don't face this issue with openjdk-8.

It seems this is caused by the missing jar : sunec.jar



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

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

Versions of packages openjdk-7-jdk depends on:
ii  libc6  2.27-2
ii  libx11-6   2:1.6.4-3
ii  openjdk-7-jre  7u161-2.6.12-1

Versions of packages openjdk-7-jdk recommends:
ii  libxt-dev  1:1.1.5-1

Versions of packages openjdk-7-jdk suggests:
pn  openjdk-7-demo
ii  openjdk-7-source  7u161-2.6.12-1
ii  visualvm  1.3.9-1

-- no debconf information

Bug#909670: ITP: gnome-remote-desktop -- Remote desktop daemon for GNOME using Pipewire

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org
Owner: jbi...@debian.org

Package Name: gnome-remote-desktop
Version: 0.1.6
Upstream Authors: Jonas Ådahl, Red Hat
License : GPL-2+
Programming Lang: C
Homepage: https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
Description: Remote desktop daemon for GNOME using PipeWire
 This daemon enables GNOME to offer remote desktop sharing using VNC
 with PipeWire. It supports both GNOME on X and GNOME on Wayland.
 Remote sharing can be enabled and managed in the GNOME Settings app.
 .
 This feature will not work on Ubuntu until mutter is recompiled
 with the remote desktop option enabled.

Other Info
--
The Debian GNOME team intends to maintain this package.

If testing goes well, we would like to install this package by default
in Debian GNOME for Buster since we currently default to Wayland.
Otherwise, at least it will be available as an option for people using
Buster.

Packaging is at
https://salsa.debian.org/gnome-team/gnome-remote-desktop

Thanks,
Jeremy Bicha

Bug#909669: vis: test

[Paride Legovini]

X-Debbugs-CC: paride.legov...@gmail.com

One last test.

With subject: 'Bug#909669: vis: test'

Bug#909669: new subject

[Paride Legovini]

X-Debbugs-CC: paride.legov...@gmail.com

A second test.

Bug#909658: debian-installer: blank screen on install (HP Elitebook 830 G5)

[Hideki Yamane]

Hi,

 Additional info,

 - CentOS7 and Fedora29 work
 - Debian9.5 (Debian Live) also works (able to login to GNOME desktop)
   but install goes to blank screen


On Wed, 26 Sep 2018 21:16:24 +0900
Hideki Yamane  wrote:
> Package: debian-installer
> Severity: important
> 
> Hi,
> 
>  I've tried to install Debian on my new laptop HP EliteBook 830 G5
>  but failed since it shows only blank screen after selecting installation
>  mode (both graphical and text). Screen doesn't work but system still
>  seems to alive because when I've selected "Install with speech synthesis"
>  it speaks.
> 
>  UEFI secure boot was disabled, and it looks similar to Bug#899240
>  but it doesn't work even if legacy boot is enabled.
> 
> 
>  However, Ubuntu 18.04.1 boots successfully, so I can get hardware info and
>  attach it to this report.
> 
>  Any ideas?
> 
> -
> Success
> - Ubuntu18.04.1 (Linux 4.15.0-29-generic)
> 
> Fail
> - Debian9.4
> - both Debian Installer Buster Alpha 3 release and daily image
> 
> Machine
> - name: HP EliteBook 830 G5/CT Notebook PC
> - cpu: Core i5-7200U (skylake)
> - graphic: Intel HD graphics 620


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#907835: [Pkg-xen-devel] Bug#907835: newer version in stable

[Ian Jackson]

Antoine Beaupré writes ("Re: [Pkg-xen-devel] Bug#907835: newer version in 
stable"):
> It's been two weeks and stable still has a newer version than unstable,
> which suffers from four security issues fixed in stable.
> 
> I understand you might have other plans in the long term, but in the
> meantime, why not just upload deb9u10 to unstable?

I went to do this but sadly, it no longer builds due to gcc8.  There
are upstream patches that could be cherry-picked but it's certainly no
longer simply a matter of importing the security update.

I am going to look at these failures since they are blocking my
package refactoring work and I expect that as an output I will produce
a list of upstream commits to cherry pick, which I will send to this
bug.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#909669: vis: test

[Paride Legovini]

Package: vis
Version: 0.5+ts-3
Severity: wishlist

X-Debbugs-CC: paride.legov...@gmail.com

Just a test.