Bug#923567: strong vote against deleting cluster on package purge

[Erik Thiele]

Package: postgresql
Version: 9.6+181+deb9u2

I am creating this bugreport because of a mishap that now has happened
twice to me and I think it does not actually have to happen and maybe
the behavior of the package should be changed.

1) At home I once tried a document management system for my private
home paper work. It worked great until I did a debian upgrade of the
server. Everything worked fine and I also --purge all removed
packages. Then all of sudden the database was gone. After noticing that
I should not have --purge the old version of postgresql I found out
that I had no backups. Since then I work with paper again. Of course it
is my fault, but ...

2) Yesterday at work I did a massive upgrade of all kinds of virtual
machines at the same time. A lot of different services like mail,
fileserver, etc. So again I ran into the pitfall that purging old
packages deletes my postgresql cluster. Of course I have backups but
the work of one day is lost and all employees are very happy of course.
Yes I know it is my fault, but ...


Here are the arguments I have against cleaning up the actual cluster
files when --purge postgresql

a) Compare postgresql to samba or nfs-kernel-server. When purging these
packages, the files on the filesystem which the server was serving will
certainly not be removed. But on postgresql they are.

b) What is worse? Having files not owned by a corresponding package
in /var/lib/postgresql or losing a complete database on system upgrade?

c) Compare this to for example ruby gems. When doing gem install xxx as
root, you will get files in /var/lib/gems/version/... Now when
upgrading the system you will get a new ruby version and when
installing gems, a new version directory will be built. The old one
just stays there and nobody ever deletes it. Especially not the old
ruby packages when you --purge them.



I am sure I am not the only one who fell in this --purge trap. To say
it again, of course it is my own fault, but still I think that the
package should not delete the cluster on --purge. Please rethink that
decision.



Thanks
Erik

Bug#923566: jacktrip FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: jacktrip
Version: 1.1~repack-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

jacktrip fails to cross build from source, because debian/rules hard
codes the build architecture pkg-config and thus fails finding rtaudio.
The attached patch fixes that part, but jacktrip continues to fail due
to its use of help2man. There is no good solution for help2man except
not using it. Please consider applying the attached patch and close this
bug when addressing the pkg-config part.

