Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)
Hi Felix, Felix Lechner writes: > I do not suffer from the issue described here but rewrote the bootloader > code locally for more flexibility (and may be able to contribute > it). Could we simply move the reference to keyboard-layout-config here > up by a few lines? [1] We could move it up and that would solve it for people not using encrypted /boot I believe. However, for people using encrypted /boot, the keymap would never be loaded instead of loaded after unlocking the volume. The solution for that is to embed the keymap in the GRUB image, so that it can always be found. I believe we don't use grub-mkimage directly for the efi case for now, which is the command we want to use to be able to include arbitrary files in the image, hence my comment about the code needing some refactoring. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
Hi Felix, Felix Lechner writes: > Could a modified version of Debbugs group submissions by Message-IDs > instead of bug numbers? Would it allow subsequent emails to be sent > before the initial message was acknowledged? To me, an ideal solution would be a service that 1) Doesn't modify any incoming mail; 2) Provides a way to look-up the bugs related to a thread and their status, preferably using Message-ID, so that it can be used in conjunction with other mail-based tools without disturbing them. Your proposed modification would be a first step in that direction, but would still not solve 1 and 2 perfectly. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
On Mon, Feb 12 2024, Josselin Poiret wrote: > Hi Felix, > > Felix Lechner writes: > >> Could a modified version of Debbugs group submissions by Message-IDs >> instead of bug numbers? Would it allow subsequent emails to be sent >> before the initial message was acknowledged? > > To me, an ideal solution would be a service that > > 1) Doesn't modify any incoming mail; > 2) Provides a way to look-up the bugs related to a thread and their > status, preferably using Message-ID, so that it can be used in > conjunction with other mail-based tools without disturbing them. > > Your proposed modification would be a first step in that direction, but > would still not solve 1 and 2 perfectly. > > Best, We could use a new email header (say X-GNU-PR-Bug) for the grouping, whose value would be a unique random id, generated (automatically) by the patchset sender? We'd have the guarantee that two different bugs won't have the same X-GNU-PR-Bug value, and we'd be able to send the patches in a more automated way. Clément
Re: bug#63775: git describe on current master says: v1.3.0-38775-g6192acf8b7
Hi, On sam., 03 févr. 2024 at 19:43, Giovanni Biscuolo wrote: > This is a git bug, not an issue with our repo, and for this reason (I > hope) I'm closing this bug; please see below. Here the explanation of the bug of “git describe”: https://lore.kernel.org/git/20191008123156.gg11...@szeder.dev/ $ git describe d1a251a1fa v2.23.0-135-gd1a251a1fa $ git log --oneline v2.23.0..d1a251a1fa | wc -l 59 Uh-oh, 59 != 135. This is happening because: - Git is too fast ;) and the committer date has a one second granularity, so scripts can easily create subsequent commits with the same committer date. Case in point are the two subsequent merge commits f3c19f85c5 and 4a3ed2bec6 at the bottom of this simplified history snippet (kind of a hand-edited 'git log --graph --format="%h %cd %s"'): * d1a251a1fa 2019-09-09 12:26:36 -0700 Merge branch 'en/checkout-mismerge-fix' |\ * | ... a big chunk of history simplified away ... | * acb7da05ac 2019-08-16 09:58:00 -0700 checkout: remove duplicate code * | a5e4be2f68 2019-04-25 16:41:15 +0900 Merge branch 'ab/commit-graph-fixes' * | f3c19f85c5 2019-04-25 16:41:14 +0900 Merge branch 'ab/gc-reflog' |/ * 4a3ed2bec6 2019-04-25 16:41:14 +0900 Merge branch 'nd/checkout-m' - 'git describe' implements its own history traversal: it iterates over all parents of a commit, adds any yet unseen parents to a commit list ordered by date, and then continues with the first, i.e. most recent commit from that list. While doing so it uses several bits in 'commit->object.flags' to track reachability information from several candidate tags at once, and copies these flags from each commit to its parents; this is important to compute the correct number of additional commits. Another important thing is the implementation detail that commit_list_insert_by_date() inserts a new commit after all other commits with the same date that are already in the list. Thanks Giovanni for pointing this out. Cheers, simon
Re: Guix Days: Patch flow discussion
Hi Josselin, On Mon, Feb 12 2024, Josselin Poiret wrote: > 1) Doesn't modify any incoming mail; What if, in addition, Debbugs were to publish bug reports and their comments via public-inbox? > 2) Provides a way to look-up the bugs related to a thread and their > status, preferably using Message-ID What if those bug reports were available for your consumption via IMAP folders or NNTP news groups whose idenfier is the initial Message-Id? Kind regards Felix
Google Season of Docs 2024
Hi, ( It is when my plate is full that I add more in. :-) ) Google is announcing the Season of Docs. Somehow, it is similar of Google Summer of Code but for… wait for it… documentation! https://opensource.googleblog.com/2024/02/announcing-google-season-of-docs-2024.html I would like that the Guix project applies as an Organization. Hence my message. Before jumping in the boring paperwork, the first questions are: 1. Who does volunteer for being potential mentor? 2. Would one of you readers be interested by being technical writer? 3. Any for improving the documentation? Well, shoot any ideas for #3. It will help in all cases. :-) It can range from a one line idea to more elaborated idea; as shown here [1, 2, 3]. Depending on the feedback, I will create a LibrePlanet webpage or else and go further in the process. :-) Last, keep in mind the deadline is less than 10 days from now. 1: https://developers.google.com/season-of-docs/docs/project-ideas 2: https://developers.google.com/season-of-docs/docs/case-study-example 3: https://developers.google.com/season-of-docs/docs/2022/participants Cheers, simon
Re: Google Season of Docs 2024
> 3. Any for improving the documentation? just a general wish: much less prose and much more structure, please. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “There is no coming to consciousness without pain. People will do anything, no matter how absurd, in order to avoid facing their own Soul. One does not become enlightened by imagining figures of light, but by making the darkness conscious. The latter procedure, however, is disagreeable and therefore not popular.” — Carl Jung (1875–1961), 'Alchemical Studies' (1967)
Re: Gaming on Guix
February 11, 2024 at 6:26 AM, "Tobias Alexandra Platen" wrote: ••• > > I am a libre game developer and I plan to package my game that I am > currently working on for Guix. On the long term I also want to make a > scalable distribution service that one can self host and which allows > paying for games using GNU Taler. Once the user has payed they can get > substitutes, if they don't want to pay, they still have the freedom > to build the game from source. I propose the name GNUtris for this > service. > > First I will make a home page using haunt for my game. Then I start > packaging ist dependencies, starting with libsurvive, which is needed > to use the Valve Index. Then I package the rest of the software, > needed to run the game. Finally I setup a sales/crowdfunding page, > this will be the harded part of my project. I heard that Taler will > soon go into production in the Euro zone. > > PS: I try to avoid Steam, Nonguix and the Guix Gaming Channels > I am definitely gave for chipping in for your crowdfunding campaign for this. I think we should find a pay to pay libre developers, and this sounds like a great idea! Also, you can also license your game source code as GPL, but license the game assets as proprietary. This does not violate the GPL. Joshua
Re: Google Season of Docs 2024
> 3. Any for improving the documentation? Example snippets for every function. Basically like https://clojuredocs.org/ but for Guile / Guix. Thanks in advance.
Re: Intermediate abstraction of system service configuration
On Tue, Feb 06 2024, Dale Mellor wrote: >Agree that it would have repercussions throughout the package > ecosystem. I would have thought that it would make things easier. You > could argue that you don't benefit from the Guile syntax checker, but > at the end of the day you don't find out you've made a mistake until > you try to run `guix system reconfigure` anyway. It might make things "easier" in one sense, but loosening the constraints on one thing often makes some other part harder. In particular, because of service extensions you can't rely on the whole configuration being written in the same place, so we would need some sort of merging logic for free-form configurations. This merging logic would have to be service specific, but would presumably need to perform its own shape checking (for good error messages, if nothing else). Presumably this would require some sort of type definitions, similar to what our current configuration system requires (maybe with less boilerplate). I'm sure it's possible to write a system that uses these things, and there has been some idea of doing this in the past for nginx specifically[1], but I'm not yet convinced it would actually be easier across the board. Having used Nix (which has more free-form configuration), I'm not sure that it's better than what Guix has. I'm happy to be convinced, though, if you'd like to put together an implementation. Maybe you could start with a single service (nginx) and see how it comes together. I'm not a committer, so convincing me doesn't get things into Guix, but presumably if you can convince me you can convince a committer as well. Carlo [1]: https://issues.guix.gnu.org/37388
