#909436 libdrm: FTBFS on hurd-i386

Package:
src:libdrm
Source:
libdrm
Submitter:
Date:
2022-02-12 09:18:03 UTC
Severity:
important
Tags:
#909436#5
Date:
2018-09-23 16:21:49 UTC
From:
To:
Hello,

Currently libdrm FTBFS on GNU/Hurd due to a missing case in
include/drm/drm.h. Attached is a patch, hurd-port.diff, to fix this and
fixes for PATH_MAX issues in in xf86dri.c and include+defines for GNU
in xf86dri.h.

Additionally the patches debian_rules.diff and debian_control.diff adds
Hurd to the architecture list.

Thanks!
#909436#18
Date:
2020-04-24 07:17:21 UTC
From:
To:
found 909436 2.4.101-2
thanks
#909436#25
Date:
2020-05-10 17:56:17 UTC
From:
To:
ping
#909436#30
Date:
2020-09-14 15:44:24 UTC
From:
To:
found 909436 2.4.102-1
thanks

Hello again,

libdrm still FTBFS on GNU/Hurd now due to bug #970304 and still missing
support for Hurd in drm.h and xf86drm.h. Attached is a patch, hurd-
port.diff, to fix this. The rest of that patch address PATH_MAX issues
in xf86dri.c as PATH_MAX is not defined for GNU/Hurd.

Note: hurd-port.diff depends on that xf86drm.c.diff in #970304 is
applied before!

Additionally the patches debian_rules.diff and debian_control.diff adds
Hurd to the architecture list.

Thanks!
#909436#37
Date:
2020-09-14 17:52:19 UTC
From:
To:

these would need to go upstream..
#909436#49
Date:
2020-09-15 20:49:40 UTC
From:
To:
thanks, but I'm afraid they don't get noticed unless they're sent as
merge-requests..
#909436#54
Date:
2020-09-16 07:53:09 UTC
From:
To:
I don't know how to create a merge request. Maybe you can do that?
Alternately, what hinders you from applying the patches in Debian until
upstream responds?

Thanks!
#909436#59
Date:
2020-09-16 14:14:38 UTC
From:
To:
It's gitlab, so merge-requests are done just like on salsa.
#909436#64
Date:
2020-09-16 14:27:00 UTC
From:
To:
Sorry I don't have a salsa account, and never used gitlab on salsa. What about
applying the patches to librdm-2.4.102-2 until merge requests have been created,
either by you or me (after researching how to do a merge request).

Thanks!
#909436#69
Date:
2020-10-14 01:20:06 UTC
From:
To:
Hello,

Svante Signell, le lun. 14 sept. 2020 17:44:24 +0200, a ecrit:

Rather use _IOC_COMMAND, that'll fix it into taking 7 bits only, not 8.

