Bug#1073509: sbuild-qemu-update works, but increases image allocated size each time

[Christian Kastner]

On 2024-06-22 12:49, Francesco Poli wrote:
> On Fri, 21 Jun 2024 00:42:21 +0200 Christian Kastner wrote:
>> In this particular case, one factor would be that the update caused new
>> APT lists to be downloaded, which have tens of MB.
> 
> How so?
> 
> As I said in the [original] bug report, I tried to run
> sbuild-qemu-update on the image that I had just regenerated from
> scratch. It seems that it found nothing to update, not even the APT
> repository lists (which were already up-to-date, as expected). Please
> take a look at the output of sbuild-qemu-update in the [original] bug
> report...

Indeed. Sorry, I replied with gut instinct here.

> Come on, I am sure you are clever enough to figure out a good strategy
> to automatically prevent the image allocated size from growing
> indefinitely!

Apparently, there is a trick after all.

(1) sbuild-qemu-{boot,update} need to add discard=unmap to the block
device options of the image
(2) In the guest,
  (2a) the root partition needs to be remounted with discard
  (2b) fstrim /
(3) On the host, qemu-img convert -O qcow2 foo.img bar.img

At least on my end, this reduced the image size.

fstrim was the only solution I could find that could trigger TRIMs on a
mounted filesystem.

I've pushed a fix implementing this. It seems safe enough, though I
wonder if I shouldn't have guarded this with a --shrink option.

Best,
Christian

Bug#1072775: Fwd: Bug#1072775: Acknowledgement (RFS: logrotate/3.22.0-1 -- Log rotation utility)

[Christian Göttsche]

control: reopen -1

> Hmm... there seems to be a build issue on 32bit.

Fixed (together with a reproducibility issue) in the latest mentors upload.

Bug#1073164: pbuilder build --twice, stray process that requires manual intervention

[Christian Göttsche]

control: tags -1 unreproducible

> Building logrotate twice with pbuilder (part of reproducible builds) e.g. 
> 'sudo
> pbuilder build --twice logrotate_-.dsc' results in a
> stray process at the end of the second build that requires manual intervention
> (hitting 'q' key) to exit and complete the build, see output below.

I tried the reproducer but it works for me.

> dpkg-genchanges: info: not including original source code in upload
> I: copying local configuration
> I: Copying back the cached apt archive contents
> I: unmounting dev/ptmx filesystem
> I: unmounting dev/pts filesystem
> I: unmounting dev/shm filesystem
> I: unmounting proc filesystem
> I: unmounting sys filesystem
> W: Stray processes left from build:
> * system-pbuilder-build-logrotate_3.21.0\x2d2-24623.slice - Slice
> /system/pbuilder/build/logrotate_3.21.>
>  Loaded: loaded
>  Active: active since Thu 2024-06-13 20:23:04 BST; 46s ago
>  Invocation: 73d59e481a6848a489f3c27c57c333cb
>   Tasks: 2
>  Memory: 253.4M (peak: 369.5M)
> CPU: 1min 1.590s
>  CGroup: /system.slice/system-pbuilder.slice/system-pbuilder-
> build.slice/system-pbuilder-build-logro>
>  `-run-r8841d7ef13ad49709af4343b1c9e543b.scope
>|-43056 flock state -c "sleep 10"
>`-43062 sleep 10

Seems like test-0092 did not finish, but I wonder how a `sleep 10` could stall.

> Jun 13 20:23:04 ks-windu systemd[1]: Created slice system-pbuilder-build-
> logrotate_3.21.0\x2d2-24623.sli>
> I: cleaning the build env
> I: removing directory /var/cache/pbuilder/build/24623 and its subdirectories
> I: Current time: Thu Jun 13 20:24:11 BST 2024
> I: pbuilder-time-stamp: 1718306651

Bug#1073509: sbuild-qemu-update works, but increases image allocated size each time

[Christian Kastner]

Hi,

On 2024-06-17 08:34, Johannes Schauer Marin Rodrigues wrote:
> Quoting Francesco Poli (wintermute) (2024-06-16 19:09:08)
>> But, the allocated size has significantly grown:
>>
>>   $ cd ~/.cache/sbuild/
>>   $ ls -altrFs --si
>>   total 4.4G
>>   4.1k drwx-- 37 $USER $USER 4.1k May  4 16:03 ../
>>   4.1k drwxrwx---  2 $USER $USER 4.1k May 13 23:19 build/
>>   3.6G -rw-rw  1 $USER $USER  27G Jun  9 22:00 
>> OLD_unstable-autopkgtest-amd64.img
>>   4.1k drwxrwx---  3 $USER $USER 4.1k Jun 16 18:26 ./
>>   832M -rw-rw  1 $USER $USER  27G Jun 16 18:26 
>> unstable-autopkgtest-amd64.img
>>
>> Now the allocated size is 832 MB, instead of 705 MB !!!

In this particular case, one factor would be that the update caused new
APT lists to be downloaded, which have tens of MB.

>> But why does the allocated size increase?
>> Maybe there's something about sparse file support that I do not
>> fully understand.
>>
>> Is there anything that can be done inside sbuild-qemu-update to prevent
>> the allocated size from growing indefinitely?
>> Apart from periodically regenerating the image from scratch, I mean...
> 
> as you suspected this is because of how sparse files work. Whenever you 
> upgrade
> something in your image, data gets deleted and new data gets added. The
> filesystem driver in the kernel does not zero-out those parts that it deletes
> and even if it would, qemu has no idea which blocks of the underlying image
> file it should now mark "sparse".

Exactly this. One has to differentiate between what goes on in the guest
(file deletion from ext4) and what QEMU sees (just blocks being used up).

I guess clever stuff could be done but honestly, it's probably simpler
to occasionally regenerate an image.

A hacky solution would be to use the --snapshot option to
sbuild-qemu-update on first run. In future runs, you could reset the
image to that snapshot using qemu-img. That would be a tradeoff though
as with time, updates would take longer and longer.

> One tool that should reduce size again is e2image from e2fsprogs:
> 
> $ e2image -rap old.img new.img
> 
> But this requires copying the actual file data. I didn't try it out, but there
> is also the "discard" extended option of e2fsck:
> 
> $ e2fsck -E discard your.img
> 
> Lastly, I do not know if the zerofree tool has support for sparse files? Maybe
> try running it on your FS and see what happens. :)

Best,
Christian

Bug#1073857: keyboard-configuration: fails to install with xkb-data dependency conflict

[Christian Stewart]

Package: keyboard-configuration
Severity: important

Dear Maintainer,

keyboard-configuration depends on xkb-data < 2.41A but only 2.42-1 is
available in the Debian Sid sources.

Reproduce:

1. docker run --platform=linux/arm64 --rm -it debian:sid bash
2. apt update
3. apt install -y keyboard-configuration

Fails:

 keyboard-configuration : Depends: xkb-data (< 2.41A) but 2.42-1 is to
be installed

This also fails if apt dist-upgrade -y is run before apt install.

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

Kernel: Linux 6.8.9-cloud-arm64 (SMP w/11 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0]   1.5.86
pn  liblocale-gettext-perl  
pn  xkb-data

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

Bug#1071456: Possible fix for 9p change breaking autopkgtest-build-qemu

[Christian Kastner]

FYI, a contributor has submitted a patch to the kernel Bugzilla [1] and
it indeed fixed the issue for the packages where I was seeing this.

Let's hope it gets recognized and accepted soon.

Best,
Christian

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=218916

Bug#1072959: python3-paraview: Errors when setting up package

[Christian Holm Christensen]

Package: python3-paraview
Version: 5.12.1+dfsg-2
Severity: normal
X-Debbugs-Cc: chol...@gmail.com


When installing the package, the following errors are reported

=== Start error log ===
Setting up python3-paraview (5.12.1+dfsg-2) ...
/usr/lib/python3/dist-packages/paraview/benchmark/logparser.py:11:
SyntaxWarning: invalid escape sequence '\d'
  _timere = '([-+]?\d*\.?\d+([eE][-+]?\d+)?) +seconds'
/usr/lib/python3/dist-packages/paraview/benchmark/logparser.py:12:
SyntaxWarning: invalid escape sequence '\w'
  _match_filter = re.compile('Execute (\w+) id: +(\d+), +' + _timere)
/usr/lib/python3/dist-packages/paraview/benchmark/logparser.py:13:
SyntaxWarning: invalid escape sequence '\w'
  _match_vfilter = re.compile('Execute (\w+) *, +' + _timere)
/usr/lib/python3/dist-packages/paraview/benchmark/logparser.py:16:
SyntaxWarning: invalid escape sequence '\d'
  'TreeComp (Send|Receive) (\d+) (to|from) (\d+) uchar (\d+), +' + _timere)
/usr/lib/python3/dist-packages/paraview/benchmark/logparser.py:22:
SyntaxWarning: invalid escape sequence '\w'
  _match_render = re.compile('(\w+|\w+ Dev) Render, +' + _timere)
/usr/lib/python3/dist-packages/paraview/smtesting.py:88: SyntaxWarning: invalid
escape sequence '\$'
  regExp = re.compile("\${DataDir}")
/usr/lib/python3/dist-packages/paraview/smtrace.py:358: SyntaxWarning: invalid
escape sequence '\g'
  gid = re.sub(regex, "\g<2>", arrayName)
/usr/lib/python3/dist-packages/paraview/smtrace.py:362: SyntaxWarning: invalid
escape sequence '\g'
  arrayName = re.sub(regex, "\g<3>", arrayName)
/usr/lib/python3/dist-packages/paraview/tpl/cinemasci/cis/cisview.py:268:
SyntaxWarning: "is not" with 'str' literal. Did you mean "!="?
  if not results[0][0] is "":
/usr/lib/python3/dist-packages/paraview/tpl/cinemasci/cis/imageview.py:208:
SyntaxWarning: "is" with 'str' literal. Did you mean "=="?
  if params["type"] is "url":
/usr/lib/python3/dist-packages/vtkmodules/util/vtkMethodParser.py:304:
SyntaxWarning: invalid escape sequence '\S'
  patn = re.compile ("  \S")
/usr/lib/python3/dist-packages/vtkmodules/web/testing.py:687: SyntaxWarning:
invalid escape sequence '\.'
  fnamePattern = re.compile("([^\.\/\\\]+)\.py")
/usr/lib/python3/dist-packages/paraview/tpl/cinemasci/cis/cisview.py:268:
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if not results[0][0] is "":
/usr/lib/python3/dist-packages/paraview/tpl/cinemasci/cis/imageview.py:208:
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if params["type"] is "url":
=== End error log ===

Most of these seem to be trivial coding errors (probably from upstream). For
example, the errors in /usr/lib/python3/dist-
packages/paraview/benchmark/logparser.py seems easily fixed by making the
strings "raw" strings.



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

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

Versions of packages python3-paraview depends on:
ii  libc6 2.38-12.1
ii  libgcc-s1 14.1.0-1
ii  libopenmpi3t644.1.6-13.3
ii  libpython3.11t64  3.11.9-1
ii  libpython3.12t64  3.12.3-1
ii  libstdc++614.1.0-1
ii  paraview  5.12.1+dfsg-2
ii  python3   3.11.8-1

python3-paraview recommends no packages.

python3-paraview suggests no packages.

-- no debconf information


-- 
Christian Holm Christensen -
 Sankt Hans Gade 23, 4, DK-2200 Copenhagen
 http://cern.ch/cholm, +4524618591

Bug#1009215: munpack does not properly decode split attachment filenames [patch]

[Christian Kelinski]

Hi,

We’ve the same problem with munpack so I was happy to see your patch. I 
downloaded the sources with

dget  http://deb.debian.org/debian/pool/main/m/mpack/mpack_1.6-18.dsc

applied your patch to the sources and a build it without problems.

I tested it with a message which has this multiline filename and it worked good 
except, that the filename has an additional X at the place where a new line 
starts.

In exact, the mime Header says

Content-Disposition: attachment;
filename*0=Report_source01_destcustomer_report_data_2024.06.09_08.30.xl;
filename*1=s

and the patched munpack saves the file as

Report_source01_destcustomer_report_data_2024.06.09_08.30.xlXs 
(application/vnd.ms-excel)

I’m not quite sure where this X comes from and sadly, my C knowledge isn’t good 
enough. Do you’ve any idea what is causing this X?

Thanks! a lot
Chris

