<zamfofex>From what I understand, Mes is written in a smaller subset of C than MesCC supports. So that it can be bootstrapped from a simpler C compiler, then used to run MesCC to compile programs that aren’t written in such a subset.
<janneke>on core-updates, mes is bootstrapped from m2-planet
<zamfofex>Also: Is there any reason there needs to be a C *compiler* early on, rather than a C *interpreter*? It could be made into a simple wrapper that simply embeds the source code in the generated output file (which could be a shebang executable) then interprets it.
<zimoun>sneek later tell civodul: the recent update a couple of days ago to manifest at version 4 leads to a severe bug: it breaks the time-machine; it means once pulled, it becomes impossible to go back. See https://issues.guix.gnu.org/56441
<sneek>civodul, zimoun says: the recent update a couple of days ago to manifest at version 4 leads to a severe bug: it breaks the time-machine; it means once pulled, it becomes impossible to go back. See https://issues.guix.gnu.org/56441
<zamfofex>jpoiret: Ough this not to be resolved by thorough tests? Or am I missing something foundational?
<jpoiret>zamfofex: they'd need to be very thorough, and in a local dev setup it's quite hard to do
<jpoiret>I just realized I forgot to add one paragraph about an example case where it's really hard to test
<jpoiret>the thing is, not everyone will test their patchsets against all combinations of guix pull, guix time-machine, upgraded guix package, etc.
<zamfofex>Would it be unreasonable to have ‘guix pull’ optionally (though by default) only work if there is a substitute? Then, if something breaks in a commit, at least ‘guix pull’ wouldn’t be affected.
<jpoiret>the point of my point was rather that we should end up with a solution that makes everyone more confident about the patchsets they merge
<jpoiret>(ie. you don't have to worry about the dozen internal subtleties that interact with each other at the level of building guix)
<jpoiret>"it builds once on my setup so it builds the same in all contexts" should be something we can rely on
<zimoun>jpoiret, I agree. To me, the only pragmatical fix with the resource we have is to decouple where devs push and where users fetch. Currently, both are master.
<zimoun>And we could have master for devs, and main for users; where main is lagging by 7 days from master – 7 days, the mean time for build farm to build and time for dev to fix.
<jpoiret>zimoun: i don't think that would even resolve much! Few people (mainly maintainers) test the other branches before big merges, and if we had a 'dev' tag, developers wouldn't test more, and the bugs would just appear with a delay
<jpoiret>many of these bugs are not discovered by CI
<zimoun>Well, cbaines proposed something similar long time ago; decouple what is “production” to what is “testing”. Today, we “test” directly with the “production”. For sure, sometimes the tests fail. ;-)
<jpoiret>i think with `guix pull` generations and particular commit pinning for channels we should keep the 'move fast and break things' approach, but users should be made more aware of these options
<jpoiret>even I forget that you can rollback the guix pull generations
<zimoun>No, for you, it would change nothing, you would still use what I named master. However, people wanting more “stability”, they would use “main”.
<jpoiret>what I'm advocating is not really directly about stability of master, but rather of a way to reduce the possible bug sources to a minimum
<zimoun>I do not think rollback is an acceptable fix. I have many examples where the generations had been GC before discovering an issue.
<jpoiret>i never gc my guix pull generations because i simply forget
<zimoun>to me, stability is about less possible bugs. ;-)
<zimoun>As I said, I am not aware of any complex system that makes their test directly in production. It is the Guix workflow though. :-)
<zamfofex>Would it be unreasonable to want pinned minor versions? E.g. consider “Guix 1.4.0” then “Guix 1.4.1” then … then “Guix 1.4.87”, etc. Or conversely to waive the concept of versioning for Guix.
<zimoun>zamfofex: I think it is too much work compared to the manpower the project has at hand.
<jpoiret>zamfofex: well, versioning is already a bit useless in Guix. 1.3 for example only matters when installing
<jpoiret>other than that, there's no difference between 1.3 and any other commit
<zamfofex>zimoun: Would it really take more than just merely labelling the commits as such?
<zamfofex>I was just thinking out loud, by the way. It’s just strange that as it is, versioning has no big role in Guix. It feels like it either should be given a significance, or abandoned in favor of fully adopting the “rolling release” model.
<jpoiret>the only 3 pros of having point releases i see right now are: stability of installer (ideally, it should follow the same model as the rest of guix, so we should expect it to be stable at any given time), announcements of new features/big bug fixes and being able to advertise them
<jpoiret>wrt the installer, imo the latest installer is way more stable than the 1.3 one right now, even though there are still a couple of issue
<jpoiret>right, and it's pretty useful, you don't want to sift through git log just to find roughly when the feature was introduced
<zimoun>jpoiret: to me, the main point of Guix release is about communication and announcements; because it appears on LWN and elsewhere.
<zimoun>One of the issue is that we do not have the manpower to release often, say twice a year. Similarly as core-updates merge BTW.
<cbaines>hopefully that situation will improve if we can do more continuous quality assurance
<zimoun>Yeah, but in the meantime, we should improve the current workflow.
<zimoun>Both are not opposite but complementary, IMHO :-)
<cbaines>I think improving the workflow is how we get to doing more continuous quality assurance
<zimoun>Moreover, using Guix in production in my lab, one of the main drawback is the lack of predictibility of “guix pull”; for instance, after a recent “guix pull”, most of the Julia packages were lacking. So it is painful (rollback, time-machine elsewhere, etc.).
<zimoun>About workflow, I mean: where patches are pushed and where users pull.
<zimoun>It is not possible to have a continuous quality following the current rate of commits.
<cbaines>zimoun, I'm hoping very soon to start building packages from patches on bordeaux.guix.gnu.org, which should be a step towards both avoiding breaking things, and ensuring substitute availability when changes are merged
<zimoun>cbaines: I agree and I am very thankful about all ths tough work. I remember the first time we met, back on Dec. 2018, you were already busy with this work. I mean, despite all the hard work over the years, we are not there, so maybe it means CI is not enough to fix all the isssues we are discussing. Well, I do not really know. Hard topic. :-)
<cbaines>zimoun, I'd like to believe that it's taking so long as I'm not able to put that much time in, rather than a problem with the approach
<cbaines>another reason why it's taking so long is that I'm flip flopping between doing things quickly, and doing things properly. Packages from patches were being built in the past, but since then, I've been putting time in to setting up bordeaux.guix.gnu.org, wrangling hardware and writing the nar-herder
<zimoun>cbaines: yes, I totally agree. And you already made hard (under-the-hood-) work as Data Service, instance of Patchwork, etc. Somehow, my point is: I think that the manpower and resource is a parameter to find the implementation that works for the project.
<zimoun>cbaines: No blame! :-) It is not your responsabilty but a collective one.
<cbaines>hopefully some of these investments will start to be realised soon, as all of this stuff should start to come back to benefit testing patches
<cbaines>on top of the value it has for substitute availability for example
<roptat[m]>if you pull from two weeks aho, you get the issues from two weeks ago, so you should have exactly the same probability to have issues with master and pulling from two weeks before
<roptat[m]>unless the number of issues is constantly increasing ;)
<cbaines>I think the theory here is that other people are hitting and fixing issues within that 2 week period
<cbaines>actually... I see your point, you're delaying getting the issues, but also delaying getting the fixes
***califax_ is now known as califax
<roptat[m]>right. at least you're more likely to get substitutes
***califax_ is now known as califax
<bost>Hi. It looks like 'guix home reconfigure' keeps on adding fish-shell abbreviations instead of recreating them. IOW 'guix home roll-back' and/or 'guix home switch-generation' don't correctly restore the previous / desired state.
<necrophcodr[m]>Does Guix have a built-in Nix Flakes alternative that I'm not aware of? Or is there a smart way of defining an environment akin to what a Nix Flake would contain? It doesn't have to be as expansive as flakes, of course, as I'm very much mostly looking for an easy way to setup a development environment for easy reprodicibility, that goes beyond simply defining a package manifest or a list of packages.
<civodul>necrophcodr[m]: hi! to reproduce your environment, you'd capture the channels in use with "guix describe -f channels"
<civodul>and then you'd pass that to "guix time-machine"
<sk>I'm having trouble getting exwm to load/merge my `~/.Xresources` (or execute `~/.xinitrc` or `~/.xprofile`). For xfce, it's quite simple as `startxcfe4` calls the included `etc/xdg/xfce4/xinitrc`, which runs `xrdb -merge` on, among others, `~/.Xresources`.
<apteryx>sk: I'm guessing exwm must have its own rc file?
<sk>apteryx: `exwm.desktop` calls `emacs-exwm-package/bin/exwm`, which runs `xhost-package/bin/xhost +SI:localuser:$USER` and then `dbus-package/bin/dbus-launch [...] emacs-package/bin/emacs [...]`. Did you mean these by rc file?
<apteryx>OK. I don't know exwm; I run ratpoison and it uses an ~/.ratpoisonrc file; but in my case I do not need to be X-related stuff in that file, as it honors .xsession
<sneek>acrow, trevdev says: Oh it absolutely works. Part of what I like about guix is that it is portable. I am on Guix System now. If there were any reason for me not to be, I have my config :) I just feel challenged by learning the packaging, mostly.
<roptat>unmatched-paren is technically correct in most contexts, just not for the staging that happens in guix packages
<unmatched-paren>Was this kind of confusion/unintuitive behaviour one of the reasons for switching to gexp syntax?
<abrenon>then it means I don't understand what is going on here : (
<chumpy>hey everyone. I'm trying to build a project and I'm not real sure of what I'm doing. The project is failing to build on a 'cc' command. I have gcc-toolchain installed. Do I need to link cc to gcc somehow?
<abrenon>oh right, I had that once, yeah, gcc-toolchain doesn't provide a binary called cc
<unmatched-paren>rekado_: how does gwl register itself as a guix extension? i don't see anything special to do that in the gwl makefile or recipe, but my package that also installs an extension into $out/share/guix/extensions doesn't get registered
<unmatched-paren>are you just supposed to set GUIX_EXTENSIONS_PATH manually until someone figures out automatic loading?