Bug#995806: nmu: js-of-ocaml_3.8.0-2

[Ralf Treinen]

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

nmu js-of-ocaml_3.8.0-2 . ANY . unstable . -m "rebuild against menhir 20210929"

libjs-of-ocaml-dev is no longer installable and needs to be rebuild
against the version of menhir in unstable. This is also blocking the
migration of menhir to testing.

-Ralf.

Bug#941830: pypy3: "import numpy" complains with: "Original error was: No module named 'numpy.core._multiarray_umath'"

[Stefano Rivera]

Hi Kingsley (2019.10.05_20:32:52_-0700)
> Here's how I elicited the error:
> 
> 1.) $ pypy3
> 
> 2.) import numpy

I'm afraid python3-numpy is only built against cpython. We haven't had
had debian python package maintainers start to build their (non-pure
python) packages for pypy3 too, yet.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#995192: carbon-c-relay: the current stable contains a _recalled_ version, hogs CPU

[Filippo Giunchedi]

On Mon, Sep 27, 2021 at 08:34 PM, grin wrote:
> I strongly suggest to update stable somehow, since this makes the package 
> pretty dangerous:
> it may kill a perfectly close-to-idle system by pushing it to 100% CPU on 
> multiple threads
> after a simple upgrade.

I've run into this as well and I agree. I think this bugfix is reasonable
for inclusion in 11.2.

Bug#995807: geoalchemy2: Use virtual postgis packages to be PG version independent.

[Bas Couwenberg]

Source: geoalchemy2
Version: 0.9.4-1
Severity: normal
Tags: patch

Dear Maintainer,

Your package is included in the postgresql-14 transition tracker [0]
because it build depends on postgresql-13-postgis and
postgresql-13-postgis-scripts.

These packages provide a version independent virtual package which you
should use instead:

 * postgresql-postgis
 * postgresql-postgis-scripts

The attached patch updates the build dependencies to do so.

Please consider applying the patch to remove to need to update your
package for future postgresql transitions.

[0] https://release.debian.org/transitions/html/postgresql-14.html

Kind Regards,

