Bug#1063723: pypdf2 1.26.0-4+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1063723 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: pypdf2
Version: 1.26.0-4+deb11u1

Explanation: 

Bug#1055115: bookworm-pu: package prometheus-node-exporter-collectors/0.0~git20230203.6f710f8-1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Tue, Oct 31, 2023 at 02:22:27PM -0400, Antoine Beaupre wrote:
> [ Reason ]
> Since the bookworm upgrade, all hosts with the
> prometheus-node-exporter-collectors package install repeatedly hit the
> mirrors with spurious apt-update runs. The Debian package
> systemd.timer(1) schedule is once on boot and then every 15 minutes
> after, which imposes a tremendous load on the mirror system.

Please go ahead.

Thanks,

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

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

Bug#1055214: bookworm-pu: package fpga-icestorm/0~20220915gita545498-3

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Nov 02, 2023 at 11:36:23AM +0100, Daniel Gröber wrote:
> [ Reason ]
> Andras Pal reported fpga-icestorm's "icebram" utility being broken in
> stable (#1055171) due to incompatible changes to yosys's output.

Please go ahead.

Thanks,

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

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

Bug#1057267: bookworm-pu: package phpldapadmin/1.2.6.3-0.3+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Dec 02, 2023 at 11:56:14AM +0100, William Desportes wrote:
> Some users have older PHP versions than the one from bookworm, phpldapadmin 
> is compatible with most of the recent ones.
> But the patch that was distributed at the time of packaging was limited to 
> PHP 8.1+ and got outdated by a newer one that is compatible with more PHP 
> versions.

Please go ahead.

Thanks,

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

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

Bug#1064276: bookworm-pu: package python-channels-redis/4.0.0-1+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Mon, Feb 19, 2024 at 01:26:17PM +, Colin Watson wrote:
> [ Reason ]
> The version of python-channels-redis in bookworm suffers from
> https://bugs.debian.org/1027387 /
> https://github.com/django/channels_redis/issues/332, which was
> introduced in 4.0.0 and is a regression from bullseye.  I ran into this
> while working on debusine.

Please go ahead.

Thanks,

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

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

Bug#1060290: django-mailman3 1.3.5-2+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1060290 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: django-mailman3
Version: 1.3.5-2+deb11u1

Explanation: scrub messages before archiving

Bug#1057084: nvidia-graphics-drivers-tesla-450 450.248.02-4~deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1057084 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-tesla-450
Version: 450.248.02-4~deb11u1

Explanation: convert to transitional packages

Bug#1064029: bookworm-pu: package mailman3/3.3.8-2~deb12u2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Fri, Feb 16, 2024 at 12:21:32AM +0100, Pierre-Elliott Bécue wrote:
> [ Reason ]
> Bug #1040708 is about a change in the way sqlalchemy reads postgresql
> URIs. Historically the prefix in this URI was postgres. Now it's
> postgresql. Therefore the default config for mailman3 is broken under
> bookworm.
> Bug #1038953 is about tracking cron-daemon instead of cron to allow more
> flexibility should one wish to use something else than cron. It was
> supposed to be done for some time.

Please go ahead.

Thanks,

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

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

Bug#1049792: upstream fix

[Konstantinos Poulios]

Should apparently apply this upstream fix:

https://git.savannah.nongnu.org/cgit/getfem.git/commit/?id=cb207a37436e8bb561c14364e6041bc849798592

Bug#1063823: bullseye-pu: package nvidia-graphics-drivers/470.223.02-2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Tue, Feb 13, 2024 at 03:50:23AM +0100, Andreas Beckmann wrote:
> [ Reason ]
> While preparing the update series for bookworm I realized that I had
> missed in the last OPU some changes in
> src:nvidia-graphics-drivers/bullseye that were added in
> src:nvidia-graphics-drivers-tesa-470/bullseye.
> To avoid confusion, these packages should stay in sync.
> The relevant bug here is libnvidia-fbc1 not being built on arm64, even
> though the library is available in the blob nowadays.

Please go ahead.

Thanks,

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

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

Bug#1041982: Speeding up Symfony 6 transition? [Was: Upcoming transitions (Symfony, PHPUnit, etc.)]

[David Prévot]

Hi,

Le Wed, Jan 03, 2024 at 07:04:12PM +0100, David Prévot a écrit :
[…]
> I’m in favour of raising the severity of bugs blocking this transition
> to RC level ASAP: Symfony 6 has been in experimental for a while now

I intend to do so early next week: symfony 6 was introduced in
experimental during the latest Debian Reunion Hamburg, and I wish to
proceed with the transition during the next MiniDebCampHamburg happening
early March (in less than two weeks).

https://wiki.debian.org/DebianEvents/de/2024/MiniDebCampHamburg

This transition should not interfere with any other one, and should not
even need any help from the Release Team (no binNMU since they’re all
arch:all packages), yet they were helpful last time to speed it up by
removing blocking packages from testing because we didn’t raise the
blocking bug severity early enough.

Regards,

taffit


signature.asc
Description: PGP signature

Bug#1064383: geeqie could depend-on/recommend webp-pixbuf-loader for animated webp support

[Bence Romsics]

Package: geeqie
Version: 1:2.2-1
Severity: normal
X-Debbugs-Cc: bence.roms...@gmail.com

Dear Maintainer,

On my Debian SID system geeqie can display animated webp files if
webp-pixbuf-loader is also installed. However the geeqie package
metadata does not seem to refer to this in any way. And without
webp-pixbuf-loader geeqie shows only a broken file icon for an
animated webp file.

Maybe the geeqie package could recommend or depend on
webp-pixbuf-loader.

Version of webp-pixbuf-loader:
ii  webp-pixbuf-loader:amd64  0.2.4-2+b1

The upstream bug that made me realize geeqie can display animated webp:
https://github.com/BestImageViewer/geeqie/issues/1086

An animated webp file I used to test:
https://mathiasbynens.be/demo/animated-webp-supported.webp

Thanks in advance,
Bence Romsics

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

Kernel: Linux 6.6.13-amd64 (SMP w/4 CPU threads; PREEMPT)
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 geeqie depends on:
ii  geeqie-common1:2.2-1
ii  libarchive13 3.7.2-1
ii  libc62.37-15
ii  libcairo21.18.0-1+b1
ii  libdjvulibre21   3.5.28-2+b1
ii  libexiv2-27  0.27.6-1+b1
ii  libffmpegthumbnailer4v5  2.2.2+git20220218+dfsg-2+b1
ii  libgcc-s114-20240201-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.3-2
ii  libgspell-1-21.12.2-1
ii  libgtk-3-0   3.24.41-1
ii  libheif1 1.17.6-1
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libjxl0.70.7.0-10.2+b1
ii  liblcms2-2   2.14-2
ii  liblua5.3-0  5.3.6-2
ii  libopenjp2-7 2.5.0-2+b2
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpangocairo-1.0-0  1.51.0+ds-4
ii  libpoppler-glib8 22.12.0-2+b1
ii  libraw23 0.21.2-2
ii  libstdc++6   14-20240201-1
ii  libtiff6 4.5.1+git230720-4
ii  libwebp7 1.3.2-0.4
ii  sensible-utils   0.0.20

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.4.7-1+b1
ii  exiftran 2.10-5
ii  exiv20.27.6-1+b1
ii  imagemagick  8:6.9.12.98+dfsg1-5+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.12.98+dfsg1-5+b1
ii  librsvg2-common  2.54.7+dfsg-2
ii  zenity   4.0.1-1

Versions of packages geeqie suggests:
ii  gimp 2.10.36-2
ii  libjpeg-turbo-progs [libjpeg-progs]  1:2.1.5-2+b2
pn  xpaint   

-- no debconf information

Bug#1033352: sbuild: autokpgtest-virt-server needs host $HOME

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Christian Kastner (2023-03-23 09:53:05)
> Attempting to build a package with the autopkgtest-virt-podman backend fails
> because of what I suspect is an issue with $HOME directory handling. podman
> needs $HOME on the host to find containers, but it defaults to
> /sbuild-nonexistent, which I guess is meant for the target enviromnent.

is this a duplicate of #1061388?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1062995: tslib: NMU diff for 64-bit time_t transition

[Martin Kepplinger]

Am Sonntag, dem 04.02.2024 um 10:51 + schrieb Steve Langasek:
> Source: tslib
> Version: 1.22-1
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
> 
> NOTICE: these changes must not be uploaded to unstable yet!
> 
> Dear maintainer,
> 
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> tslib as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
> 
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
> 
> Since turning on 64-bit time_t is being handled centrally through a
> change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it
> is
> important that libraries affected by this ABI change all be uploaded
> close
> together in time.  Therefore I have prepared a 0-day NMU for tslib
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
> 
> Please find the patch for this NMU attached.
> 
> If you have any concerns about this patch, please reach out ASAP. 
> Although
> this package will be uploaded to experimental immediately, there will
> be a
> period of several days before we begin uploads to unstable; so if
> information
> becomes available that your package should not be included in the
> transition,
> there is time for us to amend the planned uploads.
> 
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> 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)

hi Steve,

in general, tslib only ever uses time_t differences, so apart from one
glitch when wrapping around, the library will continue to work after
2038 as-is.

I'll look at what `__TIMESIZE` currently is on 32bit archs. But given
the low-impact this has for tslib functionality-wise, I'd rather find
the correct change (any help appreciated), and increment LT_CURRENT.

So: where do I start in order to comply with your scripts? do I simply
add `D__USE_TIME_BITS64` to CPPFLAGS?

thanks,

   martin

Bug#1064343: tput sgr0 adds uncalled-for codes

[Adam Borowski]

