Bug#926231: [debian-mysql] Bug#926231: mariadb-server-10.3: dpkg configure error - upgrade from mysql

[Olaf van der Spek]

On Wed, Apr 3, 2019 at 11:12 PM Graham Cobb  wrote:
> I'm not sure what the "MariaDB error log" is but I have found the following 
> entries in syslog:

It's /var/log/mysql/error.log

Bug#926368: Updating the foo2zjs Uploaders list

[Tobias Frost]

Source: foo2zjs
Version: 20170320dfsg0-2 20171202dfsg0-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Luca Capello  has retired, so can't work on
the foo2zjs package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#920692: (no subject)

[innnzzz6]

Sent from my iPhone

Bug#926147: ERROR: Connection to mail.myhost.lt:995 failed.

[Giedrius Vaivilavičius]

Thank you very much for your reply. Your answer has helped to solve this 
problem. Also grateful to you for showing security gaps. I will notify my 
administrator.




On Mon, 1 Apr 2019 10:18:39 +0200 Ricardo Mones  wrote:
> control: tags -1 moreinfo
> 
> Hi Giedrius,
> 
> On Mon, Apr 01, 2019 at 09:48:10AM +0300, Giedrius wrote:
> > Package: sylpheed
> > Version: 3.7.0-4
> > Severity: normal
> > 
> > After upgrading from strech to buster doesn't send and
> >   does not receive emails. Written by ERROR: Connection to mail.am.lt:995
> > failed.
> > I can't find anything that might be bad in the settings. With Debian strech,
> > the same settings work well.
> > Terminal writes:
> > .comments: unlink: Folders
> > 
> > (sylpheed: 12851): LibSylph-WARNING **: 09: 39: 06.590: SSL_connect () 
> > failed
> > with error 1, ret = -1 (error: 1425F102: SSL routines:
> > ssl_choose_client_version: unsupported protocol)
> > 
> > 
> > (sylpheed: 12851): LibSylph-WARNING **: 09: 39: 06.590: can't initialize 
> > SSL.
> > 
> > (sylpheed: 12851): LibSylph-WARNING **: 09: 39: 06.590: [09:39:06] Couldn't
> > connect.
> > 
> > gmail.com account is working well.
> > 
> > Maybe you can advise what's wrong here.
> 
> The server probably doesn't support TLS v1.2 protocol, which has been
> added as minimum requirement in buster.
> 
> You can workaround this by downgrading MinProtocol and/or CipherString
> in the system_default_sect section of your /etc/ssl/openssl.cnf file,
> and see if it works, but:
> 
>   ! Notice that such changes will make *all* your SSL connections less
>   ! secure. Upgrading the server to support TLS v1.2 is the right fix.
> 
> regards,
> -- 
>   Ricardo Mones 
>   ~
>   Quantity derives from measurement, figures from quantities, 
>   comparisons from figures, and victories from comparisons. 
>   Sun Tzu



-- 
Giedrius Vaivilavičius 

Bug#890550: new upstream repo:

[Jeffrey Cliff]

https://gitlab.parity.io/parity/parity-ethereum/

Bug#926367: ITP: fontparts -- API for interacting with the parts of fonts

[魏銘廷]

Package: wnpp
Severity: wishlist
Owner: Yao Wei (魏銘廷) 
Control: block 926090 by -1

* Package name: fontparts
  Version : 0.8.6
  Upstream Author : The RoboFab Developers
* URL : https://github.com/robotools/fontParts
* License : Expat
  Programming Lang: Python
  Description : API for interacting with the parts of fonts

An API for interacting with the parts of fonts during the font
development process. FontParts is the replacement for RoboFab.

This is the dependency of ufoprocessor (#926090), which in turn is the
dependency of afdko (#762252).  This package should be team maintained
under Debian Fonts Task Force.


signature.asc
Description: PGP signature

Bug#860431: building preliminary package

[Jeffrey Cliff]

at the notabug upstream repo, there is a directory for building a package
that successfully builds.
hopefully this helps,
Jeff Cliff

Bug#860431: post NSA/Microsoft upstream change

[Jeffrey Cliff]

Control: retitle -1 RFP: golang-notabug-themusicgod1-cp-dev -- File Copying
for Go

Bug#855494: Broken with different error - I'm going to ask for removal of the package soon

[Andreas Tille]

Hi,

I stumbled again about this package:

$ runPmv
Run PMV from  /usr/lib/python2.7/dist-packages/Pmv
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/Pmv/__init__.py", line 378, in runPmv
from Pmv.moleculeViewer import MoleculeViewer
  File "/usr/lib/python2.7/dist-packages/Pmv/moleculeViewer.py", line 19, in 

from DejaVu.Geom import Geom
  File "/usr/lib/python2.7/dist-packages/DejaVu/__init__.py", line 201, in 

from Viewer import Viewer
  File "/usr/lib/python2.7/dist-packages/DejaVu/Viewer.py", line 50, in 
from DejaVu.Camera import Camera
  File "/usr/lib/python2.7/dist-packages/DejaVu/Camera.py", line 39, in 
import Image
ImportError: No module named Image
hit enter to continue


I wonder whether this will be finally fixed.  I somehow lost track in
my attempt to remove this package which seems to fail again and again
for different reasons. :-(

BTW, Steffen, did you asked upstream for a change of the license for
theis future release?

Kind regards

 Andreas.

On Sun, Feb 11, 2018 at 10:00:31AM +0100, Andreas Tille wrote:
> Hi,
> 
> I just get:
> 
> 
> $ runPmv 
> Run PMV from  /usr/lib/python2.7/dist-packages/Pmv
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/Pmv/__init__.py", line 381, in runPmv
> title=title, withShell= not interactive, verbose=False, gui=gui)
>   File "/usr/lib/python2.7/dist-packages/Pmv/moleculeViewer.py", line 1026, 
> in __init__
> trapExceptions=trapExceptions)
>   File "/usr/lib/python2.7/dist-packages/ViewerFramework/VF.py", line 384, in 
> __init__
> self.GUI = ViewerFrameworkGUI(self, title=title,
> NameError: global name 'ViewerFrameworkGUI' is not defined
> 
> Please include this Traceback in your bug report.
> 
> hit enter to continue
> 
> 
> 
> There is some splash screen that vanishes after hitting enter in the
> terminal.
> 
> Please fix the package soon or I'll ask for removal from Debian.
> 
> Thank you
> 
>Andreas.
> 
> -- 
> http://fam-tille.de
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#926366: Allow /etc/default/grub.local.pre and .post

[積丹尼 Dan Jacobson]

Package: grub-pc
Version: 2.02+dfsg1-16
Severity: wishlist

I am trying to get the "final word" in how these grub variables are
appended.

Can you please specify a files, e.g.,
/etc/default/grub.local.pre
/etc/default/grub.local.post
that are initially absent, and guaranteed never to be written by anybody else 
than the user.

I tried doing

$ cat /etc/default/grub
. /root/grub.local.sh #jidanni

GRUB_CMDLINE_LINUX="panic=33 earlyprintk=vga video=SVIDEO-1:d"

GRUB_CMDLINE_LINUX_DEFAULT=""

GRUB_TIMEOUT=11

But as you see, those three "helpful GRUB_" lines got pasted on the end
anyway.

The idea is I wouldn't have to modify any file of _yours_, but still get
_my_ customizations read.

Bug#926340: preliminary building package

[Jeffrey Cliff]

at the above repo, there is now a preliminary building package directory
(that also passes all the mocha tests)

Hope this helps,
Jeff Cliff

Bug#926365: Network location provider at 'https://www.googleapis.com/' : Returned error code 403.

[積丹尼 Dan Jacobson]

Package: chromium
Version: 73.0.3683.75-1

Please see
https://bugs.chromium.org/p/chromium/issues/detail?id=753242#c31

Bug#926207: iotop: unable to run on kernels with retpoline (spectre)

[Paul Wise]

On Wed, 2019-04-03 at 12:17 -0600, Neil Tallim wrote:

> I was able to confirm that the problem doesn't occur with Debian's
> 4.19 series on unrelated hardware, however, and it looks like the
> problem has been resolved for a while in stock kernels.

OK, thanks for confirming this.

> https://lists.ubuntu.com/archives/kernel-team/2018-May/092723.html
> I wasn't able to find an equivalent in Debian's patchsets, which led
> me to check upstream; more on that below.

Thanks for the reference. I had a look at the Linux mainline master and
it appears that it was never affected by this issue, because the SSB
line was added *after* the Seccomp one lost its trailing \n character.

> After digging around for a while, it looks like this may be a side-
> effect of how LTSI works, though I'll report it anyway, in hopes that
> it can be addressed without violating the "don't break the userspace
> ABI" policy. Any semi-recent kernel version should be unaffected.

That sounds like a good idea to me, thanks.

> The following patch adds a "NoNewPrivs" line to /proc//status,
> where the blank appears in 4.4. It doesn't look like it was ever
> backported into the tree, or, rather, it seems to be the case that
> retpoline logic, which assumed there was text right after the
> capabilities block, was backported directly, leading to the gap.

Ack. This code seems like a very fragile design and not a very good API
but at least the current convention of printing the \n before each new
option should prevent future additions of blank lines.

> In any case, this is definitely an issue that should be fixed in
> (specific versions of) the kernel. I still think iotop should be
> synced to gain tolerance to unexpected input, but it isn't a Debian-
> specific problem in light of what's been discussed here.

That will happen eventually, but it won't reach Debian buster because
we are in the freeze now and the bug is not important enough.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#926149: AMD: Add nomodeset kernel parameter to avoid black screen

[積丹尼 Dan Jacobson]

And lo and behold, in /etc/grub.d/10_linux :

if [ "$ubuntu_recovery" = 1 ]; then
GRUB_CMDLINE_LINUX_RECOVERY="$GRUB_CMDLINE_LINUX_RECOVERY nomodeset"
fi

Bug#924493: stretch-pu: package publicsuffix/20190221.0923-0+deb9u1

[Daniel Kahn Gillmor]

On Tue 2019-03-26 10:21:12 +0100, Daniel Kahn Gillmor wrote:
> On Wed 2019-03-13 11:12:26 -0400, Daniel Kahn Gillmor wrote:
>> Package: release.debian.org
>> Severity: normal
>> Tags: stretch
>> User: release.debian@packages.debian.org
>> Usertags: pu
>> Control: affects -1 src:publicsuffix
>>
>> Please consider an update to publicsuffix in debian stretch.
>
> Ping!
>
> If 20190221.0923-0+deb9u1 of publicsuffix could make it into stretch, we
> could close https://bugs.debian.org/879008, a concern from a user that
> they're not getting frequent enough updates about the state of the known
> publicly-registerable DNS suffixes.

here's another weekly ping on this issue.  I'd really like to be able to
keep the PSL more up-to-date than it has been in stretch.

 --dkg

Bug#926364: unblock: itamae/1.9.10-2

[Hideki Yamane]

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

Please unblock package itamae

 itamae in testing causes execusion error and 1 line patch
 taken from upstream fixes it. Here's debdiff.

diff -Nru itamae-1.9.10/debian/changelog itamae-1.9.10/debian/changelog
--- itamae-1.9.10/debian/changelog  2016-12-01 19:23:31.0 +0900
+++ itamae-1.9.10/debian/changelog  2019-04-02 17:57:32.0 +0900
@@ -1,3 +1,12 @@
+itamae (1.9.10-2) unstable; urgency=medium
+
+  * Team upload.
+  * debian/patches
+- add 0002-fix-exec-error-taken-from-upstream.patch to fix
+  execution error (Closes: #926220)
+
+ -- Hideki Yamane   Tue, 02 Apr 2019 17:57:32 +0900
+
 itamae (1.9.10-1) unstable; urgency=low
 
   * Initial release (Closes: #842932)
diff -Nru 
itamae-1.9.10/debian/patches/0002-fix-exec-error-taken-from-upstream.patch 
itamae-1.9.10/debian/patches/0002-fix-exec-error-taken-from-upstream.patch
--- itamae-1.9.10/debian/patches/0002-fix-exec-error-taken-from-upstream.patch  
1970-01-01 09:00:00.0 +0900
+++ itamae-1.9.10/debian/patches/0002-fix-exec-error-taken-from-upstream.patch  
2019-04-02 17:57:32.0 +0900
@@ -0,0 +1,21 @@
+From: Hideki Yamane 
+Date: Tue, 2 Apr 2019 17:48:18 +0900
+Subject: fix exec error, taken from upstream
+
+---
+ lib/itamae/cli.rb | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/itamae/cli.rb b/lib/itamae/cli.rb
+index 06bba75..a90c344 100644
+--- a/lib/itamae/cli.rb
 b/lib/itamae/cli.rb
+@@ -12,7 +12,7 @@ module Itamae
+ def initialize(*)
+   super
+ 
+-  Itamae.logger.level = ::Logger.const_get(options[:log_level].upcase)
++  Itamae.logger.level = ::Logger.const_get(options[:log_level].upcase) if 
options[:log_level]
+   Itamae.logger.formatter.colored = options[:color]
+ end
+ 
diff -Nru itamae-1.9.10/debian/patches/series 
itamae-1.9.10/debian/patches/series
--- itamae-1.9.10/debian/patches/series 2016-12-01 19:23:31.0 +0900
+++ itamae-1.9.10/debian/patches/series 2019-04-02 17:57:32.0 +0900
@@ -1 +1,2 @@
 0001-Replace-use-of-git-command-in-.gemspec.patch
+0002-fix-exec-error-taken-from-upstream.patch


unblock itamae/1.9.10-2

Bug#926149: AMD: Add nomodeset kernel parameter to avoid black screen

[積丹尼 Dan Jacobson]

> "BH" == Ben Hutchings  writes:

BH> The installer normally uses a dumb framebuffer driver (probably efifb
BH> on this system) that is built into the kernel.  This is too low-
BH> performance for a proper desktop.

OK, the installer could first double check that the framebuffer driver
it intends to write to the installation really will work, by telling the
user:

"5 seconds please, while we test your framebuffer ability."

During which it could launch its proposed framebuffer,
see if /proc/sys/.../{voltage or number of lit pixels, etc.} has
suddenly dropped to zero, indicating a black screen, and then back out
of that choice. Or simply ask the user "in a moment you will be asked if
you saw a black screen".

Anyway, if the installer thinks a certain video mode is so cool that it
sets it up as what will be used when the new system boots, then why
doesn't the installer try a "taste of its own medicine," and use it
right away when running the graphical and non-graphical interactive
installs. I mean if it is so confident that it will work...

Or the kernel itself certainly should have a way to do "OK, for the next
operation, check if it has made the screen (which was not black) now
become suddenly black? If so, back out."

Anyway certainly
https://lists.opensuse.org/opensuse-factory/2011-09/msg00732.html
has it right at least about the *2nd (recovery mode) grub entries*.
They should certainly have nomodeset added!

Bug#926363: Unable to fire virtual keyboard events with X11 backend if keyval not in current group

[Ильяс Гасанов]

Package: libclutter-1.0-0
Version: 1.26.2+dfsg-10
Severity: minor
Tags: fixed-upstream

Currently it is not possible to fire certain keyboard events using
e.g. clutter_virtual_input_device_x11_notify_keyval(), in particular
when keyval argument does not correspond to any keycode in current Xkb
group. Virtual keyboard events are used to implement keybinding
actions for tablet pad buttons configured with GSettings (see the
relocatable schema "org.gnome.desktop.peripherals.tablet.pad-button",
and the meta-input-settings.c file in mutter source code). Basically
it means I cannot assign keybindings such as F13, F14 etc. for the
purpose of application-defined functions, instead of a session-wide
emulation of specific key combinations usable only for one specific
app.

A fix was already implemented upstream in Git commit ffed28c4 by
Andrea Azzarone, and made its way into 3.30.x versions according to
GNOME's upstream mutter Git repository,
https://gitlab.gnome.org/GNOME/mutter.

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

Control: -1 reopen

Hey Andreas.

I'm afraid I have to reopen this.

Today I made a fresh set of extensive checks for gapless playback in
mpv (from Debian sid with the ffmpeg from sid) and also upstream git
master HEAD ffmpeg alone.

The details results can be found here:
https://trac.ffmpeg.org/ticket/7828#comment:2
https://github.com/mpv-player/mpv/issues/2284#issuecomment-479667296

Long story short:
In mpv MP3/Opus play gapless quite fine.
In ffmpeg, it works at least with the version from git (but not with
the one in Debian); reasons seems to be an issue in the ffmpeg(1)
program itself which was recently fixed... while mpv used the libs
already correctly.


>From that I'd have expected that bs1770gain also works now and files
that have been processed by it still play back gaplessly, however it
does not.



1) First pair of test files 
>From the test-files from the two bug reports above I used:
02.split-track01.mp3
02.split-track02.mp3

and

03.split-track01.opus
03.split-track02.opus

each of them in a directory, which I then processed (each dir) with:
bs1770gain dir -t -o outdir

Playing these with:
mpv 02.split-track01.mp3 02.split-track02.mp3
respectively
mpv 03.split-track01.opus 03.split-track02.opus
works without any gap/distortion.


Fine so far, but now...




2) Second pair of test files
I do have another pair of sample file from an audio CD.
Encoded them exactly as described in the ffmpeg/mpv tickets with lame
respectively opusenc.
Processed them as above with bs1770gain (the Debian version from sid,
with the ffmpeg version from sid).

With the (bs1770gain processed) MP3 files, there is a
distortion/corruption at the the intersection, which I can clearly
hear.
However... the (bs1770gain processed) Opus files are fine!!! (wtf?)


It can also be seen in the waveform (see attached images):
For that I decoded the files with lame --decode respectively opusdec
(not with ffmpeg this time), joined each pair together with sox and
displayed them in sonic-visualizer with:


top:
the sox concatenation of the original two WAV sample files

middle:
the joined WAVs decoded from the MP3 respectively Opus 

bottom:
just the WAV of first track from MP3 respectively Opus, serving just as
reference as to where the intersection is




Any idea why the MP3 is still mangled up? It apparently seems to depend
on the input file... so maybe it's just luck, that the Opus worked
here.


Thanks,
Chris.

btw: As for the sample files, I wouldn't want to upload them publicly
since these are from some copyrighted Audio CD,... but I can make them
privately available to some developers if this is desired.

Bug#926361: Mention --width in paragraph

[積丹尼 Dan Jacobson]

Package: procps
Version: 2:3.3.15-2
File: /usr/share/man/man1/ps.1.gz
Severity: minor

   --cols option may be used to exactly determine the width in this case.  The 
w or -w option may be also be
   used to adjust width.

Also mention --width in that sentence.

And mention if --width is the same as --columns and COLUMNS variable.

Bug#926360: Add word "positive"

[積丹尼 Dan Jacobson]

Package: procps
Version: 2:3.3.15-2
Severity: minor

$ ps -e --columns 33 -o pid,start_time,cputimes:0,comm
error: column widths must be unsigned decimal numbers
  ^positive

Bug#926362: No stime entry on man page

[積丹尼 Dan Jacobson]

Package: procps
Version: 2:3.3.15-2
File: /usr/share/man/man1/ps.1.gz
Severity: minor

On the man page it says

  lstart  STARTED   time the command started.  See also bsdstart, 
start, start_time, and stime.

but there is no stime entry.

Bug#916641: marked as done (jaxb: leaves alternatives after purge: /usr/bin/{schemagen,xjc})

[Andreas Beckmann]

Thanks.

Unblock request filed: #926359


Andreas

Bug#925604: unblock: ruby-doorkeeper-openid-connect/1.5.5-1

[Utkarsh Gupta]

Hey,

On Sat, Mar 30, 2019 at 9:41 PM Ivo De Decker  wrote:

> Control: tags -1 moreinfo
>
> Hi,
>
> On Wed, Mar 27, 2019 at 07:11:57PM +0530, Utkarsh Gupta wrote:
> > Please unblock package ruby-doorkeeper-openid-connect.
> >
> > There was a CVE bug (#924747) reported against the package with severity:
> > grave.
> > It was reported on 16th March and was resolved in the latest upload,
> which was
> > on 24th March.
> > Thus, requesting you to please unblock the same and let it be a part of
> Buster,
> > as was going to :)
>
> This upload seems to include a number of changes other than the fix for the
> security issue. This doesn't seem to comply with the freeze policy. Perhaps
> you can clarify the changes. Otherwise, please revert the upload and
> upload a
> targeted fix for this issue.
>

I do understand your point but the there are only minor changes done except
for the bug fixing :(
I was hoping for it to get unblocked (that is why I didn't do a minor
update but just a patch update).
Also, since gitlab is its only reverse dependency, it'll not be a problem
to unblock I guess?
If not possible, I'd perhaps be targetting for buster-backports, but was
wishing to be unblocked to avoid other workarounds.

Thanks,
>
> Ivo
>

Best,
Utkarsh

Bug#926359: unblock: jaxb/2.3.0.1-8

[Andreas Beckmann]

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

Please unblock package jaxb

This update fixes the removal of the alternatives.

unblock jaxb/2.3.0.1-8

Andreas
diff -Nru jaxb-2.3.0.1/debian/changelog jaxb-2.3.0.1/debian/changelog
--- jaxb-2.3.0.1/debian/changelog   2018-12-13 10:37:48.0 +0100
+++ jaxb-2.3.0.1/debian/changelog   2019-04-03 09:23:42.0 +0200
@@ -1,3 +1,10 @@
+jaxb (2.3.0.1-8) unstable; urgency=medium
+
+  * Team upload.
+  * Fixed the removal of the alternatives (Closes: #916641)
+
+ -- Andreas Beckmann   Wed, 03 Apr 2019 09:23:42 +0200
+
 jaxb (2.3.0.1-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru jaxb-2.3.0.1/debian/jaxb.prerm jaxb-2.3.0.1/debian/jaxb.prerm
--- jaxb-2.3.0.1/debian/jaxb.prerm  2018-12-13 00:28:17.0 +0100
+++ jaxb-2.3.0.1/debian/jaxb.prerm  2019-04-03 09:22:51.0 +0200
@@ -3,8 +3,8 @@
 set -e
 
 if [ "$1" = "remove" ] || [ "$1" = "deconfigure" ]; then
-   update-alternatives --remove wsgen
/usr/share/jaxb/bin/schemagen.zip.sh
-   update-alternatives --remove wsimport /usr/share/jaxb/bin/xjc.zip.sh
+   update-alternatives --remove schemagen 
/usr/share/jaxb/bin/schemagen.zip.sh
+   update-alternatives --remove xjc   /usr/share/jaxb/bin/xjc.zip.sh
 fi
 
 #DEBHELPER#

Bug#922810: Maintainer

[Gavin Bauer]

Hi

I've had a good look into your request, and having known sloc in the 
past as being very usefull, I thought why not jump and help.


I've check the process required, would need a sponsor, but that comes in 
a bit later (Just for the actual upload once everything is ready)


I can offer the following process:-

Stage 1) Work on a script which will monitor your source repo on gitlab 
(+- every 24hours), and on change, build master branch and upload to a 
ftp server (My Own). I will provide link later once setup.


Stage 2) Crossbuild for all architectures and make wip available via ftp 
(I can however only test x86-64, i386 and arm64), which have worked so 
far just using golang compiler stuff)
This stage gives everyone envolved a chance to review/test the deb files 
for any errors etc.


Stage 3) Move to autobuild on new Release Tag, I.E. You create a new 
release tag, and the system builds the new release version.

(Pretesting would be done on the latest tag)

Stage 4) Upload to Debian, for final review.

