Re: Farewell to the Change-Id: trailer

>sam. 02 août 2025 at 12:13, Tomas Volf <~@wolfsden.cz> wrote: > Cayetano Santos writes: > >>>ven. 01 août 2025 at 15:02, Maxim Cournoyer wrote: >> >>> Hello, >>> >>> I'm proposing to remove the automatically added Change-Id git tra

Re: Farewell to the Change-Id: trailer

>ven. 01 août 2025 at 15:02, Maxim Cournoyer wrote: > Hello, > > I'm proposing to remove the automatically added Change-Id git trailers > to our commit messages, for reasons explained in the commit message of > the commit at . In a > nutshell, Codeberg

irc and potential users

In the same page, there is a link to Gamja. Here, users need to enter a nick by hand. Far from perfect, but this is something. Should we maybe link to Gamja directly ? Best, -- Cayetano Santos . gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682 key: meta.sr.ht/~csantosb.pgp sig

Re: Committers approving pull requests

>lun. 21 juil. 2025 at 23:57, "nomike (they/them)" wrote: > Hi > > On 17.07.25 11:52, Cayetano Santos wrote: >> So, ... what is the conclusion regarding approvals ? >> Do we have a policy about this ? I feel like approved changes get >> committers a

Re: Committers approving pull requests

> I have recently been surprised by committers approving pull requests, > wondering why they did not instead push them themselves. It might make > sense when reacting to other committers (we never discussed whether it > would be more polite to let committers push their own commits, or okay > to pu

Re: Emacs Org documentation

>lun. 07 juil. 2025 at 09:01, pinoaffe wrote: > I recently found out that ox-texinfo exists - what do y'all think about > adding a build phase to convert Org documentation files into Texinfo > files, so they can be uniformly accessed? Well, this is what we usually do, see emacs-show-font packag

Re: Committers approving pull requests

or a low ratio of regular committers / pr, let’s not overcharge them; if this number increases, adopt some kind of policy where before committing, someone’s else must have approved the changes before. -- 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: Codeberg migration check list

> - [ ] `%default-channel-url' changed to git.guix.gnu.org: > https://issues.guix.gnu.org/78547 > - [ ] URL changed to git.guix.gnu.org in Cuirass config (maintenance.git) > Please let me know if you spot any omission or problem, or if you’d like > to help out on some of these! Not directly rel

Re: Why are the git submodules not being cloned?

>ven. 02 mai 2025 at 04:12, "nomike (they/them)" wrote: > Hi! > > I'm trying to package a more recent nightly version of openscad[0] with this > package > definition[1]. > > Even though I use =(recursive? #t)= within =(git-reference)=, the submodule > directories in > the build directory (e.g.

Re: Patched version of broken offlineimap3

>jeu. 01 mai 2025 at 12:30, Andreas Enge wrote: > Hello, > > Am Wed, Apr 23, 2025 at 11:02:08PM +0200 schrieb Noé Lopez: >> As far as I know its accepted that packages are updated to versions >> beyond their current release in Guix. Especially if they don’t work >> without that version. See “inf

Re: emacs-team needs you 👉 to properly test your packages

>mer. 30 avril 2025 at 21:23, Liliana Marie Prikler >wrote: > For context, are these all packages that still fail to build? If so, I > think it'd be time for a merge request unless someone wants to tackle > emms first. No, this is not it all. I had to stop before my old laptop burns. Let me

Re: Patched version of broken offlineimap3

>mer. 23 avril 2025 at 11:56, Gary Johnson wrote: > Hi Guix, > > The offlineimap3 package is broken in the current version of Guix due > to a longstanding bug in offlineimap3 that makes it incompatible with > Python 3.11 (which is now the default python version in Guix). A patch upgrading to la

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

Hi Ludo, Thanks for the recall. I thinks it is worth having a later and careful reading on the proposal before the end of this period, considering its relevance. A few remarks (disclaimer: low profile contributor, here). First and most important, to me what really matters here is making

Re: Search alerts and Watch issue on mumi

>ven. 04 avril 2025 at 20:07, Arun Isaac wrote: > Hi all, > > mumi has two exciting new features—search alerts and watch issue. Now, > you can subscribe to any issue or search query using your feed reader. Love it. Really. Thanks a lot for all those improvements to mumi, which is getting more a

Re: Applying Patches for Review

>sam. 29 mars 2025 at 16:10, Noé Lopez wrote: > Gabriel Santos writes: > Another way I know of is to download the mailbox from the issue’s > debbugs page and apply it with “git am”. As an alternative, you have https://yhetil.org/guix-patches/ From here, you can download the full thread a

Re: Per-user Guix installations

Hi Ludo, Konrad, >Wed 02 Apr 2025 at 17:11, Ludovic Courtès wrote: > Thoughts? The lower the number of dependencies, the better, within reasonable. In the ideal case, if a single/group of users connected to a computing cluster was able to benefit from all guix goodies, without expecting too m

Re: Visiting a future of GNU? (was Re: Please don't leave GNU)

>Wed 02 Apr 2025 at 10:03, Simon Tournier wrote: > Hi Caleb, > > On Fri, 28 Mar 2025 at 18:26, Caleb Herbert wrote: > >> I use Guix primarily because of its commitment to user freedom and its >> united front with the GNU Project. > > Cool! As many of us. :-) At this point, I cannot avoid poin

Re: “Build daemon drops its privileges” 👈 blog post

>Tue 01 Apr 2025 at 08:33, Ludovic Courtès wrote: > But yes, providing a script for those who want to migrate would be nice. Being Guix a rolling release (disclaimer, I’m an Archer), manual intervention with help of instructions on how to would be fine for most users.

Re: “Build daemon drops its privileges” 👈 blog post

>lun. 31 mars 2025 at 14:14, Ludovic Courtès wrote: > Feedback welcome! Loved it, great work, really useful. One comment in paragraph about "Migrating an existing installation ...", which sounds bad. It suggest that users are at their own (unless this is documented somewhere ?); "we may provid

Re: Please don't leave GNU

>dim. 30 mars 2025 at 20:51, Tomas Volf <~@wolfsden.cz> wrote: > I decided to use Archlinux for comparison (Alpine seemed unfair ^_^). I > am not sure how to do `guix size' with pacman, You may have a look here, https://wiki.archlinux.org/title/Pacman/Tips_and_tricks section 1.1.3 signa

Re: './pre-inst-env guix build xxx' can not find packages in other channels.

>Fri 28 Mar 2025 at 08:54, Feng Shu wrote: > my question is: how to let pre-inst-env work well with my channel > setting, and no need to use -L in every command. Are you aware of GUIX_PACKAGE_PATH ? signature.asc Description: PGP signature

Re: Debbugs changes on #guix

> Please let me know what you think! Really useful, thanks ! However, to avoid a noisy feeling, what about removing repeating text ? I’m thinking about "Bug in" and "https://issues.guix.gnu.org/";. So, for example Bug in guix changed: "Pulseview with modular qt" https://issues.guix.gnu.org/2864

Re: Automatic tagging of unanswered issues in mumi

>lun. 17 mars 2025 at 14:05, Arun Isaac wrote: >> I had in mind both, "tag:unanswered" and "tag:team-whatever", which >> don’t appear in the help page. > > Thanks, I have added these as examples in > https://issues.guix.gnu.org/help#search Great ! Mumi is getting better and better ... one last

Re: Automatic tagging of unanswered issues in mumi

>ven. 14 mars 2025 at 14:02, Arun Isaac wrote: > Hi Cayetano, > >> I’m just wondering if the help page up to date with most recent hints. >> >> https://issues.guix.gnu.org/help > > The help page is technically up-to-date since I haven't changed that > interface. However, the help page could

Re: Contribute to Guix

r example: guix refresh -s module:web-browsers You may try to update nyxt or qutebrowser. > How can I send a patch for it to be updated or is there a reason why it wasnt > included in > more updated version? All is explained in the "Contributing" chapter of the manual. -- Caye

Re: Contribute to Guix

member there is #guix irc. Most important, get fun ! -- 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: Automatic tagging of unanswered issues in mumi

> mumi now automatically tags unanswered issues. Thanks for the latest improvements ! Mumi really helps a lot. I’m just wondering if the help page up to date with most recent hints. https://issues.guix.gnu.org/help C. signature.asc Description: PGP signature

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

erg during the incoming years. No one knows what the future will provide, but I think, from my perspective, that a complete demo exercise might be helpful to this respect before going any further. Thanks again, -- Cayetano Santos . gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682

Re: mumi CLI now supports tagging

>dim. 23 févr. 2025 at 13:02, Arun Isaac wrote: >> Except that the "Guix QA review form submission:" part is missing. > > I'm not sure which form you are referring to. Could you elaborate? When reviewing a patch [1] ( Patch review overview ), typically, one replies by email to cont...@debbugs.g

Re: mumi CLI now supports tagging

>sam. 22 févr. 2025 at 23:28, Arun Isaac wrote: > Hi, > > With the latest mumi 0.5.0, the mumi CLI now supports tagging and easy > composition[1] of command emails to the debbugs control server. Great news ! Thanks a lot for your time and efforts, mumi is a must have when contributing to guix.

Re: renaming of fpga.scm module

complete if I forget something on the way. -- 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: renaming of fpga.scm module

>lun. 17 févr. 2025 at 21:03, Maxim Cournoyer wrote: > Hi Cayetano, > > Andreas Enge writes: > >> Am Sun, Feb 09, 2025 at 10:11:17AM +0100 schrieb Cayetano Santos: >>> Two options at this point: we keep on happily dropping loosely related >>> packages

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

rg is expected somehow to simplify the review process: providing reviewers (and contributors!) automatised reports about building, linting, styling, checking dependencies, etc., so that they’ll just need to accept the contribution, or not, effectively freeing them from repetitive, high time consuming tasks.

Re: renaming of fpga.scm module

that a problem, after all ?); or we create a new team (if there is interest on participating) to organise and maintain these packages (I volunteer). -- Cayetano Santos . gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682 key: meta.sr.ht/~csantosb.pgp signature.asc Description: PGP signature

