Bug#996998: libconfig-model-dpkg-perl: scan-copyrights fails for package rust-coreutils

[Vignesh Raman]

On Thu, 28 Oct 2021 17:44:05 +0200 Dominique Dumont 
 wrote:

> I've got no crash with libconfig-model-dpkg-perl 2.153.

I checked with libconfig-model-dpkg-perl 2.153 and there is no crash.

> Although I see a lot of entries with unknown licenses:
>
> Files: src/uucore/src/lib/features/process.rs
> Copyright: Maciej Dziardziel  / Jian Zeng 

> AT gmail.com>
> License: UNKNOWN
>
> Files: src/uucore/src/lib/features/signals.rs
> Copyright: Maciej Dziardziel 
> License: UNKNOWN
>
> Files: src/uucore/src/lib/features/wide.rs
> Copyright: Peter Atashian 
> License: UNKNOWN
>
> Files: src/uucore/src/lib/mods/*
> Copyright: Rolf Morel 
> License: UNKNOWN
>
> I need to check whether all toml files are parsed, or just the top 
level one.

>

You may close this bug and investigate the above issue separately. Thanks.

Regards,

Vignesh

Bug#961138: autodep8 uses host APT packages to generate dependencies for pkg-r-autopkgtest tests

[Andreas Tille]

Control: tags -1 help

Hi,

any hint from debian-ci list how to solve this?

Kind regards

 Andreas.

Am Wed, May 20, 2020 at 09:07:47AM -0700 schrieb Stefano Rivera:
> Package: autodep8
> Version: 0.16
> Severity: normal
> 
> The autodep8 generator for pkg-r-autopkgtest uses APT lists to determine
> which R packages from DESCRIPTION exist in Debian. autodep8 is run
> outside the test runner, not inside it, so this makes the behaviour
> dependant on the packages available to the test runner host.
> 
> Here's the code that introduced this approach:
> https://salsa.debian.org/ci-team/autodep8/-/merge_requests/10
> 
> It all works when the autopkgtest runner has approximately the same
> packages available as the release under test, but that's not always the
> case.
> 
> I noticed that the r-bioc-hdf5 package's test misses a dependency on
> r-cranc-bit64 when the test is run from an older stable release that
> predates this package.
> 
> I don't know how else you can solve this particular problem, though...
> 
> SR
> 
> 

-- 
http://fam-tille.de

Bug#998046: Subject: RFS: fcitx5-table-extra/5.0.5+git20211025.35e5217-1 [ITP] -- Flexible Input Method Framework - Zhengma-Pinyin table

[YaNing Lu]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fcitx5-table-extra":

 * Package name: fcitx5-table-extra
   Version : 5.0.5+git20211025.35e5217-1
   Upstream Author : 2012 Xuetian Weng 
 * URL : https://github.com/fcitx/fcitx5-table-extra
 * License : GPL-3, GPL-2+
 * Vcs : https://salsa.debian.org/Dami/fcitx5-table-extra
   Section : utils

It builds those binary packages:

  fcitx5-table - Flexible Input Method Framework
  fcitx5-table-array30 - Flexible Input Method Framework - Array30 table
  fcitx5-table-array30-large - Flexible Input Method Framework -
Array30-Large table
  fcitx5-table-boshiamy - Flexible Input Method Framework - Boshiamy table
  fcitx5-table-cangjie-large - Flexible Input Method Framework -
Cangjie-Large table
  fcitx5-table-cangjie3 - Flexible Input Method Framework - Cangjie3 table
  fcitx5-table-cangjie5 - Flexible Input Method Framework - Cangjie5 table
  fcitx5-table-cantonese - Flexible Input Method Framework - Cantonese table
  fcitx5-table-cantonhk - Flexible Input Method Framework - Cantonhk table
  fcitx5-table-easy-large - Flexible Input Method Framework - Easy-Large table
  fcitx5-table-jyutping - Flexible Input Method Framework - Jyutping table
  fcitx5-table-quick-classic - Flexible Input Method Framework -
Quick-Classic table
  fcitx5-table-quick3 - Flexible Input Method Framework - Quick3 table
  fcitx5-table-quick5 - Flexible Input Method Framework - Quick5 table
  fcitx5-table-scj6 - Flexible Input Method Framework - Scj6 table
  fcitx5-table-stroke5 - Flexible Input Method Framework - Stroke5 table
  fcitx5-table-t9 - Flexible Input Method Framework - T9 table
  fcitx5-table-wu - Flexible Input Method Framework - Wu table
  fcitx5-table-wubi-large - Flexible Input Method Framework - Wubi-Large table
  fcitx5-table-zhengma - Flexible Input Method Framework - Zhengma table
  fcitx5-table-zhengma-large - Flexible Input Method Framework -
Zhengma-Large table
  fcitx5-table-zhengma-pinyin - Flexible Input Method Framework -
Zhengma-Pinyin table

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

  https://mentors.debian.net/package/fcitx5-table-extra/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/fcitx5-table-extra/fcitx5-table-extra_5.0.5+git20211025.35e5217-1.dsc

Changes for the initial release:

 fcitx5-table-extra (5.0.5+git20211025.35e5217-1) unstable; urgency=low
 .
   * Initial release. (Closes: #997975)

Regards,
-- 
  Lu YaNing

Bug#997991: Processed: ITS: unrar-free -- Unarchiver for .rar files

[PaulLiu]

Hi Bastian,

I'll handle it soon.

Thanks,
Paul

On Thu, Oct 28, 2021 at 6:21 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Processing control commands:
>
> > owner -1 !
> Bug #997991 [src:unrar-free] ITS: unrar-free -- Unarchiver for .rar files
> Owner recorded as Bastian Germann .
>
> --
> 997991: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997991
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#997951: jsvn wrapper shell script does not work at all

[tony mancill]

On Wed, Oct 27, 2021 at 03:55:11PM +0100, Simon Tatham wrote:
> Package: svnkit
> Version: 1.8.14-4
> 
> If I install svnkit and try to use the 'jsvn' command-line interface, I
> see mysterious error messages, one of which bizarrely involves Cygwin:

Hi Simon,

Thank you for reporting this bug.  That definitely does look like a
templating issue.  I assume this hasn't been reported before because the
primary use of the svnkit within Debian has been for jars in the
libsvnkit-java library package.

I am in the midst of updating svnkit to version 1.10.3, which will take
a bit yet because it requires a newer libjna-java (which should be ready
soon - I'm just making sure there aren't any unexpected regressions in
its reverse build-deps).

Once that is ready, I will take a look at the scripts in svnkit binary
package too.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#996569: Advice needed for a strange request about getmail vs. getmail6

[Charles Cazabon]

On Mon, 18 Oct 2021 22:17:27 +0100 Sudip Mukherjee  
wrote:
> 
> Thanks, I will forward the bug upstream.

If you mean the "getmail6" maintainer, he has explicitly expressed that he has
the right to use the name of my project as the name of his fork.  He has zero
intention of changing the name, and continually ignores communication on the
subject.

I am asking Debian to step in and fix this, since *you are distributing the
fork under my project name* and causing me, and the getmail community of
users, problems.  The fact that Debian silently replaces "getmail" with
"getmail6" on OS upgrade, leading to users experiencing bugs and seeking
support from me because they don't even know what "getmail6" is, is an
additional aggravating factor.

Surely if I forked mutt and tried to get it into Debian as "mutt3" after the
mutt maintainers explicitly requested that I change the name of my fork,
Debian would rightly refuse?  If I managed to submarine it into Debian and
caused problems for the mutt community, Debian would fix the problem, remove
the problematic package, and not re-accept it unless it was renamed?

Renaming the fork is the ethical thing to do, and Debian is supposed to be
about doing the ethical thing, not "whatever we want as long as we might be
able to get away with it in a court of law".

> But incidentally, I was searching the trademark database and it seems
> "getmail" is a trademark registered by "Blue Cube Solutions Limited"
> in UK.
> https://trademarks.ipo.gov.uk/ipo-tmcase/page/Results/1/UK3129080
> 
> Not sure if "getmail" now should be using the name "getmail" as its a
> registered trademark of another company. :)

getmail predates that registration by more than 17 years.  I'm not sure if
you're trying to be disingenuous or what.

Charles
-- 
--
Charles Cazabon  
Software, consulting, and services available at http://pyropus.ca/
--

Bug#995198: wsjtx: No transmit audio

[tony mancill]

On Thu, Oct 28, 2021 at 07:39:32PM +0100, Hilary Snaden wrote:
> 
> On 23/10/2021 19:12, tony mancill wrote:
> > On Fri, Oct 22, 2021 at 08:28:50PM -0700, tony mancill wrote:
> > > On Mon, Oct 18, 2021 at 10:41:07AM +0200, Christoph Berg wrote:
> > > > wsjtx runs fine here with hamlib 4.3 when still compiled against 4.1;
> > > > I have not tested rebuilding yet.
> > > 
> > > I went ahead and performed another source upload and will test against
> > > with the resulting binary from the archive.
> > 
> > The archive-built binary package (2.5.0+repack-2) does not exhibit the
> > no-TX audio problem for me (on armhf).
> > 
> > Hilary would you be willing to try again with the updated binary?
> 
> You may need to point me towards it, I generally stay with repo packages and
> appimages to avoid too much instability.

The version to test with is 2.5.0+repack-3.  It us currently in unstable
and should be in testing sometime tomorrow or perhaps on the 30th.

You can check the status here: 

https://packages.debian.org/sid/wsjtx 

> In the meantime I have tried wsjtx on the same machine with an external
> sound card, and on an older laptop running bullseye/sid. There is no
> transmit audio on any of them. Fldigi works, and wsjtx receive works, with
> all three configurations.

This sounds consistent with the problem I experienced on my Raspberry Pi
and an IC-705 (which presents to the OS as an external USB sound card).

Cheers,
tony


signature.asc
Description: PGP signature

Bug#996569: OT: Roland Puntaier / "getmail6" drama

[Charles Cazabon]

Gary R. Schmidt  wrote:
> 
> And we - the people who are using getmail in a mission-critical environment
> - are the ones who get buggered by people forking and *not* changing the
> name.

^^ This, exactly, and I couldn't have put it better myself.

I have had numerous help/support/question contacts over "getmail6".

Not one of them even knew what "getmail6" was, or that they were using
"getmail6", or that getmail had been removed from their systems during an
OS upgrade and replaced with a badly-done fork.

Not. A. Single. One.

So if Roland or his enablers think they'll just use my project name for their
fork, work to name/package-squat on getmail so "getmail6" gets installed
instead, and then claim that "continuity for the users" justifies their...
well, the closest word I know for it is piracy, in the traditional nautical
sense ... well, that's a bunch of crap.

You know how getmail users want their "continuity"?  To not have getmail
ripped out from underneath them and replaced with something that is
deliberately trying to deceive people into thinking it is my project.

Roland, renaming your fork is both the ethical thing to do, and the right
thing to do.  Most people who fork a project do it without even needing to be
asked.  Please do the right thing, here.

And Debian, you're supposed to be about doing the ethical thing.  "getmail6"
and having it as a silent "upgrade" that replaces getmail betrays the trust of
getmail's users, and drags the good reputation of getmail through the mud.

Please change the name of this package and its executable.

Charles
-- 
---
Charles Cazabon
GPL'ed software available at:   http://pyropus.ca/software/
---

Bug#998027: [Pkg-rust-maintainers] Bug#998027: rust-smallvec: autopkgtest regression: #![feature]` may not be used on the stable release channel

[peter green]

severity 998027 normal
thanks.


Possible ways forward.

1. Do nothing, wait for the issue to go away when the new rustc makes it
into testing.


I don't mind 1.


In that case I'll downgrade the bug so it doesn't unnecessarily delay
testing migration after the new rustc migrates. I think it makes
sense to keep it open for now to document the issue.

Bug#998045: nagios4-common: PID file is not being created

[Jaime Hablutzel]

Package: nagios4-common
Version: 4.4.6-4
Severity: normal
X-Debbugs-Cc: hablutz...@gmail.com

Dear Maintainer, the current systemd service unit for Nagios 4 
(/lib/systemd/system/nagios4.service) doesn't allow Nagios to create its PID 
file because Nagios is not running in daemon mode (option -d is missing) and 
Nagios (apparently) only creates its PID file ('lock_file' option in 
/etc/nagios4/nagios.cfg) when it runs in daemon mode.

In addition, the default PID file name in the service unit 
(PIDFile=/run/nagios4/nagios.pid) is different that the one in 
/etc/nagios4/nagios.cfg (lock_file=/var/run/nagios4/nagios4.pid), so it might 
be a good idea to fix that inconsistency as well.

Now, and just for reference, I've created the following systemd drop-in as a 
workaround, 
/etc/systemd/system/nagios4.service.d/10-fix-for-incorrect-pid-management.conf:

[Service]
ExecStartPost=/bin/sh -c 'umask 022; pgrep nagios4 > 
/var/run/nagios4/nagios4.pid'
PIDFile=/run/nagios4/nagios4.pid

But maybe that approach wouldn't be really appropriate for the fix and instead, 
it would be preferred to run Nagios in daemon mode as you can see upstream. 
From 
https://github.com/NagiosEnterprises/nagioscore/blob/master/startup/default-service.in:

ExecStart=@bindir@/nagios -d @sysconfdir@/nagios.cfg

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

Kernel: Linux 5.13.0-1005-gcp (SMP w/2 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 nagios4-common depends on:
ii  adduser   3.118ubuntu5
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-2build1
ii  coreutils 8.32-4ubuntu2
ii  libjs-jquery  3.5.1+dfsg+~3.5.5-7
ii  lsb-base  11.1.0ubuntu3
ii  monitoring-plugins-basic  2.3.1-1ubuntu2
ii  ucf   3.0043

Versions of packages nagios4-common recommends:
ii  monitoring-plugins  2.3.1-1ubuntu2

nagios4-common suggests no packages.

-- Configuration Files:

-- debconf-show failed

Bug#998044: ITP: python-pyreadr -- read/write R data files via Python pandas

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: python-pyreadr -- read/write R data files via Python pandas
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-pyreadr
  Version : 0.4.2
  Upstream Author : Copyright: Otto Fajardo 

* URL : https://github.com/ofajardo/pyreadr
* License : GNU-Affero-3.0
  Programming Lang: Python
  Description : read/write R data files via Python pandas
 A python package to read and write R RData and Rds files into/from pandas
 dataframes. It does not need to have R or other external dependencies
 installed.
 .
 It can read mainly R data frames and tibbles. Also supports vectors,
 matrices, arrays and tables. R lists and R S4 objects (such as those
 from Bioconductor) are not supported. Please read the Known limitations
 section and the section on what objects can be read for more information.
 .
 This package is based on the librdata C library by Evan Miller and a
 modified version of the cython wrapper around librdata jamovi-readstat
 by the Jamovi team.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/python-team/packages/python-pyreadr

Bug#998043: armnn: Tests fail with 'illegal instruction' on NEON-less hardware

[Wookey]

Package: armnn
Version: 20.08
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

armnn has built fine in the past but -10 and -7 both failed to build when the 
build machine was antheil.
Antheil is one of the Marvell armada 32-bit arm boxes.
It builds fine on APM and AMD seattle hardware (both arm64 hardware doing 
32-bit builds)

The build failure turns out to be in the tests, and testing on abel
(Marvell porterbox) determines the offending code to be in the UnitTests binary 
itself.

gdb ./build-area/UnitTests
...
Program received signal SIGILL, Illegal instruction.
__static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) 
at ./src/profiling/LabelsAndEventClasses.cpp:14
14  ProfilingGuidGenerator LabelsAndEventClasses::m_GuidGenerator;
So it's dying in the initialisation code
(gdb) disassemble
...
> 0xb6d9acf8 <+60>:vmov.i32d8, #0  ; 0x

Which is neon code I believe and NEON is an optional extension that
shouldn't be used with checking it's present (Armada has MMX2, not
NEON).

So I think either this test binary sould be built without NEON or there should 
be a HWCAP check around such usage.

Bug#998042: buster-pu: package jbig2dec/0.16-1+deb10u1

[Thorsten Alteholz]

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


The attached debdiff for jbig2dec fixes CVE-2020-12268 in Buster.

This CVE is marked as no-dsa by the security team.

The patch just adds some checks to prevent an overflow, so the risk 
should be small. The testsuite of the package showed no errors.


  Thorstendiff -Nru jbig2dec-0.16/debian/changelog jbig2dec-0.16/debian/changelog
--- jbig2dec-0.16/debian/changelog  2019-04-07 17:52:08.0 +0200
+++ jbig2dec-0.16/debian/changelog  2021-10-24 19:03:02.0 +0200
@@ -1,3 +1,12 @@
+jbig2dec (0.16-1+deb10u1) buster; urgency=high
+
+  * Team upload (printing and LTS)
+  * CVE-2020-12268
+avoid overflow with extreme values of x,y,w,h in function
+jbig2_image_compose()
+
+ -- Thorsten Alteholz   Sun, 24 Oct 2021 19:03:02 +0200
+
 jbig2dec (0.16-1) unstable; urgency=high
 
   [ upstream ]
diff -Nru jbig2dec-0.16/debian/patches/CVE-2020-12268.patch 
jbig2dec-0.16/debian/patches/CVE-2020-12268.patch
--- jbig2dec-0.16/debian/patches/CVE-2020-12268.patch   1970-01-01 
01:00:00.0 +0100
+++ jbig2dec-0.16/debian/patches/CVE-2020-12268.patch   2021-10-24 
19:03:02.0 +0200
@@ -0,0 +1,41 @@
+commit 0726320a4b55078e9d8deb590e477d598b3da66e
+Author: Robin Watts 
+Date:   Mon Jan 27 10:12:24 2020 -0800
+
+Fix OSS-Fuzz issue 20332: buffer overflow in jbig2_image_compose.
+
+With extreme values of x/y/w/h we can get overflow. Test for this
+and exit safely.
+
+Thanks for OSS-Fuzz for reporting.
+
+Index: jbig2dec-0.16/jbig2_image.c
+===
+--- jbig2dec-0.16.orig/jbig2_image.c   2021-10-25 15:53:32.254308657 +0200
 jbig2dec-0.16/jbig2_image.c2021-10-25 16:10:42.074548650 +0200
+@@ -33,6 +33,9 @@
+ #if !defined (INT32_MAX)
+ #define INT32_MAX  0x7fff
+ #endif
++#if !defined (UINT32_MAX)
++#define UINT32_MAX  0xu
++#endif
+ 
+ /* allocate a Jbig2Image structure and its associated bitmap */
+ Jbig2Image *
+@@ -258,6 +261,15 @@
+ if (src == NULL)
+ return 0;
+ 
++if ((UINT32_MAX - src->width  < (x > 0 ? x : -x)) ||
++(UINT32_MAX - src->height < (y > 0 ? y : -y)))
++{
++#ifdef JBIG2_DEBUG
++jbig2_error(ctx, JBIG2_SEVERITY_DEBUG, -1, "overflow in 
compose_image");
++#endif
++return 0;
++}
++
+ /* The optimized code for the OR operator below doesn't
+handle the source image partially placed outside the
+destination (above and/or to the left). The affected
diff -Nru jbig2dec-0.16/debian/patches/series 
jbig2dec-0.16/debian/patches/series
--- jbig2dec-0.16/debian/patches/series 2019-03-25 09:49:08.0 +0100
+++ jbig2dec-0.16/debian/patches/series 2021-10-24 19:03:02.0 +0200
@@ -1,3 +1,5 @@
 1001_ignore_python_test.patch
 1004_extract_infile_from_autogen-sh.patch
 2001_disable_memento.patch
+
+CVE-2020-12268.patch

Bug#998041: RFS: makedeb/7.1.2+bugfix1-8 -- The modern packaging tool for Debian archives.

[Leo Puvilland]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "makedeb":

 * Package name: makedeb
   Version : 7.1.2+bugfix1-8
   Upstream Author : Hunter Wittenborn 
 * URL : https://makedeb.hunterwittenborn.com
 * License : GPL-2.0+
 * Vcs : https://github.com/makedeb/makedeb
   Section : utils

It builds those binary packages:

  makedeb - The modern packaging tool for Debian archives.

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/makedeb/makedeb_7.1.2+bugfix1-8.dsc

Changes for the initial release:

 makedeb (7.1.2+bugfix1-8) unstable; urgency=medium
 .
   * Fix find command

Regards,
-- 
  Leo Puvilland

Bug#993905: lxc-create fails GPG checkserver due to keyserver depreciation

[Diederik de Haas]

Control: fixed -1 1:4.0.10-1

On Tue, 07 Sep 2021 20:21:12 -0400 Kyle  wrote:
> Package: lxc
> Version: 1:4.0.6-2
> 
> lxc-create fails with the following error message caused by
> sks-keyservers.net going offline, The lxc package currently in testing
> includes a patch that fixes the issue by changing the keyserver from
> pool.sks-keyservers.net to keyserver.ubuntu.com. 

Yes and the fix is part of version 4.0.10-1, so marking it accordingly.

> This impacts both oldstable and stable as of writing this.
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')

Normally I'd send a message to 993905-d...@bugs.debian.org to close the bug 
with the mentioned version, but I have a feeling that this issue is primarily 
about a backported fix to stable and oldstable?
Can you confirm that?

The sks-keyservers.net https certificate expired on 2021-04-23 and last time I 
checked, it's completely defunct, so it's even worse then 'deprecated'.

Cheers,
  Diederik

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

Bug#991678: new upstream versions

[Pierre-Elliott Bécue]

reopen 991678
notfixed 991678 1:4.0.10-1
thanks

Hi,

Le vendredi 29 octobre 2021 à 00:31:06+0200, Diederik de Haas a écrit :
> Version: 1:4.0.10-1
> 
> On 30 Jul 2021 09:47:14 +0200 Harald Dunkel  wrote:
> > Package: lxc
> > Version: 1:4.0.6-2
> > Severity: wishlist
> > 
> > Upstream provides a new version 4.0.10 and 4.0.9LTS, see
> 
> Version 4.0.10-1 has been uploaded to the archives, thus closing this bug.

Please before doing so, especially if you're not the bug submitter or a
maintainer of the package, consider carefully whether or not closing the
bug is appropriate.

Here, the request is to provide lxc 4.0.10 in bullseye. While having it
in unstable is a requirement, this bug is not solved because it have
entered unstable.

Regards.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for principles than to live up to them.


signature.asc
Description: PGP signature

Bug#991615: Fixed in 4.0.10 upstream

[Pierre-Elliott Bécue]

reopen 991615
notfixed 991615 1:4.0.10-1
thanks

Hi,

Le vendredi 29 octobre 2021 à 00:23:33+0200, Diederik de Haas a écrit :
> Version: 1:4.0.10-1
> 
> https://github.com/lxc/lxc/commit/3efa0cf3455cbe330b4e79a647a57ad8e9cf3476 is 
> the commit from the upstream stable-4.0 branch and was included in the 4.0.10 
> release, so closing this bug with that version.

Please, when you're not the submitter of a bug report and not a
maintainer of the package, do consider carefully before closing the bug
report whether or not it has properly been fixed.

We still have to get that commit enter bullseye.

Regards,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for principles than to live up to them.


signature.asc
Description: PGP signature

Bug#998040: RFS: makedeb-makepkg/8.8.0-1 -- Arch Linux build utility, modified for use with makedeb

[Leo Puvilland]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "makedeb-makepkg":

 * Package name: makedeb-makepkg
   Version : 8.8.0-1
   Upstream Author : Hunter Wittenborn 
 * URL : https://github.com/makedeb/makepkg/
 * License : GPL-2.0+
 * Vcs : https://github.com/makedeb/makepkg
   Section : metapackages

It builds those binary packages:

  makedeb-makepkg - Arch Linux build utility, modified for use with makedeb

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

  https://mentors.debian.net/package/makedeb-makepkg/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/makedeb-makepkg/makedeb-makepkg_8.8.0-1.dsc

Changes for the initial release:

 makedeb-makepkg (8.8.0-1) unstable; urgency=medium
 .
   * Initial Release. (closes Bug#998038)

Regards,
-- 
  Leo Puvilland

Bug#986108: RFS: f3d/1.1.0-1 [ITP] -- fast and minimalist 3D viewer

[Bastian Germann]

Control: tags -1 moreinfo

On Mon, 29 Mar 2021 18:53:15 +0200 franc...@mzf.fr wrote:

I am looking for a sponsor for my package "f3d":

 * Package name: f3d
   Version : 1.1.0-1
   Upstream Author : Kitware SAS 
 * URL : https://kitware.github.io/F3D/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/mzf/f3d
   Section : graphics


d/copyright
===
Please consider relicensing debian/* or at least debian/patches/* to a 
license that is not more restrictive than upstream's. Currently, a 
copyrightable patch (the existing ones are probably too trivial) would 
make the package a GPL-2+ package.


Ken Martin, Will Schroeder, Bill Lorensen's copyright is missing.

src/cxxopts.hpp: Expat license is missing.

d/f3d.1
===
Please describe the options in the man page.

d/patches/do_not_install_license_file.patch
===
You should prefer using the not-installed file for this use case. 
General rule: Don't patch when you can get the same effect via different 
means.


Vcs
===
I suggest to have the package in Salsa's debian namespace so that others 
can contribute easily. If you agree I can create that and grant you 
maintainer rights for it.




When you have uploaded the next revision to review (Please keep the 
version and changelog!) please remove the moreinfo tag.

Bug#998037: gargoyle-free: Mention config file path in man

[Francesco Ariis]

Package: gargoyle-free
Version: 2019.1.1-2
Severity: normal
X-Debbugs-Cc: fa...@ariis.it

Dear Maintainer,
`man gargoyle-free` does not mention that you can write a dotfile
to configure gargoyle-free, but the possibility is there [1].

My suggestion:
- mention this in the manpage;
- copy the example config file [1] in /usr/share/doc/gargoyle-free/ so
  users can study its documentation.

[1] 
https://github.com/garglk/garglk/blob/a324d66c0e4f2c929a4c835155b4972092137b63/garglk/garglk.ini


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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 gargoyle-free depends on:
ii  fonts-go  0~20170330-1
ii  fonts-liberation  1:1.07.4-11
ii  fonts-linuxlibertine  5.3.0-6
ii  fonts-noto-core   20201225-1
ii  libc6 2.31-13+deb11u2
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.8-1
ii  libgtk2.0-0   2.24.33-2
ii  libjpeg62-turbo   1:2.0.6-4
ii  libpng16-16   1.6.37-3
ii  libsdl-mixer1.2   1.2.12-16+b1
ii  libsdl-sound1.2   1.0.3-9+b1
ii  libsdl1.2debian   1.2.15+dfsg2-6
ii  libstdc++610.2.1-6
ii  zlib1g1:1.2.11.dfsg-2

gargoyle-free recommends no packages.

gargoyle-free suggests no packages.

-- no debconf information

Bug#995587: transition: ruby3.0-add

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2021-10-20 09:45:10 -0300, Antonio Terceiro wrote:
> Control: tag -1 - moreinfo
> 
> On Sat, Oct 16, 2021 at 03:46:11PM +0200, Sebastian Ramacher wrote:
> > Control: tags -1 moreinfo
> > 
> > On 2021-10-15 06:44:36 -0300, Antonio Terceiro wrote:
> > > Hi,
> > > 
> > > On Sat, Oct 02, 2021 at 03:14:39PM -0300, Antonio Terceiro wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: transition
> > > > 
> > > > We would like to add support for ruby3.0 in ruby-defaults.
> > > > 
> > > > Ben file:
> > > > 
> > > > title = "ruby3.0-add";
> > > > is_affected = (.depends ~ /ruby2.7 | .depends ~ /ruby3.0/) & !.source ~ 
> > > > /^(ruby2.7|ruby3.0|ruby-defaults)$/);
> > > > is_good = .depends ~ /ruby3.0/;
> > > > is_bad = .depends ~ /ruby2.7/ & !.depends ~ /ruby3.0/;
> > > > 
> > > > We already did a mass rebuild some time ago, and the results don't look
> > > > bad. We should be doing a new one soon, and will come up with a list of
> > > > binNMUs
> > > 
> > > This is a friendly ping. We would like to make the switch in unstable
> > > soon and start doing binNMUs.
> > > 
> > > We have these bugs related to this transition:
> > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ruby3.0;users=debian-r...@lists.debian.org
> > > 
> > > Most of those bugs are for leaf libraries. We already started fixing the
> > > ones that block a lof of other (e.g. the ones with C extensions that
> > > FTBFS with ruby3.0) so they are ready to be binNMUed.
> > 
> > ruby3.0 isn't in testing yet - it currently fails to build on ppc64el.
> > So let's at least wait until it migrated.
> 
> ruby3.0 is now in testing. Can we go ahead with this?

Yes, please go ahead

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#997929: transition: yaml-cpp

[Adrian Bunk]

On Thu, Oct 28, 2021 at 09:50:10PM +0200, Sebastian Ramacher wrote:
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-yaml-cpp.html
> 
> On 2021-10-27 05:05:57 -0500, Simon Quigley wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear Release Team,
> > 
> > I would like to upload yaml-cpp 0.7.0 to unstable which includes an ABI bump
> > and a package name change (libyaml-cpp0.6 -> libyaml-cpp0.7). It has already
> > been uploaded to Experimental and cleared NEW. Since the package now depends
> > on googletest instead of including its own embedded copy, the package now
> > builds on less architectures.
> 
> Are builds on releases acrchitectures affected by this change?

sh4 (in ports) is the only affected Linux architecture:
https://buildd.debian.org/status/package.php?p=yaml-cpp=experimental

> Cheers

cu
Adrian

Bug#998036: lxc-checkconfig complains about use of 'which' command

[Diederik de Haas]

Package: lxc
Version: 1:4.0.10-1
Severity: normal
Tags: upstream fixed-upstream patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Earlier today I ran lxc-checkconfig and then I got this:

$ lxc-checkconfig
LXC version 4.0.10
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-5.14.0-3-amd64
- --- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
Network namespace: enabled

This was easy to fix, so I submitted the following PRs upstream:
https://github.com/lxc/lxc/pull/4019
https://github.com/lxc/lxc/pull/4021

Another one was submitted which AFAICT (only) fixes 1 other instance:
https://github.com/lxc/lxc/pull/4024

Right now, my PRs have been merged into master, but they're not part of
the 4.0.11 release (and thus also not 4.0.10), but they should be easy
to backport.

Cheers,
  Diederik

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

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

Versions of packages lxc depends on:
ii  bridge-utils 1.7-1
ii  debconf [debconf-2.0]1.5.78
ii  dnsmasq-base [dnsmasq-base]  2.86-1
ii  iproute2 5.14.0-1
ii  iptables 1.8.7-1
ii  libc62.32-4
ii  libcap2  1:2.44-1
ii  libgcc-s111.2.0-10
ii  liblxc1  1:4.0.10-1
ii  libseccomp2  2.5.2-2
ii  libselinux1  3.1-3
ii  lsb-base 11.1.0

Versions of packages lxc recommends:
ii  apparmor   3.0.3-5
ii  debootstrap1.0.123
ii  dirmngr2.2.27-2
ii  gnupg  2.2.27-2
ii  libpam-cgfs1:4.0.10-1
ii  lxc-templates  3.0.4-5
ii  lxcfs  4.0.7-1
ii  openssl1.1.1l-1
ii  rsync  3.2.3-8
ii  uidmap 1:4.8.1-1
ii  wget   1.21.2-2+b1

Versions of packages lxc suggests:
ii  btrfs-progs  5.14.1-1
ii  lvm2 2.03.11-2.1
pn  python3-lxc  

- -- debconf information:
  lxc/auto_update_config:

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYXsR8QAKCRDXblvOeH7b
bmqYAQDjPaLOk5uM3S/GUIHRLJoPLGSOSpfSNv6rVWGo5a3iIQEAk37q9eQTOmXI
BscS3A/TF1tK8AEjAQ4y4nZFC0QrJwU=
=7Kvo
-END PGP SIGNATURE-

Bug#990532: RFS: eta/1.0.1-1 [ITP] -- Utility for monitoring ETA and progress of an arbitrary process

[Bastian Germann]

Control: tags -1 moreinfo

On Thu, 1 Jul 2021 13:51:14 +0100 Mark King wrote:

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

  dget -x https://mentors.debian.net/debian/pool/main/e/eta/eta_1.0.1-1.dsc

Changes for the initial release:

 eta (1.0.1-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #923225

Some notes:
- I'm targeting debhelper-compat = 12 for convenience for the time being,
but plan to target 13 once bullseye is released
- I understand that this can't be uploaded to testing before bullseye
release, but would like to get any feedback on the packaging itself before
then, if possible
- I'm working with the upstream author to publish signatures for releases,
and will update the watch file when this becomes available


Hi Mark,

Good job on you first package! There is one thing that I do not get on 
the first look: Where do you get the "or later" clause from that is in 
GPL-3.0+ (d/copyright)? I cannot see any license header in the project, 
so I would assume GPL-3 (no +) applies. With that change I would sponsor 
the package.


Please change UNRELEASED in the changelog to unstable or experimental.

Thanks,
Bastian

Bug#997971: FWD: Bug#997971: [Beolingus] Bug#997971: Monat ist männlich!

[Peter Mueller]

reopen 997971
thanks
> From your original source file it becomes apparent that Monat is listed as 
> being neutral in Austrian German.
But only colloquially! In written Austrian German (in fact, in any written 
German), Monat is masculine, consistent with https://dict.tu-chemnitz.de and 
opposed to what dict says.
> The formatting is suboptimal, but that's a different story :).
It's not about formatting. Taking a careful look, it's an omission of extremely 
important information, namely, a tag such as [ugs.] or [coll.].
Reopening. Thanks.

Bug#998035: linux-image-5.10.0-9-amd64: Debian 11 in Xen PV DomU crashes intel_pmc_core on boot, DomU zombiefies.

[Dr . Nagy Elemér Károly]

Package: linux-image-5.10.0-9-amd64
Version: linux-image-5.10.0-9-amd64 and linux-image-5.14.0-0.bpo.2-amd64
Severity: important

Dear All,

I am reporting this bug mostly to help others with the same problem, proposing
adding a warning to the Debian 11 release notes and hoping for an upstream
kernel bugfix.

Description: Debian 11 Xen PV DomU (RAM<4GB) does not correctly shuts down
because of a intel_pmc_core module problems on Intel Xeon E3-1230 (and possibly
other Intel CPUs).

https://github.com/QubesOS/qubes-issues/issues/6052 seems to be the same issue.

Workarounds:
* Use a Debian 10 kernel in the DomU, which works
* Allocate 4+ GB RAM to the DomU
* Use PVH instead of PV (needs Xen 4.9+, and is the preferred way since Xen
4.10)

Please note:
* Backports kernel (linux-image-5.14.0-0.bpo.2-amd64) suffers from the same
problem.
* Debian 10 Dom0 Xen 4.11.4+107-gef32c7afa2-1 beheaves the same way
* Debian 9 Dom0 Xen 4.8.5.final+shim4.10.4-1+deb9u12 used PVHv1, which differs
from PVHv2 used by Xen 4.09+

Test case:
* Install Debian 10 or Debian 11, install Xen, create a PV config as below and
upon startup "BUG: unable to handle page fault for address" is displayed and it
fails to stop with "poweroff" later.
kernel = "/usr/lib/grub-xen/grub-x86_64-xen.bin"
extra = '(hd1)/boot/grub/grub.cfg'
* Change PV to PVH and it works correctly:
kernel = "/root/xen/images/debian11/vmlinuz-5.10.0-9-amd64"
ramdisk = "/root/xen/images/debian11/initrd.img-5.10.0-9-amd64"
type = 'pvh'

The full bug in my case:
[3.088164] BUG: unable to handle page fault for address: c9004049b818
[3.088175] #PF: supervisor read access in kernel mode
[3.088179] #PF: error_code(0x) - not-present page
[3.088183] PGD 7fbd9067 P4D 7fbd9067 PUD 5186067 PMD 5303067 PTE 0
[3.088191] Oops:  [#1] SMP NOPTI
[3.088195] CPU: 0 PID: 201 Comm: systemd-udevd Not tainted 5.10.0-9-amd64
#1 Debian 5.10.70-1
[3.088204] RIP: e030:pmc_core_probe+0x136/0x410 [intel_pmc_core]
[3.088209] Code: c0 48 c7 c7 48 a6 3c c0 e8 c7 25 d2 c0 48 8b 05 b0 7a 00
00 48 c7 83 88 00 00 00 20 a6 3c c0 48 63 40 50 48 03 05 92 7a 00 00 <8b> 00 48
8b 15 91 7a 00 00 48 c7 c7 e0 54 3c c0 8b 4a 54 ba 01 00
[3.088222] RSP: e02b:c9004026fc30 EFLAGS: 00010286
[3.088226] RAX: c9004049b818 RBX: 88800b028400 RCX:
fe002000
[3.088232] RDX: c03ca600 RSI: c03c41f6 RDI:
c03ca648
[3.088238] RBP: 88800b028410 R08:  R09:
fe001fff
[3.088244] R10: 7ff0 R11: 888008e01740 R12:

[3.088249] R13:  R14: 0006 R15:

[3.088260] FS:  7f94ad4928c0() GS:88807d40()
knlGS:
[3.088267] CS:  e030 DS:  ES:  CR0: 80050033
[3.088271] CR2: c9004049b818 CR3: 075d4000 CR4:
00050660
[3.088281] Call Trace:
[3.088288]  platform_drv_probe+0x35/0x80
[3.088294]  really_probe+0x37b/0x480
[3.088299]  driver_probe_device+0xe1/0x150
[3.088303]  ? driver_allows_async_probing+0x50/0x50
[3.088308]  bus_for_each_drv+0x7e/0xc0
[3.088313]  __device_attach+0xd8/0x1d0
[3.088317]  bus_probe_device+0x8e/0xa0
[3.088321]  device_add+0x399/0x840
[3.088325]  platform_device_add+0x105/0x230
[3.088331]  ? 0xc0327000
[3.088351]  pmc_core_platform_init+0x78/0x1000 [intel_pmc_core_pltdrv]
[3.088358]  do_one_initcall+0x44/0x1d0
[3.088363]  ? do_init_module+0x23/0x260
[3.088381]  ? kmem_cache_alloc_trace+0xf5/0x200
[3.088386]  do_init_module+0x5c/0x260
[3.088391]  __do_sys_finit_module+0xb1/0x110
[3.088397]  do_syscall_64+0x33/0x80
[3.088402]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[3.088407] RIP: 0033:0x7f94ad94b9b9
[3.088411] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48
[3.088423] RSP: 002b:7ffde7aa3158 EFLAGS: 0246 ORIG_RAX:
0139
[3.088430] RAX: ffda RBX: 563dc68d1530 RCX:
7f94ad94b9b9
[3.088435] RDX:  RSI: 7f94adad6e2d RDI:
0018
[3.088441] RBP: 0002 R08:  R09:
563dc689c9d0
[3.088447] R10: 0018 R11: 0246 R12:
7f94adad6e2d
[3.088453] R13:  R14: 563dc68ce450 R15:
563dc68d1530
[3.088459] Modules linked in: intel_pmc_core_pltdrv(+) intel_pmc_core
ghash_clmulni_intel evdev aesni_intel libaes crypto_simd cryptd glue_helper
pcspkr drm fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2
crc32c_generic crct10dif_pclmul crct10dif_common crc32_pclmul xen_netfront
xen_blkfront crc32c_intel
[3.088487] CR2: c9004049b818
[3.088491] ---[ end trace dd3aec620db68a1d ]---
[3.088496] RIP: e030:pmc_core_probe+0x136/0x410 

Bug#998034: RFP: cachelib -- collection of cache libraries in the same API interface

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cont...@palletsprojects.com, debian-pyt...@lists.debian.org

* Package name: cachelib
  Version : 0.4.1
  Upstream Author : cont...@palletsprojects.com
* URL : https://github.com/pallets/cachelib/
* License : BSD
  Programming Lang: python
  Description : collection of cache libraries in the same API interface

This package provides a uniform API over a number of different caching backends
including:
.
  * Memory
  * File
  * Redis
  * Memcached
  * uWSGI

Bug#990014: RFS: beebasm/1.09-1 [ITP] -- 6502 cross assembler targeting the BBC Micro

[Bastian Germann]

Control: tags -1 moreinfo

On Thu, 17 Jun 2021 21:52:35 +0200 (CEST) Dave Lambley wrote:


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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/beebasm/beebasm_1.09-1.dsc

Changes for the initial release:

 beebasm (1.09-1) unstable; urgency=medium
 .
   * Initial release (Closes: #989968)


The build fails. Please fix that and remove the moreinfo tag for the 
next review cycle.


/usr/bin/c++   -g -O2 
-ffile-prefix-map=/home/bage/Projekte/beebasm-1.09=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -W -Wcast-qual -Wshadow -Wcast-align 
-Wold-style-cast -Woverloaded-virtual -MD -MT 
CMakeFiles/beebasm.dir/src/commands.cpp.o -MF 
CMakeFiles/beebasm.dir/src/commands.cpp.o.d -o 
CMakeFiles/beebasm.dir/src/commands.cpp.o -c 
/home/bage/Projekte/beebasm-1.09/src/commands.cpp
/home/bage/Projekte/beebasm-1.09/src/commands.cpp: In member function 
‘void LineParser::HandlePutFileCommon(bool)’:
/home/bage/Projekte/beebasm-1.09/src/commands.cpp:1757:51: error: 
‘streampos’ is not a member of ‘std::ifstream’ {aka 
‘std::basic_ifstream’}
 1757 | ifstream::streampos p = 
inputFile.tellg();

  |   ^
/home/bage/Projekte/beebasm-1.09/src/commands.cpp:1760:66: error: ‘p’ 
was not declared in this scope
 1760 | 
inputFile.seekg( p );

  |  ^
make[3]: *** [CMakeFiles/beebasm.dir/build.make:121: 
CMakeFiles/beebasm.dir/src/commands.cpp.o] Fehler 1

Bug#998033: src:emscripten: fails to migrate to testing for too long: depends on llvm-toolchain-13 which isn't ready for testing yet

[Paul Gevers]

Source: emscripten
Version: 2.0.12~dfsg-2
Severity: serious
Control: close -1 2.0.26~dfsg-4
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:emscripten has been trying to migrate for
75 days [2]. Hence, I am filing this bug.

The package build with llvm-toolchain-13, but according to its
maintainer [3] it could take some time until that's ready to migrate. Is
building with llvm-toolchain-11 (which is in testing) still an option?

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

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

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

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

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=emscripten
[3] https://lists.debian.org/debian-release/2021/10/msg00466.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#998032: src:breezy-debian: fails to migrate to testing for too long: uploader built arch:all binaries (and blocked by breezy)

[Paul Gevers]

Source: breezy-debian
Version: 2.8.51
Severity: serious
Control: close -1 2.8.63
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:breezy-debian has been trying to migrate
for 237 days [2]. Hence, I am filing this bug.

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

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

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

Your package is blocked because the arch:all binary package(s) aren't
built on a buildd. Unfortunately the Debian infrastructure doesn't allow
arch:all packages to be properly binNMU'ed. Hence, I will shortly do a
no-changes source-only upload to DELAYED/15, closing this bug. Please
let me know if I should delay or cancel that upload.

I just filed an RC bug against breezy, which also needs to be fixed for
breezy-debian to migrate.

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#990826: This bug can be closed now

[Amr Ibrahim]

Here is the full story:

I had installed tensorflow and keras using pip, and they had pulled
their dependencies, which could not be satisfied with Debian system
packages.

My theory is that Lollypop could not start because it could have been
using some python packages as dependencies that had been installed
using pip. Unfortunately I cannot pinpoint the offending python
package.

Now after I removed all pip-installed python packages, Lollypop starts
normally.

This bug can be closed now.

Bug#966382: RFS: photoprint/0.4.2~pre2-3 -- Image printing utility

[Bastian Germann]

Control: tags -1 moreinfo

The package fails to build from scratch:
https://salsa.debian.org/debian/photoprint/-/jobs/2124003

Please fix it and then remove the moreinfo tag.

Bug#998031: src:breezy: fails to migrate to testing for too long: unresolved RC bug and uploader built arch:all binaries

[Paul Gevers]

Source: breezy
Version: 3.1.0-8
Severity: serious
Control: close -1 3.2.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:breezy has been trying to migrate for 178
days [2]. Hence, I am filing this bug. (I waited a bit for breezy-loom
to be autoremoved, but then the RC bug was filed).

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996963: RFS: dwarves/1.22-1 -- set of advanced DWARF utilities

[Domenico Andreoli]

On October 25, 2021 8:58:57 PM UTC, Luca Boccassi  wrote:
>On Mon, 2021-10-25 at 22:28 +0200, Domenico Andreoli wrote:
>> Hi Adam, Luca and Theodore,
>> 
>> On Thu, Oct 21, 2021 at 04:50:36PM +0200, Domenico Andreoli wrote:
>> > Package: sponsorship-requests
>> > Severity: normal
>> > 
>> > Dear all,
>> > 
>> > I'm looking for a sponsor for this package:
>> 
>> Could any of you please review this upload?
>> 
>> Thanks!
>> Dom
>
>Looks good to me, uploaded.

Thanks!

>Just a minor thing for the next time you prepare an upload: the build-
>dep on libbpf-dev needs to be bumped, this version requires >= 0.4.

I'll fix with the next upload. Thank you.

Dom

rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05

Bug#998027: [Pkg-rust-maintainers] Bug#998027: rust-smallvec: autopkgtest regression: #![feature]` may not be used on the stable release channel

[Paul Gevers]

Hi Peter,

Thanks for the analysis.

On 28-10-2021 21:29, peter green wrote:
> Possible ways forward.
> 
> 1. Do nothing, wait for the issue to go away when the new rustc makes it
> into testing.
>    (currently blocked by issues in llvm and libmodulemd (via meson))
> 2. Add breaks, in some ways this is the correct soloution, but given
> that britney does
>    not properly enforce build-dependencies I fear it could cause more
> problems than it
>    solves (i.e. ending up with version of librust-smallvec-dev and rustc
> in testing that
>    are individually installable but not co-installable).
> 3. Revert the removal of " #![cfg_attr(feature = "const_generics",
> feature(min_const_generics))]"
>    in upstream commit
> https://github.com/servo/rust-smallvec/commit/2964a8469be212f6abbb05758cabe6416d144580
> 
>    this would allow the code to be used on old compilers in nightly
> mode, but afaict would mean it couldn't
>    be used in regular mode on newer compilers.
> 4. Set the test_is_broken flag for the const_generics and const_new
> features, as far
>    as I can tell no applications in Debian use those features.
> 
> Personally I'm in favor of option 1.

I don't mind 1.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#998012: [EXTERNAL] Bug#998012: transition: healpix-cxx

[Paul Gevers]

Hi,

On 28-10-2021 21:31, Singer, Leo P. (GSFC-6610) wrote:
>> On Oct 28, 2021, at 13:54, Paul Gevers  wrote:
>>
>> Hi Leo,
>>
>> On 28-10-2021 15:49, Singer, Leo P. (GSFC-6610) wrote:
 For healpy,
 apart from the rebuild (which we can schedule), is there anything else
 that need to happen? I assume a rebuild is all that's needed and you're
 pointing out that you can fix issues when/if they arise.
>>>
>>> No, no special issues with Healpy. Anyway it's looking like Healpy upstream 
>>> might be doing a release soon.
>>
>> For avoidance of doubt, please *don't* upload new versions until the
>> transition is done, unless needed to finish the transition.
> 
> 
> Hold on a second... Christoph is telling me that he needs me to upload 
> healpix-cxx to unstable. I am hearing two conflicting things.

I was talking about healpy. Indeed, please upload healpix-cxx to
unstable to start the transition. healpy is involved in the transition.
We always try to process transitions as quick as possible, so
unnecessary new versions of involved packages can cause issues we're not
aware of causing delays in the transition. Hence, please refrain from
uploading anything except the package in transition unless it's needed
for the transition.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#997997: transition: netcdf-parallel

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/auto-netcdf-parallel.html
Control: tags -1 confirmed

On 2021-10-28 13:12:32 +0100, Alastair McKinstry wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-scie...@lists.debian.org
> 
> Hi dear release team,
> 
> I request permission to undetake the netcdf-parallel transition.
> netcdf-parallell is the  parallel build(s) of netcdf; 
> netcdf 4.8.1 is now in testing, and nertcdf-parallel 4.8.1 builds successfully
> in experimental.
> 
> This is a mini-transition; the packages depending on netcdf-parallel are:
> 
> netcdf-parallel
> 
> adios
> exodusii
> 
> I maintain all three, and adios and exodusii build against 
> netcdf-parallel-4.8.1 successfully.
> There are uploads of adios and exodusii ready.

Please go ahead

Cheers

> 
> Ben file:
> 
> title = "netcdf-parallel";
> is_affected = .depends ~ "(libnetcdf\-mpi\-18|libnetcdf\-pnetcdf\-18)" | 
> .depends ~ "(libnetcdf\-mpi\-19|libnetcdf\-pnetcdf\-19)";
> is_good = .depends ~ "(libnetcdf\-mpi\-19|libnetcdf\-pnetcdf\-19)";
> is_bad = .depends ~ "(libnetcdf\-mpi\-18|libnetcdf\-pnetcdf\-18)";
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#997929: transition: yaml-cpp

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/auto-yaml-cpp.html

On 2021-10-27 05:05:57 -0500, Simon Quigley wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> I would like to upload yaml-cpp 0.7.0 to unstable which includes an ABI bump
> and a package name change (libyaml-cpp0.6 -> libyaml-cpp0.7). It has already
> been uploaded to Experimental and cleared NEW. Since the package now depends
> on googletest instead of including its own embedded copy, the package now
> builds on less architectures.

Are builds on releases acrchitectures affected by this change?

Cheers

> 
> Here is the package list from the automated Ben page[1]:
> 
> calamares
> dcm2niix
> facter
> librime
> libzypp
> mir
> opencolorio
> opensurgsim
> pdns
> qtcreator
> ring (sid only)
> rivet (sid only)
> ros-image-common
> thinkfan
> trafficserver
> vast
> ros-rviz
> 
> Let me know if you have any questions.
> 
> [1] https://release.debian.org/transitions/html/auto-yaml-cpp.html
> 
> -- 
> Simon Quigley
> tsimo...@debian.org
> tsimonq2 on LiberaChat and OFTC
> 5C7A BEA2 0F86 3045 9CC8
> C8B5 E27F 2CF8 458C 2FA4
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#997695: transition: draco

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2021-10-24 11:50:22 +0200, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: roehl...@debian.org
> 
> Dear release team,
> 
> the draco library needs a transition after an ABI break due to a
> refactored class in a public header. I notified upstream that they
> forgot to bump the SOVERSION, but they did not react yet.
> 
> Fortunately, none of the reverse dependencies (PDAL and the filament
> library waiting in NEW) uses that refactored class, so the transition
> should run smoothly, and my local rebuild on amd64 was successful at
> least.
> 
> The auto-generated ben file is good.

Please go ahead

Cheers

> 
> Cheers
> Timo
> 
> 
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#998027: [Pkg-rust-maintainers] Bug#998027: rust-smallvec: autopkgtest regression: #![feature]` may not be used on the stable release channel

[peter green]

"error[E0554]: `#![feature]` may not be used on the stable release channel" is 
a red herring.
The autopkgtests for rust packages try the tests in normal mode first, then if 
it fails with
E0554 they are rerun in "nightly" mode.

The real issue is further down the log.



error[E0658]: const generics are unstable
   --> src/lib.rs:412:15
|
412 | impl SmallVecData<[T; N]> {
|   ^
|
= note: see issue #74878  
for more information
= help: add `#![feature(min_const_generics)]` to the crate attributes to 
enable


const generics were stabilized in rustc 1.51, currently testing has 1.50 and 
unstable has 1.56

Possible ways forward.

1. Do nothing, wait for the issue to go away when the new rustc makes it into 
testing.
   (currently blocked by issues in llvm and libmodulemd (via meson))
2. Add breaks, in some ways this is the correct soloution, but given that 
britney does
   not properly enforce build-dependencies I fear it could cause more problems 
than it
   solves (i.e. ending up with version of librust-smallvec-dev and rustc in 
testing that
   are individually installable but not co-installable).
3. Revert the removal of " #![cfg_attr(feature = "const_generics", 
feature(min_const_generics))]"
   in upstream commit 
https://github.com/servo/rust-smallvec/commit/2964a8469be212f6abbb05758cabe6416d144580
   this would allow the code to be used on old compilers in nightly mode, but 
afaict would mean it couldn't
   be used in regular mode on newer compilers.
4. Set the test_is_broken flag for the const_generics and const_new features, 
as far
   as I can tell no applications in Debian use those features.

Personally I'm in favor of option 1.

Bug#992164: autorm ping

[Jonathan Carter]

Just a ping to the BTS to avoid auto-rm, I'll file this bug with 
upstream soon.

Bug#982848: binutils-m68hc1x

[Vincent Smeets]

fixed 997210 1:3.0.1
done 982848 1:3.0.1
thanks

Bug#998013: localslackirc: autopkgtest failure: Cannot find implementation or library stub for module named "typedload"

[Salvo Tomaselli]

AFAIK they always run in the source directory, otherwise the error
would be that make can't find a Makefile, rather than an issue with
missing dependencies.

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#924131: #924131: debian-history: host the scanned printout of the Debian creation announcement in Debian server

[Joost van Baal-Ilić]

tags 924131 +patch
thanks


Hi,

On Thu, Oct 28, 2021 at 07:38:10AM +0200, Joost van Baal-Ilić wrote:
> 
> This bug is now partially fixed:
> 
> I've just uploaded a copy of the 1993 announcement news posting to
> https://wiki.debian.org/DebianHistory?action=AttachFile=get=Debian-announcement-1993.txt
> ; it's linked to from https://wiki.debian.org/DebianHistory .


And uploaded the picture of the printout to
https://wiki.debian.org/DebianHistory?action=AttachFile=get=Debian-announcement-1993-pic-by-Ian_Murdock.png
.  Now maybe



The Debian Project was officially founded by Ian Murdock on https://groups.google.com/forum/message/raw?msg=comp.os.linux.development/Md3Modzg5TU/xty88y5OLaMJ;>August
16th, 1993.  (There is also a https://www.flickr.com/photos/iamurdock/20006308374/;>scanned
printout of that announcement.) At that time, the whole concept of a


could get changed to



The Debian Project was officially founded by Ian Murdock on https://wiki.debian.org/DebianHistory?action=AttachFile=get=Debian-announcement-1993.txt;>August
16th, 1993.  (There is also a https://wiki.debian.org/DebianHistory?action=AttachFile=get=Debian-announcement-1993-pic-by-Ian_Murdock.png;>scanned
printout of that announcement.) At that time, the whole concept of a


.

(And that would also fix the broken groups.google.com link; it gives 'The page 
isn’t
redirecting properly' here now.)

Bye,

Joost

Bug#996633: plasma-workspace: plasma-baloorunner.service enters failed state

[Gregor Riepl]

Package: plasma-workspace
Version: 4:5.23.0-3
Followup-For: Bug #996633
X-Debbugs-Cc: onit...@gmail.com

It looks like this intended behavior:
https://invent.kde.org/plasma/plasma-
workspace/-/blob/master/runners/baloo/baloosearchrunner.cpp#L35-37

if (!config.fileIndexingEnabled()) {
return -1;
}

If file indexing is disabled, baloo exits with -1 immediately, without even
printing any error message. That's rather short-sighted...

You should probably report this issue upstream.


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

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

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]1.12.20-3
ii  drkonqi 5.23.0-1
ii  frameworkintegration5.86.0-1
ii  gdb-minimal [gdb]   10.1-2
ii  init-system-helpers 1.60
ii  iso-codes   4.7.0-1
ii  kactivitymanagerd   5.23.0-1
ii  kded5   5.86.0-1
ii  kinit   5.86.0-1
ii  kio 5.86.0-1
ii  kpackagetool5   5.86.0-1
ii  kwin-common 4:5.23.0-2
ii  libappstreamqt2 0.14.6-1
ii  libc6   2.32-4
ii  libcolorcorrect54:5.23.0-3
ii  libegl1 1.3.4-2+b1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.11.0+dfsg-1
ii  libgcc-s1   11.2.0-10
ii  libgl1  1.3.4-2+b1
ii  libgps283.22-4
ii  libice6 2:1.0.10-1
ii  libkf5activities5   5.86.0-1
ii  libkf5activitiesstats1  5.86.0-1
ii  libkf5archive5  5.86.0-1
ii  libkf5authcore5 5.86.0-1
ii  libkf5baloo55.86.0-1
ii  libkf5bookmarks55.86.0-1
ii  libkf5calendarevents5   5.86.0-1
ii  libkf5completion5   5.86.0-1
ii  libkf5config-bin5.86.0-1
ii  libkf5configcore5   5.86.0-1
ii  libkf5configgui55.86.0-1
ii  libkf5configwidgets55.86.0-1
ii  libkf5coreaddons5   5.86.0-1
ii  libkf5crash55.86.0-1
ii  libkf5dbusaddons5   5.86.0-1
ii  libkf5declarative5  5.86.0-1
ii  libkf5globalaccel-bin   5.86.0-1
ii  libkf5globalaccel5  5.86.0-1
ii  libkf5guiaddons55.86.0-1
ii  libkf5holidays5 1:5.86.0-1
ii  libkf5i18n5 5.86.0-1
ii  libkf5iconthemes5   5.86.0-1
ii  libkf5idletime5 5.86.0-1
ii  libkf5itemmodels5   5.86.0-1
ii  libkf5jobwidgets5   5.86.0-1
ii  libkf5kcmutils5 5.86.0-1
ii  libkf5kiocore5  5.86.0-1
ii  libkf5kiofilewidgets5   5.86.0-1
ii  libkf5kiogui5   5.86.0-1
ii  libkf5kiowidgets5   5.86.0-1
ii  libkf5networkmanagerqt6 5.86.0-1
ii  libkf5newstuff5 5.86.0-3
ii  libkf5newstuffcore5 5.86.0-3
ii  libkf5notifications55.86.0-1
ii  libkf5notifyconfig5 5.86.0-1
ii  libkf5package5  5.86.0-1
ii  libkf5parts55.86.0-1
ii  libkf5people5   

Bug#998030: r-cran-dt: Add xdg-open app open attempts as recommended

[Steffen Moeller]

Package: r-cran-dt
Version: 0.17+dfsg-3
Severity: minor
Tags: a11y

The command 

DT::datatable(data = inputSettings,
  extensions = 'FixedColumns',
  options = list(fixedColumns = TRUE,
 scrollX = TRUE,
 pageLength = 9,
 dom = 't'))

stimulates

Set the BROWSER environment variable to your desired browser.

Warning: program returned non-zero exit code #256
/usr/bin/xdg-open: 882: www-browser: not found
/usr/bin/xdg-open: 882: links2: not found
/usr/bin/xdg-open: 882: elinks: not found
/usr/bin/xdg-open: 882: links: not found
/usr/bin/xdg-open: 882: lynx: not found
/usr/bin/xdg-open: 882: w3m: not found
xdg-open: no method available for opening 
'/tmp/RtmpGZs59M/viewhtmlba7f058dcace0/index.html'

which likely should affect the recommended packages.

Bug#998013: localslackirc: autopkgtest failure: Cannot find implementation or library stub for module named "typedload"

[Antonio Terceiro]

On Thu, Oct 28, 2021 at 03:39:25PM +0200, Paul Gevers wrote:
> Source: localslackirc
> Version: 1.13-1
> X-Debbugs-CC: debian...@lists.debian.org
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fails-always
> 
> Dear maintainer(s),
> 
> You recently added an autopkgtest to your package localslackirc, great.
> However, it fails. Currently this failure is blocking the migration to
> testing [1]. Can you please investigate the situation and fix it?
> 
> I copied some of the output at the bottom of this report. Seems your
> missing some (test) dependencies?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=localslackirc
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/l/localslackirc/15955881/log.gz
> 
> mypy --config-file mypy.conf *.py slackclient localslackirc
> slackclient/client.py:28: error: Cannot find implementation or library
> stub for module named "typedload"
> slackclient/client.py:29: error: Cannot find implementation or library
> stub for module named "websockets"
> slackclient/client.py:30: error: Cannot find implementation or library
> stub for module named "websockets.client"
> slack.py:26: error: Cannot find implementation or library stub for
> module named "typedload"
> slack.py:26: note: See
> https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
> Found 4 errors in 2 files (checked 9 source files)
> make: *** [Makefile:6: lint] Error 1
> autopkgtest [15:36:30]: test command1

Also, this test is testing the source tree and not the installed
package:

| Test-Command: make test
| Depends: mypy
| Restrictions: allow-stderr


signature.asc
Description: PGP signature

Bug#998029: RFP: flask-appbuilder -- simple and rapid application development framework

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: danielvazgas...@gmail.com, debian-pyt...@lists.debian.org

* Package name: flask-appbuilder
  Version : 3.3.4
  Upstream Author : Daniel Vaz Gaspar 
* URL : https://github.com/dpgaspar/flask-appbuilder/
* License : BSD
  Programming Lang: Python
  Description : simple and rapid application development framework

Simple and rapid application development framework, built on top of Flask.
includes detailed security, auto CRUD generation for your models, google charts
and much more. Extensive configuration of all functionality, easily integrate
with normal Flask/Jinja2 development.

Bug#958155: marked as done (please package the new version of Guake 3.7.0 and fix the debian/watchfile)

[Maarten]

Would it be possible to update the package to the bugfix release 3.8.1
please?

Thank you

kind regards,

Maarten Fonville


Op di 26 okt. 2021 om 06:21 schreef Debian Bug Tracking System <
ow...@bugs.debian.org>:

> Your message dated Tue, 26 Oct 2021 04:18:31 +
> with message-id 
> and subject line Bug#958155: fixed in guake 3.8.0-1
> has caused the Debian Bug report #958155,
> regarding please package the new version of Guake 3.7.0 and fix the
> debian/watchfile
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 958155: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958155
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "shirish शिरीष" 
> To: debian-bts 
> Cc:
> Bcc:
> Date: Sun, 19 Apr 2020 05:49:53 +
> Subject: please package the new version of Guake 3.7.0 and fix the
> debian/watchfile
> Package: guake
> Version: 3.6.3-2
> Severity: wishlist
>
> Dear Maintainer,
>
> Upstream has released guake 3.7.0. See
> https://github.com/Guake/guake/releases/tag/3.7.0
>
> While it has few fixes and things, dunno if its requirements for VTE
> and GTK has also changed or not, probably for the better. I wasn't
> able to find anything on upstream as readthedocs on guake is stale
>
>
> https://guake.readthedocs.io/en/latest/user/installing.html#install-from-source
>
> Currently what we use is -
>
> Guake not running, starting it
> Guake Terminal 3.6.3
> VTE 0.60.1
> Gtk 3.24.18
>
> This is from my .xsession-errors file, hence I know it's correct.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
> 'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
> 'experimental-debug')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
> (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages guake depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
> ii  gir1.2-glib-2.0  1.64.1-1
> ii  gir1.2-gtk-3.0   3.24.18-1
> ii  gir1.2-keybinder-3.0 0.3.2-1+b1
> ii  gir1.2-notify-0.70.7.9-1
> ii  gir1.2-pango-1.0 1.44.7-3
> ii  gir1.2-vte-2.91  0.60.1-1
> ii  gir1.2-wnck-3.0  3.36.0-1
> ii  libglib2.0-bin   2.64.1-1
> ii  libutempter0 1.1.6-5
> ii  python3  3.8.2-3
> ii  python3-cairo1.16.2-2+b1
> ii  python3-dbus 1.2.16-1
> ii  python3-gi   3.36.0-1+b1
> ii  python3-pbr  5.4.3-2
>
> guake recommends no packages.
>
> Versions of packages guake suggests:
> pn  numix-gtk-theme  
>
> -- no debconf information
>
> --
>   Regards,
>   Shirish Agarwal  शिरीष अग्रवाल
>   My quotes in this email licensed under CC 3.0
> http://creativecommons.org/licenses/by-nc/3.0/
> http://flossexperiences.wordpress.com
>
> E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 958155-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 26 Oct 2021 04:18:31 +
> Subject: Bug#958155: fixed in guake 3.8.0-1
> Source: guake
> Source-Version: 3.8.0-1
> Done: Daniel Echeverri 
>
> We believe that the bug you reported is fixed in the latest version of
> guake, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 958...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Daniel Echeverri  (supplier of updated guake package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Sat, 23 Oct 2021 18:53:10 -0500
> Source: guake
> Architecture: source
> Version: 

Bug#997876: license-expression: consider uploading 21.6.14-1 to unstable

[Sandro Tosi]

> During initial packaging I sadly messed up the correct source name of
> the package (which would be python-license-expression). The same is true
> for the package boolean.py (should be python-boolean.py).

there's absolutely no need to make such a change: those are the
upstream projects names, they dont conflict with anything currently in
debian, and they are perfectly valid source package names for the
general debian policy and the python policy too. I think this is just
busy work with 0 net gain which you can do if you want (of course) but
again is not necessarily at all, and given people are waiting on an
update, probably that's where effort should be spent.

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

Bug#994724: RFS: lebiniou-data/3.62.1-1 -- datafiles for Le Biniou

[Olivier Girondel]

Hi Adam,

Thanks for the upload of lebiniou-data !
Could you restart the test for lebiniou ?
lebiniou-data-3.62.3-1 should fix the autopkgtest regression.

Best regards,
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#998028: m2crypto: autopkgtest regression: No module named 'parameterized'

[Paul Gevers]

Source: m2crypto
Version: 0.38.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
m2crypto   from testing0.38.0-1
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/m/m2crypto/16259993/log.gz

[*] testing python3.9:
= test session starts
==
platform linux -- Python 3.9.7, pytest-6.2.5, py-1.10.0, pluggy-0.13.0
-- /usr/bin/python3.9
cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.sv_z4us_/downtmp/autopkgtest_tmp
collecting ... collected 277 items / 2 errors / 275 selected

 ERRORS

__ ERROR collecting tests/test_bio.py
__
ImportError while importing test module
'/tmp/autopkgtest-lxc.sv_z4us_/downtmp/autopkgtest_tmp/tests/test_bio.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/test_bio.py:13: in 
from parameterized import parameterized
E   ModuleNotFoundError: No module named 'parameterized'
__ ERROR collecting tests/test_evp.py
__
ImportError while importing test module
'/tmp/autopkgtest-lxc.sv_z4us_/downtmp/autopkgtest_tmp/tests/test_evp.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/test_evp.py:17: in 
from parameterized import parameterized
E   ModuleNotFoundError: No module named 'parameterized'
!!! Interrupted: 2 errors during collection

== 2 errors in 0.73s
===
autopkgtest [21:12:18]: test python3-m2crypto




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998027: rust-smallvec: autopkgtest regression: #![feature]` may not be used on the stable release channel

[Paul Gevers]

Source: rust-smallvec
Version: 1.7.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
rust-smallvec  from testing1.7.0-1
all others from testingfrom testing

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

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

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

Paul

[1] https://qa.debian.org/excuses.php?package=rust-smallvec

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-smallvec/16267456/log.gz

debian cargo wrapper: options, profiles, parallel: ['parallel=48'] []
['-j48']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
x86_64-linux-gnu
debian cargo wrapper: linking /usr/share/cargo/registry/* into
/tmp/tmp.gvwyouJS2W/registry/
debian cargo wrapper: options, profiles, parallel: ['parallel=48'] []
['-j48']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
x86_64-linux-gnu
debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1',
'/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose',
'-j48', '--target', 'x86_64-unknown-linux-gnu', '--all-targets',
'--all-features'],) {}
   Compiling serde v1.0.106
 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=build_script_build
CARGO_MANIFEST_DIR=/tmp/tmp.gvwyouJS2W/registry/serde-1.0.106
CARGO_PKG_AUTHORS='Erick Tryzelaar :David
Tolnay ' CARGO_PKG_DESCRIPTION='A generic
serialization/deserialization framework'
CARGO_PKG_HOMEPAGE='https://serde.rs' CARGO_PKG_LICENSE='MIT OR
Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=serde
CARGO_PKG_REPOSITORY='https://github.com/serde-rs/serde'
CARGO_PKG_VERSION=1.0.106 CARGO_PKG_VERSION_MAJOR=1
CARGO_PKG_VERSION_MINOR=0 CARGO_PKG_VERSION_PATCH=106
CARGO_PKG_VERSION_PRE=''
LD_LIBRARY_PATH='/tmp/tmp.gvwyouJS2W/target/debug/deps:/usr/lib' rustc
--crate-name build_script_build
/tmp/tmp.gvwyouJS2W/registry/serde-1.0.106/build.rs --error-format=json
--json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link
-Cembed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg
'feature="std"' -C metadata=9b685932cd0f7028 -C
extra-filename=-9b685932cd0f7028 --out-dir
/tmp/tmp.gvwyouJS2W/target/debug/build/serde-9b685932cd0f7028 -L
dependency=/tmp/tmp.gvwyouJS2W/target/debug/deps --cap-lints warn`
 Running
`/tmp/tmp.gvwyouJS2W/target/debug/build/serde-9b685932cd0f7028/build-script-build`
[serde 1.0.106] cargo:rustc-cfg=ops_bound
[serde 1.0.106] cargo:rustc-cfg=core_reverse
[serde 1.0.106] cargo:rustc-cfg=de_boxed_c_str
[serde 1.0.106] cargo:rustc-cfg=de_boxed_path
[serde 1.0.106] cargo:rustc-cfg=de_rc_dst
[serde 1.0.106] cargo:rustc-cfg=core_duration
[serde 1.0.106] cargo:rustc-cfg=integer128
[serde 1.0.106] cargo:rustc-cfg=range_inclusive
[serde 1.0.106] cargo:rustc-cfg=num_nonzero
[serde 1.0.106] cargo:rustc-cfg=core_try_from
[serde 1.0.106] cargo:rustc-cfg=num_nonzero_signed
[serde 1.0.106] cargo:rustc-cfg=std_atomic64
[serde 1.0.106] cargo:rustc-cfg=std_atomic
 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=serde
CARGO_MANIFEST_DIR=/tmp/tmp.gvwyouJS2W/registry/serde-1.0.106
CARGO_PKG_AUTHORS='Erick Tryzelaar :David
Tolnay ' CARGO_PKG_DESCRIPTION='A generic
serialization/deserialization framework'
CARGO_PKG_HOMEPAGE='https://serde.rs' CARGO_PKG_LICENSE='MIT OR
Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=serde
CARGO_PKG_REPOSITORY='https://github.com/serde-rs/serde'
CARGO_PKG_VERSION=1.0.106 CARGO_PKG_VERSION_MAJOR=1
CARGO_PKG_VERSION_MINOR=0 CARGO_PKG_VERSION_PATCH=106
CARGO_PKG_VERSION_PRE=''
LD_LIBRARY_PATH='/tmp/tmp.gvwyouJS2W/target/debug/deps:/usr/lib'
OUT_DIR=/tmp/tmp.gvwyouJS2W/target/x86_64-unknown-linux-gnu/debug/build/serde-800e740946d91bd8/out
rustc --crate-name serde
/tmp/tmp.gvwyouJS2W/registry/serde-1.0.106/src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi,artifacts
--crate-type lib --emit=dep-info,metadata,link -Cembed-bitcode=no -C
debuginfo=2 --cfg 'feature="default"' --cfg 'feature="std"' -C
metadata=6494c40e4cad4848 -C extra-filename=-6494c40e4cad4848 --out-dir
/tmp/tmp.gvwyouJS2W/target/x86_64-unknown-linux-gnu/debug/deps --target
x86_64-unknown-linux-gnu -L
dependency=/tmp/tmp.gvwyouJS2W/target/x86_64-unknown-linux-gnu/debug/deps -L
dependency=/tmp/tmp.gvwyouJS2W/target/debug/deps --cap-lints warn -C
debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C
link-arg=-Wl,-z,relro --remap-path-prefix

Bug#997913: OVMF-ia32 does not provide file usable by -bios

[dann frazier]

On Thu, Oct 28, 2021 at 11:19:06AM -0500, Glenn Washburn wrote:
> On Thu, 28 Oct 2021 07:46:11 -0600
> dann frazier  wrote:
> > On Tue, Oct 26, 2021 at 07:31:38PM -0500, Glenn Washburn wrote:
> > > Package: ovmf-ia32
> > > Version: 2020.11-4
> > > 
> > > Hello Maintainers,
> > > 
> > > I'd like ovmf-ia32 to install a file useable by QEMU's -bios option.
> > > Currently the package only installs OVMF32_CODE_4M.secboot.fd and
> > > OVMF32_VARS_4M.fd, but I believe I need a file that combines both code
> > > and vars. According to the wiki[1], I believe I can use the existing
> > > files using "-drive if=pflash,..." options, but that is not a great
> > > option for me.
> > 
> > Can you elaborate more on your use case? While we do provide such an
> > image for X64, that is for backwards-compatibility only.
> 
> I'm working on GRUB2's test suite and it has tests that use QEMU for
> many of its tests.

edk2's autopkgtest has a testing framework that tests OVMF32, and all
the other archs, using -pflash. It also does tests with GRUB images
(e.g. making sure signed versions work w/ SecureBoot enabled, unsigned
versions do not). Let me know if it'd be useful to collaborate on that
framework. Here's the main bit:

https://salsa.debian.org/qemu-team/edk2/-/blob/debian/debian/python/UEFI/Qemu.py

> Specifically, I need the combined firmware file when testing the
> i386-efi target.

Why? I mean, why can't that testing use a throw-away pflash image for
VARS like we do in edk2 autopkgtesting?

> Perhaps, I don't need a binary with combined code and vars. On the ARM
> and ARM64 EFI targets, I can pass the AAVMF32_CODE.fd to -bios just
> fine. So perhaps the IA32 firmware is built in such a way that the code
> file requires the vars, but could be build to not require it? IOW, why
> can't I just send the firmware CODE file to QEMU using -bios like I can
> with ARM and ARM64?

I don't know if or why OVMF*_CODE doesn't work with -bios. Separate
CODE/VARS is the most flexible build (and what people should use
in production), so that's what we provide. I'd need to be convinced
that there's a good reason to increase the size of the ovmf-ia32 deb
for all users to support -bios mode.

> Also, I  don't need the secure boot feature of the firmware. The wiki
> leaves me with the suspicion that I may need to configure some of the
> firmware variables before I can boot successfully. Perhaps that would
> only be the case if I were wanting to boot with secure boot enabled.
>
> I'm also curious about the 4M in the file name. My guess is that it
> indicates a build option. Could this be part of the equation?

Please read through the README.Debian file (latest one from
unstable). If that doesn't answer the above 2 points, let me know so I
can clarify it there.

  -dann

Bug#998012: [EXTERNAL] Bug#998012: transition: healpix-cxx

[Paul Gevers]

Hi Leo,

On 28-10-2021 15:49, Singer, Leo P. (GSFC-6610) wrote:
>> For healpy,
>> apart from the rebuild (which we can schedule), is there anything else
>> that need to happen? I assume a rebuild is all that's needed and you're
>> pointing out that you can fix issues when/if they arise.
> 
> No, no special issues with Healpy. Anyway it's looking like Healpy upstream 
> might be doing a release soon.

For avoidance of doubt, please *don't* upload new versions until the
transition is done, unless needed to finish the transition.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#998026: libmodulemd: autopkgtest fails with meson 0.60

[peter green]

Package: libmodulemd
Version: 2.12.0-1
Severity: serious

libmodulemd's autopkgtest is failing during testing migration tests
for meson 0.60

https://ci.debian.net/data/autopkgtest/testing/amd64/libm/libmodulemd/16225041/log.g

=== Running meson at the configure stage
The Meson build system
Version: 0.60.0
Source dir: /tmp/autopkgtest-lxc.2w0c9jq6/downtmp/build.Zb0/src
Build dir: /tmp/autopkgtest-lxc.2w0c9jq6/downtmp/build.Zb0/src/build
Build type: native build

meson.build:12:0: ERROR: Unknown options: "developer_build"


It looks like with the previous version of meson this was only a warning
rather than an error.

https://ci.debian.net/data/autopkgtest/testing/amd64/libm/libmodulemd/16197315/log.gz

Bug#997990: tornado worker does not work with Tornado 6

[Chris Lamb]

Hi Enrico,

> thank you for maintaining gunicorn!

Thanks for filing #997990 and #997992 for issues in gunicorn. As it
happens, though, I am no longer using the Debian package of gunicorn
and, as such, I wonder if it makes more sense for someone else to take
over maintainership. At the very least, this will ensure that fixes
for these two issues can reliably tested.

Would this new maintainer be, perhaps, you? :)


Regards,

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

Bug#997089: libreoffice: FTBFS: segfault in '/<>/instdir/sdk/examples/java/Inspector'

[Rene Engelhard]

Hi again,

Am 28.10.21 um 18:11 schrieb Rene Engelhard:
> Am 23.10.21 um 18:41 schrieb Lucas Nussbaum:
>> [...]

>> "/<>/instdir/program/unopkg" add -f
>> "/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/bin/Inspector.oxt"
>>
>>> Segmentation fault (core dumped)
>>> make[5]: *** [Makefile:168: 
>>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector/java_Inspector_register_component.flag]
>>>  Error 139
> Jup. Seeing this in a master build, too :(
>
>
> Incidentially this worked fine until the day before you filed the 
> bugreport. Also interestingly, in a clean chroot the
> odk-build-examples-java test (which does the exact thing as above)
> _does_ pass..

And interestingly, (after rm'ing the stale unopkg lockfile..) it passed.

Also after a new attempt with manual

$ make clean && make subsequencheck

in odk worked, too.


Just looks like a flaky test... (Even though I saw it the first time
here with this report..)


Regards,


Rene

Bug#998017: pkg-config: Build a library with its own .pc file

[Alejandro Colomar (man-pages)]

On 10/28/21 16:48, Alejandro Colomar wrote:

To build (link) a library, I have the following in my Makefile:

PC_ENV := PKG_CONFIG_PATH=lib/pkgconfig
req_pc := $(shell $(PC_ENV) pkg-config --print-requires-private libfoo)
LIBS := -L$(builddir)
LIBS += $(shell $(PC_ENV) pkg-config --libs libfoo)
LIBS += $(shell $(PC_ENV) pkg-config --libs $(req_pc))

However, I noticed today that I was missing the information in Libs.private
from my .pc file.  But I don't want to invoke '--static --libs', since that
would pull the Libs.private from all my dependencies, which I don't need.

So I need to extract those with sed.  But pkg-config could (and I think
should) do that.

To mirror cc syntax, where -static means link an executable against
static libraries, but -shared means build a shared library,
I think the best syntax for pkg-config would be to add a --shared flag.
For pkg-config, --static would be used for linking an executable against
a static library, and --shared would be used to build a shared object.

So, the following lines should be enough to pull all libs necessary for
building the shared object corresponding to a given .pc file:

PC_ENV := PKG_CONFIG_PATH=lib/pkgconfig
LIBS := $(shell $(PC_ENV) pkg-config --shared --libs libfoo)


So, that should be equivalent to:

PC_ENV := PKG_CONFIG_PATH=lib/pkgconfig
req_pc := $(shell $(PC_ENV) pkg-config --print-requires-private libfoo)
LIBS := -L$(builddir)
LIBS += $(shell $(PC_ENV) pkg-config --libs libfoo)
LIBS += $(shell $(PC_ENV) pkg-config --libs $(req_pc) 2>/dev/null)
LIBS += $(shell sed -n '/^Libs.private: /s///p' 
lib/pkgconfig/libfoo-uninstalled.pc)



--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Bug#997908: pocl: Assertion `td->printf_buffer != NULL' failed on armel/armhf

[Andreas Beckmann]

On 26/10/2021 23.29, Rebecca N. Palmer wrote:
(Filing this as something to refer to when I disable those tests; it may 
or may not actually be worth fixing.)


Let me try to figure out why this happens ...

Since some time in August, all the packages that use pocl for their 
autopkgtests have been failing on armel/armhf (but not arm64) with either

Assertion `td->printf_buffer != NULL' (libgpuarray, theano, examl)
or
Fatal Python error: Aborted (pyopencl, gpyfft).


I'm trying to reproduce this ...

Using theano since it shows the error you reported:
https://ci.debian.net/data/autopkgtest/testing/armhf/t/theano/16143356/log.gz

python3: ./lib/CL/devices/pthread/pthread_scheduler.c:512: 
pocl_pthread_driver_thread: Assertion `td->printf_buffer != NULL' failed.


On the armhf porter box abel.d.o in a sid chroot:

* install python3-theano g++ python3-pydot python3-nose 
python3-parameterized python3-pkg-resources cython3 graphviz 
pocl-opencl-icd python3-pygpu libclblast-dev libgpuarray-dev

* export AUTOPKGTEST_TMP=$(mktemp -d)
* apt-get source theano
* cd theano-1.0.5+dfsg/
* debian/tests/smoketestgpu
usr/lib/python3/dist-packages/theano/gpuarray/__init__.py:86: 
UserWarning: Theano's OpenCL support is incomplete and may contain bugs 
(some tests fail)
  warnings.warn("Theano's OpenCL support is incomplete and may contain 
bugs (some tests fail)")

Mapped name None to device opencl0:0: pthread-0x584
WARNING (theano.bin.theano-nose): KnownFailure plugin from NumPy could 
not be imported. Use --without-knownfailure to disable this warning.
test_adv_sub_slice 
(theano.gpuarray.tests.test_subtensor.G_advancedsubtensor) ... ok

theano.gpuarray.tests.test_rng_mrg.test_GPUA_full_fill ... ok

--
Ran 2 tests in 71.174s

OK

I'm similarily unable to reproduce the errors with libgpuarray or 
pyopencl, didn't try further.


Is there something "special" about the autopkgtest environment that 
differs from a plain chroot?



However, build-time tests using it (pocl itself, pyopencl) pass.


Then we have to add more ;-)
But for that, I would need to be able to reproduce this somehow s.t. I 
can reduce it to a plain C test in pocl.


Let me look at the code

  td->printf_buffer = pocl_aligned_malloc (MAX_EXTENDED_ALIGNMENT,
   scheduler.printf_buf_size);
  assert (td->printf_buffer != NULL);

So we are somehow out of memory ...

The default size is 16 MB. Per thread. This is also what clinfo reports 
in the pocl build time tests. This was also the setting in pocl 1.6

Is the autopkgtest environment extremely memory constrained?
Is the test so memory hungry that it does not leave anything for pocl?

You could prepend a call to clinfo (and maybe ulimit -a) to the 
autopkgtest scripts ...

Do the tests pass with POCL_DEVICES=basic?

Just tried again on abel while reducing the memory size with ulimit -m 
and ulimit -v ... at some point I run into python backtraces, but not 
the exact error you saw.



Andreas

Bug#992743: RFP: furo -- clean customisable Sphinx documentation theme

[Andrey Rahmatullin]

Control: noowner -1
Control: retitle -1 RFP: furo -- clean customisable Sphinx documentation theme


I've made a bunch of RFPs for NodeJS things required to build the CSS
files here. It doesn't look possible to get these deps into Debian in
reasonable time (some of them even use Dart).

Note that the PyPI tarball contains pre-built CSS files instead of their
sources. As far as I understand we can't use those until all of their
build tools are in main.

My initial packaging is at
https://salsa.debian.org/python-team/packages/python-furo

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#996670: libkdecorations2-5v5 migrated to testing too early breaking Plasma

[René Lagoni Neukirch]

  
  
OK, if you cannot tell when - that is OK.

But HOW do we get to know when the fixes (semm to be plenty) are
released to bookworm ???

/René

On Sat, 23 Oct 2021 15:57:47 +0200 Chris Nospam
 wrote:
> KDE/Plasma (package dependencies) are currently completely
broken under testing. Is there currently a chance to (somehow
simply) block the partial transition of plasma 5.23 to testing (so
that not related package updates are easy)? Selectively upgrading
single packages with dependencies one after the other from the mass
provided in testing is rather cumbersome.
> 
> Currently I get the following (sorry for the german locale):
> 
> root@xxx:~# apt-get dist-upgrade
> Paketlisten werden gelesen… Fertig
> Abhängigkeitsbaum wird aufgebaut… Fertig
> Statusinformationen werden eingelesen… Fertig
> Paketaktualisierung (Upgrade) wird berechnet… Fertig
> Die folgenden NEUEN Pakete werden installiert:
> libkdecorations2private9
> Die folgenden Pakete werden aktualisiert (Upgrade):
> bluedevil breeze breeze-cursor-theme breeze-gtk-theme drkonqi
> kactivitymanagerd kde-config-gtk-style kde-config-sddm
kde-config-updates
> kde-style-breeze kgamma5 kinfocenter kmenuedit kscreen
ksshaskpass
> kwayland-integration kwin-style-breeze kwrited
libkdecorations2-5v5
> libkf5screen-bin libkf5screen7 libpam-kwallet-common
libpam-kwallet5 milou
> oxygen-sounds plasma-discover plasma-discover-common
plasma-disks
> plasma-integration plasma-pa polkit-kde-agent-1
> 31 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht
aktualisiert.
> Es müssen 96,2 MB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 47,1 MB Plattenplatz zusätzlich
benutzt.
> Möchten Sie fortfahren? [J/n] n
> Abbruch.
> 
> All packages shown above are from version 4:5.23.0 whereas the
others would stay on 4:5.21.x. Unfortunately, it is not sufficient
to set libkdecorations2-5v5 on hold, as it would remove
plasma-desktop:
> 
> root@xxx:~# apt-mark hold libkdecorations2-5v5
> libkdecorations2-5v5 auf Halten gesetzt.
> root@xxx:~# apt-get dist-upgrade
> Paketlisten werden gelesen… Fertig
> Abhängigkeitsbaum wird aufgebaut… Fertig
> Statusinformationen werden eingelesen… Fertig
> Paketaktualisierung (Upgrade) wird berechnet… Fertig
> Die folgenden Pakete wurden automatisch installiert und werden
nicht mehr benötigt:
> accountsservice apt-config-icons-hidpi apt-config-icons-large
> apt-config-icons-large-hidpi bluedevil bluez bluez-obexd
breeze-gtk-theme
> bup bup-doc gtk2-engines-pixbuf ibus-data ieee-data
kde-config-gtk-style
> kde-config-sddm kde-config-updates kgamma5 khotkeys
khotkeys-data
> kinfocenter kmenuedit kscreen kup-backup kwrited
libaccountsservice0
> libibus-1.0-5 libkpmcore11 libqt5designer5 libqt5help5
libscim8v5
> libxcb-record0 oxygen-sounds par2 partitionmanager
plasma-desktop-data
> plasma-discover plasma-discover-common plasma-disks
python3-fuse
> python3-pylibacl python3-pyqt5 python3-pyqt5.sip
python3-pyxattr
> python3-software-properties python3-tornado
qml-module-org-kde-activities
> qml-module-org-kde-kcm qml-module-org-kde-kitemmodels
smartmontools
> software-properties-common software-properties-kde
systemsettings
> xsettings-kde
> Verwenden Sie »apt autoremove«, um sie zu entfernen.
> Die folgenden Pakete werden ENTFERNT:
> kde-plasma-desktop plasma-desktop
> Die folgenden Pakete sind zurückgehalten worden:
> breeze breeze-cursor-theme kde-config-gtk-style
kde-style-breeze
> kwin-style-breeze libkdecorations2-5v5 plasma-integration
> Die folgenden Pakete werden aktualisiert (Upgrade):
> bluedevil breeze-gtk-theme drkonqi kactivitymanagerd
kde-config-sddm
> kde-config-updates kgamma5 kinfocenter kmenuedit kscreen
ksshaskpass
> kwayland-integration kwrited libkf5screen-bin libkf5screen7
> libpam-kwallet-common libpam-kwallet5 milou oxygen-sounds
plasma-discover
> plasma-discover-common plasma-disks plasma-pa
polkit-kde-agent-1

-- 
Med venlig hilsen/kind regards

René Lagoni Neukirch
Højenhald 1, 2. th
2700 Brønshøj
Mob. 2093 1904
  

Bug#993678: Fails to produce PDF output when using scale.by.width - produces broken lstlisting/lstcode options

[Raphael Hertzog]

Control: tags -1 + patch

Le samedi 04 septembre 2021, Daniel Leidert a écrit :
> While building a PDF we stumbled upon an issue. Some of our XML files contain
> screen elements with non UTF-8 characters. When we enable scaling for listing
> elements:
> 
> scale.by.width
> 
> dblatex fails. The produced .tex files then contain line such as:
> 
> \begin{lstcode}[escapeinside={<:}{:>}][scale=false,firstnumber=1,escapeinside={}{},moredelim={**[is][\bfseries]{}{}},moredelim={**[is][\itshape]{}{}},]

Upstream has provided a patch in 
https://sourceforge.net/p/dblatex/bugs/_discuss/thread/6efb34bd22/7a8a/attachment/rawverb.patch

Can you test it and report back whether it helps? If you can send your
feedback directly to upstream that would be great:
https://sourceforge.net/p/dblatex/bugs/129/

Thank you in advance.
-- 
Raphaël Hertzog

Bug#998024: RFP: node-sass -- The reference implementation of Sass, written in Dart

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Control: block 992743 by -1

* Package name: node-sass
  Version : 1.43.4
  Upstream Author : Natalie Weizenbaum 
* URL : https://github.com/sass/dart-sass
* License : MIT
  Programming Lang: Dart
  Description : The reference implementation of Sass, written in Dart

This is a build-dep of furo.

Bug#993928: genius: depends on amtk which has been abandoned upstream

[Patrice Duroux]

By the way release 1.0.27 seems to address this:
https://www.jirka.org/genius.NEWS
* Remove dependence on AMTK

But it may be something that is already known! ;-)

Patrice

On Wed, 8 Sep 2021 10:08:18 +0100 Simon McVittie  wrote:
> Source: genius
> Version: 1.0.25-2
> Severity: important
> Tags: upstream
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs unmaintained-upstream
> Control: block 993922 by -1
> 
> amtk has been frozen and archived upstream, and contributions are no longer
> accepted. See https://gitlab.gnome.org/Archive/amtk and
> https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/564 for
> more details.
> 
> The versions of gedit and devhelp on GNOME infrastructure stopped using
> amtk at the same time they stopped using tepl, which is in a similar
> situation (see #993909). I don't think amtk should be included in Debian 12.
> 
> The remaining packages that use amtk (genius, goodvibes and gyrus) will
> either need to stop using amtk (and switch to making the same calls into
> GTK that amtk does, but more directly), or fork it. If they fork it,
> the former maintainer requests that they use a different name.
> 
> smcv
> 
> 

Bug#998023: RFP: node-gulp-uglify -- Minify files with UglifyJS

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Control: block 992743 by -1

* Package name: node-gulp-uglify
  Version : 3.0.2
  Upstream Author : Terin Stock 
* URL : https://github.com/terinjokes/gulp-uglify
* License : MIT
  Programming Lang: JavaScript
  Description : Minify files with UglifyJS

This is a build-dep of furo.

Bug#998022: RFP: node-postcss-easy-import -- PostCSS plugin to inline @import rules content with extra features

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Control: block 992743 by -1

* Package name: node-postcss-easy-import
  Version : 3.0.0
  Upstream Author : Bogdan Chadkin 
* URL : https://github.com/TrySound/postcss-easy-import
* License : MIT
  Programming Lang: JavaScript
  Description : PostCSS plugin to inline @import rules content with extra
features

This is a build-dep of furo.

Bug#998021: RFP: node-cssnano -- A modular minifier, built on top of the PostCSS ecosystem

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Control: block 992743 by -1

* Package name: node-cssnano
  Version : 5.0.8
  Upstream Author : Ben Briggs 
* URL : https://github.com/cssnano/cssnano
* License : MIT
  Programming Lang: JavaScript
  Description : A modular minifier, built on top of the PostCSS ecosystem

cssnano is a modern, modular compression tool written on top of the PostCSS
ecosystem, which allows us to use a lot of powerful features in order to
compact CSS appropriately.

Our preset system allow you to load cssnano in a different configuration
depending on your needs; the default preset performs safe transforms, whereas
the advanced preset performs more aggressive transforms that are safe only when
your site meets the requirements; but regardless of the preset you choose, we
handle more than whitespace transforms!

This is a build-dep of furo.

Bug#998019: ITP: golang-github-go-kit-log -- minimal and extensible structured logger

[Benjamin Drung]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name    : golang-github-go-kit-log
  Version : 0.2.0-1
  Upstream Author : Go kit
* URL : https://github.com/go-kit/log
* License : Expat
  Programming Lang: Go
  Description : minimal and extensible structured logger (Go library)

 The log package provides a minimal interface for structured logging in
 services. It may be wrapped to encode conventions, enforce type-safety,
 provide leveled logging, and so on. It can be used for both typical
 application log events, and log-structured data streams.
 .
 Structured logging is, basically, conceding to the reality that logs are data,
 and warrant some level of schematic rigor. Using a stricter,
 key/value-oriented message format for our logs, containing contextual and
 semantic information, makes it much easier to get insight into the operational
 activity of the systems we build. Consequently, package log is of the strong
 belief that "the benefits of structured logging outweigh the minimal effort
 involved (https://www.thoughtworks.com/radar/techniques/structured-logging)".

This library was split from golang-github-go-kit-kit and is used by
Prometheus node exporter.

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#998020: RFP: node-gulp-postcss -- PostCSS gulp plugin to pipe CSS through several plugins, but parse CSS only once

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Control: block 992743 by -1

* Package name: node-gulp-postcss
  Version : 9.0.1
  Upstream Author : Andrey Kuzmin 
* URL : https://github.com/postcss/gulp-postcss
* License : MIT
  Programming Lang: JavaScript
  Description : PostCSS gulp plugin to pipe CSS through several plugins,
but parse CSS only once


This is a build-dep of furo.

Bug#997913: OVMF-ia32 does not provide file usable by -bios

[Glenn Washburn]

On Thu, 28 Oct 2021 07:46:11 -0600
dann frazier  wrote:

> severity 997913 wishlist
> thanks
> 
> On Tue, Oct 26, 2021 at 07:31:38PM -0500, Glenn Washburn wrote:
> > Package: ovmf-ia32
> > Version: 2020.11-4
> > 
> > Hello Maintainers,
> > 
> > I'd like ovmf-ia32 to install a file useable by QEMU's -bios option.
> > Currently the package only installs OVMF32_CODE_4M.secboot.fd and
> > OVMF32_VARS_4M.fd, but I believe I need a file that combines both code
> > and vars. According to the wiki[1], I believe I can use the existing
> > files using "-drive if=pflash,..." options, but that is not a great
> > option for me.
> 
> Can you elaborate more on your use case? While we do provide such an
> image for X64, that is for backwards-compatibility only.

I'm working on GRUB2's test suite and it has tests that use QEMU for
many of its tests. Specifically, I need the combined firmware file when
testing the i386-efi target. 

Perhaps, I don't need a binary with combined code and vars. On the ARM
and ARM64 EFI targets, I can pass the AAVMF32_CODE.fd to -bios just
fine. So perhaps the IA32 firmware is built in such a way that the code
file requires the vars, but could be build to not require it? IOW, why
can't I just send the firmware CODE file to QEMU using -bios like I can
with ARM and ARM64?

Also, I  don't need the secure boot feature of the firmware. The wiki
leaves me with the suspicion that I may need to configure some of the
firmware variables before I can boot successfully. Perhaps that would
only be the case if I were wanting to boot with secure boot enabled.

I'm also curious about the 4M in the file name. My guess is that it
indicates a build option. Could this be part of the equation?

Glenn

Bug#666772: Bug 666772

[Vasyl Gello]

Hi Johannes!

Thanks for clarification! So I have to ask maintainers of groovy:all and 
libcommons-lang-java:all whether they are OK marking it M-A: foreign?

Also, why does apt-get install all arch:host build-deps but not libdevel:host 
duplicated with libdevel:build ?

Is it possible at all to have "pure" cross-compilation without need to install 
qemu-binfmt-support on host?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#997089: libreoffice: FTBFS: segfault in '/<>/instdir/sdk/examples/java/Inspector'

[Rene Engelhard]

[ sorry for the late answer, needed to get a new laptop as the battery
broke badly.. ]

Hi,

Am 23.10.21 um 18:41 schrieb Lucas Nussbaum:
> make[5]: Entering directory
> '/<>/instdir/sdk/examples/java/Inspector'
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector
>> "/<>/instdir/sdk/bin/idlc" -C -I. -I../../../idl 
>> -O/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector
>>  InstanceInspector.idl
>> Compiling: InstanceInspector.idl
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector
>> "/<>/instdir/sdk/bin/idlc" -C -I. -I../../../idl 
>> -O/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector
>>  XInstanceInspector.idl
>> Compiling: XInstanceInspector.idl
>> rm -f 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector/Inspector.uno.rdb
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector
>> "/<>/instdir/program/regmerge" 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector/Inspector.uno.rdb
>>  /UCR 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/InstanceInspector.urd
>>  
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/XInstanceInspector.urd
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/org/openoffice
>> "/<>/instdir/sdk/bin/javamaker" -nD 
>> -Torg.openoffice.InstanceInspector  -Torg.openoffice.XInstanceInspector  
>> -O/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector
>>  
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector/Inspector.uno.rdb
>>  -X"/<>/instdir/program/types.rdb" 
>> -X"/<>/instdir/program/types/offapi.rdb"
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/org/openoffice
>> "/<>/instdir/sdk/bin/javamaker" -nD 
>> -Torg.openoffice.InstanceInspector  -Torg.openoffice.XInstanceInspector  
>> -O/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector
>>  
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector/Inspector.uno.rdb
>>  -X"/<>/instdir/program/types.rdb" 
>> -X"/<>/instdir/program/types/offapi.rdb"
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>> "/usr/lib/jvm/default-java/bin/javac"  -classpath 
>> "/<>/instdir/program/classes/libreoffice.jar:/<>/instdir/program/classes/unoloader.jar::/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector:/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector"
>>  -sourcepath . -d 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>>  XDialogProvider.java
>> Note: ./MethodParametersDialog.java uses unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>> "/usr/lib/jvm/default-java/bin/javac"  -classpath 
>> "/<>/instdir/program/classes/libreoffice.jar:/<>/instdir/program/classes/unoloader.jar::/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector:/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector"
>>  -sourcepath . -d 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>>  XTreeControlProvider.java
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>> "/usr/lib/jvm/default-java/bin/javac"  -classpath 
>> "/<>/instdir/program/classes/libreoffice.jar:/<>/instdir/program/classes/unoloader.jar::/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector:/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector"
>>  -sourcepath . -d 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>>  XTreePathProvider.java
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>> 

Bug#998008: libc-bin: postinst makes a working NIS system not to work anymore at every point release

[José Trujillo Carmona]

Para evitar que pille de improviso a alguien, he actualizado todos los 
equipos (de salma) a 11.1 copiados en todos el archivo nsswitch.conf ya 
modificado de salma1


Mañana lo haré con Estadística.

salma ya son 21, puedes cambiarlo donde convenga para que ansible 
funcione. Ahora voy a avisar a Juan Ma


Gracias.

Un saludo.

El 28/10/21 a las 15:18, Santiago Vila escribió:

Package: libc-bin
Version: 2.31-13+deb11u2
Severity: serious
Tags: patch

Dear libc-bin maintainers:

In Debian 11, the default /etc/nsswitch.conf file has now "files"
instead of the traditional "compat".

So far, so good. This is documented in Release Notes, and those who
need NIS may change /etc/nsswitch.conf if they need it.

But there is a problem: The postinst updates the file every time
it is detected that it matches *any* old default (via md5sum).

This is a functionality which was part of base-files in the past and
it was useful when there was a default /etc/nsswitch.conf which
would work for almost everybody. But this is not the case anymore,
because the default file is not good for those using NIS.

As a result, not only upgrading a Debian 10 system to Debian 11 makes
NIS to require an adjustment (i.e. putting compat again after postinst
modifies the file), but also each and every upgrade from Debian 11
point x to Debian 11 point x+1.

Patch attached. I hope this may be fixed for Debian 11.2.

Thanks.

Bug#992743: RFP: furo -- clean customisable Sphinx documentation theme

[Andrey Rahmatullin]

This is also needed for the new sybil release.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#675748: Where is the show command?

[David Kalnischkies]

Hi,

On Fri, Oct 22, 2021 at 02:12:52PM -0400, Kyle Lyon wrote:
> I am working on it at home. Wondering how I can submit it once I have

You have multiple options ranging from "just" attaching a patch here in
the BTS to making a merge request on Salsa: 
https://salsa.debian.org/apt-team/apt
(Make a fork, do your thing, commit to a branch and push that branch to
 your fork – the push will have an URI you can use to open a merge
 request).


> Where is the show command located? The dumpavail function is inside of
> apt-main/cmdline/aptcache.cc, so where is the show command?

The dumpavail lives in /path/to/apt/cmdline/apt-cache.cc as it is
available only in apt-cache. apt & apt-cache share the code for the show
command (among other things), so it is in our private library in the
file /path/to/apt/apt-private/private-show.cc.


I am not quite sure what the semantics of dumpavail should be through.
The bug asks for a restoration of a behaviour from a decade ago – so
chances are for better or worse that others expect it to behave the way
it does now considering the old-soon-to-be-new behaviour a bug.

Who are the users of the command anyway? The bugreport has only
a dselect user who likes to grep in the available file. Has the former
even any users left now that it isn't really developed anymore for years
and lacks support for multi-arch and co? The later at least should be
equally or better served by using intended interfaces like 'apt search'.


Deprecating and dropping dumpavail might be a bit too heretic, but
I think before this is (intentionally) changed one way or the other
someone (aka not me) should look into who are the (remaining) users and
what they are expecting… the produced output reaches epic proportions
already (on my system: 162 MB) and that won't be less if we add more…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#996998: libconfig-model-dpkg-perl: scan-copyrights fails for package rust-coreutils

[Dominique Dumont]

On Thursday, 28 October 2021 08:32:02 CEST you wrote:
> Thanks for checking. Please could you try with the sources from
> https://packages.debian.org/experimental/rust-coreutils

I've got no crash with libconfig-model-dpkg-perl 2.153.

Although I see a lot of entries with unknown licenses:

Files: src/uucore/src/lib/features/process.rs
Copyright: Maciej Dziardziel  / Jian Zeng 
License: UNKNOWN

Files: src/uucore/src/lib/features/signals.rs
Copyright: Maciej Dziardziel 
License: UNKNOWN

Files: src/uucore/src/lib/features/wide.rs
Copyright: Peter Atashian 
License: UNKNOWN

Files: src/uucore/src/lib/mods/*
Copyright: Rolf Morel 
License: UNKNOWN

I need to check whether all toml files are parsed, or just the top level one.

In any case, you need to upgrade libconfig-model-dpkg-perl

All the best

Bug#998018: atril: does not support PDF bookmarks encoded in UTF-16

[Vincent Lefevre]

Package: atril
Version: 1.24.0-1+b1
Severity: normal

Most bookmarks from

  http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf

appear as "þÿ" (see attached png file), which is actually
U+FEFF ZERO WIDTH NO-BREAK SPACE, i.e. the BOM in UTF-16BE,
interpreted as ISO-8859-1.

"pdftk n2731.pdf dump_data" seems to handle that correctly,
e.g.

  BookmarkBegin
  BookmarkTitle: 1 Scope
  BookmarkLevel: 1
  BookmarkPageNumber: 17

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

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

Versions of packages atril depends on:
ii  atril-common 1.24.0-1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  libatk1.0-0  2.36.0-2
ii  libatrildocument31.24.0-1+b1
ii  libatrilview31.24.0-1+b1
ii  libc62.32-4
ii  libcaja-extension1   1.24.0-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-3
ii  libgtk-3-0   3.24.30-3
ii  libice6  2:1.0.10-1
ii  libsecret-1-00.20.4-2
ii  libsm6   2:1.2.3-1
ii  libxml2  2.9.12+dfsg-5
ii  shared-mime-info 2.0-1

Versions of packages atril recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-3
ii  dbus-x11 [dbus-session-bus]   1.12.20-3
ii  gvfs  1.48.1-2

Versions of packages atril suggests:
pn  caja  
ii  poppler-data  0.4.11-1
pn  unrar 

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#537358: (no subject)

[Paulo]

Sent from vivo smartphone

Bug#997976: podman suggests iptables, but "podman run" does not appear to work without it

[Reinhard Tartler]

Hi Ian,

Thank you for reaching out.

On Thu, Oct 28, 2021 at 1:39 AM Ian Wienand  wrote:

>
>
> ---
> 2021-10-28 03:35:56.042 | ++ podman run -d dib-work-image /bin/sh
> 2021-10-28 03:35:56.241 | time="2021-10-28T03:35:56Z" level=error
> msg="error
> loading cached network config: network \"podman\" not found in CNI cache"
> 2021-10-28 03:35:56.241 | time="2021-10-28T03:35:56Z" level=warning
> msg="falling back to loading from existing plugins on disk"
> 2021-10-28 03:35:56.249 | time="2021-10-28T03:35:56Z" level=error
> msg="Error
> tearing down partially created network namespace for container
> a7a992e5399d8a8537d945684ac5193b762b2dbf18f29cd3aa724c389158fb65: error
> removing pod cool_almeida_cool_almeida from CNI network \"podman\": could
> not
> initialize iptables protocol 0: exec: \"iptables\": executable file not
> found
> in $PATH"
> 2021-10-28 03:35:56.262 | Error: error configuring network namespace for
> container a7a992e5399d8a8537d945684ac5193b762b2dbf18f29cd3aa724c389158fb65:
> error adding pod cool_almeida_cool_almeida to CNI network "podman": failed
> to
> locate iptables: exec: "iptables": executable file not found in $PATH
> ---
>

podman itself does not invoke iptables or nft directly, but uses
so-call CNI Plugins for setting up the networking. The code for this
can be seen at
https://github.com/containers/podman/blob/main/libpod/networking_linux.go

I'm not super familiar with those CNI plugins and how podman interacts with
them
in detail. May I ask you to create a new issue upstream
https://github.com/containers/podman/issues/new and
mention me with @siretart in the message? -- I'd like to hear
upstream's opinion on this.

Cheers!
-rt

Bug#666772: Bug 666772

[Johannes Schauer Marin Rodrigues]

Quoting Vasyl Gello (2021-10-28 16:10:38)
> I was trying to cross-compile Kodi for armhf on amd64 and noticed that
> apt-get treats arch:all build-dependencies as arch:native and fails to find
> them.

Good. That behaviour is by design and not a bug.

> Furthermore, packages providing the implementation of virtual packages from
> Build-Depends list (aka "Reverse Provides") are treated the same way.

Good.

> Since Wookey vetted Steve's apt-get patch I decided to work around this bug
> in pbuilder-satisfydepends-apt and filed the MR#20 on Salsa:
> https://salsa.debian.org/pbuilder-team/pbuilder/-/merge_requests/20

This is not a bug. Architecture:all packages are *not* implicitly M-A:foreign.
See my other mail to this bug. If an Architecture:all package should be made
M-A:foreign, then file a bug against that package. The maintainer can then
decide whether that marking is correct or not. If in doubt, CC
debian-cr...@lists.debian.org to get advice about whether marking a package as
M-A:foreign is correct or not.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#998017: pkg-config: Build a library with its own .pc file

[Alejandro Colomar]

Package: pkg-config
Version: 0.29.2-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear Maintainer,

I'm building a library with its own pkg-config file.
That avoids repeating the information in the .pc file again in the Makefile.
And it also avoids releasing broken .pc files; if the .pc file was incorrect,
my library simply wouldn't build.

However, there's no easy way to do that (and I found today the source of a
bug in my build system due to a missing line).  It would be easier if
pkg-config allowed that in a simple manner.

To build (link) a library, I have the following in my Makefile:

PC_ENV := PKG_CONFIG_PATH=lib/pkgconfig
req_pc := $(shell $(PC_ENV) pkg-config --print-requires-private libfoo)
LIBS := -L$(builddir)
LIBS += $(shell $(PC_ENV) pkg-config --libs libfoo)
LIBS += $(shell $(PC_ENV) pkg-config --libs $(req_pc))

However, I noticed today that I was missing the information in Libs.private
from my .pc file.  But I don't want to invoke '--static --libs', since that
would pull the Libs.private from all my dependencies, which I don't need.

So I need to extract those with sed.  But pkg-config could (and I think
should) do that.

To mirror cc syntax, where -static means link an executable against
static libraries, but -shared means build a shared library,
I think the best syntax for pkg-config would be to add a --shared flag.
For pkg-config, --static would be used for linking an executable against
a static library, and --shared would be used to build a shared object.

So, the following lines should be enough to pull all libs necessary for
building the shared object corresponding to a given .pc file:

PC_ENV := PKG_CONFIG_PATH=lib/pkgconfig
LIBS := $(shell $(PC_ENV) pkg-config --shared --libs libfoo)


Thanks,

Alex


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
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 pkg-config depends on:
ii  libc6 2.32-4
ii  libdpkg-perl  1.20.9
ii  libglib2.0-0  2.70.0-3

pkg-config recommends no packages.

Versions of packages pkg-config suggests:
ii  dpkg-dev  1.20.9

-- no debconf information

Bug#996154: obexftp: FTBFS with ruby3.0: ld: final link failed: bad value

[Lucas Kanashiro]

As a note this bug is not related to ruby3.0, obexftp already FTBFS in 
unstable. Upstream seems dead, the last commit was from more than 3 
years ago and we have released the same version since old-old-stable. 
Moreover, this package is orphan, so I believe this is a good candidate 
for removal.


--
Lucas Kanashiro

Bug#997968: kde-config-sddm: SDDM Background is set incorrect (filename only, without path)

[Michael Musenbrock]

Package: kde-config-sddm
Followup-For: Bug #997968

Hi Patrick,

thanks for that hint, I may got mislead by this and the case, that if I re-open 
the SDDM settings
and click 'Change Background' the default? image gets shown and not the 
currently configured one.

So I think this report should be closed, and I will check again for the wrong 
image shown in the
'Change Background'-window. And report this issue separately.

PS: And setting a full path is even harmful, as the source background file is 
deleted from the
filesystem once it is changed to another file.

br m


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

Kernel: Linux 5.14.0-3-amd64 (SMP w/16 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 kde-config-sddm depends on:
ii  libc6   2.32-4
ii  libkf5archive5  5.86.0-1
ii  libkf5authcore5 5.86.0-1
ii  libkf5configcore5   5.86.0-1
ii  libkf5configgui55.86.0-1
ii  libkf5coreaddons5   5.86.0-1
ii  libkf5i18n5 5.86.0-1
ii  libkf5kcmutils5 5.86.0-1
ii  libkf5quickaddons5  5.86.0-1
ii  libkf5widgetsaddons55.86.0-1
ii  libqt5core5a5.15.2+dfsg-12
ii  libqt5gui5  5.15.2+dfsg-12
ii  libqt5qml5  5.15.2+dfsg-8
ii  libqt5widgets5  5.15.2+dfsg-12
ii  libstdc++6  11.2.0-10
ii  qml-module-qtquick-layouts  5.15.2+dfsg-8
ii  qml-module-qtquick2 5.15.2+dfsg-8

kde-config-sddm recommends no packages.

kde-config-sddm suggests no packages.

-- no debconf information

Bug#998016: liburdfdom-tools3.0: missing Breaks+Replaces: liburdfdom-tools (<< 3)

[Andreas Beckmann]

Package: liburdfdom-tools3.0
Version: 3.0.0+ds-1
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 .../liburdfdom-tools3.0_3.0.0+ds-1_amd64.deb ...
  Unpacking liburdfdom-tools3.0 (3.0.0+ds-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/liburdfdom-tools3.0_3.0.0+ds-1_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/check_urdf', which is also in package 
liburdfdom-tools 1.0.4+ds-5
  Errors were encountered while processing:
   /var/cache/apt/archives/liburdfdom-tools3.0_3.0.0+ds-1_amd64.deb


cheers,

Andreas


liburdfdom-tools=1.0.4+ds-5_liburdfdom-tools3.0=3.0.0+ds-1.log.gz
Description: application/gzip

Bug#666772: Bug 666772

[Vasyl Gello]

Dear colleagues,

Nine years after this bug had last activity upon I hit it :)

I was trying to cross-compile Kodi for armhf on amd64 and noticed that apt-get 
treats arch:all build-dependencies as arch:native and fails to find them.
Furthermore, packages providing the implementation of virtual packages from 
Build-Depends list (aka "Reverse Provides") are treated the same way.

Since Wookey vetted Steve's apt-get patch I decided to work around this bug in 
pbuilder-satisfydepends-apt and filed the MR#20 on Salsa:
https://salsa.debian.org/pbuilder-team/pbuilder/-/merge_requests/20

I tested that one building Kodi, its addons and several other random packages.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#987379: llvm-toolchain-11 autopkgtest segfaults on armhf

[Julien Cristau]

On Tue, Oct 26, 2021 at 04:14:35PM +0200, Paul Gevers wrote:
> Hi Diederik, all,
> 
> On 26-10-2021 08:34, Diederik de Haas wrote:
> > Therefor it may be worth trying whether this bug is resolved as well.
> 
> Well, it's not fixed in the Debian archive:
> https://ci.debian.net/data/autopkgtest/unstable/armhf/l/llvm-toolchain-12/16229260/log.gz
> 
Should this be reassigned to binutils then?

Cheers,
Julien

Bug#998012: transition: healpix-cxx

[Paul Gevers]

Control: tag -1 confirmed

Hi,

On 28-10-2021 15:38, Leo Singer wrote:
> Upstream SONAME bump.
> 
> pgsphere and healpy will need to be rebuilt.
> I will take care of healpy itself as I co-maintain it.

As said in bug #996452, please go ahead with the upload. For healpy,
apart from the rebuild (which we can schedule), is there anything else
that need to happen? I assume a rebuild is all that's needed and you're
pointing out that you can fix issues when/if they arise.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#997913: OVMF-ia32 does not provide file usable by -bios

[dann frazier]

severity 997913 wishlist
thanks

On Tue, Oct 26, 2021 at 07:31:38PM -0500, Glenn Washburn wrote:
> Package: ovmf-ia32
> Version: 2020.11-4
> 
> Hello Maintainers,
> 
> I'd like ovmf-ia32 to install a file useable by QEMU's -bios option.
> Currently the package only installs OVMF32_CODE_4M.secboot.fd and
> OVMF32_VARS_4M.fd, but I believe I need a file that combines both code
> and vars. According to the wiki[1], I believe I can use the existing
> files using "-drive if=pflash,..." options, but that is not a great
> option for me.

Can you elaborate more on your use case? While we do provide such an
image for X64, that is for backwards-compatibility only.

  -dann

Bug#996887: Also breaks mkvtoolnix-gui

[Jonas Smedegaard]

Quoting Diederik de Haas (2021-10-28 15:10:28)
> On Thu, 28 Oct 2021 14:15:56 +0200 Jonas Smedegaard  wrote:
> > Quoting Peter Keel (2021-10-28 11:05:19)
> > > It may be that this is fixed in the package, but packages 
> > > depending on libcmark0.30.1 providing 0.30.1 and not 0.30.2 are 
> > > now broken:
> > > 
> > > mkvtoolnix-gui: error while loading shared libraries: 
> > > libcmark.so.0.30.1:
> > > cannot open shared object file: No such file or directory
> > 
> > This bugreport tracks the issue of the library being broken - it 
> > isn't any longer so this bugreport is closed.
> > 
> > Packages affected need to be recompiled.
> 
> At https://release.debian.org/transitions/html/auto-cmark.html you can 
> follow that progress.

Right.

Currently all entries at above page is *red* so none of the packages 
work currently.  Only when fixed packages exist can you meaningfully 
test installation of them, not before.


> But it _appears_ that something on the packaging side isn't entirely 
> right.

Yes, something on the packaging side of each dependent consumer of the 
library is not quite right: They were built to link against the older 
broken library package, and each need a rebuild to link against the 
newer unbroken package.


> I run a fully up-to-date Sid system, but libcmark0.30.2 didn't (yet?) 
> get installed, which meant that tldr still failed.

The fixed library will get automatically pulled in when dependent 
packages link against 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#995053: dh_assistant command for listing installed files

[Jelmer Vernooij]

Hi Niels,

On Sun, Oct 24, 2021 at 10:12:13AM +0200, Niels Thykier wrote:
> On Sat, 25 Sep 2021 22:09:53 +0200 Niels Thykier  wrote:
> > Control: tags -1 moreinfo
> > 
> > Jelmer Vernooij:
> > > Package: debhelper
> > > Version: 13.5.2
> > > Severity: wishlist
> > > 
> > > Dear debhelper maintainers,
> > > 
> > > For lintian-brush, it would be really useful if it was possible to 
> > > discover
> > > which patterns it would be installing, why and where.
> > > 
> > > I have no idea how hard this would be to implement, and whether this
> > > information is readily available in debhelper - but figured it's at least 
> > > worth
> > > starting the discussion and seeing where it goes. I suspect there are some
> > > corner cases where it's impossible to discover like where dh-exec is in 
> > > use
> > > (but even some information would be great).
> > > 
> > > I imagine something like a "dh_assistant installed-files" that then 
> > > reports:
> > > 
> > > [...]
> > 
> > I can definitely see how that would be interesting to you.
> > Unfortunately, debhelper is a bunch of "black box" tools that knows
> > nothing about each other. Even figuring out which dh_tools will be run
> > is non-trivial (but I might be able to do that).
> > 
> > The best I can offer is a "post build" list of which tools installed
> > what where.  But I am pretty sure that would not be helpful to your case
> > (because that would be "did install" and not "would install").
> > 
> > Even if I did find a solution, it would rely on each tool "helping out"
> > somehow.  In other words, the solution would be incomplete or "unsafe"
> > with third party tools involved (or both).
> > 
> > 
> > Can you describe the use cases where you see the use for this?  Maybe we
> > can meet somewhere in the middle for them.
> > 
> > ~Niels
> I am still waiting/hoping for your feedback on this. :)
> 
> I would like to know what problem you want to solve using this data. :)
> If we are going forward with this that information would be necessary to
> understand what to do with:
> 
>  1) debhelper supported substitutions (should the be expanded or not)
> - If they are to be expanded, then when do we do when we cannot
>   expand them?
> 
>  2) globs - currently debhelper is strict on expanding globs.  The
> provided example output implies it should *not* be expanded.
> 
>  3) search path - debhelper cannot know where in the search path a file
> is found unless the file is present (e.g., d/tmp is only available
> after dh_auto_install).
> 
>  4) executable config files.  This involves third-party tooling and is
> completely out of control for debhelper for how they will behave.
> 
>  5) do you want tools like dh_link to provide data? It does not
> "install" any upstream provided file but it can generate links.
> 
> 
> I am still not sure to what extend debhelper can help with/provide this
> data in its current form.  However, I would still like to know the
> problem better so I can look into supporting it in the future.

Part of the challenge here is that I'm still trying to figure out
exactly what we can do here as well.

Rather than talking specifics which requires a lot more thought, let
me at least provide you with the background to what I'm trying to do.

Some of the use cases I'm trying to support are:

 * updating filepatterns in debhelper files to adjust for upstream
   changes, e.g. dropping patterns when there are no longer any files
   being provided that match those patterns, or adding new entries

 * determining which files in a source tree are relevant for various
   fixers because they're installed by the packaging.
   e.g. we only need to fix .desktop files that are installed by
   the debian package, not just any .desktop files

 * fixing file installed into bad install locations

 * being able to detect when packaging changes impact file
   installation, e.g. side-effects from a debhelper 12 => 13 upgrade

 * e.g. generating a stub manpage where a manpage is not installed

 * e.g. splitting packages with a large number of arch-all files

The last two in particular are very speculative, but those are the
sorts of things I'm thinking about.

The janitor is best-effort - it's fine if we can do the analysis for
some packages, and have to skip other packages because they e.g. rely
on executable config files - so long as we know that we have to skip a
package.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#998015: minimap2 breaks nanolyse autopkgtest on i386: undefined symbol: ksw_extz2_sse

[Paul Gevers]

Source: minimap2, nanolyse
Control: found -1 minimap2/2.22+dfsg-1
Control: found -1 nanolyse/1.2.0-2
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
minimap2   from testing2.22+dfsg-1
nanolyse   from testing1.2.0-2
all others from testingfrom testing

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

Currently this regression is blocking the migration of minimap2 to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/i386/n/nanolyse/16256284/log.gz

cat: paired_reads.fastq: No such file or directory
Traceback (most recent call last):
  File "/usr/bin/NanoLyse", line 33, in 
sys.exit(load_entry_point('NanoLyse==1.2.0', 'console_scripts',
'NanoLyse')())
  File "/usr/bin/NanoLyse", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in
_call_with_frames_removed
  File "/usr/lib/python3/dist-packages/nanolyse/NanoLyse.py", line 4, in

import mappy as mp
ImportError:
/usr/lib/python3/dist-packages/mappy.cpython-39-i386-linux-gnu.so:
undefined symbol: ksw_extz2_sse
autopkgtest [13:09:50]: test run-unit-test




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998014: cfengine3: recommend python3 instead of python

[Valentin Kleibel]

Package: cfengine3
Version: 3.15.2-3

Dear Maintainer,

I just noted that cfengine3 still recommends `python` for bullseye and 
upwards but this virtual package is no longer available.

Please change this to `Recommends: python3`.
This is especially important as without python the apt-get module of 
cfengine3 won't work.


Cheers,
Valentin

Bug#998013: localslackirc: autopkgtest failure: Cannot find implementation or library stub for module named "typedload"

[Paul Gevers]

Source: localslackirc
Version: 1.13-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package localslackirc, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

I copied some of the output at the bottom of this report. Seems your
missing some (test) dependencies?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/l/localslackirc/15955881/log.gz

mypy --config-file mypy.conf *.py slackclient localslackirc
slackclient/client.py:28: error: Cannot find implementation or library
stub for module named "typedload"
slackclient/client.py:29: error: Cannot find implementation or library
stub for module named "websockets"
slackclient/client.py:30: error: Cannot find implementation or library
stub for module named "websockets.client"
slack.py:26: error: Cannot find implementation or library stub for
module named "typedload"
slack.py:26: note: See
https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
Found 4 errors in 2 files (checked 9 source files)
make: *** [Makefile:6: lint] Error 1
autopkgtest [15:36:30]: test command1




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998012: transition: healpix-cxx

[Leo Singer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: leo.sin...@ligo.org

Upstream SONAME bump.

pgsphere and healpy will need to be rebuilt.
I will take care of healpy itself as I co-maintain it.

Ben file:

title = "healpix-cxx";
is_affected = .depends ~ "libhealpix-cxx2" | .depends ~ "libhealpix-cxx3";
is_good = .depends ~ "libhealpix-cxx3";
is_bad = .depends ~ "libhealpix-cxx2";

Bug#998011: rustc breaks meson autopkgtest: undefined reference to `fma'

[Paul Gevers]

Source: rustc, meson
Control: found -1 rustc/1.56.0+dfsg1-2
Control: found -1 meson/0.59.2-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
rustc  from testing1.56.0+dfsg1-2
meson  from testing0.59.2-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

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

Currently this regression is blocking the migration of rustc to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
rustc/1.56.0+dfsg1-2. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=rustc

https://ci.debian.net/data/autopkgtest/testing/amd64/m/meson/16267457/log.gz

The Meson build system
Version: 0.59.2
Source dir: /tmp/autopkgtest-lxc.868hskgl/downtmp/build.URn/src/test
cases/rust/5 polyglot static
Build dir: /tmp/autopkgtest-lxc.868hskgl/downtmp/build.URn/src/b 538284a9dc
Build type: native build
Project name: static rust and c polyglot executable
Project version: undefined
C compiler for the host machine: cc (gcc 10.3.0 "cc (Debian 10.3.0-11)
10.3.0")
C linker for the host machine: cc ld.bfd 2.37
Rust compiler for the host machine: rustc -C linker=cc (rustc 1.56.0)
Rust linker for the host machine: rustc -C linker=cc ld.bfd 2.37
Host machine cpu family: x86_64
Host machine cpu: x86_64
Library dl found: YES
Run-time dependency threads found: YES
Build targets in project: 2

Found ninja-1.10.1 at /usr/bin/ninja
[1/3] Compiling C object prog.p/prog.c.o
[2/3] Compiling Rust source '../test cases/rust/5 polyglot static/stuff.rs'
[3/3] Linking target prog
FAILED: prog cc  -o prog prog.p/prog.c.o -Wl,--as-needed
-Wl,--no-undefined -Wl,--start-group libstuff.a -ldl -Wl,--end-group
-pthread
/usr/bin/ld: libstuff.a(std-80e93fdce0e07191.std.9561c7b1-cgu.5.rcgu.o):
in function `std::f64lerp':
/usr/src/rustc-1.56.0//library/std/src/f64.rs:(.text._ZN3std3f6421_$LT$impl$u20$f64$GT$4lerp17h11b1be7b614aa463E+0x22):
undefined reference to `fma'
/usr/bin/ld: libstuff.a(std-80e93fdce0e07191.std.9561c7b1-cgu.6.rcgu.o):
in function `std::f32lerp':
/usr/src/rustc-1.56.0//library/std/src/f32.rs:(.text._ZN3std3f3221_$LT$impl$u20$f32$GT$4lerp17he122406d489ebe9dE+0x20):
undefined reference to `fmaf'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

ninja explain: deps for 'libstuff.a' are missing
ninja explain: libstuff.a is dirty
ninja explain: deps for 'prog.p/prog.c.o' are missing
ninja explain: prog.p/prog.c.o is dirty
ninja explain: libstuff.a is dirty
ninja explain: prog is dirty

autopkgtest [11:37:48]: test exhaustive




OpenPGP_signature
Description: OpenPGP digital signature

Bug#995333: polyml: FTBFS on arm64: Segmentation fault ./polyimport polytemp.txt -I . < ./exportPoly.sml

[Jessica Clarke]

Control: severity -1 important
Control: title -1 polyml: Intermittent FTBFS on arm64

Built ok after a give back, so not sure what’s up...

Jess

> On 29 Sep 2021, at 21:17, Sebastian Ramacher  wrote:
> 
> Source: polyml
> Version: 5.7.1-4
> Severity: serious
> Tags: ftbfs sid bookworm
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> | Use: basis/MONO_VECTOR_SLICE.sml
> | Use: basis/MONO_ARRAY.sml
> | Use: basis/MONO_ARRAY_SLICE.sml
> | Use: basis/StringSignatures.sml
> | Use: basis/String.sml
> | /bin/bash: line 1: 3933030 Segmentation fault  ./polyimport 
> polytemp.txt -I . < ./exportPoly.sml
> | make[3]: *** [Makefile:1174: polyexport.o] Error 139
> 
> See
> https://buildd.debian.org/status/fetch.php?pkg=polyml=arm64=5.7.1-4%2Bb1=1632490442=0
> 
> Cheers
> -- 
> Sebastian Ramacher
> 

Bug#998005: Regression: bad handling of permission in directory with sticky bit

[Bastian Blank]

On Thu, Oct 28, 2021 at 02:51:48PM +0200, Vincent Danjean wrote:
> Do you confirm this is a bug? Do you want I look
> for the first kernel in Debian with this regression?

It is not a bug, this are hardening settings.  See documentation about
the protected_regular setting in
https://www.kernel.org/doc/Documentation/sysctl/fs.txt

Those are enabled by default and apply to all sticky directories, so
mostly /tmp and /var/tmp.

Bastian

-- 
Yes, it is written.  Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown

Bug#998010: dpkg: Compression type not respected by, or passed to .deb packing

[Kim Alvefur (Zash)]

Package: dpkg
Version: 1.20.9
Severity: normal

Dear Maintainer,

We (Prosody.im) have a repo where we provide the latest version of
Prosody, as well as nightly builds. We use pbuilder and reprepro.

Due to Canonical having gone ahead with making Zstandard the default
Compression method for Ubuntu (see #892664), and thus packages built in
an Ubuntu environment having zstd control and data archives, which are
not supported (indirectly?) by reprepro on Debian, I've tried to pass -Z
to the package build procedure, but it appears to have no effect on the
resulting .deb files.

Running e.g. `dpkg-buildpackage -Zgzip` still produces .xz members of
the .deb on Debian, and .zstd on Ubuntu, so it seems that the -Z flag is
not passed all the way to whichever command (dpkg-deb ?) actually packs
the .deb file.

-- Package-specific info:
System tainted due to merged-usr-via-aliased-dirs.

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

Kernel: Linux 5.10.0-9-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 dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13+deb11u2
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
pn  debsig-verify  

-- no debconf information

Bug#998009: ethtool: Import new upstream version

[Bastian Germann]

Source: ethtool
Version: 1:5.9-1

ethtool version is lacking behind the latest upstream release 5.14 by several 
versions.
Please import the latest upstream release.