From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ZPLKS46MFz335N for ; Fri, 28 Mar 2025 13:02:36 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ZPLKR4RNfz2xWD for ; Fri, 28 Mar 2025 13:02:35 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4ZPLKQ5XNszc0; Fri, 28 Mar 2025 13:02:34 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1743166955; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mNzZ8oR+Vp6/C/u6KfjCQnxKCwVmisXYjUACOEUYRmQ=; b=duTTlji0GbRA/Y/BX7I985n4+W0QtLD+L9F1af34OlvZRqq82MppqLgo4vJslKzgjweiNr 8u+mjcN6IZQy8CBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1743166955; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mNzZ8oR+Vp6/C/u6KfjCQnxKCwVmisXYjUACOEUYRmQ=; b=MeuYORP3D2Rjw9khIlAuIa6/DcP+p0NuimcfgShvRmPzrN5jTSzpimlA/hDLG2A8fzSf/t UryjRMvAXpEtU5RFKSpdKtI6Nv5ZAH53T2AIJHQEOM91a558ZXSk4+5yHl269ph1cyQ4Wl hI0rY0Biu2NlHey/nYuag9FeFRI8rdb8uOc4PLok31AgaXR0R5kX9v4r1y/4hcGujbaCaK VV0fp4+obMTBpwIIZx8lblgWIKNcUyj5VfuptVQNGap/PkbAOBb5LrxEsJFaOffNfNcZqd aRxtdNOPBFQAP8nSHQ1Hz6MFQ2Bjw8NCAWbs1YbHuoicZNAw2pevm9MdFK85aQ== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: Upload libloc to Debian From: Michael Tremer In-Reply-To: <9068f306-8558-4913-8c4e-dad8dc0ee42d@guardianproject.info> Date: Fri, 28 Mar 2025 13:02:34 +0000 Cc: Valters Jansons , Stefan Schantl , =?utf-8?Q?Peter_M=C3=BCller?= , Jochen Sprickerhof , location@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D9CC9EB-55CB-49F8-85B2-C79E3B1629FD@ipfire.org> <048f09d9-9985-a356-fed1-4cd8e286b87e@guardianproject.info> <968D3231-FFDF-4347-8A43-C0C6DF5ED887@ipfire.org> <9c740e42-cd03-428c-814a-fa8bdee99db9@guardianproject.info> <968FAB68-729C-4367-BA24-FDC1D1F885A7@ipfire.org> <6e7a9c4e-63c1-4896-bdb0-e621542ca3a7@guardianproject.info> <2B3195A3-B3AC-4002-A18B-275C58DDAA80@ipfire.org> <633f6312-7914-45db-882b-cb890a6f770c@guardianproject.info> <7A44A48A-9689-42AF-BC45-2B945CB9F0E1@ipfire.org> <50924840-11D7-4132-9124-576EB7B13549@ipfire.org> <9068f306-8558-4913-8c4e-dad8dc0ee42d@guardianproject.info> To: Hans-Christoph Steiner Hello HC, > On 27 Mar 2025, at 17:22, Hans-Christoph Steiner = wrote: >=20 > Michael, if you think libloc on mips64el has no real userbase, then we = can update the package to have looser requirements there. I have done = this on other packages, its kosher to do in this kind of situation. I think I was talking bollocks here. I assumed that in bookworm, we did = not have a package for mips64el, but we do. If we didn=E2=80=99t I would = have expected that sooner or later someone would come and ask for it. Preferably we support all architectures that Debian supports. As a user = of non-amd64, it was always super annoying if some package was missing. = So I don=E2=80=99t want to be *that guy*. However, as stated before, sometimes those problems are not the easiest = to solve... > Valters, if everyone is OK with it, I'd add you as a "Developer" on = the projects on Salsa. Then you can review and merge things to the = packages. >=20 >=20 >>> Towards that end, I made a merge request to review: >>> https://salsa.debian.org/debian/libloc-database/-/merge_requests/3 >> I am wondering if the d/watch mangle rule should be changed to follow >> the same sed logic as in d/rules. Left a comment on the PR and can be >> discussed there too. Overall, it looks like a good, helpful change. >=20 > I had the same thought, if that works for you, I think that would be a = better approach. >=20 > .hc >=20 > Michael Tremer: >> Hello Valters, >>> On 27 Mar 2025, at 00:25, Valters Jansons = wrote: >>>=20 >>> On Wed, Mar 26, 2025 at 10:30=E2=80=AFAM Hans-Christoph Steiner >>> wrote: >>>>=20 >>>> Valters Jansons: >>>>=20 >>>> This is great! One workflow we could use is adding you to the = libloc and >>>> libloc-location projects on salsa, then you could review and merge = changes >>>> there. Then you'd just need Jochen and/or I for reviewing and = uploading >>>> releases to Debian. How does that sound? >>>=20 >>> Hi Hans-Christoph, >>>=20 >>> I'm not a part of the IPFire/libloc team, however I would be happy = to >>> join as a maintainer for the Debian package. >>>=20 >>> I have historically maintained an Ubuntu PPA for use in my old >>> company, and in other projects afterwards on Ubuntu 22.04 and older >>> (before the Debian Universe package). I may have gaps in how = packaging >>> is expected, but overall I feel comfortable in moving the process >>> forward. >>>=20 >>>> Towards that end, I made a merge request to review: >>>> https://salsa.debian.org/debian/libloc-database/-/merge_requests/3 >>>=20 >>> I am wondering if the d/watch mangle rule should be changed to = follow >>> the same sed logic as in d/rules. Left a comment on the PR and can = be >>> discussed there too. Overall, it looks like a good, helpful change. >>>=20 >>> On Wed, Mar 26, 2025 at 12:17=E2=80=AFPM Michael Tremer >>> wrote: >>>>=20 >>>> Hello Valters, >>>>=20 >>>> Thank you for helping to get the upstream version nice and shiny. >>>>=20 >>>>> Michael, I haven't looked further into it, but mips64el = architecture >>>>> failed to build due to undefined _ABIO32 and _ABIN32. If you have = any >>>>> proposals, they would presumably be good to include in the = "upstream" >>>>> project directly. The build log is visible at >>>>> = https://buildd.debian.org/status/fetch.php?pkg=3Dlibloc&arch=3Dmips64el&ve= r=3D0.9.18-1&stamp=3D1742656796&raw=3D0 >>>>=20 >>>> Yes, this is the error that I got. I did not look further into it = because I am not aware of any users of MIPS for libloc, or even as a = whole. >>>>=20 >>>> I assumed this was a problem in Python. Looking for the two = constants, I am not sure which one to set, because hardcoding this would = break the build for other MIPS architectures. >>>>=20 >>>> What would you suggest to fix this? >>>=20 >>> Hi Michael, >>>=20 >>> Debian doesn't support MIPS 32-bit variants (mips or mipsel), but it >>> supports mips64el (64-bit little-endian). Even more so, for packages >>> to automatically transition out of unstable, mips64el is one of the >>> architectures expected to successfully build. I haven't seen MIPS in >>> real life myself, but Debian tooling having this automation check is = a >>> strong argument for patching the issue. >> Generally I am all in favour of having the library build for as many = things as possible. Usually any problems (e.g. like the recent = endianness issue) propagate across multiple architectures. >> Sometimes however, some niche problem exists in some niche = architecture. I am currently incredibly stretched with my own time, and = therefore there is not a very good idea to spend it all on some niche = problem where we probably won=E2=80=99t have any users anyways. I am = trying to find a happy balance here. >>> And you are correct about this being unexpected behavior in CPython. >>> The reason it bubbled up now is the addition of -Werror=3Dundef as a >>> compiler flag. Previously the undefined identifiers were silently >>> converted to zero, and _MIPS_SIM would never be zero so it was >>> "working as expected". >> I agree that this would abort the build. However, the problem is not = exactly in my code :) >> I would have expected the compiler to define those values depending = on the output architecture. >>> I am not yet 100% sure how the CPython internals get prepared, and >>> need to investigate a bit more before contributing upstream there. >>> What I have found is that the logic matches what is defined twice in >>> [Misc/platform_triplet.c] as "if _MIPS_SIM =3D=3D _ABIO32, elif = _MIPS_SIM >>> =3D=3D _ABIN32, elif _MIPS_SIM =3D=3D _ABI64". Debian's >>> [ArchitectureSpecificsMemo] recommends using _MIPS_SIM for = evaluating >>> what the architecture is. >>>=20 >>> _MIPS_SIM naming seems to be sourced from a legacy constant from >>> decades ago, and overall seems reasonable.The _ABIO32 name however >>> specifically seems to stem in gcc codebase from year 2003. There = were >>> libffi changes happening, and people were trying to avoid pulling in >>> legacy headers, so gcc had a patch ["Consistently use _ABIO32 for >>> _MIPS_SIM"] which defined _ABIO32=3D1 and switched to = _MIPS_SIM=3D_ABIO32 >>> (from some other inherited magic constant) for ABI_32. Over time as >>> other MIPS architectures were added, it transformed into a = switch/case >>> in [config/mips/mips.h] also defining _ABIN32 for ABI_N32 (as 2), >>> _ABI64 for ABI_64 (as 3) and _ABIO64 for ABI_O64 (as 4). >>>=20 >>> The current issue comes from the fact that these are defined as >>> compiler `builtin_define`. That means, mips64el knows about _ABI64 = but >>> doesn't know about _ABIO32 and _ABIN32. When CPython tries to use = all >>> three, two of them are undefined, so CPython should be checking >>> whether the values are defined before trying to use them. >>>=20 >>> Two solutions I can suggest now: Either downgrading -Werror=3Dundef = to >>> -Wundef so that it raises a warning (visibility) but doesn't fail = the >>> build, or adding the magic numbers based on gcc to libloc headers, >>>=20 >>> #ifndef _ABIO32 >>> # define _ABIO32 1 >>> #endif >>> #ifndef _ABIN32 >>> # define _ABIN32 2 >>> #endif >>> #ifndef _ABI64 >>> # define _ABI64 3 >>> #endif >>> #ifndef _ABIO64 >>> # define _ABIO64 4 >>> #endif >> So it seems that all those values are somewhat defined, because if I = add it to the compiler command line, I am getting this: >> In file included from : >> ././config.h:224: warning: "_ABI64" redefined >> 224 | #define _ABI64 1 >>> Both options have pros and cons, and I haven't been able to convince >>> myself which direction I believe to be more preferable as it stands. >>>=20 >>> [Misc/platform_triplet.c]: >>> = https://github.com/python/cpython/blob/v3.13.2/Misc/platform_triplet.c#L60= >>> [ArchitectureSpecificsMemo]: = https://wiki.debian.org/ArchitectureSpecificsMemo >>> ["Consistently use _ABIO32 for _MIPS_SIM"]: >>> https://gcc.gnu.org/legacy-ml/gcc-patches/2003-10/msg00607.html >>> [config/mips/mips.h]: >>> = https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dblob;f=3Dgcc/config/mips/mips.h;h= =3D616a275b918c34caf87f333f40e00866504156d7;hb=3D04696df09633baf97cdbbdd6e= 9929b9d472161d3#l560 >> On trixie, there is an additional problem where the build = dependencies cannot be installed: >> Setting up python3.13-minimal:mips64el (3.13.2-2) ... >> /var/lib/dpkg/info/python3.13-minimal.postinst: 51: = /usr/bin/python3.13: Exec format error >> dpkg: error processing package python3.13-minimal:mips64el = (--configure): >> installed python3.13-minimal:mips64el package post-installation = script subprocess returned error exit status 126 >> Errors were encountered while processing: >> python3.13-minimal:mips64el >> E: Sub-process /usr/bin/dpkg returned an error code (1) >> E: Failed to process build dependencies >> script returned exit code 100 >> Obviously this is emulated, but qemu-user-static is generally = available for mips64el. >> Given all these problems, I would be happy to receive patches, but I = don=E2=80=99t think I have enough experience and time to poke around = here. I am happy to assist though. >> Best, >> -Michael >>> --Valters Jansons >=20 > --=20 > Signal: +13478504872 > PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556