Bug#899226: zfsnap manpage is missing

[Craig Sanders]

Package: zfsnap
Version: 1.11.1-5.1

The upstream github repo https://github.com/zfsnap/zfsnap/tree/legacy has a
man page for zfsnap, but it's missing from the package.

The markdown & html docs and examples are great to have, but a man page is
essential.

craig

--
craig sanders 

Bug#899215: kicad: eeschema is sluggish

[Carsten Schoenert]

Hello David,

On Sun, May 20, 2018 at 04:09:28PM -0700, David Tomaschik wrote:
> Package: kicad
> Version: 5.0.0~rc1+dfsg1+20180318-3
> Severity: important
> 
> Dear Maintainer,
> 
> When loading eeschema in the 5.0.0-rc1 version from experimental, the 
> schematic
> editor is very sluggish.  There is a thread about this on the kicad forums 
> here:
> 
> https://forum.kicad.info/t/debian-kicad-5-0-0-rc2-dev-eeschema-sluggish/10464
> 
> It appears to be related to USE_WX_GRAPHICS_CONTEXT, but that seems necessary 
> to
> use with wxwidgets linked with Gtk3.  I don't know what workarounds are
> possible.

this issue was already raised by some other person but somehow no bug
was opened about this. We now the root for this behavior which is
related to the currently enabled wxpython (with GTK+3 bindings) usage by
KICAD_SCRIPTING_WXPYTHON=ON.

We will drop this setting with the next upload which should happen soon
as now RC2 is released.

Regards
Carsten

Bug#899021: libembperl-perl: FTBFS with Perl 5.27, unmaintained upstream

[Dominique Dumont]

On Friday, 18 May 2018 17:08:38 CEST Dominic Hargreaves wrote:
> Currently the package has a popcon of inst: 37 / vote: 22 / recent: 1
> suggesting that it is barely used anywhere. 

Reading its features, I think this module may have been a good idea when it 
was created back in 1997, but I'm afraid it's now completely obsoleted by 
modern JavaScript frameworks.  

> So I suggest that rather than
> spending any more time maintaining it, we remove it from Debian.

Agreed.

All the best

Bug#898684: 100% when monitor is plugged/unplugged while system is suspended or hibernated

[Enrico Zini]

On Wed, May 16, 2018 at 02:20:49PM +0200, Michael Biebl wrote:

> Which graphics driver is used on this particular laptop?

# lshw -c video
  *-display 
   description: VGA compatible controller
   product: Intel Corporation
   vendor: Intel Corporation
   physical id: 2
   bus info: pci@:00:02.0
   version: 02
   width: 64 bits
   clock: 33MHz
   capabilities: pciexpress msi pm vga_controller bus_master cap_list rom
   configuration: driver=i915 latency=0
   resources: iomemory:1f0-1ef irq:132 memory:1ffa00-1ffaff 
memory:a000-afff ioport:3000(size=64) memory:c-d

> Are you using Xorg or Wayland?

Xorg

> Do you get anything relevant in the log files/journal which might hint
> at a problem?

No, and classically, after reporting the issue I'm not able to reproduce
it anymore, so I guess you can close this issue.

Still, gnome-shell remains the top CPU user in my system:

  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
 
 1811 enrico20   0 3869980 321256  43236 S   3.0   2.0 208:34.16 
gnome-shell 
 4883 enrico20   0 2004148 319344  88324 S   0.0   2.0 147:05.53 chromium   
 
 4933 enrico20   0  795644  83604  29188 S   0.0   0.5  86:15.41 chromium   
 
 1730 enrico20   0  354712  70996  41036 S   3.0   0.4  81:08.01 Xorg   
 
 5270 enrico20   0 2022956  70772  35316 S   0.0   0.4  67:42.62 chromium   
 
27543 enrico20   0 2709844 298116  88284 S   7.9   1.8  48:27.05 chromium   
 
 2305 enrico20   0  809092  58936  23204 S   3.0   0.4  32:17.70 
gnome-terminal- 
24247 enrico20   0 1354008 133344  58704 S   0.7   0.8  25:15.78 chromium   
 
  391 root  20   0  115032  27396  26092 S   0.0   0.2  16:59.94 
systemd-journal 
 2705 enrico20   0 1842936 149632  32120 S   0.0   0.9  10:30.31 gajim  
 
 6294 enrico20   0 1405352 108004  34856 S   0.0   0.7  10:01.37 chromium   
 


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#899214: lintian: Update links to emacsen-team's website

[Chris Lamb]

tags 899214 + pending
thanks

Hi Sean,

> Moved alioth->Debian wiki.  Thanks.

Applied in Git, pending upload:

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

  checks/elpa.desc | 4 ++--
  debian/changelog | 4 
  2 files changed, 6 insertions(+), 2 deletions(-)


Regards,

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

Bug#899085: release.debian.org: excuses terminology: replace "Valid Candidate" with "Trying to migrate"?

[Paul Wise]

On Mon, May 21, 2018 at 2:46 PM, Niels Thykier wrote:

> When I wrote the messages, I wanted to quickly high light the three
> basic states ("OK", "WAITING" or "BLOCKED"/rejected).  The first two
> states implies that the contributor does not need to do anything at the
> moment, where as the latter implies that the some human intervention is
> needed.

The messages for the WAITING states already start with Waiting.

The messages for the OK states indicate what is going to happen.

So, I'd say the states aren't needed in those messages but if you
prefer to keep them, that is fine too.

The messages for the BLOCKED states probably do need the state though.

I don't think you need the "please see below" style messages since
excuses are usually always presented all at once?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#899227: openjdk-10-jre-headless: javaws binary not included in the package

[Coque Couto]

Package: openjdk-10-jre-headless
Version: 10.0.1+10-4
Severity: important

Dear Maintainer,

openjdk-10-jre-headless, which is installed in Sid by default-jre,
doesn't include javaws binary for running jnlp Java applications.

I've found the javaws binary in the icedtea-netx package, which
depends on openjdk-8-jre:

$ apt-file search javaws | grep bin
icedtea-netx: /usr/lib/jvm/java-8-openjdk-amd64/bin/javaws
icedtea-netx: /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/javaws

Regards.


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

Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 openjdk-10-jre-headless depends on:
ii  ca-certificates-java  20180516
ii  java-common   0.65
ii  libc6 2.27-3
ii  libcups2  2.2.7-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.1.0-3
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-1
ii  libnss3   2:3.37-1
ii  libpcsclite1  1.8.23-3
ii  libstdc++68.1.0-3
ii  libx11-6  2:1.6.5-1
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.9-1
ii  libxrender1   1:0.9.10-1
ii  libxtst6  2:1.2.3-1
ii  util-linux2.32-0.1
ii  zlib1g1:1.2.11.dfsg-1

openjdk-10-jre-headless recommends no packages.

Versions of packages openjdk-10-jre-headless suggests:
ii  fonts-dejavu-extra 2.37-1
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
ii  libnss-mdns0.14.1-1

-- no debconf information

Bug#899085: release.debian.org: excuses terminology: replace "Valid Candidate" with "Trying to migrate"?

[Paul Wise]

On Mon, 2018-05-21 at 07:53 +, Niels Thykier wrote:

> Based on your comments, I have made a branch on salsa:
> 
> https://salsa.debian.org/release-team/britney2/tree/bug-899085-excuse-messages

Looks good to me.

> The patches are also attached (assuming it is easier for you to review
> them by email).

Yep.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#899085: release.debian.org: excuses terminology: replace "Valid Candidate" with "Trying to migrate"?

[Niels Thykier]

Control: tags -1 patch

Paul Wise:
> On Mon, May 21, 2018 at 2:46 PM, Niels Thykier wrote:
> 
>> When I wrote the messages, I wanted to quickly high light the three
>> basic states ("OK", "WAITING" or "BLOCKED"/rejected).  The first two
>> states implies that the contributor does not need to do anything at the
>> moment, where as the latter implies that the some human intervention is
>> needed.
> 
> The messages for the WAITING states already start with Waiting.
> 
> The messages for the OK states indicate what is going to happen.
> 
> So, I'd say the states aren't needed in those messages but if you
> prefer to keep them, that is fine too.
> 
> The messages for the BLOCKED states probably do need the state though.
> 
> I don't think you need the "please see below" style messages since
> excuses are usually always presented all at once?
> 

Based on your comments, I have made a branch on salsa:

https://salsa.debian.org/release-team/britney2/tree/bug-899085-excuse-messages

The patches are also attached (assuming it is easier for you to review
them by email).

Thanks,
~Niels
From 5dd4a5141c9ecedd0c0a09386725ceb839559f5a Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Mon, 21 May 2018 07:48:10 +
Subject: [PATCH 1/2] Avoid explicit state in non-actionable excuses

Signed-off-by: Niels Thykier 
---
 britney2/excuse.py | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/britney2/excuse.py b/britney2/excuse.py
index cd1e46d..dc109bf 100644
--- a/britney2/excuse.py
+++ b/britney2/excuse.py
@@ -21,13 +21,13 @@ from britney2.policies.policy import PolicyVerdict
 
 VERDICT2DESC = {
 PolicyVerdict.PASS:
-'OK: Will attempt migration (Any information below is purely informational)',
+'Will attempt migration (Any information below is purely informational)',
 PolicyVerdict.PASS_HINTED:
-'OK: Will attempt migration due to a hint (Any information below is purely informational)',
+'Will attempt migration due to a hint (Any information below is purely informational)',
 PolicyVerdict.REJECTED_TEMPORARILY:
-'WAITING: Waiting for test results, another package or too young (no action required now - check later)',
+'Waiting for test results, another package or too young (no action required now - check later)',
 PolicyVerdict.REJECTED_WAITING_FOR_ANOTHER_ITEM:
-'WAITING: Waiting for another item to be ready to migrate (no action required now - check later)',
+'Waiting for another item to be ready to migrate (no action required now - check later)',
 PolicyVerdict.REJECTED_BLOCKED_BY_ANOTHER_ITEM:
 'BLOCKED: Cannot migrate due to another item, which is blocked (please check which dependencies are stuck)',
 PolicyVerdict.REJECTED_NEEDS_APPROVAL:
@@ -35,7 +35,7 @@ VERDICT2DESC = {
 PolicyVerdict.REJECTED_CANNOT_DETERMINE_IF_PERMANENT:
 'BLOCKED: Maybe temporary, maybe blocked but Britney is missing information (check below or the buildds)',
 PolicyVerdict.REJECTED_PERMANENTLY:
-'BLOCKED: Rejected/introduces a regression (please see below)'
+'BLOCKED: Rejected/introduces a regression',
 }
 
 
-- 
2.17.0

From d11152b36601bf81c2ab0f24a476654bb1e59eff Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Mon, 21 May 2018 07:48:33 +
Subject: [PATCH 2/2] Remove the "valid candidate"/"Not considered" messages

Signed-off-by: Niels Thykier 
---
 britney2/excuse.py | 4 
 1 file changed, 4 deletions(-)

diff --git a/britney2/excuse.py b/britney2/excuse.py
index dc109bf..5a2b48a 100644
--- a/britney2/excuse.py
+++ b/britney2/excuse.py
@@ -240,10 +240,6 @@ class Excuse(object):
 else:
 res = res + "Build-Depends(-Arch): %s %s\n" % (self.name, dep, dep)
 
-if self.is_valid:
-res += "Valid candidate\n"
-else:
-res += "Not considered\n"
 res = res + "\n"
 return res
 
-- 
2.17.0

Bug#899228: lxc 2.0.07-2 - unknown key lxc.idmap

[ѽ҉ᶬḳ℠]

Package: lxc
Version: 2.0.7-2+deb9u2
Linux server 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)
x86_64 GNU/Linux
libc 2.24-11+deb9u3
uidmap 4.4-4.1

trying to run an unprivileged container produces

    "lxc-start: confile.c: parse_line: 2008 unknown key lxc.idmap
    lxc-start: parse.c: lxc_file_for_each_line: 57 Failed to parse 
config: lxc.idmap = u 0 10 65536

    lxc-start: tools/lxc_start.c: main: 284 Failed to create lxc_container"

The container config containing

"lxc.idmap = u 0 10 65536
lxc.idmap = g 0 10 65536"

output from grep root /etc/sub* 2>/dev/null

    "/etc/subgid:root:10:65536
    /etc/subuid:root:10:65536"

Bug#897111: pypandoc: diff for NMU version 1.4+ds0-1.1

[Sebastian Ramacher]

Control: tags 897111 + patch
Control: tags 897111 + pending

Dear maintainer,

