IRC channel logs
2024-12-23.log
back to list of logs
<ullemig>good morning newbie here. i'm trying to install the guix sd in a qemu vm as per the instructions on the web. all goes well until the fetching of the packages. when it gets to guix-1.4.0 or llvm-11.0.0 the download speed drops a lot and either i need to cancel all because it's taking hours, or it ends up saying corrupt input :( <fnat>ullemig: What Guix are you using to do that? Are you using Guix on top of another distribution? If so, perhaps you might want to enable substitutes from bordeaux.guix.gnu.org and ci.guix.gnu.org. <darth-cheney>Anyone free to help with a weird systerm config error whemn trying to build an image? <darth-cheney>For reference, I am trying to load a fairly basic (with some desktop UI stuff) config, but for an ARM system. I'm building the image from within a debian arm vm <ullemig>@fnat (how do i mention on here sorry) i think the substitutes servers that the installer is using are precisely bordeaux and ci <fnat>ullemig: Ha, ok, sorry. Hm, not sure then. Did you build the system image yourself or did you download it from the Guix website? <Googulator>regexes don't quite work the way our intuition tells us they will... <Googulator>so we were never actually disabling profiled builds <ullemig>it gives me the option to edit the config.scm file before starting to install but i'm to new to figure out how to tell it to not use substitutes (if that would help) <Googulator>GHC 7.6.3 Float.lhs COMPILED SUCCESSFULLY using 7.0.4! <luca>pretry sure not using substitutes would make it compile everything, which I doubt you want ;) <ullemig>luca: but with substitutes i'm not even getting past the downloading phase of the installer :/ <weary-traveler>what are the material distinctions between guix home profile and the default guix profile (~/.guix-profile)? i.e. what're the consequences of having a program $foo in one vs the other <weary-traveler>i suppose guix home makes it easier for things to be declarative <weary-traveler>and, if with $foo one also needs to modify config files then guix home works better <pers0n>hi. i set up guixsd a few months ago but stopped touching until recently. after updating i set up guix home for an account. works but the shell doesnt change if i try fish or zsh in home config. does guix home auto cover that change on login, use same tools to change shell as other distros, or rely on .bash* files for that? current home dotfiles are either autogenerated or .baah_history. <RavenJoad>weary-traveler: .guix-home is a profile generated by Guix home. .guix-profile is generated by the imperative Guix commands (guix install & co.). That's really the only difference. <RavenJoad>Guix home lets you modify $HOME configuration files (like .bashrc and so on) too, unlike the imperative commands, which can only install/remove/upgrade packages in the profile. <RavenJoad>sneek: later tell pers0n Guix home cannot change your default shell, since that is set in /etc/passwd. But you can always exec your preferred shell at the end of your .bashrc or wherever (though you should just change your preferred shell in your Guix operating-system definition). <weary-traveler>RavenJoad: thanks for the confirmation. since the default profile too can be updated from a manifest.scm, the really material difference is ability to track config/dot-files alongside relevant packages <Googulator>Is there a way to do `(modify-phases %inherited-phases ...)` (as opposed to `(modify-phases %standard-phases ...)`)? <freakingpenguin>Noticing some pretty poor performance from ci.guix.gnu.org and it looks like a whole bunch of builds are occuring on master. Anyone else see the same? <Googulator>What is the package name for a GCC i686 -> x86_64 cross compiler? I would need one to make the jump from GHC 7.10 i686 -> GHC 7.10 x86_64 <Googulator>Alternatively, is there a way to force a native x86_64 compiler into an otherwise 32-bit environment? <parnikkapore>Hi Guix! Is gtk-4.14.5 failing to build with a SIGTRAP for anyone else? x86-64, /gnu/store/f7s4a47awbv9zqyp1zbkakp66kwndhp9-gtk-4.14.5.drv <Googulator>Looks like the GHC 7.x gap has been successfully closed for i686-linux. On x86_64-linux, I'm stuck, however, getting 7.10 to cross-compile itself. <jakef>when i make a directory in a guix container, where does it go when i leave the container? is it still on disk? hanging around until the next gc perhaps? <stochastic>How would you make a Guix shepherd service that just runs a command? <efraim>Googulator: wow, congrats! I figured it was doable <efraim>one way is to force the GHC early bootstrap to be i686 with the #:system keyword and then to drop it later. Then in the x86_64 build it'll use the i686 GHC <stochastic>I've figured out how to write the service itself, but I'm trying to put it in the `services` field of `operating-system`, like with simple-service in Guix Home <stochastic>I've figured out how to write the service itself, but I'm trying to put it in the `services` field of `operating-system`, like with home-shepherd-service-type in Guix Home <homo>Googulator wow, nice work! btw, I wonder if it's possible to deduplicate code, there is too much repetition <homo>another btw, I watched Lennart's presentation on microhs, if it's possible to build mhs with hugs (since hugs supports almost all features mhs demands, except for bangpatterns) and then ghc with mhs, the build process is going to be more thanb20 times slower and resulting ghc binary is going to be more than 50 times slower, so it's going to be the most tedious bootstrap ever <Rutherther>stochastic: it should be pretty much the same as for home shepherd services, except that here you extend shepherd-root-service-type instead of the home alternative. You can of course utilize the "shepherd-service-type" to do the extension for you. Or what specifically do you have problems with? <homo>I am trying to figure out how to add bangpatterns to hugs instead of patching them out of mhs because they are important for optimisation and might prevent hugs from segfaulting <apteryx>I think that's a first :-D "application de 129 greffes pour gnome-boxes-44.3..." <civodul>apteryx: yeah the glibc graft is terrible from that perspective :-) <civodul>i wanted to run an ungraft branch, but with ‘core-packages-team’ making progress, i’m not sure it’s worth doing it before <efraim>how are we doing on substitutes for mesa-updates? <apteryx>janneke: how is meson working on the hurd? <apteryx>I see a hurd-specific patch for the hurd (p11-kit-hurd.patch); which touches configure.ac; I wonder how meson would do without that <efraim>I knew I had forgotten something. yeah, I have to go through the treesitter commits and see what's still needed and apply them <efraim>also all the wasm stuff is probably going to need a larger go-through to make sure it's sources <stochastic>> stochastic: it should be pretty much the same as for home shepherd services, except that here you extend shepherd-root-service-type instead of the home alternative. You can of course utilize the "shepherd-service-type" to do the extension for you. Or what specifically do you have problems with? <look>ah okay, i got a bit lost since all the patches I sent for helix were applied but the tree-sitter source so I figured I'd ask <look>not sure where to draw the line between skip-build #t vs #f for contributing since cargo only need the sources, and I see both #t and #f in a lot of crates <Rutherther>wouldn't it make sense for everything that contains an app to have skip build #f whereas all libraries have skip build #t? but I dunno, maybe it's intended differently <efraim>I try to build everything so we can make sure each library is working correctly and has the necessary inputs <Googulator>homo: yes, it's probably possible to deduplicate more, but I'm quite new to Guix & all things Lispy <Googulator>efraim: "one way is to force the GHC early bootstrap to be i686 with the #:system keyword and then to drop it later. Then in the x86_64 build it'll use the i686 GHC" - unfortunately GHC has protections against that :( it won't accept a 32-bit bootstrap GHC during a 64-bit build <efraim>well that's unfortunate. that was my first plan <Googulator>the easy part is patching out that check, the hard part is then making it work - I wonder if it's still possible to force the bootstrap GHC to generate C code rather than straight machine code <efraim>then how about like the guix bootstrap. use a 64-bit environment but tell the compiler to build 32-bit versions of itself <efraim>in my head cannon there's some cursed logic that makes it magically flip at some point <efraim>I looked at your gist earlier, the cross-compiler stuff is probably the correct way <Googulator>BTW, the 32-bit build of the GHC bootstrap chain died with a test failure on my fast AMD system at version 8.6.5 (Guix package manager on top of Debian in WSL). Still ongoing in my "proper" bootstrap system (a Core 2 Quad with 8GB DDR2), currently running tests for 8.10.7 <efraim>did we turn off tests for the early versions? At some point its easier to say it's for bootstrapping and if it compiles the next version is enough of a test <Googulator>Ideally, we should teach GHC the simple truth that x86_64 machines, by their nature, can run i686 code natively, so an i686 bootstrap compiler is fine <Googulator>We do have tests turned off for everything before the gap (and everything I added to fill the gap), but beyond the gap, tests are on for every revision <apteryx>ACTION is trying to figure out whether a p11-kit/pkcs#11 configured gnutls could solve our fixed /etc/ssl/certs issues <apteryx>(such as when working with containers)) <Googulator>I do plan on adding -boot variants for each version, preferably with a function to create a -boot variant from the regular one <efraim>that involves writing code. I try hard to avoid writing more code than necessary while packaging <efraim>the regular variants were only really made for bootstrapping, I don't think older versions really get used that much <apteryx>looks like yo can define a "module", which can do "something". Could that something be "read an environment variable, and set a trust path to its value?" <efraim>I guess we could rename them to all have -boot to signify that <Googulator>and see if it breaks anything, in case someone depended on them <efraim>I feel like it shouldn't be that hard to go from i686->x86_64. I just cant think of how it's done ATM for haskell <efraim>ACTION is also sitting in a lobby right now, so it's too loud to really think it through <efraim>ok, I think some of it is coming back to me. I think you can create a cross-GHC using a GHC of the same version, ie 8.6 -> 8.6, and then use that to build a native GHC (or continue bootstrapping on x86_64?) <homo>considering there is hard depency on both gcc 2.9.5 and gcc 4.9.4, it means generated C code is not portable and depends on gcc's internals that shouldn't be exposed... <efraim>ignoring 2.9.5 for a moment, it might be possible to replace gcc-4.9 with a later gcc and different compiler flags like -std=c99 <homo>don't those instructions work only on latest version of ghc? <efraim>we can keep the bootstrap on i686 until near the end and then cross over <homo>sometimes having several versions of ghc is helpful for purposes other than bootstrapping, for example, there is no API compatibility, which means every upgrade a lot of libraries and tools cannot be built <homo>haskell libraries are in a constant process of refactoring, projects that cannot afford playing this catch up game quickly become obsolete <fnat>Is it possible to install Guix on a USB stick? E.g. using QEMU? <olafes>fnat: yes, It's possible like with every other distro <Rutherther>fnat: you probably want to have store mounted at /gnu/store, because if not, substitutes won't match. So either mount the flash contents to /gnu, and then I think you should be fine to install guix normally, or if you don't want to do that, you will have to use something like linux namespaces or proot to get the flash contents to /gnu 'virtually' <olafes>Quick question: Is it possible to run some code every time a package is being build by the daemon? <olafes>It's possible by hacking on guix itself but I wonder if there is something like a build hook <olafes>There are profile hooks and build coordinator hooks, but I'm not sure if either one can be used to transform a package before the daemon builds it <fnat>Rutherther: Thanks! I'm not sure I follow though. What do you mean by "to have the store mounted at /gnu/store"? <Rutherther>or do you just want guix there without the store being on the flash drive? <fnat>The store too. (This is probably not a good idea in the long term, but it'd be just for limited use for a few days.) <fnat>I could use a machine with two USB sticks, one for the installer and one for the target? Would that make things easier? <Rutherther>alright then, then what I said should apply. I meant where you mount the flash drive. That if you didn't want to solve the issue of having the store at "/gnu/store" with some kind of namespace/chroot, you would have to mount the contents of the flash drive to "/gnu" <fnat>(And then booting the machine from the installer, I mean.) <Rutherther>the reason you would want to have store at /gnu/store exactly and nowhere else, is to get substitute hits. If you are fine with building evrything yourself then it can be where you want <fnat>Rutherther: Ok brilliant. Any idea of how bad this is from a USB wearing and system stability perspective? <Rutherther>system stability... wait so you want Guix System on the flash and not just Guix? or what do you mean by system stability here? <Rutherther>as for usb wearing, I don't have the exact numbers, but yeah, guix is quite heavy on filesystem writing across different guix commits <fnat>So as to be able to boot from the pen drive. <Rutherther>ah, okay, then don't mind what I said about gnu store mounting or chrooting and just install guix system on it normally <orahcio>homo: I could see you message about grreetd documentation, do you have the link? <homo>spoiler: there is no auto-login <divya>Guix users, we've created a groupchat (aka "swarm") dedicated to GNU Guix on GNU Jami, here's the swarm id for those who wish to join: swarm:05af4b6867ab64888be1695bd205eec90c87c75e <homo>divya jami is unable to find group, tells wrong address <divya>homo: Let me check the ID again <divya>homo: Can you text me on Jami at divyaranjan1905 or the following ID: d8c704d44f78234f734a1822cd490ff826587b14 <Googulator>It goes through configure now, but then dies because it can't find math.h, a standard libc include <Googulator>The goal of the "uncross" package is to build a version of 7.10 that compiles for x86_64, but Guix thinks it's i686 <Googulator>fixed math.h, now it's missing a kernel header, but this time, I think I know what's wrong <Rutherther>does it use some uncommon environment variables? <divya>Googulator: What exactly are you working on? <Googulator>Specifically, I have gotten it working all the way from 4.08.2 to 9.4.4 for i686, but x86_64 needs a cross-compilation step <Googulator>getting /gnu/store/m6dgdprlrfdbym0qlz2lg17id76g45xi-glibc-cross-x86_64-linux-gnu-2.35/include/bits/errno.h:26:11: fatal error: linux/errno.h: No such file or directory <cancername>Hi! Can I somehow bind my `guix home` config to my `guix system` config so I can build a system using `guix system build` that has my home configuration? <dariqq>cancername: There is a guix-home-service-type (for your operating system) which should activate the specified home environments <cancername>I apologize for the beginner Scheme question, but how can I load the home-environment from a separate Scheme file, is there something like use-modules for that? <dariqq>cancername: Maybe (load "file.scm")? <cancername>dariqq: I did try `load`, but that gave an error, something along the lines of "wrong type to apply". the file I am loading is a fairly standard home configuration <cancername>Oh wait, nevermind, that was indeed the wrong type. <homo>Googulator: if previous releases exist only for bootstrap purposes, won't it be easier to skip uncross until 9.4.4? <Rutherther>cancername: note that you could also use-modules if you made your home configuration a module, exported the configuration, and added it to load path (ie. with -L flag) <Googulator>homo: they aren't just for bootstrap; besides, the issues I'm having right now don't appear related to immature cross-compilation support in GHC 7.10, but rather are related to Guix (and my poor familiarity with it) <Googulator>...And now that I look more at the definitions for glibc & co, I now don't understand at all how and why a regular (non-cross) GCC under Guix is able to find the kernel headers.