Bug#907884: vlc: Debian 9.5 hangs when opening the mkv file in vlc 3.0.4-1

[Сергей Фёдоров]

To: sub...@bugs.debian.org
Subject: vlc: Debian 9.5 hangs when opening the mkv file in vlc 3.0.4-1
Package: vlc
Version: 3.0.4-1
Severity: critical
Justification: breaks the whole system
Tags: a11y

Debian 9.5 hangs when opening the mkv file in vlc 3.0.4-1

In Debian 9.5 Sid opening a media file {avi,mkv and others} in vlc 3.0.4-1 (and 
libvlc* 3.0.4-1)
opens a window with black content, the mouse cursor moves freely across the 
screen, but the keyboard
and mouse buttons are locked, i.e. Debian hangs.

When after rebooting we install vlc 3.0.2-0+deb9u1 (and libvlc* 3.0.2-0+deb9u1) 
(from the Debian 9.5 Stable repository)
everything works fine.

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

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

Versions of packages vlc depends on:
ii  vlc-bin  3.0.4-1
ii  vlc-plugin-base  3.0.4-1
ii  vlc-plugin-qt3.0.4-1
ii  vlc-plugin-video-output  3.0.4-1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.4-1
ii  vlc-plugin-notify  3.0.4-1
ii  vlc-plugin-samba   3.0.4-1
ii  vlc-plugin-skins2  3.0.4-1
ii  vlc-plugin-video-splitter  3.0.4-1
ii  vlc-plugin-visualization   3.0.4-1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.27-5
ii  libvlc5  3.0.4-1

Versions of packages libvlc5 depends on:
ii  libc62.27-5
ii  libvlccore9  3.0.4-1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.4-1

Versions of packages vlc-bin depends on:
ii  libc6   2.27-5
ii  libvlc-bin  3.0.4-1
ii  libvlc5 3.0.4-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-19
ii  libarchive13 3.2.2-5
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.1.6-1
ii  libass9  1:0.14.0-2
ii  libavahi-client3 0.7-4
ii  libavahi-common3 0.7-4
ii  libavc1394-0 0.5.4-5
ii  libavcodec58 7:4.0.2-1+b1
ii  libavformat587:4.0.2-1+b1
ii  libavutil56  7:4.0.2-1+b1
ii  libbasicusageenvironment12018.08.28a-1
ii  libbluray2   1:1.0.2-3
ii  libc62.27-5
ii  libcairo21.15.12-1
ii  libcddb2 1.3.2-6
ii  libchromaprint1  1.4.3-2+b1
ii  libcrystalhd31:0.0~git20110715.fdd2f19-13
ii  libdbus-1-3  1.12.10-1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.6-1
ii  libdvbpsi10  1.3.2-1
ii  libdvdnav4   6.0.0-1
ii  libdvdread4  6.0.0-1
ii  libebml4v5   1.3.6-2
ii  libfaad2 2.8.8-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libfribidi0  1.0.5-3
ii  libgcc1  1:8.2.0-4
ii  libgcrypt20  1.8.3-1
ii  libglib2.0-0 2.58.0-1
ii  libgnutls30  3.5.19-1
ii  libgpg-error01.32-1
ii  libgroupsock82018.08.28a-1
ii  libharfbuzz0b1.8.8-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libkate1 0.4.1-8
ii  liblirc-client0  0.10.0-2+b1
ii  liblivemedia62   2018.08.28a-1
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-9
ii  libmatroska6v5   1.4.9-1
ii  libmicrodns0 0.0.10-1
ii  libmpcdec6   2:0.1~r495-1+b2
ii  libmpeg2-4   0.5.1-8
ii  libmpg123-0  1.25.10-2
ii  libmtp9  1.1.13-1
ii  libncursesw6 6.1+20180714-1
ii  libnfs11 2.0.0-1~exp1
ii  libogg0  1.3.2-1+b1
ii  libopenmpt-modplug1  0.3.11-1
ii  libopus0 1.3~beta+20180518-1
ii  libpng16-16  1.6.34-2
ii  libpostproc557:4.0.2-1+b1
ii  libprotobuf-lite10   3.0.0-9.1
ii  libpulse012.0-1
ii  libraw1394-112.1.2-1+b1
ii  libresid-builder0c2a 2.1.1-15

Bug#907798: fai - setup-storage unable to set GPT partition id

[Thomas Lange]

This bug was filed because growpart wants to grow only the first
partition.
On IRC you've said: re-ordering the partition table in the first place is an 
easier task

It's not easier with FAI, since the partition numbers cannot be
defined. Adding such a feature into FAI (setup-storage) would be a
major change in the code. I prefer to fix the growpart or growroot
script instead.

-- 
regards Thomas

Bug#906921: tango-starter does not start after a reboot

[Carlos Manuel Falcon Torres]

On 09/03/2018 04:39 PM, PICCA Frederic-Emmanuel wrote:

Hello carlog


I think so, It may affect to others users.

So is it possible to add this as a patch for the packaging ?


I did a MR (https://salsa.debian.org/science-team/tango/merge_requests/1)

Can you modify your MR and update the Debian/changelog in order to close the 
bug during the next upload ?

- create a new entry (increase the debian version).
- add a message to close the bug :))

Ok, I did it. It is right?


thanks

Fred

Bug#906189: linux-image-4.17.0-1-amd64: Laptop does not suspend in 4.17 - worked up to 4.16

[Christoph Haas]

git-bisect takes ages. I got this far yet:

- 4.16.0-2 = good
- 4.17.0-3 = bad
- 4.19.0-rc2 = good





signature.asc
Description: OpenPGP digital signature

Bug#907704: choose-mirror: default to deb.debian.org

[Julien Cristau]

Control: tag -1 + patch

On 08/31/2018 06:27 PM, Julien Cristau wrote:
> Package: choose-mirror
> Severity: wishlist
> X-Debbugs-Cc: tfh...@debian.org
> 
> I think it's time for choose-mirror to stop asking by default.  AFAIK
> deb.debian.org works well enough now that we don't need users to
> manually select a mirror close to them.
> 
> PoC patch, completely untested:
> 
Updated patch, at least somewhat tested.  It downgrades the debconf
priority for mirror/http/countries and mirror/http/mirrors so they're
not asked by default (previous patch would still ask for a country).
Only the "proxy" question remains; I'd kind of want to skip it by
default unless we find out we can't get at the mirror directly, but
that's something for another bug/patch.

Cheers,
Julien
>From 5773506afb888b03d03b570bda4492c293d0d2f9 Mon Sep 17 00:00:00 2001
From: Julien Cristau 
Date: Mon, 3 Sep 2018 15:34:39 +0200
Subject: [PATCH] Default http mirror to deb.debian.org (closes: #907704).

---
 choose-mirror.c| 6 --
 debian/changelog   | 6 ++
 debian/choose-mirror-bin.templates.http-in | 3 ++-
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/choose-mirror.c b/choose-mirror.c
index 2662c5f..f44c7ad 100644
--- a/choose-mirror.c
+++ b/choose-mirror.c
@@ -617,8 +617,10 @@ static int choose_country(void) {
 		debconf_set(debconf, countries, country);
 		debconf_fget(debconf, DEBCONF_BASE "country", "seen");
 		debconf_fset(debconf, countries, "seen", debconf->value);
+		debconf_input(debconf, "medium", countries);
+	} else {
+		debconf_input(debconf, "high", countries);
 	}
-	debconf_input(debconf, "high", countries);
 
 	free (countries);
 	return 0;
@@ -665,7 +667,7 @@ static int choose_mirror(void) {
 		debconf_subst(debconf, mir, "mirrors", list);
 		free(list);
 
-		debconf_input(debconf, "high", mir);
+		debconf_input(debconf, "medium", mir);
 		free(mir);
 	} else {
 		char *host = add_protocol("hostname");
diff --git a/debian/changelog b/debian/changelog
index 762d821..e7fbf12 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+choose-mirror (2.92) UNRELEASED; urgency=medium
+
+  * Default http mirror to deb.debian.org (closes: #907704).
+
+ -- Julien Cristau   Mon, 03 Sep 2018 15:33:14 +0200
+
 choose-mirror (2.91) unstable; urgency=medium
 
   * Update Vcs-{Browser,Git} to point to salsa (alioth's replacement).
diff --git a/debian/choose-mirror-bin.templates.http-in b/debian/choose-mirror-bin.templates.http-in
index 785851e..2dc1f02 100644
--- a/debian/choose-mirror-bin.templates.http-in
+++ b/debian/choose-mirror-bin.templates.http-in
@@ -29,13 +29,14 @@ _Description: Debian archive mirror country:
 Template: mirror/http/mirror
 Type: select
 Choices: ${mirrors}
+Default: deb.debian.org
 # :sl1:
 _Description: Debian archive mirror:
  Please select a Debian archive mirror. You should use a mirror in
  your country or region if you do not know which mirror has the best
  Internet connection to you.
  .
- Usually, ftp..debian.org is a good choice.
+ Usually, deb.debian.org is a good choice.
 
 Template: mirror/http/hostname
 Type: string
-- 
2.18.0

Bug#791944: /etc/init.d/sendsigs kills systemd-udevd upon shutdown, causing dmsetup to hang

[Michael Biebl]

Hi

On 8/11/18 12:47, Trek wrote:
> I can confirm the version 239-7 is affected by this bug and it's fixed
> by the patch written by Pali Rohár
> 
> I've added a fix in the maintainer scripts to actually create rc.d
> symlinks on upgrade and some little lifting to the init.d script
> 
> thanks to all the people involved!
> 
> also I would like to port the init.d script to the new init-d-script
> format, it would be accepted? or at least to move the start and stop
> code in functions, to remove code duplication in the restart action

The patch looks fine to me from a cursory glance. I haven't tested it
though. Trek, I assume you built a test package and did a test-upgrade
checking it works as expected?

If you don't mind, would you send a git formatted patch so the changes
are properly attributed to you?
The git commit message should follow gbp-dch style, with a Closes: #791944.
A MR via https://salsa.debian.org/systemd-team/systemd would be even nicer.
It's not a pre-requisite it just makes things more convenient for us and
speeds up processing.

Thanks,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#905885: diffoscope: skipping tests on ci.debian.net is perhaps wrong?

[Mattia Rizzolo]

Control: allow to override @skip_unless_tools_exist during tests and fail the 
test if the tool is missing

On Sun, Aug 12, 2018 at 12:03:50AM +1000, Stuart Prescott wrote:
> *also* diffoscope recommends apktool but tests on ci.d.n do not fail (but 
> should, I think)

what you say here it's half true: the autopkgtest has Depends: all the
recommends that we have.  What is happening is that ci.d.n/autopkgtest
(no clue what piece of the puzzle is responsable for this) is
downloading the test dependencies from unstable if they are not
available on testing, silently.
I believe you may want to get in touch with the CI team for this, I
don't think there is much a package can do here.

> > > Perhaps @tool_required could be extended with an "all tools required"
> > > mode such that no tests are skipped or missing tools are a test failure
> > > (or error). An environment variable would work for setting that mode
> > > and that mode used at package build time and in autopkgtest.
> > 
> > (One difficulty with "just" extending @tool_required is that sometimes
> > we really do want to skip the tests as they require a newer/older
> > version of a particular tool in order that we can correctly match up
> > the output.)

That's an interesting idea, and I'm retitling this bug to do this.
Though what we would need to twak is the @skip_unless_tools_exist
decorator we use in the tests.
Also, we have comparators (and tests) for tools that Debian doesn't
ship, so if we add a flag to make @skip_unless_tools_exist fail a test
instead of skipping it, we would also need to provide a mechanism to
"override the override" and have it really skip those :)

I'm not exactly sure how we should handle the various other
@skip_unless_tool_is_* and friends though...

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#907859: task btrfs-transacti:663 blocked for more than 120 seconds

[Russell Mosemann]

Package: linux-image-4.17.0-0.bpo.3-amd6
Severity: important

 
Sep 03 08:18:04 vhost004 kernel: INFO: task btrfs-transacti:692 blocked for 
more than 120 seconds.
Sep 03 08:18:06 vhost004 kernel:   Tainted: G  I   
4.17.0-0.bpo.3-amd64 #1 Debian 4.17.17-1~bpo9+1
Sep 03 08:18:07 vhost004 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 03 08:18:07 vhost004 kernel: btrfs-transacti D0   692  2 0x8000
Sep 03 08:18:08 vhost004 kernel: Call Trace:
Sep 03 08:18:09 vhost004 kernel:  ? __schedule+0x3dc/0x860
Sep 03 08:18:09 vhost004 kernel:  schedule+0x32/0x80
Sep 03 08:18:09 vhost004 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Sep 03 08:18:10 vhost004 kernel:  ? remove_wait_queue+0x60/0x60
Sep 03 08:18:10 vhost004 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Sep 03 08:18:10 vhost004 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Sep 03 08:18:11 vhost004 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Sep 03 08:18:11 vhost004 kernel:  btrfs_commit_transaction+0xc8/0x8e0 [btrfs]
Sep 03 08:18:12 vhost004 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Sep 03 08:18:12 vhost004 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Sep 03 08:18:13 vhost004 kernel:  kthread+0xf8/0x130
Sep 03 08:18:13 vhost004 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Sep 03 08:18:13 vhost004 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Sep 03 08:18:14 vhost004 kernel:  ret_from_fork+0x35/0x40
Sep 03 08:18:14 vhost004 systemd[1]: systemd-journald.service: Main process 
exited, code=killed, status=6/ABRT
Sep 03 08:18:15 vhost004 systemd[1]: systemd-journald.service: Unit entered 
failed state.
Sep 03 08:18:16 vhost004 systemd[1]: systemd-journald.service: Failed with 
result 'watchdog'.

 

Bug#906921: tango-starter does not start after a reboot

[PICCA Frederic-Emmanuel]

Hello carlog

> I think so, It may affect to others users.

So is it possible to add this as a patch for the packaging ?

> I did a MR (https://salsa.debian.org/science-team/tango/merge_requests/1)

Can you modify your MR and update the Debian/changelog in order to close the 
bug during the next upload ?

- create a new entry (increase the debian version).
- add a message to close the bug :))


thanks

Fred

Bug#906921: tango-starter does not start after a reboot

[Carlos Manuel Falcon Torres]

Hello Fred,


On 09/03/2018 03:03 PM, PICCA Frederic-Emmanuel wrote:

Hello Carlos,


Dear Maintainer,
We saw that in some machines the tango-starter did not start after
rebooting the PC.
Note: We are using a custom version of the tango package  (
9.2.5a+dfsg1-2+patch1~bpo9+0~alba+1)

is this patch interesting for others ?

I think so, It may affect to others users.

# Should-Start:  tango-db network
# Should-Stop:   tango-db network
Could you add this fix in the init script of the official package? If
you prefer I can do a PR in salsa.d.o

Yes it would be great :)), and then prepare a new debian revision for upload :)

