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

[Gianfranco Costamagna]

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.

Bug#1064275: autopkgtest failure with python-jsonschema 4.19.2

[Ole Streicher]

Hi Thomas,

it would be nice (and IMO common practice) to get a bug report on 
experimental *before* the upload to unstable, as this gives the chance 
to react before it becomes serious. I don't monitor pseudo-migration 
excuses.


Best

Ole

Bug#1064337: [Pkg-samba-maint] Bug#1064337: samba: NMU diff for 64-bit time_t transition

[Andrew Bartlett]

On Tue, 2024-02-20 at 10:52 +0300, Michael Tokarev wrote:
> 20.02.2024 09:30, Steve Langasek wrote:
> > Source: sambaVersion: 2:4.20.0~rc2+dfsg-1Severity: importantTags:
> > patch pending sid trixieUser: debian-...@lists.debian.org
> > Usertags: time-t
> 
> -Package: libsmbclient+Package: libsmbclient0
> Well.  Maybe this is ok.  I still haven't seen samba-libs analysis
> abouttime_t abi, but smbclient never had a version in soname.
> libsmbclient is definitely a public library.
> 
> -Package: libldb2+Package: libldb2t64
> And this one is definitely not needed.

Very much agreed :-)
> libldb is an internal-to-samba library, which is used by exactlyone
> package in debian, sssd, for which you're adding Breaks.I'm already
> adding the same Breaks in the next version of libldb,because libldb
> has become incompatible with sssd *again* (thenew packages of samba
> 4.20 is in experimental, not yet with theBreaks since I'm waiting for
> a rebuild of sssd).  Due the natureof these libs (samba-libs and
> libldb), it is a stuff which is notused outside, and it does not need
> time_t transition.
> Where's the analysis of libsmbclient ABI?

I checked the header, and there are a lot of references to "struct
timespec" in the main structures, plus one of time_t in a printing
thing. 
Andrew Bartlett

-- 
Andrew Bartlett (he/him)   https://samba.org/~abartlet/Samba Team Member 
(since 2001) https://samba.orgSamba Team Lead
https://catalyst.net.nz/services/sambaCatalyst.Net Ltd
Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
company
Samba Development and Support: https://catalyst.net.nz/services/samba
Catalyst IT - Expert Open Source Solutions

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

[Phil Wyett]

On Thu, 2024-02-15 at 08:18 +, Debian Bug Tracking System wrote:
> 1059236

Hi Gianfranco,

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?

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#1064341: colorized-logs: ansi2txt/ansi2html turn sgr0 into B instead of empty string

[Paul Wise]

Package: colorized-logs
Version: 2.6-1
Severity: normal