Helmut
diff --minimal -Nru jacktrip-1.1~repack/debian/changelog 
jacktrip-1.1~repack/debian/changelog
--- jacktrip-1.1~repack/debian/changelog2016-08-03 12:31:59.0 
+0200
+++ jacktrip-1.1~repack/debian/changelog2019-03-01 14:52:29.0 
+0100
@@ -1,3 +1,10 @@
+jacktrip (1.1~repack-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Use a triplet-prefixed pkg-config. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 01 Mar 2019 14:52:29 +0100
+
 jacktrip (1.1~repack-5) unstable; urgency=medium
 
   * Only build 'release' profile
diff --minimal -Nru jacktrip-1.1~repack/debian/rules 
jacktrip-1.1~repack/debian/rules
--- jacktrip-1.1~repack/debian/rules2016-08-03 12:30:30.0 +0200
+++ jacktrip-1.1~repack/debian/rules2019-03-01 14:52:28.0 +0100
@@ -26,12 +26,15 @@
 # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
 export QT_SELECT=qt5
+-include /usr/share/dpkg/buildtools.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/qmake.mk
 include /usr/share/cdbs/1/rules/utils.mk
 
-CPPFLAGS+=$(shell pkg-config --cflags rtaudio || true)
-LDFLAGS +=$(shell pkg-config --libs   rtaudio || true)
+PKG_CONFIG ?= pkg-config
+
+CPPFLAGS+=$(shell $(PKG_CONFIG) --cflags rtaudio)
+LDFLAGS +=$(shell $(PKG_CONFIG) --libs   rtaudio)
 
 DEB_MAKE_BUILD_TARGET = release
 DEB_MAKE_INSTALL_TARGET = release-install INSTALL_ROOT=$(DEB_DESTDIR)

Bug#782001: access granted to /home files of another user

[Ansgar]

Control: tag -1 + security

I think this problem (having $HOME world-readable by default) should
really be fixed...  In installations sharing $HOME between multiple
users this means private data of all sorts (medical records, unpublished
scientific articles, exam results, ...) can be accessed by /all/ users
by default.  This seems a really bad idea.

Dear security team, should such issues get a CVE id?  If one follows the
link from [1], one should contact the Debian security team to assign one
(even though [1] says Debian won't assign one?).

Ansgar

  [1] https://www.debian.org/security/faq#cveget

Bug#902162: closed by Petter Reinholdtsen (Re: fixed 902162 in 2.2.5-2)

[Petter Reinholdtsen]

[Santiago Vila]
> Until then, I see closing the bug as counter-productive and slightly
> misleading, as it may give the false impression that the issue has
> been dealt with.

Aha.  I assumed someone had just forgotten to close it, as it was
flagged as fixed without any explanation that it was intentional to not
close it at the same time.

-- 
Happy hacking
Petter Reinholdtsen

Bug#923564: FTBFS: Could not resolve org.codehaus.plexus:plexus-classworlds:2.5.2

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Emmanuel,

Thanks for the patch.

In the future I would prefer if reverse dependencies of updated java
packages where tested when they are updated, like people do for transitions.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#922874: file: mistakes Xorg.0.log file as JSON data

[Christoph Biedl]

Control: severity 922874 important
Control: tags 922874 pending

Vincent Lefevre wrote...

> On 2019-02-21 17:02:15 +0100, Vincent Lefevre wrote:
> > file mistakes Xorg.0.log file as JSON data (which breaks viewing
> > with "less" + LESSOPEN).
> [...]
> 
> I've reported the bug upstream.

Thanks. Upstream fixed this last night, I'll try to get this into
buster still.

Christoph



signature.asc
Description: PGP signature

Bug#907009: Not fixed in upstream 0.30.x branch

[Matthew Kraai]

Hi,

This does not appear to be fixed in upstream's 0.30.x branch.  I
applied a patch of the differences between 0.30.2 and revision 2045 of
the 0.30.x branch and the same failures still occurred.

-- 
Matt

Bug#878597: mailman: messages shunted due to uncaught runner exception (UnicodeDecodeError in pipermail.py)

[Benoit Panizzon]

Package: mailman
Version: 1:2.1.23-1+deb9u4
Followup-For: Bug #878597

Dear Maintainer,

I'm experiencing exactly the same problem after upgrading to 2.1.23.

I run several mailinglists with different languages, so many emails are sent in 
utf8.

After upgrade a couple of lists stopped working and all messages are shunted 
with messages like:

Mar 02 07:18:00 2019 (29638) SHUNTING: 
1551496266.198737+c6746c07f14b963960db9eaf05fcebbfa7b49439
Mar 02 07:18:00 2019 (29638) Uncaught runner exception: 'utf8' codec can't 
decode byte 0xaa in position 26: invalid start byte
Mar 02 07:18:00 2019 (29638) Traceback (most recent call last):
  File "/var/lib/mailman/Mailman/Queue/Runner.py", line 119, in _oneloop
self._onefile(msg, msgdata)
  File "/var/lib/mailman/Mailman/Queue/Runner.py", line 190, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
  File "/var/lib/mailman/Mailman/Queue/ArchRunner.py", line 77, in _dispose
mlist.ArchiveMail(msg)
  File "/var/lib/mailman/Mailman/Archiver/Archiver.py", line 214, in ArchiveMail
h.processUnixMailbox(f)
  File "/var/lib/mailman/Mailman/Archiver/pipermail.py", line 596, in 
processUnixMailbox
self.add_article(a)
  File "/var/lib/mailman/Mailman/Archiver/pipermail.py", line 640, in 
add_article
author = fixAuthor(article.decoded['author'])
  File "/var/lib/mailman/Mailman/Archiver/pipermail.py", line 63, in fixAuthor
while i>0 and (L[i-1][0] in lowercase or
UnicodeDecodeError: 'utf8' codec can't decode byte 0xaa in position 26: invalid 
start byte

I have re-installed mailman etc, unshunted the messages, looked at the mbox 
files (I don't see anything wrong)
but the problem persists. U have no clue how I can get those lists back working.

Also deleting the shunted messages is not the solution, as new messages equaly 
get shunted.

What I have to mention, during the upgrade, something went wrong with the 
locales and I had to re-install them.
Could that be that maybe mailman compiled language files or similar while the 
locales were gone and this
caused the problem?

I would have guessed that re-installing mailman after fixing the locales would 
solve such a problem.

Any help greatly appriciated.

-Benoit-

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

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

Versions of packages mailman depends on:
ii  apache-ssl [httpd]   1.3.34-4.1+etch1
ii  apache2 [httpd]  2.4.10-10+deb8u8
ii  apache2-mpm-prefork [httpd]  2.4.10-10+deb8u8
ii  cron [cron-daemon]   3.0pl1-128+deb9u1
ii  debconf [debconf-2.0]1.5.61
ii  libc62.24-11+deb9u4
ii  logrotate3.11.0-0.1
ii  lsb-base 9.20161125
ii  python   2.7.13-2
ii  python-dnspython 1.15.0-1+deb9u1
ii  ucf  3.0036

Versions of packages mailman recommends:
ii  sendmail-bin [mail-transport-agent]  8.15.2-8

Versions of packages mailman suggests:
pn  listadmin 
ii  lynx  2.8.9dev11-1
pn  spamassassin  

-- Configuration Files:
/etc/cron.d/mailman changed:
0 8 * * * list [ -x /usr/lib/mailman/cron/checkdbs ] && 
/usr/lib/mailman/cron/checkdbs
0 9 * * * list [ -x /usr/lib/mailman/cron/disabled ] && 
/usr/lib/mailman/cron/disabled
0 12 * * * list [ -x /usr/lib/mailman/cron/senddigests ] && 
/usr/lib/mailman/cron/senddigests
0 5 1 * * list [ -x /usr/lib/mailman/cron/mailpasswds ] && 
/usr/lib/mailman/cron/mailpasswds
*/5 * * * * list [ -x /usr/lib/mailman/cron/gate_news ] && 
/usr/lib/mailman/cron/gate_news
27 3 * * * list [ -x /usr/lib/mailman/cron/nightly_gzip ] && 
/usr/lib/mailman/cron/nightly_gzip
30 4 * * * list [ -x /usr/lib/mailman/cron/cull_bad_shunt ] && 
/usr/lib/mailman/cron/cull_bad_shunt


-- debconf information:
* mailman/used_languages: ca de en es eu fi fr hu ia it nl no pl pt pt_BR ro sr 
sv tr
* mailman/site_languages: sr, tr, sv, ro, pt_BR, pt, pl, no, nl, it, ia, hu, 
fr, fi, eu, es, de, ca, en
* mailman/create_site_list:
  mailman/gate_news: true
* mailman/default_server_language: en
* mailman/queue_files_present: continue regardless

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

[Andreas Tille]

Hi Liubov,

I've lost this a bit out of sight.  Today is the last day for uploading
anything without asking the release team for migration.  I definitely
will not be able to work on the issue myself (sponsoring could be an
option but not more).

Kind regards

   Andreas.

On Sun, Feb 17, 2019 at 01:40:21PM +0100, Liubov Chuprikova wrote:
> 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

-- 
http://fam-tille.de

Bug#923156: keyutils autopkgtest shows failure on armhf

[Steve Langasek]

On Sun, Feb 24, 2019 at 05:39:30PM +0100, Christian Kastner wrote:
> > +++ ADD USER KEY
> > +++ PRINT PAYLOAD
> > +++ UPDATE USER KEY
> > +++ PRINT UPDATED PAYLOAD
> > +++ UNLINK KEY> +++ ADD LARGE USER KEY
> > FAILED
> > Unparsable key: 'no'
> > make: *** [Makefile:41: run] Error 1
> > FAILED
> > +++ CLEAR KEYRING
> > 
> >   (http://autopkgtest.ubuntu.com/packages/k/keyutils/disco/armhf)>
> > Since the Debian autopkgtest runners also use containers instead of VMs, and
> > this test passes there, it is plausible that this is a bug in the package 
> > onchange 
> > armhf rather than a wrong restriction on this subtest.

> It's really hard to say because this package is notoriously hard to
> test, as it's just the userspace tooling for a kernel feature... On the
> Debian buildds, I've also run into everything from architecture-specific
> kernel bugs to version-specific kernel bugs to buildd-specific kernel
> config issues.

> The logs don't offer that much, so I was planning to upload a 1.6-5 soon
> that also saves away all the test artifacts for analysis (it still FTBFS
> on alpha, for example).

> Could I ping you for a re-test on armhf, or will that even be triggered
> automatically?

> I do intend to set up VMs for various architectures to test this
> locally, but I'm afraid I won't get to that until March...

I've synced keyutils 1.6-5 (manually, since we're past feature freeze for
Ubuntu 19.04) and the tests have rerun, still failing on armhf. 
http://autopkgtest.ubuntu.com/packages/k/keyutils/disco/armhf

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#923565: [keepassxc] KeepassXC not showing in the icon bar

[Synthea]

Package: keepassxc
Version: 2.3.4+dfsg.1-1~bpo9+1
Severity: normal
Reproducible: Always

This behaviour was found on plasma. If "Show a system tray icon" and
"Hide window to system tray when minimized" are set, if you minimize
the window the icon in the system tray won't appear and there will be
no means of interacting with keepassxc


--- System information. ---
Architecture: 
Kernel:   Linux 4.9.0-5-amd64

Debian Release: 9.8
  500 stable-updates  deb.debian.org 
  500 stable  security.debian.org 
  500 stable  repo.skype.com 
  500 stable  dl.google.com 
  500 stable  deb.debian.org 
  500 newstable   deb.i2p2.de 
  100 stretch-backports deb.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-=
libargon2-0  (>= 0~20160406~) | 0~20160821-1+b1
libc6   (>= 2.14) | 
libgcrypt20(>= 1.7.0) | 
libqt5core5a   (>= 5.7.0) | 
libqt5dbus5(>= 5.0.2) | 
libqt5gui5 (>= 5.7.0) | 
libqt5network5 (>= 5.0.2) | 
libqt5widgets5(>= 5.6.0~beta) | 
libqt5x11extras5   (>= 5.6.0) | 
libsodium18(>= 1.0.8) | 
libstdc++6   (>= 5.2) | 
libx11-6  | 
libxi6| 
libxtst6  | 
libykpers-1-1 (>= 1.12.0) | 
libzxcvbn0(>= 0.20150103) | 
zlib1g   (>= 1:1.1.4) | 


Package's Recommends field is empty.

Package's Suggests field is empty.




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

Bug#720456: [vim-scripts] Please include the solarized colorscheme

[Marco Villegas]

Dear maintainer,

Thanks for providing the package, I find it really useful.

I have used https://github.com/altercation/solarized repository as the
base to add the solarized color scheme to the package.

Based on the note at the README file, I concluded the license of the
provided code is https://opensource.org/licenses/MIT.

I am not entirely sure of the urls on metadata at
debian/vim-scripts.status, but I guess that they are OK. It is
important to notice that there is a vim.org page, i.e.
https://www.vim.org/scripts/script.php?script_id=3520, for the color
scheme, but sadly the code there contains an older version of what I
find at the repository, and that is why I decided to use the version
from the repository.

I was a bit worried on how debian/vim-scripts.pl will handle the github
url, but both doc and update actions seems to finish OK, naturally
suggesting a false positive on the case of the new solarized addon.

Another detail I am not sure about is the value of disabledby at
debian/vim-scripts.status for this new addon, so I have just skipped it.

Also, I have started by updating the html documentation for all addons,
since I could not figure out a way to only do it for the new addon. It
is in a separate commit, just in case that change is not a good idea.

The code can be found at
https://salsa.debian.org/vim-team/vim-scripts/merge_requests/1

Let me know if I can do something else to help this change get into the
package.

Best,

-Marco

Bug#923508: systemd not restarting sshd on Debian 9 Stretch i386 due to RestartPreventExitStatus=255 in sshd.service file

[Andrew Roberts]

Michael,

as to what the bug report is about I guess there are three issues:

1) At some point the

/etc/systemd/system/sshd.service

file has been updated to include RestartPreventExitStatus=255

which has a negative effect stopping sshd restarting in order to work with a 
slow to start network connection.
This does not seem to be a sensible default option. I don't know if this comes 
under sshd or systemd.

2) The override.conf mechanism does not seem to be working. Which is a definite 
systemd issue

3) systemd seems to be complaining about the need to reload units using 
daemon-reload even when you have just done daemon-reload

These seem to have come in with the last point release, and as of yesterday, 
the latest updates on top of that had not addressed
these issues.

Andrew

Bug#919647: CUDA 9.2.148 depends on driver version 396.37 or higher

[Samuel Thibault]

Hello,

Giuseppe Bilotta, le ven. 18 janv. 2019 11:41:28 +0100, a ecrit:
> On Fri, Jan 18, 2019 at 10:45 AM Andreas Beckmann  wrote:
> > On 2019-01-18 10:19, Giuseppe Bilotta wrote:
> > > Package: nvidia-cuda-dev
> > > Version: 9.2.148-5
> > > Severity: important
> >
> > > it is currently impossible to do any CUDA development and deployment in
> > > (a fresh install of) Debian testing and unstable, due to an
> > > incompatibility between the available CUDA toolkit version and the
> > > available NVIDIA driver versions.
> >
> > It was intentional relax the driver dependency in order to perform the
> > CUDA 9.2 transition in time for the transition freeze.
> > Please use the drivers from experimental for CUDA.
> > I don't want to upload a new driver version to unstable before I got the
> > driver in stretch updated to the well tested 390.xx series in sid.
> 
> Thanks for the reply. So I assume you expect to be able to complete
> the upgrade of stretch to 390.xx and the subsequent migration of
> 410.xx to testing and unstable before the hard freeze? Otherwise, I'm
> a bit worried that with this early transition we'll end up having an
> unusable CUDA in buster.

We are now just waiting for the nvidia-graphics-drivers migration, which
depends on hashcat-nvidia dropping the nvidia-smi dependency on i386.

Samuel

Bug#923564: FTBFS: Could not resolve org.codehaus.plexus:plexus-classworlds:2.5.2

[Emmanuel Bourg]

Package: osmosis
Version: 0.47-3
Severity: serious

Hi,

osmosis currently fails to build in unstable, that was probably caused by
the upgrade of plexus-classworlds in January. Here is a patch fixing the
issue.

Emmanuel Bourg
diff --git a/debian/control b/debian/control
index 4ff5eb5..90019ea 100644
--- a/debian/control
+++ b/debian/control
@@ -27,7 +27,7 @@ Build-Depends: debhelper (>= 9),
libspring-transaction-java,
libstax2-api-java,
libosmpbf-java,
-   libplexus-classworlds2-java,
+   libplexus-classworlds-java,
libprotobuf-java (>= 3.6.1),
libwoodstox-java,
libxerces2-java,
@@ -57,7 +57,7 @@ Depends: default-jre-headless | java8-runtime-headless,
  libspring-jdbc-java,
  libspring-transaction-java,
  libosmpbf-java,
- libplexus-classworlds2-java,
+ libplexus-classworlds-java,
  libprotobuf-java,
  libxerces2-java,
  libxz-java,
diff --git a/debian/maven.rules b/debian/maven.rules
index 3898b15..8fd7b9f 100644
--- a/debian/maven.rules
+++ b/debian/maven.rules
@@ -1,6 +1,5 @@
 
 junit junit * s/.*/4.x/ * *
-org.codehaus.plexus plexus-classworlds * s/.*/2.x/ * *
 org.springframework spring-jdbc * s/.*/debian/ * *
 #s/org.jboss.netty/io.netty/ netty * s/.*/debian/ * *
 s/org.postgis/net.postgis/ postgis-jdbc * s/.*/debian/ * *
diff --git a/debian/patches/01-fix_launcher.patch 
b/debian/patches/01-fix_launcher.patch
index cda6abe..fc58210 100644
--- a/debian/patches/01-fix_launcher.patch
+++ b/debian/patches/01-fix_launcher.patch
@@ -28,7 +28,7 @@ Forwarded: not-needed
  
  # Build up the classpath of required jar files via classworlds launcher.
 -MYAPP_CLASSPATH=$MYAPP_HOME/lib/default/plexus-classworlds-*.jar
-+MYAPP_CLASSPATH=$LIBRARIES_HOME/plexus-classworlds2.jar
++MYAPP_CLASSPATH=$LIBRARIES_HOME/plexus-classworlds.jar
  
  MAINCLASS=org.codehaus.classworlds.Launcher
 -EXEC="$JAVACMD $JAVACMD_OPTIONS -cp $MYAPP_CLASSPATH -Dapp.home=$MYAPP_HOME 
-Dclassworlds.conf=$MYAPP_HOME/config/plexus.conf  $MAINCLASS $OSMOSIS_OPTIONS"

Bug#923563: freeciv-client-sdl: Fails to start: missing themes/gui-sdl2/human/DejaVuSans.ttf

[Lars Kruse]

Package: freeciv-client-sdl
Version: 2.6.0-1
Severity: important

Dear Maintainer,

I tried to run freeciv-sdl2, but sadly it failed with the following
output:

 $ LANG= freeciv-sdl2 
 2: Didn't find the option file. Creating a new one.
 2: Migrating options from sdl to sdl2 client
 2: Using Video Output: x11
 0: Could not open font: themes/gui-sdl2/human/DejaVuSans.ttf
 0: No usable default theme found, aborting!

The directory /usr/share/games/freeciv/themes/gui-sdl2/human/ does not
contain the font file mentioned above.

Thank you for your time!

Cheers,
Lars


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-2-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages freeciv-client-sdl depends on:
ii  fonts-arphic-uming0.2.20080216.2-10
ii  fonts-dejavu-core 2.37-1
ii  fonts-ipafont-gothic  00303-18
ii  fonts-unfonts-core1:1.0.2-080608-16
ii  freeciv-data  2.6.0-1
ii  libbz2-1.01.0.6-9
ii  libc6 2.28-7
ii  libcurl3-gnutls   7.64.0-1
ii  liblzma5  5.2.4-1
ii  libsdl2-2.0-0 2.0.9+dfsg1-1
ii  libsdl2-gfx-1.0-0 1.0.4+dfsg-3
ii  libsdl2-image-2.0-0   2.0.4+dfsg1-1
ii  libsdl2-mixer-2.0-0   2.0.4+dfsg1-1
ii  libsdl2-ttf-2.0-0 2.0.15+dfsg1-1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages freeciv-client-sdl recommends:
ii  freeciv-server  2.6.0-1

Versions of packages freeciv-client-sdl suggests:
ii  freeciv-client-extras   2.6.0-1
ii  freeciv-sound-standard  2.6.0-1

-- no debconf information

Bug#786808: RFA: adequate -- Debian package quality testing tool

[Paul Wise]

On Fri, 2019-03-01 at 16:54 +0100, Axel Beckert wrote:

> So I'd really prefer if a team would take it over. And I still think
> that the Lintian team would be the most appropriate team for that.

FTR, I don't know when or if I'll find the time and motivation to work
on adequate so I'll be happy for a team to take it over and then join
that team later down the track.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#918953: itstool: Messed up with encoding when output is redirected (regression?)

[Osamu Aoki]

Hi

I am traveling and away from Debian system now


Thanks
Sent from iPhone 

2019/01/11 6:12、Boyuan Yang のメール:

> Package: itstool
> Version: 2.0.5-2
> Severity: important
> X-Debbugs-CC: tanguy+deb...@ortolo.eu tan...@debian.org os...@debian.org
> Control: affects -1 debmake-doc
> 
> Dear itstool maintainer,
> 
> We recently found a potential regression that broke the building process for
> package debmake-doc. A minimal example that can reproduce the problem is
> attached with this report in a tarball.
> 
> % tree minimal_reproduce 
> minimal_reproduce
> ├── debmake-doc.en.x02
> ├── docbook.its
> ├── run_me_crash
> └── run_me_no_crash
> 
> 0 directories, 4 files
> 
> When you run the "run_me_crash" script, itstool will return with error:
> 
> -> % cat run_me_crash 
> #!/bin/sh
> itstool -i ./docbook.its ./debmake-doc.en.x02 -o - | cat
> 
> -> % cat run_me_no_crash 
> #!/bin/sh
> itstool -i ./docbook.its ./debmake-doc.en.x02 -o -
> 
> % ./run_me_crash > /dev/null
> Traceback (most recent call last):
>  File "/usr/bin/itstool", line 1578, in 
>messages.output(out)
>  File "/usr/bin/itstool", line 155, in output
>out.write(msg.format())
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u201c' in position
> 70: ordinal not in range(128)
> 
> -> % ./run_me_no_crash
> (will run successfully)
> 
> -> % ./run_me_no_crash > /dev/null
> Traceback (most recent call last):
>  File "/usr/bin/itstool", line 1578, in 
>messages.output(out)
>  File "/usr/bin/itstool", line 155, in output
>out.write(msg.format())
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u201c' in position
> 70: ordinal not in range(128)
> 
> ===
> 
> Well that is really strange. As long as there's any redirection of output,
> itstool will use 'ascii' encoding by default, which is weird and it's causing
> problems. I guess it's a bug in itstool itself.
> 
> Tanguy, could you please take a look?
> 
> --
> Regards,
> Boyuan Yang
> 

Bug#923562: kmail: fails to copy sent email to sent mail folder

[Juha Jäykkä]

Package: kmail
Version: 4:18.08.3-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

I replied to an email in the Inbox of an imap account, which is set up to keep
replies in the same folder.

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

Compose message, hit Control-Enter, answered "send as is" to the query about
sending an unsigned message.

   * What was the outcome of this action?

After a pause of several minutes, kmail claims the mail was sent, but that it
failed to place a copy of the message in the sent mail folder.  Instead, the
mail is left in unread state in Outbox, strongly suggesting no email was sent.

Network connectivity existed throughout.

   * What outcome did you expect instead?

Mail sent, copy placed in inbox.


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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:18.08.3-4
ii  kdepim-runtime   4:18.08.3-1
ii  kio  5.54.1-1
ii  libc62.28-7
ii  libgcc1  1:8.2.0-21
ii  libgpgmepp6  1.12.0-6
ii  libkf5akonadiagentbase5  4:18.08.3-4
ii  libkf5akonadicontact54:18.08.3-1
ii  libkf5akonadicore5abi2   4:18.08.3-4
ii  libkf5akonadimime5   4:18.08.3-1
ii  libkf5akonadisearch-bin  4:18.08.3-1
ii  libkf5akonadisearch-plugins  4:18.08.3-1
ii  libkf5akonadisearchdebug54:18.08.3-1
ii  libkf5akonadisearchpim5  4:18.08.3-1
ii  libkf5akonadiwidgets5abi14:18.08.3-4
ii  libkf5bookmarks5 5.54.0-1
ii  libkf5calendarcore5abi2  4:18.08.3-1
ii  libkf5calendarutils5 4:18.08.3-2
ii  libkf5codecs55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.54.0-1
ii  libkf5configgui5 5.54.0-1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5contacts5  4:18.08.3-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5followupreminder5  4:18.08.3-2
ii  libkf5grantleetheme-plugins  18.08.3-1
ii  libkf5gravatar5abi2  4:18.08.3-1
ii  libkf5guiaddons5 5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5identitymanagement518.08.3-2
ii  libkf5itemmodels55.54.0-1
ii  libkf5itemviews5 5.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kcmutils5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5kontactinterface5  18.08.3-1
ii  libkf5ksieveui5  4:18.08.3-2
ii  libkf5libkdepim-plugins  4:18.08.3-2
ii  libkf5libkdepim5 4:18.08.3-2
ii  libkf5libkdepimakonadi5  4:18.08.3-2
ii  libkf5libkleo5   4:18.08.3-2
ii  libkf5mailcommon5abi24:18.08.3-2
ii  libkf5mailtransport5 18.08.3-2
ii  libkf5mailtransportakonadi5  18.08.3-2
ii  libkf5messagecomposer5abi1   4:18.08.3-1
ii  libkf5messagecore5abi1   4:18.08.3-1
ii  libkf5messagelist5abi1   4:18.08.3-1
ii  libkf5messageviewer5abi1 4:18.08.3-1
ii  libkf5mime5abi1  18.08.3-1
ii  libkf5mimetreeparser5abi14:18.08.3-1
ii  libkf5notifications5 5.54.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5parts5 5.54.0-1
ii  libkf5pimcommon5abi2 4:18.08.3-2
ii  libkf5pimcommonakonadi5abi1  4:18.08.3-2
ii  libkf5pimtextedit5abi2   18.08.3-1
ii  libkf5sendlater5 4:18.08.3-2
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5sonnetui5  5.54.0-1
ii  libkf5templateparser54:18.08.3-1
ii  libkf5textwidgets5   5.54.0-1
ii  libkf5tnef5  4:18.08.3-1
ii  libkf5wallet-bin 5.54.0-1
ii  libkf5wallet55.54.0-1
ii  libkf5webengineviewer5abi1   4:18.08.3-1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libqgpgme7   1.12.0-6
ii  libqt5core5a 5.11.3+dfsg-5
ii  libqt5dbus5  5.11.3+dfsg-5
ii  libqt5gui5   5.11.3+dfsg-5
ii  libqt5network5   5.11.3+dfsg-5
ii  libqt5widgets5   5.11.3+dfsg-5
ii  libqt5xml5   5.11.3+dfsg-5
ii  libstdc++6   

Bug#923559: closed by Michael Biebl (Re: Bug#923559: systemd-udevd: writes to kernel log)

[Michael Biebl]

Control: tags -1 + wontfix

Am 02.03.19 um 00:27 schrieb Thorsten Glaser:
> reopen 923559
> thanks
> 
> Debian Bug Tracking System dixit:
> 
>> If this explanation is unsatisfactory and you have not received a
>> better one in a separate message then please contact Michael Biebl 
>>  by
>> replying to this email.
> 
> This is unsatisfactory.

The only other option you have is to disable logging in udevd completely.

>>> This is expected behaviour. udevd uses the journal for logging and falls
>>> back to log to the kernel ring buffer if the journal is not available.
> 
> Make it fall back to syslog first, then, please.

Sorry, this not going to happen.
We won't develop and maintain a downstream patch for that and I'm pretty
sure upstream is not interested in that either since they have a
perfectly working solution for that.

So I'm closing the bug report as wontfix.




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



signature.asc
Description: OpenPGP digital signature

Bug#408954: checkroot.sh: should not skip running fsck with JFS root

[Pierre Ynard]

Hello,

I invite you guys to look inside /etc/init.d/checkroot.sh to see that
the check for AC power or battery is actually completely commented
out. So as far as battery is concerned, the question is moot, and the
filesystem is always checked.

The battery check was introduced in #326647 in 2005:

> While reviewing the patches from Ubuntu, I came across a nice
> improvement.  Make sure to not run fsck if the machine is running on
> battery.  This would make the boot process a lot better for laptops.

I haven't researched the original Ubuntu patch to check what the
rationale was when it was introduced there.

Then in 2009, it was pointed out in #526398 that this "can cause serious
data corruption if booting on battery power" and that skipping fsck
wasn't necessarily a nice idea. Some discussion already ensued about the
necessity and conditionality of running fsck at boot, similar to this
thread. The battery check was commented out, and #326647 was reopened.

So I would believe that this 2007 bug was already fixed at the same time
as #526398, when the battery check was reverted. Now there could be
other mishaps causing the reporter's JFS filesystem to be skipped, but I
don't see any and running on batteries was specifically mentioned. So as
for this bug report proper, I suspect it could be closed.

Now as for the discussion: /etc/init.d/checkroot.sh contains a check to
skip btrfs. /lib/init/mount-functions.sh contains checks specific to
the root fs to skip nfs and nfs4; and also /etc/fstab configurations
with the pass field set to 0 - which by the way was reported in #571241
to fail to skip trying to check an ubifs root (for which there is no
fsck utility). /etc/init.d/checkfs.sh contains checks to limit fsck
operations to the undocumented FSCKTYPES variable (which is ignored by
/etc/init.d/checkroot.sh) and calls fsck with -A to let it handle itself
the pass column of /etc/fstab. And finally, initscripts ships a dummy
fsck.nfs to cope with attempts that should already be prevented by the
above check for it.

So the current handling of this matter is not very rationalized.

Ted says that checking filesystems at boot is very much not a dead
concept. Yet there are some filesystems where it's undesirable or
impossible.

Do we want a blacklist, or a whitelist?

Do we want to delegate conditionality to particular implementations? If
so, which factors? Running on battery was suggested. Shipping a dummy
fsck.$type is a way to delegate the possibility or impossibility to fsck
to the implementation - but that doesn't seem like the best or most
flexible technical solution to me.

What is the difference between checking the root filesystem, and
checking other filesystems? Why would the logic to skip brtfs and nfs
apply only to checkroot.sh, why would checkroot.sh ignore FSCKTYPES?

Does the installer set up /etc/fstab configurations requesting to fsck
wrong filesystems to begin with, that we need checks to disable later
on? Shall we ask installer maintainers, open a bug if there isn't one?

Can we have a switch in fsck similar to -A to let it parse the pass
field of /etc/fstab for us, except when checking only one device
passed in argument, or only the root fs? That way we wouldn't have
to parse it ourselves too just for the root fs and pass it from
/lib/init/mount-functions.sh back to /etc/init.d/checkroot.sh.

Can we gather the filesystem blacklist/whitelist, FSCKTYPES handling,
is_fastboot_active check, and possibly battery check, all together and
factorized in a single place in /lib/init/mount-functions.sh?

That's what I would suggest.

Regards,

-- 
Pierre Ynard

Bug#922554: network-manager: NetworkManager continuously spinning, probably while checking for connectivity

[gpe]

On Tue, 26 Feb 2019 19:26:30 +0100 Michael Biebl  wrote:
> Control: tags -1 + moreinfo
> 
> Do you have network-manager-config-connectivity-debian installed or
> connectivity checking enabled otherwise?

Yes network-manager-config-connectivity-debian is installed

> Is the server reachable for the connectivity check reachable?

Not sure to understand the question but the connectivity is ok even if I kill
NetworManager to avoid CPU consumption.

BR

Bug#923546: inkscape: Unable to build Inkscape via apt-build

[David Kalnischkies]

Control: reassign -1 apt-build 0.12.47

On Fri, Mar 01, 2019 at 09:23:20PM +0100, Mattia Rizzolo wrote:
> On Fri, Mar 01, 2019 at 07:21:27PM +0100, jEsuSdA wrote:
> > I tried to build Inkscape via apt-build and it was impossible. The 
> > debian/rules
> > binary subprocess fails.
> 
> I have no idea what `apt --build` is doing, but:

While "apt --build" exists in terms of "apt source -b" this isn't used
here… as there really exists a "apt-build" package I am happy to pass it
on (yeah for uncontrolled namespace), but I feel obligated to mention
that this package is orphaned for years.

So as a tip for the reporter: Try if you can "handroll" what is done
here as in "apt build-dep" & "apt source -b". If that fails as well its
not a problem with apt-build and you can hand this report back to
inkscape (given that a package should usually build from source).
Although it might still be an issue with your system they will know best
how to make sense of failing builds of their packages.


> > CMake Error at /usr/share/cmake-3.13/Modules/CMakeTestCCompiler.cmake:52
> > (message):
> >   The C compiler
> > 
> > "/usr/lib/apt-build/cc"
> > 
> >   is not able to compile a simple test program.
> > 
> >   It fails with the following output:
> …
> > cc: error trying to exec 'cc1': execvp: No existe el fichero o el
> > directorio
> 
> This feels like something is off with either apt or your own system;
> reassigning to apt to check what they think, but most likely it's
> something at fault in your setup.

I don't speak español (guessed by report using es_ES) but that sounds
like "No such file or directory exists". Something like PATH issues,
missing dependencies or something like that perhaps.

Having a quick look at the open bugreports against apt-build suggests
that this could also be an instance of #358730 if apt-build really
continues even if build-dependencies aren't satisfied (I can envision
that to be a source of all sorts of fun).


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#923559: closed by Michael Biebl (Re: Bug#923559: systemd-udevd: writes to kernel log)

[Thorsten Glaser]

reopen 923559
thanks

Debian Bug Tracking System dixit:

>If this explanation is unsatisfactory and you have not received a
>better one in a separate message then please contact Michael Biebl 
> by
>replying to this email.

This is unsatisfactory.

>>This is expected behaviour. udevd uses the journal for logging and falls
>>back to log to the kernel ring buffer if the journal is not available.

Make it fall back to syslog first, then, please.

Thanks,
//m.

Bug#667738: libhttp-daemon-perl: HTTP::Daemon::ClientConn is IPv4 only

[gregor herrmann]

On Fri, 01 Mar 2019 16:49:46 +0100, gregor herrmann wrote:

> On Thu, 28 Feb 2019 18:56:28 +0100, gregor herrmann wrote:
> > On Wed, 27 Feb 2019 19:28:57 +0100, Fabian Grünbichler wrote:
> > > I opened up a MR on salsa[1] to include the patches from upstream's bug
> > > tracker that enable IPv6 support by switching to IO::Socket::IP - it
> > > would be great if somebody can take a look at them and upload the -2
> > > package ;)
> > Thanks for the merge request!
> > Merge and uploaded.
> > I hope you can also help in case this breaks reverse dependencies :)
> So this broke the test suites of 3 reverse dependencies:

Thanks to Fabian's efforts and help all 3 are fixed by now.

> While it should be possible to fix the three packages in general, I
> see 2 problems:
> - other breakage this might cause (in packages without autopkgtests
>   or in local/third-party code)
> - we're running out of time for buster (last upload possibility today
>   or maybe tomorrow)
> 
> At the beginning of a release cycle I'd be happy to work from here
> and fix what we see and what might come up, but I think now is a bad
> point of time for this approach.
> 
> So I think we should revert the change (i.e. disable the patches),
> and reopen he bug, and I'll do that tonight unless other ideas/fixes
> come up in the next hours.

I guess we can wait and see if anything else pops up or not; if not
than all is fine, if we see more troubles, disabling the patches
should still be possible during the freeze.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#923522: Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules

[Ben Hutchings]

Control: severity -1 minor

On Fri, 2019-03-01 at 12:07 +0100, riccardo.mu...@gmail.com wrote:
> Package: linux-image-4.9.0-8-amd64
> Version: 4.9.144-3.1
> 
> As of March 1, 2019, running `apt upgrade` on a recent Debian 9 official
> cloud image, results in package `linux-image-4.9.0-8-amd64` being
> upgraded:
> 
> $ apt list --upgradable
> [...]
> linux-image-4.9.0-8-amd64/stable-updates 4.9.144-3.1 amd64 [upgradable 
> from: 4.9.130-2]
> [...]
> 
> However, after the upgrade, kernel modules are no longer loadable; here
> is an example triggered by `ip6tables-restore`:
> 
> # tail /var/log/syslog 
> Mar  1 10:11:08 stretch kernel: [  502.887305] nf_defrag_ipv6: disagrees 
> about version of symbol inet_frags_fini
> Mar  1 10:11:08 stretch kernel: [  502.887894] nf_defrag_ipv6: Unknown 
> symbol inet_frags_fini (err -22)
> Mar  1 10:11:08 stretch kernel: [  502.888985] nf_defrag_ipv6: disagrees 
> about version of symbol inet_frag_find
> Mar  1 10:11:08 stretch kernel: [  502.889712] nf_defrag_ipv6: Unknown 
> symbol inet_frag_find (err -22)
> Mar  1 10:11:08 stretch kernel: [  502.890386] nf_defrag_ipv6: disagrees 
> about version of symbol ip6_expire_frag_queue
> Mar  1 10:11:08 stretch kernel: [  502.891048] nf_defrag_ipv6: Unknown 
> symbol ip6_expire_frag_queue (err -22)
> Mar  1 10:11:08 stretch kernel: [  502.891885] nf_defrag_ipv6: Unknown 
> symbol pskb_trim_rcsum_slow (err 0)
> Mar  1 10:11:08 stretch kernel: [  502.893030] nf_defrag_ipv6: disagrees 
> about version of symbol inet_frag_kill
> Mar  1 10:11:08 stretch kernel: [  502.893688] nf_defrag_ipv6: Unknown 
> symbol inet_frag_kill (err -22)
> Mar  1 10:11:08 stretch kernel: [  502.894594] xt_conntrack: cannot load 
> conntrack support for proto=10
> 
> The problem is that both packages install kernel modules in the same
> directory `/lib/modules/4.9.0-8-amd64` although they are not binary
> compatible.

This is a known issue with upgrades that we don't currently plan to
fix.

> Needless to say, the issue with loading kernel modules is corrected by a
> reboot, but I think that the larger issue here is that upgrading a
> kernel package, on the *stable* distribution and *keeping the same
> (nominal) kernel version*, can break a running system -- all while that a
> solution for this problem has been known for many years now...
>
> Thanks for any help!

Normally all required modules would be loaded during boot, so there's
no breakage.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.



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

Bug#867735: /etc/bash_completion.d/dlocate-completion: Re: dlocate completions

[Richard Lewis]

Package: dlocate
Version: 1.07+nmu1
Followup-For: Bug #867735

Dear all,

The following should make dlocate complete files:


*** /tmp/dlocate-completion.patch
--- dlocate-completion.orig 2019-03-01 23:12:53.653178500 +
+++ dlocate-completion.new  2019-03-01 23:13:16.221498109 +
@@ -22,6 +22,7 @@
COMPREPLY=( $( compgen -W '-h -H -V -S -L -l -s -ls -du \
-conf -lsconf -md5sum -md5check -man --help \
--version' -- $cur ) )
+   _filedir
return 0
;;
esac

Bug#923482: [pkg-gnupg-maint] Bug#923482: dirmngr HKPS fails due to poorly configured certificates on *.pool.sks-keyservers.net

[Jim Popovitch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2019-03-01 at 15:24 -0500, Daniel Kahn Gillmor wrote:
> Hi Jim--
> 
> On Thu 2019-02-28 14:51:07 -0500, Jim Popovitch wrote:
> > When a client uses HKPS keyservers dirmngr fails hard due to TLS
> > certificate validation errors:
> 
> what pool are you using in particular?  it looks to me like you're using
> "ha.pool.sks-keyservers.net"
> 
> However, https://sks-keyservers.net/overview-of-pools.php#pool_ha
> suggests that there is no guarantee that servers in that pool all offer
> hkps.  If you want hkps, you should use
> hkps://hkps.pool.sks-keyservers.net (conveniently, that happens to also
> be the default setting, which means it should be able to work with no
> keyserver setting in either ~/.gnupg/gpg.conf or ~/.gnupg/dirmngr.conf.


Daniel, The problem (and I know this isn't Debian specific, but it does
affect Debian users of dirmngr) is that the servers in hkps.pool.sks-
keyservers.net exist in Europe, whereas ha.pool and na.pool have greater
access. Ideally, in 2019, the totality of the pool servers should all
have TLS support.  Debian should be spearheading this effort.

- -Jim P.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEECPbAhaBWEfiXj/kxdRlcPb헹ᐔॱ萀⠤䇔数
fkXVtw//UUGEpK2pSY1YQehvvIX25BLlRkYO8HVw2z4BpuKvg1D08tHBxYDcO6ul
9yfyYfR5qDe0B7dicWsSU0/꬛찌艕엏텚链牱솓閙ꁯퟖ㖁ꘜ
R9RuYlMlXJ9YG/yPW0r7LkA/DuzZqH8jMPYeHQrtWVFx6loF7GsF3EYlQnW2Mzwk
zymP0eBCXPS2qFcE1atj05KAawrGuYDA3pLfsRnaGKiV8M44qpXUsj1EfMv2rPGD
pPGTn805kSPrGxRqTqa6u/020f08zg/G2kodkgeLG9L㶐�ᙸ㻊鯑
Fq/eLB잳ꙹ圌䲹㊎쭁ᴴ猭כ六暑瀋큥쏰．ꨯ㞷쵃ꛪ揲
gBSP8ixrhsGhN3XO塸㎐譃云㲙㐧䪻Ⴤꇎ㥛⦸㧐幙蟺
bfqAN6Kx62oE2ZX7B쩜譬�ꏱ掜莅➤魢ᙀﳕ쌕茾
ƒꐣ烘「椧崠固埫ᜁ␦궑㎎嬓᝵㧹䐲⹐ᠭ뀷
znARzoZ9pW᪪藮ﻱᮄᓜট꾠殞ⴀ�뽀쇒蝸Ⱙꌾ�놠䎨
yTA땞ⶱ앾뎾ﺅᨠ湗䷻嶻푱ۨ氠煚罤豶꫶珴=
=wO
-END PGP SIGNATURE-

Bug#902162: closed by Petter Reinholdtsen (Re: fixed 902162 in 2.2.5-2)

[Santiago Vila]

Hi. What we need is an upload for stable, because packages in stretch *must* 
build in stretch.

Until then, I see closing the bug as counter-productive and slightly
misleading, as it may give the false impression that the issue has
been dealt with.

Thanks.

Bug#923561: parted: Incorrect optimal alignment for USB device

[Kevin Locke]

Package: parted
Version: 3.2-24
Severity: normal

Dear Maintainer,

Running `parted /dev/sdb mkpart primary 0% 100%` on an 8TB Seagate
"Backup Plus Hub" USB3 drive results in a partition which starts at
65535s (33553920B), which is not a multiple of the physical block size
(4096B).  It also causes parted `parted /dev/sdb mkpart primary 1MiB 100%`
to print "Warning: The resulting partition is not properly aligned for
best performance."

If this partition is used by device-mapper, the kernel will print:

device-mapper: table: 254:2: adding target device sdb1 caused an alignment 
inconsistency: physical_block_size=4096, logical_block_size=512, 
alignment_offset=0, start=33553920

The drive has the following topology (lsblk -t /dev/sdb):

NAME ALIGNMENT MIN-IO   OPT-IO PHY-SEC LOG-SEC ROTA SCHED   RQ-SIZE  RA 
WSAME
sdb  0   4096 335539204096 5121 mq-deadline  60 128   
32M

Presumably the error occurs because parted is using the optimal_io_size
for alignment.  Since optimal_io_size is based on USB constraints rather
than disk constraints, it does not seem suitable for partition layout.

I would suggest ignoring optimal_io_size if it is not a multiple of
minimum_io_size, as done by cryptsetup[1].  Alternatively, 33553920
could be ignored specifically, since it seems common for USB disks.

This issue has been discussed elsewhere:
https://www.saout.de/pipermail/dm-crypt/2016-January/004934.html
https://bugzilla.redhat.com/show_bug.cgi?id=1513820
https://unix.stackexchange.com/q/340484
https://linux-blog.anracom.com/2018/12/03/linux-ssd-partition-alignment-problems-with-external-usb-to-sata-controllers-i/

Thanks for considering,
Kevin

[1]: https://gitlab.com/cryptsetup/cryptsetup/commit/b80278c0

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

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

Versions of packages parted depends on:
ii  libc6 2.28-7
ii  libparted23.2-24
ii  libreadline7  7.0-5
ii  libtinfo6 6.1+20181013-2

parted recommends no packages.

Versions of packages parted suggests:
pn  parted-doc  

-- no debconf information

Bug#922730: cannot browse anything

[積丹尼 Dan Jacobson]

https://www.google.com/search?q=gobject/gtype.c:4265:+type+id+'0'+is+invalid

Bug#923447: [Pkg-openssl-devel] Bug#923447: openssl breaks r-cran-openssl autopkgtest

[Jeroen Ooms]

On Fri, Mar 1, 2019 at 8:05 PM Sebastian Andrzej Siewior
 wrote:
>
> On 2019-03-01 11:16:35 [+0100], Jeroen Ooms wrote:
> > FWIW, the underlying problem in a regression in libssl though. So if
> > the problem appears for other packages you could also backport this
> > libssl patch: https://github.com/openssl/openssl/issues/8375
>
> Does this problem solve your problem or does it have nothing to do with
> the current situation?

As stated, that is the bug report in libssl which causes the crash in
r-cran-openssl (and the first reply links to a PR with a patch).

I have released a workaround in the R bindings so that it can work
with libssl 1.1.1b as-is. Hence in other to fix the crash in
r-cran-openssl, you either need to update to upstream version 1.2.2,
or alternatively, you could backport the libssl patch from the
discussion above.

Bug#922730: cannot browse anything

[積丹尼 Dan Jacobson]

Here's the situation on i686. Be sure to test on i686, not amd64, where
it works fine.

libwebkit2gtk-4.0-37:
  Installed: 2.23.91-1

epiphany-browser:
  Installed: 3.31.91-2

$ mkdir /tmp/p; HOME=/tmp/p epiphany-browser

You'll see it just shows it is loading about:overview, and it just loops over 
and over with:

** (epiphany:3475): WARNING **: 05:59:49.922: Web process crashed

(WebKitWebProcess:3679): GLib-GObject-WARNING **: 05:59:50.666: 
../../../gobject/gtype.c:4265: type id '0' is invalid

(WebKitWebProcess:3679): GLib-GObject-WARNING **: 05:59:50.682: can't peek 
value table for type '' which is not currently referenced

/usr/lib/i386-linux-gnu/webkit2gtk-4.0/MiniBrowser works fine though. It
can even browse web pages and files.

strace shows the loop is at

futex(0x14656c0, FUTEX_WAKE_PRIVATE, 1) = 1
clock_gettime(CLOCK_MONOTONIC, {tv_sec=5717, tv_nsec=613493764}) = 0
futex(0x143c9ec, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, 
{tv_sec=1551478070, tv_nsec=762190103}...

Anyway please fix "gtype.c:4265: type id '0' is invalid". Thank you.

Bug#829985: imagination: Uses deprecated gnome-common macros/variables

[Eriberto Mota]

Hi all,

For this specific package, I found:

autogen.sh:if [ -n "$GNOME2_DIR" ]; then
autogen.sh: ACLOCAL_FLAGS="-I $GNOME2_DIR/share/aclocal $ACLOCAL_FLAGS"
autogen.sh: LD_LIBRARY_PATH="$GNOME2_DIR/lib:$LD_LIBRARY_PATH"
autogen.sh: PATH="$GNOME2_DIR/bin:$PATH"

All issues are inside a file only.

Regards,

Eriberto

Bug#922823: possible fix

[Chiara Marmo]

Thanks Joris,

> 
> Possible fix:
> I tried adding the missing file arv-viewer.ui as follows:
> 
>   - Modify the source package aravis-0.6.0-1, adding the following line
> to debian/aravis-tools.install:
> 
> usr/share/aravis-0.6/arv-viewer.ui
> 

I've committed the fix on salsa.debian.org

Regards,

Chiara

-- 
Chiara Marmo
Ingénieur de Recherche GEOPS - Paris Sud-11
Bât 509
Tel: +33 (0)1 69 15 49 03 

Bug#875358: Powermock RC #875358

[Markus Koschany]

I have removed powermock from all reverse-dependencies. This bug should
no longer be a blocker for Buster and powermock can be safely removed
from testing.



signature.asc
Description: OpenPGP digital signature

Bug#923446: m2crypto: autopkgtest with new version of openssl: Connection refused

[Sebastian Andrzej Siewior]

On 2019-02-28 12:17:49 [+0100], Paul Gevers wrote:
> === FAILURES
> _ MiscSSLClientTestCase.test_cipher_ok
> 
> self = 
…
> tests/test_ssl.py:472:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> /usr/lib/python2.7/dist-packages/M2Crypto/SSL/Connection.py:303: in connect
> self.socket.connect(addr)

debugging on openssl side gives me the same result as in #923448 which
means m2crypto sets somewhere a DH with <2048 bits and now it fails. So
now the DH needs to be located :)

Sebastian

Bug#901636: mandoc: "mandoc -mdoc -T man" causes memory dump

[Bdale Garbee]

Bjarni Ingi Gislason  writes:

> On Fri, Jul 27, 2018 at 03:22:03AM -0600, Bdale Garbee wrote:
>> Bjarni Ingi Gislason  writes:
>> 
>> >   Output from "mandoc -mdoc -T man groff_mdoc.7":
>> 
>> Where is "groff_mdoc.7" from?  I have no such file on my system, so
>> there's no way for me to try and reproduce this error.
>> 
>
>   It is in the "groff" package.

Thanks.  I can confirm that I see this error on this source file, too,
with mdocml version 1.14.4-1.

I do not plan to pursue this further, though, since I don't actually use
mdocml any more.  Michael Stapelberg has been taking care of the package
since Feb 2017... I just realized we never actually updated the
Maintainer assertion in the package metadata to reflect that, though.
I've just made that update in the packaging repository for the next upload.

Regards,

Bdale


signature.asc
Description: PGP signature

Bug#923559: systemd-udevd: writes to kernel log

[Thorsten Glaser]

Package: udev
Version: 241-1
Severity: normal

Mar  1 23:09:44 tglase-nb vmunix: [  125.926361] systemd-udevd[2636]: 
link_config: autonegotiation is unset or enabled, the speed and duplex are not 
writable.

I expect this instead:

Mar  1 23:09:44 tglase-nb systemd-udevd[2636]: link_config: autonegotiation is 
unset or enabled, the speed and duplex are not writable.

I expect that the kernel log contains *only* messages originating
from the kernel.


-- Package-specific info:

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages udev depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-5
ii  libblkid12.33.1-0.1
ii  libc62.28-8
ii  libkmod2 26-1
ii  libselinux1  2.8-1+b1
ii  libudev1 241-1
ii  lsb-base 10.2018112800
ii  util-linux   2.33.1-0.1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
pn  systemd  

-- debconf information excluded
P: /devices/LNXSYSTM:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYSTM:
E: USEC_INITIALIZED=12497732
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXCPU:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:
E: USEC_INITIALIZED=12500139
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXCPU:01
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:
E: USEC_INITIALIZED=12501822
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXPWRBN:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: SUBSYSTEM=acpi
E: DRIVER=button
E: MODALIAS=acpi:LNXPWRBN:
E: USEC_INITIALIZED=12506453
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
E: SUBSYSTEM=input
E: PRODUCT=19/0/1/0
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PROP=0
E: EV=3
E: KEY=10 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: USEC_INITIALIZED=12912701
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event5
N: input/event5
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event5
E: SUBSYSTEM=input
E: DEVNAME=/dev/input/event5
E: MAJOR=13
E: MINOR=69
E: USEC_INITIALIZED=13017835
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: XKBMODEL=pc105
E: XKBLAYOUT=us
E: XKBOPTIONS=terminate:ctrl_alt_bksp
E: BACKSPACE=guess
E: KMAP=/etc/console-setup/KBDmir2U.map.gz
E: net.ifnames=0
E: LIBINPUT_DEVICE_GROUP=19/0/1:LNXPWRBN/button
E: TAGS=:power-switch:

P: /devices/LNXSYSTM:00/LNXSYBUS:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYBUS:
E: USEC_INITIALIZED=12504786
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXSYBUS:00/IBM0069:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/IBM0069:00
E: SUBSYSTEM=acpi
E: MODALIAS=
E: USEC_INITIALIZED=12512386
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXSYBUS:00/IBM0079:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/IBM0079:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:IBM0079:PNP0C15:LNXDOCK:
E: USEC_INITIALIZED=12510684
E: ID_VENDOR_FROM_DATABASE=IBM Brasil
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:PNP0A08:PNP0A03:
E: USEC_INITIALIZED=12509429
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00
E: SUBSYSTEM=acpi
E: DRIVER=video
E: MODALIAS=acpi:LNXVIDEO:
E: USEC_INITIALIZED=12520479
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:01
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:01
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=12522408
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:02
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:02
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=12522988
E: net.ifnames=0

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:03
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:03
E: SUBSYSTEM=acpi
E: 

Bug#923560: newer release (0.4.0) is available for 2 years by now

[Yaroslav Halchenko]

Package: python-citeproc
Version: 0.3.0-3
Severity: wishlist

Even though it seems to be officially under QA maintenance I have decided
to mention that a new release was out there for a while already.  There was an
initial attempt to update packaging for 0.4.0 but then it was rolled back
(instead of just branching off previous point) in
https://salsa.debian.org/python-team/modules/citeproc-py/commit/09c1bb10d81ba35e8e65b5ace6dfa9fe76b3520a
to proceed with maintenance 0.3.0-3 upload.

One outstanding issue I now recall was Build-Depends on rnc2rng which was yet
to be packaged, RFP for which is http://bugs.debian.org/865666 

It is a tiny library and comes with some tests, last commit from Jul 2018
though states that no 3.7 support yet


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

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

Versions of packages python-citeproc depends on:
ii  python   2.7.15-3
ii  python-lxml  4.2.5-1

python-citeproc recommends no packages.

python-citeproc suggests no packages.

-- debconf-show failed

Bug#923482: [pkg-gnupg-maint] Bug#923482: dirmngr HKPS fails due to poorly configured certificates on *.pool.sks-keyservers.net

[Daniel Kahn Gillmor]

Hi Jim--

On Thu 2019-02-28 14:51:07 -0500, Jim Popovitch wrote:
> When a client uses HKPS keyservers dirmngr fails hard due to TLS
> certificate validation errors:

what pool are you using in particular?  it looks to me like you're using
"ha.pool.sks-keyservers.net"

However, https://sks-keyservers.net/overview-of-pools.php#pool_ha
suggests that there is no guarantee that servers in that pool all offer
hkps.  If you want hkps, you should use
hkps://hkps.pool.sks-keyservers.net (conveniently, that happens to also
be the default setting, which means it should be able to work with no
keyserver setting in either ~/.gnupg/gpg.conf or ~/.gnupg/dirmngr.conf.

I'm closing this bug report because i think it's due to the
configuration error described above, but feel free to re-open it if you
have a different configuration from the one i've surmised.  just let me
know what your configuration is!

All the best,

--dkg


signature.asc
Description: PGP signature

Bug#923558: debian-parl: FTBFS (Not a blessed reference)

[Santiago Vila]

Package: src:debian-parl
Version: 1.9.17
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules binary-indep
test -x debian/rules
dh_testroot
dh_prep 
dh_installdirs -A 
mkdir -p "."
/usr/bin/make suite=bullseye
make[1]: Entering directory '/<>'
mkdir -p content/desktop/eu/
cd content/desktop/eu/ \
&& boxer compose \
--nodedir /<>/nodes \
--skeldir /<>/skel \
--suite bullseye \
desktop-eu
Must be an existing directory containing boxer classes (in $self->{"classdir"}) 
at (eval 177) line 52
"ClassDir" is a subtype of "Dir"
"Dir" is a subtype of "Path"
Not a blessed reference
make[1]: *** [Makefile:18: content/desktop/eu/preseed.cfg] Error 255
make[1]: Leaving directory '/<>'
make: *** [debian/blends.mk:81: content/desktop/preseed.cfg] 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 also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/debian-parl.html

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#923557: bubblewrap: insecure use of /tmp

[Jakub Wilk]

Package: bubblewrap
Version: 0.3.1-2
Tags: security

Is /run/user//.bubblewrap/ doesn't exist and couldn't be created 
(as was the case on my system), bubblewrap falls back to 
/tmp/.bubblewrap-/. Local attacker could exploit this to prevent 
other users from running bubblewrap, for example:


  getent passwd | cut -d: -f3 | xargs printf '/tmp/.bubblewrap-%d\n' | xargs 
touch

But it gets worse, because bubblewrap is happy to use existing 
/tmp/.bubblewrap-/, even when the directory is owned by some else. 
In the worst case, this could be exploited by a local user to execute 
arbitrary code in the container. (Though I couldn't find any way to 
exploit this without disabling protected_symlinks.)


--
Jakub Wilk

Bug#901636: mandoc: "mandoc -mdoc -T man" causes memory dump

[Bjarni Ingi Gislason]

On Fri, Jul 27, 2018 at 03:22:03AM -0600, Bdale Garbee wrote:
> Bjarni Ingi Gislason  writes:
> 
> >   Output from "mandoc -mdoc -T man groff_mdoc.7":
> 
> Where is "groff_mdoc.7" from?  I have no such file on my system, so
> there's no way for me to try and reproduce this error.
> 

  It is in the "groff" package.

-- 
Bjarni I. Gislason

Bug#923556: stretch-pu: package r-cran-igraph/1.0.1-1+deb9u1

[Dylan Aïssi]

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

Dear release team,
Upstream has fixed CVE-2018-20349 which is non-dsa.
I already backported a patch to unstable/testing and now I would like
to fix the Stretch version.
Please find attached a corresponding debdiff.

Best,
Dylan


r-cran-igraph_1.0.1-1+deb9u1.debdiff
Description: Binary data

Bug#923448: stunnel4: autopkgtest fails with new version of openssl: failed to set DH parameters at debian/tests/runtime line 295.

[gregor herrmann]

On Fri, 01 Mar 2019 22:16:39 +0100, Sebastian Andrzej Siewior wrote:

> On 2019-03-01 21:30:04 [+0100], gregor herrmann wrote:
> > On Fri, 01 Mar 2019 21:18:37 +0100, Sebastian Andrzej Siewior wrote:
> > 
> > > The patch attached fixes the issue in libanyevent-perl by setting the
> > > default DH value to 2048.
> > There's also a new AnyEvent release but I saw the "INCOMPATIBLE
> > CHANGE" in the changelog, and I don't think it changes what is
> > affected here?

Here a link was missing:
https://metacpan.org/diff/file?target=MLEHMANN/AnyEvent-7.15/=MLEHMANN%2FAnyEvent-7.14
 
> stunnel's autopkgtest (and everyone else using that API without using a
> DH2048+key since now the API rejects smaller values properly).

Ok.
 
> > > Moving forward:
> > > - apply the patch to libanyevent-perl and be done with it
> > > - tell the stunnel4 testsuite to use 2048bit DH instead the default
> > >   value.
> > 
> > Is this an alternative or are both steps needed?
> 
> Either/or. The last b release of openssl fixes the return code of one
> function. Since that change, setting < 2048bit DH key fails (before that
> it was also failed but with a success return value so everyone assumed
> that it worked).
> 
> So either libanyevent-perl changes the default DH key to 2048 (like in
> the patch attached) _or_ someome comes up with perl foo and makes sure 
> debian/tests/runtime in the block around line 276 - 295 specifies a dh
> with 2048 bits. My perl foo was enough to narrow it down to that area :)
> 
> I *think* that 2048bit DH keys should be default these days and this
> would avoid errors like that in the future.

Thanks for the clarification.
As roam offered to look into the issue earlier today in the bug log,
I suggest to let him handle the question and fix it either in
stunnel4 or libanyevent-perl (handy to involved in both areas :))


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#923448: stunnel4: autopkgtest fails with new version of openssl: failed to set DH parameters at debian/tests/runtime line 295.

[Sebastian Andrzej Siewior]

On 2019-03-01 21:30:04 [+0100], gregor herrmann wrote:
> On Fri, 01 Mar 2019 21:18:37 +0100, Sebastian Andrzej Siewior wrote:
> 
> > The patch attached fixes the issue in libanyevent-perl by setting the
> > default DH value to 2048.
> 
> There's also a new AnyEvent release but I saw the "INCOMPATIBLE
> CHANGE" in the changelog, and I don't think it changes what is
> affected here?

stunnel's autopkgtest (and everyone else using that API without using a
DH2048+key since now the API rejects smaller values properly).

> > Moving forward:
> > - apply the patch to libanyevent-perl and be done with it
> > - tell the stunnel4 testsuite to use 2048bit DH instead the default
> >   value.
> 
> Is this an alternative or are both steps needed?

Either/or. The last b release of openssl fixes the return code of one
function. Since that change, setting < 2048bit DH key fails (before that
it was also failed but with a success return value so everyone assumed
that it worked).

So either libanyevent-perl changes the default DH key to 2048 (like in
the patch attached) _or_ someome comes up with perl foo and makes sure 
debian/tests/runtime in the block around line 276 - 295 specifies a dh
with 2048 bits. My perl foo was enough to narrow it down to that area :)

I *think* that 2048bit DH keys should be default these days and this
would avoid errors like that in the future.

> Cheers,
> gregor

Sebastian

Bug#922974: unblock: nvidia-graphics-drivers/410.93-2

[Samuel Thibault]

Hello,

Andreas Beckmann, le mer. 27 févr. 2019 16:09:15 +0100, a ecrit:
> On Fri, 22 Feb 2019 15:12:17 +0100 Andreas Beckmann  wrote:
> > nvidia-graphics-drivers seems to need a force-hint since it drops the
> > driver parts for i386 and armhf (and the libraries for armhf as well).
> > This makes the arch:all meta-package hashcat-nvidia uninstallable on
> > i386 (since nvidia-smi is gone).
> 
> Hi,
> 
> I'd like to see this sorted out before I upload a new upstream release
> to unstable. Or are there more blockers for the migration that I'm
> currently not aware of? (Cruft packages should not be an issue.)
> 
> There is also #922976 which suggests hashcat to restrict to amd64 and/or
> add alternative dependencies to the respective packages from the 390xx
> legacy driver.

For information, the hashcat-nvidia which has the issue is just
a leaf meta-package with popcon 30, which is just a convenience
package for installing both hashcat and nvidia-opencl-icd which
provides acceleration (hashcat can work without it). The nvidia-smi
dependency is merely for getting the number of GPUs for inclusion in the
tab-completion help.

I don't think anybody still with an i386 system is using this
meta-package, so making it uninstallable on i386 shouldn't hurt anybody
(and we can easily fix that during the freeze).

Samuel

Bug#923214: g++-mingw-w64: Internal compiler error when include qfloat16.h, Qt5.12.

[Stephen Kitt]

On Mon, 25 Feb 2019 20:15:56 +0900, "K.Ohta" 
wrote:
> > Le 25/02/2019 07:49, Kyuma Ohta a écrit :  
> > > When building software with Qt, internal compiler error happend 
> > > useally.
> > 
> > Where did you get your build of Qt? Did you build it yourself?
> 
> Yes. I built from source-code at mirror site of Qt project (i.e.
> ftp.jaist.ac.jp), but failed as same of this reason.
> 
> > > I built from https://github.com/Artanejp/common_source_project_fm7
> > > with Qt5.12,*BUT* same issue happens at building Qt5.12.1 with this
> > > toolchain.
> > > 
> > > This issue has *not* happend 8.2.0-17 and before version,only this
> > > version.
> > 
> > To clarify, am I right in understanding the following?
> >
> > * common_source_project_fm7 build OK with gcc-mingw-w64 8.2.0-17+21, 
> > with both Qt 5.12 and Qt 5.12.1
> > * common_source_project_fm7 causes an ICE with gcc-mingw-w64 
> > 8.2.0-21+21.1, with both Qt 5.12 and Qt 5.12.1
> > 
> > Is that correct?  
> 
> Yes.(At least mainly)As of internal-compiler-error caused by Qt's these
> headers.
> 
> > If you can tell me where you installed Qt from, I’ll try to reproduce 
> > this and narrow the problem down. Given the small amount of changes 
> > between gcc-mingw-w64 21 and 21.1, it’s likely a regression between
> > gcc 8.2.0-17 and 8.2.0-21...  
> 
> I cross-build Qt with debian's tool chain and these attached scripts.
> A config script, config_sample.5.12.sh and a build-wrapper script
> make_cross.sh. # These includes some fixed directories, please modify them.

Thanks for all the information, I’ve reproduced this. It’s a regression
somewhere on the GCC 8 branch, I’m currently bisecting to find the exact
breaking patch.

Regards,

Stephen


pgp591dWncRSN.pgp
Description: OpenPGP digital signature

Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear

[fulvio ciriaco]

Dear Daniel,

On 3/1/19 8:48 PM, Daniel Kahn Gillmor wrote:
> On Fri 2019-03-01 16:54:45 +0100, fulvio ciriaco wrote:
>> I opened another session from VT with startx and
>> exec dbus-launch awesome
>> and the delay reappeared.
>>
>> The delay does not reappear with
>> exec awesome
> 
> ok, so it works without "dbus-launch".  in the scenario where you are
> *not* using dbus-launch, what does:
> 
>systemctl --user status dbus.service
> 
> show you?
> 
systemctl shows the same info in both cases.
I attach it.
Thank you
Fulvio

> if it's "active (running)" then i suspect the issue is that you were
> running multiple dbus user sessions, and gpg-agent was connected to a
> different dbus user session than the active gpg process.
> 
> In general, you want a single dbus user session.  so it sounds like
> simplifying your .xsession is the way to go :)
> 
> I'm closing this bug report (though you can still comment on it if
> you've got more followup) because it sounds like the diagnosis is:
> 
>  Deliberately running multiple concurrent dbus user sessions will
>  confuse gpg-agent and gpg.
> 
> and the resolution is:
> 
>  Do not start up a separate dbus user session!
> 
> If you find that the removal of dbus-launch from your ~/.xsession is a
> problem, and not something you can sustain going forward, please re-open
> this bug report and explain what incompatibilities you're running into,
> so we can try to figure it out further.
> 
> thanks all for your testing and diagnosis and feedback here!
> 
>--dkg
> 
● dbus.service - D-Bus User Message Bus
   Loaded: loaded (/usr/lib/systemd/user/dbus.service; static; vendor preset: 
enabled)
   Active: active (running) since Thu 2019-02-14 17:10:24 CET; 2 weeks 1 days 
ago
 Docs: man:dbus-daemon(1)
 Main PID: 1297 (dbus-daemon)
   CGroup: /user.slice/user-1000.slice/user@1000.service/dbus.service
   ├─ 1297 /usr/bin/dbus-daemon --session --address=systemd: --nofork 
--nopidfile --systemd-activation --syslog-only
   ├─ 7097 /usr/lib/dconf/dconf-service
   ├─ 7617 /usr/bin/gnome-keyring-daemon --start --foreground 
--components=secrets
   ├─13709 /usr/bin/kactivitymanagerd start-daemon
   └─13719 /usr/bin/kglobalaccel5


signature.asc
Description: OpenPGP digital signature

Bug#923555: unblock: kombu/4.2.1-2

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package kombu

the package FTBFS due to failing tests and 4.2.1-2 adds an upstream patch that
addressed this issue.
It also bumped standards version to 4.3.0 with no changes necessary and cleans
up build artifacts that were introduced by a newer pytest release since tha last
upload.

See attached debdiff for changes.