Bas
diff -Nru geoalchemy2-0.9.4/debian/changelog geoalchemy2-0.9.4/debian/changelog
--- geoalchemy2-0.9.4/debian/changelog  2021-08-30 15:32:56.0 +0200
+++ geoalchemy2-0.9.4/debian/changelog  2021-10-06 09:05:37.0 +0200
@@ -1,3 +1,10 @@
+geoalchemy2 (0.9.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use virtual postgis packages to be PG version independent.
+
+ -- Bas Couwenberg   Wed, 06 Oct 2021 09:05:37 +0200
+
 geoalchemy2 (0.9.4-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru geoalchemy2-0.9.4/debian/control geoalchemy2-0.9.4/debian/control
--- geoalchemy2-0.9.4/debian/control2021-08-30 15:32:19.0 +0200
+++ geoalchemy2-0.9.4/debian/control2021-10-06 09:05:29.0 +0200
@@ -7,8 +7,8 @@
dh-sequence-python3,
dh-sequence-sphinxdoc,
postgis,
-   postgresql-13-postgis,
-   postgresql-13-postgis-scripts,
+   postgresql-postgis,
+   postgresql-postgis-scripts,
python3-all,
python3-psycopg2,
python3-pytest,

Bug#679905: RFP: cctbx -- Computational Crystallography Toolbox

[Andreas Tille]

Hi,

I've got a hint about cctbx and realised that there is an RFP (degraded
from ITP) as well as a salsa repository[1].  I took the freedom to
inject the latest upstream source and updated *parts* of the packaging
to recent standards.  I have no idea whether this might give some new
inspiration for those who want to catch up with this package, which is
interesting for several teams (in CC).  So I simply make some noise for
anybody who might want to continue from here.

Kind regards

  Andreas.

[1] https://salsa.debian.org/science-team/cctbx

-- 
http://fam-tille.de

Bug#994086: transition: netcdf

[Sebastian Ramacher]

On 2021-10-06 06:42:42, Sebastiaan Couwenberg wrote:
> Testing still lacks a few rebuilt packages for this transition.
> 
> labplot should migrated in two days.
> 
> pymol will be rebuilt in unstable after it gets out the DELAYED
> according to #995666, although I don't see it at
> 
>  ftp://ftp.upload.debian.org/pub/UploadQueue/DELAYED/

You can find the deferred queue at https://ftp-master.debian.org/deferred.html

Cheers

> 
> magics++ & metkit are blocked by eckit which is no longer built on 32bit
> architectures, and is waiting for ftpmaster to act on #993624.
> 
> Kind Regards,
> 
> Bas
> 
> -- 
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
Sebastian Ramacher

Bug#631665: postfix: Postfix has stopped sending mail

[GC]

A day !
A day spent trying to find out why postfix no longer wants to send by SMTP
(pipe OK). At least I have a track .. this is a bug of the package. But I
don't have nscd installed.

BlackFury

Bug#995808: --help does not mention required --enable-local-file-access

[Enrico Zini]

Package: wkhtmltopdf
Version: 0.12.6-1
Severity: important

Hello,

Thank you for packaging wkhtmltopdf!

wkhtmltopdf version 0.12.6 blocks by default access to local files (note
the "Warning: Blocked access to file"):

   $ wkhtmltopdf test.html test.pdf
   Loading page (1/2)
   Warning: Blocked access to file   
   Error: Failed to load about:blank, with network status code 301 and http 
status code 0 - Protocol "about" is unknown
   Printing pages (2/2)   
   Done   
   Exit with code 1 due to network error: ProtocolUnknownError

Using --enable-local-file-access makes it work:

   $ wkhtmltopdf --enable-local-file-access test.html test.pdf
   Loading page (1/2)
   Printing pages (2/2)   
   Done

However, earlier version of wkhtmltopdf did not support
--enable-local-file-access, and using it would cause it to error out
complaining about usage of a non-existing option.

A program calling wkhtmltopdf for rendering needs to figure out when
--enable-local-file-access is needed and when it's harmful, here's an
example use case:

   https://github.com/Truelite/python-a38/issues/6

To avoid needing to parse and compare --version output, I had opted to
parse the output of --help: if the option was documented, then it was
needed; if it was not documented, then it wasn't supported.

The version of wkhtmltopdf currently in stable requires
--enable-local-file-access but does not document it (!!)
causing both a conundrum for users who get an error message and no
documentation on the option that would fix it, and for software trying
to figure out the effective CLI interface for manipulating wkhtmltopdf
as a backend tool.


Enrico


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

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

Versions of packages wkhtmltopdf depends on:
ii  libc62.31-13
ii  libgcc-s110.2.1-6
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5network5   5.15.2+dfsg-9
ii  libqt5printsupport5  5.15.2+dfsg-9
ii  libqt5svg5   5.15.2-3
ii  libqt5webkit55.212.0~alpha4-11
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6

Versions of packages wkhtmltopdf recommends:
ii  tigervnc-standalone-server [xserver]  1.11.0+dfsg-2
ii  xserver-xephyr [xserver]  2:1.20.11-1
ii  xserver-xorg [xserver]1:7.7+22

wkhtmltopdf suggests no packages.

-- no debconf information

Bug#992196: [Pkg-sugar-devel] Bug#992196: Fwd: ITP: opensmalltalk-vm -- High performance virtual machine for Smalltalk

[Jonas Smedegaard]

Quoting Phil Bellalouna (2021-10-06 01:44:20)
> On Tue, Oct 5, 2021 at 2:06 PM Jonas Smedegaard  
> wrote:
> > Quoting Phil Bellalouna (2021-08-17 05:10:24)
> > > * Package name: opensmalltalk-vm
> > >   Version : 1.0
> > >   Upstream Author : squeak.org
> > > * URL : https://github.com/OpenSmalltalk/opensmalltalk-vm
> > > * License : MIT
> > >   Programming Lang: Smalltalk, C
> > >   Description : High performance virtual machine for Smalltalk
> > >
> > > (this is part of the Squeak project https://squeak.org)
> > >
> > [...]
> >
> > First of all, sorry for the late reply!
> >
> 
> No worries.  Your timing is actually just about perfect as we have 
> some things nearly ready to go and some administrative decisions will 
> need to be made.

Phew!  I worried if my/our silence had discouraged you too much.


> > I am quite happy to help maintain opensmalltalk-vm.  I have tried 
> > several times wrap my head around it but failed so far, so I am very 
> > pleased that you are reaching out and want to do this 
> > collaboratively.
> >
> 
> That's great to hear.  There's nothing terribly complicated about it, 
> but some of the approach and conventions adopted predate modern open 
> source by a couple of decades.  So it can tend to look a bit alien if 
> you're not used to it.  Hopefully I can fill in any gaps and generally 
> help you make sense of it.
> 
> 
> > I suggest that we use the Sugar team as platform for this package - 
> > just because it exists already, has very low activity, and is 
> > somewhat related (although if I understand correctly 
> > opensmalltalk-vm is not usable with EToys which is the only 
> > Smalltalk piece in Sugar.
> >
> 
> That works for me.  That is correct, opensmalltalk-vm will not 
> (directly) support EToys or Scratch which is part of why we also want 
> to keep (and still maintain upstream) the squeak-vm package.  One of 
> the things I've been working on is for multiple VMs to co-exist 
> side-by-side to enable simultaneously running old and new images which 
> we can discuss in more detail as we get into it.

Sounds good - both parts.


> > If that's ok with you (and if you are still around and interested, 
> > after this much silence on my part) then please create an account at 
> > Salsa and request membership in the Sugar team - as that's how you 
> > can have write access to our git repos there.  More info on that at 
> > https://wiki.debian.org/Sugar#Development and more generally at 
> > https://wiki.debian.org/Salsa
> 
> 
> I've registered at Salsa but am getting a message: 'You have signed up 
> successfully. However, we could not sign you in because your account 
> is awaiting approval from your GitLab administrator.'  So I guess I'm 
> waiting for someone to review and approve the registration?

I agree: Give it some days, and if still not working shout out - then I 
can try nuddge some folks e.g. via irc.


> > You might also want to register at the Sugar mailinglist, to receive 
> > the emails related to the packaging work.
> 
> I'm still subscribed the pkg-sugar-dev mailing list so assuming that's 
> the list you mean, we should be good to go there.

Yes, that's what I meant.

I've dropped you as direct cc on this mail now: Posting style for Debian 
lists is to only cc when explicitly requested: 
https://www.debian.org/MailingLists/#codeofconduct


Looking forward to collaborate with you,

 - 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#978051: Need it

[Bastien Roucariès]

Hi;

I need it for gulp-wrap that is needed for a chai extension

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

Bug#995809: libinput: please make the build reproducible

[Chris Lamb]

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

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
libinput could not be built reproducibly.

This is due to the use of the LIBINPUT_QUIRKS_DIR macro which includes
the absolute build path.

It is not entirely clear (during a very brief look) when/where this
value is even used — the testsuite still passes even if this is set to
a dummy value (see attached dummy patch). And, of course, the build
path cannot be relied upon at runtime.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0001-reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0001-reproducible-build.patch  2021-10-06 
10:05:03.555141278 +0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-10-06
+
+--- libinput-1.19.1.orig/meson.build
 libinput-1.19.1/meson.build
+@@ -13,7 +13,7 @@ dir_libexec = get_option('prefix') /
+ dir_lib = get_option('prefix') / get_option('libdir')
+ dir_man1= get_option('prefix') / get_option('mandir') / 'man1'
+ dir_system_udev = get_option('prefix') / 'lib' / 'udev'
+-dir_src_quirks  = meson.current_source_dir() / 'quirks'
++dir_src_quirks  = '/nonexistent'
+ dir_src_test= meson.current_source_dir() / 'test'
+ dir_src = meson.current_source_dir() / 'src'
+ 
--- a/debian/patches/series 2021-10-06 09:35:40.889907597 +0100
--- b/debian/patches/series 2021-10-06 10:00:57.178902346 +0100
@@ -1 +1,2 @@
 #placeholder
+0001-reproducible-build.patch

Bug#982959: ifupdown: regex not workig as expected

[Santiago Ruano Rincón]

El 06/10/21 a las 09:24, Martin-Éric Racine escribió:
> la 2. lokak. 2021 klo 11.13 Michael Biebl (bi...@debian.org) kirjoitti:
> >
> > Am 02.10.21 um 09:05 schrieb Martin-Éric Racine:
> > > pe 1. lokak. 2021 klo 23.39 Santiago Ruano Rincón
> > > (santiag...@riseup.net) kirjoitti:
> > >>
> > >> El 01/10/21 a las 17:05, Martin-Éric Racine escribió:
> > >>> pe 1. lokak. 2021 klo 16.21 Santiago Ruano Rincón
> > >>> (santiag...@riseup.net) kirjoitti:
> >  On Wed, 17 Feb 2021 14:32:24 +0200 Martin-Éric_Racine 
> >   wrote:
> > > Package: ifupdown
> > > Version: 0.8.36
> > > Severity: normal
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > The regex recipe below does not work as expected. I've tried both
> > >
> > > allow-hotplug /en*=en /wl*=wl
> > >
> > > and
> > >
> > > allow-hotplug /en*/=en /wl*/=wl
> > >
> > > but ifup still doesn't raise whatever interface match the regex. Have 
> > > I misunderstood the examples or am I missing something else?
> > >
> > > Thanks!
> > >
> > > - -- Package-specific info:
> > > - --- /etc/network/interfaces:
> > > allow-hotplug /en*=en /wl*=wl
> > >
> > > iface en inet dhcp
> > > iface en inet6 auto
> > >  privext 2
> > >  #dhcp 1
> > >
> > > iface wl inet dhcp
> > >  wpa-ssid AccessPoint
> > >  wpa-psk mypassword
> > > iface wl inet6 auto
> > >  privext 2
> > >  #dhcp 1
> > >>>
> > >>> [...]
> > >>>
> >  I get both interfaces configured. Could you please run ifup with -v?
> > >>>
> > >>> I just tried. Here's an interesting difference:
> > >>>
> > >>> If I use 'sudo ifup -a -v' ifup won't find the mapped interfaces.
> > >>
> > >> ifup doesn't process them since they are not configured with `auto`
> > >
> > > OK, what processes interfaces with allow-hotplug then, if not ifupdown?
> > >
> > >> s/allow-hotplug/auto/ in my /e/n/interfaces makes this work.
> > >>>
> > >>> If I use 'sudo ifup --allow hotplug -a -v' ifup correctly finds and
> > >>> maps the wireless interfaces.
> > >>>
> > >>
> > >> I wonder if there is a problem related with udev instead.
> > >
> > > Added udev (systemd) maintainers in CC.
> >
> > If you are referring to
> > /lib/udev/ifupdown-hotplug and /lib/udev/rules.d/80-ifupdown.rules,
> > those files are maintained by the ifupdown package.
> >
> > The systemd package is not involved here.
> 
> Michael, I suspected as much. Thanks for confirming this.
> 
> Santiago, all evidences point to ifupdown pattern matching only
> working for auto interfaces, but not hotplug interfaces.

Not exactly, I think. 'sudo ifup --allow hotplug -a -v' works for you.

> Basically,
> hotplug works for named interfaces, but not for pattern matched
> interfaces.

ifupdown-hotplug receives as argument the name of the real
interface, so it execs ifup --allow=hotplug $INTERFACE
https://salsa.debian.org/debian/ifupdown/-/blob/master/debian/ifupdown-hotplug#L73
and it wouldn't find it in your configuration.

Maybe your use case matches better templates and inherits (See INTERFACE
TEMPLATES) in interfaces(5).

HTH,

 -- S


signature.asc
Description: PGP signature

Bug#995808: The option is documented in --extended-help

[Enrico Zini]

Severity: normal

I found that the option is documented in -H (--extended-help) instead of
--help, and I can successfully use that to figure out what API is
expected by wkhtmltopdf.

I suppose, for such a common use case, that command line option
shouldn't be hidden outside of the normal help, or the error message
should mention the existance of --enable-local-file-access: it really
looks like wkhtmltopdf is unable to render local files!

Depending on sensitivities, the severity and validity of this bug may
vary: I'll leave it up to you to decide whether to keep it open, and
what its severity should be


Enrico

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

Bug#982959: ifupdown: regex not workig as expected

[Martin-Éric Racine]

ke 6. lokak. 2021 klo 12.20 Santiago Ruano Rincón
(santiag...@riseup.net) kirjoitti:
>
> El 06/10/21 a las 09:24, Martin-Éric Racine escribió:
> > la 2. lokak. 2021 klo 11.13 Michael Biebl (bi...@debian.org) kirjoitti:
> > >
> > > Am 02.10.21 um 09:05 schrieb Martin-Éric Racine:
> > > > pe 1. lokak. 2021 klo 23.39 Santiago Ruano Rincón
> > > > (santiag...@riseup.net) kirjoitti:
> > > >>
> > > >> El 01/10/21 a las 17:05, Martin-Éric Racine escribió:
> > > >>> pe 1. lokak. 2021 klo 16.21 Santiago Ruano Rincón
> > > >>> (santiag...@riseup.net) kirjoitti:
> > >  On Wed, 17 Feb 2021 14:32:24 +0200 Martin-Éric_Racine 
> > >   wrote:
> > > > Package: ifupdown
> > > > Version: 0.8.36
> > > > Severity: normal
> > > >
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA256
> > > >
> > > > The regex recipe below does not work as expected. I've tried both
> > > >
> > > > allow-hotplug /en*=en /wl*=wl
> > > >
> > > > and
> > > >
> > > > allow-hotplug /en*/=en /wl*/=wl
> > > >
> > > > but ifup still doesn't raise whatever interface match the regex. 
> > > > Have I misunderstood the examples or am I missing something else?
> > > >
> > > > Thanks!
> > > >
> > > > - -- Package-specific info:
> > > > - --- /etc/network/interfaces:
> > > > allow-hotplug /en*=en /wl*=wl
> > > >
> > > > iface en inet dhcp
> > > > iface en inet6 auto
> > > >  privext 2
> > > >  #dhcp 1
> > > >
> > > > iface wl inet dhcp
> > > >  wpa-ssid AccessPoint
> > > >  wpa-psk mypassword
> > > > iface wl inet6 auto
> > > >  privext 2
> > > >  #dhcp 1
> > > >>>
> > > >>> [...]
> > > >>>
> > >  I get both interfaces configured. Could you please run ifup with -v?
> > > >>>
> > > >>> I just tried. Here's an interesting difference:
> > > >>>
> > > >>> If I use 'sudo ifup -a -v' ifup won't find the mapped interfaces.
> > > >>
> > > >> ifup doesn't process them since they are not configured with `auto`
> > > >
> > > > OK, what processes interfaces with allow-hotplug then, if not ifupdown?
> > > >
> > > >> s/allow-hotplug/auto/ in my /e/n/interfaces makes this work.
> > > >>>
> > > >>> If I use 'sudo ifup --allow hotplug -a -v' ifup correctly finds and
> > > >>> maps the wireless interfaces.
> > > >>>
> > > >>
> > > >> I wonder if there is a problem related with udev instead.
> > > >
> > > > Added udev (systemd) maintainers in CC.
> > >
> > > If you are referring to
> > > /lib/udev/ifupdown-hotplug and /lib/udev/rules.d/80-ifupdown.rules,
> > > those files are maintained by the ifupdown package.
> > >
> > > The systemd package is not involved here.
> >
> > Michael, I suspected as much. Thanks for confirming this.
> >
> > Santiago, all evidences point to ifupdown pattern matching only
> > working for auto interfaces, but not hotplug interfaces.
>
> Not exactly, I think. 'sudo ifup --allow hotplug -a -v' works for you.

I should not have to type that manually to have ifupdown find and
raise the interfaces.

> > Basically,
> > hotplug works for named interfaces, but not for pattern matched
> > interfaces.
>
> ifupdown-hotplug receives as argument the name of the real
> interface, so it execs ifup --allow=hotplug $INTERFACE
> https://salsa.debian.org/debian/ifupdown/-/blob/master/debian/ifupdown-hotplug#L73
> and it wouldn't find it in your configuration.

Which is precisely the problem. The mapping fails.

> Maybe your use case matches better templates and inherits (See INTERFACE
> TEMPLATES) in interfaces(5).

It doesn't. Templates rely upon explicitly defining interfaces.

Martin-Éric

Bug#994275: Reverting breaking changes in debianutils

[Simon McVittie]

On Sun, 03 Oct 2021 at 22:09:31 +, Clint Adams wrote:
> The package description uses the phrases "specific to Debian" and
> "installation scripts of Debian packages".  The fact that
> debianutils is used on non-deb operating systems suggests a failure
> at the former.

Given its package description, I too am confused by other distributions
having picked up debianutils (as it seems at least Arch and Gentoo have),
but the packages found in non-Debian-derived distributions are not under
our control.

> The fact that 95% of my inbox consists of hatemail
> about the interactive usage of `which` suggests a failure at the
> latter.

I'm sorry you're receiving hatemail about this package, and that's not
OK, but it's orthogonal to whether the changes discussed in this bug
were the right thing for Debian.

> debianutils should consist solely of utilities that are actually
> deserving of Essential status, that are maintained by debianutils
> upstream, and do not needlessly duplicate functionality provided by
> other sources.

I was under the impression that debianutils is (intended to be)
a Debian-specific package with no separate upstream existence. Does
it have releases other than "whatever is in unstable"? Is there an
upstream maintainer distinct from its Maintainer and Uploaders, namely
you and Manoj?

"debianutils should consist of utilities maintained in debianutils"
seems slightly circular. Is there an intended scope for what's in
debianutils, beyond "things that need to be Essential because they
always used to be Essential"?

I see that CONTRIBUTING documents some of the utilities in debianutils
as being unsupported/pending deprecation, such that if new features are
desired, contributors are asked to instead fork the utility and coordinate
removal from debianutils (and presumably takeover by a new package, given
their Essential status). Can we infer the utilities you want to continue to
maintain are everything not on that list?

debianutils currently has:

- add-shell, remove-shell, update-shells: Debian-specific(?)
  maintainer-script infrastructure for maintaining /etc/shells,
  analogous to how init-system-helpers maintains system services.
  Clearly at least transitively Essential, because if they were a
  separate package, the Essential dash and bash would depend on them.

- ischroot, run-parts, savelog, which (and historically tempfile):
  these seem more like general-purpose utilities than anything else,
  and Essential from their wide use without an explicit dependency?
  Of these, CONTRIBUTING describes ischroot, savelog and which as being
  unsupported (deprecated or pending deprecation) but presumably
  run-parts is not in that category?

  CONTRIBUTING calls out logrotate as being better than savelog, but
  savelog gets used by Essential packages like dpkg, and I don't think
  logrotate is necessarily suitable to be transitively Essential.

- installkernel: the Debian implementation of an integration hook that
  is expected to be invoked by the upstream Linux kernel build
  system, analogous to how LSB init scripts can expect to source
  /lib/lsb/init-functions and we provide a Debian implementation of that
  interface in lsb-base?

> Divestiture of mktemp, readlink, sensible-editor, sensible-pager,
> sensible-browser, tempfile, and possibly mkboot were adjustments
> toward a better debianutils.

Yes, and in general I think that direction is fine, as long as the
transition away from these utilities being in debianutils is done carefully.

mktemp and readlink were taken over by Essential coreutils, with
a transitional Pre-Depends; sensible-* were moved to non-Essential
sensible-utils, with a transitional Depends (making sensible-utils
transitively Essential for one release) to ensure existing systems didn't
lose them, and presumably some reasonable plan to ensure that dropping
them from the Essential set wouldn't break existing packages.

mkboot doesn't have a replacement that I know of, but it seems like the
sort of utility that had a very limited use by the time it was removed,
so I'm happy to trust your judgement on what the appropriate time was to
remove it ("your" referring to you and Manoj as a team here - I know it
was actually Manoj who removed that one).

However, I don't think which(1) and tempfile(1) are really in the same
situation as all those. From my point of view, debianutils which(1) has a
lot in common with sysvinit-utils pidof(8): if we were defining Essential
today, those programs likely wouldn't be in it, and they should probably
be used a lot less than they are (in favour of the command builtin and
pgrep, respectively); but the fact remains that they *are* in Essential,
and too widely-used (by packages with no dependency, because Essential)
for a mass-bug-filing to be straightforward.

which(1) and tempfile(1) suffer from this somewhat worse than pidof,
because "which" is a common English word and "tempfile" is a common
name for variables, so locating users of those utilit

Bug#978051: [Pkg-javascript-devel] Bug#978051: Need it

[Yadd]

Le 06/10/2021 à 11:12, Bastien Roucariès a écrit :
> Hi;
> 
> I need it for gulp-wrap that is needed for a chai extension

OK, I'm working on it

Bug#995722: [Pkg-javascript-devel] Bug#995722: loash: Vendoring should be removed

[Yadd]

On Lu, 04 oct 21, 16:40:48, Bastien Roucariès wrote:
> Source: src:node-lodash
> Version: 4.17.21+dfsg+~cs8.31.173-1
> Severity: serious
> Justification: do not compile from source
>
> Dear Maintainer,
>
> The vendor directory should be emptied
>
> The debug version is compiled without source (lintian warn) and moreover the
> rest of file are already packaged
>
> grep -R vendor * gives only a few hit that could be cured by symlinking
>
> Bastien
Hi,

this files are used for test only, maybe severity could be decreased.

Cheers,
Yadd

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Niko Tyni]

On Wed, Sep 15, 2021 at 12:35:38PM +0100, Simon McVittie wrote:

> https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md

Many thanks for your work, and sorry for not participating earlier.

I agree with you that it would be good to send advice out sooner
rather than later.

I also agree with pretty much all you're saying in the text.

In particular:

> Questions for the committee:
> 
> - §(Definitions and current status): Does everyone agree with my
>   characterization of where we are now?

Ack from me.

> - §(Upgrade path from Debian 11 to Debian 12): Does everyone agree
>   with what I've written here about the implications of #978636?

I think I can follow the logic, and I agree with it.

> - §(Upgrade path from Debian 11 to Debian 12): Is the last paragraph
>   "If a suitable transition mechanism is not available by the time the
>   Debian 12 freeze is reached..." necessary, or is it implicit that
>   *obviously* we won't demand that the project carries on with merged-/usr
>   if it turns out not to be possible?

I think it should be included.

> - §(Testing and QA): Do we want to recommend this?

It does feel a bit like micro-managing to me. But the reasoning
makes sense. I'm fine with recommending it.
 
> - §(Building packages): Does everyone agree with my interpretation of
>   what we agreed in #914897 and its implications? Do we need to make a
>   recommendation for the Debian 12 development cycle, or is it enough
>   to assume that the "middle" option that we resolved in #914897
>   continues to be our opinion?

I agree and I don't think we need a new recommendation.

> - §(Building packages): I almost wrote an extra paragraph about how
>   this class of bugs becomes a non-issue when merged-/usr is the only
>   supported layout - but actually it doesn't! If we consider building
>   packages while having /usr/local/bin/sed to be a supported thing you
>   can do, then we need to ensure that /usr/local/bin/sed doesn't get
>   hard-coded into the resulting package, and the steps you take to
>   make that happen are the same as the steps you take to fix this class
>   of bugs.

FWIW I think we've traditionally considered such /usr/local -related
issues as bugs in the build setup rather than in the packages.

> - §(Moratorium on moving files' logical locations into /usr):
>   I think we should stop moving files into /usr on an individual basis,
>   at least until the consequences are fully understood, and perhaps for
>   the whole Debian 12 release cycle (after which, assuming merged-/usr
>   goes as we have recommended, maintainers can swap their logical location
>   without needing a transitional mechanism any more). Implementing
>   merged-/usr as the only supported layout means that moving files into
>   /usr on an individual basis is mostly unnecessary, because it has no
>   practical effect any more.

Agreed on the moratorium, mainly because of the unnecessity and the
error-prone nature of the moves. Sam brought up concerns about the
Replaces failure mode mentioned in the text, that part might need
changing.

On Mon, Sep 27, 2021 at 10:59:37AM +0100, Simon McVittie wrote:

> I am a little concerned that usrmerge is doing more intrusive surgery on
> a running system than even what's normal for an apt/dpkg-based upgrade,
> so I would prefer not to rule out designs that defer this action to a
> later time.

I share this concern.

-- 
Niko

Bug#995722: [Pkg-javascript-devel] Bug#995722: Bug#995722: loash: Vendoring should be removed

[Jonas Smedegaard]

Quoting Yadd (2021-10-06 11:43:40)
> On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
> > Source: src:node-lodash
> > Version: 4.17.21+dfsg+~cs8.31.173-1
> > Severity: serious
> > Justification: do not compile from source
> >
> > Dear Maintainer,
> >
> > The vendor directory should be emptied
> >
> > The debug version is compiled without source (lintian warn) and moreover the
> > rest of file are already packaged
> >
> > grep -R vendor * gives only a few hit that could be cured by symlinking
> >
> > Bastien
> Hi,
> 
> this files are used for test only, maybe severity could be decreased.

I find the severity accurate: Relying on non-source code is a severe 
violation of Debian Policy, not matter the purpose of relying on it.


 - 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#995722: [Pkg-javascript-devel] Bug#995722: Bug#995722: loash: Vendoring should be removed

[Yadd]

Le 06/10/2021 à 12:16, Jonas Smedegaard a écrit :
> Quoting Yadd (2021-10-06 11:43:40)
>> On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
>>> Source: src:node-lodash
>>> Version: 4.17.21+dfsg+~cs8.31.173-1
>>> Severity: serious
>>> Justification: do not compile from source
>>>
>>> Dear Maintainer,
>>>
>>> The vendor directory should be emptied
>>>
>>> The debug version is compiled without source (lintian warn) and moreover the
>>> rest of file are already packaged
>>>
>>> grep -R vendor * gives only a few hit that could be cured by symlinking
>>>
>>> Bastien
>> Hi,
>>
>> this files are used for test only, maybe severity could be decreased.
> 
> I find the severity accurate: Relying on non-source code is a severe 
> violation of Debian Policy, not matter the purpose of relying on it.
> 
> 
>  - Jonas

So let's remove test...

Bug#994275: Reverting breaking changes in debianutils

[Adrian Bunk]

On Wed, Oct 06, 2021 at 10:37:25AM +0100, Simon McVittie wrote:
> On Sun, 03 Oct 2021 at 22:09:31 +, Clint Adams wrote:
> > The package description uses the phrases "specific to Debian" and
> > "installation scripts of Debian packages".  The fact that
> > debianutils is used on non-deb operating systems suggests a failure
> > at the former.
> 
> Given its package description, I too am confused by other distributions
> having picked up debianutils (as it seems at least Arch and Gentoo have),
> but the packages found in non-Debian-derived distributions are not under
> our control.
>...

Yocto needs debianutils due to update-ca-certificates using run-parts.

> smcv

cu
Adrian

Bug#995810: libc++-13-dev: cant link without libuwind.so, should depend on that package

[Norbert Lange]

Package: libc++-13-dev
Version: 1:13.0.0-2
Severity: normal



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

Hello,

if you install just clang and libc++-dev,
then a library is missing for linking

Test:
int main() {}' | /usr/bin/clang++ -stdlib=libc++  -stdlib=libc++ -fuse-ld=lld 
-x c -

The solution should be to depend on libunwind-13-dev

Norbert

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

Versions of packages libc++-13-dev depends on:
ii  libc++1-13  1:13.0.0-2

libc++-13-dev recommends no packages.

libc++-13-dev suggests no packages.

-- no debconf information

Bug#679905: [Debichem-devel] RFP: cctbx -- Computational Crystallography Toolbox

[Andrius Merkys]

Hi,

On 2021-10-06 11:13, Andreas Tille wrote:
> I've got a hint about cctbx and realised that there is an RFP (degraded
> from ITP) as well as a salsa repository[1].  I took the freedom to
> inject the latest upstream source and updated *parts* of the packaging
> to recent standards.  I have no idea whether this might give some new
> inspiration for those who want to catch up with this package, which is
> interesting for several teams (in CC).  So I simply make some noise for
> anybody who might want to continue from here.

cctbx is quite complicated to package, alas. There is a wiki page
dedicated almost entirely to the packaging problems [1]. I recently
spent nearly a week recently working on v2021.7, without much success.
The source builds on unstable, however, I have little idea how to
debianize the built artifacts (and remove seemingly embedded absolute
paths from them).

[1] https://wiki.debian.org/DebianScience/cctbx

Best,
Andrius

Bug#995810: libc++-13-dev: cant link without libuwind.so, should depend on that package

[Sylvestre Ledru]

Right, thanks

I fixed it in the vcs

S

Le 06/10/2021 à 12:44, Norbert Lange a écrit :

Package: libc++-13-dev
Version: 1:13.0.0-2
Severity: normal



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

Hello,

if you install just clang and libc++-dev,
then a library is missing for linking

Test:
int main() {}' | /usr/bin/clang++ -stdlib=libc++  -stdlib=libc++ -fuse-ld=lld 
-x c -

The solution should be to depend on libunwind-13-dev

Norbert

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

Versions of packages libc++-13-dev depends on:
ii  libc++1-13  1:13.0.0-2

libc++-13-dev recommends no packages.

libc++-13-dev suggests no packages.

-- no debconf information

Bug#995811: enlightenment: Firefox does not respond to mouse cursor/keys until you double press F11

[Dmitri Sinitin]

Package: enlightenment
Version: 0.24.2-8
Severity: normal
X-Debbugs-Cc: thedrunkyardkee...@gmail.com

Hello! 
Hope you are doing well!

Unlike other wayland compositors (weston etc) in enlightenment you have to 
enter fullscreen mode at least in Firefox so it begun to react at the mouse 
pointer events.
After that the menus are still immune to clicks. Hotkeys works flawless.

ffstart command:
MOZ_ENABLE_WAYLAND=1 firefox


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

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

Versions of packages enlightenment depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  enlightenment-data0.24.2-8
ii  libasound21.2.5.1-1
ii  libbluetooth3 5.61-1
ii  libc6 2.32-4
ii  libecore-con1 1.25.1-1
ii  libecore-drm2-1   1.25.1-1
ii  libecore-evas11.25.1-1
ii  libecore-file11.25.1-1
ii  libecore-input1   1.25.1-1
ii  libecore-ipc1 1.25.1-1
ii  libecore-wl2-11.25.1-1
ii  libecore-x1   1.25.1-1
ii  libecore1 1.25.1-1
ii  libedje-bin   1.25.1-1
ii  libedje1  1.25.1-1
ii  libeet1   1.25.1-1
ii  libeeze1  1.25.1-1
ii  libefreet-bin 1.25.1-1
ii  libefreet1a   1.25.1-1
ii  libeina1a 1.25.1-1
ii  libeio1   1.25.1-1
ii  libelementary11.25.1-1
ii  libelput1 1.25.1-1
ii  libemile1 1.25.1-1
ii  libemotion1   1.25.1-1
ii  libevas1  1.25.1-1
ii  libevas1-engines-drm  1.25.1-1
ii  libevas1-engines-wayland  1.25.1-1
ii  libevas1-engines-x1.25.1-1
ii  libpam0g  1.4.0-10
ii  libpulse0 15.0+dfsg1-2
ii  libuuid1  2.37.2-3
ii  libwayland-client01.19.0-2+b1
ii  libwayland-server01.19.0-2+b1
ii  libxkbcommon0 1.0.3-2

Versions of packages enlightenment recommends:
ii  acpid  1:2.0.32-1
ii  bc 1.07.1-3+b1
ii  bluez  5.61-1
ii  libddcutil30.9.9-2
ii  libevas-loaders1.25.1-1
ii  packagekit 1.2.2-2
ii  terminology [x-terminal-emulator]  1.9.0-2
ii  udisks22.9.4-1

Versions of packages enlightenment suggests:
pn  gdb
pn  x-display-manager  

-- no debconf information

Bug#995636: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)

[Luca Boccassi]

On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote:
> On 2021-10-05 20:03:49 [+0200], Michael Biebl wrote:
> > Hi Kurt, hi Luca, hi everyone,
> Hi Michael,
> 
> > That said, I'm not a lawyer and reading license texts hurts my brain.
> > So my goal is is mainly to raise awareness of this issue and seek input from
> > the community.
> 
> GPL code which linked against OpenSSL usually has a "gpl-exception
> clause for OpenSSL". This should be still accepted since it refers
> specifically to OpenSSL.

Many projects do not have that. Also to be extremely pedantic it needs
to be checked if it just references OpenSSL as a project, or
specifically the OpenSSL license which is a specific and well defined
document: https://spdx.org/licenses/OpenSSL.html AFAIK there's no
"standard" clause, everyone uses their own wording, more or less.

More importantly, as far as I understand and I was told recently these
are not transitive - ie, it's fine for an executable, but if it
concerns a library, it does not "transfer" to external programs linking
to that library.

> Additionally OpenSSL is considered system library, see
>   https://bugs.debian.org/951780
>   https://bugs.debian.org/972181

Even if that interpretation holds, and it's not a universal
interpretation (eg: lawyers from Canonical strongly disagree as far as
I know), again that applies to first-party binaries only as far as I
understand. It's not as clear-cut with libraries used by third parties.

The core issue as always is uncertainty: any time there are doubts and
conflicting interpretations, we all lose, especially our users, and
especially those that are then forced to have awkward conversations
with their corporate lawyers. Which is why it's really unfortunate that
, in order to fix compatibility issues with the GPL, among all the
permissive licenses available out there, the OpenSSL project picked the
_one_ that has serious compatibility questions with the GPL :-(

But of course this doesn't mean we shouldn't move to the new version,
quite the contrary - I'll simply be careful about the projects I am
involved in and what it means for them and their license clarity, and
what I can do to make it better, if anything.

-- 
Kind regards,
Luca Boccassi


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

Bug#995813: ITP: qt6-shadertools -- APIs and tools to provide functionality for the shader pipeline

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-shadertools
  Version : 6.2.0
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : GPL-3
  Programming Lang: C++
  Description : APIs and tools to provide functionality for the shader 
pipeline

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

This module contains APIs and tools in this module provide the producer 
functionality 
for the shader pipeline that allows Qt Quick to operate on Vulkan, Metal, and 
Direct3D, 
in addition to OpenGL. 

Bug#980559: angelscript: FTBFS on arm64: test error

[Fabio Pedretti]

angelscript 2.35.1 was released and has at least 2 arm64 fixes:
https://www.angelcode.com/angelscript/changes.php

Can you try upgrading Debian angelscript package to 2.35.1 and see if
this fixes arm64 build?

Note that angelscript with arm64 build is needed by supertuxkart, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995771

Thanks.

Bug#995257: backintime-qt4: cron alternative

[wim]

Package: backintime-qt4
Version: 1.1.24-0.1
Followup-For: Bug #995257

Hello,

a workaround is use a custom instead:
mountpoint /replace_by_the_moint_point_of_the_external_storage/ && 
/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime --backup-job >> 
/var/log/backintime.log 2>&1

hth,
Wim

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

Kernel: Linux 5.10.0-0.bpo.8-amd64 (SMP w/16 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_BE.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 backintime-qt4 depends on:
ii  backintime-common 1.1.24-0.1
ii  libnotify-bin 0.7.7-4
ii  policykit-1   0.105-25
ii  python3   3.7.3-1
ii  python3-dbus.mainloop.qt  4.12.1+dfsg-2+b1
ii  python3-pyqt4 4.12.1+dfsg-2+b1
ii  x11-utils 7.7+4

Versions of packages backintime-qt4 recommends:
ii  python3-secretstorage  2.3.1-2

Versions of packages backintime-qt4 suggests:
ii  kompare  4:18.08.1-1
ii  meld 3.20.0-2

-- no debconf information

Bug#995815: ruby-eventmachine FTBFS on IPV6-only buildds

[Adrian Bunk]

Source: ruby-eventmachine
Version: 1.3~pre20190820-g10fb0c4-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=ruby-eventmachine&arch=amd64

...
TestResolver:
  test_garbage: F
===
Failure: test_garbage(TestResolver)
/<>/tests/test_resolver.rb:58:in `test_garbage'
 55:   end
 56:
 57:   def test_garbage
  => 58: assert_raises( ArgumentError ) {
 59:   EM.run {
 60: EM::DNS::Resolver.resolve 123
 61:   }

 expected but was
)
...
Finished in 8.026344954 seconds.
---
274 tests, 3490 assertions, 2 failures, 24 errors, 0 pendings, 10 omissions, 0 
notifications
90.1515% passed
---
34.14 tests/s, 434.82 assertions/s
rake aborted!
Command failed with status (1): [ruby -w -I"tests" 
/usr/share/rubygems-integration/all/gems/rake-13.0.3/lib/rake/rake_test_loader.rb
 "tests/jruby/test_jeventmachine.rb" "tests/test_attach.rb" 
"tests/test_basic.rb" "tests/test_channel.rb" "tests/test_completion.rb" 
"tests/test_connection_count.rb" "tests/test_connection_write.rb" 
"tests/test_defer.rb" "tests/test_deferrable.rb" "tests/test_epoll.rb" 
"tests/test_error_handler.rb" "tests/test_exc.rb" "tests/test_file_watch.rb" 
"tests/test_fork.rb" "tests/test_futures.rb" "tests/test_handler_check.rb" 
"tests/test_hc.rb" "tests/test_httpclient.rb" "tests/test_httpclient2.rb" 
"tests/test_inactivity_timeout.rb" "tests/test_io_streamer.rb" 
"tests/test_ipv4.rb" "tests/test_ipv6.rb" "tests/test_iterator.rb" 
"tests/test_kb.rb" "tests/test_keepalive.rb" "tests/test_line_protocol.rb" 
"tests/test_ltp.rb" "tests/test_ltp2.rb" "tests/test_many_fds.rb" 
"tests/test_next_tick.rb" "tests/test_object_protocol.rb" "tests/test_pause.rb" 
"tests/test_pending_connect_timeout.rb" "tests/test_pool.rb" 
"tests/test_process_watch.rb" "tests/test_processes.rb" 
"tests/test_proxy_connection.rb" "tests/test_pure.rb" "tests/test_queue.rb" 
"tests/test_resolver.rb" "tests/test_running.rb" "tests/test_sasl.rb" 
"tests/test_send_file.rb" "tests/test_servers.rb" 
"tests/test_shutdown_hooks.rb" "tests/test_smtpclient.rb" 
"tests/test_smtpserver.rb" "tests/test_sock_opt.rb" "tests/test_spawn.rb" 
"tests/test_ssl_args.rb" "tests/test_ssl_dhparam.rb" 
"tests/test_ssl_ecdh_curve.rb" "tests/test_ssl_extensions.rb" 
"tests/test_ssl_methods.rb" "tests/test_ssl_protocols.rb" 
"tests/test_ssl_verify.rb" "tests/test_stomp.rb" "tests/test_system.rb" 
"tests/test_threaded_resource.rb" "tests/test_tick_loop.rb" 
"tests/test_timers.rb" "tests/test_ud.rb" "tests/test_unbind_reason.rb" -v]
/usr/share/rubygems-integration/all/gems/rake-13.0.3/exe/rake:27:in `'
Tasks: TOP => default
(See full trace by running task with --trace)
ERROR: Test "ruby2.7" failed. Exiting.
dh_auto_install: error: dh_ruby --install 
/<>/ruby-eventmachine-1.3\~pre20201020-b50c135/debian/ruby-eventmachine
 returned exit code 1
make[1]: *** [debian/rules:13: override_dh_auto_install] Error 25

Bug#994392: blender: Color management settings missing

[Andrius Merkys]

Hi Matteo,

On 2021-09-16 00:19, Matteo F. Vescovi wrote:
> On 2021-09-15 at 15:24 (+03), Mikko Rasa wrote:
>> Blender 2.93.4 is missing most options in color management settings.
>> I only have "sRGB" for display device, "Standard" for view transform,
>> "None" for look and "sRGB" and "Linear" for sequencer.
>> A build downloaded from blender.org shows all of the options, so it
>> seems Debian's build is incorrectly configured somehow.
> Digging in the build logs[1] you'll find something like:
> 
> = = = = >8 = = = =
> -- Could NOT find OpenColorIO: Found unsuitable version "1.1.1", but
> -- required is at least "2.0.0"
> -- (found /usr/lib/libOpenColorIO.so;/usr/lib/x86_64-linux-gnu/libexpat.so)
> -- OpenColorIO not found
> = = = = >8 = = = =
> 
> OpenColorIO is still at 1.1.1 in Debian, in fact. And OCIO library is 
> responsible for color management in Blender, as you can see at [2].
> 
> Now, even if I've tried to spend some time on packaging the 2.x.y version
> actually I'm still failing badly due to external requests (that is, more
> libraries or tools not packaged in Debian yet) for the package to build.

Maybe you could share hare the list of missing dependencies? This way
people could help speeding up the fix.

Best,
Andrius

Bug#995793: exim4-base: /tmp partition has noexec mount option; exim4-base fails

[Marc Haber]

On Tue, Oct 05, 2021 at 03:49:58PM -0400, S Egbert wrote:
> Can't exec "/tmp/tzdata.config.jtoGAt": Permission denied at 
> /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178.

This is most obviously not a script that comes from the exim4 package.
Consider talking to the tzdata maintainers instead.

> dpkg (subprocess): unable to execute old tzdata package post-removal script 
> (/var/lib/dpkg/info/tzdata.postrm): Permission denied
> dpkg: warning: old tzdata package post-removal script 
> subprocess returned error exit status 2
> dpkg: trying script from the new package instead ...
> dpkg (subprocess): unable to execute new tzdata package post-removal script 
> (/var/lib/dpkg/tmp.ci/postrm): Permission denied
> dpkg: error processing archive 
> /var/cache/apt/archives/tzdata_2021a-1+deb11u1_all.deb (--unpack):
>  new tzdata package post-removal script subprocess returned error exit status 
> 2

This looks like dpkg is trying to execute maintainer scripts. It
obviously does that inside /var/lib/dpkg/info. This is nothing that
exim4 can do anything about. Consider talking to the dpkg maintainers
instead.

> 7Progress: [ 10%] 
> [#.] 8dpkg 
> (subprocess): unable to execute new exim4-config package pre-installation 
> script (/var/lib/dpkg/tmp.ci/preinst): Permission denied
> dpkg: error processing archive 
> /var/cache/apt/archives/exim4-config_4.94.2-7_all.deb (--unpack):
>  new exim4-config package pre-installation script subprocess returned error 
> exit status 2

Same thing here.

I intend to close this bug report by the end of this week unless
somebody has convinced me that there is anything that the exim4
package can do about.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#982959: ifupdown: regex not workig as expected

[Santiago Ruano Rincón]

El 06/10/21 a las 12:28, Martin-Éric Racine escribió:
> ke 6. lokak. 2021 klo 12.20 Santiago Ruano Rincón
> (santiag...@riseup.net) kirjoitti:
> >
> > El 06/10/21 a las 09:24, Martin-Éric Racine escribió:
> > > la 2. lokak. 2021 klo 11.13 Michael Biebl (bi...@debian.org) kirjoitti:
> > > >
> > > > Am 02.10.21 um 09:05 schrieb Martin-Éric Racine:
> > > > > pe 1. lokak. 2021 klo 23.39 Santiago Ruano Rincón
> > > > > (santiag...@riseup.net) kirjoitti:
> > > > >>
> > > > >> El 01/10/21 a las 17:05, Martin-Éric Racine escribió:
> > > > >>> pe 1. lokak. 2021 klo 16.21 Santiago Ruano Rincón
> > > > >>> (santiag...@riseup.net) kirjoitti:
> > > >  On Wed, 17 Feb 2021 14:32:24 +0200 Martin-Éric_Racine 
> > > >   wrote:
> > > > > Package: ifupdown
> > > > > Version: 0.8.36
> > > > > Severity: normal
> > > > >
> > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > > Hash: SHA256
> > > > >
> > > > > The regex recipe below does not work as expected. I've tried both
> > > > >
> > > > > allow-hotplug /en*=en /wl*=wl
> > > > >
> > > > > and
> > > > >
> > > > > allow-hotplug /en*/=en /wl*/=wl
> > > > >
> > > > > but ifup still doesn't raise whatever interface match the regex. 
> > > > > Have I misunderstood the examples or am I missing something else?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > - -- Package-specific info:
> > > > > - --- /etc/network/interfaces:
> > > > > allow-hotplug /en*=en /wl*=wl
> > > > >
> > > > > iface en inet dhcp
> > > > > iface en inet6 auto
> > > > >  privext 2
> > > > >  #dhcp 1
> > > > >
> > > > > iface wl inet dhcp
> > > > >  wpa-ssid AccessPoint
> > > > >  wpa-psk mypassword
> > > > > iface wl inet6 auto
> > > > >  privext 2
> > > > >  #dhcp 1
> > > > >>>
> > > > >>> [...]
> > > > >>>
> > > >  I get both interfaces configured. Could you please run ifup with 
> > > >  -v?
> > > > >>>
> > > > >>> I just tried. Here's an interesting difference:
> > > > >>>
> > > > >>> If I use 'sudo ifup -a -v' ifup won't find the mapped interfaces.
> > > > >>
> > > > >> ifup doesn't process them since they are not configured with `auto`
> > > > >
> > > > > OK, what processes interfaces with allow-hotplug then, if not 
> > > > > ifupdown?
> > > > >
> > > > >> s/allow-hotplug/auto/ in my /e/n/interfaces makes this work.
> > > > >>>
> > > > >>> If I use 'sudo ifup --allow hotplug -a -v' ifup correctly finds and
> > > > >>> maps the wireless interfaces.
> > > > >>>
> > > > >>
> > > > >> I wonder if there is a problem related with udev instead.
> > > > >
> > > > > Added udev (systemd) maintainers in CC.
> > > >
> > > > If you are referring to
> > > > /lib/udev/ifupdown-hotplug and /lib/udev/rules.d/80-ifupdown.rules,
> > > > those files are maintained by the ifupdown package.
> > > >
> > > > The systemd package is not involved here.
> > >
> > > Michael, I suspected as much. Thanks for confirming this.
> > >
> > > Santiago, all evidences point to ifupdown pattern matching only
> > > working for auto interfaces, but not hotplug interfaces.
> >
> > Not exactly, I think. 'sudo ifup --allow hotplug -a -v' works for you.
> 
> I should not have to type that manually to have ifupdown find and
> raise the interfaces.
> 
> > > Basically,
> > > hotplug works for named interfaces, but not for pattern matched
> > > interfaces.
> >
> > ifupdown-hotplug receives as argument the name of the real
> > interface, so it execs ifup --allow=hotplug $INTERFACE
> > https://salsa.debian.org/debian/ifupdown/-/blob/master/debian/ifupdown-hotplug#L73
> > and it wouldn't find it in your configuration.
> 
> Which is precisely the problem. The mapping fails.
> 
> > Maybe your use case matches better templates and inherits (See INTERFACE
> > TEMPLATES) in interfaces(5).
> 
> It doesn't. Templates rely upon explicitly defining interfaces.

OK, I see.

So the problem is not explicitly related to ifupdown. With the same
config from above, this does not work:

$ sudo ifup eth1
ifup: unknown interface eth1

You expect that ifupdown matches an interface given as argument to the
lists of interfaces in auto, allow-hotplug, etc, even without defining
them, as long as they are known by the kernel.


signature.asc
Description: PGP signature

Bug#995816: ITP: r-cran-mclustcomp -- Measures for Comparing Clusters

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-mclustcomp -- Measures for Comparing Clusters
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-mclustcomp
  Version : 0.3.3
  Upstream Author : Kisung You
* URL : https://cran.r-project.org/package=mclustcomp
* License : GPL-3+
  Programming Lang: GNU R
  Description : Measures for Comparing Clusters
 Given a set of data points, a clustering is defined as a disjoint
 partition where each pair of sets in a partition has no overlapping
 elements. This package provides 25 methods that play a role somewhat
 similar to distance or metric that measures similarity of two
 clusterings - or partitions. For a more detailed description, see Meila,
 M. (2005) .

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-mclustcomp

Bug#679905: RFP: cctbx -- Computational Crystallography Toolbox

[Baptiste Carvello]

Hi,

thanks for caring about Debian packaging efforts! This one is an old
one, it must have been 2012 or 2013, and salsa was called alioth :-)

What I remember was a rather inflexible packaging system, that forced us
to duplicate existing code. And an effort that, well, slowly lost steam.
Then I lost track of it due to real life commitments (my first child was
born 2014).

I also gratefully remember that Luc Bourhis was very helpful from the
upstream side. I wouldn't want to bother him again, though, until we
have something concrete to put on the table.

Best regards,
Baptiste

Le 06/10/2021 à 10:13, Andreas Tille a écrit :
> Hi,
> 
> I've got a hint about cctbx and realised that there is an RFP (degraded
> from ITP) as well as a salsa repository[1].  I took the freedom to
> inject the latest upstream source and updated *parts* of the packaging
> to recent standards.  I have no idea whether this might give some new
> inspiration for those who want to catch up with this package, which is
> interesting for several teams (in CC).  So I simply make some noise for
> anybody who might want to continue from here.
> 
> Kind regards
> 
>   Andreas.
> 
> [1] https://salsa.debian.org/science-team/cctbx
> 

Bug#679905: RFP: cctbx -- Computational Crystallography Toolbox

[Ray]

Hi all,

Are they still using the SCons system to build it? It was a real
hassle in the past. IIRC there were some issues remaining regarding the
packaging and I have tried discussions with Upstream to resolve it back
then. Unfortunately it did not lead anywhere.

I have heard that the lack of documentation was resolved recently upstream
so maybe the whole building situation improved as well.

Regards
R

Am Mi, 06. Okt 10:13 schrieb Andreas Tille:
> Hi,
> 
> I've got a hint about cctbx and realised that there is an RFP (degraded
> from ITP) as well as a salsa repository[1].  I took the freedom to
> inject the latest upstream source and updated *parts* of the packaging
> to recent standards.  I have no idea whether this might give some new
> inspiration for those who want to catch up with this package, which is
> interesting for several teams (in CC).  So I simply make some noise for
> anybody who might want to continue from here.
> 
> Kind regards
> 
>   Andreas.
> 
> [1] https://salsa.debian.org/science-team/cctbx
> 
> -- 
> http://fam-tille.de

