Bug#1061616: pixman: FTBFS on armhf: Error: garbage following instruction -- `bne 01f'

[Diederik de Haas]

Control: tag -1 -patch -upstream -fixed-upstream
Control: notforwarded -1

On 26 Aug 2024 17:22:19 +0200 Diederik de Haas  wrote:
> Control: tag -1 upstream fixed-upstream patch
> Control: forwarded -1 https://gitlab.freedesktop.org/pixman/pixman/-/issues/96

Oeps, my CC-ing this bug also modified the metadata ... incorrectly.
Should now be fixed again.

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

Bug#1061616: pixman: FTBFS on armhf: Error: garbage following instruction -- `bne 01f'

[Diederik de Haas]

Control: tag -1 upstream fixed-upstream patch
Control: forwarded -1 https://gitlab.freedesktop.org/pixman/pixman/-/issues/96

On 12 Jul 2024 13:38:30 +0900 Mike Hommey  wrote:
> Source: pixman
> Version: 0.42.2-1
> Severity: serious
> 
> The package fails to build on armhf on current sid/testing with:
> 
> ../../pixman/pixman-arm-simd-asm.h:821: Error: garbage following instruction 
> -- `bne 01f'
> ../../pixman/pixman-arm-simd-asm.h:869:  Info: macro invoked from here
>  ...
> See https://gitlab.freedesktop.org/pixman/pixman/-/issues/96 and bug
> 1073870.

https://gitlab.freedesktop.org/pixman/pixman/-/commit/865e6ce00bb79a6b925ed4c2c436e1533e4472aa
is the commit where upstream fixed this bug and for your convenience attached.

BUT this patch won't apply on top of 0.42.2, but it would apply on top
version 0.43.4 which bug 1061616 requests for.
So it would be great if both bugs can be fixed in 1 go.

Cheers,
  Diederik>From 865e6ce00bb79a6b925ed4c2c436e1533e4472aa Mon Sep 17 00:00:00 2001
From: Mike Hommey 
Date: Fri, 12 Jul 2024 11:11:17 -0400
Subject: [PATCH] pixman: Adjust arm assembly for binutils change

A change in the latest version of binutils broke building pixman for arm.

The binutils change:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=226749d5a6ff0d5c607d6428d6c81e1e7e7a994b

Closes: https://gitlab.freedesktop.org/pixman/pixman/-/issues/96
---
 pixman/pixman-arm-simd-asm.S | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/pixman/pixman-arm-simd-asm.S b/pixman/pixman-arm-simd-asm.S
index 34d38f1f..3dfe723a 100644
--- a/pixman/pixman-arm-simd-asm.S
+++ b/pixman/pixman-arm-simd-asm.S
@@ -820,13 +820,13 @@ generate_composite_function \
 .macro over_white___ca_1pixel_tail
 mvn TMP0, WK1
 teq WK1, WK1, asr #32
-bne 01f
-bcc 03f
+bne 1f
+bcc 3f
 mov WK3, WK1
-b   02f
-01: over_white___ca_combine WK1, WK3
-02: pixst   , 4, 3, DST
-03:
+b   2f
+1:  over_white___ca_combine WK1, WK3
+2:  pixst   , 4, 3, DST
+3:
 .endm
 
 .macro over_white___ca_2pixels_head
@@ -837,21 +837,21 @@ generate_composite_function \
 pixld   , 8, 3, DST
 mvn TMP0, WK1
 teq WK1, WK1, asr #32
-bne 01f
+bne 1f
 movcs   WK3, WK1
-bcs 02f
+bcs 2f
 teq WK2, #0
-beq 05f
-b   02f
-01: over_white___ca_combine WK1, WK3
-02: mvn TMP0, WK2
+beq 5f
+b   2f
+1:  over_white___ca_combine WK1, WK3
+2:  mvn TMP0, WK2
 teq WK2, WK2, asr #32
-bne 03f
+bne 3f
 movcs   WK4, WK2
-b   04f
-03: over_white___ca_combine WK2, WK4
-04: pixst   , 8, 3, DST
-05:
+b   4f
+3:  over_white___ca_combine WK2, WK4
+4:  pixst   , 8, 3, DST
+5:
 .endm
 
 .macro over_white___ca_process_head  cond, numbytes, firstreg, unaligned_src, unaligned_mask, preload
@@ -1067,9 +1067,9 @@ generate_composite_function \
   .if \offset != 0
 ldrbORIG_W, [SRC, #\offset]
   .endif
-beq 01f
+beq 1f
 teq STRIDE_M, #0xFF
-beq 02f
+beq 2f
  .endif
 uxtb16  SCRATCH, \d /* rb_dest */
 uxtb16  \d, \d, ror #8   /* ag_dest */
@@ -1079,13 +1079,13 @@ generate_composite_function \
 uxtab16 \d, \d, \d, ror #8
 mov SCRATCH, SCRATCH, ror #8
 sel \d, SCRATCH, \d
-b   02f
+b   2f
  .if \offset == 0
 48: /* Last mov d,#0 of the set - used as part of shortcut for
  * source values all 0 */
  .endif
-01: mov \d, #0
-02:
+1:  mov \d, #0
+2:
 .endm
 
 .macro in_reverse___tail  numbytes, reg1, reg2, reg3, reg4
-- 
GitLab



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

Bug#1059854: libdrm2: New upstream available for libdrm

[Diederik de Haas]

On 02 Jan 2024 07:49:47 -0500 Richard Ayotte  wrote:
> Package: libdrm2
> Version: 2.4.117-1
> Severity: wishlist
> 
> A new upstream version of available for the libdrm2 package is available and
> needed to run Hyprland.

I guess this bug has technically be fixed, but as it hasn't been marked as such 
(and closed), I hope it's ok to 'reuse' this bug to request 2.4.122 which is 
needed for wlroots 0.18?

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

Bug#1072971: mesa: fails to initialize OpenGL on s390x: Unexpected format PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb

[Diederik de Haas]

Control: tag -1 -patch

On Friday, 28 June 2024 09:55:24 CEST Michel Dänzer wrote:
> > This is fixed in upstream commit 5ca85d75c05de9df7c3170122dfdb04bc795b43a
> > ("dri: Fix BGR format exclusion"), which I attached for your convenience.
> 
> Beware that this commit caused a regression on little endian platfors:
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/11398

Thanks for that. Let's remove the patch tag then.

The discussion has been reopened in the forwarded MR:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29837#note_2470033

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

Bug#1072971: mesa: fails to initialize OpenGL on s390x: Unexpected format PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb

[Diederik de Haas]

Control: tag -1 upstream, fixed-upstream patch
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/11360 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29837

On 14 Jun 2024 13:36:54 +0200 Emilio Pozuelo Monfort  wrote:
> Control: reassign -1 mesa 24.1.1-2
> Control: affects -1 kuserfeedback
> Control: retitle -1 mesa: fails to initialize OpenGL on s390x: Unexpected
> format PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
> 
> Actually this looks like a regression in mesa in 24.1. A few rdeps are
> failing their autopkgtests with the same PIPE_FORMAT_X8B8G8R8_SRGB error,
> e.g.:
> 
> https://ci.debian.net/packages/k/kodi/testing/s390x/47675600/
> https://ci.debian.net/packages/o/openscad/testing/s390x/47689316/

This is fixed in upstream commit 5ca85d75c05de9df7c3170122dfdb04bc795b43a
("dri: Fix BGR format exclusion"), which I attached for your convenience.

I haven't tried it as I don't have access to a s390x machine, so if
someone can verify it, that would be most welcome.

Cheers,
  Diederik>From 5ca85d75c05de9df7c3170122dfdb04bc795b43a Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Fri, 21 Jun 2024 11:24:31 +0100
Subject: [PATCH] dri: Fix BGR format exclusion
Origin: upstream, https://gitlab.freedesktop.org/mesa/mesa/-/commit/5ca85d75c05de9df7c3170122dfdb04bc795b43a
Bug-Debian: https://bugs.debian.org/1072971

The check we had for BGR vs. RGB formats was testing completely the
wrong thing. Fix it so we can restore the previous set of configs we
expose to the frontend, which also fixes surfaceless platform on s390x.

Signed-off-by: Daniel Stone 
Fixes: ad0edea53a73 ("st/dri: Check format properties from format helpers")
Closes: mesa/mesa#11360
Part-of: 
---
 src/gallium/frontends/dri/dri_screen.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/src/gallium/frontends/dri/dri_screen.c b/src/gallium/frontends/dri/dri_screen.c
index 97d11f324ee0b..2e9ce01147a89 100644
--- a/src/gallium/frontends/dri/dri_screen.c
+++ b/src/gallium/frontends/dri/dri_screen.c
@@ -386,17 +386,21 @@ dri_fill_in_modes(struct dri_screen *screen)
   uint8_t msaa_modes[MSAA_VISUAL_MAX_SAMPLES];
 
   /* Expose only BGRA ordering if the loader doesn't support RGBA ordering. */
-  if (!allow_rgba_ordering &&
-  util_format_get_component_shift(pipe_formats[f],
-  UTIL_FORMAT_COLORSPACE_RGB, 0)
+  if (!allow_rgba_ordering) {
+  unsigned sh_ax = util_format_get_component_shift(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 3);
+  unsigned sh_b = util_format_get_component_shift(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 2);
 #if UTIL_ARCH_BIG_ENDIAN
- >
+  unsigned sz_b = util_format_get_component_bits(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 2);
+
+  if (sz_b + sh_b == sh_ax)
+ continue;
 #else
- <
+  unsigned sz_ax = util_format_get_component_bits(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 3);
+
+  if (sz_ax + sh_ax == sh_b)
+ continue;
 #endif
-  util_format_get_component_shift(pipe_formats[f],
-  UTIL_FORMAT_COLORSPACE_RGB, 2))
- continue;
+   }
 
   if (!allow_rgb10 &&
   util_format_get_component_bits(pipe_formats[f],
-- 
GitLab



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

Bug#1066398: xwayland: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/testfile.c:17:(.text+0x9): undefined reference to `SHA1Init'

