<raghavgururajan>nckx: I wanted to ask you some thing when I pinged (summoned) you the other day. My gnome work is stalled because I don't have access to lle-bout's build machine and bayfront don't serve substitutes for things I build through ssh. So I wanted to ask you for advice. <nckx>If it's only the occasional huge thing you need to build on bayfront, you could use ‘guix copy --from=bayfront.guix.gnu.org’ as a poor man's manual substitution. <nckx>You could script it if it's more than that. <nckx>I don't understand why substitution is broken now. <nckx>Was ‘lle-bout's build machine’ x86_64? <solene>I finally found what Guix missed. a service for openttd server. <nckx>Not fit for production :( *nckx is entirely unfit for production and shuffles off to bed. o/ <solene>nckx: I have to do the same :P good night <iskarian>jonsger, on what arch? I got a substitute fine on x86-64 (from master) <cbaines>raghavgururajan, now that the bordeaux.guix.gnu.org domain exists and is being used to serve substitutes, it's possible to run guix publish behind bayfront.guix.gnu.org again <cbaines>although, on the other hand, bayfront is now often busy building things for bordeaux.guix.gnu.org <cbaines>that's good, but it'll make it harder to also use it for personal hacking <cbaines>in the medium term, I'm kind of hopeful that the work around building packages affected by patches will help address the underlying need here, and not just for people who have SSH access to bayfront <iskarian>I just build something (from core-updates) with an -e expression, but the corresponding package -e wants to install the world? what is going on? <The_tubular>Could someone help me out figure out what I did wrong with this backtrace ? <iskarian>The_tubular, is this for a `guix system reconfigure`? If so, it would help a lot to see the config <iskarian>Just based on that, it might be users or groups you added? <iskarian>to be honest I have pretty much no clue; I can point out the non-standard bits of your config like the lack of %base-file-systems, or to suggest that you check the generated /etc/passwd for inconsistencies, but that's about it <iskarian>I really wish guix's error messages were more informative <The_tubular>Same ... I'll just wait a bit, maybe someone else will know :/ <iskarian>The_tubular, have you tried setting a password for the user...? even `(password "")` <The_tubular>I have to write my password in plain text in system.scm though ? <The_tubular>Could you guide me on where to put that line iskarian ? <iskarian>in the user account section, so you have (user-account (name ...) (group ...) (password ...) (supplementary-groups ...)) <The_tubular>I'm pretty sure it's something from my part. Doubt it's guix binary itself. <The_tubular>It's my first install and I probably did something wrong, I just wish the traceback would help me more <iskarian>If it's your first install, why don't you start with the autogenerated config and slowly pare it down from that? <iskarian>Oh, well... guix system reconfigure is intended to be run from within a working guix system <iskarian>installing would be done with guix system init, with several steps before that <The_tubular>It's actually someone from this irc that showed me his gist but I forgot his name :( <The_tubular>I'm stuck witht this web IRC client until I get guix working :/ <iskarian>Ah, well assuming you followed all the prior steps, that's weird. It obviously worked for them <iskarian>The most suspect point of error would be how you created /etc/passwd <The_tubular>But yeah, I plan to use the autogenerated config on my next install, I just wanted to test in WSL first <The_tubular>Well not just test, I like to use Linux while I'm stuck on Windows ... <iskarian>I tried WSL; it was so painful. I just setup a vbox virtual machine <The_tubular>I usually don't have this much trouble and I highly doubt my problem is WSL related. I could be wrong though <raghavgururajan>leoprikler: Not the polkit thingy. Advice on what to do if one doesn't have powerful machine to keep rebuild lot of stuff. My gnome work stalled because of this bottle-neck. <The_tubular>Completly unrelated question, is it possible to "lock out" users from executing binaries located in /gnu/store ? <ecbrown>The_tubular: i have to ask: why would you want to do that? <ecbrown>i.e. that unix permissions already protects from "normal users gone rogue" <ecbrown>and what with so many chown/chmod's to manage for all the components, i would make a vm or something where you can lock basically two files and keep someone on a manifest file <ecbrown>i dunno. i enjoy guix because it empowers userland and seldom plot how to restrict that ***terpri is now known as robin
<itismyfirstday>munksgaard and tissevert: ever make any progress on that haskell package and cabal-doctest module not importing in the build? <rekado>The_tubular: people could still run “guix install /gnu/store/whatever” and then execute the binaries. <munksgaard>itismyfirstday: i haven't had time to finish the tests for my cabal import fixes, and I must admit I don't know how to fix the cabal-doctest issue, barring rewriting the whole thing to use canal instead of runhaskell <cbaines>I'm trying to use Guix on a slightly odd Ubuntu system, and getting this error: <cbaines>guix install: error: cloning builder process: Invalid argument <cbaines>I haven't bothered stracing, I'm just using --disable-chroot <cbaines>I just want guix to work enough so that I can guix system init <efraim>good news! I randomly switched to my IRC tab! <efraim>do you have user namespaces enabled? I have a script I have saved from when I ran guix on debian <efraim>sudo sysctl -w kernel.unprivileged_userns_clone=1 <efraim>ok, I remember a bit of what happened back then <efraim>there was an issue about the page size with the daemon in the end, the daemon expected 4kb pages and I had 8kb pages or something like that <cbaines>I left a machine on overnight to build an aarch64-linux installation image, but I forgot to add --keep-going <cbaines>so, because of some polkit build failure, I'm now building linux-libre-5.12.10-guix.tar.xz again, but now on two machines <brendyn>anyone know a way to make it so that i can still watch videos without them lagging out while software is building in guix? <civodul>brendyn: i think it (surprisingly) works rather well for me <civodul>it probably depends on the kind of storage device you have <civodul>and then it's a scheduling issue, that Linux seems to handle rather well these days <raghavgururajan>brendyn: I'd try with --cores=N, where N is half of the total number of cores you have. <brendyn>it looks cpu bound when im compiling c++ <apapsch>brendyn: next challenge: write a (gnu build 0ad) module to be able to build civilizations in a declaratory way <ekaitz>hey! I need some help with --with-source I'm trying to compile a package with an edited source and I have a permission error on config.log file, is there a fast workaround for this? <apapsch>ekaitz: is there a config.log file in the custom source? if so, seems like you are supplying an unclean build directory, `make clean` might help <ekaitz>no way! haha I did make clean but it didn't clean it! <apapsch>make distclean? though that build target doesn't always exist <ekaitz>i deleted the files that don't come with the original source <ekaitz>and now it says it can't find the auxiliary config.rpath file, and it's right there <apapsch>ekaitz: have you checked file permissions? also messing manually with autotools files seems adventurous <ekaitz>apapsch: it's basically a RX file... :( <ekaitz>yeah looks like something was poluted, I'll start over with a clean directory <ekaitz>now it's telling me it doesn't have autoconf, but isn't that supposed to come with the `guix build`? <ekaitz>I'm basically building the exact same version that is packaged with guix <apapsch>ekaitz: it depends on the build system which programs are available. which package are you hacking on? <ekaitz>guix build guile@3.0.5 --with-source=$MY_CODE_FOLDER <ekaitz>also the code in my folder is at v3.0.5 <apapsch>ekaitz: might be that the usual guile package builds with the tarball release, which doesn't require autotools. there is also a guile-next package which builds from git and adds more native-inputs, among them autoconf <ekaitz>but this says "--with-source has no effect" ! <cbaines>is there any documentation about modifying .bash_profile and the like to setup sourcing the current-guix profile? <ekaitz>`guix build guile-next --with-source=guile-next=guile` <civodul>did my first "guix home reconfigure" :-) <civodul>yoctocell: i like that i didn't lose any files ;-), that there are backups, etc. <civodul>(symlink-manager.scm is intimidating though!) <civodul>fully migrating will require discipline from me, and it's quite a bit of work <yoctocell>yeah, there is no easy way to migrate, you have to do everything by hand <yoctocell>civodul: re gnutls issue: i am getting the same error as you <civodul>cbaines: thanks! what does "gnutls-cli --version" say? <cbaines>curl works for me, but I'm using 7.68.0 and I'm not sure how much it's using gnutls either <civodul>yoctocell: yes, the one from guix is known to fail :-) <civodul>yoctocell: could you try 7.77.0 in Nix, if it's available? <tschilptschilp23>Hi all! I'm still fighting with defining packages -- thanks to the tips from here I already can circumvent the program bailing because of unknown configure-flags, that get passed by the build-system in the configure phase. Now configure starts, but does not see gmp... That's clear to me, because the program wants to have gmp in /usr/local. I've tried to put both gmp and mpfr into the inputs and native-inputs, but yield the same result <tschilptschilp23>yet. The configure script features a ```--with-gmp=...``` flag -- but where would I point that to? Here 's the code I'm working with at the moment: <yoctocell>civodul: nix doesn't seem to have curl 7.77.0 yet :/ <cbaines>tschilptschilp23, also, looking at your package definition, I'm not sure you need to replace the configure phase <tschilptschilp23>cbaines: I had to, because I needed an 'empty' configure command, as something like '--enable-fast-build' that gets passed to the configure-script, kill it immediately (it only answers with the output of ```configure --help``` then...). But a BIG thank you for the link above! I'll apply now! <abcdw>civodul: Yep, I saw your post on mastodon) Congratulations!) <abcdw>yoctocell: I have a good news regarding mail TODOs, finally pushed home services for mbsync and notmuch. <yoctocell>they are using openssl instead of gnutls, i guess that's why <cbaines>I got anxious for a moment as nothing has been built for at least the last hour for bordeaux.guix.gnu.org, but nothing is actually wrong, all the 3 machines are just busy building ungoogled-chromium... *raghavgururajan 's head is dizzy packaging bitmask <leoprikler>munksgaard: did you remember to adjust the local.mk? <munksgaard>leoprikler: No, should I? There's no local.mk in the tests/ directory as far as I can tell? <munksgaard>I also haven't added any new files, just a new test to an existing file (tests/hackage.scm) <leoprikler>oh, right, it's SCM_TESTS in root Makefile.am, my bad <munksgaard>leoprikler: Ah yes, I see it. I haven't added any new files, so it shouldn't be necessary right? <munksgaard>But running `make check TESTS="tests/hackage.scm"` I get an error, even without my additions <civodul>sneek: later tell yoctocell thanks for testing cURL on Nix! <civodul>we might be the only ones using the latest cURL on GnuTLS <munksgaard>Oh, that might just be because I'm not in the right development env... Let me try again <munksgaard>And if I send a new patch, how do I close the old one? <tissevert>my understanding is that you simply keep sending patches to the same issue <tissevert>and the person who merges the changes picks the one that has been discussed as the final and accepted version <HiddenKarma>Hello, I'm testing a package I just wrote using "./pre-inst-env guix build ..." but it cannot find the package. I've already tested "./pre-inst-env guile -c '(use-modules (gnu packages ...))'" and it compiles correctly, I don't see any warning or error related to my package. Can anyone help guide me? <cbaines>HiddenKarma, is it exported in the relevant module (define-public or otherwise)? <HiddenKarma>cbaines: Yes, it has '(define-public ..." just like the other packages in the file <tissevert>(out of curiosity, why are there OCURLY and CCURLY in ts-sec and in the common-sec you added ? I expect they are respectively '{' and '}', but are those legal in a cabal file ? I've never seen those) <mothacehe>cbaines: Cuirass failed because of a "failed to resolve address for git.savannah.gnu.org: Name or service not known" error yesterday. Looks like it caused the "register" process to hang definitely. <cbaines>mothacehe, ah, ok, I think I saw data.guix.gnu.org having issues at the same time, so it was probably an issue on the Savannah end <mothacehe>yes, but the hanging part in Cuirass is a bug <mothacehe>unrelated but fetching from git.savannah.gnu.org on berlin is super slow <HiddenKarma>cbaines: Is there something I'm missing? I can send you the package definition if you want <cbaines>HiddenKarma, next thing to check is to ./pre-inst-env guile <cbaines>and then see if you can import the relevant module, and access the package definition <HiddenKarma>cbaines: ./pre-inst-env guile -c '(use-modules (gnu packages video))' -- Running this produces no errors <cbaines>HiddenKarma, right, but can you access the package when you load the module in a REPL? <munksgaard>tissevert: I admit that my parsing-implementation is mostly copy-pasted from the implementation of test suites. They had OCURLY and CCURLY, but I honestly don't know why. <cbaines>HiddenKarma, ok, what's the exact output from the guix build command? <HiddenKarma>cbaines: $ ./pre-inst-env guix build video-contact-sheet <HiddenKarma>guix build: error: video-contact-sheet : paquet inconnu -- (unknown package) <cbaines>are you using hidden-package, or (properties '((hidden? . #t)) in the package definition? <tschilptschilp23>quite interesting how it looked before -- this one finally compiles, makes, makes install without any errors: <HiddenKarma>cbaines: No, there's nothing related to hidden packages <cbaines>HiddenKarma, maybe share your package definition? <tissevert>munksgaard: oh, ok ^^ doesn't matter I was just curious : ) <munksgaard>Interestingly, it is allowed! I didn't know that :) <tissevert>I missed it (I always have a hard time browsing readthedoc sites, dunno why but I assure you I went there and missed that) <cbaines>HiddenKarma, that package definition works for me. Maybe check the pre-inst-env script, it has some directories in there, if you moved the repository, they could be pointing to the wrong place <cbaines>to regenerate pre-inst-env, I think you run ./configure (with whatever relevant options) then make <munksgaard>tissevert: Haha, no problem. Good to clear that up anyway. <HiddenKarma>cbaines: I did not move the repository, I tested ./pre-inst-env guix build with another defined package in the module: vlc, mpv, ... and they worked fine <cbaines>HiddenKarma, that's not a particularly useful test, since you might just be building vlc from a different guix. Try removing the vlc package definition, running make, then ./pre-inst-env guix build vlc <munksgaard>Has anyone tried running guix with NixOS as the host system? I'm not sure I'm brave enough to try, but right now I'm writing and testing guix patches on a remote server, which is a little bit annoying. <tissevert>never, I'm not brave enough either (I must do a little work on a nix server and I've been avoiding it for the past months, and now that I know guix it's even harder to consider going there) <tricon>I'm about to embark on the quest of bringing EJBCA into Guix. Ideally, I'd like to run this in a container alongside Nginx (preferrably in its own, linked container) as an SSL terminator/reverse proxy. Having read Ludovic's excellent post on running services in containers and considering the open questions around complex service containers, are there any present limitations that may inhibit this pursuit? <civodul>tricon: hi! i don't know EJBCA so i can't really tell, but the approach described in that blog post should work <civodul>often the question is whether this is redundant with something the daemon already does <tricon>civodul: Roger, thank you for the clarification. <roptat>from what I saw, there are 302 dependents, which is just above the limit for master, but at the same time a lot of java packages are relatively fast to build <apapsch>roptat: friday evenings are the best time to break stuff <roptat>the thing is, I've already rebuild all dependents, at it works :) <cbaines>roptat, there's been plenty of changes that have resulted in large numbers of rebuilds recently <cbaines>I don't think the whole "this many rebuilds to this branch" thing is always being followed <roptat>cbaines, so do you mean "please don't add one more of these changes" or "there are precedents, go ahead"? <cbaines>it's not great that the processes aren't being followed, but I have mixed feelings about it anyway <roptat>to me, the main reasons to not push to master would be if the change impacts a lot of users, or the committer did not rebuild all dependents <civodul>cbaines: do you have examples of cases where more rebuilds went through? <civodul>roptat: you could ping the usual Java folks <civodul>i think there's a couple more people, no? <cbaines>(I should add a better way to count changes in the Guix Data Service, as I'm guesstimating based on inspecting the HTML at the moment) <brendyn>cbaines, for your 0ad patch, changing --strip=3 to --strip=2 fixes the game. i was able to play. but the tests dont work still <roptat>(I thought of some names, but can't find them here) <brendyn>im happy with just disabling tests since i have no clue how to fix them. maybe its best if i ask upstream <roptat>cbaines, I don't see any use change in these commits? <roptat>at least guix refresh -l says there's only a handful of dependents <roptat>cbaines, from what I see, the second group adds some packages, and updates a few others that have no dependents? <rekado>my R updates probably are a bit much for the master branch <rekado>if you prefer I could push them to a separate branch in the future <roptat>I don't mind, I don't use any R package :) <civodul>cbaines: oooh, the typo in asdf-build-system.scm; my bad! <civodul>"fortunately" it's "only" Common Lisp packages <civodul>that's why we need the automation you've been working on :-) <cbaines>roptat, guix refresh is Ok, but I think there might be issues with rust things, due to the weird dependeicies via arguments thing. <roptat>so guix refresh is not accurate in that case <roptat>it's not accurate with inherited packages either <civodul>'guix refresh -l' is relative to a package anyway; it cannot compute the number of dependents of a file/module <cbaines>I've seen problems with deprecated packages too <cbaines>anyway, I'm more interested in getting to a point where there's more of a leaky bucket style rate limit approach, based on approximated build times <cbaines>rekado, providing bordeaux.guix.gnu.org keeps up (and it is at the moment), I generally don't mind <cbaines>(that's don't mind large changes being pushed) <gnarlf>Hello. Transmission bittorrent client installed with 'guix install transmission'. <gnarlf>No program in menu nor via terminal. <cbaines>gnarlf, you probably want guix install transmission:gui <gnarlf>Oh! I don't know something like that were necessary sometimes in guix <cbaines>multiple outputs are occasionally used, you can see the outputs listed if you do: guix show PACKAGE <tricon>I really can't thank everyone involved in Guix enough. I've long been fascinated by operating systems, and this one truly excites me. <gnarlf>In this case (transmission) I only saw 1 result that thought it was the needed. Maybe I missed something. Thanks <gnarlf>The only other issue where I'm stucked is trying to enable tap to click via gui settings in gnome. It doesn't appear in the options. Libinput installed and tried with synaptics <gnarlf>Is something necessary in the system config? <roptat>gnarlf, in "guix show transmission" (and in the results from guix search), there is a line that says "outputs: out gui" <roptat>that's how you know there are more than one output, and that you need :gui instead of :out (or simply "transmission" which is a shorthand for "transmission:out") <gnarlf>^^there is a line that says "outputs: out gui"^^ <gnarlf>Aaaah, see it now. Didn't knew for what was it <apapsch>a patch of mine doesn't show up in the two web interfaces, while some patches submitted later by others do. does gnu.org block outlook.com servers? <roptat>apapsch, if it's your first message to the list, it needs to be approved by a human <apapsch>roptat: yeah, it's my first message with the subject "[PATCH] gnu: php: Build sodium." <leoprikler>you'll get a mail once your bug has been accepted <roptat>apapsch, I can't accept it, but it should get through once a moderator validates your message, typically it takes less than 24h <avalenn>The guix install command could give a message when you install a package without precising output and there is several outputs <avalenn>To make people aware of the other outputs. <leoprikler>chances are people are already aware (guix search, guix show) <avalenn>I am just thinking out loud but I agree with roptat that UI is not great for multiple output packages <tissevert>by the way, question following the remark on multiple outputs: would that be the way to provide packages with support for various graphical toolkit or is it down differently ? <tissevert>(e.g. I see that the audacious package provides audacious with the qt toolkit, what would be the way to provide audacious-gtk ? a separate package ?) <leoprikler>you still need to build all outputs, which doesn't really help <tissevert>why doesn't that help ? because multiple calls to ./configure are needed ? <roptat>one idea for improving the UI would be to treat each output as its own package, so "guix search transmission" would return two "packages": transmission and transmission:gui, which would be clearer I think <roptat>ideally, we would be able to document outputs too, so there would be a different description for transmission and transmission:gui <tissevert>I don't think multiple outputs are that cumbersome, I don't remember how I learnt about it but I find it clear and convenient <leoprikler>there are some packages, that work quite well with outputs (case in point git:send-email) <avalenn>I find multiple outputs a great thing but I have the feeling we underuse them because they are not easily discoverable <leoprikler>but there are others where the metaphor starts to break (case in point transmission) ***tendousubaru[m] is now known as subaru[m]
<roptat>guix substitute: error: connect*: Connection timed out <apapsch>so, the friday evening rogue byte *did* strike ;-) <itismyfirstday>munksgaard: I tried to add a comment to the issue, but don't think it is going through. Here is what I wrote <leoprikler>tissevert: outputs are typically structured as "out" ← the thing you'll likely need and the rest being other stuff you'll less likely want <itismyfirstday>munksgaard: Having a similar problem (different package I'm trying to build). There is a guix package for cabal-doctest already, but adding to inputs or native-inputs hasn't helped me with the same error message. I can see in the log that cabal-doctest (whether the existing guix package or as in import above) is recognized for GHC_PACKAGE_PATH at <itismyfirstday>least, but runhaskell will need it in package-db (not sure how to check that, as it is in /tmp and immediately disappears). I tried adding another --package-db with the path to this library, but that didn't do anything either. <leoprikler>for instance git has its main program in out, but send-email in an extra output, because you'll commit more often than you'll be sending mail <leoprikler>for transmission, this breaks, because transmission is not geared well towards handling multiple frontends. <tissevert>so it's more like «tiles» of a given build of one program ? left-overs that you may or may not want ? <leoprikler>For instance, to build Fragment (another Transmission GTK frontend), you'll have to severely patch transmission's build and then run it as a separate process more or less <leoprikler>plus many users will arguably want the GUI, not like in python where the tk stuff can often be forgotten about <raingloom>heyyy, i'm building a system with a ~custom~ kernel and it's kind of urgent so i want to offload it, but for some reason it's built locally. my offload setup is a bit odd (only returns a machine if it can be pinged) but it definitely passes `guix offload test`. <raingloom>i also have a modified GUILE_LOAD_PATH because my machine configs are deduplicated into shared guile modules, but i don't think that should interfere with offloading?? <roptat>unless it interferes with the code in /etc/guix/machines.scm, I don't think so <raingloom>leoprikler: it's definitely not, it's not doing anything. and offloading used to work. <raingloom>guix offload status returns a normalized load of 0.03 <leoprikler>can you still offload other stuff (e.g. hello) or does that fail as well? <HiddenKarma>Hello, I'm installing Guix system on another machine using the stable build and I got the error "driver 'pcspkr' is already registered, aborting..." I just checked the issues page and the solution is to use the latest image, is there another way to fix the issue only using the stable image? <raingloom>leoprikler: guix build --check hello is also built locally <raingloom>discovery is also enabled and should be working, they are on the same LAN. <raingloom>it did work last time i checked. i build idris2 with offloading many times by just powering the big desktop machine on and then not even thinking about it. <raingloom>leoprikler: well. it does work if i revert the ping checking. uuuugh. <leoprikler>mapping outputs to propagated inputs is also a problem <leoprikler>in that case there might be something wrong with your ping checking? <leoprikler>I'm p sure that `guix offload` should itself handle an unreachable machine, no? <leoprikler>jackhill: don't propagate the input, instead add it to tlf with a comment <raingloom>i guess, but guix offload test always works. the problem is probably that it evaluates it much more often and sometimes the ping fails??? maybe??? <leoprikler>yeah, you have to be careful with stuff like that <ecbrown>cbaines: nice blog post, i have added bordeaux. what happens with bayfront? <raingloom>can't really think of a better way to do "offload only if target machine is available". i'll probably have to learn about avahi or something. and write a cookbook entry when i figure this stuff out. >_> <raingloom>(but also /etc/guix/machines.scm being evaluated multiple times within a second with no caching sounds like a bad idea. if that is indeed what's happening.) <mothacehe>I thought it was mitigated by the keep-alive mechanism :( <jackhill>leoprikler: sounds good, thanks for taking a look. I'll send a v3 shortly <sneek>Welcome back yoctocell, you have 1 message! <sneek>yoctocell, civodul says: thanks for testing cURL on Nix! <itismyfirstday>munksgaard: okay, realized there is a --keep-failed so I could see the package-db used in the build, and indeed cabal-doctest is present there. so I think it comes down to why runhaskell configure is not seeing a package in the db? or how to implement the custom-setup correctly at configure <civodul>yoctocell: yup, i'm glad we eventually found the source of the problem! <civodul>being unable to clone from bitbucket wasn't great <civodul>sneek: later tell mothacehe re server timeout, bah, we must have missed another reason :-/ <cbaines>ecbrown, currently bordeaux.guix.gnu.org and bayfront.guix.gnu.org actually point to the same substitutes, but this is a coincidence. If you want to use bordeaux.guix.gnu.org, I'd remove bayfront.guix.gnu.org <itismyfirstday>munksgaard sorry to keep spamming you here (I will need to add a comment to the issue report), but I think I figured it out. I don't think runhaskell is seeing some of the arguments passed to it, at least in the configure phase, so it is not getting the package db. will confirm, but that's what I'm seeing <phf-1> $ guix install glibc-locales <phf-1> $ export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" <phf-1> hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH' <lispmacs[work]>does Windows 10 come with something that can extract RAR files? Maybe I could take it over to my co-workers computer <dstolfa>lispmacs[work]: if it's not sensitive content, you can probably do it online. i don't think windows comes with something that can extract rar files <dstolfa>i wonder why there is no free software for rar files honestly <daveed>Hello. I am interested in using Guix Home. I have watched a couple of Andrew Tropins videos, but the backlog of videos is pretty large. Is there written documentation for Guix Home and his rde configuration? <roptat>ebubekir-siddik, I tihnk libarchive can open rar files, not entirely sure <dstolfa>hmm, my gnome actually opens sample rar files from unrarwindows.com <dstolfa>and my only channel is official guix <leoprikler>thing is, some rars come packed with weird stuff that breaks libarchive <daveed>dstolfa: debian has a package unrar-free, I'm not sure if it utilizes libarchive <dstolfa>daveed: would be worth looking into it for guix <leoprikler>from the description it looks like libarchive handles at least as much as unrar-free <roptat>how can I match the end of a line in substitute*? <roptat>I tried "z3$" to match z3 at the end of a line (to prevent matching "z3interface"), but it's not replaced as expected <leoprikler>does guile regexp understand stuff like "end of symbol"? <drakonis>daveed: have you tried checking his repository at srht? <roptat>bah, "z3\n" matches the end of line ^^' <daveed>drakonis: I will read his modified guix documentation, thank you. I guess once I understand guix home I will be able to make sense of rde. <roptat>binaries downloaded from the web don't usually work with guix <daveed>ebubekir-siddik: If you are okay with installing yet another package manager, you can install the tor browser bundle with flatpak and it works. <itismyfirstday>hi all, I'm sure this is in the manual but not seeing it: how can I make edits to e.g. guix build systems? use a guix repl? <itismyfirstday>(I think I found a bug in the haskell build system I want to test out) <itismyfirstday>was wondering if I can just live change in my current installation (on foreign os), but having a separate environment sounds better <roptat>it's possible to do these changes outside of a guix clone, but it's also a lot easier to do in a guix clone once it's setup <roptat>and a lot easier if you intend to share your changes, as you'll simply have to generate a patch, instead of having to figure out how to integrate your changes later <itismyfirstday>thanks. I've looked at the manual and did a git clone, set up that environment, made the changes, and now up to running make. after that I guess it is the "running guix before it is installed" in the manual, to use my hacked on guix <iskarian>how do I get secondary profiles to have proper search paths? It seems like only PATH is being set? Obviously I'm missing some step, but I have no idea what <roptat>you mean other profiles than ~/.guix-profile? you need to load their etc/profile <roptat>but note that guix can only put a variable in etc/profile if there is a package that needs it in that same profile <iskarian>Yeah, only PATH gets loaded. I just tested and it seems it works as long as the packages are for my native arch <roptat>so if you install guile in your default profile and guile-readline in a separate profile, you won't get $GUILE_LOAD_PATH etc <iskarian>if I add packages built for another arch, that's when the search paths aren't being set <roptat>ah, I don't know how it would work for another architecture <roptat>I don't think you want to mess these up with your native environment variables <iskarian>yeah, that's the problem. I'm trying to test a custom gcc built for another arch... for some reason `guix environment --system=powerpc64le-linux gccgo-toolchain` wants to rebuild gccgo even though `guix build ...` says it's already built <iskarian>so I'm trying to `guix package -i gccgo-toolchain -p newprofile; guix environment --pure -p newprofile` <iskarian>ah, actually that's `guix package -i /gnu/store/...gccgo-toolchain -p newprofile` <iskarian>since apparently guix package -i doesn't understand --system <roptat>iskarian, ah, but /gnu/store/... doesn't contain any info on search paths <roptat>only the package object (in guile) does <roptat>you're only installing an arbitrary set of files, not a package <roptat>also guix environment is probably missing a --ad-hoc <iskarian>thanks. now how the heck am I to get this package in a system? maybe I can specify system in a -e expression? <roptat>I never tried that, I don't know <iskarian>hmm, you're suggesting `guix environment --system=powerpc64le-linux -add-hoc gccgo-toolchain` instead? <roptat>yeah, without ad-hoc, it creates an environment that contains the dependencies of the package, with ad-hoc it creates an environment with the package itself <roptat>so it depends what you're trying to do :) <iskarian>Good to know :) I never really understood the difference between the two <iskarian>it still wants to rebuild the package unfortunately :/ <roptat>are you using two different guix versions for environment and build? <roptat>and with the same --system switch? <ss2>Hello! I'm just trying to recap the hashes being generated for each store item: When the hash of an input is generated, is the current version of said input taken into account? <roptat>iskarian, can you show /gnu/store/g0zgii5rg5wj5jv6whwylzam7h8rsrg5-gccgo-10.3.0.drv ? <roptat>ss2, hashes are generated for outputs, not inputs. For a fixed-output derivation, the hash takes only the name and expected content-hash into account. For other derivations, it takes the full name of the output (for a package, that's name, version, output), the architecture, a hash of the recipe, the location of the store (usually /gnu/store), and maybe other stuff <roptat>(when I say recipe, I mean the closure of the builder) <roptat>oh, and of course the store hash of the inputs <ss2>oh, I got the direction wrong. Meant the hash for the output. :) <ss2>ah, so it takes the inputs, and the hashes of the inputs? <ss2>hence, whenever the hash of an input changes, the hash of the output will change? <ss2>Since an input may change its own declaration. <roptat>iskarian, that's clearly not the same package: the guix build one has out, static and debug outputs, this one has out, lib and debug <roptat>iskarian, now, I don't understand why it's not the same package... <roptat>if an input changes, it modifies the hash of the output, and the change propagates further to dependents <roptat>that ensures reproducibility: a given store path can only come from a single process <roptat>so it guarantees that a store path can only contain one thing (well, as long as that process is reproducible :p) <roptat>but it's a bit strict, because there are an infinite number of processes that end up building the same bytes. guix is just playing safe <iskarian>roptat, isn't the out/static/debug for the toolchain and out/lib/debug for gccgo itself? <roptat>but looking at the derivation, it's building for x86_64 <roptat>if it works at all, I suppose it's moderated <roptat>iskarian, on my system "guix environment --pure --system=powerpc64le-linux --ad-hoc hello" creates a working environment where hello is a powerpc binary <roptat>(which is not very useful since I can't execute it ^^') <roptat>itismyfirstday, you'll probably have more luck sending an answer by email to NNNNN@debbugs.gnu.org, where NNNNN is the bug number <roptat>mh... I wonder what's going on then <roptat>oh, a native input in the toolchain? <roptat>mh? gccgo-toolchain is not in guix? <iskarian>the toolchain is just: `(define-public gccgo-toolchain-10 (make-gcc-toolchain gccgo-10))` <roptat>ok, so not an issue with native-inputs then <iskarian>how are you determining that the derivation is for x86-64? <roptat>one of the last elements is x86_64-linux <iskarian>okay, so `./pre-inst-env guix environment --pure --ad-hoc guile` is giving me a x86-64 guile <iskarian>ugh, and with --system it wants to build libgc <iskarian>the same but with guix wants to build glib... <iskarian>`./pre-inst-env guix environment --system=powerpc64le-linux --pure --ad-hoc gcc-toolchain@10` seems to work correctly <iskarian>gfortran (also made with custom-gcc) seems to work correctly as well <iskarian>the removal of #t at the end of a phase is triggering this <iskarian>Ah, I spoke too soon; any substantial enough change of custom-gcc triggers it <fellow-dev>Howdy. Do any of you happen to how I can cross compile network manager? Currently, I see "build system `meson' does not support cross builds" <iskarian>it makes me wonder if something is evaluating the phases at two different times and one of them is picking the wrong system... <nckx>fellow-dev: It's a limitation of how Guix abstracts Meson as meson-build-system, not of Meson itself, so the answer is ‘add cross-build support to Guix's abstraction’. <nckx>Unfortunately. If it were as simple as ‘set some existing option’ that option would already be set. <fellow-dev>Hmmm I see. I know very little guile, but what would be the next step to take to add cros build support to that <nckx>I'd take a look at how gnu-build-system does it. <nckx>I mean, I've never used it directly, only wearing my protective Guix. <fellow-dev>I see. Let me ask a completely different question, how would I go about setting the ip w/o nm on guix system? <jackhill>I read the meson cross building documentation briefly, but hadn't thought about how to plug that into the guix abstractions. Nievely, I don't think it would be too bad: make sure meson-build-system accepts the right keywords and that we provide meson machine files somewehre (where? In the cross compiler packages?), but unfortunatley, I haven't had a chance yet to play around with any of these ideas. <fellow-dev>Basically, the story is that I made an image for the pinebook pro, and I need a network connection <jackhill>unfortunately, static-networking (so far) only supports legacy IP and not IPv6 <jackhill>as I understand the v6 limitation, it's because we call directly into the kernel, and the scheme bindings for that have been started but not finished yet. <nckx>Kind of. I think we go through glibc (but didn't check) but the thrust is the same: we use the ancient uNiX aPi, which works out about as well in 2021 as you'd expect. <nckx>Linux would like you to use netlink. <dstolfa>unix apis are great, everything's a file until it's not and why is a signal handler racing with everything, how did this memory corruption get here and oh god why am i deadlocked <nckx>But network sockets are too special to be files so we'll just add some C calls oh dear that didn't oh god the blood is everywhere now. <nckx>(So now you configure the network by talking network to the kernel, which at least makes some kind of recursive sense.) <dstolfa>i do like/hate seeing the parts where people just completely gave up and just made it an ioctl lol <nckx>Day 4,436: everything is now one of 893 ioctls() called on /dev/ioctl and I still can't die. <dstolfa>but yes i think sockets and pipes are my favorite examples of "everything is a file and oh god what is this" <dstolfa>sockets in particular, because read/write/send/recv have completely different semantics and failure modes depending on the kind of socket or pipe <nckx>I mean, it's kind of honest in the pronunciation. No false promises there. <nckx>(If you claim to pronounce it efcontrol I'll not believe you.) <dstolfa>i recently had a fun experience writing an event loop that dispatched tasks to workers in C, but a lot of unix sockets were involved (two per task) and managed concurrently, all while signals could come in at any time <dstolfa>the amount of swearing involved was probably excessive <nckx>‘a lot of unix sockets were involved’ sounds like the end of an unforgettable friday night. <nckx>But commiserations & all. <dstolfa>if i ever get to design a new interface for protocols, it will definitely be inspired by multiparty session types *nckx doesn't work in software, gets pulled & pushed at once by such tales. <nckx>SEE the horror up close, FEEL the legacy pain, etc. <nckx>I mean, I quite enjoy legacy horror, so it's not that bad. <dstolfa>this is more like living the legacy horror rather than seeing it though <munksgaard>itismyfirstday: No worries at all. I'm not going to be home until sometime tomorrow, but your experiences correspond roughly to mine. I'd be great if we could work out what's missing <thrilleratplay[m>I am trying to bootstrap Gnat/ada with debian binaries and am making a mess of it. In the IRC logs samplet mentioned doing this with a total of 26 deb packages. Does anyone know where a copy of that script is? <dstolfa>nckx: sent in a patch to update strongswan to the latest version. using it myself and have no issues