<nckx>(Reading the mentioned ‘ECMAScript’ part in the Guile manual, I think it's quite obvious the author is talking about themselves. Maybe I'm missing some self-deprecating humour on Caleb's part but it's sad if the project left them so demotivated that they actually feared ending up a pariah.) <ix>dstolfa: take that up with just about everyone ive ever argued with <danderson>I dunno, I suppose I have a different threshold for that. It's emotional for sure, but not unreasonably so. And given the content being conveyed, it seems like a legitimate place to talk about the non-technical problems <dstolfa>ix: i think it's just a case of text-based communication being an less-than-great medium for some things <nckx>ix: Have you sobered up yet. <danderson>anyway. Thanks for the background all. Very useful context. <ix>In fact im probably more drunk than earlier, but at least a lot less generalized anger <nckx>Yes. Focus the rage beam. Preferably onto something written in C++. <drakonis>do notice that email refers to the 2017 implementation, i think you should look for the 2020 code <drakonis>this weekend i'm going to write an arcan service, for some of that sweet sweet cool software moolah <drakonis>cbaines: what are the implications of using bordeaux? <drakonis>does it mean that mirrors for serving packages can be added? <nckx>drakonis: What do you mean? <drakonis>adding the ability to have multiple substitute servers for performance <nckx>That's always been the case but yes. <nckx>It's a trade-off, since you increase the query overhead by asking each server in turn, but they are tested in order so if you put ci.guix first (or whichever is fastest to build) it's not too bad. <nckx>bordeaux is just the new name for bayfront, not a new server. <nckx>Some new scheduling software (the Guix Build Coordinator) but the same good(?) old KGPE D16 box. <nckx>You're not trusting new hardware. <ixmpp>eu.siacs.conversations.message_deleted <vslg_>Hi, this might be a stupid question, but I'm new to Guix and I'm trying to do a bit of packaging. Every time I run ./pre-inst-env guix [...], it rebuilds Guix from scratch, there are a lot of notes saying that the source file is newer than the compiled one (in the store). Is this normal? Every time I want to test a change in my package, it rebuilds everything an it takes time. <vslg_>Should I mention that I'm running Guix package manager from other distro different than Guix. <nckx>vslg_: First run ‘guix environment guix -- ./pre-inst-env make -j$(nproc)‘ to recompile all those modified files. <nckx>From then on it will only print that warning (and incur a slight delay) for the file(s) you're actually working on. <nckx>When editing different files, repeat as needed. <vslg_>Thank you very much, I'll try it. <bauermann>mbakke, FYI: I'm halfway through (I hope!) creating a patch which updates TeX Live to version 2021.1. I have a hunch that it will fix the current irreproducibility of texlive packages (bug 48064) <bauermann>though that may be just unwarranted blind hope... <danderson>hmm, does a default guix install not allow pubkey login to root@? <danderson>so, I was reading the blog post about speeding up substitution downloads... Is that in guix 1.3.x? <danderson>I ask because one of the cases it covered (FTTH downloads) still seems terribly slow for me. I can barely hit 2MiB/s in steady state :( <danderson>compounded by the download seemingly being serial and 1-at-a-time, so almost all the reconfig time ends up being trying to retrieve these files <drakonis>you can make it parallel by increasing the number of jobs <drakonis>once the daemon is in guile, first thing is to let people decide how many things they want to download at a time <flatwhatson>> successfully built /gnu/store/qnk2wpghlf4fa85pzssbbxyw7ija7kgx-gtk-4.2.1.drv <danderson>hrm. Ran reconfigure again immediately after doing it once, without altering the system config, and... it's rebuilding and regrafting a bunch of stuff? Confused. <danderson>no. In this VM, I did a `guix system reconfigure /etc/config.scm`, which took a while pulling a bunch of substitutes, but eventually finished. Then I ran the exact same thing again, and now it's building guix-1.3.0rc2 from source? <danderson>mostly I'm confused as to why the second `guix system reconfigure` wasn't a no-op. It seems to be doing more stuff that it didn't do the first time round. ***sneek_ is now known as sneek
<danderson>naively, I expected the second reconfigure to take a while to evaluate the config, then go "ope, all built already, I'm done" <danderson>instead it's building guix from source, which is taking _longer_ than the first run. <drakonis>hmm, is config.scm the one you wrote yourself? <danderson>it's the config.scm from the guix installer, with one change to the sshd config to allow pubkey logins by root <danderson>I mean, running guix pull now, but I'd like to understand what happened. Right now my mental model of what guix was doing is clearly not quite right <danderson>okay, so, coming from nixos, I'm thinking of `guix system reconfigure` as like `nixos-rebuild`. So, I ran it once, it computed and applied a new config to the system. <danderson>The second time I run a nixos-rebuild with an unchanged config, it's effectively instant. It just reruns the activation script and you're done. <danderson>But `guix system reconfigure` seems to have decided, on the _second_ run of the exact same config, that it needed to do a bunch of new work. <danderson>so... why? Why didn't it eval the config, conclude "this is unchanged" and do basically nothing? Or just the guix equivalent of the nixos activation script? <danderson>am I making sense? I applied a declarative config once, then applied the same one a second time, and afaict the second run "discovered" a bunch of new work it had to do <danderson>which doesn't make sense to me, so I must be missing a subtlety of guix <danderson>okay, after `guix pull`, my $PATH is still pointing to the system version, and `guix system reconfigure` still rebuilds guix from source <danderson>so... I guess `guix pull` doesn't actually alter the system config at all, so my problem remains the same <danderson>right, but why isn't my profile wired into my $PATH? I'm running on GuixSD, surely the shell comes preconfigured to do that... <danderson>hmkay, so, turns out I was running on a `su` root shell. Maybe the root user isn't wired up this way... <danderson>sure, and guix pull updated that profile, but it's not wired into the shell $PATH <drakonis>the root user itself has the proper shell configurations btw <drakonis>and reconfiguring evals but does not waste any more time downloading <danderson>when I `su`, my path is /run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin <danderson>so that explains the pothole I hit, `guix pull` is effectively a no-op in a su shell <drakonis>/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin <danderson>but okay, without a su shell, as a regular user, guix pull does the right thing <danderson>(all quite slow compared to nix still, that worries me a bit for ongoing use... But, pressing on) <drakonis>basically, if you do a guix pull as root, it'll update its copy of the channels it uses <drakonis>if you have any configs that depend on channels not in here will lead to rebuilds <drakonis>actually, that one didnt make a lot of sense <danderson>I don't get it. `guix pull` updated channels and the guix binary in the root profile, the problem is the guix binary in the root profile isn't the one that gets used <danderson>unlike on a non-root account, where the profile is wired up correctly <drakonis>one moment, i'm going to do some rebuilding with my root user profile <The_tubular>I'm having trouble at starting the distro, I get an error message 1 <drakonis>its about the same annoying behavior as in the install images where you cannot do a pull as a root user <danderson>right. So... why? AFAICT this boils down to "root isn't correctly set up to run guix on guixSD". I assume that's for some really good reason I don't understand yet. <drakonis>but use your own user to do these things <drakonis>i think it has to do with a missing provenance file? <danderson>I need to read up about provenance, because guix is complaining on every command that it can't establish provenance for the system. <drakonis>hmm maybe the docs have an answer to that <danderson>which is... a bit weird given that I installed it from an official guix ISO <danderson>I'd expect it to have the provenance figured out <drakonis>i think the problems are similar to the ones you'd find on nixos though <drakonis>rebuilding as a root user is discouraged afaik? <danderson>I have no idea if it's encouraged or not, but it's never not worked for me :) <drakonis>its because there was a time people still used nix-env <danderson>okay, well, now that I'm running via sudo, `guix system reconfigure` seems to behave like nixos-rebuild. Still a bit slower, but not "it'll take 30 minutes" any more, I can live with that <danderson>okay, next problem - term-auto fails to start, whatever that is. <drakonis>hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/root/.config/guix/current/bin/guix'. <danderson>Time to learn how to debug a shepherd service... <danderson>yes, because guix doesn't set up root's profile in $PATH for whatever reason <danderson>sure. I'm documenting the potholes I'm encountering as a new user :) <danderson>`hash guix` also doesn't work as a regular user, fwiw <danderson>oh, wait, no, I misread the instructons. I expected it to tell me what the path is, so I could check it against the expected one. <drakonis>but the command isnt needed on guix system <danderson>but it just silently updates the cached path. <drakonis>its a hint for when people run it as a package manager <danderson>sure. And it's a useful hint in that it's trying to tell me how to fix root's shell config. <danderson>I'm confused because I expected guixSD to get thatright for me out of the box. <drakonis>to be fair, i dont complain about that because i never actually use root to do anything <danderson>... okay, shepherd's manual is next to useless for debugging a failing service. Is theresome guide somewhere to root-cause why a service won't start? <drakonis>it is definitely an issue with the install though <danderson>`sudo herd restart term-auto` just states "Service term-auto could not be started." <danderson>... okay, _why_ ? Where do I get more details than "no" ? <danderson>herd status is also useless. "It is stopped." <danderson>yes, I know it is stopped, because you failed to start it. _why_? <danderson>I presume, somewhere, there is a log that tells me more than "lol, no", but I can't find it. On a systemd distro that'd be journalctl, and the status output would helpfully show me exerpts from it. So far I'm not finding anything like that for shepherd. <danderson>Nothing in /var/log, obviously no journald... <danderson>note I'm only even caring about this because `guix system reconfigure` told me that it failed to start some stuff and I should do it myself. <drakonis>but this service doesnt have any impact as far as i'm concerned <danderson>Sure. Pretend it does though. As a system operator, I want to know how to fix failing systems. <danderson>So far, all the logs I can find just say the same useless thing as herd status "no, you can't have that service" <dstolfa>danderson: most services will do stuff via syslog, so they well end up in /var/log somewhere <danderson>dstolfa: that's what I guessed, but all I can find in there is shepherd repeating the same unhelpful line about not being able to start this service :( <dstolfa>danderson: that's probably because it probably doesn't log anything unfortunately :/ <drakonis>i dont think term-auto ever restarts for me <dstolfa>FWIW term-auto is stopped for me too <drakonis>it depends on udev and the scheme file generated has launch parameters for some pretty boring terminal stuff <dstolfa>WSL2 is just using hyperv to virtualize a linux kernel <dstolfa>i assume the issue is with /gnu/store? <danderson>okay, guess I need to find the bugtracker then. Either this service is useless and should be removed, or it shouldn't generate a complaint every time you reconfigure guixsd. <drakonis>i think you need to not overthink the whole thing and just play around with it <The_tubular>But this does not work : C:\Users\Giuliano\Documents\WSL\guix>wsl -d guix --exec /busybox sh <danderson>drakonis: dude, I'm an SRE. When the system gives me noises about being broken, I care. <dstolfa>danderson: might be worth checking how the service is specified <danderson>"oh those are just normal errors, ignore them" is not very encouraging :/ <danderson>hm. Well, I didn't specify it, so I guess it's time to track down where that definition comes from. <danderson>(separately, I started this whole thing because I wanted to reconfigure sshd to permit root pubkey login, and even with the new config applied it won't let me, so...) <dstolfa>The_tubular: not really, sorry :/. i don't use windows personally <dstolfa>The_tubular: it *should* work though, but it obviously has issues and i don't really have a way to troubleshoot since i don't have windows here to test on <dstolfa>in any case, mailing lists are you friend in this case i think <drakonis>i'm not sure what even provides term-auto <danderson>I mean, it helps in the sense that it tells me these errors have been ignored by everyone for the last 3 years. Can't say that reassures me much, but I'll let it go I guess. <danderson>ah, and despite guix system reconfigure's noises about restarting services, it hadn't restarted sshd, which is why my config change wasn't visible. <danderson>I am exploring the system. I'm attempting to do the things the manual tells me, and finding problems. You telling me that I'm exploring wrong when I'm trying to do that the manual says isn't helping :( <drakonis>hmm, i dont know if i can help you properly <danderson>But usure, now that I've given up on this particular weirdness, I'll keep exploring. <dstolfa>danderson: might be worth documenting the weirdnesses you've encountered and shooting an email off to the mailing list that describes them <dstolfa>all of these things you're hitting are worth fixing <danderson>sorry if I sound frustrated, it's because I am. Maybe it's time for me to walk away, honestly. <vldn>The_tubular hey i'm running guix on wsl :) <vldn>i made a gist because the github doc you mentioned was way too complicated <vldn>i comment with my gist on the bottom <vldn>i hope it helps with your problem <vldn>it is not really built for other people running it in a whole, maybe try it command by command for your needs or modify the script and then run it :) <The_tubular>Yeah, I'll read a bit on what it is doing and what I was doing wrong <vldn>i also used a prebuilt busybox and started from there (like the first command) <The_tubular>Does that mean that busybox won't be tracked by guix? <vldn>download it from the release page <vldn>go to your cmd.exe shell and run : <vldn>wsl --import guix /guix rootfs.tgz --version 2 <vldn>wsl -d guix /bin/busybox sh <vldn>then you got your busybox shell and can run alle the commands in my gist <The_tubular>Gotcha ^^' It's my first time running guix so the second part that is confusing me is all the guile stuff :P <The_tubular>Like why do you define a file system if Windows already makes it for you ? <vldn>the guile part is the guix system configuration <vldn>wsl is creating a virtual filesystem for the wsl parts <vldn>and there guix system needs to know where the root file system "/" lives <vldn>try to run "df -a" in the busybox shell and you'll see something like this <vldn>tools 96.3G 56.1G 40.2G 58% /init <vldn>none 3.0G 0 3.0G 0% /dev <vldn>tmpfs 3.0G 0 3.0G 0% /sys/fs/cgroup <vldn>none 3.0G 1.0M 3.0G 0% /run <vldn>none 3.0G 0 3.0G 0% /run/lock <vldn>none 3.0G 0 3.0G 0% /run/shm <vldn>none 3.0G 0 3.0G 0% /run/user <vldn>tmpfs 3.0G 0 3.0G 0% /mnt/wsl <vldn>C:\ 96.3G 56.1G 40.2G 58% /mnt/c <vldn>G:\ 812.5G 647.5G 165.0G 80% /mnt/g <The_tubular>Gotcha, I'll have fun hacking on it for a few hours, try to understand basic guile, I'll hit you up later if I have some more question :) <The_tubular>Anyway, it's just a small, VM. I can just blow it and start another one if I do something stupid <vldn>you are not supposed to run the guile part, it is piped to the guix system reconfigure command (the last in the guix-infect.sh) <vldn>a bit much to begin with but you'll have fun :) <vldn>just comment the gist if you got questions and I'm not online <The_tubular>Yeah, I understand what guile is. Watched a few talks of guix. I just doubt I'm able to write a package definition as of now :P ***ec_ is now known as ec
<apteryx>ecbrown: i'm about to push the new qt 6.1.1 package as a base to your patch series <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, yoctocell says: have you seen https://issues.guix.gnu.org/issue/48934 ? Sometime ago you mentioned that the generated docs for service configurations had a different style compared to the hand-written ones. This should fix that. <apteryx>sneek: yoctocell thank you! I've been meaning to try it/comment on it, but haven't gotten around it yet. <apteryx>sneek: later tell yoctocell thank you! I've been meaning to try it/comment on it, but haven't gotten around it yet. <The_tubular>Is there somewhere I can see what exactly is include in %base-package ? <flatwhatson>The_tubular: guix repl > (use-modules (gnu system)) > %base-packages <sneek>mothacehe, you have 1 message! <sneek>mothacehe, civodul says: looks like Cuirass can't build, say, 'version-1.2.0', due to assumptions about the (gnu ci) module i think; thoughts? <mothacehe>mmmh right, I should maybe backport some changes to this branch. <solene>efraim: hello, I don't understand what you changed in my gnumeric patch <solene>I'm trying to send patches with no issue, improving each time I get feedback what I don't understand here <efraim>solene: the from line appeared like this: From: Solene Rapenne via Guix-patches via <guix-patches@gnu.org> <efraim>To be honest I have no idea why it does that sometimes <Horizon-1207>Greetings. I have an amd ryzen 7 radeon vega & gpu picasso hardware, will the 1.3 release or the latest Guix work if I install? Thank you <apapsch>Horizon-1207: your best bet is if the installer boots, the installed system will boot as well <Horizon-1207>apasch: I was curious because sometimes the libre kernel doesn't (didn't) support some AMD graphics cards <Horizon-1207>apapsch: I was curious because sometimes the libre kernel doesn't (didn't) support some AMD graphics cards <apapsch>Horizon-1207: I remember a conversation here a few days ago that revolved around amdgpu driver not having the firmware for a card. You should see a message via dmesg. If you are affected, you are out of luck in a pure libre system <Horizon-1207>apapsch: I was thinking of trying trisquel as that pure libre and if tht works guix should work, assuming same kernel? <roelj>When running 'guix gc --verify=contents,repair' I get 'guix gc: error: executing SQLite statement: FOREIGN KEY constraint failed'. Any ideas? <nckx>itd: I always care! Thanks, I'll apply it right away. <nckx>roelj: Eh, sounds like DB corruption… I'd try an ‘sqlite3 /var/guix/db/db.sqlite’ ‘pragma integrity_check;’ before you try anything else. ***pinoaffe1 is now known as pinoaffe
<apapsch>Horizon-1207: I wouldn't bet on it, the versions and configuration may differ much <Horizon-1207>apapsch: its more to do with the kernel, as 5.4 added support for amdgpu (i think), but not sure if it's libre? <nckx>Knowing AMD (and GPUs), probably not. <Horizon-1207>nckx: it seems the drivers are open but a binary blob is needed to use it! <nckx>AMD have successfully misled most free software users into calling their tiny GPL-compatible loader for proprietary binary blobs a ‘driver’. It's sad. <jonsger>i don't think their "tiny GPL-compatible loader" is really tiny <civodul>one of them is that i enabled substitutes and Cuirass seems to think that stuff that was substituted did not "succeed" <mothacehe>civodul: hey! interesting indeed, you enabled remote building right? Could you provide me the cuirass-remote-server.log file? <mothacehe>ok the issue seems to be on the remote-server side <thorwil>not entirely sure just setting prefix is the thing to, but that’s what i started with. only: error: Failed to import waf (cannot import name 'Context' from 'waflib' (unknown location)) <thorwil>command "python" "waf" "configure" "--prefix=/gnu/store/ni14smiskgqljqsqpmqgyn6jfii35zbf-mda-lv2-1.2.6" "--prefix=/gnu/store/ni14smiskgqljqsqpmqgyn6jfii35zbf-mda-lv2-1.2.6" failed with status 1 <civodul>waf is a bit special because it's entirely bundled <mothacehe>civodul: ok so the remote-server is trying to fetch substitutes from the workers but it hangs (113 items in the fetch queue) <civodul>mothacehe: so from localhost, right? <mothacehe>from the machine running the cuirass-remote-server yes <civodul>yeah it systematically hangs after 6.09KB <mothacehe>that's related to the keep-alive mechanism introduction <mothacehe>the workers are probably running an older daemon <civodul>but here's i'm talking to a 'guix publish' instance of the workers, right? <civodul>so the worker's guix-daemon version shouldn't matter, should it? <civodul>but here wget is opening a single connection, so no keep-alive? <civodul>ah well, "wget --debug" shows it's passing "Connection: Keep-Alive" <thorwil>civodul: yes, (build-system waf-build-system) <mothacehe>yes if you pass something like -H "Connection: close" it should work <mothacehe>so you may need to update the guix-daemon on the machine running the remote-server so that the "guix substitute" script is updated with 0b8fa24b <civodul>yeah the head node is currently running guix-1.3.0-2.9f2b2c4 <civodul>now it's running guix-1.3.0-3.50dfbbf <civodul>but wait, the problem is on the worker's 'guix publish', no? <mothacehe>if the worker's guix-publish is now respecting the keep-alive mechanism, and doesn't hang-up at the end of every NAR transfer, then on the remote-server side must be updated <mothacehe>*the "guix substitute" script must be updated <mothacehe>it won't hang for /nar/gzip as the content-length is passed properly <mothacehe>for raw nars, wget cannot know when the transfer is over <mothacehe>guix substitute knows the length because its asks the narinfo beforehand put I wasn't aware of "guix archive -t" <thorwil>apparently there should be a waflib, but the tarball for mda.lv2 comes with an empty "waflib" folder. bbl. <civodul>mothacehe: "guix archive -t" parses the raw nar, but the nar itself doesn't have a clear end marker <civodul>in HTTP terms though, there should be "something" happening when the response is complete no? <mothacehe>when the server is able to send the content-length everything works fine, as Guile http-get will do the right thing. When it's not the case, as there's no nar end marker, the client cannot know when the transfer is complete <mothacehe>and the server must not hang-up to respect the keep-alive <apapsch>on boot there are some messages printed on the console by services which is then removed by the login prompt. is it possible to retrieve or persist the messages? <itd>nckx: Sorry, didn't mean to offend. Thanks for your quick response! (Yay, now `guix import json` works for me.) :) <cbaines>civodul, I haven't looked much at the guix publish code, but the Guix Build Coordinator uses chunked transfer encoding with HTTP for transfering nars when the size is unknown <cbaines>that way you send chunks with the size, then an empty chunk to signal the end <mbakke>bauermann: that is great news, thanks! fingers crossed :-) <civodul>cbaines: ah yes, makes sense; 'guix publish' does no such thing, which i guess is a problem we didn't notice until now because the connection would be closed upon completion <civodul>so maybe keep-alive should have no effect on /nar URLs when --cache is not in effect <civodul>that said, "guix archive -t" & co. should see the end of nar, weird <mothacehe>but that's complex, if the only goal is to have wget on /nar working <mothacehe>when wget --no-http-keep-alive does the trick <irfus>how do I use a module provided by some channel for a package definition in a different local channel? <sneek>Welcome back abcdw, you have 2 messages! <sneek>abcdw, ixmpp says: im happy with yoctocell's patch, merge as you please. Would reply but sr.ht's anti-html thing is a shitfest im not gonna play part of <civodul>mothacehe: yes, and chunked encoding prevents sendfile(2) <abcdw>ixmpp: Some of that I use for reference, I didn't complete the migration of all necessary stuff for me to rde. <mothacehe>civodul: I think the problem is that guix-publish doesn't keep up when multiple workers are requesting substitutes at the same time, without keep-alive. The worker connection requests cannot be honored in less thn 5 seconds (connection timeout), causing this: https://issues.guix.gnu.org/48468. <abcdw>civodul, leoprikler, roptat: I would like to get a commit access to work on Guix Home migration from rde repo to guix-home branch of guix repository. Can you vouch for me, please? <mothacehe>Since the keep-alive fix deployment I haven't seen this error <mothacehe>but there are still some "server is somewhat slow" substitute warning denoting that guix-publish is a bit under water <leoprikler>Do I qualify for vouching? I don't recall having reviewed any of your work on the ML. <leoprikler>(Or maybe I'm bad in mapping IRC nicks to mail addresses.) <abcdw>leoprikler: I don't have too much work on guix ML, but we had few discussions on emacs build system. I'm Andrew Tropin BTW) <civodul>abcdw: i'll sure do! could you email guix-maintainers once you have three people? <civodul>mothacehe: thing is, 'guix publish' is single-threaded... <civodul>so either we "do it right" and fiberize it <civodul>or, at least as a short-term fix, we add a tiny bit of nginx caching <leoprikler>This is my first time vouching for someone. Are there any formal requirements or is "I'm vouching for Andrew" enough? <mothacehe>civodul: oh nginx caching is the reason we don't have much "somewhat slow" warnings when using the publish server at ci.guix.gnu.org? <civodul>leoprikler: no formal requirement, but it implies that you trust abcdw to "follow the rules"; ideally you'd mentor them when they get started <civodul>perhaps a discussion to be had beforehand together <mothacehe>the fiberized web server that cuirass-web uses seems to perform nicely, maybe we could also use it for guix-publish <civodul>mothacehe: there's nginx but no caching at ci.guix.gnu.org (i removed it a while back) <civodul>i liked the idea of a simple/simplistic 'guix publish', but maybe that's no longer an option <civodul>we should understand exactly where those "somewhat slow" diagnostics come from, though <mothacehe>perf on the cuirass publish server should help us <civodul>workers talk to the main 'guix publish', no? <mothacehe>that the remote-server uses to fetch build results <civodul>ah ok, so contention on Cuirass's publish should not affect ci.guix.gnu.org:443 <civodul>we do see "somewhat slow" messages on ci.guix.gnu.org, though <civodul>so something must be wrong somewhere <mothacehe>yes, but there are way more present on Cuirass <civodul>is the "somewhat slow" diagnostic even correct? <abcdw>civodul: Sure, will drop a message!) Do 3 maintainers should send their vouch messages separately before I describe my intents or they can just reply to my thread? <civodul>abcdw: typically vouchers email guix-maintainers individually, and you can also email guix-maintainers (or guix-devel) individually describing your goals <abcdw>civodul: Good. Will send a brief plan, once I get 2 more responses) <irfus>ah, nvm, got it. I need to add a channel dependency. <civodul>abcdw: alright! do take a look at the "Commit Access" section of the manual, too <jonsger>abcdw: whats your name/mail address? <abcdw>jonsger: Andrew Tropin andrew [-at-] trop.in <jonsger>abcdw: ah, you are involved in this guix-home thing :) <leoprikler>emacs-next-pgtk is a package in Guix, what's the difference to flatwhatson's package? <abcdw>civodul: Read this section a few times already) Only thing is that I use SHA-256, not SHA-512, but I think it's ok) <muradm>flatwatson: are you merging gcc and pgtk your self? <abcdw>flatwhatson: There are xwidgets in emacs-next-pgtk BTW. <abcdw>muradm: gcc in master, pgtk merges changes from master from time to time. <ixmpp>So why is gcc not in emacs-next-pgtk? <muradm>it is not by default enabled afaik <flatwhatson>none of the guix packages have native-comp enabled in the build <flatwhatson>i think it got a bit mired in discussions of package options? <abcdw>ixmpp: Because gcc was not at master, when I wrote emacs-next-pgtk package definition. <muradm>now it is, may be it is time for next? <ixmpp>Im surprised people dont pester flat to upstream those <abcdw>muradm: There are some new bugs in latest pgtk commits, so I'm not sure that it's a good idea to update emacs-next-pgtk right now, especially with new build flags. <flatwhatson>guix makes it pretty easy to use a channel, so i guess it's not that annoying <muradm>abcdw: is there any sw without bugs? :) as name suggests it is "next" :) <muradm>btw, flatwatson's is with libgccjit-10, guix still has 9 in packages <flatwhatson>i would consider going to gcc-11, but i didn't want to punish everyone with bootstrapping a new libgccjit <abcdw>muradm: Few of them is hitting me right now on emacs-next-pgtk-latest and emacs-next-pgtk doesn't have them) Anyway, I think it will be updated one way or another in some near future. <flatwhatson>actually the libgccjit build could also do with some trimming, i don't think a fully-bootstrapped gcc is necessary, there are other things to turn off for a "gccjit-only" build <muradm>abcdw: dodging bugs is part of business here) <civodul>mothacehe: by second issue is those -1.2.0 jobsets, which don't work, but we can discuss it later <mothacehe>I backported some stuff to gnu/ci.scm in version-1.2.0 branch <mothacehe>it doesn't fix guix-hpc-1.2.0 and guix-past-1.2.0 <civodul>IWBM™ to rely on as little code as possible from the target Guix <mothacehe>true, you can still rely on some manifests for those specifications <civodul>actually my colleagues want a mixture of channels + manifests <civodul>so essentially a sophisticated manifest, i guess <mothacehe>which is an awful hack to build whatever you want <civodul>ok, but i think manifests are already custom enough <civodul>where's the manifest file looked up? <civodul>fun fact: i turned my previous head node into a build node, and with unattended upgrade it reconfigured itself back as a head node during the week end :-) <efraim>I tried setting JULIA_NUM_THREADS to parallel-job-count and it slowed down the build :/ ***link2xt[nm] is now known as link2xt
<civodul>you can add "write a blog post" there ;-) <civodul>would be good to popularize the concept and tool once it's merged <dstolfa>i don't think that will be very hard civodul <dstolfa>a lot of us are already waiting for it <apteryx_>hello Guix! Quick check; supposed I was to build some package (e.g. qtbase) using a custom toolchain made of our current GCC (7.5) and an old glibc (we have 2.28), I should be able to link against it on any GNU/Linux system that has a glibc >= 2.28, correct? <abcdw>civodul: Sure, will add a Finalization section to the document!) <civodul>apteryx_: hi! maybe you don't even need an old glibc; what matters most is the minimum kernel version required by glibc <civodul>unless you want to build a custom pack stripped of Guix's own libc <apapsch>is there a way to to get details about "invalid G-expression input"? I have a hard time figuring out what is invalid <civodul>apapsch: usually it means you're "inserting" something in the gexp that cannot be "lowered" to a file in the store <civodul>for example, if you do #$(begin foo bar #$(current-module)), you'll get that error <civodul>because (current-module) returns a <module> record that cannot be lowered to a file <apapsch>ah, I see it now, a procedure that wasn't invoked but passed as value, thanks <apteryx_>apapsch: emacs + paredit changed my life <apapsch>apteryx_: I have the Perfect Setup set up, though without the fu it ain't enough. It's an immaterial thing not obtainable via guix install ;-) <apteryx_>civodul: the idea would be to build the target application (e.g., jami-qt) with Guix's Qt but otherwise using the system's native libraries (e.g. Debian 10's own libraries but with Guix's Qt). Since the linking would be made by Debian 10's glibc, the glibc used to build Guix's qt would need to be older on equal than the glibc of Debian, no? <apteryx_>apapsch: OK! Nice. It's all about practice then, which is the fun part :-). <apteryx_>err, the linking would be made by Debian's linker, rather. Which would link using the Debian's glibc symbols, IIUC. <civodul>apteryx_: you should check with dongcarl who did something like that for Bitcoin Core, IIRC <civodul>that requires some surgery though, such as changing the loader's file name and stripping RUNPATH <civodul>we could make that an option for 'guix pack' <civodul>(though i won't handle bug reports :-)) <apteryx_>hehe, OK, I will look into that and perhaps ping dongcarl, thank you <apteryx_>or go directly to the .deb guix pack generator :-) <apteryx_>I started looking into that and it doesn't seem too difficult to achieve <civodul>yeah, i guess we could run code in a Debian VM, and possibly use checkinstall <apteryx_>the .deb format is very simple; we just need to provide three files; two which are metadata and one which is the file system tarball <iskarian>when sending a patchset, is it still recommended to use `--in-reply-to=... --no-thread` when sending to NNN@debbugs.gnu.org (in reply to the cover letter)? <apteryx_>I think the difficulty would be in the details, such as when wanting to install different Guix-generated .deb files that would own the same set of /gnu/store files, they'd likely conflict together. <civodul>i was thinking about .deb files containing an FHS layout <apteryx_>OK, yeah that's for the to be written --fhs option ;-) <apteryx_>hmm, why isn't (specification->package "gcc@7") valid? It says: gcc: package not found for version 7. <apteryx_>we do have a "gcc" named package at version 7.5.0. <civodul>apteryx_: it would have been good to keep (define qtbase qtbase-5) <apteryx_>that means we have a couple broken examples in the doc, e.g.: guix edit gcc@4.8 <civodul>apteryx_: there's a "gcc" alias for "gcc-toolchain" <civodul>the goal being so "guix install gcc" is effectively "guix install gcc-toolchain" <apteryx_>yeah, I did it that way based on previous feedback from Mark w.r.t. to inkscape. They were surprised that inkscape in their manifest would not resolve to the latest and greatest. <apteryx_>it does come at the cost of more code changes (though automated) and more disruption for channels. <civodul>yes, i think the change is the right way to handle transition; i would just add (define qtbase qtbase-5) <civodul>which would later be changed to (define qtbase qtbase-6) <apteryx_>I see, that seems a good thing indeed. I'll try it now. <civodul>though it's kinda weird because the qtbase@5 derivation hasn't changed, presumably, right? <apteryx_>civodul: but perhaps I've missed something <apteryx_>w.r.t. to the specification->package not working for 'gcc', do I understand that it's an understood consequence of adding the 'gcc' alias? <civodul>(specification->package "gcc") does work, thanks to the alias <apteryx_>but not (specification->package "gcc@7") on any specified version <civodul>right, see gcc-toolchain-aka-gcc in commencement.scm <apteryx_>that's a weird Qt error to have following my change; I don't have an explanation in mind. <apteryx_>that paraview package comes from a channel? <apteryx_>civodul: just realized, in my case (specification->package "gcc@7") was used in a manifest in constructing my custom c-toolchain; what I really want to get is the lonely gcc package rather than the toolchain. Seems I'll have to use the gcc-7 variable directly. <apteryx_>civodul: note that if we add (define qtbase qtbase-5), the same will also be needed to be done for each qt module (define qtsvg qtsvg-5) when they get updated (there's a patch in review from ecbrown upgrading many qt modules for version 6) <apteryx_>civodul: for the error you see (qt 5 not being found), I guess I missed some reference to it somewhere, and it's now at qt 6 in your build, causing it to not be found <ecbrown>(not to but in but i expect if a new package arrived with qt it may not have gotten the -5 treatment) <apteryx_>ah, given that's in a channel, it didn't get the automatic rewriting treatment <apteryx_>all your qtbase references in your channel are now at qtbase-6 <apteryx_>afte we add (define qtbase qtbase-5) that build failure will probably go away. <apteryx_>hmm, thinking more about it, I don't really like the idea of having qtbase point to qt5. It means we wouldn't likely be able to have the qtbase variable be at qtbase-6 for a year or more (I'm expecting the transition will take a lot of time, similar to Python 2 -> Python 3). <civodul>apteryx_: you cannot refer to 'gcc' (the variable) via specification->package, because it's hidden <apteryx_>civodul: so I'd just suggest running the commands found in ea0a51071e68c37a4c9c25421cf03bc2f442c67b to automatically migrate your channel. Does that sound reasonable? <apapsch>given a one-shot service that is a requirement of a daemon service, the daemon service will start as soon as the one-shot service is successfully started, no? one-shot must not complete before daemon is started? <civodul>apteryx_: i'm fine with running sed on my channel, np, but it still sounds useful to keep a 'qtbase' variable <apteryx_>If qtbase was to point to qtbase-6, how would it be useful? In my opinion, Qt5 users should use qtbase-5 from now on, the same Python 2 users must specificy python-2 :-) <ecbrown>people would have 64-bit containers everywhere <ecbrown>QMap will no longer blow up when moving from laptop test cases to SMP <ecbrown>but retains 32-bit for those platforms <ecbrown>Qt5 compatility exists in the Qt5Compat module, and guix accomodates legacy users with -5 versions already patched up *ecbrown ends sales pitch for qt6 being default ***apteryx_ is now known as apteryx
***natrys is now known as _natrys_
<wenngle>New to Guix System, trying to configure SDDM as a display manager, but I get the error: service 'xorg-server' provided more than once. I'm using the service modules desktop sddm and xorg. How can I resolve this? <ecbrown>wenngle: perhaps you have to (delete (gdm-service-type)) <tissevert>it's probably because the default display manager hasn't been deactivated and still provides xorg <dstolfa>i think you have to (modify-services %desktop-services (delete gdm-service-type)) <wenngle>dstolfa: I do have that in my config <dstolfa>could you share your entire configuration? ***_natrys_ is now known as natrys_
<ecbrown>wenngle: also make sure there is not a a stray extra %desktop-services <dstolfa>there might also be the keyboard being provided <iskarian>wenngle, are you saying you explicitly have (service xorg) in your (services ...)? <dstolfa>if you have a keyboard configuration, it will provide xorg *ecbrown flames about gdm causing suspend when at gui login window <dstolfa>wenngle: get rid of (xorg-configuration ...) <dstolfa>though, i'm not sure how you're supposed to configure xorg then, but i'm pretty sure that (set-xorg-configuration) is the issue in this case <dstolfa>because that's what the issue was for me <wenngle>dstolfa: where do I put the xorg configuration then? Without configuring the refresh rate, my monitor will not work. <mothacehe>civodul: you are the first officiel Cuirass badge user, congrats ;) <wenngle>dstolfa: Oh well, thanks for the help. <civodul>mothacehe: and a happy badge user :-) <civodul>apteryx: oh you're right, i thought qtbase@6 hadn't been pushed yet, apologies for the confusion! <civodul>so yes, i'll definitely update those packages :-) <mothacehe>hehe, thanks :) they are maybe a bit large compared to "standard" badges ***natrys_ is now known as natrys
<apteryx>civodul: np. Glad the resolution is an agreeable one :-) <civodul>apteryx: besides, thumbs up on getting qt6 in shape! <civodul>i expect to have a 100% badge again soonish <apteryx>civodul: thanks! ecbrown has made a lot of work too on the the qt modules (in review) <iskarian>I'm no scheme expert, but I haven't seen guix use cons*, usually I see (append (list ...) ...) <civodul>apteryx: neat! i feel like we should have tools that automatically try s/qtbase-5/qtbase-6/ on all the dependents <dstolfa>iskarian: the issue crops up when you use sddm as a DM, it works when you don't <civodul>cons* is fine; it's rather obscure to newcomers though, which is why documentation resorts to (append (list ...) ...) <dstolfa>it would be worth chasing down in any case, (service sddm-service-type) shouldn't cause (set-xorg-configuration) to not be happy <iskarian>oh, in that case you can use (service sddm-service-type (sddm-configuration (xorg-configuration (xorg-configuration (extra-config ...))))) <bsima>does the guix world have any thoughts on nix flakes? <lispmacs[work]>raghavgururajan: not sure if you were looking for my opinion, but the badges in the 48827 issue look good. If you wanted me to be really picky, I'd probably suggest /thinking about/ maybe a slightly simpler logo text, like "GNU Guix ready" <dongcarl>apteryx: I see that I was pinged, still need help? <apteryx>dongcarl: thanks for asking :-). I'm investigating the feasibility of having qtbase built by Guix, and used as part of foreign builds (Debian, Fedora, etc.). My simplest idea is to 'guix pack qtbase', then point the foreign build system to it so that it can be used linked against by the native build. I've read that for this to work, usually the linker/gcc must be newer than any of the constituting <apteryx>parts, so perhaps I'd have to downgrade the glibc used to build qtbaes on Guix. Any thoughts? <apteryx>civodul: that could be useful, although we are not ready yet because most qt packages will not only depend on qtbase but also on the qt modules (e.g., qtsvg), which need to be updated first. <apteryx>civodul: strangely, when building qtbase using a gcc-toolchain made using the 'make-gcc-toolchain' helper, the implicit input named "libc" doesn't seem to exist among the builder inputs; (assoc-ref inputs "libc") apparently return #f, breaking qtbase's patch-paths phase. Any idea why that might be? <ixmpp>$ guix home build -L . (echo '((@ (gnu home) home-environment))' | psub) <ixmpp>guix home: error: '/tmp/.psub.BNciJvBgSh' does not return a home configuration <ixmpp>This fails for all my versions of my home config now <ixmpp>(echo "blah" | psub) == <(echo "blah") <ixmpp>I tried time machine too, no luck <roptat>the time machine wouldn't go back in time on other channels, so maybe it's an issue in the guix home chanel? <ixmpp>I also just tried a few old guixes, no luck <ixmpp>If i run (home-environment? (home-environment)) its true <roptat>is this home-environment really the one that comes from (gnu home)? could it come from somewhere else? <ixmpp>Not to mention, my home-config that worked fine til now suddenly doesnt work <roptat>could it be that there are two conflicting (gnu home) modules somewhere? <roptat>(I don't use guix home, so I help too much ^^) <ixmpp>Maybe, actually! I'll test removing one <ixmpp>roptat: Clever man! I removed guix-home-manager, guess it was conflicting with rde <roptat>ixmpp, oh, there's no (gnu home) in guix home manager I think, but it does add a "guix home" command <roptat>so guix was confused which one to run ^^ <roptat>Noisytoot, that's the home manager, guix home a different project with similar goals <apteryx>civodul: the diff of the inputs when using a custom toolchain; seems the toolchain inputs usually appearing flatly in the bag are now hidden behind the "toolchain" package: https://paste.debian.net/1201209/ <muradm>i'm trying to use libgccjit for emacs, is there any example on how to use it with other package? <muradm>just puting it to native-inputs or inputs does not work <muradm>ld: cannot find crtbeginS.o: No such file or directory <muradm>ripgrep, no uses of libgccjit in guix at all... <ixmpp>A library that nobody uses but still got added, that seems a familiar situation <ixmpp>Where are the cries of "maintenance burden" and "needs uses" <jackhill>I think it's okay to add libraries that aren't (yet or ever) used by Guix packages. Folks may want to use them in their own code. <daviwil>libgccjit will get used by Emacs as soon as 28 drops, provided that maintainers turn on the native comp feature for the main Emacs package <dstolfa>daviwil: you're sending empty messages <daviwil>Wow, sorry for the blank lines there, no idea what ERC did <muradm>jackhill: yeah, copy paste of those magic phases helps, but why magic <jackhill>hrm, although looks like that channel defines it's own gccjit <jackhill>muradm: I haven't studied it in detail yet, sorry <muradm>jackhill: yes, i know, today was my fifth attempt to build it, but no patience, libgccjit takes like forever to build <daviwil>yeah, it's painful waiting for that to build <muradm>guix has libgccjit-9 built already <jackhill>yeah, I read the gccjit documentation once, but haven't yet had the oppertunity to get into it more. <ixmpp>> I think it's okay to add libraries that aren't (yet or ever) used by Guix packages. Folks may want to use them in their own code. <ixmpp>I was lamenting the fact that this is the exact reason libsystemd hasnt been added <muradm>i would not add libsystemd also ) shepherd is more than fine, guix hosts me until there is no systemd <muradm>ixmpp: why need libsystemd any way? <ixmpp>muradm: I had a program that depends on it <dongcarl>apteryx: Oh, you can also construct a gcc-toolchain targeting any glibc version with make-gcc-toolchain <ixmpp>But apparently while thats enough of a reason for any other library, it's not for this one <apteryx>yeah, I've tried the make-gcc-toolchain helper, but it seems to mask the implicit inputs from under "toolchain", which breaks some phases (e.g., (assoc-ref inputs "libc") now returns #f). <muradm>ixmpp: i would argue that libgccjit is very core thing to execution of binaries, libsystemd is diffrent thing. <daviwil>I'm not even sure what libsystemd would even do without systemd running <ixmpp>> I think it's okay to add libraries that aren't (yet or ever) used by Guix packages. Folks may want to use them in their own code. <daviwil>Maybe this program can be built without the dependency with a compiler flag? <muradm>eactly, to put libsystemd, you need to pull systemd ecosystem in <dongcarl>apteryx: Hmm you might want to compare make-gcc-toolchain with the gnu-build-system and see how they compare <dongcarl>Also worth looking at: build-system-with-c-toolchain <muradm>ixmpp: what is that important program that dependes on libsystemd? <muradm>ixmpp: bad program, by any means should be optinal.. <muradm>checking if it working at all :) <muradm>thanks to magic from flatwatson of course <apteryx>are there any differences between .lzma and .xz archives? <jackhill>systemd sounds like its special software, so probably takes more wrangling than usual to get a working package :) It looks like some of the concerns are being worked though in the ticket, and we'll probably get a systemd package eventually. I guess gccjit is special too, but at least its a component of the already-packaged gcc <muradm>native compilation will definetly require additional step in emacs-build-system <jackhill>I wonder if native comp will make the emacs build more reproducable <dstolfa>i hope it will make emacs drain less battery... <dstolfa>emacs right now is really heavy on battery usage in large files <muradm>for now i just want lsp to work faster <muradm>jackhill: obviously i know what does it mean ) just wander why emacs build isn't <muradm>if it wasn't reproducable before, why libgccjit should make it so, i can't imagine <jackhill>well, if we knew exactly why, then it would be easier to fix :) Overall, I think non-reproducable aspects were introduced over the many years, and it hasn't been a priority by the emacs developers to fix. My thought about native comp helping came from seeing many of the reproducability problems in .elc files and the new prortable dumper, which native comp may make irrelivant. <jackhill>Or it could mean that I really don't understand the big picture. <apteryx>seems like the upstream of guile-hashing vanished <muradm>much faster build time, ~30mins instead of ~30mins + libgccjit infinity build :) <muradm>basically it sets NATIVE_AOT_FULL=1 <muradm>that makes emacs ~3min build + remaining ~20 min native byte comp of lisp code <muradm>may be it just not necessary to make NATIVE_AOT_FULL=1 at all, any way they will be built on first use <muradm>in general it feels much much better ) <muradm>this will need solution also /home/muradm/.cache/guix-extra-profiles/desktop/share/emacs/site-lisp/mu4e-view.el: Error: File error Opening output file <muradm>site-lisp packages cannot be libgccjit'ed <apteryx>does someone know how to invoke 'ar' manually to create archives with arbitrary members? <efraim>Not in front of my computer but we also have a dpkg package I think <apteryx>thanks. Perhaps digging through its sources can provide clues. <pkill9>ar is in binutils, that's all i know <muradm>maybe add binutils to native-inputs, and then (invoke "unpack" ...) <muradm>guix/build/gnu-build-system.scm:147 unpack phase