IRC channel logs


back to list of logs

<str1ngs>guix-vits: I don't think you can package qtwebengine differently in the context of build less build heavy
<str1ngs>if you want something that not to build dependent I'd recommend something based on webkitgtk. epiphany if you like scheme.. nomad :)
<pkill9>how easy would it be to build the tor browser for guix? it's really just firefox but modified to reduce fingerprinting identification, so maybe it could just be built with icecat?
<morrigan__>I'm trying to do a headless config with just dhcp, it's telling me networking is not provided by any service. It's been a while since I've done any admin stuff; what services provide networking?
<guix-vits>str1ngs: thanks.
<str1ngs>guix-vits: god knows I tried when I created the qtwebengine package :)
<palpares>dftxbs3e: yop guix might be a good choice for server. however not sure guile would be appreciated by system admins
<morrigan__>Would dhcp-client-service-type do it?
<guix-vits>pkill9: Aren't the tor-browser isn't packaged in any distro yet?
<morrigan__>Hey it worked
<str1ngs>guix-vits: I think webkitgtk is probably the best of the bunch for build time and usefulness. currently it takes about 20min on my ryzen 5 3600 6 cores and 6 threads. I'm using webkitgtk-unstable with nomad.
<emsyr>morrigan__ I think network-manager-service-type should do the work.
<str1ngs>guix-vits: though qtwebenine is probably the better renderer in terms of performance. provided you have hardware acceleration.
<morrigan__>emsyr: thanks
<morrigan__>It's headless and online, perfect
<pkill9>dunno guix-vits
<emsyr>morrigan__ you're welcome. I'm glad if I helped. Keep up the good work...
<dftxbs3e>palpares, why not
<morrigan__>I like Guix a lot. Hoping to figure out how to use Docker w/ Guix
<bdju>guix pack might help
<emsyr>morrigan__ just did a search for docker and found it is already in guix packages.
<morrigan__>emsyr: it is! I'm reading the tutorials
<OriansJ>well we literally are able to make docker images so that is kinda expected
<valignatev>I really like these self-contained tarballs that guix can produce.
<raghavgururajan>Hello Guix!
<apteryx>raghavgururajan: o/
<brettgilio>Hey all!
<brettgilio>Sorry for my unexpected leave from Guix. Life was pretty miserable for a bit. I am good now though. Work was treating me terrie. I am back.
<raghavgururajan>brettgilio Glad you are okay and back.
<brettgilio>raghavgururajan: thank you man
<brettgilio>Shit got really wild
<brettgilio>My boss was harassing me.
<brettgilio>But it worked out well. I have a better job now, with better pay
<raghavgururajan>Woah, that's bad.
<raghavgururajan>That's nice to hear.
<brettgilio>I hadnt touched my Guix machine in weeks because all of this change was eating up all of my time.
<brettgilio>So I am easing myself back in
<brettgilio>nckx: o.
<nckx>…and wow. OK. Glad you're on the other side of that mess.
<raghavgururajan>I have recently committed a sin.
<raghavgururajan>I switched to Trisquel on my daily-driver laptop.
<brettgilio>nckx: bandali raghavgururajan tldr. They changed my working schedule without notifying me. They were going to write me up for taking leave when my kid was born. They got mad at me for saying that was bullshit, and wrote me up for insubordination. They would pester me nonstop. So i left. And thank god.
<brettgilio>My new job is Backend dev in C and Java. Not my fav langs, but it pays better and the people are nicer. So ill take it.
<raghavgururajan>Within 1 hour I missed Guix and swicthed back to Guix.
<brettgilio>raghavgururajan: after using guix, all non-guix stuff feels messy.
<nckx>raghavgururajan: Now that's what I call a happy ending.
<brettgilio>Guix is hygienic.
<raghavgururajan>brettgilio Sorry to hear that.
<bandali>brettgilio, messed up indeed
<raghavgururajan>nckx Yeah.
<bandali>you deserve much better
<raghavgururajan>Dear Guix, please forgive my sins. I will never leave you again.
<raghavgururajan>Do we have Guix Father? xD
<KE0VVT>raghavgururajan: Why Trisquel?
<KE0VVT>raghavgururajan: St IGNUcius?
<nckx>brettgilio: Good god. And good riddance.
<raghavgururajan>KE0VVT Stability. I have something to say regarding Guix. I will be sending an email to guix-dev soon.
<nckx>The past week has not been a great one for Guix stability.
<raghavgururajan>nckx Yeah, I know. But Guix always recover from it. 🙂
<brettgilio>*flashback to when the build servers were dead for several weeks*
<KE0VVT>Just roll back, right?
<raghavgururajan>KE0VVT About that.. Hmm.. Let me compose and send the email now. 🙂
<KE0VVT>Every OS Is Junk™
<nckx>Yup. All software sucks.
<morrigan__>guix is throwing an `unknown keyword or bad argument` error on a `#:use-module` line
<morrigan__>Oh I misspelled it false alarm
<raghavgururajan>E-Mail Sent.
<morrigan__>I'm currently trying to write a package... what does "source expression failed to match any pattern" mean?
<raghavgururajan>nckx Well, let's suck less then. 😛
<nckx>We already do. But yes, let's.
<raghavgururajan>Yes, we do.
<nckx>morrigan__: It usually means that you used an invalid field name in a (package) record, or that you're nesting's wrong (forgotten bracket) so that something is interpreted as a field that isn't. Impossible to say without context.
<raghavgururajan>morrigan__ I think it's regarding how you express source URL and protocol.
<nckx>FFS, you're.
<morrigan__>nckx: I think I messed up my nesting
<nckx>raghavgururajan: No, it's not that.
<nckx>morrigan__: If you can't find it, paste your source (to a bin) and we shall help.
<nckx>raghavgururajan: It's a Guile error, ‘source’ is not related to the Guix record of the same name.
<raghavgururajan>nckx Ah I see. Thanks.
<morrigan__>nckx: yeah I wound up figuring it out. Always ask ddg first
<morrigan__>I'm packaging writefreely btw. No idea if Guix will want it once I'm done, but that's what I'm up to
<nckx>morrigan__: We certainly will! (…unless there's something fundamentally objectionable about your package itself.)
<morrigan__>nckx: well it might be extremely sloppy
<morrigan__>given this is a first attempt
<morrigan__>For a git package, how do I get the base32 hash? The one I got from `guix download` is throwing an error
<nckx>morrigan__: Best-effort WIP packages are also welcome at guix-patches@.
<nckx>morrigan__: guix hash -rx in a *pristine* checkout.
<nckx>morrigan__: …or just copy the ‘found’ hash from the error message.
<morrigan__>nckx: does -rx include dotfiles?
<nckx>morrigan__: Yes. Which you want it to.
<morrigan__>Okay, so just git clone the repo and then hash it
<nckx>morrigan__: It might be guix hash -rx . (with dot), I forget.
<morrigan__>nckx: It needed a ./
<morrigan__>It's throwing an error when I give it `agpl` in the license field
<morrigan__>Is there a way I can just list the available licenses?
<morrigan__>I know the AGPL must be in there
<nckx>I just use ‘grep define guix/licenses.scm’.
<nckx>morrigan__: You need to say which AGPL version: agpl1, agpl3, or agpl3+.
<morrigan__>Oh no the source doesn't say whether it's 3 or 3+
<morrigan__>I'll assume 3
<morrigan__>Okay whew. Now for the build system
<nckx>morrigan__: If it doesn't include the ‘at your option…any later version’ wording, it's 3-only.
<morrigan__>How do I read the build logs? Are they just bzipped?
<morrigan__>Oh, they clearly are
*nckx → goto bed;
<nckx>Good luck morrigan__.
<morrigan__>nckx: Thanks. I might have it from here.
<morrigan__>That or I'm hopelessly lost
***wxie1 is now known as wxie
***goldenshimmer[m] is now known as goldenshimmer
<morrigan__>welp, I've also packaged go-bindata
<morrigan__>If anyone's online I'm a little lost
<guix-vits>morrigan__: hi, maybe you'll get some use of ...
<bandali>what seems to be the issue?
<morrigan__>I'm trying to package something with an unusual but not very complicated build process
<bandali>do go on :-)
<morrigan__>Following the AUR package: Trying to duplicate this AUR package:
<morrigan__>Source github:
<KE0VVT>raghavgururajan: Received. Thanks.
<bandali>hm, i see it depends on two nodejs packages
<KE0VVT>Ei, ei, ei!
<bandali>i'm not sure about the state of node and generally js packages in guix :-/
<KE0VVT>A nightmare.
<morrigan__>I've already packaged `go-bindata` and `nodejs` can fill the other node dependencies so long as the base package is current
<drakonis>node importer here we go
<morrigan__>Oh no have I stumbled into something messy
<drakonis>node has deps to the tune of a cool thousands
<morrigan__>o_o I never realized
<drakonis>recursive dependencies.
<morrigan__>drakonis: wait, do you mean nodejs itself or node packages?
<morrigan__>I know the state of node dependency chains is nuts
<guix-vits>bandali: how did you find out it needs nodejs?
<morrigan__>Yeah okay
<bandali>guix-vits, saw in the pkgbuild file morrigan__ linked above
<bandali>it seems to make-depend on nodejs-less and nodejs-less-plugin-clean-css
<morrigan__>I was mistaken. It's not base node, but `nodejs-less` only depends on base node and npm
<morrigan__>The other dep doesn't go too deep either. It depends on nodejs-clean-css, which depends on base node and npm
<bandali>ah, looks like we have (gnu packages node) and (gnu packages node-xyz)
<drakonis>node itself isnt the issue anyways
<bandali>okay, so i'd look writing package definitions for those two nodejs-less packages in node-xyz
<morrigan__>Yeah, I think I can handle that
<bandali>looks like their dependencies don't run deep luckily
<morrigan__>Does Guix not have npm
<morrigan__>oh it's in node
<morrigan__>Shows what I know about Javascript
<guix-vits>bandali: github page claims: "you only need to be able to run an executable.". And tags have no JS. Why?
<raghavgururajan>KE0VVT Cool!
<OriansJ>morrigan__: we tend to reduce the number of binary blobs possible in guix
<bandali>guix-vits, what OriansJ says. we generally don't use any pre-built binaries in guix
<bandali>so, our package definitions build everything
<bandali>the main chunk of writefreely is go, but it also seems to have some JS bits too
<bandali>but in particular, those two node packages seem to be required for compiling LESS style files into plain CSS
<guix-vits>bandali: lessc is dependent on JS?
<morrigan__>Is it better practice to pull node packages off github or from the npm registry?
*guix-vits will try to ask less questions, to not mess with the work.
<bandali>morrigan__, the ones in node-xyz seem to all get the sources from github
<morrigan__>bandali: I'll go with github then. There's better versioning, in any case
<bandali>guix-vits, it seems so:
<bandali>and no worries about asking questions
<guix-vits>bandali: thanks.
<morrigan__>Trying to build from non-master branch. How do I specify that?
<bandali>the (commit ...) field actually takes any git ref
<guix-vits>morrigan__: all but "develop" branches are stale.
<guix-vits>sorry, fake news.
<morrigan__>guix-vits: the master branch was failing tests
<morrigan__>Not sure how critical they were but 3.11.0 is passing
<bandali>morrigan__, also, if you see packages through guix, there are tons of examples of specifying a version tag from git
<morrigan__>bandali: yeah I figured it out
<morrigan__>Sorry I have a bad habit of asking questions and then immediately realizing the answer
<KE0VVT>bandali: Hm. Less CSS is kinda cool, but the complexity might not pay off.
<bandali>morrigan__, haha no worries
<bandali>KE0VVT, right, it can definitely be handy for large amounts of js. another similar thing is SCSS
<bandali>but yeah while some of less or scss's features like nesting are handy, i personally prefer to keep things as simple as possible and use plain css
<morrigan__>guix package is telling my my base32 hash is invalid
<bandali>how did you calculate it?
<morrigan__>`guix hash -f base32 -rx .` in the repo
<bandali>hmm, firstly, not sure if the `-f base32' is necessary
<bandali>did you remember to `git checkout' the right branch or release tag before running `guix hash -rx .' ?
<morrigan__>bandali: it defaults to nix-base32, which will yield a different string
<morrigan__>I can give that a go
<morrigan__>But the hash should validate the repo as-downloaded, no?
<bandali>well, the contents of the repo :-) which depends on part on the active branch
<bandali>*in part
<morrigan__>Okay, I'll try that
<morrigan__>Still telling me it's invalid. I'll try with the nix hash
<morrigan__>Okay that's working
<bandali>can you give us the repo address, and perhaps paste your package definition you have so far in a paste service?
<bandali>mainly, i'd like to see how you're specifying the hash in your package definition
<morrigan__>I'd have to set up desktop services in the VM
<morrigan__>But I think I've got it now
<morrigan__>Actually, does Debian's pastebin service let you push from the command line?
<bandali>hmm, not sure
<bandali>but yeah you can check some examples in the (gnu packages node-xyz) module for specifying the repo hash
<bandali>time to hit the hay
<bandali>night y'all o/
<morrigan__>Huh. So I finished writing the definition, and it shows up when I `guix package -s` but...
<morrigan__>ah darn
<bandali>i can maybe take one more question :p
<bandali>morrigan__, but what?
<guix-vits>morrigan__: pastebinit -l shows debian's in
<morrigan__>When I `guix package -i` it gives me an unknown package error
<bandali>yeah at the point it'd be best to give the package definition :-)
<morrigan__>Okay, I'll try to push to the pastebin
<bandali>but as a shot in the dark, make sure your definition has a (name ...) field
<morrigan__>Oh my god lol
<morrigan__>I assigned it a different name from its package name
<bandali>nice :p
<bandali>good luck with the rest
<bandali>night o/
<morrigan__>Good night!
<morrigan__>Thanks for helping out
<bandali>cheers! o/
<morrigan__>Welp, the build failed and the error message is out of my league. I think that's a signal I should stop for tonight
<morrigan__>A desktop is up! I have two node packages that failed for the same reason, which I'll look into tomorrow
<g_bor[m]>hello guix!
<g_bor[m]>I am about the end of packaging postfix finally.
<g_bor[m]>There is one problem I face right now.
<g_bor[m]>I would need to add setgid 'postdrop' programs to the os to get rid of the warnings.
<g_bor[m]>Don't get me wrong, everything is working right now, when using root to the stuff, but that's not what the users expect.
<g_bor[m]>Right now the setuid programs stuff seems to be limited to setuid root.
<g_bor[m]>I would propose extending it so that setuid and setgid to the user and group designated would be possible. Wdyt?
<guix-vits>g_bor[m]: so `postfix` will be own by postfix:postfix and runnable by users?
<g_bor[m]>guix-vits: actually postqueue,postdrop and maildrop should have a group postdrop and be setgid.
<g_bor[m]>These are the least trusted parts of postfix.
<g_bor[m]>This would allow separating mail admins to a group.
<guix-vits>it will be an improvement, according to Wikipedia :)
***Noctambulist is now known as Sleep_Walker
<raghavgururajan>g_bor[m] o/
<janneke>g_bor[m]: that sounds good
<janneke>is it a big change?
<bricewge>Hello Guix!
<bricewge>The shepherd page is not clear enough about where to send patches, is it guix-patches as usual?
<raghavgururajan>janneke I wanted to ask you something. Would you be able to share the system config you used for sway setup please?
<dftxbs3e>hmm, an interesting discovery I made regarding bash-static removed store reference in gawk is that it appears only in powerpc64-linux-gnu output, not x86_64-linux-gnu.. weird.
<janneke>raghavgururajan: i haven't used sway, i am using exwm
<raghavgururajan>janneke I see. Are you using %base-services or %desktop-services?
<janneke>dftxbs3e: ah, the plot thickens...
<dftxbs3e>oh hey!
<janneke>raghavgururajan: usually %desktop-services, to be able to run the occasional gimp, evince, totem or eog
<janneke>dftxbs3e: saw your mail this morning and then forgot to reply until i saw you here :)
<janneke>raghavgururajan: but for a fresh install i sometimes start with %base-services
<dftxbs3e>janneke, I'm glad you even replied the first time. Feeling a bit helpless on this port :-S
<dftxbs3e>bricewge, hi :-)
<raghavgururajan>janneke Ah I see. Thanks. Will those apps work with just %base-services and *dm-service-type?
<janneke>i know the feeling ... things took a while for me to make sense
<dftxbs3e>bricewge, looking at - I believe so. If it's not right I think people will be kind enough to tell either way!
<janneke>raghavgururajan: i haven't figured out, really, but that's my impression
<raghavgururajan>janneke I am looking to setup desktop-like environment with dm+dmenu, slim-service-type and %base-services. What other service should I be needing?
<efraim>dftxbs3e: is there a grep-boot0 for intel systems now in core-updates? might be easiest to just use some of those new packages and remove them from static-binaries
<janneke>raghavgururajan: there's this *-schemas thing and gio-* binary from glib that sometimes prevent applications from starting
<raghavgururajan>janneke Ah I see.
<dftxbs3e>efraim, what do you mean? Also, I didnt use core-updates as a base because core-updates is broken in all kinds of other ways not related to powerpc with bootstrapping.
<dftxbs3e>at least, it used to be, and I didnt have quite the knowledge to figure it out.
<efraim>dftxbs3e: i got farther on core-updates than on master. janneke added a bunch of *-boot0 packages to core-updates that could be useful to smallerize the bootstrap binaries for new architectures
<dftxbs3e>efraim, really! well..
<raghavgururajan>janneke Via window-managers, how do you control volume?
<janneke>yeah, sorry for breaking those with my merger -- i hope that i'm learning :)
<janneke>efraim: currently, we go from "grep-mesboot" straight into "grep-final"
<dftxbs3e>mesboot isnt used for any other arch than x86 and maybe ARM, correct?
<janneke>i think grep-mesboot can be seen as an early grep-boot0
<efraim>oh, I thought there was a grep-boot0 also
<efraim>i just assumed since there were a bunch of others also
<janneke>dftxbs3e: correct, not even ARM just yet, but real soon now
<janneke>efraim: i had to look, a bunch of *-boot0 were added
<janneke>i did that demand-driven; apparently grep-boot0 was not necessary
<janneke>but no harm in adding it, certainly not as an experiment for ppc
<bricewge>Hey dftxbs3e!
<dftxbs3e>can't wait until all of GNU Guix is based on gcc-9 so all options required for POWER to go well are enabled.
<efraim>at the very least I would guess adding a grep-boot0 as an input before %boot-inputs should make it be first
<dftxbs3e>I've purchased 6 more sticks of 32GB of RAM, once GNU Guix works I'll run Cuirass and fix everything
<raghavgururajan>efraim I just came across your system config I have a doubt.
***apteryx is now known as Guest30736
***apteryx_ is now known as apteryx
<efraim>macbook41_config might not work, that machine overheats and I haven't booted it in at least 2 months
<efraim>E2140 and E5400 do work for sure though
<raghavgururajan>efraim I see that you have removed bunch of services from %desktop-services. Instead of that, if you were to use %base-services, what other services from %desktop-services would be adding to your system config?
<janneke>dftxbs3e: you got mail
<dftxbs3e>janneke, read already :-)
<raghavgururajan>efraim Same case with E5400.
<dftxbs3e>janneke, is rewriting strings inside binaries going to be safe anyways?
<efraim>looks like there's actually a whole bunch that I do leave
<raghavgururajan>efraim Yes, I have looked at it. My doubt is how do you declare some of those services outside of %desktop-services?
<janneke>dftxbs3e: only if you're careful ;)
<efraim>I'd add them the way they're listed in %desktop-services, like (service colord-service-type)
<janneke>but then again, being careless is not always safe
<dftxbs3e>janneke, I'll have a try at this heh. I'm a Scheme noob so excuses in advance, does substitute* take a list? is that why you provide ((find) (replace))?
<raghavgururajan>efraim Ah I see. Would the desktop (englightment in your case) work with out services in "The D-Bus clique." block?
<efraim>I'm pretty sure enlightenment uses dbus and avahi and some of the others. At least we build it that way
<raghavgururajan>efraim I see. Thanks. If I am using just window-managers with slim, do I still need services mentioned in "The D-Bus clique." block?
<efraim>raghavgururajan: that I'm not sure about. I suppose it would depend on what you're willing to live without
<janneke>dftxbs3e: yes, (("regexp1" ...) "replacement1") (("regexp2" ...) "replacement2"); have a look at a pattern that matches what you need
<janneke>dftxbs3e: are you using --system=powerpc64le-linux ?
<raghavgururajan>efraim I was wondering if display managers (any) work without accountservices, polkit, and elogind.
<dftxbs3e>janneke, I build with --target=powerpc64-linux-gnu when I'm on x86 for bootstrap binaries and else I leave it default.
<dftxbs3e>what's the difference with system?
<efraim>raghavgururajan: I haven't tried any. I started using Guix System with xfce and then got enlightenment working and haven't switched around since
<raghavgururajan>efraim Cool! Thanks.
<NieDzejkob>dftxbs3e: --target cross-compiles, --system does a native build, potentially through QEMU
<NieDzejkob>cross-compilation yields different store hashes than native builds
<dftxbs3e>hmm I see
<guix-vits>NieDzejkob: so --system may not work on CPU without virtualization support?
<dftxbs3e>guix-vits, virtualization never works if you specify a different system than current anyways (unless i386 on x86_64, or ppc on ppc64, for example)
<guix-vits>dftxbs3e: thanks.
<NieDzejkob>dftxbs3e: not true, you just need the qemu binfmt service
<dftxbs3e>NieDzejkob, I mean, it's not virtualization then
<dftxbs3e>It's binary translation
<efraim>dftxbs3e: you got the execve("/gnu/store/eeeeeeeee... ) from strace?
<dftxbs3e>efraim, yes
<efraim>OK. I'll try straceing with my grep-boot0
<dftxbs3e>efraim, gawk spawns sh internally, grep-boot0 may not
<NieDzejkob>dftxbs3e: ah, right
<janneke>huh? i'm doing ./pre-inst-env guix build --target=powerpc64-linux-gnu bootstrap-binaries (or --target=powerpc64le-linux)
<janneke> and get /gnu/store/5bdaayvl6cs8nrdivskz4dbrsy2m009c-bootstrap-binaries-0
<janneke>which says: file /gnu/store/5bdaayvl6cs8nrdivskz4dbrsy2m009c-bootstrap-binaries-0/bin/tar
<janneke>/gnu/store/5bdaayvl6cs8nrdivskz4dbrsy2m009c-bootstrap-binaries-0/bin/tar: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.30, stripped
<dftxbs3e>janneke, hmm, I do 'bootstrap-tarballs'
<dftxbs3e>not: bootstrap-binaries
<dftxbs3e>and it works OK
<dftxbs3e>janneke, it turns out regex can't work when patching binaries directly
<dftxbs3e>looking at remove-store-references but it's getting quite complex
<dftxbs3e>basically I just need to replace first bytes of the match with sh\0
<bricewge>Sending a patch series feel clunky: first sending the cover-letter to guix-patches waiting for the acknowledgement and then sending the actual series to debbugs.
<bricewge>Is there a way to send the series in one go through debbugs, so that the tracker know this is a guix patch????????????????????????????????????????????
<janneke>bricewge: yes...sadly no
<bricewge>Sorry my keyboard has a mind of is own...
<janneke>debbugs is a terrible perl hack and debbugs.gnu an unmaintained fork
<efraim>dftxbs3e: might be gawk, not grep
<janneke>i think that rekado is looking into this
<dftxbs3e>janneke, do you know about sourcehut? this looks like a good fit for GNU Guix! It supports git email workflow and provides a minimalist javascript-less web ui for all of it. issues, patches, and CI
<janneke>it would be amazing to have a modern guile implementation of debbugs
<bricewge>Yes sourcehut seems nice.
<bricewge>janneke: He is looking into building a debbugs in guile or only alternatives to the current system?
<efraim>dftxbs3e: adding gawk-boot0 and grep-boot0 I got further on glibc-intermediate. Have to see if it builds and if it can work without grep-boot0
<janneke>rekado wrote
<dftxbs3e>janneke, seems like it doesnt work over HTTP, only HTTPS
<janneke>dftxbs3e: works for me
<janneke>ah, misread that -- yes, could be
<dftxbs3e> - return HTTP Error 500 over http but not over https
<dftxbs3e> and - some times 500 (internal server error), some times 504 (gateway timeout)
<bricewge>Ho he wrote the beautifull Guix frontend.
<bricewge>dftxbs3e: I have similar issues when searching for bug I get a 504 but a retry ~10s later return the correct page.
<efraim>i forgot how long it takes glibc to build, still building it here
<janneke>we are looking at ppc64le, right?
<dftxbs3e>janneke, I'm doing powerpc64 big endian because it doesnt inhibit a long double format change in glibc, but seeing how it pans out, I'll probably be able to do powerpc64le too then
*efraim is working on 32-bit ppc
<dftxbs3e>janneke, I'm hoping to also use GNU Guix as a way to massively build and test software on OpenPOWER, so both endians is nice
<NieDzejkob>sneek: later tell ngz: FYI, you forgot to --signoff on the nheko patchstack you pushed. I tried to find an option to signoff by default, but failed miserably, so, uh... be more careful next time ;)
<sneek>Will do.
<civodul>hey hey!
<dftxbs3e>hi ludo!
<civodul>howdy dftxbs3e
<dftxbs3e>civodul, binary monkey-patching gawk .....
<dftxbs3e>that ends up being the only accessible solution
<NieDzejkob>civodul: I just realized, for the space monitoring on ci, you could have some other machine ssh and check. "pull" monitoring, if you will.
<NieDzejkob>funny, this bug was masking as a network failure:
<civodul>NieDzejkob: pull monitoring... sounds hacky :-)
<civodul>but yeah
<civodul>NieDzejkob: re swh, good catch!
<civodul>the patch LGTM
<civodul>you can remove "guix:" from the subject line
<civodul>there's a bug on core-updates with a reference to the "debug" output of mingw, which doesn't exist:
<NieDzejkob>civodul: thanks for the review, pushing...
<civodul>does that ring a bell? janneke maybe? ↑
<janneke>civodul: hmm, mingw cannot build shared and static simultaneously
<janneke>i have seen this before...
<dftxbs3e>how would I get the store path for a package in Scheme?
<janneke>civodul: hmm, i cannot read the error; is mingw-w64-i686 failing to build; or is someone trying to reference its (nonexisting) #:static output?
<janneke>mingw-w64 has no outputs field
*janneke brb
<NieDzejkob>dftxbs3e: I'd look at how guix/scripts/build.scm does it
<dftxbs3e>NieDzejkob, thanks
<NieDzejkob>Are CRLF line endings in the repository dangerous/a bad idea?
<efraim>glibc-intermediate built with gawk-boot0 and grep-boot0 added. now to try it out with just gawk-boot0
<dftxbs3e>efraim, hmm
<efraim>made it past the initial "can't find nptl", now to wait the rest of the 70 minutes it takes to compile
<dftxbs3e>efraim, ah ok. so did you rebuild gawk during bootstrap?
<efraim>dftxbs3e: there's a gawk-boot0 on core-updates, %intel machines need it for the bootstrap from mes, I added it as a native-input to glibc-intermediate and it picked it over the gawk from bootstrap-binaries
<dftxbs3e>efraim, ah ok.. handy
<civodul>janneke: yes, something is referring to the "static" output of mingw
<raghavgururajan>civodul Thanks for the push regarding gnome.
<efraim>I almost have a good solution for vim addons in guix, just need to figure out how to work with GUIX_ENVIRONMENT
<NieDzejkob>that's good to hear efraim, I'd love to manage my vim plugins with guix
<efraim>NieDzejkob: the first part is:
<efraim>" let plugins be managed by guix
<efraim>if isdirectory($HOME . "/.guix-profile/share/vim/vimfiles")
<efraim> set rtp+=~/.guix-profile/share/vim/vimfiles
<efraim>hardcodes ~/.guix-profile, but it works for me™
<NieDzejkob>huh, I thought there was some environment variable that did this...
<NieDzejkob>hmm, looks like I misremembered >_<
<janneke>civodul: so....should we add one, or find the client and convince them not to do that?
<dftxbs3e>is it merge-able to use `dd` to do binary patching?
<dftxbs3e>easiest way I found
<dftxbs3e>echo stuff | dd of=target bs=1 seek=offset
<dftxbs3e>and to get offset: grep -obUa '/gnu/store/[a-z0-9]\{32\}-bash' gawk | tr ':' ' ' | gawk '{print $1}'
<frafra>I am interested in using guix to use it in software development and in production with Docker; I created a manifest which requires Python 3.7, but there are some dependencies and commands I would like to run afterwards to prepare the environment... should I create an adhoc package for that? how to proceed? here is what I run for a small tool I am developing: $ guix environment --container --network --pure --ad-hoc --manifest=manifest.scm bash -- bash -c
<frafra>'pip3 install --user poetry && export PATH=$PATH:$HOME/.local/bin && poetry install && poetry run csv2tabulate --help'
<efraim>somewhat related, we have poetry 0.12.17
<janneke>frafra: i don't get the docker relation, but when using guix to create an environment i provide anything i need by installing guix packages
<dftxbs3e>janneke, creating images for docker to run?
<janneke>could be...
<efraim>I'd love to use mcron instead of "mbsync -a && sleep 300" or the like
<dftxbs3e> - heh
<g_bor[m]>Hello guix!
<janneke>frafra: does this help, can you use poetry from guix?
<g_bor[m]>I have found that our current setuid-programs installs the binaries not only setuid but also setgid.
<g_bor[m]>Is this intentional?
<g_bor[m]>I did not find a mention about this in the docs.
<g_bor[m]>This seems to be very low risk currently.
<dftxbs3e>ugh - execve("sh", ["sh", "-c", "test -d nptl"], 0x3fffd5d7ffd0 /* 41 vars */) = -1 ENOENT (No such file or directory)
<dftxbs3e>sh isnt in path
<dftxbs3e>PATH *
<dftxbs3e>no, it's in PATH, but execve wont find it
<janneke>dftxbs3e: yes...
<str1ngs>right execve that's the fullpath for the first argument
<dftxbs3e>str1ngs, how to tell it to seek for it in PATH entirely? can the first arg be NULL?
<str1ngs>argv[0] also includes the program
<str1ngs>that that is generally relative
<frafra>efraim, I have seen it, thanks :-)
<dftxbs3e>janneke, so I need to use execvp instead..
<civodul>janneke: re the "debug" output, i'm not sure; i don't think anything change in that area so i'm a bit confused
<frafra>janneke, it is nice to have an dev environment that matches the one you use for production (Docker in my case), but instead of using Docker + bind mount on my machine to develop, using guix seems way nicer, and then I can generate Docker images with guix pack
<str1ngs>dftxbs3e: execvp should work but in the case of /bin/sh it's probably not okay to use that
<dftxbs3e>str1ngs, what would be okay then?
<dftxbs3e>why is it not okay to use it in the case of /bin/sh?
<str1ngs>use the full path. It's okay to expect /bin/sh to exist
<dftxbs3e>str1ngs, it doesnt exist during bootstrap, does it?
<str1ngs>that's about the only thing you can assume to exsit
<str1ngs>even when bootstrapping you need /bin/sh so in most cases that's a static binary or created extremely early
<str1ngs>if you are using this with guix you can even go so far as to make a shell script instead and substitute the shabang
<janneke>civodul: "debug" output, you mean "static"? -- /me is getting confused
<dftxbs3e>str1ngs, if I use /bin/sh I think it will use my host system's /bin/sh
<dftxbs3e>so that's not right
<dftxbs3e>I'll figure it out, thanks
<civodul>janneke: yes, i meant "static", sorry; so the problem happens when doing: guix build --target="i686-w64-mingw32" bootstrap-tarballs
*civodul tries adding a "static" output to mingw
<str1ngs>dftxbs3e: the use PATH for sh is not right either. in the context guix just create a shell script and substitute the shebang
<dftxbs3e>str1ngs, PATH has /gnu/store/nnd6nvq9m327bvb34pqjhvy0khpk559y-bootstrap-binaries-0/bin which contains sh - so I should create a shell script called 'sh' in the current directory and have it point to /gnu/store/nnd6nvq9m327bvb34pqjhvy0khpk559y-bootstrap-binaries-0/bin/sh
<str1ngs>dftxbs3e: right if the file is part of a guix package this should get substituted automatically IIRC. though probably you using the boostrap sh is overkill
<dftxbs3e>str1ngs, I used: (symlink (string-append (assoc-ref %build-inputs "bash") "/bin/bash") "sh")
<dftxbs3e>and it works
<efraim>i made it past glibc-intermediate to fail at glibc-final
<dftxbs3e>efraim, good progress! I finally also made it past glibc-intermediate - it built in less than 2 mins for me
<str1ngs>dftxbs3e: glad it's working
<alextee[m]>i have a GUI toolkit that uses cairo, and then a program that uses that toolkit that also uses cairo
<alextee[m]>should i make cairo a propagated input on the GUI toolkit?
<alextee[m]>its users are expected to use cairo
<NieDzejkob>alextee[m]: name names :P
<alextee[m]>it's my own stuff lol, ztoolkit and ZLFO
<alextee[m]>i think the correct thing would be to have propagated inputs on ztoolkit for cairo, librsvg and libx11
<alextee[m]>and then including ztoolkit as a native input to zlfo
<alextee[m]>ztoolkit a static-only library
<alextee[m]>but then cairo would be a native input? maybe that's wrong
<alextee[m]>maybe something like this makes the most sense
<NieDzejkob>but then the dependencies will also get propagated to the user's profile, no?
<alextee[m]>oh right
<alextee[m]>just inputs for ztoolkit then i guess
<alextee[m]>idk why i got confused, thanks :-)
<dftxbs3e>Got this now.. output (`/gnu/store/gj7dma1dlyakz7g5mpdikkrljn7ikr4h-binutils-2.32') is not allowed to refer to path `/gnu/store/nnd6nvq9m327bvb34pqjhvy0khpk559y-bootstrap-binaries-0'
<janneke>dftxbs3e: nice
*janneke peeks at wip-guile3.0-packages and quickly looks away -- scary stuff
<janneke>oh, i guess i can try a build
<janneke>dftxbs3e: that was for your earlier success...just reading your last problem now
<dftxbs3e>janneke, I think that's about binutils-final, but not sure..
<dftxbs3e>how would I patch shebangs in binaries?
<nckx>Good morning Guix.
<janneke>dftxbs3e: you could use the fold-port-matches trick from remove-store-references (guix build utils), i think
<janneke>nckx: good morning!
<nckx>efraim: Have you built vim@8.2.0303 on x86_64?
<efraim>yeah, and vim-full. I used bayfront
<dftxbs3e>hi nckx!
<efraim>fail for you?
<nckx>And not a one-off, I tried updating vim myself and got the same error. 🙂
<nckx>‘Flaky’ indeed.
<efraim>chattr +C /tmp ?
<nckx>Hm, it's btrfs so perhaps. I'll check.
<nckx>But how the hell do you get that hunch from that output?
<efraim>mismatches are sometimes race conditions, it seems switching the ref on CoW is slower than just changing the file
<efraim>and I have to remember to do that on my machine when I boot up
<nckx>efraim: What the… 😃 It worked!
*efraim has the magics today
<nckx>So I 'sume this isn't reliably fixable by disabling parallel tests?
<nckx>Oh they are already disabled never you mind me.
<nckx>OK, vim. You win. This time.
<efraim>oh good, I was going to say it might also help it pass but shouldn't be the real way to do it
<dftxbs3e>janneke, so I solved it. It's because my edits to glibc-intermediate propagated into glibc-final, so I needed to create a different `sh` symlink with a different bash for glibc-final, so I did that. Testing now!
<nckx>At least chattr is stateful. *cries*
<dftxbs3e>(I think I solved it *)
<janneke>dftxbs3e: good!
<dftxbs3e>janneke, you don't imagine what kind of relief that is to finally succeed... I've been literally depressed out of this.
<janneke>dftxbs3e: yes, i can't imagine ;-)
<NieDzejkob>nckx, efraim: maybe the guix daemon should chattr +C the /tmp/guix-build directory?
<NieDzejkob>Is there a better way to import additional modules?
<civodul>NieDzejkob: no, that's correct
<civodul>however note that (guix build gnu-build-system) and (guix build python-build-system) both export %standard-phases
<civodul>which is probably not what you want
<civodul>prolly you'd want to #:select (site-packages) from python-build-system
<NieDzejkob>oh, I thought I'd use (@ (guix build python-build-system) site-packages), but #:select is indeed a nicer solution
<sirgazil>GNOME is not releasing RAM for me. At the end of the day, I see RAM usage is about 3 GiB. Closing all applications reduces that number to about 2 GiB. But if I log out and then log back in, those 2 GiB are still in use. After reboot, GNOME alone uses around 1.5 GiB.
<sirgazil>Using sway, RAM usage seems a lot better.
<frafra>can I install a different version of a package?
<NieDzejkob>frafra: it depends, what package?
<nckx>NieDzejkob: Builds failing on btrfs (or whatever) is annoying but usually a valuable sign of flawed assumptions. While we could improve ‘immediate’ reproducibility by making everyone's build environment slightly more similar, that would negatively affect ‘long-term’ reproducibility by masking such errors. Hence why disorderfs is a thing.
<frafra>NieDzejkob, I was looking for Python and playing with Guix, to understand more if/how to use it at work
<nckx>And more subjectively: the daemon simply shouldn't (need to) concern itself with packages' arbitrary bugs or demands. Nah.
<nckx>Luckily it's irrelevant here: a simple (invoke "chattr" "-R" "+C" ".") solves the problem for vim.
<NieDzejkob>frafra: Some packages are packaged at multiple versions, in such a case `guix show pkgname` will show all of them and you can refer to them with `pkgname@1.3`
<NieDzejkob>frafra: If you need an older package as a one-off, see guix time-machine, for example guix time-machine --commit=deadbeefgitcommithash1234 environment --ad-hoc foobar@7.3
<civodul>sirgazil: in top, if you sort by memory usage (type "<" to select a column), can you tell which process is eating memory?
<frafra>NieDzejkob, thank you very much :)
<NieDzejkob>frafra: If you need to specify an older package in a manifest, you'd use inferiors, see info '(guix)Inferiors' for a nice example
<mwette>I'm on a foreign distro. When, as user, I issue `guix package -u' I get "The following package will be upgraded:" ... "/gnu/store/7z...-guile-next-3.0.0". BUt I get that message always. I'm guessing that a process owned by guixbuilderN should be running but I don't see it. I believe there is a problem here. How can I trace it down?
<leoprikler>Do you have guile-next installed in your user-profile?
<nckx>NieDzejkob: Thanks for sifting through old bugs.
***calher is now known as KE0VVT
<dftxbs3e>I think it's going to work this time...
<NieDzejkob>civodul: I've sent a PATCH v2, would you mind taking a look?
<civodul>NieDzejkob: sure, i've just replied by mail!
<GNUtoo>hi, is it possible to run Guix in an lxc container?
<mwette>leoprikler: yes, as reported by `guix package -I'
<sirgazil>civodul: I did that before, but using GNOME system monitor, and no process seemed to be using an excessive amount of memory and the sum of the memory used by the running processes didn't seem to amount to 3 GiB. But I'll try again with top.
<dftxbs3e>GNUtoo, sure! you can use `guix system disk-image ...` to generate an image and then you can just use that with lxc!
<dftxbs3e>nevermind, docker-image rather
<GNUtoo>dftxbs3e: oh ok, I'll try that, thanks
<dftxbs3e>documented here:
<dftxbs3e>guix system takes a system configuration, akin to /etc/config.scm!
<GNUtoo>The thing is that there need to be a way to have the right shehperd + parameters
<GNUtoo>once there is that, it's easy to spawn something like lxc
<janneke>dftxbs3e: oh, has that been fixed?
<dftxbs3e>janneke, what has been fixed?
<janneke>running guix in lxc, epronk wanted to do that
<GNUtoo>I've a use case where I've some difficulties finding the right combinaison of things, if it works in lxc it would work for me, right now I'm trying to generate a docker-image
<GNUtoo>there is also another option called init in guix system, which looks interesting
<dftxbs3e>GNUtoo, I'd suggest looking at code for `guix system container ...` to figure that out. This command can spawn a container directly
<dftxbs3e>janneke, I don't know about history around the command :-S
<janneke>dftxbs3e: could be it "just works" now
<GNUtoo>What I need is just a way to tell libvirt which command to run (like /gnu/store/*/bin/shepherd) and which options to pass it
<janneke>GNUtoo: like what's in grub.cfg's --boot= script?
<dftxbs3e>It's building Guile now, I think it's done! Hooray!
<dftxbs3e>Guile, as in, the real GNU Guix guile package, not any bootstrap one
<janneke>dftxbs3e: \o/
<dftxbs3e>I don't know if any of my changes are merge-able, I'd appreciate feedback on that
<janneke>dftxbs3e: have you rebased on core-updates yet?
<dftxbs3e>janneke, I've been working with master
<janneke>i had only one or two small conflicts doing that...
<dftxbs3e>rebasing my branch onto core-updates?
<dftxbs3e>oh great. though I'm not sure it would work anymore then
<dftxbs3e>I'd prefer bootstrapping on master then iterating onto next GNU Guix versions
<janneke>dftxbs3e: what are the commands you have been using? possibly this warrants a mail to guix-devel!
*janneke needs to go afk for a bit
<dftxbs3e>janneke, `./pre-inst-env guix build hello -K` to test natively on powerpc64-linux-gnu - `./pre-inst-env guix build --target=powerpc64-linux-gnu bootstrap-tarballs -K` on x86_64-linux-gnu to cross compile bootstrap binaries
<dftxbs3e>When GNU Hello works, I'll send an email, until then, it could still fail :P
<GNUtoo>so it has created a 6zm4f5k898xkhk5hi2vrlh5f7z0wppa8-guix-docker-image.tar.gz
<GNUtoo>that contains some infos on how to run it in config.json
<GNUtoo>and the rootfs can be extracted
<GNUtoo>so for now I'll probably be able to run that
<GNUtoo>Then the next step would be to understand how, from within the lxc, to update it
<GNUtoo>dftxbs3e: I manage to boot it to a shell but now I can't use guix system reconfigure because it complains about the missing block device, so I ended up having that instead:
<GNUtoo>(file-systems %base-file-systems)
<GNUtoo>but that fails
<GNUtoo>In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #f
<dftxbs3e>GNUtoo, hmm, what missing block device?
<GNUtoo>it didn't find the uuid of that:
<GNUtoo>(cons* (file-system (mount-point "/") (device (uuid "b1ecb69d-4bb6-4bcf-9ab6-6a4d40c227f8" 'ext4)) (type "ext4")) %base-file-systems))
<GNUtoo>so I replaced all that with (file-systems %base-file-systems)
<dftxbs3e>I think you can specify device by path instead of uuid
<GNUtoo>I've no block device as it runs inside an lxc with a filesystem mapping instead
<civodul>GNUtoo: %base-file-systems is good enough if you're making a Docker image
<civodul>there's no root file system actually being mounted anyway :-)
<GNUtoo>exactly, though I was told to try docker stuff to run in an lxc container
<GNUtoo>At the end of the day I guess that I'll end up having to do many many workarounds, but I could try guix init ./thefile.scm ./rootfs too, maybe that has less hops to get it working
<civodul>i guess it depends on the use case
<civodul>sometimes a plain VM image is just more convenient
<dftxbs3e>GNU Hello built on powerpc64-linux-gnu!!!
***ChanServ sets mode: +o nckx
<drakonis>a random idea for build systems, spin up builds for other distributions
<drakonis>set up a debian mirror built entirely using an guix infrastructure
<drakonis>now, another question i'd like to ask, i cannot build something using multiple build systems, right?
<efraim>you can, it just takes more finagling
<efraim>most of the examples IIRC are pulling emacs-build-system into others
<nckx>drakonis: Yep, you can mix-&-match phases from multiple build systems whichever way you like.
<nckx>Or even call them directly.
<drakonis>very nice, is it documented or just in code?
*nckx dunno…
<drakonis>i have a package that would benefit from that
<drakonis>needs both python and C
<nckx>That's actually quite common, I'll see if I can find an example.
<drakonis>wants node, python and C
<nckx>That was mean.
<drakonis>freespace 2, y'all
*nckx goes back to looking for C+Python as if nothing spooky happened.
<drakonis>and that's not including the build steps for the source port, but that's just C
<drakonis>while i still have your attention, check up on why the package sources path points to the store path in disk
<drakonis>instead of the git path
<drakonis>on the website that is
<NieDzejkob>nckx: what "spooky thing" happened? I don't see anything in my log
<drakonis>ie: "/store/m92vxb2klbx1x5g6m0j766fm6rg7slsb-guix-module-union/share/guile/site/3.0/gnu/packages/"
<drakonis>NieDzejkob: i found a package that needs node, python and C to build
<nckx>drakonis: I'm not finding anything perfect (not sure what to grep for TBH) but gramps mixes python- and glib-or-gtk-build-system in an idiomatic way.
<drakonis>so i'd have to use multiple build systems for it
<drakonis>a big spooky thing.
<nckx>NieDzejkob: Nothing, I'm just easily spooked by Node is all. Had to resurrect a Ubuntu 18.04 machine from the dead to build a node package for my Guix server this week. That shit's traumatic. Apologies.
<drakonis>node build system some day?
<drakonis>or maybe a extra channel for handling node builds because the dependency graph is giant
<nckx>drakonis: I guess ‘grep 'build-system.*#:prefix' gnu/packages/*scm’ is a good start to find interesting examples.
<narispo>Bridging the npm eco system onto GNU Guix would solve one of a nightmare that npm is
<nckx>But nobody knows how to do that because of what a nightmare that npm is.
<narispo>I'd be much happier installing GNU Guix packages rather than NPM ones that do all kinds of bullshit in the background
<narispo>Impure operations in the background :-)
<nckx>drakonis: I have no idea if this is good code (I don't actually grok npm) but it gives you two names, of which jlicht is still regularly around in #guix.
<nckx>Better non-random microhub link:
<NieDzejkob>nckx: oh, okay. Do you always get an @ next to your name when you get spooked? ;)
<nckx>NieDzejkob: Only when the Wallops threaten to murder ChanServ
<nckx>as they have just done.
<NieDzejkob>ah, right. Would something bad happen if there were no ops in a channel?
<NieDzejkob>or is it just that we might need to swing out the banhammer?
<nckx>NieDzejkob: Nothing bad. Super-mild inconveniences like ‘we can't change the topic if the update goes wrong’.
<nckx>Mainly just in case.
<nckx>We've been very fortunate lately.
*nckx tiptoes around the thing with the stuff.
<mehlon>ah, npm...
<drakonis>hmm, an actual good/bad idea is to allow package importing when doing builds
<drakonis>as a replacement for other package managers
<drakonis>off goes build purity though
<drakonis>i'm in no position to talk about code quality myself
<mehlon>hm? I'm not sure what you mean
<nckx>‘Importing’… from the network? Yeah, that is not going into Guix until a very ill-timed bus comes along, I think.
<joshuaBPMan>Hey guix.
<drakonis>hmm, yes, like that, its probably a bad idea.
<mehlon>it could work if it's from ipfs, maybe..?
<drakonis>though the other path would be to parse the lockfiles most of the languages that have sprawling dependency webs normally use
<nckx>mehlon: At that point it's content-addressed (good) but can just be a regular fixed-output derivation, i.e. input. No need for build-side hacks.
<mehlon>there was that GX thing
<mehlon>the only thing it's missing is the letters U and I
<drakonis>this seems to be what the node build system patch is doing
<drakonis>parse lockfiles to get the dependencies to then initiate the build
*** sets mode: +o ChanServ
<drakonis>chanserve lives...
<mehlon>chanoppa gangnam style
***ChanServ sets mode: -o nckx
<drakonis>hm, that would work out.
<drakonis>looks like just the thing.
<mehlon>is nodejs even in guix?
<drakonis>it is.
<nckx>nodejs is ‘node’, right?
<drakonis>it includes npm.
<mehlon>ah, I heard that "nodejs is not bootstrappable" from the secushare site
<mehlon>so I wasn't sure what to think
<drakonis>i suppose that a build system has to replicate the way the builds function
<drakonis>hmm, still can't wait for user services to come up.
<drakonis>as a fully integrated on tree thing.
<rndd>drakonis: sorry, i'm newbe, what is "user services"? i thought user can write service for shepherd -_-
<joshuaBPMan>Hey guix, I'm having a hard time getting my guix machine to use a custom service from my custom channel.
<drakonis>rndd: its a different thing actually
<drakonis>there's system services, which are set up on the system configuration and then there'd be user services
<joshuaBPMan>actually I think I know how to fix it.
<drakonis>which are per user services
<drakonis>all the same goodness, but for your user profile.
<rndd>drakonis: ooh, that's cool. i dont remember systemd have such option
<nckx>systemd fully supports exactly that.
<nckx> 🙂
*** sets mode: +o ChanServ
<drakonis>none of that configuration goodness though
<drakonis>cool new things, except everyone gets it.
<nckx>I have yet to drink that particular Kool-Aid but it looks tasty.
<drakonis>julien wrote home-manager for guix
<drakonis>but it needs a little bit more meat in its bones
<drakonis>its similar to what nix has.
<nckx>I didn't know Nix was ahead of us in this (assuming it's not a side-project like home-manager).
<drakonis>it is a side-project, yes.
<drakonis>its unfortunately just home-manager.
<drakonis>its not ahead.
<roptat>Nix version is different from mine though, I'm doing the hard-core version :)
<roptat>They only override files in the home when reconfiguring, but with guix home manager, your home is read-only
<roptat>Which brings a lot oh croubles, but is more true to guix's way of doing things
<roptat>of troubles
<nckx>M-hm. And avoids other much harder-to-debug troubles, I'd expect.
<roptat>I did it, I use it, but I wouldn't really recommend it ^^'
<nckx>Just a bit too hard-core for me 🙂
<drakonis>its like bringing a gun to a knife fight
<roptat>At least you have the nice properties of the transactional and functional package management of guix, so you can roll-back your home instantly for instance
<roptat>Your home is just another profile, but it breaks assumptions of some software
<roptat>I can't open libreoffice for instance, I have to trick it by setting HOME to a temporary directory
<roptat>Same with pulseaudio, which is really not fun when it crashes (and it crashes often, you just don't notice because clients will restart it… except they can't with the home manager)
<drakonis>well, soon it'll be time to ditch pulseaudio for the next thing.
<drakonis>wonder if it will fail if home is read only.
<drakonis>pipewire finally reached 0.3, still waiting for fedora to set it as the default
<OriansJ>has anyone created a package for yet?
<lapinot>hey folks, i guess the heart of the guix project is some consistent view of what a userland chould be, probably more so than other distribution which are more institutional, right? So in that realm of thoughts, what would be your take on the shell? posix shell was probably the priviledged way to interact with a system because we did shell scripts and traditional init scripts, but in guix these both
<lapinot>seem to be more direct in guile
<OriansJ>lapinot: we has gash
<drakonis>guile all the way down
<OriansJ>and gash-utils
<lapinot>oh right!
<drakonis>we just havent gotten to using it for composing packages yet
<OriansJ>in guix, if you have guile; you can bootstrap the world
<OriansJ>drakonis: speak for yourself *cough bootstrapping cough cough*
<lapinot>i think i saw that but i struggled to find any text material on it
<OriansJ>lapinot: well it is very minimal right now
<drakonis>bootstrapping isnt the same as writing packages using gash utils to replace build utils
<OriansJ>drakonis: *very slow blink*
<drakonis>honestly, i'm not sure if i'm explaining myself correctly
<drakonis>there's the "build utils" library that's being used inside build phases
<drakonis>then there's directly invoking the functions reimplemented for gash-utils to recreate coreutils in guile
<lapinot>interesting... i mean i dream of the day where these main(**args) are gone and instead we would have a more structured way of publishing entrypoints to programs, a structure which would (just like as it is now) be a kind of FFI to the priviledged shell language
<drakonis>there's already a function for invoking shell
<lapinot>you mean in libc?
<joshuaBPMan>so I've got a VERY hacky openvpn client that works for me now. Kind of cool.
<drakonis>oh, libc? no i mean on guile
<drakonis>i read your message wrong
<civodul>lapinot: the REPL is a shell that gives access to more an more functionality in Guix, if that's what you had in mind
<dftxbs3e>civodul, is the plan with Gash to allow to create packages with shell script..?
<lapinot>dftxbs3e: afaik it's more like library in guile which allows you to do stuff in a guile repl that you would do in a posix shell (correct me if i'm wrong)
<lapinot>guile repl or guile script obviously
<roptat>guix repl even :)
<lapinot>roptat: oh so guix does have a repl? (yeah sorry, i didn't take the red pill yet, i'm procrastinating the harddrive/partition cleanup)
<roptat>It's mostly the same as guile repl, but it gives you easy access to guix modules
<dftxbs3e>hmm, somehow openssl fails to compile on powerpc64-linux-gnu - /gnu/store/gh8pjfc9pgmdmjxr7k40jmnnzah1yp6q-glibc-2.29/include/gnu/stubs.h:8:11: fatal error: gnu/stubs-32.h: No such file or directory
<lapinot>roptat: cool
<lapinot>maybe guix is the new lisp-machine
<drakonis>that'd be a fun end goal
<drakonis>our nix pals are about to write a lisp interpreter to have an installer
<lapinot>i'm practically convinced OSes will evolve in that kind of direction (which is mostly programming/controlling the userland in a different language), it could also help microkernels and stuff like qubes, by decoupling stuff (or at least making the couplings more standardized)
<drakonis>linux is undergoing a decoupling
<lapinot>yeah, with the namespace thing and all you mean?
<drakonis>no, microkernels.
<drakonis>its changing into one
<alextee[m]>what about hurd :D
<drakonis>hurd needs developers
<lapinot>drakonis: how so? (i mean i'm curious, i don't know a lot about linux kernel dev) since microkernel is not really so well defined i'm not sure what to search for
<alextee[m]>i wonder why there's so few devs. it looks more organized than linux
<drakonis>applications of the ebpf vm
<lapinot>hmm, so maybe there would be a step where most kernel modules are actually binaries with "ebpf" interface (or at that point more probably a basic in-kernel shell)?
<lapinot>(by modules i probably mean subsystems)
<lapinot>at which point kernel-shell and userland shell could unite and we get a microkernel \o/
<drakonis>lapinot: yes
<drakonis>that's the ongoing plan it seems
<dftxbs3e>openssl didnt define KERNEL_BITS during configuration, which means it was less likely to work on less common architecture with less developed platform detection