Bug#1001933: RFP: yt-dlp -- youtube-dl fork with additional features and fixes

[Unit 193]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Hello,

On Tue, 21 Dec 2021, Andreas Tille wrote:


Hi,

Am Mon, Dec 20, 2021 at 11:38:46PM -0500 schrieb Unit 193:

External to Debian, I've been maintaining this since August of this year, so
if it ends up not working out to get this team maintained, I'd be up to
maintain it myself.


Is this a kind of "I'd like to turn this into an ITP"?
Would you mind using some non-annonymous ID if this is the case
and do you want access to the Salsa repository (if so what is your
Salsa login)?


More that if your current plan falls though, I can just upload what I have.  I'm 
a DD, in Debian I'm known as Unit 193 with the account unit193, you should be 
able to find me on db.debian.org.  Since I am a DD and yt-dlp is in debian/, I 
should already have access if needed.



Thanks,

~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

-BEGIN PGP SIGNATURE-

iQIcBAEBCQAGBQJhwYeWAAoJEFAB4bCao3RL4rYP/09HRWpJbO9qZSpHvn4X/5JL
+EN+jZF/Ybs5nfcqvoeXTt0gkS6Hx4pns0XRCk89RBEzuhCWfFdxd11VwV3BeVfD
4oUTUTE9slefLcNDkqhyGJLzh+/rDnw29hJHSSZu/am2BM3vjjpzmQaQAOCbBnlw
ITpWxnXfXeE/X5KGrhjmZwflCwXaxg2oKjRSFO4OlS7yLbIA7Fco0LaxEPmtUH6e
nV1Ip4dpyGmtUuwOWuepzP+F19paAGFQ9xvTRrOBSZqtppZydpZ2QBNh0aJbAotJ
pqMWWfrPq9kCBYROIretiO6zAllWVnpYC4rttr6vYFbxLnCUVuM3URR0o9kBfhEk
b7k5NMafCebhjMy2CxoLmRQb25GThlq+n5wxdSHQNhdn0D5s26ocdE+pD3QL6FFK
7JHPATAKe8PkwjvCvZzQTy6Uynd1KVzt5x5boo6kUCq3LsfM5lIpLxGVf/7TFjUw
IRaNeiwmc2XP3RXGZ6vGqfIRPsufAOEHUMQjE2o6CFGn9vhQCjUC3jgIsfOijjMl
vI8GCkC47N4n/A1t82LVDoNmRlCOZ5w0tq2c+P0nQtJ9XgfCVH7cSYerM81H6UAn
N4W/ug4DSlFuH230XoBWJBrV8r1mZnjCUw+w4h+bHOu8vlPW1xeA1IVD2Yy0xrOe
GlnNafOw8w23iP9v0sBO
=B/pH
-END PGP SIGNATURE-

Bug#1001764: More info

[Graham Inggs]

Hi Dima

On Mon, 20 Dec 2021 at 22:40, Dima Kogan  wrote:
> I installed python3.10, and asked the build system to use it. Instead of
> the error you're reporting, I get a build error: it can't find the numpy
> headers because python3-numpy is built for python3.9. This makes sense.

numpy 1:1.21.4-2 in testing is already built for python3.9 and 3.10
[1].  Search for 'cpython-3' and you should find files like:

/usr/lib/python3/dist-packages/numpy/core/_multiarray_tests.cpython-310-x86_64-linux-gnu.so
/usr/lib/python3/dist-packages/numpy/core/_multiarray_tests.cpython-39-x86_64-linux-gnu.so

> What do I need to install to reproduce this bug?

You should be able to reproduce this with all packages from unstable,
or all packages from testing and only packages built from
src:python3-defaults from unstable, e.g. python3, python3-all ,etc.
Follow the links in the unstable and testing columns [2], and note the
'Trigger/Pinned packages' column on the testing page.

Regards
Graham


[1] https://packages.debian.org/bookworm/amd64/python3-numpy/filelist
[2] https://ci.debian.net/packages/m/mrgingham/

Bug#1002061: libjxl-dev: ships files already in libhwy-dev

[Andreas Beckmann]

Package: libjxl-dev
Version: 0.6.1+ds-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Preparing to unpack .../libjxl-dev_0.6.1+ds-5_amd64.deb ...
  Unpacking libjxl-dev (0.6.1+ds-5) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libjxl-dev_0.6.1+ds-5_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libhwy.a', which is also in 
package libhwy-dev 0.15.0-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libjxl-dev_0.6.1+ds-5_amd64.deb

The following files are already shipped by libhwy-dev:

usr/lib/x86_64-linux-gnu/libhwy.a
usr/lib/x86_64-linux-gnu/libhwy_contrib.a
usr/lib/x86_64-linux-gnu/pkgconfig/libhwy-contrib.pc
usr/lib/x86_64-linux-gnu/pkgconfig/libhwy-test.pc
usr/lib/x86_64-linux-gnu/pkgconfig/libhwy.pc


cheers,

Andreas


libhwy-dev=0.15.0-1_libjxl-dev=0.6.1+ds-5.log.gz
Description: application/gzip

Bug#1002060: liblunar-date-doc: missing Breaks+Replaces: liblunar-date-dev (<< 3)

[Andreas Beckmann]

Package: liblunar-date-doc
Version: 3.0.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../liblunar-date-doc_3.0.1-1_all.deb ...
  Unpacking liblunar-date-doc (3.0.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/liblunar-date-doc_3.0.1-1_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/liblunar-date-dev/changelog.gz', which 
is also in package liblunar-date-dev:amd64 2.4.0-8
  Errors were encountered while processing:
   /var/cache/apt/archives/liblunar-date-doc_3.0.1-1_all.deb


cheers,

Andreas


liblunar-date-dev=2.4.0-8_liblunar-date-doc=3.0.1-1.log.gz
Description: application/gzip

Bug#1001933: RFP: yt-dlp -- youtube-dl fork with additional features and fixes

[Andreas Tille]

Hi,

Am Mon, Dec 20, 2021 at 11:38:46PM -0500 schrieb Unit 193:
> External to Debian, I've been maintaining this since August of this year, so
> if it ends up not working out to get this team maintained, I'd be up to
> maintain it myself.

Is this a kind of "I'd like to turn this into an ITP"?
Would you mind using some non-annonymous ID if this is the case
and do you want access to the Salsa repository (if so what is your
Salsa login)?

Kind regards
 Andreas. 

-- 
http://fam-tille.de

Bug#949761: gpgconf: make socketdir configurable to users

[NIIBE Yutaka]

On Fri, 24 Jan 2020 17:21:43 +0100 Thorsten Glaser  wrote:
> Package: gpgconf
> Version: 2.2.19-1
> Severity: important
> 
> gpg2 and gpg-agent (used by gnupg (1.x) as well) now uses
> GPG_AGENT_INFO=/run/user/2339/gnupg/S.gpg-agent:0:1 but
> the directory /run/user/2339 is removed on logout by elogind
> even if processes are still running.

I happened to find a possible solution for this problem, if a user uses
systemd.

It seems that your use case is with elogind, so, this solution may not
work directly, but it would help seeking the way to solve.

In my system, I identified that:

The initial command creating /run/user/$UID/gnupg is this one (for
systemd users) by running gpgconf command:

/lib/systemd/user-environment-generators/90gpg-agent

And then, this script also invokes gpgconf command:

/etc/X11/Xsession.d/90gpg-agent

To introduce keeping old behavior of sockdir, I needed something
which runs before 90gpg-agent.

So, I created the file:
/etc/systemd/user-environment-generators/89-gpg-keep-old-behavior-of-sockdir-under-home

with the content of:
==
#!/bin/sh

D=/run/user/$(id -u)/
CONFIG_FILE=$HOME/.keep-old-behavior-of-gpg-sockdir

# Make a file to prevent use socketdir under /run by gnupg, but keep
# old behavior using $HOME/.gnupg
if [ -e $CONFIG_FILE ]; then
touch ${D}/gnupg
fi
==

That is, when a user specified by the file of
$HOME/.keep-old-behavior-of-gpg-sockdir, it creates a file
'/run/user/$UID/gnupg' before the creation of directory
/run/user/$UID/gnupg, so that the directory cannot be created and used.

Then, by the fallback mechanism of GnuPG, $HOME/.gnupg will be used.
-- 

Bug#1002059: regression: 2:4.9.5+dfsg-5+deb10u2 breaks SID to UID conversion

[McIntyre, Vincent (S, Marsfield)]

Package: samba
Version: 2:4.9.5+dfsg-5+deb10u2
Severity: important

I have a config that is not that common (below)
but it was mostly working until this update came out.
It's taken a while for this to be brought to my attention
and other tasks have intervened.

Working version was 2:4.9.5+dfsg-5+deb10u1

The user-visible impact was that shares they could connect to
before the upgrade, they could no longer connect to.
Reverting to the previous version restored access.

Immediately after upgrading this appeared in 'journalctl -u smbd'

Dec 01 03:59:25 myserv systemd[1]: smbd.service: Main process exited, 
code=killed, status=15/TERM
Dec 01 03:59:25 myserv systemd[1]: smbd.service: Succeeded.
Dec 01 03:59:25 myserv systemd[1]: Stopped Samba SMB Daemon.
Dec 01 03:59:25 myserv systemd[1]: Starting Samba SMB Daemon...
Dec 01 03:59:25 myserv smbd[31189]: [2021/12/01 03:59:25.822636,  0] 
../lib/util/become_daemon.c:138(daemon_ready)
Dec 01 03:59:25 myserv smbd[31189]:   daemon_ready: STATUS=daemon 'smbd' 
finished starting up and ready to serve connections
Dec 01 03:59:25 myserv systemd[1]: Started Samba SMB Daemon.
Dec 01 04:07:03 myserv smbd[17175]: [2021/12/01 04:07:03.989409,  0] 
../source3/auth/auth_util.c:1897(check_account)
Dec 01 04:07:03 myserv smbd[17175]:   check_account: Failed to convert SID 
  to a UID (dom_user[\])
Dec 01 04:07:04 myserv smbd[17177]: [2021/12/01 04:07:04.014896,  0] 
../source3/auth/auth_util.c:1897(check_account)
Dec 01 04:07:04 myserv smbd[17177]:   check_account: Failed to convert SID 
 to a UID (dom_user[\])
Dec 01 04:07:04 myserv smbd[17178]: [2021/12/01 04:07:04.037845,  0] 
../source3/auth/auth_util.c:1897(check_account)

and so on.

This will probably have to go to the samba list,
but my main question is if you have any clues about
what was changed in the update that could cause such breakage?

Vince

Some basic tests

# wbinfo --own-domain   returns correct domain
# wbinfo -n   returns correct SID
# wbinfo -Rreturns correct username
# wbinfo -sreturns correct \

Things that do not work
# wbinfo -r \\ failed to call wbcGetGroups: 
WBC_ERR_DOMAIN_NOT_FOUND
 Could not get groups for user \

# wbinfo -Gfailed to call wbcGidToSid: 
WBC_ERR_DOMAIN_NOT_FOUND
 Could not convert gid  to sid
# wbinfo --user-domgroups   failed to call wbcLookupUserSids: 
WBC_ERR_DOMAIN_NOT_FOUND
 Could not get user's domain groups for user 
SID 



-- Package-specific info:
* /etc/samba/smb.conf present, see below
* /var/lib/samba/dhcp.conf present, see below

-- System Information:
Debian Release: 10.11
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'oldstable-debug')
Architecture: amd64 (x86_64)

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

Versions of packages samba depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libbsd0   0.9.1-2+deb10u1
ii  libc6 2.28-10
ii  libldb1   2:1.5.1+really1.4.6-3+deb10u1
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpopt0  1.16-12
ii  libpython2.7  2.7.16-2+deb10u1
ii  libtalloc22.1.14-2
ii  libtdb1   1.3.16-2+b1
ii  libtevent00.9.37-1
ii  lsb-base  10.2019051400
ii  procps2:3.3.15-2
ii  python2.7.16-1
ii  python-dnspython  1.16.0-1+deb10u1
ii  python-samba  2:4.9.5+dfsg-5+deb10u2
ii  python2.7 2.7.16-2+deb10u1
ii  samba-common  2:4.9.5+dfsg-5+deb10u2
ii  samba-common-bin  2:4.9.5+dfsg-5+deb10u2
ii  samba-libs2:4.9.5+dfsg-5+deb10u2
ii  tdb-tools 1.3.16-2+b1

Versions of packages samba recommends:
pn  attr
ii  logrotate   3.14.0-4
ii  samba-dsdb-modules  2:4.9.5+dfsg-5+deb10u2
pn  samba-vfs-modules   

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p12+dfsg-4
pn  smbldap-tools  
pn  ufw
ii  winbind2:4.9.5+dfsg-5+deb10u2

-- no debconf information

smb.conf 
[global]
workgroup = 

# "global.conf" should be the first include in the list
# for the global parameters to be set.
include = /etc/samba/global.conf
include = /etc/samba/winbind.conf

# These have their own [section] headers within them.
include = /etc/samba/shares.conf

include = /etc/samba/printers.conf

global.conf --
   workgroup = 
   realm = 

   server string = Local %h UNIX Server (Samba %v)

   wins server =  \
  \
 
   dns proxy = no

  

Bug#995607: ITP: libfreeaptx -- Free implementation of Audio Processing Technology codec (aptX)

[Kentaro Hayashi]

Now in new queue.

https://ftp-master.debian.org/new.html

Bug#1002058: firefox-esr: no refresh firefox button in about:support

[Yihong Cao]

Package: firefox-esr
Version: 91.4.0esr-1
Severity: normal
X-Debbugs-Cc: caoyiho...@outlook.com

Dear Maintainer,


   * What led up to the situation?
   Slow down while play video online, try to refresh Firefox.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   No refresh Firefox button at about:support.
   * What outcome did you expect instead?
   Click refresh button and refresh Firefox.

When I updated to firefox 91, some online video playing becomes very slow. I
tried troubleshoot
mode and videos becomes fluent and normal. So I decided to give firefox a
refresh, but the
refresh button in about:support is missing. I thought it is a Debian specific
problem because
firefox-esr 91.4 from Mozilla did not have this problem.


-- Package-specific info:

-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox-esr/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Proxy Failover
Location: 
/home/cao/.mozilla/firefox/lmsa9m67.default-esr/features/{47afd55c-bb29-44e1-aa87-3780c4b55c66}/proxy-failo...@mozilla.com.xpi
Status: enabled

Name: SingleFile
Location: ${PROFILE_EXTENSIONS}/{531906d3-e22f-4a6c-a102-8057b88a1a63}.xpi
Status: user-disabled

Name: System theme theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: user-disabled

Name: User-Agent Switcher and Manager
Location: ${PROFILE_EXTENSIONS}/{a6c4a591-f1b2-4f03-b3ff-767e5bedf4e7}.xpi
Status: user-disabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: 亚马逊
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled


-- Addons package information
ii  firefox-esr91.4.0esr-1  amd64Mozilla Firefox web browser - 
Extended Support Release (ESR)

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

Kernel: Linux 5.15.0-2-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 firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-3
ii  libc62.33-1
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-3
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi8  3.4.2-3
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.11.0+dfsg-1
ii  libgcc-s111.2.0-12
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.2-1
ii  libgtk-3-0   3.24.30-4
ii  libnspr4 2:4.32-3
ii  libnss3  2:3.73-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libstdc++6   11.2.0-12
ii  libvpx7  1.11.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

[Guillem Jover]

On Mon, 2021-12-20 at 23:15:07 -0500, nick black wrote:
> not that i expect you to have run extensive benchmarks or
> anything, but how do you feel this compares to libdeflate?

I don't think it matters, because libdeflate does not support a
streaming API anyway, so it's of no use in many situations where
large files or streaming content needs to be dealt with. It also
does not provide a compatible zlib API, which means it cannot be
easily migrated to.

> the few comparisons i've seen suggest that they are (or at least
> were) pretty much a wash, performance-wise.

I think when I first noticed libdeflate being uploaded to Debian, I
took a look to also play with it for dpkg, but the above problems
meant that never got anywhere. From the benchmarks I've seen
libdeflate might be a bit faster, but then it would require tons more
memory to handle equivalent inputs and outputs.

The reasons I found the zlib-ng alternative interesting were because:

 - the Intel fork is not going to be adding non-Intel optimizations,
 - the Cloudflare fork does not look very lively,
 - the zlib upstream does not look very active, and apparently outright
   refuses contributions to the main code, and only accepts them into
   its contrib/ directory,

OTOH the zlib-ng looks very lively, accepts contributions, has had its
code modernized and cleaned up, and seems to be performing rather well
in comparison on multiple architectures.

Thanks,
Guillem

Bug#1002057: RFS: libfilezilla/0.34.2-3 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libfilezilla
   Version : 0.34.2-3
   Upstream Author : Tim Kosse 
 * URL : https://lib.filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/libfilezilla
   Section : libs

It builds those binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla22 - build high-performing platform-independent programs (runtime 
lib)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.34.2-3.dsc

Changes since the last upload:

 libfilezilla (0.34.2-3) unstable; urgency=medium
 .
   * Source only upload for migration to testing


Note: This is the source only upload required for migration to testing of 
previously uploaded:

libfilezilla/0.34.2-2: https://qa.debian.org/excuses.php?package=libfilezilla

This will be imported into salsa once uploaded.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1001933: RFP: yt-dlp -- youtube-dl fork with additional features and fixes

[Unit 193]

Howdy,

External to Debian, I've been maintaining this since August of this year, so if 
it ends up not working out to get this team maintained, I'd be up to maintain it 
myself.


Cheers!

~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

[nick black]

not that i expect you to have run extensive benchmarks or
anything, but how do you feel this compares to libdeflate? the
few comparisons i've seen suggest that they are (or at least
were) pretty much a wash, performance-wise.

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover 
X-Debbugs-Cc: debian-de...@lists.debian.org, Mark Brown 

* Package name: zlib-ng
  Version : 2.0.5
  Upstream Author : zlib-ng Team
* URL : http://github.com/zlib-ng/zlib-ng
* License : Zlib, Zlib-RFC, CC-BY-3.0, CC-BY-4.0, Public-Domain
  Programming Lang: C
  Description : optimized zlib compression library

 zlib-ng is a fork of the zlib library implementing the deflate compression
 method found in gzip and PKZIP.
 .
 It includes and consolidates many optimizations found in alternative forks,
 that have not been merged in the official zlib library.