I did a MR (https://salsa.debian.org/science-team/tango/merge_requests/1)


cheers

Sorry for the delay, I was on holydays.


Best,
Carlos

Bug#901502: ITP: twig-extensions -- Twig Extensions

[Joost van Baal-Ilić]

Hi Felipe,

Thanks for the reminder.

On Mon, Sep 03, 2018 at 10:31:24AM -0300, Felipe Sateler wrote:
> On Thu, Jun 14, 2018 at 9:41 AM Joost van Baal-Ilić 
> wrote:
> > On Thu, Jun 14, 2018 at 09:11:46AM -0400, Felipe Sateler wrote:
> > > On Thu, 14 Jun 2018 10:27:40 +0200 Joost van =?utf-8?Q?Baal-Ili=C4=87?= <
> > > joos...@debian.org> wrote:
> > > > Package: wnpp
> > > > Severity: wishlist
> > > > Owner: Joost van Baal-Ilić 
> > > >
> > > > * Package name: twig-extensions
> > > >   Version : 1.3.0
> > > >   Upstream Author : Fabien Potencier
> > > > * URL : https://github.com/twigphp/Twig-extensions
> > > > * License : MIT/X
> > > >   Programming Lang: PHP
> > > >   Description : Twig Extensions
> > > >
> > > >  The Twig Extensions is a library that provides several useful
> > > >  extensions for Twig that do not belong to the core.  It currently
> > > >  ships Text, i18n, Intl, Array and Date Extensions.
> > > >
> > > >  Symphony's Twig is a flexible, fast, and secure template engine for
> > > >  PHP.
> > >
> > > I have made an attempt at packaging this at [1] (it's needed by
> > > phpmyadmin too). However, I've lacked time to properly test and request
> > > review by more experienced PHP people. Please feel free to use my attempt
> > > as a starting point if it is useful.
> > >
> > > [1] https://salsa.debian.org/phpmyadmin-team/twig-extensions
> >
> > Thanks, this is very likely helpful indeed.  Note that other previous work
> > is available from
> > https://github.com/eduvpn/eduvpn-debian/tree/master/Twig-extensions too...
> 
> Any update on this?

Not really.

> It would be great if this were uploaded to debian, so phpmyadmin can be
> updated.

Some preliminary work is still available from
https://github.com/eduvpn/eduvpn-debian/tree/master/Twig-extensions .  Plan is
still to move this to salsa, in a properly setup git repo (e.g. gbp-style, or
whatever is most appropriate).

Feel free to pick up the work, btw.  I'd be happy to comaintain.

Bye,

Joost



signature.asc
Description: Digital signature

Bug#902820: gmap: FTBFS on stretch/amd64 if CPU has SSE2 and nothing more

[Alex Mestiashvili]

I believe the bug is fixed in just uploaded version 2018-07-04-3

The package is non-free and thus autobuilding is not enabled.
I've asked nonf...@release.debian.org to mark gmap as autobuildable, but
haven't got an answer so far.

Regards
Alex

Bug#907882: snapshot.debian.org: 193.62.202.27 backend for snapshot.d.o returns 404

[Sebastien Delafond]

Package: snapshot.debian.org
Severity: important

One of the backends serving snapshot.d.o seems to have issues:

  curl -H 'Host: snapshot.debian.org' 
http://193.62.202.27/archive/debian/20150929T041530Z/dists/jessie/contrib/binary-amd64/Packages.gz
 -> 404
  curl -H 'Host: snapshot.debian.org' 
http://185.17.185.185/archive/debian/20150929T041530Z/dists/jessie/contrib/binary-amd64/Packages.gz
 -> 200

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

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

Bug#907799: fai - Does not execute scripts

[Thomas Lange]

Here's a patch for this:

https://github.com/faiproject/fai/commit/f5bfc186e796f68823a36ca04a97f17e01ca233d

-- 
regards Thomas

Bug#907807: After upgrading to OpenSSL 1.1.1, many sites are unreachable

[Antoine Beaupré]

On 2018-09-02 14:53:15, Vincent Bernat wrote:
> Package: linkchecker
> Version: 9.4.0-2
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hey!
>
> Since the upgrade to OpenSSL 1.1.1pre9 in sid, linkchecker is unable
> to check many sites including:
>
>  - ones without SNI
>  - ones with DH parameters too small
>  - ones using TLS 1.0
>  - ones still using SHA1 for the signature (get.adobe.com)

Would you mind citing an example for each of those?

Thanks,

A.

-- 
There is no power on earth from which we should be prepared to accept
an order to kill.
   - Albert Einstein

Bug#907863: libeclipse-osgi-java, libequinox-osgi-java: error when trying to install together

[Emmanuel Bourg]

Hi Markus,

Le 03/09/2018 à 14:48, Markus Koschany a écrit :

> I think this could have been better communicated. I was the one who
> split libequinox-osgi-java off from Eclipse. Why can't we just use the
> existing package and update it accordingly? In any case giving a reason
> for a package takeover by another package even for team-maintained
> packages seems appropriate to me. A bug report would have been ideal for
> this sort of discussion.

Sorry if this wasn't clear but I did mention taking over
libequinox-osgi-java with src:equinox-framework in July when I exposed
my plan to package the Eclipse dependencies required by AspectJ [1] on
the debian-java mailing list. I didn't receive any feedback on this
point and I didn't expect it would be controversial.

Don't get me wrong, this is definitely not a disapprobation of your work
and I apologize if it looks like it. Your move to split
libequinox-osgi-java from src:eclipse was the right decision to move
things forward and I fully support it. But after having packaged a large
set of Eclipse modules the libequinox-osgi-java package now appears at
odds with the newly introduced packages (Maven Central as upstream vs
Eclipse Git repository, different naming convention, different build
system, no upstream version tracking). That's why I think it's more
consistent to replace libequinox-osgi-java now.

Emmanuel Bourg

[1] https://lists.debian.org/debian-java/2018/07/msg00020.html

Bug#907810: [pkg-gnupg-maint] Bug#907810: gpg --no-verbose --verify is too verbose

[Werner Koch]

On Mon,  3 Sep 2018 12:52, vinc...@vinc17.net said:

> So, do you mean that it is a bug in Mutt, which doesn't filter them
> out?

Yes, if you don't want to see them.  IIRC, tlr once used a wrapper
process to invoke the actual tool.  I have not used the direct
invocation for 15 years.

Anyway it is better to use crypt_set_gpgme ;-)


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpZScnCNO2b5.pgp
Description: PGP signature

Bug#907829: p4est: FTBFS on single CPU machines (?)

[Santiago Vila]

On Mon, Sep 03, 2018 at 01:03:27PM +0300, Adrian Bunk wrote:
> On Mon, Sep 03, 2018 at 01:22:47AM +0200, Santiago Vila wrote:
> >...
> > This single-CPU thing has been discussed before and the bugs have
> > never stopped being serious:
> > 
> > https://lists.debian.org/debian-devel/2017/02/msg00380.html
> >...
> 
> Do you have a statement from a member of the release team saying so?

FTBFS bugs have always been serious. Do you have a statement from a
member of the release team saying specifically that those bugs
should be buster-ignored?

(That's what we should really do, btw, if we wanted a serious bug not
to be RC).

> >...
> > Ok, my autobuilder is not one of buildd.debian.org. So what? Packages
> > *must* be buildable on any system where Debian itself runs (provided
> > there is enough RAM and disk), i.e. on any autobuilder which is not
> > misconfigured. Having a single CPU does not count as a "misconfiguration".
> 
> It is completely arbitrary if you want to define that requiring any
> amount of RAM or disk usage is fine, but a similar requirement for 
> the number of CPUs must not happen.

No, it's not arbitrary at all, because requiring a big amount of RAM
is not a bug [*], while requiring 2 CPUs has always been a serious bug.

[*] Only in very extreme cases like this one I went ahead and filed a bug:

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

but never as a serious bug.

> > Nothing else, like CPU speed, number of CPUs, instruction set above
> > the baseline amd64, etc. should be assumed or taken for granted
> > "just because buildd.debian.org is that way".
> > 
> > Otherwise the package will have a hidden and undeclared
> > "build-depends: buildd.debian.org" (so to speak), and I would consider
> > such build restriction completely unacceptable.
> >
> > No, we don't follow "de-facto standards", we just follow standards,
> > and so far we have not formally declared single-cpu systems as "unsuitable
> > for building" (by way of general resolution or by policy).
> >...
> 
> What packages actually follow is "builds on the buildds".

No, that's only a close approximation of what we do, but it's not what we do.

Building ok in buildd.debian.org is a necessary condition but it's not
sufficient.

Missing build-depends, for example, have always been serious bugs,
even if they do not happen in the official buildds.

Therefore "builds in buildd.debian.org" and "it has a FTBFS which is RC"
are not always the same thing.

> We don't need a GR to formally declare that
> - some packages don't build with only 1 CPU,
> - some packages don't build with only 8 GB RAM
> - some packages don't build with only 70 GB storage

No, what we don't need is a GR to declare that FTBFS bugs are serious.

If you think certain serious bugs should not be RC, that's an issue
for the release managers to decide, and we would have to use
buster-ignore for that.

What you did here sounds like "downgrade because this is not RC
because I say so" to me.

> >...
> > And no, single-cpu is not exotic. You are only considering physical
> > machines, but there is a whole world of virtualization out there where
> > you can still choose the number of CPUs in the system, and single-cpu
> > is still cheaper (and I guess it will still be for a long time).
> 
> Yes, but that usually also limits the amount of RAM

You are speaking about linode, digital ocean, vultr, etc.

But other providers, like GCE or mivocloud, allow changing CPUs and
RAM in an independent way, so that's not really a problem for me.

> and you are fine with packages using any amount of that.

I'm not really "fine" with any amount of RAM, but I accept as a fact of
life that some packages will need a lot of RAM.

But I can't accept as a fact of life that a package needs several CPUs
to build, because that's a serious bug. In this case it's the package
the one needing a change, not my building setup.

[ You will notice that not even for this particular report I have
  needed a multi-cpu machine. The build log suggested that it was a
  "number-of-cpu" problem. The maintainer has suggested a patch,
  I tried it, and it worked ].

> The machine you want to enable to build all packages would
> have the following specs:
> - 1 CPU
> - 16 GB RAM
> - 75 GB storage
> 
> This is an insane configuration.

You are perhaps assuming that I'm trying to build all packages on a
single machine which is able to build everything.

That would be insane indeed, but that's *not* what I do, because
it would be a waste of resources.

I build packages in several different machines, I keep track of the amount
of RAM required by each package so that I'm efficient at using RAM.

Also, some of my virtual machines are self-hosted by KVM and virt-manager,
so I can easily have a single CPU and a lot of RAM if required.

On the contrary, I do *not* keep track of packages requiring more than
one CPU in order to build them in a different machine, because that's
a serious FTBFS bug and I should never 

Bug#901502: ITP: twig-extensions -- Twig Extensions

[Felipe Sateler]

Hi Joost,
On Thu, Jun 14, 2018 at 9:41 AM Joost van Baal-Ilić 
wrote:

> Hi Felipe,
>
> On Thu, Jun 14, 2018 at 09:11:46AM -0400, Felipe Sateler wrote:
> > On Thu, 14 Jun 2018 10:27:40 +0200 Joost van =?utf-8?Q?Baal-Ili=C4=87?= <
> > joos...@debian.org> wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Joost van Baal-Ilić 
> > >
> > > * Package name: twig-extensions
> > >   Version : 1.3.0
> > >   Upstream Author : Fabien Potencier
> > > * URL : https://github.com/twigphp/Twig-extensions
> > > * License : MIT/X
> > >   Programming Lang: PHP
> > >   Description : Twig Extensions
> > >
> > >  The Twig Extensions is a library that provides several useful
> extensions
> > >  for Twig that do not belong to the core.  It currently ships Text,
> i18n,
> > >  Intl, Array and Date Extensions.
> > >
> > >  Symphony's Twig is a flexible, fast, and secure template engine for
> PHP.
> >
> > I have made an attempt at packaging this at [1] (it's needed by
> phpmyadmin
> > too). However, I've lacked time to properly test and request review by
> more
> > experienced PHP people. Please feel free to use my attempt as a starting
> > point if it is useful.
> >
> > [1] https://salsa.debian.org/phpmyadmin-team/twig-extensions
>
> Thanks, this is very likely helpful indeed.  Note that other previous work
> is
> available from
> https://github.com/eduvpn/eduvpn-debian/tree/master/Twig-extensions too...
>

Any update on this? It would be great if this were uploaded to debian, so
phpmyadmin can be updated.

-- 

Saludos,
Felipe Sateler

Bug#907769: chromium: tab consistently crashes when visiting arduino webpage

[Marius Mikucionis]

Package: chromium
Version: 69.0.3497.12-1
Followup-For: Bug #907769

Dear Mike,

Thank you for the fast reply.

I have replaced the packages (see the new list below) with the Debian ones and 
the issue persists.
I also tried it on a fresh VirtualBox installation upgraded to testing without 
extra repositories and the tab also crashes there, so the issue is definetly in 
Debian.

Is there a way to triangulate the offending library?

The webpage is quite simple, there are no videos embedded, nothing 
extraordinary.
I have replicated this bug on three different machines (with nvidia, i915 and 
virtualbox).

Best regards,
Marius

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

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

Versions of packages chromium depends on:
ii  chromium-common  69.0.3497.12-1
ii  libasound2   1.1.6-1
ii  libatk-bridge2.0-0   2.26.2-1
ii  libatk1.0-0  2.28.1-1
ii  libatomic1   8.2.0-4
ii  libavcodec58 7:4.0.2-1+b1
ii  libavformat587:4.0.2-1+b1
ii  libavutil56  7:4.0.2-1+b1
ii  libc62.27-5
ii  libcairo-gobject21.15.12-1
ii  libcairo21.15.12-1
ii  libcups2 2.2.8-5
ii  libdbus-1-3  1.12.10-1
ii  libdrm2  2.4.93-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.2.0-4
ii  libgdk-pixbuf2.0-0   2.36.12-2
ii  libglib2.0-0 2.56.1-2
ii  libgtk-3-0   3.22.30-2
ii  libharfbuzz0b1.8.8-2
ii  libicu60 60.2-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.19-3
ii  libnss3  2:3.38-1
ii  libopenjp2-7 2.3.0-1
ii  libopus0 1.3~beta+20180518-1
ii  libpango-1.0-0   1.42.4-1
ii  libpangocairo-1.0-0  1.42.4-1
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.34-2
ii  libpulse012.0-1
ii  libre2-4 20180701+dfsg-1
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.2.0-4
ii  libvpx5  1.7.0-3
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.6-1
ii  libx11-xcb1  2:1.6.6-1
ii  libxcb1  1.13-3
ii  libxcomposite1   1: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  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2
ii  libxss1  1:1.2.2-1+b2
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

chromium recommends no packages.

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

-- no debconf information

Bug#907881: quantum-espresso-data: missing Breaks+Replaces: quantum-espresso (<< 6.3)

[Andreas Beckmann]

Package: quantum-espresso-data
Version: 6.3-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../quantum-espresso-data_6.3-2_all.deb ...
  Unpacking quantum-espresso-data (6.3-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/quantum-espresso-data_6.3-2_all.deb (--unpack):
   trying to overwrite '/usr/share/doc-base/quantum-espresso', which is also in 
package quantum-espresso 6.0-3.1+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/quantum-espresso-data_6.3-2_all.deb


cheers,

Andreas


quantum-espresso=6.0-3.1+b1_quantum-espresso-data=6.3-2.log.gz
Description: application/gzip

Bug#907301: plasma-desktop: no system tray whith task bar and no context menu of desktop

[Bernhard Übelacker]

Hello,
with the migration yesterday of package plasma-framework 5.49.0-1
into testing this issue should be resolved.
(And also #907416 and #907696)

Kind regards,
Bernhard

Bug#829570: webrtc-audio-processing 0.3 is unbuildable on non-linux archs

[Felipe Sateler]

On Fri, Aug 24, 2018 at 8:56 PM Svante Signell 
wrote:

> On Sun, 2016-07-03 at 13:00 -0300, Felipe Sateler wrote:
> > Dear Hurd and BSD porters,
> >
> > The latest upload of webrtc-audio-processing in unstable does not
> > build on non-linux archs. This new version is required by pulseaudio
> > 9, so it will not build as well.
> >
> > My guess is that the build failures are only due to lack of
> > appropriate checks in configure (ie, not any real incompatibility).
> > If the porters could prepare such a patch, I'm more than happy to
> > apply locally and forward upstream. I currently lack time to try to
> > do this myself.
>
> There is a patch for that package available already:
> See #829570 from 04 Jul 2016.
>

I already commented on that patch with some review comments, which have not
been responded to.

BTW, forwarding upstream is now easier, with upstream using gitlab just
like debian:
https://gitlab.freedesktop.org/pulseaudio/webrtc-audio-processing

I look forward to cherry-picking the patch from upstream. It will probably
be faster if you can do the MR upstream, should any iteration be necesary.

-- 

Saludos,
Felipe Sateler

Bug#906921: tango-starter does not start after a reboot

[PICCA Frederic-Emmanuel]

Hello Carlos,

> Dear Maintainer,

> We saw that in some machines the tango-starter did not start after
> rebooting the PC.

> Note: We are using a custom version of the tango package  (
> 9.2.5a+dfsg1-2+patch1~bpo9+0~alba+1)

is this patch interesting for others ?

> # Should-Start:  tango-db network
> # Should-Stop:   tango-db network

> Could you add this fix in the init script of the official package? If
> you prefer I can do a PR in salsa.d.o

Yes it would be great :)), and then prepare a new debian revision for upload :)

cheers

Sorry for the delay, I was on holydays.

Bug#907880: libomp5-8: missing Breaks+Replaces: libomp5-7

[Andreas Beckmann]

