<podiki[m]>I wonder if the cookbook fits more for newcomers but then leave it behind? <podiki[m]>(although now I see a direnv section that looks handy) <lfam>It's definitely full of useful information <KE0VVT>OK, time to `guix system reconfigure` and `guix home reconfigure`… I hope my laptop does not explode. <lfam>And so we had to spend a lot of time re-documenting a private interface <nckx>KE0VVT: If it does, attach photos to your bug report. <lfam>We should try to avoid letting that kind of thing happen <podiki[m]>is there any "automatic" way of seeing what is referenced by the manual or cookbook? e.g. the code tags, and seeing if that is touched by a commit to guix? <lfam>It's a good question and I don't know the answer <podiki[m]>...I realize this describes the autodocumentation tools somewhat <nckx>Do we have a checklist for patches? An actual, tedious-to-read, checklist. <lfam>As a reviewer, I just grep the manual and ask for revisions that adjust things appropriately <lfam>And after this many years, I know what to look for <podiki[m]>what about as part of guix lint? such as "<..> is being modified which occurs in manual section x and cookbook chapter y"? seems possible...? <podiki[m]>so you change a package that is used in an example (say network-manager for nmtui!) and you can look if that would need an update in the manual for setuid or network services <nckx>Does guix lint handle diffs? <nckx>M-hm. How do you mark (possibly unneeded) modifications as reviewed? <podiki[m]>I'm thinking really simple to start, like @code{thing} is in the manual and you edited something in the define public thing <nckx>I'm not a heavy user of such hooks. <nckx>I think that is the extent to which a commit hook can be useful. <nckx>Maybe it's OK if it doesn't shut up on false positives. I'm just a bit concerned about training people to ignore lint output. But maybe it would not be an issue! <podiki[m]>then when you go to submit your patch, you can say "i checked where this is in the manual and no change needed" <lfam>I think that we will be happy when enough people use the linter that ignoring it becomes a problem <nckx>Git hooks are, I think, a bit of a pain to manage. Every user has to enable them by hand. But please tell me I'm wrong. <lfam>It's the most common feedback I have on patches. "The linter says this, the linter says that" <podiki[m]>perhaps a curated list of watch words to start <lfam>Well, I wish that people would lint their packages <lfam>Many people skip that step <lfam>But the linter catches minor issues, for the most part. It's great that people send patches, one way or the other <lfam>Some aspects of the linter are a bit obscure, too <lfam>Like, "synopsis should not start with an article" <lfam>It's quite a fine point of English grammar <nckx>lfam: You mean it should say ‘a/an’ instead? <lfam>Yes, it should say what an article is. At least in the US, most people would not understand what it meant <nckx>lfam: What's AmE for it? <nckx>Or, indeed, just spell it out. <lfam>What I mean is that people don't learn the language to such a degree that they have a word for words like "a" and "the" <lfam>I think adding a parenthetical with (That is, "a", "an", or "the") is enough <lfam>sailorTheCat: Hm, that's no good. Are you using Guix System or Guix on another distro? <lfam>Can you share the "commit" from `guix describe`? <podiki[m]>productive chatting with you all! I must move before I turn into....something stuck to a chair, whatever that is <lfam>Next time please just share the "commit" sailorTheCat <lfam>I can confirm the lack of text <podiki[m]>lfam: just a quick look, but is a good improvement to me, thanks for taking care of it! <lfam>Thanks podiki[m]. See you later <lfam>sailorTheCat: Can you try `guix package -p ~/.config/guix/current -l`? Please don't paste the output here. Look at the list of generations, specifically look at the generation that is before the current one <lfam>And share the line that starts with "+ guix ..." <lfam>Anki used to work before you updated? <rekado_>jlicht: with ST_NLINK_TRICK unset, xelatex finds its fonts, but pdflatex still isn’t happy <rekado_>it does encounter the font file, though <lfam>sailorTheCat: Hm, I compared the anki packages before and after your update, and nothing changed for anki. So, it must have broke earlier than that <lfam>sailorTheCat: Can you send a bug report to <bug-guix@gnu.org> giving the information that you shared here? <lfam>In the meantime, you can do `guix package --rollback` to get your old anki <lfam>Let us know if that doesn't help <dcunit3d>so i got all the way through the libreboot's Encrypted Guix guide for the first ime... and my password manager likes to do things like forget new passwords if you let it idle ... so it forgot the root password <dcunit3d>SMDH ... the only problems i hadn't fixed yet were related to the slim login command AFAIK <florhizome[m]><lfam> "It could also go in the cookbook..." <- I really don’t understand this cookbook thing. ^^ also more of a tradition. Not saying that there is not useful stuff in there. <lfam>It's supposed to be kind of like the Arch wiki. Like, instructions for accomplishing specific tasks on Guix <batalie>is anyone using anki with an up to date guix (system)? after an update all text has suddenly vanished (i.e. opening the "about" screen just shows a totally blank window).. possibly a qt or font problem? <batalie>it's the only qt program i use so that might be it <lfam>batalie: sailorTheCat just reported the same problem <lfam>We are still trying to figure out in which revision of the Guix distro it did work <lfam>Can you look at `guix package -p ~/.config/guix/current -l` and see which old generation provided the working anki? Presumably, the previous one? <rekado_>jlicht: I’ll also play with a fix for #51252 / #52268 on the branch before pushing it. <batalie>mine definitely worked in guix commit 8fcf947591413a92432da605c8da11375b612bc3 <rekado_>doesn’t feel right to push this change when it doesn’t change the outcome for pdflatex <lfam>batalie, sailorTheCat: Do you know where anki stores its data? Such as, ~/.config or ~/.cache ? <batalie>lfam: ~/.local/share/Anki has everything, i think <dcunit3d>lfam batalie i just had the same problem with QuteBrowser yesterday <lfam>Is there a bug report for that dcunit3d? <dcunit3d>i don't know. i wasn't sure if it was a problem with my system. it was only happening on one laptop, but affected most websites i would try to load. even the fonts for the devtools were missing. i didn't have time to look into it then <dcunit3d>i tried `guix pull` and ensuring all fonts were installed, but didn't check much else <lfam>So, if I use `guix time-machine` to try anki from that commit batalie, I see the same problem <lfam>For example, `guix time-machine --commit=8fcf94759141 -- install anki` <lfam>So, I think the problem must be somewhere else <lfam>sailorTheCat: Thanks, I have both of them too <lfam>I'm deleting them between tests of different Guix revisions <florhizome[m]><podiki[m]> "florhizome: I would like to..." <- Could you not have some basic checks against that? I mean the commit field becomes basically useless, you could write *anything* in there.. <florhizome[m]>Is this possible: the source changes via git rebase, but the fetched commit stays the same; thus you would get a different hash but as long as you don’t notice this by yourself and the old derivation is in the store you stay with your old version. <lfam>florhizome[m]: To clarify, this isn't specific to origins based on Git. You can make this happen with any type of origin <batalie>i can provide the list of packages that upgraded when i did that guix package -u, but i don't upgrade especially often so it is quite a lot <batalie>interestingly it includes every font i've installed <lfam>florizhome[m]: For example, fetch an origin that uses url-fetch, and then change the URL. Then try building the source again. It should be a no-op <lfam>My name starts with a lowercase L, btw <lfam>I'm not telling you that it makes it better or worse <lfam>Just that details of Git are not relevant <lfam>The point is that the source is described by the hash. Every other aspect of the source is just to help find the thing if it's not already available <florhizome[m]>I am not trying to be more sophisticated then I am, you know <lfam>That's what we mean when we say "URL": Uniform Resource Locator <lfam>The URL is just to locate the resource <lfam>But the resource is properly identified by the hash <lfam>Yes, of course. We go in circles <lfam>We explain over and over what is going on, and even discuss ways to improve the documentation <lfam>Hm, good question. It has so many benefits that it's hard to pick one <lfam>The only drawback is that people have to learn this one thing <lfam>I'd say the biggest benefit of this content-addressed cache is that it insulates us from things disappearing or moving on the internet, which happens <lfam>But it also obscures it somewhat, and we might not notice for a while <florhizome[m]>How about turning it off or checking gradually/incrementally against caches with the same hash <lfam>You can check with `guix build --source --check` <florhizome[m]>depending on where you are it is not a very long part of a build <nckx>florhizome[m]: Which problem are you trying to solve? <nckx>No. Just answer my question. <nckx>dissent: Guix is invoking the ./bootstrap script expecting it to set up the build environment (e.g., it could run autoconf/make to generate ./configure) but here ./bootstrap is a hand-written script that goes on a rambling conversation with a human. That needs to be avoided somehow. <batalie>this reminds me that i need to work on my package for wordgrinder, the only program i'm still missing from debian (main) <batalie>but the makefile is strange and i don't have much scheme-fu <nckx>What's particularly problematic about it, batalie? <nckx>My, er, ninja-fu isn't great but maybe I can give a hint. <KE0VVT>Guess I had to ref. `(gnu packages wm)` since I added Swaylock to `%setuid-programs`… <florhizome[m]>I was basically asking if there could not be a little bit of mitigation against your origin not being your hash, and just using the wrong thing over and over. <nckx>There should already be. git-file-name. <batalie>nckx: maybe what i was running into was a ninja thing, but the guix build kept throwing up an error "ninja: error: unknown target 'install-notests' <batalie>even though that target is not in the makefile <batalie>i don't know much about ninja either <nckx>Constructs a file ‘base’ name from its {name revision commit} arguments. <batalie>oh haha whoops, *i* put that target in the package def i was writing because i actually kept getting this ninja: error: unknown target 'all', did you mean 'dev'? <nckx>florhizome[m]: So you could still run into situations where you don't use it, and you just use, say, (git-file-name name version), and you don't update version, but only the (commit "…") field below it, *and* have already run Guix on your machine with an incorrect hash. <nckx>It's pretty far fetched though. Unless I'm missing something. <batalie>needless to say this is my first attempt at a package definition :p <nckx>It does not seem to be going too poorly if you're already generating custom Makefiles. <nckx>Or perhaps that is a cry for help. <dissent>batalie: can be quite easy depending on your level of skill and what you're packaging. *nckx prepares to be proven wrong by gory ninja death. <nckx>dontUseNinjaBuild = true; is interesting tho'. <batalie>oh i didn't think to look at what nix is doing <batalie>it's a fairly simple program, i wonder if i could also dodge building it with ninja somehow <nckx>It didn't occur to me until embarrasingly late, i.e., now. <nckx>Probably best, Nix packaging often… takes a different approach from Guix. <nckx>Not just that, but also that. <florhizome[m]>nckx: like I said I think a commandine switch that enables some checks in the build process would be v acceptable for me. <florhizome[m]>For the documentation and package declaration ways: it would be already be very helpful to have a short overview of the „hierarchy“ between the fields. <florhizome[m]>Well I have to look into what exactly is already told under origin <florhizome[m]>> <@florhizom:matrix.org> nckx: like I said I think a commandine switch that enables some checks in the build process would be v acceptable for me. <florhizome[m]>> For the documentation and package declaration ways: it would be already be very helpful to have a short overview of the „hierarchy“ between the fields. <florhizome[m]>> Well I have to look into what exactly is already told under origin <nckx><switch that enables some checks in the build process> Please explain if and why --check (!!) is not sufficient. <nckx>Guix lint does not compute outputs. <nckx>It is largely a style checker with some deeper knowledge of certain Guix things. <florhizome[m]>Since guix lint is run before a package is submitted, it makes a lot of sense to have the functionality there. <florhizome[m]>Something that a contributor (or a ci) will run before accepting a package <nckx>Maybe an --expensive option. <nckx>Oh wait, actually that's ‘build’, never mind 😃 <nckx>I don't understand what ‘checking origin against the hash’ means. Could you rephrase? <nckx>guix build --{source,check} does that. We might add an option to try *all* URLs, perhaps. <nckx>Then you need to explain the difference between guix build --{source,check} and your proposed guix lint feature, because they sound identical. <florhizome[m]>Does guix build build the package if it’s not there? Would guix lint try to? <nckx>I suggested building the source, not the package. <nckx>If I forgot --source anywhere: my bad. <nckx>florhizome[m]: guix lint, as it currently exists, builds nothing. That's both its strength (known-reasonable run time cost) and limits what you can do as a linter. <nckx>You could reimplement or simply call url-fetch etc. from the linter. However, we haven't even established how (if at all) guix lint would differ from guix build in this specific case, so agonising about whether we should is premature. <nckx>The current argument seems to be ‘I prefer the prefix guix lint over guix build’ which is, sorry, not enough 😉 <florhizome[m]>You would also mainly use it for checking. It doesn’t have much to do with building other then that it will build a derivation. <KE0VVT>Do I need to restart my session after doing `guix system reconfigure`, to get Swaylock to work? <nckx>‘Building a derivation’ is what guix build does. <nckx>Then, once more, I do not understand. It has 100% everything to do with building. <nckx>I have to agree with lfam. This is going in multiple circles. It might fit better on the guix-devel@ mailing list, so the argument can more easily be split into pieces that can be discussed (and either accepted or discarded) in their own right. <nckx>KE0VVT: I don't think so. <nckx>‘type swaylock’ should point to the setuid version. <nckx>Definitely guix-devel@ material. So far it sounds like a mere alias for ‘guix build -S’ which is a no from me. I think we have, at best, enough mere aliases and should not add more. <KE0VVT>nckx: swaylock is /home/caleb/.guix-home/profile/bin/swaylock <nckx>KE0VVT: Is your shell hashing (=we'd say caching) it? ‘hash swaylock’, ‘type swaylock’. <KE0VVT>nckx: swaylock is hashed (/home/caleb/.guix-home/profile/bin/swaylock) <nckx>Is /run/setuid-programs/swaylock even in your $PATH? <nckx>Sorry, /run/setuid-programs of course. <nckx>It should precede (/home/caleb/.guix-home/profile/bin. <nckx>E.g. my PATH: /home/nckx/.local/bin:/run/setuid-programs:/home/nckx/.config/guix/current/bin:/home/nckx/.guix-profile/bin:/home/nckx/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin <KE0VVT>Weird. /home/caleb/.local/bin:/home/caleb/bin:/home/caleb/.guix-home/profile/bin:/run/setuid-programs:/home/caleb/.config/guix/current/bin:/home/caleb/.guix-profile/bin:/home/caleb/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin <nckx>Ah, guix home strikes again. <nckx>See, I think this is wrong, but if it's what guix home generates, take it up with… the author or the bug tracker I guess. <nckx>Masking setuid-programs like this seems like a bug to me. <nckx>Anyway, removing it from your home packages should remove the shadowing swaylock. <nckx>Not much harm done, just confusion & time. <KE0VVT>nckx: I would remove it and reconfigure, but Home gets tripped up on the @ in my PS1. <nckx>Glory, glory. With the disclaimer that I don't use Guix home, paste your (full) home configuration, I'll try mashing a bit to see if the problem's easily fixable. <nckx>Or comment it out for now. Also a method. <nckx>Probably a better one for now. <KE0VVT>Commenting out the offensive lines. Reconfiguring. ***jonsger1 is now known as jonsger
<nckx>KE0VVT: The issue is not with Guix home or the @. You are not escaping each \, making it an invalid Scheme string, full stop. <nckx>"[\\[\\033[01;32m\\]\\u@\\h\\033[00m\\] \\[\\033[01;34m\\]\\W\\[\\033[00m\\]]> " <nckx>If you liked (), you'll love \\!™ <nckx>(Now, if guix home's shell code generator still chokes on it, it might be due to the @ or anything else, but the \s were definitely a blocker. <nckx>Same with "\\[\\033[33m\\]>>\\033[00m\\]" <podiki[m]>I had to use 4 \ the other day (escaping a \ in a substitute expression) <nckx>They breed like weasels. <podiki[m]>needless to say it took me more than 4 tries to get it right :-| <nckx>The drawbacks of a regular syntax (where bash seems to take an ‘I'll try to guess what you mean’ approach, which is fun until it isn't, at which point it is very a lot not much fun.) <nckx>But then, that is bash, in a nutshell. *nckx forgot a ) above and closes it now, so they can sleep later. <nckx>You'll summon unmatched-paren at this rate. <florhizome[m]><KE0VVT> "nckx: Doing this for now..." <- What was the problem with using swaylock, actually? <nckx>KE0VVT: Anyway, to get back to my own point: if you want a literal \\ in a Scheme string, *always* escape it, no matter what follows. <KE0VVT>florhizome[m]: It won't run from bemenu, because it is a setuid program. <nckx>florhizome[m]: At which point in time? The last problem was guix home putting its own swaylock before the setuid version, which is contrary to what guix package does. <nckx>I don't understand it either. <nckx>They are abcdw here, sometimes. <sneek>I think I remember abcdw in #guix 14 days ago, saying: jpoiret: I already did and tested them, now I want to get the code, which was actually committed, also I hope the substitutes for chromium-wayland is available too.. <florhizome[m]>i just have it set as screensaver but i don't think that changed much <florhizome[m]>I have to test my idle, hibernate and sleep functionalities sometime <nckx>sneek: botsnack, but also no pinging people. <nckx>florhizome[m]: I was about to say ‘good night’ until I realised you weren't being poetic. ***califax- is now known as califax
<nckx>Hullo blackbeard & excalamus. <excalamus>I've been having issues with video on jitsi. People say they can't see my camera and I can't share my screen. My camera shows up for me and works with something like guvcview. I'm using unGoogled-chromium. Everything worked a few months ago, but with no real error messages I'm feeling in the dark <nckx>(Nope. I don't use that browser.) <excalamus>I use icecat normally, but that flat out won't work with jitsi, it seems <excalamus>is there something else packaged within Guix that might work? <blackbeard>excalamus: maybe ungoogled-chromium with flatpak, I am not sure if it exists <blackbeard>excalamus: just be sure to remove all the bad things from Firefox <excalamus>I'm going to try qutebrowser since, if I recall, Qt uses chromium <nckx>(That is a completely broken shebang.) ***lukedashjr is now known as luke-jr
<excalamus>looking at my package history, I can see what version of chromium I was using when it last worked (92.0.4515.159-0.8164c91 ). If I understand correctly, I'd need to time machine the guix version so that I could rebuild the chromium version I want. <excalamus>I'm thinking something like time-machine to get the guix version and then shell just to run it <excalamus>so, the question is, what version of guix had that version of chromium? <excalamus>maybe there's a way I can do a git history search? <excalamus>git log -S'92.0.4515.159' -- gnu/packages/chromium.scm <excalamus>sweet, now to start compiling this over night, lol <excalamus>so that I can call the guix environment from that version of guix <excalamus>I get an environment, but I can't figure out how to build it/install it in such a way that wouldn't conflict with my latest chromium <excalamus>the environment I have is from guix! environment ungoogled-chromium <apteryx>excalamus: I think you want to use a manifest with an inferior <apteryx>refer to the manual as to how to accomplish that <excalamus>okay, I'll submit to defeat to night and regroup tomorrow with a new plan <excalamus>I've been running imperatively. Does this mean I'll need to switch over? <apteryx>should be easy with the --export-manifest option <excalamus>been meaning to switch to manifests. This seems like the impetus <akirakyle>I can't seem to get it to work, I get the following 00:00:00.017 [ERROR] [wlr] [libseat] [libseat/backend/logind.c:267] <akirakyle>Could not activate session: Interactive authentication required. <akirakyle>Was maybe hoping there was someone here who understands elogind that could help me debug? <podiki[m]>I feel this has come up recently, perhaps search any other issues or the irc logs? otherwise you'll have better luck here when it is busier (I guess on european time during the day?) <akirakyle>Thus far my searching has come up dry :/ but thanks for reminding me about the time differences here! ***lukedashjr is now known as luke-jr
<akirakyle>Those patches were applied to master and I think are the cause of my issues <akirakyle>Or rather as far as I can tell wlroots ripped out its elogind support and now depends on seatd to provide it and those patches fixed that dependency after a previous update to sway in guix <akirakyle>Yeah that's probably the right next step: update sway, seatd, and elogind to the latest commit and try again <akirakyle>I'm on aarch64 so I'm compiling everything locally anyways so I'm not sure if this is an aarch64 specific issue. Was hoping someone could just tell me the latest guix version does or does not work with sway <podiki[m]>hmm could be aarch64 if no one else has mentioned it recently on x86-64; things seem more difficult there <akirakyle>Would someone here be willing to test that for me? It should be as easy as guix pull (or just have done it in the last week or two), guix install sway, then run sway on a tty (you might need to quit whatever other window manager/desktop manager system you have running) <podiki[m]>I'm sure you'll find someone running (or able to update) the latest (I cannot, sorry) <akirakyle>Might be better to try my luck earlier in the day here <ns12>What are the minimum system requirements of Guix? Is it mentioned in the manual? <ns12>I have a small 512 MB RAM computer. I don't think Guix can run on it. Is that correct? <ns12>Yesterday, I tried to "guix pull" on a computer with 1 GB RAM + 1 GB swap, but ran out of memory. <gnoo>it should, i think. my current memory usage is 627 mb with 1 empty browser tab. without it, it goes down to 420 mb (most of it is weechat's buffers) <vagrantc>yeah, guix pull probably requires at least 2GB of ram <vagrantc>well... some years ago i was able to guix pull with only 512MB of ram, but it was painfully slow (took tens of hours) <gnoo>i just did guix pull and memory consumption jumped to 1.1 GB. so it took about 700 MiB <gnoo>(with an error: TLS error in procedure 'write_to_session_record_port': Error in the push function.) <ns12>Maybe it depends on the day. Maybe there is no consistency. I had been using 1 GB RAM + 1 GB swap for the last six months. I only had problems "guix pull" yesterday, which I solved by doubling the swap to 2 GB, giving me a total of 3 GB memory. <ns12>Guix is probably not designed to be used on old low-end computers. <florhizome[m]><akirakyle> "Would someone here be willing to..." <- Does guix have the latest releases of wayland, wayland protos and sway now? <libredev>Guix uses guile which is very slow i think <libredev>I don't think people should write operating system on lisp. <libredev>C is optimized to write operating system and its components <attila_lendvai>libredev, in a proper lisp, you have trivial ways to hook into the compiler and even to customize the code generation. then you have staged computing to optimize way beyond what's possible in C with a reasonable effort. lisp is completely capable to be the base language of an OS. <ns12>Perhaps the solution is to uninstall Guix from all computers. There should only be one computer (with large RAM) that has Guix installed. This computer would run "guix pack" to produce packages for all the other computers. This circumvents the huge memory requirements needed to run "guix pull". <florhizome[m]>It’s also not like guix os is not still written majorly in c and c++ and guix Dämon is in c++ <ns12>As time goes by, I expect Guix to be unusable on most of my computers due to Guix's increasing system requirements. I think the "guix pack" solution will allow me to uninstall Guix. Are there alternative methods? <libredev>Guix also uses Gnu Shepherd which is slow and written in guile <ns12>I don't understand why some software would ever need more than one *billion* bytes of memory ... <florhizome[m]>ns12 you can already offload builds on the local network so you don’t have to pack specifically <vagrantc>florhizome[m]: yeah, but not all of "guix pull" can be offloaded <porcupirate>guix isn't finding gdc-toolchain even though it is right there in the source. <ns12>For "guix pack", what is the difference between --system and --target? <florhizome[m]>i think guix pull can be further optimized. I think I saw some talk about it, also with guix servers. the initial communication can be spead up, more steps to download more asynchronous can be done... <florhizome[m]>It has also gotten slower to me since cuf, at least in the first view steps. <mothacehe>ns12 system uses QEMU transparent emulation while target cross-compiles <ns12>If I am using x86-linux, and I want to produce a bundle containing software to be run on i686-linux, which option should I use? --system or --target? <ns12>mothacehe: So the answer is to use --target? <mothacehe>no that's a specific case. x86 can produce i686 binaries without resorting to emulation/cross-compilation <ns12>--system will cause the bundled ("guix pack") software to depend on QEMU when the bundled software runs on my i686-linux computer? <ns12>mothacehe: But you said "system uses QEMU transparent emulation while target cross-compiles"? <mothacehe>except when using --system=i686-linux on x86_64 and --system=armhf-linux on aarch64-linux <mothacehe>in that case, there's no transparent emulation, the compiler is just passed an -m32 flag roughly <mothacehe>the produced binaries or pack will never depend on QEMU at runtime <ns12>Okay. I'm starting to understand. But how is --system different from --target when building i686-linux binaries on an x86-linux computer? <mothacehe>you can force gcc to cross-compile, but it doesn't make any sense <mothacehe>we should disable --target in that specific case <ns12>"gcc to cross-compile, but it doesn't make any sense" - Why doesn't it make sense? Isn't i686-linux a different architecture than x86-linux? <mothacehe>ns12: you can see i686 as a subset of the x86_64 arch <ns12>Okay, so if I am on an x86-linux computer, I should use --system to produce binaries for i686-linux, but --target to produce binaries for armhf-linux. Correct? <mothacehe>that's right. You can also use --system=armhf-linux, in that case the compilation will happen in QEMU. <ns12>So why would anyone want to use --system=armhf-linux on an x86-linux computer instead of using --target? <gnoo>in case your compiler can't cross-compile to that, maybe <mothacehe>yes the main reason would be that some of our packages/build-systems do not support cross-compilation <mothacehe>or fail to cross-compilation because the package recipe are written in a way that prevents cross compilation, hardcoding gcc for instance <allana>Hi! I am experimenting with guix home, and I am curious to know how to use only the profile generated by guix home. For example I have emacs 27 installed under my regular profile, but with guix home I only install emacs-next-pgtk. <allana>In my case, when running emacs from a terminal emulator I get the emacs-next-pgtk version, but when launching emacs from gnome desktop I get the emacs 27 installed under my usual profile <mothacehe>ns12: you can probably use --target=arm-linux-gnueabihf on the gnu/system/examples/bare-bones.tmpl but gnu/system/examples/desktop.tmpl will likely fail. <ns12>If the compiler and build system supports cross-compilation for the target architecture, will --system and --target produce identical binaries? <civodul>ns12: no, they don't (that's generally the case, independent of Guix) *mothacehe finally fixed GNOME bluetooth integration in Guix System <ns12>mothacehe: Thanks for answering my questions. <mothacehe>ns12 you welcome. The system/target difference is tricky and not much documented. <ns12>civodul: Cross-compiling a program for armhf on an x86-linux computer produces a different binary than when compiling the program on an armhf computer? <ns12>But both binaries will be able to run on an armhf computer, so why do they need to be different? <efraim_>--target creates cross-compiled binaries and --system creates native binaries, the path to the end result is different so the hash is different <efraim_>it would be interesting to run diffoscope against the two and see what actual differences there are <mothacehe>gcc is not behaving the same way when run natively or when cross-compiling I guess <mothacehe>when run natively, it may optimize the program more efficiently for instance i guess <civodul>efraim_: in Guix you'd see different store file names, and build systems usually have #ifdefs and stuff that work differently when you're cross-compiling ***efraim_ is now known as efraim
<fproverbio>does anyone have experience with vfio pci passthrough? i was trying to surrender a raid controller to a virtual machine to retrieve some data but the device in question is still not grabbed by vfio-pci at boot time <rekado>re memory requirements: this is a known problem with the Guile compiler. There’s little Guix can do (beyond what has already been done) to improve this. <rekado>proclamations of dOOM for old machines are misplaced here. <ns12>rekado: "Proclamations of dOOM for old machines" should be brought to #guile instead? <florhizome[m]><ns12> "rekado: "Proclamations of dOOM..." <- If it's a well known thing I think it will be solved sooner or later. <ns12>florhizome[m]: Is your statement equivalent to "I think guile maintainers like old machines"? <abrenon>I think it depends if we're working in constructive logic or not <phf-1>Hello Guix ! Is there a way to « trick » Guix into installing a python wheel ? Even if it's a one shot, I really need this to work to install fastapi. Thank you. <abrenon>what do you mean a "trick" ? what's the reason it doesn't work ? <jlicht>mothacehe: wow amazing news on the bluetooth front; I can't even remember for how long I've been running into that problem <phf-1>abrenon: « trick » because using a wheel bypasses the build step of binaries, for example with `orjson' that is a Rust based Python package. <phf-1>*bypasses the build step of guix install ... <mothacehe>jlicht: thanks, now works like a charm here :) <abrenon>so, IIUC you're trying to define a python-fastapi package, and you made it use the python-build-system but this fails because the project doesn't have a setup.py ? <phf-1>which is a dependency of `fastapi' <phf-1>abrenon: I used `guix import pypi -r fastapi' <phf-1>which produced the package definition. <abrenon>and it uses python-build-system, but there's no setup.py ? <phf-1>I've just read python-build-system.scm to try to find a way to go around this because essentially, `pip install somefile.whl' would be enough. <abrenon>anyway, orjson doesn't seem to have a package so I think you're in for packaging it as well <abrenon>well I think you can still install pip and have it install things quick'n'dirty in your homedir, if you simply want to run pip install <phf-1>and given by `guix import pypi -r fastapi' <ngz>phf-1: See tensorflow package definition, which invokes "python" "-m" "pip" "install" ...whl directly. It may help. <abrenon>the point is, the python-build-system doesn't what pip does in a clean way, that allows guix to isolate the package and build it purely <phf-1>Well, the real target is to build a relocatable archive i.e. `guix -RR -S /bin=bin somepackage' <phf-1>ngz: thanks for the pointer. <fproverbio>hi everyone, is there a way to skip python tests alltogether? i'm trying to package a big project and this dependency is getting in the way failing in the check phase (i defined it using guix import) <abrenon>fproverbio: (arguments `(#:test? #f)) should help, but is it the tests failing or the sanity checks ? I had an issue a couple days ago packaging a python lib which was trying to write stuff to my homedir during the checks <abrenon>phf-1: in any case, I see no particular trick to apply: it's just a package with a non-standard format that IIUC python is in the process of replacing pip with, so, yeah there's no sound importer (yet !) for guix, it just means more work because you'll have to script in guile what the promoters of that format require users to do in order to install their software <abrenon>but I see no conceptual impossibility (except if there's something in the install process that explicitly imposes to write in a stateful way to some precise location like /usr/bin that can't be relocated to a different root) <fproverbio>i'm gonna check, there's plenty of logs due to the continuous building :) <fproverbio>pytest_runner returns exit status 1, it doesn't seem to be trying to write to /home/ <phf-1>(sorry phone call, reading now) <abrenon>and for the sake of purity this variable is set to /homeless-shelter <abrenon>this is what disables the cache on the second line <abrenon>"/homeless-shelter/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check th" <abrenon>and that doesn't prove it is the issue at stake here <abrenon>connection error: I think the "tests" are trying to retrieve dynamically some (web) content through urllib <abrenon>and network isn't allowed during build <fproverbio>i was trying to cut that phase clean to see if the build goes through <abrenon>because we want reproducible builds, and network access isn't exactly "reproducible" (especially web query to some server that may or may not be up, etc.) <abrenon>raise-exceptions ? once the package is built ? <abrenon>or didn't the (argument …) snippet I suggested work ? <abrenon>I'm far from being fluent in guile ^^ <fproverbio>i replaced my previous attempt in argument with yours but it still complains :D <abrenon>hmm I double checked in one of the package definition I have that uses it and it works <fproverbio>i'm gonna look for examples in the python-xyz.scm file, maybe i'm missing something (module?) <abrenon>ok, so copy-paste so it's not an error on "'" instead of "`" (backquote) <phf-1>abrenon: Thank you for the answers. I'll try to script in guile then. ***remy1 is now known as Reventlov
***remy1 is now known as Reventlov
<abrenon>phf-1: you're welcome, I hope it helps <awb99_>Is it possible to run a VPN server with guix? <awb99_>is there anywhere a sample config? <xelxebar>So, package A installs /bin/baz-123, and I'd like to symlink that to /bin/baz. I created a dumb trivial-build-system package that does this, but that feels like a huge overkill. Is there a better or more canonical way? <xelxebar>The /bin paths are really <profile-path>/bin, of course. ***aya is now known as gyara
***taylan2 is now known as taylan
<rekado>xelxebar: you can modify package A with a build phase like this: (add-after 'install 'symlink-executable (lambda* (#:key outputs #:allow-other-keys) (let ((bin (string-append (assoc-ref outputs "out") "/bin"))) (symlink (string-append bin "/baz-123") (string-append bin "/baz"))))) <PotentialUser-65>Is there any good laptop to run GUIX without NONGUIX? I am looking for a modern laptop having really a good processor with a good performance, with coreboot or libreboot support and good graphics (probably I should stick with AMD). I only know Tuxedo (with AMD), System76 and Purism selling Linux laptops, but don't know if they have proprietary <PotentialUser-65>blobs or work with linux-libre. I want to buy a laptop that can run linux-libre but also has a good performance as well. <rekado>PotentialUser-65: I’m typing this on a Librem 13v2 <attila_lendvai>#~ and #$ makes code substantially less readable to me. is there a way to avoid using gexps and this-package-input in place of %build-inputs? <rekado>attila_lendvai: depends on the problem <rekado>attila_lendvai: I suggest not to worry too much about the syntax. #~ is a fancy quasiquote and #$ is a fancy unquote. <attila_lendvai>rekado, it's nothing special, just some ,(assoc-ref ) in the package arguments for #:make-flags. <rekado>PotentialUser-65: I think bluetooth might not be working on this laptop <rekado>but wifi and camera works just fine <rekado>I had a few troubles with the machine over the years, but with the latest official coreboot image from Purism and a recent Linux kernel it all works pretty well now <rekado>(or maybe I have mellowed enough to give up fighting it :)) <xelxebar>rekado: What do you mean by modify package A? Create a wrapper package with package/inherit? <rekado>xelxebar: I meant: change the package definition. Then submit a patch. <fproverbio>PotentialUser-65: i'm afraid there aren't many alternatives to what rekado said, the last affordable laptop (x86) that runs guix well is the thinkpad x220/x230 series. No blobs required (beyond neutered intel ME) and everything works out of the box if you change the included wifi card <rekado>or is that something so peculiar that it shouldn’t be default? <xelxebar>rekado: Oh. I see. Yeah, I'm thinking more personal, custom symlinks. <rekado>xelxebar: if you only want a particular package output to be available in your profile under a different name there are alternatives: 1) you could use a shell alias or 2) if this is Guix System you can use special-files-service-type <PotentialUser-65>rekado:, fproverbio: I wonder how the developers of the os or the kernel manage to compile software. Poor hardware takes around a day to compile Firefox or something. <rekado>I’m compiling everything on my laptop. <rekado>it takes time but it’s not terrible <rekado>it was a bit more painful with my thinkpad x200s <jpoiret>pretty often they have either beefy desktop machines or private CIs <rekado>(I have neither, unless ci.guix.gnu.org is considered private ;)) <jpoiret>kernel is not that long though, and with incremental compiling it can be wayyyy shorter <fproverbio>PotentialUser-65: you can offload compilation to more powerful computers or servers, it's pretty easy to spin a up a guix VPS and you don't even have to worry about linux-libre since it's qemu q35 <jpoiret>someone just submitted a 1.5k commits patch for the kernel to cut down compilation time by 70% <attila_lendvai>is there a way to mark a package not to be built on the substitutes? context: i'm working on keeping Idris bootstrappable all the way down from GHC, and it requires 4-5 intermediate versions. these are not interested to anyone who just wants the most recent version (which can be boostrapped through a shortcut of checked in scheme files) <fproverbio>jpoiret: i've read it too, glorious if it makes it to mainline ;) <fiesh>PotentialUser-65: I'm quite happy with my librem14 <rekado>attila_lendvai: you can mark packages as not substitutable, but we don’t really use that much unless we really should not provide binaries <xelxebar>rekado: A shell alias isn't ideal in this case, since I'd like `/usr/bin/env baz' to also work. The special-files-service-type is an interesting idea, though I'd prefer to keep the package in my user profile. <fiesh>I'd give the hardware 4/5 stars, and the purism support 1/5 <rekado>(e.g. for atlas which tunes itself to the CPU of the building machine; or for zfs for legal reasons) <PotentialUser-65>fproverbio by "powerful computers" do you mean which are open, or which are closed like Intel or AMD systems (like Dell, ASUS, etc.)? <rekado>fiesh: sounds like a fair rating. <attila_lendvai>rekado, even if building idris2 v0.1.1 with GHC takes quite a while (about an hour?), and uses quite some memory? <PotentialUser-65>fiesh: Wow, I would go for Librem14, but for me the price is quite high, compared to Tuxedo. <fproverbio>PotentialUser-65: generally any old server board that manages to run on coreboot is a safe bet <rekado>I should say that early on I took my broken Librem 13v2 to FOSDEM to swap out broken RAM. That was pretty good service right there. <fproverbio>lots of cores and memory at the expense of power consumption and heat :) <rekado>PotentialUser-65: you may also consider aarch64 <rekado>(if you don’t actually need a laptop) <fiesh>PotentialUser-65: I found it pretty reasonably priced, like $1200 if I remember correctly, plus a bit now for 2tb nvm and 64gb ram <rekado>attila_lendvai: users of the latest version won’t need to build the older ones when there’s a substitute, right? <xelxebar>rekado: What I'm really doing is writing a package where the user might want multiple versions installed in parallel (like python), but it's also ideal to have a standard path, a la python-wrapper, but where the user can choose which version they want to point to. <PotentialUser-65>rekado Can aarch64 really be "powerful'? I thought only x86 can be considered as powerful. <fiesh>PotentialUser-65: no idea if tuxedo has intel me disabled etc. <jlicht>on a tuxedo machine from 2017, intel me was still enabled <fproverbio>PotentialUser-65: or just wait for asahi-linux to finish their effort lol <rekado>attila_lendvai: you would also doom people who build the latest version from source to also build all the bootstrap versions locally <fiesh>well anyhow, with purism, the infuriating part is *getting* your device... once you have it, it's quite nice to be honest <rekado>PotentialUser-65: I’ve got three honeycomb LX2 machines sitting on my desk right now. They each have more cores than my laptop *and* they are quieter. <attila_lendvai>rekado, the old binaries are not needed to compile the latest version, because the scheme compiler backend output files are checked into the Idris repo, and ChezScheme is used to compile them in a so called 'bootstrap shortcut'. <rekado>attila_lendvai: I guess I don’t understand why the old versions exist at all then <rekado>attila_lendvai: you can also hide packages <rekado>they can still be built with ‘guix build -e '(@@ (gnu packages foo) bar)'’ but they won’t appear on the command line <fiesh>if the librem supported a thinkpad-style cursor thingy, had no touch pad, had better speakers and had ECC ram, I think it would be 100% perfect to be honest <rekado>(and if the display could be tilted just a tad more to the back, like the thinkpads) <attila_lendvai>rekado, i can squeeze out some arguments wrt reproducibility/security, but it's mostly only for the geek value i guess. <fiesh>rekado: mine can be made completely flat <fiesh>rekado: like opening at a 180 degree angle <rekado>PotentialUser-65: I’m pretty surprised by these ARM build machines. They are considerably faster than the ones we bought before, and kinda neat. <fproverbio>PotentialUser-65: you could also look into raptor computing machines, openpower cpu architecture <fiesh>if your budget is somewhat tight, you're almost certainly bound to x86 devices if you want decent performance <PotentialUser-65>fproverbio openpower is something I never heard. Thanks, I will learn about it. <abrenon>fproverbio: btw, have you managed to get the (arguments …) stuff right ? <fproverbio>abrenon: ok it works (no raise-exception) but it errors out with the same cuplrit <abrenon>…because that part is in the sanity-check and not the tests <abrenon>sorry, I noticed it was there, commented on it, but still did'nt see any problem with you trying to disable the tests <abrenon>(and what's more, the exact same happened to me like 3 or 4 days ago…) <fproverbio>is there a way to disable sanity checks? seems like an unreasonable thing to do :) <abrenon>yeah, it's pretty unreasonable, what you can do is probably change their course somehow <abrenon>there are examples in the codebase of how to use /tmp instead of /homeless-shelter to get a writeable path (so in your case in would allow pip to write its cache) <abrenon>about the network, I suppose you could download the files once distribute them as part of the package, changing the script that loads them to use your local versions instead of using urllib <abrenon>sounds like a lotta work, but I don't see why "sanity" check would rely on network resources (sounds pretty insane to me) <fproverbio>i mean, not to be political about it but the whole project is weirdly laid out <skn84>hi all! trying to cross-compile for freebsd: <skn84>$ guix build -K --target=x86_64-unknown-freebsd13.0 bootstrap-tarballs <skn84> 54 | #include <sys/_types.h> <skn84>In file included from ../../../gcc-10.3.0/libgcc/../gcc/tsystem.h:44, <skn84> from ../../../gcc-10.3.0/libgcc/libgcc2.c:27: <skn84>i understand the meaning of the error well and know how to fix it in a "normal" build system. <skn84>but how do i put a file for `guix build`? <skn84>first line of error message: <skn84>hm. chat eats the error text. <rekado>the reason why the chat swallowed the line is because in IRC ‘/’ indicates a chat command <rekado>does the missing header exist? What provides it? Is that location listed in CROSS_C_INCLUDE_PATH? <skn84>> does the missing header exist? <skn84>yes, of course. on freebsd. i can copy it. but where? <skn84>as far as i understand, this is part of the freebsd base system. <asdf-uio`>>> <lfam> It's clear that the 'shadow' example was too obscure <asdf-uio`>That's both my impression and a nice play on words. I had no idea how to find the correct package for setuid programs I wanted to add. I am not sure if I got the right way from examples or documentation. <asdf-uio`>Maybe a simple example and a more complicated one, along with an explanation how to find the right package would be nice? Or a link to another section where a complete explanation is to be found? <asdf-uio`>>> <podiki[m]> yeah, I noted search engines (or ddg at least) always give the "stable" old manual <asdf-uio`>I also had that kind of problem. Once you know it, it's fine, but before that... <asdf-uio`>Wouldn't a header with a big red warning like 'this is most probably not the right version of the manual if you are on a running system' and a link to the corresponding page in the current docs make sense in the online version of the manual? <asdf-uio`>Regarding the low usage of 'guix lint' for submitted packages: If most people get started with packaging with the cookboot, wouldn't it make sense to add a sentence on 'lint' there? <asdf-uio`>I don't see a way to lint a file. So I have to run 'guix pull' before 'guix lint', right? Is an option to lint a file planned? That would be useful for local channels. <jpoiret>no one in their right mind would read the whole <origin> commit sha vs tag thread. I think it's about to surpass the node patchsets in number of replies :) <skn84>> Is that location listed in CROSS_C_INCLUDE_PATH? <skn84>unlikely: this is a file from freebsd, where it is located in `/usr/include/sys/_types.h` ***makx_ is now known as makx
<skn84>let me remind you: i'm cross-compiling - `guix build -K --target=x86_64-unknown-freebsd13.0 bootstrap-tarballs` <jpoiret>all guix builds happen in a namespaced environment, so /usr/include/sys/_types.h will never be visible <jpoiret>you'd have to at least modify the package you're trying to build to include the correct headers in its inputs <skn84>`bootstrap-tarballs` you mean? <nckx>Basically, ‘port Guix to FreeBSD’. <jpoiret>oh, well, you'd need to modify gcc then. <gnoo>does gallery-dl violate some rules so that it can't be included in guix? <skn84>jpoiret: thanks. are you aware of other attempts to port to freebsd? <efraim>I believe ng0 made some attempts to port guix to netbsd a few years ago <skn84>i have already built guix directly on freebsd. but i can't continue without bootstrap-tarballs. <skn84>efraim: i think guix has become more portable since then. ***wielaard is now known as mjw
<jpoiret>skn84: guix-the-program is pretty easy to port, but guix-the-packages won't be, as you've just experienced <jpoiret>maybe you could look at how guix handles the Hurd ***zimoun` is now known as zimoun
<skn84>yes, i'm looking at how it was done. <skn84>but i'm new to both guix and guile, so it's going to be a bit difficult for me. at first. <ngz>rekado: Thank for the incoming texlive fix <jpoiret>skn84: for sure. I don't think it would be an easy first contribution <asdf-uio`>I am getting errors for inputs of common lisp systems I am trying to package, e.g. (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (sbcl-clack)) (value #f)). I assume I made some trivial mistake. The systems that resulted in these unbound-variable exceptions have all been available in guix, so far. <jpoiret>well, you're trying to use the sbcl-clack variable without it being available <nckx>asdf-uio`: Did you include the (gnu packages lisp-xyz) module? <asdf-uio`>Thank you! I did not. And I got that thought when I saw jpoiret's answer. It's weird how the same information I saw in the error message suddenly clicks when it is given by a human being. <jpoiret>i agree though that the way this exception is displayed is not very readable <nckx>Guile's error messages are… the opposite of human, indeed. <nckx>Guix does supply ‘hint: did you mean to import (gnu packages foo)?’ hints but they don't always trigger. <jpoiret>here it stems from the automatic conversion from the old throw/catch to the exception system <nckx>‘We're’ used to it but it's really horrid. <rekado>ngz: if you’re in a rush you could use wip-texlive already. It seems to be fixed there. <rekado>pdflatex will generate the font in the requested DPI <rekado>xelatex doesn’t use the bitmap fonts at all IIUC, so it works even without the most recent fix <rekado>(it just required the directory recursion fix) <asdf-uio`>Now I get this for lisp (and before that for lisp-xyz): (exception misc-error (value #f) (value "no code for module ~S") (value ((guix packages lisp))) (value #f)). Just after writing this I had another look at an existing lisp package and noticed that my mistake was using guix instead of gnu packages. Is this also something Guix could supply a hint for? <ngz>rekado: I will give this branch a try in a while. <rekado>ngz: I’m going to develop a few more fixes for texlive bugs that have accumulated <rekado>eventually I’d also like to revamp simple-texlive-package <florhizome[m]><jpoiret> "maybe you could look at how guix..." <- Doesn’t the Hurd use glibc, too? That’s a major difference, isn’t it? <rekado>that whole file is too complicated and there are too many ad-hoc solutions <rekado>florhizome[m]: it does indeed. The Hurd implementation is spread across a few projects, and glibc is one of them. <jpoiret>florhizome[m]: oh, i had forgotten about that! For sure, that's going to be a major hurdle <jpoiret>oh, but then, does guile run on BSDs? <nckx>To be clear, glibc supports FreeBSD (and probably others) just fine. <jpoiret>oh, i guess there's still a glibc equivalent that provides the necessary symbols <ngz>rekado: OK. I cannot be of much help, as I just started to dive in "tex.scm". How do you know when a package does not need to use simple-package-texlive? <nckx><To be clear> Doesn't it? Now I'm starting to doubt myself. <florhizome[m]>I actually went to #hyperbola to ask how difficult they think it would be to port their custom openbsd kernel to guix+glibc <stikonas>well in any case FreeBSD would have some C library <jpoiret>well, it looks like it does support glibc, as well as its own libc <gnoo>can i remove 'building xdg mime database' step? it takes too long and i don't have any use for it <rekado>gnoo: this is a profile hook. Profile hooks are defined in guix/profiles.scm <rekado>these are run conditionally, depending on the contents of your profile <rekado>ngz: I always try to use simple-package-texlive for new stuff <gnoo>so i should remove it from the %default-profile-hooks ? <rekado>but simple-package-texlive is a little too dumb, so I can only use it as a template and then I need to override a whole lot of settings and phases. <rekado>I’d like to make it a little less dumb, or convert it into a proper build system <jpoiret>anguixuser: can you switch to a TTY using Ctrl+alt+2, sendkey ctrl+alt+F3, Ctrl+alt+1, then log in and do `mkswap -f /dev/vda4`? <jpoiret>the installer will soon show commands being run and their status properly <jpoiret>(I'm actually finishing up the patches) <sash-kan>jpoiret: > well, it looks like it does support glibc, as well as its own libc <sash-kan>btw: to build guix, i needed to write a replacement for `strverscmp()`. <sash-kan>and it is still used in `guix/utils.scm` and `guix/build/maven/pom.scm` <jpoiret>i was suggesting that to get more info about why mkswap was failing, but that's great in any case :|) <anguixuser>jpoiret, if you want I can repeat the installation to review the error :) <jpoiret>no worries, the error you get is not very informative in any way <jpoiret>i wonder what went wrong there though <anguixuser>one other thing i noticed is that the installer does not allow you to manually partition the disk when it is new (no gpt or mbr table) <sash-kan>;;; note: source file ~/packages/gnu/packages/bootstrap.scm <sash-kan>;;; newer than compiled /gnu/store/cfqs2cylyb96832h42f09g1w3x99xc1l-guix-module-union/lib/guile/3.0/site-ccache/gnu/packages/bootstrap.go` <sash-kan>how do i remove this uninformative message? <podiki[m]>this is from a local checkout with ./pre-inst-evn? <podiki[m]>run make, maybe make clean or make clean-go first? <sash-kan>podiki[m]: did you write to me? then i didn't understand anything. <podiki[m]>sash-kan: yes. but seems you are using a local version of guix? <jpoiret>anguixuser does it prompt for a specific table format? <podiki[m]>sash-kan: what exactly are you doing with ~/gnu/packages... <sash-kan>podiki[m]: no, i just patch `gnu/packages/bootstrap.go` (added architecture). <SeerLite[m]>Is there any way to make multiple versions of a package available in PATH? Like if I have openjdk 9 and 17, can I somehow make them available as java9 and java17 (in a package definition)? <sash-kan>podiki[m]: no, i don't build guix. i'm trying to cross-compile package for freebsd. <jpoiret>well, thanks, i'll investigate it later! I hope i can reproduce it locally on qemu <podiki[m]>sash-kan: okay. so then either ignore the message or build guix and use that version if you don't want the warning, I think are your options. <jpoiret>sash-kan: guix-the-program and guix-the-package-collection are one and the same <jpoiret>ie, the packages are simply guile code that define packages programatically, and are part of guix-the-program <sash-kan>podiki[m]: I'm ignoring, of course. but it's annoying. <podiki[m]>it is telling you the source file you are using and guix are not matching, but I don't think there is a functional difference? <podiki[m]>in any event, it is certainly meaningful, but if you don't intend to build your own checkout of guix with your changes, the message will persist <gnoo>SeerLite[m]: haven't tried but probably you can use (define-publice java17 (package (inherit "openjdko-17))) <podiki[m]>as I said, the typical way to make changes to Guix's packages is to use a local git checkout and build guix with your changes <podiki[m]>if you don't do that, you'll the the warning you have. but if it works for you, just carry on <sash-kan>jpoiret: the packages are simply guile code that define packages programatically <sash-kan>thank you, i have already realized this in a few days of my acquaintance with guix + guile. <SeerLite[m]>gnoo: Thanks, but I don't think that's that I'm looking for. It will only rename the package in the Scheme code, but what I need is to have the actual binary renamed in PATH <podiki[m]>I think jpoiret's point was just that guix the program/package manager and guix packages are one and the same <SeerLite[m]>But I think I can get what I want with some simple wrapper scripts so I'll try that <sash-kan>podiki[m]: did i understand correctly that it is impossible to disable the output of this message with simple actions? <podiki[m]>sash-kan: I mean, somewhere in the source you can probably find a way, but taht would mean....building your own guix also :) <gnoo>SeerLite[m]: if you change the name as well, using (name "java17") it should work, no? <jpoiret>both packages have a bin/java in their output, and so would conflict when installed to the same profile <jpoiret>do you really need to have both in the same profile? <rekado>a simple solution is to not install them into the same profile <jpoiret>if you only need one or the other occasionally, you could use a) separate profiles b) guix shell <gnoo>oh, ok, i need to learn guix some me <nckx>sash-kan: guix() { command guix "$@" 3>&2 2>&1 1>&3 | egrep -v '^;;; .*(note: source file|newer than compiled)' 3>&2 2>&1 1>&3; return ${PIPESTATUS[0]}; } <nckx>Adjust accordingly for ./pre-inst-env etc. <nckx>There's also $GUILE_AUTO_COMPILE but I don't know if it works post facto. <podiki[m]>speaking of local checkouts, what do people like to do to keep it up to date? git pull and then make, or best to always do a make clean of sorts? <nckx>I remake each time things get slow due to significant changes. Re-bootstrap when that's no longer possible (ABI changes etc.). Seldom anything inbetween (clean-go, etc.). I just launch a bootstrap & go do something else for a known stretch of time. <jpoiret>i only make clean when something doesn't work :) <rekado>I feel that patching sources in build phases is ugly <rekado>for trivial changes it’s very verbose <rekado>all that (arguments (list #:phases (modify-phases %standard-phases (add-after 'unpack 'i-dont-care (lambda _ (substitute* …)))))) <rekado>I wonder if we should move all this to the source derivation instead <rekado>and perhaps add a way for us to provide a schemey patch syntax <rekado>substitute* is often not quite the right thing <podiki[m]>like snippets in source field but for the build phases? or you mean better than snippet syntax currently for patching <rekado>sometimes I just want to add a line; the regexp is just there to let me anchor the addition <podiki[m]>substitute* does feel like a blunt object and I have abused it <rekado>we already have (patches …) but it takes files <rekado>I haven’t thought much about it, but I have come to resent the boilerplate substitute* thing <rekado>and the annoyance of hunting for a unique string to latch onto when all I want is just to add a line somewhere <rekado>common wisdom was that we shouldn’t modify the sources in a snippet unless it’s a freedom issue or the code is unusable without the changes <rekado>so most modifications were moved to build phases <rekado>in some cases it would make sense to patch some time other than directly after 'unpack <rekado>but the vast majority of packages I’ve worked on patch right after unpacking. <podiki[m]>oh, because a snippet modifies the source derivation then? <podiki[m]>I used it recently for some unbundling, figure that makes more sense as a snippet right? <rekado>yes, unbundling is often done in snippets <rekado>I’ve often been annoyed when I debugged a build and had to manually apply the patching that the build phases prescribed <rekado>I wonder if it still makes sense to discriminate against patching in the source field. <jackhill>rekado: interesting idea. I have not particular opinion on that right now, but I have been wondering on-and-off for some time if we could perhaps provide some interface for running the build phases interactively on a directory tree… <podiki[m]>hrmm...not sure what to do with this update: <podiki[m]>I need dear-imgui 1.81 (we have 1.79) which coincidentally is the latest I see for the Debian makefile we use for it; not the latest for dear-imgui but okay for me <podiki[m]>the only package I see that uses dear-imgui is Ogre (3d engine), but just the source <podiki[m]>ogre is way out of date, but don't see a version that wants dear-imgui 1.81 source :/ <dcunit3d>when i run if i get an "error: symlink: file exists: /var/guix/profiles/per-user/my-user/current-guix" <dcunit3d>when i run "guix pull" why am i getting that error? <podiki[m]>and current Ogre version we have doesn't build with dear-imgui 1.81; should I just keep the older dear-imgui for Ogre and worry about full updates to both at a later time? (my goal is for a package I have ready to submit that needs dear-imgui 1.81) <mroh>jackhill: guix hack --interactive ;) <podiki[m]>if an input is (package-source blah) is there a way to have just the source blah without a package that will build on its own? <the_tubular>Wait, what happened : guix upgrade: warning: package 'podman' no longer exists ? <podiki[m]>the_tubular: I still see it on a pull just a few minutes ago <podiki[m]>maybe you were using a local version and that file/channel is gone? <the_tubular>No, I grabbed podman after running a normal guix pull <dcunit3d>nevermind, i guess i had manually created a link to .config/guix/current at some point during the install <podiki[m]>yeah, that typically will have guix from install time <podiki[m]>best to be user and use sudo to avoid confusion <the_tubular> /run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin <podiki[m]>any conventions or dos/don'ts for hidden packages? (need some variants of existing packages to build new packages) <rekado>jackhill: I’ve been wishing for something like that too. <rekado>I think a big obstacle to that is that we can’t take whatever we want from the daemon code <rekado>would be easier to start on this if the daemon code was reusable Scheme <nckx>the_tubular: It should contain /root/.config/guix/current/bin *if* you want root to be a separate user with a separate guix. But that's not how most people use Linux. <sneek>I think I remember reepca in #guix 10 months ago, saying: command finally failed with the same error as before. <rekado>I don’t think the student project to rewrite the daemon from C++ to Scheme is still ongoing. <the_tubular>How does root usually work if's not a seperate user ? <nckx>Most people don't log in as root. <podiki[m]>in guix the only thing done with root for me is using sudo for system reconfigure <the_tubular>I can call podman with the long path /gnu/store/...-podman/ so that works <podiki[m]>(versus on my Arch machine where sudo for package management is needed, but that's also about it) <the_tubular>Because rootless containers are bork as of right now *rekado sent a bikeshedding email to guix-devel <rekado>I’m running ‘guix refresh -t cran -u’ for the first time since the switch to the new style and I see a surprisingly large number of recommendations to remove inputs <rekado>I think the refresh code may be wrong <lfam>the_tubular: I can tell from the PATH you shared that you used `sudo su` or a similar command based on `su` <lfam>That's how you get that limited PATH <lfam>If you want to become root on Guix, you need to login as root, with `sudo --login` <lfam>Okay, then log in as root from the console <lfam>Whatever you do, you have to "log in" <nckx>Can't you just ‘sudo su -’? Or is that equivalent? I'd not heard of ‘sudo --login’. <nckx>So many ways to probably not shoot your foot off today. <lfam>That's funny, I mention `sudo --login / -i` constantly :) <lfam>Yes, looks like `sudo su -` does work <nckx>Don't use it but I've seen it, probably following your nick. <the_tubular>Meh, I'm calling podman with he long path and everything seems to work for now <nckx>lfam: What I didn't realise was that it could stand on its own, not just sudo -i COMMAND. <lfam>Also, it's fine to work as root on Guix, I do it all the time. You just have to remember that managing packages with Guix is per-user, and act accordingly. If that's confusing, then I agree that you shouldn't log in as root until you grok it <nckx>Keeps things interesting! Which is good. You don't want privilege escalation to be boring or predictable, that's how accidents happen. <lfam>It so interesting to me, how old-school distros smoothed out most of the weirdness of these overlapping tools from different generations of UNIX <lfam>It's truly a heap of ... well-loved old stuff <nckx>First you stop juggling the chainsaw, then you get cocky. <rekado>yup, changed-inputs in (guix upstream) expects labels <lfam>Anyways, in Guix the edges are still sharp <the_tubular>To be fair, smoothing the experience is a thing, but the best would be that the best tool for the use-case survived and the rest faded out. <rekado>a sharp blade is a safe bl… ouch, sliced my finger! <lfam>I've been wondering if we can remove `su` <lfam>GNU's not UNIX, and Guix is not "Linux" <the_tubular>Just poke me if you ever do, I'll reinstall sudo before lol <lfam>I think it would be sudo, since that's well-integrated with the rest of the system <lfam>Don't worry... it would be a long and careful process, removing su <the_tubular>sudo has a iffy history though from a security perspective <lfam>But, "how to escalate privileges" is a common source of confusion for Guix users <the_tubular>Yeah ... They got hit with huge CVE's and also it is very easy to misconfigure sudo. <lfam>I mean, every project that gets used widely has a lot of CVEs. That's how you know people use it ;) <lfam>Configuration is definitely important <lfam>I'm more worried about programs that don't have a history of security disclosures. It means that nobody tried to break them yet <lfam>It's not a metric, one way or the other, in my opinion <the_tubular>A lot of feature 99% of people don't even know about <lfam>I've noticed that people don't know how to use `su` properly either ;) <nckx>sudo isn't supposed to be simple. <lfam>Anyways, don't worry. This isn't a change that would be made lightly <lfam>I'm not talking about you, but everyone <lfam>`su` didn't work correctly on Guix for several years, until we did the ENV_SUPATH thing <lfam>Nobody seemed to notice or understand <lfam>Overall, the situation with authorized privilege escalation is really complicated <lfam>The security model is very brittle, I think <the_tubular>Here, I took the even dumber way and aliased /gnu/store/8lnpqdx5jadyc1g2k8wlr3xfp6s0jpf5-podman-3.4.4/bin/podman to podman <the_tubular>I probably defeated the whole purpose of guix doing so ... but <SeerLite[m]>jpoiret: Yeah I need both java versions at the same time as inputs for a package which uses both at the same time. Doesn't matter anyway as I looked at the source and the places it looks for java are hardcoded for FHS, so I'll have to patch it <ixmpp>> that's just the simplest solution™ <nckx>mount -o remount,mode=6755 / ***lukedashjr is now known as luke-jr
***lukedashjr is now known as luke-jr
<asdf-uio`>>> <lfam> GNU's not UNIX, and Guix is not "Linux" <asdf-uio`>But we could add some vocals to fix that: genial ;) <vagrantc>i've started getting help-guix messages where help-guix is neither in the To or Cc field, so replying doesn't include help-guix <nckx><20220104184100.0eb20290@primary_laptop> has it, as [person] via <help-guix@…>. <nckx>asdf-uio`: Perhaps, to reduce confusion, we should call it GALACTURD (GNU and Linux are completely, totally, utterly, radically different things). <nckx>It rolls off the tongue and other things. <vagrantc>nckx: Message-ID: <20220104184100.0eb20290@primary_laptop> <vagrantc>i'm not in to: or cc: but get messages via help-guix <podiki[m]>we have spdlog built as static (how it is typically used), but doesn't build with -fpic; anything I should check when adding that? tried one dependent and built fine with the change <fproverbio>does anyone have experience with vfio pci passthrough? i was trying to surrender a raid controller to a virtual machine to retrieve some data but the device in question is still not grabbed by vfio-pci at boot time, for completeness sake i tried both the etc-service-type and the kernel commandline in my config.scm but still no dice <podiki[m]>I used vfio a long time ago, and not on guix. I know it is tricky with iomuu groups, bios options, etc.; do you know it can work not on guix? <nckx>vagrantc: AFAICT I'm not addressed anywhere in that message either. <fproverbio>podiki[m]: sure, as a matter of fact i ran proxmox on the very same computer and vfio worked on it (debian) <fproverbio>to be fair, i can blacklist the driver so the commandline argument is working <vldn[m]>i used it on nixos and it was a breeze with the declarative config <fproverbio>i unfortunately didn't find any example on the net of such setup, just a reddit thread that is basically unresolved <podiki[m]>hrm. I would check all the boot options, but that's all I can think of right now. somethign else must be grabbing it first <vldn[m]>if you are on nix and search a command just time man configuration.nix and you get the man with all options <fproverbio>used nix before but never really modified the default configuration <podiki[m]>probably want to see the default kernel boot options in guix in case it is something there? or kernel options themselves <fproverbio>stubbing might be te answer, although i already tried "vfio-pci.ids=..." <fproverbio>podiki[m] vldn[m]: i'll check thanks for the pointers <podiki[m]>good luck! vfio was pretty cool when I used it, after I got it working (did gpu pass through for a certain non-free OS...) <podiki[m]>anyone know how to tell meson to link with a static library when both are available? found via pkgconfig I believe (all stuff I know very little about) <fproverbio>podiki[m]: i've been doing gpu passthrough for a while actually, this time is for a much more noble goal (data retrieval of a zfs pool) ^^ <podiki[m]>(not finding it in the main docs, but it worked for me) <nckx>‘Meson will do some magic’. <nckx>Presented without comment. <podiki[m]>like seeing a code comment before an indecipherable block: "magic happens here" <podiki[m]>and wow, I think I see why this package (mangohud) wanted a static library from the imgui toolkit, eliminates like 2/3s of the ldd output <nckx>I once had to debug Meson ‘magically’ invoking pksu(!) (!!!!!!) (???) (!). *vivien imagines pksu must be a terrible program <podiki[m]>pksu...no idea but scary combination of letters <fproverbio>podiki[m]: mangohud rocks though, really useful program <podiki[m]>well look for it coming to a guix near you later today, just gotta submit these patches <fproverbio>i have some emacs packages (dead easy o package i know) ready and the chia blockchain in the works <asdf-uio`>I am trying to package cl+ssl, a dependency of a dependency of another package. I added openssl to its inputs, but I still get this message: 'Unable to load any of the alternatives: <asdf-uio`> ("libcrypto.so.1.1" "libcrypto.so.1.0.0" "libcrypto.so")' <asdf-uio`> How can I check what openssl installs exactly? I tried 'guix install --dry-run' and looked at the generated derivation, but I don't find any libcrypto inside it. <fproverbio>no idea on how to contribute, my foss life has been very short <podiki[m]>the patches for mango required some work, but wasn't the worst. not sure about some changes I needed, like pciutils without zlib (hw ids) <podiki[m]>asdf-uio`: did you look at what is in the package? meaning if you build/install it and look in its store directory <podiki[m]>fproverbio: contributing packages is a good way, there's plenty of info in the manual, and I read lots of packages and patches to get the hang of it <fproverbio>podiki[m]: very short on time right now, i'll look into it as soon as possible <podiki[m]>no worries, but always good to have more contributors here <fproverbio>podiki[m]: i'm looking forward to contribute, it would be an honor for me ^^ <asdf-uio`>podiki[m]: No, I'll do that. I don't really know my way around Guix yet. <podiki[m]>feels good to make it into what you want and help out others, as one that uses so much good free software <podiki[m]>asdf-uio`: I like doing tree $(guix build package) these days <podiki[m]>or maybe a guix build package -n (dry run) first to make sure it won't take too long if there isn't a substitute <fproverbio>podiki[m]: the packages are: emacs-meow, emacs-circadian, emacs-nano-theme, emacs-nano-modeline, emacs-nano-agenda <podiki[m]>ooo the nano packages! been meaning to try them <fproverbio>podiki[m]: gorgeous i must say, circadian automatically switches the theme based on latitude <fproverbio>i'm currently on nano-dark, been on nano-light up until 4:30pm <podiki[m]>on that front I have a package of darkman I need to submit; it is a little daemon for switching light/dark mode for whatever you want using scripts <podiki[m]>so I'm just on a window manager and use it so that my browser and emacs switch based on sunrise/set time <podiki[m]>for emacs I have a custom function that gets called, but I'll check out circadian; theme switching is a little wonky in emacs sometimes <podiki[m]>no, been meaning to try it out more, but need my extensions :) <fproverbio>i see, well i can say that it's good, really good <fproverbio>i never knew i wanted a repl in a browser up until i discovered it <fproverbio>last time i messed with it i implemented a mode to hint urls in a page and play the selection in mpv <asdf-uio`>It looks like it's an issue with the path since the file name is among those cl+ssl looks for: <asdf-uio`>tree (guix build openssl -n) | grep libcrypto <asdf-uio`> /gnu/store/rgcmkr9l0mxlwgvdxfs5cc5gwyzq08vq-openssl-1.1.1l-doc <asdf-uio`> /gnu/store/cs1kihs34ccqhc69yx0c4kaf3rkiwyyy-openssl-1.1.1l <asdf-uio`> /gnu/store/1lp25m9j3g4418dvbvpvaqnajfcvzsrn-openssl-1.1.1l-static ***ChanServ sets mode: +o nckx
<asdf-uio`>btw podiki[m]: what did you mean by "(oh woah, your backtick did something)"? <nckx>asdf-uio`: Please use a pastebin for multi-line pastes. We recommend the one in the topic. ***ChanServ sets mode: -o nckx
<nckx>‘Multi’ being ‘roughly over like 3 or so or something’. <podiki[m]>asdf-uio`: I meant that on my end the formatting changed (connected via Matrix client) <asdf-uio`>Sorry, I'll try next time. I thought it'd be short enough to be ok without a paste bin. <nckx>It was borderline, I was bracing for more :) <nckx>When the tree(1) output popped in I didn't know what to think. <podiki[m]>could be that your package has hardcoded paths where it tries to find the library <asdf-uio`>nckx: completely understandable. without grep it was even too long for tmux history... <podiki[m]>a search in the source for "libcrypto" might be good, or see if it is trying to use the ld cache maybe <podiki[m]>but most often I see just a hardcoded path for the library <asdf-uio`>It seemed to show a lot more than just openssl. I saw 'incudine' in there, which is a music live coding environment in common lisp. <podiki[m]>it might have had a lot of paths if it was downloading/building dependencies of openssl; my earlier tip was more for when guix build <package> just spits out the store line (meaning it is already present) <podiki[m]>probably if you ran it again it would be shorter, but openssl has a few things in it <podiki[m]>good luck! I should take a guix break and then will send the mangohud patches <asdf-uio`>Thanks, enjoy your break! I tried taking a break, too, but it wascut short because I want to fix this. <float>is symlink-manager available to use for Guix Home configurations? <asdf-uio`>It looks like I'll have to modify the common lisp cffi library. Is there a default way to locate shared libraries in Guix? <asdf-uio`>failed to open library: libcrypto.so.1.1: cannot open shared object file: No such file or directory <asdf-uio`>I had another look at the article, noticed that it said 'ldd' was part of 'glibc' and installed it, but I soon realized I can't even follow the article, let alone know how to use 'ldd'. <rekado>one of the glibc outputs does indeed provide ldd <rekado>you use ldd by giving it an executabl <rekado>it will print the list of libraries that the argument needs and where these libraries are <apteryx>rekado: what are the available storage interfaces on Berlin? <apteryx>Does it support something like NVMe/PCIe 4.0? Which form factor would be best? 2.5 inch vs E1.L ? <apteryx>do you have the spec fo the server? I can look it up myself <opalvaults[m]>has anyone experienced troubles going to and from login/display managers? I have two computers A and B. The configuration on A is GDM, the configuration on B is SDDM. When I try to switch B from SDDM -> GDM, GDM does not load correctly and stops after the elogind is using pid blahblah message on the TTY <opalvaults[m]>The configuration on computer A, is the one I'm using on computer B (with bootloader/uuid stuff changed obviously). So they are in essence the same configuration file. <rekado>apteryx: we also have a whole bunch of PowerEdge R6415, and one old PowerEdge R630 <opalvaults[m]>It would appear that the switch from SDDM to GDM breaks the reproducibility of configurations between Guix installations/machines <apteryx>rekado: seems to have lots of storage bays: Up to 24 x 2.5" SATA/SAS/NVMe (this is just for the front bay) <rekado>opalvaults[m]: these things all leave behind state, e.g. cache files, configs etc <rekado>apteryx: yes. Going forward we wanted to make more storage available locally <rekado>if we get the green light to buy new hardware <opalvaults[m]>rekado: this tells me that Guix is not reproducible via its configuration file then? <akirakyle>opalvaults[m] are both machines the same architecture? ***Noisytoot_ is now known as Noisytoot
<opalvaults[m]>Hardware is probably different in that one is a newer Dell and the other a newer thinkpad <rekado>apteryx: that’s PCIe 4, but the server only has PCIe 3. <akirakyle>opalvaults[m] okay there was a chance if they are different arches that it was due to a recent change where guix conditionally using gdm only on x86_64 but sddm everywhere else which has caused some issues for me on aarch64 <apteryx>PCIe 4 should be able to operate as PCIe 3, although with a loss in performance <opalvaults[m]>akirakyle: just to make sure i double checked with uname -a and indeed both of these laptops are x86_64 <akirakyle>opalvaults[m]: to answer your question, guix is only reproducible starting from the same providence: so on both machines you'd need guix describe to output the same guix commit <opalvaults[m]>the interesting thing is that I originally had GDM on this laptop before switching to SDDM. It breaks after attempting to go back to GDM. I've actually experienced this twice in trying to change SDDM -> GDM <rekado>apteryx: I naively think this would matter here. 30TB in one device vs several devices. <rekado>apteryx: are you thinking about buying a disk for us? <vldn[m]>@fproverbio do you use vfio-pci and gpu passthrough with guix? <opalvaults[m]>akirakyle: would this be in the commit section? they were both installed using the same USB with the same guix version? <jpoiret>opalvaults[m]: could you try going to a TTY and doing `chown gdm:gdm -R /var/lib/gdm`? <apteryx>rekado: in my experience the much improved seek times of solid storage obliterates anything multiple HDD might be able to do in RAID. <asdf-uio`>rekado: thanks. That's all over my head at the moment. But it turns out I don't have to figure that out for now: sbcl-cl+ssl is already provided by lisp-xyz. The reason I thought it wasn't is that 'guix search sbcl-cl+ssl' does not return anything. By chance I tried 'guix edit sbcl-cl+ssl' which showed me the original package instead of the one I was trying to create. I'll try to figure out the remaining errors tomorrow. <rekado>apteryx: I’d like to use SSDs too. Reliability is a concern, though. <jpoiret>although it shouldn't be the problem, but you're never too sure. Also, you can enable (debug? #t) in the gdm-configuration to get a better syslog output <rekado>apteryx: I’d rather have a bunch of 6 to 8 TB SSDs in a big RAID than two or three 30TB disks <apteryx>rekado: that's why I'm looking at intel; they are the toughest things on the market when it comes to reliability, SSD wise (samsung must come close too, but they don't seem to offer such as high capacity drive yet). <opalvaults[m]>jpoiret: there is no gdm user on this system. I'm rolled back at the moment so it may be that it just isn't part of the configuration <jpoiret> yes, if you rolled back there is no gdm user anymore <apteryx>rekado: I don't see the benefits of RAID when using SSDs (unless you have money to throw on RAID 1) <cbaines>I still think it's much easier to just have a small store, rather than try and throw money and hardware at the problem of having a large store <jpoiret>but i don't think that's the problem. I suggest using (debug? #t) in the gdm-configuration <akirakyle>opalvaults[m]: yes if you want your guix system to be the same on both systems, (at the very least) the commits should in guix describe should be the same. The fact they were both installed using the same guix installer won't matter if you have issued guix pull at different times on each machine <opalvaults[m]>for transparency, here is the configuration file that I'm attempting to apply: <apteryx>raid 0 with multiple smaller drives would multiply the odds of a failure <cbaines>hard drives are a good fit for serving substitutes apteryx, if you just avoid importing the nars in to a large store <nckx><I don't see the benefits of RAID when using SSDs, unless> I think RAID1 is a must either way. We all seem to have wildly different opinions on storage. <cbaines>nckx, although I think no on machine redundancy is OK if you have multiple machines <nckx>OK, that's a hypothetical alternative we could discuss. <apteryx>cbaines: hi! I'd agree if the use case was purely serving files over HTTP, but here we're talking about having faster storage on the head node of the main build farm (berlin), which accumulates items from all workers. <opalvaults[m]>jpoiret: what is the syntax for this addition of debug? I don't have a gdm-configuration declaration. this is a stock from installer services block <cbaines>nckx, it's not hypothetical any more, that's the model now behind bordeaux.guix.gnu.org, the majority of the substitutes are stored on two machines (duplicated) <nckx>cbaines: Are you working on such a thing, and if so, have you published an overview of what you're working on? <cbaines>apteryx, it's avoiding that unnecessary and wasteful accumalating of files that I'm talking about. Why create a nar on a worker, send it to berlin, unpack it in to the store, only to go and create a nar again to serve? <nckx>For a tiny project we sure have very many models of doing CI. <apteryx>cbaines: how practical would that scheme be with the architecture of Cuirass as deployed on Berlin? <vivien>Is there a way to run a cron job 5 minutes after boot, and not after that? I’d like to restart some network services after networkmanager has negociated all its IP addresses. <nckx>cbaines: See, it was not immediately clear the first time I read this that it implied getting rid of the one true centralised store. More like something that sat *after* guix publish from a single source, and then after nginx. <nckx>It's still not really clear to me now, but blame me, I'm sure :) <cbaines>nckx, no worries, I still wonder if it's quite the right grouping of concerns. <cbaines>you're also right in that it's an "after guix publish" thing, since it just imports narinfos+nars, and then can move the data around <cbaines>but it's that functionality that enables having multiple machines store the same bunch of nars, whether for mirroring or for redundant storage <nckx>So using it to tackle the humungostore implies running guix publish on each build node? Because I still don't see how this saves a ‘round trip’ just yet. It could reduce the time you need to keep live items on the head node, yes, if you actively poll its nginx and extract the nars as soon as they are ready, cache them somewhere else, then frequently GC the store. <apteryx>the thing is we need something that allows 'guix gc' to work on Berlin in 2 weeks time, ideally, else we'll face running out of space. I don't really see how that scheme can fit in the current architecture of Cuirass to solve this, it'd probably need more thoughts and time. Equipping Berlin with SSD storage is something relatively inexpensive we can do that will have a long lasting positive impact <cbaines>nckx, guix publish is already running on each ci.guix.gnu.org build node I believe. <cbaines>apteryx, I do find the time constraint a bit funny and sad, since this "large store is hard" issue has been an issue for years <cbaines>and I think work in that time has yeilded results <nckx>cbaines: I thought it was just running to do what you wish to avoid, ferry results back to the head node, not directly to storage servers. <nckx>Basically, replacing the last SSH transfer of ‘guix offload’. <cbaines>nckx, I'm not against moving data through a "head node" <cbaines>it just seems that avoiding taking the nar, and putting it in the store could both save time, and help avoid the problems associated with a large store <rekado>cbaines: small store is fine, though we’re also having a huge cache <rekado>we’re already pretty sure we’ll dump the big /gnu/store <rekado>but before that we’ll need to copy the cache of substitutes to avoid downtime <rekado>so the most urgent issue is to expand storage on bordeaux <rekado>so we can serve substitutes from there while we trash /gnu/store with a quick reinstall of berlin. <opalvaults[m]>jpoiret: it still hangs at login prompt (more accurately, the elogind tty message which I assume is a red herring). GDM does not produce any output, nor can I switch TTY's <rekado>apteryx: without RAID and with huge SSDs you’re just one error away from losing it all. <cbaines>rekado, trying to add storage to bayfront does seem like a hard path to take <cbaines>couldn't we just hire a machine with 10+ TB of storage from the likes of Hetzner for a month? <jpoiret>oh, you can't switch TTYs? that's quite annoying then... <cbaines>that would cost only hundreds of euros, and would be available in days, without requiring any physical handling of hardware <opalvaults[m]>akirakyle: to your point about commits, I'd understand if it was a mismatch of package versions or something but this isn't the case. In the case of a caching error where artifacts are left behind on a read-only filesystem that leaves me unable to make reproducible changes even if it were due to that <opalvaults[m]>jpoiret: it's just the usuall message about elogind already using PID X <rekado>cbaines: bayfront is already among the default substitute servers <jpoiret>and debug? #t only tells gdm to log things to syslog, if you rollback and inspect /var/log/messages, you'll see what GDM had to say <rekado>so using bayfront (or at least the same DNS name) allows us to provide substitutes without user intervention <cbaines>bordeaux.guix.gnu.org is a default substitute server at least <cbaines>but it would make more sense to me to just change where ci.guix.gnu.org points to where the substitutes are? <cbaines>rather than trying to switch out/combine the sets of substitutes served from bordeaux.guix.gnu.org <jpoiret>unfortunately i really have to go to sleep now, i'm super tired, so i hope someone can take over <jpoiret>if not, you could open a bug report or reply to an existing one with your issue <opalvaults[m]>this is on a work computer unfortunately so I'll likely need to reinstall <opalvaults[m]>it appears according to the debug log that GDM isn't really having any issue starting? <apteryx>rekado: if we want 30 TB of storage you could add multiple smaller disks in a RAID 0, but that's RAID 0 (worst than one disk in terms of reliability). RAID 1 is twice the price; which is significant for SSD. We could have daily backups to slower storage. <jpoiret>opalvaults[m]: could you also look at /var/log/debug and /var/log/greeter/*? <opalvaults[m]>jpoiret: the one i linked is /log/debug but i'll do greeter as well <fproverbio>apteryx: how about mergerfs with some custom policy? <opalvaults[m]>I am skeptical that I am doing this services block correctly <nckx>opalvaults[m]: Around %desktop-services. <nckx>You're replacing it with its modified value. <opalvaults[m]>and then at the very end have %desktop-services? What am I appending to? <nckx>Those modified %desktop-services. <apteryx>fproverbio: that's the same result as raid 0 in terms of reliability (data integrity depends on N disks instead of 1), correct? <opalvaults[m]>albeit they have to be the two "right disks" of failure. potentially two of the "wrong" disks could fail and then in that case it's 1 drive failure tolerance *jonsger uses no RAID on "his" substitution server. The recovery "concept" are the config.scm files :P <nckx>opalvaults[m]: <why not> Cost. <opalvaults[m]>we use raid 6 on just about any host carrying data that can handle it i.e. more than 4 drives <opalvaults[m]>It's just a setting in a raid card. if you have a raid card that can raid 6 it's no extra cost and it's the same minimum amount of drives as raid 10 <nckx>You asked why, I answered. <nckx>Saying ‘it's just foo’ isn't adding new info. <opalvaults[m]>Right but why kick around mirrored RAID when alternatives, especially with SSD's are incredibly fast <nckx>I don't think stuffing literal apples or oranges into the drive bays would end well, warranty-wise, so don't have an answer. <opalvaults[m]>It's a 4 minimum on RAID 10 so that's barely anything, and if there's a big I/O need RAID 6 on SSD's can still meet DB needs. <opalvaults[m]>that is, you can use it on high frequency DB hosts and it handles read/write i/o no problem. <nckx>opalvaults[m]: RAID1 requires two drives to store the same amount of data as one drive without RAID. It's that simple. <nckx>Actually, that's literally what apteryx said above. <opalvaults[m]>nckx: i'm aware of what RAID1 is capable of. Do you only have 2 drives to work with? <nckx>This is all in the backlog. <rekado>we currently have a RAID 10 with 10 disks; effective capacity is 36.36 TB. <opalvaults[m]>i used to work in datacenters so I'm asking questions from a point of professional experience. <opalvaults[m]>rekado: so that's around 70 TB of gross capacity. RAID 6 would allow for only two drives capacity to be lost <float>is there an ideal way to manage dotfiles with symlinks through guix? <rekado>(we’re using RAID 6 elsewhere, just not on this array) <float>opalvaults: I am using it now, what's the best way to manage symlinks to say, something like .emacs.d? <opalvaults[m]>rekado: gotcha. I think it could be worth it to switch to RAID 6 so as to only lose 14TB of data vs half. <opalvaults[m]>unless you're pushing really traffic through these hosts (or you only have 4 drives), RAID 6 is pretty ideal. Otherwise RAID 10, but then you lose the potential of 2 drive tolerance. <nckx>opalvaults[m]: Didn't seem that way from here, but thanks! <opalvaults[m]>see the section where I'm pushing files from a central dotfiles repo to their respective XDG_CONFIG_DIR using simple-service <opalvaults[m]>it creates symlinks much like any symlink manager like stow would do <opalvaults[m]>nckx: thanks for what? I'm really confused by your attitude towards me right now. <nckx>opalvaults[m]: By the way, berlin currently uses mdraid10. <nckx>opalvaults[m]: For offering to help. <nckx>I've never got the theoretical numbers out of raid6 but that was probably crappy hardware more than anything. <float>opalvaults[m]: I am actually doing something very similar, but I was running into an issue where when I added a package to an org-mode file handling my settings with org-babel it would want to overwrite my init.el file (I assume to edit custom-set-variables) but init.el was read only since it was generated in place by guix home reconfigure. <opalvaults[m]>float: if you don't want org-babel-tangle to overwrite init.el, then make sure to not include :mkdirp yes in the source block <opalvaults[m]>The way I have it set up is tangle configurations, and then run guix home reconfigure. It manages all of my dotfiles including emacs so mine overwrites and symlinks my init.el to .config/emacs/init.el <opalvaults[m]>what guix home does is basically moves the current .config/emacs/init.el (or emacs.d/init.el) to a backup directory in your $HOME, and then replaces it with the new version *podiki[m] listens to opalvaults for future guix home goodness (currently a literate dotfiles + stow life) <nckx>Does it still assume everything starts with a dot? <podiki[m]>basically tangling = taking code blocks from the org file into another file <podiki[m]>and yes, you can put arguments in the top of the file (for all) or per code block or heading <rekado>opalvaults[m]: I’ll try to figure out how we could switch to RAID 6 on this array. 