Bug#910965: libngspice0: typo in short description: cicruit → circuit

[Carsten Schoenert]

Hello Jonas,

On Sat, Oct 13, 2018 at 10:55:08PM +0200, Jonas Smedegaard wrote:
> Hi,
> 
> Short description says "Spice cicruit simulator - library".
> 
> Probably should be "circuit".

not only probably. :) Sometimes you don't see such issues any more. It
was a long trip with ngspice until here.

Fixed and will be included in the next upload. Thanks!

Regards
Carsten

Bug#909441: ngspice: new upstream version available

[Carsten Schoenert]

Version: 28-1

Hello Oswald,

On Sun, Sep 23, 2018 at 07:30:09PM +0200, Oswald Buddenhagen wrote:
> Package: ngspice
> Version: 27-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> upstream released version 28 with some interesting new features 
> a few months ago.

ngspice 28-1 was needed to go through NEW bit did this yesterday.
So version 28 is now available in unstable/main.

Regards (and closing thisreport)
Carsten

Bug#910971: fails to connect to irc server with no indication why

[Damyan Ivanov]

Control: clone -1 -2
Control: retitle -2 kgb-bot: silently fails when using SSL on port 6667

-=| Joey Hess, 13.10.2018 18:42:12 -0400 |=-
> Package: kgb-bot
> Version: 1.52-1
> Severity: normal
> 
> My kgb bot fell off of all three irc servers it was connecting to 
> a while back,
> …
> Aha, looking at the changelog, it seems that use_ssl was added and 
> defaults to 1,
> and apparently it fails to connect over ssl for whatever reason, and this is 
> the

The kgb.conf file shipped in 1.52 has '-port: 6667', which doesn't 
help when the (silent) default for 'use_ssl' is 1 and I get the same 
behaviour as you locally. Adding use_ssl: 0 helps here, and I bet 
leaving the default for use_ssl and changing the port to 6697 would 
help too.

> result. This config change warrants mention in NEWS at least,

Yeah, sorry about that. We seem to constantly forget that there are 
other instances besides kgb-[0-2]

> and if there's a ssl error, it ought to show it in the log.

Cloning the silent failure when use_ssl is 1 and the port doesn't 
support SSL as a new big.


-- dam

Bug#910846: No packages.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There is no "xserver-xorg-video-radeon-dbgsym" or "xserver-xorg-core-dbgsym" in 
the repo.
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAQBQJbwsu/CRDYtWA5RV10HwAAlBoH/31H3xlegMCUp4lFdulZ
cGqNjqkA4nljr2x4Jmrr00RzxWiLUcd7P96wogePu15NSHj5qEzLTiiWlIoX
0AFJO+zaoua02QiqS9TEZz8wET11f4J/3KhqvyX00QWCXk06CQP9N7aGtL15
SCJ7x0p2B1U/6F0LVdUBcPnOAv/WB0c1SkcYJSPHZII1dCIUelHVz4lakwAA
jerubxK0qIOS1YZTNHQiLAhlLhFuhY0NPbvD4+QnEKDFm/HgJ424mBHaZ7t+
KqdZ4olbLWrYFpEkDjbs2cdSywWWA3tKYCZwZc/2u8atllg4MDNgsf7UfQNd
ZbDZp+Nzu9Hlgf0soqsg+Ww=
=00U5
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#834247: marked as done (ngspice is configured with --with-editline, --with-readline would work better)

[Felix Salfelder]

Dear Carsten.

It seems, now ngspice is configured --with-readline, reverting a change in
ngspice 24-1.

  * Change readline dependency to libedit-dev

I couldn't find an explanation for why this is possible now, there's only the
old paragraph from 2003

"""
Added Andrew Veliath patch for readline support. Using
readline with ngspice IS A VIOLATION OF GPL LICENSE, you
have been warned. The final decision is up to you. The
patch has been applied in the perspective of changing
readline library with libedit. Libedit aims to be a
replacement of readline and is covered by BSD license.
Libedit is available at the URL: libedit.sourceforge.net.
"""

in ngspice/ChangeLog.

Could you please explain what has changed since then? Apologies, if i am
missing something obvious.

best regards
felix

Bug#894519: xpra 2.4 depends on python-gtkglext1

[Celeste Weingartner]

[image: image.png]
so its removal from testing hinders xpra installation on buster.. costing
me several hours of configure time..

Bug#910975: libopkele: Please update package priority and replace "extra" with "optional"

[Boyuan Yang]

Source: libopkele
Version: 2.0.4+git20140305.9651b55-3
Severity: normal
Tags: patch

Dear libopkele maintainer,

Your package now emits lintian warnings:

W: libopkele3v5: priority-extra-is-replaced-by-priority-optional
W: libopkele-dev: priority-extra-is-replaced-by-priority-optional

This is because that  source package is still using obsoleted
Priority: extra. Please replace that with Priority: optional.

Thanks!

Regards,
Boyuan Yang

Bug#910942: [wine-development] Please use wrap-and-sort

[Jens Reyer]

Hi Mike

On 10/14/18 2:36 AM, Michael Gilbert wrote:
> Welcome back!

Thanks, much appreciated!  btw, I'm just working on 3.0.3-1.


> Wrap and sort is itself the original source of the extra diff being
> seen and will continue to be in the future.

Wrap and sort has a deterministic result.  We could add it to
debian/scripts/import, so that even misplaced entries get sorted quite
soon, and then stay in their place forever.


> I would prefer to
> maintain the original rough organization of dependencies, which is
> build tools, utilities, and data followed by libraries.  Wrap and sort
> to me is not particularly useful.

It helps to see the logic being named.  However in my packaging work on
Wine I've really seen these reorganization changes so often (in d/rules
and other files like .install) and had to spend a lot of time in
comparing files, that I'd prefer a deterministic sorting to a rough
organization which changes over time.



>> [1] This time I just noticed you replaced the builddep "fontforge-nox |
>> fontforge" with "fontforge-nox".  This reverts something I did on
>> purpose when I implemented the font-rebuilding, so that for local
>> rebuilds fontforge-nox doesn't get pulled in unnecessarily if fontforge
>> is already installed.
> 
> That change is of course intentional.  It is my opinion that it is
> preferable to try to avoid potential sources of variance in builds.  A
> desire to reduce the number of installed packages for a build I think
> should not override that.

Ok.

Greets
jre

Bug#910974: utidylib: FTBFS with new tidy-html5 5.7.16: Build-dep list needs updating, test fails (upstream behaviour change)

[Boyuan Yang]

Source: utidylib
Severity: serious
Version: 0.3-1
X-Debbugs-CC: ni...@debian.org

Dear utidylib maintainers,

Currrent utidylib 0.3-1 is not compatible with new tidy-html5.
New tidy-html5 renamed libtidy5 to libtidy5.6, thus it is necessary to
add libtidy5.6 into build-dependency and dependency alternatives.

After fixing that, there is also another problem that lies in a test:

running build_ext
test_bad_options (tidy.test_tidy.TidyTestCase) ... ok
test_big (tidy.test_tidy.TidyTestCase) ... ok
test_encodings (tidy.test_tidy.TidyTestCase) ... ok
test_error_lines (tidy.test_tidy.TidyTestCase) ... ok
test_errors (tidy.test_tidy.TidyTestCase) ... ok
test_missing_load (tidy.test_tidy.TidyTestCase) ... ok
test_nonexisting (tidy.test_tidy.TidyTestCase) ... FAIL
test_options (tidy.test_tidy.TidyTestCase) ... ok
test_parse (tidy.test_tidy.TidyTestCase) ... ok
test_write (tidy.test_tidy.TidyTestCase) ... ok

==
FAIL: test_nonexisting (tidy.test_tidy.TidyTestCase)
--
Traceback (most recent call last):
  File "/<>/tidy/test_tidy.py", line 52, in test_nonexisting
self.assertEquals(str(doc), '')
AssertionError: '\n' != u''

Besides that assertion error, the following several lines would also
have assertion errors. I figured out that it was due to a behaviour
change introduced in tidy-html5 5.5.19 (ce105dcf) that upstream now
emits FILE_NOT_FILE message instead of FILE_CANT_OPEN when the input
file does not exist.

Please consider fixing the test suite to fit the behaviour of new
tidy-html5 or disable this test.

Thanks!

--
Regards,
Boyuan Yang

Bug#893852: lmms: Please package new version and migrate to Qt5

[Javier Serrano Polo]

This report is premature.

smime.p7s
Description: S/MIME cryptographic signature

Bug#870473: calf-ladspa: Conflicts with calf-plugins in ardour

[Javier Serrano Polo]

I fail to see how this is a bug from LMMS and not from Ardour.

smime.p7s
Description: S/MIME cryptographic signature

Bug#875038: [lmms] Future Qt4 removal from Buster

[Javier Serrano Polo]

On Fri, 23 Mar 2018 18:23:51 +0800 Boyuan Yang <073p...@gmail.com>
wrote:
> lmms 1.2.0 is on its way.

I will not package a candidate version unless this bug becomes serious.
Efforts should be directed in helping upstream to release a stable
version.

smime.p7s
Description: S/MIME cryptographic signature

Bug#889042: lintian: Do not use dot as a separator in build profile names

[Javier Serrano Polo]

El ds 13 de 10 de 2018 a les 08:52 +0100, Chris Lamb va escriure:
> I still do not understand your unnecessary antagonism towards me (or
> anyone) here,

I will not explain side issues here because this report is meant for
lintian.

smime.p7s
Description: S/MIME cryptographic signature

Bug#897806: lmms: ftbfs with GCC-8

[Javier Serrano Polo]

El ds 13 de 10 de 2018 a les 11:14 +, Holger Levsen va escriure:
> why don't you attach your fix to this bug?

Because I am the lazy maintainer.

smime.p7s
Description: S/MIME cryptographic signature

Bug#807553: Kannst du mir helfen?

[Mrs. Michelle Richard]

Lieber geliebter,

Bitte lesen Sie dies langsam und sorgfältig, da es eine der
wichtigsten E-Mails sein kann, die Sie jemals bekommen.Ich bin Frau
Michelle Richard, ich war mit dem verstorbenen Robert Richard
verheiratet.Er arbeitete früher mit Shell Petroleum Development
Company London und war auch ein erfahrene Auftragnehmer in der Region
Ostasien. Er starb am Montag, den 31. Juli 2003 in Paris. Wir waren
sieben Jahre ohne Kind verheiratet.

Während du das liest, will ich nicht, dass du Mitleid mit mir hast,
weil ich glaube, dass jeder irgendwann sterben wird. Ich wurde mit
Speiseröhrenkrebs diagnostiziert und mein Arzt sagte mir, dass ich
aufgrund meiner komplizierten Gesundheitsprobleme nicht lange
überleben würde.

Ich möchte, dass Gott mir gnädig ist und meine Seele akzeptiert, also
habe ich beschlossen, Wohltätigkeitsorganisationen / Kirchen /
Moscheen / mutterlosen Babys / Tempeln / weniger Privilegierten und
Witwen Almosen zu geben, so wie ich möchte, dass dies eine der letzten
guten Taten ist Ich mache es auf der Erde, bevor ich sterbe. Bis jetzt
habe ich Geld an einige Wohltätigkeitsorganisationen in Wales,
Kroatien, Polen und Italien verteilt. Jetzt wo sich meine Gesundheit
so stark verschlechtert hat, kann ich das nicht mehr selbst machen.

Ich habe einmal meine Familienangehörigen gebeten, eines meiner Konten
zu schließen und das Geld, das ich dort habe, an eine
Wohltätigkeitsorganisation in Österreich, der Schweiz, Deutschland,
den Niederlanden und Luxemburg zu verteilen, sie weigerten sich und
behielten das Geld für sich. Daher vertraue ich nicht sie mehr, als
sie scheinen, nicht mit dem bestraft zu werden, was ich für sie
verlassen habe. Das letzte Geld, das niemand kennt, ist die riesige
Barkaution von 6 Millionen US-Dollar, die ich bei einer Bank in
Thailand habe, wo ich den Fonds eingezahlt habe. Ich möchte, dass Sie
diesen Fonds für Wohltätigkeitsprogramme nutzen und die Menschen in
Ihrem Land unterstützen, wenn Sie nur aufrichtig sind.

Ich habe diese Entscheidung getroffen, weil ich kein Kind habe, das
dieses Geld erben würde, ich habe keine Angst vor dem Tod, daher weiß
ich, wohin ich gehe. Ich weiß, dass ich im Schoß des Herrn sein werde.
Sobald ich Ihre Antwort erhalten habe, gebe ich Ihnen den Kontakt zur
Bank und erteile Ihnen ein Vollmachtsschreiben, das Sie als
Erstbegünstigten dieses Fonds ermächtigt, dieses
Wohltätigkeitsprogramm sofort in Ihrem Land zu beginnen.

Ich möchte, dass Sie immer für mich beten. Jede Verzögerung Ihrer
Antwort wird mir Raum geben, eine andere Person für diesen Zweck zu
beschaftigen. Wenn Sie nicht interessiert sind, entschuldigen Sie
bitte, dass ich Sie kontaktiert habe. Sie erreichen mich mit oder
antworten Sie mir unter meiner privaten E-Mail:
(michellerich...@outlook.com).

Vielen Dank,
Dein,
Frau Michelle Richard
Email; michellerich...@outlook.com

Bug#910973: xul-ext-firetray: needs a minor version bump of dependency

[Adam Borowski]

Package: xul-ext-firetray
Version: 0.6.1+dfsg-1.1
Severity: grave
Tags: patch
Justification: renders package unusable

Alas, with the new thunderbird upload, the extension stopped working again. 
Fortunately, no code changes are needed, but the supported version still
needs updating.

The fix to #906852 I NMUed recently says:
60.0
which is no good for a point release of 60.

Alas, we can't bump the version too far, as Thunderbird's upstream debates
whether to drop XUL or not; it's likely they will as it's hard to support it
without help from Mozilla.  So far the last version reported to work is 62;
Debian doesn't upload non-LTS thunderbirds so this doesn't really matter. 
Still, it'd be good to declare future point releases of 62 as supported.

Thus, here's a patch that sets the maxVersion to 62..


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

Kernel: Linux 4.19.0-rc7-debug-00188-gbf54891e3ef1 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xul-ext-firetray depends on:
ii  thunderbird  1:60.2.1-1

Versions of packages xul-ext-firetray recommends:
pn  libappindicator3-1  

xul-ext-firetray suggests no packages.

-- no debconf information
Description: bump TB versions
 Current thunderbird in unstable, 60.2.1-1, already fails the version check.
 The newest reported version that Firetray works with is 62; let's use
 "62." then (no idea if there's some equivalent of ~ for Mozilla).
Author: Adam Borowski 

--- firetray-0.6.1+dfsg.orig/src/install.rdf
+++ firetray-0.6.1+dfsg/src/install.rdf
@@ -23,7 +23,7 @@
   
 {3550f703-e582-4d05-9a08-453d09bdfdc6}
 57.0
-60.0
+62.
   
 
 

Bug#868411: gniall: Port to GTK+ 3

[Jeremy Bicha]

Yavor,

I think it would be better for Debian for gnial to be removed from Debian.

It has only had one upload since 2004 and that was an NMU because
debhelper compat 2 isn't supported!

It doesn't separate Debian changes from upstream code with patches
which makes it really hard to decipher what was changed 15 years ago
and why.

The project's last upstream release was in 2000. One of those Debian
changes was to port it *to* GNOME 2.

I apologize for the time you spent working on this package. Please let
me know what you think we should do here.

Thanks,
Jeremy Bicha

Bug#909990: Stange import error for nibabel when trying to import from .pybuild

[Yaroslav Halchenko]

On Sat, 13 Oct 2018, Andreas Tille wrote:

> On Fri, Oct 12, 2018 at 09:15:37AM -0400, Yaroslav Halchenko wrote:
> > > ok... will merge for the next upload to proceed -- we mitigated all
> > > known issues, and the beast builds fine all the way down to jessie, so
> > > release is coming soon now

> > oi... I guess we caused you confusion and unneeded work???

> Urgs, yes! While I for sure need to blame myself that I missed to check
> the diff between repository and uploads, your naming of branches is
> irritating.

> > I see that you updated debian branch redoing packaging for 2.3.0-1 which was
> > uploaded already awhile back, while we use this ad-hoc dist/debian/proper
> > branch (should be the default when you clone that repo):

> Could you imagine to use a branch named debian?  In my attempt to update
> packages mentioned in Debian Med tasks which are not uploaded for a long
> time and need fixing Vcs fields (and usually lots of lintian issues) I
> migrated pyepl to the "kind of usual" repository layout.  Do you have
> some tools that are relying on those unusual names (= did I broke
> something when renaming dist/debian/proper to debian in pyepl)?

> > $> grep Vcs-Git debian/control
> > Vcs-Git: https://salsa.debian.org/neurodebian-team/pynifti.git -b 
> > dist/debian/proper

> > so not yet sure how to proceed with your changes. meanwhile pushed my local
> > state of dist/debian/proper

> I'd volunteer to check the diff between your current changes and my work
> and merge everything - but can I please use a branch named debian? 

quick one:  well, the main confusion stems from that fact that
originally it was pynifti project and there is still that debian branch
for its packaging, which I thought would be the one up to date with

$> apt-cache policy python-nifti
python-nifti:
  Installed: (none)
  Candidate: 0.20100607.1-4.1
  Version table:
 0.20100607.1-4.1 600
100 http://http.debian.net/debian stretch/main amd64 Packages
600 http://http.debian.net/debian sid/main amd64 Packages
 0.20100607.1-4~nd70+1+nd90+1 500
500 http://neuro.debian.net/debian stretch/main amd64 Packages

but now I don't know -- locally it is stuck somewhere in 2009.  So, sure
-- could be 'debian' for what I care

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#910942: [wine-development] Please use wrap-and-sort

[Michael Gilbert]

On Sat, Oct 13, 2018 at 12:39 PM Jens Reyer wrote:
> To avoid these issues I suggest to use
>
>   wrap-and-sort --wrap-always --short-indent --trailing-comma

Hi Jens,

Welcome back!

Wrap and sort is itself the original source of the extra diff being
seen and will continue to be in the future.  I would prefer to
maintain the original rough organization of dependencies, which is
build tools, utilities, and data followed by libraries.  Wrap and sort
to me is not particularly useful.

> [1] This time I just noticed you replaced the builddep "fontforge-nox |
> fontforge" with "fontforge-nox".  This reverts something I did on
> purpose when I implemented the font-rebuilding, so that for local
> rebuilds fontforge-nox doesn't get pulled in unnecessarily if fontforge
> is already installed.

That change is of course intentional.  It is my opinion that it is
preferable to try to avoid potential sources of variance in builds.  A
desire to reduce the number of installed packages for a build I think
should not override that.

Best wishes,
Mike

Bug#910941: apt-get changelog uses insecure HTTP for Debian

[David Kalnischkies]

Control: clone -1 -2
Control: severity -1 wishlist
Control: reassign -2 ftp.debian.org

On Sat, Oct 13, 2018 at 05:06:37PM +0100, Ben Hutchings wrote:
> The default value of Acquire::Changelogs::URI::Origin::Debian is
> "http://metadata.ftp-master.debian.org/changelogs/@CHANGEPATH@_changelog;.

Note that this value is not used as long as the Release file contains
a Changelogs: field – which has the same value ATM.

So, for your local setup you will need:
Acquire::Changelogs::URI::Override::Origin::Debian 
"tor+http://cmgvqnxjoiqthvrc.onion/changelogs/@CHANGEPATH@_changelog;;
(expect, in your case https instead of tor and hidden service of course)

That is so that any repository can provide changelogs for its packages –
and that the URI can be changed without changing apt which has happened
historically a few times before this mechanism was introduced ~3 years
ago.


> Since metadata.ftp-master.debian.org supports HTTP-S and redirects to
> the https: scheme, the URL should be changed to use it from the start.

I think the apt client is exempt from such an automatic redirect.
The "reason" is that apt < 1.5 has no built-in support for https and needs
apt-transport-https installed.

Changing that value now means that changelog wont work for stable users
anymore who are trying to access newer Debian releases as long as they
haven't a-t-https installed – but that might be acceptable.
On the other hand we could drop the entry in the Release file for now so
that stable uses http and we change apt/unstable to use https… decisions
decisions, but that is for ftp/dakmasters to worry about. ;)


