Bug#875190: [shiboken] Future Qt4 removal from Buster

[Didier 'OdyX' Raboud]

Le lundi, 30 septembre 2019, 22.04:05 h CEST Moritz Mühlenhoff a écrit :
> On Sat, Sep 09, 2017 at 11:09:45PM +0200, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > Source: shiboken
> > Version: 1.2.2-5
> > Severity: wishlist
> > User: debian-qt-...@lists.debian.org
> > Usertags: qt4-removal
> > 
> > 
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as [announced] in:
> > 
> > [announced]
> > 
> > 
> > Currently Qt4 has been dead upstream and we are starting to have problems
> > maintaining it, like for example in the [OpenSSL 1.1 support] case.
> > 
> > [OpenSSL 1.1 support]
> > 
> > 
> > In order to make this move, all packages directly or indirectly depending
> > on the Qt4 libraries have to either get ported to Qt5 or eventually get
> > removed from the Debian repositories.
> > 
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether there
> > are suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
> 
> There are no reverse dependencies of src:shiboken in unstable and it has
> been replaced by src:pyside2, let's remove from the archive?

As maintainer: agreed!

Cheers,
OdyX

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

Bug#583847: picard: allow sorting by album title or artist

[Philipp Wolfer]

Issue can be closed. This functionality had been added in the 0.14 release
in 2011 [1] It is working now in current Debian packages.

[1] https://picard.musicbrainz.org/changelog/#release-0.14

On Mon, 31 May 2010 03:35:07 + "brian m. carlson" <
sand...@crustytoothpaste.ath.cx> wrote:
> Package: picard
> Version: 0.11-2.1+b1
> Severity: normal
>
> When I process files through picard for tagging, I am unable to sort (in
> the right pane) based on album title or artist.  I would very much like
> to be able to do that, since sometimes tracks from the same album appear
> in multiple editions.
>
> This is severity normal because although it is a request for a new
> feature, the lack of it makes picard *very* difficult to use for
> large-scale (approximately 1200 song) tagging.
>
> -- System Information:
> Debian Release: squeeze/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.34-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages picard depends on:
> ii  libavcodec52   5:0.6~svn20100526-0.0 library to encode decode
multimedi
> ii  libavformat52  5:0.6~svn20100526-0.0 ffmpeg file format library
> ii  libc6  2.10.2-9  Embedded GNU C Library:
Shared lib
> ii  libdiscid0 0.2.2-1   Library for creating
MusicBrainz D
> ii  libfftw3-3 3.2.2-1   library for computing Fast
Fourier
> ii  libgcc11:4.5-20091226-1  GCC support library
> ii  libofa00.9.3-3.1 Library for acoustic
fingerprintin
> ii  libstdc++6 4.5-20091226-1The GNU Standard C++ Library
v3
> ii  python 2.5.4-9   An interactive high-level
object-o
> ii  python-mutagen 1.15-2audio metadata editing
library
> ii  python-qt4 4.7.3-1   Python bindings for Qt4
> ii  python-support 1.0.8 automated rebuilding support
for P
>
> picard recommends no packages.
>
> picard suggests no packages.
>
> -- no debconf information
>
> --
> brian m. carlson / brian with sandals: Houston, Texas, US
> +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
> OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Bug#941463: 3dldf: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended

[Hilmar Preuße]

Control: tags 941463 + pending

Am 01.10.2019 um 07:27 teilte Steve Langasek mit:

> The texlive-generic-recommended transitional package has been dropped from
> texlive-base in sid.  Please update your build-dependency (and Recommends)
> to texlive-plain-generic instead.
> 
Fixed on salsa, tag pending. We could do an upload, but it will FTBFS
anywayI guess.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#941440: RFS: wxmaxima/19.09.1-1 -- GUI for the computer algebra system Maxima

[Adam Borowski]

On Mon, Sep 30, 2019 at 05:29:06PM +0200, Gunter Königsmann wrote:
>  * Package name: wxmaxima
>Version : 19.09.1-1

> Changes since the last upload:
> 
>* A new upstream version
>* The debian package now uses GTK3
>* Bumped the standards version to 3.9.8
>* New build depends for the automatic tests: netcat-openbsd, xvfb,
>  debian-file-utils and appstream-util

Alas, it FTBFSes for me:
xvfb-run: error: xauth command not found

http://ix.io/1LkW

-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#685102: picard: sends bad requests to server

[Philipp Wolfer]

I think this issue should be closed. This was reported for a very old
release and is definitely working in the 2.x releases.

If this should be still an issue for anyone this should be brought upstream.

Philipp

On Thu, 16 Aug 2012 21:29:58 +0200 Johannes Rohr  wrote:
> Package: picard
> Version: 1.0-1
> Severity: normal
>
> Lately, picard has trouble downloading album data. After dragging some
music files (generated and tagged by sound-juicer) to the window on the
right, picard instead of displaying the album title displays "unable to
load [MBID]"
>
> Below is an error message from the console:
>
> E: 140379710048000 21:22:54 Network request error for
http://musicbrainz.org:80/ws/2/release/e3f2c3d7-d289-4796-8b4e-407692dea96f;
e3f2c3d7-d289-4796-8b4e-407692dea96f?inc=release-groups+media+recordings+puids+artist-credits+artists+aliases+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels:
Error downloading
http://musicbrainz.org:80/ws/2/release/e3f2c3d7-d289-4796-8b4e-407692dea96f;%20e3f2c3d7-d289-4796-8b4e-407692dea96f?inc=release-groups+media+recordings+puids+artist-credits+artists+aliases+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels
- server replied: Bad Request (QT code 299, HTTP code 400)
> E: 140379710048000 21:22:54 u'Error downloading
http://musicbrainz.org:80/ws/2/release/e3f2c3d7-d289-4796-8b4e-407692dea96f;%20e3f2c3d7-d289-4796-8b4e-407692dea96f?inc=release-groups+media+recordings+puids+artist-credits+artists+aliases+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels
- server replied: Bad Request'
>
> When I look up the album directly on the musicbrainz website instead and
click the "tagger" icon, picard retrieves the album data just fine.
>
> This doesn't happen with every music file, but with many if not most of
them.
>
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (250, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages picard depends on:
> ii  libavcodec537:0.10.3-dmo1
> ii  libavformat53   7:0.10.3-dmo1
> ii  libc6   2.13-35
> ii  libdiscid0  0.2.2-3
> ii  libfftw3-3  3.3.2-3
> ii  libgcc1 1:4.7.1-2
> ii  libofa0 0.9.3-5
> ii  libstdc++6  4.7.1-2
> ii  python  2.7.3~rc2-1
> ii  python-mutagen  1.20-1
> ii  python-qt4  4.9.3-4
> ii  python2.7   2.7.3-3
>
> picard recommends no packages.
>
> picard suggests no packages.
>
> -- no debconf information
>
>

Bug#656884: picard: Can't use directories on 'File naming' Options

[Philipp Wolfer]

I think this issue should be closed. This was reported for a very old
release and is definitely working in the 2.x releases.

If this should be still an issue for anyone this should be brought upstream.

Philipp

On Sun, 22 Jan 2012 16:48:36 + =?utf-8?q?Lu=C3=ADs_Picciochi_Oliveira?=
 wrote:
> Package: picard
> Version: 0.16-1
> Severity: normal
>
> Hi,
>
> According to the picard documentation [1,2], it should be possible to
define
> directories on the "File Naming" Options panel. Music files would then be
moved
> to those directories according to the defined rules. However, when I
define
> something like:
>
> %artist$/%tracknumber% - %title%
>
> The tracks get named only according to '%tracknumber% - %title%' and
anything
> before the last slash is ignored.
> I used this feature in previous versions and it worked well. I only
noticed
> this problem on this latest update (from 0.11-2.1 to 0.16-1).
>
> Best regards,
> Luís Picciochi Oliveira
>
>
> 1 - http://musicbrainz.org/doc/MusicBrainz_Picard/Documentation/Options
> 2 - http://musicbrainz.org/doc/MusicBrainz_Picard/Documentation/Scripting
>
>
>
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: i386 (i686)
>
> Kernel: Linux 3.1.0-1-686-pae (SMP w/2 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages picard depends on:
> ii  libavcodec534:0.7.3-2
> ii  libavformat53   4:0.7.3-2
> ii  libc6   2.13-24
> ii  libdiscid0  0.2.2-2
> ii  libfftw3-3  3.3-1
> ii  libgcc1 1:4.6.2-11
> ii  libofa0 0.9.3-4
> ii  libstdc++6  4.6.2-11
> ii  python  2.7.2-9
> ii  python-mutagen  1.20-1
> ii  python-qt4  4.9-2
> ii  python2.7   2.7.2-8
>
> picard recommends no packages.
>
> picard suggests no packages.
>
> -- no debconf information
>
>
>

Bug#941464: picard: Crash when using Spanish locale

[Philipp Wolfer]

Package: picard

Version: 2.2.1-1

Picard 2.2.1 in Buster crashes when using the Spanish locale and
opening options. This is a bug that we have fixed upstream [1] in the
2.1.3 release.

I think this package should actually be updated to the 2.1.3 release
(which is a bugfix release only not introducing new functionality) or
if this is not possible at the very minimum include the patch that
fixed the translations [2]


[1] https://tickets.metabrainz.org/browse/PICARD-1461
[2] 
https://github.com/metabrainz/picard/commit/5b7b29df2ae9dd5b860326fc5260e73fde74d0a5

Bug#941463: 3dldf: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended

[Norbert Preining]

tags 941463 + pending
thanks

> The texlive-generic-recommended transitional package has been dropped from
> texlive-base in sid.  Please update your build-dependency (and Recommends)
> to texlive-plain-generic instead.

Already in git since some time, but not uploaded by now.

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#941356: less: silently hides formatting characters

[Milan Kupcevic]

On 9/29/19 7:56 AM, Adam Borowski wrote:
> 
> [Severity set to important as this regression breaks scripts and most
> file formats, making the cause not even show up on "git diff" etc.]


I have not seen git developers being bothered by this change, so far.


> Hi, since v494 (released upstream in 2017 but not uploaded to Debian until a
> few days ago), control characters with the Unicode "category" property of Cf
> are ignored instead of being displayed as <1234> as before.


It seems this was a deliberate upstream change. Please engage the
upstream development project if you want to argue about their decision.
In the meantime I'm setting severity of this bug report to wishlist and
tagging it as an upstream issue.


Milan



signature.asc
Description: OpenPGP digital signature

Bug#941463: 3dldf: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended

[Steve Langasek]

Package: 3dldf
Version: 2.0.3+dfsg-7
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear maintainers,

The texlive-generic-recommended transitional package has been dropped from
texlive-base in sid.  Please update your build-dependency (and Recommends)
to texlive-plain-generic instead.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru 3dldf-2.0.3+dfsg/debian/control 3dldf-2.0.3+dfsg/debian/control
--- 3dldf-2.0.3+dfsg/debian/control 2018-02-16 23:23:38.0 -0800
+++ 3dldf-2.0.3+dfsg/debian/control 2019-09-30 22:13:12.0 -0700
@@ -9,7 +9,7 @@
  libgsl-dev,
  texlive-binaries, tex-common, texlive-base,
  texlive-metapost,
- texlive-generic-recommended,
+ texlive-plain-generic,
  texlive-formats-extra,
  texlive-fonts-extra,
 # cm-super,
@@ -41,7 +41,7 @@
 Depends: ${misc:Depends}
 Recommends:
  3dldf,
- texlive-generic-recommended, texlive-formats-extra,
+ texlive-plain-generic, texlive-formats-extra,
  ghostscript
 Description: 3D drawing with MetaPost output -- examples
  GNU 3DLDF implements an interpreter for a METAFONT-like language for

Bug#849308: wireguard: Wireguard should not transition to stable yet

[Willem van den Akker]

Hi Daniel,

I offer by help for maintaining packaging WG.
Please let me know how I can help.

/Willem

Bug#941462: logtool FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: logtool
Version: 1.2.8-10
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

logtool fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of fixing that is using
dh_auto_configure. Even then, it configures again during dh_auto_build
via the upstream makefile as it treats a missing config.cache as a
reason to rerun ./configure without flags. Unfortunately, ./configure
does not create a config.cache. The attached patch makes logtool cross
buildable. Please consider applying it.

Helmut
diff -u logtool-1.2.8/debian/changelog logtool-1.2.8/debian/changelog
--- logtool-1.2.8/debian/changelog
+++ logtool-1.2.8/debian/changelog
@@ -1,3 +1,12 @@
+logtool (1.2.8-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Configure only once.
++ Let dh_auto_configure pass --host to ./configure.
+
+ -- Helmut Grohne   Tue, 01 Oct 2019 06:37:35 +0200
+
 logtool (1.2.8-10) unstable; urgency=medium
 
   * Revert the compat bump. This may have side effects that are hard to
diff -u logtool-1.2.8/debian/rules logtool-1.2.8/debian/rules
--- logtool-1.2.8/debian/rules
+++ logtool-1.2.8/debian/rules
@@ -10 +10,2 @@
-   ./configure --prefix=/usr --sysconfdir=/etc/logtool 
--mandir=/usr/share/man
+   touch config.cache # ./configure doesn't create it. keep make from 
rerunning ./configure
+   dh_auto_configure -- --sysconfdir=/etc/logtool

Bug#940902: doesn't read the data

[Andreas Tille]

On Mon, Sep 30, 2019 at 11:47:14PM +0200, Ana Guerrero Lopez wrote:
> > Thanks to you.  I'd be happy if you could check master[1] and confirm
> > that it is OK.  I can even give you commit permissions so you can change
> > anything you feel sensible and do the team upload yourself.
> 
> Please, add me to the group, I'll take care of the testing and upload.

Welcome to the team, Andreas. 

-- 
http://fam-tille.de

Bug#934237: [pkg-gnupg-maint] Bug#934237: Bug#934237: yubikey communication fails on startup

[Daniel Kahn Gillmor]

On Thu 2019-08-08 23:17:00 -0400, Antoine Beaupré wrote:
> So if I could rephrase that bug, I'd say that gpg-agent is
> "sticky". Whenever it gets called first is what determines the TTY. If
> that TTY is messed up (because it gets called too early in the session),
> it's forever doomed and needs to restart or be retold where it is:
>
> gpg-connect-agent UPDATESTARTUPTTY /bye
>
> This seems sub-optimal. It's also quite strange it affects only
> authentication and not signing: it might be something specific to
> gpg-agent's SSH support.

it is.  gpg-agent's SSH support uses OpenSSH's ssh-agent protocol, which
has no way of indicating to the agent how/where the prompts should
happen.

gpg-agent's native mechanism uses an entirely different protocol (on a
different socket too).  The gpg-agent mechansism *does* provide a way
for the invoking client to tell the agent where the prompting should
happen.  This means that when gpg itself talks to gpg-agent, it sets the
DISPLAY, DBUS_SESSION_BUS_ADDRESS, GPG_TTY, etc. options explicitly.

But when ssh talks to what it thinks is the ssh-agent, it provides no
such information.

If you use a graphical environment with a per-user dbus session which is
initialized with the rest of your systemd user session manager, then you
should also use a pinentry that communicates over dbus -- in this case,
gpg-agent should be started with knowledge of the dbus session, and so
the pinentry should automatically know how to communicate with the user.

afaik, pinentry-gnome3 is the only pinentry that communicates over dbus
at the moment.

so, the recommended way of avoiding these problems longer term on a
system with a graphical environment is (as the superuser):

  apt install pinentry-gnome3 dbus-user-session
  update-alternatives --set pinentry /usr/bin/pinentry-gnome3

and then log out and log back in again.

If that doesn't work for you, i'd definitely like to know about it.

   --dkg


signature.asc
Description: PGP signature

Bug#941399: dino-im FTCBFS: configures for the build architecture

[Helmut Grohne]

Hi Martin,

On Mon, Sep 30, 2019 at 05:07:09PM +0200, Martin wrote:
> Note this remark by upstream in xmpp:c...@dino.im?join :
> 
> > [12:55:59] ‎larma‎: debacle: I did cross compile dino. You
> > probably don't want to use the ./configure script for it, but
> > use CMake directly

Yes, that's what my patch did.

> ‎> [13:00:14] ‎larma‎: All I had to do was to set PKG_CONFIG_PATH
> > and CMAKE_TOOLCHAIN_FILE

In Debian, PKG_CONFIG_PATH is set by a cross wrapper. We set
PKG_CONFIG_EXECUTABLE. dh_auto_configure takes care of that and it
generally just works.

> ‎> [13:01:13] ‎larma‎: We don't use valac's compilation feature (we
> > only use it for transpiling), so there shouldn't be any issues
> > specific to vala
> ‎> [13:03:29] ‎larma‎: But that was on Fedora, not Debian

That's good. The problem here is with the packaging of valac, not with
dino-im. We need a valac for the build architecture (to be able to run
it), but dependency resolution gets us a host architecture one.
Executing it yields an "Exec format error". It needs to be fixed on the
valac side. I expect that dino-im cross builds just fine once we fix the
packaging of valac. Thanks for your help.

Unfortunately, fixing the valac side is not trivial, because it also
supports a compiling mode. Also unfortunately, the valac maintainers
seem to be very busy and unable to reply to bug reports in a timely
manner.

Helmut

Bug#787794: Lieber Freund (Assalamu Alaikum),

[AISHA GADDAFI]

-- 
Lieber Freund (Assalamu Alaikum),

Ich bin vor einer privaten Suche auf Ihren E-Mail-Kontakt gestoßen
Ihre Hilfe. Mein Name ist Aisha Al-Qaddafi, alleinerziehende Mutter und Witwe
mit drei Kindern. Ich bin die einzige biologische Tochter des späten Libyers
Präsident (Oberst Muammar Gaddafi).

Ich habe Investmentfonds im Wert von siebenundzwanzig Millionen und
fünfhunderttausend
United State Dollar (27.500.000,00 $) und ich brauche eine
vertrauenswürdige Investition
Manager / Partner wegen meines aktuellen Flüchtlingsstatus bin ich jedoch
Interesse an Ihnen für die Unterstützung von Investitionsprojekten in
Ihrem Land, kann sein
Von dort aus können wir in nächster Zukunft eine Geschäftsbeziehung aufbauen.

Ich bin gerne bereit, mit Ihnen das Verhältnis der Beteiligungsquote zu teilen
stützen Sie sich auf die zukünftigen Investitionen, die Gewinne erzielen.

Wenn Sie bereit sind, dieses Projekt in meinem Namen durchzuführen,
antworten Sie bitte dringend
Damit ich Ihnen mehr Informationen über die Investmentfonds geben kann.

Ihre dringende Antwort wird geschätzt. Schreiben Sie mir an diese
E-Mail-Adresse (
ayishagdda...@mail.com ) zur weiteren Diskussion.

Freundliche Grüße
Frau Aisha Al-Gaddafi
Antwort an: ayishagdda...@mail.com

Bug#941445: texlive-base: upgrade fails trying to overwrite files from texlive-doc-base 2019.20190830-1

[Norbert Preining]

reassign 941445 texlive-latex-extra
merge 941441 941445
tag 941441 + pending
thanks

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#941461: xfce4: Getting out of lock screen is complicated

[Jiff]

Package: xfce4
Version: 4.12.5
Severity: normal

Dear Maintainer,

   * What led up to the situation?

This is on a laptop msi CX61 2PC 8 GB RAM (no RAM problem), with an Optimus
nvidia graphic card that is unused, no packages at all about it ; I only use
the intel one. I have another screen (1920x1080) plugged on the VGA output that
right-extends it's tiny display.

As the Xfce4 fast user switch package disappeared (?), I use the lock screen
trick to open a 2nd session for another user, flipping between both by locking
again and re-login from one to another.

As soon as the screen's locked, the power button goes orange (nvidia card) then
(~10-12s) comes back to blue (intel) and then, both screens are off.
I tried everything, but the only possible outcome is to CTRL-ALT-F1, which
works and revive the laptop screen, then ALT-F7 to come back to Xfce, wait
5-6s, then the padlock appears on both screens, ~12s and the login screen of
lightdm comes to live on both screens.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

This is the only way I found to get the screens back to live after a lock.
The problem is, it is a long procedure to switch from one user to the other.




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

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

Versions of packages xfce4 depends on:
ii  gtk2-engines-xfce3.2.0-4
ii  libxfce4ui-utils 4.12.1-3
ii  thunar   1.8.4-1
ii  xfce4-appfinder  4.12.0-2
ii  xfce4-panel  4.12.2-1
ii  xfce4-pulseaudio-plugin  0.4.1-1
ii  xfce4-session4.12.1-6
ii  xfce4-settings   4.12.4-1
ii  xfconf   4.12.1-1
ii  xfdesktop4   4.12.4-2
ii  xfwm44.12.5-1

Versions of packages xfce4 recommends:
ii  desktop-base  10.0.2
ii  tango-icon-theme  0.8.90-7
ii  thunar-volman 0.9.1-1
ii  xfce4-notifyd 0.4.3-1
ii  xorg  1:7.7+19

Versions of packages xfce4 suggests:
ii  gtk3-engines-xfce3.2.0-4
ii  xfce4-goodies4.12.6
ii  xfce4-power-manager  1.6.1-1

-- no debconf information

Bug#935526: pulseaudio: Pulseaudio no longer recognizes USB devices

[Felipe Sateler]

On Sun, Sep 15, 2019 at 9:42 AM Guus Sliepen  wrote:

> On Mon, Sep 09, 2019 at 08:53:46PM -0300, Felipe Sateler wrote:
>
> > Could you please attach a verbose log of pulseaudio, both versions?
> > https://wiki.ubuntu.com/PulseAudio/Log
>
> Attached are the logs from both versions. Let me know if I need to
> provide any other information.


The log has this:


(   2.849|   0.000) D: [pulseaudio] conf-parser.c: Failed to open
configuration file
'/usr/share/pulseaudio/alsa-mixer/profile-sets/steelseries-arctis-usb-audio.conf':
No such file or directory

This is weird, because that file is not loaded anymore:

% grep steelseries /lib/udev/rules.d/90-pulseaudio.rules
ATTRS{idVendor}=="1038", ATTRS{idProduct}=="1250",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-5-usb-audio.conf"
ATTRS{idVendor}=="1038", ATTRS{idProduct}=="1260",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
ATTRS{idVendor}=="1038", ATTRS{idProduct}=="12ad",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
ATTRS{idVendor}=="1038", ATTRS{idProduct}=="1294",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
ATTRS{idVendor}=="1038", ATTRS{idProduct}=="1730",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"

So, it seems udev has not picked up the change. There are two options:

1. Have you rebooted your computer since the upgrade? If so, please try
running `udevadm trigger` as root. Maybe udev for some reason did not pick
up the change.
2. Do you have any other file in /{lib,etc}/udev/rules.d mentioning that
file?

-- 

Saludos,
Felipe Sateler

Bug#941460: redshift-gtk: Icon doesn't show in the Xfce4 notification area

[Jiff]

Package: redshift-gtk
Version: 1.12-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Launching it on command line: redshift-gtk &

It is working, but it's icon doesn't show anymore into the Xfce4 notification
area.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Nothing - on second thought, it may not be tied to redshift-gtk but to Xfce4
itself, but I don't know how to assess that.

   * What was the outcome of this action?

Nothing (which is quite logical;p)




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

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

Versions of packages redshift-gtk depends on:
ii  gir1.2-appindicator3-0.1  0.4.92-7
ii  python3   3.7.3-1
ii  python3-gi3.30.4-1
ii  python3-xdg   0.25-5
ii  redshift  1.12-2

Versions of packages redshift-gtk recommends:
ii  at-spi2-core  2.30.0-7

redshift-gtk suggests no packages.

-- no debconf information

Bug#941459: blueman: Refuses to start on command line

[Jiff]

Package: blueman
Version: 2.0.8-1
Severity: important
Tags: patch

Dear Maintainer,

   * What led up to the situation?

After an upgrade, launching the blueman applet from a terminal: blueman-applet
&

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

blueman-applet complained:

/usr/lib/python3/dist-packages/blueman/plugins/applet/AppIndicator.py:8:
PyGIWarning: AppIndicator3 was imported without specifying a version first. Use
gi.require_version('AppIndicator3', '0.1') before import to ensure that the
right version gets loaded.
  from gi.repository import AppIndicator3 as girAppIndicator

and did not start.

I edited: /usr/lib/python3/dist-packages/blueman/plugins/applet/AppIndicator.py
to add 2 lines:

from gi.repository import require_version
gi.require_version('AppIndicator3', '0.1')

   * What was the outcome of this action?

blueman-applet stopped complaining and started.

   * What outcome did you expect instead?

Blueman to draw his blue sword, me my black sword and the winner to reprogram
the other one ;)



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

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

Versions of packages blueman depends on:
ii  bluez 5.50-1
ii  bluez-obexd   5.50-1
ii  dbus  1.12.16-1
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.1-2
ii  gir1.2-appindicator3-0.1  0.4.92-7
ii  gir1.2-gdkpixbuf-2.0  2.38.1+dfsg-1
ii  gir1.2-glib-2.0   1.58.3-2
ii  gir1.2-gtk-3.03.24.5-1
ii  gir1.2-notify-0.7 0.7.7-4
ii  gir1.2-pango-1.0  1.42.4-7~deb10u1
ii  gnome-icon-theme  3.12.0-3
ii  libbluetooth3 5.50-1
ii  libc6 2.28-10
ii  libglib2.0-0  2.58.3-2+deb10u1
ii  libpulse-mainloop-glib0   12.2-4+deb10u1
ii  libpython3.7  3.7.3-2
ii  librsvg2-common   2.44.10-2.1
ii  mate-icon-theme   1.20.3-1
ii  notification-daemon   3.20.0-4
ii  python3   3.7.3-1
ii  python3-cairo 1.16.2-1+b1
ii  python3-dbus  1.2.8-3
ii  python3-gi3.30.4-1
ii  python3-gi-cairo  3.30.4-1
ii  xfce4-notifyd [notification-daemon]   0.4.3-1

Versions of packages blueman recommends:
ii  policykit-1  0.105-25
ii  pulseaudio-module-bluetooth  12.2-4+deb10u1

blueman suggests no packages.

-- no debconf information
8,9d7
< from gi.repository import require_version
< gi.require_version('AppIndicator3', '0.1')

Bug#939539: Docker is running!

[Arnaud Rebillout]

On 10/1/19 7:05 AM, Felicia wrote:

I found two things to solve this issue:

1) edit /etc/default/grub and edit the line GRUB_CMDLINE_LINUX to contain:

     GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

2) Run the following script:

     https://github.com/moby/moby/issues/8791#issuecomment-60874893



Congrats! For your information, I ran 
/usr/share/docker.io/contrib/check-config.sh on my system. To compare 
with the lines you mentioned, here's what I get:



- CONFIG_NF_NAT_IPV4: missing
- CONFIG_NF_NAT_NEEDED: missing
- CONFIG_CGROUP_HUGETLB: missing
    - CONFIG_AUFS_FS: missing

- cgroup hierarchy: properly mounted [/sys/fs/cgroup]

- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: enabled
- CONFIG_CGROUP_SCHED: enabled

- CONFIG_LEGACY_VSYSCALL_NONE: enabled

The important point, as you noted, is the cgroup part. It' surprising 
that it's not enabled for you, and that you need to enable it in the 
grub kernel cmdline. There should be no need to do that.


Are you running a custom kernel or something?

For example, what's the output of:

$ apt policy linux-image-amd64
linux-image-amd64:
  Installed: 5.2+107
  Candidate: 5.2+107
  Version table:
 *** 5.2+107 500
500 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
 5.2+106~bpo10+1 900
100 http://deb.debian.org/debian buster-backports/main amd64 Packages
 4.19+105+deb10u1 990
990 http://deb.debian.org/debian buster/main amd64 Packages


Regards,

  Arnaud

Bug#941246: RFP: elpa-ansible -- ansible syntax highlighting, completion, and yasnippet templates for Emacs

[Trent W. Buck]

Nicholas,

Eliding the parts I agree with...

Nicholas D Steeves wrote:
> I suspect that the conversion to a derived major mode should be done
> before this software is suitable for a Debian stable release.

I agree making it a local minor mode, instead of a derived major mode
(derived from yaml-mode) is a weird decision.

I *guess* this is because (AIUI) ansible has three file formats:

  1. yaml + jinja2
 (used for playbook.yaml and inventory.yaml)

  2. ini + weird magic
 (used for inventory.ini, instead of newer inventory.yaml)

  3. plain jinja2 templates
 (e.g. httpd.conf.j2, which becomes /etc/httpd.conf)

...and the ansible-mode author wanted to add the ansible
domain-specific magic to all three.

Personally I only really care about #1, so define-derived-mode from
yaml-mode makes sense to me.

> Were you able to tell if the autocompletion and yasnippets are so
> limited as to be not useful to people who use this functionality?  The
> snippets appear to be surprisingly comprehensive to me.

Sorry, I did not investigate this closely.

If you install ansible on any old system, you can run

ansible-doc --list   # pick one, e.g. "copy"
ansible-doc copy

and scroll down to look at the examples.
You can see the same information here (slightly different version):

https://docs.ansible.com/ansible/latest/modules/copy_module.html#copy-module

The snippets look to me as if they are derived from these examples.

For me, alarm bells immediately went off because the emacs-ansible
snippets can get out of sync with what the actual ansible codebase
expects.

Most of the snippets seemed to only be 1 or 2 attributes anyway, something like

- name: $1
  copy: dest=$2 $*

I wouldn't want to be in charge of constantly keeping those in sync with 
ansible.

...having just written that, I recall that some ansible modules are
flagged with "Red Hat promises not to break backwards compatibility",
so I guess those would be OK to have snippets for.

> > It depends on packages named simply "s" and "f" (oy!), but
> > those appear to be in Debian already (elpa-s and elpa-f).
> > I installed those then did
> >
> > emacs -nw -q \
> > -l emacs-ansible/ansible.el \
> > -eval "(require 'yaml-mode)" \
> > cyber-ansible/Cyber-BCP.yaml \
> > -eval '(ansible +1)'
> 
> Excellent work, are you interested in joining the Debian Emacsen team?
> It's clear you have the skills. :-)  I'd be happy to answer questions
> and provide guidance if necessary.

E, maybe.  :-)
You can find me (as "twb") on #emacs on irc.freenode.net every day.
We can chat about it there.

> > ...and yeah OK, there's more color.  It treats "name: " specially,
> > and it tries to recognize the embedded jinja2 {{}} {%%} crap without
> > actually resorting to using an actual jinja major mode (via mumamo or
> > mmm).
> 
> This is the most interesting feature imho, eg: a lightweight jinja2
> parser, and should go in the long description.  Whoever fulfills this
> RFP should verify that this functionality can catch jinja2 syntax errors.

I think I oversold that.
It looks to me like it's just a single font lock for {{}}:

(defvar ansible-playbook-font-lock
  `(("\\({{\\)\\([^}]+\\)\\(}}\\)"
  . #)

I would much rather have a "real" jinja2-mode be mixed into yaml-mode,
similar to how mhtml-mode handles CSS-in-HTML today.
(I realize this is a hard and unfun problem in Emacs.)

Once major gotcha: in ansible files,
the "when" clause has an implicit {{}}, where other clauses don't.
That's definitely domain-specific (i.e. ansible-only) behaviour.

So e.g.

name: eat {{animal}} for food
eat: food={{animal}}
when: animal
vars:
- animal: trout

name: >
  check if {{animal}} is neither a dog not a cat
  (answer is {{'dog' != animal and 'cat' != animal}}')
eat: food={{animal}}
vars: animal=trout
when:
 - animal
 - "'dog' != animal"   # double-quotes are a workaround to avoid
 - "'cat' != animal"   # confusing the yaml parser - the jinja2 parser
   # never sees them.

Bug#932939: Confirmed bug 932939

[Ashish SHUKLA]

On 10/1/19 5:23 AM, Jeff wrote:
> Confirmed the same.
> 
> Sep 30 23:40:50 debconf: Setting debconf/language to en
> Sep 30 23:40:50 kernel: [  140.827798] main-menu[16157]: segfault at 1
> ip 7f2eeec81554 sp 7ffdd0809cc8 error 4 in
> libc.so.6[7f2eeec11000+148000]
> Sep 30 23:40:50 kernel: [  140.827811] Code: 1f 80 00 00 00 00 66 0f
> 6e ce 89 f9 66 0f 60 c9 48 85 d2 0f 84 0d 03 00 00 66 0f 60 c9 83 e1
> 3f 66 0f 70 c9 00 83 f9 30 77 3c  0f 6f 07 66 0f 74 c1 66 0f d7 c0
> 85 c0 0f 85 a8 02 00 00 48 83
> 
> Changed pxe console boot kernel options from:
>console=tty0 console=ttyS0,115200n8
> to:
>console=ttyS0,115200n8
> 

Thank you for confirming.

-- 
Ashish SHUKLA



signature.asc
Description: OpenPGP digital signature

Bug#933439: amule: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

On Fri, Sep 06, 2019 at 11:41:51PM -0400, Sandro Tosi wrote:
> > Switching to the GTK 3 version may be as simple as:
> > 1) Update your Build-Depends
> >    libwxgtk3.0-dev -> libwxgtk3.0-gtk3-dev
> >    libwxgtk-media3.0-dev -> libwxgtk-media3.0-gtk3-dev
> > 2) Rebuild
> > 3) Test
> 
> i tried this but it failed with this segfault:
> 
[...]
> 
> Thread 1 "amule" received signal SIGSEGV, Segmentation fault.
> 0x771d8c1a in wxWindow::DoClientToScreen(int*, int*) const () from 
> /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0

That sounds suspiciously similar to this bug, reported as happening when
using the GTK2 flavour of wxWidgets:

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

It appears that somehow a window can end up being its own parent (or a
parent of one of its own ancestors), which isn't valid and results in wx
running out of stack when it tries to recurse up the window hierarchy.

> No idea what it really when wrong, but if you could lend a head it would be
> great!

Sadly upstream don't seem to be making progress on this.

I've recall from past wx transitions that amule is difficult to debug
without connecting to file sharing networks, which I really don't want
to be doing.  Is there a way to reproduce this without any remote
connections?

It rather looks to me like this probably isn't specific to GTK3 though.

Cheers,
Olly

Bug#939539: Docker is running!

[Felicia]

I found two things to solve this issue:

1) edit /etc/default/grub and edit the line GRUB_CMDLINE_LINUX to contain:

    GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

2) Run the following script:

    https://github.com/moby/moby/issues/8791#issuecomment-60874893

Bug#932939: Confirmed bug 932939

[Jeff]

Confirmed the same.

Sep 30 23:40:50 debconf: Setting debconf/language to en
Sep 30 23:40:50 kernel: [  140.827798] main-menu[16157]: segfault at 1
ip 7f2eeec81554 sp 7ffdd0809cc8 error 4 in
libc.so.6[7f2eeec11000+148000]
Sep 30 23:40:50 kernel: [  140.827811] Code: 1f 80 00 00 00 00 66 0f
6e ce 89 f9 66 0f 60 c9 48 85 d2 0f 84 0d 03 00 00 66 0f 60 c9 83 e1
3f 66 0f 70 c9 00 83 f9 30 77 3c  0f 6f 07 66 0f 74 c1 66 0f d7 c0
85 c0 0f 85 a8 02 00 00 48 83

Changed pxe console boot kernel options from:
   console=tty0 console=ttyS0,115200n8
to:
   console=ttyS0,115200n8

Bug#940876: ITP: storm -- object-relational mapper (ORM) for Python

[Colin Watson]

On Sat, Sep 21, 2019 at 11:20:28AM +0100, Colin Watson wrote:
> This package was previously in Debian, but was removed due to being
> orphaned and having no Python 3 port, as well as needing several new
> dependencies that were unpackaged.  I recently completed a Python 3 port
> upstream and have also packaged all the new dependencies, and so I'd
> like to reintroduce this package and maintain it under the Debian Python
> Modules Team again.

I found a few bugs in the process of packaging this, for which I've now
proposed fixes upstream:

  https://code.launchpad.net/~cjwatson/storm/py36/+merge/373380
  https://code.launchpad.net/~cjwatson/storm/fix-py3-cextensions/+merge/373435

... and also an infelicity in the way the test suite worked that made it
difficult to run the tests during the Debian package build:

  https://code.launchpad.net/~cjwatson/storm/postgresfixture/+merge/373379

So, definite progress, but I'll need to get those reviewed and landed
and make another release before I'll be happy with the packaging.  (I
don't want to skip running the tests, not least because they uncovered
some genuine problems here and there might be more.)

-- 
Colin Watson   [cjwat...@debian.org]

Bug#910901: [Pkg-kde-extras] Bug#910901: marked as done (plasma-applet-redshift-control: Mouse wheel only reduces color temperature, in either direction)

[Nicholas D Steeves]

"Debian Bug Tracking System"  writes:

> Package: plasma-applet-redshift-control
> Version: 1.0.18-2
> Severity: normal
> Tags: patch
>
> Since redshift 1.12, the interface for one-shot changes was modified, causing
> all mouse wheel operations to only lower the color temperature and gamma.  The
> fix is simply to add the new "-P" command line option.
>

Nicholas, thank you for reporting this bug!  It's been driving me nuts too.

[snip]
> Format: 1.8
> Date: Sat, 28 Sep 2019 15:06:04 +0200
> Source: plasma-applet-redshift-control
> Architecture: source
> Version: 1.0.18+phabricator~2019080100-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian KDE Extras Team 
> Changed-By: Didier Raboud 
> Closes: 910901
> Changes:
>  plasma-applet-redshift-control (1.0.18+phabricator~2019080100-1) unstable; 
> urgency=medium
>  .
>* Upstream snapshot from new upstream repository
>* Import upstream-submitted patch to fix manual mode for redshift
>  >= 1.12 (Closes: #910901)
>* Bump debhelper from old 9 to 12.
>* Drop unnecessary dh arguments: --parallel
>* Update Vcs-{Git,Browser} to Salsa
>* Bump Standards-Version to 4.4 without changes needed

Didier, Thank you for importing the fix!  Are you also going to pursue a
stable-update or backport so buster users can benefit?


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#445636:

[MAH Alli]

Bug#941246: RFP: elpa-ansible -- ansible syntax highlighting, completion, and yasnippet templates for Emacs

[Nicholas D Steeves]

Hi Trent,

Thank you for investigating and filing this RFS.  Reply follows inline.

"Trent W. Buck"  writes:

> * License : not licensed?

I've filed an upstream issue about including the full license text.

>   Description : ansible syntax highlighting, completion, and yasnippet 
> templates for Emacs
>
> Ansible (already in Debian) is a configuration management tool.
> Ansible file format is a combination of YAML (structured data) and jinja2 
> (templates).
>
> elpa-yaml (already in Debian) is mostly sufficient;
> adding ansible.el gives some domain-specific syntax highlighting.
>
> e.g. yaml-mode colors these lines the same; ansible.el colors the
> first line specially (because it has special meaning to Ansible).
>
> name: foo
> bar: baz
>
> ansible.el also has some stuff to auto-complete ansible keywords
> (e.g. "na" --> "name"), and some basic yasnippet-based templates.
> I (Trent Buck) personally do not care about those features.

Thank you for taking the time investigate and to write a nice description!

Continuing from Bug #941058

> Its documentation doesn't list the features / benefits over plain
> yaml-mode.

Good point, that doc issue ought to be fixed upstream.  Also, I suspect
that the conversion to a derived major mode should be done before this
software is suitable for a Debian stable release.  Finally, it would be
nice if the snippets were merged into Andrea Crotti's official upstream
snippets collection once ansible mode has been modified to be a derived
major mode.  I'm not sure if the .yas-parent functionality will work
properly without this change, and it would be nice to provide the
yaml-mode snippets + ansible snippets (via .yas-parent) simultaneously,
for users who enjoy this type of functionality.

> From reading the source, it looks like it provides
>  * keyword highlighting (useful),
>  * autocompletion of keywords (not useful), and
>  * yasnippets templates (not useful).
>

Were you able to tell if the autocompletion and yasnippets are so
limited as to be not useful to people who use this functionality?  The
snippets appear to be surprisingly comprehensive to me.

> It depends on packages named simply "s" and "f" (oy!), but
> those appear to be in Debian already (elpa-s and elpa-f).
> I installed those then did
>
> emacs -nw -q \
> -l emacs-ansible/ansible.el \
> -eval "(require 'yaml-mode)" \
> cyber-ansible/Cyber-BCP.yaml \
> -eval '(ansible +1)'

Excellent work, are you interested in joining the Debian Emacsen team?
It's clear you have the skills. :-)  I'd be happy to answer questions
and provide guidance if necessary.

> ...and yeah OK, there's more color.  It treats "name: " specially,
> and it tries to recognize the embedded jinja2 {{}} {%%} crap without
> actually resorting to using an actual jinja major mode (via mumamo or
> mmm).

This is the most interesting feature imho, eg: a lightweight jinja2
parser, and should go in the long description.  Whoever fulfills this
RFP should verify that this functionality can catch jinja2 syntax errors.

> I guess elpa-ansible would be useful to me, but
> not enough to put you to any significant trouble.
> I'll file an RFP and let you decide whether to action it. :-)

I'll add it to my low-priority "to package eventually if someone else
doesn't step forward" queue.


Take care,
Nicholas


signature.asc
Description: PGP signature

Bug#941385: UT99: sound missing due to missing dependency osspd

[Bruno Kleinert]

Am Sonntag, den 29.09.2019, 23:28 +0200 schrieb esp:
> without the windowed mouse bug as present in Unreal Gold. The game however 
> does
> not have sound after initial installation due to missing deb package osspd 
> (OSS
> Proxy Daemon: Userland OSS emulation). As soon as this package gets installed
> the sound works 100% fine. Suggestion to include a osspd package dependency to
> inform user to apt install osspd. Thanks

Hi,

alternative, lightweighter solutions for the OSS legacy support exist
and may work, too. Let's check that!

Do you use PulseAudio (Run "pulseaudio --check || echo 'Yep'" in a
terminal if you don't know.)? In case you do, please launch the game
from a terminal with "padsp " and let us know if that works as
you would expect it!

If you are not using PulseAudio, please install alsa-oss and launch the
game from a terminal with "aoss " and let us know if that
works as you would expect it!

If the the LD_PRELOAD wrappers work, I'd prefer to add alternative
dependencies pulseaudio-utils || alsa-oss || osspd to go from
lightweight to heavy weight dependencies. Since osspd is a daemon, it's
started during system startup and adds something to systems' boot
times.

Cheers - Bruno


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

Bug#941284: Wishlist/RFC: Use CONFIG_HZ=100 in linux-image-cloud-*

[Flavio Veloso]

Thank you for your comments.

To be very honest, I never did much research about this subject -- and 
for the reasons I explained before I always use 100Hz when recompiling 
for server usage. I can't comment about big SMPs but I always thought 
that the interrupts are routed independently, but I might have 
misunderstood that. Server usage is more sensitive to load than 
responsiveness IMHO, so to me the less context switches the better (and 
that's what we get with 100Hz, which used to be the default before 250Hz 
-- and 1KHz -- was introduced as a compromise between server and low 
latency for desktop-oriented tasks). I do not think that network latency 
plays a big hole here as net jitter alone can be much larger than the 
numbers we're talking here (specially in cloud/VPS environment). Lastly, 
I think that "because Amazon does" is not a good reason for not 
implementing it -- it might just be that they don't care about their 
users as we do.


Anyway, non-authoritative answers here too, so hopefully someone more 
knowledgeable than I am might jump in and enlighten us! :-)


On 2019-09-27 9:15 p.m., Nicholas D Steeves wrote:

Noah Meyerhans  writes:


On Fri, Sep 27, 2019 at 01:15:29PM -0700, Flavio Veloso wrote:

Since linux-image-cloud-* packages are created for cloud environments --
read: servers which do not need desktop-level responsiveness --, wouldn't it
be beneficial to build the kernels with CONFIG_HZ set to 100?

I wonder if the upstream docstring could be improved, because to my mind
100hz only makes sense for throughput-limited workloads, or for big SMP
systems. eg: when you have one 100hz timer running on each of 32 cores
the effect on latency is more like a ~3200hz timer than a 100hz one.

Also, network latency is a big deal now, so I'm not sure if this
docstring is accurate anymore.


For what it's worth, the Amazon Linux 2 4.14.x kernel also ships with
CONFIG_HZ=250. We obviously don't need to use the same settings, but
that kernel specifically targets cloud deployments, and its maintainers
do not see a need to set CONFIG_HZ=100.

I don't know what considerations were taken into account when choosing
the value for that variable at AWS.


Maybe something like socket activation, subprocess or thread creation
latency?  Or maybe because it's useful to have a 250hz timer when your
vhost only has one vcpu?

'just some non-authoritative thoughts.  I'm sure Ben can say for sure
:-)

Take care!
Nicholas


--
FV

Bug#935918: cups: can't read hpcups PPDs

[Brian Potkin]

On Mon 30 Sep 2019 at 23:40:00 +0200, Raphaël Halimi wrote:

> Le 30/09/2019 à 20:27, Didier 'OdyX' Raboud a écrit :
> > FTR, this was circumvented in Debian's hplip package version 3.19.8+dfsg0-6.
> 
> That's what hplip's changelog says, but unfortunately, after upgrading,
> I tried to re-add my printer (HP Envy 5030) and again, the PPD was
> rejected with an error, but it worked once I modified it manually. Maybe
> not all PPDs were correctly fixed ?

The changelog mentions only printer-driver-postscript-hp PPDs. Is that
the issue?

root@debian:~# dpkg -l printer-driver-hpcups
ii  printer-driver-hpcups 3.19.8+dfsg0-6 i386 HP Linux Printing and 
Imaging - CUPS Raster dr>
root@debian:~#
root@debian:~# lpadmin -p 5000 -v file:/dev/null -E -m 
drv:///hpcups.drv/hp-envy_5000_series.ppd
lpadmin: Printer drivers are deprecated and will stop working in a future 
version of CUPS.
lpadmin: Unable to open PPD "/tmp/052c15d9f9626": Illegal option keyword string 
on line 198.

Cheers,

Brian.

Bug#941458: wodim aborts before attempting to burn DVD-R

[David Griffith]

Package: wodim
Version: 9:1.1.11-3+b2
Severity: grave
Justification: renders package unusable

Attempting to burn a DVD-R using the same drive, media, and computer.
This attempt aborts prior to even starting the burn:

wodim: No write mode specified.
wodim: Assuming -tao mode.
wodim: Future versions of wodim may have different drive dependent defaults.
Device was not specified. Trying to find an appropriate drive...
Looking for a DVD-R drive to store 4442.98 MiB...
Using /dev/cdrom of unknown capabilities
scsidev: '/dev/cdrom'
devname: '/dev/cdrom'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.11
SCSI buffer size: 64512
wodim: Cannot load media with this drive!
wodim: Try to load media by hand.
Beginning DMA speed test. Set CDR_NODMATEST environment variable if device
communication breaks or freezes immediately after that.
TOC Type: 1 = CD-ROM
Driveropts: 'burnfree'
Device type: Removable CD-ROM
Version: 5
Response Format: 2
Capabilities   : 
Vendor_info: 'MATSHITA'
Identification : 'DVD/CDRW UJDA782'
Revision   : 'VB03'
Device seems to be: Generic mmc2 DVD-ROM.
Current: 0x (Reserved/Unknown)
Profile: 0x0010 (DVD-ROM) 
Profile: 0x000A (CD-RW) 
Profile: 0x0009 (CD-R) 
Profile: 0x0008 (CD-ROM) 
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE 
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R96R
FIFO size  : 12582912 = 12288 KB
wodim: Cannot load media with this drive!
wodim: Try to load media by hand.
wodim: Cannot load media.
Track 01: data  4442 MB
Total size: 5102 MB (505:30.74) = 2274806 sectors
Lout start: 5102 MB (505:32/56) = 2274806 sectors

At this point, wodim simply aborts without explanation.

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

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

Versions of packages wodim depends on:
ii  libc62.28-10
ii  libcap2  1:2.25-2

Versions of packages wodim recommends:
ii  genisoimage  9:1.1.11-3+b2

Versions of packages wodim suggests:
pn  cdrkit-doc  

-- no debconf information

Bug#941336: nvidia-legacy-340xx-kernel-dkms: Kernel module nvidia-legacy-340xx can't be loaded

[Paul Vojta]

I noticed that since I didn't run reportbug as root, it didn't give the dmesg
output.  It is attached (and was from the same boot session as the running
of reportbug).

Note the oops.

Paul Vojta
[0.00] Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 
(2019-09-20)
[0.00] Command line: \boot\vmlinuz-4.19.0-6-amd64 ro 
root=UUID=1bfba26d-93c9-43f0-9c7d-53297048d67a 
initrd=boot\initrd.img-4.19.0-6-amd64
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008efff] usable
[0.00] BIOS-e820: [mem 0x0008f000-0x0008] ACPI NVS
[0.00] BIOS-e820: [mem 0x0009-0x0009] usable
[0.00] BIOS-e820: [mem 0x0010-0x6eff] usable
[0.00] BIOS-e820: [mem 0x6f00-0x7eff] reserved
[0.00] BIOS-e820: [mem 0x7f00-0x7f718fff] usable
[0.00] BIOS-e820: [mem 0x7f719000-0x7f938fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7f939000-0x7f955fff] usable
[0.00] BIOS-e820: [mem 0x7f956000-0x7f96afff] ACPI data
[0.00] BIOS-e820: [mem 0x7f96b000-0x7f976fff] usable
[0.00] BIOS-e820: [mem 0x7f977000-0x7f99afff] reserved
[0.00] BIOS-e820: [mem 0x7f99b000-0x7f9b5fff] usable
[0.00] BIOS-e820: [mem 0x7f9b6000-0x7f9dafff] reserved
[0.00] BIOS-e820: [mem 0x7f9db000-0x7fef8fff] usable
[0.00] BIOS-e820: [mem 0x7fef9000-0x7fef] reserved
[0.00] BIOS-e820: [mem 0x9350-0x93500fff] reserved
[0.00] BIOS-e820: [mem 0xffc0-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0x6bd96018-0x6bda4c57] usable ==> usable
[0.00] e820: update [mem 0x6bd96018-0x6bda4c57] usable ==> usable
[0.00] e820: update [mem 0x6c5c6018-0x6c5c6909] usable ==> usable
[0.00] e820: update [mem 0x6c5c6018-0x6c5c6909] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0008efff] 
usable
[0.00] reserve setup_data: [mem 0x0008f000-0x0008] 
ACPI NVS
[0.00] reserve setup_data: [mem 0x0009-0x0009] 
usable
[0.00] reserve setup_data: [mem 0x0010-0x6bd96017] 
usable
[0.00] reserve setup_data: [mem 0x6bd96018-0x6bda4c57] 
usable
[0.00] reserve setup_data: [mem 0x6bda4c58-0x6c5c6017] 
usable
[0.00] reserve setup_data: [mem 0x6c5c6018-0x6c5c6909] 
usable
[0.00] reserve setup_data: [mem 0x6c5c690a-0x6eff] 
usable
[0.00] reserve setup_data: [mem 0x6f00-0x7eff] 
reserved
[0.00] reserve setup_data: [mem 0x7f00-0x7f718fff] 
usable
[0.00] reserve setup_data: [mem 0x7f719000-0x7f938fff] 
ACPI NVS
[0.00] reserve setup_data: [mem 0x7f939000-0x7f955fff] 
usable
[0.00] reserve setup_data: [mem 0x7f956000-0x7f96afff] 
ACPI data
[0.00] reserve setup_data: [mem 0x7f96b000-0x7f976fff] 
usable
[0.00] reserve setup_data: [mem 0x7f977000-0x7f99afff] 
reserved
[0.00] reserve setup_data: [mem 0x7f99b000-0x7f9b5fff] 
usable
[0.00] reserve setup_data: [mem 0x7f9b6000-0x7f9dafff] 
reserved
[0.00] reserve setup_data: [mem 0x7f9db000-0x7fef8fff] 
usable
[0.00] reserve setup_data: [mem 0x7fef9000-0x7fef] 
reserved
[0.00] reserve setup_data: [mem 0x9350-0x93500fff] 
reserved
[0.00] reserve setup_data: [mem 0xffc0-0x] 
reserved
[0.00] efi: EFI v1.10 by Apple
[0.00] efi:  ACPI=0x7f96a000  ACPI 2.0=0x7f96a014  SMBIOS=0x7f71a000 
[0.00] secureboot: Secure boot disabled
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Apple Inc. Macmini4,1/Mac-F2208EC8, BIOS 
MM41.88Z.0042.B00.1004221740 04/22/10
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 2389.066 MHz processor
[0.29] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.32] e820: remove [mem 0x000a-0x000f] usable
[0.42] last_pfn = 0x7fef9 max_arch_pfn = 0x4
[0.

Bug#924848: telegram-cli: FTBFS: build-dependency not installable: libwolfssl-dev

[Ying-Chun Liu (PaulLiu)]

severity 924848 minor
thanks

Hi all,

Wolfssl is now in Bullseye again because we tried to align with the
latest upstream version which fixes most of the security issues.
Thanks for the contribution from Felix Lechner 
And this makes telegram-cli not FTBFS anymore in Bullseye.

So I set the severity to minor. Not closing the bug because we still
need this bug to track telegram-cli's upstream for a license change. It
is surely a bug because if it compiles with OpenSSL then it violates the
GPL. Note that we don't have the issue here because we compile it with
WolfSSL.

Yours,
Paul




signature.asc
Description: OpenPGP digital signature

Bug#941457: postfix: Please include collate.pl contrib script

[Micah Anderson]

Package: postfix
Version: 3.4.5-1
Severity: wishlist

Hello,

Upstream has collate.pl under auxiliary/collate/collate.pl in the upstream 
source. 
This is a very useful utility script, and would be lovely if the debian package
would include it so it would be installed on the system when the package is 
installed.

This script, by Viktor Dukhovni, untangles a Postfix logfile and
groups the records one "session" at a time based on queue ID and
process ID information.

Thanks!
Micah

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

Kernel: Linux 4.19.67-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.12+dfsg-9
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  e2fsprogs  1.44.5-1+deb10u1
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libicu63   63.1-6
ii  libsasl2-2 2.1.27+dfsg-1
ii  libssl1.1  1.1.1c-1
ii  lsb-base   10.2019051400
ii  netbase5.6
ii  ssl-cert   1.0.39

Versions of packages postfix recommends:
ii  python3  3.7.3-1

Versions of packages postfix suggests:
ii  emacs-gtk [mail-reader]1:26.1+1-3.2
ii  libsasl2-modules   2.1.27+dfsg-1
ii  mailutils [mail-reader]1:3.5-3
pn  postfix-cdb
pn  postfix-doc
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mysql  
pn  postfix-pcre   
pn  postfix-pgsql  
ii  postfix-sqlite 3.4.5-1
ii  procmail   3.22-26
pn  resolvconf 
ii  thunderbird [mail-reader]  1:60.8.0-1~deb10u1
pn  ufw

-- debconf information excluded

Bug#932252: (no subject)

[Thomas Lange]

There's no formal definition what a team in Debian is. That's why it's
hard to decide which information should go onto this page.
But we should not list every mailing list as a team.

For me the user support mailing lists should not be listed here.
Also "Special Configurations" (including Laptops, Firewalls and
Embedded systems) is not important to list on a page about Debian
organisation structure. Maybe the same applies for ports, which are
already listed on the /ports web page.

Examples of teams that are not official delegates but should be listed
are the listmasters, salsa-admin, antiharassment, web pages, security
and others teams.

We will never be able to find a perfect solution, but let's try to
clean up the page a bit and list only the major parts (teams) that are
visible or well known.
-- 
regards Thomas

Bug#941360: fwupd: Failed to activate service: timed out

[Mario.Limonciello]

Here is a fix for it. I believe it's because of a clash with fwupd-refresh and 
fwupd specifically in systemd 242 and newer.

https://github.com/fwupd/fwupd/commit/dc7e7c3808d564d5769b2845dbd66a3651f72e07

On Sep 30, 2019 10:37, Francois Marier  wrote:

[EXTERNAL EMAIL]

On 2019-09-29 at 23:57:02, mario.limoncie...@dell.com wrote:
> What version did you upgrade from? And was that directory already existing or 
> did it get created with the package?

I'm also affected by this problem. In my case, I also purged the package and
reinstalled it. The problem persists and the cache symlink looks like this:

$ ls -l /var/cache/fwupd
lrwxr-xr-x 1 root root 13 sep 28 20:48 /var/cache/fwupd -> private/fwupd

Francois

--
https://fmarier.org/

Bug#940918: RFS: libutempter/1.1.6-4 [ITA] -- privileged helper for utmp/wtmp updates (development)

[Christian Göttsche]

Control: retitle -1 RFS: libutempter/1.1.6-4 [ITA] -- privileged
helper for utmp/wtmp updates (development)

New upload with ITA instead of NMU.

 * Package name: libutempter
   Version : 1.1.6-4
   Upstream Author : Dmitry V. Levin 
 * URL :
http://git.altlinux.org/people/ldv/packages/?p=libutempter.git
 * License : LGPL-2.1
 * Vcs : https://salsa.debian.org/cgzones-guest/libutempter
   Section : libs

It builds those binary packages:

  libutempter-dev - privileged helper for utmp/wtmp updates (development)
  libutempter0 - privileged helper for utmp/wtmp updates (runtime)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libu/libutempter/libutempter_1.1.6-4.dsc

Changes since the last upload:

   * Set myself as new maintainer (Closes: #879388)
   * Update vcs fields accordingly
   * Bump to compat level 12
   * Bump to std version 4.4.1
   * Enable all hardening options in d/rules
   * Add autopkg testsuite
   * Convert d/copyright to machine-readable format
   * Add standard salsa-ci configuration, exclude reprotest for chown failures
   * Remove unneeded ignore file for list-missing
   * Explicit set Build-Depends-Package in d/libutempter0.symbols
   * Explicit set Rules-Requires-Root to binary-targets
   * Add C compiler -Wextra flag in d/rules
   * Patches:
 - Convert to gbp style
 - add: Mark old interfaces as deprecated
 - add: Validate given hostname (Closes: #689562)

Package state:

   https://salsa.debian.org/cgzones-guest/libutempter/-/tags/debian%2F1.1.6-4

Regards,

--
  Christian Göttsche

Bug#940902: doesn't read the data

[Ana Guerrero Lopez]

Hi,

On Mon, Sep 23, 2019 at 10:18:51AM +0200, Andreas Tille wrote:
> 
...
> On Sun, Sep 22, 2019 at 11:11:47PM +0200, Ana Guerrero Lopez wrote:
...

> > Your current python3 porting is not helping here since many people will 
> > start
> > the application, will be prompted for a new user, will create it and erase
> > all their data. So please, revert your changes and if that means the package
> > will be removed from the archive, let it be. At least people will be able to
> > continue using it while they move to something else (or not), but won't lose
> > their data as it'll happen now.
> 
> I've now pushed a change to salsa[1] where I deactivated the whole 2to3
> port and replaced the warning about the port by some other warning that
> a port will be needed or the package will vanish.  Hopefully this might
> attract some coders.  BTW, I fully agree with you that the code quality
> might not be a good start.
> 
> I tried to start the build here but I get:
> 
> $ cycle 
> Traceback (most recent call last):
>   File "/usr/bin/cycle", line 213, in 
> app = MyApp(0)
>   File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk3/wx/_core.py", line 8628, 
> in __init__
> self._BootstrapApp()
>   File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk3/wx/_core.py", line 8196, 
> in _BootstrapApp
> return _core_.PyApp__BootstrapApp(*args, **kwargs)
>   File "/usr/bin/cycle", line 193, in OnInit
> ret=first_login()
>   File "/usr/share/cycle/dialogs.py", line 304, in first_login
> users = get_users()
>   File "/usr/share/cycle/dialogs.py", line 192, in get_users
> users.append((cPickle.loads(tmp[:n]), f))
> ValueError: unsupported pickle protocol: 3
> 
> 
> So I reverted to the Python2 version 0.3.1-14 (from testing) but I get
> absolutely the same error.  I wonder whether my package is fine in terms
> of "works as broken as before" or whether I messed up something else.
> 
> > Thanks for caring.
> 
> Thanks to you.  I'd be happy if you could check master[1] and confirm
> that it is OK.  I can even give you commit permissions so you can change
> anything you feel sensible and do the team upload yourself.

Please, add me to the group, I'll take care of the testing and upload.

Cheers,

Ana

Bug#935918: cups: can't read hpcups PPDs

[Raphaël Halimi]

Le 30/09/2019 à 20:27, Didier 'OdyX' Raboud a écrit :
> FTR, this was circumvented in Debian's hplip package version 3.19.8+dfsg0-6.

That's what hplip's changelog says, but unfortunately, after upgrading,
I tried to re-add my printer (HP Envy 5030) and again, the PPD was
rejected with an error, but it worked once I modified it manually. Maybe
not all PPDs were correctly fixed ?

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#941456: "inode/directory:1" is an invalid MIME type

[Michael Biebl]

Package: sirikali
Version: 1.3.9-1
Severity: normal
File: /usr/share/applications/io.github.mhogomchungu.sirikali.desktop

When running update-desktop-database, I get the following error message:
Error in file 
"/usr/share/applications/io.github.mhogomchungu.sirikali.desktop": 
"inode/directory:1" is an invalid MIME type ("inode/directory:1" contains an 
invalid character in the subtype)

Looking at the desktop file, it contains:

MimeType=inode/directory:1;



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

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

Versions of packages sirikali depends on:
ii  libc6   2.29-2
ii  libgcc1 1:9.2.1-8
ii  libgcrypt20 1.8.5-2
ii  libqt5core5a5.11.3+dfsg1-4
ii  libqt5gui5  5.11.3+dfsg1-4
ii  libqt5network5  5.11.3+dfsg1-4
ii  libqt5widgets5  5.11.3+dfsg1-4
ii  libsecret-1-0   0.19.1-1
ii  libstdc++6  9.2.1-8

Versions of packages sirikali recommends:
pn  cryfs  

Versions of packages sirikali suggests:
pn  ecryptfs-utils  
ii  encfs   1.9.5-1+b1
ii  gocryptfs   1.7-2
ii  sshfs   2.10+repack-2+b1

-- no debconf information

Bug#939967: flightcrew 0.7.2+dfsg-9+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 939967 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: flightcrew
Version: 0.7.2+dfsg-9+deb9u1

Explanation: security fixes [CVE-2019-13032 CVE-2019-13241]

Bug#939015: akonadi 18.08.3-7~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 939015 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: akonadi
Version: 18.08.3-7~deb10u1

Explanation: fix various crashes / deadlock issues

Bug#879388: O: libutempter -- privileged helper for utmp/wtmp updates (development)

[Christian Göttsche]

Control: owner -1 !
Control: retitle -1 ITA: libutempter -- privileged helper for
utmp/wtmp updates (development)

I intend to adopt libutempter.

Bug#935252: gnome-shell 3.30.2-11~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935252 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gnome-shell
Version: 3.30.2-11~deb10u1

Explanation: new upstream stable release; fix truncation of long messages in 
Shell-modal dialogs; avoid crash on reallocation of dead actors

Bug#940818: flatpak 1.2.5-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 940818 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: flatpak
Version: 1.2.5-0+deb10u1

Explanation: new upstream stable release

Bug#935250: mutter 3.30.2-9~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935250 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: mutter
Version: 3.30.2-9~deb10u1

Explanation: new upstream stable release

Bug#939965: flightcrew 0.7.2+dfsg-13+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 939965 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: flightcrew
Version: 0.7.2+dfsg-13+deb10u1

Explanation: security fixes [CVE-2019-13032 CVE-2019-13241]

Bug#939831: vanguards 0.3.1-2~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 939831 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: vanguards
Version: 0.3.1-2~deb10u1

Explanation: new upstream stable release; prevent a reload of tor's 
configuration via SIGHUP causing a denial-of-service for vanguards protections

Bug#941455: mumble: Slow upstart since 1.3.0+dfsg-1 because of jackd

[Matthias Heinz]

Package: mumble
Version: 1.3.0+dfsg-1
Severity: normal

Hi,

since the last update mumble starts very slow.

On the console it shows:

Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
exec of JACK server (command = "/usr/bin/jackd") failed: No such file or
directory
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
2019-09-30 22:29:28.762 JackAudioSystem: unable to open client due to 2
errors:
2019-09-30 22:29:28.763 JackAudioSystem: JackFailure - overall operation
failed
2019-09-30 22:29:28.763 JackAudioSystem: JackServerFailed - unable to
connect to the JACK server

I'm using pulseaudio. jackd is not installed.

Best regards
Matthias



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

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

Versions of packages mumble depends on:
ii  libasound21.1.8-1
ii  libavahi-compat-libdnssd1 0.7-4+b1
ii  libc6 2.29-2
ii  libgcc1   1:9.2.1-8
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libprotobuf17 3.6.1.3-2
ii  libpulse0 13.0-1
ii  libqt5core5a  5.11.3+dfsg1-4
ii  libqt5dbus5   5.11.3+dfsg1-4
ii  libqt5gui55.11.3+dfsg1-4
ii  libqt5network55.11.3+dfsg1-4
ii  libqt5sql55.11.3+dfsg1-4
ii  libqt5sql5-sqlite 5.11.3+dfsg1-4
ii  libqt5svg55.11.3-3
ii  libqt5widgets55.11.3+dfsg1-4
ii  libqt5xml55.11.3+dfsg1-4
ii  libsndfile1   1.0.28-6
ii  libspeechd2   0.9.1-2
ii  libspeex1 1.2~rc1.2-1.1
ii  libspeexdsp1  1.2~rc1.2-1.1
ii  libssl1.1 1.1.1d-1
ii  libstdc++69.2.1-8
ii  libx11-6  2:1.6.8-1
ii  libxi62:1.7.9-1
ii  lsb-release   11.1.0

mumble recommends no packages.

Versions of packages mumble suggests:
pn  mumble-server  
ii  speech-dispatcher  0.9.1-2

-- no debconf information

Bug#875190: [Python-modules-team] Bug#875190: [shiboken] Future Qt4 removal from Buster

[Scott Kitterman]

On Monday, September 30, 2019 4:04:05 PM EDT Moritz Mühlenhoff wrote:
> On Sat, Sep 09, 2017 at 11:09:45PM +0200, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > Source: shiboken
> > Version: 1.2.2-5
> > Severity: wishlist
> > User: debian-qt-...@lists.debian.org
> > Usertags: qt4-removal
> > 
> > 
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as [announced] in:
> > 
> > [announced]
> > 
> > 
> > Currently Qt4 has been dead upstream and we are starting to have problems
> > maintaining it, like for example in the [OpenSSL 1.1 support] case.
> > 
> > [OpenSSL 1.1 support]
> > 
> > 
> > In order to make this move, all packages directly or indirectly depending
> > on the Qt4 libraries have to either get ported to Qt5 or eventually get
> > removed from the Debian repositories.
> > 
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether there
> > are suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
> 
> There are no reverse dependencies of src:shiboken in unstable and it has
> been replaced by src:pyside2, let's remove from the archive?

I think that's an excellent idea.

Scott K

Bug#941454: claws-mail: Randomly loose ability to drag'n'drop a message

[Jiff]

Package: claws-mail
Version: 3.17.3-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Wanting to drag an e-mail from the INBOX list and drop it into another folder.

When droping, it didn't work.

NB :This is a behavior I already had with stretch ; at first, I thought it was
only tied to the fact I usually suspend to ram my laptop for the night and only
reboot once per week or even 2 weeks, but this time it happened only 2 hours
after a reboot with no suspend at all and very few moments of use (not even
sent an e-mail.) The laptop (an MSI CX61 2PC) have 8 GB RAM, memtest+ doesn't
report any problem.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

First, I copiously cursed the Russians, D.Trump, Atilla the Hun and B.Gates,
not necessarily in this order, then I closed claws and reopened it.

   * What was the outcome of this action?

The drop function worked as expected.

   * What outcome did you expect instead?

Claws working any time as expected, although working by telepathy would be good
thing but it may be a little early for that :)



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

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

Versions of packages claws-mail depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcompfaceg11:1.5.2-5+b2
ii  libcurl3-gnutls  7.64.0-4
ii  libdb5.3 5.3.28+dfsg1-0.5
ii  libenchant1c2a   1.6.0-11.1+b1
ii  libetpan20   1.9.3-2
ii  libexpat12.2.6-2+deb10u1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u1
ii  libgnutls30  3.6.7-4
ii  libgtk2.0-0  2.24.32-3
ii  libice6  2:1.0.9-2
ii  libldap-2.4-22.4.47+dfsg-3+deb10u1
ii  liblockfile1 1.14-1.1
ii  libnettle6   3.4.1-1
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  librsvg2-2   2.44.10-2.1
ii  libsasl2-2   2.1.27+dfsg-1
ii  libsm6   2:1.2.3-1
ii  xdg-utils1.1.3-1

Versions of packages claws-mail recommends:
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  aspell-fr [aspell-dictionary]  0.50-3-8
ii  claws-mail-i18n3.17.3-2
ii  xfonts-100dpi  1:1.0.4+nmu1
ii  xfonts-75dpi   1:1.0.4+nmu1

Versions of packages claws-mail suggests:
ii  claws-mail-doc  3.17.3-2
pn  claws-mail-tools
ii  dillo [www-browser] 3.0.5-5
ii  epiphany-browser [www-browser]  3.32.1.2-3~deb10u1
ii  firefox-esr [www-browser]   60.9.0esr-1~deb10u1
ii  gedit   3.30.2-2
ii  hv3 [www-browser]   3.0~fossil20110109-7
ii  lynx [www-browser]  2.8.9rel.1-3
ii  mousepad0.4.1-2

-- no debconf information

Bug#929597: not fixed by upstream

[Salvatore Bonaccorso]

Hi,

On Mon, Sep 30, 2019 at 09:56:07PM +0200, Anton Gladky wrote:
> Last commit was in April 2019. We should really think
> about existing this package in the Debian.

You mean with "think about existing this package in the Debian" about
a potential removal from Debian? A removal, considering the affected
reverse (build-)depdendencies does not seem realistic at the
moment[1].

Regards,
Salvatore

 [1] dak rm --suite=sid -n -R freeimage on respighi would list a lot
 of broken Build-Depends and broken Depends.

Bug#935348: python-nfs-ganesha: Qt4 removal from Bullseye

[Moritz Mühlenhoff]

On Wed, Aug 21, 2019 at 11:03:35PM +0300, Dmitry Shachnev wrote:
> Source: nfs-ganesha
> Version: 2.7.6-1
> Severity: important
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> Hi!
> 
> As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
> cycle, as announced in [1].
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get removed
> from the Debian repositories.
> 
> Your package still uses Qt 4, via the Python bindings (PyQt4).
> 
> Therefore, please take the time and:
> 
> - contact your upstream (if existing) and ask about the state of a Qt 5 /
>   PyQt5 port of your application;
> - if there are no activities regarding porting, investigate whether there are
>   suitable alternatives for your users;
> - if there is a Qt 5 port that is not yet packaged, consider packaging it;
> - if both the Qt 4 and the Qt 5 versions already coexist in the Debian
>   archives, consider removing the Qt 4 version.

This only affects the python-nfs-ganesha binary package, how about temporarily
dropping it until this has been fixed upstream? There are no reverse 
dependencies
in the archive.

Cheers,
Moritz

Bug#858774: modes_rx: ImportError: cannot import name QtWebKit

[Moritz Mühlenhoff]

On Fri, Sep 20, 2019 at 10:07:31PM -0400, A. Maitland Bottoms wrote:
> Moritz Mühlenhoff  writes:
> 
> > Hi Maitland,
> > per upstream issue 98 it doesn't sound as if it's going to be fixed,
> > should be remove it or are you planning to port it yourself?
> 
> I was just talking to the upstream author at the gnuradio conference.
> Our plan going forward is to just remove the GUI elements of the
> package, but keep all the signal processing code and provide gnuradio
> blocks.

Sounds good, thanks.

Cheers,
Moritz

Bug#875190: [shiboken] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:09:45PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: shiboken
> Version: 1.2.2-5
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

There are no reverse dependencies of src:shiboken in unstable and it has
been replaced by src:pyside2, let's remove from the archive?

Cheers,
Moritz

Bug#929597: not fixed by upstream

[Anton Gladky]

Last commit was in April 2019. We should really think
about existing this package in the Debian.

Anton

Am Mo., 30. Sept. 2019 um 21:44 Uhr schrieb Salvatore Bonaccorso
:
>
> On Mon, Sep 30, 2019 at 09:05:03PM +0200, Anton Gladky wrote:
> > No activity from upstream.
>
> Are they still alive upstream? Do you have a cance to ping some
> upstream people directly to make them aware of the issue via anothe
> channel?
>
> Regards,
> Salvatore

Bug#941453: vibe.d: FTBFS with libphobos2-ldc-shared86

[Paul Gevers]

Source: vibe.d
Version: 0.8.4-2
Severity: serious
Tags: ftbfs
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainers,

Your package is part of the ldc transition. It fails to build on all release
where it built in the past.

Paul

Tail of log for vibe.d on amd64:

[99/241] ldc2  -of=core/vibe-test_core 
'core/81ee925@@vibe-test_core@exe/vibe_appmain.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_args.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_concurrency.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_connectionpool.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_core.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_driver.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_libasync.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_libevent2.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_libevent2_tcp.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_native.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_threadedfile.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_timerqueue.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_utils.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_win32.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_file.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_log.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_net.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_path.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_stream.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_sync.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_task.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_internal_allocator.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_internal_freelistref.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_internal_interfaceproxy.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_internal_memory.d.o' -O -g -release -wi 
-L=-z -L=relro -L=utils/libvibe-utils.so.0.8.4 -L=data/libvibe-data.so.0.8.4 
-main -L=-lcrypto -L=-lssl -L=-levent -L=-lz -L=-lstdx-allocator -L=-lmir-core 
-L=-lmir-core -L=-rpath 
-L=/<>/obj-x86_64-linux-gnu/utils/:/<>/obj-x86_64-linux-gnu/data/
FAILED: core/vibe-test_core 
ldc2  -of=core/vibe-test_core 
'core/81ee925@@vibe-test_core@exe/vibe_appmain.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_args.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_concurrency.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_connectionpool.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_core.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_driver.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_libasync.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_libevent2.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_libevent2_tcp.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_native.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_threadedfile.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_timerqueue.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_utils.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_drivers_win32.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_file.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_log.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_net.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_path.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_stream.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_sync.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_core_task.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_internal_allocator.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_internal_freelistref.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_internal_interfaceproxy.d.o' 
'core/81ee925@@vibe-test_core@exe/vibe_internal_memory.d.o' -O -g -release -wi 
-L=-z -L=relro -L=utils/libvibe-utils.so.0.8.4 -L=data/libvibe-data.so.0.8.4 
-main -L=-lcrypto -L=-lssl -L=-levent -L=-lz -L=-lstdx-allocator -L=-lmir-core 
-L=-lmir-core -L=-rpath 
-L=/<>/obj-x86_64-linux-gnu/utils/:/<>/obj-x86_64-linux-gnu/data/
core/81ee925@@vibe-test_core@exe/vibe_core_args.d.o:args.d:_D4vibe4core4args12__ModuleInfoZ:
 error: undefined reference to '_D4vibe8internal9exception12__ModuleInfoZ'
core/81ee925@@vibe-test_core@exe/vibe_core_args.d.o:args.d:_D4vibe4core4args12__ModuleInfoZ:
 error: undefined reference to '_D4vibe8internal9exception12__ModuleInfoZ'
core/81ee925@@vibe-test_core@exe/vibe_core_args.d.o:args.d:_D4vibe4core4args12__ModuleInfoZ:
 error: undefined reference to '_D4vibe8internal9exception12__ModuleInfoZ'
core/81ee925@@vibe-test_core@exe/vibe_core_args.d.o:args.d:_D4vibe4core4args12__ModuleInfoZ:
 error: undefined reference to '_D4vibe8internal9exception12__ModuleInfoZ'
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1
[100/241] ldc2 -I=crypto/b40c6a0@@vibe-crypto@sha -I=crypto/ -I=../crypto 
-I=core/ -I=../core/ -I=utils/ -I=../utils/ -I=/usr/include/d/common -I=data/ 
-I=../data/ -I/usr/include/d/stdx-allocator -I/usr/include/d/mir-core 
-enable-color -d-ve

Bug#929597: not fixed by upstream

[Salvatore Bonaccorso]

On Mon, Sep 30, 2019 at 09:05:03PM +0200, Anton Gladky wrote:
> No activity from upstream.

Are they still alive upstream? Do you have a cance to ping some
upstream people directly to make them aware of the issue via anothe
channel?

Regards,
Salvatore

Bug#941451: buster-pu: package python-cryptography/2.6.1-3+deb10u1

[Sebastian Andrzej Siewior]

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

The upload of OpenSSL 1.1.1d to unstable broke the testsuite of 
python-cryptography in unstable. I picked two patches from upstream and
skipped one test (which upstream has no solution yet) and uploaded to
unstable.
The same version of OpenSSL should pop up soon in Buster via security
and will break the testsuite since the same version is currently in
Buster. I propose the same change for Buster as I did unstable.

Sebastian
diff -Nru python-cryptography-2.6.1/debian/changelog python-cryptography-2.6.1/debian/changelog
--- python-cryptography-2.6.1/debian/changelog	2019-03-09 12:25:47.0 +0100
+++ python-cryptography-2.6.1/debian/changelog	2019-09-30 20:55:00.0 +0200
@@ -1,3 +1,12 @@
+python-cryptography (2.6.1-3+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport two patches to fix the testsute with newer openssl.
+  * Ignore test_load_ecdsa_no_named_curve in the testsuite because it known to
+break with newer openssl (Closes: #940547).
+
+ -- Sebastian Andrzej Siewior   Mon, 30 Sep 2019 20:55:00 +0200
+
 python-cryptography (2.6.1-3) unstable; urgency=medium
 
   * Fix autopkgtest dependencies.
diff -Nru python-cryptography-2.6.1/debian/patches/series python-cryptography-2.6.1/debian/patches/series
--- python-cryptography-2.6.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ python-cryptography-2.6.1/debian/patches/series	2019-09-24 20:38:45.0 +0200
@@ -0,0 +1,3 @@
+update-our-test-to-be-more-robust-wrt-some-changes-f.patch
+use-a-random-key-for-these-tests-4887.patch
+tests-Skip-test_load_ecdsa_no_named_curve.patch
diff -Nru python-cryptography-2.6.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch python-cryptography-2.6.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch
--- python-cryptography-2.6.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch	1970-01-01 01:00:00.0 +0100
+++ python-cryptography-2.6.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch	2019-09-24 20:38:23.0 +0200
@@ -0,0 +1,31 @@
+From: Sebastian Andrzej Siewior 
+Date: Tue, 24 Sep 2019 11:18:27 +0200
+Subject: [PATCH] tests: Skip test_load_ecdsa_no_named_curve
+
+The test_load_ecdsa_no_named_curve breaks with OpenSSL 1.1.1d which is
+due to to commit 9a43a733801bd ("[ec] Match built-in curves on
+EC_GROUP_new_from_ecparameters").
+
+Upstream is aware of the issue and it is tracked at
+	https://github.com/pyca/cryptography/issues/4998
+
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ tests/x509/test_x509.py | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/tests/x509/test_x509.py b/tests/x509/test_x509.py
+index 07a6019bd1394..c553636f27efe 100644
+--- a/tests/x509/test_x509.py
 b/tests/x509/test_x509.py
+@@ -4122,6 +4122,7 @@ ParsedCertificate = collections.namedtuple(
+ ec.ECDSA(cert.signature_hash_algorithm)
+ )
+ 
++@pytest.mark.skip(reason="Breaks with openssl 1.1.1d, https://github.com/pyca/cryptography/issues/4998";)
+ def test_load_ecdsa_no_named_curve(self, backend):
+ _skip_curve_unsupported(backend, ec.SECP256R1())
+ cert = _load_cert(
+-- 
+2.23.0
+
diff -Nru python-cryptography-2.6.1/debian/patches/update-our-test-to-be-more-robust-wrt-some-changes-f.patch python-cryptography-2.6.1/debian/patches/update-our-test-to-be-more-robust-wrt-some-changes-f.patch
--- python-cryptography-2.6.1/debian/patches/update-our-test-to-be-more-robust-wrt-some-changes-f.patch	1970-01-01 01:00:00.0 +0100
+++ python-cryptography-2.6.1/debian/patches/update-our-test-to-be-more-robust-wrt-some-changes-f.patch	2019-09-24 08:34:23.0 +0200
@@ -0,0 +1,35 @@
+From e575e3d482f976c4a1f3203d63ea0f5007a49a2a Mon Sep 17 00:00:00 2001
+From: Paul Kehrer 
+Date: Wed, 11 Sep 2019 12:12:30 +0800
+Subject: [PATCH] update our test to be more robust wrt some changes from
+ upstream (#4993)
+
+---
+ tests/hazmat/primitives/test_dh.py | 11 +--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+diff --git a/tests/hazmat/primitives/test_dh.py b/tests/hazmat/primitives/test_dh.py
+index c667cd16e1a6b..43f2ce5c0318b 100644
+--- a/tests/hazmat/primitives/test_dh.py
 b/tests/hazmat/primitives/test_dh.py
+@@ -157,8 +157,15 @@ from ...utils import load_nist_vectors, load_vectors_from_file
+ dh.generate_parameters(7, 512, backend)
+ 
+ def test_dh_parameters_supported(self, backend):
+-assert backend.dh_parameters_supported(23, 5)
+-assert not backend.dh_parameters_supported(23, 18)
++valid_p = int(
++b"907c7211ae61aaaba1825ff53b6cb71ac6df9f1a424c033f4a0a41ac42fad3a9"
++b"bcfc7f938a269710ed69e330523e4039029b7900977c740990d46efed79b9bbe"
++b"73505ae878808944ce4d9c6c52daecc0a87dc889c53499be93db8551ee685f30"
++b"349bf1b443d4ebaee0d5e8b441a40d4e8178f8f612f6

Bug#941452: stretch-pu: package python-cryptography/1.7.1-3+deb9u2

[Sebastian Andrzej Siewior]

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

The upload of OpenSSL 1.1.1d to unstable broke the testsuite of
python-cryptography in unstable. These changes are also part of OpenSSL
1.1.0l (which should pop in Stretch via security) and break the
testsuite.
Only one test breaks and I propose to disable it (same issue as in
unstable).

Sebastian
diff -Nru python-cryptography-1.7.1/debian/changelog python-cryptography-1.7.1/debian/changelog
--- python-cryptography-1.7.1/debian/changelog	2018-09-02 15:17:35.0 +0200
+++ python-cryptography-1.7.1/debian/changelog	2019-09-30 20:58:11.0 +0200
@@ -1,3 +1,11 @@
+python-cryptography (1.7.1-3+deb9u2) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Ignore test_load_ecdsa_no_named_curve in the testsuite because it known to
+break with newer openssl (Closes: #940547).
+
+ -- Sebastian Andrzej Siewior   Mon, 30 Sep 2019 20:58:11 +0200
+
 python-cryptography (1.7.1-3+deb9u1) stretch; urgency=medium
 
   * Remove BIO_callback_ctrl: The prototype differs with the OpenSSL's
diff -Nru python-cryptography-1.7.1/debian/patches/series python-cryptography-1.7.1/debian/patches/series
--- python-cryptography-1.7.1/debian/patches/series	2018-09-02 15:17:12.0 +0200
+++ python-cryptography-1.7.1/debian/patches/series	2019-09-30 20:58:11.0 +0200
@@ -1,3 +1,4 @@
 0001-add-memory-limit-check-for-scrypt.patch
 0002-fix-compilation-on-1.1.0f-3603.patch
 Remove-BIO_callback_ctrl.patch
+tests-Skip-test_load_ecdsa_no_named_curve.patch
diff -Nru python-cryptography-1.7.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch python-cryptography-1.7.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch
--- python-cryptography-1.7.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch	1970-01-01 01:00:00.0 +0100
+++ python-cryptography-1.7.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch	2019-09-30 20:58:11.0 +0200
@@ -0,0 +1,26 @@
+From: Sebastian Andrzej Siewior 
+Date: Tue, 24 Sep 2019 11:18:27 +0200
+Subject: [PATCH] tests: Skip test_load_ecdsa_no_named_curve
+
+The test_load_ecdsa_no_named_curve breaks with OpenSSL 1.1.1d which is
+due to to commit 9a43a733801bd ("[ec] Match built-in curves on
+EC_GROUP_new_from_ecparameters").
+
+Upstream is aware of the issue and it is tracked at
+	https://github.com/pyca/cryptography/issues/4998
+
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ tests/test_x509.py |1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/tests/test_x509.py
 b/tests/test_x509.py
+@@ -3512,6 +3512,7 @@ from .utils import load_vectors_from_fil
+ verifier.update(cert.tbs_certificate_bytes)
+ verifier.verify()
+ 
++@pytest.mark.skip(reason="Breaks with openssl 1.1.0l, https://github.com/pyca/cryptography/issues/4998";)
+ def test_load_ecdsa_no_named_curve(self, backend):
+ _skip_curve_unsupported(backend, ec.SECP256R1())
+ cert = _load_cert(

Bug#941450: linux-image-4.19.0-6-amd64: e1000e driver periodically resets card

[Christopher David Howie]

Package: linux-image-4.19.0-6-amd64
Version: 4.19.67-2+deb10u1

This issue looks like it might be related to #657689, or at least the
symptoms are similar.

Periodically, my network link goes down for ~35 seconds at a time.  I
have not been able to determine what traffic pattern or set of other set
of circumstances that causes this and it doesn't happen on a regular
schedule.  It could happen dozens of times an hour, then not happen for
many hours.

Here is the most recent sample of the error from my kernel log:

> [1816352.315998] e1000e :00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
>TDH  
>TDT  <47>
>next_to_use  <47>
>next_to_clean
>  buffer_info[next_to_clean]:
>time_stamp   <11b0fc627>
>next_to_watch<10>
>jiffies  <11b0fc789>
>next_to_watch.status <0>
>  MAC Status <80083>
>  PHY Status <796d>
>  PHY 1000BASE-T Status  <7800>
>  PHY Extended Status<3000>
>  PCI Status <10>
> [1816354.293145] e1000e :00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
>TDH  
>TDT  <47>
>next_to_use  <47>
>next_to_clean
>  buffer_info[next_to_clean]:
>time_stamp   <11b0fc627>
>next_to_watch<10>
>jiffies  <11b0fc978>
>next_to_watch.status <0>
>  MAC Status <80083>
>  PHY Status <796d>
>  PHY 1000BASE-T Status  <7800>
>  PHY Extended Status<3000>
>  PCI Status <10>
> [1816356.313154] e1000e :00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
>TDH  
>TDT  <47>
>next_to_use  <47>
>next_to_clean
>  buffer_info[next_to_clean]:
>time_stamp   <11b0fc627>
>next_to_watch<10>
>jiffies  <11b0fcb71>
>next_to_watch.status <0>
>  MAC Status <80083>
>  PHY Status <796d>
>  PHY 1000BASE-T Status  <7800>
>  PHY Extended Status<3000>
>  PCI Status <10>
> [1816358.293101] e1000e :00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
>TDH  
>TDT  <47>
>next_to_use  <47>
>next_to_clean
>  buffer_info[next_to_clean]:
>time_stamp   <11b0fc627>
>next_to_watch<10>
>jiffies  <11b0fcd60>
>next_to_watch.status <0>
>  MAC Status <80083>
>  PHY Status <796d>
>  PHY 1000BASE-T Status  <7800>
>  PHY Extended Status<3000>
>  PCI Status <10>
> [1816358.420838] e1000e :00:1f.6 enp0s31f6: Reset adapter unexpectedly
> [1816358.421364] br0: port 1(enp0s31f6) entered disabled state
> [1816362.315470] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow 
> Control: Rx/Tx
> [1816362.315560] br0: port 1(enp0s31f6) entered blocking state
> [1816362.315565] br0: port 1(enp0s31f6) entered listening state
> [1816377.364603] br0: port 1(enp0s31f6) entered learning state
> [1816392.468385] br0: port 1(enp0s31f6) entered forwarding state
> [1816392.468388] br0: topology change detected, propagating

I did not really notice this issue until I placed the interface into a
bridge (which it shares with qemu-kvm virtual interfaces to bridge them
to the physical network).  Placing it into the bridge adds 30 seconds of
bridge learning/listening time that exacerbates the issue and makes it
much easier to notice.

To clarify, this driver issue causes the physical interface to be down
for ~5 seconds only.  However, during that time the physical link
appears down to the bridge, which then adds another 30 seconds of
downtime after the physical link is restored.

Additional information:

> $ uname -a
> Linux chowie-desktop 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) 
> x86_64 GNU/Linux

> $ dpkg -l linux-image-\* | grep ^i
> ii  linux-image-4.19.0-5-amd64  4.19.37-5+deb10u2 amd64Linux 
> 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.19.0-6-amd64  4.19.67-2+deb10u1 amd64  

Bug#929597: not fixed by upstream

[Anton Gladky]

No activity from upstream.

Anton

Bug#941124: nmu: elixir-lang_1.9.1.dfsg-1

[Paul Gevers]

Control: reassign -1 src:erlang,src:elixir-lang
Control: retitle -1 elixir-lang (autopkgtest) fails with new erlang
Control: found -1 erlang/1:22.1+dfsg-1
Control: found -1 elixir-lang/1.9.1.dfsg-1
Control: severity -1 serious

On 25-09-2019 10:53, Sergei Golovan wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu elixir-lang_1.9.1.dfsg-1 . ANY . unstable . -m "Rebuild against erlang 
> 22.1"
> 
> Hi release team!
> 
> Apparently, elixir-land needs to be rebuilt against newer erlang 22.1.

That's not the proper way to solve bugs.

> Currently, it doesn't pass autopkgtest (see [1] for details).
> 
> There were some internal changes in Erlang re module (regular expressions) 
> which
> triggered the test failure. After a simple rebuild all tests pass again.

This means that either erlang changed something they shouldn't have
changed (think of software outside of the Debian archive here as well),
or elixir-lang is buggy and it is using something of erlang that it
should be using (in its autopkgtest). Please discuss and figure out
which package needs to fix something and reassign the package to it.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#941449: ITP: google-auth-httplib2 -- Google Authentication Library: httplib2 transport

[Valentin Vidic]

Package: wnpp
Severity: wishlist
Owner: Valentin Vidic 

* Package name: google-auth-httplib2
  Version : 0.0.3
  Upstream Author : Google Cloud Platform 
* URL : 
https://github.com/GoogleCloudPlatform/google-auth-library-python-httplib2
* License : Apache 2.0
  Programming Lang: Python
  Description : Google Authentication Library: httplib2 transport

Python library providing a httplib2 transport for google-auth.
This library is intended to help existing users of oauth2client migrate
to google-auth.

The intent of this package is to be used together with the existing
python3-googleapi package (see #935562). The package will be maintained
by the DPMT on salsa.

Bug#936681: gwyddion: Python2 removal in sid/bullseye

[Andreas Tille]

Hi Shayan,

On Mon, Sep 30, 2019 at 05:43:16PM +0100, he...@shayandoust.me wrote:
> Hello Andreas,
> 
> Many thanks for your reply, and after reading the referred mail, saving me 
> from a potential headache :). Now that I think of it, it may just be good 
> practice to look at other open bugs when working on packages.
> 
> The task will probably end up being big and future upstream releases would 
> probably just override any patches done, so I will revert the python patch 
> (insignificant) and keep the new upstream release.

I think we just leave gwyddion for later in the release cycle.  Just
harvest the lower hanging fruits and climb up later. ;-)
 
> Thanks again for informing & kind regards,

You are welcome.  I just try to make sure we will not burn active
newcomers. ;-)

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#934630: transition: octave

[Paul Gevers]

Hi Sébastien,

On 30-09-2019 13:43, Emilio Pozuelo Monfort wrote:
> On 30/09/2019 11:56, Sébastien Villemot wrote:
>> Hi Paul,
>>
>> Le dimanche 29 septembre 2019 à 21:57 +0200, Paul Gevers a écrit :
>>> On Mon, 12 Aug 2019 17:53:33 +0200 =?utf-8?q?S=C3=A9bastien_Villemot?= 
>>>  wrote:
 Please schedule a transition for octave 5.

 Most reverse dependencies have already been updated by the Debian Octave 
 Group
 and should therefore be compatible with the new version. We stand ready to 
 NMU
 other reverse dependencies should the need arise.
>>>
>>> Please go ahead.
>>
>> The new version (5.1.0-2) is now uploaded and built on all release
>> architectures, except on mipsel. The build failure seems transient to
>> me (memory exhausted), because version 5.1.0-1 built previously on the
>> same buildd, and there is nothing in the diff between the two versions
>> that can explain the problem.
> 
> I have given it back.

I tried it a second time. If it's three in a row, please check carefully
again.

I scheduled the binNMU's. The first reverse depends that needs checking
is nlopt.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#923198: would it work with elogind?

[Sven Joachim]

On 2019-02-25 01:20 +0100, Adam Borowski wrote:

> Control: tags -1 +patch
>
> [Can't test it right now, perhaps in the evening todorrow.  Noticed
> this bug filed on #-changes]
>
>> xserver-xorg-core has a hard dependency on libpam-systemd.  Violates
>> "Depends: This declares an absolute dependcy...
>
> No, it has only Recommends.  On the other hand, apt handles unwanted
> Recommends in a very nasty way, making it seem the dependency is absolute
> if there's any way the Recommends could possibly become satisfied (such
> as by switching the init to systemd).
>
>> I blasted libpam-systemd off my system and Xorg didn't even blink.
>
> If I recall correctly, logind (such as libpam-systemd) is needed if you run
> X not as root.  The vast majority of us uses gdm3/lightdm/sddm/wdm/xdm/...
> which happen to run as root, which makes the dependency indeed wrong even
> for Recommends.

I think you are mistaken here, with gdm3 (the default display manager)
the X server does _not_ run as root by default.

> But, instead of removing, you can change:
> Recommends: libpam-systemd
> to
> Recommends: default-logind | logind
>
> which works nicely with elogind.

Makes sense.  Can you confirm that rootless X works with elogind?
Use gdm3 as display manager, or startx and no display manager.

Cheers,
   Sven

Bug#941198: initscripts: packages should ship systemd units

[Bill Allombert]

On Sun, Sep 29, 2019 at 03:19:43PM +0100, Josh Triplett wrote:
> On Sun, 29 Sep 2019 12:03:11 +0200 Bill Allombert  wrote:
> > On Sat, Sep 28, 2019 at 06:02:52PM -0700, Russ Allbery wrote:
> > > Sean Whitton  writes:
> > > 
> > > > I don't currently have any reason to doubt we have a project consensus
> > > > that systemd unit files should be included in packages in addition to
> > > > sysvinit scripts, so I hope we can make this change.
> > > 
> > > I agree.  This seems entirely reasonable to me.  Both the behavior and the
> > > inherent documentation are better with unit files, and systemd is the
> > > default init system so that's an advantage for a lot of our users.
> > > 
> > > That said, if anyone does object to this, please do speak up and explain
> > > why this would be a problem.
> > 
> > There is a little technical detail that should be handled though:
> > User might have made change to /etc/default/xxx that is sourced
> > by /etc/init.d/xxx.
> > 
> > Such change must not be ignored by the unit files, because we require
> > configuration to be preserved across upgrade.
> 
> I've seen multiple packages handle this through maintainer scripts that
> migrate (non-default) settings from /etc/default to a systemd drop-in or
> similar configuration file.

Could you explain how they proceed ? That might help.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#935918: cups: can't read hpcups PPDs

[Didier 'OdyX' Raboud]

Control: affects -1 src:hplip 

Le mardi, 27 août 2019, 20.33:35 h CEST Raphaël Halimi a écrit :
> Today I was unable to print on a HP Envy 5030 connected with USB that
> used to work perfectly. The error message in CUPS web interface was
> "filter failed" or something (from memory).
> 
> Not able to find the problem, I tried to reinstall the printer;
> curiously, it worked with hpijs but not with hpcups. The error message
> was "Unable to copy PPD file" (again from memory).
> 
> Using the hpijs driver was not satisfying because the printing is not
> centered (in CUPS test page, the upper and right-most frame borders are
> missing, even after setting paper size to A4 from the default Letter),
> and it can't be corrected because the options are very limited, so I was
> determined to find why adding the printer with the hpcups driver was not
> working.
> 
> Adding it through HP ToolBox (from hplip) failed too, with an error
> message I don't remember.

FTR, this was circumvented in Debian's hplip package version 3.19.8+dfsg0-6.

Cheers,
OdyX
-- 
OdyX

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

Bug#941448: ITP: hw-probe -- Hardware probe and system info collection tool

[Mathieu Malaterre]

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 

* Package name: hw-probe
  Version : 1.4
  Upstream Author : Andrey Ponomarenko
* URL : https://github.com/linuxhw/hw-probe/
* License : LGPL 2.1
  Programming Lang: Perl
  Description : Hardware probe and system info collection tool

 A tool to probe for hardware and upload results to the Linux hardware
database https://linux-hardware.org

Bug#941447: pipenv: AttributeError when running 'pipenv check'

[Imre Jonk]

Package: pipenv
Version: 11.9.0-1
Severity: normal

Dear Maintainer,

The command 'pipenv check' fails with the following output:

Checking PEP 508 requirements…
Passed!
Checking installed package safety…
An error occurred:
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/pipenv/patched/safety.zip/__main__.py", 
line 8, in 
  File 
"/usr/lib/python3/dist-packages/pipenv/patched/safety.zip/click/core.py", line 
722, in __call__
  File 
"/usr/lib/python3/dist-packages/pipenv/patched/safety.zip/click/core.py", line 
697, in main
  File 
"/usr/lib/python3/dist-packages/pipenv/patched/safety.zip/click/core.py", line 
1066, in invoke
  File 
"/usr/lib/python3/dist-packages/pipenv/patched/safety.zip/click/core.py", line 
895, in invoke
  File 
"/usr/lib/python3/dist-packages/pipenv/patched/safety.zip/click/core.py", line 
535, in invoke
  File 
"/usr/lib/python3/dist-packages/pipenv/patched/safety.zip/safety/cli.py", line 
52, in check
AttributeError: module 'pip' has no attribute 'get_installed_distributions'


This command should return information about possible security issues with the
Python packages listed in the Pipfile. This issue on GitHub might be related:
https://github.com/pypa/pip/issues/5243


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pipenv depends on:
ii  python3   3.7.3-1
ii  python3-certifi   2018.8.24-1
ii  python3-pip   18.1-5
ii  python3-pkg-resources 40.8.0-1
ii  python3-virtualenv15.1.0+ds-2
ii  python3-virtualenv-clone  0.3.0-1.2

pipenv recommends no packages.

pipenv suggests no packages.

-- no debconf information

Bug#934289: evince-common: Make evince compatible with mailcap.order

[Jakub Wilk]

* Judicael Courant , 2019-08-09, 10:07:

I would like 'see foo.pdf' to open evince (for all users).

I guess mailcap.order(5) is the right place to give evince priority 
over other pdf readers. Unfortunately that does not work: I added 
the line


evince:application/pdf


FWIW, you should be able to make it work by using the name of the 
deskop file:


org.gnome.Evince:application/pdf

Admittedly this is neither intuitive nor (AFAIK) documented anywhere. 
:-/


In the mean time, someone opened #935426 asking for documentation 
update.


--
Jakub Wilk

Bug#941446: openttd: Upstream version 1.9.3 available

[Georg Kahest]

Package: openttd
Version: 1.9.1-1
Severity: wishlist

Dear Maintainer,

new upstream version 1.9.3 is available.

As of OpenTTD requires same version for multiplayer games to work Debian
users have to resort to building the game itself to multiplay.




signature.asc
Description: OpenPGP digital signature

Bug#941445: texlive-base: upgrade fails trying to overwrite files from texlive-doc-base 2019.20190830-1

[Johannes Schilling]

Package: texlive-base
Version: 2019.20190830-1
Severity: serious

Trying to upgrade my sid installation resulted in this error:



Unpacking texlive-latex-extra-doc (2019.20190930-1) over (2019.20190830-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-WVvQWm/83-texlive-latex-extra-doc_2019.20190930-1_all.deb 
(--unpack):
 trying to overwrite '/usr/share/doc/texlive-doc/latex-dev/base/README.md', 
which is also in package texlive-latex-recommended-doc 2019.20190830-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack 
.../84-texlive-latex-recommended-doc_2019.20190930-1_all.deb ...
Unpacking texlive-latex-recommended-doc (2019.20190930-1) over 
(2019.20190830-1) ...
Preparing to unpack .../85-texlive-luatex_2019.20190930-1_all.deb ...
Unpacking texlive-luatex (2019.20190930-1) over (2019.20190830-1) ...
Preparing to unpack .../86-texlive-pictures-doc_2019.20190930-1_all.deb ...
Unpacking texlive-pictures-doc (2019.20190930-1) over (2019.20190830-1) ...
Preparing to unpack .../87-texlive_2019.20190930-1_all.deb ...
Unpacking texlive (2019.20190930-1) over (2019.20190830-1) ...
Preparing to unpack .../88-texlive-fonts-extra-doc_2019.20190930-1_all.deb ...
Unpacking texlive-fonts-extra-doc (2019.20190930-1) over (2019.20190830-1) ...
Preparing to unpack 
.../89-texlive-fonts-recommended-doc_2019.20190930-1_all.deb ...
Unpacking texlive-fonts-recommended-doc (2019.20190930-1) over 
(2019.20190830-1) ...
Preparing to unpack .../90-texlive-latex-base-doc_2019.20190930-1_all.deb ...
Unpacking texlive-latex-base-doc (2019.20190930-1) over (2019.20190830-1) ...
Preparing to unpack .../91-texlive-metapost-doc_2019.20190930-1_all.deb ...
Unpacking texlive-metapost-doc (2019.20190930-1) over (2019.20190830-1) ...
Preparing to unpack .../92-texlive-full_2019.20190930-1_all.deb ...
Unpacking texlive-full (2019.20190930-1) over (2019.20190830-1) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-WVvQWm/83-texlive-latex-extra-doc_2019.20190930-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

-

the offending file is not contained in
texlive-latex-recommended-doc in version 2019.20190930-1 anymore, but as
you can see it's being unpacked in the wrong order. i'm not sure what
versioned breaks/depends/.. is needed to make this work, but manually
installing texlive-latex-recommended-doc in the newer version first and
then running apt upgrade again fixed the issue here.


regards,
   dario

Bug#939539: More info

[Felicia P]

I installed docker.io on an Ubuntu 18.04 machine running kernel
linux-image-5.0.0-29-generic and compared the output of the script
/usr/share/docker.io/contrib/check-config.sh with the Debian machine
running kernel linux-image-5.2.0-3-amd64.  The output on the left is the
Debian machine where docker will not run and the one on the right is the
Ubuntu one:

info: reading kernel config from /boot/config-5.2.0-3-amd | info:
reading kernel config from /boot/config-5.0.0-29-ge
- cgroup hierarchy: nonexistent?? | - cgroup
hierarchy: properly mounted [/sys/fs/cgr
    (see https://github.com/tianon/cgroupfs-mount)  <
- CONFIG_NF_NAT_IPV4: missing | - CONFIG_NF_NAT_IPV4:
enabled (as module)
- CONFIG_NF_NAT_NEEDED: missing   | - CONFIG_NF_NAT_NEEDED:
enabled
    (cgroup swap accounting is currently not enabled, y |  
(cgroup swap accounting is currently enabled)
- CONFIG_LEGACY_VSYSCALL_NONE: enabled    | -
CONFIG_LEGACY_VSYSCALL_EMULATE: enabled
    (containers using eglibc <= 2.13 will not work. Swi <
 "CONFIG_VSYSCALL_[NATIVE|EMULATE]" or use "vsyscal <
 on kernel command line. Note that this will disabl <
 VDSO which may assist in exploiting security vulne <
- CONFIG_CGROUP_HUGETLB: missing  | -
CONFIG_CGROUP_HUGETLB: enabled
- CONFIG_EXT4_FS: enabled (as module) | - CONFIG_EXT4_FS: enabled
  - CONFIG_CRYPTO_AEAD: enabled (as module)   |   -
CONFIG_CRYPTO_AEAD: enabled
  - CONFIG_CRYPTO_GCM: enabled (as module)    |   -
CONFIG_CRYPTO_GCM: enabled
  - CONFIG_CRYPTO_SEQIV: enabled (as module)  |   -
CONFIG_CRYPTO_SEQIV: enabled
  - CONFIG_CRYPTO_GHASH: enabled (as module)  |   -
CONFIG_CRYPTO_GHASH: enabled
  - CONFIG_INET_XFRM_MODE_TRANSPORT: missing |    -
CONFIG_INET_XFRM_MODE_TRANSPORT: enabled (a
    - CONFIG_AUFS_FS: missing | - CONFIG_AUFS_FS:
enabled (as module)
  (note that some kernels include AUFS patches but  <
    - CONFIG_BLK_DEV_DM: enabled (as module)  | -
CONFIG_BLK_DEV_DM: enabled


Basically you can see that on the Debian system where docker fails to
run the following are reported as missing:

cgroup hierarchy
CONFIG_NF_NAT_IPV4
CONFIG_NF_NAT_NEEDED
CONFIG_LEGACY_VSYSCALL_NONE
CONFIG_CGROUP_HUGETLB
CONFIG_AUFS_FS


I was also researching on forums and found that running
/usr/sbin/dockerd by itself is useful for debugging output.  Here is
what it reports on the Debian machine:

   Error starting daemon: Devices cgroup isn't mounted



0xCEC1B8C7E51FC983.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#941442:

[lugarci1 .]

I forgot to mention an important piece of information: this bug doesn't
arise when launching kate from the terminal, that is, using the command
"kate ". Also, it doesn't happen when launching kate
from dolphin.

Bug#940680: Provide backports for Buster

[Ghislain Vaillant]

On Mon, 23 Sep 2019 10:44:08 +0100 Simon McVittie 
wrote:
> On Thu, 19 Sep 2019 at 00:17:00 +0200, ghisv...@gmail.com wrote:
> > Since the release of freedesktop runtime version 19.08, flatpak
attempts
> > to install org.freedesktop.Platform.openh264 but fails with the
> > following warning message:
> > 
> > Warning: org.freedesktop.Platform.openh264 needs a later flatpak
version
> 
> This will be addressed by flatpak 1.2.5 in the next buster
> point release (see #940818). It should become available soon via
> buster-proposed-updates, if you want to test it early.

I'd be happy to. I have enabled buster-pu and await said update.

> > Would you consider providing backports of newer releases of flatpak
to
> > Buster to bypass future issues with new runtimes?
> 
> I'll probably do a backport eventually, but ideally using backports
> shouldn't be necessary in order to use Flathub, so fixing stable is a
> higher priority for me right now than maintaining backports.

Agreed. As a flatpak maintainer myself, I have not felt the need to
upgrade to a newer release even for development purposes.

Cheers,
Ghis

Bug#941437: [Pkg-rust-maintainers] Bug#941437: Include zsh-completion for cargo

[Jörg Sommer]

Sylvestre Ledru hat am Mo 30. Sep, 17:29 (+0200) geschrieben:
> Hello,
> Le 30/09/2019 à 17:01, Jörg Sommer a écrit :
> > Package: cargo
> > Version: 0.37.0-3
> > Severity: normal
> > 
> > Hi,
> > 
> > please include the completion for Zsh in the package:
> > 
> > https://github.com/rust-lang/cargo/blob/master/src/etc/_cargo
> Fixed in the repo, should be part of the next upload!

Merci.


-- 
Professor: ‚Gott‘, unverständliches und mythisches Wesen, das sich einmal
  pro Woche im Kreis der Sterblichen manifestiert um Weisheit auf Folien
  unter das Volk zu bringen.(Dschungelbuch 11, FSU Jena)


signature.asc
Description: PGP signature

Bug#941443: openssh-client: Causes terminal corruption by disabling XON/XOFF unconditionally

[Colin Watson]

On Mon, Sep 30, 2019 at 10:55:13AM -0500, John Goerzen wrote:
> I am using an original DEC vt420 serial terminal connected to a Debian
> box.  As with many such terminals, it:
[...]

Hi,

I think this needs to be forwarded upstream.  I'm often happy to do that
on people's behalf when I understand a bug well and/or can reproduce it,
but in this case neither of those things is true.  I also suspect that
working out the best fix is going to involve some back-and-forth between
you and upstream, and I'm going to add very little to that process other
than being a rather slow proxy.

Would you consider filing this directly upstream
(https://bugzilla.mindrot.org/)?  I know it's another account to create,
but I think it would work better.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#941443: openssh-client: Causes terminal corruption by disabling XON/XOFF unconditionally

[John Goerzen]

On Mon, Sep 30 2019, Colin Watson wrote:

> I think this needs to be forwarded upstream.  I'm often happy to do that
> on people's behalf when I understand a bug well and/or can reproduce it,
> but in this case neither of those things is true.  I also suspect that
> working out the best fix is going to involve some back-and-forth between
> you and upstream, and I'm going to add very little to that process other
> than being a rather slow proxy.
>
> Would you consider filing this directly upstream
> (https://bugzilla.mindrot.org/)?  I know it's another account to create,
> but I think it would work better.

Hi Colin,

That makes sense.  I created the report here:

https://bugzilla.mindrot.org/show_bug.cgi?id=3075

- John

Bug#935931: Re: Bug#935931: debian-installer: Reinstalling Debian on a current Debian installation without erasing or fomatting the home folder

[Daniel]

Dear Lennart,

I hope that when one opens a "whishlist bug" at least there is a chance 
to have a confrontation.


The main point I want to address is when you do a "smart installation" 
it is supposed to perform a clean installation hence the only folder 
that must to be untouched is "/home". The same concept when you have "/" 
and "/home" in separated partitions and you perform a clean 
installation. I think that is pretty trivial, the smart parts are:


* the installer is able to check for a previous Debian installation 
before to begin the process;


* and in case it founds a previous installation, the installer, is able 
to perform a fresh installation without overwriting the "/home" folder.


I can confirm that ElementaryOS and POP!_OS, that share the same 
installer, can do that.



Last point I want touch is about the swap partition. With the SSD and 
the OS able to boot in a bunch of seconds the hibernation doesn't make 
any sense today. For example I have 16GB of ram, based on the standard 
rules I should use at least 1.5x of the ram if not the double. It means 
that I should use 32GB just to hibernate my session, no way... With the 
SSD disks the lesser you write on the disk the better, I put just 2GB of 
swap-file and "swappiness" at 1 and the swap is never used and I didn't 
waste 30GB of space.


To conclude I think I elaborated everything clearly, I see a lot of 
benefits and improvement with the suggestions I gave to Debian, I also 
think that are pretty trivial to implement. I don't want introduce a 
Windows behavior of "reinstall when it broken", but back to time when I 
hadn't a fast internet connection it was faster download the full ISO 
and performing a fresh installation rather than doing a "dist-upgrade".


The bottom line is with a smart installer you don't need to separate 
your disk(s) in partitions but you can throw everything in "/" including 
the "swap" as swap-file that you can modify freely based on your needs 
(if you can't live without hibernation[1]). There is also a dynamic swap 
manager available on Debian as well: https://github.com/Tookmund/Swapspace



My best,

Daniel

[1] It needs some tuning to work: 
https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#Hibernation_into_swap_file



On 9/30/19 9:49 AM, Lennart Sorensen wrote:

On Sat, Sep 28, 2019 at 11:27:29PM -0400, Daniel wrote:

Hi Nicholas,

thanks for your reply, I really appreciated your constructive approach.

I use Debian since 2007 and I did a lot of installation, I personally use a
FrankenDebian (testing with pinning toward SID and Experimental) however
when I install Debian on other machines I install definitely the current
stable available. I have been performing exclusively desktop installations
and while I consider the best option separating /home recently I found
myself not able to get the right balance between "/", "/home" and "swap".
The default "/" assigned is often too small while sometimes I wasted
gigabyte never used. The "swap" with the amount of ram available today is
always more accessory and with the SSD disk the trend is to reduce its use
the most. Eventually I stopped to create a "swap" partition in favor of a
"swap-file" (like Raspian e.g.); hence I also stopped to create "/" and
"/home" but just "/" and still as LVM; at this point you don't have anymore
issue with the space and if you need you can add all the disks you want
because it is still a LVM partition.

Now the case I am figuring out is the one you didn't separe "/" and "/home"
(however the installer is still creating "swap") but you need to reinstall
Debian because you screwed it up for some reason. Now a smart installer
before to start everything takes its time to check the disk and discovers
that you have, along a crypted disk and a LVM group, also a previous version
of Debian hence check the users and it asks you if you want keep all the
users, just one, etc... and then it reinstalls the system and recovers the
setting from the user(s) you selected, without creating a FrankenDebian but
just a fresh and **smart** installation.

This leads in my opinion in creating a further voice for the Debian install:
**the desktop installation**; Standard and Advanced are eventually too
generic and do not target properly the desktop cases. If the D-I was
properly able to read LUKS and LVM during the installation time, and if was
also able to perform a smart installation as described in the paragraph
above, a Desktop installation should be:

1. Create an encrypted partition by default (LUKS + LVM);

I rarely do that, but I can see why some people want it.


2. install everything in / ;

I do tend to prefer that for most setups myself.


3. not create a "swap partition" but a swap-file.

My understanding is that suspend to disk works much easier with a swap
partition still, but my information could be out of date on that.
And of course swap smaller than ram makes suspend to disk not possible.


I also add that:

4. 

Bug#936681: gwyddion: Python2 removal in sid/bullseye

[hello]

Hello Andreas,

Many thanks for your reply, and after reading the referred mail, saving me from 
a potential headache :). Now that I think of it, it may just be good practice 
to look at other open bugs when working on packages.

The task will probably end up being big and future upstream releases would 
probably just override any patches done, so I will revert the python patch 
(insignificant) and keep the new upstream release.

Thanks again for informing & kind regards,
Shayan Doust

Bug#933217: RM: check-mk -- RoQA, RC-Buggy, unmaintained, no reverse dependency

[Matt Taggart]

Hi,

Thanks for opening this bug, this should have been discussed a while ago.

check-mk in debian was originally packaged and uploaded for Debian when
it was a pretty basic nagios add-on. Since then upstream has both
continued to add features and automation layers above that basic
functionality (OMD, BI, etc) and also at the same time made a commercial
business out of selling support and added non-FOSS components.

It is now very difficult to support the check-mk core functionality as
it's packaged in Debian. I began packaging the 1.4.0 stable release and
realized that the levels of integration of the core functionality and
the higher layers were going to make it nearly impossible to untangle.

For check-mk to continue in Debian we'd need to either:

1) fork the "Checkmk Raw Edition (CRE)" and work to remove the
dependencies and non-FOSS integration, maintaining the fork over time
and merging changes made to the core agents.

2) repackage the FOSS components, adopting all of upstream's levels of
automation and integration as a monolithic package and no longer just be
an add-on for other monitoring system.

My own use of check-mk involved using a puppet module to automatically
configure checks for new systems as they were added, by automatically
editing config files. This does not work well with the "full stack"
model where the administrator is expected to do things via a UI. So
option #2 is not interesting to me, and option #1 sounds like a lot of
work. What I need to do next is investigate icinga2's equivalent
functionality and see if that's a good replacement option.

I think it's fine for check-mk to be removed from unstable, if it does
end up in Debian again it will be repackaged and should go through NEW
again anyway.

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#941443: openssh-client: Causes terminal corruption by disabling XON/XOFF unconditionally

[John Goerzen]

Package: openssh-client
Version: 1:7.9p1-10
Severity: important

Hello,

I am using an original DEC vt420 serial terminal connected to a Debian
box.  As with many such terminals, it:

1) Is incapable of consistently processing incoming data, particularly
if it contains escape sequences, at line rate if the line rate is
above 4800bps (though it supports line rates up to 38400bps);

2) Supports only XON/XOFF flow control.

I observed issues that were clearly related to flow control with
sshing from it to other systems, although it was working fine
locally.  I narrowed it down to this code in
sshtty.c:enter_raw_mode():

tio.c_iflag &= ~(ISTRIP | INLCR | IGNCR | ICRNL | IXON | IXANY | IXOFF);

in other words, it unconditionally disables XON/XOFF handling on the
local machine.

You might be asking at this point: well, couldn't the remote handle
it?  And the answer is no, for several reasons:

1) The internal buffer on this terminal is tiny, far less than even
the TCP packet size.  It is quite possible -- likely, even -- that a
large screen update already caused a packet to be transmitted from the
remote end that will overflow the local buffer.

2) The latency in processing could mean that the remote sends enough
text to overflow the terminal's buffer after the terminal sends XOFF.

Other people from around the internet also report this issue.  For
instance:

https://superuser.com/questions/1096862/ssh-and-xon-xoff-software-flow-control

I recognize that there may be reasons to drop IXON and IXOFF by
default, but they are not appropriate for situations in which IXON and
IXOFF are legitimately needed.  Perhaps a configuration option here?

Thanks,

John

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libc6 2.28-10
ii  libedit2  3.1-20181209-1
ii  libgssapi-krb5-2  1.17-3
ii  libselinux1   2.8-1+b1
ii  libssl1.1 1.1.1c-1
ii  passwd1:4.5-1.1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
ii  ssh-askpass   1:1.2.4.1-10

-- no debconf information

Bug#941360: fwupd: Failed to activate service: timed out

[Francois Marier]

On 2019-09-29 at 23:57:02, mario.limoncie...@dell.com wrote:
> What version did you upgrade from? And was that directory already existing or 
> did it get created with the package?

I'm also affected by this problem. In my case, I also purged the package and
reinstalled it. The problem persists and the cache symlink looks like this:

$ ls -l /var/cache/fwupd
lrwxr-xr-x 1 root root 13 sep 28 20:48 /var/cache/fwupd -> private/fwupd

Francois

-- 
https://fmarier.org/

Bug#941437: [Pkg-rust-maintainers] Bug#941437: Include zsh-completion for cargo

[Sylvestre Ledru]

Hello,
Le 30/09/2019 à 17:01, Jörg Sommer a écrit :

Package: cargo
Version: 0.37.0-3
Severity: normal

Hi,

please include the completion for Zsh in the package:

https://github.com/rust-lang/cargo/blob/master/src/etc/_cargo

Fixed in the repo, should be part of the next upload!

Cheers,
Sylvestre

Bug#934386: Bug#894663: transition: wxwidgets3.0

[Gunter Königsmann]

On 28.09.19 04:43, Olly Betts wrote:
> On Fri, Sep 27, 2019 at 05:53:17AM +0200, Gunter Königsmann wrote:
>> All the workarounds for crashes due to gtk3 bugs would have been
>> relevant, though => will make a new release as soon as I can.
> Crashes?  I don't think you've reported any crashes...
>
> I thought the two remaining bugs affecting wxmaxima were the
> two finger touchpad scroll not working, and scrolling flickering?
>
> Neither is ideal but neither is a crash.

I fix about five bugs in wxMaxima a week. Reporting a bug to debian
costs at least one week of work and wxMaxima is using enough of
wxWidget's functionality that it has the potential of being a near-ideal
bug detector for wxWidgets  => If I can work around a bug I do that
instead of reporting it. Else we would need a bigger team for supporting
wxMaxima.

> Oh, and perhaps a wxDC::Clear() issue which upstream closed but
> you claimed still isn't working.  Though I noticed in your current
> git master `WORKING_DC_CLEAR` always ends up defined (by line 370 of
> src/Worksheet.cpp) and so your rectangle drawing workaround is never
> actually used.  I didn't see any obvious window clearing issues in my
> testing FWIW.  But anyway, this one wasn't a crash either.

As there have been no new bug reports after the wxMaxima version from
July was uploaded I am rather curious if any of the problems I've
encountered are likely to materialize on other computers. Perhaps I have
managed to transform my system into a quite complete test case somehow -
which isn't bad as until now I've been able to reproduce (and in most
cases to resolve) all bug reports I got for wxMaxima.

Kind regards,

    Gunter.

Bug#941442: plasma-desktop: Taskbar freezes when launching kate from desktop

[Luis Garcia]

Package: plasma-desktop
Version: 4:5.14.5.1-2
Severity: important

Dear Maintainer,

Launching a text document with kate from an icon on the desktop freezes the 
taskbar. You can still swith betweek windows with ALT+Tab. Doesn't happen with 
other programs I tested, as okular

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

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

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.14.5-2
ii  kactivitymanagerd5.14.5-1
ii  kde-cli-tools4:5.14.5-1
ii  kded55.62.0-1
ii  kio  5.54.1-1
ii  kpackagetool55.62.0-1
ii  libappstreamqt2  0.12.9-1
ii  libc62.29-2
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-8
ii  libkf5activities55.62.0-1
ii  libkf5activitiesstats1   5.62.0-1
ii  libkf5archive5   5.62.0-1
ii  libkf5auth5  5.62.0-1
ii  libkf5baloo5 5.62.0-2
ii  libkf5codecs55.62.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.62.0-1
ii  libkf5configgui5 5.62.0-1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5coreaddons55.62.0-1
ii  libkf5dbusaddons55.62.0-1
ii  libkf5declarative5   5.54.0-1
ii  libkf5emoticons-bin  5.62.0-1
ii  libkf5emoticons5 5.62.0-1
ii  libkf5globalaccel-bin5.62.0-1
ii  libkf5globalaccel5   5.62.0-1
ii  libkf5guiaddons5 5.62.0-1
ii  libkf5i18n5  5.62.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5itemmodels55.62.0-1
ii  libkf5itemviews5 5.62.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kcmutils5  5.54.0-1
ii  libkf5kdelibs4support5   5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5newstuff5  5.54.0-2
ii  libkf5notifications5 5.62.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5package5   5.62.0-1
ii  libkf5parts5 5.54.0-1
ii  libkf5people55.54.0-1
ii  libkf5peoplewidgets5 5.54.0-1
ii  libkf5plasma55.54.0-1
ii  libkf5plasmaquick5   5.54.0-1
ii  libkf5quickaddons5   5.54.0-1
ii  libkf5runner55.54.0-1
ii  libkf5service-bin5.62.0-1
ii  libkf5service5   5.62.0-1
ii  libkf5solid5 5.62.0-2
ii  libkf5sonnetui5  5.62.0-1
ii  libkf5wallet-bin 5.62.0-1
ii  libkf5wallet55.62.0-1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.62.0-2
ii  libkf5xmlgui55.54.0-1
ii  libkfontinst54:5.14.5.1-2
ii  libkfontinstui5  4:5.14.5.1-2
ii  libkworkspace5-5 4:5.14.5.1-1
ii  libphonon4qt5-4  4:4.10.3-3
ii  libqt5concurrent55.11.3+dfsg1-4
ii  libqt5core5a 5.11.3+dfsg1-4
ii  libqt5dbus5  5.11.3+dfsg1-4
ii  libqt5gui5   5.11.3+dfsg1-4
ii  libqt5network5   5.11.3+dfsg1-4
ii  libqt5printsupport5  5.11.3+dfsg1-4
ii  libqt5qml5   5.11.3-4
ii  libqt5quick5 5.11.3-4
ii  libqt5quickwidgets5  5.11.3-4
ii  libqt5sql5   5.11.3+dfsg1-4
ii  libqt5svg5   5.11.3-3
ii  libqt5widgets5   5.11.3+dfsg1-4
ii  libqt5x11extras5 5.11.3-2
ii  libqt5xml5   5.11.3+dfsg1-4
i

Bug#875523: fixed in xournal 1:0.4.8.2016-1

[Michael Biebl]

Control: found -1 1:0.4.8.2016-4

On Fri, 08 Mar 2019 14:50:15 + b...@debian.org (Barak A. Pearlmutter)
wrote:
> Source: xournal
> Source-Version: 1:0.4.8.2016-1
> 
> We believe that the bug you reported is fixed in the latest version of
> xournal, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 875...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Barak A. Pearlmutter  (supplier of updated xournal package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Tue, 05 Mar 2019 12:23:51 +
> Source: xournal
> Binary: xournal xournal-dbgsym
> Architecture: source amd64
> Version: 1:0.4.8.2016-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Carlo Segre 
> Changed-By: Barak A. Pearlmutter 
> Description:
>  xournal- GTK+ Application for note taking
> Closes: 748165 820619 864863 869821 875523 876098
> Changes:
>  xournal (1:0.4.8.2016-1) unstable; urgency=medium
>  .
>* New upstream release (closes: #869821)
>  - removes ancient xxx(null) formal parameter (closes: #748165)
>* Upgrade to debhelper 12, tweaking build scripts accordingly
>  - build architecture configuration issue (closes: #876098)
>  - enables parallel building (closes: #820619)
>* Upgrade to Standards-Version 4.3.0
>* Remove menu file, per policy
>* Trim debian/changelog whitespace
>* Add pointer to packaging repo in salsa
>* Disable ldflags patch; handled automatically by debhelper
>* Remove debian/xournal.1 emacs major mode comment; emacs knows all
>* Harden
>* Add self as uploader
>* Remove now-superfluous linker as-needed quilt patch
>* Add desktop file tweaks quilt patch
>* Add doc-base entry for user's manual
>* Address some compiler warnings quilt patch
>* Catalan translation update patch (closes: #864863)
>* Remove KDE3 cruft (closes: #875523)


Seems like that this was not fixed properly or there was a regression in
the mean time:
1:0.4.8.2016-4 again/still ships the mimelnk files, see
https://packages.debian.org/sid/amd64/xournal/filelist

/usr/share/mimelnk/application/x-xoj.desktop
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#941441: Fails to upgrade, file conflict with texlive-latex-recommended

[Michael Biebl]

Package: texlive-latex-extra
Version: 2019.20190830-1
Severity: serious

Hi,

today's upgrade failed with the following error message:

Entpacken von texlive-latex-extra (2019.20190930-1) über (2019.20190830-1) ...
dpkg: Fehler beim Bearbeiten des Archivs 
/tmp/apt-dpkg-install-kMweLU/45-texlive-latex-extra_2019.20190930-1_all.deb 
(--unpack):
 Versuch, »/usr/share/man/man1/latex-dev.1.gz« zu überschreiben, welches auch 
in Paket texlive-latex-recommended 2019.20190830-1 ist
dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Datenübergabe 
unterbrochen (broken pipe)) getötet
Vorbereitung zum Entpacken von 
.../46-texlive-latex-recommended_2019.20190930-1_all.deb ...
Entpacken von texlive-latex-recommended (2019.20190930-1) über 
(2019.20190830-1) ...
Vorbereitung zum Entpacken von .../47-texlive_2019.20190930-1_all.deb ...
Entpacken von texlive (2019.20190930-1) über (2019.20190830-1) ...
Fehler traten auf beim Bearbeiten von:
 /tmp/apt-dpkg-install-kMweLU/45-texlive-latex-extra_2019.20190930-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)




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

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

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.91-2
ii  python 2.7.16-1
ii  python33.7.3-1
it  tex-common 6.12
iu  texlive-base   2019.20190930-1
ii  texlive-binaries   2019.20190605.51237-3
iu  texlive-latex-recommended  2019.20190930-1
iu  texlive-pictures   2019.20190930-1

Versions of packages texlive-latex-extra recommends:
iu  texlive-fonts-recommended  2019.20190930-1
iu  texlive-plain-generic  2019.20190930-1

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles
ii  libfile-which-perl  1.23-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments 2.3.1+dfsg-1
pn  texlive-latex-extra-doc 

Versions of packages tex-common depends on:
ii  dpkg  1.19.7
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
ii  debhelper  12.6.1

Versions of packages texlive-latex-extra is related to:
it  tex-common6.12
ii  texlive-binaries  2019.20190605.51237-3

-- debconf information excluded

Bug#941440: RFS: wxmaxima/19.09.1-1 -- GUI for the computer algebra system Maxima

[Gunter Königsmann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: wxmaxima
   Version : 19.09.1-1
   Upstream Author : Gunter Königsmann 
 * URL : http://wxmaxima-developers.github.io/wxmaxima/
 * License : GPL-2
 * Vcs : https://github.com/wxMaxima-developers/wxmaxima
   Section : math

It builds those binary packages:

  wxmaxima - GUI for the computer algebra system Maxima

Maxima is a cool program as it does solve mathematical problems but unlike 
other programs tries to find an equation
that provides a general solution, not only a number that solves this special 
case:

(%i1)   eq1:x^2+x-3=y;
(eq1)   x^2+x-3=y
(%i2)   solve(%,x);
(%o2)   [x=-(sqrt(4*y+13)+1)/2,x=(sqrt(4*y+13)-1)/2]

Maxima now comes as a pure command-line utility. wxMaxima is a graphical 
front-end that provides maxima with 2d
Equations, can render these as Bitmap/MathJaX/SVG/EMF/RTF and contains a 
comfortable editor including an undo 
function, many wizards and the ability to embed text, sectioning and graphics 
into the worksheet.

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

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

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

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

Changes since the last upload:

   * A new upstream version
   * The debian package now uses GTK3
   * Bumped the standards version to 3.9.8
   * New build depends for the automatic tests: netcat-openbsd, xvfb,
 debian-file-utils and appstream-util


The new Upstream version might be important for a smooth user experience, this 
time, as wxMaxima makes intensive use 
of (many? most?) of the funktionalities wxWidgets offers and the GTK3 
transition of debian seems to have triggered 
many bugs that have not yet been reported against the package wxMaxima - but 
did affect me causing me to work around 
them and to upstream the solutions before creating the release.

Regards,

--
Gunter Königsmann

Bug#778564: Should be possible to preseed ntp server

[Ian Jackson]

Just to confirm that this is still an issue in current buster.

Ian.

Bug#941439: Ships obsolete mimelnk directory

[Michael Biebl]

Package: libreoffice-common
Version: 1:6.3.2-1
Severity: minor

Hi,

libreoffice-common ships an unused, obsolete
/usr/share/mimelnk directory.

Those were used in KDE3 days which is long gone.
This directory can be dropped safely from the package.

Regards,
Michael

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

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

Versions of packages libreoffice-common depends on:
ii  libnumbertext-data 1.0.5-3
ii  libreoffice-style-colibre  1:6.3.2-1
ii  libreoffice-style-tango1:6.3.2-1
ii  ure6.3.2-1

Versions of packages libreoffice-common recommends:
ii  apparmor2.13.3-5
ii  fonts-liberation2   2.00.5-2
ii  libexttextcat-data  3.4.5-1
ii  python3-uno 1:6.3.2-1
ii  xdg-utils   1.1.3-1

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-colibre [libreoffice-style] 1:6.3.2-1
ii  libreoffice-style-elementary [libreoffice-style]  1:6.3.2-1
ii  libreoffice-style-tango [libreoffice-style]   1:6.3.2-1

Versions of packages python3-uno depends on:
ii  libc6 2.29-2
ii  libgcc1   1:9.2.1-8
ii  libpython3.7  3.7.4-4
ii  libreoffice-core  1:6.3.2-1
ii  libstdc++69.2.1-8
ii  python3   3.7.3-1
ii  python3.7 3.7.4-4
ii  uno-libs3 6.3.2-1
ii  ure   6.3.2-1

-- no debconf information

Bug#941438: lua-create-gitbuildpackage-layout references alioth

[Helmut Grohne]

Package: dh-lua
Version: 25
Severity: important
File: /usr/bin/lua-create-gitbuildpackage-layout

lua-create-gitbuildpackage-layout references alioth.debian.org rather
than salsa. I suppose that it doesn't work at all anymore.

Helmut

Bug#941399: dino-im FTCBFS: configures for the build architecture

[Martin]

Note this remark by upstream in xmpp:c...@dino.im?join :


[12:55:59] ‎larma‎: debacle: I did cross compile dino. You
probably don't want to use the ./configure script for it, but
use CMake directly

‎> [13:00:14] ‎larma‎: All I had to do was to set PKG_CONFIG_PATH

and CMAKE_TOOLCHAIN_FILE

‎> [13:01:13] ‎larma‎: We don't use valac's compilation feature (we

only use it for transpiling), so there shouldn't be any issues
specific to vala

‎> [13:03:29] ‎larma‎: But that was on Fedora, not Debian

Bug#940678: Please import pools by stable device label

[Alberto Berti]

> "Antonio" == Antonio Russo  writes:

>> The pool systematically fails to mount after the upgrade, at each boot,
>> even if I manually mounted it.. 


Antonio> The terminology with ZFS is a little different: pools are 
"imported"
Antonio> and the datasets (that are filesystems rather than, say, zvols) 
are then
Antonio> "mounted".  It sounds like you cannot import the pool, and 
therefore you
Antonio> cannot mount the datasets.

yes, that's the case

Antonio> Is your problem reproducible? By that I mean, on reboot, does the 
pool
Antonio> import or not?

no, that's the problem

Antonio> And what do you mean by "manually mounted it"? Are you talking 
about

Antonio> # zpool import -d /dev -aN

And subsequent

 zfs mount -a

Antonio> If it's not mounting on reboot, just use -d /dev/disk/by-id next 
time,
Antonio> and the problem should go away.

Yes, I'll try today or tomorrow night

>> this leads to data loss from a user pow, because the data that's not> 
there may get re-written and generate conflicts.
Antonio> If another application does not gracefully handle missing data, by 
all
Antonio> means that is a bug for that application. That's not, however, a 
ZFS
Antonio> bug.

from my point of view, the problem is that even if a
storage-relate unit (zfs-import-cache) fails, causing the missing mount
of some fs, the system reaches a state where it's considered ok for the
services to start.


Antonio> I would encourage you to open a separate bug, unrelated to this, 
for
Antonio> that issue.

>> 
Antonio> so that your import is done by labels that are stable
Antonio> across boots (names like /dev/sdX are not necessarily
Antonio> stable). This is a "well-known" best practice with ZFS [1]
Antonio> (you should always create pools using these symlinks as
Antonio> well).
>> 
>> good to know, thanks. Although I think that if the hardware
>> configuration nor the kernel version changes between the boots, we can
>> assume that each block device will get the same id... anyway I'll try it.

Antonio> You can check this---note which device nodes are being linked by 
the
Antonio> stable identifiers in /dev/disk/by-id. Do they change on reboot?

Antonio> If you find that your device nodes are to exactly the same drives, 
and
Antonio> yet the pool is not importing as you have found, that's definitely 
a bug,
Antonio> and we'll have to file it upstream. You will need verbatim dmesg 
logs,
Antonio> the zpool status $poolname output, and the output of ls -l 
/dev/disk/by-id
Antonio> on subsequent boots.

Antonio> Upstream will want to see exactly what is going on with the device 
nodes,
Antonio> since that's the most likely cause of this problem.

ok, I'll try your proposed fixes and report back, thanks.

Antonio> Yes, to export a pool, none of its datasets can be in use (e.g., 
mounted).
Antonio> Be careful with the terminology here---exporting a filesystem (or 
dataset)
Antonio> means something totally different than exporting a pool.

yes, the reuse of the terms at both zpool and zfs level is tricky

-- 
Alberto Berti  -  Information Technology Consultant
PGP: 9377 A68C C5B5 B534 36BD  F20B E3B5 C559 99D6 7CF9

"gutta cavat lapidem"