ansi2txt/ansi2html turn sgr0 into 'B' instead of an empty string.

   $ echo $TERM 
   xterm-256color

   $ tput sgr0 | hd
     1b 28 42 1b 5b 6d |.(B.[m|
   0006
   
   $ tput sgr0 | ansi2txt ; echo
   B
   
   $ tput sgr0 | ansi2html --no-header
   B

   $ man terminfo | grep sgr0 | head -n 1
  exit_attribute_mode sgr0 me   turn off all attributes
   
-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages colorized-logs depends on:
ii  less   590-2
ii  libc6  2.37-15

colorized-logs recommends no packages.

Versions of packages colorized-logs suggests:
pn  ccze   
ii  colordiff  1.0.20-1
pn  colormake  
pn  colortail  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1064337: [Pkg-samba-maint] Bug#1064337: samba: NMU diff for 64-bit time_t transition

[Michael Tokarev]

20.02.2024 10:30, Andrew Bartlett :

Kia Ora Steve,

So long since we had a chance to work together, and I thank you for your work 
on Debian.

Can we have a chat about this?

sssd does not, as I read it, use any time_t relevant parts of ldb, and is the 
only external user of LDB in Debian that we know of.


It is not only about Debian.  The transition is here not just for
packages in Debian, but also for any external 3rd-paty packages
which might be installed on user systems from any external sources
or built locally.

Still, libldb and samba-libs are private-to-samba things (or at least
semi-private), libldb isn't something which is consumed externally
(even sssd *extends* libldb, not "uses" it).  There should be no
external consumers of it.  And for sssd, we had enough changes in
libldb already which breaks sssd in one way or another and needs
sssd rebuild or refinement.

FWIW.
Do we really need libldb package?  Maybe it can be a part of
samba-libs?  There's a thread about that on samba-technical@,
but it occured to me only now, - do we *really* need a separate
libldb?  I'll reply on samba-technical@, this has nothing to do
with this time_t transition.

/mjt

Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640

[Ben Mesman | Spark Narrowcasting]

Van: Salvatore Bonaccorso 
> Hi Ben,
> 
> On Thu, Dec 14, 2023 at 09:16:48AM +, Ben Mesman | Spark Narrowcasting 
> wrote:
> > The attached patch works on my systems. Is there a way to get this in?
> 
> ...
> 
> We cannot pick changes which are not going to land in Linux upstream
> and then backported to the stable series. So the way to go here is to
> report the bug upstream, along with your proposed change. Candidates
> to reach out are:
> 
> ...
> 
> as it is affecting 6.1.y mention that the fix needs to be backported to 
> various
> stable series at least back 6.1.y and describe which testing you have
> performed.
> 
> Feel free to keep as well the Debian bug in the loop for the report.
> 
> Hope this helps?

Small update on this bug: I reached out and Fred Ai made a patch which is now 
in the mainline kernel:

commit 58aeb5623c2ebdadefe6352b14f8076a7073fea0
Author: Fred Ai 
Date:   Sat Feb 3 02:29:08 2024 -0800

mmc: sdhci-pci-o2micro: Fix a warm reboot issue that disk can't be detected 
by BIOS

Driver shall switch clock source from DLL clock to
OPE clock when power off card to ensure that card
can be identified with OPE clock by BIOS.

Signed-off-by: Fred Ai 
Fixes:4be33cf18703 ("mmc: sdhci-pci-o2micro: Improve card input timing at 
SDR104/HS200 mode")
Cc: sta...@vger.kernel.org
Link: 
https://lore.kernel.org/r/20240203102908.4683-1-fredaibayhubt...@126.com
Signed-off-by: Ulf Hansson 

I'm still waiting for the patch to land in the stable kernel series (both 6.1 
and 6.6)

Regards,
Ben Mesman.

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

[Phil Wyett]

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.

Thanks for the advice.

I will process the package in the next day or so. Playing priority catch-up 
after a number
of days in bed due to my back condition.

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#1052138: RFS: ukui-kwin/5.27.5-1 [ITP] -- UKUI window manager gl utils library

[MouseZhang]

cc Aron

> On Feb 20, 2024, at 14:43, 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.
> 
>> * 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.
> 
>> * 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).
> 

Bug#1057386: [Pkg-electronics-devel] imsprog , #1057386

[Fabio Fantoni]

Hi, is it possible to upload this shortly to try to include before the 
feature freeze on Ubuntu 24.04? (February 29th)


I helped to improve the packaging, and now seems ready to me, but I'm 
only DM and I can't upload new packages.


2 DD did a review on mentors over the past weeks and the recommended 
changes have been made, but it seems they haven't had time to review it 
again recently.




OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Julian Gilbey]

