IRC channel logs


back to list of logs

<pkill9>why was GuixSD renamed to Guix System?
<nckx>pkill9: Clarity & aesthetics.
<rekado_>pkill9: the name “GuixSD” was always an uneasy compromise. It also emphasized a difference between different uses of Guix that we found to complicate things more than it helped.
<rekado_>When it became obvious that the use of Guix for building VMs and container images is really not all that different from using Guix as a system on real hardware, adopting the new name was an almost obvious next step.
<rekado_>“Guix System” is what the “guix system” command produces – no matter if that’s a VM, a container image, or a “bare metal” operating system installation.
<rekado_>the similarities are more important than the differences
<ItsMarlin>hi guix
<ItsMarlin>is there a way i can use a scm file to set the packages to be installed, but per user instead of systemwide?
<str1ngs>ItsMarlin: yes, you can use -m flag with package
<nckx>ItsMarlin: Have you heard of manifests?
<str1ngs>ItsMarlin: see --manifest section of
<ItsMarlin>thanks :))
<ItsMarlin>writing everything down in a file is way better for keeping track
*rekado_ –> zzZ
<ItsMarlin>tomorrow i'll be backing up my dotfiles with git and gnu Stow
<krafter>Ok, I am trying to run a copy of my current config as a VM, but I don't think that qemu can find the hard disk when it boots.
<abarbosa>Paren Env: GuixSD + Emacs + Next + Stumpwm + CL
<krafter>Hello good sir.
<krafter>abarbosa: You seem to have found a interesting setup.
<abarbosa>krafter: haha...
<abarbosa>krafter: now, a JS replacement
<krafter>In your dreams.
<abarbosa>krafter: haha
<krafter>Or a parallell universe.
<abarbosa>well, JS is full of functional features nowadays :D
<krafter>But its not lisp.
<krafter>How do you find next and stumpwm working out for you?
<abarbosa>krafter: Elm - PureScript - ClojureScript :DDD
<krafter>There must be a CL -> javascript compiler.
<abarbosa>krafter: indeed.
<abarbosa>krafter: my StumpWM set up is minimal, for now. Next lacks a download manager and sandbox
<krafter>abarbosa: Sounds like I should give those two a few more years in the oven.
<abarbosa>krafter: stumpwm, if you know your way with CL anything is possible. As for Next, its already pretty usable, my default browser! hehe
<krafter>I have found the greater concern is to figure out what I actually want. I am content with i3's default so I have no reason to switch.
<abarbosa>krafter: and dont need to, unless you "want" that bad to modify you WM entire behavior, StumpWM wont offer more than i3/Awesome do.
<abarbosa>krafter: Same goes for Next, Emacs...
<krafter>abarbosa: What all of the things you mentioned have in common is that they are all made to be configured.
<abarbosa>krafter: eg: I have a few functions on Next that every time a video is load it opens with mpv, instead.
<abarbosa>kinda handy
<abarbosa>krafter: indeed. A ricers dream! :D
<abarbosa>krafter: that early vision that software is what its dev made, are totally destroyed by those tools :D
<krafter>True that.
<krafter>abarbosa: Do you virtualization?
<abarbosa>krafter: nope. native:D
<abarbosa>krafter: do you work using LISP? its my dream...
<abarbosa>well, I have a lot of CL mini-tools to deploy my website hehe
<krafter>I was a intern as a clojure dev.
<abarbosa>krafter: ohh, clojure... still have to learn it.
<krafter>I am planning of figuring out and setting up virtualization so that I don't have to reinstall the entire computer.
<krafter>abarbosa: Do you know Java at all?
<abarbosa>krafter: Ihave work with Java for a few years in my uni years...
<abarbosa>krafter: not that long ago actually, they just released Java 9
<krafter>Ok, because Clojure is in its entirety built upon Java. It makes Java quite pleasant to use.
<abarbosa>krafter: I usually move my my important files to a isolated drive/partition so I can install afresh any OS, yet not losing anything..
<krafter>You do lose the setup you have done so far if any.
<krafter>I had to reinstall recently due to a error on my part.
<abarbosa>krafter: scripts ftw. As most Distro shares almost the same configuration, no need to redo everything at hand... just let computer do it all!
<abarbosa>it took me half a hour to get GuixSD ready... :D
<krafter>abarbosa: Did the installer work for you?
<abarbosa>krafter: I did my installer hehe
<jak3b>I just get a black screen after grub
<abarbosa>jak3b: how did you install GuixSD?
<abarbosa>jak3b: spec....
<jak3b>havent installed it yet
<jak3b>that was the .iso
<jak3b>I boot the USB it shows the splash screen, boot prompt
<abarbosa>jak3b: I dont think GuixSD has a live iso
<jak3b>the install iso
<jak3b>not live
<jak3b>the graphic installer on tty1
<abarbosa>jak3b: oh my bad, you spec has any AMD/Nvidia GPU? might be it
<jak3b>I have an athlon with a radeon 6950
<jak3b>I thought that might be it
<jak3b>Ill try the manual install
<jak3b>it runs fine in a vm
<jak3b>the screen doesnt go into stand bye
<jak3b>its stays on, just dark
<jak3b>I switch to tty3 and can see the prompts
<krafter>In the installation medium, tty1 is graphical installer, tty2 is manual and the rest are normal.
<abarbosa>jak3b: well, you can always go the hard way :D
<jak3b>yep lol
<abarbosa>I still go with manual installation...
<jak3b>looks pretty straight forward
<abarbosa>jak3b: just like ol' gentoo
<jak3b>Ill right Ill give it a whirl
<krafter>abarbosa: Sounds like you have been around for a while.
<abarbosa>krafter: proud distro hopper and ricer. lol
<krafter>abarbosa: That explains why it only took 30 min to install.
<abarbosa>krafter: it look a few minutes actually. 30 min to set up envs, cli apps... all that boring configurations
<hwt[m]>Hi I am curious what area guix shines the most? Bare-metal servers, VPS, workstations/desktops, laptops, containers?
<krafter>hwt[m]: Uh, I think of it as a general purpose distro.
<krafter>hwt[m]: Judging from articles I have read it can be used pretty much for everything.
<vagrantc>so, symlinks aren't working out too well ... lrwxrwxrwx 2 root root 9 Dec 31 1969 /gnu/store/zn0862lzl2mr8zwwbhdhv7jgdpm3w9gk-bash -> /bin/bash
<vagrantc>which doesn't pull the system's /bin/bash into the build environment
<vagrantc>maybe that's why none of the substitutes are considered valid
<vagrantc>that was with "guix build hello --no-build-hook" ... without that still getting the issues where it can't find offload
<matt`>I'm considering switching to using Guix as my main distro and am trying to wrap my head around how I might deal with system configurations that aren't supported without patching guix itself. Is there a way to tell the system configuration to write an arbitrary file? For instance, let's say I needed a certain fstab file. When writing config.scm can I specify just arbitrary text that should go in /etc/fstab and have guix system do that
<matt`>for me?
<matt`>similarly, is there an easy way to see how certain system configurations lead to the resulting changes in /etc files or other configuration files?
***MinceR_ is now known as MinceR
<reepca`>hm, despite the shepherd manual stating that list-actions has a default implementation for any service, doing, for example, "sudo herd list-actions udev" just gives "herd: service 'udev' does not have an action 'list-actions'"
<reepca`>looking through the code I've noticed that "sudo herd doc udev list-actions" does the desired job
<mouldysammich>hey all, how come gnome is still at 3.28? are there problems with newer versions?
<civodul>Hello Guix!
<rekado>mouldysammich: the upgrade affects more packages and requires more testing.
<rekado>mouldysammich: since quite a few months we have a separate branch for 3.30.
<rekado>it’ll be merged into core-updates, I guess.
<mouldysammich>rekado: ah cool, thanks
*civodul roptat salut !
<dutchie>how can I work out the right hash for a texlive package, using a (texlive-ref) uri?
<dutchie>(or i guess anything which i can't just `guix download`)
<civodul>dutchie: 'guix download' prints the hash of what it just downloaded
<civodul>alternately, you can run 'guix hash' on the file or directory you're interested in
<dutchie>oh, I didn't know about guix hash
<civodul> has links to all the tools you may need as you write a package definition
<vagrantc>where is "guix offload" defined?
<dutchie>can i give guix download an svn uri somehow?
<Marlin1113>hi guix
<rekado>vagrantc: guix/scripts/offload.scm?
<vagrantc>rekado: there's also nix/scripts/
<rekado>the stuff under guix/scripts is the entry point for all commands.
<rekado>nix/scripts/offload only spawns “guix offload”
<vagrantc>should it have a corresponding offload.go file?
<rekado>yes, all source files that are compiled (including those under guix/scripts) will have a go file.
<vagrantc>this seems to be the main blocker on the debian packaging at this point...
<rekado>if you don’t have one maybe guile-ssh wasn’t found at configure time?
<rekado>FWIW you can bypass the use of the offload hook with “--no-build-hook”
<vagrantc>yeah, my builds fail with --no-build-hook too
<vagrantc>but differently, at least! :)
<vagrantc>"guix build hello" seems to download a bunch of .tar.* to the store ... guix download seems to work ... but offload is just plain confused.
<rekado>have you shared some of the output on help-guix yet?
<rekado>(I’m way behind on emails…)
<vagrantc>no, was almost to that point
<rekado>I think it’s a good idea to do that.
<civodul>vagrantc: what errors do you get related to 'guix offload'?
<civodul>could you paste them?
<reepca`>civodul: I noticed that "sudo herd list-actions <some-service>" doesn't work (the manual mentions it as an action implemented by Shepherd itself), but "sudo herd doc <some-service> list-actions" does (gleaned from the sources). Is that a bug?
***Forza_ is now known as Forza
<rekado>reepca`: this doesn’t seem right. “herd doc” isn’t even mentioned in the manual. It’s probably a bug.
<rekado>vagrantc: what are the values of GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH?
<reepca`>hm, just double-checked the grep buffer, found a match in the NEWS file under -0.6: ** `list-actions' is a sub-action of `doc' now. Seems the manual is outdated.
<rekado>reepca`: a different kind of bug then :)
<civodul>yup, something needs to be fixed anyway :-)
<vagrantc>rekado: no GUILE_* environment variables in the user's environment, or do you mean something else?
<civodul>vagrantc: can you run "guix repl", and from there try: ,use (guix scripts offload)
<civodul>that should give you a neat backtrace
<civodul>or at least an error message, actually
<vagrantc>While executing meta-command:
<vagrantc>In procedure dynamic-link: file: "/usr/lib/x86_64-linux-gnu/libsqlite3", message: "file not found"
<vagrantc>well, that's something
<civodul>vagrantc: oh, that might be a problem: the pattern for Guile bindings is to try to dlopen the ".so" file, not the ".so.A.B.C" file
<civodul>in Debian terms, it means you need to have the -dev package around
<civodul>the correct fix may be to patch those guile-* packages to refer to the exact .so.A.B.C file
<jonsger>hopefully Debian is not so strict about that
<civodul>but really, that's something we should fix on our side
<jonsger>I would appreciate that, devel packages as runtime dependency is not so nice...
<vagrantc>civodul: installing libsqlite3-dev seems to be working now...
<vagrantc>still not pulling binary substitutes ... only source tarballs and patches
<rekado>vagrantc: did you replace the bootstrap binaries?
<jonsger>vagrantc: did you run "guix archive"?
<vagrantc>jonsger: yes.
<vagrantc>rekado: yeah, the bootstrap binaries are symlinks to the host binaries ... it seems to then create the symlink in /gnu/store/...-bash etc.
<vagrantc>which i don't imagine will work well
*vagrantc wonders how many other -dev packages might be needed
<civodul>vagrantc: if you use different bootstrap binaries, then all the derivations are going to be different from "ours"
<civodul>and thus you'll end up building everything from source :-/
<vagrantc>this doesn't seem to be plausible to workaround :/
<vagrantc>debian's not going to ship binaries not built from source, and we need the same binaries
<rekado>when building Guix from source you don’t need the bootstrap binaries, do you?
<vagrantc>rekado: it wants to install them, but then the installed system definitely needs them
<vagrantc>it doesn't work to just remove them from the package
<rekado>right, but the Guix package on Debian would not need to include them.
<vagrantc>then it fails much earlier
<rekado>…if Guix were to download them at runtime into /gnu/store.
<vagrantc>yeah, that
<vagrantc>if only we could bootstrap the bootstrap binaries! :)
<vagrantc>guix download works ...
<vagrantc>how would guix know the hashes of the binaries? could i download them with guix download (or something similar) ?
<rekado>the hashes are recorded in gnu/packages/bootstrap.scm IIRC
<jonsger>vagrantc: guile-gcrypt needs libgrypt-devel, guile-git needs libgit2-devel, guile-newt needs newt-devel, guile-parted needs parted-devel, guile-sqlite needs sqlite3-devel. The packages are named slightly different on debian...
<rekado>eg. in bootstrap-guile-hash
<rekado>or %bootstrap-coreutils&co
<vagrantc>jonsger: basically all of them :)
<jonsger>remove -el and most of the names are correct :P
<civodul>jonsger: guile-{parted,newt} are not needed when packaging Guix
<jonsger>civodul: yes, they are kind of optional
<rekado>in the past we downloaded the bootstrap binaries on demand, didn’t we?
<rekado>can this still be done for Guix on Debian?
<civodul>rekado, vagrantc: in gnu/packages/bootstrap.scm, occurrences of 'search-bootstrap-binary' shows the bootstrap binaries that need to be provided by the package
<civodul>statically-linked versions of "tar", "xz", etc.
<civodul>with a bit of imagination, we could get rid of them
<civodul>that doesn't solve the short-term issue, though
<efraim>I think in the past they got moved from downloaded during configure to downloaded at the end of make
<vagrantc>yeah, i've been symlinking those to the host system, but that hasn't worked out so well
<rekado>apteryx: sorry, still haven’t been able to review your pypi importer patches. I’ll try to work on them tonight or tomorrow.
<rekado>slow laptop with little RAM makes everything a little slower — can’t do as many things at the same time as I used to.
<apteryx>rekado: no problem, there's no rush!
<Luke|Skywalker>should the mail server create a group 'mail'? I`m now trying to configure imap4d (from mailutils) without a config. In the guix manuals it says it will operate on port 143 if done so
<rekado>apteryx: could you tell me why you’re no longer considering the requirements.txt file? (First patch.)
<Luke|Skywalker>the mailog indicate the imapd couldnt found group mail, and shephard always fail to start it
<rekado>apteryx: I guess it’s no longer popular to include a requirements.txt?
<rekado>Luke|Skywalker: it’s possible that the service ought to extend the user accounts service to create that group.
<Luke|Skywalker>after the reconfigure, theres no such group in /etc/group
<rekado>Luke|Skywalker: have you created it? How?
<Luke|Skywalker>but even if i create one, the imap4d doesnt seem to work
<rekado>same or different error?
<Luke|Skywalker>the log says its up (if i ran it manually)
<Luke|Skywalker>but no port open, although the process is there in ps
<apteryx>rekado: modern and correct way to include dependency is to list them in the
<apteryx>requirements.txt was always an ad-hoc thing that could be used for developers, e.g. 'pip install -rrequirements.txt'
<apteryx>if the package is on PyPI, the required dependency *must* be listed in
<apteryx>requirements.txt is not considered when building packages with 'python build/install'
<civodul>bonjour PirBoazo
<PirBoazo>Bonjour civodul
<PirBoazo>@civodul où trouver les choix fait dans l'installation de certains packages?
<PirBoazo>@civodul par exemple pour le package postgresql
<civodul>PirBoazo: pour voir les options de configuration, si c'est ça dont tu parles, tu peux faire « guix edit postgresql »
<PirBoazo>Merci :-)
<krafter>So if I create a image with guix system vm-image, how do I run it? When I try to start it it can't find the hard drive.
<civodul>krafter: did you try the QEMU command given in ?
<krafter>civodul: Yes, the VM itself start fine, but it can't find the hard drive. I use the command in the link you sent me as a template, replacing the file part with the image created by guix system vm-image.
<civodul>so the initrd fails to find the root file system?
<Luke|Skywalker>anyone tryed to use imap4d from mailutils?
<Luke|Skywalker>something is wrong
<krafter>civodul: I guess.
<mbakke>krafter: Try giving the virtual machine more memory, e.g. with "-m 512m".
<nckx>Does ‘guix system vm /etc/my-bare-metal-system.scm’ ignore file-systems? Or does it try to mount them & presumably fail?
<krafter>mbakke: no go.
<krafter>nckx: vm command works just fine, but its not a complete VM.
<Luke|Skywalker>unsupported callback property 18
<g_bor[m]><krafter "mbakke: no go."> krafter: you could peek into the script file, and check what it is trying to do.
<dongcarl>Hey all... can't switch to core-updates at the moment as the tests for guile is failing...
<dongcarl>Specifically `FAIL: test-out-of-memory`
<dongcarl>Has anyone else encountered this problem?
<dongcarl>Perhaps there's a version of core-updates that's loaded into the substitute servers that I can download
<kkebreau>I tried to install the Guix System on my Asus C201 and the root partition is invisible...
<vagrantc>hrm. even with same bootstrap binaries, i'm still getting no substitutes
<rekado>vagrantc: does /etc/guix/acl exist?
<vagrantc>rekado: with keys imported for hydra and
<vagrantc>cat /usr/share/guix/ | sudo guix archive --authorize ... ditto for
<vagrantc>i've come so far!
*vagrantc sighs
<vagrantc>maybe i'll just put it on the back burner for a while, given that to really get it into Debian requires waiting on a few other things anyways
<chipb>vagrantc: are you packaging guix for debian?
<rekado>are the timestamps on the bootstrap binaries unchanged?
<vagrantc>chipb: yeah
<vagrantc>do these look right: /gnu/store/04pl6dnxf54m0l5j5ibib3mkj66809ad-xz /gnu/store/qn7ycbybh0gp7rmnnmdy1473j4vkkdix-tar
<vagrantc>/gnu/store/n4kp6zcmvlds6b7ax6q0gfbi5wf5jhml-mkdir /gnu/store/rvk2p932iz9jwmsc3f1xdjqkl4h63qmc-bash
<rekado>I don’t have them.
<rekado>any of them
<vagrantc>well, that would explain it
<vagrantc>the timestamps for the /usr/share/.../x86_64-linux/bash is from today ... so, that's quite plausibly the issue
<vagrantc>though in the store it's the usual epoch=1
<rekado>vagrantc: maybe that doesn’t matter all that much
<vagrantc>i know one way to find out empirically...
<rekado>what are your shasums of the files in gnu/packages/bootstrap/
<rekado>aa34ebaf13452a14c6a50b4785f01ab843c147d82c0c2cbe930ae88509dbd26562cad3bef3f9a343eae09f7f4eb7c708fe44f85cd957cd520da9aad42d6a889b gnu/packages/bootstrap/x86_64-linux/bash
<vagrantc>changed the timestamp and still produced the same store item
<vagrantc>maybe the path is embedded?
<vagrantc>rekado: ok, the packaging process maybe mangled it.
<vagrantc>rekado: doesn't match your checksum
<vagrantc>and the source one does match
*vagrantc tries monkeypatching it.
<jonsger>hm, partition and bootloader in config.scm is always trial and error for me :(
<chipb>vagrantc: huh. excellent. thank you!
<vagrantc>ding ding ding. bootstrap binaries that match result in working substitutes!
<vagrantc>now, how on earth to get the bootstrap binaries downloaded at runtime...
<chipb>might give me a more straightforward way of bootstrapping a non-/gnu/store-based installation.
<vagrantc>that's the idea
<chipb>though I guess I haven't done so in a while anyway.
<rekado>chipb: the debian packages won’t help with installing Guix with a different store directory.
<vagrantc>well, not any more than any other method
<chipb>well, it'll have all the builddeps easily packaged.
<vagrantc>yeah, that's the main blocker
<chipb>debootstrap -> install deps -> build guix itself -> transplant to host in target location.
<vagrantc>chipb: lists the blocking bugs, not including things like this bootstrap binary adventure
<vagrantc>i should probably send a status update to the bug and guix-devel
<krafter>What setups do you guys use? I am curious?
<isengaara-tomoko>I have a Vikings D16 server for bootstapping the powerpc port
<vagrantc>kkebreau: i've only installed on the asus c201/veyron-speedy with microsd ... haven't tried installing to the eMMC yeyt
<vagrantc>(with only 16GB of space ...)
<civodul>vagrantc: re automatic download, i toyed with the idea of a "builtin:download" derivation to fetch these 4 files, followed by another fixed-output derivation that would make them executable
<vagrantc>civodul: sounds like just what i need
<civodul>there's a detail that makes it not quite possible on master though: the fact "" in (gnu packages bootstrap) has references to these files
<vagrantc>it's almost like it's a bootstrapping problem
<civodul>i think it qualifies :-)
<civodul>we could fix that in core-updates
<civodul>(WIP patch:
<vagrantc>my mind is a bit twisty-windy with all this ... but even a tarball with a strong checksum might work ...
<civodul>now, we both understand that this is purely equivalent, right? :-)
<civodul>that is, the Debian package would not ship these files, but 'guix' would download them right away
<krafter>Linux drivers have come a long way.
<krafter>I have heard many say that linux drivers would be a pain in the ass. But I have used linux for ~3 years and never had any issues.
<krafter>Except with GPU performance when it comes to free drivers, but thats to be expected.
<vagrantc>civodul: and that can run without the bootstrap binaries themselves?
<civodul>vagrantc: yes, it would download these 4 files just like it downloads the ~500 MiB of bootstrap binaries
<civodul>(soon 250 MiB!)
<dongcarl>civodul: I'll disable that test. It's core-updates anyways
<vagrantc>i was also wondering if getting mes to a working state would be another alternative to download bootstrap binaries
<vagrantc>e.g. the hex only bootstrap ...
<vagrantc>i know it's a ways off
<civodul>kindof :-)
<civodul>it's never been done before
<civodul>even what's in core-updates today has never been done before
<dongcarl>vagrantc: Eh, that's a little slow, I feel like it's better to have something for debian first, then iterate
<civodul>yeah, back to the Debian packaging issue, these binaries can't be a blocker
<civodul>well i mean they might be a blocker policy-wise
<civodul>but if we reason about it, it shouldn't be an issue
<dongcarl>civodul: agree
*civodul has an idealistic & optimistic view of the problem :-)
<dongcarl>I think even if they are blockers...
<dongcarl>We can put things up in a PPA
<dongcarl>and at least that would be much better for debian/debian-derived folks
<dongcarl>vagrantc: Again... I'd be happy to help with anything :-)
<vagrantc>dongcarl: i've maybe almost got something worth testing! :)
*dongcarl jumps for joy
<vagrantc>although i haven't worked on the enable systemd and add users bits yet
<vagrantc>though that's pretty trivial
<dongcarl>I thought that after making riscv, windows 64-bit, and osx cross-compiles work for Guix, I'd also have to do the debian package...
<dongcarl>But apparently not!
<dongcarl>I think there will also be a small increase in number of developers once Guix is available in debian
<dongcarl>`guix environment guix` and then just hack away is the most beautiful onboarding experience ever
<vagrantc>i've found it a bit rougher than "most beautiful" but i'm still working on it :)
<dongcarl>"has the potential to be the most beautiful" then :)
<vagrantc>i've been meaning to write a follow-up post to the talk i gave at debconf about what as a debian developer i find useful in guix
<vagrantc>a lot of it is the two-liner package updates :)
<vagrantc>or only building a single package out of a source package that might be used to produce many different packages in debian
<dongcarl>Urgh wish I could go
<rekado>can someone here recommend a somewhat recent graphics card that is fast enough for OpenCL application development and recent OpenGL support?
<rekado>recent mailing list postings made me weary of trying this out by myself.
<rekado>from what I understand Nvidia and ATI are both terrible in their own ways.
<dongcarl>rekado: I think AMD cards are a little better since drivers are upstreamed and more open
<dongcarl>Does anyone know how to disable a test when building Guile?
<kmicu>(Drivers are almost always open, the issue is with firmware.)
*kmicu recommends reading and especially in this context searching for ‘amdgpu’ or ‘nvidia’.
<dongcarl>kmicu: Will read!
<dongcarl>kmicu: what does it say w/re amdgpu vs nvidia?
<kmicu> nVidia is always worse.
<kmicu>(And that’s not even harsh assessment but confirmed again and again by nVidia’s actions and free software devs trying to support nVidia’s cards )
<dongcarl>Hey all, wondering what you guys do when a package is distributed with a and a, and you need to patch something in Do you 1. Delete the, modify .am and regenerate?, or 2. Patch just, or 3. Patch both?
<dongcarl>(talking about Guile)
<kmicu>(Full disclosure: my second-hand laptop has an nVidia eGPU and I sometimes use it with Nouveau’s PRIME GPU offloading. Oh sweet irony.)
<dongcarl>kmicu: What distro?
<str1ngs>dongcarl: is usually generated by autotools. so you can patch then autoreconf
<dongcarl>str1ngs: Right, but if it's an easier change, wouldn't it be faster to just patch ``?
<dongcarl>in fact... looking at Guix's patches...
<dongcarl>More packages patch `` than ``
<str1ngs>I don't think so personally. technically yes that would work. but because is auto generated. it's subject to change. is created by hand.
<str1ngs>many ways to skin a cat though.
<str1ngs>I guess patching avoids calling autoreconf ?
<dongcarl>Yeah it avoids calling autoreconf
<dongcarl>Makes sense and thanks for context!
<str1ngs>that works, I see your line of thinking.
<rekado>kmicu: I never really considered an nvidia card because of how hostile they are, but I’m worried about how this amdgpu stuff could make it less likely that AMD cards can be used with free software alone.
<rekado>I got one old nvidia card from an institute workstation and it works fine, but it’s just as bad as the internal GPU on this ancient motherboard.
<kmicu>dongcarl: I used PRIME offloading on (liberated aka no firmware blobs) NixOS so I assume that should also work on Guix System (but not tested PRIME here yet).
<vagrantc>if a project isn't updating ... is it ok to switch to git tags to update the version? the git tags are also signed with a trust path as an added benifit, unlike packages... but looses guix refresh-ability
<rekado>vagrantc: yes, that’s fine.
<civodul>i think we should make 'guix refresh' work with Git checkouts, too
<civodul>before it becomes irrelevant
<kmicu>rekado: nVidia has that thing with ‘Use our signed firmware images to unlock performance’ otherwise they have perfomance close to Intel’s integrated GPUs. I recommend asking Mesa folks about libre OpenCL cards. Maybe Panfrost driver and Mali GPUs could be good for OpenCL today 🤷
<vagrantc>eats up a lot more disk space, obviously.
<vagrantc>but guix has never really been too afraid of that :)
<kmicu>(There is also this thing (relevant in Guix HPC and datacenters))
<vagrantc>civodul: your patch failed on 1.0.1 ... ERROR: In procedure string->utf8:
<vagrantc>In procedure string->utf8: Wrong type argument in position 1 (expecting string): #<derivation /gnu/store/v75qmh
<vagrantc>civodul: for more backtrace
<Marlin1113>guys, is there no way to run a binary file on guix that isn't packaged?
<kkebreau>Marlin1113: There are a few ways around the issue.
<kkebreau>Wait... make that one way.
<kkebreau>That I know of.
<kkebreau>One can keep a Debian chroot that can handle unpackaged binaries and such.
*kmicu goes 😴 about RISCV GPU liberated to the core.
<Marlin1113>hmm, is that the best solution atm?
<rekado>Marlin1113: s/guys/guix/ ;)
<rekado>Marlin1113: you can use patchelf to patch the loader.
<rekado>while this is a necessary step, it may not be sufficient.
<kkebreau>I second everything rekado just typed.
<kkebreau>In my experience, patchelf works for the simplest of cases.
<kkebreau>Otherwise, you really just end up manually writing a package with calls to patchelf all over the place.
<kkebreau>Does anyone here have Guix System installed on an Asus C201?
<Marlin1113>sudo: /run/current-system/profile/bin/sudo must be owned by uid 0 and have the setuid bit set
<Marlin1113>just noticed this happens when i use sudo
<kkebreau>I just saw vagrantc's comment to me above. I'll try a microSD install.
<Marlin1113>how i do the patchelf thing?
<rekado>Marlin1113: do you have /run/setuid-programs/sudo
<Marlin1113>seems like this one works
<rekado>that should come before /run/current-system… on PATH.
*rekado —> ZzzZ
<Marlin1113>thanks :)
<vagrantc>kkebreau: it's definitely been a while since i installed it
<kkebreau>Marlin1113: I would say that `patchelf --set-interpreter $(guix build -S glibc)/lib/ [program]` is the quickest way to begin work with patchelf, but $(guix build glibc) gives three different folders...
<kkebreau>Whoops, there shouldn't be a "-S" in that command.
<rein1>Is there a way to setup a static IP in the networking configuration of the graphical installer?
<kkebreau>Marlin1113: Just run $(guix build glibc) and use the folder without "-debug" or "-static" after it.
<kkebreau>vagrantc: Fair enough. Did you use a Guix System install image, or install from a running distro? I ran "guix system init" from PrawnOS.
<Marlin1113>doesn't seem to work'
<Marlin1113>it doesn't output anything
<kkebreau>Did you include the dollar sign and parentheses? You didn't need to, my mistake.
<Marlin1113>patchelf --set-interpreter /gnu/store/c43rbmzv1laxgbnkvf76hx4305n4206a-glibc-2.28 [program]
<Marlin1113>i'm trying to run it like that
<Marlin1113>yeah, didn't use the $() part
<nckx>Marlin1113: But also not the actual interpreter, which is the /lib/ld-… part.
<Marlin1113>nothing :()
<Marlin1113>glibc-2.28/lib/ is it this one?
<nckx>Nothing what?
<kkebreau>Marlin1113: Yes
<str1ngs>or you can use my evil dirty hack and add. ("/lib64" ,(file-append glibc "/lib")) to special services. mauh ahh ahhh
<nckx>Marlin1113: Sure. There's also (the slightly more conventional), but that's just a symlink to the one above. Both should work.
<nckx>str1ngs: It's not a hack, it's a feature. (Seriously, for once.)
<kkebreau>str1ngs: lol, how did I not think of this
<Marlin1113>neither worked
<str1ngs>nckx: it's kinda anti guix though :P
<nckx>Marlin1113: Define ‘worked’, though. Is the patched binary crashing? …?
<Marlin1113>it doesn't output anything
*nckx has an ld-linux-… special service on this very machine.
*nckx is anti-Guix \o/