[Diederik de Haas]

Control: forcemerge -1 1065184

On Saturday, 13 April 2024 16:32:04 CEST Andreas Metzler wrote:
> > If you agree, please merge these two bugs.
> > FTR: Bug #1065184 is already fixed in git.
> 
> FWIW I can cobnfirm that xwayland builds successfully if libtirpc-dev is
> installed.

Thanks, then I'm merging the bugs. Today a "release to sid" commit was made, 
so this bug will be closed/fixed real soon now.

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

Bug#1065184: xwayland: missing build-dep on libtirpc-dev

[Diederik de Haas]

Hi,

I saw that this issue was fixed in git, but there hasn't been an upload with 
that yet. It seems it's blocking the armhf build of wlroots and therefor its 
migration, so could you upload a version with that fix?

Cheers,
  Diederik

PS: On Salsa 'upstream-unstable' is set as default branch, while 'debian-
unstable' seems more used as default branch? I think that's also why 
'vcswatch' seems to have trouble analyzing the repo (according to tracker.d.o)

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

Bug#1003091: xwayland: Xwayland uses glamor and shows black screens

[Diederik de Haas]

Hi,

On 21 Jan 2022 19:49:55 +0100 Gert van de Kraats  wrote:
> I reported the bug upstream for Xwayland:
> 
> https://gitlab.freedesktop.org/xorg/xserver/-/issues/1288
> 
> It will be fixed.