On Mon, Feb 19, 2024 at 10:36:29PM +, Rebecca N. Palmer wrote:
> Thank you for caring about not breaking other packages, and yes, that's a
> good reason to not upload that new upstream for now.
> 
> Does just the patch (not the new upstream) also break debugpy?  (It
> shouldn't be able to, since it only touches test code.)

It's taking time to locate the source of the problem.  It's a bit
messy: debugpy vendors pydevd, pydevd in turn vendors bytecode.  I've
split out bytecode and pydevd into separate packages.  Unfortunately,
the bytecode version in pydevd is behind that in Debian, though that
should not be too much of a problem.  The native version of debugpy
(with all other packages being Debian ones) passes all the tests in a
Debian testing lxc container, but with the Debian versions of
bytecode, pydevd and debugpy, it doesn't.  So something's gone wrong
somewhere, but it's taking some effort to locate (and hopefully fix!)
the cause.

Best wishes,

   Julian

Bug#1063424: nmu: wlgreet_0.4.1-3

[duck]

Quack,

On 2024-02-08 15:50, Arto Jantunen wrote:

This is needed to fix #1061421 (crash with recent sway versions). This 
is
caused by the same underlying issue as #1061563 in alacritty, it was 
already

fixed via binNMU there.


Thanks a lot.
I'm in the middle of moving to a new Pond and lacked time to debug more, 
so this is really helpful.


Regards.
\_o<

--
Marc Dequènes

Bug#1063746: Upload request for golang-github-katalix-go-l2tp 0.1.7-1

[Simon Josefsson]

Tom Parkin  writes:

> Hi folks,
>
> Would someone mind please reviewing and uploading
> golang-github-katalix-go-l2tp 0.1.7-1?
>
> https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp

Looks good, although there were no tag for the previous Debian upload so
diffing changes was a bit difficult.  Do you still have the 0.1.6-2 tag
locally?  If so would be good if you could push that.  Uploaded anyway,
and I forgot to add a 'New upstream release' changelog entry, although
that should be pretty obvious from the version number anyway.

/Simon


signature.asc
Description: PGP signature

Bug#1064342: pulseaudio: a2dp-sink profile connect failed [...]: Protocol not available

[Arturo Borrero Gonzalez]

Package: pulseaudio
Version: 16.1+dfsg1-3
Severity: normal

Dear maintainer,

thanks for your hard work with this package, it is really appreciated.

Today, I hit a problem trying to pair a bluetooth headset.

I got errors like `a2dp-sink profile connect failed [...]: Protocol not 
available`.
Searching the wiki, I found there is a known solution to this, which is 
documented
here:

 
https://wiki.debian.org/BluetoothUser/a2dp#a2dp-sink_profile_connect_failed_.5B5D:_Protocol_not_available

In a nutshell, we need the following two lines in the pulseaudio config file:

load-module module-bluez5-device
load-module module-bluez5-discover

For example, in the file `/etc/pulse/default.pa.d/bluez5.pa`.

Please, consider having the config be shipped as part of the debian package.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_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)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser 3.137
ii  init-system-helpers 1.66
ii  libasound2  1.2.10-3
ii  libasound2-plugins  1.2.7.1-1+b1
ii  libc6   2.37-15
ii  libcap2 1:2.66-5
ii  libdbus-1-3 1.14.10-4
ii  libfftw3-single33.3.10-1+b1
ii  libgcc-s1   14-20240201-3
ii  libglib2.0-02.78.4-1
ii  libgstreamer-plugins-base1.0-0  1.22.10-1
ii  libgstreamer1.0-0   1.22.10-1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-7
ii  liborc-0.4-01:0.4.34-3
ii  libpulse0   16.1+dfsg1-3
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.2.2-1
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.1-1+b1
ii  libstdc++6  14-20240201-3
ii  libsystemd0 255.3-2
ii  libtdb1 1.4.10-1
ii  libudev1255.3-2
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libwrap07.6.q-32+b1
ii  libx11-62:1.8.7-1
ii  libx11-xcb1 2:1.8.7-1
ii  libxcb1 1.15-1
ii  libxtst62:1.2.3-1.1
ii  pulseaudio-utils16.1+dfsg1-3
ii  sysvinit-utils [lsb-base]   3.08-6

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.10-4
ii  libpam-systemd [logind]  255.3-2
ii  rtkit0.13-5

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 255.3-2

-- Configuration Files:
/etc/dbus-1/system.d/pulseaudio-system.conf [Errno 2] No such file or 
directory: '/etc/dbus-1/system.d/pulseaudio-system.conf'

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 

Bug#1064341: colorized-logs: ansi2txt/ansi2html turn sgr0 into B instead of empty string

[Adam Borowski]

Control: clone -1 -2
Control: retitle -2 tput sgr0 adds uncalled-for codes
Control: reassign -2 ncurses-bin

On Tue, Feb 20, 2024 at 04:15:30PM +0800, Paul Wise wrote:
> ansi2txt/ansi2html turn sgr0 into 'B' instead of an empty string.

>$ echo $TERM 
>xterm-256color
> 
>$ 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.

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.

I'm reassigning to ncurses-bin as I believe that terminfo is merely an
implementation detail here -- and a grossly obsolete one as the very concept
of terminfo has stopped working by mid-1980's -- but ncurses-bin and
ncurses-base come from the same source package so this hardly matters.

Thus:
"tput sgr0" should produce sgr0, not setusg0 sgr0.

---

There's a second bug, though, this time on my side:

>$ tput sgr0 | ansi2txt ; echo
>B
>
>$ tput sgr0 | ansi2html --no-header
> style="color:#bbb;white-space:pre-wrap;word-wrap:break-word;overflow-wrap:break-word">B

When the text being parsed contains G0/G1 settings, whether intentional or
not, they should be recognized and either implemented or ignored. ansi2txt
promises to remove all ANSI codes, not merely ones that would make sense in
the given context.

It's probably not worth the effort to implement charset conversions anymore
as non-Unicode is thoroughly dead by now; I'll thus ignore these codes.

I guess other codes should be looked at, too...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1063746: Upload request for golang-github-katalix-go-l2tp 0.1.7-1

[Tom Parkin]

On  Tue, Feb 20, 2024 at 10:54:04 +0100, Simon Josefsson wrote:
> Tom Parkin  writes:
> 
> > Hi folks,
> >
> > Would someone mind please reviewing and uploading
> > golang-github-katalix-go-l2tp 0.1.7-1?
> >
> > https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp
> 
> Looks good, although there were no tag for the previous Debian upload so
> diffing changes was a bit difficult.  Do you still have the 0.1.6-2 tag
> locally?  If so would be good if you could push that.  Uploaded anyway,
> and I forgot to add a 'New upstream release' changelog entry, although
> that should be pretty obvious from the version number anyway.

Thanks Simon, much appreciated.

In re: tags -- I'm not quite sure what's going on here.  Nilesh tagged
0.1.6-2 I believe: I did have the tag in my repo although how I'd have
it without it going via. salsa I'm not sure.

Anyway, here it is:

https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp/-/tags/debian%2F0.1.6-2

All the best,
Tom


signature.asc
Description: PGP signature

Bug#1063424: nmu: wlgreet_0.4.1-3

[Arto Jantunen]

"Marc Dequènes (duck)"  writes:

> Quack,
>
> On 2024-02-08 15:50, Arto Jantunen wrote:
>
>> This is needed to fix #1061421 (crash with recent sway versions). This is
>> caused by the same underlying issue as #1061563 in alacritty, it was already
>> fixed via binNMU there.
>
> Thanks a lot.
> I'm in the middle of moving to a new Pond and lacked time to debug more, so
> this is really helpful.

Sadly as far as I can tell that did not in fact fix the issue for
wlgreet (while it definitely did for alacritty). I don't know why,
though. More debugging is needed.

-- 
Arto Jantunen

Bug#1057386: Upload of imsprog

[Carsten Schoenert]

Hello Fabio,

Am 20.02.24 um 10:28 schrieb Fabio Fantoni:

Hi, is it possible to upload this shortly to try to include before the
feature freeze on Ubuntu 24.04? (February 29th)

I helped to improve the packaging, and now seems ready to me, but I'm
only DM and I can't upload new packages.

2 DD did a review on mentors over the past weeks and the recommended
changes have been made, but it seems they haven't had time to review it
again recently.


in a short term I need to answer no, I can't process this RFP on a quick 
run.
The uploader is responsible for the package and the upload itself, no 
matter if other DDs did have already done a review of the package in 
detail. Before the weekend I wont have time to dig into the current 
packaging.


--
Regards
Carsten

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Joachim Zobel]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : vzlogger
 Version : 3.1-4
 Upstream contact : Joachim Zobel 
 * URL : http://wiki.volkszaehler.org/software/controller/vzlogger
 * License : GPL-3
 * Vcs : https://github.com/volkszaehler/vzlogger
 Section : net 

The source builds the following binary packages:

 vzlogger - program to read measurements from smart meters and log them
to Influxdb or forward them via MQTT.

vzlogger is a tool to read and log measurements of a wide variety of
smart meters and sensors. It supports various commonly used protocols
such as s0, d0, sml, oms and others. It can write these data to an
Influxdb, forward them via MQTT, make them available via HTTP or eport
them to a volkszaehler.org middleware.

The package is maintained in the upstream repository. Upstream (which I
am part of) currently builds native packages. These are patched (a
switch from native to quilt, a different changelog and a version >= 3.0
for the dependency on openssl) to make them more suitable for debian.
The package is therefore availabe in the upstream repo 

https://github.com/volkszaehler/vzlogger.git 

on branch debian-0.8.3-1.

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

 dget -x 
http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.3-1.dsc

Regards,
-- 
 Joachim Zobel

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

[Hideki Yamane]

Package: gnome-settings-daemon
Version: 46~beta-1
Severity: important
X-Debbugs-Cc: henr...@debian.org

Dear Maintainer,

 Recently I've updated my Debian testing box and rebooted it, then I could not
 input Japanese with IME (ibus + mozc) on some applications e.g. firefox-esr,
 google-chrome, slack, etc.

 After some investigations, I can input Japanese on Xorg session, instead of 
wayland.
 However, it misses some input on Xorg, so it is not a solution for me. And 
after
 more investigations, I've found that downgrade gnome-settings-daemon to 45.1-1
 solves this problem.


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

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

Versions of packages gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common  45.1-1
ii  gsettings-desktop-schemas 45.0-2
ii  libasound21.2.10-3
ii  libc6 2.37-15
ii  libcairo2 1.18.0-1+b1
ii  libcanberra-gtk3-00.30-11
ii  libcanberra0  0.30-11
ii  libcolord21.4.7-1
ii  libcups2  2.4.7-1+b1
ii  libfontconfig12.14.2-6+b1
ii  libgck-1-03.41.1-4
ii  libgcr-base-3-1   3.41.1-4
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-3+b1
ii  libgeoclue-2-02.7.1-2
ii  libgeocode-glib-2-0   3.26.3-6+b1
ii  libglib2.0-0  2.78.4-1
ii  libgnome-desktop-3-20 44.0-2+b1
ii  libgtk-3-03.24.41-1
ii  libgudev-1.0-0238-3
ii  libgweather-4-0   4.4.0-1
ii  libmm-glib0   1.22.0-3
ii  libnm01.44.2-7
ii  libnotify40.8.3-1
ii  libp11-kit0   0.25.3-4
ii  libpam-systemd [logind]   255.3-2
ii  libpango-1.0-01.51.0+ds-4
ii  libpangocairo-1.0-0   1.51.0+ds-4
ii  libpolkit-gobject-1-0 124-1
ii  libpulse-mainloop-glib0   16.1+dfsg1-3
ii  libpulse0 16.1+dfsg1-3
ii  libspa-0.2-bluetooth  1.0.3-1
ii  libupower-glib3   1.90.2-8
ii  libwacom9 2.9.0-2
ii  libwayland-client01.22.0-2.1+b1
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8.1-1
ii  pipewire-audio1.0.3-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy   3.5-1+b1
ii  pipewire-audio 1.0.3-1
ii  pkexec 124-1
ii  x11-xserver-utils  7.7+10

Versions of packages gnome-settings-daemon suggests:
pn  usbguard  

-- no debconf information

Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640

[Diederik de Haas]

On Tuesday, 20 February 2024 09:22:06 CET Ben Mesman | Spark Narrowcasting 
wrote:
>   mmc: sdhci-pci-o2micro: Fix a warm reboot issue that disk can't be
> detected by BIOS
>  ...
> Link:
> https://lore.kernel.org/r/20240203102908.4683-1-fredaibayhubt...@126.com
> 
> I'm still waiting for the patch to land in the stable kernel series (both
> 6.1 and 6.6)

That patched is queued in both 6.1 and 6.6 (and 6.7) so should normally land 
in the next upstream point release.

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

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

[Jeremy Bícha]

On Tue, Feb 20, 2024 at 6:39 AM Hideki Yamane  wrote:
>  Recently I've updated my Debian testing box and rebooted it, then I could not
>  input Japanese with IME (ibus + mozc) on some applications e.g. firefox-esr,
>  google-chrome, slack, etc.
>
>  After some investigations, I can input Japanese on Xorg session, instead of 
> wayland.
>  However, it misses some input on Xorg, so it is not a solution for me. And 
> after
>  more investigations, I've found that downgrade gnome-settings-daemon to 
> 45.1-1
>  solves this problem.

Does this happen every time?

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?

Thank you,
Jeremy Bícha

Bug#1064346: RFS: highlight/4.10-1 [ITA] -- Universal source code to formatted text converter

[Shriram Ravindranathan]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : highlight
   Version  : 4.10-1
   Upstream contact : Andre Simon 
 * URL  : http://www.andre-simon.de
 * License  : Expat, LGPL-2.1+, GPL-3+
 * Vcs  : https://salsa.debian.org/debian/highlight
   Section  : devel

The source builds the following binary packages:

  highlight - Universal source code to formatted text converter
  highlight-common - source code to formatted text converter (architecture 
independent files)
  libhighlight-perl - perl bindings for highlight source code to formatted text 
converter

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/highlight/highlight_4.10-1.dsc

Changes since the last upload:

 highlight (4.10-1) unstable; urgency=medium
 .
   * New upstream version 4.10
   * New maintainer (Closes: #1022114)
   * d/copyright:
 - Add new maintainer to copyright
 - Convert copyright to DEP5 format
 - Remove stanzas for files that no longer exist
   * d/control:
 - Add new maintainer's name to Maintainer field
 - Update VCS-Browser field to canonical URI
   * d/p/*: Remove git-debcherry artifacts and follow DEP-3
   * Add debian/upstream/metadata

Regards,
--
  Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064209: offpunk: opnk.py:52: SyntaxWarning: invalid escape sequence '\%'

[Étienne Mollier]

Control: forwarded -1 https://lists.sr.ht/~lioploum/offpunk-devel/patches/49706
Control: tag -1 + patch upstream

Hi Paul,

Paul Wise, on 2024-02-18:
> I got a warning when upgrading offpunk:
> 
>Preparing to unpack .../archives/offpunk_2.2-1_all.deb ...
>Unpacking offpunk (2.2-1) over (2.1-1) ...
>Setting up offpunk (2.2-1) ...
>/usr/lib/python3/dist-packages/opnk.py:52: SyntaxWarning: invalid escape 
> sequence '\%'
>  less_prompt = "page %%d/%%D- lines %%lb/%%L - %%Pb\%%"

Thank you for the report, I sent a mitigation upstream so this
should be fixed in upcoming versions.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#1062131: groonga: NMU diff for 64-bit time_t transition

[Kentaro HAYASHI]

NOTE:

I've found the SEGV issue with 13.1.1+dfsg-1 on armhf.

With patched abi=+time64 version 13.1.1+dfsg-1.2 in experimental, the
issue was resolved.

Before: 13.1.1+dfsg-1 on armhf

  groonga  db/test < load-last-modified.grn 
  [[0,1708379668.191548,0.02317619323730469],1]
  root@debian:/home/debian/bug1062131#  date --set="2038-01-19 12:14:00"
  Tue Jan 19 12:14:00 UTC 2038
  root@debian:/home/debian/bug1062131# date
  Tue Jan 19 12:14:03 UTC 2038
  root@debian:/home/debian/bug1062131# groonga db/test <
  update-last-modified.grn Segmentation fault

After: 13.1.1+dfsg-1.2 on armhf

  date --set="2038-01-19 12:13:50"
  Tue Jan 19 12:13:50 UTC 2038
  root@debian:/home/debian/bug1062131# groonga  db/test <
  load-last-modified.grn [[0,2147516032.44891,0.01663732528686523],1]
  date
  Tue Jan 19 12:14:18 UTC 2038
  root@debian:/home/debian/bug1062131# groonga db/test <
  update-last-modified.grn [[0,2147516064.584529,0.01893329620361328],1]

Here is the schema and data:

cat bug1062131.schema 
table_create --name Logs --flags TABLE_NO_KEY
column_create --table Logs --name log --type ShortText
column_create --table Logs --name level --type UInt8
column_create --table Logs --name timestamp --type Time

root@debian:/home/debian/bug1062131# cat load-last-modified.grn 
# cat load-last-modified.grn 
# Time.parse("2024-01-01 00:00:00").to_i
# => 1704034800 
load --table Logs
[
{"_id": 1, "level": 0, "log": "check last_modified in object header",
"timestamp": 1704034800} ]

root@debian:/home/debian/bug1062131# cat update-last-modified.grn 
# Time.parse("2024-02-01 00:00:00").to_i
# => 1706713200 
load --table Logs
[
{"_id": 1, "level": 1, "log": "check last_modified in object header",
"timestamp": 1706713200} ]

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

[Hideki Yamane]

On Tue, 20 Feb 2024 22:59:33 +0900
Hideki Yamane  wrote:
> > Does this happen every time?
> 
>  Yes, at least on my laptop for work (Debian testing).

 I've reproduced it with 
 
https://cdimage.debian.org/mirror/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-gnome.iso



-- 
Hideki Yamane 

Bug#1064294: [Pkg-freeipa-devel] Bug#1064294: bind-dyndb-ldap: FTBFS: error: Install BIND9 development files

[Timo Aaltonen]

Aurelien Jarno kirjoitti 19.2.2024 klo 21.37:

Source: bind-dyndb-ldap
Version: 11.10-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

bind-dyndb-ldap fails to build from source, from my build log on amd64:

| checking for -fvisibility=hidden compiler flag... yes
| checking for -fno-delete-null-pointer-checks compiler flag... yes
| checking for -std=gnu11 compiler flag... yes
| checking for isc-config.sh... no
| checking for working isc-config... no
| configure: WARNING:
|   Could not detect script isc-config.sh. Compilation may fail.
|   Defining variable BIND9_CFLAGS will fix this problem.
|   
| checking for isc_dir_open in -lisc... yes
| checking for dns_name_init in -ldns... no
| configure: error: Install BIND9 development files
|   cd build && tail -v -n \+0 config.log

A full build log is also available on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=bind-dyndb-ldap&arch=riscv64&ver=11.10-6%2Bb2&stamp=1703783350&raw=0

The issue is also visible on the reproducible builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/bind-dyndb-ldap_11.10-6.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/bind-dyndb-ldap_11.10-6.rbuild.log.gz

Regards
Aurelien


This issue could be fixed by changing d/patches/hardcode-version.diff, 
but the real issue is that it won't build against 9.19 at all. Upstream 
has known for a year and hasn't fixed it yet. 9.19 should become stable 
9.20 next month, when I'd assume upstream to fix the build.



--
t

Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

[Sam Hartman]

> "Matthew" == Matthew Vernon  writes:
Matthew> This continues to make me worry we are not on the path of
Matthew> robust engineering. But I appreciate I'm in a very small
Matthew> minority in that regard.

I want to second the above.
I do still believe that the way forward is through rather than by
backing out and starting over.
However, I think it is essential that we spend significant time figuring
out how we can do better with future upgrades and decision processes,
possibly at a point where we have enough distance that we can hear each
other without anger, while not so much distance that we have lost the
technical detail.

As an example, if I had known protective diversions would be part of the
solution back when debating whether merged /usr was something we were
ready to do, I would have said we absolutely were not ready to go down
the path until we had better architected tools.

I'm not proposing to turn around now, and that may possibly be an area
where Matthew and I disagree.  But I absolutely want to lend credibility
to the idea that we are digging ourselves into a hole, hoping that it
will become a tunnel and we will find light at the other end.

--Sam


signature.asc
Description: PGP signature

Bug#1064347: openssh-server: sshd crashes under heavy traffic

[George Kissandrakis]

Package: openssh-server
Version: 1:8.4p1-5+deb11u3
Severity: normal
X-Debbugs-Cc: gkiss...@gmail.com

Dear Maintainer,

   * What led up to the situation?
We have a public facing sftp server for our customers
After upgrading Debian 10 to Debian 11, sshd is crashing under heavy traffic

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried reconfigure timeouts, keepalives etc but none worked

   * What was the outcome of this action?
No change

   * What outcome did you expect instead?
Not sure

Very similar (or the same) with
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2043114


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

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

Versions of packages openssh-server depends on:
ii  adduser3.118+deb11u1
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.13
ii  libaudit1  1:3.0-2
ii  libc6  2.31-13+deb11u8
ii  libcom-err21.46.2-2
ii  libcrypt1  1:4.4.18-4
ii  libgssapi-krb5-2   1.18.3-6+deb11u4
ii  libkrb5-3  1.18.3-6+deb11u4
ii  libpam-modules 1.4.0-9+deb11u1
ii  libpam-runtime 1.4.0-9+deb11u1
ii  libpam0g   1.4.0-9+deb11u1
ii  libselinux13.1-3
ii  libssl1.1  1.1.1w-0+deb11u1
ii  libsystemd0247.3-7+deb11u4
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0
ii  openssh-client 1:8.4p1-5+deb11u3
ii  openssh-sftp-server1:8.4p1-5+deb11u3
ii  procps 2:3.3.17-5
ii  runit-helper   2.10.3
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  247.3-7+deb11u4
ii  ncurses-term 6.2+20201114-2+deb11u2
ii  xauth1:1.1-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

-- Configuration Files:
/etc/pam.d/sshd changed [not included]

-- debconf information excluded
kern.log:Feb 19 22:29:40 ecmif01 kernel: [ 2288.914649] traps: sshd[72022] 
general protection fault ip:7f6b8116d3b7 sp:7fff87eb22f0 error:0 in 
libc-2.31.so[7f6b8110d000+159000]
kern.log:Feb 19 22:46:04 ecmif01 kernel: [ 3272.826055] traps: sshd[98328] 
general protection fault ip:7f5e5c0433b7 sp:7fff4d3109f0 error:0 in 
libc-2.31.so[7f5e5bfe3000+159000]
kern.log:Feb 19 23:14:08 ecmif01 kernel: [ 4956.789461] traps: sshd[152300] 
general protection fault ip:7f62249523b7 sp:7ffc761c4300 error:0 in 
libc-2.31.so[7f62248f2000+159000]
kern.log:Feb 20 01:37:02 ecmif01 kernel: [13531.048898] sshd[437092]: segfault 
at 5618ab5283c8 ip 7f5f0a4a937f sp 7ffd30ac6640 error 4 in 
libc-2.31.so[7f5f0a449000+159000]
kern.log:Feb 20 01:37:02 ecmif01 kernel: [13531.049177] Code: 00 00 eb a3 0f 1f 
80 00 00 00 00 ff d0 eb c5 66 66 2e 0f 1f 84 00 00 00 00 00 90 48 83 ec 08 48 
8b 4f 08 48 89 c8 48 83 e0 f8 <48> 3b 04 07 0f 85 91 00 00 00 48 8b 47 10 48 8b 
57 18 48 3b 78 18
kern.log:Feb 20 02:03:10 ecmif01 kernel: [15098.671459] traps: sshd[488901] 
general protection fault ip:7ff8c0fb23b7 sp:7ffdc8d60140 error:0 in 
libc-2.31.so[7ff8c0f52000+159000]
kern.log:Feb 20 02:13:08 ecmif01 kernel: [15696.975972] sshd[496790]: segfault 
at 562609c87458 ip 7f7645a4c37f sp 7ffe0c52ee90 error 4 in 
libc-2.31.so[7f76459ec000+159000]
kern.log:Feb 20 02:13:08 ecmif01 kernel: [15696.976252] Code: 00 00 eb a3 0f 1f 
80 00 00 00 00 ff d0 eb c5 66 66 2e 0f 1f 84 00 00 00 00 00 90 48 83 ec 08 48 
8b 4f 08 48 89 c8 48 83 e0 f8 <48> 3b 04 07 0f 85 91 00 00 00 48 8b 47 10 48 8b 
57 18 48 3b 78 18
kern.log:Feb 20 04:32:05 ecmif01 kernel: [24033.447133] traps: sshd[759145] 
general protection fault ip:7f6ebe48e3b7 sp:7ffe40a2cf30 error:0 in 
libc-2.31.so[7f6ebe42e000+159000]
kern.log:Feb 20 04:46:01 ecmif01 kernel: [24869.466121] traps: sshd[804956] 
general protection fault ip:7f926c9863b7 sp:7fffdc0400a0 error:0 in 
libc-2.31.so[7f926c926000+159000]
kern.log:Feb 20 05:16:14 ecmif01 kernel: [26682.432389] traps: sshd[871829] 
general protection fault ip:7f4ea598b3b7 sp:7ffd003bccf0 error:0 in 
libc-2.31.so[7f4ea592b000+159000]
kern.log:Feb 20 05:58:09 ecmif01 kernel: [29197.006583] traps: sshd[978131] 
general protection fault ip:7f11eb09c3b7 sp:7ffefa5baaa0 error:0 in 
libc-2.31.so[7f11eb03c000+159000]
kern.log:Feb 20 07:02:05 ecmif01 kernel: [33033.374881] traps: sshd[989] 
general protection fault ip:7fc463ef43b7 sp:7ffe79095300 error:0 in 
libc-2.31.so[7fc463e94000+159000]
kern.log:Feb 20 07:28:04 ecmif01 kernel: 

Bug#1031557: Can't reproduce

[Tino Mettler]

Hi,

I tried to reproduce this by runnung RPD after setting
QT_QPA_PLATFORM=wayland and performing some actions in the GUI, but
everything looks fine in top. I also downgraded to 0.9.33-1.1. I'll try
to get Sway running instead of Gnome and see if this makes a difference.

Regards,
Tino

Bug#1063206: papi: NMU diff for 64-bit time_t transition

[Andreas Beckmann]

On 07/02/2024 23.53, Andreas Beckmann wrote:

Preparing a fix ...


There are now 7.1.0-3 in sid and 7.1.0-4 in experimental. Please verify 
that I correctly extracted the t64 changes from your NMU.


Feel free to upload to sid once the transition requires that.


Andreas

Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

[Russ Allbery]

Sam Hartman  writes:

> However, I think it is essential that we spend significant time figuring
> out how we can do better with future upgrades and decision processes,
> possibly at a point where we have enough distance that we can hear each
> other without anger, while not so much distance that we have lost the
> technical detail.

+1

There were some very important technical and social lessons to be learned
from this whole process, as well as a whole lot of incredibly valuable
research and a greater understanding of some misunderstandings and
fragility in how are full ecosystem of packaging tools fits together.  I
think the only way out for the /usr-merge transition specifically is
through, and until we finish that we're probably not in a good position to
absorb those lessons in a more comprehensive way, but I hope we don't skip
that step.

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

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

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#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#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#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#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#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#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#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#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#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'), (5

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#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#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#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#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#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#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#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#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#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#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#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#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 1

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#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#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#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#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#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&arch=riscv64&ver=0.0%7Egit20231214.ab13479-1&stamp=1707440925&raw=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#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#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#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#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
20

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#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#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#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#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#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#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#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#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#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#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#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#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

[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#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#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#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#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#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#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#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#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#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#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

[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#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#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#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#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]

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#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&suite=sid
[2]: 
https://github.com/horms/kexec-tools/commit/ab3a70af85679bbc5efe63057c7f65365ed6e748

thanks,
Ming

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#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#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