renaming of fpga.scm module

, renaming fpga to electronics would make guix compatible with guix-science, where we follow this criteria. Regards, -- 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: [GCD] Migrating repositories, issues, and patches to Codeberg

if it > affects us (or others). Not only. The question about how to economically participate on hardware maintenance needs to be considered, specially, if we plan to make an important use of it. -- 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: [GCD] Migrating repositories, issues, and patches to Codeberg

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

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

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: [GCD] Migrating repositories, issues, and patches to Codeberg

Just for the record, and as for Sourcehut maintainers, "sr.ht is mostly hosted in the Netherlands, with a backup site in the US" -- Cayetano Santos GnuPG Key: https://meta.sr.ht/~csantosb.pgp FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682 signature.asc Descri

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

onsider current one as insufficient. Which brings the question about the new tooling (see previous mumi related exchange). -- Cayetano Santos GnuPG Key: https://meta.sr.ht/~csantosb.pgp FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682 signature.asc Description: PGP signature

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

change improves current situation so as to compensate for the lack of flexibility it imposes. -- Cayetano Santos GnuPG Key: https://meta.sr.ht/~csantosb.pgp FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682 signature.asc Description: PGP signature

Re: mirrors of main guix repository at savannah

>mer. 18 déc. 2024 at 06:49, Felix Lechner wrote: > Hi Cayetano, > > On Wed, Dec 18 2024, Cayetano Santos wrote: > >> (more or less) official mirrors for main guix repo at savannah ? > > I maintain a lazy mirror on Codeberg. [1] The effort is manual because > Codeb