-- 

Bug#986013: asterisk: codec_amr not built

[Athos Ribeiro]

Package: asterisk
Version: 1:16.16.1~dfsg-2
Followup-For: Bug #986013
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

Here is a patch to enable and test the AMR codec. The changes include:

  * Build-Depend on libvo-amrwbenc-dev for AMR codec support (LP: #1845765)
  * d/t/amr: Test if AMR codec support is available

Thanks for considering the patch.

*** /tmp/tmpqgrbz6u6/asterisk_1:16.16.1~dfsg-2ubuntu1.debdiff
diff -Nru asterisk-16.16.1~dfsg/debian/control 
asterisk-16.16.1~dfsg/debian/control
--- asterisk-16.16.1~dfsg/debian/control2021-08-06 10:35:20.0 
-0300
+++ asterisk-16.16.1~dfsg/debian/control2021-09-29 16:02:29.0 
-0300
@@ -61,6 +61,7 @@
  libtonezone-dev [linux-any],
  libunbound-dev,
  liburiparser-dev,
+ libvo-amrwbenc-dev,
  libvorbis-dev,
  libvpb-dev [linux-any],
  libxml2-dev,
diff -Nru asterisk-16.16.1~dfsg/debian/tests/amr 
asterisk-16.16.1~dfsg/debian/tests/amr
--- asterisk-16.16.1~dfsg/debian/tests/amr  1969-12-31 21:00:00.0 
-0300
+++ asterisk-16.16.1~dfsg/debian/tests/amr  2021-09-29 16:02:29.0 
-0300
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+# Veryfy amr support is enabled as per
+# https://www.mail-archive.com/asterisk-dev@lists.digium.com/msg45213.html
+# by verifying if the amr codecs are listed and by checking if amr transcoding
+# is available
+
+asterisk -x 'core show codecs audio' | grep -E '\bamr\b'
+asterisk -x 'core show codecs audio' | grep -E '\bamrwb\b'
+
+asterisk -x 'core show translation' | grep -E '\bamr\b'
+asterisk -x 'core show translation' | grep -E '\bamrwb\b'
diff -Nru asterisk-16.16.1~dfsg/debian/tests/control 
asterisk-16.16.1~dfsg/debian/tests/control
--- asterisk-16.16.1~dfsg/debian/tests/control  2021-08-06 10:35:20.0 
-0300
+++ asterisk-16.16.1~dfsg/debian/tests/control  2021-09-29 16:02:29.0 
-0300
@@ -1,3 +1,7 @@
 Tests: asttestmods
 Restrictions: needs-root, isolation-container
 Depends: asterisk, asterisk-voicemail, asterisk-tests, 
asterisk-core-sounds-en-gsm, libxml2-utils
+
+Tests: amr
+Restrictions: needs-root
+Depends: asterisk, asterisk-modules, grep


-- System Information:
Debian Release: 11.0
  APT prefers impish
  APT policy: (500, 'impish')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-16-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Athos Ribeiro

Bug#995817: ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger

[Salvatore Bonaccorso]

Package: bpftrace
Version: 0.13.0-1
Severity: important
X-Debbugs-Cc: car...@debian.org

Hi Vincent,

After updating bpftrace to 0.13.0-1 in unstable, I noticed invocation
using a BEGIN block do not work anymore, the BEGIN_trigger symbol
cannot be resolved, basically reproducible with the minimal:

# bpftrace -e 'BEGIN { }'
Attaching 1 probe...
ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger

Samewise for the END_trigger.

Not further checked on the issue.

p.s.: please downgrade if you think important is not appropriate.

Regards,
Salvatore

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

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

Versions of packages bpftrace depends on:
ii  libbpf0   1:0.5.0-1
ii  libbpfcc  0.21.0+ds-7
ii  libc6 2.32-4
ii  libclang1-11  1:11.1.0-4
ii  libgcc-s1 11.2.0-8
ii  libllvm11 1:11.1.0-4
ii  libstdc++611.2.0-8

bpftrace recommends no packages.

bpftrace suggests no packages.

-- no debconf information

Bug#995448: apt-listbugs: fails to connect to the BTS - certificate expired

[Antonio Terceiro]

Control: reassign -1 ruby-httpclient
Control: retitle -1 ruby-httpclient: uses stale copy of CA certificates
Control: severity -1 serious
Control: forwarded -1 https://github.com/nahi/httpclient/issues/445

On Tue, Oct 05, 2021 at 06:45:39PM +0200, Francesco Poli wrote:
> On Tue, 05 Oct 2021 11:55:25 +0200 Diederik de Haas wrote:
> 
> [...]
> > I ran 
> > 'reportbug apt-listbugs' and so I found this bug. It also shows 995432.
> > (I usually use the web interface to see whether 'my' issue has already been 
> > found, but it doesn't show up there)
> 
> For the record, this bug report is not currently assigned to
> apt-listbugs, it only affects apt-listbugs.
> 
> That's why it does not show up on
> 
> 
> However, it shows up on
> 

This is caused by ruby-httpclient having a stale copy of CA
certificates:

https://github.com/nahi/httpclient/issues/445

I have confirmed this locally, and have a fix I will get out soon.


signature.asc
Description: PGP signature

Bug#995722: [Pkg-javascript-devel] Bug#995722: Bug#995722: Bug#995722: loash: Vendoring should be removed

[Yadd]

Le 06/10/2021 à 12:17, Yadd a écrit :
> Le 06/10/2021 à 12:16, Jonas Smedegaard a écrit :
>> Quoting Yadd (2021-10-06 11:43:40)
>>> On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
 Source: src:node-lodash
 Version: 4.17.21+dfsg+~cs8.31.173-1
 Severity: serious
 Justification: do not compile from source

 Dear Maintainer,

 The vendor directory should be emptied

 The debug version is compiled without source (lintian warn) and moreover 
 the
 rest of file are already packaged

 grep -R vendor * gives only a few hit that could be cured by symlinking

 Bastien
>>> Hi,
>>>
>>> this files are used for test only, maybe severity could be decreased.
>>
>> I find the severity accurate: Relying on non-source code is a severe 
>> violation of Debian Policy, not matter the purpose of relying on it.
>>
>>
>>  - Jonas
> 
> So let's remove test...

Sadly (Hopefully) test aren't enabled in node-lodash...

Bug#995819: ITP: xrstools -- x-ray Raman scattering tools

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams 
X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org

* Package name: xrstools
  Version : 0.15.0+git20210910+c147919d-1
  Upstream Author : European Synchrotron Radiation Facility
* URL : https://gitlab.esrf.fr/ixstools/xrstools/-/tree/mac
* License : MIT
  Programming Lang: Python
  Description : x-ray Raman scattering tools

 Collection of tools and Python3 modules to extract and analyze
 x-ray Raman scattering (XRS) data from ID20 of the
 European Synchrotron Radiation Facility

This package is to be maintained with the Debian Science Team.

Bug#992286: Patch to migrate to exfatprogs

[Sven Hoexter]

tags 992286 patch
thanks

Hi,
I've created a PR to migrate to exfatprogs now. I would really like to get rid
of at least exfat-utils soon.

https://salsa.debian.org/libvirt-team/libguestfs/-/merge_requests/1

Joseph, since I would like to remove exfat-fuse and exfat-utils from Debian
I see no point in making them an alternative. If someone needs it for a backport
he should add it only for the backport. But opinions might differ on that one.

Cheers,
Sven
diff --git a/debian/changelog b/debian/changelog
index ad8d629a2..571706100 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+libguestfs (1:1.44.1-6) UNRELEASED; urgency=medium
+
+  * Migrate from exfat-utils and exfat-fuse to exfatprogs.
+Since bullseye we have in kernel support for exFAT, no need to rely
+on the fuse implementation anymore.
+
+ -- Sven Höxter   Wed, 06 Oct 2021 14:47:03 +0200
+
 libguestfs (1:1.44.1-5) unstable; urgency=medium
 
   * Attempt to fix running tests
diff --git a/debian/check-appliance-build-deps.sh b/debian/check-appliance-build-deps.sh
index ee5a9d84d..44a0f058b 100755
--- a/debian/check-appliance-build-deps.sh
+++ b/debian/check-appliance-build-deps.sh
@@ -13,7 +13,7 @@ m4 -DDEBIAN=1 -DEXTRA_PACKAGES= appliance/packagelist.in \
 | tr ' ' '\n' \
 | sed -e '/^$/d' \
   -e '/^\(bash\|coreutils\|dash\|diffutils\|findutils\|grep\|gzip\|libc-bin\|sed\|tar\|util-linux\)$/d' \
-  -e '/\(btrfs-tools\|fuse-exfat\|gfs2*-tools\|iproute\|module-init-tools\|procps-ng\)$/d' \
+  -e '/\(btrfs-tools\|exfat-fuse\|exfat-utils\|fuse-exfat\|gfs2*-tools\|iproute\|module-init-tools\|procps-ng\)$/d' \
 | grep -v ^lib \
 | grep -v ufsutils \
 | sort -u \
diff --git a/debian/control b/debian/control
index 9c1c827d4..2e8f9dbfc 100644
--- a/debian/control
+++ b/debian/control
@@ -63,7 +63,7 @@ Build-Depends: debhelper (>= 12),
   curl,
   debootstrap,
   dosfstools,
-  exfat-fuse, exfat-utils,
+  exfatprogs,
   extlinux [i386 amd64],
   f2fs-tools,
   fdisk,

Bug#995820: wolfssl: Import new upstream version

[Bastian Germann]

Source: wolfssl
Version: 4.6.0-3

Version 4.8.1 is available for some time now. Please upload the new version.

Bug#995821: ITP: libthumbnailator-java -- thumbnail generation library for Java

[Markus Koschany]

Package: wnpp
Severity: wishlist
Owner: Markus Koschany 
X-Debbugs-Cc: debian-de...@lists.debian.org, a...@debian.org

* Package name: libthumbnailator-java
  Version : 0.4.14
  Upstream Author : Chris Kroells
* URL : https://github.com/coobird/thumbnailator
* License : Expat
  Programming Lang: Java
  Description : thumbnail generation library for Java

Thumbnailator simplifies the task of making thumbnails into a single method
call.
 .
  * Create high-quality thumbnails from existing images.
  * Option to embed a watermark (such as a logo) in the thumbnails.
  * Transparency of the watermark is adjustable from transparent (0%) to opaque
(100%).
  * Supports rotation of thumbnail.
  * Preserves the aspect ratio of resulting thumbnail, if desired.

Thumbnailator is a new build-dependency of libsejda-java.

Bug#995267: Re: Bug#995267: devhelp doesn't load the selected content

[Evangelos Ribeiro Tzaras]

Hi,

On Sat, 02 Oct 2021 23:46:10 +0300 =?UTF-8?B?UmluYXQgSWJyYWdpbW92?=
 wrote:
> Looks like it's sufficient to remove
~/.local/share/mime/application/x-extension-html.xml
> and then to regenerate database:
> 
> update-mime-database ~/.local/share/mime
> 

On my system I still had some 'user-extension-*htm*.xml' files in
~/.local/share/mime/packages and updating the database would regenerate
the files under ~/.local/share/mime/applications.

After removing *those* as well and regenerating the database it started
working again.


-- 
Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19





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

Bug#995823: bullseye-pu: package kodi/2:19.2+dfsg1-1~deb11u1 (pre-upload unblock bug)

[Vasyl Gello]

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

Please unblock package kodi

[ Reason ]

This is a second point release of Kodi 19 "Matrix".

It consists of 69 commits, closing 40 upstream bugs.

Most notable bugs fixed include 8 PVR issues, that led to Kodi crashes
under certain circumstances, and 4 fixes for Kodi's default skin, Estuary.

Another must-have bugfix for users controlling their Kodi set-ups remotely
is the proper handling of partial websocket messages.

Debian packaging changes requested by users include the patch adding metainfo
file to /usr/share/metainfo, needed by GNOME 40 integration.

Apart from that, translations of i10n were updated to fix users' complaints. 
These changes produce a lot of changes in .po files, so I filtered the debdiff
as follows to get rid of noise not related to code:

filterdiff kodi_19.1+dfsg2-2_19.2+dfsg1-1.debdiff \
-x "*/addons/*.xml" \
-x "*/addons/*.po" \
-x "*/cmake/scripts/windows/*" \
-x "*/docs/*" \
-x "*/Changelog" \
-x "*/Makefile.in" \
-x "*/*.m4" \
-x "*/configure" \
-x "*/msvc/*" \
-x "*/media/*" \
-x "*/system/*" \
-x "*/tools/buildsteps/windows/*" \
-x "*/xbmc/cores/VideoPlayer/VideoRenderers/windows/*" \
-x "*/xbmc/windowing/win10/*" \
-x "*/xbmc/windowing/windows/*" \
1>kodi_19.1+dfsg2-2_19.2+dfsg1-1.filterdiff

[ Impact ]

Users receive fixes for problems reported upstream

[ Tests ]

Automated tests + manual testing by Kodi users

[ Risks ]

The struct release policy of upstream ensures no breaking
changes are allowed past BETA releases. Point releases
bring only bugfixes and security fixes, so risk is low.

Furthermore, I have become the official member of Team Kodi!
That should contribute in the mitigation of risks :)

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Changes ]

