Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Simon McVittie]

On Thu, 28 Feb 2019 at 17:53:37 -0500, Reinhard Tartler wrote:
> Upstream doesn't appear to be willing to upgrade to a new version (quote from
> the bug above "[...] I really don't want to [...]". Looking at how this 
> package
> is using the vendored library, it seems openshift/imagebuilder is using a
> rather specific subset of the docker code, some of which possibly shouldn't
> have been exposed in the first place. Therefore, I'm inclined to follow
> upstream and vendor this library.

I agree that this sounds like a de facto fork of the vendored library,
more than a convenience code copy.

> I wonder whether it wouldn't be actually be more
> appropriate to create a tarbal with the vendored library and ship it in the
> debian/ subdirectory.

You could consider using a multiple-.orig-tarball package in 3.0
(quilt) format? See for example yquake2 (a relatively simple
example which bundles together https://github.com/yquake2/yquake2 and
https://github.com/yquake2/ctf) or llvm-toolchain-7 (a more elaborate
example with multiple subprojects).

smcv

Bug#923439: dh-runit: Don't ship /etc/sv unless the package ships service files

[Dmitry Bogatov]

control: tags -1 +confirmed +pending

[2019-02-28 10:38] Mathieu Mirmont 
> Package: dh-runit
> Version: 2.8.6
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> When producing multiple packages, dh-runit installs /etc/sv in every
> package, even if such packages do not ship service directories.
>
> The attached patch removes the systematic install_dir() call from
> dh-runit. Since install_dir() eventually calls "install -d", the
> further install_dir() calls do create /etc/sv if not present.

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

Bug#923247: Request: Qt 5.12 before the full freeze

[Salvi Loris]

Hi,


However the issue with duplex printing should be fixed in qtbase 5.11.3+dfsg-4
where I backported commit [1] from upstream.

[1]: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=fa854f214a3c812e


I've tried to install qtbase 5.11.3+dfsg-5 and i can confirm the bug 
with duplex seems to be fixed.


Thank you!


AVVISO: Questo messaggio e' inviato da Banca Sammarinese di Investimento S.p.A. 
e puo' contenere informazioni di carattere estremamente riservato e 
confidenziale. Qualsivoglia utilizzo non autorizzato del contenuto di questo 
messaggio costituisce violazione dell'obbligo di non prendere cognizione della 
corrispondenza tra altri soggetti, salvo piu' grave illecito ed espone il 
responsabile alle relative conseguenze.
Qualora non foste i destinatari, vogliate immediatamente informarci con lo 
stesso mezzo ed eliminare il messaggio, con gli eventuali allegati, senza 
trattenerne copia. Grazie per la collaborazione.

DISCLAIMER: This e-mail contains confidential information, which is intended 
only for the use of the recipient(s) named above. If you have received this 
communication in error, please notify the sender immediately via e-mail and 
return the entire message. Thank you for your assistance.

Bug#923491: RM: openssl1.0 -- RoQA; Obsoleted by OpenSSL 1.1

[Sebastian Andrzej Siewior]

On 2019-02-28 23:24:54 [+0100], Moritz Muehlenhoff wrote:
> Could we force the removal of src:openssl1.0 at this point?
+ROM

> Besides various outdated kfreebsd binaries there are only
> three source packages left:
…

I opened #923194, #923195 to deal with the outdated packages.

> Cheers,
> Moritz

Sebastian

Bug#921645: dipy: FTBFS against scipy 1.2.1

[Drew Parsons]

Source: dipy
Followup-For: Bug #921645

dipy continues to FTBFS against scipy 1.2.1-1exp1

The error is:

ERROR: dipy.core.tests.test_sphere.test_interp_rbf
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/home/test/scipy/dipy-0.14.0/debian/tmp/usr/lib/python2.7/dist-packages/dipy/core/tests/test_sphere.py",
 line 375, in test_interp_rbf
interp_data_a = interp_rbf(data, s0, s1, norm="angle")
  File 
"/home/test/scipy/dipy-0.14.0/debian/tmp/usr/lib/python2.7/dist-packages/dipy/core/sphere.py",
 line 572, in interp_rbf
**kwargs)
  File "/usr/lib/python2.7/dist-packages/scipy/interpolate/rbf.py", line 241, 
in __init__
self.nodes = linalg.solve(self.A, self.di)
  File "/usr/lib/python2.7/dist-packages/scipy/interpolate/rbf.py", line 247, 
in A
r = squareform(pdist(self.xi.T, self.norm))  # Pairwise norm
  File "/usr/lib/python2.7/dist-packages/scipy/spatial/distance.py", line 2030, 
in pdist
dm[k] = metric(X[i], X[j], **kwargs)
  File 
"/home/test/scipy/dipy-0.14.0/debian/tmp/usr/lib/python2.7/dist-packages/dipy/core/sphere.py",
 line 544, in angle
xx[np.isnan(xx)] = 0
TypeError: 'numpy.float64' object does not support item assignment


-- 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-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#921280: systemd-cgtop no longer shows memory usage

[Anthony DeRobertis]

On 2/28/19 1:48 PM, Michael Biebl wrote:


Hm, interesting.
I see that this particular PR is not part of v241.
That said, when I run systemd-cgtop I *do* see the memory usage column
with 241-1

Anthony, could you please re-test with this version and report back?



I installed systemd 241-1 from unstable. systemd-cgtop still doesn't 
display memory usage. Since kernel version apparently matters,


$ uname -a
Linux Watt 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 
GNU/Linux


I went ahead and tried the patch from 
https://github.com/systemd/systemd/pull/11775 and installed that, and it 
works. (though I installed and not configured, since the dependencies 
are really tight, and I also have libsystemd0:i386 here, which I didn't 
wind up building on my amd64 box...) So the patch fixes it.

Bug#923507: [proposal] Move long list of recommends from ruby-rails to rails binary package

[Pirate Praveen]

Package: src:rails
version: 2:5.2.2+dfsg-5
X-debbugs-cc: debian-r...@lists.debian.org

Currently ruby-rails pulls a lot of packages via recommends including 
chromium browser. I suggest we move the recommends list from ruby-rails 
to rails binary package.


Another option is to move all of this as Depends of a rails-dev binary 
package (or change recomends to depends in rails binary). This will 
also help us with autopkgtests which currently depends on the 
deprecated restriction needs-recommends.

Bug#921636: python-fluids: FTBFS against scipy 1.2.1

[Drew Parsons]

Package: python-fluids
Version: 0.1.73-1
Followup-For: Bug #921636

python-fluids 0.1.73-1 continues to FTBFS against scipy 1.2.1-1exp1.

The error is the same:

tests/test_particle_size_distribution.py ..FF[ 67%]
=== FAILURES ===
 test_PSDLognormal_ds_discrete _

def test_PSDLognormal_ds_discrete():
# Test the cdf discrete
dist = PSDLognormal(s=0.5, d_characteristic=5E-6)
ds = dist.ds_discrete(d_min=1e-7, d_max=1e-6, pts=8)
ans = dist.fractions_discrete(ds)
fractions_expect = [2.55351295663786e-15, 3.831379657981415e-13, 
3.762157252396037e-11, 2.41392961175535e-09, 1.01281244724305e-07, 
2.7813750147487326e-06, 5.004382447515443e-05
, 0.00059054208024234]
>   assert_allclose(fractions_expect, ans, rtol=1e-5)
E   AssertionError: 
E   Not equal to tolerance rtol=1e-05, atol=0
E   
E   Mismatch: 12.5%
E   Max absolute difference: 5.55111512e-17
E   Max relative difference: 0.00014491
Ex: array([2.553513e-15, 3.831380e-13, 3.762157e-11, 2.413930e-09,
E  1.012812e-07, 2.781375e-06, 5.004382e-05, 5.905421e-04])
Ey: array([2.553513e-15, 3.830825e-13, 3.762163e-11, 2.413930e-09,
E  1.012812e-07, 2.781375e-06, 5.004382e-05, 5.905421e-04])

tests/test_particle_size_distribution.py:430: AssertionError
_ test_PSDLognormal_dn _

def test_PSDLognormal_dn():
disc = PSDLognormal(s=0.5, d_characteristic=5E-6)

# Test input of 1
ans = disc.dn(1)
# The answer can vary quite a lot near the end, so it is safest just to
# compare with the reverse, plugging it back to cdf
assert_allclose(disc.cdf(ans), 1, rtol=1E-12)
#assert_allclose(ans, 0.0002964902595794474)

# Test zero input
assert_allclose(disc.dn(0), 0)

# Test 50% input
ans = disc.dn(.5)
assert_allclose(ans,  5.0e-06, rtol=1E-6)

with pytest.raises(Exception):
disc.dn(1.5)
with pytest.raises(Exception):
disc.dn(-.5)

# Other orders of n - there is no comparison data for this yet!!
assert_allclose(disc.pdf(1E-5), disc.pdf(1E-5, 3))
assert_allclose(disc.pdf(1E-5, 2), 13468.122877854335)
assert_allclose(disc.pdf(1E-5, 1), 4628.2482296943508)
assert_allclose(disc.pdf(1E-5, 0), 1238.6613794833427)

# Some really large s tests - found some issues with this
dist = PSDLognormal(s=4, d_characteristic=5E-6)
>   assert_allclose(dist.dn(1e-15), 8.220922763476676e-20, rtol=1e-3)
E   AssertionError: 
E   Not equal to tolerance rtol=0.001, atol=0
E   
E   Mismatch: 100%
E   Max absolute difference: 1.08103573e-21
E   Max relative difference: 0.01314981
Ex: array(8.112819e-20)
Ey: array(8.220923e-20)

tests/test_particle_size_distribution.py:463: AssertionError
=== warnings summary ===
.pybuild/cpython2_2.7_fluids/build/tests/test_jet_pump.py::test_liquid_jet_pump_examples_round_robin
  /usr/lib/python2.7/dist-packages/scipy/optimize/nonlin.py:1040: 
RuntimeWarning: invalid value encountered in true_divide
d = v / df_norm**2
  /usr/lib/python2.7/dist-packages/scipy/optimize/nonlin.py:999: 
RuntimeWarning: divide by zero encountered in true_divide
d = v / vdot(df, v)
  /usr/lib/python2.7/dist-packages/scipy/optimize/nonlin.py:774: 
RuntimeWarning: invalid value encountered in multiply
self.collapsed += c[:,None] * d[None,:].conj()
  /usr/lib/python2.7/dist-packages/scipy/optimize/nonlin.py:999: 
RuntimeWarning: invalid value encountered in true_divide
d = v / vdot(df, v)

-- Docs: https://docs.pytest.org/en/latest/warnings.html
=== 2 failed, 314 passed, 26 deselected, 4 warnings in 12.56 seconds ===





-- 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-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-fluids depends on:
ii  python 2.7.15-4
ii  python-fuzzywuzzy  0.17.0-1
ii  python-ipython 5.8.0-1
ii  python-pandas  0.23.3-1
ii  python-pint0.9-1
ii  python-scipy   1.2.1-1exp1
ii  python-sympy   1.3-2

python-fluids recommends no packages.

Versions of packages python-fluids suggests:
ii  python-fluids-doc  0.1.73-1

-- no debconf information

Bug#923506: dbus-user-session: does not work with elogind

[Brian Clinkenbeard]

Package: dbus-user-session
Severity: important

Dear Maintainer,

The new elogind package does not allow for this package to be installed
despite the fact that it provides the necessary functionality that
dbus-user-session depends on. Gentoo for example provides
dbus-user-session from solely elogind.

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

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

Versions of packages dbus-user-session depends on:
ii  dbus1.12.12-1
ii  libpam-elogind-compat [libpam-systemd]  1.3
pn  systemd 

Versions of packages dbus-user-session recommends:
pn  systemd-sysv  

dbus-user-session suggests no packages.

Bug#923395: this worked for me

[Paolo Greppi]

Hi Christof,

this worked for me:

cat /etc/default/lxc-net
USE_LXC_BRIDGE="true"

cat /etc/lxc/default.conf
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1

and don't forget to start the lxc-net service before starting any container:

sudo systemctl start lxc-net

Paolo

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[James Pooton]

> You could try to debug by directly running `sudo openssl rehash -v
> /etc/ssl/certs` on either version of ca-certificates (new one has new
> CAs added, old ones removed, and a couple other bug fixes, but openssl
> behavior should be the same).

Well, this is very odd….  

First with ca-certificates (20170717) in place and running `openssl rehash -v
/etc/ssl/cert` as root.  It’s successful and spits out:

Doing /etc/ssl/certs
rehash: warning: skipping ca-certificates.crt,it does not contain exactly 
one certificate or CRL
link D-TRUST_Root_Class_3_CA_2_EV_2009.pem -> d4dae3dd.0
link Certplus_Root_CA_G2.pem -> 451b5485.0
link Amazon_Root_CA_1.pem -> ce5e74ef.0
…..

Then with ca-certificates (20190110) in place and running `openssl rehash -v
/etc/ssl/cert` as root.  It fails only outputting:

Doing /etc/ssl/certs

Try it several more times, get the same single line output as above.  So I was 
curious that it didn’t even give the warning about ca-certificates.crt at 
least.  So I moved that with `mv ca-certificates.crt ..` which curiously spit 
out:

qemu: Unsupported syscall: 382
qemu: Unsupported syscall: 382

But now running `openssl rehash -v /etc/ssl/cert` as root again was 
successful(!) with:

Doing /etc/ssl/certs
link D-TRUST_Root_Class_3_CA_2_EV_2009.pem -> d4dae3dd.0
link Amazon_Root_CA_1.pem -> ce5e74ef.0
link Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem -> 
3bde41ac.0
link Certum_Trusted_Network_CA_2.pem -> 40193066.0
…..


So then, for fun I take the “suspect" ca-certificates.crt from (20190110) and 
toss it in to replace the one in (20170717) and try running rehash.  It works 
fine ?!

Ok, so then for a final test, I take take a fresh install of ca-certificates 
(20190110) and do the following:

root@e67c226047ba:/# openssl rehash -v /etc/ssl/certs
Doing /etc/ssl/certs

root@e67c226047ba:/# openssl rehash -v /etc/ssl/certs
Doing /etc/ssl/certs

root@e67c226047ba:/# openssl rehash -v /etc/ssl/certs
Doing /etc/ssl/certs

root@e67c226047ba:/# touch /etc/ssl/certs/ca-certificates.crt 

root@e67c226047ba:/# openssl rehash -v /etc/ssl/certs
Doing /etc/ssl/certs
rehash: warning: skipping ca-certificates.crt,it does not contain exactly 
one certificate or CRL
link D-TRUST_Root_Class_3_CA_2_EV_2009.pem -> d4dae3dd.0
link Amazon_Root_CA_1.pem -> ce5e74ef.0
link Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem -> 
3bde41ac.0
link Certum_Trusted_Network_CA_2.pem -> 40193066.0
…..

Seems crazy….  but touching that file allows rehash to work under QEMU.

Bug#900748: u-boot-sunxi: Backport suggestion: reduce DRAM clock speed of Orange Pi Zero

[Vagrant Cascadian]

Control: fixed 900748 2017.09+dfsg1-1

On 2018-06-04, Jan Kiszka wrote:
> it seems reasonable to integrate
>
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=8792a64d87708139bc0cf8b48d4a580a39167473
>
> into the stable version of u-boot-sunxi. I personally wasn't able to
> reproduce a clear before-after scenario, but the commit log is
> suggesting that the DRAM clock speed reduction is an important measure
> to increase stability.

With buster coming soon, it might be best to just use a newer u-boot at
this point, unless someone really wants to tackle this soon.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#920695: knot-resolver: uninstallable and FTBFS in stretch-backports

[Daniel Kahn Gillmor]

Control: severity 920695 important

On Thu 2019-02-28 22:06:09 -0500, Daniel Kahn Gillmor wrote:
> So i'm marking #920695 as fixed in 3.2.1-1 with the hope of getting all
> of these migrations to move forward.

I've tagged the shared git repo for both knot-dns and for knot-resolver
source package stretch-backports releases.

I've also published the relevant packages to
https://people.debian.org/~dkg/knot-stretch-backports/ so that people
can get access to them if they want them before stretch-backports is
capable of taking them.

In order to try to help the transition along, i'm reducing the severity
of this bug report as well.   If there's a serious objection to this
severity reduction, please feel free to correct it back again, and
explain what you think the right thing to do is.

happy hacking,

   --dkg

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Michael Shuler]

On 2/28/19 7:37 PM, James Pooton wrote:
> So installing ca-certificates (20170717) with the latest openssl
> (1.1.1a-1), does produce the hashes in /etc/ssl/certs when doing an ARM
> 32bit build via QEMU.
> 
> One interesting thing is that the 382 syscalls were still present in the
> build, so that may be a red herring:
> 
> ...
>     Preparing to unpack .../ca-certificates_20170717_all.deb ...
>     Unpacking ca-certificates (20170717) ...
>     Setting up ca-certificates (20170717) ...
>     Updating certificates in /etc/ssl/certs...
>     qemu: Unsupported syscall: 382
>     148 added, 0 removed; done.
>     Processing triggers for ca-certificates (20170717) ...
>     Updating certificates in /etc/ssl/certs...
>     qemu: Unsupported syscall: 382
>     0 added, 0 removed; done.
> ...

Interesting, thanks. So c_rehash works fine-ish, which we were pretty
sure of, and the same behavior with the syscall errors.

/usr/bin/c_rehash is perl with a few calls out to openssl within.

You could try to debug by directly running `sudo openssl rehash -v
/etc/ssl/certs` on either version of ca-certificates (new one has new
CAs added, old ones removed, and a couple other bug fixes, but openssl
behavior should be the same).