I've prepared an NMU for pypandoc (versioned as 1.4+ds0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru pypandoc-1.4+ds0/debian/changelog pypandoc-1.4+ds0/debian/changelog
--- pypandoc-1.4+ds0/debian/changelog	2017-06-18 17:50:07.0 +0200
+++ pypandoc-1.4+ds0/debian/changelog	2018-05-21 11:00:13.0 +0200
@@ -1,3 +1,11 @@
+pypandoc (1.4+ds0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Apply upstream patches to fix compatibility with recent
+pandoc versions. (Closes: #897111)
+
+ -- Sebastian Ramacher   Mon, 21 May 2018 11:00:13 +0200
+
 pypandoc (1.4+ds0-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru pypandoc-1.4+ds0/debian/patches/0003-Fix-tests-with-newer-pandoc.patch pypandoc-1.4+ds0/debian/patches/0003-Fix-tests-with-newer-pandoc.patch
--- pypandoc-1.4+ds0/debian/patches/0003-Fix-tests-with-newer-pandoc.patch	1970-01-01 01:00:00.0 +0100
+++ pypandoc-1.4+ds0/debian/patches/0003-Fix-tests-with-newer-pandoc.patch	2018-05-21 10:57:11.0 +0200
@@ -0,0 +1,159 @@
+From ea9d2642f91489646b56faf13d8a852e7b737b0b Mon Sep 17 00:00:00 2001
+From: Jan Schulz 
+Date: Fri, 6 Apr 2018 02:03:32 +0200
+Subject: [PATCH] Fix tests with newer pandoc
+
+---
+ tests.py | 38 +++---
+ 1 file changed, 19 insertions(+), 19 deletions(-)
+
+--- a/tests.py
 b/tests.py
+@@ -134,7 +134,7 @@
+ self.assertTrue(isinstance(version, pypandoc.string_types))
+ major = int(version.split(".")[0])
+ # according to http://pandoc.org/releases.html there were only two versions 0.x ...
+-self.assertTrue(major in [0, 1])
++self.assertTrue(major in [0, 1, 2])
+ 
+ def test_converts_valid_format(self):
+ self.assertEqualExceptForNewlineEnd(pypandoc.convert("ok", format='md', to='rest'), 'ok')
+@@ -150,7 +150,7 @@
+ self.assertRaises(RuntimeError, f)
+ 
+ def test_basic_conversion_from_file(self):
+-with closed_tempfile('.md', text='#some title\n') as file_name:
++with closed_tempfile('.md', text='# some title\n') as file_name:
+ expected = u'some title{0}=={0}{0}'.format(os.linesep)
+ received = pypandoc.convert(file_name, 'rst')
+ self.assertEqualExceptForNewlineEnd(expected, received)
+@@ -158,7 +158,7 @@
+ def test_basic_conversion_from_file_url(self):
+ # this currently doesn't work: https://github.com/jgm/pandoc/issues/3196
+ return
+-with closed_tempfile('.md', text='#some title\n') as file_name:
++with closed_tempfile('.md', text='# some title\n') as file_name:
+ expected = u'some title{0}=={0}{0}'.format(os.linesep)
+ # this keeps the : (which should be '|' on windows but pandoc
+ # doesn't like it
+@@ -176,14 +176,14 @@
+ 
+ def test_convert_with_custom_writer(self):
+ lua_file_content = self.create_sample_lua()
+-with closed_tempfile('.md', text='#title\n') as file_name:
++with closed_tempfile('.md', text='# title\n') as file_name:
+ with closed_tempfile('.lua', text=lua_file_content, dir_name="foo-bar+baz") as lua_file_name:
+ expected = u'title{0}'.format(os.linesep)
+ received = pypandoc.convert_file(file_name, lua_file_name)
+ self.assertEqualExceptForNewlineEnd(expected, received)
+ 
+ def test_basic_conversion_from_file_with_format(self):
+-with closed_tempfile('.md', text='#some title\n') as file_name:
++with closed_tempfile('.md', text='# some title\n') as file_name:
+ expected = u'some title{0}=={0}{0}'.format(os.linesep)
+ received = pypandoc.convert(file_name, 'rst', format='md')
+ self.assertEqualExceptForNewlineEnd(expected, received)
+@@ -193,11 +193,11 @@
+ 
+ def test_basic_conversion_from_string(self):
+ expected = u'some title{0}=={0}{0}'.format(os.linesep)
+-received = pypandoc.convert('#some title', 'rst', format='md')
++received = pypandoc.convert('# some title', 'rst', format='md')
+ self.assertEqualExceptForNewlineEnd(expected, received)
+ 
+ expected = u'some title{0}=={0}{0}'.format(os.linesep)
+-received = pypandoc.convert_text('#some title', 'rst', format='md')
++received = pypandoc.convert_text('# some title', 'rst', format='md')
+ self.assertEqualExceptForNewlineEnd(expected, received)
+ 
+ def test_conversion_with_markdown_extensions(self):
+@@ -215,16 +215,16 @@
+ def test_conversion_from_markdown_with_extensions(self):
+ input = u'~~strike~~'
+ expected_with_extension = u'strike'
+-expected_without_extension = u'strike'
++#expected_without_extension = u'stri

Bug#897953: dvtm: Please stop shipping dvtm and dvtm-256color terminfo entries

[Sven Joachim]

On 2018-05-12 16:23 +0300, kact...@gnu.org wrote:

> control: tags -1 +pending
>
> [2018-05-05 08:29] Sven Joachim 
>> In early 2017, the dvtm and dvtm-256color terminfo entries were added to
>> ncurses upstream, and I would like to include them in the ncurses-term
>> package, replacing the ones shipped currently in the dvtm package.
>> 
>> This requires coordinated uploads of dvtm and ncurses, adding a
>> versioned Breaks/Replaces on dvtm to ncurses-term and a versioned
>> dependency on ncurses-term to dvtm.
>
> Sure. I just uploaded dvtm_0.15-3, that depends on 
> ncurses-term (>> 6.1+20180210-2) into DELAYED/10. 
>
> As such, I expect it to arrive at 2018/05/22. I propose you to make new
> upload of ncurses-term with apporiate Breaks/Depends into DELAYED in
> such way, that our packages arrive at same time.

Just uploaded ncurses 6.1+20180210-4 to DELAYED/1, thanks.

Cheers,
   Sven

Bug#899229: lava-server: [INTL:fr] French debconf translation

[jean-pierre giraud]

Package: lava-server
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french debconf translation
file, proofread by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.gz
Description: application/gzip

Bug#899230: prometheus: [INTL:fr] French debconf translation

[jean-pierre giraud]

Package: prometheus
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french debconf translation
file, proofread by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.gz
Description: application/gzip

Bug#897516: Decreasing fail-under parameter helps passing the test

[GCS]

On Sun, May 20, 2018 at 2:00 PM Andreas Tille  wrote:
> On Thu, May 10, 2018 at 10:00:07AM +0200, Andreas Tille wrote:
> I've uploaded a package with decreased fail-limit and hereby I'm
> decreasing the severity of the bug.  Further investigation about the
> failure should be done - possibly by involving upstream.

> > Laszlo, before I'll dive deeper into it I'd like to know what you think
> > about maintaining this package in Debian Python Modules Team.  I'd
> > volunteer to create a Git repository on Salsa and try to fix this bug
> > if you agree to it.

> Since you did not raised disagreement I uploaded on behalf of the
> DPMT and commited the package to Salsa[1].
  I didn't agreed either. Possibly due to that I was not online for some
days. But no problem, I see you maintain it.

Thanks,
Laszlo/GCS

Bug#899231: new upstream versions

[Harald Dunkel]

Package: lxc
Version: 2.0.9-6

Upstream provides new versions 2.1 and 3.0, see 
https://linuxcontainers.org/lxc/news/. AFAIK there are new versions in the 
Ubuntu repository as well. Do you think they could be included in Debian, 
before Buster is frozen?

Thanx in advance
Harri

Bug#899233: ITP: sqlalchemy-i18n -- Internationalization extension for SQLAlchemy models

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 

* Package name: sqlalchemy-i18n
  Version : 1.0.3
  Upstream Author : Konsta Vesterinen 
* URL : https://github.com/kvesteri/sqlalchemy-i18n
* License : BSD-3-clause
  Programming Lang: Python
  Description : Internationalization extension for SQLAlchemy models

 Extend SQLAlchemy models to include translations in different languages.
 .
 Each model can have an associated model that contains translatable fields.
 .
 Translatable attributes are available in the current locale via a hybrid
 property on the base model.

I plan to maintain this package as part of the python modules team.
-- 
Edward.

Bug#810605: nautilus: Crash when logging in to flashback mode

[Sam Morris]

Source: nautilus
Followup-For: Bug #810605
Version: 3.26.3.1-1

Not seen this one for a while.

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (540, 'stable-updates'), (540, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Sam Morris 
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#899234: git-buildpackage: gbp-push fails when there is no upstream branch

[Paride Legovini]

Package: git-buildpackage
Version: 0.9.8
Severity: normal

Dear gbp maintainers/devs,

When working with git remotes and tags (instead of importing upstream
tarballs) an upstream branch is not normally not needed or wanted. This
kind of workflow is not uncommon, in fact is is suggested by the gbp
documentation:

/usr/share/doc/git-buildpackage/manual-html/gbp.import.upstream-git.html

and DEP14 somehow implies that an upstream branch may not exist by not
mentioning it at all in the "Importing upstream releases from Git tags"
section.

Now, coming to the point of this report. When ‘gbp push’ is called, it
will look for the branch where commit tagged with the release version
lies, and it will try to push this refspec to the corresponding remote
branch. When working without an upstream branch, the tag will refer to a
commit in the debian branch, and this commit will be behind the branch tip.
As gbp-push pushes up the the tag, the push command will fail
("non-fast-forward" error).

One way to work around this would be to check if the commit has already
been pushed. This should be doable with:

git branch -r --contains 

which should probably be run after a fetch. People with a more complete
picture of gbp in mind will probably have better ideas.

Cheers,

Paride

Bug#897953: dvtm: Please stop shipping dvtm and dvtm-256color terminfo entries

[Thomas Dickey]

- Original Message -
| From: "Sven Joachim" 
| To: kact...@gnu.org
| Cc: 897...@bugs.debian.org, ncur...@packages.debian.org
| Sent: Monday, May 21, 2018 5:07:15 AM
| Subject: Re: Bug#897953: dvtm: Please stop shipping dvtm and dvtm-256color 
terminfo entries
| 
| On 2018-05-12 16:23 +0300, kact...@gnu.org wrote:
| 
| > control: tags -1 +pending
| >
| > [2018-05-05 08:29] Sven Joachim 
| >> In early 2017, the dvtm and dvtm-256color terminfo entries were
| >> added to
| >> ncurses upstream, and I would like to include them in the
| >> ncurses-term
| >> package, replacing the ones shipped currently in the dvtm package.
| >> 
| >> This requires coordinated uploads of dvtm and ncurses, adding a
| >> versioned Breaks/Replaces on dvtm to ncurses-term and a versioned
| >> dependency on ncurses-term to dvtm.
| >
| > Sure. I just uploaded dvtm_0.15-3, that depends on
| > ncurses-term (>> 6.1+20180210-2) into DELAYED/10.
| >
| > As such, I expect it to arrive at 2018/05/22. I propose you to make new
| > upload of ncurses-term with apporiate Breaks/Depends into DELAYED in
| > such way, that our packages arrive at same time.
| 
| Just uploaded ncurses 6.1+20180210-4 to DELAYED/1, thanks.

The package's versions of the terminfo entries have 2-3 errors in them.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net

Bug#899235: RFS: gnustep-base/1.25.1-4

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

 Dear mentors,

I am looking for a sponsor for my package "gnustep-base".

 * Package name: gnustep-base
   Version : 1.25.1-4
   Upstream Author : Richard Frith-Macdonald ,
 Adam Fedor  and many others
 * URL : http://gnustep.org
 * License : LGPL-2.1+ (library), GPL-3+ (tools/daemons)
   Section : gnustep

It builds these binary packages:

gnustep-base-common - GNUstep Base library - common files
gnustep-base-doc - Documentation for the GNUstep Base Library
gnustep-base-runtime - GNUstep Base library - daemons and tools
libgnustep-base-dev - GNUstep Base header files and development libraries
libgnustep-base1.25 - GNUstep Base library

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

  https://mentors.debian.net/package/gnustep-base

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnustep-base/gnustep-base_1.25.1-4.dsc

Or clone the Git repository at:

  https://salsa.debian.org/gnustep-team/gnustep-base

Changes since the last upload:

  * debian/patches/hurd-systemuptime.patch: New, fix intermittent test
failure/FTBFS on GNU/Hurd when procfs is not available.
  * debian/patches/series: Update.
  * debian/templates/control.m4: Move Suggests: gnustep-base-doc from
-common to the -dev package as it is most useful for developers.
Remove version requirement; not really needed.  Likewise, let the -doc
package recommend -dev without specific version.
  * debian/control: Regenerate.

Bug#898281: closed by Michael Prokop (Bug#898281: fixed in libguytools2 2.0.5-2)

[Michael Prokop]

* Helmut Grohne [Sat May 19, 2018 at 12:40:30PM +0200]:
> On Fri, May 18, 2018 at 12:27:03PM +, Debian Bug Tracking System wrote:

> >* [1f3de7a] Apply patch to fix FTCBFS. Thanks to Helmut Grohne
> >   for bugreport + patch (Closes: #898281)

> I'm not quite sure how you managed to do this, but the bug is only
> partially fixed. When building a source package, what is relevant is the
> Build-Depends from the .dsc file. While the unpacked debian/control has
> qt5-qmake:native, the .dsc file doesn't. Thus one gets an error from
> dpkg-checkbuilddeps when trying to build.

> Did you maybe use a very old dpkg-source? Please verify that the
> Build-Depends properly propagate from debian/control to .dsc for your
> next upload.

Yes, this was exactly my issue (dpkg-source from Debian/jessie).
Stumbled into this trap already once in a similar situation. :(
Thanks for spotting, will take care with another upload soon-ish.

regards,
-mika-


signature.asc
Description: Digital signature

Bug#886473: apt-setup lacks a dependency on gnupg

[Philipp Kern]

On 1/15/18 2:53 AM, Cyril Brulebois wrote:
> We should be fixing this bug to stop using apt-key, and start putting
> files under the right location with the right filename:
>   https://bugs.debian.org/851774
> 
> This would render the need for gnupg moot, as we would move away from
> using a deprecated way of adding keys.

So what's the current contract with apt? ASCII-armored files need to go
into .asc and binary files into .gpg? Is the right way to infer ASCII
armor to grep for the preamble? Also right now we discard the file name
of the key fetched, is that something we'd want to preserve?

(I sort of agree that we should drop files into the right place, on the
other hand the fix would be "apt-install gnupg" with the current setup.)

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#899235: RFS: gnustep-base/1.25.1-4

[Peter Pentchev]

On Mon, May 21, 2018 at 12:26:52PM +0300, Yavor Doganov wrote:
> Package: sponsorship-requests
> Severity: normal
> 
>  Dear mentors,
> 
> I am looking for a sponsor for my package "gnustep-base".
> 
>  * Package name: gnustep-base
>Version : 1.25.1-4

Uploaded, thanks!  A small idea for the future: adding
a debian/upstream/metadata file might be nice.

Please feel free to contact me directly for future uploads.

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#790482: Mirrors deliber bzip2 content under regular filename

[Niels Thykier]

reassign 790482 mirrors
retitle 790482 ftp2.de.d.o serves bzip2 instead of plain-text / 404
thanks

Hi,

I am reassigning this old (but still reproducible) bug to the mirror
team as I assume they can help with getting ftp2.de.d.o to tweak their
configuration or at least help forward it.

I am quoting Eduard's mail in full below for the mirror team's
convenience and my reproduction attempt is appended below that mail.

Thanks,
~Niels


On Sat, 22 Aug 2015 15:49:27 +0200 Eduard Bloch  wrote:
> Hallo,
> * Raphael Geissert [Sat, Aug 22 2015, 01:16:44AM]:
> > Hi,
> > 
> > How is this relevant to ftp master?
> > 
> > APT does the right thing in order to cope with those mirrors that
> > happen to have apache multiviews enabled.
> 
> Huh? I was not talking about APT. I also don't think it's an apache
> problem, I blame nginx for this crap.
> 
> I reported this bug here since I assumed that the maintainers here are
> doing some basic QA work and can dispatch the issue accordingly.
> 
> And regarding multiview, see below. Even when I set Accept-Encoding: to
> identity, this does not change a thing. You might argue that 
> SHOULD!=MUST but it's still a broken way to handle this situation, IMHO.
> 
> | If an Accept-Encoding field is present in a request, and if the server
> | cannot send a response which is acceptable according to the
> | Accept-Encoding header, then the server SHOULD send an error response
> | with the 406 (Not Acceptable) status code.
> 
> GET /debian/dists/unstable/main/i18n/Translation-de HTTP/1.1
> User-Agent: Wget/1.16.3 (linux-gnu)
> Accept: */*
> Accept-Encoding: identity
> Host: ftp2.de.debian.org
> Connection: Keep-Alive
> 
> HTTP/1.1 200 OK
> Server: nginx/1.6.2
> Date: Sat, 22 Aug 2015 13:29:00 GMT
> Content-Type: application/x-bzip2
> Content-Length: 1832158
> Connection: keep-alive
> Content-Location: Translation-de.bz2
> Vary: negotiate
> TCN: choice
> Last-Modified: Sat, 25 Apr 2015 03:14:16 GMT
> ETag: "1bf4de-51483e868b200;51de294049878"
> Accept-Ranges: byte
> 
> Regards,
> Eduard.
> 
> -- 
>  argumentum ad populum?
>  argentum ad wirhabengenugdavonum
> 
> 

My reproduction attempt today:

> $ curl -vH 'Accept-Encoding: identity' 
> http://ftp2.de.debian.org/debian/dists/unstable/main/i18n/Translation-de  
> -o/dev/null
> [...]
> > GET /debian/dists/unstable/main/i18n/Translation-de HTTP/1.1
> > Host: ftp2.de.debian.org
> > User-Agent: curl/7.58.0
> > Accept: */*
> > Accept-Encoding: identity
> > 
> < HTTP/1.1 200 OK
> < Server: nginx/1.10.3
> < Date: Mon, 21 May 2018 10:57:52 GMT
> < Content-Type: application/x-bzip2
> < Content-Length: 1642052
> < Connection: keep-alive
> < Content-Location: Translation-de.bz2
> < Vary: negotiate
> < TCN: choice
> < Last-Modified: Mon, 21 May 2018 03:51:56 GMT
> < Accept-Ranges: bytes
> < 

Bug#899234: git-buildpackage: gbp-push fails when there is no upstream branch

[Guido Günther]

Hi,
On Mon, May 21, 2018 at 11:22:31AM +0200, Paride Legovini wrote:
> Package: git-buildpackage
> Version: 0.9.8
> Severity: normal
> 
> Dear gbp maintainers/devs,
> 
> When working with git remotes and tags (instead of importing upstream
> tarballs) an upstream branch is not normally not needed or wanted. This
> kind of workflow is not uncommon, in fact is is suggested by the gbp
> documentation:
> 
> /usr/share/doc/git-buildpackage/manual-html/gbp.import.upstream-git.html

I think the documentation above does not suggest that there is no
upstream branch, rather that you don't need gbp import-orig to maintain
it. At least that's the intention. If that's not the case please let
me know where you read that not having a branch with pristine upstream
source is a good idea. We should fix that then.

> and DEP14 somehow implies that an upstream branch may not exist by not
> mentioning it at all in the "Importing upstream releases from Git tags"
> section.
> 
> Now, coming to the point of this report. When ‘gbp push’ is called, it
> will look for the branch where commit tagged with the release version
> lies, and it will try to push this refspec to the corresponding remote
> branch. When working without an upstream branch, the tag will refer to a
> commit in the debian branch, and this commit will be behind the branch tip.

"in the debian branch" is not defined in git. Upstream as well as Debian
tags are always reachable from the Debian branch. Upstream-tags are
reachable from the Upstream branch as well whereas Debian tags are not..

By released version do you refer to the Debian or upstream version?

> As gbp-push pushes up the the tag, the push command will fail
> ("non-fast-forward" error).

As reportbug suggests: please include the full output run with "-v".
Even better provide a repo and steps to reproduce. Can you provide
either of these please?

I think I can see where the problem you describe comes from but it's
unrelated whether you have an upstream branch or not (I'm maintaining
several packages directly out of git). It's a rather long standing bug
in "gbp push" that it doesn't cope well with pushing older releases I
think it did not make it to the BTS yet so this report is the perfect
opportunity!

> One way to work around this would be to check if the commit has already
> been pushed. This should be doable with:
> 
> git branch -r --contains 

Yeah, that's what I had i mind but we might end up having to run "gbp
clone" first (or at least suggesting that to the user). But I'd like to
understand the full problem first.
Cheers,
 -- Guido

> which should probably be run after a fetch. People with a more complete
> picture of gbp in mind will probably have better ideas.
> 
> Cheers,
> 
> Paride

Bug#897516: Decreasing fail-under parameter helps passing the test

[Andreas Tille]

Hi László,

On Mon, May 21, 2018 at 11:15:13AM +0200, László Böszörményi (GCS) wrote:
> > > Laszlo, before I'll dive deeper into it I'd like to know what you think
> > > about maintaining this package in Debian Python Modules Team.  I'd
> > > volunteer to create a Git repository on Salsa and try to fix this bug
> > > if you agree to it.
> 
> > Since you did not raised disagreement I uploaded on behalf of the
> > DPMT and commited the package to Salsa[1].
>   I didn't agreed either.

I did not intended to tip on your toes.  I simply experienced that
people did not responded for a long time and since bug #897516 is now
removing several packages in Debian Med maintenance out of testing,
I felt some action would be needed.

> Possibly due to that I was not online for some
> days. But no problem, I see you maintain it.

Unfortunately the issue is not yet solved.  If you have some contact to
upstream (which does not seem very active) or personal insight it would
be really helpful. 

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#855817: Please hide automatic debug packages from NEW overview pages

[Niels Thykier]

On Wed, 22 Feb 2017 01:03:01 + James Clarke  wrote:
> Package: ftp.debian.org
> Severity: wishlist
> Tags: patch
> User: ftp.debian@packages.debian.org
> Usertags: dak
> 
> Hi,
> Currently, the NEW package overview pages include all the automatic
> debug packages, which makes it very noisy. Please consider the attached
> untested patch, which should (hopefully) hide these packages when they
> are not considered NEW.
> 
> Regards,
> James

Hi James,

I see you have this old patch that has not been applied.  In the last
few days, there have been a number of patches merged into dak via salsa.d.o.

Please consider rebasing your patch and create a Merge Request to dak
via: https://salsa.debian.org/ftp-team/dak/merge_requests

I hope this will expedite the merge of your patch. :)

Thanks,
~Niels

Bug#899235: RFS: gnustep-base/1.25.1-4

[Yavor Doganov]

Peter Pentchev wrote:
> On Mon, May 21, 2018 at 12:26:52PM +0300, Yavor Doganov wrote:
> > I am looking for a sponsor for my package "gnustep-base".
> 
> Uploaded, thanks!

Many thanks for sponsoring and congratulations for becoming a DD!

> A small idea for the future: adding a debian/upstream/metadata file
> might be nice.

For the time being I am ignoring this in all my packages because:

- the DEP is not accepted yet so there might be changes in the
  format/implementation.
- I hope it won't be accepted, ever.  It is actually useful only for a
  (small) set of packages.

> Please feel free to contact me directly for future uploads.

Thanks!  Do you mean for gnustep-base only or for the whole GNUstep
stack?  If it's the latter, I've got three other RFS (#898363, #898403
and #898534).

Bug#825398: [PATCH] Don't be so eager to remove outdated arch:all binary packages

[Niels Thykier]

On Tue, 6 Dec 2016 17:22:22 + James Clarke  wrote:
> Updated patch:
> 
>  * Removed stray whitespace change
>  * Fixed comment in queryNBS
> 
> Regards,
> James

Hi James,

I see you have this old patch that has not been applied.  In the last
few days, there have been a number of patches merged into dak via salsa.d.o.

Please consider rebasing your patch and create a Merge Request to dak
via: https://salsa.debian.org/ftp-team/dak/merge_requests

I hope this will expedite the merge of your patch.

Thanks,
~Niels

(IANA FTP-master)

Bug#899235: RFS: gnustep-base/1.25.1-4

[Peter Pentchev]

On Mon, May 21, 2018 at 02:22:51PM +0300, Yavor Doganov wrote:
> Peter Pentchev wrote:
> > On Mon, May 21, 2018 at 12:26:52PM +0300, Yavor Doganov wrote:
> > > I am looking for a sponsor for my package "gnustep-base".
> > 
> > Uploaded, thanks!
> 
> Many thanks for sponsoring and congratulations for becoming a DD!

Thanks :)

> > A small idea for the future: adding a debian/upstream/metadata file
> > might be nice.
> 
> For the time being I am ignoring this in all my packages because:
> 
> - the DEP is not accepted yet so there might be changes in the
>   format/implementation.
> - I hope it won't be accepted, ever.  It is actually useful only for a
>   (small) set of packages.

OK, no worries; it's completely at the maintainer's discretion.
I guess we may take this discussion off-line; I was just making sure
that you were aware of it (and it was kind of stupid of me to presume
that you were not, judging from the overall great quality of
the gnustep-base package; sorry about that).

> > Please feel free to contact me directly for future uploads.
> 
> Thanks!  Do you mean for gnustep-base only or for the whole GNUstep
> stack?  If it's the latter, I've got three other RFS (#898363, #898403
> and #898534).

The whole GNUstep stack; I was just looking through -mentors for other
RFS messages from you.  I'll look at these, too.

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#898363: RFS: wrapperfactory.app/0.1.0-5

[Peter Pentchev]

Control: owner -1 !

On Thu, May 10, 2018 at 10:47:16PM +0300, Yavor Doganov wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "wrapperfactory.app".
> 
>  * Package name: wrapperfactory.app
>Version : 0.1.0-5

I'm looking at this one.  Thanks for your work!

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#898403: RFS: batmon.app/0.9-2 [RC]

[Peter Pentchev]

Control: owner -1 !

On Fri, May 11, 2018 at 11:19:53AM +0300, Yavor Doganov wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "batmon.app".
> 
>  * Package name: batmon.app
>Version : 0.9-2

I'm looking at this one; thanks for your work!

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#898534: RFS: ftp.app/0.6-2 [RC]

[Peter Pentchev]

Control: owner -1 !

On Sun, May 13, 2018 at 11:08:29AM +0300, Yavor Doganov wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ftp.app".
> 
>  * Package name: ftp.app
>Version : 0.6-2

I'm looking at this one; thanks for your work!

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#899237: RFP: markup.ml -- Error-recovering streaming HTML5 and XML parsers

[Mehdi Dogguy]

Package: wnpp
Severity: wishlist

* Package name: markup.ml
  Version : 0.7.6
  Upstream Author : Anton Bachin
* URL : https://github.com/aantron/markup.ml
* License : BSD-2
  Programming Lang: OCaml
  Description : Error-recovering streaming HTML5 and XML parsers

Markup.ml is a pair of parsers implementing the HTML5 and XML
specifications, including error recovery. Usage is simple, because
each parser is a function from byte streams to parsing signal streams.

This software is needed as a new build dependency for tyxml.

Bug#899238: RFP: ppx-tools-versioned -- Tools for authors of ppx rewriters

[Mehdi Dogguy]

Package: wnpp
Severity: wishlist

* Package name: ppx-tools-versioned
  Version : 5.1
  Upstream Author : Alain Frisch and al.
* URL : https://github.com/ocaml-ppx/ppx_tools_versioned
* License : MIT
  Programming Lang: OCaml
  Description : Tools for authors of ppx rewriters

This library is a variant of ppx-tools where all tools are versioned.
It is needed to build latest versions of tyxml.

Bug#869114: status of the topkg package

[Mehdi Dogguy]

Hi,

On 2018-05-21 08:49, Andy Li wrote:

Hi Hendrik,

What is the status of the topkg package?
I want to update jsonm, which now depends on topkg.



FWIW, I updated jsonm today using a custom debian/rules file (the
famous debian/rules file used for pretty much all Daniel's software
packaged in Debian).

Regards,

--
Mehdi

Bug#835103: powerline: shell/default.json do not display the right side

[Daniel Baumann]

Hi,

given that bash doesn't support the right-side of a prompt, there's
nothing powerline can do about it, hence I wonder if this bug report
shouldn't be closed (or reassigned as an upstream-wishlist bug to bash).

somewhat related to that, the switching of the default theme to
default_leftonly.json for shell can be covered with #899153.

Regards,
Daniel

Bug#899239: java-package: please add support for java 10

[Frédéric Baldit]

Package: java-package
Version: 0.62
Severity: normal

Dear Maintainer,

the following command worked for me with java 8 but failed for java 10:

$ make-jpkg jdk-10.0.1_linux-x64_bin.tar.gz
Creating temporary directory: /tmp/make-jpkg.KtGzbUGZ37
Loading plugins: /usr/share/java-package/common.sh /usr/share/java-
package/javase.sh /usr/share/java-package/jdk-doc.sh /usr/share/java-
package/oracle-jdk-doc.sh /usr/share/java-package/oracle-jdk.sh
/usr/share/java-package/oracle-jre.sh /usr/share/java-package/oracle-server-
jre.sh

Detected Debian build architecture: amd64
Detected Debian GNU type: x86_64-linux-gnu

No matching packaging method was found for
jdk-10.0.1_linux-x64_bin.tar.gz. Please make sure you are using a
tar.gz or a self-extracting archive Removing temporary directory: done

It seems this bug is similar to the one previously reported for java 9
(#876426), but now Oracle is only provinding java 10 and java 8 jdks.

Thank's in advance for any help,


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

Kernel: Linux 4.9.0-6-amd64 (SMP w/8 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 java-package depends on:
ii  build-essential  12.3
ii  debhelper10.2.5
ii  dpkg-dev 1.18.24
ii  fakeroot 1.21-3.1
ii  libasound2   1.1.3-5
ii  libfontconfig1   2.11.0-6.7+b1
ii  libgl1-mesa-glx  13.0.6-1+b2
ii  libgtk2.0-0  2.24.31-2
ii  libx11-6 2:1.6.4-3
ii  libxslt1.1   1.1.29-2.1
ii  libxtst6 2:1.2.3-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  unzip6.0-21

java-package recommends no packages.

Versions of packages java-package suggests:
pn  openjdk-7-jre  

-- no debconf information




--
  Frédéric Baldit

Bug#813226: tzdata config script ignores /etc/timezone on non-interactive configuration

[Raymond Rakesh Chetty]

Copy paste error: https://stackoverflow.com/a/20693661

Don't forget the 1 at the end or you get sent to the wrong place =).

Somewhat related... maybe I have a misunderstanding of debconf... can you
reconfigure packages that belong to 'd-i'? There are a lot of preseed
questions belonging to 'd-i' (debian-installer), would it make sense (is it
possible?) to allow reconfiguration using parts of the installer
configuration/debconf answers? Not sure there is a reason to have all of
d-i clock-setup/utc, d-i time/zone & tzdata tzdata/Areas etc. But that
might be a discussion left to another day (or maybe the documentation is
out of date?).


$ sudo debconf-get-selections --installer | grep -v '#' | grep 'd-i' | grep
zone
$ sudo debconf-get-selections | grep -v '#' | grep 'd-i' | grep zone
https://www.debian.org/releases/stable/amd64/apbs04.html.en#preseed-time

On Sun, May 20, 2018 at 8:40 PM, Raymond Rakesh Chetty <
raymond.che...@berkeley.edu> wrote:

> Why isn't debconf the single source of truth for tzdata configuration? If
> you used debconf then people wouldn't rely on implementation details to
> correctly configure their systems. Abstract configuration from
> implementation (i.e. separate timezone from is the file a link?, where is
> it located?, which file needs the right information?)
>
> https://stackoverflow.com/a/2069366 would be the top vote and everybody
> would have (or soon obtain) a good (some) understanding of debconf.
>
> All people need to know is what question is going to get asked, or needs
> answering (debconf-show + some documentation). Isn't that how debian is
> supposed to work? https://wiki.debian.org/debconf
>
> The original timezone configuration would get assigned with:
>
> $ echo "tzdata tzdata/Areas select Asia" | sudo debconf-set-selections
>
> $ echo "tzdata tzdata/Zones/Asia select Tokyo" | sudo debconf-set-selection
>
> $ dpkg-reconfigure -fnoninteractive tzdata
>
> --
> Best,
> Raymond Chetty
>
> raymond.che...@berkeley.edu
>
> Confidentiality Notice: This e-mail message, including any attachments, is
> for the sole use of the intended recipient(s) and may contain confidential
> and privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message.
>



-- 
Best,
Raymond Chetty

raymond.che...@berkeley.edu

Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

Bug#899234: git-buildpackage: gbp-push fails when there is no upstream branch

[Paride Legovini]

On 21/05/2018 13.04, Guido Günther wrote:
> Hi,

Hi Guido, thanks for your reply.

> On Mon, May 21, 2018 at 11:22:31AM +0200, Paride Legovini wrote:
>>
>> When working with git remotes and tags (instead of importing upstream
>> tarballs) an upstream branch is not normally not needed or wanted. This
>> kind of workflow is not uncommon, in fact is is suggested by the gbp
>> documentation:
>>
>> /usr/share/doc/git-buildpackage/manual-html/gbp.import.upstream-git.html
> 
> I think the documentation above does not suggest that there is no
> upstream branch, rather that you don't need gbp import-orig to maintain
> it. At least that's the intention. If that's not the case please let
> me know where you read that not having a branch with pristine upstream
> source is a good idea. We should fix that then.

I was hoping to get a comment on this. :)

The idea that gbp.import.upstream-git.html somehow suggests that an
upstream branch is not necessary comes from the following facts:

(1) In the proposed workflow, an upstream branch is not mentioned. The
document is almost a step-by-step guide, for example it shows how to
fetch and merge a new upstream release, but no hint is given on how to
maintain an upstream branch.

(2) By following that workflow, the master branch is almost what an
upstream branch should be. Actually, in the beginning I thought that I
had to consider the upstream branch to be "master". But this branch is
never updated: the new upstream versions are merged directly in the
Debian branch.

(3) When releases are tagged upstream, I don't see the advantage of
maintaining an upstream branch. Tags can be checkedout and already
represent the pristine upstream source. This seems to be a sound idea,
and in fact by default we have upstream-tree=TAG.

Should we conclude that I'm wrong and that there are good reasons to
maintain an upstream branch, then the central point of this report will
cease to exist.

>> and DEP14 somehow implies that an upstream branch may not exist by not
>> mentioning it at all in the "Importing upstream releases from Git tags"
>> section.

And, should we conclude that an upstream branch has to be maintained, I
think DEP14 should be more explicit on this point.

>> Now, coming to the point of this report. When ‘gbp push’ is called, it
>> will look for the branch where commit tagged with the release version
>> lies, and it will try to push this refspec to the corresponding remote
>> branch. When working without an upstream branch, the tag will refer to a
>> commit in the debian branch, and this commit will be behind the branch tip.
> 
> "in the debian branch" is not defined in git. Upstream as well as Debian
> tags are always reachable from the Debian branch. Upstream-tags are
> reachable from the Upstream branch as well whereas Debian tags are not..
> 
> By released version do you refer to the Debian or upstream version?

I forgot to mention something here -- sorry. If there is no upstream
branch, gbp-push fails as you may expect (debian-branch=debian/sid):

$ gbp push --verbose --dry-run
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/debian/sid']
gbp:debug: ['git', 'config', 'branch.debian/sid.remote']
gbp:debug: ['git', 'tag', '-l', 'debian/1.5.0-1']
gbp:debug: ['git', 'tag', '-l', '1.5.0']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', '1.5.0^{commit}']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify',
'refs/heads/upstream']
gbp:error: revision 'refs/heads/upstream' not found

I tried to work around this error by setting upstream-branch=debian/sid
(that is, upstream-branch = debian-branch). It is the branch that
contains the commit the upstream version tag refers to, after all. In
this case we get the behavior I described:

$ gbp push --verbose --dry-run
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/debian/sid']
gbp:debug: ['git', 'config', 'branch.debian/sid.remote']
gbp:debug: ['git', 'tag', '-l', 'debian/1.5.0-1']
gbp:debug: ['git', 'tag', '-l', '1.5.0']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', '1.5.0^{commit}']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify',
'refs/heads/debian/sid']
gbp:info: Dry-run: Pushing 1.5.0 to origin
gbp:debug: ['git', 'push', 'origin', 'tag', '1.5.0', '--dry-run']
gbp:info: Dry-run: Pushing 2ac8d1947dab3f545fe42d910681dd0253cb79a3 to
origin:refs/heads/debian/sid
gbp:debug: ['git', 'push', 'origin', '--dry-run',
'2ac8d1947dab3f545fe42d910681dd0253cb79a3:refs/heads/debian/sid']
gbp:error: Error running git push: To salsa.debian.org:paride-guest/spm.git
 ! [rejected]2ac8d1947dab3f545fe42d910681dd0253cb79a3 ->
debian/sid (non-fast-forward)
error: 

Bug#898613: [git-buildpackage/master] docs: document how to use GBP_CONF_FILES to override debian/gbp.conf

[Guido Günther]

tag 898613 pending
thanks

Date:   Mon May 21 13:26:30 2018 +0200
Author: Guido Günther 
Commit ID: a1f4af5504373c1e1e65e98054a7f1040c21358a
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=a1f4af5504373c1e1e65e98054a7f1040c21358a
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=a1f4af5504373c1e1e65e98054a7f1040c21358a

docs: document how to use GBP_CONF_FILES to override debian/gbp.conf

Closes: #898613

  

Bug#899240: debian-installer: blank screen on boot (6th Gen. ThinkPad X1)

[Matti Pöllä]

Package: debian-installer
Severity: normal
Tags: d-i

Dear Maintainer,

booting to Debian Installer fails on a 6th Generation Lenovo ThinkPad
X1 (type 20KH-006MMX) with the following symptoms:

* Boot from a Debian installation media (mini.iso 2018-05-18 on a USB
  drive). Also tested with Wheezy, Jessie, Stretch and Testing amd64
  ISOs.

* GRUB menu (version 2.02-2) shows options "Install", "Advanced
  options" and "Install with speech synthesis".

* On entering "Install", the screen goes blank. The machine is still
  powered on and the keyboard leds respond to, e.g., the "mute"
  button. Switching to virtual terminals does not help as the screen
  appears dead.

Similar problems with a blank screen have been reported on earlier
versions of the ThinkPad X1 (see
https://bbs.archlinux.org/viewtopic.php?id=210007) with workarounds
involving boot parameters intel_pstate=no_hwp or
intel_pstate=disable. In this case, this does not help. Also, the bug
appears on several kernel versions (from 3.16 in Jessie).

Booting to a live environment using debian-live-9.3.0-amd64-gnome.iso
is not affected by the bug. The live system uses a full 2560x1440
resolution on a 4.9.0-4-amd64 kernel. However, the "Install" option on
the same ISO results in a blank screen.

Bug#886473: apt-setup lacks a dependency on gnupg

[Cyril Brulebois]

Hi,

Philipp Kern  (2018-05-21):
> So what's the current contract with apt? ASCII-armored files need to go
> into .asc and binary files into .gpg? Is the right way to infer ASCII
> armor to grep for the preamble?

That would match my recollection of that issue (but don't trust that);
maybe loop apt people in for a last check?

> Also right now we discard the file name of the key fetched, is that
> something we'd want to preserve?

I guess that would be preferable, yes?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#898637: Pluma text editor crashes when scrolling while hovering over a tab

[C. Masloch]

> Please, can you check if this patch fixes the bug?

Yes, that fixes the bug. Now scrolling while pointing at filenames, tab
close buttons, or the free space to the right of the tab headers, all
work as expected. That is, they switch the active tab, and no crash
seems to occur any longer.

Regards,
ecm

Bug#899241: Amplifier detected by source from program developer but not by Debian package.

[m1k3kn0tt]

Package: mustang-plugVersion: 1.2-1+b1Severity: grave
PROBLEMDear Maintainer,
I own a Mustang IV and Mustang I (both v2) and am used to using the
Fender Fuse software to control both (this works perfectly with both).
I have a reasonably solid understanding of Linux, have come across your
"Plug" package and would like to use it.
Before I was aware of your package, I had installed the Plug software
directly from the develope's website (v1.2). The install went
perfectly: - unpacked to /home/me/Programs/Plug, - ran: apt install
qt4.dev libusb-1.0-0-dev - ran: qmake plug.pro - ran make (lots of
output...) - ran: export PATH=$PATH:/home/me/Programs/PlugEntering
"plug" into a terminal as user "me", ran the program and it showed
sound patches I had saved in both amps themselves. So... great:
connection no problem, loading from amps, no problem.
Then I became aware of your package and, as always, would prefer to use
the Stretch repos than source. So, I installed your package. It
installed with no error or messages.
I connected to my Mustang I. It connected immediately and I was able to
load the sound patches from the amp. Great. But when I connected to my
Mustang IV... nothing. 
So, I checked the developer's website and there was some advice... - I
checked the existence of the group "plugdev"; it existed and I was
already a member of it. - I followed the developer's advice to create a
file called "50-mustang.rules" in /etc/udev/rules.d and added the
following to it:
***SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0004",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0005",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0006",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0007",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0010",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0011",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0012",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0013",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0014",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0015",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0016",
GROUP="plugdev"SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0017", GROUP="plugdev*** -
restarted udev.Nothing: the Mustang I still worked; the Mustang IV, no
joy.
 - I added myself to the udev group. No joy. - I updated firmware using
FUSE, no joy.END PROBLEM
REPORTBUG OUTPUT-- System Information:Debian Release: 9.4  APT prefers
stable-updates  APT policy: (500, 'stable-updates'), (500,
'stable')Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)Locale: LANG=en_GB.UTF-
8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8
(charmap=UTF-8)Shell: /bin/sh linked to /bin/dashInit: systemd (via
/run/systemd/system)
Versions of packages mustang-plug depends on:ii  libc6   2.24-
11+deb9u3ii  libgcc1 1:6.3.0-18+deb9u1ii  libqt4-
network  4:4.8.7+dfsg-11ii  libqtcore4  4:4.8.7+dfsg-
11ii  libqtgui4   4:4.8.7+dfsg-11ii  libstdc++6  6.3.0-
18+deb9u1ii  libusb-1.0-02:1.0.21-1
mustang-plug recommends no packages.
mustang-plug suggests no packages.
-- no debconf informationEND REPORTBUG OUTPUT

Just ask for anything else you need. Happy to send more information,
outputs from diagnostic commands, etc.Cheers,Mike

Bug#898825: linux-image-4.16.0-1-amd64: KMS/graphics not working on Lenovo P50 with 4.16

[Sam Morris]

Control: tag -1 - moreinfo + fixed-upstream

On Sun, May 20, 2018 at 04:10:42PM +0200, Ben Hutchings wrote:
> Control: tag -1 patch moreinfo
> 
> On Wed, 2018-05-16 at 11:39 +0100, Sam Morris wrote:
> > I noticed that after a few minutes, the kernel logs additional messages.
> > Aside from libvirt, the tasks all appear to be stuck inside nouveau/drm
> > funtions.
> [...]
> 
> Sorry, should have read this before sending the previous reply.  This
> is definitely different from the bugs I mentioned.
> 
> This looks like it could be the bug fixed by:
> 
> commit 352672db857290ab5b0e2b6a99c414f92bee024c
> Author: Lyude Paul 
> Date:   Wed May 2 19:38:48 2018 -0400
> 
> drm/nouveau: Fix deadlock in nv50_mstm_register_connector()
> 
> This is included in stable update 4.16.9.  You can test it now by
> applying the attached patch, following the instructions at:
> https://kernel-handbook.debian.net/ch-common-tasks.html#s-common-official

Many thanks Ben, that patch has fixed the problem.

Regards,

-- 
Sam Morris 
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#899242: update-service: can't disable service (only when auto-enabled on install)

[Lorenzo Puliti]

Package: getty-run
Version: 2.1.2-13
Severity: normal



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

Kernel: Linux 4.15.12-van (SMP w/4 CPU cores; PREEMPT)
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: sysvinit (via /sbin/init)

Versions of packages getty-run depends on:
ii  runit 2.1.2-13
ii  runit-helper  2.7.2

Versions of packages getty-run recommends:
ii  fgetty  0.7-3

getty-run suggests no packages.

-- no debconf information

Dear Maintainer,
I recently upgrade getty-run; before the upgrade getty1 was disabled while 
getty2-6 were already enabled.
During the upgrade getty1 was automatically enabled, and upgrade-service can't 
handle
symlinks done this way.

# update-service --remove /etc/sv/getty-tty1
  update-service: fatal: /etc/service/getty-tty1 does not point to 
/etc/sv/getty-tty1.

here's the difference between the two symlinks
this was symlinked during the upgrade
ls -l /etc/service/getty-tty1
lrwxrwxrwx 1 root root 22 May 13 21:39 /etc/service/getty-tty2 -> 
../../../sv/getty-tty1

and this was symlinked with "update-service --add /etc/sv/getty-tty4" (no 
problem here with update-service --remove )
ls -l /etc/service/getty-tty4
lrwxrwxrwx 1 root root 18 Jul 16  2017 /etc/service/getty-tty4 -> 
/etc/sv/getty-tty4

I think that upgrade-service's code or the code responsible for enabling 
services on install (is it dh_runit?)
need a fix. 
Also, please (if possible) don't auto-enable services on upgrade when the 
service is disabled by admin choice.
Thanks

Lorenzo 

Bug#873464: WIP

[Lisandro Damián Nicanor Pérez Meyer]

It's worth to mention that work is in progress.

-- 
Either he's dead or my watch has stopped.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#899243: Needs porting to later tornado

[Enrico Zini]

Package: python3-sockjs-tornado
Version: 1.0.3-1
Severity: serious

Hello,

in recent tornado versions, PeriodicCallback lost the io_loop argument:
http://www.tornadoweb.org/en/stable/ioloop.html#tornado.ioloop.PeriodicCallback
but sockjs.tornado is still trying to use of it:

>>> import sockjs.tornado
>>> sockjs.tornado.SockJSRouter(sockjs.tornado.SockJSConnection)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/sockjs/tornado/router.py", line 111, in 
__init__
self.io_loop)
TypeError: __init__() takes 3 positional arguments but 4 were given

Because of this, sockjs.tornado does not work in current Debian Testing.


Enrico

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

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

Versions of packages python3-sockjs-tornado depends on:
ii  python3  3.6.4-1
ii  python3-tornado  5.0.2-1

python3-sockjs-tornado recommends no packages.

python3-sockjs-tornado suggests no packages.

-- no debconf information

Bug#899244: tracker.debian.org: emails sent to non-existing/misspelled team names (team+NAME@..) are silently discarded

[Lars Kruse]

Package: tracker.debian.org
Severity: normal

Dear Maintainer,

recently I sent a mail to , as this is
currently (by mistake) advertised as the contact address of the munin
package maintainers.
(this issue of the missing team "munin") is about to be fixed now)

My mail was silently discarded (see [1]).

Instead I expected a failure notice message.

Thus I was unaware, that my mail disappeared, until I talked to one
of the maintainers in person.


Thank you for your time,
Lars

[1]
https://salsa.debian.org/qa/distro-tracker/commit/a707768aec9af00095548da39d7a4050d3ae5627#3486c809fba164e9b499a234b211b7ede204ca1e_127_146

Bug#899183: sub...@bugs.debian.org

[Martin Kittel]

Hi Markus,

thanks for the prompt reply. I gave it another try with Java 11 and to
my surprise it is working there. After having a closer look at the Java
doc it turns out that the change in return value type from Buffer to
ByteBuffer is only present in Java 9 and has been reverted in 10 again.
While I don't understand why it is working with Java 11 but not with 1.7
I am happy to see that it is. I was afraid it would be broken for all
JDKs when compiled against Java 9.

Thanks again and best wishes,

Martin.

Bug#899245: kgb-bot: support for password-protected channels

[Yves-Alexis Perez]

Source: kgb-bot
Severity: wishlist

Hi there,

subject mostly says it all, but it'd be nice if KGB could support
password-protected IRC channels for notifications.

Regards,
-- 
Yves-Alexis

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

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

Bug#886473: apt-setup lacks a dependency on gnupg

[Philipp Kern]

On 5/21/18 3:06 PM, Cyril Brulebois wrote:
> Philipp Kern  (2018-05-21):
>> So what's the current contract with apt? ASCII-armored files need to go
>> into .asc and binary files into .gpg? Is the right way to infer ASCII
>> armor to grep for the preamble?
> That would match my recollection of that issue (but don't trust that);
> maybe loop apt people in for a last check?

Adding deity@ to Cc. For context: This is about a debian-installer
script[0] that adds custom repositories to the final system.

I see at least the following options:

1) Run apt-install gnupg and use add-key.
2) Place the key file somewhere on the target file system and use
signed-by with the file path in sources.list.
3) Add the key file to /etc/apt/trusted.gpg.d.

I think in the latter two cases it's necessary to name the key fragments
.asc or .gpg depending on the content, correct? Right now we do not have
this distinction, so we'd need to somehow detect which one it is. Worst
case using grep for the ASCII armored preamble. Neither sources.list(5)
nor apt-secure(8) describe what the contract for /etc/apt/trusted.gpg.d
or other fragments actually is.

We also use fetch-url from debian-installer-utils at the moment, which
discards the source file name. I suppose we could use something like
${url%%://*} to strip the protocol (which fetch-url already does) and
then use basename somehow to figure out the name, but I feel that this
would be a little surprising.

Kind regards and thanks
Philipp Kern

[0]
https://salsa.debian.org/installer-team/apt-setup/blob/master/generators/60local

Bug#898707: debian/rules build target attempts network access when git is installed

[Troy Heber]

On 05/17/18 17:25, Thadeu Lima de Souza Cascardo wrote:
> Package: crash
> Version: 7.2.1-1+b1
> Followup-For: Bug #898707
> 
> Attaching a debdiff for an NMU fixing the cloning and the cleanup that
> still needs a small change in rules even after fixing the cloning
> problem.

Thanks for the patch! I will get it uploaded right away.

Troy

Bug#899246: runit-init: stage 3: using runit's own shutdown/reboot code

[Lorenzo Puliti]

Package: runit-init
Version: 2.1.2-13
Severity: wishlist



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

Kernel: Linux 4.15.12-van (SMP w/4 CPU cores; PREEMPT)
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: sysvinit (via /sbin/init)

Versions of packages runit-init depends on:
ii  getty-run 2.1.2-13
ii  initscripts   2.88dsf-59.10
ii  libc6 2.27-3
ii  runit 2.1.2-13
ii  runit-helper  2.7.2
ii  sysv-rc   2.88dsf-59.10

runit-init recommends no packages.

runit-init suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /sbin/shutdown (from runit-init package)


Hi,
I would like to share a setup that uses runit's code for reboot/shutdown: this 
way shutdown/reboot's external
code is used only when switching init.
Also, the /etc/init.d/rc script is no longer used for the shutdown sequence.
I'm currently using this on my pc and i have tested the systemd-->runit-init 
sitch on Virtualbox and works for me.
Sharing in case you want to use it or just take some ideas from it.

mv /sbin/shutdown /sbin/shutdown-sysv
rm /sbin/reboot
rm /sbin/halt


/etc/runit/3
--
#!/bin/sh
exec 2>&1

PATH=/sbin:/usr/sbin:/bin:/usr/bin

# LAST=0

# While test -x is more natural, it does not consider file with
# executable bit set on 'noexec' filesystem as executable, and /run
# often is mounted as 'noexec'.
# [ $(stat -c %a /run/runit.reboot) = 100 ] && LAST=6

echo 'Waiting for services to stop...'
sv force-stop /etc/service/*
sv exit /etc/service/*

# Stop sysv services, reverse order
run-parts --reverse --regex=S --arg=stop -- /etc/rc2.d

# Print a message, not really essential since runit will print
# a similar message when exiting stage 3 

if [ -e /run/runit.reboot ]; then
   echo 'Shutdown: reboot...'
else
   echo 'Shutdown: poweroff...'
fi

# perform shutdown tasks using initscripts
# skip reboot/halt scripts so that runit uses it's own code
for script in /etc/rc0.d/K* ; do
   echo $script | grep -vq halt && $script stop
done

# echo 'Shutdown...'
# /etc/init.d/rc $LAST


-

cat /sbin/shutdown
#!/bin/sh

if [ -e /run/runit.stopit ]; then
   init 0
else
   exec /sbin/shutdown-sysv
fi

---

cat /sbin/reboot
#!/bin/sh

if [ -e /run/runit.stopit ]; then
   touch /run/runit.reboot && init 6
else
if [ "$2" = -f ]; then
  exec /sbin/shutdown-sysv -f
else
  exec /sbin/shutdown-sysv
fi
fi

-

cat /sbin/halt
#!/bin/sh

# /etc/init.d/unmountnfs.sh is doing "halt -w" before unmounting.
# shutdown.c only supports -f option.
# halt -w makes runit print a warning ("signals only work in stage 2")
# then runit perform a poweroff even if it was correctly instructed to reboot

if [ -e /run/runit.stopit ] && [ "$1" = -w ] ; then
echo 'halt: -w option not yet supported'
else
exec /sbin/shutdown-sysv
fi
---

Thanks

Lorenzo

Bug#899247: openshot-qt: fails to start - requires pyhton module 'requests'

[Cesare Tirabassi]

Package: openshot-qt
Version: 2.4.1+dfsg1-1
Severity: important



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

Kernel: Linux 4.16.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 openshot-qt depends on:
ii  fonts-cantarell 0.0.25-4
ii  libjs-jquery3.2.1-1
ii  python3 3.6.5-3
ii  python3-openshot0.1.9+dfsg1-3+b2
ii  python3-pyqt5   5.10.1+dfsg-2
ii  python3-pyqt5.qtsvg 5.10.1+dfsg-2
ii  python3-pyqt5.qtwebkit  5.10.1+dfsg-2
ii  python3-zmq 17.0.0-1

Versions of packages openshot-qt recommends:
ii  blender   2.79.b+dfsg0-1
pn  inkscape  

Versions of packages openshot-qt suggests:
pn  openshot-qt-doc  

-- no debconf information

Attemping to run openshot-qt on my system leads to the following error:

Loaded modules from installed directory: 
/usr/lib/python3/dist-packages/openshot_qt
  launch:INFO 
  launch:INFOOpenShot (version 2.4.1)
  launch:INFO 
qt.qpa.screen: Output DisplayPort-0 is not connected
qt.qpa.screen: Output HDMI-A-0 is not connected
qt.qpa.screen: Failed to parse EDID data for output "DVI-I-0" edid data:  ""
qt.qpa.screen: Failed to parse EDID data for output "DVI-D-1" edid data:  ""
qt.qpa.screen: adding QXcbScreen(0x25951c0, name="DVI-I-0", 
geometry=1920x1080+0+0, availableGeometry=1920x1080+0+0, devicePixelRatio=1.0, 
logicalDpi=QPair(96.1,96.3), physicalSize=521.0x293.0mm, screenNumber=0, 
virtualSize=3200x1080 (3200.0x1080.0mm), 
orientation=Qt::ScreenOrientation(LandscapeOrientation), depth=24, 
refreshRate=60.0, root=5ea, windowManagerName="Openbox") (Primary: true )
qt.qpa.screen: adding QXcbScreen(0x25952b0, name="DVI-D-1", 
geometry=1280x1024+1920+0, availableGeometry=1280x1024+1920+0, 
devicePixelRatio=1.0, logicalDpi=QPair(96.1,96.3), physicalSize=338.0x270.0mm, 
screenNumber=0, virtualSize=3200x1080 (3200.0x1080.0mm), 
orientation=Qt::ScreenOrientation(LandscapeOrientation), depth=24, 
refreshRate=60.0, root=5ea, windowManagerName="Openbox") (Primary: false )
qt.qpa.screen: primary output is "DVI-I-0"
qt.qpa.gl: Choosing xcb gl-integration based on following priority
 ("xcb_glx", "xcb_egl")
qt.qpa.gl: Xcb GLX gl-integration created
qt.qpa.gl: Xcb GLX gl-integration successfully initialized
 app:INFO openshot-qt version: 2.4.1
 app:INFO libopenshot version: 0.1.9
 app:INFO platform: Linux-4.16.0-1-amd64-x86_64-with-debian-buster-sid
 app:INFO processor: 
 app:INFO machine: x86_64
 app:INFO python version: 3.6.5
 app:INFO qt5 version: 5.10.1
 app:INFO pyqt5 version: 5.10.1
  logger:ERROR Traceback (most recent call last):
  logger:ERROR   File "/usr/bin/openshot-qt", line 11, in 
  logger:ERROR load_entry_point('openshot-qt==2.4.1', 'gui_scripts', 
'openshot-qt')()
  logger:ERROR   File 
"/usr/lib/python3/dist-packages/openshot_qt/launch.py", line 70, in main
  logger:ERROR app = OpenShotApp(sys.argv)
  logger:ERROR   File 
"/usr/lib/python3/dist-packages/openshot_qt/classes/app.py", line 91, in 
__init__
  logger:ERROR from classes import exceptions
  logger:ERROR   File 
"/usr/lib/python3/dist-packages/openshot_qt/classes/exceptions.py", line 30, in 

  logger:ERROR from classes.metrics import track_exception_stacktrace
  logger:ERROR   File 
"/usr/lib/python3/dist-packages/openshot_qt/classes/metrics.py", line 30, in 

  logger:ERROR import requests
  logger:ERROR ModuleNotFoundError
  logger:ERROR :
  logger:ERROR No module named 'requests'

Installing python3-requests solves the issue. Perhaps python3-requests should
be a dependency of openshot-qt?

Bug#899234: git-buildpackage: gbp-push fails when there is no upstream branch

[Paride Legovini]

On 21/05/2018 13.04, Guido Günther wrote:
> On Mon, May 21, 2018 at 11:22:31AM +0200, Paride Legovini wrote:
>>
>> /usr/share/doc/git-buildpackage/manual-html/gbp.import.upstream-git.html
> 
> I think the documentation above does not suggest that there is no
> upstream branch, rather that you don't need gbp import-orig to maintain
> it. At least that's the intention.
> [...]
> (I'm maintaining several packages directly out of git).

I didn't lose the opportunity to have a look at the state of the art.

Well, it seems to me that calypso has a branch layout that will bring to
the issue I'm describing (no upstream branch). I don't think it is
currently possible to use gbp-push with it.

Paride

Bug#899248: debhelper: upstream changelog no longer installed

[Sven Joachim]

Package: debhelper
Version: 11.3

Upon rebuilding (binary-arch only) ncurses with debhelper 11.3, I found
that lintian would notice missing upstream changelogs:

,
| P: libtinfo6: no-upstream-changelog
| P: libtinfo5: no-upstream-changelog
| P: lib64tinfo6: no-upstream-changelog
| P: ncurses-bin: no-upstream-changelog
| P: ncurses-examples: no-upstream-changelog
`

In debian/rules I have "dh_installchangelogs -a NEWS", nothing fancy.
And dh_installchangelogs silently skipped this file.


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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  0.041-1
ii  dpkg 1.19.1
ii  dpkg-dev 1.19.1
ii  dwz  0.12-2
ii  file 1:5.33-2
ii  libdpkg-perl 1.19.1
ii  man-db   2.8.3-2
ii  perl 5.26.2-5
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201701

-- no debconf information

Bug#899232: thunderbird: Main screen corrupted with 52.8.0-1

[Carsten Schoenert]

Hello Jean-Luc,

On Mon, May 21, 2018 at 11:18:36AM +0200, Jean-Luc Coulon (f5ibh) wrote:
 
> Since the latest update to 52.8.0-1, the main window is corrupted. And
> the problem is becoming worse as I use thunderbird: it seems that the
> old data arent correctly overwritten.
> 
> I remarked this kind of behaviour also with the experimental version.

looks like a GTK+3 related issue which I can't reproduce on my
installations (under Testing). If you say you see this also with
Thunderbird from experimental I even more think this is mostly related
to GTK+3. The Thunderbird version 52.7.0-1 is now almost 6 weeks old,
version 52.8.0 and 60.0 are just some days or weeks and things in
unstable moving fast.

Currently there is nothing I can suggest to do. Except to play around
with Wayland/X11 and some other Desktop Environment.

Regards
Carsten

Bug#899249: ncmpcpp: symbol lookup error on launch - boost related?

[Robbie Harwood]

Package: ncmpcpp
Version: 0.8.1-1+b1
Severity: important

Dear Maintainer,

This may be the same bug as #899163 so feel free to handle appropriately, but
I didn't perform any forcing.  This just happened during an upgrade.

Anyway, whenever I try to launch ncmpcpp, it fails like so:

rharwood@seton:~$ ncmpcpp
ncmpcpp: symbol lookup error: ncmpcpp: undefined symbol: 
_ZNK5boost16re_detail_10620031icu_regex_traits_implementation12do_transformEPKiS3_PKN6icu_608CollatorE

Thanks!

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

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

Versions of packages ncmpcpp depends on:
ii  libboost-date-time1.62.01.62.0+dfsg-5+b1
ii  libboost-filesystem1.62.0   1.62.0+dfsg-5+b1
ii  libboost-locale1.62.0   1.62.0+dfsg-5+b1
ii  libboost-program-options1.62.0  1.62.0+dfsg-5+b1
ii  libboost-regex1.62.01.62.0+dfsg-5+b1
ii  libboost-system1.62.0   1.62.0+dfsg-5+b1
ii  libboost-thread1.62.0   1.62.0+dfsg-5+b1
ii  libc6   2.27-3
ii  libcurl3-gnutls 7.58.0-2
ii  libfftw3-double33.3.7-1+b1
ii  libgcc1 1:8.1.0-3
ii  libicu6060.2-6
ii  libmpdclient2   2.11-1
ii  libncursesw66.1+20180210-3
ii  libreadline77.0-5
ii  libstdc++6  8.1.0-3
ii  libtag1v5   1.11.1+dfsg.1-0.2+b1
ii  libtinfo6   6.1+20180210-3

ncmpcpp recommends no packages.

Versions of packages ncmpcpp suggests:
pn  desktop-file-utils  
ii  mpd 0.20.19-1+b1

-- no debconf information

Bug#894703: davmail: Disconnects after IMAP FETCH command issued

[Sam Morris]

On Thu, Apr 05, 2018 at 01:30:14PM +0200, Alexandre Rossi wrote:
> Do you run with log4j.logger.davmail=DEBUG?
> Can you reproduce with upstream's prebuilt binaries?

I gave this a go today but can no longer reproduce this. I'm going to
put it down to flakey networking. :/

Thanks for taking a look anyway!

-- 
Sam Morris 
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#897893: (no subject)

[Eugene Budanov]

Hi!

I tried to make the kernel dump, but I found a strange situation. I can't 
create it when sending echo c > /proc/sysrq-trigger .

My settings:

# cat /etc/default/kdump-tools
USE_KDUMP=1
KDUMP_RUNLEVEL="1"
KDUMP_SAVEDIR="file:///var/crash"
KDUMP_NET="none"
KDUMP_SYSCTL="kernel.panic_on_oops=1"
KDUMP_COREDIR="/var/crash"
KDUMP_FAIL_CMD="reboot -f"
DEBUG_KERNEL=/usr/lib/debug/boot/vmlinux-4.9.0-6-amd64
MAKEDUMP_ARGS="-c -d 17

# cat /etc/sysctl.conf
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additonal system variables
# See sysctl.conf (5) for information.
#

fs.file-max = 2097152
net.core.somaxconn = 1
net.core.rmem_max = 1048576
net.core.wmem_max = 16777216
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_syncookies = 1
net.ipv4.ip_local_port_range = 31000 65535
vm.swappiness = 0
kernel.core_pattern = /tmp/core.%e.%p.%h.%t
kernel.core_uses_pid = 1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
vm.dirty_bytes = 536870912
vm.dirty_background_bytes = 268435456
net.netfilter.nf_conntrack_max = 12621440
net.nf_conntrack_max = 12621440
net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 120
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_window_scaling = 1
kernel.shmmax = 40802189312
kernel.shmall = 9961473
vm.zone_reclaim_mode = 0
vm.min_free_kbytes = 524288
net.core.wmem_default = 65536
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 5
net.ipv4.tcp_low_latency = 1
net.ipv4.tcp_congestion_control = htcp
net.ipv6.conf.eth0.disable_ipv6 = 1
# KERNEL PANIC OPTIONS
kernel.panic = 1
kernel.hung_task_panic = 1
kernel.panic_on_io_nmi = 1
kernel.panic_on_oops = 1
kernel.panic_on_unrecovered_nmi = 1
kernel.softlockup_panic = 1

Of course, kdump-tools is running.

Additional information:
# dmesg |  grep "Reserving"
[    0.00] Reserving 512MB of memory at 336MB for crashkernel (System RAM: 
130958MB)

# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.9.0-6-amd64 root=/dev/mapper/system-root ro nomodeset 
net.ifnames=0 biosdevname=0 consoleblank=0 rootdelay=120 
transparent_hugepage=never quiet crashkernel=512M (yes, server have 128 GB RAM)

# cat /sys/kernel/kexec_crash_loaded
1

The packages kdump-tools linux-image-dbg crash kexec-tools makedumpfile is 
installed too.

What is I'm missing?

---
With best regards,
Eugene Budanov.

Bug#899250: bcpp FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: bcpp
Version: 0.0.20131209-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

bcpp fails to cross build from source, because it does not pass --host
to ./configure. The easiest way of doing so is deferring the task to
dh_auto_configure. After doing so, bcpp cross builds successfully.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru bcpp-0.0.20131209/debian/changelog 
bcpp-0.0.20131209/debian/changelog
--- bcpp-0.0.20131209/debian/changelog  2015-08-02 13:56:56.0 +0200
+++ bcpp-0.0.20131209/debian/changelog  2018-05-21 16:56:06.0 +0200
@@ -1,3 +1,10 @@
+bcpp (0.0.20131209-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 21 May 2018 16:56:06 +0200
+
 bcpp (0.0.20131209-1) unstable; urgency=medium
 
   * New Upstream Release
diff --minimal -Nru bcpp-0.0.20131209/debian/rules 
bcpp-0.0.20131209/debian/rules
--- bcpp-0.0.20131209/debian/rules  2015-08-02 16:47:59.0 +0200
+++ bcpp-0.0.20131209/debian/rules  2018-05-21 16:55:15.0 +0200
@@ -21,10 +21,7 @@
cp -f /usr/share/misc/config.guess config.guess
 endif
 
-   ./configure \
-   --prefix=/usr \
-   --mandir=\$${prefix}/share/man \
-   --infodir=\$${prefix}/share/info \
+   dh_auto_configure -- \
CFLAGS="$(CFLAGS) $(CPPFLAGS) 
-DBCPP_CONFIG_DIR=\\\"/etc/bcpp/\\\"" \
CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS) 
-DBCPP_CONFIG_DIR=\\\"/etc/bcpp/\\\"" \
LDFLAGS="$(LDFLAGS) $(LDFLAGS2)"

Bug#899251: installation-reports

[Luis Alberto SOSA]

Package: installation-reports

Boot method: 
Image version: 
Date: 

Machine: 
Processor: 
Memory: <2GB>
Partitions: 


Output of lspci -knn (o lspci -nn): < > Base System Installation Checklist: 
 [O] = OK, 
[E] = Error (descríbalo a continuación), [ ] = didn't try it Initial boot: [O] 
<¿Funcionó el arranque inicial?> Detect network card: [O] <¿Se configuró el 
hardware de red?> Configure network: [0] <¿Se configuró la red?> Detect CD: [0] 
<¿Se detectó la unidad de CD?> Load installer modules: [0] <¿Se cargaron los 
módulos del instalador?> Detect hard drives: [0] <¿Se detectaron los discos 
duros?> Partition hard drives: [0] <¿Se particionó el disco duro?> Install base 
system: [0] <¿Se instaló el sistema base?> Clock/timezone setup: [0] <¿Se 
configuró bien la zona horaria?> User/password setup: [0] <¿Se configuró 
correctamente el usuario?> Install tasks: [E] <¿Se instalaron bien las tareas?> 
Install boot loader: [ ] <¿Se instaló el gestor de arranque?> Overall install: 
[ ] <¿Reinició correctamente?> Comments/Problems: 

Bug#897583: haskell-graphviz: FTBFS: unsatisfiable build-dependency: libghc-fgl-dev (< 5.6) but 5.6.0.0-2 is to be installed

[Gianfranco Costamagna]

control: fixed -1  2999.19.0.0.git20180507-1
control: close -1

fixed :)

G.

On Thu, 3 May 2018 08:09:38 +0200 Lucas Nussbaum  wrote:
> Source: haskell-graphviz
> Version: 2999.19.0.0-1
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20180502 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > +--+
> > | Install package build dependencies
> >|
> > +--+
> > 
> > 
> > Setup apt archive
> > -
> > 
> > Merged Build-Depends: cdbs, debhelper (>= 9), ghc (>= 8), ghc-prof, 
> > haskell-devscripts (>= 0.13), libghc-colour-dev (<< 2.4), libghc-colour-dev 
> > (>= 2.3), libghc-colour-prof, libghc-dlist-dev (<< 0.9), libghc-dlist-dev 
> > (>= 0.5), libghc-dlist-prof, libghc-fgl-dev (<< 5.6), libghc-fgl-dev (>= 
> > 5.4), libghc-fgl-prof, libghc-polyparse-dev (<< 1.13), libghc-polyparse-dev 
> > (>= 1.9), libghc-polyparse-prof, libghc-temporary-dev (<< 1.3), 
> > libghc-temporary-dev (>= 1.1), libghc-temporary-prof, libghc-text-dev, 
> > libghc-text-prof, libghc-wl-pprint-text-dev (<< 1.2.0.0), 
> > libghc-wl-pprint-text-dev (>= 1.1.0.0), libghc-wl-pprint-text-prof, 
> > ghc-doc, libghc-colour-doc, libghc-dlist-doc, libghc-fgl-doc, 
> > libghc-polyparse-doc, libghc-temporary-doc, libghc-text-doc, 
> > libghc-wl-pprint-text-doc
> > Filtered Build-Depends: cdbs, debhelper (>= 9), ghc (>= 8), ghc-prof, 
> > haskell-devscripts (>= 0.13), libghc-colour-dev (<< 2.4), libghc-colour-dev 
> > (>= 2.3), libghc-colour-prof, libghc-dlist-dev (<< 0.9), libghc-dlist-dev 
> > (>= 0.5), libghc-dlist-prof, libghc-fgl-dev (<< 5.6), libghc-fgl-dev (>= 
> > 5.4), libghc-fgl-prof, libghc-polyparse-dev (<< 1.13), libghc-polyparse-dev 
> > (>= 1.9), libghc-polyparse-prof, libghc-temporary-dev (<< 1.3), 
> > libghc-temporary-dev (>= 1.1), libghc-temporary-prof, libghc-text-dev, 
> > libghc-text-prof, libghc-wl-pprint-text-dev (<< 1.2.0.0), 
> > libghc-wl-pprint-text-dev (>= 1.1.0.0), libghc-wl-pprint-text-prof, 
> > ghc-doc, libghc-colour-doc, libghc-dlist-doc, libghc-fgl-doc, 
> > libghc-polyparse-doc, libghc-temporary-doc, libghc-text-doc, 
> > libghc-wl-pprint-text-doc
> > dpkg-deb: building package 'sbuild-build-depends-haskell-graphviz-dummy' in 
> > '/<>/resolver-leDeuw/apt_archive/sbuild-build-depends-haskell-graphviz-dummy.deb'.
> > dpkg-scanpackages: warning: Packages in archive but missing from override 
> > file:
> > dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy 
> > sbuild-build-depends-haskell-graphviz-dummy
> > dpkg-scanpackages: info: Wrote 2 entries to output Packages file.
> > Ign:1 copy:/<>/resolver-leDeuw/apt_archive ./ InRelease
> > Get:2 copy:/<>/resolver-leDeuw/apt_archive ./ Release [963 B]
> > Ign:3 copy:/<>/resolver-leDeuw/apt_archive ./ Release.gpg
> > Get:4 copy:/<>/resolver-leDeuw/apt_archive ./ Sources [714 B]
> > Get:5 copy:/<>/resolver-leDeuw/apt_archive ./ Packages [780 B]
> > Fetched 2457 B in 0s (0 B/s)
> > Reading package lists...
> > Reading package lists...
> > 
> > Install haskell-graphviz build dependencies (apt-based resolver)
> > 
> > 
> > Installing build dependencies
> > Reading package lists...
> > Building dependency tree...
> > Reading state information...
> > Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> > 
> > The following packages have unmet dependencies:
> >  sbuild-build-depends-haskell-graphviz-dummy : Depends: libghc-fgl-dev (< 
> > 5.6) but 5.6.0.0-2 is to be installed
> > E: Unable to correct problems, you have held broken packages.
> > apt-get failed.
> 
> The full build log is available from:
>
> http://aws-logs.debian.net/2018/05/02/haskell-graphviz_2999.19.0.0-1_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

Bug#858294: Unreproducible, moreinfo needed

[Lisandro Damián Nicanor Pérez Meyer]

forwarded 858294 https://bugreports.qt.io/browse/QTBUG-68380
tag 858294 - moreinfo
thanks

El miércoles, 11 de abril de 2018 18:11:25 -03 Vladimir Berezenko escribió:
> Lisandro Dami?n Nicanor P?rez Meyer wrote:
> > > This is definitely reproducible. The current Qt5 version is 5.9.2-2 on
> > > my
> > > quad G5, and 5.8.4 on G4 powerbook. Both machines are not reacting on
> > > mousewheel events at all. I've tried KDE, LXQt. GTK2/3 apps are not
> > > affected at all.
> > 
> > Well, this is totally strange, as the only report we have heard so far is
> > from you.
> 
> This might be because others are not using Qt5 at all. It's strange, but
> understandable in case that newer Qt5 is using chromium as a web backend and
> it is not compileable to anything except x86 and arm and this renders Qt5
> almost unusable in modern cases.

While I agree that using chromium is not a great idea I still have to mae the 
point that there are lots of apps using Qt5 without the webengine submodule. 
So I tstill think it's weird we have only heard this from you so far.

> > I understand that you tried on two machines. Just to be clear: have you
> > tried with a new user?
> 
> The older installation on G5 is working the same in all users (tried new
> one). The G4 installation on powerbook is the fresh one.

ACK

> > There is the chance that you might have configured something in the same
> > way in both machines. If you still can reproduce this bug with a new user
> > then we can file a bug upstream.
> 
> Both installations are independent and on older one (G5 one) I've tried
> several users.

ACK.

> > Actually you should do it yourself, as I don't have any ways of
> > reproducing
> > this bug. Please file the upstream bug at https://bugreports.qt.io and
> > then
> > please send the bug number here. I'll happily subscribe to the bug to
> > follow it and, if possible at all, help.
> 
> Reading the bugs there I've found that it is possible that the problem is in
> QXcbAtom::ButtonWheel* wrong detection. I'm yet unable to find how does Qt5
> detects wheel buttons and where from it is getting the mouse events. The
> xinput shows everything ok, and Qt4 and GTK2/3 apps all are using the wheel
> perfectly
> Regarding the bugreport. I should register on the site and when I will fill
> bug report I'll attach it here.

Done, the URL is on the first line of the mail's body.

-- 
"Any sufficiently advanced technology is indistinguishable from magic"
 Arthur C. Clarke

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#798931:

[Shriramana Sharma]

This and #804204 are the same bug though phrased differently.

As of Kubuntu Bionic the command service seems to be replaced by
systemctl so the requisite steps are:

#! /bin/sh
sudo a2enmod cgid
sudo systemctl restart apache2

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा 𑀰𑁆𑀭𑀻𑀭𑀫𑀡𑀰𑀭𑁆𑀫𑀸

Bug#899248: debhelper: upstream changelog no longer installed

[Sven Joachim]

On 2018-05-21 17:05 +0200, Sven Joachim wrote:

> Package: debhelper
> Version: 11.3
>
> Upon rebuilding (binary-arch only) ncurses with debhelper 11.3, I found
> that lintian would notice missing upstream changelogs:
>
> ,
> | P: libtinfo6: no-upstream-changelog
> | P: libtinfo5: no-upstream-changelog
> | P: lib64tinfo6: no-upstream-changelog
> | P: ncurses-bin: no-upstream-changelog
> | P: ncurses-examples: no-upstream-changelog
> `
>
> In debian/rules I have "dh_installchangelogs -a NEWS", nothing fancy.
> And dh_installchangelogs silently skipped this file.

For the reference, commit 406bd37eb469 ("dh_installchangelogs: Prefer
existing changelog in d//u/s/d/") is the culprit.

Cheers,
   Sven

Bug#804204:

[Shriramana Sharma]

This and #798931 are the same bug though phrased differently.

As of Kubuntu Bionic the command service seems to be replaced by
systemctl so the requisite steps are:

#! /bin/sh
sudo a2enmod cgid
sudo systemctl restart apache2

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा 𑀰𑁆𑀭𑀻𑀭𑀫𑀡𑀰𑀭𑁆𑀫𑀸

Bug#862473: Unreproducible, mor einfo needed

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo unreproducible

Hi! I can not reproduce this bug. Are you still able to reproduce it with Qt 
in testing/unstable?

Thanks!

-- 
15: Que es el "Correo Electronico"
* El correo que te llega por la corriente
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#794983: More info needed

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo unreproducible

Hi! I can not reproduce this bug with the Qt version in testing. Can you still 
reproduce it?




-- 
16: De quien es Internet
* De DIOS dado que todas las cosas del mundo le pertenecen
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#899248: debhelper: upstream changelog no longer installed

[Niels Thykier]

Control: tags -1 patch
Control: severity -1 serious

On Mon, 21 May 2018 17:05:54 +0200 Sven Joachim  wrote:
> Package: debhelper
> Version: 11.3
> 
> Upon rebuilding (binary-arch only) ncurses with debhelper 11.3, I found
> that lintian would notice missing upstream changelogs:
> 
> ,
> | P: libtinfo6: no-upstream-changelog
> | P: libtinfo5: no-upstream-changelog
> | P: lib64tinfo6: no-upstream-changelog
> | P: ncurses-bin: no-upstream-changelog
> | P: ncurses-examples: no-upstream-changelog
> `
> 
> In debian/rules I have "dh_installchangelogs -a NEWS", nothing fancy.
> And dh_installchangelogs silently skipped this file.
> 
> 
> [...]
Hi Sven,

Thanks for reporting this bug.

Could you please try the attached patch and see/confirm it fixes the
issue for you?

Thanks,
~Niels
diff --git a/dh_installchangelogs b/dh_installchangelogs
index 6f4c7e9c..b1594411 100755
--- a/dh_installchangelogs
+++ b/dh_installchangelogs
@@ -152,6 +152,7 @@ init();
 my $news_name="NEWS.Debian";
 my $changelog_name="changelog.Debian";
 
+my $explicit_changelog = @ARGV ? 1 : 0;
 my $default_upstream = $ARGV[0];
 my $default_upstream_text=$default_upstream;
 my $default_upstream_html;
@@ -198,11 +199,15 @@ on_pkgs_in_parallel {
 		my $tmp=tmpdir($package);
 		my $changelog=pkgfile($package,"changelog");
 		my $news=pkgfile($package,"NEWS");
-		my $upstream_changelog = $ARGV[0];
+		my $upstream_changelog;
 		my ($upstream_changelog_text, $upstream_changelog_html);
 		my $changelog_from_tmp_dir = 0;
 
-		if (! defined($upstream_changelog)) {
+		if ($explicit_changelog) {
+			$upstream_changelog = $default_upstream;
+			$upstream_changelog_text = $default_upstream_text;
+			$upstream_changelog_html = $default_upstream_html;
+		} else {
 			# Check if the upstream build system provided a
 			# changelog
 			$upstream_changelog = find_changelog("${tmp}/usr/share/doc/${package}");
@@ -211,11 +216,6 @@ on_pkgs_in_parallel {
 $changelog_from_tmp_dir = 1;
 			}
 		}
-		if (not $upstream_changelog || defined($ARGV[0])) {
-			$upstream_changelog = $default_upstream;
-			$upstream_changelog_text = $default_upstream_text;
-			$upstream_changelog_html = $default_upstream_html;
-		}
 
 		if (!$changelog) {
 			$changelog="debian/changelog";

Bug#899252: sloccount FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: sloccount
Version: 2.26-5.2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

sloccount fails to cross build from source, because it uses the build
architecture compiler. The easiest way of passing cross tools to make is
letting dh_auto_build do it. After doing so, sloccount cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru sloccount-2.26/debian/changelog 
sloccount-2.26/debian/changelog
--- sloccount-2.26/debian/changelog 2017-03-17 15:01:31.0 +0100
+++ sloccount-2.26/debian/changelog 2018-05-21 18:30:08.0 +0200
@@ -1,3 +1,10 @@
+sloccount (2.26-5.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 21 May 2018 18:30:08 +0200
+
 sloccount (2.26-5.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff --minimal -Nru sloccount-2.26/debian/rules sloccount-2.26/debian/rules
--- sloccount-2.26/debian/rules 2017-03-17 14:53:01.0 +0100
+++ sloccount-2.26/debian/rules 2018-05-21 18:30:05.0 +0200
@@ -62,7 +62,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE)
+   dh_auto_build
 
touch build-stamp
 

Bug#899038: libgit2 0.27 transition

[Pirate Praveen]

On Fri, 18 May 2018 21:22:48 +0530 Pirate Praveen 
 wrote:


libgit2 0.27 is now available in experimental. Please make sure your 
package is ready for this version by the time we upload this package to 
unstable in one to two weeks. The severity of this report will be raised 
to serious once libgit2 0.27 is uploaded to unstable.


I rebuilt cargo with libgit2 0.27 and got 4 test failures.

failures:

 dont_require_submodules_are_checked_out stdout 
	running `/<>/target/x86_64-unknown-linux-gnu/release/cargo 
build -v`

thread 'dont_require_submodules_are_checked_out' panicked at '
Expected: execs
but: exited with signal: 11
--- stdout

--- stderr
', debian/../vendor/hamcrest-0.1.1/src/core.rs:31:13
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a 
verbose backtrace.

stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: hamcrest::core::assert_that
   8: git::dont_require_submodules_are_checked_out
   9: >::call_box
  10: __rust_maybe_catch_panic

 git_dep_build_cmd stdout 
	running `/<>/target/x86_64-unknown-linux-gnu/release/cargo 
build`

thread 'git_dep_build_cmd' panicked at '
Expected: execs
but: exited with signal: 11
--- stdout

--- stderr
warning: path 
`/<>/target/x86_64-unknown-linux-gnu/cit/t20/foo/src/foo.rs` 
was erroneously implicitly accepted for binary `foo`,

please set bin.path in Cargo.toml
', debian/../vendor/hamcrest-0.1.1/src/core.rs:31:13
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a 
verbose backtrace.

stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: hamcrest::core::assert_that
   8: git::git_dep_build_cmd
   9: >::call_box
  10: __rust_maybe_catch_panic

 git_build_cmd_freshness stdout 
	running `/<>/target/x86_64-unknown-linux-gnu/release/cargo 
build`

thread 'git_build_cmd_freshness' panicked at '
Expected: execs
but: exited with signal: 6
--- stdout

--- stderr
malloc_consolidate(): invalid chunk size
', debian/../vendor/hamcrest-0.1.1/src/core.rs:31:13
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a 
verbose backtrace.

stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: hamcrest::core::assert_that
   8: git::git_build_cmd_freshness
   9: >::call_box
  10: __rust_maybe_catch_panic


failures:
dont_require_submodules_are_checked_out
git_build_cmd_freshness
git_dep_build_cmd

test result: FAILED. 34 passed; 3 failed; 1 ignored; 0 measured; 0 
filtered out

Bug#899232: thunderbird: Main screen corrupted with 52.8.0-1

[Jean-Luc]

Hello Carsten,

Le 21/05/2018 à 17:02, Carsten Schoenert a écrit :

Hello Jean-Luc,

On Mon, May 21, 2018 at 11:18:36AM +0200, Jean-Luc Coulon (f5ibh) wrote:
  

Since the latest update to 52.8.0-1, the main window is corrupted. And
the problem is becoming worse as I use thunderbird: it seems that the
old data arent correctly overwritten.

I remarked this kind of behaviour also with the experimental version.

looks like a GTK+3 related issue which I can't reproduce on my
installations (under Testing). If you say you see this also with
Thunderbird from experimental I even more think this is mostly related
to GTK+3. The Thunderbird version 52.7.0-1 is now almost 6 weeks old,
version 52.8.0 and 60.0 are just some days or weeks and things in
unstable moving fast.

Thanks for the informations.

Currently there is nothing I can suggest to do. Except to play around
with Wayland/X11 and some other Desktop Environment.
FYI, I just tried gnome/xwayland , gnome/x11, gnome flashback 
(metacity): all these flavours of gnome give the same problem (them 
icorrectly managed).

But on the other hand, it works fine with xfce.

But I will not switch to xfce, I still have some colour managment with it.

I think it will not be easy to have a fix. The gtk guys have sometimes a 
stange way to manage the updates (API change without correct versioning 
for instance)


Regards

Jean-Luc

Bug#894762: cups-daemon: with IdleExitTimeout 60, correctly exits when idle for 60 s, but immediately respawns [regression]

[Brian Potkin]

forcemerge 894762 898745
thanks


On Sun 20 May 2018 at 12:01:04 +0200, Francesco Poli wrote:

> On Fri, 18 May 2018 18:58:21 +0100 Brian Potkin wrote:
> 
> > On Wed 04 Apr 2018 at 22:29:07 +0200, Francesco Poli wrote:
> > 
> > > Looking forward to hearing back from you.
> > > Thanks for your time and patience!
> > 
> > Not too long a wait, I hope, Francesco.
> > 
> > Please try the technique in #898745
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898745
> > 
> > and see how you go on.
> 
> Hello,
> I have just given cups-daemon/2.2.7-5 a try with socket activation
> re-enabled.
> 
> I really seems to work as intended.
> The bug fix appears to solve the issue!
> Thank you so much.
> 
> I think this bug report may be forcemerged with #898745 (and thus
> closed). Please do so, if you agree

Doing as you suggest. Thanks for the update.

Cheers,

Brian.

Bug#876478: ben tracker --global-conf ignores settings

[Sebastiaan Couwenberg]

On 05/15/2018 11:15 AM, Mehdi Dogguy wrote:
> On 2018-05-14 18:46, Sebastiaan Couwenberg wrote:
>> On 05/14/2018 08:26 AM, Mehdi Dogguy wrote:
>>> On 2018-05-14 08:01, Sebastiaan Couwenberg wrote:
 Unfortunately that doesn't apply cleanly on top of 0.7.4 for
 stretch. If
 you can provide a rebased commit for 0.7.4 I'm willing to test that.

>>>
>>> No problem. Here it is (attached). Thanks for your tests!
>>
>> Thanks for the patch, it doesn't seem to work as expected, though.
>>
>> `ben tracker` downloads the Packages & Sources files again even when
>> `ben download` downloaded them just before. It also uses the current
>> working directory for the downloaded files instead of the cache-dir from
>> the global.conf.
>>
>> It looks like this is caused by the custom template that was built with
>> the old ben, because switching the template to debianrt in global.conf
>> results in the expected behaviour.
>>
> 
> Indeed. I didn't explain fully how to apply the patch. My apologies.
> 
> The only effect of my second patch is to build templates differently to
> avoid linking and include all Ben's library. So in order to have this
> bug fixed, templates must be recompiled.
> 
>> Rebuilding the template fails when executed from the root of the git
>> directory:
>>
>>  $ ocamlbuild -pkg ben debiangis.cmxs
>>  + /usr/bin/ocamlopt unix.cmxa -I /usr/lib/ocaml/ocamlbuild
>> /usr/lib/ocaml/ocamlbuild/ocamlbuildlib.cmxa -I /usr/lib/ocaml -I
>> /usr/lib/ocaml/ben -I /usr/lib/ocaml/bytes -I /usr/lib/ocaml/ocamlgraph
>> -I /usr/lib/ocaml/pcre -I /usr/lib/ocaml/tyxml -I /usr/lib/ocaml/uutf
>> /usr/lib/ocaml/unix.cmxa /usr/lib/ocaml/pcre/pcre.cmxa
>> /usr/lib/ocaml/ocamlgraph/graph.cmxa /usr/lib/ocaml/str.cmxa
>> /usr/lib/ocaml/uutf/uutf.cmxa /usr/lib/ocaml/tyxml/tyxml.cmxa
>> /usr/lib/ocaml/ben/benl.cmxa myocamlbuild.ml
>> /usr/lib/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
>>  File "myocamlbuild.ml", line 1:
>>  Error: Files /usr/lib/ocaml/unix.cmxa and /usr/lib/ocaml/unix.cmxa
>>     both define a module named Unix
>>
> 
> It is true that the fix needs a documentation update to specify how
> templates should be built. I'll send you one very soon.
> 
> If you have an already built plugin, you may use the /usr/lib/ocaml/expunge
> tool to hide/remove non-necessary modules (that you can list using
> ocamlobjinfo). But, in any case, I'll provide a new procedure to build
> custom plugins.

Do you still have to for the documentation update?

Kind Regards,

Bas

Bug#899248: debhelper: upstream changelog no longer installed

[Sven Joachim]

On 2018-05-21 16:28 +, Niels Thykier wrote:

> Control: tags -1 patch
> Control: severity -1 serious
>
> On Mon, 21 May 2018 17:05:54 +0200 Sven Joachim  wrote:
>> Package: debhelper
>> Version: 11.3
>> 
>> Upon rebuilding (binary-arch only) ncurses with debhelper 11.3, I found
>> that lintian would notice missing upstream changelogs:
>> 
>> ,
>> | P: libtinfo6: no-upstream-changelog
>> | P: libtinfo5: no-upstream-changelog
>> | P: lib64tinfo6: no-upstream-changelog
>> | P: ncurses-bin: no-upstream-changelog
>> | P: ncurses-examples: no-upstream-changelog
>> `
>> 
>> In debian/rules I have "dh_installchangelogs -a NEWS", nothing fancy.
>> And dh_installchangelogs silently skipped this file.
>> 
>> 
>> [...]
> Hi Sven,
>
> Thanks for reporting this bug.
>
> Could you please try the attached patch and see/confirm it fixes the
> issue for you?

Yep, that seems to work. :-)

Thanks,
   Sven

Bug#876478: ben tracker --global-conf ignores settings

[Mehdi Dogguy]

Hi,

On 2018-05-21 18:43, Sebastiaan Couwenberg wrote:


Do you still have to for the documentation update?



I've published new instructions on Ben's website (which
is generated from Ben's git repository). You can read
them here: https://ben.debian.net/#_tracker

Basically, it is:
$ ocamlbuild -pkg ben foo.cmx
$ ocamlopt -shared -o foo.cmxs _build/foo.cmx

In short: Do not use ocamlbuild to generate the .cmxs
file.

--
Mehdi

Bug#895866: Bug 895866

[Mirko Raner]

I'm a little surprised at the nonchalance here. In my mind, this is a
pretty serious bug that will cause many people a good amount of headaches,
myself included.
Tomcat 8.5 does not intrinsically require Java 9, so, introducing a
dependency by compiling it with Java 9 seems the wrong choice to begin
with. And having a package declare a dependency on Java 8 when it really
depends on Java 9 is a major bug; the package will install without errors
but will not actually work.

Personally, I would like to see a higher priority on this bug. And I'm sure
I will not be the only one who will appreciate this problem being fixed.

Bug#899036: libgit2 0.27 transition

[Pirate Praveen]

On Fri, 18 May 2018 21:20:16 +0530 Pirate Praveen 
 wrote:


libgit2 0.27 is now available in experimental. Please make sure your 
package is ready for this version by the time we upload this package to 
unstable in one to two weeks. The severity of this report will be raised 
to serious once libgit2 0.27 is uploaded to unstable.


The build failed, but it could be a bug in libgit2 itself as new version 
is supposed to be using mbedtls instead of openssl.


configure:19592: checking for GITCHANGEBAR
configure:19601: $PKG_CONFIG --exists --print-errors "$GP_GTK_PACKAGE >= 
2.18

  glib-2.0
  libgit2 >= 0.21"
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'openssl', required by 'libgit2', not found
configure:19606: $? = 1
configure:19624: $PKG_CONFIG --exists --print-errors "$GP_GTK_PACKAGE >= 
2.18

  glib-2.0
  libgit2 >= 0.21"
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'openssl', required by 'libgit2', not found
configure:19629: $? = 1
configure:19645: result: no
Package 'openssl', required by 'libgit2', not found
configure:19665: error: Package requirements (gtk+-3.0 >= 2.18
  glib-2.0
  libgit2 >= 0.21) were not met:

Package 'openssl', required by 'libgit2', not found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables GITCHANGEBAR_CFLAGS
and GITCHANGEBAR_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Bug#899036: libgit2 0.27 transition

[Pirate Praveen]

Control: clone -1 -2
Control: reassign -2 libgit2-dev
Control: retitle -2 libgit2.pc requires openssl even though we use 
mbedtls now

Control: found -2 0.27.0+dfsg.1-0.1

On Mon, 21 May 2018 22:33:43 +0530 Pirate Praveen  
wrote:


The build failed, but it could be a bug in libgit2 itself as new version 
is supposed to be using mbedtls instead of openssl.


cloning and assigning to libgit2.

Bug#899254: mkpasswd(1) truncates passwords to 127 characters

[Aaron Toponce]

Package: whois
Version: 5.3.0

The mkpasswd(1) binary is truncating passwords longer than 127-characters:

Unique password string for 126 characters:

$ printf 'a%.0s' {1..126} | mkpasswd -m SHA-512 -S '' -s

$6$$W.thEL8diDVRFeHWlFLX3uJQViSwuCRjGgQNzFHsGNmaRKC2opCC5Kn075sSXTyzjQu8KB36qYKzDuokqspu91

Same password string for both 127 and 128 characters:

$ printf 'a%.0s' {1..127} | mkpasswd -m SHA-512 -S '' -s

$6$$ohe17aZZw6Y3jUoSMm3bz3npIzYz2TBeXUPuvxc2LpQ.ARle/n5CF3.9yLYUPmGuLHGbc1jJKz3J/nJ5B5/yb1
$ printf 'a%.0s' {1..128} | mkpasswd -m SHA-512 -S '' -s

$6$$ohe17aZZw6Y3jUoSMm3bz3npIzYz2TBeXUPuvxc2LpQ.ARle/n5CF3.9yLYUPmGuLHGbc1jJKz3J/nJ5B5/yb1

This behavior does not match passwd(1) behavior when updating passwords in the
shadow(5) file. In this first example, a 127-character "a" string is printed,
and copy/pasted to passwd(1) for a "testing" user. The password generated by
passwd(1), which is believe is calling crypt(3), matches the password generated
with mkpasswd(1), which is also calling crypt(3), when using the same salt:

# printf 'a%.0s' {1..127}; echo

aaa
# passwd testing
Enter new UNIX password: (copy/paste from above)
Retype new UNIX password: 
passwd: password updated successfully
# grep testing /etc/shadow

testing:$6$rounds=5$3ideW/N8$6fTBlETOHVxEaxkQ/bAzuV2zd006reQXl..swD4VOevqM6scHykTuGKEU0AH06fz.56czYRYn37zoBDoy2WTx0:17672:0:9:7:::
# printf 'a%.0s' {1..127} | mkpasswd -R 5 -S '3ideW/N8' -m SHA-512 -s

$6$rounds=5$3ideW/N8$6fTBlETOHVxEaxkQ/bAzuV2zd006reQXl..swD4VOevqM6scHykTuGKEU0AH06fz.56czYRYn37zoBDoy2WTx0

In this second example, a 128-character "a" string is printed, and copy/pasted
to passwd(1), for the "testing" user, just as in the first example. However,
the password generated by mkpasswd(1) does not match, when using the same salt:

# printf 'a%.0s' {1..128}; echo


# passwd testing
Enter new UNIX password: (copy/paste from above)
Retype new UNIX password: 
passwd: password updated successfully
# grep testing /etc/shadow

testing:$6$rounds=5$qkMTUfnR$iZi0HouwMMgCPDLkrMTWbLAP7rxFvlQJrVhWWoTD6yyfG9prX2xQHkfqW4rB17hRwV5BMnugV8H9osy3cXbKo1:17672:0:9:7:::
# printf 'a%.0s' {1..128} | mkpasswd -R 5 -S 'qkMTUfnR' -m SHA-512 -s

$6$rounds=5$qkMTUfnR$ViyQ1KWaHVjBWxJbQikeSZfbp1MXyfRn2.KbTnMqcI7I/gqKmVXPW64rK/qz18LAtL5QjHoOn2CBhbWrZ/jRe.

This seems to be a bug with mkpasswd(1), by truncating passwords at 127
characters.

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o


signature.asc
Description: PGP signature

Bug#885947: marco: After updating, restart (user or pc) and log in, desktop fails

[Santiago]

Package: marco
Version: 1.18.1-3
Followup-For: Bug #885947

Thanks for answering and for the questions.

> Also, I assume, you are on Debian buster, correct?

lsb_release -ds
Debian GNU/Linux testing (buster)

cat /etc/debian_version 
buster/sid


> And what are the versions of the underlying Xserver?

dpkg -l xserver-xorg-video-*


||/ Nombre Versión  Arquitectura 
Descripción
+++-==---=
ii  xserver-xorg-video-all 1:7.7+19 amd64X.Org 
X server -- output driver metapackage
ii  xserver-xorg-video-amdgpu  18.0.1-1 amd64X.Org 
X server -- AMDGPU display driver
ii  xserver-xorg-video-ati 1:18.0.1-1   amd64X.Org 
X server -- AMD/ATI display driver wrapper
ii  xserver-xorg-video-fbdev   1:0.4.4-1+b5 amd64X.Org 
X server -- fbdev display driver
ii  xserver-xorg-video-intel   2:2.99.917+git20171229-1 amd64X.Org 
X server -- Intel i8xx, i9xx display driver
ii  xserver-xorg-video-ivtv1.1.2-2+b5   amd64X.Org 
X server -- IVTV display driver
un  xserver-xorg-video-mach64  (no 
hay ninguna descripción disponible)
un  xserver-xorg-video-modesetting (no 
hay ninguna descripción disponible)
ii  xserver-xorg-video-nouveau 1:1.0.15-2   amd64X.Org 
X server -- Nouveau display driver
ii  xserver-xorg-video-qxl 0.1.5-2  amd64X.Org 
X server -- QXL display driver
un  xserver-xorg-video-r128(no 
hay ninguna descripción disponible)
ii  xserver-xorg-video-radeon  1:18.0.1-1   amd64X.Org 
X server -- AMD/ATI Radeon display driver
ii  xserver-xorg-video-vesa1:2.3.4-1+b2 amd64X.Org 
X server -- VESA display driver
ii  xserver-xorg-video-vmware  1:13.2.1-1+b1amd64X.Org 
X server -- VMware display driver


> And what version of libxpresent do you have?
>
>   dpkg -l libxpresent1

Before updating marco (1.18.1-3 => 1.20.1-2), the libxpresent1 (1.0.0-2+b10) is 
not installed, it is a new package that will install.


> Have you already tried creating a new user with a fresh user profile?  
> Does that new user show the same symptons?

Moreover, I installed a recent DVD image (20180402-04: 13 Binary-1 amd64) on 
another disk from scratch, with the same symptoms.


> What is the exact specification of your graphics card?

lspci -nnk | grep VGA -A3
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV25 [GeForce4 Ti 
4200] [10de:0253] (rev a3)
Subsystem: Micro-Star International Co., Ltd. [MSI] NV25 [GeForce4 Ti 
4200] [1462:8700]
Kernel driver in use: nouveau
Kernel modules: nouveau


The PC woks fine in Debian 9, and too in Debian 10 with mate 1.18.1-3, just 
until I update to the following versions.

Santiago.


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

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

Versions of packages marco depends on:
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-3
ii  libcairo-gobject2 1.15.10-3
ii  libcairo2 1.15.10-3
ii  libcanberra-gtk3-00.30-6
ii  libcanberra0  0.30-6
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.29-3
ii  libgtop-2.0-112.38.0-2
ii  libice6   2:1.0.9-2
ii  libmarco-private1 1.18.1-3
ii  libpango-1.0-01.42.0-1
ii  libpangocairo-1.0-0   1.42.0-1
ii  libsm62:1.2.2-1+b3
ii  libstartup-notification0  0.12-5
ii  libx11-6  2:1.6.5-1
ii  libxcomposite11:0.4.4-2
ii  libxcursor1   1:1.1.15-1
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxinerama1  2:1.1.3-1+b3
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  marco-common  1.18.1-3
ii  mate-desktop-common   1.20.1-2
ii  zenity3.28.1-1

marco recommends no packages.

marco suggests no packages.

-- no debconf information

Bug#855034: debdiff to update to Protobuf 3.2.1 and add ruby-google-protobuf

[GCS]

On Fri, May 18, 2018 at 7:02 PM Pirate Praveen  wrote:
> On Fri, 14 Apr 2017 11:06:10 + Maarten 
> wrote:
> > tag 855034 +patch
> > retitle 855034 update to Protobuf 3.2.1 and add ruby-google-protobuf
> >
> > I attached a debdiff to update to protobuf 3.2.1 and also added a
> > decleration for the ruby-google-protobuf package.

> protobuf 3.5.2 is available in experimental.

> ruby-google-protobuf is a separate source package now.
  Indeed.

> Laszlo and other maintainers, what is the plan for uploading this
> version to unstable? I need this for gitlab.
  As I see, I'm the only maintainer at the moment - or other please speak up.
About the upload timing: I'll do it when I could test everything and I'm
allowed to do it.

Cheers,
Laszlo/GCS

Bug#898991: deja-dup: Deja-Dup backups failing. Calls to dbus service timing out.

[Don Alexander]

False bug. Error was in a corrupt /var/lib/Packagekit/transaactions.db 
which cause packagkitd to fail to start.

This in turn caused deja-dup not to work.


Maybe demote bug and flag it as a needed dependency.


-- 
==

Don Alexander

It's a tough job, but some mug has to do it...

RooSoft Ltd




signature.asc
Description: OpenPGP digital signature

Bug#898940: lastpass-cli: error: Peer certificate cannot be authenticated with given CA certificates

[Chris Lamb]

Dear Troy,

> I would be more that happy for you to take over maintenance of
> this package!

Thanks for letting me know. I'll get around to this soon :)


Best wishes,

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

Bug#898940: lastpass-cli: error: Peer certificate cannot be authenticated with given CA certificates

[Troy Heber]

On 05/18/18 15:56, Chris Lamb wrote:
> 
> Would you be interested in letting me adopt this package (or co-
> maintaining it?).

I would be more that happy for you to take over maintenance of
this package!

Troy

Bug#898495: [pkg-cryptsetup-devel] Bug#898495: cryptsetup: [patch] make failsleep configurable

[Guilhem Moulin]

Hi Chris,

On Sat, 12 May 2018 at 19:10:43 +0100, Chris Lamb wrote:
> It would be nice if the sleep-on-failure time was configurable, just
> like tries=N, etc.
> 
> Patch attached.

Thanks for the patch!  (We discussed about this bug IRL but let me
follow up here for the sake of transparency.)  The sleep-on-failure
behavior was added in 2:1.7.3-2 as mitigation for local brute-force
attacks (CVE-2016-4484).  See mejo's blogpost about it:

https://blog.freesources.org/posts/2016/12/CVE-2016-4484/

Given that a major refactoring of the initramfs integration is ongoing,
I didn't merge your patch.  In fact we all seem to agree that the attack
vector described in the CVE isn't really related to cryptsetup nor its
initramfs integration (if one protects the BIOS and passes the
‘panic=’ parameter to the kernel command line, the boot script no
longer yields a debug shell after a couple of failed attempts at
unlocking the root device), and that our mitigation gives a marginal
security gain.  So we're likely to remove said mitigation as part of our
refactoring.  You intended to use the ‘failsleep=’ boot parameter
to disable it, right?

Of course, since it was our response to the CVE we shouldn't remove it
silently.  I guess a follow-up to mejo's blog post and/or an entry in
the NEWS file are appropriate.  Either way, we'll keep that bug open
until we either merge your patch, or decide to remove the mitigation.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#899255: [fortunes-debian-hints] Some Debian hints are outdated

[Alexander Kernozhitsky]

Package: fortunes-debian-hints
Version: 2.01.1
Severity: normal

Some hints about Debian found in this package are outdated. For example, #31 
says about services in sysv, while systemd is used by Debian now. There are 
hints saying about packages apt-spy and apt-zip, which don't exist in archives 
now. Please update these hints for new Debian version.

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

Debian Release: buster/sid
  990 testing ftp.by.debian.org 
  500 unstableftp.by.debian.org 

--- Package information. ---
Package's Depends field is empty.

Recommends (Version) | Installed
-+-=
fortune-mod (>= 9708-31) | 1:1.99.1-7+b1


Package's Suggests field is empty.
-- 
-
Alexander Kernozhitsky

Bug#899256: calibre: Closing "Table of Content" in viewer when switching gnome workspaces

[Jureq]

Package: calibre
Version: 3.23.0+dfsg-1
Severity: minor

Dear Maintainer,

I open any ebook in calibre viewer. Table of Content panel is open. Then I
switch to another gnome workspace and back. Table of Content panel gets closed.
I have to reopen it with Ctrl-T (or icon).
The same error in calibre 2.75 in stable (stretch).



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

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

Versions of packages calibre depends on:
ii  calibre-bin  3.23.0+dfsg-1
ii  fonts-liberation 1:1.07.4-6
ii  imagemagick  8:6.9.9.34+dfsg-3+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.9.34+dfsg-3+b1
ii  libjs-coffeescript   1.12.7~dfsg-3
ii  libjs-mathjax2.7.3+dfsg-1
ii  poppler-utils0.63.0-2
ii  python-apsw  3.16.2-r1-2+b1
ii  python-chardet   3.0.4-1
ii  python-cherrypy3 8.9.1-2
ii  python-cssselect 1.0.3-1
ii  python-cssutils  1.0.2-1
ii  python-dateutil  2.6.1-1
ii  python-dbus  1.2.6-1
ii  python-feedparser5.2.1-1
ii  python-html5-parser  0.4.4-1
ii  python-lxml  4.2.1-1
ii  python-markdown  2.6.9-1
ii  python-mechanize 1:0.2.5-3
ii  python-msgpack   0.5.6-1
ii  python-netifaces 0.10.4-1
ii  python-pil   4.3.0-2
ii  python-pkg-resources 39.1.0-1
ii  python-pyparsing 2.2.0+dfsg1-2
ii  python-pyqt5 5.10.1+dfsg-1
ii  python-pyqt5.qtsvg   5.10.1+dfsg-1
ii  python-pyqt5.qtwebkit5.10.1+dfsg-1
ii  python-regex 0.1.20171212-2
ii  python-routes2.4.1-1
ii  python2.72.7.15-1
ii  xdg-utils1.1.2-2

Versions of packages calibre recommends:
ii  python-dnspython  1.15.0-1

calibre suggests no packages.

-- no debconf information

Bug#899257: RFP: crelay -- Controlling different relay cards for home automation with a Linux software

[Victoria Ivanova]

Package: wnpp
Severity: wishlist

https://github.com/ondrej1024/crelay It is licensed under
GNU General Public License Version 2
https://github.com/ondrej1024/crelay/blob/master/LICENSE.  It makes it
possible to control USB relay cards from different manufacturers under
Linux in unified way.

Bug#899248: debhelper/11.3 appears to break gem2deb/0.39 autopkgtest in testing

[gregor herrmann]

On Mon, 21 May 2018 18:07:43 +, Paul Gevers wrote:

> tl;dr: debhelper/11.3 appears to break gem2deb/0.39 autopkgtest in testing
> see: https://ci.debian.net/packages/g/gem2deb/testing/amd64/
> and https://qa.debian.org/excuses.php?package=debhelper

This looks like #899248.

| Failure: test: Gem2Deb should install CHANGELOG.rdoc as upstream changelog. 
(Gem2DebTest):


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Willi Resetarits + Stubnblues: da r abr


signature.asc
Description: Digital Signature

Bug#897127: psensor FTBFS on i386/armhf: FAIL: test-cppcheck.sh

[Enrico Tröger]

On 05/13/2018 02:36 PM, Joachim Reichel wrote:
> See bug 898327.

Thanks.
Just for the records, for me the problem is gone with the new version.

I guess this bug report can be closed.




signature.asc
Description: OpenPGP digital signature

Bug#899118: flash-kernel: add missing arm64 boards

[Karsten Merker]

On Mon, May 21, 2018 at 01:01:56AM +0200, Heinrich Schuchardt wrote:
> On 05/20/2018 09:15 PM, Karsten Merker wrote:
> > On Sat, May 19, 2018 at 02:57:41PM +0200, Heinrich Schuchardt wrote:
> > 
> >> Package: flash-kernel
> >> Version: 3.94
> >> Severity: normal
> >> Tags: patch
> >>
> >> Add 60 missing database entries for arm64 boards
> >> supported both by U-Boot and by Linux:
[...]
> > many thanks for the patch.  Just to make sure that we don't run
> > into problems later on: do all these boards really use u-boot's
> > config_distro_bootcmd.h and thereby work properly with
> > bootscr.uboot-generic?
> > 
> > When looking at the defconfigs for several of these systems, I
> > see e.g. CONFIG_BOOTARGS settings that don't really match what I
> > would expect for systems using config_distro_bootcmd.h.
> > Three random examples:
> > 
> > - r8a77995_draak_defconfig:
> >   CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs 
> > nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20"
> > 
> > - ls1088ardb_sdcard_qspi_defconfig:
> >   CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
> > earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 
> > default_hugepagesz=2m hugepagesz=2m hugepages=256"
> > 
> > - hikey_defconfig:
> >   CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw"
[,,,]
> For a board to be able to benefit from flash-kernel U-Boot must:
> 
> - be capable to load and execute boot.scr
> - provide the booti command
> - allow the definition of the following environment variables:
>   - devtype, devnum, partition
>   - fdtfile
>   - kernel_addr_r
>   - fdt_addr_r
>   - ramdisk_addr_r
> 
> In your examples above I could not find any evidence that U-Boot cannot
> be configured and built to fulfill these requirements.
> 
> For instance build
> 
> make r8a77995_draak_defconfig
> make menuconfig
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_BOOTARGS="console=ttySC0,115200"
> CONFIG_ENV_IS_IN_MMC=y (this is a default value)
> make -j6
> 
> Setup missing environment variables interactively and save them to MMC
> and you can rely on flash-kernel for booting.
> 
> ls1088ardb_sdcard_qspi_defconfig and hikey_defconfig select
> CONFIG_DISTRO_DEFAULTS=y. CONFIG_BOOTARGS has to be reconfigured.
> 
> This patch is only about providing flash-kernel for the boards. It is
> not about providing U-Boot configured to match flash-kernel's requirements.
> 
> I think that even for boards for which we do not provide U-Boot as a
> Debian package we should allow the usage of flash-kernel without setting
> up a local override for the machine database (/etc/flash-kernel/db).

Hello,

our policy has always been to only add an entry for an
armhf/arm64 system to the flash-kernel database if this entry
works out of the box with the default mainline u-boot
configuration for the respective device.  Users usually expect
that a system boots out of the box without having to build a
non-standard u-boot configuration and modify the default
environment if the system is listed in the flash-kernel machine
db.

I'm open to arguments to the contrary, but for now I believe that
is makes sense to keep this policy.

Having to build u-boot with an undocumented non-standard
configuration and having to modify various non-obvious parts of
the default environment (which possibly includes having to find
out the platform-specific kernel_addr_r, fdt_addr_r and
ramdisk_addr_r values for systems where they are not already
defined in the default environment) to make the system boot is an
extremely high and completely unexpected hurdle for a "normal"
user, and I believe that we would do a large part of our userbase
a misservice by including entries that do not work out of the
box.

For somebody who has the knowledge to perform all the
aforementioned steps on the u-boot side, it's usually easy to
also add a corresponding local entry to /etc/flash-kernel/db.

I'm CCing debian-arm for further opinions on the matter.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#899118: Aw: Re: Bug#899118: flash-kernel: add missing arm64 boards

[Heinrich Schuchardt]

I will try to build those 60 images and analyze which conform to your requirements. But that will take some time.

Best regards

Heinrich

Bug#897435: eureka: please bring back the "add sidedef" button

[Jonathan Dowland]

There is a option in the config file called "sidedef_add_del_buttons"
setting it to 1 (by editing the config file) will restore those buttons.


That's satisfactory for me. I accept it's a bit of an expert-user "here
be dragons" feature.


Thanks,

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#899248: debhelper/11.3 appears to break gem2deb/0.39 autopkgtest in testing

[Paul Gevers]

user debian...@lists.debian.org
usertags 899248 needs-update
thanks

On 21-05-18 20:43, gregor herrmann wrote:
> On Mon, 21 May 2018 18:07:43 +, Paul Gevers wrote:
> 
>> tl;dr: debhelper/11.3 appears to break gem2deb/0.39 autopkgtest in testing
>> see: https://ci.debian.net/packages/g/gem2deb/testing/amd64/
>> and https://qa.debian.org/excuses.php?package=debhelper
> 
> This looks like #899248.
> 
> | Failure: test: Gem2Deb should install CHANGELOG.rdoc as upstream changelog. 
> (Gem2DebTest):
> 
> 
> Cheers,
> gregor
> 



signature.asc
Description: OpenPGP digital signature

Bug#899258: RM: ttf-adf -- ROM; all binaries built by src:fonts-adf now

[Adam Borowski]

Package: ftp.debian.org
Severity: normal


Hi!
Please remove source package ttf-adf -- all of its binaries are now dummies
built from src:fonts-adf.  The new version has transitioned to testing a few
days ago, but the old one hasn't been decrufted automatically, thus I'm
filing this RM -- please remove the old source.


Meow!