I just discovered this project, and started packaging [P] it to be able
to play with a dpkg branch switching its zlib support to zlib-ng. The
speed up is quite significant, for example when packing the 0ad-data,
on my system it takes 5m50s~ with zlib and 4m30s~ with zlib-ng.

  [P] https://git.hadrons.org/cgit/wip/debian/pkgs/zlib-ng.git/

The project has a compat mode which generates API "compatible" zlib
replacement libraries, but unfortunately it is stated not to guarantee
to be ABI compatible, so no compat packages or similar could be
produced right now as that could potentially break other packages. I've
filed a report [S] upstream to request a more usable shim instead.

  [S] 


I'm still pondering whether to upload this, although the packing is
already done, but w/o the above mentioned shim its utility seems
restricted as most upstream projects use it via its compat mode,
instead of with its native API. But if that happens, I think it would
make sense to upload, as it's currently being embedded in several
upstream projects and even if dpkg would not switch to it, it would
still help with removing embedded code copies, and speeding up other
packages. Or make other RPFs such as #901490 (an alternative fork)
unnecessary.

Thanks,
Guillem

Bug#1002021: apt-cache [--installed] lists package name for each available version

[наб]

Control: tags -1 + patch

Patch attached (based on top of Salsa HEAD, 2662f6f255).
It's something, I think, but it's also entirely possible it's nothing!

New output:
-- >8 --
$ build/cmdline/apt-cache rdepends libtokyocabinet9
libtokyocabinet9
Reverse Depends:
  libtokyocabinet-dev
  neomutt
  libtokyocabinet9-dbgsym
  tokyocabinet-bin
  bogofilter-tokyocabinet
  ruby-tokyocabinet
  regina-normal
  mutt
  libtokyocabinet-perl
  libgrok1
  grok
  duc-nox
  duc
-- >8 --

Diff of apt-cache depends systemd --recurse, bullseye against patch,
first 200 lines, is promising:
-- >8 --
diff --git a/tmp/cur b/tmp/new
index 975d5b1d2..f38a4840b 100644
--- a/tmp/cur
+++ b/tmp/new
@@ -645,7 +645,6 @@ locales
 locales-all
   Depends: libc-l10n
 macs
-  Depends: python3
   Depends: python3
   Depends: python3-numpy
   Depends: 
@@ -658,7 +657,6 @@ nscd
   Depends: lsb-base
   Depends: libaudit1
   Depends: libc6
-  Depends: libc6
   Depends: libcap2
   Depends: libselinux1
 openarena
@@ -671,7 +669,6 @@ openarena
   Depends: openarena-085-data
   Depends: openarena-088-data
   Depends: openarena-data
-  Depends: openarena-data
   Depends: libc6
   Recommends: openarena-oacmp1
 openssh-server
@@ -773,7 +770,6 @@ libnss-nis
 libnss-nisplus
   Depends: libc6
   Depends: libnsl2
-  Depends: libnsl2
   Depends: libtirpc3
   Breaks: libc6
   Replaces: libc6
@@ -831,7 +827,6 @@ rng-tools-debian
   Depends: makedev
   Conflicts: 
   Breaks: rng-tools
-  Breaks: rng-tools
   Replaces: 
 rng-tools-debian
   Replaces: rng-tools
@@ -1216,7 +1211,6 @@ network-manager
   Depends: policykit-1
 policykit-1:i386
   Breaks: ppp
-  Breaks: ppp
   Recommends: ppp
   Recommends: dnsmasq-base
 dnsmasq-base-lua
@@ -1291,7 +1285,6 @@ perl:i386
   Suggests: 
   Suggests: make:i386
 make-guile:i386
-make-guile
   Suggests: 
   Replaces: perl-base:i386
 perl
@@ -1799,7 +1792,6 @@ python3:i386
   Suggests: python3-venv:i386
   Replaces: python3-minimal:i386
 python3-dbus
-  Depends: python3
   Depends: python3
   Depends: 
 python3:i386
@@ -1813,7 +1805,6 @@ python3-dbus
 python3-gi
   Depends: gir1.2-glib-2.0
   Depends: python3
-  Depends: python3
   Depends: 
 python3:i386
 python3
@@ -1960,11 +1951,9 @@ nscd:i386
 lsb-base
   Depends: libaudit1:i386
   Depends: libc6:i386
-  Depends: libc6:i386
   Depends: libcap2:i386
   Depends: libselinux1:i386
 unscd
-  Depends: libc6
   Depends: libc6
   Depends: libsystemd0
 libelogind0
@@ -2702,18 +2691,15 @@ libgegl-dev
   Replaces: 
 libgegl-dev
 libc-bin
-  Depends: libc6
   Depends: libc6
   Recommends: manpages
 libc-bin:i386
-  Depends: libc6:i386
   Depends: libc6:i386
   Recommends: 
 manpages
 python3-numpy
   Depends: python3-pkg-resources
   Depends: python3
-  Depends: python3
   Depends: 
 python3.9:i386
 python3.9
@@ -4037,7 +4023,6 @@ libgegl-0.4-0:i386
   Replaces: libgegl-dev:i386
   Breaks: libgegl-dev:i386
 macs:i386
-  Depends: python3:i386
   Depends: python3:i386
   Depends: python3-numpy:i386
   Depends: 
@@ -4120,7 +4105,6 @@ libnss-nis:i386
 libnss-nisplus:i386
   Depends: libc6:i386
   Depends: libnsl2:i386
-  Depends: libnsl2:i386
   Depends: libtirpc3:i386
   Breaks: libc6:i386
   Replaces: libc6:i386
@@ -4178,7 +4162,6 @@ openarena:i386
   Depends: 
   Depends: 
   Depends: 
-  Depends: 
   Depends: libc6:i386
   Recommends: 
 r-cran-later:i386
@@ -4233,7 +4216,6 @@ network-manager:i386
   Depends: policykit-1:i386
 policykit-1
   Breaks: ppp:i386
-  Breaks: ppp:i386
   Recommends: ppp:i386
   Recommends: dnsmasq-base:i386
 dnsmasq-base-lua:i386
@@ -4937,14 +4919,6 @@ make-guile:i386
   Suggests: 
   Replaces: make:i386
 make-guile:i386
-make-guile
-make-guile
-  Depends: guile-3.0-libs
-  Depends: libc6
-  Conflicts: make
-  Suggests: make-doc
-  Replaces: make
-make-guile
 libperl5.32
   Depends: libbz2-1.0
   Depends: libc6
@@ -5054,6 +5028,13 @@ make
   Conflicts: make-guile
   Suggests: make-doc
   Replaces: make-guile
+make-guile
+  Depends: guile-3.0-libs
+  Depends: libc6
+  Conflicts: make
+  Suggests: make-doc
+  Replaces: make
+make-guile
 libtap-harness-archive-perl
   Depends: perl
   Depends: libyaml-tiny-perl
@@ -5079,7 +5060,6 @@ python3-doc
   Suggests: python3
   Suggests: python3-examples
 python3-tk
-  Depends: python3
   Depends: python3
   Depends: blt
   Depends: libc6
@@ -5580,8 +5560,6 @@ postfix
   Suggests: 
 dovecot-core
  |Suggests: libsasl2-modules
-  Suggests: 
-dovecot-core
   Suggests: resolvconf
 openresolv
   Suggests: postfix-cdb
@@ -6179,8 +6157,6 @@ postfix:i386
   Suggests: 
 dovecot-core:i386
  |Suggests: libsasl2-modules:i386
-  Suggests: 
-dovecot-core:i386
   Suggests: 
 openresolv
   Suggests: postfix-cdb:i386
@@ -6349,7 +6325,6 @@ exim4
  |Depends: debconf
   Depends: cdebconf
   Depends: exim4-base
-  Depends: exim4-base
  |Depends: exim4-daemon-light
  |Depends: exim4-daemon-heavy
   Depends: 
-- >8 --

Of apt-cache -o 

Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)

[Nicholas D Steeves]

Package: lintian
Version: 2.114.0
Severity: normal

Hi,

Gpl-2+ (used in d/copyright) is equivalent to gpl-2.0+ used in
appstream metadata, so this is a false positive.  Were GNU to
hypothetically release a GPL 2.1, and were upstream to switch to it,
the onus would be on the Debian maintainer to update d/copyright.  It
also seems wrong to emit this at the warning level for this specific
case.

If lintian is encouraging maintainers to use the "gpl-2.0+" notation
rather than gpl-2+ in d/copyright, then it should emit a different
(lower severity than warning) tag for that case.

It seems clear to me that (gpl-2.0+ = gpl-2+), so it looks like the
correct approach is to use a table of equivalent license notations to
prevent the false positive.  Apologies if bias has prevented me from
deeper analysis or seeing other solutions.

Thanks!
Nicholas

Bug#1002037: heartbeat: Heartbeat 3.0.6-11 will not start on bullseye

[Valentin Vidic]

On Mon, Dec 20, 2021 at 06:23:38PM +, Adam Thorn wrote:
> Could the fix from 3.0.6-12, which distributes
> 
>   /usr/lib/tmpfiles.d/heartbeat.conf
> 
> as part of the deb, be backported/released for bullseye please?

Yes, I have opened #1002051 to request heartbeat update in bullseye.

-- 
Valentin

Bug#1002052: process-cpp: FTBFS on riscv64, linked with -lpthread instead of -pthread

[Aurelien Jarno]

Source: process-cpp
Version: 3.0.1-8
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

process-cpp fails to build on riscv64 with the following failure:

| Linking CXX shared library libprocess-cpp.so
| cd /<>/obj-riscv64-linux-gnu/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/process-cpp.dir/link.txt --verbose=1
| /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c++11 -Wall -fno-strict-aliasing -fvisibility=hidden 
-fvisibility-inlines-hidden -pedantic -Wextra -Werror -Wno-error=format  
-Wl,--version-script,/<>/symbols.map -Wl,-z,relro 
-Wl,--no-undefined -shared -Wl,-soname,libprocess-cpp.so.3 -o 
libprocess-cpp.so.3.0.0 CMakeFiles/process-cpp.dir/core/posix/backtrace.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/child_process.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/exec.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/fork.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/process.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/process_group.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/signal.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/signalable.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/standard_stream.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/wait.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/this_process.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/linux/proc/process/oom_adj.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/linux/proc/process/oom_score.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/linux/proc/process/oom_score_adj.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/linux/proc/process/stat.cpp.o 
CMakeFiles/process-cpp.dir/core/testing/cross_process_sync.cpp.o 
CMakeFiles/process-cpp.dir/core/testing/fork_and_run.cpp.o  
/usr/lib/riscv64-linux-gnu/libboost_iostreams.so.1.74.0 
/usr/lib/riscv64-linux-gnu/libboost_system.so.1.74.0 -lpthread 
| /usr/bin/ld: CMakeFiles/process-cpp.dir/core/posix/child_process.cpp.o: in 
function `.L0 ':
| /usr/include/riscv64-linux-gnu/c++/11/bits/gthr-default.h:778: undefined 
reference to `__atomic_exchange_1'
| collect2: error: ld returned 1 exit status

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=process-cpp=riscv64=3.0.1-8=1639996742=0

The problem is that the linking is not done correctly, it uses -lpthread
meaning linking with the pthread library, instead of -pthread which
means enable thread support, and which brings libatomic.so on riscv64.
This can be fixed by using the THREADS_PREFER_PTHREAD_FLAG option, which
is "highly recommended" according to the documentation, but
unfortunately not the default.

This is what the attached patch does, could you please include it in the
next upload?

Thanks,
Aurelien
--- process-cpp-3.0.1/debian/patches/0003-link-pthread.patch
+++ process-cpp-3.0.1/debian/patches/0003-link-pthread.patch
@@ -0,0 +1,19 @@
+Description: Link with -pthread instead of -lpthread
+ The canonical way to link with the thread library is to use -pthread, which
+ brings in additional libraries like libatomic.so on riscv64. However cmake
+ defaults to link with -lpthread which only bring the libpthread.so library.
+ Fortunately it has the option THREADS_PREFER_PTHREAD_FLAG for that, which is
+ "highly recommended" but not the default.
+Author: Aurelien Jarno 
+Last-Update: 2021-12-20
+
+--- process-cpp-3.0.1.orig/CMakeLists.txt
 process-cpp-3.0.1/CMakeLists.txt
+@@ -20,6 +20,7 @@ project(process-cpp)
+ 
+ find_package(Boost COMPONENTS iostreams system REQUIRED)
+ find_package(PkgConfig REQUIRED)
++set(THREADS_PREFER_PTHREAD_FLAG ON)
+ find_package(Threads REQUIRED)
+ 
+ pkg_check_modules(PROPERTIES_CPP properties-cpp)
--- process-cpp-3.0.1/debian/patches/series
+++ process-cpp-3.0.1/debian/patches/series
@@ -1,2 +1,3 @@
 0001-Don-t-run-tests.patch
 0002-Reproducible-documentation.patch
+0003-link-pthread.patch

Bug#1002051: bullseye-pu: package heartbeat/1:3.0.6-11+deb11u1

[Valentin Vidic]

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

[ Reason ]
heartbeat deamon starts correctly after installation, but not
after reboot because of missing /run/heartbeat directories.
The change reintroduces a tempfiles configuration for creating
the required directories on boot.

[ Impact ]
heartbeat fails to start correctly until the required directories
in /run are created.

[ Tests ]
Manually tested by checking the service starts correctly after
a reboot.

[ Risks ]
The change is simple and has already been released to unstable
in #993575 and tested by users.

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

[ Changes ]
Change removes creating /run directories in postinst, since
this masks the problem until reboot. Instead a tempfiles
configuration is included for creating the required directories.

[ Other info ]
The bug only affects systemd installations since the init script
recreates the required directories on every start.


diff -Nru heartbeat-3.0.6/debian/changelog heartbeat-3.0.6/debian/changelog
--- heartbeat-3.0.6/debian/changelog2021-01-20 21:59:42.0 +0100
+++ heartbeat-3.0.6/debian/changelog2021-12-20 23:51:42.0 +0100
@@ -1,3 +1,9 @@
+heartbeat (1:3.0.6-11+deb11u1) bullseye; urgency=medium
+
+  * Use tmpfiles.d to create /run/heartbeat (Closes: #1002037)
+
+ -- Valentin Vidic   Mon, 20 Dec 2021 23:51:42 +0100
+
 heartbeat (1:3.0.6-11) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru heartbeat-3.0.6/debian/heartbeat.postinst 
heartbeat-3.0.6/debian/heartbeat.postinst
--- heartbeat-3.0.6/debian/heartbeat.postinst   2018-12-09 14:58:48.0 
+0100
+++ heartbeat-3.0.6/debian/heartbeat.postinst   2021-12-20 23:50:08.0 
+0100
@@ -33,7 +33,6 @@
fi
 
for i in /var/lib/heartbeat/ccm /var/lib/heartbeat/crm \
-   /run/heartbeat/ccm /run/heartbeat/crm \
/var/lib/heartbeat/pengine; do
mkdir -p $i
chmod 750 $i
@@ -41,10 +40,6 @@
chgrp haclient $i
done
 
-   # prepare agent state dir
-   mkdir -p /run/resource-agents
-   chmod 755 /run/resource-agents
-
chgrp haclient /usr/bin/cl_status
chmod 2555 /usr/bin/cl_status
 
diff -Nru heartbeat-3.0.6/debian/rules heartbeat-3.0.6/debian/rules
--- heartbeat-3.0.6/debian/rules2020-08-22 23:04:27.0 +0200
+++ heartbeat-3.0.6/debian/rules2021-12-20 23:50:08.0 +0100
@@ -103,7 +103,7 @@
 
# move sysv init script and systemd service file to expected locations 
for dh_install
! test -e ./debian/tmp/usr/lib/tmpfiles.d/heartbeat.conf || \
-   mv ./debian/tmp/usr/lib/tmpfiles.d/heartbeat.conf 
./debian/heartbeat.tmpfile
+   mv ./debian/tmp/usr/lib/tmpfiles.d/heartbeat.conf 
./debian/heartbeat.tmpfiles
! test -e ./debian/tmp/lib/systemd/system/heartbeat.service || \
mv ./debian/tmp/lib/systemd/system/heartbeat.service 
./debian/heartbeat.service
! test -e ./debian/tmp/etc/init.d/heartbeat || \
@@ -129,6 +129,7 @@
dh_installexamples -a
dh_installinit -a -n -u 'defaults 20 32'
dh_installsystemd -a
+   dh_installtmpfiles -a
dh_installman -a
dh_installchangelogs -a `pwd`/doc/ChangeLog
dh_installlogcheck -a

Bug#1002050: dh-addon dependency test false positive

[Bdale Garbee]

Package: lintian
Version: 2.114.0

I'm getting the error:

E: lepton-eda source: missing-build-dependency-for-dh-addon autoreconf => 
dh-autoreconf | debhelper (>= 9.20160403~) | debhelper-compat [debian/rules]

on a package that has   

Build-Depends: debhelper (>= 13)

in the control file.  This seems like a bug?

Bdale

Bug#1002049: Please add Provides: libfreetype6-dev to allow transition

[Jochen Sprickerhof]

Package: libfreetype-dev
Version: 2.11.0+dfsg-1
Severity: minor
Tags: patch
X-Debbugs-Cc: jspri...@debian.org

Hi,

please apply the attached patch to allow replacing libfreetype6-dev by
libfreetype-dev in versioned dependencies like libcairo2-dev or
libfontconfig-dev.

Cheers Jochen


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 libfreetype-dev depends on:
ii  libbrotli-dev  1.0.9-2+b3
ii  libc6-dev [libc-dev]   2.33-1
ii  libfreetype6   2.11.0+dfsg-1
ii  libpng-dev 1.6.37-3
ii  zlib1g-dev [libz-dev]  1:1.2.11.dfsg-2

libfreetype-dev recommends no packages.

Versions of packages libfreetype-dev suggests:
pn  freetype2-doc  

-- debconf-show failed
>From 98908723b8e06cfd16856e7d0912f42b350dc971 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Mon, 20 Dec 2021 23:43:43 +0100
Subject: [PATCH] Have libfreetype-dev provide 6-dev to ease transition

As documented in https://wiki.debian.org/RenamingPackages.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 1434eb0e..240679a4 100644
--- a/debian/control
+++ b/debian/control
@@ -70,6 +70,7 @@ Depends:
 Suggests: freetype2-doc (= ${binary:Version})
 Replaces: libfreetype6-dev (<< 2.10.1)
 Breaks: libfreetype6-dev (<< 2.10.1)
+Provides: libfreetype6-dev (= ${binary:Version})
 Description: FreeType 2 font engine, development files
  The FreeType project is a team of volunteers who develop free,
  portable and high-quality software solutions for digital typography.
-- 
2.34.1

Bug#1001155: Fails to update when service is masked

[Uwe Kleine-König]

Package: pcscd
Version: 1.9.5-1
Followup-For: Bug #1001155

Hello,

I just encountered the same problem. Digging into it (and before having
found this bug in the BTS) I saw the postinst script of pcscd restarts
the daemon twice. Once explicitly in debian/pcscd.postinst:

case "$1" in
configure|reconfigure)
# restart pcscd (PCSC daemon)
invoke-rc.d pcscd restart
;;

