<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?
<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, Oh wow. That's an actual guix mirror. I was thinking something more simpler like this: https://github.com/peanutbutterandcrackers/guix-packages 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, 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
<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'?
<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
<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 email@example.com. 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
<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>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.
<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>(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
<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>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
<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?
<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
<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 :/
<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
<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, 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
<peanutbutterandc>oriansj, This m2 project. This seems so super cool. All it needs is something like this: (http://landoflisp.com/) the comic from the lower part of the pages to explain things to not-wizards-yet people like myself
<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
<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)
<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)
<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 😛
<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: https://pastebin.com/x5mVBwqy 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
<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?
<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?
<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.
<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 between....in particular dropping out the modal mode with spacebar works nicely.
<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>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
<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$"))
<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.
<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.
<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
<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
<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.
<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