From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id YC4xBLL1XGMx9AAAbAwnHQ (envelope-from ) for ; Sat, 29 Oct 2022 11:43:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 6JQ4BLL1XGOPfQAA9RJhRA (envelope-from ) for ; Sat, 29 Oct 2022 11:43:14 +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 EA42225EC1 for ; Sat, 29 Oct 2022 11:43:13 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ooiMT-000260-Pa; Sat, 29 Oct 2022 05:42:41 -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 1ooiMR-00025h-2R for help-guix@gnu.org; Sat, 29 Oct 2022 05:42:39 -0400 Received: from mout-p-101.mailbox.org ([2001:67c:2050:0:465::101]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1ooiMN-00065d-Rg for help-guix@gnu.org; Sat, 29 Oct 2022 05:42:38 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Mzvb66gNCz9sQD; Sat, 29 Oct 2022 11:42:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1667036546; 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=pMvN+igBKNhceRMRj720529QQ6P0EF6ilPcALznfv84=; b=I/3Yq5HZQNkW2e+7zwM6Qj+1/RkZmhnatHALw9Y61KspKxAV+4XqzTQkcFU5hpq/ipbmw8 ozpjW0uEZ0sp9NuY+Ro1Uv2gA9JE940Xg7EZYRsXVXoxgdGuUA9p0AysyimGSGVaStUBKh XkGI904kFKpbuv2NvZXmcVZtCIFpIRiKllKyoDWABoTk9/qH2VStN1g7E2er0qEdMh/Pw5 n80oTIetu1fYAqntUJcMHuhvtIoc4X3Pm8lSZe0LnHlPkSgz+fXslPVDITpwD6U5zW4MPi SOkAIYWO2pMqiEm38/q+5Q2Fjv0mBPpn0L1dTrJp4R3dBXxGoA5eh/yJVv3hwA== Message-ID: <7128f34e-aa48-9afb-59af-e4f69a600c86@mailbox.org> Date: Sat, 29 Oct 2022 09:42:19 +0000 MIME-Version: 1.0 Subject: Re: Package renpy broken? Content-Language: en-US To: Wojtek Kosior Cc: help-guix@gnu.org References: <1b808a95-2a93-b3d1-00a5-4cf458d718c6@mailbox.org> <20221028172912.6806f9e2@koszkonutek-tmp.pl.eu.org> From: Christian Gelinek In-Reply-To: <20221028172912.6806f9e2@koszkonutek-tmp.pl.eu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-MBO-RS-ID: a5b514255babe942955 X-MBO-RS-META: cy4ocjrnbi1dmd4ui9k4qkw4ub7exfu6 Received-SPF: pass client-ip=2001:67c:2050:0:465::101; envelope-from=christian.gelinek@mailbox.org; helo=mout-p-101.mailbox.org X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Help-Guix" Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org X-TUID: mL67/eLDjXSi Hi Wojtek, thanks for your response and the useful links to learn how to patch a package. > Once you grasp a bit of it, you should be able to define your own > variant of the Ren'Py package. One without the bug. That would probably be the easiest fix, but I do wonder about other users of Ren'Py - particularly whoever packaged it first, did they ever get it working for them? > I realize it's probably a bit discouraging to come to a new distro and > find out you need to learn packaging to utilize it. I guess switching distros is always going to cause some friction, so I was partly prepared for that. > Yet, honestly, Guix is a geeky package manager - you can only benefit from its > super-powers once you're yourself Guix geek ¯\_(ツ)_/¯ You're right in that, and it also seems to have some really compelling features that motivated me to switch and which (hopefully) make this learning experience worthwhile. On the other hand, I do like packages which *just work* out of the box, and I feel the declarative approach should generally help with that. As a newcomer I do have the concern that this "geekiness" can also lead to a pile of patches on top of each other (in this case, the patch to remove TFD and then another to make the package work again without it) that I feel would increase the maintenance burden rather than decreasing it beyond the short term. Please tell me if what I said doesn't match the deeper philosophy behind Guix for some reason or another. Looking at my Ren'Py issue, I am wondering whether the cleaner approach would be to package TFD as a separate package (I think zlib counts as a Free Software license) and make it a dependency of Ren'Py, hoping that will fix the issue. Maybe other packages like rust-tinyfiledialogs could benefit from such a package as well (I am wondering how users of that are currently actually using TFD). What are your thoughts? Christian