<roptat>I don't use the openvpn-service anymore actually... <smithras>I was looking into it a year ago, I ended up not bothering with the service and just running the server manually when needed <rmra>hello, does anyone have a problem when using guix with the geiser (emacs)? <roptat>raghavgururajan, I don't have one anymore, so I can't, sorry <roptat>I think that was before I started collecting my configs in my repo <raghavgururajan>roptat: No worries: I am trying to set up mine, I get some errors. Are you available to discuss? <roptat>no sorry, I stopped using openvpn before I started this repo <roptat>we can discuss if you want of course <roptat>I don't see a configuration on that page <raghavgururajan>During system reconfigure, I get "shepherd: Service vpn-client could not be started." <roptat>ok, there are some explanations, but no reference to a file in /etc or /var right? <raghavgururajan>That is proabably because I did not change anything in openvpn-client-configuration <roptat>I think you need auth-user-pass, nothing else <roptat>it should be a filename that's outside of the repo, because it will contain your username and password <raghavgururajan>I guess the "VPN Server: vpn.riseup.net" is for "openvpn-remote-configuration parameter: string name" <roptat>you'd have something like '(remote (list (openvpn-remote-configuration (name "vpn.riseup.net") (port "1194"))))' <raghavgururajan>roptat: So only field to use in openvpn-client-configuration scheme procedure are: [1] openvpn-remote-configuration [2] auth-user-pass ?? <roptat>that should be the file you're supposed to download and verify <raghavgururajan>The ca file form riseup is in .pem format. But the manual says its .cert? ***sturm is now known as Guest77255
<raghavgururajan>For auth-user-pass, should I create a plain text file in /etc/openvpn, which has username and password is separate lines? <roptat>raghavgururajan, I think the format is good <roptat>.cert is not a specific encoding anyway <roptat>also the ca file should be .pem, not .pam ;) <roptat>you can use a file-like object for the CA, it's public anyway <roptat>here you pass a string, which is just copied to the config, and it happens to be a file name <roptat>a file-like object creates a file in the store, so there's a bit of a type-check, but a file in the store is world-readable <roptat>file-like objects are created by plain-file, computed-file and co <roptat>A good way to check you config is to run openvpn manually with the generated config <roptat>then you'll see error messages and such <roptat>no, I mean openvpn --config /gnu/store/... or something like that ***amfl_ is now known as amfl
<guixy>Does anyone here run guix on an Intel Atom CPU? <roptat>raghavgururajan, yeah there's an issue with the service, but that doesn't tell what <raghavgururajan>roptat: I am using connman instead of network-manager. Would that make any difference? <roptat>no, networking is any networking service <roptat>so that doesn't make any difference <roptat>guix system would have told you if a networking service was missing <raghavgururajan>To connect manually, openvpn /gnu/store ... where can I locate the config file in the /gnu/store? <roptat>guix gc -R `readlink -f /run/current-system` | grep openvpn <roptat>my connection is very unstable, I keep disconnecting from my bouncer... ***amfl_ is now known as amfl
***catonano_ is now known as catonano
<guixy>How useful is guix on an airgapped laptop? <guixy>When I try to boot into an sd card, it says it launches a repl. <guixy>It says "waiting for partition 31393730-3031-3031-3139-333534353239 to appear..." a few times, then starts a repl. <guixy>This happens on multiple different laptops. <guixy>I'm building an install ISO to see if that also fails. I'm already drafting a bug report. <guixy>It happens with both x86 and 64-bit iso images <guixy>I'm getting the same behavior from an i386-linux install iso built with a recent commit. I'll send the bug report. ***apteryx is now known as Guest74417
***apteryx_ is now known as apteryx
<lane>Q: I've finally gotten the project I'm packaging to build, but the built executable doesn't have the correct RUNPATH. I found the place in the Makefile where RUNPATH is set, so I know I can use `substitute*` to change it to the correct value before building. What I'm not sure about is how I should be setting the path. The executable depends on `.so` files from its inputs. Does this mean those libraries need to be propagated-inputs? <efraim>lane: I'd do a grep through the code for 'rpath', adding (string-append "LDFLAGS=-Wl,-rpath=" %output "/lib") to configure-flags might be enough <lane>efraim: Thanks, I tried that but it didn't seem to work- maybe it would if I had the libs as propagated inputs... <maav>lane: IIUC, these shouldn't need to be propagated inputs, but I think you'll need to add "-Wl,-rpath=" (assoc-ref %build-inputs "otherlib") "/lib" to LDFLAGS too <maav>being otherlib the dependency you have to add to the runtime library path <maav>lane: or substituting the Makefile if providing LDFLAGS to the configure script isn't an option, of course <wehlutyk>after a `git pull` on my guix checkout, on master, I `./bootstrap` and `./configure --localstatedir=/var` then `SHELL=$(which bash) make check` (otherwise my shell being fish some tests fail), I'm hitting a `failed to load 'guix/scripts/system/reconfigure.scm'` error, followed by `ice-9/eval.scm:293:34: In procedure allocate-struct: Wrong number of initializers when instantiating #<record-type <gexp>>`. Does this ring a bell? <wehlutyk>all this in a `guix environment guix --pure --ad-hoc bash which less -- bash` environment <efraim>possibly something changed and you might need to remove some now stale go files. My first suggestion is to do make clean-go <lane>maav: That seems to do the trick, thanks! <bdju>can someone update the qt packages? specifically I wish qutebrowser were built with 5.15 instead of 5.14.2. it may or may not fix an issue I'm having loading websites that use cloudflare <bdju>and is anyone else using qutebrowser having cloudflare problems? <mange>Is there an easy way to build a disk-image that embeds the current Guix version after a "guix pull"? I've noticed that we have current-guix in (gnu packages package-management), but it doesn't seem to work from a "guix pull" (the documentation around it implies that it needs to be run in a source checkout). Presumably I could write my own package definition to get the "source" from... somewhere? <efraim>bumping qt is a major undertaking, it'll take a bit *civodul just fixed an embarrasing thinko in 'version-1.2.0' <civodul>mange: no really "easy" way, but i'd like to support that <civodul>the installation system tests do that <civodul>but it only works in the context of ./pre-inst-env IIRC <mange>Okay, excellent! That gives me something concrete to work with. I'll see what I can do with that. Thanks! <civodul>it's probably safer but then we need people to actually test it <lane>Hmm, I'm working on submitting my first patch to add a package, and `./pre-inst-env guix lint mypackage` is failing with `error: define-json-mapping: unbound variable`. Anyone run into this before? <nckx>lane: Try installing guile-json (version 4, I believe) into your environment. <maav>lane: happy to help. I cannot keep the pace of the IRC, hehe :-) <nckx>civodul: I'm certainly game but capped at <100K/s, might literally take all day or more. <nckx>My ISP hates humans and wants them to infect each other & die. <civodul>we'll wait for your downloads to complete <nckx>‘Tip: download during off-peak hours.’ Great idea, I'll schedule meetings at 2am now, thanks. <nckx>‘[A]ccording to N. Decaro and A. Lorusso in Veterinary Microbiology (May 2020), "Novel Human Coronavirus (SARS-CoV-2): A Lesson from Animal Coronaviruses", pigeons are not known carriers of COVID-19’ <nckx>civodul: Would that RC2 be current version-1.2.0? <nckx>Then I can start building it now. <nckx>maav: Plus the frame rate is terrible. <maav>nckx: yeah, but you can get a whole flash-card attached to the message, hehehe <maav>poor pidgeons, nonetheless <nckx>‘Sorry, forgot attachment, I'll try again tomorrow.’ <nckx>maav: Apparently they're starving in the streets due to lack of ‘food’/cigarette butts. <lane>nckx: Working from the git repo, that means I would do `./pre-inst-env guix package install guile-json@4.3.2` right? I still run into the error when running `./pre-inst-env guix lint mypackage` <nckx>Are you running ./pre-inst-env in something equivalent to ‘guix environment guix’? I think that's necessary. <lane>Yep- `guix environment --pure guix` <nckx>You can add ‘--ad-hoc guile-json’ to that. <lane>It seems like the right version should be included in the environment anyway, right? <nckx>I can't reproduce your error. <nckx>Yes, it should be a native-input. <maav>i just tried too and it's working on my pc too <nckx>guile-json@4 is also in Guix's closure. I'm not sure what's up. civodul? <lane>hmmm. haha I guess it couldn't hurt to try restarting. Be back in a minute <nckx>sneek: Later ask lane: So to be clear, I can run ‘guix environment --pure guix -- ./pre-inst-env guix lint dear-imgui’ without issue (assuming it ever finishes fetching CVEs at this pace :-/ ). What are you running? <nckx>Pretty sure that's a lie. <lane>nckx: After a fresh restart, I do `cd ~/src/guix` `guix environment --pure guix` and then `./pre-inst-env guix lint dear-imgui` and get the same unbound variable error <maav>lane: ok, could you do echo $GUILE_LOAD_PATH and readlink -f $GUILE_LOAD_PATH/json/record.scm? <lane>maav: $GUILE_LOAD_PATH -> /gnu/store/fiqh61n2b4fdr4vy3a0abg6agy82yczf-profile/share/guile/site/3.0 <nckx>sneek: I apologize. Botsnack! <lane>Output for the other command: /gnu/store/12y1s0p3585ydf336gq85kjh5217pnzp-guile-json-4.3.2/share/guile/site/3.0/json/record.scm <maav>ok, cool, now do the same but with ./pre-inst-env bash -c 'echo...' <maav>the simple quotes are important <lane>Output for the first one: /home/lane/src/guix:/home/lane/src/guix:/gnu/store/fiqh61n2b4fdr4vy3a0abg6agy82yczf-profile/share/guile/site/3.0 <lane>The second one seems to give no output <maav>you have to bootstrap+configure again <civodul>nckx: perhaps lane is running an old guix, and thus "guix environment guix" provides guile-json < 4 <maav>civodul, nckx: nope, we're not tracking the dependencies about the environment on ./pre-inst-env, therefore a possibly gc'ed profile can stay there <maav>it hasn't to be old, just gc'ed since ./configure call <nckx>OK. I did rebootstrap recently. <lane>Still running into the error after bootstrap + configure... <maav>lane: hmm, could you check the ./pre-inst-env echo again? <lane>Exactly the same output as before <maav>civodul: nope, my bad, it's PKG_CONFIG_PATH the one stored... <maav>(not there, in config.status) <lane>`guix show guile-json` shows that 4.3.2 is available... <maav>lane: what shows fgrep json config.log? <maav>i have guix_cv_have_recent_guile_json=yes <lane>guix_cv_have_recent_guile_json=yes <lane>Also since I tried to install 4.3.2 in the pre install env before, it shows up when I do `./pre-inst-env guix package --list-installed` <lane>Is there a straightforward way to totally reset the pre-inst env? <maav>lane: that isn't the pre-installed-env, that's your profile <maav>if $GUILE_LOAD_PATH/json/record.scm exists, that should be enough for guile to find it <maav>could you simply launch a guile session and try (use-modules (json)) <maav>perhaps there is a more useful error there <lane>Seems to work (using `./pre-inst-env guile`) <lane>Also `(use-modules (guix cve))` succeeded <lane>(Which is where the error is coming from when I do `guix lint`) <maav>lane: ,apropos define-json-mapping ? <maav>could you try (use-modules (json record)) and the ,apropos again? <lane>Seems to be defined then: (json record): define-json-mapping <lane>So IIUC this environment has the right guile-json, but somehow in the context of running `guix lint` it's not getting resolved? <maav>guix.m4 already checks exactly that form... and it's used on (guix cve), could you try loading that? <lane>so `(use-modules (guix cve))`? <lane>yep that loads successfully. I'm trying `(guix-lint "package")` now to see if it makes any difference whether I try to do it from a shell vs. from the REPL <lane>Guile is spending a lot of time compiling files before I get the output from that. Going afk for a bit <maav>lane: that's a bad sign to me, you should "make clean-go all" then <lane>maav: I'll try that. The linting worked this way however... <lane>maav: After running "make clean-go all", `guix lint` works from the command line. Thanks again! <divoplade>Hi! I'm testing my service definition by creating an operating-system definition with just that service (and the required fields), then create a docker-image of that system, start it and run bash as described in "invoking guix system". But, if I run herd status, my service is not listed. <divoplade>The user which is supposed to run my service exists <divoplade>It extends account-service-type, to add the user, and shepherd-root-service-type <divoplade>Maybe the -root- service is intended to be run as root! <divoplade>Well, shepherd-service-type does not seem to exist <leoprikler>just looked at the code, shepherd-service-type is syntactic sugar for shepherd-root-service-type <leoprikler>for the record, the service should be recorded if you run a full-blown vm <nckx>divoplade: root- just means tree root, as in root of all evil. <lane>hmmm I sent my patch in about 45 minutes ago and it hasn't shown up on the issue tracker yet. Is there usually a sizable delay or did I mess something up? <lane>yep, to guix-patches@gnu.org <lane>"[PATCH] gnu: web: add uriparser" <lane>Cool, no worries- I just wanted to see if it was a sure sign that I did something incorrectly <nckx>It can take multiple hours I'm afraid. For reasons wholly unknown. <lane>Oh man... do you know if that's a guix specific issue or does it apply to all projects using debbugs? *civodul spawns "make release" for RC2 and goes out under the sun ***w2gz is now known as w1gz
<nckx>lane: I assume it applies to the entire GNU debbugs instance, as in I can't think of anything that makes us special. <leoprikler>lane: if this is your first patch, you will have to pass moderation, which can be rather slow <leoprikler>once your address is known, things are typically faster <nckx>All that is true but that's not what's happening here. <nckx>There are no pending requests. <divoplade>I have this error that popped in today: guix system: error: service 'qemu-binfmt' requires 'file-system-/proc/sys/fs/binfmt_misc', which is not provided by any service <apteryx>you have to restart the qemu-binfmt service as well as the guix-daemon <apteryx>hurd doesn't restart any service that are already running <divoplade>guix system: error: service 'dockerd' requires 'file-system-/sys/fs/cgroup/blkio', which is not provided by any service <apteryx>Is it the first time you added dockerd to your config.scm? <apteryx>and when did the error appear? Was it after manually restarting the dockerd service? *divoplade is trying to bisect the problem with guix commits <apteryx>unattended upgrades? through a mcron job you manually configured? <nckx>apteryx: There's a unattended-upgrade-service-type. <nckx>divoplade: A reboot will probably ‘fix’ this, but it's great that you're willing to find the cause ♥ <nckx>There was a similar debugfs error a while back. <divoplade>So I'll know if it's a problem with guix or something else <nckx>apteryx: Newish, few months old. <divoplade>apteryx, if you do this, reduce the number of cores of the guix daemon <nckx>I haven't been brave enough to try it myself. <divoplade>I have icecat in my system packages, and whenever something changes in rust I need to rebuild it ^^ <nckx>Rust changes on master should be avoided but it doesn't seem to be documented. And they're easy to overlook. <maav>it seems the error divoplade has seen is already fixed on version-1.2.0, who's merging this time? ;-) *nckx not volunteering, just curious 😉 <maav>nckx: 37b98e8cca, looking at the message <nckx>I'd be very likely to fuck something up by butting in at this late stage. I'll just test things. <nckx>I don't even have it yet, must be very new. *nckx waits patiently while individual commits are flown in per pigeon. <divoplade>So it works with the older commit 71456036de246694b393a6697af0c73d0901b65d, trying branch version-1.2.0... <nckx>civodul: When you return from the sun, it looks like 37b98e8 needs to make it to master somehow. <maav>divoplade: the problem seems to be introduced by 977eb5d023 <lane>yet another question: I'm working on packaging something that includes a command line utility which is installed in `out/bin`. I was expecting that if I do `./pre-inst-env guix environment --pure mypackage` then I would be able to execute it, but that doesn't seem to be the case <nckx>lane: You need --ad-hoc mypackage to include mypackage itself, not it's build inputs. <nckx>lane: So your mail just arrived now... <nckx>Who knows where it's been. What it's seen. <zimoun>the download/latest about Hurd Binary return 502, is it expected? <divoplade>OK I confirm the problem is fixed in version-1.2.0 <nckx>What's supposed to be listening on berlin's localhost:8081? <nckx>zimoun: The problem is in cuirass-web, which returns an empty reply for both /download/1385 and /download/1450 (latest binary tarball & Hurd qcow2), but not for /download/1692 (latest Guix System). <nckx>Has the GC [root] policy been tweaked again? <civodul>nckx: we'll merge version-1.2.0 in master <civodul>zimoun: that must be a problem with Cuirass, maybe email bug-guix so people notice <nckx>I'm already writing a report. <nckx>Oh, I missed divoplade last message. <nckx>If they both fix the problem I think I prefer 37b98e8. <civodul>nckx: could you just merge version-1.2.0 into master? <civodul>that way you'll get the fix that i pushed <nckx>civodul: Done. Hope I did it right. <nckx>luis-felipe: Thank you for making them. I like them. Like Efraim, now I have trouble choosing between silver or gold... <jeko>"guix deploy" in progress… \o/ <civodul>zimoun: lack of substitutes, generally speaking, is due to the CI mess :-) <jayspeer>what is the best way to "apply a patch" to a package? `nqc` packaged in guix doesn't include usb support (which is added by patching the original source) <divoplade>I'm trying the new merge for my problem, but guix warns me that there will be 785 MB to download <zimoun>civodul: I am almost sure it is fixable because IMHO the current design (static offload) and huge store to GC (with deduplication I guess) does not scale. Now we know :-) I really hope for fruitful discussions on this area in the 2 sessions: Fix the CI and Coordianator. <jonsger>are mesa updates happening nowadays on core-updates or staging? It has 2k deps <zimoun>civodul: sometimes the substitutes are available on Bayfront, does it make sense to fallback before trying to build locally from source? <nckx>jayspeer: Ideally, if the patch is hosted somewhere stable on the 'net, you add a PATCHES field to SOURCE, with an ORIGIN field that points to it. Otherwise, it might be appropriate to ship the patch with Guix (in gnu/packages/patches) and using SEARCH-PATCHES. <nckx>It depends a bit on the size & nature of the patch. <nckx>zimoun: What do you mean by ‘IO issue’? It's not fs damage, just that (apparently) Cuirass didn't create a GC root (or deleted it too soon), so the GC cron job deleted the images before their time. <nckx>divoplade: Could you share the list of what's being downloaded? I want to make sure it looks sane. <jayspeer>nckx: since the patching is the straightforward part of the thing I'm trying to accomplish, let me share you some links which explain what I need to do <jayspeer>don't worry :D it's like 3 commands normally <jayspeer>I'm not sure how to do it correctly so it can go upstream <civodul>zimoun: what would fall back to what? :-) <jayspeer>my first thought was to add another build phase, which adds and applies this patch. But after second thought, I've came to the conclusion that it might be stupid, given what guix is trying to accomplish <samplet>Hooray! My local Cuirass is building Disarchive metadata. It’s even using the Scheme interface via “with-extensions”. :) <nckx>jayspeer: Since that SF link looks pretty stable, use the first approach I gave above. <nckx>Take a look at rust-winit in gnu/packages/crates-graphics.scm to see it in axion. <nckx>Since it's an origin you'll have to specify a hash. guix download gives me 0z5gx55ra1kamhhqxz08lvvwslfl36pbmwdd566rhmbgmyhlykbr. <samplet>Now I need to: make it run on my bigger computer; find a way to use the results; and fix various other Disarchive-level problems. <zimoun>civodul: try ci.guix.gnu.org then fallback to bayfront.guix.gnu.org then build locally <nckx>zimoun: Why *wouldn't* that make sense? Lots of people do that. <jeko>oh "guix deploy" take a loooot of time… 30minutes actually. Can I assume there is something wrong? <zimoun>nckx: yeah but that’s not automatic, or I miss something <zimoun>basically, guix build foo try a lot of different upstream source (build farm, mirrors, etc.). and try only one (official) susbtitute build farm; or 2 are up, if I read correctly. <cbaines>zimoun, sounds like you are talking about the default list of substitute servers/keys <cbaines>adding bayfront might be nice, although the downside is that checking for substitutes and not finding any does have a cost (in time) <nckx>I think what you mean is that Guix will trust a positive (‘I have that’) narinfo response, and fail hard if the server can't serve it, without falling back to the next server in the substitute-urls list? <cbaines>and bayfront has even worse substitute availability than ci.guix.gnu.org <nckx>Or do you mean that bayfront should come as a default out of the box? <nckx>(Is it as trusted as ci.guix?) <zimoun>nckx: yes and I do not know about the trust. <cbaines>nckx, they used the same signing key for a long time... <zimoun>nckx: :-) default out of the box <zimoun>cbaines: what do you mean by this downside? <nckx>zimoun: The more servers you add, the more time Guix spends polling them (‘Checking for’... or whatever it prints) when you build something. <zimoun>nckx: except for quick builds, this extra cost is always fewer than the build time <nckx>It's not a lot of traffic and it's reasonable efficiently pipelined by our standards but it's still noticeable. <zimoun>so the user is ready to pay this cost, I guess <zimoun>and maybe, it could help to reduce the store of Berlin. I mean, choosing accordingly the GC policy on the both <cbaines>The answer is 520 with the data the Guix Data Service has <nckx>zimoun: Anyway, I don't see any drawback to shipping bayfront as a %default-substitute-urls besides first making sure bayfront is as trustworthy as it should be. <nckx>It would just provide redundancy (like when a build fails, such as Gmsh). It's puny compared to berlin. <nckx>Most requests would never make it to bayfront, which is probably good. <zimoun>nckx: yeah it just eases the Guix experience. Especially when Cuirass hangs; like these times. <zimoun>what is the storage size on Bayfront? <cbaines>Regarding trust, I think the way forward there is using multiple substitute servers. I want to get back to looking at that at some point <nckx>Yeah, I notice plenty of downloads from guix.tobias.gr too. <zimoun>cbaines: nice! and thanks for looking at it. <cbaines>I haven't actually bothered to check/track if anyone else is using guix.cbaines.net *nckx → away in a manger. <zimoun>cbaines: the mago link is about bayfront, right? <zimoun>cbaines: yes, it is bayfront. Sorry I miss the obvious :-) *zimoun says see you then <apteryx>if they're annotated shouldn't that be automatic? <civodul>vagrantc: thanks for the reminder, done! :-) <civodul>apparently "git push" alone doesn't cut it <civodul>i do that through Magit though, maybe it does something special, dunno <Rovanion>Is there a guix equivalent of nix-shell or python viirtualenvs? That is: a tool which allows you to download and activate a virtual shell environment with the packages needed to develop some piece of software without polluting the user or system environment. *vagrantc hopes to add armhf to the successful builds of guix in Debian <civodul>email sent, upload is still running but almost done <apteryx>civodul: ah, the git option is 'git push --follow-tags', or set push.followTags to yes in your .gitconfig <apteryx>it'll push annotated tags by default <vagrantc>civodul: i see you only publish RC versions on alpha.gnu.org rather than ftp.gnu.org ? <lane>is there a way to run programs installed using guix as sudo? <vagrantc>i usually use push.followtags=true, though for some projects explicitly disable it <Rovanion>Thank you civodul! I wasn't able to find it by searching DDG, would it be OK to add a mention of `nix shell` on the manual page to help future people like me? <jayspeer>I can't seem to figure out a basic thing - how do I build packaged from updated definition in the source tree? <jayspeer>running `./pre-inst-env guix build nqc` keeps returning the same thing over and over, no matter why I do to the source file :/ <bavier[m]1>jayspeer: should the change result in a build? Things like changes to description, synopsis do not cause a rebuild. <jayspeer>I've updated the source (added a patch) - but even deleting the whole file (gnu/packages/lego.scm), keeps returning the same output without error <jayspeer>just to be clear: I should 1. updated the package definition, 2. run `./pre-inst-env guix build nqc`. Or am I mistaken? <bavier[m]1>./pre-inst-env should use the in-tree package once the tree is configured. <jayspeer>ok. I've reseted my branch, add my changes back, run `./bootstrap` and `./configure --localstatedir=/var` and then `./pre-inst-env guix build nqc` <nckx>jayspeer: Can you share your diff? <jayspeer>nckx: what is your preffered way to view it? <nckx>The pastebin in the topic (paste.debian.net) if it's up this week. <nckx>anarkat: We can't help you find love, only freedom. <nckx>But one isn't worth much without the other, I guess. <anarkat>nckx: sorry about that my sister is trolling me <jayspeer>well, my problem is - I've deleted the package definition all together, and the `./pre-inst-env guix build nqc` still returned the same output <jayspeer>so something is fishy, somewhere - no idea what :D <nckx>jayspeer: I've applied your pasted diff here and ./pre-inst-env applies the patch. (It fails, unfortunately...) <jayspeer>hmmm, how can I make it fail on my machine too? <nckx>I have no idea. What you describe sounds correct. <nckx>I'd ask you to ‘make clean-go’ or re-bootstrap but you say you've done that too. <nckx>(The latter should more than imply the former.) <nckx>(But maybe not, I tend to put stuff like that in ./nckx/bootstrap scripts and never look at them again.) <jayspeer>damn it, still the same outcome! I'll just try deleting the whole repo at this point <nckx>Meanwhile, in my deterministic universe: any way to pass ‘-p0’ to (patches ...) patches? <bavier[m]1>jayspeer: will you be packaging brickemu too? ;) <nckx>Ah, patch-flags is a thing. <jayspeer>bavier[m]1: not likely, never used it, since I have like 6 rcx bricks just laying around <jayspeer>I'll probably try my hand at pybricks though, after I get my hands on the new mindstorms <jayspeer>what the hell, it still ends up in the same way; could the problem be that I have this package installed? <nckx>Eww, nqc-3.1.r6.tgz is a tarbomb and we were just ignoring it because it worked. <nckx>No wonder the patch doesn't apply. <nckx>There's url-fetch/tarbomb to cope with it. <nckx>Maybe this package predates it. <jayspeer>first I need to figure out how to get my system to behave, I'll get back to you after that <nckx>Using that & removing the deal-with-tarbomb phase works. <jayspeer>no idea what is going on at this point :( `./pre-inst-env guix build nqc -v 10000` ← this, just returns this → `/gnu/store/6yh8xsjy1fdrir14b8765kf4ms4g2m59-nqc-3.1.r6` no matter what I do <lfam>jayspeer: That means that it's already been built <jayspeer>my setup must be wrong - added nonsensical stuff to other package def and guix just fetched it from the substitutes <lfam>That usually means that your build environment is not set up correctly, yes <nckx>Sanity check: what does ‘./pre-inst-env guix edit nqc’ show? <nckx>It should edit the lego.scm in your cwd repository and show your changes. <jayspeer>nckx: why, of course not the stuff it should <nckx>Whatever your editor is, can you find out which file it's actually showing? <jayspeer>it's a definition from the store, not the source tree <nckx>I mean, I guess your regular guix is leaking into the pre-inst-env PATH? I've never encountered that before. <nckx>guix environment guix -- ./pre-inst-env which guix ? <jayspeer>nckx: `/home/jayspeer/.config/guix/current/bin/guix` <nckx>*lfam just pauses for a minute to increase tension* <lfam>I don't use `guix edit` so I can't speak to its relevance here. But usually when `./pre-inst-env` stops working for me, it's when I've garbage collected the build dependencies and failed to rebuild my Git tree <lfam>The result is that guix falls back to using its default — i.e. ~/.config/guix/current <jayspeer>I haven't gced today, and this is clean state source tree - I've just redownloaded it <lfam>So, try creating a Guix development environment and re-running `./configure --localstatedir=/var && make` <nckx><run `./bootstrap` and `./configure --localstatedir=/var` and then `./pre-inst-env guix build nqc`> <lfam>Did you build it yet jayspeer? <nckx>jayspeer: Did you not run make? <divoplade>nckx, your merge commit solved my problem, thanks! <nckx>Oh, now lfam types, never mind. <jayspeer>of course not - point me to the place in the docs which says I should <nckx>Sorry, it was just a suggesh. <lfam>Check the manual chapter Contributing. Specifically the chapters Building From Git and Running Guix Before It Is Installed <jayspeer>I've read this thing like 3 times today :D <jayspeer>nckx: it's building right now, my dual core isn't that fast <nckx>Just FMI, are you running all of this in a ‘guix environment guix’? I don't know what the docs say, and I don't want to confuse you, but it's what I do and it always works. <jayspeer>and sorry if I'm being a jerk right now, but the docs don't say in any place one should run `make` :( <nckx>jayspeer: Don't worry, Guix isn't fast anywhere. <lfam>"Finally, you have to invoke make check to run tests" <lfam>That should be found in the section Building From Git <jayspeer>as a typical software developer I don't run checks until something breaks :p <lfam>I suppose it should be clarified that running `make check` implies that compilation will occur <jayspeer>this might have been a big assumption on my part though, so I see your point <lfam>This section of the manual is chronically problematic <lfam>It's not really your fault <lfam>There is tension between making sure the instructions are "complete and correct" and "easy to understand" <lfam>The part about localstatedir is another long-term usability issue <jayspeer>there is also no implication anywhere that building the project is necessary to test package definition <nckx>I still think it's a bit hubristic to skip steps without even thinking back to them when things fail, but that's human nature and not aimed at you personally jayspeer. <lfam>I think that, for people not accustomed to Guix, it's surprising that "package definitions" are software and are integrated with the broader piece of software called Guix <jayspeer>well, to my defense everything seemed to be working just fine. too fine unfortunately ;) <nckx>I think I understand why the person who wrote that combined ‘make’ and ‘make check’, I think they were trying to avoid shootings in feet, but it has drawbacks too. <lfam>Yes, the failure mode is seriously misleading <lfam>I wonder how we can improve this situation. I'd say it never makes sense to use `./pre-inst-env` with a Guix found in ~/.config/guix/current <lfam>Maybe the script should error out if that is the case <lfam>And we could change the manual to instruct users to do `make && make check` <jayspeer>↑ this one would be certainly be helpful IMHO <nckx>Yes, there should be more sanity checks in code vs. ‘we mentioned it in the manual somewhere so it's taken care of’. <nckx>Meh. The manual telling you to run ‘make && make check’ instead of the 100% equivalent ‘make check’ is only helpful if you're sneakily planning on skipping ‘make check’. <lfam>The second chapter implicitly depends on the first because you only get the `./pre-inst-env` script by following the instructions of the first <jayspeer>who never skipped checks, be the first to stone me :) <lfam>Well... people don't know that `make check` includes compiling <lfam>And I run `make` almost every day but almost never run `make check` <lfam>I'd describe `make && make check` as an "affordance" to user-friendliness :) <lfam>And even though it would be redundant... it's not as redundant as explaining it on IRC <nckx>If they don't know what it includes they shouldn't skip it. Anyway, I don't like this ‘humans are lazy, but it's documentation that doesn't pander to them that is flawed, not them’ trend but it's not going to change any minds ☺ <nckx>Clearly it's in our own self-interest to do so. <jayspeer>the first problem with tools is that their built for human in first place :( <lfam>I think that updating documentation is a band-aid. The ideal solution is to make it so that it doesn't require documentation <nckx>Soon we will dispense with flawed meatbags entirely. *nckx failed the Turing test again dammit. <lfam>What about making pre-inst-env more robust? What exactly could it check for? <lfam>The failure case you get after `guix gc` is not great <nckx>lfam: I don't know. What's the failure case now? I don't tend to run into them. I suspect most of the folks who could be annoyed into fixing the current tools don't. <ngz>Hello. I just packaged axel, which is a so-called download accelerator. I'm wondering in what file it could go. AFAIK, it doesn't handle bittorrent, bittorrent.scm is not appropriate. So, would you have any idea? <jayspeer>IMO the only problem with the first chapter is that it never implies the `make` as a necessary step of the setup. `make check` implies this is just for tests and the chapter refers to hacking on guix directly - so if one just wants to add/update a package definition, one will think that this step is not necessary <lfam>ngz: The networking module? <lfam>nckx: If you have a working development environment and garbage collect it, the pre-inst-env script will "silently" begin using ~/.config/config/guix/current, and so you won't actually be testing your changes in the Git repo. Depending on what you are testing, this can be really confusing <lfam>jayspeer: I understand your point of view jayspeer. Like I said, I don't run the test suite often. But everything in the directions is mandatory :) <jayspeer>`make` finished and my package finally failed to build! what an astounding success :) thanks for the support <lfam>That's why it says "you *have* to invoke make check" :) <nckx>jayspeer: Ah, think I see what you mean now. Hacking on package definitions *is* hacking on Guix (there is no Guixpkgs, no ‘Guix package repo’), the two are intertwingled, but as (I think) lfam mentioned above it's not common knowledge. <lfam>I'm actually not sure exactly what 'pre-inst-env' falls back to after dev dependencies are garbage collected. It may fall back to the already-built .go files in the Git repo. In any case, it fails to warn that code changes are no longer effective <lfam>Well, it's a developer tool for developers and not a first-class part of Guix, but it would still be nice to avoid this <jayspeer>nckx: I've interpreted *hacking on Guix* as playing around with like `deploy` and `system`. Comparing packages to those seem like "library vs variable" if you get what I'm getting at. <nckx>lfam: Oh wow, that is extremely surprising. I promise I would have stomped off to fix it if it had happened to me even once. <civodul>vagrantc: yes, alpha.gnu.org is meant for pre-releases <lfam>It's all-in-one jayspeer. Like the Linux kernel integrating drivers and core, we do it all in the same codebase <jayspeer>lfam: still, I don't expect having to run test for the whole kernel, after adding a variable somewhere <lfam>It happens to me after every `guix gc` nckx. I've learned to follow gc with a `./configure && make` <nckx>jayspeer: Absolutely. It's just so obvious to long-time users that it took me a moment to realise what you meant. <lfam>You don't have to jayspeer. Just run `make` <lfam>You couldn't test the kernel without doing that anyways <jayspeer>documentation by asking on irc can get very tedious :D <lfam>We ask users to run `make check` because we need bug reports from weird systems <nckx>If you want to do the ‘I know what I'm doing’ dance it's still fine, you just skipped one word too many. Drop ‘check’, not ‘make’. <jayspeer>I have never implied that I have any idea on what I'm doing <jayspeer>if I had we would never had this convo in the first place ;) <ngz>lfam: as a data point, the `guix gc' issue has bitten me a couple of times already. ***nothingmuch_ is now known as nothingmuch
<jayspeer>nckx: you've mentioned that you've managed to build the nqc with the patch, can you share your work? <ngz>Well, it's not an issue, per se. Anyway. <lfam>ngz: Yes, I've helped several people get past it before <nckx>ngz: Actually, it is, and I think it's worth tracking in a bug report (by anyone). <nckx>jayspeer: Not quite, and I lately got distracted by posturing on some weird IRC channel. <jayspeer>nckx: don't worry about it then (I've assumed you've basically finished it), I'll try to do it myself <nckx>‘Error: could not create compiler/rcx1_nqh.h’ <jayspeer>maybe we should have a go with the debian patches <nckx>jayspeer: That gives the exact same error. <lane>Can anyone here help with an issue regarding shared libraries? <ngz>nckx: would a reproducer be : modify some package 'foo'; guix environment guix; guix gc; ./pre-inst-env guix build foo <-- silently builds unmodified foo. I didn't test it because "recovering" from a guix gc takes ages. <nckx>lane: There's no better place at least. <nckx>ngz: Defining ‘unmodified’ is harder than just checking ‘which guix’ in the environment. <nckx>If it's not $PWD/scripts/guix, you will not be going to Guix today. <ngz>By modified, I meant something obvious as "update version". <nckx>I mean that building anything is a roundabout way to test for using a different guix. You can get away without it. <nckx>I get the same error with all Debian patches applied. <jayspeer>nckx: I'm getting the same error without any patches at all :( <lane>haha ok, I'll try: For some context, I'm trying to package openFrameworks, a fairly popular framework for creative coding in C++. It basically just glues a ton of libraries together and provides a more unified interface that's a bit more newbie friendly. My goal is to eventually use it as a way to teach Guile/Guix, but for now I'm just trying to package it for Guix. Currently, it's successfully built by Guix, but there's still some <lane>issues. Part of the installation is a "project generator" which uses templates to make a new openFrameworks project (i.e. generating some basic source files and a Makefile). So when I install my package, I can use the project generator and successfully compile the generated project. However, the generated executable crashes immediately, apparently due to missing/mismatched shared libraries. Using `readelf` and `ldd` I get some hints <lane>about the exact problem, but it's unclear to me how this type of problem can even occur. <lane>For example, `glew` is a dependency, and according to `readelf` the executable is looking for `libGLEW.so.2.0`, but in the `lib` of my guix profile, only `libGLEW.so`, `libGLEW.so.2.1` and `libGLEW.so.2.1.0` exist <jayspeer>nckx: sanity check: plain build works (without any changes) <ngz>nckx: I understand. The thing is I don't know what `which guix' is supposed to return compared to the guix executable from `./pre-inst-env guix'. IOW, I don't understand how to check what changed at this level between before and after the gc. ISTM that `which guix' always return the same thing in both cases. <lane>I guess I could work around this by creating a symlink from `libGLEW.so.2.0` -> `libGLEW.so` as part of the installation, but it seems like the fact that I'm using the same `glew` during the build process means that the executable should have the correct filename already... <jayspeer>nckx: huh, I wonder what was wrong in your original attempt <nckx>ngz: Anything else is wrong. <nckx>Anything else will give ‘old’ packages. <nckx>$PWD/scripts/guix never will. <nckx>jayspeer: Nothing AFAICS, I need to compare the build environments with & without /tarbomb. <jayspeer>nckx: compiles, but doesn't work unfortunately - I get `USB Tower not supported` <jayspeer>damn it we've broke the sourceforge nckx xD I'm getting 503 due to high traffic <ngz>nckx: Unfortunately: "guix environment guix; guix gc; ./pre-inst-env which guix" still returns $PWD/scripts/guix so I assume this is not a good reproducer =/ <civodul>"./pre-inst-env which guix" always returns the same thing, it's designed for that :-) <ngz>Yes, of course. I just cannot figure it out how to create a reproducer. It may involve a guix pull updating "guix" somehow… I'm really grasping at straws. Ah, well. <nckx>civodul: And yet it returned ~/.config/guix/current/bin/guix. <nckx>Assumptions are wrong somewhere, and they aren't checked. <nckx>jayspeer: Wow, and Guix should cache the patch it once it's downloaded. <nckx>jayspeer: I don't think the /tarbomb variant (that fails to create compiler/rcx1_nqh.h) is wrong, per se, but that the nqc build system somehow behaves differently when the directory name changes even if the contents are the same. <nckx>Anyway, that's a separate issue. <nckx>The native-input solution is ugly but works just as well. <civodul>nckx: uh i don't see how that's possible, pre-inst-env starts by setting PATH <ngz>could this be related to the XXX in the script/guix script? <maav>good night/day, hackers! :) <jayspeer>nckx: I've played around with this stuff some more, my finding: building normally the patch works, I can talk to the robot with the usb device. Package built with guix doesn't work, seems the patch wasn't applied; trying to find a workaround <jayspeer>I suspect it's related to combination of these two things: tarbomb download & patch has to be applied from a directory which contains the project directory (so one level bellow) <nckx>jayspeer: I haven't had time since posting that patch but I suspect it has no effect on the output at all. <jayspeer>On unrelated note - does anyone here use magit when working on guix? It's really slow for me <jayspeer>nckx: something still is not right, package compiled, but I get empty output everytime when I'm running it <jayspeer>wait, I'm getting empty on the other binary too <civodul>jayspeer: Magit is terribly slow if you have changes under po/ <civodul>make sure to run (cd po; git checkout .) when that happens <jayspeer>nckx: sorry I was being an idiot - everything works! <ngz>civodul: you can also set `magit-section-initial-visibility-alist' to something useful to help a bit, if my memory serves. <ngz>Mine is '((stashes . hide) (untracked . hide) (unpushed . hide)) <civodul>it's not good for my mental health to see 200+ stashes every time i hit M-x magit-status <ngz>Odd. '((stashes . hid)) is the default value <jayspeer>thanks to our combined effort we've managed to make my robot move forward for one meter after only ~4h of work! great job guys :) <jayspeer>nckx: can I count on you to merge this update or should we try incorporating the debian patches too? <civodul>ngz: oh you're right, it's the untracked files that are filling my screen :-) <bavier[m]1>jayspeer: If you send a patch, I can look at it. I might even test it. <nckx>jayspeer: The error was entirely mine - I didn't expect you to spot that typo. Sure, I'll merge it. <nckx>jayspeer: What do the Debian patches add? I'd rather not add things just to add things. <nckx>Debian tends to patch things more than we do. <jayspeer>they mentions fixing this and that - I'll try to verify what exactly they do, but not until the Saturday unfortunately <jayspeer>that's what happens when you try to make fulltime job, uni, hobby and healthy amount of sleep go in tandem - pro tip: they don't ;) <nckx>Definitely won't add cosmetic things like the compiler warning one. <nckx>It's what I do and I'm perfectly healtzzzzzzzzzzzzzzzzzzzzzzzzzzz <jayspeer>this one seems useful `make sure swan code do not segfault` - I'll need to verify with the swam firmware <jayspeer>this one too `apply defaul serial name to /dev/rcx` - if someone has more than one serial port this will be helpful <nckx>(The ‘not segfault’ one.) <nckx>The random SF discussion thread patch has 524 lines over Debian's apply-legousbtower.patch's 88. <nckx>No Debian patches mention TCP. <jayspeer>the TCP stuff will be useful for the rcx simulator s1 mentioned before <bavier[m]1>I mentioned it, yeah, but I don't plan on packaging it soon. <jayspeer>I imagine that anyone who has interest in such a piece of software will own at least one rcx, so it's kinda unnecessary <jayspeer>bavier[m]1: can share the name of this simulator? I'd like to keep it somewhere in my mind <jayspeer>Though first I plan on packaging the pbForth - which will be a challenge, since the author vanished and repo went offline (wayback machine still has it fortuntely) <ngz>civodul: I didn't test the last patch set, and there have been at least two attempts to update Poetry to 1.1.4 meanwhile, so I kinda lost track of it at that point =/ <nckx>Why does Debian change /dev/ttyS0 to /dev/rcx? Is that just a cosmetic/distro policy change? <jayspeer>nckx: by default the `nqc` assumes the /dev/ttyS0. Which I imagine was annoying to anyone who connected something else there <jayspeer>so they've set the /dev/rcx as the default, which you can set to be the symlink to the desired port <jayspeer>`nqc -d your_program.nqc` vs `nqc -S/dev/ttyS1 -d your_program.nqc` - so purely for convenience <nckx>That's what I mean by cosmetic though. <nckx>That does not meet the bar for inclusion in Guix for me. <jayspeer>sure, I imagine that if you meet anyone in the future who is at the same time using: 1) guix, 2) 20y old lego mindstorms, 3) has multiple serial ports in their machine; then you'll more than glad to patch it up ;) just for the novelty <nckx>If they write a udev rule to make the symlinking automagic, deal! <jayspeer>It's been a pleasure interacting with you guys, unfortunately one has to sleep sometimes. See you around <bavier[m]1>I've wanted to try pbForth, so I will look for your patch :)