IRC channel logs
2023-08-21.log
back to list of logs
<mirai>ngz: does the simplified package still work within a ”guix shell --pure dblatex -- dblatex <path to test file>”? <nikolar>you probably need proprietary firmeware to get it to work <nikolar>one option is to plug your phone and enable usb tethering <PotentialUser-59>Or alternatively, what ethernet card can I purchase that doesn't require proprietary firmware? <ngz>mirai: I don't know. Have you tried it? <amjoseph><chipb> "oh no are you jumping ship to guix? ;-P" having more than one boat is generally a good idea. <aarcov>Does anyone know how long it tends to take for a patch submission to be merged into the master branch? <podiki>aarcov: varies wildly on what it is, who sees it, etc. <podiki>one in particular you had in mind? <aarcov>It's my first patch submission, I'm curious as to if I submitted it correctly <aarcov>If it's good, I have a few others I'm looking to submit <podiki>submitted correctly yes, a few quick notes <podiki>looks like some formatting was introduced that shouldn't have been (e.g. change in native-inputs) <podiki>and what is the reason for change to unreleased version? looks like next release is 1.9.6 but it wasn't tagged or released yet; for something like that often you can just use a package transformation to use locally in the meantime <aarcov>podiki, are you refering to the (list glib bin) line? <podiki>yes, either it should be one line for all inputs or one per each line as it was before your change <aarcov>the switching to a git commit is due the the project not having created a formal git tag for 1.9.6 for some reason <podiki>(one line only if it would fit and is I think 5 or less inputs usually) <podiki>in my quick look seems they haven't released a new version yet <aarcov>1.9.6 has about 1years worth of additions, and fixes a problem caused by the newer versions of glibc no longer defining a constant (Something like MAXVAL, don't remember off the top of my head) <podiki>so typically unless there is a particular reason for it, we keep to releases <podiki>okay; so you'd want to note that in a comment I would say <podiki>and I think it would still be version 1.9.5? not sure on that. also revision starts at 0 <aarcov>I haven't been able to figure out how to force it to compile the older versions with glibc-2.29, which should still have the old constant set <podiki>maybe check some other packages that also have a commit since no new version in a long time, I forget the conventions <podiki>I don't know about glibc details or whether you really want to mix that, but someone else will know better (we do have other versions of glibc of course) <podiki>or if it is easier to just use the commit that fixes the problem you see and include that as a patch on top of the 1.9.5 version? <aarcov>podiki, so, it seems `guix style` is changing the native inputs to be compacted to 2 lines <podiki>ah; yeah sometimes it doesn't get some things right <podiki>here since you are just updating the version/commit, I would leave the rest formatted as is (other than the spacing change from the let) <aarcov>ok, so, resubmit it with the native-inputs returned to their original multi-line setup? should I also decrement the revision to 0 for the git commit? <podiki>i would check some package that is also a version + more recent commits to make sure the versioning is correct, but pretty sure revision 0 yes <aarcov>ya, I can drop it to revision '0' <aarcov>I'm seeing a revision '0' in ufetch in packages/admin.scm <podiki>yes, I see lots of 0s and that's what I would probably use, but see ones that start at 1 too. something to document/make a convention properly <podiki>i guess it depends on what is the first revision too, in this case we have a package already, but this is the first "guix revision"? (i guess it doesn't matter much but i get hung up on these little things) <aarcov>should I repatch/amend against the same commit, or pull to the current head and then patch it <aarcov>it probably doesn't matter too much if it is changed from 1.9.5 to 1.9.6-#.<commit> as long as the '#' increments with each change until a 1.9.7 is released? <podiki>pull what to current head? you mean of guix? (shouldn't matter here) <podiki>i think the next release of tilix is still 1.9.6, since they didn't tag or make a release I don't see it as 1.9.6 yet (but i only looked quickly) <aarcov>correct, wasn't sure if they cared if the patch was submitted against the same commit (I've been mostly creating my patches from a temp directory, although I do still have that same folder availible as I haven't rebooted) <aarcov>podiki, so are you saying I should make the base commit be 1.9.5 instead of 1.9.6? <podiki>yes, the way I see it tilix is version 1.9.5 still and now will get a newer commit rather than the 1.9.5 tag <chipb>amjoseph: yeah, it doesn't hurt. I admire lots about the project but can't say I personally enjoyed scheme as much as I thought I might. <adanska>congratulations to the kde team for getting kde merged into main!!! super exciting <adanska>gonna give it a spin now :) i wonder... are you still able to use gdm with kde? i know its not as seamless, but just for testing purposes <adanska>btw, whats wayland support like in kde atm? is it as good as gnome? <iyzsong>adanska: in plasma/wayland basic wm function and IME seems work well, but it can't take a screenshot, screen sharing/recording net tested.. <iyzsong>and its splash screen is long and seems doing nothing, disable it in systemsettings make the desktop start quick.. <adanska>ahhh right... the common pain points are still there haha <amjoseph>well i'm starting from low expectations there. when i made the decision between gentoo/guix/nixpkgs, scheme was literally the only negative for guix. i've since begun to think that i shouldn't let my personal taste in languages matter so much. or maybe just force my tastes to change. <nikolar>amjoseph: what's wrong with scheme, just curious <janneke>dongcarl: any idea if/when mingw built reproducibly? <xelxebar>Ugh. node-build-system doesn't do --production builds, so devDependencies keep getting pulled in. Why?? <civodul>none of them uses this manifest, hm! <janneke>civodul: also, i've been quite conservative still in hurd-manifest.scm, mainly because guix doesn't build (pass the check phase) yet (see hurd-team); but at some point we'll want to attempt a broader selection of packages <janneke>IWBN if people could just pick-up packages with build failures and fix them, PATH_MAX comes to mind, also debian possibly has many fixes that we don't have yet <cbaines>civodul, shepherd on milano-guix-1 is in a bit of a weird state. I don't know if you're interested in taking a look? <civodul>janneke: could you move this file to etc/ next to its friends, and add it to Makefile.am? <civodul>cbaines: sure! do you have more info? <civodul>i'm not sure i can connect to that machine <cbaines>civodul, I think you have a user account at least and I can set you a root password <civodul>cbaines: what's the host name actually? :-) <cbaines>civodul, milano-guix-1.mips.di.unimi.it <civodul>cbaines: so "herd status" hangs, right? <cbaines>I'm not sure, I guess it was working when the machine booted <civodul>ok, i was wondering whether we could find it in /var/log/messages <civodul>problem is that it doesn't go beyond Aug. 11 <civodul>i think rottlog is not doing what we're asking it to do; it's deleting logs too early <civodul>oh, interesting: "herd status nscd" works, for instance <civodul>which prolly means root's fiber is at fault <janneke>civodul: done, pushed as 3c6b6941a2c76c26ebf0c1bfd7f901a22c19dce1 <cbaines>civodul, I don't know much about shepherd, but maybe the problem is connected to a particular service <cbaines>herd status guix-build-coordinator-agent doesn't work <cbaines>and I was trying to restart the service when I noticed this problem <civodul>do you have a history of the "herd" commands before you noticed the problem? <civodul>cbaines: so it looks like the control fiber of 'root' and that of 'guix-build-coordinator-agent' is no longer responding (did they exit? are they blocked on a receive?) <civodul>i don't see how this can happens so far, so we'll need more imagination and ideally more logs <civodul>the process-monitoring fiber is working: if i kill a service's process, it gets restarted <cbaines>civodul, I'm pretty sure I C-c'ed herd restart guix-build-coordinator-agent so maybe that stopped something that would have done get-message later? <cbaines>so maybe something could be blocked on put-message as well <civodul>cbaines: i don't think an EPIPE on the client socket can cause a deadlock internally among the fibers <civodul>so for now i think you'll have to do a hard reboot <civodul>and then we'll have to pay attention to the logs etc. <civodul>i'll report a bug with our findings so far <PotentialUser-52>Hallo, könnte mir hier jemand vielleicht weiterhelfen? Ich weiß das entspricht nicht der Philosophie des Betriebssystems, aber es geht um ein Wifi Treiber von Intel. Wie könnte man Intel Treiber installieren auf Guix OS? Wäre nett wenn mir da jemand helfen könnte. <civodul>janneke: it's building /gnu/store/87zpy94435zf24wy97ni6m3lw314ijsg-hurd-v0.9.git20230216.drv, which is x86_64-linux <civodul>i checked the i586-gnu box and nothing else <janneke>ACTION is finally experimenting with emacs-envrc and it seems an amazing upgrade over M-x guix-set-emacs-environment <janneke>any ideas why guix shell --search-paths omits INFOPATH? <rekado>ngz: apteryx or mbakke would know more about GUIX_TEXMF. It was introduced after my time in the TeX mines. <rekado>initially we used to create a union directory of all texlive packages and embed the location of the union directory in the config file <rekado>GUIX_TEXMF was introduced to do without this extra step of creating a union directory <ngz>rekado: I understand the motivation, but I am missing the consequences. For example, what GUIX_TEXMF is used when a package is defined with (inputs (texlive-updmap.cfg …)), and its executable later called within a user environment, with a different GUIX_TEXMF? <ngz>rekado: Also, I'm currently hit by that modification: "TEXMFROOT = {$GUIX_TEXMF}/..\n". It seems these braces are not always expanded. For example, when running a strace on the `chktex' executable , I see access("{/gnu/store/…-profile/share/texmf-dist}/../texmf-dist/chktex/chktexrc", R_OK) = -1, even though /gnu/store/…-profile/share/texmf-dist/../texmf-dist/chktex/chktexrc does exist. <civodul>janneke: probably because you don't have 'info' nor 'emacs' in that profile? <janneke>civodul: yes! oh my what a picnic -- thanks :) <attila_lendvai_>hello civodul, any hope for shepherd-from-git to be applied? https://issues.guix.gnu.org/61750 it has an issue with cross-compiling due to help2man, but i would suggest to get rid of it altogether, because that man page is of little value. <civodul>attila_lendvai: hi, sorry for dropping the ball <civodul>i guess this approach is less interesting now that shepherd can be used as a channel <attila_lendvai>civodul, i don't see how shepherd from a channel helps my problem. does it help with running `guix system vm` images? my use case is to test/run my guix checkout in a vm to hack/test shepherd in a real-world environment. <civodul>it helps for tests, not for testing indeed <attila_lendvai>a new headache appeared a few weeks ago when trying my custom shepherd leads to rebuilding large packages locally <civodul>the way i work is that i have my "normal" dev envivornment for Shepherd <civodul>then when i want to test it on the bare metal or in a VM, i get it from the channel <attila_lendvai>civodul, i don't know what "get it from the channel" means... :/ do you have anything written up anywhere that i could read? if not, then does that mean that a `./pre-inst-env guix system vm` will run a VM with the shepherd codebase from the channel as the init process? (and not recompile any large packages) <civodul>attila_lendvai: re channel, check out the README in the Shepherd <civodul>i'm looking at the tests/graph.scm test failure <civodul>if anyone has done it before, i'm all ears! <civodul>a regression from 560cb51e7b37e2c6f6fe4b72a3781185c57fdf83 <janneke>civodul: so... etc/release-manifest.scm has (internally) <janneke>(define* (package->manifest-entry* package system #:key target) <janneke> "Return a manifest entry for PACKAGE on SYSTEM, optionally cross-compiled to <janneke>possibly etc/hurd-manifest.scm needs that too? <civodul>janneke: i think it's a bug in (gnu ci), lemme see <gabber`>how can i access the man pages (or the info manual) of a package in a guix shell? i have the man-db and man-pages installed in my home profile, but $(guix shell foo -- man foo) won't do the trick (No manual entry for foo) <janneke>gabber: you also need man-db in the same profile as foo; try: <zamfofex>xelxebar: Maybe you could work around it with an argument. <xelxebar>zamfofex: Yeah, unfortunately, it's the configure step that's the problem, and it's implementation doesn't feed in any user-supplied flags. <xelxebar>Install step specifies --production, so I'm not sure why configure doesn't. <civodul>janneke: 97f062f33c4243fb1fcb53e0806bdf6cd08ac9d6 should fix our manifest problem <xelxebar>Man, trying to package things can be severely demoralizing sometimes. Wasted half of today in a fruitless rabbit hole, trying to get tty-share's server built. Go and Node being abundant sources of pain and gnashing of teeth. <mirai>xelxebar: did you use the importers? <apteryx>ngz: re TEXMF expansion problems, I believe these are caused by assumptions in the upstream files that the path is a single item rather than a collection. It should be fixed there (upstream). <janneke>hurd isn't easily tamed, so it seems <andreas-e>apteryx: Is it new that the texlive "paths" can be paths and not just single directories? <attila_lendvai_>after a guix pull i'm getting "guix system: error: service 'user-processes' provided more than once". any thints? <andreas-e>About 10 years ago, I think only directory names were allowed for TEXMFDIST etc. (well, so my question has to be taken for some value of "new"...) <apteryx>(it's not knew, but poorly tested it seems) <civodul>attila_lendvai: oops, mistake of mine, let me push a fix <apteryx>andreas-e, ngz: the trick is to use { } on a variable such as {$GUIX_TEXMF} in the texmf.cnf configuration file so that it is "expanded" <apteryx>see texlive-libkpathsea for our default texmf.cnf file which makes use of $GUIX_TEXMF <ngz>apteryx: But I think these braces is the source of some issues. <apteryx>ngz: they can probably be fixed! the ability to compose multiple TEXMF trees without resorting to union hacks is valuable. <civodul>mirai: it's trying to tell you (ahem...) that you need to have gnupg installed <civodul>so it can authenticate the source tarball <mirai>adding gnupg doesn't do much I'm afraid <xelxebar>mirai: Well, the go package has a bespoke organization for it's util code, so the importerts didn't catch it. <apteryx>ngz: see rationale in 04a0b1e09abce99857e7930336421ca6d15ae630 ("gnu: texlive-bin: Enable the use of multiple TeX Live trees") if you hadn't stumbled on it already <xelxebar>And there's no node package importer AFAICT <ngz>apteryx: Have you seen my two questions earlier, the first one being about how GUIX_TEXMF behaves when it is set from package inputs through texlive-updmap.cfg and from user profile? <apteryx>ngz: I think the braces may not understood/expanded by all components of TexLive, and this is what should be fixed. <apteryx>ngz: sorry, I missed your earlier questions; would you have a link? <ngz>apteryx: (it was on this chan) What GUIX_TEXMF is used when a package is defined with (inputs (texlive-updmap.cfg …)), and its executable later called within a user environment, with a different GUIX_TEXMF? <ngz>apteryx: what TeX Live system is going to be used in this case, the one from inputs or the one from the profile? <attila_lendvai>ACTION pings civodul about the earlyoom fix (assuming that the fix is trivial) <apteryx>ngz: I forgot how updmap.cfg works; I guess it's discovered from GUIX_TEXMF itself? <apteryx>ngz: at any rate, GUIX_TEXMF is what defines what texlive components get used at any time <apteryx>so texlive-updmap.cfg is typically useful at build time, where there is no profile. For a user profile, it seems we now regenerate it via the texlive-font-maps profile hook <apteryx>cbaines: maybe until qa has enough x86 machines to build we could suspend building for i686? <apteryx>berlin will fill in the gaps for that <apteryx>mirai: you have to enter 'y RET' when prompted to add the key to your keyring <apteryx>oh I guess you did and then it failed? <mirai>weird, it works within a `guix build --source'… but it craps out with shell <mirai>and it insists on asking if I'd like to add the key (even though I just added it during the guix build ??) <apteryx>can I filter for "new failure" / "broken" on cuirass? <mirai>does guix have something like guixrc <mirai>I'd like to get longer backtrace lines (the truncated output is nearly useless) <apteryx>but that only works for code ran as your user <apteryx>(no the one processed by the daemon) <mirai>ok, COLUMNS does allow me to get slightly more output, though the underscores would be a nice to have <martin>hi, I am trying to use an external monitor with guix system installed on my computer, but the monitor does not receive any signal. Any advice on setting up external monitors with guix system? <apteryx>not sure what you use; a desktop environment such as GNOME should allow you to configure it via the GUI <apteryx>otherwise for minimal X environments I use xrandr <attila_lendvai>i just got a "guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function." <martin>apteryx, thank you. I am using i3, so I will try using xrandr + autorandr <mirai>ok, wtf, `guix shell gnupg automake --with-version=automake=1.15.1' fails since it can't find gpgv <mirai>BUT this 'guix shell gnupg -- guix shell automake --with-version=automake=1.15.1' works? <mirai>ah, I think I see _why_: guix doesn't yet see gnupg while its building the new shell environment <mirai>though the error is incredibly obtuse since answering the prompt makes things worse (backtrace) than not answering (exit) <martin>podiki, arandr is cool! I just tried it, and it seems easy and effective. Thanks! <podiki>martin: welcome! simple and quick for what i need <podiki>martin: it can also save a layout as a simple script with the xrandr commands to reproduce <martin>podiki: I was able to save my docked layout and my non-docked layout, but do you know if arandr should automatically switch between them? It seems like I might have to open arandr and "open" the layout that I want to use <podiki>i've never tried anything like that, probably you need something else to trigger on something (seeing a device appear/disappear) and then run the correct script <podiki>(arandr is just a little frontend to xrandr i believe) <martin>one more (unrelated) question: what is the "guix way" to add a script to my path? ~/.guix_profile/bin is read-only, so I am not sure if I should use sudo to add a file to it? Or is there another way? <andreas-e>martin: I would put it wherever you want and extend the path. <andreas-e>For instance, I have scripts in $HOME/local/bin and a line "export PATH=$HOME/local/bin:$PATH" in my .bashrc. <andreas-e>Maybe this can also be handled with "guix home", but the above is a solution independent of the distribution. <martin>andreas-e: thanks, I'll try that <apteryx>ngz: seems like 6d13afcd7a05e05860835833cca4b2d1f4750fc5 caused a rebuild of qt ? <mirai>do guix inferiors actually work? it seems to poorly handle missing/gone patches <apteryx>ngz: ah, nevermind, I think the board shows all packages <apteryx>evaluation of qtbase is #654346, which is older <Altadil>Hi, I’m trying to figure out guix packaging. I need to use guix download to determine the hash I need to put in the package description. But I can’t figure out the URL I should give it. The package’s source is on github so I’m copying the way it’s done for others, with git-fetch. But I don’t get what url it’s going to evaluate to. Any pointers ? <apteryx>it'll just call 'git fetch' on that URL <apteryx>to figure out the hash you can clone it somewhere, *checkout the exact version tag*, then 'guix hash -rx .' from within the checkout <janneke>yeah, guix download doesn't support/detect git urls <zamfofex>Altadil: A simple solution is writing a random hash and replacing it with the one Guix gives you when it fails to verify it. <Altadil>zamfofex: Oh, that’s a nice hack! Thanks :) <geri>hey, what particular services/packages do i need for my laptop to be able to wake up after i open a closed lid? <jpoiret>geri: does it go to deep sleep when you close the lid? <geri>yeah, it can't wake up unless i press the poweroff button <jpoiret>if it does not wake up when you open the lid, well it's probably an annoying acpi problem <jpoiret>i dunno exactly how that works though, but it doesn't have to do with services/packages <jpoiret>you should look into generic "linux [my model]" queries <geri>it didn't happen when i used %desktop-services, but i literally need to crop out half of it so i prefer to specify packages manually <geri>that upower-service-type doesn't help, im afraid it's gonna be something as weird as what happened w/ dunst <geri>i.e. you need network-manager-applet for dunst to work <geri>(it was a bug that a guy here fixed already) <amjoseph>nikolar well, er, i sort of like infix operators, like the ones mathematicians use :) but i will try to learn to live without them. <geri>imo it's one of the cool things about lisp - syntax as simple as it gets <geri>easy to learn too, even if weird at first <amjoseph>geri simple for machines i guess. every time i look at scheme or lisp i feel like I'm feeding GIMPLE directly to gcc. but i will give it a chance. <geri>it's simple for everyone - it's always function and rest are arguments <amjoseph>btw, does guix have something like crate2nix? this is the tool that turns a Cargo.lock into a huge pile of derivations, one per crate, each of which uses rustc directly (cargo is not involved). this is as opposed to the usual way of building which runs `cargo build` in one huge derivation. <geri>problem is we're very much not used to it <amjoseph>the benefit of crate2nix is that the build can be distributed across multiple machines, and those subderivations can be cached and shared between parent derivations. <jpoiret>we already have an unsatisfying cargo-build-system <jpoiret>geri: I think the "easy to learn" part goes away in Guix with all the weird stuff like g-exps and monads <geri>guix itself for sure, i was talking abt lisps <amjoseph>finding out that you guys treat the store as a monad was a big "a ha" moment <geri>i keep forgetting what a monad was... <geri>something that lets you do side effects iirc <jpoiret>it's just a monoid in the category of endofunctors, why 😈 <geri>can you speak english instead please :D <jpoiret>amjoseph: the store monad is really just a state monad in disguise <amjoseph>jpoiret hrm... but operations on the store monad occur in the build sandbox, right? <amjoseph>ACTION will need to read more about the store monad <jpoiret>what happens in the build sandbox is what's inside of g-exps <jpoiret>the store monad just encapsulates Guile code that need a connection to the guix daemon <jpoiret>so that you have one running connection <jpoiret>there's also some caching going on, hence why it's not just a reader monad <jpoiret>then you lower gexps to derivations and ask the daemon to build that <jpoiret>but the Guile code itself that runs under the store monad is just regular Guile code that can `rm -rf $HOME` <jpoiret>(that guile code is part of Guix, so it shouldn't do that) <amjoseph>jpoiret okay, "store monad encapsulates the daemon connection" makes a lot of sense to me. but being able to mutate stuff outside of /gnu/store seems scary and not right... is there a reason for that? <jpoiret>well, you do want to change the target of your ~/.guix-profile symlink, right? <jpoiret>at some point there *has* to be some mutation <amjoseph>one of the things I like about nix is that I can `nix-build` random nix code from people I don't trust, and as long as there isn't a sandbox escape, I don't have to worry about it `rm -rf $HOME`ing me. <geri>sec, scrubbing my melted brain off the floor <jpoiret>amjoseph: well yeah, if you add a random channel, it can totally `rm -rf $HOME` if you try to build its package <jpoiret>Guix is not designed to deal with that <jpoiret>right, but it's also how channels can roll out entire new features <geri>+1 reason to read the code you run <jpoiret>Guix Home originated from another channel <amjoseph>imho the only mutation should be (a) creating things in /gnu/store and (b) creating or modifying symlinks that point into /gnu/store <mirai>amjoseph: well, tbh I don't see problems with it <jonsger>ACTION tries to get his Nitrokey 3 working as FIDO/U2F key... <mirai>if you add a channel you are trusting it <jpoiret>amjoseph: but you can't restrict that with a general purpose language <amjoseph>i guess i consider not having to read the code **inside {nix,guix}-build** to be a valuable feature <jpoiret>and yes, as mirai implies, if you use a channel, there's no difference between its build code being able to `rm -rf` and the binary it builds doing `rm -rf` later on <mirai>putting a fake 'bash' package in the channel that does rm -rf accomplishes the same if you ask me <amjoseph>it lets me run testcases sent in by random people i don't necessarily trust <jpoiret>i wouldn't really say the sandboxing is a *security* feature, but rather a *reproducibility* feature <amjoseph>jpoiret forget channels for a moment. i'm just talking about `guix build`. <mirai>guix build is within its own bubble <jpoiret>amjoseph: but if you don't have channels then `guix build` means you trust Guix, same as nix <jpoiret>sure, some Guix code *could* do `rm -rf`, but Nix could just as well <mirai>a rm -rf within a build phase doesn't do anything (I think?) <jpoiret>well it does rm all the build files :) <geri>sandboxing `rm -rf ~` sounds funny <amjoseph>mirai "guix build is within its own bubble" <- so it can't `rm -rf $HOME`? i was hoping that it could not. <mirai>it doesn't even have a $HOME lol <jonsger>the boot time of the hydra workers looks a bit old: 12 Nov 2022 15:02... <jpoiret>(arguments (list #:tests (begin (goo goo ga ga) #t)) in a package definition will execute (goo goo ga ga) when building <amjoseph>jpoiret, you cannot `rm -rf $HOME` by feeding malicious *.nix files to `nix-build`. <mirai>surely some kernel exploit would break a build phase too but the only safeguard in that respect is to unplug the pc <mirai>jpoiret: ah, I was only considering “staged” code <jpoiret>whereas in a package definition in guix you can <jpoiret>mirai: yes, in nix there's no real "unstaged" code compared to guix <amjoseph>ACTION needs to learn what staged code is <jpoiret>although they might have had to invent it at some point <geri>code that hadn't been run ig amjoseph <geri>nix is a real pain to work with honestly <jpoiret>staged code is some code that you carry as data to run later <amjoseph>geri the syntax is definitely very weird. but it's basically just haskell without types. <jpoiret>in guix, staged code (represented by gexp), is used for build phases <amjoseph>jpoiret so i guess my question is: why is unstaged code allowed to write to the disk? <jpoiret>amjoseph: because everything is Guile in Guix <mirai>unstaged is running on the host <jpoiret>your package definitions are Guile code that also contain some staged code <amjoseph>jpoiret but isn't there some limited subset of Guile that can't make system calls? <geri>the problem is i wanna have a cool directory structure and nix just says "recurion lol" <geri>guile actually lets me decide what i wanna do <jpoiret>amjoseph: there can be, but it's quite complicated <amjoseph>i would think that's what you would want to use for the unstaged code. <jpoiret>it's possible to add some sandboxing to Guile but I'm not sure it's watertight <jpoiret>but again it's the power of Guix compared to Guile <mirai>perhaps to gnu/packages only but aren't we going to a DSL with that route <jpoiret>if you want you can generate packages on the fly by polling a crates.io page or whatnot <amjoseph>hrm, okay, i guess i will add this to my list of philosophical differences between nix and guix. it's a pretty fundamental property of nix that evaluating a *.nix file cannot have any side effects beyond creating derivations. <jpoiret>right, but you can also say that evaluating a nix file can't do anything interesting 🙃 <apteryx>cbaines: now it's moved to "Exception checking changes between merge base and master." (qt-updates) branch <geri>jpoiret: like rm -rf $HOME <mirai>amjoseph: I might be wrong here, but the equivalent of the .nix file here would be a .drv <amjoseph>jpoiret exactly! building derivations is how you do interesting things :) <jpoiret>mirai: not really, .drv are just a lower-level representation of things to build, guix and nix both have them <jpoiret>the nix DSL is a higher level language to create these, just as we have gexps + scheme <amjoseph>jpoiret one thing I really like about guix is that it's the same language on "both sides" of the daemon connection <amjoseph>you guys write your packages in scheme, and the builder is (usually) a scheme interpreter <mirai>hmm… then perhaps in nix is .nix DSL -> .drv whereas guix can be thought as YOUR_FAVOURITE_LANG_HERE used to write a .drv file? <amjoseph>nix, on the other hand, uses nix to write packages and bash (barf) to build them <jpoiret>being able to do interesting things with the scripts is really a hacker's paradise, guix has had lots of very experimental features implemented by just ... writing some scheme code <jpoiret>mirai: yes as long as YOUR_FAVOURITE_LANG_HERE meant Guile <apteryx>ugh, the "cannot build missing derivation" is plaguing the aarch64 builders <amjoseph>jpoiret are there good examples of unstaged code in guix/packages that need to write to the disk? <amjoseph>i'm curious how much stuff would break if guix's unstaged code were untrusted like nix's is <nckx>Wrapping most guix invocations into a read-only Guix container sounds like a good intermediate-level project that shouldn't take *too* long.¹ <nckx>¹ Possibly exaggerated to lure in someone but I don't mind. <jpoiret>amjoseph: once again, nix's unstaged code is *trusted* <amjoseph>but seriously i'd like to get some spitballing from people who know the codebase about what would break first if that were attempted <jpoiret>just that you can't put unstaged code in .nix <jpoiret>you can already do that though? at least for `guix build` <amjoseph>jpoiret sorry, i guess i am misusing the terminology. what do you call code that executes on the same machine that runs `guix build`, rather than on the remote builder? <jpoiret>there's even a guix shell option for a nested Guix? <nckx>Automatically, of course. <amjoseph>jpoiret then what kind of code is in a .nix file? <jpoiret>you can only put a very constrained set of metadata, and some staged code <amjoseph>jpoiret ah, i guess you consider .nix files to not be code. they are however turing-complete... <amjoseph>sure, you have unbounded recursion and unlimited-length lists. <geri>why are both nix' and guix' error messages often appear so random? <jpoiret>well it's of course possible but they did it by designing a whole new language from the ground up, so that's easier on that front <jpoiret>but once again, Guix's focus is not really complete isolation of everything so that you can run untrusted code <jpoiret>also, funny filesystem hierarchy go brrr <jpoiret>if you do want isolation you can run guix commands themselves in a container <geri>and even that isn't foolproof <geri>container in a vm isn't foolproof either <jpoiret>yes. i just pretend all the oss-security posts don't exist <jpoiret>otherwise i wouldn't be using a computer still <geri>how do i do (local-file ".") properly? <jpoiret>at least abacuses don't have RCEs. or do they <geri>i don't wanna have 10 million subdirectories so my emacs module for example is just my .emacs.d w/ main.scm within it, and i need to somehow "upload" the whole thing to store <geri>rn i du (local-file "../emacs") and it works but hurts my soul <jpoiret>(dirname (current-filename)) won't work? <geri>i've been burned by current-filename stuff way too many times, but it might be a good option in this case <mirai>jpoiret: the operators might? <mirai>At least if you consider unintended things that happen to them like optical illusions, etc. <andreas-e>apteryx: This may be the main reason why there are so few aarch64 packages on berlin. They are almost complete on bordeaux. <nanounanue>hi everyone, any idea about how to create a shepherd service for dockerd? I am using guix home in a foreign distro? is it possible? <attila_lendvai>whenever it comes up people say that substitute availability is not bad with guix, but in my day-to-day use i'm regularly annoyed by large packages getting built locally. i'm badly missing a staging branch that would leave time for the workers to build stuff. <geri>attila_lendvai: whenever i need to build chromium locally i just forget about updating for a day or two and i dont need to build it anymore <geri>but i agree it's painful <mirai>I had to conscript a nearby computer for guix offload 😅 <attila_lendvai>geri, the problem is that i'm hacking on guix itself, and my own channel, and whenever i want to test something i hardly can tolerate the delay of downloading it... :) <geri>i'd rather have a way to set a "only use substitures" policy <attila_lendvai>...and then sometimes i fix a channel to a specific commit to avoid local building, forget about it, and scratch my head later what's going on. or what's worse, i pick a commit from the past that is not fully built by the substitute servers => even more annoyance <geri>that's the price to be paid... <geri>jpoiret: current-source-directory did the trick <attila_lendvai>geri, it wouldn't be an insurmountable task to introduce a staging branch, and set up a script to only pull it into master with up to the latest commit with which the build farm is done <apteryx>andreas-e: I think so; when something core fails that way, all the rest fails because of the missing dependency <mirai>would it be “alright” to run autoreconf within the gcc packages? (within a phase) <mirai>or will this introduce some breakage regarding bootstrap, module cycling & co. <apteryx>ah, part of core-updates jobset. hm. <civodul>mirai: it'd be like opening a can of worms <apteryx>hm, nope, I forgot to press "Go" ^^' <mirai>but I'm pretty sure they're valid for almost all GCC versions (?) <civodul>mirai: neat! did you see the libstdc++-doc package? <mirai>would it be worth inserting these into the (patches …) of every gcc? <mirai>civodul: yes, and pretty much everything that touches docbook <andreas-e>apteryx: I probably cancelled this go build months ago... I would assume that a new build has been done on the master branch in the meantime? <mirai>~50 patches to c-u that will shed all kludges related to it <civodul>mirai: you can patch libstdc++-doc however you like, just not gcc itself <mirai>still have to reword & fixup the commits but I've improved docbook support within guix <mirai>it should transparently work now without any kind of source patching <mirai>civodul: libstdc++ docs inherit gcc (and thus its source) <apteryx>andreas-e: my understanding was that repaired builds cause failing dependents to be retried by cuirass <mirai>I think I could inherit and modify the inherited source? <mirai>civodul: btw, any reason why the docs are gcc-4 and gcc-9 only? <andreas-e>apteryx: Yes, failed builds are retried when their inputs change. But cancelled builds from one evaluation are not retried when the same derivation reappears in a different evaluation. <andreas-e>This "Go" button also took me a while to get used to... <andreas-e>So I ended up not cancelling any builds any more, but this can result in using a lot of build power for long obsolete branches. <andreas-e>Hm, maybe I misunderstood your statement; it depends on what you mean by "repaired build". If the input and thus the derivation of a package changes, then it is rebuilt. If a package failed on cuirass with "dependency failed", and the dependency is restarted and then builds, the package itself is not retried. <apteryx>andreas-e: I see! it'd be nice to change that behavior (cancelled but retried when a fresh derivation refers to it) <apteryx>andreas-e: without having cancelled anything on qt-updates, my experience is that builds stuck in 'dependency failed' mode are retried when the blocking dependency is resolved <apteryx>e.g. if qtbase failed due to the cannot build derivation weird bug, and all of qt is broken, retrying qtbase will cause all the qt packages to be built if qtbase now passes <apteryx>but that probably changes when something was cancelled, I guess? <apteryx>looks like cancelling has some definitive quality (or flaw) <andreas-e>Interesting! I noticed at the time that cancelling was definitive, indeed. <andreas-e>And as my icedtea example shows, I was convinced that also failed and repaired builds do not cause dependents to be rebuilt. <andreas-e>A cuirass specialist should be able to answer the question... Or an experiment. <apteryx>let's monitor both to see the end result <apteryx>overdrive1 is still comfortably idling <andreas-e>I am pessimistic. This can take ages. The aarch64 machines tend to idle while there are thousands of queued build jobs. <Altadil>hum, it might just be me being a noob, but is it normal that the "base32" encoding in origins in packages matches the -f nix-base32 of guix hash and not it’s -f base32 ? I just spend quite some time being confused. ^^ <sneek>vagrantc, you have 1 message! <sneek>vagrantc, efraim says: do you have audio from your speakers working on your pinebookpro? I don't have any currently with Guix System <vagrantc>efraim: i've used a few usb audio devices with the pinebookpro