> The only other thing I noticed (which certainly may not be related) is
> that a a few of the CA cert filename must have some crazy UTF8
> characters that get encoded (“NetLock_Arany”,
> “RKTRUST_Elektronik_Sertifika_Hizmet_Sa”, “k_Sertifika_Hizmet_Sa”).
>  Just seemed odd, and potentially something that could trip things up.

Yep, there are a few CAs with UTF8 labels, so the files are written out
that way. I was included in a conversation maybe 2 years ago with
someone that did some UTF8 filename research through the package
repositories, but there haven't been any issues raised.

An example of the options would be the existing UTF8:
"NetLock Arany (Class Gold) Főtanúsítvány"
or:
"NetLock Arany (Class Gold) F..tan..s..tv..ny"

F..who? :) I think the native UTF8 is a better option. It's probably a
bug if some file widget does not handle UTF8 files correctly.

-- 
Kind regards,
Michael

Bug#923504: cause of this particular message

[積丹尼 Dan Jacobson]

By the way, such mysteries happen not due to user error,
e.g., #923505. But that is only one cause of at accidents...

Bug#920695: knot-resolver: uninstallable and FTBFS in stretch-backports

[Daniel Kahn Gillmor]

Control: 920695 fixed 3.2.1-1

I'm able to rebuild knot-resolver just fine on stretch, when i build
3.2.1-1 against a backported knot 2.7.6-2.  I'll be uploading those to
stretch-backports shortly, but they can't go in until they've reached
testing.