Here is the outline of changes merged in 19.2:

https://github.com/xbmc/xbmc/pull/20224 ('Bump to 19.2. final'): 1 commit(s)
- "Bump to 19.2. final"
https://github.com/xbmc/xbmc/pull/20189 ('[CGUIDialogVolumeBar] Fix dialog not 
updating values if smartredraw i…'): 1 commit(s)
- "[CGUIDialogVolumeBar] Fix dialog not updating values if smartredraw is 
enabled"
https://github.com/xbmc/xbmc/pull/20185 ('[Backport] Sync game controllers for 
language updates'): 1 commit(s)
- "Sync game controllers for language updates"
https://github.com/xbmc/xbmc/pull/20178 ('[Matrix] PVR: fix "Delete 
permanently" of recordings from trash'): 1 commit(s)
- "PVR: fix "Delete permanently" of recordings from trash"
https://github.com/xbmc/xbmc/pull/20161 ('[Backport][linux] Use posix_memalign 
to implement AlignedMalloc'): 1 commit(s)
- "[linux] Use posix_memalign to implement AlignedMalloc"
https://github.com/xbmc/xbmc/pull/20140 ('[Backport] Websocket: handle partial 
messages'): 1 commit(s)
- "Websocket: handle partial messages"
https://github.com/xbmc/xbmc/pull/20119 ('[Matrix][PVR] Search missing channel 
icons job must be executed by PVR manage…'): 1 commit(s)
- "[PVR] Search missing channel icons job must be executed by PVR manager 
thread to avoid races in complex restart scenarios."
https://github.com/xbmc/xbmc/pull/20116 ('[Matrix][Estuary] PVR Guide window: 
Truncated channel names should scroll whe…'): 1 commit(s)
- "[Estuary] PVR Guide window: Truncated channel names should scroll when 
focused."
https://github.com/xbmc/xbmc/pull/20115 ('[Matrix][Estuary] PVR channel guide 
dialog changes.'): 1 commit(s)
- "[Estuary] PVR channel guide dialog changes."
https://github.com/xbmc/xbmc/pull/20114 ('[Matrix][Estuary] Default PVR radio 
channel icon should have transparent background'): 1 commit(s)
- "[Estuary] Default PVR radio channel icon should have transparent background."
https://github.com/xbmc/xbmc/pull/20092 ('[Matrix][PVR] Fix and simplify addon 
connection state change handling.'): 1 commit(s)
- "[PVR] Fix and simplify addon connection state change handling."
https://github.com/xbmc/xbmc/pull/20060 ('[addons] sync 
service.xbmc.versioncheck with repo'): 1 commit(s)
- "[addons] sync service.xbmc.versioncheck with repo"
https://github.com/xbmc/xbmc/pull/20053 ('[Music] Fix grouping discs by 
subtitle if first disc has one'): 1 commit(s)
- "[MUSIC] Ensure grouping discs by title if subtitles present"
https://github.com/xbmc/xbmc/pull/20051 ('[bp][addons] Update default and SNES 
controller addons'): 1 commit(s)
- "[addons] Update default and SNES controller addons"
https://github.com/xbmc/xbmc/pull/20047 ('[bp][addons] fix display logic for 
official/3rd party modules'): 3 commit(s)
- "[addons] fix display logic for official/3rd party modules"
- "[cleanup] remove advanced settings 'showalldependencies' (obsolete)"
- "[addons] move sort out of for-loop that fills t

Bug#995824: New version available (1.5.6)

[chrysn]

Source: ruby-kramdown-rfc2629
Severity: wishlist
File: /usr/bin/kramdown-rfc2629

The latest available version (1.5.6) is necessary for many recent
drafts, please consider updating the packages.

(I can't pinpoint the exact changes of what breaks where, as there is
some interdependency with xml2rfc too, but it's probably a smooth
upgrade).

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

Kernel: Linux 5.13.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#995823: bullseye-pu: package kodi/2:19.2+dfsg1-1~deb11u1 (pre-upload unblock bug)

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2021-10-06 at 13:39 +, Vasyl Gello wrote:
> Please unblock package kodi
> 

That's not what you mean if the subject is accurate. But see below.

> [ Reason ]
> 
> This is a second point release of Kodi 19 "Matrix".
> 
[...]
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing

That's the checklist for an unblock request, i.e. for migrating a
package from unstable to testing, not an update to stable, which is a
p-u bug. Which are you actually requesting? The metadata is for one
sort of request while the content is for another.

If you're actually asking about an update to stable then the checklist
is:

[ Checklist ]
  [ ] *all* changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in stable
  [ ] the issue is verified as fixed in unstable

This clearly isn't a changelog entry for a stable update:

+kodi (2:19.2+dfsg1-1) unstable; urgency=medium
+
+  * New upstream version 19.2+dfsg1
+  * Restrict watchfile to current Debian stable codename
+  * Bump standard version
+  * Refresh patches
+  * Install package metainfo
+
+ -- Vasyl Gello   Wed, 06 Oct 2021 10:59:56 +
+

2:19.2 also isn't even in unstable yet, which adds to my confusion.

[...]
> [ Other info ]
> 
> unblock kodi/2:19.2+dfsg1-1~deb11u1

Unblock hints (and indeed, hints in general) are for testing. They have
nothing to do with updates to (old)stable.

If you're actually talking about an upload to unstable, then as we're
outside of freeze and this upload wouldn't cause a transition so far as
I can see, then you don't need to request the Release Team's permission
to upload.

Regards,

Adam

Bug#995814: socket /run/pcscd/pcscd.comm immediately removed upon start

[Ludovic Rousseau]

Le 06/10/2021 à 13:50, Philipp Marek a écrit :

Package: pcscd
Version: 1.9.4-1
Severity: normal
X-Debbugs-Cc: phil...@marek.priv.at

I noticed that 1.9.4-1 removes the /run/pcscd/pcscd.comm socket after
starting up; at least, after a "systemctl restart" I can see pcscd
having that socket open (via "lsof"), but it doesn't exist in the
filesystem - and so client services (like "p11tool --list-tokens")
don't see any hardware tokens.


I can reproduce the problem if I use "sudo systemctl restart pcscd".
You should NOT do that.

If you really need to restart pcscd you should do something like:
$ systemctl stop pcscd.service
$ systemctl stop pcscd.socket
$ systemctl start pcscd.socket

See 
https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html

Why do you want to restart pcscd?

Bye

--
Dr. Ludovic Rousseau

Bug#741537: pssh: IPv6 host address processing broken

[Ivan Vilata i Balaguer]

Hello Hilmar, I tested the 2.3.4 packages and yes, the bug still seems to be
there. `:(`

Thanks for the heads up!


Hilmar Preuße (2021-09-17 00:11:32 +0200) wrote:

> Am 13.03.2014 um 16:37 teilte Ivan Vilata i Balaguer mit:
> 
> Hi,
> 
> > The handling of IPv6 addresses is broken since the
> > ``parse_host_entry()`` function in ``psshutil.py`` thinks the colons
> > in it are an indication for a port and the last component is taken
> > apart.  Enclosing the address in brackets doesn't work either because
> > the host name resolution includes the brackets around the IP
> > address.
> > 
> I'm pretty sure the issue is still in 2.3.4 available I'm currently
> packaging for Debian unstable. Are you nevertheless willing to test that
> version, in case it has been solved in the meantime?
> 
> https://freeshell.de/hille42/pssh_2.3.4/
> 
> Hilmar

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

Bug#995823: bullseye-pu: package kodi/2:19.2+dfsg1-1~deb11u1 (pre-upload unblock bug)

[Vasyl Gello]

Hi Adam!

Sorry for confusion!

I have prepared the release which will first go into unstable (and after 
several days, to testing).

I also want this release in stable, because it is a bugfix point release fixing 
a lot of user reports.
So I decided to file the pre-unblock bug for stable upload just like I did at 
freeze time.

I want to be sure the Stable Release Managers accept it.

The version in stable will be kodi/2:19.2+dfsg1-1~deb11u1 as Mattia suggested, 
but it will differ
from kodi/2:19.2+dfsg1-1 targeting unstable only by an entry in d/changelog.

Hope I was clear this time! :)

Cheers!
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#995823: bullseye-pu: package kodi/2:19.2+dfsg1-1~deb11u1 (pre-upload unblock bug)

[Vasyl Gello]

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

[ Reason ]

This is a second point release of Kodi 19 "Matrix".

It consists of 69 commits, closing 40 upstream bugs.

Most notable bugs fixed include 8 PVR issues, that led to Kodi crashes
under certain circumstances, and 4 fixes for Kodi's default skin, Estuary.

Another must-have bugfix for users controlling their Kodi set-ups remotely
is the proper handling of partial websocket messages.

Debian packaging changes requested by users include the patch adding metainfo
file to /usr/share/metainfo, needed by GNOME 40 integration.

Apart from that, translations of i10n were updated to fix users' complaints. 
These changes produce a lot of changes in .po files, so I filtered the debdiff
as follows to get rid of noise not related to code:

filterdiff kodi_19.1+dfsg2-2_19.2+dfsg1-1.debdiff \
-x "*/addons/*.xml" \
-x "*/addons/*.po" \
-x "*/cmake/scripts/windows/*" \
-x "*/docs/*" \
-x "*/Changelog" \
-x "*/Makefile.in" \
-x "*/*.m4" \
-x "*/configure" \
-x "*/msvc/*" \
-x "*/media/*" \
-x "*/system/*" \
-x "*/tools/buildsteps/windows/*" \
-x "*/xbmc/cores/VideoPlayer/VideoRenderers/windows/*" \
-x "*/xbmc/windowing/win10/*" \
-x "*/xbmc/windowing/windows/*" \
1>kodi_19.1+dfsg2-2_19.2+dfsg1-1.filterdiff

[ Impact ]

Users receive fixes for problems reported upstream

[ Tests ]

Automated tests + manual testing by Kodi users

[ Risks ]

The struct release policy of upstream ensures no breaking
changes are allowed past BETA releases. Point releases
bring only bugfixes and security fixes, so risk is low.

Furthermore, I have become the official member of Team Kodi!
That should contribute in the mitigation of risks :)

[ Checklist ]

