<civodul>berlin is occasionally getting 502 from git.sv.gnu.org <ryanprior>I'm following the "building from git" instructions from the manual. I'm running the second step, verify-commit, and it's telling me that Ludovic Courtès key is expired and that "make authenticate" has no rule to make target. <ryanprior>Should I be alarmed, file a bug report, skip this step, something else? <lfam>ryanprior: You need to update your copy of the key <lfam>Presumably this is the key: `gpg --keyserver hkps://keyserver.ubuntu.com --refresh-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5` <enderby>hi, wondering if there's an easy guix cli option to list which packages are installed - in a way that i can do something like guix package install *something* to install all the same packages on another machine <plasma41>Guix uses mcron, right? Does mcron have a maintainer? <rekado>enderby: you can list installed packages with “guix package --list-installed” <rekado>use cut to get the first item of each line <enderby>rekado: yeah, so then the only way is to reformat that list? <rekado>you could also use Scheme to process the profile’s manifest file <enderby>rekado: cool, doing the manifest way <ryanprior>now GPG is telling me: pg: WARNING: This key is not certified with a trusted signature! There is no indication that the signature belongs to the owner. <ryanprior>The instructions say: Take note that a warning like “This key is not certified with a trusted signature!” is normal. <ryanprior>But it still says "no rule to make target 'authenticate'" when I'm trying to verify my guix git tree. <ayuce>trust level of a key should be private to you, so if you didn't trust the key, gpg wouldn't know if the key is trusted or not and warns you about it. <ryanprior>Okay, that makes sense. Still mystifying why `make authenticate` doesn't work though. <ayuce>maybe that's because you need to verify it before making authenticated. <ryanprior>Well, verify fails because I don't trust the key. Why do we have this set up where the only way to build guix is to go to a key signing party with Ludovic Courtès X.X <ryanprior>I just wanted to check that my patch to guix actually works before submitting it and an hour of following instructions later, I find out that guix master is failing its own `make check` so I'm just gonna submit the patch blind and see if anybody complains. *jsoo confused by cabal’s configure ***wxie1 is now known as wxie
***catonano_ is now known as catonano
<plstohelp>going to try my hand at building a package tomorrow <ryanprior>plstohelp nice! Let me know if you run into snags, I certainly did (and do regularly) <xelxebar>plstohelp: Cool. We're kind of on the same page. I just got taskserver successfully built. <xelxebar>Now I'm just left with the task of creating an associated service... <xelxebar>FWIW, I found the process relatively straightforward. Use guix download to download the source tar and get its hash, hack out a template draft, run make to build the template, then run guix build and fix the error. <xelxebar>Of course, the devil is in the details. I've been quite impressed with guix's info docs. Lots of love has gone into them. <plstohelp>you know, i was really shocked how my internet browsing habits didn't change at ALL with librejs <xelxebar>The only annoying thing I found is that the generated *.po files aren't part of .gitignore, so git status remains polluted. <plstohelp>but then i found out it breaks a TON of stuff on gitlab, even if i whiteist everything i can <ryanprior>Oh yeah why aren't the .po files ignored? I found that to be vexing. <raghavgururajan>During install phase, I get this error "sudo: /gnu/store/l320ig872ny66d1yi6v7n4zb93iz50dx-sudo-1.8.31p1/bin/sudo must be owned by uid 0 and have the setuid bit set". <raghavgururajan>Is there way to make the install phase not to use "sudo" for any actions? <xelxebar>raghavgururajan: I'd guess that's a hard constraint to work around. It really doesn't make a lot of sense for sudo to be owned by anyone else other than root, and it looks like sudo is a requisite of several core packages. <xelxebar>raghavgururajan: You could perhaps try using unshare to fake uid 0 to guix <xelxebar>I'm not exactly sure of the ramifications that would have though. <akoppela>I'm facing certificate is not trusted issue. nss-certs and le-certs packages are installed. SSL_CERT_DIR and SSL_CERT_FILE are set correctly. <akoppela>Or what would be the way to debug issue? <str1ngs>akoppela: is your computer clock time correct? <lispmacs>what is the command-line command for displaying the source file of a package? <lispmacs>can this be done for hidden packages like gcc? <str1ngs>raghavgururajan: a package should not use sudo while doing make install. that seems like a problem with the package <str1ngs>lispmacs yes but take some magic. one sec <str1ngs>lispmacs: guix build -S -e "(begin (@@ (gnu packages gcc) gcc))" <str1ngs>you can drop the begin. I might to remove that. <lispmacs>the power of the Source is strong in this one <str1ngs>I don't feel that way when I'm reading hygienic macros :( lol <str1ngs>I feel like luke after the revenge of the sith :P <rekado_>ryanprior: you don’t need “make authenticate” to *build* Guix <rekado_>it is a target to verify commits, but you’ll need all the keys that were used to sign commits. <ryanprior>Oh I found that out, but it's listed in your build instructions using words like "must" <ryanprior>I would recommend streamlining and better explaining that step or moving it into a separate page <nagamalli>sry, I lost my internet connection , My doubt is regarding about the finding stable version of gnome-todo package. <nagamalli>But I was suggested to update only to a stable <nagamalli>version matching the other parts of GNOME we have. <str1ngs>raghavgururajan: what ever package had that in the source. it's very bad to do that. <str1ngs>users can always do sudo make install . if they need to <xelxebar>Oh, I completely misunderstood that question. <raghavgururajan>nagamalli If the package is available in ftp sources, then it is a official release by gnome. So go ahead. Gnome don't do LTS. <str1ngs>rag nice thing is since guix does not set sticky bit. guix-daemon caught it. <raghavgururajan>str1ngs It was gtksu. But the program is poorly maintained. Lots of spelling and syntax errors. So used ktsuss instead. <nagamalli>raghavgururajan, Yeah Thank you very much, but i am hesitating regaring stable version and about this issue <nagamalli>gnome-todo 3.28.1 fails to build with new glib2.0 >= 2.60.0 <str1ngs>raghavgururajan strange because that is actually a useful package. <str1ngs>raghavgururajan I don't have commit rights sorry <str1ngs>raghavgururajan: I can at least help review <str1ngs>nagamalli: I'm assuming spacefm needs this glib-or-gtk-build-system now? <str1ngs>nagamalli: sometimes gnome package names do not correlate with gtk releases. <str1ngs>raghavgururajan: I'm assuming you had a good reason to change the build system? <raghavgururajan>str1ngs I used glib-or-gtk to fix icons. They did not load previously. <raghavgururajan>Anyway, gnu-build-system and glib-or-gtk build are almost same. The latter has phases releated to glib and gtk stuff. <nagamalli>Ok, I am very new to this,THta's why little bit confusions.. <str1ngs>glib-or-gtk wraps binaries and libraires providing environment variables <str1ngs>nagamalli: I would say if it build and works it's okay. you can always check in #gnome on #gimpnet to be sure about versioning <nagamalli>I will just try to update the gnome-todo package from 3.28 to 3.91 <lispmacs>I must say that if you know that package transformation commands, it is really easy to build and install hacked source code <str1ngs>what license is non-copyleft raghavgururajan ? <raghavgururajan>str1ngs As far as I know, it is a misc license declared in license.scm. <str1ngs>raghavgururajan: what does the license say upstream? <str1ngs>I just built webkitgtk use guix on a machine I don't have root access too :) \o/ <rekado_>raghavgururajan: is there a more specific license you could use? <rekado_>nagamalli: please don’t try to upgrade to 3.91. <akoppela>str1ngs: I'm using GuixSD and timezome and date are correct <rekado_>nagamalli: are you aware of the branch containing GNOME upgrades? <nagamalli>rekado,Yeah ,As you said don't upgrade to 3.91 , i don't know the reason why ? <rekado_>nagamalli: the current GNOME version in the master branch is 3.32 as far as I can tell. <rekado_>so upgrading any GNOME package beyond that version requires upgrading all of GNOME to that version. <str1ngs>gnome version don't always work that way rekado_ <rekado_>aside from the fact that 3.91 is not a stable version you shouldn’t upgrade beyond 3.32 if you target the master branch <rekado_>raghavgururajan: that is probably a mistake <rekado_>we should aim to be consistent with GNOME <rekado_>in the past we weren’t and that caused a lot of trouble <rekado_>I’ve done two upgrades in the past and they are very involved <rekado_>the point of whether GNOME devs have stable or LTS versions is moot. <str1ngs>well the stable release for gnome todo is 3.26.1 but guix has 3.28.1 <rekado_>the point is that they should be consistent <raghavgururajan>So the general ruel of thumb is to upgrade to version one less than latest? <rekado_>the rule of thumb is to keep GNOME things at around the same version <rekado_>obviously major version, but nobody packages GNOME 4.x or 2.x at this point ;) <rekado_>the minor version is just as important <rekado_>we’ve had cases in the past where upgrading beyond the same x.yy version caused segfaults when running the application <str1ngs>it's going to be a long road to gtk 4 lots of big changes <rekado_>that’s not uncommon because there are cross-cutting assumptions that GNOME software can make <nagamalli>rekado: <aside from the fact that 3.91 is not a stable version you shouldn’t upgrade beyond 3.32 if you target the master branch> How did you checked it's not a stable version? <str1ngs>gtk_init gone, no more using signals on widgets. <rekado_>by using inconsistent versions you invite lots of avoidable problems. <rekado_>nagamalli: 3.9x appeared before 3.3x for a bunch of GNOME applications <rekado_>so it’s safe to disregard that version <raghavgururajan>That's true. I was initially inclined to this way to consistency. But along the way, I was told it doesn't matter with gnome. Seems its wrong. <str1ngs>rekado_: is wip-gnome-updates bleeding edge? <rekado_>there are a few exceptions to the rule such as epiphany <rekado_>but generally we aim to have GNOME software stay around the same version and upgrade them together <nagamalli>as str1ngs said well <the stable release for gnome todo is 3.26.1 but guix has 3.28.1> , i am also having same doubt? <rekado_>str1ngs: I haven’t worked on wip-gnome-upgrades recently, so I don’t know. <str1ngs>I'm just curious to see how nomad does on that branch. maybe I can do some future proofing now. *raghavgururajan will be working on gnome, hopefully with outreachy. <rekado_>nagamalli: with GNOME TODO I actually don’t know what 3.91 is; it’s mentioned in the NEWS file as if it was a regular release. Weird. <rekado_>I don’t know if the expectation is that current GNOME will have the TODO app at version 3.91 or any other version. <rekado_>raghavgururajan: what does “BLOCKERS” mean? <rekado_>I don’t really have the time to do a proper review of all of the mentioned patches <nagamalli>and wants to update , having some doubts just asking? <nagamalli>Can u please suggest me how can i move forward? <raghavgururajan>nagamalli rekado_ was suggesting that you try to update wip-gnome.. instead of master. <rekado_>FWIW Fedora 31 has gnome-todo 3.28.1 <rekado_>(they usually have an up-to-date GNOME) <rekado_>the wip-gnome* branches are not good starting points for beginners <rekado_>perhaps you can look into upgrading another package <xelxebar>So, the repo's make rules contain bashisms which badly screws up if you're on a foreign distro where /bin/sh isn't bash. <xelxebar>I reported this to bug-guix and Ludovic replied with a pointer to a bug from 2017 reporting the same thing. <xelxebar>I followed up with a proof-of-concept, one-liner patch to configure.ac, but unfortunately it got zero attention. <xelxebar>I'd like to get opinions on it, but it feels too pushy to xpost on guix-patches <xelxebar>For whatever reason, I cannot find this message on issue.guix.gnu.org. <rekado_>the reason for not finding anything new on issues.guix.gnu.org is that it is not currently updating <rekado_>we got blocked from debbugs.gnu.org temporarily for updating too often, so I’ve been working on an alternative updating method that does not affect performance of debbugs.gnu.org <rekado_>this new version is almost ready, but there are a few regressions that I need to fix first <janneke>raghavgururajan: what is 40753 about? *janneke goes to have a look <rekado_>xelxebar: don’t worry about receiving no response for a while. It’s hard for us to see all patches and respond in time. It’s fine to ping. <rekado_>raghavgururajan: no, I need to get back to working on issues.guix.gnu.org and making space on ci.guix.gnu.org <raghavgururajan>rekado_ Cool! Just wanted to make sure as I asked janneke look at it. <xelxebar>rekado_: Thanks. I'll give it a few more days and ping in case it's still languishing. <janneke>raghavgururajan: ah, has that already been reviewed? <janneke>i'll see if i can run it, never heard of it before ***apteryx_ is now known as apteryx
***jonsger1 is now known as jonsger
<lprndn>bricewge: bad news on for the lightdm service. It seems we can't use handle-xorg-configuration with a service that support extension as it overwrites `compose` and `extend` fields :/ <bricewge>I'm not sure of this. If lightdm-service-type is extended by set-xorg-configuration it get a xorg-configuration record, so it should be possible to handle the extension differently based on the type it is extend with? <lprndn>bricewge: yeah, looking into that, it should be possible. just a little meh. <bricewge>lprndn: If it seems impossible you should ask on guix-devel if it is actually possible or which extension type should be supported, since not having a set-xorg-configuration may be a showstopper for some reviewer... <bricewge>It's a bit of bummer. Sorry to have forgotten about that part when we discussed the UI <lprndn>don't worry, I'm learning a lot! ;) <jonsger>dftxbs3e: what is the current state of guix on ppc64 (BE)? <dftxbs3e>jonsger, guile2.2 has a cross compiling bug which makes cross compiled guile object files not work on ppc64 big endian when cross compiled from x86_64, otherwise, it works, it bootstraps (with a manually crafted guile2.2 bootstrap tarball), and then I've been fixing packages over and over, don't remember exactly which one I was fixing last time, my tree contains all latest changes, I havent been able to work on it more recently because my <dftxbs3e>attention has shifted to a day job at a french state hospital, I'm paid for 50% of my time but right now I'm doing more like 100%, unpaid, but whatever <jonsger>dftxbs3e: oke, thanks for the update <dftxbs3e>jonsger, and for your information, I crafted the guile2.2 tarball by compiling guile objects natively with gentoo and injecting them inside the cross built tarball to replace the broken ones <efraim>dftxbs3e: does guile-2.0 work? and what's the story with gcc-5? I don't remember if that one worked <efraim>on core-updates at least the bootstrap binaries creation process has been switched to guile-2.0 and gcc-5 <dftxbs3e>I'd be so glad if you tried upstreaming some of it like you said, but I think that guile bug is a blocker for upstreaming <efraim>janneke did most of the rest of the work getting the hurd bootstrap to work *ecbrown is really impressed with the hurd work <janneke>efraim: are you cross-compiling? do you have patches? <efraim>janneke: I'm working at it natively but crosscompiling would be a lot nicer time-wise <efraim>the libffi patch is pretty unconditional for ppc32, not sure about ppc64 <rbonnal>if I modify a file while in a phase, How can I be sure that my patch has been really applied ? <efraim>I had an issue with binutils-final and refering to bootstrap binaries but I think it's probably due to the bootstrap binaries not being an older version than the ones in commencement.scm <janneke>efraim: ah yes. civodul inspired me to move from native to cross, which is really helpful time-wise <janneke>efraim: but i'm also asking because we have a problem cross-compiling especially guix <dftxbs3e>janneke, yeah the hurd work is like sooo amazing! <dftxbs3e>It's like we've talking about it a little the other day and you went full bananas about it since then! <janneke>dftxbs3e: thanks, i might be a little bananas but it's /we/ who are doing it! <dftxbs3e>efraim, I've worked around that by allowing it and it's been fine! <dftxbs3e>or like, have a final phase that fails intentionally and use the --keep-failed feature <efraim>janneke: just a normal './pre-inst-env guix build --no-grafts --target=powerpc-linux-gnu hello'? <janneke>efraim: oh, possibly -- i was talking about hurd and suggesting such a path for powerpc; haven't done that myself! <efraim>janneke: yeah, well... s@powerpc-linux-gnu@i586-pc-gnu@ <efraim>was more what I meant in terms of using --target <efraim>looks like I'll have to stop running the daemon with --no-substitutes *ecbrown crows upon discovering emacs-pdf-tools <jonsger>how can I escape an $ in substitute? \ and \\ doesnt work <thvk-ivgf>jonsger: if this yet doesn't work somehow, maybe you're willing to paste the expression? (idk about REs :) <jonsger>I had a wrong }, lets see if its working now ***wxie1 is now known as wxie
<pkill9>does `guix system reconfigure` now output the build's standard output again? it's doing that for me ***wxie1 is now known as wxie
<sturm1>I've just been trying to reply to an old bug to add some extra useful information, but my replies seem to vanish. I thought reopening it might help, but nothing seems to happen when in send "reopen" to control: https://issues.guix.gnu.org/issue/35746 <sturm1>Any tips on how best to add this extra info to the report? <rekado_>sturm1: issues.guix.gnu.org is currently in read-only mode <rekado_>I’m working on bringing it back online <rekado_>that’s why you currently don’t see any updates there. <sturm1>ah, thanks rekado - I also can't see anything via emacs debbugs-guix - is that similarly affected? <divansantana>how to configure service docker-service-type? I want to change the network range it uses. Which is normally set in /etc/docker/daemon.json <rekado_>“Did not alter fixed versions” — not sure what that means <sturm1>Ok, sounds like my control message did reopen it then. I'll resend my comment and see what happens *rekado_ prepares to deploy updated version of Mumi to issues.guix.gnu.org <pkill9>nice, what changes have been made? <civodul>pkill9: local mailbox processing i guess <rekado_>pkill9: I removed mumimu (the fork of mu), added Guile-Xapian, replaced the indexer and query processor, and added support for raw Debbugs bug log files that we now sync over rsync directly from debbugs.gnu.org. <civodul>quite a big change, thumbs up, rekado_! <pkill9>could a link to issues.guix.gnu.org be added to the top bar of the guix.gnu.org front page? <rekado_>so updates to issues.guix.gnu.org will no longer break debbugs.gnu.org, and users shouldn’t really be able to tell the difference <rekado_>also brought back “mdate” search (“mdate” for message dates, as opposed to “date” which is for the date of bug submission) <rekado_>the system configuration for berlin can be found in the maintenance git repository <rekado_>or do you mean the Cuirass specifications shown at ci.guix.gnu.org? <pkill9>i just used the word specification because that's what is in the title on that page <civodul>pkill9: build results are the substitutes you get from ci.guix.gnu.org (same machine) ***wxie1 is now known as wxie
<pkill9>is 'staging-staging' the correct one to find info on package builds? *janneke removes `wip-hurd' <janneke>i guess it's easier/less confusing to possibly go back to that name later if it hasn't been used for a while ***wxie1 is now known as wxie
*janneke prepares a wip-ppc branch <janneke>efraim: starting to build --target=powerpc-linux-gnu `hello', i noticed again how long the todo list is <efraim>I guess I could push my wip-ppc branch to savannah <efraim>yeah, I had to drop glibc down to 2.30, forget what the error was for 2.31 <janneke>efraim, so i what would really do in practice is: ./pre-inst-env guix build --target=powerpc-linux-gnu -e '(@@ (gnu packages commencement) gnu-make-boot0)' <efraim>I tried reverting it after I created the bootstrap-tarballs but when it got past glibc in commencement the errors returned <janneke>anyway, i like my list of work to start smaller, and enjoy success sooner :) <janneke>oh, that's really painful, juggling glibc like that *janneke would never do such a thing /S ;) <pinoaffe>im trying to package "sqlitebrowser", and i'm getting an error stating that qt5linguisttools could not be found - others that had the same issue fixed it by installing qt-dev packages and the like, is there an analogue for guix / is there some other fix / do I need to package qt5linguisttools first? <pkill9>the only qt packages i have in there are qtbase and qttools <rekado_>pkill9: staging-staging is for the “staging” branch. <rekado_>pkill9: the “master” branch is “guix-master”. <rekado_>pkill9: the “guix pull” stuff is “guix-modular-master” <civodul>also note that the "build details" page points to an "evaluation" page that'll soon display info about the commits used <civodul>also note² that guixsd.org is super deprecated <pinoaffe>pkill9: thanks, ading qttools seems to have done the trick! *rekado_ reconfigures ci.guix.gun.org ***rekado_ is now known as rekado
<zzappie>Anyone knows is there a fuse library in guile? <civodul>rekado: yay! is it the new Mumi that i see already? :-) <civodul>zzappie: not that i know of, but check also on #guile <rekado>civodul: no, I’m still reconfiguring ***langdon_ is now known as langdon
<rekado>okay, looks like issues.guix.gnu.org is back now <rekado>still have to write a service for rsyncing the data from debbugs.gnu.org continuously <rekado>and I still need to fix the mailer <rekado>and perhaps I introduced a few minor regressions as we’re now using debbugs log files <rekado>so let me know if something’s wrong. <rekado>(I still need to import archived issues, but that’s easy) <jonsger>rekado: thanks for all your mumi/debbugs work!!! <civodul>does that mean we now have to actually review those patches? <janneke>civodul: what a nice patch series on declarative profiles; the various ways of interacting with the store monad; especially mlet and -> are things that i use on a cargo-culting basis; i don't understand enough to make good comments about that, yet ;) <civodul>janneke: heh, that'll give us fewer reasons to mlet -> return >>= all the things! <janneke>must be quick to learn or they're all gone :-) <rekado>hmm, first problem: 40770 does not render <rekado>one of the errors is: string contains #\nul character <efraim>given the quantity of patches we recieve I'm going to suggest either have a "more" button to load more or to make the default 25 instead of 10 most recent patches <civodul>rekado: perhaps regexp-exec complaining? <civodul>a "Process" button would be neat, too :-) <rekado>hmm, the problem is that debbugs logs record mails differently dependent on whether they were received as incoming mails or via some other mechanism <rekado>so some of the other messages don’t seem to have From headers <rekado>and that leads to errors down the road <rekado>I’ll make this more robust before trying to figure out how Debbugs records things <jonsger>it even finds only half year old builds on core-updates <cbaines>jonsger, are you looking at the staging-staging specification on ci.guix.gnu.org? <cbaines>I'm not sure why the search doesn't seem to find it <rekado>something’s not quite right with the search <rekado>it’s on my list to investigate this <jonsger>cbaines: oke thanks. But then vala should have substitutes? <jonsger>I aborted it and run it again. And now its building only local changes on top of staging. Strange thing... <rekado>if you are the first to request a substitute it may have been built but not cached yet. <rekado>on a cache miss the cache is populated but you’ll get a 404 first <rekado>after a little while you can request it and be served the cached substitute. <rekado>I don’t like this because it gives the impression that we have fewer substitutes than we actually do. <rekado>but a better solution has not become apparent yet <rekado>efraim: next version of mumi will have a “more” link <cbaines>this shouldn't happen very often now for ci.guix.gnu.org and master now, as data.guix.gnu.org queries for substitutes repeatedly (at least for recent derivations) <diligentcircle>Hi! So, a few days ago, I decided to try installing version 1.1 of the Guix system on my laptop. Much better than version 1.0.1. :) But I still ran into a problem. When I got to network selection, I was able to choose our (secured) wireless network, but it didn't prompt me for a password and got stuck in a dialog saying it was connecting. I tried leaving it there for at least a half hour; it seems it really was stuck. Is this a <diligentcircle>Specifically (just tested this again), I get stuck on a dialog (after I select our wireless network, which is called "Appoline"): "Connecting to Appoline, please wait." When that happens, it's stuck there; I'm not able to do anything through keypresses, all I can do is force power off the laptop. <diligentcircle>Ah, slight correction: I *am* able to use Alt+SysRq+REISUB just fine. <nothingmuch>i tried importing petlib from pypi, it seems to build fine if i add openssl as a regular input, but validate-runpath fails <nothingmuch>is it plausible that this is just a false positive? there's a few other python packages (e.g. python-pyopenssl) that link against openssl and don't seem to disable validate-runpath <cbaines>Grafana is going to take some time to package due to the Javascript stuff, but I've got it running on a server now, as it's useful to look at data in Prometheus <drakonis>you probably dont want to open all of them at once <rekado>shouldn’t be too difficult to add to goggles.scm <rekado>civodul, efraim Fixed the mumi bug that rendered some issues blank; also added a “more” link for even more recent issues. <operator-name>Hi, I found a tiny bug and would like some handholding in how to use savannah and mail patches. <operator-name>So I've cloned git://git.savannah.gnu.org/guix.git and I'm fixing the doc <rekado>(found another problem with mumi: encoding of the debbugs log files is not always correctly identified…) <rekado>operator-name: did you have a quick look at the Contributing section in the manual? <operator-name>aha, lovely. I can always count on gnu projects to have nice documentation. I'll give that a read <rekado>(hmm, oddly enough the encoding looks right on my machine. Maybe env var related…) <rekado>operator-name: excellent! Let us know if something’s unclear. <operator-name>Hmm, uhh I've stumbled at the second step of running `git verify-commit` <operator-name>sorry for the complete noobness. so I think I need to setup gpg? <cbaines>operator-name, you can skip the verify-commit bit if you don't want to GPG verify some commits <cbaines>It's not a prerequsite for sending patches <operator-name>okay, there's quite a lot I need to learn to get fully up to speed if I ever switch from nixos haha <operator-name>so the bug is with the documentation, so I think quite a lot of the manual doesn't currently apply <operator-name>I'm feeling a little lost, where do I find how the documentation stuff happens? <operator-name>right, but I'm assuming I need to run something on that to double check I haven't broken anything <janneke>raghavgururajan: thanks; and i failed to add the my mail: "Thanks for your patch!" <cbaines>operator-name, I guess you could run makeinfo -o /dev/null doc/guix.texi <cbaines>operator-name, or make doc/guix.html <bricewge>cbaines: Hoo, Grafana on Guix, that's really nice! <operator-name>cbaines: okay, I think I've gone wrong somewhere because `make authenticate` doesn't find a target <operator-name>hmm, yeah. I think the documentation is missing some steps/assuming too much of little old me <operator-name>assuming `git verify-commit `git log --format=%H build-aux/git-authenticate.scm`` doesn't change the state of anything <operator-name>$ make authenticatemake: *** No rule to make target 'authenticate'. Stop. <rekado>I guess this should come after the bootstrap and configure steps <lfam>Right, the Makefile hasn't been created yet <rekado>I suppose we should also give instructions on how to obtain all keys <operator-name>this is getting out of the scope of what i originally wanted to do <operator-name>so let's assume my change to the documentation doesn't break anything <operator-name>It's this tiny url change that I'm using to take the opportunity to learn your buildsystem <nagamalli>Hi , I wrote 9 packages of cran , should i send each patch as separate patches? <lfam>operator-name: Yes. Usually we prefer you test your patch before sending it in. It's okay to skip the `make authenticate` step <lfam>nagamalli: Yes, 9 separate patches. Send an introduction letter to <guix-patches@gnu.org>. You will receive a reply with a special email address for your bug ticket. Then send the 9 patches to that address <operator-name>lfam: Yeah, I might spin up a guix vm and add some more documentation on how to get started from a non guix system, but for now I'd like some guidence on the changelog format for commits. I'm beginning to realise how advanced guix is. <lfam>Sure. In general you can read the Git log for the file / code you are changing and get an idea of how to write it based on that. The reviewer will usually rewrite it for you, if necessary. It's the "GNU Changelog" format ***MightyJoe is now known as cyraxjoe
<lfam>So you could do `git log doc/guix.texi` and look at some examples <lfam>You could also do `git blame doc/guix.texi`, look at commits that mostly touched the section you are working on, and get more targeted examples <lfam>Or, we could just tell you what to write ;) <lfam>We aim to make it easy for new contributors to get hooked... I mean, get started <operator-name>commit 34faf63ebc9221f5cac460bc54237ea8436d5046Author: Ludovic Courtès <ludo@gnu.org>Date: Wed Apr 22 15:24:47 2020 +0200 gexp: Add 'load-path?' field to <scheme-file>. * guix/gexp.scm (<scheme-file>)[load-path?]: New field. (scheme-file): Add #:set-load-path? and honor it. (scheme-file-compiler): Pass #:set-load-path? to <operator-name>What's going on with the guix/gexp.scm (<scheme-file>)[load-path?] () and [] here? <lfam>Generally, the changelog entries consist of a title that describes the change imperatively. Then, you list changes to files. <lfam>Within each file section, you list variables and changes to them. Variables are contained in (parentheses) <rekado>(…) is for variables, […] for fields within variables <lfam>Yup to rekado and bricewge <lfam>operator-name: You'll find simpler examples for changes in the 'gnu/packages' directory <operator-name>I think I'm getting the gist. I hope I can take advantage of my noobness to at least help improve the documentation after this. <operator-name>commit f17e84f14a1d71dce6ced8b6bc43e31e9f736bd8 (HEAD -> master)Author: operator.name <operator.name@protonmail.com>Date: Wed Apr 22 19:57:07 2020 +0100 doc/guix.texi: Update url to singularity before link rot occurs. * doc/guix.texi: Update url to singularity before link rot occurs.diff --git a/doc/guix.texi b/doc/guix.texiindex <operator-name>4787f38181..9e45c0b61b 100644--- a/doc/guix.texi+++ b/doc/guix.texi@@ -5118,7 +5118,7 @@ guix pack -f squashfs bash guile emacs geiser @noindent The result is a SquashFS file system image that can either be mounted or directly be used as a file system container image with the-@uref{https://singularity.lbl.gov, Singularity container <operator-name>Yeah, to be honest I've also just started using nixos and I can't say I undersatnd it either <operator-name>*understand nixos enough to understand how to use nkxpkgs/pull/85463 <bricewge>It's my point of view that Guix is way more understandable that NixOS and hackable <operator-name>see, I come from a haskell background so and all the haskell people I know used nixos so that's what I tried first <operator-name>but I definitely appreciate the difference in philosophy - the tiny bootstrap script, guix pack and so on <rekado>does anyone know where ~/.config/guix/keyrings/channels/guix.kbx comes from? It seems to be missing some keys. <operator-name>In fact the reason I'm committed to learning this right now is because I was experimenting with nix-bundle and got nowhere. <rekado>Guix has a store monad, so Haskellers should feel right at home ;) <bricewge>operator-name: s|doc/guix.texi|doc On the first line <rekado>operator-name: I let my editor darken the parentheses <rekado>ah, the problem is that not all keys are on the key servers <operator-name>bricewge: done. so is that a guix thing or are the changelog docs not complete? <bricewge>operator-name: IDK, just do `git log --oneline doc/guix.texi` to take inspiration <operator-name>I'm assuming your editor is emacs then rekado? I also made the opposite choice to learning vim when I had the time so unfortunately that's out too. <bricewge>You just need to specify the guile's module name before the : <rekado>operator-name: I learned vim first and needed three attempts to switch to Emacs. <lfam>rekado: Did you figure out what makes that keyring? <rekado>I actually switched to Emacs because of Haskell! <bricewge>operator-name: ^ It's vim UI on top of emacs <rekado>…because I read that communication between editor and external processes was nicer in Emacs <cbaines>bricewge, Grafana packaged for Guix is a few months off I think at least <operator-name>I have tried spacemacs in the past, but as you know an editor isn't one of those things you can feel comfortably switching in a day. To be honest I'm still using vscode most of the time anyway <cbaines>bricewge, It's going to take a while to unpick both the Go and Javascript code <cbaines>bricewge, I'm pretty committed to get it done though! <rekado>the encoding problem on issues.guix.gnu.org is due to the environment in which the web server runs. Works fine when I run it interactively on the server, but it looks broken when it’s started by shepherd. <cbaines>Does it need to use a utf8 locale maybe? <operator-name>it's one of these things I'm quite conscious of - hopefully seeing me ask these questions had made you aware the mountain of context and state that one accepts are "normal" *rekado has never used vscode before <rekado>Emacs is nice because we can easily extend it, but we don’t discriminate based on editor preference or habit here <operator-name>`guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master` <bricewge>cbaines: I can imagine, but it's nice to see some work being done on packaging it <rekado>if it’s a trivial change you don’t need it. <operator-name>What does the command do? I'm assuming the intent is to not have any merge conflicts with master? <bricewge>cbaines: I'm wondering how packaging such a beast is done tough <bricewge>cbaines: I mean what is the process to package big web apps <rekado>operator-name: “guix pull” is how Guix builds newer versions of itself. It is how people upgrade their copy of Guix to get access to package updates, new packages, and generally new features of Guix. <rekado>by running it with “--url” you tell it not to build the latest version from the shared repository at Savannah, but to try to build from your current git repository <cbaines>bricewge, I don't think anything like Grafana has been packaged for Guix yet, it uses npm/yarn for lots of Javascript stuff, the process for handling that needs some discovering <rekado>“--profile” tells it to install the results to /tmp/guix.master instead of ~/.config/guix/current <bricewge>cbaines You start with the pre build binary or start form scratch building the package a million time until there is no error? <rekado>operator-name: so when this command eventually succeeds you can be fairly sure that your commit won’t break updates for all Guix users once that’s been pushed to the central repo. <rekado>operator-name: but it is a very slow command and I reserve it for changes that are more invasive <cbaines>bricewge, my strategy so far is to try and get an importer for npm packages (and Go packages). Hopefully that will make packaging the dependencies feasible. <operator-name>oh, it was a guix command. I read it as git and was mighty confused. <bricewge>cbaines: Hoo! That's even nicer, taking the long way. <bricewge>cbaines: Having these importer would help a lot for packaging such web apps <bricewge>cbaines: I hope you succeed with the NPM one since it has been a long time in the making <operator-name>so now i've deleted the thousands of .patch files I accidentally created I think i've submitted the patch <civodul>rekado, efraim: re mumi, nice! it seems to work like a charm now! <g_bor[m]>cbaines: I just had a nice discussion with civodul the other day, and drafted and idea. It goes like this: if we have a stable output importer, then the import can be made a fixed output derivation. <g_bor[m]>From then on we can have another thing which serves as a diff, to make adjustments to what the importer did. <cbaines>g_bor[m], what's the context? Is this about packaging npm things? <g_bor[m]>Yes, I would be willing to try this with npm and go. ***selimcan-i_sani is now known as selimcan
<g_bor[m]>With a bit of additional tooling this would allow us to remove a lot of code, but still ensure the qa guarantees. <g_bor[m]>I was looking for a candidate to see how this would work out, and npm seems like a perfect fit. <g_bor[m]>Quite easy to create a few hundred package recursive import there I guess. <cbaines>I've been looking at the importer for npm that Jelle Licht, roptat and swedebugia worked out at points. <cbaines>One of the things I want to look at next is making the source the git repository, rather than npm, as I think in many cases npm doesn't actually distribute sources. <operator-name>I have to say this experience has made me pretty grateful of git web interfaces such as github and gitlab <g_bor[m]>What I am not so sure about is how to handle version bloat. I believe I would favor a stupid mechanical from the build file importer and allow for explicit version rewrites. <g_bor[m]>And augment the stuff with tooling that suggest version rewrites. <g_bor[m]>That might sound a bit old fashioned, but having explicit control feels like the right thing to do. <jonsger>uff. another hard fight won against git send-email :P <operator-name>git send-email? you think two highly me, for I sadly have not configured my email to work from the command line <lfam>You can use `git format-patch` and send it as an attachment <operator-name>I'm assuming gitlab doesn't meet librejs standards so that's why I've had to hack like it's... let's just say before my time <lfam>I'm looking at the Makefile of GNU FreeFont, and it does something really strange. The primary build targets for 'all' involve creating tarballs that include the current date in their filenmae <lfam>It's not about that operator-name. It's just that this works for most of us <lfam>And setting up something like Gitlab would take a lot of work <lfam>The FreeFont Makefile includes things like this: TTFTARFILE=freefont-ttf-$(DATE).tar.gz <jonsger>operator-name: maybe we need a gitlab repo which bridges the merge request via mail. I would definitly use it :) <lfam>The thing about graphical Git hosting is that it's good for new users and small projects, but the workflow is too slow when there is a lot of contributions <lfam>I've seen this pattern repeatedly from successful Github projects I follow <lfam>The reviewers start to lose their mind <lfam>But, there are problems with what we have now <lfam>So... room for improvement, and invention <operator-name>It's the meta question right, nix and guix allow us to specify dependencies for software but what we really need is dependencies for humans <operator-name>Having given nixos a go I truly believe that these kinds of package managers are the way forwards, but at the same time have been thinking about the new user problem <operator-name>The meme that ubuntu is the beginner distro has truthhood, and when it comes to learning these systems I've really come to appericate those kinds of distros <lfam>have been? Or haven't been? <lfam>Guix is good for new developers or distro people, IMO <lfam>It let me get involved with a skill level that wouldn't have cut it at Debian or Fedora, I think <lfam>The packaging workflow is way more accessible <lfam>But Guix is still pretty obscure for new computer users compared e.g. Ubuntu, as you say <lfam>You don't need to know Lisp or Scheme to make packages <lfam>Unless they are really complicated for some reason <operator-name>To me the issue is similar to teaching fp to those that learn an imperative language as their first programming language <operator-name>defaults matter and have power, and considering most people take the path of least resistance choices such as shepherd and guile do add complexity <drakonis>lfam: you do need it for doing advanced tasks <drakonis>nix has been ushering in a era of people bending nix into doing wild tasks <operator-name>take arch for example, it's basically the default hackers distro. Most arch users I know have accumulated so much "state" that the cost of switching often overshadows any other benifits <drakonis>being a hacker's distro is debatable but sure <lfam>Yes drakonis, you do. We have a long way to go. I'd say a graphical package management UI is important <lfam>I think that "system configuration" is great for hackers and the like but most computer users don't need it... at all <lfam>They need to get online and that's it <lfam>So, making sure that GNOME and XFCE are working well is important for them <mehlon>guix is a meta-distribution.. it's really a set of tools that generate a distribution <lfam>(Can you tell I don't use a DE?) <mehlon>for instance chromium OS was based on the meta-distro Gentoo. chromium is usable for total noobs, but gentoo isn't, ofc <drakonis>right but that's not where this is headed <operator-name>lfam you mentioned debian, but debian is complex because it caters to many types of users <lfam>I think it shows the path forward drakonis <jonsger>operator-name: the good thing about guix is, you can use it while staying on your beloved system <lfam>If we could have a chromium-os style config.scm template, it would be *great* for accessibility <lfam>operator-name: Yes, Debian tries to be everything for all use cases. Guix is similar, but I think we have a greater ability to cater to special use cases, for a number of reasons. <lfam>For one thing, I think we get more "mileage" for the people-power we have available to us <lfam>Our tooling lets us complete and test our work much more efficiently <lfam>In Debian, there isn't even a true source->binary link <operator-name>would it though? I recall watching a (the?) guix talk where the presenter was asked something along the lines of "doesn't the (guix version of nix-env -i) defeat the purpose" <dustyweb>not hexchat, but I was entering them in manually and missed a / <lfam>I don't know what means operator-name <drakonis>y'all need to work a bit more on your config generation game <lfam>Sure drakonis, there is a lot of room for improvement <lfam>The system-level stuff is still pretty simplistic <mehlon>if we're talking idealistically, I'd say the very idea of having a separate PC for every single person is itself problematic, since computers are really very complicated, and yet everyone is expected to administer their own device <lfam>operator-name: Yes, the imperative package management is not really the aim of it. It's recommended to use manifests, and we don't aim to convert the masses with a CLI anyways :) <operator-name>`guix package -i` and `nix-env -i` are friendly, but are also in conflict with the core philosophy <lfam>We need a package management GUI <drakonis>invoking guile scripts in a manner similar to nix-shell would be somewhat interesting though <mehlon>what a coincidence, we were just talking about that in #nixos <drakonis>being able to invoke guix scripts to do things <drakonis>like an augmented guile is what i'm trying to get to <drakonis>nix has seen quite a lot of sucess through nix-shell making it easier to do things <operator-name>mehlon: see, doesn't that just push the can down the road? lfam: an even if there were a GUI, look at GUIs for apt such, wound't they go against the philosophy of unix? <drakonis>the success of nix is its automation features <lfam>I don't think that Guix has much to do with Unix <raghavgururajan>lfam Long story short, I am back home from work. There has been changes to the schedule. <mehlon>I don't think anyone seriously cares about the philosophy of unix anymore <drakonis>being able to invoke them outside of advancing generations <lfam>And, personally, I don't think we really care about the latest cult of "backwards compatibility" being a synonym for "software freedom" <lfam>Which seems to be how the anti-systemd zealots have begun describing that issue <lfam>I mean... look at our filesystem layout <lfam>GUIs are how people compute these days <lfam>Spreadsheets, notebooks, etc <drakonis>the point i'd like to make is to make it easier to use guix features without needing to do rebuilds *raghavgururajan loves unix's design principles/philosophies. Not all though. Minimalism, Simplicity and Modularity. <mehlon>GUIs are how normal people interact with an information system... <lfam>Ah, interesting drakonis. Do you have an example of the sort of problem you are thinking of? <drakonis>from what i recall, you're not familiar with the nix lang <operator-name>drakonis: okay, take the nix lang. C(++) is popular enough that most have learned it, and it delegates the rest to shell scripts <operator-name>Chrome right, it's open source but how many people actually have the ability to understand and make changes? <lfam>A few dozen if not hundreds <lfam>Similar to most complex software <Parra>Hi, I'm trying to cross-compile with Guix, and it seems to be a bit complex. I've seen that zig c acts as a gcc/clang frontend for cross-compiling to darwin, mingw, and other targets, would it be possible to overwrite CC env var or similar, for a given package, so it can use zig instead of gcc? t <Parra>or is there another way I can achieve cross-compiling in guix for unsupported targets? <mehlon>I already see where this argument is headed, and yeah there's something to be said about software freedom and software complexity, but not a lot <drakonis>nix-shell is invoked to execute the language <operator-name>lfam: but that's the thing, even with the dependency graph and "technical superiority" that doesn't translate to adoption <raghavgururajan>operator-name Not necessary. There can be a version that be proof-read by someone that non-technical user trusts (instead of blindly trusting devleoper). That version should be verified with hash. Atleast ideally. <drakonis>there's an example nix expression that can be used to fetch rust in the readme <mehlon>it sounds like you need.... a distributed social graph <lfam>I don't see how that follows operator-name. I'm not sure how that statement is related to issues about software complexity or expense <drakonis>ah this conversation is getting a bit confusing <operator-name>Sorry, let me try to state my intention clearly. I want more people to be using nix/guix, but I'm not hopeful for the future. <mehlon>well I'm already on nixos, and some day Guix will run on my machine too <mehlon>then I'll be able to say, "btw I use guix" <lfam>I think that, like most things, there are levers. Winning users one at a time will not allow Nix or Guix to take over. <drakonis>operator-name: i think you've missed the point of getting the language <raghavgururajan>operator-name I would like that too. More people using guix (not nix though, as it is not FSDG). <lfam>These levers could be, like, how is ChromiumOS built? Who is in charge of ChromiumOS within Google? What about Debian's utterly terrible and obsolete package management? These things can be changed, and that is where you have an impact <lfam>It requires social skills more than technical skills <drakonis>anyways, i'd like to get back to explaining the utility of having an augmented guile environment for interacting with guix <lfam>Well, obviously Debian's package management works fine. But I think the state of the art it represents holds the project back technically and in terms of community building <mfg>i'm currently trying to use font-awesome, but fc-list doen't list it. Any hint on where i should search? <lfam>Did you install the font-awesome package mfg? <lfam>mfg: Hm, I'm not so confident about font things in Guix mfg. But you should try running `fc-cache -rv` <mfg>alright, i will check that out <drakonis>lfam: one of the primary benefits of nix-shell is that it allows for executing arbitrary nix scripts, ie: you could write a script and test it right away <lfam>I'm almost done with the freefont issue raghavgururajan. I see why nobody fixed it sooner <lfam>I'm not sure I get the problem it's solving <drakonis>mozilla has a nix repository that provides nix files for building rust, firefox and other things <drakonis>you can use nix-shell to build these as you need <drakonis>then drop into an environment with the output available <Parra>or is it possible to modify the gnu build system for the packages I'm gonna build <lfam>I don't think it will be necessary for unifont <lfam>Not sure Parra! Maybe restate your question and wait a while, or try asking on <help-guix@gnu.org> <drakonis>you might have an idea of what i'm trying to explain here <mfg>lfam: it works now, thx :) <raghavgururajan>Parra Would you like to modify the phases? Yes, you can. You can skip/delete/alter/add phases of gnu-build-system. <drakonis>lfam: the main gripe i have with running guix is that if i want to change anything, i have to run a contrived set of steps <drakonis>i wrote a new package for my channel? i have to pull it in and hope everything is okay <raghavgururajan>Parra What kind of packages? If they are glib/gtk based packages that required wrapping, you can import modules from glib-or-gtk-build-system. <Parra>raghavgururajan: but I mean modifying all packages compiler <Parra>basically the same you achieve doing: <Parra>I want to do that to all packages that my packages depend on, not just mine <drakonis>i can't use guix facilities for tasks outside of guix <Parra>like modifying the gnu-build-system directly <Parra>so all packages use the modified version <Parra>I don't know, I just want to cross-compile XD <raghavgururajan>Parra Okay, I think I saw somewhere about using clang instead of gcc. But I am not entriely sure. May be rekado could help you with this. :-) <drakonis>better yet, i've seen a nix script that drops me into an environment that is fhs compliant <Parra>I asked this time ago, but recently I saw zig option, it may help on this task <drakonis>so i can run things that dont like nix not having the fhs that everyone else has <raghavgururajan>operator-name mehlon. GUI vs CUI depends on nature of computing. Most high/large tasks are better dealt with CUIs. Example, resize 1000 images at once or performing git operations. <mehlon>I'd say git is the least usable of all command line interface programs <mehlon>anything but basic git add, git commit, git push. requires an internet search to do <ryanprior>If I want to change the name of an installed executable in a guix package, do I edit the build system to do that as an extra step? Or apply a patch to the build scripts? What's a smart option? <lfam>Not once you learn the idioms, mehlon <lfam>ryanprior: I would use rename-file in a new phase after the install-phase. But, we don't usually rename executables from what upstream chose. Only when there are reasons :) <mehlon>well yes but I think git isn't exactly so special that it deserves having to read an entire book just to use it <includeals>We've received an email from GNU GSoC admins concerning the slots distribution <lfam>Perhaps mehlon :) An old debate! *raghavgururajan thinks information systems cannot be interacted in a same way we interact with outside world (graphically/touch etc.). <includeals>and they've recommended GNU social to talk about with GNU Guix about getting that extra second slot <includeals>what would be the preferred way for discussing about that? <ryanprior>lfam fair enough, that seems like a wise thing to do in general. There's a bunch of apps from the elementary OS ecosystem that use a naming system like "io.elementary.sideload" or "com.github.danrabbit.harvey" - for submitting them to guix I think they would be better named eg. "sideload" and "harvey" - what do you think? <lfam>Hm, ryanprior. I guess it depends. Can they be used effectively outside of the Elementary OS GUI? What happens when you try to run them from the terminal on that system? <lfam>It might be a case where we make symlinks rather than renaming <mehlon>oh well guess I'll buy a macbook. For Freedom! <ryanprior>there are a scarce few things I miss about the time I spent using a Mac for work and GitUp is one of them. a Linux port would be a lot of work but a great boon to users. <lfam>I've heard great things about magic, but that is for Emacs <lfam>Magit is apparently magic <ryanprior>Yes Magit is a great interface, but it's not really a GUI per se, it's an emacsy interface for people who like emacsy things. *raghavgururajan is procastinating on learning emacs. <mehlon>a great git user interface, and all I have to do is learn the antiquated emacs system? excellent! <lfam>People seem to be happy there <ryanprior>lfam when you run those from the terminal on elementary OS you have to use the long names like you'd expect. It also has a nice desktop launcher app that lets you quickly launch them by their short names. <lfam>ryanprior: As a compromise, let's make symlinks from the short names to the real executable with the upstream name <ryanprior>The elementary OS apps work just fine outside its ecosystem and could be of benefit to any guix user. <ryanprior>mehlon magit is not a good user interface for people who are not interested in learning emacs. If you haven't followed emacs development though you might be shocked to find how modern it is, though. <drakonis>gotta have better tools that doesnt depend on emacs for everything <mehlon>well maybe we can develop a more modern text editor, and make it a plug-in to emacs <civodul>not all Guix developers use Emacs and there are quite a few Git UIs out there <ecbrown>what is better for scheme than emacs? <ryanprior>lfam symlinks does seem like a reasonable compromise, thanks. Should I add a step to the build system then to create those symlinks? <lfam>Yes ryanprior, after the install phase <mehlon>I still just use the CLI, gitk and git gui in general <drakonis>being able to execute guix augmented guile scripts without needing to rebuild everything would be quite nice <mehlon>I mean, there's really not that much that git does. it's just commits, branches, and files <drakonis>but i'm not sure if it is within the realm of guile right now <ecbrown>drakonis: it is all there in emacs + geiser <raghavgururajan>lfam: I would like to change the font mentioned in %default-console-font in base.scm of services, from "LatGrkCyr-8x16" to "GNU Unifont". What do you think? I would be good since we are GNU-based system. ;-) <lfam>raghavgururajan: You should check out which commit added that code, try understand why they chose it, and decide if changing it to the unifont is a good idea <includeals>raghavgururajan: thanks, just private messaged him :) <raghavgururajan>civodul I had this thought for long time, but kept forgetting. Shall we change to guix's default editor from emacs to nano? The latter is small and installed by default with %base-packages. So it makes sense to prefer it. <drakonis>ecbrown: does that let me instantly drop into a development environment? <drakonis>it would be good if i could install guix on other machines and have a synchronized development environment <TZander>raghavgururajan: I'm not running guix so the default editor isn't really relevant to me. But there is this decades old fight between vim/emacs that makes me wonder why on earth a distro wants to prefer one over the other. That just upsets a lot of peope for no reason. <raghavgururajan>TZander Yes, I am aware of that fight. But the thing I asked if different. Neither vim nor emacs are provided in base installation. So nano would make sense. <TZander>oh, then I misundestood. Yeah, nano is an easy generic one that I think a lot of other distros use as default too <Blackbeard>TZander: for what is worth, emacs is not a text editor but a full lisp environment :) <civodul>raghavgururajan: "guix edit" honors $EDITOR <raghavgururajan>No worries. yeah, when a user install base system does `guix edit`, they gonna be hit with an error. <civodul>but yeah, maybe "nano" is a better default <raghavgururajan>civodul Yes, that is correct. I was suggesting to make nano default. So user can edit $EDITOR to set something elase. <Blackbeard>TZander: well, that's fair. But think of Emacs sort of GTK not just an editor. <TZander>Blackbeard: the difference may be the amount of apps depending on it. Even a KDE desktop ends up installing gtk while its quite common to not have emacs installed. <civodul>raghavgururajan: please send a patch! :-) <mehlon>I have to contest that. Ed *is* the standard text editor, no? <mehlon>wow. that channel has not been touched in 9 years <mehlon>and it still mentions PSYC, from secushare.org <lfam>This freefont thing is really confounding. I'm going to keep the old behaviour with system*, raghavgururajan <raghav-gururajan>Blackbeard I wonder why emacs's default not just be emacs engine and even text-editor can be a plugin/mode to add it. That makes it even more modular. <lfam>I don't know about unifont <lfam>I'm not going to look into it <Blackbeard>raghav-gururajan: probably because it has evolved since the 70's <drakonis>hmm, now that it finally cooled down, developing an augmented script that can interact with the store seems like a good idea, no?