<SeerLite[m]>Hi! Should `guix system image --volatile <config>` be enough to make a bootable USB with said config? It's not getting recognized by the UEFI of the PC I'm trying to boot it in <podiki[m]>uefi-raw maybe? i forget, but yes, guix system image should make a bootable image of any ocnfig <podiki[m]>well you can try the iso9660 then? or could be how you use the image, dd making sure to use sync after and unmounting properly <podiki[m]>but that should work with uefi-raw, I've done just that before (though not with --volatile) <SeerLite[m]>podiki[m]: The iso9660 bit kinda confuses me, isn't that like only BIOS booting? <podiki[m]>I'm not sure, I know I used iso9660 for the install image, but uefi-raw for a live system image (according to old command history) <SeerLite[m]>Were you able to install in UEFI mode from the iso9660 image? <SeerLite[m]>Wait is the boot mode of the live usb unrelated to the one of the installation? <podiki[m]>yes. honestly I don't remember or know what those options are for exactly... sorry <robin>hmm, it seems very common for packages to install documentation in share/doc/$PKG and for license files to be auto-installed in share/doc/$PKG-$VERSION <podiki[m]>SeerLite: I thought the image type is just for what is in the image created, which should just be how you write it (and/or boot from it?), sorry don't know more <podiki[m]>I think the bootloader in the image is always from the config you pass it though <SeerLite[m]>Ohh right, the bootloader from the config! So nevermind, it wouldn't even be able to boot if the image is BIOS-only while the config has UEFI grub, I think? Actually, I don't know what I'm talking about haha. I'll just try with iso9660 and hopefully it boots, I only want it as an install medium anyway. Thank you podiki ! <podiki[m]>the normal install image I think is iso9660? or at least when I made one that's how I used it (I think I was also confused between the options...and still am) <robin><5% of packages in my profile bother to install documentation alongside the license files <robin>not strictly a bug, but maybe suboptimal (presumably only packages where multiple versions can usefully coexist would want the longer subdir name) <robin>hm, some documentation that gets installed on debian isn't on guix, e.g. the coreutils THANKS file <robin>also just noticed some packages have etc/ld.so.cache, which is probably a bug <robin>podiki[m], ah, ty, that explains it :) <robin>slightly confusing that $PROFILE/etc/ld.so.conf is from a random package (bzflag in my case, lol) but that's a small price to pay <the_tubular>The following package will be upgraded: calibre (dependencies or package changed) nothing to be done <the_tubular>Nothing to be done ... Or is it going to be upgraded ...? <bdju>did anyone fix the text display issue in qt stuff yet? <podiki[m]>robin: I noticed that too (forget what package), maybe something to be cleaned up somewhere <apteryx>podiki[m]: could you share the exact error? <podiki[m]>apteryx: the problem was on my end (I'm terrible with meson), I got it to build <podiki[m]>trying to run it now to see if it works the same <podiki[m]>oh, apteryx what do we want to do on the pciutils front? I'll test the hwdata package later to check that it works <podiki[m]>mangohud still works for opengl, but not seeing it in vulkan <podiki[m]>oh, I had to add to the imgui package since it wasn't building everything before, maybe something still missing... <apteryx>podiki[m]: about pciutils I replied by email to your message and also the new pciutils patch <podiki[m]>I should reply to the pciutils thread, but when I did this in my patches the closure size was smaller at least (zlib gone) <apteryx>I think it may be worth it spending some time to see if we could make the library solution I thought about work; dropping compression (increase in size from 300K to 1.2M) or a duplicate uncompressed variant seems unsatifastory to me <apteryx>yeah, but the world depends on zlib, so its closure size is not very meaningful <podiki[m]>how about the package of just the hwdata? that seems useful on its own, and if pciutils has pci.ids.gz it won't be a profile collision either <robin>podiki[m], lots of packages, if you mean the share/doc thing <robin>maybe a #:versioned-fhs-dirs? argument would be useful (for share/foo, lib/foo, libexec/foo, share/doc/foo...) <robin>i'm not sure guix's license-file-copying is actually all that useful to store in share/doc/foo, actually, given that it just hoovers up any LICENSE/COPYING/COPYRIGHT files in the source tree and dumps there, when packages should install the relevant files themselves... <\f>disposabled[m]: have you pulled recently? <mroh>`guix show rust` shows 1.57.0 <robin>(oh, just the top level actually, it just tries to be clever about out-of-tree builds. still, in theory i'd consider it a package bug for installation to leave out license info, maybe it's too common an omission for guix to leave it up to packages) <\f>disposabled[m]: try running `hash guix` and search again, see if that helps. <disposabled[m]>Previously, `Authenticating channel 'guix', commits 9edb3f6 to d1ca5b8 (16,329 new commits)...` <disposabled[m]>Now, `Authenticating channel 'guix', commits 9edb3f6 to d1ca5b8 (12,914 new commits)...` <\f>disposabled[m]: is there a message at the end of `guix pull`? <robin>ideally i'd just check the license field anyway, too many packages these days do things like having LICENSE but not COPYING and then requiring one to go source spelunking to discover it's actually AGPL3+ and not simply AGPL3 or whatever <robin>(today's real-world example: brogue, but many people seem to skip the "How to Apply These Terms to Your New Programs" section of the *GPL) <disposabled[m]>somehow. my scrollback that contained 1000s of lines from which I copied the above just shrunk to 50 <\f>disposabled[m]: basically your shell is pointing at the wrong version of guix right after you `guix pull`. <\f>It prints a message that tells you to reload your profile and run `hash guix` to ensure it points to the new one. <sleepydog>i am trying to use the 'opam' importer and getting a certificate error for opam.ocaml.org. my browser and openssl say the cert's valid (i'm on arch linux). how can i inform guix of the root CA? <robin>sleepydog, hmm, on guix you'd use the nss-certs package (see (info "(guix)X.509 Certificates")). not sure how to make guix itself use those certs on a foreign distro though (vs. user programs) <mitchell>Hello guix, Does anyone have any experience using the emacs-guix package? When I attempt to do most things with it, it doesn't seem to understand gexps and drops into a debugger <kitty1>ah yeah I was trying to mess around with that too earlier <robin>sleepydog, oh wait, ofc running an importer shouldn't involve the daemon, so just setting up nss-certs as suggested may do the trick <sleepydog>robin: i tried `guix install nss-certs`, then running again, it didn't seem to make a difference <sleepydog>looking at strace, it seems to look in ~/.guix-profile/etc/ssl/certs <robin>sleepydog, hm, and it sounds like the env vars are set correctly if it's checking that directory <sleepydog>letsencrypt recently made some changes to their PKI, so it might be missing, or the ocaml folks may have made a mistake. i'll know in a minute <sleepydog>oh, this looks wrong: openat(AT_FDCWD, "/home/me/.guix-profile/etc/ssl/certs:/home/me/.guix-profile/etc/ssl/certs", ...) = -1 ENOENT <sleepydog>it looks like my SSL_CERT_DIR variable is wrong <sleepydog>fixing that resolved the issue. i wonder how it got set like that <robin>yeah, that's a bit odd...guix and a few other packages specify SSL_CERT_DIR as an environment variable, but as a single-entry "search path" ***anticomputer_ is now known as anticomputer
<robin>might be worth checking ~/.guix-profile/etc/profile to make sure it's setting it properly (on guix system it's set in /etc/environment which i don't think has an equivalent on foreign distros) <sleepydog>i think somehow i sourced it twice, because that script prepends to it <robin>sleepydog, sounds like a bug if you feel like reporting it :) <sleepydog>sent an email. apologies in advance if the bug report isn't up to snuff <sleepydog>oh, do I need to subscribe to bugs-guix to send? <robin>sleepydog, bug-guix*, but no, shouldn't need a subscription as it's debbugs rather than a mailing list <sleepydog>i don't see it yet. i'll check back tomorrow <robin>i may be able to withdraw from emacs someday, but M-x doctor tells me i won't be able to kick the habit until guile-cl works well enough to run CLIM applications ;) <kitty1>emacs is great but would be 100x better if it was rebuilt from scratch modernly and sanely ***whound is now known as dust__
<dust__>It it possible to use pipewire successfully in Guix ? <iyzsong>i think we're missing pipewire-media-session, will look into it later... <podiki[m]>sneek: later tell apteryx I think mangohud will work with the newer imgui (with a few changes of files to add to the build in imgui), still need to test hwdata package and iron out something in mangohud <dust__>iyzsong: wireplumber can be used as alternative to pipeeire-media-session right ? <iyzsong>let me see if i can make it works... <iyzsong>dust__: yes, it works! I started pipewire, pipewire-pulse and wireplumber in my window manager (which was started by dbus-run-session). <iyzsong>wireplumber require the 'elogin-service' system service though. ***dust_ is now known as dust__
<dust__>iyzsong: Can you just list way to set up pipewire ? <dust__>:iyzsong How do you disable pulseaudio service. I used delete macro in modify-service in my system configuration and it doesnt stop the service. <iyzsong>dust__: I don't have pulseaudio in my services <iyzsong>dust__: i think you just need to make sure that 'pipewire-pulse' is started before any pulseaudio based applications. <iyzsong>dust__: i'm not sure, but delete them can't be harmful <dust__>iyzsong: I thought by deleting them the service would stop but it still runs. <vivien>Dear guix, I would love to get the MNE python package approved. I opened https://issues.guix.gnu.org/53402#6 and I would love to get further reviews. Vinicius Monego helped me a lot already, so maybe some other person could hop into the discussion. What do you think? <abrenon>futurile: did you manage to find a way to update all the packages in a module like you were trying to ? <sss1>hi all, is it possible to override /etc/guix/channels.scm for just one command ?, i need to do guix time-machine --commit= with only default guix channel <sneek>sss1, maximed says: If you error: see "ungexp: unbound variable", that means the variable ungexp is unbound but you're trying to use it anyway, so you need to import the module that defines it. <sneek>sss1, maximed says: I.e., (guix gexp) <sneek>sss1, maximed says: nevermind, it's a bit more complicated <sneek>sss1, maximed says: Make sure you're using #$ (i.e., ungexp) from within a #~ (i.e., gexp) form. #$ is only available inside #~ forms. Or possibly you don't need #$ at all. <sneek>sss1, maximed says: Remove the #$ from wireshark <sneek>sss1, maximed says: file-appends needs a file-like object, and wireshark is a package, and all packages are file-like objects, so the #$ isn't uuseful there <sneek>sss1, maximed says: The G-exp mechanisms (#~, #$, #+) aren't used in setuid-programs <mange>sss1: "guix time-machine --help" tells me that there's a --channels option that might do what you want? <sss1>mange: thx, i will check <roptat>help, I'm clicking through windows :/ <zimoun>roptat, you mean correct English? Well, I just looked for an example in the backlog and just copy/paste. The message worked, right? <roptat>I suppose you didn't want to send a message to "later"? <sneek>later, roptat says: zimoun hello <roptat>and now, you won't get the message after you speak <roptat>sneek, later tell zimoun hello hello :) <sneek>Welcome back zimoun, you have 1 message! <sneek>zimoun, roptat says: hello hello :) <zimoun>Is it documented somewhere? Because my search/copy/paste does not always work. :-) <roptat>no idea, it's just a few commands I've seen and remembered <abrenon>also, you can ask sneek directly by saying help to it <sneek>Someone once said Haskell is a generator of monad tutorials. <sneek>Its been said that scheme is a beautiful and elegant lisp dialect. <mange>Yeah, that sounds right. You should be able to use %default-channels instead of defining the channel explicitly. I had hoped "guix time-machine --channels=<(echo %default-channels)" would work, but it doesn't look like Guix is able to read the process substitution file. :( <lilyp>sneek abrenon is someone who finds sneek's description of Scheme and Haskell unfair. <abrenon>it's not documented in its help, though <sneek>From what I understand, lilyp is someone who gives helpful advice <sneek>Its been said that the cake is a lie <xelxebar>Every now and then I encounter manpages that appear to be raw troff. elogind(8) and logind.conf(5) are examples. <xelxebar>Could someone sanity check that this isn't just me? <xelxebar>Looks like elogind uses meson-build-system, which appears to be pulling in and adding to %standard-phases from gnu-build-system. <AwesomeAdam54321>After I do guix gc, the default browser extension icons don't load because they no longer exist in the store <robin>hmm, any idea what package include/X11/bitmaps/gray might be in? <ekaitz>efraim: do you know if a backport of gcc for riscv exists anywhere (fedora/rhel/centos maybe)? someone told me you might know <efraim>ekaitz: how far back are you looking? <ekaitz>efraim: I just wanted to know if htat exists. Do you have any idea of that? <efraim>I know there are a bunch of backports for aarch64, I haven't checked for riscv before <allana>Hi guix! Maybe this is a question better for the mailing list, but I suppose that I can start here. I have seen that debian, gentoo, and likely other distributions replacing glibc's libcrypt with something called libxcrypt -- which supports more hashing algorithms -- and I am wondering if there has been any discussion regarding this in guix. I have seen commented out references to a "libxcrypt" in an unrelated discussion in the <allana>guix-devel mailing list, but that's about it. I for one am interested in such functionality. <efraim>ekaitz: First glance gcc gained support for riscv in the gcc-7 branch <ekaitz>efraim: the 7 is not really a backport i'd say, that's what we have in standard gcc <ekaitz>i'll have to do it myself it seems <acrow>allana: I don't see xcrypt being worked on in guix yet. I wonder if there is some reason? At first glance it doesn't look like it would be hard to package. <ekaitz>it's still pretty recent, I have to backport to 4.7 but that will be useful <allana>acrow: I'm going to try to package it, but after that I am lost. It is intended to be a drop-in replacement for glibc's libcrypt, and the build of glibc can have libcrypt disabled. So I wonder if it would require having an alternative glibc, or would the replacement just live along just fine, and be "chosen" by software that uses it as a propagated input? These are quesitons that I will have to try to figure out by trial and error or by <allana>asking people who know how these things work :-) <efraim>I don't think there's anyone like collabora but for riscv, but github.com/riscvarchive looks pretty good <jonsger>ekaitz: what are you trying to achieve? <ekaitz>jonsger: I'm backporting riscv to gcc to make it bootstrappable from a c compiler <acrow>allana: I'd be in the discovery through trial and error camp; but, optimistic about your plan. <acrow>allana: it may be easier to implement in guix bc multiple versions of glibc can co-exist peacefully. <ekaitz>jonsger: It's part of the guix full source bootstrapping effort, and I'm being funded by NlNet for this <AwesomeAdam54321>Nevermind, I fixed the issue by deleting extensions.json and the new one generated uses the built-in extensions from the current IceCat <roptat>restarted, now my clicks work properly... <roptat>no idea what happened, it was super weird <ekaitz>roptat: what was the problem? you lost the clicks? <roptat>no, they were registered, but they wenth through windows <roptat>trying to select text on a window would go through and select text on the window below it... <ekaitz>I asked because my sister lost the left click during an arch upgrade last week <roptat>now changing virtual desktop would "reset" the window that could get the clicks to the front window at the moment I entered the desktop, so it wouldn't go through that window <roptat>alt-tab would let me change window, but not change the window that could receive clicks *roptat needs to go now :) <phf-1>I've setup a VPS with Guix System on it. <phf-1>I've followed your tutorial after failing to use Cuirass on a foreign distro. <phf-1>mothacehe, well, no, it works! <mothacehe>may i ask what would u like to build with cuirass? a custom channel? <phf-1>also, if I can get a substitute it's great <phf-1>mothacehe, well no, guix download behaves the same with or without .git extension <phf-1>jobs are scheduled but not executed <phf-1>2022-02-22T16:18:26 error: build succeeded: '/gnu/store/gqc8jcd6vwh6gd64xfjiisjn5jzynvvv-texlive-ruhyphen-59745-checkout.drv' <mothacehe>could you paste the cuirass service configuration you are using> <mothacehe>i meant the scheme guix service configuration ***the-porcupirate is now known as porcupirate
<blake2b>something I forgot to bring up during guix days: guile needs a german localization called "geil scheme" <mothacehe>but i'll investigate later the issue you are having <mothacehe>don't hesitate to submit a bug report about that ***robin_ is now known as robin
<blake2b>see, the german contributors agree: guile ist geil <ss2>blake2b: best pronounciation. :) <VS4mwaLnRSM>Oh blake2b, always lovely to see you! Hope you are being used liberally! <VS4mwaLnRSM>I do use SipHash when it makes sense, too, with which I hash the keys. <VS4mwaLnRSM>I wonder why djb picked CubeHash for checks involving file integrity. <blake2b>VS4mwaLnRSM: smh, BLAKE is the only way to go <VS4mwaLnRSM>I think BLAKE3 supports arbitrary digest length, is that really the case? At least when I do "echo 'foo' | b3sum -l 1000" I get output where the first N characters are as it should be, and then it continues, whereas b2sum says invalid length, and that maximum digest length for blake2b is 512 bits. <phf-1>sneek later ask mothacehe I've sent a bug report. Trying the other method. <lfam>Howdy, I'm curious if the discussion "10 years of Guix - a retrospective" was recorded? <blake2b>tbh, i'm a sha guy. my name is blake shaw, so I, like most, choose encryption based on surname precedence. 2b was just to indicate I'm a recovering philosophy academic. <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, xelxebar says: Thanks for the poke. In this case, I was running essentially bare-bones.tmpl, so ntp wasn't even running! IIRC, the ntp-configuration defaults to setting allow-large-adjustment? to #t which apparently corresponds to the -g option of ntpd. The guix man pages don't mention that option, but looking in the sources, it says -g allows adjustments of "up to 68 years in the past or <lfam>sneek: later tell xelxebar: Regarding NTP and bare-bones.tmpl, Okay! I suppose that 68 years will be good enough for the time being <lfam>phf-1: Yeah, it's the same thing <lfam>If you're curious about details of sneek, the human behind the bot lives in #guile <lfam>Sometimes it's more natural to "ask" vs "tell", but they are equivalent as far as I've noticed <phf-1>Ok. I was wondering if the message could have been delivered as soon as the account connects instead of as soon as the account speaks. <lfam>At least this way, you're sure the recipient is actually "present" <sneek>From what I understand, Sneek is bicoastal. <sneek>Someone once said Sneek is bicoastal. <sneek>apteryx, you have 1 message! <sneek>apteryx, podiki[m] says: I think mangohud will work with the newer imgui (with a few changes of files to add to the build in imgui), still need to test hwdata package and iron out something in mangohud <rndd>hi guix! is there way to run vnc server on guix to use it as a remote desktop? <apteryx>rndd: we don't have a service for that; I have on my todo to add a service to allow configuring SPICE for remote desktop usage <apteryx>as that's supposed to be faster/better than VNC. <apteryx>we already have some SPICE integration, for example in our vm template that makes interacting with the virtual machine nicer; it's probably not that difficult to expose the config needed to allow remoting in (perhaps already possible?) <Lembrun>Hey, I was just wondering if you could have an unencrypted /boot partition and encrypted root? <rndd>apteryx: hi, thank you for the reply. Okay, i will live with ssh for now <podiki[m]>apteryx: I found some pieces of imgui that were not built, once I figure out if mangohud is fully working (having some Vulkan issue, but I think it is on my end) I'll submit new patches: fix for imgui, new mangohud package <podiki[m]>apteryx: I'll respond on the pciutils issue, in short I think a separate hwdata package is helpful and seems programs that want just that data might not want all of pciutils anyway (pciutils can have compressed pci.ids) <nckx>apteryx: (options (or rootflags (file-system-options root-fs*))) ; interesting, is it really that easy? No mount flags/mount options distinction? <apteryx>podiki[m]: the new imgui package doesn't link against some vulkan stuff; if you need vulkan support at the imgui level we may need to add some input and link option <apteryx>nckx: the doc only says: rootflags= [KNL] Set root filesystem mount option string <podiki[m]>locally I enabled more backends, though I actually dont know how it works really (mangohud normally can build its own imgui, but with no backends...) <podiki[m]>it does work in a vulkan test (vkcube) but not in other things I do with mangohud, so just want to make sure it is not inherent in the package <nckx>apteryx: So rootflags=noatime works? <podiki[m]>apteryx: more importantly, a couple of the imgui .cpp files weren't compiled, missing things like tables; I'll send a patch once I test more <apteryx>nckx: if noatime is an option, it should work yes <nckx>Whoa, I just remembered xerofoify. There's a wild blast from the past. <nckx>That's the reason for my question. <apteryx>ours is more consistent; initrd behaves like linux <apteryx>for the initial root file system mount <nckx>Hah. I found it unclear. <lilyp>Is there any package other than libglvnd that has libGLX.so? <apteryx>clear as long as mount 'options' in their doc really means 'options'. Which may not be granted given they named the argument 'rootflags' <nckx>apteryx: I guess that's the (historical?) reason for e.g. ‘ro’ and ‘rw’ being stand-alone options & not rootflags. <nckx>apteryx: That is the most Linuxy sophistry I've heard in a while 😃 (by which I don't mean to imply you're wrong, in fact I agree with you). <apteryx>my limited testing suggest it is working as intended (as options) :-) <apteryx>I could pass for example btrfs options such as "subvol=@root", and it booted, and I didn't see the usual options that I usually provided via my root file system (such as "compress-force=zstd,degraded"). <nckx>Do you think it's excessive to explicitly point that out in guix.texi, where you say it replaces @code{options}? Or am I too paranoid? <nckx>I.e. adding the user-friendly equivalent of a (sic). <apteryx>I've already @emph'd the word 'options', but if you think that will spare some answers here, I don't mind stressing that even more. <nckx>I'd (rather ironically) missed the @emph. <nckx>Dunno if it's common. Reason I asked was a user complaining about rootflags=noatime a while back (using my older, crappier rootflags= patch ☺). If the answer is ‘notabug, (trad)Linux wouldn't support it either’ I'm OK with that. Thanks for the explanation. <apteryx>nckx: ok :-) perhaps we can leave it the way it is, and refine if/when the need arises <Michal_Atlas[m]>Hello, sorry for such a broad question, but, how does one debug system declarations? When I run guix system reconfigure I just get "unbound variable" or "no code for..." when there's an error anywhere and it can't compile (--debug doesn't change this at all), but trying it with "guile -s" just yields errors since the channels aren't in scope. What do I do? 😅 <apteryx>nckx: there's something which I hadn't really foresee with the patch "system: Add a version field to the <boot-parameters> record."; (version 0) used to be *part* of the expected parameters file data structure; now the version can be any positive, exact integer <apteryx>this is OK going forward, and booting old generations works fine also <apteryx>but older guices won't be able to reconfigure the system if it some generations to rebuild grub.cfg file contains a parameters file with (version 1) <apteryx>it's the price to pay to move to a proper versioning of that file, I guess. <nckx>So IIUC booting an old generation and reconfiguring won't work? <nckx>Would a future bump from 1 → 2 in the same situation be handled better in future? I don't see how but I'm just looking at the patches in RoundCube (-_-;) <djeis>Is there any better story for md raid than giving the raw /dev device names for the partitions in the array? I’ve definitely experienced drives getting shuffled around after reboots on some of the servers I’m managing, so I’d like to avoid relying on that if possible. <apteryx>nckx: in the future, going from 1 -> 2 shouldn't cause this problem <apteryx>as from now on a valid version would be any exact integer >= 0 <apteryx>it used to be that version had to be strictly 0. <nckx>Yeah, that match was silly. But older Guix's won't choke on unknown new fields? That was my worry, but it sounds like it was unwarranted. Great. <djeis>I tried to write my own raid mapped device which assembles by the array name or uuid, but the downside of that seems to be guix no longer loads the kernel modules for my drives in the initramfs. <apteryx>nckx: older guices get their kernel command-line parameters from grub.cfg; and the grub.cfg is generated conditionally to the version of the boot-parameter record <apteryx>if it's 0, it uses the old style arguments. If it's 1, it uses the new ones. <apteryx>In the future, we can introduce more change if we bump the version to 2, for example. ***lukedashjr is now known as luke-jr
<nckx>apteryx: Great. I just wondered if it had been tested, since clearly the original author also thought they were doing versioning right 😉 <apteryx>I've made sure 'make check TESTS=tests/boot-parameters.scm' is still happy <apteryx>the 'make check-system TESTS=basic' also passes; and I've manually tested it on my machine (booting last reconfigure revision or an older one works) <mrw>Good day all. I've been exploring using guix to create an embedded system. I am ware of the FOSSDEM 2020 talk on Guix as potential replacement for Yocto. I've make some progress in that I can now build a cross toolchain for a given gcc version, glibc and kernel headers (I work on some old stuff for which I am currently forced to use 3.10 for <mrw>example). Given this toolchain, I'd like to see how to use guix system to build a rootfs image. But I'm not curently understanding how the --system argument maps to a particular toolchain, or if that mapping can even reasonably altered. Does anyone have an ideas or suggestions? <mrw>I think this would be a really neat alternative to yocto or even buildroot, but those are typically able to specify at a very detailed level aspects of the toolchain (gcc version, gcc features) c library (glibc, uClibc, etc) and kernel version. Is this something that could be done with Guix as well or is it incompatible with the project? <jgeerds>Could someone tell me where the activation point for "guix home" is in case of a foreign distro? Should it be "~/.profile" ? This file is not sourced on my machine (running Gnome under Wayland). I guess that's more a Wayland issue than a foreign distro <roptat>mrw, the --target flag controls the target of the build, and it's up to the build-system to interpret what that means. Most of the time, that means using whatever toolchain is defined in (gnu packages cross-base) <roptat>I don't think it gives you fine control over versions of the toolchain you use ***lukedashjr is now known as luke-jr
<mrw>roptat that is consistent with what I've figured out on my own so far. I suppose I'm wondering if that's how it always will be of if there is any desire / ability to add more control. <roptat>is there a reason why you need specific versions in the toolchain? ***lukedashjr is now known as luke-jr
<roptat>the role of the --target is to build for a given architecture and be able to run that there. It's similar to not having a --target and building for the current architecture. It's supposed to work on any machine with that architecture <mrw>it's pretty common in the embedded linux world to do this sort of thing. sometimes it's because the board is of a particular vintage or you might be stuck with a vendor-specific port of the linux kernel, so on and so forth <roptat>so when you build natively, you don't get to chose the toolchain either <roptat>does the kernel version impact the toolchain? <mrw>i can choose different versions of gcc-toolchain, which often are tied to a specific version of the linux-libre-headers <roptat>aren't they supposed to be compatible between versions? <mrw>The C library is usually compiled against a version of kernel headers <roptat>guix has multiple versions of the kernel, but only one linux-libre-headers for its toolchain <mrw>Not from what I've seen. <roptat>I meam the default toolchain uses only one version of the headers, right? <roptat>yet we can chose between multiple versions of the kernel <mrw>Oh, yes. That's true. <mrw>It's a package deal, usually <mrw>Anyway, it's just something I was exploring and curious about. <roptat>well, it sounds like --target is not the right abstraction then <roptat>have you tried installing guix (the package manager at least, not the system) on these embedded devices? did it work? <roptat>or run a guix pack built for that target' <mrw>My goal is to cross-compile a system on a host then install it on the target. I will go down the path shortly of trying to run a guix-built package on a target. <mrw>buildroot is usually my go-to for this type of thing, but I thought it would pretty neat if I could eventually uses Guix. It doesn't seem though that is realistic. <roptat>at least try to run something built by guix, that should reassure you, or if you fail, motivate us to find a solution :) <roptat>if it doesn't work because of the toolchain, then is time to find a way to make it easier to customize the cross-toolchain <roptat>need to go to bed now though, good luck :) <mrw>Thanks for the input roptat ***lukedashjr is now known as luke-jr