unblock kombu/4.2.1-2

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlx5mRMRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wo5HQf/Za1iUTzre1+QLjIAicFsbldIcV/2wOKP
BAe4XXVixv+y9IX/o3bIR3TkmJ5Yd3Bf/hhfXMxvINXPbd/OQsPXiB4Qx9TcPL61
DuX5cL4Fd6D4pFNtZMpyyvL6mppIXlcdlG2kGmXc/T8GVNg/1Z4uI+kwIRYIu+V5
alGNbuQzAUiVmsyGZf5tADCffkQAtbGzQucaJ+V1WZbBTSmBGauWreCgh8+XvgDj
8Phm/XwpHyZ/QD6hZ16vdTZ3v3VePqQpuzBl6RXfx7xMNBj3HiQQsgL6OVrw6xcQ
pbQElG6ueN0SM2jTjvL8Pj6c51rlSDHOw9CqxngMU4Y21BSQZNa81A==
=wcSM
-END PGP SIGNATURE-
diff -Nru kombu-4.2.1/debian/changelog kombu-4.2.1/debian/changelog
--- kombu-4.2.1/debian/changelog2018-06-20 10:02:04.0 +0200
+++ kombu-4.2.1/debian/changelog2019-03-01 20:03:25.0 +0100
@@ -1,3 +1,16 @@
+kombu (4.2.1-2) unstable; urgency=high
+
+  [ Ondřej Nový ]
+  * Use 'python3 -m sphinx' instead of sphinx-build for building docs
+
+  [ Michael Fladischer ]
+  * Apply upstream patch PR#978 to fix failing unittests of pyamqp
+transport (Closes: #921787).
+  * Clean up pytest artifacts to allow two builds in a row.
+  * Bump Standards-Version to 4.3.0.
+
+ -- Michael Fladischer   Fri, 01 Mar 2019 20:03:25 +0100
+
 kombu (4.2.1-1) unstable; urgency=low
 
   [ Ondřej Nový ]
diff -Nru kombu-4.2.1/debian/clean kombu-4.2.1/debian/clean
--- kombu-4.2.1/debian/clean2018-06-20 10:02:04.0 +0200
+++ kombu-4.2.1/debian/clean2019-03-01 20:03:25.0 +0100
@@ -1 +1,4 @@
 kombu.egg-info/
+.pytest_cache/README.md
+.pytest_cache/v/cache/nodeids
+.pytest_cache/v/cache/stepwise
diff -Nru kombu-4.2.1/debian/control kombu-4.2.1/debian/control
--- kombu-4.2.1/debian/control  2018-06-20 10:02:04.0 +0200
+++ kombu-4.2.1/debian/control  2019-03-01 20:03:25.0 +0100
@@ -55,7 +55,7 @@
 Build-Conflicts:
  python-cjson,
  python-sphinx,
-Standards-Version: 4.1.4
+Standards-Version: 4.3.0
 Homepage: https://github.com/celery/kombu/
 Vcs-Git: https://salsa.debian.org/python-team/modules/kombu.git
 Vcs-Browser: https://salsa.debian.org/python-team/modules/kombu
diff -Nru 
kombu-4.2.1/debian/patches/0004-Fix-failing-unittests-of-pyamqp-transport.patch 
kombu-4.2.1/debian/patches/0004-Fix-failing-unittests-of-pyamqp-transport.patch
--- 
kombu-4.2.1/debian/patches/0004-Fix-failing-unittests-of-pyamqp-transport.patch 
1970-01-01 01:00:00.0 +0100
+++ 
kombu-4.2.1/debian/patches/0004-Fix-failing-unittests-of-pyamqp-transport.patch 
2019-03-01 20:03:25.0 +0100
@@ -0,0 +1,27 @@
+From: Matus Valo 
+Date: Thu, 3 Jan 2019 06:43:31 -0800
+Subject: Fix failing unittests of pyamqp transport.
+
+Failing unittests were caused by commit 
f16df2a17630c9804a6da614443c5e862271823f in pyamqp.
+---
+ t/unit/transport/test_pyamqp.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/t/unit/transport/test_pyamqp.py b/t/unit/transport/test_pyamqp.py
+index 8292991..32094b4 100644
+--- a/t/unit/transport/test_pyamqp.py
 b/t/unit/transport/test_pyamqp.py
+@@ -68,11 +68,11 @@ class test_Channel:
+ assert self.channel.connection is None
+ 
+ def test_basic_consume_registers_ack_status(self):
+-self.channel.wait_returns = 'my-consumer-tag'
++self.channel.wait_returns = ['my-consumer-tag']
+ self.channel.basic_consume('foo', no_ack=True)
+ assert 'my-consumer-tag' in self.channel.no_ack_consumers
+ 
+-self.channel.wait_returns = 'other-consumer-tag'
++self.channel.wait_returns = ['other-consumer-tag']
+ self.channel.basic_consume('bar', no_ack=False)
+ assert 'other-consumer-tag' not in self.channel.no_ack_consumers
+ 
diff -Nru kombu-4.2.1/debian/patches/series kombu-4.2.1/debian/patches/series
--- kombu-4.2.1/debian/patches/series   2018-06-20 10:02:04.0 +0200
+++ kombu-4.2.1/debian/patches/series   2019-03-01 20:03:25.0 +0100
@@ -1,3 +1,4 @@
 0001-Remove-image-from-remote-donation-site-privacy-issue.patch
 0002-Disable-intershpinx-mapping-for-now.patch
 0003-Remove-pytest-sugar-from-test-requirements.patch

Bug#923554: libspring-java should have tightened (build) dependencies on aspectj

[Matthias Klose]

Package: src:libspring-java
Version: 4.3.22-1

libspring-java ftbfs with a too old aspectj (1.8.9). It builds with 1.9.2, so
please update both the dependencies and the build dependencies.

Bug#923448: stunnel4: autopkgtest fails with new version of openssl: failed to set DH parameters at debian/tests/runtime line 295.

[gregor herrmann]

On Fri, 01 Mar 2019 21:18:37 +0100, Sebastian Andrzej Siewior wrote:

> The patch attached fixes the issue in libanyevent-perl by setting the
> default DH value to 2048.

There's also a new AnyEvent release but I saw the "INCOMPATIBLE
CHANGE" in the changelog, and I don't think it changes what is
affected here?

> Moving forward:
> - apply the patch to libanyevent-perl and be done with it
> - tell the stunnel4 testsuite to use 2048bit DH instead the default
>   value.

Is this an alternative or are both steps needed?
 
Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#923553: poppler: CVE-2019-9543: recursive function call in function JBIG2Stream::readGenericBitmap()

[Salvatore Bonaccorso]

Source: poppler
Version: 0.71.0-2
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/issues/730

Hi,

The following vulnerability was published for poppler.

CVE-2019-9543[0]:
| An issue was discovered in Poppler 0.74.0. A recursive function call,
| in JBIG2Stream::readGenericBitmap() located in JBIG2Stream.cc, can be
| triggered by sending a crafted pdf file to (for example) the
| pdfseparate binary. It allows an attacker to cause Denial of Service
| (Segmentation fault) or possibly have unspecified other impact. This is
| related to JArithmeticDecoder::decodeBit.

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-9543
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9543
[1] https://gitlab.freedesktop.org/poppler/poppler/issues/730

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#923546: inkscape: Unable to build Inkscape via apt-build

[Mattia Rizzolo]

Control: reassign -1 apt
Control: severity -1 minor

Hi,

On Fri, Mar 01, 2019 at 07:21:27PM +0100, jEsuSdA wrote:
> I tried to build Inkscape via apt-build and it was impossible. The 
> debian/rules
> binary subprocess fails.

I have no idea what `apt --build` is doing, but:

> CMake Error at /usr/share/cmake-3.13/Modules/CMakeTestCCompiler.cmake:52
> (message):
>   The C compiler
> 
> "/usr/lib/apt-build/cc"
> 
>   is not able to compile a simple test program.
> 
>   It fails with the following output:
…
> cc: error trying to exec 'cc1': execvp: No existe el fichero o el
> directorio

This feels like something is off with either apt or your own system;
reassigning to apt to check what they think, but most likely it's
something at fault in your setup.

-- 
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#923552: poppler: CVE-2019-9545: Recursive function call at function JBIG2Stream::readTextRegion()

[Salvatore Bonaccorso]

Source: poppler
Version: 0.71.0-2
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/issues/731

Hi,

The following vulnerability was published for poppler.

CVE-2019-9545[0]:
| An issue was discovered in Poppler 0.74.0. A recursive function call,
| in JBIG2Stream::readTextRegion() located in JBIG2Stream.cc, can be
| triggered by sending a crafted pdf file to (for example) the pdfimages
| binary. It allows an attacker to cause Denial of Service (Segmentation
| fault) or possibly have unspecified other impact. This is related to
| JBIG2Bitmap::clearToZero.

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-9545
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9545
[1] https://gitlab.freedesktop.org/poppler/poppler/issues/731

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#923448: stunnel4: autopkgtest fails with new version of openssl: failed to set DH parameters at debian/tests/runtime line 295.

[Sebastian Andrzej Siewior]

+perl, last uploader of libanyevent-perl

On 2019-02-28 22:15:48 [+0100], To Paul Gevers wrote:
> On 2019-02-28 12:40:25 [+0100], Paul Gevers wrote:
> > Source: stunnel4
> > Version: 3:5.50-2
> 
> > __DIE__ handler invoked: dh params schmorp1539: failed to set DH
> > parameters at debian/tests/runtime line 295.
> > dh params schmorp1539: failed to set DH parameters at
> > debian/tests/runtime line 295.
> 
> This error is due to
> |commit 3b91ae1c07a4310778b3d7ba74ff4ff787f0
> |Author: Paul Yang 
> |Date:   Wed Nov 21 13:16:27 2018 +0800
> |
> |Fix wrong return value in ssl3_ctx_ctrl

The patch attached fixes the issue in libanyevent-perl by setting the
default DH value to 2048.
Moving forward:
- apply the patch to libanyevent-perl and be done with it
- tell the stunnel4 testsuite to use 2048bit DH instead the default
  value.

Sebastian
diff -purN libanyevent-perl-7.140/lib/AnyEvent/TLS.pm libanyevent-perl-7.140-patched/lib/AnyEvent/TLS.pm
--- libanyevent-perl-7.140/lib/AnyEvent/TLS.pm	2019-03-01 20:49:35.0 +0100
+++ libanyevent-perl-7.140-patched/lib/AnyEvent/TLS.pm	2019-03-01 21:05:56.410919571 +0100
@@ -472,7 +472,7 @@ of course.
 =item dh => $string
 
 Specify the Diffie-Hellman parameters in PEM format directly as a string
-(see C), the default is C unless C was
+(see C), the default is C unless C was
 specified.
 
 AnyEvent::TLS supports supports a number of precomputed DH parameters,
@@ -631,7 +631,7 @@ sub new {
   $dh_bio = Net::SSLeay::BIO_new_file ($dh_file, "r")
  or croak "$dh_file: failed to open DH parameter file: $!";
} else {
-  $arg{dh} = "schmorp1539" unless exists $arg{dh};
+  $arg{dh} = "schmorp2048" unless exists $arg{dh};
 
   if (defined $arg{dh}) {
  $dh_file = "dh string";

Bug#923551: dmarc-cat: fails when filename contains unique-id (and returns 0)

[Daniel Kahn Gillmor]

Package: dmarc-cat
Version: 0.9.2-1
Severity: normal

https://tools.ietf.org/html/rfc7489#section-7.2.1.1 says:

--
 filename = receiver "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension

 unique-id = 1*(ALPHA / DIGIT)
--

But:

0 dkg@alice:~/tmp$ ls -l 
'fastmail.com!fifthhorseman.net!1551312000!1551398399!189898144.xml.gz'
-rw--- 1 dkg dkg 559 Mar  1 15:02 
'fastmail.com!fifthhorseman.net!1551312000!1551398399!189898144.xml.gz'
0 dkg@alice:~/tmp$ dmarc-cat 
'fastmail.com!fifthhorseman.net!1551312000!1551398399!189898144.xml.gz'
2019/03/01 15:10:02 error handling 
fastmail.com!fifthhorseman.net!1551312000!1551398399!189898144.xml.gz: bad 
filename
0 dkg@alice:~/tmp$

It seems to work fine if the unique-id part of the filename isn't
present.

Additionally, i note that while dmarc-cat fails, the process as a
whole returns 0 (the first part of PS1 for me is $?).  This seems
problematic to me, as i'd expect a failing process to return a
non-zero error code.

 --dkg


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

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

Versions of packages dmarc-cat depends on:
ii  libassuan0 2.5.2-1
ii  libc6  2.28-7
ii  libgpg-error0  1.35-1
ii  libgpgme11 1.12.0-6

dmarc-cat recommends no packages.

dmarc-cat suggests no packages.

-- no debconf information

Bug#923550: dmarc-cat: Missing documentation

[Daniel Kahn Gillmor]

Package: dmarc-cat
Version: 0.9.2-1
Severity: normal

0 dkg@alice:~/tmp$ man dmarc-cat
No manual entry for dmarc-cat
See 'man 7 undocumented' for help when manual pages are not available.
16 dkg@alice:~/tmp$ dmarc-cat --help
Usage of dmarc-cat:
  -DDebug mode
  -NDo not resolve IPs
  -S string
Sort results (default "\"Count\" \"dsc\"")
  -j int
Parallel jobs (default 4)
  -vVerbose mode
  -version
Display version
2 dkg@alice:~/tmp$ ls -la /usr/share/doc/dmarc-cat/
total 164
drwxr-xr-x2 root root   4096 Mar  1 14:54 .
drwxr-xr-x 4242 root root 151552 Mar  1 14:54 ..
-rw-r--r--1 root root208 Feb  6 10:21 changelog.Debian.gz
-rw-r--r--1 root root   1905 Feb  6 10:21 copyright
0 dkg@alice:~/tmp$ 


This doesn't even tell me how i am supposed to invoke dmarc-cat or
point it to specific files.  Given the name "cat", i'd imagine i can
feed it documents on stdin, but that doesn't work.

having some minimal documentation would be useful!

Thanks for maintaining dmarc-cat in debian,

   --dkg

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

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

Versions of packages dmarc-cat depends on:
ii  libassuan0 2.5.2-1
ii  libc6  2.28-7
ii  libgpg-error0  1.35-1
ii  libgpgme11 1.12.0-6

dmarc-cat recommends no packages.

dmarc-cat suggests no packages.

-- no debconf information

Bug#922117: RFS: waybar/0.3.0-1 ITP

[Birger Schacht]

There has been a new release today- i've updated the packge on mentors
and pushed the changes to salsa.

cheers,
Birger

Bug#923549: open-infrastructure-compute-tools: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: open-infrastructure-compute-tools 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of open-
infrastructure-compute-tools debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip

Bug#921840: Fwd: Re: Upload necessary before March 2nd (Buster hard freeze), Bug #921840 NOAA URL -> https

[Kees Leune]

Ok!

On Fri, Mar 1, 2019 at 2:49 PM Joost van Baal-Ilić 
wrote:

> Hoi Kees,
>
> ( @ bugs.debian.org: sorry for speaking dutch here )
>
> Of ben je anders van plan een .tar.gz release te maken?
> Volgens je eigen instructies gaat dat met"
>
> 0. Assign a new version number in VERSION.m4, commit, push
> 1. Clone the repository from github
> 2. Remove .git/
> 3. rename the repository directory as metar-newversion-1
> 4. create a new tarball
> tar c --exclude debian -zf metar_newversion-1.origin.tar.gz
>
>
> Kun je die .tar.gz dan op github in "releases" zetten?  Of zet hem
> anders ergens op https://leune.org/ ter download, dat kan ook.
>
> Dan kan ikzelf wel voor de debian packaging zorgen.
>
> Groeten,
>
> Joost
>
>
> On Thu, Feb 28, 2019 at 08:05:28PM +0100, Joost van Baal-Ilić wrote:
> > Hoi hoi,
> >
> > OK, ik wacht ongeveer 24 uur af; daarna ga ikzelf wel aan de slag.
> Verwacht
> > dat we op die manier de deadline wel gaan halen :)
> >
> > Heel hartelijk bedankt iig!
> >
> > Groeten,
> >
> > Joost
> >
> > On Thu, Feb 28, 2019 at 01:51:43PM -0500, Kees Leune wrote:
> > > Hallo!
> > >
> > > Ik ben gisteren begonnen aan het package; kennelijk zijn de packaging
> rules
> > > weer veranderd en moet ik het hele ding naar nieuwe standaarden brengen
> > > voordat ik een schone linitian krijg. Dat kost (misschien) meer tijd
> dan ik
> > > heb, maar ik zal het proberen.
> > >
> > >
> > > On Thu, Feb 28, 2019 at 6:13 AM Joost van Baal-Ilić <
> joos...@debian.org>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Yes, I could invest one hour in getting this solved.
> > > >
> > > > Kees: laat me maar weten wat je nodig hebt.  (En hoe is t verder?)
> > > >
> > > > Groeten, Bye, Tschüß,
> > > >
> > > > Joost
> > > >
> > > >
> > > > On Thu, Feb 28, 2019 at 11:43:04AM +0100, Daniel Lange wrote:
> > > > > Hi Joost,
> > > > >
> > > > > we need an upload of a fixed metar before March 2nd to fix bug
> #921840.
> > > > > Kees will prepare that and I would have uploaded it today but my
> internet
> > > > > connection has been cut earlier today and will need 1-2 days for
> fixing.
> > > > So
> > > > > I'm using the phone to tether. No builds that way.
> > > > >
> > > > > So could you kindly jump in and co-ordinate with Kees to get metar
> > > > uploaded?
> > > > >
> > > > > Kind regards,
> > > > > Daniel
> > > > >
> > > > >
> > > > >  Weitergeleitete Nachricht 
> > > > > Betreff:  Re: Upload necessary before March 2nd (Buster hard
> > > > freeze), Bug
> > > > > #921840 NOAA URL -> https
> > > > > Datum:Wed, 27 Feb 2019 09:51:41 -0500
> > > > > Von:  Kees Leune 
> > > > > An:   Daniel Lange 
> > > > >
> > > > >
> > > > >
> > > > > The process was very different back then ;) Joost van Baal did my
> initial
> > > > > uploads.
> > > > >
> > > > > I'll take care of this later today!
> > > > >
> > > > > On Wed, Feb 27, 2019 at 9:16 AM Daniel Lange  > > > > > wrote:
> > > > >
> > > > > Hi Kees,
> > > > >
> > > > > Am 27.02.19 um 15:07 schrieb Kees Leune:
> > > > >  > No problem. How do I upload?
> > > > >
> > > > > You seem to have been able to upload yourself in the past (at
> least
> > > > > until 2007):
> > > > > https://tracker.debian.org/pkg/metar
> > > > > Or may be the process was vastly different back then from
> today.
> > > > >
> > > > > In any case you can upload to https://mentors.debian.net/
> > > > > and I or somebody else can grab it and upload for you.
> > > > >
> > > > > Kind regards,
> > > > > Daniel
> > > > >
> > > > > --
> > > > > https://www.leune.org/about
> > > >
> > >
> > >
> > > --
> > > https://www.leune.org/about
>
-- 
https://www.leune.org/about

Bug#921840: Fwd: Re: Upload necessary before March 2nd (Buster hard freeze), Bug #921840 NOAA URL -> https

[Joost van Baal-Ilić]

Hoi Kees,

( @ bugs.debian.org: sorry for speaking dutch here )

Of ben je anders van plan een .tar.gz release te maken?
Volgens je eigen instructies gaat dat met"

0. Assign a new version number in VERSION.m4, commit, push
1. Clone the repository from github
2. Remove .git/
3. rename the repository directory as metar-newversion-1
4. create a new tarball
tar c --exclude debian -zf metar_newversion-1.origin.tar.gz


Kun je die .tar.gz dan op github in "releases" zetten?  Of zet hem
anders ergens op https://leune.org/ ter download, dat kan ook.

Dan kan ikzelf wel voor de debian packaging zorgen.

Groeten,

Joost


On Thu, Feb 28, 2019 at 08:05:28PM +0100, Joost van Baal-Ilić wrote:
> Hoi hoi,
> 
> OK, ik wacht ongeveer 24 uur af; daarna ga ikzelf wel aan de slag.  Verwacht
> dat we op die manier de deadline wel gaan halen :)
> 
> Heel hartelijk bedankt iig!
> 
> Groeten,
> 
> Joost
> 
> On Thu, Feb 28, 2019 at 01:51:43PM -0500, Kees Leune wrote:
> > Hallo!
> > 
> > Ik ben gisteren begonnen aan het package; kennelijk zijn de packaging rules
> > weer veranderd en moet ik het hele ding naar nieuwe standaarden brengen
> > voordat ik een schone linitian krijg. Dat kost (misschien) meer tijd dan ik
> > heb, maar ik zal het proberen.
> > 
> > 
> > On Thu, Feb 28, 2019 at 6:13 AM Joost van Baal-Ilić 
> > wrote:
> > 
> > > Hi,
> > >
> > > Yes, I could invest one hour in getting this solved.
> > >
> > > Kees: laat me maar weten wat je nodig hebt.  (En hoe is t verder?)
> > >
> > > Groeten, Bye, Tschüß,
> > >
> > > Joost
> > >
> > >
> > > On Thu, Feb 28, 2019 at 11:43:04AM +0100, Daniel Lange wrote:
> > > > Hi Joost,
> > > >
> > > > we need an upload of a fixed metar before March 2nd to fix bug #921840.
> > > > Kees will prepare that and I would have uploaded it today but my 
> > > > internet
> > > > connection has been cut earlier today and will need 1-2 days for fixing.
> > > So
> > > > I'm using the phone to tether. No builds that way.
> > > >
> > > > So could you kindly jump in and co-ordinate with Kees to get metar
> > > uploaded?
> > > >
> > > > Kind regards,
> > > > Daniel
> > > >
> > > >
> > > >  Weitergeleitete Nachricht 
> > > > Betreff:  Re: Upload necessary before March 2nd (Buster hard
> > > freeze), Bug
> > > > #921840 NOAA URL -> https
> > > > Datum:Wed, 27 Feb 2019 09:51:41 -0500
> > > > Von:  Kees Leune 
> > > > An:   Daniel Lange 
> > > >
> > > >
> > > >
> > > > The process was very different back then ;) Joost van Baal did my 
> > > > initial
> > > > uploads.
> > > >
> > > > I'll take care of this later today!
> > > >
> > > > On Wed, Feb 27, 2019 at 9:16 AM Daniel Lange  > > > > wrote:
> > > >
> > > > Hi Kees,
> > > >
> > > > Am 27.02.19 um 15:07 schrieb Kees Leune:
> > > >  > No problem. How do I upload?
> > > >
> > > > You seem to have been able to upload yourself in the past (at least
> > > > until 2007):
> > > > https://tracker.debian.org/pkg/metar
> > > > Or may be the process was vastly different back then from today.
> > > >
> > > > In any case you can upload to https://mentors.debian.net/
> > > > and I or somebody else can grab it and upload for you.
> > > >
> > > > Kind regards,
> > > > Daniel
> > > >
> > > > --
> > > > https://www.leune.org/about
> > >
> > 
> > 
> > -- 
> > https://www.leune.org/about

