Bug#919929: python-scipy: autopkgtest fails (Re: bug#919929)

[Drew Parsons]

On 2019-03-10 03:51, Paul Gevers wrote:

Hi Drew,

On 08-03-2019 03:08, Drew Parsons wrote:

On 2019-03-07 20:46, Paul Gevers wrote:
If you upload now, your package will not migrate to testing before 
the
full freeze becomes effective so it would need an unblock. If you 
want
to fix this issue with the three lines I saw in the bug report, you 
can
go ahead. However, it is probably worth waiting for a resolution of 
bug

915738 and combine it with that.



Alas, the deprecation patch (in python-scipy 1.1.0-3) doesn't actually
prevent emission of the deprecation warnings, so they're still 
spamming

the debci log.


Do you have evidence they did anything at all? If not, please revert
this if we get to a new upload.


It would seem it did not help.  In any case, the upstream patches 
supercede this patch, so it will be removed naturally.



To remove the deprecation warnings we'd need to deal with them at the
source. Upstream has patches
https://github.com/scipy/scipy/commit/614847c5fc8d5f8a618980df3c1b93540428ae46

https://github.com/scipy/scipy/commit/e0cfa29e2fbe86f994924c0c7514ff5bbfffd514

and for completeness
https://github.com/scipy/scipy/commit/87e48c3c54d7a85bc6628c88c1de98ac0469b6fa


The deprecation problem (matrix API) appears in many places, but the 
fix

is straightfoward: replace np.matrix with matrix from from
scipy.sparse.sputils

Can you authorise an unblock to apply these 3 upstream patches to
python-scipy 1.1.0 ?
That won't necessarily fix the debci failure, but it will make it a 
lot

easier to see what's actually failing.


I am slightly unhappy with the second patch, as it seems to be doing
more than you describe above in a few places. This may be correct but
that is difficult to quickly judge.


The patches as they are don't apply cleanly to the 1.1.0 source, so I'll 
need to adapt them anyway.  I can retain only the ones relevant to 
updating the matrix API.




Also, what is the general documented way that these wrappers can be
used? scipy is sort of taking over the maintenanceship of these
functions in this way if we're not careful.



It's a good question that the other scipy maintainers might have thought 
more about.  As far as I can tell, the scipy tests affected here involve 
sparse matrices.  The trouble arises from an "inadequacy" in the core 
numpy API, with numpy.matrix only being suitable for dense matrices.  
scipy could be described as "numpy+algorithms", with additional 
algorithms required to handle sparse matrices, provided in 
scipy.sparse.sputils.matrix.


numpy.matrix is documented at 
https://docs.scipy.org/doc/numpy/reference/generated/numpy.matrix.html


The scipy sparse matrix API is at 
https://docs.scipy.org/doc/scipy/reference/sparse.html, but that's 
specifically for scipy.sparse.spmatrix


There is discussion of the distinction between numpy.matrix and 
numpy.ndarray (which is at the heart of the deeprecation warning) at 
https://docs.scipy.org/doc/scipy/reference/tutorial/linalg.html#numpy-matrix-vs-2d-numpy-ndarray


The utility class scipy.sparse.sputils itself is apparently 
undocumented, by which I infer it's intended for internal use only, not 
a public API. I guess it's reasonable for a package to be testing it's 
own internal functions.  Strange thing is, scipy.sparse.sputils.matrix 
is not actually defined in scipy/sparse/sputils.py. Must be inherited or 
defined in some deep pythonfu that I haven't mastered yet.


I'll check that I can adapt those upstream patches to cleanly remove 
these deprecation warnings.


Drew

Bug#924047: FTBFS: package don't build successful after new GCC version

[Carsten Schoenert]

Am 10.03.19 um 05:39 schrieb أحمد المحمودي:
> I'd rather remove the symbols file.

That's the last option in my eyes as it's a step backwards and is
absolutely not needed as I fixed the problem already.

The main problem with the symbols is that the symbols are simply not
versioned and that's an upstream problem.

-- 
Regards
Carsten Schoenert

Bug#924184: no help for download template?

[Harald Dunkel]

Package: lxc
Version: 1:3.1.0+really3.0.3-5

Running
lxc-create -t download -- --help

I had expected to get usage information about the download template,
but instead I got a huge list of images. Next it showed

Distribution:

and got unresponsive. Exit with ^C or ^D. Apparently it has created a
new container directory /var/lib/lxc/--help.

This is unexpected. The -- is supposed to separate the template
options from the options to lxc-create itself. There should have
either been an error message about the missing "-n name" option,
or any kind of usage message.


Regards
Harri

Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery

[intrigeri]

Package: postfix
Version: 3.4.1-1
Severity: important
Tags: patch

Hi,

I have entries like this:

  [domain.tld]:587secure tafile=/etc/ssl/certs/Lets-Encrypt-Authority-X3.pem

… in the file referenced by:

  smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

This worked just fine until 3.3.2-4 inclusive but since I've upgraded
my sid system yesterday and Postfix was upgraded to 3.4.1-1 I see:

  postfix/smtp[15202]: warning: Trust anchor files not supported
  postfix/smtp[15202]: warning: TLS policy lookup error for 
[domain.tld]:587/domain.tld: client TLS configuration problem
  postfix/smtp[15202]: warning: TLS policy lookup for 
[domain.tld]:587/domain.tld: client TLS configuration problem
  postfix/smtp[15202]: 8B30018835E3: to=, relay=none, 
delay=1197, delays=1196/0.82/0.36/0, dsn=4.7.5, status=deferred (client TLS 
configuration problem)

This seems to come from src/tls/tls_dane.c. I see that 3.4.0 has
modified this file quite a bit, e.g. these lines were removed:

  #if OPENSSL_VERSION_NUMBER >= 0x100fL && \
 (defined(X509_V_FLAG_PARTIAL_CHAIN) || !defined(OPENSSL_NO_ECDH))
  #define TRUST_ANCHOR_SUPPORT

… and there's only one "#ifdef TRUST_ANCHOR_SUPPORT" left, that guards
the warning I'm seeing. This feels like a leftover of an incomplete
cleanup of the TLS support code that happened in this release, such as
dropping support for OpenSSL 1.0.1.

FWIW the attached patch fixes this problem for me. I don't know if it
can cause any trouble.

I'm setting severity to important as this is a regression introduced
at the last minute before the Buster freeze, but of course feel free
to adjust as you wish :)

Cheers!


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

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

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.12+dfsg-6
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.5
ii  e2fsprogs  1.45.0-1
ii  libc6  2.28-8
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libicu63   63.1-6
ii  libsasl2-2 2.1.27+dfsg-1
ii  libssl1.1  1.1.1b-1
ii  lsb-base   10.2018112800
ii  netbase5.6
ii  ssl-cert   1.0.39

Versions of packages postfix recommends:
ii  python3  3.7.2-1

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]8.1.2-0.20180807cvs-1
ii  dovecot-core [dovecot-common]  1:2.3.4.1-1
ii  emacs-gtk [mail-reader]1:26.1+1-3.2
ii  evolution [mail-reader]3.30.5-1
ii  libsasl2-modules   2.1.27+dfsg-1
ii  mailutils [mail-reader]1:3.5-2
ii  mutt [mail-reader] 1.10.1-2
pn  postfix-cdb
pn  postfix-doc
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mysql  
pn  postfix-pcre   
pn  postfix-pgsql  
pn  postfix-sqlite 
pn  procmail   
pn  resolvconf 
ii  thunderbird [mail-reader]  1:60.5.1-1
pn  ufw

-- debconf information:
  postfix/kernel_version_warning:
  postfix/destinations: $myhostname, manticora, localhost.localdomain, , 
localhost
  postfix/mydomain_warning:
  postfix/tlsmgr_upgrade_warning:
  postfix/chattr: false
  postfix/relay_restrictions_warning:
  postfix/mailbox_limit: 0
  postfix/sqlite_warning:
  postfix/root_address:
  postfix/relayhost:
* postfix/main_mailer_type: No configuration
  postfix/main_cf_conversion_warning: true
  postfix/retry_upgrade_warning:
  postfix/procmail: false
  postfix/mailname: manticora
  postfix/bad_recipient_delimiter:
  postfix/lmtp_retired_warning: true
  postfix/rfc1035_violation: false
  postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
  postfix/dynamicmaps_conversion_warning:
  postfix/recipient_delim: +
  postfix/not_configured:
  postfix/compat_conversion_warning: true
  postfix/protocols: all
  postfix/newaliases: false

-- 
intrigeri

>From 4d98d0aa5aeb4fbb9941a4239251edfb1537a0e9 Mon Sep 17 00:00:00 2001
From: intrigeri 
Date: Sun, 10 Mar 2019 06:29:25 +
Subject: [PATCH] Drop leftover of obsolete check for trust anchor support.

---
 src/tls/tls_dane.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/tls/tls_dane.c b/src/tls/tls_dane.c
