IRC channel logs


back to list of logs

<nckx>vagrantc: RAID0 root makes good sense if one runs a Guix build farm on 2 spinning drives, for example. Uncommon but valid.
<oriansj>sameerynho: and you performed steps like these right?
<sameerynho>oriansj: yeah i remember some of it
<oriansj>sameerynho: and what exactly are the steps that you took to hit a segfault; so that we can help you troubleshoot with you
<oriansj>remember precise details are what are needed for me to create an identical environment and the exact same issue; this is because guix is deterministic
<sameerynho>oriansj: well install guile and just tried to build guix's master branch from source
<oriansj>sameerynho: more precise steps, what are the exact commands being issued
<moesasji>oriansj: did you do that following 14.1 in the manual?
<sameerynho>oriansj: guix environment guix --pure --ad-hoc help2man git strace guile bash
<sameerynho> ./configure --localstatedir=/var
<sameerynho>and make
<moesasji>missing ./bootstrap ??
<sameerynho>bootstrap ?
<moesasji>the manual has a ./bootstrap command before the configure step.
<sameerynho>moesasji: ah i did that before that's how i got the configure
<sameerynho>also when i try to do `guix pull`
<sameerynho>i get this error which is a segfault again
<moesasji>sameerynho: only difference from what I do is that I don't have the --pure in the command.
<moesasji>I use: guix environment guix --ad-hoc help2man git strace
<sameerynho>moesasji: cool i'll give it a try
<drakonis>hmm, so, i have found that there is a problem
<drakonis>the timezone reported by the system to all the applications is set to london
<drakonis>as it turns out, it is correctly selected on my configuration.
<NieDzejkob>what applications are you testing?
<drakonis>gnome and git
<drakonis>git has set the clock to utc +1
<NieDzejkob>what timezone have you specified in your configuration?
<drakonis>see PM
<drakonis>date has the right utc
<drakonis>firefox is timezone unaware
<NieDzejkob>str1ngs: how does your hack deal with the path?
<NieDzejkob>drakonis: by firefox, do you mean IceCat?
<drakonis>oh i can see the problem here with git
<drakonis>it uses the timezone of the committer for the logs
<drakonis>as for firefox/icecat it cant pick up the timezone in the expected place
<drakonis>gnome has the timezone set to -3 but shows london for some reason but i suppose i shouldnt care too much
<NieDzejkob>I feel like the issue with icecat is that this is some way of avoiding coarse geolocation
<drakonis>hm, i see.
<NieDzejkob>flipping about:config -> privacy.resistFingerprinting to false makes websites read the right timezone for me
<drakonis>okay, cool.
<NieDzejkob>hmm, now it doesn't? O_o
<NieDzejkob>ah, I was testing with `new Date()', now I'm testing with `Date()'
<NieDzejkob>apparently that makes a difference
<drakonis>that's how i tested with icecat
<drakonis>huh okay that's how, alright.
***stallman is now known as akko
<str1ngs>NieDzejkob I uses a special service file to handle the dynamic linker
<str1ngs>NieDzejkob you only need lib64 for this
<str1ngs>NieDzejkob my hack takes a bit to load but it's nice since it uses a profile and keeps thing within guix where possible
<valignatev>Hey Guix! How do I unbuild a package? I build something with ./pre-inst-env guix build and now every time I build again it reuses derivation, or graft, or whatever. How do I force it to build again?
<oriansj>valignatev: --no-grafts
<valignatev>No luck, it just prints out a path to the store with the previously built package and exits
<valignatev>Should've said that I've tried it
<str1ngs>try with --no-grafts --check
<str1ngs>if that does not work. --no-substitutes --no-grafts --check most defiantly will work
<valignatev>--no-substitutes will build the whole world though, don't want that :)
<valignatev>--no-grafts --check seems to be working, thanks!
<roptat>there's no really a point to "unbuild" something though
<roptat>and what check does is to rebuild the thing, check it's bit-identical to what you already have and forget about it
<roptat>or report if it's not identical
***jonsger1 is now known as jonsger
<valignatev>I've changed something in the dependencies of a package I'm building, so I wanted to check if it still builds
<jackhill>valignatev: changing the imputs should have changed the derivation though, so if it's producing the same store item, something's not right.
<jackhill>I wonder if it could be as simple as not saving the file?
<brettgilio_>I added a version of MLton to my guix channel that tracks master, as well as the parallel extension to MLton called MaPLe.
<brettgilio_>MLton still isn't able to be upstreamed to guix master, yet. So you will have to use my channel.
<valignatev>jackhill: I didn't really changed the inputs. I rearranged couple dependencies and was checking if I didn't break anything accidentally
<valignatev>So in fact, nothing should've changed
<jackhill>valignatev: well I guess guix didn't think anything changed :) I asume it was bit-identical?
<jackhill>brettgilio_: cool! Is it not upstreamable because it depends on a blob for bootstrapping?
<valignatev>If you mean bit-identical in the source code sense then no. But the supposed output should be bit identical, right
<brettgilio_>jackhill: right. A few blobs rather
<jackhill>valignatev: yeah, I thinking about the output. However, now I'm curious what dependencies changed that weren't inputs.
<valignatev>Transitive inputs, so dependencies of a dependencies
<valignatev>They haven't really changed. I just inherited some of them from their newer versions and was checking that it all still works
<jackhill>cool, glad it's still working, that's always a good feeling
<str1ngs>jackhill: #nomad-browser has officially promoted you to be our main QT tester!
<jackhill>str1ngs: :) I guess I should pop over there and start testing then
<brettgilio_>Goodnight Guix!
<apteryx>do gnome savvy people think that updating glib on core-updates to the latest version would be OK?
<apteryx>brettgilio_: good night!
<jackhill>brettgilio_: I see you have a newer racket in your channel too. Is there a problem with having that in guix?
<drakonis>so, there's definitely something wrong with playing back mp4 audio on icecat, it sounds very distorted
<drakonis>it looks like the icecat patch messed up with fonts
<drakonis>fonts are super broken
<bandali>i *think* the mp4 issue is already known/reported, potentially related to codecs etc
<bandali>as for fonts, maybe try installing a font from guix if you haven’t already, and refresh the font cache using fc-cache -fv
<bandali>ah, looks like mark recently pushed “gnu: icecat: Fix support for ffmpeg codecs.”:
<drakonis>no i mean that the audio sounds very distorted
<drakonis>the mpv video channel is fine but oh man the audio channel just sounds awful and slow
<roptat>oh I just got that actually
<roptat>I think it's dropping like half of audio points, it's very low and clicky
<roptat>but I first want to make sure it's not just the video
<bandali>is that in spite of mark’s newest commit?
<drakonis>its not with all kinds of audio though, just mp4
<roptat>it just happened once for me, but I didn't get Mark's latest commit (I'm whitelisting /gnu/store/ entirely)
<drakonis>mark's commit brings font breakage, possibly because it only exposes ffmpeg to it
<bandali>i guess it’d be a good idea to reply to him on then
<roptat>anyway, you might want to try: (sorry, this was a link I clicked on, but I don't really get what that means, probably some american politics ^^')
<roptat>the video plays nicely after downloading it with youtube-dl, but not in the browser
<bandali>plays fine for me with js tho
<roptat>the video part is fine, but the audio is terrible
<drakonis>this one serves as a example
<roptat>yep, I have the same weird audio on that one too
<roptat>(you can replace the part with, which is slightly less loaded with javascript that tries to get your attention :), the video source remains the same)
<drakonis>i see
<roptat>bandali, so with a more recent icecat, it workes better? I think I'm already on a recent commit, but maybe something changed
<roptat>I'll pull and reconfigure
<roptat>well, actually I'll do that tomorrow, I need to sleep now
<roptat>see you later!
<bandali>roptat, i’m not sure, i haven’t pulled recent icecat just ywt
<roptat>then don't, you'll be disappointed :p
<drakonis>mind you its still broken even without pulling recent icecat
<raghav-gururajan>sneek later tell roptat: I just saw your email with regards to closing the bug related to video rendering icecat. But it's still doesn't work. :/
<sneek>Welcome back raghav-gururajan!, you have 1 message!
<sneek>raghav-gururajan, raghav-gururajan says: test
<sneek>Got it.
<raghav-gururajan>sneek Have double-shot of botsnack botsnack.
<raghav-gururajan>No two :) ? Okay.
<raingloom>how do folks on guix currently manage snapshots? i wanna set up something like snapper so that i don't accidentally delete my $HOME or something
<raingloom>(i should also have off-site backups, i know)
<nixo_>Hello guix! is there some resource out there on how to find out determinism problems? Like, when I run guix build --check PACKAGE, if I get an error, how can I run diffoscope on it?
<jonsger1>for those who wanna try a current install image from master
<peanutbutterandc>Hello there
<sneek>Welcome back peanutbutterandc!, you have 2 messages!
<sneek>peanutbutterandc, str1ngs says: I have mailed in a patch fixing the sound issue with tuxguitar. the keyboard issue is not quite resolved seems the default key accelerators not set. you can set them though using menu->tools->shortcuts. here is the patch for reference.
<sneek>peanutbutterandc, str1ngs says: you will still need to use timidity to produce sound.
<peanutbutterandc>str1ngs, Wow. That is super neat. Do you also happen to have a channel somewhere that I can add and see how tuxguitar works with your patch? Thank you for your hard work.
<peanutbutterandc>Now I don't have to resolve to using flatpaks
<str1ngs>peanutbutterandc: github or gitlabs? I mirror on both
<str1ngs>or if want substitutes I can do that as well
<peanutbutterandc>str1ngs, I do have a GitHub account so if you want issues reported there, GitHub please. Whoa. Substitutes too? How?
<str1ngs>peanutbutterandc: publish server
<peanutbutterandc>str1ngs, I might not have reached that section in the reference manual yet, sorry. But I do understand that soon there will be p2p substitute sharing with gnu net and then guix will be truly invincible :)
<peanutbutterandc>str1ngs, Your channel URL, please?
<str1ngs>peanutbutterandc: though use the tuxguitar branch. master branch tracks upstream
<str1ngs>let me know if you need to to rebase on master
<str1ngs>need me*
<str1ngs>peanutbutterandc: I think that gets tuxguitar cleaned up. still need to look at keybindings more. but at least I know what the problem is
<str1ngs>peanutbutterandc: I packaged pianobooster too. but that that has real midi issues
<str1ngs>peanutbutterandc: I think p2p might use ipfs. though gnunet would be nice as well. and more GNUish
<str1ngs>is GNUish a word?
<peanutbutterandc>str1ngs, Oh wow. That's an actual guix mirror. I was thinking something more simpler like this: but I can see why you're doing that. Um, I don't know what will happen if I add that branch as a channel: guix itself will get updates from upstream but all my packages will be updated from your branch or upstream depending on which one is newer, I presume?
<peanutbutterandc>str1ngs, Most certainly a whole lot more gnuish!
<str1ngs>thing with gnunet is it has all the pieces but they have to be put together
<peanutbutterandc>Also, Did you use the GitHub fork for the packaging or the Sourforge original one?
<str1ngs>I use sourceforge
<str1ngs>master branch tracks origin (fetch)
<peanutbutterandc>str1ngs, Perhaps guix adopting gnunet will be the exact thing that'll make them famous? It seems that guix is guile's primary champion. Perhaps likewise will happen with gnunet? But I don't yet understand which one is better among the two
<str1ngs>my branchs are just used until my patches are merged. then they get deleteed
<peanutbutterandc>Perhaps the GitHub fork would be a better idea, if I may suggest
<str1ngs>no, I track upstream guix :P
<str1ngs>you can though git am might be a better solution.
<peanutbutterandc>I am not yet that much of a git ninja, sadly. But regarding the thing about where my updates will come from: so if I add the tuxguitar branch and guix upstream gets a newer version of, say, emacs... which one will I get when I 'guix pull'?
<peanutbutterandc>(sorry if that is a stupid question)
<str1ngs>for channels like that I don't mix the two. you would get the channel version
<peanutbutterandc>Or perhaps because we (cons ...) the channels, whichever is the first should get more priority?
<str1ngs>first I believe get priority but don't quote me on that.
<str1ngs>I would personally just use ~/src/git.git and apply the diff patch for tuxguitar
<str1ngs>since.. that's my workflow to have it eventually included in guix
<str1ngs>then you can do ./pre-inst-env guix build tuxguitar
<peanutbutterandc>Perhaps the behaviour should be standardized and documented? That way in situations like the one we are in right now, it'd be a whole lot clearer? I understand. Guix Reference Manual does recommend making changes in the source tree, too
<str1ngs>it is documented under contributing
<peanutbutterandc>Oh... I still haven't reached that section yet. I am taking a detour to learn scheme/guile at the moment. So it'll have to be the entirety of guile reference manual first, and then section 4 of guix manual *sigh*
<str1ngs>I understand let me know if you need any help. personally for this I would go with the patch approach off of if you prefer to use git proper you can just add my staging repo as a remote.
<str1ngs>then you want run into potential channel issues just for one package
<peanutbutterandc>str1ngs, Hmm... then I would like to go with the patch approach. How would I go about doing it please?
<str1ngs>peanutbutterandc: see
<str1ngs>peanutbutterandc: assuming you have cloned guix already
<str1ngs>for reference I use ~/src/guix.git
<peanutbutterandc>str1ngs, I get a 404 for the URL and tried looking for that section in the manual but can't see it in the Table of Contents
<str1ngs>peanutbutterandc: google guix contributing should be enough
<str1ngs>strange you are getting 404 error though
<str1ngs>peanutbutterandc: do you use emacs?
<peanutbutterandc>str1ngs, I am learning it, yes sir. `info guix`?
<peanutbutterandc>Whoa. 'info guix' has a Tracking bugs and patches but the html version does not
<moesasji>strings: That section heading doesn't seem to feature in the manual; maybe that is why it gives a 404
<peanutbutterandc>Section 14.7
<peanutbutterandc>I thought the whole idea of of texinfo was one source many formats...
<str1ngs>moesasji maybe I'm getting some http caching then
<str1ngs>but why would that section be removed that does not make sense
<str1ngs>maybe it was moved, not removed?
<moesasji>I'm trying to get the guix building from a git branch and didn't see this specific section online at all.
<str1ngs>moesasji does give you 404 too?
<moesasji>yes it does.....and if I search for it using google I get no appropriate hits.
<peanutbutterandc> is throwing a 504.
<moesasji>strings: info guix for me also doesn't have this section.
<str1ngs>issues ... well it generally has issues lol
<peanutbutterandc>I just read the section from info guix d1ac643062b51ea69ed2413e2d4457ab8db4fd9d but the section seems to be incomplete. It only talked about the web urls to track (via web) and not about using the patches to test things locally....
<peanutbutterandc>But perhaps it assumes the knowledge
<peanutbutterandc>But since I am a n00b, help please
<peanutbutterandc>I understand the "apply tuxguitar patch to your local copy of guix" part. What then?
<peanutbutterandc>Do I set that as a package path and then do guix install tuxguitar?
<str1ngs>there is definitely a Contributing section in the Guix manual
<str1ngs>once the patch is applied now you can do ./pre-inst-env guix build
<str1ngs>peanutbutterandc: assuming you have done configure --localstatedir=/var and make?
<str1ngs>withing a guix enironment guix
<peanutbutterandc>Whoa. That's a lot. Perhaps I will go with the guix package path environment variable route. And --rollback once the testing is done. Seems like a much easier way to do it (for a n00b, anyways). Plus, no souce building. Should save me some time?
<str1ngs>I would not use GUIX_PACKAGE_PATH with guix.git. IMHO
<str1ngs>the building is one time. after that is' incremental. plus it doesnt taint guix pull etc
<str1ngs>also with ./pre-inst-env guix environment --ad-hoc tuxguitar -- tuxguitar . it won't taint my profile either
<peanutbutterandc>str1ngs, Is there a side-effect to GUIX_PACAKGE_PATH that I should be aware of? I will go your recommended route then. (and ask questions as they arise)
<str1ngs>in most cases no, but when used on guix.git its going to auto compile a whole lot of things. its easier to boostrap it one. then you are done
<str1ngs>bootstrapping is not much more work then a guix pull. and it's incremental so you only really have to do it once
<str1ngs>take that last statement with a grain of salt. it is cheaper to build incrementally is the take away there.
<peanutbutterandc>str1ngs, I see. So first I git branch this_branch_contains_str1ngs_tuxguitar_patch and then I apply the patch and then, in that branch I configure and then do ./pre-inst-env; and if you make some more changes, I'll have to patch those changes in and then do the thing again, right?
<moesasji>peanutbutterandc: go one step at a time; first try to follow the steps in the manual without patching.....if that works start with modification.
<peanutbutterandc>moesasji, I see. Okay. Which section in the manual, again, please? (Sorry. Too much n00b)
<moesasji>just search for "contributing guix"; that should get you to the right section.
<peanutbutterandc>I see. Thank you.
<peanutbutterandc>This is such next-level stuff for someone whose only experience with collaborative git so far has been GitHub PRs
<str1ngs>peanutbutterandc: clone and build guix.git see . after that you can use guix simply by doing ./pre-inst-env guix <command>
<str1ngs>peanutbutterandc: after that apply the tuxguitar patch. now you can build tuxguitar.
<peanutbutterandc>Okay. One step at a time. You can do it, peanutbutterandc :D
<str1ngs>peanutbutterandc: if you don't want to use a patch approach. you can clone my repo but you still need to build guix either way
<str1ngs>peanutbutterandc: I as looking at this which has p2p issues built on ipfs
<moesasji>str1ngs: are you doing this on a guix system or on a foreign distro?
<peanutbutterandc>Wait. So I first `guix environment guix` and then `./configure --localstatedir=/var` (which will be referring to the /var inside the container, and then ./pre-inst-env guix command inside that container? This is like inception level stuff
<peanutbutterandc>I am on a foreign distro, BTW
<str1ngs>moesasji: guix system. but both work
<str1ngs>I also use guix foreign so the same process applies
<moesasji>I'm on a foreign distro and it fails for me at the moment. No clue why.....
<moesasji>hitting this error message:
<str1ngs>moesasji: do you use guix environment guix --pure first?
<str1ngs>moesasji: please use guix environment guix first
<moesasji>done that, but not yet the pure option. Just tried the container option (-C) as suggested in pjotr's guide.
<moesasji>that made no difference.
<str1ngs>no need for container
<str1ngs>moesasji: try with guix environment guix --ad-hoc guile-gcrypt
<str1ngs>moesasji: actually better yet guix environment guix --ad-hoc guile guile-gcrypt
<peanutbutterandc>Okay I just ran `guix environment guix` Now do I go for ./configure ... ?
<moesasji>pretty sure I tried that already; the exact steps as given in the manual definitely don't seem to work for me.
***ng0_ is now known as ng0
<peanutbutterandc>or bootstrap? o.O
<peanutbutterandc>running ./bootstrap
<peanutbutterandc>(because there was no ./configure) and the manual said ./bootstrap second
<str1ngs>moesasji: try anyways to confirm it doesn't work please
<str1ngs>peanutbutterandc: yes you need to boostrap first. it's a one time thing specific to git repo only. not the source tarball
<moesasji>str1ngs: just need to think a bit as this is the third time I have now build guix from source. Using manual, approach that was in one of posts on guix dev, then pjotrs guide.
<moesasji>the build completes, but somehow I don't see the paths exported by the ./pre-inst-env script.
<str1ngs>moesasji: this specific err no code for module (gcrypt hash) indicates guile-gcrypt is not availible. which is highly plausible on a foreign distro. the command I gave should make it availible.
<moesasji>OK; will give that a go....and keep quiet for another hour as a result. ;)
<str1ngs>if I was to make a guess maybe you are using debian or ubuntu. I'll wager the later?
<str1ngs>moesasji: no need to keep quite. you may need to run configure again which is okay
<moesasji>neither: I'm on Slackware current
<str1ngs>if you are on slackware I'd say guile-gcrypt is not available using pre-inst-env so the need for the command I gave.
<str1ngs>theoretically you could install guile-gcrypt into your profile. but personally the environment would be more stable
<moesasji>OK. Will have a go. Thanks for the help
<str1ngs>no problem
<str1ngs>don't forget to ./configure --localstatedir=/var for good measure. while in guix enviroment
<str1ngs>just encase something has moved around. if you still get the (gcrypt hash) error. check that you have not manually set GUILE_LOAD_PATH somewhere
<str1ngs>tough I think --pure should handle that situation
<peanutbutterandc>str1ngs, After a make failure, I tried just plain old `./pre-inst-env guix --version` and it works. Can I skip make?
<str1ngs>peanutbutterandc: I would not skip make, what is your make failure?
<str1ngs>as in what is your error
***janneke_ is now known as janneke
<peanutbutterandc>str1ngs, This is strange. ./pre-inst-env guix --verion gives me a different version string than the one I have. Also, ./pre-inst-env which guix tells me that it is actually running a script called guix from inside scripts
<peanutbutterandc>and that script's code does not seem to be all that magical as guix
<str1ngs>this looks like you high C-c though
<str1ngs>^Cerror: failed to load 'gnu/packages/video.scm
<peanutbutterandc>Just 50 lines. and ./pre-inst-env guix show tuxguitar is just stuck?
<str1ngs>did you run make after configure?
<peanutbutterandc>Oh yeah... I didn't realize that. Sorry. My computer froze. I don't remember C-c-ing. Yes, sir. configure and then make. I'll re-run make again
<str1ngs>you need to run make. or it will try to auto compile which is a PITA
<peanutbutterandc>I see. That makes sene
<peanutbutterandc>Thank you
<peanutbutterandc>Or, one could perhaps export GUILE_AUTO_COMPILE=OFF or sth (from guile manual)?
<str1ngs>yes, but then everything is CPU bound. running make is one off. and then incremental from there
<str1ngs>so it's a more ideal scenerio
<peanutbutterandc>str1ngs, Could you pleae me what "incremental from there" means? As in, the way I have done a bit of C so far, I do something, I compile it, and if I only change a typo (in hello.c, for now), I have to recompile the whole thing. Oh... wait. It is becasue we use make. And make only makes the files that are newer than the binaries. Silly me. (Did I get it right?)
<str1ngs>peanutbutterandc: right it only builds changes files after
<peanutbutterandc>Also, does guile compile a LSB binary file thingy? How can I compile hello.scm to a binary with guile? I thought the .go files weren't exactly LSB-binary thingies
<str1ngs>and say in the case of the tuxguitar patch it will only auto compile music.scm vs the whole git repo
<peanutbutterandc>Ah! Yes, that certainly makes a whole lot of sense. Thank you
<str1ngs>can we just call LSB binaryies. elf? :P
<peanutbutterandc>I was thinking only in terms of the compiler and not make. Okay elfs
<peanutbutterandc>str1ngs, Is there a way I can `guile -o hello hello.scm` just to poke around? o.O
<oriansj>well the problem with scheme compilers is they have to embed alot of themselves in the binaries they generate, otherwise you get weird behavioral changes
<str1ngs>to compile you want to use guild
<oriansj>eg if foo.scm is (define (main args) (display (+ (car args) 1))); one has to include alot to get it to do the *right* thing
<oriansj>such as arbitrary precision primitives, garbage collection, stack manipulation, list primitives and arbitrary string processing primitives
<oriansj>should one wish to compile it to just foo (as an ELF binary)
<oriansj>unless it just becomes a shell script and doesn't work on systems that don't have guile
<peanutbutterandc>Phew! My internet connection...
<peanutbutterandc>It kinda' threw me off. Let me check the logs to see what I missed
<peanutbutterandc>Okay. So I just took the compiled .go file from GUILE_COMPILED_CACHE PATH thingy and chmod u+x and ./hello.scm.go and it didn't work
<oriansj>peanutbutterandc: that is because guile compiles it to its own personal bytecode architecture to execute
<oriansj>it needs to run on the guile virtual machine to work
<peanutbutterandc>oriansj, I see. I just tried to figure out what my `which guix` was and it turns out `guix` is just a script, still. My whole life has been a lie. lol
<str1ngs>peanutbutterandc: think of guile as a VM. but it's also a compiler tower.
<str1ngs>peanutbutterandc: see
<nckx>Same goes for Java and .exe binaries, you can use a custom binfmt interpreter to make ‘./hello.scm.go’ just work but there's probably no good reason.
<peanutbutterandc>oriansj, Ah the virtual machine thing. While I don't fully understand it, I heard that because Java has a VM, it is write once run everywhere. And one can make android apps with java. Does that mean one could in theory make android apps with guile? [Yes, I am an abosulte n00b]
<str1ngs>peanutbutterandc: it's common for guile programs to have a bash file for entry. though all the modules will be compile so the performance is still good.
<leoprikler>You can make Android apps in Java, because Android is built on top of a JVM.
<oriansj>peanutbutterandc: well virtual machines simplify the problem often found in hardware (their designers suck at their jobs)
<peanutbutterandc>Ah... I see.... but now, with guile3 there is something called just in time compilation. Which is supposed to be a whole lot faster. Does that JIT compiler compile to C-like ELF or the same old guile-VM code?
<peanutbutterandc>leoprikler, I see...
<str1ngs>VM is basically abstracted hardware.
<leoprikler>you'd have to write your Scheme-y Android code in Kawa, Clojure or any other LISP/Scheme that compiles to JVM bytecode
<leoprikler>or write a compiler from Guile VM to JVM
<peanutbutterandc>Ah! So the fact that guile uses a VM is why guix can work in multiple architectures and cross compile?
<oriansj>for example you want to do R0 = R1 * R2 (but only get the top half); x86 makes that a bitch to do
<peanutbutterandc>leoprikler, I see...
<leoprikler>It certainly makes it easier.
<peanutbutterandc>oriansj, I see....
<leoprikler>You can write portable C, but there's much undefined behaviour and architecure-specific stuff in many C programs.
<oriansj>or if you wanted to divide any register besides EAX:EDX
<nckx>peanutbutterandc: There's been work to make Guile better support ‘pluggable back ends’ (for example to compile Guile to WASM, though why you'd want to I do not know). You could make it emit JVM bytecode if you wanted to.
<peanutbutterandc>Whoa. You guys really are a bunch of wizards, aren't you? Talking about all the low-level stuffs. Super cool
<oriansj>peanutbutterandc: well if you want to know about about the low ends stuffs checkout #bootstrappable
<oriansj>we literally are bootstrapping GCC from a 357byte hex monitor
<leoprikler>Guile to WASM would be kinda neat though.
<leoprikler>Imagine running Guile code in those lame browsers that were built without Guile support.
<nckx>peanutbutterandc: JIT means that it generates native (non-VM) code on-the-fly.
<leoprikler>e.g x86 instructions
<oriansj>as native is always faster than VM instructions
<nckx>Calling x86 ‘native’ is probably a political statement in itself but let's assume it's true.
<peanutbutterandc>Whoa. So when Mr. Wingo said "I am not going to say we'll be faster than C, but we'll get there" or so, he really meant it.
<leoprikler>nckx: Well, it's the nativest you can get on an x86 board, even if that CPU is itself an interpreter that JIT-compiles to some RISC.
<oriansj>peanutbutterandc: for the selection of problems where scheme is a better match than C, yes absolutely
<oriansj>leoprikler: a VLIW which no one is allowed to know the details of if one wanted to be precise
<nckx>leoprikler: Sure. That aside wasn't aimed at you specifically, I didn't notice your x86 comment until afterward.
<peanutbutterandc>Me right now: 😲 I thought all of you were just functional programming wizards but it seems you practice wizardry at near-the-metal levels too.
<leoprikler>That's the wizdom that comes from implementing at least one compiler on your own, even if you hate yourself after doing so.
<oriansj>peanutbutterandc: to make fast code, you must understand the machine it is running on
<oriansj>or atleast taking the time to understand how a compiler works:
<peanutbutterandc>leoprikler, I was actually going through but it's on a hiatus
<oriansj>it is all alot simpler than you think:
<peanutbutterandc>oriansj, Oh wow. Transpiler as in something that compiles a source code in one language to another?
<janneke>nckx: friendly ping to ack grub resolution #38809, or is there anything you need?
<nckx>peanutbutterandc: You'll always be able to write a faster C version of a Scheme programme simply because it does less (e.g. memory management is now your problem, have fun), and you can better tailor your code to the hardware. But it turns out that humans really suck at doing that correctly and securely. ‘Faster’ is often not worth it.
<janneke>if it doesn't have to be correct, there's always a faster implementation
<oriansj>peanutbutterandc: yes, in that cause it compiles C to assembly
<leoprikler>nckx: Even if you compile your Scheme code with Stalin?
<oriansj>nckx: scheme is better at fault handling than C in terms of performance
<nckx>janneke: I didn't realise you were waiting for an ack. I trust you, and you now know what to test for. If you want me to test it too I can do so this evening?
<nckx>oriansj: Even Guile? (With its ‘special’ C-compat call/cc)
<nckx>But I guess that's the same argument in a way 🙂
<oriansj>nckx: most C programmers suck at implementing them; so yes
<alextee[m]>Use C for everything! Where's my C web app framework :/
<leoprikler>Guix is the best in error handling, obviously.
<peanutbutterandc>nckx, I see...
<nckx>In backtrace lines/second we are the absolute win.
<peanutbutterandc>oriansj, Was there not a gcc option to give the assembly level code? If I remember correctly?
<alextee[m]>Don't listen to people saying bad things about C!
<oriansj>peanutbutterandc: there is -s
<leoprikler>Yeah, but Java still beats us in backtraces per backtrace ☹️
<nckx>alextee[m]: C is great, it's just not a good fit for the vast majority humans.
<oriansj>peanutbutterandc: however M2-Planet exists for bootstrapping reasons
<nckx>…or problems.
<janneke>nckx: ah, i could have been more explicit -- no hurry, but i'd like a test and ack some time; esp. after you needed to revert it, does that make sense?
<oriansj>Think of C as just portable assembly
<peanutbutterandc>oriansj, I see... I don't think I fully understand but it's a blurry picture... :)
<janneke>nckx: yes, i found a test that failed and now passes...but still :-)
<peanutbutterandc>"portable assembly" Haha :)
<oriansj>peanutbutterandc: we can always clarify any detail you are fuzzy on
<peanutbutterandc>oriansj, What is M2-Planet trying to bootstrap? In n00b-inglish?
<alextee[m]>nckx: well, it gives you great power as a high level language, but with great power comes great responsibility!
<peanutbutterandc>Itself, by the name "bootstrap"
<nckx>alextee[m]: …as I said, a bad fit for the vast majority of humans 😉
<nckx>You're right, of course.
<peanutbutterandc>but what does it do, again? (It's probably an insult to ask such n00bish questions, sorry)
<alextee[m]>Hehe, i guess
<peanutbutterandc>Also, is gnu shepherd written in guile, too?
<nckx>Get the ‘write good C’ cybernetic implant and you're good.
<nckx>Just hope that the implant firmware isn't written in C.
<oriansj>peanutbutterandc: M2-Planet is effectively a C compiler that can be compiled by cc_x86 (a c compiler written in assembly )
<str1ngs>janneke: I resolved my emacsy-ran-undefined-command? issue. emacsy-tick can be called twice it just needs to be avoid when emacsy-display-minibuffer? is true
<leoprikler>nckx: No problem, it's written in assembly.
<viaken>alextee[m]: I don't have a C framework handy. Can I interest you in a Forth one?
<oriansj>peanutbutterandc: thus allowing us to bootstrap C compilers such as GCC without having to depend upon any C compilers in our bootstrap binaries
<nckx>janneke: Just a misunderstanding. You want to explicitly include a ‘?‘ somewhere if I'm involved, or I'll just assume it's an FYI.
<peanutbutterandc>oriansj, A cc_x86 c combiler compile M2-Planet, and then M2-planet compiles C programs, including the very code that the initial cc_x86 compiled to create the first M2-planet compiler? #compiler-ception ?
<oriansj>peanutbutterandc: it is called self-hosting
<viaken>alextee[m]: DDG gives me as a C web framework.
<alextee[m]>viaken: what is forth o_o
<janneke>nckx: sure, np -- i'm often a bit too implicit
<str1ngs>janneke: I will try to eventually update the emacsy examples. for nomad I use g-timeout-add which might be better suited for the examples as well. would avoid the high CPU usage the examples have IIRC
<peanutbutterandc>oriansj, Wait, so M2-planet can then go on to compile the standard GNU-C compiler which is used to compile basically everything (including Linux Kernel and HURD)?
<alextee[m]>viaken: yeah i saw that but doesnt look very promising. I found another called kore
<oriansj>peanutbutterandc: that is the plan (via Gnu Mes)
<viaken>alextee[m]: If this is your first exposure to stack-based languages, have fun learning there. Forth is one of the oldest programming languages no one's heard of.
<peanutbutterandc>oriansj, and this initial cc_x86, where does that come from? o.O
<janneke>str1ngs: oh great, that's good news; yes, the examples are terrible
<oriansj>peanutbutterandc: you build it M0
<oriansj>which was written in hex2
<peanutbutterandc>oriansj, Whoa! M2-planet is mentioned there. I have a feeling that without knowing it I'm talking to someone very very important here.
<nckx>I thought Forth was that one weird language everyone had heard of.
<alextee[m]>viaken: no type checking, oof
<str1ngs>janneke: I will update them sooner if there are any user inquires.
<oriansj>peanutbutterandc: everyone here is important; everyone deserves kindness and consideration
<alextee[m]>I want to be scolded by the compiler otherwise i cant program
<peanutbutterandc>oriansj, That makes me want to cry. Somebody actually wrote that down, by hand, in hex2?
<viaken>alextee[m]: I mean... It's from 1970. What do you want?
<janneke>str1ngs: sure, no hurry!
<oriansj>peanutbutterandc: yep and wrote the program that can build hex2 in hex1:
<viaken>alextee[m]: If you need typed, is a statically typed stack based language.
<oriansj>and wrote that hex1 assembler in hex0
<oriansj>and then we hit bottom with hex0:
<alextee[m]>viaken: oh god that code example
<peanutbutterandc>oriansj, Whoa. Does that mean... that this self-hosting system... if the entirety of the world tech somehow disappeared overnight and only these remained, we'd get back to a GNU Dawn pretty soon?
<oriansj>peanutbutterandc: well once mes-m2 is done; we would be completely operational inside of a week
<peanutbutterandc>oriansj, This is like super sci-fi stuff here. So... mes-m2 will then compile GNU-C-compiler and GNU-C-compiler would then compile GNU/HURD?
<oriansj>peanutbutterandc: mes-m2 is a scheme interpreter that is directly buildable via M2-Planet
<oriansj>as Gnu Mes requires a working scheme interpreter to compile C code to bootstrap GCC
<nckx>peanutbutterandc: You've probably been indocrinated to think the natural order is asm → C → Scheme, but it's asm → Scheme → C 😉
<oriansj>and when mes-m2 is done; it'll be a drop in replacement for guile; thus allowing guix to do the build process, bootstrap guile and MesCC to bootstrap the world of Gnu in one go
<leoprikler>Waiting for Scheme → asm → Scheme → C.
<leoprikler>or Scheme → {asm, C}
<peanutbutterandc>oriansj, This m2 project. This seems so super cool. All it needs is something like this: ( the comic from the lower part of the pages to explain things to not-wizards-yet people like myself
<oriansj>nckx: well it is actually:
<peanutbutterandc>nckx, Whoa
<peanutbutterandc>I still can't wrap my head around this but whoa!
<oriansj>peanutbutterandc: to become a wizard, spend more time helping out wizards; you'll pick up alot of magic that way
<nckx>Scheme → BASIC → GOTO Scheme ;; recursion??
<peanutbutterandc>oriansj, "thus allowing guix to do the build process, bootstrap guile and..." meaning that guix could run in a world where guile has suddenly disappeared?
<peanutbutterandc>nckx, I have read that using GOTO is a cardinal sin. :D
<oriansj>peanutbutterandc: when mes-m2 is done, yes
<peanutbutterandc>oriansj, Whoa. But how will that 'guile' that guix bootstraps in that hypothetical world be guile as it is and not racket or mit-scheme? o.O
<oriansj>peanutbutterandc: we have the source code for guile, that we can bootstrap from
<peanutbutterandc>oriansj, Ah... I see. And guile source is in C. Yes. That makes sense. So basically, if everything from the world disappeared, except for their source code. But if we even lost all the compilers and interpreters. And all we had was just python and guile source code written in C but no compiler to compile it from, all one has to do is run to the secret vault where GNU hackers have hid the m2 thing and within a week, everything is back to normal
<peanutbutterandc>I hope I got that right
<oriansj>peanutbutterandc: close enough;
<oriansj>one only needs source code and a single 357byte binary
<peanutbutterandc>oriansj, Whoa. Super cool. I am sorry to ask but what would this high level of bootstraping/self-hosting wizardry mean for the common people living in a world without aforementioned hypothetical disaster? What magic can we expect?
<peanutbutterandc>357byte binary... could that be ridden of too, and replaced with normal soldered chip-circuit hardware magic?
<oriansj>peanutbutterandc: well end users will never know the difference, developers on the other hand get a path of trust that is universally auditable and inspectable
<oriansj>peanutbutterandc: one could also hand toggle in 357bytes into memory using dip switches
<oriansj>we did in fact write a hex0-monitor after all (and a text editor written in hex0)
<oriansj>(here it is in assembly:
<moesasji>Hi All, still trying to work out how to work with guix build from source and stuck on something that is probably obvious.
<moesasji>I've build using guix environment guix --add-hoc guile guile-gcrypt. That works and guix --version gives me a different version from the one using ./pre-inst-env
<oriansj>peanutbutterandc: and here is the hex0-monitor:
<moesasji>However if I leave that environment I get a backtrace when using ./pre-inst-env guix --version, yet I have both guile and guile-gcrypt installing using guix. Can someone explain why?
<nckx>You could replace the DIP switches with even simpler (if more fragile) contacts and pull a home-made punch card through them for sweet reproducible builds.
<peanutbutterandc>oriansj, Whoa. Another question: don't the developers currently have a path of trust? After all the GCC is Free Software? And so are so much of the other infrastructres... how does the m2 project give devs a path of trust that is universally auditable and inspectable that they don't have already? (Maybe I don't see something here)
<oriansj>nckx: fuck that, paper tape reader
<nckx>Eh, what's the diff?
<oriansj>peanutbutterandc: you may wish to learn about:
<peanutbutterandc>nckx, Doess that mean if we sent oriansj with m2 project and all the source code we have back to the 60s Bell Labs, he could, in theory, show Mr. Thompson the language that he'll go on to create in 2008 (GoLang) in 1960s?
<nckx>oriansj: I didn't mean whatever-standard card stock 😛
<nckx>This is the apocalypse.
<peanutbutterandc>oriansj, Thank you, sir! I will read up on it. :)
<peanutbutterandc>This is so cool.
<oriansj>peanutbutterandc: just remember you too are important; learning from others and sharing that skill with others is quite important to preserve the most important knowledge we have
<oriansj>nckx: apocalypse or not, fuck punch cards. spend the extra pound of rat meat and get a proper 8bit paper tape reader
<moesasji>str1ngs: I get this backtrace when running ./pre-inst-env guix version --version: Any idea why that is as both guile and guile-gcrypt are in the environment?
<nckx>I obviously triggered some deep trauma by using the word ‘card’ when I obviously should have said ‘tape’ 😃 Someone drop a box in high school…?
<peanutbutterandc>oriansj, Whoa. Thank you very much. Could you please also recommend some books that I could read to understand more of these stuffs? I'm not that good with computers yet. But I'd like to be able to do some wizardry someday too.
<oriansj>peanutbutterandc: talking to people is the best way people learn
<Parra>is it possible to enable downloads during build with guix? even if it breaks reproductible builds
<nckx>peanutbutterandc: If we're writing speculative sci-fi anyway, I guess so. You could do the same with a box of printed hard-copy C source (they'd be able to decipher our modern dialect).
<oriansj>so join us on #bootstrappable and ask every dumb question you can think of
<peanutbutterandc>oriansj, I see. Thank you, sir. You have been very kind.
<oriansj>peanutbutterandc: everyone deserves kindness and consideration.
<nckx>Actually running any of it would not be trivial. ‘Hi, I'd like to show you ‘Go’. Where's the largest supercomputer you have? I'll need MEGABYTES of memory.’
<peanutbutterandc>nckx, Cool! Does it also mean that someday guixSD could ship a version, hypothetically, that would bootstrap itself from the 300-sth byte binary so as to have the complete chain of trust that was being referred to?
<peanutbutterandc>oriansj, :)
<peanutbutterandc>nckx, Haha :D
<leoprikler>Something irks me about the 357 byte bootstrap. Specifically, the odd number of bytes is… odd.
<oriansj>nckx: well bringing back knowledge of 500nm lithography would solve that problem too
<nckx>peanutbutterandc: Sure. The post-apocalyptic box-set. It would take a while to bootstrap but it's certainly possible.
<oriansj>leoprikler: well you could always make it smaller
<oriansj>peanutbutterandc: well that kinda is the goal right now:
<nckx>oriansj: You're assuming you can just hitch a trailer to your DeLorean and it will make it through? I don't think that's canonical.
<peanutbutterandc>nckx, "Guix SD: Post-Apocalyptic Box-Set. Buy now to support the FSF! Running on RISC-V Librebooted Laptop!" I'd so totally want that!
<oriansj>nckx: skip trailer, it'll only take about 2K pages of text
<peanutbutterandc>oriansj, Oh wow! This bootstrap: this happens during the installtion of GuixSD, I presume? I am still using just a foreign distro (debian).
<oriansj>peanutbutterandc: well we are heading towards having guix bootstrap from the Gnu Mes part of the bootstrap graph shortly ( janneke will be doing a talk about it at fosdem: )
<oriansj>although if you want to catch up on the old bootstrapping talks:
<oriansj>(it is probably just best to git clone '' as I try to keep it up to date with the latest in bootstrapping)
<oriansj>(org-mode files look best in emacs)
<str1ngs>moesasji: looking at the backtrace now
<peanutbutterandc>oriansj, Whoa. Super cool!
<str1ngs>moesasji: what is the full command you are using for guix environment?
<moesasji>str1ngs, both guix --version and ./pre-inst-env guix --version work in the environment created with guix environment guix --ad-hoc guile guile-gcrypt.
<str1ngs>moesasji: can you try with --pure see if that helps. I'm wondering if GUILE_LOAD_PATH gets clobberd
<moesasji>However ./pre-inst-env guix --version gives that backtrace outside the environment with both guile and guile-gcrypt installed
<str1ngs>please for this case use a guix enviroment
<moesasji>I think my question is what the logic for using the environment is once guix is build from source.
<msiism>I've just been looking at the Guix website and was wondering: If Guix (I mean GuixSD) is a GNU/Linux distribution, why isn't that mentioned right in the overview at the top of the page or, at least, in the introduction of the Guix Manual?
<slyfox>it also has some support for hurd
<peanutbutterandc>str1ngs, `make` completed successfully. What was the next step again, please? Patch music.scm and then run ./pre-inst-env guix install tuxguitar?
<str1ngs>moesasji: it's mainly do to foreign distro. you might have success if you install guile and guile-gcrypt into your profile. then do configure and make
<str1ngs>moesasji: but that's still kinda flaky.
<str1ngs>moesasji: so my understanding is ./pre-inst-env guix works but only while in a guix environment?
<moesasji>str1ngs: it works and in the process of setting up a guix system; having a heavily remapped keyboard makes it a hurdle as i need to get a spacefn functionality working on it.
<str1ngs>moesasji: spacefn like xcape you mean?
<moesasji>str1ngs: yes that is correct. It works fine in the environment
<msiism>slyfox: Ok, then that could simply be mentioned as well, I'd say. Perhaps something like: a runnable GNU/Linux system is available, a version based on hurd is in the works, or some such. I mean, the way it is written now is just really unnecessarily confusing and looks like the project was trying to hide something, which I guess it isn't.
<moesasji>xcape doesn't work well for spacebar; i currently use a modified part of xorg instead.
<slyfox>i suggest filing a bug
<str1ngs>moesasji: okay you could try ./configure and make with guile and gule-crypt in your profile.
<str1ngs>moesasji: but if you are just using guix system build etc. kinda more work for less gain
<moesasji>str1ngs: no worries I was just trying to get to a state where I could add bits that I need on my new machine.
<str1ngs>moesasji: also you can try with ./pre-inst-env guile -c "(display %load-path)" outside of guix environment
<str1ngs>maybe that will shed some light
<str1ngs>moesasji: I use xcape for ctrl space modifier. I'd be interested how X11 is method is better.
<str1ngs>moesasji: for me holding space modifies it int a ctrl basically
<msiism>slyfox: Ok, let me see. I'll read the Code of Conduct first.
<moesasji>I type pretty fast and get too many errors with xcape on spacebar. I currently use:
<str1ngs>moesasji: yes I do need to pace myself with xcape sometimes. will check this out thanks
<str1ngs>moesasji here's my xcape startup script.
<str1ngs>moesasji: someone just need to produce a modern space-cadet keyboard :P
<moesasji>str1ngs: looks familiar. I've been looking at interception tools, which should also work on console: But that isn't yet packaged
<moesasji>str1ngs: with that the following one should do what I need:
<str1ngs>moesasji: are you keybinds vi or emacs oriented?
<moesasji>completely customized, which makes me starting to move away from vi.
<str1ngs>I converted from vi/vim myself.
<moesasji>I'm using a heavily modified version of the balanced 12 one in the comments here:
<str1ngs>I found it easier to drop vi/vim and use emacs bindings everywhere
<oriansj>str1ngs: spacemacs is a thing
<str1ngs>spacemacs is terrible
<str1ngs>use-package and xcape can literally replace all of spacemacs
<moesasji>I'm looking at moving over to emacs-objed; seems to be a good middle ground between vi and emacs bindings.
<oriansj>str1ngs: you are not wrong
<oriansj>but some people need time to transistion to emacs
<janneke>took me three summers to move to emacs
<oriansj>especially from vi/vim; that is one hell of a transistion to make
<str1ngs>for me and these is after using vi/vim for over 20 odd years. was using xcape and vanilla emacs and vanilla bindings.
<str1ngs>that was me. I'm sure there are other ways.
<str1ngs>evil is great unto it's self the issues is mode mappings and documentation I found. seemed always like swimming upstream.
<oriansj>str1ngs: well because you effectively were
<str1ngs>right :)
<oriansj>and turning around is sometimes the hardest part; knowing that you'll have to go backwards for a while
<moesasji>str1ngs: did you ever try
<str1ngs>I don't use modal editing any more.
<str1ngs>I just treat Ctrl like a vim leader key in my mind. and use vanilla bindings. granted it took time
<pinoaffe>i saw a lot of talk about parameterising packages on the mailing list - what's the benefit of adding support for parameters to package definitions over standardizing functions/interfaces to procedurally generate / modify packages?
<moesasji>I like it as it sits in particular dropping out the modal mode with spacebar works nicely.
<moesasji>yet all emacs normal commands fit.
<str1ngs>moesasji: that might be nice common ground.
<str1ngs>peanutbutterandc: yep
<str1ngs>peanutbutterandc: just do ./pre-inst-env gux build tuxguitar
<str1ngs>peanutbutterandc: and to test you can do ./pre-inst-env guix environment --ad-hoc tuxguitar -- tuxguitar
<str1ngs>peanutbutterandc: once you are happy then you can install
<janneke>pinoaffe: interesting question
<str1ngs>is it plausible to use emacs-debbugs to apply patches from guix-patches?
<janneke>pinoaffe: in general i prefer transformation over parameterization
<nixo_>civodul: Hi, I was sending the upadated patches on julia + julia-xyz, but I think something went wrong. Do you mind if I send them as attachments to a single mail? (I'm asking you since last time you had a look at them)
<civodul>nixo_: np, attachments are fine!
<sneek>Welcome back civodul!, you have 1 message!
<sneek>civodul, nckx says: I don't get current-module-debugging-port in (gnu build linux-modules). Is it just intended to be hand-edited while debugging?
<nixo_>civodul: fine! Let's wait another bit because I found unrelated changes in a patch, sorry >.<"
<civodul>nckx: well, it's for developers; you could parameterize it in your initrd, or change its default value right in that file
<Parra>I just discovered node build system is just a copy of all js files, it doesn't handle the dependencies
<nckx>oriansj, pinoaffe (re: parameterisation): I wonder the same thing.
<civodul>nckx: but we could also change 'boot-system' to parameterize it if a special kernel command-line argument is passed, like "gnu.modules.debug"
<Parra>I am improving thought, knowing about guix internals makes things easier
<nckx>civodul: The latter was what I expected (sniffing a ‘debug’ parameter from /proc/cmdline). So I was surprised. It seems equivalent to including ‘;; (pk blah)’ which I know you wouldn't do.
<nckx>This question prompted by me adding (pk blah) 😛 It was less work.
<oriansj>nckx: well parameterization does have short term user facing advantages but ultimately I think it might not be the wisest of plans for guix
<oriansj>but then again; I'd love to be proved wrong
<nckx>oriansj: I personally agree but try to keep an open mind.
<nckx>Ah, exact same.
<civodul>nckx: yeah i agree it would make sense to honor a kernel command-line argument, we should do that
<nckx>civodul: You'd keep it module(no pun intended)-specific?
***ng0_ is now known as n0
<rhou[m]>why do I get `configure: error: Guile-JSON is missing; please install it` when running `./configure` in a `guix environment guix` environment
***n0 is now known as ng0_
***ng0_ is now known as ng0
<str1ngs>rhou[m]: are you on foreign distro?
<rhou[m]>str1ngs: yes on arch linux
<rhou[m]>I should mention that I used the `--pure` flag with the same result
<str1ngs>rhou[m]: can you try with guix environment guix --ad-hoc guile guile-json
<str1ngs>pure is good
<str1ngs>though might not find system guile-json if that's what you want
<rhou[m]>I just assumed that the `guix` package should contain all it's dependencies including `guix-json`
<str1ngs>not exactly it's kinda biased towards guix system
<rhou[m]>yes `--ad-hoc` did the trick
<str1ngs>for example on guix system guile-json and guile-gcrypt always exist
<str1ngs>not the case on foreign distro so this can get over looked depending on what distro you are using
<rhou[m]>so in fact it's missing from the inputs list?
<str1ngs>guix environment does not handle native search paths either. *someone please correct me if I'm wrong*
<str1ngs>rhou[m]: see propagated inputs enviroment does not handles those
<str1ngs>you would have to use --ad-hoc or install into your profile
<str1ngs>IMHO --ad-hoc is the best choice it's more explicted
<str1ngs>but if you want to use ./pre-inst-env outside guix environment you need to install those to your profile manually
<rhou[m]>I just wanted to add a package and test it locally
<str1ngs>rhou[m]: this is mainly a foreign disto problem
<str1ngs>rhou[m]: once you have built guix. try pre-inst-env outside of guix environment. might be okay
*mwette posted to bugs-guix regarding SElinux guix-daemon.cil file
<rhou[m]><str1ngs "rhou: once you have built guix. "> ok will try, thanks for the help!
<str1ngs>rhou[m]: no problem
<civodul>nckx: the kernel parameter could map 1-to-1 to current-module-debugging-port; is that what you were asking for?
<peanutbutterandc>str1ngs, Hey there, I just tried `guix environment tuxguitar -- tuxguitar` after all else, and I still have no sound. Anything I might be doing wrong? Tools> Settings> Sounds doesn't show any MIDI server this time around either
<peanutbutterandc>./pre-inst-env, ofcourse
<str1ngs>peanutbutterandc: you sure the patch was applied/
<peanutbutterandc>str1ngs, Instead of applying your patch from the debbugs, I added your repo as a remote branch and merged str1ngs/tuxguitar with master (in a separate branch) and ran from there
<peanutbutterandc>A quick look at gnu/packages/music.scm shows the recent changes that we were talking about (.desktop file installation)
<peanutbutterandc>So the patch was applied. Affirmative.
<str1ngs>peanutbutterandc what are the dependencies for with ./pre-inst-env guix show tuxguitar
<peanutbutterandc>alsa-lib and java-swt
<str1ngs>looks right
<str1ngs>peanutbutterandc: what does the location field have?
<peanutbutterandc>str1ngs, gnu/packages/music.scm:1734:2
<str1ngs>peanutbutterandc: looks good
<str1ngs>peanutbutterandc: can you screenshot the sound dialog window. use scrot -s and click on that window
<str1ngs>peanutbutterandc: eventually also you need to start timidity but I don't think that would effect not haveing any midi output
<str1ngs>there should be something in both drop downs
<peanutbutterandc>str1ngs, Negative, sir. But I see an error from the terminal. Would you like me to send you the screenshot?
<str1ngs>what's the terminal error?
<str1ngs>peanutbutterandc: also what is the output of aconnect -l
<str1ngs>need alsa-utils for that command
<peanutbutterandc>str1ngs, The error in the command line
<peanutbutterandc>str1ngs, It might take me a while to install alsa-utils
<str1ngs>ah are you on foreign distro?
<peanutbutterandc>str1ngs, Yes, sir. A Foreigner by heart! Debian 10. :)
<str1ngs>that could be problematic I will test on foreign distro. maybe I can work around this
<str1ngs>peanutbutterandc: thanks for testing this out
<peanutbutterandc>str1ngs, The pleasure is all mine. I'm happy I could be of some help. And I am very keen on using tuxguitar from guix, too. So thank you all the more! :)
<str1ngs>peanutbutterandc hopeful its just a dlopen issue where I can substitute
***apteryx_ is now known as apteryx
<peanutbutterandc>str1ngs, Please do let me know once it is done and I will test it again.
<guixy>hello guix!
<oriansj>civodul: any news of when the standard guix is going to do fallback to alternate providers of source code tars when the checksums don't match?
<guixy>Don't substitutes provide source code tars?
<guixy>I guess it's only used when you're using guix build --source though
<oriansj>guixy: and guix package -u without substitutes just dies
<guixy>I think it depends on if the current profile is locked.
<guixy>No, it just doesn't recognize that option.
<oriansj>guixy: skip option, it should be the default behavior for guix package -u
<guixy>vim fails its tests when guix builds it for arm, even on arm. But it doesn't fail when guix builds it natively for x86-64. Is this new?
<moewe>hey guix
<guixy>hi meowe
<moewe>so I'm on GuixSD and try to build a package
<guixy>Which package?
<moewe>in my git checkout there's no "configure" and no "pre-inst-env" - do I have to generate them somehow?
<moewe>I'm trying to update texmf because one of it'S packages is out of date and bugged
<moewe>so I have cloned the repository, applied the changes, but I don't know where to go from here
<guixy>git checkout for guix has no configure or pr-inst-env?
<moewe>well it has
<nckx>Hullo Guix.
<guixy>You have to generate them with the "bootstrap" script
<guixy>hi nickx
<nckx>moewe: What guixy said, inside ‘guix environment --pure guix’.
<moewe>huh, it can be so easy
<moewe>sorry wrong window
<guixy>I would think substitutes would be useful for "guix package -u"
<guixy>Especially when you're building something big like kdenlive.
<guixy>or ungoogled-chromium
<guixy>But I also understand when you would want to avoid substitutes.
<guixy>So it's odd that guix package -u doesn't understand the only way to toggle between using substitutes and not using substitutes if they are available.
<moewe>* but it does use substitutes?
<moewe>because I am on an old laptop and I have updated icecat at least once, building it would have taken days
<leoprikler>well, the thing is if you're unlucky CI has not yet completed building whatever package you're trying to update
<leoprikler>especially a freshly pushed icecat is very likely not ready
<moewe>quick question - in the packet definitions, sha256sums are saved base32-encoded, right?
<moewe>since it's "(sha256sum (base32 "X"))"
<nckx>moewe: Yes, it's base32 *but* with a different character set (‘Nix base32’).
<moewe>can I generate it from shell? because echo x | base32 outputs something with newlines and upper case letters only
<nckx>moewe: ‘guix hash’, but it takes a file, I don't know if /dev/stdin will work.
<moewe>it doesn't, that's a shame
<moewe>because the file in question is over 2 gigs, but has a sha256 sums readily available - wanted to spare my internet
<moewe>thanks anyway
<nckx>moewe: You could map the characters by hand… nix/libutil/ string base32Chars = "0123456789abcdfghijklmnpqrsvwxyz";
<nckx>moewe: See page 97 of if you care about the historical (Nix) reasons for this.
<kirisime>Is wireguard in the mainline kernel distributed by guix already?
<nckx>‘This is to reduce the possibility that hash representations contain character sequences that are potentially offensive to some users’
<nckx>kirisime: It's not in mainline at all.
<nckx>kirisime: The wireguard package has a :kernel-patch output that you need to apply.
<kirisime>nckx: Right, so I don't get to remove it yet.
<nckx>Last I heard there was a good chance of it landing in 5.4.
<kirisime>And last I heard it's definitely coming in "some future version" according to 2019
<nckx>It's not wrong.
<moewe>one last question: do I need to make guix inside the checkout before I make a guix package?
<moewe>some guy in an email told me I needed to do so, but the cookbook says to simply use ./pre-inst-env
<nckx>moewe: You definitely want to.
<nckx>And if you've modified more than a handful of packages you'll want to run make again to improve performance (Guile will ‘helpfully’ warn you about each file that's being interpreted, which is slow).
<nckx>For once, some guy on the Internet was right.
<alextee[m]>does install-file work for whole directories too?
<alextee[m]>i'm looking for an equivalent to (for-each (lambda (file) (install-file file bin)) (find-files ".." "\\.lv2$"))
<alextee[m]>but for directories
<vup>moewe: for your sha -> base32 problem: i just created a simple service that converts arbitrary hex strings to nix base32:
<vup>to convert a hex string to nix base32 just add it to the url
<vup>for example:
<vup>maybe this is of use to some of you
<nckx>vup: This fills me with many conflicting emotions. Well done.
<vup>why ;)
<polezaivsani>Hi! When provisioning services on guix system, do the related packages get pulled in automatically? E.g. for wpa_supplicant, having (service wpa-supplicant-service-type) is enough, but is it the case in general?
<alextee[m]>are there any known issues w ith opengl in guix?
<alextee[m]>some OpenGL GUIs show as black and apparently it only happens in guix
<nckx>alextee[m]: I've played more than a handful of high-end (well, for my laptop) GL games on Guix and never noticed artefacts.
<alextee[m]>hmm i see
<nckx>polezaivsani: Yes, all services are self-contained. However, they are orthogonal to system packages, so having wpa-supplicant-service-type running doesn't give you the command-line wpa_supplicant. That's provided only by (package '(wpa-supplicant …)).
<nckx>alextee[m]: In fact I've been pleasantly surprised by risky ‘enable hardware acceleration’ knobs in non-3D applications like IceCat too. Never seen bugs. Which driver/card do you use?
*nckx uses i915 which is probably the best-tested Linux driver ever.
<alextee[m]>nckx: intel onboard
<alextee[m]>but i think this is a problem with upstream
<nckx>Really? Hm.
<alextee[m]>i just tried the same thing in an archlinux VM and it's black there too
<nckx>Ah. May I ask which GUI this is?
<alextee[m]>the example plugins found in "bin" after you run make
<nckx>So not something I can trivially ‘guix build’.
<alextee[m]>you'll need a host to open them too lol
*kmicu is passing longer and longer strings to the new hip service.
<nckx>Or is this dpf-plugins?
<alextee[m]>i made a quick n dirty package
<alextee[m]>nckx: dpf-plugins are plugins using this framework, and they work properly
<alextee[m]>but the example plugins from DPF don't seem to work properly (on my system at least lol)
<nckx>Hi kmicu. Could you submit a patch to rip out (guix base32) and upgrade it to use only this modern Web microservice? Thanxxx.
<alextee[m]>gonna try on a debian machine now to verify that it's an upstream problem, i don't trust VMs for opengl stuff
<polezaivsani>nckx: thank you so much! does it mean that the service will get its dependencies, just not my profile?
<nckx>polezaivsani: Exactly!
<nckx>alextee[m]: That's a good idea.
<kmicu>Yep, creating a service ‘accepting arbitrary […] strings’ (and caching them) is not the best idea xD
<kmicu>Mea culpa, service is already broken xD
<vup>good thing it gets automatically restarted when it breaks :P
<kmicu>Let me tell you about this amazing tool called 🖐 while loop 🖑 ;)
<nckx>Why the hell does Hexchat render 01F590 but not 01F591.
<nckx>Can we restart ‘computers’ from scratch please I've the feeling we went wrong somewhere.
<vup>Ah yes let me put it under cloudflare dos protection
*kmicu will not start venting about ternary computing and why choosing binary was our first mistake.
<kmicu>🖐 2020 is the year of Guix on Ternary Soviet Computers 🖑
<apteryx>oriansj: Can't Guix already download tarballs from Software Heritage?
<civodul>oriansj: no news, as in: we're all waiting for someone else to fix it :-)
<civodul>apteryx: it can, but not upon hash mismatches
<nckx>apteryx: The problem is it won't try if the upstream URL returns 200 with bogus/different data.
<apteryx>I see!
<civodul>for those who can read French:
<civodul>the article is very positive, but then in comments people describe it as an "academic" project for "RMS fans with a beard"
<civodul>go figure!
<nckx>I can read French but not write well enough to sound credible on les internets. Francophones, assemble!
<nckx>civodul: The rest of that comment makes about as much sense TBH. It's like they just heard about Guix today and improvised a bad take on the spot.
<civodul>nckx: yeah, looks like this!
<civodul>anyway, it's always interesting to read someone's first impressions
<nckx>Thanks for posting the link.
*civodul finally watched
<civodul>lots of good ideas in there
<kirisime>I have been building for many hours and I'm still building. Truly this is the source-based distro experience.
<mwette>in case anyone cares, SElinux error building openssl: " set-up failure: CONFIG_HEADER not defined"
<kirisime>If I put my own computer in machines.scm will I be able to build on both of the machines at the same time?
<civodul>kirisime: did you enable substitutes?
<kirisime>civodul: Yes, what I'm doing is patching some stuff in GNOME depencencies so it's taking a while.
<civodul>ah, ok
<nckx>mwette: We care, it's just very hard to debug SELinux-related failures when almost nobody uses it <>. Have you enabled substitutes?
<nckx>kirisime: I've never tried that, let us know if it works 🙂
*apteryx wrestles with c++ (
<sameerynho>is it possible to run guix without the daemon ? i mean in a way that guix itself handle the guix-daemon job
<sameerynho>i need to use guix as a package manager for my emacs
<civodul>apteryx: it looks like warnings from the "system headers", which is a problem on our side (we use CPATH and thus those non-Inkscape headers are not considered "system headers", and thus warnings origininating in those headers go through)
<civodul>dongcarl had worked on it last month or so
<civodul>not sure what the status is
<civodul>hey, right in time :-)
<leoprikler>sameerynho: if you can write another guix daemon that essentially does the same, yes
<dongcarl>Oh? What's going on?
<dongcarl>Sorry been configuring my IRC client so lots of missed messages
*kmicu links to cuz that’s relevant to Guix future too.
*nckx reading, but could you explain why, kmicu?
<kmicu>nckx: Cuz one of their goals was a welcoming community and they, partially, ended up with a mob harassing others.
<oriansj>kmicu: thank you for the link
<kmicu>(personally I think that story is relevant to Guix cuz I already saw Guix individuals antagonizing reproducible folks from Debian or Nix)
<mwette>nckx: thanks for the link. I was not trying to be sarchastic. I understand that this is not a priority (nor should it be). And since you are intersted, I will keep posting discovered issues and fixes. (I did report one item to bugs-guix.)
<oriansj>kmicu: then we have the right to say "provide solutions first"
<apteryx>sneek: tell civodul thanks for the pointers
<sneek>civodul, apteryx says: thanks for the pointers
*bandali chuckles
<bandali>apteryx, you forgot the “later”
<oriansj>since at the end of the day, developers need to be willing to accept help from others but sometimes, the right thing is to say no to changes that are the wrong thing to do; fork and merge
<apteryx>sneek: later tell civodul thanks for the pointers w.r.t. CPATH and Inkscape compilation warnings.
<sneek>Got it.
<apteryx>sneek: botsnack
<kmicu>I had ‘’ in hosts file for many years so I could be part of the problem. I’m also curious what’s baking in Guix Telegram channel.
<nckx>sneek: later, botsnack
<nckx>Not so pedantic now are we.
<oriansj>Sometimes the creator of a thing, doesn't know the right next step. (see many Gnu projects as an example) but it only works when a new developer forks, does alot of the work needed and the community merges around them instead.
<nckx>kmicu: I learnt of the Telegram channel y'day. How does one join?
<ngz>What is the recent Guix command to test if a package is reproducible, and display a diff about it? I cannot remember.
<leoprikler>guix build --check, if memory serves.
<ngz>This one doesn't provide a diff (with diffoscope)
<leoprikler>not a full diff, though, you'll need diffoscope for that
<leoprikler>IIRC guix prints the two conflicting directories, you can diffoscope them afterwards
<leoprikler>I'm not sure whether guix has diffoscope built-in.
<ngz>It has, with guix challenge --diff=diffoscope
<ngz>diffoscope is not built-in, of course.
<leoprikler>you learn something new everyday
<tatsumaru>hey guys
<tatsumaru>read on Hyperbola's news section that they feel the Linux kernel is rapidly proceeding down an unstable path. Reasons include Linux kernel forcing adaption of DRM, including HDCP. Linux kernel proposed usage of Rust (which contains freedom flaws and a centralized code repository that is more prone to cyber attack and generally requires internet access to use.) Linux kernel being written without security in mind. (KSPP is basically a dead p
<tatsumaru>roject and Grsec is no longer free software) Many GNU userspace and core utils are all forcing adaption of features without build time options to disable them. E.g. (PulseAudio / SystemD / Rust / Java as forced dependencies). etc. I was wondering what the Guix position on this was?
<mwette>enabled substitutes, trying "guix pull" again