and again later added by dh_installinit/13.5.2:

if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -z "${DPKG_ROOT:-}" ] && [ -x "/etc/init.d/pcscd" ]; then
update-rc.d pcscd defaults >/dev/null
invoke-rc.d --skip-systemd-native pcscd restart || exit 
1
fi
fi

Even if you consider it a bug to mask pcscd.socket but not pcscd.service
(I disagree BTW), I still ask you to remove the explicit call to
invoke-rc.d pcscd restart, as the snippet added by dh_installinit should
serve the same purpose and this doesn't fail with pcscd.socket masked.

The latter invocation of invoke-rc.d is also better as it honors policy
9.3.3 "Maintainer scripts for packages including init scripts must use
update-rc.d [...]." So keeping the status quo might even justify a
serious severity for this bug.

(Note: There is one relevant difference, where I'm unsure if the snippet
added by dh_installinit is better: The explicit call also triggers for
$1 == reconfigure.)

Best regards
Uwe

Bug#995467: Salvaging status

[Ryan Kavanagh]

Hi Wesley,

On Mon, Dec 20, 2021 at 11:42:42AM -0800, Wesley W. Terpstra wrote:
> Can I pass the baton of mlton package ownership off to someone?

Sure, I'm in the process of taking over maintainership:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995467#5

> I'd be happy to answer questions about how to get things to work, if
> that is helpful.

Great, thanks! I'll let you know if I have any questions.

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#1001710: multipath-tools: booting with lvm over multipath it does not setup devices for lvm

[BARROS FERNANDEZ, Carlos]

Hello Ritesh

In another testing I had a boot problem.

This time was because the megaraid_sas module was later that the other hba. So 
/dev/sda was other disk and the initrd drop me into the shell.

I did change the filter, now using the internal raid controller directory,  and 
simplify for which devices to look for in this case :

 filter = [ "a|/dev/disk/by-id/dm-name-.*|", 
"a|/dev/disk/by-id/scsi-SDELL_PERC_6/.*|", "r|/block/|", "r|/disk/|", 
"r|/sd[a-z].*|", "a|.*|" ]

Notes on creating a filter rule for multipath, I think that you can use this 
text:

Multipath is used in SAN (Storage Area Network) by a special HBA of the type 
FC. iSCSI is the other type, but it can be used with a network card or a 
special HBA card supporting iSCSI protocol.
There are some SAS storage decives that allows multipath, but you need 2 SAS HBA

It is not possible to have more than one path to a RAID card nor using 2 
RAID-cards in RAID-mode for multipath, as RAID-cards do caching and other 
things that it is not compatible with multipath.

Normally you set multipath with a pair of the same type of the HBA ( 2 FC or 2  
iSCSI)

There are a very few systems that uses FC for managing it's internal disks, and 
there is no system with iSCSI for it's internal disks

Th lvm.conf filter rule must be adjusted for the server that uses mutipath to 
avoid using components of a multipath device as a PV.
A component of a multipath device is also called a path and in linux is a disk, 
like /dev/sdX
So the filter must exclude some or all /dev/sdX.
Only exclude all /dev/sdX if your system boots and uses only multipathed 
devices, for example it does not have internal disks and have 2 SAN HBAs

When you have internal disks configured in LVM, you must no exclude the 
internal disks in the filter.
If you have a software-raid (mdadm) as a PV and no other non-multipathed disk, 
you can exclude all /dev/sdX, but you have to keep the rule "a|.*|" for LVM to 
use the /dev/mdX device (or use other type of rule)

When you can not exclude all disks (/dev/sdX) from LVM, it is better to include 
in the filter the disk  by using /dev/disk/by-id/*, because this paths do not 
change between reboots due to paralell scanning of hardware that the kernel 
does.
Here are some examples of how to set the lvm.conf rules


On a Dell server with PERC-6, exclude all internal RAID volumes (the PERC 
driver is megaraid_sas)

 filter = [ "a|/dev/disk/by-id/dm-name-.*|", 
"a|/dev/disk/by-id/scsi-SDELL_PERC_6/.*|", "r|/block/|", "r|/disk/|", 
"r|/sd[a-z].*|", "a|.*|" ]

On a IBM/Lenovo server with a ServeRaid, exclude all internal RAID volume. 
(same driver as PERC, megaraid_sas, but no directory exists)
 filter = [ "a|/dev/disk/by-id/dm-name-.*|", 
"a|/dev/disk/by-id/scsi-SIBM_ServeRAID_.*|", "r|/block/|", "r|/disk/|", 
"r|/sd[a-z].*|", "a|.*|" ]
On a HPe server with SmartArray, exclude all internal RAID volumes (using hpsa 
driver)
 filter = [ "a|/dev/disk/by-id/dm-name-.*|", 
"a|/dev/disk/by-id/scsi-SHP_LOGICAL_VOLUME-.*|", "r|/block/|", "r|/disk/|", 
"r|/sd[a-z].*|", "a|.*|" ]
Exclude a disk/volue and it's partitions by it's WWN or WWNN:
 filter = [ "a|/dev/disk/by-id/dm-name-.*|", 
"a|/dev/disk/by-id/scsi-36d4ae5207d32f7001fe159a422f3750c.*|", "r|/block/|", 
"r|/disk/|", "r|/sd[a-z].*|", "a|.*|" ]
 filter = [ "a|/dev/disk/by-id/dm-name-.*|", 
"a|/dev/disk/by-id/wwn-0x6d4ae5207d32f7001fe159a422f3750c.*|", "r|/block/|", 
"r|/disk/|", "r|/sd[a-z].*|", "a|.*|" ]


The last filter is to add in these examples allows to include /dev/md* under LVM

There are variations fo names from different controllers/servers as you can see 
from these examples.


Regards

--

Carlos Barros.

On lun, 2021-12-20 at 15:32 +0530, Ritesh Raj Sarraf wrote:
Control: tag -1 +pending

Thanks for confirming Carlos. The following has been added and will be
part of the next upload.


commit 00b79442b9af0c5275880b73b9bae5c68150e2c5 (HEAD -> master)
Author: Ritesh Raj Sarraf mailto:r...@debian.org>>
Date:   Mon Dec 20 15:29:43 2021 +0530

Add some documentation about LVM + DM-Multipath setup

Thanks: Carlos Barros
Closes: 1001710

diff --git a/debian/multipath-tools.README.Debian 
b/debian/multipath-tools.README.Debian
index 257eebdb..ec1dee40 100644
--- a/debian/multipath-tools.README.Debian
+++ b/debian/multipath-tools.README.Debian
@@ -1,6 +1,24 @@
 Additional information for users of multipath-tools from Debian.


+LVM over DM-Multipath
+=
+
+Debigu Bug #1001710
+
+On a setup that involves both, LVM and DM-Multipath, it is important to set the
+right filter in lvm.conf file to ensure that LVM does not acquire the bare 
SCSI devices
+before DM-Multipath can.
+
+On such combined setups, the standard recommendation is to pvcreate devices on 
the
+enumerated multipathed devices. And also ensure that the bare SCSI devices are 
filtered out
+from LVM's list
+
+   # filter = [ "a|/dev/mapper/|", "r|/block/|", "r|/disk/|", 
"r|/sd[b-z].*|", "a|.*|" ]
+
+In the 

Bug#995846: FTBFS: Fatal TYPE-ERROR and tests incompatible with PG14

[Christoph Berg]

Re: Sébastien Villemot
> I’ve uploaded a new cl-esrap. It seems pgloader builds again.

Merci! I'll try to polish the package over the next days.

Christoph

Bug#1002046: ITP: bme280 -- Python interface for a Bosch BME280 digital sensor module

[Anton Gladky]

Package: wnpp
Severity: wishlist
Owner: Anton Gladky 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: bme280
  Version : 0.2.4~git720dcbe6+ds1
* URL : https://github.com/rm-hull/bme280/
* License : MIT
  Programming Lang: Python
  Description : Python interface for a Bosch BME280 digital sensor module

The package provides a python interface for BME280 sensor, measuring
temperature, humidity and pressure.

The package will be maintained under the roof of pkg-electronics team.

Anton

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmHA60QRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYXPw/+JTSmg7NYQk+4Cv587PAeAvIaFrtbwNnH
cQ8lczhoeyjCr/f/ChieD14imt+fit+GpWgYjJnJm/e3r8xHdaM+QEMr+Zx4mltt
FjgiAz2N0nKJzLiwhuixzNp846DS/91U/y1wfkk70AZ8HcgSQqYvvSEbNucrwDUB
FBM3pNfEKHOU+UYxDARs3Dx5AvGqqpWErW8eFbqDowyIvrO9rYDiDXbAV3Yp/BQR
EdmpFL0CA9J9hWrKSgYyf4qbBhce9XT0pd2+yDr3Eo0s5NZcvDvyTAry8TqEevwm
vTS93oyng+IwQWQm3P04ygTzvyz460BVcfugpFwRWhOoT/8IgJqi8azH6y5ZzBTX
ZNmAPskyFAizVGYpbW7VwugugJBYfCFDFIFKJkj38rRK1PQmq0xYKHfzpoJ9YzVH
6wBfEbyWwF8XGsqUzRKj4Z4KQJxNSUgDjI64XPpAfDMliygB9fNojfId1rJqFhhv
6RBpJ/MuFHvzpWCsmfFr0rwTyD05FnITreo7fJCkUEj3TYesrJLKJShLlglYoRJB
Hq7k0IWemOnYqwxpGBLAsboQhGfb1+s6ROU/kYoLUeFPAEApTYlzLYiILz2rynod
aNH08WAy9E9Od3Vz5vzj7HBOhAlScM6aw/C8C8hf0Tu3PBwFYtnEuZ8uSF/sq1o2
ysYBf1jutcs=
=XrR8
-END PGP SIGNATURE-

Bug#1002045: python3-aioresponses: Failed to import: No module named 'pkg_resources'

[Boyuan Yang]

Package: python3-aioresponses
Version: 0.7.2-1
Severity: grave
X-Debbugs-CC: d...@jones.dk
Tags: sid bookworm

Dear python-aioresponses maintainer,

After installing your package, the package cannot work when using "install
aioresponses":

% sudo apt install python3-aioresponses
% python3
Python 3.9.9 (main, Dec 16 2021, 23:13:29) 
[GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import aioresponses
Traceback (most recent call last):
  File "", line 1, in 
  File "/dev/shm/python-aioresponses/aioresponses/__init__.py", line 2, in

from .core import CallbackResult, aioresponses
  File "/dev/shm/python-aioresponses/aioresponses/core.py", line 21, in

from pkg_resources import parse_version
ModuleNotFoundError: No module named 'pkg_resources'
>>>

This error is also present in autopkgtest:
https://ci.debian.net/packages/p/python-aioresponses .

I believe this issue can be easily solved by explicitly adding python3-pkg-
resources into running dependency.

Since you are listed in the lowNMU list, I will upload a 0-day NMU shortly.
Let me know if you have any other issues.

-- 
Thanks,
Boyuan Yang


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

Bug#1001764: More info

[Dima Kogan]

Hi. Thanks for the bug report. I'm not clear on how to reproduce this so
that I can fix it.

I installed python3.10, and asked the build system to use it. Instead of
the error you're reporting, I get a build error: it can't find the numpy
headers because python3-numpy is built for python3.9. This makes sense.

What do I need to install to reproduce this bug?

Thanks.

Bug#1001680: O: libmp3-info-perl -- Perl MP3::Info - Manipulate / fetch info from MP3 audio files

[Damyan Ivanov]

Control: retitle -1 ITA: libmp3-info-perl -- Perl MP3::Info - Manipulate / 
fetch info from MP3 audio files
Control: owner -1 !

-=| Alexander Wirt, 14.12.2021 08:13:48 +0100 |=-
> Package: wnpp
> Severity: normal
> Control: affects -1 src:libmp3-info-perl
> 
> I intend to orphan the libmp3-info-perl package. That was a dependency
> for mp3burn and I don't need it anymore.
> 
> The package description is:
>  This Perl library gives a set of function for manipulating info tags in MP3
>  files and retrieving technical information from them.
>  .
>  This package was formerly known as MPEG::MP3Info and still has a wrapper
>  for applications that refer to it using the old name.
>  .
>  The Debian package also provides a simple tool for editing MP3 tags - mp3id.

I want to take over this package for the Debian Perl Group.

Even if it is said to be deprecated upstream and there is 
a replacement by the same upstream author packaged in Debian, there 
are still reverse dependencies so it can't be dropped yet.


-- dam

Bug#1002035: nodejs: sse2-support failure leaves dependencies in apt that cannot be met

[Jérémy Lal]

Le lun. 20 déc. 2021 à 21:11, J. William Campbell <
jwilliamcampb...@comcast.net> a écrit :

> Hi Jérémy,
>Thank you for your very prompt reply. I will reply in line to your
> responses.
>
> On 12/20/2021 11:14 AM, Jérémy Lal wrote:
>
> hello,
>
> NB: i am going to reply below, in chronological order.
> Please adopt the same style in future emails.
>
> Le lun. 20 déc. 2021 à 19:48, J. William Campbell <
> jwilliamcampb...@comcast.net> a écrit :
>
>> Package: nodejs
>> Version: 12.22.5~dfsg-2~11u1
>> Severity: important
>> X-Debbugs-Cc: jwilliamcampb...@comcast.net
>>
>> Dear Maintainer,
>>
>> I attempted to install package nodejs on an Intel processor that does not
>> support sse2 instructions. The library dependencies for nodejs require
>> the sse2 support. It is unclear to me why nodejs itself would require
>> such support, but in any case installing nodejs requires package
>> sse2-support, which will always fail to install on older CPUs. This in
>> itself, while disappointing, isn't a problem.
>
>
> Indeed, nodejs embeds another software (v8) that needs a lot of
> work for each architecture. Authors of v8 decided to simplify their
> work by supporting only a subset of available processors.
>
> To make sure, you can double-check that nodejs as distributed by
> their authors, does indeed *not* run on your system, by trying their
> own debian package, see instructions at:
> https://github.com/nodesource/distributions
>
> However, this failure occurs
>> fairly deep in the installation of packages. The result a package with
>> dependencies that cannot be statisfied. --fix-broken is of course unable
>> to
>> do so, because sse2-support will never install.
>>
>
> Yes, you cannot install sse2-support  on a system that doesn't support
> sse2.
> This is by design.
>
> Indeed it is by design. However, that design has serious drawbacks .
>
>
> I now have a broken apt configuration that I have been unable to fix. I
>> cannot remove/purge nodejs because of the unmet dependencies and I
>> cannot meet them because the required package will not ever install.
>>
>
> I'm not sure that you have a problem with nodejs debian package here.
> It looks, from the description of your problem, that you don't know how to
> deal with apt in that case.
> You should seek some help on that front.
>
> I have, at least in so far as lots of Google searches. Basically, I have
> got nowhere. The "normal" way to correct missing dependencies is to find a
> package that satisfies those dependencies and install it. This approach
> works even when your intention is to subsequently purge the package that
> caused the problem in the first place, but ONLY if you find and install
> such a package. Since sse2-support is designed to not install in this case,
> you can't ever do so. There are lots of attempts to solve similar problems
> by various combinations of approaches. None of them seem to work in this
> case. If you have a pointer to a method that will reliably remove packages
> with unmet dependencies, I would appreciate it.
>
>
> This is a serious annoyance. The package sse2-support is present only to
>> cause the install of the package to fail. It provides no code. A possible
>> fix would be to allow the user to force sse2-support to install in order
>> to
>> satisfy the dependencies so that the package nodejs will not be broken.
>> The user can then remove nodejs or go ahead with the understanding that if
>> sse2 instructions in the library are actually used a fault will occur. The
>> documentation does not warn that nodejs requires sse2-support, but even
>> if it did it is probable this fact would be unclear to many users.
>>
>> What I expected is that nodejs would install without problems, and that
>> if it did not it would not leave the package management on my Debian
>> system basically inoperative. That is where I am now, and I have been
>> unable
>> to find a solution.
>>
>
> I repeat here: on a i686 non-sse2 platform, you can't install nodejs.
> However, i hear you, there should be a more explicit way of failing
> installation
> of a package that is not available for a given processor.
>
> Indeed. Right now sse2-support pops up a failure screen informing you that
> your processor doesn't support the required instructions and returns an
> error code indicating the package was not installed. IMHO a better approach
> would be to throw the error but allow the user to proceed anyway (return a
> "success" code) by responding to a prompt. The user has been told the
> software won't work, so he has no right to expect it will. However, if the
> package is installed one can remove nodejs without problems. I understand
> that it might be real hard to "walk back" all the things that were already
> installed before the problem was detected. For that reason, a "work around"
> would be appropriate.
>

Now i think the problem you see comes from sse2-support package.
That bad a user experience is probably a bug somewhere.
Let's see what 

Bug#1001961: No longer properly hooks the stat call

[Christoph Biedl]

Control: tags 1001961 patch

Christoph Biedl wrote...

> it seems recent changes in libc6 caused the stat() call in C applications
> to be expanded in a different way, a way fakeroot does not properly
> handle, resulting in the real user-id, not 0.

Fix appended (inline, not a patch) for better readability. Tested
successfully on the following archs: amd64, i386, armel, armhf, arm64;
with both fakeroot(-sysv) and fakeroot-tcp.

Cheers,

Christoph

Subject: Also wrap the "stat" library call
Author: Christoph Biedl 
Date: 2021-12-20
Bug-Debian: https://bugs.debian.org/1001961

Seems changes in glibc 2.33 caused the stat() function to be mapped
into a stat() library call instead of __xstat() as it used to be.

However, fakeroot does not wrap this, causing files to be reported
with the real owner, not 0 as expected.

The fix for this got more ugly than wished as the abstraction in
configure.ac would not allow wrapping both "stat" and "__xstat". So
enhance the search list capabilities with an optional symbol how the
wrapped function is named internally. Also hack the parser so
"state" gets actually probed.

Using "realstat" is not the best choice as it might be confusing,
but "statstat" seemed even worse.

--- a/configure.ac
+++ b/configure.ac
@@ -353,9 +353,13 @@
 
 :>fakerootconfig.h.tmp
 
-for SEARCH in %stat f%stat l%stat f%statat %stat64 f%stat64 l%stat64 
f%statat64 %mknod %mknodat; do
-  FUNC=`echo $SEARCH|sed -e 's/.*%//'`
+for SEARCH in %stat s%tat@realstat f%stat l%stat f%statat %stat64 f%stat64 
l%stat64 f%statat64 %mknod %mknodat; do
+  FUNC=`echo $SEARCH|sed -e 's/.*%// ; s/@.*//'`
   PRE=`echo $SEARCH|sed -e 's/%.*//'`
