From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <location+bounces-15-archive=lists.ipfire.org@lists.ipfire.org> Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ZPLPJ6gKRz335N for <archive@lists.ipfire.org>; Fri, 28 Mar 2025 13:05:56 +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) client-signature RSA-PSS (4096 bits)) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ZPLPH6zYJz2xWD for <location@lists.ipfire.org>; Fri, 28 Mar 2025 13:05:55 +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 4ZPLPH0z50zlL; Fri, 28 Mar 2025 13:05:55 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1743167155; 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=7ELf1WeLubMjKzQ1+bzSLGnqsZwESTlA5nwv6s4WPZw=; b=Z6AJJJ86QIY/wQjK36M+MYZ58leXenuQcPdUo+bSo1G+7hanaNKAEUJG2x7rt9IO4LB5RB o0XijBkQ+IDUKTBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1743167155; 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=7ELf1WeLubMjKzQ1+bzSLGnqsZwESTlA5nwv6s4WPZw=; b=N+3fjwvNpUdONNhc7cddJLcRX0+ELb4xQu++5CjXEni47vEe/H8qGhG5+ByUwJB2lEvG3b UiziD+o/vv2XBSi9XhwQ2YN001TxzgPhsNNqAiKLeZC1G41ow1O9ElCFc3P9v8D444we2I enp0Wcstrp9TZjNI9vl1AbTsCtbeamiUBvmsoMaamRpsiIpJZD0NZXsWikR1rc9VA+xFcr y0eWgvA1xo7AjiPvee2EYBZ82JmHv0fPJoYWVxMCfgYMEtGODk9cirHiklfUw24S3UuSPg ANKdWNMyIvjnngjxFEnctH/la5CVF+ban2Hq0RCPqIjP84wAOxCdav2jisItKA== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: <location.lists.ipfire.org> List-Subscribe: <https://lists.ipfire.org/>, <mailto:location+subscribe@lists.ipfire.org?subject=subscribe> List-Unsubscribe: <https://lists.ipfire.org/>, <mailto:location+unsubscribe@lists.ipfire.org?subject=unsubscribe> List-Post: <mailto:location@lists.ipfire.org> List-Help: <mailto:location+help@lists.ipfire.org?subject=help> Sender: <location@lists.ipfire.org> Mail-Followup-To: <location@lists.ipfire.org> Mime-Version: 1.0 Subject: Re: Upload libloc to Debian From: Michael Tremer <michael.tremer@ipfire.org> In-Reply-To: <3209250b-4bb9-42f1-89d2-63ac86085148@guardianproject.info> Date: Fri, 28 Mar 2025 13:05:54 +0000 Cc: Valters Jansons <valter.jansons@gmail.com>, Stefan Schantl <stefan.schantl@ipfire.org>, =?utf-8?Q?Peter_M=C3=BCller?= <peter.mueller@ipfire.org>, Jochen Sprickerhof <jspricke@debian.org>, location@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: <FFD9F304-03BB-45C1-93AC-3DFABF25B6F3@ipfire.org> References: <YsU8pT9YYst9QLOY@vis.fritz.box> <3D9CC9EB-55CB-49F8-85B2-C79E3B1629FD@ipfire.org> <YvzqcBK2xTHB88PN@vis.fritz.box> <048f09d9-9985-a356-fed1-4cd8e286b87e@guardianproject.info> <f52d27c9f0bbf07481181248f4d37f6bd0fdab88.camel@ipfire.org> <968D3231-FFDF-4347-8A43-C0C6DF5ED887@ipfire.org> <9c740e42-cd03-428c-814a-fa8bdee99db9@guardianproject.info> <968FAB68-729C-4367-BA24-FDC1D1F885A7@ipfire.org> <CB346F61-9EB0-4651-AC1B-A880D725D918@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> <CA+sCei1C8QXxh6MB9U7bJ5U8EpW2V5Qi+xvh7rpDvNEDNjcjVg@mail.gmail.com> <50924840-11D7-4132-9124-576EB7B13549@ipfire.org> <CA+sCei0KN7rDFouoVtY6gPN=5FeWiydc=V4P5jg5pZ-_7LHcqg@mail.gmail.com> <FB71CEFD-4135-41E0-AB36-9F10926DF57E@ipfire.org> <9068f306-8558-4913-8c4e-dad8dc0ee42d@guardianproject.info> <3209250b-4bb9-42f1-89d2-63ac86085148@guardianproject.info> To: Hans-Christoph Steiner <hans@guardianproject.info> Hello, I would once again need help with this. In our configure script we are asking the system where it would like its = Lua stuff: = https://git.ipfire.org/?p=3Dlocation/libloc.git;a=3Dblob;f=3Dconfigure.ac;= h=3D1fae3a336f7a4e9165f9cca56e60c8c25476bab3;hb=3DHEAD#l231 I have been searching for documentation on how to handle this on Debian = as most packages are actually built for multiple versions of Lua. I = could not find out whether that is legacy stuff or actual policy and = what would be the best in our case. On my system the Lua interpreter = finds the module, so it cannot be that wrong :) Is there anyone from the Lua team we could contact? -Michael > On 28 Mar 2025, at 11:01, Hans-Christoph Steiner = <hans@guardianproject.info> wrote: >=20 >=20 > There seems to be some issues with the lua-location library, my = autotools is very rusty these days: > https://salsa.debian.org/debian/libloc/-/jobs/7328277 >=20 > E: lua-location: non-empty-dependency_libs-in-la-file = /usr/lib/x86_64-linux-gnu/libloc.la -lssl -lcrypto -llua5.4 -lresolv = [usr/lib/x86_64-linux-gnu/lua/5.4/location.la:20] > W: libloc source: = autotools-pkg-config-macro-not-cross-compilation-safe AC_PATH_PROG = [configure.ac:217] >=20 > Hans-Christoph Steiner: >> 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. >> 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. >>>> 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. >> I had the same thought, if that works for you, I think that would be = a better approach. >> .hc >> Michael Tremer: >>> Hello Valters, >>>=20 >>>> On 27 Mar 2025, at 00:25, Valters Jansons = <valter.jansons@gmail.com> wrote: >>>>=20 >>>> On Wed, Mar 26, 2025 at 10:30=E2=80=AFAM Hans-Christoph Steiner >>>> <hans@guardianproject.info> 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 >>>> <michael.tremer@ipfire.org> 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&ver=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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>> 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". >>>=20 >>> I agree that this would abort the build. However, the problem is not = exactly in my code :) >>>=20 >>> I would have expected the compiler to define those values depending = on the output architecture. >>>=20 >>>> 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 >>>=20 >>> So it seems that all those values are somewhat defined, because if I = add it to the compiler command line, I am getting this: >>>=20 >>> In file included from <command-line>: >>> ././config.h:224: warning: "_ABI64" redefined >>> 224 | #define _ABI64 1 >>>=20 >>>> 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=3D04696df09633baf97= cdbbdd6e9929b9d472161d3#l560 >>>=20 >>> On trixie, there is an additional problem where the build = dependencies cannot be installed: >>>=20 >>> 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 >>>=20 >>> Obviously this is emulated, but qemu-user-static is generally = available for mips64el. >>>=20 >>> 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. >>>=20 >>> Best, >>> -Michael >>>=20 >>>> --Valters Jansons >=20 > --=20 > Signal: +13478504872 > PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556