mirrors of main guix repository at savannah

remotely using ci jobs. When the pull stage fails for any reason, the image breaks (hopefully) until next try, which is annoying. Pulling from the ci service itself should be way more stable. I’m sure redundancy must be useful in other contexts. Thanks, -- Cayetano Santos GnuPG Key: https

Re: GNU Manuals in Info/HTML format via Guix?

a dedicated guix channel, external but complementary to guix upstream itself, to distribute manuals. This would about any additional overload on guix maintenance tasks. -- Cayetano Santos GnuPG Key: https://meta.sr.ht/~csantosb.pgp FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF

Re: bug#74715: Request for merging "python-team" branch

>dim. 15 déc. 2024 at 17:53, "Ian Eure" wrote: > Would it be helpful to open a bug about this? I confirm, this line (inputs (list python-setuptools python-wheel)) fixes the issue for me. However, ‘guix lint’ complaints about python-setuptools not necessary. -- Cayetano

Re: On the quest for a new release model

le release is" So, what exactly is a packager of guix expected to package, from guix point of view ? -- Cayetano Santos GnuPG Key: https://meta.sr.ht/~csantosb.pgp FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682 signature.asc Description: PGP signature

Re: On the quest for a new release model

Once they fall into the rabbit hole, they’ll pull substitutes from channels. But we need releases, first. -- Cayetano Santos GnuPG Key: https://meta.sr.ht/~csantosb.pgp FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682 signature.asc Description: PGP signature

