<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.
<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.
<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>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.
<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>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
<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: 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: 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?
<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
<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> Create a thread in email@example.com with the subject "GNOME 40"  Create a git branch with the name "gnome-40" (somewhere), where we can both push to and work together.  Once we have commits ready to be merged, we'll generate patches of them and sent it to the email thread.  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>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>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>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>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
<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?
<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.
<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  php+shepherd  Update the chart for GNOME 40  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.
<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>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
<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>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.).
<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
<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 ?