Could you update this bug with its status?
I got the impression that it is fixed upstream, but IIUC the commit that fixed 
it is as of yet only in the 'master' branch and (thus) not part of an upstream 
released version. But it also seems that this issue resulted in fixes in 
several projects? It appears that you were on top of (all the) things, so I 
figured it's better to ask you then trying to figure it out myself.

Cheers,
  Diederik

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

Bug#1066398: xwayland: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/testfile.c:17:(.text+0x9): undefined reference to `SHA1Init'

[Diederik de Haas]

Hi,

On Wed, 13 Mar 2024 13:06:09 +0100 Lucas Nussbaum  wrote:
> Source: xwayland
> Version: 2:23.2.4-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > /usr/bin/ld: /tmp/ccL8lXZd.o: in function `main':
> > ./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/./obj-x86_64-linux-gnu/
meson-private/tmpz22kr2qg/testfile.c:17:(.text+0x9): undefined reference to 
`SHA1Init'
> > collect2: error: ld returned 1 exit status
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2024/03/13/xwayland_23.2.4-1_unstable.log

It think this is actually https://bugs.debian.org/1065184 because:

1) https://sources.debian.org/src/xwayland/2%3A23.2.4-1/meson.build/#L263
is about using (g)libc's SHA1 implementation and #1065184 is about a change in 
glibc causing a FTBFS issue.
IIUC xwayland uses libgcrypt for the SHA1 implementation

2) near the end of your build log is the following message:
"../os/meson.build:63:8: ERROR: Problem encountered: secure-rpc requested, but 
neither libtirpc or libc RPC support were found"
And that matches the build issue mentioned in #1065184.