Re: On the quest for a new release model

do a `python pull`, `firefox pull` or `guix pull`. It comes to the same for them: they won’t understand. Once they get used to use guix daily, they’ll care about pulls, channels or asking support for guix on the cluster. -- Cayetano Santos GnuPG Key: https://meta.sr.ht/~csantosb.pgp FingerPr

On the quest for a new release model (was: Discussion notes on releases and branches)

audience (foreign first, system then). Releases are a real requirement to that goal. Best, [1] https://semver.org/ [2] https://nvie.com/posts/a-successful-git-branching-model/ -- Cayetano Santos GnuPG Key: https://meta.sr.ht/~csantosb.pgp FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F

Re: emacs-git-email: Guix policy for dealing with abandoned packages with active forks

>jeu. 07 nov. 2024 at 10:48, Suhail Singh wrote: > Cayetano Santos writes: > >>>> To note that this is a completely different beast compared to previous >>>> package (repo, version and mantainer). >>> >>> Yes. Please let me know in case the

Re: emacs packages and elpa

>dim. 31 déc. 2023 at 13:07, Nicolas Goaziou wrote: > Hello, > > Cayetano Santos writes: > >> We distribute emacs packages from gnu/elpa by downloading .tar files >> from there: I’m thinking about emacs-ggtags. >> >> My first concern is, what em

emacs packages and elpa

Hello Guix, We distribute emacs packages from gnu/elpa by downloading .tar files from there: I’m thinking about emacs-ggtags. My first concern is, what emacs-ggtags 0.9.0 corresponds to exactly ? There is no 0.9.0 tag in upstream github reposotory, and, if I understand it correctly, e

[emacs]: snapshots against latest versions

Hi Guix, Following a recent patch to an snapshot of an emacs package (emacs-mastodon), where latest stable (tagged) release dates back from a long time, the question of whether to send patches for non stable (tagged) versions is pertinent or not. Of course, the answer is clear: we onl

Re: Emacs next variants

>ven. 10 mars 2023 at 22:44, Andrew Tropin wrote: > [[PGP Signed Part:Undecided]] > On 2023-03-10 19:24, Cayetano Santos wrote: > >>>ven. 10 mars 2023 at 19:14, Simon Tournier wrote: >> >>> Hi, >>> >>> On Fri, 10 Mar 2023 at 17:59, Joh

Re: Emacs next variants

>ven. 10 mars 2023 at 19:14, Simon Tournier wrote: > Hi, > > On Fri, 10 Mar 2023 at 17:59, John Kehayias > wrote: > >> During this discussion some changes were made to this inheritance structure >> in >> >>

Re: Emacs next variants

>ven. 10 mars 2023 at 13:07, Simon Tournier wrote: > Note that emacs-next-tree-sitter is not from the 29 branch (emacs-next) > but from the 30 branch. Therefore, it would mean emacs-next-pgtk also > be an Emacs 30 version. I do not use them so I have not opinion. > > And why not split the cha

Emacs next variants

Hi guix, As for today, the inheritance of emacs, master branch, variants is as follows (emacs-next-tree-sitter (emacs-next-gtk (emacs-next (emacs Having tree-sitter is really useful, but optional, and doesn’t produce any harm to users. They may opt to use it, or not. This is

Re: emacs packaging: do we need to pull existing dependencies ?

>> Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4, >> which is not specified in the package definition, meaning we always >> pull the latest available. Do we have to, provided that emacs >> releases with org? Maybe there is already a clear rule about this >> topic, but to me thi

emacs packaging: do we need to pull existing dependencies ?

Hello Guix, I’m referring here to the way we handle propagated-inputs in package definitions, when dependencies are already present in the latest stable emacs we provide (28.2 as for today.) Think for example on all org-packages which depend on (and whose package definition declare as

Emacs packaging: do we need to pull existing dependencies ?

Hello Guix, I’m referring here to the way we handle propagated-inputs in package definitions, when dependencies are already present in the latest stable emacs we provide (28.2 as for today). Think for example on all org-packages which depend on (and whose package definition declare as

Emacs packaging: do we need to pull existing dependencies ?

Hello Guix, I’m referring here to the way we handle propagated-inputs in package definitions, when dependencies are already present in the latest stable emacs we provide (28.2 as for today.) Think for example on all org-packages which depend on (and whose package definition declare as