Bug#895927: sha256 checksum of output database not reproducible with command line tools

[Hannes von Haugwitz]

tags 895927 + unreproducible
thanks

Hi Marc,

On Tue, Apr 17, 2018 at 04:13:33PM +0200, Marc Haber wrote:
> I would like to verify the database mentioned in aide output before
> copying it over to the input database name. That does not seem to work:
> 
> [19/5003]mh@ivanova:~ $ ls -al /var/lib/aide/aide.db.new output.aide 
> -rw-rw-r-- 1 mh   mh   2,1M Apr 17 11:36 output.aide
> -rw--- 1 root root  71M Apr 17 11:36 /var/lib/aide/aide.db.new
> [20/5004]mh@ivanova:~ $ grep SHA512 output.aide | tail -n 1
>   SHA512   : LhaYUYpxlUaOFnLffOnCyxm8gq6rwxQW
> [21/5005]mh@ivanova:~ $ sudo openssl sha256 -binary /var/lib/aide/aide.db.new 
> | openssl base64
> rN/Af3eq+dKO6DKmpN1XOs+vpH6IQ3qFrELjhslp1Qs=
> [22/5006]mh@ivanova:~ $ sudo zcat /var/lib/aide/aide.db.new | openssl sha256 
> -binary | openssl base64
> 5uIy2b4L4ckKlzZ6o5UMlePKyKdRR8u/YhgciUQlFWg=
> [23/5007]mh@ivanova:~ $ 
> 
> What am I supposed to do with aide.db.new if I want the sha256 (or other) 
> checksums to match aide's own output?

First please note that the checksums in the report are wrapped to
multiple lines. Apart from that you seem to grep for sha512 checksum in
the output of AIDE but compute the sha256 checksum of the database file.

I got the following output for my last AIDE run:

# grep -A2 SHA512 /var/log/aide/aide.log | tail -n 3
  SHA512   : xCCa+gNpk4/A70vpUDcj07ghhg2v5W5x
 7oV+U7qaM1db1CaMdt0G8ew3WSgoHWc5
 W3C2FVzT4V95mGXpL0Rfig==
# zcat /var/lib/aide/aide.db | openssl sha512 -binary | openssl base64
xCCa+gNpk4/A70vpUDcj07ghhg2v5W5x7oV+U7qaM1db1CaMdt0G8ew3WSgoHWc5
W3C2FVzT4V95mGXpL0Rfig==

If that solves your issue please close this bug report.

Best regards

Hannes

Bug#922502: plasma-desktop: regional settings allow do select system incompatible locales

[Charlemagne Lasse]

Package: plasma-desktop
Version: 4:5.14.5-1
Severity: critical
Justification: makes unrelated software break on the system

The "regional settings" allow to select various regions which are not
available on the system (even with locales-all). An example here is
en_DE (Germany) for "Time". This is then exported at the next login in
the env variable LC_TIME as "en_DE.UTF-8". This is not supported on
any Debian buster installation and is causing other software to break.

Here an example of me trying to install tex-common under the
environment created by the plasma desktop:

sudo aptitude reinstall tex-common
Warning: Invalid locale (please review locale settings, this might
lead to problems later):
  locale::facet::_S_create_c_locale name not valid
The following packages will be REINSTALLED:
  tex-common
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and
33 not upgraded.
Need to get 53.0 kB of archives. After unpacking 0 B will be used.
Get: 1 http://ftp.de.debian.org/debian buster/main amd64 tex-common
all 6.10 [53.0 kB]
Fetched 53.0 kB in 1s (105 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
apt-listchanges: Can't set locale; make sure $LC_* and $LANG are correct!
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 21 files and directories currently installed.)
Preparing to unpack .../tex-common_6.10_all.deb ...
Unpacking tex-common (6.10) over (6.10) ...
Setting up tex-common (6.10) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.kwturaob
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess
returned error exit status 1
Processing triggers for man-db (2.8.5-1) ...
Errors were encountered while processing:
 tex-common
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up tex-common (6.10) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.oXxMEBqv
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
 tex-common





sudo cat /tmp/fmtutil.oXxMEBqv
fmtutil: fmtutil is using the 

Bug#922508: prosody-modules: please add mod_onions

[Sandro Knauß]

Package: prosody-modules
Version: 0.0~hg20190203.b54e98d5c4a1+dfsg-1
Severity: wishlist

please add mod_onions, which allows to serve XMPP via tor see:
https://modules.prosody.im/mod_onions.html

hefee

Bug#919638: solr-tomcat: Permission problems after update to tomcat9

[Markus Koschany]

Control: reassign -1 src:tomcat9

Am 17.02.19 um 06:58 schrieb Michael Welsh Duggan:
[...]
> Based on your prior tip, I had already done that.  (Only the
> /var/lib/solr/ entry seemed to be necessary.)  This caused things to
> work again.

Thank you for the confirmation. Then I think reassigning this issue to
src:tomcat9 and fixing it there is sensible.



signature.asc
Description: OpenPGP digital signature

Bug#922213: Bug#922500: tex-common: Fails to install with LC_TIME=en_DE.UTF-8

[Charlemagne Lasse]

> On Sun, 17 Feb 2019, Charlemagne Lasse wrote:
> > perl: warning: Setting locale failed.
> > perl: warning: Please check that your locale settings:
> > LANGUAGE = "en_US:en",
> > LC_ALL = (unset),
> > LC_TIME = "en_DE.UTF-8",
> > LANG = "C"
> > are supported and installed on your system.
>
> > locale: Cannot set LC_ALL to default locale: No such file or directory
>
> You have a broken locale setup, there is nothing we can do. luatex needs
> correctly setup locales, but they are not.

But the installation of tex-common should not fail because of this. It
works fine when LC_TIME is not set to C or en_US.UTF-8 and so on
(everything which locales-all provides).

If the installation of a package fails because a user set locale is
wrong then something is terrible broken with your installation
process. I understand that it may fail when the user calls luatex
manually with some incorrect env but not when the installation process
is run.

Setup/Installation happens in the system context. But now you are
telling me that something in the user context is allowed to break the
installation. Nothing in the users env should change the way how the
package installation process behaves. We have /etc for that - not the
user specific env.

What would you say when you swedish system administrator installs
package xyz and suddenly all english-only speaking users of the system
have to deal with a swedish-only installation of xyz - even when the
swedish system admin never explicitly said that a swedish-only version
should be installed? Sounds wrong, correct?

It is a little bit like farting in the face of the reproducible build
folks. Cool, we removed all the non-reproducible behavior in the build
process - lets move all the reproducibility problems in the
installation process.

Maybe the package is assigned incorrectly in this ticket and
dpkg/aptitude/... should sanitize the env. But the ticket should not
be closed so easily.

It is not like I sat down and broke the package on purpose. I just
selected some good looking regional settings in KDE plasma. And
suddenly my texlive installation doesn't work anymore. Not something
which you would expect.

Bug#922507: wml: Missing depends on libgd-perl

[Kurt Roeckx]

Package: wml
Version: 2.12.2~ds1-1
Severity: serious

Hi,

I'm getting the following error:
Can't locate GD.pm in @INC (you may need to install the GD module) (@INC 
contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 
/usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 
/usr/local/lib/site_perl) at /tmp/wml.28518.tmp1 line 197.
BEGIN failed--compilation aborted at /tmp/wml.28518.tmp1 line 197.

It seems that this was part of wml in older versions, but not in
the current version.


Kurt

Bug#922509: security issue in PEP plugin (CVE-2019-1000021)

[W. Martin Borgert]

Source: slixmpp
Version: 1.2.2-1.1
Severity: grave
Tags: security patch upstream

See
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-121
for details. A fixed version for stretch-security is on its way.

Bug#922386: VICE Commodore 8bit emulator does not play sound

[Cambays Water]

Control: tags -1 +moreinfo

On Fri, Feb 15, 2019 at 11:33 AM Cambays Water  wrote:
> Vice seems to need package libmp3lame0 in order to play sound.
 It should _not_ as it's an mp3 encoding library and not a sound player.

> I also had to issue this command:
>
> ln -s /usr/lib/x86_64-linux-gnu/libmp3lame.so.0.0.0
> /usr/lib/x86_64-linux-gnu/libmp3lame.so
>
> because it searches for libmp3lame.so
 This is strange. I also have an amd64 type of machine and x64 can
find and open libmp3lame.so.0 on my system.


It seems you are right; I deleted the soft link, started x128 & x64 and 
sound was still available. I just got this error message on the console:


opening dynamic library libmp3lame.so failed!
ERROR setting up dynamic lame lib!



> After making the link sound was available.
 Which emulator did you try? Do you see "Sound: Available sound
devices: ..." line in the output of your emulator and what does it
contain?


I tried x128, x64, xplus4.

From the console:
Sound: Available sound devices: pulse alsa uss dummy fs dump wav voc iff 
aiff mp3 soundmovie




Do you also see "Sound: Opened device ..." in the emulator output?