Package: libomp5-8
Version: 1:8~svn340819-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libomp5-8_1%3a8~svn340819-1_amd64.deb ...
  Unpacking libomp5-8:amd64 (1:8~svn340819-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libomp5-8_1%3a8~svn340819-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libomp.so.5', which is also 
in package libomp5-7:amd64 1:7~+rc2-1~exp2
  Errors were encountered while processing:
   /var/cache/apt/archives/libomp5-8_1%3a8~svn340819-1_amd64.deb


cheers,

Andreas


libomp5-7=1%7~+rc2-1~exp2_libomp5-8=1%8~svn340819-1.log.gz
Description: application/gzip

Bug#907863: libeclipse-osgi-java, libequinox-osgi-java: error when trying to install together

[Markus Koschany]

Hi,

Am 03.09.2018 um 14:04 schrieb Emmanuel Bourg:
> Control: reassign -1 libeclipse-osgi-java
> Control: affects -1 libequinox-osgi-java
> 
> libeclipse-osgi-java will replace libequinox-osgi-java. I forgot to add
> the proper Breaks/Replaces fields.

I think this could have been better communicated. I was the one who
split libequinox-osgi-java off from Eclipse. Why can't we just use the
existing package and update it accordingly? In any case giving a reason
for a package takeover by another package even for team-maintained
packages seems appropriate to me. A bug report would have been ideal for
this sort of discussion.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#904895: Bug#783096: fixed in ieee-data 20150531.1

[Michael]

PS: "switched to https-only" is only partly true. It depends on the 
domain.


http://standards-oui.ieee.org/oui/oui.txt -> works
http://standards.ieee.org/regauth/oui/oui.txt -> forwards to https
https://standards.ieee.org/regauth/oui/oui.txt -> fails because of no 
intermediate


##

$ wget http://standards.ieee.org/regauth/oui/oui.txt
--2018-09-03 14:15:24--  http://standards.ieee.org/regauth/oui/oui.txt
Resolving standards.ieee.org (standards.ieee.org)... 34.237.206.211
Connecting to standards.ieee.org 
(standards.ieee.org)|34.237.206.211|:80... connected.

HTTP request sent, awaiting response... 302 Found
Location: https://standards.ieee.org/regauth/oui/oui.txt [following]
--2018-09-03 14:15:25--  https://standards.ieee.org/regauth/oui/oui.txt
Connecting to standards.ieee.org 
(standards.ieee.org)|34.237.206.211|:443... connected.

ERROR: The certificate of ‘standards.ieee.org’ is not trusted.
ERROR: The certificate of ‘standards.ieee.org’ hasn't got a known 
issuer.


##

$ wget http://standards-oui.ieee.org/oui/oui.txt
--2018-09-03 14:15:34--  http://standards-oui.ieee.org/oui/oui.txt
Resolving standards-oui.ieee.org (standards-oui.ieee.org)... 
140.98.223.27
Connecting to standards-oui.ieee.org 
(standards-oui.ieee.org)|140.98.223.27|:80... connected.

HTTP request sent, awaiting response... 200 OK
Length: 3978006 (3.8M) [text/plain]
Saving to: ‘oui.txt’

oui.txt100%[>]   
3.79M   470KB/s   in 8.5s


2018-09-03 14:15:43 (459 KB/s) - ‘oui.txt’ saved [3978006/3978006]

Bug#907879: ITP: sentinelsat -- Utility to search and download Copernicus Sentinel satellite images

[Simon Spöhel]

Package: wnpp

* Package name: sentinelsat
  Upstream url: https://pypi.org/project/sentinelsat
* License : GPL-3.0
  Description : search and download Copernicus Sentinel satellite 
images


  Sentinelsat makes searching, downloading and retrieving the metadata
  of Sentinel satellite images from the Copernicus Open Access Hub easy.
  .
  It offers an easy-to-use command line interface

Greetings,
Simon

Bug#907829: p4est: FTBFS on single CPU machines (?)

[Santiago Vila]

On Mon, Sep 03, 2018 at 09:23:54AM +0200, Graham Inggs wrote:
> Hi Santiago
> 
> On 2 September 2018 at 19:21, Santiago Vila  wrote:
> > My guess is that this is a bug in p4est but it's triggered by a build 
> > depends
> > which changed behaviour somewhere between 2017-12-24 (where version 1.1-5
> > still built ok for me in buster) and 2018-06-03 (where it did not anymore).
> 
> Yes, openmpi flipped the default for oversubscription *again*, see #849974.
> 
> Would you please check whether the following change to debian/rules
> fixes it for you?
> 
> --- a/debian/rules
> +++ b/debian/rules
> @@ -3,6 +3,7 @@
>  include /usr/share/dpkg/pkg-info.mk
> 
>  export OMPI_MCA_plm_rsh_agent=/bin/false
> +export OMPI_MCA_rmaps_base_oversubscribe=1
> 
>  %:
>  dh $@
> 

Yes, it fixes it.

Thanks a lot.

Bug#907877: aegisub: installation libboost-regex1.62.0+dfsg-8 require to delete aegisub packet

[Сергей Фёдоров]

To: sub...@bugs.debian.org
Subject: aegisub: installation libboost-regex1.62.0+dfsg-8 require to delete 
aegisub packet
Package: aegisub
Version: 3.2.2+dfsg-3+b6
Severity: important
Tags: a11y

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

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

Versions of packages aegisub depends on:
ii  libasound2 1.1.6-1
ii  libass9    1:0.14.0-2
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4
ii  libboost-locale1.62.0  1.62.0+dfsg-4
ii  libboost-regex1.62.0   1.62.0+dfsg-4
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libboost-thread1.62.0  1.62.0+dfsg-4
ii  libc6  2.27-5
ii  libffms2-4 2.23-3+b1
ii  libfftw3-double3   3.3.8-1
ii  libfontconfig1 2.13.0-5
ii  libgcc1    1:8.2.0-4
ii  libgl1 1.1.0-1
ii  libgl1-mesa-glx    18.1.7-1
ii  libhunspell-1.6-0  1.6.2-1+b1
ii  libicu57   57.1-9
ii  libluajit-5.1-2    2.1.0~beta3+dfsg-5.1
ii  libpulse0  12.0-1
ii  libstdc++6 8.2.0-4
ii  libwxbase3.0-0v5   3.0.4+dfsg-4
ii  libwxgtk3.0-0v5    3.0.4+dfsg-4
ii  zlib1g 1:1.2.11.dfsg-1

aegisub recommends no packages.

Versions of packages aegisub suggests:
pn  aegisub-l10n  

-- no debconf information

Bug#907878: xrdp: gnome session asks permission for colord

[Jimmy Stretch]

Package: xrdp
Version: 0.9.1-9+deb9u3
Severity: minor

Hallo,

using xrdp en xorg as protocols, starting default debian gnome as an enviroment;
an popup is shown after login, asking for a pasword (to access the color 
scheme..)

* ignoring this popup each time you login works: hence a minor bug
* or solving this issue by adding a policy for it:

sudo bash -c "cat 
>/etc/polkit-1/localauthority/50-local.d/45-allow.colord.pkla" anybody)

hth,
Wim

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

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

Versions of packages xrdp depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u3
ii  libfuse2 2.9.7-1+deb9u1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libopus0 1.2~alpha2-1
ii  libpam0g 1.1.8-3.6
ii  libssl1.11.1.0f-3+deb9u2
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  libxrandr2   2:1.5.1-1
ii  lsb-base 9.20161125
ii  ssl-cert 1.0.39

Versions of packages xrdp recommends:
ii  fuse  2.9.7-1+deb9u1
ii  xorgxrdp  0.9.1-9+deb9u3

Versions of packages xrdp suggests:
pn  guacamole  

Versions of packages xorgxrdp depends on:
ii  libc6  2.24-11+deb9u3
pn  xorg-input-abi-24  
ii  xserver-xorg-core [xorg-video-abi-23]  2:1.19.2-1+deb9u2

Versions of packages xorgxrdp recommends:
ii  xorg  1:7.7+19

Versions of packages xrdp is related to:
pn  vnc-server   
pn  xserver-xorg-legacy  

-- Configuration Files:
/etc/xrdp/xrdp.ini changed:
[Globals]
; xrdp.ini file version number
ini_version=1
; fork a new process for each incoming connection
fork=true
; tcp port to listen
port=3389
; regulate if the listening socket use socket option tcp_nodelay
; no buffering will be performed in the TCP stack
tcp_nodelay=true
; regulate if the listening socket use socket option keepalive
; if the network connection disappear without close messages the connection 
will be closed
tcp_keepalive=true
; security layer can be 'tls', 'rdp' or 'negotiate'
; for client compatible layer
security_layer=negotiate
; minimum security level allowed for client
; can be 'none', 'low', 'medium', 'high', 'fips'
crypt_level=high
; X.509 certificate and private key
; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 
365
certificate=
key_file=
; specify whether SSLv3 should be disabled
; set TLS cipher suites
; Section name to use for automatic login if the client sends username
; and password. If empty, the domain name sent by the client is used.
; If empty and no domain name is given, the first suitable section in
; this file will be used.
autorun=
allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
max_bpp=32
new_cursors=true
; fastpath - can be 'input', 'output', 'both', 'none'
use_fastpath=both
; when true, userid/password *must* be passed on cmd line
; You can set the PAM error text in a gateway setup (MAX 256 chars)
;
; colors used by windows in RGB format
;
blue=009cb5
grey=dedede
;
; configure login screen
;
; Login Screen Window Title
; top level window background color in RGB format
ls_top_window_bg_color=009cb5
; width and height of login screen
ls_width=350
ls_height=430
; login screen background color in RGB format
ls_bg_color=dedede
; optional background image filename (bmp format).
; logo
; full path to bmp-file or file in shared folder
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50
; for positioning labels such as username, password etc
ls_label_x_pos=30
ls_label_width=60
; for positioning text and combo boxes next to above labels
ls_input_x_pos=110
ls_input_width=210
; y pos for first label and combo box
ls_input_y_pos=220
; OK button
ls_btn_ok_x_pos=142
ls_btn_ok_y_pos=370
ls_btn_ok_width=85
ls_btn_ok_height=30
; Cancel button
ls_btn_cancel_x_pos=237
ls_btn_cancel_y_pos=370
ls_btn_cancel_width=85
ls_btn_cancel_height=30
[Logging]
LogFile=xrdp.log
LogLevel=DEBUG
EnableSyslog=true
SyslogLevel=DEBUG
; LogLevel and SysLogLevel could by any of: core, error, warning, info or debug
[Channels]
; Channel names not listed here will be blocked by XRDP.
; You can block any channel by setting its value to false.
; IMPORTANT! All channels are not supported in all use
; cases even if you set all values to true.
; You can override these settings on each session type
; These settings are only used if 

Bug#907876: aegisub: installation libboost-regex1.62.0+dfsg-8 require to delete aegisub packet

[Сергей Фёдоров]

To: sub...@bugs.debian.org
Subject: aegisub: installation libboost-regex1.62.0+dfsg-8 require to delete 
aegisub packet
Package: aegisub
Version: 3.2.2+dfsg-3+b6
Severity: important
Tags: a11y

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

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

Versions of packages aegisub depends on:
ii  libasound2 1.1.6-1
ii  libass91:0.14.0-2
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4
ii  libboost-locale1.62.0  1.62.0+dfsg-4
ii  libboost-regex1.62.0   1.62.0+dfsg-4
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libboost-thread1.62.0  1.62.0+dfsg-4
ii  libc6  2.27-5
ii  libffms2-4 2.23-3+b1
ii  libfftw3-double3   3.3.8-1
ii  libfontconfig1 2.13.0-5
ii  libgcc11:8.2.0-4
ii  libgl1 1.1.0-1
ii  libgl1-mesa-glx18.1.7-1
ii  libhunspell-1.6-0  1.6.2-1+b1
ii  libicu57   57.1-9
ii  libluajit-5.1-22.1.0~beta3+dfsg-5.1
ii  libpulse0  12.0-1
ii  libstdc++6 8.2.0-4
ii  libwxbase3.0-0v5   3.0.4+dfsg-4
ii  libwxgtk3.0-0v53.0.4+dfsg-4
ii  zlib1g 1:1.2.11.dfsg-1

aegisub recommends no packages.

Versions of packages aegisub suggests:
pn  aegisub-l10n  

-- no debconf information

Bug#907875: virtuoso-opensource-7-{bin,common}: missing Breaks+Replaces: virtuoso-opensource-6.1-{bin,common}

[Andreas Beckmann]

Package: virtuoso-opensource-7-bin,virtuoso-opensource-7-common
Version: 7.2.5.1+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../virtuoso-opensource-7-bin_7.2.5.1+dfsg-1_amd64.deb ...
  Unpacking virtuoso-opensource-7-bin (7.2.5.1+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/virtuoso-opensource-7-bin_7.2.5.1+dfsg-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/bin/isql-vt', which is also in package 
virtuoso-opensource-6.1-bin 6.1.6+dfsg2-4+b2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/virtuoso-opensource-7-bin_7.2.5.1+dfsg-1_amd64.deb

  Preparing to unpack .../virtuoso-opensource-7-common_7.2.5.1+dfsg-1_amd64.deb 
...
  Unpacking virtuoso-opensource-7-common (7.2.5.1+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/virtuoso-opensource-7-common_7.2.5.1+dfsg-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/bin/inifile', which is also in package 
virtuoso-opensource-6.1-common 6.1.6+dfsg2-4+b2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/virtuoso-opensource-7-common_7.2.5.1+dfsg-1_amd64.deb


cheers,

Andreas


virtuoso-opensource-6.1-bin=6.1.6+dfsg2-4+b2_virtuoso-opensource-7-bin=7.2.5.1+dfsg-1.log.gz
Description: application/gzip

Bug#907874: trans-de-en: 2x transposed letters: "Pirmarschule" instead of "Primarschule"

[Axel Beckert]

Package: trans-de-en
Version: 1.8.1-1
Severity: normal
Tags: upstream
Control: found -1 1.8.1-4

Hi Roland,

the following entry contains 2x transposed letters in the words
"Primarschule" and "Primarschulen":

Grundschule {f} [Dt.] [Südtirol]; Klippschule {f} [Nordostdt.]; Elementarschule 
{f} [hist.]; Volksschule {f} [Ös.]; Pirmarschule {f} [Schw.]; Primärschule {f} 
[Lux.] [school] | Grundschulen {pl}; Klippschulen {pl}; Elementarschulen {pl}; 
Volksschulen {pl}; Pirmarschulen {pl}; Primärschulen {pl} :: primary school 
[Br.]; elementary school [Am.]; grammar school [Am.]; grade school [Am.] | 
primary schools; elementary schools; grammar schools; grade schools

Please replace "Pirmarschule" and "Pirmarschulen" with "Primarschule"
and "Primarschulen".

This seems to be an upstream issue since
https://dict.tu-chemnitz.de/dings.cgi?service=deen=0=0=primary+schools=
also shows these transposed characters.

P.S.: http://dict.tu-chemnitz.de/ redirects to
https://dict.tu-chemnitz.de/, so maybe the upstream URL in the long
package description should be updated to HTTPS, too. (Maybe it even
makes even sense to give the binary package trans-de-en its own distinct
Homepage header and to move the URL from the package description there.)

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

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

trans-de-en depends on no packages.

trans-de-en recommends no packages.

Versions of packages trans-de-en suggests:
ii  ding  1.8.1-1

-- no debconf information

Bug#907863: libeclipse-osgi-java, libequinox-osgi-java: error when trying to install together

[Emmanuel Bourg]

Control: reassign -1 libeclipse-osgi-java
Control: affects -1 libequinox-osgi-java

libeclipse-osgi-java will replace libequinox-osgi-java. I forgot to add
the proper Breaks/Replaces fields.

Bug#907873: python3-jaraco.itertools,python-jaraco.itertools: ships /usr/lib/python*/dist-packages/.pytest_cache/v/cache/nodeids

[Andreas Beckmann]

Package: python3-jaraco.itertools,python-jaraco.itertools
Version: 2.0.1-2
Severity: serious

Hi,

I'm just investigating file collisions of your packages with other
packages on the paths

  /usr/lib/python2.7/dist-packages/.pytest_cache/v/cache/nodeids
  /usr/lib/python3/dist-packages/.pytest_cache/v/cache/nodeids

which don't look like they should be shipped at all.


Andreas


python3-alembic=1.0.0-1_python3-jaraco.itertools=2.0.1-2.gz
Description: application/gzip

Bug#907871: python3-alembic,python-alembic: ships /usr/lib/python*/dist-packages/.pytest_cache/v/cache/nodeids

[Andreas Beckmann]

Package: python3-alembic,python-alembic
Version: 1.0.0-1
Severity: serious

Hi,

I'm just investigating file collisions of your packages with other
packages on the paths

  /usr/lib/python2.7/dist-packages/.pytest_cache/v/cache/nodeids
  /usr/lib/python3/dist-packages/.pytest_cache/v/cache/nodeids

which don't look like they should be shipped at all.


Andreas

Bug#907870: lintian: warn on packages shipping /usr/lib/python*/dist-packages/.pytest_cache/*

[Andreas Beckmann]

Package: lintian
Version: 2.5.99
Severity: normal

Hi,

I just found a collision on python{,3}-alembic and python{,3}-jaraco.itertools
which both ship

  /usr/lib/python*/dist-packages/.pytest_cache/v/cache/nodeids

>From the path I conclude that this file shouldn't be shipped in any package.


Andreas

Bug#907869: ITP: python-geomet -- convert GeoJSON to WKT/WKB, and vice versa

[Simon Spöhel]

Package: wnpp

* Package name  : python-geomet
  Upstream url  : https://pypi.org/project/geomet/
* License   : Apache-v2.0
  Description   : Convert GeoJSON to WKT/WKB, and vice versa

  Convert GeoJSON to WKT/WKB (Well-Known Text/Binary), and vice versa.

Greetings
Simon

Bug#895599: The fix is incomplete

[Apollon Oikonomopoulos]

Unfortunately the fix for this bug is incomplete, as reported on the 
ganeti mailing list[1]. It looks like I forgot to cherry-pick upstream 
commit 5f90a0f64bf5fee7fe353a95d02c79736a5943c5[2].


[1] https://groups.google.com/forum/#!topic/ganeti/0jh6xxI3bM4
[2] 
https://github.com/ganeti/ganeti/commit/5f90a0f64bf5fee7fe353a95d02c79736a5943c5

Bug#907867: nmu: aces3_3.0.8-5.1

[Alastair McKinstry]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu aces3_3.0.8-5.1 . ANY . unstable . -m "Build against openmpi 3.1.2"

aces3 builds hung due to a bug in openmpi/pmix which led to thread locking.
This was fixed with #904825, and test builds with later (current openmpi 3.1.2) 
work.
Please recompile aces3.

Thanks
Alastair

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

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

Bug#907865: stretch-pu: package python-imaplib2/2.55-1+deb9u1

[Ilias Tsitsimpis]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

The Python 3 version of imaplib2 (python3-imaplib2 package) is currently
unusable in stretch, as it is affected by #902755 and #899102.


#902755: Python 3 version broken, throws exception immediately after connecting

Upstream ships two different versions of imaplib2, one for Python 2 and
one for Python 3. The problem is that the python3-imaplib2 package ships
the Python 2 version. This has been fixed by having debian/rules install
the correct Python module.


#899102: python3-imaplib2: connection to IMAP-SSL host fails on armhf

The Python 3 version of imaplib2 fails on 32-bit architectures, because
the TIMEOUT_MAX value used in Condition.wait() overflows, causing the
above function to return immediately. This has been reported upstream as
  https://github.com/imaplib2/imaplib2/issues/2
  https://github.com/imaplib2/imaplib2/issues/3
and fixed by removing the timeout and having Condition.wait() block
indefinitely (patch submitted at https://github.com/imaplib2/imaplib2/pull/4).


Both of these bugs have been fixed in unstable/testing. I would like to
update python-imaplib2 in stretch to fix the above bugs. Attached is the
proposed diff.

Thanks,

-- 
Ilias
diff -Nru python-imaplib2-2.55/debian/changelog 
python-imaplib2-2.55/debian/changelog
--- python-imaplib2-2.55/debian/changelog   2017-07-12 11:37:15.0 
+0300
+++ python-imaplib2-2.55/debian/changelog   2018-09-03 11:44:48.0 
+0300
@@ -1,3 +1,15 @@
+python-imaplib2 (2.55-1+deb9u2) stretch; urgency=medium
+
+  * Install the correct module for Python 3.
+Until now, python3-imaplib2 installed the Python 2 version of this module.
+Thanks to Faidon Liambotis for reporting this (Closes: 902755)
+  * Apply patch to remove TIMEOUT_MAX variable.
+On some architectures, using threading.TIMEOUT_MAX for the timeout
+parameter can overflow causing Condition.wait() to return immediately.
+Thanks to Maximilian Stein for reporting this (Closes: #899102)
+
+ -- Ilias Tsitsimpis   Mon, 03 Sep 2018 11:44:48 +0300
+
 python-imaplib2 (2.55-1+deb9u1) stretch; urgency=medium
 
   * Fix typo that resulted in missing dependencies for python3-imaplib2.
diff -Nru python-imaplib2-2.55/debian/patches/Do-not-use-TIMEOUT_MAX.patch 
python-imaplib2-2.55/debian/patches/Do-not-use-TIMEOUT_MAX.patch
--- python-imaplib2-2.55/debian/patches/Do-not-use-TIMEOUT_MAX.patch
1970-01-01 02:00:00.0 +0200
+++ python-imaplib2-2.55/debian/patches/Do-not-use-TIMEOUT_MAX.patch
2018-09-02 18:08:03.0 +0300
@@ -0,0 +1,68 @@
+From: Ilias Tsitsimpis 
+Date: Sat, 25 Aug 2018 09:43:41 +0300
+Subject: Do not use TIMEOUT_MAX
+
+On some architectures, using threading.TIMEOUT_MAX for the timeout
+parameter can overflow causing Condition.wait() to return immediately.
+Instead of relying on TIMEOUT_MAX, remove it and wait forever.
+
+Bug-Debian: https://bugs.debian.org/899102
+Bug: https://github.com/imaplib2/imaplib2/issues/3
+Forwarded: https://github.com/imaplib2/imaplib2/pull/4
+---
+ imaplib2.py  | 5 ++---
+ imaplib2.py3 | 4 ++--
+ 2 files changed, 4 insertions(+), 5 deletions(-)
+
+diff --git a/imaplib2.py b/imaplib2.py
+index 1fd47d2..3a8b6c0 100755
+--- a/imaplib2.py
 b/imaplib2.py
+@@ -67,7 +67,6 @@ if bytes != str:
+ else:
+ import Queue as queue
+ string_types = basestring
+-threading.TIMEOUT_MAX = 9223372036854.0
+ 
+ select_module = select
+ 
+@@ -192,7 +191,7 @@ class Request(object):
+ def get_response(self, exc_fmt=None):
+ self.callback = None
+ if __debug__: self.parent._log(3, '%s:%s.ready.wait' % (self.name, 
self.tag))
+-self.ready.wait(threading.TIMEOUT_MAX)
++self.ready.wait()
+ 
+ if self.aborted is not None:
+ typ, val = self.aborted
+@@ -1391,7 +1390,7 @@ class IMAP4(object):
+ self.commands_lock.release()
+ if need_event:
+ if __debug__: self._log(3, 'sync command %s waiting for empty 
commands Q' % name)
+-self.state_change_free.wait(threading.TIMEOUT_MAX)
++self.state_change_free.wait()
+ if __debug__: self._log(3, 'sync command %s proceeding' % 
name)
+ 
+ if self.state not in Commands[name][CMD_VAL_STATES]:
+diff --git a/imaplib2.py3 b/imaplib2.py3
+index 0aeff4d..e02f094 100755
+--- a/imaplib2.py3
 b/imaplib2.py3
+@@ -182,7 +182,7 @@ class Request(object):
+ def get_response(self, exc_fmt=None):
+ self.callback = None
+ if __debug__: self.parent._log(3, '%s:%s.ready.wait' % (self.name, 
self.tag))
+-self.ready.wait(threading.TIMEOUT_MAX)
++self.ready.wait()
+ 
+ if self.aborted is not None:
+ typ, val = self.aborted
+@@ -1316,7 +1316,7 @@ class IMAP4(object):
+ self.commands_lock.release()
+ if need_event:
+ if 

Bug#907866: nasm: CVE-2018-16382

[Salvatore Bonaccorso]

Source: nasm
Version: 2.13.03-2
Severity: important
Tags: security upstream
Forwarded: https://bugzilla.nasm.us/show_bug.cgi?id=3392503

Hi,

The following vulnerability was published for nasm.

CVE-2018-16382[0]:
| Netwide Assembler (NASM) 2.14rc15 has a buffer over-read in
| x86/regflags.c.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-16382
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16382
[1] https://bugzilla.nasm.us/show_bug.cgi?id=3392503

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#907864: ITP: aareguru -- access temperature of the river Aare in Bern

[Simon Spöhel]

Package: wnpp

* Package name: aareguru
  Upstream Author : Claude Gex 
* License : GPLv3
  Description : access temperature of the river Aare in Bern

  Display information from aare.guru about the temperature of the
  river Aare and local weather information for Bern, Switzerland.

Greetings,
Simon

Bug#907863: libeclipse-osgi-java,libequinox-osgi-java: error when trying to install together

[Andreas Beckmann]

Package: libeclipse-osgi-java,libequinox-osgi-java
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite
Control: found -1 3.12.100+eclipse4.7.3-1
Control: found -1 3.9.1-1

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Selecting previously unselected package libequinox-osgi-java.
  Preparing to unpack .../libequinox-osgi-java_3.9.1-1_all.deb ...
  Unpacking libequinox-osgi-java (3.9.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libequinox-osgi-java_3.9.1-1_all.deb (--unpack):
   trying to overwrite 
'/usr/share/maven-repo/org/eclipse/osgi/org.eclipse.osgi/debian/org.eclipse.osgi-debian.pom',
 which is also in package libeclipse-osgi-java 3.12.100+eclipse4.7.3-1
  Errors were encountered while processing:
   /var/cache/apt/archives/libequinox-osgi-java_3.9.1-1_all.deb

This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  
usr/share/maven-repo/org/eclipse/osgi/org.eclipse.osgi/debian/org.eclipse.osgi-debian.jar
  
usr/share/maven-repo/org/eclipse/osgi/org.eclipse.osgi/debian/org.eclipse.osgi-debian.pom

This bug is assigned to both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may
also register in the BTS that the other package is affected by the bug.

Cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see https://qa.debian.org/dose/file-overwrites.html


libeclipse-osgi-java=3.12.100+eclipse4.7.3-1_libequinox-osgi-java=3.9.1-1.log.gz
Description: application/gzip

Bug#907798: fai - setup-storage unable to set GPT partition id

[Thomas Lange]

Are all cloud providers need this special partitioning scheme?

We may use gdisk (export mode, transpose) to fix the partition number
in FAI.

-- 
regards Thomas

Bug#570623: reprepro: please add multiple version management

[Benjamin Drung]

Hi everyone,

I rebased the patch set on top of the 5.2.0-1 release. Attached are all
71 patches as tarball. You can also pull the multiple-versions branch
from https://github.com/profitbricks/reprepro
Feel free to report bugs on GitHub.

Release Notes
=

Changes between 2017-04-12 and 2018-09-03:

* Rebased on 5.2.0
* Fix missing quotation mark in component list
* Fixed "Package database is not sorted!!!" by update command
  https://github.com/profitbricks/reprepro/issues/6
* Fixed screwing up database names by the database migration
  https://github.com/profitbricks/reprepro/issues/8
* Fix adding the same upstream tarball twice
  https://github.com/profitbricks/reprepro/issues/9
* Fix removesrc when multiple version are available

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL: https://www.profitbricks.de

Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens

multiple-versions-patches-5.2.0.tar.xz
Description: application/xz-compressed-tar

Bug#906189: linux-image-4.17.0-1-amd64: Laptop does not suspend in 4.17 - worked up to 4.16

[Christoph Haas]

I will try with bisect. Hass been a while that I compiled my kernel from
source. :)

I have not yet reported the problem to upstream mailing lists. Seems
though that the power optimizations added with kernel 4.17 would cause this.

Will report back.




signature.asc
Description: OpenPGP digital signature

Bug#907855: racket-mode: testsuite failure on arm64

[David Bremner]

Gianfranco Costamagna  writes:

> Source: racket-mode
> Severity: important
> Version: 20180731+0+g948c8aa-2
>
> Hello, since the last snapshot, testsuite has started to fail in Ubuntu (and 
> I presume in Debian too), but only on arm64...
>

I can't duplicate this in a debian sid arm64 porterbox.

The test in question looks like:

,
| Starting racket to run /home/bremner/racket-mode-20180731+0+g948c8aa/run.rkt 
...
| Still trying to connect to racket-command process on port 7 ...
| Still trying to connect to racket-command process on port 7 ...
| Connected to racket-command process on port 7 after 15 attempt(s)
| Closing existing connection to racket-command process ...
| Closing existing connection to racket-command process ...
| 
| 
|passed  3/5  racket-tests/repl
| 
`

there are related looking changes in upstream master, so a new snapshot
may help (or hurt).

Bug#907862: gtkpod segfaults on startup

[Peter Chubb]

Package: gtkpod
Version: 2.1.5-6
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

I installed gtkpod, ran gio mount afc://serialnumber then started
gtkpod.  ~/.gtkpod did not exist before I started.  The iPad is
mounted in /run/user/uid/gvfs/afc:serialnumber 

I get an immediate segmentation fault.

GDB shows:
(gdb) r
Starting program: /usr/bin/gtkpod 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe54a1700 (LWP 3285)]
[New Thread 0x7fffe4b5f700 (LWP 3286)]
[New Thread 0x7fffd700 (LWP 3287)]
[New Thread 0x7fffdf7fe700 (LWP 3288)]
[New Thread 0x7fffdedf0700 (LWP 3289)]

(gtkpod:3280): GLib-GObject-CRITICAL **: 20:14:43.209: 
g_value_type_transformable: assertion 'G_TYPE_IS_VALUE (src_type)' failed

(gtkpod:3280): Gtk-WARNING **: 20:14:43.209: 
../../../../gtk/gtkliststore.c:836: Unable to convert from (null) to gchararray

(gtkpod:3280): GLib-GObject-CRITICAL **: 20:14:43.290: 
g_value_type_transformable: assertion 'G_TYPE_IS_VALUE (src_type)' failed

(gtkpod:3280): Gtk-WARNING **: 20:14:43.290: 
../../../../gtk/gtkliststore.c:836: Unable to convert from (null) to gchararray
[New Thread 0x7fffcb57e700 (LWP 3290)]

Thread 1 "gtkpod" received signal SIGSEGV, Segmentation fault.
0x7652b57d in g_type_check_value_holds ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
(gdb) bt
#0  0x7652b57d in g_type_check_value_holds ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x75da5319 in  () at /usr/lib/x86_64-linux-gnu/libgpod.so.4
#2  0x75daa1f3 in itdb_parse ()
at /usr/lib/x86_64-linux-gnu/libgpod.so.4
#3  0x77d6268d in gp_import_itdb ()
at /usr/lib/x86_64-linux-gnu/libgtkpod.so.1
#4  0x77d63268 in gp_load_ipod ()
at /usr/lib/x86_64-linux-gnu/libgtkpod.so.1
#5  0x77d7b64f in  () at /usr/lib/x86_64-linux-gnu/libgtkpod.so.1
#6  0x76c790a0 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#7  0x7622bb73 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x7622b0f5 in g_main_context_dispatch ()
at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x7622b4c0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x7622b7d2 in g_main_loop_run ()
at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x77171e85 in gtk_main ()
at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0xc833 in main ()


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

Kernel: Linux 4.18.0-rc6+ (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gtkpod depends on:
ii  gtkpod-data 2.1.5-6
ii  libanjuta-3-0   2:3.28.0-3
ii  libatk1.0-0 2.28.1-1
ii  libatomicparsley0   2.1.5-6
ii  libc6   2.27-5
ii  libcairo-gobject2   1.15.12-1
ii  libcairo2   1.15.12-1
ii  libclutter-1.0-01.26.2+dfsg-4
ii  libclutter-gtk-1.0-01.8.4-3
ii  libcogl-pango20 1.22.2-3
ii  libcogl-path20  1.22.2-3
ii  libcogl20   1.22.2-3
ii  libcurl3-gnutls 7.61.0-1
ii  libdrm2 2.4.94-1
ii  libegl1-mesa18.1.7-1
ii  libflac81.3.2-3
ii  libgbm1 18.1.3-1
ii  libgdk-pixbuf2.0-0  2.36.12-2
ii  libgdl-3-5  3.28.0-1
ii  libglib2.0-02.56.1-2
ii  libgpod40.8.3-12
ii  libgstreamer-plugins-base1.0-0  1.14.2-dmo2
ii  libgstreamer1.0-0   1.14.2-2
ii  libgtk-3-0  3.22.30-1
ii  libgtkpod1  2.1.5-6
ii  libid3tag0  0.15.1b-13
ii  libimobiledevice6   1.2.1~git20180302.3a37a4e-1
ii  libjson-glib-1.0-0  1.4.2-4
ii  libpango-1.0-0  1.42.0-1
ii  libpangocairo-1.0-0 1.42.0-1
ii  libplist3   2.0.0-4
ii  libvorbisfile3  1.3.6-1
ii  libwayland-client0  1.14.0-2
ii  libwayland-cursor0  1.14.0-2
ii  libwayland-egl1 [libwayland-egl1-mesa]  1.15.0-2
ii  libwayland-egl1-mesa18.1.7-1
ii  libwayland-server0

Bug#907747: [Pkg-utopia-maintainers] Bug#907747: network-manager manages interface managed by /etc/network/interfaces

[Arian Sanusi]

to put my paint point first, maybe it was not clear: at boot NM does not 
connect at boot to a WiFi. Instead I have to click the applet, wait multiple 
seconds for a scan to finish and then have to choose the wifi manually. NM says 
it would be connected to my bridge, see attached screenshot.

> I still don't undestand: Are you saying that NM tries to manage your
> "bridge" interface while it shouldn't?
^ this, at least sort of: it behaves like the presence of the bridge is enough, 
while the bridge can't give me internet access. It doesn't change bridge's 
settings AFAICT
> Or are you expecting NM to manager your bridge interface but it does not?

> Anyway, if want to mark a device as unmanaged by NM, you have more
> explicit ways then relying on the eni parser.
> E.g. you could create a conf file like this:
> 
> # cat /etc/NetworkManager/conf.d/unmanaged.conf
> [keyfile]
> unmanaged-devices=interface-name:bridge
thanks for this suggestion, I'll try it! however I still think theres something 
unnecessarily annoying that should be fixed, especially when docu suggest that 
ENI was enough.


> I don't see anything in the logs which would indicate that NM manages
> your bridge interface, it simply shows, that such a device has been
> detected.

the lines from the log that read wrong to me:
 
>   adding bridge port none to eni_ifaces
none is a special value indicating an empty list that I guess the parser does 
not handle. If this was python it would be "bridge_ports = []"

>   devices added (path: /sys/devices/virtual/net/bridge, iface: bridge)
>   device added (path: /sys/devices/virtual/net/bridge, iface: bridge): 
> no ifupdown configuration found.
I can't find another explanation for this as that the eni parser is wrong

>   device (bridge): Activation: starting connection 'bridge' 
> (92896f34-0c23-4893-a459-7bf9f941f397)
if this is not saying that NM does something about the bridge, then it's 
misleading.


signature.asc
Description: OpenPGP digital signature

Bug#907810: [pkg-gnupg-maint] Bug#907810: gpg --no-verbose --verify is too verbose

[Vincent Lefevre]

On 2018-09-03 11:59:06 +0200, Werner Koch wrote:
> On Sun,  2 Sep 2018 15:18, vinc...@vinc17.net said:
> > outputs many [GNUPG:] debugging messages, partly hiding useful output.
> 
> These ain't no debugging messages but the required information for any
> program or script to interact with gpg.  You have requested them using
> the --status-fd option.

Yes, it is needed by Mutt.

> Which is the Right Thing to do. The human readable output is, well,
> for humans and not for machine consumption.

So, do you mean that it is a bug in Mutt, which doesn't filter them
out?

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

Bug#851860: [Android-tools-devel] Bug#851860: Intent to NMU google-android-installers to fix longstanding l10n bugs

[殷啟聰 | Kai-Chung Yan]

Hello Helge,

I am one of the devs at `android-tools` team although I don't maintain the 
contrib installer packages like this. AFAIK Mouaad is MIA after his work in 
GSoC 2016, but I can say he will be fine with the NMU and he is not preparing 
for a new release yet. Please go ahead with your other NMUs on the l10n as well.

Thank you for the contribution!



signature.asc
Description: OpenPGP digital signature

Bug#906608: pyconfigure: FTBFS in buster/sid (failing tests)

[Andreas Beckmann]

Followup-For: Bug #906608
Control: tag -1 sid buster

I can reproduce it in buster, but not in sid (nor stretch).

This is probably a duplicate of #906426 in automake-1.16.


Andreas

Bug#907810: [pkg-gnupg-maint] Bug#907810: gpg --no-verbose --verify is too verbose

[Werner Koch]

On Sun,  2 Sep 2018 15:18, vinc...@vinc17.net said:

> outputs many [GNUPG:] debugging messages, partly hiding useful output.

These ain't no debugging messages but the required information for any
program or script to interact with gpg.  You have requested them using
the --status-fd option.  Which is the Right Thing to do.  The human
readable output is, well, for humans and not for machine consumption.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpAsr4T6T_sU.pgp
Description: PGP signature

Bug#903703: emacs-goodies-el: should we keep rfcview.el in Debian?

[David Bremner]

Nicholas D Steeves  writes:

> Hello!
>
> So just to confirm:
>
> Dave Love is the upstream maintainer for rfcview and we still need a
> Debian maintainer for the elpafied package?  If so, we ought to
> reassign this bug to wnpp and make it an RFP or ITP.
>
> Cheers,
> Nicholas

Yes, probably an RFP at this point.

d

Bug#892717: If there is a MIME header: then no additional tags are needed

[أحمد المحمودي]

On Sat, Sep 01, 2018 at 11:50:17PM +0600, Власенко Михаил Викторович wrote:
> This should fix it. My patch for solving this problem I send as an 
> attachment. Can you test this and see if it works?
---end quoted text---

I don't understand the problem, but I see a similar diff in upstream 
git.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#901572: acccheck: CVE-2018-12268: Patch proposal

[Phil.]

Okay,

From what I've seen, the code is effectively just horrible !

Thanks for adding the affect tag, as I've haven't seen the removal request.

Cheers, 

Le 3 septembre 2018 11:07:08 GMT+02:00, Raphael Hertzog  a 
écrit :
>Control: affects 904200 acccheck
>
>On Mon, 03 Sep 2018, p...@reseau-libre.net wrote:
>> I've updated the acccheck.pl behavior to correct (i hope) the
>> CVE-2018-12268. User and password input files are sanitized before
>any use
>> in the generated commandline string. The patch is given attached to
>this
>> mail.
>
>FWIW, I requested the removal of the package a while ago:
>https://bugs.debian.org/904200
>
>And this is not the only security issue in that script... there's no
>point
>in spending any time on this issue.
>
>Cheers,
>-- 
>Raphaël Hertzog ◈ Debian Developer
>
>Support Debian LTS: https://www.freexian.com/services/debian-lts.html
>Learn to master Debian: https://debian-handbook.info/get/

-- 
O Philippe Thierry. 
/Y\/ GPG: 7010 9a3c e210 763e 6341 4581 c257 b91b cdaf c1ea
o#o 

Bug#907829: p4est: FTBFS on single CPU machines (?)

[Adrian Bunk]

On Mon, Sep 03, 2018 at 01:22:47AM +0200, Santiago Vila wrote:
>...
> This single-CPU thing has been discussed before and the bugs have
> never stopped being serious:
> 
> https://lists.debian.org/debian-devel/2017/02/msg00380.html
>...

Do you have a statement from a member of the release team saying so?

>...
> Ok, my autobuilder is not one of buildd.debian.org. So what? Packages
> *must* be buildable on any system where Debian itself runs (provided
> there is enough RAM and disk), i.e. on any autobuilder which is not
> misconfigured. Having a single CPU does not count as a "misconfiguration".

It is completely arbitrary if you want to define that requiring any
amount of RAM or disk usage is fine, but a similar requirement for 
the number of CPUs must not happen.

> Nothing else, like CPU speed, number of CPUs, instruction set above
> the baseline amd64, etc. should be assumed or taken for granted
> "just because buildd.debian.org is that way".
> 
> Otherwise the package will have a hidden and undeclared
> "build-depends: buildd.debian.org" (so to speak), and I would consider
> such build restriction completely unacceptable.
>
> No, we don't follow "de-facto standards", we just follow standards,
> and so far we have not formally declared single-cpu systems as "unsuitable
> for building" (by way of general resolution or by policy).
>...

What packages actually follow is "builds on the buildds".

We don't need a GR to formally declare that
- some packages don't build with only 1 CPU,
- some packages don't build with only 8 GB RAM
- some packages don't build with only 70 GB storage

>...
> And no, single-cpu is not exotic. You are only considering physical
> machines, but there is a whole world of virtualization out there where
> you can still choose the number of CPUs in the system, and single-cpu
> is still cheaper (and I guess it will still be for a long time).

Yes, but that usually also limits the amount of RAM
and you are fine with packages using any amount of that.

The machine you want to enable to build all packages would
have the following specs:
- 1 CPU
- 16 GB RAM
- 75 GB storage

This is an insane configuration.

Also notice that the "75 GB storage" is exactly the amount provisioned 
today on the amd64 buildds, there are packages that have workarounds for 
being able to build on the buildds with only 75 GB storage - and won't 
build with even less.

Don't get me wrong, a package not building on a machine with 1 CPU
is a bug that should be reported.

But trying to enforce to be able to build every single package in the 
archive on single-CPU machines is something that strikes me as a huge
waste of time - we have so many far more relevant bugs that should
be debugged and fixed before that.

> Thanks.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#907861: DAK/DM-Admin: Please add John Sullivan to DM Admin ACL

[Jonathan McDowell]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi.

John Sullivan has been added to the keyring-maint team as per:

https://lists.debian.org/debian-devel-announce/2018/08/msg7.html

Please can his key (A4626CBAFF376039D2D7554497BA9CE761A0963B) be added
to the Command::DM-Admin / AdminFingerprints list in dak.conf so he is
able to remove / change DM fingerprints in response to DM → DD
transitions and DM key migrations?

Thanks,
J.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEERUuPEyEc/2gMWDpQ/xYvxc8/utEFAluM+08ACgkQ/xYvxc8/
utGEtg//YVtIgyv1Kl0Ire3QpjXSuzuPzb1bYLz4MUI4lvn+w9U0QHzzcGqg3Bl4
zuF0ZQYiu4eEI0a4lPT31r31HNWVEfPzRI8JCsHh51CzeFrbvUpD97F9e6zhYbA/
bvBTkBletE9nOn/EkPdg+9zEONXacA7wYk0df3kCi4hsC6suqvc+YU/5yfTw9ZOa
ImL9m5KAK5dw46Bnpvi/HnJKxyX3toRi0vKXeceYFphsqpTml5NxiJWmRfSnDQkh
+5cae/STiGhSW169ibl6Y6iZHd+B5ay1que8IITDIcKlXO1D4uPK0Z6StavfPjtu
6BwSkegcBy+lvNgAewxWjR4B1AqH40Q71nzBwQa/sXqf/hiZZzeAkHq0+Ze5KWNd
7gGy74AfvxkzW4pOJBZKkAVZ7E12ggBNsk4tbpUhpZC2QQxn6k3cZfogYTeBG4q6
10jJEEKGkA9QxKtS1vmQsHYVOCMPt+hAsd0E40hUi8/YxbD5dKz/DXBdSWSedoMt
ACnCdxQIZEbkGFtYTH1jJ1PfAN/yyJhsojndp6Dx47ZoZqepFieRpF9Qw6OXnQDC
3/rPI2Lte+HpS6WAv/PZq5q0MvBGie2GOv50UESVbbGPaJLCZt5gZEw0kCdk0a+S
P/vybf17YNVc3XHQEYaPXTsUkD7IZl8VopN6Pjyr7xnaLWR44X8=
=5zH+
-END PGP SIGNATURE-

Bug#904895: Bug#783096: fixed in ieee-data 20150531.1

[Michael]

Hi,

like Luciano said, there's some issue with wget not able to fetch 
intermediate certs via TLS AIA url.


It's a general problem by that time also for stable and oldstable. The 
workaround with #783096 (using http) is non functional now because ieee 
has switched to https-only (forwarding http to https).


If you want to reproduce/verify the issue:

###

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux testing (buster)
Release:testing
Codename:   buster

$ sudo /usr/sbin/update-ieee-data
Updating /var/lib/ieee-data//oui.txt
Checking permissions on /var/lib/ieee-data//oui.txt
Downloading 
https://standards.ieee.org/develop/regauth/oui/oui.txt to 
/var/lib/ieee-data//oui.txt
wget -q -O- https://standards.ieee.org/develop/regauth/oui/oui.txt exit 
with 5


###

$ wget https://standards.ieee.org/develop/regauth/oui/oui.txt
--2018-09-03 11:12:19--  
https://standards.ieee.org/develop/regauth/oui/oui.txt

Resolving standards.ieee.org (standards.ieee.org)... 34.237.206.211
Connecting to standards.ieee.org 
(standards.ieee.org)|34.237.206.211|:443... connected.

ERROR: The certificate of ‘standards.ieee.org’ is not trusted.
ERROR: The certificate of ‘standards.ieee.org’ hasn't got a known 
issuer.


###

$ echo "" | openssl s_client -connect standards.ieee.org:443 -prexit 
2>/dev/null | sed -n -e '/BEGIN\ CERTIFICATE/,/END\ CERTIFICATE/ p' > 
standards.ieee.org.crt

$ openssl verify standards.ieee.org.crt
C = US, ST = New Jersey, L = Piscatwaway, O = IEEE, OU = IT-Systems 
Analysts, CN = *.ieee.org

error 20 at 0 depth lookup: unable to get local issuer certificate
error standards.ieee.org.crt: verification failed
$ wget http://aia.entrust.net/l1k-chain256.cer
$ openssl x509 -inform der -outform pem -in l1k-chain256.cer -out 
l1k-chain256.pem

$ openssl verify -untrusted l1k-chain256.pem standards.ieee.org.crt
standards.ieee.org.crt: OK

###

btw: IEEE violating standards by not submitting intermediate certs?

regards
hede

Bug#907662: python-tvrage: useless after TVRage.com shut down?

[Hans-Christoph Steiner]

yeah, I guess it should be removed.  Feel free to remove this, I won't
have to do it in the near future.



signature.asc
Description: OpenPGP digital signature

Bug#907032: has there been any thought of also having the rav1e encoder as well ?

[James Cowgill]

Hi,

On 03/09/2018 09:26, shirish शिरीष wrote:
> Hi all,
> 
> Have people looked at https://github.com/xiph/rav1e . One of the
> blockages though seems to be https://github.com/mbebenita/rustfmt
> which doesn't seem to be packaged in Debian at least in first glance.
> As shared this one is supposed to be a bit faster than the reference
> implementation for encoding though.

I had a brief look during Debconf at rav1e. At the time lots of
dependencies weren't packaged. I know things are improving quickly with
Rust in Debian so this may have changed. AFAIK upstream hasn't sorted
the public API out yet or even made a release which I think are both
requirements for packaging this in Debian.

James



signature.asc
Description: OpenPGP digital signature

Bug#906250: ITP: execline -- small and non-interactive scripting language

[Adam Borowski]

On Mon, Sep 03, 2018 at 10:17:09AM +0200, Jakub Wilk wrote:
> * Shengjing Zhu , 2018-09-02, 14:42:
> > When I try to package execline(a non-interactive shell script)[1], it
> > installs following binaries in default PATH,
> > 
> > cd, if, exec, wait, 
> 
> Three of them (cd, umask, wait) clash with shell's regular built-in
> utilities. [...] The execline's implementation are of course not compatible
> with POSIX, and therefore must not be included within PATH.

And with the Policy, too:

§10.1.
# Two different packages must not install programs with different
# functionality but with the same filenames.  (The case of two programs
# having the same functionality but different implementations is handled via
# “alternatives” or the “Conflicts” mechanism.

Regular "cd" changes the directory for the calling process (thus it even
can't possibly be a separate process), this "cd" takes two arguments and
runs a _child_ with the changed directory.

So having execline in $PATH conflicts not only with POSIX, common sense,
but even our Policy. :þ


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]

Bug#901572: acccheck: CVE-2018-12268: Patch proposal

[Raphael Hertzog]

Control: affects 904200 acccheck

On Mon, 03 Sep 2018, p...@reseau-libre.net wrote:
> I've updated the acccheck.pl behavior to correct (i hope) the
> CVE-2018-12268. User and password input files are sanitized before any use
> in the generated commandline string. The patch is given attached to this
> mail.

FWIW, I requested the removal of the package a while ago:
https://bugs.debian.org/904200

And this is not the only security issue in that script... there's no point
in spending any time on this issue.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#907860: ITP: appmenu-registrar -- Appmenu DBusMenu registrar

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: appmenu-registrar
  Version : 0.7.1
  Upstream Author : Konstantin Pugin 
* URL : https://gitlab.com/vala-panel-project/vala-panel-appmenu/
* License : LGPL-3.0+
  Programming Lang: C
  Description : Appmenu DBusMenu registrar

 This packages provides a standalone Appmenu registrar that allows other
 applications to access any active window's application menu tree.
 .
 Such a registrar is extremely useful for, e.g.
 .
   * implementing global menus (application menus appear in the top
 panel bar of the desktop environment) 
   * adding an application menu browser or search engine to HUDs
 .
 The registrar uses the protocol originally published with the Unity7
 desktop environment. It supports all features found in that
 implementation.
 .
 This package is a subproject of the vala-panel-appmenu project.
 .
 This package was previously shipped as bin:pkg
 vala-panel-appmenu-registrar.

Bug#741663: Fixed upstream

[Mathieu Malaterre]

Control: tags -1 fixed-upstream

Patch has been applied upstream, so marking as fixed-upstream (v4.19-rc1)

Bug#868806: Resolved upstream

[Christian Ehrhardt]

Hi,
I wanted to let you know that after a bit of a discussion this was resolved
upstream by adding back CAP_AUDIT_WRITE.

You can find more details on [1][2]

The TL;DR for Debian is to add CAP_AUDIT_WRITE (now with reasons why
:-) )

[1]: https://sourceforge.net/p/openvpn/mailman/message/36403133/
[2]:
https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/CAATJJ0K1v4eLLSwrpdnSgLV5LZkEAmVW3LfbRT3ssLW8Xb2bCw%40mail.gmail.com/#msg36406486

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#906250: ITP: execline -- small and non-interactive scripting language

[Shengjing Zhu]

On Mon, Sep 3, 2018 at 4:43 PM Shengjing Zhu  wrote:
> > Three of them (cd, umask, wait) clash with shell's regular built-in
> > utilities. POSIX requires them to be exec(2)able[0][1]. Debian doesn't
> > currently provide standalone executables for them (which is a bug), but
> > some other distros do. The execline's implementation are of course not
> > compatible with POSIX, and therefore must not be included within PATH.
> >
>
> Sorry, I can't get your point. Doesn't this mean execline _follows_
> POSIX, which makes cd/umask/wait execable?
>

Oh, you mean the behaviours of execline's cd/umask/wait are not
compatible with POSIX.

-- 
Shengjing Zhu 
GPG Key: 0xCF0E265B7DFBB2F2
Homepage: https://zhsj.me

Bug#887490: O: backuppc -- high-performance, enterprise-grade system for backing up PCs

[Axel Beckert]

Hi Raoul,

Raoul Bhatia wrote:
> I've tried to keep some up2date packages in my Github repositories,
> see
> https://github.com/backuppc/backuppc/wiki/Build-Your-Own-Packages ,
> specifically
> 
> * https://github.com/raoulbhatia/rsync-bpc/tree/3.0.9.12-DEBIAN
> * https://github.com/raoulbhatia/backuppc/tree/DEBIAN
> * https://github.com/raoulbhatia/backuppc-xs/tree/DEBIAN

Thanks for these!

> Would this help to get things back in shape?

I'm sure it will. I haven't looked at them, but since the hint to your
packages in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873075#35 my plan is
to look at them and try to do a Debian QA upload based on them.

I though don't have my Debian Testing based BackupPC server in shape
yet, so I can't test it currently.

Once I managed to do this, I intent to look into making a QA upload of
BackupPC to at least get it back in shape. Or maybe first a simple 3.x
upload to unstable to get a few things fixed and then upload 4.x to
experimental first. (JFTR: This should though not keep anyone from
doing this before I get to it! I do not claim this bug.)

It's though not my top priority at the moment, so I don't want make
any promises I may not be able to keep.

> Especially, I am no Debian expert and also have basic requirements
> for BackupPC only, so I will not be able to do this properly all by
> myself.

I'd join and help if anyone wants to form a BackupPC team in Debian.
I'm though not keen on taking the lead.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Mathieu Malaterre]

Hi Rick,

On Tue, Apr 12, 2016 at 12:08 PM Mathieu Malaterre  wrote:
>
> Dear all,
>
> I am looking for testers for the following patch:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741663#20
>
> Wolfram (CC here) is looking for feedback from users for this patch.

Wolfram is still looking for feedback from user on the patch applied
recently upstream:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/macintosh/therm_windtunnel.c?id=3e7bed52719de4b5b5fb900869e293eae0bc3f3e

Could you give it a try ?

Thanks

Bug#906250: ITP: execline -- small and non-interactive scripting language

[Shengjing Zhu]

On Mon, Sep 3, 2018 at 4:17 PM Jakub Wilk  wrote:
>
> * Shengjing Zhu , 2018-09-02, 14:42:
> >When I try to package execline(a non-interactive shell script)[1], it
> >installs following binaries in default PATH,
> >
> >cd, if, exec, wait, 
>
> Three of them (cd, umask, wait) clash with shell's regular built-in
> utilities. POSIX requires them to be exec(2)able[0][1]. Debian doesn't
> currently provide standalone executables for them (which is a bug), but
> some other distros do. The execline's implementation are of course not
> compatible with POSIX, and therefore must not be included within PATH.
>

Sorry, I can't get your point. Doesn't this mean execline _follows_
POSIX, which makes cd/umask/wait execable?

--
Shengjing Zhu 
GPG Key: 0xCF0E265B7DFBB2F2
Homepage: https://zhsj.me

Bug#907859: task btrfs-transacti:663 blocked for more than 120 seconds

[Russell Mosemann]

Package: linux-image-4.17.0-0.bpo.3-amd6
Severity: important

Dear Maintainer,

   * What led up to the situation?
 
Normal system operation, as far as I am aware, and then btrfs hung. The file 
system became inaccessible. See log lines below.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 
Had to reboot.

   * What was the outcome of this action?
 
The system was accessible, again.

   * What are the log entries?
 
Sep 03 00:08:02 vhost003 kernel: INFO: task btrfs-transacti:663 blocked for 
more than 120 seconds.
Sep 03 00:08:02 vhost003 kernel:   Tainted: G  I   
4.17.0-0.bpo.3-amd64 #1 Debian 4.17.17-1~bpo9+1
Sep 03 00:08:02 vhost003 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 03 00:08:02 vhost003 kernel: btrfs-transacti D0   663  2 0x8000
Sep 03 00:08:02 vhost003 kernel: Call Trace:
Sep 03 00:08:02 vhost003 kernel:  ? __schedule+0x3dc/0x860
Sep 03 00:08:02 vhost003 kernel:  schedule+0x32/0x80
Sep 03 00:08:02 vhost003 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Sep 03 00:08:02 vhost003 kernel:  ? remove_wait_queue+0x60/0x60
Sep 03 00:08:02 vhost003 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Sep 03 00:08:02 vhost003 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Sep 03 00:08:02 vhost003 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Sep 03 00:08:02 vhost003 kernel:  btrfs_commit_transaction+0xc8/0x8e0 [btrfs]
Sep 03 00:08:02 vhost003 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Sep 03 00:08:02 vhost003 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Sep 03 00:08:02 vhost003 kernel:  kthread+0xf8/0x130
Sep 03 00:08:02 vhost003 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Sep 03 00:08:02 vhost003 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Sep 03 00:08:02 vhost003 kernel:  ret_from_fork+0x35/0x40
Sep 03 00:08:02 vhost003 su[12343]: Successful su for nobody by root
Sep 03 00:08:02 vhost003 su[12343]: + ??? root:nobody
Sep 03 00:08:02 vhost003 su[12343]: pam_unix(su:session): session opened for 
user nobody by (uid=0)
Sep 03 00:08:02 vhost003 systemd[1]: Created slice User Slice of nobody.
Sep 03 00:08:03 vhost003 systemd[1]: Starting User Manager for UID 65534...
Sep 03 00:08:03 vhost003 systemd-logind[794]: New session c2 of user nobody.
Sep 03 00:08:03 vhost003 systemd[1]: Started Session c2 of user nobody.
Sep 03 00:08:03 vhost003 systemd[12344]: pam_unix(systemd-user:session): 
session opened for user nobody by (uid=0)
Sep 03 00:12:58 vhost003 kernel: INFO: task btrfs-transacti:663 blocked for 
more than 120 seconds.
Sep 03 00:12:59 vhost003 kernel:   Tainted: G  I   
4.17.0-0.bpo.3-amd64 #1 Debian 4.17.17-1~bpo9+1
Sep 03 00:12:59 vhost003 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 03 00:12:59 vhost003 kernel: btrfs-transacti D0   663  2 0x8000
Sep 03 00:12:59 vhost003 kernel: Call Trace:
Sep 03 00:12:59 vhost003 kernel:  ? __schedule+0x3dc/0x860
Sep 03 00:12:59 vhost003 kernel:  schedule+0x32/0x80
Sep 03 00:12:59 vhost003 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Sep 03 00:12:59 vhost003 kernel:  ? remove_wait_queue+0x60/0x60
Sep 03 00:12:59 vhost003 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Sep 03 00:12:59 vhost003 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Sep 03 00:12:59 vhost003 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Sep 03 00:12:59 vhost003 kernel:  btrfs_commit_transaction+0xc8/0x8e0 [btrfs]
Sep 03 00:12:59 vhost003 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Sep 03 00:12:59 vhost003 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Sep 03 00:12:59 vhost003 kernel:  kthread+0xf8/0x130
Sep 03 00:12:59 vhost003 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Sep 03 00:12:59 vhost003 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Sep 03 00:12:59 vhost003 kernel:  ret_from_fork+0x35/0x40
Sep 03 00:12:59 vhost003 systemd[1]: systemd-journald.service: Main process 
exited, code=killed, status=6/ABRT
Sep 03 00:12:59 vhost003 systemd[1]: systemd-journald.service: Unit entered 
failed state.
Sep 03 00:12:59 vhost003 systemd[1]: systemd-journald.service: Failed with 
result 'watchdog'.
Sep 03 00:12:59 vhost003 systemd[1]: systemd-journald.service: Service has no 
hold-off time, scheduling restart.
Sep 03 00:12:59 vhost003 systemd[1]: Stopped Flush Journal to Persistent 
Storage.
Sep 03 00:12:59 vhost003 systemd[1]: Stopping Flush Journal to Persistent 
Storage...
Sep 03 00:12:59 vhost003 systemd[1]: Stopped Journal Service.
Sep 03 00:12:59 vhost003 systemd[1]: Starting Journal Service...
Sep 03 00:12:59 vhost003 kernel: INFO: task btrfs-transacti:663 blocked for 
more than 120 seconds.
Sep 03 00:12:59 vhost003 kernel:   Tainted: G  I   
4.17.0-0.bpo.3-amd64 #1 Debian 4.17.17-1~bpo9+1
Sep 03 00:12:59 vhost003 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this 

Bug#907858: problem solved

[Josef Atmin]

Dear Maintainer,

I figured that there are two different places for changing the grid
line color.  I was looking in the default preferences and not in the
document specific preferences.  And I was not restarting a document
but opening a new one.  Thus, the behavior of inkscape is the correct
one.

Sorry for the inconvenience.

Best,

Josef.

Bug#907641: What's the URL?

[Guido Günther]

Hi,
On Sun, Sep 02, 2018 at 12:33:34PM +0200, Erik Brangs wrote:
> Hi,
> 
> the URL is missing in the original report. Is 
> https://source.puri.sm/Librem5/phosh the correct URL?

Yes, that's the correct one. Note that this is waiting for libhandy to
be accepted. The packaging is mostly there, main thing would be to
switch from 1.0 (native) to 3.0 (quilt).

Cheers,
 -- Guido

Bug#887490: O: backuppc -- high-performance, enterprise-grade system for backing up PCs

[Raoul Bhatia]

Hi!

I've tried to keep some up2date packages in my Github repositories, see 
https://github.com/backuppc/backuppc/wiki/Build-Your-Own-Packages , 
specifically


* https://github.com/raoulbhatia/rsync-bpc/tree/3.0.9.12-DEBIAN
* https://github.com/raoulbhatia/backuppc/tree/DEBIAN
* https://github.com/raoulbhatia/backuppc-xs/tree/DEBIAN

Would this help to get things back in shape?  Especially, I am no Debian 
expert and also have basic requirements for BackupPC only, so I will not 
be able to do this properly all by myself.


Raoul

On Thu, 18 Jan 2018 21:12:43 +0100 Axel Beckert  wrote:

Hi,

Ludovic Drolez wrote:
> Due to lack of time, I intend to orphan the backuppc package.


Thanks for recognizing such issues yourself and for doing the
orphaning yourself!


> Maintaining this package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.

I agree here and that's why I won't adopt it alone.

I'm nevertheless very interested in getting the package back in shape
and would join a team of people interested in team-maintaining
backuppc (and probably libbackuppc-xs-perl, too, see
https://bugs.debian.org/887491).

So if nobody else shows up soon-ish for joining a potential team, I
might start fixing issues doing a QA upload, getting the packaging up
to current standards, fixing long-standing trivial issues like e.g.
https://bugs.debian.org/488098 and creating a packaging git repository
under https://salsa.debian.org/debian i.e. the collab-maint successor
on Salsa. (Packaging 4.x.y versions is very likely not included in
such a first step.)

JFTR: I'm a BackupPC user and admin for more than 15 years now (in
personal as well as professional surroundings), it's in most cases my
primary backup system, and I'm even brave enough to run one soon-to-be
production instance on Debian Testing. :-)

Regards, Axel
--
 ,''`.  |  Axel Beckert , 
https://people.debian.org/~abe/

: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

--
DI (FH) Raoul Bhatia M.Sc.
E-Mail. ra...@bhatia.at
Tel. +43 699 10132530

Bug#862765: RFP: atomic -- Atomic Run Tool for installing/running/managing container images

[phil]

retitle 862765 RFP: atomic -- Atomic Run Tool for 
installing/running/managing container images


thanks
--
Philippe Thierry.

Bug#907032: has there been any thought of also having the rav1e encoder as well ?

[shirish शिरीष]

Hi all,

Have people looked at https://github.com/xiph/rav1e . One of the
blockages though seems to be https://github.com/mbebenita/rustfmt
which doesn't seem to be packaged in Debian at least in first glance.
As shared this one is supposed to be a bit faster than the reference
implementation for encoding though.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#905184: [Pkg-freeipa-devel] Bug#905184: upgrade of 389-ds-base fails if /var/lib/dirsrv is on different partition as /etc

[Jan Kowalsky]

solves the issue:

--- updates.orig/60upgradeconfigfiles.pl2018-09-03 09:58:45.911804203 
+0200
+++ updates/60upgradeconfigfiles.pl 2018-09-03 09:59:36.420699451 +0200
@@ -31,7 +31,7 @@
 next if (! -f $oldname); # does not exist - skip - already
(re)moved
 my $newname = "$bakdir/$file";
 $! = 0; # clear
-rename $oldname, $newname;
+move $oldname, $newname;
 if ($!) {
 push @errs, ["error_renaming_config", $oldname, $newname, $!];
 }
@@ -57,7 +57,7 @@
 next if (! -f $oldname); # does not exist - not backed up
 my $newname = $inf->{slapd}->{config_dir} . "/" . $file;
 next if (-f $newname); # not removed
-rename $oldname, $newname;
+move $oldname, $newname;
 }
 return @errs;
 }

Bug#905184: [Pkg-freeipa-devel] Bug#905184: upgrade of 389-ds-base fails if /var/lib/dirsrv is on different partition as /etc

[Jan Kowalsky]

Hi Timo,

sorry for delay, I missed the mail.

> What if you change 'rename' with 'move' in /usr/share/dirsrv/updates/*.pl?

It's suffucient to change it in

  /usr/share/dirsrv/updates/60upgradeconfigfiles.pl

then it works fine.

Regards
Jan

Bug#906250: ITP: execline -- small and non-interactive scripting language

[Jakub Wilk]

* Shengjing Zhu , 2018-09-02, 14:42:
When I try to package execline(a non-interactive shell script)[1], it 
installs following binaries in default PATH,


cd, if, exec, wait, 


Three of them (cd, umask, wait) clash with shell's regular built-in 
utilities. POSIX requires them to be exec(2)able[0][1]. Debian doesn't 
currently provide standalone executables for them (which is a bug), but 
some other distros do. The execline's implementation are of course not 
compatible with POSIX, and therefore must not be included within PATH.


[0] 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tagtcjh_18
[1] 
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap01.html#tag_23_01_07

--
Jakub Wilk

Bug#907858: inkscape: changes in grid color in the preferences take effect only after restart of the document

[Josef Atmin]

Package: inkscape
Version: 0.92.1-1
Severity: normal

Dear Maintainer,

I changed the color of the grid lines in the preferences.

First, nothing changed.

Only when I closed the document and reopened/restarted it did the color change 
take effect.

It would be great if the color would change immediately and would not require a 
restart.

In other applications there is often an [Apply] button that makes changes in the
preferences effective.  That might be useful here as well.

As a minor issue aside, a [Close] button in the color change window that pops 
up when I
klick on the color for minor or major lines in the preferences would be useful, 
or
closing it on typing return.  Would save one klick.

Best,

Josef.


-- System Information:
Debian Release: 9.5
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages inkscape depends on:
ii  libaspell150.60.7~20110707-3+b2
ii  libatk1.0-02.22.0-1
ii  libatkmm-1.6-1v5   2.24.2-2
ii  libc6  2.24-11+deb9u3
ii  libcairo2  1.14.8-1
ii  libcairomm-1.0-1v5 1.12.0-1+b1
ii  libcdr-0.1-1   0.1.3-3+b1
ii  libdbus-1-31.10.26-0+deb9u1
ii  libdbus-glib-1-2   0.108-2
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.2
ii  libgc1c2   1:7.4.2-8
ii  libgcc11:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0 2.36.5-2+deb9u2
ii  libglib2.0-0   2.50.3-2
ii  libglibmm-2.4-1v5  2.50.0-1
ii  libgomp1   6.3.0-18+deb9u1
ii  libgsl22.3+dfsg-1
ii  libgtk2.0-02.24.31-2
ii  libgtkmm-2.4-1v5   1:2.24.5-1
ii  libgtkspell0   2.0.16-1.1
ii  libjpeg62-turbo1:1.5.1-2
ii  liblcms2-2 2.8-4
ii  libmagick++-6.q16-78:6.9.7.4+dfsg-11+deb9u5
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-11+deb9u5
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-11+deb9u5
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpangoft2-1.0-0  1.40.5-1
ii  libpangomm-1.4-1v5 2.40.1-3
ii  libpng16-161.6.28-1
ii  libpoppler-glib8   0.48.0-2+deb9u2
ii  libpoppler64   0.48.0-2+deb9u2
ii  libpopt0   1.16-10+b2
ii  libpotrace01.13-3
ii  librevenge-0.0-0   0.0.4-6
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libstdc++6 6.3.0-18+deb9u1
ii  libvisio-0.1-1 0.1.5-4+b1
ii  libwpg-0.3-3   0.3.1-3
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-2.2+deb9u2
ii  libxslt1.1 1.1.29-2.1
ii  python 2.7.13-2
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages inkscape recommends:
ii  aspell   0.60.7~20110707-3+b2
ii  fig2dev [transfig]   1:3.2.6a-2+deb9u1
ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u5
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u5
ii  libimage-magick-perl 8:6.9.7.4+dfsg-11+deb9u5
ii  libwmf-bin   0.2.8.4-10.6
ii  python-lxml  3.7.1-1
ii  python-numpy 1:1.12.1-3
ii  python-scour 0.32-2
ii  transfig 1:3.2.6a-2+deb9u1

Versions of packages inkscape suggests:
pn  dia | dia-gnome  
pn  libsvg-perl  
pn  libxml-xql-perl  
ii  pstoedit 3.70-3+b2
pn  python-uniconvertor  
ii  ruby 1:2.3.3

-- no debconf information

Bug#906284: lintian: check for incomplete-creative-commons-license gives false positives: the "not a law firm" is a preamble, not a license

[Chris Lamb]

Hi,

> I attempted to simulate this change in Lintian with a totally
> separate hacky script

(I like how this implies that Lintian, too, is a hacky script...)

Do let me know when you are happy with the output so we can update
Lintian, etc.


Regards,

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

Bug#907857: inkscape: an option to change the width of grid lines would be great

[Josef Atmin]

Package: inkscape
Version: 0.92.1-1
Severity: wishlist

Dear Maintainer,

it would be great if there were an option to change the width of the grid 
lines.  The
defauld width is to thin for my taste.  And when I use points instead of lines, 
they are
hardly visible.  Has probably to do with the high resolution of my screen.  So 
there is
good reason to make that changable.

Best,

Josef.

-- System Information:
Debian Release: 9.5
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages inkscape depends on:
ii  libaspell150.60.7~20110707-3+b2
ii  libatk1.0-02.22.0-1
ii  libatkmm-1.6-1v5   2.24.2-2
ii  libc6  2.24-11+deb9u3
ii  libcairo2  1.14.8-1
ii  libcairomm-1.0-1v5 1.12.0-1+b1
ii  libcdr-0.1-1   0.1.3-3+b1
ii  libdbus-1-31.10.26-0+deb9u1
ii  libdbus-glib-1-2   0.108-2
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.2
ii  libgc1c2   1:7.4.2-8
ii  libgcc11:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0 2.36.5-2+deb9u2
ii  libglib2.0-0   2.50.3-2
ii  libglibmm-2.4-1v5  2.50.0-1
ii  libgomp1   6.3.0-18+deb9u1
ii  libgsl22.3+dfsg-1
ii  libgtk2.0-02.24.31-2
ii  libgtkmm-2.4-1v5   1:2.24.5-1
ii  libgtkspell0   2.0.16-1.1
ii  libjpeg62-turbo1:1.5.1-2
ii  liblcms2-2 2.8-4
ii  libmagick++-6.q16-78:6.9.7.4+dfsg-11+deb9u5
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-11+deb9u5
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-11+deb9u5
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpangoft2-1.0-0  1.40.5-1
ii  libpangomm-1.4-1v5 2.40.1-3
ii  libpng16-161.6.28-1
ii  libpoppler-glib8   0.48.0-2+deb9u2
ii  libpoppler64   0.48.0-2+deb9u2
ii  libpopt0   1.16-10+b2
ii  libpotrace01.13-3
ii  librevenge-0.0-0   0.0.4-6
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libstdc++6 6.3.0-18+deb9u1
ii  libvisio-0.1-1 0.1.5-4+b1
ii  libwpg-0.3-3   0.3.1-3
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-2.2+deb9u2
ii  libxslt1.1 1.1.29-2.1
ii  python 2.7.13-2
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages inkscape recommends:
ii  aspell   0.60.7~20110707-3+b2
ii  fig2dev [transfig]   1:3.2.6a-2+deb9u1
ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u5
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u5
ii  libimage-magick-perl 8:6.9.7.4+dfsg-11+deb9u5
ii  libwmf-bin   0.2.8.4-10.6
ii  python-lxml  3.7.1-1
ii  python-numpy 1:1.12.1-3
ii  python-scour 0.32-2
ii  transfig 1:3.2.6a-2+deb9u1

Versions of packages inkscape suggests:
pn  dia | dia-gnome  
pn  libsvg-perl  
pn  libxml-xql-perl  
ii  pstoedit 3.70-3+b2
pn  python-uniconvertor  
ii  ruby 1:2.3.3

-- no debconf information

Bug#907838: RFS: 2 pkgs once part of emacs-goodies-el: bm-el/201808-1, mutt-alias-el/1.5-1

[Chris Lamb]

Nicholas,

Please separate upload requests for different packages regardless of
their origin.


> https://mentors.debian.net/debian/pool/main/b/bm-el/bm-el_201808-1.dsc

Uploaded. For your next upload please address:

  * Isn't:

 Files: bm-sync.el
 Copyright: 2016 Jo Odland
 License: GPL-2+

.. superfluous, given:

 Files: *
 Copyright: 2000-2016 Jo Odland
 License: GPL-2+

  * Standards-Version: 4.2.0 → Standards-Version: 4.2.1

> https://mentors.debian.net/debian/pool/main/m/mutt-alias-el/mutt-alias-el_1.5-1.dsc

Uploaded. For your next upload please address:

  * s/mutt/Mutt/ in description(s).

  * Standards-Version: 4.2.0 → Standards-Version: 4.2.1

  * Drop DH_VERBOSE=1

  * Tidy the long description; there is a de facto standard of sorts
for such lists here or at least prettier ones.


Regards,

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

Bug#905824: med-fichier: missing files due to non-CMake build

[Kurt Kremitzki]

By the way, do you happen to know the story with the shared library
version numbers for med-fichier? Instead of using the version number
3.3.1, we have 1.9.1 for libmed.so and libmedc.so, and 0.3.0 for
libmedimport.so.

Producing a CMake build wants to use the version number 3.3.1 which
would suggest the need for a package rename from libmed{,c}1v5 and
libmedimport0v5, but I can't really find anything on why the version
numbers are what they are now or what's up with the strange package names.

On Sat, 11 Aug 2018 23:43:13 +0200 Gilles Filippini  wrote:

> Control: tags -1 + moreinfo
>
> Hi,
>
> On Fri, 10 Aug 2018 04:59:38 -0500 Kurt Kremitzki 
> wrote:
> > Source: med-fichier
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Med-fichier supports CMake builds, and if CMake is used there are
> > several .cmake helper files generated which are currently missing from
> > the package. Downstream projects then expect those .cmake files to be
> > available, and it causes difficulty when they are not.
> >
> > Please update the package to use the CMake buildsystem and include all
> > missing files.
>
> Patches welcome :)
>
> I gave a try using the CMake build system, but it failed. Firstly, there
> is no CMakeList.txt to build the doc. Secondly the test suite fails:
> > Start 37: Testtest13f
> > 37/70 Test #37: Testtest13f ..***Failed 0.01 sec
> > 0
> > Maillage de nom : maa1 et de dimension : 3
> > 0
> > Nombre d'equivalence : 1
> > Equivalence numero : 1
> >
/build/med-fichier-VMwX2G/med-fichier-3.3.1+repack/src/hdfi/MEDfichierNo.c
[39] : Impossible d'identifier un numéro de fichier correct à partir de
l'identifiant :
> >
/build/med-fichier-VMwX2G/med-fichier-3.3.1+repack/src/hdfi/MEDfichierNo.c
[40] : id = 4294967296
> >
/build/med-fichier-VMwX2G/med-fichier-3.3.1+repack/src/misc/MEDversionedApi3C.c
[42] : Cette bibliothèque MED n'est pas capable de lire un fichier MED
de version < 2.2.0
> >
/build/med-fichier-VMwX2G/med-fichier-3.3.1+repack/src/misc/MEDversionedApi3C.c
[43] : La version demandée est :
> >
/build/med-fichier-VMwX2G/med-fichier-3.3.1+repack/src/misc/MEDversionedApi3C.c
[44] : _fversionMMR = 0
> >
/build/med-fichier-VMwX2G/med-fichier-3.3.1+repack/src/misc/MEDversionedApi3C.c
[116] : Impossible d'obtenir une implémentation de :
> >
/build/med-fichier-VMwX2G/med-fichier-3.3.1+repack/src/misc/MEDversionedApi3C.c
[117] : key = "_MEDequivalenceInfo"
> >
/build/med-fichier-VMwX2G/med-fichier-3.3.1+repack/src/misc/MEDversionedApi3C.c
[118] : en version :
> >
/build/med-fichier-VMwX2G/med-fichier-3.3.1+repack/src/misc/MEDversionedApi3C.c
[119] : _fversionMMR = 0
> >
/build/med-fichier-VMwX2G/med-fichier-3.3.1+repack/src/misc/MEDversionedApi3C.c
[120] : Vérifiez votre fichier .med et votre version de bibliothèque.
>
> Thanks,
>
> _g.
>

Bug#907856: inkscape: color of minor grid lines is used for major grid lines when zooming out

[Josef Atmin]

Package: inkscape
Version: 0.92.1-1
Severity: minor

Dear Maintainer,

I changed the preference of the grid lines so that minor lines are orange and 
major lines are still blue (the default).

(First nothing changes, I had to leave the document and start it anew before 
the change was accepted, but that is another bug report.)

When I restarted the document, the major lines were orange (which they should 
not be).
Only when I zoomed in, in the moment where minor lines were added (in the 
correct color =
orange), did the color of the major lines change to blue, the correct color.  
So when I
zoom in and out the color of the major lines change in the moment the minor 
lines are
added.  I find that confusing and consider it a bug.  Instead the color of the 
major
lines should always be the color of the major lines in the preferences, blue in 
this
case.

Thanks for providing such a great tool to the community.

Best regards,

Josef.

-- System Information:
Debian Release: 9.5
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages inkscape depends on:
ii  libaspell150.60.7~20110707-3+b2
ii  libatk1.0-02.22.0-1
ii  libatkmm-1.6-1v5   2.24.2-2
ii  libc6  2.24-11+deb9u3
ii  libcairo2  1.14.8-1
ii  libcairomm-1.0-1v5 1.12.0-1+b1
ii  libcdr-0.1-1   0.1.3-3+b1
ii  libdbus-1-31.10.26-0+deb9u1
ii  libdbus-glib-1-2   0.108-2
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.2
ii  libgc1c2   1:7.4.2-8
ii  libgcc11:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0 2.36.5-2+deb9u2
ii  libglib2.0-0   2.50.3-2
ii  libglibmm-2.4-1v5  2.50.0-1
ii  libgomp1   6.3.0-18+deb9u1
ii  libgsl22.3+dfsg-1
ii  libgtk2.0-02.24.31-2
ii  libgtkmm-2.4-1v5   1:2.24.5-1
ii  libgtkspell0   2.0.16-1.1
ii  libjpeg62-turbo1:1.5.1-2
ii  liblcms2-2 2.8-4
ii  libmagick++-6.q16-78:6.9.7.4+dfsg-11+deb9u5
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-11+deb9u5
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-11+deb9u5
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpangoft2-1.0-0  1.40.5-1
ii  libpangomm-1.4-1v5 2.40.1-3
ii  libpng16-161.6.28-1
ii  libpoppler-glib8   0.48.0-2+deb9u2
ii  libpoppler64   0.48.0-2+deb9u2
ii  libpopt0   1.16-10+b2
ii  libpotrace01.13-3
ii  librevenge-0.0-0   0.0.4-6
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libstdc++6 6.3.0-18+deb9u1
ii  libvisio-0.1-1 0.1.5-4+b1
ii  libwpg-0.3-3   0.3.1-3
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-2.2+deb9u2
ii  libxslt1.1 1.1.29-2.1
ii  python 2.7.13-2
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages inkscape recommends:
ii  aspell   0.60.7~20110707-3+b2
ii  fig2dev [transfig]   1:3.2.6a-2+deb9u1
ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u5
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u5
ii  libimage-magick-perl 8:6.9.7.4+dfsg-11+deb9u5
ii  libwmf-bin   0.2.8.4-10.6
ii  python-lxml  3.7.1-1
ii  python-numpy 1:1.12.1-3
ii  python-scour 0.32-2
ii  transfig 1:3.2.6a-2+deb9u1

Versions of packages inkscape suggests:
pn  dia | dia-gnome  
pn  libsvg-perl  
pn  libxml-xql-perl  
ii  pstoedit 3.70-3+b2
pn  python-uniconvertor  
ii  ruby 1:2.3.3

-- no debconf information

Bug#904669: xmds2: autopkgtest times out since 2018-07-19

[Rafael Laboissière]

Hi Paul,

* Paul Gevers  [2018-09-02 18:21]:


Hi Rafael,

On 02-09-18 18:10, Rafael Laboissière wrote:


I just uploaded version 2.2.3+dfsg-11 of the xmds2 package to unstable. 
The time-out problem seems to be fixed in this version.  Could you 
please remove xmds2 from the blacklist to see what happens?


I'll manually trigger a run (actually already did before even checking 
if the package was available). If it succeeds, I'll lift the blacklist.


Did it work?  Unfortunately, the autobuild failed [*].  It is certainly a 
problem related to MPI and it is very hard to debug.  I was convinced 
that I have fixed it in version 2.2.3+dfsg-11 of the package.


Best,

Rafael

[*] 
https://buildd.debian.org/status/fetch.php?pkg=xmds2=all=2.2.3%2Bdfsg-11=1535907154=0

Bug#901572: acccheck: CVE-2018-12268: Patch proposal

[phil]

tags 901572 + patch
user p...@reseau-libre.net
usertags pkg-security-team

thanks

Hello,

I've updated the acccheck.pl behavior to correct (i hope) the 
CVE-2018-12268. User and password input files are sanitized before any 
use in the generated commandline string. The patch is given attached to 
this mail.


Nevertheless, the package doesn't have separated branches for stretch 
and unstable releases, which leads to d/changelog files being denoted as 
targetting for 'unstable' even in the stetch package. In the given 
patch, the only missing point is the "stretch-security" naming of the 
target, as it whould be better to separate into two branches first.


Cheers,
--
Philippe Thierry.diff -Nru acccheck-0.2.1/debian/changelog acccheck-0.2.1/debian/changelog
--- acccheck-0.2.1/debian/changelog	2016-11-08 14:36:12.0 +0100
+++ acccheck-0.2.1/debian/changelog	2018-08-31 21:28:02.0 +0200
@@ -1,3 +1,13 @@
+acccheck (0.2.1-4) unstable; urgency=high
+
+  * Team-upload.
+
+  [ Philippe Thierry ]
+  * Fixes CVE-2018-12268 (command injection via user or password file)
+  * Closes: #901572
+
+ -- Philippe Thierry   Fri, 31 Aug 2018 21:28:02 +0200
+
 acccheck (0.2.1-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru acccheck-0.2.1/debian/patches/series acccheck-0.2.1/debian/patches/series
--- acccheck-0.2.1/debian/patches/series	2016-11-08 14:36:12.0 +0100
+++ acccheck-0.2.1/debian/patches/series	2018-08-31 21:28:02.0 +0200
@@ -1 +1,2 @@
 amend-usage-output
+shell_escape_fix.patch
diff -Nru acccheck-0.2.1/debian/patches/shell_escape_fix.patch acccheck-0.2.1/debian/patches/shell_escape_fix.patch
--- acccheck-0.2.1/debian/patches/shell_escape_fix.patch	1970-01-01 01:00:00.0 +0100
+++ acccheck-0.2.1/debian/patches/shell_escape_fix.patch	2018-08-31 21:28:02.0 +0200
@@ -0,0 +1,45 @@
+Description: Fixes vulnerability in users and passwords file usage
+ This bug allow remote command injection (CVE-2018-12268)
+Author: Philippe Thierry :w
+Bug-Debian: https://bugs.debian.org/901571 
+--- a/acccheck.pl
 b/acccheck.pl
+@@ -88,6 +88,20 @@
+ $userFile=0;
+ $verbose=0;
+ 
++# first of all, sanitizing non-printable chars
++sub sanitize
++{
++  foreach $item (@_) {
++  # ASCII printable chars only
++  $item =~ s/[^[:print:]]//g;
++  # Fixes: CVE-2018-12268
++  # single quoting is used for escaping when executing smbclient.
++  # Any single quote found in the string must be escaped using autonmous
++  # explicit single quoted string
++  $item =~ s/'/'\\''/g;
++  }
++}
++
+ #main
+ {
+ 	$SIG{"INT"} = "cleanup";
+@@ -142,11 +156,15 @@
+ 	}
+ 	if($passFile == 1)
+ 	{
+-		tie @PASS_LIST, 'Tie::File', $PASSFILE or die "cannot open $PASSFILE file";
++		tie @UNSAFE_PASS_LIST, 'Tie::File', $PASSFILE or die "cannot open $PASSFILE file";
++@PASS_LIST = @UNSAFE_PASS_LIST;
++sanitize(@PASS_LIST);
+ 	}
+ 	if($userFile == 1)
+ 	{
+-		tie @USER_LIST, 'Tie::File', $USERFILE or die "cannot open $USERFILE file";
++		tie @UNSAFE_USER_LIST, 'Tie::File', $USERFILE or die "cannot open $USERFILE file";
++@USER_LIST = @UNSAFE_USER_LIST;
++sanitize(@USER_LIST);
+ 	}
+ 
+ 

Bug#867668: packages on security.debian.org have different Priority than in the main archive

[intrigeri]

Hi,

Sven Joachim:
> The package priorities on security.debian.org differ from the ones in
> the main archive

Here's another brand new example:

$ apt-cache show mutt | grep -E '^(Version|Priority)' 
Version: 1.7.2-1+deb9u1
Priority: standard
Version: 1.7.2-1
Priority: optional

This causes mutt to be installed by default in some setups since
1.7.2-1+deb9u1 was uploaded, which was not the case before 2018-08-17.

Is there anything a DD who's not on the ftpmaster team can do to help
fix that? (I was not able to find the relevant file that needs to
be updated.)

Cheers,
-- 
intrigeri

Bug#907803: closed by Adam Borowski (Re: Bug#907803: RFS: udfclient/0.8.9-1)

[Pali Rohár]

On Monday 03 September 2018 01:15:28 Adam Borowski wrote:
> On Sun, Sep 02, 2018 at 11:37:43PM +0200, Pali Rohár wrote:
> > On Sunday 02 September 2018 21:33:03 Debian Bug Tracking System wrote:
> > > Nitpick: these warnings are trivial to fix:
> > > W: udfclient source: dep5-copyright-license-name-not-unique bsd-2-clause 
> > > (paragraph at line 37)
> > > W: udfclient source: dep5-copyright-license-name-not-unique bsd-2-clause 
> > > (paragraph at line 62)
> > > W: udfclient source: dep5-copyright-license-name-not-unique bsd-4-clause 
> > > (paragraph at line 149)
> > > so it'd be nice if you could get rid of them in the future.  Not an
> > > important thing, but less noise is good.
> > 
> > How to fix this problem? There are basically 3 different texts of BSD
> > licenses in source files.
> 
> You need to give them unique names.  If the body of a license is different,
> so must be its short name.
> 
> Yeah, that's somewhat unpleasant, but the reason is obvious.

Ok. So which short names should I use? I used "bsd-*-clause" name as described 
in table at:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name

-- 
Pali Rohár
pali.ro...@gmail.com

Bug#907855: racket-mode: testsuite failure on arm64

[Gianfranco Costamagna]

Source: racket-mode
Severity: important
Version: 20180731+0+g948c8aa-2

Hello, since the last snapshot, testsuite has started to fail in Ubuntu (and I 
presume in Debian too), but only on arm64...

I packaged the old version and it was good, even with the new emacs, so this is 
why I'm reporting a bug.

Everything is good, with the "next-free-port" changed in testsuite to the old 
fixed 6 port.

I don't know the root cause for the failure, this is the "revert patch" I added 
in Ubuntu build.

+--- racket-mode-20180731+0+g948c8aa.orig/racket-tests.el
 racket-mode-20180731+0+g948c8aa/racket-tests.el
+@@ -71,7 +71,7 @@
+   "Start REPL. Confirm we get Welcome message and prompt. Exit REPL."
+   (let ((tab-always-indent 'complete)
+ (racket--repl-command-connect-timeout (* 15 60))
+-(racket-command-port (racket-tests/next-free-port))
++(racket-command-port 6)
+ (racket-command-timeout (* 15 60)))
+ (racket-repl)
+ (with-racket-repl-buffer
+@@ -98,7 +98,7 @@
+ 
+ (ert-deftest racket-tests/run ()
+   (let* ((racket--repl-command-connect-timeout (* 15 60))
+- (racket-command-port (racket-tests/next-free-port))
++ (racket-command-port 6)
+  (racket-command-timeout (* 15 60))
+  (pathname (make-temp-file "test" nil ".rkt"))
+  (name (file-name-nondirectory pathname))



and the test failure:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/arm64/r/racket-mode/20180820_184445_abda2@/log.gz

autopkgtest [18:14:06]: test command1: dh_elpa_test --autopkgtest
autopkgtest [18:14:06]: test command1: [---
emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 
'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f 
package-initialize -L . -L test -l racket-tests.el --eval 
\(ert-run-tests-batch-and-exit\)
Running 5 tests (2018-08-20 18:14:09+)
   passed  1/5  racket-tests/font-lock
Indenting region...
Indenting region...64%
Indenting region...75%
Indenting region...done
Indenting region...
Indenting region...62%
Indenting region...96%
Indenting region...done
   passed  2/5  racket-tests/indent-rkt
Checking Racket version ...

Starting racket to run 
/usr/share/emacs/site-lisp/elpa-src/racket-mode-20170731/run.rkt ...
Still trying to connect to racket-command process on port 7 ...
Still trying to connect to racket-command process on port 7 ...
Still trying to connect to racket-command process on port 7 ...

[lots of similar lines]
Still trying to connect to racket-command process on port 7 ...
Test racket-tests/repl backtrace:
  (progn (error "Could not connect to racket-command process on port %
  (if (eq -with-timeout-value- (quote timeout)) (progn (error "Could n
  (let ((-with-timeout-value- (catch (quote timeout) (let* ((-with-tim
  racket--repl-command-connect-finish()
  racket--repl-command-async((syms) (closure ((result . RACKET-REPL-AW
  (let* ((awaiting (quote RACKET-REPL-AWAITING)) (result awaiting)) (r
  racket--repl-command((syms))
  (list (racket--repl-command (quote (syms
  (setq racket--namespace-symbols (list (racket--repl-command (quote (
  (progn (setq racket--namespace-symbols (list (racket--repl-command (
  (if (racket--in-repl-or-its-file-p) (progn (setq racket--namespace-s
  (if racket--namespace-symbols nil (if (racket--in-repl-or-its-file-p
  racket--completion-candidates()
  (cl-reduce (function (lambda (results strs) (append results (all-com
  racket--completion-candidates-for-prefix("with-inp")
  (closure ((end . 37) (beg . 29) (_predicate) t) (_) (racket--complet
  #[771 "\211\242\302=\206\n�\211\303=?\2053�r\301\204�p\202(�\304 \3
  try-completion("with-inp" #[771 "\211\242\302=\206\n�\211\303=?\2053
  completion-basic-try-completion("with-inp" #[771 "\211\242\302=\206\
  #[257 "\300

\2368\301\242\302\242\303\304\242$\207" [1 ("with-inp")
  completion--some(#[257 "\300

\2368\301\242\302\242\303\304\242$\207
  completion--nth-completion(1 "with-inp" #[771 "\211\242\302=\206\n�\
  completion-try-completion("with-inp" #[771 "\211\242\302=\206\n�\211
  completion--do-completion(# 37)
  completion--in-region-1(# 37)
  #[1028 "

\n\203!�\304!\203�\202�\305!\305\306\"F\307\310
  apply(#[1028 "

\n\203!�\304!\203�\202�\305!\305\306\"F\3
  #[771 ":\2030�@\301=\203�\300\242\302A\"\303#\207\304@\305\30
  completion--in-region(# 37 #[771 "\21
  completion-in-region(# 37 #[771 "\211
  completion-at-point()
  indent-for-tab-command(nil)
  funcall-interactively(indent-for-tab-command nil)
  call-interactively(indent-for-tab-command nil nil)
  command-execute(indent-for-tab-command)
  execute-kbd-macro([9])
  (let ((blink-matching-paren nil)) (execute-kbd-macro (string-to-vect
  racket-tests/type("   ")
  racket-tests/press("TAB")
  racket-tests/type("with-inp" 

Bug#907829: p4est: FTBFS on single CPU machines (?)

[Graham Inggs]

Hi Santiago

On 2 September 2018 at 19:21, Santiago Vila  wrote:
> My guess is that this is a bug in p4est but it's triggered by a build depends
> which changed behaviour somewhere between 2017-12-24 (where version 1.1-5
> still built ok for me in buster) and 2018-06-03 (where it did not anymore).

Yes, openmpi flipped the default for oversubscription *again*, see #849974.

Would you please check whether the following change to debian/rules
fixes it for you?

--- a/debian/rules
+++ b/debian/rules
@@ -3,6 +3,7 @@
 include /usr/share/dpkg/pkg-info.mk

 export OMPI_MCA_plm_rsh_agent=/bin/false
+export OMPI_MCA_rmaps_base_oversubscribe=1

 %:
 dh $@

Regards
Graham

Bug#782287: hw-detect: install open-vm-tools in d-i

[Christian Ehrhardt]

On Wed, 13 Jun 2018 00:29:33 +0200 Bernd Zeimetz  wrote:
> Hi again,
>
> things have changed - thanks VMware - and I'd be happy to support
> whatever is needed to make d-i install open-vm-tools when being run in a
> VMware environment.

I'd think so as well, things got better since then.

> Regarding the suggested extra binary I'm wondering if dmidecode wouldn't
> be appropriate to handle the detection of a virtualized environment as
> dmidecode is shipping an udeb anyway.

I opened PR [1] for your consideration which would be a rewrite with the
suggested changes.
Looking much simpler now, but I can't test that so I'd ask people with
VMWare to give that a sanity check.

@Oliver Kurth  maybe you can give that a shot if it
would suit your needs?

[1]: https://salsa.debian.org/installer-team/hw-detect/merge_requests/2

Bug#906352: ekg2: FTBFS in buster/sid (Can't exec "automake-1.15")

[Juhani Numminen]

On Fri, 17 Aug 2018 11:19:32 + Santiago Vila  wrote:
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:
> 
> [...]
> autoreconf: failed to run automake-1.15: No such file or directory

That's because of 
https://sources.debian.org/src/ekg2/1:0.4%7Epre+20120506.1-14/debian/rules/#L7
---
# As recommended by "current Debian best practice" prescribed by autotools-dev,
# we specify an explicit automake version
export AUTOMAKE=automake-1.15
---

autoreconf will try to use the older automake even though it isn't a 
build-dependency.
This has happened before: https://bugs.debian.org/797230 
https://bugs.debian.org/722607

Note: I think the comment is referring to 
https://sources.debian.org/src/autotools-dev/20180224.1/debian/autotools-dev.README.Debian/#L168


Cheers,
Juhani

Bug#899298: golang-1.10-go: vgo run fail

[Gregor Riepl]

That doesn't work. The path should be: /usr/share/go-1.10

Alternatively, one can use:
export VGOROOT=/usr/share/go-1.10

vgo working out of the box would be nicer though, agreed.

Bug#907854: RM: mail-notification -- ROM; uses obsolete GNOME libraries, unlikely to be ported

[Stephen Kitt]

Package: ftp.debian.org
Severity: normal

Dear FTP team,

Please remove mail-notification — it relies on GNOME libraries which
won’t ship with Buster, and is highly unlikely to be ported to their
replacements. (I’m upstream; if it does get ported, it can go through
NEW again, but in the mean time it’s better to stop kidding myself and
the package’s users.)

Regards,

Stephen

Bug#907853: liblwp-protocol-https-perl: turning off hostname verification does not work

[Slaven Rezic]

Package: liblwp-protocol-https-perl
Version: 6.06-2
Severity: normal

Dear Maintainer,

to disable hostname verification in https requests one would set ssl_opts'
verify_hostname to a false value. However, this does not work:

$ perl -MLWP::UserAgent -e '$ua=LWP::UserAgent->new; 
$ua->ssl_opts(verify_hostname=>0); $res = $ua->get("https://www.dwd.de;); warn 
$res->as_string' 
500 Can't connect to www.dwd.de:443 (certificate verify failed)
Content-Type: text/plain
Client-Date: Mon, 03 Sep 2018 05:58:34 GMT
Client-Warning: Internal response

Can't connect to www.dwd.de:443 (certificate verify failed)

SSL connect attempt failed error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify failed at 
/usr/share/perl5/LWP/Protocol/http.pm line 47.

With a self-compiled perl and modules installed from CPAN this works as expected
(in this case there's no artificial 500 response, but a 403 Forbidden response).

I found out that it's possible to workaround the issue with
Debian's perl by setting SSL_verify_mode:

$ perl -MIO::Socket::SSL=SSL_VERIFY_NONE -MLWP::UserAgent -e 
'$ua=LWP::UserAgent->new; $ua->ssl_opts(SSL_verify_mode => SSL_VERIFY_NONE, 
verify_hostname => 0); $res = $ua->get("https://www.dwd.de;); warn 
$res->as_string'

The issue is still present on Ubuntu 18.04 which has a newer
version of liblwp-protocol-https-perl. I also don't know if the
problem lies in LWP, LWP::Protocol::https, IO::Socket::SSL,
Net::SSLeay, or any other module.

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

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

Versions of packages liblwp-protocol-https-perl depends on:
ii  ca-certificates20161130+nmu1+deb9u1
ii  libio-socket-ssl-perl  2.044-1
ii  libnet-http-perl   6.12-1
ii  libwww-perl6.15-1
ii  perl   5.24.1-3+deb9u4

liblwp-protocol-https-perl recommends no packages.

Versions of packages liblwp-protocol-https-perl suggests:
pn  libcrypt-ssleay-perl  

-- no debconf information

Bug#473227: less: Prints UTF-8 Byte order mark

[Paul Hardy]

Hi,

Just an update.  I did not have a released package to check for Byte
Order Marks (BOMs) when I wrote my previous message for this bug.
Today, however, I uploaded what I think is a reasonably working
version of my package utfcheck, which checks an input file to see if
it is valid UTF-8.  Among other things it will look for and report
BOMs anywhere in an input file.  You can see it here:

 https://tracker.debian.org/pkg/utfcheck

Start with the latest uploaded version, utfcheck-1.2-1.  That has
additional information in the man page that was not in previous
versions.  It prints a summary after reaching end of file on its
input, and will even report BOMs that are embedded in the middle of a
file--something that a user could easily miss with less.

As for the BOM being in text files, programs need to handle that
condition correctly.  I mentioned in my last message that a UTF-8 BOM
has been specifically mentioned as legal Unicode in Table 2.4 of the
Unicode Standard from version 5.0 onwards, and actually before then
that table was Table 2.3 in version 4.0 of the standard.  Someone
mentioned elsewhere that LibreOffice includes the BOM in text files,
so if nothing else there is no escaping it if a program is to read
UTF-8 input from a text file that LibreOffice creates.

In version 3.0 of the Unicode Standard, Section 13.6 "Specials" on p.
324 states that "In UTF-8...this sequence can serve as a signature for
UTF-8 encoded text where the character set is unmarked."  That was
published in 2000, almost 20 years ago.

I could look it up in older versions of the Unicode Standard too (I
have them going back to version 1.0), but I hope there can be general
agreement that such a long period of time is long enough for
application software to conform.

In keeping with the original Unix philosophy that a program should do
one thing, and do it well, less should be able to render scrolling
text as it is meant to be displayed.  That doesn't solve the situation
of the UTF-8 BOM though.  I hope that utfcheck helps the situation.

Thanks,


Paul Hardy