<pancak3>bash is notoriously slow. Dash is built for speed. If you have a ton of scripts it's supposedly worth it. I probably would never notice the difference though. On arch linux I never had an issue with /bin/sh being dash
*nckx lns /bin/sh to dash, puts on the goggles, bootstraps guix.
<pancak3>Honestly, Guix is better prepared than most distros to set /bin/sh to something faster since we got a patch shebangs infrastructure. I still dunno about setting it to the default since normies want scripts they download from the internet to work.
<pancak3>I think the first issue arises at doc/local.mk:100, but I'm really not confident about that
<leoprikler>if everything else fails you can try building guix in a container where /bin/sh is symlinked to bash
<pancak3>Pine64 makes some good SBC. Not sure how they are on Guix but I'd image pretty darn good
<nothingmuch>hah, i sent that right before my bouncer dumped a relevant backlog on me too =)
<nothingmuch>yeah pine64 looks real nice, and beagleboard too, and i seem to have misplaced my shortlist from the other day, one sec... i got overwhelmed with options and it's hard to look up information on freedom and compatibility
<str1ngs>sneek: later tell guix-vits. Hello, in regards to Nomad C-e issue with buffers and the minibuffer. Turns out this is a deeper problem then I thought. Originally I thought it was emacsy related but it's more related to (ice-9 gap-buffer) which is what emacsy underlying for buffers. I'll have to think more on how to best handle this.
<str1ngs>xelxebar: I'll probably just let the substitute server finish so not to long now. since I always have a hard time getting guix archive to work in terms of transfer and using on the substitute server.
<xelxebar>Oh dang. Your local machine already finished??
<xelxebar>No problem. If I built myself, it would take me until this evening... if the build didn't fall over again.
<str1ngs>xelxebar: yes it took longer to decompress and patch then to build lol
<sneek>guix-vits, nckx says: I added (service elogind-service-type) to my system configuration and rebooted. System works fine. elogind is running.
<sneek>guix-vits, str1ngs says: Hello, in regards to Nomad C-e issue with buffers and the minibuffer. Turns out this is a deeper problem then I thought. Originally I thought it was emacsy related but it's more related to (ice-9 gap-buffer) which is what emacsy underlying for buffers. I'll have to think more on how to best handle this.
<str1ngs>guix-vits: disregard that I have a fix now. just need to test it out make sure it's okay. since it's a change to emacsy
<guix-vits>sneek later tell nckx: Thanks. I need to try this again.
<ArneBab_>I still remember how annoyed I was to see "just get Guix". Now I have Guix and I say that myself, because Guix is just so convenient … :-)
<str1ngs>guix-vits: oh that's not to bad. though on your laptop that could change.
<guix-vits>I didn't measured this. Also i didn't ran into any substitutes for linux-libre-arm64-generic (again, that linux-libre didn't worked for _me_ isn't a thing). The making of .xz is near 1 hour. And so for compilation (if not more). Did not measured, though.
<str1ngs>guix-vits: ah that's what I was looking for I can maybe provide substitute for that if you need it.
<str1ngs>guix-vits: right now I'm running guix system build on that declaration encase you need substitutes.
<ArneBab_>str1ngs: is there a chance to get gecko support? Or is Firefox too unstable for that?
<guix-vits>str1ngs: BTW, that plastic thing for applying a thermal paste is good to remove the eMMC from that board.
<str1ngs>ArneBab_: the problem right now regards to gecko is it uses xulrunner. which is terrible to use as a widget. it's why nobody users it. though I do have hopes for servo which is like next gen experimental.
<str1ngs>firefox has potential it was my daily driver but now I use Nomad. and now and again I need to use firefox because when Nomad is ambitious for one person to develop. so it still lacks features
<str1ngs>like downloads only semi implemented because of an issue I need to track down in emacsy.
<str1ngs>ArneBab_: thanks for the link this is insightful.
<ArneBab_>I think so, too. It shows how completely sensible design choices (using a quick unrestricted API for extending) can have high cost later on. How important it is to design the extension API instead of just allowing access to all internals.
<ArneBab_>I got the link in #freenet, because there we have a very similar problem: plugins have access to all internals, so any change we do can break any plugin.
<str1ngs>ArneBab_: I'm reading this thing about addons. and I'm thinking to myself hmmm you can modify anything in Nomad while it is running.
<xelxebar>How can I get a hold of the config used to build linux-libre?
<ArneBab_>str1ngs: Emacs shows how such a model can work, but even there API changes are hard. I’ve had repeated config breakage. Still I wouldn’t want to lose it.
<guix-vits>ArneBab_: addons in Firefox are silly: "Sorry. Your CSS will not work on this page, this is insecure!", "Your keybindings will not...". rrrr...
<str1ngs>ArneBab_: after some philosophical thinking on that. I realized that it's okay for users to break things. I just need to becareful once I get out of alpha phase not to change API much. I'll probably have a version 1.0 API freeze
<xelxebar>guix-vits: Oops. Forgot to mention that I am on a foreign distro.
<ArneBab_>after reading the blog post I understand why they got there. Still I think FF forgot the importance of power-users. That these are the ones who drive your usage.
<str1ngs>ArneBab_: apologies Nomad is still pretty alpha and quite the moving target yet. currently there is a 0.2.0-alpha. which should build. also build from git on the devel branch has all the minor fixes for 0.2.0 series
<ArneBab_>str1ngs: do you keep the guix package updated?
<str1ngs>ArneBab_: I keep them updated at certain mile stones. the current nomad in guix uses g-golf is now 99% scheme. so that was a milestone. and I plan for a new point release soon. so submit a patch to update nomad then in guix.
<str1ngs>ArneBab_: also I've been working on package for guix like qtwebengine and the later qutebrowser to switch to qtwebengine by default. as a side effect on looking for backends for nomad.
<ArneBab_>what’s the difference between qtwebengine and webkitgtk?
<guix-vits>ArneBab_: I think those are different engines: `guix show qtwebengine| recsel -p description`
<str1ngs>qtwebengine use the blink render which is basically google chromes fork of webkit but as a QT widget. so it's pretty much like using chromium from QT also its C++. webkit is GTK fork of webkit but as a GTK widget, with other GLib classes for varies web related tasks it interface is C.
<str1ngs>also use GStreamer all the things GTK related.
<str1ngs>also little know fact Apples webkit was originally fork from khtml. so ya qtwebengine literally went around the block.
<xelxebar>str1ngs: Well, the only way gc could check for a moved symlink is to scan the entire filesystem, no? My guess is that the symlink path is stored somewhere, and if missing, then the root is potentially available for garbage collection.
<xelxebar>Yeah, but I want to prevent gc from collecting the build, so moving doesn't seem like an option.
<str1ngs>I tested with guix build -r ./test make . the produces test-0 test-1 the link to /gnu/store/4k33n2nhsnnaxk2ip75gj7xiqdjns5hq-make-4.3. guix gc -d /gnu/store/4k33n2nhsnnaxk2ip75gj7xiqdjns5hq-make-4.3 removes the stall info and deletes the build
<xelxebar>Is there a frontend for moving roots around?
<str1ngs>normally you don't have to worry about roots they are used via profiles
<str1ngs>either system guix-profile or current-guix
<xelxebar>str1ngs: Well, I want to make sure the linux-libre build you gave me doesn't get garbage collected.
<xelxebar>But I just don't like the location where I originally created the symlink
<ArneBab_>str1ngs: ah, thank you! I knew that webkit came from khtml — back then I watched the fight of KDE to get Apple to release the code of their fork. Case in point: If it weren’t for the LGPL, we wouldn’t live in a world in which all relevant browser engines are free software.
<guix-vits>xelxebar: if linux-libre isn't installed, it can be gc'ed
<xelxebar>I created a vm with guix system vm --expose=/foo/path. When the host creates new files under /foo/path, the guest sees these. However, when modifying files, the guest does not immediately see the changes.
<c4droid>guix-vits: Sorry, it my fault, scandir typed sacndir..
<xelxebar>What's going on here? Caching of some sort?
<guix-vits>Sorry. Probably i better take a book instead of app, then :)
<leoprikler>"will" is the verb "want". E.g. "Will ich Guix auf meinem Pinebook installieren?" -- "Do I want to install Guix on my Pinebook?"
<apteryx>mothacehe: do you think it'd be reasonable to turn substitution off by default for the image record in (gnu image)? These are typically large files, and not so costly to generate anymore, right?
*zzappie just realized that `guix environment` setups inputs of a package only... Now I get the full power of --ad-hoc
<pkill9>zzappie: i think that may change at some point, so by default it does --ad-hoc, there was talk on the mailing list
<apteryx>civodul: it's the default, but if you supply your own list of options, it gets lost.
<guix-vits>zzappie: Use profiles. First: "guix environment" can be garbage collected. Second: after guix pull You may wait before new version being maked. While in profile the old version will be there.
<zzappie>thre could be ab ambiguous situation with -l. I once expected that ill get the package defined in file defined in environment and did not know that --ad-hoc has effect on -l flag
<terramorpha>Hi everyone! I'm trying to create a package definition for a very small bash script I created. In theory, I wouldn't need to set the "source" field in the package definition because the script's content is embedded in the scheme file. However, when I run `guix build <script-name>`, guix complains that I need to set the source field. Is there a way to work arount that ?
<apteryx>IMO, we should turn defaults into true when #f, so that if we pass the options parameter without overriding them, their value remains #f.
*nckx welcomes fitzsim, who is interested in the fledgling Guix ppc64 port.
<guix-vits>nckx: "whispers words of whisdom: let it beee"
<terramorpha>do I just have to put the #~(...) bin in place of the origin statement ?
<daemonspudguy>I'm trying to install GuixSD but can't get past the network connection part. I am on Wifi and need to type in a password. But the installer hangs on "Connecting to [SSID REDACTED], please wait". Any help?
<nckx>daemonspudguy: This sounds very much like a bug that might be fixed in http://guix.gnu.org/download/latest/ . No guarantees (not even of merchantability! or fitness for a particular purpose!) but it's worth a try.
<leoprikler>Hmm, apparently you're the only one who got sneeked in that drama. Consider yourself honoured 🙃️
<raghavgururajan>leoprikler, I was doubting it could be that. But not sure where is that variable @storedir@ resides.
<Kimapr[m]>How do you replace packages in guix modules from other modules and is that possible at all? I want to have a module that wraps gcc in a script that constantly retries gcc command if it crashes with an internal compiler error
<Kimapr[m]>So can i replace variables in arbitrary modules from other modules?
<hendursaga>So, I'm trying to package something and it fails, presumably because there are no tests. What's a nice shortcut to go to the source directory so I can manually check if there are any tests? I have Emacs-Guix installed, too.
<zzappie>hey anyone got strange output with patch-shebang function? For some reason make's output and patch-sheebang output are mixed together... Even though they are invoked sequentially (first patch-sheebang then (invoke "make ...")
<leoprikler>hendursaga: guix build -K; then cd to the directory that was created
<nckx>I don't get the ‘x is paid to y’ meme. We're literally a movement built from nothing by people putting in hours and hours of hard work for free(dom), and for fun, but anyone disagreeing with me on the Internet must be getting a cheque in the mail, because I am important.
<nckx>zzappie: Assuming they're both from the same build, it's possible they are buffered differently.
<lfam>raghavgururajan: The problem that Guix has with Electron and NPM is that software like that is extremely hard to package with Guix. Although the source code is free, the dependency graphs have thousands of nodes, and there are cycles in the graph; Guix cannot handle cycles. I think that the Delta Chat team will probably not see this as a problem, so they will not be interested to port their software to another language ecosystem
<lfam>I do think it's worth saying that, but not pushing them too hard
<nckx>raghavgururajan: TBQH, I feel a bit put on the spot by asking to join in a conversation that I didn't start, about I client I'd never heard of before, using Electron which I just want to ignore until it quietly dies.
<raghavgururajan>lfam: True! I was not meaning to force them or anything. Just wanted to let them know what are struggling with. So that if they hear something same from other distros, they might consider porting.
<pkill9>i don't understand how a cyclic depnedency can exist
<Tirifto>Thank you, lfam. I got into a funny situation where I added ‘/usr/local/bin’ at the front of my path, so that my programs would run in Firejail, but it turns out ‘guix’ is also linked to what appears to be the root’s binary there, so I guess I’m calling that one now. :)
<lfam>Tirifto: Hm, yes, in some cases you might end up with '/usr/local/bin/guix'. I believe the binary installer script still does that (not sure!) In general, '~/.config/guix/current/bin' should come first
<leoprikler>what about option c: configure firejail to ignore guix paths?
<nckx>Tirifto: /usr/local/bin/guix is there so any user can immediately run ’guix’ without manually mucking about with $PATH. But you can put it anywhere, no part of Guix (like guix-daemon.service) relies on *that* symlink.
<Tirifto>nckx: That means I can safely remove /usr/local/bin/guix, which shouldn’t break anything (for my user which has other links set up in PATH) and it shouldn’t come back again later?
<nckx>Rename it to guix-local or whatever if you're worried but that should be correct.
<nckx>Put differently: if you're already using Guix and ‘guix pull’, and you suddenly can't run ‘guix’ anymore because it was looking in /usr/local/bin, your system was *very broken* anyway and you should be happy you found out 😉
<Tirifto>Oh, it looks like ‘hash’ then prints whatever you gave ‘hash [arg]’.
<nckx>Sorry to nitpick, but this subtlety is exactly why it's all so confusing: ‘which’ will not be affected by hashing, it looks only at $PATH, so it may print something totally different from what your shell will actually run. ‘hash foo’ clears the shell's cached last-used ‘foo’ file name and looks it up anew. ‘type foo’ is a shell built-in and uses the same hash table, so it should always print what the shell would run.
<nckx>For extra fun: ‘which’, which is a stand-alone binary and could be called from other shells unlike bash's built-in ‘type’, just re-implements ‘the same algorithm as bash’ (man which). So it will still return subtly different results if you're lucky. At least the jank is portable!
<hendursaga>lfam: Does Rust/cargo has cycles in their dependency graphs?
<lfam>hendursaga: Yes, but Guix "cheats" when dealing with it. It's kind of a problem, because it breaks a lot of features of Guix, but the status quo (the code has been added to Guix) tends to prevail
<lfam>And ridiculously sensitive to minor version updates
<lfam>I don't really see a future for Rust on GNU/Linux distros unless that changes
<hendursaga>Oh, yeah. The sensitivity. I haven't messed with Rust too much but that was a worry of mine.
<lfam>We have a nifty "semantic version"-aware importer, and that's really the only thing that makes it possible to package Rust software in Guix
<lfam>Otherwise... it would be a full-time job to package a single program
<str1ngs>lfam: go language is kinda the same boat and I like go.
<lfam>I worked on packaging the rav1e program and it required thousands of lines of new code, for ~250 new packages. Just for a video codec. If it was written in C it would have been a single package
<str1ngs>lfam: I think they rely more on there own tooling and distro's are an after thought.
<lfam>Go is similar but the scale is less, and there are no cycles
<lfam>Go is older so they've had more time to mature. Hopefully Rust gets there
<str1ngs>also with go mod. the philosophy is more inline with how guix works. though I can't speak for rust.
<guix-vits>nckx: while me, adding elogind to the (services, gets a cgroup: Unknown sussys name 'reezer'.
<sneek>Welcome back guix-vits, you have 5 messages!
<sneek>guix-vits, nly says: best thing in your whole life!
<sneek>guix-vits, nly says: "Tell me, Do you even geek?" You will!
<sneek>guix-vits, str1ngs says: Yes emacsy-mode-line is ideal. We need something that truncates the uri to manageable length. I'll at it to my TODO list at latest.
<sneek>guix-vits, str1ngs says: also buffer-name for <web-buffer> is kinda meh. That's a hard one to figure out though.
<sneek>guix-vits, str1ngs says: another option is to remove uri from emacsy-mode-line generic method altogether. since M-x: current-url exists. Not sure how useful truncating is ultimately.
<raghavgururajan>apteryx: You mentioned that gnome-maps does not work outside gnome right? I have fixed it. Soon will be available in master.
<apteryx>raghavgururajan: I asked because I was wondering if a ticket about it could be closed. Thanks for taking care of it!
<apteryx>civodul: I was surprised to find reconfiguring my system trying to send gigabytes of data through my meager 10 Mbps uplink connection at home (the images were being generated for the hurd-vm service) to my offload machines.