Re: Haskell & Rust Team on recent stable releases of compilers
Andreas Enge writes: > Am Mon, Oct 21, 2024 at 03:28:48PM + schrieb Divya Ranjan: >> Okay, should I contact them separately or do I need to CC someone specific? > > From the checkout, you can do this: >./etc/teams.scm show rust > > ... > members: > + Efraim Flashner > > Well, so a team can be one person ;-) > I think Efraim reads this list, but feel free to cc him. Thanks for that tip, Andreas! Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software.
Re: Haskell & Rust Team on recent stable releases of compilers
Hello Andreas! Andreas Enge writes: >> Regarding copyright assignment, I've already started the paperwork by >> emailing >> the form to ass...@gnu.org. I did it through Emacs, but I believe I don't >> need >> to do it again? Some guidance for that would also be helpful. > > No need to assign copyright for work on Guix, we keep the individual > contributors. Great! > But I may as well comment on the other ones and have myself corrected by more > knowlegeable people from the corresponding teams. > >> I've been using Guix for the last few months. As a Haskell programmer, I >> realized the latest stable that's available in the guix package repository is >> 9.2.8 which is _really_ old, considering that the current stable releases are >> at least older than 9.6.x. >> >> I'd like to contribute to this if I can, since I myself would like to have >> the >> latest GHC for my uses. So, how can I get the latest versions available? Do >> I >> need to add every release, or can I just add the most latest? >> >> Also, is the process of adding a GHC release, or any Haskell package any >> different from the typical procedure to add a package? I'd like some >> introductory guidance/resources to learn that. > > There should not be a difference with packages for other languages. > As far as I know, however, ghc is annoying to bootstrap, and we need at > least the latest x.y.z version to continue to x.(y+2). Understood, will keep in mind. >> The same is true for rustc, the latest stable release is not updated. I'd >> like >> to help with that, if possible. > > For rust, there is a special branch rust-team, where the work is coordinated. Okay, should I contact them separately or do I need to CC someone specific? Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software.
Re: Haskell & Rust Team on recent stable releases of compilers
Hello, Saku! Saku Laesvuori writes: > I think you need to add every other major release to the chain. We > already have 9.2 and 9.4, so 9.6 should not be a problem in that regard. Okay, so GHC needs to be incrementally upgraded, understood. >> Also, is the process of adding a GHC release, or any Haskell package >> any different from the typical procedure to add a package? I'd like >> some introductory guidance/resources to learn that. > > Not really, but this specific update (GHC 9.4 to 9.6) is quite tricky > because GHC changed their build system from a make to Hadrian. Hadrian > written in Haskell and depends on quite many packages, so we need to > build all those with an earlier GHC version to be able to build the > current GHC. See https://issues.guix.gnu.org/67921 for the current > situation with this. I am still quite busy with other things in life, so > feel free to pick those patches up. Indeed, since I’ve done a bit of tinkering with GHC’s source, and have tried building with Hadrian, I’ll see what can be done. Thank you for referring me to the issue, I’ll check. > The Guix manual[1] and cookbook[2] have generic documentation and examples > for creating Guix packages. > > [1]: https://guix.gnu.org/manual/devel/en/guix.html > [2]: https://guix.gnu.org/cookbook/en/guix-cookbook.html Thanks! Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software.
Re: Haskell & Rust Team on recent stable releases of compilers
Hello Lars! Lars-Dominik Braun writes: >> Not really, but this specific update (GHC 9.4 to 9.6) is quite tricky >> because GHC changed their build system from a make to Hadrian. Hadrian >> written in Haskell and depends on quite many packages, so we need to >> build all those with an earlier GHC version to be able to build the >> current GHC. See https://issues.guix.gnu.org/67921 for the current >> situation with this. I am still quite busy with other things in life, so >> feel free to pick those patches up. > > in addition, note that we’re importing packages matching our GHC version > from Stackage where possible and not the latest and greatest from Hackage. Is there a specific reason why we’re following the Stackage releases? Stackage is one step slower in getting the updates. The current Stackage Nightly is 9.8.2, while Hackage has 9.10.1. Is this due to some stability issues with Hackage? Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software.
Re: On "next" packages and related confusions.
Hello Ryan, > I think it would be appropriate if each "next" package had a code comment, or > perhaps an addendum to its package description, describing how it relates to > the main packaged version. I think the whole "next" category is problematic. Why not just have a version number of that package that's different from the "main" one? So instead of emacs-next have emacs-30.0.9 or whatever. At least here the choice of arbitrariness is visible. A "next" makes no sense. > In case you don't know about "--with-latest", that's the supported way to > install the latest master branch of a package. "-next" packages are not meant > to closely track master. Thank you for this, how can this be added when declaring a package in system or home configuration? Regards, Divya Ranjan, Mathematics, Philosophy and Libre Software
On "next" packages and related confusions.
Hello, As someone who’s been recently involved in packaging some software for GNU Guix I’m confused with certain choices, mostly with the [package]-next category. What should these next packages be? "More recent" than the non-next package? If so, how much more recent? One release ahead? Or is it supposed to follow the latest master release from the source repository of the package, and the non-next package would be the stable one? None of the above options seem to satisfy, emacs-next does not follow the latest master, but it further away than one release from the stable. So what exactly does emacs-next follow for being updated? This is not only confusing, but I believe creating issues in packaging as well, someone has even consdiered packaging a "emacs-nextnext" [0]. A better solution is necessary, at least if not that we should decide what and how should the "next" packages be provided and packaged, emacs-next doesn’t even have a description. The next packages should have a _distinct_ description from the non-next ones, so that when the user is installing it they know that they’re installing not a stable, or more recent or whatever we decide as the distinguishing element between the two categories. I’ve seen similar issues in trying to upgrade the ghc package as well, the ghc-next isn’t clear as to what its following [1]. A clearance of these confusions would be better for both package maintainers and end-users who don’t see much beyond the description, version and do `guix install'. [1]: https://issues.guix.gnu.org/issue/47335 [0]: https://issues.guix.gnu.org/73281 Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software.
Re: On "next" packages and related confusions.
"Philip McGrath" writes: > On Mon, Nov 11, 2024, at 7:50 PM, Divya Ranjan wrote: > > > I think it would be appropriate if each "next" package had a code comment, > or perhaps an > addendum to its package description, describing how it relates to the main > packaged version. > > I think the whole "next" category is problematic. Why not just have a > version number of that > package that's different from the "main" one? So instead of emacs-next have > emacs-30.0.9 or > whatever. At least here the choice of arbitrariness is visible. A "next" > makes no sense. > > One problem with this is that tools resolve a bare package name like "emacs" > to the package with > that name with the greatest version. So if, for example, the base package is > following a LTS channel, > or if there's a reason to package a pre-release version, adding "-next" to > the name ensures that users > don't accidentally end up with a newer-than-recommended version. But that should be handled differently I believe. Since this only creates confusion. Can there be a way to sort of "pin" the release version to the namespace "emacs" and other versions to be emacs-x.x. Or at least remove the arbitrariness of emacs-next and keep it updated to the master like emacs-git in Arch. Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software.
On updating anki to latest Qt version
Hello Robert and others, Checking the logs, I found that you added Anki in Feb (8534c94). As a regular user of anki, I found that the one provided by Guix is simply too old, almost 5 years old. The index of the downloads doesn’t even show 2.1.16. The comment in /gnu/packages/education.scm shows: #+begin_src scheme (define-public anki (package (name "anki") ;; Later versions have dependencies on npm packages not yet in Guix. (version "2.1.16") (source ...)) #+end_src I haven’t checked all the versions, but the latest version of Anki _does not_ seem to have any npm dependencies. The official development instructions [0] do not mention anything about npm, and the Linux Specific notes [1] only mention that node binary is a prerequisite, which seems to be already packaged in guix. Other guides [2] do not seem to need any npm either, I’ve known that it’s been notoriously difficult to package anki into distros [3,4], but I _believe_ (I’m not sure), things have changed since they switched from Bazel back to Ninja build system? I’d like some work on this, I want to rely on flatpak as less I can. [0]: https://github.com/ankitects/anki/blob/main/docs/development.md [1]: https://github.com/ankitects/anki/blob/main/docs/linux.md [2]: https://chrislongros.com/2023/03/23/how-to-build-anki-from-source-in-linux/ [3]: https://github.com/ankitects/anki/issues/1378 [4]: https://forums.ankiweb.net/t/need-support-for-building-packaging/41892/5 Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software.
Re: On a Guile-based Build-Tool complimenting Guix
gt; (name "has-gdb-inproctrace") > (value (delay >(and (find-binary/progress "gdb") > (find-library "libinproctrace.so") > (variable > (name "has-liteinst") > (value has-liteinst?)) > (variable > (name "has-csmith") > (value >(delay (and (find-binary/progress "csmith") #t > (variable > (name "csmith-include-directory") > (value >(delay > (and=> (find-header "csmith/csmith.h") dirname > (variable > (name "environ") > (value (delay (environ) > %standard-directory-variables)) > (options >(append > (list > (option > (switch "disable-ftrace-build") > (synopsis "do no build libpatch-ftrace.so") > (action (make-simple-action "build-libpatch-ftrace" #f))) > (option > (switch "disable-patch-coverage-build") > (synopsis "do not build libpatch-coverage.so") > (action (make-simple-action "build-libpatch-coverage" #f))) > (option > (switch "disable-patch-integrity-build") > (synopsis "do not build libpatch-integrity.so") > (action (make-simple-action "build-libpatch-integrity" #f))) > (option > (switch "enable-tsan-on-native-benchmarks") > (synopsis "enable TSAN for native benchmarks") > (action (make-simple-action "tsan-native-benchmarks" #t))) > (option > (switch "without-manpages") > (synopsis "disable manpages generation") > (action (make-simple-action "build-manpages" #f))) > (option > (switch "without-lttng") > (synopsis "disable any usage of LTTng") > (action (lambda _ (set! lttng-allowed? #f > (option > (switch "without-dyninst") > (synopsis "disable any usage of Dyninst for benchmarking") > (action (lambda _ (set! dyninst-allowed? #f > (option > (switch "without-liteinst") > (synopsis "disable any usage of LiteInst for benchmarking") > (action (lambda _ (set! liteinst-allowed? #f > (option > (switch "without-benchmarks") > (synopsis "do not compile benchmarks") > (action (make-simple-action "build-benchmarks" #f > %standard-directory-options)) > (templates >(list > (template-file > (input "aux/Makefile.in") > (output "Makefile")) > (template-file > (input "aux/project-repl.in") > (output "project-repl") > (mode #o744)) > (template-file > (input "src/lib/pkgconfig/libpatch.pc.in")) > (template-file > (input "src/bin/patch-ftrace.in") > (mode #o744)) > (template-file > (input "src/bin/patch-coverage.in") > (mode #o744)) > (template-file > (input "src/bin/patch-integrity.in") > (mode #o744)) > (template-file > (input "scripts/debug-test.in") > (mode #o744 > (config-files >(list > (c-config-file > (path ".config.h") > (namespace "CONFIG_")) > (scm-config-file > (path "config.scm") > (namespace "config" > (status-file >"config.status"))) > >(define (main args) > (with-exception-handler > (lambda (exn) >(if (eq? 'quit (exception-kind exn)) >(raise-exception exn) >(begin > (print-exception (current-error-port) > #f > (exception-kind exn) > (exception-args exn)) > (primitive-exit EXIT_FAILURE >(lambda () > (call-with-values > (lambda () >(configure libpatch-configuration)) >(lambda (variables _ errors) > (with-nest-progress > "features summary" > (for-each > (match-lambda > ((feature-name . feature-description) > (let ((name+feature (assoc feature-name variables))) >(if name+feature >(progress "~a ~a" > (if (cdr name+feature) > (colorize-string "OK
Re: On a Guile-based Build-Tool complimenting Guix
Hello Attila, > i'm not sure whether that is part of your goals. maybe you just want to > provide an alternative build system, and merely inspire upstream authors to > migrate to it? (as opposed to providing a compatible guile-based build script > in parallel to upstream's makefiles) Indeed the latter is more like it. I want the build-system to be Makefile-compatible but it should be different enough from it. I do see the complexity of the project, but I believe it's not exactly "rewrite bazel on guile" but more like "a build system to complement guix packaging". > and as a final note: below is a nice bird's eye view on build systems. it's > part of an enlightening series of chapters where a martian programmer crashes > their ship on earth and enters into a dialog with a human programmer while > trying to rebuild his ship: > https://ngnghm.github.io/blog/2016/04/26/chapter-9-build-systems-and-modularity/ Thanks a lot for the blogpost! Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: GNU Manuals in Info/HTML format via Guix?
I plan to begin working towards this to package GNU Manuals. But, I wish to ask, where should I collect these manuals from? They aren't at a centralized place, I guess? So I should look for them one-by-one through the FSF Directory? And Guix users/devs, is there a way to figure our whether a GNU Manual is already packaged with its parent package (of which it is a manual) or not? I plan to first port them to my Guix channel [0] and then send patches upstream. [0]: https://codeberg.org/divyaranjan/divya-lambda Regards, On 18 December 2024 01:20:58 GMT, Maxim Cournoyer wrote: >Hello, > >Cayetano Santos writes: > >>>dim. 15 déc. 2024 at 22:34, Jeremy Bryant wrote: >> >>> Following a discussion on emacs-devel, several people suggested that >>> GNU Guix may be a a good way to contemplate this distribution mechanism, >>> for obvious GNU-related reasons. >> >> Remember you always have the possibility to create a dedicated guix >> channel, external but complementary to guix upstream itself, to >> distribute manuals. This would about any additional overload on guix >> maintenance tasks. > >Well, the topic being GNU manuals, they'd be more than at home in GNU >Guix. Typically though they come with the packages themselves, such as >'libc.info.gz' which is shipped with glibc. > >I think Guix would be a fine place to have them packaged and made >available. We already have the C manual you mentioned; it's a great >read! You can read it with > >--8<---cut here---start->8--- >$ guix shell info-reader c-intro-and-ref -- info c' >--8<---cut here---end--->8--- > >More info on this package: > >--8<---cut here---start->8--- >$ guix show c-intro-and-ref >name: c-intro-and-ref >version: 0.0.0-1.47e5a23 >outputs: >+ out: tout >systems: x86_64-linux i686-linux >dependencies: texinfo@6.8 >location: gnu/packages/c.scm:83:4 >homepage: https://www.gnu.org/ >license: FDL 1.3+ >synopsis: GNU C Language Intro and Reference >description: This manual explains the C language for use with the GNU Compiler >Collection (GCC) on the >+ GNU/Linux system and other systems. We refer to this dialect as GNU C. If >you already know C, you can use >+ this as a reference manual. >--8<---cut here---end--->8--- > >-- >Thanks, >Maxim > Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: On a Guile-based Build-Tool complimenting Guix
Hello Fi, Would you prefer a guile interface to meson, or a meson replacement in Guile? Regards, On 27 December 2024 00:41:33 GMT, Fi wrote: >I was thinking this the other day!, was wondering about how useful a guile >interface to meson would be. > >On 19. 12. 24 22:12, Divya Ranjan wrote: >> Hello Guix, >> >> The other day, after being frustrated of build systems (auto-tools, meson, >> maven etc.), I wondered why doesn’t Guix which has such powerful tools >> within it (`guix build`, `guix pack` etc.) also not have a purely >> Guile-based build tool? After all, our goal is to make deployment, and >> building both more declarative and away from the all-too-familiar >> “dependency hell”. >> >> I am not exactly sure how I want to go with this, but I want to extend (if >> needed) the capabilities of Guix, to allow the developer of a package to use >> it also to build the package effectively replacing existing build tools. >> Since we already have build-system, instead of executing make (or whatever >> other tool) commands from it, we could modify it to itself have all those >> things that a Makefile would have. >> >> The developer would use Guile to declare their build config, I am again not >> sure what this might exactly look like, but can’t we have it such that we >> provide the developer with some tools to _declare_ a custom and >> package-specific build-system in Guile (just like our familiar >> gnu-build-system), but this is purely in Guile and executes whatever >> commands, path declarations and other interactions (such as calling gcc) >> directly from Guile and not by just calling `make`. I haven’t thought >> through this clearly, but even if this doesn’t work, the main idea I’d like >> to propose is to fully replace existing build-tools by making a new Guile >> build tool to work alongside Guix. >> >> Ideally, once the developer has a build config ready, one can just wrap it >> up with a package definition in Guile, just like the ones we create to >> package something upstream. This package definition can then be used in >> `guix build -f package.scm` to result in a fully transactional building >> process that focuses not on getting out of dependency hell, but just >> declaring your config right. And all of this without having to learn yet >> another build tool that might disappear, and of course, without leaving the >> comfortable world of Lisp (Scheme). >> >> I was indicated by others that such an idea has previously been conceievd >> among Guix developers themselves, namely as a GSoC proposal[0]. I couldn’t >> find if that has progressed towards anything, nor could find anything in the >> mailing list. I did see Pjotr volunteering to mentor for it, I’ve CC-ed them >> to see if they’re still interested in such a project. Meanwhile, I’d like >> input from other Guix core developers on what they think of this, and if >> they could provide me with some leads on where to go with this. >> >> >> [0]: https://libreplanet.org/wiki/Group:Guix/GSoC-2024 >> >> Regards, Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: Expressing my interest for participation in fellowship-like programs
Hello Ashvith, The GSoC program you're considering was only a proposal, and I'm not sure if it was an accepted one. Pjotr can say more about that. I recently began a thread on a Guile-based build system, you can look through that and ask if anything's needed. Regards, On 26 December 2024 09:41:21 GMT, Ashvith Shetty wrote: >Hello folks, > >I would love to take part in the next GSoC/Outreachy with Guix as my >organisation of choice. I have contributed to Guix before, and >participated in the unofficial matrix channel. > >I am a little worried about the difficulty and the scope of the >project topic of some of the projects mentioned in LibrePlanet, and I >would like to start with something that is a bit easier to work and >understand, before the start of the program to evaluate the >difficulty, learn and get used to the workflow for the internal >components. > >Right now, I have my interest in "Guile based build-tool for Guix", >and I've also come across examples like Bespoke and potato-make. >Honestly, I don't know much about build-system, so I would love to >understand how and what are the prerequisite skills that would enable >me to be able to successfully complete the program. > >Regards, >Ashvith > Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: On a Guile-based Build-Tool complimenting Guix
Hello Pjotr, glad to see that you'd be still interested in such a project. > Where it comes to other targets, such as Debian distros and all, it is > probably going to be too painful to handle to resolve all their demands. Can you elaborate on what exactly would be hard to figure out for a Debian target? And, I personally think just generating makefiles in Guile isn't really going to be better. I mean it'll save someone from writing a Makefile in, well, Make, but it will still have the issues of `make`. I believe it is an alternate build system that we should try. Regards, Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: On a Guile-based Build-Tool complimenting Guix
Thanks for sharing these, Janeke! On 19 December 2024 21:17:39 GMT, Janneke Nieuwenhuizen wrote: >Divya Ranjan writes: > >Hello, > >> The other day, after being frustrated of build systems (auto-tools, >> meson, maven etc.), I wondered why doesn’t Guix which has such >> powerful tools within it (`guix build`, `guix pack` etc.) also not >> have a purely Guile-based build tool? After all, our goal is to make >> deployment, and building both more declarative and away from the >> all-too-familiar “dependency hell”. > >[..] > >> I was indicated by others that such an idea has previously been >> conceievd among Guix developers themselves, namely as a GSoC >> proposal[0]. I couldn’t find if that has progressed towards anything, >> nor could find anything in the mailing list. > >From my notes I have > >* make in Guile: potato-make, bespoke >** https://github.com/spk121/potato-make >** https://codeberg.org/lechner/bespoke > >but there's probably more. And then there's also the Guix Workflow >Language. > >Greetings, >Janneke > >-- >Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org >Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: On a Guile-based Build-Tool complimenting Guix
Hello Sergio, > While I don’t have a specific starting point in mind, I believe that an > essential feature such a tool, is the ability of continuing builds from > successful phases. While I haven't looked Nicholas' patches carefully, how do you think we could use Guix's build-system functionality as it stands now for a proper build system? Olivier, have you thought about this? A sort of custom build-system (loke gnu-build-system) for each package to build? Regards, Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: Guix Consensus Document process ratified!
Hello Ludo, Glad that we've finalized the GCD! Really happy to see it. But is it that you've missed my "I support" or that my name is not there in /etc/teams.scm? I just did a search in https://issues.guix.gnu.org/74736 and found that I had sent a "I support" on 25th Jan 17:18 UTC. It doesn't matter since the GCD has been accepted overall, but just wanted to ensure I successfully submitted it. Regards, On 6 February 2025 21:40:15 GMT, "Ludovic Courtès" wrote: >Hello Guix, > >The Guix Consensus Document (GCD) deliberation process was set to expire >yesterday, February 5th, anywhere on Earth. I was quite impatient so I >checked the results¹: 22 team members expressed support; quorum was 25% >of 44 people², or 11 people, so we’re good. The GCD process is accepted! > >Really happy that we can move forward with this and thankful to everyone >who participated. > >Simon, Noé: let’s coordinate to update guix-consensus-documents.git and >to communicate. > >Ludo’. > > >¹ Here’s what I collected from the deliberation thread at > <https://issues.guix.gnu.org/74736>: > > * Support (team members) > >- Andreas Enge >- André Batista >- Andrew Tropin >- Efraim Flashner >- Ekaitz Zarraga >- Eric Bavier >- Florian Pelz >- Guillaume Le Vaillant >- Ian Eure >- Janneke Nieuwenhuizen >- jgart >- Lars-Dominik Braun >- Laurent Gatto >- Liliana Marie Prikler >- Ludovic Courtès >- Maxim Cournoyer >- Nicolas Goaziou >- Ricardo Wurmus >- Sharlatan Hellseher >- Tanguy Le Carrour >- Tobias Geerinckx-Rice >- 宋文武 (iyzsong) > > * Support (other contributors) > >- David Thompson >- Gabriel Wicki >- Hilton Chain >- Timothy Sample >- Zheng Junjie > > * Accept (other contributors) > >- Hartmut Goebel > >² “./etc/teams.scm list-teams |recsel -P members |sort -u |wc -l” > returns 44 as of c8c025973bf9bfc060b7cc82c6b025ebd87ffa2f, but that > includes one blank line. > Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: Guix (and Guile's) promise, and how to (hopefully) get there
re as they work on building it? How much do we value this, is it higher, lower or equal to the technical aspects of Guix? In my opinion, currently we prioritize it highly or equally, and I think we _should_ continue with that. If the community and the foundation choses to change this to a lower priority, losing the spirit of free/libre software, then it makes sense to leave GNU. I have used GNU/Linux distributions over the last 5 years, I spent 4 of them exclusively on Arch Linux. My primary machine used to be a 16 year old i3 1st generation, and Guix ran on it as smoothly as any distribution would. I never faced issues with firmware due to linux-libre kernel. This month when I switched to a newer machine, I realized that it’ll be unusable on linux-libre, and I was forced (with much regret) to rely on linux with firmware blobs. Other than this, I have faced no major issues from Guix itself, had I used linux-libre in Arch, I would’ve had the same issue. Thus, I think we might be focusing on the wrong things when we analyze lacunae of Guix. Just like Emacs has ELPA and MELPA, we also have nongnu alternatives for those who are forced to rely on it, and that might be improved, but why consider that GNU is holding Guix back? I doubt anyone would say GNU has held Emacs back, it hasn’t. If at all, Emacs (despite the recent drama and others in past) has grown to remain one of the best editors with modern features (TreeSitter, multiple LSP clients, etc.) Similarly, I would suggest the thoughts on improving Guix/Guile to look at aspects of the project where we might not be doing the best job, or if we can take different steps in terms of reachout. But as an user and contributor, please don’t take steps to separate Guix from GNU. It’ll be a considerable loss too both the projects. Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software.
Re: HP Printer setup with Cups & hplip
Hello Maxim, I never did solve the problem, I even changed machines and a fresh installation of Guix, that too moving from linux-libre to mainstream linux kernel, but the issue persists. On 15 December 2024 04:43:18 GMT, Maxim Cournoyer wrote: >Hi, > >Divya Ranjan via "Development of GNU Guix and the GNU System >distribution." writes: > >> Felix Lechner via "Development of GNU Guix and the GNU System distribution." >> writes: >> >>> Hi Divya, >>> >>> On Wed, Oct 23 2024, Divya Ranjan via "Development of GNU Guix and the GNU >>> System distribution." wrote: >>> >>>> I’ve tried the hp-setup to setup the printer again, nothing >>>> changes. I’ve tried other hp scripts like hp-check, hp-doctor, >>>> hp-diagnose_plugin etc. they don’t work either. >>> >>> I've never had much luck with hplip. Can you install the PPD for your >>> printer [1] manually into CUPS and use it directly? >>> >>> [1] >>> https://sources.debian.org/src/hplip/3.16.11%2Brepack0-3/ppd/hpcups/hp-laserjet_professional_p1108.ppd/ >> >> Thanks Felix, I did download this and put it as the PPD through CUPS, but >> nothing changes. > >I remember loosing some hairs on a similar issue, and in the end the solution >was >something extremely ridiculous, like making the printer 'active' in the >CUPS we admin interface. > >I had never disabled it, so was quite surprised by that. > >I hope you can make it work; it's quite frustrating to troubleshoot >problems like this, especially when we have real work to do :-). > >Good luck. > >-- >Thanks, >Maxim Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: GNU Manuals in Info/HTML format via Guix?
Hello, Jeremy, Jeremy Bryant writes: > Hi Guix developers, > > 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? I believe this is certainly feasible, and desirable. Since Guix itself relies a lot on functioning with info for its documentation requirements. > Following a discussion on emacs-devel, several people suggested that > GNU Guix may be a a good way to contemplate this distribution mechanism, > for obvious GNU-related reasons. > > We discussed both a comprehensive solution for Info manuals, as well as > specific cases such as RMS's C manual (c.info) which is not part of a > software project. As Maxim noted, the particular manual already exists. But we need to think about how exactly to package the Info manuals. Since Guix’s process of packaging is a bit differently organized, we’d have to figure out where exactly should the package definitions for these manuals live in the Guix source tree. I see that the C manual is in gnu/packages/c.scm and SICP in gnu/packages/scheme.scm, so maybe each manual could go into the relevant program/language’s guile module. Or, should we have a module just for the Info manuals? I see gnu/packages/texinfo.scm and it has mostly a few packages related to TeXinfo readers, could we put them there, or only the miscellaneous ones? Those more knowledgeable about Guix’s source-tree management should shed light on this. Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software.
On a Guile-based Build-Tool complimenting Guix
Hello Guix, The other day, after being frustrated of build systems (auto-tools, meson, maven etc.), I wondered why doesn’t Guix which has such powerful tools within it (`guix build`, `guix pack` etc.) also not have a purely Guile-based build tool? After all, our goal is to make deployment, and building both more declarative and away from the all-too-familiar “dependency hell”. I am not exactly sure how I want to go with this, but I want to extend (if needed) the capabilities of Guix, to allow the developer of a package to use it also to build the package effectively replacing existing build tools. Since we already have build-system, instead of executing make (or whatever other tool) commands from it, we could modify it to itself have all those things that a Makefile would have. The developer would use Guile to declare their build config, I am again not sure what this might exactly look like, but can’t we have it such that we provide the developer with some tools to _declare_ a custom and package-specific build-system in Guile (just like our familiar gnu-build-system), but this is purely in Guile and executes whatever commands, path declarations and other interactions (such as calling gcc) directly from Guile and not by just calling `make`. I haven’t thought through this clearly, but even if this doesn’t work, the main idea I’d like to propose is to fully replace existing build-tools by making a new Guile build tool to work alongside Guix. Ideally, once the developer has a build config ready, one can just wrap it up with a package definition in Guile, just like the ones we create to package something upstream. This package definition can then be used in `guix build -f package.scm` to result in a fully transactional building process that focuses not on getting out of dependency hell, but just declaring your config right. And all of this without having to learn yet another build tool that might disappear, and of course, without leaving the comfortable world of Lisp (Scheme). I was indicated by others that such an idea has previously been conceievd among Guix developers themselves, namely as a GSoC proposal[0]. I couldn’t find if that has progressed towards anything, nor could find anything in the mailing list. I did see Pjotr volunteering to mentor for it, I’ve CC-ed them to see if they’re still interested in such a project. Meanwhile, I’d like input from other Guix core developers on what they think of this, and if they could provide me with some leads on where to go with this. [0]: https://libreplanet.org/wiki/Group:Guix/GSoC-2024 Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software.
Re: On the "next" packages, and packaging confusion.
Hello Sharlatan, That is understandable, but I guess you can already see how diverse these customs are between one ecosystem and another. I was simply asking if these practices can either be documented clearly or made uniformly. Regards, Divya Ranjan On 23 November 2024 15:34:24 GMT, Sharlatan Hellseher wrote: > >Hi Divya, > >Speaking from Python/Golang/Astro teams perspective. > >I see and use *-next where I need the latest package version but >updating inherited one would trigger a large amount of re-builds. It may >be swap on dedicated team branch when more packages start needing it. > >In Golang, there are breaking changes versions which are specified in >module path and reflected in Guix' package names e.g. >go-github-com---v2 > >If updating package does not trigger more than 300-400 related packages >there is not need to introduce *-next variant and it's reasonable just to >update to the latest version. > >Hope it helps > >Live well! > >-- >Oleg Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: [GCD] Migrating repositories, issues, and patches to Codeberg
Hello, Ricardo Indeed, I trust that over the years you and others must have tried their best. > Or they *do* Cc the team, but the email drowns in all the other Guix emails > and I have no way of listing all patches affecting my field of > responsibility, etc. This I agree with, after being part of teams, I had been looking for such methods. One way is to get patches which mention the branch name (Rust Team, Emacs Team etc.) but maybe we should have also another tag in the subject every time it's directed to a team? Akin to labels in a web-based setup. Also, since you and others have had such experience with these tools, I'd like some suggestions from you and everyone else on what Savannah and FSF can do to have the workflow smoother. I believe the "learning curve" issue is irrelevant to this, but mostly infrastructure wise, what can be improved/repaired/maintained better? I ask this because I'm slowly taking responsibilities at FSFSysOps and Savannah. I communicated with the FSFSysOps team last night, and they're open to working on improvements. While of course, I'm not suggesting Guix to rely on this or wait for it, I'm simply asking what we can learn from this to go forward in having other GNU projects to be better. Thank you. Regards, Divya Ranjan Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: [GCD] Migrating repositories, issues, and patches to Codeberg
Hello Ludo, > All this contributes to a [poor > experience](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-3/) > for those who choose to contribute despite the barrier to entry, probably > discourages many to even start contributing, and adds to the load of > committers and infrastructure maintainers. While I have differing views on the poor experience, from the 3rd part of survey’s results, don’t we see the answers to "What would help you contribute more to the project?" has answers of differing priorities? Only 9% of contributors feel like the addition of a PR-based workflow ála Github/Codeberg/Gitlab would lead to them contributing further but while 203 respondents (a total of 20%) report that it’s the timely reviews and actions on contributions that inhibit motivation for further contribution. I have started contributing over the last few months, and the current (Savannah, email based) workflow was a bit difficult but I overcame it in a few days, not even a week. And I’d certainly accept that I had an existing workflow for similar projects I contribute to, and have had used Gnus, and debbugs.el, but the learning curve isn’t really that much of an issue, from my personal opinion. What I do think could lead to better contributions is what’s reported in the survey before the workflow change, i.e, timely reviews, better REPL debugging and most importantly a guidance/mentoring setup. Guix Social goes far enough to enable this to some extent, thanks to Steve, but we should have a workflow where we keep certain issues/upgrades as low-hanging fruit for the beginners, and walk them through it over time. I had Ekaitz do the same with me, when i was contributing my first package to Guix. And I’d always be grateful for that, because if I hadn’t had that mentoring for a day or two, I’d have gotten frustrated and kept contributing to Guix aside for a while. I use and have used Codeberg and Sourcehut, it’d be not an issue for me to switch either way. Though I do have to ask, would there be an intent to maintain a mirror at Savannah, if Guix chooses to primarily shift to codeberg/forgejo? And also, it is better to go with Forgejo as a self-hosted instance than relying on codeberg.org since the latter has limitations on how big repositories you can host[0]. I’ve heard they can provide more, but since we already have existing infrastructure, why not go the self-host path? I’d be glad to contribute to the migration however I can, but I suggest we reflect on the necessity and consequences of this a bit more. [0]: https://docs.codeberg.org/getting-started/faq/ Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Re: GNU Manuals in Info/HTML format via Guix?
Greetings for a New Year, Richard, > The task here is to distribute Info manuals in a few platform-independent > non-source forms, perhaps Info and HTML. Perhaps PDF files too. That is so > much simpler than what Guix has to do that using Guix for this would be a > quick and dirty hack. Indeed, I agree with you here. Though, a special aspect of Guix is that it is _both_ and independent GNU/Linux distribution, and a package manager that can be hosted on any foreign GNU/Linux distribution whether Debian or Trisquel. That said, the problem here is that distributing the manuals through Guix now limits them to users of Guix (package manager and distribution). And that is not what we want, the manuals should be distributed so that anyone can have them regardless of which distribution they use. > The task here can be done with something much simpler, and if we decide to do it, writing a clean solution won't take very long. And it will be simpler to understand than Guix. I agree it would be simpler than installing and learning Guix, but can you hint at what such a solution might look like? Manuals are usually distributed as packages, and package management of most (Guix is an exception) GNU/Linux distributions is painfully isolated and idiosyncratic to the particular system. Can we create a single repository containing all of the manuals, which then acts as the main source from which all GNU/Linux distributions can fetch and update? I believe the construction of a system to _manage_ such manuals is relatively much simple, but it is the distribution that I'm afraid would be complicated. Regards, Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: Jami: anyone using it in a Guix System?
Hello Giovanni, I’m a daily GNU Jami user, and also slowly contributing to it upstream. > sorry for the crossposting but AFAIU other users have problems using > Jami on Guix. [1] > > Please is someone succesfully using Jami on a Guix System? > > I'm asking because I'm succesfully using it on Debian after having > started it via "guix shell jami" (version 20240524.0), but I was not > able to use it on 3 different Guix Systems, for this reason I've opened > the bug report #76231: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76231 > https://issues.guix.gnu.org/76231 > > (if you have useful info on the bug please follow-up in the bug report > thread) > > To be clear: (Latest™) Jami is working fine and I'm impressed by the > quality of the (one-to-one) audio/video call feature, including screen > sharing; I'm using it on my work desktop and laptop (installed via guix > on Debian) and on my Android smartphone (installad via F-Droid) and all > is working fine, so it's not a problem with Jami but with Jami running > on (a very recent) Guix System. Distributing Jami is actually a pain, and getting it working on something like Guix is moreso. Take a look at ffmpeg-jami (in gnu/packages/video.scm of Guix source tree) or jami’s qt package in Guix. There’s a lot of patching that gets done. I also experience the same sort of issues you mentioned, synchronization issues and the freezing ones. Thank you for investigating with different systems, now we know with some certainty that the issue is in Guix’s Jami package. I was going to such testing with different devices soon. Also thank you for creating the issue, we can follow up there. There’s also an issue in upstream jami-client-qt at: https://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/1781 if you want to take a look. P.S: We also have a Jami swarm for Guix (and Emacs), if you want to connect there with other Guix users, send me a contact invitation to the username: divyaranjan1905 Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Re: Please don't leave GNU
Hello Florian, The discussion has happened in guix-devel before. The one when I participated was last year[0], and there was also discussion of this in the last Guix Days[1]. [0]: https://lists.nongnu.org/archive/html/guix-devel/2024-12/msg00141.html [1]: https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00014.html On 30 March 2025 10:55:33 GMT, "pelzflorian (Florian Pelz)" wrote: >Hello Caleb. > >Caleb Herbert writes: >> Please don't leave GNU > >Your mail alerted me; I too hope but also believe there are no such >plans to leave GNU. Where have you heard? > >There are not yet decided discussions that GNU Guix leave Savannah and >Debbugs and replace them for Codeberg/Forgejo. > >One argument among many (I forgot where it is from; searched on yhetil >mailing list archives but cannot find it…) is that Steve George’s user >survey [1] indicated users want to be told that there is a third-party >channel where users can get nonfree drivers to make Guix support >graphics, wifi on more kinds of hardware. Savannah does not (really?) >allow telling that to users. (This seems not quite true, I think.) >This is the only indication of leaving GNU that I know of. > > >> Guix has several drawbacks that, while trivial, make it worse than >> Fedora Silverblue: >> >> * Guix asks for my LUKS password twice > >Not sure of the current situation, but this was because GNU GRUB lacked >support for passing on the unlocked LUKS device with a secure key >derivation function or some such thing. The fix should be made >upstream. > > >> and has no Plymouth screen for >> entering the LUKS password. >> * Guix is slow at package management, even slower than DNF. > >Git-based Guix pull is slow because of Git, yes. But it must use a big >Git repo for its reproducibility, transactions and it uses only one big >slow repository because its package dependencies are so intertwined. > > >> * GNU Shepherd is immature and hard to use. >> * Guix uses more resources (disk space, processing power) than >> conventional distros. > >Except for guix pull and similar commands, is that really true? The >installed software is like in other package managers. > > >> * Guix inherits legacy practices from Debian-based distros >> * X11 should be Wayland >> * ext4 should be btrfs or XFS >> * Docker should be Podman > >This info is outdated when you use the latest Guix from the website or >after you guix pull. GNOME on Guix System uses Wayland. There is btrfs >and podman support. But GNOME Wayland is not the default in official >releases yet when not upgrading. > >Regards, >Florian > >[1] >https://guix.gnu.org/de/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/ > Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Suhail Singh writes: > 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 may not? That, and they have the freedom to not worry if it’s costing them a bit too much, both financially and workload wise. I don’t think any of the kernel subsystem maintainers are heavily working on the infrastructure, it is simply provided to them from Linux Foundation. I think if a lot of our infrastructural worries could be handled by some other entity while the committers focus on contributing to Guix, it’d been much easier. As much as we like to talk of Savannah being unstable, it is managed by less than 5 people at FSFSysOps. Last month I recommended to communicate or work with them[0], but I don’t think anyone wanted that. The degree to which a workflow is smooth depends not only on the workflow itself but on how it’s being supported. [0]: https://yhetil.org/guix/177b8808-9d2b-43ed-bc6d-02f1dac36...@subvertising.org/ -- Divya Ranjan, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Re: [GCD] Deliberation on: Migrating repositories, issues, and patches to Codeberg
I support. On 23 April 2025 09:10:50 GMT, "Ludovic Courtès" wrote: >Hello Guix, > >It’s been two months since we started discussing GCD 002, entitled >“Migrating repositories, issues, and patches to Codeberg”. Its final >version is attached below. > >In accordance with the GCD process, team members have until May 6th to >participate in deliberation by sending one of the following replies >(quoting the GCD process): > > - “I support”, meaning that one supports the proposal; > - “I accept”, meaning that one consents to the implementation of the >proposal; > - “I disapprove”, meaning that one opposes the implementation of the >proposal. A team member sending this reply should have made constructive >comments during the discussion period. > >Thanks in advance, >Ludo’. > Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: Deliberation period for GCD 003 "Rename the default branch" has technically started
I disapprove. On 21 April 2025 14:07:14 GMT, Liliana Marie Prikler wrote: >Hi Guix, > >as the date for the GCD 003 was set to February 18th, the discussion >period actually ended on Saturday already. I have incorporated some >changes on Sunday to realign the proposal with GCD 002 (the Codeberg >one), but barring any emergency changes there, GCD 003 is now to be >considered final. > >As outlined in GCD 001, please respond to this mail with one of the >following: > >- “I support”, meaning that you support the proposal; >- “I accept”, meaning that you consent to the implementation of the > proposal; >- “I disapprove”, meaning that you oppose the implementation of the > proposal. > >To count my own vote, I support the change of the default branch name >to “main”. > >Cheers > Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: [GCD] Rename “main” branch
I hear you Christopher. I personally am not on board with this either. And as an anarcho-communist politically who detests any form of authoritarian structures, I find this move to be misled in the pursuit of any actual liberation. I wish the contributors here actually dealt with history critically, and studied critical race theory. I wish I could take this as anything other than merely a performative posturing to "look inclusive", but don't we see those things already in the activities of our enemies (Microsoft, Google etc.)? The sad fact is that, the critical disposition is really absent. I personally care more about that and not what name the branch has. Any system without enough internal criticism is bound to either dissolve or eventually form an authoritarian structure. I hope at least some of us can keep such a disposition. I cannot really give a crash course on critical (race) theory, but I'd end this mail with one of my favorite quotes from Frantz Fanon, one of the people who actually cared about liberation from racism, probably more than any of us: "I am a man, and what I have to recapture is the whole past of the world. I am not responsible solely for the slave revolt in Santo Domingo. Every time a man has contributed to the victory of the dignity of the spirit, every time a man has said no to an attempt to subjugate his fellows, I have felt solidarity with his act. In no way does my basic vocation have to be drawn from the past of peoples of color. In no way do I have to dedicate myself to reviving a black civilization unjustly ignored. I will not make myself the man of any past. /.../ My black skin is not a repository for specific values. /.../ Haven't I got better things to do on this earth than avenge the Blacks of the seventeenth century? /.../ I as a man of color do not have the right to hope that in the white man there will be a crystallization of guilt toward the past of my race. I as a man of color do not have the right to seek ways of stamping down the pride of my former master. I have neither the right nor the duty to demand reparations for my subjugated ancestors. There is no black mission; there is no white burden. /.../ I do not want to be the victim of the Ruse of a black world. /.../ Am I going to ask today's white men to answer for the slave traders of the seventeenth century? Am I going to try by every means available to cause guilt to burgeon in their souls? /.../ I am not a slave to slavery that dehumanized my ancestors. /.../ It would be of enormous interest to discover a black literature or architecture from the third century before Christ. We would be overjoyed to learn of the existence of a correspondence between some black philosopher and Plato. But we can absolutely not see how this fact would change the lives of eight-year-old kids working in the cane fields of Martinique or Guadeloupe. /.../ I find myself in the world and I recognize that I have one right alone: That of demanding human behavior from the other." Frantz Fanon, "Black Skins, White Masks" (1952) On 18 February 2025 15:50:25 GMT, Christopher Howard wrote: >Personally, I believe the whole push to switch from "master" to "main" is >politically correct nonsense, and a waste of time. Obviously a "master" branch >in repository has nothing to do with slavery or political perspectives, but >DEI proponents have a compulsive desire to eradicate from society and language >anything that has some vague connection to what they find displeasing. > >If "main" is the default for new git repositories, I don't care and that is >fine with me, but I see no need to rename leading branches on any existing >projects. > >-- >Christopher Howard > Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
o from there, can be decided upon how good the litmus test goes. [0]: https://codeberg.org/api/swagger#/repository/repoCreatePullReview Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
enabled. Whoever wishes to contribute, can create an issue, or fork and make a pull-request directly on Codeberg with their desired workflow (which arguably is largely the web approach). Here we have a committer or two to handle the Codeberg repository, label issues, and organize things, but *not* for reviewing patches. Instead, we host a backend service that regularly checks the Codeberg repository for any new issues or PRs and then communicates to us through the Codeberg’s Forgejo API [0] the content of said issues and PRs. The data received from the API then gets directed to our Debbugs or Mumi backend, which parses the information from it and opens a new Debbugs issue for it. Thus, for every issue opened on Codeberg, we have a mirrored Debbugs issue, and same for PRs where the diff can be then parsed into a valid patch. To be noted that such mirroring is strictly one-directional initially, every issue opened previously or opened later shouldn’t get mirrored into the Codeberg repository. If we assume that only committers are the people fluent and wanting of email-based workflow, the new Debbugs issue would only be created by them, while we encourage newcomers to always report through Codeberg’s issue tracker. Since Codeberg already allows to communicate in issues over email, i.e. you can respond to someone in a particular issue over email, this shouldn’t be too difficult to arrange. Newcomer opens issue #xxyz -> Debbugs/Mumi mirror it and create x...@debbugs.gnu.org -> Interested committer responds to it over his desired email workflow -> It reaches the newcomer without him having to open email. I argue the same workflow can be replicated for pull-requests as well, without the need for any "merge button". We remind ourselves that the need for a PR/GitHub/Web workflow is to cater newcomers, who have nothing to do with merge issues but everything to do with forking and contributing changes. Ergo, the only part of the PR workflow we need is it’s creation, not the entire package of fork->pull->merge->commit. The latter two are to be under the responsibility of committers, who will not have to change any part of their workflow. As described above, they’ll get the PRs rendered to them as good ol’ git patches, over mail and they can apply them, work on merge issues and get back to the newcomer contributor over email. The only additional part in the case of PRs would be the need to replicate the patches also across guix-patches mailing list. I know this requires some setting up, but we need such time and effort in any case if we decide to migrate and not fall into the issues Ekaitz and Maxime pointed out. With the help of Codeberg people for their API, and the knowledgeable people on Debbugs such as Felix, Arun, Ricardo et.al, this might be a feasible task. I am also willing to contribute in whatever way and means possible, since I’m slowly working myself towards contributing more and more to Guix. And even though I’m not a committer, I retain the email-based workflow through Gnus and debbugs.el. So, it will help me as well. Let me know what you think. [0]: https://codeberg.org/api/swagger Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Hello Ricardo, >> We have a *humongous* backlog of patches, [...] > >> [...] we host a backend service that regularly checks the Codeberg >> repository for any new issues or PRs and then communicates to us >> through the Codeberg’s Forgejo API [0] the content of said issues >> and >> PRs. The data received from the API then gets directed to our >> Debbugs >> or Mumi backend, which parses the information from it and opens a >> new >> Debbugs issue for it. Thus, for every issue opened on Codeberg, we >> have a mirrored Debbugs issue [...] > > So at the end we'd have an even larger backlog of patches, and spread > across two systems...? [...] We would have that regardless of whether one follows my proposition or not. The old backlog is going nowhere. Even if we make a full-switch to Codeberg immediately, the committers would either have to work on both things tenaciously as they (committers such as Maxime) get used to an entirely new workflow. What is the probability that such an immediate increase in responsibilities will not lead to a further increase of existing backlog? I don’t think anything can solve the backlog quickly, what I proposed was with the intent of solving the issue of committers not having to learn a new workflow altogether to work on the backlog, ergo, not having another hurdle to it amidst a list of others. > And where do we source the time and motivation > to hack on yet another piece of software? Outside contributions to > mumi have been *very* few in all these years; that's not for a lack of > problems we've had with the system, and for once it's not for a lack > of > review either. Indeed, that is a problem. It was a mere proposition, so if enough people want it to happen, we can have it :) > As a long time contributor with commit access I have the impression > that > people new to Guix hold the assumption that the current system and > workflow works for long time contributors. I may just be wildly > incompetent, but for me it most assuredly does not work in enabling > reviews. I mostly review patches that were sent to me directly or > that > happen to solve a problem I'm trying to solve as part of my > maintainance > work. I acknowledge your experience, but we heard from others such as Maxime how to them it might require learning and changing the workflow. So the people for whom the email-based workflow works isn’t really a null set. > The haphazard GNU fork of Debbugs also lacks a number of features, has > odd unaddressed bugs, lacks people who even understand in what ways it > differs from the Debian version, lacks people working on improving it > and addressing these issues. (There is literally *one* person who > keeps > the lights on.) > > It does not even do simple things like delivering notifications to > *everyone* who participates in an issue discussion. This is the > reason > for the sudden eery silence that can be seen in many issues. > > I honestly have my doubts that the move to Codeberg would > automatically > solve all of my workflow issues, but let's please not eulogize the > email-based workflow too much. It makes sense to me to base our > efforts > on a system that is *actively* developed by a *team* of aligned free > software hackers. > > I don't see an active future for the GNU fork of Debbugs, and I think > it > is not a good use of our time to work on a system that won't improve > unless we burden ourselves with even more work (like taking over > hosting > and administration). I'd rather work on Guix. By all means, but I think you are confusing a plea for not breaking certain people’s workflow as a means to "eulogize" something. The goal here is to simply not put enough pressure on people who already have a lot on themselves to change their workflow in order to continue contributing to Guix. And my proposal is targetted towards an eventual move to Codeberg, just a more gradual approach, based on empirical feedback and with some time to clear the existing backlog and to learn the new system. Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Hello Suhail, > "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? > Despite me being in support of a workflow that doesn’t require opening a browser, while thinking about how Linux kernel does it and Guix, I had to realize that Linux gets a *lot* more in funding and infrastructure than Guix. Of course part of it is because of sheer technological necessity of handling a 30M LOC project that’s used by everyone. But it’s also because they *can* get it, through the help of Linux Foundation and so on. I don’t think we have that many degrees of freedom here, so we need to be careful about our resources, and the work of volunteers and committers. I would be open to a consideration of using BugZilla or Gerrit for that matter, even though I’m not used to them, the possibility of working with them without a browser, motivates me to learn them. Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Re: On a Guile-based Build-Tool complimenting Guix
To keep others in the loop, Olivier and I had a discussion off-the-list on such a build tool. Soon we'd be creating a rudimentary repository and experimenting the tool with different packages. Hopefully we can come up with some interesting outcomes that can be used upstream for Guix. Regards. Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: [GCD] Rename “main” branch
The absurdity of this claim relies on the assumption that the burden of self-reflection is supposed to be _only_ on the shoulders of Christopher, or anyone who doesn't agree with those who "feel the need". What is stopping those who so strongly do feel the need for this change to _also_ undergo a similarly critical self-reflection of their position? Regards, On 20 February 2025 21:32:46 GMT, Vagrant Cascadian wrote: >On 2025-02-18, Christopher Howard wrote: >> Personally, I believe the whole push to switch from "master" to "main" >> is politically correct nonsense, and a waste of time. Obviously a >> "master" branch in repository has nothing to do with slavery or >> political perspectives, but DEI proponents have a compulsive desire to >> eradicate from society and language anything that has some vague >> connection to what they find displeasing. >> >> If "main" is the default for new git repositories, I don't care and >> that is fine with me, but I see no need to rename leading branches on >> any existing projects. > >The fact that you see no need when obviously others do, might be time >better spent, in my humble opinion, by asking questions (internally or >externally) than making dismissive comments. > > >live well, > vagrant Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: Team members: create and share your Codeberg account
Divya Ranjan in Emacs, Haskell and Rust teams. https://codeberg.org/divyaranjan Regards, On 26 May 2025 12:34:39 GMT, "Ludovic Courtès" wrote: >Hello, > >Noé Lopez writes: > >> Is it possible to do a similar thread for non-committers to get added to >> our teams? > >Yes, definitely: if you’re a team member and not a committer, please >share your Codeberg account name here! > >> AFAIK, getting added to a team on Codeberg does not necessarily give >> extra permissions. And since I am a member of the gnome team, I would >> like to get added! > >That’s my understanding too. > >Thanks, >Ludo’. > Divya Ranjan, Mathematics, Philosophy and Libre Software
Re: GCD005: Regular and efficient releases (consideration/decision)
I support. On 23 June 2025 14:43:14 GMT, Steve George wrote: >Hi all, > >After a good long discussion I'm moving GCD005 to Deliberation. > >The final version is below and can be found on Codeberg: > > > https://codeberg.org/guix/guix-consensus-documents/src/branch/main/005-regular-releases.md > >This means that team members have 14 days to send one of the following replies >on the patch-tracking entry of the GCD: > >- “I support”, meaning that one supports the proposal; >- “I accept”, meaning that one consents to the implementation of the proposal; >- “I disapprove”, meaning that one opposes the implementation of the proposal. > >The Issue is: > >78...@debbugs.gnu.org > >https://issues.guix.gnu.org/78332 > >In terms of next steps beyond the GCD, Efraim has said he's willing to be the >next Release Manager, and both myself and Andreas have committed to help out - >I'm sure there will be others! > >Thanks so much! > >Steve / Futurile Divya Ranjan, Mathematics, Philosophy and Libre Software