[https://www.emetriq.com/wp-content/uploads/2024/01/E-Mail.jpg]
[https://www.emetriq.com/wp-content/uploads/2022/07/logo.png]
 trusted success
emetriq GmbH (Deutsche Telekom Gruppe) • Vorsetzen 35 • 20459 Hamburg
Sitz der Gesellschaft: Bonn • Handelsregister: AG Bonn, HRB 20117 • 
Geschäftsführer: Stephan Jäckel

Datenschutz ist emetriq sehr wichtig. Weitere Informationen finden Sie in 
unseren Datenschutzhinweisen unter 
www.emetriq.com/datenschutz.

This e-mail is confidential and is intended for the addressee(s) only. If you 
are not the named addressee you may not use it, copy it or disclose it to any 
other person. If you received this message in error please notify the sender 
immediately.


Karriere

Komm an Bord und werde Teil eines starken Teams und bewirb dich jetzt!
zu den Jobs


Mitgliedschaft

Wir sind Mitglied im Bundesverband Digitale Wirtschaft.
mehr erfahren


Folge uns

emetriq in den sozialen Netzwerken

LinkedIn 
Xing 
Facebook 
Instagram

Bug#1072775: RFS: logrotate/3.22.0-1 -- Log rotation utility

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : logrotate
   Version  : 3.22.0-1
   Upstream contact : https://github.com/logrotate/logrotate/issues
 * URL  : https://github.com/logrotate/logrotate
 * License  : BSD-3-Clause, GPL-2, GPL-3+
 * Vcs  : https://salsa.debian.org/debian/logrotate
   Section  : admin

The source builds the following binary packages:

  logrotate - Log rotation utility

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/logrotate/logrotate_3.22.0-1.dsc

Changes since the last upload:

 logrotate (3.22.0-1) unstable; urgency=medium
 .
   * New upstream version 3.22.0
 .
   * d/tests/control: drop redundant Depends
   * d/control: bump to std version 4.7.0 (no further changes)
   * d/upstream/signing-key.asc: add key for new release

Regards,
-- 
   Christian Göttsche

Bug#1072688: gnome-shell-extension-tiling-assistant: Panel icon is not shown when activated (advances mode needs to be turned on - then 3rd tab in settings is shown)

[Christian Lauinger]

Package: gnome-shell-extension-tiling-assistant
Version: 46-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

1. Enabled advanced mode
2. on the now visible 3rd tab "Layout" there is an option to enable a panel
icon
3. enabling the panel icon does add a button to the panel but with no icon.

Reason:
Upstream there is a media folder which seems not to be deployed by the deb
package.
Copied it from github to "/usr/share/gnome-shell/extensions/tiling-
assistant\@leleat-on-github/"
and restarted gnome-shell.

Now the icon is shown.


*** End of the template - remove these template lines ***


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

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

Versions of packages gnome-shell-extension-tiling-assistant depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  gnome-shell  46.2-1

Versions of packages gnome-shell-extension-tiling-assistant recommends:
ii  gnome-shell-extension-prefs  46.2-1

gnome-shell-extension-tiling-assistant suggests no packages.

-- no debconf information

Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.

[Christian Böck]

Hi Hakan!

Sure.
I hope attaching the files to this mail works.

On Tue, 4 Jun 2024 10:20:34 +0300 =?UTF-8?Q?Hakan_Bay=C4=B1nd=C4=B1r?= 
 wrote:

> Dear Christian,
>
> Can you please share the outputs "lspci -vvv" and "dmidecode" commands
> (please run them as the root user) as text files? This will allow
> anybody interested to see your hardware details, so pinpointing your
> computer's details plus the hardware used for sound will be much easier.
>
> Cheers,
>
> H.
>
> On 3.06.2024 ÖS 6:09, Christian Böck wrote:
> > On Mon, 3 Jun 2024 12:42:17 +0200 Andrius Merkys 
 wrote:

> > > Hi Christian,
> > >
> > > On 2024-06-03 11:38, Christian Böck wrote:
> > > > when using headphones with my laptop (Thinkpad W550s) I get a
> > repeating
> > > > cracking (~1sec intervalls) when nothing is playing.
> > >
> > > I have a similar issue on a workstation with Ubuntu 22.04. What 
is your
> > > operating system version? I believe the issue started manifesting 
once I

> > > installed Jack. Do you have Jack on your machine?
> > >
> > > Andrius
> > >
> > >
> >
> > Hi Andrius!
> >
> > I'm running an up-to-date Debian 12 64Bit (bookworm) and I don't have
> > Jack installed.
> > After some messing with duckduckgo the problem seems to be, that the
> > system puts the audio-chip to sleep, but not the headphone-amplifier.
> > I hope someone from Debian can fix it.
>
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
66 structures occupying 3194 bytes.
Table at 0xACBFD000.

Handle 0x, DMI type 222, 14 bytes
OEM-specific Type
Header and Data:
DE 0E 00 00 01 99 00 03 10 01 20 02 30 03
Strings:
Memory Init Complete
End of DXE Phase
BIOS Boot Complete

Handle 0x0001, DMI type 14, 8 bytes
Group Associations
Name: Intel(R) Silicon View Technology
Items: 1
0x (OEM-specific)

Handle 0x0002, DMI type 134, 13 bytes
OEM-specific Type
Header and Data:
86 0D 02 00 02 04 15 20 00 00 00 00 00

Handle 0x0003, DMI type 7, 19 bytes
Cache Information
Socket Designation: L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 32 kB
Maximum Size: 32 kB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Parity
System Type: Data
Associativity: 8-way Set-associative

Handle 0x0004, DMI type 4, 42 bytes
Processor Information
Socket Designation: U3E1
Type: Central Processor
Family: Core i7
Manufacturer: Intel(R) Corporation
ID: D4 06 03 00 FF FB EB BF
Signature: Type 0, Family 6, Model 61, Stepping 4
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Multi-threading)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
Voltage: 1.0 V
External Clock: 100 MHz
Max Speed: 3000 MHz
Current Speed: 2400 MHz
Status: Populated, Enabled
Upgrade: Socket BGA1168
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: 0x0007
Serial Number: None
Asset Tag: None
Part Number: None
Core Count: 2
Core Enabled: 2
Thread Count: 4
Characteristics:
64-bit capable
Multi-Core
Hardware Thread
Exec

Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.

[Christian Böck]

On Mon, 3 Jun 2024 12:42:17 +0200 Andrius Merkys  wrote:
> Hi Christian,
>
> On 2024-06-03 11:38, Christian Böck wrote:
> > when using headphones with my laptop (Thinkpad W550s) I get a repeating
> > cracking (~1sec intervalls) when nothing is playing.
>
> I have a similar issue on a workstation with Ubuntu 22.04. What is your
> operating system version? I believe the issue started manifesting once I
> installed Jack. Do you have Jack on your machine?
>
> Andrius
>
>

Hi Andrius!

I'm running an up-to-date Debian 12 64Bit (bookworm) and I don't have 
Jack installed.
After some messing with duckduckgo the problem seems to be, that the 
system puts the audio-chip to sleep, but not the headphone-amplifier.

I hope someone from Debian can fix it.

Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.

[Christian Böck]

Package: general
Severity: normal
X-Debbugs-Cc: deb...@funtech.org

Dear Maintainer,

when using headphones with my laptop (Thinkpad W550s) I get a repeating
cracking (~1sec intervalls) when nothing is playing.

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I used headphones for the first time with Debian.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I can't find a fitting setting, so I did nothing.

   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Bug#1072474: backintime-common: "sshfs" should be "dep" instead of "sug"

[Christian Buhtz]

Package: backintime-common
Version: 1.3.3-4
Severity: important

Upstream maintainer here.

I migrated from Debian 11 to 12 with fresh installing the whole system
including Back In Time (BIT). I realized that "sshfs" is not installed when
installing BIT.

I would say that "sshfs" should be a "depending" package instead of just a
"suggestion".

With "sshfs" remote backups using SSH are not possible. BIT gives error
messages about a missing "sshfs" but don't handle the situation in an elegant
way. Users will get lost. SSH using backup profiles are not disabled in this
case.

I would ease up a lot for us maintainers and users if "sshfs" would be a hard
dependecy.

Not sure how the Debian Policy is about it but I would suggest to also fix the
current stable (Debian 12) version.

Best,
Christian Buhtz


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

Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 backintime-common depends on:
ii  cron [cron-daemon]  3.0pl1-162
ii  openssh-client  1:9.2p1-2+deb12u2
ii  python3 3.11.2-1+b1
ii  python3-dbus1.3.2-4+b1
ii  python3-keyring 23.9.3-2
ii  python3-packaging   23.0-1
ii  rsync   3.2.7-1

Versions of packages backintime-common recommends:
ii  backintime-qt  1.3.3-4

Versions of packages backintime-common suggests:
pn  encfs   
pn  powermgmt-base  
pn  sshfs   

-- no debconf information

Bug#1071456: autopkgtest-virt-qemu: autopkgtest [15:14:50]: ERROR: testbed failure: sent `auxverb_debug_fail', got `timeout', expected `ok...'

[Christian Kastner]

Hi Paride,

On 2024-05-20 18:25, Paride Legovini wrote:
> On 2024-05-20 17:55, Christian Kastner wrote:
>> The test trigger we recorded was "linux-signed-amd64=6.8.9+1" but that
>> could just be coincidental.
> 
> Hi, this seems to be the same of:
> 
> https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/2056461
> 
> which turned out to be a kernel bug. If you want to verify that's
> actually the case, I suggest running autopkgtest --debug and checking
> that the timeout happens during a "copydown" operation.

yes that's exactly it.

Great, that just saved me a *lot* of time debugging :)

I was also hitting this earlier in our Ubuntu VMs, but they're still WIP
ion our team's CI so I thought it might be something else.

Best,
Christian

Bug#1071533: autopkgtest: timed out waiting for 'command prompt on serial console'

[Christian Kastner]

Package: autopkgtest
Version: 5.28
Severity: normal

In the Debian ROCm Team's CI, QEMU workers occasionally tmpfail with the
following error:

> autopkgtest: timed out waiting for 'command prompt on serial console'

>From [1], I guess that the official CI hit this, too.

However, this is an output parsing issue, rather than a timeout issue.
When the command preceding this returns fast enough, then it includes
the command prompt as "\n# ", but the code checking for this
expects "\n# ". I suspect that the uuid was an addition at some point.

A merge request fixing this will be filed shortly.

Best,
Christian

[1]: 
https://salsa.debian.org/ci-team/autopkgtest/-/commit/57cd6f0b98695362ce4c13f1115688b87d56a691

Bug#1071456: autopkgtest-virt-qemu: autopkgtest [15:14:50]: ERROR: testbed failure: sent `auxverb_debug_fail', got `timeout', expected `ok...'

[Christian Kastner]

Hi,

On 2024-05-19 17:06, Wouter Verhelst wrote:
> Package: autopkgtest
> Version: 5.35
> Severity: normal
> 
>> sudo autopkgtest-build-qemu --architecture amd64 sid 
>> /opt/chroots/autopkgtest-qemu.img
> 
> followed by
> 
>> autopkgtest . --test-name=initrd-boot -- qemu 
>> /opt/chroots/autopkgtest-qemu.img
> 
> in a directory that is a checkout of https://salsa.debian.org/wouter/nbd.git
> 
> It installed the test dependencies, and then failed on:
> 
>> autopkgtest [16:55:00]: Setting up user "user" to sudo without password...
>> qemu-system-x86_64: terminating on signal 15 from pid 150414 
>> (/usr/bin/python3)
>> autopkgtest [17:00:02]: ERROR: testbed failure: sent `auxverb_debug_fail', 
>> got `timeout', expected `ok...'
> 
> which I did not expect...

I've also starting seeing this recently in the Debian ROCm Team's CI.

In my case, this happens only with packages that have 2+ tests. When the
testbed is rebooted after the first test concludes, everything works
fine right until the "Setting up user "" to sudo without
password...", and then the timeout occurs.

In our particular case, the tests first started failing on 2024-05-17.
This was still with autopkgtest 5.34, and nothing else changed in our
infra over the past few days.

The test trigger we recorded was "linux-signed-amd64=6.8.9+1" but that
could just be coincidental.

Best,
Christian

Bug#1071000: sbuild-qemu: runs lintian on .changes file with Distribution != changelog target and lintian complains

[Christian Kastner]

Hi,

@josch, sorry, I overlooked that you referenced me earlier in this bug.

On 2024-05-14 12:12, Johannes Schauer Marin Rodrigues wrote:
> In general, you should avoid using -d or --dist with sbuild. But I see that
> sbuild-qemu always adds this option to the sbuild call. I am unable to say why
> it does that. Maybe Christian can clarify?

That's simple: because I wasn't aware of this side effect.

Internally, the distribution is set because some value is needed to
auto-guess the image name. It defaults to 'unstable' but if --dist is
set, its value is used is guessing the name.

This was actually wrong for many reasons. Another one would be that it
was passed on twice if the user used --dist.[1]

I just pushed a fix. Tested with
  $ sbuild-qemu --noexec foo
  $ sbuild-qemu --noexec --dist unstable foo
  $ sbuild-qemu --noexec --dist experimental --image /path/to/img foo

Best,
Christian