If you agree, please merge these two bugs.
FTR: Bug #1065184 is already fixed in git.

Cheers,
  Diederik

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

Bug#1063370: vulkan-tools: Fails to build from source.

[Diederik de Haas]

Control: tag -1 upstream fixed-upstream

On Tue, 06 Feb 2024 13:45:14 -0800 Elizabeth Loss-Cutler-Hull 
 wrote:
> Package: vulkan-tools
> Version: 1.3.268.0+dfsg1-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> In file included from /<>/vulkaninfo/vulkaninfo.cpp:33:
> /<>/vulkaninfo/generated/vulkaninfo.hpp: In function 
> ‘std::vector 
> VkVideoCodecOperationFlagBitsKHRGetStrings(VkVideoCodecOperationFlagBitsKHR)’:
> /<>/vulkaninfo/generated/vulkaninfo.hpp:1337:9: error: 
> ‘VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_EXT’ was not declared in this 
> scope; did you mean ‘VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_KHR’?
>  1337 | if (VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_EXT & value) 
> strings.push_back("VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_EXT");
>   | ^~~~
>   | VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_KHR
> /<>/vulkaninfo/generated/vulkaninfo.hpp:1338:9: error: 
> ‘VK_VIDEO_CODEC_OPERATION_ENCODE_H265_BIT_EXT’ was not declared in this 
> scope; did you mean ‘VK_VIDEO_CODEC_OPERATION_ENCODE_H265_BIT_KHR’?
>  1338 | if (VK_VIDEO_CODEC_OPERATION_ENCODE_H265_BIT_EXT & value) 
> strings.push_back("video_codec_operation_encode_h265_bit_ext");
>   | ^~~~
>   | vk_video_codec_operation_encode_h265_bit_khr
> 
> i confirmed that building through sbuild in a sid chroot behaves exactly
> the same way as building on my sid machine.
> 
> ...
> -- system information:
> ii  libvulkan1  1.3.275.0-1

The mismatch between 1.3.268 and 1.2.275 is likely the problem.
https://github.com/KhronosGroup/Vulkan-Tools/commit/64d9218726083ece79099341249890c75a5c4491
is where this issue was fixed and that commit is part of 1.3.274 (and higher).

If you downgrade src:vulkan-loader to 1.3.268.0-1 then it should compile again.

Looks like the vulkan-sdk versions need to be in sync.


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

Bug#1004125: Screen flickering with 2.4.109

[Diederik de Haas]

Control: tag -1 -moreinfo