Sadly, I haven't thought about allowing this field to be multiline to
give multiple URIs – then again, it might be for the best as that would
turn complicated fast.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#910819: dpkg: ../../src/packages.c:245: process_queue: Assertion `dependtry <= 4' failed

[Guillem Jover]

Hi!

On Thu, 2018-10-11 at 19:56:46 +0200, Holger Levsen wrote:
> Package: dpkg
> Version: 1.18.25
> Severity: important

> on June 28th 2018 was the last successful test of
> https://jenkins.debian.net/job/chroot-installation_stretch_install_education-mathematics_upgrade_to_buster/
> which tests the installation of the education-mathmatics meta-package on
> a clean stretch install (in a chroot) and then upgrades this chroot to
> buster. Since July 7th 2018 this test is failing...
> 
> As I read
> https://jenkins.debian.net/job/chroot-installation_stretch_install_education-mathematics_upgrade_to_buster/35/consoleFull
> the upgrade is done using dpkg 1.8.25, however I'm not fully sure the
> bug is coming from dpkg...
> 
> The failure is (happening when upgrading packages to buster):
> 
> Setting up kalgebra (4:17.08.3-2) ...
> dpkg: ../../src/packages.c:245: process_queue: Assertion `dependtry <= 4' 
> failed.
> E: Sub-process /usr/bin/dpkg exited unexpectedly
> 
> Feedback much appreciated as I'm lost here. Also maybe this bug should
> have severity 'serious' as it breaks upgrades to Buster?!?

Just in case this is helpful in the future, I've reproduced this now,
by using in addition:

  ,--- /etc/dpkg/dpkg.cfg.d/00db-git ---
  post-invoke "cd /var/lib/dpkg && git add -A && git commit -m 'Committing dpkg 
db to git' || true"
  `---

  ,--- /etc/dpkg/dpkg.cfg.d/01debug ---
  debug 7
  `---

And an initial:

  $ cd /var/lib/dpkg
  $ git init
  $ git add -A
  $ git commit -m 'Initial import'

Then, first, there's a bug (normal probably) in dpkg with the
assert/internal-error, which should be a proper error message, this
needs to be fixed, and I think there's one or two bugs about just that.
Then, the current reporting in the buster internal error message still
sucks, so I'll try to improve that too, to:

  - Print the current processed package and in the ones in the queue.
  - Print the command-line options used to invoke dpkg, or at least
the state of the --[no-]triggers option, and whether we were
called with a --pending or an explicit list of packages.
  - Recommend running «dpkg --audit» and attaching that too, while
reporting the problem.

But in any case the real cause for this seem to be just the usual trigger
cycle problem (serious, for the offending cycle introducer), that gets
abandoned and resets the state of dbus, which is never tried to get
configure again, as specified.

The trigger happens with this:

  ,---
  […]
  D01: process queue pkg gconf2:amd64 queue.len 168 progress 53, try 2
  D01: trigproc gconf2:amd64
  D01: check_triggers_cycle pnow=gconf2:amd64
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=dbus
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=dbus 
tortoisetrig=/etc/dbus-1/system.d
  D04: tortoise_not_in_hare pnow=gconf2 tortoise=dbus 
tortoisetrig=/etc/dbus-1/system.d haretrig=/etc/dbus-1/system.d
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=shared-mime-info
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=shared-mime-info 
tortoisetrig=/usr/share/mime/packages
  D04: tortoise_not_in_hare pnow=gconf2 tortoise=shared-mime-info 
tortoisetrig=/usr/share/mime/packages haretrig=/usr/share/mime/packages
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=libvlc-bin:amd64
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=libvlc-bin:amd64 
tortoisetrig=/usr/lib/x86_64-linux-gnu/vlc/plugins
  D04: tortoise_not_in_hare pnow=gconf2 tortoise=libvlc-bin:amd64 
tortoisetrig=/usr/lib/x86_64-linux-gnu/vlc/plugins 
haretrig=/usr/lib/x86_64-linux-gnu/vlc/plugins
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=libc-bin
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=libc-bin 
tortoisetrig=ldconfig
  D04: tortoise_not_in_hare pnow=gconf2 tortoise=libc-bin 
tortoisetrig=ldconfig haretrig=ldconfig
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=dictionaries-common
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=dictionaries-common 
tortoisetrig=aspell-autobuildhash
  D04: tortoise_not_in_hare pnow=gconf2 tortoise=dictionaries-common 
tortoisetrig=aspell-autobuildhash haretrig=aspell-autobuildhash
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=gconf2
  D02: tortoise_not_in_hare pnow=gconf2 tortoise=gconf2 
tortoisetrig=/usr/share/gconf/schemas
  D04: tortoise_not_in_hare pnow=gconf2 tortoise=gconf2 
tortoisetrig=/usr/share/gconf/schemas haretrig=/usr/share/gconf/schemas
  dpkg: cycle found while processing triggers:
   chain of packages whose triggers are or may be responsible:
shared-mime-info -> gconf2
   packages' pending triggers which are or may be unresolvable:
dbus: /etc/dbus-1/system.d
shared-mime-info: /usr/share/mime/packages
libvlc-bin:amd64: /usr/lib/x86_64-linux-gnu/vlc/plugins
libc-bin: ldconfig
dictionaries-common: aspell-autobuildhash
gconf2: /usr/share/gconf/schemas
  D01: check_triggers_cycle pnow=gconf2:amd64 giveup=dbus:amd64
  dpkg: error 

Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils

[Andreas Henriksson]

Just one more thing 

On Sun, Oct 14, 2018 at 01:13:28AM +0200, Andreas Henriksson wrote:
> On Sat, Oct 13, 2018 at 06:28:03PM -0400, Muammar El Khatib wrote:
> > Is that what you meant? If that is correct, then I think that the
> > package `mkchromecast` does not have to be provided at all.

If you go with "the -common way" then yes... eventually!
You will still need to provide an upgrade path for current users,
so for atleast 1 debian release you would need to have a transitional
mkchromecast package that simply depends on mkchromecast-common.

This is another reason I would not go with "the -common way", but
rather the alternative in the patch (or the third option).

Regards,
Andreas Henriksson

Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils

[Andreas Henriksson]

On Sat, Oct 13, 2018 at 06:28:03PM -0400, Muammar El Khatib wrote:
> On Fri, Oct 12, 2018 at 4:13 AM Andreas Henriksson  wrote:
[...]
> > Normally I find that the main package (mkchromecast here) instead has
> > alternative dependency on the different backends, eg. mkchromecast would:
> > Depends: mkchromecast-pulseaudio | mkchromecast-alsa | 
> > mkchromecast-gstreamer
> >
> > (Or in which ever order you prefer, listing the recommended and best
> > supported backend as the first alternative.)
> >
> > (And to avoid circular dependencies, the mkchromecast-* package would
> > have to drop or demote the Dependency on mkchromecast to a Recommends.)
> >
> > This way the users can just pull the package named after the program and
> > end up having the recommeded backend pulled in for them.
[...]



> Your explanation makes lots of sense for me. Just to clarify this layout:
> 
> 1) mkchromecast-common would contain all needed files to make things
> functional meaning the python module itself and things in /usr/bin/.

Yes (except -common packages usually don't ship /usr/bin things).
This basically means renaming the current mkchromecast package
to mkchromecast-common.

> 2) There will be other mkchromecast-* packages e.g.:
> mkchromecast-pulseaudio; mkchromecast-alsa, and mkchromecast-gstreamer
> and those ones will pull out dependencies to make the package work for
> each of those audio servers.  Basically, instead of doing an `apt
> install mkchromecast`, users would need to do `apt install
> mkchromecast-something`.

Yes, isn't that what you already expect them to do?

> 
> Is that what you meant? If that is correct, then I think that the
> package `mkchromecast` does not have to be provided at all. I would
> like just to confirm these things before I go and change the
> packaging.

As I tried to explain before, but probably confused you with by
mentioning two different ways in the same mail. I think "the -common
way" (discussed above) is not the preferred way though. The alternative
would be like the attached patch does (untested, but hopefully it should
show my thinking). It implements the way I quoted at the top of this
mail from my previous mail and has the following advantages over "the
-common way":

- you can install from either direction. Doing 'apt install
  mkchromecast' gives the uninformed user a nice setup, and the
  picky informed people can still do 'apt install mkchromecast-alsa'
  to get a particular set.
- this is much more in line with how most other packages does it.
- you don't have to go through NEW queue because of renamed packages.


Having said that, I think there's a third option here as well. Since
mkchromecast-* seems to just be meta-packages that for many users seems
to add more confusion than they help. The third option would thus simply
be to get rid off all -* packages (removing packages doesn't need NEW
either) and simply listing all pulseaudio/alsa pieces under Recommends
on the main (and only) mkchromecast binary package. That way people get
all choices and functionality by default, but people who want a slimmer
install and are informed can skip installing the pieces they don't want.
This would actually be probably the most in line with debian policy and
how most other packages does it.

Hope this helps.

Regards,
Andreas Henriksson
diff -uriNp mkchromecast-0.3.8.1/debian/control mkchromecast-0.3.8.1.patched/debian/control
--- mkchromecast-0.3.8.1/debian/control	2017-12-24 15:29:49.0 +0100
+++ mkchromecast-0.3.8.1.patched/debian/control	2018-10-14 01:00:07.010435210 +0200
@@ -27,11 +27,10 @@ Depends: ${python3:Depends},
  opus-tools,
  youtube-dl,
  nodejs,
- gir1.2-notify-0.7
+ gir1.2-notify-0.7,
+ mkchromecast-pulseaudio | mkchromecast-alsa | mkchromecast-gstreamer
 Suggests: libav-tools,
-  ffmpeg,
-  mkchromecast-pulseaudio,
-  mkchromecast-alsa
+  ffmpeg
 Description: Cast your Linux audio or video to your Google Cast devices
  It is written in Python, and it streams via node.js, ffmpeg, or avconv.
  mkchromecast is capable of using lossy and lossless audio formats provided
@@ -57,8 +56,8 @@ Depends: ${python3:Depends},
  ${misc:Depends},
  pavucontrol,
  pulseaudio-utils,
- pulseaudio,
- mkchromecast
+ pulseaudio
+Recommends: mkchromecast
 Description: Pulseaudio dependencies to cast with mkchromecast
  This dependency package contains an informational list of packages which are
  considered essential for using mkchromecast together with pulseaudio sound
@@ -71,8 +70,8 @@ Depends: ${python3:Depends},
  alsa-utils,
  alsa-tools,
  kmod,
- ffmpeg,
- mkchromecast
+ ffmpeg
+Recommends: mkchromecast
 Description: ALSA dependencies to cast with mkchromecast
  This dependency package contains an informational list of packages which are
  considered essential for using mkchromecast together with 

Bug#887794: New version of MusE

[Tim]

On 10/13/2018 05:51 PM, Nicholas D Steeves wrote:

Control: block 875049 853565 by -1
Control: severity -1 important

Moving thread from pkg-multimedia-maintain...@alioth-lists.debian.net
to this bug report (it will be CCed to the mailing list).

Hi Tim,

On Sat, Oct 13, 2018 at 04:38:29PM -0400, Tim wrote:

Hello, I am a primary developer of MusE.
We're getting requests for a new deb package.
We released source version 3.0.2 early 2018.


At this time no version of Muse will included in Debian 10 (buster)
due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853565

Would you please confirm that the GCC-7 failure to build from source
is fixed in muse-3.0.2 at bug #853565?


Yes, confirmed fixed in 3.0.2 source, the two stoppages
 that I can see listed in 853565 have been fixed:

/<>/muse/ctrl/ctrlcanvas.cpp:575:9: warning: 'n' may be 
used uninitialized in this function [-Wmaybe-uninitialized]

 if(i->second->num() == n)
 ^~
/<>/muse/ctrl/ctrlcanvas.cpp:525:25: warning: 'mp' may be 
used uninitialized in this function [-Wmaybe-uninitialized]

 MusECore::MidiPort* mp;

We now initialize n to zero and mp to NULL in version 3.0.2



Additionally, it would also be nice to have a comment about the status
of the QT5 port at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875049


No problem, we went all Qt5 quite a while ago, there shouldn't
 be any trouble with Qt5, nor any Qt4 dependencies.



There is a request to Debian in January to update
  to the newer version:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887794

I can see is that it is being 'watched':
https://qa.debian.org/cgi-bin/watch?pkg=muse


Thank you for reaching out, I can understand how frustrating it must
be for the Debian package to not reflect the last year of work.  Great
timing, by the way!  Now is the time to fix these issues for the next
Debian release. :-)


Although I was an experienced .spec file and RPM maker
  years ago, I know absolutely nothing about making
  Debian packages.


Getting up to speed with Debian packaging requires reading more than
for RPMs, (eg: Debian Policy, plus other resources like New
Maintainers Guide or Debian Packaging Tutorial) and I'd be happy to
furnish links to this material.  That said, there's no need to learn
how to build a package from scratch when one already exists.

Options:  1. Wait for someone to fix the package, or
   2. Set up a Debian development environment and
  a) Fork https://salsa.debian.org/multimedia-team/muse
 and submit your changes as a merge request, or
  b) Join the Debian Multimedia Team.


But I am highly active in MusE's development.
I am usually available for quick response.

We'd like to see a new deb package for users.
Anything you need us to do - questions, fixes,
  you name it, just ask!


I've bumped the priority of this new version bug and blocked two
others, because I think everyone will agree that this is the best way
forward.  Unfortunately I am swamped with work until sometime in early
November.  I hope that someone else can work on this asap, just in
case any issues emerge, because it sounds like you're on call to be
able to help out :-)

Cheers!
Nicholas


Thank you much for the quick reply.
Hopefully MusE can move forward now.

I know the best would be for us to at least try to make a package
 and propose it so you could look at it. If I get up the nerve
 to try I will certainly submit one but it might be quite a while.
I am examining the existing package now.

PS: If this helps: Some RPM packagers contacted us because the
 packagers wanted to use -no-undefined linker flag.
But this also requires our own cmake -DMODULES_BUILD_STATIC flag,
 be sure to include that flag if -no-undefined is desired.
With those flags given, there were a lot of errors at the time
 but they were fixed as of 28.01.2018, thankfully
 included in release 3.0.2.

There are exciting and important changes in MusE,
 and much more in git master on the way, but we're
 pretty slow with releases. Due for a new release soon :-)

Tim.

Bug#881748: (no subject)

[Amy Wrigley]

Recently found the same issue with version 4:17.12.3-1 on testing as 
well. As far as I can tell this wasn't happening with 4:17.08.3-1, at 
least for me. Akregator crashes with a segmentation fault immediately 
upon starting. KDE Plasma catches the crash and offers to report but 
says the generated crash data is not useful.

Bug#885051: pdfmod: Drop unnecessary Build-Depend on libgnome2.0-cil-dev

[Jeremy Bicha]

Control: tags -1 +pending

On Sat, Jan 27, 2018 at 9:10 PM Jeremy Bicha  wrote:
> There was a typo in my second patch.
>
> I have imported my corrected patches to
>
> https://salsa.debian.org/jbicha/pdfmod

I submitted a merge request and uploaded my work as an NMU to the
DELAYED/2 queue.

https://salsa.debian.org/dotnet-team/pdfmod/merge_requests/1

Thanks,
Jeremy Bicha

Bug#910971: fails to connect to irc server with no indication why

[Joey Hess]

Package: kgb-bot
Version: 1.52-1
Severity: normal

My kgb bot fell off of all three irc servers it was connecting to a while back,
and this is all there is in the log (with debug=1)

2018.10.13 22:35:22: 1063: irc_connected 'irc.oftc.net' 
2018.10.13 22:35:22: 1063: irc_raw_out 'CAP REQ :identify-msg' 
2018.10.13 22:35:22: 1063: irc_raw_out 'CAP REQ :multi-prefix' 
2018.10.13 22:35:22: 1063: irc_raw_out 'CAP LS' 
2018.10.13 22:35:22: 1063: irc_raw_out 'CAP END' 
2018.10.13 22:35:22: 1063: irc_raw_out 'NICK KGB-k' 
2018.10.13 22:35:22: 1063: irc_disconnected 'irc.oftc.net' {} {} 

I don't have any difficulty connecting to the irc server from the same host
manually, and it seems to be failing before it identifies so not a password 
problem.
The lack of any indication what happened makes it hard to fix if it's a
configuration problem.

Aha, looking at the changelog, it seems that use_ssl was added and defaults to 
1,
and apparently it fails to connect over ssl for whatever reason, and this is the
result. This config change warrants mention in NEWS at least, and if there's
a ssl error, it ought to show it in the log.

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

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

Versions of packages kgb-bot depends on:
ii  adduser3.118
ii  git1:2.19.1-1
ii  kgb-client 1.52-1
ii  libipc-run-perl20180523.0-1
ii  libjson-xs-perl3.040-1
ii  libmonkey-patch-perl   0.03-2
ii  libnet-ip-perl 1.26-2
ii  libpoe-component-irc-perl  6.90+dfsg-1
ii  libpoe-component-server-soap-perl  1.14-2
ii  libpoe-component-sslify-perl   1.012-1
ii  libpoe-perl2:1.3670-2
ii  libproc-pid-file-perl  1.27-4
ii  libschedule-ratelimiter-perl   0.01-2
ii  libyaml-perl   1.26-1
ii  lsb-base   9.20170808
ii  perl   5.26.2-7+b1

kgb-bot recommends no packages.

Versions of packages kgb-bot suggests:
ii  libfile-which-perl  1.22-1
pn  polygen 

-- Configuration Files:
/etc/default/kgb-bot changed [not included]
/etc/kgb-bot/kgb.conf [Errno 13] Permission denied: '/etc/kgb-bot/kgb.conf'

-- no debconf information

-- 
see shy jo

Bug#910946: [Pkg-xen-devel] Bug#910946: xen-hypervisor-4.11-amd64: HVM DomU - 64-bit kernel cannot access emulated ATA devices

[Stephen Oberholtzer]

On Sat, Oct 13, 2018 at 5:44 PM Hans van Kranenburg 
wrote:

> 19:35 < andyhhp__> Stevie-O: Thats most likely a dom0 kernel bug
> 19:35 < andyhhp__> the 32 and 64bit block protocols were binarily
> diverged for a while due to some "interesing" bugfixes
> 19:36 < andyhhp__> but its the most common cause of "32bit works, 64bit
> doesn't" when it comes to anything vaguely like disks
>
>

> Since the comments from Andrew point at at least the dom0 kernel version
> being a factor in this equation: can you also add linux kernel version
> information for dom0 and domU for your tests? These kind of things
> explode into a testing-matrix of combinations of things very fast, and
> any testing you can do providing that info will help other people
> helping you narrowing down the issue.
>
>
Certainly!

The dom0 is 4.18.6.  It is a custom-built version of the
linux-image-4.18.6, with xen_pciback compiled-in (instead of being a
module.)

The domU kernels are whatever on the CD-ROMs images. The host is shut down
at the moment, but I can get those tonight or tomorrow if it's really
important.

However, I disagree with andyhhp's assessment with regard to 32-bit/64-bit
protocols: these are virtual CD-ROMs, which are not PV block devices, but
fully-emulated hardware.
They speak the ATAPI protocol, which does not change based on the bitness
of the kernel running inside the VM.
The failure is happening when the domU kernel sends an IDENTIFY DEVICE
command to find out what type of drive it is.  Since that doesn't involve
anything in dom0 (optical drives exist separately and independently from
the media inside the drives), the dom0 kernel shouldn't be getting involved
at all.

(I would very much like more information on those 'interesting bugfixes'
that affect 32/64 compatibility, however.)

-- 
-- Stevie-O
Real programmers use COPY CON PROGRAM.EXE

Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils

[Muammar El Khatib]

Hi,

On Fri, Oct 12, 2018 at 4:13 AM Andreas Henriksson  wrote:
>
> Hi,
>
> Chiming in here because I'd like to just suggest an alternative
> that might be more in line with how other packages are layed out
> and thus how users might expect things to work.
>
> On Thu, Oct 11, 2018 at 04:24:16PM -0400, Muammar El Khatib wrote:
> > On Sat, Sep 29, 2018 at 3:33 AM Ruben Undheim
> >  wrote:
> [...]
> > > I get an error saying 'pactl' cannot be found when
> > > starting. Solved it by installing pulseaudio-utils.
> > >
> >
> > The package suggests mkchromecast-pulseaudio:
> [...]
>
> I think I understand how you layed out the package.
> You expect the user to pick a particular special version that suits
> their needs from mkchromecast-* and install that. Then that pulls in the
> common (mkchromecast) package.
>
> If a package has the bulk of the program, but users are not expected to
> directly install it but rather have it pulled in via a dependency then
> usually the package name gets a -common postfix, ie. in your current
> layout you could have named mkchromecast mkchromecast-common instead.
>
> Going back a bit and looking at the bigger picture again I find your
> current layout not how packages in debian normally are layed out.
> Normally I find that the main package (mkchromecast here) instead has
> alternative dependency on the different backends, eg. mkchromecast would:
> Depends: mkchromecast-pulseaudio | mkchromecast-alsa | mkchromecast-gstreamer
>
> (Or in which ever order you prefer, listing the recommended and best
> supported backend as the first alternative.)
>
> (And to avoid circular dependencies, the mkchromecast-* package would
> have to drop or demote the Dependency on mkchromecast to a Recommends.)
>
> This way the users can just pull the package named after the program and
> end up having the recommeded backend pulled in for them.
>
> With this package layout you avoid ever having an uninformed user
> ending up with installing a package and having it 'not working'.
> If they install mkchromecast they get the recommended backend with it.
> If they install a particular mkchromecast-* the recommends will pull
> in the mkchromecast package. (And if they disable installing recommends
> then they are expected to pay attention or they get to keep all their
> broken pieces. eg. apt install mkchromecast mkchromecast-gstreamer would
> given them the non-default backend without pulling in the
> recommended/first alternative dependency.)
>

Your explanation makes lots of sense for me. Just to clarify this layout:

1) mkchromecast-common would contain all needed files to make things
functional meaning the python module itself and things in /usr/bin/.
2) There will be other mkchromecast-* packages e.g.:
mkchromecast-pulseaudio; mkchromecast-alsa, and mkchromecast-gstreamer
and those ones will pull out dependencies to make the package work for
each of those audio servers.  Basically, instead of doing an `apt
install mkchromecast`, users would need to do `apt install
mkchromecast-something`.

Is that what you meant? If that is correct, then I think that the
package `mkchromecast` does not have to be provided at all. I would
like just to confirm these things before I go and change the
packaging.

Thanks for this idea Andreas.

Best,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#910970: flameshot: does not work on debian buster under wayland

[Karl Kashofer]

Package: flameshot
Version: 0.6.0-4
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
fails to to start:

karl@karl-acer2:~$ flameshot
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
QT_QPA_PLATFORM=wayland to run on Wayland anyway.
karl@karl-acer2:~$ QT_QPA_PLATFORM=wayland flameshot
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be
initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen,
vnc, xcb.

Abgebrochen
karl@karl-acer2:~$




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

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

Versions of packages flameshot depends on:
ii  libc6   2.27-6
ii  libgcc1 1:8.2.0-7
ii  libqt5core5a5.11.1+dfsg-9
ii  libqt5dbus5 5.11.1+dfsg-9
ii  libqt5gui5  5.11.1+dfsg-9
ii  libqt5network5  5.11.1+dfsg-9
ii  libqt5widgets5  5.11.1+dfsg-9
ii  libstdc++6  8.2.0-7

flameshot recommends no packages.

Versions of packages flameshot suggests:
ii  ca-certificates  20170717
ii  openssl  1.1.0h-4

-- no debconf information

Bug#771000: looptools: no documentation

[Gürkan Myczko]

Hi Dmitry

I have an updated package here, with documentation, feel free to try:
dget http://sid.ethz.ch/debian/looptools/looptools_2.15-1.dsc
dpkg-source -x *.dsc
cd loop*/
debuild
cd ..
dpgk -i the.deb # you want

Regards,

Bug#910969: stretch-pu: package firmware-nonfree/20161130-4

[Ben Hutchings]

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

This update addresses three sets of bugs:

- The firmware-{adi,ralink} pckages were supposed to be replaced by
  firmware-misc-nonfree between jessie and stretch, but I failed to
  include transitional packages to make this work (#907320).

- Security vulnerabilities in packet processing in Broadcom wifi
  firmware (CVE-2016-0801, CVE-2017-0561, CVE-2017-9417, #869639,
  a.k.a. "Broadpwn").

- Security vulnerabilities in WPA2 key handling in Broadcom wifi
  firmware (CVE-2017-13077, CVE-2017-13078, CVE-2017-13079,
  CVE-2017-13080, CVE-2017-13081, a.k.a. "KRACK").

(The security vulnerabilities went unfixed for a long time so it
doesn't make much difference if the fixes wait for the next point
release.)

The following source diff excludes generated files debian/control,
debian/firmware-*.copyright, and debian/rules.gen.

Ben.

---
diff --git a/debian/bin/gencontrol.py b/debian/bin/gencontrol.py
index 491bbe329c54..b087b7e602d5 100755
--- a/debian/bin/gencontrol.py
+++ b/debian/bin/gencontrol.py
@@ -1,9 +1,10 @@
 #!/usr/bin/env python3
 
-import os, re, sys, codecs
+import os, re, sys, locale
 
 sys.path.insert(0, "debian/lib/python")
 sys.path.append(sys.argv[1] + "/lib/python")
+locale.setlocale(locale.LC_CTYPE, "C.UTF-8")
 
 from config import Config
 from debian_linux.debian import Package, PackageRelation
@@ -92,7 +93,7 @@ Package._fields['Description'] = PackageDescription
 for dir in self.dirs:
 filename = "%s/%s.in" % (dir, name)
 if os.path.exists(filename):
-f = codecs.open(filename, 'r', 'utf-8')
+f = open(filename, 'r')
 if prefix == 'control':
 return read_control(f)
 elif prefix == 'templates':
@@ -145,7 +146,7 @@ Package._fields['Description'] = PackageDescription
 makefile = Makefile()
 
 self.do_source(packages)
-self.do_meta(packages, makefile)
+self.do_extra(packages, makefile)
 self.do_main(packages, makefile)
 
 self.write(packages, makefile)
@@ -154,17 +155,17 @@ Package._fields['Description'] = PackageDescription
 source = self.templates["control.source"]
 packages['source'] = self.process_package(source[0], ())
 
-def do_meta(self, packages, makefile):
+def do_extra(self, packages, makefile):
 config_entry = self.config['base',]
 vars = {}
 vars.update(config_entry)
 
-for entry in self.templates["control.binary.meta"]:
+for entry in self.templates["control.extra"]:
 package_binary = self.process_package(entry, {})
 assert package_binary['Package'].startswith('firmware-')
 package = package_binary['Package'].replace('firmware-', '')
 
-f = open('debian/copyright.meta')
+f = open('debian/copyright.debian')
 open("debian/firmware-%s.copyright" % package, 'w').write(f.read())
 
 makeflags = MakeFlags()
@@ -203,8 +204,8 @@ Package._fields['Description'] = PackageDescription
 f = open('%s/copyright' % package_dir)
 open("debian/firmware-%s.copyright" % package, 'w').write(f.read())
 else:
-vars['license'] = codecs.open("%s/LICENSE" % package_dir, 'r', 
'utf-8').read()
-codecs.open("debian/firmware-%s.copyright" % package, 'w', 
'utf-8').write(self.substitute(copyright, vars))
+vars['license'] = open("%s/LICENSE" % package_dir, 'r').read()
+open("debian/firmware-%s.copyright" % package, 
'w').write(self.substitute(copyright, vars))
 
 try:
 os.unlink('debian/firmware-%s.bug-presubj' % package)
@@ -308,19 +309,19 @@ Package._fields['Description'] = PackageDescription
 
 if 'initramfs-tools' in config_entry.get('support', []):
 postinst = self.templates['postinst.initramfs-tools']
-codecs.open("debian/firmware-%s.postinst" % package, 'w', 
'utf-8').write(self.substitute(postinst, vars))
+open("debian/firmware-%s.postinst" % package, 
'w').write(self.substitute(postinst, vars))
 
 if 'license-accept' in config_entry:
-license = codecs.open("%s/LICENSE.install" % package_dir, 'r', 
'utf-8').read()
+license = open("%s/LICENSE.install" % package_dir, 'r').read()
 preinst = self.templates['preinst.license']
 preinst_filename = "debian/firmware-%s.preinst" % package
-codecs.open(preinst_filename, 'w', 
'utf-8').write(self.substitute(preinst, vars))
+open(preinst_filename, 'w').write(self.substitute(preinst, vars))
 
 templates = 
self.process_templates(self.templates['templates.license'], vars)
 license_split = re.split(r'\n\s*\n', license)
 templates[0]['Description'].extend(license_split)
 

Bug#910837: RFS: mle/1.2-1 [ITP] -- flexible terminal-based text editor (C)

[as]

Hi Mo,

Thanks for the info.

> 1. Can we avoid shipping with embedded code copy[1] of lua, termbox and
>uthash? . lua 5.3 and uthash are already in the archive. termbox needs
>to be packaged.

Yes, I can make Lua and uthash package deps instead of embedding them.
Is it ok to embed termbox for now, or should we consider that a
blocker?

There is a packaging branch in the main repo by the way:
https://github.com/adsr/mle/tree/debian

Thanks for the tip about the "Recommends" field. I will add optional
runtime deps there.

Adam

On Fri, 12 Oct 2018 04:50:12 + Mo Zhou  wrote:
> Hi Adam,
>
> Thanks for this package, the copyright file looks good to me.
> However there are still a couple of problems:
>
> 1. Can we avoid shipping with embedded code copy[1] of lua, termbox and
>uthash? . lua 5.3 and uthash are already in the archive. termbox needs
>to be packaged.
>
> 2. I'd recommend you to create a packaging repo so that the others can
>track the changes about packaging with git. Since you are also the
>upstream author, it's fine if you set the source format as
>"3.0 (native)" and push the debian directory to the upstream git repo.
>A separate git repo following e.g. the gbp-buildpackage workflow is
>also acceptable. No packaging repo is fine too but not encouraged.
>
> 3. External tools such as fzf can be leveraged by mle to enhance
>features. That means those packages should be listed in the
>"Recommends" or "Suggests" fields.
>
> Best.
>
> [1] https://wiki.debian.org/EmbeddedCodeCopies
>
> On Thu, Oct 11, 2018 at 08:04:33PM -0400, Adam Saponara wrote:
> > Package: sponsorship-requests
> > Severity: wishlist
> >
> > Dear mentors,
> >
> > I am looking for a sponsor for my package "mle":
> >
> >   Package name: mle
> >   Version : 1.2-1
> >   Upstream Author : Adam Saponara 
> >   URL : https://github.com/adsr/mle
> >   License : Apache, Expat, BSD-1-clause
> >   Section : editors
> >
> > It builds those binary packages:
> >
> >   mle - flexible terminal-based text editor (C)
> >
> > To access further information about this package, please visit the 
> > following URL:
> >
> >   https://mentors.debian.net/package/mle
> >
> > Alternatively, one can download the package with dget using this command:
> >
> >   dget -x https://mentors.debian.net/debian/pool/main/m/mle/mle_1.2-1.dsc
> >
> > More information about hello can be obtained from 
> > https://github.com/adsr/mle.
> >
> > Changes since the last upload: -
> >
> > Regards,
> >
> > Adam
> >
>

Bug#887794: New version of MusE

[Nicholas D Steeves]

Control: block 875049 853565 by -1
Control: severity -1 important

Moving thread from pkg-multimedia-maintain...@alioth-lists.debian.net
to this bug report (it will be CCed to the mailing list).

Hi Tim,

On Sat, Oct 13, 2018 at 04:38:29PM -0400, Tim wrote:
> Hello, I am a primary developer of MusE.
> We're getting requests for a new deb package.
> We released source version 3.0.2 early 2018.

At this time no version of Muse will included in Debian 10 (buster)
due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853565

Would you please confirm that the GCC-7 failure to build from source
is fixed in muse-3.0.2 at bug #853565?

Additionally, it would also be nice to have a comment about the status
of the QT5 port at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875049

> There is a request to Debian in January to update
>  to the newer version:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887794
> 
> I can see is that it is being 'watched':
> https://qa.debian.org/cgi-bin/watch?pkg=muse

Thank you for reaching out, I can understand how frustrating it must
be for the Debian package to not reflect the last year of work.  Great
timing, by the way!  Now is the time to fix these issues for the next
Debian release. :-)

> Although I was an experienced .spec file and RPM maker
>  years ago, I know absolutely nothing about making
>  Debian packages.

Getting up to speed with Debian packaging requires reading more than
for RPMs, (eg: Debian Policy, plus other resources like New
Maintainers Guide or Debian Packaging Tutorial) and I'd be happy to
furnish links to this material.  That said, there's no need to learn
how to build a package from scratch when one already exists.

Options:  1. Wait for someone to fix the package, or
  2. Set up a Debian development environment and
 a) Fork https://salsa.debian.org/multimedia-team/muse
and submit your changes as a merge request, or
 b) Join the Debian Multimedia Team.

> But I am highly active in MusE's development.
> I am usually available for quick response.
> 
> We'd like to see a new deb package for users.
> Anything you need us to do - questions, fixes,
>  you name it, just ask!

I've bumped the priority of this new version bug and blocked two
others, because I think everyone will agree that this is the best way
forward.  Unfortunately I am swamped with work until sometime in early
November.  I hope that someone else can work on this asap, just in
case any issues emerge, because it sounds like you're on call to be
able to help out :-)

Cheers!
Nicholas


signature.asc
Description: PGP signature

Bug#910968: gnome-software: doesn't change status after uninstalling a software

[Fábio Assis]

Package: gnome-software
Version: 3.22.5-1
Severity: minor

Dear Maintainer,

I was uninstalling some softwares that I don't use by clicking in the
"uninstall" button at the Gnome Software.
After the removing process, the status of the software wasn't change (i.e.
Gnome Software still shows the "execute" and "remove" buttons). I have to
restart gnome software to update the status of the software I uninstalled.

Fábio Assis



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

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

Versions of packages gnome-software depends on:
ii  appstream0.10.6-2
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gnome-software-common3.22.5-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libappstream-glib8   0.6.8-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u3
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libenchant1c2a   1.6.0-11+b1
ii  libfwupd10.7.4-2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgnome-desktop-3-123.22.2-1
ii  libgtk-3-0   3.22.11-1
ii  libgtkspell3-3-0 3.0.9-1
ii  libgudev-1.0-0   230-3
ii  libjson-glib-1.0-0   1.2.6-1
ii  libpackagekit-glib2-18   1.1.5-2+deb9u1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpolkit-gobject-1-00.105-18
ii  libsecret-1-00.18.5-3.1
ii  libsoup2.4-1 2.56.0-2+deb9u2
ii  libsqlite3-0 3.16.2-5+deb9u1
ii  packagekit   1.1.5-2+deb9u1
ii  software-properties-gtk  0.96.20.2-1

gnome-software recommends no packages.

Versions of packages gnome-software suggests:
pn  fwupd  
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-limba

-- no debconf information

Bug#910946: [Pkg-xen-devel] Bug#910946: xen-hypervisor-4.11-amd64: HVM DomU - 64-bit kernel cannot access emulated ATA devices

[Hans van Kranenburg]

Hi Stephen,

On 10/13/2018 07:31 PM, Stephen Oberholtzer wrote:
> Package: xen-hypervisor-4.11-amd64
> Version: 4.11.1~pre.20180911.5acdd26fdc+dfsg-3
> Severity: normal

Thanks for trying out the new Xen 4.11 packages, spending time testing
things and writing up reports.

> Dear Maintainer,
> 
> This mostly manifests as an "unable to access emulated CD-ROM drive", because 
> there are no PVHVM CD-ROMs.
> 
> NOTE: I had similar issues with 4.8, so I upgraded to 4.11. This actually 
> gave me *more* issues.

Yeah, I've noticed that you also reported this earlier on #xen irc.

There was a reply from Andrew Cooper:
19:35 < andyhhp__> Stevie-O: Thats most likely a dom0 kernel bug
19:35 < andyhhp__> the 32 and 64bit block protocols were binarily
diverged for a while due to some "interesing" bugfixes
19:36 < andyhhp__> but its the most common cause of "32bit works, 64bit
doesn't" when it comes to anything vaguely like disks

I suspect that this issue, together with the other two issues you just
opened are not things that can easily be resolved only by the people
doing the packaging work for Debian. This means that we have to get into
the mode "let's prepare a well-written bug report for upstream xen
developers".

Since the comments from Andrew point at at least the dom0 kernel version
being a factor in this equation: can you also add linux kernel version
information for dom0 and domU for your tests? These kind of things
explode into a testing-matrix of combinations of things very fast, and
any testing you can do providing that info will help other people
helping you narrowing down the issue.

Thanks,

> Attempting to boot an HVM domU from a CD image (to perform an install or 
> rescue on VM data) fails when the CD uses a 64-bit kernel.
> (When I use the Knoppix 'failsafe' mode, which uses a 32-bit kernel, I get 
> different behavior.  Under 4.8, it boots; under 4.11, it hangs during ATA bus 
> probing.)
> 
> I have tried the following ISO images:
> * debian-buster-DI-alpha3-amd64-netinst.iso (tested on 4.8 only; can't use at 
> all on 4.11)
> * KNOPPIX_V8.2-2018-05-10-EN.iso
> * debian-live-9.5.0-amd64-kde.iso
> * gparted-live-0.32.0-1-amd64.iso
> 
> Here are some additional details (mostly gleaned from Knoppix, because that's 
> what I was doing my testing with):
> - When I try booting Knoppix in a non-accelerated VM by directly running 
> qemu, everything works fine, so Xen is definitely a factor.
> - PVHVM is working: non-CDROM drive shows up as xvbda
> - With PVHVM disabled (xen_platform_pci=0), hda also fails to be detected
> - Persuading libata to dump IDENTIFY data reveals that the returned page is 
> all zeroes.
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (400, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.18.6 (SMP w/12 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/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> xen-hypervisor-4.11-amd64 depends on no packages.
> 
> Versions of packages xen-hypervisor-4.11-amd64 recommends:
> ii  xen-hypervisor-common  4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1
> ii  xen-utils-4.11 4.11.1~pre.20180911.5acdd26fdc+dfsg-3
> 
> xen-hypervisor-4.11-amd64 suggests no packages.
> 
> -- no debconf information

--
Hans van Kranenburg

Bug#900296: ITP: trio -- Async/await-native Python3 I/O library for humans and snake people

[Robie Basak]

On Sat, Oct 13, 2018 at 09:03:47PM +0200, Matthias Urlichs wrote:
> On 13.10.18 17:43, Robie Basak wrote:
> > Any news on this? If not, any objection to me taking over this ITP?
> 
> Go for it. You'll have to package a couple of small dependencies first
> (sniffio, outcome).

On it already. Thanks!

> I'm not too busy to be co-maintainer. ;-)

I intend to put the packages into DPMT for team maintenance, though I
need to join the DPMT first and get the package into compliance with
their policies, so I'll just upload to unstable first to get there
incrementally.

Robie


signature.asc
Description: PGP signature

Bug#910967: See bug 97977 in pam_unix

[Leonardo Macchia]

For pam_unix, I this was discussed and addressed some time ago in bug 97977.

Thanks and regards, Leo.

Bug#876733: Licensing of jeuclid

[Ivo De Decker]

Control: severity -1 normal

Hi,

On Wed, Nov 15, 2017 at 02:01:14AM -0600, Michael Lustfield wrote:
> > according to bug #876733, there is a licensing problem with jeuclid :
> > - the LICENSE.txt file [1] says Apache 2.0 ;
> 
> LICENSE.txt showed up in revision b9d5f518ae61 (61) as a rename of LICENSE.
> LICENSE showed up in revision 7a11e25aacfa (0) during a CVS import.
> 
> support/LICENSE.txt shows up in revision 472677a11fef (683).. and is 
> Apache-2.0.
> 
> > - the NOTICE file [2] looks like an Apache 1.0.
> 
> NOTICE also showed up in revision 7a11e25aacfa (0).
> 
> NOTICE seems to be Apache-1.1 with word replacements. (not Apache-1.0)

In 7a11e25aacfa (CVS import), there is also a file CHANGELOG, which has

08/06/06 Max
* added serialVersionUID to Exception classes.
* removed unused imports from MathEnclose
* removed unused imports, variables from FontTest
* fixed warnings on MathBaseTest
* made MathBaseTest an actual JUnit Testcase
* made sure every source file has actual Apache 2 license in it.
* added basic checkstyle configuration.
* repaired ant task
* made sure license is apache 2 license
* removed webapp directories (they are inactive anyways)
* added support for ImageIO writers to Converter (requires JDK 1.4)

This first showed up in 2.9, downloadable from
https://sourceforge.net/projects/jeuclid/files/older%20releases/

The following lines make it clear that the license is intended to be apache 2:

* made sure every source file has actual Apache 2 license in it.
* made sure license is apache 2 license

It seems to be clear what the license is supposed to be, and this is
documented in the copyright file, so I'm downgrading this bug. As it might be
good to remove the NOTICE file to avoid further confusing, I'm leaving it
open. Feel free to close if you disagree.

Cheers,

Ivo

Bug#910967: libpam-modules: pam_exec should reset SIGCHLD to default before fork()

[Leonardo Macchia]

Package: libpam-modules
Version: 1.1.8-3.6
Severity: normal

Dear Maintainer,

pam_exec is currently not handling SIGCHLD in the same way that other
pam modules do when using fork (see for example how pam_unix reset
SIGCHLD to default before fork and restore SIGCHLD to the old value
after wait).

By not resetting SIGCHLD, you might encounter a race conditions when the
process that is calling pam actually sets up a signal handler that runs
wait (to retrieve pids of its children).

I was able to always reproduce this behaviour with a fresh Debian
installation (minimal set of packages) and:

- install a trivial pam_exec line, for example append in
  /etc/pam.d/common-account

- sets up an at job for the near future

- verify the behaviour of the atd process

- you should see that it fails and in the log:

/var/log/auth.log:
Oct 13 21:47:00 d9test atd[766]: pam_exec(atd:account): waitpid returns with 
-1: No child processes

and a strace of atd reveals what happens (atd has pid 487, the new
process that is generated at 21:47 has pid 766)
(see the output of "strace -tt -f -p 487")

- atd (pid=487) forks at exactly 21:47 (it's the job that has been
  setup) producing pid=766
- pam stack runs, pam_exec fork/exec the process that is defined in
  /etc/pam.d (in this example /bin/true), pid=767
- pid=767 exits immediately with exit=0
- pid=766 receives SIGCHLD and you can clearly see that there's a signal
  handler that collects pid=767
- after the signal handler, there's another wait call (pam_exec's) that
  cannot find this child and therefore exit with exit=1

487   21:46:24.691254 restart_syscall(<... resuming interrupted nanosleep ...>) 
= 0
487   21:47:00.039083 stat(".", {st_mode=S_IFDIR|S_ISVTX|0770, st_size=4096, 
...}) = 0
[...]
487   21:47:00.040078 clone(child_stack=NULL, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7fad11926f50) = 766
766   21:47:00.040313 set_robust_list(0x7fad11926f60, 24) = 0
[...]
766   21:47:00.060342 clone(child_stack=NULL, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7fad11926f50) = 767
767   21:47:00.060535 set_robust_list(0x7fad11926f60, 24 
[...]
767   21:47:00.158848 execve("/bin/true", ["/bin/true"], [/* 3 vars */]) = 0
[...]
767   21:47:00.160283 exit_group(0) = ?
767   21:47:00.160345 +++ exited with 0 +++
766   21:47:00.160366 <... read resumed> "", 4096) = 0
766   21:47:00.160412 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, 
si_pid=767, si_uid=1, si_status=0, si_utime=0, si_stime=0} ---
766   21:47:00.160462 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 
WNOHANG, NULL) = 767
766   21:47:00.160549 wait4(-1, 0x7ffe3a24a914, WNOHANG, NULL) = -1 ECHILD (No 
child processes)
766   21:47:00.160607 rt_sigreturn({mask=[]}) = 0
766   21:47:00.160668 close(7)  = 0
766   21:47:00.160719 wait4(767, 0x7ffe3a24aff8, 0, NULL) = -1 ECHILD (No child 
processes)
[...]
766   21:47:00.163397 exit_group(1) = ?
766   21:47:00.163533 +++ exited with 1 +++
[...]

A simple fix (that works for me) could be to do what pam_unix does:
reset to SIG_DFL before fork and then restore the signal at wait.
(in pam_unix there's also a check of option UNIX_NOREAP, it might be a
good idea to also introduce this in pam_exec).

--- pam_exec.c.orig
+++ pam_exec.c
@@ -48,6 +48,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 #define PAM_SM_AUTH
@@ -212,6 +213,10 @@
 return PAM_SERVICE_ERR;
   }
 
+  memset(, '\0', sizeof(newsa));
+  newsa.sa_handler = SIG_DFL;
+  sigaction(SIGCHLD, , );
+
   pid = fork();
   if (pid == -1)
 return PAM_SYSTEM_ERR;
@@ -258,6 +263,7 @@
 
   while ((retval = waitpid (pid, , 0)) == -1 &&
 errno == EINTR);
+  sigaction(SIGCHLD, , NULL);   /* restore old signal handler */
   if (retval == (pid_t)-1)
{
  pam_syslog (pamh, LOG_ERR, "waitpid returns with -1: %m");



Regards, Leonardo.


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

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

Versions of packages libpam-modules depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  libaudit1  1:2.6.7-2
ii  libc6  2.24-11+deb9u3
ii  libdb5.3   5.3.28-12+deb9u1
ii  libpam-modules-bin 1.1.8-3.6
ii  libpam0g   1.1.8-3.6
ii  libselinux12.6-3+b3

libpam-modules recommends no packages.

libpam-modules suggests no packages.

-- debconf information:
  libpam-modules/disable-screensaver:

Bug#910966: RFS: 4pane

[David Hart]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an update of my package "4pane"

  * Package name: 4pane
Version : 5.0-2
Upstream Author : David Hart 
  * URL : https://4Pane.co.uk
  * License : GPL3
Section : x11

It builds these binary packages:

  4pane - four-pane detailed-list file manager

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

  https://mentors.debian.net/package/4pane


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

dget -x https://mentors.debian.net/debian/pool/main/4/4pane/4pane_5.0-2.dsc

There is also a git repo:
 https://github.com/dghart/4pane-debian-dir

The upload mostly changes to the latest debhelper and policy versions, with
consequent lintian fixes. However it also switches 4pane to use the GTK3 flavour
of wxwidgets3.0: see #894663.

This is a request for a review and upload of the update. The amended package
builds and works, and is lintian-clean.

Changes since the last upload:

4pane (5.0-2) unstable; urgency=medium

  * Depend on the gtk+3 version of wxWidgets: see #894663
  * Override testsuite-autopkgtest-missing
  * Add an upstream/metadata file
  * Move the appdata.xml file from appdata/ to metadata/
  * Change some links from http: to https:
  * Update to the latest debhelper and policy versions


Regards,

David Hart

Bug#910934: thunar and thunar daemom stoped working

[Dani]

Hi!

I made a fresh Buster install and thunar ressurrected :-)
Thanks a lot ! :-)

I consider this closed. :-)

[]'s Dani.


Em sáb, 13 de out de 2018 às 11:57, Daniel Norte de Moraes <
danielchea...@gmail.com> escreveu:

> Package: thunar
> Version: 1.8.2-1
> Severity: important
>
> Dear Maintainer,
>
> Thunar in xfce4 don't work anymore.
>
> exec "thunar" in terminal with normal user show nothing and freezes.
> exec "thunar" as daemon in terminal with root user show:
> _
> Thunar: Failed to initialize Xfconf: Unable to autolaunch a dbus-daemon
> without a $DISPLAY for X11
>
> Unable to init server: Não foi possível conectar: Conexão recusada
>
> (thunar:1462): Gtk-WARNING **: 11:50:46.874: cannot open display:
> 
>
> this make my whole xfce4 desktop unusable... :-)
>
> Really Thanks for yours continued work.
>
> []'s Dani.
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
> LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages thunar depends on:
> ii  desktop-file-utils  0.23-4
> ii  exo-utils   0.12.2-2
> ii  libatk1.0-0 2.30.0-1
> ii  libc6   2.27-6
> ii  libcairo2   1.15.12-1
> ii  libexo-2-0  0.12.2-2
> ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
> ii  libglib2.0-02.58.1-2
> ii  libgtk-3-0  3.24.1-2
> ii  libgudev-1.0-0  232-2
> ii  libice6 2:1.0.9-2
> ii  libnotify4  0.7.7-3
> ii  libpango-1.0-0  1.42.4-3
> ii  libsm6  2:1.2.2-1+b3
> ii  libthunarx-3-0  1.8.2-1
> ii  libxfce4ui-2-0  4.12.1-3
> ii  libxfce4util7   4.12.1-3
> ii  libxfconf-0-2   4.12.1-1
> ii  shared-mime-info1.10-1
> ii  thunar-data 1.8.2-1
>
> Versions of packages thunar recommends:
> ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
> ii  dbus-x11 [dbus-session-bus]   1.12.10-1
> ii  gvfs  1.38.0-2
> ii  libcairo-gobject2 1.15.12-1
> ii  libpangocairo-1.0-0   1.42.4-3
> ii  libxfce4panel-2.0-4   4.12.2-1
> ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
> ii  thunar-volman 0.9.0-1
> ii  tumbler   0.2.3-1
> ii  udisks2   2.8.1-1
> ii  xdg-user-dirs 0.17-1
>
> Versions of packages thunar suggests:
> ii  thunar-archive-plugin 0.4.0-1
> ii  thunar-media-tags-plugin  0.3.0-1
>
> -- no debconf information
>


-- 
"There are many plans in the Human heart, But
 is the Lord's Purpose that prevails"

"Existem Muitos planos e desejos no coração Humano, MAS
são os Propósitos do Senhor que prevalecem"

  []'s Dani:-)

Bug#909990: Stange import error for nibabel when trying to import from .pybuild

[Andreas Tille]

On Fri, Oct 12, 2018 at 09:15:37AM -0400, Yaroslav Halchenko wrote:
> > ok... will merge for the next upload to proceed -- we mitigated all
> > known issues, and the beast builds fine all the way down to jessie, so
> > release is coming soon now
> 
> oi... I guess we caused you confusion and unneeded work???

Urgs, yes! While I for sure need to blame myself that I missed to check
the diff between repository and uploads, your naming of branches is
irritating.
 
> I see that you updated debian branch redoing packaging for 2.3.0-1 which was
> uploaded already awhile back, while we use this ad-hoc dist/debian/proper
> branch (should be the default when you clone that repo):

Could you imagine to use a branch named debian?  In my attempt to update
packages mentioned in Debian Med tasks which are not uploaded for a long
time and need fixing Vcs fields (and usually lots of lintian issues) I
migrated pyepl to the "kind of usual" repository layout.  Do you have
some tools that are relying on those unusual names (= did I broke
something when renaming dist/debian/proper to debian in pyepl)?
 
> $> grep Vcs-Git debian/control
> Vcs-Git: https://salsa.debian.org/neurodebian-team/pynifti.git -b 
> dist/debian/proper
> 
> so not yet sure how to proceed with your changes. meanwhile pushed my local
> state of dist/debian/proper

I'd volunteer to check the diff between your current changes and my work
and merge everything - but can I please use a branch named debian? 

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#710117: new version, desktop file

[Markus Koschany]

Hi Gürkan,

Am 11.10.18 um 17:42 schrieb Gürkan Myczko:
> Hello Josue and Markus
> 
> I've prepared a new upstream version of greed, and added the desktop file.
> Feel free to use:
> 
> http://phd-sid.ethz.ch/debian/greed/greed_4.2-1.dsc
> 
> Best,

Thank you for preparing a new Debian release of greed. I've only made
some minor changes. I documented that upstream switched to the
BSD-2-clause license and I also installed a desktop icon based on the
already existing greed-logo but with a white background instead of a
transparent one. The package should hit the mirrors in a few hours.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#907421: nm.debian.org: crash on keyserver timeout

[Mattia Rizzolo]

Control: reopen -1

On Sat, Sep 29, 2018 at 02:26:43PM +0200, Pierre-Elliott Bécue wrote:
> > Anyway, I like the proposal, please propose further :)
> 
> Ack, then we can try to enhance this patch to make it fit your needs and
> comply with the coding style of nm.d.o.

Turns out it's quite more involved.

Today, the server that nono.d.o reached to started failing, so we got
several of these:

HTTPError at /process/479/am_ok/statement/create
500 Server Error: Internal Server Error for url: 
http://pool.sks-keyservers.net:11371/pks/lookup?search=0xFBFABDB541B5DC955BD9BA6EDB16CF5BB12525C4=mr=on=get

Request Method: POST
Request URL: https://nm.debian.org/process/479/am_ok/statement/create
Django Version: 1.10.7
Python Executable: /usr/bin/python3
Python Version: 3.5.3

Traceback:

File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner
  42. response = get_response(request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_legacy_get_response
  249. response = self._get_response(request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  187. response = self.process_exception_by_middleware(e, 
request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  185. response = wrapped_callback(request, *callback_args, 
**callback_kwargs)

File "/usr/lib/python3/dist-packages/django/views/generic/base.py" in view
  68. return self.dispatch(request, *args, **kwargs)

File "/srv/nm.debian.org/nm2/backend/mixins.py" in dispatch
  72. return super(VisitorMixin, self).dispatch(request, *args, 
**kwargs)

File "/usr/lib/python3/dist-packages/django/views/generic/base.py" in dispatch
  88. return handler(request, *args, **kwargs)

File "/usr/lib/python3/dist-packages/django/views/generic/edit.py" in post
  182. if form.is_valid():

File "/usr/lib/python3/dist-packages/django/forms/forms.py" in is_valid
  169. return self.is_bound and not self.errors

File "/usr/lib/python3/dist-packages/django/forms/forms.py" in errors
  161. self.full_clean()

File "/usr/lib/python3/dist-packages/django/forms/forms.py" in full_clean
  370. self._clean_fields()

File "/usr/lib/python3/dist-packages/django/forms/forms.py" in _clean_fields
  391. value = getattr(self, 'clean_%s' % name)()

File "/srv/nm.debian.org/nm2/process/forms.py" in clean_statement
  17. key = Key.objects.get_or_download(self.fpr)

File "/srv/nm.debian.org/nm2/keyring/models.py" in get_or_download
  106. body = self.download(fpr)

File "/srv/nm.debian.org/nm2/keyring/models.py" in download
  65. res.raise_for_status()

File "/usr/lib/python3/dist-packages/requests/models.py" in raise_for_status
  893. raise HTTPError(http_error_msg, response=self)

Exception Type: HTTPError at /process/479/am_ok/statement/create
Exception Value: 500 Server Error: Internal Server Error for url: 
http://pool.sks-keyservers.net:11371/pks/lookup?search=0xFBFABDB541B5DC955BD9BA6EDB16CF5BB12525C4=mr=on=get



So I think there needs to be a more systematic catch somewhere higher in
the stack (that then propagates the error and get displayed in all
pages that might end up with it or so).
This occasion made me remember of https://bugs.debian.org/895896 - so
pretty much all pages that let a user add a statement are affected.
And somehow, not sure how, even pages that don't, like /process/NNN, do.

-- 
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#910965: libngspice0: typo in short description: cicruit → circuit

[Jonas Smedegaard]

Package: libngspice0
Version: 28-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Short description says "Spice cicruit simulator - library".

Probably should be "circuit".

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlvCW6sACgkQLHwxRsGg
ASGFWA/+KLyN7CUsKRc9iTA112nDQPVzOezAAsN6ERMR027uf5A++NC5dqz3+4Hi
4EhGoB+8YXgGT6sCmleDor3RcRkVcnSWdWnIWD2cJCGJdodIytcqf2P8qaJa7rKh
jCUeE0ea2yDq8nAPi8dUtOgXa7x+DO3qzQMtvzjXJ1VyziNZy8Jea7PuNQ/BghUa
DX/aJFIacVw5suoMnMuiyaAyJp7jDJs2y+wpW3md5KjvLK9h26uWU8LyLpuHMsTi
BGGRWmd5l3w7+t4uW57q1qqcKL5wea+ReuJAtlZCu9AixorliKcURF0tJlLQp9SB
cM0GTsXoNU44/KkeoJMCcpCath8ts0XDMi9IzYv2axR+Zm86P6HbSQUpKaiR57c8
+imDjUoryoyCyc3yxuYgOXideBwLnNWCUTsctt2a2EscL6jdhvn/lkFN0GQ4JqdI
kjYwDguD4diUumx4wn1iFnE6Eoxy2T7R9ZI2kCD7GtLfMPQ3vdCyHEm/CK4C+Tj5
xdy/42cFSb4iDFJsXr9DDwPY6dtx3BBsuoPKP4H0X5jJtH6n4nOVrcssC+i2GFF6
uLnrjQN86lvcOiVq2avjElg1kTaUZVLKCyRFwyagiENyRpV2XfXzbcaER3OGOJsH
ftdOhVJPkkmwef8fZalDXorIljSgZUlaYIg6sO7LKXI/AadB5U0=
=vDNB
-END PGP SIGNATURE-

Bug#910963: x265 FTBFS on !x86: undefined references to x265*::detect512()

[Adrian Bunk]

Source: x265
Version: 2.9-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=x265=sid

...
[100%] Linking CXX executable x265
/usr/bin/cmake -E cmake_link_script CMakeFiles/cli.dir/link.txt --verbose=1
/usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed 
-L/<>/x265-10bit -L/<>/x265-12bit -rdynamic 
-Wl,-Bsymbolic,-znoexecstack CMakeFiles/cli.dir/input/input.cpp.o 
CMakeFiles/cli.dir/input/y4m.cpp.o CMakeFiles/cli.dir/input/yuv.cpp.o 
CMakeFiles/cli.dir/output/output.cpp.o CMakeFiles/cli.dir/output/raw.cpp.o 
CMakeFiles/cli.dir/output/reconplay.cpp.o CMakeFiles/cli.dir/output/y4m.cpp.o 
CMakeFiles/cli.dir/output/yuv.cpp.o CMakeFiles/cli.dir/x265.cpp.o  -o x265 
-Wl,-rpath,/<>/x265-8bit: libx265.so.165 -lpthread -lrt -ldl 
-lnuma -Wl,-Bstatic -lx265_main10 -lx265_main12 -Wl,-Bdynamic -lpthread -lrt 
-ldl -lnuma 
/usr/bin/ld: libx265.so.165: undefined reference to `x265_12bit::detect512()'
/usr/bin/ld: libx265.so.165: undefined reference to `x265_10bit::detect512()'
/usr/bin/ld: libx265.so.165: undefined reference to `x265::detect512()'
collect2: error: ld returned 1 exit status
make[4]: *** [CMakeFiles/cli.dir/build.make:208: x265] Error 1

