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 4ZNPb66cWJz332Q for ; Thu, 27 Mar 2025 00:26:10 +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 4ZNPb601YKz2ywd for ; Thu, 27 Mar 2025 00:26:10 +0000 (UTC) Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4ZNPb44Wnhz1yW for ; Thu, 27 Mar 2025 00:26:08 +0000 (UTC) Authentication-Results: mail01.ipfire.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=VB1kF3vc; spf=pass (mail01.ipfire.org: domain of valter.jansons@gmail.com designates 2001:4860:4864:20::33 as permitted sender) smtp.mailfrom=valter.jansons@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ipfire.org; s=202003rsa; t=1743035169; 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:dkim-signature; bh=IuIYaVdDebLP9JNSIc+Szqw0Lcn1goDwwHP+lyZbkEo=; b=QBnZjJeUkBxygRMf+fYZk1RO3vxpd4QQjKvWCYi1zAYBckVYUvqPLL1907yr5dlUZWq9T6 A6c/jQ1+jQY8F5SsXs/dSj9+B6Ry2oBwSyPHvpUjpQGbeRROBZD/BC1XbjZj4E+wrdNf39 BJOPBGErk6429nyOqzssQyRYI7p+wPD0frEp4HPHaBGwiMG6WPsA6SJ3Vy7/nggu19MOIW Y1pBA/BZIRGjEC/kla2lqjSsHd9S1AT8ievpKnXX4aD+m2Vf/pxAxsdAvT+dzCGrQuB/Nd AAvsDl5A1FjmtvHJzPkObrzkycKYM/CtJyhf0JHK4sPakSuqRQWaKB2D4vmiAg== ARC-Authentication-Results: i=1; mail01.ipfire.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=VB1kF3vc; spf=pass (mail01.ipfire.org: domain of valter.jansons@gmail.com designates 2001:4860:4864:20::33 as permitted sender) smtp.mailfrom=valter.jansons@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=202003rsa; d=lists.ipfire.org; t=1743035169; a=rsa-sha256; cv=none; b=aXVWUhW4fF0UmCt4PL7qzYhqDtfx2CCvwp9xGGFn4Kn+Y6InhePGVlJbiNYUu1DzsDR3SX 4ZIqg3mQDNMxsd5IH2No/ViM9+XNSDs58rhlzPmKK5Ipz2m/5UGoZ9wPnJQ4gOEuM/QGUu wBpL77DIK3xgN6IjM6rlFyYz3Egwp8X8Z9+pr9RPlNF2l/ky3yX1Abx0BGwaxagHRA/7xc 65alrJW9zwTn2YYWwh5+f6Bn8tOoy19YecCJU7s/KekawlnHanKzL9a0frkzmEy81bHHBJ 3c+BGOBKwMmOAmLunrwfo6gyQ05gTzmuLs3VXey4SmbJTkEvnEd6b0aCVPcIug== Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-2b3680e548aso837549fac.0 for ; Wed, 26 Mar 2025 17:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743035166; x=1743639966; darn=lists.ipfire.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=IuIYaVdDebLP9JNSIc+Szqw0Lcn1goDwwHP+lyZbkEo=; b=VB1kF3vc6WYk6Xin0Dl4XrE3kLtY1KS29qG/wLDE/tHRExGtPbENJL3W8EXs7DVZvZ /OZbK1wtgKjmI0jvlVGl1G1STmGc1ZsP0CgQZAnOSgXy8ZMTp2s8pfhD+TUsHUpR9eNB vMslpIQVBbJPvtAUFxoYu5mU2ieBDibplLY8s0K0cQ2F0i1IPhKmrpfm/0IKQmOVLi3K FqvRSU6j6TggsYiRD+f36gOq8Cjaee8N0yIUmjeGhsK51/D8RK1H3IpMQSdeGhyYpPu3 czYnplEDjR+x1OzFC+d2ISI2e3BM9BRIGUbW6prmO/luT/gyeDwMJ/ys6O0yUzQy5hI0 Q9FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743035166; x=1743639966; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IuIYaVdDebLP9JNSIc+Szqw0Lcn1goDwwHP+lyZbkEo=; b=q3po96w/fPow9r038JnZTVwFcRo3VA5NG2d+9CtyhHvFJN1pT2kcNV0uexH3M7HdR2 2qP73MHuG/dcKsKvDoR9/u8TY6uAj6bZ707cSHSjoGJdiJMq8WLwgD6fsbkli9xkvoX0 9xadlT68oEEQOTbYDTFPecYCKGE+C9GUWa17ueouGbdR0kdNLrBFO3p+4/Eu8rnrXX/x 4loz4y4Xh6R81N1h5+qdrShQXOM28e3oFg+BijCKm3XDGp+SXxKIlgqx2tF42z2jlZxj iOg21E+rbPpP0L5LnULeGp9UjQESHJ5tEX+iBXXSRajxi6o/xgvHxNo2hlhBpqxLAGud 37OQ== X-Forwarded-Encrypted: i=1; AJvYcCXIwBwpleBWR8lUBl+Rs7bCYORAEWwwGNsp2sG+00cMMs6NN1LfMnnTY80vAqOg9f2Ys39XaYUkUQ==@lists.ipfire.org X-Gm-Message-State: AOJu0YzCPGZP9ECs7OUh3tBptKjz3d8euxshFOuYJO46swmC1Ngk1MCc hpk4tEU1kRNppY9mx2pgAfrLUDwqhNsKmb2qMcjQR8MiA+e5iLOKmtttwpxHt95oshAwgeNpn95 aeKHS/QHtY679cS0InKY+tX3NrS4= X-Gm-Gg: ASbGncs4O/cFuqDlrHgamyvDUPM7OXkLAmJdWlWdoQXJfLzx4Ky9OknK9Je+PDr0Ol+ GfPg4pqecbj+wIMji0RfSx+15KNHGKA7+zyFsBi/tMUk+L5/FtOgWQJjx1ZdlGU7jyACqSUhVaZ 3VFRlIEaJlk1pp0MnS4RYjYMU71IY= X-Google-Smtp-Source: AGHT+IF5e0AagUUgZV8YVMJal5sCeNJQbTR+s2+ZhA0QsNsPGO+bRuxbP/2KZsgJ8QYs1WTRmza3ZDG0dKh8+ZOG2+4= X-Received: by 2002:a05:6870:9c87:b0:2bd:607c:c804 with SMTP id 586e51a60fabf-2c826acef59mr3367571fac.6.1743035166389; Wed, 26 Mar 2025 17:26:06 -0700 (PDT) Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 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> In-Reply-To: <50924840-11D7-4132-9124-576EB7B13549@ipfire.org> From: Valters Jansons Date: Thu, 27 Mar 2025 02:25:55 +0200 X-Gm-Features: AQ5f1Jqg4CG3AwW9cXXoGTVXHsQH74ZZdrVv2Fu6fA59UBM_ReSMsWxAFRRRPm0 Message-ID: Subject: Re: Upload libloc to Debian To: Michael Tremer , Hans-Christoph Steiner Cc: Stefan Schantl , =?UTF-8?Q?Peter_M=C3=BCller?= , Jochen Sprickerhof , location@lists.ipfire.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: mail01.haj.ipfire.org X-Rspamd-Queue-Id: 4ZNPb44Wnhz1yW X-Spamd-Result: default: False [-12.28 / 11.00]; REPLY(-4.00)[]; BAYES_HAM(-2.90)[99.56%]; R_DKIM_ALLOW(-1.68)[gmail.com:s=20230601]; NEURAL_HAM(-0.99)[-0.993]; DKIM_REPUTATION(-0.96)[-0.95536502739368]; SPF_REPUTATION_HAM(-0.65)[-0.65262636993106]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; IP_REPUTATION_HAM(-0.28)[asn: 15169(-0.28), country: US(-0.01), ip: 2001:4860:4864:20::(0.00)]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::33:from]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; FUZZY_RATELIMITED(0.00)[rspamd.com]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; ARC_SIGNED(0.00)[lists.ipfire.org:s=202003rsa:i=1]; PREVIOUSLY_DELIVERED(0.00)[location@lists.ipfire.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TAGGED_FROM(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Action: no action On Wed, Mar 26, 2025 at 10:30=E2=80=AFAM Hans-Christoph Steiner wrote: > > Valters Jansons: > > 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 change= s > there. Then you'd just need Jochen and/or I for reviewing and uploading > releases to Debian. How does that sound? Hi Hans-Christoph, I'm not a part of the IPFire/libloc team, however I would be happy to join as a maintainer for the Debian package. 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. > 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. On Wed, Mar 26, 2025 at 12:17=E2=80=AFPM Michael Tremer wrote: > > Hello Valters, > > Thank you for helping to get the upstream version nice and shiny. > > > 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 > > 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. > > 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. > > What would you suggest to fix this? Hi Michael, 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. 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 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. _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). 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. 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, #ifndef _ABIO32 # define _ABIO32 1 #endif #ifndef _ABIN32 # define _ABIN32 2 #endif #ifndef _ABI64 # define _ABI64 3 #endif #ifndef _ABIO64 # define _ABIO64 4 #endif 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. [Misc/platform_triplet.c]: https://github.com/python/cpython/blob/v3.13.2/Misc/platform_triplet.c#L60 [ArchitectureSpecificsMemo]: https://wiki.debian.org/ArchitectureSpecificsM= emo ["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=3D04696df09633baf97cdbbdd6e9= 929b9d472161d3#l560 --Valters Jansons