<jab>vivien: at some point I might play with it...I've got too many things that I want to do. I need to just pick one. :) <jab>But thanks for the tip! <vivien>I wanted to do some GUI stuff, but then I remembered my brain is not wired to program any GUI better than a window with a big "hello world" button in the middle. <lilyp>To be fair, Guile-GI needs to laboriously import everything if you actually use a higher-level library like Gtk, it's not even fun. <SeerLite[m]>Hi! I think I found a bug: When using any display manager other than GDM and setting the user shell to zsh, $PATH doesn't have the directories /run/setuid-programs and /run/current-system/profile/sbin inside the session. PATH is correct when logging in from a TTY so I don't think the problem is zsh. Can anyone else reproduce this or is it just me? Thanks :) <lilyp>what's in your zprofile and is it being run? <SeerLite[m]>There's a single `source /etc/profile` line. Just checked that file and I see that that's where the PATH is set with those dirs. Must mean it's not being run inside the session... But I'm not sure why <SeerLite[m]>Yeah I know what it is now. I forgot I had set `$ZDOTDIR` to somewhere else which meant I was sourcing a different .zprofile. I'll update it to source /etc/profile. Thank you lilyp ! <attila_lendvai>is there a way to ignore errors from tests? i'm calling them like this: (apply invoke "make" "test" make-flags) <iskarian>attila_lendvai, what's the point of running them then? <attila_lendvai>iskarian, it's not something i plan to submit. only to inform me while in the process, but don't cancel the entire build... <attila_lendvai>idris Vn may be able to bootstrao idris V(n+1), even though some tests fail <iskarian>ah, I see what you mean. typically, I'd just do `guix build -K' and then cd into /tmp/guix-build-somepackage and test it there, or build with `guix build --without-tests=package' <iskarian>`guix build package --without-tests=package' that is <iskarian>You could use 'guard' to catch the invoke error, and ignore it, I suppose <iskarian>or perhaps 'false-if-exception', though I'm not sure if returning #f will stop a build or not <jab>how does one export a profile in the fish shell? <jab>or is it possible to make bash do a C-r on all input like fish does? ***califax- is now known as califax
<ytc>apteryx: are you using x200? if yes, how is your system's daily performance compared to other distributions? ***tungsten.libera.chat sets mode: +o ChanServ
<theruran>is camlboot in the bootstrap path of OCaml in Guix now? <theruran>actually the `guix graph ocaml` looks really boring. looks like it depends on Perl? <brendyn>Hi. I'm working on updating everything KDE related <brendyn>I started doing every package one commit at a time and realised it takes a loooong time <PurpleSym>brendyn: I’m doing the opposite right now for Haskell, updating the entire worktree and then trying to commit everything package by package. Not fun either. <PurpleSym>Do we have any tooling beyond etc/committer.scm (which does not work)? <brendyn>PurpleSym, oh i did that too for a whole module. That's pretty easy if you use Emacs with magit. <brendyn>And for the commit messages there are yassnippets that help. It's still a lot of button presses though. <brendyn>But I noticed the last time someone updated KDE they did many packages in a single commit. Seems logical because once you update one thing, 30 other things are broken until they are updated anyway. <PurpleSym>brendyn: That would be a big help. I’ve got around 500 updated packages with lots of dependencies. <PurpleSym>Just switched to kakoune, but so far I like it alot more than vim. <brendyn>Rules have intents behind them. The purpose is to have a single "logical" change per commit, and ideally, each commit leaves Guix in a working state. That's not always easy to achive though. <PurpleSym>Hm, so far I’ve only seen one package per commit (for updates). <brendyn>and you do the git stuff via command line? <PurpleSym>brendyn: So far yes. I think there’s a git module though, not sure how powerful it is. <brendyn>I end up playing to much 0AD when I should be coding <civodul>PurpleSym: etc/committer doesn't work? <PurpleSym>civodul: Nope, it batches multiple new packages and unrelated patch deletions into one commit and then throws a stack trace when processing some other patches. <PurpleSym>Sure, I can submit a bug report, but I don’t know how to fix them unfortunately :( <civodul>iskarian fixes a couple of things recently <civodul>i don't write enough package definitions myself to be a good user :-) ***wielaard is now known as mjw
<lilyp>I think etc/committer.scm is the wrong tool for this <lilyp>if you have a bunch of changes you want to commit "at once"/in short sequence magit+snippets it is <lilyp>though it'd be interesting to bake some "one package per hunk" logic into committer <PurpleSym>lilyp: I’ve never used emacs, so magit does not seems like an option. <lilyp>I see you still need to undergo your rite of passage then :) <lilyp>much manual typing and probably ignored by committer.scm <rekado>it used to split up new packages into separate commits, but now it just adds all of them into one commit. <rekado>but it should work fine for mere changes to existing packages. <rekado>(I used it a few weeks ago to upgrade CRAN and Bioconductor packages) <rekado>fine = separate commits for independent packages. <raghavgururajan>sneek, later ask nckx: Does screen rotation button and bluetooth module work out-of-box with linux-libre on your X230T? <sneek>mbakke, civodul says: hi! you mentioned a problem with the bit-field change in base32.scm; is there a bug report about it? <civodul>(also, you have to say "sneek: later tell civodul xyz" :-)) <brendyn>Is there a convenvient tool for checking if an input to a package is probably extraneous? <lilyp>brendyn you could diff the package with that input vs. without it <lilyp>there's probably going to be false positives though, like RUNPATHs et al <civodul>brendyn: you can check "guix gc --references $(guix build pkg) | grep the-dependency" <civodul>if it's supposed to be a run-time dependency, it should be there <ss2>hello, I want to get into writing services. Which service would be easier to read through, and maybe to build upon? <brendyn>ss2, session-environment-service-type is a pretty simple start. it just creates a file /etc/environment <brendyn>ss2, the general pattern seems to be to start with define-record-type* to make a record of the configuration details needed by the user. then you define the service with (service-type ...), creating any helper functions you need on the way <ss2>rsync seems a good starting point. <makx>Is Vagrant Cascadian in here? They posted abnout "dynamic loading of modules from initrd" on the issuetracker (#48266); <makx>on that note, does anyone know how to figure out dependency chains that enable one to minimise the number of modules that need to be put into initrd to get the eMMC to work? I spent a couple of hours yesterday trying to find a more structured way than "try and error" <sneek>I last saw vagrantc in #guix 9 days ago, saying: if you have the ram ... :). <makx>how did that nick not tab complete earlier? <makx>oh, because they're not here right now <attila_lendvai>random note: hrm... package hashes are independent of the git commit metadata. i'm amending stuff by replacing an identical commit that was created by someone else, and the hash remains the same. <brendyn>attila_lendvai, I think the .git dir gets deleted <attila_lendvai>brendyn, most probably, but it's somewhat surprising to me. makes sense in a way, but then it ignores stuff like commit signatures... i guess authentication should happen earlier in a separate step. <jlicht>attila_lendvai: authentication here is/(should?) be done by the package author/reviewer; after that, file contents are 'pinned' by the hashes in the package definition <attila_lendvai>heh, right. it's irrelevant that the signature is missing/changed if i have the *same content* plus a signature locally... :) *attila_lendvai is making good progress with the idris2 full-bootstrap packaging <apteryx>hmm, no rtl8812au .ko on latest linux-libre kernel (rtl8812au-aircrack-ng-kernel-module) <vivien>TIL that when you call (next-method) in a GOOPS method, it may call a method specialized for parameters where no class is a subclass of any of the original arguments <vivien>And that’s the briliant thing to do, because if you always call (next-method) until a top method (where all arguments are <top>), you will not skip any. <vivien>I’m not sure about the <top> thing though <radvendii>(a) how do I tell what git revision I'm on after running `guix pull` and (b) is there an equivalent of "nixos-unstable" that's more up to date? <sneek>radvendii, you have 2 messages! <sneek>radvendii, iskarian says: well, I guess I was wrong, it does work with your package after all; I've seen it fail on e.g. the Azure repos, though. <roptat>kotlin 0.11 series starts getting annoying to package <roptat>it requires a new part of the intellij-sdk that in turn requires some older software, that need rhinojs (a js interpreter in javascript?) <roptat>I tried removing the files that need rhino, but they're really needed <dstolfa>i do not envy your situation right now, but appreciate your work <roptat>I'll have a look at rhino, maybe it's not *that* bad <vivien>I hope it is not the typical typescript project <roptat>mh, it looks like it doesn't have any dependencies other than a jdk, and some others for tests <vivien>It looks like all the JS is for tests ^^ <civodul>please do share on HN or whatever to stir the debate around packaging practices :-) <roptat>bah, it tries to download xbeans, and maybe others during the build... <vivien>civodul, having source code is not only about transparency, auditability and provenance tracking, it’s also about being able to have a modified version <makx>civodul: It doesn't suggest otherwise, but also doesn't press the point ;) <vivien>I see you wrote "they need the ability to customize it experiment with it" in the conclusion, but in the introduction, it seems that the reason to want source code is to see it (the sentence starting with "We want to make sure our users can see the source code that corresponds to the code they run;…"), I would have added a couple of words for a modified versions here. ***ec_ is now known as ec
<makx>"as much as we value transparency and verifiability for scientific work." dangerous comparison sometimes ;) <civodul>but supposedly, these are core values for scientists <vivien>Everyone with a few hundred graphics card can reproduce our results :) <civodul>yeah, reproducing results obtained on HPC is a real issue <civodul>(machine learning worse... another story!) <hjklambda>Hello! when I try to build python it fails with the log having "while setting up the build environment: executing `/gnu/store/...-guile-bootstrap-2.0/bin/guile': Exec format error", I took a look at the file and it had a shebang line pointing to some bash in the store, then I tried to execute this bash and it failed with "cannot execute binary file: Exec format error" <civodul>hjklambda: hi! what command did you type, and on what system? <brendyn>Running into the need to have <filesystem> and thus gcc-9 lately <hjklambda>civodul: 'guix build $pkgs --with-input=pulseaudio=alsa-lib --with-input=ffmpeg=ffmpeg-small --no-substitutes -v2 -M4' with pkgs begin a variable containing the packages I have installed. My system is x86_64 <makx>should guix-daemon automatically detect a local guix publish? <makx>can I somehow tell whether my guix publish is visible? <civodul>hjklambda: what does "file" say for the bash in the shebang? <civodul>$ head -1 $(guix build guile-bootstrap)/bin/guile <civodul>#!/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash <civodul>$ file /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash <civodul>/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.30, stripped <hjklambda>gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.30, stripped <radvendii>attila_lendvai aha! Thank you, I was. Meanwhile I put something in channels.scm so I'm now working off of guix master branch, which indeed fixed the problem I was having <hjklambda>civodul: Oh I know why, I forgot to enable x86 emulation on my kernel! thanks! <civodul>are there x86_64 CPUs that don't natively run i386 code? <attila_lendvai>where can i read/look about what happens when multiple packages install the same file into their bin/ output? e.g. how is the conflict resolved when merging into /home/user/.config/guix/current/bin ? <attila_lendvai>i'm thinking about idris emitting both an bin/idris-1.2.3 and also symlink it to bin/idris <roptat>if two packages provide the same file, guix will chose one version, arbitrarily <rekado>attila_lendvai: see (guix build union), “union-build”. <rekado>by default it uses “warn-about-collisions”, which picks the first of any colliding files. <attila_lendvai>thank you! i was hoping for it being smart about version numbers... :/ <roptat>what alphanumeric sort? if the files have the same name... <radvendii>iskarian thanks for the help btw. It turns out the problems / shortcomings with `guix import go` had been fixed, they just aren't in a stable release yet <acrow>civodul: Nice article, "What's in a package". I hope it is widely read. Note: s/reproducibibility/reproducibility/ <civodul>i hope it reaches non-Guix/Nix folks <dstolfa>civodul: have you posted it on hackernews/lobsters? <acrow>Yes, I do too. I'm trying to think of people I know of that might help facilitate changes that might drive guix adoption and recognition of the need for reproducible software. I'll be forwarding your link provided you are comfortable with that. <civodul>i think what's intesresting here is to get feedback from people who're not "sold to the cause" <radvendii>what are you looking for feedback on? I'm an avid Nix user but not sold on guix (only just started experimenting with it) <dstolfa>civodul: i don't really have any of those accounts -- they are a distraction and i'd rather spend that time with family <civodul>radvendii: if you want just tell us what you think of the post :-) <civodul>it's not so much about Guix than it's about packaging practices in general <radvendii>I think it makes the case well for high-security or high-reliability environments. The kind of applications that would also worry about using ECC memory. I'm not sure it makes the case for everyday users <radvendii>which maybe isn't a bad thing. the arguments that appeal to those two groups tend to be different <rekado>PurpleSym: that “guix gc --repair” bug is pretty annoying. <rekado>even when I run the daemon with “--disable-deduplication” I still cannot get it to repair broken directories. <rekado>I … just “herd stop guix-daemon” and then start the daemon manually. I’m unaware of bug 47115. <jackhill>rekado: ah, yes, so it sounds like you're only running it that way for short periods of time. When I tried to run it that way for longer, it didn't really seem usable because of that issue. <jackhill>civodul: oh the notion of which libraries were included and not, could it be for license complience reasons, and excluding copyleft libraries becasue when they aren't produced reproducably it's hard to provide the scripts that control the compilation and instalation? <jackhill>would be interesting to know if our pytorch package works on the ppc64le port. I'm betting one can't get it pre-build for that archetecture from pypi :) <radvendii>I have a VM running `guix build` that keeps failing with "Killed". I figurd it was an OOM problem, but it still happens even with 8GB of memory assigned <radvendii>is guix just that memory hungry, or is something else going on? <rekado>radvendii: how many CPUs does it use? <rekado>does it still happen when you use “--cores=1”, for example? <radvendii>i don't have a number of cores explicitly specified on the `qemu` command. not sure how many it gives by default <civodul>radvendii: thanks for your feedback; re "making the case for high-security", it's interesting because i don't see it that way: there's security, yes, but to me these are just basic transparency requirements that should sound familiar in a scientific context <radvendii>civodul yeah I think scientific contexts are high-reliability contexts, so this applies. But like, for an average every day person why should they care? <radvendii>Also I think it's a fairly new thing that scientists care about code reproducibility. Lots of papers have been published without even open sourcing the code, no? <radvendii>(i'm no expert on this, i just remember noticing that years ago and being frustrated) <civodul>radvendii: that's true, but there's at last awareness that this is a problem <civodul>your question about "average person" is a good one, though i can't really answer it because i despise that concept <civodul>the idea that there'd be an elite who cares about and deserves feature X <civodul>while the rest of us just "won't care" because they don't know <radvendii>i mean, for the record i'm totally on board with the argument <radvendii>i just know for most people "i can just click click and it installs" is much more important than "i can verify that the code is what it says it is" <vivien>That’s a chance to make them think about source code, which is good :) <jackhill>radvendii, civodul: I know why I care, but maybe that doesn't resonate with everyone: the pypi approach might work now for my particular situation, but it could become a hassle for me in the future for any variety of reasons, and may prevent me from experimenting with future improvements to my computation environment. I value avoiding future pain highly and am willing to put in more work now to avoid it. <civodul>right, that's in part an education problem <radvendii>and i think for someone who doesn't care, this doesn't make the case that htey should <jackhill>Other probably value different things. Also maybe of note, I'm not responsible for bringing in grant money <civodul>radvendii: then that's a problem :-) <vivien>It’s hard to tell what people care about, because they can lie to you <civodul>it's hard to adopt a perspective that's at odds with one's own perspective <civodul>which makes it hard to make the case for "someone who doesn't care", i guess <vivien>Have you noticed how hard it is to talk about freedom outside of the computer to people you barely know? Or maybe it’s just me ^^ <vivien>Maybe they appear not to care, but they still care a bit <dstolfa>radvendii: i think it's just about phrasing. suppose you phrased this as: "guix allows you to give your full system to a developer with the click of a button, ensuring that reporting and solving your bugs is quick and efficient" <dstolfa>it would be a much more interesting feature than talking about reproducability, science, etc to regular users (even though i think it matters more in science) <dstolfa>we would need some tooling for the above to happen, but all it really needs to do is pick up your config and profiles with the bug report and send it off <radvendii>yeah, that's a much better framing i think for developers <dstolfa>radvendii: another thing worth pointing out... at least for me. `guix environment --ad-hoc jupyter ... --container --network` is much more convenient to me than `podman pull && podman create ... && podman start` or worse yet, having to write a dockerfile and so on <radvendii>honestly i think for me the main pull of nix / guix is the statelessness. Whenever I use a stateful system I feel like my brain has to keep track of all the state <radvendii>yeah. it's super relaxing to use nix/guix by comparison <dstolfa>one thing i wish i had in guix was a redhat-style kernel. i would replace every system i have on rhel in a heartbeat <podiki[m]>I definitely feel more relaxed knowing all the important stuff is in a config file, my dotfiles, (and data in home only) <podiki[m]>I dread having to recreate a home server, with the various little tweaks and config files spread out who knows where <radvendii>well, i have increased the VM's memory to my system memory, 16GB, and now I'm getting "Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS" <vivien>... and not knowing what service is still active, and what was paused when I got distracted, and what I could not figure out how to run. <vivien>Declarative configuration for a server is really useful ^^ <radvendii>yeah. at the system-configuration level there's also the advantage of being able to piggy back on other people's work <dstolfa>vivien: so long it's not TOO declarative, as is sometimes the case with ansible :) <radvendii>i wonder if the ease of setting up services can prompt a resurgence of self-hosted / federated software <roptat>mh, there are other distros that target exactly that, but I don't think any is extremely successful (yunohost might be the most successful) <roptat>and there's the limitation that you need to know guile in order to really customize services, whereas yunohost might be more limited in options, but all you have to do it click on a few buttons on a web interface to customize your services <vivien>I must say that we are not in the best spot to target self-hosting, because we don’t have much of the whole NPM situation <civodul>roptat: due to statefulness, yunohost cannot fully deliver on its promise <zimoun>Does Guix have a nextcloud client? <zimoun>roptat: thanks, that’s I was looking for. :-) <zimoun>civodul: hehe! It is too slow!! ;-) <civodul>GSaaSoI: "guix search as a service over IRC" <jackhill>civodul: reguarding the security argument: at least at my institution, the people who work in the IT Security Office are so far afield that I doubt they could even understand the argument about building from source, much less reject it. I was recently asked to install some non-free software to run as root to improve security… I suspect I'll get out of this requirement since they won't be able to produce <jackhill>a version of the software that works with Guix :) <civodul>jackhill: heh, i've also seen things along these lines <civodul>but that's why we need to raise our concerns publicly <civodul>and maybe, eventually, our views will be mainstream :-) <jackhill>yes, when at first I didn't get traction on my concerns, I found it disorienting, but as I thought about it more, I think it is just a bridge in understanding that is yet to be built <vivien>I imagine a world where every discussion about how that program is bloated turns to a discussion about whether its build is reproducible <radvendii>i mean... we can have both discussions. f*ck bloated software <radvendii>Anyone know about this "Too many heap sections" error? It seems to be connected to still just not enough memory <radvendii>but it's got 16GB. I guess I can figure out about setting up swap for the VM <radvendii>i'm trying to compile go stuff. it should be able to do each module individually though <radvendii>is there a way to get guix to not parallelize besides setting `--cores=1`? <jackhill>radvendii: what command are you running, I'm wondering if I can try to reproduce it. Are you testing the go 1.17 and build system fixes that were submitted recently? <radvendii>I ran `guix import go -r github.com/tweag/trustix/packages/trustix` <radvendii>and then am running `guix build -f guix.scm --cores=1` on that file <radvendii>well, i added the package name at the bottom of the file so it actually builds the right thing <jackhill>oh, guix import go. I haven't tried it, let me see… <jackhill>radvendii: still on the import step, do you also get: ‘guix import: warning: Failed to import package "github.com/cncf/udpa/go"’. ? <nckx>raghavgururajan: So… Bluetooth, short answer: mine doesn't work with Linux-Libre. Rotation button, long answer: it doesn't ‘do anything’ out of the box (not even sure how that would work), you need something listening to the button press and do the right thing, depending on what you want the button to do (cycle? toggle?) and how (X? Wayland? etc.). <sneek>nckx, raghavgururajan says: Does screen rotation button and bluetooth module work out-of-box with linux-libre on your X230T? <radvendii>jackhill that's the error i was getting before i switched to master <nckx>To add to the fun it sometimes generates duplicate button press events when you press it, so you need to filter those out. <jackhill>hmm, I'm on master at commit 00e3a3a177b9e0369a7b4b3d179e8d76e2764082 maybe I need to pull <radvendii>yeah i just did a `guix pull` like 20 min ago lol <nckx>But it's usable, as is the actual tablet sensor (= the lid sensor, except it knows if you closed the lid screen-up or -down). <nckx>raghavgururajan: …actually, I'm currently running without the front bezel (don't ask) and have never used this machine with the original O$, so I don't know how it's supposed to behave, I just made it up. There are two buttons that both look like ‘rotate’ to me; the green one works: https://www.tobias.gr/buts.png <nckx>I didn't find a way to get events for the other one, but I didn't try hard; I don't need 2 buttons. *nckx belatedly mutters ‘Good morning Guix’ :-) <civodul>radvendii: could it be that "guix import go" spit something wrong with circular dependencies? <radvendii>ohhh good question civodul. I figured guix would catch a circular dependency like that and warn me. <civodul>yeah, it's been discussed but, you know... :-) <ix>Is it realistic that in the forseeable future guix would support arbitrary service managers, not just shepherd? <ix>Shepherd is cool, but it's a bit half-baked at the moment, and choice is nice <ix>At least it's not systemd so ripping it out doesn't cause internal haemhorraging <ix>Apologies for vapid tautology <rekado>hmm, is there another way to repair corrupt items in the store? <rekado>I guess I could download, unpack, and copy over… <dstolfa>ix: i think the main problem is that someone would have to implement a way to generate unit files, and ironically, it might be less work to just support parallel boot and a couple of other things for shepherd depending on what you need <dstolfa>if you need a full fledged system bus and all that, then it's less work to generate unit files, for sure. <dstolfa>but if it's just a few simple things from systemd, it might be relatively easy to put them into shepherd <dstolfa>for example, we could catch stdout/stderr with shepherd and log it to /var fairly easily i think. <ix>I'd be more interested in s6 <ix>And i think it'd be pretty easy to switch out, codewise, they don't have very different interfaces <dstolfa>ix: i certainly think it'd be cool to support different inits with guix, but don't really have time to work on any of it at the moment. i'd happily look at your patch, though! <ix>Just curious if its in the crosshairs for the devs though, or if the plan is shepherd all the way <ix>If not, I might see how hard it'd be to translationally swap out for my system, and if that works at least i'm a PoC <dstolfa>my understanding is that the main init will remain shepherd, as given time, it's fairly easy to massage it into being much more robust and supporting the commonly requested things. shepherd is *extremely* simple and the codebase is small. but that doesn't mean we couldn't have different backends :) <dstolfa>ultimately i don't think guix cares all that much on what starts the services, so long as you have a way to do it <dstolfa>it would just require some mapping from existing service definitions in guix to say, s6 <ix>Seems eminently doable <ix>dstolfa: my immediate thought is "would this require a new operating-system" or could i do it a neater hacky way? <dstolfa>ix: my initial take would be to just add a field to operating-system and then see as you go along <Guest2565>Should I put it in a new file `gnu/services/jupyter.scm` or add it to `gnu/services/web.scm` <roptat>is it only one service, or do you expect more related services to be created later? <Guest2565>it's in a working state, but it could also use a bit of work. <roptat>I don't think so, web.scm is good <Guest2565>Hopefully I can get a patch series sent within the next two hours. <Noisytoot>guix package: error: integer expected from stream ***dongcarl1 is now known as dongcarl
<nckx>Noisytoot: Is there more? I'm trying to reproduce it here; it's happily downloading subs so far. <nckx>& does it happen for any package or only for the set you happen to have installed? <Noisytoot>It could be something to do with my Guix channel. I'm disabling it and guix pulling *Noisytoot tries doing it on another computer <nckx>If it takes ages to load, let it, it probably means that page is a-comin'. <Noisytoot>it seems to be specific the the package set I have installed <Guest2565>Is there a command to generate a texi template about a service and its configuration structure? <nckx>That's what I feared, Noisytoot. My update is still running (which is fine—one was long overdue, so thanks, I guess :) <nckx>Guest2565: Not quite that, but there's a ‘generate-documentation’ helper used in various (gnu services) that I've never investigated more closely. <nckx>Noisytoot: You may well be doing it already since it's obvious, but if you have the time, could you ‘bisect’ your package set? <ss2>hello, I'm having problems with emacs-guix right now. I just pulled to 6eded1a04186e3118b293486b038c994e05efedf, and now any package listing fails with similar message as such: 14 (eval (#<procedure 7f62b89c4c30 at <unknown port>:21:16 ()>) #<directory (emacs-guix) 7f62b9b63820>) <ss2>I'm just removing packages, but then it complains at the next package. <Guest25>Building guix with my jupyter-service-type. Expect a patch soon... <nckx>Guest25: Cool! And thanks :) <theruran>civodul: will camlboot be used to bootstrap OCaml on Guix? how is it bootstrapped now? I didn't fully understand `guix graph` <roptat>theruran, it is used, but it can only bootstrap ocaml 4.07 at the moment <roptat>so, more recent versions of OCaml are not bootstrapped, they use the bitcode version in the sources <roptat>for 4.07, we use something close to DDC: we build camlboot, use it to build ocaml and reuse that ocaml to build the final version <theruran>I see. as long as that bootstrapped 4.07 is used to build later versions? <roptat>it's not, the plan is rather to port camlboot so it can bootstrap the more recent versions <attila_lendvai>i'm not allowed to use certain modules in packages? i get "no code for module (guix packages)" when i try... i want to use `package-name` in the arguments section <roptat>attila_lendvai, you probably want to unquote before using it <roptat>what's quoted gets copied to the build side, which doesn't have access to most of guix code <roptat>but if it's something that can be computed before copying to the build side, you can unquote <iskarian>sneek, later ask PurpleSym: can you give the diff settings from #50363 a try? They make etc/committer a bit bit better at determining the package a hunk belongs to <attila_lendvai>roptat, oh, right, thanks! it's available at definition-time, too. <roptat>if it's the name of the current package, you can even use ,name unless the field is not defined (yet, or inherited) <iskarian>sneek, later tell PurpleSym: that won't do anything for multiple new packages in one hunk, though <iskarian>attila_lendvai, if you would want an inheriting package to use the new name rather than the name of the defining package, you can use ,(package-name this-package) *attila_lendvai is making notes <attila_lendvai>i still nowhere near as comfortable in macroexpanding and inspecting suff as i am with CL <civodul>rekado: repairing store items with "guix gc --repair" (?) only works when there are substitutes available <civodul>though you can always "guix archive --import" things i think <lilyp>is there already an ETA on core-updates-frozen merge or is it still in fixing stage? <roptat>lilyp, it's still being worked on <iskarian>Last I checked there were an absolute ton of broken rust- packages <iskarian>I don't know if those will be addressed by #50358 <rekado>there definitely is corruption, but “guix gc --repair=verify,contents” did *not* detect the broken items. <rekado>pango and cairo are broken, so few programs can be started <civodul>uh, did you check their hash compared to substitutes? <civodul>q: how do you do comint-history-isearch-backward-regexp at the REPL when paredit is active? <rekado>since I’m a sneaky person I copied these directories from ci.guix.gnu.org; they are definitely different <rekado>I then placed them in the store and ran “guix gc --repair” again — this time it *did* complain about the hash and fixed them. <civodul>did you try "guix archive --import" on them? <rekado>no, haven’t tried “guix archive --import” <civodul>it's unfortunate that this part of the code is insufficiently tested <rekado>now I’m a bit worried that there might be other items that are broken. <rekado>i have a Python package here (qmk) that needs to be built with “python3 -m build”. This method appears to ignore all provided inputs. Any ideas how to fix it? <iskarian>rekado, are you sure you want "-m build"? I believe that builds dist packages <rekado>there is no setup.py and the README says I should use “python3 -m build“ because of PEP517. <rekado>I don’t know much about Python to know my options here. <rekado>(just want to flash the firmware of my little Atreus keyboard) <iskarian>Ah, you don't have to have setup.py to use setuptools anymore; it looks for pyproject.toml as well <rekado>how do I use setuptools to do that? What should I run? <iskarian>I believe the build system should do it for you? <rekado>no, it just says ‘no setup.py found’ <rekado>I have added python-pypa-build to the native-inputs as well as python-setuptools. <iskarian>Ah, sorry rekado, I'm not sure then. I know that I've build python packages with just pyproject.toml and no setup.py in the past <rekado>jackhill: I used the online configurator to generate a JSON file, so I wanted to use qmk tools to convert that to source code. But it looks like I can also download the full source code on the configurator. <jackhill>rekado: oh neat, I wanted to do everything locally out of principle. I agree that having the qmk helper would be a good addition to Guix :) <rekado>yeah, I’d like to do everything locally as well, but I’m the newbiest noob that ever noobed. <jackhill>As would getting the configurator to run, but that probably involves JS. What I really want is to build my firmware as a derivation <rekado>(I just want dvorak with tap/hold modifiers on the home row) <rekado>the librem’s keyboard is just too uncomfortable <iskarian>rekado, can you try "python -m pip install ."? <jackhill>For what it's worth editing the C macros/arrays turned out to be less hard than I feared. Often I get new hardward and don't use it for a while because it takes me forever to get it set up. Yay pragmatism. Anyways I'm veering offtopic and it sounds like iskarian has actaully helpful suggestions. Just wanted to offer moral support for doing keyboard hacking in guix. <iskarian>(you might need to add python-pip as a dependency) <rekado>iskarian: doesn’t work. It still tries to look for dependencies on the network. <rekado>this runs the following failing command: command: /gnu/store/9w9jvy3bgjg4qaqmrij01nbppiccqr7c-python-3.8.2/bin/python3 /gnu/store/9w9jvy3bgjg4qaqmrij01nbppiccqr7c-python-3.8.2/lib/python3.8/site-packages/pip install --ignore-installed --no-user --prefix /tmp/guix-build-python-qmk-1.0.0.drv-0/pip-build-env-2uopol5c/overlay --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- 'setu <iskarian>Hmm, it shouldn't look for dependencies on the network if they're all present. <iskarian>It *looks* like `guix import pypi -r qmk' got all the dependencies <rekado>the import output requires quite a bit of work to make the packages all compile 
