<pkill9>content-addressed derivations sound great <pkill9>you can display gtk applications in a web browser <vagrantc>i can't seem to find in the guix manual where it recommends to add the relevent enviornment variables so that "guix" points to the one from "guix pull" on foreign distro installations ... ***j is now known as jess
<apteryx>I think it's all in the manual, but it's a bit of a treasure hunt <vagrantc>i usually just symlink ~/bin/guix to point to current/guix :) <vagrantc>trying to add some documentation to the Debian package so that they're not stuck on guix 1.2.0 after running guix pull <vagrantc>yes, treasure hunt is an apt description of the manual sometimes :) <vagrantc>there's so much there, but if you're looking for a particular gem, it gets lost in the hoardes of information <apteryx>but to answer your question succintly, I think none action is required; it seems 'guix pull' automates the symlink creation. *vagrantc also wonders why not just link directly to /var/guix/profiles/per-user/USER/current-guix <apteryx>for this you'd source ~/.guix-profile/etc/profile, no? <vagrantc>which is why i symlink it into ~/bin/ ... a lot simpler <vagrantc>i guess that doesn't set the other variables, though <apteryx>right, you'd be missing any other env that your Guix profiles requires <vagrantc>i wonder if i shouldn't ship something in /etc/profile.d/guix.sh <roptat>alright, I think I managed to build scala with the binary scala <roptat>a necessary step if I want to build it with (non yet existing) bootstrapping scala compiler :) <apteryx>vagrantc: the guix-install.sh script has the comment about why it installs this file: "Create /etc/profile.d/guix.sh for better desktop integration" <vagrantc>maybe we can split that out of the install.sh so i can simply install it in the package... <vagrantc>and then just embed it in the "shipped" install.sh <vagrantc>as that would be nice to have working out of the box in the package <apteryx>raghavgururajan: I'm now looking at patch 43/53 for the linphone series <raghavgururajan>> apteryx: raghavgururajan: was there a reason you added python to belle-sip? I seem to get away without. <apteryx>is there a way to disable CVE checking for a package? 'cli' is not listed in the CPE dictionary, yet it collects many false positives. <apteryx>yeah; there may be some trick at the package properties level <raghavgururajan>Regarding codesynthesis.scm, the idea is similar to suckless.scm and linphone.scm. This project has produce multiple software, which are often inter-connected and/or inter-dependent. So created dedicated module for this project 'Code Synthesis'. <apteryx>OK, so far cpp.scm seems sufficient; it's a relatively small module itself <apteryx>codesynthesis is somewhat misleading as a module name, not all their tools are about code synthesis (that's their company name, but that ain't obvious) <apteryx>I've merged stuff in cpp.scm already, if you check your emails/master <apteryx>I seem to recall that civodul (correct me if I'm wrong about it) had this opinion that module names should be preferably attributed to packages we want to showcase/advertise, such as GNU packages (e.g., we have gnu/packages/gimp.scm). Not a hard rule, but worth considering before creating a new module, in my opinion :-) <apteryx>ouch, no ffmpeg on master (needs to build the whole rust) <apteryx>not sure what I did, but what I said above is no longer (never was?) true. ***sneek_ is now known as sneek
<FennecCode>Anyone else getting a "Bad http-version header component: ´¼|Ä·C½C.ÞO/çrçåügçoWs4\¤sÎyaLWôú«·Ûn5J©ä]õòÓH±s0òkûí" on guix pull? <raghavgururajan>sneek, later tell lle-bout: I'll get back to you on things for next batch. I first have to update the chart for GNOME 40. <raghavgururajan>sneek, later ask civodul: Was there rationale for choosing https over ftps, for downloading sources and substitute? ***gurmble is now known as grumble
***apteryx_ is now known as apteryx
***sneek_ is now known as sneek
<leoprikler>FennecCode: that issue should already have been resolved. Do you still get it on a more recent version of Guix? ***sneek_ is now known as sneek
***sneek_ is now known as sneek
***sneek_ is now known as sneek
<ennoausberlin>Hello, I still struggle to make a package for python-asttokens. Can you give me some advice, why it fails? <genr8_>wheres the build log. i would guess its got something to do with wheel and setuptools <genr8_>i doubt its your fault. you're probably gonna have to wait for someone higher up to handle it <genr8_>it may be something as simple as declaring an environment variable <ennoausberlin>enr_: If I unpack it by myself and run it to install locally, I dont get an error <nckx>Good morning, Guix, sneek. <genr8_>might have to do with PYTHONPATH env var <nckx>ennoausberlin: Is python-wheel in the package inputs? <ennoausberlin>enr_: I will scam over other packages in python-xyz to see how PYTHONPATH is related <genr8_>im doing this myself now :) i am not finding much success <genr8_>maybe another question to answer: what system CPU architecture are you building on ? ***sneek_ is now known as sneek
<nckx>What's going on with sneek? <nckx>ennoausberlin: <If I unpack it by myself and run it to install locally, I dont get an error> You can't meaningfully compare the two. <nckx>sneek: later tell sneek: come back :( <genr8_>what is the diff between setuptools and setuptools-scm in this case ? <genr8_>also, was the order of operations for the inputs relevant ? <nckx>Nope, I'm just obsessive. <ennoausberlin>nckx: Your version works. Thank you. How can one publish this to the official package channel? <nckx>genr8_: They're just different packages. setuptools-scm feeds scm-managed package versions to setuptools to ‘build’. <genr8_>yeah that must have been it. python-setuptools-scm-3.4.3 vs python-setuptools-52.0.0 <nckx>genr8_: What do you mean? <genr8_>the scm one doesnt have a dependency of the actual setuptools <nckx>ennoausberlin: You make a git patch against Guix proper adding this to one of the files in gnu/packages (probably python-xyz.scm) in a vaguely alphabetical location. See the ‘building from Git’ section in the manual if you don't have a local Guix check-out yet. <nckx>Then the rest applies. Move your package to python-xyz.scm, make sure it builds from the git check-out, commit a patch and git send-email it --to=guix-patches at gnu.org. <nckx>genr8_: Doesn't it? I thought setuptools was a hard dependency of setuptools-scm. That's what the docs imply. <ennoausberlin>The real package I want to add is python icecream. That belongs to asttokens. But guix search asttokens does not give me an result while guix package -I does <genr8_>I think that was the issue at hand here <nckx>ennoausberlin: Isn't that just because you installed your own package? <ennoausberlin>I want to test both locally first before I send something to guix-patches <nckx>Thanks. Nothing worse than ‘here's a new package you're welcome’ ‘hm doesn't work here’ ‘oh I didn't test it’. <nckx>Once you've added both to python-xyz.scm you can test them by installing them, loading them at a REPL, adding them as an input to other packages, … <ennoausberlin>python-asttokens is propagated-input for icecream. Do I have to specify where it is found in python-icecream.scm? <nckx>If this is about the final patch: add both to python-xyz.scm. Icecream doesn't deserve it's own module. <nckx>If this is about using ‘guix … -f’ (which I never use): I don't think there's a way to declare inter-file relationships yet. -f is for quick tests, and takes a single file. <nckx>Morning raghavgururajan. <ennoausberlin>ckx: OK. I have to figure it out somehow. I will add both to my local xyz first. I am still not fluent on the guile repl. This will change soon, if I have to build more and more packages at work, <nckx>raghavgururajan: I am answering e-mails this morning. Just to answer any question you might have. <nckx>ennoausberlin: If you get stuck, ask specific questions & I'll do my best to get you unstuck. *nckx happy little digger. *raghavgururajan resumes GNOME work <nckx>The way offloading is currently designed that would give you the ability to upload arbitrary store directories with arbitrary contents (so a /gnu/store/<the right hash>-util-linux/bin/ls that's actually ungoogled-chromium, or even worse) and Guix wouldn't know the difference, wouldn't ‘repair’ it because it's valid, and would serve it to anyone using bayfront as substitute server. <nckx>Extreme irreproducible builds. <nckx>You can always ask guix-sysadmin@ but be aware of what you're asking. <nckx>OTOH this is the same access anyone hosting a berlin build node (/me waves) already has... (/me shrugs). <nckx>TL;DR offloading can use a redesign but that is not the topic at hand. <nckx>A very coincidental lle-bout appears. Good morning :) <raghavgururajan>nckx: Ah I see. No worries then. One issue with I am having with ssh is that, bayfront builds everything since it doesn't use substitutes. Whereas, if I do offloading, bayfront builds only things that is asked by my machine. <raghavgururajan>lle-bout: Working on glib-networking as it is a blocker to building gtk+ <lle-bout>raghavgururajan: is there a reason you can't use the machine I gave you with SSH? <lle-bout>raghavgururajan: I noticed glib-networking was broken yes <raghavgururajan>lle-bout: I could build there. But as you mentioned, guix publish wasn't setup? Also, our guix copy attempts didn't go well. <lle-bout>raghavgururajan: I generated substitutes for the core-updates branch on my machine, also on the proxmox-2 server <nckx>raghavgururajan: Right, that's the exact mechanism that would allow you to upload arbitrary binaries. You could ask bayfront to build a custom package that depends on <malware>, then bayfront will kindly ask you for the binary <malware> instead of building it from source, and voila. <nckx>Not saying you would do that, of course. <lle-bout>raghavgururajan: I'll give you offloading access to a VM on that same machine so it's secure, hang tight <cbaines>I'm hoping to get bayfront running a Guix Build Coordinator instance, which will at least mean it'll be busy building stuff, and not generally idle <cbaines>I realise some people have been making personal use of it, and as it's been generally idle, I can see why. It would be nice to properly tackle that need though <nckx>lle-bout: Do you do anything clever to reduce storage duplication? <lle-bout>cbaines: I don't know if Cuirass remote build is more secure in that aspect, maybe we could import that from Cuirass into the GNU Guix daemon/else <lle-bout>but in general, I was thinking, replace the code that tries to copy store items by some code that asks to rebuild derivations instead <cbaines>lle-bout, what you set out in one of your emails is basically how the Guix Build Coordinator currently works (and Cuirass does similarly) <nckx>raghavgururajan, lle-bout: I thought that rebuilding was was Raghav was trying to avoid in the first place. <cbaines>I believe they both now use substitutes to move things between machines, rather than copying store items <lle-bout>nckx: yes but the machines are powerful the ones I provide, it would be OK, the only way for it to be secure is to rebuild anyway <nckx>Cuirass or the GBC in their current form won't solve that though (no security difference between SSH copying/substitution). <nckx>I think we mean the same thing though. <nckx>Builds of things you already have that you want bayfront to re-use, not build from source? <raghavgururajan> For example, lets say package A has two depdendents B and C. All three of them has been built on CI and substitutes are available. Now I modify package A (not B and C), my machine tries to build A (without B and C as it gets substitutes from CI). <lle-bout>raghavgururajan: the machine I am giving you, marusich has access to it also, so beware of that when you use it, I and marusich would have power to compromise your machine, you can however setup your machine in such a way that this cannot happen, e.g. by doing the offloading from a VM, but you can also trust us, we most certainly wont attempt such stuff <raghavgururajan> If I build modified A on bayfront, it also builds B and C, because bayfront doesn't use substitutes or have B+C already built. <lle-bout>raghavgururajan: please give me your store public key <lle-bout>raghavgururajan: I should also setup a substitute server on proxmox-2 but don't know how very much <genr8_>having a server that rebuilds everything seems preferable. just not for you <nckx>raghavgururajan: With s/dependents/dependencies/ I understand what you mean. But the issue is still the same: either bayfront has to trust a substitute server, or it trusts you. It currently does neither for a reason. There's no way around that without dropping that reason. <nckx>raghavgururajan: /etc/guix/signing-key.pub <lle-bout>raghavgururajan: "guix archive --generate-key" as root <leoprikler>raghavgururajan: is the license for codesynthesis build really GPL2+? Seems pretty GPL2 to me <lle-bout>raghavgururajan: you can connect on port 10522 SSH www.proxmox-2.schmilblick.org with your IRC nick, you ssh public key is authorized ***sneek_ is now known as sneek
<lle-bout>raghavgururajan: you can add another SSH key to your account (one generated by root for example) so that you can fill your /etc/guix/machines.scm configuration <raghavgururajan>lle-bout: Thanks! Should I authorize via config.scm or guix command? *raghavgururajan checks the manual <nckx>Does ‘guix environment --ad-hoc gramps -- gramps’ work for you? <lle-bout>raghavgururajan: I also added that substitute server to the machine I gave you, so it should get substitutes from the proxmox-2 host too, so it doesnt waste CPU power <lle-bout>raghavgururajan: the VM has local access to the proxmox-2 server, so that's fast, too <nckx>lle-bout: How tedious is it for you to create such VMs? I'd like one too, but I'm also interested in whether/how you're automating it. <nckx>raghavgururajan: Thanks! <lle-bout>raghavgururajan: so all you have to do is add that offload server and everything will tick into place <nckx>raghavgururajan: If it doesn't work, I'd love to know if it does with --pure. <lle-bout>nckx: I use proxmox-2 it's AGPL software and runs on top of Debian, but I don't think it's perfect, I think you may be better served by cockpit on top of Debian with libvirt plugins (the web virt-manager replacement), but also, ganeti in GNU Guix looks nice <raghavgururajan>nckx: The app runs but barfed an error window about incomplete gtk installation. <lle-bout>nckx: basically if you set up libvirt on a machine, you can then connect remotely to it over SSH with virt-manager GTK client <nckx>Is that without --pure? Any difference with? <lle-bout>raghavgururajan: so first step, generate an SSH key for your root account on your machine, then add the SSH public key of that in your authorized_keys of your rag.. account on the VM I gave you, then setup the machines.scm to connect to the rag.. account on the VM with the key in the root account of your machine <lle-bout>raghavgururajan: you can but I create a new one for the root account specially for offload <lle-bout>raghavgururajan: basically if you want to use the one of your account you need to explicitly set it's path, and also I don't think it works with encrypted keys, so that's why also <lle-bout>nckx: I think there's some work until I can fully automate this VM stuff with GNU Guix System, I would really like to <lle-bout>raghavgururajan: also yes you need the host key <soouul>anybody know how i can blacklist a usb device? <lle-bout>raghavgururajan: not you, only on the VM that is <lle-bout>soouul: hey! blacklist with the kernel command like? <soouul>in a file in /etc/udev/rules.d/file.rules <soouul>not called files obnviously but yeah <soouul>but i did it and it did not get blacklisted, so im assuming if it has to do with the specific program or with the rule being ignored <lle-bout>soouul: in the manual search for udev-rule <nckx>soouul: Does Guix's udev even look in that directory? Try using the service method explained in ‘Base Services’ in the Guix manual. <nckx>soouul: There's an %example-udev-rule that's easy to adapt. <soouul>im compiling firefox though so itll be a bit :c <soouul>and this rule in the example, i can call it whatever? <nckx>Calling ‘usb-thing’ is not mandatory. :) <raghavgururajan>(FYI: My user account username is rg). I;ll use its ssh instead of root, as it is not password encrypted. <lle-bout>raghavgururajan: to test offloading, as root run: guix offload test <raghavgururajan>After creating machines.scm, I should do something in config.scm right? <lle-bout>raghavgururajan: in config.scm, you need to trust the offload machine's public store key, let me get that for you <lle-bout>I use plain-file instead of local-file so I can embed the keys in my configuration itself but using files is fine too <lle-bout>then once that's done, as root, run: "guix offload test" and everything should work! <soouul>can i add a packges list for my user-account? <lle-bout>soouul: basically you would manage those using your main profile as your user <lle-bout>soouul: guix install as your user effectively does that <soouul>thats what i been doing, just curious if i could declare it <lle-bout>soouul: but beware, you would need to upgrade those packages separately, using guix upgrade, a system reconfigure upgrade wouldnt touch them <lle-bout>soouul: you can declare it of course, you can use guix package --export-manifest to get a manifest then.. (looks up) <soouul>wait so, the sane option is to put all packages i need globally? <lle-bout>That they are all handled with the same command <lle-bout>soouul: I think profiles are however useful for development, used with guix environment <lle-bout>soouul: I use: "guix environment --ad-hoc something -- something" to spawn one-off commands without "installing" them at all <soouul>yep, that makes sense, alright im moving everything to my main system config! <lle-bout>I was thinking I could create some command-not-found handler for this and automatically try to run it from a package but I would need to create a list of package name <-> program name list <genr8_>lle-bout, you could parse all your /store's /bin dirs <genr8_>id rather start with everything and work backwards <nckx>genr8_: That's extremely slow and at best heuristic, although it would be a pretty good heuristic. <lle-bout>genr8_: sure, since the store contains all the previous versions of packages I would do something a bit better with 'guix build' itself but yes <raghavgururajan>lle-bout: All set! I created ssh key for root, as user's was indeed protected. <lle-bout>raghavgururajan: don't forget to add that root account's public key in authorized_keys of the raghavgururajan user in the VM <raghavgururajan>lle-bout: Oh, so for that, I login via ssh and do `guix archive --authorize`? <lle-bout>raghavgururajan: yes login but just edit the ~/.ssh/authorized_keys file, this is about SSH not guix here <lle-bout>raghavgururajan: I don't see it as /home/raghavgururajan/.ssh/authorized_keys on the VM <raghavgururajan>guix offload: error: SSH public key authentication failed for 'www.proxmox-2.schmilblick.org': Access denied for 'publickey'. Authentication that can continue: publickey,password <raghavgururajan>ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIErzQMgnxFJChAVuQaDOWSUyA1GdLll00HBhIU7BlJ0V rg@secondary <raghavgururajan>ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKr3YxR/wA4dl2AxD+7U98HAslGPCPDwkhgRel6Xc5z/ root@secondary <lle-bout>raghavgururajan: you added it to the host server not the VM it seems <lle-bout>raghavgururajan: I mean: ssh -p 10522 raghavgururajan@www.proxmox-2.schmilblick.org <lle-bout>This is a VM I gave you access to, for offloading <lle-bout>the main host, you can't have access for offloading because it's too much privilege I can't give you (it's basically root access on there) <lle-bout>raghavgururajan: I deleted the root key from www main host FYI <gxr>I wonder if anyone could help me find out if I correctly set up udev in my guix system. I wrote a rule which is available in the folder of 'sudo herd rules udev'. But when I run the udevadm test command or plug in the usb device, the rule is not triggered unfortunately :( <lle-bout>raghavgururajan: I think maybe you wont need access to the main host anymore now? <lle-bout>raghavgururajan: does "guix offload test" work? <lle-bout>raghavgururajan: so that's the store signing key of the VM, you didnt do: "herd restart guix-daemon" maybe? <lle-bout>raghavgururajan: so you didnt add the store signing key to your config.scm correctly maybe? <gxr>I did at least one reboot <lle-bout>raghavgururajan: and /etc/lle-bout-offload.pub contains the key in the error? <raghavgururajan>guix offload: successfully imported '/gnu/store/49cfs1r69mv1kb8b20v0mp4xmh3skjji-import-test' from 'www.proxmox-2.schmilblick.org' <lle-bout>gxr: I advise you look at udev-rules-service instead of using modify-services <lle-bout>raghavgururajan: build all the things now! <lle-bout>gxr: I don't know about that particular thing, not a Scheme expert, but I know i've used udev-rules-service and it worked <lle-bout>udev-rules-service extends things correctly, maybe modify-services like you've done is not enough or wrong somehow, but I wouldnt know <Rovanion>The sendmail source repo provides both sendmail itself and the libmilter library. If I want to package libmilter, do I declare a new public package or do I add an output to sendmail? *raghavgururajan hugs lle-bout <lle-bout>Rovanion: I think it may be wise to create another package here, but "lib" output could be fine <lle-bout>Rovanion: I am thinking for discoverability, people might not know libmilter comes from sendmail <lle-bout>So it would have to be specified in the description somehow, so it shows up in 'guix search' <soouul>can i show the system global packages with guix? something like guix package --list-installed? <Rovanion>lle-bout: Yeah, that is true. Better give it its own top level name then. That is how Debian has done it, not that they have outputs but. <raghavgururajan>lle-bout: Fixed glib-networking. Let me get back to you for setting up a work-flow. <lle-bout>soouul: there's no command but you can make some Scheme code to parse your /run/current-system/configuration.scm and returns the operating-system's definition packages field <Rovanion>Hmm, soouul: add --profile=/run/current-system/profile <soouul>will do, doing something rn so will try later, thanks! <nckx>Rovanion: That's correct, and too little known. <gxr>lle-bout: Ok. I'll give udev-rules-service a try. Looks cleaner to me anyway. Thanks. I'll report ;) <nckx>genr8_: Will fix. I think it's also ‘PKCS #12’. At least without sounds weird to me. <lle-bout>nckx: about the refresh --installed discussion on the ML recently, that would've sorted it out for system profiles <nckx>lle-bout: Did I participate in that? <nckx>Always remember: I am demented. <lle-bout>nckx: a refresh --installed command was added and I was asking for system configurations, so it takes system installed packages <genr8_>whats our policy on how to decide when openssl/fixed 1.1.1k takes over the entry for openssl 1.1.1i <lle-bout>genr8_: there's an ungrafting branch, also core-updates, lots of policies it seems we don't respect, so ASAP, but don't know when, depends on who can commit to doing it, probably before the release, speaking of which, I should look at blocking items for the 1.2.1 release <genr8_>what happens if someone depends on openssl/fixed and then the fixed is removed ? <lle-bout>genr8_: the openssl package is grafted, so using either is equivalent for the end user <lle-bout>you don't have to depend on openssl/fixed <hqert>I am looking at building a home server that can host nfs and samba shares, git/fossil repositories and maybe a few VMs in the future. The plan is to have the OS run on its own disk on an ext4 partition, and all services store data on a zfs pool spanning other disks. Any comment or advice there? I saw that there is already a zfs package available, b <hqert>ut also that raid5atemyhomework appears to be actively submitting patches related to zfs. I am new to Guix and Scheme (this server seemed like a nice learning opportunity), so am suffering from a bad case of information overload. Is there someone knowledgeable about zfs on Guix here that could give a brief overview of how feasible this plan is curr <raghavgururajan>lle-bout: When there is offloading, nothing gets built on my local device right? <nckx>genr8_: In fact you shouldn't. It shouldn't even be public, unless I'm missing a reason for it to be so. <lle-bout>nckx: some people say grafts should be public for 'guix install pkg' to install the newer version directly instead of the graft, some others says not, so I don't know what to do when I do it <nckx>I didn't mean it as criticism. The current code base is just as confused. <lle-bout>genr8_: also there's variable names in Scheme, but also there's package names, openssl/fixed still has "openssl" package name, so that's fine if you depend on it <lle-bout>nckx: I understand, didnt take it that way, but I want to know what to do myself also <lle-bout>It's just that I made this openssl graft in particular also :-P <lle-bout>Some grafts I didnt make public, some others I didnt.. <lle-bout>genr8_: "guix install" or any use of "specifications" uses package name and not variable name <lle-bout>hqert: best thing would be to email the raid5atemyhomework guy <lle-bout>not all their patches are merged for now AFAICT <lle-bout>nckx: what do we do about the zfs guy, they most certainly gave up on us now <hqert>lle-bout: they actually submitted new patches a few days ago I think <gxr>hqert: If zfs is not a must for you, but you still want to proceed with your guix experience while building your server. You could try if ceph fits your needs. <soouul>how do you deal with the "cannot have two different version or variants of 'xxx' " errors? <gxr>At least there is a package for it. I haven't tried it yet. <lle-bout>gxr: for proper integration it would need a service etc. <hqert>gxr: zfs is not an absolute must, but it appeared to be a good solution for storage of important stuff. It was highly recommended to me, and I like the checksumming, snapshot and incremental backup features <gxr>lle-bout: The stuff I wanted to do was possible without further integration. But I agree, that a proper integration would be better. <raghavgururajan>[1] Create a thread in guix-patches@gnu.org with the subject "GNOME 40" [2] Create a git branch with the name "gnome-40" (somewhere), where we can both push to and work together. [3] Once we have commits ready to be merged, we'll generate patches of them and sent it to the email thread. [4] Then we'll merge them to core-updates. ***davidl_ is now known as davidl
<lle-bout>raghavgururajan: do you have commit access? <hqert>I will email raid5atemyhomework and see what they say. My understanding is that his patches are regularly changing however, so maybe using them as a core part of my system is not the best idea? <lle-bout>If so, then we can create the branch and go on <lle-bout>hqert: that is also one of the problem hurting review, it's that things change often <lle-bout>raghavgururajan: okay! great! did you get 3 vouch? <lle-bout>raghavgururajan: let's do that yes sounds good to me, we can create that branch on GNU Guix git itself once you are approved, how long has it been now? <gxr>hqert: zfs has a lot of neat features. I do not have a requirement at the moment to use zfs, ceph or something similar. I use btrfs with luks. I do regular backups in order to not loose anything critical. I can live with a few hours of data loss atm. But anyway, good luck with your zfs endeavour. <lle-bout>nckx: I think that it may be OK in GNU Guix because basically it's not adding ZFS to Linux itself but providing tools to combine ZFS and Linux for private use <hqert>lle-bout: I see. I would like to get the fileserver part running soon-ish, but will check in with them if I can do something to help with advancing the patchset. <lle-bout>hqert: reviewing the patchset for your usage will be helpful also, you can post your results to the mailing list <lle-bout>It's helpful information useful to the committers <leoprikler>that's just as far as the GPL itself goes to explain about future versions <lle-bout>raghavgururajan: please do send such mail on guix-devel instead I think, then we'll cooperate, I think we can create a new repo where we both have access <cbaines>I just need the relevant keys to add <lle-bout>raghavgururajan: please send your ssh public key to cbaines <cbaines>once I've had time to remove the email password from that Git repository, I'll be able to give people access to the Gitolite admin repository too <hqert>lle-bout: Let's see what raid5atemyhomework says, I will keep you updated. Thanks for the help! <lle-bout>cbaines: do you think you could get per-branch access rights also? <lle-bout>cbaines: so you could become some kind of staging area for WIP stuff of non-committers securely, because GNU infra is inert <cbaines>I think gitolite probably supports branch specific access control <cbaines>lle-bout, that's the direction I'd like to see <lle-bout>Yes I feel like we have lots of social and technical bottlenecks in GNU Guix that's making lots of people feel left off or frustrated <cbaines>since Savannah lacks support for per branch access control, I think separating master, core-updates, staging ... from the wip-* branches would be good <lle-bout>For me, I think it is a matter of inclusivity that we tackle these problems, one of which is writing better documentation somehow and information sharing more <lle-bout>There's not many GNU Guix "experts" I feel like I can refer to or learn from when needed <hqert>gxr: thank you too for the information. I will also look into other filesystems and maybe try to run the fileserver as an appliance, and experiment with zfs on the side. <lle-bout>People that know lots about the project and can answer questions about lots of its components and how they work <lle-bout>raghavgururajan: I mean we will send the patchset later, when complete <lle-bout>raghavgururajan: to announce and speak about our work I think guix-devel is better <raghavgururajan>lle-bout: I have glib-networking patches, shall I start the thread and include patches for that alone? So that we can get started. <lle-bout>raghavgururajan: I think I can push them without going through guix-patches, let's just work on the wip-gnome-40 branch I just created at cbaines's guix-patches git <raghavgururajan>lle-bout: Cool! I just stared the thread on guix-devel with intro message. <soouul>sorry to interrupt again but i am confused as to how i can allow programs to find libstdc++, doesnt seem to be in neither the system or my profile lib folder <lle-bout>raghavgururajan: I'll re-create wip-gnome-40 on guix-patches because I did it wrong <lle-bout>soouul: are you compiling a package manually again? <soouul>its steam, needs to find libstdc++ <lle-bout>soouul: GNU Guix doesnt provide steam as it is nonfree software, so that's not where you can get help <lle-bout>See with whatever third party channel may provide such package <raghavgururajan>lle-bout: Are you checking out the new branch 'wip-gnome-40' from master or c-u as base? <soouul>i knowww but i figured id ask about the linker stuff <lle-bout>soouul: it's very specific to nonfree software, that problem <soouul>its funny how open source stuff works flawlessly and this has been more of a headache <lle-bout>soouul: GNU Guix is designed for Free/Libre and Open Source Software :-) <soouul>oh i didnt mean just in guix, i meant in everything <soouul>i am so glad i switched off of nvidia graphics cards, because that was so painful too <lle-bout>oh well, probably because FOSS is easier to understand and integrate <lle-bout>raghavgururajan: I need to take care of myself for a bit, havent been eating so well, see you soon <lle-bout>raghavgururajan: see with cbaines also their build farm will be crunching this <lle-bout>but I feel like it's too overloaded to be useful for dev now <cbaines>at least some builds do seem to be happening :) <lle-bout>cbaines: yes! do you think there's software optimizations that can happen here or just more machines? <cbaines>I think the Build Coordinator will scale up well with available hardware, so the situation is better now than it was before <cbaines>lle-bout, I'd hope that more machines should make things go faster <cbaines>raghavgururajan, this is where names get confusing, it's separate from ci.guix.gnu.org, although much more related to CI in my opinion <lle-bout>cbaines: I could rent an AMD Epyc Milan dedicated machine (most recent 2nd generation 7nm), then have it run guix-build-coordinator as it's sole purpose <cbaines>even though we don't really practice continuous integration as a project, I really hope that things like Patchwork will help things get merged faster <lle-bout>CI/CD workflows help streamline review so much <raghavgururajan>cbaines: I see. Can lle-bout and I, add your machine's address to get substitutes? <cbaines>lle-bout, it's probably not quite worth your money at the moment <cbaines>one direction to investigate in the future is having a shared Guix Build Coordinator instance for people to use for development purposes <lbll>Hi all, I am a scheme noob. What is the meaning of the lambda* syntax versus lambda (without the star) ? <lle-bout>cbaines: using substitutes from builds.guix-patches.cbaines.net is definitely dangerous <lle-bout>Well basically, you are in danger from anyone having hardware in the build farm, otherwise, no danger AFAICT <lle-bout>Or else, the danger comes from vulnerabilities in the guix-daemon or else <cbaines>lle-bout, regarding more hardware, at the moment, it's not the most important thing to spend time on. I'll get to it at some point, and then it would be great, but at the moment, it's probably a distraction. <lle-bout>To me, it's not acceptable to run untrusted code from random people without at least a VM for builds <lle-bout>That the build sandbox should be adapted to run in VMs also <lle-bout>Something like Firecracker could be used to quikcly spawn one-off VMs <lle-bout>The store item would have to be securely copied out of the VM, instead of giving access to the store directly <cbaines>I think your talking about multiple issues <lle-bout>When I send an email to guix-patches, untrusted code can run on your build VMs <cbaines>lle-bout, indeed, but there's some isolation from the guix-daemon <lle-bout>If this untrusted code compromises the build VMs because of a flaw in guix-daemon or the Linux kernel, then builds.guix-patches.cbaines.net substitute server can no longer be trusted <lle-bout>I think that isolation is not sufficient for untrusted code <cbaines>currently the bigger hole is that the Guix Data Serivce runs some Guile code from the guix-patches Git repository without isolation <lle-bout>One vulnerability in the Linux kernel or guix-daemon is sufficient to compromise everything, it's too risky, per defense-in-depth strategy, there should be some additional layer <lle-bout>cbaines: if that's the case.. then definitely very dangerous <lle-bout>cbaines: I am thinking we could make use of the GNU Guile sandboxed evaluation features to have things like "sandboxed channels" <cbaines>It's been a long while since I looked at them though <lle-bout>cbaines: if not already, I am thinking we should put bolder security warnings in the manual on GNU Guix features and what kind of trust they involve <lle-bout>e.g. Adding a GNU Guix channel means giving arbitrary code execution rights to your computer to the hosting provider hosting the channel as git repo, or anyone who has a copy of the GPG private key used to sign the channel commits if that's used <pkill9>I thought it's all built in a container <pkill9>then again i suppose packages can have local-file declarations <lle-bout>pkill9: practically in information security, vulnerabilities happen, and counting on the fact that one system is never vulnerable for security is not enough, you must make it so one needs multiple working vulnerabilities to compromise the whole system, try to have some mechanism that limit the impact of the exploitation of one vulnerability <lle-bout>cbaines: do you need financial support for your work? I see liberapay is empty, unfortunately I can only give out Bitcoin and your liberapay doesnt have that it seems <raghavgururajan>substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix substitute: error: TLS error in procedure 'write_to_session_record_port': Resource temporarily unavailable, try again. <pkill9>lle-bout: I thought that when you say it 'gives' it arbitrary code execution rights, that it doesn't have a single safeguar <lle-bout>I thought you spoke about something else <lle-bout>Channels is arbitrary code execution yes <lle-bout>I have eaten plenty of stuff I feel better now <lle-bout>pkill9: it is that way because it basically extends GNU Guile's GUILE_LOAD_PATH and that means it executes the Scheme code within the files as soon as the first 'guix' command is run after installation (and pull) of the channel <i1l>did someone ran a GUI app installed with Guix on an foreighner? or a Guix bundle? <sneek>i1l, bone-baboon says: I will try Sway and Wayland. I read the Inferiors section of the manual and tried modifying the example given but I get an error that I posted to the mailing list. <lle-bout>i1l: I think I did that earlier, it worked OK, though maybe some icons or fonts messed up <lle-bout>The font/icon issue can be solved by adding more packages within the pack <lle-bout>In the future I hope these will not be loosely defined <lle-bout>"this version of libmilter is divorced from the rest of sendmail because <lle-bout>holy shit that is the worst build system ever, how about we use some <lle-bout>standardized gnu tools instead?" - I approve <Rovanion>I can get its build system to build libmilter.a, but I can't get the damn thing to copy the file to $out/lib. Can I just copy it with Scheme instead? <lle-bout>I believe it is here for historical reasons, but it needs change now <lle-bout>Rovanion: however, are you sure this repo contains latest libmilter as in sendmail official sources? <lle-bout>Rovanion: yes, if nothing works, copy with Scheme, that's fine <Rovanion>lle-bout: I'm not going to use that repo. I'm just as frustrated as the author of the text. It seems abandoned. <lle-bout>Rovanion: copy-file or symlink if it's already in the out dir <Rovanion>Its not. I'll track down some use of copy-file that looks like what I'm after. <cbaines>lle-bout, I did setup Liberapay, at the moment, I'm entirely donating though :) I'm OK with accepting donations (and I can make use of Bitcoin), but I'm fortunate that I'm OK finance wise <lle-bout>cbaines: OK! If you start not being OK anymore, let me know, I wouldnt want you being forcefully attracted away from GNU Guix somehow <lle-bout>raghavgururajan: we must somehow fix php and shepherd <Rovanion>The origin of the libmilter.a file depends on the kernel version and platform, got any hints on how to produce a string like obj.Linux.5.10.7.x86_64? <lle-bout>Rovanion: best thing I think is to patch the build system so that's not the case anymore <lle-bout>Rovanion: make sure it doesnt build binaries specially optimized for the machine it builds on, as that's not good for GNU Guix <lle-bout>pkill9: The software freedom that channels give is huge and very appreciated, however it also comes with security shortcomings, I hope we can find something to solve that later on <pkill9>maybe by default have them restricted *i1l channels inside flatpaks, ha <lle-bout>pkill9: well it's not that easy, because the freedom that they give also is useful for some, how are you going to compose code together if it's isolated <lle-bout>Secure software composition is a whole another topic, there's lots of new stuff happening on it with WebAssembly and WASI, as well as what dustyweb's doing with Goblins <Rovanion>lle-bout: My mind screams at the thought of patching the build system... <lle-bout>Rovanion: maybe look at Debian, Arch or Gentoo packages <genr8_>there should be some kind of central patch aggregator <genr8_>where you can check all the best distros at once <lle-bout>raghavgururajan: so let me see to get those commits to real core-updates <lle-bout>cbaines: idea: create a lint pass that runs licensecheck tool on sources <cbaines>lle-bout, I think that's definately worth looking at incorporating in somewhere <lle-bout>another idea: create a lint pass that runs abidiff, or other abi comparing tools on replacement vs package without replacement <lle-bout>also reports changes in the file hierarchy <cbaines>I'd like to automate running diffoscope on source changes, and maybe output changes too, just in case it's helpful for spotting changes <lle-bout>so when we do need it, we have all data at hand <cbaines>yeah, it's difficult to mandate that voluenteers rigeriously check various things, but it is possible to make it easier I think <lle-bout>cbaines: do you think it's OK if I push some of raghavgururajan's commit without going through guix-patches? They are rather simple non-controversial commits <cbaines>automating this also acts as a prompt, so people should realise to fix things before someone comes around to review it <lle-bout>cbaines: yes exactly saves us time on manual review <lle-bout>cbaines: you could send emails to author and signed-off/co-author of commits about issues automatically <lle-bout>I would reply to guix-commits emails, but that might get spammy <lle-bout>Might be possible to reply but not send to guix-commits, just send to guix-ci and people involved (author, signed-off, co-author..) <cbaines>lle-bout, assuming they're regular changes, then peer review is the important thing, so if you've reviewed them, it's fine to push them. <lle-bout>cbaines: I feel like the back and forth guix-patches is just slowing us down here <cbaines>if they're not regular changes, then it can be good to send them through the usual process, just in case someone wants to comment on them <lle-bout>cbaines: well they're about the GNOME upgrade <lle-bout>raghavgururajan: I don't think the thing really matters for test, since the license label is probably for the installed version themselves <lle-bout>raghavgururajan: To make sure we agree, I think we should always rebase our branch instead of merging, so the commit history stays clean and ready for review <lle-bout>Or maybe not, since it's harder for cooperation <mdevos>Is there anyone here that can help me with the system test, or should I ask later? <oreoking[m]><nckx "oreoking: Thanks. Your problem "> Oh I was using pkill9s channel for wayfire looks like I will have to package it myself <pkill9>tbh wayfire would be good to be packaged in guix, but I don't have much of a dev environment set up <pkill9>so i just dump it in my own channel <pkill9>things like, working with the mailing list, I don't have it all set up <pkill9>so if people make changes I can't easily test it and merge it <pkill9>if I had that set up, or if there was some package that did that, I would merge all my packages with guix <oreoking[m]>Its possible to package software binaries in Guix so there's no need to build from source or use substitutes right? <mdevos>oreeking[m]: I guess you could do that, but why? <oreoking[m]><mdevos "oreeking[m]: I guess you could d"> So you dont have to wait for build times <i1l>oreoking[m]: sorry: flatpaks? <mdevos>consider inferiors intead (5.8 Inferiors) in the manual <i1l>mdevos: "avoid builds" <mdevos>1il: using inferiors avoids rebuilds, if you select a commit version instead of a branch name <i1l>oreoking[m]: also see `unshare`. i happen to install Debian in a namespace chroot. Firefox worked, but chromium didn't. Or `proot`. <i1l>mdevos: last time i tried this trick, build farm ran gc again :) <mdevos>or "guix time-machine --commit FIXED-COMMIT -- environment --ad-hoc PACKAGE -- name-of-the-binary" <i1l>a matter of luck, aha. <mdevos>... and "guix time-machine --commit FIXED-COMMIT -- install PACKAGE" <mdevos>but I would recommend inferior packages <i1l>also an option, ofcourse. <raghavgururajan>lle-bout: Intresting about the license, did it introduce in my upgrade or those test files were there before? <lle-bout>raghavgururajan: don't know, it's highly possible they were here before <raghavgururajan>lle-bout: I see. May be we can add the changes to c-u for now, so that its dependent packages starts building. We'll correct the license later. <lle-bout>raghavgururajan: yes I don't think the license is very important for now <lle-bout>raghavgururajan: things already build on cbaines's infra by the way <i1l>does Macron preserved the State? ^ a watchful citizen want to know (Ikosit). <lle-bout>raghavgururajan: I rebased the branch and force-pushed wip-gnome-40 <raghavgururajan>Btw, `./pre-inst-env guix build gtk+` is building a bunch of stuff, including rust (again). Lets see how it goes. <lle-bout>raghavgururajan: I run this: "$ ./pre-inst-env guix build -v1 -k gnome-desktop" <raghavgururajan>lle-bout: I'd not do that. W are touching gnome's many dependants. So its better to test what we change and progressively we'll be reaching gnome-desktop. Else, for each dependants we change, you gonna build lot off stuff again and again, which we won't be dealing with until the end. *raghavgururajan has no idea why they fail. <lle-bout>raghavgururajan: I would like to start doing the work you are doing on GNOME, but I feel like I lack some training or information, what were you going to do next? <lle-bout>I'll try fixing php and shepherd, nonetheless <Moosef>Does anyone have advice for adding a guix package to the guile scheme load path? I am trying to get chickadee working. <raghavgururajan>lle-bout: We'll [1] php+shepherd [2] Update the chart for GNOME 40 [3] Update packages in 'core-deps' column one-by-one [3.1] If there are patches for a package in 'wip-desktop', lets reuse it [3.2] if not, create new patches. <lle-bout>Moosef: use: guix environment --ad-hoc <guile-xxx> - command <Moosef>lle-bout: Thanks! I tried `guix environment --ad-hoc guile guile-chickadee` but when load chickadee in the repl it is still not found. Should I try something else or should I check over as #guile? <lle-bout>Moosef: this works for me: guix environment --ad-hoc guile guile-chickadee guile-readline guile-colorized -- guile -c '(use-modules (chickadee))' <lle-bout>raghavgururajan: so I found out php doesnt work with libgd 2.3.1 and later <Ikosit>Moosef: You can also just put `(add-to-load-path "/home/vherrmann/.guix-profile/share/guile/site/3.0/")` into ~/.guile <lle-bout>raghavgururajan: some things were altered in the libgd 2.3.1 version about pkg-config <monego[m]>tried to build mlpack but it ate all my ram+swap. can i offload it somewhere? <lle-bout>raghavgururajan: it may be our package that's faulty though <Ikosit>Moosef: What do you want to create with chickadee? <Moosef>lle-bout: I ran your command and my output was `no code for module (chickadee)` not sure why. <lle-bout>Moosef: your outer environment could be polluting <Moosef>Ikosit: I want to make a simple toy interface for making visualizations for algorithms. <Moosef>lle-bout: I used --pure and got the same response for some reason <lle-bout>Moosef: how do you run GNU Guix? Update to latest version maybe? <lle-bout>Moosef: that's a really interesting project! I wanted to make some framework to aid that before! <Moosef>lle-bout: Thanks! I don't really know what I am doing just though it could be an interesting way to learn guile. I installed guix today. Just ran guix pull and we will see if that helps. <Moosef>lle-bout: Got it working! I think.... Thanks for your help! <Moosef>Updating and then fixing my ENV vars <jgart[m]>If you're free and would like to package with us, just stop by :) <marusich>It's not too many. Just wait for a netsplit... <lle-bout>I worked on the blog post a little but didnt get very far <marusich>I'm working on that now, thinking about what to include <marusich>I didn't have much time between last time and now to do it, but now I have a few hours <lle-bout>marusich: I was trying to make a description of the commits made the most important ones, then describe what's left to do <lle-bout>For what's left, I was thinking mentioning go bootstrapping that must be changed from using go 1.4 to gccgo, then getting GNU Guix System to work <lle-bout>Then also talk about the fact that bootstrap binaries arent reproducible <marusich>We also need to get cuirass working - so people can make their own build farm, and so we can add a build node to ours I think <lle-bout>Basically document and centralize the links to all our discussions <lle-bout>marusich: by the way cbaines's build farm already processes powerpc64le-linux things <marusich>Yeah, a section about that would be good. I also have detailed notes about dependencies during bootstrap that might be interesting; basically I was very curious to answer the question, "What am I trusting?" as I built my release binary <lle-bout>I have a guix-build-coordinator-agent running at home, also on the OSUOSL machine <marusich>OK so it can be done. I don't know what the right configuration is for that, though; it could be interesting to produce or point to a copy that is easy for someone to adapt who has little knowledge (like me!) of how to get started w/it <marusich>I think I will take a moment to try to summarize what we did and gather interesting links. <lle-bout>I was starting to do it but now working on the GNOME upgrade <lle-bout>also have some security stuff to fix probably <lle-bout>marusich: also maybe we should also have big endian there? <lle-bout>At least the bootstrap stuff, so they can fix things if they want to <lle-bout>raghavgururajan: I fixed php, now shepherd <davidl>something interesting happened: I ran guix deploy and ended up with a couple binaries that errors out with: cannot execute binary file: Exec format error <davidl>unfortunately, one of those are sshd so I'm unable to ssh back into the system. <davidl>(the error is seen on the target machine) <davidl>virtualized machines running on intel cpu's <davidl>this is for openssh-8.5p1, I can still execute sshd for openssh-8.4p1 <davidl>and Im having the same error across reboots <pkill9>is there a way to download a substitute using e.g. wget and manually import the file ***shtumf_ is now known as shtumf
<nckx>pkill9: Sure. Substitutes aren't special, they're just nar files. See ‘Invoking guix archive’. <Ikosit>Is it possible to use Appimages on GuixSD? <pkill9>nckx: guix archive --import doesn't work with it <lle-bout>Ikosit: not out of the box because they arent actual static binaries <pkill9>i'm giving it the compressed version i think <nckx>Hm, I know I've done so in the past. Could you give me the URL, pkill9? <Ikosit>lle-bout: So, is there some way inside of the box? E.g. NixOS has the script appimage-run. <lle-bout>Ikosit: GUN Guix doesnt support not building things from source <nckx>Well, it's not a priority anyway. <shtumf>Hi, I am runing manjaro linux distro and would like to painlessly switch to GNU GuixSD, is there a tool that I can run on my machine and install GNU GuixSD from manjaro. Not the iso way, but install form another distro. Is that possible ? <nckx>Running binary blobs that is. <pkill9>distros transofmring into other distros <pkill9>though it probably only works with guix because it relies only on /gnu and /var/guix <nckx>pkill9: You're right, it won't work on non-export archives. I can't remember how I did it but I have :-/ <nckx>shtumf: There's no tool, just ‘guix system init <your system.scm> /’. It's how many ARM systems & VPSes have been converted to Guix. It does leave a lot of cruft from the old distro behind, most of which is trivial to clean up (rm -rf /usr, etc.). <nckx>s/Guix/Guix System/ to be exact. <nckx>I think it how all of the aarch64 build nodes got Guix'd. <pkill9>hmm that would have been easier than the way i did it lol <nckx>Yours already sounds more fun. <pkill9>make a vps to extract the guix iso, download extracted iso from my server to vultr, boot VPS with that ISO <pkill9>plus you could update guix before init'ing <pkill9>since you could install it as a package manager, guix pull, then guix system init <nckx>It will only complete (and overwrite your boot loader) if everything built successfully, so it should be *relatively* safe. <Mathias123>my guix daemon is sending SIGPOLL message and it restart my graphic interface in NixOS <Mathias123>when I try in VM, it just send SIGPOLL message, but in real computer, it restart my graphical interface <genr8_>the SIGPOLL is normal, the restarting isnt <nckx>pkill9: Nope, can't figure out or remember how I got Guix to import detached-signature .nars :( Sorry. But it *is* possible. I was pretty desparate. Always helps. <pkill9>it would be helpful for the large downlaods that get interrupted <pkill9>until guix supports resuming downloads <shtumf>it me again :>, what about installing GuixSD but not over existing system, but on a separate partition from existing manjaro system ? 'guix system init <your system.scm> /' so I would change / with /media/partitionForGuixSD . Any comments on this approach ? <genr8_>pkill9, cant you do guix build --substitute-urls=file:///path/to/the/thing.xz <nckx>genr8_: If it matches the (in this case ‘hello’) package your Guix would build exactly, you can. <nckx>It won't work to ‘just import this nar plz’. <genr8_>well, you can always figure out what exact .drv derivation it relates to, right ? and build that, and substitute it 1 by 1 ? <nckx>(Earlier, I was about to suggest to pkill9 to ‘just spin up a local HTTP server and use --substitute-urls=localhost...’ but I caught myself before going full unix.) <vldn>does someone know how to write a package file with a custom build system? like unpackphase tar xzvf, configure phase, edit a text file, installphase move files? someone has a good example? <cdegroot_>I'd take the simplest existing build system and take it from there. <davidl>is there any way to use time-machine in a g-exp? Say I want to run a vpn-service and in the service definition field I can specify which openvpn package to use, and I want to set it to <whatever-version-was-at-guix-commit-1234567> - is this possible? <davidl>ok, thats not a g-exp, but Im interested in whatever way you can refer to an old package from inside an OS-declaration. <davidl>without using package inherit and rolling back the commit. <brown121407>This is what I use to pin down my kernel version to the one from a specific Guix commit <davidl>brown121407: Thanks, I think using an inferior is the way to go! Since the openssh service has an openssh package to use config-parameter which is what I was actually looking for, it seems to me that the inferior example should work if adapted for openssh. <tissevert>just to be sure before spamming the mailing list for nothing: the thread about Gnome 40 is related to the issues we were discussing about NetworkManager and ibus-daemon spawned from gnome-shell, lle-bout , right ?