Stage 5) Hand over to Incoming, and wait/bug report for an upload 
sponsor to accept/comment etc.


I am new in the maintainer side, but am willing to setup, and have the 
facilities to setup this build in a mostly automated fashion. I.E. I 
only have to click the final submit button if everything goes to plan.


Full source of the actual script will be available once released.

Regards
Gavin Bauer

Bug#926357: unblock: claws-mail/3.17.3-2

[Ricardo Mones]

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

Please unblock package claws-mail

Just added a patch from upstream to fix a segfault when using gdata
plugin with German locales, caused by an unnecessary %s in a msgstr.

Debdiff attached, thanks in advance!

unblock claws-mail/3.17.3-2

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru claws-mail-3.17.3/debian/changelog claws-mail-3.17.3/debian/changelog
--- claws-mail-3.17.3/debian/changelog  2018-12-29 18:10:15.0 +0100
+++ claws-mail-3.17.3/debian/changelog  2019-04-03 20:11:50.0 +0200
@@ -1,3 +1,10 @@
+claws-mail (3.17.3-2) unstable; urgency=medium
+
+  * debian/patches/90fix_segfault_gdata_german.patch
+  - Add patch fixing segfault in gdata plugin (Closes: #923980)
+
+ -- Ricardo Mones   Wed, 03 Apr 2019 20:11:50 +0200
+
 claws-mail (3.17.3-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru claws-mail-3.17.3/debian/patches/90fix_segfault_gdata_german.patch 
claws-mail-3.17.3/debian/patches/90fix_segfault_gdata_german.patch
--- claws-mail-3.17.3/debian/patches/90fix_segfault_gdata_german.patch  
1970-01-01 01:00:00.0 +0100
+++ claws-mail-3.17.3/debian/patches/90fix_segfault_gdata_german.patch  
2019-04-03 20:11:50.0 +0200
@@ -0,0 +1,17 @@
+Description: Fix segfault using gdata plugin in German locales
+Origin: 
https://git.claws-mail.org/?p=claws.git;a=commit;h=0ffa910327b3476aafec74013d69af98dd9fb5e2
+Bug-Debian: https://bugs.debian.org/923980
+
+diff --git a/po/de.po b/po/de.po
+index 979095871..7332704c9 100644
+--- a/po/de.po
 b/po/de.po
+@@ -10502,7 +10502,7 @@ msgstr "GData-Plugin: Fehler beim Erneuern der 
Autorisierung: %s\n"
+ 
+ #: src/plugins/gdata/cm_gdata_contacts.c:535
+ msgid "GData plugin: Authorization refresh successful\n"
+-msgstr "GData-Plugin: Erneuern der Autorisierung erfolgreich: %s\n"
++msgstr "GData-Plugin: Erneuern der Autorisierung erfolgreich\n"
+ 
+ #: src/plugins/gdata/cm_gdata_contacts.c:595
+ #, c-format
diff -Nru claws-mail-3.17.3/debian/patches/series 
claws-mail-3.17.3/debian/patches/series
--- claws-mail-3.17.3/debian/patches/series 2018-12-29 18:10:15.0 
+0100
+++ claws-mail-3.17.3/debian/patches/series 2019-04-03 20:11:50.0 
+0200
@@ -1,2 +1,3 @@
 11mark_trashed_as_read.patch
 12fix_manpage_header.patch
+90fix_segfault_gdata_german.patch

Bug#925208: python-smoke-zephyr: FTBFS randomly (tests hang the autobuilder)

[Samuel Henrique]

Hello Santiago,

Thanks for reporting this, upstream fixed that on 1.4.1, can you please
confirm that it's fixed on your machines with 1.4.1-1 (unstable), please?

Regards,

-- 
Samuel Henrique 

Bug#926315: [Pkg-openssl-devel] Bug#926315: Bug#926315: Bug#926315: openssl: wget https://google.com fails in d-i

[Kurt Roeckx]

On Thu, Apr 04, 2019 at 12:48:22AM +0200, Cyril Brulebois wrote:
> Hi,
> 
> And thanks for digging…
> 
> Kurt Roeckx  (2019-04-04):
> > On Thu, Apr 04, 2019 at 12:07:37AM +0200, Kurt Roeckx wrote:
> > > On Wed, Apr 03, 2019 at 11:57:12PM +0200, Kurt Roeckx wrote:
> > > > On Wed, Apr 03, 2019 at 11:23:19PM +0200, Cyril Brulebois wrote:
> > > > > 1726  write(2, "Disabling SSL due to encountered errors.\n", 41) 
> > > > > = 41
> > > > 
> > > > wget in buster actually seems to be linked to gnutls, and trying
> > > > other applications just seem to work without config file.
> > > 
> > > So I can reproduce this with the tag OpenSSL_1_1_1b, it's fixed in
> > > the current OpenSSL_1_1_1-stable branch ...
> > 
> > So the commit that fixes it is:
> > commit 9933d4a06bd0a0b5b757f072944e8cd54d4bddd3
> > Author: Richard Levitte 
> > Date:   Wed Mar 20 10:18:13 2019 +0100
> > 
> > OPENSSL_config(): restore error agnosticism
> > 
> > Great effort has been made to make initialization more configurable.
> > However, the behavior of OPENSSL_config() was lost in the process,
> > having it suddenly generate errors it didn't previously, which is not
> > how it's documented to behave.
> > 
> > A simple setting of default flags fixes this problem.
> > 
> > Fixes #8528
> > 
> > Reviewed-by: Matt Caswell 
> > (Merged from https://github.com/openssl/openssl/pull/8533)
> > 
> > (cherry picked from commit 905c9a72a708701597891527b422c7f374125c52)
> > 
> > The one that broke it was the one I pointed out earlier.
> 
> Would it be helpful if I were to rebuild openssl with that patch and double
> check what happens with its updated udebs?

I don't think that will be needed. I hope to get an other
important bugfix soon, and we can do an upload then.


Kurt

Bug#926315: [Pkg-openssl-devel] Bug#926315: Bug#926315: Bug#926315: openssl: wget https://google.com fails in d-i

[Cyril Brulebois]

Hi,

And thanks for digging…

Kurt Roeckx  (2019-04-04):
> On Thu, Apr 04, 2019 at 12:07:37AM +0200, Kurt Roeckx wrote:
> > On Wed, Apr 03, 2019 at 11:57:12PM +0200, Kurt Roeckx wrote:
> > > On Wed, Apr 03, 2019 at 11:23:19PM +0200, Cyril Brulebois wrote:
> > > > 1726  write(2, "Disabling SSL due to encountered errors.\n", 41) = 
> > > > 41
> > > 
> > > wget in buster actually seems to be linked to gnutls, and trying
> > > other applications just seem to work without config file.
> > 
> > So I can reproduce this with the tag OpenSSL_1_1_1b, it's fixed in
> > the current OpenSSL_1_1_1-stable branch ...
> 
> So the commit that fixes it is:
> commit 9933d4a06bd0a0b5b757f072944e8cd54d4bddd3
> Author: Richard Levitte 
> Date:   Wed Mar 20 10:18:13 2019 +0100
> 
> OPENSSL_config(): restore error agnosticism
> 
> Great effort has been made to make initialization more configurable.
> However, the behavior of OPENSSL_config() was lost in the process,
> having it suddenly generate errors it didn't previously, which is not
> how it's documented to behave.
> 
> A simple setting of default flags fixes this problem.
> 
> Fixes #8528
> 
> Reviewed-by: Matt Caswell 
> (Merged from https://github.com/openssl/openssl/pull/8533)
> 
> (cherry picked from commit 905c9a72a708701597891527b422c7f374125c52)
> 
> The one that broke it was the one I pointed out earlier.

Would it be helpful if I were to rebuild openssl with that patch and double
check what happens with its updated udebs?


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


signature.asc
Description: PGP signature

Bug#926355: O: aes2501-wy -- userspace software for usb aes2501 fingerprint scanner

[Tobias Frost]

Package: wnpp

All maintainer of aes2501-wy are not active anymore.  Therefore, I orphan this 
package now.

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

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: aes2501-wy
Binary: aes2501-wy
Version: 0.1-5
Maintainer: FingerForce Team 
Uploaders: Luca Capello , Miguel Gea Milvaques 
Build-Depends: debhelper (>= 5), docbook-to-man
Architecture: any
Standards-Version: 3.7.3
Format: 1.0
Files:
 5c8b133eb7ea8b4bdabeba7f63c5d4f1 733 aes2501-wy_0.1-5.dsc
 92db325eadd7be72257518c4deccbe2e 11617 aes2501-wy_0.1.orig.tar.gz
 7c21f0d2d91ceca252af64092745f86d 5144 aes2501-wy_0.1-5.diff.gz
Checksums-Sha256:
 299c32efdcda566024d90efaee2f35fcde0af92ae966ab52ece69b67a4ebd106 733 
aes2501-wy_0.1-5.dsc
 dc7bf00523538b15397b75f1b5cc982c18bfc887a2062dd167a7c1d5c5c635fd 5144 
aes2501-wy_0.1-5.diff.gz
 a8179514573fc85c3582eec3001b29cb58fc325063c0dc6201ed7c52b8b1dc98 11617 
aes2501-wy_0.1.orig.tar.gz
Homepage: http://gkall.hobby.nl/authentec.html
Directory: pool/main/a/aes2501-wy
Priority: source
Section: graphics

Package: aes2501-wy
Source: aes2501-wy (0.1-5)
Version: 0.1-5+b2
Installed-Size: 39
Maintainer: FingerForce Team 
Architecture: amd64
Depends: libc6 (>= 2.2.5)
Recommends: imagemagick
Description-en: userspace software for usb aes2501 fingerprint scanner
 Command line scanning sofware for AES2501 usb fingerprint reader. The ouput
 are grayscale pnm files with quite good quality.
 .
 The AES 2501 fingerprint scanner vendor is Authentec and this sensor can be
 found in:
  * Medion MD85264 USB sensor
  * HP nx6125 notebook
  * HP Compaq 6710b
  * HP Compaq 6510b
  * HP Compaq nx6320
  * HP nx6325
  * HP Compaq nc8430
  * HP Compaq nc6320
  * Compaq HEL80/81 notebook
  * Fujitsu-Siemens P7120 notebook.
  * LG P1 PRO Express Dual notebook.
  * LG S1 Pro Express Dual notebook
  * Lenovo 3000 N100
  * Lenovo 3000 n200 notebook
  * Toshiba Libretto U100
  * Toshiba Portégé R200 notebook
  * Targa Traveller 1577 X2
Description-md5: adf4b5ff79942426c50ed9150701b236
Homepage: http://gkall.hobby.nl/authentec.html
Tag: admin::hardware, hardware::usb, implemented-in::c,
 interface::commandline, role::program, scope::utility,
 security::cryptography, use::driver, use::scanning
Section: graphics
Priority: optional
Filename: pool/main/a/aes2501-wy/aes2501-wy_0.1-5+b2_amd64.deb
Size: 13038
MD5sum: c66b8246ffa37618f78324a09dc18e33
SHA256: 9d160f64ed81c89c4a347415e661f9f83e839c58cb7def8e6c83aaf6f989f96a



signature.asc
Description: PGP signature

Bug#926356: Updating the libsigsegv Uploaders list

[Tobias Frost]

Source: libsigsegv
Version: 2.12-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Luca Capello  has retired, so can't work on
the libsigsegv package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#926315: [Pkg-openssl-devel] Bug#926315: Bug#926315: Bug#926315: openssl: wget https://google.com fails in d-i

[Kurt Roeckx]

On Thu, Apr 04, 2019 at 12:07:37AM +0200, Kurt Roeckx wrote:
> On Wed, Apr 03, 2019 at 11:57:12PM +0200, Kurt Roeckx wrote:
> > On Wed, Apr 03, 2019 at 11:23:19PM +0200, Cyril Brulebois wrote:
> > > 1726  write(2, "Disabling SSL due to encountered errors.\n", 41) = 41
> > 
> > wget in buster actually seems to be linked to gnutls, and trying
> > other applications just seem to work without config file.
> 
> So I can reproduce this with the tag OpenSSL_1_1_1b, it's fixed in
> the current OpenSSL_1_1_1-stable branch ...

So the commit that fixes it is:
commit 9933d4a06bd0a0b5b757f072944e8cd54d4bddd3
Author: Richard Levitte 
Date:   Wed Mar 20 10:18:13 2019 +0100

OPENSSL_config(): restore error agnosticism

Great effort has been made to make initialization more configurable.
However, the behavior of OPENSSL_config() was lost in the process,
having it suddenly generate errors it didn't previously, which is not
how it's documented to behave.

A simple setting of default flags fixes this problem.

Fixes #8528

Reviewed-by: Matt Caswell 
(Merged from https://github.com/openssl/openssl/pull/8533)

(cherry picked from commit 905c9a72a708701597891527b422c7f374125c52)

The one that broke it was the one I pointed out earlier.


Kurt

Bug#926261: closed by Ben Hutchings (Re: Bug#926261: linux-image-4.19.0-4-amd64: fan continiously spinning above 6900 RPM after resume on lenovo carbon x1 thinkpad with isa adap

[Ben Hutchings]

On Wed, 2019-04-03 at 20:08 +, Karol Szkudlarek wrote:
> > It has been closed by Ben Hutchings b...@decadent.org.uk.
> > 
> > Their explanation is attached below along with your original
> > report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Ben Hutchings 
> > b...@decadent.org.uk by
> > 
> > replying to this email.
> > 
> > 
> > -
> > 
> > Linux doesn't control the fan, that's done by the system firmware.
> > 
> > Ben.
> 
> System firmware is a part of Linux.
[...]

The system firmware (sometimes called the "BIOS") is what came with the
hardware.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.




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

Bug#926354: postfixadmin: Missing symbolic link to config.local.php results in warning message during setup

[Michael Krieger]

Package: postfixadmin
Version: 3.2.1-2
Severity: minor

When using /postfixadmin/setup.php, a warning is provided as follows:
  Warning: config.local.php - NOT FOUND
  It's Recommended to store your own settings in config.local.php instead of 
editing config.inc.php
  Create the file, and edit as appropriate (e.g. select database type etc)

To fix, 
  ln -s /etc/postfixadmin/config.local.php 
/usr/share/postfixadmin/config.local.php
is appropriate (the same way config.inc.php is linked) on installation



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

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

Versions of packages postfixadmin depends on:
ii  apache2 [httpd] 2.4.38-2
ii  dbconfig-common 2.0.11
ii  debconf 1.5.71
ii  default-mysql-client1.0.5
ii  php 2:7.3+69
ii  php-fpm 2:7.3+69
ii  php-imap2:7.3+69
ii  php-mbstring2:7.3+69
ii  php-mysql   2:7.3+69
ii  php7.3 [php]7.3.3-1
ii  php7.3-fpm [php-fpm]7.3.3-1
ii  php7.3-imap [php-imap]  7.3.3-1
ii  php7.3-mbstring [php-mbstring]  7.3.3-1
ii  php7.3-mysql [php-mysqlnd]  7.3.3-1
ii  wwwconfig-common0.3.0

Versions of packages postfixadmin recommends:
ii  dovecot-core1:2.3.4.1-3
ii  mariadb-server  1:10.3.13-1
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.13-1
ii  php7.3-cli [php-cli]7.3.3-1
ii  postfix-mysql   3.4.4-1
pn  zendframework   

postfixadmin suggests no packages.

-- Configuration Files:
/etc/apache2/conf-available/postfixadmin.conf changed [not included]

-- debconf information excluded

Bug#926315: [Pkg-openssl-devel] Bug#926315: Bug#926315: openssl: wget https://google.com fails in d-i

[Kurt Roeckx]

On Wed, Apr 03, 2019 at 11:57:12PM +0200, Kurt Roeckx wrote:
> On Wed, Apr 03, 2019 at 11:23:19PM +0200, Cyril Brulebois wrote:
> > 1726  write(2, "Disabling SSL due to encountered errors.\n", 41) = 41
> 
> wget in buster actually seems to be linked to gnutls, and trying
> other applications just seem to work without config file.

So I can reproduce this with the tag OpenSSL_1_1_1b, it's fixed in
the current OpenSSL_1_1_1-stable branch ...


Kurt

Bug#857791: postfixadmin & dbconfig-common: mysql/mysqli mismatch

[Michael Krieger]

Package: postfixadmin
Version: 3.2.1-2
Followup-For: Bug #857791

This bug remains in the current buster release.
As PHP 5.x and MySQL (not MySQLi) is fully depreciated there is no need for 
even the patch
in question. Very simply, this should just have mysqli as the database engine 
and nothing more.

1. It may be doable with just dbconfig-common's scripts in this package
2. otherwise a simple sed
3. or including this at the bottom of the file: if ($dbtype=='mysql') 
$dbtype='mysqli';


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

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

Versions of packages postfixadmin depends on:
ii  apache2 [httpd] 2.4.38-2
ii  dbconfig-common 2.0.11
ii  debconf 1.5.71
ii  default-mysql-client1.0.5
ii  php 2:7.3+69
ii  php-fpm 2:7.3+69
ii  php-imap2:7.3+69
ii  php-mbstring2:7.3+69
ii  php-mysql   2:7.3+69
ii  php7.3 [php]7.3.3-1
ii  php7.3-fpm [php-fpm]7.3.3-1
ii  php7.3-imap [php-imap]  7.3.3-1
ii  php7.3-mbstring [php-mbstring]  7.3.3-1
ii  php7.3-mysql [php-mysqlnd]  7.3.3-1
ii  wwwconfig-common0.3.0

Versions of packages postfixadmin recommends:
ii  dovecot-core1:2.3.4.1-3
ii  mariadb-server  1:10.3.13-1
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.13-1
ii  php7.3-cli [php-cli]7.3.3-1
ii  postfix-mysql   3.4.4-1
pn  zendframework   

postfixadmin suggests no packages.

-- Configuration Files:
/etc/apache2/conf-available/postfixadmin.conf changed [not included]

-- debconf information excluded

Bug#926315: [Pkg-openssl-devel] Bug#926315: openssl: wget https://google.com fails in d-i

[Kurt Roeckx]

On Wed, Apr 03, 2019 at 11:23:19PM +0200, Cyril Brulebois wrote:
> 1726  write(2, "Disabling SSL due to encountered errors.\n", 41) = 41

Looking at the source, about the only reason I can see to get that
is that SSL_CTX_new() failed.

If I understand correctly, it's actually a change in libcrypto
between 1.1.1a and 1.1.1b?

The most likely commit to change behaviour seems to be:
commit 25eb9299cec4404a4cdf3167056bd147af2582f3
Author: Viktor Dukhovni 
Date:   Tue Jan 1 02:53:24 2019 -0500

More configurable crypto and ssl library initialization

1.  In addition to overriding the default application name,
one can now also override the configuration file name
and flags passed to CONF_modules_load_file().

2.  By default we still keep going when configuration file
processing fails.  But, applications that want to be
strict about initialization errors can now make explicit
flag choices via non-null OPENSSL_INIT_SETTINGS that omit
the CONF_MFLAGS_IGNORE_RETURN_CODES flag (which had so far
been both undocumented and unused).

3.  In OPENSSL_init_ssl() do not request OPENSSL_INIT_LOAD_CONFIG
if the options already include OPENSSL_INIT_NO_LOAD_CONFIG.

4.  Don't set up atexit() handlers when called with opts equal to
OPENSSL_INIT_BASE_ONLY (this flag should only be used alone).

Reviewed-by: Bernd Edlinger 
Reviewed-by: Matt Caswell 
(Merged from https://github.com/openssl/openssl/pull/7969)

But the commit message at least indicates that it should just continue.

wget in buster actually seems to be linked to gnutls, and trying
other applications just seem to work without config file.


Kurt

Bug#926353: python3-pyocr: unknown Tesseract cmdline argument

[IOhannes m zmoelnig]

Package: python3-pyocr
Version: 0.3.0-1
Severity: normal

Dear Maintainer,

experimenting a bit with OCR, i stumbled upon pyocr.
Unfortunately, I cannot seem to make it work (at least with the tesseract
backend), as it seems to require a different tesseract version (that uses
different cmdline arguments):

~~~
$ python3
Python 3.7.3 (default, Mar 26 2019, 07:25:18) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyocr
>>> import pyocr.builders
>>> from PIL import Image
>>> captcha=Image.open("captcha.png")
>>> tools = pyocr.get_available_tools()
>>> tools
[]
>>> tool = tools[0]
>>> txt = tool.image_to_string(captcha, builder=pyocr.builders.TextBuilder())
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pyocr/tesseract.py", line 291, in 
image_to_string
raise TesseractError(status, errors)
pyocr.tesseract.TesseractError: (1, b"Error, unknown command line argument 
'-psm'\n")
>>>
~~~

The Cuneiform backend works nicely.

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

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

Versions of packages python3-pyocr depends on:
ii  python3  3.7.3-1
ii  python3-pil  5.4.1-1

Versions of packages python3-pyocr recommends:
ii  cuneiform  1.1.0+dfsg-7
ii  tesseract-ocr  4.0.0-2

python3-pyocr suggests no packages.

-- no debconf information

Bug#926351: python3-tesserocr: segfaults on import

[IOhannes m zmoelnig]

Package: python3-tesserocr
Version: 2.4.0-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

i'm experimenting a bit with OCR and tried out python3-tesserocr.
Unfortunately, it appears to be completely unusable:

~~~
$ python3
Python 3.7.3 (default, Mar 26 2019, 07:25:18) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tesserocr
!strcmp(locale, "C"):Error:Assert failed:in file baseapi.cpp, line 209
Segmentation fault (core dumped)
$
~~~

my locale setting uses 'C.UTF-8', but when i tried to set other values i get the
same result:

~~~
$ LANG=de python3
Python 3.7.3 (default, Mar 26 2019, 07:25:18) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tesserocr
!strcmp(locale, "C"):Error:Assert failed:in file baseapi.cpp, line 209
Segmentation fault (core dumped)
$
~~~

Since I see no way to use this package when even importing fails with a
segfault, i use severity 'grave'.
Hopefully this package will be fixed.

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

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

Versions of packages python3-tesserocr depends on:
ii  libc6  2.28-8
ii  libgcc11:8.3.0-4
ii  liblept5   1.78.0-1
ii  libstdc++6 8.3.0-4
ii  libtesseract4  4.0.0-2
ii  python33.7.3-1

python3-tesserocr recommends no packages.

python3-tesserocr suggests no packages.

-- no debconf information

Bug#926352: curl.1: Some lines begin with a ', causing them to not appear in the output

[Bjarni Ingi Gislason]

Package: curl
Version: 7.64.0-2
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?

Warnings from "nroff -ww ...", used in "man curl 2> ..." with
MANOPT=--warnings=w
MAN_KEEP_STDERR=yes

troff: :531: warning: macro 'foobar'' not defined
troff: :1147: warning: macro '~/.ssh/id_rsa',' not defined
troff: :1618: warning: macro 'all',' not defined


  The patch:

>From 655add8444a7e4ddf5bca8b66f5ab7a55252e8ea Mon Sep 17 00:00:00 2001
From: Bjarni Ingi Gislason 
Date: Tue, 2 Apr 2019 21:55:11 +
Subject: [PATCH] curl.1: Missing lines caused by undefined macros

  Some lines begin with a "'" (apostrophe, single quote), which is then
interpreted as a control character in *roff.

  Such lines are interpreted as being a call to a macro, and if
undefined, the lines are removed from the output.

Signed-off-by: Bjarni Ingi Gislason 
---
 docs/cmdline-opts/data.d  | 2 +-
 docs/cmdline-opts/key.d   | 2 +-
 docs/cmdline-opts/proto.d | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/cmdline-opts/data.d b/docs/cmdline-opts/data.d
index 7d499665e..d18312aaa 100644
--- a/docs/cmdline-opts/data.d
+++ b/docs/cmdline-opts/data.d
@@ -24,7 +24,7 @@ chunk that looks like \&'name=daniel=lousy'.
 If you start the data with the letter @, the rest should be a file name to
 read the data from, or - if you want curl to read the data from
 stdin. Multiple files can also be specified. Posting data from a file named
-'foobar' would thus be done with --data @foobar. When --data is told to read
+\&'foobar' would thus be done with --data @foobar. When --data is told to read
 from a file like that, carriage returns and newlines will be stripped out. If
 you don't want the @ character to have a special interpretation use --data-raw
 instead.
diff --git a/docs/cmdline-opts/key.d b/docs/cmdline-opts/key.d
index 4877b4238..855e2f7b6 100644
--- a/docs/cmdline-opts/key.d
+++ b/docs/cmdline-opts/key.d
@@ -5,7 +5,7 @@ Help: Private key file name
 ---
 Private key file name. Allows you to provide your private key in this separate
 file. For SSH, if not specified, curl tries the following candidates in order:
-'~/.ssh/id_rsa', '~/.ssh/id_dsa', './id_rsa', './id_dsa'.
+\&'~/.ssh/id_rsa', '~/.ssh/id_dsa', './id_rsa', './id_dsa'.
 
 If curl is built against OpenSSL library, and the engine pkcs11 is available,
 then a PKCS#11 URI (RFC 7512) can be used to specify a private key located in a
diff --git a/docs/cmdline-opts/proto.d b/docs/cmdline-opts/proto.d
index 1513fdc05..e1ece1788 100644
--- a/docs/cmdline-opts/proto.d
+++ b/docs/cmdline-opts/proto.d
@@ -6,7 +6,7 @@ Added: 7.20.2
 ---
 Tells curl to limit what protocols it may use in the transfer. Protocols are
 evaluated left to right, are comma separated, and are each a protocol name or
-'all', optionally prefixed by zero or more modifiers. Available modifiers are:
+\&'all', optionally prefixed by zero or more modifiers. Available modifiers 
are:
 .RS
 .TP 3
 .B +
-- 
2.20.1


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

Kernel: Linux 4.19.28-2 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages curl depends on:
ii  libc6 2.28-8
ii  libcurl4  7.64.0-2
ii  zlib1g1:1.2.11.dfsg-1

curl recommends no packages.

curl suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason

Bug#924888: why bsd.license?

[Boyuan Yang]

On Wed, 3 Apr 2019 13:34:16 +0100 MJ Ray  wrote:
> On Mon, 1 Apr 2019 12:26:13 +0200
> Laura Arjona Reina  wrote:
> 
> > BSD, and
> > 
> > I have checked that the content of the bsd.license file matches the
> > BSD-3-Clause license at opensource.org, so I've updated the links to
> > 
> > https://opensource.org/licenses/BSD-3-Clause
> > 
> > and removed the file.
> 
> Could you add a redirect instead of breaking links from other
> documentation, please?  In line with Cool URIs Don't Change,
> https://www.w3.org/Provider/Style/URI.html
> 
> https://manpages.debian.org/testing/pal/vcard2pal.1.en.html could
> probably be fixed by us, as could the links from our wiki, but it looks
> like there are also links to it from code on github.

I've grep-ed throughout the entire webwml repository and replaced all
occurrences of misc/bsd.license with the link to opensource.org.

Besides, it's worthwhile to search through the entire Debian source code and
remove them to our best efforts:

https://codesearch.debian.net/search?q=misc%2Fbsd.license=1

--
Regards,
Boyuan Yang


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

Bug#926350: CAS middleware incompatible with Django >= 1.10

[Bill Blough]

Package: python3-django-casclient
Version: 1.2.0-2
Severity: grave
Tags: upstream patch

Due to middleware API changes in Django 1.10, django-cas-client 1.2 no
longer works (fails with an unhandled exception).  This currently
effects stable, testing, and unstable (oldstable used django 1.7).  So
unless a user upgraded from jessie but did *not* upgrade django, this
package is broken. (hence grave severity)

There is a fix upstream [1] that was applied as part of the 1.3.0
release.  I have tested the patch locally against 1.2.0 and it seems to
correct the issue without any side effects.  However I have not tested
it with versions of django < 1.10.

[1] 
https://patch-diff.githubusercontent.com/raw/kstateome/django-cas/pull/64.diff


I'd be willing to NMU the fix and file the unblock request if that is helpful.


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

Kernel: Linux 4.9.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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-django-casclient depends on:
ii  python3  3.5.3-1

python3-django-casclient recommends no packages.

Versions of packages python3-django-casclient suggests:
pn  python-django-cas-doc  

-- no debconf information

Bug#926315: [Pkg-openssl-devel] Bug#926315: openssl: wget https://google.com fails in d-i

[Cyril Brulebois]

Hi again,

Cyril Brulebois  (2019-04-03):
> I'm pretty sure we had successes with wget/https within d-i not so long
> ago (i.e. during the last BSP at Mozilla's, past week), and there were no
> changes on the openssl side in the meanwhile.

Or maybe my explicit testing didn't happen at the right time.

> I'll be double checking using the month worth of dailies we have, and
> report back with my findings.

Anyway: downgrading libssl1.1-udeb to the previous version (1.1.1a-1) isn't
sufficient; I've had to downgrade its companion library, libcrypto1.1-udeb.

I've included strace-udeb in the image, and extracted a trace. It seems the
mere existence (or lack thereof) of the configuration file is what triggers
the early exit. Running “touch” on it is sufficient to get a successful
connection/download, with the current version of both libraries (1.1.1b-1).


1726  execve("/usr/bin/wget", ["wget", "https://google.fr;], ["USER=root", 
"HOME=/", "TERM=linux", "BOOT_IMAGE=linux", 
"PATH=/sbin:/usr/sbin:/bin:/usr/bin", "vga=788", "SHELL=/bin/sh", 
"initrd=initrd.gz", "PWD=/"]) = 0
1726  brk(NULL) = 0x56007142f000
1726  access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or 
directory)
1726  openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
1726  openat(AT_FDCWD, 
"/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
1726  stat("/lib/x86_64-linux-gnu/tls/x86_64/x86_64", 0x7ffd7454c960) = -1 
ENOENT (No such file or directory)
1726  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1726  stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7ffd7454c960) = -1 ENOENT 
(No such file or directory)
1726  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1726  stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7ffd7454c960) = -1 ENOENT 
(No such file or directory)
1726  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1726  stat("/lib/x86_64-linux-gnu/tls", 0x7ffd7454c960) = -1 ENOENT (No 
such file or directory)
1726  openat(AT_FDCWD, 
"/lib/x86_64-linux-gnu/x86_64/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
1726  stat("/lib/x86_64-linux-gnu/x86_64/x86_64", 0x7ffd7454c960) = -1 
ENOENT (No such file or directory)
1726  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/x86_64/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1726  stat("/lib/x86_64-linux-gnu/x86_64", 0x7ffd7454c960) = -1 ENOENT (No 
such file or directory)
1726  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/x86_64/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1726  stat("/lib/x86_64-linux-gnu/x86_64", 0x7ffd7454c960) = -1 ENOENT (No 
such file or directory)
1726  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1726  stat("/lib/x86_64-linux-gnu", {st_dev=makedev(0, 0x2), st_ino=9367, 
st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, 
st_blocks=0, st_size=160, st_atime=1554325535 /* 2019-04-03T21:05:35+ */, 
st_atime_nsec=0, st_mtime=1554325535 /* 2019-04-03T21:05:35+ */, 
st_mtime_nsec=0, st_ctime=1554325844 /* 2019-04-03T21:10:44.514891234+ */, 
st_ctime_nsec=514891234}) = 0
1726  openat(AT_FDCWD, 
"/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1726  stat("/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64", 0x7ffd7454c960) = 
-1 ENOENT (No such file or directory)
1726  openat(AT_FDCWD, 
"/usr/lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
1726  stat("/usr/lib/x86_64-linux-gnu/tls/x86_64", 0x7ffd7454c960) = -1 
ENOENT (No such file or directory)
1726  openat(AT_FDCWD, 
"/usr/lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
1726  stat("/usr/lib/x86_64-linux-gnu/tls/x86_64", 0x7ffd7454c960) = -1 
ENOENT (No such file or directory)
1726  openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/tls/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1726  stat("/usr/lib/x86_64-linux-gnu/tls", 0x7ffd7454c960) = -1 ENOENT (No 
such file or directory)
1726  openat(AT_FDCWD, 
"/usr/lib/x86_64-linux-gnu/x86_64/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
1726  stat("/usr/lib/x86_64-linux-gnu/x86_64/x86_64", 0x7ffd7454c960) = -1 
ENOENT (No such file or directory)
1726  openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/x86_64/libpcre2-8.so.0", 

Bug#926287: barbican: FTBFS: TypeError: set_defaults() got an unexpected keyword argument 'vault_approle_role_id'

[Thomas Goirand]

On 4/3/19 7:10 PM, Andreas Beckmann wrote:
> On 2019-04-03 17:27, Thomas Goirand wrote:
>> Weird, I couldn't reproduce. Could it be my setup with
>> --build-dep-resolver=aspcud?
> 
> Likely. I'd guess my build pulled a package from sid due to
> insufficiently versioned B-D.
> 
> Andreas

Hi Andreas,

When I look into my build log, I can see that it took python3-castellan
1.2.2-1, while yours took 0.19.0-1. So I replaced aspcud by aptitude,
and then I saw the same issue you reported. Lesson learned: I'll use
aptitude from now on, as it looks like it does a better job at taking
the right (expected) dependencies.

After bumping castellan to 1.2.2, built succeeds. Uploading and filing a
bug upstream...

Thanks for all of your valuable bug reports,
Cheers,

Thomas Goirand (zigo)

Bug#926349: RFS: streamlink/1.0.0+dfsg-1~bpo9+1

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors and backports developers,

I am looking for a sponsor for my package "streamlink" into Debian
stretch-backports repository.

 * Package name: streamlink
   Version : 1.0.0+dfsg-1~bpo9+1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  livestreamer - transitional package - streamlink
  python3-streamlink - Python module for extracting video streams at
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.0.0+dfsg-1~bpo9+1.dsc

More information about streamlink can be obtained from
https://streamlink.github.io/

Changes since the last backport upload (0.14.2+dfsg-1~bpo9+1):
streamlink (1.0.0+dfsg-1~bpo9+1) stretch-backports; urgency=medium

  * Rebuild for stretch-backports.

 -- Alexis Murzeau   Tue, 02 Apr 2019 22:22:49 +0200

streamlink (1.0.0+dfsg-1) unstable; urgency=medium

  * docs: mark Multi-Arch: foreign
  * Update d/copyright years to 2019
  * Bump standard version to 4.3.0, no change required
  * New upstream version 1.0.0+dfsg
  * Update patch remove_new_version_check
  * Update d/README.source to use gbp pq

 -- Alexis Murzeau   Thu, 31 Jan 2019 20:09:50 +0100


Differences from testing package (1.0.0+dfsg-1):
  * pybuild test: implement d/pybuild.testfiles in d/rules
  * Use debhelper 10 as 11 is not available.
  * pycountry: add patch to support stable provided version (1.8)
  * d/control: require pycountry <= 1.15
  * pybuild test: implement d/pybuild.testfiles in d/rules (pybuild in
stable does not support that file)


Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F




signature.asc
Description: OpenPGP digital signature

Bug#926231: mariadb-server-10.3: dpkg configure error - upgrade from mysql

[Graham Cobb]

Package: mariadb-server-10.3
Version: 1:10.3.13-2
Followup-For: Bug #926231

I'm not sure what the "MariaDB error log" is but I have found the following 
entries in syslog:

Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: Installation of 
system tables failed!  Examine the logs in
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: /var/lib/mysql for 
more information.
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: The problem could 
be conflicting information in an external
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: my.cnf files. You 
can ignore these by doing:
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: shell> 
/usr/bin/mysql_install_db --defaults-file=~/.my.cnf
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: You can also try 
to start the mysqld daemon with:
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: shell> 
/usr/sbin/mysqld --skip-grant-tables --general-log &
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: and use the 
command line tool /usr/bin/mysql
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: to connect to the 
mysql database and look at the grant tables:
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: shell> 
/usr/bin/mysql -u root mysql
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: mysql> show 
tables;
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: Try 'mysqld 
--help' if you have problems with paths.  Using
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: --general-log 
gives you a log in /var/lib/mysql that may be helpful.
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: The latest 
information about mysql_install_db is available at
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: You can find the 
latest source at https://downloads.mariadb.org and
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: the maria-discuss 
email list at https://launchpad.net/~maria-discuss
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: Please check all 
of the above before submitting a bug report
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: at 
http://mariadb.org/jira
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: 
Apr  3 20:31:00 novatech mariadb-server-10.3.postinst[8489]: 2019-04-03 
20:31:00 0 [Note] /usr/sbin/mysqld (mysqld 10.3.13-MariaDB-2) starting as p

Reading those entries, I tried the following:

1) Looked for logs in /var/lib/mysql. I couldn't find anything that looked like 
an error log.

2) I tried starting the mysqld daemon but it exited after a couple of seconds.
It did write a log file in /var/lib/mysql containing:

/usr/sbin/mysqld, Version: 10.3.13-MariaDB-2-log (Debian buildd-unstable). 
started with:
Tcp port: 0  Unix socket: /run/mysqld/mysqld.sock
TimeId Command  Argument

3) I searched for my.cnf files and found only:
/etc/mysql/my.cnf.fallback
/etc/mysql/my.cnf
/etc/alternatives/my.cnf (softlink to /etc/mysql/mariadb.cnf)

4) I notice that /etc/alternatives/my.cnf imports files from /etc/mysql/conf.d/ 
and /etc/mysql/mariadb.conf.d/

Those directories contain...

/etc/mysql/conf.d/
  mysql.cnf  mysqld_safe_syslog.cnf  mysqldump.cnf

/etc/mysql/mariadb.conf.d/
  50-client.cnf  50-mysql-clients.cnf  50-mysqld_safe.cnf  50-server.cnf


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

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

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-1
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-8
ii  libdbi-perl   1.642-1+b1
ii  libgnutls30   3.6.6-2
ii  

Bug#922259: python-libnacl: FTBFS (ValueError: byte must be in range(0, 256))

[Santiago Vila]

> ==
> ERROR: test_verify32 (unit.test_verify.TestVerify)
> --
> Traceback (most recent call last):
>   File 
> "/<>/.pybuild/cpython3_3.7_libnacl/build/tests/unit/test_verify.py",
>  line 30, in test_verify32
> v32x[libnacl.randombytes_random() & 31] += 1
> ValueError: byte must be in range(0, 256)

Hi. This is still happening (randomly) on reproducible-builds.

I could offer ssh access to a machine where this randomness is
reproducible, but I believe the randomness is intrisic to the
(wrongly designed) test and maybe it happens on any machine
as far as you try enough times.

Can you execute test_verify32 in a loop and report if it fails
randomly or not for you? (Or tell me the way to do it).

Thanks.

Bug#926348: ruby-devise: CVE-2019-5421

[Salvatore Bonaccorso]

Source: ruby-devise
Version: 4.5.0-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/plataformatec/devise/issues/4981

Hi,

The following vulnerability was published for ruby-devise.

CVE-2019-5421[0]:
| Plataformatec Devise version 4.5.0 and earlier, using the lockable
| module contains a CWE-367 vulnerability in The
| `Devise::Models::Lockable` class, more specifically at the
| `#increment_failed_attempts` method. File location:
| lib/devise/models/lockable.rb that can result in Multiple concurrent
| requests can prevent an attacker from being blocked on brute force
| attacks. This attack appear to be exploitable via Network connectivity
| - brute force attacks. This vulnerability appears to have been fixed
| in 4.6.0 and later.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-5421
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5421
[1] https://github.com/plataformatec/devise/issues/4981
[2] https://github.com/plataformatec/devise/pull/4996

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#926315: [Pkg-openssl-devel] Bug#926315: openssl: wget https://google.com fails in d-i

[Cyril Brulebois]

Hi,

Thanks for looping me in, extending to debian-boot@.

Kurt Roeckx  (2019-04-03):
> On Wed, Apr 03, 2019 at 10:03:13PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2019-04-03 11:14:54 [+0100], Dimitri John Ledkov wrote:
> > > $ wget https://google.com
> > > 
> > > fails in Buster alpha installer, when used from a booted netinst iso
> > > in a tty. It also means that fetch-url fails, and thus one cannot use
> > > https preseeding.
> > > 
> > > A fix/workaround, is $ touch /usr/lib/ssl/openssl.cnf it appears that
> > > openssl requires for that file to be present, and it cannot be a
> > > dangling symlink. However, in udeb environment such file does not
> > > exists. I guess that maybe libssl1.1-udeb should ship an empty
> > > openssl.cnf there, or ship the regular deb's /etc/ssl/openssl.cnf in
> > > /usr/lib/ssl/openssl.cnf in the udeb.
> > 
> > interresting.
> > Kurt: should we provide the openssl.cnf and move it from openssl to
> > libssl1.1 as well or should we rather treat the missing openssl.cnf as
> > okay?
> 
> I think shipping it in the libssl1.1 .deb is going to complicate
> upgrades, so I rather not do that. I don't see a problem doing it
> in the .udeb.
> 
> I'm not sure why not having the config file causes problems. I
> think it should be possible to run without config file, so I would
> at least like to know first why it fails.

I'm pretty sure we had successes with wget/https within d-i not so long
ago (i.e. during the last BSP at Mozilla's, past week), and there were
no changes on the openssl side in the meanwhile.

I'll be double checking using the month worth of dailies we have, and
report back with my findings.


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


signature.asc
Description: PGP signature

Bug#924337: Causes regression with upgrades from stretch

[Jonathan McDowell]

Control: merge 924337 925420
Control: severity 924337 serious

This causes failures on upgrades from stretch to buster, and bit me
today. Ideally the mqtt/varnish plugins would be re-enabled but failing
that a note in NEWS.Debian and the release notes seems appropriate.

J.

-- 
  Don't hit the keys so hard, it   |  .''`.  Debian GNU/Linux Developer
  hurts.   | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

Bug#926341: close

[c.buhtz]

Please close. Sorry.

https://github.com/keepassxreboot/keepassxc-browser/issues/375#issuecomment-479590355

Bug#926315: [Pkg-openssl-devel] Bug#926315: openssl: wget https://google.com fails in d-i

[Kurt Roeckx]

On Wed, Apr 03, 2019 at 10:03:13PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-04-03 11:14:54 [+0100], Dimitri John Ledkov wrote:
> > $ wget https://google.com
> > 
> > fails in Buster alpha installer, when used from a booted netinst iso
> > in a tty. It also means that fetch-url fails, and thus one cannot use
> > https preseeding.
> > 
> > A fix/workaround, is $ touch /usr/lib/ssl/openssl.cnf it appears that
> > openssl requires for that file to be present, and it cannot be a
> > dangling symlink. However, in udeb environment such file does not
> > exists. I guess that maybe libssl1.1-udeb should ship an empty
> > openssl.cnf there, or ship the regular deb's /etc/ssl/openssl.cnf in
> > /usr/lib/ssl/openssl.cnf in the udeb.
> 
> interresting.
> Kurt: should we provide the openssl.cnf and move it from openssl to
> libssl1.1 as well or should we rather treat the missing openssl.cnf as
> okay?

I think shipping it in the libssl1.1 .deb is going to complicate
upgrades, so I rather not do that. I don't see a problem doing it
in the .udeb.

I'm not sure why not having the config file causes problems. I
think it should be possible to run without config file, so I would
at least like to know first why it fails.


Kurt

Bug#926347: suitesparse: FTBFS on hurd-i386: mach/clock.h non-existent on GNU/Hurd

[Paul Sonnenschein]

Package: suitesparse
Severity: normal
Version: 1:5.4.0+dfsg-1
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Suitesparse fails to build from source on hurd-i386 because the header
mach/clock.h is not contained in GNU Mach, however it gets included in
GraphBLAS/Demo/Include/simple_timer.h used by
GraphBLAS/Demo/Source/simple_timer.c.

For a detailed log, please see [0].

The patch consists of the following changes:

simple_timer.h
 1. Enable the Linux case (not strictly necessary, due to the existence
of an OpenMP and a C11 fallback case).
 2. Enable the Mach case only if __APPLE__ is defined

simple_timer.c
 1. Enable the Linux case on Hurd (not necessary, see simple_timer.h)
 2. Disable the Mach case unless __APPLE__ is defined (not strictly
necessary, because of the OpenMP case)

Using the Linux case is recommended in [1], however [1] does not
mention the C11 clock function.

Thanks,
Paul Sonnenschein


[0]: 
https://buildd.debian.org/status/fetch.php?pkg=suitesparse=hurd-i386=1%3A5.4.0%2Bdfsg-1=1545919779=0
[1]: https://www.gnu.org/software/hurd/hurd/porting/guidelines.html
diff --git a/GraphBLAS/Demo/Include/simple_timer.h b/GraphBLAS/Demo/Include/simple_timer.h
index 23a1c358..ef24c371 100644
--- a/GraphBLAS/Demo/Include/simple_timer.h
+++ b/GraphBLAS/Demo/Include/simple_timer.h
@@ -37,7 +37,7 @@
 #define _POSIX_C_SOURCE 200809L
 #include 
 
-#if defined ( __linux__ )
+#if defined ( __linux__ ) || defined ( __GNU__ )
 #include 
 #endif
 
@@ -45,7 +45,7 @@
 #include 
 #endif
 
-#if defined ( __MACH__ )
+#if defined ( __MACH__ ) && defined ( __APPLE__ )
 #include 
 #include 
 #endif
diff --git a/GraphBLAS/Demo/Source/simple_timer.c b/GraphBLAS/Demo/Source/simple_timer.c
index 57239d18..28fc9b9d 100644
--- a/GraphBLAS/Demo/Source/simple_timer.c
+++ b/GraphBLAS/Demo/Source/simple_timer.c
@@ -27,7 +27,7 @@ void simple_tic /* returns current time in seconds and nanoseconds */
 tic [0] = omp_get_wtime ( ) ;
 tic [1] = 0 ;
 
-#elif defined ( __linux__ )
+#elif defined ( __linux__ ) || defined ( __GNU__ )
 
 /* Linux has a very low resolution clock() function, so use the high
resolution clock_gettime instead.  May require -lrt */
@@ -36,7 +36,7 @@ void simple_tic /* returns current time in seconds and nanoseconds */
 tic [0] = (double) t.tv_sec ;
 tic [1] = (double) t.tv_nsec ;
 
-#elif defined ( __MACH__ )
+#elif defined ( __MACH__ ) && defined ( __APPLE__ )
 
 clock_serv_t cclock ;
 mach_timespec_t t ;


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

Bug#926261: closed by Ben Hutchings (Re: Bug#926261: linux-image-4.19.0-4-amd64: fan continiously spinning above 6900 RPM after resume on lenovo carbon x1 thinkpad with isa adap

[Karol Szkudlarek]

>
> It has been closed by Ben Hutchings b...@decadent.org.uk.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ben Hutchings 
> b...@decadent.org.uk by
>
> replying to this email.
>
>
> -
>
> Linux doesn't control the fan, that's done by the system firmware.
>
> Ben.

System firmware is a part of Linux. and the problem is actually far from done. 
If you are able to close this ticket and have knowledge maybe give a simple 
suggestion how move forward. For example by reassign to proper debian package. 
Thank you.

Bug#926315: openssl: wget https://google.com fails in d-i

[Sebastian Andrzej Siewior]

On 2019-04-03 11:14:54 [+0100], Dimitri John Ledkov wrote:
> $ wget https://google.com
> 
> fails in Buster alpha installer, when used from a booted netinst iso
> in a tty. It also means that fetch-url fails, and thus one cannot use
> https preseeding.
> 
> A fix/workaround, is $ touch /usr/lib/ssl/openssl.cnf it appears that
> openssl requires for that file to be present, and it cannot be a
> dangling symlink. However, in udeb environment such file does not
> exists. I guess that maybe libssl1.1-udeb should ship an empty
> openssl.cnf there, or ship the regular deb's /etc/ssl/openssl.cnf in
> /usr/lib/ssl/openssl.cnf in the udeb.

interresting.
Kurt: should we provide the openssl.cnf and move it from openssl to
libssl1.1 as well or should we rather treat the missing openssl.cnf as
okay?

> Regards,
> 
> Dimitri.

Sebastian

Bug#925321: RM: openjdk-8/8u171-b11-2

[Rene Engelhard]

Hi,

On Tue, Apr 02, 2019 at 10:48:52PM +0200, Rene Engelhard wrote:
> On Tue, Apr 02, 2019 at 09:08:19PM +0200, Paul Gevers wrote:
> > Just for info, from IRC #debian-release today:
> > 
> > [21:03:39] <_rene_> elbrus: I think you are right (ENOSPC on my rpi
> > handling the mail, need to fix it later), looks like remains of hackery
> > working around Java broken with stack clash fix on i386
> > 
> > [21:04:48] <_rene_>   ifeq "$(DEB_HOST_ARCH)" "i386"
> > [21:04:48] <_rene_> JAVA_RUNTIME_DEPENDS := openjdk-8-jre (>=
> > 8u151-b12-2~) | openjdk-9-jre (>= 9.0.1+11-1~)
> > [21:04:51] <_rene_>   else
> > [21:04:51] <_rene_> [...]
> 
> Jup, will remove.

Fixed in 1:6.1.5-2
 
Regards,
 
Rene

Bug#926286: unblock: wxpython4.0/4.0.4+dfsg-2

[Paul Gevers]

Control: tags -1 confirmed

Hi Scott,

On 03-04-2019 20:23, Scott Talbert wrote:
> On Wed, 3 Apr 2019, Paul Gevers wrote:
>> If so, please make sure the package is actually in unstable. Currently
>> there is nothing to unblock. (I didn't actually review your changes, so
>> don't rush the upload if the FTBFS is actually fixed now.
> 
> My bad.  I'm new to unblock requests.  My read of the guidelines was
> that I needed to get the unblock approval before uploading to unstable.

I think it tells you that you can ask for a per-approval if you are
unsure. (Next time, make that explicit in the bug).

> There were two causes of FTBFS with SIP 4.19.14 that are fixed in my
> pending upload:
> 1) Addition of SIP_OVERRIDE
> 2) Addition of a mapped type for size_t
> 
> The rollback of SIP_OVERRIDE in the sip4 package technically removes the
> need for the SIP_OVERRIDE FTFBS fixes in wxpython4.0, but my preference
> would be to leave them in because they appear to be fix actual bugs,
> even though they are no longer FTBFS bugs.  Do you have any opinion on
> that?

Ok, so there remains a FTBFS problem. Then yes, please proceed with
uploading your fix, remove the moreinfo tag and we will check again.

Are the patches known upstream?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#926322: [Pkg-openssl-devel] Bug#926322: libssl1.1: datovka app is crashing after upgrade to libssl 1.1.1b

[Sebastian Andrzej Siewior]

control: reassing -1 src:openssl
control: forcemerge 923516 -1

On 2019-04-03 15:27:42 [+0200], Štěpán Liška wrote:
> https://github.com/openssl/openssl/issues/8375

So you want also the openssl issue 8375 fixed in Buster/Sid openssl.
This can be done however upstream did not merge a patch for that yet.
Once this done we can check if we wait 1.1.1c or cherry-pick the fix.

Sebastian

Bug#926346: unblock: kronosnet/1.8-2

[Ferenc Wágner]

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

Please unblock package kronosnet

Dear Release Team,

The buildd setup got me again: the upload you kindly unblocked in
#926246 failed to build on all release architectures, because the
official buildds have module loading disabled, thus lack SCTP support,
and the changes introduced a new unit test which wasn't protected from
this yet.  I already uploaded a new revision 1.8-2 which adds a patch to
skip this new test if the SCTP protocol is not supported.  (The same
tests succeed on debci all right, BTW.)  I've blacklisted the sctp
module on my test machine to catch this problem next time.  For now,
please unblock 1.8-2; I provide the incremental debdiff below for ease
of review.

Thanks,
Feri.

diff -Nru kronosnet-1.8/debian/changelog kronosnet-1.8/debian/changelog
--- kronosnet-1.8/debian/changelog  2019-04-01 23:59:14.0 +0200
+++ kronosnet-1.8/debian/changelog  2019-04-03 10:33:30.0 +0200
@@ -1,3 +1,10 @@
+kronosnet (1.8-2) unstable; urgency=medium
+
+  * [b6a2cdc] New patch: send test: skip the SCTP test if SCTP is not supported
+by the kernel
+
+ -- Ferenc Wágner   Wed, 03 Apr 2019 10:33:30 +0200
+
 kronosnet (1.8-1) unstable; urgency=medium
 
   * [ff7beff] New upstream release (1.8)
diff -Nru 
kronosnet-1.8/debian/patches/send-test-skip-the-SCTP-test-if-SCTP-is-not-supported-by-.patch
 
kronosnet-1.8/debian/patches/send-test-skip-the-SCTP-test-if-SCTP-is-not-supported-by-.patch
--- 
kronosnet-1.8/debian/patches/send-test-skip-the-SCTP-test-if-SCTP-is-not-supported-by-.patch
1970-01-01 01:00:00.0 +0100
+++ 
kronosnet-1.8/debian/patches/send-test-skip-the-SCTP-test-if-SCTP-is-not-supported-by-.patch
2019-04-03 10:33:22.0 +0200
@@ -0,0 +1,28 @@
+From: =?utf-8?q?Ferenc_W=C3=A1gner?= 
+Date: Wed, 3 Apr 2019 10:26:11 +0200
+Subject: send test: skip the SCTP test if SCTP is not supported by the kernel
+
+For example, module loading is disabled on Debian build daemons.
+---
+ libknet/tests/api_knet_send.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/libknet/tests/api_knet_send.c b/libknet/tests/api_knet_send.c
+index f241201..1c55db1 100644
+--- a/libknet/tests/api_knet_send.c
 b/libknet/tests/api_knet_send.c
+@@ -173,12 +173,13 @@ static void test(uint8_t transport)
+   }
+ 
+   if (knet_link_set_config(knet_h, 1, 0, transport, , , 0) < 0) {
++  int exit_status = transport == KNET_TRANSPORT_SCTP && errno == 
EPROTONOSUPPORT ? SKIP : FAIL;
+   printf("Unable to configure link: %s\n", strerror(errno));
+   knet_host_remove(knet_h, 1);
+   knet_handle_free(knet_h);
+   flush_logs(logfds[0], stdout);
+   close_logpipes(logfds);
+-  exit(FAIL);
++  exit(exit_status);
+   }
+ 
+   if (knet_link_set_enable(knet_h, 1, 0, 1) < 0) {
diff -Nru kronosnet-1.8/debian/patches/series 
kronosnet-1.8/debian/patches/series
--- kronosnet-1.8/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ kronosnet-1.8/debian/patches/series 2019-04-03 10:33:22.0 +0200
@@ -0,0 +1 @@
+send-test-skip-the-SCTP-test-if-SCTP-is-not-supported-by-.patch

unblock kronosnet/1.8-2

Bug#916863: [nftables] tproxy action not parsed correctly

[Michał Mirosław]

It turns out that v0.9.0 of nftables userspace does not have tproxy
support at all and the errors are just misleading.

The support was committed in

2be1d52644cf 2018-08-03 12:17:31 +0200 src: Add tproxy support

but the release is:

cd21a243162a (tag: v0.9.0) 2018-06-08 14:46:00 +0200

Bug#924787: yubikey-personalization: After I upgraded to version 1.19.3-2, I can't read my Yubikeys.It shows is "Unknow error occured"

[Thomas Ross]

Package: libykpers-1-1
Version: 1.19.3-2
Followup-For: Bug #924787

Hi,

I'm having the same issue after upgrading to 1.19.3-2. The problem is in the
udev rules - in 1.19.3-2, the package switched from providing udev rules to
using the rules in libu2f-udev (source package libu2f-host). The relevant udev
rules provided in libu2f-udev are:

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1050", 
ATTRS{idProduct}=="0113|0114|0115|0116|0120|0200|0402|0403|0406|0407|0410", 
TAG+="uaccess", GROUP="plugdev", MODE="0660"

It looks like the udev rules we need to allow the YubiKey to be used properly
need to have SUBSYSTEMS=="usb", as using this one works:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1050", 
ATTRS{idProduct}=="0113|0114|0115|0116|0120|0200|0402|0403|0406|0407|0410", 
TAG+="uaccess", GROUP="plugdev", MODE="0660"

Here are the old udev rules that were provided by libykpers
(https://salsa.debian.org/auth-team/yubikey-personalization/blob/ff35f76c2f533c224b1f64919d159c08f19ac598/70-yubikey.rules):

ACTION=="add|change", SUBSYSTEM=="usb", \
  ATTRS{idVendor}=="1050", 
ATTRS{idProduct}=="0010|0110|0111|0114|0116|0401|0403|0405|0407|0410", \
  TEST=="/var/run/ConsoleKit/database", \
  RUN+="udev-acl --action=$env{ACTION} --device=$env{DEVNAME}"

Here's the dump from udevadm info -q all:

  looking at device 
'/devices/pci:00/:00:14.0/usb2/2-12/2-12:1.0/0003:1050:0407.0036/input/input55':
KERNEL=="input55"
SUBSYSTEM=="input"
DRIVER==""
ATTR{properties}=="0"
ATTR{uniq}==""
ATTR{name}=="Yubico YubiKey OTP+FIDO+CCID"
ATTR{phys}=="usb-:00:14.0-12/input0"

  looking at parent device 
'/devices/pci:00/:00:14.0/usb2/2-12/2-12:1.0/0003:1050:0407.0036':
KERNELS=="0003:1050:0407.0036"
SUBSYSTEMS=="hid"
DRIVERS=="hid-generic"
ATTRS{country}=="00"

  looking at parent device 
'/devices/pci:00/:00:14.0/usb2/2-12/2-12:1.0':
KERNELS=="2-12:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="usbhid"
ATTRS{supports_autosuspend}=="1"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bInterfaceClass}=="03"
ATTRS{bNumEndpoints}=="01"
ATTRS{authorized}=="1"
ATTRS{bInterfaceSubClass}=="01"
ATTRS{bInterfaceProtocol}=="01"

  looking at parent device '/devices/pci:00/:00:14.0/usb2/2-12':
KERNELS=="2-12"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{authorized}=="1"
ATTRS{urbnum}=="17"
ATTRS{tx_lanes}=="1"
ATTRS{idVendor}=="1050"
ATTRS{quirks}=="0x0"
ATTRS{configuration}==""
ATTRS{bDeviceSubClass}=="00"
ATTRS{maxchild}=="0"
ATTRS{bConfigurationValue}=="1"
ATTRS{speed}=="12"
ATTRS{bDeviceClass}=="00"
ATTRS{devnum}=="61"
ATTRS{devpath}=="12"
ATTRS{busnum}=="2"
ATTRS{manufacturer}=="Yubico"
ATTRS{ltm_capable}=="no"
ATTRS{bNumInterfaces}==" 3"
ATTRS{removable}=="removable"
ATTRS{bMaxPower}=="30mA"
ATTRS{bDeviceProtocol}=="00"
ATTRS{idProduct}=="0407"
ATTRS{product}=="YubiKey OTP+FIDO+CCID"
ATTRS{rx_lanes}=="1"
ATTRS{bNumConfigurations}=="1"
ATTRS{version}==" 2.00"
ATTRS{bmAttributes}=="80"
ATTRS{bcdDevice}=="0512"

Thanks,
Thomas.

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

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

Versions of packages libykpers-1-1 depends on:
ii  libc6 2.28-8
ii  libjson-c30.12.1+ds-2
ii  libusb-1.0-0  2:1.0.22-2
ii  libyubikey0   1.13-4

Versions of packages libykpers-1-1 recommends:
ii  libu2f-udev  1.1.9-1

libykpers-1-1 suggests no packages.

-- no debconf information

Bug#926345: isync: Fails to sync Maildir++ subfolders after initial sync

[Nik A. Melchior]

Package: isync
Version: 1.3.0-2
Severity: normal

Dear Maintainer,

This is a follow-up to #782054, where I was one of the commenters.  I'm still
using the same mail configuration (dovecot remote, local Maildir++ accessed by
mutt), but I've finally upgraded to isync/mbsync 1.3.0.  My Maildir still
includes subfolders of the format "~/Mail/.lists.ip".

When I run mbsync, it performs an initial synchronization without complaint.
I can verify that new or moved messages in remote subfolders appear in the
corresponding local folders.  Once mbsync is running, though, any further
activity on these folders is not synchronized, but produces an error such as:



Sync completed after 0s at 2019-04-03 14:52:59 (1 mailbox)
Sync started at 2019-04-03 14:52:59 (all mailboxes)
+ mbsync hostname
C: 1/1  B: 69/69  M: +0/0 *0/0 #0/0  S: +1/1 *1/1 #0/0imap(username): Info: 
Disconnected: Logged out in=4346 out=4023155

Sync completed after 10s at 2019-04-03 14:53:09 (all mailboxes)
Sync started at 2019-04-03 14:53:19 (1 mailbox)
+ mbsync hostname:lists.ip
C: 0/1  B: 0/1  M: +0/0 *0/0 #0/0  S: +0/0 *0/0 #0/0
Maildir error: store 'local', folder 'lists.ip': SubFolders style Maildir++ 
does not support dots in mailbox names
C: 1/1  B: 1/1  M: +0/0 *0/0 #0/0  S: +0/0 *0/0 #0/0imap(username): Info: 
Disconnected: Logged out in=21 out=469

Sync errored: mbsync exited (status 1) after 1s at 2019-04-03 14:53:20 (1 
mailbox)



If I kill mbsync and restart it, the updated messages are synchronized during
the initial pass.

I am using the Maildir++ "SubFolders" option, and I think my filesystem layout
is essentially the same as in the earlier ticket.  I'd be happy to produce any
useful debugging output.  A relevant excerpt of the output from "mbsync -l -Dn
-a" includes:


>>> 1 NAMESPACE
* NAMESPACE (("" ".")) NIL NIL
1 OK Namespace completed.
>>> 2 LIST "" "*"
...
* LIST (\HasChildren) "." lists
* LIST (\HasNoChildren) "." lists.ip
...
2 OK List completed.
INBOX
lists
lists/ip
...
>>> 3 LOGOUT


Thanks,

-- Nik

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

Kernel: Linux 4.15.0-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
Init: sysvinit (via /sbin/init)

Versions of packages isync depends on:
ii  libc6   2.27-1
ii  libdb5.35.3.28-12
ii  libsasl2-2  2.1.26.dfsg1-15
ii  libssl1.1   1.1.0d-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

isync recommends no packages.

Versions of packages isync suggests:
ii  mutt  1.9.4-2

-- no debconf information

Bug#926344: RFP: libomemo -- implements OMEMO encryption for XMPP

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

* Package name: libomemo
  Version : 0.6.2
  Upstream Author : Richard Bayerle 
* URL : https://github.com/gkdr/libomemo
* License : MIT
  Programming Lang: C
  Description : implements OMEMO encryption for XMPP

Implements OMEMO (XEP-0384) in C.

Input and output are XML strings, so it does not force you to
use a certain XML lib. While the actual protocol functions do
not depend on any kind of storage, it comes with a basic
implementation in SQLite.

It deals with devicelists and bundles as well as encrypting the
payload, but does not handle the double ratchet sessions for
encrypting the key to the payload. However, you can use my axc
lib for that and easily combine it with this one (or write all
the libsignal client code yourself if that is better suited to
your needs).

Bug#926343: RFP: libaxc -- client library for libsignal-protocol-c

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

* Package name: libaxc
  Version : 0.3.2
  Upstream Author : Richard Bayerle 
* URL : https://github.com/gkdr/axc
* License : GPL 3
  Programming Lang: C
  Description : client library for libsignal-protocol-c

Implements the necessary interfaces using gcrypt and SQLite.

This is a dependency for purple-lurch (#905883).

Bug#925106: php7.3-common: please add Breaks: php7.0-curl, gforge-common (<< 6)

[Andreas Beckmann]

On 2019-04-03 13:45, Ondřej Surý wrote:
> Hi Andreas,
> 
> there will be new upstream release of PHP 7.3 this week, so I’ll handle it as 
> one batch, ok?

That's fine.

> I just wonder if there’s a way how to fix that without breaking 
> co-installability with php7.0-curl from external repositories.

How does such a package look like? What dependencies does it have?
What's the versioning scheme?
We could try a Breaks: libcurl3 in php7.3-common.
... trying ...
Nope, that only make it worse.

Is stretch getting new php 7.0 point releases? In that case we can't
have a versioned
  Breaks: php7.0-curl (<< external-repo-version-newer-than-stretch)
that will continue to be valid. (Unless the external repo versions come
with an epoch)

> What if we fixed this in php7.0-curl package?  (I keep separate sources for 
> it.)

I don't think there is much fixable in php7.0-curl, its the
libcurl{3->4} transition biting us here ...

The big hammer that should work is
  gcc-8-base: Breaks: libcurl3
but it's a completely unrelated package ...


Andreas

Bug#926342: libprotobuf17: I was forced to download libprotobuf17 on this site: https://packages.debian.org/buster/amd64/libprotobuf17/download

[Gilles CHARABOT]

Package: libprotobuf17
Version: 3.6.1.3-1
Severity: normal

Dear Maintainer,



   * What led up to the situation?

I wanted to update libphonenumber7 but I couldn't, I was blocked with 
libprotobuf10. I have then download libprotobuf17 directly on this website 
https://packages.debian.org/buster/amd64/libprotobuf17/download and then I 
could update libphonenumber7.
Today, several months after I performed this operation, there is now no 
candidate version for libprotobuf17 in Buster.

# aptitude why libprotobuf17
i   evolution-plugins   Dépend libebook-contacts-1.2-2 (>= 3.16.2)
i A libebook-contacts-1.2-2 Dépend libphonenumber7
i A libphonenumber7 Dépend libprotobuf17  

# apt-cache policy libprotobuf17
libprotobuf17:
  Installé : 3.6.1.3-1
  Candidat : (aucun)
 Table de version :
 *** 3.6.1.3-1 -3
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status





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

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

Versions of packages libprotobuf17 depends on:
ii  libc6   2.28-8
ii  libgcc1 1:8.3.0-4
ii  libstdc++6  8.3.0-4
ii  zlib1g  1:1.2.11.dfsg-1

libprotobuf17 recommends no packages.

libprotobuf17 suggests no packages.

-- no debconf information

Bug#926316: systemd: Installing the systemd package switches the init system to systemd

[Felipe Sateler]

On Wed, Apr 3, 2019 at 1:23 PM Michael Biebl  wrote:

> Am 03.04.19 um 18:08 schrieb Felipe Sateler:
> > Looks like sysvinit-core needs XB-Important: yes to prevent such easy
> > removal.
>
> I though about this too, but on the other hand with "init" we actually
> allow users to switch between sysvinit and systemd and adding
> XB-Important: yes to sysvinit-core would render "init" moot.
>

Ah, you are right. I mixed init with systemd-sysv, which does not have the
Important flag set.


>
> I have to say I'm surprised apt prefers uninstalling a package to
> satisfy a Recommends over not installing a Recommends and keeping that
> package.
>

Yeah, I that is surprising. Would it make sense to loop the apt maintainers
into this?


>
>
> If systemd is the active PID 1, we want libpam-systemd installed
> alongside. So far we also considered that users might not have
> systemd-sysv installed but instead boot with init=/lib/systemd/systemd.
> I have no idea how common that is, so maybe an alternative could be to
> move the libpam-systemd Recommends from systemd to systemd-sysv
> (alongside the existing libnss-systemd).
>

Makes a lot of sense to me.


> WDYT? Is it too late in the release cycle to make such a change?
>

I don't know. Most likely we would need a tight dependency on systemd, to
ensure at least one pacakge Recommends libpam-systemd.

-- 

Saludos,
Felipe Sateler

Bug#919231: Salt-master unable to access directories

[Felipe Sateler]

On Wed, Apr 3, 2019 at 2:26 PM Michael Biebl  wrote:

> On Wed, 27 Feb 2019 10:33:48 -0300 Felipe Sateler 
> wrote:
> > Control: found -1 241-5
> > Control: tags -1 confirmed upstream
> > Control: forwarded -1 https://github.com/systemd/systemd/issues/11842
> >
> > I was able to reproduce the issue, and forwarded this upstream.
>
> Seems like something which we should consider fixing for buster.
>
> Felipe, this bug is marked as fixed upstream. Since you already had a
> look at this issue, could you cherry-pick the necessary upstream commits
> and verify that the issue is fixed?
>

Unfortunately the fix seems to have been merged with some other
refactorings and the diff is not as small[1]. I'll try to check if some of
the patches are not necessary.


[1] https://github.com/systemd/systemd/pull/12005/files


-- 

Saludos,
Felipe Sateler

Bug#926286: unblock: wxpython4.0/4.0.4+dfsg-2

[Scott Talbert]

On Wed, 3 Apr 2019, Paul Gevers wrote:


Please unblock package wxpython4.0

This fixes a wxpython4.0 FTBFS bug (#924856) with SIP 4.19.14 which was
uploaded in late February.


Instead, we (well, Dmitry) fixed sip4 to not add the new sip_override.
Do you still want your new package in buster?

If so, please make sure the package is actually in unstable. Currently
there is nothing to unblock. (I didn't actually review your changes, so
don't rush the upload if the FTBFS is actually fixed now.


My bad.  I'm new to unblock requests.  My read of the guidelines was that 
I needed to get the unblock approval before uploading to unstable.


There were two causes of FTBFS with SIP 4.19.14 that are fixed in my 
pending upload:

1) Addition of SIP_OVERRIDE
2) Addition of a mapped type for size_t

The rollback of SIP_OVERRIDE in the sip4 package technically removes the 
need for the SIP_OVERRIDE FTFBS fixes in wxpython4.0, but my preference 
would be to leave them in because they appear to be fix actual bugs, even 
though they are no longer FTBFS bugs.  Do you have any opinion on that?


Thanks,
Scott

Bug#926207: iotop: unable to run on kernels with retpoline (spectre)

[Neil Tallim]

> Any chance you could upgrade to either the Debian kernel or one based
> on the Debian kernel or on 4.19 mainline and see if any of them fix it?
>
> Also, I suggest you try to get those quirks fixed in Linux mainline,
> so that you don't have to keep building Linux yourself :)

I'm afraid upgrading would be difficult. The use-case is one of fairly
entrenched networking for my company, so there's significant
regression-testing required to even move further within the same minor
version.

The quirks are also somewhat difficult to generalise: some of the
hardware is rather antiquated, requiring driver hacks for
initialisation, and many of the other changes are similarly niche and
intended only as case-specific optimisations. (It's divergent in much
the same way that much of the OpenWRT project's kernel patches will
never be suitable for mainline, but we do submit bugfixes and stuff
when we can)

I was able to confirm that the problem doesn't occur with Debian's
4.19 series on unrelated hardware, however, and it looks like the
problem has been resolved for a while in stock kernels.


> Do you have any details about which patch this is?

https://lists.ubuntu.com/archives/kernel-team/2018-May/092723.html

I wasn't able to find an equivalent in Debian's patchsets, which led
me to check upstream; more on that below.


> Also, it would be great if you could try to get the patch into the
> Linux kernel's mainline stable releases.

After digging around for a while, it looks like this may be a
side-effect of how LTSI works, though I'll report it anyway, in hopes
that it can be addressed without violating the "don't break the
userspace ABI" policy. Any semi-recent kernel version should be
unaffected.

The following patch adds a "NoNewPrivs" line to /proc//status,
where the blank appears in 4.4. It doesn't look like it was ever
backported into the tree, or, rather, it seems to be the case that
retpoline logic, which assumed there was text right after the
capabilities block, was backported directly, leading to the gap.

NoNewPrivs patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=af884cd4a5ae62fcf5e321fecf0ec1014730353d


In any case, this is definitely an issue that should be fixed in
(specific versions of) the kernel. I still think iotop should be
synced to gain tolerance to unexpected input, but it isn't a
Debian-specific problem in light of what's been discussed here.


Thanks for the sanity-checks here.

-Neil

Bug#926291: [Pkg-puppet-devel] Bug#926291: puppetdb 6 not compatible with puppet-master 5

[Chad W Seys]

Hi Apollon,
   I was able to run your autopkgtest successfully with puppet-master 5 
and puppetdb 6, so I'll look at that config to see if I can find the 
problem.

Thanks!
Chad.

Bug#926286: unblock: wxpython4.0/4.0.4+dfsg-2

[Paul Gevers]

Control: tags -1 moreinfo

Hi Scott,

On 03-04-2019 00:16, Scott Talbert wrote:
> Please unblock package wxpython4.0
> 
> This fixes a wxpython4.0 FTBFS bug (#924856) with SIP 4.19.14 which was 
> uploaded in late February.

Instead, we (well, Dmitry) fixed sip4 to not add the new sip_override.
Do you still want your new package in buster?

If so, please make sure the package is actually in unstable. Currently
there is nothing to unblock. (I didn't actually review your changes, so
don't rush the upload if the FTBFS is actually fixed now.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#926341: keepassxc: Firefox AddOn "KeePassXC-Browser" force the current upstream-realease

[Christian Buhtz]

Package: keepassxc
Version: 2.3.4+dfsg.1-1~bpo9+1
Severity: important

KeePassXC 2.4.0 release official/stable at upstream.

The firefox addon "KeePassXC-Browser" no force to contact to 2.4.0 and deny to
contact to the current Debian stable keepassxc 2.3.4.

It would be nice if you could (out of the usual way) force to update to the new
version in the stable repository.

Next step would be to get in contact to the upstream developers and have a
seriouse talk with them. It is unpolite useless etc

https://github.com/keepassxreboot/keepassxc-browser/issues/375



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

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

Versions of packages keepassxc depends on:
ii  libargon2-0   0~20160821-1+b1
ii  libc6 2.24-11+deb9u4
ii  libgcrypt20   1.7.6-2+deb9u3
ii  libqt5core5a  5.7.1+dfsg-3+deb9u1
ii  libqt5dbus5   5.7.1+dfsg-3+deb9u1
ii  libqt5gui55.7.1+dfsg-3+deb9u1
ii  libqt5network55.7.1+dfsg-3+deb9u1
ii  libqt5widgets55.7.1+dfsg-3+deb9u1
ii  libqt5x11extras5  5.7.1~20161021-2
ii  libsodium18   1.0.11-2
ii  libstdc++66.3.0-18+deb9u1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libxi62:1.7.9-1
ii  libxtst6  2:1.2.3-1
ii  libykpers-1-1 1.17.3-1
ii  libzxcvbn02.0+dfsg-1
ii  zlib1g1:1.2.8.dfsg-5

keepassxc recommends no packages.

keepassxc suggests no packages.

-- no debconf information

Bug#926118: unblock: libmspack/0.10.1-1

[Jens Reyer]

On 03.04.19 09:05, Marc Dequènes (duck) wrote:
> I already asked for an unblock, explaining the situation (like why it
> was blocked out of testing, why the recent fixes…), but it was rejected
> without any comment on my rational:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923885

Strange, #923885 doesn't appear on
https://lists.debian.org/debian-release/2019/03/threads.html (or page 2
or 3).  I checked before, and now triple checked again.


> I'm not convinced backporting a bunch of patches on top of 0.8-1
> (important and security fixes), which would end-up creating an untested
> version would be a safe solution. 0.9.1-1 and now 0.10.1-1 have been
> around for some time without problem.

After reading duck's insiders rational I'm even more convinced that this
is the right way to go.

libmspack/0.8-1 really is problematic.  The now broken "cabextract -F"
is used quite often in Winetricks.  Users are frequently reporting
issues upstream.[1]  So if we can't get 0.10.1-1 accepted, I guess I'd
try to submit a patched, freeze-policy compliant version targeted only
at the problem that affects winetricks.  I'd be more then surprised if
that results in a nearly as good and tested version as 0.10.1-1 is.

0.8-1 was superseded after only 8 days by 0.9.1-1 in unstable last
November.  At least winetricks users will have manually updated long
time ago.


> So I hope the release team will change their mind, or suggest a solution.

Yes, please make an exception.  Sorry for the work now, but please help
us to solve this issue in a good way.

Greets
jre


[1]
https://github.com/kyz/libmspack/issues/22
https://github.com/Winetricks/winetricks/issues/1120
https://github.com/Winetricks/winetricks/issues/1154
https://github.com/Winetricks/winetricks/issues/1172
https://github.com/Winetricks/winetricks/issues/1178
https://github.com/Winetricks/winetricks/issues/1193

Bug#926340: RFP: node-evacuated-chai-string -- Strings comparison matchers for chai

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-evacuated-chai-string
  Version : 1.4.0
  Upstream Author : Oleg Nechiporenko 
* URL : 
https://salsa.debian.org/themusicgod1-guest/evacuated-chai-string/
* License : MIT
  Programming Lang: javascript
  Description : Strings comparison matchers for chai

Matchers for chai to help with common string comparison assertions

It is a prerequisite for Mist ( #827314 )

Bug#919231: Salt-master unable to access directories

[Michael Biebl]

On Wed, 27 Feb 2019 10:33:48 -0300 Felipe Sateler 
wrote:
> Control: found -1 241-5
> Control: tags -1 confirmed upstream
> Control: forwarded -1 https://github.com/systemd/systemd/issues/11842
> 
> I was able to reproduce the issue, and forwarded this upstream.

Seems like something which we should consider fixing for buster.

Felipe, this bug is marked as fixed upstream. Since you already had a
look at this issue, could you cherry-pick the necessary upstream commits
and verify that the issue is fixed?

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

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

[Andrey Rahmatullin]

libwolfssl was removed from testing due to #918952.
The shared lib was removed but this package was not, because it doesn't
depend on the lib. Maybe the B-D can be safely removed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#926339: unblock: libreoffice/1:6.1.5-2

[Rene Engelhard]

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

Please unblock package libreoffice

unblock libreoffice/1:6.1.5-2

The main reason for this update is basically the fix for #926281 so that
openjdk-8 can properly be removed.

To get it build on sid with the changed java.vendor variable (I still
think this change should be reverted...) to "Debian" instead of "Oracle
Corporation", I need to fix that too (see #926318), While debugging that
issue I saw a (admittedly minor) doc problem which I just fixed.

Last but not least there's the new recommendation for gstreamer1.0-gtk3
for better experience in Impress with LibreOffice using gtk3 (as in
GNOME)

Diff:

diff -Nru libreoffice-6.1.5/debian/changelog libreoffice-6.1.5/debian/changelog
--- libreoffice-6.1.5/debian/changelog  2019-02-02 22:49:54.0 +0100
+++ libreoffice-6.1.5/debian/changelog  2019-04-03 13:19:34.0 +0200
@@ -1,3 +1,20 @@
+libreoffice (1:6.1.5-2) unstable; urgency=medium
+
+  * debian/patches/mention-java-common-package.diff: update message to
+reflect current config dir...
+  * debian/patches/java.vendor-Debian.diff: make jvmfwk recognize "Debian"
+as java.vendor as that's what is set in openjdk 11 >= 11.0.3+4-2
+- see #926009 (closes: #926318)
+
+  * debian/control.gtk3.in:
+- make libreoffice-gtk3 recommend gstreamer1.0-gtk3 (see LP: #1820062)
+  * debian/rules:
+- remove i386 special-casing for openjdk-8 and -9 from old "stack clash
+  fix broken on i386" days preventing removal openjdk-8
+  (closes: #926281)
+
+ -- Rene Engelhard   Wed, 03 Apr 2019 13:19:34 +0200
+
 libreoffice (1:6.1.5-1) unstable; urgency=medium

   * New upstream release
@@ -66,6 +83,8 @@
 libreoffice (1:6.1.4-1) unstable; urgency=medium

   * New upstream release
+- show partial signatures even if cert validation fails
+  (CERT-Bund#2018100828000257)

   * debian/patches/disableClassPathURLCheck.diff: add new upstream
 configure check for this (from master)
diff -Nru libreoffice-6.1.5/debian/control libreoffice-6.1.5/debian/control
--- libreoffice-6.1.5/debian/control2019-02-02 22:49:54.0 +0100
+++ libreoffice-6.1.5/debian/control2019-04-03 13:19:34.0 +0200
@@ -4246,6 +4246,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Suggests: libreofficekit-data
+Recommends: gstreamer1.0-gtk3
 Section: gnome
 Enhances: libreoffice
 Description: office productivity suite -- GTK+ 3 integration
diff -Nru libreoffice-6.1.5/debian/control.gtk3.in 
libreoffice-6.1.5/debian/control.gtk3.in
--- libreoffice-6.1.5/debian/control.gtk3.in2018-01-22 17:38:50.0 
+0100
+++ libreoffice-6.1.5/debian/control.gtk3.in2019-04-03 13:19:34.0 
+0200
@@ -4,6 +4,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Suggests: libreofficekit-data
+Recommends: gstreamer1.0-gtk3
 Section: gnome
 Enhances: libreoffice
 Description: office productivity suite -- GTK+ 3 integration
diff -Nru libreoffice-6.1.5/debian/patches/java.vendor-Debian.diff 
libreoffice-6.1.5/debian/patches/java.vendor-Debian.diff
--- libreoffice-6.1.5/debian/patches/java.vendor-Debian.diff1970-01-01 
01:00:00.0 +0100
+++ libreoffice-6.1.5/debian/patches/java.vendor-Debian.diff2019-04-03 
13:19:34.0 +0200
@@ -0,0 +1,39 @@
+diff --git a/jvmfwk/distributions/OpenOfficeorg/javavendors_linux.xml 
b/jvmfwk/distributions/OpenOfficeorg/javavendors_linux.xml
+index b008bb1fc0f7..ea0ddc4e7c91 100644
+--- a/jvmfwk/distributions/OpenOfficeorg/javavendors_linux.xml
 b/jvmfwk/distributions/OpenOfficeorg/javavendors_linux.xml
+@@ -25,6 +25,9 @@
+ 
+   1.6.0
+ 
++
++  1.6.0
++
+ 
+   1.5.0
+ 
+diff --git a/jvmfwk/plugins/sunmajor/pluginlib/vendorlist.cxx 
b/jvmfwk/plugins/sunmajor/pluginlib/vendorlist.cxx
+index 60911f8a63ca..eaa26f441ad7 100644
+--- a/jvmfwk/plugins/sunmajor/pluginlib/vendorlist.cxx
 b/jvmfwk/plugins/sunmajor/pluginlib/vendorlist.cxx
+@@ -41,6 +41,7 @@
+ #endif
+ VENDOR_MAP_ENTRY("Sun Microsystems Inc.", SunInfo)
+ VENDOR_MAP_ENTRY("Oracle Corporation", SunInfo)
++VENDOR_MAP_ENTRY("Debian", SunInfo)
+ VENDOR_MAP_ENTRY("AdoptOpenJdk", SunInfo)
+ #ifndef MACOSX
+ VENDOR_MAP_ENTRY("IBM Corporation", OtherInfo)
+diff --git a/bean/com/sun/star/comp/beans/LocalOfficeWindow.java 
b/bean/com/sun/star/comp/beans/LocalOfficeWindow.java
+index 67ace100fb5f..46cdb32fd276 100644
+--- a/bean/com/sun/star/comp/beans/LocalOfficeWindow.java
 b/bean/com/sun/star/comp/beans/LocalOfficeWindow.java
+@@ -250,7 +250,7 @@ public class LocalOfficeWindow
+ if (getNativeWindowSystemType() == SystemDependent.SYSTEM_XWINDOW )
+ {
+ String vendor = System.getProperty("java.vendor");
+-if ((vendor.equals("Sun Microsystems Inc.") || 
vendor.equals("Oracle Corporation"))
++if ((vendor.equals("Sun Microsystems Inc.") || 
vendor.equals("Oracle 

Bug#926287: barbican: FTBFS: TypeError: set_defaults() got an unexpected keyword argument 'vault_approle_role_id'

[Andreas Beckmann]

On 2019-04-03 17:27, Thomas Goirand wrote:
> Weird, I couldn't reproduce. Could it be my setup with
> --build-dep-resolver=aspcud?

Likely. I'd guess my build pulled a package from sid due to
insufficiently versioned B-D.

Andreas

Bug#926334: lintian: Does the SafeSEH check make sense for Mono/.NET DLLs?

[Felix Lechner]

Control: tags 926334 moreinfo

On Wed, Apr 3, 2019 at 9:30 AM Hilko Bengen  wrote:
>
> In this
> context, looking for the x86-specific SafeSEH feature does not make much
> sense, does it?

I do not know enough about Mono to say whether your DLLs are
vulnerable to manipulation of the Structured Exception Handler. Why
don't you just override the tag if you are sure?

Bug#926337: unblock: notary/0.6.1~ds1-3

[Shengjing Zhu]

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

Please unblock package notary

* Regenerate some test certs since they are expired (Closes: #924119)

unblock notary/0.6.1~ds1-3
diff -Nru notary-0.6.1~ds1/debian/changelog notary-0.6.1~ds1/debian/changelog
--- notary-0.6.1~ds1/debian/changelog   2018-07-11 09:34:36.0 +0800
+++ notary-0.6.1~ds1/debian/changelog   2019-04-04 00:12:00.0 +0800
@@ -1,3 +1,10 @@
+notary (0.6.1~ds1-3) unstable; urgency=medium
+
+  * Team upload.
+  * Regenerate some test certs since they are expired (Closes: #924119)
+
+ -- Shengjing Zhu   Thu, 04 Apr 2019 00:12:00 +0800
+
 notary (0.6.1~ds1-2) unstable; urgency=medium
 
   * New upstream patch to remove "golang-ed25519-dev" dependency.
diff -Nru notary-0.6.1~ds1/debian/control notary-0.6.1~ds1/debian/control
--- notary-0.6.1~ds1/debian/control 2018-07-11 09:17:53.0 +0800
+++ notary-0.6.1~ds1/debian/control 2019-04-04 00:12:00.0 +0800
@@ -30,7 +30,8 @@
golang-golang-x-sys-dev,
golang-google-grpc-dev (>= 0.0~git20151002~),
golang-gopkg-gorethink-gorethink.v3-dev,
-   golang-goprotobuf-dev
+   golang-goprotobuf-dev,
+   openssl
 Standards-Version: 4.1.4
 Homepage: https://github.com/theupdateframework/notary
 Vcs-Browser: https://salsa.debian.org/go-team/packages/notary
diff -Nru notary-0.6.1~ds1/debian/rules notary-0.6.1~ds1/debian/rules
--- notary-0.6.1~ds1/debian/rules   2018-06-19 23:04:42.0 +0800
+++ notary-0.6.1~ds1/debian/rules   2019-04-04 00:12:00.0 +0800
@@ -13,6 +13,14 @@
  --buildsystem=golang \
  --with=golang
 
+override_dh_auto_configure:
+   # Note(zhsj): some certs are expired and cause test failures.
+   # but there's no need to regenerate certs which need cfssljson tool.
+   # And I don't want to add another Build-Depends.
+   sed -i '/command -v cfssljson/i exit 0' 
./fixtures/regenerateTestingCerts.sh
+   cd fixtures && ./regenerateTestingCerts.sh
+   dh_auto_configure
+
 override_dh_auto_build:
dh_auto_build -- -tags "$(BUILDTAGS)"
 


signature.asc
Description: PGP signature

Bug#926338: tomcat9: tomcat user's home folder is '/'

[Alex]

Package: tomcat9
Version: 9.0.16-1~bpo9+1
Severity: important
Tags: d-i

Dear Maintainer,

With default `tomcat9` installation a system user is created as per the
following instructions:

# Create the tomcat user as defined in /usr/lib/sysusers.d/tomcat9.conf
systemd-sysusers


/usr/lib/sysusers.d/tomcat9.conf:
#Type Name ID GECOS Home directory Shell
u tomcat   -  "Apache Tomcat"   -  /usr/sbin/nologin


Which results in `/` (root folder) as a home dir
grep tomcat /etc/passwd | awk -F: '{ print $6}'
/

A problem begins when some of Tomcat's webapps are trying to access $HOME for 
writing. That's completely another question about _why_ they want to write to 
$HOME. But the whole idea having `/` as home dir is definitely insecure.


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

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

Versions of packages tomcat9 depends on:
ii  lsb-base9.20161125
ii  systemd 241-1~bpo9+1
ii  tomcat9-common  9.0.16-1~bpo9+1
ii  ucf 3.0036

Versions of packages tomcat9 recommends:
ii  libtcnative-1  1.2.21-1~bpo9+1

Versions of packages tomcat9 suggests:
ii  tomcat9-admin 9.0.16-1~bpo9+1
pn  tomcat9-docs  
pn  tomcat9-examples  
ii  tomcat9-user  9.0.16-1~bpo9+1

-- no debconf information

Bug#921267: systemd fails to reach shutdown.target when rebooting or shutting down the system after resuming from suspend

[Michael Biebl]

Hi,

so far the bug reports all mention that this is specific to AMD hardware.

Does the affected system have an AMD CPU/graphics card?

-- 
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#926336: tracker.debian.org: changing the sphinx theme from default to sphinx_rtd_theme

[Salman Mohammadi]

Package: tracker.debian.org
Severity: wishlist

Dear Maintainer,

It would be nice if we changed the documentation (sphinx) theme from
*default* to *sphinx_rtd_theme*. I suppose it is more visually appealing.


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

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

Bug#926060: lintian: portable-executable-missing-security-features false positives

[Chris Lamb]

Hi Scott,

> >… I strongly suspect this is the case, yeah. If you agree, please
> >go ahead and -done this issue. Thanks either way, naturally. :)
> 
> These are all EICAR test files [1].  Generically these are all test 
> files (I haven't checked, other packages may ship these to).  It would 
> be at least slightly generic and not unreasonable to exclude any files 
> with the EICAR test string from the test.

Good idea. Unfortunately, your files don't actually actually include the
EICAR string :)


Best wishes,

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

Bug#926334: lintian: Does the SafeSEH check make sense for Mono/.NET DLLs?

[Hilko Bengen]

Package: lintian
Version: 2.11.0
Severity: normal

Dear Maintainers,

two .NET-based projects which I am currently working on (dnlib, de4dot)
give me Lintian warnings such as

,
| E: libdnlib2.1-cil: portable-executable-missing-security-features 
usr/lib/cli/dnlib-2.1/dnlib.dll SafeSEH
`

The file in question, according to file(1) is a
,
| PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows
`

which contains code that is JIT-compiled by the Mono runtime. In this
context, looking for the x86-specific SafeSEH feature does not make much
sense, does it?

Cheers,
-Hilko

Bug#926316: systemd: Installing the systemd package switches the init system to systemd

[Michael Biebl]

Am 03.04.19 um 18:08 schrieb Felipe Sateler:
> Looks like sysvinit-core needs XB-Important: yes to prevent such easy
> removal.

I though about this too, but on the other hand with "init" we actually
allow users to switch between sysvinit and systemd and adding
XB-Important: yes to sysvinit-core would render "init" moot.

I have to say I'm surprised apt prefers uninstalling a package to
satisfy a Recommends over not installing a Recommends and keeping that
package.


If systemd is the active PID 1, we want libpam-systemd installed
alongside. So far we also considered that users might not have
systemd-sysv installed but instead boot with init=/lib/systemd/systemd.
I have no idea how common that is, so maybe an alternative could be to
move the libpam-systemd Recommends from systemd to systemd-sysv
(alongside the existing libnss-systemd).


WDYT? Is it too late in the release cycle to make such a change?

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



signature.asc
Description: OpenPGP digital signature

Bug#926333: ripgrep: PCRE2 is not available

[Jakub Wilk]

Package: ripgrep
Version: 0.10.0-2
Severity: wishlist

I wanted to use rg with PCREs, but it didn't work:

   $ rg -P foo
   PCRE2 is not available in this build of ripgrep

Please enable PCRE2 support.


-- System Information:
Architecture: i386

Versions of packages ripgrep depends on:
ii  libc62.28-8
ii  libgcc1  1:8.3.0-4

--
Jakub Wilk

Bug#926293: e2fsprogs: Add method to initialize mount count

[Theodore Ts'o]

On Tue, Apr 02, 2019 at 07:43:34PM -0700, Elliott Mitchell wrote:
> Package: e2fsprogs
> Version: 1.43.4-2
> 
> Could `mke2fs` and `tune2fs` get some method to initialize the maximum
> mount count to a non-zero value?
> 
> Having to search for random values to initialize the maximum mount count
> is a bit annoying.  Perhaps a -O init_max_mount_count setting?
> 
> I understand the author's misgivings about all the complaints from people
> annoyed by precautionary checks.  Yet some of us are fine with occasional
> checks.  Meanwhile the time-based checks were just awful.

I suspect the best way forward is to teach tune2fs to be able to
support "tune2fs -c random".  The -O option is only for file system
features that are encoded in feature bitmaps in the ext4 superblock.

However, if you are using LVM, the better way to move forward is to
use e2scrub, which is in e2fsprogs 1.45.0.  That's not going to land
in Debian Buster, since we're in lockdown and the version of e2fsprogs
in Buster is 1.44.5-1.  But realistically, the change that you are
asking for isn't going to be landing any time soon, either.

 - Ted

Bug#926316: systemd: Installing the systemd package switches the init system to systemd

[Felipe Sateler]

On Wed, Apr 3, 2019 at 7:18 AM Emmanuel Bourg  wrote:

> Package: systemd
> Version: 241-1
> Severity: normal
>
> Hi,
>
> The description of the systemd package states that installing it will not
> switch the init system, unfortunately that's what happens, unless systemd
> is installed with --no-install-recommends. It looks like a recommended
> dependency (libpam-systemd?) triggers the removal of sysvinit-core.


> I haven't been able to track exactly why it happens in testing with the
> version 241-1. With the version 241-2 in sid I guess the removal of
> systemd-shim from the alternative dependencies of libpam-systemd [1]
> last week doesn't help.
>
>
> root@sysvinit:~# ps aux
> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME
> COMMAND
> root 1  0.0  0.0   7900  1980 pts/1Ss+  09:29   0:00 init
> [2]
> root   884  0.0  0.1 156188  2412 ?Ssl  09:29   0:00
> /usr/sbin/rsyslogd
> root   912  0.0  0.0   5508  1968 ?Ss   09:29   0:00
> /usr/sbin/cron
> root   940  0.0  0.1   4000  3300 ?Ss   09:29   0:00
> /bin/bash
> root  1237  0.0  0.0   2420  1480 pts/0Ss+  09:31   0:00
> /sbin/getty --noclear 38400 tty1
> root  1238  0.0  0.0   2420  1556 pts/1Ss+  09:31   0:00
> /sbin/getty --noclear 38400 tty2
> root  2269  0.0  0.1   7640  2724 ?R+   09:53   0:00 ps aux
>
> root@sysvinit:~# ls -l /sbin/init
> -rwxr-xr-x 1 root root 53016 Feb 14 20:33 /sbin/init
>
> root@sysvinit:~# apt install systemd
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages were automatically installed and are no longer
> required:
>   initscripts insserv startpar sysv-rc
> Use 'apt autoremove' to remove them.
> The following additional packages will be installed:
>   dbus libargon2-1 libcryptsetup12 libdbus-1-3 libexpat1 libjson-c3
> libnss-systemd libpam-systemd systemd-sysv
> Suggested packages:
>   default-dbus-session-bus | dbus-session-bus systemd-container
> policykit-1
> The following packages will be REMOVED:
>   sysvinit-core
> The following NEW packages will be installed:
>   dbus libargon2-1 libcryptsetup12 libdbus-1-3 libexpat1 libjson-c3
> libnss-systemd libpam-systemd systemd systemd-sysv
> 0 upgraded, 10 newly installed, 1 to remove and 0 not upgraded.
> Need to get 4786 kB of archives.
> After this operation, 16.7 MB of additional disk space will be used.
> Do you want to continue? [Y/n] n
> Abort.
>

Looks like sysvinit-core needs XB-Important: yes to prevent such easy
removal.

-- 

Saludos,
Felipe Sateler

Bug#926328: [Pkg-utopia-maintainers] Bug#926328: network-manager-gnome: nm-applet crashes with a coredump when try to create a new WiFi network

[Michael Biebl]

Am 03.04.19 um 17:15 schrieb Jiang Jun:
> Package: network-manager-gnome
> Version: 1.8.20-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I am experiencing a crash every time I try to create a hot-spot WiFi using nm-
> applet menu. The steps were:
> 
> 1. Click nm-applet(I am using Xfce4 and xfce-panel, BTW), in the drop down
> menu, click Creat New WiFi Network...
> 2. In the pop up window, fill in Network Name and Key.
> 3. In the WiFi security drop down menu, select None or WEP 128bit Passphrase 
> or
> WEP 40/128, doesn't matter, the result will be the same (a crash).
> 4. Click Create. And nm-applet will disappear from the panel Notification 
> Area.
> 
> In journalctl you'll see: https://cfp.vim-cn.com/cbfwN
> 
> 
> And there will be a new coredump in coredumpctl list like:
> 
> Wed 2019-04-03 23:06:44 CST   19318  1000  1000   6 present   /usr/bin/nm-
> applet
> 
> coredumpctl info shows this: https://cfp.vim-cn.com/cbfwP

Please install the dbgsym packages to get a more meaningful backtrace.

https://wiki.debian.org/HowToGetABacktrace
-- 
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#926332: socat: please support SNI

[Benjamin Barenblat]

Package: socat
Version: 1.7.3.2-2
Severity: wishlist
Tags: upstream

socat does not support the TLS Server Name Indication extension. This
extension has become pretty widely deployed at this point, and socat’s
TLS support could be substantially more useful if it sent SNI.

A patch against 1.7.3.0 is available [1]; I’ve also attached it here for
convenience. I haven’t tested or reviewed it, though, so its inclusion
should not be treated as an endorsement. :)

[1] 
https://github.com/moparisthebest/socat/commit/268432bf4220502535dbd373344b60b8fd10e3ce
>From 268432bf4220502535dbd373344b60b8fd10e3ce Mon Sep 17 00:00:00 2001
From: moparisthebest 
Date: Fri, 17 Jul 2015 22:08:00 -0400
Subject: [PATCH 1/1] Add OpenSSL snihost option for TLS SNI extension

---
 doc/socat.yo  |  9 +++--
 xio-openssl.c | 16 +++-
 xio-openssl.h |  2 ++
 xioopts.c |  2 ++
 xioopts.h |  1 +
 5 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/doc/socat.yo b/doc/socat.yo
index 65e9894..18269da 100644
--- a/doc/socat.yo
+++ b/doc/socat.yo
@@ -502,13 +502,15 @@ label(ADDRESS_OPENSSL_CONNECT)dit(bf(tt(OPENSSL::)))
link(openssl-commonname)(OPTION_OPENSSL_COMMONNAME) option.
Socat tries to match it against the certificates subject commonName,
and the certifications extension subjectAltName DNS names. Wildcards in the
-   certificate are supported.nl() 
+   certificate are supported. To specify the TLS SNI hostname to set use the
+   link(snihost)(OPTION_OPENSSL_SNIHOST) option.nl()
Option groups: link(FD)(GROUP_FD),link(SOCKET)(GROUP_SOCKET),link(IP4)(GROUP_IP4),link(IP6)(GROUP_IP6),link(TCP)(GROUP_TCP),link(OPENSSL)(GROUP_OPENSSL),link(RETRY)(GROUP_RETRY) nl()
Useful options:
link(cipher)(OPTION_OPENSSL_CIPHERLIST),
link(method)(OPTION_OPENSSL_METHOD),
link(verify)(OPTION_OPENSSL_VERIFY),
-   link(commonname)(OPTION_OPENSSL_COMMONNAME)
+   link(commonname)(OPTION_OPENSSL_COMMONNAME),
+   link(snihost)(OPTION_OPENSSL_SNIHOST),
link(cafile)(OPTION_OPENSSL_CAFILE),
link(capath)(OPTION_OPENSSL_CAPATH),
link(certificate)(OPTION_OPENSSL_CERTIFICATE),
@@ -2700,6 +2702,9 @@ label(OPTION_OPENSSL_COMMONNAME)dit(bf(tt(commonname=)))
certificates commonname. This option has only meaning when option
link(verify)(OPTION_OPENSSL_VERIFY) is not disabled and the choosen cipher
provides a peer certificate.
+label(OPTION_OPENSSL_SNIHOST)dit(bf(tt(snihost=)))
+   Specify the SNI hostname for the TLS request. The server can use this TLS
+   extension to choose which certificate to send.
 label(OPTION_OPENSSL_FIPS)dit(bf(tt(fips)))
Enables FIPS mode if compiled in. For info about the FIPS encryption
implementation standard see lurl(http://oss-institute.org/fips-faq.html). 
diff --git a/xio-openssl.c b/xio-openssl.c
index 665430d..a04e5bf 100644
--- a/xio-openssl.c
+++ b/xio-openssl.c
@@ -117,6 +117,7 @@ const struct optdesc opt_openssl_compress= { "openssl-compress",   "compress
 const struct optdesc opt_openssl_fips= { "openssl-fips",   "fips",   OPT_OPENSSL_FIPS,GROUP_OPENSSL, PH_SPEC, TYPE_BOOL, OFUNC_SPEC };
 #endif
 const struct optdesc opt_openssl_commonname  = { "openssl-commonname", "cn", OPT_OPENSSL_COMMONNAME,  GROUP_OPENSSL, PH_SPEC, TYPE_STRING,   OFUNC_SPEC };
+const struct optdesc opt_openssl_snihost = { "openssl-snihost",   "snihost", OPT_OPENSSL_SNIHOST, GROUP_OPENSSL, PH_SPEC, TYPE_STRING,   OFUNC_SPEC };
 
 
 /* If FIPS is compiled in, we need to track if the user asked for FIPS mode.
@@ -197,6 +198,7 @@ static int
bool opt_ver = true;	/* verify peer certificate */
char *opt_cert = NULL;	/* file name of client certificate */
const char *opt_commonname = NULL;	/* for checking peer certificate */
+   const char *opt_snihost = NULL;   /* for sni host */
int result;
 
if (!(xioflags & XIO_MAYCONVERT)) {
@@ -226,10 +228,15 @@ static int
 
retropt_string(opts, OPT_OPENSSL_CERTIFICATE, _cert);
retropt_string(opts, OPT_OPENSSL_COMMONNAME, (char **)_commonname);
+   retropt_string(opts, OPT_OPENSSL_SNIHOST, (char **)_snihost);

if (opt_commonname == NULL) {
   opt_commonname = hostname;
}
+   /* could do this, but might not be desired?
+   if (opt_snihost == NULL) {
+  opt_snihost = hostname;
+   } */
 
result =
   _xioopen_openssl_prepare(opts, xfd, false, _ver, opt_cert, );
@@ -289,7 +296,7 @@ static int
 	 return result;
   }
 
-  result = _xioopen_openssl_connect(xfd, opt_ver, opt_commonname, ctx, level);
+  result = _xioopen_openssl_connect(xfd, opt_ver, opt_commonname, opt_snihost, ctx, level);
   switch (result) {
   case STAT_OK: break;
 #if WITH_RETRY
@@ -358,6 +365,7 @@ static int
 int _xioopen_openssl_connect(struct single *xfd,
 			 bool opt_ver,
 			 const char *opt_commonname,
+			 const char *opt_snihost,
 			 SSL_CTX *ctx,
 			 int level) {
SSL *ssl;
@@ -382,6 +390,12 @@ int 

Bug#926331: Source of that warning

[Francois Marier]

It looks like that warning comes from a Debian-specific patch:

  
https://salsa.debian.org/postfix-team/postfix-dev/blob/7fd2e6facc18bbe22829735fc94d6eee7e58fc0f/debian/patches/70_postfix-check.diff#L15

introduced two years ago:

  
https://salsa.debian.org/postfix-team/postfix-dev/commit/1819dbdcd43b9c6c53f81c499101b7b59d371c4a

Francois

-- 
https://fmarier.org/

Bug#923715: [Ceph-maintainers] Bug#923715: Bug#923715: This doesn't make the package unusable

[Paul Emmerich]

> Thomas Goirand :
> 
> On 4/2/19 11:23 PM, Alfredo Deza wrote:
>> 
>> 
>> I would argue that an unusable ceph-volume would make Ceph unusable
>> for most users.

Agree. Virtually no-one will be able to use it.

> If you want to set things up by hand, you may reuse this script too (and
> adapt it to your needs, of course, as this tightly integrates with OCI):
> 
> https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer/blob/debian/stein/bin/oci-make-osd
> 
> Comments on it, or even better, improvements, would be welcome.

I'm sorry, but this script is horrible. Suggested improvement would be 
re-writing it based on
ceph-volume, there is just too much wrong with it.
Just from skimming it:

* no support for nvme disks
* what about servers with more than 26 disks?
* that's not how you should allocate IDs for OSDs, just let ceph handle that
* adding a separate wal/db partition *on the same device* makes no sense
* no support for wal/db on separate disks
* no support for encrypted OSDs
* what happens if you have to move disks between servers?
* the part where you write a ceph.conf entry for each OSD and manually set the 
port particularly horrible

You basically implemented a limited and broken version of ceph-volume yourself 
for no apparent good reason



Paul

Bug#926331: warning: symlink leaves directory: /etc/postfix/./makedefs.out

[Francois Marier]

Package: postfix
Version: 3.4.5-1
Severity: normal

I seem to be getting the following in my logs once a day:

  Apr  3 06:47:05 hostname postfix/postfix-script[8633]: warning: symlink 
leaves directory: /etc/postfix/./makedefs.out
  Apr  3 06:47:05 hostname postfix/postfix-script[8633]: warning: symlink 
leaves directory: /etc/postfix/./makedefs.out
  Apr  3 06:47:05 hostname postfix/postfix-script[8633]: warning: symlink 
leaves directory: /etc/postfix/./makedefs.out

Not sure what that warning means.

Francois

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

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

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.12+dfsg-6
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.6
ii  e2fsprogs  1.45.0-1
ii  libc6  2.28-8
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libicu63   63.1-6
ii  libsasl2-2 2.1.27+dfsg-1
ii  libssl1.1  1.1.1b-1
ii  lsb-base   10.2019031300
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  bsd-mailx [mail-reader]  8.1.2-0.20180807cvs-1
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
ii  mutt [mail-reader]   1.10.1-2
pn  postfix-cdb  
pn  postfix-doc  
pn  postfix-ldap 
pn  postfix-lmdb 
pn  postfix-mysql
pn  postfix-pcre 
pn  postfix-pgsql
pn  postfix-sqlite   
ii  procmail 3.22-26
pn  resolvconf   
pn  ufw  

-- debconf information:
* postfix/root_address: francois
  postfix/kernel_version_warning:
  postfix/mailbox_limit: 0
  postfix/relay_restrictions_warning:
  postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
* postfix/mailname: hostname.dyndns.org
* postfix/chattr: false
  postfix/retry_upgrade_warning:
  postfix/sqlite_warning:
* postfix/relayhost: example.com
  postfix/newaliases: false
* postfix/dynamicmaps_conversion_warning: true
* postfix/compat_conversion_warning: true
  postfix/recipient_delim: +
  postfix/protocols: ipv4
  postfix/bad_recipient_delimiter:
  postfix/lmtp_retired_warning: true
  postfix/mydomain_warning:
  postfix/tlsmgr_upgrade_warning:
  postfix/main_cf_conversion_warning: true
  postfix/procmail: true
  postfix/not_configured:
* postfix/main_mailer_type: Internet with smarthost
  postfix/rfc1035_violation: false
* postfix/destinations: hostname.dyndns.org, hostname, localhost.localdomain, 
localhost

-- 
https://fmarier.org/

Bug#926309: gdm3: gdm-x-session calls Xsession with broken arguments

[Simon McVittie]

Control: found -1 3.30.2-3

On Wed, 03 Apr 2019 at 17:15:15 +0200, Matijs van Zuijlen wrote:
> On 03/04/2019 12:14, Simon McVittie wrote:
> > This is presumably a regression in the gdm3 version in experimental,
> > or a regression in some related GNOME 3.32 component in experimental
> > (maybe gnome-session or similar). buster/sid are hopefully unaffected?
> 
> Oh, I actually only installed the version from experimental because
> reportbug told me to try it. The version in unstable has the same
> problem, I'm afraid.

Marking the bug as found in that version.

(I still have no idea why this would happen.)

smcv

Bug#926327: qgit: Crash on some malformed git repositories

[Andrey Rahmatullin]

Control: tags -1 + upstream

Please forward it to https://github.com/tibirna/qgit/issues, ideally with
instructions how to create such repo.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#926330: RFS: cuba/4.2-1 [ITP]

[Francesco Montanari]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: cuba
  Version : 4.2-1
  Upstream Author : Thomas Hahn 
* URL : http://www.feynarts.de/cuba/
* License : LGPL-3+
  Section : math

It builds those binary packages:

libcuba4 - multidimensional numerical integration -- library package
libcuba-dev - multidimensional numerical integration -- development package
libcuba-doc - multidimensional numerical integration -- documentation 
package

partview - partition viewer for the Cuba library Partview reads Cuba

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


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

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

  dget -ux 
https://mentors.debian.net/debian/pool/main/c/cuba/cuba_4.2-1.dsc


Regards,
 Francesco Montanari

Bug#926287: barbican: FTBFS: TypeError: set_defaults() got an unexpected keyword argument 'vault_approle_role_id'

[Thomas Goirand]

On 4/3/19 12:31 AM, Andreas Beckmann wrote:
> Source: barbican
> Version: 1:8.0.0~rc1-2
> Severity: serious
> Justification: fails to build from source
> 
> Hi,
> 
> barbican/experimental FTBFS with 
> 
> ==
> FAIL: 
> barbican.tests.plugin.test_castellan_secret_store.WhenTestingVaultSecretStore.test_delete_secret_throws_key_error
> barbican.tests.plugin.test_castellan_secret_store.WhenTestingVaultSecretStore.test_delete_secret_throws_key_error
> --
> _StringException: Traceback (most recent call last):
>   File 
> "/build/barbican-8.0.0~rc1/barbican/tests/plugin/test_castellan_secret_store.py",
>  line 50, in setUp
> self.plugin = vss.VaultSecretStore(self.cfg_mock)
>   File "/build/barbican-8.0.0~rc1/barbican/plugin/vault_secret_store.py", 
> line 65, in __init__
> vault_conf = self.get_conf(conf)
>   File "/build/barbican-8.0.0~rc1/barbican/plugin/vault_secret_store.py", 
> line 86, in get_conf
> vault_use_ssl=conf.vault_plugin.use_ssl
> TypeError: set_defaults() got an unexpected keyword argument 
> 'vault_approle_role_id'
> 
> 
> Andreas

Weird, I couldn't reproduce. Could it be my setup with
--build-dep-resolver=aspcud?

Cheers,

Thomas Goirand (zigo)