+  PF_PRE=`echo $SEARCH|sed -e 's/.*@//'`
+  if test "$PF_PRE" = "$SEARCH" ; then
+PF_PRE="${PRE}${FUNC}"
+  fi
   FOUND=
   for WRAPPED in __${PRE}x${FUNC} _${PRE}x${FUNC} __${PRE}${FUNC}13 
${PRE}${FUNC}; do
 AC_CHECK_FUNCS($WRAPPED,FOUND=$WRAPPED)
@@ -366,8 +370,8 @@
 dnl  for WRAPPED in _${PRE}${FUNC}; do
 dnlFOUND=$WRAPPED
 if test -n "$FOUND"; then
-  PF=[`echo ${PRE}${FUNC}| tr '[a-z]' '[A-Z]'`]
-  DEFINE_WRAP=[`echo wrap_${PRE}${FUNC}| tr '[a-z]' '[A-Z]'`]
+  PF=[`echo $PF_PRE | tr '[a-z]' '[A-Z]'`]
+  DEFINE_WRAP=[`echo wrap_${PF_PRE}| tr '[a-z]' '[A-Z]'`]
   DEFINE_NEXT=[`echo wrap_${FOUND}| tr '[a-z]' '[A-Z]'`]
   DEFINE_ARG=[`echo wrap_${FOUND}| tr '[a-z]' '[A-Z]'`]
   AC_DEFINE_UNQUOTED(WRAP_${PF}, $FOUND)
@@ -509,6 +513,12 @@
 #define TMP_STAT  __astat
 #define NEXT_STAT_NOARG  next___astat
 
+#define WRAP_REALSTAT  __astat
+#define WRAP_REALSTAT_QUOTE  __astat
+#define WRAP_REALSTAT_RAW  __astat
+#define TMP_REALSTAT  __astat
+#define NEXT_REALSTAT_NOARG  next___astat
+
 #define WRAP_LSTAT_QUOTE  __astat
 #define WRAP_LSTAT  __astat
 #define WRAP_LSTAT_RAW  __astat


signature.asc
Description: PGP signature

Bug#1002044: python3-pkg-resources: test cruft in package

[Julian Gilbey]

Package: python3-pkg-resources
Version: 59.6.0-1

This package currently ships the file
/usr/lib/python3/dist-packages/pkg_resources/tests/data/my-test-package-source/setup.py
which seems to be a random part of the package's testsuite that
somehow got included in the final package.  It's the only file from
the testsuite included, which is just weird.

Best wishes,

   Julian

Bug#1002043: RM: lprng-doc -- ROM; Not used, orphaned for 18 months

[Craig Small]

Package: ftp.debian.org
Severity: normal

Hi ftp people,
  In January 2009 I RFA'ed lprng. In September 2020 cascardo made it an
orphan. It's basically been that since and I'm not even sure it has an
upstream.

This RM is for lprng-doc, the documentation of the orphaned lprng
package.

In July 2020 I orphaned the lprng-doc package. It's basically had
nothing done to it for ages. I'd like lprng-doc removed.

 - Craig

Bug#1001774: tm_isdst=1 with mktime produces unexpected output

[Aurelien Jarno]

On 2021-12-20 09:06, Daniel McDonald wrote:
> Dear Aurelian,
> 
> I can confirm that changing the timezone within Ubuntu 20.04 through Github 
> Actions resolves the bug. The default set timezone is “Etc/UTC” as reported 
> by “timedatectl”. Setting to “America/Los_Angeles” with “timedatectl” allows 
> for a passing workflow. A link to the pass, with contextual information, can 
> be found here (note, this is under a fork of CPython where this behavior was 
> being investigated):
> 
> https://github.com/wasade/cpython/runs/4584894670?check_suite_focus=true#step:17:76
> 
> While this is reassuring, it seems the behavior is qualitatively different 
> across operating systems (or glibc versions). I’m unsure if that is expected. 
> As an example, we pass on Ubuntu 18.04 without changing the timezone:
> 
> https://github.com/wasade/cpython/runs/4585124128?check_suite_focus=true#step:14:43

Ubuntu 18.04 seems to run glibc 2.27. Versions of glibc older than 2.29
are affected by bug #23789 [1], and do not report any error if the date
is not representable. This is arguably a bug in Ubuntu 18.04, but this
behaviour is expected.

Regards,
Aurelien


[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23789

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1002041: glibc: rc

[John David Anglin]

Source: glibc
Version: 2.34-0experimental2
Severity: normal

Dear Maintainer,

There are two new regressions in glibc 2.34 that need to be xfailed on
hppa:

+-+
| Encountered regressions that don't match expected failures. |
+-+
FAIL: dirent/tst-readdir64-compat
FAIL: signal/tst-minsigstksz-5
touch /<>/stamp-dir/check_libc
CHECK SUMMARY
check for check_libc failed
make: *** [debian/rules.d/build.mk:187: build-arch-post-check] Error 1
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


The dirent/tst-readdir64-compat failure is libc/27654.  This is apparently
a test issue.

The signal/tst-minsigstksz-5 failure is a known issue with the signal
trampoline which should be fixed when the kernel implements a vdso:
https://www.spinics.net/lists/linux-parisc/msg15397.html

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.14.21+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#988120: jigdo-file: Fails to re-use its own cache file correctly

[mwonl]

Hello,

I just wanted to report that I have noticed the same problem.

I usually mount all old DVD images in one parent directory. On update 
jigdo just scanned this whole directory for the first new DVD and 
created a jigdo-file-cache.db file. For all other following new DVDs 
jigdo-file-cache.db was used and no additional scan of the directory was 
done.


After upgrading to bullseye (and using jigdo-file 0.8.0-1) I see the 
same behaviour as reported in this bug. A complete rescan of the whole 
directory is done for EVERY DVD and jigdo-file-cache.db seems to be 
ignored. This is very time consuming compared to the old behaviour.


I just downgraded to the buster version 0.7.3-5+deb10u1 and the 
behaviour is like before and there is only one scan for the first new 
DVD and the created jigdo-file-cache.db is then used for the following 
new ones.


(Testing was done with the 11.2.0 jigdo images)

So it seems a bug was introduced which corrupts (?) jigdo-file-cache.db 
for directories with a (very) large number of files.


If needed I can do some debugging with my setup.

Best regards,

Mark

Bug#1002040: src:python-lupa: fails to migrate to testing for too long: FTBFS on mipsel

[Paul Gevers]

Source: python-lupa
Version: 1.9+dfsg-1
Severity: serious
Control: close -1 1.10+dfsg-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1001239

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:python-lupa has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package FTBFS on mipsel, 
which I reported two weeks ago.


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=python-lupa



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002039: embree: add arm64 architecture

[Stephan Lachnit]

Source: embree
Version: 3.13.2+dfsg-1
Severity: wishlist
X-Debbugs-Cc: stephanlach...@debian.org, m...@debian.org

Dear maintainer,

please consider adding support for arm64, as it seems to be supported by
embree, see [1] and [2] (under "Cross Platform").

Maybe this also gives an update to #976496 [3].

Regards,
Stephan

[1] https://github.com/embree/embree/releases/tag/v3.13.1
[2] https://www.embree.org/
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976496


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

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

Bug#1002038: noninteractive upgrade with UCF_FORCE_CONFFNEW=1 fail with ucf conflict

[lvlolotov]

Package: grub-pc
Version: 2.04-20

noninteractive upgrade with UCF_FORCE_CONFFNEW=1 fail with ucf conflict.
Error: Only one of force_conffold and force_conffnew should be set

Reproduce:
  - Modify sources.list for a new release.

  - Set ucf options
  export DEBIAN_FRONTEND=noninteractive
  unset UCF_FORCE_CONFFOLD
  export UCF_FORCE_CONFFNEW=1

  - noninteractive upgrade
  apt-get dist-upgrade
  ...
  Paramétrage de grub-pc (2.04-20) ...
  Error: Only one of force_conffold and force_conffnew should be set
  dpkg: erreur de traitement du paquet grub-pc (--configure) :
  installed grub-pc package post-installation script subprocess 
returned error exit status 1

  ...

From ucf source :
  if [ "X$force_conffold" != "X" -a "X$force_conffnew" != "X" ]; then
    echo >&2 "Error: Only one of force_conffold and force_conffnew should";
    echo >&2 "   be set";
    exit 1;
  fi

From /etc/ucf.conf :
  # Please note that only one of conf_force_conffold and
  # conf_force_conffnew should be set.

From grub-pc postinst script :
    # If the template configuration file hasn't changed, then no 
conflict is

    # possible.  ucf can't figure this out for itself since we apply
    # debconf-based customisations on top of the template configuration
    # file.
    if [ -e /var/lib/grub/ucf/grub.previous ] && \
   cmp -s /usr/share/grub/default/grub 
/var/lib/grub/ucf/grub.previous && \

   [ -e /etc/default/grub ]; then
  ucf_env=UCF_FORCE_CONFFOLD=1
    else
  ucf_env=
    fi

    env $ucf_env ucf --three-way --debconf-ok 
--sum-file=/usr/share/grub/default/grub.md5sum "$tmp_default_grub" 
/etc/default/grub

    cp -aZ /usr/share/grub/default/grub /var/lib/grub/ucf/grub.previous

I suggest that grub postinst script should honor ucf options specified 
by commandline or in /etc/ucf.conf file.
If UCF_FORCE_CONFFNEW is true or conf_force_conffnew=YES is set in 
/etc/ucf.conf then we should not try to define UCF_FORCE_CONFFOLD in 
postinst.

grub-efi packages have the same behaviour :
  grub-efi-amd64
  grub-efi-amd64-signed
  shim-signed

I'm using Debian GNU/Linux 11 (bullseye) Kernel 5.10.70-1 (2021-09-30) 
x86_64 GNU/Linux.

Bug#995467: Salvaging status

[Wesley W. Terpstra]

Can I pass the baton of mlton package ownership off to someone?

I've been intending to some day come back to working on this, but the
reality is, I probably never will.
I'd be happy to answer questions about how to get things to work, if that
is helpful.

You need someone who either is currently or wants to become a debian
developer (and go through that whole process).

On Mon, Dec 20, 2021 at 11:39 AM Henry Cejtin 
wrote:

> I built the pdf guide a while ago, and I noticed a few problems that I
> managed to work around.
>
> One point is that you need to have lots of other packages installed, and
> if you don't, it doesn't say anything clear.
>
> I installed all of the following to make it work:
>
> asciidoc
> texlive-full
> docbook
> source-highlight
> context-nonfree
> context-doc-nonfree
> docbook-dsssl-doc
> docbook-defguide
> python-apt-doc
> vim-doc
> w3m
> lynx
> links
> vim-scripts
> epubcheck
> sgmls-doc
>
> (This was a while ago, under Debian Stretch.)
>
> A second point is that under Buster and Bullseye, the convert program
> (from ImageMagick) won't accept pdf's.  The reason has to do with an old
> Ghostscript but and security concerns.
>
> This problem of convert losing this capability also causes the Debian
> package pdfsandwich to no longer work.  It is all a real problem.  Note,
> that there are many other ways to do what needs to be done.  To put
> images into a pdf you can use the Debian package img2pdf.  To go the
> other way, you can use pdfimages or pdftocairo (in poppler-utils).
>
> Somehow it seems that this should be fixed in the imagemagick package
> since there must be other programs that depend on it.
>
> I agree with the comments from people about it probably not being a good
> idea to just edit /etc/ImageMagick-6/policy.xml to let Ghostscript do
> stuff.  That definitely makes me too nervous to do.
>
> On Sun, Dec 19, 2021 at 9:33 PM Ryan Kavanagh  wrote:
> >
> > Another status update for those following at home:
> >
> > The mlton package (upstream release 20210117) now bootstraps and builds!
> >
> > For some reason I can't get the guide to compile (pdflatex spits out a
> > bunch of errors and then dies, and the tool that calls pdflatex suggests
> > the docbook input is invalid), so I might just temporarily disable
> > building/installing it. I figure having an installable mlton package
> > sans PDF guide is better than having no mlton package whatsoever in the
> > meantime.
> >
> > I have considerably more time to work on this now that the semester is
> > over, so I'm hoping to get it uploaded in the next week or so.
> >
> > Best,
> > Ryan
> >
> > --
> > |)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
> > |\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A
>

Bug#998697: ITP: bees -- a btrfs deduplication agent

[Felix Zielcke]

Am Samstag, dem 06.11.2021 um 21:32 +0300 schrieb Alexander GQ
Gerasiov:
> Package: wnpp
> Severity: wishlist
> Owner: Alexander GQ Gerasiov 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name    : bees
>   Version : 0.7
>   Upstream Author : Zygo Blaxell b...@furryterror.org
> * URL : https://github.com/Zygo/bees
> * License : GPL-3+
>   Programming Lang: C++
>   Description : a btrfs deduplication agent
> 
> Best-Effort Extent-Same, a btrfs deduplication agent.
> 
> bees is a block-oriented userspace deduplication agent designed for
> large
> btrfs filesystems. It is an offline dedupe combined with an
> incremental data
> scan capability to minimize time data spends on disk from write to
> dedupe.
> 

Hi Alexander,

I totally forgot to look if there's already an ITP filed when I did my
one #1002036.

How far are you with packaging? And do you want a Co-Maintainer? Though
I'm only a DM not DD.

I just did a first version of a Debian package avaible at:
https://salsa.debian.org/fzielcke/bees/

Feel free to use anything of it.

Regards,
Felix

Bug#995467: Salvaging status

[Henry Cejtin]

I built the pdf guide a while ago, and I noticed a few problems that I
managed to work around.

One point is that you need to have lots of other packages installed, and
if you don't, it doesn't say anything clear.

I installed all of the following to make it work:

asciidoc
texlive-full
docbook
source-highlight
context-nonfree
context-doc-nonfree
docbook-dsssl-doc
docbook-defguide
python-apt-doc
vim-doc
w3m
lynx
links
vim-scripts
epubcheck
sgmls-doc

(This was a while ago, under Debian Stretch.)

A second point is that under Buster and Bullseye, the convert program
(from ImageMagick) won't accept pdf's.  The reason has to do with an old
Ghostscript but and security concerns.

This problem of convert losing this capability also causes the Debian
package pdfsandwich to no longer work.  It is all a real problem.  Note,
that there are many other ways to do what needs to be done.  To put
images into a pdf you can use the Debian package img2pdf.  To go the
other way, you can use pdfimages or pdftocairo (in poppler-utils).

Somehow it seems that this should be fixed in the imagemagick package
since there must be other programs that depend on it.

I agree with the comments from people about it probably not being a good
idea to just edit /etc/ImageMagick-6/policy.xml to let Ghostscript do
stuff.  That definitely makes me too nervous to do.

On Sun, Dec 19, 2021 at 9:33 PM Ryan Kavanagh  wrote:
>
> Another status update for those following at home:
>
> The mlton package (upstream release 20210117) now bootstraps and builds!
>
> For some reason I can't get the guide to compile (pdflatex spits out a
> bunch of errors and then dies, and the tool that calls pdflatex suggests
> the docbook input is invalid), so I might just temporarily disable
> building/installing it. I figure having an installable mlton package
> sans PDF guide is better than having no mlton package whatsoever in the
> meantime.
>
> I have considerably more time to work on this now that the semester is
> over, so I'm hoping to get it uploaded in the next week or so.
>
> Best,
> Ryan
>
> --
> |)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
> |\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A

Bug#996051: extension compatibility with GNOME Shell 41

[Gunnar Hjalmarsson]

Control: tags -1 - fixed-upstream

It's not clear to me why the upstream issue was closed. I see nothing 
which indicates that the bug has been fixed.


--
Gunnar Hjalmarsson

Bug#1002035: nodejs: sse2-support failure leaves dependencies in apt that cannot be met

[Jérémy Lal]

hello,

NB: i am going to reply below, in chronological order.
Please adopt the same style in future emails.

Le lun. 20 déc. 2021 à 19:48, J. William Campbell <
jwilliamcampb...@comcast.net> a écrit :

> Package: nodejs
> Version: 12.22.5~dfsg-2~11u1
> Severity: important
> X-Debbugs-Cc: jwilliamcampb...@comcast.net
>
> Dear Maintainer,
>
> I attempted to install package nodejs on an Intel processor that does not
> support sse2 instructions. The library dependencies for nodejs require
> the sse2 support. It is unclear to me why nodejs itself would require
> such support, but in any case installing nodejs requires package
> sse2-support, which will always fail to install on older CPUs. This in
> itself, while disappointing, isn't a problem.


Indeed, nodejs embeds another software (v8) that needs a lot of
work for each architecture. Authors of v8 decided to simplify their
work by supporting only a subset of available processors.

To make sure, you can double-check that nodejs as distributed by
their authors, does indeed *not* run on your system, by trying their
own debian package, see instructions at:
https://github.com/nodesource/distributions