Samuel
#909436#74
Date:
2020-11-10 18:03:58 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
libdrm, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 909436@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Timo Aaltonen <tjaalton@debian.org> (supplier of updated libdrm package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 10 Nov 2020 19:51:20 +0200
Source: libdrm
Architecture: source
Version: 2.4.103-1
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
Changed-By: Timo Aaltonen <tjaalton@debian.org>
Closes: 909436 970304
Changes:
 libdrm (2.4.103-1) unstable; urgency=medium
 .
   * New upstream release. (Closes: #970304)
   * control, rules, hurd-port.diff: Add support for Hurd. (Closes:
     #909436)
Checksums-Sha1:
 49f95a424ad26daeb60293cbca386cb174f71059 3326 libdrm_2.4.103-1.dsc
 7583f6c48fca590cbf813e6d92bc4d26f7f4e0ee 412796 libdrm_2.4.103.orig.tar.xz
 b072ee945f648eb9462c927bbded31291fe6e855 833 libdrm_2.4.103.orig.tar.xz.asc
 5e6d56ee7baf0b7fc51ebb077b93cb9811cc4c7c 54832 libdrm_2.4.103-1.debian.tar.xz
 ecb02b98684c3fded6c642d498d9a45fa73d30b9 8219 libdrm_2.4.103-1_source.buildinfo
Checksums-Sha256:
 7580d383c04f83ee1f03e4dc1e9de7331517b2d195bce62186d1c0d7a44c02b4 3326 libdrm_2.4.103-1.dsc
 3fe0affdba6460166a7323290c18cf68e9b59edcb520722826cb244e9cb50222 412796 libdrm_2.4.103.orig.tar.xz
 b15719eb4943fed298dfe94eb8192c183ca4771d07c3eb55be494b73d47a9178 833 libdrm_2.4.103.orig.tar.xz.asc
 057cce20c8d9227a3c0b69b8af156046261bf126eae5e89db3b78790e3d866e2 54832 libdrm_2.4.103-1.debian.tar.xz
 c14c7842399c284f22eb7d766a93a760cf02a457f7d0734143f201b435eac357 8219 libdrm_2.4.103-1_source.buildinfo
Files:
 a1e06e9101d14e09c08bb9b9c342a45e 3326 libs optional libdrm_2.4.103-1.dsc
 002e4e06e7f23fadc2ec6dbd03f3d1ee 412796 libs optional libdrm_2.4.103.orig.tar.xz
 7cef30fe10e154268b54552bc984a15a 833 libs optional libdrm_2.4.103.orig.tar.xz.asc
 d2e48b6b0aa32eacb0f1f3b33bdebebe 54832 libs optional libdrm_2.4.103-1.debian.tar.xz
 f81b95bca19c96571374529b8e4d6c17 8219 libs optional libdrm_2.4.103-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdS3ifE3rFwGbS2Yjy3AxZaiJhNwFAl+q02EACgkQy3AxZaiJ
hNxW/w//VIE4gR9c8Nci0aYsDqACXPMpNiong2bMjTvNJ4Hlm/Pp1hZqhntPNK90
opYEAN5KpgzhMDwy44Ea6rnPb3wJqMvr+wXBQxa4hykgX/2CofzVwtJ/qiSP5B3j
1vZs8UhHGZOrrrHu4VYat9V6AOqBwq5EKjd0gIvIWh9LLfD3Z4e7k4VZsb5M9MU0
T0qqTpesu4/c0OW6yRAkqLO5jWEePuiKsSP84LzjclGyChivBHYCHi14Q4IGByzB
tkgYGgn8CycvYuzz434UN/JEQn4b/6WMs+/3OWwGSYZ0ZbVzL0ofUijUE/8mcZY1
zz22x3gzFIHjLcOj0K7cUCQxWhT2Uw7TmWYmb0yNAkUOWTBLgjtUp73RfCFKHGvj
KlWKXLa9Sq7NEx6pPNYbO24kPrJSS38inPwzPx6YOPDsprPGvJBL3Iqv0ebIZZQJ
lFL/pXK2yGvNV9wrfGIrSS+PenH1jOg1uhm4ESud/MvWPML0V0va0jUXRZp8KzIY
90GvGShwofTWchhr1THWvuXc/ORXV2wIPj7HzSZx5WioWEJ1DRp5kz68ya1l/+/c
ak/dStVtwP4ai+ETXDobKlEOfxSvHro2vspuopaxTb6jiB8L7KZbr9LplRdbJ9aK
ZtX+eZxA3j2LZ8HWAT5iHeJ/n2zpRtdBDXPwlDdVUALvbwum63Y=
=+b/X
-----END PGP SIGNATURE-----
#909436#83
Date:
2021-04-26 21:43:37 UTC
From:
To:
Hello Svante,

For information, your patch got dropped because of #975658

Samuel
#909436#88
Date:
2021-04-26 23:04:30 UTC
From:
To:
Yes I know since a long time. And you did not care or anybody else
either. So why bother... Why spend time on worthless issues?
#909436#93
Date:
2021-04-26 23:06:06 UTC
From:
To:
Svante Signell, le mar. 27 avril 2021 01:04:30 +0200, a ecrit:

Ok, I hadn't seen it.

Well, usually it's the patch author who follows up on its consequences.

Worthless? Qt5 depends on it.

Samuel
#909436#98
Date:
2021-04-27 07:21:39 UTC
From:
To:
You need to send them upstream. Mesa is also carrying a patch which is
basically useless since it again fails to build on hurd due to other issues.
#909436#107
Date:
2021-12-06 12:44:17 UTC
From:
To:
Hello again,

libdrm still FTBFS on GNU/Hurd, now ate 2.4.108-1. Attached are two
updated patches, hurd-port.diff and path_max.diff.

libdrm-2.4.108-1 (and 2.4.104-1) has been built and tested fine on
GNU/Linux and GNU/Hurd. On Linux the patches have also been tested with
valgrind using the package drm-info, depending on libdrm2. With the
previous patch for path_max the bug reported in #975658 has been
verified with the program drm_info. The patches are now valgrind-clean:

valgrind drm_info
...
==8475== HEAP SUMMARY:
==8475==     in use at exit: 0 bytes in 0 blocks
==8475==   total heap usage: 1,891 allocs, 1,891 frees, 277,802 bytes
allocated
==8475==
==8475== All heap blocks were freed -- no leaks are possible
==8475==
==8475== For lists of detected and suppressed errors, rerun with: -s
==8475== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

(Compiling xf86drm.c still causes a lot of warnings, but these are
already present in the upstream code.)

Thanks!
#909436#112
Date:
2021-12-15 15:58:55 UTC
From:
To:
please send a MR upstream
#909436#117
Date:
2021-12-16 22:44:34 UTC
From:
To:
I'll try. But I don't know yet how to create an MR, any ideas?

Thanks!
#909436#124
Date:
2022-01-18 16:46:42 UTC
From:
To:
Hello again,

libdrm still FTBFS on GNU/Hurd, now at 2.4.109-2. Attached are two
updated patches, hurd-port.diff and path_max.diff and two new ones.
hurd_port.diff, path_max.diff, tests_amdgpu_ras_tests.c.diff and
tests_amdgpu_amdgpu_test.c.diff.

The above patches will be submitted to upstream in due time.  For completeness
they are attached here, and as they were not included in the email announcing
them, dated 06 Dec 2021.

On GNU/Hurd the executable amdgpu_test is built but not on GNU/Linux. Therefore
override_dh_missing in debian/rules complains.
dh_missing --fail-missing
dh_missing: warning: usr/bin/amdgpu_test exists in debian/tmp but is not
installed to anywhere
dh_missing: error: missing files, aborting

The added file can be incorporated in libdrm-tests.install file with
using dh_exec and making libdrm-tests.install executable.
+#! /usr/bin/dh-exec
+[hurd-any] usr/bin/amdgpu_test

Alternately (and simpler) a separate file for Hurd can be created solving the
same problem. Attached is a patch creating that file: libdrm-
tests.install.hurd.diff

Built and installed on both GNU/Linux and GNU/Hurd. valgrind drm_info still
reports "All heap blocks were freed -- no leaks are possible"

Thanks!
#909436#129
Date:
2022-01-19 19:20:09 UTC
From:
To:
Add to this a build-dependency of dh-exec needed in debian/control.
--- a/debian/libdrm-tests.install       2021-12-15 16:55:18.000000000 +0100
+++ b/debian/libdrm-tests.install       2022-01-12 18:28:35.000000000 +0100
@@ -1,3 +1,3 @@
-usr/bin/amdgpu_stress
+usr/bin/amdgpu_*
 usr/bin/drmdevice
 usr/bin/modetest

Thanks again!
#909436#134
Date:
2022-02-11 21:22:52 UTC
From:
To:
The patches are now submitted to
https://gitlab.freedesktop.org/mesa/drm/-/issues/24

Would this be enough to make upstream aware, or is something else
needed, like a merge request?

Thanks!
#909436#139
Date:
2022-02-12 09:14:44 UTC
From:
To:
Svante Signell kirjoitti 11.2.2022 klo 23.22:

A merge request would be better, it allows code review etc.