index 93f8e2a5..013426b1 100644
--- a/src/tls/tls_dane.c
+++ b/src/tls/tls_dane.c
@@ -1125,7 +1125,6 @@ TLS_DANE *tls_dane_resolve(unsigned port, const char *proto, DNS_RR *hostrr,
 
 int tls_dane_load_trustfile(TLS_DANE *dane, const char *tafile)
 {
-#ifdef 

Bug#924182: [pre-approval] unblock: julia/1.0.3+dfsg-5

[Mo Zhou]

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

This is a pre-approval for unblocking julia 1.0.3+dfsg-5,
which follows the unblock request for llvm-toolchain-6.0 (= 1:6.0.1-11).

The difference between julia/testing and julia/1.0.3+dfsg-5 will be:

* Drop the embedded LLVM tarball from debian directory.
* Remove dirty hacks used for building the vendored LLVM.
* Build julia against system LLVM instead of the vendored one.

The vendored LLVM was temporarily added since 1.0.3+dfsg-3,
so it's quite safe to switch back to the system LLVM since
nearly all patches required by julia have been added to
llvm-toolchain-6.0 (= 1:6.0.1-11).

(include/attach the debdiff against the package in testing)
debdiff not available yet.

unblock julia/1.0.3+dfsg-5

-- 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_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#924181: unblock: llvm-toolchain-6.0/1:6.0.1-11

[Mo Zhou]

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

Please unblock package llvm-toolchain-6.0

-- Summary --

 * Remove 'Multi-Arch: same' in libclang (Closes: #874248)
 * Cherry-pick various llvm fixes for Julia (Closes: #919628)
 * Rebase and enable D51639-optim-issue.diff
 * Remove some useless patches

-- Detail --

diffstat for llvm-toolchain-6.0-6.0.1 llvm-toolchain-6.0-6.0.1

 changelog |   14
 control   |1

   * Remove 'Multi-Arch: same' in libclang (Closes: #874248)

 orig-tar.sh   |6

   Just changed several "http" into "https", to trivial to write into log.

 patches/D51639-optim-issue.diff   |   22

   This patch has been rebased and re-enabled because it fixes an old problem:
   79ca353 2018-09-06 20:51 +0200 Sylvestre Ledru I Fix an optimization issues 
(Closes: #907649) See upstream bug 38786
 
 patches/fix-lldb-server-build |   73

   Removed. Deprecated long time ago.

 patches/install-lldb-sb-headers.patch |   58

   Removed. Merged into upstream long time ago.

 patches/julia/llvm-6.0-NVPTX-addrspaces.patch |   32
 patches/julia/llvm-D27629-AArch64-large_model_6.0.1.patch |   24
 patches/julia/llvm-D34078-vectorize-fdiv.patch|   53
 patches/julia/llvm-D42262-jumpthreading-not-i1.patch  |   82
 patches/julia/llvm-D44892-Perf-integration.patch  |  677 +
 patches/julia/llvm-D50010-VNCoercion-ni.patch |   89
 patches/julia/llvm-D50167-scev-umin.patch | 1143 ++
 patches/julia/llvm-rL326967-aligned-load.patch|  301
 patches/julia/llvm-rL327898.patch | 6131 ++
 patches/series|   33

   Fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919628
   These patches are important for julia.
   Details on what each patch does:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919628#37

 16 files changed, 8587 insertions(+), 152 deletions(-)

debdiff attached.

unblock llvm-toolchain-6.0/1:6.0.1-11

-- 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_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


llvm.diff.zst
Description: Binary data

Bug#924180: file-roller: Trims files extracted from iso images

[pavel]

Package: file-roller
Version: 3.30.1-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I tried to extract files from ISO images of WinXP and Win7 installation disks.

   * What was the outcome of this action?

Extraction passed without any error. The I have mounted ISO files with "mount
-i loop ..." and noticed that total size of files in mounted folder is larger
than in extracted. I looked through these folders and noticed that one file
that is about 5GB in mounted folder is about 1GB in extracted folder. In case
of another image several extracted filed have zero size instead of several KB.
So I think the problem is not specific to large files.

   * What outcome did you expect instead?

Extracted image and folder mounted with "mount -i loop ..." should be the same.

*** End of the template - remove these template lines ***



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

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

Versions of packages file-roller depends on:
ii  bzip21.0.6-9
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gconf-gsettings-backend [gsettings-backend]  3.2.6-5
ii  libarchive13 3.3.3-3
ii  libc62.28-7
ii  libcairo21.16.0-2
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.2-4
ii  libgtk-3-0   3.24.4-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libnautilus-extension1a  3.30.5-1
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-6
ii  p7zip-full   16.02+dfsg-6

Versions of packages file-roller recommends:
ii  gvfs  1.38.1-2+b1
pn  yelp  

Versions of packages file-roller suggests:
pn  arj  
pn  lha  
pn  lzip 
ii  lzop 1.03-4+b1
pn  ncompress
pn  rpm2cpio 
pn  rzip 
pn  sharutils
pn  squashfs-tools   
pn  unace
pn  unalz
pn  unar 
ii  unzip6.0-21
ii  xz-utils [lzma]  5.2.4-1
ii  zip  3.0-11+b1
pn  zoo  

-- debconf-show failed

Bug#924027: unblock: extsmail/2.2-4

[Olivier Girondel]

On Sat, 9 Mar 2019 15:43:51 + Jonathan Wiltshire  wrote:
> Control: tag -1 moreinfo
> 
> Hi,
> 
> On Fri, Mar 08, 2019 at 02:40:48PM +0100, Olivier Girondel wrote:
> > Please unblock extsmail.
> > 
> > I uploaded a new version of extsmail, which reset the package's
> > transition countdown, which will cause it to miss the hard freeze window:
> 
> Well, as the package wasn't in testing at all on the 12th February it's
> actually not the hard freeze window that's relevant here. But yes, 2.2-1
> might have just squeaked in but 2.2-2, 2.2-3 and 2.2-4 have all followed
> that and will not be migrating.
> 
> I have some concerns about the packaging quality - not release critical,
> but still:
> 
>  - missing Vcs-* line in d/control?

Hi Jonathan,

Current "Vcs-Browser: https://github.com/ltratt/extsmail;

>  - referred vcs doesn't contain any Debian packaging?
I was asked to remove "Vcs-Git:
https://github.com/oliv3/extsmail-debian;, which is the repo where I do
packaging from though

>  - you added --no-parallel in 2.2-1, removed it in 2.2-2, added it again in
>2.2-3 with no explanations?

--no-parallel was the way to go, saved me from adding patchs.

> 
> None of these are show-stoppers but they do stand out a bit. Any comment on
> them?

Thanks for looking at this !

--
Olivier

Bug#917738: patch

[Joe Lee]

tag 917738 + patch
thanks

Hi, here's a patch for bug #917738 that I extracted from upstream.
Description: remove WebServiceException
Origin: upstream, https://github.com/OpenHFT/Chronicle-Threads/commit/bb1d4edfc7a783ebdc7c58bfc2f278f665e2539e#diff-e5af304c7efa4fec7930553b2fab754b
Index: openhft-chronicle-threads-1.1.6/src/main/java/net/openhft/chronicle/threads/MonitorEventLoop.java
===
--- openhft-chronicle-threads-1.1.6.orig/src/main/java/net/openhft/chronicle/threads/MonitorEventLoop.java
+++ openhft-chronicle-threads-1.1.6/src/main/java/net/openhft/chronicle/threads/MonitorEventLoop.java
@@ -25,7 +25,6 @@ import org.jetbrains.annotations.NotNull
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
-import javax.xml.ws.WebServiceException;
 import java.io.Closeable;
 import java.util.ArrayList;
 import java.util.List;
@@ -120,7 +119,8 @@ public class MonitorEventLoop implements
 }
 
 @Override
-public void close() throws WebServiceException {
+public void close() {
+stop();
 service.shutdown();
 try {
 if (!service.awaitTermination(100, TimeUnit.MILLISECONDS))

Bug#924139: www.debian.org: migrate from python to python3

[황병희]

On Sat, Mar 09 2019, Cyril Brulebois wrote:
> ...snip...
> point, as Python 2 is on the way out.

Well i'm not position to resolve it. However that is very very very
dangerous i think. Anyhow, it is interesting PR, to me.

Sincerely, Byung-Hee.

-- 
Still i'm waiting for Debian 11 -- ^Bullseye_^))//

Bug#924047: FTBFS: package don't build successful after new GCC version

[أحمد المحمودي]

On Fri, Mar 08, 2019 at 09:43:17PM +0100, Carsten Schoenert wrote:
> the systemc package is currently failing to build from source basically
> related due a newer GCC version and changed symbols introduced by the
> newer GCC.
> 
> I've fixed the reason of the FTBFS by modifying and adopting the
> symbols file so the package is building again on all RC platforms. I've
> pushed the adopted symbols file to Salsa after I've tested the builds.
---end quoted text---

I'd rather remove the symbols file.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#922647: Info received (Bug#922647: systemd --user no longer running)

[Steve Langasek]

On Sat, Mar 09, 2019 at 08:25:50PM +0100, Michael Biebl wrote:
> [bringing Steve, our pam maintainer, into the loop]

> Hi Steve,

> the following looks like an issue in pam-auth-update and similar to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923362

> Any idea what might be going wrong there?

If it's the same as bug #923362, note that this bug was closed as invalid as
the user had a corrupt debconf database that was somehow causing the wrong
information to be returned to pam-auth-update.

So it's quite possible this is a latent debconf database corruption problem
on end users' systems, which is only tickled now as a result of there being
a new upstream version of pam causing pam debconf prompts for the first time
in a few years.

I would suggest taking a snapshot of /var/cache/debconf, then running
/usr/share/debconf/fix_db.pl as the submitter of the other bug did, then
diffing to see what has changed if anything.

> Am 09.03.19 um 19:55 schrieb Julien Leproust:
> > Hi,
> > 
> > Well we're in luck, I have etckeeper installed since 2012.
> > 
> > On both machines, I never edited /etc/pam.d/common-* manually.
> > 
> > * fc3256a - Sat, 9 Mar 2019 12:59:20 +0100 (7 hours ago) (HEAD -> master)
> > |   daily autocommit - root
> > * efc0d23 - Thu, 7 Feb 2019 23:16:46 +0100 (4 weeks ago)
> > |   committing changes in /etc made by "aptitude" - root
> > * 6d1fbcf - Tue, 20 Feb 2018 22:51:34 +0100 (1 year, 1 month ago)
> > |   committing changes in /etc after apt run - root
> > * 72d4029 - Tue, 19 Apr 2016 22:00:51 +0200 (2 years, 11 months ago)
> > |   committing changes in /etc after apt run - root
> > * 50f69ee - Sat, 1 Mar 2014 15:33:33 +0100 (5 years ago)
> > |   committing changes in /etc after apt run - root
> > * dee824f - Sat, 4 Aug 2012 10:55:33 +0200 (7 years ago)
> >     Initial commit - root
> > 
> > The modification today is the fix using pam-auth-update.
> > 
> > The last modification, which broke pam_systemd.so, was triggered by
> > libpam-cap:amd64 (1:2.25-2). The update triggered pam-auth-update, and
> > /var/log/apt/term.log shows the choices I made:
> > 
> > ┤ PAM configuration ├───
> > Pluggable Authentication Modules (PAM) determine how authentication,
> > authorization, and password changing are handled on the system, as
> > well as allowing configuration of additional actions to take when
> > starting user sessions.
> > 
> > Some PAM module packages provide profiles that can be used to
> > automatically adjust the behavior of all PAM-using applications on
> > the system.  Please indicate which of these behaviors you wish to
> > enable.
> > 
> > PAM profiles to enable:
> > 
> >    [*] Unix authentication
> >    [*] Register user sessions in the systemd control group ...
> >    [ ] Create home directory on login
> >    [*] GNOME Keyring Daemon - Login keyring management
> >    [*] Inheritable Capabilities Management
> > 
> > 
> >      
> > 
> > 
> > 
> > And then, pam_systemd.so was incorrectly removed? I'm sure you're going
> > to assume I disabled the second option, but I really doubt this.
> > 
> > Previous modifications:
> > - 20 Feb 2018: removal of libpam-ck-connector
> > - 19 Apr 2016: installation of libpam-cgfs
> > - 1 Mar 2014: installation of libpam-systemd
> > 
> > Initial state for reference in August 2012:
> > ===
> > #
> > # /etc/pam.d/common-session - session-related modules common to all
> > services
> > #
> > # This file is included from other service-specific PAM config files,
> > # and should contain a list of modules that define tasks to be performed
> > # at the start and end of sessions of *any* kind (both interactive and
> > # non-interactive).
> > #
> > # As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
> > # To take advantage of this, it is recommended that you configure any
> > # local modules either before or after the default block, and use
> > # pam-auth-update to manage selection of other modules.  See
> > # pam-auth-update(8) for details.
> > 
> > # here are the per-package modules (the "Primary" block)
> > session    [default=1]    pam_permit.so
> > # here's the fallback if no module succeeds
> > session    requisite    pam_deny.so
> > # prime the stack with a positive return value if there isn't one already;
> > # this avoids us returning an error just because nothing sets a success
> > code
> > # since the modules above will each just jump around
> > session    required    pam_permit.so
> > # and here are more per-package modules (the "Additional" block)
> > session    required    pam_unix.so
> > session    optional    pam_systemd.so
> > session    optional    pam_ck_connector.so nox11
> > # end of pam-auth-update config
> > 

Bug#924179: Package: installation-reports

[Tom Thekathyil]

Package: installation-reports

Boot method: DVD
Image version:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/iso-dvd/firmware-testing-amd64-DVD-1.iso
Date: 2019-03-10 noon (AU)

Machine: Desktop
Processor: Ryzen 3 2200G/Vega 8
Memory: 2x4gb ddr4 team 2400
Partitions: N/A -see below

Output of lspci -knn (or lspci -nn): N/A

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [0]
Detect network card:[0]
Configure network:  [0]
Detect CD:  [0]
Load installer modules: [E]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems: Getting error message:

"No kernel modules were found.  This probably is due to a mismatch
between the kernel used by this version of the installer and the
kernel version available in the archive.

If you're installing from a mirror, you can work around this problem
by choosing to install a different version of Debian.  The install
will probably fail to work if you continue without kernel modules.

Continue the install without loading kernel modules?"

Got this message twice so aborted.

Regards, Tom Thekathyil

-- 
PO Box 76, St. Helens, TAS 7216, Australia - Ph: 61 3 6373 6191
GnuPG Public Key 0xD8F45B65

Bug#924177: RFS: blastem/0.6.3-1 -- Fast and accurate Genesis emulator

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: blastem
   Version : 0.6.3-1
   Upstream Author : Michael Pavone 
 * URL : https://www.retrodev.com/blastem
 * License : GPL-3+
   Section : games

  It builds those binary packages:

  blastem - Fast and accurate Genesis emulator

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/blastem/blastem_0.6.3-1.dsc

  More information about BlastEm can be obtained from 
https://gitlab.com/coringao/blastem.

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#924176: apt-dater: broken symlink: /usr/share/doc/apt-dater/README -> README.md

[Andreas Beckmann]

Package: apt-dater
Version: 1.0.4-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m22.7s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/apt-dater/README -> README.md (apt-dater)


cheers,

Andreas


apt-dater_1.0.4-1.log.gz
Description: application/gzip

Bug#924178: python-paramiko: DeprecationWarning about EllipticCurvePublicNumbers when using duplicity

[Francois Marier]

Package: python-paramiko
Version: 2.4.2-0.1
Severity: normal
Forwarded: https://github.com/paramiko/paramiko/issues/1369

I see the following in my duplicity cronjob logs:

/usr/lib/python2.7/dist-packages/paramiko/kex_ecdh_nist.py:39: 
CryptographyDeprecationWarning: encode_point has been deprecated on 
EllipticCurvePublicNumbers and will be removed in a future version. Please use
EllipticCurvePublicKey.public_bytes to obtain both compressed and uncompressed 
point encoding.
  m.add_string(self.Q_C.public_numbers().encode_point())
/usr/lib/python2.7/dist-packages/paramiko/kex_ecdh_nist.py:96: 
CryptographyDeprecationWarning: Support for unsafe construction of public 
numbers from encoded data will be removed in a future version. Please use
EllipticCurvePublicKey.from_encoded_point
  self.curve, Q_S_bytes
/usr/lib/python2.7/dist-packages/paramiko/kex_ecdh_nist.py:111: 
CryptographyDeprecationWarning: encode_point has been deprecated on 
EllipticCurvePublicNumbers and will be removed in a future version. Please use
EllipticCurvePublicKey.public_bytes to obtain both compressed and uncompressed 
point encoding.
  hm.add_string(self.Q_C.public_numbers().encode_point())

This was reported upstream at

  https://github.com/paramiko/paramiko/issues/1369

and fixed using the following patch:

  https://github.com/paramiko/paramiko/pull/1379.

Francois

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

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

Versions of packages python-paramiko depends on:
ii  python   2.7.16-1
ii  python-bcrypt3.1.6-1
ii  python-cryptography  2.6.1-2
ii  python-nacl  1.3.0-2
ii  python-pyasn10.4.2-3

python-paramiko recommends no packages.

Versions of packages python-paramiko suggests:
pn  python-gssapi  

-- no debconf information

Bug#924175: android-sdk: broken symlink: /usr/lib/android-sdk/tools/bin/screenshot2 -> ../../../../bin/screenshot2

[Andreas Beckmann]

Package: android-sdk
Version: 25.0.0+10
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m20.7s ERROR: FAIL: Broken symlinks:
  /usr/lib/android-sdk/tools/bin/screenshot2 -> ../../../../bin/screenshot2 
(android-sdk)

Is android-sdk missing a dependency on android-platform-tools-base ?


cheers,

Andreas


android-sdk_25.0.0+10.log.gz
Description: application/gzip

Bug#924174: ruby-rails-assets-perfect-scrollbar: broken symlink: /usr/share/ruby-rails-assets-perfect-scrollbar/app/assets/javascripts/perfect-scrollbar.js -> ../../../../javascript/utatti-perfect-scr

[Andreas Beckmann]

Package: ruby-rails-assets-perfect-scrollbar
Version: 1.4.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m13.4s ERROR: FAIL: Broken symlinks:
  
/usr/share/ruby-rails-assets-perfect-scrollbar/app/assets/javascripts/perfect-scrollbar.js
 -> ../../../../javascript/utatti-perfect-scrollbar/dist/perfect-scrollbar.js 
(ruby-rails-assets-perfect-scrollbar)

You probably want to target 
/usr/share/ruby-rails-assets-perfect-scrollbar/app/assets/javascripts/utatti-perfect-scrollbar/dist/perfect-scrollbar.js
 instead.


cheers,

Andreas

Bug#924129: debian-installer: Kernel for armhf for stretch unbootable

[Vagrant Cascadian]

On 2019-03-09, Vagrant Cascadian wrote:
> On 2019-03-09, Cyril Brulebois wrote:
>> Peter Lebbing  (2019-03-09):
>>> Debian kernel bug #922478 renders armhf systems unbootable. This bug was
>>> fixed, but the debian-installer images still use (I presume) kernel
>>> version 4.9.144-3, the unbootable version.
...
>>> The installer worked when I overwrote the /vmlinuz in that image with
>>> the one from the new 4.9.144-3.1.
>
> Thanks for that specific piece of information; I was hoping to confirm
> that myself shortly, but that's promising.

I can also confirm that simply replacing the broken kernel with the one
from stretch-updates works for the netboot image.


>> Thanks for your report; that's known and fixed on the kernel side
>> already; how to deal with d-i is discussed in:
>>   https://lists.debian.org/debian-boot/2019/03/msg00165.html
>>
>> Currently waiting on some input from Vagrant:
>>   https://lists.debian.org/debian-boot/2019/03/msg00179.html

I rebuilt the package from the stretch git branch on armhf against
stretch+stretch-updates, and the build went fine. I tested the netboot
image and it too seems to be working.

Looks like a way forward to me!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#924173: nmu: sphinxbase_0.8+5prealpha+1-3

[Andreas Beckmann]

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

nmu sphinxbase_0.8+5prealpha+1-3 . ANY . unstable . -m "Rebuild with dh-python 
3.20190307 (#920037)"
dw sphinxbase_0.8+5prealpha+1-3 . ANY . unstable . -m "dh-python (>= 
3.20190307)"

Please rebuild sphinxbase with a fixed dh-python to correct the shared
library renaming.

relavant part of the binary debdiff:

Files in second .deb but not in first
-
-rw-r--r--  root/root 
/usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.cpython-37m-x86_64-linux-gnu.so

Files in first .deb but not in second
-
-rw-r--r--  root/root 
/usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
lrwxrwxrwx  root/root 
/usr/lib/python3.7/site-packages/sphinxbase/_sphinxbase.so -> 
_sphinxbase.so.0.0.0


Andreas

Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster

[Cyril Brulebois]

Package: www.debian.org
Severity: normal
User: www.debian@packages.debian.org
Usertags: scripts

Hi,

While working on rebuilding the website within stretch and buster, I've
noticed the following.

This is a curated summary based on diffing a stretch build tree and a
buster build tree, after building the english subdirectory only, with
USE_SAMPLE_FILES=1. This was built by diffing both directory, excluding
all files with 8 changes (assuming those were due to the webwml version
and dates of last modification/build changes, which a cursory look
confirms on dozens of them, but that really should be automated).

I'd think items #1 and #7 should be given high priority.


1. Changes related to canonicalization(?) of the URL


--- stretch/webwml/english/News/news.en.rdf
+++ buster/webwml/english/News/news.en.rdf
@@ -1,5 +1,5 @@
 
-
+
 http://www.w3.org/1999/02/22-rdf-syntax-ns#;
   xmlns="http://purl.org/rss/1.0/;

--- stretch/webwml/english/sitemap.en.html
+++ buster/webwml/english/sitemap.en.html

-
-  
-
+
+  
+

-  
+  

-   About Debian
-   Getting Debian
-   Support
-   Developers' Corner
+   About Debian
+   Getting Debian
+   Support
+   Developers' Corner

[ and many more ]


2. Changes in mail address representation
=

--- stretch/webwml/english/consultants/index.en.html
+++ buster/webwml/english/consultants/index.en.html

Many changes there, but I suppose this is due to some random obfuscation
of mail address, which is likely not reproducible anyway.


3. Changes in a log file


--- stretch/webwml/english/devel/misc/card.log
+++ buster/webwml/english/devel/misc/card.log

No surprises here, with versions for the build chain being bumped, and
timestamps.


4. Changes in ordering of coordinators
==

--- stretch/webwml/english/devel/website/translation_coordinators.en.html
+++ buster/webwml/english/devel/website/translation_coordinators.en.html

-Arabic: Ayman Negm n...@debian.org, Mohammed Adnne 
Trojette adn+...@diwi.org
+Arabic: Mohammed Adnne Trojette adn+...@diwi.org, 
Ayman Negm n...@debian.org

[ Ditto for: Arabic, Chinese, Indonesian, Persian, Polish, Romanian ]

Is it expected to have a random order? Or should this be made to build
and list people in a reproducible order?


5. Changes in ordering under wnpp
=

--- stretch/webwml/english/devel/wnpp/*
+++ buster/webwml/english/devel/wnpp/*

Should packages be listed in a reproducible order?


6. Changes in order under l10n
==

--- stretch/webwml/english/international/l10n/po-debconf/rank.en.html
+++ buster/webwml/english/international/l10n/po-debconf/rank.en.html

--- stretch/webwml/english/international/l10n/po/gen/rank.inc
+++ buster/webwml/english/international/l10n/po/gen/rank.inc

--- stretch/webwml/english/international/l10n/po/gen/stats
+++ buster/webwml/english/international/l10n/po/gen/stats

--- stretch/webwml/english/international/l10n/po/rank.en.html
+++ buster/webwml/english/international/l10n/po/rank.en.html

There might be some reproducibility issues here too.


7. Changes related to image width/height attributes
===


--- stretch/webwml/english/partners/2018/index.en.html
+++ buster/webwml/english/partners/2018/index.en.html

-  
+  

--- stretch/webwml/english/partners/2019/index.en.html
+++ buster/webwml/english/partners/2019/index.en.html

-  
+  

-  
+  

--- stretch/webwml/english/partners/index.en.html
+++ buster/webwml/english/partners/index.en.html

-  
+  

-  
+  

For some reason, width/height were empty, and they seem to be stripped
now? Progress, maybe, except that might be hiding the root issue?


8. More ordering changes (architectures, DSAs)
==

--- stretch/webwml/english/releases/potato/installmanual.en.html
+++ buster/webwml/english/releases/potato/installmanual.en.html

--- stretch/webwml/english/releases/potato/releasenotes.en.html
+++ buster/webwml/english/releases/potato/releasenotes.en.html

--- stretch/webwml/english/releases/woody/installmanual.en.html
+++ buster/webwml/english/releases/woody/installmanual.en.html

--- stretch/webwml/english/releases/woody/releasenotes.en.html
+++ buster/webwml/english/releases/woody/releasenotes.en.html

--- stretch/webwml/english/security/crossreferences.en.html
+++ buster/webwml/english/security/crossreferences.en.html

-- stretch/webwml/english/security/ref-table.inc
++ 

Bug#908514: [rt.cpan.org #127094] possible duplicate, doubts about the patch and the original code

[Josip Rodin]

On Fri, Dec 28, 2018 at 10:12:15PM +0100, joy wrote:
>  * https://forum.mikrotik.com/viewtopic.php?t=91863 from 2014
> 
> Even if all those devices have not been RFC-compliant

JFTR I had approached MikroTik about their issue, provided a test case and
tested a beta, and now with RouterOS 6.44 (released 2019-02-25) Net::SNMP
no longer croaks.

-- 
 2. That which causes joy or happiness.

Bug#924171: libdictzip-java: broken symlinks: /usr/share/doc/libdictzip-java/api/jquery/jquery-ui.* -> ../../../../javascript/jquery-ui/jquery-ui.*

[Andreas Beckmann]

Package: libdictzip-java
Version: 0.8.2-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m16.1s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libdictzip-java/api/jquery/jquery-ui.min.js -> 
../../../../javascript/jquery-ui/jquery-ui.min.js (libdictzip-java)
  /usr/share/doc/libdictzip-java/api/jquery/jquery-ui.min.css -> 
../../../../javascript/jquery-ui/themes/base/jquery-ui.min.css (libdictzip-java)
  /usr/share/doc/libdictzip-java/api/jquery/jquery-ui.js -> 
../../../../javascript/jquery-ui/jquery-ui.js (libdictzip-java)
  /usr/share/doc/libdictzip-java/api/jquery/jquery-ui.css -> 
../../../../javascript/jquery-ui/themes/base/jquery-ui.css (libdictzip-java)

Is libdictzip-java missing a Depends/Recommends/Suggests: libjs-jquery-ui?


cheers,

Andreas


libdictzip-java_0.8.2-2.log.gz
Description: application/gzip

Bug#924170: kytos-sphinx-theme-common: broken symlinks: /usr/share/kytos_sphinx_theme/kytos/static/{bootstrap,js}

[Andreas Beckmann]

Package: kytos-sphinx-theme-common
Version: 0.0.1+dfsg-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m17.0s ERROR: FAIL: Broken symlinks:
  /usr/share/kytos_sphinx_theme/kytos/static/js -> 
../../../../lib/python3/dist-packages/sphinx_bootstrap_theme/bootstrap/static/js
 (kytos-sphinx-theme-common)
  /usr/share/kytos_sphinx_theme/kytos/static/bootstrap -> 
../../../../lib/python3/dist-packages/sphinx_bootstrap_theme/bootstrap/static/bootstrap-3.3.7
 (kytos-sphinx-theme-common)

I'm not sure whether adding a dependency on python3-sphinx-bootstrap-theme
would be the logical solution in this case.


cheers,

Andreas


kytos-sphinx-theme-common_0.0.1+dfsg-1.log.gz
Description: application/gzip

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

[Gennaro Oliva]

Hi Met,
thank you for this bug report.

On Fri, Mar 01, 2019 at 12:48:20AM +0100, n...@sucha.eu wrote:
> 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.

The intention was to modify the location specified in the
slurm-wlm-configurator.html and not every possible location. This
because for any reason you can keep your pid file elsewhere and create 
the service file accordingly as you did. Anyway, since /var/run is only
a symbolic link to /run I modified the post installation script to handle
also this option, as in your case, in the next package release.

> Hint: maybe a wrong regex to match paths? Maybe only /var/run but not /run
> is updated?

the last hypothesis was the right one.

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

I don't think this is appropriate because, if a system administrator decide
to keep the pid file in another place and create a new service file
accordingly, removing the pid file entry in the configuration would make
services fail to start.

Best regards,
-- 
Gennaro Oliva

Bug#924166: debram: broken symlink: /usr/share/doc/debram/HISTORY.gz -> ../debram-data/HISTORY.gz

[Thaddeus H. Black]

Good notice. I believe that you are right. I don't suppose that this bug is
important enough to bother the release managers about, since the package in
question is used by almost no one, but if not before the release this bug
should be addressed after.

Thank you for the notice. I appreciate it. I do not believe that you and I
have met face to face but I hope that we shall someday meet. I admire your
OpenCL work and would like to discuss that matter further with you sometime.

At any rate, after the release (or before, if you think it important
enough), I will fix that link.


On Sun, Mar 10, 2019 at 12:18 AM Andreas Beckmann  wrote:

> Package: debram
> Version: 2.1.0
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + debram-data
>
> Hi,
>
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
>
> >From the attached log (scroll to the bottom...):
>
> 0m19.7s ERROR: FAIL: Broken symlinks:
>   /usr/share/doc/debram/HISTORY.gz -> ../debram-data/HISTORY.gz (debram)
>
> The target file does not (any longer) exist.
>
>
> cheers,
>
> Andreas
>

Bug#639937: Don't tell people to use jigdo

[積丹尼 Dan Jacobson]

OK I let it run, and indeed now it is getting packages from
snapshot.debian.org/archive/ ... at rate 24.3KB/s...

So nevermind, instead of
$ jigdo-lite 
http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo
and selecting a local Taiwan mirror,
I'll just look at e.g., http://debian.cs.nctu.edu.tw/debian-cd/
and get 
http://debian.cs.nctu.edu.tw/debian-cd/current/amd64/iso-cd/debian-9.8.0-amd64-netinst.iso
and as we speak,
debian-9.8.0-amd64-netinst.iso 43%[> ] 126.91M 
2.35MB/s eta 68s

Thus: no point to jigdo at all, even for Antarctica, probably.
Yup, is there a case where jigdo still beats the above scenario?

Bug#924169: libdvd-pkg: requires /var/lib to be 'exec'

[michel bonnet user]

Package: libdvd-pkg
Version: 1.4.0-1-2
Severity: normal

Dear Maintainer,

*** /tmp/bug_report_libdvd-pkg.txt
package : libdvd-pkg

* first attempts :
# dpkg-reconfigure libdvd-pkg
Can't exec "/var/lib/dpkg/info/libdvd-pkg.config": Permission non accordée at
/usr/share/perl/5.24/IPC/Open3.pm line 178.
open2: exec of /var/lib/dpkg/info/libdvd-pkg.config reconfigure 1.4.0-1-2
failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.

* it seems the package needs /var/lib to be exec
* besides, doc requires /usr/src to be used (this is ok, that place is used for
rebuilding kernels, modules, ...)

* normal settings on my system :
root@pc-fixe-on-1:~# cat /etc/fstab | grep '/usr '
/dev/mapper/vg1-lv_usr /usrext4noatime,nodev,ro 0   2
root@pc-fixe-on-1:~# cat /etc/fstab | grep '/var '
/dev/mapper/vg1-lv_var /varext4
nodev,nosuid,noexec,usrquota,grpquota 0   2

* changing settings for libdvd-pkg requirements :
root@pc-fixe-on-1:~# mount /usr -o rw,remount
root@pc-fixe-on-1:~# mount /var -o remount,exec

* second attempt :
root@pc-fixe-on-1:~# dpkg-reconfigure libdvd-pkg

* no errors

** conclusion :
this package requires /var/lib to be exec ; this is not a good idea and should
be changed

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

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

Versions of packages libdvd-pkg depends on:
ii  build-essential12.3
ii  debconf [debconf-2.0]  1.5.61
ii  debhelper  10.2.5
ii  devscripts 2.17.6+deb9u2
ii  dh-autoreconf  14
ii  wget   1.18-5+deb9u2

Versions of packages libdvd-pkg recommends:
ii  libcap2-bin  1:2.25-1

libdvd-pkg suggests no packages.

-- debconf information:
* libdvd-pkg/post-invoke_hook-install: true
* libdvd-pkg/first-install:
  libdvd-pkg/upgrade:
* libdvd-pkg/post-invoke_hook-remove: false
  libdvd-pkg/title_b-i:
  libdvd-pkg/title_u:
* libdvd-pkg/build: false
package : libdvd-pkg

* first attempts :
# dpkg-reconfigure libdvd-pkg
Can't exec "/var/lib/dpkg/info/libdvd-pkg.config": Permission non accordée at 
/usr/share/perl/5.24/IPC/Open3.pm line 178.
open2: exec of /var/lib/dpkg/info/libdvd-pkg.config reconfigure 1.4.0-1-2 
failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.

* it seems the package needs /var/lib to be exec
* besides, doc requires /usr/src to be used (this is ok, that place is used for 
rebuilding kernels, modules, ...)

* normal settings on my system :
root@pc-fixe-on-1:~# cat /etc/fstab | grep '/usr '
/dev/mapper/vg1-lv_usr /usrext4noatime,nodev,ro 0   2
root@pc-fixe-on-1:~# cat /etc/fstab | grep '/var '
/dev/mapper/vg1-lv_var /varext4
nodev,nosuid,noexec,usrquota,grpquota 0   2

* changing settings for libdvd-pkg requirements :
root@pc-fixe-on-1:~# mount /usr -o rw,remount
root@pc-fixe-on-1:~# mount /var -o remount,exec

* second attempt :
root@pc-fixe-on-1:~# dpkg-reconfigure libdvd-pkg

* no errors

** conclusion :
this package requires /var/lib to be exec ; this is not a good idea and should 
be changed
no others debian packages to my memory requires that.
package : libdvd-pkg

* first attempts :
# dpkg-reconfigure libdvd-pkg
Can't exec "/var/lib/dpkg/info/libdvd-pkg.config": Permission non accordée at 
/usr/share/perl/5.24/IPC/Open3.pm line 178.
open2: exec of /var/lib/dpkg/info/libdvd-pkg.config reconfigure 1.4.0-1-2 
failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.

* it seems the package needs /var/lib to be exec
* besides, doc requires /usr/src to be used (this is ok, that place is used for 
rebuilding kernels, modules, ...)

* normal settings on my system :
root@pc-fixe-on-1:~# cat /etc/fstab | grep '/usr '
/dev/mapper/vg1-lv_usr /usrext4noatime,nodev,ro 0   2
root@pc-fixe-on-1:~# cat /etc/fstab | grep '/var '
/dev/mapper/vg1-lv_var /varext4
nodev,nosuid,noexec,usrquota,grpquota 0   2

* changing settings for libdvd-pkg requirements :
root@pc-fixe-on-1:~# mount /usr -o rw,remount
root@pc-fixe-on-1:~# mount /var -o remount,exec

* second attempt :
root@pc-fixe-on-1:~# dpkg-reconfigure libdvd-pkg

* no errors

** conclusion :
this package requires /var/lib to be exec ; this is not a good idea and should 
be changed
no others debian packages to my memory requires that.

Bug#821006: make_systemd_links() does not resolve symlinks

[Michael Biebl]

On Thu, 14 Apr 2016 15:44:02 +0200 Michael Biebl  wrote:
> Package: init-system-helpers
> Version: 1.29
> Severity: normal
> File: /usr/sbin/update-rc.d
> 
> If a package ships a native service file, like NetworkManager.service,
> and a static symlink, like network-manager.service,
> update-rc.d enable network-manager should resolve the symlink in
> make_systemd_links(), as upstream systemctl does.
> Otherwise we will have a
> /etc/systemd/system/multi-user.target.wants/network-manager.service
> symlink, when we only want
> /etc/systemd/system/multi-user.target.wants/NetworkManager.service
> 

This is less of an issue nowadays as update-rc.d will use systemctl if
available, which dtrt.

-- 
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#924168: jetty9: broken symlink: /usr/share/jetty9/lib/apache-jsp/jdt-core.jar -> ../../../java/ecj.jar

[Andreas Beckmann]

Package: jetty9
Version: 9.4.15-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m34.1s ERROR: FAIL: Broken symlinks:
  /usr/share/jetty9/lib/apache-jsp/jdt-core.jar -> ../../../java/ecj.jar 
(jetty9)

Is jetty9 missing a dependency on libecj-java ?


cheers,

Andreas


jetty9_9.4.15-1.log.gz
Description: application/gzip

Bug#892357: deb-systemd-invoke: if one unit is forbidden by policy-rc.d, all requested units are skipped

[Michael Biebl]

Hi Colin,

sorry for the late reply

Am 08.03.18 um 13:49 schrieb Colin Watson:
> Package: init-system-helpers
> Version: 1.51
> Severity: normal
> 
> dh_systemd_start generates a deb-systemd-invoke command listing all the
> binary package's units.  For snapd in Ubuntu, for example, this looks
> like this:
> 
>   deb-systemd-invoke start snapd.autoimport.service snapd.core-fixup.service 
> snapd.refresh.service snapd.refresh.timer snapd.service 
> snapd.snap-repair.service snapd.snap-repair.timer snapd.socket 
> snapd.system-shutdown.service >/dev/null || true
> 
> (I'm sure there are other similar examples of a package shipping many
> services; this is just the one I have to hand right now.)
> 
> Now, in some situations one might well want to disable a subset of those
> units using the policy-rc.d interface.  For example, in a buildd-type
> situation, it makes sense to disable snapd.refresh.timer.  Unfortunately
> this can't be done using policy-rc.d because deb-systemd-invoke handles
> policy-rc.d like this:
> 
>   if (-x $policyhelper) {
>   for my $unit (@units) {
>   system(qq|$policyhelper $unit "$action"|);
>   
>   # 0 or 104 means run
>   # 101 means do not run
>   my $exitcode = ($? >> 8);
>   if ($exitcode == 101) {
>   print STDERR "$policyhelper returned 101, not running '" . 
> join(' ', @ARGV) . "'\n";
>   exit 0;
>   } elsif ($exitcode != 104 && $exitcode != 0) {
>   print STDERR "deb-systemd-invoke only supports $policyhelper 
> return codes 0, 101, and 104!\n";
>   print STDERR "Got return code $exitcode, ignoring.\n";
>   }
>   }
>   }
> 
> Thus, if policy-rc.d returns 101 for any single unit, they all fail to
> start (and so it's necessary to resort to alternative hacks like
> symlinking /etc/systemd/system/snapd.refresh.timer to /dev/null).  This
> seems at best somewhat counterintuitive.
> 
> Would it be possible instead for deb-systemd-invoke to handle this in a
> finer-grained way?  I'm thinking of something like the following,
> although it's untested beyond a syntax check:

Makes sense to me although I'm not a perl guy.

> diff --git a/script/deb-systemd-invoke b/script/deb-systemd-invoke
> index 71b1c33..ba76cba 100755
> --- a/script/deb-systemd-invoke
> +++ b/script/deb-systemd-invoke
> @@ -61,6 +61,7 @@ my $policyhelper = '/usr/sbin/policy-rc.d';
>  my @units = @ARGV;
>  my $action = shift @units;
>  if (-x $policyhelper) {
> +my @allowed_units;
>  for my $unit (@units) {
>  system(qq|$policyhelper $unit "$action"|);
>  
> @@ -68,13 +69,16 @@ if (-x $policyhelper) {
>  # 101 means do not run
>  my $exitcode = ($? >> 8);
>  if ($exitcode == 101) {
> -print STDERR "$policyhelper returned 101, not running '" . 
> join(' ', @ARGV) . "'\n";
> -exit 0;
> +print STDERR "$policyhelper returned 101, not running '$unit'\n";
>  } elsif ($exitcode != 104 && $exitcode != 0) {
>  print STDERR "deb-systemd-invoke only supports $policyhelper 
> return codes 0, 101, and 104!\n";
>  print STDERR "Got return code $exitcode, ignoring.\n";
> +push @allowed_units, $unit;
> +} else {
> +push @allowed_units, $unit;
>  }
>  }
> +@units = @allowed_units;
>  }
>  
>  # If the job is disabled and is not currently running, the job is not 
> started or restarted.
> @@ -107,5 +111,5 @@ if ($action eq "start" || $action eq "restart") {
>  }
>  exit(0);
>  } else {
> -exec '/bin/systemctl', @ARGV;
> +exec '/bin/systemctl', @units if @units;

Aren't we missing the $action here?



-- 
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#924167: gap-openmath: broken symlink: /usr/share/doc/gap-openmath/README.cds -> ../../gap/pkg/openmath/cds/README

[Andreas Beckmann]

Package: gap-openmath
Version: 11.4.2+ds-3
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m11.9s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/gap-openmath/README.cds -> ../../gap/pkg/openmath/cds/README 
(gap-openmath)


cheers,

andreas


gap-openmath_11.4.2+ds-3.log.gz
Description: application/gzip

Bug#924138: unblock: libnet-duo-perl/1.02-1

[Russ Allbery]

Control: tag -1 -moreinfo

Jonathan Wiltshire  writes:
> On Sat, Mar 09, 2019 at 12:44:59PM -0800, Russ Allbery wrote:

>> * Upload 1.02-1 to unstable and have you unblock that for propagation to
>>   testing as a regular package update?  This is a leaf package, so I'm
>>   pretty confident that this should be safe, but it has extraneous changes
>>   compared to only fixing this bug.

> This one please; and then remove moreinfo from this bug when it's ready to
> unblock.

Now uploaded and in unstable, so it should be ready to unblock (unless I
misunderstood and you meant after the package had aged as well).

Thank you!

-- 
Russ Allbery (r...@debian.org)   

Bug#918965: adequate tells about broken-symlink in quassel-data

[Scott Kitterman]

On Sun, 10 Mar 2019 00:52:35 +0100 Andreas Beckmann  wrote:
> On Fri, 15 Feb 2019 12:52:13 -0500 Scott Kitterman
>  wrote:
> > See the package Suggests.  This is intentional.
> 
> There is no package in sid that ships a mpris-quassel binary.

Thanks.  Looks like I got it mixed up with inxi.  I agree it's a bug.

Scott K

Bug#639937: Don't tell people to use jigdo

[積丹尼 Dan Jacobson]

Also when jigdo-lite is asking us questions, it can first mention "don't
worry about 404s"

Bug#924166: debram: broken symlink: /usr/share/doc/debram/HISTORY.gz -> ../debram-data/HISTORY.gz

[Andreas Beckmann]

Package: debram
Version: 2.1.0
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + debram-data

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m19.7s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/debram/HISTORY.gz -> ../debram-data/HISTORY.gz (debram)

The target file does not (any longer) exist.


cheers,

Andreas


debram-data_2.1.0.log.gz
Description: application/gzip

Bug#639937: Don't tell people to use jigdo

[積丹尼 Dan Jacobson]

SM> You don't show to the end of the log. Jigdo will switch to grabbing
SM> missing files from snapshot.d.o once it has finished with all the
SM> files it can find on the mirrors you've told it about.

GREAT: BUT:

The user will start seeing these 404s interspersed with the 200s and
think:

"Yup, just as I suspected. 'Jigdo not being further developed' 'FAQ not
touched since 2005'...

So, just as I did, they hit ^C and delete all of what has been half
downloaded, and purge the jigdo-lite .deb from their system.

Therefore: You need to reassure the user, before he gets started, that
interspersed 404s are normal, and it will get the rest from
snapshot.d.o.

So you need to say it on the jigdo-lite man page, on the www.debian.org
pages and most of all, right next to each 404 as they fly by!

Else who will sit there downloading hundreds of megabytes and watching
404s go by. Nobody will wait till the end thinking that some miracle
will happen. Unless you make sure they know that it will. Thanks.

Bug#872635: util-linux: FTBFS on armel: test failure

[Andy Simpkins]

I have had a look at this as part of the Cambridge BSP 2019-03-09

I am able to reproduce this 'bug', on multiple architectures  the
following is copy/paste from buster on my AMD64 laptop :-p

Simply running the test by hand
Assuming you have a working / reliable resolver / untainted cache then
the command succeeds:


../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -d  root
IPv6 root a.root-servers.n Wed Aug 28 21:30 - 21:40  (00:10)

wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013




../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -w -d root
IPv6 root a.root-servers.net Wed Aug 28 21:30 - 21:40  (00:10)

wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013




../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -a -d root
IPv6 root Wed Aug 28 21:30 - 21:40  (00:10)
a.root-servers.net

wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013







causing a failure can be done simply by unplugging the machine from the
network, thus...

../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -d root
IPv6 root dns-server   Wed Aug 28 21:30 - 21:40  (00:10)

wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013



../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -w -d root
IPv6 root dns-server   Wed Aug 28 21:30 - 21:40  (00:10)

wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013



/util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -a -d root
IPv6 root Wed Aug 28 21:30 - 21:40  (00:10) dns-server

wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013



From this I conclude that the test itself is poor - it is assuming that
there is a consistently good network / resolver for the duration of the
test, something that can not be assumed to always be true. Theoretically
glitches can happen anywhere, at any time.

Question.  What is the purpose of these 3 specific tests?
 If we are confirming that 'last' is formatting output in the manor
specified by the switches then the tests are successful:  the reported
output may contain EITHER a.root-servers.net XOR dns-server
If we are testing that the lookup has happened then it is perfectly
acceptable that it will not be possible due to a transitory network
failure.  this does not mean that last itself is not working correctly
only that this test did not PASS (i.e. !PASS is not the same as FAIL)

Maybe remove/disable the test, or add retries? Maybe add detection for a
timeout failure and simply return a different value to warn about this?



signature.asc
Description: OpenPGP digital signature

Bug#924165: node-xmlhttprequest: broken symlink: /usr/lib/nodejs/xmlhttprequest/index.js -> XMLHttpRequest.js

[Andreas Beckmann]

Package: node-xmlhttprequest
Version: 1.8.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m23.7s ERROR: FAIL: Broken symlinks:
  /usr/lib/nodejs/xmlhttprequest/index.js -> XMLHttpRequest.js 
(node-xmlhttprequest)

You probably want to target lib/XMLHttpRequest.js instead.


cheers,

Andreas


node-xmlhttprequest_1.8.0-1.log.gz
Description: application/gzip

Bug#924164: Don't say use Jigdo

[積丹尼 Dan Jacobson]

Package: www.debian.org

On https://www.debian.org/CD/jigdo-cd :

See my comment at the end of bug #639937. Jigdo will not build 100%
correct CDs due to the index files often not being in 100% sync. So please
don't recommend it as a way to download Debian CDs. Else one will take
such CD to some remote mountain only to find parts missing so cannot
proceed with installation.

Bug#924163: node-libnpx: broken symlink: /usr/lib/nodejs/libnpx/node_modules/npm -> ../../npm

[Andreas Beckmann]

Package: node-libnpx
Version: 10.2.0+repack-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m27.1s ERROR: FAIL: Broken symlinks:
  /usr/lib/nodejs/libnpx/node_modules/npm -> ../../npm (node-libnpx)

Is node-libnpx missing a Depends/Recommends/Suggests: npm ?


cheers,

Andreas


node-libnpx_10.2.0+repack-1.log.gz
Description: application/gzip

Bug#639937: Don't tell people to use jigdo

[Steve McIntyre]

Hi Dan,

On Sun, Mar 10, 2019 at 07:52:22AM +0800, 積丹尼 Dan Jacobson wrote:
>So jigdo will build defective CDs with missing files,
>that one will only discover when one tries to use them?
>
>Some files will be present, others missing?
>
>--2019-03-10 07:45:52--  
>http://opensource.nchc.org.tw/debian/dists/sid/main/installer-amd64/20190118/images/netboot/debian-installer/amd64/grub/x86_64-efi/iorw.mod
>Reusing existing connection to opensource.nchc.org.tw:80.
>HTTP request sent, awaiting response... 200 OK
>Length: 4504 (4.4K)
>Saving to: 
>‘./debian-testing-amd64-netinst.iso.tmpdir/opensource.nchc.org.tw/debian/dists/sid/main/installer-amd64/20190118/images/netboot/debian-installer/amd64/grub/x86_64-efi/iorw.mod’
>
>opensource.nchc.org.tw/debian/dists/sid 
>100%[>]
>   4.40K  --.-KB/sin 0s  
>
>2019-03-10 07:45:53 (110 MB/s) - 
>‘./debian-testing-amd64-netinst.iso.tmpdir/opensource.nchc.org.tw/debian/dists/sid/main/installer-amd64/20190118/images/netboot/debian-installer/amd64/grub/x86_64-efi/iorw.mod’
> saved [4504/4504]
>
>--2019-03-10 07:45:53--  
>http://opensource.nchc.org.tw/debian/pool/main/g/gcc-8/libatomic1_8.2.0-21_amd64.deb
>Reusing existing connection to opensource.nchc.org.tw:80.
>HTTP request sent, awaiting response... 404 Not Found
>2019-03-10 07:45:53 ERROR 404: Not Found.
>
>--2019-03-10 07:45:53--  
>http://opensource.nchc.org.tw/debian/pool/main/libt/libtext-wrapi18n-perl/libtext-wrapi18n-perl_0.06-7.1_all.deb
>Reusing existing connection to opensource.nchc.org.tw:80.
>HTTP request sent, awaiting response... 200 OK
>Length: 8644 (8.4K) [application/x-debian-package]
>Saving to: 
>‘./debian-testing-amd64-netinst.iso.tmpdir/opensource.nchc.org.tw/debian/pool/main/libt/libtext-wrapi18n-perl/libtext-wrapi18n-perl_0.06-7.1_all.deb’
>
>opensource.nchc.org.tw/debian/pool/main 
>100%[>]
>   8.44K  --.-KB/sin 0s  

You don't show to the end of the log. Jigdo will switch to grabbing
missing files from snapshot.d.o once it has finished with all the
files it can find on the mirrors you've told it about.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Bug#918965: adequate tells about broken-symlink in quassel-data

[Andreas Beckmann]

On Fri, 15 Feb 2019 12:52:13 -0500 Scott Kitterman
 wrote:
> See the package Suggests.  This is intentional.

There is no package in sid that ships a mpris-quassel binary.


Andreas

Bug#919843: lirc-doc: broken symlinks: /usr/share/doc/lirc/lirc.org/* -> /build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/*

[Nicolas Braud-Santoni]

Control: tag -1 + patch pending

Dear maintainer,

On Sun, Jan 20, 2019 at 04:57:04AM +0100, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.

Given the lack of answer, I prepared a fixed version, and performed a NMU
to DELAYED/3, so you can dcut it should it be undesirable.

The changes were also submitted against the packaging repository:

  https://gitlab.com/leamas/lirc/merge_requests/1



Best,

  nicoo


signature.asc
Description: PGP signature

Bug#639937: Don't tell people to use jigdo

[積丹尼 Dan Jacobson]

So jigdo will build defective CDs with missing files,
that one will only discover when one tries to use them?

Some files will be present, others missing?

--2019-03-10 07:45:52--  
http://opensource.nchc.org.tw/debian/dists/sid/main/installer-amd64/20190118/images/netboot/debian-installer/amd64/grub/x86_64-efi/iorw.mod
Reusing existing connection to opensource.nchc.org.tw:80.
HTTP request sent, awaiting response... 200 OK
Length: 4504 (4.4K)
Saving to: 
‘./debian-testing-amd64-netinst.iso.tmpdir/opensource.nchc.org.tw/debian/dists/sid/main/installer-amd64/20190118/images/netboot/debian-installer/amd64/grub/x86_64-efi/iorw.mod’

opensource.nchc.org.tw/debian/dists/sid 
100%[>]
   4.40K  --.-KB/sin 0s  

2019-03-10 07:45:53 (110 MB/s) - 
‘./debian-testing-amd64-netinst.iso.tmpdir/opensource.nchc.org.tw/debian/dists/sid/main/installer-amd64/20190118/images/netboot/debian-installer/amd64/grub/x86_64-efi/iorw.mod’
 saved [4504/4504]

--2019-03-10 07:45:53--  
http://opensource.nchc.org.tw/debian/pool/main/g/gcc-8/libatomic1_8.2.0-21_amd64.deb
Reusing existing connection to opensource.nchc.org.tw:80.
HTTP request sent, awaiting response... 404 Not Found
2019-03-10 07:45:53 ERROR 404: Not Found.

--2019-03-10 07:45:53--  
http://opensource.nchc.org.tw/debian/pool/main/libt/libtext-wrapi18n-perl/libtext-wrapi18n-perl_0.06-7.1_all.deb
Reusing existing connection to opensource.nchc.org.tw:80.
HTTP request sent, awaiting response... 200 OK
Length: 8644 (8.4K) [application/x-debian-package]
Saving to: 
‘./debian-testing-amd64-netinst.iso.tmpdir/opensource.nchc.org.tw/debian/pool/main/libt/libtext-wrapi18n-perl/libtext-wrapi18n-perl_0.06-7.1_all.deb’

opensource.nchc.org.tw/debian/pool/main 
100%[>]
   8.44K  --.-KB/sin 0s  

Bug#922370: libreoffice: Libreoffice duplicated global menu on plasma desktop

[Filipe Mosca]

Hi !! Sorry for the delay. I was not notified by your answer.
The problem still persists. I tried to install a flatpak but the same
occurs.

> Does the presence of libreoffice-kde5 make a difference (which is
> in 6.1.x bascially a disguiseed gtk3 with a kde5 file picker)? I see
> below you have it installed (-kde being for kde4 in stretch gets
> replaced with that one.)

> Does it also happen with -kde5 from 6.2.0 (which has a "native" KDE5
plugin
> instead of that gtk3 thingy.)

So i need to unnintastal libreoffice-kde5 ?

New link to the image https://imgur.com/a/C65Cib9

I discovered the same bug report in bugs.kde:
https://bugs.kde.org/show_bug.cgi?id=402044

Bug#924162: libodb-api-dev: broken symlinks: /usr/lib//lib{odbemos,odb,Odbmigrator}.so -> lib{odbemos,odb,Odbmigrator}.0d

[Andreas Beckmann]

Package: libodb-api-dev
Version: 0.18.1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m45.0s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/libodbemos.so -> libodbemos.0d 
(libodb-api-dev:amd64)
  /usr/lib/x86_64-linux-gnu/libodb.so -> libodb.0d (libodb-api-dev:amd64)
  /usr/lib/x86_64-linux-gnu/libOdbmigrator.so -> libOdbmigrator.0d 
(libodb-api-dev:amd64)

You probably wanted to target lib*.so.0d instead.


cheers,

Andreas


libodb-api-dev_0.18.1-4.log.gz
Description: application/gzip

Bug#924161: unblock: lirc/0.10.1-5.1

[Nicolas Braud-Santoni]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: block 919843 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

Please unblock package lirc, as I fixed an RC bug.
Note that the upload was to DELAYED/3, as it is a NMU.


Best,

  nicoo


diff -Nru lirc-0.10.1/debian/changelog lirc-0.10.1/debian/changelog
- --- lirc-0.10.1/debian/changelog2019-01-01 15:19:01.0 +0100
+++ lirc-0.10.1/debian/changelog2019-03-10 00:28:01.0 +0100
@@ -1,3 +1,18 @@
+lirc (0.10.1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * debian/rules: Replace rdfind-based dedup with dh_installdocs --link-doc
+This achieves the same effect (copyright, changelog, ... aren't duplicated)
+cleanly and without RC-buggyness.  (Closes: #919843)
+
+  * debian/control: Fix relationships on liblirc{,client}-dev.
+This should be Breaks+Replaces, not Conflict+Replaces.
+Using the former should ensure that upgrading from stretch works smoothly.
+
+  * debian/changelog: Fix spelling in v0.10.1-4
+
+ -- Nicolas Braud-Santoni   Sun, 10 Mar 2019 00:28:01 +0100
+
 lirc (0.10.1-5) unstable; urgency=medium
 
   * Fix upstream #343, --connect parsing error.
@@ -11,7 +26,7 @@
 lirc (0.10.1-4) unstable; urgency=medium
 
   [ Alec Leamas ]
- -  * Dont use broken LOG_CONS syslog flag, closes: #872749.
+  * Don't use broken LOG_CONS syslog flag, closes: #872749.
 
   [ Pino Toscano ]
   * Fix build on !linux OS, restrict systemd only to linux OS. closes: #912400
diff -Nru lirc-0.10.1/debian/control lirc-0.10.1/debian/control
- --- lirc-0.10.1/debian/control  2019-01-01 15:19:01.0 +0100
+++ lirc-0.10.1/debian/control  2019-03-10 00:28:01.0 +0100
@@ -29,7 +29,6 @@
  python3-dev (>= 3.5),
  python3-setuptools,
  python3-yaml,
- - rdfind,
  socat [!hurd-any],
  systemd [linux-any],
  xsltproc
@@ -128,7 +127,7 @@
 #Multi-Arch: same
 Section: libdevel
 Provides: liblircclient-dev
- -Conflicts: liblircclient-dev (<< 0.9.1)
+Breaks: liblircclient-dev (<< 0.9.1)
 Replaces: liblircclient-dev (<< 0.9.1)
 Depends:
  liblirc0 (= ${binary:Version}),
diff -Nru lirc-0.10.1/debian/rules lirc-0.10.1/debian/rules
- --- lirc-0.10.1/debian/rules2019-01-01 15:19:01.0 +0100
+++ lirc-0.10.1/debian/rules2019-03-10 00:28:01.0 +0100
@@ -46,8 +46,6 @@
for f in lircd.conf lircmd.conf irexec.lircrc lirc_options.conf; do \
mv debian/tmp/etc/lirc/$$f debian/tmp/etc/lirc/$$f.dist; \
done
- -   # De-duplicate docs
- -   rdfind -makesymlinks true debian/tmp/usr/share/doc/lirc
 
 override_dh_auto_test:
 ifneq "nocheck"  "$(findstring nocheck,$(DEB_BUILD_OPTIONS))"
@@ -64,6 +62,10 @@
 endif
 
 
+override_dh_installdocs:
+   dh_installdocs --link-doc=lirc -a
+   dh_installdocs -p lirc-doc
+
 override_dh_installsystemd:
 ifeq ($(DEB_BUILD_ARCH_OS), linux)
dh_installsystemd -p lirc lircd.socket


unblock lirc/0.10.1-5.1

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAlyETwkRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MtsZw//VaakF1WKmQZogNQgcC4iyvFE1c6e4fue
HlsHGiJonBOh259DkJUiWDrkGWXB8FdKfg8tmOmiMatwEloahHajjY+32RYglVgi
9sWIbTWE8GBv4Qe4P3epKWby2TR8zzz/gS8i35oKlQL/ikpyl0LBBHvDgr3drvbo
HatUrqjcwIAkA0ANE0Qc3CD/mk40R+YQldq9K8x7SwPdPvqOR1SuWbFd99ykfVc3
pKGEjMgjtYW9+0DAKn4/CrfunkN9EXVdUK4QIZLhnUa7Rp8CkdNWO76l+oHZ5mv4
lfNtO7qcvPRPMrIigxg5lzE3xIJgjcsmE6O8+7YhkQZf+EEO9KoifQl8qLVe6ZxR
qtG45tx6oVruf9iNTMAVu8f3Ph3x/BllCgg/9wK04YP69yvoxIxUwjB0wX07jXgz
OoqRzbuz8pzGyUTWqqUmc7yvmHmSzNf9tfuqcNAhUhDR7XMRLl5YuP71v7jP1vfC
42OSyKbP8MHSaiCAkAoDQbNQMlUyXXRjKXOotn1a70aa9d7EweDRonLS+FbQIPRM
waYpSBUIw41lQqQk+Zzq2PhMG/AHbDurT7q0QmPKu4aRpBUcpepmOwxJjcLvYmD3
werZS5tu2SCjtlVoeILxFOQBTQPTTqpV+AzMuDrC2+l0LGIP0Ge3W66oRisQPqyf
66uMn3mRtjw=
=kQuD
-END PGP SIGNATURE-

Bug#865999: [exiv2] Please package exiv2 0.26

[Richard B. Kreckel]

On Tue, 26 Sep 2017 17:56:57 +0200 Raphael Hertzog 
wrote:
> Except that version 0.26 is vulnerable to multiple security issues which
> are currently not present in earlier versions [...]
Raphaël, what makes you sure that these CVEs are not present in earlier
versions (e.g. in 0.25 currently in testing)?

They were reported against 0.26 because that version was fuzzed, that's
all, AFICT.

  -richy.
-- 
Richard B. Kreckel

Bug#924160: libjs-markdown-it-html5-embed: broken symlinks: /usr/share/doc/libjs-markdown-it-html5-embed/*.HISTORY.md -> node_modules/*/HISTORY.md

[Andreas Beckmann]

Package: libjs-markdown-it-html5-embed
Version: 1.0.0+ds-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m17.6s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libjs-markdown-it-html5-embed/mimoza.HISTORY.md -> 
node_modules/mimoza/HISTORY.md (libjs-markdown-it-html5-embed)
  /usr/share/doc/libjs-markdown-it-html5-embed/mime-db.HISTORY.md -> 
node_modules/mime-db/HISTORY.md (libjs-markdown-it-html5-embed)

The target files do not seem to exist in any package in sid.


cheers,

Andreas


libjs-markdown-it-html5-embed_1.0.0+ds-2.log.gz
Description: application/gzip

Bug#914006: exiv2: Please package version 0.27

[Richard B. Kreckel]

It looks like I forgot one grave bug:
#62 (CVE-2018-5772) 

But that's also fixed in 0.27.0.

  -richy.
-- 
Richard B. Kreckel

Bug#915706: 9.6.0 DVD and XFCE CD for mipsel are actually netinst

[Steve McIntyre]

Control: reassign -1 cdimage.debian.org
Control: severity -1 important

On Thu, Dec 06, 2018 at 05:54:51PM +0800, seam...@debian.org wrote:
>Package: debian-installer
>Severity: serious
>
>I tried "debian-9.6.0-mipsel-xfce-CD-1.iso" and 
>"debian-9.6.0-mipsel-DVD-1.iso" on QEMU and found that both images are 
>actually "netinst" variant. After I chose my country and defined the hostname, 
>the installer forced me to choose a mirror. After that it started downloading 
>components of the installer from the mirror and ignores the many preloaded 
>packages inside the CD/DVD.
>
>This should be consider "unusable" because the nature of the artifacts has 
>changed.

Hi!

How did you make this work with qemu on mipsel? I've tried a little
and I can't get very far. We've not had useful installation media for
mipsel for a very long time - patches welcome...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

Bug#924159: android-libcutils-dev: broken symlink: /usr/include/android/cutils/android_filesystem_config.h -> ../private/android_filesystem_config.h

[Andreas Beckmann]

Package: android-libcutils-dev
Version: 1:8.1.0+r23-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m19.7s ERROR: FAIL: Broken symlinks:
  /usr/include/android/cutils/android_filesystem_config.h -> 
../private/android_filesystem_config.h (android-libcutils-dev)

Is android-libcutils-dev missing a dependency on
android-platform-system-core-headers?


cheers,

Andreas


android-libcutils-dev_1:8.1.0+r23-4.log.gz
Description: application/gzip

Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)

[Thorsten Glaser]

On Sat, 9 Mar 2019, Pierre Ynard wrote:

> /fastboot and /forcefsck are created by `shutdown -f` and `shutdown -F`

Oh, I didn’t know that, I just sudo touch them as used to on Unix.

> the shutdown binary, it could create /forcefsck or /run/forcefsck, which

/run is a tmpfs.

> would then be checked by a script in runlevel 0 or 6 that calls tune2fs
> on the relevant filesystems.

Oh, no, please don’t call tune2fs automatically from anything EVER.
Way too dangerous/invasive/… especially when you temporarily have
a disc setup that differs from your fstab.

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#914006: exiv2: Please package version 0.27

[Richard B. Kreckel]

On Sun, 18 Nov 2018 06:47:43 -0500 Jeremy Bicha  wrote:
> There is a new exiv2 0.27 RC2 tarball release. Could you look into
> whether it fixes the security issues from 0.26 and would be acceptable
> for unstable?

I just went through all Debian bug reports associated with CVEs.
As far as I can see, upstream has fixed them all in exiv2 0.27.0.

Grave bugs:
#876242 (CVE-2017-12957) 
#880027 (CVE-2017-14861) 
#880015 (CVE-2017-14866) 
#63 (CVE-2017-1000127) 
#64 (CVE-2017-1000126) 
#65 (CVE-2017-14865) 
#66 (CVE-2017-14863) 
#67 (CVE-2017-14860) 
#69 (CVE-2017-14857) 
#72 (CVE-2017-12956) 
#73 (CVE-2017-12955) 
#74 (CVE-2017-11553) 
#894179 (CVE-2018-8977) 
#903763 (CVE-2018-14046) 
#912828 (CVE-2018-18915) 
#915134 (CVE-2018-19607) 
#923472 (CVE-2019-9143) 
#923473 (CVE-2019-9144) 

Important bugs:
#886006 (CVE-2017-17669) 
#886962 (CVE-2018-4868) 
#891044 (CVE-2017-17722) 
#891783 (CVE-2017-17724) 
#895568 (CVE-2017-11592) 
#897260 (CVE-2017-1000128) 
#903813 (CVE-2018-8976) 
#910060 (CVE-2018-17581) 
#910909 (CVE-2018-9145) 
#913272 (CVE-2018-19108) 
#913273 (CVE-2018-19107) 
#915135 (CVE-2018-19535) 
#916081 (CVE-2018-16336) 

This looks good to me!

  -richy.

Bug#924158: lirc shoud byte-compile its Python modules in postinst

[Nicolas Braud-Santoni]

Source: lirc
Version: 0.10.1-5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

Per the Debian Python policy [0], lirc should be automatically byte-compiling
its installed Python modules.

I'm not sure why it's not done automatically by dh-python in your package,
though I expect the right maintscript is injected in a phase that you overrode.


Best,

  nicoo


[0]: 
https://www.debian.org/doc/packaging-manuals/python-policy/module_packages.html#byte_compilation

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAlyEStsRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MtDwg//Scj2c7jQ+cMzq+9my0VVrLnV6ZfAG1Pf
nID5/eveTb7+zH4LMx3av91/l9B2kkM3TfLR3rDIJqQNniV0OUf6AnkwAqiiK1Yn
ghrLQ9RfcI0b4tVIMC6TYYHHcfv7V1mjLe46wEOEbcL369Sy7HK9lvQoId3QFpVc
07GiiCwvA47ctW7HW2j/l62//2ULpDIfKYohgH/AyCfbwv1qvEoWvB2bxTVIKnfE
HskyzMaMwDPd3Md4W3leiiYj4//n3PEUCH4ucvXbAO7B0pe7UmHdgchPY/7V30iH
BnlGcfiBlAXduk0j203hp8sLSBOkFTh7kMJZCh3UxrUYVXrNWHEdgal9rYxTPjjz
dtB/EaeWLbd8O5481JQv5gnYhkQTeUayVDJDWQZFyZYndtA5ZcVhOuBjHflK/aLG
ZHH2u+VbsGg/i4LyIT6d3gOykaDYUqJXHtNjb+BZBWFelkuHuBS3Tmg3HM01vtdJ
c9YEvOnY3QaLBzA+6dV4NfW0lAkzDBsifknWqo8Ch+3y1trdzuC+Mid61aJ7Rvu7
MAHSVNa/E3IgfFtIUkjQ4npW6S8YvoPrlY+eyJv4TvsUFrL5h9Yt+j/WYX8Nmne/
GFZq9PUZc8YcMKTEAToHOIa/wPmehddH3tn6vYiaFsjVFQSbqmf2zRPq9t7FvvGD
OldzCUP8o1U=
=My4/
-END PGP SIGNATURE-

Bug#863601: systemd-notify doesn't work because of race condition

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/2739

On Thu, 1 Jun 2017 17:50:27 +0200 Michael Biebl  wrote:
> On Mon, 29 May 2017 09:20:52 +0200
> =?UTF-8?B?0JDQvdC00YDQtdC5INCU0L7RhtC10L3QutC+?= 
> wrote:
> > Package: systemd
> > Version: 232
> > 
> > I used unit-file with options below:
> > 
> > Type=notify
> > NotifyAccess=all
> > 
> > Command `systemd-notify --ready` worked only once. All other times it did
> > nothing. Service was killed by systemd after timeout. systemd-notify
> > returned zero code (success). No error was reported.
> > 
> > Workaround script I used to solve the issue:
> > 
> > inport systemd.daemon;
> > systemd.daemon.notify('READY=1')
> > 
> > Another bug report might describe the same issue:
> > https://bugzilla.redhat.com/show_bug.cgi?id=982376
> > But in my case everything works without any sleeps.
> 
> Can you please share the complete unit file and the script you used so
> we have a minimal test case to reproduce the issue.

I tried the test service that was linked in the bugzilla bug report but
was not able to reproduce the issue.
Do you still see the problem with a recent version of systemd?

That said, I suppose the referenced upstream bug report is about the
same issue and still marked as unfixed. So tentatively marking the bug
as forwarded.

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#924120: Say "netinst multi-arch CD images"

[積丹尼 Dan Jacobson]

Well all I know is we think they must be in contrast to the other items
listed.

> "HW" == Holger Wansing  writes:
HW> Hi,

HW> 積丹尼 Dan Jacobson  wrote:
>> Package: www.debian.org
>> 
>> On https://www.debian.org/devel/debian-installer/
>> After "Current daily snapshots" say
>> "netinst multi-arch CD images"
>> Not just
>> "multi-arch CD images".
>> 

HW> The "multi-arch CD images" is - as first - the definition of a group of 
images,
HW> or say a category.
HW> Currently, there is only the netinst image in that category, but maybe there
HW> are more multi-arch images to come in the future?

HW> If that happens, the label would then be no longer correct now.

Bug#924155: icewm-common: broken symlink: /usr/share/doc/icewm-common/FAQ/index.html -> IceWM-FAQ.html

[Andreas Beckmann]

Package: icewm-common
Version: 1.4.3.0~pre-20181030-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m42.9s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/icewm-common/FAQ/index.html -> IceWM-FAQ.html (icewm-common)

IceWM-FAQ.html does not seem to exist in any package in sid.


cheers,

Andreas


icewm-common_1.4.3.0~pre-20181030-2.log.gz
Description: application/gzip

Bug#912445: RM: openhft-chronicle-threads/1.1.6-1

[Andrej Shadura]

Control: clone -1 -2
Control: reassign -2 release.debian.org
Control: tags -2 = buster
Control: retitle -2 RM: RM: openhft-chronicle-threads/1.1.6-1

On Wed, 31 Oct 2018 18:33:17 +0200 Adrian Bunk  wrote:
> Source: openhft-chronicle-threads
> Version: 1.1.6-1
> Severity: serious
> Tags: ftbfs buster sid
> Control: fixed -1 1.16.3-1
> Control: close -1
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/openhft-chronicle-threads.html
> 
> ...
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 2.711 s
> [INFO] Finished at: 2019-12-02T18:25:38-12:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile 
> (default-compile) on project chronicle-threads: Compilation failure: 
> Compilation failure: 
> [ERROR] 
> /build/1st/openhft-chronicle-threads-1.1.6/src/main/java/net/openhft/chronicle/threads/MonitorEventLoop.java:[28,20]
>  package javax.xml.ws does not exist
> [ERROR] 
> /build/1st/openhft-chronicle-threads-1.1.6/src/main/java/net/openhft/chronicle/threads/MonitorEventLoop.java:[123,32]
>  cannot find symbol
> [ERROR]   symbol:   class WebServiceException
> [ERROR]   location: class net.openhft.chronicle.threads.MonitorEventLoop
> [ERROR] -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp 
> /usr/share/maven/boot/plexus-classworlds-2.x.jar 
> -Dmaven.home=/usr/share/maven 
> -Dmaven.multiModuleProjectDirectory=/build/1st/openhft-chronicle-threads-1.1.6
>  -Dclassworlds.conf=/etc/maven/m2-debian.conf 
> -Dproperties.file.manual=/build/1st/openhft-chronicle-threads-1.1.6/debian/maven.properties
>  org.codehaus.plexus.classworlds.launcher.Launcher 
> -s/etc/maven/settings-debian.xml 
> -Ddebian.dir=/build/1st/openhft-chronicle-threads-1.1.6/debian 
> -Dmaven.repo.local=/build/1st/openhft-chronicle-threads-1.1.6/debian/maven-repo
>  --batch-mode package -DskipTests -Dnotimestamp=true -Dlocale=en_US returned 
> exit code 1
> make: *** [debian/rules:4: build] Error 1

> This bug is already fixed in experimental.

Same as with openhft-chronicle-wire, this package is very broken and
there’s very little chance anyone finds enough time to actually fix it.
Please remove it from testing.

-- 
Cheers,
  Andrej

Bug#893498: RM: openhft-chronicle-wire/1.1.13-1

[Andrej Shadura]

Control: clone -1 -2
Control: reassign -2 release.debian.org
Control: tags -2 = buster
Control: retitle -2 RM: openhft-chronicle-wire/1.1.13-1

Please remove openhft-chronicle-wire from testing, I don’t see any
chance of us properly solving this for Buster.

-- 
Cheers,
  Andrej

Bug#915678: gcc-x86-64-linux-gnux32: broken symlink: /usr/share/doc/gcc-x86_64-linux-gnux32 -> cpp-x86_64-linux-gnux32 (gcc-x86-64-linux-gnux32)

[Andreas Beckmann]

Followup-For: Bug #915678
Control: found -1 4:8.3.0-1
Control: found -1 g++-x86-64-linux-gnux32/4:8.3.0-1
Control: affects -1 + g++-x86-64-linux-gnux32

Hi,

this invalid symlink is still present in some packages:

0m28.0s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/g++-x86_64-linux-gnux32 -> cpp-x86_64-linux-gnux32 
(g++-x86-64-linux-gnux32)


Andreas

Bug#867590: networkd removes statically set default route when RA expires

[Michael Biebl]

Hi Marc

On Fri, 07 Jul 2017 17:52:04 +0200 Marc Haber
 wrote:
> Package: systemd
> Version: 232-25
> Severity: normal
> Tags: ipv6
> 
> Hi,
> 
> I do have a system with systemd-networkd. IPv6AcceptRA is set to 1,
> which is not strictly needed, but I can easily dream up a use case
> where this is actually useful.
> 
> In the .network unit file, I have an IPv6 Gateway set statically:
> 
> [1/847]mh@milonga:~ $ cat /etc/systemd/network/milonga.network
> [Match]
> Name=e*
> 
> [Network]
> Gateway=2001:db8::1
> IPv6AcceptRA=yes
> DHCP=no
> 
> [Address]
> Address=2001:db8::43:100/64
> 
> When this system boots, it learns IPv6 default gateways from a HSRP
> pair of routers, resulting in this routing table:
> 
> 2001:67c:24f8:1002::/64 dev eth0 proto kernel metric 256  pref medium
> 2001:67c:24f8:1002::/64 dev eth0 proto ra metric 1024  pref medium
> fe80::/64 dev eth0 proto kernel metric 256  pref medium
> default metric 1024 
> nexthop via 2001:67c:24f8:1002::1  dev eth0 weight 1
> nexthop via fe80::21d:70ff:fe9f:65a0  dev eth0 weight 1
> nexthop via fe80::21e:13ff:fe22:b510  dev eth0 weight 1
> 
> I am not sure whether it has any negative effects that the /64 route
> is entered twice.
> 
> The HSRP pair of routers has RA disabled. It will, however, answer
> router solicitations, a behavior which cannot be turned off on Cisco
> devices.
> 
> When the SLAAC learned IP address and routes expire, systemd-networkd
> removes the statically set default route as well, leaving the system
> without IPv6 connectivity outside the local network.
> 
> Expected behavior would be to leave the statically set route in place.
> 
> A workaround is setting IPv6AcceptRA=no, but this means that even after
> sending a router announcement, the system will not learn a new IP
> address. Sending out a router announcement is a frequently used trick to
> access a system whose network init has failed in some way and therefore
> the static IP address failed to show up.


Is this still an issue with 241-1 from unstable?
If so, it would be great if you can file a bug report upstream at
https://github.com/systemd/systemd/issues
Unfortunately I don't have a network setup where I could easily
reproduce the issue myself so it's better if you talk to upstream directly.

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#888222: systemd: invalid mount order of btrfs subvolumes after apt upgrade and reboot

[Michael Biebl]

Control: tags -1 + moreinfo

On Fri, 16 Nov 2018 00:52:56 +0100 Michael Biebl  wrote:
> Hi
> 
> On Tue, 23 Jan 2018 19:39:29 -0500 "LeJacq, Jean Pierre"
>  wrote:
> > Package: systemd
> > Version: 236-3~bpo9+1

This version is rather old, could you please try with v241 and report back

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#920234: systemd: insufficient log options when there is a bad /etc/crypttab entry

[Michael Biebl]

On Wed, 23 Jan 2019 11:42:57 +1100 Russell Coker 
wrote:
> Package: systemd
> Version: 240-4
> Severity: normal
> 
> When I have a bogus /etc/crypttab entry (for example when converting an
> encrypted laptop to a virtual machine that's not encrypted) the boot process
> hangs for 90 seconds for no obvious reason.
> 
> [**] A start job is running for /dev/dis·9597-dbdb2fedbd1f (24s / 1min 
> 30s)
> 
> When seeing the above anyone who doesn't know that "grep -R dbdb2fedbd1f /etc"
> is necessary will have trouble determining the cause of this.
> 
> # systemd-analyze blame
> Bootup is not yet finished 
> (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
> Please try again later.
> Hint: Use 'systemctl list-jobs' to see active jobs
> # systemctl list-jobs
> JOB UNIT   TYPE  
> STATE  
> 181 dev-disk-by\x2duuid-…75\x2d410c\x2d9597\x2ddbdb2fedbd1f.device start 
> running
> 179 systemd-cryptsetup@nvme0n1p2_crypt.service start 
> waiting

Can you provide the journal -alb log from such a boot?

-- 
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#920446: tries to rename VLAN interface

[Michael Biebl]

Hi Marc

On Fri, 25 Jan 2019 17:10:55 +0100 Marc Haber
 wrote:
> Package: systemd
> Version: 240-4
> Severity: normal
> File: systemd-networkd
> 
> Hi,
> 
> On my desktop computer, I run some VMs and am using systemd-networkd.
> The machine has its 'own' network untagged on the ethernet and the VM
> network tagged.
> 
> I have code to rename my ethernet interface to lanc0 to have consistent
> interface naming across my machines:

If this is still a problem with v241, would you mind filing a bug report
upstream at https://github.com/systemd/systemd

I would forward the bug report myself if I had a setup where I can
reproduce the issue. Unfortunately this is not the case.

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#924154: swi-prolog-x: broken symlink: /usr/lib/swi-prolog/xpce.rc -> xpce/pl/xpce.rc

[Andreas Beckmann]

Package: swi-prolog-x
Version: 8.0.2+dfsg-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m11.7s ERROR: FAIL: Broken symlinks:
  /usr/lib/swi-prolog/xpce.rc -> xpce/pl/xpce.rc (swi-prolog-x)

xpce.rc does not exist in any package in sid.


cheers,

Andreas


swi-prolog-x_8.0.2+dfsg-1.log.gz
Description: application/gzip

Bug#924153: novnc: broken symlink: /usr/share/novnc/include/web-socket-js-project/swfobject.js -> ../../../javascript/swfobject/swfobject.js

[Andreas Beckmann]

Package: novnc
Version: 1:1.0.0-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m33.6s ERROR: FAIL: Broken symlinks:
  /usr/share/novnc/include/web-socket-js-project/swfobject.js -> 
../../../javascript/swfobject/swfobject.js (novnc)

swfobject.js is gone from sid.


cheers,

Andreas


novnc_1:1.0.0-1.log.gz
Description: application/gzip

Bug#924129: debian-installer: Kernel for armhf for stretch unbootable

[Vagrant Cascadian]

On 2019-03-09, Cyril Brulebois wrote:
> Peter Lebbing  (2019-03-09):
>> Debian kernel bug #922478 renders armhf systems unbootable. This bug was
>> fixed, but the debian-installer images still use (I presume) kernel
>> version 4.9.144-3, the unbootable version. I noticed this today while
>> trying to install a new system using:
>> 
>> http://http.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/firmware.Wandboard.img.gz
>> 
>> The installer worked when I overwrote the /vmlinuz in that image with
>> the one from the new 4.9.144-3.1.

Thanks for that specific piece of information; I was hoping to confirm
that myself shortly, but that's promising.


> Thanks for your report; that's known and fixed on the kernel side
> already; how to deal with d-i is discussed in:
>   https://lists.debian.org/debian-boot/2019/03/msg00165.html
>
> Currently waiting on some input from Vagrant:
>   https://lists.debian.org/debian-boot/2019/03/msg00179.html

Sorry to keep folks waiting...


live well,
  vagrant

Bug#924152: node-cacache: broken symlink: /usr/share/doc/node-cacache/figgy-pudding.CHANGELOG.md -> ../figgy-pudding/CHANGELOG.md

[Andreas Beckmann]

Package: node-cacache
Version: 11.3.2-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m22.3s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/node-cacache/figgy-pudding.CHANGELOG.md -> 
../figgy-pudding/CHANGELOG.md (node-cacache)


cheers,

Andreas


node-cacache_11.3.2-2.log.gz
Description: application/gzip

Bug#923037: Acknowledgement (Please package new upstream version 2.5.x, or from git)

[Ian Jackson]

I needed to use a newer version of this library myself.  I didn't have
time to do a proper update but I did manage to produce a thing that
builds.  It is Really Not Very Good.

But I thought I would share the horrible thing I did anyway.  It can
be found here:

 
https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=nlopt.git;a=shortlog;h=refs/heads/glerk
 git://git.chiark.greenend.org.uk/~ianmdlvl/nlopt.git

It's in the branch `glerk'.  That is on top of the result of `dgit
clone' followed by `git-debrebase convert-from-dgit-view' followed by
`git-debrebase new-upstream'.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#924151: grub2-common: wrong grub.cfg for efi boot and fully encrypted disk

[Joerg Jaspert]

Package: grub2-common
Version: 2.02+dfsg1-11
Severity: grave

Dear Maintainer,

I'm unsure about the severity, so feel free to adjust it. But it did
make my system unbootable twice already, and as its a setup one can
get directly from within debian-installer, it would be nice if it can be
fixed before buster.

Setup: A new buster install with a fully (except for the EFI partition)
encrypted disk. That includes /boot as encrypted, as /boot is just part
of / here. In that setup, grub-install writes a
/boot/efi/EFI/debian/grub.cfg that contains something like

--8<---cut here---start->8---
cryptomount -u e37941013b6c4997bfcdff6145ee0918
search.fs_uuid a6cd673c-de1d-474f-8808-2ae4fdc7e755 root 
lvmid/0l70u1-APaW-hXej-Sn6a-Nnsb-ue1X-0cFW3Y/APpMrR-2yO8-7EOl-V1pi-DH3a-eNby-lwWX3K 
set prefix=($root)'/boot/grub'

configfile $prefix/grub.cfg
--8<---cut here---end--->8---

Which tries to be clever to not duplicate the actual information in
grub.cfg by loading it from the usual /boot/grub/grub.cfg place.

Unfortunately the cryptomount line above appears to *not* be enough to
enable grub to decrypt /, so it can not load the real config and you end
up in a rather unusable tiny grub shell. Ugh.

A cp /boot/grub/grub.cfg /boot/efi/EFI/debian/grub.cfg fixes it and
makes it nicely bootable. No idea which of the many extra commands in
the full grub.cfg are doing the magic, but they do. grub asks for
passphrase, then takes ages (easily 45 seconds) to decrypt, then shows
grub menu and boots. Yay.

I do get the same small efi grub.cfg again if i run another grub-install
--efi-directory=/boot/efi/EFI/debian/ so I guess it comes from there.

-- Package-specific info:


*** BEGIN /proc/mounts
/dev/mapper/lennier-root / ext4 rw,relatime,discard,errors=remount-ro 0 0
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 
0 0

*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
 set have_grubenv=true
 load_env
fi
if [ "${next_entry}" ] ; then
  set default="${next_entry}"
  set next_entry=
  save_env next_entry
  set boot_once=true
else
  set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
 menuentry_id_option="--id"
else
 menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
 set saved_entry="${prev_saved_entry}"
 save_env saved_entry
 set prev_saved_entry=
 save_env prev_saved_entry
 set boot_once=true
fi

function savedefault {
 if [ -z "${boot_once}" ]; then
   saved_entry="${chosen}"
   save_env saved_entry
 fi
}
function load_video {
 if [ x$feature_all_video_module = xy ]; then
   insmod all_video
 else
   insmod efi_gop
   insmod efi_uga
   insmod ieee1275_fb
   insmod vbe
   insmod vga
   insmod video_bochs
   insmod video_cirrus
 fi
}

insmod part_gpt
insmod fat
if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root  FAAB-1A17
else
 search --no-floppy --fs-uuid --set=root FAAB-1A17
fi
if loadfont /EFI/debian/grubfont.pf2 ; then
 set gfxmode=auto
 load_video
 insmod gfxterm
 set locale_dir=$prefix/locale
 set lang=de_DE
 insmod gettext
fi
terminal_input gfxterm
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
 set timeout=30
else
 if [ x$feature_timeout_style = xy ] ; then
   set timeout_style=menu
   set timeout=5
 # Fallback normal timeout code in case the timeout_style feature is
 # unavailable.
 else
   set timeout=5
 fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod lvm
insmod ext2
cryptomount -u e37941013b6c4997bfcdff6145ee0918
set 
root='lvmid/0l70u1-APaW-hXej-Sn6a-Nnsb-ue1X-0cFW3Y/APpMrR-2yO8-7EOl-V1pi-DH3a-eNby-lwWX3K'

if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root 
 --hint='lvmid/0l70u1-APaW-hXej-Sn6a-Nnsb-ue1X-0cFW3Y/APpMrR-2yO8-7EOl-V1pi-DH3a-eNby-lwWX3K' 
 a6cd673c-de1d-474f-8808-2ae4fdc7e755

else
 search --no-floppy --fs-uuid --set=root a6cd673c-de1d-474f-8808-2ae4fdc7e755
fi
insmod png
if background_image 
/usr/share/desktop-base/futureprototype-theme/grub/grub-16x9.png; then

 set color_normal=white/black
 set color_highlight=black/white
else
 set menu_color_normal=cyan/blue
 set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 

Bug#923678: [Pkg-javascript-devel] Bug#923678: libjs-leaflet-markercluster: not a transitional package for apt

[Jonas Smedegaard]

control: reassign -1 ftp.debian.org
control: retitle -1 libjs-leaflet-markercluster: section field out of sync

Quoting Thorsten Glaser (2019-03-03 19:21:42)
> When removing the libjs-leaflet-markercluster “transitional” package,
> apt also clears the new one for removal:
[...]
> This is because libjs-leaflet-markercluster is not in Section oldlibs
> (used to also require Priority extra, but please recheck with apt docs).
> 
> Proper transitional packages make apt transfer the “manually installed”
> bit to the depended-on packages.

Hi ftpmasters,

Please update section field in apt to match package control field for 
libjs-leaflet-markercluster.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#923674: systemd: test-stat-util fails with SIGABRT when /dev/random is bind-mounted from /dev/urandom

[Santiago Vila]

> from those references:
> "You should consider adding more entropy rather than compromising your
> system."
> or
> "One simple way (which I don't really suggest)"

Oh, sure, and maybe also "only do it if you know what you are doing".

I'm using sbuild, and the bind-mount is only performed in the chroots
being used to build packages, not in the host system.

The host systems, additionally, are only used to test package building.

I think that's safe enough.

Thanks.

Bug#882473: ruby-httpclient FTBFS and Debci failure: test_verification_without_httpclient fails

[Chris Lamb]

Hi,

> ruby-httpclient FTBFS and Debci failure: test_verification_without_httpclient 
> fails

This is likely another OpenSSL 1.1 incompatibility wrt. SHA1
signatures.


Regards,

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

Bug#924138: unblock: libnet-duo-perl/1.02-1

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Sat, Mar 09, 2019 at 12:44:59PM -0800, Russ Allbery wrote:
> * Upload 1.02-1 to unstable and have you unblock that for propagation to
>   testing as a regular package update?  This is a leaf package, so I'm
>   pretty confident that this should be safe, but it has extraneous changes
>   compared to only fixing this bug.

This one please; and then remove moreinfo from this bug when it's ready to
unblock.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#918309: sphinxcontrib-programoutput: Please update to v0.13 that is compatible with Sphinx 1.8

[Chris Lamb]

tags 918309 + pending patch
thanks

I've uploaded sphinxcontrib-programoutput 0.11-3.1 to DELAYED/5:
  
  sphinxcontrib-programoutput (0.11-3.1) unstable; urgency=medium
  
* Non-maintainer upload.
* Fix FTBFS with Sphinx 1.8 by backporting patch from upstream.
  (Closes: #918309)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for sphinxcontrib-programoutput-0.11 sphinxcontrib-programoutput-0.11

 changelog  |8 ++
 patches/fix-tests-for-sphinx-1.8.patch |   38 +
 patches/series |1 
 3 files changed, 47 insertions(+)

diff -Nru sphinxcontrib-programoutput-0.11/debian/changelog 
sphinxcontrib-programoutput-0.11/debian/changelog
--- sphinxcontrib-programoutput-0.11/debian/changelog   2018-01-21 
14:01:43.0 +
+++ sphinxcontrib-programoutput-0.11/debian/changelog   2019-03-09 
22:26:13.0 +
@@ -1,3 +1,11 @@
+sphinxcontrib-programoutput (0.11-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with Sphinx 1.8 by backporting patch from upstream.
+(Closes: #918309)
+
+ -- Chris Lamb   Sat, 09 Mar 2019 22:26:13 +
+
 sphinxcontrib-programoutput (0.11-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
sphinxcontrib-programoutput-0.11/debian/patches/fix-tests-for-sphinx-1.8.patch 
sphinxcontrib-programoutput-0.11/debian/patches/fix-tests-for-sphinx-1.8.patch
--- 
sphinxcontrib-programoutput-0.11/debian/patches/fix-tests-for-sphinx-1.8.patch  
1970-01-01 01:00:00.0 +0100
+++ 
sphinxcontrib-programoutput-0.11/debian/patches/fix-tests-for-sphinx-1.8.patch  
2019-03-09 22:23:04.0 +
@@ -0,0 +1,38 @@
+--- 
sphinxcontrib-programoutput-0.11.orig/src/sphinxcontrib/programoutput/tests/__init__.py
 
sphinxcontrib-programoutput-0.11/src/sphinxcontrib/programoutput/tests/__init__.py
+@@ -3,7 +3,7 @@ import os.path
+ import shutil
+ import tempfile
+ 
+-from docutils.parsers.rst import directives
++from docutils.parsers.rst import directives, roles
+ from sphinx.application import Sphinx
+ 
+ from functools import update_wrapper
+@@ -60,9 +60,12 @@ class AppMixin(object):
+ # sphinxcontrib.programoutput: directive u'program-output' is
+ # already registered, it will be overridden".
+ self.directives = directives._directives.copy()
++# Likewise for 'eq'
++self.roles = roles._roles.copy()
+ 
+ def tearDown(self):
+ directives._directives = self.directives
++roles._roles = self.roles
+ 
+ @Lazy
+ def tmpdir(self):
+--- 
sphinxcontrib-programoutput-0.11.orig/src/sphinxcontrib/programoutput/__init__.py
 
sphinxcontrib-programoutput-0.11/src/sphinxcontrib/programoutput/__init__.py
+@@ -218,6 +218,11 @@ def run_programs(app, doctree):
+ error_message = 'Command {0} failed: {1}'.format(command, error)
+ error_node = doctree.reporter.error(error_message, base_node=node)
+ node.replace_self(error_node)
++# Sphinx 1.8.0b1 started dropping all system_message nodes with a
++# level less than 5 by default (or 2 if `keep_warnings` is set to 
true).
++# This appears to be undocumented. Reporting failures is an 
important
++# part of what this extension does, so we raise the default level.
++error_node['level'] = 6
+ else:
+ if returncode != node['returncode']:
+ app.warn('Unexpected return code {0} from command {1}'.format(
diff -Nru sphinxcontrib-programoutput-0.11/debian/patches/series 
sphinxcontrib-programoutput-0.11/debian/patches/series
--- sphinxcontrib-programoutput-0.11/debian/patches/series  2017-11-18 
13:19:22.0 +
+++ sphinxcontrib-programoutput-0.11/debian/patches/series  2019-03-09 
22:26:13.0 +
@@ -1 +1,2 @@
 remove-failing-tests-when-LANG-equal-C.patch
+fix-tests-for-sphinx-1.8.patch

Bug#923674: systemd: test-stat-util fails with SIGABRT when /dev/random is bind-mounted from /dev/urandom

[Michael Biebl]

Am 09.03.19 um 23:20 schrieb Santiago Vila:
> On Sat, Mar 09, 2019 at 11:08:15PM +0100, Michael Biebl wrote:
>> Am 09.03.19 um 23:00 schrieb Santiago Vila:
>>> The reason I would still consider this as a bug (with whatever severity
>>> you like) is that symlinking /dev/random to /dev/urandom is a common
>>> workaround for lack of entropy, which in turn has traditionally been a
>>> common problem for anybody who tries to build a lot of packages in a row.
>>
>> Can you point to any reference that this is indeed a common practice?
>> I think this is a rather bad and dangerous practice, tbh.
> 
> I don't have a reference for how much common it can be, but it is easy
> to find such suggestion as a workaround for the lack of entropy problem.
> Some examples:
> 
> https://superuser.com/questions/309840/how-can-i-point-dev-random-to-dev-urandom
> https://www.ploxiln.net/urandom_random.html

from those references:
"You should consider adding more entropy rather than compromising your
system."
or
"One simple way (which I don't really suggest)"



-- 
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#890075: ruby-http ftbfs (test failures with 2.5)

[Chris Lamb]

notfound 890075 3.3.0-2
thanks

Emanuele Rocca wrote:

> Note that the bug is not reproducible with ruby-http 3.3.0-2 as tests
> have been disabled

Therefore marking in the BTS to match.


Regards,

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

Bug#923674: systemd: FTBFS (failing tests)

[Michael Biebl]

Am 09.03.19 um 22:43 schrieb Michael Biebl:
> Am 09.03.19 um 22:27 schrieb Santiago Vila:
>> On Sat, Mar 09, 2019 at 09:59:16PM +0100, Michael Biebl wrote:
>>> Am 09.03.19 um 21:50 schrieb Michael Biebl:
 Am 09.03.19 um 21:00 schrieb Santiago Vila:
> to which I also add these two lines:
 ..> /dev/urandom/dev/random nonerw,bind 0   0

 This might very well be the culprit, given that test-stat-util does the
 following check:

 test_device_path_make_canonical_one("/dev/random");
 test_device_path_make_canonical_one("/dev/urandom");

 https://github.com/systemd/systemd/blob/master/src/test/test-stat-util.c#L148
>>
>> Good catch!
>>
>>> Why are you bind mounting /dev/urandom to /dev/random (note the missing
>>> 'u')?
>>
>> It is a workaround for the fact that some packages FTBFS because of
>> lack of entropy (mostly unit tests for cryptography-related packages).
>>
>> Why are you testing /dev/random and /dev/urandom at all?
>>
>> They are supposed to be sane in an autobuilder, no need to check them
>> while building any package.
> 
> The point of the test is to check the implementation of the
> device_path_make_{major_minor|canonical) functions provided by
> libsystemd-shared.
> 
> For that it checks a set of device nodes, among others /dev/random and
> /dev/urandom.
> 
> I'm having a hard timinig blaming the test here, tbh. Having
> /dev/urandom provide a defined behaviour is something that can be
> expected from a sanely configured system.

Felipe, Martin, what's your take on this issue?
I'm inclined to simply close this bug report but would welcome your
feedback first.

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#924129: debian-installer: Kernel for armhf for stretch unbootable

[Cyril Brulebois]

Hi Peter,

Peter Lebbing  (2019-03-09):
> Package: debian-installer
> Version: 20170615+deb9u5+b2
> Severity: grave
> Justification: renders package unusable
> 
> Dear maintainers,
> 
> Debian kernel bug #922478 renders armhf systems unbootable. This bug was
> fixed, but the debian-installer images still use (I presume) kernel
> version 4.9.144-3, the unbootable version. I noticed this today while
> trying to install a new system using:
> 
> http://http.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/firmware.Wandboard.img.gz
> 
> The installer worked when I overwrote the /vmlinuz in that image with
> the one from the new 4.9.144-3.1.

Thanks for your report; that's known and fixed on the kernel side
already; how to deal with d-i is discussed in:
  https://lists.debian.org/debian-boot/2019/03/msg00165.html

Currently waiting on some input from Vagrant:
  https://lists.debian.org/debian-boot/2019/03/msg00179.html


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


signature.asc
Description: PGP signature

Bug#924128: prokka: creates world writable directory tree /var/lib/prokka/*

[Andreas Tille]

Control: severity -1 normal 

On Sat, Mar 09, 2019 at 08:24:46PM +0100, Andreas Beckmann wrote:
> 
> during a test with piuparts I noticed your package creates a world
> writable directory tree.
> 
> >From the attached log (scroll to the bottom...):
> 
> 0m49.9s ERROR: Command failed (status=1): ['chroot', 
> '/srv/piuparts/tmp/tmpLm6y7M', 
> 'tmp/scripts/pre_remove_50_find_bad_permissions']
>   ERROR: BAD PERMISSIONS
>   drwxrwxrwx 3 root root  60 Mar  5 02:46 /var/lib/prokka
>   drwxrwxrwx 4 root root  80 Mar  5 02:46 /var/lib/prokka/db
>   drwxrwxrwx 2 root root 260 Mar  5 02:46 /var/lib/prokka/db/cm
>   drwxrwxrwx 2 root root 580 Mar  5 02:46 /var/lib/prokka/db/genus

I actually did some effort to make this dir world writable since users
*need* to write and update these databases.  Do your have any suggestion
for a better approach which enables every user to update a common
database?  I was wondering whether I should create a group prokka and
making the dir only writable for users belonging to this group.  But for
a first packaging attempt testing user responses this seemed to be over
enginering.  There is also some work done at upstream to enable a better
solution for user writable databases.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#923674: systemd: test-stat-util fails with SIGABRT when /dev/random is bind-mounted from /dev/urandom

[Santiago Vila]

I confirm that dropping the /dev/urandom line from
/etc/schroot/default/fstab makes the package to build again.

Now I fear that crypto packages with random-intensive test suites
start to FTBFS again...

Thanks.

Bug#918309: sphinxcontrib-programoutput: Please update to v0.13 that is compatible with Sphinx 1.8

[Chris Lamb]

tags 918309 + patch
thanks

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/src/sphinxcontrib/programoutput/__init__.py 
b/src/sphinxcontrib/programoutput/__init__.py
index 7eb1c5d..824c045 100644
--- a/src/sphinxcontrib/programoutput/__init__.py
+++ b/src/sphinxcontrib/programoutput/__init__.py
@@ -218,6 +218,11 @@ def run_programs(app, doctree):
 error_message = 'Command {0} failed: {1}'.format(command, error)
 error_node = doctree.reporter.error(error_message, base_node=node)
 node.replace_self(error_node)
+# Sphinx 1.8.0b1 started dropping all system_message nodes with a
+# level less than 5 by default (or 2 if `keep_warnings` is set to 
true).
+# This appears to be undocumented. Reporting failures is an 
important
+# part of what this extension does, so we raise the default level.
+error_node['level'] = 6
 else:
 if returncode != node['returncode']:
 app.warn('Unexpected return code {0} from command {1}'.format(
diff --git a/src/sphinxcontrib/programoutput/tests/__init__.py 
b/src/sphinxcontrib/programoutput/tests/__init__.py
index 7547962..1e19120 100644
--- a/src/sphinxcontrib/programoutput/tests/__init__.py
+++ b/src/sphinxcontrib/programoutput/tests/__init__.py
@@ -3,7 +3,7 @@ import os.path
 import shutil
 import tempfile
 
-from docutils.parsers.rst import directives
+from docutils.parsers.rst import directives, roles
 from sphinx.application import Sphinx
 
 from functools import update_wrapper
@@ -60,9 +60,12 @@ class AppMixin(object):
 # sphinxcontrib.programoutput: directive u'program-output' is
 # already registered, it will be overridden".
 self.directives = directives._directives.copy()
+# Likewise for 'eq'
+self.roles = roles._roles.copy()
 
 def tearDown(self):
 directives._directives = self.directives
+roles._roles = self.roles
 
 @Lazy
 def tmpdir(self):

Bug#923637: Bug#923637: 923637 is pending

[Andreas Tille]

Hi Andrius,

thanks a lot for the fix.

On Sat, Mar 09, 2019 at 07:37:19PM +0200, Andrius Merkys wrote:
> It must be an overlook. I will fix it today/tomorrow.

Please don't.
 
> On Sat, 9 Mar 2019, 19:26 Olivier Sallou,  wrote:
> 
> > there is a remaining warning:
> >
> > W: libffindex0: package-name-doesnt-match-sonames libffindex2.0.2
> >
> > so this not a big issue by itself, but why packgae is named libffindex0
> > while lib version is 2.x ?

Its simply because upstream does not know the difference between version
and SOVERSION.  There is no ABI change and thus its fine to stick to
libffindex0.  I'd rather think that it would be more appropriate to fic
the soname - but not touching this - specifically under freeze policy is
a safe thing, IMHO.

Kind regards

   Andreas.


-- 
http://fam-tille.de

Bug#923674: systemd: test-stat-util fails with SIGABRT when /dev/random is bind-mounted from /dev/urandom

[Santiago Vila]

On Sat, Mar 09, 2019 at 11:08:15PM +0100, Michael Biebl wrote:
> Am 09.03.19 um 23:00 schrieb Santiago Vila:
> > The reason I would still consider this as a bug (with whatever severity
> > you like) is that symlinking /dev/random to /dev/urandom is a common
> > workaround for lack of entropy, which in turn has traditionally been a
> > common problem for anybody who tries to build a lot of packages in a row.
> 
> Can you point to any reference that this is indeed a common practice?
> I think this is a rather bad and dangerous practice, tbh.

I don't have a reference for how much common it can be, but it is easy
to find such suggestion as a workaround for the lack of entropy problem.
Some examples:

https://superuser.com/questions/309840/how-can-i-point-dev-random-to-dev-urandom
https://www.ploxiln.net/urandom_random.html
https://kb.vmware.com/s/article/1036980

Thanks.

Bug#913765: RM: leafpad -- GTK+ based simple text editor

[Andrej Shadura]

Control: reassign -1 release.debian.org
Control: retitle -1 RM: leafpad -- GTK+ based simple text editor

On Thu, 10 Jan 2019 14:31:56 +0100 Andrej Shadura 
wrote:
> On Wed, 14 Nov 2018 22:44:08 +0100 krystal  wrote:
> > This needs love or it will die. Needs to be updated to use gtk3, has at 
> > least one bug that may cause data loss without warning. Is anyone going 
> > to take this on, or is there a better simple text editor that we should 
> > all move to and let this one go?
> 
> I would say gedit seems to be much a better choice. I’m not sure it
> makes sense to keep this bare-bones simple but outdated editor, when
> gedit is also quite simplistic, but has additional features and is
> maintained upstream.

Five months after the initial orphaning request, nothing has happened to
suggest a drastic change in the package’s future.

It’s the time for leafpad to go, I suppose.

-- 
Cheers,
  Andrej

Bug#924150: stretch-pu: package libdate-holidays-de-perl/1.9-1+deb9u3

[Christoph Biedl]

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

As I wrote in #902042:

> FWIW, there are currently no further plans to change holidays in
> Germany, so this is hopefully the last update for a long time.

This did not hold. So another round: This time Berlin introduced two
more public holidays, March 8th from 2019 on (first one already passed),
and May 8th one time in 2020.

To keep libdate-holidays-de-perl in sync, I've prepared 1.9-1+deb9u3.
The related upload for sid (2.00-2) happened already a few weeks ago and
has migrated to testing in the meantime. Upload to 9/stretch/stable will
follow in a moment, following the stable release policy change last
year.

Kind regards,

Christoph


signature.asc
Description: PGP signature

Bug#923674: systemd: test-stat-util fails with SIGABRT when /dev/random is bind-mounted from /dev/urandom

[Michael Biebl]

Am 09.03.19 um 23:00 schrieb Santiago Vila:
> The reason I would still consider this as a bug (with whatever severity
> you like) is that symlinking /dev/random to /dev/urandom is a common
> workaround for lack of entropy, which in turn has traditionally been a
> common problem for anybody who tries to build a lot of packages in a row.

Can you point to any reference that this is indeed a common practice?
I think this is a rather bad and dangerous practice, tbh.

-- 
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#924147: geeqie-common: Please add Multi-Arch: foreign

[Elrond]

retitle 924147 geeqie-common: Please add Multi-Arch: foreign
thanks

Ups.

I used an old request as a template and missed to fixup the
Subject.

Cheers

Elrond

Bug#878590: systemd: jessie to stretch upgrade resulted in eth0 being given a new style predictable name (enp1s9)

[Michael Biebl]

Hi Phil

On Sat, 14 Oct 2017 21:56:40 +0100 Philip Hands  wrote:
> Package: systemd
> Version: 232-25+deb9u1
> Severity: important
> 
> Hi,
> 
> After upgrading to Stretch, the system came up with its NIC named as
> enp1s9, and thus had no working network (since eth0 was configured
> in /etc/network/interfaces), requiring me to get console access to
> fix things.
> 
> I suspect that this is the result of me having two empty udev rules
> files on the system, prior to the upgrade:
> 
>  udev/rules.d/70-persistent-net.rules
>  udev/rules.d/75-persistent-net-generator.rules
> 
> Those empty files being there in order to ensure that the one NIC in
> the machine will never end up being called anything other than eth0,
> not even if the NIC gets replaced.
> 
> It is my suspicion that something is checking for the existence of
> the persistent-net rules file, and if it is there, is assuming that it
> contains a rule to keep the NIC named as whatever it was named before.

There is
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/udev.postinst#L52


> If that is the case, I broke that assumption.

In a way, yes. The assumption is, that if
/etc/udev/rules.d/70-persistent-net.rules exists it was used to setup
static names using the old scheme.

Afaics, you wanted to disable the generator, so only overriding
udev/rules.d/75-persistent-net-generator.rules would not have broken the
above assumption.

> I can imagine that dealing with this case automatically might be rather
> tiresome.

We already have quite a few corner cases and and I'm worried to change
anything now in stable which has the potential to break other setups in
subtle ways.
Somehow I feel the boat has sailed here and since we didn't have other
user bug reports about running into the same issue, I wonder if simply
closing this bug report is the sanest thing to do at this point.

Wdyt?




> I would have been happy if the upgrade had failed with a warning that
> having an empty 70-persistent-net.rules is not supported, and that I
> should take steps to either define the new names in network/interfaces,
> or add net.ifnames=0 to the kernel command line, or perhaps recommending
> a new udev rule that would have the effect of naming the one NIC in the
> machine as 'en0' say, if there is a nice way of doing that which survives
> the NIC being replaced.
> 
> If something else is going on, I realise that this report is very light
> on detail, and will be happy to do any tests, or provide any further
> details to work out what's really going on here -- please just ask.
> 
> I believe that what I did was the recommended way of getting the behaviour
> I wanted, and that the intention was that NIC naming should be preserved
> on upgrade, hence the severity of important, since this breaks networking,
> which might cause significant inconvenience for people.
> 
> I'm sorry if this should be reported against e.g. udev instead, but the
> persistent naming seems to be under the aegis of systemd, so this seemed
> like a reasonable starting point -- please reassign as appropriate.
> 
> BTW I note that the recommendation from here:
>   
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> to restore the old behaviour by doing:
> 
>   ln -s /dev/null /etc/systemd/network/99-default.link

You need to rebuild the initramfs after doing that.





-- 
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#923481: alpine: replies lose In-Reply-To and References headers

[Unit 193]

Howdy,

As I understand it, this is not a regression in alpine but a difference in how 
pine and alpine function, correct?


~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

Bug#923674: systemd: test-stat-util fails with SIGABRT when /dev/random is bind-mounted from /dev/urandom

[Santiago Vila]

retitle 923674 systemd: test-stat-util fails with SIGABRT when /dev/random is 
bind-mounted from /dev/urandom
severity 923674 normal
thanks

Sorry for this false positive. I think this retitle reflects much better the 
issue.

The reason I would still consider this as a bug (with whatever severity
you like) is that symlinking /dev/random to /dev/urandom is a common
workaround for lack of entropy, which in turn has traditionally been a
common problem for anybody who tries to build a lot of packages in a row.

BTW: After building 28500 source packages in buster, I only found
another package which failed for this very reason:

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

(Still trying the build in my autobuilders with the fixed fstab
but I expect it will work this time).

Thanks a lot.

Bug#924148: unblock: python-dmidecode/3.12.2-9

[Sandro Tosi]

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

Please unblock package python-dmidecode

this reverts completely the attempt to migrate to use symlinks for the doc
directory of the -dbg packages; i've wasted enough time on something that would
only save a handful of KBs. in doing so it fixes a FTBFS bug

Attached the debdiff

unblock python-dmidecode/3.12.2-9

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-dmidecode-3.12.2/debian/changelog 
python-dmidecode-3.12.2/debian/changelog
--- python-dmidecode-3.12.2/debian/changelog2019-03-07 17:51:40.0 
-0500
+++ python-dmidecode-3.12.2/debian/changelog2019-03-09 14:49:11.0 
-0500
@@ -1,3 +1,9 @@
+python-dmidecode (3.12.2-9) unstable; urgency=medium
+
+  * revert symlink_to_dir for -dbg packages; Closes: #924007
+
+ -- Sandro Tosi   Sat, 09 Mar 2019 14:49:11 -0500
+
 python-dmidecode (3.12.2-8) unstable; urgency=medium
 
   * debian/rules
diff -Nru python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript 
python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript
--- python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript
2019-03-07 17:51:40.0 -0500
+++ python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript
2019-03-09 14:49:11.0 -0500
@@ -1 +1 @@
-dir_to_symlink /usr/share/doc/python3-dmidecode-dbg python3-dmidecode 3.12.2-8~
+symlink_to_dir /usr/share/doc/python3-dmidecode-dbg python3-dmidecode 3.12.2-9~
diff -Nru python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript 
python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript
--- python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript 
2019-03-07 17:51:40.0 -0500
+++ python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript 
2019-03-09 14:49:11.0 -0500
@@ -1 +1 @@
-dir_to_symlink /usr/share/doc/python-dmidecode-dbg python-dmidecode 3.12.2-8~
+symlink_to_dir /usr/share/doc/python-dmidecode-dbg python-dmidecode 3.12.2-9~
diff -Nru python-dmidecode-3.12.2/debian/rules 
python-dmidecode-3.12.2/debian/rules
--- python-dmidecode-3.12.2/debian/rules2019-03-07 17:51:40.0 
-0500
+++ python-dmidecode-3.12.2/debian/rules2019-03-09 14:49:11.0 
-0500
@@ -38,12 +38,7 @@
 endif
 
 override_dh_installdocs:
-   dh_installdocs -p$(P2)-dbg --link-doc=$(P2)
-   dh_installdocs -p$(P3)-dbg --link-doc=$(P3)
-   dh_installdocs -p$(P2) README doc/AUTHORS doc/changelog 
doc/README.types doc/AUTHORS.upstream doc/README.upstream
-   dh_installdocs -p$(P3) README doc/AUTHORS doc/changelog 
doc/README.types doc/AUTHORS.upstream doc/README.upstream
-   mkdir -p $(CURDIR)/debian/$(P2)-data/usr/share/doc/
-   cp -r $(CURDIR)/debian/$(P2)/usr/share/doc/$(P2) 
$(CURDIR)/debian/$(P2)-data/usr/share/doc/$(P2)-data
+   dh_installdocs -A README doc/AUTHORS doc/changelog doc/README.types 
doc/AUTHORS.upstream doc/README.upstream
 
 override_dh_strip:
 ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))

Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)

[Pierre Ynard]

> > As you convincingly remarked below, we may want honor `test -f /forcecheck'
> > for every filesystem, whose `fsck' supports `-f' option. As far as I
> > follow the thread, it is:
> >
> > ext2 ext3 ext4 reiserfs
>
> Interesting that acceptance of that parameter is so low.

fsck.minix supports it too. I don't use many filesystems and don't have
many tool suites installed so I really wouldn't know how widespread it
is.

> > But I really want to have some transition plan to get rid of
> > /forcecheck, something like:
>
> … you might like that tune2fs can now (1.45.0-1, not yet in
> buster, officially not likely to make it but we can hope) set
> a flag force_fsck that next boot’s auto e2fsck will honour.
> I’m assuming this works for ext2/ext3/ext4; ask tytso if unsure.

You may want to look at #470956 for related reasons and discussions.
/fastboot and /forcefsck are created by `shutdown -f` and `shutdown -F`
respectively. I like the idea that instead of this interface, it should
call tune2fs to set that flag. Or rather, if that doesn't belong inside
the shutdown binary, it could create /forcefsck or /run/forcefsck, which
would then be checked by a script in runlevel 0 or 6 that calls tune2fs
on the relevant filesystems.

We could use that script any time we want (like in runlevel S too) to
print deprecation warnings to assist in the transition.

-- 
Pierre Ynard

Bug#924149: RFP: py-spy -- sampling profiler for Python programs

[Sandro Tosi]

Package: wnpp
Severity: wishlist

* Package name: py-spy
  Version : 0.1.10
  Upstream Author : Ben Frederickson 
* URL : https://github.com/benfred/py-spy
* License : GPLv3
  Programming Lang: Rust
  Description : sampling profiler for Python programs

Py-Spy is a sampling profiler for Python programs. It lets you visualize what
your Python program is spending time on without restarting the program or
modifying the code in any way. Py-Spy is extremely low overhead: it is written
in Rust for speed and doesn't run in the same process as the profiled Python
program. This means Py-Spy is safe to use against production Python code.

Bug#923674: systemd: FTBFS (failing tests)

[Michael Biebl]

Am 09.03.19 um 22:27 schrieb Santiago Vila:
> On Sat, Mar 09, 2019 at 09:59:16PM +0100, Michael Biebl wrote:
>> Am 09.03.19 um 21:50 schrieb Michael Biebl:
>>> Am 09.03.19 um 21:00 schrieb Santiago Vila:
 to which I also add these two lines:
>>> ..> /dev/urandom/dev/random nonerw,bind 0   0
>>>
>>> This might very well be the culprit, given that test-stat-util does the
>>> following check:
>>>
>>> test_device_path_make_canonical_one("/dev/random");
>>> test_device_path_make_canonical_one("/dev/urandom");
>>>
>>> https://github.com/systemd/systemd/blob/master/src/test/test-stat-util.c#L148
> 
> Good catch!
> 
>> Why are you bind mounting /dev/urandom to /dev/random (note the missing
>> 'u')?
> 
> It is a workaround for the fact that some packages FTBFS because of
> lack of entropy (mostly unit tests for cryptography-related packages).
> 
> Why are you testing /dev/random and /dev/urandom at all?
> 
> They are supposed to be sane in an autobuilder, no need to check them
> while building any package.

The point of the test is to check the implementation of the
device_path_make_{major_minor|canonical) functions provided by
libsystemd-shared.

For that it checks a set of device nodes, among others /dev/random and
/dev/urandom.

I'm having a hard timinig blaming the test here, tbh. Having
/dev/urandom provide a defined behaviour is something that can be
expected from a sanely configured system.

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#924147: gnucash-common: Please add Multi-Arch: foreign

[Elrond]

Package: geeqie-common
Version: 1:1.4+git20190121-2
Severity: wishlist
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

Hi,

It looks like geeqie-common offers an architecture
independent (data level) interface to its users.

Would you mind setting it to Multi-Arch: foreign?
It's usually a matter of adding one line to debian/control.

This would hopefully improve install options for different
architectures. Like running the x32 variant on an amd64
system.

Note: Architecture=all packages are not Multi-Arch=foreign
automatically for various reasons, so they need to be set
manually.


Cheers

Elrond

Bug#712023: initscripts: wait for child to exit during shutdown/reboot

[Pierre Ynard]

tags 712023 moreinfo
thanks

> I have made a script to readout the vm's that are running and save
> there state one by one. This takes some time. At the beginning no vm
> was saved right. I did some tunning with the scripts and have now 5-10
> sec's before the other vboxservices are terminated. So i can bring 3
> maybe 4 syetems the rightway down.
>
> I did look in the documentation, and i didnot found a usefull option ,
> that could ensure me that the vm is brought down the rightway. (wait
> for child to terminated)

I'm not sure I understand correctly. Does your script run outside the
VMs to list and save them one by one, or does it run inside each VM?
What does it do? How do you launch your script? What terminates the VMs
in the wrong way? What would be the right way?

> I am looking for a manner that the system will wait for the proces to
> terminated and not be killed. Because killing running vm's might lead
> top dataloss.

You can write an init script to save and stop your VMs waiting all the
time it takes, and set proper dependencies for that init script to
ensure the shutdown sequence waits for it to have completed, with all
your VMs properly saved, before all remaining processes on the system
are killed. Is there any reason why that wouldn't work in your case?

> I'm thinking about some tag in the initscripts - to place if a proces
> has to be waited for. Maybe with the possibillity to set a maxtime,
> so it is guaranted that the machine will not hang for waiting on a
> process that will not terminated.

Considering that you should be able to do this in the way I mentioned
above, I don't think it's necessary to add such a mechanism - but maybe
I misunderstood your problem.

-- 
Pierre Ynard

Bug#923674: systemd: FTBFS (failing tests)

[Santiago Vila]

On Sat, Mar 09, 2019 at 09:59:16PM +0100, Michael Biebl wrote:
> Am 09.03.19 um 21:50 schrieb Michael Biebl:
> > Am 09.03.19 um 21:00 schrieb Santiago Vila:
> >> to which I also add these two lines:
> > ..> /dev/urandom/dev/random nonerw,bind 0   0
> > 
> > This might very well be the culprit, given that test-stat-util does the
> > following check:
> > 
> > test_device_path_make_canonical_one("/dev/random");
> > test_device_path_make_canonical_one("/dev/urandom");
> > 
> > https://github.com/systemd/systemd/blob/master/src/test/test-stat-util.c#L148

Good catch!

> Why are you bind mounting /dev/urandom to /dev/random (note the missing
> 'u')?

It is a workaround for the fact that some packages FTBFS because of
lack of entropy (mostly unit tests for cryptography-related packages).

Why are you testing /dev/random and /dev/urandom at all?

They are supposed to be sane in an autobuilder, no need to check them
while building any package.

I'm going to check without the bind mount and probably retitle and
downgrade the bug.

Thanks.