<the_tubular>Docs online says to put in into ~/.config/channels.scm, but there must be a more guixy way to do this <mroh>the_tubular: you could try to add an etc-service that writes to /etc/guix/channels.scm, but I'm not sure if that's a good idea. <kitty1>One of my friends that uses nixos keeps talking about nix flakes, I'm kinda struggling to wrap my mind around their description of it, but im quite curious if anyone has attempted anything like that with guix yet? <kitty1>havent heard anything like that, but might just be missing something ***lukedashjr is now known as luke-jr
<kitty1>the_tubular: not quite sure tbh, supposedly it makes proper reproducibility much much easier to deal with in certain circumstances or something <kitty1>there is plenty of good posts (including a recent reddit post discussing the purported advantages of it) on it <podiki[m]>from my brief look seems similar to channel commit pinning? but being able to specify that for a project <podiki[m]>I guess something like inferiors, pinning, and manifest/profile in guix? <the_tubular>Nix people should definitely *Peer into the Land of Parentheses* <kitty1>the_tubular: and guix people like myself should also peer into what nix is up to, both projects serve to benefit from eachother <podiki[m]>I think the idea (as a non-nix person) is so that someone can e.g. clone a repo and do the exact same build <kitty1>but yeah, even tho im a bit confused they do seem very neat, would be fun to play with on guix some day <kitty1>probably will spin up a nixos vm some time and mess with it to get a better idea some time here lmao <podiki[m]>I'm sure there would be interest in making such a thing easy in guix, seems the ingredients are there (add in guix shell and container too) <acrow>jeko: A nicely done article. It's good to see emacsclient leveraged this way. I'll have to think about the security implications though. I think you intend that your vm be the sandbox and it seems reasonable to me. <podiki[m]>I don't think you need a full nix vm for this, just nix as a package manager (which guix has) <podiki[m]>do think it would be cool to build out using guix for reproducible builds in any old project (haven't tried out what is there, e.g. using a guix.scm to define the build) <podiki[m]>anyway, don't know much about it, but probably others do and can let you know what the equivalent in guix-land is, or what tools could be used to make something similar <kitty1>yeah, very curious on that if anyone knows, I get a feeling its the latter, and with the tools on guix it looks like it would be relatively simple to someone a bit more familiar to hack something together that has a similiar purpose? <the_tubular>To contrbiute to guix, do you have to sign the FSF paperworks ? <podiki[m]>you just add your copyright line as part of the file you edit, it will be part of the patch <the_tubular>I don't remember what it's called but I know you have to sign paperwork for some FSF projects <kitty1>hadnt heard of that one before tbh <podiki[m]>so that answers it as I don't see an FSF copyright in guix files <the_tubular>Guess not... I'm still reading about what they are ^^ <podiki[m]>compared to, e.g. emacs where you see the FSF attribution in each file <the_tubular>Sorry, didn't mean to Hijack the conversation, I though it would be a simpler answer <podiki[m]>in short, guix copyright is not held by FSF but by the individual authors (I'm not a lawyer) <the_tubular>Because from what I heard, you can send those paperworks, but they take a while to process it <the_tubular>I don't remember where I read that, so don,t take this for absolute truth either <kitty1>I cant stop thinking about flakes lmao, like, I dont have enough experience here but it really feels like that wouldnt be hard to hack together, right? <podiki[m]>I think it is safe to assume any legal paperwork takes a while :) <the_tubular>Yes kitty1, from my very small understanding it seems it would be of gluing different part of guix togheter <podiki[m]>kitty1: I think you are right, from what little I understand. a profile with pinned channel commits and then a package definition or scheme file to do the build roughly (in a build container or how packages are built) <podiki[m]>I think you can even do it with a local channel defining your package and specify the commit of the other channels it depends on? <podiki[m]>because guix package definition and channel commits will then specify the derivation which is reproducible (up to things that are non-reproducible more generally) <podiki[m]>anyway, sounds like a good discussion to have, I'm off for now though! <kitty1>if anyone knows any more feel free to ping <kitty1>yeah, some time here I will probably start messing with nix flakes themselves a bit ***dgcampea-2 is now known as dgcampea
<apteryx>nckx: perhaps instead of falling back to fictitious defaults, we could error out when the user hasn't provided 1. root= or 2. an operating-system containing a root file system? <nckx>We could, if that doesn't break the volatile-root? hack. <nckx>TBH the whole mount-root-file-system special case feels wrong at this point, why are we treating it so horribly special. <apteryx>it seems volatile-root? only comes into play when there *is* a root file system <nckx>I'm not looking at code right now. ***A_Dragon is now known as NotRegistered
***NotRegistered is now known as A_Dragon
<the_tubular>Anyway to control guix container on multiple hosts ? ***aya is now known as gyara
<apteryx>nckx: I've pushed what I did for the rootflags... but 'make check-system TESTS=basic' fails. I don't get it. <apteryx>pushed to the wip-initrd-rootflags branch <allana>Hi guix! sorry for the accidental paste in the chatroom <kitty1>allana: haha ive done that before. if you dont mind me asking; what's #lobsters btw? <allana>kitty1: it's a chatroom related to a tech news aggregation site. I wanted to request an invitation to the site so that I could participate in a comments section related to guix <kitty1>yeah ive def seen both cool discussion discussion and misinformation on guix on various places on the internets :P <pkal>allana: What was posted? <allana>pkal: There was a nix post, and guix was mentioned in the comments. <pkal>allana: Link? I don't see anything on the front-page? *allana shared the link in a direct query <pkal>Can regular services be used in home configurations? <civodul>pkal: nope, only services from (gnu home services ...) <pkal>Hmm, and there is currently no way to automatically convert one into the other? <civodul>no, but not all system services may be used as an unprivileged user anyway <pkal>I wanted to use syncthing as a user-service <pkal>So if I understand correctly, it would be possible to define services that can be used both on a system and user level, but it cannot be done for free? ***ff is now known as Guest7777
<civodul>though, in the case of syncthing, we should be able to make it available for free <pkal>Hmm, maybe I can take a look if I can get it to work. <pkal>Probably not though, I still haven't managed to get a satisfiying Guix development setup <civodul>keep in mind that Home is still very much WIP <civodul>you can get a nice development setup without Guix Home though :-) <the_tubular>civodul unnatended-upgrades would be cool to have for users <rekado_>I wonder about pipewire. Is there a way to configure ones system to use pipewire — even without Guix Home? <rekado_>the daemon must run, but I guess on a single-user system it could just run as a regular system service, no? <civodul>the_tubular: yup, that's a good example <civodul>rekado_: i don't know, i don't think someone's working on this <civodul>then again, quite a bit of Home-related work happens "outside", in rde <civodul>and there isn't much progress on the ground work we need <the_tubular>Also, I'm not sure I understand what you meant by : right, it doesn't come for free <civodul>the_tubular: that you can't just add (service syncthing-service-type) to your Home config <the_tubular>I might try my hand at unnatended-upgrades for guix-home <pkal>Another question, it seems that after guix gc, any guix package operation always starts by downloading the same packages (git-minimal, gnutls) again, what might be the reason for this? <maximed>civodul: I've sent a patch for upower <maximed>pkal: 'git-minimal' is (usually) only used for downloading source code, so it does not end up in the references of anything in the profile, so the GC considers it unreachable and collects it <maximed>Perhaps this can be avoided with --gc-keep-derivations and --gc-keep-outputs <pkal>I'm going to try it (have to anyway since I'm running out of space in /gnu/store all the time anyway) <civodul>i see you keep asking questions on v2, but as a rule of thumb, i think we cannot ask for more work after a review round <civodul>(IOW, review round N+1 cannot state requirements/demands that were not already stated at round N) <Haider>OH, lilyp made a talk about "how guix saved me". Nice talk *civodul curious to watch it too <civodul>yesterday i enjoyed the talk by John Keyhayias about a newcomer's experience ***Guest2562 is now known as roptat
<roptat>hi guix! Finally got the last missing video for the Guix Days this week-end! <roptat>don't forget to watch them, they won't be repeated live! <abrenon>i'm watching it too (spoiler: she speaks french at the begining !!) <roptat>also, I'll try to chair the first session, trying to find what to say :) <civodul>i won't be here for the 1st session, sadly <roptat>that's ok, we're all very busy with our lives :) <civodul>yeah, and i'll be traveling towards the sun, which is nice too ;-) <roptat>don't go too far, around mercury is pretty hot :p <roptat>(but nice, I also need more sun :/) <civodul>hopefully i'll chime in for the 4PM session on Sunday, we'll see... <civodul>roptat: do you plan to record the live sessions? <allana>Users of guix pack and Docker: Is there a way to set environment variables, cmd, or entrypoint of a docker image generated by guix pack? <allana>ah, so sorry, I do see that entry-point is supported <civodul>allana: for environment variables, only those that correspond to a search path get defined <civodul>IWBN to have more flexibility for these things <roptat>civodul, right now the room says so, but the blog post says otherwise. Not sure what we should do <mmorko>i am messing around with guix from few days now and i am intrigued <mmorko>i installed on my trusty eeepc and it works great <mmorko>it does start and gives me an error, i want to NOT start gdm at all <mmorko>i do have hikari wm on wayland and sway as well working great <mmorko>what is really bother me is that gdm start, throw and error and stay there lingering on TTY7 <mmorko>i am trying to not start dgm inthe last few days and whatever i do the bugger still start <AwesomeAdam54321>mmorko: I think you should remove gdm from the system configuration if you aren't using it <maximed>Perhaps you could use another login manager, say slim-service-type <mmorko>ideally i do not want any login manager <mmorko>i want to login on ttywhatever and start sway or hikari at will <maximed>mmorko: perhaps use sddm-configuration with 'autologin-user'? <mmorko>i udnerstood that gdm is started by %desktop-services <roptat>you can remove it from the desktop services <mmorko>but i need desktop services to start other functions <mmorko>i found some code snippet but i receive errors all the time <maximed>mmorko: You can remove gdm from %destkop-services and keep the rest <roptat>but (modify-services %desktop-services (delete gdm-service-type)) should do the trick <mmorko>thanks all yes i was using that from the manual but it throw eror <roptat>don't paste more than three lines on irc <maximed>mmorko: What error (including backtrace), and what is the configuration? <roptat>use paste.debian.org for instance to paste more and share the link here <mmorko>error: (%modify-service service (delete gdm-service-type)): source expression failed to match any pattern <mmorko>ok i will try pastebin for the conf <mmorko>it is strange becouse it is code from the manual <mmorko>the error from gdm is not important i do not want to start it at all so no matter why it fails <mmorko>the machine is an old one and i prefer to not have stuff at boot <maximed>mmorko: Thatcode contains %desktop-services twice <mmorko>but if i remove the second one it is still giving same error <mmorko>i saw someone suggesting sddm, i can try but for the moment i prefer to stick with the plan and not having login manager of sort <maximed>mmorko: Can you paste the modified configuration? <mmorko>i also removed xfce desktop service <mmorko>maximed you do not have any error? <maximed>It again works for me. I wonder, did you see ‘waarschuwing: the 'target' field is deprecated, please use 'targets' instead’? <maximed>That's unrelated to the observed syntax error, but if you didn't see it, that might mean you have an old version of guix <mmorko>i have done it, but i cann pull again <maximed>1.2.0 is a relatively old version, nowadays it's 1.3.0 (though you'd want the latest guix, guix is rolling release and version numbers are only a kind of milestone) <pkal>How can I find out why a package (I thought to have removed) is still in /gnu/store? <mmorko>not sure why i downloaded 1.3.0 last weekend <mmorko>so not sure why it states 1.2 ... weird <maximed>pkal: Packages are only removed from the store during "guix gc". It's not something that happens when doing "guix package -r" <mmorko>my understanding is that when you guix remove package it actually remove the links <mmorko>unless you do garbage collection <mmorko>thhius is how and why you can rollback <pkal>maximed: I know, but no matter how often I gc it is never removed <pkal>In my case ghc and the noto fonts are wasting 3-4GB constantly preventing me from updating my system <maximed>pkal: "guix gc" or "guix graph" (not sure which) has some options to ask why a store item is being considered ‘live’, I forgot the name though <maximed>Perhaps try "guix gc --referrers /gnu/store/STORE-ITEM-OF-NOTO-FONTS"? <maximed>And "guix delete-generations" + "guix system delete-generations" to delete rollback information (if any) keeping ghc & noto-fonts active? <mmorko>maximed i am running guix pull, let see the outcome, but i m quite sure i already did it <mmorko>thanks for the suggestions, i will update as soon the pull is over <sneek>roptat was in #guix 38 minutes and 37 seconds ago, saying: paste.debian.net I mean. <zimoun>roptat: do you have a moment to discuss some details about the Guix Days ? <mmorko>guix is hashed (/run/current-system/profile/bin/guix) <maximed>mmorko: Seems like the wrong version of guix is used. Has ~/.profile (and perhaps ~/.bash_profile) been set up? <mmorko>i just installed the 1.3 downloaded from the site and started to use it <mmorko>is the first time for me to try guix out <maximed>mmorko: See '(guix)Getting Started' for what to put in ~/.bash_profile <maximed>(both the $HOME/.guix-profile and $HOME/.config/guix/current things) <maximed>FWIW, I thought that ~/.bash_profile was set up automatically on Guix System <maximed>I don't know what's going on there. This step can be sidestepped by explicitely passing the full filename: ~/.config/guix/current/bin/guix/pull system reconfigure ... <maximed>"type guix" outputs the filename of "guix" that the shell will use to start "guix" <maximed>If it's /run/..., that means the shell will use an old guix. If it's $HOME/.config/guix/current/bin/guix, it's the version of guix you just pulled <maximed>mmorko: The output was /run/current-system/profile/bin/guix right? Then it's the old version. <maximed>What I proposed with ‘This step can be sidestepped by explicitely’, is for now focussing on reconfiguring the system to something up to date, and leaving proper ~/.bash_profile setup for later. <mmorko>ok i think i understand a bit, but not sure what to do now <maximed>As I understand it, you want to reconfigure the system, right? <maximed>If so, you can ignore .profile for now and do ~/.config/guix/current/bin/guix/pull system reconfigure <mmorko>sorry now i understood it was .config/guix/current/bin/guix pull <civodul>roptat: re recording the sessions, i don't know, there are pros and cons to both <civodul>i'd lean towards recording at least the BoFs and the first and last sessions <civodul>but it should be clear to participants whether or not they are recorded <civodul>(i think BBB notifies users when they log in) <maximed>mmorko: oops, I meant ~/.config/guix/current/bin/guix system reconfigure /location/of/the/configuration.scm (no pull) <roptat>yes, it should be clear when it's recorded <zimoun>civodul, recording means “video editing” (montage vidéo). I remember you have good skills and wrote a nice post about it. :-p <mmorko>maximed thanks, got it now, it is reconfiguring the system <abrenon>keep reading it over and over each time I try to do something that might be vaguely similar hoping to get some wisdom <civodul>zimoun: true, that part i consider easy now :-) <civodul>lilyp: nice talk! with bits of French, even :-) <civodul>i agree that we should provide higher-level options for the container tools <roptat>btw, talking with taiju on mastodon, it became clear some people would like to watch the talks but are not very good at spoken English <roptat>I'll need some volunteers to help create subtitles after the Guix Days :) <xelxebar>Hrm. Just guix inited a new system, which completed successfully; however, it fails to boot, with grub complaining about an unknown filesystem. <sneek>Welcome back xelxebar, you have 2 messages! <sneek>xelxebar, lfam says: Maybe we can fix your "clock is waaay off" problem by having Guix set the clock to the date of the Guix revision itself if NTP won't make such a big change, and then try NTP again. It might fix some instances of the bug, since the date of the revision-in-use is probably not more than a year old <sneek>xelxebar, lfam says: It would be great to get some more details about the case where NTP wouldn't fix the time. Like, how wrong does the clock have to be? <jpoiret>xelxebar: what fs type are you using? <abrenon>any particular software you can recommend to create a .srt ? or do you use a different format ? <xelxebar>Oh! I specifically specified luks2. That's probably it. <jpoiret>yeah, LUKS2 is still not properly supported by grub for the root partition <jpoiret>basically, it can decrypt it, but it's not able (yet) to detect that it should include the luks2-specific code in the binary <jpoiret>yes. There are 4 patches sitting in the ML that try doing that <jpoiret>including mine, since it came up quite a lot here :) <xelxebar>Also, you completely swoosh-shotted this troubleshoot. Thanks <jpoiret>but it requires restructuring a bit your mountpoints <jpoiret>basically, I mount my EFI partition on /esp, and bind mount /esp/EFI/Guix/ to /boot (not /boot/efi) <jpoiret>that way, everything that's put on /boot is available directly from the ESP, including /boot/grub/, which contains the luks modules <xelxebar>Interesting. How large is your esp partition? <jpoiret>the issue is that until GRUB is able to find the loadable modules, it's limited to what's compiled in the initial image <jpoiret>256M total with 41M used (and I have a certain non-free OS's bootloader on there as well) <jpoiret>the issue is that it's not possible to do it that easily with non-EFI setups, as it requires an extra partition, whereas here you just re-use one you already have <xelxebar>Makes sense. There's a small bit of chicken-and-egg going on. <xelxebar>Is luks2 kept in a module because it would make the grub blob too large or something? <xelxebar>Also, any reason why you do the indirect bind mount and not just directly mount to /boot? <jpoiret>basically LUKS1 and LUKS2 code are in the same GRUB module (cryptodisk is the name I think), it's just that `grub-install` is able to detect that it should embed it in the binary only when LUKS1 is involved, not LUKS2 <jpoiret>I do the inderect bind-mount so that everything is organized neatly in the EFI partition <xelxebar>Cheers. Thanks for the crystal clear rundown. <cbaines>any tips on using gdb to debug segfaults during builds? <cbaines>all I seem to be doing in attempting to use gdb is get the daemon to hang <sughosha>Hi #guix! Just now I ran `guix gc -d` and cleared GBs of the store. At last, it is saying "note: currently hard linking saves 4496.69 MiB". Is it saying that still around 4 GiB garbage left? If so, can I clear them too? <roptat>no, it's *saving* space, not wasting it <jpoiret>sughosha: hard links that remain after guix gc are not garbage, but rather files in multiple store outputs that are hard linked together <civodul>cbaines: segfaults of the thing you're packaging, right? <roptat>sometimes store items you need contain identical files. Instead of duplicating them, guix hard-links them so there's only one copy of them. This sames 4GB in your case <xelxebar>cbaines: Interesting. I have been seeing segfaults during builds as well. Is the build falling over consistently at a specific place? <cbaines>I'm guessing this could be something to do with the guile 3.0.7 to 3.0.8 upgrade <cbaines>I can reproduce it consistently on multiple machines, just not outside the guix-daemon yet <civodul>cbaines: right, so guix-data-service is segfaulting, not guix-daemon or guix <jpoiret>if so, you should be able to debug the core post-mortem with gdb <civodul>the above data.guix.gnu.org URL is unreachable for me <apteryx>rekado_: I've made a patch adding rootflags, which should give us some flexibility to try things at the GRUB level (e.g. to specify a device=/dev/sda3,/dev/sdb3,... option string). Unfortunately it doesn't pass tests yet. The branch is wip-initrd-rootflags. <cbaines>civodul, the URL seems fine for me, what problem do you see? <civodul>hmm now i do with IceCat, but not w3m <form_feed>I'm getting `guix upgrade: error: profile contains conflicting entries for` for the first time. How to properly handle this? I have already deleted a couple packages but new ones keep popping up. Actually, what's happening? <cbaines>unusual, maybe try https rather than http (not sure why that would make a difference) <civodul>cbaines: to debug that, i'd build the thing with -K until i've hit the segfault, and from there i'd run gdb on the core dump <civodul>now, you need to change the rlimits so that there actually is a core dump <civodul>so in a build phase, you do: (let ((MiB (* 1024 1024))) (setrlimit 'core (* 300 MiB) (* 500 MiB))) <sughosha>I need one more help. When I run `guix gc` and then perform upgrade, so many packages (especially so many "rust-...") get download, sometimes also compile locally, which take a day or more sometimes. Is there a way to only remove the previous generations' files and leave all the "native-inputs" of installed packages? <sughosha>This also hapens if I reconfigure the system. <jpoiret>do you need to set the rlimit in a build phase because the limits aren't inherited by other namespaces? <jpoiret>sughosha: I don't think there's an easy way to do so currently <jpoiret>when i'm tight on store space but need to run guix pull, I usually check the size of store items with ncdu and try removing the bigger ones, then `guix pull`ing, then `guix gc` <AwesomeAdam54321>sughosha: To delete packages from all previous generations you can do `guix package --delete-generations` <sughosha>But that doesn't delete files from store, right? <sughosha>Yes, I use `guix gc -d` to delete altogether at once. <sughosha>@jpoiret: By "removing the bigger ones", do you mean generations? <abrenon>maybe if you know you plan on upgrading right after, you could ask guix to free only a small amount of disk space ? <abrenon>guix gc accepts a PATHS argument, see: guix gc --help <jpoiret>although it might not work with your use-case (I often have big `guix system image`s in the store that sit there for no reason) <sughosha>Can `guix gc` be run selectively like that? <jpoiret>although it will refuse to remove any living path <sughosha>Oh ok. Thanks for that. This is probably the nearest for what I was looking for. <abrenon>but more generally, it is a bad practice to gc right before upgrading <abrenon>you should rather do it the other way round <sughosha>Ya now I realized that, after wasting 3 days doing the same mistake, waiting for around a day and figuring out why the hell it is downloading again and again even if I don't `guix pull`. <jpoiret>building rust locally is a Guix rite of passage <sughosha>Why does rust get built locally? rust and webkit2gtk both. <cbaines>sughosha, can you share some of the derivations you keep having to build? <jpoiret>well, there should almost always be substitutes for those, but maybe you can't download substitutes for some reason <AwesomeAdam54321>sughosha: Because rust takes a long time to bootstrap, and when substitutes aren't available they are built locally <sughosha>cibaines: I have just deleted the previous generations. <cbaines>just the names of the derivation files is fine <sughosha>"guix 0955ec3". Is this what you were asking, cbaines? <jpoiret>sughosha: no, rather the output of `guix build -d rust` <cbaines>the useful command is: guix build --no-grafts -d rust <cbaines>since you want the derivation for the package, rather than the derivation that grafts things <cbaines>that also shouldn't download anything <sughosha>Ok. It's "/gnu/store/bn6m6wqfqlbi5hkw6m4mbcz3qh76h65b-rust-1.57.0.drv" <cbaines>there should be substitutes for that derivation, so you should be able to download them if you run guix build --no-grafts rust <cbaines>if you run guix build rust, it'll do some grafting locally, but that's usually pretty quick <sughosha>Ok. Thanks. This would save so much of time for me. <jpoiret>that should all happen when reconfiguring though, so I don't think the problem is gone <paul_j>Good afternoon guix! I am working on a channel of my own, but while testing it thermald has stopped building with an error (unrelated to my channel). The werror has resulted from "-Werror=depricated-declarations", and a deprecated function in the thermald source. How do the compiler error settings get made? <cbaines>civodul, jpoiret I'm building with the setrlimit thing now, and I get this output: Segmentation fault (core dumped) <cbaines>but I don't know where it's been dumped? <sughosha>jpoiret but once it pulls the substitutes doesn't it just use them for system reconfigure instread of buildig again? <jpoiret>I think it should be dumped in the cwd of the program that segfaulted <cbaines>hmm, I can't see anything in the build directory <rndd>hi guix! is there way to generate manifest of installed packages wich i can later use to install them again? <civodul>cbaines: ... unless you're on a distro such as Ubuntu that has core dumps carried over to some place in /var or /run <jpoiret>rndd: yes! with `guix package --export-manifest` <jpoiret>cbaines: you should check `/proc/sys/kernel/core_pattern` <cbaines>jpoiret, that says /tmp/core-%e-%s-%u-%g-%p-%t <jpoiret>mine is `core`, but it can also be an absolute path <cbaines>I'll change it to core and try again <jpoiret>oh right, i don't think you can access the build's /tmp post mortem <civodul>apteryx: hi! re wip-initrd-rootflags, it'll be a bit more complicated than this, because you still want to be able to boot older generations <cbaines>Ok, I think that's worked! I have a core file <civodul>apteryx: so what that means is that we'll have to first record all the flags to the "parameters" files <apteryx>civodul: hi! eh, I always neglect that part (the parameters), because I don't quite understand its role :-) <mbakke>isn't the "root" Linux argument mainly for initrd-less "automagic" boot style setups? should we be "messing" with it? <apteryx>mbakke: seems the root argument is honored both by initrd and the kernel itself (when used without initrd) <apteryx>in our case it wouldn't really matter since we use an initrd and root will already have been mounted, so I'd expect the kernel to ignore the option <cbaines>civodul, jpoiret I think I've got gdb opening the core file now, although I'm not sure the backtrace provides much information, apart from the segfault probably happens in some jit related code https://paste.debian.net/plain/1231401 <cbaines>is there anything specific I should include in a bug report? <apteryx>haha, I think I've found the problem with wip-initrd-rootflags; the (if root-device ...) condition I touched; I flattened and that's wrong <apteryx>I should have dropped the 2nd branch of it <apteryx>or is there a use case of using our initrd without any root file system at all? <jpoiret>looks like it's erroring while trying to display a backtrace <jpoiret>although that's not the root cause of the SEGFAULT :p <jpoiret>i think the people over at #guile will be able to help you help them <apteryx>civodul: I don't see where changing '--root' to 'root' in the initrd affects the parameters file; it records the root file system as a distinct "root-device" <apteryx>am I the only one for which debbugs.gnu.org seems sluggish? ***GNUtoo_ is now known as GNUtoo
<apteryx>jpoiret: thanks; it does seem OK through the web interface; it's through emacs-debbugs that it isn't working well for me <apteryx>(currently stuck on 'Get bug numbers...') <blacked>guys i want to contribute to guix but i it is far away , nobody would recognize me oh i contributed that. <blacked>although i dont wanted to get fame by contributing on this and that project, but sometimes useful in getting jobs if not. <blacked>i was thinking why guix choose `guile` instead of `common-lisp` ? <jpoiret>Guile is the official GNU extension language <apteryx>blacked: hi! for the record, we prefer more inclusive language such as "folks" or "guix" rather than "guys" around here :-) <roptat>and the language is not that important; package descriptions are usually pretty far from the usual guile program <blacked>apteryx umm right i also like to use inclusive language, but everywhere on the internet and most people are just retarted by nicki minaj anaconda. <blacked>folks it would be great if guix have torrent distributions while downloading ? <roptat>.it's not always easy to get rid of old habits, but really we're not all guys here :) <roptat>it could be nice indeed. I think it just never came up at the right time (before a release) <roptat>oh, I was thinking the release tarball/the iso <roptat>I don't know what kind of setup we would need to make that work already <roptat>I think they both will require a very different setup <roptat>for once, we would need a bittorrent client in guile to have substitutes over bittorrent <abrenon>doesn't that exist already per chance ? <roptat>(I actually looked into it in the past, bittorrent is fun but hard to implement properly) <blacked>`need a bittorrent client in guile` :/ is guile really a turing complete ? <blacked>how much mature is it ? does it have guis? <roptat>there's guile-torrent, but it's limited to parsing .torrent files <singpolyma>roptat: given how good guile FFI is would a torrent in C not be usable if desired? <Kolev>abrenon: Telephony over copper wire. <roptat>I only know of libtorrent which is in C++ <roptat>that might work. reimplementing in pure guile is more fun though :) <abrenon>oh, thanks I didn't know the term (I thought it was an acronym like "LGTM") !! <Kolev>I wish writing GTK apps in Guile were easier. <blacked>i could contribute something by learning it , but you are away in different world <abrenon>why ? how is "our" world any different ? <singpolyma>Kolev: yeah, like a port of the racket gui system to guile? <jpoiret>Kolev: GTK is quite idiosyncratic to be honest (most big GUI toolkits are) <apteryx>I think it might come handy at the GRUB prompt on Berlin if it fails to boot again the next time we try <blacked>abrenon you have seperate git repo, going to it , sigingup ,learning about that environemnt, is bit hard for common people like me <blacked>although hate to say, but today popular is github, mirroring the site on github everytime , allowing all people to contribute would be a greatest idea <jpoiret>it has its own refcounting mechanism, along with object system. guile-gi might help you though <abrenon>I get your point but there are really good reasons to have our own servers, especially in a world where Microsoft owns github <vivien>guile-gi is quite good, but I wish there were examples about how to subclass gobject classes <abrenon>but really I hate to read you call yourself a "common people": all of us are, and I feel your use of the term quite self-deprecative <Kolev>jpoiret: I couldn't understand G-Golf, or how to use it on a Guix system. <blacked>abrenon i dont mean , removing own server, i was saying just put mirror to listen to place where every population reside. :) <abrenon>if you mean it as something that inherently stops you from doing what you want, please stop believing that, and don't ever let anyone make you feel like that <blacked>oh i thought you guys are genius so i told myself common but anyway , thank you everybody are common :) <blacked>oh i've downloading and trying guix, it is taking like 3 hours <abrenon>anyway, even if you had as much to learn as you say, well, learning never is a waste (plus it's fun — most of the time) <civodul>apteryx: for old generations, you'll need to pass "--root=DEVICE", whereas for new generations, you need to pass "root=DEVICE" <apteryx>civodul: on place where the new "root" gets written is in the grub.cfg config; which could be problematic for booting older generations <civodul>(you can end up generation a grub.cfg that contains entries for both new and old generations) <civodul>so i think the way to go is to have everything in the 'kernel-arguments' field of "parameters" <civodul>and then, have a compat shim that check whether there's "root=" in there; if not, append "--root=DEVICE" <civodul>it's a good idea to remove those "--" anyway :-) <civodul>we can also replace "--repl" with "guix.repl" or "gnu.repl" <apteryx>perhaps, for consistency! although these don't have their equivalent in Linux so nobody has an expectation on them, and it could be argued that having them prefixed by '--' makes that more obvious <apteryx>but I think I prefer consistency :-) <paul_j>Good afternoon all. I am getting a build failure on thermald. It has been working all morning (I am doing some work on my own channel, and therefore reconfiguring my system repeatedly). The build failure suggests the compiler option -Werror=deprecated-declarations has now been set. However, I see no code changes to the guix repo, nor the thermald repo which could have made this change. Where should I look next? <apteryx>so the parameters file is used to keep per-generation kernel command-line arguments, that complement what's in grub.cfg? <jpoiret>paul_j: it's possible that a new gcc version is the culprit, however that issue would have already cropped up 2 months ago <jpoiret>also, maybe an update to the package brought a new compiler flag into eg the makefile <paul_j>I don't see any changes to the thermald code in their github repo. The version number certainly hasn't changed, but of course I understand that is not always a good indication of when code changes! <paul_j>It feels like there is some sort of global change being made somewhere which has caused this. <paul_j>...but I can't see any changes to the guix repo either which could be responsible (at least not today). <jpoiret>you could try bisecting the change that caused this issue? <rekado_>it doesn’t mention “guix shell” and still refers to an older version of Guix. <mroh>apteryx: I think that's a great patch set, ty! I need something like that for my root-on-lvm experiments/patches... <apteryx>mroh: OK! you might want to wait a bit for the 1/3 commit though, as I think it'll break booting an older generation <paul_j>jpoiret: I've never done that before - guess I had better go and read up how to do it! <jpoiret>well, the issue is present on other distros <jpoiret>I'm looking into it, no need to bisect yet I think <jpoiret>alright, so it's the update from upower 0.99.13 to 0.99.15 <jpoiret>that's commit b3d7eae08ee71674ebcf6c6dc5ef575f35493240 <djeis>So I managed to PXE boot a guix system with an nfs root, with a little bit of bodgery involving busybox's udhcpc, but now I'm trying to mount the store separately from the root fs and I'm running into an error from the getaddrinfo call in gnu/build/file-systems: "Servname not supported for ai_socktype". I'm using a raw IP address for the nfs server, but am I right in there not being a simple way to skip that call? And, are there any suggestions for how <djeis>to deal with that error? From the searching I've done it feels like something to do with the limits of the initramfs, which wouldn't surprise me given my aforementioned hacks to even get network access there in the first place. <jpoiret>the function is newly marked as deprecated which is why it fails <paul_j>That makes sense. So I should have dug around to see where the offending function is defined then. <abrenon>djeis: what you're attempting is so cool ! <abrenon>so would the store also be mounted from NFS ? <jpoiret>paul_j: it seems the issue is not resolved upstream, i don't even see one open <paul_j>Should I post an issue on their github page then? <jpoiret>well, I don't see anything that would cause -Werror=deprecated... on their side, so it should still be able to compile <djeis>abrenon: That's the theory. If I get it right I'd like to use a central guix daemon with an nfs-shared store for a bunch of netbooted machines. <paul_j>So is the compiler setting a guix setting then? <jpoiret>maybe, i don't really know where this could come from <djeis>As I said, I already managed to use the grub-efi-netboot bootloader and a PXE server to netboot a standalone root+store. Now I'm trying to have the initramfs mount the same store as my main build daemon but separate from it's root fs. <djeis>Perhaps I'm insane, but from the success others seem to have using guix in cluster environments I feel like it ought to be doable. <paul_j>I guess the other question for me is why did it work at all today? I have been running guix pull and system reconfigure successfully several times this morning, but the upower update was made uesterday. <jpoiret>well, the commit was made yesterday, but maybe it was merged later today <paul_j>Ok - that makes sense. That means this time the problem isn't with my system configuration! <jpoiret>djeis: someone more experienced than me should weight in on this, but your store shouldn't be shared between guix daemons <apteryx>unless the daemon is also shared via the GUIX_DAEMON_SOCKET trick <djeis>One daemon, client machines all talk to that central daemon using either the tcp or ssh comms methods. <jpoiret>oh, right, you'd be offloading to one machine? <djeis>Not offloading, just GUIX_DAEMON_SOCKET. <djeis>Offloading would be multiple daemons- might do that with a little local build farm eventually. <djeis>But not shared stores between them ofc. <mmorko>hello again, i had some help before on my issue with gdm, and now it is solved. But apparently i have another issue <mmorko>the command "type guix" return the following guix is /run/current-system/profile/bin/guix <abrenon>djeis: don't know enough about network mounts to be helpful please document thoroughly your failures and successes, I'm very interested in the idea of netbooting guix instances <djeis>abrenon: I'll see what I can do :) <jpoiret>djeis: do you know when the rootfs is failing to mount? <djeis>jpoiret: I'm actually using a tmpfs for the root in this test- if I have everything in a single nfs share and mount that as the root I can get it to work. <jpoiret>do you have some configuration snippets? <djeis>The trouble is when I mount the store as a separate nfs share. <jpoiret>it seems weird that it's the getaddrinfo part that fails <djeis>It's a bit of a mess, I admit. <djeis>And I probably need to correct some of the options for the nfs mount- when doing an nfs mount for the root you have to pass the addr= explicitly yourself since that code wasn't integrated in to the mount root routine in linux-boot. <djeis>You'll also have to my custom mapped-device hack to run udhcpc. <djeis>I'm trying my best to avoid having to write my own version of linux-boot altogether, but I suspect I'm getting to that point. <djeis>From some searching it sounds like getaddrinfo implicitly depends on an /etc/services file, which isn't present in the initramfs. <djeis>Yea, if it used gethostbyname or getaddrinfo without the "nfs" service arg it'd be fine- just tested in the initramfs emergency repl. <djeis>And I don't think the code in build/file-systems is actually using the service info. <philip>Is there a package I can install to get a local copy of the Guix manual as HTML (as oposed to info)? <djeis>I wonder I can solve this in the short-term with a dedicated root+store on nfs, as I was doing before, but then mount over the dedicated store with the shared one once past the initramfs... <xelxebar>sneek: later tell lfam, 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 <gnoo>hmm, i think there's a bug on guix shell <gnoo>i basically can't use it for anything. guix environment works <gnoo>i think it's pkg-config related, can't buid emacs <gnoo>with guix shell -D emacs <mroh>sneek: later tell philip, I don't think there is a package for that (a 'doc' output for guix might be an idea, though), but you can `guix shell -D guix -- make html` in a guix git repo to generate html doc. <gnoo>also, what package provides curses.h ? i tried inside 'guix environment --ad-hoc ncurses' and make is complaining: `fatal error: curses.h: No such file or directory' (not emacs, something else) ***form_feed is now known as \f
<jpoiret>gnoo: guix shell and guix environment have most of their code in common <jpoiret>they should use the same guix profiles <gnoo>this is what i get for guix shell --check -D emacs: guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell environment <gnoo>but i just compiled emacs from source with guix environment <gnoo>GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of 2022-02-18 <gnoo>finally, hot and shiny emacs <jpoiret>you can check the env variables manually <jpoiret>theoretically, the env vars set by shell and environment should be the same <jpoiret>is PKG_CONFIG_PATH actually missing from inside guix shell? <jpoiret>from inside the shell, you can also do `cat $GUIX_ENVIRONMENT/etc/profile` to see which variables will theoretically be set in the shell <gnoo>hmm, no, but i can't compile for some reason... <gnoo>PKG_CONFIG_PATH=/gnu/store/8718c70hzyrg80jv2g3pshj12bzgvjhq-profile/lib/pkgconfig:/gnu/store/8718c70hzyrg80jv2g3pshj12bzgvjhq-profile/share/pkgconfig <jpoiret>what's the exact issue you're running into? <gnoo>ok well now i can, but previously couldn't <jpoiret>djeis: sorry, I was away for a little while. linux-boot is in dire need of modularity, but that'd require some work <lilyp>civodul: re racket I'm only doing review on a machine without commit access atm. This shouldn't be an issue, because I'll have more time next week to apply them, but someone else could take over if it falls into my office hours <lilyp>sneek later tell civodul re racket I'm only doing review on a machine without commit access atm. This shouldn't be an issue, because I'll have more time next week to apply them, but someone else could take over if it falls into my office hours <lilyp>sneek later tell civodul i don't think v2 can be pushed as-is, but I expect v3 can. If you disagree and say v2 is fine, though, I'm not going to gatekeep. <vldn>Someone successfully used xtensa-lx106-elf-g++? I made a platformio package (http://ix.io/3PXM) but everytime i run "pio run" it say xtensa-lx106-elf-g++ not found, even if the file exists (downloaded from pio run automatically on first run) in ~/.platformio/packages/toolchain-xtensa/bin, ldd shows this: http://ix.io/3PXZ , so everything seems to be linked.. maybe a 32bit userland is required or <vldn>something? "file" shows ELF 64 Bit executable .. <djeis>jpoiret: No worries :) if you (or anyone, really) could think of a better solution to doing initramfs dhcp than my busybox hack that alone would clean up a lot of what I'm doing. Ultimately this nfs store trickery is far from necessary since I can do nfs for the root. <jpoiret>i think your busybox hack is the way to go for now <jpoiret>it's just, having to use it through a mapped-device like this is pretty ugly <jpoiret>you need to setup through DHCP, so you need a DHCP client, seems ok to me <djeis>Yeah, but I can't think of another way to sneak my own code in to the initrd that doesn't involve me reimplementing base-initrd. <jpoiret>oh for sure, it's just too bad that it's the only good solution to this <jpoiret>apart from rewriting the booting process <jpoiret>i'm interested in this as well, but have been working on other things for now <jpoiret>maybe it's something we could discuss in the Future of Guix on Sunday :) <djeis>Oh I hadn't heard about that- I'm only recently getting involved in the guix community to be honest. <djeis>I am interested in getting more involved though. <jpoiret>well, the guix days are the perfect occasion <djeis>I'll try to be around for it :) <batalie>is there a list of programs/services guix home import picks up? i guess i could read the code, but i don't have the guix repo cloned on this machine :) <batalie>mine only picked up bashrc and i think there should be at least 1-2 more.. <apteryx>which procedure is responsible for writing the system/parameters file? <lifestronaut>I'm trying to install guix, and I'm at the "guix system init <path to config.scm> /mnt" step. I'm getting a large error and I can't figure out how to scroll back in the terminal to see what the error is. How do I scroll through text in the terminal? <lifestronaut>FlaminWalrus: When I use less, it scrolls to the end of the wall of text. When I push the up arrow, it erases everything and leaves a column of tildes ~ in the first column <lifestronaut>I've tried the >> operator to pipe the output into a file, but that didn't work <FlaminWalrus>lifestronaut: try vim/Emacs scroll bindings perhaps? less can break with more complicated program outputs. The redirection operator is > iirc; not sure what >> might be doing. <rekado_>no wonder our aarch64 builds largely fail: while setting up the build environment: a `aarch64-linux' is required to build `/gnu/store/0hc7inxqcczb8mq2wcwrcw0vd3i2agkv-llvm-11.0.0.drv', but I am a `x86_64-linux' <rekado_>looks like the qemu emulation is still set up and isn’t actually working <djeis>lifestronaut: You need to capture the output of stderr, not stdout. ***iyzsong- is now known as iyzsong
<djeis>A simple way would be to redirect stderr to stdout, i.e. guix ... 2>&1 | less <apteryx>rekado_: on berlin, there doesn't seem to be any misc_binfmt registrations: /proc/sys/fs/binfmt_misc/ is empty <rekado_>apteryx: no, on the build nodes connected to berlin <rekado_>I’m redeploying to the build nodes now <apteryx>were you able to fix the deploy bug deploying x86_64 binaries to the aarch64-linux machines? <rekado_>I just don’t use deploy for those machines <rekado_>not great, but I really need to use my desk for other things soon, so I want to get them ready for the move :) <rekado_>(also: electricity got stupid expensive recently; I’d much rather have them use MDC electricity…) <rekado_>I think I’ll move them some time next week already. <rekado_>only one of them at first to see if it all works <lifestronaut>All that trouble to discover I had a parenthesis in the wrong place... ugh <rekado_>lifestronaut: this sucks… :-/ A well-configured editor can help there, but sometimes it’s just the wrong grouping. <lifestronaut>It's the nonguix iso, whichi I assume only has whatever is on the guix iso by default <lifestronaut>I was using nano, but I should have attempted to use emacs <apteryx>I'm thinking to handle gracefully renaming our kernel arguments, it appears best to bump the version of the boot-parameters record and determine the course of action based on it. <apteryx>that way when reading old parameters file, we'd be able to say 'ah, so this is for a generation that didn't understand parameter Y' and adjust the grub config output to use the legacy parameter X instead. <vivien>sneek, later tell civodul my gcrypt ECC problem was because I did not set the rfc6979 flag in the data sexp, and I used "dsa" as a signature type instead of the expected "ecdsa" <FlaminWalrus>I'm migrating to Guix after cryptic breakage of my Gentoo X server on Sunday night. Quick question: can one modify %base-packages in the same way as %base-services? <acrow>FlaminWalrus: %base-packages is a scheme symbol just like %base-services is and so the same principles apply. ***zimoun` is now known as zimoun
***zimoun is now known as 047AACB9C
<acrow>FlaminWalrus: Even more precisely, both of those symbols point to scheme lists. <vldn>someone uses ArduinoIDE or xtensa-esp32-elf? <jeko>Hey Guix ! I build my profile using a manifest containing "guile". And I have a package with guile-3.0 in inputs. I my profile it is Guile 3.0.8. When I guix shell my-package I get Guile 3.0.7. which guile package should I put in my inputs to get the same as in my profile ? <stikonas>I don't know the origin of the term though <rekado_>hey, I got a rockpro64 board with SATA adapter and just installed a minimal Guix System with u-boot on an SSD. <rekado_>does anyone know how I can make the board use the u-boot on the SSD? <rekado_>it boots from a uSD card with armbian <stikonas>and it can't directly boot if you installed on SSD <rekado_>I’m a u-boot noob. Can I chainload u-boot? <stikonas>so on rockpro64 u-boot comes in 3 stages <stikonas>first is very small stage (TPL) that initializes RAM <stikonas>then there is secondary stage (SPL) that still has to be on of of those 3 media (emmc, spi or sdcard) <stikonas>I think it should be possible to load third stage from somewhere else... <stikonas>but I think that would require specifying it in u-boot config during compilation <stikonas>you can chainload form third stage u-boot on (emmc, spi, sdcard) to another bootloader on SSD <jeko>podiki[m]: oh wow haha I was about to do a sudo -i then a guix pull haha <stikonas>that should also work and is probably simplre <stikonas>rekado_: you can even install grub on SSD <jeko>podiki[m]: could it help if I reproduce ? :') <stikonas>so u-boot becomes kind of UEFI implementation <podiki[m]>jeko: I'm sure they will appreciate that (I'm not involved with that bug but did remember seeing it discussed here the other day too, if you want to search the logs) <stikonas>rekado_: third stage u-boot has a default configuration that scans boot media for ESP partitions and boots EFI/BOOT/BOOTAA64.EFI file <stikonas>rekado_: hopefully that gives you some ideas/things to try <jeko>podiki[m]: I will avoid to guix pull as root right now and see if I can bring useful info in the bug tracking <stikonas>rekado_: do you have uart adapter? that's useful for boot debugging <jeko>podiki[m]: thank you for the pointer! <rekado_>stikonas: I have one but I’d need to figure out where to connect it to first :) <jeko>sneek: later tell acrow: in deed! I wanted to have a disposable system to throw away after each pair-programming session. appreciate your consideration ! ;) <FlaminWalrus>How does one compare packages by name? I'm debugging (lset-difference eq? %base-packages '(sudo nvi nano wireless-tools)). Comparing the value of e.g. the sudo symbol by evaluating (%base-packages) and (sudo) in a guile REPL yields different objects. eqv? didn't seem to work either. <cbaines>FlaminWalrus, maybe compare against the names of the packages, rather than the record <cbaines>also, package names are strings rather than symbols <the_tubular>Is there something like docker network for guix container ? <cbaines>FlaminWalrus, you could also change the other side of lset-difference and use a list of packages, rather than a list of symbols