On Thursday, 9 November 2023 08:48:27 CET Philipp Marek wrote:
> > If you can still reproduce this with the latest kernel and libdrm
> > packages,
> > can you open a new issue upstream? And mention that in this bug?
> 
> Well, right now with 6.5.0-1-amd64 I can't reproduce.
> (Yeah, that's not the latest, I know)

That sounds like you expect the issue to return 'any moment', so I'll refrain 
from closing this bug. From https://bugs.debian.org/796087 it appears that 
you're not the only one who sees issues come and go periodically.

The goal was to test it with a newer kernel/libdrm versions, so testing with 
6.5.0-1 was good enough AFAIC. 
If -4 would reintroduce the problem, that would be an interesting data point.

Looking at libdrm's commit log, I see periodically commits where they sync up 
with the upstream linux kernel. Maybe these issues come and go when there is/
was a mismatch between the kernel and libdrm (which the sync up then fixes)?

At https://snapshot.debian.org/binary/libdrm-intel1/ you can find (most) 
previous versions and if you still have the 5.15.0-3 kernel installed, could 
you try if version 2.4.110-1 with it would also solve the problem?
And try newer libdrm-intel1 versions if not till you find one where it is fixed.

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

Bug#1004125: Screen flickering with 2.4.109

[Diederik de Haas]

Control: tag -1 moreinfo

On 21 Jan 2022 12:23:33 +0100 Philipp Marek  wrote:
> See also https://gitlab.freedesktop.org/drm/intel/-/issues/1512

It's great that you participated in that upstream issue, but my guess is that 
it's not getting attention because the issue is closed.
If you can still reproduce this with the latest kernel and libdrm packages, 
can you open a new issue upstream? And mention that in this bug?

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

Bug#929130: falkon: Falkon crash at start

[Diederik de Haas]

Control: tag -1 moreinfo

On 30 May 2019 14:37:26 +0200 Bardot Jérôme  wrote:
> Le 29/05/2019 à 21:14, Bernhard Übelacker a écrit :
> > You might also want to look through "dmesg -T" output
> > if there is anything related to nouveau in the given time.
> > That might also be helpful for the maintainer.
> I add the output for previous execution (there is 2 minutes between
> falkon log and dmesg log because first time i didn’t had LC_ALL=C ) and
> re add previous log for libdrm-nouveau

This bug is quite old and it would be useful to know whether the issue
still exists.

I looked at your dmesg log and I'd recommend to update your BIOS and
make sure you have the latest intel-microcode package installed.

- BIOS A19 05/17/2016
You were running BIOS A19 (2016-05-27) and according to [1] there's now
an A28 version from 2019-07-15.

Once you've done that you can check the 'health' of your system with
the following commands:
- dmesg --level emerg,alert,crit
- dmesg --level emerg,alert,crit,err
- dmesg --level emerg,alert,crit,err,warn

Doing it in that sequence allows you to focus on the most important issues
first before looking into the 'minor' ones. 
Getting results on the 1st command is pretty bad. On the last one is to
some extend expected, but may be worth looking into nonetheless.

HTH

[1] 
https://www.dell.com/support/home/en-us/product-support/product/precision-t1700-workstation/drivers

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

Bug#1053864: libdrm-amdgpu1: gpu crash on graphics start with Radeon 760M (both sway and gdm3)

[Diederik de Haas]

Control: tag -1 moreinfo

On Fri, 13 Oct 2023 00:47:57 -0400 Simon Heath  wrote:
> Package: libdrm-amdgpu1
> Version: 2.4.115-1
> 
> When GDM3 starts, or when I turn it off and log into the console by hand
> and then start sway or another WM, often the graphics mode switch will
> hang for a few seconds on an unresponsive black screen, then go back to
> a text console for an instant and try again.  This seems to repeat 0-3
> times until eventually it works successfully.  Sometimes it works on the
> first try, often on the second try, etc.
> 
> Once Sway or GDM3 and Xorg have actually started, it *seems* perfectly
> stable, as far as I've seen so far.
> 
> I also see the following errors in dmesg associated with the
> apparent-crash-and-restart:
> 
> [   26.625039] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, 
> signaled seq=23, emitted seq=25
> [   26.625482] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process 
> information: process  pid 0 thread  pid 0
> [   26.625820] amdgpu :c1:00.0: amdgpu: GPU reset begin!
> [   26.810595] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
> [amdgpu]] *ERROR* MES failed to response msg=3
> [   26.810761] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to 
> unmap legacy queue
> ...
> Kernel: Linux 6.5.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)

Those messages are actually from the kernel driver.
Can you test whether the issue is still present with kernel 6.5.8-1 (Testing)
and if so, also try it with 6.5.10-1 from Unstable?

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

Bug#981618: libdrm: reduce Build-Depends

[Diederik de Haas]

On Tuesday, 7 November 2023 11:35:28 CET Diederik de Haas wrote:
> I did add the removal of the 2 B-Ds in that MR, but as it doesn't include
> all the items of this bug report, I won't close this bug with those
> changes.

FTR: https://salsa.debian.org/xorg-team/lib/libdrm/-/merge_requests/5

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

Bug#774899: libdrm-intel1: 855GM: Failed to submit batch buffer, expect rendering corruption: No space left on device

[Diederik de Haas]

Control: tag -1 = upstream moreinfo

