Questions on updating `aerc` and its Go dependency
Hi Guix, I’m working on updating `aerc` to 0.20.1. On the package itself I: - bumped the version - removed the patch - fixed the way the `notmuch` flaged is passed but I also had to update one of its dependency: `go-git-sr-ht-rjarry-go-opt`. It’s a major update to `2.0.1` so I created a new `go-git-sr-ht-rjarry-go-opt-v2` inheriting from `go-git-sr-ht-rjarry-go-opt`… but realized that `go-git-sr-ht-rjarry-go-opt` was only used by `aerc`. Is it any use to create a new package? Should I just update the existing one? Should I rename it? Create a new one? … so many questions!! 😱 Any advice welcome! -- Tanguy
Re: Cgit disabled on Savannah
Leo Famulari aliandika: > On Tue, Jan 21, 2025 at 09:01:33PM +0300, Munyoki Kilyungi wrote: >> --8<---cut here---start->8--- >> ╭─munyoki@saitama ~/FOSS/guix ‹master› >> ╰─➤ git pull >> 141 ↵ >> fatal: unable to access 'https://git.savannah.gnu.org/git/guix.git/': Failed >> to connect to git.savannah.gnu.org port 443 after 133844 ms: Connection >> timed out >> --8<---cut here---end--->8--- >> >> ... times out for me. Is there any agreed upon >> fall-back guix clone to work from? > > Are you still having this problem? > > My understanding is that although cgit (the web interface) has been > disabled on Savannah, the Git server itself is still alive, although > not exactly 100% responsive. Currently works! Just tested it out :) -- (Life is like a pencil that will surely run out, but will leave the beautiful writing of life) (D4F09EB110177E03C28E2FE1F5BBAE1E0392253F (hkp://keys.openpgp.org)) signature.asc Description: PGP signature
Re: [GCD] Migrating repositories, issues, and patches to Codeberg
>mer. 05 févr. 2025 at 12:36, Efraim Flashner wrote: > I packaged codeberg-cli (https://codeberg.org/Aviac/codeberg-cli) and > forgejo-cli (https://codeberg.org/Cyborus/forgejo-cli/) and generated a > token for codeberg-cli to try and test it out. This is great, thanks ! Any plans to share the packages ? It would be great for the community to test alternative tools before moving forward in this thread. -- Cayetano Santos . gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682 key: meta.sr.ht/~csantosb.pgp signature.asc Description: PGP signature
Re: Questions on updating `aerc` and its Go dependency
On Wed, Feb 5, 2025, at 03:05, Tanguy LE CARROUR wrote: > but I also had to update one of its dependency: > `go-git-sr-ht-rjarry-go-opt`. > It’s a major update to `2.0.1` so I created a new > `go-git-sr-ht-rjarry-go-opt-v2` > inheriting from `go-git-sr-ht-rjarry-go-opt`… but realized that > `go-git-sr-ht-rjarry-go-opt` was only used by `aerc`. > > Is it any use to create a new package? Should I just update the existing one? > Should I rename it? Create a new one? … so many questions!! 😱 You should update the existing package. No need to rename it. Treat it like any other library package. It would be more complicated if it had more than one user. Any other questions? :)
Re: [GCD] Migrating repositories, issues, and patches to Codeberg
I've been thinking through how I feel about this for about a week now. On one hand I've found a workflow that works for me for applying patches to trees. Finding the patches is harder; I almost exclusively rely on them being sent to me directly as part of the etc/teams script. When I do go in search of patches I generally check qa.guix.gnu.org to see what's building correctly, and I'll check my local maildir of patches. My local maildir isn't great, all I have is unread is open, read is closed. I have a snippet I use in mutt to flag bugs that are closed and then I can mark them all read. This only works if an email was sent to close the bug, not if it was closed using debbugs.el. I have about 29k emails in my guix-patches directory and about 110k in the archive directory for guix-patches. So to summarize, if a patch is sent to me directly I have a workflow that I've worked out, but otherwise I almost never look at the other patches, and even then I'm not always sure if the patch is already applied or not. I've never really had to use a webui (or Rich HTML Experience™) for shared development previously, so the change is (don't say scary!) not one that I'm looking forward to excitedly. At least it's not Gitlab, which I've regularly had poor experiences with since either because of using icecat or because my browser/GPU was too slow. I packaged codeberg-cli (https://codeberg.org/Aviac/codeberg-cli) and forgejo-cli (https://codeberg.org/Cyborus/forgejo-cli/) and generated a token for codeberg-cli to try and test it out. (ins)efraim@3900XT /tmp$ git clone https://codeberg.org/martianh/fj.el Cloning into 'fj.el'... (ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg --help Codeberg CLI app Usage: berg [OPTIONS] Commands: api API subcommands auth Authentication subcommands configConfig subcommands user User subcommands issue Issue subcommands pull Pull request subcommands label Label subcommands repo Repository subcommands milestone Milestone subcommands notification Notification subcommands completionPrint completion script help Print this message or the help of the given subcommand(s) (ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg pull --help Pull request subcommands Usage: berg pull Commands: list List pull requests create Create a pull request edit Edit pull request view View details of a selected pull request comment Add comment to selected pull request help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg pull view ? Select the desired pull request > #79:main #73:Minor fixes to 'fj-render-body' #27:test PR: dev into main #26:test PR dev into main (ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg pull view > Select the desired pull request #27:test PR: dev into main ┌─┬─┐ │ Pull Request┆ │ │ #222527 ┆ │ ╞═╪═╡ │ Title ┆ test PR: dev into │ │ ┆ main│ ├╌┼╌┤ │ Created ┆ 10.07.2024 (209 │ │ ┆ days ago) │ ├╌┼╌┤ │ Labels ┆ │ ├╌┼╌┤ │ Description ┆ │ └─┴─┘ (ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg pull comment > Select the desired pull request #27:test PR: dev into main ? Open editor to write a comment [(e) to open vim, (enter) to submit] ┌───┐ │ Operation was interrupted by the │ │ user │ └───┘ (ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg notifications error: unrecognized subcommand 'notifications' tip: a similar subcommand exists: 'notification' Usage: berg [OPTIONS] For more information, try '--help'. (ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg notification --help Notification subcommands Usage: berg notification Commands: list view help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg notification list ┌──┐ │ Notification Threads
Re: [GCD] Migrating repositories, issues, and patches to Codeberg
On Wed, Feb 05, 2025 at 11:56:40AM +0100, Cayetano Santos wrote: > > >mer. 05 févr. 2025 at 12:36, Efraim Flashner wrote: > > > I packaged codeberg-cli (https://codeberg.org/Aviac/codeberg-cli) and > > forgejo-cli (https://codeberg.org/Cyborus/forgejo-cli/) and generated a > > token for codeberg-cli to try and test it out. > > This is great, thanks ! Any plans to share the packages ? It would be > great for the community to test alternative tools before moving forward > in this thread. I've pushed them both to master (the packages, not the token). -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
[ennoausber...@me.com: Re: [GCD] Migrating repositories, issues, and patches to Codeberg]
Hello, this must have been directed at guix-devel, but apparently only arrived in my mailbox. So I am forwarding it. Andreas - Weitergeleitete Nachricht von Enrico Schwass - Date: Thu, 30 Jan 2025 10:51:43 +0100 From: Enrico Schwass To: Andreas Enge Subject: Re: [GCD] Migrating repositories, issues, and patches to Codeberg X-Mailer: iPhone Mail (22D63) Hello I find trac https://trac.edgewall.org/ a good gitlab alternative. I am not sure if it ticks all boxes for Guix needs but it might be worth a look. It is easy to setup and run and has a Guix package already. Bye Enno Am 2025/01/30 um 08:37 schrieb Andreas Enge : Hello Tomas, Am Tue, Jan 28, 2025 at 10:41:40PM +0100 schrieb Tomas Volf: From more ideological point of view, I think it is a strict downgrade regarding the entry barrier. The very first thing new contributor needs to do before contributing to GNU Guix is to read Terms of Service document of a third party and agree to it. I took the time to read it, and there are few points I have an issue with: definitely a new barrier to entry is the need to create an account. I just did, and interestingly, at no point in time was I provided with a checkbox to accept and a link to read the ToS. So now I have an account without agreeing to anything. Actually at the bottom of the page there is a link "Terms of Use" under the heading "Legal". I just went through it and found it amazingly light, and containing mainly commonplace assertions. In particular, it does not contain the infamous lines I have seen elsewhere (git*, I think, but forgot which) that I would indemnify the organisation for any legal fees that would arise from my actions, or other essentially unacceptable clauses. It mainly describes under which circumstances codeberg reserves the right to close my account; and there is no reason to believe this would happen following normal work on Guix. So I am fine sticking to these ToS and do not see them as a big blocker for contributors. Nevertheless, we would probably lose bug reports by people who cannot be bothered to create an account just to help Guix. This could be mitigated by the continued existence of the help-guix and guix-devel mailing lists. Andreas - Ende weitergeleitete Nachricht -
OCI provisioning service
Hi Guix, I just sent an updated version of the oci-container-service-type at https://issues.guix.gnu.org/76081 It has all the features of the old service type and additionally it supports OCI network and volume provisioning, it supports both Docker and rootless Podman runtimes and has some Shepherd actions useful for debugging. Please if you are interested let me know your thoughts and feelings about this. Thank you all for your work, giacomo
Re: [GCD] Migrating repositories, issues, and patches to Codeberg
Thanks ! I’ve been playing with them for a while: the experience is, well, to be greatly improved, at a similar level to emacs fj.el. I invite interested people to give them a try, in particular, when one is reluctant to web forges. guix pull && guix install codeberg-cli forgejo-cli berg -V fj version -- Cayetano Santos . gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682 key: meta.sr.ht/~csantosb.pgp signature.asc Description: PGP signature
Understanding #:substitutable? and #55231
Hello, I have been working on trying to set up a booting ZFS-based system with Guix, and am trying to understand the reasons that #55231 (which would help greatly with this, as Kaelyn noted last May) was not merged. Of course, it may simply be lack of reviewer time, which is fine. It did, however, seem that there was some concern expressed regarding the `#:substitutable` flag, and the possibility of redistributing a compiled ZFS kernel module as part of an initrd. My understanding of the issue is that when an initrd is created using the `expression->initrd` function, a call to `computed-file` is made, and the options which are ultimately passed to `gexp->derivation` do not include `#:substitutable? #f`, so a situation is created where, in principle, a compiled ZFS kernel module could be distributed. The concern expressed seemed to be generally one of documentation, in which case I think that the fact that the documentation was changed not to use a non-substitutable module as an example should cover any opposition to the merging of #55231. If the concern is rather that this change makes it easier for someone to accidentally redistribute a compiled ZFS kernel module and commit a copyviol, I struggle to see how this concern is particular enough to #55231 to be a reason not to merge it. It seems to me, at least in principle, that it would be just as simple to commit a copyviol by using, say, the `make-linux-libre` function (which does not appear to set `#:substitutable? #f` on the resulting derivation, unsurprisingly) to build a kernel with the ZFS kernel module built in, and then redistributing that. It seems like the only way to completely remove this possibility would be to make `#:substitutable?` "poisoning", so to speak, in the sense that any derivation taking non-substitutable derivations as inputs would be marked non-substitutable itself. This seems to entirely eliminate the possibility of substituting something which is non-substitutable, but I have no idea if this is practical or even desirable. If the issue is simply that the patch has not been rebased against a new enough version of Guix to be merged, I am happy to do that rebasing. Additionally, please correct me if I have made any incorrect assertions above. Best, Morgan
Re: `map-derivation' is too slow for meaningful usage
Hello, On 10/23/24 18:38, Ludovic Courtès wrote: No idea, but the implementation is likely naïve: I wrote once, tested it on simple cases, but it never got any use beyond that. I went ahead and implemented caching[1] so the procedure is usable for derivations with big dependency bags. It even works for full blown operating system derivations. [1]: https://issues.guix.gnu.org/71941#3 Regards, Sergio.
