Bug#964289: systemd-container: armhf countainer cannot be started on amd64 host

[Ryutaroh Matsumoto]

Package: systemd-container
Version: 245.6-1
Severity: normal

Dear Maintainer,

I installed
# dpkg-query -W | grep qemu-user-static
qemu-user-static1:5.0-5

Then I built a root directory as

# mmdebstrap --components="main contrib non-free" --architectures=armhf 
--variant=important bullseye /var/lib/machines/armhf-bullseye

Then 
# systemd-nspawn -D /var/lib/machines/armhf-bullseye -a
works fine.

But I got the following error and could not start the container...
# systemd-nspawn -D /var/lib/machines/armhf-bullseye   -b
Spawning container armhf-bullseye on /var/lib/machines/armhf-bullseye.
Press ^] three times within 1s to kill container.
systemd 245.6-1 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR 
+SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP 
+BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
Detected virtualization systemd-nspawn.
Detected architecture arm.

Welcome to Debian GNU/Linux bullseye/sid!

Set hostname to .
Failed to enqueue loopback interface start request: Operation not supported
Caught , core dump failed (child 3, code=killed, status=11/SEGV).
Exiting PID 1...
Container armhf-bullseye failed with error code 255.

Best regards, Ryutaroh Matsumoto


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

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

Versions of packages systemd-container depends on:
ii  dbus 1.12.18-1
ii  libacl1  2.2.53-8
ii  libbz2-1.0   1.0.8-3
ii  libc62.30-8
ii  libcurl3-gnutls  7.68.0-1
ii  libgcrypt20  1.8.5-5
ii  liblzma5 5.2.4-1+b1
ii  libseccomp2  2.4.3-1+b1
ii  libselinux1  3.0-1+b3
ii  systemd  245.6-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages systemd-container recommends:
pn  libnss-mymachines  

systemd-container suggests no packages.

-- no debconf information

Bug#964288: override: debichem

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
could you please apply these changes:

dak override debichem-cheminformatics metapackages # from 'debichem'
dak override debichem-visualisation metapackages # from 'debichem'
dak override debichem-view-edit-2d metapackages # from 'debichem'
dak override debichem-semiempirical metapackages # from 'debichem'
dak override debichem-modelling metapackages # from 'debichem'