But knot won't go into testing untlik knot-resolver migrates, due to
autopkgtests (see #922172), and knot-resolver itself won't migrate until
this bug report is non-RC.  heh, a tangled mess.

So i'm marking #920695 as fixed in 3.2.1-1 with the hope of getting all
of these migrations to move forward.

 --dkg


signature.asc
Description: PGP signature

Bug#922179: shim-signed depends on packages not repos

[Cyril Brulebois]

Hi Steve,

Moritz Mühlenhoff  (2019-02-26):
> On Fri, Feb 15, 2019 at 07:28:57PM +0100, Cyril Brulebois wrote:
> > Right, this also breaks the build of the debian-installer source package
> > on amd64 since its build dependencies cannot be satisfied.
> 
> Is there an ETA for a fix?

We're getting deeper and deeper into the freeze, and we seem to be
lacking a reasonable timeline regarding Secure Boot for Buster.

The problems we're seeing are:
 1. the hard shim/shim-signed dependency means the shim-signed package
isn't installable in sid;
 2. src:debian-installer therefore cannot be built because of
unsatisfiable build-dependencies;
 3. shim cannot migrate to testing.

We don't know how long it will take to get the new shim signed by
Microsoft; until that happens these problems will continue to block
development (and potentially the release).

Apologies for not spotting these as potential problems earlier, before
asking you to upload the new version of shim into unstable. :-(

If our understanding is correct, it seems that re-uploading the contents
of the previous shim package (either with an over-long “+really”-like
version, with an epoch, or with the trick detailed below), and adjusting
the versioned dependency in shim-signed to match, would make both
packages installable again. It wouldn't change anything regarding the
actual signatures: they would be validated as previously.

The “old” shim/shim-signed couple is already able to chainload
GRUB/Linux/etc. signed by either the Debian test key (as we've been
testing recently) or the embedded Debian production key. This would be a
quick fix for the next D-I Alpha/RC, but could also serve as a last
resort solution for buster itself if we don't get an updated shim-signed
package in time. In the meantime, we could upload the new shim
source/binary package to experimental for people to work with.

The main drawbacks (compared to actually getting an updated shim-signed
package) would be:
 1. lacking the newer shim code that upstream EFI people would like us
to be using;
 2. only having support for amd64.

Until an updated shim-signed package is available, it seems to us that
the re-upload suggested above would fix all issues we're seeing, without
having any negative impact. That's why we're considering doing so in the
next few days. 

Looking at the version numbers we have:
 - 0.9+1474479173.6c180c6-1 in testing
 - 15+1533136590.3beb971-2 in sid

so we could re-upload with 16+1474479173.6c180c6-1, which would sort
higher than the version in sid, but also lower than
16+1533136590.3beb971-*, that can be used to re-upload the new shim when
the matching shim-signed is ready.

How does that sound to you please?


Finally: we don't want to steal too much of your time for shim. It seems
like now would be a really good time to move maintenance formally to the
debian-efi team?


Cheers,
Cyril Brulebois & Steve McIntyre for the D-I / EFI teams
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#915241: heaptrack -- resolve poor discoverability

[Nicholas D Steeves]

On Wed, Feb 27, 2019 at 10:08:40AM +0200, Anton Gladky wrote:
>Hi Nicholas,
>I have managed to upload it.
>Thanks for your contribution!
>Regards
>Anton

Thank you Anton! :-)


Truly,
Nicholas


signature.asc
Description: PGP signature

Bug#923505: Be sure locales are available even during updates

[積丹尼 Dan Jacobson]

Package: locales
Version: 2.28-8
Severity: wishlist

You know, there is a slight gap in time when updating locales,
that all locales disappear.

This causes e.g., an at(1) job that happens to run during that time to
give e.g.,

> Subject: Output from your job  866

> sh: line 48: warning: setlocale: LC_CTYPE: cannot change locale 
> (zh_TW.UTF-8): No such file or directory

mysterious messages (Bug #923504).

Certainly your package's update script is doing something like

rm all_the_old_files
install all_the_new_files

Perhaps, as these are all mission critical files,
maybe you could do something like

copy all_the_new_files one by one on top of all_the_old_files
remove any_remaining_old_files_that_need_to_be_removed

That way there won't be any more time gaps when things will fail! Thanks.

Bug#921207: Octave GEMM error on large matrix due to openmp thread race condition

[Mo Zhou]

Hi Sébastien,

On Sun, Feb 03, 2019 at 12:07:20PM +, Mo Zhou wrote:
> It turns out that the incorrect matrix product is a result of
> gomp + iomp library clash: octave is linked against the GNU OMP,
> while libmkl-rt.so invokes Intel(LLVM) OMP by default.

I got in touch with MKL team and they confirmed that the iomp+gomp
mixture is actually a very common error among users. They plan to change
the loading mechanism of libmkl-rt for the 2020 production line, to
avoid iomp+gomp clash (sounds like yet another magic).

So let's keep this bug open for both MKL and Octave for a while,
in case any other user came across similar errors. Maybe this
bug will be fixed in the late 2019 (they released MKL 2019 in late
2018).

Bug#923504: add --also-include-job-in-mail

[積丹尼 Dan Jacobson]

Package: at
Version: 3.1.23-1
Severity: wishlist

It is rather hard to debug when something bad happens.

All you get is a mail e.g.,

> sh: line 48: warning: setlocale: LC_CTYPE: cannot change locale 
> (zh_TW.UTF-8): No such file or directory

You have no idea what caused it.

You might say "well then do nightly backups of your atspool".

But the job might have been submitted earlier today.

Therefore please add some option like:

--also-include-job-in-mail

Which makes:
Dear User, your at job:
echo feed the dog
Produced the output
feed the dog
Signed, your friendly at team.

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[James Pooton]

> 20170717 was the previous version in testing (20180409 introduced the
> `openssl rehash` usage and was kept from testing for an important bug).
> 
> 20170717 used the perl c_rehash utility. If you need it, here it is!
> 
> http://snapshot.debian.org/package/ca-certificates/20170717/#ca-certificates_20170717
>  
> 
> 

Thanks, that site is a keeper. :) 

So installing ca-certificates (20170717) with the latest openssl (1.1.1a-1), 
does produce the hashes in /etc/ssl/certs when doing an ARM 32bit build via 
QEMU.   I used the following dockerfile to make the test image:


FROM arm32v7/debian:buster-slim
ENV DEBIAN_FRONTEND noninteractive

COPY ca-certificates_20170717_all.deb /tmp/ca-certificates_20170717_all.deb

RUN apt-get update && \
apt-get install -y openssl && \
dpkg -i /tmp/ca-certificates_20170717_all.deb && \
apt-get install -y curl 

CMD [ "curl", "-sSL", "https://www.google.com;]


A container from it ran fine, pulling back Google.

One interesting thing is that the 382 syscalls were still present in the build, 
so that may be a red herring:

...
Preparing to unpack .../ca-certificates_20170717_all.deb ...
Unpacking ca-certificates (20170717) ...
Setting up ca-certificates (20170717) ...
Updating certificates in /etc/ssl/certs...
qemu: Unsupported syscall: 382
148 added, 0 removed; done.
Processing triggers for ca-certificates (20170717) ...
Updating certificates in /etc/ssl/certs...
qemu: Unsupported syscall: 382
0 added, 0 removed; done.
...

The only other thing I noticed (which certainly may not be related) is that a a 
few of the CA cert filename must have some crazy UTF8 characters that get 
encoded (“NetLock_Arany”, “RKTRUST_Elektronik_Sertifika_Hizmet_Sa”, 
“k_Sertifika_Hizmet_Sa”).  Just seemed odd, and potentially something that 
could trip things up.

Thanks again...

Bug#923503: localepurge: Typo in README.dpkg-path

[Горбешко Богдан]

Package: localepurge
Version: 0.7.3.5
Severity: minor

Dear Maintainer,

I found a typo: "lising".


-- System Information:
Debian Release: buster/sid
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable'), 
(500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages localepurge depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  locales    2.28-6
ii  procps 2:3.3.15-2
ii  ucf    3.0038+nmu1

localepurge recommends no packages.

Versions of packages localepurge suggests:
ii  bleachbit  2.0-3
ii  debfoster  2.7-2.1+b1
ii  deborphan  1.7.31

-- debconf information excluded

Bug#923365: ftgl: FTBFS in sid (LaTeX error)

[Santiago Vila]

tags 923365 - moreinfo
close 923365
thanks

Big oops! Sorry, I have now double-checked and the report was based on
a build log dated 2019-02-26, but apparently it took a while for me to
actually submit the bug. The underlying bug in texlive was fixed in
the meantime.

The package is sunny everywhere here:

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

so I'm closing this.

Thanks.

Bug#885759: Use /var/run as a statedir, and not /var/run/slurm-llnl

[nikt]

Package: slurmdbd
Version: 18.08.5.2-1
Followup-For: Bug #885759

Dear Maintainer,

The update to slurm 18.08.5.2-1 was supposed to move pid files of slurm
daemons from /var/run/slurm-llnl/ to /run/.
During the update apt promised to correct configuration files to update
pid path to /run (if it was set in the config).
However, this did not happen.

What happened is that config files (slurm.conf, slurmdbd.conf) still
contain pid paths in /run/slurm-llnl/. Note: not /var/run/slurm-llnl/ but
/run/slurm-llnl in my case.
These are respected by slurm processes (pid files still generated in
/run/slurm-llnl/), but systemd tries to access pids in /run/, stalling the
restart and failing it after a timeout.

This renders all slurm daemons fail to start and requires a manual edit to
config files. I.e. the update does not go smoothly as promised.


Apt did modify the config files, because it is visible in the modification
date, not a single byte changed. Old paths are still there:
PidFile=/run/slurm-llnl/slurmdbd.pid
Hint: maybe a wrong regex to match paths? Maybe only /var/run but not /run
is updated?
Since the pid is hardcoded in systemd unit configs, then imo it is better
to remove the pid file entries altogether from slurm config files.

Met

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

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

Versions of packages slurmdbd depends on:
ii  libc62.28-7
ii  lsb-base 10.2018112800
ii  munge0.5.13-2
ii  slurm-wlm-basic-plugins  18.08.5.2-1
ii  ucf  3.0038+nmu1

slurmdbd recommends no packages.

slurmdbd suggests no packages.

-- no debconf information

Bug#923502: clementine: left panel has broken text with random "&"s

[Aurélien Murith]

Package: clementine
Version: 1.3.1+git609-g623a53681+dfsg-1
Severity: minor

Text in the left panel appears broken, with many "&" symbols, whose placement
seems to be random. In English you get "Li", "", "",
"" "Son info" and " info", similar problem in French where you
get "Rec", "èque", "", "" and
"P&ériphériques".



-- 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/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.14.4-1
ii  gstreamer1.0-plugins-good   1.14.4-1
ii  gstreamer1.0-plugins-ugly   1.14.4-1
ii  libc6   2.28-7
ii  libcdio18   2.0.0-2
ii  libchromaprint1 1.4.3-3
ii  libcrypto++65.6.4-8
ii  libfftw3-double33.3.8-2
ii  libgcc1 1:8.2.0-21
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-7
ii  libglib2.0-02.58.3-1
ii  libgpod40.8.3-13
ii  libgstreamer-plugins-base1.0-0  1.14.4-1
ii  libgstreamer1.0-0   1.14.4-1
ii  libimobiledevice6   1.2.1~git20181030.92c5462-1
ii  liblastfm5-11.0.9-1
ii  libmtp9 1.1.16-2
ii  libmygpo-qt5-1  1.1.0-3
ii  libplist3   2.0.1~git20190104.3f96731-1
ii  libprojectm2v5  2.1.0+dfsg-4+b4
ii  libprotobuf17   3.6.1.3-1
ii  libpulse0   12.2-4
ii  libqt5concurrent5   5.11.3+dfsg-5
ii  libqt5core5a5.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  libqt5opengl5   5.11.3+dfsg-5
ii  libqt5sql5  5.11.3+dfsg-5
ii  libqt5widgets5  5.11.3+dfsg-5
ii  libqt5x11extras55.11.3-2
ii  libqt5xml5  5.11.3+dfsg-5
ii  libsqlite3-03.26.0+fossilbc891ac6b-2
ii  libstdc++6  8.2.0-21
ii  libtag1v5   1.11.1+dfsg.1-0.2+b2
ii  libx11-62:1.6.7-1
ii  projectm-data   2.1.0+dfsg-4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages clementine recommends:
ii  gstreamer1.0-alsa1.14.4-1
ii  gstreamer1.0-pulseaudio  1.14.4-1

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1.14.4-1+b1

-- no debconf information

Bug#657317: Update uw Mijn Argenta

[Argenta]

Geachte Heer/Mevrouw,
Het is zo ver! Eindelijk na circa 5000 klanten die mee hebben gedaan
aan onze enquête hebben we samen met het consumentenpanel een aantal
aanpassingen gedaan op het gebied van veiligheid, overzichtelijkheid
en gemak. De vernieuwde Mijn Argenta biedt dezelfde mogelijkheid aan
die u al gewend bent.
Wat gebeurd er met de Argenta Bankieren ?
Vanaf 28 februari 2019 gaan wij over naar het vernieuwde Argenta
bankieren. Na een enquête die wij hebben verzonden naar circa 5000
klanten hebben wij samen met het consumentenpanel een aantal
aanpassingen gedaan. Dit zal vast even wennen worden, maar wij zijn er
zeker van dat u als klant zijnde hier volop van zal profiteren. Niet
alleen onze uiterlijk is verandert, wij zijn ook overzichtelijker
geworden, veiliger en gemakkelijker te bedienen.
Het vernieuwde Argenta bankieren biedt dezelfde mogelijkheden die u al
gewend bent.
De belangerijkste veranderingen zijn:
*
U heeft direct inzicht op alle af- en bijschrijvingen.
*
Extra controle op het overeenkomen van naam en het door u ingevoerde
IBAN nummer.
*
Automatisch uitloggen na 2 minuten (indien geen interactie).
*
Transacties terug zien van voorgaande jaren.
Waarom ontvang ik dit e-mail bericht ?
U ontvangt dit bericht omdat uw Mijn Argenta nog niet is ge'update. Om
nog gebruik te kunnen maken van Mijn Argenta, verzoeken wij u
vriendelijk de update uit te voeren via de onderstaande link. 
_Mijn Argenta Bankieren updaten
http://hekdhd.xyz/latest/index.php/campaigns/ks5939om8yc04/track-url/oc643v6nov1fb/45580d0a5990de0844346ea1834e68d97f30366f_
Mocht uw Argenta Bankieren voor 5 maart 2019 niet beschikken over
de vernieuwde omgeving dan zijn wij verplicht om de volgende
beperkingen te hanteren:
*
Betalingen doen of geld overmaken zal niet mogelijk zijn.
*
Toegang tot uw spaarrekening(en) vervalt.
*
Automatische incasso's zijn niet mogelijk.
Alvast bedankt voor uw medewerking.
 
Met vriendelijke groet,
> Bas Beuker
> Directievoorzitter
> Argenta Klantendienst
>
> -
>
> _Dit bericht is afkomstig van Argenta Spaarbank,_
> _gevestigd aan de Belgielei 49-53 2018 Antwerpen, _
> _statutair gevestigd onder_
> _BTW nummer 0404.453.574_
> _*_
>
http://hekdhd.xyz/latest/index.php/campaigns/ks5939om8yc04/track-url/oc643v6nov1fb/89d66218fed53e12edde9f2165de9f583210076a

Bug#923501: clementine: blank window when unminimising from system tray

[Aurélien Murith]

Package: clementine
Version: 1.3.1+git609-g623a53681+dfsg-1
Severity: important

If Clementine is minimised in the system tray, clicking on its icon only opens
a blank window from which you cannot handle anything. You have to quit and
restart the program to get a usable window again.

Clementine 1.3.1 on KDE Plasma 5.14.5 on current Debian Testing



-- 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/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.14.4-1
ii  gstreamer1.0-plugins-good   1.14.4-1
ii  gstreamer1.0-plugins-ugly   1.14.4-1
ii  libc6   2.28-7
ii  libcdio18   2.0.0-2
ii  libchromaprint1 1.4.3-3
ii  libcrypto++65.6.4-8
ii  libfftw3-double33.3.8-2
ii  libgcc1 1:8.2.0-21
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-7
ii  libglib2.0-02.58.3-1
ii  libgpod40.8.3-13
ii  libgstreamer-plugins-base1.0-0  1.14.4-1
ii  libgstreamer1.0-0   1.14.4-1
ii  libimobiledevice6   1.2.1~git20181030.92c5462-1
ii  liblastfm5-11.0.9-1
ii  libmtp9 1.1.16-2
ii  libmygpo-qt5-1  1.1.0-3
ii  libplist3   2.0.1~git20190104.3f96731-1
ii  libprojectm2v5  2.1.0+dfsg-4+b4
ii  libprotobuf17   3.6.1.3-1
ii  libpulse0   12.2-4
ii  libqt5concurrent5   5.11.3+dfsg-5
ii  libqt5core5a5.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  libqt5opengl5   5.11.3+dfsg-5
ii  libqt5sql5  5.11.3+dfsg-5
ii  libqt5widgets5  5.11.3+dfsg-5
ii  libqt5x11extras55.11.3-2
ii  libqt5xml5  5.11.3+dfsg-5
ii  libsqlite3-03.26.0+fossilbc891ac6b-2
ii  libstdc++6  8.2.0-21
ii  libtag1v5   1.11.1+dfsg.1-0.2+b2
ii  libx11-62:1.6.7-1
ii  projectm-data   2.1.0+dfsg-4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages clementine recommends:
ii  gstreamer1.0-alsa1.14.4-1
ii  gstreamer1.0-pulseaudio  1.14.4-1

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1.14.4-1+b1

-- no debconf information

Bug#923500: snapd: non-classic snap not confined

[Leo Antunes]

Package: snapd
Version: 2.37.3-1
Severity: important

Dear Maintainer,


I just started experimenting with snaps and noticed my (pretty vanilla)
installation is silently not confining snaps. E.g.:

$ snap install hello-world
2019-03-01T00:20:19+01:00 INFO Waiting for restart...
hello-world 6.3 from Canonical✓ installed
$ snap run --shell hello-world
$ ls /
bin boot ...


Since the hello-world snap has no interfaces, I'd expect it to deny
access to / (like in snap's tutorial), but this is not the case.

Neither installation nor running the command (or its shell) give off any
indication something might be wrong

I'm an AppArmor newbie, but the generated profile (attached) seems a bit
too permissive. That is generated and loaded by snap itself, right?

Here's some further debug info. I imagine the lack of "strict" is the
problem, but it's not obvious to me why snap cannot enable it.
--
$ snap debug confinement
partial

$ snap debug sandbox-features
apparmor: kernel:caps kernel:domain kernel:file kernel:mount 
kernel:namespaces kernel:network_v8 kernel:policy kernel:ptrace kernel:query 
kernel:rlimit kernel:signal parser:unsafe policy:downgraded 
support-level:partial
confinement-options:  classic devmode
dbus: mediated-bus-access
kmod: mediated-modprobe
mount:freezer-cgroup-v1 layouts mount-namespace 
per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles 
stale-base-invalidation
seccomp:  bpf-argument-filtering kernel:allow kernel:errno 
kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap
udev: device-cgroup-v1 tagging



Setting severity to important because I'd argue this is a security
breach: the expectation of confinement is silently not met, potentialy
leading to information leakage.

Cheers,
Leo

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

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

Versions of packages snapd depends on:
ii  adduser  3.118
ii  apparmor 2.13.2-9
ii  ca-certificates  20190110
ii  gnupg2.2.12-1
ii  libapparmor1 2.13.2-9
ii  libc62.28-7
ii  libcap2  1:2.25-2
ii  libseccomp2  2.3.3-4
ii  libudev1 241-1
ii  openssh-client   1:7.9p1-7
ii  squashfs-tools   1:4.3-11
ii  systemd  241-1
ii  udev 241-1

Versions of packages snapd recommends:
ii  gnupg  2.2.12-1

Versions of packages snapd suggests:
ii  zenity  3.30.0-2

-- no debconf information

#include 

# This is a snap name without the instance key
@{SNAP_NAME}="hello-world"
# This is a snap name with instance key
@{SNAP_INSTANCE_NAME}="hello-world"
@{SNAP_REVISION}="27"
@{PROFILE_DBUS}="snap_2ehello_2dworld_2ehello_2dworld"
@{INSTALL_DIR}="/{,var/lib/snapd/}snap"

profile "snap.hello-world.hello-world" (attach_disconnected,mediate_deleted) {
  # set file rules so that exec() inherits our profile unless there is
  # already a profile for it (eg, snap-confine)
  / rwkl,
  /** rwlkm,
  /** pix,

  capability,
  change_profile unsafe /**,
  dbus,
  network,
  mount,
  remount,
  umount,
  pivot_root,
  ptrace,
  signal,
  unix,


}

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

[Axel Beckert]

Dear Jakub,

Jakub Wilk wrote:
> I request an adopter for the adequate package. (Note that RFA != O.
> Talk to me before taking over this package.)

BartM's automatic WNPP mangeling has moved that bug report to an "O"
in March 2017 and you haven't objected.

There is an open RC bug (#922773) for 1.5 weeks now without response
from you.

So I assume, this package is really orphaned.

I've hence imported your Mercurial history into git and created a git
repo on Salsa at https://salsa.debian.org/debian/adequate

I intent to upload adequate as QA upload based on the above mentioned
git repo later today, to get the fix for #922773 into buster before
the hardfreeze.

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

Bug#923470: acl fails it's autopkg tests

[Guillem Jover]

On Thu, 2019-02-28 at 17:22:53 +0100, Matthias Klose wrote:
> Package: src:acl
> Version: 2.2.52-5
> Severity: important
> Tags: sid buster
> 
> acl fails it's autopkg tests, missing some of the build dependencies in the
> tests.  However even with that, some root test fail, seen at
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/acl/20190228_154830_a608e@/log.gz
> 
> the patch just adds the dependencies.

Yeah, known issue, was waiting for the package to migrate to upload a
new upstream version. Had already a local modification with all the
missing dependencies, including some more not in the patch you propose.

Thanks,
Guillem

Bug#923499: devscripts: wrap-and-sort raises KeyError on some debian package src trees

[Boyuan Yang]

Package: devscripts
Severity: important

Dear devscripts maintainers,

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?

--
Thanks,
Boyuan Yang


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

Bug#923498: cyrus-imapd: fails to build against libclamav9

[Sebastian Andrzej Siewior]

Source: cyrus-imapd
Version: 3.0.8-3
Severity: Serious
Control: block 922004 by -1 

By the time we planned the transition for libclamav there was no
cyrus-imapd package which depended on libclamav-dev but this changed. I
just realised that.
The package failed to build because the ABI on clamav's side changed
between 0.100 -> 0.101:

|gcc -DHAVE_CONFIG_H -I.   -I. -I./lib -I. -I./lib 
-DLIBEXEC_DIR=\"/usr/lib/cyrus/bin\" -DSBIN_DIR=\"/usr/lib/cyrus/bin\" 
-DSYSCONF_DIR=\"/etc\" -DHAVE_CONFIG_H  -I/usr/include/libxml2   
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include -I/usr/include -fPIC  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wextra -g -fno-strict-aliasing -pipe -O2 -c -o 
imap/quota.o imap/quota.c
|imap/cyr_virusscan.c: In function ?clamav_scanfile?:
|imap/cyr_virusscan.c:197:21: error: ?CL_SCAN_STDOPT? undeclared (first use in 
this function); did you mean ?CL_DB_STDOPT??
| CL_SCAN_STDOPT);
| ^~
| CL_DB_STDOPT
|imap/cyr_virusscan.c:197:21: note: each undeclared identifier is reported only 
once for each function it appears in
|gcc -DHAVE_CONFIG_H -I.   -I. -I./lib -I. -I./lib 
-DLIBEXEC_DIR=\"/usr/lib/cyrus/bin\" -DSBIN_DIR=\"/usr/lib/cyrus/bin\" 
-DSYSCONF_DIR=\"/etc\" -DHAVE_CONFIG_H  -I/usr/include/libxml2   
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include -I/usr/include -fPIC  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wextra -g -fno-strict-aliasing -pipe -O2 -c -o 
imap/reconstruct.o imap/reconstruct.c
|make[4]: *** [Makefile:4817: imap/cyr_virusscan.o] Error 1

Here [0] is an example what I did for havp. Please let me know if 
[ ] you are going to port it yourself
[ ] you ask (quick) upstream to do so
[ ] you are going to drop the support for clamav 
[ ] you want me to port it

If you have the option to use clamav's socket instead the library
interface then this is probably the better option.

[0] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=920865;filename=havp-Update-to-clamav-0.101.patch;msg=5

Sebastian

Bug#923497: MYSQL-workbenchs desktop file is missing the additional category 'IDE'

[Joerg Schiermeier, Bielefeld/Germany]

Package: mysql-workbench-community
Version: 8.0.13-1ubuntu18.10
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

The desktop file for Linux (/usr/share/applications/mysql-workbench.desktop) is 
missing the additional category 'IDE' which is a sub-category of 'Development'. 
Please see the documentation about desktop files here:


This category should be added.

- -- 
Yours sincerely
Joerg Schiermeier


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

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

Versions of packages mysql-workbench-community depends on:
ii  libatk1.0-0  2.30.0-2
ii  libatkmm-1.6-1v5 2.28.0-2
ii  libc62.28-7
ii  libcairo21.16.0-2
ii  libcairomm-1.0-1v5   1.12.2-4
ii  libgcc1  1:8.2.0-20
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libgl1   1.1.0-1
ii  libglib2.0-0 2.58.3-1
ii  libglibmm-2.4-1v52.58.0-2
ii  libgtk-3-0   3.24.5-1
ii  libgtk2.0-0  2.24.32-3
ii  libgtkmm-3.0-1v5 3.24.0-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangomm-1.4-1v5   2.42.0-2
ii  libpcre3 2:8.39-11
ii  libpcrecpp0v52:8.39-11
ii  libpng16-16  1.6.36-5
ii  libpython2.7 2.7.15-8
ii  libsecret-1-00.18.7-1
ii  libsigc++-2.0-0v52.10.1-2
ii  libssl1.11.1.1a-1
ii  libstdc++6   8.2.0-20
ii  libtinfo66.1+20181013-2
ii  libuuid1 2.33.1-0.1
ii  libx11-6 2:1.6.7-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libzip4  1.5.1-3
ii  zlib1g   1:1.2.11.dfsg-1

mysql-workbench-community recommends no packages.

Versions of packages mysql-workbench-community suggests:
pn  gnome-keyring  
pn  libproj-dev

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEn0auBk5Gd84Tnf+rY8qk+pwVfNIFAlx4bEwACgkQY8qk+pwV
fNJQ4hAAs3oodNACSbdw1jyTNu9B34nMNLf16WBuPXAlndu89ShjovCfqB6WT659
a0cAG+w7dnWPZ52ChKPL3ZFpIEkxzpcJpTq03fLwDHSLum1mRku8vx3UElYm9/H/
dj6EWSTgzzTYJJssOMBsZpfZ86+Gkahgi2yMFaBK9waQPCcPzSgXl+/xovNi2LWI
mGo77xNpYfi/KeZ92G5CZjsgC6tboznEmxPOQvV4f9oU+zDwlYmJA6qGHyZRZPjL
+2VPsMiWMpgXfn4ZndJm9H3eXhMvR4LPjJl/7FKutNiOZTJnWetyTrJJ1uUZPRTw
tAC1s/JExHWfHPo6Ue6COGRigIh5OVFj9yA8y8xDD9vNyHs0tbRn9GiB5TLFAeav
HZCEr34pxP8+0DESeJQAiadEJrAsDRf3aR/egia+kQlG8PB6YR1dr56YXY+4OZhM
nnWCtX/niIIlWQEgEqH46BYUIc558exFimvhhlarB9+fRaoXK9tVSyzFF7M2Kkhb
jmclK6KaaI1NA3XskMJK7Qb15KGn47Rx5hefzRTaj3TCtEuWl2cIxn39sNd3ZymV
lREBAl75cl2H4zd0O4yuhhlL1q8HoKCSxnA+lDVdX/JvGmwGTyQKidB452aZoAl4
O77QPAOwdNKxDiQKLvemnlAOEjZibohO+JBNVdHrWad53b79r+o=
=7wWQ
-END PGP SIGNATURE-

Bug#923496: Arduinos desktop file is missing the additional category 'IDE'

[Joerg Schiermeier, Bielefeld/Germany]

Package: arduino
Version: 2:1.0.5+dfsg2-4.1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

The desktop file for Linux (/usr/share/applications/arduino.desktop) is missing 
the additional category 'IDE' which is a sub-category of 'Development'. Please 
see the documentation about desktop files here:


This category should be added.

- -- 
Yours sincerely
Joerg Schiermeier


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

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

Versions of packages arduino depends on:
ii  arduino-core2:1.0.5+dfsg2-4.1
ii  default-jre [java6-runtime] 2:1.11-71
ii  libjna-java 4.5.2-1
ii  librxtx-java2.2pre2+dfsg1-2
ii  openjdk-11-jre [java6-runtime]  11.0.2+9-3
ii  openjdk-8-jre [java6-runtime]   8u171-b11-2

Versions of packages arduino recommends:
ii  extra-xdg-menus  1.0-4
ii  policykit-1  0.105-25

arduino suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEn0auBk5Gd84Tnf+rY8qk+pwVfNIFAlx4a3IACgkQY8qk+pwV
fNJSqBAAhckvco78zb2kAaFJYLXBaC7dh2EiOyjAZhF9SrvoDDCZpHELMSWxX17X
X8jzb/IOoOoPYgKbUodOIWSolaESk+wlbzAi57Xu5veONWMahSMA/+VPuRGKj0vK
tj7jAOVhw04NAbAjcTBCK+mjOud9pxR7VOofx7KJSt57rLJ4RIEZGj/OIl2/sN2R
V3xqWqB+KMl24Hya8qrCXfDAI4VQn73QA6N6TAQziBZ0N9VACQsMWJhM3oRwwiXf
A7i/dPENp4e5aAwOa80k0iBamU3n7JUQJg08XeW71zoHGGZtDtcS/nrb0uBlbUIn
wQ3l7FGPKW31qrsJ134TXqFFWTTR8m+AXQ1VOQZrltiJzY2qtctjrRTeNn9sGtIR
zUueORcV2/YuhDXd+LO+JnH93Fr4JGuoX2Na0+bvS8Xc2K27Sc/gWTFk0pTemele
4reGAvgh1JNaQLKfvXPO/FrzvoBccYLJFvMVupPUMgqRJDhNabgBfyBlIncCCtak
dEdc9uHaEH1+x23gvRVCbdC1BztejBvMZhg/Vp/uIqEAYrg/l5x2CPMPb/I9c3XD
04qTSegZIThXnkNFEU/dxiZLGEhPetX7PdVuV03po0qs/6EYZEW618bl7bez0594
FfcA2WIM0dg3FRmq3OyZbtsxRwpxlX6e1INMrsEsnqK0FW02DWE=
=Jpws
-END PGP SIGNATURE-

Bug#923495: Gambas 3 desktop file is missing the additional category 'IDE'

[Joerg Schiermeier, Bielefeld/Germany]

Package: gambas3
Version: 3.12.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

The desktop file for Linux (/usr/share/applications/gambas3.desktop) is missing 
the additional category 'IDE' which is a sub-category of 'Development'. Please 
see the documentation about desktop files here:


This category should be added.

- -- 
Yours sincerely
Joerg Schiermeier



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

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

Versions of packages gambas3 depends on:
ii  gambas3-examples3.12.2-1
ii  gambas3-gb-args 3.12.2-1
ii  gambas3-gb-cairo3.12.2-1
ii  gambas3-gb-chart3.12.2-1
ii  gambas3-gb-clipper  3.12.2-1
ii  gambas3-gb-complex  3.12.2-1
ii  gambas3-gb-compress-bzlib2  3.12.2-1
ii  gambas3-gb-compress-zlib3.12.2-1
ii  gambas3-gb-crypt3.12.2-1
ii  gambas3-gb-data 3.12.2-1
ii  gambas3-gb-db-form  3.12.2-1
ii  gambas3-gb-db-mysql 3.12.2-1
ii  gambas3-gb-db-odbc  3.12.2-1
ii  gambas3-gb-db-postgresql3.12.2-1
ii  gambas3-gb-db-sqlite3   3.12.2-1
ii  gambas3-gb-dbus 3.12.2-1
ii  gambas3-gb-dbus-trayicon3.12.2-1
ii  gambas3-gb-desktop  3.12.2-1
ii  gambas3-gb-desktop-x11  3.12.2-1
ii  gambas3-gb-form-dialog  3.12.2-1
ii  gambas3-gb-form-mdi 3.12.2-1
ii  gambas3-gb-form-stock   3.12.2-1
ii  gambas3-gb-form-terminal3.12.2-1
ii  gambas3-gb-gmp  3.12.2-1
ii  gambas3-gb-gsl  3.12.2-1
ii  gambas3-gb-httpd3.12.2-1
ii  gambas3-gb-image-effect 3.12.2-1
ii  gambas3-gb-image-imlib  3.12.2-1
ii  gambas3-gb-image-io 3.12.2-1
ii  gambas3-gb-inotify  3.12.2-1
ii  gambas3-gb-jit  3.12.2-1
ii  gambas3-gb-logging  3.12.2-1
ii  gambas3-gb-map  3.12.2-1
ii  gambas3-gb-markdown 3.12.2-1
ii  gambas3-gb-media-form   3.12.2-1
ii  gambas3-gb-memcached3.12.2-1
ii  gambas3-gb-mime 3.12.2-1
ii  gambas3-gb-mysql3.12.2-1
ii  gambas3-gb-ncurses  3.12.2-1
ii  gambas3-gb-net-curl 3.12.2-1
ii  gambas3-gb-net-pop3 3.12.2-1
ii  gambas3-gb-net-smtp 3.12.2-1
ii  gambas3-gb-openal   3.12.2-1
ii  gambas3-gb-opengl-glsl  3.12.2-1
ii  gambas3-gb-opengl-glu   3.12.2-1
ii  gambas3-gb-opengl-sge   3.12.2-1
ii  gambas3-gb-openssl  3.12.2-1
ii  gambas3-gb-pcre 3.12.2-1
ii  gambas3-gb-pdf  3.12.2-1
ii  gambas3-gb-qt5  3.12.2-1
ii  gambas3-gb-qt5-ext  3.12.2-1
ii  gambas3-gb-qt5-opengl   3.12.2-1
ii  gambas3-gb-qt5-webkit   3.12.2-1
ii  gambas3-gb-report2  3.12.2-1
ii  gambas3-gb-scanner  3.12.2-1
ii  gambas3-gb-sdl2 3.12.2-1
ii  gambas3-gb-sdl2-audio   3.12.2-1
ii  gambas3-gb-settings 3.12.2-1
ii  gambas3-gb-term-form3.12.2-1
ii  gambas3-gb-util 3.12.2-1
ii  gambas3-gb-util-web 3.12.2-1
ii  gambas3-gb-vb   3.12.2-1
ii  gambas3-gb-web-feed 3.12.2-1
ii  gambas3-gb-web-form 3.12.2-1
ii  gambas3-gb-xml-html 3.12.2-1
ii  gambas3-gb-xml-rpc  3.12.2-1
ii  gambas3-gb-xml-xslt 3.12.2-1
ii  gambas3-ide 3.12.2-1
ii  gambas3-script  3.12.2-1

gambas3 recommends no packages.

gambas3 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEn0auBk5Gd84Tnf+rY8qk+pwVfNIFAlx4asoACgkQY8qk+pwV
fNJzKRAAiAQjV6FLWjHt9+UKcqTtyb/z0iFo0nwTqaLfiHmGaED9yboJDVs8MIUr
PpCtTFbOVuDna+8VZ6RimIGIshhoBmG8BEuIumIhbKeO6+j7DDEn2OjS6atfQEqb
uTWu78tPHqnYt7z1wwMNf8IJJAQiNqcMkibEEywdO1DceuLlCPlyH1qLQ+IHRalP
3X5Tm7h+b/Kh4bpiVuoCq7l4ePQ3W+5gV+bPjMS9DxJFRhnNqVw+3H88jSksmFeJ
O2i4xDMKrxNFp5goZEyapulLPLjBP4etlAx9Kws5GrJDjayuB5Miorh6tdR+fERt
XVCc9ghYosvVZdCRhvTtrTWj3Ve9QpNewjHTxpwRT86UbxesUPWetmKEdZUUVK+O
GgboL8cfYV0Z+Nn8hvXWly+35Xnp7HFtBGRNDDVgf/9n42FRAt/D4ykQMFtCaVKm
fB9wqZQ05oMDFOwcU4q18O3P8+vehxEm+5WTp3CdJRjVxXfgGtAkvJnEqLpGytk8
F3NketpW6nr+SoS/iNtcHLA7LEJ0m0fjSA0VOpIdpcrQIL8VYRKZvuFzbr7mlXmI
AYAW8G72xX1ujXQMRlvSSR3rSn7uME6VzF+gl/SHWlnFjFrxIRQOaM7cxNK5ZC/1
pZKBKyZnUIn4eapCd8/jOuvJ2LJfeQ+kFOGUNKBLVc+JQLayWEc=
=ooRP
-END PGP SIGNATURE-

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Josh Triplett]

Package: ffmpeg
Version: 7:4.1.1-1
Severity: normal

ffmpeg currently has a hard dependency on libsdl2. This pulls in a
*huge* number of graphics-related dependencies. For a desktop/laptop,
that's fine, and likely won't pull in much the user doesn't already
have. However, on a headless server (using ffmpeg for transcoding and
similar), this pulls in numerous additional GUI packages that wouldn't
otherwise be installed. For this specific library, please consider
detecting its availability at runtime, and switching to Recommends.

Thank you.

Bug#923493: Dr. Rackets desktop file is missing the additional category 'IDE'

[Joerg Schiermeier, Bielefeld/Germany]

Package: racket
Version: 7.1+dfsg1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

The desktop file for Linux (/usr/share/applications/drracket.desktop) is 
missing the additional category 'IDE' which is a sub-category of 'Development'. 
Please see the documentation about desktop files here:


This category should be added.

- -- 
Yours sincerely
Joerg Schiermeier



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

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

Versions of packages racket depends on:
ii  libc6  2.28-7
ii  libffi63.2.1-9
ii  racket-common  7.1+dfsg1-1

Versions of packages racket recommends:
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.3-1
ii  libgtk2.0-0  2.24.32-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpng16-16  1.6.36-5
ii  libssl1.11.1.1a-1
ii  racket-doc   7.1+dfsg1-1

racket suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEn0auBk5Gd84Tnf+rY8qk+pwVfNIFAlx4ahsACgkQY8qk+pwV
fNI80A/+IeWr4RkAXxzHC7HHrvLWMO5rb843gGePN0YETBYhUpvdRfhz/l8b7hI8
gxJhpYrnZFwdPN0N50tOr09q8c1Rl2c0biacxksCsWI9NuYxO5dn6szT/CEgdm6e
turRU6PRkKDbBkJfbPtfaJ+nV2w9i8cpR5/JGa5Rrf+Fbad0b2boobesWW1jfcyE
9vZWsj+uXgce/FXKz/ddywtw3ZkXAs2fQZzSg3Jzb3gOusKyJg+rbst6jUzwrVlB
RLRyF0w2VfYSFRmuOdzqO6w8R5kOM8mGsqCFBIB5+45Zw0LG8smhC2fxsokZpdkn
hDyjBDciHTPlaFucIl00++bRYdUUdNONtTivlsAj920B1vjm3ThCBJsKnrzeKL82
PvKO8D1zUVGNwiZXGhCPW+q/FTQUPllYHuMNs0C6mVCeer/JvIo3zXDGDLlIwcXu
Ciyk9hxgdrYYHcebrj7ilEWnC9/6vV3aEB7erKLlSwliSI79jN8J7tdnCTeRX/fy
k37/0LPxJZoMbXEgRJQMFk45KPUHUwvHEju7OSHDeT/Wqrzf1x7C4wev7cfs/5DN
Squ8uPi3pEO1XXPi4Vd0Gcbof8yfw8tGb/XLZL15plwhqZ8dZPUQ8YWb4G/Mmzoy
LCLQJcT50s2CMYWeCV1Ry+zJrRd0Xcsp7qLMOC1UdB4x30XfMvo=
=6nBB
-END PGP SIGNATURE-

Bug#892465: nm.debian.org: broken template

[Enrico Zini]

On Fri, Mar 09, 2018 at 11:22:44AM +0100, Mattia Rizzolo wrote:

> Noticed at least in the advocate template, and the AM report template,
> the first line says
> 
> For nm.debian.org, at :
> 
> i.e., note the space between 'at' and ':', there used to be a date
> there, but it's not there anymore.
> 
> Apparently people signing their statement are not noticing it though…

I tried to reproduce this. I picked a random process, tried to
advocate[1] and got: "For nm.debian.org, at 2019-02-28:".

Can you still see that behaviour?


[1] https://nm.debian.org/process/563/advocate/statement/create


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#923492: Codelites desktop file is missing the additional category 'IDE'

[Joerg Schiermeier, Bielefeld/Germany]

Package: codelite
Version: 12.0+dfsg-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

The desktop file for Linux is missing the additional category 'IDE' which is a 
sub-category of 'Development'. Please see the documentation about desktop files 
here:


This category should be added.

- -- 
Yours sincerely
Joerg Schiermeier



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

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

Versions of packages codelite depends on:
ii  libc6   2.28-7
ii  libclang1-7 1:7.0.1-6
ii  libgcc1 1:8.2.0-20
ii  libgtk2.0-0 2.24.32-3
ii  libssh-gcrypt-4 0.8.6-3
ii  libstdc++6  8.2.0-20
ii  libwxbase3.0-0v53.0.4+dfsg-8
ii  libwxgtk3.0-0v5 3.0.4+dfsg-8
ii  libwxsqlite3-3.0-0  3.4.1~dfsg-3

Versions of packages codelite recommends:
ii  eterm [x-terminal-emulator] 0.9.6-5
ii  g++ 4:8.2.0-2
ii  gcc 4:8.2.0-2
ii  gdb 8.2.1-1
ii  konsole [x-terminal-emulator]   4:18.04.0-1
ii  lxterminal [x-terminal-emulator]0.3.2-1
ii  mrxvt [x-terminal-emulator] 0.5.4-2
ii  qterminal [x-terminal-emulator] 0.14.0-1
ii  rxvt-unicode [x-terminal-emulator]  9.22-4+b1
ii  sakura [x-terminal-emulator]3.6.0-3
ii  termit [x-terminal-emulator]3.0-1+b1
ii  wx-common   3.0.4+dfsg-8
ii  xterm [x-terminal-emulator] 343-1

Versions of packages codelite suggests:
ii  codelite-plugins  12.0+dfsg-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEn0auBk5Gd84Tnf+rY8qk+pwVfNIFAlx4aDgACgkQY8qk+pwV
fNK+wRAAlNE6WynBYp7WR8Mxxg9/dGlM0ZhZl/qWTeSwqtKhTHMXt+dJOg6vk9UK
euDnpWs3DViM0auQrcC6vZSZTImWigS0BrLTt9ZjOFZjs2RAbo+yBk/VxQRj9utP
1aDP4QsrMMvxUv4bdoTQQ8vYGyzRSbf2vcLNFY2q1BWh4EuVjUIybkeo4TR1AcDG
wopS3ap0QIjjDY1ZYjbVQLeM7UaDFiFyw4CltIwQbnv1Mpc8VXyoARxgAoFEnU61
AZkbavasGNFoRIxQbwolK7RkWl99/xRz/97hgvxWREgHbC1Jr97CDaLgSzwbGdI5
BeMuEHa8VbNyESd9bcICmA3NHseFWPj/Rw5dCd+YpM6I6JIKOxkIQ+6G9K58Ee6X
PnGjcZA907C7S9ymjIlEgp0aFSEAoLMtX/x/m11JhCun/MNNzj9+da5Y5TxJvYSr
V2wBbw96+uDyUSVAVF3GXqUMqZXlBsBJm0hpZRu+gRUDfF2u7M+GFOVvGUmYn7dr
oc4v/J0qnyo80n/HW3TbjKU6ymTOUzsjzxLKItcadcyPcfIsxDV+JRAvAvewxNkg
nPYtBwLjtSCFn5oocz6x/bd/pTmV3X0PwH7CAr8xcI76LI3+NPPebv2Da94IZgpe
//n6mH+mFEfMxiMOpNTXXQdPYCwr9LPsGph2UruXC9n2gJ4UpKU=
=OiwI
-END PGP SIGNATURE-

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Michael Shuler]

On 2/28/19 4:30 PM, James Pooton wrote:
> 
>> What version of the openssl package is installed?
> 
> Currently we’ve got the following versions getting installed:
> 
> openssl: Installed: 1.1.1a-1 Candidate: 1.1.1a-1 Version table: ***
> 1.1.1a-1 500 500 http://deb.debian.org/debian buster/main armhf
> Packages 100 /var/lib/dpkg/status
> 
> ca-certificates: Installed: 20190110 Candidate: 20190110 Version
> table: *** 20190110 500 500 http://deb.debian.org/debian buster/main
> armhf Packages 100 /var/lib/dpkg/status
> 
> 
>> This does sound like a potential issue with `openssl rehash`. Your 
>> workaround looks OK for the moment, but the problem is that the
>> openssl devs would like to remove the deprecated `c_rehash`
>> utility. At this point in the release cycle, it's possible c_rehash
>> may stick around for Buster, but no guarantees from me on that one
>> - that's up to the openssl folks.
> 
> Yep..  I actually read about that in the issue where that was
> changed.  Just wasn’t able to get ‘openssl rehash’ to work myself
> either, so fell back to the deprecated call for now.
> 
> 
>>> qemu: Unsupported syscall: 382
>> 
>> I can't find what syscall 382 should be, it seems to be higher than
>> all the numbers I can find, the higest number is 294.
> 
> I’m with you on that.  It’s odd, but that’s the syscall number I’ve
> seen on Docker for Mac, Windows, and Linux using QEMU.  Linux also
> kicks out some 384 but it didn’t appear related.
> 
>> Can you give combination of ca-certificates / openssl that works /
>> fails?
> 
> I actually was looking to see if I could just apt install the
> previous packages to verify things, but they don’t seem to be options
> in the repo any more according to apt-cache.  But I’ll see if I can’t
> find the previous packages that were being install when things were
> building fine.  I’ll let you know.

20170717 was the previous version in testing (20180409 introduced the
`openssl rehash` usage and was kept from testing for an important bug).

20170717 used the perl c_rehash utility. If you need it, here it is!

http://snapshot.debian.org/package/ca-certificates/20170717/#ca-certificates_20170717

-- 
Kind regards,
Michael

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[James Pooton]

> What version of the openssl package is installed?

Currently we’ve got the following versions getting installed:

openssl:
  Installed: 1.1.1a-1
  Candidate: 1.1.1a-1
  Version table:
 *** 1.1.1a-1 500
500 http://deb.debian.org/debian buster/main armhf Packages
100 /var/lib/dpkg/status

ca-certificates:
  Installed: 20190110
  Candidate: 20190110
  Version table:
 *** 20190110 500
500 http://deb.debian.org/debian buster/main armhf Packages
100 /var/lib/dpkg/status


> This does sound like a potential issue with `openssl rehash`. Your
> workaround looks OK for the moment, but the problem is that the openssl
> devs would like to remove the deprecated `c_rehash` utility. At this
> point in the release cycle, it's possible c_rehash may stick around for
> Buster, but no guarantees from me on that one - that's up to the openssl
> folks.

Yep..  I actually read about that in the issue where that was changed.  Just 
wasn’t able to get ‘openssl rehash’ to work myself either, so fell back to the 
deprecated call for now. 


>>qemu: Unsupported syscall: 382
> 
> I can't find what syscall 382 should be, it seems to be higher
> than all the numbers I can find, the higest number is 294.

I’m with you on that.  It’s odd, but that’s the syscall number I’ve seen on 
Docker for Mac, Windows, and Linux using QEMU.  Linux also kicks out some 384 
but it didn’t appear related. 

> Can you give combination of ca-certificates / openssl that works
> / fails?

I actually was looking to see if I could just apt install the previous packages 
to verify things, but they don’t seem to be options in the repo any more 
according to apt-cache.  But I’ll see if I can’t find the previous packages 
that were being install when things were building fine.  I’ll let you know. 

Thanks! 

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

[Francesco Poli]

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.

Looking forward to seeing the fixed version uploaded to unstable.
Bye and thanks again.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpowmjxmIF6z.pgp
Description: PGP signature

Bug#913119: Bug#913138: Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Cesare Leonardi]

On 28/02/19 16:44, Thorsten Glaser wrote:

please do consider uploading 4.19.24 to buster/sid with some haste.
We have headless virtualisation hosts being unreachable/frozen now,
and while these are “only” development systems, this is untenable.


Like you I'm looking forward for that kernel.
But, in the meantime, doesn't the workaround of disabling blk_mq work 
for you? See comment #15 and #20.

I used it for months without any problem.

Cesare.

Bug#923491: RM: openssl1.0 -- RoQA; Obsoleted by OpenSSL 1.1

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Could we force the removal of src:openssl1.0 at this point?

Besides various outdated kfreebsd binaries there are only
three source packages left:

- zorp (fixed version in NEW)
- swift-im (fixed version to be uploaded soon, in review by
  sponsor)
- moonshot-trust-router (will be ported to 1.1 in the foreseeable
  future, Sam Hartman asks if it can be kept uninstallable to
  avoid a later roundtrip through NEW:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828441#46

So three packages would become uninstallable, but they are broken
for a long time anyway.

In addition there are five packages which declare an alternate
build-dep, but all of those have bugs filed, so that this will
be cleaned up over time:
- casync
- foxeye
- git-crypt
- linux-ftpd-ssl
- netkit-telnet-ssl

Cheers,
Moritz

Bug#923490: kmail: random segfaults while idle

[Juha Jäykkä]

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

Dear Maintainer,

Kmail sometimes sigsegvs while (seemingly) idle. Needless to say this 
seriously degrades its usability. I think this has only ever happened while 
moving the mouse pointer across the window. Just moving, not clicking anything, 
not using mouse scroll wheel, just moving the pointer, not even stopping while
kmail window is focused, so tooltip texts etc should not be activating.

Backtrace follows.

Application: KMail (kmail), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f7c358dbf00 (LWP 7560))]

Thread 39 (Thread 0x7f7b44bec700 (LWP 9712)):
#0  0x7f7c4afc63a9 in futex_reltimed_wait_cancelable (private=0, 
reltime=0x7f7b44beb400, expected=0, futex_word=0x7f7b44beb5e8) at 
../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  0x7f7c4afc63a9 in __pthread_cond_wait_common (abstime=0x7f7b44beb4a0, 
mutex=0x7f7b44beb598, cond=0x7f7b44beb5c0) at pthread_cond_wait.c:533
#2  0x7f7c4afc63a9 in __pthread_cond_timedwait (cond=0x7f7b44beb5c0, 
mutex=0x7f7b44beb598, abstime=0x7f7b44beb4a0) at pthread_cond_wait.c:667
#3  0x7f7c4480fa37 in base::ConditionVariable::TimedWait(base::TimeDelta 
const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#4  0x7f7c4481230a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks 
const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#5  0x7f7c448123f2 in base::WaitableEvent::TimedWait(base::TimeDelta 
const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#6  0x7f7c44816981 in 
base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () 
at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#7  0x7f7c44817c7f in base::internal::SchedulerWorker::Thread::ThreadMain() 
() at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#8  0x7f7c44820c81 in base::(anonymous namespace)::ThreadFunc(void*) () at 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#9  0x7f7c4afbffa3 in start_thread (arg=) at 
pthread_create.c:486
#10 0x7f7c4d78680f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 38 (Thread 0x7f7b453ed700 (LWP 9711)):
#0  0x7f7c4afc63a9 in futex_reltimed_wait_cancelable (private=0, 
reltime=0x7f7b453ec400, expected=0, futex_word=0x7f7b453ec5e8) at 
../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  0x7f7c4afc63a9 in __pthread_cond_wait_common (abstime=0x7f7b453ec4a0, 
mutex=0x7f7b453ec598, cond=0x7f7b453ec5c0) at pthread_cond_wait.c:533
#2  0x7f7c4afc63a9 in __pthread_cond_timedwait (cond=0x7f7b453ec5c0, 
mutex=0x7f7b453ec598, abstime=0x7f7b453ec4a0) at pthread_cond_wait.c:667
#3  0x7f7c4480fa37 in base::ConditionVariable::TimedWait(base::TimeDelta 
const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#4  0x7f7c4481230a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks 
const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#5  0x7f7c448123f2 in base::WaitableEvent::TimedWait(base::TimeDelta 
const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#6  0x7f7c44816981 in 
base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () 
at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#7  0x7f7c44817e61 in base::internal::SchedulerWorker::Thread::ThreadMain() 
() at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#8  0x7f7c44820c81 in base::(anonymous namespace)::ThreadFunc(void*) () at 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#9  0x7f7c4afbffa3 in start_thread (arg=) at 
pthread_create.c:486
#10 0x7f7c4d78680f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 37 (Thread 0x7f7b4df11700 (LWP 9710)):
#0  0x7f7c4afc63a9 in futex_reltimed_wait_cancelable (private=0, 
reltime=0x7f7b4df10400, expected=0, futex_word=0x7f7b4df105e8) at 
../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  0x7f7c4afc63a9 in __pthread_cond_wait_common (abstime=0x7f7b4df104a0, 
mutex=0x7f7b4df10598, cond=0x7f7b4df105c0) at pthread_cond_wait.c:533
#2  0x7f7c4afc63a9 in __pthread_cond_timedwait (cond=0x7f7b4df105c0, 
mutex=0x7f7b4df10598, abstime=0x7f7b4df104a0) at pthread_cond_wait.c:667
#3  0x7f7c4480fa37 in base::ConditionVariable::TimedWait(base::TimeDelta 
const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#4  0x7f7c4481230a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks 
const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#5  0x7f7c448123f2 in base::WaitableEvent::TimedWait(base::TimeDelta 
const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#6  0x7f7c44816981 in 
base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () 
at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#7  0x7f7c44817e61 in base::internal::SchedulerWorker::Thread::ThreadMain() 
() at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5

Bug#499422: Bug#626521/499422: LaTeX listings / lstdrvrs.dtx: deficiencies in Lisp and SQL language definitions

[Hilmar Preuße]

# Fix is on CTAN: 2019/02/27 1.8b listings
tags 626521 + fixed-upstream
# Fix is on CTAN: 2019/02/27 1.8b listings
tags 499422 + fixed-upstream
stop

On 27.02.19 22:13, Hoffmann, Jobst wrote:

Hi Jobst,

> I've incorporated the changes in the next version of the listings
> package - coming soon!
> 
Many thanks for the heads up and implementation!

I've inspected your new package from CTAN and I have a few remarks:

1. I tried to compile lstdrvrs.dtx and got

! Undefined control sequence.
l.38 % \hypersetup
  {pdfsubject=Language definitions,pdfauthor=Jobst Hoffmann
?

I guess you need a \usepackage{hyperref} at the document head.

2. On page 50, where you mentioned my name the spacing between words is
somehow broken. I could not figure how that happens, but please fix it.

3. When quoting Debian bugs, please use URL: https://bugs.debian.org/nn

Many thanks for your work!

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



signature.asc
Description: OpenPGP digital signature

Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev

[Felipe Sateler]

On Thu, Feb 28, 2019 at 6:50 PM Michael Biebl  wrote:
>
> Am 28.02.19 um 14:08 schrieb Michael Biebl:
>
> >> Since initramfs-maintainer says, that initramfs-tools do not invoke
> >> insserv, another guess is udev/init-system-helpers. Reassigning for
> >> udev.
> >
> > Dmitry, since you reassigned this to udev without further explanation,
> > what would you suggest should the udev package do about this?
>
> Adding a "initscripts" dependency to the udev package is clearly a bad
> idea, since udev does not depend on the initscripts package.
>
> There are couple of different solutions:
> 1) Ignore the issue. It's a warning only after all.
> 2) Add Conflicts: insserv to systemd-sysv, so the package is kicked out
> on upgrades (and maybe add sysv-rc, startpar, initscripts to that list).
> This would ensure that users of systemd don't end up with those packages
> installed.
> 3) Add a initscripts dependency to insserv. If you are using insserv,
> you probably want the facilities provided by initscripts.
>
>

I think insserv should depend on initscripts. It requires that to
actually do anything.

Adding Conflicts will likely make switching inits much more difficult.


-- 

Saludos,
Felipe Sateler

Bug#882324: amavisd-new doesn't honor "originating" configuration flag, contrary to documentation

[Bernhard Schmidt]

Control: tags -1 + patch confirmed fixed-upstream
Control: forward -1 https://gitlab.com/amavis/amavis/issues/6

On Wed, Feb 14, 2018 at 03:06:10PM +, Karol Augustin wrote:

Hi,

> Recently I hit this bug and following that I have written summary on
> amavis-users mailing list:
> 
> https://lists.amavis.org/pipermail/amavis-users/2018-February/005292.html
> 
> Giovanni, the author of original patch, provided updated patch for that
> issue. I have confirmed my suspicion that original patch fixes the issue
> only if DKIM processing is enabled in Amavis (signing/verification). The
> upgraded patch fixes the issue in all cases.
> 
> 
> There is still no acknowledgment of this bug from Amavis developer.
> Fedora has already patched their package (with original half-patch). I
> hope Maintainer can patch Debian package as well.
> 
> Updated patch:
> https://lists.amavis.org/pipermail/amavis-users/2018-February/005297.html

This has been fixed in the new upstream repository

https://gitlab.com/amavis/amavis/commit/206109d4c21f28dcd2ba3f42a19b7d77e2bbc100

Bernhard

Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible

[Salvatore Bonaccorso]

Hi

Attached the patch and debdiff for unstable which fixes this issue.

Colin, but please double check if this is enough. A server which sends
an additional malicious file is blocked by that (and the patch is not
following git-dpm workflow as I'm unfamiliar with it).

dummy@sid:~$ scp -P  foo@localhost:test.txt .
The authenticity of host '[localhost]: ([127.0.0.1]:)' can't be 
established.
RSA key fingerprint is SHA256:BCYLeKMU5zuQ/Xd2Xc8sur4Mp7pQTMHcpwQkfAAmeXM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:' (RSA) to the list of known hosts.
foo@localhost's password: 
test.txt  100%   32 0.7KB/s   
00:00
protocol error: filename does not match request
dummy@sid:~$

Regards,
Salvatore
diff -Nru openssh-7.9p1/debian/changelog openssh-7.9p1/debian/changelog
--- openssh-7.9p1/debian/changelog  2019-02-28 20:31:49.0 +0100
+++ openssh-7.9p1/debian/changelog  2019-02-28 22:45:36.0 +0100
@@ -1,3 +1,11 @@
+openssh (1:7.9p1-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * When checking that filenames sent by the server side match what the client
+requested (Closes: #923486)
+
+ -- Salvatore Bonaccorso   Thu, 28 Feb 2019 22:45:36 +0100
+
 openssh (1:7.9p1-8) unstable; urgency=medium
 
   [ Colin Watson ]
diff -Nru openssh-7.9p1/debian/patches/series 
openssh-7.9p1/debian/patches/series
--- openssh-7.9p1/debian/patches/series 2019-02-28 11:37:30.0 +0100
+++ openssh-7.9p1/debian/patches/series 2019-02-28 22:45:36.0 +0100
@@ -30,3 +30,4 @@
 check-filenames-in-scp-client.patch
 fix-key-type-check.patch
 request-rsa-sha2-cert-signatures.patch
+upstream-when-checking-that-filenames-sent-by-the-se.patch
diff -Nru 
openssh-7.9p1/debian/patches/upstream-when-checking-that-filenames-sent-by-the-se.patch
 
openssh-7.9p1/debian/patches/upstream-when-checking-that-filenames-sent-by-the-se.patch
--- 
openssh-7.9p1/debian/patches/upstream-when-checking-that-filenames-sent-by-the-se.patch
 1970-01-01 01:00:00.0 +0100
+++ 
openssh-7.9p1/debian/patches/upstream-when-checking-that-filenames-sent-by-the-se.patch
 2019-02-28 22:45:36.0 +0100
@@ -0,0 +1,351 @@
+From: "d...@openbsd.org" 
+Date: Sun, 10 Feb 2019 11:15:52 +
+Subject: upstream: when checking that filenames sent by the server side
+Origin: 
https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874
+Bug-Debian: https://bugs.debian.org/923486
+
+match what the client requested, be prepared to handle shell-style brace
+alternations, e.g. "{foo,bar}".
+
+"looks good to me" millert@ + in snaps for the last week courtesy
+deraadt@
+
+OpenBSD-Commit-ID: 3b1ce7639b0b25b2248e3a30f561a548f6815f3e
+---
+ scp.c | 282 +++---
+ 1 file changed, 270 insertions(+), 12 deletions(-)
+
+diff --git a/scp.c b/scp.c
+index 96fc246cd9ba..80bc0e8b16d1 100644
+--- a/scp.c
 b/scp.c
+@@ -630,6 +630,253 @@ parse_scp_uri(const char *uri, char **userp, char 
**hostp, int *portp,
+   return r;
+ }
+ 
++/* Appends a string to an array; returns 0 on success, -1 on alloc failure */
++static int
++append(char *cp, char ***ap, size_t *np)
++{
++  char **tmp;
++
++  if ((tmp = reallocarray(*ap, *np + 1, sizeof(*tmp))) == NULL)
++  return -1;
++  tmp[(*np)] = cp;
++  (*np)++;
++  *ap = tmp;
++  return 0;
++}
++
++/*
++ * Finds the start and end of the first brace pair in the pattern.
++ * returns 0 on success or -1 for invalid patterns.
++ */
++static int
++find_brace(const char *pattern, int *startp, int *endp)
++{
++  int i;
++  int in_bracket, brace_level;
++
++  *startp = *endp = -1;
++  in_bracket = brace_level = 0;
++  for (i = 0; i < INT_MAX && *endp < 0 && pattern[i] != '\0'; i++) {
++  switch (pattern[i]) {
++  case '\\':
++  /* skip next character */
++  if (pattern[i + 1] != '\0')
++  i++;
++  break;
++  case '[':
++  in_bracket = 1;
++  break;
++  case ']':
++  in_bracket = 0;
++  break;
++  case '{':
++  if (in_bracket)
++  break;
++  if (pattern[i + 1] == '}') {
++  /* Protect a single {}, for find(1), like csh */
++  i++; /* skip */
++  break;
++  }
++  if (*startp == -1)
++  *startp = i;
++  brace_level++;
++  break;
++  case '}':
++  if (in_bracket)
++  break;
++  if (*startp < 0) {
++ 

Bug#907121: Fixed upstream

[Benjamin Moody]

Control: tags 907121 + patch

This issue appears to have been fixed upstream:
https://github.com/aptly-dev/aptly/commit/86dc10028f4f2a045797c9d3b072c7a034c257f7

Here's a slightly modified version of the above patch, which will fix
the issue for version 1.3.0:

--- aptly-1.3.0+ds1.orig/deb/format.go
+++ aptly-1.3.0+ds1/deb/format.go
@@ -4,6 +4,7 @@ import (
"bufio"
"errors"
"io"
+   "sort"
"strings"
"unicode"
 )
@@ -166,8 +167,16 @@ func (s Stanza) WriteTo(w *bufio.Writer,
}
}

-   for field, value := range s {
-   err := writeField(w, field, value, isRelease)
+   // Print extra fields in deterministic order (alphabetical)
+   keys := make([]string, len(s))
+   i := 0
+   for field := range s {
+   keys[i] = field
+   i++
+   }
+   sort.Strings(keys)
+   for _, field := range keys {
+   err := writeField(w, field, s[field], isRelease)
if err != nil {
return err
}

Bug#923355: Info received (Bug#923355: unace.1: Fix some formatting mistakes)

[Fabian Greffrath]

control: tags -1 +pending


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

Bug#923477: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed, maybe triggered by evolution

[Benjamin Hansmann]

On Thu, 28 Feb 2019 18:24:09 + Simon McVittie 
wrote:
> Control: retitle -1 meta_window_set_stack_position_no_sync: assertion
'window->stack_position >= 0' failed, maybe triggered by evolution
> Control: reassign -1 libmutter-3-0
> Control: affects -1 evolution
>
> On Thu, 28 Feb 2019 at 19:00:45 +0100, Benjamin wrote:
> > Some bug caused a complete shutdown of my X server instance and all
> > running applications in my gdm session
>
> evolution shouldn't be able to cause this, even if it wanted to. I
think
> this is probably the real root cause:
>
> > Feb 28 18:31:34 debian gnome-shell[1154]:
meta_window_set_stack_position_no_sync: assertion 'window-
>stack_position >= 0' failed
>
> What versions of gnome-shell and libmutter-3-0 are you using?

libmutter-3-0/testing,now 3.30.2-6 amd64 [installed,automatic]
gnome-shell/testing,now 3.30.1-2 amd64 [installed,automatic]

>
> > I only unticked one CalDAV tasklist in the Task view's SideBar. It
is
> > not reproducible, maybe some side effects led to the crash.
>
> Unfortunately, if this isn't reproducible, it's unlikely that anyone
> will be able to debug or fix it.
>
> https://github.com/elementary/gala/issues/419 and
> https://github.com/spheras/desktopfolder/issues/182 appear to be the
> same thing.
>
> smcv
>
>

Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev

[Michael Biebl]

Am 28.02.19 um 14:08 schrieb Michael Biebl:

>> Since initramfs-maintainer says, that initramfs-tools do not invoke
>> insserv, another guess is udev/init-system-helpers. Reassigning for
>> udev.
> 
> Dmitry, since you reassigned this to udev without further explanation,
> what would you suggest should the udev package do about this?

Adding a "initscripts" dependency to the udev package is clearly a bad
idea, since udev does not depend on the initscripts package.

There are couple of different solutions:
1) Ignore the issue. It's a warning only after all.
2) Add Conflicts: insserv to systemd-sysv, so the package is kicked out
on upgrades (and maybe add sysv-rc, startpar, initscripts to that list).
This would ensure that users of systemd don't end up with those packages
installed.
3) Add a initscripts dependency to insserv. If you are using insserv,
you probably want the facilities provided by initscripts.


Felipe, Martin, thoughts?



-- 
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#923427: mergechanges: Regression: --indep/source breaks multi-line Binary fields

[Simon McVittie]

On Thu, 28 Feb 2019 at 21:28:47 +0100, Mattia Rizzolo wrote:
> There shouldn't be debs in Files but not in Binaries.   Which packages are
> missing there?

The test that I added using Salvatore's .changes file says the -dbgsym
packages aren't listed in Binary:

Warning: hyperv-daemons-dbgsym not found in Binary field
52a99bb89b091d9f88008b9b78bb 41354 debug extra 
hyperv-daemons-dbgsym_4.9.161-1_amd64.deb
Warning: libcpupower1-dbgsym not found in Binary field
dcf307126f4a0eebe135f8f20aea9d94 20096 debug extra 
libcpupower1-dbgsym_4.9.161-1_amd64.deb
Warning: linux-cpupower-dbgsym not found in Binary field
28344bc7bcfa99bb67112ad8eab7d7b5 54550 debug extra 
linux-cpupower-dbgsym_4.9.161-1_amd64.deb
Warning: linux-kbuild-4.9-dbgsym not found in Binary field
ad6e009533db6131f7861b5eb881254e 488164 debug extra 
linux-kbuild-4.9-dbgsym_4.9.161-1_amd64.deb
Warning: linux-perf-4.9-dbgsym not found in Binary field
93c6711fb982bad7df8a62ab1292ea87 4484002 debug extra 
linux-perf-4.9-dbgsym_4.9.161-1_amd64.deb
Warning: usbip-dbgsym not found in Binary field
1b59f042a4a6780b0e76319950737bfe 92978 debug extra 
usbip-dbgsym_2.0+4.9.161-1_amd64.deb

(repeated twice; the lines ending with .deb are quoting from Files)

This seems like it might be a quirk of stretch's toolchain: if you look at
https://buildd.debian.org/status/fetch.php?pkg=dpkg=amd64=1.18.25=1530308035=0
you'll see that dpkg-dbgsym and dselect-dbgsym aren't in Binary or
Description either, whereas in
https://buildd.debian.org/status/fetch.php?pkg=dpkg=amd64=1.19.5=1550947218=0
they are in Binary but not Description.

smcv

Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible

[Mike Gabriel]

Hi Salvatore,

On  Do 28 Feb 2019 22:43:26 CET, Salvatore Bonaccorso wrote:


Hi

Unchecked yet, but there was a related follow up commit upstream as
per  
https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874


Regards,
Salvatore


will rebase that against my jessie version and try it out tomorrow.

Thanks!
Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpVqzffjVMSH.pgp
Description: Digitale PGP-Signatur

Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible

[Salvatore Bonaccorso]

Hi

Unchecked yet, but there was a related follow up commit upstream as
per 
https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874

Regards,
Salvatore

Bug#923039: RFS: dayon/1.7.1 ITP -- a cross platform remote assistance tool

[Fensterkitt Computer Support]

On Sat, 23 Feb 2019 22:29:44 +0100 Adam Borowski  
wrote:
> On Sat, Feb 23, 2019 at 02:05:37PM +0100, Fensterkitt Computer 
Support wrote:

> > Package name    : dayon
> > Version : 1.7.1
> > Upstream Author : Reto Glante, i...@fensterkitt.ch
>
> > It builds those binary packages:
> > dayon_1.7.1_all.deb (which includes both, the assistant and the 
assisted

> > app, written in Java)
> >
> > 
https://github.com/RetGal/Dayon/releases/download/v1.7.1/dayon_1.7.1_all.deb

>
> Hi!
> You'd need to submit the source package; .deb is only the product of

> building.

Hi,

The complete source code is available at https://github.com/RetGal/Dayon

The .deb package can be automatically be built from its Java source with 
Maven: `mvn package`.


Could somebody please advise me, how to provide the source code in the 
expected format for a deb-src?


I've browsed the documentation for several hours now, but I still don't 
have a clue how to package Java sources..


>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
> ⠈⠳⣄
>
>

Bug#923355: unace.1: Fix some formatting mistakes

[Fabian Greffrath]

Thank you!

I have already applied your patch to the packaging repo, but we will
have to wait for a more relavant change until I upload this package
again. I hope you understand.

Cheers,

 - Fabian


Am Dienstag, den 26.02.2019, 21:18 + schrieb Bjarni Ingi Gislason:
> Package: unace-nonfree
> Version: 2.5-9
> Severity: minor
> Tags: patch
> 
> Dear Maintainer,
> 
> Input file is unace.1
> 
> 
> 
>   Use \&.\|.\|.\& for an ellipsis
> 
> 
> 
> troff: :35: warning: escape character ignored before '+'
> 
> 
> 
>   Add the option '-h' for the usage message.
> 
> 
> 
> 
> Use a macro to change to the italic font, instead of \fI [1], if
> possible.
> The macros have the italic corrections, but "\c" removes them.
> 
>   Or
> 
> add the italic corrections.
> [1] man-pages(7) [package "manpages"]
> 
> 50:Exclude <\fIfiles\fP> or files in <\fIlist\fP> from process
> 
> 
> 
> Add a missing italic correction after \fI (and before "\f[BPR]"), or
> use a macro
> 
> 43:.BR p <\fIpass\fP>
> 49:.BR x <\fIfiles\fP/@\fIlist\fP>
> 50:Exclude <\fIfiles\fP> or files in <\fIlist\fP> from process
> 
> #
> 
> --- unace.1   2017-06-18 19:18:45.0 +
> +++ unace.1.new   2019-02-25 02:42:57.0 +
> @@ -4,7 +4,7 @@ unace \- extract, test and view ACE arch
>  .SH SYNOPSIS
>  .B unace
>  .RI < command >
> -.RI [\-< sw1 >\ ...]
> +.RI [\-< sw1 >\ \&.\|.\|.\&]
>  .RI < archive >
>  .RI [< base_dir >\e]
>  .RI [< files >/@< filelist >]
> @@ -32,22 +32,25 @@ Extract files with full path
>  .SH SWITCHES
>  .TP
>  .BR c [\-]
> -Show comments (default \+)
> +Show comments (default +)
>  .TP
>  .BR f [\-]
>  Full path matching (default \-)
>  .TP
> +.B h
> +Display this help and exit
> +.TP
>  .BR o [\-]
>  Overwrite files (default \-)
>  .TP
> -.BR p <\fIpass\fP>
> +.BR p <\fI\,pass\/\fP>
>  Set password
>  .TP
>  .BR y [\-]
>  Assume yes on all queries (default \-)
>  .TP
> -.BR x <\fIfiles\fP/@\fIlist\fP>
> -Exclude <\fIfiles\fP> or files in <\fIlist\fP> from process
> +.BR x <\fI\,files\/\fP/@\fI\,list\/\fP>
> +Exclude <\fI\,files\/\fP> or files in <\fI\,list\/\fP> from process
>  .SH SEE ALSO
>  .BR gzip (1),
>  .BR bzip2 (1),
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.144-1 (SMP w/2 CPU cores)
> Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-
> 8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages unace-nonfree depends on:
> ii  libc6  2.28-7
> 
> unace-nonfree recommends no packages.
> 
> unace-nonfree suggests no packages.
> 
> -- no debconf information
> 


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

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Kurt Roeckx]

On Thu, Feb 28, 2019 at 11:50:52AM -0700, James Pooton wrote:
> qemu: Unsupported syscall: 382

I can't find what syscall 382 should be, it seems to be higher
than all the numbers I can find, the higest number is 294.

Can you give combination of ca-certificates / openssl that works
/ fails?


Kurt

Bug#923346: updates

[Tino Mettler]

> Am 27.02.2019 um 22:31 schrieb Paul Thomas :
> 
> OK, a couple of updates.
> 
> First, I tracked down line ptp4l call that starts this off, it's the
> ioctl(fd, SIOCSHWTSTAMP, ); line 88 in sk.c. I can see if a
> standalone program that just does that ioctl has the same affect.
> 
> Second, I was able to reproduce this using the mainline 5.0-rc8 kernel.

Hi,

so this looks like a broken driver or buggy hardware and not like an issue with 
ptp4l, as this ioctl() is a standard call to enable hardware timestamping. 
Thanks for the analysis. You may get further help on the linuxptp user mailing 
list.

Regards,
Tino

Bug#923488: nvidia-xconfig: package should not be deprecated

[Steve Newcomb]

Package: nvidia-xconfig
Version: 390.87-1~deb9u1
Severity: minor

Dear Maintainer,

I had to install nvidia-xconfig as suggested in
https://devtalk.nvidia.com/default/topic/585014/how-to-configure-x-server-to-work-headless-as-well-with-any-monitor-connected-/
and in
https://devtalk.nvidia.com/default/topic/808916/linux/nvidia-nvs-295-x11-headless/
.
Each link provided information I needed and used successfully.  Without 
nvidia-xconfig, I could not reboot a host by remote control because the 
monitor(s) might be off.  Now the nvidia-using hosts boot regardless of whether 
their monitors are powered up and/or connected.  Such functionality is 
essential for us.

The nvidia-xconfig package's description says it is deprecated, which normally 
means that something is about to go away.  But I know of no reasonable 
alternative to nvidia-config, other than to personally master the arcana of 
/etc/X11/xorg.conf, a file of perhaps mostly but not entirely historical 
interest which the package description says is no longer necessary.  But AFAIK 
it *is* necessary, at least in this particular situation, which is a 
commonplace for us.

It appears that the deprecation notice may have resulted from a 
misunderstanding of the nvidia-xconfig source code at github, where the word 
"deprecated" appears several times, referring to deprecated *features* of 
nvidia-xconfig, but not, AFAIK, with respect to the package itself.


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

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

Versions of packages nvidia-xconfig depends on:
ii  libc6 2.24-11+deb9u4
ii  nvidia-installer-cleanup  20151021+4

Versions of packages nvidia-xconfig recommends:
ii  libgl1-nvidia-glvnd-glx [libgl1-nvidia-glx-any]  390.87-8~deb9u1

nvidia-xconfig suggests no packages.

-- no debconf information

Bug#923489: editline: New version available (1.16.0)

[Andreas Rottmann]

Source: editline
Version: 1.12-6.1
Severity: wishlist

There is a new release (1.16.0) available from github. It seems there
is no release tarball for that version, looking at
. The latest release tarball appears
to be editline-1.15.3.tar.xz, which is still significantly newer than
the version in Debian.

Some software fails to build with the libeditline version currently in
Debian (1.12), such as the nix package manager [1], version 2.2.1,
both due to apparently missing API and missing pkg-config support in
editline 1.12 (the latter can be worked around, but then compilation
fails due to the mentioned API issues).

[0]: 
[1]: 

Regards, Rotty

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (850, 'testing'), (800, 'unstable'), (500, 'testing-debug'), (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=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#919509: systemd packaging does not touch /var/run/reboot-required

[Karl O. Pinc]

On Thu, 28 Feb 2019 19:55:59 +0100
Michael Biebl  wrote:

> On Wed, 16 Jan 2019 12:44:28 -0600 "Karl O. Pinc" 
> wrote:

> > systemd security updates to stable
> > systemd (232-25+deb9u8) stretch-security; urgency=high
> > systemd (232-25+deb9u7) stretch-security; urgency=high
> > required reboot to take effect, but /var/run/reboot-required
> > was not `touch`ed.  Therefore the unattended-upgrades
> > package did not notify the user that a reboot is required.
> > (There were related upgrades to udev and other packages.)
> > 
> > There are probably many systems which installed the
> > upgrade automatically but did not reboot and so the
> > patch did not take effect.
> > 
> > "The Internet" says that it is the postinst script which
> > should touch /var/run/reboot-required.
> >   
> 
> This should probably be /run/reboot-required, /var/run is a symlink
> to /run.

Yes.  See latest debian policy doc patch at:

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

> That said, an update of the systemd package does not strictly require
> a reboot of the system. We do reexec PID 1 and restart all binaries
> (besides logind), so I'm a bit undecided if we should actually trigger
> that message or not.

If systemd restarts all of its processes which are affected
by package upgrade then the only reason to require a restart would
be if some changes in new systemd packages required a restart
of non-systemd components.  So maybe this is a non-bug.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

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-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
|
|This fixes issue #7677
|
|Reviewed-by: Matt Caswell 
|(Merged from https://github.com/openssl/openssl/pull/7678)

and affects us due to
CipherString = DEFAULT@SECLEVEL=2

in openssl.cnf

Sebastian

Bug#921482: RFS: note/1.3.26-3

[Bart Martens]

About this package at mentors:

Version:1.3.26-3
Uploaded:   2019-02-16 01:38
Source package: 
https://mentors.debian.net/debian/pool/main/n/note/note_1.3.26-3.dsc

In debian/patches/fix-spelling.patch some spelling fixes got removed, I guess
accidentally. For example "aditional" and "usefull". I think you meant to keep
the existing fixes and to add more fixes.

Bug#923487: fluidsynth: new upstream 2.0.4

[Jonatan Nyberg]

package: fluidsynth
severity: normal

Please consider to upgrade to the current upstream version
(2.0.4).

Regards,
Jonatan

Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible

[Mike Gabriel]

Source: openssh
Version: 1:7.9p1-7
Severity: important
Tags: security
Control: found -1 1:7.9p1-6
Control: found -1 1:7.4p1-10+deb9u5
Control: found -1 1:6.7p1-5+deb8u7

Hi,

while working on a fixed openssh version for Debian jessie LTS regarding

  CVE-2019-6110
  CVE-2019-6111
  CVE-2018-20685

after several checks, code readings, double checking, I am pretty sure  
that CVE-2019-6111 is still not yet fixed. Neither in Debian, nor  
openssh upstream (though I haven't tested that, only from code  
readings I assume that).


What I tested this with is this piece of Python code:
https://www.exploit-db.com/exploits/46193

In fact, the sshtranger_things.py script needs a little bit of  
patching, to not throw unwanted exceptions:


```
--- sshtranger_things.py.orig   2019-02-28 21:48:41.868955825 +0100
+++ sshtranger_things.py2019-02-28 20:47:01.456096511 +0100
@@ -85,7 +85,10 @@
 return paramiko.OPEN_FAILED_ADMINISTRATIVELY_PROHIBITED

 def check_channel_exec_request(self, channel, command):
-command = command.decode('ascii')
+try:
+command = command.decode('ascii')
+except:
+pass
 logging.info('Approving exec request: %s', command)
 parts = command.split(' ')
 # Make sure that this is a request to get a file:
```

Can someone please double-check this with a second pair of eyes? I  
guess this needs to be communicated back to upstream. Can this be  
handled by the security team and/or the package maintainers?


Thanks+Greets,
Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpdLn8k2CcJM.pgp
Description: Digitale PGP-Signatur

Bug#922421: Drop special cases for updates from ancient versions (Closes: #922421)

[Pierre Ynard]

> > Could it be made a conffile?
>
> Definitely. Could you please file a seperate bug about it?

Filed as #923485

-- 
Pierre Ynard

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

[Pierre Ynard]

Package: initscripts
Version: 2.93-8
Severity: wishlist

Dear Maintainer,

/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.

Thanks,

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

Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages initscripts depends on:
ii  coreutils   8.30-1
ii  debianutils 4.8.6.1
ii  lsb-base10.2018112800
ii  mount   2.33.1-0.1
ii  sysv-rc 2.93-8
ii  sysvinit-utils  2.93-8

Versions of packages initscripts recommends:
ii  e2fsprogs  1.44.5-1
ii  psmisc 23.2-1

initscripts suggests no packages.

-- Configuration Files:
/etc/default/rcS changed [not included]
/etc/default/tmpfs changed [not included]

-- no debconf information

Bug#922769: yubikey-luks: Cant use yubikey with luks. Yubikey ignored

[Markus Frosch]

Control: tags -1 + moreinfo

Am 20.02.19 um 14:09 schrieb GP:
> I encrypted my hard disk and tried to add another slot for unlocking the hard
> disk with another password and yubikey (challenge response)
> 
> The commands i entered
> 
> sudo ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 
> -oserial-api-
> visible
> sudo /usr/bin/yubikey-luks-enroll -d /dev/nvme0n1p3 -s 7
> sudo reboot
> 
>* What was the outcome of this action?
> 
> The yubikey is ignored at boot up. I dont get any messages on unlocking the
> disk with the use of yubikey.
> I can only unlock my hard disk with the original password with or without the
> yubikey inserted at usb slot.
> 
>* What outcome did you expect instead?
> 
> I should be ask to enter the original password or the password needed with
> yubikey. I should insert the yubikey and the password and decrypt my hard 
> disk.

Thanks for your report.

Have you actually changed your /etc/crypttab to use yubikey to unlock?
It is no longer enabled by default.

Please see:
/usr/share/doc/yubikey-luks/README.md
/usr/share/doc/yubikey-luks/NEWS.Debian.gz

Cheers
Markus Frosch
-- 
mar...@lazyfrosch.de / lazyfro...@debian.org
https://lazyfrosch.de



signature.asc
Description: OpenPGP digital signature

Bug#923443: u-boot-sunxi: build support for bananapi_m2_berry

[Lucas Nussbaum]

On 28/02/19 at 11:26 -0800, Vagrant Cascadian wrote:
> On 2019-02-28, Lucas Nussbaum wrote:
> > I'm trying to install Debian on a Banana Pi M2 Berry.
> >
> > Upstream U-boot has support for the board, but the support is not built
> > in the Debian package. I confirm that adding
> > armhf   sunxi   bananapi_m2_berry u-boot-sunxi-with-spl.bin
> > to debian/targets
> > is enough to get a u-boot-sunxi-with-spl.bin that works on the board.
> 
> Would you be willing to be listed as a tester for the board? I
> periodically ping people asking for tests, and ideally people log their
> tested versions at:
> 
>   https://wiki.debian.org/U-boot/Status
> 
> There are not infrequent regressions that are board-specific, and I
> can't test what I don't have, and like to have people be proactive about
> finding board-specific bugs...
> 
> More information at:
> 
>   https://wiki.debian.org/U-boot/
> 
> So, if you're available to test it, I can add it! (maybe even early
> enough to get it into buster, if my timing is *perfect*)
> 
> Then we can also add entries for debian-installer and flash-kernel if
> needed...

Hi,

I think I can try! Even if I don't have much experience about such
boards.

Lucas


signature.asc
Description: PGP signature

Bug#923480: ftp.debian.org: cleanup old installer versions from sid

[Cyril Brulebois]

Hi,

Julien Cristau  (2019-02-28):
> I noticed there's a bunch of d-i versions in the archive for sid:
> 
> 20160101
> 20160106
> 20160516
> 20160516+b1
> 20160630
> 20161027
> 20161031
> 20170112
> 20170127
> 20170407
> 20170525
> 20170608
> 20170615
> 20170828
> 20171204
> 20180610
> 20181206
> 20190118
> 
> I would say all but the last one should go.  Maybe keeping the 2018 ones
> if you want to be conservative, but even that I'm not sure is useful.

I think I gave a green light long ago to perform some clean up; right
now, it would be good to keep the 2018 ones.


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


signature.asc
Description: PGP signature

Bug#921824: terminator: Impossible to load a layout on startup after upgrading to 1.91-3

[Markus Frosch]

On Sat, 9 Feb 2019 12:06:55 +0100 phep  wrote:
> I managed to fix this with the patch below but this probably not the best 
> way to do it. Besides, this might be the sign that the code base should be 
> checked up more thoroughly before to depend on python3.

Hey Patrice,
thank you so much for testing and suggesting a patch.

I partially adopted your patch and will add it to the next upload.

If you noticed something else with the current packages please report it ;)

Cheers
Markus Frosch
-- 
mar...@lazyfrosch.de / lazyfro...@debian.org
https://lazyfrosch.de



signature.asc
Description: OpenPGP digital signature

Bug#923442: octave: FTBFS (/bin/sed: can't read libinterp/parse-tree/oct-parse.cc-t: No such file or directory)

[Mike Miller]

On Thu, Feb 28, 2019 at 20:10:46 +0100, Sébastien Villemot wrote:
> If you don't have the time to do the upload today, I will do it
> tomorrow.
> 
> Note that you'll have to create a new git branch, named "buster",
> branching off at 4.4.1-4, since master already contains 5.1.0.

I've done exactly that, successfully tested in sbuild locally. Please
tag and upload when you get a chance.

-- 
mike


signature.asc
Description: PGP signature

Bug#923484: sbuild: Fix Build-Space tag to report used Disc Space

[Helge Deller]

Package: sbuild
Version: 0.78.1-1
Severity: normal
Tags: patch

sbuild fails to report used "Disc space" when building debian packages.
This can be seen for various architecturs which are already using this
sbuild version for their buildds. Here are examples for m68, ppc64 and
hppa:
https://buildd.debian.org/status/logs.php?pkg=globus-net-manager=m68k
https://buildd.debian.org/status/logs.php?pkg=globus-net-manager=ppc64

For hppa arch I've applied the patch below, and with that change sbuild
will now report the size in the "Build-Space:" tag of the build log:
https://buildd.debian.org/status/logs.php?pkg=globus-net-manager=hppa

Can you apply the patch below (or a correct variant of it) to the next
sbuild uploads?
I'm happy to test any other patch as well.

Thanks,
Helge


diff -up /usr/share/perl5/Sbuild/Build.pm.org /usr/share/perl5/Sbuild/Build.pm
--- /usr/share/perl5/Sbuild/Build.pm.org2019-02-28 21:00:01.033696326 
+0100
+++ /usr/share/perl5/Sbuild/Build.pm2019-02-28 21:01:11.885230625 +0100
@@ -2783,7 +2783,7 @@ sub check_space {
 # the required space.
 unless( defined $dscdir && -d $dscdir)
 {
-   return -1;
+   # DO NOT: return -1;
 }
 
 

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

[Vincent Blut]

Control: tags -1 - moreinfo
Control: found -1 3.0-4+deb9u1

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

On Wed, 27 Feb 2019 14:05:03 +0100 Vincent Blut wrote:

[...]

On Mon, Feb 25, 2019 at 10:07:28PM +0100, Francesco Poli wrote:

[...]

>Nothing is added to /var/log/messages when chrony fails to start.

Ok so I think I can reproduce this issue on a Debian Buster i386 virtual
machine. However, to double check that I’m facing the same issue as
yours, I’d like you to:

- stop the chronyd daemon
# service chrony stop

- install strace
# apt install strace

- use the log directive in chrony.conf (“log measurements” alone
  suffices to trigger the issue)

- execute strace on chronyd
# strace -o chronyd_debug.txt chronyd -d -F -1

- don’t forget to attach the chronyd_debug.txt file when you answer ;-)


 # strace -o /tmp/chronyd_debug.txt chronyd -d -F -1
 2019-02-27T21:11:34Z chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC 
+PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
 2019-02-27T21:11:34Z Frequency -63.045 +/- 0.023 ppm read from 
/var/lib/chrony/chrony.drift
 2019-02-27T21:11:34Z Loaded seccomp filter
 Bad system call

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.



Thanks for yout time,


Thanks to you, for your helpfulness and patience!


You’re welcome!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#923483: flash-kernel: db entry for Banana Pi M2 Berry

[Lucas Nussbaum]

Package: flash-kernel
Version: 3.97
Severity: wishlist

Hi,

I'm trying to run Debian on a Banana Pi M2 Berry. Here is a DB entry,
confirmed to work:

Machine: Banana Pi M2 Berry
Kernel-Flavors: armmp armmp-lpae
Boot-Script-Path: /boot/boot.scr
DTB-Id: sun8i-v40-bananapi-m2-berry.dtb
U-Boot-Script-Name: bootscr.sunxi
Required-Packages: u-boot-tools

Thanks

Lucas

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

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

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.61
pn  devio  
ii  initramfs-tools0.130
ii  linux-base 4.5
pn  mtd-utils  
ii  ucf3.0036

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2016.11+dfsg1-4

flash-kernel suggests no packages.

Bug#918368: do not parse apt output (was Re: [Git][pbuilder-team/pbuilder][master] 2 commits: buildpackage-funcs: change source of the default gcc.)

[Thorsten Glaser]

Mattia Rizzolo dixit:

>buildpackage-funcs: change source of the default gcc.
>
>Thanks to Helmut for the suggestion.

This breaks:

# apt-cache show gcc | sed 's/^Depends: .*gcc-\([0-9]\+\) .*/\1/;t;d'
8
6

Don’t do that. Or, at least, ensure you only catch the installed
version; the tool for that is dpkg.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

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

[Jim Popovitch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: dirmngr
Version: 2.1.18-8~deb9u4

When a client uses HKPS keyservers dirmngr fails hard due to TLS
certificate validation errors:

2019-02-28 14:35:17 dirmngr[2155] listening on socket
'/run/user/1000/gnupg/S.dirmngr'
2019-02-28 14:35:17 dirmngr[2156.0] permanently loaded certificates: 0
2019-02-28 14:35:17 dirmngr[2156.0] runtime cached certificates: 0
2019-02-28 14:35:18 dirmngr[2156.6] handler for fd 6 started
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 -> # Home:
/home/jimpop/.gnupg
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 -> # Config:
/home/jimpop/.gnupg/dirmngr.conf
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 -> OK Dirmngr 2.1.18 at
your service
2019-02-28 14:35:18 dirmngr[2156.6] connection from process 2153
(1000:1000)
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 <- GETINFO version
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 -> D 2.1.18
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 -> OK
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 <- KEYSERVER --clear
hkps://ha.pool.sks-keyservers.net
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 -> OK
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 <- KEYSERVER
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 -> S KEYSERVER
hkps://ha.pool.sks-keyservers.net
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 -> OK
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 <- KEYSERVER --clear
hkps://ha.pool.sks-keyservers.net
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 -> OK
2019-02-28 14:35:18 dirmngr[2156.6] DBG: chan_6 <- KS_GET --quick --
0xF4B8B79CC372FBE38580F4C241EED2521FD6B2CA
2019-02-28 14:35:19 dirmngr[2156.6] resolve_dns_addr for 'ha.pool.sks-
keyservers.net': '192.146.137.99'
2019-02-28 14:35:19 dirmngr[2156.6] resolve_dns_addr for 'ha.pool.sks-
keyservers.net': '192.146.137.98'
2019-02-28 14:35:19 dirmngr[2156.6] resolve_dns_addr for 'ha.pool.sks-
keyservers.net': '178.32.66.144'
2019-02-28 14:35:19 dirmngr[2156.6] resolve_dns_addr for 'ha.pool.sks-
keyservers.net': '46.4.246.179'
2019-02-28 14:35:19 dirmngr[2156.6] resolve_dns_addr for 'ha.pool.sks-
keyservers.net': '37.191.231.105'
2019-02-28 14:35:19 dirmngr[2156.6] number of system provided CAs: 151
2019-02-28 14:35:20 dirmngr[2156.6] TLS verification of peer failed:
hostname does not match
2019-02-28 14:35:20 dirmngr[2156.6] DBG: expected hostname:
ha.pool.sks-keyservers.net
2019-02-28 14:35:20 dirmngr[2156.6] DBG: BEGIN Certificate 'server[0]':
2019-02-28 14:35:20 dirmngr[2156.6] DBG:  serial:
031DA3EEAFB1931E9D70695C4F75EB13B412
2019-02-28 14:35:20 dirmngr[2156.6] DBG:   notBefore: 2019-01-06
14:13:25
2019-02-28 14:35:20 dirmngr[2156.6] DBG:notAfter: 2019-04-06
14:13:25
2019-02-28 14:35:20 dirmngr[2156.6] DBG:  issuer: CN=Let's Encrypt
Authority X3,O=Let's Encrypt,C=US
2019-02-28 14:35:20 dirmngr[2156.6] DBG: subject: CN=sks.mj2.uk
2019-02-28 14:35:20 dirmngr[2156.6] DBG: aka: (8:dns-
name10:sks.mj2.uk)
2019-02-28 14:35:20 dirmngr[2156.6] DBG:   hash algo:
1.2.840.113549.1.1.11
2019-02-28 14:35:20 dirmngr[2156.6] DBG:   SHA1 fingerprint:
E9AF92BDFE5ACBEC36630FA51ABCBF18B7E42E7A
2019-02-28 14:35:20 dirmngr[2156.6] DBG: END Certificate
2019-02-28 14:35:20 dirmngr[2156.6] DBG: BEGIN Certificate 'server[1]':
2019-02-28 14:35:20 dirmngr[2156.6] DBG:  serial:
0A014142015385736A0B85ECA708
2019-02-28 14:35:20 dirmngr[2156.6] DBG:   notBefore: 2016-03-17
16:40:46
2019-02-28 14:35:20 dirmngr[2156.6] DBG:notAfter: 2021-03-17
16:40:46
2019-02-28 14:35:20 dirmngr[2156.6] DBG:  issuer: CN=DST Root CA
X3,O=Digital Signature Trust Co.
2019-02-28 14:35:20 dirmngr[2156.6] DBG: subject: CN=Let's Encrypt
Authority X3,O=Let's Encrypt,C=US
2019-02-28 14:35:20 dirmngr[2156.6] DBG:   hash algo:
1.2.840.113549.1.1.11
2019-02-28 14:35:20 dirmngr[2156.6] DBG:   SHA1 fingerprint:
E6A3B45B062D509B3382282D196EFE97D5956CCB
2019-02-28 14:35:20 dirmngr[2156.6] DBG: END Certificate
2019-02-28 14:35:20 dirmngr[2156.6] TLS connection authentication
failed: General error
2019-02-28 14:35:20 dirmngr[2156.6] error connecting to 'https://178.32
.66.144:443': General error
2019-02-28 14:35:20 dirmngr[2156.6] command 'KS_GET' failed: General
error 

There's multiple ways to resolve this (use HPK instead of HPKS, etc),
but the best way is for *.pool.sks-keyservers.net to fix their TLS
certificates.


Debian/Stretch
Linux host  4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19)
x86_64GNU/Linux
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEECPbAhaBWEfiXj/kxdRlcPb+1fkUFAlx4O6sACgkQdRlcPb+1
fkUrhQ/9Ge7cJXAUdYoINVszlrOFG1ePZoCIhU4LFnAUjRCsm/WojaQMHH3MJcv3
dKLWEsrXIQ0m5tXWmN3lUP5izsrsaMDFVTmP8nFogYhW8KL+wIaQRnpV2UFpArKV
45j59lirx6T0Iyf2kkCGgENFErbcVdVFuZ65Maph81Wkjqn/Ezb1uCNlXcpqDsE7
Gvnq569YlCM0dMR7pi+uiO+NJtP/mOWQfTYbgS1/C/hQW57is/zrE4Dz5EqJhp5U
xaULhIIMDnAygMSLTUjeCVKwF04O0X1Y1rmx2wReq1MJ3B6tc3tCniuSMSDZAHHK
Sj3+Ug49sfpzRNHHAgHEPeBD38bdARu1JUwttJWPpEPnpMmSEKLN0QULJODM/QQu

Bug#923427: mergechanges: Regression: --indep/source breaks multi-line Binary fields

[Simon McVittie]

Control: retitle -1 mergechanges: Regression: --indep/source breaks multi-line 
Binary fields
Control: forwarded -1 
https://salsa.debian.org/debian/devscripts/merge_requests/112
Control: tags -1 + patch

On Thu, 28 Feb 2019 at 17:59:25 +, Simon McVittie wrote:
> I'll try to put together some sort of parsing fix in shell for buster

Try this:
https://salsa.debian.org/debian/devscripts/merge_requests/112

I've added Salvatore's changes file unmodified as a test-case, since it
has a couple of interesting corner cases for the parser.

To make mergechanges accept that changes file, I also had to make it more
tolerant of packages that are in Files but not Binary, which apparently
happens in stretch kernels? (Again, I didn't know this was even possible.)

Regards,
smcv

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Michael Shuler]

What version of the openssl package is installed?

This does sound like a potential issue with `openssl rehash`. Your
workaround looks OK for the moment, but the problem is that the openssl
devs would like to remove the deprecated `c_rehash` utility. At this
point in the release cycle, it's possible c_rehash may stick around for
Buster, but no guarantees from me on that one - that's up to the openssl
folks.

-- 
Kind regards,
Michael

Bug#923481: alpine: replies lose In-Reply-To and References headers

[Thorsten Glaser]

Package: alpine
Version: 2.21+dfsg1-1.1
Severity: serious

If I take a message, reply to it, then go to the Subject line,
press ^K to remove the existing (possibly damaged) text and type
new text (possibly to change the subthread subject), the eMail
gets sent out AND Fcc’d without both In-Reply-To and References
headers, completely and utterly breaking threading.

This is a major regression relative to pine 4.64 which does emit
these headers in that exact case (as just checked by me).

-- 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 alpine depends on:
ii  libc6 2.28-7
ii  libgssapi-krb5-2  1.17-2
ii  libkrb5-3 1.17-2
ii  libldap-2.4-2 2.4.47+dfsg-3
ii  libpam0g  1.3.1-5
ii  libssl1.1 1.1.1b-1
ii  libtinfo6 6.1+20181013-2
ii  mlock 8:2007f~dfsg-6

Versions of packages alpine recommends:
pn  alpine-doc  

Versions of packages alpine suggests:
ii  aspell  0.60.7~20110707-6
ii  postfix [mail-transport-agent]  3.3.2-4

-- no debconf information

Bug#923476: webkit2gtk: FTBFS for unknown reasons (maybe Makefile bug)

[Alberto Garcia]

On Thu, Feb 28, 2019 at 05:19:40PM +, Santiago Vila wrote:
> make[3]: *** No rule to make target 'JavaScriptCore-4.0.gir', needed by 
> 'WebKit2-4.0.gir'.  Stop.

I think I've come across this error a couple of times, does it go away
if you try to rebuild?

We are considering to use --buildsystem=cmake+ninja for the build,
perhaps that solves this problem (I haven't tried it yet).

> In either case, I've put a bunch of failed build logs here for you to see:
> 
> https://people.debian.org/~sanvila/build-logs/webkit2gtk/

Thanks. Does it fail all the time then?

Berto

Bug#734423: initscripts: typos in /etc/network/if-up.d/mountnfs

[Pierre Ynard]

tags 734423 patch
thanks

Attaching patch

-- 
Pierre Ynard
From 3c6577c04166fa90b7aae9b914dc5a69b2a0042d Mon Sep 17 00:00:00 2001
From: Pierre Ynard 
Date: Thu, 28 Feb 2019 12:13:51 +0100
Subject: [PATCH] Fix typos in comments in /etc/network/if-up.d/mountnfs
 (Closes: #734423)

---
 debian/src/initscripts/etc/network/if-up.d/mountnfs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/src/initscripts/etc/network/if-up.d/mountnfs b/debian/src/initscripts/etc/network/if-up.d/mountnfs
index 267c32f..cceed59 100644
--- a/debian/src/initscripts/etc/network/if-up.d/mountnfs
+++ b/debian/src/initscripts/etc/network/if-up.d/mountnfs
@@ -145,7 +145,7 @@ exit_unless_last_interface() {
 # Using 'no !=' instead of 'yes =' to make sure async nfs mounting is
 # the default even without a value in /etc/default/rcS
 set_env
-# Exit imediately and do not claim to wait for the last interface if
+# Exit immediately and do not claim to wait for the last interface if
 # no network file systems are listed in /etc/fstab.
 if [ "$start_nfs" = "no" ] && [ ! "$NETFS" ] && [ ! "$NETDEV" ]; then
   exit 0
@@ -160,7 +160,7 @@ if [ no != "$ASYNCMOUNTNFS" ]; then
 # Lock around this otherwise insanity may occur
 mkdir /var/run/network  2>/dev/null || true
 
-# Wait until all auto interfaces are up before attemting to mount
+# Wait until all auto interfaces are up before attempting to mount
 # network file systems.
 exit_unless_last_interface
 
-- 
2.1.4

Bug#921131: taking over yum-utils

[Holger Levsen]

Hi Markus!

On Thu, Feb 28, 2019 at 08:27:11PM +0100, Markus Frosch wrote:
> thanks I just did so, and uploaded a new version.

yay, very cool!

> During testing I noticed the "refactoring" patch actually broke logging,
> and therefor reposync working.

ouch, sorry.

> I fixed it with an additional patch:
> https://salsa.debian.org/pkg-rpm-team/yum-utils/commit/0c946a3b072b921a96d1b47a9653367db74d5cf0

thanks!

> Upstream has applied more refactoring, I will rebase our patches at a
> later point, for now it should work.

*nods*


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#921131: taking over yum-utils

[Markus Frosch]

Am 22.02.19 um 10:26 schrieb Holger Levsen:
> please adopt yum-utils and get the changes from experiemental into
> sid/buster before the freeze is fully in effect. You still have almost a
> week to do that! ;)
> 
> Also if you do that, please dont forget to include the changes from my
> NMU.
> 
> If you need any help or advice, please shout!

Hey Holger,
thanks I just did so, and uploaded a new version.

During testing I noticed the "refactoring" patch actually broke logging,
and therefor reposync working.

I fixed it with an additional patch:
https://salsa.debian.org/pkg-rpm-team/yum-utils/commit/0c946a3b072b921a96d1b47a9653367db74d5cf0

Upstream has applied more refactoring, I will rebase our patches at a
later point, for now it should work.

Cheers
Markus Frosch
-- 
mar...@lazyfrosch.de / lazyfro...@debian.org
https://lazyfrosch.de



signature.asc
Description: OpenPGP digital signature

Bug#923443: u-boot-sunxi: build support for bananapi_m2_berry

[Vagrant Cascadian]

On 2019-02-28, Lucas Nussbaum wrote:
> I'm trying to install Debian on a Banana Pi M2 Berry.
>
> Upstream U-boot has support for the board, but the support is not built
> in the Debian package. I confirm that adding
> armhf   sunxi   bananapi_m2_berry u-boot-sunxi-with-spl.bin
> to debian/targets
> is enough to get a u-boot-sunxi-with-spl.bin that works on the board.

Would you be willing to be listed as a tester for the board? I
periodically ping people asking for tests, and ideally people log their
tested versions at:

  https://wiki.debian.org/U-boot/Status

There are not infrequent regressions that are board-specific, and I
can't test what I don't have, and like to have people be proactive about
finding board-specific bugs...

More information at:

  https://wiki.debian.org/U-boot/

So, if you're available to test it, I can add it! (maybe even early
enough to get it into buster, if my timing is *perfect*)

Then we can also add entries for debian-installer and flash-kernel if
needed...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#908879: pyparted: FTBFS randomly (ImportError: No module named _ped)

[Herbert Fortes]

fixed 908879 3.11.2-3
thanks

I am fixing what I did. It is registered that a fix was done by
skipping (empty override) the tests.

The fix for 'No module named _ped' was in version 3.11.2-3 when
a patch[0] from Steve Langasek added the deps to build the _ped 
module. Here is the debian/changelog[1]:

[0] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922081
[1] - https://tracker.debian.org/media/packages/p/pyparted/changelog-3.11.2-10

In version 3.11.2-4 I tried to run tests for py3 only but forgot to
fix the search ('find') for the specific file ('*gnu.so'). Because of 
that this[2] happened multiple times:

File "/usr/lib/python3.7/unittest/loader.py", line 436, in _find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python3.7/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File "/<>/tests/test__ped_alignment.py", line 22, in 
import _ped
ImportError: /<>/.pybuild/cpython2_2.7_parted/build/_ped.so: 
undefined symbol: _Py_ZeroStruct

[2] - 
https://buildd.debian.org/status/fetch.php?pkg=pyparted=ia64=3.11.2-5=1550014323=0


I removed the wrong override in version 3.11.2-7. debhelper does a better
job doing a 'cd build dir'; 'pyX unittest discover'.

The problem now seems to be mainly in armhf (unitl now). There is a 
'Floating point exception'[3]:

[...]
runTest (tests.test_parted_disk.DiskUnsetFlagTestCase) ... ok

--
Ran 273 tests in 1.568s

OK (skipped=118)

/bin/sh: line 1: 26652 Floating point exceptionpython2.7 -m unittest discover -v

[3] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/pyparted.html


obs:
./src/parted/device.py:264:return long(math.floor((float(sector) / 
(heads * sectors)) + 1))
./src/parted/device.py:271:return long(math.ceil(float((sector + 1)) / 
(heads * sectors)))
./src/parted/device.py:299:size = float(self.__device.length)

src/pytimer.c has float() - 222, 298

https://docs.python.org/2/library/decimal.html?highlight=floating



Regards,
Herbert

Bug#686531: checkroot-bootclean.sh fails if rootfs is mounted read-only via NFS

[Pierre Ynard]

tags 686531 patch
thanks

Attaching patch to fix this

-- 
Pierre Ynard
From 9f5efa15466ca52ca34f458e66ef153f7512059a Mon Sep 17 00:00:00 2001
From: Pierre Ynard 
Date: Thu, 28 Feb 2019 19:51:26 +0100
Subject: [PATCH] Skip bootclean.sh on read-only directories (Closes: #686531)

---
 debian/src/initscripts/lib/init/bootclean.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/src/initscripts/lib/init/bootclean.sh b/debian/src/initscripts/lib/init/bootclean.sh
index 03a593e..08096a4 100644
--- a/debian/src/initscripts/lib/init/bootclean.sh
+++ b/debian/src/initscripts/lib/init/bootclean.sh
@@ -60,6 +60,8 @@ clean_tmp() {
 
 	# Does not exist
 	[ -d /tmp ] || return 1
+	# Read-only filesystem?
+	[ -w /tmp ] || return 0
 	# tmpfs does not require cleaning
 	[ -f /tmp/.tmpfs ] && return 0
 	# Can clean?
@@ -152,6 +154,8 @@ clean() {
 
 	# Does not exist
 	[ -d "$dir" ] || return 1
+	# Read-only filesystem?
+	[ -w "$dir" ] || return 0
 	# tmpfs does not require cleaning
 	[ -f "$dir/.tmpfs" ] && return 0
 	# Can clean?
-- 
2.1.4

Bug#923480: ftp.debian.org: cleanup old installer versions from sid

[Julien Cristau]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: jcris...@debian.org, k...@debian.org

Hi,

I noticed there's a bunch of d-i versions in the archive for sid:

20160101
20160106
20160516
20160516+b1
20160630
20161027
20161031
20170112
20170127
20170407
20170525
20170608
20170615
20170828
20171204
20180610
20181206
20190118

I would say all but the last one should go.  Maybe keeping the 2018 ones
if you want to be conservative, but even that I'm not sure is useful.

Cheers,
Julien

Bug#923442: octave: FTBFS (/bin/sed: can't read libinterp/parse-tree/oct-parse.cc-t: No such file or directory)

[Sébastien Villemot]

Le jeudi 28 février 2019 à 09:53 -0800, Mike Miller a écrit :
> Control: tags -1 + patch
> 
> On Thu, Feb 28, 2019 at 10:08:33 +, Santiago Vila wrote:
> > I tried to build this package in buster but it failed:
> 
> […]
> > /bin/sed: can't read libinterp/corefcn/oct-tex-parser.cc-t: No such
> > file or directory
> 
> Confirmed separately in upstream Octave development, this is caused
> by
> the recent upload of bison 3.3 to unstable/buster.
> 
> Octave 4.4 needs this patch to work with bison 3.3
> 
>   https://hg.savannah.gnu.org/hgweb/octave/rev/df42ea23502f
> 
> I'll try building that a bit later today and push the fix if it works
> for me.

Thanks for pointing to the relevant upstream commit.

If you don't have the time to do the upload today, I will do it
tomorrow.

Note that you'll have to create a new git branch, named "buster",
branching off at 4.4.1-4, since master already contains 5.1.0.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


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

Bug#923454: renderdoc: FTBFS (error: braces around scalar initializer for type 'int')

[Andrey Rahmatullin]

The problem here is the API compatibility break in glslang, described in
https://github.com/KhronosGroup/glslang/issues/1538#issuecomment-431643795
Changes related to the new glslang version seem to be bundled in
https://github.com/baldurk/renderdoc/commit/2ea6174c83c3c55f504c107303991d9bb2aa9af3
(I see 3 source files changed there).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#919344: adequate reports obsolete-conffile in openssh-client

[Colin Watson]

On Tue, Feb 26, 2019 at 11:57:00PM +0100, Dominik George wrote:
> How about the attached approach?
> 
> It uses dpkg-maintscript-helper in openssh-client to remove the
> conffile. dpkg-maintscript=helper does all the magic to determine
> whether the file was changed by the user. Here, we use the fact that in
> preinst, it only moves the file to a backup location, and this location
> is different when the file is user-modified.
> 
> In postinst of openssh-server, we then check for the backup file and
> move it back in place if it exists. This…
> 
>  …fixes the obsolete conffile,
>  …avoids an annoying question on upgrade whether to overwrite the file,
>   is it was user-modified,
>  …still keeps user modifications intact.
> 
> I tested the following:
[...]

Ah, clever.  Thanks!  I also tested this, including upgrades through
intermediate versions, and it works correctly in every scenario I can
come up with.

Normally the openssh-server postinst code in fact does nothing because
apt currently seems to unpack the new openssh-server before the new
openssh-client and so by the time dpkg-maintscript-helper runs from
openssh-client.preinst the file has already been taken over by
openssh-server; but even if I perform the unpack and configure
operations manually using dpkg such that openssh-client.preinst runs
before the new openssh-server is unpacked, your code still works.

I fleshed out the comment a bit, and committed this in your name.  I'll
upload it soon along with other pending changes.

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

Bug#919259: systemd: (Security?) update breaks systemd (inside unprivileged container?)

[Michael Biebl]

Control: reassign -1 lxc

On Wed, 16 Jan 2019 09:52:47 +0100 Matthijs Kooijman 
wrote:
> severity 919259 normal
> found 919259 232-25
> retitle 919259 Reexecuting fails in containers without CAP_SYS_ADMIN
> thanks
> 
> Hey Michael,
> 
> > My suggestion would be to roll back to 232-25+deb9u1 and then gradually
> > upgrading to deb9u2, deb9u2 ... deb9u3
> Yeah, that was my intention. I discovered some interesting things.
> 
>  - On my host system, systemd is now also upgraded without problems.
>  - Restarting a container works just fine, even with deb9u8. However,
>the problem occurs when re-execing (e.g. systemctl daemon-reexec).
>  - Downgrading to deb9u1 and re-execing also breaks, so this is not
>broken by the upgrade that happened this week.
>  - Looking in the logs, I found that the last time re-exec happened
>(succesfully) was on 2017-09-12. It seems that was from a manual
>upgrade, so I am not sure what version that was exactly. From old
>unattended upgrade e-mails, I *suspect* it was deb9u1.
>  - Looking through my config git history, I did not find any seemingly
>relevant changes in the lxc config since 2017. However, I think I did
>upgrade from jessie to stretch since then (or maybe just before then,
>but I probably didn't restart the containers and/or system until
>later).
>  - For good measure, I also tested the original 232-25 version, which
>also breaks.
>  - When I remove `lxc.cap.drop = sys_admin` from the lxc config, reexec
>works fine again.
> 
> So it seems that *some* lxc upgrade since 2017 broke this. What is
> broken is re-execing systemd inside a container running without
> CAP_SYS_ADMIN.
> 
> I'm not sure if this means this bug should be against lxc instead, but
> until we know more, I guess keeping it against systemd would be good.
> 
> Since booting still works (and this issue can be worked around be
> rebooting the container), I'd say this issue can be downgraded
> from important to normal. I've went ahead and did this, feel free to
> revert if you feel otherwise.
> 
> Going forward, I guess it would be good to investigate why the re-exec
> fails, based on the error messages shown:
> 
>   systemd[1]: Failed to create /../../init.scope control group: Operation not 
> permitted
>   systemd[1]: Failed to allocate manager object: Operation not permitted
> 
> One interesting question is also why the initial startup does *not* fail, but
> the re-exec does.
> 
> I'm out of time again for now. I'll have a closer look at what this init.scope
> control group is exactly and how systemd handles it on normal startup. Any
> additional thoughts are welcome :-)


I'm going to re-assign this to lxc, simply because they know more about
lxc then myself. I have no idea how well supported unprivileged
containers are in stretch. Maybe this is just a configuration issue.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[James Pooton]

Package: ca-certificates
Version: 20190110

This is a little fringe and likely crosses projects, as it seems to be specific 
to QEMU emulating 32bit ARM, and may involve the “openssl rehash” function from 
openssl. But it did appear as a result of the 20190110 ca-certificates update, 
and affects anything (like CURL) that depend on the CA cert hashes created by 
via update-ca-certificates, so I’ll start by posting here.  

Basically changes in ca-certificates 20190110 seem to have broken our 32 bit 
ARM Buster Docker image builds (which are done with QEMU).  Essentially, 
installing ca-certificates in the image (which triggers 
update-ca-certificates), fails to create the hashes used by programs like CURL, 
resulting in failure of any subsequent CURL calls.  Running the previously used 
c_rehash command (manually) however, does create the hashes.

For example the following fails running under Docker for Mac/Windows (which has 
QEMU baked in) or Docker Linux x86 with QEMU added, but is successful when run 
on 32bit ARM Docker Linux directly:

docker run -it --rm arm32v7/debian:buster  \
  /bin/bash -c \
'export DEBIAN_FRONTEND=noninteractive && \
apt-get update &&  apt-get install -y ca-certificates curl && \
curl -sSL https://www.google.com'

QEMU Docker hosts fail with:

….
Setting up ca-certificates (20190110) ...
Updating certificates in /etc/ssl/certs...
qemu: Unsupported syscall: 382
128 added, 0 removed; done.
Setting up libkrb5support0:armhf (1.17-1) ...
Setting up libk5crypto3:armhf (1.17-1) ...
Setting up libkrb5-3:armhf (1.17-1) ...
Setting up libgssapi-krb5-2:armhf (1.17-1) ...
Setting up libcurl4:armhf (7.64.0-1) ...
Setting up curl (7.64.0-1) ...
Processing triggers for libc-bin (2.28-5) ...
Processing triggers for ca-certificates (20190110) ...
Updating certificates in /etc/ssl/certs...
qemu: Unsupported syscall: 382
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.


However, adding the previously used c_rehash function does create the hashes 
and is successful for QEMU Docker hosts:

docker run -it --rm arm32v7/debian:buster  \
  /bin/bash -c \
'export DEBIAN_FRONTEN=noninteractive && \
apt-get update &&  apt-get install -y ca-certificates curl && \
c_rehash &&  \
curl -sSL https://www.google.com'

We’re using that work-around for 32-bit ARM image builds currently, but just a 
heads up that something seems to have changed that affects the hash creation 
under QEMU for ARM 32-bit.  It was working prior to the 20190110 update.

-James

Bug#923478: initscripts use unsafe `: >` shell command to create files

[Thorsten Glaser]

Hi Pierre,

I’d say that aborting might be preferrable, but I checked your patch.

In the first case, it’s indeed preferrable to continue the init script
(and have the two additional error messages from chmod and chgrp, but
it continue on), and in the second case…

>Init scripts try to use this for example in the bootclean.sh logic to
>create /tmp/.clean: there is even code to handle the failure case which
>unfortunately does not get run, in fact the whole cleanup operation is
>ended short.

… this is true: the error handling does not get run.

So (from a shell maintainer’s PoV) these patches are good and should
be applied, in time for buster.

Thanks,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Bug#920035: Logs in /run/log/journal not readable by group adm

[Michael Biebl]

Hi dato,

On Mon, 21 Jan 2019 16:34:43 -0300 Dato  wrote:

> $ sudo ls -ld /run/log/journal{,/ef...}
> drwxr-xr-x 3 root root 60 Jan 21 16:24 /run/log/journal
> drwxr-x--- 2 root root 60 Jan 21 16:24 /run/log/journal/ef...
> 
> It would be great to see group ownership and ACLs fixed for 
> /run/log/journal, so that this works again.

If you can still reproduce this issue (with 241-1), would you mind
filing this upstream at https://github.com/systemd/systemd/issues ?

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



signature.asc
Description: OpenPGP digital signature

Bug#923466: lammps: FTBFS (dh_auto_configure fails)

[Andrey Rahmatullin]

The actual error message is
"""
CMake Error at CMakeLists.txt:298 (message):
  MPIIO package needs LAMMPS to be build with MPI
Call Stack (most recent call first):
  CMakeLists.txt:304 (pkg_depends)
"""

It seems to mean MPI is not found. After removing QUIET from
find_package(MPI):

-- Found MPI_C: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so (found version 
"3.1")
-- Found MPI_CXX: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so (found 
version "3.1")
-- Could NOT find MPI_Fortran (missing: MPI_Fortran_WORKS)
-- Could NOT find MPI (missing: MPI_Fortran_FOUND) (found version "3.1")
CMake Error at CMakeLists.txt:298 (message):
  MPIIO package needs LAMMPS to be build with MPI
Call Stack (most recent call first):
  CMakeLists.txt:304 (pkg_depends)

The package B-D on fortran-compiler. The package is virtual, and we see
here why is that considered a problem to B-D on a virtual package.
Previously gfortran was installed during the build, now flang07 is
installed. Yet mpif90 says "The Open MPI wrapper compiler was unable to
find the specified compiler gfortran in your PATH." Install gfortran fixes
this problem.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#919509: systemd packaging does not touch /var/run/reboot-required

[Michael Biebl]

Control: severity -1 wishlist

On Wed, 16 Jan 2019 12:44:28 -0600 "Karl O. Pinc"  wrote:
> Package: systemd
> Version: 232-25+deb9u8
> Severity: normal
> 
> Hi,
> 
> systemd security updates to stable
> systemd (232-25+deb9u8) stretch-security; urgency=high
> systemd (232-25+deb9u7) stretch-security; urgency=high
> required reboot to take effect, but /var/run/reboot-required
> was not `touch`ed.  Therefore the unattended-upgrades
> package did not notify the user that a reboot is required.
> (There were related upgrades to udev and other packages.)
> 
> There are probably many systems which installed the
> upgrade automatically but did not reboot and so the
> patch did not take effect.
> 
> "The Internet" says that it is the postinst script which
> should touch /var/run/reboot-required.
> 

This should probably be /run/reboot-required, /var/run is a symlink to /run.

That said, an update of the systemd package does not strictly require a
reboot of the system. We do reexec PID 1 and restart all binaries
(besides logind), so I'm a bit undecided if we should actually trigger
that message or not.

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