On Tue, Feb 20, 2024 at 07:41:42PM +0100, Sven Joachim wrote:
> > On Tue, Feb 20, 2024 at 04:15:30PM +0800, Paul Wise wrote:
> >>$ tput sgr0 | hd
> >>  1b 28 42 1b 5b 6d |.(B.[m|
> >
> > Here's the culprit.  The code you asked for is "\e[0m" -- shortenable to
> > non-canonical but valid "\e[m", which is the second half of tput's output.
> >
> > What you did not ask for, is "\e(B", which is not allowed in UTF-8 mode,
> > and in non-Unicode world would switch to an ancient "US" charset.
> 
> Maybe that is true for the Linux console, but we are talking about xterm
> here.

It's not a property of the terminal, but of ECMA-35.

And what "xterm" are you talking about?  tput has no way to know the
terminal on the other side, as the string TERM=xterm (and
TERM=xterm-256color) applies to over a hundred different terminals using
tens of different code bases.  And you can't even blame their authors, as:
 * most Unices stopped maintaining their terminfo databases (eg. Solaris
   still hasn't learned about TERM=linux.  Solaris is no longer relevant now
   but was relevant for most of that time frame.)
 * even if the databases were maintained, a new terminal would become useful
   only several years after it gets released (as the terminfo entry would
   need to be deployed on every box you might possibly ssh into, with
   failure mode being complete breakage of any terminfo-using program)
Thus, putting aside historic terminals, there are only three TERM values:
 * linux
 * rxvt (used by its derivatives like aterm)
 * xterm (everything else)
(Skipping decorations like -256color which most programs hard-code anyway. 
I thus had to implement 256 color fallbacks in the kernel in 2016; it seems
that eg. 24-bit color is moving the same way.)

> > Putting aside arguments if this code is allowed or not (eg. the author of
> > Putty has strong feelings on the matter), it's very clearly not what you
> > asked for, thus the real bug is on tput's side.

> > Thus:
> > "tput sgr0" should produce sgr0, not setusg0 sgr0.
> 
> It does of course produce sgr0, i.e. it emits whatever escape sequence
> $TERM's terminfo entry declares as sgr0.  In the case of xterm-256color,
> sgr0=\E(B\E[m.

And it's that entry what's wrong.  sgr0 means "\e[0m" (or "\e[m"); see
eg. docs for real xterm: https://www.xfree86.org/current/ctlseqs.html

> The reason for including \E(B here is that sgr0 should cancel the
> effects of a previous smacs (start alternate character set) sequence and
> thus includes the rmacs (end alternate character set) escape sequence.

Then it combines two completely different concepts in one label.  SGR is
for character attributes, G0/G1 are for encoding.

> People are relying on this behavior, see #595484 for instance.

Seems like an XKCD 1172 case.

> Closing the bug, because everything works as intended.

...

Well, I'm not going to fight a BTS war, but I don't agree with your
decision.

I'll work around this misbehaviour (as it's no extra work for me: I need
to handle legitimately occuring G0/G1 changes anyway).  Still, it is a bug
even if its severity is negligible: thanks to PuTTY's author's stubborness
no maintained software uses G0/G1 anymore.

Thus, the only real fallout is bloating terminal output.  It's still too
slow on serial links or inferior terminals (I felt bad about Scaleway's
web console just hours ago); saving three bytes per sgr0 is not much but
it is a very frequently used sequence.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄

Bug#1043240: transition: pandas 1.5 -> 2.1

[Andreas Tille]

Hi Rebecca,

Am Tue, Feb 20, 2024 at 10:10:46PM + schrieb Rebecca N. Palmer:
> Remaining blockers for testing migration:
> - python-ulmo #1044057: has a patch, please upload

I've uploaded this yesterday.

> - pydevd #1063274: unclear whether my patch breaks something else, please
> leave alone for now

I've read the discussion in this bug report and leave the decision to
Julian who is obviously way deeper involved into this.

 
> Status unclear:
> - python-xarray: autopkgtest has failed 3 times, but all 3 are (different)
> failures that have occurred without pandas 2, apparently at random

I admit I see no flaws here.  Tracker page looks fine and debci[1] has
only issues for ppc64el and riscv64 - if it would be Pandas it would
probably fail on all architectures, thought.

> - q2-*: autopkgtest fails in "fixed" versions, but possibly because they're
> not all being tested together

I uploaded the latest versions of q2* packages by enabling tests of
all supported Python3 versions.  The tests for Python3.12 are failing
in most of the q2-* packages due to some code in qiime which is not
related to Pandas (IMHO).  I've reported this upstream[2] and hope
for a quick solution.

Thanks a lot for all your work and support
Andreas.

[1] https://ci.debian.net/packages/p/python-xarray/
[2] https://github.com/qiime2/qiime2/issues/751

-- 
http://fam-tille.de

Bug#1059236: closed by Gianfranco Costamagna (Re: Bug#1057954: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities)

[Phil Wyett]

Control: reopen -1

On Tue, 2024-02-20 at 08:12 +, Gianfranco Costamagna wrote:
> Hello,
> 
> > I think I need advice here. I am tempted to breaks replace and upgrade all 
> > to
> > libnanomsg6
> > and then work with upstream on SONAMES etc. How would you and Tobias 
> > proceed?
> 
> yes, this is correct. Change soname and go for experimental, and ask upstream 
> to change
> soname only
> if symbols are changed.
> 
> G.

Hi Gianfranco,

This is now done and ready for review.

Regards copyrights that pop-up i.e.:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059236#16

This is the original author, now working under their company name.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12

[Matt Marjanovic]

Package: grub-efi-amd64
Version: 2.12-1
Followup-For: Bug #1056764
X-Debbugs-Cc: mad...@mir.com

Dear Maintainer,

FYI, I experienced a pretty similar problem today:  failure to boot after
upgrading to 2.12-1.

Machine:  Lenovo Thinkpad T460p
   BIOS:  2.36 (initially)
  UEFI boot (without SecureBoot enabled)

Upon reboot, after showing the Lenovo splash screen, the system would just
drop into the BIOS setup screen.  My eventual workaround was to boot into
rescue-mode via a Debian 12.5 installer on a USB flashdrive and reinstall
the older grub (bookworm's 2.06-etc) from that.

I did upgrade the BIOS after that (from 2.36 -> 2.37, via fwupdmgr), but
I do not remember if I tried grub 2.12-1 again after that.  (By then, I was
just wanting to get some work done.)

-mm


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/mentos--vg-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda4 /boot ext2 rw,relatime 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

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

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

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

export menuentry_id_option

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

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

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
else
  search --no-floppy --fs-uuid --set=root 6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
else
  search --no-floppy --fs-uuid --set=root 6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-19f8d973-adaa-4fa2-8fb4-74ac2cc923f9' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
else
  search --no-floppy --fs-uuid --set=root 
6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
fi
echo'Loading Linux 6.6.15-amd64 ...'
linux   /vmlinuz-6.6.15-amd64 root=/dev/mapper/mentos--vg-root ro  
quiet rd.driver.blacklist=nouveau nouveau.modeset=0 modprobe.blacklist=nouveau 
no_console_suspend modprobe.blacklist=mei_wdt rd.driver.blacklist=mei_wdt 
acpi_osi=Linux
echo'Loading initial ramdisk ...'
initrd  /initrd.img-6.6.15-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 

Bug#1064343: tput sgr0 adds uncalled-for codes

[Paul Wise]

On Tue, 2024-02-20 at 19:41 +0100, Sven Joachim wrote:

> Maybe that is true for the Linux console, but we are talking about xterm here.

It is actually gnome-terminal, but I guess that doesn't change things,
I presume gnome-terminal emulates xterm faithfully enough.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1057536: tiles-autotag: FTBFS with default Java 21

[tony mancill]

On Fri, Feb 16, 2024 at 04:22:14PM +1300, Vladimir Petko wrote:
> Hi,
> 
> The issue is caused by the outdated version of the byte-buddy. Upgrading it
> to 1.14 should solve the issue.
> The issue can be worked around by adding -Dnet.bytebuddy.experimental=true
> to the argLine in maven-surefire-plugin.

FTBFS with Java 21 fixed via the work-around for now.

Bug#1063842: openssh-server: Binding to a static IPv6 address causes sshd to fail at bootup

[bert]

Thanks for the info on making a persistent change, this is helpful as a 
workaround for now.

I had previously tried to make it start after networking or networkmanager, 
without success. It seems it doesn’t wait for DAD.

It would be better if SSHD didn’t give up in scenarios like this, and kept 
retrying to start. For hosts without physical access, a lack of SSHD can be a 
big problem. 

Firewall rules are not always desirable, as enabling the firewall (and 
especially conntrack) can incur a significant performance hit, or introduce 
other problems. Systems acting as routers, or being used for network scanning 
for example.

There are also other reasons to bind to specific addresses, for instance if you 
want to run something else on the same port but a different address.

In any case binding to a specific address is a documented feature of OpenSSH, 
so it should be usable.

Bug#1052138: RFS: ukui-kwin/5.27.5-1 [ITP] -- UKUI window manager gl utils library

[Aron Xu]

Hi,

On Tue, 20 Feb 2024 14:43:22 +0800 MouseZhang  wrote:
> Hi,
>
> Thanks for your inquiry regarding the package.
>
> > * Which version of the original kwin is used?
> Based on version 5.27.5 of the original kwin.
>

OK, please document that somewhere in your release.

> > * What is missing from the original kwin and why is a fork needed?
> The decision to fork the original kwin was driven by specific needs and 
> requirements that were not fully met by the original project.
> This fork allows us to tailor the window manager more closely to our specific 
> features within the UKUI environment.
> 1. Tablet Mode Support: We have incorporated support for the UKUI tablet 
> mode, which differs from the existing tablet mode mechanism in KWin. 
> Therefore, corresponding modifications are required to adapt to our desktop 
> environment.
> 2. Virtual Keyboard: We have developed a virtual keyboard, but the current 
> window layering in KWin does not fully meet our needs. Particularly, when 
> using the virtual keyboard for text input, pop-up windows such as QCompleter 
> often obscure the virtual keyboard. To address this issue, we need to add a 
> new window layer to ensure that the virtual keyboard always displays above 
> popup windows.
> 3. Custom Protocols: To fulfill the application requirements in the UKUI 
> environment, we have added or modified certain protocols, such as the blur 
> effect with gradual intensity changes.
> 4. Window Snapping Functionality: We have implemented a window snapping 
> feature similar to that in Windows 11, which allows users to manage windows 
> more efficiently.
> 5. Global Gestures: We have replaced the original edge gestures in KWin with 
> global gestures, such as using a four-finger swipe to invoke search.
> 6. Dependency Management: We aim to release UKUI without some of the 
> dependencies associated with the Plasma desktop environment, while still 
> using KWin as our window manager and Wayland compositor.
> 7. X11 Support: We require continued support for X11 and plan to develop new 
> features to ensure flexibility and compatibility of UKUI across various 
> systems.
>

Understood.

> > * What changes have been made based on the original kwin?
> Currently, ukui-kwin only replaces the name and does not conflict with the 
> original kwin.
> In order to meet the Ubuntu DebianImportFreeze deadline, we hope to first 
> introduce ukui-kwin into the Debian repository and then proceed with 
> functionality transplantation. The existing kwin repository used by the UKUI 
> desktop environment is located at https://gitee.com/openkylin/kwin, which 
> includes the aforementioned functionality. However, this conflicts with the 
> original kwin, so we need to fork ukui-kwin. Subsequently, the functionality 
> will be transplanted into UKUI-Kwin (https://gitee.com/openkylin/ukui-kwin).
>

But this does not sound like a reason to just rename and release - if
the reasons behind forking it aren't addressed to some certain extent,
it makes little to no sense to duplicate it in the archive. Therefore
I'd vote my -1 regarding this upload.

Thanks,
Aron

Bug#1064382: ITP: coremltools -- tools for Core ML model conversion, editing, and validation

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: coremltools
  Version : 7.1
  Upstream Authors: Apple Inc. 
  URL : https://github.com/apple/coremltools
* License : BSD-3-Clause
  Description : supporting tools for Core ML model conversion, 
editing, and validation
 This is Core ML Tools (coremltools) to convert machine learning models 
from
 third-party libraries to the Core ML format. This Python package 
contains the

 supporting tools for converting models from training libraries.

Bug#1061437: firefox-esr: Fails to build with Python 3.12 as default

[Mike Hommey]

On Tue, Feb 20, 2024 at 11:59:11PM -0500, Jeremy Bícha wrote:
> Amin Bandali collected several other fixes that were necessary for
> mozjs115 to build with Python 3.12 beyond the one that I noticed was
> included in 115.8.
> 
> You can find them in the python3.12 patches in
> https://salsa.debian.org/gnome-team/mozjs/-/tree/debian/115/master/debian/patches
> 
> (Note that mozjs115 is partially stripped down so I can't guarantee
> that even those patches are complete for firefox-esr's needs.)
> 
> Therefore, I presume we will need to reopen this bug, but I have not
> tried building firefox-esr myself.

I've totally built Firefox 115esr with python 3.12 without those
patches. At quick glance, they touch code that is not involved during
the build.

Mike

Bug#1064381: ITP: elfkickers -- collection of programs that access and manipulate ELF files

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: elfkickers
  Version : 0+git20240221+ds
  Upstream Authors: Brian Raiter 
  URL : https://github.com/BR903/ELFkickers
* License : GPL-2-or-later
  Description : collection of programs that access and manipulate 
ELF files

 This distribution is a collection of programs that are generally
 unrelated, except in that they all deal with the ELF file format.
 .
 The main purpose of these programs is to be illustrative and
 educational -- to help fellow programmers understand the ELF file
 format and something of how it works under the Linux platform. For the
 most part, these programs have limited real-world utility.
 .
 With the exception of shared use of the elfrw static library, each
 program is independent of the others. There is no other shared code
 between them, and they all take slightly different approaches to
 handling ELF files.

Bug#1057533: qpid-proton-j-extensions: FTBFS with default Java 21

[tony mancill]

On Fri, Feb 16, 2024 at 04:10:16PM +1300, Vladimir Petko wrote:
>  [1] 
> https://salsa.debian.org/java-team/qpid-proton-j-extensions/-/merge_requests/1

Merged and uploaded.  Thank you for patch!

Bug#1061437: firefox-esr: Fails to build with Python 3.12 as default

[Jeremy Bícha]

Amin Bandali collected several other fixes that were necessary for
mozjs115 to build with Python 3.12 beyond the one that I noticed was
included in 115.8.

You can find them in the python3.12 patches in
https://salsa.debian.org/gnome-team/mozjs/-/tree/debian/115/master/debian/patches

(Note that mozjs115 is partially stripped down so I can't guarantee
that even those patches are complete for firefox-esr's needs.)

Therefore, I presume we will need to reopen this bug, but I have not
tried building firefox-esr myself.

Thank you,
Jeremy Bícha

Bug#1064378: libevolution: identified for time_t transition but no ABI in shlibs

[Jeremy Bícha]

On Tue, Feb 20, 2024 at 7:24 PM Michael Hudson-Doyle
 wrote:
> It is therefore not obvious that we should rename the package to
> 'libevolution-t64' as part of this transition.
>
> Looking at the archive, the only packages that depend on this package
> are also built from the evolution source package.

evolution-ews also depends on libevolution. However, evolution and
evolution-ews have such a strict dependency on evolution-data-server
that I agree that I don't think any change will be necessary for
evolution. Note that evolution-data-server is getting its libraries
renamed for the time transition.

I also expect to do an evolution 3.52 transition soon after the time
transition completes.

Thank you,
Jeremy Bícha

Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed

[Jeremy Bícha]

On Tue, Feb 20, 2024 at 8:18 PM Alban Browaeys  wrote:
> gnome-control-center 46~beta-1 is supposed to already be ported to the
> new gnome-online-accounts gtk4 API, from
> " online-accounts: port to new API"
> https://gitlab.gnome.org/GNOME/gnome-control-center/-/commit/80fcc8c2f26f7561538418fc5d72e18ecbbe512b
> so I believe that in sid gnome-control-center 46~beta-1, managing
> accounts from gnome-online-accounts should already broken.
> But installing this sid version, I can still show all accounts details
> with gnome-online-accounts 3.49.0. I can also remove and adda kerberos
> account.

The new gnome-online-accounts API was implemented in
gnome-control-center upstream version 46.beta.1. In Debian, we adjust
the first . to ~ to make 46~beta.1 (to ensure that 46~beta sorts lower
than 46.0). The downstream Debian version is the part of the version
number after the final - . So, 46~beta-1 is actually upstream's
46.beta instead of 46.beta.1. The final -1 just means this is the
"first" Debian revision for that upstream version. Sorry, that it is
so confusing here.

Yes, we intentionally did not package 46.beta.2 (or beta.1) yet
because of how disruptive the new gnome-online-accounts version will
be. It will take some time to think about how to handle it.

Thank you,
Jeremy Bícha

Bug#1064346: Source is missing errors on HTML source files

[Soren Stoutner]

Shriram,

1.  For anything that has the unminified source in the upstream tarball, I 
would just create a 
lintian override with a comment listing the full path to the source for each 
file.  You can see 
an example of how this can be done here:

https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/lintian-overrides?ref_type=heads[1]

Typically you only copy the source to the debian/missing-sources directory when 
it is not 
included in the upstream tarball and you have had to acquire it from another 
place.

2.  The github link below includes an embedded font in woff format.  Typically, 
fonts like 
this would be considered compiled, so a separate font source would be needed.  
However, 
I’m not sure what the Debian guidance for dealing with an HTML embedded font 
like this.  
If someone else on mentors doesn’t know, I would recommend you ask on 
debian-legal.

As these are mostly README files, and if it becomes difficult for you to 
acquire the source 
for some of them, you might consider excluding those you can’t get the source 
for, at least 
temporarily, using Files-Excluded in debian/copyright (and then running uscan, 
which will 
produce a modified tarball that does not include the problematic files).  For 
example, see:

https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright?
ref_type=heads[2]

Whether this is a good option depends on how helpful those README files are for 
the users 
of your package.  If you go this route, you should add +dfsg to the version of 
your package 
to indicate that the upstream tarball has been repackaged to remove files that 
are not free 
(or for which the source is not available).

Soren

On Tuesday, February 20, 2024 8:23:41 PM MST Shriram Ravindranathan wrote:
> Thanks, Soren.
> 
> It looks like most of these files have just one or two lines that are 
> extremely long.
> 
> These are mostly README files. Most of them seem to have this 
> github-markdown.css 
>  
> minified and pasted in them. While others have the sources that were 
> used to generate them listed in the same folder.
>
> Should I copy these sources into the d/missing-sources directory?

-- 
Soren Stoutner
so...@debian.org


[1] 
https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/
lintian-overrides?ref_type=heads
[2] 
https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright?
ref_type=heads


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

Bug#1060326: #1060326,RM: obs-studio [ppc64el] -- ROM; unsatisfied build-dependency

[James Lu]

Hi,

Forwarding this along to maintainers of the affected packages. If 
there's no objection, I can look at opening those RM bugs.


(Chiming in here as I'm also affected by obs-studio being kicked from 
testing with looking-glass)


Best,
James

On Sun, 14 Jan 2024 17:16:55 + (UTC) Thorsten Alteholz 
 wrote:

Control: tags -1 + moreinfo

Hi IOhannes,

there are reverse dependencies that need to be taken care of:


Checking reverse dependencies...
# Broken Depends:
obs-3d-effect: obs-3d-effect
obs-advanced-scene-switcher: obs-advanced-scene-switcher
obs-ashmanix-blur-filter: obs-ashmanix-blur-filter
obs-ashmanix-countdown: obs-ashmanix-countdown
obs-color-monitor: obs-color-monitor
obs-command-source: obs-command-source
obs-downstream-keyer: obs-downstream-keyer
obs-gradient-source: obs-gradient-source
obs-move-transition: obs-move-transition
obs-ptz: obs-ptz
obs-scene-as-transition: obs-scene-as-transition
obs-scene-collection-manager: obs-scene-collection-manager
obs-scene-notes-dock: obs-scene-notes-dock
obs-scene-tree-view: obs-scene-tree-view
obs-source-clone: obs-source-clone
obs-source-copy: obs-source-copy
obs-time-source: obs-time-source
obs-transition-table: obs-transition-table
obs-vintage-filter: obs-vintage-filter
obs-websocket: obs-websocket

# Broken Build-Depends:
looking-glass: libobs-dev
obs-3d-effect: libobs-dev (29 >=)
obs-advanced-scene-switcher: libobs-dev (26.1.2 >=)
obs-ashmanix-blur-filter: libobs-dev
obs-ashmanix-countdown: libobs-dev (29 >=)
obs-color-monitor: libobs-dev (29 >=)
obs-command-source: libobs-dev (29 >=)
obs-downstream-keyer: libobs-dev (29 >=)
obs-gradient-source: libobs-dev (29 >=)
obs-move-transition: libobs-dev (28.0.1 >=)
obs-ptz: libobs-dev
obs-scene-as-transition: libobs-dev (29 >=)
obs-scene-collection-manager: libobs-dev (28.0.1 >=)
obs-scene-notes-dock: libobs-dev (29 >=)
obs-scene-tree-view: libobs-dev (29 >=)
obs-source-clone: libobs-dev (29 >=)
obs-source-copy: libobs-dev (29 >=)
obs-time-source: libobs-dev
obs-transition-table: libobs-dev (29 >=)
obs-vintage-filter: libobs-dev (29 >=)
obs-websocket: libobs-dev (26.1 >=)


In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


   Thorsten




OpenPGP_0x2EC3F60DE71C0B9D.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064380: RFS: jpeginfo/1.7.1-1 [Team] -- Prints information and tests integrity of JPEG/JFIF files

[肖盛文]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : jpeginfo
Version : 1.7.1-1
Upstream contact : [fill in name and email of upstream]
* URL : https://www.kokkonen.net/tjko/projects.html
* License : GPL-3
* Vcs : https://salsa.debian.org/debian-phototools-team/jpeginfo
Section : graphics

The source builds the following binary packages:

jpeginfo - Prints information and tests integrity of JPEG/JFIF files

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/j/jpeginfo/jpeginfo_1.7.1-1.dsc


Changes since the last upload:

jpeginfo (1.7.1-1) unstable; urgency=medium
.
* Team upload.
* New upstream version
* d/copyright:
- update copyright year info to 2024
- change upstream License to GPL-3
* use upstream make install
- d/rules: delete override_dh_auto_install target
- delete d/install d/manpages
* d/rules:
- add export DEB_BUILD_MAINT_OPTIONS = hardening=+all
- add override_dh_autoreconf target
* remove d/patches, no more use
* d/watch: add opts=pgpsigurlmangle=s%$%.sig%
* add d/clean
* add d/u/metadata
* add d/u/signing-key.asc

Regards,

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064346: Source is missing errors on HTML source files

[Shriram Ravindranathan]

Thanks, Soren.

It looks like most of these files have just one or two lines that are 
extremely long.


These are mostly README files. Most of them seem to have this 
github-markdown.css 
 
minified and pasted in them. While others have the sources that were 
used to generate them listed in the same folder.


Should I copy these sources into the d/missing-sources directory?

On 21/02/24 2:28 am, Soren Stoutner wrote:

The question is if the long lines in these HTML files are actually indications
that the HTML files are not the original source.  This usually happens in one
of two cases.

1.  The files have been minified.
2.  The files were originally created in another format and converted to HTML.

Sometimes HTML files naturally have long lines.  If you look at the
descriptions of the lintian warnings, they acknowledge that this is an
imperfect check that will result in some false-positives.  If that is the
case, the HTML files are the original source, and they have not been minified,
then you can override these warnings with a description as to why.

On Tuesday, February 20, 2024 9:08:17 AM MST Shriram Ravindranathan wrote:

Hello mentors,

I am getting a few lintian "source-is-missing" errors for some HTML
files. These HTML files are infact present in the source code but they
have too many lines which triggers a
"very-long-line-length-in-source-file" lintian tag and that in turn
causes the "source-is-missing" error.

Most of the info I could find in the policy manual and in the forums
pertained to binary files that were included in the source, the strategy
these resources suggested were
1. Repack upstream tar with the source code of these files
2. Add the source code to the d/missing-sources directory

I don't think either of these are viable options in my case. I was
wondering whether it would be okay to suppress these errors. Is there
any other way to solve this?

--
Shriram Ravindranathan




--
Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#961834: New release

[john faulk]

Hello everyone,
its been a while since this was last discussed, and it seemed tagging
a new release was pre-requisite to being added back to debian. Thus, I
have forked the fork, and tagged a release, shown below:
https://github.com/MrReplikant/clearlooks-phenix/releases/tag/7.0.2

I am doing this as such to volunteer to be the guardian of this
release until someone more willing/capable/knowledgeable of theming is
able to take over from me. my hopes is that this will allow
clearlooks-phenix to be allowed back into the repo.

if there are any questions or concerns, please do not hesitate to contact me

-John

Bug#1064298:

[Michael Hudson-Doyle]

Hi, thanks so much for this. I've updated the diff in bug 1064090 to
include your changes (and uploaded the new package to experimental as
~exp2).

Bug#1064379: kexec-tools: Request to pull v2.0.28 for loong64 architecture.

[Ming Wang]

Package: kexec-tools
Version: 1:2.0.27-1
Source Version: 1:2.0.27-1
Severity: wishlist
Tags: fixed-upstream
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear kexec-tools maintainers,

I found that currently there are build errors with kexec-tools for loong64 
architecture,see[1].
The upstream code has been fixed, see [2]. v2.0.28 already contains relevant 
patch.

So is it possible to pull kexec-tools-v2.0.28 for loong64?

[1]: https://buildd.debian.org/status/package.php?p=kexec-tools=sid
[2]: 
https://github.com/horms/kexec-tools/commit/ab3a70af85679bbc5efe63057c7f65365ed6e748

thanks,
Ming

Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed

[Alban Browaeys]

On Wed, 21 Feb 2024 01:43:11 +0100 Alban Browaeys 
wrote:
> Note that 3.49.1 also includes a migration to GTK4 and API changes
> which would breaks gnome-control-center 45 "Bump soname?"
> https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/291
> Though we have gnome-control-center 46~alpha-2 in trixie and 46~beta-
1
> in sid, I don't know which gnome-control-center 46 release was ported
> to this API (as I have 1:46~alpha-2 currently I believe it is not
> ported yet as it works with gnome-online-accounts 3.49.0).
> 


gnome-control-center 46~beta-1 is supposed to already be ported to the
new gnome-online-accounts gtk4 API, from
" online-accounts: port to new API"
https://gitlab.gnome.org/GNOME/gnome-control-center/-/commit/80fcc8c2f26f7561538418fc5d72e18ecbbe512b
so I believe that in sid gnome-control-center 46~beta-1, managing
accounts from gnome-online-accounts should already broken.
But installing this sid version, I can still show all accounts details
with gnome-online-accounts 3.49.0. I can also remove and adda kerberos
account.

Cheers,
Alban

Bug#1062022: dcmtk: NMU diff for 64-bit time_t transition

[Michael Hudson-Doyle]

On Wed, 31 Jan 2024 at 22:03, Mathieu Malaterre  wrote:

> Hi,
>
> On Wed, Jan 31, 2024 at 1:09 AM  wrote:
> > If you have any concerns about this patch, please reach out ASAP.
> Although
> > this package will be uploaded to experimental immediately, there will be
> a
>
> Are you going to nuke my work on dcmtk 3.6.8 transition ?
>

Hi,

Sorry for the late reply. No, we are not going to nuke your work on the
transition. We still expect to NMU dcmtk to unstable along with the other
packages to avoid creating a dependence on your timetable, but you should
be able to ignore those changes when you do your transition in unstable.

Cheers,
mwh

Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed

[Alban Browaeys]

The 405 status was locally and manually fixed by applying the "webdav
migration" implemented upstream in merge request 146.

That is in ~/.config/goa-1.0/accounts.conf for my owncloud provider,
add "remote.php/webdav" to the "https://nextcloud.domain/; in the "Uri"
key.
I also create CalDavUri and CardDavUri from the "Uri" key but appending
"remote.php/dav" to them instead of "remote.php/webdav".
I got the clue from the issue "critical when testing new WebDav support
on existing nextcloud account: g_uri_peek_scheme: assertion 'uri !=
NULL' failed"
https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/276 ).


The fix: "goabackend: migrate existing WebDAV
accounts"https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/146
It is merged in 3.49.1 (while Debian is 3.49.0).

Note that 3.49.1 also includes a migration to GTK4 and API changes
which would breaks gnome-control-center 45 "Bump soname?"
https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/291
Though we have gnome-control-center 46~alpha-2 in trixie and 46~beta-1
in sid, I don't know which gnome-control-center 46 release was ported
to this API (as I have 1:46~alpha-2 currently I believe it is not
ported yet as it works with gnome-online-accounts 3.49.0).

Might be the best way for now is to port the merge request 146 to
3.49.0 in Debian trixie.

The API breakage in gnome-control-center was done in "goabackend: port
to GTK4"
https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/142
which is merged into 3.49.1.

Cheers,
Alban

On Sat, 27 Jan 2024 08:11:10 +0100 Alban Browaeys 
wrote:
> Package: gnome-online-accounts
> Version: 3.49.0-1
> Severity: important
> 
> 
> I upgrade gnome-online-accounts from 3.48.0-2 to 3.49.0-1, I still
had
> Nextcloud ok in gnome-control-center (Settings) 1:46~alpha-2.
> Then on one box I rebooted, then I got "Credential have expired" for
> Nextcloud in Settings. Trying to authenticate anew gave me "Error
> connecting to WebDAV server: Authentication failed".
> 
> I then tried on the other box, which still had nextcloud login ok,
where
> I also upgraded gnome-control-center but did not yet restart it, to
> kill goa-daemon and restart it. Then I ended up with the same error
as
> wiht the box I rebooted.
> 
> Settings output is:
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: Starting new address enumeration
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: lookup_by_name_with_flags_async: starting new lookup for
cloud.prahal.homelinux.net with GTask 0x5581b3e13eb0, LookupData
0x5581b3ce9500
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: lookup_by_name_with_flags_async: starting new lookup for
cloud.prahal.homelinux.net with GTask 0x5581b3d76160, LookupData
0x5581b3d1c5b0
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: Address enumeration succeeded
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: Starting TCP connection attempt
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: TCP connection successful
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: Starting application layer connection
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: Connection successful!
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]:
GoaBackend: goa_dav_client_check(): response (0x5581b422b970, 405)
> 
> Note the 405 status.
> Could it be my old Nextcloud version does not support a method call
from
> goa 0.49.0?
> 

Bug#1064378: libevolution: identified for time_t transition but no ABI in shlibs

[Michael Hudson-Doyle]

Package: libevolution
Version: 3.50.3-1
Severity: important
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainers,

Analysis of the archive for the 64-bit time_t transition[0][1]
identifies libevolution as an affected package, on the basis that the
headers could not be compiled and analyzed out of the box using
abi-compliance-checker[2], so we have to assume it's affected (also, a
quick manual peek at the headers suggests that the package very likely
to be affected by the transition!)

However, libevolution's shlibs file declares a dependency on a library
package name that contains no ABI information:

$ cat DEBIAN/shlibs
libeabutil 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libeabwidgets 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libecontacteditor 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libecontactlisteditor 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libecontactprint 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libemail-engine 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libessmime 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-addressbook-importers 0 libevolution (>= 3.50.3), libevolution (<< 
3.51)
libevolution-calendar-importers 0 libevolution (>= 3.50.3), libevolution (<< 
3.51)
libevolution-calendar 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail-composer 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail-formatter 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail-importers 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-shell 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-smime 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-util 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libgnomecanvas 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
$

It is therefore not obvious that we should rename the package to
'libevolution-t64' as part of this transition.

Looking at the archive, the only packages that depend on this package
are also built from the evolution source package.

Since there is no self-evident thing to do with the library package
name here, we will not be handling this package as part of the mass
NMUs.  Instead I am filing a serious bug because partial upgrades from
bookworm to trixie on 32-bit architectures (e.g. upgrading
libevolution without also upgrading evolution-plugin-bogofilter) will
result in ABI skew and may result in broken behavior.

Cheers,
mwh

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html
[2] 
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-16T21%3A19%3A00/logs/evolution-dev/base/log.txt


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#1064377: tcl-expect: identified for time_t transition but no ABI in shlibs

[Michael Hudson-Doyle]

Package: tcl-expect
Version: 5.45.4-2build1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainers,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
tcl-expect as an affected package, on the basis that the headers could
not be compiled and analyzed out of the box using abi-compliance-checker[2],
so we have to assume it's affected.

However, tcl-expect' shlibs file declares a dependency on a library
package name that contains no ABI information:

$ cat DEBIAN/shlibs
libexpect 5.45 tcl-expect
$

It is therefore not obvious that we should rename the package to
'tcp-expect-t64' as part of this transition.

Looking at the archive, there is a package built from a separate source
package, 'skycat', which depends on this library

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs.
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures (upgrading tcl-expect without also upgrading
skycat) will result in ABI skew and may result in broken behavior.

Cheers,
mwh

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html
[2] 
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-16T21%3A19%3A00/logs/tcl-expect-dev/base/log.txt


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#1064369: gobject-introspection dropped versioned dependency on python3

[Jeremy Bícha]

On Tue, Feb 20, 2024 at 6:27 PM Simon McVittie  wrote:
> It's unfortunate that Ubuntu is trying to go directly from
> gobject-introspection 1.78.1-6 to 1.79.x, without ever getting the higher
> 1.78.1-x revisions that are in Debian testing: that would have decoupled
> the introduction of new binary packages from the GLib 2.79.x and Python
> 3.12 transitions.

Unfortunately, gobject-introspection 1.78.1-13 was uploaded a few
hours after Ubuntu started the Python 3.12 transition which has not
quite finished. We also thought that it was getting late to not have
gotten glib into Ubuntu so we synced glib 2.79 which then forced us to
get gboject-introspection 1.79 too. So glib can't migrate without
gobject-introspection which has to wait for python3-defaults to
migrate.

https://salsa.debian.org/gnome-team/gobject-introspection/-/merge_requests/14

I think there are few enough packages involved that we can manually
trigger the autopkgtests we need this week since I got the meson
ppc64el autopkgtest to pass.

Thank you,
Jeremy Bícha

Bug#1042955: zzzeeksphinx: please make the output reproducible

[James Addison]

Followup-For: Bug #1042955
Control: forwarded -1 https://github.com/sqlalchemyorg/zzzeeksphinx/issues/23

Bug#1064369: gobject-introspection dropped versioned dependency on python3

[Simon McVittie]

On Tue, 20 Feb 2024 at 23:15:09 +0100, Matthias Klose wrote:
> On 20.02.24 22:50, Simon McVittie wrote:
> > What is the situation that is going wrong in autopkgtest? Can you perhaps
> > provide a log?
> 
> see
> https://autopkgtest.ubuntu.com/packages/m/meson/noble/ppc64el
> 
> the one triggered by python3-defaults/3.12.1-0ubuntu1
> gobject-introspection/1.79.1-1

Do you mean b2bf9aa6-b7bf-4f75-a69c-d2292de2ebbe, requested by you with
those two packages as triggers, which failed like this?

377s autopkgtest [20:34:18]: test exhaustive: preparing testbed
...
559s The following packages have unmet dependencies:
559s  gobject-introspection : Depends: python3 (< 3.12) but 3.12.1-0ubuntu1 is 
to be installed
559s  python3-dev : Depends: python3 (= 3.11.4-5ubuntu1) but 3.12.1-0ubuntu1 is 
to be installed
559s E: Unable to correct problems, you have held broken packages.
559s autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt 
install on test deps directly for further data about failing dependencies in 
test logs
559s exhaustive   FAIL badpkg

It isn't clear to me why that one is failing. apt seems to have started
by trying to install gobject-introspection_1.78.1-6, even though it had
--apt-pocket=proposed=src:python3-defaults,src:gobject-introspection on the
autopkgtest command-line - which I would have expected would make all binary
packages from src:gobject-introspection have 1.79.1-1 as the candidate
version?

Is it possible that autopkgtest might be adding pins for all of the
binary packages built by src:gobject-introspection in noble that will
take those binary packages from -proposed, but without adding similar pins
for the binary packages that were newly added in -proposed? Or some similar
interaction?

It's unfortunate that Ubuntu is trying to go directly from
gobject-introspection 1.78.1-6 to 1.79.x, without ever getting the higher
1.78.1-x revisions that are in Debian testing: that would have decoupled
the introduction of new binary packages from the GLib 2.79.x and Python
3.12 transitions.

> The problem is, that the -bin package is new and that no rdeps know about it
> yet.

rdeps are not meant to depend on the -bin package directly (it's meant
to be an implementation detail of the main g-i package), so any solution
that involves adding the -bin package to rdeps' dependencies seems like
the wrong thing. Ideally, all rdeps continue to not know about it.

smcv

Bug#1064016: fixed in adwaita-icon-theme 46~beta-2

[Amy Kos]

Thank You for the explanation.
My prior suggestion is not worthwhile.


What names is it looking for?


lxqt-config/lxqt-config-appearance looks for:

left_ptr_watch -> progress
size_fdiag -> nwse-resize
d9ce0ab605698f320427677b458ad60b -> help

None of these cursors are high-visibility.
The hash-based alias is likely not visible at all.

I'll try to contact LXQt upstream to address this minor issue.

I would prefer not to have too many aliases that have been specifically 
rejected upstream


Right. I fully agree.

Cheers,
Amy

Bug#1060829: Bug#1061384: acl2: add support for loongarch64

[Camm Maguire]

Greetings, and thanks for your reports!  GCL is the key to porting these
programs and more.  Is there any remote ssh access to a machine on which
I may implement this?

Take care,

zhangdandan  writes:

> Source: acl2
> Version: 8.5dfsg-5
> Severity: wishlist
> Tags: patch
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
>
> Dear maintainers,
>
> Maybe we need to add LoongArch support in
> books/kestrel/x86/parsers/parse-pe-file.lisp.
> Refer to riscv64, please consider the patch I have attached.
> If you have better modification suggestions, please help us fix this patch.
>
> I would like to remind you that the compilation dependency of acl2 is
> not yet satisfied. Depends on the gcl ( >= 2.6.14-1) package when 
> compiling acl2.
> If you have any questions, you can contact me at any time.
>
> thanks,
> Dandan Zhang
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#1052300: O: xdaliclock -- Melting digital clock

[Tormod Volden]

I would be happy to maintain this package. It is a Suggests dependency
for the xscreensaver package that I am already maintaining. With the
same upstream and much of the same libraries and tooling I think it
shouldn't be too much extra effort for me.

I have staged commits to https://salsa.debian.org/tormod/xdaliclock
that makes the package (currently a broken and unreleased 2.47-1
version in the main repo) build correctly again. Merging in the new
2.48 release goes without issues, I just haven't pushed this (simply
since I reserve the right to polish this until it has been merged into
the main repo, and rebasing is more work with an upstream merge in the
middle). Please feel free to merge this in any case.

Note that I need a sponsor for uploads (I may work towards upload
rights for xscreensaver and this one), and I would need to be added to
the main repo. I haven't asked my regular xscreensaver sponsor yet if
he's willing to do this, but I think that is a possibility.

Regards,
Tormod

Bug#1064376: RM: ganglia -- ROM; Unmaintained upstream, better alternatives exist

[Marcos Fouces]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: mar...@debian.org
User: ftp.debian@packages.debian.org
Usertags: remove

Bug#1043240: transition: pandas 1.5 -> 2.1

[Rebecca N. Palmer]

Remaining blockers for testing migration:
- python-ulmo #1044057: has a patch, please upload
- pydevd #1063274: unclear whether my patch breaks something else, 
please leave alone for now


Status unclear:
- python-xarray: autopkgtest has failed 3 times, but all 3 are 
(different) failures that have occurred without pandas 2, apparently at 
random
- q2-*: autopkgtest fails in "fixed" versions, but possibly because 
they're not all being tested together

Bug#1064375: rust-gtk: Unmaintained library should not be included in Trixie

[Jeremy Bícha]

Source: rust-gtk
Version:
Severity: important
Tags: trixie sid
Control: block -1 by 1064373 1064374

rust-gtk is no longer maintained upstream. I believe we should not
include it in the next Debian Stable release, codenamed Trixie.

https://gtk-rs.org/blog/2023/08/28/new-release.html

Thank you,
Jeremy Bícha

Bug#1064374: rust-gtk-layer-shell-sys: Depends on obsolete rust-gtk

[Jeremy Bícha]

Source: rust-gtk-layer-shell-sys
Version: 0.7.0-1
Severity: serious
X-Debbugs-CC: maytha8the...@gmail.com, sylves...@debian.org

rust-gtk-layer-shell-sys (and rust-gtk-layer-shell) depends on
rust-gtk which is the old GTK3 library that is no longer maintained.
rust-gtk is only in Debian because of squeekboard.

Please instead package https://crates.io/crates/gtk4-layer-shell and
encourage apps using the old rust-gtk-layer-shell to switch to the
gtk4 version.

Please let me know if there is a reason we should not file a removal
bug for rust-gtk-layer-shell-sys (which only appeared in Debian this
month).

On behalf of the Debian Rust Maintainers,
Jeremy Bícha

Bug#1064373: squeekboard: Depends on obsolete rust-gtk

[Jeremy Bícha]

Source: squeekboard
Version: 1.22.0-5
Severity: important
Tags: upstream trixie sid
Forwarded: https://gitlab.gnome.org/World/Phosh/squeekboard/-/issues/64

rust-gtk (the old GTK3 bindings) are no longer maintained. Squeekboard
is the last thing keep rust-gtk in Debian. Please switch to rust-gtk4.

Thank you,
Jeremy Bícha

Bug#1064369: gobject-introspection dropped versioned dependency on python3

[Matthias Klose]

On 20.02.24 22:50, Simon McVittie wrote:

Control: tags -1 + moreinfo

On Tue, 20 Feb 2024 at 22:15:21 +0100, Matthias Klose wrote:

The package had in the past dependencies of the form

   python3 (<< 3.12), python3 (>= 3.11~), python3:any

the new one just

   python3:any

This leads to badly triggered autopkg tests, with a mismatching
python3-defaults.  Afaik, gobject-introspection can only handle the default
python version, not all supported python versions.


The parts that require a specific python3 version are now in the
gobject-introspection-bin binary package, which correctly depends on:

 python3 (<< 3.12), python3 (>= 3.11~), python3:any

via dh_python and ${python3:Depends}. The gobject-introspection package
no longer contains any binary Python extensions. This was necessary to be
able to make it a Multi-Arch: same wrapper around a build-architecture
gobject-introspection-bin.

As far as I can see, it would not be straightforward to add a
lockstep-Python-version dependency to gobject-introspection, because it
does not directly contain any binary Python extensions itself (although
of course anyone wanting to prove me wrong is welcome to provide an
implementation).

gobject-introspection depends on gobject-introspection-linux-little-endian
(= 1.78.1-15) (or -big-endian on s390x, etc.). That's a virtual package
provided by gobject-introspection-bin, ensuring that gobject-introspection
and gobject-introspection-bin are upgraded in lockstep; so it should
not be possible to install a mismatched set.

What is the situation that is going wrong in autopkgtest? Can you perhaps
provide a log?


see
https://autopkgtest.ubuntu.com/packages/m/meson/noble/ppc64el

the one triggered by python3-defaults/3.12.1-0ubuntu1 
gobject-introspection/1.79.1-1



If gobject-introspection explicitly depended on gobject-introspection-bin
by name (not just via a virtual package), would that help?


I think that would do it, deps there are:

python3 (<< 3.13), python3 (>= 3.12~), python3:any

The problem is, that the -bin package is new and that no rdeps know 
about it yet.

Bug#1062772: apt: apt.conf(5) should document all options

[Thorsten Glaser]

Hi Wesley,

> /usr/share/doc/apt/examples/configure-index. It documents all the options you
> can find.

ah, interesting.

It does not document all the options I can find, though.

It lists them all. Some have a short comment, which for
a small number of them passes for documentation; default
values are also only shown exceedingly rarely.

That is more useful than not having it, but… still not
quite there yet ☺

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

Bug#1064369: gobject-introspection dropped versioned dependency on python3

[Simon McVittie]

Control: tags -1 + moreinfo

On Tue, 20 Feb 2024 at 22:15:21 +0100, Matthias Klose wrote:
> The package had in the past dependencies of the form
> 
>   python3 (<< 3.12), python3 (>= 3.11~), python3:any
> 
> the new one just
> 
>   python3:any
> 
> This leads to badly triggered autopkg tests, with a mismatching
> python3-defaults.  Afaik, gobject-introspection can only handle the default
> python version, not all supported python versions.

The parts that require a specific python3 version are now in the
gobject-introspection-bin binary package, which correctly depends on:

python3 (<< 3.12), python3 (>= 3.11~), python3:any

via dh_python and ${python3:Depends}. The gobject-introspection package
no longer contains any binary Python extensions. This was necessary to be
able to make it a Multi-Arch: same wrapper around a build-architecture
gobject-introspection-bin.

As far as I can see, it would not be straightforward to add a
lockstep-Python-version dependency to gobject-introspection, because it
does not directly contain any binary Python extensions itself (although
of course anyone wanting to prove me wrong is welcome to provide an
implementation).

gobject-introspection depends on gobject-introspection-linux-little-endian
(= 1.78.1-15) (or -big-endian on s390x, etc.). That's a virtual package
provided by gobject-introspection-bin, ensuring that gobject-introspection
and gobject-introspection-bin are upgraded in lockstep; so it should
not be possible to install a mismatched set.

What is the situation that is going wrong in autopkgtest? Can you perhaps
provide a log?

If gobject-introspection explicitly depended on gobject-introspection-bin
by name (not just via a virtual package), would that help?

Thanks,
smcv

Bug#1063274: pydevd: autopkgtest-failing warning with pandas 2.1

[Rebecca N. Palmer]

Is that a yes to>> Does just the patch (not the new upstream) also break 
debugpy?or have you not tried specifically that?


(I'm looking for a quick fix for the autopkgtest fail to unblock the 
pandas 2.x transition.  I agree that upgrading to a new upstream is a 
good idea in the long run.)



the bytecode version in pydevd is behind that in Debian,


This is currently true (Debian has python3-bytecode 0.15.1, upstream 
pydevd 2.10.0 vendors 0.13.0.dev), but if it were a problem I'd expect 
it to mean that pydevd/debugpy were *already* buggy, not that my patch 
makes them worse.

Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility

[Soren Stoutner]

Mateusz,

When compiling locally on my system, the current version of lintian (2.117.0) 
found the following problems.  These are not displayed on mentors.debian.net, 
leading me to believe they were recently added checks.

W: qt5ct: link-to-shared-library-in-wrong-package usr/lib/x86_64-linux-gnu/
libqt5ct-common.so.1.8 [usr/lib/x86_64-linux-gnu/libqt5ct-common.so]
N: 
N:   Although this package is not a "-dev" package, it installs a
N:   "libsomething.so" symbolic link referencing the corresponding shared
N:   library. When the link doesn't include the version number, it is used by
N:   the linker when other programs are built against this shared library.
N:   
N:   Shared libraries are supposed to place such symbolic links in their
N:   respective "-dev" packages, so it is a bug to include it with the main
N:   library package.
N:   
N:   However, if this is a small package which includes the runtime and the
N:   development libraries, this is not a bug. In the latter case, please
N:   override this warning.
N: 
N:   Please refer to Development files (Section 8.4) in the Debian Policy
N:   Manual for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: libraries/shared/links
N:   Renamed from: non-dev-pkg-with-shlib-symlink
N: 
N:
W: qt5ct: package-name-doesnt-match-sonames libqt5ct-common1.8
N: 
N:   The package name of a library package should usually reflect the soname of
N:   the included library. The package name can determined from the library
N:   file name with the following code snippet:
N:   
N:$ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/
^[[:space:]]*SONAME[[:space:]]*//p' | \
N:sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/\L&/'
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: libraries/shared/soname
N: 
N:
I: qt5ct: no-symbols-control-file usr/lib/x86_64-linux-gnu/libqt5ct-common.so.
1.8
N: 
N:   Although the package includes a shared library, the package does not have
N:   a symbols control file.
N:   
N:   dpkg can use symbols files in order to generate more accurate library
N:   dependencies for applications, based on the symbols from the library that
N:   are actually used by the application.
N: 
N:   Please refer to the dpkg-gensymbols(1) manual page and
N:   https://wiki.debian.org/UsingSymbolsFiles for details.
N: 
N:   Visibility: info
N:   Show-Always: no
N:   Check: debian/shlibs

As noted in the text of the checks, there are scenarios where these do not 
apply (like small packages that include the runtime and the development files), 
which appears to be the case with qt5ct.  Can you please help me to understand 
why qt5ct is including this shared library, if there are any other packages in 
Debian that are building against this library, and if you feel that any of the 
lintian checks above apply?  If you feel they don’t apply I would recommend 
you add lintian overrides and I will be happy to upload your package.

Soren

-- 
Soren Stoutner
so...@debian.org

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

Bug#1064370: python-xarray: intermittent fail in TestOpenMFDatasetWithDataVarsAndCoordsKw

[Rebecca N. Palmer]

Package: python3-xarray
Version: 2023.12.0-3

The xarray autopkgtest sometimes (~20% of the time) fails with
RuntimeError: NetCDF: Not a valid ID
in tests/test_backends.py::TestOpenMFDatasetWithDataVarsAndCoordsKw

Unlike the other random failures, this seems to be amd64-specific.

Exactly which test case fails varies:
test_open_mfdataset_does_same_as_concat[left-different-by_coords-None]
https://ci.debian.net/packages/p/python-xarray/testing/amd64/43085145/
test_open_mfdataset_dataset_combine_attrs[drop]
https://ci.debian.net/packages/p/python-xarray/testing/amd64/42861417/
test_open_mfdataset_does_same_as_concat[right-minimal-nested-t]
+ test_open_mfdataset_does_same_as_concat[right-minimal-by_coords-None]
https://ci.debian.net/packages/p/python-xarray/testing/amd64/42753466/
test_open_mfdataset_does_same_as_concat[outer-minimal-by_coords-None]
https://ci.debian.net/packages/p/python-xarray/testing/amd64/43021198/

Bug#1064369: gobject-introspection dropped versioned dependency on python3

[Matthias Klose]

Package: gobject-introspection
Version: 1.78.1-15
Severity: serious
Tags: sid trixie

The package had in the past dependencies of the form

  python3 (<< 3.12), python3 (>= 3.11~), python3:any

the new one just

  python3:any

This leads to badly triggered autopkg tests, with a mismatching 
python3-defaults.  Afaik, gobject-introspection can only handle the 
default python version, not all supported python versions.


Currently seen in Ubuntu, where 3.12 already is the default, but we will 
see this on a much larger scale when doing the 3.12 transition in 
Debian.  From my point of view, this dependency has to be added back.


Same for the version in experimental.

Bug#1064368: python-xarray: intermittent segfault in test_open_mfdataset_manyfiles[netcdf4-20-True-*-5]

[Rebecca N. Palmer]

Package: python3-xarray
Version: 2023.12.0-3

xarray sometimes (~10% of the time) segfaults in 
tests/test_backends.py::test_open_mfdataset_manyfiles, usually 
[netcdf4-20-True-None-5] but sometimes [netcdf4-20-True-5-5].


This has happened in both Python 3.11 and 3.12, and on various 
architectures:

https://ci.debian.net/packages/p/python-xarray/testing/amd64/43068287/
https://ci.debian.net/packages/p/python-xarray/testing/armhf/42545225/
https://ci.debian.net/packages/p/python-xarray/testing/s390x/43076980/
https://ci.debian.net/packages/p/python-xarray/testing/ppc64el/42673240/

Bug#1059671: python3-capstone: Python 3.12 has no module named 'distutils'

[Timo Röhling]

On Fri, 2 Feb 2024 08:49:11 +0200 Graham Inggs  
wrote:

I believe all that is required here is patching out the import of
distutils.sysconfig:

--- a/bindings/python/capstone/__init__.py
+++ b/bindings/python/capstone/__init__.py
@@ -263,7 +263,6 @@

 import ctypes, ctypes.util
 from os.path import split, join, dirname
-import distutils.sysconfig

 import inspect
 if not hasattr(sys.modules[__name__], '__file__'):

...and dropping the dependency on python3-distutils:

--- a/debian/control
+++ b/debian/control
@@ -66,7 +67,6 @@
 Section: python
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, libcapstone4,
- python3-distutils
 XB-Python3-Version: ${python:Versions}
 Description: lightweight multi-architecture disassembly framework -
Python bindings
  Capstone is a lightweight multi-platform, multi-architecture disassembly


I just NMU'd capstone (see the attached diff)

Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/changelog b/debian/changelog
index 0133e16a..09e72715 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+capstone (4.0.2-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove vestigial distutils.sysconfig import (Closes: #1059671)
+
+ -- Timo Röhling   Tue, 20 Feb 2024 21:30:13 +0100
+
 capstone (4.0.2-5) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index a7d23515..9f422dc8 100644
--- a/debian/control
+++ b/debian/control
@@ -66,7 +66,6 @@ Package: python3-capstone
 Section: python
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, libcapstone4,
- python3-distutils
 XB-Python3-Version: ${python:Versions}
 Description: lightweight multi-architecture disassembly framework - Python bindings
  Capstone is a lightweight multi-platform, multi-architecture disassembly
diff --git a/debian/patches/0001-Remove-magic-for-loading-shared-libraries.patch b/debian/patches/0001-Remove-magic-for-loading-shared-libraries.patch
index 69f041b8..1f0e426a 100644
--- a/debian/patches/0001-Remove-magic-for-loading-shared-libraries.patch
+++ b/debian/patches/0001-Remove-magic-for-loading-shared-libraries.patch
@@ -3,17 +3,18 @@ Date: Wed, 25 Jul 2018 15:14:07 +0200
 Subject: Remove magic for loading shared libraries
 
 ---
- bindings/python/capstone/__init__.py | 46 +---
- 1 file changed, 1 insertion(+), 45 deletions(-)
+ bindings/python/capstone/__init__.py | 47 +---
+ 1 file changed, 1 insertion(+), 46 deletions(-)
 
 diff --git a/bindings/python/capstone/__init__.py b/bindings/python/capstone/__init__.py
-index 757dc7d..4917af9 100644
+index 757dc7d..0bdb782 100644
 --- a/bindings/python/capstone/__init__.py
 +++ b/bindings/python/capstone/__init__.py
-@@ -264,56 +264,12 @@ CS_OPT   = {v:k for k,v in locals().items() if k.startswith('CS_OPT_')}
+@@ -263,57 +263,12 @@ CS_OPT   = {v:k for k,v in locals().items() if k.startswith('CS_OPT_')}
+ 
  import ctypes, ctypes.util
  from os.path import split, join, dirname
- import distutils.sysconfig
+-import distutils.sysconfig
 -import pkg_resources
  
  import inspect


signature.asc
Description: PGP signature

Bug#1060016: packagekit: CVE-2024-0217

[Matthias Klumpp]

Hi!

Am Fr., 5. Jan. 2024 um 18:57 Uhr schrieb Salvatore Bonaccorso
:
> [...]
> Got a reply from Pedro Sampaio in 
> https://bugzilla.redhat.com/show_bug.cgi?id=2256624#c3
>
> It is mentioned that although the following is not a direct fix for
> the issue, that the commit in v1.2.7 to reduce the impact is the
> following:
>
> https://github.com/PackageKit/PackageKit/commit/64278c9127e342b56ead99556161f7e86f79
>
> Does that help you with your upstream hat on, and downstream in
> Debian?

Not at all... I also don't know why I should hunt around the code to
find an issue that someone else has found but where they don't tell me
where the problem even is.
The CVE page lists that commit as "patch" now, and given that emitting
a finished transaction as finished multiple times could indeed cause
issues (and use-after-free issues potentially as well), I am inclined
to think that that's indeed the issue here and that the patch fixes
it.
That would mean though that all PK versions starting from and
including 1.2.7 are not vulnerable... But the CVE tells otherwise.
Very odd.

Best,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1064346: Source is missing errors on HTML source files

[Soren Stoutner]

The question is if the long lines in these HTML files are actually indications 
that the HTML files are not the original source.  This usually happens in one 
of two cases.

1.  The files have been minified.
2.  The files were originally created in another format and converted to HTML.

Sometimes HTML files naturally have long lines.  If you look at the 
descriptions of the lintian warnings, they acknowledge that this is an 
imperfect check that will result in some false-positives.  If that is the 
case, the HTML files are the original source, and they have not been minified, 
then you can override these warnings with a description as to why.

On Tuesday, February 20, 2024 9:08:17 AM MST Shriram Ravindranathan wrote:
> Hello mentors,
> 
> I am getting a few lintian "source-is-missing" errors for some HTML 
> files. These HTML files are infact present in the source code but they 
> have too many lines which triggers a 
> "very-long-line-length-in-source-file" lintian tag and that in turn 
> causes the "source-is-missing" error.
> 
> Most of the info I could find in the policy manual and in the forums 
> pertained to binary files that were included in the source, the strategy 
> these resources suggested were
> 1. Repack upstream tar with the source code of these files
> 2. Add the source code to the d/missing-sources directory
> 
> I don't think either of these are viable options in my case. I was 
> wondering whether it would be okay to suppress these errors. Is there 
> any other way to solve this?
> 
> -- 
> Shriram Ravindranathan
> 


-- 
Soren Stoutner
so...@debian.org

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

Bug#1064367: gnome-core: demote gnome-software to Recommends

[Drew Parsons]

Package: gnome-core
Version: 1:44+1
Severity: normal

gnome-core is generally useful for maintaining a Gnome desktop
environment. gnome-software is not.

Some people find gnome-software useful, but it is certainly not core
for a Gnome environment when apt is used for package installation.

On the contrary, gnome-software introduces other problems, including
an unwelcome packagekitd dependency. The two together are currently
spamming syslog (Bug#1064364).

All the problems associated with gnome-software could be alleviated
simply by making gnome-core Recommend: gnome-software, instead of
Depends:.

Bug#1064366: minisat2 FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: minisat2
Version: 1:2.2.1-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

minisat2 fails to cross build from source, because it performs some
build steps using the build architecture compiler while passing host
architecture compiler flags. This happens during dh_auto_install where
nothing should be built anymore. The cause is that the install target
transitively depends on an artifact that is not part of all. Once we
enable that artifact ("sh") in dh_auto_build, minisat2 cross builds
successfully. I'm attaching a patch to debian/rules. Consider to patch
the Makefile instead and add sh as a prerequisite for all, because the
default install target requires it.

Helmut
diff --minimal -Nru minisat2-2.2.1/debian/changelog 
minisat2-2.2.1/debian/changelog
--- minisat2-2.2.1/debian/changelog 2024-02-20 12:23:45.0 +0100
+++ minisat2-2.2.1/debian/changelog 2024-02-20 21:21:06.0 +0100
@@ -1,3 +1,10 @@
+minisat2 (1:2.2.1-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build all required parts via dh_auto_build. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 20 Feb 2024 21:21:06 +0100
+
 minisat2 (1:2.2.1-6) unstable; urgency=low
 
   * Bumped standards version to 4.6.2 (no changes)
diff --minimal -Nru minisat2-2.2.1/debian/rules minisat2-2.2.1/debian/rules
--- minisat2-2.2.1/debian/rules 2024-02-20 12:23:45.0 +0100
+++ minisat2-2.2.1/debian/rules 2024-02-20 21:21:06.0 +0100
@@ -20,6 +20,9 @@
 %:
dh $@ 
 
+override_dh_auto_build:
+   dh_auto_build -- all sh
+
 override_dh_auto_configure:
dh_testdir
$(MAKE) config prefix=/usr

Bug#1064365: src:endless-sky: fails to migrate to testing for too long: FTBFS on i386 and ppc64el and unresolved RC issue

[Paul Gevers]

Source: endless-sky
Version: 0.10.2-6
Severity: serious
Control: close -1 0.10.4-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1061241

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:endless-sky has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build on i386 and ppc64el. It also has an unresolved RC issue: bug 
#1061241.


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 trixie, 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/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=endless-sky



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064364: gnome-software: causes packagekit to spam syslog

[Drew Parsons]

Package: gnome-software
Version: 46~beta-1
Severity: important

gnome-software is causing packagekit to spam the syslog (and resources
generally).  Even if I stop packagekit with
  sudo systemctl stop packagekit
gnome-software causes it to immediately restart.

The only workaround is to mask it with
  sudo systemctl mask packagekit
which sends packagekit startup to /dev/null.  That seems like an
excessive solution. gnome-software should not be triggering it every
second in the first place.

The problem (when not masked) causes packagekit to run every 1-5
seconds. So /var/log/syslog looks like:

2024-02-20T21:32:32.925448+01:00 sandy PackageKit: get-updates transaction 
/218502_dbddaeaa from uid 1000 finished with success after 1307ms
2024-02-20T21:32:37.603603+01:00 sandy PackageKit: get-updates transaction 
/218503_dcaeccca from uid 1000 finished with success after 1358ms
2024-02-20T21:32:39.000560+01:00 sandy PackageKit: get-updates transaction 
/218504_aebabccd from uid 1000 finished with success after 1390ms
2024-02-20T21:32:39.685662+01:00 sandy PackageKit: get-details transaction 
/218505_caabdbae from uid 1000 finished with success after 637ms
2024-02-20T21:32:41.050140+01:00 sandy PackageKit: get-updates transaction 
/218506_dbabbdcb from uid 1000 finished with success after 1357ms
2024-02-20T21:32:45.600123+01:00 sandy PackageKit: get-updates transaction 
/218507_dadbdbbd from uid 1000 finished with success after 1350ms
2024-02-20T21:32:46.988202+01:00 sandy PackageKit: get-updates transaction 
/218508_babbbeab from uid 1000 finished with success after 1381ms
2024-02-20T21:32:47.689595+01:00 sandy PackageKit: get-details transaction 
/218509_dacbeaeb from uid 1000 finished with success after 657ms
2024-02-20T21:32:49.071197+01:00 sandy PackageKit: get-updates transaction 
/218510_eeebadbc from uid 1000 finished with success after 1375ms
2024-02-20T21:32:53.605185+01:00 sandy PackageKit: get-updates transaction 
/218511_accacdcd from uid 1000 finished with success after 1365ms
2024-02-20T21:32:54.978413+01:00 sandy PackageKit: get-updates transaction 
/218512_cbeeeaea from uid 1000 finished with success after 1366ms
2024-02-20T21:32:55.712877+01:00 sandy PackageKit: get-details transaction 
/218513_cdeabbad from uid 1000 finished with success after 668ms
2024-02-20T21:32:57.082777+01:00 sandy PackageKit: get-updates transaction 
/218514_cccabecc from uid 1000 finished with success after 1363ms
2024-02-20T21:33:01.634916+01:00 sandy PackageKit: get-updates transaction 
/218515_bded from uid 1000 finished with success after 1384ms
2024-02-20T21:33:03.024803+01:00 sandy PackageKit: get-updates transaction 
/218516_aecbbddb from uid 1000 finished with success after 1383ms
2024-02-20T21:33:03.731606+01:00 sandy PackageKit: get-details transaction 
/218517_cbcbdcbc from uid 1000 finished with success after 646ms
2024-02-20T21:33:05.140069+01:00 sandy PackageKit: get-updates transaction 
/218518_ecaeedaa from uid 1000 finished with success after 1401ms
2024-02-20T21:33:09.583931+01:00 sandy PackageKit: get-updates transaction 
/218519_bddabbce from uid 1000 finished with success after 1342ms
2024-02-20T21:33:10.956327+01:00 sandy PackageKit: get-updates transaction 
/218520_deeebcca from uid 1000 finished with success after 1365ms
2024-02-20T21:33:11.628647+01:00 sandy PackageKit: get-details transaction 
/218521_baeeaacc from uid 1000 finished with success after 623ms
2024-02-20T21:33:12.990549+01:00 sandy PackageKit: get-updates transaction 
/218522_ebaebdbc from uid 1000 finished with success after 1354ms
2024-02-20T21:33:17.639282+01:00 sandy PackageKit: get-updates transaction 
/218523_ccbcecda from uid 1000 finished with success after 1395ms
2024-02-20T21:33:19.004690+01:00 sandy PackageKit: get-updates transaction 
/218524_aeddacad from uid 1000 finished with success after 1357ms
2024-02-20T21:33:19.740742+01:00 sandy PackageKit: get-details transaction 
/218525_dcdcbbeb from uid 1000 finished with success after 684ms
2024-02-20T21:33:21.09+01:00 sandy PackageKit: get-updates transaction 
/218526_eabcdaad from uid 1000 finished with success after 1296ms
2024-02-20T21:33:25.591749+01:00 sandy PackageKit: get-updates transaction 
/218527_decabccd from uid 1000 finished with success after 1377ms
2024-02-20T21:33:26.766187+01:00 sandy PackageKit: get-updates transaction 
/218528_cacbbeed from uid 1000 finished with success after 1168ms
2024-02-20T21:33:27.405423+01:00 sandy PackageKit: get-details transaction 
/218529_aaaeadbd from uid 1000 finished with success after 601ms
2024-02-20T21:33:28.655457+01:00 sandy PackageKit: get-updates transaction 
/218530_abdceccd from uid 1000 finished with success after 1245ms
2024-02-20T21:33:33.663481+01:00 sandy PackageKit: get-updates transaction 
/218531_dbabddab from uid 1000 finished with success after 1396ms
2024-02-20T21:33:35.060284+01:00 sandy PackageKit: get-updates transaction 
/218532_dadbccaa from uid 1000 finished with success after 1390ms

Bug#1064016: fixed in adwaita-icon-theme 46~beta-2

[Simon McVittie]

On Tue, 20 Feb 2024 at 21:05:55 +0100, Amy Kos wrote:
> latest change in 46~beta-4
>  "Use a more minimal set of aliases as requested by upstream"
> is understandable from Gnome perpective.

I did try to get a more comprehensive set of aliases merged, but
the upstream maintainer refused, and I was concerned that if I pushed
harder, he would have rejected the change entirely (leaving e.g. Firefox,
Chromium, SDL in a similarly bad situation).

The policy we ended up with is that where the CSS/freedesktop.org
cursors had an obvious equivalence with one of the XC_ constants in
, we added aliases for those, but we did not add any
aliases for the hashes of custom cursors, or for other non-standardized
names (some of which might have originated in Qt, but the nature of
non-standardized names is that it's hard to tell where they came from
or who might be using them).

> Nevertheless it will take time until other software catch up.
> For instance in LXQt at least these are missing:
>  progress, help, nwse-resize and nesw-resize

Those are some of the standardized (CSS/freedesktop.org) names, so I
assume you mean that LXQt is looking for legacy/non-standardized names
that should be equivalent to those. What names is it looking for?

> Would it be worthwile to provide the missing symlinks
> from 46~beta-3 in Debian for the time being?

I would prefer not to have too many aliases that have been specifically
rejected upstream: if we do that, it will encourage projects whose
upstream maintainers happen to use Debian/Ubuntu to keep using the old
names, and then be surprised when their code doesn't work as intended
on non-Debian-derived distributions.

If these cursors are particularly high-visibility, we could consider
adding back a small number of aliases, but I'd prefer to have a
bug report against the package that needs them (in this case LXQt)
before we do that. That bug report's steps to reproduce will show us
how high-visibility the other package's use of those cursors is, and
watching to see when those bugs are closed will give us a cutoff point
at which we can drop the legacy aliases.

In particular, I don't want to keep the hash-based aliases as a
downstream divergence unless they're absolutely necessary, because
those are *extremely* opaque. (We can at least guess at the intended
semantics of left_ptr_watch, but what are the intended semantics of
1081e37283d983c07f3ef6bf? Nobody knows, unless someone can dig
out the original X11 bitmap that hashes to that value!)

So perhaps you could open a bug report against LXQt as a starting point?
That would consist of a list of some scenarios in which a wrong cursor
is seen, and ideally some suggestions for the CSS/freedesktop.org name
that it should be using in those scenarios. Some useful references:
https://drafts.csswg.org/css-ui/#cursor
https://developer.mozilla.org/en-US/docs/Web/CSS/cursor
https://www.freedesktop.org/wiki/Specifications/cursor-spec/

Or, if you can identify the lower-level code that is actually selecting
these cursors (perhaps Qt?), a bug report against the library that would
need to be updated to switch to CSS/freedesktop.org names would also
be fine.

All of the packages I've looked at so far (Firefox, Chromium, SDL) seemed
to be using either CSS/freedesktop.org names, or  names
(which now have aliases set up, where available), or a mixture of the two:
they were only using other legacy names as fallbacks, if at all.

smcv

Bug#1062772: apt: apt.conf(5) should document all options

[Wesley Schwengle]

Hi Thorsten,


I would expect apt.conf(5) to document any and all configuration
items one can do to apt*, either directly or by other manpages
referenced from “SEE ALSO”.


The man page of apt.conf shows the following:

EXAMPLES
   /usr/share/doc/apt/examples/configure-index.gz is a 
configuration file showing example values for all possible options.


The file location is incorrect (on Debian sid), this should be 
/usr/share/doc/apt/examples/configure-index. It documents all the 
options you can find.


Cheers,
Wesley

--
Wesley Schwengle
E: wes...@schwengle.net

Bug#1064363: Keep tmux 3.4 out of testing for now

[Romain Francoise]

Package: tmux
Version: 3.4-1
Severity: serious

tmux 3.4 has a few regressions that I would like to have fixed before
the package is allowed to migrate to testing.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1064362: golang-k8s-kube-openapi: FTBFS on riscv64 due to test timeout

[Aurelien Jarno]

Source: golang-k8s-kube-openapi
Version: 0.0~git20231214.ab13479-1
Severity: important
Tags: patch ftbfs upstream fixed-upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear maintainer,

golang-k8s-kube-openapi fails to build from source on riscv64 with a
timeout in on test:

| Running Suite: Integration Test Suite - 
/<>/_build/src/k8s.io/kube-openapi/test/integration
| 

| Random Seed: 1707440586
| 
| Will run 4 of 4 specs
| --
| [BeforeSuite] [FAILED] [39.046 seconds]
| [BeforeSuite] 
| 
/<>/_build/src/k8s.io/kube-openapi/test/integration/integration_suite_test.go:70
| 
|   Timeline >>
|   STEP: building openapi-gen @ 02/09/24 01:03:06.541
|   STEP: processing go idl with openapi-gen @ 02/09/24 01:03:35.566
|   [FAILED] in [BeforeSuite] - 
/<>/_build/src/k8s.io/kube-openapi/test/integration/integration_suite_test.go:101
 @ 02/09/24 01:03:45.586
|   << Timeline
| 
|   [FAILED] Timed out after 10.004s.
|   Expected process to exit.  It did not.
|   In [BeforeSuite] at: 
/<>/_build/src/k8s.io/kube-openapi/test/integration/integration_suite_test.go:101
 @ 02/09/24 01:03:45.586
| --
| 
| Summarizing 1 Failure:
|   [FAIL] [BeforeSuite] 
|   
/<>/_build/src/k8s.io/kube-openapi/test/integration/integration_suite_test.go:101
| 
| Ran 0 of 4 Specs in 39.056 seconds
| FAIL! -- A BeforeSuite node failed so all tests were skipped.
| --- FAIL: TestGenerators (39.06s)
| FAIL
| FAILk8s.io/kube-openapi/test/integration39.125s
| === RUN   TestConvertGolden
| --- PASS: TestConvertGolden (0.15s)
| PASS
| ok  k8s.io/kube-openapi/test/integration/openapiconv0.245s
| FAIL
| dh_auto_test: error: cd _build && go test -vet=off -v -p 4 
k8s.io/kube-openapi/cmd/openapi-gen k8s.io/kube-openapi/cmd/openapi-gen/args 
k8s.io/kube-openapi/cmd/openapi2smd k8s.io/kube-openapi/pkg/aggregator 
k8s.io/kube-openapi/pkg/builder k8s.io/kube-openapi/pkg/builder3 
k8s.io/kube-openapi/pkg/builder3/util k8s.io/kube-openapi/pkg/cached 
k8s.io/kube-openapi/pkg/common k8s.io/kube-openapi/pkg/common/restfuladapter 
k8s.io/kube-openapi/pkg/generators k8s.io/kube-openapi/pkg/generators/rules 
k8s.io/kube-openapi/pkg/handler k8s.io/kube-openapi/pkg/handler3 
k8s.io/kube-openapi/pkg/idl k8s.io/kube-openapi/pkg/internal 
k8s.io/kube-openapi/pkg/internal/third_party/go-json-experiment/json 
k8s.io/kube-openapi/pkg/openapiconv k8s.io/kube-openapi/pkg/schemaconv 
k8s.io/kube-openapi/pkg/schemamutation k8s.io/kube-openapi/pkg/spec3 
k8s.io/kube-openapi/pkg/util k8s.io/kube-openapi/pkg/util/jsontesting 
k8s.io/kube-openapi/pkg/util/proto k8s.io/kube-openapi/pkg/util/proto/testing 
k8s.io/kube-openapi/pkg/util/proto/validation k8s.io/kube-openapi/pkg/util/sets 
k8s.io/kube-openapi/pkg/validation/errors 
k8s.io/kube-openapi/pkg/validation/spec 
k8s.io/kube-openapi/pkg/validation/strfmt 
k8s.io/kube-openapi/pkg/validation/strfmt/bson 
k8s.io/kube-openapi/pkg/validation/validate 
k8s.io/kube-openapi/test/integration 
k8s.io/kube-openapi/test/integration/builder 
k8s.io/kube-openapi/test/integration/builder3 
k8s.io/kube-openapi/test/integration/openapiconv 
k8s.io/kube-openapi/test/integration/pkg/generated 
k8s.io/kube-openapi/test/integration/testutil returned exit code 1
| make: *** [debian/rules:4: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

The full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=golang-k8s-kube-openapi=riscv64=0.0%7Egit20231214.ab13479-1=1707440925=0

I submitted a patch upstream which has now been merged:
https://github.com/kubernetes/kube-openapi/commit/b4a5507e9c90356cbf47fb4ad34862ded7919b1e

Would it be possible to include that fix in the next upload?

Thanks
Aurelien

Bug#1064016: fixed in adwaita-icon-theme 46~beta-2

[Amy Kos]

Hi,

latest change in 46~beta-4
 "Use a more minimal set of aliases as requested by upstream"
is understandable from Gnome perpective.

Nevertheless it will take time until other software catch up.
For instance in LXQt at least these are missing:
 progress, help, nwse-resize and nesw-resize

Would it be worthwile to provide the missing symlinks
from 46~beta-3 in Debian for the time being?
-
81600681408080010102 -> ns-resize
028006030e0e7ebffc7f7070c0600140 -> ew-resize
08e8e1c95fe2fc01f976f1e063a24ccd -> progress
1081e37283d983c07f3ef6bf -> copy
14fef782d02440884392942c11205230 -> ew-resize
2870a09082c103050810ffde0204 -> ns-resize
3085a0e285430894940527032f8b26df -> alias
3ecb610c1bf2410f44200f48c40d3599 -> progress
4498f0e0c1937ffe01fd06f973665830 -> move
5c6cd98b3f3ebcb1f9c7f1c204630408 -> help
6407b0e94181790501fd1e167b474872 -> copy
640fb0e74195791501fd1ed57b41487f -> alias
9081237383d90e509aa00f00170e968f -> move
9d800788f1b08800ae810202380a0822 -> pointer
c7088f0f3e6c8088236ef8e1e3e7 -> nwse-resize
d9ce0ab605698f320427677b458ad60b -> help
dnd-copy -> copy
dnd-link -> alias
dnd-no-drop -> no-drop
e29285e634086352946a0e7090d73106 -> pointer
fcf1c3c7cd4491d801f1e1c78f10 -> nesw-resize
h_double_arrow -> ew-resize
left_ptr_help -> help
left_ptr_watch -> progress
link -> alias
openhand -> grab
size_all -> move
size_bdiag -> nesw-resize
size_fdiag -> nwse-resize
size_hor -> ew-resize
size_ver -> ns-resize
v_double_arrow -> ns-resize
-

Cheers,
Amy

Bug#1062001: RFS: trader/7.20-1 -- simple game of interstellar trading

[Tobias Frost]

Control: tags -1 moreinfo

Hi,

some review:

d/control: 
- Please remove all versions from the versioned build depends
  that are fulfiled already since oldstable, e.g gettext and automake.
- Your VCS-Git link git:// is not using an encrypted link, but the site
  supports https://. Please use https.

d/copyright:
- the directory lib/ has files which are not documented in d/copyright;
  (They have a different license and copyright)
- same for the m4 macros

embedded code copies:
- gnulib is packaged for Debian, any reason why you don't use the packaged 
version?
- there are m4 macros from autoconf-archive. Please check if you can use
  the ones from the package autoconf-archive.

Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata

d/changelog
- d/changelog's purpose is to document changed to the packageing,
  generaly not to document upstream changes, so I'd cut that down
  to:

  trader (7.20-1) unstable; urgency=low
 
* New upstream release.
* Updated to Debian Policy 4.6.2 (no changes).

- lintian findings:
W: trader: groff-message troff::133: warning: macro 'mR' not 
defined [usr/share/man/man6/trader.6.gz:1]
I: trader source: public-upstream-key-not-minimal has 16 extra signature(s) for 
keyid 0D254111C4EE569B [debian/upstream/signing-key.asc]
I: trader source: vcs-field-uses-insecure-uri Git 
git://git.zap.org.au/data/git/trader.git -b with-debian
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-hpux.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-irix.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-osf.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-solaris.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-zos.h]

Cheers,
-- 
tobi




On Wed, Jan 31, 2024 at 10:59:26AM +1100, John Zaitseff wrote:
> Hi, Bastian et al.,
> 
> > > > 7.19-1 was never uploaded to Debian, so please remove it from
> > > > the changelog.
> > >
> > > Would this still be the case even though I _did_ release it on
> > > The ZAP Group Australia's repository?  If so, how would I
> > > preserve the changes listed for v7.19 -- should I just add them
> > > as part of the 7.20-1 changelog entry?
> >
> > Yes, you should do that. Alternatively, you can upload 7.19-1
> > before uploading 7.20-1.
> 
> I have removed the changelog entry for 7.19-1; the entry for 7.20-1
> now reads:
> 
>  trader (7.20-1) unstable; urgency=low
> 
>* New upstream release: changed documentation (history of the game),
>  updated Swedish, Norwegian Bokmål, French, German, Serbian, Esperanto,
>  Romanian, Polish and Ukrainian translations.
>* Incorporates changes made to previous upstream release (not uploaded
>  to Debian): new Polish, Romanian and Ukrainian translations, renamed
>  AppStream metainfo and desktop files.
>* Require at least Gettext 0.21 and Automake 1.16 for building.
>* Updated to Debian Policy 4.6.2 (no changes).
> 
> Could you (or someone) now sponsor the package?  The original link
> now points to the updated package:
> 
>   dget -x 
> https://ftp.zap.org.au/pub/debian/dists/zapgroup-sid/main/source/trader_7.20-1.dsc
> 
> Yours truly,
> 
> John Zaitseff
> 
> -- 
> John Zaitseff   ╭───╮   Email: j.zaits...@zap.org.au
> The ZAP Group   │ Z │   GnuPG: 0x0D254111C4EE569B
> Australia Inc.  ╰───╯   https://www.zap.org.au/~john/
> 

Bug#1064361: libreadline8t64: file loss due to concurrent /usr-move and package rename (DEP17 P1)

[Helmut Grohne]

Package: libreadline8t64
Version: 8.2-3.1~exp1
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p1
Control: affects -1 + libreadline8
X-Debbugs-Cc: vor...@debian.org, mwhud...@debian.org, bug-readl...@gnu.org

Hi,

readline upstream: Please skip the next paragraph.

the time64 transition causes a DEP17 P1 problem for the actual shared
libraries contained in libreadline8t64. These were located below /lib in
libreadline8 in bookworm and thus can be lost in an upgrade. I'm
attaching a patch to add protective diversions for this situation. Since
this library is rather close to essential, I'm using the conservative
method of keeping the diversions beyond postinst. In forky, we can
remove the diversions and in forky+1, we can remove the maintainer
scripts introduced here.

Given the proximity of readline to the base system (e.g. fdisk and
python3 depend on it), I also looked into alternatives.
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libreadline-dev/base_to_lfs/compat_report.html
indicates that we are not faced with LFS ABI changes, but
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libreadline-dev/lfs_to_time_t/compat_report.html
indicates that we are faced with history_get_time changing its return
type from 32bit to 64bit. Providing ABI duality here is even easier than
in the case of libselinux and upstream is vaguely active (last commit 3
weeks ago). Also note that this function already handles range errors
and returns 0 in that case. This behaviour could naturally be extended
for 2038. I think providing duality here would reduce the risk of failed
upgrades breaking user systems.

Context:
https://sources.debian.org/src/readline/8.2-3/history.c/?hl=241#L241

Sketch:

// .h
#if time64 changes ABI
typedef time_t time64_t;
typedef int32_t time32_t;
time64_t history_get_time64 (HIST_ENTRY *hist);
time32_t history_get_time (HIST_ENTRY *hist);
#define history_get_time history_get_time64
#else
time_t history_get_time (HIST_ENTRY *hist);
#endif

// .c
time_t
// The earlier #define may change the function name
history_get_time (HIST_ENTRY *hist)
{
  // original function unchanged
}

#if time64 changes ABI
#undef history_get_time
time32_t
history_get_time (HIST_ENTRY *hist)
{
  time64_t ret64 = history_get_time(hist);
  time32_t ret32 = ret64;
  if ((time64_t)ret32 != ret64)
return (time32_t)0;
  return ret32;
}
#endif

I've directly Cced readline upstream to see whether they're interested.

Helmut
diff --minimal -Nru readline-8.2/debian/changelog readline-8.2/debian/changelog
--- readline-8.2/debian/changelog   2024-02-19 23:47:01.0 +0100
+++ readline-8.2/debian/changelog   2024-02-20 09:18:09.0 +0100
@@ -1,3 +1,11 @@
+readline (8.2-3.1~exp1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * DEP17 P1: Mitigate file loss due to package rename with concurrent
+aliasing change. Closes: #-1.
+
+ -- Helmut Grohne   Tue, 20 Feb 2024 09:18:09 +0100
+
 readline (8.2-3.1~exp1) experimental; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru readline-8.2/debian/libreadline8t64.postrm.in 
readline-8.2/debian/libreadline8t64.postrm.in
--- readline-8.2/debian/libreadline8t64.postrm.in   1970-01-01 
01:00:00.0 +0100
+++ readline-8.2/debian/libreadline8t64.postrm.in   2024-02-20 
09:17:54.0 +0100
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+if test "$1" = remove; then
+   # DEP17 P1 mitigation. Remove these diversions via postinst once trixie 
is released.
+   for lib in libhistory.so.8 libhistory.so.8.2 libreadline.so.8 
libreadline.so.8.2; do
+   dpkg-divert --package libreadline8t64 --no-rename --divert 
"/lib/#DEB_HOST_MULTIARCH#/$lib.usr-is-merged" --remove 
"/lib/#DEB_HOST_MULTIARCH#/$lib"
+   done
+fi
+
+#DEBHELPER#
+
+exit 0
diff --minimal -Nru readline-8.2/debian/libreadline8t64.preinst.in 
readline-8.2/debian/libreadline8t64.preinst.in
--- readline-8.2/debian/libreadline8t64.preinst.in  1970-01-01 
01:00:00.0 +0100
+++ readline-8.2/debian/libreadline8t64.preinst.in  2024-02-20 
09:18:03.0 +0100
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+if test "$1" = install -o "$1" = upgrade; then
+   # DEP17 P1 mitigation. Remove these diversions via postinst once trixie 
is released.
+   for lib in libhistory.so.8 libhistory.so.8.2 libreadline.so.8 
libreadline.so.8.2; do
+   dpkg-divert --package libreadline8t64 --no-rename --divert 
"/lib/#DEB_HOST_MULTIARCH#/$lib.usr-is-merged" --add 
"/lib/#DEB_HOST_MULTIARCH#/$lib"
+   done
+fi
+
+#DEBHELPER#
+
+exit 0
diff --minimal -Nru readline-8.2/debian/rules readline-8.2/debian/rules
--- readline-8.2/debian/rules   2024-02-19 23:47:01.0 +0100
+++ readline-8.2/debian/rules   2024-02-20 09:18:09.0 +0100
@@ -154,6 +154,9 @@
 
touch configure-stamp
 
+debian/%:debian/%.in
+   sed 's/#DEB_HOST_MULTIARCH#/$(DEB_HOST_MULTIARCH)/g' $< > $@

Bug#1064360: volume-key FTCBFS: uses the build architecture python

[Helmut Grohne]

Source: volume-key
Version: 0.3.12-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs

volume-key cannot be cross built from source, because it depends on
python3-dev. This refers to a host architecture Python installation,
which usually is not what we want. Usually, one uses a build
architecture development tools and host architecture libraries. Once
changing them, the build picks up build architecture compiler flags with
a host architecture compiler. This is due to configure.ac searching for
python3-config using AC_PATH_PROG and thus getting the build
architecture one. Using AC_PATH_TOOL fixes the build. I'm attaching a
patch for your convenience.

Helmut
diff --minimal -Nru volume-key-0.3.12/debian/changelog 
volume-key-0.3.12/debian/changelog
--- volume-key-0.3.12/debian/changelog  2022-09-08 01:54:16.0 +0200
+++ volume-key-0.3.12/debian/changelog  2024-02-20 09:36:48.0 +0100
@@ -1,3 +1,12 @@
+volume-key (0.3.12-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Multiarchify python-dev dependency.
++ cross.patch: Use AC_PATH_TOOL to locate python3-config.
+
+ -- Helmut Grohne   Tue, 20 Feb 2024 09:36:48 +0100
+
 volume-key (0.3.12-5) unstable; urgency=medium
 
   * Use dh-sequence-python3 Build-Depends to enable the python3 addon
diff --minimal -Nru volume-key-0.3.12/debian/control 
volume-key-0.3.12/debian/control
--- volume-key-0.3.12/debian/control2022-09-08 01:54:16.0 +0200
+++ volume-key-0.3.12/debian/control2024-02-20 09:36:46.0 +0100
@@ -12,7 +12,8 @@
libblkid-dev,
swig,
libnss3-tools,
-   python3-dev,
+   libpython3-dev,
+   python3-dev:any,
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/utopia-team/volume-key
diff --minimal -Nru volume-key-0.3.12/debian/patches/cross.patch 
volume-key-0.3.12/debian/patches/cross.patch
--- volume-key-0.3.12/debian/patches/cross.patch1970-01-01 
01:00:00.0 +0100
+++ volume-key-0.3.12/debian/patches/cross.patch2024-02-20 
09:36:48.0 +0100
@@ -0,0 +1,20 @@
+--- volume-key-0.3.12.orig/configure.ac
 volume-key-0.3.12/configure.ac
+@@ -62,7 +62,7 @@
+ ;;
+ esac
+ if test "x$__vk_tmp" = x; then
+-AC_PATH_PROG([PYTHON_CONFIG], [python2-config python-config], [no])
++AC_PATH_TOOL([PYTHON_CONFIG], [python2-config python-config], [no])
+ if test "x${PYTHON_CONFIG}" = xno; then
+ __vk_tmp=python2-config
+ fi
+@@ -132,7 +132,7 @@
+ ;;
+ esac
+ if test "x$__vk_tmp" = x; then
+-AC_PATH_PROG([PYTHON3_CONFIG], [python3-config], [no])
++AC_PATH_TOOL([PYTHON3_CONFIG], [python3-config], [no])
+ if test "x${PYTHON3_CONFIG}" = xno; then
+ __vk_tmp=python3-config
+ fi
diff --minimal -Nru volume-key-0.3.12/debian/patches/series 
volume-key-0.3.12/debian/patches/series
--- volume-key-0.3.12/debian/patches/series 2022-09-08 01:54:16.0 
+0200
+++ volume-key-0.3.12/debian/patches/series 2024-02-20 09:36:48.0 
+0100
@@ -1,2 +1,3 @@
 Revert-Switch-to-gpg2.patch
 Fix-FTBFS-with-Python-3.8.patch
+cross.patch

Bug#1064359: pd-flext FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: pd-flext
Version: 0.6.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pd-flext fails to cross build from source, because it strips with the
build architecture strip. Beyond breaking cross compilation, doing so
breaks DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym
packages. I recommend letting dh_strip handle the stripping and am
attaching a patch for your convenience. After applying it, pd-flext can
be cross built again.

Helmut
diff --minimal -Nru pd-flext-0.6.3/debian/changelog 
pd-flext-0.6.3/debian/changelog
--- pd-flext-0.6.3/debian/changelog 2024-01-30 23:24:55.0 +0100
+++ pd-flext-0.6.3/debian/changelog 2024-02-20 20:35:31.0 +0100
@@ -1,3 +1,10 @@
+pd-flext (0.6.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 20 Feb 2024 20:35:31 +0100
+
 pd-flext (0.6.3-1) unstable; urgency=medium
 
   * New upstream version 0.6.3
diff --minimal -Nru pd-flext-0.6.3/debian/rules pd-flext-0.6.3/debian/rules
--- pd-flext-0.6.3/debian/rules 2024-01-30 23:24:55.0 +0100
+++ pd-flext-0.6.3/debian/rules 2024-02-20 20:35:31.0 +0100
@@ -49,7 +49,7 @@
 
 override_dh_auto_install: $(patsubst %,install_%,$(FLAVORS))
 install_%:
-   dh_auto_install --builddir $(builddir)$*
+   STRIPPROG=true dh_auto_install --builddir $(builddir)$*
 
 DEB_COPYRIGHT_CHECK_IGNORE_REGEX = \
debian/.*

Bug#1062344: htslib: diff for 64-bit time_t transition, for htslib 1.19

[Étienne Mollier]

Hi Graham,

I migrated htslib 1.19 to unstable in the past weekend (and in
turn it migrated to testing this morning).  The experimental
distribution being now available, I am preparing an upload with
your changes for the migration to the 64-bit time_t.  You will
find the new debdiff in attachment; normally there should be no
surprises here, but just in case.

In hope this helps,
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-on air: Crippled Black Phoenix - Bonefire
diff -Nru htslib-1.19+ds/debian/changelog htslib-1.19+ds/debian/changelog
--- htslib-1.19+ds/debian/changelog 2024-02-17 11:42:52.0 +0100
+++ htslib-1.19+ds/debian/changelog 2024-02-20 19:55:09.0 +0100
@@ -1,3 +1,13 @@
+htslib (1.19+ds-1+exp1) experimental; urgency=medium
+
+  * Rename libraries for 64-bit time_t transition.
+This change was initially proposed as NMU, but it didn't make it to
+experimental due to a conflicting version already present at the time
+of the upload.  See also #1062344.
+Thanks to Graham Inggs for the initial version and work on 64-bit time_t
+
+ -- Étienne Mollier   Tue, 20 Feb 2024 19:55:09 +0100
+
 htslib (1.19+ds-1) unstable; urgency=medium
 
   * Migrate htslib 1.19 from experimental to unstable.
diff -Nru htslib-1.19+ds/debian/control htslib-1.19+ds/debian/control
--- htslib-1.19+ds/debian/control   2023-12-15 17:43:46.0 +0100
+++ htslib-1.19+ds/debian/control   2024-02-20 19:55:09.0 +0100
@@ -21,18 +21,20 @@
 Homepage: https://github.com/samtools/htslib
 Rules-Requires-Root: no
 
-Package: libhts3
+Package: libhts3t64
+Provides: ${t64:Provides}
 Architecture: any
 Multi-Arch: same
 Section: libs
 Depends: ${misc:Depends},
  ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
-Breaks: libtabixpp (<< 1.0.0-5~),
+Breaks: libhts3 (<< ${source:Version}),
+libtabixpp (<< 1.0.0-5~),
 libhts-dev (<< 1.13~),
 samtools (<< 1.17~),
 ivar (<< 1.3.1~)
-Replaces: libhts-dev (<< 1.13~)
+Replaces: libhts3, libhts-dev (<< 1.13~)
 Description: C library for high-throughput sequencing data formats
  HTSlib is an implementation of a unified C library for accessing common file
  formats, such as SAM (Sequence Alignment/Map), CRAM and VCF (Variant Call
@@ -48,7 +50,7 @@
 Architecture: any
 Multi-Arch: same
 Section: libdevel
-Depends: libhts3 (= ${binary:Version}),
+Depends: libhts3t64 (= ${binary:Version}),
  libcurl4-gnutls-dev,
  libdeflate-dev,
  liblzma-dev,
diff -Nru htslib-1.19+ds/debian/libhts3.install 
htslib-1.19+ds/debian/libhts3.install
--- htslib-1.19+ds/debian/libhts3.install   2022-10-19 16:55:31.0 
+0200
+++ htslib-1.19+ds/debian/libhts3.install   1970-01-01 01:00:00.0 
+0100
@@ -1,3 +0,0 @@
-usr/lib/${DEB_HOST_MULTIARCH}/libhts.so.*  usr/lib/${DEB_HOST_MULTIARCH}
-usr/lib/${DEB_HOST_MULTIARCH}/htslib   usr/lib/${DEB_HOST_MULTIARCH}
-usr/share/man/man5/*   usr/share/man/man5
diff -Nru htslib-1.19+ds/debian/libhts3.manpages 
htslib-1.19+ds/debian/libhts3.manpages
--- htslib-1.19+ds/debian/libhts3.manpages  2022-07-03 09:14:15.0 
+0200
+++ htslib-1.19+ds/debian/libhts3.manpages  1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-htslib-s3-plugin.7
diff -Nru htslib-1.19+ds/debian/libhts3.symbols 
htslib-1.19+ds/debian/libhts3.symbols
--- htslib-1.19+ds/debian/libhts3.symbols   2023-12-15 22:15:41.0 
+0100
+++ htslib-1.19+ds/debian/libhts3.symbols   1970-01-01 01:00:00.0 
+0100
@@ -1,929 +0,0 @@
-libhts.so.3 libhts3 #MINVER#
-* Build-Depends-Package: libhts-dev
- HTSLIB_1.0@HTSLIB_1.0 1.17
- HTSLIB_1.10@HTSLIB_1.10 1.17
- HTSLIB_1.11@HTSLIB_1.11 1.17
- HTSLIB_1.12@HTSLIB_1.12 1.17
- HTSLIB_1.13@HTSLIB_1.13 1.17
- HTSLIB_1.14@HTSLIB_1.14 1.17
- HTSLIB_1.15@HTSLIB_1.15 1.17
- HTSLIB_1.16@HTSLIB_1.16 1.17
- HTSLIB_1.17@HTSLIB_1.17 1.17
- HTSLIB_1.18@HTSLIB_1.18 1.18
- HTSLIB_1.1@HTSLIB_1.1 1.17
- HTSLIB_1.2.1@HTSLIB_1.2.1 1.17
- HTSLIB_1.3@HTSLIB_1.3 1.17
- HTSLIB_1.4@HTSLIB_1.4 1.17
- HTSLIB_1.5@HTSLIB_1.5 1.17
- HTSLIB_1.6@HTSLIB_1.6 1.17
- HTSLIB_1.7@HTSLIB_1.7 1.17
- HTSLIB_1.9@HTSLIB_1.9 1.17
- bam_aux2A@HTSLIB_1.0 1.17
- bam_aux2Z@HTSLIB_1.0 1.17
- bam_aux2f@HTSLIB_1.0 1.17
- bam_aux2i@HTSLIB_1.0 1.17
- bam_auxB2f@HTSLIB_1.4 1.17
- bam_auxB2i@HTSLIB_1.4 1.17
- bam_auxB_len@HTSLIB_1.4 1.17
- bam_aux_append@HTSLIB_1.0 1.17
- bam_aux_del@HTSLIB_1.0 1.17
- bam_aux_first@HTSLIB_1.17 1.17
- bam_aux_get@HTSLIB_1.0 1.17
- bam_aux_next@HTSLIB_1.17 1.17
- bam_aux_remove@HTSLIB_1.17 1.17
- bam_aux_update_array@HTSLIB_1.9 1.17
- bam_aux_update_float@HTSLIB_1.9 1.17
- bam_aux_update_int@HTSLIB_1.9 1.17
- bam_aux_update_str@HTSLIB_1.4 1.17
- bam_cigar2qlen@HTSLIB_1.0 1.17
- bam_cigar2rlen@HTSLIB_1.0 1.17
- bam_cigar_table@HTSLIB_1.10 1.17
- bam_copy1@HTSLIB_1.0 1.17
- bam_destroy1@HTSLIB_1.0 

Bug#1060435: sbuild-qemu-create shows error because "zerofree" not installed

[Christian Kastner]

Hi Carles,

On 2024-01-11 12:01, Carles Pina i Estany wrote:
> It ended with:
> Exec: ['sh', '-ec', 'export AUTOPKGTEST_BUILD_QEMU=1; 
> /usr/share/sbuild/sbuild-qemu-create-modscript "$ROOT"']
> Exec: ['zerofree', '-v', '/dev/mapper/loop0p1']
> ERROR: [Errno 2] No such file or directory: 'zerofree'
> ERROR: FileNotFoundError(2, 'No such file or directory')
> Exec: ['kpartx', '-dsv', 
> '/srv/sbuild/qemu/unstable-autopkgtest-amd64.img.raw']
> Exec: ['losetup', '--json', '-l', '/dev/loop0']
> All went fine.
> 
> Installing "zerofree" does not show the error.
> 
> I expected "zerofree" to be in Depends or Recommends.

I'm not entirely sure how to best address this bug, as it's not a bug in
sbuild-qemu, but in its dependency vmdb2, and has recently been fixed
there (#1021341).

I supposed it can't hurt to add the dependency it to sbuild-qemu, though.

Best,
Christian

Bug#1058712: ITP: sddm-conf -- Graphical editor for SDDM

[Aaron Rainbolt]

I have prepared the packaging for Debian, porting it from the Ubuntu 
packaging created originally by Simon Quigley which I further enhanced. 
The Git repository is at https://salsa.debian.org/ArrayBolt3/sddm-conf.


CC'ing Simon for review.

--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub:https://github.com/ArrayBolt3

Bug#1064358: network-manager-l2tp: cannot connect with mschapv2 if mppe is required

[Rémi Letot]

Package: network-manager-l2tp
Version: 1.20.12-1
Severity: normal
X-Debbugs-Cc: hob...@poukram.net

Dear Maintainer,

since upgrading to 1.20.12-1, I cannot connect to my ipsec/l2tp vpn anymore. 

I tried many things, but the only thing that works is disabling mppe, 
or downgrading to 1.20.10-1

Here are the debug log for 1.20.12-1:

fév 20 20:04:02 sphax pppd[88301]: CHAP authentication succeeded
fév 20 20:04:02 sphax pppd[88301]: nm-l2tp[87948]   [helper-88301] 
phasechange: status 8 / phase 'network'
fév 20 20:04:02 sphax pppd[88301]: sent [CCP ConfReq id=0x1 ]
fév 20 20:04:02 sphax pppd[88301]: rcvd [IPCP ConfReq id=0x1 ]
fév 20 20:04:02 sphax pppd[88301]: sent [IPCP TermAck id=0x1]
fév 20 20:04:02 sphax pppd[88301]: rcvd [proto=0x8281] 01 01 00 04
fév 20 20:04:02 sphax pppd[88301]: Unsupported protocol 'MPLSCP' (0x8281) 
received
fév 20 20:04:02 sphax pppd[88301]: sent [LCP ProtRej id=0x3 82 81 01 01 00 04]
fév 20 20:04:02 sphax pppd[88301]: rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0a 
12 06 01 00 00 60]
fév 20 20:04:02 sphax pppd[88301]: Protocol-Reject for 'Compression Control 
Protocol' (0x80fd) received
fév 20 20:04:02 sphax pppd[88301]: MPPE required but peer negotiation failed
fév 20 20:04:02 sphax pppd[88301]: nm-l2tp[87948]   [helper-88301] 
phasechange: status 10 / phase 'terminate'
fév 20 20:04:02 sphax pppd[88301]: nm-l2tp[87948]   [helper-88301] 
phasechange: status 5 / phase 'establish'
fév 20 20:04:02 sphax pppd[88301]: PPPoL2TP options: debugmask 0
fév 20 20:04:02 sphax pppd[88301]: sent [LCP TermReq id=0x4 "MPPE required but 
peer negotiation failed"]
fév 20 20:04:02 sphax pppd[88301]: rcvd [LCP TermAck id=0x4]
fév 20 20:04:02 sphax pppd[88301]: nm-l2tp[87948]   [helper-88301] 
phasechange: status 11 / phase 'disconnect'
fév 20 20:04:02 sphax pppd[88301]: Connection terminated.


And here is the log with 1.20.10-1:

fév 20 20:02:00 sphax pppd[87014]: CHAP authentication succeeded
fév 20 20:02:00 sphax pppd[87014]: nm-l2tp[86623]   [helper-87014] 
phasechange: status 8 / phase 'network'
fév 20 20:02:00 sphax pppd[87014]: sent [IPCP ConfReq id=0x1 ]
fév 20 20:02:00 sphax pppd[87014]: sent [IPV6CP ConfReq id=0x1 ]
fév 20 20:02:00 sphax pppd[87014]: rcvd [IPCP ConfReq id=0x1 ]
fév 20 20:02:00 sphax pppd[87014]: sent [IPCP ConfAck id=0x1 ]
fév 20 20:02:00 sphax pppd[87014]: rcvd [proto=0x8281] 01 01 00 04
fév 20 20:02:00 sphax pppd[87014]: Unsupported protocol 'MPLSCP' (0x8281) 
received
fév 20 20:02:00 sphax pppd[87014]: sent [LCP ProtRej id=0x3 82 81 01 01 00 04]
fév 20 20:02:00 sphax pppd[87014]: rcvd [IPCP ConfNak id=0x1 ]
fév 20 20:02:00 sphax pppd[87014]: sent [IPCP ConfReq id=0x2 ]
fév 20 20:02:00 sphax pppd[87014]: rcvd [LCP ProtRej id=0x2 80 57 01 01 00 0e 
01 0a c0 9b 5a 53 5f c8 54 ac]
fév 20 20:02:00 sphax pppd[87014]: Protocol-Reject for 'IPv6 Control Protocol' 
(0x8057) received
fév 20 20:02:00 sphax pppd[87014]: rcvd [IPCP ConfAck id=0x2 ]

I still have the «Unsupported protocol», but then the connection carries on and 
works. 

Don't hesitate to ask for more information, and thanks for your work,

-- 
Rémi


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

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager-l2tp depends on:
ii  libc62.37-15
ii  libglib2.0-0 2.78.4-1
ii  libnm0   1.44.2-7
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.96.1-1
ii  libreswan4.12-1
ii  libssl3  3.1.5-1
ii  network-manager  1.44.2-7
ii  ppp  2.4.9-1+1.1+b1
ii  xl2tpd   1.3.18-1

network-manager-l2tp recommends no packages.

network-manager-l2tp suggests no packages.

-- no debconf information

Bug#1058890: troubleshooting

[Dr . André Desgualdo Pereira]

I changed just the disk of the notebook and installed Debian 12 on it, without 
any encryption and suspend works fine on kernel 6.1.0-18. 
Which makes me conclude that something is wrong with some patch of that Debian 
kernel, not allowing the disk to be decrypted with sedutil after waking up. I 
don't think the problem is on mainline Linux kernel because it is reported to 
work at least up to kernel 6.6.7-arch1-1 ( 
https://github.com/Drive-Trust-Alliance/sedutil/issues/90#issuecomment-1952402111
 )

Bug#1064357: flask-socketio: autopkgtest regression with newer flask

[Gianfranco Costamagna]

Source: flask-socketio
Version: 5.3.2-1
Severity: serious


Hello, looks like autopkgtests are now failing due to newer flask

(taking the autopkgtest log from Ubuntu, same happens on Debian ci)
444s (Reading database ... 70452 files and directories currently installed.)
444s Removing autopkgtest-satdep (0) ...
445s autopkgtest [10:03:29]: test verify.sh: [---
445s E.E
445s ==
445s ERROR: test_managed_session (__main__.TestSocketIO.test_managed_session)
445s --
445s Traceback (most recent call last):
445s   File 
"/tmp/autopkgtest.ASzlXQ/build.Le4/src/debian/tests/test_socketio.py", line 
485, in test_managed_session
445s client = socketio.test_client(app, flask_test_client=flask_client,
445s  ^
445s   File "/usr/lib/python3/dist-packages/flask_socketio/__init__.py", line 
784, in test_client
445s return SocketIOTestClient(app, self, namespace=namespace,
445s^^
445s   File "/usr/lib/python3/dist-packages/flask_socketio/test_client.py", 
line 80, in __init__
445s self.connect(namespace=namespace, query_string=query_string,
445s   File "/usr/lib/python3/dist-packages/flask_socketio/test_client.py", 
line 117, in connect
445s self.flask_test_client.cookie_jar.inject_wsgi(environ)
445s ^
445s AttributeError: 'FlaskClient' object has no attribute 'cookie_jar'
445s
445s ==
445s ERROR: test_unmanaged_session 
(__main__.TestSocketIO.test_unmanaged_session)
445s --
445s Traceback (most recent call last):
445s   File 
"/tmp/autopkgtest.ASzlXQ/build.Le4/src/debian/tests/test_socketio.py", line 
505, in test_unmanaged_session
445s client = socketio.test_client(app, flask_test_client=flask_client,
445s  ^
445s   File "/usr/lib/python3/dist-packages/flask_socketio/__init__.py", line 
784, in test_client
445s return SocketIOTestClient(app, self, namespace=namespace,
445s^^
445s   File "/usr/lib/python3/dist-packages/flask_socketio/test_client.py", 
line 80, in __init__
445s self.connect(namespace=namespace, query_string=query_string,
445s   File "/usr/lib/python3/dist-packages/flask_socketio/test_client.py", 
line 117, in connect
445s self.flask_test_client.cookie_jar.inject_wsgi(environ)
445s ^
445s AttributeError: 'FlaskClient' object has no attribute 'cookie_jar'
445s
445s --
445s Ran 39 tests in 0.049s
445s
445s FAILED (errors=2)
445s autopkgtest [10:03:29]: test verify.sh: ---]
445s autopkgtest [10:03:29]: test verify.sh:  - - - - - - - - - - results - - - 
- - - - - - -
445s verify.shFAIL non-zero exit status 1
446s autopkgtest [10:03:30]:  summary
446s verify.shFAIL non-zero exit status 1
456s Creating nova instance 
adt-noble-amd64-flask-socketio-20240213-095602-juju-7f2275-prod-proposed-migration-environment-3
 from image adt/ubuntu-noble-amd64-server-20240213.img (UUID 
25679943-9d0a-4f95-9d90-759bbb713965)...

This commit might be the fix
https://github.com/miguelgrinberg/flask-socketio/commit/70203246bcbc23715350ca5505527b31bf0693c1


G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059186: sane-backends: installs saned.service mask into /lib

[Michael Biebl]

Control: tags -1 + patch

On Thu, 21 Dec 2023 01:06:01 +0100 Chris Hofstaedtler  
wrote:

Source: sane-backends
Version: 1.2.1-7
User: helm...@debian.org
Usertags: dep17m2

Hi!

sane-backends currently installs this symlink:
  lib/systemd/system/saned.service -> /dev/null

For the ongoing Debian UsrMerge effort [1], /lib should become empty,
and instead /usr/lib should be used.
To find the correct location of saned.service, you can ask
  `pkg-config --variable systemdsystemunitdir systemd`


Please find attached a build-tested patch.
Hard-coding the directory is fine, as long as you don't upload the 
package to stable(-backports). If you plan to do that, please revert the 
patch for the stable upload.


Regards,
Michael

diff -Nru sane-backends-1.2.1/debian/changelog 
sane-backends-1.2.1/debian/changelog
--- sane-backends-1.2.1/debian/changelog2023-12-17 13:05:00.0 
+0100
+++ sane-backends-1.2.1/debian/changelog2024-02-20 19:22:16.0 
+0100
@@ -1,3 +1,10 @@
+sane-backends (1.2.1-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install saned.service mask symlink into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Tue, 20 Feb 2024 19:22:16 +0100
+
 sane-backends (1.2.1-7) unstable; urgency=medium
 
   * debian/rules:
diff -Nru sane-backends-1.2.1/debian/sane-utils.links 
sane-backends-1.2.1/debian/sane-utils.links
--- sane-backends-1.2.1/debian/sane-utils.links 2022-02-24 07:34:54.0 
+0100
+++ sane-backends-1.2.1/debian/sane-utils.links 2024-02-20 19:21:27.0 
+0100
@@ -1 +1 @@
-/dev/null  /lib/systemd/system/saned.service
+/dev/null  /usr/lib/systemd/system/saned.service


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064356: vpnc: install systemd unit into /usr

[Michael Biebl]

Source: vpnc
Version: 0.5.3+git20220927-1
Severity: normal
Tags: patch trixie sid
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. vpnc installs files into /lib; these should be moved into
the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead or defer the placement of the
unit files to systemd.pc.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru vpnc-0.5.3+git20220927/debian/changelog 
vpnc-0.5.3+git20220927/debian/changelog
--- vpnc-0.5.3+git20220927/debian/changelog 2022-12-27 20:24:45.0 
+0100
+++ vpnc-0.5.3+git20220927/debian/changelog 2024-02-20 19:13:59.0 
+0100
@@ -1,3 +1,10 @@
+vpnc (0.5.3+git20220927-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd unit into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Tue, 20 Feb 2024 19:13:59 +0100
+
 vpnc (0.5.3+git20220927-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru vpnc-0.5.3+git20220927/debian/rules 
vpnc-0.5.3+git20220927/debian/rules
--- vpnc-0.5.3+git20220927/debian/rules 2022-12-27 20:01:18.0 +0100
+++ vpnc-0.5.3+git20220927/debian/rules 2024-02-20 19:13:28.0 +0100
@@ -21,7 +21,7 @@
 
 override_dh_auto_install:
touch install-doc
-   dh_auto_install -- PREFIX=/usr SYSTEMDDIR=/lib/systemd/system install
+   dh_auto_install -- PREFIX=/usr SYSTEMDDIR=/usr/lib/systemd/system 
install
rm -rf ./debian/vpnc/usr/share/licenses
 
 override_dh_fixperms:

Bug#1064191: openjdk-8: fails to install on i386 mantic, focal and jammy

[Thorsten Glaser]

Hi Vladimir,

>Thank you!!!

sure. I don’t want to make your life harder, but I did that change
to address another installability bug on those platforms ;-)

>I will prepare the patch for Ubuntu stable releases/i386 and update the bug.

OK, wonderful.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1064354: steam-installer: Unable to install steam-installer

[Tobias Frost]

Control: tags -1 moreinfo

Hi Wesley,

On Tue, Feb 20, 2024 at 01:24:30PM -0400, Wesley Schwengle wrote:
(...)
> I've also tried to install it by executing:
> 
> sudo dpkg --add-architecture i386
> 
> to no avail.
(...)
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'testing'), 
> (10, 'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), 
> (10, 'oldoldstable'), (10, 'stable'), (10, 'oldstable')
> Architecture: amd64 (x86_64)

You system information indicates that the i386 archictecure has NOT been
added, as I would expect a 
  "Foreign Architectures: i386"
in the System Information" section.

Please recheck if the addition of the architecutre has worked, and
remember you'll need to apt update afterwards,

Checking in a chroot, I get the exact error message as you are getting,
when there is _no_ i386 architecture added, but after adding it and
after apt-update, steam-installer can be installed.

-- 
Cheers,
tobi

Bug#1037136: [PATCH 3/3] Also emit -Werror=implicit-function-declaration for feature=+time64

[Thorsten Glaser]

Hi *,

from my experience, adding -Werror=* flags causes breakage
because way too many configure scripts miss the appropriate
headers when probing for symbols, so this wouldn’t lead to
build failures but to changed feature sets or the programs
using older/fallback APIs (e.g. if probing openat() fails,
a program could unconditionally use open in an insecure way
as fallback, and the missing header would be there in the
site that actually uses it but autoconf generally misses
them).

In MirBSD, I’ve worked around this by appending a new flag
-Werror-maybe-reset to CFLAGS and CXXFLAGS which has no
effect in GCC unless an extra environment variable is set,
in which case it does -Wno-error. Then, we set that env
during the configure call but not during make all/install.
This was achieved with a trivial local GCC patch.

I know we already add -Werror=format-security in many
cases, but that has less chance to break the configue
stage (even so I’d look sceptical at it).

bye,
//mirabilos
-- 
 cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht noch 3 Jahre warten können?  bis dahin gibts google nicht
mehr  ja, könnte man meinen. wahrscheinlich ist der angekündigte welt-
untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum
müssen die die doodles vorher noch raushauen

Bug#1063106: bctoolbox: NMU diff for 64-bit time_t transition

[Dennis Filder]

X-Debbugs-CC: Steve Langasek 

On Fri, Feb 16, 2024 at 01:55:51PM -0800, Steve Langasek wrote:
> > I presume the need for "close together in time" is to prevent
> > interoperability issues from cropping up in unstable between shared
> > library versions on different sides of the time_t transition.  How
> > timely would our staged versions need to be uploaded to unstable to
> > obviate the need for the NMUs?  I ask because it is very difficult to
> > say with a useful degree of certainty when these staged versions will
> > actually reach testing.  Experience has shown that linphone stack
> > transitions are prone to being afflicted by (sometimes multi-month)
> > delays due to being blocked by other transitions, and I see no open
> > bugreport for linphone on the release.debian.org pseudopackage, so
> > Berni (who will do these uploads) apparently has not yet applied for a
> > new transition slot.
>
> Based on the above I think you should let us go ahead with the NMUs to
> unstable and not worry about it, clobbering them later at your convenience.

I agree.

Regards.

Bug#1064355: ITP: client-desktop-shell-integration-dolphin -- ownCloud client integration for Dolphin

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: Pierre-Elliott Bécue 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-owncloud-maintain...@lists.alioth.debian.org

* Package name: client-desktop-shell-integration-dolphin
  Version : 5.0.0
  Upstream Contact: Fabian Müller 
* URL : 
https://github.com/owncloud/client-desktop-shell-integration-dolphin
* License : GPL-2
  Programming Lang: C++
  Description : ownCloud client integration for Dolphin

Dolphin ownCloud is an extension that integrates the ownCloud web
service with Plasma Desktop (KDE). It was part of src:owncloud-client,
but upstream removed it and put it in another repo.

I intend to have this package maintained into the owncloud-maintainers
team.

Bug#1064354: steam-installer: Unable to install steam-installer

[Wesley Schwengle]

Package: steam-installer
Severity: important
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I wanted to install the steam-installer package, this fails:

$ sudo apt-get install steam-installer/unstable
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '1:1.0.0.79~ds-2' (Debian:unstable, Debian:testing [amd64]) 
for 'steam-installer'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 steam-installer : Depends: steam-libs-i386 (= 1:1.0.0.79~ds-2) but it is not 
installable
E: Unable to correct problems, you have held broken packages.

I don't have steam-libs-i386, but I do see steam-libs:

$ apt-cache policy steam-libs
steam-libs:
  Installed: (none)
  Candidate: 1:1.0.0.79~ds-2
  Version table:
 1:1.0.0.79~ds-2 900
900 https://deb.debian.org/debian unstable/main amd64 Packages
500 https://deb.debian.org/debian testing/main amd64 Packages
 1:1.0.0.75+ds-6 10
 10 https://deb.debian.org/debian stable/main amd64 Packages

Which I can also install:
$ sudo apt-get install steam-libs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  libudev0 nvidia-driver-libs nvidia-vulkan-icd
Recommended packages:
  libasound2-plugins libva-glx2 mesa-vulkan-drivers steam-devices zenity
The following NEW packages will be installed:
  steam-libs
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 18.9 kB of archives.
After this operation, 38.9 kB of additional disk space will be used.
Get:1 https://deb.debian.org/debian unstable/main amd64 steam-libs amd64 
1:1.0.0.79~ds-2 [18.9 kB]
Fetched 18.9 kB in 1s (32.1 kB/s)
Selecting previously unselected package steam-libs:amd64.
(Reading database ... 474365 files and directories currently installed.)
Preparing to unpack .../steam-libs_1%3a1.0.0.79~ds-2_amd64.deb ...
Unpacking steam-libs:amd64 (1:1.0.0.79~ds-2) ...
Setting up steam-libs:amd64 (1:1.0.0.79~ds-2) ...

I tried reinstalled steam-installer, but this failed (as expected, but tried it
none the less):

$ sudo apt-get install steam-installer/unstable
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '1:1.0.0.79~ds-2' (Debian:unstable, Debian:testing [amd64]) 
for 'steam-installer'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 steam-installer : Depends: steam-libs-i386 (= 1:1.0.0.79~ds-2) but it is not 
installable
E: Unable to correct problems, you have held broken packages.

I cannot seem to install it for ANY version of the steam-installer:

$ sudo apt-get install steam-installer/testing
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '1:1.0.0.79~ds-2' (Debian:unstable, Debian:testing [amd64]) 
for 'steam-installer'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 steam-installer : Depends: steam-libs-i386 (= 1:1.0.0.79~ds-2) but it is not 
installable
E: Unable to correct problems, you have held broken packages.

$ sudo apt-get install steam-installer/stable
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '1:1.0.0.75+ds-6' (Debian:12.5/stable [amd64]) for 
'steam-installer'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 steam-installer : Depends: steam-libs (= 1:1.0.0.75+ds-6) but 1:1.0.0.79~ds-2 
is to be installed
   Depends: steam-libs-i386 (>= 1:1.0.0.75+ds-6) but it is not 
installable
E: Unable to correct problems, you have held broken packages.

I've also tried to install it by executing:

sudo dpkg --add-architecture i386

to no avail.




-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'experimental'), 

Bug#1064353: postsrsd: fails to install with sysvinit-core

[Michal Mauser]

Package: postsrsd
Version: 1.10-2+b1
Severity: important

Dear Maintainer,

we are trying to install new KVM virtual machines with Debian 12 and 
here is what happens after reboot with sysvinit and apt install:


postsrsd: Generating initial /etc/postsrsd.secret
Starting Postfix Sender Rewriting Scheme daemon: postsrsdpostsrsd: 
Cannot write PID: /var/run/postsrsd.pid


 failed!
invoke-rc.d: initscript postsrsd, action "start" failed.

Looks like some issue with Apparmor. It works with systemd.

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages postsrsd depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u4
ii  sysvinit-utils [lsb-base]  3.06-4

postsrsd recommends no packages.

postsrsd suggests no packages.

-- debconf information:
  postsrsd/domain: netio.cz

Bug#1064345: gnome-settings-daemon: Cannot input Japanese on some apps with wayland

[Hideki Yamane]

Hi Jeremy,

On Tue, 20 Feb 2024 07:27:40 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= 
 wrote:
> Does this happen every time?

 Yes, at least on my laptop for work (Debian testing).
 Not depend on users, I've tested it on my laptop with two users,
 and it happens for those two.


> There should not have been any input related changes in
> gnome-settings-daemon 46 Beta:
> https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/compare/45.1...46.beta
> 
> Maybe something else changed on your system instead?

 No, just downgrading gnome-settings-daemon (as below) solves this problem.

> > Start-Date: 2024-02-20  20:03:40
> > Commandline: apt install ./gnome-settings-daemon-common_45.1-1_all.deb 
> > ./gnome-settings-daemon_45.1-1_amd64.deb
> > Requested-By: henrich (1000)
> > Downgrade: gnome-settings-daemon-common:amd64 (46~beta-1, 45.1-1), 
> > gnome-settings-daemon:amd64 (46~beta-1, 45.1-1)
> > End-Date: 2024-02-20  20:03:44


 And here is reproduce step)

 1. upgrade gnome-settings-daemon to 46~beta-1
 2. logout from gnome
 3. re-login (to use updated gnome-settings-daemon)
 4. try to input Japanese on firefox-esr and could not do it
 5. downgrade gnome-settings-daemon to 45.1-1
 6. switch to second user
 7. try to input Japanese on firefox-esr and it works
 8. logout and switch back to first user
 9. logout (first user) and re-login
 10. try to input Japanese on firefox-esr and it works


 I'm not sure how to debug it and get some logs...


-- 
Hideki Yamane 

Bug#1064352: ITP: python-duet -- Duet is a simple future-based async library for python

[Pulak Bhushan]

Package: wnpp
Severity: wishlist
Owner: Pulak Bhushan 
X-Debbugs-Cc: debian-de...@lists.debian.org, pulakbhus...@gmail.com

* Package name: python-duet
  Version : 0.2.9
  Upstream Contact: The Duet Authors 
* URL : https://github.com/google/duet
* License : Apache-2.0
  Programming Lang: Python
  Description : Duet is a simple future-based async library for python

Duet takes inspiration from the amazing trio library and the 
 structured concurrency approach to async programming that it uses.

 This is a depend for other Python packages. I want to maintain this under DPT.
 I need sponsorship. 

Bug#1064351: ikos: FTBFS: Could NOT find GMP.

[Andreas Beckmann]

Source: ikos
Version: 3.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

ikos FTBFS with

...
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/build/ikos-3.2'
dh_auto_configure --\
-DLLVM_CONFIG_EXECUTABLE=/usr/bin/llvm-config-14\
-DINSTALL_PYTHON_VIRTUALENV=OFF \
-DPYTHON_VENV_EXECUTABLE=/usr/bin/python3   \
-DCMAKE_BUILD_TYPE=RelWithDebInfo
cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DLLVM_CONFIG_EXECUTABLE=/usr/bin/llvm-config-14 
-DINSTALL_PYTHON_VIRTUALENV=OFF -DPYTHON_VENV_EXECUTABLE=/usr/bin/python3 
-DCMAKE_BUILD_TYPE=RelWithDebInfo ..
CMake Deprecation Warning at CMakeLists.txt:41 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument  value or use a ... suffix to tell
  CMake that the project does not need compatibility with older versions.


-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Install prefix: /usr
-- Build type: RelWithDebInfo
-- CMake version: 3.28.3
-- CMake generator: Unix Makefiles
-- Including core
CMake Deprecation Warning at core/CMakeLists.txt:41 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument  value or use a ... suffix to tell
  CMake that the project does not need compatibility with older versions.


Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0 (found version 
"1.55.0")
Found Boost components:
   unit_test_framework
CMake Error at 
/usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find GMP.  Please provide -DGMP_ROOT=/path/to/gmp (missing:
  GMP_INCLUDE_DIR GMP_LIB GMPXX_INCLUDE_DIR GMPXX_LIB)
Call Stack (most recent call first):
  /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
  cmake/FindGMP.cmake:109 (find_package_handle_standard_args)
  core/CMakeLists.txt:90 (find_package)


-- Configuring incomplete, errors occurred!
...


Andreas

Bug#1064223: imbalanced-learn: fails tests with sklearn 1.4: needs new versions

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 
https://github.com/scikit-learn-contrib/imbalanced-learn/issues/1062

Hi,

thanks a lot for the hint about the new version of imbalanced-learn.
Unfortunately it is not sufficient to simply upgrade to latest
upstream as you can see in Salsa CI[1].  Thus I've reported the
issue upstream.

Kind regards
   Andreas.


[1] https://salsa.debian.org/med-team/imbalanced-learn/-/jobs/5331921

-- 
http://fam-tille.de

Bug#1064350: piuparts: breaks some salsa-ci tests

[Andreas Beckmann]

Package: piuparts
Version: 1.3
Severity: serious

Hi,

I'm not sure whether this is caused by piuparts itself or by the way how
salsa-ci uses piuparts, but recently some piuparts tests run by salsa-ci
started to fail. So far I've only noticed this if salsa-ci.yml contains
  SALSA_CI_COMPONENTS: 'main contrib non-free'
e.g. in this failure

https://salsa.debian.org/nvidia-team/bumblebee/-/jobs/5333059

...
0m0.2s DEBUG: sources.list:
  deb http://deb.debian.org/debian sid main
  deb http://deb.debian.org/debian sid contrib
  deb http://deb.debian.org/debian sid non-free
...
0m0.2s DEBUG: Starting command: ['chroot', '/tmp/tmpz130bkq5', 'eatmydata', 
'apt-get', 'update']
0m0.9s DUMP: 
  Hit:1 http://deb.debian.org/debian sid InRelease
  /usr/bin/apt-key: 95: cannot create /dev/null: Permission denied
  /usr/bin/apt-key: 95: cannot create /dev/null: Permission denied
  /usr/bin/apt-key: 95: cannot create /dev/null: Permission denied
  E: gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed
  Sub-process apt-key returned an error code (29)Err:1 
http://deb.debian.org/debian sid InRelease
gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed
  Reading package lists...
  W: An error occurred during the signature verification. The repository is not 
updated and the previous index files will be used. GPG error: 
http://deb.debian.org/debian sid InRelease: gpgv, gpgv2 or gpgv1 required for 
verification, but neither seems installed
  W: Failed to fetch http://deb.debian.org/debian/dists/sid/InRelease  gpgv, 
gpgv2 or gpgv1 required for verification, but neither seems installed
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  W: Target Packages (main/binary-amd64/Packages) is configured multiple times 
in /etc/apt/sources.list:1 and /etc/apt/sources.list.d/debian.sources:1
  W: Target Packages (main/binary-all/Packages) is configured multiple times in 
/etc/apt/sources.list:1 and /etc/apt/sources.list.d/debian.sources:1
0m0.9s DEBUG: Command ok: ['chroot', '/tmp/tmpz130bkq5', 'eatmydata', 
'apt-get', 'update']
...

apt-get update did not fail, but Packages for not-main are not loaded
resulting in subsequent installation failures of contrib or non-free
packages.


Another example where the test still succeeded 3 months ago:
https://salsa.debian.org/nvidia-team/python-pycuda/-/jobs/4920273
but fails today:
https://salsa.debian.org/nvidia-team/python-pycuda/-/jobs/5275149


Andreas

Bug#1064349: amavisd-new: fails to install with sysvinit-core

[Michal Mauser]

Package: amavisd-new
Version: 1:2.13.0-3
Severity: important

Dear Maintainer,

we are trying to install new KVM virtual machines with Debian 12 and 
here is what happens after reboot with sysvinit and apt install:


Creating group 'amavis' with GID 996.
Creating user 'amavis' (AMaViS system user) with UID 996 and GID 996.
Starting amavisd: You are missing a dpkg-statoverride on 
/var/run/amavis.  Fix it, otherwise you risk silent breakage on

 upgrades.
invoke-rc.d: initscript amavis, action "start" failed.

The installation works on systemd. /var/run/amavis doesn't exist. I 
haven't checked it on Debian 11 but we use amavis on Debian 10 sysvinit.


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages amavisd-new depends on:
ii  debconf [debconf-2.0]   1.5.82
ii  file1:5.44-3
ii  init-system-helpers 1.65.2
pn  libarchive-tar-perl 
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libconvert-tnef-perl0.18-1.1
ii  libconvert-uulib-perl   1:1.8+dfsg-1
pn  libdigest-md5-perl  
ii  libio-stringy-perl  2.111-3
ii  libmail-dkim-perl   1.20230212-1
ii  libmailtools-perl   2.21-2
pn  libmime-base64-perl 
ii  libmime-tools-perl  5.510-1
ii  libnet-libidn-perl  0.12.ds-4+b1
ii  libnet-server-perl  2.013-2
ii  libnet-snmp-perl6.0.1-7
ii  libunix-syslog-perl 1.1-4+b1
ii  pax 1:20201030-1
ii  perl [libtime-hires-perl]   5.36.0-7+deb12u1
ii  systemd-standalone-sysusers [systemd-sysusers]  252.22-1~deb12u1

Versions of packages amavisd-new recommends:
ii  altermime 0.3.10-12
ii  libnet-patricia-perl  1.22-2+b1
pn  ripole

Versions of packages amavisd-new suggests:
ii  apt-listchanges 3.24
pn  arj 
pn  cabextract  
pn  clamav  
pn  clamav-daemon   
ii  cpio2.13+dfsg-7.1
pn  dspam   
pn  lhasa   
ii  libauthen-sasl-perl 2.1600-3
pn  libdbi-perl 
ii  libjson-perl4.1-1
pn  liblwp-protocol-https-perl  
pn  libnet-ldap-perl
ii  libnet-ssleay-perl  1.92-2+b1
pn  libsnmp-perl
pn  libwww-perl 
pn  lzop
pn  nomarch 
pn  p7zip   
pn  rpm 
pn  spamassassin
pn  unrar   

-- no debconf information

Bug#1064348: openstack-cluster-installer: Don't listen for SSH on ceph-cluster IPs

[Jim Scadden]

Package: openstack-cluster-installer
Version: 42.3.7~bpo12+1
Tags: patch

I've raised a merge request [1] to exclude networks with the
ceph-cluster role when compiling the list of IPs which the SSH daemon
listens on.

This feels like a sensible security enhancement since AFAIK there is
always a 'management' network so there's no reason to want/need to use
SSH over a ceph-cluster network.

--

Regards
Jim Scadden (FloydianJim)

[1] 
https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer/-/merge_requests/47

Bug#1060153: closed by Debian FTP Masters (reply to Thomas Goirand ) (Bug#1060153: fixed in python-pbr 6.0.0-1)

[Alexandre Detiste]

Thank you.

I don't have a weird & twisted obsession about six library,
but I'm concerned about packages with undeclared dependencies
that suddenly start to FTBFS.

As pbr is still a popular build dependency,
this helps locate them :-)

Le mar. 20 févr. 2024 à 15:48, Debian Bug Tracking System
 a écrit :
> #1060153: /usr/bin/pbr: please package v6.0.0
> Please package v6.0.0 and strip-out trival usage of six.

Bug#1064346: Source is missing errors on HTML source files

[Shriram Ravindranathan]

Hello mentors,

I am getting a few lintian "source-is-missing" errors for some HTML 
files. These HTML files are infact present in the source code but they 
have too many lines which triggers a 
"very-long-line-length-in-source-file" lintian tag and that in turn 
causes the "source-is-missing" error.


Most of the info I could find in the policy manual and in the forums 
pertained to binary files that were included in the source, the strategy 
these resources suggested were

1. Repack upstream tar with the source code of these files
2. Add the source code to the d/missing-sources directory

I don't think either of these are viable options in my case. I was 
wondering whether it would be okay to suppress these errors. Is there 
any other way to solve this?


--
Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature