Bug#1076854: ITP: python-juliandate -- Simple conversions between Julian Dates and Julian/Gregorian calendar dates, supporting ancient dates (BCE)

[Enkelena Haxhiu]

Hi Arlisson,

It has been around 1 month and a half since the interest to package
julidandate was expressed from your end, but I did not see the package
uploaded.
Since this is a dependency for another package that I maintain and I
was waiting for a new version from upstream there since August, they
pinged me last week with the new version being ready, thus I had to go
ahead and package juliandate.

I am in the process of finishing it up and it should be ready by the
end of this working week.
When it's published, feel free to talk to me about suggestions or if
you want to upload new versions when they come.

Kind regards,
Enkelena



On Fri, Dec 27, 2024 at 11:08 PM Arlisson Jaques
 wrote:
>
> Okay, thank you very much Enkelena.
>
> I will proceed with the packaging.
>
> Thanks again for the quick response.
>
> Arlisson Jaques.
>
> Em sex., 27 de dez. de 2024 às 17:02, Enkelena Haxhiu  
> escreveu:
>>
>> Hi Arlison,
>>
>> Thanks for reaching out. I am super busy with writing my Master's thesis so 
>> I don't plan to do it for the next month. Please feel free to continue.
>>
>> Kind regards,
>> Enkelena
>>
>>
>> On Fri, 27 Dec 2024, 20:57 Arlisson Jaques,  wrote:
>>>
>>> Hello, how's it going?
>>>
>>> I'm also interested in putting this package on Debian.
>>>
>>> How is the progress? Do you intend to continue?
>>>
>>> I would like to continue because another package I am working on needs this 
>>> in the new upstream version.

Bug#1095640: RM: atig -- ROM; upstream dead, upstream API unavailable

[Youhei SASAKI]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: a...@packages.debian.org, uwab...@gfd-dennou.org
User: ftp.debian@packages.debian.org
Usertags: remove

Atig, Another Twitter IRC gateway, is no longer available due to
changes in the twitter API service.

Bug#1082237: transition: numpy 2

[Emilio Pozuelo Monfort]

On 19/09/2024 15:24, Timo Röhling wrote:

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: nu...@packages.debian.org
Control: affects -1 + src:numpy
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

I'd like to transition NumPy 2 and rebuild all binary Python extensions
against the new version. The current NumPy 2 release is backwards compatible
with NumPy 1, i.e., extensions built against NumPy 2 will continue to work
with NumPy 1.24.x (but not the other way around).

Therefore old binary packages will have "Depends: python3-numpy-abi9", and
rebuilt binary packages will have "Depends: python3-numpy2-abi0 |
python3-numpy-abi9".

Below is a suggested Ben file which looked okay when I tested it locally.
I may have missed some subtle problems though as this is my first hand-written
rule set.


I removed the packages that were failing to build, but there's a few that are 
good in the tracker but are failing their autopkgtests. Some of them don't have 
bugs filed. Can you look at them [1] and file bugs as appropriate?


Cheers,
Emilio

[1] https://tracker.debian.org/pkg/numpy

Bug#1095607: [PATCH] debian: fix lintian warnings: superfluous-file-pattern; closes: bug#1095607

[Matthieu Baerts]

Hi Jonas,

Thank you for your reply!

On 09/02/2025 21:56, Jonas Smedegaard wrote:
> Quoting Matthieu Baerts (NGI0) (2025-02-09 19:57:37)
>> From: Matthieu Baerts 
>>
>> Simply fix the remaining lintian warnings from:
>>
>>   https://udd.debian.org/lintian/?packages=iwd
> 
> I disagree with how lintian parses copyright files.
> 
>>  Files:
>> - */configure
>> + configure
> 
> My intent is to match any file named "configure" at any depth - similar
> to the example */Makefile.in at
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-field

Should it not be "*configure" and "*Makefile.in" then?

According to the same doc...

> Only the wildcards * and ? apply; the former matches any number of
> characters (including none), the latter a single character. Both
> match slashes (/) and leading dots, unlike shell globs. The pattern
> *.in therefore matches any file whose name ends in .in anywhere in
> the source tree, not just at the top level.
... it is a bit confusing: when reading this, it sounds like
"*/configure" means all the "configure" file from any subdirectories. It
should then match "./configure", but maybe it doesn't work like that.

>>  Files:
>> - */Makefile.in
>> + Makefile.in
> 
> This is *exactly* the same as the example in the official definition.

Is it needed to add something to silent the lintian warnings, or should
we just ignore them?

> 
>> - */ylwrap
> 
> This change I agree with - there is indeed no ylwrap file on source.
> 
> I will treat the removal of that one like as solving this bug - because
> the alternative of forking the bugreport, closing one part, and keeping
> the other open with a wontfix tag feels like too much effort for no real
> gain.  But please do tell if you prefer my opposition to lintian parsing
> be more visible, then I'll do the alternative approach.

Fine by me!

Note that I'm fine with only the modification you did. I only shared
this patch because I saw the warnings. It is OK for me to ignore them.

Cheers,
Matt

Bug#1094242: (mini)transition: perl 5.40.1

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

Hi Niko,

On 26/01/2025 13:37, Niko Tyni wrote:

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

Perl 5.40.1 is in experimental, and I think it's ready for unstable +
testing. I expect this is the version we will want to release trixie with.

It is ABI compatible with 5.40.0, but will need five packages to be
rebuilt, because they have strict dependencies on the upstream version
for various reasons [1].

   nmu libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl libcommon-sense-perl 
libdevel-mat-dumper-perl . ANY . -m "Rebuild against Perl 5.40.1." --extra-depends 
'perl-base (>= 5.40.1)'

I have tested the new version on amd64 by rebuilding and running
autopkgtest checks on ~5K related packages and found no regressions.
I don't quite understand why latexml fails on ci.debian.net, but it passes
for me locally. I suspect --add-apt-source or --pin-packages don't work
quite perfectly with build dependency resolution under 'build-needed'.

After more than fifteen years of doing this I'm still not sure about
your preferred process for these minor Perl releases, so I'm erring on
the safe side. Please let me know if/when it's OK to upload to unstable.


This is fine, since it will need binNMUs we can track them in this request. Feel 
free to document it there.


Please go ahead.

Cheers,
Emilio

Bug#1082237: transition: numpy 2

[Timo Röhling]

Hi Emilio,

* Emilio Pozuelo Monfort  [2025-02-10 09:52]:
I removed the packages that were failing to build, but there's a 
few that are good in the tracker but are failing their 
autopkgtests. Some of them don't have bugs filed. Can you look at 
them [1] and file bugs as appropriate?

Yes, will do as soon as possible. Probably this evening or tomorrow.

Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1094405: smp-utils: option parsing broken for smp_discover -p/--phy and -n/--num

[Ritesh Raj Sarraf]

On Mon, 2025-02-10 at 04:27 +0100, Louis Sautier wrote:
> 
> It has now been ~2 weeks since I opened the issue on GitHub and
> almost a 
> month since I emailed the author.
> 
> Could you or another maintainer check my merge request at 
> https://salsa.debian.org/linux-blocks-team/smp-utils/-/merge_requests/4
>  
> please? Having the option parsing code restored would be of great
> help.

Hello Louis,

I've copied some of the other DDs who may have stake in smp-utils. I
personally no more actively maintain these packages but hope to
help/chime in, if I have time.

I've copied Douglas on this email, for what record I have.


I have no idea why you are facing this problem. The changes look fine
to me. They are just standardizing on using a more standard interface
command in REPORT GENERAL. Also, that change is from almost 7 years
ago. From personal experience, as such, if it was a general issue, it'd
have been uncovered widely by now.

I personally wouldn't override the current code with your proposed MR
changes, for I have limited insight of its side-effects.

For you, I guess if this change is a blocker, you could continue to use
the older versions until the cause of this anomaly is sorted out.

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#1095557: reportbug: after an update , the apps indicator menu has disapeared . it makes gnome unusuable .

[alain]

hi guys ,

hi , dear maintainers ,

i made an update .

see what i've got :

of course , there's no result :

apps menu  still not works .

waiting for some ideas or some solutions ...

if you can / know  


@sid:~$ sudo dpkg -l gnome-shell-extension*
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| 
État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements

|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom   Version Architecture 
Description

+++-=---==
un  gnome-shell-extension-appindicator   (aucune 
description n'est disponible)
ii  gnome-shell-extension-apps-menu   47.4-1 all  
Category based app menu for GNOME Shell
ii  gnome-shell-extension-auto-move-windows   47.4-1 all  
GNOME Shell extension to move apps to specific workspaces
un  gnome-shell-extension-dash-to-panel   
(aucune description n'est disponible)
un  gnome-shell-extension-dashtodock   (aucune 
description n'est disponible)
un  gnome-shell-extension-desktop-icons   
(aucune description n'est disponible)
un  gnome-shell-extension-desktop-icons-ng   
(aucune description n'est disponible)
ii  gnome-shell-extension-drive-menu  47.4-1 all  
Removable drive status menu for GNOME Shell
un  gnome-shell-extension-gamemode   (aucune 
description n'est disponible)
ii  gnome-shell-extension-launch-new-instance 47.4-1 all  
GNOME Shell extension to launch new instances of apps
ii  gnome-shell-extension-light-style 47.4-1 all  
GNOME Shell extension to switch the Shell to light style
un  gnome-shell-extension-manager   (aucune 
description n'est disponible)
ii  gnome-shell-extension-native-window-placement 47.4-1 all  
GNOME Shell extension to arrange windows in a more compact way
ii  gnome-shell-extension-places-menu 47.4-1 all  
Places menu for GNOME Shell
ii  gnome-shell-extension-prefs   47.3-1 amd64    
tool to enable / disable GNOME Shell extensions
ii  gnome-shell-extension-screenshot-window-sizer 47.4-1 all  
GNOME Shell extension to resize windows for GNOME Software screenshots
ii  gnome-shell-extension-system-monitor  47.4-1 all  
Display system information in GNOME Shell status bar
un  gnome-shell-extension-taskbar   (aucune 
description n'est disponible)
un  gnome-shell-extension-top-icons-plus   
(aucune description n'est disponible)
ii  gnome-shell-extension-user-theme  47.4-1 all  
GNOME Shell extension to load alternative GNOME Shell themes
ii  gnome-shell-extension-window-list 47.4-1 all  
GNOME Shell extension to display a window list
ii  gnome-shell-extension-windows-navigator   47.4-1 all  
GNOME Shell extension to allow keyboard selection in overlay mode
ii  gnome-shell-extension-workspace-indicator 47.4-1 all  
Workspace indicator for GNOME Shell
un  gnome-shell-extension-workspaces-to-dock   
(aucune description n'est disponible)
ii  gnome-shell-extensions    47.4-1 all  
Extensions to extend functionality of GNOME Shell
ii  gnome-shell-extensions-common 47.4-1 all  
common files for official GNOME Shell extensions




On Sun, 9 Feb 2025 13:55:32 +0100 alain  
wrote:


> pending an update of the packages ,
> I unhold them.
> I don't know if I'm doing the right thing ...
>
> @sid:~$ sudo apt-mark unhold gnome-shell-extension*
> gnome-shell-extension-appindicator était déjà marqué comme non figé.
> gnome-shell-extension-bluetooth-quick-connect était déjà marqué comme
> non figé.
> gnome-shell-extension-impatience était déjà marqué comme non figé.
> gnome-shell-extension-no-annoyance était déjà marqué comme non figé.
> gnome-shell-extensions-extra était déjà marqué comme non figé.
> gnome-shell-extension-gamemode était déjà marqué comme non figé.
> gnome-shell-extension-prefs était déjà marqué comme non figé.
> gnome-shell-extension-dash-to-panel était déjà marqué comme non figé.
> gnome-shell-extension-dashtodock était déjà marqué comme non figé.
> gnome-shell-extension-desktop-icons-ng était déjà marqué comme non figé.
> gnome-shell-extension-top-icons-plus était déjà marqué comme non figé.
> gnome-shell-extension-arc-menu était déjà marqué comme non figé.
> gnome-shell-extension-autohidetopbar était déjà marqué comme non figé.
> gnome-shell-extension-caffeine était déjà marqué comme non figé.
> gnome-shell-extension-easyscreencast était déjà marqué comme non figé.
> gnome-shell-extension-espresso était déjà marqué comme non figé.
> gnome-shell-extension-flypie était déjà marqué comme non figé.
> gnome-shell-extension-freon étai

Bug#1082237: transition: numpy 2

[Andrey Rakhmatullin]

On Mon, Feb 10, 2025 at 09:52:22AM +0100, Emilio Pozuelo Monfort wrote:
> I removed the packages that were failing to build, but there's a few that
> are good in the tracker but are failing their autopkgtests. Some of them
> don't have bugs filed. Can you look at them [1] and file bugs as
> appropriate?

All of them should have bugs filed at this stage, and I've just rechecked
that. The only ones that don't have them are python-soxr (needs a rebuild
but is blocked by a build-dep bug), scikit-learn and spectral-cube (both
fail because of joblib).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1095651: ruby-devise-lastseenable: Could not find 'useragent' (~> 0.16)

[Pirate Praveen]

Package: ruby-devise-lastseenable
Version: 0.0.6-1.1
Severity: serious
X-Debbugs-Cc: prav...@debian.org

Dear Maintainer,

autopkgtest broken with rails 7.

full log
https://ci.debian.net/packages/r/ruby-devise-
lastseenable/unstable/amd64/57495069/


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

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

Versions of packages ruby-devise-lastseenable depends on:
ii  ruby 1:3.3~3.1
pn  ruby-devise  
ii  ruby-rails   2:6.1.7.3+dfsg-4
pn  ruby-warden  

ruby-devise-lastseenable recommends no packages.

ruby-devise-lastseenable suggests no packages.

Bug#1089225: [pkg-apparmor] Bug#1089225: Bug#1089225: apparmor.service can't start due to PROC undeclared

[intrigeri]

Control: tag -1 + moreinfo

Hi,

Unfortunately, as it stands, this bug report is not actionable.

Please:

 - either share *privately* a tarball of your /etc/apparmor.d/
   directory so I can try to reproduce the bug with your configuration

 - or figure out steps to reproduce the bug, starting from a clean
   Debian installation

Thanks in advance!

Cheers,
-- 
intrigeri

Bug#1094349: nml: please replace the runtime dependency on python3-setuptools with a proper python3-pkg-resources

[Matthijs Kooijman]

forwarded 1094349 https://github.com/OpenTTD/nml/issues/340
thanks

Hi Alexandre,

Thanks for reporting this issue.

Upstream has also identified this issue and fixed it upstream, see
https://github.com/OpenTTD/nml/issues/340 and
https://github.com/OpenTTD/nml/pull/341

It seems that some change in newer python triggered this bug, the fix
seems to be to fix escaping of a regex that matches whitespace.

I'll coordinate with upstream to see if they can release this fix soon,
otherwise I'll backport it.

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#1095652: RM: wlroots-0.17 -- ROM; All dependencies migrated to wlroots 0.18.x

[Guido Günther]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

libwlroots-0.17 was reuploaded to new in October as some dependencies
were expected to take longer to migrate to libwlroots-0.18. However the
last remaining one (phoc) was fixed just a couple of days ago (and a
beta version migrated to testing just 3 days ago) so there are no longer
any packages requiring wlroots 0.17 in unstable:

  $ build-rdeps --only-main libwlroots-dev 
  Reverse Build-depends in experimental/main:
  ---
  
  No reverse build-depends found for libwlroots-dev.
  
  Reverse Build-depends in unstable/main:
  ---
  
  No reverse build-depends found for libwlroots-dev.

There are still compositors out there that use 0.17 but none packaged
for Debian so we could take the chance and remove that package.

I intended to request removal of wlroots-0.17 from NEW once phoc 0.45
migrates but since wlroots-0.17 was just accepted to unstable again I
thought I'd rater do so right away.

Cheers,
 -- Guido

Bug#1095646: dracut-core: Shipping /usr/lib/kernel/install.d/50-dracut.install causes two initrds to be installed on kernel postinst

[Mourad De Clerck]

Package: dracut-core
Version: 106-1
Severity: important

As of 106-1 dracut-core is shipping /usr/lib/kernel/install.d/50-dracut.install

The Debian kernel postinst invokes:
- /etc/kernel/postinst.d/dracut which generates an initrd and calls 
kernel-install
- /etc/kernel/postinst.d/zz-systemd-boot which calls kernel-install (and now 
also generates an initrd with different options)

So I end up with two initrds and two "initrd" options in my 
/efi/loader/entries/ file.

It seems we need one or the other. I'm not sure if Debian's initramfs-tools 
will also converge on using systemd's kernel-install, 
but I guess some coordination is needed.

My current workaround is running `dpkg-reconfigure dracut` after kernel 
install, which seems to fix the double initrd in my ESP.

Related to #1091455 and #1082811

Kind regards,

-- Mourad DC


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

Kernel: Linux 6.12.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dracut-core depends on:
ii  cpio2.15+dfsg-2
ii  dracut-install  106-1
ii  e2fsprogs   1.47.2-1
ii  kmod33+20240816-2
ii  libc6   2.40-6
ii  udev257.2-3

Versions of packages dracut-core recommends:
ii  binutils2.44-1
pn  console-setup   
ii  cryptsetup  2:2.7.5-1
pn  dmraid  
ii  dmsetup 2:1.02.201-1
ii  kpartx  0.9.9-1
pn  lvm2
pn  mdadm   
ii  systemd 257.2-3
ii  systemd-cryptsetup  257.2-3
ii  systemd-sysv257.2-3
ii  zstd1.5.6+dfsg-2

dracut-core suggests no packages.

-- no debconf information

Bug#1095643: osmocom-dahdi-linux: -dkms only builds for the running kernel, -source unusable

[Andreas Beckmann]

Source: osmocom-dahdi-linux
Version: 0.0~git20241003.b2ea348-1
Severity: serious

Hi,

src:osmocom-dahdi-linux has a few problems:

The -dkms package only builds for $(uname -r) ignoring any -k arguments
given to dkms. This was not noticed since the package did not have dkms
autopkgtests enabled. The integration of the -dkms package is overly
complicated ... most of that could be handled by dh_dkms.

The -source package is not buildable with module-assistant (and
kernel-package is long gone ...)
While it's possible to make that a valid module-assistant compatible
source package (please see the template in the module-assistant
documentation), I see not much point in doing that for a "new" package
and would rather drop it entirely.

I'm preparing a merge request on salsa fixing these (and a few more)
issues.

Andreas

Bug#1083100: help needed on the Prometheus front

[Jérémy Lal]

Le lun. 10 févr. 2025 à 06:43, Martina Ferrari  a écrit :

> Hi all,
>
> A bit late to the party, but I have just uploaded prometheus 2.53.1 to
> unstable, after a long wait due to the constant problem of outdated or
> missing dependencies.
>
> This is the last LTS (lont-term support) release of the 2.x series, so I
> really wanted to have this in trixie. As things stand, we won't be able
> to upgrade to 3.x in time, plus there is no 3.x LTS release yet; so I
> think this is a good version to include in trixie.
>
> Considering all this, it might be worth seeing if it is possible at all
> to try to build the "old" react UI from source, resorting to vendoring
> in NPM dependencies, as it looks that the lit might not be that long at
> this point. In the last couple of years, I have gained quite a bit of
> experience with JavaScript and NodeJS (on the backend side mostly), but
> I still struggle with the Debian packaging tools. So maybe with a bit of
> help with somebody from the JS team we can try this?
>
> > i *think* the "react-app/" directory is the older implementation,
> which
> > can be disregarded.
>
> This would actually be the one we can try to build, which corresponds to
> the list of dependencies Daniel listed in October.
>
> On 07/10/2024 19:08, Jérémy Lal wrote:
> > I think the proper method will be to mut-bundle as much, and as cleanly,
> > as possible,
>
> Jérémy, could you explain what do you mean by "mut-bundle"? I can't find
> any package name resembling that..
>

A multiple upstream tarball, example of watch file:
https://sources.debian.org/src/node-webfont/11.4.0+dfsg2+~cs35.7.26-10/debian/watch/?hl=12#L12

I'm sure what's the best package to serve as an example of dh-nodejs usage,
however it's good to skim through sources.debian.org, and read
https://wiki.debian.org/Javascript/GroupSourcesTutorial



> > with most packages not re-exported to /usr/share/nodejs, because it is
> > just asking for trouble.
>
> Agreed.


> > There are tools to help in that task, like pkgjs-tools'
> add-node-component.
>
> Would this be using multiple source tarballs? I wonder if that wouldn't
> conflict with the usual workflow where we don't rely on pristine-tar but
> on upstream git history.


I never found a way to make both (m.u.t. and upstream git history) work.
Maybe it's possible, though.

I guess an option could be to package this in a
> separate source package, but I'd like to avoid any extra steps and trips
> to NEW.
>

The simplest solution, by far, is to switch to the other gbp layout
(without git history).

Jérémy

Bug#1095644: casacore: FTBFS: fatal error: numpy/arrayobject.h: No such file or directory

[zhangdandan]

Source: casacore
Version: 3.6.1-5
Severity: normal
Tags: ftbfs patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-CC: debian-loonga...@lists.debian.org

Dear maintainers,

Compiling the casacore failed for loong64 in the Debian Package 
Auto-Building environment.

The error log is as follows,
```
..
In file included from 
/<>/casacore/python/Converters/PycArray.tcc:30,

 from /<>/python/Converters/PycArray.cc:28:
/<>/casacore/python/Converters/PycArrayNP.h:35:10: fatal 
error: numpy/arrayobject.h: No such file or directory

   35 | #include 
  |  ^
compilation terminated.
```

The full build log can be found at 
https://buildd.debian.org/status/fetch.php?pkg=casacore&arch=loong64&ver=3.6.1-5&stamp=1738956862&raw=0.


After analysis, there are 3 findings as follows,
1. for casacore 3.6.1-5 version, built error on loong64.
'-- PYTHON3_NUMPY_INCLUDE_DIRS . = 
/usr/lib/loongarch64-linux-gnu/python3-numpy/numpy/_core/include'

2. For casacore 3.6.1-4, built right on loong64.
'-- PYTHON3_NUMPY_INCLUDE_DIRS . = 
/usr/lib/python3/dist-packages/numpy/core/include'

3. For loong64 or other architectures
numpy/arrayobject.h header file is provided in 
/usr/lib/python3/dist-packages/numpy/core/include/.


There are 2 suggestions:
1. Could you add NumPy in python3/CMakeLists-cmake3.14.txt?
```
@@ -1,6 +1,6 @@
 message(STATUS "Looking for python3 specific environment...")

-find_package(Python3 REQUIRED COMPONENTS Interpreter Development)
+find_package(Python3 REQUIRED COMPONENTS Interpreter Development NumPy)
```
2. Or could you add /usr/lib/python3/dist-packages/numpy/core/include/ 
in d/rules's configure stage?

```
override_dh_auto_configure:
    dh_auto_configure -- -Wno-dev \
..
-DPYTHON3_NUMPY_INCLUDE_DIRS=/usr/lib/python3/dist-packages/numpy/core/include/
```

Based on the first suggestion, there is a patch I attached.
Based on the attached patch, I have built casacore 3.6.1-5 successfully 
on local ENV.

```
  dh_md5sums -O--buildsystem=cmake
   dh_builddeb -O--buildsystem=cmake
dpkg-deb: building package 'libcasa-casa8-dbgsym' in 
'../libcasa-casa8-dbgsym_3.6.1-5_loong64.deb'.
dpkg-deb: building package 'casacore-dev' in 
'../casacore-dev_3.6.1-5_loong64.deb'.

..
```

Your opinions are welcome.

Best regards,
Dandan Zhang

>From bcbb86b867c45324610a73a0fda6cf9e305b44a3 Mon Sep 17 00:00:00 2001
From: Dandan Zhang 
Date: Mon, 10 Feb 2025 10:03:15 +
Subject: [PATCH] casacore add NumPy in CMakeLists-cmake3.14.txt

---
 python3/CMakeLists-cmake3.14.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/python3/CMakeLists-cmake3.14.txt b/python3/CMakeLists-cmake3.14.txt
index 2f7e39f..26d5ca5 100644
--- a/python3/CMakeLists-cmake3.14.txt
+++ b/python3/CMakeLists-cmake3.14.txt
@@ -1,6 +1,6 @@
 message(STATUS "Looking for python3 specific environment...")
 
-find_package(Python3 REQUIRED COMPONENTS Interpreter Development)
+find_package(Python3 REQUIRED COMPONENTS Interpreter Development NumPy)
 
 if (Python3_FOUND)
 find_package(Boost REQUIRED)
-- 
2.47.1

Bug#1095645: ruby-rails-timeago: Could not find 'useragent' (~> 0.16) among 134 total gem(s) (Gem::MissingSpecError)

[Pirate Praveen]

Package: ruby-rails-timeago
Version: 2.19.0-1
Severity: serious
X-Debbugs-Cc: prav...@debian.org

Dear Maintainer,

Broken with rails 7 in experimental - this will be reuploaded to 
unstable soon.


Full log
https://ci.debian.net/packages/r/ruby-rails-timeago/unstable/amd64/57495100/


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

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

Versions of packages ruby-rails-timeago depends on:
pn  libjs-jquery-timeago  
ii  ruby  1:3.3~3.1
ii  ruby-actionpack   2:6.1.7.3+dfsg-4
ii  ruby-activesupport2:6.1.7.3+dfsg-4

ruby-rails-timeago recommends no packages.

ruby-rails-timeago suggests no packages.

Bug#1095648: ruby-js-routes: Could not find 'useragent' (~> 0.16)

[Pirate Praveen]

Package: ruby-js-routes
Version: 1.4.9-1
Severity: serious
X-Debbugs-Cc: prav...@debian.org

Dear Maintainer,

autopkgtest broke with rails 7.

Full log
https://ci.debian.net/packages/r/ruby-js-routes/unstable/amd64/57495088/


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

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

Versions of packages ruby-js-routes depends on:
ii  ruby  1:3.3~3.1
ii  ruby-railties 2:6.1.7.3+dfsg-4
ii  ruby-sprockets-rails  3.5.2-1

ruby-js-routes recommends no packages.

ruby-js-routes suggests no packages.

Bug#1095649: RM: ruby-js-routes -- ROM; rc buggy, unused

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: ruby-js-rou...@packages.debian.org, prav...@debian.org
Control: affects -1 + src:ruby-js-routes
User: ftp.debian@packages.debian.org
Usertags: remove

Originally packaged from diaspora, which is already removed.

Bug#1093620: transition: gnustep-multiarch

[Emilio Pozuelo Monfort]

On 10/02/2025 11:02, Yavor Doganov wrote:

On Mon, 03 Feb 2025 10:53:55 +0200,
Emilio Pozuelo Monfort wrote:

On 02/02/2025 05:14, Yavor Doganov wrote:

So perhaps now is a good time to schedule the biNMUs for level 3.


Scheduled.


Thanks; please schedule the last binNMUs, both with dep-wait on
libgnustep-gui-dev (>= 0.31.1-9):

mpdcon.app
viewpdf.app


Scheduled.


There's one bug remaining to be fixed (#1095275) but it's out of our
hands.  I'll monitor the grep-excuses status and will let you know
when it is time to remove the block hint.  Although it seems that some
additional assistance would be needed...  I don't quite understand why
unar is blocked by gnustep-base which is blocked because unar in
testing has autopkgtest failures.  Shouldn't the migration scripts
figure out that the packages will migrate together and that this
failure is irrelevant?


britney schedules test with as few restrictions as possible. Thus if 
gnustep-base doesn't break unar/testing, then it will be tested against that 
version, because it's possible that gnustep-base migrates and unar doesn't. So 
gnustep-base may need to gain a breaks against unar/testing, and that will also 
help the autopkgtest.


I found other autopkgtest failures, all related to gnustep-dl2/testing 
apparently:

https://tracker.debian.org/pkg/gnustep-gui
https://tracker.debian.org/pkg/gnustep-back
https://tracker.debian.org/pkg/gorm.app

Cheers,
Emilio

Bug#1092659: jpeg-xl builds using GCC 13

[Matthias Klose]

On 09.02.25 23:43, Jeremy Bícha wrote:

Yes, the jpeg-xl s390x build tests fail unless we use gcc 13. I
reverified this today:

https://launchpadlibrarian.net/775617795/buildlog_ubuntu-plucky-s390x.jpeg-xl_0.11.1-1build1_BUILDING.txt.gz

We also opt into gcc 13 on riscv64. That might be unnecessary but I
haven't tested that again yet.

Thank you,
Jeremy Bícha


so the package has a patch to remove failing tests on big endian, but 
still fails in the tests on all big endian targets (except for s390x). 
Is that really a compiler issue, or an upstream issue with unsupported 
big endian targets?

Bug#1095641: ruby-mobile-fu: Could not find 'useragent' (~> 0.16) among 150 total gem(s) (Gem::MissingSpecError)

[Pirate Praveen]

Package: ruby-mobile-fu
Version: 1.4.0+github-4 
Severity: serious
X-Debbugs-Cc: prav...@debian.org

Dear Maintainer,

autopkgtest failed with rails 7 currently in experimental - this will be
uploaded to unstable soon.

full log
https://ci.debian.net/packages/r/ruby-mobile-fu/unstable/amd64/57495091/


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

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

Versions of packages ruby-mobile-fu depends on:
pn  ruby-rack-mobile-detect  
ii  ruby-rails   2:6.1.7.3+dfsg-4

ruby-mobile-fu recommends no packages.

ruby-mobile-fu suggests no packages.

Bug#1095642: ruby-activerecord-import: Unknown key: :unique. Valid keys are: :limit, :precision, :scale, :default, :null, :collation, :comment, :primary_key, :if_exists, :if_not_exists, :as, :type, :s

[Pirate Praveen]

Package: ruby-activerecord-import
Version: 1.5.0-1 Severity: serious
X-Debbugs-Cc: prav...@debian.org

Dear Maintainer,

Broken with rails 7.

Full log
https://ci.debian.net/packages/r/ruby-activerecord-
import/unstable/amd64/57495058/


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

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

Versions of packages ruby-activerecord-import depends on:
ii  ruby-activerecord  2:6.1.7.3+dfsg-4

ruby-activerecord-import recommends no packages.

ruby-activerecord-import suggests no packages.

Bug#1093620: transition: gnustep-multiarch

[Yavor Doganov]

On Mon, 03 Feb 2025 10:53:55 +0200,
Emilio Pozuelo Monfort wrote:
> On 02/02/2025 05:14, Yavor Doganov wrote:
> > So perhaps now is a good time to schedule the biNMUs for level 3.
> 
> Scheduled.

Thanks; please schedule the last binNMUs, both with dep-wait on
libgnustep-gui-dev (>= 0.31.1-9):

mpdcon.app
viewpdf.app

mpdcon.app needs an additional dw on libsqlclient-dev (>= 1.9.0-4).

There's one bug remaining to be fixed (#1095275) but it's out of our
hands.  I'll monitor the grep-excuses status and will let you know
when it is time to remove the block hint.  Although it seems that some
additional assistance would be needed...  I don't quite understand why
unar is blocked by gnustep-base which is blocked because unar in
testing has autopkgtest failures.  Shouldn't the migration scripts
figure out that the packages will migrate together and that this
failure is irrelevant?

Bug#1095650: oakleaf: FTBFS on 32-bit architectures

[Emilio Pozuelo Monfort]

Source: oakleaf
Version: 1.0.0-1
Severity: serious
Tags: ftbfs

Hi,

Your package failed to build on 32-bit architectures. From the armel and
armhf build logs:

| rfun_hampel_real128.f08:59:44:
|
|59 |   elemental pure function pshampel_REAL128(x) result(pshampel)
|   |1
| Error: Symbol 'x' at (1) has no IMPLICIT type


And from the i386 build log:

| noise_real128.f08:91:54:
|
|91 | lnoise = median - mad*sign(1.0_kind,u)*log(1_kind - 2_kind*abs(u))
|   |  1
| Error: Integer kind 16 at (1) not available

Cheers,
Emilio

Bug#1068174: yosys: Please package the latest upstream release

[Scott Ashcroft]

On Mon, 2025-02-10 at 01:03 +0100, Daniel Gröber wrote:
> Hi Scott,
> 
> On Wed, Feb 05, 2025 at 08:28:47PM +, Scott Ashcroft wrote:
> > That was much more difficult than I thought.
> 
> Tell me about it! ;-)
> 
> > The combination of your work and upstream had dealt with all the
> > date/time based stuff. The tex source for the various images which
> > get
> > inserted had the magic:
> > 
> > \pdfinfoomitdate 1
> > \pdfsuppressptexinfo 1
> > \pdftrailerid{}
> > 
> > in them but the .tex file generated by sphinx did not.
> > I've added a patch which modifies the conf.py file to make that
> > happen.
> > Multiple builds in a row now produce manual.pdf with the same
> > checksum.
> 
> Excellent! Can you send the patch upstream or do you want me to?

If you could that would be best as I don't have a github account.

> That all looks good. However. I've now had a closer look at the git
> repo
> and I find you didn't do the upstream import quite right.
> d/README.Source
> documents the correct incantation:
> 
>     $ gbp import-orig --component=abc --uscan

That's exactly what I ran to start everything off.
I forked the project on salsa.
git cloned my fork.
Ran the gbp command as given above.

I suspect that what's gone wrong is that the merge requests only cover
the master branch so you don't see the upstream (and pristine-tar)
branch commits from my fork.

> 
> You see, I don't want to have to trust you didn't smuggle a backdoor
> into
> the huge "new upstream" git commit, I just want to download the
> tarball
> myself and not have to think about that possibility :-)
> 
> For that reason I generally do the import myself and rebase or
> cherry-pick
> commits from contributors. Andreas merging your MRs broke this bit of
> my
> workflow so now I'll have to force push over this.

I really expected my MR not to be merged and that only the useful
changes in debian/ would be picked up.

> Hoping you have a slightly better idea of why things take so darn
> long in
> Debian now. Getting this far took most of my Sunday,
> --Daniel

I really do appreciate the work are you doing and I'm sorry if my ham-
fisted attempts to help have made it more difficult.

Cheers,
Scott
 

Bug#1093620: transition: gnustep-multiarch

[Yavor Doganov]

Emilio Pozuelo Monfort wrote:
> On 10/02/2025 11:02, Yavor Doganov wrote:
> > Thanks; please schedule the last binNMUs, both with dep-wait on
> > libgnustep-gui-dev (>= 0.31.1-9):
> > 
> > mpdcon.app
> > viewpdf.app
> 
> Scheduled.

Thanks.  Hopefully, this should be the last action from your side (the
very last would be the removal of the block hint).

> > Shouldn't the migration scripts figure out that the packages will
> > migrate together and that this failure is irrelevant?
> 
> britney schedules test with as few restrictions as possible.

I see, thanks for the detailed explanation.

> So gnustep-base may need to gain a breaks against unar/testing, and
> that will also help the autopkgtest.
> 
> I found other autopkgtest failures, all related to
> gnustep-dl2/testing apparently:

OK, so we'll make additional uploads of gnustep-base, gnustep-gui,
gnustep-back, gorm.app and gnustep-dl2 with the appropriate breaks.

Bug#1029097: PAM HURD patches

[Svante Signell]

Hello,

I did not see this mail. And I don't know why. It is not easy to
communicate when emails are lost. Same problems with other emails too.

And btw: The OS is not HURD or hurd, it's either GNU/Hurd or just Hurd.

Best regards,
Svante Signell

To: svante.sign...@gmail.com, 1029097-d...@bugs.debian.org
Cc: debian-h...@lists.debian.org
Subject:Re: Bug#1029097: PAM HURD patches
Date:   Fri, 07 Feb 2025 18:05:05 -0700 (08.02.2025 02:05:05)

control: tags -1 wontfix

Hi.
I still have not received an answer to my questions.
Also, the patch as written would not be sufficient to get pam to
compile on hurd.

I don't think our communications strategies work well together.  My
recommendation for getting PAM HURD patches updated are:

* I summarize my thinking on the thread I started about PATHMAX and max
hostname, letting people know what patches I'm open to and what 
patches I'm not.  I'll try to make a response within two weeks.
If you do not hear from me in that time, please prod me until you get a
response.

* A porter other than you prepares a patch.  In that patch if you are
disabling tests, be clear about why the test should be disabled.
I'm likely to accept patches that disable functionality not present on
HURD, but am not likely to accept patches to disable legitimate
failures. Patches can be submitted as a MR against PAM or a new
wishlist bug against PAM.

* I work with the porter and review the patches.

--Sam

> > > > > "Svante" == Svante Signell  writes:

    Svante> reopen 1029097 thanks

Bug#1095654: ITP: python-elasticsearch-transport -- Transport classes and utilities shared among Python Elastic client libraries

[Karsten Schöke]

Package: wnpp
Severity: wishlist
Owner: Karsten Schöke 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-elasticsearch-transport
  Version : 8.17.0
  Upstream Contact: Elastic Client Library Maintainers 
* URL : https://github.com/elastic/elastic-transport-python
* License : Apache 2.0
  Programming Lang: Python
  Description : Transport classes and utilities shared among Python Elastic 
client libraries

This library was lifted from elasticsearch-py and then transformed
to be used across all Elastic services rather than only Elasticsearch.


This is a new dependency of python-elasticsearch
an will be maintained by DPT.

Bug#1068174: yosys: Please package the latest upstream release

[Daniel Gröber]

Hi Scott,

On Mon, Feb 10, 2025 at 11:03:32AM +, Scott Ashcroft wrote:
> If you could that would be best as I don't have a github account.

Alright.

> > That all looks good. However. I've now had a closer look at the git
> > repo
> > and I find you didn't do the upstream import quite right.
> > d/README.Source
> > documents the correct incantation:
> > 
> >     $ gbp import-orig --component=abc --uscan
> 
> That's exactly what I ran to start everything off.
> I forked the project on salsa.
> git cloned my fork.
> Ran the gbp command as given above.
> 
> I suspect that what's gone wrong is that the merge requests only cover
> the master branch so you don't see the upstream (and pristine-tar)
> branch commits from my fork.

Huh. That's possible, but doesn't explain why abc was missing then? Looking
at 581750b0 it seems to be there after all. Where did I pull the 48kLoC
number from then? Weird.

One theory: did you use `gbp clone`? If not some of the relevant branches
might have been missing locally. Maybe gbp fails hillariously when you
don't do that? Unsure.

> I really expected my MR not to be merged and that only the useful
> changes in debian/ would be picked up.
> 
> I really do appreciate the work are you doing and I'm sorry if my ham-
> fisted attempts to help have made it more difficult.

Don't worry about it! I don't say these things to berate you for doing
anything wrong, but merely to explain what's going on and motivate you to
help ;-P

I've been doing this Debian thing for a little while now and I still don't
have a clue, but learning means being comfortable not knowing things (yet).

--Daniel


signature.asc
Description: PGP signature

Bug#1095653: ruby-build: fails test build-ruby-openssl on unstable/armhf

[Lucas Nussbaum]

Source: ruby-build
Version: 20241225.2-1
Severity: serious

Hi,

See
https://ci.debian.net/packages/r/ruby-build/unstable/armhf/

The error message in the build log is:
cc  -I. -Iinclude -Iapps/include  -fPIC -pthread -march=armv7-a 
-Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC 
-DOPENSSLDIR="\"/tmp/autopkgtest.TtHp4o/autopkgtest_tmp/openssl/ssl\"" 
-DENGINESDIR="\"/tmp/autopkgtest.TtHp4o/autopkgtest_tmp/openssl/lib/engines-3\""
 
-DMODULESDIR="\"/tmp/autopkgtest.TtHp4o/autopkgtest_tmp/openssl/lib/ossl-modules\""
 -DOPENSSL_BUILDING_OPENSSL -DZLIB -DZLIB_SHARED -DNDEBUG  -MMD -MF 
apps/lib/libapps-lib-app_rand.d.tmp -MT apps/lib/libapps-lib-app_rand.o -c -o 
apps/lib/libapps-lib-app_rand.o apps/lib/app_rand.c
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
make[1]: *** [Makefile:4291: apps/lib/libapps-lib-app_params.o] Error 1

I think that what happens is:
* the 'build-ruby-openssl' test builds the ruby interpreter with a
  vendored openssl (not the system one), so first it builds openssl
  (3.0.15)
* openssl's configure results in explicitely using -march=armv7-a
  (rather than using the compiler's default, which would be
  -march=armv7-a+fp)
* but the code being compiled has FP instructions
* so GCC refuses to compile that code

Those links sound relevant:
1/ https://github.com/checkpoint-restore/criu/issues/1653

> Starting with gcc-11, Debian's armhf compiler no longer builds with a
> default -mfpu= option. Instead it enables the FPU via an extension to
> the -march flag (--with-arch=armv7-a+fp). criu's Makefile explicitly
> passes its own -march=armv7-a setting, which overrides the +fp
> default, so we end up with no FPU:
>   cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU

This was fixed with 
https://salsa.debian.org/debian/criu/-/commit/55d4dc414e6542c69c4fae95d31160256d726013

2/ https://github.com/openssl/openssl/issues/21630 (closed)
The last comment is:
> I've read the note several times but the behaviour of Configure does
> not seem to match it. Rather than actually leaving the options open,
> it adds the -march=armv7-a. If it had just picked the base linux-armv4
> target, things would have been fine.


So, this is not going to be fixed in openssl. This could be worked
around in ruby-build.

Lucas

Bug#761511: Suggested patch

[Mark Hindley]

Control: tags -1 patch

Hi,

Sorry for the extended wait for a resolution to this.

I suspect the /dev/run -> /run/shm migration is pretty much done now, but I
suggest the following to ensure the warning is only printed when /dev/shm
actually appears in /etc/fstab.

Mark


commit 1b9c9ee5b8bb8968c5dbee93555699ad6f25056c
Author: Mark Hindley 
Date:   Mon Feb 10 11:08:37 2025 +

Only warn about old /dev/shm mount if it is actually present in /etc/fstab.

Closes: #761511

diff --git a/debian/src/initscripts/lib/init/mount-functions.sh 
b/debian/src/initscripts/lib/init/mount-functions.sh
index 4348ecfa..02a5ea3f 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -384,7 +384,9 @@ run_migrate ()
if [ ! -L "$OLD" ] && [ -d "$OLD" ] ; then
if [ "$OLD" != "/tmp" ]; then
log_warning_msg "Filesystem mounted on $OLD; setting up 
compatibility bind mount."
-   log_warning_msg "Please remove this mount from 
/etc/fstab; it is no longer needed, and it is preventing completion of the 
transition to $RUN."
+   if read_fstab_entry "$OLD" ; then
+   log_warning_msg "Please remove this mount from 
/etc/fstab; it is no longer needed, and it is preventing completion of the 
transition to $RUN."
+   fi
fi
mount -t $FSTYPE "$RUN" "$OLD" $OPTS
else

Bug#1094487: patroni: pg_clonecluster_patroni fails: Error: cluster configuration already exists

[Ben Harris]

On Mon, 10 Feb 2025, Michael Banck wrote


Hi,

On Wed, Jan 29, 2025 at 07:01:00PM +, Ben Harris wrote:

On Wed, 29 Jan 2025, Ben Harris wrote


I tried to reproduce the reinit failure, but it always worked for me.
Not sure what is different on your side :-/


I could send you the recipe my clusters use, but it's thousands of lines 
of Ansible and probably not very portable.  Do you have a simple test 
recipe that I might be able to reproduce?  Then I might be able to work 
out where the difference is.



I would suggest that the proper fix here is to insert the missing '/' and
move the "rm" command back to being after the "pg_dropcluster" command. Or
just drop the "rm" command entirely.


I did the former now in the salsa git repo, however, that will only be
part of the 4.0.x releases.


Thank you!

--
Ben Harris, University of Cambridge Information Services.

Bug#1095662: yadifa: Uses ANY queries to find A or AAAA records

[Kevin]

Package: yadifa
Severity: normal
Tags: upstream ipv6
X-Debbugs-Cc: deb...@kevinsteen.net

Dear Maintainer,

When queried for a CNAME record, yadifa tries to locate relevant A and 
records by sending an ANY query to the external nameserver. These now fail at
most servers and should be replaced by A and  queries. (Observed with
v2.6.4-1 in bookworm)

-Kevin


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

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

Versions of packages yadifa depends on:
ii  adduser 3.134
ii  debconf 1.5.82
ii  libc6   2.36-9+deb12u9
ii  libssl3 3.0.15-1~deb12u1
pn  libssl3t64  
ii  netbase 6.4

yadifa recommends no packages.

yadifa suggests no packages.

Bug#1093611: transition: urdfdom and dart

[Emilio Pozuelo Monfort]

On 10/02/2025 13:50, Jose Luis Rivero wrote:

Thanks Emilio. I've uploaded urdfdom and dart to unstable.

Note: the new dart version does not support 32bits architectures anymore so
we probably need to remove armel, armhf and i386 binary packages from
unstable.


Please file a bug using `reportbug ftp.debian.org`, that'll get it removed on 
the necessary architectures.


Cheers,
Emilio

Bug#1095663: ITP: r-cran-flexdashboard -- R Markdown Format for Flexible Dashboards

[Juri Grabowski]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-flexdashboard -- R Markdown Format for Flexible Dashboards
Package: wnpp
Owner: Juri Grabowski 
Severity: wishlist

* Package name: r-cran-flexdashboard
  Version : 0.6.2
  Upstream Author : Garrick Aden-Buie ,
* URL : https://cran.r-project.org/package=flexdashboard
* License : MIT
  Programming Lang: GNU R
  Description : R Markdown Format for Flexible Dashboards
 Format for converting an R Markdown document to a grid
 oriented dashboard. The dashboard flexibly adapts the size of it's
 components to the containing web page.

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

Bug#1094950: MR is prepared

[Roland Clobus]

Hello maintainers,

I've prepared a MR for this:
https://salsa.debian.org/live-team/live-tasks/-/merge_requests/8

With kind regards,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1094487: patroni: pg_clonecluster_patroni fails: Error: cluster configuration already exists

[Michael Banck]

Hi,

On Mon, Feb 10, 2025 at 12:43:54PM +, Ben Harris wrote:
> On Mon, 10 Feb 2025, Michael Banck wrote
> > I tried to reproduce the reinit failure, but it always worked for me.
> > Not sure what is different on your side :-/
> 
> I could send you the recipe my clusters use, but it's thousands of lines of
> Ansible and probably not very portable.  Do you have a simple test recipe
> that I might be able to reproduce?  Then I might be able to work out where
> the difference is.

I tried the following simple ansible playbook:

https://github.com/credativ/ansible-playbook-patroni-debian/

After bootstrapping the cluster, a patronictl reinit worked (but I do
see those 'Use of uninitialized value' warnings):

|Feb 10 14:01:41 pg1 patroni@14-main[6097]: 2025-02-10 14:01:41,096 INFO: no 
action. I am (pg1), a secondary, and following a leader (pg2)
|Feb 10 14:01:43 pg1 patroni@14-main[6097]: 2025-02-10 14:01:43,679 INFO: 
Removing data directory: /var/lib/postgresql/14/main
|Feb 10 14:01:43 pg1 patroni@14-main[6147]: Use of uninitialized value 
$data_directory in concatenation (.) or string at /usr/share/perl5/PgCommon.pm 
line 284.
|Feb 10 14:01:43 pg1 patroni@14-main[6147]: Use of uninitialized value 
$data_directory in concatenation (.) or string at /usr/share/perl5/PgCommon.pm 
line 284.
|Feb 10 14:01:43 pg1 patroni@14-main[6147]: Use of uninitialized value 
$data_directory in concatenation (.) or string at /usr/share/perl5/PgCommon.pm 
line 284.
|Feb 10 14:01:43 pg1 patroni@14-main[6147]: Warning: corrupted cluster: data 
directory does not exist
|Feb 10 14:01:45 pg1 patroni@14-main[6097]: 2025-02-10 14:01:45,218 INFO: 
replica has been created using pg_clonecluster
|Feb 10 14:01:45 pg1 patroni@14-main[6097]: 2025-02-10 14:01:45,219 INFO: 
bootstrapped from leader 'pg2'

What I don't see is the "INFO: trying to bootstrap from leader 'foo'"
message you mentioned, but maybe that is due to me using 4.0.x (but it
is still there in the HA loop code). Maybe your work-flow is different?


Michael

Bug#1092509: nml: FTBFS: make[3]: *** [Makefile:24: 001_action8] Error 1

[Matthijs Kooijman]

forwarded 1092509 https://github.com/OpenTTD/nml/issues/340
thanks

Hi Lucas,

Thanks for reporting this issue.

Upstream has also identified this issue and fixed it upstream, see
https://github.com/OpenTTD/nml/issues/340 and
https://github.com/OpenTTD/nml/pull/341

It seems that some change in newer python triggered this bug, the fix
seems to be to fix escaping of a regex that matches whitespace.

I'll coordinate with upstream to see if they can release this fix soon,
otherwise I'll backport it.

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#1068032: stimfit 0.16.4-1.1 packaged for debian

[Matthias Klumpp]

Am Mo., 10. Feb. 2025 um 07:43 Uhr schrieb Christoph Schmidt-Hieber
:
> > On 9 Feb 2025, at 20:31, Matthias Klumpp  wrote:
> >
> > It looks like in order to get stimfit back into the next Debian
> > release, it will unfortunately also need to be ported from sip4 to
> > sip6, as sip4 does not work with Python 3.12+ anymore...
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648 which is
> > currently holding up the migration of stimfit.
> >
>
> Fixed:
> https://github.com/neurodroid/stimfit/commit/705cb1e2
>
> > For the next upload, it would also be nice to provide an icon for the
> > desktop-entry file, so the AppStream error goes away:
> > https://appstream.debian.org/sid/main/issues/stimfit.html
> > (you may even want to switch to only using the desktop-entry file,
> > dropping the menu file)
> >
>
> Done:
> https://github.com/neurodroid/stimfit/commit/85ab2247
>
> Should I prepare a new package version?

Yes, please! This totally warrants a new upload :-)
Thanks for all the work, that's super nice! You can also make the
upload "medium" priority, that's the new default (and would be totally
find here, so the package migrates to testing again a bit faster).

Cheers,
Matthias

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

Bug#1095613: dovecot-core: Upgrade to 2.4.0 for trixie/sid

[Noah Meyerhans]

> Dovecot 2.4.0 has been much anticipated and is released.
> Announcement: 
> https://dovecot.org/mailman3/archives/list/dovecot-n...@dovecot.org/thread/UYNR6GBP25XEGFCS633SWPR4HXV3NSS3/
> Upgrade Details: 
> https://doc.dovecot.org/2.4.0/installation/upgrade/2.3-to-2.4.html
> 
> Includes built-in full-text-indexing, better security options, UTF8 support 
> improvements and more.
> Some breaking config changes are in there as well.
> 
> Would love to see 2.4.0 in testing and ultimately in trixie.

This in the works (see [1] and [2]), but the config file changes cause
some problems.  The fact that upstream doesn't provide a working example
config equivalent to the one provided with 2.3.x does help.  If you'd
like to contribute, porting the old default config to the new version
would be extremely helpful.

noah

1. https://salsa.debian.org/debian/dovecot/-/merge_requests/43
2. https://salsa.debian.org/debian/dovecot/-/tree/pkg-rename?ref_type=heads

Bug#1095668: ITP: r-cran-shinywidgets -- Custom Inputs Widgets for Shiny

[Juri Grabowski]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-shinywidgets -- Custom Inputs Widgets for Shiny
Package: wnpp
Owner: Juri Grabowski 
Severity: wishlist

* Package name: r-cran-shinywidgets
  Version : 0.8.7
  Upstream Author : Victor Perrier ,
* URL : https://cran.r-project.org/package=shinyWidgets
* License : GPL-3
  Programming Lang: GNU R
  Description : Custom Inputs Widgets for Shiny
 Collection of custom input controls and user interface components
 for 'Shiny' applications. Give your applications a unique and
 colorful style !

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

Bug#1095667: curl: Numbers in content types in --form field cause mysterious error.

[Colm Buckley]

Package: curl
Version: 8.11.1-1~bpo12+1
Severity: normal
X-Debbugs-Cc: c...@tuatha.org

Dear Maintainer,

Attempting to specify "application/x-pkcs12" as the content type for a file
upload form field causes a seemingly irrelevant error:

$ echo > localfile
$ curl -F 'field=@localfile;type=application/x-pkcs12' https://www.google.com/
curl: (26) Failed to open/read local data from file/application

while using eg: "application/json" works fine:

$ echo > localfile
$ curl -F 'field=@localfile;type=application/x-pkcs12' https://www.google.com/
<... an error message from Google's endpoint, as expected ...>

It *seems* to be the numbers in the content-type it is objecting to; if I try
types without numbers, like "type=application/x-pkcs" it seems to work but 
"type=1"
fails.

I am guessing that some regular expression in the argument parser is failing to
extract the full type of the form field and is terminating on a non-alphabetic
character?

Colm

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

Kernel: Linux 6.12.9+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages curl depends on:
ii  libc62.36-9+deb12u9
ii  libcurl3-gnutls  8.11.1-1~bpo12+1
ii  zlib1g   1:1.2.13.dfsg-1

curl recommends no packages.

curl suggests no packages.

-- no debconf information

Bug#1095669: ITP: r-cran-sunburstr -- Sunburst 'Htmlwidget'

[Juri Grabowski]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-sunburstr -- Sunburst 'Htmlwidget'
Package: wnpp
Owner: Juri Grabowski 
Severity: wishlist

* Package name: r-cran-sunburstr
  Version : 2.1.8
  Upstream Author : Kent Russell ,
* URL : https://cran.r-project.org/package=sunburstR
* License : MIT
  Programming Lang: GNU R
  Description : Sunburst 'Htmlwidget'
 Make interactive 'd3.js' sequence sunburst diagrams in R with the
 convenience and infrastructure of an 'htmlwidget'.

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

Bug#1095655: util-linux: Please package exch

[Jörg Behrmann]

On Mon, Feb 10, 2025 at 02:57:47PM +0100, Chris Hofstaedtler wrote:
> How important is `exch`? Is it a tool that is really essential, and
> should thus be in the "util-linux" package, which is installed on
> each and every Debian installation?
> 
> I've been avoiding adding new stuff to "util-linux" to avoid
> bloating it even more.
> 
> Can it land in util-linux-extra, which is at least only
> pseudo-Essential? Or some other package, like bsdutils or
> bsdextrautils (not the best names)?
> 

It could in principle also go to util-linux-extra, but it would be a nice
addition in the default set. Looking at other distros, Arch, CentOS 10 Stream
(and therefore once it trickles down its downstreams RHEL, Alma und Rocky), and
openSUSE Tumbleweed ship it by default. In the spirit of fewer differences
between distros that necessitate fallback codepaths, it would make sense to add
this.

Also, it is rather small:

> $ du /usr/bin/exch
> 16/usr/bin/exch

> Regarding your merge request: this seems to miss installing man
> pages into the appropriate packages.
> 

Updated the MR, hopefully that should be enough.


signature.asc
Description: PGP signature

Bug#1095673: darkradiant ftbfs with GCC 15 and precompiled headers turned off

[Matthias Klose]

Package: src:darkradiant
Version: 3.9.0-1

darkradiant ftbfs with GCC 15 and precompiled headers turned off. 
Trying to look for compiler errors, but when turning off the percompiled 
headers, the package fails to build.


Please could you forward that upstream? I can't access the bug tracker.


Configuring with -DCMAKE_DISABLE_PRECOMPILE_HEADERS=ON

/home/packages/tmp/darkradiant-3.9.0/libs/render/CamRenderer.h:65:28: 
error: invalid use of incomplete type ‘using 
std::__shared_ptr_accessfalse>::element_type = class Shader’ {aka ‘class Shader’}
   65 | mergeShader->addRenderable(renderable, 
localToWorld);

  |^~
In file included from 
/home/packages/tmp/darkradiant-3.9.0/include/inode.h:5,
 from 
/home/packages/tmp/darkradiant-3.9.0/include/iselectiontest.h:6,
 from 
/home/packages/tmp/darkradiant-3.9.0/include/iinteractiveview.h:3,
 from 
/home/packages/tmp/darkradiant-3.9.0/include/icameraview.h:4,
 from 
/home/packages/tmp/darkradiant-3.9.0/include/imousetoolevent.h:3,
 from 
/home/packages/tmp/darkradiant-3.9.0/include/imousetool.h:6,
 from 
/home/packages/tmp/darkradiant-3.9.0/include/imousetoolmanager.h:3,
 from 
/home/packages/tmp/darkradiant-3.9.0/radiant/camera/CameraWndManager.h:6:
/home/packages/tmp/darkradiant-3.9.0/include/irenderable.h:7:7: note: 
forward declaration of ‘using std::__shared_ptr_access__gnu_cxx::_S_atomic, false, false>::element_type = class Shader’ {aka 
‘class Shader’}

7 | class Shader;
  |   ^~
/home/packages/tmp/darkradiant-3.9.0/libs/render/CamRenderer.h:71:46: 
error: invalid use of incomplete type ‘using 
std::__shared_ptr_accessfalse>::element_type = class Shader’ {aka ‘class Shader’}
   71 | 
_shaders.primitiveHighlightShader->addRenderable(renderable, localToWorld);

  |  ^~
/home/packages/tmp/darkradiant-3.9.0/include/irenderable.h:7:7: note: 
forward declaration of ‘using std::__shared_ptr_access__gnu_cxx::_S_atomic, false, false>::element_type = class Shader’ {aka 
‘class Shader’}

7 | class Shader;
  |   ^~
/home/packages/tmp/darkradiant-3.9.0/libs/render/CamRenderer.h:76:41: 
error: invalid use of incomplete type ‘using 
std::__shared_ptr_accessfalse>::element_type = class Shader’ {aka ‘class Shader’}
   76 | 
_shaders.faceHighlightShader->addRenderable(renderable, localToWorld);

  | ^~
/home/packages/tmp/darkradiant-3.9.0/include/irenderable.h:7:7: note: 
forward declaration of ‘using std::__shared_ptr_access__gnu_cxx::_S_atomic, false, false>::element_type = class Shader’ {aka 
‘class Shader’}

7 | class Shader;
  |   ^~
/home/packages/tmp/darkradiant-3.9.0/radiant/camera/CameraSettings.cpp: 
In member function ‘void ui::CameraSettings::importDrawMode(int)’:
/home/packages/tmp/darkradiant-3.9.0/radiant/camera/CameraSettings.cpp:146:9: 
error: ‘GlobalRenderSystem’ was not declared in this scope; did you mean 
‘RenderSystem’?

  146 | GlobalRenderSystem().setShaderProgram(
  | ^~
  | RenderSystem
/home/packages/tmp/darkradiant-3.9.0/radiant/camera/CameraSettings.cpp:148:29: 
error: incomplete type ‘RenderSystem’ used in nested name specifier

  148 | ? RenderSystem::SHADER_PROGRAM_INTERACTION
  | ^~
/home/packages/tmp/darkradiant-3.9.0/radiant/camera/CameraSettings.cpp:149:29: 
error: incomplete type ‘RenderSystem’ used in nested name specifier

  149 | : RenderSystem::SHADER_PROGRAM_NONE
  | ^~~

Bug#1095672: g10k :FTBFS:build failed ( -race is not supported on linux/*)

[Yue Gui]

Source:  g10k
Version:  0.9.9-2
Severity: serious
Tags: FTBFS, patch

Dear g10k maintainer,
The package g10k build failed on most arch.The crucial buildd log below:
```

dh_auto_build -- -race -ldflags "-X main.buildversion=0.9.9 -X
main.buildtime=1739129287"
cd obj-riscv64-linux-gnu && go install -trimpath -v -p 4 -race
-ldflags "-X main.buildversion=0.9.9 -X main.buildtime=1739129287"
github.com/xorpaul/g10k
-race is not supported on linux/riscv64
dh_auto_build: error: cd obj-riscv64-linux-gnu && go install -trimpath
-v -p 4 -race -ldflags "-X main.buildversion=0.9.9 -X
main.buildtime=1739129287" github.com/xorpaul/g10k returned exit code
2
make[1]: *** [debian/rules:11: override_dh_auto_build] Error 25
make[1]: Leaving directory '/build/reproducible-path/g10k-0.9.9'
make: *** [debian/rules:25: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
exit status 2

```
The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=g10k&arch=riscv64&ver=0.9.9-2&stamp=1739167351&raw=0
My solution to this issue:
  This issue arises because the "-race" flag is only supported on amd64,
arm64, ppc64el, and s390x. Therefore, my solution is to remove the "-race"
flag on unsupported architectures.  The debpatch is in the attachment. I
have tested that locally,and it works well.Please let me know whether this
solution can be accepted.
Gui-Yue
Best  Regards


fix_-race_issue.patch
Description: Binary data

Bug#950095: ITP: pyout -- interface for writing structured records as a table in a terminal

[Boyuan Yang]

On Tue, 28 Jan 2020 16:48:58 -0500 Yaroslav Halchenko  
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Yaroslav Halchenko 
> 
> * Package name    : pyout
>   Version : 0.5.0
>   Upstream Author : Kyle Meyer 
> * URL : https://github.com/pyout/pyout
> * License : MIT/X
>   Programming Lang: Python
>   Description : interface for writing structured records as a table in a 
>terminal
> 
> pyout is a Python package that defines an interface for writing
> structured records as a table in a terminal. It is being developed to replace
> custom code for displaying tabular data in in ReproMan and DataLad.
> .
> A primary goal of the interface is the separation of content from style
> and presentation. Current capabilities include
> .
>  - automatic width adjustment and updating of previous values
>  - styling based on a field value or specified interval
>  - defining a transform function that maps a raw value to the displayed value
>  - defining a summary function that generates a summary of a column (e.g., 
>value totals)
>  - support for delayed, asynchronous values that are added to the table as 
>they come in
> 
> 
> This package is needed for other upcoming ITPs, and eventually might
> also be used in already existing packages (e.g. datalad)
> 
> The plan is to team maintain it within Debian Python Modules Team, since 
> pyout is
> of general utility.

As the new version of con-duct ( https://tracker.debian.org/pkg/con-duct ) 
needs it,
I am uploading it as https://salsa.debian.org/python-team/packages/python-pyout 
.

Thanks,
Boyuan Yang


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

Bug#1095664: RM: dart [armel armhf i386] -- ANAIS; dart 6.13.2 does not support 32bits

[Jose Luis Rivero]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dart
User: ftp.debian@packages.debian.org
Usertags: remove

The new dart 6.13.2 in unstable does not support 32 bits architectures.

Explicit upstream message for this:
https://github.com/dartsim/dart/issues/1671#issuecomment-1200457339

There is also an static assertion for 32 bits systems on memory size:
https://github.com/dartsim/dart/blob/release-6.13/dart/common/PoolAllocator.cpp#L47-L49

Bug#1093611: transition: urdfdom and dart

[Jose Luis Rivero]

On Mon, Feb 10, 2025 at 1:55 PM Emilio Pozuelo Monfort 
wrote:

> On 10/02/2025 13:50, Jose Luis Rivero wrote:
> > Thanks Emilio. I've uploaded urdfdom and dart to unstable.
> >
> > Note: the new dart version does not support 32bits architectures anymore
> so
> > we probably need to remove armel, armhf and i386 binary packages from
> > unstable.
>
> Please file a bug using `reportbug ftp.debian.org`, that'll get it
> removed on
> the necessary architectures.
>

Thanks for the pointer. I created #1095664

Bug#1095657: RM: ruby-ammeter -- ROM; rc buggy, unused

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: ruby-amme...@packages.debian.org, prav...@debian.org
Control: affects -1 + src:ruby-ammeter
User: ftp.debian@packages.debian.org
Usertags: remove

Its only reverse build dependency ruby-rspec-rails dropped the build-depends in
the last update.

Bug#1085722: apt-listchanges: displays all old entries for some packages

[Vincent Lefevre]

On 2025-02-10 12:41:34 +0100, Vincent Lefevre wrote:
> I've also been seeing old entries for some packages, for instance,
> concerning packages of gcc-mingw-w64 source today.
> 
> The currently installed version of one of these packages:
> 
> cventin:~> dpkg -s gcc-mingw-w64-i686
[...]
> Source: gcc-mingw-w64 (26.7)
> Version: 13.3.0-12+26.7
> [...]
[...]

BTW, like Raphaël, I think I also saw the same issue on the linux and
gcc-defaults source packages (but not always).

There is something in common for these 3 cases: the version of the
binary packages does not match the version of the corresponding source
package. I'm wondering whether this may confuse apt-listchanges.

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

Bug#1095661: autopkgtest: Virtualization backends shipped by other backends

[Christian Kastner]

Source: autopkgtest
Version: 5.43
Severity: wishlist

Dear autopkgtest maintainers,

(re-submitting as a bug, as my original mail to autopkgtest@package.d.o
probably didn't surface where I expected it to)

pkg-rocm-tools [1] is (resp: was, accepted today) sitting in NEW and
contains a feature that I only now realize I probably should have
cleared beforehand with you.

Intro: this package contains a collection of scripts that facilitate
using AMD GPUs in rootless containers and VMs.

To this end, it also ships:

/usr/bin/autopkgtest-virt-podman+rocm
/usr/bin/autopkgtest-virt-qemu+rocm

These are simple wrappers around the respective autopkgtest backends.
The wrappers add a few options, take care of setup, etc. For example,
the following will attach the GPU on PCI slot 03:00.0 to the VM, and
perform various checks (is it assigned to VFIO for pass-through, does
the user have the right permissions, etc.):

   $ autopkgtest -B rocrand -- qemu+rocm --gpu 03:00.0 
unstable-autopkgtest-amd64.img

I uploaded pkg-rocm-tools to main as we consider it stable, it is
generally useful, and most importantly has a helper script for any other
Debian contributor to easily run autopkgtests against AMD GPUs in our
infra. This has been requested a few times now.

But having used this naturally for so long, it didn't occur to me in
time that I should have checked whether shipping this in effectively the
autopkgtest namespace would be OK with you.

I would appreciate your feedback on the matter. Is this approach
acceptable to you? If not, can you suggest another approach to which
you would be more amenable?

I'm leaving the package in experimental, pending resolution.

Best,
Christian

PS: We've been using this for more than a year on our own CI [2] which
runs a number of forked and new components [3].

[1]: https://salsa.debian.org/rocm-team/pkg-rocm-tools
[2]: https://ci.rocm.debian.net/
[3]: 
https://salsa.debian.org/rocm-team/rocm-team-infra/-/blob/master/doc/Software-in-our-infra.md

Bug#1084814: Possible solution

[Roland Clobus]

Hello,

The package 'systemsettings' is added to the live images due to 'kio6' 
which effectively comes from 'calamares-settings-debian' (which is a Qt 
program).


I've locally tried the following:
Add 'Conflicts: systemsettings' to the live-tasks-gnome package.

Since we probably are the only users of this package, a 'Conflicts' 
section will not break the setup of other people.
However, it would prevent a (theoretical) combined GNOME-KDE image from 
working properly.


If the 'Conflicts' option would be acceptable, some other non-Qt-based 
desktops might benefit as well.


With kind regards,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1083022: closed by Debian FTP Masters (reply to Yves-Alexis Perez ) (Bug#1083022: fixed in tumbler 4.18.2-1)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2025-02-10 at 11:47 +, mag...@autistici.org wrote:
> Hi Yves-Alexis, hi Helmut!
> 
> @Helmut: I'm writing to you too because Yves-Alexis raised
> the severity of the bug to serious and Yves-Alexis is asking
> below if this does apply to stable too.

Hey, small clarification: Helmut was the one raising the severity, I was
asking if it was considered serious in stable as well (I'm not sure about the
intended cross-buildability/crossgradability of stable).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmep/WAACgkQ3rYcyPpX
RFuOrQgAgMRu1mK6fp0zeCdWLtTsP1i4Hd3Gbe2B6dtyhzBRoX4HSI3p3Rw3suQQ
o69tcV1NC/z1BrLHSCoPzcJrxVd9iOaDNdx5ofFA7Vhalf/Bj4P7o0IyeNiG3zcu
/n5lpWS+GbP40Z7j6OrRwD3ep/jD7nYVtIr0F1zdhJydcDxmUG3xiT/J8UN4Uptx
4DyWGLCJxvp5sGZwTF+JYFHcZLuwKniTTbAkjNArvvCYQf7HiDxuR8VkWEoTYIeu
ayOpwoREOTxR5MbSGICFMUISjtLDo74acYIXhJ/tAmOKb+/T3S6Tb52bOWjTvb1d
uu/2Rur6/tQ/MQdXlKy4bSekgj5n9Q==
=YeNg
-END PGP SIGNATURE-

Bug#744215: wvdial: Segmentation fault during modem initialization

[Chris Hofstaedtler]

Hi,

On Mon, Feb 10, 2025 at 12:02:09AM +, Felix wrote:
> Package: wvdial
> Version: 1.61-8
> Followup-For: Bug #744215
> X-Debbugs-Cc: fizo...@hotmail.com
> 
> Everything was working fine in bookworm, and even in trixie at the
> start. Some update (perhaps rfcomm?) may have eventually caused this
> segmentation fault... 

It seems unlikely that bug #744215 from 2014 would be the same thing
as what you are seeing in 2025. Please open a new bug and provide
all details, including a full log, backtrace and your config and so
on.

Without details this is not actionable.

Chris

Bug#1095667: curl: Numbers in content types in --form field cause mysterious error.

[Colm Buckley]

Package: curl
Version: 8.11.1-1~bpo12+1
Followup-For: Bug #1095667
X-Debbugs-Cc: c...@tuatha.org

This seems to be https://github.com/curl/curl/issues/15761 upstream.
Note it's a fairly serious bug.

Bug#1095670: orange3: needs patches for numpy 2 compatibility

[Stuart Prescott]

Source: orange3
Version: 3.38.1-2
Severity: serious
Justification: FTBFS
X-Debbugs-Cc: stu...@debian.org

Dear Maintainer,

The orange3 package needs patches for numpy 2 compatibility.

I spotted this upstream patch which appears to be enough:

https://github.com/biolab/orange3/commit/3517623b26322a1a7c3f8a05653d25e29cadba8d

Once orange3 is fixed for numpy 2, orange-spectroscopy can then be
uploaded.

Additionally, the tests for orange3 are neither run at build time nor in
the autopkgtest tests (despite the included autopkgtest script) - that
is why the incompatibility with numpy 2 was not discovered until now. The
following additional build-deps are needed (at least) to allow the
unittests to run; they don't all pass even with these extra packages:

python3-httpx python3-pyqt6.qtsvg python3-orange-canvas-core
python3-orange-widget-base python3-pyqtgraph python3-opentsne
python3-pyqt5.qtsvg xvfb xauth

regards
Stuart

Bug#1068032: stimfit 0.16.4-1.1 packaged for debian

[Christoph Schmidt-Hieber]

> On 10 Feb 2025, at 14:28, Matthias Klumpp  wrote:
>
> Am Mo., 10. Feb. 2025 um 07:43 Uhr schrieb Christoph Schmidt-Hieber
> :
>>> On 9 Feb 2025, at 20:31, Matthias Klumpp  wrote:
>>>
>>> It looks like in order to get stimfit back into the next Debian
>>> release, it will unfortunately also need to be ported from sip4 to
>>> sip6, as sip4 does not work with Python 3.12+ anymore...
>>> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648 which is
>>> currently holding up the migration of stimfit.
>>>
>>
>> Fixed:
>> https://github.com/neurodroid/stimfit/commit/705cb1e2
>>
>>> For the next upload, it would also be nice to provide an icon for the
>>> desktop-entry file, so the AppStream error goes away:
>>> https://appstream.debian.org/sid/main/issues/stimfit.html
>>> (you may even want to switch to only using the desktop-entry file,
>>> dropping the menu file)
>>>
>>
>> Done:
>> https://github.com/neurodroid/stimfit/commit/85ab2247
>>
>> Should I prepare a new package version?
>
> Yes, please! This totally warrants a new upload :-)
> Thanks for all the work, that's super nice! You can also make the
> upload "medium" priority, that's the new default (and would be totally
> find here, so the package migrates to testing again a bit faster).


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

Christoph

Bug#1095674: halt.5: Some remarks and a patch with editorial changes for this man page

[Bjarni Ingi Gislason]

Package: initscripts
Version: 3.13-1
Severity: minor
Tags: patch

   * What led up to the situation?

 Checking for defects with a new version

test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z < "man 
page"

  [Use "groff -e ' $' -e '\\~$' " to find obvious trailing spaces.]

  ["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).

  [The fate of "test-nroff" was decided in groff bug #55941.]

   * What was the outcome of this action?

an.tmac::1: style: .TH missing fourth argument; consider package/project 
name and version (e.g., "groff 1.23.0")
troff::18: warning: trailing space in the line
troff::23: warning: trailing space in the line


   * What outcome did you expect instead?

 No output (no warnings).

-.-

  General remarks and further material, if a diff-file exist, are in the
attachments.


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

Kernel: Linux 6.12.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages initscripts depends on:
ii  sysv-rc 3.13-1
ii  sysvinit-utils  3.13-1

Versions of packages initscripts recommends:
ii  e2fsprogs 1.47.2-1
ii  psmisc23.7-1
ii  util-linux-extra  2.40.4-3

initscripts suggests no packages.

-- Configuration Files:
/etc/default/halt changed [not included]
/etc/init.d/hwclock.sh changed [not included]

-- no debconf information
Input file is halt.5

Output from "mandoc -T lint  halt.5": (shortened list)

  2 input text line longer than 80 bytes: This manual page is ...
  1 input text line longer than 80 bytes: You should have rece...
  3 whitespace at end of input line

-.-.

Output from "test-groff -mandoc -t -ww -z halt.5": (shortened list)

  2 trailing space in the line

-.-.

Remove space characters (whitespace) at the end of lines.
Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".

Number of lines affected is

3

-.-.

Wrong distance between sentences in the input file.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

Mark a final abbreviation point as such by suffixing it with "\&".

Some sentences (etc.) do not begin on a new line.

21:brought down. This is the default.
26:down. What exactly this means depends on your hardware.
47:This manual page 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.

-.-.

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.

Line 45, length 243

This manual page is free software; you can redistribute it and/or modify it 
under the terms of the GNU General Public License as published by the Free 
Software Foundation; either version 2 of the License, or (at your option) any 
later version.

Line 47, length 236

This manual page 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.

Line 49, length 202

You should have received a copy of the GNU General Public License along with 
this manual page; if not, write to the Free Software Foundation, Inc., 59 
Temple Place, Suite 330, Boston, MA 02111\-1307 USA


-.-.

Add a zero (0) in front of a decimal fraction that begins with a period
(.)

8:.IP "" .5i

-.-.

Put a parenthetical sentence, phrase on a separate line,
if not part of a code.
See man-pages(7), item "semantic newline".


halt.5:12:Comments (starting with '#') are also allowed.
halt.5:45:This manual page is free software; you can redistribute it and/or 
modify it under the terms of the GNU General Public License as published by the 
Free Software Foundation; either version 2 of the License, or (at your option) 
any later version.

-.-.


FSF office address update.  See
https://lists.gnu.org/archiv

Bug#1095677: lowmem installer UI frames start getting corrupted (UTF-8 as cp437(?)) after first stage of install (@ scanning install media stage)

[наб]

Package: debian-cd
Severity: normal

Hi!

Reported by a friend, I'm reproing in QEMU
(> 4G; truncate -s 4G 4G; qemu-system-x86_64 -enable-kvm -smp 2 -m 500m -cdrom 
debian-testing-amd64-netinst.iso 4G -bios /usr/share/ovmf/OVMF.fd
 and non-lowmem with -m 2g)
but platform probably irrelevant;
happens on debian-12.5.0-amd64-netinst.iso
   debian-12.9.0-amd64-netinst.iso
   debian-testing-amd64-netinst.iso (dated 2025-02-10 11:30)

Please see attached jpeg.
Repro by just mashing through all the defaults.

This looks like it corresponds to the switch from cp437 box-drawing frames
(M-DM-DM-DM-D) to the thin UTF-8 ones 
(M-^CM-^TM-^@M-^CM-^TM-^@M-^CM-^TM-^@M-^CM-^TM-^@)
(sorry the d-i busybox doesn't have od, cat -A is the best I could do).

AFAICT, there's no reason for this to happen: all the processes have
LANG=C.UTF-8, which does exist regardless of the mode,
so it's not an incidental bad reinterpretation of UTF-8 box-drawing
characters as bytes in the C locale in some writer process or whatever
(but then I can hardly probe all the incidental processes for LANG[UAGE]/LC_* 
with /proc/environ;
 pulling in strace confirms C.UTF-8 works).

The VT is -iutf8 by default; stty -F /dev/tty0 -iutf8 and clicking
through for a redraw fixes it,
but non-lowmem doesn't need this to transition properly.

I've exhausted everything I could think of to dissect this outside-in,
the particular mechanics of d-i here are opaque to me.

Best,


signature.asc
Description: PGP signature

Bug#1095678: ruby-actionpack: Dependency change not corrected in Gemfile

[Jörg-Volker Peetz]

Package: ruby-actionpack
Version: 2:6.1.7.3+dfsg-11
Severity: serious

Dear Lucas Nussbaum,

the change of dependency on ruby-rack-session to "| ruby-rack (<< 3)" is not
corrected in the Gemfile
/usr/share/rubygems-integration/all/specifications/actionpack-6.1.7.3.gemspec
. Installation breaks the bundle configuration for , e.g., redmine with
the message

>  Could not find compatible versions
>
>  Because every version of rails depends on actionpack = 6.1.7.3
>and every version of actionpack depends on rack-session >= 1.0.1,
>every version of rails requires rack-session >= 1.0.1.
>  So, because rack-session >= 1.0.1 could not be found in locally installed 
gems
>and Gemfile depends on rails ~> 6.1.7,
>version solving has failed.

Regards,
Jörg.

Bug#1095674: halt.5: Some remarks and a patch with editorial changes for this man page

[Mark Hindley]

Control: tags -1 pending

Bjarni,

On Mon, Feb 10, 2025 at 03:46:46PM +, Bjarni Ingi Gislason wrote:
> Package: initscripts
> Version: 3.13-1
> Severity: minor
> Tags: patch
Queued in git for the next upload.

Thanks.

Mark

Bug#1091774: qt6-base-dev-tools: moc sometimes segfaults on armhf

[Philip Rinn]

Hi,

just another data point: for gImageReader this happens on the first 
build (and with a different error message):


https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/gimagereader.html

> [...]

AutoMoc subprocess error

The moc process failed to compile
  "SRC:/qt/src/Config.hh"
into
  "SRC:/build-qt/gimagereader_autogen/Y3SAW5HENG/moc_Config.cpp"
Process was terminated by signal 11

Command
---
/usr/lib/qt6/libexec/moc -DENABLE_VERSIONCHECK=0 "-DGETTEXT_PACKAGE=\"gimagereader\"" -DHAVE_ENCHANT2 
"-DMANUAL_DIR=\"/usr/share/doc/gimagereader\"" "-DPACKAGE_NAME=\"gImageReader\"" "-DPACKAGE_REVISION=\"\"" 
"-DPACKAGE_VERSION=\"3.4.2\"" -DQT_CONCURRENT_LIB -DQT_CORE5COMPAT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG 
-DQT_NO_DEBUG_OUTPUT -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -I/build/reproducible-path/gimagereader-3.4.2/common 
-I/build/reproducible-path/gimagereader-3.4.2/build-qt -I/usr/include/leptonica -I/usr/include/enchant-2 -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include 
-I/usr/include/sysprof-6 -I/usr/include/podofo -I/usr/include/QtSpell-qt6 -I/usr/include/poppler/qt6 -I/usr/include/poppler -I/build/reproducible-path/gimagereader-3.4.2/qt/src 
-I/build/reproducible-path/gimagereader-3.4.2/qt/src/hocr -I/usr/include/QuaZip-Qt6-1.4 -I/usr/include/QuaZip-Qt6-1.4/quazip -I/usr/include/arm-linux-gnueabihf/qt6/QtCore 
-I/usr/include/arm-linux-gnueabihf/qt6 -I/usr/lib/arm-linux-gnueabihf/qt6/mkspecs/linux-g++ -I/usr/include/arm-linux-gnueabihf/qt6/QtCore5Compat 
-I/usr/include/arm-linux-gnueabihf/qt6/QtWidgets -I/usr/include/arm-linux-gnueabihf/qt6/QtGui -I/usr/include/arm-linux-gnueabihf/qt6/QtNetwork 
-I/usr/include/arm-linux-gnueabihf/qt6/QtDBus -I/usr/include/arm-linux-gnueabihf/qt6/QtXml -I/usr/include/arm-linux-gnueabihf/qt6/QtPrintSupport 
-I/usr/include/arm-linux-gnueabihf/qt6/QtConcurrent -I/usr/include -I/usr/include/c++/14 -I/usr/include/arm-linux-gnueabihf/c++/14 -I/usr/include/c++/14/backward 
-I/usr/lib/gcc/arm-linux-gnueabihf/14/include -I/usr/local/include -I/usr/include/arm-linux-gnueabihf --include 
/build/reproducible-path/gimagereader-3.4.2/build-qt/gimagereader_autogen/moc_predefs.h --output-dep-file -o 
/build/reproducible-path/gimagereader-3.4.2/build-qt/gimagereader_autogen/Y3SAW5HENG/moc_Config.cpp /build/reproducible-path/gimagereader-3.4.2/qt/src/Config.hh

> [...]

Best,
Philip

Bug#1095679: ITP: r-cran-gistr -- Work with 'GitHub' 'Gists'

[Juri Grabowski]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gistr -- Work with 'GitHub' 'Gists'
Package: wnpp
Owner: Juri Grabowski 
Severity: wishlist

* Package name: r-cran-gistr
  Version : 0.9.0
  Upstream Author : Scott Chamberlain ,
* URL : https://cran.r-project.org/package=gistr
* License : MIT
  Programming Lang: GNU R
  Description : Work with 'GitHub' 'Gists'
 Work with 'GitHub' 'gists' from 'R' (e.g.,
 ,
 ). A 
'gist'
 is simply one or more files with code/text/images/etc. This package allows
 the user to create new 'gists', update 'gists' with new files, rename files,
 delete files, get and delete 'gists', star and 'un-star' 'gists', fork 'gists',
 open a 'gist' in your default browser, get embed code for a 'gist', list
 'gist' 'commits', and get rate limit information when 'authenticated'. Some
 requests require authentication and some do not. 'Gists' website:
 .

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

Bug#1095680: ITP: r-cran-hiddenmarkov -- Hidden Markov Models

[Juri Grabowski]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-hiddenmarkov -- Hidden Markov Models
Package: wnpp
Owner: Juri Grabowski 
Severity: wishlist

* Package name: r-cran-hiddenmarkov
  Version : 1.8
  Upstream Author : David Harte ,
* URL : https://cran.r-project.org/package=HiddenMarkov
* License : GPL-2+
  Programming Lang: GNU R
  Description : Hidden Markov Models
 Contains functions for the analysis of Discrete Time Hidden Markov
 Models, Markov Modulated GLMs and the Markov Modulated Poisson Process.
 It includes functions for simulation, parameter estimation, and the
 Viterbi algorithm. See the topic "HiddenMarkov" for an introduction to
 the package, and "Change Log" for a list of recent changes. The
 algorithms are based of those of Walter Zucchini.

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

Bug#1095682: cirrus_drv.so: undefined symbol: vgaHWFreeHWRec

[Julien Plissonneau Duquène]

Package: xserver-xorg-video-cirrus
Version: 1:1.6.0-1
Severity: important
X-Debbugs-Cc: sre4e...@free.fr

Dear Maintainers,

This driver currently fails to load on trixie with the following error:

[51.396] (EE) Failed to load /usr/lib/xorg/modules/drivers/cirrus_drv.so: 
/usr/lib/xorg/modules/drivers/cirrus_drv.so: undefined symbol: vgaHWFreeHWRec
[51.396] (EE) Failed to load module "cirrus" (loader failed, 0)

This emulated CLGD 5446 is the default graphics device used by libvirt/qemu
VMs, and is currently used by the Debian Vagrant boxes.

I will attach a Vagrantfile later for testing.

Best regards,

-- 
Julien Plissonneau Duquène


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 173 Feb 10 17:08 test.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 6.12.10-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-14 (Debian 14.2.0-14) 14.2.0, GNU ld (GNU Binutils for 
Debian) 2.43.50.20250108) #1 SMP PREEMPT_DYNAMIC Debian 6.12.10-1 (2025-01-18)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 4435 Feb 10 17:08 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[51.387] 
X.Org X Server 1.21.1.15
X Protocol Version 11, Revision 0
[51.387] Current Operating System: Linux testing 6.12.10-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.12.10-1 (2025-01-18) x86_64
[51.387] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.12.10-amd64 
root=UUID=8a0ea76d-9e4b-4249-96ea-f5f937edf4a2 ro consoleblank=0 elevator=noop 
scsi_mod.use_blk_mq=Y net.ifnames=0 biosdevname=0
[51.387] xorg-server 2:21.1.15-2 (https://www.debian.org/support) 
[51.387] Current version of pixman: 0.44.0
[51.387]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[51.387] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[51.387] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 10 17:08:23 
2025
[51.388] (==) Using config directory: "/etc/X11/xorg.conf.d"
[51.388] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[51.388] (==) No Layout section.  Using the first Screen section.
[51.388] (**) |-->Screen "Screen0" (0)
[51.388] (**) |   |-->Monitor ""
[51.388] (**) |   |-->Device "Device0"
[51.388] (==) No monitor specified for screen "Screen0".
Using a default monitor configuration.
[51.388] (**) Allowing byte-swapped clients
[51.388] (==) Automatically adding devices
[51.388] (==) Automatically enabling devices
[51.388] (==) Automatically adding GPU devices
[51.388] (==) Automatically binding GPU devices
[51.388] (==) Max clients allowed: 256, resource mask: 0x1f
[51.388] (WW) The directory "/usr/share/fonts/X11/misc" does not exist.
[51.388]Entry deleted from font path.
[51.388] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[51.388]Entry deleted from font path.
[51.388] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[51.388]Entry deleted from font path.
[51.388] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[51.388]Entry deleted from font path.
[51.388] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[51.388]Entry deleted from font path.
[51.388] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[51.388]Entry deleted from font path.
[51.388] (==) FontPath set to:
/usr/share/fonts/X11/Type1,
built-ins
[51.388] (==) ModulePath set to "/usr/lib/xorg/modules"
[51.388] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[51.388] (II) Loader magic: 0x55e4ab328f20
[51.388] (II) Module ABI versions:
[51.388]X.Org ANSI C Emulation: 0.4
[51.388]X.Org Video Driver: 25.2
[51.388]X.Org XInput driver : 24.4
[51.388]X.Org Server Extension : 10.0
[51.389] (++) using VT number 7

[51.389] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[51.389] (II) xfree86: Adding drm device (/dev/dri/card0)
[51.389] (II) Platform probe for 
/sys/devices/pci:00

Bug#977546: Still An Issue

[Barak A. Pearlmutter]

I just tried to delete all but one full backup from a remote which had
a successful full backup followed by some successful incrementals then
a failed incremental due to space exhaustion ... and it deleted
everything. Everything. Target directory was empty, not a single file.

This is with duplicity 3.0.3.2-1.

It seems like a pretty serious issue, because it could cause silent
data loss, and the whole point of duplicity is to avoid data loss.

Bug#1094603: [PATCH] debian: network-manager-iwd: remove conflict with wpasupplicant; closes: bug#1094603

[Jonas Smedegaard]

Quoting Matthieu Baerts (2025-02-09 23:49:37)
> 9 Feb 2025 22:15:50 Jonas Smedegaard :
> > Quoting Matthieu Baerts (NGI0) (2025-02-09 19:56:27)
> >> iwd doesn't provide all the same features as the ones from
> >> wpa_supplicant, especially everything not related to the Wireless world,
> >> e.g. Ethernet authentication (bug#956457), or some more specific
> >> features like MACsec.
> >>
> >> wpa_supplicant and iwd can then be used in parallel, for different
> >> purposes.
> >
> > When you install only the iwd package, then you can also install the
> > wpasupplicant package, and carefully configure them to not step on each
> > others' toes.
> >
> > What the package network-manager-iwd offers is relieving the user of
> > manual configuration: It is ensured that iwd works together with
> > network-manager, but since network-manager recommends wpasupplicant,
> > it is not adequate to provide a network-manager config snippet, because
> > wpasupplicant will still be installed and will in its default
> > configuration interfere with the default configuration of iwd.
> 
> I see, but in fact, thanks to the config file provided by this package,
> at the next reboot, NM will use iwd and leave wpasupplicant alone.
> So no conflicts.
> 
> iwd is just one WiFi backend that is loaded after having read the config.
> NM will not try to use both at the same time.

I might be wrong, but my understanding (and as I recall my personal
experience as well) is not a problem of which helper tool
network-manager interacts with, but instead that wpasupplicant by
default loads itself as a daemon which somehow (listening to same
socket, I guess) causes iwd to fail to load or operate reliably.

See https://wiki.debian.org/NetworkManager/iwd for related info.

> > Thanks for the proposal, but I disagree with this one.
> 
> (I think there is a small mixed-up in the changelog file, because it is
> saying the opposite, but that's a detail :) )

What mixup, more specifically?  I like perfect changelogs. :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1095607: [PATCH] debian: fix lintian warnings: superfluous-file-pattern; closes: bug#1095607

[Matthieu Baerts]

Hi Jonas,

On 10/02/2025 18:07, Jonas Smedegaard wrote:
> Quoting Matthieu Baerts (2025-02-10 09:55:34)
>> On 09/02/2025 21:56, Jonas Smedegaard wrote:
>>> Quoting Matthieu Baerts (NGI0) (2025-02-09 19:57:37)
 Simply fix the remaining lintian warnings from:

   https://udd.debian.org/lintian/?packages=iwd
>>>
>>> I disagree with how lintian parses copyright files.
>>>
  Files:
 - */configure
 + configure
>>>
>>> My intent is to match any file named "configure" at any depth - similar
>>> to the example */Makefile.in at
>>> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-field
>>
>> Should it not be "*configure" and "*Makefile.in" then?
> 
> No, that would be too broad to also cover e.g. a file "myconfigure".

Indeed. Then maybe lintian expect two entries then when there are files
in the root dir, and subdirectories (which is not the case here with iwd):

  configure## only the root dir
  */configure  ## from subdirectories (but there are none there)

But well, fine not to change anything here. The ticket is closed and
that's OK for me!

> 
>> According to the same doc...
>>
>>> Only the wildcards * and ? apply; the former matches any number of
>>> characters (including none), the latter a single character. Both
>>> match slashes (/) and leading dots, unlike shell globs. The pattern
>>> *.in therefore matches any file whose name ends in .in anywhere in
>>> the source tree, not just at the top level.
>> ... it is a bit confusing: when reading this, it sounds like
>> "*/configure" means all the "configure" file from any subdirectories. It
>> should then match "./configure", but maybe it doesn't work like that.
>>
  Files:
 - */Makefile.in
 + Makefile.in
>>>
>>> This is *exactly* the same as the example in the official definition.
>>
>> Is it needed to add something to silent the lintian warnings, or should
>> we just ignore them?
> 
> In my view, silencing lintian implies that lintian is wrong specifically
> which is not the case: I believe lintian is wrong generally.  When I (or
> you?) find the energy to file a bugreport against lintian about the
> issue, it makes sense to be to silence the noise with a reference to
> said bugreport - see debian/source/lintian-overrides for how I do that
> for another similar long-standing issue.

I see, thank you for the explanation! Then such warnings can be easily
ignored!

> 
>> Note that I'm fine with only the modification you did. I only shared
>> this patch because I saw the warnings. It is OK for me to ignore them.
> 
> ...and I am happy that you did - having fresh eyes on things is great!
Great! :)

Cheers,
Matt

Bug#1095683: impossible to install: depends on missing package librust-databake-0.2-dev

[Jonas Smedegaard]

Package: librust-litemap-dev
Version: 0.7.4-1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

librust-litemap-dev is impossible to install: depends on missing package
librust-databake-0.2-dev.

In future, please use the experimental suite for new packages, and only
introduce into unstable when package is believed usable (the word
"unstable" refers to the suite, not each package).

 - Jonas


-BEGIN PGP SIGNATURE-

wsG7BAEBCgBvBYJnqjkyCRAsfDFGwaABIUcUAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmez3zviTEw9QujbTgIXdV5rAvyVmIZQlVepmqBUEL/+
BBYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAADIVw/9H0PsI9pvl+OyPwFDJRmRKvau
L1Z+na7NiutEqIeEH5JMpn05HkedG53Y/QgsxglFAtbmaYYcknf7MqeQSF+UT0Sn
iKYNy32o+UPMJDwCCADfVIjCzFidheRAf1Dxoht2C997jGraW/js1UsdRfDmU92L
O7Q/cjC62/5eTxi04f7VriWkg8Y1xVa8VEB3T9n5pWifAN0KppG+vupzAY+Wb+8h
VJVxTsfb5rOpN34sCAzt7ToI99xSQlWIF01UF2FhwKxSbk6amAO+e3sMs0A6tC8S
z8ZYubA9vyYAD+K3I6gf48p77yoO4B6zSSk7kzYGuUozVMWUe3+7KY5rpdn37W2F
dJaAYT6bXAJwrTGdy7Zig5Iv1Plq8hxemAkwR+D/mBkaK3sPSf+K+/FDqTtl0QxR
OPDY2I0CWUOAddi2CXBDGd0NomYhDS7dVLWAGKOsJfZ1T6/+VYeVKdpQMtlkO9Cb
HNWB3Hb7KG8jo2jdMlwyfMGAhGLjsgiPHIzo5dP+ZiXBvFpdCLHABFHWeAgsrKR0
ePeYdltDCQN4/iDuLu9k5U23dG9S4BRaVVLBo/jJz3sODZGn/CMP6QspUbHSo7FA
mjxebUc1BQFn5vyxa95iYEGxImlVKd1m+CeVo6QmpGV5EXD3RpqekFNj33KMOAy4
OLg1cEQUwAQE4+gCIEc=
=yGYe
-END PGP SIGNATURE-

Bug#1084134: python3-dogtail: sniff fails to start on Wayland (No module named 'ponytail')

[intrigeri]

Control: tag -1 + patch

Hi,

intrigeri (2024-12-12):
> intrigeri (2024-10-08):
 I can't find such ponytail package in Debian archive, and I found the 
 gnome-
 ponytail-daemon [2] project online but I'm not sure that's the correct 
 upstream
 source.
 I understand that it should be packaged and added as a required dependency 
 for
 python3-dogtail?
>>>
>>> Yes. Contribution welcome ;)
>>
>> I'll come back to it in a month or so to see if we can help. But if
>> anyone else has the skills & bandwidth, by all means, please go ahead
>> and don't wait for us.
>
> FTR we at Tor/Tails have decided to fund this work:
>
>   https://bugs.debian.org/1088917

ponytail is now in testing/sid.

I've prepared a MR that adds a dependency:
https://salsa.debian.org/debian/dogtail/-/merge_requests/2

Feel free to downgrade to Recommends, I did not check carefully which
one would be best, and I trust you know the use cases for Dogtail in
Debian better than I do.

Cheers,
-- 
intrigeri

Bug#1095676: hosts_access.5: Some remarks and a patch with editorial changes for this man page

[Bjarni Ingi Gislason]

Package: libwrap0
Version: 7.6.q-35
Severity: minor
Tags: patch

   * What led up to the situation?

 Checking for defects with a new version

test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z < "man 
page"

  [Use "groff -e ' $' -e '\\~$' " to find obvious trailing spaces.]

  ["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).

  [The fate of "test-nroff" was decided in groff bug #55941.]

   * What was the outcome of this action?

an.tmac::1: style: .TH missing third argument; consider document 
modification date in ISO 8601 format (-MM-DD)
an.tmac::1: style: .TH missing fourth argument; consider package/project 
name and version (e.g., "groff 1.23.0")

   * What outcome did you expect instead?

 No output (no warnings).

-.-

  General remarks and further material, if a diff-file exist, are in the
attachments.


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

Kernel: Linux 6.12.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libwrap0 depends on:
ii  libc6  2.40-6

libwrap0 recommends no packages.

libwrap0 suggests no packages.

-- no debconf information
Input file is hosts_access.5

Output from "mandoc -T lint  hosts_access.5": (shortened list)

  1 fill mode already disabled, skipping: nf
  1 missing date, using "": TH
  8 whitespace at end of input line

-.-.

Output from "test-groff -mandoc -t -ww -z hosts_access.5": (shortened list)

  9 trailing space in the line

-.-.

Remove space characters (whitespace) at the end of lines.
Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".

Number of lines affected is

9

-.-.


Use "\e" to print the escape character instead of "\\" (which gets
interpreted in copy mode).

353:in.tftpd: ALL: (/usr/sbin/safe_finger -l @%h | \\

-.-.


Change a HYPHEN-MINUS (code 0x2D) to a minus(-dash) (\-),
if it
is in front of a name for an option,
is a symbol for standard input,
is a single character used to indicate an option,
or is in the NAME section (man-pages(7)).
N.B. - (0x2D), processed as a UTF-8 file, is changed to a hyphen
(0x2010, groff \[u2010] or \[hy]) in the output.

138:built with -DPARANOID (default mode), it drops requests from such
140:without -DPARANOID when you want more control over such requests.
353:in.tftpd: ALL: (/usr/sbin/safe_finger -l @%h | \\
354:/usr/bin/mail -s %d-%h root) &

-.-.

Add a comma (or \&) after "e.g." and "i.e.", or use English words
(man-pages(7)).
Abbreviation points should be protected against being interpreted as
an end of sentence, if they are not, and that independent of the
current place on the line.

234:most, i.e. when the client system has been compromised.  In general,

-.-.

Wrong distance between sentences in the input file.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

Mark a final abbreviation point as such by suffixing it with "\&".

Some sentences (etc.) do not begin on a new line.

N.B.

  The number of lines affected can be too large to be in a patch.

7:name, host name/address) patterns.  Examples are given at the end. The
12:\fIhosts_options\fR(5) document. \fBNote that this language supersedes
17:a host requesting service. Network daemon process names are specified
20:The access control software consults two files. The search stops
32:file. Thus, access control can be turned off by providing no access
36:lines are processed in order of appearance. The search terminates when a
40:character. This permits you to break up long lines so that they are
72:A string that begins with a `.\' character. A host name is matched if
77:A string that ends with a `.\' character. A host address is matched if
83:(formerly YP) netgroup name. A host name is matched if it is a host
84:member of the specified netgroup. Netgroup matches are not supported
90:`net/mask\' pair. An IPv4 host address is matched if `net\' is equal to the
91:bitwise AND of the address and the `mask\'. For example, the net/mask
102:`[net]/prefixlen\' pair. An IPv6 host address is matched if
10

Bug#1089580: visualvm: JVM crashes with StackOverflowError at startup

[Julien Plissonneau Duquène]

Control: tags -1 - moreinfo

Hi,

While trying to craft a Vagrantfile to reproduce this it appeared that I 
misdiagnosed the issue in multiple ways. The packaged visualvm actually 
runs fine with the default JDK when the JDK 11 is not installed.


The issue can be reproduced by installing a JDK 11 on a Trixie system. 
I'm attaching a Vagrantfile [1] for testing.


The `visualvm` startup script ignores JAVA_HOME and uses the JDK 11 if 
it's installed on the system rather than the default JDK and I didn't 
notice this before filing this bug report.


It is possible to work around this issue either by using the --jdkhome 
CLI argument, or by adding a configuration file, e.g.:
echo visualvm_jdkhome=/usr/lib/jvm/default-java > 
~/.visualvm/2.1.10/etc/visualvm.conf


Le 2025-02-04 14:26, Tobias Wich a écrit :


The start script /usr/bin/visualvm has code which always selects Java 
11, when installed. When changing line 80 as follows, it starts 
properly with Java 21.


- for j in /usr/lib/jvm/java-11-openjdk-$ARCH 
/usr/lib/jvm/default-java; do

+ for j in /usr/lib/jvm/default-java; do


I don't think the hardcoded path for the JDK 11 in the launcher script 
is still necessary. The modification suggested above should be enough to 
close this bug.


For the record:
- removing -Djava.security.manager=allow from the java invocation makes 
it possible to run visualvm with the JDK 11. On my system it is usable, 
but on the VM with a 16bpp depth the graphical rendering is unusable 
(windows only show a uniform plain color), reconfiguring the X server 
for a 24bpp depth makes visualvm/JDK11 usable again
- setting the property above is required to run visualvm with the 
default JDK 21 (with deprecation warnings though); runs fine with 16bpp 
and 24bpp depths
- there is probably an underlying bug either in the JDK 11 or in 
visualvm that causes the JVM to crash when the (required for JDK21) 
property is defined.


Thanks,


[1]: https://salsa.debian.org/-/snippets/773

--
Julien Plissonneau Duquène
# Usage: vagrant up --provider=libvirt

Vagrant.configure("2") do |config|
  config.vm.box = "debian/testing64"
  config.vm.box_version = "0"
  #config.vm.box_version = "20250126.1"
  # Note: 
https://vagrantcloud.com/debian/boxes/testing64/versions/20250126.1/providers/libvirt/amd64/vagrant.box
  #   fails with 429 Too Many Requests
  #   -> download with a browser from:
  #   
https://portal.cloud.hashicorp.com/vagrant/discover/debian/testing64/versions/20250126.1
  #   and run:
  #   vagrant box add --provider libvirt --name "debian/testing64" 
--checksum 073c794a90187cff320096c3ff0310d4e69f5469e93bbc354dd59584a0c8294b 
trixie_607a06e9-dc01-11ef-8648-52d4cdf5194b.box
  config.vm.box_download_checksum = 
"073c794a90187cff320096c3ff0310d4e69f5469e93bbc354dd59584a0c8294b"
  config.vm.box_download_checksum_type = "sha256"

  config.vm.box_check_update = false

  bugref = "1089580"

  config.vm.define "testing" do |it|
it.vm.hostname = "testing"
  end

  config.vm.provider "libvirt" do |libvirt|
# unfortunately won't work OOTB:
#libvirt.qemu_use_session = true

libvirt.default_prefix = "bug-#{bugref}-"
  end

  config.vm.provision "shell", inline: <<-'SHELL'
apt-get purge -y unattended-upgrades
apt-get -y -U install --no-install-recommends apt-eatmydata zstd kbd
apt-get -y upgrade
cat > /var/tmp/runonce.sh < /etc/apt/sources.list.d/trixie.sources  /etc/apt/apt.conf.d/20tum.conf < /etc/apt/sources.list.d/unstable.sources &2 ) 2>&1 | tee visualvm.log ; less -M visualvm.log ; 
/bin/bash'
EOD
echo Done.
cat > /etc/systemd/system/tmp-runonce.service <

Bug#1095675: new upstream (2.6.13)

[Daniel Baumann]

Package: openvpn
Severity: normal

Hi,

thanks for maintiaining openvpn in debian. it would be nice if you could
upgrade the package to the current upstream version as 2.6.13 has some
nice to have fixes.

Regards,
Daniel

Bug#989566: freeaptx is in Debian

[Jakob Haufe]

Just to prevents others from spending more time digging into this:

libfreeaptx, which is a fork of libopenaptx 0.2.0, is available in
Debian since bookworm.

The only reverse dependency of libopenaptx at the time of writing is
baresip.

AIUI, there's currently no functional difference between both libraries.

-- 
ceterum censeo microsoftem esse delendam.


pgp1NpXKaqeST.pgp
Description: OpenPGP digital signature

Bug#1095607: [PATCH] debian: fix lintian warnings: superfluous-file-pattern; closes: bug#1095607

[Jonas Smedegaard]

Quoting Matthieu Baerts (2025-02-10 09:55:34)
> On 09/02/2025 21:56, Jonas Smedegaard wrote:
> > Quoting Matthieu Baerts (NGI0) (2025-02-09 19:57:37)
> >> Simply fix the remaining lintian warnings from:
> >>
> >>   https://udd.debian.org/lintian/?packages=iwd
> > 
> > I disagree with how lintian parses copyright files.
> > 
> >>  Files:
> >> - */configure
> >> + configure
> > 
> > My intent is to match any file named "configure" at any depth - similar
> > to the example */Makefile.in at
> > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-field
> 
> Should it not be "*configure" and "*Makefile.in" then?

No, that would be too broad to also cover e.g. a file "myconfigure".

> According to the same doc...
> 
> > Only the wildcards * and ? apply; the former matches any number of
> > characters (including none), the latter a single character. Both
> > match slashes (/) and leading dots, unlike shell globs. The pattern
> > *.in therefore matches any file whose name ends in .in anywhere in
> > the source tree, not just at the top level.
> ... it is a bit confusing: when reading this, it sounds like
> "*/configure" means all the "configure" file from any subdirectories. It
> should then match "./configure", but maybe it doesn't work like that.
> 
> >>  Files:
> >> - */Makefile.in
> >> + Makefile.in
> > 
> > This is *exactly* the same as the example in the official definition.
> 
> Is it needed to add something to silent the lintian warnings, or should
> we just ignore them?

In my view, silencing lintian implies that lintian is wrong specifically
which is not the case: I believe lintian is wrong generally.  When I (or
you?) find the energy to file a bugreport against lintian about the
issue, it makes sense to be to silence the noise with a reference to
said bugreport - see debian/source/lintian-overrides for how I do that
for another similar long-standing issue.

> Note that I'm fine with only the modification you did. I only shared
> this patch because I saw the warnings. It is OK for me to ignore them.

...and I am happy that you did - having fresh eyes on things is great!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1093363: uvloop: FTBFS: AssertionError: Lists differ: [(

[Sebastiaan Couwenberg]

Control: tags -1 unreproducible

On Fri, 17 Jan 2025 18:54:25 + Santiago Vila  wrote:

AssertionError: Lists differ: [(

This suggests an IPv6 only host, as the package builds successfully in a plain 
sid cowbuilder chroot on my system.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1082570: libportal: FTBFS with segfault during TestInputCapture, reliably on AWS but rarely elsewhere

[Simon McVittie]

On Mon, 10 Feb 2025 at 15:53:23 +0100, Santiago Vila wrote:
> El 9/2/25 a las 18:48, Simon McVittie escribió:
> > On the VM that Santiago provided, I successfully built libportal from
> > source twice in a row (by entering the sid schroot and building with
> > dpkg-buildpackage), which seems inconsistent with Santiago getting a
> > less than 10% success rate.
> 
> I've just noticed that the machine I gave you was not the type I wanted
> (it was r7a.medium instead of m7a.large as intended).
> 
> Please try the new machine I've prepared for you (details in private email).

On the new 2-vCPU machine (test-4) the crash is indeed more readily
reproducible than on the 1-vCPU machine (test-3), although still not 100%:
I saw 8 failures and 2 successes in 10 runs.

As with previous attempts, I have no idea what it is about these machines
specifically that makes this race condition more likely to be hit. The
reason for the test failure seems to be a race condition in libportal
(a genuine bug, not a flaw in the test suite) which is very rarely
hit on my laptop and (as far as I can tell) has never been hit on the
official buildds, but for whatever reason is much more common on these
cloud machines.

If it's going to fail, `meson test` generally fails in around 10 seconds
on this machine. If it's going to succeed, it generally takes about a minute.

I've sent merge requests upstream to
https://github.com/flatpak/libportal/pull/184,
https://github.com/flatpak/libportal/pull/189,
https://github.com/flatpak/libportal/pull/191 attempting to fix this.
They passed 100 iterations of the test suite on test-3, and I'll queue
them to run a similar number of iterations on test-4 next.

I have spent as much time on this as I can right now, and I have other
work that I need to prioritize, so I will resume when time permits
(hopefully with a code review from upstream).

Santiago, I've powered off test-3 as you asked (sudo init 0) and if you
need to do anything further to clear it up, you can do so now; but I'm
still using test-4.

smcv

Bug#1076854: ITP: python-juliandate -- Simple conversions between Julian Dates and Julian/Gregorian calendar dates, supporting ancient dates (BCE)

[Arlisson Jaques]

Hello Enkelena, how are you?

Sorry, I really started the process, but I had several unforeseen events in
the last few days that slowed me down a lot. Thank you very much for
continuing.

Kind regards,
Arlisson Jaques

Em seg., 10 de fev. de 2025 às 05:35, Enkelena Haxhiu 
escreveu:

> Hi Arlisson,
>
> It has been around 1 month and a half since the interest to package
> julidandate was expressed from your end, but I did not see the package
> uploaded.
> Since this is a dependency for another package that I maintain and I
> was waiting for a new version from upstream there since August, they
> pinged me last week with the new version being ready, thus I had to go
> ahead and package juliandate.
>
> I am in the process of finishing it up and it should be ready by the
> end of this working week.
> When it's published, feel free to talk to me about suggestions or if
> you want to upload new versions when they come.
>
> Kind regards,
> Enkelena
>
>
>
> On Fri, Dec 27, 2024 at 11:08 PM Arlisson Jaques
>  wrote:
> >
> > Okay, thank you very much Enkelena.
> >
> > I will proceed with the packaging.
> >
> > Thanks again for the quick response.
> >
> > Arlisson Jaques.
> >
> > Em sex., 27 de dez. de 2024 às 17:02, Enkelena Haxhiu <
> enkelen...@gmail.com> escreveu:
> >>
> >> Hi Arlison,
> >>
> >> Thanks for reaching out. I am super busy with writing my Master's
> thesis so I don't plan to do it for the next month. Please feel free to
> continue.
> >>
> >> Kind regards,
> >> Enkelena
> >>
> >>
> >> On Fri, 27 Dec 2024, 20:57 Arlisson Jaques, 
> wrote:
> >>>
> >>> Hello, how's it going?
> >>>
> >>> I'm also interested in putting this package on Debian.
> >>>
> >>> How is the progress? Do you intend to continue?
> >>>
> >>> I would like to continue because another package I am working on needs
> this in the new upstream version.
>

Bug#1094603: [PATCH] debian: network-manager-iwd: remove conflict with wpasupplicant; closes: bug#1094603

[Matthieu Baerts]

Hi Jonas,

On 10/02/2025 18:23, Jonas Smedegaard wrote:
> Quoting Matthieu Baerts (2025-02-09 23:49:37)
>> 9 Feb 2025 22:15:50 Jonas Smedegaard :
>>> Quoting Matthieu Baerts (NGI0) (2025-02-09 19:56:27)
 iwd doesn't provide all the same features as the ones from
 wpa_supplicant, especially everything not related to the Wireless world,
 e.g. Ethernet authentication (bug#956457), or some more specific
 features like MACsec.

 wpa_supplicant and iwd can then be used in parallel, for different
 purposes.
>>>
>>> When you install only the iwd package, then you can also install the
>>> wpasupplicant package, and carefully configure them to not step on each
>>> others' toes.
>>>
>>> What the package network-manager-iwd offers is relieving the user of
>>> manual configuration: It is ensured that iwd works together with
>>> network-manager, but since network-manager recommends wpasupplicant,
>>> it is not adequate to provide a network-manager config snippet, because
>>> wpasupplicant will still be installed and will in its default
>>> configuration interfere with the default configuration of iwd.
>>
>> I see, but in fact, thanks to the config file provided by this package,
>> at the next reboot, NM will use iwd and leave wpasupplicant alone.
>> So no conflicts.
>>
>> iwd is just one WiFi backend that is loaded after having read the config.
>> NM will not try to use both at the same time.
> 
> I might be wrong, but my understanding (and as I recall my personal
> experience as well) is not a problem of which helper tool
> network-manager interacts with, but instead that wpasupplicant by
> default loads itself as a daemon which somehow (listening to same
> socket, I guess) causes iwd to fail to load or operate reliably.
> 
> See https://wiki.debian.org/NetworkManager/iwd for related info.

I guess you can have the conflict if you set IWD as the new backend,
then restart NM without stopping wpasupplicant that was already launched
from a previous instance. (I don't know if it can still be an issue today.)

If there is a reboot, the issue will not occur (that's what I had on my
side) because wpasupplicant will not be used as backend by NM.

In other words, there is a risk of issues only during the session where
IWD has just been installed, when the NM service is restarted but the
wpasupplicant one is left running. If someone wants to use IWD right
away, it will have to stop wpasupplicant as mentioned in the wiki. Do we
need to cover this case?

I don't think it is needed, but then a post-install script could also
stop wpasupplicant and restart NM.

Now that I'm thinking about that, with the conflict, wpasupplicant will
be removed, but NM will not be restarted and will try to continue using
it. I don't think it is a good situation. Keeping wpasupplicant seems
safer. (Or a post-install script is needed.)

>>> Thanks for the proposal, but I disagree with this one.
>>
>> (I think there is a small mixed-up in the changelog file, because it is
>> saying the opposite, but that's a detail :) )
> 
> What mixup, more specifically?  I like perfect changelogs. :-)
The changelog for the last version mentioned this:

  * relax binary package network-manager-iwd
to not conflict with wpasupplicant;
update long description;
closes: bug#1094603, thanks to Matthieu Baerts

Did you not remove the entry for the bug#1095606 instead of this one?

Cheers,
Matt

Bug#1091799: installation-reports: Qualcomm Atheros AR9485 detected, wifi networks seen but no network connection

[magnus]

Hi Pascal, hi kibi ;-)

On 2025-02-05 11:47, Pascal Hambourg wrote:

On 05/01/2025 at 19:48, mag...@autistici.org wrote:

mag...@autistici.org  (2024-12-31):


The problem during the installation was the following: d-i detected 
the
Qualcomm Atheros AR9485 wireless network card, but it couldn't 
connect
for some reason! This problem is present in the installed system, 
too:
the wifi networks are shown but no connections despite correct 
passwords.

I tested with two different mobile phones using tethering wifi.

(...)

My friend came again to my home with his Notebook. So I prepared a USB
stick with the Trixie Alpha 1 Netinst (...)

Unfortunately the problem is the same as with the bookworm installer


I am not surprised. Atheros AR9485 is more than 10 years old and 
supported since linux 2.6.38 so I did not expect any improvement in 
Trixie. Can you try with other access points than mobile phones ?


Yes, will do when my friend will come again to my home: we will go to a
nearby coffee shop as we both only have mobile phones as access points.


kibi: Different issue, but when reading the installer syslog I noticed 
that check-missing-firmware failed to identify and reload the proper 
module ath9k_htc for the Atheros USB wireless adapter after installing 
the missing firmware. So it seems that the workaround for the usb case 
did not work here.


If needed I could test my Atheros USB wireless adapter which uses free
firmware build from source (see #900171) with an updated netinst image
and provide the logs!

HTH, Magnus

Bug#1095647: linux-image-6.12.12-cloud-amd64: Enable config options for AWS Nitro Enclaves

[Alexander Graf]

Package: src:linux
Version: 6.12.12-1
Severity: important
X-Debbugs-Cc: g...@amazon.com

Dear Maintainer,

AWS Nitro Enclaves[1] are a technical capability that (almost) every EC2
instance can enable. It allows the VM to carve CPU and memory from
itself and seed a Nitro Enclave (separate VM) from it. To perform that
separation, we need the Nitro Enclaves kernel driver which is part of
Linux upstream since v5.10 guarded behind CONFIG_NITRO_ENCLAVES.

If a user also wants to run the Debian kernel inside a Nitro Enclave,
they will additionally want support for the Nitro Secure Module - a
minimalistic TPM only available in Nitro Enclaves, including its QEMU
emulation model[2]. Support for NSM arrived in upstream Linux v6.10
behind CONFIG_NSM.

To allow users to run Nitro Enclaves on Debian VMs as well as Debian
inside Nitro Enclaves, please enable the following kernel options:

  CONFIG_NSM=m
  CONFIG_VIRT_DRIVERS=y (dependency of CONFIG_NITRO_ENCLAVES) 
  CONFIG_NITRO_ENCLAVES=m

Please enable them on both amd64 as well as arm64 kernel flavors.

Alex

[1] https://aws.amazon.com/ec2/nitro/nitro-enclaves/
[2] https://www.qemu.org/docs/master/system/i386/nitro-enclave.html


-- Package-specific info:
** Version:
Linux version 6.12.12-cloud-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-14 (Debian 14.2.0-16) 14.2.0, GNU ld (GNU Binutils for 
Debian) 2.43.90.20250127) #1 SMP PREEMPT_DYNAMIC Debian 6.12.12-1 (2025-02-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.12.12-cloud-amd64 
root=PARTUUID=1ac422f6-1b40-4725-9fb0-a3ec91531fdf ro console=tty0 
console=ttyS0,115200 earlyprintk=ttyS0,115200 consoleblank=0

** Not tainted

** Kernel log:
[4.211417] ena :27:00.0: ENA device version: 0.10
[4.213914] ena :27:00.0: ENA controller version: 0.0.1 implementation 
version 1
[4.222440] ena :27:00.0: Elastic Network Adapter (ENA) found at mem 
c870, mac addr 02:1f:bc:d7:75:cf
[4.231719] ena :27:00.0 enp39s0: renamed from eth0
[4.398021] input: AT Translated Set 2 keyboard as 
/devices/platform/i8042/serio0/input/input0
[4.984285] EXT4-fs (nvme0n1p1): mounted filesystem 
d2595be6-a7e4-414e-bb0e-de8ecb67e8bd ro with ordered data mode. Quota mode: 
none.
[5.220779] Not activating Mandatory Access Control as /sbin/tomoyo-init 
does not exist.
[9.989275] systemd[1]: Inserted module 'autofs4'
[   10.298971] NET: Registered PF_VSOCK protocol family
[   10.494331] systemd[1]: systemd 257.2-3 running in system mode (+PAM +AUDIT 
+SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL 
+BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP 
+LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 
+BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF -XKBCOMMON -UTMP +SYSVINIT 
+LIBARCHIVE)
[   10.508396] systemd[1]: Detected virtualization amazon.
[   10.510924] systemd[1]: Detected architecture x86-64.
[   10.642626] systemd[1]: No hostname configured, using default hostname.
[   10.645561] systemd[1]: Hostname set to .
[   10.773781] systemd[1]: Initializing machine ID from SMBIOS/DMI UUID.
[   10.776653] systemd[1]: Installed transient /etc/machine-id file.
[   11.092678] systemd[1]: bpf-restrict-fs: LSM BPF program attached
[   13.845856] systemd[1]: Queued start job for default target graphical.target.
[   13.882569] systemd[1]: Created slice system-getty.slice - Slice 
/system/getty.
[   13.888150] systemd[1]: Created slice system-modprobe.slice - Slice 
/system/modprobe.
[   13.893685] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice 
/system/serial-getty.
[   13.899549] systemd[1]: Created slice system-systemd\x2dfsck.slice - Slice 
/system/systemd-fsck.
[   13.905339] systemd[1]: Created slice user.slice - User and Session Slice.
[   13.909145] systemd[1]: Started systemd-ask-password-console.path - Dispatch 
Password Requests to Console Directory Watch.
[   13.915235] systemd[1]: Started systemd-ask-password-wall.path - Forward 
Password Requests to Wall Directory Watch.
[   13.921287] systemd[1]: Set up automount proc-sys-fs-binfmt_misc.automount - 
Arbitrary Executable File Formats File System Automount Point.
[   13.927730] systemd[1]: Expecting device 
dev-disk-by\x2dpartuuid-4f5ce17e\x2daa72\x2d41cf\x2db7a6\x2d25b78e22a7ab.device 
- /dev/disk/by-partuuid/4f5ce17e-aa72-41cf-b7a6-25b78e22a7ab...
[   13.936227] systemd[1]: Expecting device dev-ttyS0.device - /dev/ttyS0...
[   13.939836] systemd[1]: Reached target paths.target - Path Units.
[   13.943288] systemd[1]: Reached target remote-fs.target - Remote File 
Systems.
[   13.948341] systemd[1]: Reached target slices.target - Slice Units.
[   13.951855] systemd[1]: Reached target swap.target - Swaps.
[   13.957001] systemd[1]: Listening on systemd-creds.socket - Credential 
Encryption/Decryption.
[   13.962547] systemd[1]: Listening on systemd-initctl.socket - initctl 
Compatibility Named Pipe.
[   13.968114] systemd[1]: Listening on systemd-j

Bug#1095658: yadifa: Does not support CAA records

[Kevin]

Package: yadifa
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: deb...@kevinsteen.net

This is just a heads-up for anyone considering using yadifa with a modern mail
setup (like mox) - the CAA record type isn't yet supported in yadifa.

CAA records are optional, so this isn't a big deal - just something I wish I
knew while considering which DNS server to setup. (CAA records specify which
Certificate Authorities are allowed to generate certificates for a domain.)

-Kevin


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

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

Versions of packages yadifa depends on:
ii  adduser 3.134
ii  debconf 1.5.82
ii  libc6   2.36-9+deb12u9
ii  libssl3 3.0.15-1~deb12u1
pn  libssl3t64  
ii  netbase 6.4

yadifa recommends no packages.

yadifa suggests no packages.

Bug#1094487: patroni: pg_clonecluster_patroni fails: Error: cluster configuration already exists

[Michael Banck]

Hi,

On Wed, Jan 29, 2025 at 07:01:00PM +, Ben Harris wrote:
> On Wed, 29 Jan 2025, Ben Harris wrote

I tried to reproduce the reinit failure, but it always worked for me.
Not sure what is different on your side :-/

> > If I add "WorkingDirectory=~" to patroni@.service, even on a current
> > Patroni package, reinit starts working again.  This gives me a
> > convenient workaround, but I'll try to work out the cause as well.
> 
> And after a bit of fighting with strace, I've spotted where the bug (or
> rather the anti-bug) is.  Here, in pg_clonecluster_patroni:
> 
> rm -f etc/postgresql/$VERSION/$CLUSTER/postgresql.base.conf
> 
> Note the lack of a '/' before "etc".

Ouch, thanks for spotting that.
 
> This means that if the script is run with its current directory being / (as
> systemd runs services by default), then in will successfully delete
> postgresql.base.conf, pg_dropcluster will fail, and so reinit will fail. But
> if the current directory is set by systemd then the "rm" will fail,
> pg_dropcluster will succeed, and so reinit will succeed.
> 
> I would suggest that the proper fix here is to insert the missing '/' and
> move the "rm" command back to being after the "pg_dropcluster" command. Or
> just drop the "rm" command entirely.

I did the former now in the salsa git repo, however, that will only be
part of the 4.0.x releases.


Michael

Bug#1095660: yadifa: As installed, zone file errors aren't logged/reported

[Kevin]

Package: yadifa
Severity: wishlist
X-Debbugs-Cc: deb...@kevinsteen.net

Dear Maintainer,

The configuration when first installed doesn't log errors in zone files, making
it difficult to troubleshoot why a newly-added zone isn't working. Neither the
system journal, nor the files in /var/log/yadifa/ had any error indications.

I eventually figured out that adding these lines in the  section would
give me the debugging information I needed in the journal:

  database  *  stdout
  zone  *  stdout

I think doing this by default in the Debian package might be beneficial to
others also using yadifa for the first time.

-Kevin


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

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

Versions of packages yadifa depends on:
ii  adduser 3.134
ii  debconf 1.5.82
ii  libc6   2.36-9+deb12u9
ii  libssl3 3.0.15-1~deb12u1
pn  libssl3t64  
ii  netbase 6.4

yadifa recommends no packages.

yadifa suggests no packages.

Bug#1095643: osmocom-dahdi-linux: -dkms only builds for the running kernel, -source unusable

[Andreas Beckmann]

Followup-For: Bug #1095643
Control: tag -1 patch

Merge request:
https://salsa.debian.org/debian-mobcom-team/osmocom-dahdi-linux/-/merge_requests/1

CI passes except for a Lintian error:
E: osmocom-dahdi-linux source: debian-watch-file-pubkey-file-is-missing 
[debian/watch]

The autopkgtests pass on amd64, i386, armhf, arm64, ppc64el (after
setting BUILD_EXCLUSIVE_CONFIG="CONFIG_PPP CONFIG_HDLC" because these
are not enabled in all kernels).
Should autopkgtest failures occur on other architectures (not covered
by my qemu setup) I'll send followup patches.


Andreas

Bug#1095655: util-linux: Please package exch

[Jörg Behrmann]

Package: util-linux
Version: 2.38.1-5+deb12u3
Severity: wishlist

Dear maintainers,

please include the "exch" tool in the util-linux package, that has been
introduced in upstream util-linux' 2.40 release.

It is a simple wrapper around renameat2's RENAME_EXCHANGE functionality to
atomatically exchange two files.

The tool is built by default, but currently not packaged, as can be see in the
build logs:

> dh_missing: warning: usr/bin/exch exists in debian/tmp but is not installed 
> to anywhere

sincerely,
Jörg Behrmann

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

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

Versions of packages util-linux depends on:
ii  libblkid1 2.38.1-5+deb12u3
ii  libc6 2.36-9+deb12u9
ii  libcap-ng00.8.3-1+b3
ii  libcrypt1 1:4.4.33-2
ii  libmount1 2.38.1-5+deb12u3
ii  libpam0g  1.5.2-6+deb12u1
ii  libselinux1   3.4-1+b6
ii  libsmartcols1 2.38.1-5+deb12u3
ii  libsystemd0   252.33-1~deb12u1
ii  libtinfo6 6.4-4
ii  libudev1  252.33-1~deb12u1
ii  libuuid1  2.38.1-5+deb12u3
ii  util-linux-extra  2.38.1-5+deb12u3
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages util-linux recommends:
ii  sensible-utils  0.0.17+nmu1

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.5.1-1+b1
pn  util-linux-locales  

-- no debconf information

Bug#1095659: RM: libfest-test-java-doc -- RoQA; Doc package is not build any more, please remove outdated binary package

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: fest-t...@packages.debian.org
Control: affects -1 + src:fest-test
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

source package fest-test version 2.1.0-2 does not build the doc
package any more.  Thus libfest-test-java-doc remained at version
2.1.0-1.1.  Please remove this binary package from unstable.

Kind regards and thanks for your work as ftpmaster
   Andreas.

Bug#1094349: nml: please replace the runtime dependency on python3-setuptools with a proper python3-pkg-resources

[Matthijs Kooijman]

notforwarded 1094349
thanks

> Upstream has also identified this issue and fixed it upstream, see
> https://github.com/OpenTTD/nml/issues/340 and
> https://github.com/OpenTTD/nml/pull/341
W00ps, replied on the wrong bugreport, ignore the previous message :-)
I will resend it to the right report.

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#1095666: ITP: r-cran-pryr -- Tools for Computing on the Language

[Juri Grabowski]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-pryr -- Tools for Computing on the Language
Package: wnpp
Owner: Juri Grabowski 
Severity: wishlist

* Package name: r-cran-pryr
  Version : 0.1.6
  Upstream Author : Hadley Wickham ,
* URL : https://cran.r-project.org/package=pryr
* License : GPL-2
  Programming Lang: GNU R
  Description : Tools for Computing on the Language
 Useful tools to pry back the covers of R and understand the
 language at a deeper level.

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

Bug#1085722: apt-listchanges: displays all old entries for some packages

[Vincent Lefevre]

I've also been seeing old entries for some packages, for instance,
concerning packages of gcc-mingw-w64 source today.

The currently installed version of one of these packages:

cventin:~> dpkg -s gcc-mingw-w64-i686
Package: gcc-mingw-w64-i686
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 256
Maintainer: Stephen Kitt 
Architecture: all
Source: gcc-mingw-w64 (26.7)
Version: 13.3.0-12+26.7
[...]

/usr/share/doc/gcc-mingw-w64-i686/changelog.Debian.gz starts with

gcc-mingw-w64 (26.7) unstable; urgency=medium
[...]
 -- Stephen Kitt   Sat, 18 Jan 2025 18:54:00 +0100

gcc-mingw-w64 (26.6) unstable; urgency=medium
[...]
 -- Stephen Kitt   Wed, 04 Dec 2024 07:36:40 +0100

gcc-mingw-w64 (26.5) unstable; urgency=medium
[...]
 -- Stephen Kitt   Wed, 23 Oct 2024 13:20:10 +0200

and so on.

When upgrading to 26.8, "/usr/bin/apt-listchanges --apt" shows

gcc-mingw-w64 (26.8) unstable; urgency=medium
[...]
 -- Stephen Kitt   Fri, 07 Feb 2025 07:51:32 +0100

gcc-mingw-w64 (26.7) unstable; urgency=medium
[...]
 -- Stephen Kitt   Sat, 18 Jan 2025 18:54:00 +0100

gcc-mingw-w64 (26.6) unstable; urgency=medium
[...]
 -- Stephen Kitt   Wed, 04 Dec 2024 07:36:40 +0100

down to the initial release

gcc-mingw-w64 (0.1) unstable; urgency=low
[...]
 -- Stephen Kitt   Tue, 16 Nov 2010 12:52:08 +0100

My /etc/apt/listchanges.conf file:

[apt]
frontend=pager
email_address=none
confirm=1
save_seen=/var/lib/apt/listchanges
which=both
no_network=false
headers=false
reverse=false

Just in case, "apt-listchanges --dump-seen --profile=apt" gives
information only for packages upgraded earlier today:

packages:
  apt 1739185510 (2025-02-10)
  apt-doc 1739185510 (2025-02-10)
  apt-utils 1739185510 (2025-02-10)
  libapt-pkg6.0t64 1739185510 (2025-02-10)
  linux-compiler-gcc-12-x86 1739185412 (2025-02-10)
  linux-doc-6.1 1739185413 (2025-02-10)
  linux-kbuild-6.1 1739185414 (2025-02-10)
exact checksums:
[...] (all for 2025-02-10)

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

Bug#1083022: closed by Debian FTP Masters (reply to Yves-Alexis Perez ) (Bug#1083022: fixed in tumbler 4.18.2-1)

[magnus]

Hi Yves-Alexis, hi Helmut!

@Helmut: I'm writing to you too because Yves-Alexis raised
the severity of the bug to serious and Yves-Alexis is asking
below if this does apply to stable too.

On 2025-01-20 13:49, Yves-Alexis Perez wrote:


On Sat, 2025-01-18 at 13:14 +, mag...@autistici.org wrote:

i Yves-Alexis, hi Debian Xfce Maintainers,

On 2024-10-11 09:09, Debian Bug Tracking System wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the tumbler package:
>
> #1083022: tumbler fails to coinstall: trying to overwrite shared
> '/usr/lib/systemd/user/tumblerd.service'
> Debian Xfce Maintainers 
> It has been closed by Debian FTP Masters
>  (reply to Yves-Alexis Perez
> ).

Could you apply the simple patch (unmark tumbler as m-a: same)
in stable/bookworm too, as tumbler still breaks crossgrader
there? This should be possible as the bug is Severity: serious.


Is it severity:serious for stable though?


Well, I think so but let's see what Helmut will answer.

Thank you, Magnus

Bug#987316: tmpfs-config(5): clarify TMPFS_SIZE

[Mark Hindley]

Control: tags -1 patch

The relevant manpage is not tmpfs-config(5). Proposed patch is below.

Mark

commit 3a6ea309c50e497ca2646ffa2cb582c63b1d3791
Author: Mark Hindley 
Date:   Mon Feb 10 11:46:19 2025 +

Clarify that TMPFS_SIZE override requires empty string.

Closes: #987316

diff --git a/debian/src/initscripts/man/tmpfs-config.5 
b/debian/src/initscripts/man/tmpfs-config.5
index 4df348ec..0be74258 100644
--- a/debian/src/initscripts/man/tmpfs-config.5
+++ b/debian/src/initscripts/man/tmpfs-config.5
@@ -159,8 +159,8 @@ change from the defaults be necessary.
 .IP "\fBTMPFS_SIZE\fP"
 Maximum size for all tmpfs filesystems if no specific size is
 provided.  The default is \fB20%VM\fP (20% of virtual memory,
-including swap space).  If no value is provided here, the kernel
-default (50% RAM) will be used.  Note that the "%VM" suffix may be
+including swap space).  If this is explicitly set to an empty string, the
+kernel default (50% RAM) will be used.  Note that the "%VM" suffix may be
 used in this and all the _SIZE settings below, but may not be used in
 /etc/fstab (the absolute size is calculated by the init scripts).
 

Bug#1095656: ruby-ammeter: Could not find 'useragent' (~> 0.16) among 136 total gem(s) (Gem::MissingSpecError)

[Pirate Praveen]

Package: ruby-ammeter
Version: 1.1.7-1
Severity: serious
X-Debbugs-Cc: prav...@debian.org

Dear Maintainer,

Broken with rails 7.

Full log
https://ci.debian.net/packages/r/ruby-ammeter/unstable/amd64/57495061/


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

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

Versions of packages ruby-ammeter depends on:
ii  ruby-activesupport  2:6.1.7.3+dfsg-4
ii  ruby-railties   2:6.1.7.3+dfsg-4
pn  ruby-rspec-rails

ruby-ammeter recommends no packages.

ruby-ammeter suggests no packages.

Bug#1093611: transition: urdfdom and dart

[Jose Luis Rivero]

Thanks Emilio. I've uploaded urdfdom and dart to unstable.

Note: the new dart version does not support 32bits architectures anymore so
we probably need to remove armel, armhf and i386 binary packages from
unstable.


On Mon, Jan 20, 2025 at 1:05 PM Emilio Pozuelo Monfort 
wrote:

> Control: tags -1 confirmed
>
> On 20/01/2025 12:49, Jose Luis Rivero wrote:
> > Package: release.debian.org
> > Severity: normal
> > X-Debbugs-Cc: urdf...@packages.debian.org
> > Control: affects -1 + src:urdfdom + src:dart
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > Dear release team:
> >
> > As the maintainer of the urdfdom and dart I think that we are good to
> move the
> > versions on experimental to unstable. Both packages bump the major
> version and
> > the ABI/API with them:
> >
> >   - urdfdom 3.0.1 -> urdfdom 4.0.0
> >   - dart 6.12.1 to 6.13.2
>
> dart has no rdeps, that's why no auto tracker was created. And neither
> package
> is currently in testing. Go ahead with both.
>
> Cheers,
> Emilio
>

Bug#1095665: ITP: r-cran-pool -- Object Pooling

[Juri Grabowski]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-pool -- Object Pooling
Package: wnpp
Owner: Juri Grabowski 
Severity: wishlist

* Package name: r-cran-pool
  Version : 1.0.4
  Upstream Author : Hadley Wickham 
* URL : https://cran.r-project.org/package=pool
* License : MIT
  Programming Lang: GNU R
  Description : Object Pooling
 Enables the creation of object pools, which make it less
 computationally expensive to fetch a new object. Currently the only
 supported pooled objects are 'DBI' connections.

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

Bug#1095655: util-linux: Please package exch

[Chris Hofstaedtler]

* Jörg Behrmann  [250210 12:48]:
> please include the "exch" tool in the util-linux package, that has been
> introduced in upstream util-linux' 2.40 release.

> It is a simple wrapper around renameat2's RENAME_EXCHANGE functionality to
> atomatically exchange two files.

How important is `exch`? Is it a tool that is really essential, and
should thus be in the "util-linux" package, which is installed on
each and every Debian installation?

I've been avoiding adding new stuff to "util-linux" to avoid
bloating it even more.

Can it land in util-linux-extra, which is at least only
pseudo-Essential? Or some other package, like bsdutils or
bsdextrautils (not the best names)?

Regarding your merge request: this seems to miss installing man
pages into the appropriate packages.

Chris

Bug#1082570: libportal: FTBFS with segfault during TestInputCapture, reliably on AWS but rarely elsewhere

[Santiago Vila]

El 9/2/25 a las 18:48, Simon McVittie escribió:


On the VM that Santiago provided, I successfully built libportal from
source twice in a row (by entering the sid schroot and building with
dpkg-buildpackage), which seems inconsistent with Santiago getting a
less than 10% success rate. Running the tests manually with
`meson test -C obj-x86_64-linux-gnu --repeat=20`, it failed on the first
or second loop iteration the first few times, but another attempt has
now passed its first 6 iterations and is still going. So there still
seems to be quite a significant difference between the reproducibility
of failure that Santiago saw, and what I'm now seeing.


I've just noticed that the machine I gave you was not the type I wanted
(it was r7a.medium instead of m7a.large as intended).

Please try the new machine I've prepared for you (details in private email).

I'm really sorry for the confusion.

Thanks.