However, this failure occurs
> fairly deep in the installation of packages. The result a package with
> dependencies that cannot be statisfied. --fix-broken is of course unable to
> do so, because sse2-support will never install.
>

Yes, you cannot install sse2-support  on a system that doesn't support sse2.
This is by design.

I now have a broken apt configuration that I have been unable to fix. I
> cannot remove/purge nodejs because of the unmet dependencies and I
> cannot meet them because the required package will not ever install.
>

I'm not sure that you have a problem with nodejs debian package here.
It looks, from the description of your problem, that you don't know how to
deal with apt in that case.
You should seek some help on that front.

This is a serious annoyance. The package sse2-support is present only to
> cause the install of the package to fail. It provides no code. A possible
> fix would be to allow the user to force sse2-support to install in order to
> satisfy the dependencies so that the package nodejs will not be broken.
> The user can then remove nodejs or go ahead with the understanding that if
> sse2 instructions in the library are actually used a fault will occur. The
> documentation does not warn that nodejs requires sse2-support, but even
> if it did it is probable this fact would be unclear to many users.
>
> What I expected is that nodejs would install without problems, and that
> if it did not it would not leave the package management on my Debian
> system basically inoperative. That is where I am now, and I have been
> unable
> to find a solution.
>

I repeat here: on a i686 non-sse2 platform, you can't install nodejs.
However, i hear you, there should be a more explicit way of failing
installation
of a package that is not available for a given processor.

Jérémy

Bug#1000803: autopkgtest: avoid duplication with autopkgtests and how unittests are run at build-time

[Antonio Terceiro]