Sound: Opened device `alsa', speed 44100Hz, fragment size 21,3ms, buffer 
size 106ms




Also interested about your setting, please run:
$ grep SoundDeviceName ~/.config/vice/vicerc


SoundDeviceName="alsa"
SoundDeviceName="alsa"
SoundDeviceName="alsa"
SoundDeviceName="alsa"
SoundDeviceName="alsa"
SoundDeviceName="alsa"

As you see from the result, I have tried the setting for all emulators.

Let me explain the full scenario: My system is a Debian Buster, updated 
from Stretch. ALSA only system. After updating I initially had no sound 
on VICE, tried to copy the old vicerc file, later started with new 
configuration. Still no sound. When the emulator started (whether x128, 
x64 or xplus4) it showed a message about not able to open pulse 
(apparently the default sound choice). The problem was that I could not 
even check the Settings menu -> audio settings -> enable sound playback 
tick, in order to enable sound and the change to ALSA. I also tried 
editing vicerc and setting ALSA and enable sound manually, still I 
didn't have sound.
After looking at the console messages about liblame and adding the soft 
link on my system, I could check Settings menu -> audio settings -> 
enable sound playback. So I supposed that was the solution. Apparently 
not, since deleting the soft link sound is still available and the menu 
accessible.
I can't tell what affected my access on Settings menu -> audio settings 
-> enable sound playback setting.

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable

[Reco]

Hi all.

I'd like to add that plain armmp (non-lpae) is broken too.
At least for Armada385/Caiman and QEMU's virt.

Reco

Bug#922513: capstone: Block from entering testing

[Hilko Bengen]

Source: capstone
Version: 3.0.5-4
Severity: grave

I recently uploaded the capstone4 as a separate source package, assuming
that this would not have consequences in testing. As I was told on
#debian-release, that is not the case because the capstone4 package
takes over python-capstone, python3-capstone, capstone-tool and a
subsequent capstone migration to testing would cause removal of those
binary packages from testing.

This bug is intended to prevent such a migration.

Bug#915298: gdebi FTBFS with pyflakes 2.0.0-1

[Andrey Rahmatullin]

Here is the actual pyflakes3 output:

./gdebi-kde:92: local variable 'e' is assigned to but never used
./gdebi-gtk:80: local variable 'e' is assigned to but never used
./GDebi/KDEAptDialogs.py:147: local variable 'e' is assigned to but never used
./GDebi/GDebiKDE.py:363: local variable 'msg' is assigned to but never used
./GDebi/GDebiGtk.py:69: local variable 'e' is assigned to but never used
gdebi-gtk:80: local variable 'e' is assigned to but never used
gdebi-kde:92: local variable 'e' is assigned to but never used

I don't think aborting on non-empty pyflakes output, just like compiling
with -Werror, should be a part of a Debian package build.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#909856: [Pkg-owncloud-maintainers] Bug#909856: owncloud-client: Build against libsecret

[Sandro Knauß]

Control: reassign -1 libqt5keychain1 0.9.1-1
Control: forcemerge 909588 -1

Hey,

the bug is inside qtkeychain and not in owncloud-client.

Regards,

hefee

--
On Samstag, 26. Januar 2019 11:36:46 CET Thomas Maaß wrote:
> Source: owncloud-client
> Followup-For: Bug #909856
> 
> Dear Maintainer,
> 
> I can only confirm, that the problem is solved when building with libsecret
> installed.
> I checked it by rebuilding the owncloud-client package.
> I also built the nextcloud-client package, which is still not in Debian,
> from sources.
> It has exactly the same behaviour.
> 
> Regards
> Thomas



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

Bug#922503: closed by Samuel Thibault (Re: Bug#922503: espeakup 0.80+deb9u3 is damaged)

[Samuel Thibault]

Hello,

Fran Torres, le dim. 17 févr. 2019 11:15:43 +0100, a ecrit:
> on the espeakup package was disapear the error on log
> and apear other error.

I believe that's just a deprecation warning.

Samuel

Bug#922510: galternatives: [INTL:de] Updated German translation

[Chris Leick]

Package: galternatives
Version: 1.0.3
Severity: wishlist
Tags: l10n patch



Hi,

please find attached the newest German translation.

Kind regards,
Chris


de.po.gz
Description: application/gzip

Bug#922511: pkg-config-references-unknown-shared-library false positive when using variables

[Faidon Liambotis]

Package: lintian
Version: 2.7.0
Severity: normal

Hi there,

jemalloc's pc has this:
  [...]
  install_suffix=
  [...]
  Libs: -L${libdir} -ljemalloc${install_suffix}

(install_suffix is autoconf-interpolated at build time, so there is a
reason it exists despite being purposefully empty in Debian)

pkg-config seems entirely happy with that, but lintian complains:
 W: libjemalloc-dev: pkg-config-references-unknown-shared-library
usr/lib/x86_64-linux-gnu/pkgconfig/jemalloc.pc
-ljemalloc${install_suffix} (line 12)

I'm far from a pkg-config or lintian expert, but I think this is a false
positive, resulting from lintian's inability to interpolate pkg-config
variables before its check.

Regards,
Faidon

Bug#921803: python-scrapy: FTBFS randomly (failing tests)

[Santiago Vila]

retitle 921803 python-scrapy: FTBFS randomly (failing tests)
severity 921803 important
thanks

On Sun, Feb 17, 2019 at 02:37:42PM +0500, Andrey Rahmatullin wrote:
> I cannot reproduce this on the current sid chroot.
> Unfortunately the log excerpt in the bug is not helpful and I couldn't
> access the RB website.

Sorry, I initially believed this was an "always-FTBFS bug" but I was wrong.

The failure is really random, so to reproduce you will have to try
several times. I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/python-scrapy/

Please contact me privately and I will try to give you access
to a machine where this failure (randomly) happens, so that
you can reproduce it as well.

Thanks.

Bug#904462: RFS: uefitool/0.25.1-1 [ITP]

[Yangfl]

Andrey Rahmatullin  于2019年2月17日周日 下午6:42写道：
>
> Control: owner -1 !
>
> Please upgrade to the new upstream version and the new packaging
> standards and I'll sponsor it.
>
> --
> WBR, wRAR

Updated. Thank you.

Bug#922514: release.debian.org: RM: capstone4/4.0.1-2

[Hilko Bengen]

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

Please remove the capstone4 package from unstable.

I recently uploaded the capstone4 as a separate source package, assuming
that this would not have consequences in testing. As I was told on
#debian-release, that is not the case because the capstone4 package
takes over python-capstone, python3-capstone, capstone-tool and a
subsequent capstone migration to testing would cause removal of those
binary packages from testing.

Cheers,
-Hilko

Bug#877202: Bug #877202 in pyxdg marked as pending

[Simon McVittie]

On Thu, 14 Feb 2019 at 11:02:33 +, Simon McVittie wrote:
> Alternatively, uploading a version closely resembling the one in Ubuntu
> would be a low-risk option with a minimal fix for this bug.

For now I've done this, on a new debian/buster branch, and merged that
branch into master.

smcv

Bug#834331: test code fails and ignored for ibus

[Osamu Aoki]

Hi,

On Sun, Feb 17, 2019 at 11:02:45AM +, Simon McVittie wrote:
> On Sun, 17 Feb 2019 at 15:44:07 +0900, Osamu Aoki wrote:
> > ./runtest: 113: ./runtest: pushd: not found
> 
> pushd is a bash feature (a "bashism"). If runtest needs to use it,
> then it should be a #!/bin/bash script, not a #!/bin/sh script.

Thanks for good catch.

ibus being Developed by RH people under FEDORA etc., #!/bin/sh may be
BASH.  I see.

autogen.sh:#!/bin/sh
debian/ibus.prerm:#!/bin/sh
debian/ibus.postrm:#!/bin/sh
debian/ibus-doc.preinst:#!/bin/sh
debian/ibus.postinst:#!/bin/sh
docs/reference/ibus/Makefile.in:$(AM_V_GEN)echo "#!/bin/sh -e" > $@; \
gtk-doc.make:   $(AM_V_GEN)echo "#!/bin/sh -e" > $@; \
install-sh:#!/bin/sh
ltmain.sh:#   #!/bin/sh
py-compile:#!/bin/sh
setup/ibus-setup.in:#!/bin/sh
src/tests/runtest:#!/bin/sh

Hmmm... src/tests/runtest:#!/bin/sh is the only causality ...  

Let me patch it to see...

> > NOT FOUNND ibus-memconf. Need configure --enable-memconf
> 
> It looks as though the tests rely on an optional feature that the Debian
> package doesn't enable.

Yah... this is what I was thinking.  debian/rules can be adjusted  ...
I will try to build with --enable-memconf to see whast it produces.

Thanks.

Osamu

Bug#911859: Seems to be

[John Talbut]

I found that the setting:
"Use SQL-92 naming constraints"
in Edit > Database > Advanced settings" was set.  I unset it and the
problem seems to be resolved.

Is this a new setting that defaults to being set?  Or a setting that has
been changed to default to set?

I suppose I could have inadvertently set it, but I don't know how as
these are not settings that I am not aware of ever having changed.

John

Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Vincent Lefevre]

On 2019-02-17 14:13:45 +0300, Sergey B Kirpichev wrote:
> On Sat, 22 Dec 2018 03:17:27 +0100 Vincent Lefevre  wrote:
> > So, it seems to be a bug in the monit code that makes it think that
> > the link is up while it is not.
> > 
> > In validate.c, I see:
> > 
> > [...]
> > for (LinkStatus_T link = s->linkstatuslist; link; link = 
> > link->next) {
> > Event_post(s, Event_Link, State_Succeeded, link->action, 
> > "link data collection succeeded");
> > }
> > // State
> > if (! Link_getState(s->inf.net->stats)) {
> > for (LinkStatus_T link = s->linkstatuslist; link; link = 
> > link->next)
> > Event_post(s, Event_Link, State_Failed, 
> > link->action, "link down");
> > return State_Failed; // Terminate test if the link is down
> > } else {
> > for (LinkStatus_T link = s->linkstatuslist; link; link = 
> > link->next)
> > Event_post(s, Event_Link, State_Succeeded, 
> > link->action, "link up");
> 
> Ok, CC upstream to see their opinion (I think this problem wasn't reported 
> yet.)

According to my mail archives, 1:5.25.1-1 was fine, and 1:5.25.2-1
has the bug.

So I suspect that it is the following commit that introduced the bug:

diff --git a/src/validate.c b/src/validate.c
index a2fd520..f5e630b 100644
--- a/src/validate.c
+++ b/src/validate.c
@@ -1751,7 +1751,7 @@ State_Type check_net(Service_T s) {
 if (! havedata)
 return State_Failed; // Terminate test if no data are available
 for (LinkStatus_T link = s->linkstatuslist; link; link = link->next) {
-Event_post(s, Event_Size, State_Succeeded, link->action, "link 
data collection succeeded");
+Event_post(s, Event_Link, State_Succeeded, link->action, "link 
data collection succeeded");
 }
 // State
 if (! Link_getState(s->inf.net->stats)) {

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

Bug#739636: postfix: Exagerated error on authentication server connexion issue

[Samuel Thibault]

Control: reopen -1
Control: reassign -1 dovecot
Control: retitle -1 dovecot: should provide a way for exim to know that an 
authentication error is temporary

Scott Kitterman, le dim. 17 févr. 2019 03:42:14 -0500, a ecrit:
> On Tue, 23 May 2017 09:52:14 +0200 Samuel Thibault  
> wrote:
> > Scott Kitterman, on mar. 23 mai 2017 01:25:06 -0400, wrote:
> > > > Feb 20 18:22:41 toccata postfix/smtpd[2465]: warning: 
> > > unknown[12.216.224.110]: SASL PLAIN authentication failed: Connection 
> > > lost 
> to 
> > > authentication server
> > > 
> > > How would postfix know an authentication failure is temporary?
> > 
> > Well, perhaps it's sasl which needs to be able to report differently to
> > postfix, then.
> > 
> > > Also, in this case do MUAs treat temporary and permanent errors
> > > differently (if they don't this doesn't matter)?
> > 
> > Yes.
> 
> I don't think this is a postfix bug, so closing.

Err, well, let's rather reassign the bug that scratching it, it poses
problem to us on each mysql upgrade, potentially losing mail each time.

Samuel

Bug#922504: socket-activate: FTBFS in sid (failing tests)

[Santiago Vila]

Package: src:socket-activate
Version: 0.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid but it failed:


[...]
 debian/rules binary-indep
dh binary-indep
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
   dh_auto_build -i
make -j1 "INSTALL=install --strip-program=true"
make[1]: Entering directory '/<>'
pandoc -s -t man -o socket-activate.1 socket-activate.md
make[1]: Leaving directory '/<>'
   dh_auto_test -i
make -j1 check
make[1]: Entering directory '/<>'
SOCKET_ACTIVATE=/<>/socket-activate ./tests/basic
env: '/<>/socket-activate': No such file or directory
2019/02/17 09:32:10 socat[13787] E connect(5, AF=1 
"/<>/tests/sock", 62): No such file or directory
make[1]: *** [Makefile:14: check] Error 1
make[1]: Leaving directory '/<>'
dh_auto_test: make -j1 check returned exit code 2
make: *** [debian/rules:4: binary-indep] Error 2
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A" and it fails 
every time.

I'm using sbuild + schroot. If for whatever reason you could not reproduce 
this, please
contact me privately and I will gladly offer ssh access to a test machine where 
this
happens all the time.

Thanks.

Bug#922505: Please relax the dependencies of lxqt-branding-debian

[Jordi Pujol]

Package: lxqt-branding-debian
Version: 0.14.0.2
Severity: normal

Hello,

The dependencies of this new package are demanding 150MB of disk
space. However, the lxqt environment worked well without them before.
Consider that lxqt-core not really depends on it, and
lxqt-branding-debian may be only recommended.
Also there is one possibility that not all icon packages are needed
for lxqt-branding-debian and some of the dependencies may be
transformed in recommendations.

Thanks,

Jordi Pujol

Bug#921790: liquidsoap: FTBFS (ld: cannot find -lexif)

[Andrey Rahmatullin]

On Sat, Feb 09, 2019 at 12:15:34AM +, Santiago Vila wrote:
> OCAMLOPT -o liquidsoap
> /usr/bin/ld: cannot find -lexif
libexif-dev is indeed not installed but my build fails even earlier:

OCAMLOPT -c tools/file_watcher.ml
OCAMLOPT -c tools/file_watcher_mtime.ml
OCAMLOPT -c configure.mli
OCAMLOPT -c configure.ml
File "configure.ml", line 25, characters 11-32:
Error: Unbound module Camomile
make[4]: *** [../Makefile.rules:193: configure.cmx] Error 2
make[4]: Leaving directory '/<>/src'


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#922506: [libvirt0] lxc: internal error: child reported (status=125): Kernel does not provide mount namespace: No such file or directory

[Dirk Heinrichs]

Package: libvirt0
Version: 5.0.0-1
Severity: normal

--- Please enter the report below this line. ---
I currently see above error when I try to stop an LXC container running
under libvirtd using

   # virsh --connect lxc:///system shutdown myContainer
   error: Failed to shutdown domain myContainer
   error: internal error: child reported (status=125): Kernel does not
   provide mount namespace: Datei oder Verzeichnis nicht gefunden

   --- System information. ---
   Architecture: 
   Kernel:   Linux 4.19.0-2-amd64

   Debian Release: buster/sid
 500 testing vwakviie2ienjx6t.onion

   --- Package information. ---
   Depends (Version) | Installed
   =-+-===
   libacl1 (>= 2.2.51-8) | 2.2.52-3+b1
   libapparmor1   (>= 2.6~devel) | 2.13.2-7
   libaudit1(>= 1:2.2.1) | 1:2.8.4-2
   libavahi-client3  (>= 0.6.16) | 0.7-4+b1
   libavahi-common3  (>= 0.6.16) | 0.7-4+b1
   libc6   (>= 2.17) | 
   libcap-ng0 (>= 0.7.9) | 
   libcurl3-gnutls   (>= 7.28.0) | 
   libdbus-1-3   (>= 1.9.14) | 
   libdevmapper1.02.1 (>= 2:1.02.97) | 
   libgcc1  (>= 1:3.3.1) | 
   libgnutls30(>= 3.6.5) | 
   libnl-3-200(>= 3.2.7) | 
   libnl-route-3-200  (>= 3.2.7) | 
   libnuma1  (>= 2.0.11) | 
   libsasl2-2| 
   libselinux1   (>= 2.1.12) | 
   libssh2-1  (>= 1.2.8) | 
   libxml2(>= 2.7.4) | 
   libyajl2   (>= 2.0.4) | 


   Recommends  (Version) | Installed
   =-+-===
   lvm2  | 


   Package's Suggests field is empty.

   Bye...

Dirk
   -- 
   Dirk Heinrichs
   GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
   Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de 


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

Bug#904462: RFS: uefitool/0.25.1-1 [ITP]

[Andrey Rahmatullin]

Control: owner -1 !

Please upgrade to the new upstream version and the new packaging
standards and I'll sponsor it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#922512: minissdpd: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: minissdpd
Version: 1.5.20180223-6
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for minissdpd's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


minissdpd_1.5.20180223-6_pt.po.gz
Description: application/gzip

Bug#922502: plasma-desktop: regional settings allow do select system incompatible locales

[Charlemagne Lasse]

See also https://bugs.debian.org/922500

Bug#922503: closed by Samuel Thibault (Re: Bug#922503: espeakup 0.80+deb9u3 is damaged)

[Fran Torres]

Hello,

after add the /bin/ before sh -c, the dpkg was configured the rest of
packages but, on the espeakup package was disapear the error on log
and apear other error. In this case, i'm not capable found the
problem. I add you a log (syslog, espeakup.service and output of apt)
in a unique log for can solve

Fran.
PD: the log are atached in another message

2019-02-17 10:39 GMT+01:00, Debian Bug Tracking System :
> This is an automatic notification regarding your Bug report
> which was filed against the espeakup package:
>
> #922503: espeakup 0.80+deb9u3 is damaged
>
> It has been closed by Samuel Thibault .
>
> 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 Samuel Thibault
>  by
> replying to this email.
>
>
> --
> 922503: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922503
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#896468: [Pkg-javascript-devel] Bug#896468: Bug#896468: libjs-chartjs: Please upload newer versions

[Pirate Praveen]

On Sun, Feb 17, 2019 at 2:47 AM, Paul Gevers  wrote:

Hi,

On 15-02-2019 07:46, Pirate Praveen wrote:

 Thanks Jonas for the confirmation. I have uploaded 2.7.3 to
 experimental. Since browserify is not available in the archive, I 
have
 used rollup to build the umd bundle. Please review, test and 
confirm if

 it is working as expected and I can upload to unstable.


I must admit that I don't know how to program in JavaScript, but if I
compare the upstream version of 2.7.3 [1] with the one in 
experimental,

I am missing already the first function that I see upstream, i.e.
getRgba().

I expect that is not ok, no?



Thanks Paul for testing. The missing dependencies were treated as 
external dependencies by rollup (webpack would give an error), would 
have worked in node, but not in browser. I embedded the missing 
dependencies and also used rollup-plugin-node-resolve to include all 
dependencies in the bundle. So please test 2.7.3+dfsg-2 and confirm if 
it is working as expected (for gitlab, I still don't use the packaged 
version, so can't really test now).


I can now see 'function getRgba(string) {' in the built bundle.

Also the file looks quite different, but I guess that is to be 
expected

due to build system differences.


As long as it is working as expected, the exact match is not required. 
Each build tool has their on signature styles for bundling.

Bug#922486: python3-sbml5: libsbml fails to import

[Liubov Chuprikova]

Hi Andreas,

On Sat, 16 Feb 2019 at 22:43, Andreas Tille  wrote:

>
> If you see any chance to hunt this issue in libsbml down this would be
> really welcome.


I would like to fix this if I have time in the following week. I can't say
right now.

JFI: Just looking onto the files installed with the package, there is no
__init__.py
in the installation directory. So the question is whether it hasn't
generated during
the build or it just hasn't installed properly.

I'm busy with real life this weekend.
>

This is awesome! Have a nice weekend!

__
Liubov

Bug#922500: tex-common: Fails to install with LC_TIME=en_DE.UTF-8

[Charlemagne Lasse]

Package: tex-common
Version: 6.10
Severity: serious
Justification: Fails to install on a normal KDE installation with
"Germany" setting as Time localization

The installation works fine with LC_TIME=C but not with the setting
generated by KDE LC_TIME=en_DE.UTF-8. The aptitude output follows and
at the end the log file content mentioned in the aptitude output

sudo LC_TIME=en_DE.UTF-8 aptitude reinstall tex-common
Warning: Invalid locale (please review locale settings, this might
lead to problems later):
  locale::facet::_S_create_c_locale name not valid
The following packages will be REINSTALLED:
  tex-common
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and
33 not upgraded.
Need to get 53.0 kB of archives. After unpacking 0 B will be used.
Get: 1 http://ftp.de.debian.org/debian buster/main amd64 tex-common
all 6.10 [53.0 kB]
Fetched 53.0 kB in 1s (105 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
apt-listchanges: Can't set locale; make sure $LC_* and $LANG are correct!
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 21 files and directories currently installed.)
Preparing to unpack .../tex-common_6.10_all.deb ...
Unpacking tex-common (6.10) over (6.10) ...
Setting up tex-common (6.10) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.kwturaob
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess
returned error exit status 1
Processing triggers for man-db (2.8.5-1) ...
Errors were encountered while processing:
 tex-common
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up tex-common (6.10) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.oXxMEBqv
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
 tex-common














sudo cat /tmp/fmtutil.oXxMEBqv
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the 

Bug#922501: ERROR: No runner implements step with keys grub, root-part, device, console, root-fs

[Martin Pitt]

Package: vmdb2
Version: 0.13.2+git20190215-1

I'm trying to build a stretch VM image using autopkgtest's tool:

   autopkgtest-build-qemu  stretch /tmp/autopkgtest-stretch-amd64.qcow2

which under the hood calls

   vmdb2 --verbose --image=/tmp/autopkgtest-stretch-amd64.qcow2.raw /tmp/config

I'm attaching /tmp/config here for reference (in reality it's a temporary
random file name, of course).

This immediately fails with

  Load spec file /tmp/config
  ERROR: No runner implements step with keys grub, root-part, device, console, 
root-fs

This happens in a relatively small sid schroot, so there are no packages like
grub etc. installed. I did try to install grub2, but it doesn't make a
difference.

Apparently there are some missing dependencies/recommends here?

Thanks,

Martin
steps:
  - mkimg: "{{ image }}"
size: 20G

  - mklabel: msdos
device: "{{ image }}"

  - mkpart: primary
device: "{{ image }}"
start: 0%
end: 100%
part-tag: root-part

  - mkfs: ext4
partition: root-part

  - mount: root-part
fs-tag: root-fs

  - debootstrap: stretch
mirror: http://deb.debian.org/debian
target: root-fs

  - apt: install
packages:
  - linux-image-amd64
  - ifupdown
fs-tag: root-fs

  - chroot: root-fs
shell: |
  passwd --delete root
  useradd --home-dir /home/user --create-home user
  passwd --delete user
  echo host > /etc/hostname
  echo '/dev/sda1 / ext4 errors=remount-ro 0 1' > /etc/fstab

  - grub: bios
root-fs: root-fs
root-part: root-part
device: "{{ image }}"
console: serial

  - mount-virtual-filesystems: root-fs

  - shell: 'debian/autopkgtest/setup-commands/setup-testbed $ROOT'
root-fs: root-fs

  - shell: '/bin/true $ROOT'
root-fs: root-fs

Bug#922489: qtkeychain: relies on existence of libsecret-1.so -dev symlink

[Sandro Knauß]

Control: Forwarded -1 https://github.com/frankosterfeld/qtkeychain/pull/139

Hey,

thanks for the fast reply, that gave me the right direction to search for the 
bugfix.

> I think this is a qtkeychain bug. This code that appears to be responsible
> for dlopen()ing libsecret:
> 
> LibSecretKeyring::LibSecretKeyring()
> 
> : QLibrary("secret-1")
> 
> doesn't mention the ABI version, so it could equally easily end up loading
> an incompatible future library libsecret-1.so.1 or libsecret-1.so.27,
> and then crashing when it calls a function by assuming that it has the
> same ABI as the corresponding function in libsecret-1.so.0.

This was the bug, that there is no version added to QLibrary. Actually all 
other libraries have a abiversion defined. I added a patch upstream to fix this.

> I haven't programmed against Qt for years, but the documentation
> suggest that it should probably inherit from QLibrary("secret-1", 0)
> as described at ,
> so that Qt will specifically load libsecret-1.so.0 on Unix platforms.

Interestingly that noone stumbled over this bug before...

hefee

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

Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Sergey B Kirpichev]

tags 902204 -moreinfo
thanks

On Sat, 22 Dec 2018 03:17:27 +0100 Vincent Lefevre  wrote:
> So, it seems to be a bug in the monit code that makes it think that
> the link is up while it is not.
> 
> In validate.c, I see:
> 
> [...]
> for (LinkStatus_T link = s->linkstatuslist; link; link = link->next) {
> Event_post(s, Event_Link, State_Succeeded, link->action, 
> "link data collection succeeded");
> }
> // State
> if (! Link_getState(s->inf.net->stats)) {
> for (LinkStatus_T link = s->linkstatuslist; link; link = 
> link->next)
> Event_post(s, Event_Link, State_Failed, link->action, 
> "link down");
> return State_Failed; // Terminate test if the link is down
> } else {
> for (LinkStatus_T link = s->linkstatuslist; link; link = 
> link->next)
> Event_post(s, Event_Link, State_Succeeded, 
> link->action, "link up");

Ok, CC upstream to see their opinion (I think this problem wasn't reported yet.)

Bug#921803: python-scrapy: FTBFS (failing tests)

[Andrey Rahmatullin]

I cannot reproduce this on the current sid chroot.
Unfortunately the log excerpt in the bug is not helpful and I couldn't
access the RB website.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#834331: test code fails and ignored for ibus

[Simon McVittie]

On Sun, 17 Feb 2019 at 15:44:07 +0900, Osamu Aoki wrote:
> ./runtest: 113: ./runtest: pushd: not found

pushd is a bash feature (a "bashism"). If runtest needs to use it,
then it should be a #!/bin/bash script, not a #!/bin/sh script.

> NOT FOUNND ibus-memconf. Need configure --enable-memconf

It looks as though the tests rely on an optional feature that the Debian
package doesn't enable.

smcv

Bug#921573: lintian: binary-from-other-architecture only works sometimes

[Mattia Rizzolo]

On Thu, Feb 07, 2019 at 04:52:26PM +0100, Chris Lamb wrote:
> You don't still have it, so no worries. I don't get what the big
> deal is. :)

For the advantage of everybody, here are links to the cross-builds from
amd64 to mips64el and arm64 of procmail.

just dget this url (which is more convenint than attachment to the BTS…)

https://volatile.mapreri.org/2019-02-17/4cd8a58f48ab2d24e9b9387df580de93/procmail_3.22-26_arm64.changes
https://volatile.mapreri.org/2019-02-17/130da1c8cbfd405daeb1a7d0a51f536d/procmail_3.22-26_mips64el.changes

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#922520: libiio: please make the documentation reproducible

[Chris Lamb]

Source: libiio
Version: 0.16-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that libiio could not be build its documention reproducibly.

Patch attached, although the binaries themselves remain unreproducible
alas.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2019-02-17 17:31:13.329110362 
+0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2019-02-17
+
+--- libiio-0.16.orig/Doxyfile.in
 libiio-0.16/Doxyfile.in
+@@ -71,7 +71,7 @@ INLINE_INHERITED_MEMB  = NO
+ # shortest path that makes the file name unique will be used
+ # The default value is: YES.
+ 
+-FULL_PATH_NAMES= YES
++FULL_PATH_NAMES= NO
+ 
+ # The STRIP_FROM_PATH tag can be used to strip a user-defined part of the 
path.
+ # Stripping is only done if one of the specified strings matches the left-hand
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2019-02-17 17:31:12.357098608 +0100
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#922525: procps: typo in sysctl.conf

[Nobuhiro Ban]

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

Dear Maintainer,

I found a (very) small typo in /etc/sysctl.conf.
Please apply this patch to fix.

--- procps/etc/sysctl.conf2018-04-10 20:49:54.0 +0900
+++ sysctl.conf2019-02-17 19:03:21.227782340 +0900
@@ -9,7 +9,7 @@
 # Uncomment the following to stop low-level messages on console
 #kernel.printk = 3 4 1 3

-##3
+###
 # Functions previously found in netbase
 #



Regards,
Nobuhiro Ban

Bug#834053: openjdk-8: java.awt.Font#deriveFont(int style) corrupts font size

[Nobuhiro Ban]

Ping.

Or, should I send this report to upstream?


Regards,
Nobuhiro Ban

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable

[Cyril Brulebois]

Hi folks,

Jürgen Löb  (2019-02-16):
> Package: linux-image-4.9.0-8-armmp-lpae
> Version: 4.9.144-3
> Severity: serious
> 
> Updated my Lamobo R1 board with apt update;apt upgrade
> 
> After the update uboot is struck at "Starting kernel". There is no
> further output after "Starting kernel". Same happens on Bananapi 1
> board. Unfortunately there is no more useful information.
[…]

Summing up, it looks like everybody in cc is confirming the regression
happens between 4.9.130-2 and 4.9.144-3, with and without lpae, on
various boards. Any chance you could check what happens with the
4.9.135-1 intermediary version that can be found on snapshot.debian.org?

  https://snapshot.debian.org/package/linux/4.9.135-1/

This might help narrow it down when the regression happened.

(And please use reply-all so that everyone is kept in the loop.)


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


signature.asc
Description: PGP signature

Bug#922477: postfix: FTBFS under Linux > 4

[Sven Joachim]

On 2019-02-17 15:55 +, Scott Kitterman wrote:

> Can you change:
>
> Linux.[34].*) SYSTYPE=LINUX$RELEASE_MAJOR
>
> to:
>
> Linux.[345].*) SYSTYPE=LINUX$RELEASE_MAJOR
>
> in makedefs and verify it builds and works (just a smoke test is fine)
> with your kernel?

I also had to change src/util/sys_defs.h:

diff --git a/src/util/sys_defs.h b/src/util/sys_defs.h
index f4f53300..6a5da4fe 100644
--- a/src/util/sys_defs.h
+++ b/src/util/sys_defs.h
@@ -748,7 +748,7 @@ extern int initgroups(const char *, int);
  /*
   * LINUX.
   */
-#if defined(LINUX2) || defined(LINUX3) || defined(LINUX4)
+#if defined(LINUX2) || defined(LINUX3) || defined(LINUX4) || defined(LINUX5)
 #define SUPPORTED
 #define UINT32_TYPE	unsigned int
 #define UINT16_TYPE	unsigned short

After that, postfix builds.  And if you receive this mail, it also
works. :-)

> I'm having discussions with upstream about this and
> that would be helpful in moving things forward.

It might be better to use a single SYSTYPE for all current and future
Linux kernels, e.g. like this:

diff --git a/makedefs b/makedefs
index 227fdd54..bd3ab32e 100644
--- a/makedefs
+++ b/makedefs
@@ -546,7 +546,7 @@ EOF
 		: ${SHLIB_ENV="LD_LIBRARY_PATH=`pwd`/lib"}
 		: ${PLUGIN_LD="${CC-gcc} -shared"}
 		;;
-  Linux.[34].*)	SYSTYPE=LINUX$RELEASE_MAJOR
+  Linux.[3456789].*)	SYSTYPE=LINUX3
 		case "$CCARGS" in
 		 *-DNO_DB*) ;;
 		 *-DHAS_DB*) ;;

That buys some additional time until Linux 10 comes along.

Cheers,
   Sven

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable

[Cyril Brulebois]

Hi,

Reco  (2019-02-17):
> Did this already in QEMU (virt board).
> 4.9.135-1 works.
> 4.9.144-1 (next one) is broken.

Is there any chance you could share how to get such a VM set up in QEMU?

I'd be happy to try a few kernel builds, but having a quick way to check
whether a given kernel build is OK/KO would be much appreciated.
 

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


signature.asc
Description: PGP signature

Bug#922533: please document location of accounting file

[Marc Haber]

Package: acct
Version: 6.6.4-2
Severity: wishlist

Hi,

my package atop needs to adapt itself to acct being installed or not. If
acct is installed, atop reads from acct's log files, while establishing
its own accounting interface it acct is not installed.

Historically, the pacct file is found in various different places,
varying across distribution, so atop's upstream code does through
various contortions to find the correct file. It for example acts on
/etc/logrotate.d/psacct to find the file being rotated, which fails on
Debian since Debian's acct package uses savelog in /etc/cron.d/acct.

atop on Debian is currently growing code to parse for the savelog line
in /etc/cron.d/acct to find out the acct file being used.

Would it be possible ot have the acct file's location in a more easily
parsable location? Thanks for helping!

Greetings
Marc


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

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

Versions of packages acct depends on:
ii  dpkg  1.19.4
ii  install-info  6.5.0.dfsg.1-4+b1
ii  libc6 2.28-7
ii  lsb-base  10.2018112800

acct recommends no packages.

acct suggests no packages.

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable

[Cyril Brulebois]

Hi,

Reco  (2019-02-17):
> 1) Install qemu-system-arm.
> 
> 2) Unpack kernel .deb, locate vmlinuz-4.9.0-8-armmp.
> Or search your just-built zImage.
> 
> 3) Run qemu (no root required):
> 
> qemu-system-arm -M virt -nographic -kernel vmlinuz-4.9.0-8-armmp
> 
> If you see a kernel panic - the outcome is positive, the kernel is OK.
> If it just stays there eating 100% CPU - the outcome is negative.

Perfect, checked with .135-1 and .144-3.

That's super useful, much appreciated!


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


signature.asc
Description: PGP signature

Bug#922539: new upstream release available

[Antoine Beaupre]

Package: fail2ban
Version: 0.10.2-2.1
Severity: wishlist

Hi,

there are two new upstream releases available for fail2ban (0.10.3 and
0.10.4, at the time of writing, which include a lot of bugfixes and
performance improvements. I think it would be important to ship those
with buster, at the very least.

Thanks!

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

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

Versions of packages fail2ban depends on:
ii  init-system-helpers  1.48
ii  lsb-base 9.20161125
ii  python3  3.5.3-1

Versions of packages fail2ban recommends:
ii  iptables   1.6.0+snapshot20161117-6
ii  python 2.7.13-2
ii  python3-pyinotify  0.9.6-1
ii  python3-systemd233-1
ii  whois  5.2.17~deb9u1

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
pn  monit
ii  rsyslog [system-log-daemon]  8.24.0-1

-- Configuration Files:
/etc/fail2ban/fail2ban.conf changed [not included]

-- no debconf information

Bug#912586: python-cobra still fails it's autopkg tests

[Liubov Chuprikova]

Hi,

I have just pushed a fix for this. In fact, the solution was proposed in
one of the previous messages [1]: the test suite was returning True some
time ago, but now it returns the exit code instead.

Some tests are `xfail`-ing (in the beginning I thought that's was the
problem) but as I understood they are expected to fail and that's why they
are ignored. For some other skipped tests, the extra dependencies are not
satisfied.

With regards,
Liubov

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912586#25

Bug#922507: wml: Missing depends on libgd-perl

[Axel Beckert]

Control: tag -1 + confirmed

Hi Kurt,

thanks for the bug report!

Kurt Roeckx wrote:
> I'm getting the following error:
> Can't locate GD.pm in @INC (you may need to install the GD module) (@INC 
> contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 
> /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 
> /usr/local/lib/site_perl) at /tmp/wml.28518.tmp1 line 197.
> BEGIN failed--compilation aborted at /tmp/wml.28518.tmp1 line 197.

This seems to come from using wml::des::imgbg:

/usr/share/wml/include/des/imgbg.wml:use GD;
/usr/share/wml/include/des/imgbg.wml:$im = GD::Image->new($size, 
$pixels);
/usr/share/wml/include/des/imgbg.wml:$im = GD::Image->new($pixels, 
$size);
/usr/share/wml/include/des/imgdot.wml:use GD;
/usr/share/wml/include/des/imgdot.wml:$im = GD::Image->new($x, $y);

So, indeed, there's a missing package relation.

> It seems that this was part of wml in older versions, but not in
> the current version.

Indeed. Previously there (i.e. in Stretch), there was a dependency on
libgd3 directly, because wml::des::imgbg used WML::GD which was a very
thin XS wrapper around the C library GD. That wrapper is gone now and
I missed the fact that it didn't just vanish but has been replaced
with calls to the existing perl module GD.

Will upload a fix shortly.

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

Bug#915547: Use iso639-3.xml file

[Osamu Aoki]

control: forwarded -1 https://github.com/ibus/ibus/issues/2062

Looks like pull request https://github.com/ibus/ibus/pull/2061 is
already applied to fujiwara's https://github.com/fujiwarat/ibus  repo
for 1.5.20.

1cd52548 ("src: use iso 639-3 to have names for more languages", 2018-12-17)

He didn't apply it to https://github.com/ibus/ibus repo

Let's close this when ibus 1.5.20 is packaged for post-buster.

If Daniel think upstream patch needs to be backported, can you create
pull request on salsa?

  https://salsa.debian.org/debian/ibus

With rationale to patch it for Debian.

Regards,

Osamu

Bug#922518: ITP: libdata-methodproxy-perl -- module to inject dynamic data into static data

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libdata-methodproxy-perl
  Version : 0.03
  Upstream Author : Aran Clary Deltac 
* URL : https://metacpan.org/release/Data-MethodProxy
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to inject dynamic data into static data

A method proxy as provided by the Data::MethodProxy module is an array ref
describing a class method to call and the arguments to pass to it. The first
value of the array ref is the scalar $proxy, followed by a package name, then
a subroutine name which must callable in the package, and a list of any
subroutine arguments.

 [ '$proxy', 'Foo::Bar', 'baz', 123, 4 ]

The above is saying, do this:

 Foo::Bar->baz( 123, 4 );

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#922521: flake FTCBFS: performs a native build

[Helmut Grohne]

Source: flake
Version: 0.11-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

flake fails to cross build from source, because it performs a native
build. To perform a cross build, one has to supply --cc=... and
--cross-compile. After doing so, flake cross builds successfully. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru flake-0.11/debian/changelog flake-0.11/debian/changelog
--- flake-0.11/debian/changelog 2017-03-05 13:42:48.0 +0100
+++ flake-0.11/debian/changelog 2019-02-17 18:03:15.0 +0100
@@ -1,3 +1,10 @@
+flake (0.11-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass --cc and --cross-compile to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 17 Feb 2019 18:03:15 +0100
+
 flake (0.11-3) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru flake-0.11/debian/rules flake-0.11/debian/rules
--- flake-0.11/debian/rules 2017-03-05 13:28:38.0 +0100
+++ flake-0.11/debian/rules 2019-02-17 18:03:15.0 +0100
@@ -1,10 +1,13 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@ --no-parallel
 
 override_dh_auto_configure:
-   CFLAGS="$(CFLAGS) $(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" ./configure 
--cpu=$(DEB_HOST_ARCH) --disable-strip --prefix=/usr
+   CFLAGS="$(CFLAGS) $(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" ./configure 
--cpu=$(DEB_HOST_ARCH) --cc=$(CC) $(if $(filter 
$(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)),,--cross-compile) --disable-strip 
--prefix=/usr
 
 override_dh_auto_install:
DESTDIR=$(CURDIR)/debian/flake $(MAKE) install-progs

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

[Torrance, Douglas]

On 2/17/19 11:49 AM, Andreas Metzler wrote:
> On 2019-02-13 Nye Liu  wrote:
>> On February 13, 2019 9:54:12 AM PST, Andreas Metzler  
>> wrote:
>>> I am not sure about the second part of the patch. I understand wmbiff
>>> breaking on GNUTLS_E_AGAIN from gnutls_read, because this only started
>>> to happen recently (with TLS1.3) on blocking sockets.
> 
>>> What I do not get from my rudimentary understanding C programmimg is
>>> the second part, this is in the else of "if (scs->tls_state)", so,
>>> afaiui for non-encrypted connections. Is the change necessary there
>>> at all, is it the right thing to retry read on EAGAIN then?
> 
>> Probably not, unless some other code change changes the conventional
>> fd to no block. I added it only for symmetry sake. It does not fix any
>> currently known bug.
> 
> Doug, when there is no actual benefit for this part I would drop
> it. - What do you think?

That sounds good to me.  I'll patch it upstream first and let you know 
when a new version of the Debian package is in git.

Doug

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable

[Reco]

Hi.

On Sun, Feb 17, 2019 at 07:38:18PM +0100, Cyril Brulebois wrote:
> Hi folks,
> 
> Jürgen Löb  (2019-02-16):
> > Package: linux-image-4.9.0-8-armmp-lpae
> > Version: 4.9.144-3
> > Severity: serious
> > 
> > Updated my Lamobo R1 board with apt update;apt upgrade
> > 
> > After the update uboot is struck at "Starting kernel". There is no
> > further output after "Starting kernel". Same happens on Bananapi 1
> > board. Unfortunately there is no more useful information.
> […]
> 
> Summing up, it looks like everybody in cc is confirming the regression
> happens between 4.9.130-2 and 4.9.144-3, with and without lpae, on
> various boards. Any chance you could check what happens with the
> 4.9.135-1 intermediary version that can be found on snapshot.debian.org?

Did this already in QEMU (virt board).
4.9.135-1 works.
4.9.144-1 (next one) is broken.

The problem is - 4.9.144-1 introduced large amount of changes, including
two Spectre mitigations.

My attempts to build a kernel with CONFIG_SPECTRE=n yielded unbootable
kernels, which may mean that:

a) Spectre mitigations are not related to the problem.
b) My kernel-rebuilding skill could use some improvement.

Reco

Bug#922532: Debian 9.8 does'nt starts on Cubieboard

[M.Gergo]

Package: linux-base
Version: 4.5
Description: After I upgraded to debian9.8 the kernel does'nt starts on 
Cubieboard2 (Allwinner/armhf).

The debian installer is also affected.
The system is freezed after displaying 'Starting kernel ...' line
Previously, there was an error (since debian9.0)  I got a kernel panic, 
every time, I typed a 'poweroff' command, with (at least) one 
attached/mounted gpio line.



Here is my boot-log:
=
U-Boot SPL 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1


U-Boot 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51 +) Allwinner 
Technology


CPU:   Allwinner A20 (SUN7I)
Model: Cubietech Cubieboard2
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
SCSI:  SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   eth0: ethernet@01c5
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
Hit any key to stop autoboot:  2  1  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
1575 bytes read in 24 ms (63.5 KiB/s)
## Executing script at 4310
Mainline u-boot / new-style environment detected.
reading vmlinuz
3716200 bytes read in 266 ms (13.3 MiB/s)
reading dtbs/sun7i-a20-cubieboard2.dtb
22846 bytes read in 135 ms (165 KiB/s)
reading initrd.gz
21360541 bytes read in 1432 ms (14.2 MiB/s)
Booting the Debian installer...

## Flattened Device Tree blob at 4300
   Booting using the fdt blob at 0x4300
   Loading Ramdisk to 48ba1000, end 499d ... OK
   Loading Device Tree to 48b98000, end 48ba093d ... OK

Starting kernel ...

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable

[Reco]

Hi.

On Sun, Feb 17, 2019 at 08:27:34PM +0100, Cyril Brulebois wrote:
> Hi,
> 
> Reco  (2019-02-17):
> > Did this already in QEMU (virt board).
> > 4.9.135-1 works.
> > 4.9.144-1 (next one) is broken.
> 
> Is there any chance you could share how to get such a VM set up in QEMU?
> 
> I'd be happy to try a few kernel builds, but having a quick way to check
> whether a given kernel build is OK/KO would be much appreciated.

1) Install qemu-system-arm.

2) Unpack kernel .deb, locate vmlinuz-4.9.0-8-armmp.
Or search your just-built zImage.

3) Run qemu (no root required):

qemu-system-arm -M virt -nographic -kernel vmlinuz-4.9.0-8-armmp

If you see a kernel panic - the outcome is positive, the kernel is OK.
If it just stays there eating 100% CPU - the outcome is negative.

Reco

Bug#922537: ansible: CVE-2019-3828

[Salvatore Bonaccorso]

Source: ansible
Version: 2.7.6+dfsg-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/ansible/ansible/pull/52133

Hi,

The following vulnerability was published for ansible.

CVE-2019-3828[0]:
path traversal in the fetch module

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-3828
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3828
[1] https://github.com/ansible/ansible/pull/52133

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#922540: Please give back ocaml-gettext on all architectures

[Hilko Bengen]

Package: release.debian.org
Severity: normal

src:ocaml-gettext could not be built because src:camomile was broken up
to version 1.0.1-2, see #922271. The recent upload of
src:camomile/1.0.1-3 fixes the issue; please give back ocaml-gettext on
all architectures.

  gb ocaml-gettext_0.3.7-1 . amd64 arm64 armel armhf i386 mips mips64el mipsel 
ppc64el s390x

I am not sure whether I should have the exact "+bn" binNMU versions for
each architecture in the line above. Just in case:

  gb ocaml-gettext_0.3.7-1+b2 . mips mips64el mipsel
  gb ocaml-gettext_0.3.7-1+b3 . amd64 arm64 armel i386 ppc64el s390x
  gb ocaml-gettext_0.3.7-1+b4 . armhf

Thank you,
-Hilko

Bug#922500: tex-common: Fails to install with LC_TIME=en_DE.UTF-8

[Norbert Preining]

You set the locale for root while installing, this has nothing to do with user 
settings what so ever. If you remove bash and a different program fails to 
install, do you think this is an error of the program bring installed?

If locales are not properly set up, then luatex fails to build a format, this 
is independent from the Debian packaging.

Anyway, you reopened the bug, so let's enjoy it.

Best

Norbert

On February 17, 2019 1:06:08 PM GMT+01:00, Charlemagne Lasse 
 wrote:
>> On Sun, 17 Feb 2019, Charlemagne Lasse wrote:
>> > perl: warning: Setting locale failed.
>> > perl: warning: Please check that your locale settings:
>> > LANGUAGE = "en_US:en",
>> > LC_ALL = (unset),
>> > LC_TIME = "en_DE.UTF-8",
>> > LANG = "C"
>> > are supported and installed on your system.
>>
>> > locale: Cannot set LC_ALL to default locale: No such file or
>directory
>>
>> You have a broken locale setup, there is nothing we can do. luatex
>needs
>> correctly setup locales, but they are not.
>
>But the installation of tex-common should not fail because of this. It
>works fine when LC_TIME is not set to C or en_US.UTF-8 and so on
>(everything which locales-all provides).
>
>If the installation of a package fails because a user set locale is
>wrong then something is terrible broken with your installation
>process. I understand that it may fail when the user calls luatex
>manually with some incorrect env but not when the installation process
>is run.
>
>Setup/Installation happens in the system context. But now you are
>telling me that something in the user context is allowed to break the
>installation. Nothing in the users env should change the way how the
>package installation process behaves. We have /etc for that - not the
>user specific env.
>
>What would you say when you swedish system administrator installs
>package xyz and suddenly all english-only speaking users of the system
>have to deal with a swedish-only installation of xyz - even when the
>swedish system admin never explicitly said that a swedish-only version
>should be installed? Sounds wrong, correct?
>
>It is a little bit like farting in the face of the reproducible build
>folks. Cool, we removed all the non-reproducible behavior in the build
>process - lets move all the reproducibility problems in the
>installation process.
>
>Maybe the package is assigned incorrectly in this ticket and
>dpkg/aptitude/... should sanitize the env. But the ticket should not
>be closed so easily.
>
>It is not like I sat down and broke the package on purpose. I just
>selected some good looking regional settings in KDE plasma. And
>suddenly my texlive installation doesn't work anymore. Not something
>which you would expect.


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

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

[Andreas Metzler]

On 2019-02-13 Nye Liu  wrote:
> On February 13, 2019 9:54:12 AM PST, Andreas Metzler  wrote:
>> I am not sure about the second part of the patch. I understand wmbiff
>> breaking on GNUTLS_E_AGAIN from gnutls_read, because this only started
>> to happen recently (with TLS1.3) on blocking sockets.

>> What I do not get from my rudimentary understanding C programmimg is
>> the second part, this is in the else of "if (scs->tls_state)", so,
>> afaiui for non-encrypted connections. Is the change necessary there
>> at all, is it the right thing to retry read on EAGAIN then?

> Probably not, unless some other code change changes the conventional
> fd to no block. I added it only for symmetry sake. It does not fix any
> currently known bug. 

Doug, when there is no actual benefit for this part I would drop
it. - What do you think?

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#922524: syslog-ng-core: warning message on start

[Nobuhiro Ban]

Package: syslog-ng-core
Version: 3.19.1-3
Severity: minor

Dear Maintainer,

syslog-ng (with default config files) warns on start.

/etc/syslog-ng/syslog-ng.conf:
># First, set some global options.
>options { chain_hostnames(off); flush_lines(0); use_dns(no); use_fqdn(no);
>  owner("root"); group("adm"); perm(0640); stats_freq(0);
>  bad_hostname("^gconfd$");
>};

Error message from /var/log/syslog (using systemd):
>Feb 18 01:10:07 blackbox syslog-ng[12242]: [2019-02-18T01:10:07.303183] 
>WARNING: With use-dns(no), dns-cache() will be forced to 'no' too!;



Adding "dns_cache(no);" into options { ... } resolves this matter.


Regards,
Nobuhiro Ban


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

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

Versions of packages syslog-ng-core depends on:
ii  libc6  2.28-6
ii  libcap21:2.25-2
ii  libcurl4   7.64.0-1
ii  libglib2.0-0   2.58.3-1
ii  libivykis0 0.42.3-1
ii  libjson-c3 0.12.1+ds-2
ii  libnet11.1.6+dfsg-3.1
ii  libpcre3   2:8.39-11
ii  libssl1.1  1.1.1a-1
ii  libsystemd0240-5
ii  libuuid1   2.33.1-0.1
ii  libwrap0   7.6.q-27
ii  lsb-base   10.2018112800
ii  syslog-ng-mod-journal  3.19.1-3
ii  util-linux 2.33.1-0.1

Versions of packages syslog-ng-core recommends:
ii  logrotate  3.14.0-4

Versions of packages syslog-ng-core suggests:
pn  syslog-ng-mod-add-contextual-data  
pn  syslog-ng-mod-amqp 
pn  syslog-ng-mod-examples 
pn  syslog-ng-mod-extra
pn  syslog-ng-mod-geoip
pn  syslog-ng-mod-geoip2   
pn  syslog-ng-mod-getent   
pn  syslog-ng-mod-graphite 
pn  syslog-ng-mod-map-value-pairs  
pn  syslog-ng-mod-mongodb  
pn  syslog-ng-mod-pacctformat  
pn  syslog-ng-mod-python   
pn  syslog-ng-mod-redis
pn  syslog-ng-mod-riemann  
pn  syslog-ng-mod-smtp 
pn  syslog-ng-mod-snmptrapd-parser 
pn  syslog-ng-mod-sql  
pn  syslog-ng-mod-stardate 
pn  syslog-ng-mod-stomp
pn  syslog-ng-mod-tag-parser   
pn  syslog-ng-mod-xml-parser   

-- no debconf information

Bug#922528: ITP: golang-github-arduino-go-timeutils -- Functions to handle timezones in golang

[Rock Storm]

Package: wnpp
Severity: wishlist
Owner: Rock Storm 

* Package name: golang-github-arduino-go-timeutils
  Version : 0.0~git20171220.d1dd9e3-1
  Upstream Author : Arduino
* URL : https://github.com/arduino/go-timeutils
* License : GPL-2.0
  Programming Lang: Go
  Description : Functions to handle timezones in golang

The package 'arduino-builder' [1] has been split into several smaller
Go libraries like this one. I intend to maintain this package within
the umbrella of the Go team.

[1]: https://salsa.debian.org/electronics-team/arduino/arduino-builder

Regards,

-- 
Rock Storm
GPG KeyID: 4096R/C96832FD
GPG Fingerprint:
 C304 34B3 632C 464C 2FAF  C741 0439 CF52 C968 32FD


signature.asc
Description: PGP signature

Bug#922527: x2gobroker: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: x2gobroker
Version: 0.0.4.0-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for x2gobroker's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


x2gobroker_0.0.4.0-3_pt.po.gz
Description: application/gzip

Bug#921598: No METAR available since noaa.gov switched to https

[Dr. Tobias Quathamer]

Am 16.02.2019 um 17:18 schrieb Gabriel F. T. Gomes:
> On Sat, Feb 16 2019, Florent Rougon wrote:
>>
>> As has been discussed on flightgear-devel and despite the commit
>> message, commit [1] is not a proper fix and will probably be reverted (I
>> mean, the "if( responseCode() >= 400 )" part, not the http to https URL
>> change which is okay though unnecessary now that redirection is fixed in
>> SimGear's HTTP::Client).
> 
> OK, thanks for the clarification.
> 
>> The correct fix is [a]. [b] is also a bug fix in this area, but doesn't
>> solve the particular METAR fetching problem.
>>
>> [a] 
>> https://sourceforge.net/p/flightgear/simgear/ci/34b3c52a288d62779073fc7694344d0658755645/
>> [b] 
>> https://sourceforge.net/p/flightgear/simgear/ci/6197098541eceecdb0dcfe8a58b15f0d0773c391/
> 
> I'll close the merge request.

Hi Gabriel and Florent,

thanks for reporting this bug and pointing to the commits! I'm currently
preparing a new upload of simgear which should still be in time for buster.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#922536: notmuch-emacs: notmuch breaks on directory removal

[Joerg Jaspert]

Package: notmuch-emacs
Version: 0.28-2~bpo9+1
Severity: normal

Dear Maintainer,

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

  * What led up to the situation?

Open notmuch "from" a random buffer. Keep the notmuch-hello open.

Remove the directory of that buffer (and the buffer too).

Try refreshing notmuch.

Get greeted by:

"apply: Setting current directory: No such file or directory, 
/the/removed/directory/"


  * What outcome did you expect instead?

Notmuch should change its own buffers to a safe dir that always exists.

--
bye, Joerg

Bug#919504: Info received ([kmail] blank page on print preview)

[hlehmbruch]

When i start kmail from the konsole, open the printpreview and than is
reproducible crashing (mostly every time) i get this information.
As attachment i send the crash report from drkonqi.

greetz Hendrik

 :~$ LANG=C kmail
org.kde.pim.kidentitymanagement: IdentityManager: There was no default
identity. Marking first one as default. No text-to-speech plug-ins were
found. Failure to generate QImage from invalid or empty PDF document.
QIODevice::read (QLocalSocket): device not open
QIODevice::read (QLocalSocket): device not open
*** KMail got signal 11 (Exiting)
*** Dead letters dumped.
/tmp/messageviewer_TlucUh.index.2 was removed .
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kmail path = /usr/bin pid = 19477
KCrash: Arguments: /usr/bin/kmail
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
from kdeinit sock_file=/run/user/1000/kdeinit5__0

[1]+  Angehalten  LANG=C kmail
Application: KMail (kmail), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f2e368a2f00 (LWP 8480))]

Thread 33 (Thread 0x7f2d0bdf2700 (LWP 9597)):
#0  0x7f2e4c18b3a9 in pthread_cond_timedwait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f2e459d4a37 in base::ConditionVariable::TimedWait(base::TimeDelta 
const&) () from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#2  0x7f2e459d730a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks 
const&) () from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#3  0x7f2e459d73f2 in base::WaitableEvent::TimedWait(base::TimeDelta 
const&) () from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#4  0x7f2e459db981 in 
base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () 
from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#5  0x7f2e459dcc7f in base::internal::SchedulerWorker::Thread::ThreadMain() 
() from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#6  0x7f2e459e5c81 in base::(anonymous namespace)::ThreadFunc(void*) () 
from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#7  0x7f2e4c184fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#8  0x7f2e4e94b80f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 32 (Thread 0x7f2d9132f700 (LWP 8559)):
#0  0x7f2e4c18b3a9 in pthread_cond_timedwait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f2e459d4a37 in base::ConditionVariable::TimedWait(base::TimeDelta 
const&) () from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#2  0x7f2e459d730a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks 
const&) () from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#3  0x7f2e459d73f2 in base::WaitableEvent::TimedWait(base::TimeDelta 
const&) () from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#4  0x7f2e459db981 in 
base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () 
from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#5  0x7f2e459dce61 in base::internal::SchedulerWorker::Thread::ThreadMain() 
() from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#6  0x7f2e459e5c81 in base::(anonymous namespace)::ThreadFunc(void*) () 
from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#7  0x7f2e4c184fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#8  0x7f2e4e94b80f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 31 (Thread 0x7f2d91b57700 (LWP 8558)):
#0  0x7f2e4c18b3a9 in pthread_cond_timedwait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f2e459d4a37 in base::ConditionVariable::TimedWait(base::TimeDelta 
const&) () from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#2  0x7f2e459d730a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks 
const&) () from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#3  0x7f2e459d73f2 in base::WaitableEvent::TimedWait(base::TimeDelta 
const&) () from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#4  0x7f2e459db981 in 
base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () 
from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#5  0x7f2e459dce61 in base::internal::SchedulerWorker::Thread::ThreadMain() 
() from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#6  0x7f2e459e5c81 in base::(anonymous namespace)::ThreadFunc(void*) () 
from /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#7  0x7f2e4c184fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#8  0x7f2e4e94b80f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 30 (Thread 0x7f2d932e8700 (LWP 8556)):
#0  0x7f2e4c18afbc in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f2e43446e4a in ?? () from /lib/x86_64-linux-gnu/libQt5Script.so.5
#2  0x7f2e43446e69 in ?? () from /lib/x86_64-linux-gnu/libQt5Script.so.5
#3  0x7f2e4c184fa3 in start_thread () from 

Bug#922538: cultivation FTCBFS: performs a native build

[Helmut Grohne]

Source: cultivation
Version: 9+dfsg1-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

cultivation fails to cross build from source, because it does not pass
any cross tools to make. The easiest way of doing so - using
dh_auto_build - does not quite fix that, because cultivation uses an
uncommon name for the C++ compiler "GXX". After renaming the compiler,
it cross builds successfully. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cultivation-9+dfsg1/debian/changelog 
cultivation-9+dfsg1/debian/changelog
--- cultivation-9+dfsg1/debian/changelog2013-06-02 08:24:40.0 
+0200
+++ cultivation-9+dfsg1/debian/changelog2019-02-17 21:21:39.0 
+0100
@@ -1,3 +1,12 @@
+cultivation (9+dfsg1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Rename compiler to GXX.
+
+ -- Helmut Grohne   Sun, 17 Feb 2019 21:21:39 +0100
+
 cultivation (9+dfsg1-2) unstable; urgency=low
 
   [ Barry deFreese ]
diff --minimal -Nru cultivation-9+dfsg1/debian/rules 
cultivation-9+dfsg1/debian/rules
--- cultivation-9+dfsg1/debian/rules2013-06-02 06:58:06.0 +0200
+++ cultivation-9+dfsg1/debian/rules2019-02-17 21:21:39.0 +0100
@@ -20,7 +20,7 @@
sed -i -e 's/^OPTIMIZE_FLAG = .*/OPTIMIZE_FLAG = /' 
game2/gameSource/Makefile
sed -i -e 's/^COMPILE_FLAGS = /COMPILE_FLAGS = $$(CFLAGS) $$(CPPFLAGS) 
/' game2/gameSource/Makefile
sed -i -e 's/^LINK_FLAGS = /LINK_FLAGS = $$(LDFLAGS) /' 
game2/gameSource/Makefile
-   $(MAKE) -C game2/gameSource LDFLAGS="$(LDFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
CFLAGS="$(CFLAGS) -DDATADIR=\\\"/usr/share/games/cultivation\\\""
+   dh_auto_build --sourcedirectory=game2/gameSource -- 'GXX=$$(CXX)' 
LDFLAGS="$(LDFLAGS)" CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS) 
-DDATADIR=\\\"/usr/share/games/cultivation\\\""
 
 override_dh_auto_clean:
[ ! -f game2/gameSource/Makefile ] || $(MAKE) -C game2/gameSource clean

Bug#922515: python-xarray: Fix CRS being WKT instead of PROJ.4

[Antonio Valentino]

Source: python-xarray
Version: 0.11.3-1
Severity: wishlist

Dear Maintainer,
as discussed in [1,2] it seems that some change in rasterio introduces
some breakage in packages depending on it.
IN particular I'm interested in the satpy package that started failing
tests at the end of January [3].

The issue can be fixed by applying the patch attached to [1] to xarray.
Please note that the patch has been already applied upstream.

It would be nice if you could consider applying the patch to the xarray
debian package before the final freeze.

[1] https://github.com/pydata/xarray/pull/2715
[2] https://github.com/pytroll/satpy/issues/604
[3] https://ci.debian.net/packages/s/satpy/unstable/amd64/

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

Kernel: Linux 4.18.0-16-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#922516: missing binary gtk-query-immodules-3.0

[Jeremy Bicha]

On Sun, Feb 17, 2019 at 8:51 AM Osamu Aoki  wrote:
> As I see the source package gtk+3.0-3.24.5/debian/libgtk-3-bin.install
> is missing entry for usr/bin/gtk-query-immodules-3.0
>
> This may be intentional since you may wish to make this in 64 and 32 bit
> version.  But not having any is buggy.  IM (Input method test will fail)

It is installed to
/usr/lib/x86_64-linux-gnu/libgtk-3-0/gtk-query-immodules-3.0 (on
64-bit).

See https://salsa.debian.org/gnome-team/gtk3/commit/e447da62

Thanks,
Jeremy Bicha

Bug#922519: ITP: ruby-data-uri -- URI::Data class for parsing RFC2397 data URIs

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name : ruby-data-uri
  Version  : 0.1.0
  Upstream Author  : Donald Ball
* URL  : https://github.com/dball/data_uri
* License  : Expat
  Programming Lang : Ruby
  Description  : URI::Data class for parsing RFC2397 data URIs

Data URIs allow resources to be embedded inside a URI. The URI::Data class
provides support for parsing these URIs using the normal URI.parse method.

Best,
Utkarsh

Bug#919831: Javadoc -link makes broken links if module name matches package name

[tony mancill]

On Fri, Feb 15, 2019 at 08:22:14PM +0100, Markus Koschany wrote:
> Am 15.02.19 um 15:42 schrieb tony mancill:
> [...]
> > Any thoughts on whether we should focus on fixing javadoc generation or
> > look at other ways to mitigate the FTBFS?
> 
> Like burning all those -doc packages? :)
> 
> In my opinion we could ask Robert Scholte for advice. He is chairman of
> Apache Maven and directly involved in fixing this bug. If he doesn't
> know
> 
> However I think I have found a workaround, and we all love workarounds,
> don't we.
> 
> In your initial post you pointed to a related bug report. [1] That made
> me think and also read the fine Maven Javadoc documentation. There is an
> option called detectJavaApiLink
> 
> https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#detectJavaApiLink
> 
> If I add
> 
> detectJavaApiLink=false to debian/maven.properties in libparanamer-java,
> the package builds from source again.
> 
> Maybe we should patch our tools and set this property to false and move
> on for now? Hopefully in a few months this will just work again without
> changing this option, when maven-javadoc-plugin et al. have been
> catching up?

Hi Markus,

Very nice find about detectJavaApiLink!  I'll try patching the
default value in current maven-javadoc-plugin here [1] and kick off as
large of a ratt build as I can see about coverage.  Assuming that is
successful, we could then look into what it would take to schedule a
binary NMU all packages that depend on maven-javadoc-plugin.  (Or maybe
someone on the list has a better idea?)

Do we know if there is any downside to disabling this by default?

Thanks!
tony

[1] 
https://salsa.debian.org/java-team/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L569


signature.asc
Description: PGP signature

Bug#922522: ITP: waylandpp -- wayland compositor infrastructure - C++ development files

[Balint Reczey]

Package: wnpp
Owner: Balint Reczey 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: waylandpp
  Version : 0.2.4
  Upstream Author : Nils Brause
* URL : https://github.com/NilsBrause/waylandpp
* License : GPL-3+
  Programming Lang: C++
  Description : wayland compositor infrastructure - C++ development files

Wayland is a protocol for a compositor to talk to its clients as well
as a C library implementation of that protocol. The compositor can be
a standalone display server running on Linux kernel modesetting and
evdev input devices, an X application, or a wayland client
itself. The clients can be traditional applications, X servers
(rootless or fullscreen) or other display servers.

This package ships the C++ bindings for the development libraries.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

The package is a build dependency of Kodi 18 for enabling Wayland support.

I'd be happy to maintain the package under Debian X Strike Force's
umbrella if the team accepts that.

Bug#922523: RFS: dav-text/0.8.9-1 - minimalist ncurses-based text editor

[Adam Bilbrough]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dav-text"

 Package name: dav-text
 Version: 0.8.9-1
 Upstream Author : Adam Bilbrough 
 URL: https://github.com/atsb/dav-text
 License: GPLv2
 Section: text

  It builds those binary packages:

dav-text - minimalist ncurses-based text editor

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

  https://mentors.debian.net/package/dav-text


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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dav-text/dav-text_0.8.9-1.dsc

  More information about dav-text can be obtained from
https://github.com/atsb/dav-text

  Changes since the last upload:

  * Removed some warnings from GCC8.
  * Fixed incorrect casting from int to long unsigned int.

  Regards,
   Adam

Bug#922324: clojure breaks nrepl-clojure autopkgtest

[Elana Hashman]

On Thu, Feb 14, 2019 at 04:45:48PM +0100, Paul Gevers wrote:
> autopkgtest [12:11:27]: test hello-nrepl: [---
> WARNING: requiring-resolve already refers to:
> #'clojure.core/requiring-resolve in namespace: user, being replaced by:
> #'nrepl.misc/requiring-resolve
> "e7d1e44b-654f-4a09-8460-7c9e3d01d783"
> autopkgtest [12:11:32]: test hello-nrepl: ---]
> autopkgtest [12:11:32]: test hello-nrepl:  - - - - - - - - - - results -
> - - - - - - - - -
> hello-nrepl  FAIL stderr: WARNING: requiring-resolve already
> refers to: #'clojure.core/requiring-resolve in namespace: user, being
> replaced by: #'nrepl.misc/requiring-resolve

Looks like it's a name shadowing issue introduced by 1.10. Simplest
solution is to update the autopkgtest to allow stderr, slightly more
sophisticated solution would be to patch the code to avoid name
shadowing.

I will see if I can submit the latter patch upstream but will proceed
with patching the test on nrepl as a quick fix for now.

- e


signature.asc
Description: PGP signature

Bug#922535: tea FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: tea
Version: 47.0.1-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

tea fails to cross build from source, because tea-qmake.pro hard codes
"pkg-config" in a few places and thus uses the wrong pkg-config. The
attached patch fixes that and makes tea cross buildable. Please consider
applying it.

Helmut
--- tea-47.0.1.orig/tea-qmake.pro
+++ tea-47.0.1/tea-qmake.pro
@@ -303,11 +303,12 @@
 icons/tea-icon-v3-02.png \
 icons/tea-icon-v3-03.png
 
+PKG_CONFIG = $$pkgConfigExecutable()
 
 unix:  {
 #LIBS += -lz
 
-system(pkg-config --exists zlib) {
+system($$PKG_CONFIG --exists zlib) {
 message ("Zlib found")
 PKGCONFIG += zlib
 }
@@ -323,7 +324,7 @@
 
 
 contains(USE_HUNSPELL,true){
-system(pkg-config --exists hunspell) {
+system($$PKG_CONFIG --exists hunspell) {
 message ("hunspell enabled")
 PKGCONFIG += hunspell
 DEFINES += HUNSPELL_ENABLE
@@ -332,7 +333,7 @@
 
 
 usepoppler{
-system(pkg-config --exists poppler-qt5) {
+system($$PKG_CONFIG --exists poppler-qt5) {
 message ("Poppler enabled")
 PKGCONFIG += poppler-qt5
 DEFINES += POPPLER_ENABLE
@@ -341,7 +342,7 @@
 
 
 usedjvu{
-system(pkg-config --exists ddjvuapi) {
+system($$PKG_CONFIG --exists ddjvuapi) {
 message ("djvu enabled")
 PKGCONFIG += ddjvuapi
 DEFINES += DJVU_ENABLE

Bug#922534: lintian: Typo fixes

[Guillem Jover]

Package: lintian
Version: 2.7.0
Severity: minor

Hi!

Here's a couple of patches I had sitting on my local lintian tree.

Thanks,
Guillem
From af1af30e9973e7da6f59fec405611392d1bf2aaf Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 17 Feb 2019 20:28:53 +0100
Subject: [PATCH 1/2] c/deb-format: Improve malformed-deb-archive tag extra
 information

Remove the .gz extension for control.tar, given that .xz is now also
accepted. Print the compressed data.tar member extensions matching the
ones being tested.
---
 checks/deb-format.pm| 4 ++--
 t/tags/debs/deb-format-wrong-order/tags | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/checks/deb-format.pm b/checks/deb-format.pm
index b1298282d..6d3bb0cee 100644
--- a/checks/deb-format.pm
+++ b/checks/deb-format.pm
@@ -116,7 +116,7 @@ sub run {
 if (not defined($ctrl_member)) {
 # Somehow I doubt we will ever get this far without a control
 # file... :)
-tag 'malformed-deb-archive', 'Missing control.tar.gz member';
+tag 'malformed-deb-archive', 'Missing control.tar member';
 $failed = 1;
 } else {
 if (
@@ -150,7 +150,7 @@ sub run {
 tag 'malformed-deb-archive',
   join(' ',
 "third (official) member $data_member",
-'not data.tar.(gz|bz2|xz)');
+'not data.tar.(gz|xz|bz2|lzma)');
 $failed = 1;
 } elsif ($type eq 'udeb'
 && $data_member !~ m/^data\.tar\.[gx]z$/) {
diff --git a/t/tags/debs/deb-format-wrong-order/tags b/t/tags/debs/deb-format-wrong-order/tags
index d5a22fae3..183f24f02 100644
--- a/t/tags/debs/deb-format-wrong-order/tags
+++ b/t/tags/debs/deb-format-wrong-order/tags
@@ -1,2 +1,2 @@
 E: deb-format-wrong-order: malformed-deb-archive second (official) member data.tar.gz not control.tar.(gz|xz)
-E: deb-format-wrong-order: malformed-deb-archive third (official) member control.tar.gz not data.tar.(gz|bz2|xz)
+E: deb-format-wrong-order: malformed-deb-archive third (official) member control.tar.gz not data.tar.((gz|xz|bz2|lzma)
-- 
2.20.1.791.gb4d0f1c61a

From 329303c24f727d3ef1a311400eb83fb9e7af946b Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 17 Feb 2019 20:38:20 +0100
Subject: [PATCH 2/2] t: Remove duplicate word across newline boundary

---
 t/scripts/Lintian/Lab/data/changes/lintian_2.5.11_amd64.changes | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/scripts/Lintian/Lab/data/changes/lintian_2.5.11_amd64.changes b/t/scripts/Lintian/Lab/data/changes/lintian_2.5.11_amd64.changes
index b366feddb..23e21f8b9 100644
--- a/t/scripts/Lintian/Lab/data/changes/lintian_2.5.11_amd64.changes
+++ b/t/scripts/Lintian/Lab/data/changes/lintian_2.5.11_amd64.changes
@@ -34,7 +34,7 @@ Changes:
  .
* checks/*:
  + [NT] Remove assumption that lintian will chdir into the
-   the lab before calling the check.
+   lab before calling the check.
  + [NT] Be better at avoiding false-positive spelling errors
for references to packages that also happen to be common
spelling mistake.  Thanks to Paul Tagliamonte for the
-- 
2.20.1.791.gb4d0f1c61a

Bug#922516: missing binary gtk-query-immodules-3.0

[Osamu Aoki]

Package: src:gtk+3.0
Version: 3.24.5-1
Severity: normal

What is the problem:

gtk-query-immodules-3.0 binary should be packaged into libgtk-3-bin

Please build it and add it to libgtk-3-bin.install


I was trying to compile ibus and realized:

| FAIL: ibus-compose
| ==
| 
| ~/pub/salsa/ibus/ibus/src/tests/tmp-ibus-compose 
~/pub/salsa/ibus/ibus/src/tests
| ./runtest: line 148: gtk-query-immodules-3.0-64: command not found
| Unable to init server: Could not connect: Connection refused
| 
| (ibus-compose:973): Gtk-WARNING **: 22:12:10.142: cannot open display:
| ~/pub/salsa/ibus/ibus/src/tests
| FAIL ibus-compose (exit status: 1)
| 
| FAIL: ibus-keypress
| ===
| 
| ~/pub/salsa/ibus/ibus/src/tests/tmp-ibus-keypress 
~/pub/salsa/ibus/ibus/src/test
| s
| ./runtest: line 148: gtk-query-immodules-3.0-64: command not found
| Unable to init server: Could not connect: Connection refused
| 
| (/home/osamu/pub/salsa/ibus/ibus/src/tests/.libs/ibus-keypress:960): 
Gtk-WARNING
|  **: 22:12:10.137: cannot open display:
| ./runtest: line 111:   960 Trace/breakpoint trap   "../$tst" ${1+"$@"}
| ~/pub/salsa/ibus/ibus/src/tests
| FAIL ibus-keypress (exit status: 133)
| 

On Debian, there is nothing like "gtk-query-immodules-3.0" command but
alas, I have manpage for gtk-query-immodules-3.0 provided by libgtk-3-bin

As I see the source package gtk+3.0-3.24.5/debian/libgtk-3-bin.install
is missing entry for usr/bin/gtk-query-immodules-3.0

This may be intentional since you may wish to make this in 64 and 32 bit
version.  But not having any is buggy.  IM (Input method test will fail)

Please think about adding this command.

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

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

Bug#922500: tex-common: Fails to install with LC_TIME=en_DE.UTF-8

[Norbert Preining]

And by the way, quoting from your first message

> LANG=C sudo aptitude
> Warning: Invalid locale (please review locale settings, this might
> lead to problems later):

And it did.

Best wishes


On February 17, 2019 3:11:41 PM GMT+01:00, Norbert Preining  
wrote:
>You set the locale for root while installing, this has nothing to do
>with user settings what so ever. If you remove bash and a different
>program fails to install, do you think this is an error of the program
>bring installed?
>
>If locales are not properly set up, then luatex fails to build a
>format, this is independent from the Debian packaging.
>
>Anyway, you reopened the bug, so let's enjoy it.
>
>Best
>
>Norbert
>
>On February 17, 2019 1:06:08 PM GMT+01:00, Charlemagne Lasse
> wrote:
>>> On Sun, 17 Feb 2019, Charlemagne Lasse wrote:
>>> > perl: warning: Setting locale failed.
>>> > perl: warning: Please check that your locale settings:
>>> > LANGUAGE = "en_US:en",
>>> > LC_ALL = (unset),
>>> > LC_TIME = "en_DE.UTF-8",
>>> > LANG = "C"
>>> > are supported and installed on your system.
>>>
>>> > locale: Cannot set LC_ALL to default locale: No such file or
>>directory
>>>
>>> You have a broken locale setup, there is nothing we can do. luatex
>>needs
>>> correctly setup locales, but they are not.
>>
>>But the installation of tex-common should not fail because of this. It
>>works fine when LC_TIME is not set to C or en_US.UTF-8 and so on
>>(everything which locales-all provides).
>>
>>If the installation of a package fails because a user set locale is
>>wrong then something is terrible broken with your installation
>>process. I understand that it may fail when the user calls luatex
>>manually with some incorrect env but not when the installation process
>>is run.
>>
>>Setup/Installation happens in the system context. But now you are
>>telling me that something in the user context is allowed to break the
>>installation. Nothing in the users env should change the way how the
>>package installation process behaves. We have /etc for that - not the
>>user specific env.
>>
>>What would you say when you swedish system administrator installs
>>package xyz and suddenly all english-only speaking users of the system
>>have to deal with a swedish-only installation of xyz - even when the
>>swedish system admin never explicitly said that a swedish-only version
>>should be installed? Sounds wrong, correct?
>>
>>It is a little bit like farting in the face of the reproducible build
>>folks. Cool, we removed all the non-reproducible behavior in the build
>>process - lets move all the reproducibility problems in the
>>installation process.
>>
>>Maybe the package is assigned incorrectly in this ticket and
>>dpkg/aptitude/... should sanitize the env. But the ticket should not
>>be closed so easily.
>>
>>It is not like I sat down and broke the package on purpose. I just
>>selected some good looking regional settings in KDE plasma. And
>>suddenly my texlive installation doesn't work anymore. Not something
>>which you would expect.
>
>
>--
>PREINING Norbert http://www.preining.info
>Accelia Inc. + JAIST + TeX Live + Debian Developer
>GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13


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

Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies

[Peter Pentchev]

On Sat, Feb 16, 2019 at 03:32:46PM +0100, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2019-02-15 at 10:46:43 -0500, Daniel Kahn Gillmor wrote:
> > Control: clone 922353 -2
> > Control: reassign -2 dpkg
> > Control: retitle -2 start-stop-daemon should support socket-activation via 
> > the sd_listen_fds(3) convention
> > Control: severity -2 wishlist
> 
> Thanks.
> 
> > On Fri 2019-02-15 04:34:47 +0100, Guillem Jover wrote:
> > > Another option would be to implement this in start-stop-daemon, like
> > > the similar support for the systemd readiness protocol was recently
> > > implemented there too.
> > 
> > Thanks for the suggestion!  How widely-distributed is start-stop-daemon
> > outside of debian?  I see it's been ported to OpenBSD; are they
> > syncing from upstream?
> 
> . For the BSDs to use
> this more seriously the code would probably need to be split into its
> own project, so that it does not pollute their licensing. Its current
> "license" might also need to be clarified (PD), and "relicensed" into
> MIT or similar.
> 
> This is something I've actually pondered doing anyway, so this might
> be a good excuse, I guess.
> 
> > The code i have is just python3 right now (simple argument parsing made
> > development much quicker), but it's not too terrible to do it in C.
> 
> Yes, and it should be pretty generic and portable.
> 
> > I'm opening this as a wishlist issue for dpkg just so we don't lose
> > track of it, since it might take me some cycles to get the C
> > implementation in shape.  If anyone else wants to beat me to it, i
> > certainly wouldn't complain :)
> 
> I'll probably look into it once I've gone over some of the immediate
> stuff I have on my plate, if there's been no patch submitted by then.
> :)

Here you go :)

https://gitlab.com/dkg/socket-activate/merge_requests/1#note_142084524

G'luck,
Peter

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


signature.asc
Description: PGP signature

Bug#919917: yui-compressor: insufficient java dependency in jessie

[Markus Koschany]

Contol: severity -1 normal

On Mon, 21 Jan 2019 20:13:37 -0800 tony mancill  wrote:
> On Sun, Jan 20, 2019 at 06:14:31PM +0100, Andreas Beckmann wrote:
> > Package: yui-compressor
> > Version: 2.4.7-2
> > Severity: serious
> > Tags: jessie
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> > Control: affects -1 + libjs-protoaculous
> > Control: found -1 libjs-protoaculous/5
> 
> Hi Andreas,
> 
> The version of the package in the bug is found in jessie (oldstable)
> and doesn't exist in stretch (stable) or buster (testing).  Also, I
> believe the problem is with the version of default-jre-headless in
> jessie, given that the Depends hasn't changed since 2012.
> 
> Are you requesting that the bug be addressed for jessie?  (Do we need to
> open a RC-severity bug for oldstable right before the buster freeze?)

Bugs in Jessie not affecting Buster are not release critical.





signature.asc
Description: OpenPGP digital signature

Bug#922516: missing binary gtk-query-immodules-3.0

[Simon McVittie]

On Sun, 17 Feb 2019 at 22:52:14 +0900, Osamu Aoki wrote:
> gtk-query-immodules-3.0 binary should be packaged into libgtk-3-bin

If it was in libgtk-3-bin, it would become misleading to mark libgtk-3-bin
as Multi-Arch: foreign. On Debian, it's in libgtk-3-0, in a multiarch
directory.

Please add /usr/lib/x86_64-linux-gnu/libgtk-3-0 to the PATH when running
tests that rely on gtk-query-immodules-3.0, or invoke it by its full
path. Note that this is a Debian-specific change and should not be
upstreamed.

smcv

Bug#921790: liquidsoap: FTBFS (ld: cannot find -lexif)

[Kyle Robbertze]

Hi,

On 2019/02/17 11:52, Andrey Rahmatullin wrote:
> On Sat, Feb 09, 2019 at 12:15:34AM +, Santiago Vila wrote:
>> OCAMLOPT -o liquidsoap
>> /usr/bin/ld: cannot find -lexif
> libexif-dev is indeed not installed but my build fails even earlier:
> 
> OCAMLOPT -c tools/file_watcher.ml
> OCAMLOPT -c tools/file_watcher_mtime.ml
> OCAMLOPT -c configure.mli
> OCAMLOPT -c configure.ml
> File "configure.ml", line 25, characters 11-32:
> Error: Unbound module Camomile
> make[4]: *** [../Makefile.rules:193: configure.cmx] Error 2
> make[4]: Leaving directory '/<>/src'

This is because version 1.0.1 of Camomile is in unstable. I am busy
packaging liquidsoap 1.3.4, which is compatible with newer versions of
Camomile and will fix both these issues.

Cheers
Kyle

Bug#913576: Update

[bkw+1542031175]

Hi Mattia,

Unfortunately, I haven't heard anything from the Debian developers 
regarding this error.  However, this morning, with adequate time and 
careful preparation, I decided to perform a reboot on this server.  I'm 
very happy to report that the server booted successfully.  So, it 
appears that the generated EFI images functioned successfully.


I don't know what this means, for the error I encountered which led to 
me reporting this bug.  But it appears that the error was either a false 
alarm, or it was not a critical error.


Regardless, a reboot was successful.

Thanks.

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable

[Timo Sigurdsson]

Hi,

I've also been hit by this bug on two systems (both are Lemaker Bananapi). The 
first system upgraded the kernel via unattended-upgrades and failed to come up 
after reboot. I don't have a serial cable, but I did hook up the board to a 
HDMI display. U-Boot loads the kernel, dtb and initramfs and starts the kernel 
but that's the last message and nothing happens after that anymore. My first 
suspicion was that something went wrong during the upgrade and the reboot might 
have happened before everything was configured. But I also tried manual package 
upgrade with a second device via apt update && apt full-upgrade followed by a 
manual reboot. That system didn't boot either.

I recovered both systems by replacing the contents of the directories /boot/ 
and /lib/modules/ with those of a recent backup (taken 3 days ago). After 
logging into the systems again, I downgraded the package 
linux-image-4.9.0-8-armmp-lpae to 4.9.130-2 and rebooted again in order to make 
sure no other package upgrade caused the issue. Indeed, with all packages 
up-to-date except linux-image-4.9.0-8-armmp-lpae, the systems work just fine.

So, there must be a serious regression in 4.9.144-3 at least on armmp-lpae. My 
amd64 systems run fine, btw, even with the latest kernel.


Thanks,

Timo

Bug#918578: gosa: GOsa web interface missing password field

[Wolfgang Schweer]

On Mon, Jan 14, 2019 at 03:43:26PM +, Holger Levsen wrote:
> On Mon, Jan 14, 2019 at 05:15:59PM +0200, Eliza Ralph wrote:
> > So are you saying it's not possible to fix GOsa in this case?
> 
> it's not gosa that is broken but your php setup.

After upgrading a Debian Edu main server (Stretch 9.8 -> Buster) the 
password entry field is missing just like reported.
Further investigation needed...

Wolfgang


signature.asc
Description: PGP signature

Bug#921790: liquidsoap: FTBFS (ld: cannot find -lexif)

[Andrey Rahmatullin]

On Sun, Feb 17, 2019 at 04:58:58PM +0200, Kyle Robbertze wrote:
> This is because version 1.0.1 of Camomile is in unstable. I am busy
> packaging liquidsoap 1.3.4, which is compatible with newer versions of
> Camomile and will fix both these issues.
Please note the freeze policy.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#922529: libtool: Emits warnings in very alarming bold red color

[Guillem Jover]

Package: libtool
Version: 2.4.6-9
Severity: normal

Hi!

The libtool program emits warnings in bold red which is a very
unexpected and confusing color for a warning (in contrast to an error),
and it always triggers alarms when I see it scroll by, for example for:

  ,---
  libtool: warning: remember to run 'libtool --finish /usr/lib/x86_64-linux-gnu'
  `---