Bug#922976: hashcat-nvidia: should be restricted to arch:amd64

[Samuel Thibault]

Samuel Thibault, le ven. 01 mars 2019 11:43:12 -0800, a ecrit:
> Andreas Beckmann, le ven. 22 févr. 2019 15:35:25 +0100, a ecrit:
> > It's probably sufficient to restrict the architecture of this
> > metapackage to amd64 (or amd64 i386, if nvidia-smi can be downgraded to
> > a Recommends).
> 
> nvidia-smi seems to be only used in the tab-completion help, so I'd say
> we should just downgrade to recommends.

I'd say we should just NMU-upload this, for nvidia-graphics-drivers
to be able to migrate at worse 10 days from now, before the freeze
deadline.

Samuel

Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear

[Daniel Kahn Gillmor]

On Fri 2019-03-01 16:54:45 +0100, fulvio ciriaco wrote:
> I opened another session from VT with startx and
> exec dbus-launch awesome
> and the delay reappeared.
>
> The delay does not reappear with
> exec awesome

ok, so it works without "dbus-launch".  in the scenario where you are
*not* using dbus-launch, what does:

   systemctl --user status dbus.service

show you?

if it's "active (running)" then i suspect the issue is that you were
running multiple dbus user sessions, and gpg-agent was connected to a
different dbus user session than the active gpg process.

In general, you want a single dbus user session.  so it sounds like
simplifying your .xsession is the way to go :)

I'm closing this bug report (though you can still comment on it if
you've got more followup) because it sounds like the diagnosis is:

 Deliberately running multiple concurrent dbus user sessions will
 confuse gpg-agent and gpg.

and the resolution is:

 Do not start up a separate dbus user session!

If you find that the removal of dbus-launch from your ~/.xsession is a
problem, and not something you can sustain going forward, please re-open
this bug report and explain what incompatibilities you're running into,
so we can try to figure it out further.

thanks all for your testing and diagnosis and feedback here!

   --dkg


signature.asc
Description: PGP signature

Bug#923548: unblock: postfix/3.4.0-2

[Scott Kitterman]

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

Please unblock package postfix

I realize 'unblock' is slightly jumping the gun, but I would like to solicit
feedback/agreement from the release team before doing something non-minimal
right before freeze.

Upstream postfix has just release 3.4.0.  I would like to include it in
Buster.  I know it's late, but I think it's worth doing anyway.  Here are the
new features relevant to Debian (from the RELEASE_NOTES):

=
Major changes - bdat support


[Feature 20180826] Postfix SMTP server support for RFC 3030 CHUNKING
(the BDAT command) without BINARYMIME, in both smtpd(8) and
postscreen(8). This has no effect on Milters, smtpd_mumble_restrictions,
and smtpd_proxy_filter. See BDAT_README for more.

Major changes - containers
--

N/A for Debian package.

Major changes - database support


[Feature 20181105] Support for (key, list of filenames) in map
source text.

- Currently, this feature is used only by tls_server_sni_maps.

- When a map is created from source with "postmap -F maptype:mapname",
  the command processes each key as usual and processes each value
  as a list of filenames, concatenates the content of those files
  (with one newline character in-between files), and stores an entry
  with (key, base64-encoded result).

- When a map is queried with "postmap -F -q ...", the command
  base64-decodes each value. It reports an error when a value is
  not in base64 form.

  This "postmap -F -q ..." behavior also works when querying the
  memory-resident map types cidr:, inline:, pcre:, randmap:, regexp:,
  and static:. Postfix reads the files specified as table values,
  stores base64-encoded content, and base64-decodes content upon
  table lookup.

  Internally, Postfix will turn on this behavior for lookups (not
  updates) when a map is opened with the DICT_FLAG_RHS_IS_FILE flag.

Major changes - logging
---

[Feature 20190126] Support for logging to file or stdout, instead
of using syslog.

N/A for Debian package.

Major changes - safety
--

[Feature 20180623] Automatic retirement: dnsblog(8) and tlsproxy(8) process
will now voluntarily retire after after max_idle*max_use, or some
sane limit if either limit is disabled. Without this, a process
could stay busy for days or more.

Major changes - tls connection pooling
--

[Feature 20180617] Postfix SMTP client support for multiple deliveries
per TLS-encrypted connection. This is primarily to improve mail
delivery performance for destinations that throttle clients when
they don't combine deliveries.

This feature is enabled with "smtp_tls_connection_reuse=yes" in
main.cf, or with "tls_connection_reuse=yes" in smtp_tls_policy_maps.
It supports all Postfix TLS security levels including dane and
dane-only.

The implementation of TLS connection reuse relies on the same
scache(8) service as used for delivering plaintext SMTP mail, the
same tlsproxy(8) daemon as used by the postscreen(8) service for
inbound connections, and relies on the same hints from the qmgr(8)
daemon. It reuses the configuration parameters described in
CONNECTION_CACHE_README.

The Postfix SMTP client now logs whether an SMTP-over-TLS connection
is newly established ("TLS connection established") or whether the
connection is reused ("TLS connection reused").

The following illustrates how TLS connections are reused:

Initial plaintext SMTP handshake:
  smtp(8) -> remote SMTP server

Reused SMTP/TLS connection, or new SMTP/TLS connection:
  smtp(8) -> tlsproxy(8) -> remote SMTP server

Cached SMTP/TLS connection:
  scache(8) -> tlsproxy(8) -> remote SMTP server

Major changes - tls support
---

[Feature 20190106] SNI support in the Postfix SMTP server, the
Postfix SMTP client, and in the tlsproxy(8) daemon (both server and
client roles). See the postconf(5) documentation for the new
tls_server_sni_maps and smtp_tls_servername parameters.

[Feature 20190106] Support for files that contain multiple (key,
certificate, trust chain) instances. This was required to implement
server-side SNI table lookups, but it also eliminates the need for
separate cert/key files for RSA, DSA, Elliptic Curve, and so on.
The file format is documented in the TLS_README sections "Server-side
certificate and private key configuration" and "Client-side certificate
and private key configuration", and in the postconf(5) documentation
for the parameters smtp_tls_chain_files, smtpd_tls_chain_files,
tlsproxy_client_chain_files, and tlsproxy_tls_chain_files.

Note: the command "postfix tls" does not yet support the new
consolidated certificate chain format.  If you switch to the new
format, you'll need to manage your keys and certificates directly,
rather than via postfix-tls(1).

Major changes - usability

Bug#922976: hashcat-nvidia: should be restricted to arch:amd64

[Samuel Thibault]

Hello,

Andreas Beckmann, le ven. 22 févr. 2019 15:35:25 +0100, a ecrit:
> with the 410.xx nvidia-graphics-drivers series upstream dropped driver
> support for 32bit architectures.
> nvidia-smi is only available on amd64, nvidia-opencl-icd is still
> available on i386, too. (While nvidia-smi (and libcuda1) was available
> on armhf, nvidia-opencl-icd was never available there.)

For information, this is preventing nvidia-graphics-drivers from
entering testing since it makes hashcat-nvidia uninstallable on i386.

> It's probably sufficient to restrict the architecture of this
> metapackage to amd64 (or amd64 i386, if nvidia-smi can be downgraded to
> a Recommends).

nvidia-smi seems to be only used in the tab-completion help, so I'd say
we should just downgrade to recommends.

Samuel

Bug#923508: systemd not restarting sshd on Debian 9 Stretch i386 due to RestartPreventExitStatus=255 in sshd.service file

[Michael Biebl]

Control: tags -1 + moreinfo

[snip]

I don't understand what this bug report is supposed to be about.
Is it about sshd.service using RestartPreventExitStatus=255 (in which
case you should file the bug report against the openssh-server) package.

Or is it about your drop-in snippets not being applied?

Or something else?




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



signature.asc
Description: OpenPGP digital signature

Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log

[Vincent Blut]

Control: tags -1 pending

On Thu, Feb 28, 2019 at 11:36:10PM +0100, Francesco Poli wrote:

On Thu, 28 Feb 2019 21:11:48 +0100 Vincent Blut wrote:

[...]

On Wed, Feb 27, 2019 at 10:26:13PM +0100, Francesco Poli wrote:

[...]

>File chronyd_debug.txt is attached (gzipped).

That correspond to what I’m seeing in my tests. Upstream have applied
the patch I submitted to fix this so it should find its way in Debian in
the next days.

[...]

That's great news!   :-)
I really appreciate everything you did to deal with this bug.


Thanks for the kind words. :-)

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#853042: (no subject)

[Lluís Gili]

it may be your hosting provider, changing this file on install time

like Hetzner does:
https://wiki.hetzner.de/index.php/Installimage/en#Particularities

regards,
Lluís

Bug#923542: Error: parsed key is not in key set: 'RuleFile'

[Birger Schacht]

control: forwarded -1 https://github.com/USBGuard/usbguard/issues/269

Hi Enrico!

thanks for filing a bug! Apparently its not unsupported options (it
happens with every key in the config file) but the parser seems broken.
There is an issue in the upstream issue tracker about this, thus setting
the forwarded address.

cheers,
Birger

Bug#923447: [Pkg-openssl-devel] Bug#923447: openssl breaks r-cran-openssl autopkgtest

[Sebastian Andrzej Siewior]

On 2019-03-01 11:16:35 [+0100], Jeroen Ooms wrote:
> FWIW, the underlying problem in a regression in libssl though. So if
> the problem appears for other packages you could also backport this
> libssl patch: https://github.com/openssl/openssl/issues/8375

Does this problem solve your problem or does it have nothing to do with
the current situation?

Sebastian

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

[Emmanuel Bourg]

Le 01/03/2019 à 18:29, Markus Koschany a écrit :

> I have never extended security permissions of
> another systemd service. How is this supposed to work?

I'm not used to this either, but I think we just have to install a
/etc/systemd/system/tomcat9.d/solr-permissions.conf file with theses lines:

  [Service]
  ReadWritePaths=/var/lib/solr/

A call to 'systemctl daemon-reload' is probably needed in the postinst
script (but maybe there is a trigger taking care of that already).

Bug#923529: giada: FTBFS (error: expected ')' before '*' token)

[Andrey Rahmatullin]

The code giving the errors is actually from juce-modules-source. The
version used for building the current sid giada package is 5.3.2~repack-1,
while the version in sid (which causes FTBFS) is
5.4.1+really5.4.1~repack-2. This seems to be related to #913915, I have no
idea how can the current sid version work as some things in
juce_VSTPluginFormat.cpp are not defined anywhere.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#922462: git debrebase convert-from-gbp fails on cups-filters with unhelpful error message

[Ian Jackson]