On Wed, Dec 01, 2021 at 08:19:20PM -0300, Antonio Terceiro wrote:
> Hi,
> 
> Adding debian-python@l.d.o
> 
> The context is #1000803 where Sandro asked about reducing duplication
> when running upstream test suites both during the build and under
> autopkgtest.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000803
> 
> On Tue, Nov 30, 2021 at 12:47:42AM -0500, Sandro Tosi wrote:
> > > This is usually solved outside of autopkgtest itself.
> > >
> > > For example Ruby packages have a single place where tests are specified
> > > (debian/ruby-tests.*{rb,rake,yaml}, and the appropriate
> > > debian/tests/control file is autogenerated by autodep8. I would say 99%
> > > of Ruby packages require no duplication, or even explicitly specifying
> > > commands to run tests at all.
> > >
> > > In general, this is most efficiently solved by package type (e.g.
> > > programming language), because the way the tests are run at build-time
> > > usually is tied to the build system. You then usually need some test
> > > runner, probably extracted from, or provided by, the build system, to
> > > also provide the same funcionality in an autopkgtest-compatible way.
> > >
> > > All the package types that are well supported in autodep8 have their
> > > specialized test runner tools that avoid this type of duplication.
> > 
> > I'm mostly interested in the python ecosystem, and the provided
> > autodep8 test are extremely superficial (essentially only importing
> > the main python module packaged), which is better than nothing but not
> > the same level as what's in d/rules.
> > 
> > Are you aware of any effort to expand the Python autodep8 tests to
> > uniform them into a comprehensive, and unique place to run tests at
> > build-time and via autopkgtest?
> 
> I'm not.
> 
> > If no such effort currently exists, what would one have to do to start
> > developing it? Not necessarily volunteering, just gathering
> > information.
> 
> In general terms, I see this being implemented like this:
> 
> 0) modify pybuild so one can call e.g. `pybuild --autopkgtest`. That
> should work almost the same as `pybuild --test`, but would copy the test
> files under ${AUTOPKGTEST_TMP} and run the tests from there, instead of
> assuming a previously built tree and trying to chdir into
> .pybuild/*/build.
> 
> 1) add a way of being able to specify pybuild parameters outside of
> debian/rules that can be used both during the build and under
> autopkgtest
> 
>For Ruby, gem2deb-test-runner is driven by debian/ruby-tests.*, both
>during the build, and under autopkgtest.
> 
>In pybuild, some aspects of the test run can already be done this
>way, e.g. debian/pybuild.testfiles. Maybe we could have
>debian/pybuild.env to read options in the same way as they are set in
>debian/rules today (with environment variables).
> 
> 2) update autodep8 to generate the appropriate control file to call
>`pybuild --autopkgtest`. This needs to be "smart" enough to not
>automatically add this call to packages that are not ready for it. At
>the moment, almost 1000 source packages have
>`Testsuite: autopkgtest-pkg-python`. We would probably need a new
>value, or (probably better) to additionally check for something else
>in the source tree.
> 
> Each item has quite some details to be figured out, but this is the
> general idea.

I have written a prototype implementation of this, and published it as
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27


signature.asc
Description: PGP signature

Bug#1002036: ITP: bees -- Best-Effort Extent-Same, a btrfs deduplication agent.

[Jérémy Lal]

Le lun. 20 déc. 2021 à 19:45, Felix Zielcke  a écrit :

> Package: wnpp
> Severity: wishlist
> Owner: Felix Zielcke 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: bees
>   Version : 0.7
>   Upstream Author : Zygo Blaxell b...@furryterror.org
> * URL : https://github.com/Zygo/bees
> * License : GPL-3+
>   Programming Lang: C++
>   Description : Best-Effort Extent-Same, a btrfs deduplication agent.
>
>  bees is a block-oriented userspace deduplication agent designed for
>  large btrfs filesystems. It is an offline dedupe combined with an
>  incremental data scan capability to minimize time data spends on disk
>  from write to dedupe.
>
> I'm happy to maintain it inside a team or with co-maintainer(s).
> I'm only DM so if someone has interest in sponsoring this, feel free to
> contact me.
>
> First debianized version avaible at https://salsa.debian.org/fzielcke/bees
>
> I guess it's a problem for ftp-masters that copyright and license is only
> mentioned inside README.md, but not directly at the source files?
>

The mentions in the README.md and the license in COPYING are just exactly
what is expected by everyone here.
But what you actually need is a mentor, i guess:
https://mentors.debian.net/

Jérémy


> Then it can't yet be uploaded.
>
>

Bug#1002037: heartbeat: Heartbeat 3.0.6-11 will not start on bullseye

[Adam Thorn]

Package: heartbeat
Version: 1:3.0.6-11
Severity: important

Dear Maintainer,

The heartbeat service as provided by 3.0.6-11 cannot start on Debian
bullseye, as reported in #993575.  I see the same behaviour as reported
in #993575, and have confirmed that if I manually install 3.0.6-12 from
testing then the service will start successfully.

Could the fix from 3.0.6-12, which distributes

  /usr/lib/tmpfiles.d/heartbeat.conf

as part of the deb, be backported/released for bullseye please?


-- System Information:
Debian Release: 11.2
  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-10-amd64 (SMP w/2 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 heartbeat depends on:
ii  adduser  3.118
ii  cluster-glue 1.0.12-20
ii  gawk 1:5.1.0-1
ii  iproute2 5.10.0-4
ii  iputils-ping [ping]  3:20210202-1
ii  libc62.31-13+deb11u2
ii  libglib2.0-0 2.66.8-1
ii  libheartbeat21:3.0.6-11
ii  libpam-runtime   1.4.0-9+deb11u1
ii  libpils2 1.0.12-20
ii  libplumb21.0.12-20
ii  libplumbgpl2 1.0.12-20
ii  libstonith1  1.0.12-20
ii  libxml2-utils2.9.10+dfsg-6.7
ii  psmisc   23.4-2
ii  python3  3.9.2-3
ii  resource-agents  1:4.7.0-1

Versions of packages heartbeat recommends:
pn  iptables 
ii  logrotate3.18.0-2
pn  pacemaker
ii  rsyslog [system-log-daemon]  8.2102.0-2

heartbeat suggests no packages.

-- no debconf information

Bug#1002036: ITP: bees -- Best-Effort Extent-Same, a btrfs deduplication agent.

[Felix Zielcke]

Package: wnpp
Severity: wishlist
Owner: Felix Zielcke 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: bees
  Version : 0.7
  Upstream Author : Zygo Blaxell b...@furryterror.org
* URL : https://github.com/Zygo/bees
* License : GPL-3+
  Programming Lang: C++
  Description : Best-Effort Extent-Same, a btrfs deduplication agent.

 bees is a block-oriented userspace deduplication agent designed for
 large btrfs filesystems. It is an offline dedupe combined with an
 incremental data scan capability to minimize time data spends on disk
 from write to dedupe.

I'm happy to maintain it inside a team or with co-maintainer(s).
I'm only DM so if someone has interest in sponsoring this, feel free to
contact me.

First debianized version avaible at https://salsa.debian.org/fzielcke/bees

I guess it's a problem for ftp-masters that copyright and license is only
mentioned inside README.md, but not directly at the source files?
Then it can't yet be uploaded.

Bug#1002035: nodejs: sse2-support failure leaves dependencies in apt that cannot be met

[J. William Campbell]

Package: nodejs
Version: 12.22.5~dfsg-2~11u1
Severity: important
X-Debbugs-Cc: jwilliamcampb...@comcast.net

Dear Maintainer,

I attempted to install package nodejs on an Intel processor that does not
support sse2 instructions. The library dependencies for nodejs require
the sse2 support. It is unclear to me why nodejs itself would require
such support, but in any case installing nodejs requires package
sse2-support, which will always fail to install on older CPUs. This in
itself, while disappointing, isn't a problem. However, this failure occurs
fairly deep in the installation of packages. The result a package with
dependencies that cannot be statisfied. --fix-broken is of course unable to
do so, because sse2-support will never install.

I now have a broken apt configuration that I have been unable to fix. I
cannot remove/purge nodejs because of the unmet dependencies and I
cannot meet them because the required package will not ever install.

This is a serious annoyance. The package sse2-support is present only to
cause the install of the package to fail. It provides no code. A possible
fix would be to allow the user to force sse2-support to install in order to
satisfy the dependencies so that the package nodejs will not be broken.
The user can then remove nodejs or go ahead with the understanding that if
sse2 instructions in the library are actually used a fault will occur. The
documentation does not warn that nodejs requires sse2-support, but even
if it did it is probable this fact would be unclear to many users.

What I expected is that nodejs would install without problems, and that
if it did not it would not leave the package management on my Debian
system basically inoperative. That is where I am now, and I have been unable
to find a solution.

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

Kernel: Linux 5.10.0-9-686 (SMP w/1 CPU thread)
Locale: LANG=C, 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 nodejs depends on:
ii  libc6  2.31-13+deb11u2
iu  libnode72  12.22.5~dfsg-2~11u1

Versions of packages nodejs recommends:
ii  ca-certificates  20210119
ii  nodejs-doc   12.22.5~dfsg-2~11u1

Versions of packages nodejs suggests:
pn  npm  

-- no debconf information

Bug#1002034: f2fs-tools: resize.f2fs always fails with Error: Device size is not sufficient for F2FS volume, more segment needed

[Marcel Partap]

Package: f2fs-tools
Version: 1.14.0-2
Severity: normal
X-Debbugs-Cc: mpar...@gmx.net

c.f. https://bugs.archlinux.org/task/71801

Version from git seems to work fine.


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, 
TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 f2fs-tools depends on:
ii  libblkid12.37.2-4
ii  libc62.33-1
ii  libselinux1  3.1-3
ii  libuuid1 2.36.1-8

f2fs-tools recommends no packages.

f2fs-tools suggests no packages.

-- debconf-show failed

Bug#999524: python-language-server: FTBFS with numpy 1.21 (in experimental): dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[Julian Gilbey]

On Thu, Nov 25, 2021 at 09:35:24PM +0100, Drew Parsons wrote:
> Source: python-language-server
> Followup-For: Bug #999524
> 
> Upstream lost write access to the python-language-server repo
> https://github.com/palantir/python-language-server/issues/935
> so have forked the project to python-lsp-server at
> https://github.com/python-lsp/python-lsp-server
> 
> As part of the move they renamed the module from pyls to pylsp.
> 
> The new version is packaged and available (python3-pylsp,
> src:python-lsp-server).
> 
> python-language-server can be removed once spyder is updated for pylsp.

Indeed!

Spyder is waiting for three packages to migrate from NEW, and then it
can be upgraded to 5.2.0; most of my packaging work is already in
salsa, and I'm just working on the autopkgtest suite at the moment.

Best wishes,

   Julian

Bug#997478: bug 997478 is forwarded to https://github.com/rupert/pyls-black/issues/36

[Julian Gilbey]

On Mon, Dec 06, 2021 at 11:14:06PM +0200, Adrian Bunk wrote:
> forwarded 997478 https://github.com/rupert/pyls-black/issues/36
> thanks

Thanks Adrian!

The way we're going to resolve this bug, though, is to upgrade Spyder
to version 5.2.0, which depends on pylsp-black instead, and then
request the removal of this package from Debian.

Best wishes,

   Julian

Bug#989490: docker: systemd shutdown script takes a long time waiting for containers that aren't running?

[Felix Geyer]

Control: tags -1 patch

On Tue, 12 Oct 2021 13:47:08 +0200 pedeb  wrote:

Hi Andrew,

Looks like the systemd unit is not properly configured. I had the same 
the same problem and here is a solution.


Meanwhile this is not solved in debian, you can place the systemd unit 
in a way that is not going to be changed because of upgrades


```
cp -p /lib/systemd/system/docker.service /etc/systemd/system/docker.service
```

and reload systemd daemon

```
systemctl daemon-reload
```

the solution is changing the systemd unit this way [0]


I've opened a merge request at 
https://salsa.debian.org/go-team/packages/docker/-/merge_requests/6

Bug#1002033: RFP: lpairs2 -- Classic memory game with nice graphics

[Antoni Aloy Torrens]

Package: wnpp
Severity: wishlist


LPairs2 is a memory game with 2x36 high resolution animal cards where 
you turn over any two cards and if they match they get removed. If they 
don't match they are turned back over. The game is over when all cards 
have been matched. You can play with different set sizes in fullscreen 
(6x4 to 12x6) or windowed mode (6x4 to 10x7). And for anyone who's bored 
by just matching pairs: You can try to match triplets and quadruplets as 
well. There is also a 2-player mode with a CPU opponent.


It is easy to create own themes with other pictures (submissions are 
welcome, please check out the README).


This game requires SDL2[1], SDL2 Image[2], SDL2 Mixer[3] and SDL2 TTF[4].


* Package name: lpairs2
* Version: 2.1
* License: GPL-3.0-or-later
* Upstream author: Michael Speck
* URL: https://lgames.sourceforge.io/LPairs/
* Language: C, C++


[1] http://www.libsdl.org/
[2] http://www.libsdl.org/projects/SDL_image/
[3] http://www.libsdl.org/projects/SDL_mixer/
[4] http://www.libsdl.org/projects/SDL_ttf/

Bug#1002031: liquidprompt : does not remove temperature warning when temperature goes down

[Erwan David]

Package: liquidprompt
Version: 2.0.3-1
Severity: normal

When I start a task with high CPU usage temperature rise, and I see a warning in
liquidprompt
⌁ θ82° edavid@maine-ocean:~ %

However after temprature goes down, the warning stays. If I open a new shell, no
warning.



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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

liquidprompt depends on no packages.

liquidprompt recommends no packages.

Versions of packages liquidprompt suggests:
ii  acpi1.7-1.1
ii  lm-sensors  1:3.6.0-7

-- no debconf information

Bug#1002032: sha1cdsum: The long description could be improved

[Sylvestre Ledru]

Package: sha1cdsum
Severity: minor

Dear Maintainer,

The current description is:
---
 This package contains the following binaries built from the Rust crate
 "sha1collisiondetection":
  - sha1cdsum
---

It could be improved a bit :)

Thanks
Sylvestre


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (500, 'oldoldstable'), (500, 
'stable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#1002030: RFS: swish++/6.1.5-6 [QA] [RC] -- Simple Document Indexing System for Humans: C++ version

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "swish++":

 * Package name: swish++
   Version : 6.1.5-6
   Upstream Author :
 * URL : http://swishplusplus.sourceforge.net/
 * License :
 * Vcs : https://salsa.debian.org/debian/swishplusplus
   Section : web

It builds those binary packages:

  swish++ - Simple Document Indexing System for Humans: C++ version

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

  https://mentors.debian.net/package/swish++/

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/swish++/swish++_6.1.5-6.dsc

Changes since the last upload:

 swish++ (6.1.5-6) unstable; urgency=medium
 .
   [ Tobias Frost ]
   * QA upload.
   * Moved repository to salsa.debian.org.
 .
   [ Ondřej Nový ]
   * d/changelog: Remove trailing whitespaces
   * d/rules: Remove trailing whitespaces
   * d/watch: Use https protocol
 .
   [ Debian Janitor ]
   * Trim trailing whitespace.
   * Add missing ${misc:Depends} to Depends for swish++.
   * debian/rules: Use dh_prep rather than "dh_clean -k".
   * Set debhelper-compat version in Build-Depends.
   * Remove patches fix_splitmail_manpage that are missing from
 debian/patches/series.
 .
   [ Håvard Flaget Aasen ]
   * Refresh all patches using quilt.
   * Change to dh sequencer. Closes: #838727
 - This includes target build-arch and build-indep. Closes: #998917
 - Build also respects DEB_BUILD_OPTIONS nostrip and noopt. Closes:
#908047
   * d/watch: Bump to version 4.
   * Change capitalization on Vcs* fields.
   * Bump debhelper to 13.
   * Drop quilt as build dependency.
   * Convert d/email_indexing/nnir.el to utf-8
   * Document Root-Requires-Root.
   * Update Standards-Version to 4.6.0.

Regards,
Håvard

Bug#1002029: postgresql-14 JIT failure with LLVM 13 on s390x: ERROR: failed to JIT module: Added modules have incompatible data layouts

[Christoph Berg]

Source: llvm-toolchain-13
Version: 1:13.0.0-9
Severity: important

Hi,

after switching from LLVM 11 to LLVM 13 for postgresql-14's JIT
mechanism, JIT fails on s390x with

2021-12-03 11:07:38.194 UTC client backend[815426] pg_regress/tablespace ERROR: 
 failed to JIT module: Added modules have incompatible data layouts: 
E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64 (module) vs 
E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64 (jit)

https://buildd.debian.org/status/fetch.php?pkg=postgresql-14=s390x=14.1-3=1638529682=0

The other architectures are fine (armel/armhf fail for a gcc-11 ICE).

Christoph

Bug#196513:

[tagba martin]

שלום ערב טוב, אנא התקשר אליי עכשיו או השב למייל ששלחתי לך מאתמול

Bug#643021:

[tagba martin]

שלום ערב טוב, אנא התקשר אליי עכשיו או השב למייל ששלחתי לך מאתמול

Bug#548845: screen: Please support displaying caption on the top

[Axel Beckert]

Hi Steve,

Steve Dodd wrote:
> There seems to be a patch available here:
> https://github.com/brauner/screen/commit/2111bd2fa42d0dd20ef7ac09a599c892b7910c3c
> - I can't work out if it has been upsteamed, as Savannah seems to be
> down ..

Seems to be in the master branch, but not in the screen-v4 branch from
where the stable releases are made for as of now. The "fixed-upstream"
tag on the bug report page also hints towards that direction.

P.S.: Please use a (preferably meaningful) subject next time.

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

Bug#1002028: ITP: r-cran-palmerpenguins -- GNU R Palmer Archipelago (Antarctica) penguin data

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-palmerpenguins -- GNU R Palmer Archipelago (Antarctica) 
penguin data
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-palmerpenguins
  Version : 0.1.0
  Upstream Author : Allison Horst,
* URL : https://cran.r-project.org/package=palmerpenguins
* License : CC0
  Programming Lang: GNU R
  Description : GNU R Palmer Archipelago (Antarctica) penguin data
 Size measurements, clutch observations, and blood isotope ratios for
 adult foraging Adélie, Chinstrap, and Gentoo penguins observed on
 islands in the Palmer Archipelago near Palmer Station, Antarctica. Data
 were collected and made available by Dr. Kristen Gorman and the Palmer
 Station Long Term Ecological Research (LTER) Program.

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

Bug#727021: Bug#965846: ufiformat: diff for NMU version 0.9.9-1.1

[Stephen Kitt]

You’re very welcome! I hope the changes aren’t too invasive; since short 
dh “just worked”, including cross-compilation, I went with that.


Regards,

Stephen


Le 20/12/2021 17:44, David Given a écrit :

Thank you for fixing these; I completely missed both of these bugs when 
they got filed.


On Mon, 20 Dec 2021 at 15:33, Stephen Kitt  wrote:


Package: ufiformat
Version: 0.9.9-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for ufiformat (versioned as 0.9.9-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

Stephen

Bug#965846: ufiformat: diff for NMU version 0.9.9-1.1

[David Given]

Thank you for fixing these; I completely missed both of these bugs when
they got filed.

On Mon, 20 Dec 2021 at 15:33, Stephen Kitt  wrote:

> Package: ufiformat
> Version: 0.9.9-1
> Severity: normal
> Tags: patch  pending
>
> Dear maintainer,
>
> I've prepared an NMU for ufiformat (versioned as 0.9.9-1.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.
>
> Regards,
>
> Stephen
>

Bug#1002027: bumpversion: finalize migration to bump2version

[Lars Kruse]

Source: bumpversion
Version: 1.0.1-1
Severity: wishlist

Dear Maintainer,

thank you for moving to the new upstream (bump2version, #916498)!

Could you please add the following minor corrections in order to
properly inform users of the new state of the package:

* change `Homepage` in `d/control` to the new upstream
* mention the switch to a new upstream implementation in `d/changelog`
  (for v1.0.0)

Thank you for maintaining this package!

Cheers,
Lars

Bug#986201: [Debian-med-packaging] Bug#986201: fsm-lite: Please provide autopkgtest

[Andreas Tille]

Hi,

Am Mon, Dec 20, 2021 at 07:12:48PM +0530 schrieb Nilesh Patra:
> On 12/20/21 7:07 PM, Lance Lin wrote:
> > Hi Nilesh, Andreas,
> > I chose this approach over static text comparisons since this will work for 
> > any input .FASTA file instead of searching for hard-coded values such as 
> > '1508'. I am open to your feedback and any improvements.
> > 
> > https://salsa.debian.org/med-team/fsm-lite/-/merge_requests/1
> 
> Thanks Lance, I left a review on your PR. can you address that?

I merged the change and did some fixes.  Please note that AUTOPKGTEST_TMP
is a fixed variable name in CI tests and we should stick to this.  Moreover
it is in general to stick to pure POSIX shell syntax and not to rely on
bash features like [[ ]] if not necessariy.  Finally there was some issue
with the comparison itself.

So far the test works now but I fully agree with Nilesh that an md5sum
based test (as for install in maffilter, probabel and many others) is
better here.  It would be great if you could change it that way.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1001626: enlightenment: Starting gkrellm or qmmp, enlightenment process takes too much cpu cycles

[Adrian Immanuel Kiess]

Dear Ross,

thank you for your answer.

I talked to raster at the #e IRC-channel.

The cause seems to be the shaped windows, like gkrellm owns.

He suggested, I should change the default gkrellm theme.

This worked fine for a locally running gkrellm.

When using remote GTK applications over SSH, the shaped windows of my
current GTK seems to be the issue.

In addition to that, what also adds to the cause is the connection to
my virtual private server using SSH. Using another network connection to
a local VM, the issue is not present.

To fix this, I think I'll need faster hardware then. 

You can close this bug-report.

Thank you for your kind help.

Sincerely,

Adrian

On Wed, 15 Dec 2021 21:51:57 -0800
Ross Vandegrift  wrote:

> On Wed, Dec 15, 2021 at 11:37:24AM +0100, Adrian Immanuel Kiess wrote:
> > I can sharpen this in the way that I use the gkrellm instances remotely
> > over SSH connections. Also, other GTK+/GNOME3 applications executed
> > remotely over SSH and displayed locally on my Enlightenment XOrg window
> > manager session take a lot of high CPU% cycles.
> > 
> > Maybe this helps identify the bottle-neck.
> > 
> > Sometimes it takes a low CPU% percentage at start right after booting
> > into Englightenment, but having eight gkrellm instances (seven remotely
> > via SSH) make take Enlightenment one full CPU core after having it
> > run for a while. 
> > 
> > This does not happen when I don't run gkrellm. Enlightenment takes as
> > low as 0,7-6% CPU% usage, even after having running Enlightenment for
> > two days. Spurring on gkrellm, the same affect happens again.
> > 
> > Changing the refresh time/rate of gkrellm in the gkrellm preferences
> > does not change the effect.
> 
> That's strange - changing the refresh rate has a large impact for me.  At 
> 20Hz,
> enlightenment uses ~25%; at 1Hz, enlightenment uses ~2%.  Running local vs
> remote over ssh doesn't seem to make any difference.
> 
> > I hope this can be fixed! If no solution can be found (maybe it has to
> > do with some library, I don't know) I will contact 
> > https://www.enlightenment.org/contact.
> 
> Good luck!
> 
> Ross


-- 
With many greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Gothaer Straße 34
D-04155 Leipzig

 — < adr...@kiess.onl >

--SYSTEM--
echo "Your fortune cookie: " && /usr/games/fortune -c -s de
> (zitate) % Die Hölle kann auch produktiv sein, der Himmel ist nur langweilig. 
> -- Herbert Achternbusch

echo "g6.lan.dac uptime: " && /usr/bin/uptime
> 17:29:26 up 6 days, 4:26, 14 users, load average: 0,75, 1,38, 1,62

Bug#1002026: python3-fabric is missing python3-decorator when fabric package is not installed

[Bolesław Tokarski]

Package: python3-fabric
Version: 2.5.0-0.3
Severity: serious
Justification: Policy 3.5
X-Debbugs-Cc: boleslaw.tokar...@gmail.com

Dear Maintainer,

This is a follow-up on bug 956320.

I installed python3-fabric, and created some simple code using the library. I 
got:

Traceback (most recent call last):
  File "script.py", line 2, in 
from fabric import Connection
  File "/usr/lib/python3/dist-packages/fabric/__init__.py", line 3, in 
from .connection import Config, Connection
  File "/usr/lib/python3/dist-packages/fabric/connection.py", line 10, in 

from decorator import decorator
ModuleNotFoundError: No module named 'decorator'

I do not need the 'fabric' package to use python3-fabric as a library. The
dependency should not be in the fabric package, but in the python3-fabric
package. Actually, just like the bug description says, "python3-fabric:
Missing dependency on python3-decorator".

Installing python3-decorator solves the problem, thus it should be a
dependency of python3-fabric, and cleared from the 'fabric' package
dependencies, since it will get pulled with python3-fabric.

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

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 python3-fabric depends on:
ii  python3   3.9.2-3
ii  python3-invoke1.4.1+ds-0.1
ii  python3-paramiko  2.7.2-1

python3-fabric recommends no packages.

python3-fabric suggests no packages.

-- no debconf information

Bug#820708: autopkgtest if cge works with current libpng version

[Michalis Kamburelis]

Note that Castle Game Engine contains a number of automatic tests that load PNG 
images already.

In particular tests/code/testcastleimages.pas loads various PNG images, 
checking that the type (like RGBA) and sizes are correct. See 
https://github.com/castle-engine/castle-engine/blob/master/tests/code/testcastleimages.pas
 .

This testcase is executed as part of large application in tests/, using 
FpcUnit, and Debian already executes this testsuite automatically as far as I 
know.

The one thing we don't test there is whether we actually use LibPng, not some 
other PNG-reading library.


CGE by itself will automatically fallback from LibPng to FpImage (in CGE 
7.0-alpha1) if LibPng is not found. This is acceptable for CGE, although on 
Linux practically everyone has LibPng, and we take care of distributing LibPng 
for other platforms too (like Windows, Android, iOs). But we still consider a 
"fallback on some other library to read PNG, like FpImage" useful, as A. we 
need such library anyway for other image formats (like JPG) and B. it will work 
in all possible cases (e.g. if someone packages CGE application in some weird 
way on Windows, and deletes "libpngXXX.dll").

In the upcoming CGE version, 7.0-alpha2, this fallback will likely change from 
FpImage to Vampyre Imaging Library, see our news last weekend: 
https://castle-engine.io/wp/2021/12/18/integration-with-vampyre-imaging-library-new-example-image_display-to-test-image-loading-speed-and-format-support/
 . From the point of view of Debian, it still means we just have a fallback 
from LibPng -> some other PNG reader, with implementation contained within 
Pascal units in CGE.


To test whether CGE actually uses LibPng, just

1. add to uses clause of TestCastleImages new unit: CastleInternalPng

2. add a method like this:

"""
procedure TTestImages.TestUsingLibPng;
begin
AssertTrue(CastlePngInitialized);
end;
"""

This will make sure that CGE is actually using LibPng, not any fallback. If 
this succeeds, and other TestCastleImages methods will also succeed -> you know 
that CGE is using LibPng and that it works :)

So Debian can carry the patch adding TestUsingLibPng (if you want to require 
that CGE in Debian always uses LibPng, which is fine by me, although I don't 
want to require it in upstream). And everything else will be tested using ready 
tests in CGE, which we maintain constantly :)

Regards,
Michalis

Bug#1001710: multipath-tools: booting with lvm over multipath it does not setup devices for lvm

[BARROS FERNANDEZ, Carlos]

Hi Ritessh.

On another server I have a stranger setup :) :
1 LVM over multipath
+
1 LVM over mdadm-device and the mdadm-device over multipaths

Did had problems because the mdadm-device did not setup the multipath, just the 
/dev/sdX devices
In this case, mdadm was called from udev as soon as a block device was setup, 
so it always started the software-raid on /dev/sdX
What I did was tell mdadm to not setup any block devices, only devices 
belonging to /dev/disk/by-id/dm-name-* because of the 'friendly-names' used un 
multipath.
I spent some time to figure it out.
The file /etc/mdadm/mdadm.conf should have a 'DEVICES' line that tells mdadm to 
only read those devices as follows:

DEVICE /dev/disk/by-id/dm-name-*



# definitions of existing MD arrays

ARRAY  /dev/md/0 metadata=1.2 UUID=d7285198:51ed20e4:7d1e82e6:b01569dd 
devices=/dev/disk/by-id/dm-name-* name=pandora:0


In this case, it is simpler, but it is very different from LVM as to where it 
must be set.(I find it clearer too)

Also, the filter in LVM only takes care of the /dev/sd[b-z) disks, but it is 
common to have several paths( and disks) like  /dev/sda[a-z] /dev/sdb[a-z] and 
so on.
That filter would not filter out /dev/sda[a-z]*, it will use them.
So I did change the rule in LVM to include those cases, one for /dev/sda[a-z] 
and one for /dev/sd[b-z] that covers the extra devices.

filter = [ "a|/dev/mapper/|", "r|/block/|", "r|/disk/|", "r|/sd[b-z].*|", 
"r|/sda[a-z].*|", "a|.*|" ]


Would you modify the info to reflect the 'modified' filter rule? Also a note on 
mdadm with that info would be nicer!


Regards.

INFORMACIÓN BÁSICA SOBRE PROTECCIÓN DE DATOS CONFORME EL NUEVO REGLAMENTO 
EUROPEO (RGPD)

RESPONSABLE: Grupo Econocom en España (Econocom SA, Econocom Servicios S.A., 
Econocom Products & Solutions S.A.U.) sitas en Cardenal Marcelo Spínola, 4, 
28016 Madrid
FINALIDAD PRINCIPAL: Mantener relaciones profesionales y/o comerciales con la 
empresa en la que usted trabaja o de la que es representante.
LEGITIMACIÓN: Consentimiento del interesado.
DESTINATARIOS: No se cederán datos a terceros, salvo autorización expresa u 
obligación legal.
DERECHOS: Acceder, rectificar y suprimir los datos, portabilidad de los datos, 
limitación u oposición a su tratamiento, transparencia y derecho a no ser 
objeto de decisiones automatizadas.
INFORMACIÓN ADICIONAL: Puede consultar la información adicional y detallada 
sobre nuestra política de 
privacidad
DELEGADO DE PROTECCIÓN DE DATOS (DPD): Miguel Angel Muñoz +34 93 470 30 00 
dpo_econocom...@econocom.com
CONFIDENCIALIDAD: Si Ud. no es el destinatario y recibe este mail por error, 
rogamos se ponga en contacto con nosotros y borre de inmediato el mail por 
error recibido con todos sus documentos adjuntos sin leerlos ni hacer ningún 
uso de los datos que en ellos figuren, ateniéndose a las consecuencias que de 
un uso indebido de dichos datos puedan derivarse.


BASIC INFORMATION ON DATA PROTECTION ACCORDING TO THE NEW EUROPEAN REGULATION 
(GDPR)

CONTROLLER: Grupo Econocom in Spain. (Econocom SA, Econocom Servicios S.A., 
Econocom Products & Solutions S.A.U.) registered at Cardenal Marcelo Spínola, 
4, 28016 Madrid
PURPOSE: Maintain professional and / or commercial relationship with the 
company which you represent or work for
LEGITIMATION: Data subject consent.
RECIPIENTS: data will not be transferred to third parties, unless explicit 
consent or legal obligation.
RIGHTS: Right to Access, right to rectification and erasure, data portability, 
right to restriction of processing, right to object and not been subject to a 
decision based solely on automated processing, and to be informed in a clearly 
and transparent way of how their personal data are processing.
ADDITIONAL INFORMATION: you can consult the additional and detailed information 
about our privacy 
policy
DATA PROTECTION OFFICER (DPO): Miguel Angel Muñoz +34 93 470 30 00 
dpo_econocom...@econocom.com
CONFIDENTIALITY: If you received this email in error, please immediately 
contact us and destroy the material in its entirety, whether in electronic or 
hard copy format. If you are not the intended recipient, you are hereby 
notified that any disclosure, copying, distribution, or use of the information 
contained herein (including any reliance thereon) is strictly prohibited, on 
his/her own responsibility.

Bug#1001807: Acknowledgement (sbuild-createchroot fails if DEBIAN-MIRROR-URI contains @)

[Johannes Schauer Marin Rodrigues]

Hi Tilman,

Quoting Tilman Keskinöz (2021-12-16 19:11:33)
>>Create a chroot from a debian-mirror that uses username password 
>>authentification.
>>
>>This works in stretch, but is broken in buster and bullseye.
>>
>>Reproducer:
>>
>>sbuild-createchroot --make-sbuild-tarball=foo.tar bullseye 
>>/tmp/bullseye-sbuild-chroot
>>http://f...@ftp.at.debian.org/debian
>>
>>Output fails:
>>I: Base system installed successfully.
>>E: failed running setup script: Global symbol "@ftp" requires explicit 
>>package name (did you forget to declare
>>"my @ftp"?) at (eval 22) line 58.
>>
> So here is my quick an dirty patch.

that patch is indeed just a workaround but doesn't solve the underlying
problem. Effectively, you could put any valid Perl code into the URL and use
that to execute arbitrary code. This should fix the problem:

https://salsa.debian.org/debian/sbuild/-/commit/43b256e52166cfb27f972af34695b3617dfdb6ac

Feel free to verify that this works for you.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#982407: mark libfabric1 Multi-Arch: same

[Afif Elghraoui]

On 12/14/21 7:48 AM, tony mancill wrote:
> On Tue, Feb 09, 2021 at 09:25:09PM +0100, Helmut Grohne wrote:
>> Package: libfabric1
>> Version: 1.11.0-2
>> Tags: patch
>> User: debian-cr...@lists.debian.org
>> Usertags: cross-satisfiability
>>
>> The affected packages cannot satisfy their cross Build-Depends, because
>> they request coinstalling libfabric1, but libfabric1 is not marked
>> Multi-Arch: same. It can be thus marked, because it does not have any
>> conflicting files. Please consider applying the attached patch.
> 
> Hi Debian HPC,
> 
> Any concerns with an NMU or team upload of this change?  I don't work in
> HPC and came across this bug via Debian Med (it affects the abyss
> package), so when I say "team" upload, I merely keeping the packaging
> repo updated.  I have requested team access via Salsa.  
> 

Hello,

I'm not involved with the package, but I've granted you access and any
help is welcome as far as I'm concerned.

thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name

Bug#970021: Provisional packaging for Aoache Arrow available

[Sascha Steinbiss]

Hi,

just for the record in this RFP and to move this a bit into the
spotlight: I have moved my packaging repository for Apache Arrow to the
Debian Science project in Salsa [1]. See the corresponding thread in the
Debian Med mailing list for more context [2].

TLDR: I have prepared a package to cover as much of Arrow as is possible
with what we have in Debian, dependency-wise. There is still a review of
d/copyright missing, and some bundled code might need some extra love or
removal.

If someone wants to work on this and wants to maintain it for longer,
feel free to let me know and I might help get it finished. :)
I just feel I won't be able to keep this updated in time on my own given
how busy upstream seems to be.

Cheers
Sascha

[1] https://salsa.debian.org/science-team/arrow
[2] https://lists.debian.org/debian-med/2021/08/msg00066.html

Bug#1002023: wine: Regression after upgrade to bullseye: crash with X_ConfigureWindow / BadWindow error

[CJP]

Package: wine
Version: 5.0.3-3
Severity: normal
X-Debbugs-Cc: cornware...@ultimatestunts.nl

Dear Maintainer,

On Debian Buster, Wine was able to run Microsoft Flight Simulator 2004.
After upgrading to Bullseye, it no longer does: when starting Flight Simulator,
the loading screen appears, and then sometimes the main window for a fraction
of a second, and then the application crashes. When doing this in a terminal
window ("wine fs9.exe" in its installation directory), the following error is
visible in the output:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  12 (X_ConfigureWindow)
  Resource id in failed request:  0x3800157
  Serial number of failed request:  992
  Current serial number in output stream:  1011

I am aware that Wine does not yet run all windows applications yet, but since
Flight Simulator worked nicely in Buster's wine version, I did not expect this
regression. Since a lot of things have probably been upgraded in the Buster ->
Bullseye upgrade, I am not sure which changes cause this: wine itself, the
window manager, graphics drivers, maybe even the kernel? Wine seems like the
first suspect though.

I tested some OpenGL games supplied with Debian, and they worked fine. I tested
Flight Simulator in another desktop environment (blackbox instead of MATE),
that still gives the same error. I used "winecfg" to try different graphics
settings (including dektop mode); that still gives the same error (note that
winecfg itself works fine, without crashing). I still need to test whether
other windows games work within wine.

I tried the following:

WINEDEBUG=+x11drv wine fs9.exe 2>&1 | tee ~/winetrace.txt

and the output (including the above error) is in the attachment. I also tried
this with "WINEDEBUG=+x11drv,+synchronous", but that seemed to trigger another
kind of crash, so the output didn't look so useful.

If I have time I'll keep on puzzling, doing more tests, reading the source,
learning the X11 protocol & so on. If you have any suggestions / fixes, please
let me know.


-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

-- System Information:
Debian Release: 11.2
  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-10-amd64 (SMP w/4 CPU threads)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 wine depends on:
ii  wine32  5.0.3-3
ii  wine64  5.0.3-3

wine recommends no packages.

Versions of packages wine suggests:
ii  dosbox0.74-3-3
pn  exe-thumbnailer | kio-extras  
pn  playonlinux   
pn  q4wine
pn  winbind   
pn  wine-binfmt   
ii  winetricks0.0+20210206-2

Versions of packages wine is related to:
pn  dxvk 
pn  dxvk-wine32-development  
pn  dxvk-wine64-development  
pn  fonts-wine   
ii  wine [wine]  5.0.3-3
ii  wine32   5.0.3-3
ii  wine64   5.0.3-3

-- no debconf information
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
0024:trace:x11drv:init_pixmap_formats depth 1, bpp 1, pad 32
0024:trace:x11drv:init_pixmap_formats depth 4, bpp 8, pad 32
0024:trace:x11drv:init_pixmap_formats depth 8, bpp 8, pad 32
0024:trace:x11drv:init_pixmap_formats depth 15, bpp 16, pad 32
0024:trace:x11drv:init_pixmap_formats depth 16, bpp 16, pad 32
0024:trace:x11drv:init_pixmap_formats depth 24, bpp 32, pad 32
0024:trace:x11drv:init_pixmap_formats depth 32, bpp 32, pad 32
0024:trace:x11drv:init_visuals default 

Bug#1001995: libcrypto++: ftbfs on armhf

[GCS]

Control: tags -1 +confirmed
Control: forwarded -1 https://github.com/weidai11/cryptopp/issues/1094

Hi Steve,

On Mon, Dec 20, 2021 at 1:03 AM Steve Langasek
 wrote:
> Libcrypto++ is failing to build on armhf because gcc there defaults to an
> implied -mfloat-abi=hard, which conflicts with -march=armv7-a because
> armv7-a does not guarantee floating-point support, and libcrypto++
> hard-codes -march=armv7-a in its makefile:
 Thanks, confirmed the problem and the fix as well on armhf in a Sid
chroot. Still need to check it on armel.

Cheers,
Laszlo/GCS

Bug#1002022: logrotate: enforce stricter parsing of config files

[Salvatore Bonaccorso]

Source: logrotate
Version: 3.18.1-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/logrotate/logrotate/pull/427
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.18.0-2
Control: found -1 3.14.0-4

Hi

Background for this hardening for logrotate is from
https://www.openwall.com/lists/oss-security/2021/10/20/2 .
See the upstream issue
https://github.com/logrotate/logrotate/pull/427, but I suggest to wait
until the changes are commited.

Later on after some expure, it might be worth making the fixes as well
available to stable and older via point releases.

Regards,
Salvatore

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

Kernel: Linux 5.16.0-rc3-amd64 (SMP w/8 CPU threads; PREEMPT)
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

Bug#1002021: apt-cache [--installed] lists package name for each available version

[наб]

Package: apt
Version: 2.2.4
Version: 2.3.13
Severity: normal

Dear Maintainer,

Please consider this output:
-- >8 --
$ apt-cache rdepends libtokyocabinet* --installed
libtokyocabinet9
Reverse Depends:
  neomutt
  libtokyocabinet-dev
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  libtokyocabinet9-dbgsym
  neomutt
libtokyocabinet-dev
Reverse Depends:
  neomutt-build-deps
libtokyocabinet-perl
Reverse Depends:
libtokyocabinet-perl-dbgsym
Reverse Depends:
libtokyocabinet9-dbgsym
Reverse Depends:
-- >8 --

It's relatively obvious that I don't have multiple neomutt versions
installed (indeed, just the one ‒ 20211029+dfsg.1-0.2~bpo11+2).

The manual notes --no-all-versions as a countermeasure;
no luck: it is not understood in combination with the other options.

If the output were locally sorted (#335925, #403808), this would be
solvable with a uniq(1) pipe. It isn't, so it's not.

The same happens without --installed:
-- >8 --
$ apt-cache rdepends libtokyocabinet9
libtokyocabinet9
Reverse Depends:
  bogofilter-tokyocabinet
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  neomutt
  tokyocabinet-bin
  ruby-tokyocabinet
  regina-normal
  neomutt
  mutt
  libtokyocabinet9-dbgsym
  libtokyocabinet-perl
  libtokyocabinet-dev
  libgrok1
  grok
  duc
  duc-nox
-- >8 --

Though in that case you can make the argument that all of these neomutts
can potentially depend on libtokyocabinet9 (but, well, there is no
additional information over just the one with no versions listed).

Best,
наб

For reference, here's the listing (amd64 only, repeats for i386 and x32):
-- >8 --
$ apt list neomutt
Listing... Done
neomutt/unstable 20211029+dfsg.1-0.2 amd64 [upgradable from: 
20211029+dfsg.1-0.2~bpo11+2]

$ apt list neomutt --all-versions
Listing... Done
neomutt/unstable 20211029+dfsg.1-0.2 amd64 [upgradable from: 
20211029+dfsg.1-0.2~bpo11+2]
neomutt/now 20211029+dfsg.1-0.2~bpo11+2 amd64 [installed,upgradable to: 
20211029+dfsg.1-0.2]
neomutt/unstable 20210205+dfsg.1-0.1 amd64
neomutt/stable 20201127+dfsg.1-1.2 amd64
neomutt/unstable 20201127+dfsg.1-0.1 amd64
neomutt/unstable 20201120+dfsg.1-0.1 amd64
neomutt/unstable 20200925+dfsg.1-0.2 amd64
neomutt/unstable 20200925+dfsg.1-0.1 amd64
neomutt/unstable 20200814+dfsg.1-0.1 amd64
neomutt/unstable 20200626+dfsg.1-0.1 amd64
neomutt/unstable 20200619+dfsg.1-0.1 amd64
neomutt/unstable 20200501+dfsg.1-0.4 amd64
neomutt/unstable 20200501+dfsg.1-0.3 amd64
neomutt/unstable 20200501+dfsg.1-0.2 amd64
neomutt/unstable 20200501+dfsg.1-0.1 amd64
neomutt/unstable 20200320+dfsg.1-0.2 amd64
neomutt/unstable 20200320+dfsg.1-0.1 amd64
neomutt/unstable 20200313+dfsg.1-0.2 amd64
neomutt/unstable 20200313+dfsg.1-0.1 amd64
-- >8 --

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::LastInstalledKernel "5.10.0-10-amd64";
APT::Get "";
APT::Get::AutomaticRemove "";
APT::Get::AutomaticRemove::Kernels "false";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: 

Bug#927899: ITP: cage -- A Wayland kiosk

[Birger Schacht]

Hi,

On 12/20/21 15:56, Johannes Schauer Marin Rodrigues wrote:

Quoting Birger Schacht (2021-12-17 12:14:25)

On 12/16/21 11:49, Johannes Schauer Marin Rodrigues wrote:

are you still interested in this package? Did you start with packaging it? I
saw the empty repo at https://salsa.debian.org/birger/cage and wanted to ask if
you already have an existing packaging somewhere and maybe just need somebody
to upload it to NEW?


Sorry for the delay, and thanks for nudging me, cage 0.1.4 is now in NEW ;)


Thank you! :)

Can you push your packaging repo to salsa as well?


Its part of the swaywm-team:
https://salsa.debian.org/swaywm-team/cage

cheers,
Birger




Thanks again!

cheers, josch


OpenPGP_0xCB06EA7B78DBE151.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002020: php-proxy-manager: Failing testsuite with PHP 8.1

[David Prévot]

Package: php-proxy-manager
Version: 2.11.1+1.0.3-1
Severity: important
Control: block 976811 by -1
Control: found -1 2.11.1+1.0.5-1

Hi,

The testsuite is currently failing with PHP 8:

(see
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/php-proxy-manager/17524886/log.gz
or more recent)

[…]
There were 9 failures:

1) 
/tmp/autopkgtest-lxc.bnfk1eqk/downtmp/build.0sn/src/tests/language-feature-scripts/access-interceptor-scope-localizer-serialized-class-private-property-isset.phpt
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'bool(false)'
+'Deprecated: Kitchen implements the Serializable interface, which is 
deprecated. Implement __serialize() and __unserialize() instead (or in 
addition, if support for old PHP versions is necessary) in Standard input code 
on line 5\n
+\n
+Deprecated: 
ProxyManagerGeneratedProxy\__PM__\Kitchen\Generated3e0dd340cc53a6b11dc36d7d0976dff6
 implements the Serializable interface, which is deprecated. Implement 
__serialize() and __unserialize() instead (or in addition, if support for old 
PHP versions is necessary) in 
/usr/share/php/ProxyManager/GeneratorStrategy/EvaluatingGeneratorStrategy.php(54)
 : eval()'d code on line 3\n
+bool(false)'

/tmp/autopkgtest-lxc.bnfk1eqk/downtmp/build.0sn/src/tests/language-feature-scripts/access-interceptor-scope-localizer-serialized-class-private-property-isset.phpt:30

2) 
/tmp/autopkgtest-lxc.bnfk1eqk/downtmp/build.0sn/src/tests/language-feature-scripts/access-interceptor-scope-localizer-serialized-class-private-property-read.phpt
Failed asserting that string matches format description.
--- Expected
+++ Actual
@@ @@
-%SFatal error:%sCannot access private property %s::$sweets in %a
+Deprecated: Kitchen implements the Serializable interface, which is 
deprecated. Implement __serialize() and __unserialize() instead (or in 
addition, if support for old PHP versions is necessary) in Standard input code 
on line 5
+
+Deprecated: 
ProxyManagerGeneratedProxy\__PM__\Kitchen\Generated3e0dd340cc53a6b11dc36d7d0976dff6
 implements the Serializable interface, which is deprecated. Implement 
__serialize() and __unserialize() instead (or in addition, if support for old 
PHP versions is necessary) in 
/usr/share/php/ProxyManager/GeneratorStrategy/EvaluatingGeneratorStrategy.php(54)
 : eval()'d code on line 3
+
+Fatal error: Uncaught Error: Cannot access private property Kitchen::$sweets 
in 
/usr/share/php/ProxyManager/GeneratorStrategy/EvaluatingGeneratorStrategy.php(54)
 : eval()'d code:155
+Stack trace:
+#0 
/usr/share/php/ProxyManager/GeneratorStrategy/EvaluatingGeneratorStrategy.php(54)
 : eval()'d code(160): 
ProxyManager\Stub\EmptyClassStub->ProxyManagerGeneratedProxy\__PM__\Kitchen\{closure}()
+#1 Standard input code(24): 
ProxyManagerGeneratedProxy\__PM__\Kitchen\Generated3e0dd340cc53a6b11dc36d7d0976dff6->__get()
+#2 {main}
+  thrown in 
/usr/share/php/ProxyManager/GeneratorStrategy/EvaluatingGeneratorStrategy.php(54)
 : eval()'d code on line 155

/tmp/autopkgtest-lxc.bnfk1eqk/downtmp/build.0sn/src/tests/language-feature-scripts/access-interceptor-scope-localizer-serialized-class-private-property-read.phpt:30
[…]


signature.asc
Description: PGP signature

Bug#927899: ITP: cage -- A Wayland kiosk

[Johannes Schauer Marin Rodrigues]

Quoting Birger Schacht (2021-12-17 12:14:25)
> On 12/16/21 11:49, Johannes Schauer Marin Rodrigues wrote:
> > are you still interested in this package? Did you start with packaging it? I
> > saw the empty repo at https://salsa.debian.org/birger/cage and wanted to 
> > ask if
> > you already have an existing packaging somewhere and maybe just need 
> > somebody
> > to upload it to NEW?
> 
> Sorry for the delay, and thanks for nudging me, cage 0.1.4 is now in NEW ;)

Thank you! :)

Can you push your packaging repo to salsa as well?

Thanks again!

cheers, josch

signature.asc
Description: signature

Bug#995846: FTBFS: Fatal TYPE-ERROR and tests incompatible with PG14

[Sébastien Villemot]

Le vendredi 10 décembre 2021 à 10:27 +0100, Sébastien Villemot a
écrit :
> 
> The problem seems again related to cl-esrap. I noticed that the Debian
> package tracks an old (dead) upstream, while there is a new alive fork.
> I’ll take over that package and hopefully fix the problem.

I’ve uploaded a new cl-esrap. It seems pgloader builds again.

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



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

Bug#995467: Salvaging status

[Matthew Fluet]

Great news!  I'm going to incorporate some of the bootstrap changes that we
identified on the GitHub issue into `master` in the next couple of weeks.
Hopefully, I'll also be able to cut a 202201?? release shortly after the
new year.
-Matthew

On Sun, Dec 19, 2021 at 10:33 PM Ryan Kavanagh  wrote:

> Another status update for those following at home:
>
> The mlton package (upstream release 20210117) now bootstraps and builds!
>
> For some reason I can't get the guide to compile (pdflatex spits out a
> bunch of errors and then dies, and the tool that calls pdflatex suggests
> the docbook input is invalid), so I might just temporarily disable
> building/installing it. I figure having an installable mlton package
> sans PDF guide is better than having no mlton package whatsoever in the
> meantime.
>
> I have considerably more time to work on this now that the semester is
> over, so I'm hoping to get it uploaded in the next week or so.
>
> Best,
> Ryan
>
> --
> |)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
> |\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A
>

Bug#557427: Buenos días,

[Martin Benard Marclord]

Buenos días,

Soy Martin Benard Marclord, te escribí hace dos días sin tu respuesta.
Espero que esta vez vea mi mensaje. Tengo una propuesta comercial para
usted por valor de 13,6 millones de dólares estadounidenses. Espero su
respuesta para más detalles.
sobre este tema

atentamente,
Martin Benard Marclord

Bug#727021: ufiformat: diff for NMU version 0.9.9-1.1

[Stephen Kitt]

Package: ufiformat
Version: 0.9.9-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for ufiformat (versioned as 0.9.9-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

Stephen
diff -u ufiformat-0.9.9/debian/changelog ufiformat-0.9.9/debian/changelog
--- ufiformat-0.9.9/debian/changelog
+++ ufiformat-0.9.9/debian/changelog
@@ -1,3 +1,14 @@
+ufiformat (0.9.9-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to debhelper compatibility level 13 and short dh rules.
+Closes: #965846, #727021.
+  * Switch to libext2fs-dev.
+  * Watch https://github.com/tedigh/ufiformat instead of the dead
+GeoCities page.
+
+ -- Stephen Kitt   Mon, 20 Dec 2021 15:23:36 +0100
+
 ufiformat (0.9.9-1) unstable; urgency=low
 
   * New upstream release
reverted:
--- ufiformat-0.9.9/debian/compat
+++ ufiformat-0.9.9.orig/debian/compat
@@ -1 +0,0 @@
-5
diff -u ufiformat-0.9.9/debian/control ufiformat-0.9.9/debian/control
--- ufiformat-0.9.9/debian/control
+++ ufiformat-0.9.9/debian/control
@@ -2,8 +2,8 @@
 Section: utils
 Priority: optional
 Maintainer: David Given 
-Build-Depends: debhelper (>= 5), autotools-dev, automake, e2fslibs-dev
-Homepage: http://www.geocities.jp/tedi_world/format_usbfdd_e.html
+Build-Depends: debhelper-compat (= 13), libext2fs-dev
+Homepage: https://github.com/tedigh/ufiformat
 Standards-Version: 3.9.4
 
 Package: ufiformat
reverted:
--- ufiformat-0.9.9/debian/dirs
+++ ufiformat-0.9.9.orig/debian/dirs
@@ -1 +0,0 @@
-usr/bin
diff -u ufiformat-0.9.9/debian/rules ufiformat-0.9.9/debian/rules
--- ufiformat-0.9.9/debian/rules
+++ ufiformat-0.9.9/debian/rules
@@ -1,79 +1,7 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
-# debian/rules file for ufiformat.
-# This file was originally written by Joey Hess and Craig Small.
-# As a special exception, when this file is copied by dh-make into a
-# dh-make output file, you may use that output file without restriction.
-# This special exception was added by Craig Small in version 0.37 of dh-make.
 
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-
-# These are used for cross-compiling and for saving the configure script
-# from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
-export CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
-export CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
-export CXXFLAGS = $(shell dpkg-buildflags --get CXXFLAGS)
-export LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
-
-configure:
-	dh_testdir
-	autoreconf -i
-	
-config.status: configure
-	dh_testdir
-	./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
-
-
-build: build-arch build-indep
-build-arch: build-stamp
-build-indep: build-stamp
-
-build-stamp:  config.status
-	dh_testdir
-	$(MAKE)
-	touch $@
-
-clean:
-	dh_testdir
-	dh_testroot
-	
-	rm -f build-stamp
-	[ ! -f Makefile ] || $(MAKE) distclean
-	rm -f aclocal.m4 Makefile.in
-	rm -f config.sub config.guess config.status config.status.lineno
-	rm -f config.log configure config.h.in
-
-	dh_clean 
-
-install: build
-	dh_testdir
-	dh_testroot
-	dh_clean -k 
-	dh_installdirs
-	$(MAKE) DESTDIR=$(CURDIR)/debian/ufiformat install
-
-binary-indep: build install
-	# none
-
-binary-arch: build install
-	dh_testdir
-	dh_testroot
-	dh_installchangelogs ChangeLog
-	dh_installdocs
-	dh_installman ufiformat.man
-	dh_strip
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_shlibdeps
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
-
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install 
+%:
+	dh $@
diff -u ufiformat-0.9.9/debian/watch ufiformat-0.9.9/debian/watch
--- ufiformat-0.9.9/debian/watch
+++ ufiformat-0.9.9/debian/watch
@@ -1,6 +1,4 @@
-# Check upstream for a new version
-
-# Compulsory line, this is a version 3 file
-version=3
-
-http://www.geocities.jp/tedi_world/format_usbfdd_e.html  ufiformat-(.*)\.tar\.gz
+version=4
+opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%" \
+https://github.com/tedigh/ufiformat/releases \
+(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate


signature.asc
Description: PGP signature

Bug#1001081: sbcl: `sbcl --load quicklisp.lisp` fails with `internal error 222` since 2.1.11-1

[Sébastien Villemot]

Control: tags -1 + moreinfo

Dear David,

Le vendredi 03 décembre 2021 à 14:27 -0600, David Loyall a écrit :
Package: sbcl
Version: 2:2.1.11-1
Severity: important

Dear Sébastien Villemot,

Here is some output from a terminal:

sebboh@debian:~/prj$ sbcl --load quicklisp.lisp
This is SBCL 2.1.11.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
While evaluating the form starting at line 1154, column 0
  of #P"/home/sebboh/prj/quicklisp.lisp":

debugger invoked on a SIMPLE-ERROR @52CF6451 in thread
#:
  internal error 222: NIL; args=NIL

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY   ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file
"/home/sebboh/prj/quicklisp.lisp".
  2: [ABORT   ] Abort loading file "/home/sebboh/prj/quicklisp.lisp".
  3:Ignore runtime option --load "quicklisp.lisp".
  4:Skip rest of --eval and --load options.
  5:Skip to toplevel READ/EVAL/PRINT loop.
  6: [EXIT] Exit SBCL (calling #'EXIT, killing the process).

(SB-C:MAKE-TN-REF # NIL)
0] 6
;
; compilation unit aborted
;   caught 1 fatal ERROR condition

debugger invoked on a SIMPLE-ERROR @52A4A930 in thread
#:
  internal error 222: NIL; args=NIL

The current thread is not at the foreground,
SB-THREAD:RELEASE-FOREGROUND has to be called in
#
for this thread to enter the debugger.
Killed

I can’t replicate your problem. Loading quicklisp.lisp with sbcl 2.1.11-1 works 
fine for me.

In order to rule out problems caused by your initialization scripts, can you 
try the following:

 sbcl --no-sysinit --no-userinit --load 
/usr/share/common-lisp/source/quicklisp/quicklisp.lisp

Best,

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



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

Bug#999620: pktanon: autopkgtest regression on armhf

[Sascha Steinbiss]

Hi Paul,

sorry for the delay in replying, I was quite busy and now I have some
free time over the holidays to follow up.

>> I am puzzled. The recent upload only changed the watchfile and updated
>> Standards-Version, compat level etc -- packaging things. Nothing touched
>> the code or build rules.
> 
> Well, but maybe your build dependencies have. Also, compat level isn't
> totally safe either in general (although the issue here doesn't
> obviously look like it).

Yes, I agree it's likely not that.

[...]>> I must admit that being unfamiliar with these architectures and not
>> really having an idea of where to start, I am tempted to just remove
>> armhf from the list of supported architectures and have the version with
>> the broken autopkgtest removed from unstable. Do you probably know
>> someone who might be more knowledgeable with such architecture-specific
>> issues?
> 
> We have porters for architecture specific support. However, I'm not
> totally convinced yet it's architecture specific.

Maybe. You noted that it seems to work fine on a machine with the same
architecture but different specs.

> Is there anything I can try out for you on our armhf host to help debug
> the issue? Run the command with more debug options? Grab an output file
> from somewhere? 
Hmmm. Since I am pretty unfamiliar with the source and/or any
assumptions that are being made in the code, a good start would be to
get an idea of where in the code the bus error is triggered. You could
try the -v option but I am not sure it would help much.
I think a real stack trace would help, by running the tests with
valgrind or via gdb. Nothing one would do in a generic test suite :/
How much customization would be possible in the test run?

> I could try to run the test in testing with a rebuild of
> the package in testing, would that help?

Maybe, if that does not cost much then please try.

Cheers
Sascha

Bug#1002016: libvirt-clients: virsh hangs without controlling TTY

[Detlef Vollmann]

Package: libvirt-clients
Version: 7.10.0-1
Severity: important
X-Debbugs-Cc: d...@vollmann.ch

Dear Maintainer,

   * What led up to the situation?
Using virsh to start a VM from fvwm.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I start a VM from fvwm normally with such an entry:
Exec virsh start vm && virt-viewer vm

This stopped working after the last libvirt upgrade.
Using a script and strace I found that it opens /dev/tty shortly before
the end of the output, so I assume there's a problem here.
Running the command from the command line in an xterm works fine.

   * What was the outcome of this action?
The virsh process still shows up in 'ps', but doesn't show
any activity, doesn't end and doesn't start the VM.

   * What outcome did you expect instead?
That the program returns and starts the VM.



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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
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 libvirt-clients depends on:
ii  libc6   2.33-1
ii  libgcc-s1   11.2.0-13
ii  libglib2.0-02.70.2-1
ii  libgnutls30 3.7.2-4
ii  libreadline88.1-2
ii  libvirt07.10.0-1
ii  libxml2 2.9.12+dfsg-5+b1
ii  sensible-utils  0.0.17

libvirt-clients recommends no packages.

Versions of packages libvirt-clients suggests:
ii  libvirt-daemon   7.10.0-1
pn  libvirt-login-shell  

-- no debconf information

Bug#1002015: dependency on trivial-with-current-source-form should be reinstated

[Sébastien Villemot]

Package: cl-esrap
Version: 20211008.gitc99c33a-1
Severity: normal

The patch drop-with-current-source-form.patch removes the dependency on the
Common Lisp package trivial-with-current-source-form.

The latter should be packaged in Debian and this patch removed.

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

Bug#1002017: the testsuite fails on ecl, clisp and abcl

[Sébastien Villemot]

Package: cl-esrap
Version: 20211008.gitc99c33a-1
Severity: normal

The subject says it all.

Once those failures are fixed, the corresponding implementation stanzas should
be reinstated for the autopkgtests (in debian/tests/control).

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

Bug#448063: reopen reason

[肖盛文]

please see: https://lists.debian.org/debian-chinese-gb/2021/12/msg3.html



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#548845:

[Steve Dodd]

There seems to be a patch available here:
https://github.com/brauner/screen/commit/2111bd2fa42d0dd20ef7ac09a599c892b7910c3c
- I can't work out if it has been upsteamed, as Savannah seems to be
down ..

Steve

Bug#1001320: needrestart misdetects socket activated ssh and restarts service instead of socket

[Timo Weingärtner]

Hallo Marc Haber,

19.12.21 16:15 Marc Haber:
> On Wed, Dec 08, 2021 at 04:01:30PM +0100, Timo Weingärtner wrote:
> > 08.12.21 13:31 Marc Haber:
> > > I am running a number of test systems with ssh as socket activated
> > > service. Sometimes, after an update, I find myself without ssh access to
> > > those systems (connection refused). After a console login and systemctl
> > > restart ssh.socket, things are fine again.
> > > 
> > > I THINK this might be connected to needrestart. Today, a libc6 update
> > > marked the running ssh daemon (that I was using for the update) as using
> > 
> > > obsolete libraries, which resulted in the following console output:
> > To me it looks like a problem in needrestart. The (forked off) sshd
> > process
> > handling your client connection belongs to cgroup session-NN.scope, no
> > matter if it was started by systemd socket activation or regular sshd.
> 
> I concur with your analysis. So we need a bug report against needrestart
> with the title "misdetects ssh as started from ssh.service if it's
> actually ssh.socket or ssh@.service"?

ssh.socket doesn't contain processes.
ssh@.service would AFAIR be detected if libpam-systemd is 
not installed or if the connection is not yet complete. At least I remember 
(some years back) needrestart showing me ssh@.service ticked 
by default sawing off the branch I was sitting on when blindly nodded through.

We should be more specific here: it's about the per-client process which 
should not get restarted by default.
Even when ssh.service is running it misdetects per-client processes, but in 
that case it is usually quite harmless.

> > A workaround might be masking ssh.service.
> 
> That seems to do it for me, this hasn't happeneed on my test systems
> since I masked ssh.service. I do consider this a valid workaround (but
> not a soution) for the time being.
> 
> ssh maintainer, I think this warrants at least some documentation, for
> example in /usr/share/doc/openssh-server/README.Debian.gz, as the way
> documented there just suggests disabling ssh.service and not masking it.

Masking ssh.service also helps with people (possibly even including yourself) 
doing "systemctl restart ssh" after editing sshd_config.


Grüße
Timo

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

Bug#998842: octave: inv() causes segfault if io package pre-loaded

[Sébastien Villemot]

Control: tags -1 + moreinfo

Dear Leonardo,

Le lundi 08 novembre 2021 à 13:18 +, Leonardo Vainsencher a écrit :
The following code causes 'Segmentation fault' when inv() is
executed:
%%% begin octave code %%%
 pkg load io 
 w = exp(-1i*pi/3); 
 P_6x6 = [ 1, -1,    1,    1,    1,    -1; ...
   1, -w,    w^2,  w^3,  w^4,  -w^5; ...
   1, -w^2,  w^4,  w^6,  w^8,  -w^10; ...
   1, -w^3,  w^6,  w^9,  w^12, -w^15; ...
   1, -w^4,  w^8,  w^12, w^16, -w^20; ...
   1, -w^5,  w^10, w^15, w^20, -w^25];
 Pi_6x6 = inv(P_6x6); % causes segfault
 D_6x6  = det(P_6x6); % causes segfault
%%% end octave code %%%

Octave run command (bash):
 octave-cli --no-init-file

If `pkg load io` is omitted, no segfault occurs (io package is a
dependency
of communications). If pinv() is used instead of inv(), segfault does
not
occur either.

Thanks for your bug report.

I am unable to replicate your problem. This code works fine for me
(tested on both Debian stable and unstable).

Can you provide a full backtrace of the segfault? For instructions,
see:
https://wiki.debian.org/HowToGetABacktrace

Can you also report the output of the following command:
 octave --eval "version -blas"

Best,

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



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

Bug#652747: patch

[Soeren Ziehe]

Hello.

On Sat, 14 Sep 2013 13:21:37 +0200 Frederic Peters  wrote:

Hi,

I discovered that bug today and wrote a patch, I tested it against
mailman 2.1.13 (as found in Squeeze); I tracked the change in Mailman
and found it to be revision 972:

  CGI/admin.py
   The email address which forms a part of the various CGI data keys
   in the admin membership list is now urllib.quote()ed. This allows
   changing options for and unsubbing an address which contains a
   double-quote character.

  -- http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/972


Fred

--- listadmin.pl.orig   2013-09-14 13:10:33.760699371 +0200
+++ listadmin.pl2013-09-14 13:11:54.785101152 +0200
@@ -588,7 +588,7 @@
 
 sub url_quote_parameter {

 my $param = shift;
-$param =~ s/(\W)/sprintf ("%%%02x", ord ($1))/ge;
+$param =~ s/(\W)/sprintf ("%%%02X", ord ($1))/ge;
 $param;
 }
 
@@ -1763,6 +1763,7 @@

  user => \@addresses);
 for my $a (@addresses) {
$params{$a . "_unsub"} = "on";  # Mailman 2.x
+   $params{url_quote_parameter($a) . "_unsub"} = "off" # Mailman >=2.1.12
 }
 my $resp = $ua->post($url, \%params);
 return $resp->status_line unless $resp->is_success;



This seems to encode "too much" AND the parameter has to be "on".

Against mailman 2.1.15 is apparently "enough" to just encode the "@" sign.

I propose this patch:


*** ./listadmin.orig2018-09-20 19:26:39.0 +0200
--- ./listadmin 2021-12-20 13:39:33.153488479 +0100
*** sub remove_subscribers {
*** 1836,1841 
--- 1836,1845 
  user => \@addresses);
  for my $a (@addresses) {
$params{$a . "_unsub"} = "on";  # Mailman 2.x
+   # mailman > 2.1.11 encodes the "@" sign
+   my $b = $a;
+   $b =~ s/@/%40/;
+   $params{$b . "_unsub"} = "on";  # Mailman > 2.1.11
  }
  my $resp = $ua->post($url, \%params);
  return $resp->status_line unless $resp->is_success;

Regards,
S. Ziehe



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#152195: Question on the use of "/nonexistent"

[Marc Haber]

On Sun, Dec 19, 2021 at 12:08:54PM +0100, Marc Haber wrote:
> I don't have anything to add but my support for the way that has been
> unanimously lined out in this discussion. Jason, you have my "go" to do
> those changes, and if it would be my choice it'd be --homeless ;-)

--homeless should also turn off the
Warning: The home dir /nonexistent you specified can't be accessed: No
such file or directory
that adduser emits.

Greetings
Marc

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

Bug#1001527: FTBFS with fmtlib 8

[Sascha Steinbiss]

Hi,

> I have uploaded fmtlib/8 to experimental, and plan to start this transition.
> 
> You package FTBFS with fmtlib/8, it has been fixed in version 2021.08.26.
> Please package the new version or backport the relevant commits.

Unfortunately never versions than the one currently in testing
(2021.05.27) can not be easily packaged, since new versions require
Apache Arrow which is not (yet) available in Debian [0]. A package for
Arrow has been prepared [1] but I am not willing to maintain this large
software dependency -- which is very actively developed with potentially
breaking API/ABI changes -- on my own so I am currently refraining from
uploading it. I have handed my preliminary work over to the Debian
Science Team.

The backport of the libfmt support update is too much of a hassle to
port to an old version that is unlikely to be used by anyone as VAST
development also moves too fast to be OK with Debian's update routine.

I suggest to let VAST drop out of testing until Apache Arrow is
available, so it does not block your transition.

Cheers
Sascha

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021
[1] https://salsa.debian.org/science-team/arrow

Bug#989030: memtest86+: New upstream version available v5.31b

[Christoph Anton Mitterer]

Hey.

Just for the records:

Last September I had a short email conversation with memtest86+'
upstream, and it seemed to me that he considered 5.31b rather as a
"stabli-ish" version than b(eta):


On Thu, 2021-09-09 at 18:46 +0200, Samuel D.  wrote:
> Hi Christoph,
> 
> Right now, many issues have been solved in 5.31. This version works
> usually fine on modern system but without the experimental SMP mode.
> 
> SMP mode has been added a decade ago and is deprecated now. All
> modern multi-core CPU now have the power to achieve full computing
> power and saturate the whole IMC bandwidth while using a single core.
> 
[... plus some more about the lack of UEFI support ...]


So I guess one should perhaps consider 5.31b fit for being used, rather
than the current version which is at least for me broken on nearly any
modern CPU.


Cheers,
Chris.

Bug#1001894: ITP: spacecadetpinball -- Decompilation and port of "3D Pinball for Windows - Space Cadet"

[lucylikesyourface]

On 19/12/2021 16:24, "Andrej Shadura"  wrote:

Im afraid the fact this source has been obtained as the result of a 
decompilation of the original proprietary binary means this project cannot be 
legally under the MIT license. If this is true, it cannot be included in Debian 
main or contrib, and possibly not even in non-free.


Thank you for pointing that out, I had not considered that the source itself 
might not be distributable. I shall look into this.

Bug#1002013: Regression: IPMIEVD_OPTIONS was removed, served a purpose

[Sergio Gelato]

Package: ipmitool
Version: 1.8.18-10.1
Severity: important

The changelog for 1.8.18-7 mentions
  * Remove not longer needed debian/ipmitool.ipmievd.default (Closes: #907832).
- New debian/ipmitool.maintscript to remove /etc/default/ipmitool.
- Add IPMIEVD_OPTIONS from /etc/default/ipmitool into
  debian/ipmitool.ipmievd.service.

Unfortunately, that last change was done by hard-coding the default value
"open daemon" into the ExecStart line of the systemd service unit, with no
convenient way to customise it. Some hardware requires "sel daemon" instead;
on such systems ipmievd breaks on upgrade from buster to bullseye.

Bug#1000645: bullseye-pu: package symfony/4.4.19+dfsg-2+deb11u1

[David Prévot]

Le Sat, Dec 04, 2021 at 04:12:01PM -0400, David Prévot a écrit :
[…]
> Thanks, uploaded (with changelog updated).

Really uploaded now, seems like i failed to actually upload two weeks
ago, sorry about that.

Regards

David


signature.asc
Description: PGP signature