<simonsouth>vagrantc: Thanks for the response to my email. I'm building a new disk image now, we'll see how it goes...
<dissoc2>im trying to run guix system on a desktop with nvidia video card. when i get to GDM it displays but it doesnt really respond/update properly. for example if I type in password it wont show. if i click the gear the drop down doesnt show properly. any ideas?
<dissoc2>I'm able to login to gnome. and it also doesnt display properly. the mouse clicks dont correspond to the location of the mouse. similar refresh issues
<vagrantc>simonsouth: i've also got a rock64, so i'll be curious how it goes for you!
<alextee[m]>anyone has steps somewhere to install guix on hetzner?
<lfam>alextee[m]: Shepherd can be used on any system but the services that come predefined on Guix System only work on Guix System
<noobly>hello, how might i verify that a c++ program I'm trying to compile has access to the freeglut library I just installed? I imagine this is some sort of profile variable that I haven't set properly?
<Blackbeard>noobly: try running the script from the same terminal where you installed freeglut
<noobly>Blackbeard: boilerplate.cpp:15:10: fatal error: GL/freeglut.h: No such file or directory. im not sure if this has to do with me not knowing guix or not knowing freeglut, but i believe -lfreeglut is the appropriate flag for compiling
<noobly> iyzsong: it's working completely now, thanks a bunch! I wasn't sure if freeglut was a drop in replacement for glut but it seems it is, all compiler flags are identical which, while confusing at first, is super handy
<dissoc2>i'll give SLiM a shot first. i think my issues may be from the nvidia video card.
<raghavgururajan>dissoc2: BTW, what do you mean by gdm not working? Does gdm start and show you the login screen?
<dissoc2>i went from gentoo with nvidia proprietary drivers and now trying to get nouveau working. maybe i need xorg.conf?
<dissoc2>well i can see like 10% of what i think the gdm screen will look like. everything is off screen. I try to login (but i cant actually see it). and it seems like it starts to login but fails and goes back to login screen
<jsoo>Oh ok. I don’t really publish it on purpose. Mostly I just want to share dotfiles with ny friends and it’s easier to just share it
<raghavgururajan>jsoo I meant inside git repo. After `git clone`, only master is checked out. If I do `git checkout -B core-updates --track origin/core-updates`, do I have to `./bootstrap`, ./`configure` and `make` again? Even though I did them for master.
<jsoo>raghavgururajan: nope! Like I said, I’ve only ever had to do configure or bootstrap after a guix gc
<nckx>My 2.7M kernel supports crazy stuff like networking or it would be even smaller. Because I wanted it to double as a tiny rescue environment. But I don't expect others to know their way around. There's not enough space for that.
<damo22>so yeah, but integrate it into a coreboot payload that optionally boots into a rescue mode
<nckx>I don't see where trusting megabytes of Linux kernel on a ROM chip come in. If you're the kind of person who's rebuilding GCC from scratch, why would you be OK with cutting a huge corner. Why not actually bootstrap from Mes as intended?
<damo22>i dont know how mes works but maybe it could drive an output that saves to a disk or something
<nckx>I still don't actually know what we're discussing 😛
<jsoo>I was thinking recently about system sizes and I had a bit of an idea. Functional package management as laid out in eelco dolstra’s thesis is kind of a misnomer. It’s more like memory management for your filesystem. So what if we could use some of the newer ideas in memory management and apply them here? Namely systems like rust that have the
<jsoo>notion of a lifetime or affine type systems or quantitative types which allow you to express the number of references to some item and thus can tell when it can be safely deallocated. If there were some quantitive information about references on each package or artifact, then some items might be deallocated immediately. So for instance, if make is
<jsoo>just a build time input to some other package, it might have some information to track that and not need to be kept in the store. What am I missing there?
<jsoo>Whoa that was large. Sorry for the wall of text
<nckx>jsoo: Why would make be kept in the store now?
<jsoo>It is currently in the closure of the package (declared as an input)
<nckx>Nothing to do with ‘dependencies’ (in the colloquial non-Guix package manager sense of ‘stuff that stays installed because I have foo installed’) or closures. 🙂
<nckx>Applying new lessons in memory management to the functional package model or whatever you want to call it is definitely a great idea, but the parallels between what Nix/Guix do and heap management are quite well known. Explicit, even. Even in Nix AFAIK.
<jsoo>Yeah for sure. I like that a lot. I think having that idea of heap management as a fundamental concept when working with guix/nix makes the whole process make a lot more sense
<nckx>jsoo: I'm not a CS person. What kind of coolness would counting references (beyond the ‘some/none’ we already do) bring?
<jsoo>well the things that rust gets out of it is that the language user doesn’t have to manage memory, yet there is no garbage collector
<nckx>jsoo: Yeah, and there are probably undiscovered ways of extending that metaphor. It's just already there in the code & many names for things.
<nckx>jsoo: But ‘the compiler’ (Guix) can't know you're debugging Gnome this week and are going to be very cross if you suddenly have to rebuild stuff you already built because it was'n referenced (we already know that build inputs aren't referenced — we don't have manual ‘guix gc’ because it's hard to automate, but because only the user has the information to do so).
<jsoo>I think we would maybe not do counting but maybe do something closer to what the counting compiles to.
<nckx>jsoo: I'd love to hear more about those effects.
<jsoo>Hmm. I think we could get smaller system footprints. But on the flip side maybe we would lose some richness of information about a system that would be available for inspection when the user is working in the environment
<nckx>Source doesn't have to remain cached on the system as long as the binary is, though.
<jsoo>Hmm. I thought I saw a thread in the mailing list from long ago about that. I might be misremembering though
<krusnus>Hey everyone! For some reason when i run "which guix" it returns "/run/current-system/profile/bin/guix" and not "~/.config/guix/current/bin/guix". It's messing everything up. How do i set it to the correct one permanently?
<jsoo>krusnus: have you installed guix in your profile?
<ATuin>after upgrading my stumpwm takes like 1-2 mins to initialize
<ATuin>after debugging the problem seems to be with ASDF (the problem happens when running asdf:load-system :module
<krusnus>jsoo: what does that mean? i'm running guixSD and i actaully have no idea of how i got in this mess
<ATuin>asdf loads itself and that takes a lot of time
<nckx>jsoo: So the way Guix currently manages dependencies is scanning for references: if /gnu/store/…gcc/ contains the string /gnu/store/…glibc anwyhere, glibc is a dependency of gcc. Otherwise it's not, and (if GCC is the only ‘live’ package on your imaginary 2-package system 🙂) glibc will be deleted. That's… pretty binary, and minimal assuming there are no bogus references [and if there are, I don't see how you can safely tell]. How are
<ATuin>jsoo: i will keep debuging this cl problem then
<jsoo>nckx: aha. Right. Which is close to standardish garbage collection I think. The change would be to mark in the package definition when it would be ok for a package to be removed.
<nckx>alextee[m]: Even then, it's much easier/safer/pleasant to install from a ‘rescue’ system if they offer that. Even if it's not Guix. Boot the rescue system, run the binary installation script to ‘install’ Guix to RAM, then run ‘guix system init …’ on the separate drive. You'll have so much more hair left at the end.
<jsoo>The current heap management is like java whereas if we give more information up front about runtime liveness that would be closer to rust
<krusnus>jsoo: I'll give some more context. I'm new to guix so I'm 90% sure I'm wrong about this, but I think I've somehow messed with an env file after accidentally selecting it when choosing a wm for lxqt. anyway, now everything is messed up. None of the user installed programms work and most guix commands return "error: unsupportet manifest format"
<jsoo>krusnus: ah I see. That is the problem. So probably don’t install guix in your profile as nckx says.
<nckx>My problem is that I know a great deal about Guix (but not everything!), a bit about Lispy memz, and absolutely nothing about Java or Rust or …. So ‘like Java’ means nothing to me, as frustrating as that is for the conversation.
<ATuin>interesting "DISPLAY=:1 $(readlink /home/atuin/.guix-profile/bin/stumpwm)" makes stumpw to fail, while "DISPLAY=:1 /home/atuin/.guix-profile/bin/stumpwm" seems to work fine :D
<jsoo>meaning a separate process must stop the world and scan for live objects
<nckx>Oh wait. We're discussing the implementation of the GC and not the reference model? That's a huge difference. Nix GC isn't quite stop-the-world but can be made even less so without having to change the model. I think.
<nckx>Thing is that for Guix/Nix's definition of ‘run-time liveness’, the GC already has 100% accurate information at any time.
<jsoo>nckx: ah now I’m probably getting out of my depth since I’m no compiler writer. I think maybe you are right if the retained pointers to store paths can always be scanned correctly
<jsoo>The bigger win would be that I think if the runtime references were declared earlier then certain packages might never have to go in the store at all and the gc might never have to happen
<jsoo>That’s why I was thinking it would help reduce, say, vm image sizes
<krusnus>thats the thing, i dont really know. And I'm probably wrong about the cause, but I was checking out lxqt and after i started x it prompted me to choose window manager, and the only file in the promt (which whas a filemanagery kind of prompt) was a file called "env", I didnt even look at the icon, assuming it was some sort of folder, and double clic
<krusnus>ked it lxqt went black, i couldnt exit and i rebooted the system. and everything's basically been fucked since. I think i've messed things up even more by trying to reset my user and stuff so i have no idea what to even do
<jsoo>Ah man sorry krusnus I gotta go. It’s night here. Thanks for the discussion nckx!
<nckx>jsoo: Just so we're clear: you realise that if I add ‘wine’ as an input, and ‘qtwebkit’ as a native input, to ‘hello’, this will not in any way affect the size of the resulting hello package, its closure, or the final system/vm image/… containing it, right?
<nckx>If so, you make me extremely curious 😉 Bye! o/
<krusnus>I just reinstalled guix and everything was working fine untill i rebooted and now none of my manually installed programms work and guix install [anything] returns "guix install: error: unsupported manifest format"
<mekeor>PotentialUser-73: i don't celebrate easter, i don't believe in christianity, i pay homage to St. Ignucius only
<PotentialUser-73>tomorrow it'll be released the new version of guix, if I want it an a pre installed version can I just run: guix pull && guix upgrade and it is the same thing?
<mekeor>PotentialUser-73: sorry, i was just trying to make a joke :)
<xelxebar>usney: Thanks for the links. They're not directly relevant, unfortunately. However, I did find an open issue on the tracker that seems relevant, but the server is returning 500 when I try to open the link.
<xelxebar>Yeah, the errors happen when building the german info file, it looks like, but I don't have any german locales set. Don't speak much German, I'm afraid to say.
<mroh>xelxebar: try `make SUBDIRS=` as a workaround.
<rekado>xelxebar: if “the server” that is “returning 500” is issues.guix.gnu.org: that’s because it cannot currently update (since a few days) because I’m waiting for a response from the maintainers of debbugs.gnu.org.
<ATuin>is there any option to keep the source build even for successful builds?
<ngz>ATuin: I don't think so, but you can insert an error in one of the phases to at a given point.
<ATuin>btw seems that lot of packages build using asdf-build-system complain about the version scheme not being asdf compatible
<xavierm02>I tried 3 random commits (a few months ago, six months ago and a year ago if I remember correctly) and couldn't get xen to compile in any of them. The two recent ones had the same error, and for the older commit make failed before for some seemingly unrelated reason
<xavierm02>Is there really no way to get a commit where xen works?
<pinoaffe1>I want to be able to compile for an esp32 on guix, (I think I would need a crosscompiling gcc toolchain targeting xtensa), anyone got pointers / has anyone played with this before?
<xavierm02>I've looked a bit into why the xen build fails. And it seems to be because (getenv "C_INCLUDE_PATH") and (getenv "CPLUS_INCLUDE_PATH") return #f, and some procedure later on really wanted those values to be strings
***ChanServ sets mode: +o civodul
***civodul changes topic to 'GNU Guix | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | Test: https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00224.html'
<kraai>I'm trying to package diceware. When I run guix lint, it says "source not archived on Software Heritage". What do I do about that?
<guix-vits>nly and folks: First of all, i'm sorry i'd claimed that tor-service-type doesn't working properly. It's my crappy 'firehole' was misconfigured.
<xavierm02>Is it possible to write a package in current guix that has as input a package from a past commit?
<pkill9>xavierm02: I think it could be possible with an inferior package
<pkill9>then again, probably not, because accessing the package metadata requires functions just fo rinferior packages, so the build systems and whatnot probably will give an error if they try to use the normal functions to access the package metadata
<xavierm02>(I tried fixing xen, but making filter-environment! work when (getenv "C_INCLUDE_PATH") if #f brings a new problem: It can't find Python.h. And I tried adding (assoc-ref inputs "python") "/include/python2.7/" to the C_INCLUDE_PATH but it still doesn't find it so I give up)
<anadon>Continuing from last night, I can't figure out where a few errors are in my modifications to update packages and the behavior and stack traces just haven't related to any actual problem. Here's where I'm at: https://imgur.com/a/N9jci7u
<bavier`>anadon: It looks like you don't have guile-gcrypt in your build environment
<bavier`>and maybe also don't have the guix-daemon started
<homocarbonis>Does anyone know how I can refer to a file in a package in the store from my system definition?
<homocarbonis>I am trying to set up nginx and I want to refer to put "include /gnu/store/*-nginx-*/share/nginx/conf/fast_cgiparams"
<bricewge>homocarbonis: “file-append” from (guix gexp) I think
<anadon>bavier`: If it was missing from my build environment then it should fail to build in the first place. That isn't happening.
<anadon>From my understanding, in order to use the new packages the daemon has to have those packages and thus the new daemon must be running in place of the old one.
<homocarbonis>That looks right, thank you. I should have read the manual again.
<anadon>bavier`: A guix daemon has to be started for anything to work. As you can see in the image, the old one was stopped and the new one was run.
<mbakke>anadon: did you configure with "--localstatedir=/var --sysconfdir=/etc" ?
<mbakke>anadon: unless you are testing changes to guix-daemon itself, you don't have to run it from the checkout
<reepca>do we have any tools packaged that can let me play through multiple sets of headphones at once via pulseaudio?
<pkill9>does anyone know how to use pulseaudio with jack on guix system?
<xavierm02>I'm trying to make creating packages faster by caching some phases (so that when you are working on the install phase, you can test it without recompiling everything). I was trying to do so by splitting a package into several packages, one per phase, and having each package have the previous one as input and performing a single phase. But I'm starting to wonder whether this is how it should be done, the alternative being
<xavierm02>editing the script behind guix build. What do you think?
<vagrantc>i still haven't decided what to do regarding the "(allows|permits) to" grammar with "(allows|permits) one to" ... as neither sound right to my ear
<anadon>When building my django modifications, there's a failure in the django tests but the test file doesn't exist in the django repo. The file does exist under the django directory in guix. Could this be a misdirection and the failure is actually in another package, django doing something non-obvious, guix, doing something non-obvious, or something else I haven't thought of?
<anadon>I'm running it again for something clean to post.
<efraim>I personally try hard not to know. Sometimes it's developer interest, sometimes its drama, sometimes its lots of drama, mostly it's interesting to me as another option to make work
<efraim>talking to other people at FOSDEM recently, I mentioned "I don't like saying Linux is 'just a kernel', but there's a bunch of options out there and there's no reason to not support more of them"
<anadon>Steering back towards my question, I'm having a tough time making sense to the build failure.