Re: GUI for Guix

Ricardo Wurmus writes: > Is it *actually* broken? If it is and you can provide information on > how to trigger the broken behavior we might be a step closer to fixing > it. I believe it's unclear how to ensure that it is configured correctly. I.e., I believe the package mostly works when config

Re: GUI for Guix

Ludovic Courtès writes: > The only thing broken for me is completion in shell-mode FWIW, as an alternative, emacs-bash-completion () works quite well for completion in shell-mode. I unintern pcomplete/guix and use it in its stead. -- Suhail

Re: doc: Removing much of Binary Installation

Matt writes: > I wonder if we should have similar concerns about the Debian and > openSUSE packages? FWIW, as an openSUSE Tumbleweed user, I believe Tumbleweed users who don't care if there is an easy way to uninstall Guix would be better served by using =guix-install.sh= as opposed to =zypper=.

Re: doc: Removing much of Binary Installation

Suhail Singh writes: > FWIW, as an openSUSE Tumbleweed user, I believe Tumbleweed users who > don't care if there is an easy way to uninstall Guix would be better > served by using =guix-install.sh= as opposed to =zypper=. Btw, for completeness, on Tumbleweed, the user need

Re: doc: installation: fix ~root confusion (was Re: doc: Removing much of Binary Installation)

Vagrant Cascadian writes: > but "guix pull" does not update the running guix-daemon; Just to be clear, however, if one were to do =sudo -i guix pull= instead, followed by =systemctl restart guix-daemon.service= it /would/ update the running guix-daemon on Debian, correct? Or is that not the cas

Re: Disabling authentication checks for tests in local Guix checkouts

Ludovic Courtès writes: > I’m not sure how to integrate it though: in the general case, we > probably want to keep authentication enabled by default, but how to > allow users to easily disable it when using a personal checkout? Could you please elaborate on what the challenge is? Is the challen

Re: Disabling authentication checks for tests in local Guix checkouts

Ludovic Courtès writes: > The challenge is in determining that Guix is running from a local > checkout. Now that I think about it, it’s not that hard: ./pre-inst-env > sets ‘GUIX_UNINSTALLED’. So we could do: > > #:authenticate? (not (getenv "GUIX_UNINSTALLED")) > > Problem is that an attacke

Re: Reducing "You found a bug" reports

Simon Tournier writes: > More than often, the issue is transient, hard if not impossible to > reproduce and thus hard to analyze. Even, when it happens for me, > sometimes I say ok let try to collect some information for helping in > debugging that but then just running again “guix pull” makes i

Re: Request for assistance maintaining LibreWolf

Ian Eure writes: > The initial patch to update the version to 127.x was submitted on June > 29th; updated to 128.x on July 17th; and I’ll be sending the patch > updating it to 129.x later today, after I’ve finished building and > testing it. Thank you for your continued commitment to this despit

Re: Request for assistance maintaining LibreWolf

Ian Eure writes: > Guix seems committed to using an email-based workflow, so I think it > makes a lot of sense to look at how Linux does it. It’s the most > successful project in the world to use email-based development. I believe, perhaps, the biggest issue with Guix is a diffusion of responsi

Re: Global modification of #:make-flags

Sarthak Shah writes: > https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html > > Unfortunately, it hasn't been merged into the main branch yet, however > you should be able to make everything use -Os with the patch. The blog doesn't mention a related debbugs issue. I

Re: Global modification of #:make-flags

Sarthak Shah writes: > I think starting a debbugs issue could be a good idea once everyone's > onboard with getting this patch merged! I'm not sure I agree that consensus has to be a pre-requisite for creating an issue. > Right now, from what I gather, there are some more important conversation

Re: Global modification of #:make-flags

Sarthak Shah writes: > From my understanding, debbugs issues are meant for technical features > or issues pending implementation, while guix-devel threads are meant > for discussions surrounding Guix and possible features. I am no authority on the matter, so please take what I say with a grain o

Re: Simplify contribution by using user-friendly bug tracker and git interface