Please switch this to something like bold yellow instead. And use bold
red for errors instead.

Thanks,
Guillem

Bug#746426: Debian Bug#746426: marked as done (gcc: Enable -fasynchronous-unwind-tables on more arches.)

[Kurt Roeckx]

On Wed, Jan 23, 2019 at 07:54:57PM +0100, Kurt Roeckx wrote:
> 
> But those pass at least run-backtrace-native: arm64, armel, armhf,
> i386, ppc64el, s390x, powerpc, ppc64, sparc64
> 
> This means that for the arches we release for, mips* is the only
> one that does not pass run-backtrace-native.

So at least the test suite failures on riscv64 are caused by gcc
not enabling this.

I've been told that "Unwinding information is not optional on
GNU".

Please just enable this.


Kurt

Bug#904462: RFS: uefitool/0.25.1-1 [ITP]

[Andrey Rahmatullin]

Thank you, uploaded.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#922477: postfix: FTBFS under Linux > 4

[Scott Kitterman]

Can you change:

Linux.[34].*) SYSTYPE=LINUX$RELEASE_MAJOR

to:

Linux.[345].*) SYSTYPE=LINUX$RELEASE_MAJOR

in makedefs and verify it builds and works (just a smoke test is fine) with 
your kernel?  I'm having discussions with upstream about this and that would be 
helpful in moving things forward.