Ian Jackson writes ("Re: Bug#922462: git debrebase convert-from-gbp fails on 
cups-filters with unhelpful error message"):
> Doing that git-diff rune shows that you have made changes to the
> toplevel .gitignore which are not in any patch.
> 
> I'm not sure whether git-debrebase convert-from-gbp should
> automatically turn your .gitignore changes into a delta queue commit.
> What do people think ?

I should expand on this to explain why the answer to this question is
not simply `yes'.  ISTM that in a number of cases, the maintainer will
want instead to drop (some of) the .gitignore changes.

For example, in this case the change made to the upstream .gitignore
was precisely to ignore `.pc'.  Of course with git-debrebase one never
encounters a .pc directory and there is no need to have it in
.gitignore.


So, Didier:

If you git rm your .gitignore, you can do the conversion.  You will
unfortunately encounter another half-broken error message.  In that
case, the correct message would be:

git-debrebase: snag detected (-funexpected-upstream-changes): history between 
upstream (upstream/1.22.1) and HEAD contains direct changes to upstream files - 
are you sure this is a gbp (patches-unapplied) branch?
list expected changes with:  git log --stat --ancestry-path 
0030fffefd69db302f302c3494a08f192609b2a2..HEAD -- :/ ':!/debian'

and running this shows two commits: `Merge upstream 1.22.1 version and
refresh git-dpm patches' where presumably .gitignore came in, and the
one I made which removed .gitignore again.  This is as expected,
under the circumstances.

With -funexpected-upstream-changes the conversion seems to go ahead.


I will fix the broken messages.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#922462: git debrebase convert-from-gbp fails on cups-filters with unhelpful error message

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Bug#922462: git debrebase convert-from-gbp fails 
on cups-filters with unhelpful error message"):
> Just after importing cups-filters' latest upstream releas, I considered moving
> to git debrebase (for the occasional patches); but didn't manage:
> 
> $ export LANG=C
> $ git clone -b debian/experimental 
> https://salsa.debian.org/printing-team/cups-filters/ cups-filters 
> $ cd cups-filters
> $ git debrebase convert-from-gbp
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
> Use of uninitialized value $_[1] in sprintf at 
> /usr/share/dgit/gdr/perl5/Debian/Dgit/I18n.pm line 26.
>  at /usr/share/dgit/gdr/perl5/Debian/Dgit.pm line 145.
> Debian::Dgit::__ANON__("Use of uninitialized value \$_[1] in 
> sprintf at /usr/share/dgi"...) called at 
> /usr/share/dgit/gdr/perl5/Debian/Dgit/I18n.pm line 26
> Debian::Dgit::I18n::f_("upstream (%s) and HEAD are 
> not\x{a}identical in upstream files.  "..., undef, undef) called at 
> /usr/bin/git-debrebase line 2562
> main::cmd_convert_from_gbp() called at /usr/bin/git-debrebase 
> line 3050

Well, I have fixed bug which was just in the error handling.  The
message you should have received is this:

git-debrebase: error: upstream (upstream/1.22.1) and HEAD are not
git-debrebase: identical in upstream files.  See diffstat above, or run
git-debrebase:   git diff 0030fffefd69db302f302c3494a08f192609b2a2 HEAD -- 
:!/debian :/

Doing that git-diff rune shows that you have made changes to the
toplevel .gitignore which are not in any patch.

I'm not sure whether git-debrebase convert-from-gbp should
automatically turn your .gitignore changes into a delta queue commit.
What do people think ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#759725: [Pkg-postgresql-public] #759725: postgresql-common: non-synchronous service postgresql stop

[Christoph Berg]

Re: To b...@debian.org 2015-12-18 <20151218150513.gd28...@msg.df7cb.de>
> an update here: unfortunately it seems rather involved to have an
> umbrella service such as postgresql.service wait both for sub-service
> start and stop. Achieving one or the other is rather easy, we can just
> put "Before=postgresql.service" into postgresql@.service (sync start,
> this is what we have now), or "After=..." (sync stop), but not both.

There is a workaround that hasn't been mentioned here yet:

systemctl stop postgresql "postgresql@*"

> We'd really like to get this fixed, but at the moment it looks like
> synchronous start will have to do for now...

This needs fixing in systemd, I don't think we can do it on the PG
side.

Christoph

Bug#923547: libcaf-doc: missing Breaks+Replaces: libcaf-dev (<< 0.16.3)

[Andreas Beckmann]

Package: libcaf-doc
Version: 0.16.3-0.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../libcaf-doc_0.16.3-0.1_all.deb ... 

   Unpacking libcaf-doc 
(0.16.3-0.1) ...

dpkg: error processing archive 
/var/cache/apt/archives/libcaf-doc_0.16.3-0.1_all.deb (--unpack):   

   trying to overwrite 
'/usr/share/doc/libcaf-dev/manual.pdf.gz', which is also in package libcaf-dev 
0.13.2-3
 dpkg-deb: error: subprocess paste was killed 
by signal (Broken pipe) 

Errors were encountered while processing:   

  
/var/cache/apt/archives/libcaf-doc_0.16.3-0.1_all.deb   

  

cheers,

Andreas


libcaf-dev=0.13.2-3_libcaf-doc=0.16.3-0.1.log.gz
Description: application/gzip

Bug#923545: ninja-build: Package ninja 1.9.0

[Gregor Jasny]

Package: ninja-build
Version: 1.8.2-1
Severity: wishlist

Hello,

could you please package ninja 1.9.0? If you need help I could
prepare a merge request on salsa.

Thanks,
Gregor

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.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

Versions of packages ninja-build depends on:
ii  libc6   2.28-5
ii  libstdc++6  8.2.0-14

ninja-build recommends no packages.

ninja-build suggests no packages.

-- no debconf information

Bug#923546: inkscape: Unable to build Inkscape via apt-build

[jEsuSdA]

Package: inkscape
Version: 0.92.4-2
Severity: important

Dear Maintainer,

I tried to build Inkscape via apt-build and it was impossible. The debian/rules
binary subprocess fails.

Here te ouput:


-> Downloading source inkscape (0.92.4-2) <-
Leyendo lista de paquetes... Hecho
NOTA: el empaquetamiento de «inkscape» se mantiene en el sistema de control de
versiones «Git» en:
https://salsa.debian.org/multimedia-team/inkscape.git
Utilice:
git clone https://salsa.debian.org/multimedia-team/inkscape.git
para obtener las últimas actualizaciones (posiblemente no publicadas aún) del
paquete.
Omitiendo el fichero ya descargado «inkscape_0.92.4-2.dsc»
Se necesita descargar 32,0 MB de archivos fuente.
Des:1 http://ftp.de.debian.org/debian testing/main inkscape 0.92.4-2 (tar)
[31,9 MB]
Des:2 http://ftp.de.debian.org/debian testing/main inkscape 0.92.4-2 (asc) [833
B]
Des:3 http://ftp.de.debian.org/debian testing/main inkscape 0.92.4-2 (diff)
[29,0 kB]
Descargados 19,2 MB en 1s (15,2 MB/s)
dpkg-source: información: extrayendo inkscape en inkscape-0.92.4
dpkg-source: información: desempaquetando inkscape_0.92.4.orig.tar.bz2
dpkg-source: información: desempaquetando inkscape_0.92.4-2.debian.tar.xz
dpkg-source: información: using patch list from debian/patches/series
dpkg-source: información: aplicando
«0001-Drop_PS_and_PDF_support_in_MimeType.patch»
dpkg-source: información: aplicando «0002-typos-libcroco.patch»
dpkg-source: información: aplicando «upstream/0003-localized-manpages»
dpkg-source: información: aplicando «upstream/0004-crash-snap-lp1796046.patch»
dpkg-source: información: aplicando «upstream/0005-Make-the-command-line-PDF-
output-reproducible.patch»
dpkg-source: información: aplicando «upstream/0006-Fix-typo-s-Distrubute-
Distribute.patch»
dpkg-source: información: aplicando «upstream/0007-Update-the-appstream-
metadata-file-from-the-upstream.patch»
W: Download is performed unsandboxed as root as file
'inkscape_0.92.4.orig.tar.bz2' couldn't be accessed by user '_apt'. -
pkgAcquire::Run (13: Permiso denegado)
-> Building inkscape <-
dpkg-buildpackage: información: paquete fuente inkscape
dpkg-buildpackage: información: versión de las fuentes 0.92.4-2+aptbuild1
dpkg-buildpackage: información: distribución de las fuentes UNRELEASED
dpkg-buildpackage: información: fuentes modificadas por root

dpkg-buildpackage: información: arquitectura del sistema amd64
 dpkg-source --before-build .
 debian/rules clean
dh clean --buildsystem cmake --with python2,bash-completion --without
autoreconf
   dh_auto_clean -O--buildsystem=cmake
   dh_clean -O--buildsystem=cmake
 debian/rules binary
dh binary --buildsystem cmake --with python2,bash-completion --without
autoreconf
   dh_update_autotools_config -O--buildsystem=cmake
   debian/rules override_dh_auto_configure-arch
make[1]: se entra en el directorio '/var/cache/apt-build/build/inkscape-0.92.4'
dh_auto_configure -- \
-DWITH_DBUS=ON \

cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DWITH_DBUS=ON ..
--
Building Makefile for Inkscape
--
Source Dir: /var/cache/apt-build/build/inkscape-0.92.4
Binary Dir: /var/cache/apt-build/build/inkscape-0.92.4/obj-x86_64-linux-gnu
-- Creating build files in: /var/cache/apt-
build/build/inkscape-0.92.4/obj-x86_64-linux-gnu
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working C compiler: /usr/lib/apt-build/cc
-- Check for working C compiler: /usr/lib/apt-build/cc -- broken
CMake Error at /usr/share/cmake-3.13/Modules/CMakeTestCCompiler.cmake:52
(message):
  The C compiler

"/usr/lib/apt-build/cc"

  is not able to compile a simple test program.

  It fails with the following output:

Change Dir: /var/cache/apt-build/build/inkscape-0.92.4/obj-x86_64-linux-
gnu/CMakeFiles/CMakeTmp

Run Build Command:"/usr/lib/apt-build/make" "cmTC_3b735/fast"
make[2]: se entra en el directorio '/var/cache/apt-
build/build/inkscape-0.92.4/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/lib/apt-build/make -f CMakeFiles/cmTC_3b735.dir/build.make
CMakeFiles/cmTC_3b735.dir/build
make[3]: se entra en el directorio '/var/cache/apt-
build/build/inkscape-0.92.4/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
make[3]: warning: -j4 forced in submake: resetting jobserver mode.
Building C object CMakeFiles/cmTC_3b735.dir/testCCompiler.c.o
/usr/lib/apt-build/cc   -g -O2 -fdebug-prefix-map=/var/cache/apt-
build/build/inkscape-0.92.4=. -fstack-protector-strong -Wformat -Werror=format-
security -Wdate-time -D_FORTIFY_SOURCE=2-o
CMakeFiles/cmTC_3b735.dir/testCCompiler.c.o   -c /var/cache/apt-

Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2

[Jonas Meurer]

Georg Faerber:
> Hi all,
> 
> I've just uploaded 0.8.0-1 to unstable, which ships .epub support as
> requested by some people and the patch to make the Nautilus extension
> work. It should migrate on March 10 or the day after.
> 
> On 19-02-26 11:31:21, Jonas Meurer wrote:
>> After I slept a night over it, I realized that this plan doesn't take
>> into account our options to still handle the mat1 -> mat2 transition
>> in time for buster. After all we agreed on that mat(1) should better
>> not be shipped with buster. Now that we have at least a Nautilus
>> extension for mat2, there's no blocker for the mat -> mat2 transitoon
>> anymore, no?
> 
> You're right, I've missed this, thanks for keeping track of it.
> 
>> If we ask ftpmasters and the Release Team for help, there might still
>> be a chance to get a mat2 with a new transitional 'mat' binary package
>> into buster, don't you think so?
>>
>> What do you think about the following:
>>
>> 1. Ask ftpmaster and Release Team for their opinions on this matter
>> 2. Upload mat2 0.7.0-2 with new transitional binary package 'mat'
>> 3. Since it will sit in NEW for a few days anyway, maybe 0.7.0-1 will
>>transition to buster in the meantime. If not, no worries - we want to
>>get 0.7.0-2 into buster anyway.
>>
>> Maybe you could give short replies on whether you're in favour of this
>> plan. I would contact ftpmasters and Release Team as soon as I get
>> some positive feedback.
> 
> Sounds good -- in case you're too busy, I could also do it next week. I
> think our chances that this gets accepted are pretty good.

Turned out that it's much easier than that:

* Source packages that take over existing binary packages don't have to
  go through NEW. After Georg uploaded 0.8.0-2 with the new transitional
  binary package to experimental yesterday, I went ahead today and
  uploaded mat2 0.8.0-3 to unstable just now.
* The soft freeze only blocks new *source* packages from transitioning
  to buster. So if all goes well, mat2 0.8.0-3 with the new transitional
  binary package 'mat' will enter buster in time, without us needing to
  ask for a freeze exception at all.

> I would also fill the RM bug against mat to get it removed;
> @intrigeri / dkg: Could you give a short ACK on this?

Well, we decided to go ahead. Hope that's fine with you, intrigeri and dkg.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#784512: Remove pyside?

[Hanno Stock]

Ok, sorry - so it would be better to file bugs against these as well?

Bug#923544: preload is automatically installed even though it's supposed to be in suggests

[shirish शिरीष]

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

Dear all,

I am/was upgrading debian when I came across the following scenario -

$ sudo aptitude install lxqt lxqt-branding-debian lxqt-core lxqt-theme-debian -y
The following NEW packages will be installed:
  preload{a}
The following packages will be upgraded:
  lxqt lxqt-branding-debian lxqt-core lxqt-theme-debian


 This goes against what is being said in the changelog .

 xqt-metapackages (28) unstable; urgency=medium

  * lxqt-core:
- Depend on lxqt-branding-debian | lxqt-branding
- Recommend qterminal
- Recommend qps
- Suggest feathernotes
- Suggest preload



I am/was trying to update lxqt-branding-debian to 0.14.0.3 but as can
be seen there is a difference between what is shared and how it works.


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

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

Versions of packages lxqt-branding-debian depends on:
ii  desktop-base10.0.0
ii  gnome-themes-extra  3.28-1
ii  lxqt-theme-debian   0.14.0.1
ii  oxygen-icon-theme   5:5.54.0-1
ii  papirus-icon-theme  20190106-1
ii  xfwm4-theme-breeze  0.1.0-4
ii  xsettingsd  0.0.20171105+1+ge4cf9969-1

lxqt-branding-debian recommends no packages.

lxqt-branding-debian suggests no packages.

-- no debconf information


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

Bug#842943: feasibility of packaging signal-desktop

[Paolo Greppi]

I have given signal-desktop a first look.

In terms of dependencies, apart from electron (ehm...) this is what I found:

- to be updated:
  1. node-chalk: 2.3.0 -> 2.4.1
  2. node-espree: 3.5.1 -> 3.5.4
  3. node-filesize: 3.5.11 -> 3.6.1
  4. node-got: 7.1.0 -> 8.2.0
  5. node-he: 1.1.1 -> 1.2.0
  6. node-jquery: 3.3.1 from experimental
  7. node-os-locale: 2.0.0 -> 2.1.0
  8. node-tar: 4.4.6 -> 4.4.8
  9. node-tmp: 0.0.31 -> 0.0.33

- should be possible to build from sources we already have:
  1. @scottnonnenberg-signal/node-sqlcipher: - we can use node-sqlite3, see: 
https://bugs.debian.org/923512
  2. react-dom: same upstream source as node-react, see: 
https://bugs.debian.org/923537

- can be probably patched away:
  1. electron-updater: we want to disable "auto-update"
  2. testcheck: clojure script ...
  
- can be bundled:

  1. electron-editor-context-menu: 104 LOC and 7 dependents
  2. electron-is-dev: 6 LOC and 88 dependents
  3. emoji-datasource: contains JSON data and static assets only, 21 dependents
  4. emoji-datasource-apple: same upstream as emoji-datasource
  5. firstline: 28 LOC and 26 dependents
  6. read-last-lines: 81 LOC and 30 dependents

- ITP existing but could be bundled:
  1. blueimp-canvas-to-blob: https://bugs.debian.org/802243 (102 LOC and builds 
with uglifyjs)

- to bundle or not to bundle:
  1. linkify-it: 123 LOC and 148 dependents
  2. proxy-agent: 168 LOC and 147 dependents

- ITP existing:
  1. blueimp-load-image: https://bugs.debian.org/802244
  2. bunyan: https://bugs.debian.org/902062
  3. node-sass: https://bugs.debian.org/88
  4. node-jsdoc: https://bugs.debian.org/774565

- need ITP:
  1. @sindresorhus/is: https://github.com/sindresorhus/is BTW, could this 
replace all node-is* modules we have ?
  2. blob-util: https://github.com/nolanlawson/blob-util this is built using 
run-s and run-p commands from https://github.com/mysticatea/npm-run-all and 
rollup
  3. classnames: 143 LOC but 14000+ dependents
  4. config: 1471 LOC and 2756 dependents
  5. emoji-js: 2630 LOC and 23 dependents
  6. emoji-panel: 1 dependent but built with webpack
  7. google-libphonenumber: uses ant for building (?), 286 dependents
  8. intl-tel-input: built with grunt, 27 dependents
  9. protobufjs: built wih gulp and 967 dependents
  10. react-contextmenu: built with webpack and 67 dependents
  11. spellchecker: nodejs native addon

There is a WIP repo here:
https://salsa.debian.org/js-team/signal-desktop
of course it does not build yet !

Paolo

Bug#923543: python-tabulate: adopted out of DPMT but Vcs-* was not changed

[Mattia Rizzolo]

Source: python-tabulate
Version: 0.8.2-1

You adopted this package and moved it out of team maintenance (I'll
refrein from commenting on the bad idea of that…), but you didn't remove
nor changed the Vcs-* fields.

If you want to keep it out of the team please change the Vcs-* fields.

I also asked a team admin to archive
https://salsa.debian.org/python-team/modules/python-tabulate/

-- 
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#923499: devscripts: wrap-and-sort raises KeyError on some debian package src trees

[Mattia Rizzolo]

Control: tag -1 patch

On Thu, Feb 28, 2019 at 06:25:12PM -0500, Boyuan Yang wrote:
> When maintaining packages in Debian, I noticed that wrap-and-sort would
> raise an error on a specific source code tree:
> 
> https://salsa.debian.org/input-method-team/marisa/tree/faea327eca5a5e4f7cc6a4d50b32fd1d6d4e4031
> 
> [~/src/debian/input-method-team/marisa] [master]
> -> % wrap-and-sort -abst 
> Traceback (most recent call last):
>   File "/usr/bin/wrap-and-sort", line 318, in 
> main()
>   File "/usr/bin/wrap-and-sort", line 303, in main
> modified_files = wrap_and_sort(args)
>   File "/usr/bin/wrap-and-sort", line 209, in wrap_and_sort
> control.wrap_and_sort()
>   File "/usr/bin/wrap-and-sort", line 102, in wrap_and_sort
> self.paragraphs = first + sorted(sortable, key=sort_key)
>   File "/usr/lib/python3/dist-packages/debian/deb822.py", line 505, in
> __getitem__
> value = self.__dict[keyi]
> KeyError: 'Package'
> 
> Could you please take a look?

That's because it's trying to sort the paragraphs in d/t/control.

This patch would fix it, which I'll commit if nobody comes up with
anything better (like, how should we sort the paragraphs in that file?):

diff --git a/scripts/wrap-and-sort b/scripts/wrap-and-sort
index cea9cd4a..e470d711 100755
--- a/scripts/wrap-and-sort
+++ b/scripts/wrap-and-sort
@@ -96,6 +96,8 @@ class WrapAndSortControl(Control):
 paragraph["Architecture"] = " ".join(archs)

 if self.args.sort_binary_packages:
+if self.filename.endswith('tests/control'):
+return
 first = self.paragraphs[:1 + int(self.args.keep_first)]
 sortable = self.paragraphs[1 + int(self.args.keep_first):]
 sort_key = operator.itemgetter("Package")


-- 
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#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?

[Dmitry Bogatov]

`
[2019-02-28 18:01] Niko Tyni 
> > > But ideally gdbm would restore compatibility and libmarc-charset-perl 
> > > would
> > > not need any changes.
> > 
> > I believe upstream release 1.8.1 introduced change, that
> > made it possible to read old /usr/lib/libmarc-charset-perl/Table. Am I
> > missing something in current situation?
>
> I thought so too, but this new bug highlights the fact that the fix
> does not work on all architectures.  This was missed earlier because
> Debian does not have autopkgtest checks on !amd64, so we're relying
> on user bug reports and haven't got any so far.
>
> I've now verified that creating GDBM files with Perl, Python 2 or Python 3
> on stretch i386 and then upgrading to buster renders the old databases
> unusable with the corresponding software in buster.
>
> I can file a separate bug against src:gdbm if that makes things clearer.

Yes, it would help. Please include as much details, as possible,
including database created on stretch-i386. It would speed-up
communication with upstream.

> > By the way, I disagree about compability. If all we need to make
> > everything good is just a binNMU, I'd rather not introduce any
> > patches/hacks/compatibility layers/etc.
>
> binNMU'ing libmarc-charset-perl will only fix libmarc-charset-perl,
> not unpackaged local user databases. If those become unusable on
> stretch -> buster upgrades with no way to recover them, that seems
> like a major problem.
>
> binNMU'ing libmarc-charset-perl does not fix partial upgrades where
> perl that uses a newer libgdbm is upgraded before  libmarc-charset-perl.
> Hence the need for Breaks and versioned build dependencies that I listed.

Ah, I see. Yes, breaking user databases would not be nice.

> > By the way, it is sad that libmarc-charset-perl uses gdbm, not cdb.
> Are you referring to https://cr.yp.to/cdb.html ? I see there's a CDB_File
> Perl module in libcdb-file-perl but I'm not familiar with it. Seems worth
> a wishlist bug.

Among advantages of cdb is that it has well-specified format on disk.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923485: initscripts: Please make /etc/rc.local a conffile

[Dmitry Bogatov]

[2019-02-28 21:41] Pierre Ynard 
> /etc/rc.local is currently installed from a static heredoc in
> initscripts.postinst. This isn't very clean, and also old systems don't
> benefit from new file versions on upgrades, and nothing handles its
> removal on uninstall.
>
> Please consider making /etc/rc.local a conffile instead.

It proved to be slightly more involved then I expected. If I just make
default /etc/rc.local part of package, dpkg will silently overwrite
already existing /etc/rc.local. To fix it, I had to move existing
/etc/rc.local to temporary file in preinst and move back in postinst.

If anybody knows how to push this work on some existing tool,
suggestions are welcome.


From c241125c29c5103e3aa914160f892c024df3e953 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Fri, 1 Mar 2019 10:39:33 +
Subject: [PATCH] Make /etc/rc.local conffile (Closes: #923485)

---
 debian/initscripts.postinst |  4 
 debian/initscripts.preinst  | 10 +-
 debian/src/initscripts/Makefile |  1 +
 debian/src/initscripts/etc/rc.local | 12 
 4 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 debian/src/initscripts/etc/rc.local

diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index ad0eb4d0..1b23e3aa 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -18,6 +18,10 @@ case "$1" in
;;
 esac
 
+if [ -f /etc/rc.local.dpkg-old ] ; then
+   mv /etc/rc.local.dpkg-old /etc/rc.local
+fi
+
 umask 022
 
 # In 2.88dsf-23 the "mountoverflowtmp" script was dropped entirely.
diff --git a/debian/initscripts.preinst b/debian/initscripts.preinst
index 6c11ca13..698be29a 100755
--- a/debian/initscripts.preinst
+++ b/debian/initscripts.preinst
@@ -49,4 +49,12 @@ esac
 
 #DEBHELPER#
 
-:
+case $1 in
+(install|upgrade)
+   if dpkg --compare-versions "$2" lt '2.94-2' ; then
+   if [ -f /etc/rc.local ] ; then
+   mv /etc/rc.local /etc/rc.local.dpkg-old
+   fi
+   fi
+   ;;
+esac
diff --git a/debian/src/initscripts/Makefile b/debian/src/initscripts/Makefile
index 995ac89c..79294915 100644
--- a/debian/src/initscripts/Makefile
+++ b/debian/src/initscripts/Makefile
@@ -27,6 +27,7 @@ install:
find $(DESTDIR)/lib -type d -name .svn  -print0 |xargs -r0 rm -r
chmod 755 $(DESTDIR)$(sysconfdir)/init.d/[a-z]*
chmod 755 $(DESTDIR)$(sysconfdir)/network/if-up.d/[a-z]*
+   chmod 755 $(DESTDIR)$(sysconfdir)/rc.local
chmod 644 $(DESTDIR)/lib/init/*.sh
chmod -R g-w $(DESTDIR)
chown -R root:root $(DESTDIR)
diff --git a/debian/src/initscripts/etc/rc.local 
b/debian/src/initscripts/etc/rc.local
new file mode 100644
index ..972c0672
--- /dev/null
+++ b/debian/src/initscripts/etc/rc.local
@@ -0,0 +1,12 @@
+#!/bin/sh -e
+#
+# rc.local
+#
+# This script is executed at the end of each multiuser runlevel.
+# Make sure that the script will "exit 0" on success or any other
+# value on error.
+#
+# In order to enable or disable this script just change the execution
+# bits.
+
+[ -d /etc/boot.d ] && run-parts /etc/boot.d

-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#567071: what is the purpose of fstab-decode

[Dmitry Bogatov]

[2019-02-28 15:43] Jonathan de Boyne Pollard 

>  > What exactly is decoded? Where should I read about escaping rules?
> How it is different from plain `xargs'?
>
> You are suffering from the notoriously poor Linux documentation. (-:

Thank you. Wouderful. I believe it should find its way into upstream
distribution. Also, reference to fstab(5) and this particular paragraph
may be useful:

The second field (fs_file).
  This  field  describes the mount point (target) for the filesys‐
  tem.  For swap partitions, this field  should  be  specified  as
  `none'.  If  the name of the mount point contains spaces or tabs
  these can be escaped as `\040' and '\011' respectively.

> The manuals for fstab on the BSDs explain that the fields are encoded , 
> so that they can contain whitespace characters, with strvis() and must 
> be decoded with strunvis() when read.  The BSD C library getfsent() 
> function does this for one.
>
> It is pretty much undocumented, but roughly the same in fact holds true 
> for Linux operating systems and their C libraries.  It is not the vis 
> encoding scheme, and is rather an encoding scheme that is peculiar to 
> fstab.  But the fields are encoded so that they can contain whitespace 
> characters, and the getfsent() library function (or, actually, the 
> getmntent() library function in the GNU C library) does this for one.
>
> If you read fstab with a program like awk, it will of course read and 
> process the encoded forms.  To actually get hold of the decoded forms, 
> so that they can be passed as arguments to programs that do not expect 
> them to be encoded, such as unmount in the example; one has to pass them 
> through a decoder program.  fstab-decode is simply such a decoder 
> program.  It runs all of its arguments through the decoder, and then 
> execs the result.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923542: Error: parsed key is not in key set: 'RuleFile'

[Enrico Zini]

Package: usbguard
Version: 0.7.4+ds-1+b1
Severity: normal

Hello,

thank you for maintaining usbguard.

I installed it and I wanted to give IPC access to my user. 

I ran this:

usbguard add-user enrico -p list -d list -e listen -P list

And I got:

[1551462757.473] (E) Error: parsed key is not in key set: 'RuleFile'
ERROR: KeyValueParser: Parser: Invalid key

It seems to refer to this:

# grep RuleFile /etc/usbguard/usbguard-daemon.conf 
# RuleFile=/path/to/rules.conf
RuleFile=/etc/usbguard/rules.conf

It looks like default config file having options that are not supported
anymore/yet, or something like that?


Enrico


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

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

Versions of packages usbguard depends on:
ii  dbus  1.12.12-1
ii  libaudit1 1:2.8.4-2
ii  libc6 2.28-7
ii  libcap-ng00.7.9-2
ii  libdbus-1-3   1.12.12-1
ii  libdbus-glib-1-2  0.110-4
ii  libgcc1   1:8.2.0-21
ii  libglib2.0-0  2.58.3-1
ii  libseccomp2   2.3.3-4
ii  libstdc++68.2.0-21
ii  libusbguard0  0.7.4+ds-1+b1

usbguard recommends no packages.

usbguard suggests no packages.

-- Configuration Files:
/etc/usbguard/usbguard-daemon.conf [Errno 13] Permission denied: 
'/etc/usbguard/usbguard-daemon.conf'

-- no debconf information

Bug#918276: (no subject)

[Sebastian Ramacher]

Hi

On 2019-02-26 12:17:30, Сергей Фёдоров wrote:
> Installed Debian 9.8 amd64 from scratch. In it in "stable" vlc 3.0.6-0+deb9u1
> works fine, but if you install vlc 3.0.6-1 from sid, when you open
> any video file Debian freezes and only the mouse cursor moves across the 
> screen.
> I.e. everything in Debian to 9.6. In Debian 9.6, amd64 worked fine in
> "stable" vlc 3.0.3-1-0+deb9u1, and if you install vlc 3.0.5-1 from "sid", 
> then when
> open any *.mp4 file Debian hangs on the screen and moves the cursor
> mice.

We really need those logs. And when you upgraded to vlc from sid, did you 
upgrade the rest of your
system as well?

> 
> If it does not open the video file, vlc --version, then it will report:
> VLC media player 3.0.6 Vetinari (revision 3.0.6-0-g5803e85f73)
> VLC version 3.0.6 Vetinari (3.0.6-0-g5803e85f73)
> Compiled by buildd on x86-ubc-01.debian.org (Jan 10 2019 19:03:32)
> Compiler: gcc version 8.2.0 (Debian 8.2.0-14)
> This program comes with NO WARRANTY, to the extent permitted by law.
> You may redistribute it under the terms of the GNU General Public License;
> see the file named COPYING for details.
> Written by the VideoLAN team; see the AUTHORS file.
> 
> I. e. not 3.0.6-1, but 3.0.6-0, which looks suspicious.

Nothing suspicious here. That's just what git describe produces as version 
information for the 3.0.6
tag.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#784512: Remove pyside?

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, 1 Mar 2019 at 12:33, Hanno Stock  wrote:
>
> Control: severity -1 normal
>
> Since pyside has been superseeded by pyside2 and pyside2 is in testing,
> but pyside is not - should we remove pyside from sid as well?
>
> Also I think this is no longer serious, since an alternative exists and
> pyside won't work anyways with Qt4's removal.

Well:

Checking reverse dependencies...
# Broken Depends:
pyside-tools: pyside-tools
python-ghost: python-ghost
 python3-ghost
yubikey-piv-manager: yubikey-piv-manager
yubioath-desktop: yubioath-desktop

# Broken Build-Depends:
pyside-tools: libpyside-dev (>= 1.0.6)
 python-pyside.qtcore (>= 1.0.6)
 python-pyside.qtgui (>= 1.0.6)

Dependency problem found.

removing it also means removing python-ghost, yubikey-piv-manager and
yubioath-desktop

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#923541: libdbd-mysql-perl: FTBFS against mariadb-10.3 1:10.3.13-1

[gregor herrmann]

Source: libdbd-mysql-perl
Version: 4.050-1
Severity: serious
Tags: upstream ftbfs sid
Justification: fails to build from source (but built successfully in the past)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is already discussed in
https://lists.debian.org/debian-perl/2019/02/msg00026.html
but filing it as a bug:

libdbd-mysql-perl fails its tests with

t/rt118977-zerofill.t ... 
1..8
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
not ok 8
#   Failed test at t/rt118977-zerofill.t line 22.
#  got: '1'
# expected: '1'
# Looks like you failed 1 test of 8.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/8 subtests 

when built against mariadb-10.3 1:10.3.13-1.

This looks like #917303 which was fixed in 4.050-1 and this fix
worked with mariadb-10.3 1:10.3.12-2. Seems that there is a change in
mariadb between 10.3.12 and 10.3.13 which breaks the test again.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlx5bDpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgb5UA/6A9nE1Lc053by+8vO/bTPqbCWfUR+3J4ECcK0zzu1sZ89xoRP07LRpr/r
LFL5H38YIhEwxqvgzq1wtLo0y16nNvGZ/qMhpJNTulbMfCzI78IP9ipjzyhg8eS+
/Fc/QubSFCy/c8rkvoINi2aRo53icn8nnBuwlamQyBydzEN4Pi+ysCFmmJiJ2CFf
1aeL+NCX8d9E+aQrkvqjLvmaQ2SscZgNr18xBSWl3UywPiUhidrAOjme85G8OPLN
5jCvC/LxcPk54bxToLMlxvS+NJ1BmjTGLpWnnCXmo9ZMoLGaY0UU8XnG4FJgJUgB
O8rHgKBrqvOpVbi8/3vz7A6kkteMpaVnNDUG+sjBKdYc5mD8cZv8Oa+7/kFloOlJ
UWDUYL8I8qjvUuCBz5mDVs7bz5bXZfEdsKy08QVoh7cRXTgkTT/2fZ9xfyGa6ZJe
JiG6LtlH47gDJf6IDOE9MX4abh1nAF2P+ZCGoAAz+J7kSCFxb5e5604RY4u8fhYJ
3xRliHFH4467RK979VOXKZWGYsVOC7YGGdTBMhRPrb2aNeBGC4j+/q5PJ3gmEoB7
vPXaawAi5jKEjRi9N9KCedztL65GEKrChY7/Y8JnXiSi3S8cpUWfuMghP7zSz7IL
BFo790+5FDCayDTIHLfTpsI1dg8t8cIrX1UyGFqmyD5uLquExZk=
=6lnQ
-END PGP SIGNATURE-

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

[Markus Koschany]

Am 01.03.19 um 18:24 schrieb Emmanuel Bourg:
> Le 01/03/2019 à 18:19, Markus Koschany a écrit :
> 
>> I think just creating /var/lib/solr with tomcat9.dirs is sufficient. I
>> tested both cases, installing tomcat9 first and then solr-tomcat and
>> vice versa, and the server always started correctly. SystemD just
>> requires an existing directory. Do you agree with this change?
>>
>> https://salsa.debian.org/java-team/tomcat9/commit/fc31e79f1c5f94cfcef0c75c3133654edf00a28e
> 
> It looks a bit odd to put solr specific stuff in tomcat9. I'd rather
> investigate a solution involving a /etc/systemd/system/tomcat9.d/ file
> installed by solr-tomcat and extending the write permissions.
> 
> Emmanuel Bourg

I find adding an additional empty and root owned directory to be the
lesser of two evils. I have never extended security permissions of
another systemd service. How is this supposed to work?



signature.asc
Description: OpenPGP digital signature

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

[Emmanuel Bourg]

Le 01/03/2019 à 18:19, Markus Koschany a écrit :

> I think just creating /var/lib/solr with tomcat9.dirs is sufficient. I
> tested both cases, installing tomcat9 first and then solr-tomcat and
> vice versa, and the server always started correctly. SystemD just
> requires an existing directory. Do you agree with this change?
> 
> https://salsa.debian.org/java-team/tomcat9/commit/fc31e79f1c5f94cfcef0c75c3133654edf00a28e

It looks a bit odd to put solr specific stuff in tomcat9. I'd rather
investigate a solution involving a /etc/systemd/system/tomcat9.d/ file
installed by solr-tomcat and extending the write permissions.

Emmanuel Bourg

Bug#922567: FTBFS against opencv 4.0.1 (exp)

[Alexis Bienvenüe]

Thanks for the report!
I will update the package also in unstable after buster release.

Regards,
Alexis Bienvenüe.

Bug#923540: libcommons-compress-java b-d should be tightened

[Matthias Klose]

Package: src:libapache-poi-java
Version: 4.0.1-1

libapache-poi-java ftbfs with libcommons-compress-java 1.13, therefore the build
dependency should be tightened.  The build works with 1.18.

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

[Markus Koschany]

Hi,

I think just creating /var/lib/solr with tomcat9.dirs is sufficient. I
tested both cases, installing tomcat9 first and then solr-tomcat and
vice versa, and the server always started correctly. SystemD just
requires an existing directory. Do you agree with this change?

https://salsa.debian.org/java-team/tomcat9/commit/fc31e79f1c5f94cfcef0c75c3133654edf00a28e

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#786808: RFA: adequate -- Debian package quality testing tool

[shirish शिरीष]

at bottom :-

On 01/03/2019, Axel Beckert  wrote:
> Hi Jakub,
>
> Jakub Wilk wrote:
>> >>I request an adopter for the adequate package. (Note that RFA !=
>> >>O. Talk to me before taking over this package.)
>>
>> I wrote this in May 2015.
>> Then, in May 2016, I orphaned the package.
> [...]
>> [...], so there wasn't anything for me to
>> object.
>
> Ah, sorry, missed that part when I read through the history of this
> bug report. For a long time, BartM had a bug in his script retitling
> WNPP bug reports from ITA to O even if they were just RFA beforehand,
> so I expected this to be an victim of that bug, too,
>
> Anyway, in that case I've likely done just the right thing. So thanks
> for the clarification. :-)
>
> I intent to take care of the package under the QA umbrella in case of
> RC bugs or similar.
>
> But if I'd ever take over the package alone respectively its
> development, I likely have to rewrite tests/run-tests in another
> language. Testing Perl scripts with Python scripts is definitely not
> my way of doing such things, especially if TAP is not used.
>
> So I'd really prefer if a team would take it over. And I still think
> that the Lintian team would be the most appropriate team for that.
>
>   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
>
> --
> To unsubscribe, send mail to 786808-unsubscr...@bugs.debian.org.
>

Dear Axel,

While I may not be useful in development (not a coder) , I would
definitely be interested in being the guinea pig and any tests that
you want me to run after every new release. Using adequate has
certainly made my life a bit easier, although at times it does have
false-positives. Maybe there is something there I could help with ?

Looking forward to know in whichever way I could help out.

:)

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

Bug#890646: having a look at this

[Hanno Stock]

I am having a look at this. Hoping to get 1.2.1 ready today.

If anybody else is working on this, please give me a ping.

-- 
Regards
  Hanno



signature.asc
Description: OpenPGP digital signature