On Thu, 15 Jan 2015 14:40:40 +0100 Matthias Großmann  
wrote:
> > There is a report for a similar bug (#725781), which was fixed
> > upstream (https://bugs.freedesktop.org/show_bug.cgi?id=59771#c29). If
> > you think there is a chance that this patch fixes my problem too, I'm
> > going to test it.
> 
> I applied the patch (ec65f8d71eb3eb065c7cadf4153138435ac3b388), but 
> unfortunately, this did not fix this bug.

I realize this is a very old bug and I'm wondering whether the issue is still 
present.
Can you check and report back (including with which versions you tested)?

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

Bug#981618: libdrm: reduce Build-Depends

[Diederik de Haas]

On Tuesday, 7 November 2023 14:06:23 CET Helmut Grohne wrote:
> On Tue, Nov 07, 2023 at 11:35:28AM +0100, Diederik de Haas wrote:
> > > I am not sure what you mean with heavy-handed here and why that would be
> > > an issue.
> > 
> > Not fully understanding it, it felt like "some tests may be problematic,
> > let's disable all them"
> 
> Do I understand correctly that this no longer is your understanding?

Yep, it adds the option to not do the test and in that case you also don't 
need the build dependency. Thus it doesn't unconditionally disable (all) the 
test, but gives the option/flexibility to do so.

Thinking about it some more, I actually use it myself a lot when building 
kernels. I pretty much always use the 'nodoc' profile, which saves ~1 GB of 
dependencies to install (IIRC, mostly due to texlive-latex-extra).
Or use the 'cross' profile when cross-compiling a kernel.

There's still a lot of magic (to me) involved and I don't fully/properly 
understand how it works (yet), but I do use it.

> > While I'm now less clueless about this then before, I don't feel
> > comfortable enough that I would be able to 'defend' the inclusion of the
> >  annotation, so I won't include that part in the MR I'm working
> > on.
> Fair enough. I can offer you two ways forward. You may add me as
> reviewer, so I can do the defending part if it becomes necessary. The
> correctness of a nocheck build profile can be technically validated. If
> you locally perform a build with and without nocheck and both produce
> the same artifacts (the reproducible bit-identical ense), then that's a
> very strong clue that the dependency wasn't used for building (but maybe
> used for testing). And since "nocheck" really means disabling all tests,
> you're right in thus annotating the dependency.

I actually have now build libdrm locally, but I usually let Salsa's CI do that 
for me. And I'm compiling it on my main PC and have yet to learn how to do it 
with tools like sbuild. It's on my TODO, but I'm not there yet.
I also want to learn tools like diffoscope (I think R-B is amazing), but I 
don't understand (its output) one bit. One day I will, but that will not be in 
the near future.

Did I miss option 2?

Thanks again,
  Diederik


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

Bug#981618: libdrm: reduce Build-Depends

[Diederik de Haas]

On Monday, 6 November 2023 22:13:45 CET Helmut Grohne wrote:
> On Mon, Nov 06, 2023 at 09:52:54PM +0100, Diederik de Haas wrote:
> > > And libx11-dev is only used in some tests.
> > > We can annotate libx11-dev .
> > 
> > Is that still the case?
> 
> I don't know. I filed the patch more than two years ago. A relatively

That was one of the reasons I asked ;)

> > Can you perhaps expand on why that annotation is appropriate (for my
> > learning experience)? Policy 4.9.1 mentions "to not run any build-time
> > test suite provided by the package" with the 'nocheck' tag, but that
> > sounds a bit heavy- handed to me?
> 
> I am not sure what you mean with heavy-handed here and why that would be
> an issue.

Not fully understanding it, it felt like "some tests may be problematic, let's 
disable all them"

> The technical term for  is "restriction formula" according to
> man deb-src-control. It expresses that when the nocheck build profile is
> enabled, the annotated dependency is disabled. The nocheck build profile
> may be used together with the nocheck build option to disable running
> build-time tests. Any such testing is not supposed to affect the output
> artifacts of the package in case the build succeeds. The method I used
> for validation here is performing such a nocheck build and comparing its
> artifacts with a regular build using diffoscope.
> 
> Note that none of the regular build daemons used for building packages
> on release architectures ever enable this build profile. It is enabled
> on some ports architectures and it is also enabled by default for cross
> builds. Nevertheless, a failure to build with a nocheck profile is
> considered release-critical since trixie, because the autoremover will
> consider breaking  annotated dependencies.

Thanks so much for taking the time to explain it :-)

While I'm now less clueless about this then before, I don't feel comfortable 
enough that I would be able to 'defend' the inclusion of the  
annotation, so I won't include that part in the MR I'm working on.
I did add the removal of the 2 B-Ds in that MR, but as it doesn't include all 
the items of this bug report, I won't close this bug with those changes.

Note that (currently?) the valgrand B-D is commented out/disabled in
debian/control, so together that may help with the (original) reason for filing 
this bug?

Cheers,
  Diederik

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

Bug#822220: libgl1-mesa-dri-experimental: When using nouveau gl driver it renders black window in 3d

[Diederik de Haas]

On 31 Aug 2011 Vladimir Berezenko  wrote:
> Package: libgl1-mesa-dri-experimental
> Version: 7.10.3-4
> Severity: important
> 
> On my powerpc G5 quad in debian testing when started glxgears the window it
> shows is completely black while seems that the 3d itself works because is
> shows FPS and not crash.
> Tested some other apps. Blender just crash, armagetronad shows black window
> with some rarely blinking graphics and squares.

