<str1ngs>guix-vits: I don't think you can package qtwebengine differently in the context of build less build heavy <str1ngs>if you want something that not to build dependent I'd recommend something based on webkitgtk. epiphany if you like scheme.. nomad :) <pkill9>how easy would it be to build the tor browser for guix? it's really just firefox but modified to reduce fingerprinting identification, so maybe it could just be built with icecat? <morrigan__>I'm trying to do a headless config with just dhcp, it's telling me networking is not provided by any service. It's been a while since I've done any admin stuff; what services provide networking? <str1ngs>guix-vits: god knows I tried when I created the qtwebengine package :) <palpares>dftxbs3e: yop guix might be a good choice for server. however not sure guile would be appreciated by system admins <guix-vits>pkill9: Aren't the tor-browser isn't packaged in any distro yet? <str1ngs>guix-vits: I think webkitgtk is probably the best of the bunch for build time and usefulness. currently it takes about 20min on my ryzen 5 3600 6 cores and 6 threads. I'm using webkitgtk-unstable with nomad. <emsyr>morrigan__ I think network-manager-service-type should do the work. <str1ngs>guix-vits: though qtwebenine is probably the better renderer in terms of performance. provided you have hardware acceleration. <emsyr>morrigan__ you're welcome. I'm glad if I helped. Keep up the good work... <morrigan__>I like Guix a lot. Hoping to figure out how to use Docker w/ Guix <emsyr>morrigan__ just did a search for docker and found it is already in guix packages. <OriansJ>well we literally are able to make docker images so that is kinda expected <valignatev>I really like these self-contained tarballs that guix can produce. <brettgilio>Sorry for my unexpected leave from Guix. Life was pretty miserable for a bit. I am good now though. Work was treating me terrie. I am back. <brettgilio>But it worked out well. I have a better job now, with better pay <brettgilio>I hadnt touched my Guix machine in weeks because all of this change was eating up all of my time. <nckx>…and wow. OK. Glad you're on the other side of that mess. <brettgilio>nckx: bandali raghavgururajan tldr. They changed my working schedule without notifying me. They were going to write me up for taking leave when my kid was born. They got mad at me for saying that was bullshit, and wrote me up for insubordination. They would pester me nonstop. So i left. And thank god. <brettgilio>My new job is Backend dev in C and Java. Not my fav langs, but it pays better and the people are nicer. So ill take it. <brettgilio>raghavgururajan: after using guix, all non-guix stuff feels messy. <nckx>raghavgururajan: Now that's what I call a happy ending. <nckx>brettgilio: Good god. And good riddance. <raghavgururajan>KE0VVT Stability. I have something to say regarding Guix. I will be sending an email to guix-dev soon. <nckx>The past week has not been a great one for Guix stability. <brettgilio>*flashback to when the build servers were dead for several weeks* <nckx>Yup. All software sucks. <morrigan__>guix is throwing an `unknown keyword or bad argument` error on a `#:use-module` line <morrigan__>I'm currently trying to write a package... what does "source expression failed to match any pattern" mean? <nckx>We already do. But yes, let's. <nckx>morrigan__: It usually means that you used an invalid field name in a (package) record, or that you're nesting's wrong (forgotten bracket) so that something is interpreted as a field that isn't. Impossible to say without context. <raghavgururajan>morrigan__ I think it's regarding how you express source URL and protocol. <nckx>raghavgururajan: No, it's not that. <nckx>morrigan__: If you can't find it, paste your source (to a bin) and we shall help. <nckx>raghavgururajan: It's a Guile error, ‘source’ is not related to the Guix record of the same name. <morrigan__>nckx: yeah I wound up figuring it out. Always ask ddg first <morrigan__>I'm packaging writefreely btw. No idea if Guix will want it once I'm done, but that's what I'm up to <nckx>morrigan__: We certainly will! (…unless there's something fundamentally objectionable about your package itself.) <morrigan__>For a git package, how do I get the base32 hash? The one I got from `guix download` is throwing an error <nckx>morrigan__: Best-effort WIP packages are also welcome at guix-patches@. <nckx>morrigan__: guix hash -rx in a *pristine* checkout. <nckx>morrigan__: …or just copy the ‘found’ hash from the error message. <nckx>morrigan__: Yes. Which you want it to. <morrigan__>Okay, so just git clone the repo and then hash it <nckx>morrigan__: It might be guix hash -rx . (with dot), I forget. <morrigan__>It's throwing an error when I give it `agpl` in the license field <morrigan__>Is there a way I can just list the available licenses? <nckx>I just use ‘grep define guix/licenses.scm’. <nckx>morrigan__: You need to say which AGPL version: agpl1, agpl3, or agpl3+. <morrigan__>Oh no the source doesn't say whether it's 3 or 3+ <nckx>morrigan__: If it doesn't include the ‘at your option…any later version’ wording, it's 3-only. <morrigan__>How do I read the build logs? Are they just bzipped? ***wxie1 is now known as wxie
***goldenshimmer[m] is now known as goldenshimmer
<guix-vits>morrigan__: hi, maybe you'll get some use of ... <morrigan__>I'm trying to package something with an unusual but not very complicated build process <KE0VVT>raghavgururajan: Received. Thanks. <bandali>hm, i see it depends on two nodejs packages <bandali>i'm not sure about the state of node and generally js packages in guix :-/ <morrigan__>I've already packaged `go-bindata` and `nodejs` can fill the other node dependencies so long as the base package is current <drakonis>node has deps to the tune of a cool thousands <morrigan__>drakonis: wait, do you mean nodejs itself or node packages? <morrigan__>I know the state of node dependency chains is nuts <guix-vits>bandali: how did you find out it needs nodejs? <bandali>guix-vits, saw in the pkgbuild file morrigan__ linked above <bandali>it seems to make-depend on nodejs-less and nodejs-less-plugin-clean-css <morrigan__>I was mistaken. It's not base node, but `nodejs-less` only depends on base node and npm <morrigan__>The other dep doesn't go too deep either. It depends on nodejs-clean-css, which depends on base node and npm <bandali>ah, looks like we have (gnu packages node) and (gnu packages node-xyz) <bandali>okay, so i'd look writing package definitions for those two nodejs-less packages in node-xyz <bandali>looks like their dependencies don't run deep luckily <guix-vits>bandali: github page claims: "you only need to be able to run an executable.". And tags have no JS. Why? <OriansJ>morrigan__: we tend to reduce the number of binary blobs possible in guix <bandali>guix-vits, what OriansJ says. we generally don't use any pre-built binaries in guix <bandali>so, our package definitions build everything <bandali>the main chunk of writefreely is go, but it also seems to have some JS bits too <bandali>but in particular, those two node packages seem to be required for compiling LESS style files into plain CSS <morrigan__>Is it better practice to pull node packages off github or from the npm registry? *guix-vits will try to ask less questions, to not mess with the work. <bandali>morrigan__, the ones in node-xyz seem to all get the sources from github <morrigan__>bandali: I'll go with github then. There's better versioning, in any case <bandali>and no worries about asking questions <morrigan__>Trying to build from non-master branch. How do I specify that? <bandali>the (commit ...) field actually takes any git ref <morrigan__>Not sure how critical they were but 3.11.0 is passing <bandali>morrigan__, also, if you see packages through guix, there are tons of examples of specifying a version tag from git <morrigan__>Sorry I have a bad habit of asking questions and then immediately realizing the answer <KE0VVT>bandali: Hm. Less CSS is kinda cool, but the complexity might not pay off. <bandali>KE0VVT, right, it can definitely be handy for large amounts of js. another similar thing is SCSS <bandali>but yeah while some of less or scss's features like nesting are handy, i personally prefer to keep things as simple as possible and use plain css <morrigan__>guix package is telling my my base32 hash is invalid <bandali>hmm, firstly, not sure if the `-f base32' is necessary <bandali>did you remember to `git checkout' the right branch or release tag before running `guix hash -rx .' ? <morrigan__>bandali: it defaults to nix-base32, which will yield a different string <morrigan__>But the hash should validate the repo as-downloaded, no? <bandali>well, the contents of the repo :-) which depends on part on the active branch <morrigan__>Still telling me it's invalid. I'll try with the nix hash <bandali>can you give us the repo address, and perhaps paste your package definition you have so far in a paste service? <bandali>mainly, i'd like to see how you're specifying the hash in your package definition <morrigan__>Actually, does Debian's pastebin service let you push from the command line? <bandali>but yeah you can check some examples in the (gnu packages node-xyz) module for specifying the repo hash <morrigan__>Huh. So I finished writing the definition, and it shows up when I `guix package -s` but... <bandali>i can maybe take one more question :p <morrigan__>When I `guix package -i` it gives me an unknown package error <bandali>yeah at the point it'd be best to give the package definition :-) <bandali>but as a shot in the dark, make sure your definition has a (name ...) field <morrigan__>I assigned it a different name from its package name <morrigan__>Welp, the build failed and the error message is out of my league. I think that's a signal I should stop for tonight <morrigan__>A desktop is up! I have two node packages that failed for the same reason, which I'll look into tomorrow <g_bor[m]>I am about the end of packaging postfix finally. <g_bor[m]>I would need to add setgid 'postdrop' programs to the os to get rid of the warnings. <g_bor[m]>Don't get me wrong, everything is working right now, when using root to the stuff, but that's not what the users expect. <g_bor[m]>Right now the setuid programs stuff seems to be limited to setuid root. <g_bor[m]>I would propose extending it so that setuid and setgid to the user and group designated would be possible. Wdyt? <guix-vits>g_bor[m]: so `postfix` will be own by postfix:postfix and runnable by users? <g_bor[m]>guix-vits: actually postqueue,postdrop and maildrop should have a group postdrop and be setgid. <g_bor[m]>These are the least trusted parts of postfix. <g_bor[m]>This would allow separating mail admins to a group. <guix-vits>it will be an improvement, according to Wikipedia :) ***Noctambulist is now known as Sleep_Walker
<bricewge>The shepherd page is not clear enough about where to send patches, is it guix-patches as usual? <raghavgururajan>janneke I wanted to ask you something. Would you be able to share the system config you used for sway setup please? <dftxbs3e>hmm, an interesting discovery I made regarding bash-static removed store reference in gawk is that it appears only in powerpc64-linux-gnu output, not x86_64-linux-gnu.. weird. <janneke>raghavgururajan: i haven't used sway, i am using exwm <janneke>raghavgururajan: usually %desktop-services, to be able to run the occasional gimp, evince, totem or eog <janneke>dftxbs3e: saw your mail this morning and then forgot to reply until i saw you here :) <janneke>raghavgururajan: but for a fresh install i sometimes start with %base-services <dftxbs3e>janneke, I'm glad you even replied the first time. Feeling a bit helpless on this port :-S <raghavgururajan>janneke Ah I see. Thanks. Will those apps work with just %base-services and *dm-service-type? <janneke>i know the feeling ... things took a while for me to make sense <janneke>raghavgururajan: i haven't figured out, really, but that's my impression <raghavgururajan>janneke I am looking to setup desktop-like environment with dm+dmenu, slim-service-type and %base-services. What other service should I be needing? <efraim>dftxbs3e: is there a grep-boot0 for intel systems now in core-updates? might be easiest to just use some of those new packages and remove them from static-binaries <janneke>raghavgururajan: there's this *-schemas thing and gio-* binary from glib that sometimes prevent applications from starting <dftxbs3e>efraim, what do you mean? Also, I didnt use core-updates as a base because core-updates is broken in all kinds of other ways not related to powerpc with bootstrapping. <dftxbs3e>at least, it used to be, and I didnt have quite the knowledge to figure it out. <efraim>dftxbs3e: i got farther on core-updates than on master. janneke added a bunch of *-boot0 packages to core-updates that could be useful to smallerize the bootstrap binaries for new architectures <janneke>yeah, sorry for breaking those with my merger -- i hope that i'm learning :) <janneke>efraim: currently, we go from "grep-mesboot" straight into "grep-final" <dftxbs3e>mesboot isnt used for any other arch than x86 and maybe ARM, correct? <janneke>i think grep-mesboot can be seen as an early grep-boot0 <efraim>oh, I thought there was a grep-boot0 also <efraim>i just assumed since there were a bunch of others also <janneke>dftxbs3e: correct, not even ARM just yet, but real soon now <janneke>efraim: i had to look, a bunch of *-boot0 were added <janneke>i did that demand-driven; apparently grep-boot0 was not necessary <janneke>but no harm in adding it, certainly not as an experiment for ppc <dftxbs3e>can't wait until all of GNU Guix is based on gcc-9 so all options required for POWER to go well are enabled. <efraim>at the very least I would guess adding a grep-boot0 as an input before %boot-inputs should make it be first <dftxbs3e>I've purchased 6 more sticks of 32GB of RAM, once GNU Guix works I'll run Cuirass and fix everything ***apteryx is now known as Guest30736
***apteryx_ is now known as apteryx
<efraim>macbook41_config might not work, that machine overheats and I haven't booted it in at least 2 months <efraim>E2140 and E5400 do work for sure though <raghavgururajan>efraim I see that you have removed bunch of services from %desktop-services. Instead of that, if you were to use %base-services, what other services from %desktop-services would be adding to your system config? <dftxbs3e>janneke, is rewriting strings inside binaries going to be safe anyways? <efraim>looks like there's actually a whole bunch that I do leave <raghavgururajan>efraim Yes, I have looked at it. My doubt is how do you declare some of those services outside of %desktop-services? <efraim>I'd add them the way they're listed in %desktop-services, like (service colord-service-type) <janneke>but then again, being careless is not always safe <dftxbs3e>janneke, I'll have a try at this heh. I'm a Scheme noob so excuses in advance, does substitute* take a list? is that why you provide ((find) (replace))? <raghavgururajan>efraim Ah I see. Would the desktop (englightment in your case) work with out services in "The D-Bus clique." block? <efraim>I'm pretty sure enlightenment uses dbus and avahi and some of the others. At least we build it that way <raghavgururajan>efraim I see. Thanks. If I am using just window-managers with slim, do I still need services mentioned in "The D-Bus clique." block? <efraim>raghavgururajan: that I'm not sure about. I suppose it would depend on what you're willing to live without <janneke>dftxbs3e: yes, (("regexp1" ...) "replacement1") (("regexp2" ...) "replacement2"); have a look at a pattern that matches what you need <janneke>dftxbs3e: are you using --system=powerpc64le-linux ? <raghavgururajan>efraim I was wondering if display managers (any) work without accountservices, polkit, and elogind. <dftxbs3e>janneke, I build with --target=powerpc64-linux-gnu when I'm on x86 for bootstrap binaries and else I leave it default. <efraim>raghavgururajan: I haven't tried any. I started using Guix System with xfce and then got enlightenment working and haven't switched around since <NieDzejkob>dftxbs3e: --target cross-compiles, --system does a native build, potentially through QEMU <NieDzejkob>cross-compilation yields different store hashes than native builds <guix-vits>NieDzejkob: so --system may not work on CPU without virtualization support? <dftxbs3e>guix-vits, virtualization never works if you specify a different system than current anyways (unless i386 on x86_64, or ppc on ppc64, for example) <NieDzejkob>dftxbs3e: not true, you just need the qemu binfmt service <dftxbs3e>NieDzejkob, I mean, it's not virtualization then <efraim>dftxbs3e: you got the execve("/gnu/store/eeeeeeeee... ) from strace? <efraim>OK. I'll try straceing with my grep-boot0 <dftxbs3e>efraim, gawk spawns sh internally, grep-boot0 may not <janneke>huh? i'm doing ./pre-inst-env guix build --target=powerpc64-linux-gnu bootstrap-binaries (or --target=powerpc64le-linux) <janneke> and get /gnu/store/5bdaayvl6cs8nrdivskz4dbrsy2m009c-bootstrap-binaries-0 <janneke>which says: file /gnu/store/5bdaayvl6cs8nrdivskz4dbrsy2m009c-bootstrap-binaries-0/bin/tar <janneke>/gnu/store/5bdaayvl6cs8nrdivskz4dbrsy2m009c-bootstrap-binaries-0/bin/tar: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.30, stripped <dftxbs3e>janneke, it turns out regex can't work when patching binaries directly <dftxbs3e>looking at remove-store-references but it's getting quite complex <dftxbs3e>basically I just need to replace first bytes of the match with sh\0 <bricewge>Sending a patch series feel clunky: first sending the cover-letter to guix-patches waiting for the acknowledgement and then sending the actual series to debbugs. <bricewge>Is there a way to send the series in one go through debbugs, so that the tracker know this is a guix patch???????????????????????????????????????????? <bricewge>Sorry my keyboard has a mind of is own... <janneke>debbugs is a terrible perl hack and debbugs.gnu an unmaintained fork <efraim>dftxbs3e: might be gawk, not grep <janneke>i think that rekado is looking into this <dftxbs3e>janneke, do you know about sourcehut? this looks like a good fit for GNU Guix! It supports git email workflow and provides a minimalist javascript-less web ui for all of it. issues, patches, and CI <janneke>it would be amazing to have a modern guile implementation of debbugs <bricewge>janneke: He is looking into building a debbugs in guile or only alternatives to the current system? <efraim>dftxbs3e: adding gawk-boot0 and grep-boot0 I got further on glibc-intermediate. Have to see if it builds and if it can work without grep-boot0 <dftxbs3e>janneke, seems like it doesnt work over HTTP, only HTTPS <bricewge>Ho he wrote the beautifull Guix frontend. <bricewge>dftxbs3e: I have similar issues when searching for bug I get a 504 but a retry ~10s later return the correct page. <efraim>i forgot how long it takes glibc to build, still building it here <dftxbs3e>janneke, I'm doing powerpc64 big endian because it doesnt inhibit a long double format change in glibc, but seeing how it pans out, I'll probably be able to do powerpc64le too then *efraim is working on 32-bit ppc <dftxbs3e>janneke, I'm hoping to also use GNU Guix as a way to massively build and test software on OpenPOWER, so both endians is nice <NieDzejkob>sneek: later tell ngz: FYI, you forgot to --signoff on the nheko patchstack you pushed. I tried to find an option to signoff by default, but failed miserably, so, uh... be more careful next time ;) <dftxbs3e>civodul, binary monkey-patching gawk ..... <dftxbs3e>that ends up being the only accessible solution <NieDzejkob>civodul: I just realized, for the space monitoring on ci, you could have some other machine ssh and check. "pull" monitoring, if you will. <civodul>NieDzejkob: pull monitoring... sounds hacky :-) <civodul>you can remove "guix:" from the subject line <civodul>does that ring a bell? janneke maybe? ↑ <janneke>civodul: hmm, mingw cannot build shared and static simultaneously <dftxbs3e>how would I get the store path for a package in Scheme? <janneke>civodul: hmm, i cannot read the error; is mingw-w64-i686 failing to build; or is someone trying to reference its (nonexisting) #:static output? <NieDzejkob>dftxbs3e: I'd look at how guix/scripts/build.scm does it <efraim>glibc-intermediate built with gawk-boot0 and grep-boot0 added. now to try it out with just gawk-boot0 <efraim>made it past the initial "can't find nptl", now to wait the rest of the 70 minutes it takes to compile <dftxbs3e>efraim, ah ok. so did you rebuild gawk during bootstrap? <efraim>dftxbs3e: there's a gawk-boot0 on core-updates, %intel machines need it for the bootstrap from mes, I added it as a native-input to glibc-intermediate and it picked it over the gawk from bootstrap-binaries <civodul>janneke: yes, something is referring to the "static" output of mingw <efraim>I almost have a good solution for vim addons in guix, just need to figure out how to work with GUIX_ENVIRONMENT <NieDzejkob>that's good to hear efraim, I'd love to manage my vim plugins with guix <efraim>" let plugins be managed by guix <efraim>if isdirectory($HOME . "/.guix-profile/share/vim/vimfiles") <efraim> set rtp+=~/.guix-profile/share/vim/vimfiles <efraim>hardcodes ~/.guix-profile, but it works for me™ <NieDzejkob>huh, I thought there was some environment variable that did this... <janneke>civodul: so....should we add one, or find the client and convince them not to do that? <dftxbs3e>is it merge-able to use `dd` to do binary patching? <dftxbs3e>echo stuff | dd of=target bs=1 seek=offset <dftxbs3e>and to get offset: grep -obUa '/gnu/store/[a-z0-9]\{32\}-bash' gawk | tr ':' ' ' | gawk '{print $1}' <frafra>I am interested in using guix to use it in software development and in production with Docker; I created a manifest which requires Python 3.7, but there are some dependencies and commands I would like to run afterwards to prepare the environment... should I create an adhoc package for that? how to proceed? here is what I run for a small tool I am developing: $ guix environment --container --network --pure --ad-hoc --manifest=manifest.scm bash -- bash -c <frafra>'pip3 install --user poetry && export PATH=$PATH:$HOME/.local/bin && poetry install && poetry run csv2tabulate --help' <efraim>somewhat related, we have poetry 0.12.17 <janneke>frafra: i don't get the docker relation, but when using guix to create an environment i provide anything i need by installing guix packages <dftxbs3e>janneke, creating images for docker to run? <efraim>I'd love to use mcron instead of "mbsync -a && sleep 300" or the like <janneke>frafra: does this help, can you use poetry from guix? <g_bor[m]>I have found that our current setuid-programs installs the binaries not only setuid but also setgid. <g_bor[m]>I did not find a mention about this in the docs. <g_bor[m]>This seems to be very low risk currently. <dftxbs3e>ugh - execve("sh", ["sh", "-c", "test -d nptl"], 0x3fffd5d7ffd0 /* 41 vars */) = -1 ENOENT (No such file or directory) <dftxbs3e>no, it's in PATH, but execve wont find it <str1ngs>right execve that's the fullpath for the first argument <dftxbs3e>str1ngs, how to tell it to seek for it in PATH entirely? can the first arg be NULL? <frafra>efraim, I have seen it, thanks :-) <dftxbs3e>janneke, so I need to use execvp instead.. <civodul>janneke: re the "debug" output, i'm not sure; i don't think anything change in that area so i'm a bit confused <frafra>janneke, it is nice to have an dev environment that matches the one you use for production (Docker in my case), but instead of using Docker + bind mount on my machine to develop, using guix seems way nicer, and then I can generate Docker images with guix pack <str1ngs>dftxbs3e: execvp should work but in the case of /bin/sh it's probably not okay to use that <dftxbs3e>why is it not okay to use it in the case of /bin/sh? <str1ngs>use the full path. It's okay to expect /bin/sh to exist <dftxbs3e>str1ngs, it doesnt exist during bootstrap, does it? <str1ngs>that's about the only thing you can assume to exsit <str1ngs>even when bootstrapping you need /bin/sh so in most cases that's a static binary or created extremely early <str1ngs>if you are using this with guix you can even go so far as to make a shell script instead and substitute the shabang <janneke>civodul: "debug" output, you mean "static"? -- /me is getting confused <dftxbs3e>str1ngs, if I use /bin/sh I think it will use my host system's /bin/sh <civodul>janneke: yes, i meant "static", sorry; so the problem happens when doing: guix build --target="i686-w64-mingw32" bootstrap-tarballs *civodul tries adding a "static" output to mingw <str1ngs>dftxbs3e: the use PATH for sh is not right either. in the context guix just create a shell script and substitute the shebang <dftxbs3e>str1ngs, PATH has /gnu/store/nnd6nvq9m327bvb34pqjhvy0khpk559y-bootstrap-binaries-0/bin which contains sh - so I should create a shell script called 'sh' in the current directory and have it point to /gnu/store/nnd6nvq9m327bvb34pqjhvy0khpk559y-bootstrap-binaries-0/bin/sh <str1ngs>dftxbs3e: right if the file is part of a guix package this should get substituted automatically IIRC. though probably you using the boostrap sh is overkill <dftxbs3e>str1ngs, I used: (symlink (string-append (assoc-ref %build-inputs "bash") "/bin/bash") "sh") <efraim>i made it past glibc-intermediate to fail at glibc-final <dftxbs3e>efraim, good progress! I finally also made it past glibc-intermediate - it built in less than 2 mins for me <alextee[m]>i have a GUI toolkit that uses cairo, and then a program that uses that toolkit that also uses cairo <alextee[m]>should i make cairo a propagated input on the GUI toolkit? <alextee[m]>i think the correct thing would be to have propagated inputs on ztoolkit for cairo, librsvg and libx11 <alextee[m]>and then including ztoolkit as a native input to zlfo <alextee[m]>but then cairo would be a native input? maybe that's wrong <NieDzejkob>but then the dependencies will also get propagated to the user's profile, no? <dftxbs3e>Got this now.. output (`/gnu/store/gj7dma1dlyakz7g5mpdikkrljn7ikr4h-binutils-2.32') is not allowed to refer to path `/gnu/store/nnd6nvq9m327bvb34pqjhvy0khpk559y-bootstrap-binaries-0' *janneke peeks at wip-guile3.0-packages and quickly looks away -- scary stuff <janneke>dftxbs3e: that was for your earlier success...just reading your last problem now <dftxbs3e>janneke, I think that's about binutils-final, but not sure.. <janneke>dftxbs3e: you could use the fold-port-matches trick from remove-store-references (guix build utils), i think <nckx>efraim: Have you built vim@8.2.0303 on x86_64? <efraim>yeah, and vim-full. I used bayfront <nckx>And not a one-off, I tried updating vim myself and got the same error. 🙂 <nckx>Hm, it's btrfs so perhaps. I'll check. <nckx>But how the hell do you get that hunch from that output? <efraim>mismatches are sometimes race conditions, it seems switching the ref on CoW is slower than just changing the file <efraim>and I have to remember to do that on my machine when I boot up <nckx>efraim: What the… 😃 It worked! *efraim has the magics today <nckx>So I 'sume this isn't reliably fixable by disabling parallel tests? <nckx>Oh they are already disabled never you mind me. <nckx>OK, vim. You win. This time. <efraim>oh good, I was going to say it might also help it pass but shouldn't be the real way to do it <dftxbs3e>janneke, so I solved it. It's because my edits to glibc-intermediate propagated into glibc-final, so I needed to create a different `sh` symlink with a different bash for glibc-final, so I did that. Testing now! <nckx>At least chattr is stateful. *cries* <dftxbs3e>janneke, you don't imagine what kind of relief that is to finally succeed... I've been literally depressed out of this. <NieDzejkob>nckx, efraim: maybe the guix daemon should chattr +C the /tmp/guix-build directory? <civodul>however note that (guix build gnu-build-system) and (guix build python-build-system) both export %standard-phases <civodul>prolly you'd want to #:select (site-packages) from python-build-system <NieDzejkob>oh, I thought I'd use (@ (guix build python-build-system) site-packages), but #:select is indeed a nicer solution <sirgazil>GNOME is not releasing RAM for me. At the end of the day, I see RAM usage is about 3 GiB. Closing all applications reduces that number to about 2 GiB. But if I log out and then log back in, those 2 GiB are still in use. After reboot, GNOME alone uses around 1.5 GiB. <sirgazil>Using sway, RAM usage seems a lot better. <frafra>can I install a different version of a package? <nckx>NieDzejkob: Builds failing on btrfs (or whatever) is annoying but usually a valuable sign of flawed assumptions. While we could improve ‘immediate’ reproducibility by making everyone's build environment slightly more similar, that would negatively affect ‘long-term’ reproducibility by masking such errors. Hence why disorderfs is a thing. <frafra>NieDzejkob, I was looking for Python and playing with Guix, to understand more if/how to use it at work <nckx>And more subjectively: the daemon simply shouldn't (need to) concern itself with packages' arbitrary bugs or demands. Nah. <nckx>Luckily it's irrelevant here: a simple (invoke "chattr" "-R" "+C" ".") solves the problem for vim. <NieDzejkob>frafra: Some packages are packaged at multiple versions, in such a case `guix show pkgname` will show all of them and you can refer to them with `pkgname@1.3` <NieDzejkob>frafra: If you need an older package as a one-off, see guix time-machine, for example guix time-machine --commit=deadbeefgitcommithash1234 environment --ad-hoc foobar@7.3 <civodul>sirgazil: in top, if you sort by memory usage (type "<" to select a column), can you tell which process is eating memory? <frafra>NieDzejkob, thank you very much :) <NieDzejkob>frafra: If you need to specify an older package in a manifest, you'd use inferiors, see info '(guix)Inferiors' for a nice example <mwette>I'm on a foreign distro. When, as user, I issue `guix package -u' I get "The following package will be upgraded:" ... "/gnu/store/7z...-guile-next-3.0.0". BUt I get that message always. I'm guessing that a process owned by guixbuilderN should be running but I don't see it. I believe there is a problem here. How can I trace it down? <leoprikler>Do you have guile-next installed in your user-profile? <nckx>NieDzejkob: Thanks for sifting through old bugs. ***calher is now known as KE0VVT
<civodul>NieDzejkob: sure, i've just replied by mail! <GNUtoo>hi, is it possible to run Guix in an lxc container? <mwette>leoprikler: yes, as reported by `guix package -I' <sirgazil>civodul: I did that before, but using GNOME system monitor, and no process seemed to be using an excessive amount of memory and the sum of the memory used by the running processes didn't seem to amount to 3 GiB. But I'll try again with top. <dftxbs3e>GNUtoo, sure! you can use `guix system disk-image ...` to generate an image and then you can just use that with lxc! <GNUtoo>dftxbs3e: oh ok, I'll try that, thanks <dftxbs3e>guix system takes a system configuration, akin to /etc/config.scm! <GNUtoo>The thing is that there need to be a way to have the right shehperd + parameters <GNUtoo>once there is that, it's easy to spawn something like lxc <janneke>running guix in lxc, epronk wanted to do that <GNUtoo>I've a use case where I've some difficulties finding the right combinaison of things, if it works in lxc it would work for me, right now I'm trying to generate a docker-image <GNUtoo>there is also another option called init in guix system, which looks interesting <dftxbs3e>GNUtoo, I'd suggest looking at code for `guix system container ...` to figure that out. This command can spawn a container directly <dftxbs3e>janneke, I don't know about history around the command :-S <janneke>dftxbs3e: could be it "just works" now <GNUtoo>What I need is just a way to tell libvirt which command to run (like /gnu/store/*/bin/shepherd) and which options to pass it <janneke>GNUtoo: like what's in grub.cfg's --boot= script? <dftxbs3e>It's building Guile now, I think it's done! Hooray! <dftxbs3e>Guile, as in, the real GNU Guix guile package, not any bootstrap one <dftxbs3e>I don't know if any of my changes are merge-able, I'd appreciate feedback on that <janneke>dftxbs3e: have you rebased on core-updates yet? <janneke>i had only one or two small conflicts doing that... <dftxbs3e>oh great. though I'm not sure it would work anymore then <dftxbs3e>I'd prefer bootstrapping on master then iterating onto next GNU Guix versions <janneke>dftxbs3e: what are the commands you have been using? possibly this warrants a mail to guix-devel! *janneke needs to go afk for a bit <dftxbs3e>janneke, `./pre-inst-env guix build hello -K` to test natively on powerpc64-linux-gnu - `./pre-inst-env guix build --target=powerpc64-linux-gnu bootstrap-tarballs -K` on x86_64-linux-gnu to cross compile bootstrap binaries <dftxbs3e>When GNU Hello works, I'll send an email, until then, it could still fail :P <GNUtoo>so it has created a 6zm4f5k898xkhk5hi2vrlh5f7z0wppa8-guix-docker-image.tar.gz <GNUtoo>that contains some infos on how to run it in config.json <GNUtoo>so for now I'll probably be able to run that <GNUtoo>Then the next step would be to understand how, from within the lxc, to update it <GNUtoo>dftxbs3e: I manage to boot it to a shell but now I can't use guix system reconfigure because it complains about the missing block device, so I ended up having that instead: <GNUtoo>(file-systems %base-file-systems) <GNUtoo>In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #f <GNUtoo>it didn't find the uuid of that: <GNUtoo>(cons* (file-system (mount-point "/") (device (uuid "b1ecb69d-4bb6-4bcf-9ab6-6a4d40c227f8" 'ext4)) (type "ext4")) %base-file-systems)) <GNUtoo>so I replaced all that with (file-systems %base-file-systems) <dftxbs3e>I think you can specify device by path instead of uuid <GNUtoo>I've no block device as it runs inside an lxc with a filesystem mapping instead <civodul>GNUtoo: %base-file-systems is good enough if you're making a Docker image <civodul>there's no root file system actually being mounted anyway :-) <GNUtoo>exactly, though I was told to try docker stuff to run in an lxc container <GNUtoo>At the end of the day I guess that I'll end up having to do many many workarounds, but I could try guix init ./thefile.scm ./rootfs too, maybe that has less hops to get it working <civodul>sometimes a plain VM image is just more convenient <dftxbs3e>GNU Hello built on powerpc64-linux-gnu!!! ***ChanServ sets mode: +o nckx
<drakonis>a random idea for build systems, spin up builds for other distributions <drakonis>set up a debian mirror built entirely using an guix infrastructure <drakonis>now, another question i'd like to ask, i cannot build something using multiple build systems, right? <efraim>you can, it just takes more finagling <efraim>most of the examples IIRC are pulling emacs-build-system into others <nckx>drakonis: Yep, you can mix-&-match phases from multiple build systems whichever way you like. <nckx>Or even call them directly. <drakonis>very nice, is it documented or just in code? <drakonis>i have a package that would benefit from that <nckx>That's actually quite common, I'll see if I can find an example. *nckx goes back to looking for C+Python as if nothing spooky happened. <drakonis>and that's not including the build steps for the source port, but that's just C <drakonis>while i still have your attention, check up on why the package sources path points to the store path in disk <NieDzejkob>nckx: what "spooky thing" happened? I don't see anything in my log <drakonis>ie: "/store/m92vxb2klbx1x5g6m0j766fm6rg7slsb-guix-module-union/share/guile/site/3.0/gnu/packages/" <drakonis>NieDzejkob: i found a package that needs node, python and C to build <nckx>drakonis: I'm not finding anything perfect (not sure what to grep for TBH) but gramps mixes python- and glib-or-gtk-build-system in an idiomatic way. <drakonis>so i'd have to use multiple build systems for it <nckx>NieDzejkob: Nothing, I'm just easily spooked by Node is all. Had to resurrect a Ubuntu 18.04 machine from the dead to build a node package for my Guix server this week. That shit's traumatic. Apologies. <drakonis>or maybe a extra channel for handling node builds because the dependency graph is giant <nckx>drakonis: I guess ‘grep 'build-system.*#:prefix' gnu/packages/*scm’ is a good start to find interesting examples. <narispo>Bridging the npm eco system onto GNU Guix would solve one of a nightmare that npm is <nckx>But nobody knows how to do that because of what a nightmare that npm is. <narispo>I'd be much happier installing GNU Guix packages rather than NPM ones that do all kinds of bullshit in the background <narispo>Impure operations in the background :-) <NieDzejkob>nckx: oh, okay. Do you always get an @ next to your name when you get spooked? ;) <nckx>NieDzejkob: Only when the Wallops threaten to murder ChanServ <NieDzejkob>ah, right. Would something bad happen if there were no ops in a channel? <NieDzejkob>or is it just that we might need to swing out the banhammer? <nckx>NieDzejkob: Nothing bad. Super-mild inconveniences like ‘we can't change the topic if the update goes wrong’. <nckx>We've been very fortunate lately. *nckx tiptoes around the thing with the stuff. <drakonis>hmm, an actual good/bad idea is to allow package importing when doing builds <drakonis>as a replacement for other package managers <drakonis>i'm in no position to talk about code quality myself <nckx>‘Importing’… from the network? Yeah, that is not going into Guix until a very ill-timed bus comes along, I think. <drakonis>hmm, yes, like that, its probably a bad idea. <mehlon>it could work if it's from ipfs, maybe..? <drakonis>though the other path would be to parse the lockfiles most of the languages that have sprawling dependency webs normally use <nckx>mehlon: At that point it's content-addressed (good) but can just be a regular fixed-output derivation, i.e. input. No need for build-side hacks. <mehlon>the only thing it's missing is the letters U and I <drakonis>this seems to be what the node build system patch is doing <drakonis>parse lockfiles to get the dependencies to then initiate the build ***cherryh.freenode.net sets mode: +o ChanServ
***ChanServ sets mode: -o nckx
<nckx>nodejs is ‘node’, right? <mehlon>ah, I heard that "nodejs is not bootstrappable" from the secushare site <drakonis>i suppose that a build system has to replicate the way the builds function <drakonis>hmm, still can't wait for user services to come up. <rndd>drakonis: sorry, i'm newbe, what is "user services"? i thought user can write service for shepherd -_- <joshuaBPMan>Hey guix, I'm having a hard time getting my guix machine to use a custom service from my custom channel. <drakonis>there's system services, which are set up on the system configuration and then there'd be user services <drakonis>all the same goodness, but for your user profile. <rndd>drakonis: ooh, that's cool. i dont remember systemd have such option <nckx>systemd fully supports exactly that. ***cherryh.freenode.net sets mode: +o ChanServ
<drakonis>none of that configuration goodness though <drakonis>cool new things, except everyone gets it. <nckx>I have yet to drink that particular Kool-Aid but it looks tasty. <drakonis>but it needs a little bit more meat in its bones <nckx>I didn't know Nix was ahead of us in this (assuming it's not a side-project like home-manager). <roptat>Nix version is different from mine though, I'm doing the hard-core version :) <roptat>They only override files in the home when reconfiguring, but with guix home manager, your home is read-only <roptat>Which brings a lot oh croubles, but is more true to guix's way of doing things <nckx>M-hm. And avoids other much harder-to-debug troubles, I'd expect. <roptat>I did it, I use it, but I wouldn't really recommend it ^^' <nckx>Just a bit too hard-core for me 🙂 <drakonis>its like bringing a gun to a knife fight <roptat>At least you have the nice properties of the transactional and functional package management of guix, so you can roll-back your home instantly for instance <roptat>Your home is just another profile, but it breaks assumptions of some software <roptat>I can't open libreoffice for instance, I have to trick it by setting HOME to a temporary directory <roptat>Same with pulseaudio, which is really not fun when it crashes (and it crashes often, you just don't notice because clients will restart it… except they can't with the home manager) <drakonis>well, soon it'll be time to ditch pulseaudio for the next thing. <drakonis>wonder if it will fail if home is read only. <drakonis>pipewire finally reached 0.3, still waiting for fedora to set it as the default <lapinot>hey folks, i guess the heart of the guix project is some consistent view of what a userland chould be, probably more so than other distribution which are more institutional, right? So in that realm of thoughts, what would be your take on the shell? posix shell was probably the priviledged way to interact with a system because we did shell scripts and traditional init scripts, but in guix these both <drakonis>we just havent gotten to using it for composing packages yet <OriansJ>in guix, if you have guile; you can bootstrap the world <OriansJ>drakonis: speak for yourself *cough bootstrapping cough cough* <lapinot>i think i saw that but i struggled to find any text material on it <OriansJ>lapinot: well it is very minimal right now <drakonis>bootstrapping isnt the same as writing packages using gash utils to replace build utils <drakonis>honestly, i'm not sure if i'm explaining myself correctly <drakonis>there's the "build utils" library that's being used inside build phases <drakonis>then there's directly invoking the functions reimplemented for gash-utils to recreate coreutils in guile <lapinot>interesting... i mean i dream of the day where these main(**args) are gone and instead we would have a more structured way of publishing entrypoints to programs, a structure which would (just like as it is now) be a kind of FFI to the priviledged shell language <drakonis>there's already a function for invoking shell <joshuaBPMan>so I've got a VERY hacky openvpn client that works for me now. Kind of cool. <civodul>lapinot: the REPL is a shell that gives access to more an more functionality in Guix, if that's what you had in mind <dftxbs3e>civodul, is the plan with Gash to allow to create packages with shell script..? <lapinot>dftxbs3e: afaik it's more like library in guile which allows you to do stuff in a guile repl that you would do in a posix shell (correct me if i'm wrong) <lapinot>guile repl or guile script obviously <lapinot>roptat: oh so guix does have a repl? (yeah sorry, i didn't take the red pill yet, i'm procrastinating the harddrive/partition cleanup) <roptat>It's mostly the same as guile repl, but it gives you easy access to guix modules <dftxbs3e>hmm, somehow openssl fails to compile on powerpc64-linux-gnu - /gnu/store/gh8pjfc9pgmdmjxr7k40jmnnzah1yp6q-glibc-2.29/include/gnu/stubs.h:8:11: fatal error: gnu/stubs-32.h: No such file or directory <drakonis>our nix pals are about to write a lisp interpreter to have an installer <lapinot>i'm practically convinced OSes will evolve in that kind of direction (which is mostly programming/controlling the userland in a different language), it could also help microkernels and stuff like qubes, by decoupling stuff (or at least making the couplings more standardized) <lapinot>yeah, with the namespace thing and all you mean? <lapinot>drakonis: how so? (i mean i'm curious, i don't know a lot about linux kernel dev) since microkernel is not really so well defined i'm not sure what to search for <alextee[m]>i wonder why there's so few devs. it looks more organized than linux <lapinot>hmm, so maybe there would be a step where most kernel modules are actually binaries with "ebpf" interface (or at that point more probably a basic in-kernel shell)? <lapinot>(by modules i probably mean subsystems) <lapinot>at which point kernel-shell and userland shell could unite and we get a microkernel \o/ <dftxbs3e>openssl didnt define KERNEL_BITS during configuration, which means it was less likely to work on less common architecture with less developed platform detection