From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id vYD7Hx0Q12EvowAAgWs5BA (envelope-from ) for ; Thu, 06 Jan 2022 16:51:57 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id qKufGx0Q12HxgwEAauVa8A (envelope-from ) for ; Thu, 06 Jan 2022 16:51:57 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id F2C7D25CCF for ; Thu, 6 Jan 2022 16:51:56 +0100 (CET) Received: from localhost ([::1]:48388 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5V3T-0002zY-W5 for larch@yhetil.org; Thu, 06 Jan 2022 10:51:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53442) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5V1e-0001sG-QO for guix-patches@gnu.org; Thu, 06 Jan 2022 10:50:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:49075) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n5V1e-0006jb-DW for guix-patches@gnu.org; Thu, 06 Jan 2022 10:50:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n5V1e-000512-6E for guix-patches@gnu.org; Thu, 06 Jan 2022 10:50:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#52977] [PATCH 0/6] Update some minetest packages Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 06 Jan 2022 15:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52977 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Maxime Devos , Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 52977@debbugs.gnu.org Received: via spool by 52977-submit@debbugs.gnu.org id=B52977.164148416819238 (code B ref 52977); Thu, 06 Jan 2022 15:50:02 +0000 Received: (at 52977) by debbugs.gnu.org; 6 Jan 2022 15:49:28 +0000 Received: from localhost ([127.0.0.1]:41978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n5V16-00050E-Ca for submit@debbugs.gnu.org; Thu, 06 Jan 2022 10:49:28 -0500 Received: from mail-wm1-f66.google.com ([209.85.128.66]:37703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n5V11-0004zx-RE for 52977@debbugs.gnu.org; Thu, 06 Jan 2022 10:49:27 -0500 Received: by mail-wm1-f66.google.com with SMTP id l12-20020a7bc34c000000b003467c58cbdfso3440989wmj.2 for <52977@debbugs.gnu.org>; Thu, 06 Jan 2022 07:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=tDCaKsnoInZiY9cwlDKs238eGNb93OsYkmeS7vUvrZA=; b=bsZUAxtUxhWBGdOdVWr4O2F52NBRyxhrJnnGIFMEuWU5iZInE8YVRUN+B1ixiwo3wn j/0yguFy+g8OW6zG4mAZyTzMOAS8Ic0Nw6Tcfe9NccysFewtMHyugy8ASekYmZmyS6B2 CcGW0WMGA3oDcdayGyrxRYHtbcp8pAjs6PVF84bHpjUCikmL8q1UgsAYk8RPspNxxot1 T+WqBbKOwqVq0iXmifRPKKugDhFFNSuFZpJYPgBHSYQxWeynxaqQvoKaB9NHfbw+W97y c3gIsKRPiieJH3/k/HvOGE+4tnmWKA9VuID+O93AeojxNEKysG9t1ZlTaLFBGZGf5y8x qKcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=tDCaKsnoInZiY9cwlDKs238eGNb93OsYkmeS7vUvrZA=; b=AtCmKFG+5Tk/qB2cceA+H6a0/9oXMORmjdIz3PWq36jp8fiFRA2K7KMtERuM9rCb9J UIoE28pG9XGuZNgvZTu2QCTvudeMeWKLnWMrs6tXkIsTz1Au+Rxjyh18o6HQfQXG9n7y QfHobwmS60QQtYAoiRYTU4HI+teOGxF6sjtoYL418TTRtIvknMfNIotaCt4KOWczaoG8 Vz9tihANvf58v91gw+mibtfruf8pOw3NaOOzgOOJbBgNO2t/iAv2TLTAR57bCr2Up0AF GH8NU6caVvWEmf8Rj1WArOD2zgj3+TO6tByeWSB/Vg/4vN7MtolpY1SvhyQ/eVFCr06M nmPg== X-Gm-Message-State: AOAM531ROz1K7qIpoDZmsPXGUS3bE8EZ9W+1YwHA00bFDnU2UmB8ygpo SIX+NNKSydfkIpl31egzH9Y= X-Google-Smtp-Source: ABdhPJxhEqUNFxGg7MnA0nWlQgi8CcaImcHMZfCS8Rgq+3ODZASF4O+1bKQt4eq2iyDAddXv6un9uQ== X-Received: by 2002:a05:600c:510f:: with SMTP id o15mr7524122wms.104.1641484157947; Thu, 06 Jan 2022 07:49:17 -0800 (PST) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id o14sm6053647wms.4.2022.01.06.07.49.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Jan 2022 07:49:17 -0800 (PST) Message-ID: <7d62bc8873fdb79cd1aa5305d6c0cf06c85be9cc.camel@gmail.com> From: Liliana Marie Prikler Date: Thu, 06 Jan 2022 16:49:14 +0100 In-Reply-To: References: <0eceb36ac47fee789ebaa551cc3b041e777bbce1.camel@telenet.be> <87czl5hl2a.fsf@gnu.org> <07bdaad1c688d1cdf0a9f89f315e60cb6b2a084e.camel@telenet.be> <4dcbff837011d55f31b2514364c88e9011760a69.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641484317; h=from:from:sender:sender: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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=tDCaKsnoInZiY9cwlDKs238eGNb93OsYkmeS7vUvrZA=; b=HYgzPgiZmAgdnUonmCSJi0aWenXWUH/ECu/1PjYDIRjPWclvSVlf+j0cmN0TzbB6Gpx8K8 tv26dxqPcpbGZCGcnVtZEm7RA9jNFB6nmtk5pMND3sYtseu5lthLEaHAb/tCMKg6eWrHYa DhArKP05zRKkg+kTYNqcAqv6A/wfCw2HIkI3IF1Pypo6dtxXoT23Tbs1343J4wHKfxap1l 50YRYp/ySICVPI6qUJdYTnBxQVhEYwIttEEebTxuVnK+sMGmtTHw5PS0uvAjNE5gs+w1qX 8vSBT9Bi7ssLibRI/4xDJ7I+KjWLovgGEPn4uIppBut9ZxFoD7I2u0jd6L0aEw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641484317; a=rsa-sha256; cv=none; b=Z/P3WfmlNHD4dX2UdB9UTuuNqNYPubqzkMsV9ZC06hW5kUPvkVZ49bfGVJw99OfVlsQaXT InltL7xNRoIBI6wBX0yokzuLv84/9X3sNoSID5g7S+MhPniFKYLKVcaqbOntpnXoloZCYU qkE6Ph4CuQ4cQ+kNvKXrMzeWQugBvRNIyxt+u9iJEKY1UNQtDXHGMqpDd9CUm+FZPX5EhM lIrgIABZpbIxmScAjRhqIX4It6FWfwA6fJq96A7q55++1PyLNpTj10E/bO0WGeIDtbM4D4 1q5Z61jM9mFEF5mY6RfGa5MQizjhl+jR4fdCCKQmzfma+44e05yAVDNkZJXdVA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=bsZUAxtU; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.50 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=bsZUAxtU; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: F2C7D25CCF X-Spam-Score: -2.50 X-Migadu-Scanner: scn0.migadu.com X-TUID: rK65Rd4AplGz Hi, Am Donnerstag, dem 06.01.2022 um 09:33 +0000 schrieb Maxime Devos: > Hi, > > Liliana Marie Prikler schreef op do 06-01-2022 om 01:52 [+0100]: > > > [...] > > If I recall correctly, this was also a point of debate in the initial > > series that added the importer.  Can we establish an > > ordering/heuristic here?  E.g. "if we have git tags use those, > > otherwise use contentdb", "always use contentdb" or "always use > > whatever was edited most recently"? > > Keep in mind that the minetest importer doesn't know about git tag > -- the only interaction it has with git is cloning repositories > and checking out commits by the commit id provided by ContentDB. > I'm assuming you're referring to the generic-git updater here, > or a hypothetical minetest updater that has been modified to > interact with git tags. Ahh, sure, but imho it could try to make a best effort guess. E.g. if git tags are named like Minetest releases and exist in equal count, assume a mapping from one to the other. However if I recall correctly there was a ContentDB policy to only tag once, which makes the mapping from ContentDB version to git commit unique. Do I remember correctly? > * Problem with using git tags: git tags sometimes disappear. >   E.g., in minetest-ethereal, there's currently a tag >   2021-04-06 and 2021-09-23, but there's no tag for 2021-07-28 >   (the version currently in guix). > >   This could be resolved by including the commit instead of the >   tag in the package definition, and still searching for the git tag, >   but as I understand it, there have been some objections to > including the commit in the package definition > (https://lists.gnu.org/archive/html/guix-devel/2021-12/msg00259.html). Thanks for linking my thread :) I do cite minetest.scm as an exception there, since your comments make very clear what you're doing and why. However, my actual intent is blown way out of proportion, which has led to a lot of confusion on all sides and a rather long discussion. To clarify it here, I am trying to avoid the following pattern: (package (name "hello") (version "1.0") (source  (origin (method git-fetch) (uri (git-reference (url some-url) (commit "abcdef..."))) [...])) [...]) while encouraging both (package (name "hello") (version "1.0") (source (origin (method git-fetch) (uri (git-reference (url some-url) (commit (version->git-tag version)))) [...])) [...]) and (package (name "hello") (version (git-version "1.0" revision commit)) (source (origin (method git-fetch) (uri (git-reference (url some-url) (commit commit))) [...])) [...]) In the latter, revision and commit are let-bound as per Guix' standards. Now if you say "minetest mod packages are generally unreliable, git-version everywhere", that is completely fine by me. >   Even then, there's another problem: sometimes releases are made >   without a corresponding git tag.  E.g., on ContentDB there's a >   version 2022-01-05 but there's no 2022-01-05 tag in the git >   repository. > >   That could be resolved by ‘always use contentdb for minetest >   packages’ or ‘always use whatever was edited most recently’. > > * Problem with ‘whatever was edited most recently’: AFAIK git tags >   don't carry that information. Though the commit time/modification >   time in the commit it points to might be a decent approximation >   in practice. > >   ContentDB has some information on when a release was released >   (release_date, see https://content.minetest.net/help/api/). > >   I suppose this could work, though there's a slight problem: > >   The version scheme in guix would occassionally switch between x.y.z >   and YYYY-MM-DD, which would confuse the ‘these packages have been >   upgraded’ logic. Does ContentDB always use CalVer or are the repo owners in control of the tags? If there's a SemVer/CalVer conflict, I would say doing  (latest-semver)-(calver)-commit would probably be acceptable. At least I hope none of these mods release twice daily. > I suppose the best option would be to always use the version from > ContentDB (*), because the exact versioning scheme used doesn't > matter much, as long as it remains consistent over time, and just > using ContentDB is convenient. > > (*) Unless it isn't on ContentDB of course, though all minetest > packages currently in Guix are on ContentDB. If a package was used outside of ContentDB, that's not ContentDB's requirement, is it? Now perhaps there is an issue if the contentdb updater relies on the minetest-mod-build-system being used to determine that its suitable, rather than something else. > Additionally, if the forum versions / git tags / contentdb releases > are inconsistent (e.g. the forum and git tags are x.y.z and the > releases are YYYY-MM-DD), we could inform upstream that guix uses the > release titles because otherwise things become complicated for guix, > so if upstream doesn't want that, they need to use x.y.z in their > release titles as well > > Does that seem reasonable to you? I could write a patch to that > effect. Poking upstream maintainers sounds fun, but before making a hard decisions, perhaps we should reach out to them and ask what they consider the most reliable. If it's a wild mess, we could also use package-properties with an assumed default of "release title = git tag = forum post", e.g. (upstream-versioning . forum-post), (upstream- versioning . contentdb) and (upstream-versioning . git-version) to indicate who's right in case of a mismatch. WDYT?