Scott K

On February 16, 2019 5:26:39 PM UTC, Sven Joachim  wrote:
>Source: postfix
>Version: 3.3.2-3
>Severity: important
>Tags: ftbfs
>
>I was trying to test a patch for #922475, but the build system barfed
>when it saw my kernel:
>
>,
>| make[1]: Entering directory '/tmp/postfix'
>| /usr/bin/make -f Makefile.in MAKELEVEL= Makefiles
>| make: Entering directory '/tmp/postfix'
>| (echo "# Do not edit -- this file documents how Postfix was built for
>your machine."; /bin/sh makedefs) >makedefs.tmp
>| ATTENTION:
>| ATTENTION: Unknown system type: Linux 5.0.0-rc6-nouveau
>| ATTENTION:
>| make: *** [Makefile.in:32: Makefiles] Error 1
>`
>
>Please tell upstream to stop this nonsense.  Linux kernel version
>numbers don't really mean anything, as Linus has told the world for
>many
>years.
>
>
>-- System Information:
>Debian Release: buster/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable'), (101, 'experimental')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>Kernel: Linux 5.0.0-rc6-nouveau (SMP w/2 CPU cores)
>Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
>LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)

Bug#922531: lintian: Please make package-uses-vendor-specific-patch-series Debian-archive specific

[Guillem Jover]

Package: lintian
Version: 2.7.0
Severity: wishlist

Hi!

As the maintainer of dpkg, I do not agree at all (well I'd go as far as
to consider them to be just bogus :) with the rationale and conclusions
that were arrived to get the package-uses-vendor-specific-patch-series
tag implemented.

But the above is sadly besides the point here, given the authority that
was wielded to force this through. The reach of this tag should have been
exclusively up to the Debian archive, and not apply to any local runs, or
derivatives, etc.

So, I'd appreciate very much to see this tag emitted exclusively when
running lintian on lintian.d.o and Debian's ftp-master (possibly for
Ubuntu too, given their complaints) as part of its acceptance checks.
But not when running locally or for any other derivatives, because
both dpkg and lintian are used beyond Debian, where that ruling should
have no reach.

Thanks,
Guillem

Bug#921418: Kernel update from 4.18 to 4.19 breaks vlc (update)

[Sebastian Ramacher]

Control: reassign -1 linux 4.19.12-1

Hi Hartmut

On 2019-02-16 12:00:15, Hartmut Buhrmester wrote:
> The latest kernel update for stretch-backports seems to solve the problems
> with vlc. This update was on Thu, Feb 14 2019. The logfile /var/log/aptitude
> says:
> 
> > Aptitude 0.8.7: log report
> > Thu, Feb 14 2019 03:41:42 +0100
> > 
> >   IMPORTANT: this log only lists intended actions; actions which fail
> >   due to dpkg problems may not be completed.
> > 
> > Will install 4 packages, and remove 0 packages.
> > 151 MB of disk space will be used
> > 
> > [HOLD, DEPENDENCIES] manpages-de:i386 2.9-1~bpo9+1
> > [INSTALL, DEPENDENCIES] apparmor:i386 2.11.0-3+deb9u2
> > [INSTALL, DEPENDENCIES] libapparmor-perl:i386 2.11.0-3+deb9u2
> > [INSTALL, DEPENDENCIES] linux-image-4.19.0-0.bpo.2-686-pae:i386 
> > 4.19.16-1~bpo9+1
> > [UPGRADE] linux-image-686-pae:i386 4.19+101~bpo9+1 -> 4.19+102~bpo9+1
> > 
> > 
> > Log complete.
> 
> 
> Then we may update the results table to:
> 
> Kernel 4.9.130  4.18.20  4.19.124.19.16
> -- ---  ---  ------
> vlc-3.0.3  okay okay program_hangs  okay
> vlc-3.0.6  okay okay program_hangs  okay

Thanks for the follow-up. I'll reassign the bug to linux and mark it as closed 
in 4.19.16.

Cheers

> 
> The tested kernels are:
> 
> package-version kernel-version
> --- --
> linux-image-4.9.0-8-686-pae 4.9.130-2
> linux-image-4.18.0-0.bpo.3-686-pae  4.18.20-2~bpo9+1
> linux-image-4.19.0-0.bpo.1-686-pae  4.19.12-1~bpo9+1
> linux-image-4.19.0-0.bpo.2-686-pae  4.19.16-1~bpo9+1
> 
> These packages are referenced by a meta-package linux-image-686-pae, which
> still has a different numbering scheme.
> 
> 
> I don't know, what caused the problems with vlc, or what solved them in the
> end. I suspected at some point, that there might be changes to the "radeon"
> driver, but there are no obvious changes to "radeon" between kernel 4.19.12
> and 4.19.16. So it might be a side effect of something completely different.
> 
> I learned, that old package versions can be found at
> https://snapshot.debian.org/ , if others like to repeat these tests.
> 
> 
> Regards,
> Hartmut Buhrmester
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable

[Timo Sigurdsson]

Hi,

Cyril Brulebois schrieb am 17.02.2019 19:38:

> Hi folks,
> 
> Jürgen Löb  (2019-02-16):
>> Package: linux-image-4.9.0-8-armmp-lpae
>> Version: 4.9.144-3
>> Severity: serious
>> 
>> Updated my Lamobo R1 board with apt update;apt upgrade
>> 
>> After the update uboot is struck at "Starting kernel". There is no
>> further output after "Starting kernel". Same happens on Bananapi 1
>> board. Unfortunately there is no more useful information.
> […]
> 
> Summing up, it looks like everybody in cc is confirming the regression
> happens between 4.9.130-2 and 4.9.144-3, with and without lpae, on
> various boards. Any chance you could check what happens with the
> 4.9.135-1 intermediary version that can be found on snapshot.debian.org?
> 
>  https://snapshot.debian.org/package/linux/4.9.135-1/
> 
> This might help narrow it down when the regression happened.
> 
> (And please use reply-all so that everyone is kept in the loop.)

So, I also tested 4.9.135-1 on a Bananapi board and can confirm it works.

I would suspect the issue is caused by Debian's kernel configuration or 
changes. The Kernel CI project has ARM hardware, including the Bananapi board 
and does tests of stable kernel updates to verify that the kernel boots. At 
least with multi_v7_defconfig and sunxi_defconfig, upstream 4.9.144 does boot 
on Allwinner-based hardware, see: 
https://kernelci.org/soc/allwinner/job/stable-rc/kernel/v4.9.144/

On a sidenote: This issue makes me wonder if Debian's approach to kernel 
updates (i.e. not bumping the version number/ABI and overwriting the kernel 
image and modules) is really the best option. IMHO Ubuntu's handling of kernel 
updates is more robust. It would have made things much easier today if I could 
have simply selected an older kernel in the bootloader, rather than having to 
recover one from a backup.

Kind regards,

Timo

Bug#823892: fail2ban: very slow startup *and* shutdown

[Antoine Beaupré]

Control: tags -1 +confirmed

I can confirm both bugs here. During the last upgrade, needrestart
noticed fail2ban needed a restart, so it did. Here's what systemd sees
right now:

root@marcos:/home/anarcat# systemctl status fail2ban
● fail2ban.service - Fail2Ban Service
   Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Sun 2019-02-17 15:32:58 EST; 9min ago
 Docs: man:fail2ban(1)
  Process: 5829 ExecStop=/usr/bin/fail2ban-client stop (code=exited, status=255)
  Process: 12738 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, 
status=0/SUCCESS)
 Main PID: 12745 (fail2ban-server)
Tasks: 14 (limit: 4915)
   Memory: 33.3M
  CPU: 3min 14.842s
   CGroup: /system.slice/fail2ban.service
   └─12745 /usr/bin/python3 /usr/bin/fail2ban-server -s 
/var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ba

fév 17 15:42:06 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.80
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.82
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.84
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.85
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.86
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.87
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.88
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.90
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.91
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.93
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.94
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.95
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.97

... and those lines are still being added there:

fév 17 15:43:28 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.182.250

etc...

In other words, fail2ban has been loading a list of IP addresses in the
firewall for the last 9 minutes. Before that, it was *removing* IP
addresses from the firewall for another three minutes (before systemd
gave up, see #...):

root@marcos:/home/anarcat# journalctl -u fail2ban.service | grep systemd
fév 17 15:29:57 marcos systemd[1]: Stopping Fail2Ban Service...
fév 17 15:31:27 marcos systemd[1]: fail2ban.service: Stopping timed out. 
Terminating.
fév 17 15:31:27 marcos systemd[1]: fail2ban.service: Control process exited, 
code=exited status=255
fév 17 15:32:57 marcos systemd[1]: fail2ban.service: State 'stop-sigterm' timed 
out. Killing.
fév 17 15:32:57 marcos systemd[1]: fail2ban.service: Killing process 2176 
(fail2ban-server) with signal SIGKILL.
fév 17 15:32:57 marcos systemd[1]: fail2ban.service: Main process exited, 
code=killed, status=9/KILL
fév 17 15:32:57 marcos systemd[1]: Stopped Fail2Ban Service.
fév 17 15:32:57 marcos systemd[1]: fail2ban.service: Unit entered failed state.
fév 17 15:32:57 marcos systemd[1]: fail2ban.service: Failed with result 
'timeout'.
fév 17 15:32:57 marcos systemd[1]: Starting Fail2Ban Service...
fév 17 15:32:58 marcos systemd[1]: Started Fail2Ban Service.

Now it systemd considers the thing "started" even though it's still
loading the IP list. Because systemd timed out, we also see this in the
logs:

fév 17 15:45:39 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] 
183.160.227.26 already banned 

... obviously, fail2ban didn't have time to remove all addresses from
the firewall.

There are many things wrong here:

 1. "service fail2ban restart" should try to remove all IP addresses
from the firewall if it's going to re-add them all a second later

 2. even if it *does* decide to do that, it shouldn't fail halfway
through.

 3. if "stop" waits for all IPs to be cleared out, "start" should as
well

 4. loading IP addresses shouldn't be that slow

I don't have that many addresses loaded in that jail:

Status for the jail: postfix-auth
|- Filter
|  |- Currently failed: 4
|  |- Total failed: 456
|  `- File list:/var/log/mail.log
`- Actions
   |- Currently banned: 4499
   |- Total banned: 4499 
   `- Banned IP list:   [...]

A 5000 IP block list is really not that much. Note that I'm using the
`ipset` functionality in my jails to improve on that process (it was
even slower before):

# head -5 /etc/fail2ban/jail.local 
[DEFAULT]
findtime = 60
ignoreip = 192.168.0.7
banaction = iptables-ipset-proto6
banaction_allports = iptables-ipset-proto6-allports

-- 
On ne résout pas un problème avec les modes de pensée qui l'ont
engendré.
- Albert Einstein

Bug#834331: test code fails and ignored for ibus

[Osamu Aoki]

control: retitle -1 build package with test fully enabled

Test code issue summary:

BASHISM: pushed  -> comited patch to salsa master

--enable-memconf -> ChromeOS feature
 I created branch to enable this and tagged it as memconf

Still fails
 FAIL: ibus-compose
 FAIL: ibus-keypres

Both of failures come from missing gtk-query-immodules-3.0 command in
libgtk-3-bin package.

Filed bug report:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922516

Now at least 12 successes and 2 failures
(It used to be 14 failures)

Bug#922516: missing binary gtk-query-immodules-3.0

[Jeremy Bicha]

On Sun, Feb 17, 2019 at 9:08 AM Jeremy Bicha  wrote:
> See https://salsa.debian.org/gnome-team/gtk3/commit/e447da62

Never mind. That commit is unrelated.

Jeremy

Bug#907898: gmap: autopkgtest regression

[Liubov Chuprikova]

Hi Andreas,

I have just found the easiest bug to solve :-) This one was solved in the
very next version 2018-07-04-4 and since then the autopkgtest is passing
everywhere [1].