According to the forwarded issue, it should've been fixed 4 years ago.
Can you confirm that's the case (so that the bug can be closed)?

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

Bug#981618: libdrm: reduce Build-Depends

[Diederik de Haas]

On Tue, 2 Feb 2021 07:34:35 +0100 Helmut Grohne  wrote:
> Source: libdrm
> Version: 2.4.104-1
> Tags: patch
> 
> libdrm no longer builds its documentation with xsltproc and ruses
> restructred text now. It also no longer uses xutils-dev.

I was able to confirm that those can be dropped.

> And libx11-dev is only used in some tests.
> We can annotate libx11-dev .

Is that still the case?
Can you perhaps expand on why that annotation is appropriate (for my learning 
experience)? Policy 4.9.1 mentions "to not run any build-time test suite 
provided by the package" with the 'nocheck' tag, but that sounds a bit heavy-
handed to me?

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

Bug#1036176: MR on Salsa which fixes these bugs

[Diederik de Haas]

Control: tag -1 - patch

On 13 Jun 2023 15:32:28 +0200 Diederik de Haas  wrote:
> Control: tag -1 patch
> 
> I've created a MR which fixes this bug here:
> https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/27

Removed the source format change from the MR, so remove the tag here too.

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

Bug#1032712: MR on Salsa which fixes these bugs

[Diederik de Haas]

Control: tag -1 patch

I've created a MR which fixes these bugs here:
https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/27

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

Bug#1009027: mesa: Please enable panfrost vulkan driver

[Diederik de Haas]

On Fri, 8 Apr 2022 07:16:25 +0300 Timo Aaltonen  wrote:
> Emma Anholt kirjoitti 7.4.2022 klo 22.41:
> >>> VULKAN_DRIVERS
> >>> - panfrost (there is already a gallium driver for this)
> >>
> >> ok
> > 
> > panvk is very much not ready for use and shouldn't be packaged.
> 
> thanks, won't add it then

A year has passed, Bookworm has been released and I'm seeing quite some 
activity in the upstream repo wrt panfrost vulkan driver:
https://gitlab.freedesktop.org/mesa/mesa/-/commits/main/src/panfrost/vulkan

Would now be a good time to enable vulkan for panfrost?

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

Bug#1029731: libglapi-mesa: Apps fail with 'DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory' after upgrade from 22.3.2-1 to 22.3.3-1

[Diederik de Haas]

On Thursday, 23 February 2023 04:44:16 CET Stuart Young wrote:
> Just a note that it looks like this patch got picked up in the 22.3.6
> release that just went out.

That's good to know, thanks.
But I don't know if at this stage in the Freeze new upstream releases are 
still allowed. I'm pretty confident that targeted fixes are and therefor I 
attached the patch. If 22.3.6 is allowed, that would be better I presume.

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

Bug#1029731: libglapi-mesa: Apps fail with 'DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory' after upgrade from 22.3.2-1 to 22.3.3-1

[Diederik de Haas]

Control: tag -1 upstream fixed-upstream patch

On Tue, 31 Jan 2023 01:19:54 +0300 Andrey Skvortsov 
 wrote:
> Here is link to created upstream issue.
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/8198

In https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21330 this issue 
got fixed upstream and I've attached the patch/diff to this message.

When adding it to debian/patches and adding it to debian/patches/series and 
running `debian/rules patch`, it applies cleanly (which is not the case for 
all of them):

```
me@laptop:~/dev/debian/salsa/xorg-team/lib/mesa$ debian/rules patch
dh patch --with quilt \
--builddirectory=build/ \
--buildsystem=meson
   dh_quilt_patch -O--builddirectory=build/ -O--buildsystem=meson
Applying patch 07_gallium-fix-build-failure-on-powerpcspe.diff
patching file src/gallium/include/pipe/p_config.h

Applying patch path_max.diff
patching file src/util/tests/cache_test.cpp
Hunk #1 succeeded at 82 (offset 1 line).
patching file src/util/tests/process_test.c
patching file src/gallium/auxiliary/pipe-loader/pipe_loader.c
Hunk #1 succeeded at 42 (offset -1 lines).

Applying patch src_glx_dri_common.h.diff
patching file src/glx/dri_common.h
Hunk #1 succeeded at 57 (offset 2 lines).

Applying patch bug102973-lima.diff
patching file src/gallium/drivers/lima/lima_resource.c

Now at patch bug102973-lima.diff
```

