From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id wAzgEQmV82SdXQEAG6o9tA:P1 (envelope-from ) for ; Sat, 02 Sep 2023 22:03:21 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id wAzgEQmV82SdXQEAG6o9tA (envelope-from ) for ; Sat, 02 Sep 2023 22:03:21 +0200 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 D3BB35DC2A for ; Sat, 2 Sep 2023 22:03:20 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=VDfGTUwz; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1693685001; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=fLrJqyquC18jZNfORgzjTLElr9lAX2z8+aKldAeY1J4=; b=YAjyS/xjB31b1e8T/2gHu2bZ9+rMfEwDc4iks0SDu6OXXAzxwW9cbLfml9PielZhYg3g4w ruf3WfDIE9ziUMUg+ZF13FJc6i5a7AJu3x0HqdcWc9aRYEhKUlmsVr23t/JxYcOHQG4bkG zEulkiV1BnxTDQH8lqeZTUVs/7D3TsaZ2k00L5u76eKqGT6QRCUyDgCjmL7j8YqasKiUx7 3q282EZwji2VHAr8vkQgYtxdUChPmRx2a+52RJ0Eh1IQoufM9Rcg8VVQFeNNjiKpYDJ4e+ JbllUuhUcNK28RqVYXUHppQ6ozEV0hg2gFokx+7e1GhfwdAkm6mDgtTGpauTHQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=VDfGTUwz; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693685001; a=rsa-sha256; cv=none; b=gkeQmrqV5WDqdoBltlP1/wHdTZ9cq9OiLp1yQfyx2OLmu/HzW5aZmVQAdvIOlfTvAy+VhB jpjQBLBoQzlDYEeVpwnFCxsyZo12x7Cb5L/BBbbYV6wSDbRVeIoOoL3WiyaINwu7sPrPvI N8mF4pvr1vRS3OxU2RFhp6w1Ob7ItrRQsyHOtp1pa/f6gXknZNa7F4MJs/vOEkwdvL2WjB eo8MScGH/B5a5oFlq6ihr+atibSiQgowIt5SW3Lbf+5MVSEBR6dfkF8F74cC2rADRq5/4u xbAaEKHFuWaQHQgLQl42Smm0p9hYdq5kFaCQOiT/atbX68n2URwYc5ivUgR3CA== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qcWpP-00029m-ES; Sat, 02 Sep 2023 16:02:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qcWpN-000299-Pt for guix-devel@gnu.org; Sat, 02 Sep 2023 16:02:41 -0400 Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qcWpL-0002UD-0k for guix-devel@gnu.org; Sat, 02 Sep 2023 16:02:41 -0400 Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-41369b80875so638571cf.1 for ; Sat, 02 Sep 2023 13:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693684957; x=1694289757; darn=gnu.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fLrJqyquC18jZNfORgzjTLElr9lAX2z8+aKldAeY1J4=; b=VDfGTUwzAv4EbmFGUZY6yOlQZG/VeotOg3UyrAz8jG2JKPX4BEHqOg0bcBZ8wqtG9w 9oLxheZzFH5iZd6Dn8lscTrF7fn97lW3h4hs4M9BYReH8m8jbvy7qNfRwr/ptaayV3Dy tB+3bjETUKFgpQOZriM3a3YoonHMTBfYf/uLUXUa8uCMNg46vrydu3JKFDm9li3zvmEG RNV4DqGr5HroqttasWYNKSnT78wv8Av1FUGsDeo/SXF/D8qm6GfwiNl7zhGMmrk9IobQ Bc2cJ02qlKLhh0+5eu6uHpJCHKVSObSxEEITlhRwLvOuho7w79nsEWZXa3hH4yQgloMt CCJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693684957; x=1694289757; h=content-transfer-encoding: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=fLrJqyquC18jZNfORgzjTLElr9lAX2z8+aKldAeY1J4=; b=H3tW7KTD0PbWCOOmg9+OzbbASpolftWwhnM3Sp4y4Gq/NQELQOZ65nz4qNiJv/OwfW 1Kycc2z4kypSBdotEFeqoLrwdTxmPoC+5zHNR0SWau81fzUCBdFd8IiN3wT23g5DxXz8 5p2TkI/bvEQ+OHd+BPZQJ1SVXVDGkovgqqWJqbc+yWRtVn35VT7Oy0neImsghS/n0jWc 0ediGdeBXGgmUGKD17htIoWZmGwI8YKMpxaC7arX2ESf5LALAmiVQirt1N7rJion8gS2 kDd/TwtT3E3NoErM0zzDNET5bXigguQlgQXz50C3vybXRtzdLF57EQB62A8fEmSK4s38 hV7A== X-Gm-Message-State: AOJu0YztXwMAvM10Tg4ueFNK7O1kySDlDzZVAwVA+cEQoAW5FoV4h+RF Vr2lqBTJxvNWUtuBygwsAPonW5EOYwDgU2L0qOEY2/GcY/U6+Q== X-Google-Smtp-Source: AGHT+IHyi4NsPFi66+5QidJwPL/rnqe/paqv1PhdsUXb/nuaEffbSrceiyBa2HRwbFFBW9DUJvGDFfSkg4IuiIb3uMA= X-Received: by 2002:ac8:5c85:0:b0:403:f389:5793 with SMTP id r5-20020ac85c85000000b00403f3895793mr8609660qta.32.1693684957323; Sat, 02 Sep 2023 13:02:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Eidvilas_Markevi=C4=8Dius?= Date: Sat, 2 Sep 2023 23:02:26 +0300 Message-ID: Subject: Re: Relaxing the restrictions for store item names To: guix-devel@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::82f; envelope-from=markeviciuseidvilas@gmail.com; helo=mail-qt1-x82f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: D3BB35DC2A X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -6.59 X-Spam-Score: -6.59 X-TUID: mBP5+zqifytf So I've being trying to tackle this issue by myself somewhat [1], but very quickly got into a problem where, even when the restrictions inside the store-api.cc are gotten rid of, this strange error appears on an encounter of any non-ASCII character that I don't know how to deal with: $ guix build -L . test-=C4=85=C4=8D=C4=99=C4=97=C4=AF=C5=A1=C5=B3=C5=AB Backtrace: In srfi/srfi-1.scm: 673:15 19 (append-map _ _ . _) 586:17 18 (map1 ("x86_64-linux")) In guix/scripts/build.scm: 713:21 17 (_ _) In guix/store.scm: 1380:11 16 (map/accumulate-builds # # _ #:cutoff _) 1298:8 15 (call-with-build-handler # _) In guix/scripts/build.scm: 672:18 14 (_ _) In guix/store.scm: 2168:25 13 (run-with-store # _ #:guile-for-build _ #:system _ #:target _) 1996:8 12 (_ _) In guix/packages.scm: 1970:11 11 (_ _) In guix/store.scm: 2040:38 10 (_ #) In guix/derivations.scm: 833:24 9 (derivation # "test-=C4=85=C4=8D=C4=99=C4=97=C4=AF=C5=A1=C5=B3=C5=AB-0" "/gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile" ("--no-auto-compile" "-L" "/gnu/s=E2=80=A6" =E2=80=A6) =E2=80=A6) 690:10 8 (derivation-hash _) 677:5 7 (write-derivation _ #) 630:4 6 (write-string-list _) In srfi/srfi-1.scm: 634:9 5 (for-each # ("/gnu/store/14i2qkvlx6gi98akhwwk7bh26s710s35-test-=C4=85=C4=8D=C4=99=C4=97= =C4=AF=C5=A1=C5=B3=C5=AB-0-builder")) In guix/derivations.scm: 626:4 4 (_ "/gnu/store/14i2qkvlx6gi98akhwwk7bh26s710s35-test-=C4=85=C4=8D=C4=99=C4=97= =C4=AF=C5=A1=C5=B3=C5=AB-0-builder") In unknown file: 3 (put-string # "/gnu/store/14i2qkvlx6gi98akhwwk7bh26s710s35-test-=C4=85=C4=8D=C4=99=C4=97= =C4=AF=C5=A1=C5=B3=C5=AB-0-builder" # #) In ice-9/boot-9.scm: 1685:16 2 (raise-exception _ #:continuable? _) 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: Throw to key `encoding-error' with args `("put-char" "conversion to port encoding failed" 84 # #\=C4=85)'. If anyone is knowledgeable enough to tell me why this happens and/or how to fix it, I'd be grateful. Thanks. Also, sorry for not opening a separate issue on the debbugs for now; I will, if it turns out that the problem is a bit more than I can chew on by myself (which, from the looks of, may actually be the case, but I'm not entirely sure yet... maybe it's an easy fix). [1] https://gitlab.com/markeviciuseidvilas/guix On Tue, Aug 22, 2023 at 9:49=E2=80=AFAM Eidvilas Markevi=C4=8Dius wrote: > > Hello Guix, > > Not long ago, somebody has raised an issue regarding an error that > occurs whenever some unconventional character is used as the name for > a store item [0]. Tobias Geerinckx-Rice pointed out that this > restriction was directly inherited from the Nix source code [1] and > that, as such, it isn't really a bug. Regardless, I believe that the > imposed limitation may be undesirable in some situations. One that I > can think of off the top of my head is packaging a piece of software > with a name that contains non-Latin characters in it (e.g., > "Nar=C5=A1ytuvas" by Ra=C5=A1tija [2]). Of course, there are very few exa= mples > of such programs in actual practice, but there's a small chance of > encountering them from time to time, especially if they're oriented > towards non-English speaking users, and personally, I don't feel like > resorting to transliteration is a good solution to this. After all, > it's 2023, why would such a restriction need to be there in the first > place when most filesystems are able to handle unicode characters just > fine? > > Another scenario where these artificial restrictions could be a > potential cause of trouble is when we consider a possibility that Guix > might be used for packaging and distributing not only software, but > all kinds of non-executable data such as films, books, music, > databases, historical documents, website archives, etc. [3]. In the > case of website archives: say I wanted to package the contents of the > whole ra=C5=A1tija.lt website. When choosing the package name for it, > should I go with "rastija.lt", "rashtija.lt", or "ra=C5=A1tija.lt". The > latter would be a clear winner in my mind, since it is the canonical > domain name for that particular site. And for all other types of data > and media packages, using the official/original titles for their names > would, too, be much more preferable over making use of any kind of > transcription or transliteration method, IMO. > > Therefore, my proposal is to relax these limitations as much as > possible (or at least somewhat) and to allow some more freedom when it > comes to naming packages and other kinds of items in the store. We > could, of course, still disallow all the main problematic characters, > such as NUL, /, $, ~, space, newline and a few others, but other than > that, I don't see any reason to forbid any of the remaining ones from > being used. > > I'd like to hear your opinions on this and get to know whether this > idea is feasible to implement at all or not, and if not =E2=80=93 why? > > [0] https://issues.guix.gnu.org/64976 > [1] https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/store-ap= i.cc#n58 > [2] https://ra=C5=A1tija.lt/liepa/paslaugos-vartotojams/narsytuvas > [3] https://gitlab.com/guix-media-channels