Jan Wielkiewicz writes: > The issue that needs to be addressed however is the documentation, this > page to be precise: > https://guix.gnu.org/en/manual/devel/en/html_node/Sending-a-Patch-Series.html > I propose turning it into numbered list of things a contributors needs > to do in order to suc

Re: toward a plan? (was Re: Reducing "You found a bug" reports)

Simon Tournier writes: > IMHO, the next actions are: > > a) Replace this message: > > (message (format #f "You found a bug: the program '~a' > failed to compute the derivation for Guix (version: ~s; system: ~s; > host version: ~s; pull-version: ~s). > Please report the COMP

Re: Are Guix-generated Docker images reproducible?

Konrad Hinsen writes: > Suppose you do > > guix time-machine --channels=channels.scm -- \ > pack --format=docker --manifest=manifest.scm > > You keep a copy of channels.scm and manifest.scm, and run the same > command a few months (and "guix pull"s) later, can you expect to get the >

Re: Are Guix-generated Docker images reproducible?

Konrad Hinsen writes: > As you may have guessed, the reason for my question was that I > encountered a non-reproducible Docker image build. And as both of you > point out, the packages entering into the images must be > reproducible. Right, that's necessary, but as you observed, not sufficient.

Re: Clarification regd. native-search-paths and search-paths

Hi Felix, Felix Lechner writes: >> does use here mean being an "input" to a package? > > Yes, precisely. Or being used in a profile. I see. Thank you. >> At least for certain variables such as $SSL_CERT_DIR and $SSL_CERT_FILE >> they only have the desired effect when added to native-search-p

Re: Clarification regd. native-search-paths and search-paths

Felix Lechner writes: >> Does "used" above refer to runtime usage? > > It refers to any use of the "python" package. Since I am trying to understand what constitutes "use", could you please give examples? For instance does use here mean being an "input" to a package? Something more/less/else?

Clarification regd. native-search-paths and search-paths

Hello Guix, Per the manual: #+caption: [[info:guix#Search Paths][guix#Search Paths]] #+begin_quote What this ‘native-search-paths’ field says is that, when the ‘python’ package is used, the ‘GUIX_PYTHONPATH’ environment variable must be defined to include all the ‘lib/python/3.9/site-packag

Re: Clarification regd. native-search-paths and search-paths

Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > All of it is in the Guix source code, however, which is > public. I don't have time to look into it for you right now, but I bet > you and I both would learn a lot! At least in my case, being able to find thi

Language-specific guides for using "guix shell" (was: [bug#72925] [PATCH v3] adding jpm package)

Moving the discussion to guix-devel. "jgart" writes: > what do people think of having language specific guides for using > `guix shell` with particular programming languages? > > not unlike this Nix guide that shows how to use Python in a `nix > shell` to develop on a flask application: > > http

Re: Guix (and Guile's) promise, and how to (hopefully) get there

Ludovic Courtès writes: >> Specifically, the bulk of patch submissions in Guix deal with packages. >> Barring some core packages, perhaps Guix would be better served by >> splitting other packages into a separate channel. The organization and >> management of said channel could be optimized for

Re: Guix (and Guile's) promise, and how to (hopefully) get there

Efraim Flashner writes: > The problem is RMS. The incident Juliana is referring to is when he > appointed himself back onto the board of the FSF a few years ago. Thank you for clarifying. > To phrase it diplomatically, it is not his Free Software positions that > give people pause. I will not

Re: Guix (and Guile's) promise, and how to (hopefully) get there

"Thompson, David" writes: > Changing GNU/FSF from the inside has been a losing strategy for at > least a decade, as a conservative estimate. Nothing has meaningfully > changed for the better and the situation continues to deteriorate both > socially and infrastructurally. Since I am unaware, for

Re: Guix (and Guile's) promise, and how to (hopefully) get there

Christine Lemmer-Webber writes: > That patches aren't being reviewed and aren't making it in. Alas. We have ~45 authorized contributors. Based on the manner in which these contributors were added, I believe they have reasonable trustworthiness to uphold the goals of Guix. However, I do not be

Re: Why "update substitutes?"

Tobias Geerinckx-Rice writes: >>"Fetching list of available substitutes" would be clearer, IMHO. > > Less accurate though. We never care about or download a complete list > of available substitutes. To be fair it didn't say "the list" nor "complete list". Regardless, would "updating list of av

Re: Forge and build automation

Ludovic Courtès writes: >> WIth 29,000+ packages the nature of the project has changed from >> adding new software to managing updates (what fraction of new packages >> are rust or python dependencies?). > > … that’s the crux of the problem. What works for our little channels > mentioned above i

Re: Why "update substitutes?"

Ludovic Courtès writes: > The “updating substitutes” bit corresponds to making pipelined GET > requests for narinfos¹ to figure out upfront what’s going to be > available as substitutes and what will have to be built. "Fetching list of available substitutes" would be clearer, IMHO. -- Suhail

Re: Including code in a non-Guile language into Guix

Daniel Littlewood writes: > guix pull ("38k new commits"): 21m45s > guix pull immediately after: 2m25s > guix shell emacs (fresh): 1m49s > ... > > nix-channel --update: 0m23s > nix shell -p emacs (fresh): 0m24s Those are some interesting comparisons. Is the reason guix pull takes so long as com

Re: Rebuilding a package after removing a build step

Konrad Hinsen writes: > Unfortunately, when there are several packages with identical name and > version number in two channels, Guix silently chooses one of them. Ah, I had wondered what it did. Thank you for reporting. > It would probably be more useful to emit a warning. Agreed. On a rela

Re: Rebuilding a package after removing a build step

Vagrant Cascadian writes: > Rather than picking an arbitrary incremental number, I have in the past > used something based on the results from git describe... e.g. in my > current checkout of guix: > > $ git describe --match=v1.4'*' > v1.4.0-142685-gfc059c66cf > > e.g. 142685 commits past v1.

Re: Rebuilding a package after removing a build step

Konrad Hinsen writes: >> On a related note, when multiple channels are enabled, is there a way to >> specify a specific package from a particular channel? > > Yes, using the -e option followed by the Guile module name. See > > https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package

emacs-git-email: Guix policy for dealing with abandoned packages with active forks (was: [bug#74231] QA review for 74231)

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 commit message needs to be revised >> (it already does note that we are changing the referenced fork). The >> p

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

Hello Guix, Below is a summary of the situation that we're seeking guidance on. Please ignore this message, if already aware of context. Suhail Singh writes: >> I’d say, better bring the question to guix-devel, as this has large >> implications. There must be a policy already

Re: Blog post: Guix/Hurd on Real Iron

Janneke Nieuwenhuizen writes: > I conisdered this a well known fact; do you think we should mention this > (more explicitly) in the blog post? If so, do you have a suggestion? For what anecdotal evidence is worth, I didn't know about Debian GNU/Hurd till this email thread. -- Suhail

Re: Guix online meetup (Friday) and talk by Christine Lemmer-Webber

Steve George writes: > 1. If you want YOUR patches reviewed (or you see easy ones) > Please give them a usertag guix and patch-hackers-review-list [1]. > > ... > > [1] > https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=patch-review-hackers-list;status=open;users=guix Steve, is it patch-hacker

Re: Extend channel-build-system?

Nicolas Graves writes: > This is because the current channel-builds-system is only able to > build a guix channel, rather than any channel. Perhaps this is obvious to others, but for the benefit of others (such as myself), could you please share some specifics? -- Suhail

Re: New committer

Ian Eure writes: > I’ve applied for, and received, my commit bit! Congratulations! -- Suhail

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

Richard Stallman writes: > That is so much simpler than what Guix has to do that using Guix for > this would be a quick and dirty hack. There's no denying that using Guix isn't necessary. However, to be clear, Guix does already distribute Info manuals (standalone and otherwise) today. While no

Re: Extend channel-build-system?

Nicolas Graves writes: > I'm at peace without an extension of the build-system, but we should > probably at least make it more visible in the manual and doctrings > that this is only for a Guix channel and cannot be user to build any > channel you found online. I probably would've wasted some ti

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

Thank you for taking the time to respond. Ludovic Courtès writes: > even though I’m currently mixing ‘fj.el’ and the dreaded web > interface. Out of curiosity, could you please briefly mention what you're using each for as of now? With the understanding that it's not meant as a recommendation,

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

Ludovic Courtès writes: > This is more or less what some proposed at the Guix Days: starting with > a “sandbox” where interested committers and some contributors (we’d need > to figure out to not make it wide open, probably) could test the > workflow and tools at Codeberg to get a clearer picture

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

Attila Lendvai writes: > do you think there's a substantial number of reviews done by people > who don't have the commit bit? and that their review is a substantial > help for the patch throughput? My point is precisely that I do not know definitively what is the case. And as such, it needs _som

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

Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > summary of this thread: Let's ignore all the issues Guix has and > switch to a new hosting platform, then everything will be better! A part of me fears that that is indeed what's happening. Another part is ho

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

Tomas Volf <~@wolfsden.cz> writes: > The README recommend to just "set fj-token", I *hope* it can be > integrated with (auth)Top somehow. So I definitely have some research > to do here. The best I came up with was this: #+begin_src elisp ((nil . ((eval . (setq fj-token

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

Leo Famulari writes: > The status quo seems bad, with respect to adequate code review, so > many of us are not interested in preserving it. The status quo isn't great. However, it's not clear (to me and some others) that this move will be better. It'll lead to improvements in some areas, but t

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

paul writes: > It is the way to go if Guix is really to be something as useful and as > nice as Debian. Out of curiosity, do you believe that the Linux kernel isn't useful or not nice? -- Suhail

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

Suhail Singh writes: > Ludovic Courtès writes: > >> ## Workflow > > While this section talks in some detail about CI and the merge workflow, > it leaves unstated what the actual review process would look like (and > what demands it may or may not make of the revie

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

Attila Lendvai writes: > - writing comments on a PR or issue in emacs I have yet to see a way (that works with existing forges) that matches the ease of replying to an email, but I look forward to being proven wrong and pleasantly surprised. > what i wanted to point out is that it's not a lot o

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

Ludovic Courtès writes: > ## Workflow While this section talks in some detail about CI and the merge workflow, it leaves unstated what the actual review process would look like (and what demands it may or may not make of the reviewers). Could you please elaborate on that? -- Suhail

Re: On the quest for a new release model

Ricardo Wurmus writes: >> What does making a release entail? Is this documented somewhere? > > It is documented: > > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org Thank you. Should this be linked from the Guix manual? Or is the omission intentional? -- Suhail

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

Jeremy Bryant writes: > The GNU Project's documentation format is Texinfo. How about > distributing some or many Texinfo manuals through Guix, is this > something that is consistent with previous norms in Guix? Guix has had SICP available via Info format since 2016:

Re: On the quest for a new release model

Ricardo Wurmus writes: > Efraim Flashner writes: > >> Since, IMO, the major uses of the actual guix package is for the daemon >> and the installer, I think we could tag a minor release just about every >> time we bump the guix package. That's a sensible approach. How should the discussion proc

Re: On the quest for a new release model

Maxim Cournoyer writes: > If we can agree that producing a release with lowered expectations is > better than producing none, I don't mind to get the ball going. I think it would be helpful to consider our approach for the upcoming release distinctly from what we choose to do for subsequent rele

Re: On the quest for a new release model

Ludovic Courtès writes: > I believe what we need is a release team with rotating duties. That > is, a bunch of 3–5 people commit to doing the work leading to 1.5.0; > then a new team (possibly with overlap) takes over for the next > version, and so on. The issue, as I see it, is the time commit

Re: On the quest for a new release model

Suhail Singh writes: > The issue, as I see it, is the time commitment required from the > release-team. Correction, the issues (IMO) are (in no particular order): 1. the timespan (several weeks) 2. uncertainty around total effort 3. amount of manual effort involved It's unclear w

Re: On the quest for a new release model

Ricardo Wurmus writes: >> Let's say we have two channels in the future: $guix-slim and >> $guix-extras. Wouldn't it be sufficient for $guix-extras to depend on >> $guix-slim ? If not, could you please elaborate? > > You have multiplied the release problem by two. If more releases pose a proble

Re: On the quest for a new release model

Tomas Volf <~@wolfsden.cz> writes: > I just feel there is a lot to figure out with this proposal. Thank you for the detailed response. And I agree that this isn't a solved problem (yet). I propose that further discussion on this tangent happen on a separate thread. Whether Guix is split into m

Splitting up Guix channel (was: On the quest for a new release model)

Ricardo Wurmus writes: > This has been discussed in the past and it is far from trivial. > Consider that glibc needs Python at build time and the Linux kernel may > need Rust. Consider also that it is easy to introduce a package from > the outer ring to the inner ring through transitive dependen

Re: On the quest for a new release model

Simon Josefsson via "Development of GNU Guix and the GNU System distribution." writes: > can we strip away almost all of the packages and still have a minimal > bootable system? If we minimize that set of really-core packages, > maybe there can be one team that works on this minimal bootable OS

Re: On the quest for a new release model

Greg Hogan writes: > We only need a release team and a documented release process. Releases > should be scheduled rather than depending on other teams. What benefit > is there to the Guix user when glibc or the default gcc are updated? > You're only a "guix pull" away from updated packages. > > A

Re: On the quest for a new release model

Suhail Singh writes: > If the goal is to increase the frequency of releases while maintaining > quality, the only consideration that the teams-branch ought to make is > to ensure that the commit in question (corresponding to th

Re: On the quest for a new release model

Ricardo Wurmus writes: > Releases are made a short time after the core team branch is merged. > This would give us a new release whenever e.g. the default GCC and > glibc is bumped up. We could aim for a release two months after the > merge to allow for minor fixes after the merge. I think agre

Re: On the quest for a new release model

Cayetano Santos writes: > Let me just play the dummies advocate for a moment ... Thank you. I believe it is important to consider such scenarios (among others). > They will be doing `whatever install guix`, and then they’ll happily > start using guix: with a bit of documentation, they’ll love

Re: On the quest for a new release model

Ricardo Wurmus writes: > Suhail Singh writes: > >> Assuming my understanding above is correct, wouldn't you agree that >> (even) for those individuals what's most important is that there is a >> _stable_ and _not-very-outdated_ release available? My (and I bel

Re: On the quest for a new release model

Tomas Volf <~@wolfsden.cz> writes: > I would like to point out that there is more work involved than just > splitting it into separate channels and adding those into > %default-channels. Could you please elaborate? Or were these the two points you noted below? > While multiple channels do work

Re: Automatically testing package updates

Efraim Flashner writes: > Also I don't think we should spam the bug tracker with package upgrades, > so we'd have to think about something for that. Could you clarify what you're objecting to? Is it bug issues being created that are then not (as is currently the case) automatically closed? Or

Re: Automatically testing package updates

Attila Lendvai writes: > what other data would you miss that is not available in the git log? No data that is currently being automatically generated. Then again, none of the patches at present are. One can argue (and perhaps that's what you are) that, even in the future, whatever automated-co

Re: bug#68895: Difference between trace behavior in guix repl and guile

Suhail Singh writes: >> It looks like this isn't the only REPL command that doesn't work in >> `guix repl`. I haven't done anything close to a full investigation (I am >> new to using Guile!), but many other commands simply don't work. > > Thank y

Re: bug#68895: `guix repl` breaks Guile REPL features

45mg <45mg.wri...@gmail.com> writes: > It looks like this isn't the only REPL command that doesn't work in > `guix repl`. I haven't done anything close to a full investigation (I am > new to using Guile!), but many other commands simply don't work. Thank you for your investigation. I am cc-ing g

Re: Request-For-Comment process: concrete implementation (v5)

Ludovic Courtès writes: > Even better if we can finalize before Guix Days so: > > discussion period ending on Jan. 14th > deliberation period ending on Jan. 28th > > How does that sound? I have commented on the issue. If my request to be a supporter is accepted, I support the above amendmen

Re: Request-For-Comment process: concrete implementation (v5)

Simon Tournier writes: > During the Discussion Period, we discuss, all. The aim of Supporter is > to keep the RFC on track. Especially, to let space and time to all to > express their voice. Nix names this Role: Shepherd. Maybe it captures > better the idea. > > Then during the Deliberation P

Re: Moving ruby@2 packages to guix-past?

Nicolas Graves writes: > I was trying to get devdocs working properly in a branch, and since it > probably requires updating the whole Ruby world in Guix, I was wondering > about some changes. I was looking into this a few months ago, but ran out of spare time to continue the investigation. Tha

Re: Insights for future development from the Guix Survey

45mg <45mg.wri...@gmail.com> writes: > I'm thinking this could help collect unreviewed work in one place so > that everyone who wants to can see it. For your situational awareness, note that one such place already exists to an extent today. The usertag "patch-review-hackers-list" has been used b

Re: Insights for future development from the Guix Survey

jbra...@dismail.de writes: > What is "patch-review-hackers-list" ? Can you send me some documentation > on how to use it? It's one of a few tags that the london guix meetup has used in the past. See for details, including other re

Re: Guix Common Document process (v7)

Simon Tournier writes: > That’s why, I proposed (v7) to use the low traffic info-guix for > announcing and asking for inputs. info-guix has the following description which, I believe, makes it well-suited to the task: "Low-traffic mailing list for announcements to Guix users." > However, I fin

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

Liliana Marie Prikler writes: > That's why I commented on the Codeberg GCD — so that it can be > included in a v2 of said GCD. I do expect there will be some > revisions before the decision is final. Ah, my bad. That that was the intent had escaped me. Thank you for clarifying. -- Suhail

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

Liliana Marie Prikler writes: > Note that these steps are really not that different from moving Guix > to Codeberg (you have to update %default-channel-url). Since users > have to update either way, it's better to do both at once than just > one at a time. Unless Ludo has changed his preference

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

Liliana Marie Prikler writes: >> I think this is just a matter of image, and I'm not sure about who >> are we trying to please with the change. > Since I was the one to initially make this suggestion: myself, plus > whoever agrees with me, regardless of their reason. ... > As a gesture towards

Re: GCDs on info-guix?

Andreas Enge writes: > info-guix should be announcements for users, and this is clearly a > developers' issue (mainly relevant to the people who have a say in the > end, that is, team members, although anybody can chime in). I think it would be better to not think of a GCD as simply a "developer

Re: GCDs on info-guix?

Simon Tournier writes: > • We do not go via info-guix and then people will complain because > they had not been aware and they did not have the opportunity to > raise their voice; > > • We go via info-guix and then yes the traffic on info-guix might be a > bit higher than usual fo

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

Andreas Enge writes: > my observation was rather the inverse: our current debbugs approch > struggles for patch series. Ah, my bad. I mistook "issues" to mean issues on a forge as opposed to a debbugs issue. Thank you for correcting. > Which says nothing about the experience on a forge, logic

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

Ludovic Courtès writes: > As for experimenting, I agree and I reiterate my invitation to send > trivial patches to (or to > Guix-Science, Guix-Past, etc.). I think this GCD’s discussion period is > the right time to give it a try as it can better inform discus

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

"Thompson, David" writes: > The email-based workflow worked well enough in the early days, but > Guix outgrew it 5+ years ago. Do you also believe that the Linux kernel has outgrown the "email-based workflow"? If not, what makes things different for Guix, in your opinion? Since a number of cri

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

Divya Ranjan writes: > I had to realize that Linux gets a *lot* more in funding and > infrastructure than Guix. While I agree in general, I don't understand the specific point you were making. Was it that Linux with its greater funding has someone to manage something like Bugzilla, where Guix m

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

"Thompson, David" writes: >> Do you also believe that the Linux kernel has outgrown the "email-based >> workflow"? If not, what makes things different for Guix, in your >> opinion? > > I don't contribute to Linux so I have nothing to add here. I don't believe that that's a necessary pre-requisi

Re: Scaling issues with forges Was: Trying out Codeberg

Hi Simon, Simon Tournier writes: > Yeah, I’m happy with my setup and I shared [3] several times how Emacs + > Notmuch + Org-mode is really nice for me. And I also engaged [4] how > public-inbox can help. Are the relevent portions of your .emacs or init.el accessible somewhere? -- Suhail