HTH>From c426e5677f36c3b0b8e8ea199ed4f2c7fad06d47 Mon Sep 17 00:00:00 2001
From: Erico Nunes 
Date: Sun, 12 Feb 2023 22:33:30 +0100
Subject: [PATCH] lima: don't use resource_from_handle while creating scanout

resource_from_handle implementations create an additional reference to
the scanout resource, which caused lima to leak those resources after
commit ad4d7ca8332488be8a75aff001f00306a9f6402e.

Do as the other drivers do and import the bo directly while creating
the scanount resource.

Cc: 22.3 mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8198
Signed-off-by: Erico Nunes 
Reviewed-by: Vasily Khoruzhick 
Part-of: 
---
 src/gallium/drivers/lima/lima_resource.c | 26 ++--
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/lima/lima_resource.c b/src/gallium/drivers/lima/lima_resource.c
index 54869ec03d24..0b7691f2b46f 100644
--- a/src/gallium/drivers/lima/lima_resource.c
+++ b/src/gallium/drivers/lima/lima_resource.c
@@ -59,7 +59,10 @@ lima_resource_create_scanout(struct pipe_screen *pscreen,
struct lima_screen *screen = lima_screen(pscreen);
struct renderonly_scanout *scanout;
struct winsys_handle handle;
-   struct pipe_resource *pres;
+
+   struct lima_resource *res = CALLOC_STRUCT(lima_resource);
+   if (!res)
+  return NULL;
 
struct pipe_resource scanout_templat = *templat;
scanout_templat.width0 = width;
@@ -71,20 +74,31 @@ lima_resource_create_scanout(struct pipe_screen *pscreen,
if (!scanout)
   return NULL;
 
+   res->base = *templat;
+   res->base.screen = pscreen;
+   pipe_reference_init(&res->base.reference, 1);
+   res->levels[0].offset = handle.offset;
+   res->levels[0].stride = handle.stride;
+
assert(handle.type == WINSYS_HANDLE_TYPE_FD);
-   pres = pscreen->resource_from_handle(pscreen, templat, &handle,
-PIPE_HANDLE_USAGE_FRAMEBUFFER_WRITE);
+   res->bo = lima_bo_import(screen, &handle);
+   if (!res->bo) {
+  FREE(res);
+  return NULL;
+   }
+
+   res->modifier_constant = true;
 
close(handle.handle);
-   if (!pres) {
+   if (!res->bo) {
   renderonly_scanout_destroy(scanout, screen->ro);
+  FREE(res);
   return NULL;
}
 
-   struct lima_resource *res = lima_resource(pres);
res->scanout = scanout;
 
-   return pres;
+   return &res->base;
 }
 
 static uint32_t
-- 
GitLab



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

Bug#991548: mesa: Since 20.3.5-1 AMD Vega GPU runs at max V and 90W in idle

[Diederik de Haas]

On Wed, 28 Jul 2021 16:52:47 +0200 Pim  wrote:
> This issue looks similar: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991453

Indeed, the symptoms sound very familiar.

According to the other bug report, it was a kernel issue which got fixed with 
5.10.46-3, so the most likely case is that it's already resolved.
'merspieler' can you confirm that?
The link in the submission doesn't work for me (anymore?), but the following 
command should make it clear whether it is the same issue as #991453:

$ cat /sys/class/drm/card0/device/gpu_busy_percent

and running 'sensors' showed quite a dramatic change in power1 and fans also 
got quiet again after 5.10.46-3.

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

Bug#964973: mesa-opencl-icd: Applications using OpenCL crash with : CommandLine Error: Option 'polly' registered more than once!

[Diederik de Haas]

On zaterdag 18 juli 2020 23:43:07 CEST Diederik de Haas wrote:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964791 seems similar,
> but not the same, but it could all be caused by the same thing.

I wonder why I said "similar, but not the same" as the error msg is exactly 
the same.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964791#10 links to https://
bugs.debian.org/cgi-bin/bugreport.cgi?bug=852746 which is forwarded to 
https://bugs.llvm.org/show_bug.cgi?id=30587 which seems to be the same 
problem.
Note that I only have 1 ICD package installed (mesa-opencl-icd) and 
/etc/OpenCL/ only has mesa.icd which seems to confirm this (afaiui).

So, does this mean that the bug is actually in LLVM?

Cheers,
  Diederik

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