(as requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956258# )

Thanks!

Bug#937009: [Python-apps-team] Bug#937009: mercurial: Python2 removal in sid/bullseye

[Sandro Tosi]

> > > Do you need any help in coordinating with the packaged extensions,
> > > testing changes, preparing patches? a lot of time has passed since we
> > > started asking about mercurial and python3 and it is becoming the only
> > > reverse-dependency of several packages that could be removed if
> > > mercurial switched to py3k.
> > >
> > Getting an uptodate list of extensions and their status wrt porting both
> > upstream and in Debian would be useful.  I've spent some time looking at
> > hgsubversion a few weeks ago but there's a ton of work and I don't
> > actually use it so I've kind of given up on that; I forget what the
> > status is on others.
>
> will look into the rdeps of mercurial once 5.4.1-1+exp1 hits the archive

I've rebuilt all rdeps of mercurial against the python3 version
uploaded to unstable; results are:

2020/07/05 00:28:22 Build results:
2020/07/05 00:28:22 PASSED: salt
2020/07/05 00:28:22 PASSED: golang-github-masterminds-vcs-dev
2020/07/05 00:28:22 PASSED: pepper
2020/07/05 00:28:22 PASSED: python-hglib
2020/07/05 00:28:22 PASSED: git-remote-hg
2020/07/05 00:28:22 PASSED: haskell-filestore
2020/07/05 00:28:22 PASSED: composer
2020/07/05 00:28:22 PASSED: yotta
2020/07/05 00:28:22 PASSED: ros-rosinstall
2020/07/05 00:28:22 PASSED: check-manifest
2020/07/05 00:28:22 PASSED: jags
2020/07/05 00:28:22 PASSED: setuptools-scm
2020/07/05 00:28:22 PASSED: reposurgeon
2020/07/05 00:28:22 PASSED: devpi-common
2020/07/05 00:28:22 PASSED: firmware-microbit-micropython
2020/07/05 00:28:22 PASSED: python-hgapi
2020/07/05 00:28:22 PASSED: hgsubversion
2020/07/05 00:28:22 PASSED: ros-wstool
2020/07/05 00:28:22 PASSED: ros-vcstools
2020/07/05 00:28:22 FAILED: hg-git (see buildlogs/hg-git_0.8.12-1.2)
2020/07/05 00:28:22 FAILED: meson (see buildlogs/meson_0.54.3-1)

(build logs and artifacts are at
https://people.debian.org/~morph/mercurial_python3/ )

hg-git is RC and not in testing since mid-December, and meson is i
think a real error, since without mercurial depending on python2 now
the build fails to find that executable

Tbh, i think it's time to just rip the bandaid and upload mercurial
python3 to unstable, and deal with the consequences there (i volunteer
to do so); you mentioned hgsubversion as a potential blocker: that
package are popcon on 56, i dont believe such a minor package should
hold progress with the py2removal effort (I've added debian-python@ to
gather their input on this).

I do understand the rebuild results are not conclusive on the python3
migration (after all hgsubversion rebuilds fine with py3k mercurial,
which also raises the questions of why it b-d on it since it clearly
doesnt use it, but i'm digressing), but i think it's better to just go
ahead and upload the experimental version to unstable and see what's
the impact there

What do people think about this?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#963232: iceweasel: seccomp sandbox violation: syscall 315 (__NR_sched_getattr) and 332 (__NR_statx) on amd64

[Thorsten Glaser]

Package: firefox-esr
Version: 68.10.0esr-1
Followup-For: Bug #963232
Control: retitle -1 iceweasel: seccomp sandbox violation: syscall 315 
(__NR_sched_getattr) and 332 (__NR_statx) on amd64

[…]
###!!! [Child][MessageChannel] Error: 
(msgtype=0x530005,name=PHttpChannel::Msg_Cancel) Channel closing: too late to 
send/recv, messages will be lost

[Parent 20551, Gecko_IOThread] WARNING: pipe error (206): Connection reset by 
peer: file 
/build/firefox-esr-q0MF88/firefox-esr-68.10.0esr/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 358
Sandbox: seccomp sandbox violation: pid 22860, tid 22951, syscall 332, args 0 0 
0 4095 0 0.
Sandbox: seccomp sandbox violation: pid 22884, tid 22884, syscall 315, args 
22884 139696552967168 56 0 15 139696552967168.
Sandbox: seccomp sandbox violation: pid 22977, tid 22977, syscall 315, args 
22977 139700215836096 56 0 6 139700215836096.
Sandbox: seccomp sandbox violation: pid 22884, tid 23103, syscall 332, args 0 0 
0 4095 0 0.
Sandbox: seccomp sandbox violation: pid 22977, tid 23122, syscall 332, args 0 0 
0 4095 0 0.

###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, 
messages will be lost
[…]



-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.11
ii  fontconfig2.13.1-4.2
ii  libasound21.2.2-2.3
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-8
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.20-1
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-4
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.2+dfsg-2
ii  libgcc-s1 10.1.0-4
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libglib2.0-0  2.64.3-2
ii  libgtk-3-03.24.20-1
ii  libjsoncpp1   1.7.4-3.1
ii  libnspr4  2:4.25-1
ii  libnss3   2:3.53.1-1
ii  libpango-1.0-01.44.7-4
ii  libsqlite3-0  3.32.3-1
ii  libstartup-notification0  0.12-6
ii  libstdc++610.1.0-4
ii  libx11-6  2:1.6.9-2+b1
ii  libx11-xcb1   2:1.6.9-2+b1
ii  libxcb-shm0   1.14-2
ii  libxcb1   1.14-2
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.16-5
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec57  7:3.2.14-1~deb9u1
ii  libavcodec58  7:4.3-3

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-10
ii  libgtk2.0-02.24.32-4
pn  pulseaudio 

-- no debconf information

Bug#964161: I have this bug too

[Marcelo Zapatta]

Dear Maintainer,

I'm also having this problem, after upgrading via apt get. chromium
becomes impossible to use. I even have to downgrade from
83.0.4103.116-1~deb10u1 to 80.0.3987.162-1~deb10u1 for get an usable
version of chromium.

In the 83 version I have several crashes after some time using the
browser and it just crashes with no messages, and facing a really slow
browsing experience.

Bug#964017: Dpkg::Source::Package:new require_valid_signature => 0

[Guillem Jover]

Control: clone -1 -2
Control: reassign -2 dgit
Control: retitle -2 dgit: Incorrect use of Dpkg::Source::Package argument

On Fri, 2020-07-03 at 11:09:40 +0100, Ian Jackson wrote:
> Guillem Jover writes ("Re: Bug#964017: grep-excuses"):
> > On Tue, 2020-06-30 at 14:15:13 +0100, Ian Jackson wrote:
> > > The string "failed to verify signature" is not generated by code in
> > > dgit.  Looking at the code in dgit, I think the error happens here:
> > > 
> > > my $dp = new Dpkg::Source::Package filename => $dscfn,
> > > require_valid_signature => $needsig;
> > > {
> > > local $SIG{__WARN__} = sub {
> > > print STDERR $_[0];
> > > return unless $needsig;
> > > fail __ "import-dsc signature check failed";
> > > };
> > > if (!$dp->is_signed()) {
> > > warn f_ "%s: warning: importing unsigned .dsc\n", $us;
> > > } else {
> > > my $r = $dp->check_signature();
> > > confess "->check_signature => $r" if $needsig && $r;
> > > }
> > > }
> > > 
> > > I think this rather complex code is trying to deal with API
> > > compatibility issues surrounding require_valid_signature etc.  Anyway,
> > > I think the message is generated by the call to
> > > Dpkg::Source::Package::new.  I think that function inserted $0 into
> > > the error message.
> > > 
> > > I don't know why it is verifying the signature.  I think in this
> > > particular test $needsig is 0.  I searched the code for the variable
> > > and the only place dgit sets it trueish is if dgit import-dsc is
> > > told --require-valid-signature.
> > 
> > This error message comes from Dpkg::OpenPGP::verify_signature() called
> > by Dpkg::Source::Package->check_signature(), so if you do not want to
> > verify the signature I guess you'd need to conditionalize that call
> > also with $needsig.
> 
> Sorry, I was confused before.  Yes, I see that it does verify the
> signature even if $needsig is 0.  That's desirable because I still
> want to print a warning if the signature doesn't verify.
> 
> Previously this worked, I think.
> 
> The problem is that, now, check_signature exits the process when the
> signature check fails, rather than returning a falseish value.
> I'm pretty sure this must be a change in src:dpkg, since ci.d.n does
> rerun the dgit test suite for gpg[v] migrations.

Ok, so I've tracked this down, and there is a behavior regression with
the Dpkg::Source::Package module (but not dpkg-source itself), which
due to some refactoring now defaults to require_valid_signature being
«1», I'm fixing this and setting all other supported options to their
implicit old default value.

The other part is that the dgit code, and its test suite seems to have
never passed the correct option to that module, and the new regression
just surfaced that problem now.

The require_valid_signatures needs to be passed within the «options»
hashref, and not as part of the main args. Something like:

   my $dp = Dpkg::Source::Package->new(
   filename => $dscfn,
   options => {
   require_valid_signature => $needsig,
   },
   );

Trying to extract one of the failing source packages (f.ex.
«tests/tmp/import-dsc/mirror/pool/main/example_1.2.dsc») with the buster
version of dpkg-source using --require-valid-signature, shows that
would fail there too.

> > > So I don't know what a "trustedkeys.kbx" file is or why I need one
> > > now.  (dgit's test suite naturally has a set of test keys, so it has
> > > its own idea of the public keys to use for signature verifications.
> > > But this test case should not involve any of that.)
> > 
> > Hmm, I guess I should be passing --homedir to gpg also within the
> > verify_signature(), like I did for the import_key() call. But I'm
> > assuming you are setting GNUPGHOME in the test suite as well, which
> > is what would make gpg look for the trustedkeys db in there.
> 
> Yes, I do pass GNUPGHOME.  But it's quite possible that this test,
> which is not supposed to have a valid signature, has a .dsc with a
> signature whose public key is not available.

So while I'm still doing this out of robustness, I don't think this is
what is causing the problem at hand.

Thanks,
Guillem

Bug#964285: asterisk: New upstream release: 17.5.1

[Gabriel Filion]

Source: asterisk
Severity: wishlist

Hello dear maintainers!

First, thanks for your work for keeping this package alive in debian. I use it
for work and it's greatly useful.

I've just had a quick look at upstream and it would seem as though the version
that's presently in bullseye is quite late with regards to the upstream latest
release.

The latest release is as of this writing 17.5.1. It would be fantastic to get
the 17.x branch in testing before bullseye reaches its freeze cycle.

Cheers, and many thanks in advance!

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

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

Bug#964284: guile-gnutls: update to use guile 3.0

[Vagrant Cascadian]

Package: guile-gnutls
Version: 3.6.14-2
Severity: normal
Tags: patch

The attached patch updates guile-gnutls to use guile 3.0, which is the
current version of guile, available in unstable and bullseye. It would
be ideal if the switch happened before bullseye was released.

Thanks for maintaining gnutls!

live well,
  vagrant

From 41e18c8105d45c2e19070d33cf54b5081b86f52d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 5 Jul 2020 01:49:47 +
Subject: [PATCH] guile-gnutls: Switch to guile 3.0.

---
 debian/control | 4 ++--
 debian/rules   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index a7db83c..0c54bc2 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
  datefudge ,
  debhelper-compat (=12),
  freebsd-net-tools [kfreebsd-i386 kfreebsd-amd64] ,
- guile-2.2-dev ,
+ guile-3.0-dev ,
  libcmocka-dev ,
  libgmp-dev (>= 2:6),
  libidn2-dev,
@@ -230,7 +230,7 @@ Package: guile-gnutls
 Build-Profiles: 
 Architecture: any
 Section: lisp
-Depends: ${misc:Depends}, ${shlibs:Depends}, guile-2.2
+Depends: ${misc:Depends}, ${shlibs:Depends}, guile-3.0
 Description: GNU TLS library - GNU Guile bindings
  GnuTLS is a portable library which implements the Transport Layer
  Security (TLS 1.0, 1.1, 1.2, 1.3) and Datagram
diff --git a/debian/rules b/debian/rules
index bf693b8..65774f3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -53,7 +53,7 @@ override_dh_makeshlibs:
 		-- -c4
 	dh_makeshlibs $(BDIR) -p libgnutls-openssl27 -V 'libgnutls-openssl27 (>= 3.6.11-0)'
 	dh_makeshlibs $(BDIR) --remaining-packages \
-		-Xguile/2.2/
+		-Xguile/3.0/
 
 
 # pre-clean rule: save gnutls.pdf since it is expensive to regenerate.
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#959075: Still not working on Debian testing

[Paul Wise]

On Sat, 2020-07-04 at 18:08 +0200, richard lucassen wrote:

> Rereading it, I don't know if this issue was present in 2.9 or earlier.
> I just noticed it while testing the new version.

Would you mind downgrading to 2.9 and testing it?
You can install it from Debian buster or snapshot.d.o

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#944738: Also occurs with openjdk-14-jdk 14.0.1+7-1

[Nye Liu]

This bug is nearly a year old. Is anyone working on it?

Bug#964282: lintian: tried to issue unknown tags: manpage-in-wrong-directory at /usr/share/perl5/Lintian/Group.pm line 451.

[Axel Beckert]

Hi,

Axel Beckert wrote:
> tried to issue unknown tags: manpage-in-wrong-directory at 
> /usr/share/perl5/Lintian/Group.pm line 451.
[...]
> This tag seems to have been renamed to odd-place-for-manual-page.

The patch for this seems trivial:

diff --git a/checks/documentation/manual.pm b/checks/documentation/manual.pm
index cf4f433ac..b30bf6081 100644
--- a/checks/documentation/manual.pm
+++ b/checks/documentation/manual.pm
@@ -144,7 +144,7 @@ sub files {
 
 # number of directory and manpage extension equal?
 if ($section_num != $section) {
-$self->tag('manpage-in-wrong-directory', $file);
+$self->tag('odd-place-for-manual-page', $file);
 }
 } else {
 $self->tag('wrong-name-for-manual-page', $file);

But I wonder why the test suite didn't catch this issue. So I'm not
sure if the patch above is sufficient.

Additionally I seem to no more have the required resources on my
laptop to build lintian — it wanted to install nearly 1 TB of
additional build-dependencies.

And just calling

  $ debian/rules runtests onlyrun=tag:odd-place-for-manual-page

still seems to try to build all 1189 test case source packages instead
of just those few needed for the checks related to this tag.

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

Bug#937009: [Python-apps-team] Bug#937009: mercurial: Python2 removal in sid/bullseye

[Sandro Tosi]

> Yeah basically fixing the RC bug in sid took priority and then I ran out
> of steam before merging back to experimental.  I also want to figure out
> how to deal with #961245 there going forward.

I've merged debian/master into debian/experimental, merged the changes
done in 5.4-1+exp1 and uploaded the result to experimental

> > Do you need any help in coordinating with the packaged extensions,
> > testing changes, preparing patches? a lot of time has passed since we
> > started asking about mercurial and python3 and it is becoming the only
> > reverse-dependency of several packages that could be removed if
> > mercurial switched to py3k.
> >
> Getting an uptodate list of extensions and their status wrt porting both
> upstream and in Debian would be useful.  I've spent some time looking at
> hgsubversion a few weeks ago but there's a ton of work and I don't
> actually use it so I've kind of given up on that; I forget what the
> status is on others.

will look into the rdeps of mercurial once 5.4.1-1+exp1 hits the archive

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#964282: lintian: tried to issue unknown tags: manpage-in-wrong-directory at /usr/share/perl5/Lintian/Group.pm line 451.

[Axel Beckert]

Package: lintian
Version: 2.82.0
Severity: important

Hi,

after trying to rename man page sections in lintian by just renaming the
files and putting them in the right directory, and then running lintian
over the resulting package, lintian seems to have crashed as follows:

Now running lintian -iIE --pedantic wml_2.28.0~ds1-1_amd64.changes ...
Warning in group wml/2.28.0~ds1-1: Check documentation/manual has no tag 
manpage-in-wrong-directory. at /usr/share/perl5/Lintian/Check.pm line 147.
tried to issue unknown tags: manpage-in-wrong-directory at 
/usr/share/perl5/Lintian/Group.pm line 451.
Lintian::Group::process(Lintian::Group=HASH(0x5588ced83078), 
HASH(0x5588cdf6fed8), HASH(0x5588cde600d8), 
Lintian::Output::Standard=HASH(0x5588cdf32178)) called at 
/usr/share/perl5/Lintian/Pool.pm line 179
Lintian::Pool::process(Lintian::Pool=HASH(0x5588cdf53710), 
Lintian::Profile=HASH(0x5588cefb8af0), SCALAR(0x5588cef5cd68), 
HASH(0x5588cde600d8), GLOB(0x5588ccecc810), 
Lintian::Output::Standard=HASH(0x5588cdf32178)) called at 
/usr/share/lintian/commands/lintian.pm line 778
main::main() called at /usr/bin/lintian line 47
eval {...} called at /usr/bin/lintian line 47
main::__ANON__("/usr/share/lintian/commands/lintian.pm") called at 
/usr/bin/lintian line 120
dplint::run_tool("/usr/bin/lintian", "lintian") called at 
/usr/bin/lintian line 299
dplint::main() called at /usr/bin/lintian line 383
Finished running lintian.

This tag seems to have been renamed to odd-place-for-manual-page.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils  2.34-8
ii  bzip2 1.0.8-3
ii  diffstat  1.63-1
ii  dpkg  1.20.3
ii  dpkg-dev  1.20.3
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdigest-sha-perl6.02-1+b2
ii  libdpkg-perl  1.20.3
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libsereal-decoder-perl4.014+ds-1
ii  libsereal-encoder-perl4.014+ds-1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  man-db2.9.3-1
ii  patchutils0.3.4-3
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
ii  binutils-multiarch 2.34-8
ii  libtext-template-perl  1.58-1

-- no debconf information

Bug#964277: picard: Current version is unusable due to GUI glitches

[eb]

Package: picard
Version: 2.3.2-1
Severity: important

Dear Maintainer,

After the last upgrade, Picard become unusable due to GUI glitches. I
have enclosed the screenshot: 
https://send.firefox.com/download/e8d7329716e621cf/#UPOxBekz4X4erd3rcdRnLQ
Briefly, folder/files/button cannot be pressed correctly, GUI is
misaligned, toolbar icons are overlaping, etc.
Kind regards,
EB

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/48 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) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages picard depends on:
ii  libc6 2.30-8
ii  libchromaprint-tools  1.5.0-1
ii  python3   3.8.2-3
ii  python3-libdiscid 1.1-1+b2
ii  python3-mutagen   1.44.0-1
ii  python3-pyqt5 5.15.0+dfsg-1+b1

Versions of packages picard recommends:
ii  libqt5multimedia5-plugins   5.14.2-2
ii  python3-pyqt5.qtmultimedia  5.15.0+dfsg-1+b1

Versions of packages picard suggests:
ii  hicolor-icon-theme  0.17-2

-- no debconf information

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

When you say "write a proper source package ", are you referring to the
actual ".deb"  package ? or something else ?

Bottom line : What is actually needed ? I mean, in concrete terms ?
Something I can actually type on a command line ? 


On 2020-07-04 21:23, Andrey Rahmatullin wrote:

On Sat, Jul 04, 2020 at 08:39:36PM +0100, Joan Moreau wrote: 


(1) As a "software provider", what files are expected (besides the
sources, the Makefile and the binary) ? ( please kindly refer to :
https://github.com/grosjo/tomboy-reborn )

The sources and the build system to build them. Binaries should never be
shipped in the sources.


(2) As a "package maintainer" , the error below keeps poping up, so most
probably I am missing something

I have no idea what does debmake do when you already have some files in
debian/. The doc you are reading certainly doesn't expect that.


How to concretely create the ".deb" package (which tool does create the
deb format, what does it contains really )besides the theory not
describing the actual content) ), so I can pack it directly ?

You don't need to "pack the deb directly", you already have your deb from
checkinstall. On the other hand, if you want a proper package acceptable
in Debian, you shouldn't "pack the deb directly" but write a proper source
package.

Bug#963180: automake-1.16 could NOT build with DEB_BUILD_PROFILE=stage1

[Đoàn Trần Công Danh]

On 2020-07-04 18:32:23-0400, Eric Dorland  wrote:
> Is this a bug in debhelper? If you're asking for nodoc build, why
> would dh_installinfo want to install anything?

I'm not very familiar with Debian build process.
But, it seems like you're right.

Would you mind forwarding this bug to debhelper team?

> 
> * Đoàn Trần Công Danh (sgn.d...@gmail.com) wrote:
> > Package: automake
> > Version: 1.16.1-4
> > 
> > Step to procedure:
> > 
> > $ export DEB_BUILD_PROFILE=stage1
> > $ # Below is none-complete, filled all no-profiles from
> > $ # https://wiki.debian.org/BuildProfileSpec
> > $ export DEB_BUILD_PROFILES=stage1,nodoc,nocheck,nobiarch
> > $ dpkg-buildpackage
> > 
> > dh_installinfo complains that doc/automake-1.16.info not found.
> > 
> > I need this patch:
> > 8<
> > --- debian/rules.orig   2020-06-20 13:47:36.551860112 +0700
> > +++ debian/rules2020-06-20 13:48:07.398980348 +0700
> > @@ -30,6 +30,7 @@
> >  override_dh_auto_build:
> >  ifeq ($(DEB_BUILD_PROFILE),stage1)
> > touch doc/automake.info
> > +   cp doc/automake.info doc/automake-$(version).info
> >  endif
> > dh_auto_build
> >  
> > >8--
> > 
> 
> -- 
> Eric Dorland 
> 43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93



-- 
Danh


signature.asc
Description: PGP signature

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

Hello, 

Concretely: 


(1) As a "software provider", what files are expected (besides the
sources, the Makefile and the binary) ? ( please kindly refer to :
https://github.com/grosjo/tomboy-reborn ) 


(2) As a "package maintainer" , the error below keeps poping up, so most
probably I am missing something 


How to concretely create the ".deb" package (which tool does create the
deb format, what does it contains really )besides the theory not
describing the actual content) ), so I can pack it directly ? 

Thank you very much 


On 2020-07-04 18:16, Andrey Rahmatullin wrote:

On Sat, Jul 04, 2020 at 06:06:05PM +0100, Joan Moreau wrote: 


Input file sare visibles on
https://github.com/grosjo/tomboy-reborn/tree/master/packages

You are supposed to include thesoftware source in the package, not this.
So debian/ should be in the root of the repo.


This is the exact ouptut I get (from debuild -d)

I: check_all_licenses completed for 32 files.
I: bunch_all_licenses
I: format_all_licenses
I: make debian/* template files
I: found "debian/changelog"
I: debmake -x "0" ...
I: skipping :: debian/control (file exists)
I: creating => debian/copyright
I: substituting => /usr/share/debmake/extra0/rules
I: skipping :: debian/rules (file exists)
I: substituting => /usr/share/debmake/extra0/changelog
I: skipping :: debian/changelog (file exists)

You aren't supposed to run debmake with debian/ already existing.

Bug#964281: lintian: tag national-encoding emitted for patches fixing this tag

[Axel Beckert]

Package: lintian
Version: 2.82.0
Severity: normal

Because lintian emitted the national-encoding tag for a bunch of
upstream files, I added a patch which fixes this.

Now lintian complains about that patch:

W: wml source: national-encoding 
debian/patches/change-national-encoding-to-utf-8.patch

IMHO files under debian/patches should be either completely excluded
from this tag or (less trivial) only the DEP3 headers in these files
should be checked for containing national encoding.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils  2.34-8
ii  bzip2 1.0.8-3
ii  diffstat  1.63-1
ii  dpkg  1.20.3
ii  dpkg-dev  1.20.3
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdigest-sha-perl6.02-1+b2
ii  libdpkg-perl  1.20.3
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libsereal-decoder-perl4.014+ds-1
ii  libsereal-encoder-perl4.014+ds-1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  man-db2.9.3-1
ii  patchutils0.3.4-3
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
ii  binutils-multiarch 2.34-8
ii  libtext-template-perl  1.58-1

-- no debconf information

Bug#963121: systemd: Systemd hangs 90 seconds on AUTHENTICATING at shutdown/restart

[Michael Biebl]

This looks like you are using GNOME where the login session is managed
by systemd --user. Is that correct?

I fail to see the systemd bug here, just some services that don't
terminate properly and are killed after the user 90s timeout.
Can you elaborate?



signature.asc
Description: OpenPGP digital signature

Bug#963135: systemd: logind parameters "IdleAction=Lock" is not working

[Michael Biebl]

Hello

Am 19.06.20 um 16:09 schrieb venkat:
> 
> 
> I have seen the source code and after applying the below change the "Lock"
> event is working,
> 
> 
> diff --git a/src/login/logind.c b/src/login/logind.c
> index 95ec0a57c6..ea505ceed8 100644
> --- a/src/login/logind.c
> +++ b/src/login/logind.c
> @@ -1019,7 +1019,7 @@ static int manager_dispatch_idle_action(sd_event_source
> *s, uint64_t t, void *us
>  (m->idle_action_not_before_usec <= 0 || n >=
> m->idle_action_not_before_usec + m->idle_action_usec)) {
>  log_info("System idle. Taking action.");
> 
> -manager_handle_action(m, 0, m->idle_action, false,
> false);
> +manager_handle_action(m, 0, m->idle_action, false,
> true);
>  m->idle_action_not_before_usec = n;
>  }
> 
> 
> Is there any specific reason blocking the "Lock" action in the source code?
> If not, can this change will apply in upstream or at least as configurable.

I see that the relevant code is still unchanged in v245, the latest
upstream release. Could you please raise this upstream at
https://github.com/systemd/systemd and submit your change as PR.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#964280: DDPO: lintian links no longer work

[Eric Dorland]

Package: qa.debian.org
Severity: normal

For example, the link for the package "dnscrypt-proxy" is 
https://lintian.debian.org/reports/maintainer/eric%40debian.org.html#dnscrypt-proxy,
 which returns a 404. It looks like there are now links for source packages 
like https://lintian.debian.org/sources/dnscrypt-proxy.html that should be easy 
to use instead.

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

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

Bug#963180: automake-1.16 could NOT build with DEB_BUILD_PROFILE=stage1

[Eric Dorland]

Is this a bug in debhelper? If you're asking for nodoc build, why
would dh_installinfo want to install anything?

* Đoàn Trần Công Danh (sgn.d...@gmail.com) wrote:
> Package: automake
> Version: 1.16.1-4
> 
> Step to procedure:
> 
>   $ export DEB_BUILD_PROFILE=stage1
>   $ # Below is none-complete, filled all no-profiles from
>   $ # https://wiki.debian.org/BuildProfileSpec
>   $ export DEB_BUILD_PROFILES=stage1,nodoc,nocheck,nobiarch
>   $ dpkg-buildpackage
> 
> dh_installinfo complains that doc/automake-1.16.info not found.
> 
> I need this patch:
> 8<
> --- debian/rules.orig 2020-06-20 13:47:36.551860112 +0700
> +++ debian/rules  2020-06-20 13:48:07.398980348 +0700
> @@ -30,6 +30,7 @@
>  override_dh_auto_build:
>  ifeq ($(DEB_BUILD_PROFILE),stage1)
>   touch doc/automake.info
> + cp doc/automake.info doc/automake-$(version).info
>  endif
>   dh_auto_build
>  
> >8--
> 

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#964279: [deluge] TypeError: '>' not supported between instances of 'NoneType' and 'NoneType'

[Lyndon Brown]

Package: deluge-gtk
Version: 2.0.3-2

finding a lot of this in my system log (logged as deluge.desktop):

TypeError: '>' not supported between instances of 'NoneType' and
'NoneType'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/listview.py",
line 233, in stabilized
result = sort_func(model, iter1, iter2, data)
  File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/torrentview.py",
line 106, in progress_sort
return cmp(state1, state2)
  File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/common.py", line
45, in cmp
return (x > y) - (x < y)

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Andrey Rahmatullin]

On Sat, Jul 04, 2020 at 09:35:15PM +0100, Joan Moreau wrote:
> When you say "write a proper source package ", are you referring to the
> actual ".deb"  package ? or something else ?
I'm referring to a Debian source package. I've already linked you to
https://wiki.debian.org/Packaging/SourcePackage. All the docs about Debian
packaging describe creating a source package and then building it to get a
.deb which is a binary package.

> Bottom line : What is actually needed ? I mean, in concrete terms ?
A Debian source package. To get it you need an orig tarball with upstream
sources and a debian/ directory.

> Something I can actually type on a command line ?
No.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#964145: chromium: high cpu load and frequent crashes

[Hewa Saleem]

Package: chromium
Version: 83.0.4103.116-1~deb10u1
Followup-For: Bug #964145

Dear Maintainer,

An upgrade to 83.0.4103.116-1~deb10u1 led to unexpected experiences.
The browser is very slow and crashes frequently. It became useless.


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

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

Versions of packages chromium depends on:
ii  chromium-common  83.0.4103.116-1~deb10u1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1.4-1~deb10u1
ii  libavformat587:4.1.4-1~deb10u1
ii  libavutil56  7:4.1.4-1~deb10u1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcups2 2.2.10-6+deb10u3
ii  libdbus-1-3  1.12.16-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-2+deb10u1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgbm1  18.3.6-2+deb10u1
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6+deb10u1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42.1-1+deb10u2
ii  libopenjp2-7 2.3.0-2+deb10u1
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpulse012.2-4+deb10u1
ii  libre2-5 20190101+dfsg-2
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.3.0-6
ii  libvpx5  1.7.0-3+deb10u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb-dri3-01.13.1-2
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2.2~deb10u1
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  83.0.4103.116-1~deb10u1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1+deb10u1

Versions of packages chromium-common recommends:
ii  chromium-sandbox 83.0.4103.116-1~deb10u1
ii  fonts-liberation 1:1.07.4-9
ii  libgl1-mesa-dri  18.3.6-2+deb10u1
ii  libu2f-udev  1.1.9-1
ii  notification-daemon  3.20.0-4
ii  upower   0.99.10-1

Versions of packages chromium-sandbox depends on:
ii  libc6  2.28-10

-- no debconf information

Bug#962353: django-js-reverse: diff for NMU version 0.7.3-1.1

[Adrian Bunk]

Control: tags 962353 + patch
Control: tags 962353 + pending

Dear maintainer,

I've prepared an NMU for django-js-reverse (versioned as 0.7.3-1.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should
cancel it.

cu
Adrian
diff -Nru django-js-reverse-0.7.3/debian/changelog django-js-reverse-0.7.3/debian/changelog
--- django-js-reverse-0.7.3/debian/changelog	2018-01-04 15:32:41.0 +0200
+++ django-js-reverse-0.7.3/debian/changelog	2020-07-05 00:06:24.0 +0300
@@ -1,3 +1,10 @@
+django-js-reverse (0.7.3-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Remove the unused phantomjs build dependency. (Closes: #962353)
+
+ -- Adrian Bunk   Sun, 05 Jul 2020 00:06:24 +0300
+
 django-js-reverse (0.7.3-1) unstable; urgency=low
 
   * Initial release (Closes: #876505)
diff -Nru django-js-reverse-0.7.3/debian/control django-js-reverse-0.7.3/debian/control
--- django-js-reverse-0.7.3/debian/control	2018-01-04 14:05:02.0 +0200
+++ django-js-reverse-0.7.3/debian/control	2020-07-05 00:06:23.0 +0300
@@ -5,7 +5,6 @@
 Uploaders: Hans-Christoph Steiner 
 Build-Depends: debhelper (>=9),
dh-python,
-   phantomjs,
python3-all,
python3-django (>= 1.5),
python3-selenium,

Bug#938587: sugar-etoys-activity: Python2 removal in sid/bullseye - reopen 938587

[Adrian Bunk]

On Fri, Jun 19, 2020 at 10:40:58PM -0400, Sandro Tosi wrote:
> Control: reopen -1
> 
> This bug was closed, but the package has still some dependencies towards
> Python2 packages, in details:
> 
> (binary:sugar-etoys-activity)Depends->python
> 
> Re-opening, so that they can be taken care of.

I wonder what is going on here:

The manual dependency on python is still there, and no dependency
on python3 is being generated.

The only usage of python in the package appears to be:

$ cat /usr/share/sugar/activities/Etoys.activity/setup.py
#!/usr/bin/env python
from sugar3.activity import bundlebuilder
$ 


cu
Adrian

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

Input file sare visibles on
https://github.com/grosjo/tomboy-reborn/tree/master/packages 

This is the exact ouptut I get (from debuild -d) 


I: check_all_licenses completed for 32 files.
I: bunch_all_licenses
I: format_all_licenses
I: make debian/* template files
I: found "debian/changelog"
I: debmake -x "0" ...
I: skipping :: debian/control (file exists)
I: creating => debian/copyright
I: substituting => /usr/share/debmake/extra0/rules
I: skipping :: debian/rules (file exists)
I: substituting => /usr/share/debmake/extra0/changelog
I: skipping :: debian/changelog (file exists)
I: run "debmake -x1" to get more template files
I: $ wrap-and-sort
dpkg-buildpackage -d -us -uc -ui
dpkg-buildpackage: info: source package tomboy-reborn
dpkg-buildpackage: info: source version 1.0.0-1
dpkg-buildpackage: info: source distribution stable
dpkg-buildpackage: info: source changed by Joan Moreau 
dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
fakeroot debian/rules clean
dh clean
dh: Please specify the compatibility level in debian/compat
make: *** [debian/rules:18: clean] Error 255
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess
returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -d -us -uc -ui failed 

Thank you so much 


On 2020-07-04 17:57, Joan Moreau wrote:

Is there a web page stating the steps to go through, without all this complexity ? 

similar to the Arch  : https://wiki.archlinux.org/index.php/AUR_submission_guidelines 

On 2020-07-04 17:43, Andrey Rahmatullin wrote: 
On Sat, Jul 04, 2020 at 05:38:05PM +0100, Joan Moreau wrote: Let's imagine I found it (using lazbuild most probably), then where

should I put that command ? override_dh_auto_build, assuming you use dh(1)

How to specifiy the options needed ? As usual in the command arguments.

where to put lazarus is required ? 
Build-Depends.


Following
https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html#step-upstream,
I am getting the error "Please specify the compatibilitle level in
debian/compat' (meaning what should I write where ?) debmake would create that 
file for you, so I'm not sure what exactly did
you do.

Bug#964278: linux-image-5.7.0-1-amd64

[klak]

Package:linux-image-5.7.0-1-amd64
Version:5.7.6.1

Without words:

[Fr Jul  3 00:36:32 2020] BUG: kernel NULL pointer dereference,address: 
0010
[Fr Jul  3 00:36:32 2020] #PF: supervisor read access in kernel mode
[Fr Jul  3 00:36:32 2020] #PF: error_code(0x) - not-present page
[Fr Jul  3 00:36:32 2020] PGD 0 P4D 0
[Fr Jul  3 00:36:32 2020] Oops:  [#1] SMP NOPTI
[Fr Jul  3 00:36:32 2020] CPU: 0 PID: 2046 Comm:nfsd Not tainted 5.7.0-1-amd64 
#1 Debian 5.7.6-1
[Fr Jul  3 00:36:32 2020] Hardware name: ASUS All Series/X99-E-10G WS,BIOS 1201 
05/27/2019 [Fr Jul  3 00:36:32 2020]
RIP:0010:__cgroup_bpf_run_filter_skb+0x26b/0x3d0
[Fr Jul  3 00:36:32 2020]Code: 44 24 4c 48 8b 44 24 08 48 c7 00 00 00 00 00 48 
c7 40 08 00 00 00
00 c7 40 10 00 00 00 00 e9 c5 fe ff ff 48 8b 86 20 06 00 00 <4c> 8b 70
10 48 8d 68 10 4d 85 f6 0f 84 3a 01 00 00 49 8d 47 30 31
[Fr Jul  3 00:36:32 2020] RSP: 0018:ab0a83853a38 EFLAGS: 00010246
[Fr Jul  3 00:36:32 2020] RAX:  RBX:  RCX: 
0034
[Fr Jul  3 00:36:32 2020] RDX:  RSI: 9d179a1ca000 RDI: 
9d1784c15780
[Fr Jul  3 00:36:32 2020] RBP: 9d1784c15780 R08: 9d12dc817ae0 R09: 
ab0a83853af0
[Fr Jul  3 00:36:32 2020] R10: 0080 R11: ab0a83853e50 R12: 
9d12dc817ae0
[Fr Jul  3 00:36:32 2020] R13: 0001 R14:  R15: 
9d12dc817ae0
[Fr Jul  3 00:36:32 2020] FS: ()
GS:9d1fbfa0() knlGS:
[Fr Jul  3 00:36:32 2020] CS:  0010 DS:  ES:  CR0: 80050033
[Fr Jul  3 00:36:32 2020] CR2: 0010 CR3: 000689b30002
CR4: 003626f0
[Fr Jul  3 00:36:32 2020] DR0:  DR1: 
DR2: 
[Fr Jul  3 00:36:32 2020] DR3:  DR6: fffe0ff0
DR7: 0400
[Fr Jul  3 00:36:32 2020] Call Trace:
[Fr Jul  3 00:36:32 2020]  ?nft_do_chain_ipv4+0x66/0x80 [nf_tables]
[Fr Jul  3 00:36:32 2020]  ip_finish_output+0x68/0xa0
[Fr Jul  3 00:36:32 2020]  ip_output+0x76/0xf0
[Fr Jul  3 00:36:32 2020]  ?__ip_finish_output+0x1e0/0x1e0
[Fr Jul  3 00:36:32 2020]  __ip_queue_xmit+0x16c/0x420
[Fr Jul  3 00:36:32 2020]  __tcp_transmit_skb+0x541/0xb30
[Fr Jul  3 00:36:32 2020]  tcp_write_xmit+0x378/0x11b0
[Fr Jul  3 00:36:32 2020]  __tcp_push_pending_frames+0x32/0xf0
[Fr Jul  3 00:36:32 2020]  tcp_sendmsg_locked+0xc36/0xdb0
[Fr Jul  3 00:36:32 2020]  ? nfsd_setuser+0xb0/0x270 [nfsd]
[Fr Jul  3 00:36:32 2020]  tcp_sendmsg+0x28/0x40
[Fr Jul  3 00:36:32 2020]  sock_sendmsg+0x57/0x60
[Fr Jul  3 00:36:32 2020]  xprt_sock_sendmsg+0x119/0x320 [sunrpc]
[Fr Jul  3 00:36:32 2020]  svc_tcp_sendto+0x6f/0xc0 [sunrpc]
[Fr Jul  3 00:36:32 2020]  svc_send+0x7c/0x1a0 [sunrpc]
[Fr Jul  3 00:36:32 2020]  nfsd+0xe3/0x140 [nfsd]
[Fr Jul  3 00:36:32 2020]  kthread+0xf9/0x130
[Fr Jul  3 00:36:32 2020]  ? nfsd_destroy+0x50/0x50 [nfsd]
[Fr Jul  3 00:36:32 2020]  ? kthread_park+0x90/0x90
[Fr Jul  3 00:36:32 2020]  ret_from_fork+0x1f/0x40
[Fr Jul  3 00:36:32 2020] Modules linked in: rpcsec_gss_krb5 nfsv4
dns_resolver nfsv3 nfs fscache vfio_pci vfio_virqfd vfio_iommu_type1
vfio vhost_net v


Greets from Germany
klak

Bug#964145: chromium: an upgrade to "83.0.4103.116" led to unexpected experiences. The Browser became useless.

[Hewa Saleem]

Package: chromium
Version: 83.0.4103.116-1~deb10u1
Followup-For: Bug #964145

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)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages chromium depends on:
ii  chromium-common  83.0.4103.116-1~deb10u1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1.4-1~deb10u1
ii  libavformat587:4.1.4-1~deb10u1
ii  libavutil56  7:4.1.4-1~deb10u1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcups2 2.2.10-6+deb10u3
ii  libdbus-1-3  1.12.16-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-2+deb10u1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgbm1  18.3.6-2+deb10u1
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6+deb10u1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42.1-1+deb10u2
ii  libopenjp2-7 2.3.0-2+deb10u1
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpulse012.2-4+deb10u1
ii  libre2-5 20190101+dfsg-2
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.3.0-6
ii  libvpx5  1.7.0-3+deb10u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb-dri3-01.13.1-2
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2.2~deb10u1
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  83.0.4103.116-1~deb10u1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1+deb10u1

Versions of packages chromium-common recommends:
ii  chromium-sandbox 83.0.4103.116-1~deb10u1
ii  fonts-liberation 1:1.07.4-9
ii  libgl1-mesa-dri  18.3.6-2+deb10u1
ii  libu2f-udev  1.1.9-1
ii  notification-daemon  3.20.0-4
ii  upower   0.99.10-1

Versions of packages chromium-sandbox depends on:
ii  libc6  2.28-10

-- no debconf information

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

Is there a web page stating the steps to go through, without all this
complexity ? 


similar to the Arch  :
https://wiki.archlinux.org/index.php/AUR_submission_guidelines 


On 2020-07-04 17:43, Andrey Rahmatullin wrote:

On Sat, Jul 04, 2020 at 05:38:05PM +0100, Joan Moreau wrote: 


Let's imagine I found it (using lazbuild most probably), then where
should I put that command ?

override_dh_auto_build, assuming you use dh(1)


How to specifiy the options needed ?

As usual in the command arguments.


where to put lazarus is required ?


Build-Depends.


Following
https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html#step-upstream,
I am getting the error "Please specify the compatibilitle level in
debian/compat' (meaning what should I write where ?)

debmake would create that file for you, so I'm not sure what exactly did
you do.

Bug#964276: ngircd: FTBFS on IPv6-only hosts

[Niko Tyni]

Source: ngircd
Version: 25-3
Severity: serious
Tags: ftbfs

This package fails to build from source on IPv6-only hosts, including
some of the official buildds. It looks like the 26-1 build failures
on armel and amd64 are because of this, but I've verified that 25-3 is
also affected.

  running whois-test ... failure!
  FAIL: whois-test
  running server-link-test ... failure!
  FAIL: server-link-test

This should be reproducible with something like

  # unshare -n
  # ip li set lo up
  # ip dev add dummy0 type dummy
  # ip li set dummy0 up

and probably comes from passing the AI_ADDRCONFIG hint flag to
getaddrinfo(3) so it only returns IPv6 addresses on IPv6-only hosts,
even for 'localhost'.

 src/ngircd/resolve.c:249:   hints.ai_flags = AI_ADDRCONFIG;

-- 
Niko Tyni   nt...@debian.org

Bug#964031: src:viking: New version 1.8 available; offer to help maintain viking

[Bernd Zeimetz]

Hi,

thanks a lot!

Bernd

On 2020-07-02 22:13, Paul Gevers wrote:

Hi Bernd,

On 30-06-2020 22:52, Bernd Zeimetz wrote:
so you should have access - please just do whatever is necessary if 
you

have the time.


Done.

Paul


--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

Let's imagine I found it (using lazbuild most probably), then where
should I put that command ? 

How to specifiy the options needed ? where to put lazarus is required ? 


Following
https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html#step-upstream,
I am getting the error "Please specify the compatibilitle level in
debian/compat' (meaning what should I write where ?) 


On 2020-07-04 17:07, Andrey Rahmatullin wrote:

On Sat, Jul 04, 2020 at 04:57:37PM +0100, Joan Moreau wrote: 


Hi Boyuan,

Thank you so much for your feedback.

The program is to be compiled with Lazarus
(https://packages.debian.org/buster/lazarus-ide ), this is pretty
straighforward for anyone willing to compile from source.

SHould I put "lazarus" somewhere ? where ?

You need to find out how to build the project without launching the IDE.
There are suggestions regarding that in another email.

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Andrey Rahmatullin]

On Sat, Jul 04, 2020 at 08:39:36PM +0100, Joan Moreau wrote:
> (1) As a "software provider", what files are expected (besides the
> sources, the Makefile and the binary) ? ( please kindly refer to :
> https://github.com/grosjo/tomboy-reborn )
The sources and the build system to build them. Binaries should never be
shipped in the sources.

> (2) As a "package maintainer" , the error below keeps poping up, so most
> probably I am missing something
I have no idea what does debmake do when you already have some files in
debian/. The doc you are reading certainly doesn't expect that.

> How to concretely create the ".deb" package (which tool does create the
> deb format, what does it contains really )besides the theory not
> describing the actual content) ), so I can pack it directly ?
You don't need to "pack the deb directly", you already have your deb from
checkinstall. On the other hand, if you want a proper package acceptable
in Debian, you shouldn't "pack the deb directly" but write a proper source
package.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#964260: reportbug: add info to help page about how to see what bts' are available

[florine forine]

Package: reportbug
Version: 7.6.0+devuan1
Severity: wishlist

Dear Maintainer,

When calling "reportbug --help" there should be a hint that
"reportbug --bts help" gives a list of available bts'.

-- Package-specific info:
** Environment settings:
EDITOR="vim"
INTERFACE="text"

-- System Information:
Debian Release: bullseye/sid


signature.asc
Description: PGP signature

Bug#964275: flowblade: the package is missing the helpfiles

[M. Dietrich]

Package: flowblade
Version: 2.4.0.1-2
Severity: normal

flowblade opens a helpfile
/usr/share/flowblade/Flowblade/res/help/en/help.html which is
not contained in the package.

-- System Information:
Debian Release: bullseye/sid
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages flowblade depends on:
ii  frei0r-plugins1:1.4-dmo4
ii  gir1.2-gdkpixbuf-2.0  2.40.0+dfsg-5
ii  gir1.2-glib-2.0   1.64.1-1
ii  gir1.2-gtk-3.03.24.20-1
ii  gir1.2-pango-1.0  1.44.7-4
ii  gmic  2.4.5-1.1
ii  libmlt-data   1:0.9.6-dmo1
ii  librsvg2-common   2.48.7-1
ii  python3   3.8.2-3
ii  python3-cairo 1.16.2-3
ii  python3-dbus  1.2.16-2
ii  python3-distutils 3.8.3-2
ii  python3-gi3.36.0-3
ii  python3-gi-cairo  3.36.0-3
ii  python3-mlt   6.20.0-2+b1
ii  python3-numpy 1:1.19.0-1
ii  python3-opencv4.2.0+dfsg-6+b1
ii  python3-pil   7.0.0-4+b1
ii  swh-plugins   0.4.17-2

flowblade recommends no packages.

flowblade suggests no packages.

-- debconf-show failed

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

Hi Boyuan, 

Thank you so much for your feedback. 


The program is to be compiled with Lazarus
(https://packages.debian.org/buster/lazarus-ide ), this is pretty
straighforward for anyone willing to compile from source. 

SHould I put "lazarus" somewhere ? where ? 

Thank you 


On 2020-07-04 16:28, Boyuan Yang wrote:


Hi Joan,

在 2020-07-04星期六的 13:23 +0100，Joan Moreau写道： 


Hi Evangelos

Found also this page 
https://coderwall.com/p/urkybq/how-to-create-debian-package-from-source


It contains 3 files
- the binary (to go into /usr/bin)
- the icon
- the .desktop file

The sources are here : https://github.com/grosjo/tomboy-reborn

How to know the files needed, and is there "tar" or similar software
to create the ".deb" file form a files tree ?


Disclaimer -- I'm providing you with some information that you might be
missing instead of trying to push this packaging process forward.

It looks like you are in lack of 2 large pieces of knowledge that is
critical to do a proper packaging:

(1) How to act properly as a software upstream, by providing a
functioning build system that can automatically convert source code
into binaries as well as providing handy instructions to install built
binaries into the system. This kind of buildsystem is often achieved
through a build automation software and you may find a list at 
https://en.wikipedia.org/wiki/List_of_build_automation_software .


(2) How to act properly as a downstream (Debian) packager on top of
upstream build system.

These 2 parts are separated but both essential when trying to create a
good software package. The fact that you are using a non-mainstream
programming language (Pascal) further complicates the situation.

From the very beginning (part (1)), you need a proper building system
in your upstream project, https://github.com/grosjo/tomboy-reborn .
Works in part (1) has nothing to do with Debian or any specific Linux
distributions.

In your case, I do not see any build system in your source code
repository. There is a built binary file but there's no script or
instructions describing how the built binary was generated. I have
absolutely no idea how you were building the Pascal source code into
binaries. My best guess is that you are using the building function
embedded in Lazarus IDE -- which is completely unacceptable since a
working build system should be fully automated and require no graphical
IDE tool to function well. It could be a handwritten Makefile, CMake-
based solutions, Meson-based solutions or something else. Since you are
using Pascal, I do not know what proper buildsystem should I recommend.
(If you are using a mainstream programming language like C, C++, C# or
even Python or Java, the buildsystem solution is largely known:
Makefile, CMake, Meson, python-setuptools, Maven, Gradle, etc.)
However, there are several existing Pascal-written software in Debian
and other Linux distributions. It might be easier for you to see what
other Pascal projects are using and do in a similar way. There is also
a Debian Pascal Team [1 [1]] and you may get some help from team members.
Remember that in part (1) you are acting as an upstream software
developer; if necessary, you may refer to Debian's guide to upstream
software developers at [2 [2]].

[1] 
https://qa.debian.org/developer.php?email=pkg-pascal-devel%40lists.alioth.debian.org

[2] https://wiki.debian.org/UpstreamGuide

For the latter part (part (2)), you will finally act as a downstream
software packager. we can discuss it later after you have a functioning
buildsystem. It won't be difficult as long as your build system is
sane. In any case, using prebuilt binaries from upstream is
unacceptable: Debian dislikes this and holds a view that any binaries should be 
generated (automatically) from source code at _build_ time.

I hope those information could be useful to you.



Links:
--
[1]
https://qa.debian.org/developer.php?email=pkg-pascal-devel%40lists.alioth.debian.org
[2] https://wiki.debian.org/UpstreamGuide

Bug#964259: libseccomp2 upgraded from 2.4.1-0ubuntu0.18.04.2 => 2.4.3-1ubuntu3.18.04.2 , logwatch service stopped

[Ramblin2Day]

Package: libseccomp2
Version: 2.3.3-4
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)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages libseccomp2 depends on:
ii  libc6  2.28-10

libseccomp2 recommends no packages.

libseccomp2 suggests no packages.

-- no debconf information

I have created a custom service under logwatch to monitor the emails sent via 
msmtp

The logwatch service was working perfectly until July 2 when the ONLY change to 
the system was an unattended-upgrades upgrade to libsecccomp2
which I was notified went from "Upgraded: libseccomp2:amd64 
2.4.1-0ubuntu0.18.04.2 => 2.4.3-1ubuntu3.18.04.2" 

After July 2, logwatch contined to run but the custom service no longer 
reported.

I see there is another issue with libseccomp2 in the Ubuntu bug reports at
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1886115
but the suggested downgrade of libsecccomp2 did not work for me since it could 
not find the suggested downgrades.
I am running Debain 10 with no Desktop interface as a server for an 
appache-based web site
so Ubuntu is not the issue; I just include the above as reference

This is my first submission of a bug to you so if there is information missing, 
please advise and I will fill it in.

Bug#964274: ruby-websocket-extensions: CVE-2020-7663

[Salvatore Bonaccorso]

Source: ruby-websocket-extensions
Version: 0.1.2-1
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for ruby-websocket-extensions.

CVE-2020-7663[0]:
| websocket-extensions ruby module prior to 0.1.5 allows Denial of
| Service (DoS) via Regex Backtracking. The extension parser may take
| quadratic time when parsing a header containing an unclosed string
| parameter value whose content is a repeating two-byte sequence of a
| backslash and some other character. This could be abused by an
| attacker to conduct Regex Denial Of Service (ReDoS) on a single-
| threaded server by providing a malicious payload with the Sec-
| WebSocket-Extensions header.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-7663
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7663
[1] 
https://github.com/faye/websocket-extensions-ruby/security/advisories/GHSA-g6wq-qcwm-j5g2
[2] 
https://github.com/faye/websocket-extensions-ruby/commit/aa156a439da681361ed6f53f1a8131892418838b

Regards,
Salvatore

Bug#962021: forwarded upstream

[Bernhard M. Wiedemann]

https://gitlab.com/graphviz/graphviz/-/merge_requests/1454
was easy, because I had the forked repo still around

Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

[Sven Hoexter]

On Sat, Jul 04, 2020 at 02:49:15PM -0400, Nicholas D Steeves wrote:

Hi Nicholas,

> > Since people started to ping me about getting this one introduced
> > I now give in and pick it up. I plan to continue for now the
> > maintenance of the fuse-exfat and exfat-utils packages.
> > While fuse-exfat can be coinstalled at any moment exfat-utils and
> > exfatprogs will for now conflict with each other.
> > Maybe I later on drop the mkfs.exfat and fsck.exfat links from
> > the exfat-utils package.
> 
> Might /etc/alternatives also be considered for mkfs.exfat and
> fsck.exfat?
> Also, what about /sbin/mount.exfat?  That one also seems
> like a candicate for /etc/alternatives.

Yes I thought about it, I also thought about dropping the symlinks
similar to the mount.exfat helper issue with fuse-exfat.

Right now I believe we should cater for the general use cases which
probably is someone wanting to mount an exfat filesystem with the
most convenient and fast driver, which is the kernel based one.
So if you have a reason to still want to use the fuse driver you
make an explicit choice. That's when I expect you to be able to
invoke the mount.exfat-fuse helper.

One thing to note is that there is no alternative for the mount.exfat
helper, either it's there or it's not. Michael proposed a thin
wrapper in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963752
but I do not believe that helps the average user. That's why I droped
the symlink from the package.

Now back to the utils situation:
Here we could use alternatives, but I believe for the average user that
will be even more confusing. Luckily upstream of the exfatprogs
made the concious decision to not create a naming colision with the
existing exfat-utils package, so user have a chance to recognise
the different upstream sources. I believe it's more straight forward
to let the user select the implementation he prefers and just make
sure we do not have the naming conflict of the binaries.
The other, longterm more likely option from my point of
view, is to drop the mkfs.exfat and fsck.exfat links, and let the user
invoke exfatfsck and mkexfatfs binary provided by the package.

I do not want to make that change right now, and would prefer to
wait a bit if we see some bugs with the exfatprogs implementation,


> Probably tangential: I wonder if this is a case where a virtual package
> (where both the Samsung and the exfat-utils Provide exfat-tools or
> similar) could be considered?  As you know, I'm primarily interested in
> backports, and I wonder if whatever the kernel team does with Wireguard
> would be a useful precedent to follow.  eg: if newer kernels Provide:
> feature that that was previously wireguard-dkms.  'not sure if that's
> over-engineering dependency and feature resolution though ;-)

I believe the use case here is so narrow that we should keep it as simple
as possible.

Cheers,
Sven

Bug#964273: ITP: golang-github-brentp-vcfgo: Golang library to read, write, manipulate VCF format files

[Nilesh Patra]

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


* Package name: golang-github-brentp-vcfgo
  Version : 0.0~git20190824.654ed2e-1
  Upstream Author :  Brent Pedersen
* URL : https://github.com/brentp/vcfgo

* License : Expat
  Programming Lang: Golang
  Description : Golang library to read, write, manipulate VCF format
files

 Package vcfgo implements a Reader and Writer for variant
 call format. It eases reading, filtering modifying VCF's
 even if they are not to spec.
 .
 Status: vcfgo is well-tested, but still in development.
 It tries to tolerate, but report errors; after every
 rdr.Read() call, the caller can check rdr.Error() and
 get feedback on the errors without stopping
 execution unless it is explicitly requested to do so.

I shall maintain this package.

Bug#964271: golang-x-text: CVE-2020-14040

[Salvatore Bonaccorso]

Source: golang-x-text
Version: 0.3.2-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/golang/go/issues/39491
Control: clone -1 -2
Control: reassign -2 src:golang-golang-x-text 0.3.2-4
Control: retitle -2 golang-golang-x-text: CVE-2020-14040


Hi,

The following vulnerability was published for golang-x-text and
golang-golang-x-text.

CVE-2020-14040[0]:
| Go version v0.3.3 of the x/text package fixes a vulnerability in
| encoding/unicode that could lead to the UTF-16 decoder entering an
| infinite loop, causing the program to crash or run out of memory. An
| attacker could provide a single byte to a UTF16 decoder instantiated
| with UseBOM or ExpectBOM to trigger an infinite loop if the String
| function on the Decoder is called, or the Decoder is passed to
| golang.org/x/text/transform.String.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-14040
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14040
[1] https://github.com/golang/go/issues/39491
[2] https://go.googlesource.com/text/+/23ae387dee1f90d29a23c0e87ee0b46038fbed0e
[3] https://groups.google.com/forum/#!topic/golang-announce/bXVeAmGOqz0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

[Nicholas D Steeves]

Hi Sven,

s...@stormbind.net writes:

> * Package name: exfatprogs
[snip]
>
> Since people started to ping me about getting this one introduced
> I now give in and pick it up. I plan to continue for now the
> maintenance of the fuse-exfat and exfat-utils packages.
> While fuse-exfat can be coinstalled at any moment exfat-utils and
> exfatprogs will for now conflict with each other.
> Maybe I later on drop the mkfs.exfat and fsck.exfat links from
> the exfat-utils package.

Might /etc/alternatives also be considered for mkfs.exfat and
fsck.exfat?  Also, what about /sbin/mount.exfat?  That one also seems
like a candicate for /etc/alternatives.

Probably tangential: I wonder if this is a case where a virtual package
(where both the Samsung and the exfat-utils Provide exfat-tools or
similar) could be considered?  As you know, I'm primarily interested in
backports, and I wonder if whatever the kernel team does with Wireguard
would be a useful precedent to follow.  eg: if newer kernels Provide:
feature that that was previously wireguard-dkms.  'not sure if that's
over-engineering dependency and feature resolution though ;-)


Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#964270: salt: autopkgtest regression: [Errno 6] No such device or address

[Paul Gevers]

Source: salt
Version: 3001+dfsg1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of salt the autopkgtest of salt fails in testing
when that autopkgtest is run with the binary packages of salt from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
salt   from testing3001+dfsg1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=salt

https://ci.debian.net/data/autopkgtest/testing/amd64/s/salt/6135926/log.gz

==
ERROR: test_run_cwd_in_combination_with_runas
(unit.modules.test_cmdmod.CMDMODTestCase)
[CPU:0.0%|MEM:6.3%] cmd.run executes command in the cwd directory
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.vefy12bw/downtmp/autopkgtest_tmp/tests/unit/modules/test_cmdmod.py",
line 449, in test_run_cwd_in_combination_with_runas
runas = os.getlogin()
OSError: [Errno 6] No such device or address

--
Ran 9852 tests in 220.597s

FAILED (errors=1, skipped=2164, expected failures=1)
Exception ignored in: 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/transport/ipc.py", line 695,
in _read
TypeError: catching classes that do not inherit from BaseException is
not allowed
autopkgtest [15:28:11]: test unittest: ---]




signature.asc
Description: OpenPGP digital signature

Bug#356769: Antworten;;;;;;;;;;;

[James Adomako]

*Hallo, Ich heiße James Adomako. Ich habe Ihnen diese E-Mail vor einem
Monat gesendet, bin mir aber nicht sicher, ob Sie sie erhalten. Ich habe
wichtige Informationen in Bezug auf einen Fonds von $13.580.000,00 USD für
Sie, da Sie mit meinem verstorbenen Kunden denselben Nachnamen haben und
ich möchte, dass wir zusammenarbeiten, um den Fonds aus rechtlichen Gründen
zu unserem beiderseitigen Vorteil in Anspruch zu nehmen. Dies ist nur eine
kurze Information, antworten Sie für weitere Details. Ich entschuldige mich
für die Fehler, ich spreche und schreibe tatsächlich auf Englisch, ich habe
einen Online-Übersetzer benutzt.*

*Mit freundlichen Grüßen,*

*Fürsprecher Adomako James*

Bug#964269: src:cb2bib: fails to migrate to testing for too long: FTBFS on mips64el

[Paul Gevers]

Source: cb2bib
Version: 1.9.9-1
Severity: serious
Control: close -1 2.0.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:cb2bib in its
current version in unstable has been trying to migrate for 60 days [2].
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=cb2bib




signature.asc
Description: OpenPGP digital signature

Bug#964268: src:geary: fails to migrate to testing for too long: FTBFS on multiple archs: failing tests

[Paul Gevers]

Source: geary
Version: 3.36.1-1
Severity: serious
Control: close -1 3.36.2-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:geary in its
current version in unstable has been trying to migrate for 60 days [2].
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=geary




signature.asc
Description: OpenPGP digital signature

Bug#962074: blender: crash in an assertion and doubt about CMAKE_BUILD_TYPE

[Antonio Ospite]

On Tue, 30 Jun 2020 14:01:50 +0200
Fabian Greffrath  wrote:

> Hi there,
> 
> Am 2020-06-30 13:49, schrieb Matteo F. Vescovi:
> > I'm spending few days of [VAC] so I'm afk.
> > Feel free to provide me a patch to fix the issue and I'll more than
> > happy to apply it to the package once I'm back, as already done in the
> > past. ;-)
> 
> will adding the line
> 
> export DEB_CPPFLAGS_MAINT_APPEND = -DNDEBUG
> 
> to debian/rules already do the fix?
> 
>   - Fabian

Thanks Fabian, this is viable as a minimum fix indeed.

The intent of my original report was also to ask Matteo if he had an
opinion about building with CMAKE_BUILD_TYPE=Release instead, since I
may not be familiar with all the implications.

But yeah, let's play it safe and go with the -DNDEBUG fix.

There is another issue with 2.83.0+dfsg as apparently something
changed upstream about fonts installation, I think the following commits
break some assumptions in
debian/patches/0004-locales_directory_install.patch:
https://github.com/blender/blender/commit/68e341e9d59ae917eba992591f4f60660f6c58ff
https://github.com/blender/blender/commit/d7514914894e9c96c9eab21fb625a2021aaa71cb

I opened an MR which should fix both issues:
https://salsa.debian.org/multimedia-team/blender/-/merge_requests/2

Thanks,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#964267: src:rust-ppv-lite86: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: rust-ppv-lite86
Version: 0.2.5-2
Severity: serious
Control: close -1 0.2.6-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 961335

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-ppv-lite86 in its current version in unstable has been trying
to migrate for 61 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=rust-ppv-lite86




signature.asc
Description: OpenPGP digital signature

Bug#964266: ITP: golang-github-brentp-irelate: Streaming relation testing of sorted files of intervals

[Nilesh Patra]

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


* Package name: golang-github-brentp-irelate
  Version : 0.0~git20180801.1bf7c8f+ds-1
  Upstream Author : Brent Pedersen
* URL : https://github.com/brentp/irelate

* License : Expat
  Programming Lang: Golang
  Description : Streaming relation testing of sorted files of intervals

Description: Streaming relation testing of sorted files of intervals
 Helps to relate (e.g. intersect or by distance) sets of intervals.
 For example, if the nearest gene to a set of ChIP-Seq peaks needs
 to be reported, BEDTools does this extremely well, irelate is an
 attempt to provide an API so that users can write their own tools
 with little effort in go.
 .
 Performance irelate is quite fast, but use PIRelate for parallel
 intersection. It is less flexible than irelate, but skips parsing of
 database intervals for sparse regions in the query.  In addition, it
 has very good (automatic) parallelization.

I shall maintain this package.

Bug#761878: [Pkg-sysvinit-devel] Bug#761878: sysv-rc: policy-rc.d should live under /etc

[Michael Biebl]

On Tue, 16 Sep 2014 17:57:28 +0200 Ansgar Burchardt 
wrote:
> Henrique de Moraes Holschuh  writes:
> > On Tue, 16 Sep 2014, Ansgar Burchardt wrote:
> >> policy-rc.d is supposed to be configured (and thus edited) by the
> >> local admin. It should thus not live in /usr/sbin.
> >
> > It is supposed to be supplied under the Debian alternatives subsystem or
> > something equivalent, which will install a symlink there.  In fact, it will
> > install a symlink to /etc/alternatives/policy-rc.d, which will be another
> > symlink there to the active "alternative".
> 
> But nobody ever does that.
> 
> > The /usr/sbin/policy-rc.d symlink would be created and managed by the
> > packages providing policy-rc.d, through /usr/sbin/update-alternatives.  The
> > local admin can do the same if he wants.  Or he can just add a real file in
> > /usr/sbin/policy-rc.d, and update-alternatives should leave it alone.
> >
> > Nobody ever found a reason to package a general-use policy-rc.d, although
> > the feature is directly used by some tools that create private chroots, such
> > as pbuilder.
> 
> That's the most common use (also by d-i as far as I remember). And
> sometimes people write their own policy-rc.d.
> 
> In all cases, it's a configuration choice and not shipped by a package,
> and so belongs below /etc.
> 
> >> Please support using a policy-rc.d located under /etc (and leave
> >> /usr/sbin/policy-rc.d as a legacy location).
> >
> > AFAIK, there is no strong technical reason to change the policy-rc.d ABI at
> > this time, so I will downgrade this to wishlist and tag it wontfix.
> 
> Well, it doesn't break any old use. It's an ABI-compatible change ;)
> 

I think /etc/ is a weird place, /usr/local/sbin might be more appropriate.





signature.asc
Description: OpenPGP digital signature

Bug#769895: init-system-helpers: deb-systemd-helper should remove timestamps on timer unit purge

[Michael Biebl]

Hi Felipe

On Tue, 20 Dec 2016 09:46:38 -0300 Felipe Sateler 
wrote:
> Control: forwarded -1 https://github.com/systemd/systemd/issues/4930
> 
> On Mon, 17 Nov 2014 12:46:38 +0100 Alexandre Detiste
>  wrote:
> > Package: init-system-helpers
> > Version: 1.21
> > Severity: minor
> >
> > Dear Maintainer,
> >
> > When a timer unit with flag "Persistant=true" is purged,
> > a loose time stamp (0 byte file) is left loose
> > in /var/lib/systemd/timers/stamp-.timer
> >
> > This file could be safely removed by deb-systemd-helper during a purge.
> 
> I'd really rather not rely on implementation details. I have forwarded
> the bug to systemd upstream so they provide an interface to clear the
> stamp files. When that is done, we can add that invocation in
> deb-systemd-helper.

We now do have a "systemctl clean" interface.
Should we simply run that unconditionally on deb-systemd-helper purge?
For all unit types or only timers?

I also note, that this apparently doesn't work in chroots:
# systemctl clean apt-daily.timer
Running in chroot, ignoring request: clean

Not sure if this is something we should be concerned about.

Regards,
Michael





signature.asc
Description: OpenPGP digital signature

Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

[sven]

Package: wnpp
Severity: wishlist
Owner: Sven Hoexter 

* Package name: exfatprogs
  Version : 1.0.3
  Upstream Author : Namjae Jeon 
Hyunchul Lee 
* URL : https://github.com/exfatprogs/exfatprogs
* License : GPL-2
  Programming Lang: C
  Description : tools to create, check and label exFAT filesystems

 Tools to manage extended file allocation table filesystem.
 This package provides tools to create, check and label the
 filesystem. It contains
  - mkfs.exfat to create an exFAT filesystem
  - fsck.exfat to check and repair an exFAT filesystem
  - tune.exfat to print and edit the filesystem label
 The tools included in this package are the exfatprogs
 maintained by Samsung engineers, who provided Linux exFAT
 support. A similar but independent implementation of these
 tools, written by the author of the exfat-fuse implementation,
 are available in the exfat-utils package.


Since people started to ping me about getting this one introduced
I now give in and pick it up. I plan to continue for now the
maintenance of the fuse-exfat and exfat-utils packages.
While fuse-exfat can be coinstalled at any moment exfat-utils and
exfatprogs will for now conflict with each other.
Maybe I later on drop the mkfs.exfat and fsck.exfat links from
the exfat-utils package.

Bug#964264: VRF-aware dhclient-script

[Aaron Dewell]

Package: isc-dhcp-client
Version: 4.4.1-2.1+b2

The distributed dhclient-script will does not work correctly in a VRF 
environment, the default route will be added to the main routing table when the 
lease is obtained. This functionality should be extended, thus this is more of 
a feature request than a bug (though it does behave badly when presented with 
such an environment).
Example:
root@test:~# ip link add external type vrf table 1
root@test:~# ip rule add iif external table 1
root@test:~# ip rule add oif external table 1
root@test:~# ip link set ext master external
root@test:~# dhclient ext
root@test:~# ip route show table 1
broadcast 172.19.121.0 (172.19.226.0) dev ext proto kernel scope link src 
172.19.121.181
172.19.121.0/24 (172.19.226.0/24) dev ext proto kernel scope link src 
172.19.121.181
local 172.19.121.181 (172.19.226.181) dev ext proto kernel scope host src 
172.19.121.181 (172.19.226.181)
broadcast 172.19.121.255 (172.19.226.255) dev ext proto kernel scope link src 
172.19.121.181 (172.19.226.181)
root@test:~# ip route show
default via 172.19.121.1 (172.19.226.1) dev ext

Expected behavior: if the interface is in a VRF, the default route will be 
added to the VRF.
Here are the changes I made to the script (the detection method I used might 
break bridges though, however, I'd think bridge interfaces will never make it 
to that point anyway). My logic: detect whether this interface has a master or 
not, find it, find which table this route is meant to be a part of, and then 
set the string. If none of that happened, the string will be empty and things 
will work as they do now.
This could be improved (in many ways, but in particular) by doing a backcheck 
of ip link show vrf $vrf and observing that we do indeed see $interface within 
that output.
Tested in my environment and it properly gives two default routes, one in the 
VRF, one not.
--- /sbin/dhclient-script 2020-03-23 03:08:55.0 -0600
+++ dhclient-script 2020-07-04 10:34:11.197856308 -0600
@@ -264,15 +264,23 @@
if_metric=${if_metric:-1}
fi

+ # For VRFs.
+ vrf="`ip link show dev ${interface} | grep master | awk '{print $9}'`"
+ if [ ! -z $vrf ]; then
+ # find parent table
+ vrf_table="`ip vrf show | grep $vrf | awk '{print $2}'`"
+ vrf_string="table $vrf_table"
+ fi
+
for router in $new_routers; do
if [ "$new_subnet_mask" = "255.255.255.255" ]; then
# point-to-point connection => set explicit route
- ip -4 route add ${router} dev $interface >/dev/null 2>&1
+ ip -4 route add ${router} dev $interface $vrf_string >/dev/null 2>&1
fi

# set default route
ip -4 route add default via ${router} dev ${interface} \
- ${if_metric:+metric $if_metric} >/dev/null 2>&1
+ ${if_metric:+metric $if_metric} $vrf_string >/dev/null 2>&1

if [ -n "$if_metric" ]; then
if_metric=$((if_metric+1))

Bug#964159: /usr/bin/deb-systemd-helper: Makes packages using dh_installsystemduser(1) fail piuparts

[Michael Biebl]

On Fri, 3 Jul 2020 01:21:54 +0200 Guilhem Moulin  wrote:
> On Thu, 02 Jul 2020 at 21:05:26 +0200, guil...@debian.org wrote:
> > `postrm purge` removes these but not the parents directories, hence causes
> > `piuparts -d sid --no-upgrade-test` to fail with
> > 
> > ERROR: FAIL: Package purging left files on system:
> >  /etc/systemd/user/ not owned
> >  /var/lib/systemd/deb-systemd-user-helper-masked/   not owned
> 
> Prominent examples appear to be gpg-agent and dirmngr:
> 
> https://piuparts.debian.org/sid-strict/fail/gpg-agent_2.2.20-1.log
> https://piuparts.debian.org/sid-strict/fail/dirmngr_2.2.20-1.log
> 
> qa.d.o claims it turns blocks piuparts checks for their ~1k reverse
> dependencies.

Thanks for patch, Guilhem, LGTM.
I've committed it as a1ef8e9154a885e5a05d1297938d57d251f8415f

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#964025: berusky2: New upstream release

[Asher Gordon]

Hi Markus,

Markus Koschany  writes:

> Thank you. I have uploaded berusky2 a few minutes ago.

Cool, thanks!

> Tip for the future: You can just attach your compressed debian
> diretory to the bug report or open a merge request on salsa.debian.org
> and send a note to your bug report. If you create a patch for upstream
> and debian files I can't apply it as is because of the
> master/upstream/pristine-tar Git structure of our packages. There is
> also a tool called debdiff which eases the creation of Debian patches.

Thanks, good to know.

> Have a nice weekend

You too.

Asher

-- 
"It's my cookie file and if I come up with something that's lame and I like it,
it goes in."
-- karl (Karl Lehenbauer)
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#913128: uncompress

[Teus Benschop]

This how2do it.

If it's in debhelper, it must be the following override:

dh_compress --exclude=.ogg

https://manpages.debian.org/jessie/debhelper/dh_compress.1.en.html

Bug#964263: linux-image-5.7.0-1-amd64: Switching from a graphical VT to a non-graphical one freezes display

[Asher Gordon]

Package: src:linux
Version: 5.7.6-1
Severity: normal

Dear Maintainer,

When I switch from a VT running a graphical environment, specifically
EXWM, to a VT running a plain old console with getty, the display
freezes up. Switching from that VT to another one (graphical or console)
unfreezes the display. The VT still recognizes my keypresses, but it
still displays whatever was on the screen before I switched VTs. I use
Ctrl+Alt+F[1-6] to switch VTs.

Strangely enough, this doesn't happen all the time. Sometimes I can't
make it happen even once, but sometimes it happens most of the time. I
have observed the bug in both EXWM and i3, but I have yet to observe it
in GNOME.

I noticed this when I upgraded the kernel, and if I boot onto the old
one (linux-image-amd64 5.6.14-2, linux-image-5.6.0-1-amd64 5.6.7-1), I
am unable to cause the symptoms described.

Also, if the non-graphical VT that I am switching to is not running
getty, the symptoms do not appear. So if I run 'systemctl stop
getty@tty3.service' and then run a graphical shell (using startx) in
tty2, switching from tty2 to tty3 will not freeze the display. However,
if I then switch from tty3 back to tty2 and then back to tty3 again, it
will (maybe) freeze the display, since getty is now running in tty3.

Note that I only stopped getty, I didn't actually deallocate the VT
(using deallocvt). I suspect that stopping getty could have caused the
VT to automatically deallocate itself.

I have not observed this bug when switching from a graphical to
graphical VT, from a non-graphical to non-graphical VT, or from a
non-graphical to graphical VT. Only when switching from a graphical to
non-graphical VT does the bug appear.

Thanks,
Asher

-- Package-specific info:
** Version:
Linux version 5.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-14), GNU ld (GNU Binutils for Debian) 2.34) #1 SMP Debian 5.7.6-1 
(2020-06-24)

** Command line:
BOOT_IMAGE=/vmlinuz root=/dev/sda1 rw quiet splash

** Tainted: I (2048)
 * workaround for bug in platform firmware applied

** Kernel log:
[6.336783] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[6.338438] sd 0:0:0:0: Attached scsi generic sg0 type 0
[6.411428] systemd[1]: Created slice system-wacom\x2dinputattach.slice.
[6.411776] systemd[1]: Condition check resulted in Dispatch Password 
Requests to Console Directory Watch being skipped.
[6.411968] systemd[1]: Condition check resulted in FUSE Control File System 
being skipped.
[6.412078] systemd[1]: Condition check resulted in Kernel Configuration 
File System being skipped.
[6.412183] systemd[1]: Condition check resulted in Set Up Additional Binary 
Formats being skipped.
[6.412228] systemd[1]: Condition check resulted in Rebuild Hardware 
Database being skipped.
[6.412276] systemd[1]: Condition check resulted in Commit a transient 
machine-id on disk being skipped.
[6.412309] systemd[1]: Condition check resulted in Platform Persistent 
Storage Archival being skipped.
[6.428197] audit: type=1400 audit(1593880876.069:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=293 comm="apparmor_parser"
[6.462107] cfg80211: Loading compiled-in X.509 certificates for regulatory 
database
[6.462454] cfg80211: Loaded X.509 cert 'b...@debian.org: 
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[6.462816] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[6.463157] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[6.466353] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db
[6.466725] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db.p7s
[6.468314] snd_hda_codec_conexant hdaudioC0D0: CX20561 (Hermosa): BIOS 
auto-probing.
[6.469853] audit: type=1400 audit(1593880876.109:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=305 comm="apparmor_parser"
[6.485434] systemd[1]: Finished Load/Save Screen Backlight Brightness of 
backlight:intel_backlight.
[6.493410] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20561 
(Hermosa): line_outs=1 (0x1a/0x0/0x0/0x0/0x0) type:speaker
[6.493413] snd_hda_codec_conexant hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[6.493415] snd_hda_codec_conexant hdaudioC0D0:hp_outs=2 
(0x19/0x16/0x0/0x0/0x0)
[6.493416] snd_hda_codec_conexant hdaudioC0D0:mono: mono_out=0x0
[6.493418] snd_hda_codec_conexant hdaudioC0D0:dig-out=0x1c/0x0
[6.493419] snd_hda_codec_conexant hdaudioC0D0:inputs:
[6.493421] snd_hda_codec_conexant hdaudioC0D0:  Mic=0x18
[6.493423] snd_hda_codec_conexant hdaudioC0D0:  Internal Mic=0x1d
[6.493424] snd_hda_codec_conexant hdaudioC0D0:  Dock Mic=0x17
[6.530933] input: HDA Intel Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input8
[6.531005] input: HDA 

Bug#964188: chromium: crashes & system crashes after security update to v83

[pham...@bluewin.ch]

On Raspberry Pi 4 running with Raspbian 10 OS 64 bits (beta), the problem is 
the same, it is a developer version which was published and not a stable 
version.
Chrome is the official browser for Raspbian. It now takes 2 minutes 30 seconds 
to open the youtube.com page ;-( The only existing arm compatible alternative 
is Firefox.
Regards..

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Andrey Rahmatullin]

On Sat, Jul 04, 2020 at 06:06:05PM +0100, Joan Moreau wrote:
> Input file sare visibles on
> https://github.com/grosjo/tomboy-reborn/tree/master/packages
You are supposed to include thesoftware source in the package, not this.
So debian/ should be in the root of the repo.

> This is the exact ouptut I get (from debuild -d)
> 
> I: check_all_licenses completed for 32 files.
> I: bunch_all_licenses
> I: format_all_licenses
> I: make debian/* template files
> I: found "debian/changelog"
> I: debmake -x "0" ...
> I: skipping :: debian/control (file exists)
> I: creating => debian/copyright
> I: substituting => /usr/share/debmake/extra0/rules
> I: skipping :: debian/rules (file exists)
> I: substituting => /usr/share/debmake/extra0/changelog
> I: skipping :: debian/changelog (file exists)
You aren't supposed to run debmake with debian/ already existing.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#964248: base-installer: Pass "--extra-suites=unreleased" to debootstrap on ports arches

[Samuel Thibault]

Hello,

наб, le sam. 04 juil. 2020 13:32:35 +0200, a ecrit:
> I've posted these patches to debian-boot@ last month,
> but thought I'd try again.

Thanks for the ping. Since there was no concern raised in the meanwhile,
I have pushed the change to the gits.

Samuel

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Andrey Rahmatullin]

On Sat, Jul 04, 2020 at 05:57:51PM +0100, Joan Moreau wrote:
> Is there a web page stating the steps to go through, without all this
> complexity ?
> 
> similar to the Arch  :
> https://wiki.archlinux.org/index.php/AUR_submission_guidelines

https://mentors.debian.net/intro-maintainers is similar to that page.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#964252: Failure to build from source on buster

[Sebastian Ramacher]

Control: found -1 1:1.1.0-1
Control: notfound -1 1.1.0-1

On 2020-07-04 15:45:12 +0200, Nils König wrote:
> Source: libbluray
> Version: 1.1.0-1
> Severity: serious
> Tags: ftbfs
> 
> Hi,
> 
> Building from source fails on buster (amd64) while trying to create pdf docs.
> Relevant log excerpt at end of mail, full log available here:
>   https://oneric.de/public/libbluray-1.1.0-1_ftbfs.log
> It seems like that, while no tex files are produced, doxygen still tries to 
> build pdf docs.
> 
> I retrieved the source with
>   apt-get source libbluray/buster
> and tried building both with
>   apt-get source -b libbluray/buster
> and
>  debuild -us -uc -b
> Build dependencies were installed with mk-build-deps.
> 
> System: Debian Buster amd64
>  libc6   2.28-10
>  doxygen 1.8.13-10
>  texlive 2018.20190227-2
> 
> 
> Either dropping patch 0004-Disable-PDF-documentation or adding
> 
> confflags += --disable-doxygen-pdf
> confflags += --disable-doxygen-ps
> 
> to debian/rules resolved this for me.
> 
> Regards
> Nils König
> 
> 
> ---
> 
> […]
> Generating file index...
> Generating file member index...
> Generating example index...
> finalizing index lists...
> writing tag file...
> lookup cache used 359/65536 hits=1092 misses=366
> finished...
> cd doc/doxygen/latex; \
> rm -f *.aux *.toc *.idx *.ind *.ilg *.log *.out; \
> /usr/bin/latex refman.tex; \
>  refman.idx; \
> /usr/bin/latex refman.tex; \
> countdown=5; \
> while /usr/bin/egrep 'Rerun (LaTeX|to get cross-references right)' \
>   refman.log > /dev/null 2>&1 \
>   && test $countdown -gt 0; do \
>   /usr/bin/latex refman.tex; \
>   countdown=`expr $countdown - 1`; \
> done; \
> /usr/bin/dvips -o ../libbluray.ps refman.dvi
> /bin/bash: line 0: cd: doc/doxygen/latex: No such file or directory
> This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) 
> (preloaded format=latex)
>  restricted \write18 enabled.
> entering extended mode
> ! I can't find file `refman.tex'.
> <*> refman.tex
>   
> (Press Enter to retry, or Control-D to exit)
> Please type another input file name:

FWIW, this only happens in a non-clean build environment with texlive
installed.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#964262: FTBFS: needs updated build-depends; needs to build-depend on libreoffice-dev-gui

[Rene Engelhard]

Source: openclipart
Version: 1:0.18+dfsg-17
Severity: serious

Dear Maintainer,

Hi,

as discussed back then in

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

gengal was moved to libreoffice-dev-gui for the 7.x LO packages.

These got uploaded to sid now [1].

Please build-depend on (the hopefully soon available)
libreoffice-dev-gui.

Regards,

Rene

[1] unfortunately thay are BD-Uninstallable anywhere due to the
bsdmainutils mess (#)964242 but.:

libreoffice build-depends on:
- javahelper:amd64 (>= 0.37~)
javahelper depends on:
- bsdmainutils:amd64
bsdmainutils depends on missing:
- bsdextrautils:amd64 (>= 2.35.2-7)

Bug#964251: libreoffice-common: needs Breaks+Replaces against openclipart-libreoffice

[Rene Engelhard]

clone 964251 -1

reassign -1 openclipart-libreoffice

retitle -1 contains /usr/lib/libreoffice/share/gallery/shapes.* also in
libreoffice-common from LO 7.0.x onwards

thanks

Hi,

Am 04.07.20 um 15:51 schrieb Andreas Beckmann:
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> [...]
[...]
> These three files are conflicting:
>
>   usr/lib/libreoffice/share/gallery/shapes.sdg
>   usr/lib/libreoffice/share/gallery/shapes.sdv
>   usr/lib/libreoffice/share/gallery/shapes.thm

I am not sure whether Replaces: is correct here. I mean besides that
both are names shapes.* and contain Shapes they don't have the same
stuff and thus aren't "replaced".

But probably there isn't a better field...

> openclipart-libreoffice will probably need updates as well to no longer
> ship these files (or rename them), it's probably easiest if you fix and
> upload that QA maintained package, too.

No. I don't care, actually :-) That's why it is QA maintained.


Yoju did the last QA uploads, you can do that too. (Actually it needs an
update for the new

libreoffice-dev-gui anyways.)


Regards,


Rene

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Andrey Rahmatullin]

On Sat, Jul 04, 2020 at 05:38:05PM +0100, Joan Moreau wrote:
> Let's imagine I found it (using lazbuild most probably), then where
> should I put that command ?
override_dh_auto_build, assuming you use dh(1)

> How to specifiy the options needed ? 
As usual in the command arguments.

> where to put lazarus is required ?

Build-Depends.

> Following
> https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html#step-upstream,
> I am getting the error "Please specify the compatibilitle level in
> debian/compat' (meaning what should I write where ?)
debmake would create that file for you, so I'm not sure what exactly did
you do.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#964025: berusky2: New upstream release

[Markus Koschany]

Hi Asher,

Am 04.07.20 um 02:43 schrieb Asher Gordon:
> Hi Markus,
> 
> Markus Koschany  writes:
> 
>> Thank you very much for all your work on berusky2! I take a look at the
>> new version as soon as possible and intend to make a new Debian release
>> soon.
> 
> Great, thanks! But actually, I think I managed it myself. I was able to
> build and install the packages with my changes. Here is the patch for
> the data:

[...]

Thank you. I have uploaded berusky2 a few minutes ago. Tip for the
future: You can just attach your compressed debian diretory to the bug
report or open a merge request on salsa.debian.org and send a note to
your bug report. If you create a patch for upstream and debian files I
can't apply it as is because of the master/upstream/pristine-tar Git
structure of our packages. There is also a tool called debdiff which
eases the creation of Debian patches.

Have a nice weekend

Markus



signature.asc
Description: OpenPGP digital signature

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

Hi Evangelos 


Found also this page
https://coderwall.com/p/urkybq/how-to-create-debian-package-from-source 


But I am not getting anywhere.

My tentative package is however extremely simple 

It contains 3 files 

- the binary (to go into /usr/bin) 

- the icon 

- the .desktop file 

The sources are here : https://github.com/grosjo/tomboy-reborn 


How to know the files needed, and is there "tar" or similar software to
create the ".deb" file form a files tree ? 

Thank you so much 

JM 


On 2020-07-01 22:31, Evangelos Ribeiro Tzaras wrote:


Hi,

I originally got started with [1 [1]], however you should probably consult the 
new
version [2 [2]]. This should hopefully help you figure things out.

[1] https://www.debian.org/doc/manuals/maint-guide/index.html
[2] https://www.debian.org/doc/devel-manuals#debmake-doc

On 7/1/20 9:20 PM, Joan Moreau wrote: Hi

I am really sorry to bother you, but I am a bit lost.

I created a .deb file (see
https://github.com/grosjo/tomboy-reborn/tree/master/packages ) so I should now
create a deb-src package, right ?

The wiki page you mentioned does not really explain how to do so. Is there a
simple, step-by-step, process described somewhere ?

THank you so much

On 2020-07-01 18:46, Andrey Rahmatullin wrote:

On Wed, Jul 01, 2020 at 05:35:21PM +0100, Joan Moreau wrote: This is not a "source 
package" as the source is in Pascal (using Lazarus
compiler package). Should I include the Pascal source also ? You need to create 
a Debian source package that can be built to produce a
Debian binary package.
It doesn't really matter what language is used or what should be contained
in the binary package. The workflow is the same.
https://wiki.debian.org/Packaging/SourcePackage


---

Evangelos Ribeiro Tzaras



Links:
--
[1] https://www.debian.org/doc/manuals/maint-guide/index.html
[2] https://www.debian.org/doc/devel-manuals#debmake-doc

Bug#959075: Still not working on Debian testing

[richard lucassen]

On Sat, 04 Jul 2020 13:41:33 +0800
Paul Wise  wrote:

> Is this a regression from 2.9 or just an old bug still present?

Rereading it, I don't know if this issue was present in 2.9 or earlier.
I just noticed it while testing the new version.

-- 
richard lucassen
https://contact.xaq.nl/

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Andrey Rahmatullin]

On Sat, Jul 04, 2020 at 04:57:37PM +0100, Joan Moreau wrote:
> Hi Boyuan,
> 
> Thank you so much for your feedback.
> 
> The program is to be compiled with Lazarus
> (https://packages.debian.org/buster/lazarus-ide ), this is pretty
> straighforward for anyone willing to compile from source.
> 
> SHould I put "lazarus" somewhere ? where ?
You need to find out how to build the project without launching the IDE.
There are suggestions regarding that in another email.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#964230: debhelper: dh_missing conflicts with global --sourcedir option

[Thorsten Glaser]

Niels Thykier dixit:

>Historical artefact caused by debhelper accepting abbreviations of the

Interesting, but I looked at debhelper(7):

   -Ddirectory, --sourcedir=directory, --sourcedirectory=directory
   Assume that the original package source tree is at the specified
   directory rather than the top level directory of the Debian source
   package tree.

The documentor probably wasn’t aware of the clash.

>Anyhow, based on your report, you can probably resolve this by using
>--sourcedirectory=thatsubdir.  The longer form is *only* accepted by the
>dh_auto_* tools (making dh_install/dh_missing ignore it).

Ah okay. I’ve used -D for now (managed to get it packaged yesterday),
does _that_ clash anywhere? ;-)

>Sadly, --destdir is also taken... by dh_builddir. >.>

Ah okay.

>Indeed, it might be overdue to clean up this ancient clashes.

Probably for the best.

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#959579: adapta-gtk-theme: diff for NMU version 3.95.0.11-1.1

[Sudip Mukherjee]

Control: tags 959579 + patch
Control: tags 959579 + pending


Dear maintainer,

I've prepared an NMU for adapta-gtk-theme (versioned as 3.95.0.11-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

--
Regards
Sudip

diff -Nru adapta-gtk-theme-3.95.0.11/debian/changelog 
adapta-gtk-theme-3.95.0.11/debian/changelog
--- adapta-gtk-theme-3.95.0.11/debian/changelog 2018-10-02 20:21:00.0 
+0100
+++ adapta-gtk-theme-3.95.0.11/debian/changelog 2020-07-04 16:41:37.0 
+0100
@@ -1,3 +1,10 @@
+adapta-gtk-theme (3.95.0.11-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS. (Closes: #959579)
+
+ -- Sudip Mukherjee   Sat, 04 Jul 2020 16:41:37 
+0100
+
 adapta-gtk-theme (3.95.0.11-1) unstable; urgency=medium
 
   * Initial release (Closes: #894026).
diff -Nru adapta-gtk-theme-3.95.0.11/debian/patches/fix_render.patch 
adapta-gtk-theme-3.95.0.11/debian/patches/fix_render.patch
--- adapta-gtk-theme-3.95.0.11/debian/patches/fix_render.patch  1970-01-01 
01:00:00.0 +0100
+++ adapta-gtk-theme-3.95.0.11/debian/patches/fix_render.patch  2020-07-04 
16:29:09.0 +0100
@@ -0,0 +1,87 @@
+Description: Fix rendering with inkscape
+ The arguments have changed with the new version of inkscape, update them.
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/959579
+Forwarded: no
+
+---
+
+--- 
adapta-gtk-theme-3.95.0.11.orig/gtk/asset/assets-gtk2-scripts/render-assets-gtk2.sh
 
adapta-gtk-theme-3.95.0.11/gtk/asset/assets-gtk2-scripts/render-assets-gtk2.sh
+@@ -30,7 +30,8 @@ render-non-scale() {
+ $INKSCAPE --export-id=$ID \
+   --export-dpi="$non_scale_dpi" \
+   --export-id-only \
+-  --export-png=$ASSETS_DIR/$i.png $SRC_FILE >/dev/null \
++  --export-type=png \
++  --export-filename=$ASSETS_DIR/$i.png $SRC_FILE >/dev/null \
+ 2>>../inkscape.log
+ }
+ 
+--- 
adapta-gtk-theme-3.95.0.11.orig/gtk/asset/assets-gtk3-scripts/render-assets-gtk3.sh
 
adapta-gtk-theme-3.95.0.11/gtk/asset/assets-gtk3-scripts/render-assets-gtk3.sh
+@@ -32,7 +32,8 @@ render-non-scale() {
+ $INKSCAPE --export-id=$i \
+   --export-dpi="$non_scale_dpi" \
+   --export-id-only \
+-  --export-png=$ASSETS_DIR/$i.png $SRC_FILE >/dev/null \
++  --export-type=png \
++  --export-filename=$ASSETS_DIR/$i.png $SRC_FILE >/dev/null \
+ 2>>../inkscape.log
+ }
+ 
+@@ -40,7 +41,8 @@ render-scale() {
+ $INKSCAPE --export-id=$i \
+   --export-dpi="$scale_dpi" \
+   --export-id-only \
+-  --export-png=$ASSETS_DIR/$i...@2.png $SRC_FILE >/dev/null \
++  --export-type=png \
++  --export-filename=$ASSETS_DIR/$i...@2.png $SRC_FILE >/dev/null \
+   2>>../inkscape.log
+ }
+ 
+--- adapta-gtk-theme-3.95.0.11.orig/shell/asset/render-assets-cinnamon-thumb.sh
 adapta-gtk-theme-3.95.0.11/shell/asset/render-assets-cinnamon-thumb.sh
+@@ -48,11 +48,11 @@ fi
+ 
+ # Renderer
+ render-non-scale() {
+-$INKSCAPE --export-dpi="$non_scale_dpi" \
+-  --export-png=$ASSETS_DIR/$THUMB.png $SRC_DIR/$THUMB.svg 
>/dev/null \
++$INKSCAPE --export-dpi="$non_scale_dpi" --export-type=png \
++  --export-filename=$ASSETS_DIR/$THUMB.png $SRC_DIR/$THUMB.svg 
>/dev/null \
+   
2>>inkscape.log
+-$INKSCAPE --export-dpi="$non_scale_dpi" \
+-  --export-png=$ASSETS_DARK_DIR/$THUMB.png 
$SRC_DARK_DIR/$THUMB.svg >/dev/null \
++$INKSCAPE --export-dpi="$non_scale_dpi" --export-type=png \
++  --export-filename=$ASSETS_DARK_DIR/$THUMB.png 
$SRC_DARK_DIR/$THUMB.svg >/dev/null \
+   
  2>>inkscape.log
+ }
+ 
+--- 
adapta-gtk-theme-3.95.0.11.orig/wm/asset/assets-metacity-scripts/render-assets-metacity.sh
 
adapta-gtk-theme-3.95.0.11/wm/asset/assets-metacity-scripts/render-assets-metacity.sh
+@@ -26,8 +26,8 @@ fi
+ 
+ # Renderer
+ render-non-scale() {
+-$INKSCAPE --export-dpi="$non_scale_dpi" \
+-  --export-png=$ASSETS_DIR/$i.png $SRC_DIR/$i.svg >/dev/null \
++$INKSCAPE --export-dpi="$non_scale_dpi" --export-type=png \
++  --export-filename=$ASSETS_DIR/$i.png $SRC_DIR/$i.svg >/dev/null 
\
+   
2>>../inkscape.log
+ }
+ 
+--- 
adapta-gtk-theme-3.95.0.11.orig/wm/asset/assets-xfwm-scripts/render-assets-xfwm.sh
 
adapta-gtk-theme-3.95.0.11/wm/asset/assets-xfwm-scripts/render-assets-xfwm.sh
+@@ -26,8 +26,8 @@ fi
+ 
+ # Renderer
+ render-non-scale() {
+-$INKSCAPE --export-dpi="$non_scale_dpi" \
+-  --export-png=$ASSETS_DIR/$i.png $SRC_DIR/$i.svg 

Bug#963975: blender: Blender crashes on launch (failed assert)

[Antonio Ospite]

On Mon, 29 Jun 2020 15:34:36 +0100
Ben Morris  wrote:

> Package: blender
> Version: 2.83.1+dfsg-1
> Severity: grave
> Justification: renders package unusable
> 
> Blender 2.83.1+dfsg-1 is crashing on launch with the output shown below. I 
> have
> tested this with and without an existing ~/.config/blender/ directory.
> 
> $ blender
> blf_load_font_default: 'fonts' data path not found for 'droidsans.ttf', will
> not be able to display text
> blf_load_font_default: 'fonts' data path not found for 'bmonofont-i18n.ttf',
> will not be able to display text
> blf_load_font_default: 'fonts' data path not found for 'bmonofont-i18n.ttf',
> will not be able to display text

This is one bug, probably due to some changes in where blender expects
the default fonts, which breaks assumptions in a debian-specific patch,
see:
https://github.com/blender/blender/commit/68e341e9d59ae917eba992591f4f60660f6c58ff
https://github.com/blender/blender/commit/d7514914894e9c96c9eab21fb625a2021aaa71cb

> blender(BLI_system_backtrace+0x33) [0x55751863b4b3]
> blender(BLF_default+0x1c) [0x55751851eddc]
> blender(+0x18262bb) [0x5575168382bb]
> blender(ED_time_scrub_draw+0x1af) [0x5575165eab8f]
> blender(+0x184943d) [0x55751685b43d]
> blender(ED_region_do_draw+0x841) [0x55751656e911]
> blender(wm_draw_update+0x4ba) [0x55751620f4ba]
> blender(WM_main+0x30) [0x55751620d3c0]
> blender(main+0x2b8) [0x557515ee36c8]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f0c01ea0e0b]
> blender(_start+0x2a) [0x557515f303ba]
> BLI_assert failed:
> /build/blender-l5zyJy/blender-2.83.1+dfsg/source/blender/blenfont/intern/blf.c:185,
> BLF_default(), at 'global_font_default != -1'
> Aborted
> 

The crash by itself is another issue with asserts, probably similar to
what reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962074

I will hopefully have a fix for both soon.

Ciao,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#963993: dolphin crashes with segfault

[Hans-J. Ullrich]

Package: dolphin
Followup-For: Bug #963993

Dear Maintainer,

in the meantime I could solve this problem for me. The cause of the crash was 
found in the file ~.local/share/kxmlgui5/dolphin/dolphinui.rc.

When I deleted this file, I could start dolphin again. However, I do not 
understand, what happened, as I never edited this file.

I kept the defective file as a backup, so if one is interested to compare the 
correct one and the defective, please drop me a line. I will be happy to send 
them to him/her.

Thank you very much for all the work.

This bugreport can be safely closed!


Best regards and stay safe.

Hans


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

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

Versions of packages dolphin depends on:
ii  baloo-kf5  5.70.0-2
ii  kinit  5.70.0-1
ii  kio5.70.1-1
ii  libc6  2.30-8
ii  libdolphinvcs5 4:20.04.2-1
ii  libkf5activities5  5.70.0-1
ii  libkf5baloo5   5.70.0-2
ii  libkf5baloowidgets54:20.04.2-1
ii  libkf5bookmarks5   5.70.0-1
ii  libkf5codecs5  5.70.0-1
ii  libkf5completion5  5.70.0-1
ii  libkf5configcore5  5.70.0-1
ii  libkf5configgui5   5.70.0-1
ii  libkf5configwidgets5   5.70.0-1
ii  libkf5coreaddons5  5.70.0-1
ii  libkf5crash5   5.70.0-1
ii  libkf5dbusaddons5  5.70.0-1
ii  libkf5filemetadata35.70.0-1
ii  libkf5i18n55.70.0-1
ii  libkf5iconthemes5  5.70.0-1
ii  libkf5itemviews5   5.70.0-1
ii  libkf5jobwidgets5  5.70.0-1
ii  libkf5kcmutils55.70.0-1
ii  libkf5kiocore5 5.70.1-1
ii  libkf5kiofilewidgets5  5.70.1-1
ii  libkf5kiowidgets5  5.70.1-1
ii  libkf5newstuff55.70.0-1
ii  libkf5notifications5   5.70.0-1
ii  libkf5parts5   5.70.0-1
ii  libkf5service-bin  5.70.0-1
ii  libkf5service5 5.70.0-1
ii  libkf5solid5   5.70.0-1
ii  libkf5textwidgets5 5.70.0-1
ii  libkf5widgetsaddons5   5.70.0-1
ii  libkf5windowsystem55.70.0-1
ii  libkf5xmlgui5  5.70.0-1+b1
ii  libphonon4qt5-44:4.11.1-3
ii  libqt5core5a   5.14.2+dfsg-4
ii  libqt5dbus55.14.2+dfsg-4
ii  libqt5gui5 5.14.2+dfsg-4
ii  libqt5widgets5 5.14.2+dfsg-4
ii  libqt5xml5 5.14.2+dfsg-4
ii  libstdc++6 10.1.0-4
ii  phonon4qt5 4:4.11.1-3

Versions of packages dolphin recommends:
ii  kimageformat-plugins  5.70.0-1
ii  kio-extras4:19.12.3-1

Versions of packages dolphin suggests:
ii  dolphin-plugins  4:20.04.2-1

-- debconf-show failed

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[The Wanderer]

On 2020-07-04 at 11:28, Boyuan Yang wrote:

> In your case, I do not see any build system in your source code 
> repository. There is a built binary file but there's no script or 
> instructions describing how the built binary was generated. I have 
> absolutely no idea how you were building the Pascal source code into 
> binaries. My best guess is that you are using the building function 
> embedded in Lazarus IDE -- which is completely unacceptable since a 
> working build system should be fully automated and require no
> graphical IDE tool to function well.

For what it's worth, there appears to exist a tool called 'lazbuild',
which is apparently supposed to be able to compile a program from the
command line if passed the appropriate Lazarus project file. I find two
different versions of it in Debian, both in the lcl-utils-2.0 package.

Also, https://forum.lazarus.freepascal.org/index.php?topic=37272.0
involves people talking about how to build a Lazarus project from the
command line; they appear to have gotten it working without the use of
lazbuild in at least one case, but whether that's worth the effort I
don't know.

If that's viable, there may not be any need to add a separate build
system, although there would still be a need to add appropriate
how-to-build documentation and (of course) the necessary debian/rules
glue to get it to be run at package-build time.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Boyuan Yang]

Hi Joan,

在 2020-07-04星期六的 13:23 +0100，Joan Moreau写道：
> Hi Evangelos
> 
> Found also this page 
> https://coderwall.com/p/urkybq/how-to-create-debian-package-from-source
> 
> It contains 3 files
> - the binary (to go into /usr/bin)
> - the icon
> - the .desktop file
> 
> 
> The sources are here : https://github.com/grosjo/tomboy-reborn
> 
> How to know the files needed, and is there "tar" or similar software
> to create the ".deb" file form a files tree ?

Disclaimer -- I'm providing you with some information that you might be
missing instead of trying to push this packaging process forward.

It looks like you are in lack of 2 large pieces of knowledge that is
critical to do a proper packaging:

(1) How to act properly as a software upstream, by providing a
functioning build system that can automatically convert source code
into binaries as well as providing handy instructions to install built
binaries into the system. This kind of buildsystem is often achieved
through a build automation software and you may find a list at 
https://en.wikipedia.org/wiki/List_of_build_automation_software .

(2) How to act properly as a downstream (Debian) packager on top of
upstream build system.

These 2 parts are separated but both essential when trying to create a
good software package. The fact that you are using a non-mainstream
programming language (Pascal) further complicates the situation.

From the very beginning (part (1)), you need a proper building system
in your upstream project, https://github.com/grosjo/tomboy-reborn .
Works in part (1) has nothing to do with Debian or any specific Linux
distributions.

In your case, I do not see any build system in your source code
repository. There is a built binary file but there's no script or
instructions describing how the built binary was generated. I have
absolutely no idea how you were building the Pascal source code into
binaries. My best guess is that you are using the building function
embedded in Lazarus IDE -- which is completely unacceptable since a
working build system should be fully automated and require no graphical
IDE tool to function well. It could be a handwritten Makefile, CMake-
based solutions, Meson-based solutions or something else. Since you are
using Pascal, I do not know what proper buildsystem should I recommend.
(If you are using a mainstream programming language like C, C++, C# or
even Python or Java, the buildsystem solution is largely known:
Makefile, CMake, Meson, python-setuptools, Maven, Gradle, etc.)
However, there are several existing Pascal-written software in Debian
and other Linux distributions. It might be easier for you to see what
other Pascal projects are using and do in a similar way. There is also
a Debian Pascal Team [1] and you may get some help from team members.
Remember that in part (1) you are acting as an upstream software
developer; if necessary, you may refer to Debian's guide to upstream
software developers at [2].

[1] 
https://qa.debian.org/developer.php?email=pkg-pascal-devel%40lists.alioth.debian.org
[2] https://wiki.debian.org/UpstreamGuide

For the latter part (part (2)), you will finally act as a downstream
software packager. we can discuss it later after you have a functioning
buildsystem. It won't be difficult as long as your build system is
sane. In any case, using prebuilt binaries from upstream is
unacceptable: Debian dislikes this and holds a view that any binaries should be 
generated (automatically) from source code at _build_ time.

I hope those information could be useful to you.

-- 
Thanks,
Boyuan Yang


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

Bug#964258: ITP: mistletoe -- fast, extensible Markdown parser in pure Python

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : python-mistletoe
  Version  : 0.7.2
  Upstream Author  : Mi Yu 
* Url  : https://github.com/miyuchina/mistletoe
* Licenses : Expat
  Programming Lang : Python

 mistletoe is a Markdown parser in pure Python,
 designed to be fast, spec-compliant and fully customizable.
 .
 Apart from being the fastest
 CommonMark-compliant Markdown parser implementation in pure Python,
 mistletoe also supports easy definitions of custom tokens.
 Parsing Markdown into an abstract syntax tree
 also allows us to swap out renderers for different output formats,
 without touching any of the core components.
 .
 CommonMark is a dialect of Markdown with a strict specification.
 .
 Markdown is a lightweight markup language
 with plain-text-formatting syntax.

I plan to maintain this package myself, keeping debianization in following
Git repository:

 https://salsa.debian.org/debian/python-mistletoe.git

 - 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#867187: update chroot script to mount bind systemd notify socket

[Simon Deziel]

Hello,

An ubuntu user also ran into this problem [1] as well so I revisited the
patch and turned it into a merge request [2]. I tested the code with
Unbound 1.10.1-1 and chroot set to /var/lib/unbound.

Regards,
Simon

1: https://bugs.launchpad.net/bugs/1885907
2: https://salsa.debian.org/dns-team/unbound/-/merge_requests/10

Bug#956033: RFS: idseq-bench [ITP]

[Andreas Tille]

Hi Sao,

On Sat, Jul 04, 2020 at 04:26:36PM +0900, Sao I Kuan wrote:
> Hi,
> 
> I'm looking for a sponsor for the package:
>   * idseq-bench (#956033)
> 
> The package is on:
> https://salsa.debian.org/med-team/idseq-bench
> ...
> Please consider to review and sponsor this. Any kind of suggestions
> are appreciated.

I've build the package and started the executables in /usr/bin with
--help option.  These issue a warning:

unable to import 'smart_open.gcs', disabling that module

Do you know what this means?

Kind regards

  Andreas

-- 
http://fam-tille.de

Bug#861182: RFS ete

[Andreas Tille]

Hi,

On Sat, Jul 04, 2020 at 10:48:13PM +0800, zhao feng wrote:
> > The package at
> >
> >  https://salsa.debian.org/med-team/python-ete3
> >
> > builds but is also not finished yet.  I do not remember what had stopped
> > me from finalising and uploading.  Please checkout and moreover if you
> > talk next time about "ete packaging repositor" provide a link. :-)
> 
> Thanks for your information. I have not noticed the existing RFP and
> have issued an ITP
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963732.
> Should I close the ITP I issued ? I wonder how to turn the RFP into ITP.

I do not really mind.  May be merging both bugs is the technical correct
way to go.

> I have created a personal repository at
> https://salsa.debian.org/zhaofeng-shu33-guest/ete/ and the ci passes
> https://salsa.debian.org/zhaofeng-shu33-guest/ete/-/pipelines/152628.
> The package has been uploaded to https://mentors.debian.net/package/ete.

As I said I do not require sponsees to upload to mentors.  The rationale
is that I sometimes want to change things quickly and directly - thus I
always sponsor from salsa repository.

> I am intending to merge these works into
> https://salsa.debian.org/med-team/python-ete3.

Yes, please do so.
 
> Some technical aspect of merging these two repos:
> I have found that med-team/python-ete3 repo uses some patches to deal
> with the offline testing problems. I think there is a more elegant way
> to handle this obstacle.

As I tried to express: Feel free to take over your solution.  There is
no point in sticking to not so good solutions just because they were
invented once.

> To summarize the way: using pytest instead of unittest.
> For more detail, see
> https://lists.debian.org/debian-python/2020/06/msg00035.html.
> So I am planning to override med-team/python-ete3 testing rule by
> using the one of zhaofeng-shu33-guest/ete/.

Yep.  Please go for it! :-)

> For other parts, I think it is not difficult to merge.

Sounds good.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#964257: Correctly handle apostophes in English dictionaries

[Yuri D'Elia]

Package: hunspell-en-us
Version: 1:2019.10.06-1
Severity: minor

For an embarassingly long time I was wondering why
aspell/ispell/hunspell wouldn't handle correctly anything basic with
apostrophes, such as "isn't".

Turns out I read the explaination, by random chance, here:

https://www.emacswiki.org/emacs/InteractiveSpell#toc16

It seems that /usr/share/hunspell/en_US.aff already has the ICONV rules,
but doesn't include "'’" in WORDCHARS.

I can confirm that those to WORDCHARS makes hunspell actually behave as
intended. Shouldn't this be the default for all english dictionaries?

(note that while the URL mentions emacs, this does affect the basic
hunspell cli as well)

Bug#964256: libbrotli-dev not multiarch installable

[Christian Klein]

Package: libbrotli-dev
Version: 1.0.7-6.1
Severity: important

libbrotli-dev is not multiarch-installable. Since libfreetype-dev now depends
on libbrotli-dev, this breaks libfreetype-dev multiarch support, too.

The fix is trivial, the control file is just missing "Multi-Arch: same". I'll
create a PR on salsa.debian.org to fix this issue.



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (999, 'unstable'), (998, 'testing'), (350, 'experimental')
Architecture: i386 (x86_64)

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

Versions of packages libbrotli-dev depends on:
ii  libbrotli1  1.0.7-6.1

libbrotli-dev recommends no packages.

libbrotli-dev suggests no packages.

-- no debconf information

Bug#962102: ltunify, something to review

[Geert Stappers]

Hello Anthony,

On Wed, 3 Jun 2020 17:15:45 +0200 Geert Stappers  wrote:
> On Wed, Jun 03, 2020 at 12:40:08PM +0100, Anthony Perkins wrote:
  ...
> > 
> > I believe this might be a good argument for including both. I have done
> > the packaging work already in my personal Gitea repo. I can push this to
> > Salsa for review if that would be useful.
> 
> Yes, make review possible.
> 

Could it be that you are waiting on me?  That I should create a git
repository at Salsa? (I did offer that and the offer still stands)

Anyway: What packaging work can be reviewed?

Goal: ltunify in Debian.


Regards
Geert Stappers
Wannabe uploading sponsor of ltunify

Bug#861182: RFS ete

[zhao feng]

> The package at
>
>  https://salsa.debian.org/med-team/python-ete3
>
> builds but is also not finished yet.  I do not remember what had stopped
> me from finalising and uploading.  Please checkout and moreover if you
> talk next time about "ete packaging repositor" provide a link. :-)

Thanks for your information. I have not noticed the existing RFP and
have issued an ITP
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963732.
Should I close the ITP I issued ? I wonder how to turn the RFP into ITP.

I have created a personal repository at
https://salsa.debian.org/zhaofeng-shu33-guest/ete/ and the ci passes
https://salsa.debian.org/zhaofeng-shu33-guest/ete/-/pipelines/152628.
The package has been uploaded to https://mentors.debian.net/package/ete.
I am intending to merge these works into
https://salsa.debian.org/med-team/python-ete3.

Some technical aspect of merging these two repos:
I have found that med-team/python-ete3 repo uses some patches to deal
with the offline testing problems. I think there is a more elegant way
to handle this obstacle.
To summarize the way: using pytest instead of unittest.
For more detail, see
https://lists.debian.org/debian-python/2020/06/msg00035.html.
So I am planning to override med-team/python-ete3 testing rule by
using the one of zhaofeng-shu33-guest/ete/.
For other parts, I think it is not difficult to merge.

Yours
zhaofeng-shu33


On Sat, Jul 4, 2020 at 1:17 AM Andreas Tille  wrote:
>
> On Fri, Jul 03, 2020 at 05:10:32PM +0300, mer...@debian.org wrote:
> > On 2020-07-03 13:50, zhao feng wrote:
> > > Thanks for your help. I can build the package on buster and bullyseye.
> > > Which distribution do you use? I find the version of softwares like
> > > python is quite new.
> >
> > The package fails to build on clean sid chroot. Most likely some Python
> > dependencies are missing from debian/control.
>
> The package at
>
>https://salsa.debian.org/med-team/python-ete3
>
> builds but is also not finished yet.  I do not remember what had stopped
> me from finalising and uploading.  Please checkout and moreover if you
> talk next time about "ete packaging repositor" provide a link. :-)
>
> > By the way, packaging of 'ete3' seems to be ongoing in Debian Med team
> > as well (adding Andreas in CC):
> > https://salsa.debian.org/med-team/python-ete3. I suggest getting in
> > touch with them to keep duplicate efforts minimal.
>
> Definitely.  Thanks for spotting.
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de

Bug#937519: RM pyrex?

[Scott Talbert]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: pyrex -- RoQA; dead upstream; no rdeps; blocking py2 
removal

Bug#964254: sympy: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Package: sympy
Version: 1.6-3
Severity: wishlist
Tags: patch l10n

Please find the initial German debconf translation for sympy
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of sympy debconf templates to German
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the sympy package.
# Helge Kreutzmann , 2020.
#
msgid ""
msgstr ""
"Project-Id-Version: sympy 1.6-3\n"
"Report-Msgid-Bugs-To: sy...@packages.debian.org\n"
"POT-Creation-Date: 2020-06-15 10:11+0200\n"
"PO-Revision-Date: 2020-07-04 16:24+0200\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../python-sympy-doc.templates:1001
msgid "Activate live.sympy.org service"
msgstr "Aktivierung des Dienstes »live.sympy.org«"

#. Type: boolean
#. Description
#: ../python-sympy-doc.templates:1001
msgid ""
"One can activate the service provided by https://live.sympy.org, which can "
"improve one's experience by providing the \"Sympy Live Shell\" inside "
"documentation pages."
msgstr ""
"Sie können den durch »https://live.sympy.org« bereitgestellten Dienst "
"aktivieren, der den Benutzungskomfort verbessert, indem es die »Sympy Live "
"Shell« innerhalb der Dokumentationsseiten bereitstellt."

#. Type: boolean
#. Description
#: ../python-sympy-doc.templates:1001
msgid ""
"However one must know that even if the button \"Sympy Live Shell\" is not "
"triggered, when one is browsing enabled documentation pages, HTTP requests "
"are sent to the website https://live.sympy.org, so there is a privacy breach."
msgstr ""
"Sie müssen allerdings wissen, dass HTTP-Anfragen an die Webseite »https://;
"live.sympy.org« gesandt werden, falls Sie die aktivierten "
"Dokumentationsseiten lesen, selbst wenn Sie den Knopf »Sympy Live Shell« "
"nicht auslösen. Dies stellt eine Verletzung der Privatsphäre dar."

#. Type: boolean
#. Description
#: ../python-sympy-doc.templates:1001
msgid ""
"When the parameter python-sympy-doc/live-sympy is true, links to https://;
"live.sympy.org are active. When this parameter is false, those links are "
"replaced by links to http://localhost, so there is no privacy breach."
msgstr ""
"Wenn der Parameter »python-sympy-doc/live-sympy« auf »true« gesetzt ist, "
"dann sind Links auf https://live.sympy.org aktiv. Ist dieser Parameter "
"»false«, dann werden solche Links durch Links auf »http://localhost« "
"ersetzt, so dass es keine Verletzung der Privatsphäre gibt."

#. Type: boolean
#. Description
#: ../python-sympy-doc.templates:1001
msgid "You can safely keep the default 'false' value for this parameter."
msgstr ""
"Sie können problemlos die Vorgabe »false« für diesen Parameter beibehalten."

Bug#964255: python-certbot: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Package: python-certbot
Severity: wishlist
Tags: patch l10n

Please find the initial German debconf translation for python-certbot
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of python-certbot debconf templates to German
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the python-certbot package.
# Helge Kreutzmann , 2020.
#
msgid ""
msgstr ""
"Project-Id-Version: python-certbot\n"
"Report-Msgid-Bugs-To: python-cert...@packages.debian.org\n"
"POT-Creation-Date: 2020-06-21 21:24-0400\n"
"PO-Revision-Date: 2020-07-04 16:25+0200\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../certbot.templates:1001
msgid "You have unexpired certs; do you still want to purge?"
msgstr ""
"Sie haben Zertifikate, die noch nicht abgelaufen sind, möchten Sie dennoch "
"vollständig löschen?"

#. Type: boolean
#. Description
#: ../certbot.templates:1001
msgid ""
"The certbot configuration directory /etc/letsencrypt still contains "
"unexpired certificates that may be live on your system.  If you choose this "
"option, the purge will continue and delete those certificates, potentially "
"breaking services which depend on them."
msgstr ""
"Das Certbot-Konfigurationsverzeichnis »/etc/letsencrypt« enthält noch "
"Zertifikate, die noch nicht abgelaufen sind und auf Ihrem System genutzt "
"werden könnten. Falls Sie diese Option auswählen, wird das vollständige "
"Löschen fortgesetzt und diese Zertifikate löschen. Dadurch werden "
"möglicherweise Dienste beschädigt, die von diesen Zertifikaten abhängen."

#. Type: boolean
#. Description
#: ../certbot.templates:1001
msgid ""
"If you have already installed different certificates in your services, or "
"you have confirmed you don't have any services depending on these "
"certificates, you should choose this option.  To cancel and manually delete "
"the /etc/letsencrypt directory, you should refuse this option."
msgstr ""
"Falls Sie bereits andere Zertifikate auf Ihrem System installiert haben oder "
"Sie überprüft haben, dass keine Dienste von diesen Zertifikaten abhängen, "
"dann sollten Sie diese Option auswählen. Um abzubrechen und das Verzeichnis "
"»/etc/letsencrypt« händisch zu löschen, sollten Sie diese Option ablehnen."

Bug#964247: qemu-kvm: 5.0-6 breaks macos guests

[Michael Tokarev]

04.07.2020 17:08, Simon John wrote:
> Just tried compiling qemu from their git master and it has the same problem.
> 
> Compiling tag v5.0.0 and even branch 4.2.1 works fine.
> 
> So i guess the problem isn't the debian patches, but whatever changed in 
> master since the debian build 5.0-5

The changes in debian since build 5.0-5 come from upstream as bugfixes,
all the changes are in debian/patches/series file.  Here's the list:

$ git diff debian/qemu_5.0-5..debian-unstable debian/patches/series
diff --git a/debian/patches/series b/debian/patches/series
index 59817de0958..88329162f59 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,21 @@ 
aio-posix-dont-duplicate-fd-handler-deletion-in-fdmon_io_uring_destroy.patch
 aio-posix-disable-fdmon-io_uring-when-GSource-is-used.patch
 hostmem-dont-use-mbind-if-host-nodes-is-empty.patch
 net-use-peer-when-purging-queue-in-qemu_flush_or_purge_queue_packets.patch
+qemu-nbd-close-inherited-stderr.patch
+9p-lock-directory-streams-with-a-CoMutex.patch
+virtio-balloon-fix-free-page-hinting-check-on-unreal.patch
+virtio-balloon-fix-free-page-hinting-without-an-iothread.patch
+virtio-balloon-unref-the-iothread-when-unrealizing.patch
+net-do-not-include-a-newline-in-the-id-of-nic-device.patch
+fix-tulip-breakage.patch
+fix-qga-assert-regression.patch
+ati-vga-check-mm_index-before-recursive-call-CVE-2020-13800.patch
+revert-memory-accept-mismatching-sizes-in-memory_region_access_valid-CVE-2020-13754.patch
+exec-set-map-length-to-zero-when-returning-NULL-CVE-2020-13659.patch
+megasas-use-unsigned-type-for-reply_queue_head-and-check-index-CVE-2020-13362.patch
+megasas-use-unsigned-type-for-positive-numeric-fields.patch
+megasas-fix-possible-out-of-bounds-array-access.patch
+nbd-server-avoid-long-error-message-assertions-CVE-2020-10761.patch
+es1370-check-total-frame-count-against-current-frame-CVE-2020-13361.patch
+sdcard-update-coding-style-to-make-checkpatch-happy.patch
+sdcard-dont-switch-to-ReceivingData-if-address-is-invalid-CVE-2020-13253.patch

Most of that seems to be unrelated. I can only think about
sdcard changes, but that is hardly relevant, either..

/mjt

Bug#964247: qemu-kvm: 5.0-6 breaks macos guests

[Simon John]

Just tried compiling qemu from their git master and it has the same problem.

Compiling tag v5.0.0 and even branch 4.2.1 works fine.

So i guess the problem isn't the debian patches, but whatever changed in 
master since the debian build 5.0-5


Regards.

--
Simon John

Bug#964253: libbluray: Include list_titles and bdsplice utilities

[Oneric]

Package: libbluray-bin
Version: 1:1.1.0-1
Severity: wishlist

Hi,

I think it might be worth including the `list_titles` and `bdsplice` utilities 
in libbluray-bin (curretnly only `bd_info`).
list_titles gives some more information about titles/playlists on the BD and 
bdsplice allows to extract single titles/playlists or just some chapters.

Just like `bd_info` the source of these utilities is already present in 
libbluray in src/examples and also already built – but not yet included in 
libbluray-bin.

Regards
Nils König

Bug#964252: Failure to build from source on buster

[Nils König]

Source: libbluray
Version: 1.1.0-1
Severity: serious
Tags: ftbfs

Hi,

Building from source fails on buster (amd64) while trying to create pdf docs.
Relevant log excerpt at end of mail, full log available here:
  https://oneric.de/public/libbluray-1.1.0-1_ftbfs.log
It seems like that, while no tex files are produced, doxygen still tries to 
build pdf docs.

I retrieved the source with
  apt-get source libbluray/buster
and tried building both with
  apt-get source -b libbluray/buster
and
 debuild -us -uc -b
Build dependencies were installed with mk-build-deps.

System: Debian Buster amd64
 libc6   2.28-10
 doxygen 1.8.13-10
 texlive 2018.20190227-2


Either dropping patch 0004-Disable-PDF-documentation or adding

confflags += --disable-doxygen-pdf
confflags += --disable-doxygen-ps

to debian/rules resolved this for me.

Regards
Nils König


---

[…]
Generating file index...
Generating file member index...
Generating example index...
finalizing index lists...
writing tag file...
lookup cache used 359/65536 hits=1092 misses=366
finished...
cd doc/doxygen/latex; \
rm -f *.aux *.toc *.idx *.ind *.ilg *.log *.out; \
/usr/bin/latex refman.tex; \
 refman.idx; \
/usr/bin/latex refman.tex; \
countdown=5; \
while /usr/bin/egrep 'Rerun (LaTeX|to get cross-references right)' \
refman.log > /dev/null 2>&1 \
&& test $countdown -gt 0; do \
/usr/bin/latex refman.tex; \
countdown=`expr $countdown - 1`; \
done; \
/usr/bin/dvips -o ../libbluray.ps refman.dvi
/bin/bash: line 0: cd: doc/doxygen/latex: No such file or directory
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) 
(preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
! I can't find file `refman.tex'.
<*> refman.tex
  
(Press Enter to retry, or Control-D to exit)
Please type another input file name:

Bug#964251: libreoffice-common: needs Breaks+Replaces against openclipart-libreoffice

[Andreas Beckmann]

Package: libreoffice-common
Version: 1:7.0.0~rc1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi Rene,

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

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

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

  Preparing to unpack .../libreoffice-common_1%3a7.0.0~rc1-1_all.deb ...
  Unpacking libreoffice-common (1:7.0.0~rc1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libreoffice-common_1%3a7.0.0~rc1-1_all.deb (--unpack):
   trying to overwrite '/usr/lib/libreoffice/share/gallery/shapes.sdg', which 
is also in package openclipart-libreoffice 1:0.18+dfsg-17
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  rmdir: failed to remove '/var/lib/libreoffice/share/prereg/': No such file or 
directory
  rmdir: failed to remove '/var/lib/libreoffice/share/': No such file or 
directory
  rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or 
directory
  rmdir: failed to remove '/var/lib/libreoffice': No such file or directory
  rmdir: failed to remove '/var/lib/libreoffice': No such file or directory
  Errors were encountered while processing:
   /var/cache/apt/archives/libreoffice-common_1%3a7.0.0~rc1-1_all.deb

These three files are conflicting:

  usr/lib/libreoffice/share/gallery/shapes.sdg
  usr/lib/libreoffice/share/gallery/shapes.sdv
  usr/lib/libreoffice/share/gallery/shapes.thm

openclipart-libreoffice will probably need updates as well to no longer
ship these files (or rename them), it's probably easiest if you fix and
upload that QA maintained package, too.


cheers,

Andreas


openclipart-libreoffice=1:0.18+dfsg-17_libreoffice-common=1:7.0.0~rc1-1.log.gz
Description: application/gzip

Bug#963480:

[Sao I Kuan]

Control: block 963743 by -1

Bug#963234:

[Sao I Kuan]

Control: block 963743 by -1

Bug#963234: RFS: cwlformat [ITP]

[Sao I Kuan]

Hi,

I'm looking for a sponsor for the package:
   cwlformat (#963234)

The package is on:
https://salsa.debian.org/med-team/cwlformat

The package is dependency of benten[1,2].

[1] https://github.com/rabix/benten
[2] https://bugs.debian.org/963743

The package is lintian-clean. The package does have autopkgtest and passed well.

Please consider to review and sponsor this. Any kind of suggestions
are appreciated.

Thank you!

Sincerely,

Sao I Kuan
saoik...@gmail.com

Bug#964250: Master PDF Editor 5 v5.4.38 stopped working

[Joerg Schiermeier, Bielefeld/Germany]

Package: master-pdf-editor
Version: 5.4.38
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

Unfortunaly my payed "Master PDF Editor 5 v5.4.38" stopped working. I got this 
error message in the terminal:

/opt/master-pdf-editor-5/masterpdfeditor5: symbol lookup error: 
/opt/master-pdf-editor-5/masterpdfeditor5: undefined symbol: 
_ZN10QMutexPool17globalInstanceGetEPKv

In a forum related to OpenSUSe I found this:


As I said: i payed money for this software and I expect it to work.

- -- 
Yours sincerely
Joerg Schiermeier


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

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

Versions of packages master-pdf-editor depends on:
ii  libqt5gui5   5.14.2+dfsg-4
ii  libqt5network5   5.14.2+dfsg-4
ii  libqt5printsupport5  5.14.2+dfsg-4
ii  libqt5svg5   5.14.2-2

master-pdf-editor recommends no packages.

master-pdf-editor suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Comment: This was created by GnuPG for Linux.

iQIzBAEBCAAdFiEERMHJSMoKBiNrvtXJodFQ9YsO8GMFAl8Ag0wACgkQodFQ9YsO
8GPZ0Q/9Frsy8CVH/w12h2XpxZ40RL/ewctT5vQQNI2bOePcjHuu7h6nlHjbIGLn
S0UAiIwatjn+qhKGx9fKfNLwPrMqqExhHcQObVIaTSbgNeLuvZ1fdK06Rnql0iJ9
mC9ZO6Ar1OP3T5YwhrSm0Rxkk+tG4Tb7CufSreiPwUnv/7FcqyHd+8J28naMohxq
nX8Qs9MeUjIctPhATAlly2nLnRC9IUk7uk1h/Fg8Mn4XBtO2UsRHNl4hf8hITdg0
onXGWox3dl4OPSIJMT5wSCUsl0UK8Em4iYUwjlTnupTUlyL6bIxxgvuvDj1krckH
kEnWTjqIiV9xs+3lrNFU2KUpFeWGGlAu01vPEXU5ByI3DhrQqEfkHyBwN+AMg7/Q
dBC0oZYkGcPoDrNULV+sWbMAAis5sRW01RGv7Rl+RfgrIM4u+jvylE793iIThxf3
KJ64vM4KvpXxuqjBD971CSfGg7/JNaamx2YuOKXRriHUxzuFrOCsV0ntOHcqUwAI
1T7hqY/d6bNWMndPgdTL+GcIOporzTsNBfpFdS+CFGdgR9Uvg1lDuo2mGjLL60UV
LcP6rkkss/6GWbYpLUXaUcu+W5MgpvYZNrUcRxIuAQZBryxlnQ20YDS6d5kwcuUT
yIQyvtF8ixfSWrIOgJ2XlCplKwA9RO2DjPQORD4bdX/4OuoU3rk=
=596B
-END PGP SIGNATURE-

Bug#963480: RFS: python-duckpy [ITP]

[Sao I Kuan]

Hi,

I'm looking for a sponsor for the package:
  *python-duckpy (#963480)

The package is on:
https://salsa.debian.org/med-team/python-duckpy

The package is dependency of benten[1,2].

[1] https://github.com/rabix/benten
[2] https://bugs.debian.org/963743

The package is lintian-clean.

Please consider to review and sponsor this. Any kind of suggestions
are appreciated.

Thank you!

Sincerely,

Sao I Kuan
saoik...@gmail.com

Bug#963971: [Pkg-samba-maint] Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

[Michael Stone]

On Sat, Jul 04, 2020 at 03:21:03PM +0200, Mathieu Parent wrote:

Le sam. 4 juil. 2020 à 15:15, Michael Stone  a écrit :


On Sat, Jul 04, 2020 at 07:28:32AM +0200, Mathieu Parent wrote:
>clone 963971 -1
>tag 963971 + upstream
>tag -1 + upstream fixed-upstream patch
>reassign -1 sssd-ad-common
>
>Le lun. 29 juin 2020 à 14:48, Michael Stone  a écrit :
>>
>> Package: samba-libs
>> Version: 2:4.12.3+dfsg-2
>> Severity: critical
>> Justification: breaks the whole system
>>
>> The new samba-libs package changes the soname of libndr from libndr.so.0 to
>> libndr.so.1 without reflecting this change in the package name. 
sssd-ad-common
>> has a dependency on samba-libs (>= 2:4.11.5+dfsg) and links to libndr.so.0.
>> When the samba-libs package is updated and libndr.so.0 disappears sssd fails 
to
>> start, which then makes a system's remote users unavailable. (Worse, this
>> doesn't happen until the next time sssd restarts--which may not be until the
>> next reboot.)
>
>It looks to be fixed in sssd 2.3.0:
>https://github.com/SSSD/sssd/commit/bc56b10aea999284458dcc293b54cf65288e325d
>
>I'm cloning this bug:
>- on the samba side I'll add a breaks: sssd-ad-common (<< 2.3.0)
>- on the sssd side, an update to 2.3.0+ is needed

Going forward, do things using samba-libs need a strict version
depenedency since there is no ABI version in the package name?


No, I think. According to the sssd commit, sssd 2.3 will still build
on older samba-libs.


Not a build-time dependency, a run-time dependency; if there is no 
guarantee that the ABI is stable between versions, a dependency on 
"samba-libs >= something" simply isn't valid. (Packages built from the 
samba source package already have a dependency on "samba-libs = version" 
but there currently isn't anything telling other packages that the 
dependencies need to work that way.)