Bug#910964: libprotobuf17 might need Breaks: libprotobuf10

[Adrian Bunk]

Package: libprotobuf17
Version: 3.6.1-2
Severity: serious
Control: affects -1 src:cura-engine

https://buildd.debian.org/status/package.php?p=cura-engine=sid

...
Running tests...
/usr/bin/ctest --force-new-ctest-process -j4
Test project /<>/obj-x86_64-linux-gnu
Start 1: SpaceFillingTreeFillTest
Start 2: SparseGridTest
Start 3: IntPointTest
Start 4: LinearAlg2DTest
1/8 Test #1: SpaceFillingTreeFillTest .***Exception: Child aborted  
0.02 sec
[libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was 
compiled against version 3.0.0 of the Protocol Buffer runtime library, which is 
not compatible with the installed version (3.6.1).  Contact the program author 
for an update.  If you compiled the program yourself, make sure that your 
headers are from the same version of Protocol Buffers as your link-time 
library.  (Version verification failed in "google/protobuf/any.pb.cc".)
terminate called after throwing an instance of 
'google::protobuf::FatalException'
  what():  This program was compiled against version 3.0.0 of the Protocol 
Buffer runtime library, which is not compatible with the installed version 
(3.6.1).  Contact the program author for an update.  If you compiled the 
program yourself, make sure that your headers are from the same version of 
Protocol Buffers as your link-time library.  (Version verification failed in 
"google/protobuf/any.pb.cc".)

Start 5: PolygonUtilsTest
2/8 Test #2: SparseGridTest ...***Exception: Child aborted  
0.03 sec
[libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was 
compiled against version 3.0.0 of the Protocol Buffer runtime library, which is 
not compatible with the installed version (3.6.1).  Contact the program author 
for an update.  If you compiled the program yourself, make sure that your 
headers are from the same version of Protocol Buffers as your link-time 
library.  (Version verification failed in "google/protobuf/any.pb.cc".)
terminate called after throwing an instance of 
'google::protobuf::FatalException'
  what():  This program was compiled against version 3.0.0 of the Protocol 
Buffer runtime library, which is not compatible with the installed version 
(3.6.1).  Contact the program author for an update.  If you compiled the 
program yourself, make sure that your headers are from the same version of 
Protocol Buffers as your link-time library.  (Version verification failed in 
"google/protobuf/any.pb.cc".)

Start 6: PolygonTest
3/8 Test #3: IntPointTest .***Exception: Child aborted  
0.03 sec
[libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was 
compiled against version 3.0.0 of the Protocol Buffer runtime library, which is 
not compatible with the installed version (3.6.1).  Contact the program author 
for an update.  If you compiled the program yourself, make sure that your 
headers are from the same version of Protocol Buffers as your link-time 
library.  (Version verification failed in "google/protobuf/any.pb.cc".)
terminate called after throwing an instance of 
'google::protobuf::FatalException'
  what():  This program was compiled against version 3.0.0 of the Protocol 
Buffer runtime library, which is not compatible with the installed version 
(3.6.1).  Contact the program author for an update.  If you compiled the 
program yourself, make sure that your headers are from the same version of 
Protocol Buffers as your link-time library.  (Version verification failed in 
"google/protobuf/any.pb.cc".)

Start 7: StringTest
4/8 Test #4: LinearAlg2DTest ..***Exception: Child aborted  
0.02 sec
[libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was 
compiled against version 3.0.0 of the Protocol Buffer runtime library, which is 
not compatible with the installed version (3.6.1).  Contact the program author 
for an update.  If you compiled the program yourself, make sure that your 
headers are from the same version of Protocol Buffers as your link-time 
library.  (Version verification failed in "google/protobuf/any.pb.cc".)
terminate called after throwing an instance of 
'google::protobuf::FatalException'
  what():  This program was compiled against version 3.0.0 of the Protocol 
Buffer runtime library, which is not compatible with the installed version 
(3.6.1).  Contact the program author for an update.  If you compiled the 
program yourself, make sure that your headers are from the same version of 
Protocol Buffers as your link-time library.  (Version verification failed in 
"google/protobuf/any.pb.cc".)

Start 8: UnionFindTest
5/8 Test #6: PolygonTest ..***Exception: Child aborted  
0.01 sec
[libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was 
compiled against version 3.0.0 of the Protocol Buffer runtime library, which is 
not compatible with the installed version (3.6.1).  Contact the program author 
for an update.  If you compiled the program 

Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)

[Salvatore Bonaccorso]

control: 908192 blocked by 908223
Control: tag 908192 + wontfix

Hi Christian,

On Tue, Oct 09, 2018 at 02:06:09AM +0200, Christian Brauner wrote:
> On Sat, 22 Sep 2018 21:20:19 +0200 Salvatore Bonaccorso
>  wrote:
> > Hi,
> >
> > On Thu, Sep 20, 2018 at 06:09:07PM +0800, johnw wrote:
> > >
> > > Is it also reverted/back port to Debian?
> > > Because I still have this problem.
> >
> > it has not yet been reverted upstream, the discussion got stuck here:
> 
> Hey, I'm one of the ACKers of the original patch and the author
> of the revert. The kernel patch that broke userspace won't be reverted 
> upstream.
> However, I'm also a LXC maintainer and I have fixed LXC upstream to handle
> 4.18 kernels. The relevant commits are:
> 
> master:
> https://github.com/lxc/lxc/commit/3e04a6083eefe0b837db6d1b826721fd985ce052
> https://github.com/lxc/lxc/commit/5067e4dd8594c3b1f8ee78f0e86edb480f84a156
> 
> stable-3.0:
> https://github.com/lxc/lxc/commit/c221e3780a59ac08cd7e8758f7d71422f0c4decf
> 
> I haven't done a backport of this to stable-2.0 yet. So far there weren't
> any complains for that one.

Thanks for your followup, much appreciated. The repsective bug report
for LXC itself is #908223 where it then should be fixed.

I'm going to mark #908192 as wontfix for the kernel side. Is it
planned to backport a fix for stable-2.0?

Regards,
Salvatore

Bug#910962: pykwalify FTBFS: test failures in non-UTF-8 locales

[Adrian Bunk]

Source: pykwalify
Version: 1.7.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=pykwalify=sid

...
I: pybuild base:217: cd /<>/.pybuild/cpython3_3.6/build; python3.6 
-m pytest tests
= test session starts ==
platform linux -- Python 3.6.7rc1, pytest-3.6.4, py-1.6.0, pluggy-0.6.0
rootdir: /<>, inifile: pytest.ini
collected 47 items

tests/test_cli.py .. [  4%]
tests/test_core.py . [ 31%]
tests/test_core_methods.py   [ 40%]
tests/test_exceptions.py ..  [ 44%]
tests/test_rule.py ...   [ 93%]
tests/test_types.py .[ 95%]
tests/test_unicode.py FF [100%]

=== FAILURES ===
_ TestUnicode.test_files_with_unicode_content_success __

self = 
tmpdir = local('/tmp/pytest-of-buildd/pytest-1/test_files_with_unicode_conten0')

def test_files_with_unicode_content_success(self, tmpdir):
"""
These tests should pass with no exception raised
"""
fail_data_2s_yaml = {
'schema': {
'type': 'map',
'mapping': {
'msg': {
'type': 'int',
},
}
},
'data': {
'msg': 123,
},
'errors': []
}

source_f = tmpdir.join(u"2s\xe5.json")
>   source_f.write(yaml.safe_dump(fail_data_2s_yaml, allow_unicode=True))

tests/test_unicode.py:50: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/py/_path/local.py:501: in write
f = self.open(mode)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 
local('/tmp/pytest-of-buildd/pytest-1/test_files_with_unicode_conten0/2s\xe5.json')
mode = 'w', ensure = False, encoding = None

def open(self, mode='r', ensure=False, encoding=None):
""" return an opened file with the given mode.

If ensure is True, create parent directories if needed.
"""
if ensure:
self.dirpath().ensure(dir=1)
if encoding:
return py.error.checked_call(io.open, self.strpath, mode, 
encoding=encoding)
>   return py.error.checked_call(open, self.strpath, mode)
E   UnicodeEncodeError: 'ascii' codec can't encode character '\xe5' in 
position 65: ordinal not in range(128)

/usr/lib/python3/dist-packages/py/_path/local.py:361: UnicodeEncodeError
_ TestUnicode.test_files_with_unicode_content_failing __

self = 
tmpdir = local('/tmp/pytest-of-buildd/pytest-1/test_files_with_unicode_conten1')

def test_files_with_unicode_content_failing(self, tmpdir):
"""
These tests should fail with the specified exception
"""
# To trigger schema exception we must pass in a source file
fail_data_2f_yaml = {
'schema': {
'type': 'map',
'mapping': {
'msg': {
'type': 'int',
},
}
},
'data': {
'msg': 'Foobar',
},
'errors': ["Value 'Foobar' is not of type 'int'. Path: '/msg'"]
}

source_f = tmpdir.join(u"2f\xe5.json")
>   source_f.write(yaml.safe_dump(fail_data_2f_yaml, allow_unicode=True))

tests/test_unicode.py:105: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/py/_path/local.py:501: in write
f = self.open(mode)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 
local('/tmp/pytest-of-buildd/pytest-1/test_files_with_unicode_conten1/2f\xe5.json')
mode = 'w', ensure = False, encoding = None

def open(self, mode='r', ensure=False, encoding=None):
""" return an opened file with the given mode.

If ensure is True, create parent directories if needed.
"""
if ensure:
self.dirpath().ensure(dir=1)
if encoding:
return py.error.checked_call(io.open, self.strpath, mode, 
encoding=encoding)
>   return py.error.checked_call(open, self.strpath, mode)
E   UnicodeEncodeError: 'ascii' codec can't encode character '\xe5' in 
position 65: ordinal not in range(128)

/usr/lib/python3/dist-packages/py/_path/local.py:361: UnicodeEncodeError
=== warnings summary ===

Bug#910961: xen-hypervisor-4.11-amd64: HVM domU fails to start when using PCI passthrough

[Stephen Oberholtzer]

Package: xen-hypervisor-4.11-amd64
Version: 4.11.1~pre.20180911.5acdd26fdc+dfsg-3
Severity: normal

Dear Maintainer,

HVM domUs that specify PCI passthrough will not start.  The same configuration 
file started under Xen 4.8.

The output I am receiving is as follows:

libxl: error: libxl_pci.c:1146:libxl__device_pci_reset: Domain 0:The kernel 
doesn't support reset from sysfs for PCI device :00:14.0
libxl: error: libxl_qmp.c:292:qmp_handle_error_response: Domain 31:received an 
error message from QMP server: Binding of interrupt 0 failed: Permission denied
libxl: error: libxl_pci.c:1300:libxl__add_pcidevs: Domain 
31:libxl_device_pci_add failed: -3
libxl: error: libxl_create.c:1519:domcreate_attach_devices: Domain 31:unable to 
add pci devices
libxl: error: libxl_domain.c:1034:libxl__destroy_domid: Domain 31:Non-existant 
domain
libxl: error: libxl_domain.c:993:domain_destroy_callback: Domain 31:Unable to 
destroy guest
libxl: error: libxl_domain.c:920:domain_destroy_cb: Domain 31:Destruction of 
domain failed

(There are three PCI devices I'm trying to pass through: 00:14.0, 01:00.[01], 
and 03:00.0. I tried each set individually, and got equivalent results each 
time.)

With 'log_lvl=all guest_loglvl=all', all I get in xl dmesg is a bunch of lines 
saying "HVM save:" for CPU, PIC, IOAPIC, etc.

Google gives me nothing.  I can find a small number of (unanswered) "Binding of 
interrupt 0 failed" messages, but none about 'Permission denied'.
However, it looks like the message may be incorrect, due to an mismatch between 
qemu and libxen.  Reading through the source code:

qemu: hw/xen/xen_pt.c line 874 logs the message.
874 error_setg_errno(errp, errno, "Binding of interrupt %u 
failed",
875  e_intx);

 That's using 'errno'.  However, the failed call was to 
xc_domain_bind_pt_pci_irq.

libxen: tools/libxc/xc_domain.c:1899, xc_domain_bind_pt_pci_irq forwards to 
xc_domain_bind_pt_irq
libxen: tools/libxc/xc_domain.c:1827, xc_domain_bind_pt_irq forwards to 
xc_domain_bind_pt_irq_int
libxen: tools/libxc/xc_domain.c:1783, xc_domain_bind_pt_irq_int
If an invalid argument is passed, this function returns -1 and sets 
errno to EINVAL, matching what qemu is expecting.
If pre-validation passes, the request is forwarded to do_domctl.
lixben: xen/common/domctl.c:380, do_domctl
This function doesn't seem to set errno. Instead, it returns (-ETHING).

This means that, if the request is handled by do_domctl, errno is unchanged, 
and so the "Permission denied" message may be
from an EPERM left in errno from an earlier operation.



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

Kernel: Linux 4.18.6 (SMP w/12 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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xen-hypervisor-4.11-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.11-amd64 recommends:
ii  xen-hypervisor-common  4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1
ii  xen-utils-4.11 4.11.1~pre.20180911.5acdd26fdc+dfsg-3

xen-hypervisor-4.11-amd64 suggests no packages.

-- no debconf information


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

Kernel: Linux 4.18.6 (SMP w/12 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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xen-hypervisor-4.11-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.11-amd64 recommends:
ii  xen-hypervisor-common  4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1
ii  xen-utils-4.11 4.11.1~pre.20180911.5acdd26fdc+dfsg-3

xen-hypervisor-4.11-amd64 suggests no packages.

-- no debconf information

Bug#910960: ITP: python-outcome -- capture the outcome of Python function calls

[Robie Basak]

Package: wnpp
Severity: wishlist
Owner: Robie Basak 

* Package name: python-outcome
  Version : 1.0.0-1
  Upstream Author : Nathaniel J. Smith 
* URL : https://github.com/python-trio/outcome
* License : Apache-2.0 or Expat
  Programming Lang: Python
  Description : capture the outcome of Python function calls

 Outcome provides a function `capture' for capturing the outcome of a Python
 function call, so that it can be passed around - even if the function raises
 an exception. It also provides the async equivalent function `acapture'.

This is a dependency of trio, ITP bug #900296

I intend to join the DPMT and then maintain it there, but as I'm not a
member right now, I will take things a step at a time and get it into
unstable first.


signature.asc
Description: PGP signature

Bug#910959: grub-cloud-amd64: missing Conflicts: grub-coreboot, grub-efi-ia32, grub-ieee1275, grub-xen

[Andreas Beckmann]

Package: grub-cloud-amd64
Version: 0.0.1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

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 grub-cloud-amd64.
  Preparing to unpack .../6-grub-cloud-amd64_0.0.1_amd64.deb ...
  Unpacking grub-cloud-amd64 (0.0.1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-5Ao0pQ/6-grub-cloud-amd64_0.0.1_amd64.deb (--unpack):
   trying to overwrite '/etc/kernel/postinst.d/zz-update-grub', which is also 
in package grub-coreboot 2.02+dfsg1-6

It's a bit unfortunate that the grub packages don't use
Provides+Conflicts+Replaces on a virtual package to ensure
only variant is installed. So you'll have to list all the packages
in your Conflicts.

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

etc/kernel/postinst.d/zz-update-grub
etc/kernel/postrm.d/zz-update-grub

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

Bug#910958: RFP: golang-notabug-themusicgod1-cookiejar -- A contestant's algorithm toolbox

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: golang-notabug-themusicgod1-cookiejar
  Version : 2.0
  Upstream Author : Péter Szilágyi 
* URL : https://notabug.org/themusicgod1/cookiejar
* License : BSD
  Programming Lang: go
  Description : A contestant's algorithm toolbox

CookieJar is a small collection of common algorithms, data structures and 
library extensions 
that were deemed handy for computing competitions at one point or another.

It is a (currently vendored) dependency of geth ( #890541 ).

Bug#910957: sysinfo: Intent to remove from Debian

[Jeremy Bicha]

Source: sysinfo
Version: 0.7-10.1
Severity: serious
Tags: buster sid
X-Debbugs-Cc: joshi...@microsoft.com

sysinfo was removed from Debian Testing a year ago because it doesn't
run. It also depends on gnome-sharp2. gnome-sharp2 is one of several
packages preventing the removal of libgnome from Debian.

Therefore, I intend to file a removal bug for sysinfo. Please let me
know promptly if you agree or object.

See https://bugs.debian.org/869427

Thanks,
Jeremy Bicha

Bug#900296: ITP: trio -- Async/await-native Python3 I/O library for humans and snake people

[Matthias Urlichs]

On 13.10.18 17:43, Robie Basak wrote:
> Any news on this? If not, any objection to me taking over this ITP?

Go for it. You'll have to package a couple of small dependencies first
(sniffio, outcome).

I'm not too busy to be co-maintainer. ;-)

-- 
-- Matthias Urlichs




signature.asc
Description: OpenPGP digital signature

Bug#907316: [pkg-cli-apps-team] Bug#907316: tomboy: Is tomboy still being maintained?

[Jeremy Bicha]

I don't think orphaning will help here. Among its other issues, tomboy
depends on the gnome-sharp2 libraries. gnome-sharp2 is one of several
packages preventing the removal of the libgnome libraries from Debian.

tomboy was already removed from Testing 6 months ago (overriding its
popcon) because of these issues.

I suggest that its maintainers strongly consider removing tomboy from
Debian now as part of the libgnome removal process.

Thanks,
Jeremy Bicha

Bug#910954: tomboy-latex: Intent to remove from Debian

[Jeremy Bicha]

Source: tomboy-latex
Version: 0.5-5
Severity: serious
Tags: buster sid
X-Debbugs-Cc: joshi...@microsoft.com

tomboy-latex was removed from Debian Testing 6 months ago because it
depends on tomboy which depends on the unmaintained gnome-sharp2
libraries. gnome-sharp2 is one of several packages preventing the
removal of libgnome from Debian.

Therefore, I intend to file a removal bug for tomboy-latex. Please let
me know promptly if you agree or object.

See https://bugs.debian.org/891586

Thanks,
Jeremy Bicha

Bug#910955: debtags: proposed tag: implemented-in::golang

[Adam Borowski]

Package: debtags
Version: 2.1.5
Severity: wishlist

There's over 1000 packages written in golang in Debian, a tag is way
overdue.  Such a tag would also be meaningful beyond a random oddity about
the package as for most languages, as Go suffers from security issues caused
by no dynamic linking, and is IIRC not covered by security support in
Debian.

It's up to you whether to go with "::golang" or "::go".


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

Kernel: Linux 4.19.0-rc7-debug-00188-gbf54891e3ef1 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debtags depends on:
ii  python3 3.6.6-1
ii  python3-apt 1.7.0
ii  python3-debian  0.1.33

debtags recommends no packages.

Versions of packages debtags suggests:
pn  tagcoll  

-- no debconf information

Bug#910736: ruby-progressbar: installs files with generic names in /usr/bin

[Andreas Beckmann]

Followup-For: Bug #910736

There is also a file-conflict with conserver-client which seems to make
legitimate use of /usr/bin/console.


Andreas

Bug#910956: ITP: python-sniffio -- detect which async Python library is in use

[Robie Basak]

Package: wnpp
Severity: wishlist
Owner: Robie Basak 

* Package name: python-sniffio
  Version : 1.0.0-1
  Upstream Author : Nathaniel J. Smith 
* URL : https://github.com/python-trio/sniffio
* License : Apache-2.0 or Expat
  Programming Lang: Python
  Description : detect which async Python library is in use

 Python libraries that support multiple async packages (like Trio, asyncio,
 etc) need to know which is in use. This library provides this information.

This is a dependency of trio, ITP bug #900296

I intend to join the DPMT and then maintain it there, but as I'm not a
member right now, I will take things a step at a time and get it into
unstable first.


signature.asc
Description: PGP signature

Bug#910953: ruby-aruba: autopkgtest regression

[Paul Gevers]

Source: ruby-aruba
Version: 0.14.6-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of ruby-aruba the autopkgtest of ruby-aruba fails
in testing when that autopkgtest is run with the binary packages of
ruby-aruba from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
ruby-aruba from testing0.14.6-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. Interestingly,
the changelog mentioned the removal of an obsolete patch to prevent a
broken test. I hope that is not related.

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

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

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-aruba

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-aruba/1144035/log.gz

autopkgtest [15:07:59]: test command1: gem2deb-test-runner --autopkgtest
--check-dependencies 2>&1
autopkgtest [15:07:59]: test command1: [---

┌──┐
│ Checking Rubygems dependency resolution on ruby2.5
  │
└──┘

Invalid gemspec in [aruba.gemspec]: No such file or directory - git
GEM_PATH= ruby2.5 -e gem\ \"aruba\"
/usr/lib/ruby/2.5.0/rubygems/dependency.rb:312:in `to_specs': Could not
find 'childprocess' (< 0.10.0, >= 0.6.3) - did find:
[childprocess-0.5.9] (Gem::MissingSpecVersionError)
Checked in
'GEM_PATH=/home/debci/.gem/ruby/2.5.0:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all',
execute `gem env` for more information
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1469:in `block in
activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in `each'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in
`activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1440:in `activate'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:68:in `block
in gem'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in
`synchronize'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `gem'
from -e:1:in `'



signature.asc
Description: OpenPGP digital signature

Bug#910952: binfmt-support - Fails to run if it can't load modules

[Bastian Blank]

Package: binfmt-support
Version: 2.1.8-2
Severity: important

Currently the update-binfmt tool fails to run if it can't use modprobe
to load the binfmt_misc module.  As the kernel does autoloading for this
module, just mounting the filesystem is enough.

This makes building the Debian cloud images using this package
impossible and we have to fall-back to manual binfmt setup.  Such builds
run inside a disposable environment without any access to the kernel
modules of the host system.

I think just dropping the not used for ages proc support would be the
easiest fix.

See https://salsa.debian.org/waldi/debian-cloud-images/-/jobs/54047

Regards,
Bastian

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

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

Bug#910951: ITP: python-trustme -- fake certificate authority for test use

[Robie Basak]

Package: wnpp
Severity: wishlist
Owner: Robie Basak 

* Package name: python-trustme
  Version : 0.4.0
  Upstream Author : Nathaniel J. Smith 
* URL : https://github.com/python-trio/trustme
* License : Apache-2.0 or Expat
  Programming Lang: Python
  Description : fake certificate authority for test use

 trustme is a tiny Python package that gives you a fake certificate authority
 (CA) that you can use to generate fake TLS certificates to use in tests. Its
 only useful purpose is as a dependency of test suites.

This is a (test) dependency of trio, ITP bug #900296

I intend to join the DPMT and then maintain it there, but as I'm not a
member right now, I will take things a step at a time and get it into
unstable first.


signature.asc
Description: PGP signature

Bug#910480: ghc: missing Breaks+Replaces+Provides for newly bundled libraries

[Andreas Beckmann]

Followup-For: Bug #910480

Hi,

there is also libghc-cabal-dev, where an insufficently versioned
Conflicts already exists.

Please update to

Breaks:
 libghc-cabal-dev (<< 2.2.0.1+),
Replaces:
 libghc-cabal-dev (<< 2.2.0.1+),

(the correct Provides are already in place)


Andreas

Bug#790584: gjots2: depends on python-gnome2 which is deprecated

[Jeremy Bicha]

gjots2 is now one of the last 3 packages in Debian depending on the
unmaintained gnome-python libraries.

Please either upgrade gjots2 to the new version or request that gjots2
be removed from Debian.

Thanks,
Jeremy Bicha

Bug#910950: libfits-java: Missing/broken version info

[Attila Kovacs]

Package: libfits-java
Version: 1.15.2-1
Severity: normal

Dear Maintainer (Ole?),

The 'fits.jar' archive that is built for Debian (ver. 1.15.2-1) from source has
a problem locating the version information resource in the JAR, crashing on
Fits.version() calls with an unexpected NullPointerException, and likely
breaking any code that tries to call Fits.version().

It looks like the JAR archive build for Debian has the resource:

  /META-INF/maven/gov.nasa.gsfc.heasarc/nom-tam-fits/pom.properties

missing from the JAR archive.

As such it can break any dependent code that uses the Fits.version() call, and
which otherwise works as expected with the stock (not Debian-built) 'fits.jar'.

Further info:

> lsb_release -rd:

Description:Ubuntu 18.04.1 LTS
Release:18.04

> libfits-java version: 1.15.2-1

> Expected behavior:

Fits.version() java calls return the libfits-java underlying library version
String (e.g. "1.15.2"), just like the stock JAR library that is provided by
nom.tam.fits.

> Actual behavior:

Fits.version() calls result in an unexpected NullPointerException. This is both
an unwelcome divergence of behavior the Debian-built JAR from the official
'binary' release, and will break code that tries to use Fits.version() calls.



-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-36-generic (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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libfits-java depends on:
ii  libcommons-compress-java  1.13-2

libfits-java recommends no packages.

Versions of packages libfits-java suggests:
pn  libfits-java-doc  

-- no debconf information

Bug#910949: RFP: node-is-generator -- Check whether a given value is a generator function

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-is-generator
  Version : 1.0.1
  Upstream Author : Blake Embrey 
* URL : https://notabug.org/themusicgod1/is-generator
* License : MIT
  Programming Lang: javascript
  Description : Check whether a given value is a generator function

Relatively small (2 small functions) nodejs package to check whether a 
value is a generator function.

( Generator: A specific type of iterator object. 
Generator Function: A function* declaration, returns a generator object. )

depended on by node-co-mocha ( #910602 ) 

not to be confused with node-is-generator-function ( #902067 ).

Bug#907518: wpa: problems with openssl 1.1.1

[Josh Triplett]

On Sun, Oct 07, 2018 at 11:00:48AM +0200, Andrej Shadura wrote:
> I’m unsure what can be done to help resolve this issue from the wpa side.

For debugging purposes, I'd still be interested to know this:

> On Wed, 5 Sep 2018 14:57:59 -0700 Josh Triplett 
> wrote:
> > Is there a way I can easily get wpa_supplicant to log the full client
> > and server certificate chain, and flag which *specific* certificate in
> > that chain it has an issue with? I'm trying to present appropriate
> > information to get the wireless network infrastructure improved, and
> > unlike https I can't just use `openssl s_client` to get the details I
> > need.

Bug#908681: libsane1: pointless package rename

[Philip Rinn]

Control: -1 severity normal

Hi,

I lower the severity of this bug as I couldn't find a severe violation of the
Debian policy - please point me to it if I missed something.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#910948: xen-hypervisor-4.11-amd64: HVM DomU: Emulated PS/2 keyboard does not work (through VNC)

[Stephen Oberholtzer]

Package: xen-hypervisor-4.11-amd64
Version: 4.11.1~pre.20180911.5acdd26fdc+dfsg-3
Severity: important

Dear Maintainer,

With Xen 4.11, I cannot use the standard emulated PS/2 keyboard when booting 
HVM domUs (through VNC.)
I did not have this problem with Xen 4.8 
(4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9).

In SeaBIOS, pressing ESC does not interrupt the boot.
In OVMF, pressing ESC does not interrupt the boot; typing does not work at the 
UEFI shell, either.
I cannot type at Syslinux prompts.
When a kernel boots, I cannot type at the console.

If I use '-device usb-kbd' to add a USB keyboard, I can usually type at the 
Syslinux prompt and at shells, but I still can't affect the BIOS.

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

Kernel: Linux 4.18.6 (SMP w/12 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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xen-hypervisor-4.11-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.11-amd64 recommends:
ii  xen-hypervisor-common  4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1
ii  xen-utils-4.11 4.11.1~pre.20180911.5acdd26fdc+dfsg-3

xen-hypervisor-4.11-amd64 suggests no packages.

-- no debconf information

Bug#910947: RFS: regexxer/0.10-4 [QA]

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a QA upload of the package "regexxer".

 * Package name: regexxer
   Version : 0.10-4
   Upstream Author : Daniel Elstner 
 Fabien Parent 
 * URL : http://regexxer.sf.net
 * License : GPL-2+
   Section : devel

It builds this binary package:

regexxer   - visual search and replace tool using Perl Regex

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/regexxer/regexxer_0.10-4.dsc

Changes since the last upload:

  * QA upload.
  * debian/compat: Set to 11.
  * debian/control (Build-Depends): Drop gconf2; completely unnecessary
(Closes: #894261).  Require debhelper >= 11.  Remove dh_autoreconf.
(Standards-Version): Claim compliance with 4.2.1; no changes needed.
  * debian/rules: Remove --with autoreconf; that's the default.
  * debian/patches/50_exception-prefdialog.patch: New; fix unhandled
exception due to invalid property which does not allow the preferences
dialog to be opened.
  * debian/patches/series: Update.
  * debian/lintian-overrides: Delete; unused.
  * debian/copyright: Use https for copyright format.  Add myself.
  * debian/changelog: Strip trailing whitespace.

Bug#910913: RFS: ghostwriter/1.7.3-1 [ITP]

[Herbert Fortes]

Hi,

On 10/13/18 7:52 AM, ghost wrote:

Package: sponsorship-requests
Severity: wishlist


 Forwarded Message  
Subject:RFS: ghostwriter/1.7.3-1 [ITP]
Date:   Mon, 08 Oct 2018 05:49:14 +1300
From:   Sebastien CHAVAUX 
To: 894...@bugs.debian.org, ghost 


 Dear mentors,

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


You sent a link to 1.7.3-1.dsc. But mentors also has others
revision number. The last one is 1.7.3-4.

The package is new in Debian. It must be 1.7.3-1. A few questions:

 - debian/changelog must has only one entry. About Debian. With an ITP number.
 - debian/compat is 10. Is there a reason to not use 11? I tried with 11
   and seems fine.
 - The package really does not have a git? Vcs-*.
 - patch files does not have info about description, author, last-update
   but as you are the upstream I think they will be removed in a next
   release.
 - debian/copyright seems to need an update. There are code with different
   license from the project. Different author from the project.

Please, fix the package.



Regards,
Herbert




* Package name: ghostwriter
  Version : 1.7.3-1
  Upstream Author :wereturtle 

* URL :http://wereturtle.github.io/ghostwriter/
* License : GPLv3
  Section : editors

 It builds those binary packages:

   ghostwriter - Distraction-free, themeable Markdown editor

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

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


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

   dget 
-xhttps://mentors.debian.net/debian/pool/main/g/ghostwriter/ghostwriter_1.7.3-1.dsc

 More information about ghostwriter
can be obtained fromhttp://wereturtle.github.io/ghostwriter/.

 Changes since the last upload:

 - Update to version 1.7.3:
 * Fixed segfault that occurred when changing the theme or interface style 
after opening the Preview Options dialog


 Regards,
  Sebastien CHAVAUX

Bug#761300: libc6: Printf("%c",'x') does not follow stdio

[Sven Joachim]

Control: retitle -1 libc6: putchar does not follow stdio

On 2014-09-12 09:10 -0700, Thomas D. Dean wrote:

> Package: libc6
> Version: 2.13-38+rpi2+deb7u3
> Severity: normal
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> Redirecting stdout in C code does not work for printf("%c",'x')
> I ssh into the system.  I want to redirect all output to stdout to
> the local terminal.  This works as expected for everything except
> when printing a single character.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
>   FILE *display_fp;
>   if ((display_fp = fopen("/dev/tty1","r+")) == NULL) {
>  perror("Open /dev/tty1");
>  return -1;
>   }
>   stdout = display_fp;
>
> Then,
>
> printf("%s","asdfasdf"); /* output to /dev/tty1 */
> printf("%c",'x'); /* output to original terminal */
>
>* What was the outcome of this action?
>
> All the output except for the "%c" case went to /dev/tty1.  The
> output in the "%c" case went to the ssh terminal

It is actually a bit more subtle than that, as gcc has its own printf
builtin function which comes into play.  Compiling the program with
-fno-builtin in fact makes it work as intended (at least with glibc
2.27-6).

Looking closer, I found that with -fno-builtin

printf("%c",'x');   works
putc('x', stdout);  works
putchar('x');   exhibits the bug

This result is rather surprising.  After all, "putchar('x')" is supposed
to do the same as "putc('x', stdout)", but here it does not.

I'm attaching the whole program, so that future researchers have less to
copy and paste.

Cheers,
   Sven

#include 
#include 

int main (int argc, char** argv)
{
  FILE *display_fp;
  if ((display_fp = fopen("/dev/tty1","r+")) == NULL) {
perror("Open /dev/tty1");
return -1;
  }
  stdout = display_fp;
  printf("%s","asdfasdf"); /* output to /dev/tty1 */
  putchar('x'); /* output to original terminal */
}

Bug#910946: xen-hypervisor-4.11-amd64: HVM DomU - 64-bit kernel cannot access emulated ATA devices

[Stephen Oberholtzer]

Package: xen-hypervisor-4.11-amd64
Version: 4.11.1~pre.20180911.5acdd26fdc+dfsg-3
Severity: normal

Dear Maintainer,

This mostly manifests as an "unable to access emulated CD-ROM drive", because 
there are no PVHVM CD-ROMs.

NOTE: I had similar issues with 4.8, so I upgraded to 4.11. This actually gave 
me *more* issues.

Attempting to boot an HVM domU from a CD image (to perform an install or rescue 
on VM data) fails when the CD uses a 64-bit kernel.
(When I use the Knoppix 'failsafe' mode, which uses a 32-bit kernel, I get 
different behavior.  Under 4.8, it boots; under 4.11, it hangs during ATA bus 
probing.)

I have tried the following ISO images:
* debian-buster-DI-alpha3-amd64-netinst.iso (tested on 4.8 only; can't use at 
all on 4.11)
* KNOPPIX_V8.2-2018-05-10-EN.iso
* debian-live-9.5.0-amd64-kde.iso
* gparted-live-0.32.0-1-amd64.iso

Here are some additional details (mostly gleaned from Knoppix, because that's 
what I was doing my testing with):
- When I try booting Knoppix in a non-accelerated VM by directly running qemu, 
everything works fine, so Xen is definitely a factor.
- PVHVM is working: non-CDROM drive shows up as xvbda
- With PVHVM disabled (xen_platform_pci=0), hda also fails to be detected
- Persuading libata to dump IDENTIFY data reveals that the returned page is all 
zeroes.


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

Kernel: Linux 4.18.6 (SMP w/12 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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xen-hypervisor-4.11-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.11-amd64 recommends:
ii  xen-hypervisor-common  4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1
ii  xen-utils-4.11 4.11.1~pre.20180911.5acdd26fdc+dfsg-3

xen-hypervisor-4.11-amd64 suggests no packages.

-- no debconf information

Bug#910943: libhtml-tidy-perl: Please upload pending 1.60-2 and coordinate with libtidy transition

[gregor herrmann]

On Sat, 13 Oct 2018 12:46:33 -0400, Boyuan Yang wrote:

> I have just uploaded an updated version of tidy-html5 onto Debian
> unstable. Your package needs to be rebuilt against new tidy to finish
> the transition (either by sourceful upload or binNMU).

Neither a binNMU nor an upload of -2 in git will work, as the package
doesn't build anymore due to test failures caused by the new
tidy-html5.

> Besides,
> currently the autopkgtest of your package would fail with new
> tidy-html5.

Right, that's the same breakage.
 
> Could you please investigate into those issues and upload a new
> version to solve the incompatibility problem?

For the future: Could you please upload breaking changes to
experimental, file bugs reports against rdeps, and only then upload
to unstable?


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Rebekka Bakken: Didn't I


signature.asc
Description: Digital Signature

Bug#910945: fontcustom: autopkgtest fails

[Jeremy Bicha]

Source: fontcustom
Version: 2.0.0+ds4-5

The fontcustom autopkgtest fails.

https://ci.debian.net/packages/f/fontcustom/testing/amd64/

Thanks,
Jeremy Bicha

Bug#910360: debbugs: get_bug_log SOAP operation truncates message

[Don Armstrong]

On Sat, 13 Oct 2018, Michael Albinus wrote:
> > I like this approach better, but I'd suggest that we do something like:
> >
> > attachments => [{attachment_id => 1,
> >  content_type => 'text/plain',
> >  content_name => 'if defined',
> >  # or whatever the right mime headers are; I forget
> >  },]
> >
> >
> > and then another SOAP interface which does something like:
> >
> > get_bug_attachment($bug_num,$msg_num,$attachment_id)
> 
> OK, I'll go along these lines.

Perfect, thanks!

> > Another option could be for the SOAP call just to return the entire
> > message without doing any MIME parsing; maybe that would be better?
> 
> Hmm, isn't this possible already via
> ?

True; though I think I'd like to avoid having the URLs be an API.

> And it has the disadvantage that the whole MIME parsing is left to the
> different SOAP clients.

Right; I think this is the main argument against this option (returning
whole message).


-- 
Don Armstrong  https://www.donarmstrong.com

I finally developed
a computer with feelings.
It just doesn't have
feelings for me.
 -- a softer world #633
http://www.asofterworld.com/index.php?id=633

Bug#910911: libgdbm6: can't read (some?) older GDBM databases

[Niko Tyni]

On Sat, Oct 13, 2018 at 01:20:55PM +0300, Niko Tyni wrote:
> Package: libgdbm6
> Version: 1.18-2
> Severity: grave
> X-Debbugs-Cc: p...@packages.debian.org, 
> libmarc-charset-p...@packages.debian.org
> 
> The libgdbm6 transition broke autopkgtest checks of src:perl and
> libmarc-charset-perl.
> 
> It looks like some GDBM databases which were working with the older
> gdbm are not readable any more with the new one.

Just to clarify, I've set the severity to 'grave' as it currently looks
probable that all GDBM (and NDBM, which presumably uses GDBM under the
hood) database files created with Perl bindings at their default settings
are unusable with the new gdbm version.

If they are indeed broken somehow and can't / won't be supported any more,
I think we need a transition period and some way to warn users that they
need to recover their local database files. But it would obviously be
much nicer to keep backward compatibility.
-- 
Niko Tyni   nt...@debian.org

Bug#903214: Dutch translation has been improved

[Bálint Réczey]

Control: fixed -1 1.6

 ezt írta (időpont: 2018. júl. 7., Szo, 20:57):
>
> Package: unattended-upgrades
> Version: 1.2
> Severity: minor
> Tags: patch, l10n
>
> Dear Maintainers
>
>
> The Dutch translation for the unattended-upgrades package has been
> improved. It has been made to apply to version 1.2 of your package.
> However, it applies to version 1.4 too.
>
> The improved translation has been reviewed within the Dutch
> translation team. Please use the new translation for the next version
> of your package.

Thanks, fixed in latest upload.

Cheers,
Balint

Bug#890200: PyQt5 package should provide an egg-info

[Bastian Germann]

There is no installed.txt file but a RECORD file which should not be
provided in this use case anyway.

>From the PEP: "The install command also provides an option to prevent
the RECORD file from being written and this option should be used when
creating system packages."

So there is no file list to be provided. The other dist-info files
(METADATA, INSTALLER) should be in python{,3}-pyqt5.

Bug#910944: [wine-development] FTBFS on arm64

[Jens Reyer]

Package: wine-development
Version: 3.17-1
Severity: serious
Tags: upstream, fixed-upstream


wine-development 3.17-1 ftbfs on arm64:

https://buildd.debian.org/status/fetch.php?pkg=wine-development=arm64=3.17-1=1539395513=0


It looks like upstream already fixed this in 3.18 with commits
6cfda8bf..d9998f77.

The build-failures on powerpc also seem to be fixed there, but I didn't
look to hard into that.

jre

Bug#910943: libhtml-tidy-perl: Please upload pending 1.60-2 and coordinate with libtidy transition

[Boyuan Yang]

Package: libhtml-tidy-perl
Severity: important
Version: 1.60-1
X-Debbugs-CC: f...@debian.org

Dear libhtml-tidy-perl maintainers,

I have just uploaded an updated version of tidy-html5 onto Debian
unstable. Your package needs to be rebuilt against new tidy to finish
the transition (either by sourceful upload or binNMU). Besides,
currently the autopkgtest of your package would fail with new
tidy-html5.

Could you please investigate into those issues and upload a new
version to solve the incompatibility problem?

Thank you very much!

--
Regards,
Boyuan Yang

Bug#910360: debbugs: get_bug_log SOAP operation truncates message

[Michael Albinus]

Don Armstrong  writes:

Hi Don,

>> Good idea. Shall I raise a (wishlist) bug report about?
>
> There's a wishlist bug for it right now:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712979

Thanks. I've just subscribed to this bug.

> I like this approach better, but I'd suggest that we do something like:
>
> attachments => [{attachment_id => 1,
>  content_type => 'text/plain',
>  content_name => 'if defined',
>  # or whatever the right mime headers are; I forget
>  },]
>
>
> and then another SOAP interface which does something like:
>
> get_bug_attachment($bug_num,$msg_num,$attachment_id)

OK, I'll go along these lines.

> Another option could be for the SOAP call just to return the entire
> message without doing any MIME parsing; maybe that would be better?

Hmm, isn't this possible already via
?

And it has the disadvantage that the whole MIME parsing is left to the
different SOAP clients.

Best regards, Michael.

Bug#897806: lmms: ftbfs with GCC-8

[Boyuan Yang]

Holger Levsen  于2018年10月13日周六 上午7:18写道：
>
> On Sat, Oct 13, 2018 at 01:03:28AM +0200, Javier Serrano Polo wrote:
> > Someone should give me access to the repository, user jasp-guest.
>
> why don't you attach your fix to this bug?

I believe he is one of package's co-maintainer and should be granted with
repository write access immediately without any hesitation.

Repo URL: https://salsa.debian.org/debian-edu-pkg-team/lmms

FYI As package lmms's last NMU uploader, I've been monitoring the status of
lmms in Debian; I own a personal packaging repo,
https://salsa.debian.org/byang/lmms ,
which contains some preliminary work for porting to Qt5. I hope that helps.

If you have any doubts, please let me know.

--
Thanks,
Boyuan Yang

Bug#910942: [wine-development] Please use wrap-and-sort

[Jens Reyer]

Package: wine-development
Version: 3.17-1
Severity: normal

Hi Mike,

in the recent uploads you re-sorted the dependencies in d/control.in
once again.  Each time this happens this takes some of my time when I
sync the src:wine packaging, or dig into issues that exist only in one
of our or other packages (upstream, downstream, other versions, ...).
Further it obfuscates packaging changes[1] and has potential for
copy errors.

To avoid these issues I suggest to use

  wrap-and-sort --wrap-always --short-indent --trailing-comma

which will keep the general layout intact, but sorts the entries
alphabetically.  You objected this change some years ago, but we didn't
discuss it in depth back then.  Hopefully I could change your mind this
time.

Greets
jre

[1] This time I just noticed you replaced the builddep "fontforge-nox |
fontforge" with "fontforge-nox".  This reverts something I did on
purpose when I implemented the font-rebuilding, so that for local
rebuilds fontforge-nox doesn't get pulled in unnecessarily if fontforge
is already installed.

Greets
jre

Bug#910934: thunar and thunar daemom stoped working

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2018-10-13 at 11:54 -0300, Daniel Norte de Moraes wrote:
> Thunar in xfce4 don't work anymore.

Looks like a local issue on your side, not a bug in Thunar.
> 
> exec "thunar" in terminal with normal user show nothing and freezes.

Is the thunar daemon running?

> exec "thunar" as daemon in terminal with root user show:

Don't do that. Why would you run it as root, there's 100% chance to ruin your
session with that.
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlvCHbIACgkQ3rYcyPpX
RFus/gf/Q3bxY8b1koTinvTbJSj5/9Ssi5lDN+o5SBMfztmE9ULbEIesCknrwUQ9
GGdBA2pnPB9mIV7OoDzNj2iPpnVasQVNYfOPCxJffldeTznA7imZoSKv6pmrdYc9
RIyiOJJzUBNU2YwrTPCo/rc9nHqF47cUvLfi90pRRK2XWpwKsrpTxoGwmlAPwims
4ONnVl8Bq90fRtCG5GSfhSdExveBD5jKTWdHAi7b60wIK8OcV6NGNOi7bAIP/DvX
X16zOsIwQ+uR1OJiyRPhb0ezVXAO+iHbUJscnS41Zgvxj+yxm5BSKpyN44221uhN
GQolH+OxZyBgNhVs/Gf0Pia+BHgPyA==
=uat9
-END PGP SIGNATURE-

Bug#887495: cups-browsed: 'No destination host name supplied by cups-browsed for printer "name", is cups-browsed running?' for all queues

[Brian Potkin]

Thank you for your reports, Jens, christoph and Marc. For the avoidance
of doubt - I am not a cups-browsed maintainer.


On Thu 11 Oct 2018 at 13:16:13 +0200, Marc Haber wrote:

> On Mon, Mar 26, 2018 at 01:43:00PM +0200, Christoph Pleger wrote:
> > I discovered the same problem on my computer today and found out that it is
> > NO coincidence that the problem occurs on the KDE desktop.
> 
> Half a year later without maintainer response on this bug, I stumbled
> about this issue and had the same issue on my system. I would NEVER have
> come to the conclusion that the desktop environment in use plays a role
> in this issue which presents itself as rooted deeply between system
> daemons and network issues.

It is unlikely to be a DE issue. I came across the behaviour today while
working in a non-KDE environment and printing from LibreOffice and with
lp.

Only Jens provides the cups version being used and modifications to
cups-browsed.conf made. For me, its cups v2.2.8 and having "driverless"
for the CreateIPPPrinterQueues directive as the only change. On the
surface, we are using different printing systems. I am only inclined to
conduct tests on unstable. "BrowseRemoteProtocols cups" doesn't motivate
me.

> The absolutely inadequate debug logging of the software in question has
> not made it any easier to debug this issue.

Has anyone managed consistently to reproduce the reported behaviour? I
haven't yet formulated a plan of attack to do so.

> That being said, my system prints again.
> 
> What did not help:
> Activate KDE screen saver, start additional session, log in with the
> same account with lxqt, try printing from there (didn't work, same
> error).
> 
> What helped:
> Log out of KDE, start new session with same account with lxqt, try
> printing from there (worked), log out of lxqrt, log into KDE with the
> smae account (worked).
> 
> This is one of the most mysterious and astonishing issuest hat I have
> encountered in my lifetime. Kudos for nailing this down to KDE.

KDE? Maybe, maybe not. Perhaps the "No destination host name supplied..."
message has three different causes?

Regards,

Brian.

Bug#910910: uscan: uninitialized value $lastversion in concatenation + error

[Xavier]

Control: found -1 2.17.6

Le 13/10/2018 à 12:18, Mattia Rizzolo a écrit :
> Package: devscripts
> Version: 2.18.6
> Severity: important
> User: devscri...@packages.debian.org
> Usertas: uscan
> 
> using the watchfile:
> 
> ~~
> version=4
> 
> # main tarball
> opts="\
> uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha|b|a)[\-\.]?\d*)$/$1~$2/,
>  \
> dversionmangle=s/\+(debian|dfsg|ds|deb)\d*$//, \
> pgpmode=next" \
> https://launchpad.net/inkscape/+download \
> (?:.*/)?inkscape[_\-\.]?(\d\S+)\.(?:tgz|txz|tar\.(?:bz2|gz|z2|xz)) debian
> 
> # find the signature
> opts=pgpmode=previous \
> https://launchpad.net/inkscape/+download \
> (?:.*/)?inkscape[_\-\.]?(\d\S+)\.(?:tgz|txz|tar\.(?:bz2|gz|z2|xz)).(?:asc|pgp|gpg|sig)
>  previous
> ~
> 
> I get:
> 
> mattia@warren ~/devel/debian/inkscape/inkscape (git)-[master] % uscan --report
> uscan warn: Unable to set versionmode=prev for the line without 
> opts=pgpmode=prev
>   in debian/watch, skipping:
>   https://launchpad.net/inkscape/+download 
> (?:.*/)?inkscape[_\-\.]?(\d\S+)\.(?:tgz|txz|tar\.(?:bz2|gz|z2|xz)).(?:asc|pgp|gpg|sig)
>  previous [Devscripts::Uscan::WatchLine: 773]
> uscan info: Scan finished
> 1 mattia@warren ~/devel/debian/inkscape/inkscape (git)-[master] %
> 
> Note the "Use of uninitialized value" message, and how the second
> WatchLine actually failed to be parsed.
> 
> I think I can nowadays redo this watchfile using pgpmode=auto (wasn't
> there when I wrote this watcfile), but still :)

Hello,

same behavior with 2.17.6 (stable) except $lastversion warning which
comes with 2.18.1. Previous versions not tested due to dependencies.

Bug#910865: prometheus-node-exporter: Files in /usr/share/doc/prometheus-node-exporter/examples/text_collector_examples/ should not be compressed

[Philipp Kern]

On 12.10.2018 20:01, Martín Ferrari wrote:
> On 12/10/18 16:47, Philipp Kern wrote:
> 
>> I'd be great if we had a better story for the scripts in
>> /usr/share/doc/prometheus-node-exporter/examples/text_collector_examples/
>> but right now one of them (and only one) is even gziped and hence not
>> directly executable (despite no configuration being needed) and that's
>> smartmon.sh.gz. Could you exclude those files from being compressed?
> 
> I agree it would be good if these are not compressed.. But as I
> understand the policy, they must be compressed if they are documentation
> or examples.
> 
> An alternative would be to ship them in
> /usr/share/promenteus-node-exporter, but I am not sure that is
> appropriate.. Maybe you can advise?
> 
>> Bonus points if there were systemd services one could turn on to run
>> them periodically. :)
> 
> True. But right now I don't have the bandwidth do write those.. I would
> be glad to add them if you write them :)

https://salsa.debian.org/go-team/packages/prometheus-node-exporter/merge_requests/1

Please test and let me know if that works / doesn't work for you. And
yes, maybe that should have been contributed upstream instead, but a
distro can be more opinionated.

Kind regards and thanks
Philipp Kern

Bug#910941: apt-get changelog uses insecure HTTP for Debian

[Ben Hutchings]

Package: apt
Version: 1.7.0
Severity: normal

The default value of Acquire::Changelogs::URI::Origin::Debian is
"http://metadata.ftp-master.debian.org/changelogs/@CHANGEPATH@_changelog;.

Since metadata.ftp-master.debian.org supports HTTP-S and redirects to
the https: scheme, the URL should be changed to use it from the start.

Ben.

Bug#910360: debbugs: get_bug_log SOAP operation truncates message

[Don Armstrong]

On Wed, 10 Oct 2018, Michael Albinus wrote:
> Since it returns just empty 'attachments' as of today, and it isn't
> specified anywhere what shall be in, it makes sense.
> 
> > 2) MIME messages are much more complicated than just a list of
> > attachments; there could be additional messages with more attachments
> > within them
> 
> Yes, although such nested attachments are rather rare in bug
> communication I guess.

The usual case where they exist is in forwarded messages or in the cases
where the BTS includes the original message as an attachment when the
bug is closed.

> Good idea. Shall I raise a (wishlist) bug report about?

There's a wishlist bug for it right now: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712979

On Thu, 11 Oct 2018, Michael Albinus wrote:
> The most simple way would be to handle any attachment like a message.
> 'header' would be the two lines 'Content-Type' and
> 'Content-Transfer-Encoding'. Every attachment would get a unique
> message number, like the messages themselves. 'get_bug_log' shall
> support the second argument $msg_num (which is still could be
> optional), in order to retrieve the bodies of attachments.

 
> Alternatively, we could have a structure in the attachments with just
> 'header' and 'msg_num', like
> 
> --8<---cut here---start->8---
>  [{header  => '...',
>body=> '...',
>attachments => [{header  => '...',
> msg_num => 11,
>},
> header  => '...',
> msg_num => 15,
>},
>{header => '...',
> msg_num => 20,
>},
>   ],
>msg_num => 5,
>   },
>   {header  => '...',
>body=> '...',
>attachments => [],
>msg_num => 8,
>   },
>  ]
> --8<---cut here---end--->8---

I like this approach better, but I'd suggest that we do something like:

attachments => [{attachment_id => 1,
 content_type => 'text/plain',
 content_name => 'if defined',
 # or whatever the right mime headers are; I forget
 },]


and then another SOAP interface which does something like:

get_bug_attachment($bug_num,$msg_num,$attachment_id)


Another option could be for the SOAP call just to return the entire
message without doing any MIME parsing; maybe that would be better?

-- 
Don Armstrong  https://www.donarmstrong.com

unbeingdead isn't beingalive
 -- e.e. cummings "31" _73 Poems_

Bug#910940: sagemath-common: fails to start with error /usr/bin/env: ‘sage-python23’: No such file or directory

[Amaury Pouly]

Package: sagemath-common
Version: 8.3-3
Severity: important
Tags: upstream

Dear Maintainer,
the sage notebook fails to start because there is no sage-python23 installed
on my system. Can be reproduced by running
  sage --notebook
A similar issue was raised for other binaries (bug #902545) but for some reason
the notebook was not patched, maybe it was forgotten or it requires a special
treatement. The upstream version of this file also uses sage-python23

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

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

Versions of packages sagemath-common depends on:
ii  python 2.7.15-3
ii  python2.7  2.7.15-4

sagemath-common recommends no packages.

sagemath-common suggests no packages.

-- no debconf information

Bug#910939: dds: Fails to build on i386

[Jeremy Bicha]

Source: dds
Version: 2.9.0-5
Severity: serious
Tags: ftbfs

dds fails to build on i386, in the build test stage:

https://buildd.debian.org/status/package.php?p=dds

Build log excerpt


debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
ln -sf ../src/libdds.so.0 examples/libdds.so
/usr/bin/make -C examples -f Makefiles/Makefile_linux DealerPar
make[2]: Entering directory '/<>/examples'
g++ -O3 -flto -fopenmp -Wshadow -Wsign-conversion -pedantic -Wall
-Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy
-Wdisabled-optimization -Winit-self -Wlogical-op
-Wmissing-declarations -Wmissing-include-dirs -Wnoexcept
-Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wsign-promo
-Wstrict-null-sentinel -Wstrict-overflow=1 -Wswitch-default -Wundef
-Werror -Wno-unused -Wno-unknown-pragmas -Wno-long-long -Wno-format -c
hands.cpp -o hands.o
g++ -O3 -flto -fopenmp -Wshadow -Wsign-conversion -pedantic -Wall
-Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy
-Wdisabled-optimization -Winit-self -Wlogical-op
-Wmissing-declarations -Wmissing-include-dirs -Wnoexcept
-Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wsign-promo
-Wstrict-null-sentinel -Wstrict-overflow=1 -Wswitch-default -Wundef
-Werror -Wno-unused -Wno-unknown-pragmas -Wno-long-long -Wno-format -c
DealerPar.cpp -o DealerPar.o
g++ -O3 -flto -fopenmp -Wshadow -Wsign-conversion -pedantic -Wall
-Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy
-Wdisabled-optimization -Winit-self -Wlogical-op
-Wmissing-declarations -Wmissing-include-dirs -Wnoexcept
-Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wsign-promo
-Wstrict-null-sentinel -Wstrict-overflow=1 -Wswitch-default -Wundef
-Werror -Wno-unused -Wno-unknown-pragmas -Wno-long-long -Wno-format
hands.o DealerPar.o -L. -ldds -o DealerPar
make[2]: Leaving directory '/<>/examples'
LD_LIBRARY_PATH=src examples/DealerPar
terminate called after throwing an instance of 'std::length_error'
  what():  vector::_M_default_append
Aborted


Thanks,
Jeremy Bicha

Bug#910894: spamass-milter: Socket permissions not set correctly if startup takes more than one second

[Don Armstrong]

On Fri, 12 Oct 2018, Will Aoki wrote:
> If spamass-milter takes too long to create the socket after daemonizing
> itself, the socket file will not exist when the startup script attempts
> to change its permissions. MTAs relying on the permission change, such
> as Postfix, will then be unable to communicate with the milter.
> 
> This is a very rare condition: I've encountered it only once in years of
> operation. It may have involved I/O contention with other VMs.
> 
> The following appeared in the system log. Note that systemd thinks
> spamass-milter startup failed, but spamass-milter was actually running.

Yeah, you're absolutely right. The correct solution (for systemd)
involves having systemd create the sockets with the right permissions,
and then pass them on to spamass-milter but that requires significant
changes to spamass-milter that I won't have time to create in the near
future.

I'll certainly accept patches which do that, though.

-- 
Don Armstrong  https://www.donarmstrong.com

Of course, there are cases where only a rare individual will have the
vision to perceive a system which governs many people's lives; a
system which had never before even been recognized as a system; then
such people often devote their lives to convincing other people that
the system really is there and that it aught to be exited from. 
 -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_

Bug#910929: gitlab: postinst fails to set up /var/lib/gitlib and nginx

[Pirate Praveen]

On 10/13/18 6:49 PM, Kusuno wrote:
Hi Kusuno,

Thanks for the report.

>  1.Wrong permission for /var/lig/gitlab.
>The correct owner id is not set on the directory.

I noticed it already and fixed it locally. I will upload the fixed
version soon.

>  2.Nginx can't start because of the wrong setup of /etc/nginx/sites-*.
>Postinst script maight fail to copy the corrent set-up file into
> /etc/nginx/sites-enable.

I will check this issue once I fix the dependency issues.

>  I don't know the way of solving these problems.
>  Thanks in advance,

Reporting and testing is important as well. Thanks.



signature.asc
Description: OpenPGP digital signature

Bug#910937: openvpn: AED decrypt error between 2 Debian stretch server when client server was restarted

[Daniel]

Package: openvpn
Version: 2.4.0-6+deb9u2
Severity: normal

Dear Maintainer,

2 servers are connected in tun mode, both running stable version. After a 
kernel upgrade
we reboot the master server, 1/2 hour or more after the client one when the 
master already
rebooted and the client correctly reopened the VPN link. Here raise the 
problem.

To solve the problem we have to restart master openvpn daemon.

On the client side we have in logs:

Sat Oct 13 17:17:17 2018 Initialization Sequence Completed
Sat Oct 13 17:17:21 2018 Authenticate/Decrypt packet error: packet HMAC 
authentication failed
Sat Oct 13 17:17:22 2018 Authenticate/Decrypt packet error: packet HMAC 
authentication failed
Sat Oct 13 17:17:23 2018 Authenticate/Decrypt packet error: packet HMAC 
authentication failed
Sat Oct 13 17:17:24 2018 Authenticate/Decrypt packet error: packet HMAC 
authentication failed
Sat Oct 13 17:17:25 2018 Authenticate/Decrypt packet error: packet HMAC 
authentication failed
Sat Oct 13 17:17:25 2018 Authenticate/Decrypt packet error: packet HMAC 
authentication failed
Sat Oct 13 17:17:26 2018 Authenticate/Decrypt packet error: packet HMAC 
authentication failed
Sat Oct 13 17:17:31 2018 Authenticate/Decrypt packet error: packet HMAC 
authentication failed
Sat Oct 13 17:17:35 2018 Authenticate/Decrypt packet error: packet HMAC 
authentication failed
Sat Oct 13 17:17:36 2018 Authenticate/Decrypt packet error: packet HMAC 
authentication failed
Sat Oct 13 17:17:37 2018 NOTE: --mute triggered...

On the server side:

Sat Oct 13 17:17:17 2018 kumquat/xx.xx.xx.138:1194 PUSH: Received control 
message: 'PUSH_REQUEST'
Sat Oct 13 17:17:17 2018 kumquat/xx.xx.xx.138:1194 PUSH: client wants to 
negotiate cipher (NCP), but server has already generated data channel keys, 
ignoring client request
Sat Oct 13 17:17:17 2018 kumquat/xx.xx.xx.138:1194 SENT CONTROL [kumquat]: 
'PUSH_REPLY,route 10.0.70.0 255.255.255.0,route 10.2.70.0 255.255.255.0,route 
192.168.10.0 255.255.255.0,route 192.168.12.0 255.255.255.0,topology p2p,ping 
10,ping-restart 120,ifconfig 10.99.0.54 10.99.0.49,peer-id 0' (status=1) 
Sat Oct 13 17:17:18 2018 kumquat/xx.xx.xx.138:1194 AEAD Decrypt error: cipher 
final failed
Sat Oct 13 17:17:19 2018 kumquat/xx.xx.xx.138:1194 AEAD Decrypt error: cipher 
final failed
Sat Oct 13 17:17:29 2018 kumquat/xx.xx.xx.138:1194 AEAD Decrypt error: cipher 
final failed
Sat Oct 13 17:17:29 2018 kumquat/xx.xx.xx.138:1194 AEAD Decrypt error: cipher 
final failed
Sat Oct 13 17:17:30 2018 kumquat/xx.xx.xx.138:1194 AEAD Decrypt error: cipher 
final failed
Sat Oct 13 17:17:31 2018 kumquat/xx.xx.xx.138:1194 AEAD Decrypt error: cipher 
final failed
Sat Oct 13 17:17:32 2018 kumquat/xx.xx.xx.138:1194 AEAD Decrypt error: cipher 
final failed
Sat Oct 13 17:17:33 2018 kumquat/xx.xx.xx.138:1194 AEAD Decrypt error: cipher 
final failed
Sat Oct 13 17:17:43 2018 kumquat/xx.xx.xx.138:1194 AEAD Decrypt error: cipher 
final failed
Sat Oct 13 17:17:43 2018 kumquat/xx.xx.xx.138:1194 AEAD Decrypt error: cipher 
final failed
Sat Oct 13 17:17:44 2018 kumquat/xx.xx.xx.138:1194 NOTE: --mute triggered...


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/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: systemd (via /run/systemd/system)

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  iproute2   4.9.0-1+deb9u1
ii  libc6  2.24-11+deb9u3
ii  liblz4-1   0.0~r131-2+b1
ii  liblzo2-2  2.08-1.2+b2
ii  libpam0g   1.1.8-3.6
ii  libpkcs11-helper1  1.21-1
ii  libssl1.0.21.0.2l-2+deb9u3
ii  libsystemd0232-25+deb9u4
ii  lsb-base   9.20161125

Versions of packages openvpn recommends:
ii  easy-rsa  2.2.2-2

Versions of packages openvpn suggests:
ii  openssl 1.1.0f-3+deb9u2
pn  resolvconf  

-- Configuration Files:
/etc/default/openvpn changed:
AUTOSTART="mango"
OPTARGS=""
OMIT_SENDSIGS=0

/etc/openvpn/update-resolv-conf changed:
[ -x /sbin/resolvconf ] || exit 0
case $script_type in
up)
for optionname in ${!foreign_option_*} ; do
option="${!optionname}"
echo $option
part1=$(echo "$option" | cut -d " " -f 1)
if [ "$part1" == "dhcp-option" ] ; then
part2=$(echo "$option" | cut -d " " -f 2)
part3=$(echo "$option" | cut -d " " -f 3)
if [ "$part2" == "DNS" ] ; then
IF_DNS_NAMESERVERS="$IF_DNS_NAMESERVERS $part3"
fi
if [ "$part2" == "DOMAIN" ] ; then
IF_DNS_SEARCH="$IF_DNS_SEARCH $part3"

Bug#910853: closed by Sebastiaan Couwenberg (Re: Bug#910853: qgis: Crashes on attempt to use Python console)

[Shai Berger]

Tried again on a cleaner system, and indeed, cannot reproduce.

Thanks, and sorry for the noise.

Bug#910936: ITP: praelector -- helps one to read a latin phrase in a "natural" way

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: praelector
  Version : 0.1
  Upstream Author : Yves Ouvrard 
* URL : https://github.com/ycollatin/Praelector
* License : GPL-3+
  Programming Lang: C++
  Description : helps one to read a latin phrase in a "natural" way

 William G. Hale (1849-1928) explained in "The Art Of Reading Latin"
 principles of such a "natural" way of reading latin sentences, which is
 radically different of the way of reading our modern languages.

 - this package enriches Debian with a tool to study latin language
   it is a good fellow for the packages collatinus and felix-latin already
   available in Debian.

 - I shall maitain it on the behalf of my friend Yves Ouvrard, the packaging
   work is in salsa.debian.org

Bug#910935: cmake-extras: GMockConfig.cmake doesn't work with googletest/1.8.1-1

[Shengjing Zhu]

Package: cmake-extras
Severity: serious
Control: affects -1 googletest

Dear Maintainer,

GMockConfig.cmake doesn't work with googletest/1.8.1-1 in sid.
I'm not sure whether it's bug in googletest or not.

Take ayatana-indicator-power for example, it depends gmock_main target
from GMockConfig.cmake. It will ftbfs with,

cd /<>/obj-x86_64-linux-gnu/tests && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/test-device.dir/link.txt --verbose=1
/usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c++11  -Wall -Wextra -Wpedantic -Wformat=2 
-Wno-missing-field-initializers -Wno-weak-vtables -Wno-global-constructors  
-Wl,-z,relro -Wl,-z,now -rdynamic CMakeFiles/test-device.dir/test-device.cc.o  
-o test-device ../src/libayatanaindicatorpowerservice.a -ldbustest -lglib-2.0 
-lgio-2.0 -lnotify -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 
-lgio-2.0 -lnotify -lgdk_pixbuf-2.0 -lgobject-2.0 gmock/gtest/libgtest.a 
-lpthread gmock/libgmock.a gmock/libgmock_main.a 
/usr/bin/ld: gmock/libgmock_main.a(gmock_main.cc.o): in function `main':
/usr/src/googletest/googlemock/src/gmock_main.cc:52: undefined reference to 
`testing::InitGoogleMock(int*, char**)'


Following is workaround for it, but I'm not expert in cmake...

--- src/GMock/GMockConfig.cmake.orig2018-10-13 23:01:36.681319674 +0800
+++ src/GMock/GMockConfig.cmake 2018-10-13 23:01:54.405374263 +0800
@@ -77,7 +77,7 @@
 
 add_library(gmock_main INTERFACE)
 target_include_directories(gmock_main INTERFACE ${GMOCK_INCLUDE_DIRS})
-target_link_libraries(gmock_main INTERFACE ${findgmock_gmock_main_lib} gmock)
+target_link_libraries(gmock_main INTERFACE ${findgmock_gmock_main_lib} gmock 
gtest_main)
 
 set(GTEST_LIBRARIES gtest)
 set(GTEST_MAIN_LIBRARIES gtest_main)

 -- 
 Shengjing Zhu