<lfam>Paging roptat re: Gradle <jeko>rekado: special-files-service-type feels easier to understand to me right know ! thx I keep reading about plain-file or local-file <rekado>jeko: note that this is for global system files, not for user files. <avalenn>When doing "make check" I have failures related to store-protocol-error. e.g. <avalenn>#<&store-protocol-error message: "derivation `/gnu/store/n519whhwnrm4ps0ibnx39q41frmljxi2-tar.drv' has incorrect output `$WORKDIR/guix/test-tmp/store/rpxddhq13992fhc9wwhwgalz7b63w0s3-tar', should be `/gnu/store/k015iy4mrrbd5vf2ihz40ai8swlvcj2p-tar'" <jeko>rekado: that's fine ! i only use root for this experiment <lfam>I think CI is having trouble registering new store items <lfam>However, when I do `guix build /gnu/store/4xn3gvwlqq2lz70133s8wwb84gkdxmcy-borg-1.1.16.drv` on the Berlin server, it starts building <civodul>lfam: it's just that it doesn't keep things in the local store for very long <lfam>Oh, they are supposed to go to the nginx cache? <rekado>perhaps it should be configured to download substitutes from itself … <lfam>Well, I checked on CI because I didn't get a substitute <lfam>I mean, I didn't get a substitute on my own computer <civodul>oh, so it never made it to the head node, then <civodul>would be worth discussing with Mathieu <civodul>i wonder if it's possible for a derivation to be built, retrieved, and then gc'd before "guix publish" has baked it <hpfr>rekado: re: format=flowed, yes mu4e can do that, but you have to compose your emails with long lines first and it will reflow on send. but I think f=f creates issues with inline git patches, so maybe better not to <roptat>morgansmith, we don't have gradle because it's not bootstrap <roptat>usually, you can use a binary of gradle to build, but sometimes (esp. android), it also downloads native libraries (.so, and not simply .jar files) that are not compatible with guix <roptat>alright, we have entered string freeze, please refrain from any modification to the strings of guix and guix-manual until the release :) <lfam>Thanks for managing the translations, roptat <lfam>That patch changes the manual <lfam>What are the consequences of pushing it now? <lfam>I suppose we could push the patch without the docs changes <roptat>I can accept it if you push right now <roptat>but basically, if you push the doc changes, it means translators who thought they finished the work will have some untranslated sentences in the release manual <roptat>so, if you can postpone the patch until after the release, let's do it, but if it has security implications, let's not wait and push it now <roptat>or if it's fixing something important, etc <lfam>IIUC, the postgresql service defaults are broken without it <roptat>so, if you push it in the next 2 hours, ping me, we can do it <lfam>Sorry to cause last-minute complications <roptat>it's not hard to update the strings, but it's not nice to translators <roptat>we announced "we give you x days to translate" and we pull the rug under their feet ^^' <jgart[m]>Hi Guix! Is there a way to build with --no-substitutes while only pulling substitutes for the build tools/toolchain? For example, I only want to build direct dependencies of the vis package, the one in (gnu packages text-editors), on my local machine. <roptat>jgart[m], no, it's a global switch, on or off <roptat>you could rebuild locally with "check", if you list dependencies of the package, that might work <morgansmith>I think I knew this at one point, but how do you rebuild a package that doesn't think it has changed but has? <roptat>what do you mean "it doesn't think it has changed"? <morgansmith>I changed the version in gnu-standards and rebuilt it but the revision doesn't use the version. Then I went and changed the revision but it doesn't think anything has changed <morgansmith>*anything has changed since I built it with only the version changed <morgansmith>also on a slightly unrelated note, I don't actually know if an update for gnu-standards is available or not because I'm finding cvs very confusing <roptat>ah, not in the source because it's a fixed-output derivation: the declare hash is the only thing that is taken into account for the store hash <roptat>you should change that declare hash (change the initial 0 to 1 or 1 to 0) <roptat>you'll get the wrong one and it'll force it to download again <morgansmith>:D thanks so much! That makes a lot of sense really! <roptat>morgansmith, fixed-output derivations are a bit difficult to work with, it's nice to have, but it can backfire <roptat>as you noticed, the result only depends on the hash, it's "content-addressed", so if you already have a derivation with that declared content, guix doesn't download anything (it already has the expected result), and it doesn't check <roptat>so sometimes you silently introduce an error that only manifests on others systems because you make them download something different <morgansmith>I mean wouldn't they notice really quickly when they get a hash error? <roptat>yeah, they would, but you would have pushed an incorrect commit already :) <jgart[m]>roptat: Do you think it would be nice to have a cli option for filtering out groups of dependencies that you'd prefer to build locally versus acquiring them via substitutes instead of having a global on/off switch? <roptat>that's usually not a problem if the filename contains the version, as there's usually only one file per version you may want to download, but if that's not the case (for instance git-fetch names the output checkout by default) <roptat>maybe your package doesn't have an explicit filename? Since you said you changed the version? <roptat>if it has a version, it'd be best to use (file-name (git-file-name "gnu-standards-src" version)) <roptat>where you would have only one place where you define version, to make sure it's updated together <morgansmith>nah this is cvs not git. I greped for other cvs packages and found this: (file-name (string-append name "-" version "-checkout")) <roptat>interestingly, that's exactly what git-file-name does :) <morgansmith>ok setting the version to 2021-01-01 or 2021-06-21 gives me back the same hash. I don't like this <lfam>jgart[m]: Try this: `guix environment --no-grafts foo -- guix build --no-grafts --no-substitutes foo` <lfam>It's not exactly what you asked for (build first-level dependencies) but it shows how to separate substitutable builds <lfam>You could combine it with `guix build --no-grafts --dry-run foo` somehow, or parse the dependencies from `guix show foo` using recsel from recutils <morgansmith>I finally figured out the latest change to gnustandards was on 2020-11-24 but in order to get that version from cvs I have to use revision 2020-11-25. very intuitive. <Frosku>I'm on a dual GPU laptop (intel + nvidia discrete) and having serious issues getting my external monitor to work. It displays text during init but then entirely disappears in X (and past modesetting). Any ideas? <Frosku>Documentation seems thin on the ground. <Frosku>xrandr only shows one monitor connected (laptop screen) <Frosku>Hey, sorry about the bounce. I'm on a laptop with Intel + discrete (nvidia, unfortunately) graphics. I've just tried plugging in an external HDMI monitor -- the monitor shows some text during init so I know the cable works, but then seemingly vanishes from existence once I get into X (might actually be once I get past kernel modesetting). xrandr shows only one monitor connected. Any ideas? <Frosku>lsmod shows nouveau and i915 running, xrandr --listproviders shows two providers. <Frosku>lspsi | grep VGA shows both devices (Intel Corporation UHD Graphics and NVIDIA Corporation TU117M [GeForce CTX 1650 Ti Mobile]) ***iyzsong-- is now known as iyzsong-w
<terpri>nij, it's not packaged but there's the option of just using quicklisp by itself (with a guix-packaged CL implementation), which is what i do <terpri>in theory someone could probably write a "guix import quicklisp" auto-importer to produce corresponding guix packages <terpri>nij, though i'd add that there are 415 "cl-*" packages in guix so it may be worth looking at the relevant scheme files to get an idea of how difficult CL packaging would be for your usage <jgart[m]>lfam: thanks for the tips. I'll try your suggestion soon. <jgart[m]>nij: what lisp packages are you missing? <rekado_>we don’t have a package for GNAT (the Ada compiler). Is this due to bootstrapping problems…? <rekado_>I’m asking because it’s needed for building coreboot. <rhou[m]>why are services not organised in channels? <rhou[m]>rekado_: If want to add for example an experimental service which is not yet added to guix <rhou[m]>and in a sense they are very similar to packages <rekado_>rhou[m]: you *can* do that with channels. <rekado_>rhou[m]: same as for packages. You create a module that exports your values. <rekado_>rhou[m]: a channel is a collection of Guile modules exporting values. <rekado_>rhou[m]: so to define a service you need to create a Guile module that exports a service value. <rekado_>rhou[m]: to use it you need the channel and then refer to the module by name to access its exported values. <rhou[m]>rekado_: thanks that was exactly what I wanted to know <rhou[m]>rekado_: Is there an example somewhere? ***apteryx is now known as Guest39774
***apteryx_ is now known as apteryx
<abcdw>Is there any documentation workflow manual? Or I just update texi files and call `make doc/file.html` and check the results? ***iyzsong-- is now known as iyzsong-w
<abcdw>leoprikler: No fancy guide on documenting workflow for me :'( <rekado_>abcdw: I rarely ever build the raw HTML *raghavgururajan wakes up and rubs his eyes <leoprikler>final w.r.t. what else appears in the review process <rekado_>likely culprit: a247f5c7537df7e0c09051ba22d5c95eb08f48b9 <efraim>sneek: later tell morgansmith I checked the bug, I also don't see my response email to it. Perhaps it got lost in a mail queue, it was supposed to close the bug. <canant>As your suggestion, I've just changed the title assignment on the html.scm. <canant>- `((title ,(string-append title " - Guix Data Service"))) <canant>- `((title "Guix Data Service"))) <canant>+ `,(string-append title " - Guix Data Service") <canant>What do you think of this version of the assignment? <rekado_>I’m about to push a fix to guix-past, using srfi-1:delete instead of delete *rekado_ looks if the guix-bimsb channel is also broken now <civodul>'delete' should definitely be bound since it's provided twice <civodul>i think a better fix would be to use (gnu packages) instead of (gnu) <leoprikler>raghavgururajan: congrats on getting commit access <civodul>rekado_: np, thanks for the quick reaction <raghavgururajan>leoprikler: I think it will be very difficult for me and anyone willing to work on gnome, if we are going to merge the patches to different branches. It will not be easy to rebase wip-gnome with multiple branches. <pineapples>Wish me luck, everyone; I'm planning to make my first contribution to GNU Guix today :') <raghavgururajan>So I think, let all patched first come to guix-patches, and then after review process we'll merge to wip-gnome. From wip-gnome, any commiter who has time can cherry pick and merge to master or c-u ot staging. <leoprikler>Cherry-picking is the biggest "fuck you" when rebasing, so I can't recommend that workflow. <leoprikler>Let's also not forget, that we don't necessarily push your patches to staging as-is, so you need to be extra careful. <canant>pineapples Good luck and congrats :) <leoprikler>Hmm, in that case it should be possible to merge master or staging into c-u and then rebase wip-gnome onto the merge commit. <leoprikler>(well, not that wip-gnome will have much stuff designated for master, but still) <raghavgururajan>Here is the flow cycle I suggest: [1] Contributor will pull wip-gnome [2] contributor will work [3] contributor will send the work to guix-patches [4] reviewers will review and/or send modified patches [5] committers will push the reviewed and corrected patches to wip-gnome [6] contributors back to square one. [0] As we find fit, we merge select patches from wip-gnome to master, staging or c-u. <lle-bout[m]>Not sure there's any non-committer contributor now that you got it <lle-bout[m]>For any external contributor, unless reviews are handled in a timely manner and consider avoiding having to rebase these patches constantly for the contributor, any external contribution will be painful. <raghavgururajan>Yes, but I won't be pushing any patches to wip-gnome, until it is reviewed by atleast two other commiters. <raghavgururajan>For now, I say we'll try merge gst v2 patches sent by leoprikler, to wip-gnome. <raghavgururajan>So that I can pull and rebase my local wip-gnome copy and work on next things. <efraim>Hmmm, problems with 64/128 bit long longs on core-updates on ppc <leoprikler>I'd still wait for more reviews before merging those patches to wip-gnome upstream <lle-bout[m]>efraim: Glibc 2.33 upgrade recently, also update to GCC 8, look at Glibc 2.33 changelog for info and possible new requirements also <raghavgururajan>I could continue working locally, but if the patches gets modified before going into wip-gnome, I'll have to face many merge conflicts. <lle-bout[m]>raghavgururajan: As long as such doesnt make this GNOME upgrade simply grind to a halt and everyone give up <leoprikler>[5] Committers push the reviewed patch to the designated branch (which may no longer be wip-gnome). *raghavgururajan 's head spins *raghavgururajan looks at ncks for holy water <lle-bout[m]>I think that wip-gnome can be rebased at any time so it's not such a big deal if it has commits of varrying quality in it, it can always be handled and rebased before final merge, I just hope that collaboration is efficient for everyone. <leoprikler>Fair enough, if wip-gnome is properly rebased just before merge to c-u, then everything is fine. <leoprikler>I just feel like it might be more headache to delay such rebasings. <lle-bout[m]>leoprikler: It could, I don't know what's the biggest headache, people must be very explicit in comments or commit messages <lle-bout[m]>I think that once GNOME 40 works there will be such an enormous motivation boost for everyone that maybe it wont be an issue <leoprikler>But going from "it works" to "I have to rebase it until it works again" might be a pain in and of itself :P <lle-bout[m]>At the same time, it's important for patches to be merged early so they don't suffer conflicts, and it's also important these patches hold up quality-wise <efraim>lle-bout[m]: i'll try using the powerpc64le flag from gcc for powerpc also, see if that takes care of it. <efraim>re gnome-40, I'd suggest building it against master to minimize toolchain rebuilds and then merge into staging/core-updates when it's ready <lle-bout[m]>efraim: On core-updates, GCC 8 upgrade was pending already, do it, for Glibc 2.32 it was already required <leoprikler>fwiw if you stick to the core gnome stack you won't get anything, that can be merged outside of c-u <leoprikler>GStreamer is a bit of an outlier, as it's adjacent to GNOME, but not really GNOME. <raghavgururajan>Regarding [4], due to time-sensitive nature of this work (I can work on gnome, full-time, for one more month, after that my availability goes down), shall we use the 3 values/tries rule used in science? The patches can go to wip-gnome after minimum for 3 reviews by 3 different committers (other than me)? WDYT lle-bout[m] and leoprikler ? <iyzsong>raghavgururajan: sound good, feeling we're on the right track! <iyzsong>to be honest, my workflow is send patches/reviews by emails, then push to the correct branch <raghavgururajan>> efraim: re gnome-40, I'd suggest building it against master to minimize toolchain rebuilds and then merge into staging/core-updates when it's ready <raghavgururajan>This seems to be good idea. Thanks efraim! Shall we kill the existing wip-gnome and re-create it based off master? No changes added there yet anyway. <iyzsong>if the patches are trivial, I push them if no one raise issues. if not, waiting for 1 LGTM from a committer is enough for me.. <efraim>lle-bout[m]: right, I wanted to make sure it was applied before I forgot. I tried gcc-10 and gcc-9 but ran into issues with some packages <efraim>raghavgururajan: it's up to you, I'd re-use the wip-gnome tag and just grab any commits that were added <nij>Hello! Suppose package B depends on A1, and suppose A1 upgrades to A2, and suppose I want B to have both goodies from A1 and A2. Can I let B depend on both A1 and A2, and call the functions in A1 and A2 by their names and versions? <mdevos>nij: that is rather vague. What are A1 and A2? Guile libraries? Shell scripts? <efraim>raghavgururajan: yeah I mean re-create the branch. the WIP branches are OK to rewrite history with. <nij>mdevos: say shell scripts. <nij>I'm trying to compare guix's model with another model.. the question might become too vague.. <roptat>probably not, there would be conflicts when loading the two scripts <roptat>it would work if they had separate files and you'd have B explicitely load each from A1 or A2 <mdevos>IIUC, B is something like (package ... (inputs `(("a1" ,a-1) ("a2" ,a-2)))) <nij>roptat: yeah. I wonder if it makes sense to load the function F in A1 as A1/F, and that in A2 as A2/F <mdevos>you would somehow have to teach the package B to sometimes use A@1, and sometimes use A@2 <roptat>a bit of manual work, but possible if the packages are meant to be used that way <nij>not really a thing guix can solve <nij>it depends on the developers who wrote B <mdevos>if the shell scripts are binaries like "ls", "stat", ... (ok these aren't actually shell scripts), that aren't ‘loaded’ but rather executed as a separate process, then sometimes using coreutils@version-A and sometimes coreutils@version-B should work fine <raghavgururajan>lle-bout[m], iyzsong and leoprikler: Shall we re-create the wip-gnome branch, based off of master, as efraim suggested? Next, are we in agreement to merge the gst v2 patches to it? <iyzsong>gstreamer may go into master without merged into core-updates first, but iirc some gnome updates require glib update, which is only in core-updates though.. <raghavgururajan>Err! yeah. le-bout[m], iyzsong and leoprikler: Let's not re-create the wip-gnome, we have previous changes in c-u. <raghavgururajan>iyzsong: If lle-bout[m] and leoprikler agrees, could you sign-off and merge the gst v2 patches to wip-gnome? If not I can do it. <leoprikler>I'd say keep wip-gnome as close as reasonable to c-u. <iyzsong>raghavgururajan: you can push them, thank you! <leoprikler>btw. you might want to change my signoffs to co-authorings *raghavgururajan is excited <raghavgururajan>Oh. I am use to git apply and commit OR git am, patches that are attachments. How do I do it form patches sent via git send-email? <felipebalbi>raghavgururajan: you can save the email to a file, it'll be an mbox format. Then you can git am as usual <felipebalbi>raghavgururajan: if your email client allows, you just pipe the message to git am as well <felipebalbi>raghavgururajan: saving + git am is probably the way to go, then *raghavgururajan looks at Ken Thompson and Dennis Ritchie, and says "Okay! I get it now." <pineapples>Am I supposed to place my package.scm file in my local guix repository prior to running `make`? <mdevos>pineapples.scm: what are you trying to do? <mdevos>I guess you want something like "guix build -f package.scm" <raghavgururajan>pineapples: No need to create .scm file if you are using local repository. First bootstrap+configure+make then apply to package-definition to relevant .scm module under /gnu/packages. Then run guix build in pre-inst-env. <pineapples>mdevos: Trying to contribute my package declaration to upstream. raghavgururajan: And if it's a separate .scm module (I found no relevant .scm module for my package-definition), just copy and paste it into ../gnu/packages? <pineapples>leoprikler: It is seatd: https://git.sr.ht/~kennylevinsen/seatd. I've already packaged and sucessfully used it for the last 2 months. I already announced that I'd contribute it to the project on this IRC channel weeks ago, but I haven't got onto it until today; I saw that the future sway releases will have a hard dependency on libseat, and figured that I should contribute it to save whoever tries to <leoprikler>perhaps it should go to freedesktop.scm next to elogind? <pineapples>leoprikler: I considered this but decided not to—seatd is not part of the wider freedesktop ecosystem. <leoprikler>Still, having a single file for it when it's clearly related in some sense seems off. <pineapples>..though, libseat, a seat management libarary that is part of my seatd package, supports elogind-backend for systems that don't use `seatd'. <pineapples>..so, this could technically qualify it for the inclusion within freedesktop.scm <pineapples>leoprikler: I'll do as you say; you have the deciding vote, so to speak <BlackMug>i see default packages installed like avahi-daemon , wpa-supplicant... but when i type guix remove avahi-daemon it says not found <leoprikler>2) even if it's your user profile, it may be propagated <BlackMug>what i mean is simple, in debian for example i want to remove x package <siraben>BlackMug: they could be dependencies of packages <BlackMug>yeah but that doesnt make sense if its not be shown <siraben>everything gets put in the store including transitive dependencies <BlackMug>it is in the store but why its not shown when i type guix remove packagename <pineapples>leoprikler: Does it matter after which package-defintion in the freedeskop.scm module do I apply my package-definition? It looks like they are not alphabetically sorted <leoprikler>I suggest putting it close to similar packages, in this case after elogind <leoprikler>Either way, you want to avoid putting them at the end, because that leads to merge conflicts <pineapples>leoprikler: I see. I wasn't aware of this. I'll keep this in mind for the future reference <siraben>BlackMug: if they are no longer referenced you can do guix gc <leoprikler>Doing a 'git pull' locally, everything seems fine. <civodul>roptat: i'm being told we have full Slovak translation for the "guix" domain :-) <leoprikler>also don't forget to use the correct order. if you have it wrong in your file-system bad things happen <pineapples>Is the (guix-support?) field of qemu-binfmt-configuration deprecated? <pineapples>The manual doesn't reflect this, but I'm getting a message that it's an extraneous file initializer <leoprikler>I reviewed and found it was a better fit to staging → hence reparented it to staging. <BlackMug>siraben question how can someone for example remove wpa-supplicant? <siraben>BlackMug: what does guix refresh --list-dependent wpa-supplicant say <leoprikler>BlackMug: See `guix gc --referrers /gnu/store/*avahi*` <leoprikler>If any of the returned store paths match a package you have installed as user or in the system configuration, you have to remove that <leoprikler>then reconfigure, delete all your old configurations and gc <raghavgururajan>Lets decide something. Despite gst being outlier, there are gnome apps that depend on it. So all the patches is related to gnome upgrade, so I need those patches in wip-gnome. So shall we decide on sending them to wip-gnome first and then we'll see how things can go to other branches. *raghavgururajan didn't realise the many so <BlackMug>siraben building the following 2 packages would ensure.... <- some of the output of your command <leoprikler>What do you mean when you say "send to wip-gnome first"? <BlackMug>leoprikler will show too many /gnu/store paths/packages <leoprikler>How many GNOME packages realistically rely on the changes from 1.18.2 to 1.18.4? <raghavgururajan>Why? I need them there. When I update apps like gnome-music and video, I have to test it with updated dependencies. <leoprikler>You have to test against updated dependencies when you update the dependencies. <leoprikler>I'm not sure how semantic gst's versioning is, but it looks pretty semantic to me. <raghavgururajan>May be lets not deal with staging at all. Lets push everything to wip-gnome, which will be rebased often with c-u. Periodically, we can merge wip-gnome to c-u. <leoprikler>A staging merge might be done sooner than you're done with wip-gnome. <leoprikler>Getting patches to their appropriate non-wip branch asap is a good idea. <raghavgururajan>I agree staging will be merged faster. For simplicity, we'll use only c-u, for this gnome-upgrade work. <pineapples>mbakke: Thanks! (I think) It's already building the dependencies of dependencies of my package for armhf. I guess this is due to the limited availability of packages substitutions for ARM <mbakke>pineapples: indeed, I think we are no longer providing 32-bit ARM substitutes at all :/ <pineapples>I'll re-build my package for aarch64 then. I think building this many packages on my system is a bit too extreme. <raghavgururajan>In my upgrading process, there will be changes to gnome packages and non-gnome packages (dependencies). I need both the changes to be in *same* branch for testing. If we push non-gnome packages to different branch and gnome packages to wip-gnome, then I cannot test those changes together. <raghavgururajan>That is why it is better to push the patches to wip-gnome. Once the work is done, we test the branch as a whole. If all good, merge the branch to core-updates. <leoprikler>I'm sorry to say, but this does not really make much sense to me. <leoprikler>You can test against newer gstreamer without needing to push it to wip-gnome. <leoprikler>All you need to do is to cherry-pick or locally merge staging into wip-gnome and then do whatever tests you want to do. <leoprikler>You will have to do so at least once before merging wip-gnome into c-u anyway. <raghavgururajan>Its not just gst, there will be several non-gnome packages thats gonna be changed. <leoprikler>If it's gcc then that goes to c-u anyway and you can simply rebase onto updated c-u. <leoprikler>If the GNOME stack already hard depends on something, then it's very likely a c-u candidate anyway. <leoprikler>If it's just one or two fringe packages, then maybe it'd be more applicable to master or staging, but I don't think that will have much importance either way. <janneke>civodul: omg, that's the *unbootstrappable* project <leoprikler>So tell me at least one package, that is super-important to GNOME, but would go to staging, that is not GStreamer. <janneke>how to ensure we will never escape any binary blobs, deep in our toolchain *pineapples goes AFK for a while <leoprikler>"This isn't just an idea pushed by Rust enthusiasts." <civodul>it's such a crazy concept it's hart to type <civodul>we should write about it because zdnet is not gonna do it for us :-) <raghavgururajan>There many things to consider. c-u has changes that are not in staging. If some of the patches were merged in staging and then I can't just cherry-pick it to wip-gnome. There will be conflicts, as patches won't cleanly apply. I can't keep resolving those conflicts because of the load it puts on me. <civodul>Sylvestre Ledru is amazing: beeng pushing non-copyleft for 10+ years (first Clang, now Rust) <raghavgururajan>For example, you saw 03 didn't cleany apply. One patch is fine. In future, I can't do for many patches. <leoprikler>Well, obviously you'd have to go for a somewhat clean merge commit, but it's not your sole responsibility. <leoprikler>There are more contributors to core-updates than just you and anyone of them can decide to merge staging because it has gstreamer. <apteryx>is anyone else having problems with docker? Something about not finding the containerd binary. I reconfigured from my checkout yesterday, and it happens since then. <leoprikler>(Including you when you feel it doesn't put too much load on you.) <raghavgururajan>Merging patches to relevant branch directly from guix-patches, works fine for shot-term work, where the patches targets specific set packages or adds new packages. But not for long wip, I'd say. <leoprikler>That's why you should keep the wip as short as possible. <leoprikler>Merging a lot of small patches anywhere is always easier than merging a huge blob of 3k commits. <leoprikler>hence why I isolated 9 patches for staging from a set of 30 while I still had the chance. <leoprikler>Merging to the appropriate branch takes work away from you as you no longer have to keep that part of your patch set around. You can thereafter focus on what's actually important to wip-gnome, which is GNOME itself, rather than having to update the entire world. <rekado_>apteryx: have you tried installing containerd? <apteryx>not yet, it was working before, with the same version of docker/containerd, so I'm puzzled <apteryx>If someone would like to check if docker fails the same on their system, you can do: 'sudo $(guix build docker)/bin/dockerd --debug' <apteryx>here it prints: Containerd not running, starting daemon managed containerd failed to start containerd: exec: "containerd": executable file not found in $PATH <pineapples>I generated a patch file. Do I copy and paste it into the body of my e-mail message to guix-patches <at> gnu.org? <apteryx>ah, I think this only happens when containerd is not already running, and our docker-service-type includes a containerd-shepherd-service <apteryx>I think it had crashed: sudo herd stop containerd -> system-error("getpgid" "~A" ("No such process") (3)) <apteryx>indeed, restarting the containerd service resolved it <leoprikler>pineapples: if you plan on doing more than just one contribution, you might want to setup git send-email to do the work for you <leoprikler>copypasta sometimes breaks patches depending on your mail client, so attachments are safer <leoprikler>however, if you have a mail client, that allows you to send mbox files as-is, that works too <pineapples>leoprikler: I see. Thanks. I'll attach the patch file to the mail to be safer <leoprikler>Btw. you don't need to add a signoff line to your own commits, but oh well *raghavgururajan installs <leoprikler>I find it pretty easy to just right-click a commit in it and then "cherry-pick onto" > target branch <leoprikler>that said, you can also "git cherry-pick" on the command line if you prefer. <leoprikler>but gitg being a gnome tool i thought you'd be interested in it :) <raghavgururajan>I am using work-trees. My dirs look like ~/guix/{rg-master,rg-staging,rg-core-updates,rg-wip-gnome} each tracking respective upstream branches. Also, each of the work-trees has been bootstraped. <mbakke>raghavgururajan: I think your key is not in .guix-authorizations on staging yet, so the branch probably needs a rebase <mbakke>raghavgururajan: try running 'make authenticate' in your staging worktree to verify <mbakke>raghavgururajan: we recommend new contributors to install the 'pre-push' hook from 'etc/git/pre-push' to prevent such problems, but it may have gotten lost in your case :-) <raghavgururajan>My apologies! Isn't commit hooks for auto-signing commits with gpg-keys? <pineapples>leoprikler: I've sent the patch. Hopefully, I didn't mess anything up.. <mbakke>raghavgururajan: hooks are scripts that run before/after git operations, the 'pre-push' script runs before any 'git push' operation <mbakke>raghavgururajan: to install it, drop it into your main ~/src/guix/.git/hooks or wherever your main clone lives <raghavgururajan>Yeah! Since manual mentioned "You can prevent yourself from accidentally pushing unsigned commits to Savannah by using the pre-push Git hook called located at etc/git/pre-push", I did `git config commit.gpgsign true`. <mbakke>right, that section could use some clarification <raghavgururajan>Also, it mentioned that .guix-authorizations will be updated by a maintainer. I received email from nckx that things were updated in the right places. <raghavgururajan>mbakke: So should I re-commit the with the hook and force-push to staging? <leoprikler>I just tried force-pushing staging, but it got rejected :( <nckx>We can ask Savannah admins to reset it (again). <nckx>raghavgururajan: This is all in Commit Access in the manual. Please read it attentively. <nckx>Also, if something's not clear (I'm guessing this is a candidate), let us know. <mbakke>raghavgururajan: the branch needs a hard reset to before your commits, then someone already in .guix-authorizations will need to cherry-pick or merge 2946a8c50c595b0c1b365a1e0cd2cfc9ce07062d, and then you can commit and push the patches <mdevos>what's up? What are people working on now? *raghavgururajan feels bad <mdevos>I know people are working on wip-gnome, but that's about it <leoprikler>We agreed on pushing part of that wip-gnome work to staging and gave raghav the honour of doing so without them being authorized on staging yet. <leoprikler>So part of it lies on me as well for not checking ._. <leoprikler>I said "part of it". I'm well aware, that multiple factors were at play here and that it's silly to assign blame to any single person. <nckx>leoprikler: It's on me for not preemptively merging master. <leoprikler>Well, master does raise some merge conflicts, tho. <nckx>raghavgururajan: Please install that hook now :) And I'm going to change the manual to make it sound less like a great idea and more like an obligation. <raghavgururajan>I put it in root of the clone. It will extend to work-trees as well right? <nckx>That's a good question. I think so. If you put it in <guix>/.git/hooks it should apply to everything .git applies to. <nckx>Then the .git in worktrees is something of a NIH symlink that points back to that. <raghavgururajan>Yeah, I have put it in ~/guix/.git/hooks. Using the same command as mentioned in manual. <efraim>lle-bout[m]: using --with-double-long-128 fixed the build failure on powerpc <efraim>nckx: I believe we can delete the branch and re-create it, I did it when I made a mistake on core-updates with the merge <nckx>Oh. So only master is protected? Why is that? <nckx>It's not needed anymore but good to know. <nckx>staging is back on Maxim's last commit. <efraim>if anyone was concerned gnucobol builds on powerpc64le <nckx>raghavgururajan: I'm going to merge in master, then you can push again. <raghavgururajan>nckx: Glad! So I should `git pull --rebase` and then push again right? <nckx>I tend to be pretty rough with git: I git fetch --all && git reset --hard … . Not sure what the gentle workflow looks like. <efraim>I normally fetch and then rebase but that should work also <nckx>raghavgururajan: Let me know when you've synced up. <nckx>No. That's the test: it should reject your commit. <nckx>Make sure it's to staging. <nckx>Don't worry, it sounds like you set it up correctly, and even if it fails it's better to know and reset than never to have known at all. *nckx still really hopes it fails tho. <raghavgururajan>error: failed to push some refs to 'git.savannah.gnu.org:/srv/git/guix.git' <nckx>raghavgururajan: OK, that's because you now need to run ‘git push’ from within ‘guix environment guix’. <nckx>You're now authorised to commit on staging. *raghavgururajan does `git pull --rebase` <leoprikler>pineapples: your patch seems to have arrived well <nckx>Too many conflicts with core-updates for me to fix here without risk of breakage (lots of distraction). Just... don't commit to c-u until further notice :) <boscojefferson[4>I'm Bosco by name. I'm a business/trade analyst with data engineering. I want to introduce you to tradevolumefx Capital! We are a leading trading platform with the records of highest profits and profit conversion. We offer the best trading platform and plans. Free alerts on options, stocks, crypto, forex, and general stock value analysis. We have Over 20 professional analysts that offer Free education to become a <leoprikler>Can I take the option not to pollute the environment with crypto? ***ChanServ sets mode: +b boscojefferson[4!*@*
***boscojefferson[4 was kicked by ChanServ (User is banned from this channel)
<nckx>I look away for a second and shitcoin happens. ***ChanServ sets mode: -b boscojefferson[4!*@*
<pineapples>leoprikler: About that.. it was sent twice for some reason, but, other than that, it looks good <nckx>pineapples: I've merged the two. <pineapples>nckx: For what it's worth now, Sway 1.7 will depend on libseat from that seatd package. We could patch our Sway package to use libseatd ahead of the upstream <nckx>pineapples: Sounds good. <leoprikler>I think merging here just means merging the bug numbers <nckx>pineapples: When was seatd support added to sway? <nckx>Or should I be looking in wlroots? <raghavgururajan>git push running make on all modules. I think it will be pushed when it finishes. <nckx>Unless someone pushed something in the meantime, then you get to go again. <nckx>pineapples: You're running a modified Sway? <pineapples>AFAIK, replacing `elogind' with `seatd' in the inputs of (wlroots), and adding `seatd' to the inputs of (sway) should do it <pineapples>nckx: yes, I do. I just added `seatd' to the inputs of my custom sway package-definition <nckx>OK. I'm on 1.6 from core-updates, I'll try. <pineapples>I'm using whatever is available in our master branch <davidl>Could someone review/commit a small PATCH I sent in reg. the mysql service? #47704. Maxime D. has reviewed already but he doesn't have commit access. <nij>Hello! I'm still working on letting my guix system run stumpwm :D -- This time I have this error - <nij>fatal error: lfp.h: No such file or directory 14 | #include <nij> <lfp.h> | ^~~~~~~ compilation terminated. . <nij>What kind of error is this? It's not missing some dyn libraries, iiuc.. what kind of approach should I try? <leoprikler>nij: it seems the header for lfp is missing. Perhaps a missing input? Or missing include path? <nij>It doesn't happen on my arch machine. <nij>Why would a c header be missing here? Is it populated on some other path that is different from the "default"> <nij>Right.. I've searched through my `/`, and there's no lfp.h at all. <rekado_>nij: what command yields this error? <leoprikler>Guix only looks at the Guix package inputs, not at anything that might come from Arch. <nij>rekado_: In the link (full error) it says it's g++ ... <nij>leoprikler: yep, im trying to find out how to comply for the guix way <nij>Since I have no lfp.h on my whole disk.. I suppose this is something elementary. Maybe I just need an extra package. <ss2`>hi! My system is kernel panicking now. :/ <ss2`>All previous generations won't boot either. <rekado_>nij: no, I mean: what did you run to get this error. <nij>rekado_: I launched stumpwm, a window manager written in common lisp. <nij>And stumpwm returned this error to me. <ss2`>Is there a way to recover this? <rekado_>launching stumpwm shouldn’t compile anything… odd. <rekado_>ss2`: depends on the error. Kernel panic on boot could mean that your root disk isn’t found. <nij>Oh, it reads my personal config, which requires some package to be fetched. <ss2`>hm.. I never changed anything. <nij>ss2`: One time I literally had this.. and later just found that my disk isn't installed properly. <nij>I solved it pushed the disk into where it should be installed a little bit more. <nij>Hope your issue is as trivial as mine. <ss2`>It is saying that it is recovering or partitions are clean. <ss2`>disks are there and can be mounted. <ss2`>was too quick about the mounting.. <ss2`>can mount it, and fsck is happy too. <ss2`>Can I chroot into and rebuild profiles? <nij>Oh, even my sbcl repl isn't working - fatal error encountered in SBCL pid 2341 tid 2341: core was built for runtime "localhost-nixbld-2020-11-02-22-19-41" but this is "localhost-nixbld-2021-03-29-09-07-53"`` <nij>I have a more thorough error message. This time it pops out when I'm quickloading some cl packages - https://bpa.st/WCXQ <leoprikler>perhaps you should add that to your stumpwm environment, so that it doesn't need to recompile it? <nij>Hmm.. it seems that I do have iolib. But it's missing a dependency "lfp" <ss2`>yeah, the last message before kernel panic is: no code for module (ice-9 popen) <nij>Someone told me it's abbrev from libfixposix.. I just got that package. Lemme retry. <nij>Great! That's indeed the case.. now the next error :D - <nij>Unable to load foreign library (LIBFIXPOSIX). Error opening shared object "libfixposix.so": libfixposix.so: cannot open shared object file: No such file or directory. <nij>Seems that the dynamic library is installed in some place that sbcl (or some library) isn't aware of. <jackhill>or it is and there are other issues that have the same symptoms :) <nij>jgart[m]: wow - taking a look :) thanks! <ss2`>hm.. think I'll have to reinstall now. <jgart[m]>nij: there's quite a number of gems in there <mdevos>Does someone have a setup for hacking on glibc on the Hurd with Guix? <mdevos>I want to support SOCK_CMSG_CLOEXEC (code should be easy™), and I was wondering how to go about setting up a development environment <nij>is that person an active guix user? <jgart[m]>nij: definitely! He contributed the syncthing-service-type amongst many other things <jgart[m]>nij: He's also one of the co-authors of The Reasoned Schemer <jgart[m]>There's a public mediagoblin developer meeting this Saturday over mumble. Ben Sturmfels, who's leading the project is hosting it. I'm going to attend. I'm waiting to hear back on the exact time for the meeting. One of the immediate goals of the mediagoblin project is to get it ready for inclusion in guix/guix system. Join #freenode_#mediagoblin:matrix.org or the mailing list for more info. <lfam>It's not exactly what I had in mind ;) <lfam>It does take me back to 1997 <lfam>Did you see my message about how to separate substitutable builds from non-substitutable builds? <jgart[m]>Yes, I did. I haven't tried it yet. But I added it to my notes of things to do soon. <lfam>It would be nice to have a command that did exactly what you asked for <lfam>I mean, it can be done in the Guile REPL, I'm sure <lfam>But for the CLI jockeys among us... <lfam>My pipe dream is a GUI that shows a package dependency graph and lets you take action with each node, like "show derivation" or "build from source" <lfam>A complete Guix explorer <jgart[m]>Yes, I'd love to have a cli for it. What modules do you recommend looking at to make it happen at the repl? <lfam>This would really take the integrated software environment that Guix offers, and make it accessible to an order of magnitude more people <lfam>It's a question better answered by some other people :) <lfam>And, most of the work is already done! We just need the GUI layer <lfam>The foundations are solid <lfam>To be clear, I would not be the person who makes it :) <phireh>Hi there, I have one question... is there a way to globally enable the "doc" output for guix packages? <lfam>I find that Qt packages work better across distros, whereas GTK packages are fiddly on foreign distros <pineapples>Also, I personally feel like there might be licensing issues with Qt in the future <lfam>So, I guess that GTK support under Guix is worse than meh <lfam>There are options besides GTK and Qt, however <jgart[m]>maybe this feature can be added to emacs-guix first? <lfam>I think that the ideal thing would be something that integrates nicely in GNOME <lfam>Hm, I suppose. I don't use Emacs so that wouldn't be useful for me. And the group of people I'd hope to reach also don't use Emacs <lfam>I'm talking about people that won't do something without a GUI. It doesn't really overlap with Emacs users <jgart[m]>what do you think of it being implemented with vala? <lfam>Oh yeah, I've never used it, but Elementary looks very nice <lfam>Ultimately, it's up to whoever decides to do the work <jgart[m]>I'd like guix system to have the whole Pantheon desktop environment someday <lfam>It would be great to improve coordination between Guix and GNOME, since they are both GNU <pineapples>As a Wayland user, I need to disagree that Qt is better in this regard. Many of our Qt packages won't run natively under Wayland, and I'm in no capacity to patch all of them in a clean and orderly fashion. I wish I could use a full Qt suite of programs on my Guix installation, but this is a distant future for me :-( <lfam>Huh, does Qt have plans to address Wayland? <jgart[m]>wasn't ambrevar working on a gui for guix? <lfam>I think there is affinity between our projects <pineapples>lfam: Qt works fine under Wayland, it is just that `qtwayland' isn't the input across many of our Qt packages, which renders them unable to run natively under Wayland. efraim suggested how to fix this, but I don't remember what it was <lfam>Okay, well that's not too bad pineapples <lfam>It's not a fundamental problem <lfam>My idea is not going to happen tomorrow <lfam>These are only growing pains <pineapples>Still, I'm concerned about the future of this toolkit <lfam>Well, time will tell if Qt is a profitable business on its own, or if the future is with the community <lfam>It would be a shame to reject the community efforts prematurely <kisaja[m]>Qt depends only on kde, and they are not that big to maintain all <pineapples>Good point. Either way, where it stands now, I'll primaly use GTK for the foreesable future until I can re-create my dream setup <kisaja[m]>is there a gnu project for display server (like xorg and wayland are)? <lfam>I haven't heard of one, but there are lots of old GNU projects <lfam>There is GNUstep, which is a GUI framework <lfam>Shepherd was one of those old projects. We picked it back up and used it for Guix <kisaja[m]>Well guess well just have to wait for emacs ppl to write some display server haha <Myon[m]>Can linux framebuffer be considered that? <ss2`>oh please, I'd really appreciate a bit of help now. I killed my workstation and the installer is always failing to install to the efi partition. <ss2`>I've screenshots for the error messages. <kisaja[m]>Have you tried without letting installer touch partitions, i think a long time ago installer had repartitioned my disk unsuccesfully <ss2`>it is grub that is failing <ss2`>the system seems to be installed. <ss2`>so I'm trying to manually install grub <ss2`>could I actually do a guix system reconfigure directly from the installer, after preparing all partitions (with their respective UUIDs?) <ss2`>but I haven't pulled yet. I think I remember that I tried this once, where something went out of space afterwards. <ss2`>anyway, where could I paste a screenshot? Is there a throughaway picture paste service around? <pineapples>nckx: I apologise for the trouble this may cause, but may you re-open my ticket? It looks like it remains closed <jackhill>Is it becasue of grafts? I still don't have a good intuition for that. <roptat_>ss2`, do you have a /boot/efi partition? <ss2`>it is mounted to /mnt/efi <jackhill>roptat_: yes? I'm confused why it is being substituted if it doesn't end up in the closure of movim-desktop <ss2`>roptat_: so, no, I don't have a /boot/efi, rather /mnt/efi <roptat_>(since that's where grub is installing) <ft>Hm. Cross-compilation is not a thing yet, right? So I won't be able to generate a guix rootfs for my beagleboneblack from an amd64 machine right now. Correct? <ss2`>I tried that, but it failed to <ss2`>roptat_: Do I say that in the installer? <ss2`>I've always being either selecting /efi or /boot/efi.. <roptat_>not sure if you actually have an option for that in the installer <ss2`>or do I have to tell the installer that efi is in /mnt/boot/efi? <ft>roptat_: Oh really? Well, I'll give it a whirl then. Would be a happy surprise. :) <ss2`>no, I'm manually selecting partitions <ss2`>I'll reboot selecting /mnt/boot/efi <roptat_>ft, there aren't too many people doing cross-compilation, so it doesn't always work very well, but for a basic system, that might work <nckx>It was open when I sent that mail. Not sure what happened. <ft>Doesn't look like it's working. → @ unsupported-platform /gnu/store/4blcfrrzc3yx6xjvw31mhnr1r9lpw4mj-Python-3.8.2.tar.xz.drv armhf-linux, while setting up the build environment: a `armhf-linux' is required to build `/gnu/store/4blcfrrzc3yx6xjvw31mhnr1r9lpw4mj-Python-3.8.2.tar.xz.drv', but I am a `x86_64-linux' <pineapples>nckx: Thanks! Both the merged tickets appeared closed on my end, regardless of the number of website refreshes <ss2`>Can I download the 1.1.0 installer still? <nckx>pineapples: Which URL are you looking at? <ss2`>I installed the system with 1.1.0 then, so I better try it with the old installer. <ss2`>roptat: still fails..... <dongcarl>Hmmm is there a branch for v1.2.1 yet? Would like to test it out :-) <ss2`>or just fetch the latest image. <pineapples>nckx: I was looking at the URLs of #47751 and #47750 respectively, and they were shown as closed and remained such an hour after your last message in #47751's e-mail thread. <Aurora_v_kosmose>I have no ~root/.guix-profile/lib/systemd/system/guix-publish.service file <nij>jgart[m]: do you use stumpwm? It seems that wigust uses his own channel for stumpwm, which somehow workarounds the problem that CFFI didn't know where to look for dynamical libraries. <nij>But I'm not sure how it bypasses it. <nckx>pineapples: *Which* URLs. <nckx>There are multiple views. <roptat>ft, you need to use the --target flag, with a triplet (need to find doc to get the right one) <roptat>ft, that would be --target=arm-unknown-linux-gnueabihf <roptat>Aurora_v_kosmose, although, that's a bug in the manual <roptat>it should be ~root/.config/guix/current instead of ~root/.guix-profile I think <nckx>pineapples: Mystery solved. Someone's replying to the bug using the nnn-done@ address, closing it every time. <ft>roptat: Aha! That makes it try a cross-build indeed. One of the things I tried to include uses ‘meson’ as its build system, which is why it breaks now, but I suppose it's easy enough to get rid of that one. Thanks for the hint! <roptat>yeah, you should be able to create a minimal system with that <roptat>and then boot it and build more stuff on the real machine <Aurora_v_kosmose>roptat: In either case, there's no file at that path. There is one at /var/guix/profiles/per-user/root/current-guix-1-link/lib/systemd/system/guix-publish.service <ft>roptat: That's pretty cool. So worst case, I'm bootstrapping a system to run in a VM to build a full rootfs with. <ft>roptat: As long as I don't have to get into open-embedded, all is good. ;) <ft>roptat: Hm. Removed the offending package, now I'm back at the point where I was before, with python refusing to build. Same error message too. <ft>roptat: I'm running the guix package manager on top of a foreign distribution (debian). Maybe that's a limitation? <Aurora_v_kosmose>roptat: So I think that whatever is supposed to set that link by default is no longer working. <roptat>Aurora_v_kosmose, it should be ~root/.config/guix/current instead of ~root/.guix-profile I think <roptat>ft, no that shouldn't be an issue <roptat>ft, maybe I didn't remember right, and it's actually not supported, sorry :/ <ft>roptat: Ah no worries. Thanks for your help. :) <roptat>Aurora_v_kosmose, oh, it's in the "guix" package, so you can find it as `guix build guix`/lib/systemd/system/guix-publish.service <apteryx>to run wireshark without privilege on Guix System, is it supposed to be enough to add my user to the 'wireshark' group? <roptat>Aurora_v_kosmose, yes, but don't install guix in your profile <ft>roptat: It may have been pebcak. I may have misunderstood --system. I had --system=armhf-linux on the guix call too. Leaving it off, with just --target=...triple... seems to start to build things. Soooo pebcak, I guess. ;) <ss2`>right, turns out the uefi was full... =_= <roptat>ft, ah right --target is for cross-compiling to a given GNU triplet, --system is for native build using packages packages of the given system type <roptat>so --system=i686-linux on x86_64 works and produces the same as native compilation from i686, but --target=i686-linux-gnu uses a cross-compiler and produces something different from the previous one <ft>Makes sense. Thanks again! <ss2`>So, I can't find out what happened that my previous system became unbootable, but I do remember that I did a gc yesterday or so and deleted a lot of files in the store.. <ss2`>and I'm quite sure that I never reconfigured the system until I rebooted.. <ss2`>has anyone experienced that before? <roptat>Aurora_v_kosmose, we use something like that for our Chinese mirror I think, but I don't know the details <roptat>ss2`, it can happen if you used guix from a git checkout and forgot to add --localstatedir when running configure <lfam>dongcarl: 1.2.1 will be based on the master branch <lfam>There are still some bugs to be squashed, but they don't usually affect "typical" usage, or they would have been fixed already: <https://bugs.gnu.org/47297> <Aurora_v_kosmose>roptat: There doesn't really seem to be anything built-in for this, I'm also not sure how to change the default "guix" channel host for a given machine. <roptat>Aurora_v_kosmose, you mean default build farm (set of substitutes), or default channel (set of packages) <Aurora_v_kosmose>roptat: I have a local substitutes machine now, let's call it cache-host. I want cache-host to also be where every other machine in my LAN fetches the guix repository. <roptat>so you can redefine the list of channels in your ~/.config/guix/channels.scm <roptat>instead of using %default-channels as the documentation suggests, you'd list the guix channel with your mirror <roptat>to mirror the git repo, just use whatever tool you would use for any other git repo <roptat>(note that you'll have to mirror at least the master and the keyring branches) <jgart[m]><nij "jgart: do you use stumpwm? It se"> I don't use stumpwm at the moment. There was a period when I was using it. I'm currently using i3. My other pipe dream would be have minimal experimental guile bindings to my dwm config.h just because. Not sure when I'll find the time to experiment with that. Maybe soon. <Aurora_v_kosmose>Mhm. But would setting ~/.config/guix/channels.scm for the root user be enough for any new generated users to follow? <Aurora_v_kosmose>(With current users needing their ~/.config/guix/current/manifest adjusted manually) <nixo_>hi! my guix is crashing guile (and it happens on two different machines). I'm on master, and I was trying to build a package from a manifest guix build -f manifest.scm . The MWE is this: '(use-modules (guix git-download)) (git-predicate "repo")' <ss2`>roptat: as in building from a git checkout, but not installing? <nixo_>oh but it depends on the content of repo maybe <nixo_>no, an empty folder causes the same <ss2`>I was checking out and building packages localy. <Aurora_v_kosmose>At least, I think ~/.config/guix/current/manifest is what drives that. I could be wrong. <roptat>Aurora_v_kosmose, no, users would default to %default-guix-channels <Aurora_v_kosmose>roptat: I see, so I'll need to ensure users have the appropriate ~/.config/guix/channels.scm set instead. <roptat>nixo_, can you report it to bug-guix@gnu.org? <ss2`>so forgetting --localstatedir can break things? <Aurora_v_kosmose>I would imagine the Chinese mirror set things up as a hook upon receiving commit emails. <roptat>ss2`, yes, there's a warning if you forget it, but it's not necessarily very visible :/ <roptat>Aurora_v_kosmose, no idea, you can probably ask on help-guix *lfam tests update of the 'guix' package <ss2`>uh, that isn't a good thing actually.. is there a way to prevent this happening again? <ss2`>I am just about to redy myself to hack on things and this happens.. <nckx>ss2`: Not beyond ‘don't forget it again’. Changing the default to the value everyone uses has been rejected in the past because it goes against the GNU coding standards. <nckx>Perhaps it may be reconsidered in future. <nckx>(I don't think a warning would ever be seen when it matters.) <ss2`>honestly, it's the first time it happens to that a ./configure (forgetting a parameter) can break a system so thoughly like this today. <ss2`>all my stored generations where broken <ss2`>good thing is, that it is Guix and slapping a config.scm and a manifest will pull up ones system again in no time. :) <lfam>To be fair, messing up ./configure for a very large number of Guix packages could also break a system 