[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable

[ Changes ]

Here is the outline of changes merged in 19.2:

https://github.com/xbmc/xbmc/pull/20224 ('Bump to 19.2. final'): 1 commit(s)
- "Bump to 19.2. final"
https://github.com/xbmc/xbmc/pull/20189 ('[CGUIDialogVolumeBar] Fix dialog not 
updating values if smartredraw i…'): 1 commit(s)
- "[CGUIDialogVolumeBar] Fix dialog not updating values if smartredraw is 
enabled"
https://github.com/xbmc/xbmc/pull/20185 ('[Backport] Sync game controllers for 
language updates'): 1 commit(s)
- "Sync game controllers for language updates"
https://github.com/xbmc/xbmc/pull/20178 ('[Matrix] PVR: fix "Delete 
permanently" of recordings from trash'): 1 commit(s)
- "PVR: fix "Delete permanently" of recordings from trash"
https://github.com/xbmc/xbmc/pull/20161 ('[Backport][linux] Use posix_memalign 
to implement AlignedMalloc'): 1 commit(s)
- "[linux] Use posix_memalign to implement AlignedMalloc"
https://github.com/xbmc/xbmc/pull/20140 ('[Backport] Websocket: handle partial 
messages'): 1 commit(s)
- "Websocket: handle partial messages"
https://github.com/xbmc/xbmc/pull/20119 ('[Matrix][PVR] Search missing channel 
icons job must be executed by PVR manage…'): 1 commit(s)
- "[PVR] Search missing channel icons job must be executed by PVR manager 
thread to avoid races in complex restart scenarios."
https://github.com/xbmc/xbmc/pull/20116 ('[Matrix][Estuary] PVR Guide window: 
Truncated channel names should scroll whe…'): 1 commit(s)
- "[Estuary] PVR Guide window: Truncated channel names should scroll when 
focused."
https://github.com/xbmc/xbmc/pull/20115 ('[Matrix][Estuary] PVR channel guide 
dialog changes.'): 1 commit(s)
- "[Estuary] PVR channel guide dialog changes."
https://github.com/xbmc/xbmc/pull/20114 ('[Matrix][Estuary] Default PVR radio 
channel icon should have transparent background'): 1 commit(s)
- "[Estuary] Default PVR radio channel icon should have transparent background."
https://github.com/xbmc/xbmc/pull/20092 ('[Matrix][PVR] Fix and simplify addon 
connection state change handling.'): 1 commit(s)
- "[PVR] Fix and simplify addon connection state change handling."
https://github.com/xbmc/xbmc/pull/20060 ('[addons] sync 
service.xbmc.versioncheck with repo'): 1 commit(s)
- "[addons] sync service.xbmc.versioncheck with repo"
https://github.com/xbmc/xbmc/pull/20053 ('[Music] Fix grouping discs by 
subtitle if first disc has one'): 1 commit(s)
- "[MUSIC] Ensure grouping discs by title if subtitles present"
https://github.com/xbmc/xbmc/pull/20051 ('[bp][addons] Update default and SNES 
controller addons'): 1 commit(s)
- "[addons] Update default and SNES controller addons"
https://github.com/xbmc/xbmc/pull/20047 ('[bp][addons] fix display logic for 
official/3rd party modules'): 3 commit(s)
- "[addons] fix display logic for official/3rd party modules"
- "[cleanup] remove advanced settings 'showalldependencies' (obsolete)"
- "[addons] move sort out of for-loop that fills the vector to be sorted"
https://github.com/xbmc/xbmc/pull/20037 ('change explanation string for cddb'): 
1 co

Bug#986027: firefox: WebExtensions process sometimes consumes 100% CPU indefinitely on Firefox 87

[Christoph Anton Mitterer]

Hey Mike.

Would it be possible to cherry pick the upstream candidate for fix...
maybe at least for some version in experimental?

This issue really seems like a showstopper for everyone using addons.


Cheers,
Chris

Bug#974186: /usr/bin/gnome-software: gnome-software uses way too much memory

[Stephen Kitt]

On Wed, Nov 11, 2020 at 04:12:30PM +1100, Timothy Allen wrote:
> I have a low-end laptop with 2GB of RAM, and I usually run GNOME 3 because 
> it's
> highly polished and light-weight enough that I can still run a browser and a
> few terminals to get work done. The one exception is gnome-software, which
> frequently claims 15% or more of my RAM whenever it checks for updates. Right
> now, it's sitting at ~18%, or 335MB resident — that may not be much on other
> computers, but for my little laptop it's often enough to get my browser OOM-
> killed while I'm in the middle of something.

This might be related to
https://sourceware.org/bugzilla/show_bug.cgi?id=14827 — connecting gdb
to an offending gnome-software process and calling malloc_trim(0)
releases a lot of memory; I went from

steve2801906  0.1  3.4 2924988 1136840 ? Sl   Oct02   6:32 
/usr/bin/gnome-software --gapplication-service

to

steve2801906  0.1  0.6 2908452 219416 ?  Sl   Oct02   6:32 
/usr/bin/gnome-software --gapplication-service

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#995826: mozjs78: Please disable Atomics/*/bigint tests on powerpc

[John Paul Adrian Glaubitz]

Source: mozjs78
Version: 78.4.0-2
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hello!

The Atomic/*/bigint fails on powerpc causing the package to FTBFS. Since it's
not sure whether we actually need 128-bit(?) integers for mozjs, I suggest
we just disable these tests.

Those would be:

test262/built-ins/Atomics/and/bigint/good-views.js
test262/built-ins/Atomics/compareExchange/bigint/good-views.js
test262/built-ins/Atomics/wait/bigint/false-for-timeout-agent.js
test262/built-ins/Atomics/wait/bigint/no-spurious-wakeup-on-add.js
test262/built-ins/Atomics/wait/bigint/no-spurious-wakeup-on-xor.js
test262/built-ins/Atomics/wait/bigint/no-spurious-wakeup-no-operation.js
test262/built-ins/Atomics/wait/bigint/no-spurious-wakeup-on-compareExchange.js
test262/built-ins/Atomics/wait/bigint/no-spurious-wakeup-on-exchange.js
test262/built-ins/Atomics/wait/bigint/was-woken-before-timeout.js
test262/built-ins/Atomics/wait/bigint/nan-for-timeout.js
test262/built-ins/Atomics/wait/bigint/value-not-equal.js
test262/built-ins/Atomics/wait/bigint/negative-timeout-agent.js
test262/built-ins/Atomics/wait/bigint/waiterlist-block-indexedposition-wake.js
test262/built-ins/Atomics/wait/bigint/no-spurious-wakeup-on-or.js
test262/built-ins/Atomics/wait/bigint/no-spurious-wakeup-on-and.js
test262/built-ins/Atomics/wait/bigint/waiterlist-order-of-operations-is-fifo.js
test262/built-ins/Atomics/wait/bigint/no-spurious-wakeup-on-sub.js
test262/built-ins/Atomics/wait/bigint/no-spurious-wakeup-on-store.js
test262/built-ins/Atomics/load/bigint/good-views.js
test262/built-ins/Atomics/store/bigint/good-views.js
test262/built-ins/Atomics/exchange/bigint/good-views.js
test262/built-ins/Atomics/add/bigint/good-views.js
test262/built-ins/Atomics/or/bigint/good-views.js
test262/built-ins/Atomics/xor/bigint/good-views.js
test262/built-ins/Atomics/sub/bigint/good-views.js
test262/built-ins/Atomics/notify/bigint/notify-all-on-loc.js

I have not managed to disable the tests myself. I added them to EXCLUDES in
debian/rules, but the tests were run anyway. I haven't really understood
how the test.sh script works, especially since the basic/bug653153.js test
is not run on i386 despite not being passed with "--exclude" to the test
script.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=mozjs78&arch=i386&ver=78.13.0-1&stamp=1630158790&raw=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995827: llvm-toolchain-13: FTBFS on armel, mipsel, mips64el: undefined references to __atomic_foo symbols

[Simon McVittie]

Source: llvm-toolchain-13
Version: 1:13.0.0-2
Severity: important
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org, 
debian-...@lists.debian.org

llvm-toolchain-13 has always failed to build on armel, mipsel, mips64el.
This makes mesa BD-Uninstallable on those release architectures since
its move to llvm-toolchain-13.

On armel:
> FAILED: bin/llvm-profdata 
> : && /<>/build-llvm/./bin/clang++ -fPIC 
> -Wno-unused-command-line-argument -Wno-unknown-warning-option -fPIC 
> -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time 
> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
> -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
> -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type 
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override 
> -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color 
> -ffunction-sections -fdata-sections -O2 -DNDEBUG -g1 -marm -Wl,-z,relro
> -Wl,-rpath-link,/<>/build-llvm/tools/clang/stage2-bins/./lib  
> -Wl,-O3 -Wl,--gc-sections 
> tools/llvm-profdata/CMakeFiles/llvm-profdata.dir/llvm-profdata.cpp.o -o 
> bin/llvm-profdata  -Wl,-rpath,"\$ORIGIN/../lib"  lib/libLLVM-13.so.1  
> -lpthread && :
> /usr/bin/arm-linux-gnueabi-ld: 
> tools/llvm-profdata/CMakeFiles/llvm-profdata.dir/llvm-profdata.cpp.o: 
> undefined reference to symbol '__atomic_fetch_add_4@@LIBATOMIC_1.0'
> /usr/bin/arm-linux-gnueabi-ld: /usr/lib/arm-linux-gnueabi/libatomic.so.1: 
> error adding symbols: DSO missing from command line

On mips*el, the failure is in a different place, but might have the same
root cause (or not, clone this bug if necessary):
> FAILED: lib/clang/13.0.0/lib/linux/libclang_rt.scudo_standalone-mipsel.so 
> : && /usr/bin/g++-10 -fPIC -fPIC -Wno-unused-command-line-argument 
> -Wno-unknown-warning-option -fPIC -fno-semantic-interposition 
> -fno-shrink-wrap -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra 
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wno-missing-field-initializers -pedantic -Wno-long-long 
> -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess 
> -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type 
> -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment 
> -Wmisleading-indentation -fdiagnostics-color -ffunction-sections 
> -fdata-sections -Wall -std=c++14 -Wno-unused-parameter -O2 -DNDEBUG -g1  
> -fPIC -Wno-unused-command-line-argument -Wno-unknown-warning-option 
> -Wl,--build-id -Wl,-z,defs -Wl,-z,nodelete   -mips32r2 -mabi=32 
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-z,defs,-z,now,-z,relro 
> -ffunction-sections -fdata-sections -Wl,--gc-sections -pthread 
> -Wl,-rpath-link,/<>/build-llvm/./lib -shared 
> -Wl,-soname,libclang_rt.scudo_standalone-mipsel.so -o 
> lib/clang/13.0.0/lib/linux/libclang_rt.scudo_standalone-mipsel.so 
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/checksum.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/common.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/crc32_hw.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/flags_parser.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/flags.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/fuchsia.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/linux.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/release.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/report.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/string_utils.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_cpp.cpp.o
>   -Wl,-rpath,"\$ORIGIN/../lib" && :
> /usr/bin/ld: 
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o:
>  in function `scudo::atomic_u64::Type 
> scudo::atomic_load(scudo::atomic_u64 const volatile*, 
> scudo::memory_order)':
> /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
> undefined reference to `__atomic_load_8'
> /usr/bin/ld: 
> /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
> undefined reference to `__atomic_load_8'

smcv

Bug#995448: marked as pending in ruby-httpclient

[Diederik de Haas]

On Wed, 06 Oct 2021 14:14:28 + Antonio Terceiro  
wrote:
> 
> Add patch to use the system certificate store
> 
> Closes: #995448
> 

You can add another Closes, namely #911259 with title:
ruby-httpclient: Please use the system ca-certificates instead of bundling one

Cheers and thanks,
  Diederik

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

Bug#995636: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)

[Paul Wise]

On Wed, Oct 6, 2021 at 11:30 AM Luca Boccassi wrote:
> On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote:
> > Additionally OpenSSL is considered system library, see
> >   https://bugs.debian.org/951780
> >   https://bugs.debian.org/972181
>
> Even if that interpretation holds, and it's not a universal
> interpretation (eg: lawyers from Canonical strongly disagree as far as
> I know), again that applies to first-party binaries only as far as I
> understand. It's not as clear-cut with libraries used by third parties.

As I understand it, it is meant only for binaries distributed by
parties other than the one distributing the system containing the
"system library". So third-party app distributors are fine to ignore
the incompatibility between a GPL app and a proprietary libc, but the
OS vendor can't include GPL apps linked to that proprietary libc
within their system.

https://lists.debian.org/debian-devel/2020/10/msg00168.html

> The core issue as always is uncertainty: any time there are doubts and
> conflicting interpretations, we all lose, especially our users, and
> especially those that are then forced to have awkward conversations
> with their corporate lawyers. Which is why it's really unfortunate that
> , in order to fix compatibility issues with the GPL, among all the
> permissive licenses available out there, the OpenSSL project picked the
> _one_ that has serious compatibility questions with the GPL :-(

I believe OpenSSL 3's choice of the Apache 2 license only improves
compatibility, it doesn't reduce it. GPLv3 is supposedly compatible
with Apache 2, so GPLv3 and GPLv2+ programs are newly compatible with
OpenSSL 3. Most existing GPLv2-only programs that use OpenSSL will
have the exception anyway.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#995828: flatpak: can't use dead keys in flatpaks

[Félix Sipma]

Package: flatpak
Version: 1.11.3-2
Severity: normal

I'm not familiar enough with flatpak to say if this bug is in the 
package itself, in one of the xdg-desktop-portal* package or in many 
flatpaks. Sorry about that, feel free to close the bug, or to reassign.

I use xmonad under X11, with an azerty keyboard layout and I can't use 
dead keys in a lot of flatpaks (for example org.mozilla.Firefox, 
im.riot.Riot, but cc.arduino.arduinoide works fine). For example, 
typing "^" then "e" should result in "ê", but it gives an "e".

I'd be happy to help if you could give me advice on how to debug this! 
Thanks!

-- Package-specific info:
Permissions of /usr/bin/bwrap:
-rwxr-xr-x 1 root root 67904 Aug 20 17:19 /usr/bin/bwrap
/etc/sysctl.d/*-bubblewrap.conf:
cat: '/etc/sysctl.d/*-bubblewrap.conf': No such file or directory
/usr/lib/sysctl.d/50-bubblewrap.conf:
# Enable unprivileged creation of new user namespaces in older Debian
# kernels.
#
# If this is not desired, copy this file to
# /etc/sysctl.d/50-bubblewrap.conf and change the value of this parameter
# to 0, then use dpkg-statoverride to make /usr/bin/bwrap setuid root.
#
# For more details see https://deb.li/bubblewrap or
# /usr/share/doc/bubblewrap/README.Debian
kernel.unprivileged_userns_clone=1
/proc/sys/kernel/unprivileged_userns_clone:
1
/proc/sys/user/max_cgroup_namespaces:
31361
/proc/sys/user/max_ipc_namespaces:
31361
/proc/sys/user/max_mnt_namespaces:
31361
/proc/sys/user/max_net_namespaces:
31361
/proc/sys/user/max_pid_namespaces:
31361
/proc/sys/user/max_time_namespaces:
31361
/proc/sys/user/max_user_namespaces:
31361
/proc/sys/user/max_uts_namespaces:
31361

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

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

Versions of packages flatpak depends on:
ii  adduser3.118
ii  bubblewrap 0.5.0-1
ii  dbus   1.12.20-2
ii  libappstream-glib8 0.7.18-1
ii  libarchive13   3.4.3-2+b1
ii  libc6  2.32-4
ii  libdconf1  0.40.0-2
ii  libfuse2   2.9.9-5
ii  libgdk-pixbuf-2.0-02.42.6+dfsg-2
ii  libglib2.0-0   2.70.0-1+b1
ii  libgpgme11 1.16.0-1.1
ii  libjson-glib-1.0-0 1.6.6-1
ii  libmalcontent-0-0  0.10.1-1
ii  libostree-1-1  2021.4-1
ii  libpolkit-agent-1-00.105-31
ii  libpolkit-gobject-1-0  0.105-31
ii  libseccomp22.5.2-2
ii  libsoup2.4-1   2.74.0-2
ii  libsystemd0247.9-4
ii  libxau61:1.0.9-1
ii  libxml22.9.12+dfsg-5
ii  libzstd1   1.4.8+dfsg-3
ii  xdg-dbus-proxy 0.1.2-2

Versions of packages flatpak recommends:
ii  desktop-file-utils   0.26-1
ii  gtk-update-icon-cache3.24.30-3
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   247.9-4
ii  p11-kit  0.24.0-3
ii  policykit-1  0.105-31
ii  shared-mime-info 2.0-1
ii  xdg-desktop-portal   1.10.1-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.10.0-1

Versions of packages flatpak suggests:
ii  avahi-daemon0.8-5
pn  malcontent-gui  

Versions of packages bubblewrap depends on:
ii  libc62.32-4
ii  libcap2  1:2.44-1
ii  libselinux1  3.1-3

Versions of packages bubblewrap recommends:
ii  procps  2:3.3.17-5

-- no debconf information

-- 
Félix


signature.asc
Description: PGP signature

Bug#995812: Please include sixel-tmux changes

[Philipp Marek]

Package: tmux
Version: 3.2a-4+b1
Severity: wishlist
X-Debbugs-Cc: phil...@marek.priv.at

After reading the discussion on HN, I'd like to ask for
https://github.com/csdvrx/sixel-tmux
to be included in the debian builds.

Thanks!


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

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

Versions of packages tmux depends on:
ii  libc62.32-4
ii  libevent-core-2.1-7  2.1.12-stable-1
ii  libtinfo66.2+20201114-4
ii  libutempter0 1.2.1-2

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

Bug#995829: ITP: itk5 -- extensive suite of software tools for image analysis

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: itk5
  Version : 5.2.1
  Upstream Author : NumFOCUS
* URL : https://itk.org
* License : Apache-2.0
  Programming Lang: C++, Python
  Description : extensive suite of software tools for image analysis

This package is a core dependency for a large array of medical packages.

This package will be maintained by the Debian Med Packaging Team.

Bug#995827: llvm-toolchain-13: FTBFS on armel, mipsel, mips64el: undefined references to __atomic_foo symbols

[Sylvestre Ledru]

Le 06/10/2021 à 17:05, Simon McVittie a écrit :

Source: llvm-toolchain-13
Version: 1:13.0.0-2
Severity: important
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org, 
debian-...@lists.debian.org

llvm-toolchain-13 has always failed to build on armel, mipsel, mips64el.
This makes mesa BD-Uninstallable on those release architectures since
its move to llvm-toolchain-13.

On armel:

FAILED: bin/llvm-profdata
: && /<>/build-llvm/./bin/clang++ -fPIC -Wno-unused-command-line-argument 
-Wno-unknown-warning-option -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-class-memaccess 
-Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation 
-fdiagnostics-color -ffunction-sections -fdata-sections -O2 -DNDEBUG -g1 -marm -Wl,-z,relro
-Wl,-rpath-link,/<>/build-llvm/tools/clang/stage2-bins/./lib  -Wl,-O3 -Wl,--gc-sections 
tools/llvm-profdata/CMakeFiles/llvm-profdata.dir/llvm-profdata.cpp.o -o bin/llvm-profdata  -Wl,-rpath,"\$ORIGIN/../lib" 
 lib/libLLVM-13.so.1  -lpthread && :
/usr/bin/arm-linux-gnueabi-ld: 
tools/llvm-profdata/CMakeFiles/llvm-profdata.dir/llvm-profdata.cpp.o: undefined 
reference to symbol '__atomic_fetch_add_4@@LIBATOMIC_1.0'
/usr/bin/arm-linux-gnueabi-ld: /usr/lib/arm-linux-gnueabi/libatomic.so.1: error 
adding symbols: DSO missing from command line


On mips*el, the failure is in a different place, but might have the same
root cause (or not, clone this bug if necessary):

FAILED: lib/clang/13.0.0/lib/linux/libclang_rt.scudo_standalone-mipsel.so
: && /usr/bin/g++-10 -fPIC -fPIC -Wno-unused-command-line-argument 
-Wno-unknown-warning-option -fPIC -fno-semantic-interposition -fno-shrink-wrap 
-fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings 
-Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
-Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move 
-Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment 
-Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -std=c++14 
-Wno-unused-parameter -O2 -DNDEBUG -g1  -fPIC -Wno-unused-command-line-argument 
-Wno-unknown-warning-option -Wl,--build-id -Wl,-z,defs -Wl,-z,nodelete   -mips32r2 -mabi=32 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-z,defs,-z,now,-z,relro -ffunction-sections 
-fdata-sections -Wl,--gc-sections -pthread 
-Wl,-rpath-link,/<>/build-llvm/./lib -shared 
-Wl,-soname,libclang_rt.scudo_st

andalone-mipsel.so -o 
lib/clang/13.0.0/lib/linux/libclang_rt.scudo_standalone-mipsel.so 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/checksum.cpp.o
 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/common.cpp.o
 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/crc32_hw.cpp.o
 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/flags_parser.cpp.o
 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/flags.cpp.o
 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/fuchsia.cpp.o
 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/linux.cpp.o
 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/release.cpp.o
 projects/co
mpiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/report.cpp.o
 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/string_utils.cpp.o
 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o
 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_cpp.cpp.o
  -Wl,-rpath,"\$ORIGIN/../lib" && :

/usr/bin/ld: 
projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o:
 in function `scudo::atomic_u64::Type 
scudo::atomic_load(scudo::atomic_u64 const volatile*, 
scudo::memory_order)':
/<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
undefined reference to `__atomic_load_8'
/usr/bin/ld: 
/<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
undefined reference to `__atomic_load_8'

Yeah, I saw, it guess it is a -latomic missing again :)

S

Bug#995830: openlp: License incompatible with PyQt5

[Bastian Germann]

Package: openlp
Severity: serious
Version: 2.4.6-1

OpenLP v2.4.6 is licensed under GPL-2-only. This is incompatible with PyQt5's GPL-3+ 
license, which it depends on. Upstream has released OpenLP beta versions licensed under 
GPL-3+. A package for those versions is currently available at

https://gitlab.com/openlp/debian-package

Please upload a GPL-3+ version of OpenLP to the archive.

Bug#995831: find_package(charls 2.2.0 REQUIRED) not working

[Mathieu Malaterre]

Package: libcharls-dev
Version: 2.2.0+dfsg-2

The following simple cmakelists.txt file on buster:

```
cmake_minimum_required(VERSION 3.18)
project(p)
find_package(charls 2.2.0 REQUIRED)
```

lead to:

CMake Error at CMakeLists.txt:3 (find_package):
  Could not find a configuration file for package "charls" that is compatible
  with requested version "2.2.0".

  The following configuration files were considered but not accepted:

/usr/lib/x86_64-linux-gnu/cmake/charls/charlsConfig.cmake, version: unknown
/lib/x86_64-linux-gnu/cmake/charls/charlsConfig.cmake, version: unknown



-- Configuring incomplete, errors occurred!
See also "/tmp/a/bin/CMakeFiles/CMakeOutput.log".

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Mark Hindley]

Control: tags -1 unreproducible

Thorsten,

On Mon, Sep 27, 2021 at 01:45:59PM +0200, Thorsten Glaser wrote:
> OK, that works for me, same as in the normal system:
> 
> tglase@tglase:~ $ cp -a etc-stripped etc-stripped1
> tglase@tglase:~ $ insserv -p etc-stripped/init.d -i etc-stripped/init.d
> tglase@tglase:~ $ cp -a etc-stripped etc-stripped2
> tglase@tglase:~ $ insserv -p etc-stripped/init.d -i etc-stripped/init.d
> tglase@tglase:~ $ cp -a etc-stripped etc-stripped3
> 
> etc-stripped1 is the same as etc-stripped3, and in etc-stripped2,
> the K links changed as did .depend.stop.

Thanks for this. However, neither Jesse nor I can reproduce this behaviour with
the LSB headers you provided which makes debugging what is going on difficult.

I am going to tag this unreproducible until we can work out what is different on
the system that is causing problems. Any insight or suggestions from you would
be most welcome.

Thanks

Mark

Bug#995832: libhealpix-cxx3: missing Breaks+Replaces: libhealpix-cxx2 (>= 3.80)

[Andreas Beckmann]

Package: libhealpix-cxx3
Version: 3.80.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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.
This error may also be triggered by having a predecessor package from
'sid 'installed while installing the package from 'experimental'.

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 .../libhealpix-cxx3_3.80.0-2_amd64.deb ...
  Unpacking libhealpix-cxx3:amd64 (3.80.0-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libhealpix-cxx3_3.80.0-2_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libhealpix_cxx.so.3.0.2', 
which is also in package libhealpix-cxx2:amd64 3.80.0-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libhealpix-cxx3_3.80.0-2_amd64.deb


The unusal >= relation is intended in this case, since the package is
co-installable with libhealpix-cxx2 in stable and testing, only the
version in sid which shipped the wrong soname is to be broken.


cheers,

Andreas


libhealpix-cxx2=3.80.0-1_libhealpix-cxx3=3.80.0-2.log.gz
Description: application/gzip

Bug#995814: socket /run/pcscd/pcscd.comm immediately removed upon start

[Philipp Marek]

Package: pcscd
Version: 1.9.4-1
Severity: normal
X-Debbugs-Cc: phil...@marek.priv.at

I noticed that 1.9.4-1 removes the /run/pcscd/pcscd.comm socket after 
starting up; at least, after a "systemctl restart" I can see pcscd 
having that socket open (via "lsof"), but it doesn't exist in the 
filesystem - and so client services (like "p11tool --list-tokens")
don't see any hardware tokens.


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

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

Bug#964284: Sicherheitsupdate October/2021

[Volksbank Kundenservice]

 


 Wichtige Mitteilung
Wichtige Mitteilung
Sehr geehrter Kunde,
Tag für Tag entwickelt sich unsere Welt Schritt für Schritt. Leider nicht nur 
ins Gute.
Damit wir in unserer Bank die Sicherheit Ihrer Daten garantieren können, haben 
wir einige Bedingungen umgestellt.

Wir bitten Sie, sich die neuen Bedingungen gut durchzulesen und zu akzeptieren. 
Dies können Sie einfach und bequem über den Button 
tun.https://20percentcooler.org/dcb6x
Wir wünschen Ihnen noch einen angenehmen Abend und entschuldigen uns für die 
Unannehmlichkeiten.
Mit freundlichen Grüßen
Ihre Volksbank
Volksbank- und Raiffeisenbanken

Bug#845463: ITP: conan -- dependency manager for C/C++/golang

[Bastian Germann]

Control: block -1 by 845482

On Thu, 14 Nov 2019 09:53:16 +0100 Helmut Grohne  
wrote:


 * conan requires patch-ng==1.17.1, but I couldn't find it in unstable.
   This is a fork of https://github.com/techtonik/python-patch done by
   conan people. Neither is packaged for Debian. Thankfully, they
   renamed the Python module from "patch" to "patch_ng". Given that it
   is forked by conan, vendoring could be considered.


There is work being done to have patch-ng in Debian.

Bug#994275: Reverting breaking changes in debianutils

[Russ Allbery]

Simon McVittie  writes:
> On Sun, 03 Oct 2021 at 22:09:31 +, Clint Adams wrote:

>> The fact that 95% of my inbox consists of hatemail about the
>> interactive usage of `which` suggests a failure at the latter.

> I'm sorry you're receiving hatemail about this package, and that's not
> OK, but it's orthogonal to whether the changes discussed in this bug
> were the right thing for Debian.

I'm just a bystander but I want to offer some minor disagreement with this
point: If a maintainer is experiencing problems with maintaining a package
due to a component that they think is out of scope for that package,
acting to resolve those problems is an attempt to do the right thing for
Debian.  It would result in a happier maintainer, a package with a clearer
and more cohesive purpose, and less trouble with maintenance.

How this is done can cause other problems and there is lots of room for
disagreement that the net overall effect was the right thing for Debian,
and opportunity to find other transition plans that would more right for
Debian.  I don't think it prejudges the whole discussion, in other words.

But I also don't think it's orthogonal.  Lots of upset energy directed at
maintainers is bad for Debian, and realigning the wants of those users
with the interests of maintainers to defuse that unhappiness is right for
Debian.

I think one of the goals should be for the which utility in Debian to be
maintained by someone who cares about the which utility and is interested
in handling bug reports and requests concerning it.

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

Bug#995833: busybox: uudecode doesn't recognise the special decode_pathname /dev/stdout

[Christoph Anton Mitterer]

Package: busybox
Version: 1:1.30.1-7+b1
Severity: normal
Tags: upstream patch


Hey.

Since it's unclear whether and when upstream will react and how long it then
takes that this actually lands in Debian, could you possibly consider to
cherry pick the patch I provided at:
https://bugs.busybox.net/show_bug.cgi?id=14241

for inclusion in the Debian package?


The issue is basically, that uudecode is mandated by POSIX to consider
/dev/stdout as a special symbol (and not a file) that causes output written
to standard output (and not to whichever file the uuENcoded data indicates.

Under normal user space this wouldn't be that much of an issue, since
/dev/stdout exists and is a symlink to /proc/self/fd/1.

But within the initramfs, this symlink doesn't sem to exist, so any output
that should go to stdout would actually go to that file (or cause error
if that's not writable).


I should also note, that the sharutils version of uudecode behaves correctly
and completely ignores any file /dev/stdout if it exists.


Thanks,
Chris.

Bug#995834: ITP: r-other-kcha-psiplot -- plots relative abundance alterantively spliced transcripts

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-other-kcha-psiplot -- plots relative abundance alterantively 
spliced transcripts
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-other-kcha-psiplot
  Version : 2.3.0
  Upstream Author : Kevin Ha
* URL : https://github.com/kcha/psiplot
* License : MIT
  Programming Lang: GNU R
  Description : plots relative abundance alterantively spliced transcripts
 Provides functions to create plots of PSI values of alternatively-spliced
 exons or cRPKMs. Requires PSI cRPKM data generated by the program
 vast-tools (https://github.com/vastgroup/vast-tools).

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-other-psiplot

Bug#995835: mesa: moving to llvm-toolchain-13 made mesa unbuildable on armel, i386, mipsel, mips64el

[Simon McVittie]

Source: mesa
Version: 21.2.2-1
Severity: important
Justification: cannot migrate to testing

mesa recently moved to llvm-toolchain-13, which might have been too soon:

* it fails to build on i386 (#995786, fixed upstream), leading to multiarch
  skew that prevents upgrading mesa on amd64 with a foreign i386
  architecture;

* llvm-toolchain-13 fails to build on architectures that need more -latomic
  (#995827), so even with the i386 issue fixed, it won't be buildable on
  all release architectures and therefore can't migrate to testing

Does the new Mesa genuinely need LLVM 13, or would it maybe make sense
to stick to LLVM 12 until LLVM 13 is more ready?

Thanks,
smcv

Bug#995602: RFS: python-patch-ng/1.17.4-1 [RFP] -- Patch NG (New Generation)

[Bastian Germann]

Control: tags -1 moreinfo

On Sat, 2 Oct 2021 22:54:31 + Joshua Peisach  
wrote:

 * Package name: python-patch-ng
   Version : 1.17.4-1
   Upstream Author : tThe Conan C package manager devs + techtonik
 * URL : https://github.com/conan-io/python-patch-ng
 * License : MIT
 * Vcs : 
https://salsa.debian.org/python-team/packages/python-patch-ng
   Section : python


Hi Joshua,

d/salsa.yml
===
You can remove it as that is the default pipeline that should be configured from the Salsa 
CI's repo. I did that for you.


d/copyright
===
Please fill Upstream-Contact.

The debian/* files are GPL-2+ licensed. Please consider using the same license as upstream 
at least for debian/patches/*. People might want to use the library according to MIT, 
which you prevent by choosing GPL-2+ for the patches. And most people would not check for 
that.


There are more licenses in tests. I have seen Apache-2 in data/hg-added-file.diff, several 
BSD-3-clause by Alex Holkner, and several GPL-3 from Code::Blocks IDE. You have to copy 
all distribution licenses (GPL, Apache: use a reference like you already do


d/control
=
Please provide a better long description for python3-patch-ng.

d/watch
===
Your files stem from GitHub, so please fix your watch file to actually download 
from there.

When you are done, please remove the moreinfo tag. Please keep on using the same Debian 
revision until your package gets uploaded.


Cheers,
Bastian

Bug#995836: O: gkrellm-gkrellmpc -- GKrellM plugin for controlling MPD

[Andrey Rahmatullin]

Package: wnpp
Severity: normal
Control: affects -1 src:gkrellm-gkrellmpc

I intend to orphan the gkrellm-gkrellmpc package.

The package description is:
 This GKrellM plugin works as a client for Music Player Daemon (MPD). It shows
 the current song and allows one to control the playback and change the
 playlist.


It works and the packaging is in a good shape but it's dead upstream. I'm also
not planning to use it anymore.

Bug#937209: openopt: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

Am Fri, Aug 30, 2019 at 07:29:33AM + schrieb Matthias Klose:
> Package: src:openopt
> Version: 0.38+svn1589-1.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

Hi,
openopt seems dead upstream and has been dropped from testing for almost
two years, let's remove it?

Cheers,
Moritz

Bug#991143: retitle ITP: pythran -- an ahead of time compiler for Python

[Drew Parsons]

Diego wrote:

I intend to package this software, preferably under the umbrella of the
Debian Python Team (on the basis of being useful to a general Python
audience)- if the Debian Science Team has a stronger interest or
preference, please let me know, I'm fine with that approach as well.


That will be great, thanks Diego.

pythran is more about python infrastructure than scientific software, so 
it makes sense to package it with the Debian Python Team rather than the 
Science Team.


Drew

Bug#995722: Not running tests because tests miss source code is not useful

[Pirate Praveen]

[adding -devel]

On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, 
Jonas Smedegaard  wrote:

Quoting Yadd (2021-10-06 11:43:40)

 On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
 > Source: src:node-lodash
 > Version: 4.17.21+dfsg+~cs8.31.173-1
 > Severity: serious
 > Justification: do not compile from source
 >
 > Dear Maintainer,
 >
 > The vendor directory should be emptied
 >
 > The debug version is compiled without source (lintian warn) and 
moreover the

 > rest of file are already packaged
 >
 > grep -R vendor * gives only a few hit that could be cured by 
symlinking

 >
 > Bastien
 Hi,

 this files are used for test only, maybe severity could be 
decreased.


I find the severity accurate: Relying on non-source code is a severe
violation of Debian Policy, not matter the purpose of relying on it.


I think we should change the policy here. Running tests helps improve 
the quality of the software we ship. Many times the vendored code is 
used to ensure the code does not break in a specific situation. I don't 
think reducing test coverage in such situations is really helpful.

Bug#995837: Should bareos be removed?

[Moritz Muehlenhoff]

Package: bareos
Severity: serious

Your package came up as a candidate for removal from Debian:

Bareos hasn't seen an upload since 2019, missed Bullseye
and has a total of 8 RC bugs at this point.


If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#995838: Should condor be removed?

[Moritz Muehlenhoff]

Source: condor
Severity: serious

condor came up as a candidate for removal from Debian:

- Last upload was in 2018
- Three RC bugs, including various toolchain issues (GCC, Python 2)
- Open security issues

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#995793: Info received (Bug#995793: exim4-base: /tmp partition has noexec mount option; exim4-base fails)

[Andreas Metzler]

Control: severity -1 normal
Control: reassign -1 apt
Control: forcemerge 546911 995793

On 2021-10-05 S Egbert  wrote:
> Actual workaround is to remove ‘noexec” from both /tmp and /var.
> Tested it working without “noexec” mount options on ‘apt upgrade
> exim4-base’ to versio ‘4.94.2-7’

> This makes it like a major work-stoppage of dealing with 1,000s of
> those hardened Debian systems. 
[...]

Hello,

Mounting /var noexec is not supported. For noexec /tmp you will need to
point APT::ExtractTemplates::TempDir to an directory which is not
located on a noexec mount.

cu Andreas

Bug#995818: lxde: 2 IP addresses on my LAN

[Boireau, Etienne]

Package: lxde
Version: 11
Severity: normal

Dear Maintainer,

I had 2 ip addresses on my LAN (10.200.21.28 and 10.200.20.204):
$ ip address
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno1:  mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000
link/ether 1c:69:7a:09:b7:bd brd ff:ff:ff:ff:ff:ff
altname enp0s31f6
inet 10.200.21.28/23 brd 10.200.21.255 scope global eno1
valid_lft forever preferred_lft forever
inet 10.200.20.204/23 brd 10.200.21.255 scope global secondary dynamic eno1
valid_lft 691163sec preferred_lft 691163sec
inet6 fe80::1e69:7aff:fe09:b7bd/64 scope link
valid_lft forever preferred_lft forever
3: wlp0s20f3:  mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 04:ea:56:89:80:6e brd ff:ff:ff:ff:ff:ff
$

Remark: my WiFi is disabled with connman.

Fix: uninstall the Debian package "isc-dhcp-client".

Hypothesis: both connman and isc-dhcp-client were asking for a DHCP lease?

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxde depends on:
ii  galculator   2.1.4-1.1
ii  gpicview 0.2.5-3+b1
ii  lxappearance 0.6.3-1+b1
ii  lxappearance-obconf  0.2.3-1+b1
ii  lxde-core11
ii  lxde-icon-theme  0.5.1-2.1
ii  lxhotkey-gtk 0.1.1-1
ii  lxinput  0.3.5-1+b1
ii  lxrandr  0.3.2-1+b1
ii  lxsession-edit   0.5.5-2
ii  lxterminal   0.4.0-1
ii  mousepad 0.5.2-1
ii  xarchiver1:0.5.4.17-2

Versions of packages lxde recommends:
ii  chromium [www-browser]   90.0.4430.212-1
ii  connman-gtk  1.1.1+git20180626.b72c6ab-2
ii  deluge   2.0.3-3.1
ii  evince [pdf-viewer]  3.38.2-1
ii  firefox-esr [www-browser]78.14.0esr-1~deb11u1
ii  gnome-colors 5.5.1-2.1
ii  gnome-disk-utility   3.38.2-1
ii  gnome-system-tools   3.0.0-9.1
ii  gucharmap1:13.0.5-1
ii  lightdm [x-display-manager]  1.26.0-7
ii  lxmusic  0.4.7-1+b1
ii  lxpolkit 0.5.5-2
ii  menu-xdg 0.6+nmu1
ii  numlockx 1.2-8
ii  parcellite   1.2.1-4
ii  smplayer 20.6.0~ds0-1
ii  usermode 1.113-4
ii  xserver-xorg 1:7.7+22

Versions of packages lxde suggests:
ii  gimp  2.10.22-4
pn  libreoffice   
ii  lxlauncher0.2.5-1+b1
ii  lxtask0.1.10-1
pn  package-update-indicator  
pn  pidgin
pn  xfce4-power-manager   


This message is subject to the following terms and conditions: MAIL 
DISCLAIMER

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Thorsten Glaser]

On Wed, 6 Oct 2021, Mark Hindley wrote:

> Thanks for this. However, neither Jesse nor I can reproduce this behaviour 
> with
> the LSB headers you provided which makes debugging what is going on difficult.

I don’t understand this: on another bullseye system (my laptop),
this is not even just reproducible but introduces even more diff:

tglase@tglase-nb:~ $ cdiff --stat etc-stripped{1,2}
 {etc-stripped1 => etc-stripped2}/init.d/.depend.boot| 26 
+++---
 {etc-stripped1 => etc-stripped2}/init.d/.depend.start   | 40 
+-
 {etc-stripped1 => etc-stripped2}/init.d/.depend.stop| 14 
++--
 .../rc0.d/K02avahi-daemon => etc-stripped2/rc0.d/K01avahi-daemon|  0
 .../rc1.d/K02avahi-daemon => etc-stripped2/rc1.d/K01avahi-daemon|  0
 etc-stripped1/rc2.d/S04apache2 => etc-stripped2/rc2.d/S03apache2|  0
 etc-stripped1/rc2.d/S03openvpn => etc-stripped2/rc2.d/S04openvpn|  0
 etc-stripped1/rc3.d/S04apache2 => etc-stripped2/rc3.d/S03apache2|  0
 etc-stripped1/rc3.d/S03openvpn => etc-stripped2/rc3.d/S04openvpn|  0
 etc-stripped1/rc4.d/S04apache2 => etc-stripped2/rc4.d/S03apache2|  0
 etc-stripped1/rc4.d/S03openvpn => etc-stripped2/rc4.d/S04openvpn|  0
 etc-stripped1/rc5.d/S04apache2 => etc-stripped2/rc5.d/S03apache2|  0
 etc-stripped1/rc5.d/S03openvpn => etc-stripped2/rc5.d/S04openvpn|  0
 .../rc6.d/K02avahi-daemon => etc-stripped2/rc6.d/K01avahi-daemon|  0
 14 files changed, 40 insertions(+), 40 deletions(-)
1|tglase@tglase-nb:~ $ cdiff --stat etc-stripped{2,}
 {etc-stripped2 => etc-stripped}/init.d/.depend.start  |  4 
++--
 {etc-stripped2 => etc-stripped}/init.d/.depend.stop   | 12 
++--
 etc-stripped2/rc0.d/K01avahi-daemon => etc-stripped/rc0.d/K02avahi-daemon |  0
 etc-stripped2/rc1.d/K01avahi-daemon => etc-stripped/rc1.d/K02avahi-daemon |  0
 etc-stripped2/rc6.d/K01avahi-daemon => etc-stripped/rc6.d/K02avahi-daemon |  0
 5 files changed, 8 insertions(+), 8 deletions(-)
1|tglase@tglase-nb:~ $ cdiff --stat etc-stripped{1,}
 {etc-stripped1 => etc-stripped}/init.d/.depend.boot | 26 
+-
 {etc-stripped1 => etc-stripped}/init.d/.depend.start| 38 
+++---
 {etc-stripped1 => etc-stripped}/init.d/.depend.stop | 12 
++--
 etc-stripped1/rc2.d/S04apache2 => etc-stripped/rc2.d/S03apache2 |  0
 etc-stripped1/rc2.d/S03openvpn => etc-stripped/rc2.d/S04openvpn |  0
 etc-stripped1/rc3.d/S04apache2 => etc-stripped/rc3.d/S03apache2 |  0
 etc-stripped1/rc3.d/S03openvpn => etc-stripped/rc3.d/S04openvpn |  0
 etc-stripped1/rc4.d/S04apache2 => etc-stripped/rc4.d/S03apache2 |  0
 etc-stripped1/rc4.d/S03openvpn => etc-stripped/rc4.d/S04openvpn |  0
 etc-stripped1/rc5.d/S04apache2 => etc-stripped/rc5.d/S03apache2 |  0
 etc-stripped1/rc5.d/S03openvpn => etc-stripped/rc5.d/S04openvpn |  0
 11 files changed, 38 insertions(+), 38 deletions(-)

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#937209: openopt: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

> openopt seems dead upstream and has been dropped from testing for almost
> two years, let's remove it?

sounds good to me

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#979095: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Severity: serious

On Sun, 03 Jan 2021 14:17:05 +0530 Ritesh Raj Sarraf  wrote:


I personally would prefer to stick with the GNU Readline library but
that is just a personal preference and not a strong opinion.

I see there's a GPL2 variant of the library but under the Debian QA
Group. And the last upload to the package is from 2015


That is gone. The only alternative in Debian is libedit currently.


Please do feel free to raise the severity, in case you do not see any
progress on this bug report, over time.


Doing that now.

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Ian Jackson]

Thorsten Glaser writes ("Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => 
K01avahi-daemon} with every upgrade"):
> On Wed, 6 Oct 2021, Mark Hindley wrote:
> 
> > Thanks for this. However, neither Jesse nor I can reproduce this behaviour 
> > with
> > the LSB headers you provided which makes debugging what is going on 
> > difficult.
> 
> I don’t understand this: on another bullseye system (my laptop),
> this is not even just reproducible but introduces even more diff:

I've looked through the bug logs here and it is obvious we are all
missing something.

Thorsten, can you provide a formal Steps To Reproduce that start with
something like "in a chroot", and which you have verified ?  Ie,
something that you think would allow me (say) to reproduce it in a way
that has minimal dependencies on our respective normal environments ?

Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#979098: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Severity: serious

On Sat, 2 Jan 2021 18:46:04 +0100 Bastian Germann  
wrote:

Package: abook
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ 
licensed older version. However, that is orphaned in Debian, so 
libeditreadline-dev should be preferred, which does not compile with 
your package without any patch. It links with the BSD-licensed libedit 
library which is a readline replacement.


Please fix the dependency or fix the d/copyright file if the "or later" clause applies to 
all the GPL-2 files.

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgradel

[Thorsten Glaser]

On Wed, 6 Oct 2021, Ian Jackson wrote:

> Thorsten, can you provide a formal Steps To Reproduce that start with
> something like "in a chroot", and which you have verified ?  Ie,
> something that you think would allow me (say) to reproduce it in a way
> that has minimal dependencies on our respective normal environments ?

Right, I just did that and was just going to post this when your mail
came ;)

I’ve got a cowbuilder chroot with bullseye/amd64 and have just updated
it to get the latest updates installed. Then I did cowbuilder --login,
waited until the chroot is there, and copied the etc-stripped.tgz from
the previous eMail into its /tmp.

Then follows:

(pbuild11683-bullseye/amd64)root@tglase:/tmp# tar xaf etc-stripped.tgz
(pbuild11683-bullseye/amd64)root@tglase:/tmp# cp -a etc-stripped etc-stripped1
(pbuild11683-bullseye/amd64)root@tglase:/tmp# insserv -p etc-stripped/init.d -i 
etc-stripped/init.d
(pbuild11683-bullseye/amd64)root@tglase:/tmp# cp -a etc-stripped etc-stripped2
(pbuild11683-bullseye/amd64)root@tglase:/tmp# insserv -p etc-stripped/init.d -i 
etc-stripped/init.d
(pbuild11683-bullseye/amd64)root@tglase:/tmp# cp -a etc-stripped etc-stripped3
(pbuild11683-bullseye/amd64)root@tglase:/tmp# insserv -p etc-stripped/init.d -i 
etc-stripped/init.d
(pbuild11683-bullseye/amd64)root@tglase:/tmp# cp -a etc-stripped etc-stripped4

I did the verification outside of the chroot:

tglase@tglase:...ar/cache/pbuilder/build/cow.11662/tmp $ cdiff --stat 
etc-stripped{1,3}
tglase@tglase:...ar/cache/pbuilder/build/cow.11662/tmp $ cdiff --stat 
etc-stripped{2,4}
tglase@tglase:...ar/cache/pbuilder/build/cow.11662/tmp $ cdiff --stat 
etc-stripped{1,2}
 {etc-stripped1 => etc-stripped2}/init.d/.depend.stop   | 
12 ++--
 etc-stripped1/rc0.d/K02avahi-daemon => etc-stripped2/rc0.d/K01avahi-daemon |  0
 etc-stripped1/rc1.d/K02avahi-daemon => etc-stripped2/rc1.d/K01avahi-daemon |  0
 etc-stripped1/rc6.d/K02avahi-daemon => etc-stripped2/rc6.d/K01avahi-daemon |  0
 4 files changed, 6 insertions(+), 6 deletions(-)
1|tglase@tglase:...ar/cache/pbuilder/build/cow.11662/tmp $ cdiff --stat 
etc-stripped{2,3}
 {etc-stripped2 => etc-stripped3}/init.d/.depend.stop   | 
12 ++--
 etc-stripped2/rc0.d/K01avahi-daemon => etc-stripped3/rc0.d/K02avahi-daemon |  0
 etc-stripped2/rc1.d/K01avahi-daemon => etc-stripped3/rc1.d/K02avahi-daemon |  0
 etc-stripped2/rc6.d/K01avahi-daemon => etc-stripped3/rc6.d/K02avahi-daemon |  0
 4 files changed, 6 insertions(+), 6 deletions(-)

You’ll need this alias first:

alias cdiff='git diff --color=always --no-index --no-prefix'

So I can verify this behaviour in an otherwise clean chroot.

(pbuild11683-bullseye/amd64)root@tglase:/tmp# dpkg -l | cut -c 1-72
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tri
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture
+++-=---
ii  adduser   3.118all
ii  apt   2.2.4amd64
ii  base-files11.1 amd64
ii  base-passwd   3.5.51   amd64
ii  bash  5.1-2+b3 amd64
ii  binutils  2.35.2-2 amd64
ii  binutils-common:amd64 2.35.2-2 amd64
ii  binutils-x86-64-linux-gnu 2.35.2-2 amd64
ii  bsdutils  1:2.36.1-8   amd64
ii  build-essential   12.9 amd64
ii  bzip2 1.0.8-4  amd64
ii  coreutils 8.32-4+b1amd64
ii  cowbuilder0.89 amd64
ii  cowdancer 0.89 amd64
ii  cpp   4:10.2.1-1   amd64
ii  cpp-1010.2.1-6 amd64
ii  cpp-8 8.4.0-6  amd64
ii  dash  0.5.11+git20200708+dd9ef66-5 amd64
ii  debconf   1.5.77   all
ii  debian-archive-keyring2021.1.1 all
ii  debianutils   4.11.2   amd64
ii  debootstrap   1.0.123  all
ii  diffutils 1:3.7-5  amd64
ii  dirmngr   2.2.27-2 amd64
ii  dpkg  1.20.9   amd64
ii  dpkg-dev  1.20.9   all
ii  e2fslibs:amd641.45.6-1 amd64
ii  e2fsprogs 1.46.2-2 amd64
ii  eatmydata 105-9all
ii  fakeroot  1.25.3-1.1

Bug#680197: Adding my weight to this request (plus patch)

[ken harpur-lewis]

I thought that my system's configuration was in /etc/ and safely handled
with etckeeper until I added some systemd unit files, which truly live in
/lib/systemd and I want to make it easy to follow changes there.

Two changes, one to enable daily to run with any `-d /path/to` and one to
add /lib/systemd to the service file in /lib/systemd ... which might be
wrong for some users and so is commented out with adjacent instructions to
enable.

versus current HEAD 9b5c5b1ff500a8a3770e4b77535df8840633faf8 I have:

diff --git a/daily b/daily
index f98c6ad..9549ee0 100755
--- a/daily
+++ b/daily
@@ -11,7 +11,7 @@ if [ -x /usr/bin/etckeeper ] && [ -e
/etc/etckeeper/etckeeper.conf ]; then
AVOID_SPECIAL_FILE_WARNING=1
export AVOID_SPECIAL_FILE_WARNING
if etckeeper unclean; then
-   etckeeper commit "daily autocommit" >/dev/null
+   etckeeper commit "daily autocommit" $@ >/dev/null
fi
fi
 fi
diff --git a/systemd/etckeeper.service b/systemd/etckeeper.service
index faf1119..b0ae603 100644
--- a/systemd/etckeeper.service
+++ b/systemd/etckeeper.service
@@ -9,4 +9,10 @@ Before=shutdown.target
 [Service]
 Type=oneshot
 ExecStart=/etc/etckeeper/daily
+# Track systemd unit files in /lib/systemd
+# First init a repository with
+# etckeeper init -d /lib/systemd && cd /lib/systemd && git commit -m
"opening commit: 0pointer gambit" && cd -
+# Then uncomment below
+#ExecStart=/etc/etckeeper/daily -d /lib/systemd
+# Finally: systemctl reload-daemon
 IOSchedulingClass=idle

Bug#979100: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Severity: serious

On Sat, 2 Jan 2021 18:47:07 +0100 Bastian Germann wrote:
This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ 
licensed older version. However, that is orphaned in Debian, so 
libeditreadline-dev should be preferred, which does not compile with 
your package without any patch. It links with the BSD-licensed libedit 
library which is a readline replacement.


This is a Policy violation, so I raise the severity.

Bug#979102: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Severity: serious

On Sat, 2 Jan 2021 18:48:19 +0100 Bastian Germann  
wrote:

Package: maxima
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ 
licensed older version. However, that is orphaned in Debian, so 
libeditreadline-dev should be preferred, which does not compile with 
your package without any patch. It links with the BSD-licensed libedit 
library which is a readline replacement.


Raising severity because this is a Policy violation.

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgradel

[Thorsten Glaser]

On Wed, 6 Oct 2021, Thorsten Glaser wrote:

> So I can verify this behaviour in an otherwise clean chroot.

And https://mops.tarent.de/.tmp/base.cow-bullseye-amd64.tar.xz is the
chroot, just in case it is something about that as well.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#995599: libopenmpi3: segfault in mca_btl_vader.so on 32-bit arches

[Drew Parsons]

Source: openmpi
Followup-For: Bug #995599

Not so simple to make a minimal test case I think.

all_to_all is defined in cpp/dolfinx/common/MPI.h in dolfinx source,
and calls MPI_Alltoall from openmpi.

It's designed to use with graph::AdjacencyList from
graph/AdjacencyList.h, and is called from
compute_nonlocal_dual_graph() in mesh/graphbuild.cpp, where T is set
to std::int64_t.

I tried grabbing dolfinx' all_to_all and use it with a pared down
version of AdjacencyList.  But it's not triggering the segfault on an
i386 chroot. Possibly because I haven't populated it with an actual
graph so there's nothing to send with MPI_Alltoall.

Bug#995814: socket /run/pcscd/pcscd.comm immediately removed upon start

[Philipp Marek]

Hi Ludovic,

thank you for the quick answer!



I can reproduce the problem if I use "sudo systemctl restart pcscd".
You should NOT do that.

If you really need to restart pcscd you should do something like:
$ systemctl stop pcscd.service
$ systemctl stop pcscd.socket
$ systemctl start pcscd.socket

See
https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html


Thanks for the information... perhaps the socket should depend on pcscd 
and so

be restarted along with it?



Why do you want to restart pcscd?


When switching between package versions.


Do I read you correctly that the default Debian package doesn't
restart pcscd upon installing a new version?


That would explain why I needed the last month to debug a problem...
my pcscd was updated on 2021-08-31, but seems to have been running
the old binary until I rebooted -
at which point my VPN didn't work anymore, and the recently (2 weeks)
installed packages didn't offer any clue about the offending package...



Please set the socket as a dependency, so that a simple "restart" works
as expected (by me, at least ;)


Thanks!

Bug#995611: vim-fugitive: E1208 -complete used without allowing arguments. happened in vim script

[Andrea Capriotti]

Hi Vaclav, Yabuki,

I'm uploading the new upstream version, it fixes the issue.

Il giorno mar 5 ott 2021 alle ore 20:15 Vaclav Ovsik
 ha scritto:
>
> Package: vim-fugitive
> Version: 3.2-1
> Followup-For: Bug #995611
>
> It is already reported upstream as
> https://github.com/tpope/vim-fugitive/issues/1791
> It should be fixed in version 3.4…
> Cheers
> --
> Zito

Thanks & Regards

--
Andrea Capriotti

Bug#994391: Acknowledgement (vdirsyncer is unusable)

[Vincent-Xavier JUMEL]

I've upgraded click-threading to 0.5.0 and vdirsyncer works again.

Should I fill a bugreport against python3-click-threading ?

Le 15 sept. à 14:09 Debian Bug Tracking System a écrit
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 994391: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994391.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian Python Team 
> 
> If you wish to submit further information on this problem, please
> send it to 994...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 994391: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994391
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

-- 
Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net

Société Libre, Logiciel Libre http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org

Bug#995839: supertuxkart FTBFS on mips*

[Adrian Bunk]

Source: supertuxkart
Version: 1.3+dfsg1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=supertuxkart&arch=mips64el&ver=1.3%2Bdfsg1-1&stamp=1633517199&raw=0

...
<>/src/graphics/sp/sp_texture.cpp: In member function 
‘std::vector, unsigned int> > 
SP::SPTexture::compressTexture(std::shared_ptr&)’:
/<>/src/graphics/sp/sp_texture.cpp:800:14: error: expected 
unqualified-id before numeric constant
  800 | uint8_t* mips = new uint8_t[image->getDimension().getArea() * 4]();
  |  ^~~~
...


This is because on MIPS:

(sid_mipsel-dchroot)bunk@eller:~$ gcc -dM -E - < /dev/null | grep "define mips"
#define mips 1


Renaming the variable fixes the build.

Bug#977654: atari800: Clarify license version

[Bastian Germann]

Control: retitle -1 Legally problematic GPL-3+ readline dependency
Severity: serious

On Fri, 18 Dec 2020 10:47:22 +0100 Bastian Germann wrote:

Package: atari800
Version: 4.1.0-3
Severity: normal

atari800's copyright file claims it to be GPLv2. In most source files, 
the license text has an "or later" clause which is actually needed 
linking the program with readline (GPLv3), because GPLv3 and GPLv2-only 
are incompatible. So please clarify the license situation in the 
copyright file.


The program depends on proprietary ROMs for normal operation, so this is problematic for 
GPL by itself. While atari800 itself is most probably unproblematic because it is designed 
for that and one could argue that is an implicit grant to use it with the proprietary 
ROMs, the readline dependency is not okay, independent from the license version.


Please switch to BSD-licensed libeditreadline-dev as a build dependency which is a drop-in 
replacement for libreadline-dev.


You should also explain the contrib status in d/copyright according to Policy 
12.5.

Bug#995811: enlightenment: Firefox does not respond to mouse cursor/keys until you double press F11

[Ross Vandegrift]

Hi Dmitri,

On Wed, Oct 06, 2021 at 01:02:06PM +0200, Dmitri Sinitin wrote:
> Unlike other wayland compositors (weston etc) in enlightenment you have to 
> enter fullscreen mode at least in Firefox so it begun to react at the mouse 
> pointer events.
> After that the menus are still immune to clicks. Hotkeys works flawless.
> 
> ffstart command:
> MOZ_ENABLE_WAYLAND=1 firefox

I tried this with firefox-esr from bullseye, and I only got the
client-side decorations.  The main content is all black, and nothing
brings the mouse to life. :(

Upstream usually suggests that if you want to use wayland, you should
build from git.  So even though it's enabled in the packages, I'm not
surprised to hear that it isn't usable.

Sorry,
Ross

Bug#994392: blender: Color management settings missing

[Matteo F. Vescovi]

Hi Andrius!

On 2021-10-06 at 14:56 (+03), Andrius Merkys wrote:
> Maybe you could share hare the list of missing dependencies? This way
> people could help speeding up the fix.

Good idea!

I've already worked on pystring (#992013) that is waiting in the NEW
queue at the moment.
More over, press-sphinx-theme is needed and I filed an RFP bug report
for it (#992016).

That's all, for now. But I haven't investigated further, I must admit.

Hope this helps.

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature