IRC channel logs
2023-03-20.log
back to list of logs
<lechner>stfnbms / Hi, please see #62283 for your SIL font updates. After two or three days, our CI infrastructure may supply build information via the badge at the top, but it could be several weeks before your patch series is accepted. Thanks for your contribution to Guix! <stfnbms>lechner: Thank you very much! I am excited to see these in Guix. <Hasnep[m]>Hi everyone, I've checked out the Guix git repository and I've added a new package, but I can't figure out how to build the new package. I want to install it in a profile for testing before I submit the patch. How do people normally test the packages they develop locally? Thanks! <lechner>Hasnep[m] / Hi, I use two approaches: For software I use myself, I build it as part of my system or home configurations (which installs them in a profile). You can also just use a 'guix.scm'. Then I transfer it into a Git checkout of Guix and submit it for consideration to the committers <Hasnep[m]>lechner: Sorry, I'm pretty new to Guix (and I'm using it on a foreign distro in case that's relevant). How do you include local packages in your system config? <lechner>Hasnep[m] / on a foreign distro, there is no system config. i am not sure about home. just write a guix.scm that evaluates to your package definition in its last expression and run guix build -f guix.scm <lechner>you can use it with guix shell -f guix.scm <sabazk>trying to get guixsd installed but i need one parameter on this hardware.Ā how do i pass --no-nvram to the grub installer so i can get the install to finish (nvram env variables are readonly on this machine) so it causes grub install to fail <apteryx>sabazk: someone did that recently; I believe tehy must have run 'grub-install' by hand <lechner>yeah, running by hand is a good one-time option, as well <civodul>i replied offering a bit of paperwork :-) <cbaines>I have sent the patch to guile-devel, but I can open a bug against Guile (and send the patch there) as well <civodul>cbaines: ah yes sorry, i tend to pay more attention to bug-guile because it shows up in the debbugs.el backlog <civodul>(and i think it's good to document issues that way) <cbaines>no worries, I've created a bug for Guile now # <jpoiret>civodul: are you used to mach/hurd debugging? <jpoiret>i have an image now, but setting the passive translators for /servers/{exec,socket/1} fails <jpoiret>i'm now wondering if this is worth it at all, since it might just be a bug with the commits I chose š <jpoiret>i've already spent so much time on this and have not done anything else for core updates (well apart from fixing a few qemu-related build errors) <civodul>jpoiret: hi! yes, don't pull your hair over it! <civodul>most likely we can fix this afterwards without rebuilding the world <civodul>so i think we can apply the fixes you have, in particular for cross-compilation <civodul>and later on we'll see what remains to be fixed <jpoiret>although I'm not sure that my cross-compilation fixes actually work since I haven't booted up the hurd completely <jpoiret>i'm also thinking we could provide a newer glibc for Hurd only, so that we can follow upstream more closely <jpoiret>that way we could help them ensure their "releases" work fine <civodul>we did that in the past but i think it's simpler if we can avoid it <jpoiret>imo it would be better for the project to have some external QA (possibly from us) for their work rather than trying to catch up years of work every time <jpoiret>but this discussion belongs to the post-core-updates-merge world :) <jpoiret>I will first need to up my skills in kernel dev/debugging though if I want to be a part of it <jpoiret>the guix part I can navigate just fine, but once qemu starts all bets are off <jpoiret>civodul: how did that work though? was it following HEAD? <Guest59>hello guix, I'm trying to hack on the main guix repository on a foreign distro (an ubuntu machine with guix installed through apt), I cloned the guix repository, chdir'd into it, made sure all dependencies are installed and ran ./bootstrap and ./configure with the appropriate state dir.Ā When I try to use guix with ./pre-inst-env guix package -A <Guest59>mruby, it tells me the only available version is 2.1.2, but the guix checkout is defining version 3.2.0 in gnu/packages/ruby.scm, leading me to believe that it's not using the local checkout at all! Did I miss a step while setting up? <jpoiret>Guest59: does `guix show mruby` work better? <Guest59>when I run ./pre-inst-env guix show mruby it also tells me version as 2.1.2 <Guest59>I did run make in a previous attempt but not in this one as I thought it would be okay to skip, the manual said it's okay to skip but everything will run a bit slower because it's being interpreted as opposed to running the bytecode that is generated by running make <Guest59>I can make the projekt of course if that would help <jpoiret>i would make sure to `make` at least once <jpoiret>and in general, running `make` incrementally isn't that long, i don't think there's any difference with running the code itself. Just to be on the safe side I woud run `make` each time <mirai>how does the define-compile-time-procedure work? <gabber>hi! i was wondering if anybody was available to comment on my patch(set) here: #59867 - it's been quite a while and i really think Guix is ready for MbedTLS 3 ;) <mirai>gabber: how about switching to G-Expressions? (do that in a separate commit though) <civodul>jpoiret: it would follow HEAD of each project (except glibc, because official glibc lacks many Hurd patches at the time) <mirai>drop the trailing #t at the end of the lambda as well <civodul>mirai: you question about define-compile-time-procedure, is it about the implementation or about what it does? <mirai>civodul: both & how/when to use them vs. a regular procedure <mirai>the name suggests 'something at compile time' but how exactly do I make the judgement call here? <mirai>other than applying the vague concept of āgut instinctā <Guest59>When running make, it's telling me that all my source files are newer than the respective compiled units in /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/[...].go, so for some reason it's using the system cache instead of my users cache? <jpoiret>Guest59: what I would think is happening is that you haven't built the go files for your checkout yet, so it only sees the ones you have installed globally. The new ones will be built inside your checkout though <jpoiret>but yes, that's why I suggested running make <gabber>mirai: which part should i convert to a G-exp? i was trying to keep as much from the original package definition as possible (but i ran `guix style` afterwards) -- the #t at the end of the lambda came from the past <mirai>gabber: see daa681a38b7a296fdc58bf81a8385e8dd66f7b66 for inspiration <civodul>mirai: you'd use it typically for checks that can (and should) be done entirely at macro-expansion time <civodul>that could be the case with field sanitizers, for instance <civodul>as always with macros, there's a risk of code bloat, which you need to keep in mind <mirai>does it have any advantage over a regular procedure? <jpoiret>mirai: it's executed at compile-time, meaning it can catch errors way earlier <jpoiret>ie. if it is used in a thunked field of a record, it will error out instantly rather than waiting for all the guix machinery to eval the thunk <mirai>what about the āhow do I drive thisā part: example: (define-compile-time-procedure (assert-valid-address (address string?)) <mirai>assert-valid => name of the procedure <mirai>but then it comes with an extra round of (... ) ? <Baptiste>Hello everyone, does someone know if there is a way to have a `xorg-configuration` without X being started by a display manager like GDM or SDDM? <gabber>mirai: thanks for the inspiration! unfortunately you didn't really answer my question :) maybe i better rephrase: should i, after running `guix style`, re-write packages i didn't author? or should i *not* run `guix style` on packages i touch (altough it is mentioned in the "Submitting Patches" part of the manual)? <Guest59>`make` is crashing with `ice-9/eval.scm:293:34: error: nefine-public: unbound variable` in `make-core-go` :( <Guest59>Just checkout the repository anew and try again? <gabber>btw: is the g-exp style better than ` and , style? is the latter deprecated? <gabber>and finally (sorry for the flood of questions): is any of this a game-stopper for my patch series? <mirai>not a game stopper but Gexps are āthe new way of thingsā <mirai>run guix style on the packages you're changing <mirai>doesn't matter who authored them first/last <civodul>mirai: check out the docstring :-) in the example above, it means that ADDRESS has to be a literal that matches the 'string?' predicate <civodul>you can try it at the REPL: ,expand (assert-valid-address "abcd") <gabber>mirai: thanks for the clarifications! <mirai>is it feasible for configuration->documentation to support showing identifiers as default values? <mirai>it doesn't render any (default: @code{%value}) <bjc>mirai: i'm trying to use geiser to make some changes to āgnu/services/baseā and i get errors during compilation for āvalid-name?ā and ācidr->netmaskā being unbound. i assume because of the use of ādefine-compile-time-procedureā <bjc>is there a way around this? is compile-time a hard requirement? it's honestly very annoying <bjc>these also appear to be the only two uses in the entire codebase for ādefine-compile-time-procedureā <civodul>bjc: hi! you get compilation errors in gnu/services/base.scm? <bjc>errors. it won't compile <bjc>error: valid-name?: unbound variable <bjc>i don't really get it, but i'm reasonably sure of my hypothesis. i'm just not deep into guile enough to understand why it happens <bjc>if i manually āC-x C-eā on those procedures, i can then compile the module <reyman>I have one last reef in my guix Quarto packaging challenge ... <reyman>i need to provide "./vendor" file downloaded during packaging of Quarto <reyman>what's the guix way to provide these packages (downloaded by using a cli already packaged into guix by me : deno) <reyman>from quarto point of view i suppose i need to set a /gnu/store path using some an env variable <reyman>i have a json with a list of thing to download from deno cli <reyman>so how i set that into a /gnu/store, i need to create a new source mecanism ? <civodul>reyman: if it's a Git repo with submodules, you can set (recursive? #t) in your (git-reference ...) <reyman>@civodul, no it's some sort of downloader that use a json file to download <reyman>but i have also a .ts typescript that also download thing <Guest59>Ran `make` in the new checkout and when I execute `./pre-inst-env guix package -A mruby` it still shows me 2.1.2 as the only available version while I can clearly see 3.2.0 being available. It also reports the wrong line number for the package definition, so it's definitely looking at the wrong place <reyman>i could remove this step by patching quarto and provide the corresponding files <reyman>but this script need dependencies from quarto source file, so this is complicated. <rekado>just found out that the cargo-build-system doesnāt work with Rust inputs whose source was fetched with git <rekado>any users of such packages fail to unpack the crate <reyman>this typecript script is infamous, it download and update things by patching sources before quarto packaging into final .js file <civodul>rekado: isn't that the majority of Rust packages? <rekado>civodul: no, almost all use crate-url <reyman>So if you need to give any external files (zip or any other file, url and not url) in entry of my package.scm, how i do ? <rekado>only when I use (crate-uri "autocompress" version) downstream users can see it. <abcdw>Where can I get debbugging symbols for libgtk-3.so.0 and libgobject-2.0.so.0 to use it with gdb? <civodul>both glib and gtk+ have a "debug" output <mirai>a macro that acts within a gexp? <apteryx>rekado: how do you do proceed with the large r updates? do you use a branch which the ci builds, or you build everything manually and push directly when you're confident? <apteryx>I'm asking because I have a branch with > 200 ruby updates/additions, and was wondering about the best way to proceed (I've ensure everything builds including their dependents, and that they all pass guix lint) <abcdw>civodul, helpful-friend: Thank you very much! <civodul>mirai: perhaps you could have a procedure, rather than a macro? <jonsger>guix shell from a manifest including package definitions imported with `guix import` feels like beeing on stereoids :) <mirai>civodul: I'll revisit this later, I suspect I'm hitting some troubles with gexp-ungexp-module-imports-... <bjc>mirai: did you see my messages earlier about āvalid-name?ā and ācidr->netmaskā? <mirai>did you manage to find a way around it? <bjc>no. it's been bugging me for a while <bjc>civodul acked it, but i'm not sure he actually looked at it =) <mirai>open ticket on bug-guix perhaps? else this is going to be forgotten :) <bjc>yeah, i will. was only asking here in case there were a more expedient way forward <mirai>can the guilec phase be spread of offloaded? <mirai>spread over multiple computers or offloaded <Guest54>Is it possible to define in guide home or system a .x session? <mirai>idk what went in my head when I typed that <civodul>bjc: i did look at it, will push a fix later today! <mirai>extensible define-configuration's out: #62298 <lechner>just saw that! i think it "in" rather than "out" though :) <lechner>mirai / thanks so much for doing that! <lechner>Guest54 / Hi, I 'm not sure, but I would look in Guix Home first of all <mirai>lechner: is this regarding #61744? <lechner>mirai / whoops, i did not see that. my interest was merely to clean up in preparation for having PAM modules in Guile. Do you think we could incorporate some of my ideas? <mirai>lechner: I think you kinda reimplemented #61744 v2 patch-series there? <apteryx>cbaines: for your info, I've finally sent the Ruby patches for the corresponding ticket opened a few days ago (I had found some problems to fix); I thought I'd ping since you're on the Ruby team, but didn't want to CC you on hundreds of patches ;-); see:https://issues.guix.gnu.org/62196 <mirai>lechner: does it do anything extra compared to the patch I posted? <lechner>mirai / i'm reading v2 but probably not <sarg>lechner lgtm. I'd rather leave a comment in the code on why /info/refs is appended. Though you've explained it in the commit message, so that's also fine. <cbaines>apteryx, awesome :) I'll try and have a look tomorrow (and hopefully by then the QA stuff will have a picture of the changes as well) <lechner>sarg / i'll change it. our code does not generally have a lot of comments so i was reluctant to add a lot of explanatory text or hyperlink references <lechner>mirai / v2 may break existing syntax i think, and it still uses a file location in /etc for limits.conf, which I do not believe is needed <lechner>mirai / but otherwise, it's actually what i was hoping for <lechner>i did not have the courage to make those changes <mirai>lechner: do you have an example of syntax break? <mirai>that would mean the tests there are missing some case <lechner>mirai/ it's probably somewhat far-fetched: what if somebody was trying get ahead of the curve and used -service-type directly, passing plain-file <apteryx>seems gmail is limited to sending 100 patches in a row <lechner>apteryx / it may be a hundred patches (messages) in a day <apteryx>nope, I retry after a few moments and I'm good for a hundred more <mirai>ah, I'm now seeing what problem apteryx is having <lechner>apteryx / where are you sending those messages, and why? <bjc>civodul: great! i'll keep an eye out for it. thank you! <apteryx>lechner: to guix-patches; for QA and cbaines to take a peek <apteryx>(and anyone who's interested in Ruby package updates) <lechner>i love email, but that does not seem quite right. it is so 1990s <mirai>lechner: mail bug-guix or guix-devel and CC rekado <lechner>mirai / i am currently debating whether the PAM modules included with libpam can use absolute references, as well. i think they should <mirai>how pam works is beyond me, better ask someone else with more expertise in the matter <lechner>mirai / the issue is whether programs linked to other versions of libpam are allowed to use the modules that came with that version, and i think the answer is no <mirai>you might want to either wait for v2 to get merged or develop on top of it if you feel brave? <lechner>i really need the libpam fom core-updates, so i am just doing house cleaning <mirai>git am < --wget incantation here-- ? <lechner>Hi, can Savannah provide permalinks? <lechner>rekado / my pam_limits request. it's already in your inbox <rekado>#61744 ? I already responded to that one. <mirai>rekado: it was me redirecting lechner to you for pam inquiries :) <rekado>do you want us to generate PAM modules? <lechner>no, we will configure all the logic in Guile <rekado>PAM modules are supposed to have a small footprint and are tightly coupled to the PAM API. Iād sleep worse knowing that out there someone is routing PAM to a general purpose programming language. <rekado>if you want to add Guile as a PAM module thatās fine <rekado>but Iād rather not use that to replace all existing PAM modules <lechner>if it does not sounds attractive, i recommend having a look at the libpam or pam_mount code bases <lechner>what's up with all this fear of innovation? <jpoiret>just because guile code itself seems simple and ok doesn't mean it's safer <bjc>fear is a valuable tool granted us through nature and experience, and shouldn't be discounted wholesale <jpoiret>it doesn't seem like a bad idea, it's definitely not a waste, but adopting it as default? <jpoiret>sure, if I want to add new pam modules that I can configure in Guile, why not <mirai>my 2Ā¢: lots of tests, even better if you can formally prove parts of the program and setup a channel for ābig/controversial changesā <lechner>jpoiret / i am only offering an alternative and, looking positively into the future, hope for widespread enthusiasm <mirai>after some <criteria to be decided> it could be graduated into guix? <bjc>lechner: no, it's not "fearful ego", whatever that is. it's acknowledging that natural selection doesn't tend to allow things that require a lot of energy to exist without purpose <bjc>fear, in-and-of itself, is valuable. context, as always, is key <lechner>mirai / it would only happen after the skeptics considered all the alternatives. OpenBSD has OpenPAM. Why would we not have Guile-PAM? <lechner>bjc / the book will change your life, i promise <bjc>i sincerely doubt that <mirai>I'm not discarding the idea, but it will have to pass the ātrial by fireā <jpoiret>lechner: I would be okay with adding it to Guix as long as it does not become the default, for now <jpoiret>maybe once it has proved its robustness, Guix could switch to it <GNUtoo>Hi, is there a way to create a bridge in a system definition? <GNUtoo>And if so is it possible to add an interface and an ip address to it? <Guest19>I also tried .xinitrc that has just "exwm" in it but that doesn't start either.Ā I thought if I install it through home to easily manage everything later it woks ouf othe box just like in system <apteryx>lechner: re big ideas: nothing/no one should stop you from having them, but they'll need to make consensus before their implementation can make it into guix! before going all in in something like this, you may want to open the discussion on guix-devel to check what people have to say about it (see: https://www.seedsforchange.org.uk/consensus). I recently read the whole thing (it's a bit long), but <apteryx>I think I've learned a couple new things. <Guest19>lechner okay thanks.Ā I want to know why it is so complicated to get it to work with guix home.Ā do you may know why? <jpoiret>in general, DEs only detect system wide WMs <jpoiret>that's because of how Guix and DEs work, it doesn't mix well <jpoiret>(DEs weren't really made with user-installable packages in mind) <lechner>apteryx / i haven't even made it to the mailing list! i just asked on IRC, and the reaction to any kind of novelty is always profoundly negative. <Guest19>jpoiret Ah okay.Ā Well it worked out of the box with "guix install emacs emacs-exwm" so I thought it would work the same with guix home.Ā Does that mean I shouldn use guix home for emacs since I use it as my wm? <apteryx>lechner: there's probably some reason behind it; and a mailing list thread would give the space to expound on these <jpoiret>it worked out of the box? With GDM? Without using Xinit or whatever other trick? <lechner>yes, the reason is fear and hostility to innovation <jpoiret>that's great but I'm not sure why it would work <jpoiret>lechner: I would not summarize what has been said by "hostility to innovation" <Guest19>jpoiret no I have a .xsession file (my old system worked like this) now I reinstalled guix without efi and thought I could use guix home and commit everything in git <lechner>apteryx / and as for seeking consensus, how much sense does it make to give that advice to someone like me, who has no standing whatsoever. i cannot fathom to ask for any kind of adoption without widespread excitement, even though such excitement is far off <jpoiret>you can, but for WMs you usually need some system-wide installation <Guest19>jpoiret okay, but how would I add packages without installing those system wide for emacs to grab it? <jpoiret>lechner: I don't think anyone gives a single thought about "standing" <apteryx>lechner: consensus should not care about "standing"; consensus decision making is about researching the best outcome for the group of participants <jpoiret>i remember my first interaction with the community was adding wayland support to GDM and the new swap-devices interface, everyone considered the changes and consensus was quickly reached <lechner>apteryx / consensus starts small, and the response here was negative <jpoiret>but with a mail you get a lot more than offhand comments to describe your rationale and the impact of the change <rekado>lechner: where does your negativity come from? You are projecting negative attributes and motivations on your fellow hackers. <rekado>jpoiret and I both said that this would be fine as a new PAM module <mirai>I didn't read it as negative, it was mostly "it will need to be battle-tested" <rekado>Iād hardly call that āfear of innovationā <rekado>no, Iām not. But I also donāt care to continue this discussion under these circumstances. We seem to be talking past each other. <lechner>thanks for the projection comment. that's right i am negative, and you were super enthusiastic about my idea <Guest19>shouldn't load gdm .initrc after start? Can't I just put exwm in there?Ā Normally that is how you would do it <apteryx>lechner: consensus doesn't need to start with positive feedback, although it means the group will have to work harder toward finding a suitable proposal. if you believe in the idea, I encourage you to have it discussed! It may not be adopted the way you envisioned it, but something nice may come out of it nonetheless! <zeropoint>anyone have some tips for debugging configuration? I'm trying to migrate an lvm/luks setup I'm using on debian and getting an ambiguous error message: "pre-mount actions failed" <lechner>apteryx / maybe one day you will see it's all upside down. what rekado said about me was totally twisted <lechner>i am sure there was a time when no one thought that a language like Guile was capable to express an operating system <apteryx>lechner: please remain courteous. a breath of fresh air may help. <rekado>lechner: I really donāt feel like arguing. Not being āsuper enthusiasticā does not warrant attribution of negative motivation. You donāt need my blessing. All I say is: donāt make this the default for Guix. <rekado>and now, if youāll excuse me: thereās a curmudgeon meeting and I still have to put on my beige pants, but the suspenders arenāt set up short enough to pull the pants above my belly button <rekado>ACTION looks for the suspender adjustment tool in this beige vest, but it has way too many pockets, and they are all filled with coins! <sarg>zeropoint that's an early boot message, right? <zeropoint>yeah, the last message that gets output before that is the result from pvchange (or vgchange) can't remember which one <sarg>zeropoint do you end up in a guile repl? checking the code `pre-mount` is to map devices and find filesystems. Maybe partition labels are wrong in your `operating-system` or something like that <zeropoint>Yeah, I do. I did some poking around in the initram (is that what it's called?) and saw that my device maps seem to exist. Is there a way to continue the operating system filesystem mounting process from within the repl? <sarg>sure, it's just guile code running and you're in a repl. But you need to understand the boot process and how it's organised in guix. I'm afraid I can'd advise you here. <zeropoint>hmm, well that's probably out of my depth for now too lol. I'm still new to guile... <Guest19>Okay it works now.Ā I can use exwm with guix home.Ā The problem was just that .profile isn't loaded automatically without the shell service.Ā Isn't this a bug? since you can install packages but you can't even use them without defining the shell service <jpoiret>zeropoint: you have two mapped-devices right? <zeropoint>jpoiret: in filesystems or mapped-devices? or both? <evilsetg[m]>zeropoint: can you post your config? I was at a similar point (pre-mount failure) a week ago and feel with you. <old>I've asked this question before and Apteryx gave me answer partially. <lechner>apteryx / where was i not courteous, please? <old>I would like to have a `guix shell' with a full gcc-toolchain for ARM <old>Right now I decleare a package with `(cross-gcc "aarch64-linux-gnu")' and do a `--with-c-toolchain=my-package=gcc-cross-sans-libc-aarch64-linux-gnu' <old>however, the environment I'm now in does not have C_INCLUDE_PATH defined <old>this breaks my build system <lechner>old / i have not tried cross building but from the way environment variables are being handled for interpreted languages, i believe you may have to set those variables yourself <old>Guix actually set them if not doing cross compilation <old>so I wonder what I'm not doing okay here <lechner>how do you get to "the environment I'm now" please? <lechner>and "if not doing cross compilation" ? <old>I do get C_INCLUDE_PATH and LIBRARY_PATH <old>I'm going to try by passing a libc to cross-build <lechner>sorry, that's in a guix shell --development ? <old>Yes I do: guix shell --pure --development libpatch <old>for Cross: guix shell --pure -L .guix --with-c-toolchain=libpatch=gcc-cross-aarch64-linux-gnu --developement libpatch <old>oh well cross-compiling glibc rn <old>I'll be back in 5 hours :-) <evilsetg[m]>zeropoint: Does the initrd ask you for the passphrase? <old>lechner: Will know when I'm done with compiling glibc <civodul>old: i'm afraid that won't work: when cross-compiling, you need a mixture of host, build, and target tools <jpoiret>zeropoint: I am 100% sure you need to put lvm before luks <lechner>is it possible to use guix build --target=arch64-linux-gnu ? <jpoiret>we don't order pre-mount actions, just rely on the mapped-devices being ordered this way <jpoiret>civodul: i was thinking, shouldn't we rename --target to --host? :) <jpoiret>i'm rebasing on top of core-updates right now (and on top of some changes you made on master i think?), will send the patch once I've made sure they build <lechner>shouldn't 'host' be renamed to 'target'? <jpoiret>unfortunately the build/host/target terminology is pretty old at this point and is the standard for toolchains I think <lechner>so why is --target inaccurate though, please? <jpoiret>old: you can try using `guix shell -m/-f` combined with the procedures from cross-base.scm <jpoiret>it's not a walk in the park but should work (i think) <evilsetg[m]>zeropoint: If I read your config correctly your root partition is only on luks without lvm? On which "physical volumes" lives "raid_vg0"? Have you tried installing without the other partitions (that I assume are optional for booting)? <jpoiret>lechner: --target for compiler toolchains means that the new compiler should target that arch, not that it should run on that arch <jpoiret>--host is for where the generated executable wil run <jpoiret>ie. you can cross-build a cross-compiler by using distinct --build + --host + --target š³ <jpoiret>with these conventions in mind what we do is actually --host, not --target <jpoiret>lechner: oh and btw, cross-compilation is really under-tested, and might or might not work for you <lechner>isn't that terminology only for building the compiler? for most folks build and host are the same, aren't they? <civodul>jpoiret: bags use build/host/target, whereas higher-level tools just have system/target in Guix <old>how does guix-build do ? <jpoiret>right, but i'm only talking about the cosmetic change of renaming target to host <old>you can specify a target triplet for cross-compiling <old>otherwise I will just launch a Guix VM with ARM emulated <old>I would try to avoid that since qemu-system is heavy for emulating ARM <spacecadet[m]>Can anyone tell me what I should add to dependencies for an NFS file-system entry? Currently it seems that an NFS mount will deadlock my box at boot trying to reach the NFS host before network is up. <jpoiret>how does it switch to the cross toolchain? <civodul>jpoiret: dunno, i'm fine with "target" :-) <jpoiret>civodul: yeah, I was looking at CMake and they also use "target" <jpoiret>i guess it's just me who got confused when I got into the cross toolchain business and target didn't mean the same thing there :p <mirai>spacecadet[m]: set mount to false, needed for boot to false <jpoiret>lechner: depends on what you intend to do <jpoiret>if you want to build, let's say, hurd for i586-pc-gnu, you'd have --build=x86_64-linux-gnu (for me for example), --host=i586-pc-gnu and --target doesn't exist for things that aren't toolchains (mostly) <jpoiret>if you want to build a toolchain to cross-compile for the hurd, you want --build=--host=x86_64-linux-gnu, but --target=i586-pc-gnu <spacecadet[m]>mirai: Thanks! Is there an easy way to have it mount automatically after network is up? <mirai>[click here to find out how] <spacecadet[m]>Heh. I guess I could have a script run as a one-shot to mount it. <old>jpoiret: You can specify a target architecture in guix-build <old>I've never use the feature, but I guess it means that you can compile a package for a given ARCH <mirai>it works best with NetworkManager <old>my guess is that guix build recursively the package with the correct toolchain for the given archiecture <old>I realize now that using a diffrent c-toolchain is not enough in guix-shell <old>I would have to re-compile every dependencies <jpoiret>using `--target=sometriplet` will set %current-target-system so that the right toolchain is selected <jpoiret>yes, although if it's only libpatch it should be quite easy :) <old>lttng-ust, libuwind, elfutils, dyninst <old>oh and Guile but I assume that one is trivial <jpoiret>the basics should be available as substitutes, I think guile for example <old>anyway, I think what I'm trying to do is simply not possible as in the current state <old>I was hoping to be able to cross-compile my tool and use binfmt to emulate it, but I will use qemu-system instead <jpoiret>old: i do think it should be possible, though with a bit of guix know-how. But I can't really back my claims up right now <old>well I for one would like a `--target' option for guix-shell like for guix-build <jpoiret>one thing that's missing though is the ability to add a cross-toolchain <jpoiret>and you probably need some native things in the shell as well, like binutils and friends. It would definitely be a great feature to have <jpoiret>Hurd built, omw to send my 15 patches :) <old>well thanks for everybody help on that <old>If someone think of a way of doing what I want, please ping me :-) <zeropoint>evilsetg: initrd does ask me for passphrase, I've got a debian install that I'm migrating from which is why I have the extra disconnected lvm/luks volumes and I'm trying to move everything piecemeal... my debian system has keyfiles setup which was going to be my next step. <zeropoint>jpoiret: will try swapping the order, that makes sense <jpoiret>zeropoint: we don't support keyfiles in the initrd right now, FTR <jpoiret>the main probles is that the generated initrd ends up in the store which is world-readable <evilsetg[m]>zeropoint: Your root file system is only on luks, without lvm right? <zeropoint>figured that just entering passphrases for now would be fine <zeropoint>I guess I could setup a simple service or something after boot which reads files in the root file system or something... <ekaitz>hi! how can I copy a "phase" of a package to execute it twice? Just rewrite it in guile? or is there an easy way? <ngz>ekaitz: (add-after 'phase-foo 'another-phase-foo (assoc-ref %standard-phases 'phase-foo)) <jpoiret>why did I even take care of avoiding world rebuilds on core-updates, when some new commits just caused some <civodul>maybe a Rust thing coming from the merge of 'master'? <jpoiret>i just wanted to check that my patches to u-boot-tools were still working (and didn't change too much), and I got this prohibitive build plan <jpoiret>also, CI is failing (i'm trying to guix pull to see what is going wrong) <jpoiret>why is git getting build for a guix pull? <gnucode>well apparently openBSD is working on getting nix packaged... <civodul>jpoiret: git might be built because there's some git-fetch origin on the path <jpoiret>no, it's because guile-gnutls now relies on gnulib which has git in its native-inptus <jpoiret>and git doesn't build on core-updates? <jpoiret>can't the tests of gnulib just rely on git-minimal? <evilsetg[m]>zeropoint: Your config looks okay to me. I would suggest starting with the essential devices (cryptroot), building from there and seeing where it fails. A useful thing to look at would be the init script that is located within the initrd. Beware that the init file is a symlink refering to the store within the initrd. Easiest would be reading it on another computer but you can also view it from within the initrd. The `#:pre-mount` section of <evilsetg[m]>the `boot-system` procedure is what you would need to look at. <civodul>jpoiret: so that's the first thing to fix IMO <jpoiret>yes, but also getting git to build would be nice :p <jpoiret>i'll probably call it a day now though <jlicht>sneek: later tell lechner: you pointed out guix-patches@debbugs.gnu.org, but it should probably be guix-patches@gnu.org. The wrong address used to be in the manual, but should have been fixed :-) <jpoiret>civodul: if possible, could you check out the patch I just sent? guile-gnutls builds fine with it <jpoiret>so that we're able to get an evaluation going, and then substitutes for tomorrow? <jpoiret>or someone else who has committer rights :) <jpoiret>and also the whole Hurd patchset! just kidding š¤ <civodul>well i'll go to bed soon despite obvious excitement ;-)