With regards,
Liubov

[1] https://ci.debian.net/packages/g/gmap/

Bug#922517: libconfig-model-dpkg-perl: Doesn't know debhelper-compat

[gregor herrmann]

Package: libconfig-model-dpkg-perl
Version: 2.121
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Running `cme fix dpkg-control' in a package with 'debhelper-compat (=
12)' leads to:

Connecting to api.ftp-master.debian.org to check debhelper-compat versions. 
Please wait...
got info for debhelper-compat
Connecting to api.ftp-master.debian.org to check debhelper-compat versions. 
Please wait...
got info for debhelper-compat
Warning in 'source Build-Depends:0': package debhelper-compat is unknown. Check 
for typos if not a virtual package.
Offending value: 'debhelper-compat (= 12)'

debhelper has
Provides: debhelper-compat (= 10), debhelper-compat (= 11), debhelper-compat (= 
12), debhelper-compat (= 9),

which probably doesn't help when querying api.ftp-master.debian.org
so maybe we should add debhelper-compat to the list of virtual
packages (and/but also see #865720).


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlxpiOJfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZiUA//epNjC4T2DPuWbjf93vT94qSzmXI4wduEGJpq2yt1lBvKfdCLKCYNpV9Y
2izPNismB8GZTfrAoJGQX14z+hzaEJKfRHx6zonqKw1ZsgIMMewQRVqu90n/xvk0
9d1/qA1PmdRQlgxLG3bvv3M9ZhuZxfs11jGuFkM8afRwFYRlIZ8/4kLkRgmIYM0m
CR02yoXkLWOYALOU5ANQtNprlly2B0ZDDcsevMPAaM2x+i/Nnxcsy8vqsd5bhXXq
CQV7wq7TcIkDCdbebw9ewl+FYkKUxACcxXBfGH350qcl6ttMjcZSo53e1E2qNj2w
o/kmRU8+/blPmtlkiRaPu7wvBTz3BwmN7iMnHNwp+6+l2EEuEieqsbkZ5+AkWStq
FadbIm1WX/Ff6405UHeKQMZFZlKnBini65J91ld1ir8cCfHc3aC9wji3EPUQPuz0
A2iCjbm+v2d2BpZEwIThtV8nriPqZ8DeQxrdtJPUfqNt9zhhcP8v7oEY04sPjyuf
ITyMPfaEO5QoK9u/gaSfr51GAHVlYlvr9YDs6ZcHGACe3k+yewsq1HnUR79O/sx4
ObjgBO2c1s/muATw9A9D9DcIaBsMElcDFknusR+KOw4wPKaMDrgfOUhZRxA3KQoj
TM4HZeDi7xTlHUrfkF65KpKz0yc3Bx3FidD35bZEs5eYZvjUcw0=
=DClM
-END PGP SIGNATURE-