[1] Clean-up and proper tests are still on my TODO list :(

Bug#1030477: libx52pro0: New upstream release 0.3.0

[Christian Marillat]

On 12 mai 2024 10:52, Petter Reinholdtsen  wrote:

> [Christian Marillat 2023-02-04]
>> This package is still maintained ?
>> 
>> The last upload has been done in 2015
>
> Apparently not.  I just orphaned it, and moved the packaging to git on
> salsa.
>
> Do you know where the new upstream is located?  The d/watch file point
> to a obsolete source.

I discovered this one but the code isn't the same.

https://nirenjan.github.io/libx52/

https://github.com/nirenjan/libx52

Christian

Bug#1070984: mate-themes: Strange lines below title bar in maximized windows for Yaru and Traditional themes

[Christian Weiske]

Package: mate-themes
Version: 3.22.24-1
Severity: normal

Dear Maintainer,


Maximized windows show a distorted line below the title bar
when using the Mate desktop with one of the following window frame themes:
- TraditionalOk
- TraditionalGreen
- YaruOk
- YaruGreen
- MurrineRoundedLessFramed
- MurrineRoundedLessFramedIcon

The line changes now and then and looks like it is read from corrupted memory.

Screenshots:
- http://tmp.cweiske.de/bug-mate-theme/appearance_maximized.png
- http://tmp.cweiske.de/bug-mate-theme/appearance_non-maximized.png
- http://tmp.cweiske.de/bug-mate-theme/traditional-green_2.png
- http://tmp.cweiske.de/bug-mate-theme/traditional-ok.png
- http://tmp.cweiske.de/bug-mate-theme/yaru-green.png
- http://tmp.cweiske.de/bug-mate-theme/yaru-ok.png


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

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 mate-themes depends on:
ii  gtk2-engines  1:2.20.2-5+b2
ii  gtk2-engines-murrine  0.98.2-4
ii  gtk2-engines-pixbuf   2.24.33-4
ii  librsvg2-common   2.58.0+dfsg-1
ii  mate-icon-theme   1.26.0-1

mate-themes recommends no packages.

mate-themes suggests no packages.

-- no debconf information

Bug#1070773: libglib2.0-dev: dependency on python seems broken for multi-arch?

[Christian Klein]

Package: libglib2.0-dev
Version: 2.80.0-10
Severity: normal
X-Debbugs-Cc: dvl...@gmail.com

I install both the i386 and amd64 version for multi-arch support.

With the newest versions, a dependency to python was added.

Unfortunately, the package has two dependencies for python:
"python3:any"
and
"python3 | qemu-user | qemu-user-static".

While python3:any is satisfied by the amd64 version of python, the second the
second dependency  resolves to "python3:i386", which is not co-installable with
python:amd64.
So, I now have to install qemu-user as dependency, which comes with a few other
heavy dependencies. Is this really needed, and how does that help at all?


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (999, 'unstable'), (998, 'testing'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'proposed-updates'), (350, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libglib2.0-dev depends on:
ii  libc6  2.38-8
ii  libffi-dev 3.4.6-1
ii  libffi83.4.6-1
ii  libgirepository-2.0-0  2.80.0-10
ii  libglib2.0-0t642.80.0-10
ii  libglib2.0-bin 2.80.0-10
ii  libglib2.0-dev-bin [libglib2.0-dev-bin-linux]  2.80.0-10
ii  libmount-dev   2.40-8
ii  libpcre2-dev   10.42-4+b1
ii  libselinux1-dev3.5-2+b2
ii  libsysprof-capture-4-dev   46.0-1
ii  pkgconf1.8.1-1+b2
ii  python33.11.8-1
ii  qemu-user  1:8.2.3+ds-2
ii  zlib1g-dev 1:1.3.dfsg-3.1

libglib2.0-dev recommends no packages.

Versions of packages libglib2.0-dev suggests:
ii  gir1.2-glib-2.0-dev  2.80.0-10
pn  libglib2.0-doc   

-- no debconf information

Bug#1070481: quotatool: Failed setting gracetime (generic): Invalid argument

[Christian Schwamborn]

Package: quotatool
Version: 1.6.2-6

quotatool fails trying to adjust the grace time:

0 root@test-fs:~$ quotatool -vvv -u -b -t "2 weeks" /home
quotatool: option: 'v', argument: '(null)'
quotatool: option: 'u', argument: '(null)'
quotatool: not mangling: NULL user
quotatool: using uid (null)
quotatool: option: 'b', argument: '(null)'
quotatool: working with block limits
quotatool: option: 't', argument: '2 weeks'
quotatool: using filesystem /home
quotatool: Looking for fs_spec '/home'
quotatool: Checking device 'sysfs', mounted at '/sys'
... snip ...
quotatool: Checking device '/dev/xvdb1', mounted at '/home'
quotatool: filesystem /home has device node /dev/xvdb1
quotatool: Detecting quota format
quotatool: Detected quota format: VFSV1
quotatool: Detected quota interface: GENERIC
quotatool: fetching quotas: device='/dev/xvdb1',id='0'
quotatool:
quotatool: Limit  Old  New
quotatool: -  ---  ---
quotatool: block grace:   252001209600
quotatool: Failed setting gracetime (generic): Invalid argument
3 root@test-fs:~$

As the dev of this tool figured out, there where some quota api changes
in the more recent kernels (including bookwoorms kernel) causing this to
fail.

Since 1.6.3 and 1.6.4 are pure bugfix releases it shouldn't be an issue
updating this tool without breaking anything in the system. As I guess
that it's against debian policy to bump up the version, might it be
possible to get this in backports?

A quick test of the current git version 1.6.4 in bookworm confirmed its
functionality again.

0 root@test-fs:~/quotatool/git/quotatool-master_1.6.4$ ./quotatool -vvv
-u -b -t "2 weeks" /home
quotatool: option: 'v', argument: '(null)'
quotatool: option: 'u', argument: '(null)'
quotatool: not mangling: NULL user
quotatool: using uid (null)
quotatool: option: 'b', argument: '(null)'
quotatool: working with block limits
quotatool: option: 't', argument: '2 weeks'
quotatool: using filesystem /home
quotatool: Looking for fs_spec '/home'
quotatool: Checking device 'sysfs', mounted at '/sys'
... snip ...
quotatool: Checking device '/dev/xvdb1', mounted at '/home'
quotatool: filesystem /home has device node /dev/xvdb1
quotatool: Detecting quota format
quotatool: Detected quota format: VFSV1
quotatool: Detected quota interface: GENERIC
quotatool: fetching quotas: device='/dev/xvdb1',id='0'
quotatool:
quotatool: Limit  Old  New
quotatool: -  ---  ---
quotatool: block grace:   252001209600
quotatool: >> set global block gracetime
0 root@test-fs:~/quotatool/git/quotatool-master_1.6.4$

Best regards
Christian

Bug#1069899: lvm2: do not copy SELinux contexts in initramfs hook

[Christian Göttsche]

Package: lvm2
Version: 2.03.22-1
User: selinux-de...@lists.alioth.debian.org
Usertags: selinux
Tags: patch

Dear Maintainer,

when copying files into the temporary initramfs working directory the
SELinux security contexts are copied verbatim.
This can lead to issue when the original context is not allowed on the
destination filesystem and the process needs elevated access to the
original context.

See 
https://salsa.debian.org/debian/plymouth/-/commit/3edb1985b586b8362ef206c894ba6926f96e2e5f
for a similar situation in plymouth.
See https://salsa.debian.org/lvm-team/lvm2/-/merge_requests/3 for a
salsa merge request.

Regards,
   Christian Göttsche

diff --git a/debian/initramfs-tools/lvm2/hooks/lvm2
b/debian/initramfs-tools/lvm2/hooks/lvm2
index b28901a01..46a01b615 100755
--- a/debian/initramfs-tools/lvm2/hooks/lvm2
+++ b/debian/initramfs-tools/lvm2/hooks/lvm2
@@ -16,7 +16,7 @@ esac

. /usr/share/initramfs-tools/hook-functions

-cp -a /etc/lvm/ ${DESTDIR}/etc/lvm/
+cp -dRp /etc/lvm/ ${DESTDIR}/etc/lvm/

mkdir -p $DESTDIR/lib/udev/rules.d/
for rules in 56-lvm.rules 69-lvm.rules; do

Bug#747303: openssh-server: Please move pam_selinux open call higher in the session PAM stack

[Christian Göttsche]

Kindly ping.

Anything missing or unclear?

Regards,
   Christian Göttsche

Bug#1069027: python3-notebook: Jupyter Notebook fails to start - wrong call to traitlets.warn

[Christian Holm Christensen]

Package: python3-notebook
X-Debbugs-Cc: chol...@gmail.com
Version: 6.4.12-2.2
Severity: grave
Justification: renders package unusable

When launching `jupyter notebook`, the following stack-trace is produced:

Begin stack-trace
```
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 235, in
_resolve_classes
klass = self._resolve_string(klass)
^^^
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 2015, in
_resolve_string
return import_item(string)
   ^^^
  File "/usr/lib/python3/dist-packages/traitlets/utils/importstring.py", line
33, in import_item
module = __import__(package, fromlist=[obj])
 ^^^
ModuleNotFoundError: No module named 'jupyter_server.contents'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/jupyter-notebook", line 33, in 
sys.exit(load_entry_point('notebook==6.4.12', 'console_scripts', 'jupyter-
notebook')())
^
  File "/usr/lib/python3/dist-packages/jupyter_core/application.py", line 282,
in launch_instance
super().launch_instance(argv=argv, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line
1073, in launch_instance
app = cls.instance(**kwargs)
  ^^
  File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", line
583, in instance
inst = cls(*args, **kwargs)
   
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1292, in
__new__
inst.setup_instance(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1335, in
setup_instance
super(HasTraits, self).setup_instance(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1311, in
setup_instance
init(self)
  File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 226, in
instance_init
self._resolve_classes()
  File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 238, in
_resolve_classes
warn(f"{klass} is not importable. Is it installed?", ImportWarning)
TypeError: warn() missing 1 required keyword-only argument: 'stacklevel'
```
End stack-trace

The offending line is line 238 of `/usr/lib/python3/dist-
packages/notebook/traittypes.py` where `traitlets.warn` is called

```
 warn(f"{klass} is not importable. Is it installed?", ImportWarning)
```

The call fails to provide the required keyword argument `stacklevel` as seen in
line 9 of

```
/usr/lib/python3/dist-packages/traitlets/utils/warnings.py
```

A solution could be to patch the `jypyter-notebook` sources, though that would
probably need to be done in many places, or perhaps and update to newer
sources.

Yours,
Christian



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

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

Versions of packages python3-notebook depends on:
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1
ii  libjs-backbone 1.4.1~dfsg+~1.4.15-3
ii  libjs-bootstrap3.4.1+dfsg-3
ii  libjs-bootstrap-tour   0.12.0+dfsg-5
ii  libjs-codemirror   5.65.0+~cs5.83.9-3
ii  libjs-es6-promise  4.2.8-12
ii  libjs-jed  1.1.1-4
ii  libjs-jquery   3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-typeahead 2.11.0+dfsg1-3
ii  libjs-jquery-ui1.13.2+dfsg-1
ii  libjs-marked   4.2.3+ds+~4.0.7-3
ii  libjs-mathjax  2.7.9+dfsg-1
ii  libjs-moment   2.29.4+ds-1
ii  libjs-requirejs2.3.6+ds+~2.1.34-2
ii  libjs-requirejs-text   2.0.12-1.1
ii  libjs-text-encoding0.7.0-5
ii  libjs-underscore   1.13.4~dfsg+~1.11.4-3
ii  libjs-xterm5.3.0-2
ii  python33.11.8-1
ii  python3-argon2 21.1.0-2
ii  python3-ipykernel  6.29.3-1
ii  python3-ipython-genutils   0.2.0-6
ii  python3-jinja2 3.1.3-1
ii  python3-jupyter-client 7.4.9-2
ii  python3-jupyter-core   5.3.2-1
ii  python3-nbconvert  6.5.3-5
ii  python3-nbformat   5.9.1-1
ii  python3-nest-asyncio   1.5.4-1
ii  python3-prometheus-client  0.19.0+ds1-1
ii  python3-send2trash 1.8.2-1
ii  python3-terminado  0.18.0-1
ii  python3-tornado6.4.0-1
ii  python3-trai

Bug#960729: More issues trying to create an Ubuntu focal image

[Christian Kastner]

On 2024-04-11 15:25, Paride Legovini wrote:
> On 2024-04-11 08:35, Christian Kastner wrote:
> Ubuntu did indeed switch to something else: that's netplan.io.
> On a Bionic system:
> 
> $ apt show netplan.io
> Package: netplan.io
> Version: 0.99-0ubuntu3~18.04.5
> Priority: important
Oh, that explains ifupdown moving to universe, I guess...

> So we have another option: teach setup-testbed how to configure
> netplan.

> This would be a more realistic setup for a modern Ubuntu system,
> and won't need any extra dependency outside of what debootstrap
> installs automatically.

I think "more realistic" is a strong argument for a test environment.
And if the package is already installed, adding the configuring step
seems the simplest solution.

Best,
Christian

Bug#960729: More issues trying to create an Ubuntu focal image

[Christian Kastner]

On 2024-04-11 09:27, Paul Gevers wrote:
>> (2) Modify setup-commands/setup-testbed and generally move ifupdown
>>  installation there. This would require re-ordering stuff, as
>>  interface configuration is currently performed *before* APT
>>  configuration, when in needs to be after (otherwise ifupdown can't
>>  be downloaded from universe).
> 
> I'm against this route. I think we should require images to have
> networking to not grow the setup script even more than needed.
> Networking is nothing special, it should just be there.

I concur. From my first experiments with this, the script just felt like
the wrong place. It involves guessing the testbed type, and it would
require somewhat nuanced restructuring of the script.

And as long as universe is enabled unconditionally in the post-build
image customization by setup-command, limiting the build to main doesn't
seem to gain much.

Best,
Christian

Bug#960729: More issues trying to create an Ubuntu focal image

[Christian Kastner]

Control: tags -1 - pending

On 2024-04-08 15:21, Paride Legovini wrote:
> Fixed in master by:
> 
> https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/315

Sadly, it turns out that this wasn't the fix, at least not in a wider sense.

Yes, images can be built now, but without ifupdown their network
interface is left unconfigured, and thus autopkgtests can't download
packages.

With the move of ifupdown to universe, I was assuming that Ubuntu did
things differently. The cloud images *do* things differently, namely
they have systemd-networkd. But autopkgtest allows for alternative init
systems, so we can't rely on that.

So ifupdown seems to be needed, and this poses an interesting problem
with at least the following possible solutions:

(1) Enable universe in autopkgtest-build-qemu after all, as in [1]

(2) Modify setup-commands/setup-testbed and generally move ifupdown
installation there. This would require re-ordering stuff, as
interface configuration is currently performed *before* APT
configuration, when in needs to be after (otherwise ifupdown can't
be downloaded from universe).

Note that (1) and (2) don't exclude each other. One could do (1) to fix
things short-term, then implement (2).

And of course, there could be other solutions. And though I'm doing more
and more Ubuntu stuff, I'm not yet familiar enough to propose better ideas.

Best,
Christian

PS: Apologies for not discovering this right away, I was having troubles
getting images to boot, but that's fixed now.

[1] https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/309

Bug#1068748: autopkgtest-build-qemu: Ubuntu EFI VMs fail to boot

[Christian Kastner]

On 2024-04-10 15:29, Simon McVittie wrote:
> On Wed, 10 Apr 2024 at 11:54:02 +0200, Christian Kastner wrote:
>> I've already filed an MR at vmdb2 upstream that fixes the logic, but I
>> thought it might be best to track the issue here as well. Please feel
>> free to close this bug if you think it is superfluous.
> 
> If there's no actionable bug in autopkgtest, and a fix in vmdb2 will
> automatically fix autopkgtest without any autopkgtest code changes being
> required or desirable, then the usual way to represent that would be to
> give the vmdb2 bug report an "affects" on autopkgtest.

Good to know, thanks. I've marked vmdb2's bug as such.

How does this discoverability? Do "affects" bugs appear in the BTS view
of the affected package? (I'm thinking of the zerofree issue for
example, which was also a vmdb2 issue, but users reported it against
autopkgtest and sbuild-qemu).

I'll leave it open to the maintainers to determine if a code change is
desirable (eg: bump dependency) or if this bug here can be closed.

Best,
Christian

Bug#1068748: autopkgtest-build-qemu: Ubuntu EFI VMs fail to boot

[Christian Kastner]

Package: autopkgtest
Version: 5.34
Severity: normal
Block: -1 by 1068746

When building an Ubuntu image with autopkgtest-build-qemu and using
--boot=efi, the resulting image fails to boot when running autopkgtests
on it.

An attempted manual boot with qemu-system-x86_64 shows EFI complaining
about some disk not found.

The cause for this is #1068746, vmdb2 invoking grub-install with flipped
logic on Ubuntu, related to #951766.

I've already filed an MR at vmdb2 upstream that fixes the logic, but I
thought it might be best to track the issue here as well. Please feel
free to close this bug if you think it is superfluous.

Best,
Christian

Bug#1068746: vmdb2: Flipped boolean argument breaks Ubuntu EFI boot

[Christian Kastner]

Package: vmdb2
Version: 0.28-2
Severity: normal
Forwarded: https://gitlab.com/larswirzenius/vmdb2/-/merge_requests/143

In #951766, grub's --force-extra-movable (Debian) was conditionalized
for Ubuntu grub's --no-extra-removable. But the logic is flipped: where
Debian uses --force-extra-removable, Ubuntu does this by default, so it
should simply be omitted.

Best,
Christian

Bug#1068735: Trying to overwrite libpmix.so.2, which is also in package libpmix2t64:armhf

[Christian Marillat]

Package: libopenmpi3t64
Version: 4.1.6-8
Severity: serious
X-Debbugs-Cc: maril...@deb-multimedia.org

Hi,

apt-get error message :

Unpacking libopenmpi3t64:armhf (4.1.6-9) over (4.1.6-8) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-0UNMnK/4-libopenmpi3t64_4.1.6-9_armhf.deb (--unpack):
 trying to overwrite '/usr/lib/arm-linux-gnueabihf/libpmix.so.2', which is also 
in package libpmix2t64:armhf 5.0.1-4.1

Christian

-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 6.1.83 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
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)

Versions of packages libopenmpi3t64 depends on:
ii  libc6   2.37-16
ii  libevent-core-2.1-7t64  2.1.12-stable-8.1+b3
ii  libevent-pthreads-2.1-7t64  2.1.12-stable-8.1+b3
ii  libfabric1  1.17.0-3+b1
ii  libgcc-s1   14-20240330-1
ii  libhwloc-plugins2.10.0-1+b1
ii  libhwloc15  2.10.0-1+b1
ii  libibverbs1 50.0-2+b1
ii  libnl-3-200 3.7.0-0.3
ii  libstdc++6  14-20240330-1
ii  zlib1g  1:1.3.dfsg-3.1

libopenmpi3t64 recommends no packages.

libopenmpi3t64 suggests no packages.

-- no debconf information

Bug#388408: Text to work around #898685

[Henrik Christian Grove]

Control: submitter -1 !

Bug#1050588: bookworm-pu: package nsis/3.08-3+deb12u1

[Christian Franke]

Jonathan Wiltshire wrote:

...
Thanks. The bug #1050288 isn't fixed in unstable according to the BTS,
which is a requirement. What's the status?


The problem described in #1050288 does not longer occur since NSIS 3.09. 
The problem appeared in Debian 12 because the Mingw-w64 toolchain now 
enables ASLR (and therefore emits relocation information) by default but 
NSIS does not support relocation information. NSIS upstream addressed 
this in the build recipes of 3.09.


I could confirm that this has the desired effect:
In the smartmontools project, we use a Debian 12 based docker image for 
reproducible CI builds (https://builds.smartmontools.org/). After 
forcibly upgrading NSIS to 3.09 from Debian trixie, the problem 
disappeared. Here the related commit:

https://github.com/smartmontools/docker-build/commit/9b231f0

Therefore I guess that #1050288 is also fixed in unstable.

--
Regards,
Christian

Bug#1068623: Right patch

[Christian Marillat]

On 08 avril 2024 07:15, "Debian Bug Tracking System"  
wrote:

Here is the right patch (missing !m68k)

diff -Nru mpg123-1.32.6/debian/libmpg123-0t64.symbols 
mpg123-1.32.6/debian/libmpg123-0t64.symbols
--- mpg123-1.32.6/debian/libmpg123-0t64.symbols 2024-04-05 23:18:03.0 
+0200
+++ mpg123-1.32.6/debian/libmpg123-0t64.symbols 2024-04-08 09:05:11.0 
+0200
@@ -136,4 +136,4 @@
  mpg123_volume_change@Base 1.6.2
  mpg123_volume_change_db@Base 1.30.0
 (arch=i386 hurd-i386)#include "libmpg123-0t64.symbols.32bit.in"
-(arch=!armel !armhf !hppa !mipsel !ppc !sh4 !x32)#include 
"libmpg123-0t64.symbols.t64.in"
+(arch=!armel !armhf !hppa !mipsel !powerpc !m68k !sh4 !x32)#include 
"libmpg123-0t64.symbols.t64.in"
diff -Nru mpg123-1.32.6/debian/libsyn123-0t64.symbols 
mpg123-1.32.6/debian/libsyn123-0t64.symbols
--- mpg123-1.32.6/debian/libsyn123-0t64.symbols 2024-04-05 23:17:58.0 
+0200
+++ mpg123-1.32.6/debian/libsyn123-0t64.symbols 2024-04-08 09:05:11.0 
+0200
@@ -32,14 +32,14 @@
  syn123_resample_incount@Base 1.26.0
  syn123_resample_inexpect@Base 1.26.0
  syn123_resample_intotal64@Base 1.32.3
- (arch=!armel !armhf !hppa !mipsel !ppc !sh4 !x32)syn123_resample_intotal@Base 
1.26.2
+ (arch=!armel !armhf !hppa !mipsel !powerpc !m68k !sh4 
!x32)syn123_resample_intotal@Base 1.26.2
  (arch=i386 hurd-i386)syn123_resample_intotal_32@Base 1.26.2
  syn123_resample_intotal_64@Base 1.26.0
  syn123_resample_maxincount@Base 1.26.0
  syn123_resample_maxrate@Base 1.26.0
  syn123_resample_out@Base 1.32.3
  syn123_resample_total64@Base 1.32.3
- (arch=!armel !armhf !hppa !mipsel !ppc !sh4 !x32)syn123_resample_total@Base 
1.26.2
+ (arch=!armel !armhf !hppa !mipsel !powerpc !m68k !sh4 
!x32)syn123_resample_total@Base 1.26.2
  (arch=i386 hurd-i386)syn123_resample_total_32@Base 1.26.2
  syn123_resample_total_64@Base 1.26.0
  syn123_setup_filter@Base 1.26.0

Bug#1068623: mpg123: FTBFS Wrong architectures in symbols file

[Christian Marillat]

Source: mpg123
Version: 1.32.6-2
Severity: important

Dear Maintainer,

These symbols files :

debian/libmpg123-0t64.symbols
debian/libsyn123-0t64.symbol

Contains the wrong architecture name for ppc instead of powerpc and missing m68k

The patch below fix this issue.

Build tested for powerpc arch.

Christian

,
| diff -Nru mpg123-1.32.6/debian/libmpg123-0t64.symbols 
mpg123-1.32.6/debian/libmpg123-0t64.symbols
| --- mpg123-1.32.6/debian/libmpg123-0t64.symbols   2024-04-08 
08:49:49.0 +0200
| +++ mpg123-1.32.6/debian/libmpg123-0t64.symbols   2024-04-05 
23:18:03.0 +0200
| @@ -136,4 +136,4 @@
|   mpg123_volume_change@Base 1.6.2
|   mpg123_volume_change_db@Base 1.30.0
|  (arch=i386 hurd-i386)#include "libmpg123-0t64.symbols.32bit.in"
| -(arch=!armel !armhf !hppa !mipsel !powerpc !sh4 !x32)#include 
"libmpg123-0t64.symbols.t64.in"
| +(arch=!armel !armhf !hppa !mipsel !ppc !sh4 !x32)#include 
"libmpg123-0t64.symbols.t64.in"
| diff -Nru mpg123-1.32.6/debian/libsyn123-0t64.symbols 
mpg123-1.32.6/debian/libsyn123-0t64.symbols
| --- mpg123-1.32.6/debian/libsyn123-0t64.symbols   2024-04-08 
08:50:08.0 +0200
| +++ mpg123-1.32.6/debian/libsyn123-0t64.symbols   2024-04-05 
23:17:58.0 +0200
| @@ -32,14 +32,14 @@
|   syn123_resample_incount@Base 1.26.0
|   syn123_resample_inexpect@Base 1.26.0
|   syn123_resample_intotal64@Base 1.32.3
| - (arch=!armel !armhf !hppa !mipsel !powerpc !sh4 
!x32)syn123_resample_intotal@Base 1.26.2
| + (arch=!armel !armhf !hppa !mipsel !ppc !sh4 
!x32)syn123_resample_intotal@Base 1.26.2
|   (arch=i386 hurd-i386)syn123_resample_intotal_32@Base 1.26.2
|   syn123_resample_intotal_64@Base 1.26.0
|   syn123_resample_maxincount@Base 1.26.0
|   syn123_resample_maxrate@Base 1.26.0
|   syn123_resample_out@Base 1.32.3
|   syn123_resample_total64@Base 1.32.3
| - (arch=!armel !armhf !hppa !mipsel !powerpc !sh4 
!x32)syn123_resample_total@Base 1.26.2
| + (arch=!armel !armhf !hppa !mipsel !ppc !sh4 !x32)syn123_resample_total@Base 
1.26.2
|   (arch=i386 hurd-i386)syn123_resample_total_32@Base 1.26.2
|   syn123_resample_total_64@Base 1.26.0
|   syn123_setup_filter@Base 1.26.0
`


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

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

Bug#1068588: redesign of how autopkgtest talks to the testbed

[Christian Kastner]

Hi Paul,

On 2024-04-07 16:42, Paul Gevers wrote:
> The following issues have come up several times over the years. I
> propose to discuss them in one place (this bug report) to define the
> solution strategy. I haven't gone through all the details myself, so I
> might be thinking in the wrong direction, please correct me if you think
> so. Please also voice agreement, if not on the details, then on the
> general concept.

I'm not a maintainer but I use autopkgtest a lot. I hope it's OK if I
contribute input.

I generally agree with all of what you said, and would add the following:

> * [mostly orthogonal] currently the autopkgtest code has a lot of state
> in a non-Pythonic way. Reasoning about what goes on and debugging
> autopkgtest code flow is non-trivial.

It is indeed very difficult to keep track of what's going on. A lot of
state is kept in/communicated through globals, and it can be challenging
to remember which role the running threads are playing, and in which
relationship.

(smcv put this into historical context once.)

> Solution direction
> ==
> * handle communication between runner/autopkgtest and the virt servers
> and the ssh driver via Python classes instead of the text based
> protocol. Do this in a "plugin" friendly way such that backends can
> still easily be used without changes to src:autopkgtest.

I would add to this that testbed I/O and test I/O could benefit from
separate communications channels.

Example: the Debian ROCm Team requested the --timeout-poweroff option
for the QEMU backend because the hardware we pass in needs a clean
shutdown procedure. But it is not possible to trigger a shutdown when a
test is running, because on the I/O channel is being waited on for
output. So a timeout still ends with a SIGTERM of the testbed.

Best,
Christian

Bug#1033352: Not pending

[Christian Kastner]

Control: tags -1 - pending

I close the proposed MR implementing this as in light of the recently
published workaround, it is too invasive.

Bug#1068536: gnome-shell-extension-shortcuts: Wrong dependencies gnome-shell-extension-shortcuts in experimental (tag 1.5.x supports GNOME 46)

[Christian Lauinger]

Package: gnome-shell-extension-shortcuts
Version: 1.5.1-1~exp1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
tried to install gnome-shell-extension-shortcuts from experimental
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
cannot do anything
   * What was the outcome of this action?
gnome-shell-extension-shortcuts hängt ab von gnome-shell (<< 46~); aber:
  Version von gnome-shell auf dem System ist 46.0-1.
   * What outcome did you expect instead?
installation of the package


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

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

Versions of packages gnome-shell-extension-shortcuts depends on:
ii  gnome-shell  46.0-1

gnome-shell-extension-shortcuts recommends no packages.

gnome-shell-extension-shortcuts suggests no packages.

-- no debconf information

Bug#1068465: closed by Guilhem Moulin (Re: Bug#1068465: plugin thunderbird_labels and keyboard_shortcuts causing traces)

[Christian Schwamborn]

Just out of curiosity: Why aren't those patches the current stable
bookworm package of roundcube-plugins-extra included?

On 05/04/2024 18.54, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the roundcube-plugins-extra package:
> 
> #1068465: plugin thunderbird_labels and keyboard_shortcuts causing traces
> 
> It has been closed by Guilhem Moulin .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Guilhem Moulin 
>  by
> replying to this email.
> 
> 

Bug#975509: ITP: nbdime -- Jupyter Notebook Diff and Merge tools

[Christian Kastner]

Hi Joe,

On 2020-11-23 06:03, Joseph Nahmias wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Joseph Nahmias 
> 
> * Package name: nbdime
>   Version : 2.1.0
>   Upstream Author : Jupyter Development Team 
> * URL : https://nbdime.readthedocs.io/
> * License : BSD
>   Programming Lang: Python
>   Description : Jupyter Notebook Diff and Merge tools
> 
> nbdime provides tools for diffing and merging of Jupyter Notebooks.

Xuanteng (in CC) is working on packages jupyter-cache and myst-nb, both
of which make use of nbdime in their test suites. We were wondering if
you could provide us with a status update for nbdime?

We gave our own brief look, after upgrading nbdime to 4.0.1, but the
build fails because npm tries to download source-map-loader:

> INFO:hatch_jupyter_builder.utils:> /usr/bin/npm install
> npm ERR! code ECONNREFUSED
> npm ERR! syscall connect
> npm ERR! errno ECONNREFUSED
> npm ERR! FetchError: request to 
> https://registry.npmjs.org/source-map-loader/-/source-map-loader-4.0.1.tgz 
> failed, reason: connect ECONNREFUSED 127.0.0.1:9

We've added it [1] and node-jupyterlab [2] to B-D as a stab in the dark,
but that didn't fix it. Unfortunately, we don't have experience with
node stuff in Debian.

Do you have an idea what's going on here? Otherwise I could ask on the
debian-js list.

Best,
Christian

[1] https://packages.debian.org/sid/node-source-map-loader
[2] https://packages.debian.org/sid/node-jupyterlab

Bug#1068465: plugin thunderbird_labels and keyboard_shortcuts causing traces

[Christian Schwamborn]

Package: roundcube-plugins-extra
Version: 1.4.10+1-4

I got an error like this, trying to set a message Flag:

[05-Apr-2024 15:16:54 UTC] PHP Warning:  Undefined property:
rcmail::$imap in
/usr/share/roundcube/plugins/thunderbird_labels/thunderbird_labels.php
on line 318
[05-Apr-2024 15:16:54 UTC] PHP Fatal error:  Uncaught TypeError:
array_merge(): Argument #1 must be of type array, null given in
/usr/share/roundcube/plugins/thunderbird_labels/thunderbird_labels.php:327

I think the issue is in function set_flags, around line 318 is a
definition '$imap = $this->rc->imap;'.
The object $this->rc->imap seems to be renamed to $this->rc->storage.
Changing this one line fixed the issue for me.

The same issue can be found in keyboard_shortcuts.
Replacing '$rcmail->imap' with '$rcmail->storage' between lines 104 and
109 fixes the issue there.

Bug#783011: Skip /etc/awstats/awstats.conf if it's not configured

[Christian Weiske]

I created several awstats.mydomain.conf files which all include the
default awstats.conf file as base config.

I'd prefer that awstats.conf is skipped once domain config files exist.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

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

[Christian Kastner]

On 2024-02-21 09:22, Christian Kastner wrote:
> On 2024-02-21 08:02, Johannes Schauer Marin Rodrigues wrote:
>> is this a duplicate of #1061388?
> 
> I *think* so, but I'm not sure.
> 
> The cause definitely seems to be the same: on the host, prior to opening
> the chroot, $HOME is set to /sbuild-nonexistent, which triggers these
> two bugs.
> 
> I'm not sure because I don't know if the $HOME thing above is buggy ,or
> it's correct (though strict) and autopkgtest-build-podman, incus, or
> something else needs fixing.
> 
> For example, in #1061388, a possible fix in incus is mentioned.
> 
> From my current understanding, this wouldn't work for podman, because
> its attempted use of $HOME/.config/local/*.conf is not just legitimate,
> I'd actually call it required.

I'm happy to say that I've found a workaround.

podman needs $HOME for runtime configuration and storage location, but
$HOME cannot be used even when put in ENVIRONMENT_FILTER.

However: podman also looks into the XDG_ directories, which *can* be
added to ENVIRONMENT_FILTER.

So by

(1) adding

  XDG_CACHE_HOME
  XDG_CONFIG_HOME
  XDG_DATA_HOME

to $environment_filter in .sbuildrc, and

(2) assuming that one has created a suitable container image with
autopkgtest-build-podman,

(3) one can run an autopkgtest with the podman backend as follows:

  $ export XDG_DATA_HOME="${XDG_DATA_HOME:-$HOME/.local/share}"
  $ export XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-$HOME/.config}"
  $ export XDG_CACHE_HOME="${XDG_CACHE_HOME:-$HOME/.cache}"

  $ sbuild \
--chroot-mode=autopkgtest \
--autopkgtest-virt-server=podman \
--autopkgtest-virt-server-opt= \
--purge-deps=never \
--apt-update --apt-upgrade \
--dist  \
<...>

If not for one missing variable->path mapping, one could even explicitly
set podman-specific variables, which would make integration much easier
because they could not affect any other part of sbuild.

Bug#1068022: Document the Testsuite-Triggers field

[Christian Kastner]

Hi again,

On 2024-03-29 20:30, Christian Kastner wrote:
> Policy 5.6.30 lists the Testsuite field, but it doesn't list the
> Testsuite-Triggers field that seems to be part of Sources files and is
> generated by dpkg-source >= 1.18.8.
> 
> This field is quite useful, as given my package src:foo, I can find out
> which packages have autopkgtests that depend on it, and are thus in the
> set of reverse dependencies that I could check for breakage.

I've read up on the change process [1], and I guess my proposal to
submit a patch was too far into the process.

Thus, I take a step back, and seek discussion first.

In addition to what I've said above, I think documenting this field
would not only enhance discoverability, but give more weight to it for
tooling that makes use of these fields.

For discussion context, I'd like to quote dsc(5) on this field:
> Testsuite-Triggers: package-list
> 
> This field declares the comma-separated union of all test dependencies 
> (Depends fields in debian/tests/control file), with all restrictions removed, 
> and OR dependencies flattened (that is, converted to separate AND 
> relationships), except for binaries generated by this source package and its 
> meta-dependency equivalent @.
> 
> Rationale: this field is needed because otherwise to be able to get the test 
> dependencies, each source package would need to be unpacked.
Best,
Christian

[1] https://www.debian.org/doc/debian-policy/ap-process.html

Bug#1068199: librocfft0: callback test failures on gfx900 and gfx1030

[Christian Kastner]

On 2024-04-04 09:05, Christian Kastner wrote:
> The issue is already visible with AMD_LOG_LEVEL=1, it's the lack of PCIe
> atomics:
> 
>> [ RUN  ] rocfft_UnitTest.default_load_callback_complex_single
>> :1:rocvirtual.cpp   :2949: 1796815625 us: [pid:1917  
>> tid:0x7f4a2102c980] Pcie atomics not enabled, hostcall not supported
>> :1:rocvirtual.cpp   :3289: 1796816120 us: [pid:1917  
>> tid:0x7f4a2102c980] AQL dispatch failed> clients/tests

> In an older ROCm ticket, a workaround to enable PCIe atomics in the
> guest was discussed [1], but I never got this to work. The relevant bit
> is not set after invoking setpci.

In a more recent issue [2], a lack of PCIe atomics was also discovered
on physical hardware (it can depend on the CPU and/or the PCIe slot).

In that issue, it was stated that updating to ROCm 6.0 (and PyTorch)
resolved the issue.

I just rebuilt rocfft to 6.0.2 but the issue is still present. But that
was naive, there are other < 6.0 components in the stack that could
affect this.

> [1] 
> https://github.com/ROCm/ROCK-Kernel-Driver/issues/26#issuecomment-313857180

[2] https://github.com/ROCm/ROCm/issues/2429

Bug#1068199: librocfft0: callback test failures on gfx900 and gfx1030

[Christian Kastner]

On 2024-04-02 00:35, Cordell Bloor wrote:
> I tried to reproduce the rocfft callback bug with a W6800 (gfx1030). I
> used a Debian Unstable docker container on an Ubuntu Noble host, but the
> tests all passed. This made me realize that the test failure pattern on
> the CI is that all the qemu-based workers are failing and all the
> podman-based workers are passing.
> 
> This issue seems to be somehow related to the qemu+rocm autopkgtest
> environment.

The issue is already visible with AMD_LOG_LEVEL=1, it's the lack of PCIe
atomics:

> half epsilon: 0.000977single epsilon: 3.75e-05double epsilon: 
> 1e-15
> Random seed: 1392424582
> rocFFT version: 1.0.23.
> Note: Google Test filter = 
> rocfft_UnitTest.default_load_callback_complex_single
> [==] Running 1 test from 1 test suite.
> [--] Global test environment set-up.
> [--] 1 test from rocfft_UnitTest
> [ RUN  ] rocfft_UnitTest.default_load_callback_complex_single
> :1:rocvirtual.cpp   :2949: 1796815625 us: [pid:1917  
> tid:0x7f4a2102c980] Pcie atomics not enabled, hostcall not supported
> :1:rocvirtual.cpp   :3289: 1796816120 us: [pid:1917  
> tid:0x7f4a2102c980] AQL dispatch failed> 
> clients/tests/default_callbacks_test.cpp:280: Failure
> Expected equality of these values:
>   rocfft_execute(plan, _ptr, _ptr, info)
> Which is: 1
>   rocfft_status_success
> Which is: 0
> 
> clients/tests/default_callbacks_test.cpp:310: Failure
> Expected: (diff.l_inf) < (type_epsilon()), actual: 32.230823516845703 
> vs 3.75e-05
> 
> [  FAILED  ] rocfft_UnitTest.default_load_callback_complex_single (907 ms)
> [--] 1 test from rocfft_UnitTest (908 ms total)

(I did not check all 130 failures, so strictly speaking there could be
additional causes, too.)

In an older ROCm ticket, a workaround to enable PCIe atomics in the
guest was discussed [1], but I never got this to work. The relevant bit
is not set after invoking setpci.

I don't know how to best address this. A workaround would be to skip
these tests if the host is a guest VM, but that would reduce coverage.
However, switching everything to podman would reduce coverage even more
if we only use the latest kernel.

Best,
Christian

PS: Full AMD_LOG_LEVEL=4 attached, for reference.

[1] https://github.com/ROCm/ROCK-Kernel-Driver/issues/26#issuecomment-313857180half epsilon: 0.000977  single epsilon: 3.75e-05double epsilon: 1e-15
Random seed: 3631874771
rocFFT version: 1.0.23.
Note: Google Test filter = rocfft_UnitTest.default_load_callback_complex_single
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from rocfft_UnitTest
[ RUN  ] rocfft_UnitTest.default_load_callback_complex_single
:3:rocdevice.cpp:442 : 1761239558 us: [pid:1890  
tid:0x7f13ab583980] Initializing HSA stack.
:3:rocdevice.cpp:208 : 1761720693 us: [pid:1890  
tid:0x7f13ab583980] Numa selects cpu 
agent[0]=0x563d5daf67a0(fine=0x563d4cdd0020,coarse=0x563d5db0c3b0) for gpu 
agent=0x563d5db36800 CPU<->GPU XGMI=0
:3:rocdevice.cpp:1680: 1761721192 us: [pid:1890  
tid:0x7f13ab583980] Gfx Major/Minor/Stepping: 10/3/0
:3:rocdevice.cpp:1682: 1761722377 us: [pid:1890  
tid:0x7f13ab583980] HMM support: 0, XNACK: 0, Direct host access: 0
:3:rocdevice.cpp:1684: 1761722570 us: [pid:1890  
tid:0x7f13ab583980] Max SDMA Read Mask: 0x0, Max SDMA Write Mask: 0x0
:4:rocdevice.cpp:2063: 1761722742 us: [pid:1890  
tid:0x7f13ab583980] Allocate hsa host memory 0x7f13a9dfc000, size 0x38
:4:rocdevice.cpp:2063: 1761723175 us: [pid:1890  
tid:0x7f13ab583980] Allocate hsa host memory 0x7f129570, size 0x101000
:4:rocdevice.cpp:2063: 1761723636 us: [pid:1890  
tid:0x7f13ab583980] Allocate hsa host memory 0x7f129550, size 0x101000
:4:runtime.cpp  :83  : 1761723779 us: [pid:1890  
tid:0x7f13ab583980] init
:3:hip_context.cpp  :48  : 1761723839 us: [pid:1890  
tid:0x7f13ab583980] Direct Dispatch: 1
:3:hip_memory.cpp   :1302: 1761724035 us: [pid:1890  
tid:0x7f13ab583980]  hipMemcpyFromSymbol ( 0x563d4bfa06c8, 0x7fff49c710f8, 
8, 0, hipMemcpyDeviceToHost ) 
:3:devprogram.cpp   :2681: 1761725089 us: [pid:1890  
tid:0x7f13ab583980] Using Code Object V4.
:3:rocdevice.cpp:2230: 1761730456 us: [pid:1890  
tid:0x7f13ab583980] device=0x563d5db5ff10, freeMem_ = 0x3fef8
:3:rocdevice.cpp:2732: 1761730568 us: [pid:1890  
tid:0x7f13ab583980] number of allocated hardware queues with low priority: 0, 
with normal priority: 0, with high priority: 0, maximum per priority is: 4
:3:rocdevice.cpp:2810: 1761734314 us: [pid:1890  
tid:0x7f13ab583980] created hardware queue 0x7f13a9d7c000 with size 16384 with 
priority 1, cooperative: 0
:3:rocdevice.cpp   

Bug#849741: Text to work around #898685

[Henrik Christian Grove]

Control: submitter -1 !

Bug#1068199: librocfft0: callback test failures on gfx900 and gfx1030

[Christian Kastner]

Hey Cory,

thank you for the analysis. I'll try to reproduce and lock this down on
my end, too.

Best,
Christian

On 2024-04-02 00:35, Cordell Bloor wrote:
> I tried to reproduce the rocfft callback bug with a W6800 (gfx1030). I
> used a Debian Unstable docker container on an Ubuntu Noble host, but the
> tests all passed. This made me realize that the test failure pattern on
> the CI is that all the qemu-based workers are failing and all the
> podman-based workers are passing.
> 
> This issue seems to be somehow related to the qemu+rocm autopkgtest
> environment.

Bug#1068022: Document the Testsuite-Triggers field

[Christian Kastner]

Hi Sean,

On 2024-03-30 02:35, Sean Whitton wrote:
>> I'd provide a patch based on the documentation in dsc(5), but I don't
>> know what the current process is. Does anyone have a link to a doc on
>> how to submit a change?
> 
> There is a chapter of Policy regarding the Policy Changes Process.

ironically enough, I did find that one before I submitted, but I didn't
see this as a Policy change, instead as documenting a change that had
already happened. Which, in hindsight, was of course an erroneous
assumption.

I'll continue on the proper process after the three-day-weekend here in
Austria.

Best,
Christian

Bug#1068022: Document the Testsuite-Triggers field

[Christian Kastner]

Package: debian-policy
Version: 4.6.2.0
Severity: wishlist

Policy 5.6.30 lists the Testsuite field, but it doesn't list the
Testsuite-Triggers field that seems to be part of Sources files and is
generated by dpkg-source >= 1.18.8.

This field is quite useful, as given my package src:foo, I can find out
which packages have autopkgtests that depend on it, and are thus in the
set of reverse dependencies that I could check for breakage.

I'd provide a patch based on the documentation in dsc(5), but I don't
know what the current process is. Does anyone have a link to a doc on
how to submit a change?

Best,
Christian

Bug#1067955: www.debian.org: Unclear why "Ubunut keyserver" is used in this description

[Christian Buhtz]

Package: www.debian.org
Severity: normal

This is about this page:

https://keyring.debian.org/creating-key.html

In the end of that page "keyserver.ubuntu.com" is used as a key server. But
page is about Debian. This section should make clear why Ubuntu is involved
here and if it needs to be that way.

Kind
Christian

Bug#1067949: www.debian.org: No language selection on "www.debian.org/doc/manuals/maint-guide/"

[Christian Buhtz]

Package: www.debian.org
Severity: normal
X-Debbugs-Cc: 924889-subscr...@bugs.debian.org

Hello,

this is about

<https://www.debian.org/doc/manuals/maint-guide/>

There is no option to select the language of that document. I always see the
translated version (in my case German). But I want to see the original of
course.

I am aware that I can manipulate the URL but that is not a solution just a
workaround.

The footer do not offer other languages like some other debian.org pages do.

Kind
Christian Buhtz

Bug#1067939: wiki.debian.org: Move "ITP" page into Developers Reference (or decide against it)

[Christian Buhtz]

Package: wiki.debian.org
Severity: normal

Dear Maintainers,

My request is about this wiki page:

<https://wiki.debian.org/ITP>

The first paragraph say that this content should be moved into the
Developers Reference.

I am not experienced enough to do it nor to decide it. I put the Dev Ref people
into CC.

Finishing such TODO comments and also removing them from the Wiki will IMHO
increase the professional image of Debian itself.

Thanks in advance,
Christian Buhtz

Bug#1061816: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Christian Kastner]

Hi josch,

On 2024-03-28 11:28, Johannes Schauer Marin Rodrigues wrote:
> I think sbuild-qemu-boot and sbuild-qemu-update should do the same as
> autopkgtest did here:
> 
> https://salsa.debian.org/ci-team/autopkgtest/-/commit/7a4954ded0f24221ac34ca0aaf10f3f9b083afa2

Thanks for pointing this out! Applied (though stupidly, with two commits.)

Though if I understand #1061816 correctly, then this should probably be
a separate bug, right? (Wanted to check before I clone)

Best,
Christian

Bug#849741: (no subject)

[Henrik Christian Grove]

Control: submitter -1 !

Bug#1042976: #1042976 seems to be solved

[Christian Britz]

The problem seems to be solved for arm64 with current version in
bookworm 3.6-4+deb12u1

Bug#1067427: dpkg-dev: Fail to generate a substitution variable ${t64:Provides} (time_t transition)

[Christian Marillat]

On 21 mars 2024 15:41, Simon McVittie  wrote:


[...]

>  4. armel, armhf are the two 32-bit release architectures which are
> not in any of the previous categories, so they are genuinely changing
> their ABIs.
> Non-release architectures in the same category: hppa m68k powerpc sh4.
>
> On these architectures, libopenshot-audio9t64 must not have a Provides
> on libopenshot-audio9, because its ABI has changed, so the new library
> does not provide an interface that is compatible with the old library.
> (This is the reason why we're doing all this renaming!)

I did not know.

> So I think this is not a bug, and certainly not a RC bug. The warnings are
> a bit annoying, but do not indicate a genuine problem.

Yes of course, you can close this bug.

Christian

Bug#1067427: dpkg-dev: Fail to generate a substitution variable ${t64:Provides} (time_t transition)

[Christian Marillat]

Package: dpkg-dev
Version: 1.22.6
Severity: serious

Dear Maintainer,

Feel free to reassign.

I noticed this bug with the libopenshot-audio source and with
armel, armh and powerpc architectures from buildd logs and my rebuild.

I didn't pay attention for others sources, but I noticed that only
after a second rebuild...

,
| pkg-gencontrol: warning: Provides field of package libopenshot-audio9t64: 
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libopenshot-audio9t64: 
substitution variable ${t64:Provides} used, but is not defined
`

https://buildd.debian.org/status/fetch.php?pkg=libopenshot-audio=powerpc=0.3.2%2Bdfsg1-2.1=1709343482=0

https://buildd.debian.org/status/fetch.php?pkg=libopenshot-audio=armhf=0.3.2%2Bdfsg1-2.1=1709142395=0

Chirstian


-- Package-specific info:

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

Kernel: Linux 6.8.1-1-custom (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 dpkg-dev depends on:
ii  binutils  2.42-4
ii  bzip2 1.0.8-5.1
ii  libdpkg-perl  1.22.6
ii  make  4.3-4.1
ii  patch 2.7.6-7
ii  perl  5.38.2-3.2
ii  tar   1.35+dfsg-3
ii  xz-utils  5.6.0-0.2

Versions of packages dpkg-dev recommends:
ii  build-essential  12.10
ii  clang-16 [c-compiler]1:16.0.6-23
ii  fakeroot 1.34-1
ii  gcc [c-compiler] 4:13.2.0-7
ii  gcc-13 [c-compiler]  13.2.0-19
ii  gnupg2.2.40-3
ii  gpgv 2.2.40-3
pn  libalgorithm-merge-perl  

Versions of packages dpkg-dev suggests:
pn  debian-keyring  

-- no debconf information

Bug#1067134: Try to remove i386 packages

[Christian Marillat]

On 19 mars 2024 13:28, Helmut Grohne  wrote:


[...]

> I agree that the experience is a little messed up, but this is
> resolvable with apt and it only affects unstable users. Do you agree
> with closing this bug with no action?

Yes, if you think that this bug is only related to unstable...

Christian

Bug#1067134: Try to remove i386 packages

[Christian Marillat]

On 19 mars 2024 10:26, Helmut Grohne  wrote:


[...]

> So we need to know which libcom-err2 and libcom-err2t64 packages are
> installed for which architectures on your system. If there is any
> libcom-err2t64, please "upgrade" to libcom-err2. Then retry your
> original apt. I fear this is going to be manual in unstable as there is
> no sane way to make apt understand that we really don't need
> libco-err2t64. I expect that upgrades from bookworm and trixie are
> unaffected by this issue. Unless this expectation is wrong, I suggest
> that we close this bug as wontfix.

We can't upgrade from version 1.47.0-2.3+b1 to 1.47.0-2.4

,
| $ dpkg --print-architecture 
| amd64
`

,
| $ dpkg --print-foreign-architectures 
| i386
`

,
| $ dpkg -l | grep libcom-err
| ii  libcom-err2t64:amd64   1.47.0-2.3+b1  
 amd64common error description library
| ii  libcom-err2t64:i3861.47.0-2.3+b1  
 i386 common error description library
`

upgrading libcom-err2 to 1.47.0-2.4 remove all i386 packages

,
| $ dpkg -l |grep libcom-err2  
| ii  libcom-err2:amd64  1.47.0-2.4 
 amd64common error description library
`

but now I can reinstall i386 packages again :

,
| $ dpkg -l |grep libcom-err2
| ii  libcom-err2:amd64  1.47.0-2.4 
 amd64common error description library
| ii  libcom-err2:i386   1.47.0-2.4 
 i386 common error description library
`

Christian

Bug#1067134: Try to remove i386 packages

[Christian Marillat]

Package: comerr-dev
Version: 2.1-1.47.0-2.4
Severity: serious

Dear Maintainer,

I'm unable to install comerr-dev under a multiarch amd64/i386
machine.

Here is a simple example :

,
| $ sudo apt-get install comerr-dev 
| Reading package lists... Done
| Building dependency tree... Done
| Reading state information... Done
| 
| [...]
| 
| The following additional packages will be installed:
|   libcom-err2
| Suggested packages:
|   doc-base
| The following packages will be REMOVED:
|   inetutils-telnet:i386
| The following NEW packages will be installed:
|   comerr-dev libcom-err2
| 0 upgraded, 2 newly installed, 1 to remove and 0 not upgraded.
`

Christian


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

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

Bug#1067029: www.debian.org: Landing page missing donation information

[Christian Buhtz]

Package: www.debian.org
Severity: normal

Hello,

I realized that the landing page <https://www.debian.org> do miss information
(or link) about how to donate to Debian.

Might be <https://www.debian.org/donations.en.html>

Kind
Christian

Bug#1066916: wiki.debian.org: Remove ""PackagingWithGit/GitDpm/ImportDsc" because it is merged into ""PackagingWithGit/GitDpm"

[Christian Buhtz]

Package: wiki.debian.org
Severity: normal

Dear Maintainer,

I don't see how to remove wiki pages.

Please remove "PackagingWithGit/GitDpm/ImportDsc" because it's content now is
integrated into "PackagingWithGit/GitDpm". There was to less content on that
page to reason it existence.

Kind
Christian Buhtz

Bug#1066902: wiki.debian.org: Loggin page typographical incorrect

[Christian Buhtz]

Package: wiki.debian.org
Severity: normal

Dear Maintainer,

this is about the German version of the logging page.

<https://wiki.debian.org/PackagingWithGit/GitDpm/ImportDsc?action=login>

In German you see this string at the end of the page.

"Wenn Sie kein Konto haben, können Sie nun eins anlegen.Passwort
vergessen?"
^
The problem is that there is a missing blank between this two sentences.

I can confirm that the English version looks ok.

I assume there is a po-file somewhere containing this false string. But I
couldn't find one and I also don't see a translation platform like Weblate to
modify it.

Thanks in advance
Christian Buhtz

Bug#1066899: wiki.debian.org: Missing definition (link) about "git-dpm project"

[Christian Buhtz]

Package: wiki.debian.org
Severity: normal

Dear Maintainer,

This report is about

<https://wiki.debian.org/PackagingWithGit/GitDpm/Initialize>

Its first paragraph tells me about "git-dpm project".

Problem description:
The term is not defined or explained on the whole page. The page also miss a
link to a definition of that term.

Suggested solution:
Use a hyperlink on the string "git-dpm project" to point the correct definition
page in the debian wiki.

Thanks in advance
Christian Buhtz

Bug#1066845: gnome-genius: Is Genius really proprietary?

[Christian Böck]

Package: gnome-genius
Version: 1.0.27-1+b1
Severity: minor
X-Debbugs-Cc: deb...@funtech.org

Dear Maintainer,

According to the "Software"-tool Genius is proprietary software.
But when you visit its homepage it is licensed under the GPL and sources can be
downloaded.

Not realy a bug, but I think it should be fixed anyways.

Sincerely
Chris


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

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

Versions of packages gnome-genius depends on:
ii  genius-common 1.0.27-1
ii  libc6 2.36-9+deb12u4
ii  libcairo2 1.16.0-7
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-2
ii  libgmp10  2:6.2.1+dfsg1-1.1
ii  libgtk-3-03.24.38-2~deb12u1
ii  libgtksourceview-4-0  4.8.4-4
ii  libmpfr6  4.2.0-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libreadline8  8.2-1.3
ii  libvte-2.91-0 0.70.6-2~deb12u1

gnome-genius recommends no packages.

gnome-genius suggests no packages.

-- no debconf information

Bug#1065329: O: numpy -- Fast array facility to the Python 3 language

[Christian Kastner]

Hi Timo,

On 2024-03-14 10:06, Timo Röhling wrote:
>> Having read up on debian-python, I have misread the situation. I think
>> there needs to be a policy resolution first.
> I don't understand what you mean. The orphaning process is not tied to
> DPT policy, is it?
> 
> FWIW, I am a regular user of this package and would also like to help
> maintain it.

I underspecified -- what I meant is resolution of both policy and the
active team dynamics.

In any case, if this isn't resolved soon, I'm also happy to contribute.

Best,
Christian

Bug#1065701: rocm_agent_enumerator: crash on systems without AMD GPU

[Christian Kastner]

Control: found -1 5.2.3-3

Hi Cory,

On 2024-03-09 07:20, Cordell Bloor wrote:
> On systems, the rocm_agent_enumerator command may crash with an error:
> 
> Traceback (most recent call last):
>   File "/usr/bin/rocm_agent_enumerator", line 260, in 
> main()
>   File "/usr/bin/rocm_agent_enumerator", line 244, in main
> target_list = readFromKFD()
>   ^
>   File "/usr/bin/rocm_agent_enumerator", line 193, in readFromKFD
> for node in sorted(os.listdir(topology_dir)):
>
> FileNotFoundError: [Errno 2] No such file or directory: 
> '/sys/class/kfd/kfd/topology/nodes/'

I've been seeing this one for a long time in package builds, but it
didn't occur to me that this is a user-visible issue, too.

Seen here [1], for example.

Best,
Christian

[1] 
https://buildd.debian.org/status/fetch.php?pkg=rocblas=amd64=5.3.3%2Bdfsg-2=1685955323=0

Bug#1063673: ITP: llama.cpp -- Inference of Meta's LLaMA model (and others) in pure C/C++

[Christian Kastner]

Hey Ptter,

On 2024-03-08 20:21, Petter Reinholdtsen wrote:
> [Christian Kastner 2024-02-13]
>> I'll push a first draft soon, though it will definitely not be
>> upload-ready for the above reasons.
> 
> Where can I find the first draft?

I've discarded the simple package and now plan another approach: a
package that ships a helper to rebuild the utility when needed, similar
to DKMS. Rationale:
  * Continuously developed upstream, no build suited for stable
  * Build optimized for the current host's hardware, which is a key
feature. Building for our amd64 ISA standard would be absurd.
I'm open for better ideas, though.

I had to pause this primarily because of ROCm infrastructure work and
our updates to 5.7 in preparation of the gfx1100,gfx1101,gfx1102
architectures, and that is still my focus.

Incidentally, we could use some help with that, see thread at [1].
MIOpen in particular is something that our ROCm stack will eventually need.

Best,
Christian

[1] https://lists.debian.org/debian-ai/2024/03/msg00029.html
[2] https://github.com/ROCm/MIOpen

Bug#1065487: new packaging repo based on tarballs

[Christian Kreidl]

Package: urjtag
Severity: wishlist

Dear Maintainer,

Since urjtag debian packages are really old I've invested some work in debian 
packaging.

I tried to get the already started packaging in
https://salsa.debian.org/electronics-team/urjtag
to work, but it failed since upstream git has the sources in a subdirectory
and the released tarballs differ from the git tag.

So I decided to base a new git packaging repo on tarballs only:
https://salsa.debian.org/ckreidl/urjtag
Keeping up with new versions should be straight forward.

Please feel free to copy the repo to electronics-team.

Thanks!
Christian

Bug#1065423: vlc-plugin-pipewire uninstallable in unstable after vlc time_t transition

[Christian Klein]

Package: vlc-plugin-pipewire
Version: 3-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: dvl...@gmail.com

vlc-plugin-pipewire depends on vlc-plugin-abi-3-0-0f. However, after the time_t
transition, the libvlccore9 package provides vlc-plugin-abi-3-0-0ft64.
Due to this, the package can no longer be installed.

A simple rebuild of the package will likely already fix the problem.
I wonder why this didn't happen automatically during the transition without any
manual intervention. Maybe the fact that the package depends on libvlccore9
twice - once directly and once via vlc-plugin-abi-3-0-0f - causes this.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (999, 'unstable'), (998, 'testing'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'proposed-updates'), (350, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages vlc-plugin-pipewire depends on:
ii  libc6 2.38-6
ii  libpipewire-0.3-0t64 [libpipewire-0.3-0]  1.0.3-1.1
ii  libvlccore9 [vlc-plugin-abi-3-0-0f]   3.0.20-1+b2

vlc-plugin-pipewire recommends no packages.

vlc-plugin-pipewire suggests no packages.

-- no debconf information

Bug#1065329: O: numpy -- Fast array facility to the Python 3 language

[Christian Kastner]

Control: retitle -1 O: numpy -- Fast array facility to the Python 3 language
Control: tags -1 - pending

Having read up on debian-python, I have misread the situation. I think
there needs to be a policy resolution first.

On 2024-03-02 22:18, Christian Kastner wrote:
> Control: retitle -1 ITA: numpy -- Fast array facility to the Python 3 language
> Control: tags -1 pending

Bug#1065329: O: numpy -- Fast array facility to the Python 3 language

[Christian Kastner]

Control: retitle -1 ITA: numpy -- Fast array facility to the Python 3 language
Control: tags -1 pending

I intend to put this under the Debian Python Team.

On 2024-03-02 21:46, Sandro Tosi wrote:
> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: nu...@packages.debian.org, mo...@debian.org
> Control: affects -1 + src:numpy
> 
> I intend to orphan the numpy package.
> 
> The package description is:
>  Numpy contains a powerful N-dimensional array object, sophisticated
>  (broadcasting) functions, tools for integrating C/C++ and Fortran
>  code, and useful linear algebra, Fourier transform, and random number
>  capabilities.
>  .
>  Numpy replaces the python-numeric and python-numarray modules which are
>  now deprecated and shouldn't be used except to support older
>  software.
>  .
>  This package contains Numpy for Python 3.
> 

Bug#1065316: libatspi2.0-dev 2.51.90-1 no longer multi-arch installable due to dependencies

[Christian Klein]

Package: libatspi2.0-dev
Version: 2.51.90-1
Severity: important
X-Debbugs-Cc: dvl...@gmail.com

libatspi2.0-dev is no longer muti-arch installable.
It now has a dependency on libgirepository1.0-dev, which isn't multi-arch.
2.50.0-1 didn't have that dependency

This breaks libgtk-3-dev multiarch install, since libgtk-3-dev depends on
libatspi2.0-dev via libatk-bridge2.0-dev.

Looking at the changelog, I don't see why the additional dependency is
necessary.
Even worse, for i386, this now pulls in ~250MB additional packages, because
libgirepository1.0-dev needs gobject-introspection:i386, which pulls in
gcc-i686-linux-gnu.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (999, 'unstable'), (998, 'testing'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'proposed-updates'), (350, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libatspi2.0-dev depends on:
ii  gir1.2-atspi-2.0  2.50.0-1+b1
pn  libatspi2.0-0 
ii  libdbus-1-dev 1.14.10-4
ii  libglib2.0-dev2.78.4-2.1
ii  libxtst-dev   2:1.2.3-1.1

libatspi2.0-dev recommends no packages.

libatspi2.0-dev suggests no packages.

-- no debconf information

Bug#1055830: systemd in a container fails to set up mount namespacing

[Christian Horn]

Hello,

thank you for commenting.

On Wed, Feb 28, 2024 at 07:02:10PM +0100, Michael Biebl wrote:
> 
> On Sun, 12 Nov 2023 11:15:45 +0100 Christian Horn 
> wrote:
> > Package: systemd
> > Version: 252.17-1~deb12u1
> > Severity: important
> > [..]
> 
> From the provided information it is not obvious that this is actually a
> systemd issue. It could be the kernel or any of the dependencies systemd
> relies on or even redis itself.
> 
> In any case, if you think this is a systemd issue, we would need further
> information how to fix this.

The issue still exists with the latest bookworm packages in the container.
Updating then 'redis' in the container to the trixie version does not 
change the issue, update of package systemd pulls in these packages:
  libsystemd-shared libsystemd0 libudev1 
  libzstd1 systemd systemd-timesyncd
..and afterwards redis can be started.

Just in case it helps someone else, reproducer details:
```
# On a Fedora 39 host with podman installed, as user:
mkdir build-bookworm/
cat >build-bookworm/Containerfile< Job for redis-server.service failed because the [..]
> See "systemctl status redis-server.service" and [..]
```

There were no further comments from others on this bug, I guess
it's not widely hit.  I work around it now and do not plan to look
deeper, in Trixie it also does not exist.

Thank you,
Christian

Bug#1064629: libamd-comgr2: segfault in rocfft

[Christian Kastner]

Hey Cory,

On 2024-02-28 21:16, Cordell Bloor wrote:
> This segfault does seem to be caused by mixing clang-15 and clang-17 in
> the HIP RTC codepath. When libamdhip64 from ROCm 5.6.1 (built with the
> same clang-17 as rocm-compilersupport 6.0+git20231212.4510c28+dfsg-1) is
> used, the segfault disappeared [1].

I think that this also needs to be fixed in bin:hipcc. It currently has
an unversioned Depends on libamdhip64-dev, making it possible to use
clang-17 hipcc with clang-15 libamdhip64-5.

# should also work with s/podman/docker/, of course
$ podman run --rm -it debian:experimental sh -c 'apt update && apt install -s 
hipcc/experimental | grep "Inst.*libamdhip64"'
[...]
Inst libamdhip64-5 (5.2.3-13 Debian:unstable [amd64])
Inst libamdhip64-dev (5.2.3-13 Debian:unstable [amd64])

I'd file a bug and fix the dependency in rocm-hipamd myself, but I'm
only 90% confident that I'm not missing something, so wanted to check
first.

If it's indeed missing from bin:hipcc, I guess it should be updated to
libamdhip64-dev (= ${binary:Version})

Discovered when building the newer rocFFT, which only build-depends on
hipcc.

Best,
Christian

> [1]: https://ci.rocm.debian.net/packages/r/rocfft/unstable/amd64+gfx1030/7998/

Bug#1061208: Please upgrade to llvm-toolchain-17

[Christian Kastner]

Hi Étienne,

On 2024-02-26 19:29, Étienne Mollier wrote:
> If that helps, the autoremoval timer is reset each time the RC
> critical bug triggering the autoremoval is updated, e.g. when
> reporting an evolution of the situation in a new comment.
thanks for the info! That's incredible useful to know.

Funny how I never realized that this was a thing.

Best,
Christian

Bug#969491: gnome-shell: User Switcher not working in Gnome-Shell with lightdm

[Christian Weiske]

I can confirm this bug still exists with

gnome-shell 43.9-0+deb12u1
on Debian GNU/Linux 12 (bookworm)

--
Regards/Mit freundlichen Grüßen
Christian Weiske

Bug#1033352: sbuild doesn't support autotpkgest-virt-incus: Error: mkdir /sbuild-nonexistent: permission denied

[Christian Kastner]

Hi all,

adding #1033352 as below contains information for that bug, too.

On 2024-02-25 19:50, Johannes Schauer Marin Rodrigues wrote:
> in that issue you asked exactly the question I was about to ask you. :)
> 
> Though it seems incus should now be able to deal gracefully with the situation
> and there is nothing else that sbuild needs to do to handle this, correct?
> 
> Note, that the autopkgtest/podman backend has a similar issue, see #1033352 
> for
> details. To fix this, Christian submitted this MR against sbuild:
> 
> https://salsa.debian.org/debian/sbuild/-/merge_requests/55
> 
> Reading how incus worked around this problem, maybe podman can do the same?

I believe there is one difference: unless Im mistaken, incus has a
centralized location for containers, whereas podman rootless container
images are stored in $HOME.

Also, the podman configuration lives $HOME.

> On Tue, 23 Jan 2024 14:30:07 + stefa...@debian.org wrote:
>> Filed an incus upstream bug about handling this situation more 
>> gracefully: https://github.com/lxc/incus/issues/422

That issue does mention a practical solution: grabbing $HOME from
/etc/passwd. But it mentions that incus only does that when $HOME is not
in env, so HOME=/sbuild-nonexistent would impede that.

Technically, by providing the right envvars, setting ENVIRONMENT_FILTER,
and other tricks, it should be possible to trick
sbuild+autopkgtest+podman to ignore $HOME. But unfortunately, podman
does not allow this -- similar to the incus issue above.

Another trick I thought of was to hack autopkgtest-virt-podman: when
run, if HOME=/sbuild-nonexistent, ignore it and use the value
/etc/passwd. This might be less invasive than my MR to sbuild. It still
has a failure mode (if HOME is deliberately set to something else) but
that's a fairly unusual use case.

Best,
Christian

Bug#1064809: libhipsparse0-tests: csr2bsr test failures

[Christian Kastner]

On 2024-02-26 07:23, Cordell Bloor wrote:
> The update of rocsparse 5.5.1 to 5.7.1 seems to have caused a regression
> in hipsparse. Although, it's also possible that this problem was because
> rocsparse was therefore rebuilt with the updated rocprim 5.7.1.

This one looks a bit tricky as it also seems to be GPU-arch dependent.

The following is all going by the logs of gfx1034 [1]:

One issue is that the test suite is often aborted early, so the csr2bsr
tests (from this bug) don't even get run. From the tail of the latest
log in experimental [2]:

>  82s [ RUN  ] dense2csr/parameterized_dense2csr.dense2csr_float/158
>  82s [   OK ] dense2csr/parameterized_dense2csr.dense2csr_float/158 (0 ms)
>  82s [ RUN  ] dense2csr/parameterized_dense2csr.dense2csr_float/159
>  82s [   OK ] dense2csr/parameterized_dense2csr.dense2csr_float/159 (0 ms)
>  82s [ RUN  ] dense2csr/parameterized_dense2csr.dense2csr_float/160
>  82s hipSPARSE error: HIPSPARSE_STATUS_INTERNAL_ERROR
>  82s hipSPARSE error: HIPSPARSE_STATUS_INTERNAL_ERROR
>  82s double free or corruption (out)
>  82s Aborted
>  82s autopkgtest [00:40:28]: test command1: ---]
>  83s command1 FAIL non-zero exit status 1
>  83s autopkgtest [00:40:29]: test command1:  - - - - - - - - - - results - - 
> - - - - - - - -
>  84s autopkgtest [00:40:30]:  summary
>  84s command1 FAIL non-zero exit status 1

The last fully completed run (no abort) was on 2024-01-27 [3], with a
runtime of 3m38s. And then the rocsparse-5.7.1 upgrade happens, and
indeed, after that update, no other successful completion can be seen,
suggesting that this might be a factor.

But, within the preceding 24hrs, we had two other test runs [4,5] abort
early -- with rocsparse=5.5.1-2.

Some of the earlier logs have more informative error messages prior to
the abort, eg:

>  85s Memory access fault by GPU node-1 (Agent handle: 0x5608f9e506c0) on 
> address 0x7fa318408000. Reason: Page not present or supervisor privilege.
>  85s Nearby memory map:
> [...]
> 85s hipsparse-test: ./src/core/runtime/runtime.cpp:1276: static bool 
> rocr::core::Runtime::VMFaultHandler(hsa_signal_value_t, void*): Assertion 
> `false && "GPU memory access fault."' failed.
>  85s ./clients/common/unit.cpp:128: Failure

I think these tests were all in VMs, I'll try to reproduce them on bare
metal just to be sure.

And to make things even more interesting, the test history of gfx1030
[6] suggests that rocsparse indeed was a factor. Tests on gfx1030 passed
until rocsparse=5.7.1-2, then failed, and now pass again with
hipsparse=5.7.1-1~exp1.

Best,
Christian

[1]: https://ci.rocm.debian.net/packages/h/hipsparse/unstable/amd64+gfx1034/
[2]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1034/h/hipsparse/7767/log.gz
[3]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1034/h/hipsparse/5234/log.gz
[4]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1034/h/hipsparse/5075/log.gz
[5]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1034/h/hipsparse/5003/log.gz

Bug#1064811: libhipsparse0-tests: HIPSPARSE_STATUS_INTERNAL_ERROR

[Christian Kastner]

Package: libhipsparse0-tests
Version: 5.7.1-1~exp1
Severity: normal

On gfx1031/gfx1032/gfx1034, there are numerous occurrences of
HIPSPARSE_STATUS_INTERNAL_ERROR, see [1] for a full log. Interestingly,
only some of them lead to test failures (some examples below), and
sometimes there is more than one occurrence per test.

These passed on gfx900/gfx1030 so I don't immediately suspect my update
to the optional-test-matrices resp. allow-missing-matrix-data-in-tests
patches to be the cause.

>  63s hipSPARSE error: HIPSPARSE_STATUS_INTERNAL_ERROR
>  63s ./clients/tests/test_dense_to_sparse_csr.cpp:38: Failure
>  63s Expected equality of these values:
>  63s   status
>  63s Which is: 7
>  63s   HIPSPARSE_STATUS_SUCCESS
>  63s Which is: 0
>  63s 
>  63s [  FAILED  ] dense_to_sparse_csr.dense_to_sparse_csr_i32_i32_float (7 ms)

> 63s [ RUN  ] dense_to_sparse_csc.dense_to_sparse_csc_i64_i32_double
>  63s hipSPARSE error: HIPSPARSE_STATUS_INTERNAL_ERROR
>  63s hipSPARSE error: HIPSPARSE_STATUS_INTERNAL_ERROR
>  63s [   OK ] dense_to_sparse_csc.dense_to_sparse_csc_i64_i32_double (3 
> ms)

> 66s [ RUN  ] bsrmv/parameterized_bsrmv.bsrmv_float/260
>  66s hipSPARSE error: HIPSPARSE_STATUS_INTERNAL_ERROR
>  66s hipSPARSE error: HIPSPARSE_STATUS_INTERNAL_ERROR
>  66s hipSPARSE error: HIPSPARSE_STATUS_INTERNAL_ERROR
>  66s hipSPARSE error: HIPSPARSE_STATUS_INTERNAL_ERROR
>  66s ./clients/tests/test_bsrmv.cpp:114: Failure
>  66s Expected equality of these values:
>  66s   status
>  66s Which is: 7
>  66s   HIPSPARSE_STATUS_SUCCESS
>  66s Which is: 0
>  66s 
>  66s [  FAILED  ] bsrmv/parameterized_bsrmv.bsrmv_float/260, where GetParam() 
> = (500, 842, 3, 1, 9, 0, 0) (1 ms)

[1]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1031/h/hipsparse/7762/log.gz

Bug#1064809: libhipsparse0-tests: csr2bsr test failures

[Christian Kastner]

On 2024-02-26 07:23, Cordell Bloor wrote:
> The update of rocsparse 5.5.1 to 5.7.1 seems to have caused a regression
> in hipsparse. Although, it's also possible that this problem was because
> rocsparse was therefore rebuilt with the updated rocprim 5.7.1.

Interestingly, this passed on gfx900 [1].

(I checked a small sample of tests to check that they weren't just
being skipped)

[1]: https://ci.rocm.debian.net/packages/h/hipsparse/unstable/amd64+gfx900/

Bug#1061208: Please upgrade to llvm-toolchain-17

[Christian Kastner]

Hi Sebastian,

writing to you as you bumped the severity to 'serious': could the rT
please give us an extension on the autoremoval for this particular bug.

The transition from first-filing-to-serious was unusually short notice,
and caught us in the middle of our own update of the stack.

This affects a key package of our stack, so it's not just about testing
this particular package, but the entire stack, and everything else in
the archive that depends on it.

A fix is in progress.

Best,
Christian

On 2024-01-20 21:59, Sylvestre Ledru wrote:
> Source: rocm-hipamd
> Severity: important
> 
> Dear Maintainer,
> 
> As part of the effort to limit the number of llvm packages in the
> archive, it would be great if you could upgrade to -17.
> 
> This package depends on 15.

Bug#1064637: lintian: Detect ~exp revision and warn if suite not experimental

[Christian Kastner]

Package: lintian
Version: 2.117.0
Severity: wishlist

It would be nice if lintian could warn about packages with ~exp in their
Debian revisions where suite is not experimental.

So these would warn:

  libfoo (1.0-1~exp) unstable; urgency=medium
  libfoo (1.0-1~exp1) unstable; urgency=medium
  ^^

But these wouldn't:

  libfoo (1.0-1) unstable; urgency=medium
  libfoo (1.0-1) experimental; urgency=medium

(More generally, anything without ~exp would be ignored.)

Best,
Christian

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

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages lintian depends on:
ii  binutils2.42-2
ii  bzip2   1.0.8-5+b2
ii  diffstat1.65-1
ii  dpkg1.22.4
ii  dpkg-dev1.22.4
ii  file1:5.45-2+b1
ii  gettext 0.21-14+b1
ii  gpg 2.2.40-1.1+b1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.16.0-1
ii  libapt-pkg-perl 0.1.40+b3
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b2
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b2
ii  libclone-perl   0.46-1+b1
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1+b1
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.4
ii  libemail-address-xs-perl1.05-1+b2
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.049-1
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b2
ii  libperlio-utf8-strict-perl  0.010-1+b1
ii  libproc-processtable-perl   0.636-1+b1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1+b1
ii  libsereal-encoder-perl  5.004+ds-1+b1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1+b1
ii  libterm-readkey-perl2.38-2+b2
ii  libtext-levenshteinxs-perl  0.03-5+b2
ii  libtext-markdown-discount-perl  0.16-1+b1
ii  libtext-xslate-perl 3.5.9-1+b3
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b2
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2+b1
ii  liburi-perl 5.27-1
ii  libwww-mechanize-perl   2.18-1
ii  libwww-perl 6.76-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b2
ii  libyaml-libyaml-perl0.89+ds-1
ii  lzop1.04-2
ii  man-db  2.12.0-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.38.2-3
ii  plzip [lzip-decompressor]   1.11-1
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.5-0.3

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1064421: refpolicy: show CIL warnings within semodule command

[Christian Göttsche]

Package: selinux-policy-default
Version: 2:2.20240202-1
Tags: patch

The invocation of semodule in the postinst maintanier script might
fail, e.g. due to conflicts with local modifications.
Since by default the CIL log level is error and those error messages
are rather generic the actual cause is most of the time not shown.
A solution is to run semodule in verbose mode, which increases the
verbosity of CIL from error to warning, see
https://github.com/SELinuxProject/selinux/blob/82195e77e317d322dd9b5fc31d402462d6845357/policycoreutils/semodule/semodule.c#L419:

--- debian/postinst.policy.bak  2024-02-21 21:56:04.383102610 +0100
+++ debian/postinst.policy  2024-02-21 21:56:09.307157364 +0100
@@ -117,7 +117,7 @@
   fi

   ret=0
-   semodule -X $priority $noreload -s $flavour $to_remove
$to_install $to_disable || ret=$?
+   semodule -v -X $priority $noreload -s $flavour $to_remove
$to_install $to_disable || ret=$?
   if [ $ret -eq 0 ]; then
   echo " done."
   else

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

[Christian Kastner]

Hi josch,

On 2024-02-21 08:02, Johannes Schauer Marin Rodrigues wrote:
> Quoting Christian Kastner (2023-03-23 09:53:05)
>> Attempting to build a package with the autopkgtest-virt-podman backend fails
>> because of what I suspect is an issue with $HOME directory handling. podman
>> needs $HOME on the host to find containers, but it defaults to
>> /sbuild-nonexistent, which I guess is meant for the target enviromnent.
> 
> is this a duplicate of #1061388?

I *think* so, but I'm not sure.

The cause definitely seems to be the same: on the host, prior to opening
the chroot, $HOME is set to /sbuild-nonexistent, which triggers these
two bugs.

I'm not sure because I don't know if the $HOME thing above is buggy ,or
it's correct (though strict) and autopkgtest-build-podman, incus, or
something else needs fixing.

For example, in #1061388, a possible fix in incus is mentioned.

>From my current understanding, this wouldn't work for podman, because
its attempted use of $HOME/.config/local/*.conf is not just legitimate,
I'd actually call it required.

Best,
Christian

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

[Christian Kastner]

Hi Carles,

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

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

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

Best,
Christian

Bug#1064070: RFP: cxxheaderparser -- python library for parsing C++ headers

[Christian Kastner]

Control: tag -1 pending

I've uploaded this to experimental, though with the Debian Python Team
as maintainer. Because although it is a dependency of the ROCm stack, it
seems to be a generally useful Python library.

Best,
Christian

On 2024-02-16 18:57, Cordell Bloor wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org
> 
> * Package name: cxxheaderparser
>   Version : 1.3.1
>   Upstream Contact: RobotPy Development Team 
> * URL : https://github.com/robotpy/cxxheaderparser
> * License : BSD-3-Clause
>   Programming Lang: Python
>   Description : Python library for parsing C++ headers
> 
> The cxxheaderparser library is used to parse syntactically valid C++
> code and operate on the results. It provides both a visitor-style
> interface to process the results as they are being parsed or the option
> of a single data structure containing all parsed information.
> 
> This library is a successor to CppHeaderParser, which is a build
> dependency of the AMD ROCm GPU profiling libraries used by PyTorch.
> Specifically, CppHeaderParser is required for roctracer and parts of
> rocm-hipamd. As CppHeaderParser has been deprecated by its authors,
> those libraries will need to be migrated to cxxheaderparser.
> 

Bug#1024830: ERROR: Unable to connect to servers to test latency.

[Christian Marillat]

On 14 févr. 2024 16:13, Paul Wise  wrote:

> On Wed, 14 Feb 2024 08:11:41 +0100 Christian Marillat wrote:
>
>> speedtest-cli is also unable to list remote server
>
> Please try to download the lists with curl/wget/browser:
>
> curl http{,s}://{www,c}.speedtest.net/speedtest-servers{,-static}.php

See https://github.com/sivel/speedtest-cli/pull/796

Christian

Bug#1024830: ERROR: Unable to connect to servers to test latency.

[Christian Marillat]

On 14 févr. 2024 16:13, Paul Wise  wrote:

> On Wed, 14 Feb 2024 08:11:41 +0100 Christian Marillat wrote:
>
>> speedtest-cli is also unable to list remote server
>
> Please try to download the lists with curl/wget/browser:
>
> curl http{,s}://{www,c}.speedtest.net/speedtest-servers{,-static}.php

That explain why speedtest-cli doesn't work

,
| 429 Error - Too Many Requests
| 
| Your IP address is making too many requests. We ask that you limit requests 
to no more than 1 per second.
| 
| We make an attempt to be flexible, allowing small bursts in traffic. You have 
exceeded this threshold however and have been blocked.
| 
| Please reduce the speed at which your requests are made and try again after a 
while. If you feel you have reached this message in error, please contact us at 
noc @ speedtest.net and reference this error code.
| 
| Thank you
`

Christian

Bug#1024830: ERROR: Unable to connect to servers to test latency.

[Christian Marillat]

On 14 févr. 2024 14:44, Paul Wise  wrote:

> On Fri, 26 Jan 2024 11:46:15 +0100 Yves-Alexis Perez wrote:
>> On Sat, 26 Nov 2022 08:35:40 +0100 cuboid_06_wavers wrote:
>> >   running speedtest
>> > 
>> >    * What was the outcome of this action?
>> > 
>> >   ERROR: Unable to connect to servers to test latency.
>> 
>> Same thing happens here. As far as I can tell that makes the package pretty
>> unusable so I guess the severity could be raised.
>
> I'm not able to reproduce this, speedtest-cli works fine for me,
> so lets let it back into testing until it is confirmed really broken.
>
> Could you all paste the output of your speedtests? Mine are below.
>
> Also probably a good idea to try the --secure or --single options.

Still doesn't work for me even with --secure or --single options
also tested on 3 machines

speedtest-cli is also unable to list remote server

,
| $ speedtest-cli --list
| Retrieving speedtest.net configuration...
`

Christian

Bug#1063673: ITP: llama.cpp -- Inference of Meta's LLaMA model (and others) in pure C/C++

[Christian Kastner]

Hi Petter,

On 2024-02-13 08:36, Petter Reinholdtsen wrote:
> I tried building the CPU edition on one machine and run it on another,
> and experienced illegal instruction exceptions.  I suspect this mean one
> need to be careful when selecting build profile to ensure it work on all
> supported Debian platforms.

yeah, that was my conclusion from my first experiments as well.

This is a problem though, since one key point of llama.cpp is to make
best use of the current hardware. If we'd target some 15-year-old amd64
lowest common denominator, we'd go against that.

In my first experiments, I've also had problems with ROCm builds on
hosts without a GPU.

I have yet to investigate if/how capabilities can be generally enabled,
and use determined at runtime.

Another issue that stable is clearly the wrong distribution for this.
This is a project that is continuously gaining new features, so we'd
need to stable-updates.

> I would be happy to help getting this up and running.  Please let me
> know when you have published a git repo with the packaging rules.

I'll push a first draft soon, though it will definitely not be
upload-ready for the above reasons.

Best,
Christian

Bug#1063715: monitoring-plugins-common: check_flexlm (monitoring-plugins-standard) fails because utils.pm has empty PATH_TO_LMSTAT

[Christian Ospelkaus]

Package: monitoring-plugins-common
Version: 2.3.3-5+deb12u2
Severity: normal
Tags: patch

Dear Maintainer,

The command check_flexlm from montoring-plugins-standard is useless
because it relies on the setting PATH_TO_LMSTAT from
monitoring-plugins-common, which is unfortunately empty. AFAIK, no Debian 
package provides lmstat. So I suggest setting PATH_TO_LMSTAT to 
/usr/local/bin/lmstat so that somebody who wants to use the plugin can 
provide a symbolic link under /usr/local/bin/lmstat or place the exectutable 
right there. Even if there were a debian package that provided lmstat, the 
mechanism would still allow to make things work... Thanks for considering my 
suggesion. Here is my patch:

--- /usr/lib/nagios/plugins/utils.pm2024-02-11 17:57:02.238612539 +0100
+++ /usr/lib/nagios/plugins/utils.pm.orig   2024-02-11 17:58:59.337727843 
+0100
@@ -19,7 +19,7 @@
 ## updated by autoconf
 $PATH_TO_SUDO= "/usr/bin/sudo";
 $PATH_TO_RPCINFO = "/usr/sbin/rpcinfo" ;
-$PATH_TO_LMSTAT  = "/usr/local/bin/lmstat" ;
+$PATH_TO_LMSTAT  = "" ;
 $PATH_TO_SMBCLIENT = "/usr/bin/smbclient" ;
 $PATH_TO_MAILQ   = "/usr/bin/mailq";
 $PATH_TO_QMAIL_QSTAT = "";

Best wishes,

Christian

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

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

Versions of packages monitoring-plugins-common depends on:
ii  libc6  2.36-9+deb12u4
ii  ucf3.0043+nmu1

monitoring-plugins-common recommends no packages.

Versions of packages monitoring-plugins-common suggests:
ii  icinga2  2.13.6-2

-- no debconf information

Bug#1063673: ITP: llama.cpp -- Inference of Meta's LLaMA model (and others) in pure C/C++

[Christian Kastner]

Package: wnpp
Severity: wishlist
Owner: Christian Kastner 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: llama.cpp
  Version : b2116
  Upstream Author : Georgi Gerganov
* URL : https://github.com/ggerganov/llama.cpp
* License : MIT
  Programming Lang: C++
  Description : Inference of Meta's LLaMA model (and others) in pure C/C++

The main goal of llama.cpp is to enable LLM inference with minimal
setup and state-of-the-art performance on a wide variety of hardware -
locally and in the cloud.

* Plain C/C++ implementation without any dependencies
* Apple silicon is a first-class citizen - optimized via ARM NEON,
  Accelerate and Metal frameworks
* AVX, AVX2 and AVX512 support for x86 architectures
* 2-bit, 3-bit, 4-bit, 5-bit, 6-bit, and 8-bit integer quantization for
  faster inference and reduced memory use
* Custom CUDA kernels for running LLMs on NVIDIA GPUs (support for AMD
  GPUs via HIP)
* Vulkan, SYCL, and (partial) OpenCL backend support
* CPU+GPU hybrid inference to partially accelerate models larger than
  the total VRAM capacity

This package will be maintained by the Debian Deep Learning Team.

Bug#1054606: libcap2-bin: Move /sbin/getcap to /bin

[Christian Kastner]

Hi Peter,

On 2023-10-26 19:29, Peter Samuelson wrote:
> Package: libcap2-bin
> Version: 1:2.66-4
> Severity: wishlist
> 
> In my opinion, getcap(8) is useful to run as a non-root user, so it
> should be in /bin rather than /sbin.  This seems analogous to ip(8)
> from iproute2, which was moved to /bin many years ago.

this makes sense in general, but is a bit tricky.

It can't just be moved, as this would break scripts that hard-code
/usr/sbin/getcap.

A symlink wouldn't do much good.

I think what's needed is a move to /bin and a wrapper in /sbin calling
the version in /bin, but emitting a decprecation notice.

However, in the end, this would need to be coordinated by upstream, and
we'd want consistency over all distros. I'll make a ping.

Best,
Christian

Bug#1059972: LGTM, added to git

[Christian Ehrhardt]

Control: tags 1059972 + patch pending

Hi,
thank you for your prep work.
I've opened [1] to add it to the git branch.

The intention is to upload it to experimental once 23.11.1 is around,
check if all loong64 builds are correct and then push to unstable.

[1]: https://salsa.debian.org/debian/dpdk/-/merge_requests/78

-- 
Christian Ehrhardt
Director of Engineering, Ubuntu Server
Canonical Ltd

Bug#1063349: libamd-comgr2 exports wrong symbol version

[Christian Kastner]

On 2024-02-06 14:28, Christian Kastner wrote:
> As discussed in this thread [1], libamd-comgr2 exports
> amd_comgr_get_isa_count@1.8 when upstream is at @2.0.
> 
> This is because the symbol was erroneously not removed from @1.8 when it
> was added to @2.0 when the ABI changed.

Following [1] (bottom example), I updated the patch restoring the old
symbol with the suggested trickery, and together with the restored
export map, this seems to have worked.

unstable:
  $nm -gD /usr/lib/x86_64-linux-gnu/libamd_comgr.so.2.4.0 | grep isa_count
  005cbd10 T amd_comgr_get_isa_count@@amd_comgr_1.8

experimental+updated patch:
  $ nm -gD /usr/lib/x86_64-linux-gnu/libamd_comgr.so.2.6.0 | grep isa_count
  00491d70 T amd_comgr_get_isa_count@@amd_comgr_2.0
  00491d70 T amd_comgr_get_isa_count@amd_comgr_1.8

To test this, I compiled a minimal test program using the old version.
Then I updated the library, and compiled a new test program. The old
program continued to work fine with @1.8, and the new one used @2.0.

I'm not sure how portable this is, but this is localized to us anyway.

Best,
Christian

[1] https://gcc.gnu.org/wiki/SymbolVersioning

Bug#1063397: virtualenvwrapper: Installation incomplete

[Christian Buhtz]

Package: virtualenvwrapper
Version: 4.8.4-4
Severity: normal

Dear Maintainer,

I am aware that upstream do tell its users to do "source
/virtuelenvwrapper.sh".

This is an unnecessary step. When using Debian package I would expect that
"apt" will do this for me. The package do not work after "apt install". I still
have to make this manual step. This is IMHO a bug on usability.

Kind
Christian Buhtz


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-17-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 virtualenvwrapper depends on:
ii  python3-virtualenvwrapper  4.8.4-4
ii  virtualenv 20.17.1+ds-1

Versions of packages virtualenvwrapper recommends:
ii  bash-completion  1:2.11-6

Versions of packages virtualenvwrapper suggests:
pn  virtualenvwrapper-doc  

-- no debconf information

Bug#1063349: libamd-comgr2 exports wrong symbol version

[Christian Kastner]

Package: libamd-comgr2
Version: 5.2.3-2
Severity: important

As discussed in this thread [1], libamd-comgr2 exports
amd_comgr_get_isa_count@1.8 when upstream is at @2.0.

This is because the symbol was erroneously not removed from @1.8 when it
was added to @2.0 when the ABI changed.

The discrepancy between upstream and our version needs to be resolved.

[1] https://lists.debian.org/debian-ai/2024/01/msg00087.html