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 4ZNq9n3fflz32wd for ; Thu, 27 Mar 2025 16:39:09 +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 4ZNq9m3wm1z32mc for ; Thu, 27 Mar 2025 16:39:08 +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 4ZNq9l3zfDz2pq; Thu, 27 Mar 2025 16:39:07 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1743093547; 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=E4vCILffAcpeC+oIgLR+d6j2OeLRJWxxRsCIh+VtMhE=; b=ehjewKNTcP/qdIZxr0+Z/nFj5pXMEbR+ZFUd653WZew4mBepSbX/NSUYox+zk7cBA8886Y rjt/IHY9mcbJQ5Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1743093547; 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=E4vCILffAcpeC+oIgLR+d6j2OeLRJWxxRsCIh+VtMhE=; b=KeC/9q1eSzgTDgKoOV7+xWzIUY51h7tOafFaiO8cYmaYXnvHLx1t48JNtRVFWRMC4jqBFE EnE//apckFq5EdxazeFSl/cb7WJ0ulTLboPrkHG7y9yO7z9AJAbtsJC6N41ziUtoRxFiZQ fV01FfeEEyx5eThDbAHrrf7EDILWEHPsttpKPI2vYMut2R9KBMKrqp+/iXdGBbePeokvmW NWpVBr89G334kwUF/klAXsslx4ZGfjsPB9InhaoovRbkB13qonHpSEnvY3ZmnvncVMYNAq kQtcUVPyXa0i/4/mOcWr0iNscj22NFt5/XLVsvLjB+abYMlwwj116AFvSecv+w== 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: Date: Thu, 27 Mar 2025 16:39:07 +0000 Cc: Hans-Christoph Steiner , Stefan Schantl , =?utf-8?Q?Peter_M=C3=BCller?= , Jochen Sprickerhof , location@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB03F40-8299-4448-ADCE-064905D6B831@ipfire.org> <53A0D651-73FD-4A97-81E9-DC2D7565D7EF@ipfire.org> <26719411-D6EA-46E4-8259-487E39E72F7F@ipfire.org> <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> To: Valters Jansons 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