<apteryx>sneek: later tell civodul activation time would mean the system had successfully booted already, right? If that's true, it'd be too late: the needed bits are for the grub.cfg config of the system. Another option is to make it declarative through 'file-system', by adding, for example: (properties '(btrfs-top-level-store-submodule-path . "/root-snapshots/root-current/guix-score") <apteryx>sneek: later tell civodul this is easy to implement, but less convenient for users. <apteryx>sneek: later tell civodul it also doesn't solve the requirement to have Btrfs subvolume IDs translated to subvolume names (that'd be just unsupported with option 2). <htgoebel1>Debian testing has split this package into "cairosvg" (contaning only the main program) and "python-cairosvg" containing only the python package. <htgoebel1>Are there other packages I can take as an example? <rekado_>htgoebel1: there is no generic way to do this. Depends on the package. <rekado_>I’d start with cairosvg and then let python-cairosvg inherit from it. <rekado_>the second package would override the build system and possibly change the working directory in a build phase. <htgoebel1>rekado_: I don't quite understand. "cairosvg" would require "python-cairosvg", so how can the later inherit the former? ***jje_ is now known as jje
<desmes>I'm trying out GUIX and after installing, running 'guix pull' and then 'sudo guix system reconfigure /etc/config.scm', it takes a lot of time (more than 1 hour) to get past 'building /gnu/store/....linux-libre'. Is something wrong? <apteryx>desmes: hello! (by the way; s/guys/people/ is better form here :-)) <roptat>desmes, most likely you're building a kernel version for which there is no substitutes yet <desmes>I'm sorry, I'm not native and I thought 'guys' could also be gender-neutral hahaha <apteryx>desmes: it means there was no binary substitutes available for the kernel at the time, and it's building it locally. It's normal to take some time, dependending on your hardware. <desmes>Damn! It is compiling the whole kernel then? How can I get past this? I'm on a VM, which I guess can make this take even longer. <roptat>desmes, don't worry we won't ban you for this, you just didn't know, that's why we tell you :) <apteryx>desmes: I'm not native either, and in some areas of the world, it may be be used by both men and women, but it still isn't quite neutral :-) <roptat>maybe the substitute is available now, you can check on another terminal with "guix system build /etc/config.scm -n" (-n is for --dry-run, it won't build anything but it will tell you what will be downloaded or built locally) <apteryx>desmes: you could wait a couple hours/minutes and try again; by that time the build farm may have finished building a binary substitute for it <desmes>Thanks a lot for the information guys. I guess I can just C-c that proces, can't I? <apteryx>what has been cached/built so far will remain for the next time you run the command, speeding it up (as long as you don't run 'guix pull' again) <roptat>although progress on building the kernel will be lost <sneek>civodul, you have 3 messages. <sneek>civodul, apteryx says: activation time would mean the system had successfully booted already, right? If that's true, it'd be too late: the needed bits are for the grub.cfg config of the system. Another option is to make it declarative through 'file-system', by adding, for example: (properties '(btrfs-top-level-store-submodule-path . "/root-snapshots/root-current/guix-score") <sneek>civodul, apteryx says: this is easy to implement, but less convenient for users. <sneek>civodul, apteryx says: it also doesn't solve the requirement to have Btrfs subvolume IDs translated to subvolume names (that'd be just unsupported with option 2). *civodul needs to page that in :-) <desmes>How come when I run 'guix build linux-libre --dry-run' it says 'the following derivation would be built'. But when I run 'guix build emacs --dry-run' it says 'xMB would be downloaded'? I'm reading the documentation, and downloading substitutes is the default behaviour. Does this mean that 'linux-libre' is not on the substitute server (and that 'emacs' is)? <apteryx>desmes: that means that linux-libre is still not available from the substitute server, while emacs is. <desmes>Ok, thanks. I thought the server was down. Now I see that some packages can be not aviable. <apteryx>when running something like 'sudo guix system reconfigure my-config.scm', does all the host-side Guile program run as root? <apteryx>that'd allow for example to list Btrfs submodules by using a script generated with, e.g., (gexp->script "list-subvolumes.scm" (system* (string-append #$btrfs-progs "/bin/btrfs") "subvolume" "list" "/")) ? <civodul>apteryx: "sudo guix" means all of guix runs as root, yes <roptat>desmes, when you run "guix pull" you get the latest version of the recipes. The build farm uses guix pull (or something equivalent) to know what it needs to work on, so it always lags a bit behind <roptat>it's not an issue as long as you have enough power to build stuff locally, because of binary transparency: there's no difference between what you build locally and what is built on the build farm, they are bit-to-bit identical <desmes>I see. It guess this is just an issue for me right now since I'm running it on a VM. I' <desmes>I've never used a distro that built/compiled it's packages instead of downloading from the repos <desmes>I like the idea of having both options. <apteryx>desmes: it can be an issue on a normal desktop as well, if you use really heavy packages such as Chrome or the likes; but the build farm got much better than it used to. <apteryx>I personally try to keep my system small and simple, because I don't want to *depend* on the build farm at all times. <desmes>I will do the same. By the way, if I can build 'linux-libre' it means that I have its code. Where is my system getting the code from? The same server that lacks the compiled 'linux-libre'? <roptat>either that, or directly from the official sources <apteryx>desmes: look at 'guix edit linux-libre'. The origin field of its package record will define where the code gets pulled from and how. <roptat>(the build farm also caches sources, so you can get a copy from the build farm, or download from the location in the origin field) <apteryx>desmes: s/origin/source/ but, source usually contains an <origin> record. <apteryx>linux-libre seems rather difficult to grasp in this regard though <roptat>also there's a fallback to nix's build farm and software heritage if you can't get it from guix's build farm or the origin <roptat>you can use "guix build -S linux-libre" to get just the sources and inspect them if you want <apteryx>desmes: it uses a helper that uses the URLs coded in the procedure: `linux-libre-urls' <g_bor>I am trying to get gnupg working, but keep getting problem with agent: No pinentry. <g_bor>This is an almost bare-bones guix system install. <g_bor>I have pinentry-tty installed, gnupg installed. And I have pinentry-program ~/.guix_profile/bin/pinentry-tty in ~/.gnupg/gpg-agent.conf <demotri>g_bor: How is Outreachy going? What about that Monitoring-Idea? <g_bor>demotri: It is delayed to the next round. <g_bor>We currently have guix data service internationalization, and creating a netlink wrapper. <g_bor>Full detalis will be available from today 16:00 UTC. <demotri>So, today will the listings be opened? ***ng0_ is now known as ng0
<g_bor>demotri: the real problem is how to get the metrics out of cuirass. Once we have that, we can attach any monitoring solution. <g_bor>As currently we already have zabbix on berlin, it would make sense to get that working first. <demotri>What the article does: Call "ps" every second to get process stats for all running processes. <demotri>The article just looks at one process. <g_bor>I also have a working package for prometheus, but it is not in a shape to be upstreamed. <demotri>What WE need to do: Gather all statistics for one job. AND look at the process-tree: Connect all "cc1", "make", etc up to the guix-daemon and the starting process. <g_bor>demotri: The problem is that the daemon is a single process, we should do some internal measurement. <demotri>Simultaniousely maybe look at the logs and see at which time which build phase is running. <g_bor>One easy way to get some sane metrics would be to attach triggers on the cuirass db... <g_bor>demotri: there are two stages: once it collects build jobs, then it offloads them to build slaves. <demotri>And that is build slave is a separate process? <g_bor>It also does some ordering to minimize copying between build slaves, and blocking waiting for dependencies. <g_bor>It is a separate node completely. <demotri>But when it is done on the same machine? <g_bor>Then you can see a separate build container for each build. <g_bor>So yes, then it can be extracted from the process tree. <demotri>I was looking into it recently because my qtwebkit build was so lame. I want better substitute availability for it. <g_bor>demotri: so, it would be really nice if every relevant event would reach cuirass somehow, and then we could easily export a metrics endpoint for scraping. <demotri>g_bor: Not sure if that is the way or you better monitor the build machine while some event is going. <g_bor>demotri: yes, it might be better to distribute this to the build machines. In that case it would be nice to export the build queue events from the daemon. <g_bor>For that it would be really nice if we have the daemon in guile. <g_bor>Actually the two solution produces different kind of data. <g_bor>The original idea was to monitor ci throughput, time to delivery, so highly accumulated metrics. <g_bor>Monitoring cuirass, or the 'master' daemon would enable us to do that. <g_bor>From the operational point of view, for example to identify bottlenecks the per-build-node monitoring would be needed. <demotri>g_bor: :-) I was trying to reproduce it in my VM, but I haven't used it for a long time. It's still updating. At least now it will be on a decent state :-) <g_bor>It is noce if you will have an a uptodate vm. <g_bor>I am doing this on an experimental system, where guix-home-manager is installed, which brings a lot of ther problems to surface <g_bor>Some programs really don't like a read-only home. <desmes>I'm reading the 'guix system' documentation. The 'reconfigure' command should always be invoked using 'sudo' and the 'etc/config.scm' file, shouldn't it? This is the default location for the system config file? <civodul>desmes: if it doesn't run as root it won't be able to perform the actual reconfiguration, indeed <civodul>the config file is usually in /etc/config.scm, but that is entirely up to the user <g_bor>what timezone should I specify in the blogpost? <g_bor>I have seen a simple time there. Should that be in UTC? <apteryx>g_bor: UTC seems as fair as it can be ;-) <demotri>desmes: I have for example a git repository where I store all my systems configs in. In that way, I can compare them, can have a history and might go back to an older config. <demotri>desmes: As a normal user, you can still do "guix system build my-config.scm" to build the system. Only to really "guix system reconfigure" you need root. <desmes>demotri: isn't something like this implemented by default? With the rollbacks and all this (similar to git) <demotri>desmes: AFAIK, it doesn't store the system-configuration. And even if it does: A rollback and a gc would destroy it. In git, it is saved "forever" (and can be shared/pushed between hosts). <desmes>demotri: You are right, for the system config file, it seems like git has more functionality than the default generations managing. <desmes>By the way, can I use (on another terminal) 'guix package' or even 'guix pull' while guix system is getting reconfigures. I suppose I can (?). <g_bor>do we not have at packaged, or is it hidden somewhere? <civodul>g_bor: like i said ealier, you can use CEST <civodul>let us know when it's posted so people can spread the word <g_bor>ok, I will do it at 16:00 UTC, like they asked us. <desmes>I have an error, running 'sudo guix system reconfigure /etc/config.scm' for the first time (after running 'guix pull'). This one: 'build of /gnu/store/...guix-1.0.1...drv failed'. I've runned the command a couple of times and the same error keeps popping out. What can be happening? <roptat>desmes, you probably have a log somewhere, guix should have told you the location of the log file in bold <roptat>you can use bzless on it to see its content <desmes>I'm looking at it and I can't figure it out to be honest. There seems to be a problem here: 'ice-9/eval.scm' <desmes>Somewhere inside the '...module-import...' in /gnu/store <desmes>Is there a way to copy it to the clipboard though? <civodul>desmes: you can open the log file in an editor and copy from there maybe? <demotri>desmes: You can use bzcat to uncompress it and then use "Browse file"? <roptat>it's probably the easiest solution from your VM <desmes>damn I don't even have VB guest additions installed in this machine. I can't use the clipboard nor the shared folders hahaha <desmes>I'll continue in the night. Thanks a lot everyone for the help with setting this new machine <sirmacik1>hey guix! anybody has working config to read variables from guix profile in eshell? <truby>is there a quick and easy way to install emacs with lucid instead of gtk? the daemon crashing bug gets me every time :-( <truby>I know I can write a new package that inherits from the emacs package and replaces the inputs and configure flags, but that feels heavy <roptat>--with-input=gtk=lucid or something maybe? <truby>Huh, I think that might have worked, but I am not sure I can actually tell :-) can I find the build log for the thing I just installed somewhere or does it get deleted on success? <roptat>you can rebuild it with guix build --check and set verbosity level to 2 <truby>that just seems to apply some grafts and then tell me it's done <truby>--no-grafts seems to fix that <truby>ok, yeah that did make it build with lucid :-) (--with-input=gtk+=libxaw was the right combo) <truby>roptat: thanks for the help! <quiliro>Minall: Mi iros al la laborejo hodiaux kun Giksa Sistemo kaj Freedombone-o. <quiliro>Minall: Mi ekiras en 10 minutoj kaj eniras en 60 minutoj pli. <g_bor>The Outreachy blog post is now pushed. <g_bor>It should be picked up soon. <gugurumbe>Hello guix! In the other distro that I use, gnulib is packaged and I can call the gnulib-tool program. I could not find such a package on Guix though. Did I miss it? The gnulib website says that there are no releases. Would it be possible to package it though? <rekado_>gugurumbe: gnulib is supposed to be copied to whichever project is using it. <bavier>gugurumbe: right, see the gnulib manual <bavier>but I suppose having a package in guix might be kinda nice. <gugurumbe>Sorry, this is quite confusing: let's say I develop a program P, which uses stddef_h from gnulib. There are 2 repos: the one for P, and the one from gnulib. I do: gnulib-tool --import stddef in P. I get m4/stddef_h.m4 (I don't know if that's the exact file name but whatever). Should I check in m4/stddef_h.m4 in P repository and update it before each commit? This looks like a very bad idea, because the files would make unneces <gugurumbe>sary conflicts between different computers and managing updates would be very difficult. Are we talking about this or is there a misunderstanding? <count3rmeasure>hey all, just saw the outreach intern announcement on twitter and when I checked the page I got 404s on a couple of the links, just fyi <gugurumbe>Because I did not see anything about this in the manual. But maybe I missed it, of course <truby>would it make sense at all to change the ld-wrapper script to take the linker you want to wrap as an environment variable? (or behave the current way if an environment variable isn't provided) ld.gold and ld.lld take the same linker options as ld.bfd so it'd make these usable in gcc-toolchain environments, which would be pretty nice <count3rmeasure>rekado_: I mean, I'm just trying to help. I cut and pasted directly, so....? <count3rmeasure>I thought it looked wrong too fwiw, but those are the links embedded in the relevant anchor elements off of the guix page itself <rekado_>count3rmeasure: I don’t know where these URLs come from or who published them. I only see that they are wrong. We have no control over the Outreachy website. <rekado_>can you please show me where that is? <rekado_>these must be internal URLs for use by the coordinator <rekado_>I’ll see if I can update the blog post <rekado_>g_bor[m]: could you please take a look at this? <count3rmeasure>to be honest, I do this, report broken links whenever I find them, and this the literally the first time anyone has even bothered to respond so....*shrug* <rekado_>g_bor[m]: I also see that only one of the projects ended up getting accepted, so perhaps the blog post should be amended. <rekado_>g_bor[m]: never mind, I just saw the second project <rekado_>count3rmeasure: I’ve replaced the broken URLs in the post, but it may take a little while before the online version is updated automatically. Thanks again for the report! <rekado_>hmm, you know, it may be that this is really just an Outreachy timing problem. <rekado_>their website says “Applicants cannot see the project details linked below until the contribution person opens on Oct. 1, 2019.” <rekado_>don’t know what that means, but the URLs it refers to were those used in the blog post <g_bor>rekado: thanks for fixing the blogpost. <g_bor>I believe that the urls should be public by now, but they had a typo. <count3rmeasure>so I'm in the middle of trying an install in a virtualbox vm and whoa, this is alot easier then I was led to believe <g_bor[m]>count3rmeasure: nice to see that this is going well. <count3rmeasure>g_bor: I'm really excited, I've got a project right now in guile that will benefit enormously from intergration with guix, so this is nice to see <count3rmeasure>well done to all of the developers who've put in time to make this what it is <count3rmeasure>I'm using the guile api for gdb to automate aspects of checking exploitability when presented with a vuln <count3rmeasure>I'd like to see how much the presence of a lisp, i.e. a lang with full macros, makes program analysis easier <count3rmeasure>given guiles outstanding C lang interop I'm able to script on top of libraries like z3, a SMT solver with a datalog engine, and capstone, a disassembly library <count3rmeasure>what I realized recently is that guix will allow me to programmatically integrate multi-version testing into the framework <sirmacik>how looks guix support for wayland and sway, anybody using it and capable of sharing ones config.scm for that? <count3rmeasure>depending on how fast the development goes I'll also be able to create some fuzzing primitives in C, scripting it in guile, and then integrating that with guix for the aforementioned versioning <rekado_>sirmacik: I’d be interested in that as well! <rekado_>sirmacik: this would be a great little addition to the Guix Cookbook, I think. <g_bor[m]>sirmacik. (@freenode_sirmacik:matrix.org): <count3rmeasure>g_bor: do you know anyone who has extant guile scripts for gdb? Like, I've looked pretty extensively, asked on irc and the mailing list, searched github, I've turned up literally one project that wasn' <g_bor[m]>sirmacik (@freenode_sirmacik:matrix.org): i have something along these lines. Also i did not use gdm, just start it from the command line. So most of the config is in dotfiles. <gugurumbe>Sorry to bother you again, but how do you run a container? When I try LANG=C guix environment --ad-hoc --container guile, I get guix environment: error: mount: mount "/gnu/store/zzakf905mzla4csi1dn9qpcwmgbxj29b-bash-static-4.4.23" on "/tmp/guix-directory.TvMwuT//gnu/store/zzakf905mzla4csi1dn9qpcwmgbxj29b-bash-static-4.4.23": Operation not permitted <count3rmeasure>wasn't even functional. It kind of threw me for a loop, honestly. Like, why is no one using these bindings? I get the ubiquity of python (and learning curve) but I've been fairly surprised that no one seems to be using these bindings, at all, after 5 years <sirmacik>g_bor[m]: can you share your config.scm fot such setup? <sirmacik>I'd love to see that and experiment a little <sirmacik>I have sway autostarted if I login via tty1 <cbaines>gugurumbe, given it ways not permitted, I wonder if the same command works as root? <g_bor[m]>sirmacik (@freenode_sirmacik:matrix.org): i am on mobile right now. I will share something once I get to my machine. I will leave you a message here with a link. <gugurumbe>If I run the failing mount command as root, I get: <gugurumbe># LANG=C mount "/gnu/store/zzakf905mzla4csi1dn9qpcwmgbxj29b-bash-static-4.4.23" "/tmp/guix-directory.Qe72yU//gnu/store/zzakf905mzla4csi1dn9qpcwmgbxj29b-bash-static-4.4.23" <gugurumbe>mount: /tmp/guix-directory.Qe72yU//gnu/store/zzakf905mzla4csi1dn9qpcwmgbxj29b-bash-static-4.4.23: mount point does not exist. <g_bor[m]>The blogpost still looks broken to me. I will have another take with it today. <gugurumbe>But I guess those intermediate directories were cleaned by guix <mbakke>gugurumbe: which distro are you on? <cbaines>gugurumbe, well, that's slightly different. Does /tmp exist, and do you see any guix related directories inside of it? <demotri>g_bor[m]: Yes, broken links. Otherwise, looks fine to me. <mbakke>gugurumbe: you need to enable "user namespaces" in your kernel for Guix containers to work. <mbakke>gugurumbe: try "sysctl kernel.unprivileged_userns_clone=1" <demotri>I got a 404 on yours. Probably they are just available if you are logged in as Mentor? <demotri>g_bor[m]: No problem. Will leave now. Good bye. <gugurumbe>Do I need to reboot? I have the same error for both user and root <mbakke>gugurumbe: whoops, try 'sysctl -w kernel.unprivileged_userns_clone=1' (note the -w) <desmes>Does anybody know how to install the dependencies of a package. I know how to look at them, e.g. with icecat: guix package --show=icecat <desmes>But I dont know how to install them automatically <gugurumbe>With my guix environment hammer, I would say: guix environment icecat --dry-run <desmes>gugurumbe: I still dont know how to use guix environment. I will have to look at that in the future. I just want icecat to be able to run youtube videos <gugurumbe>I don't know many things, sorry :) Why do you think that installing the dependencies would help? <sirmacik>what are the chances of guix gaining luks2 support? <rekado_>sirmacik: it’s just that nobody has identified what really is missing <rekado_>perhaps it would be enough to tweak the generated initrd a little <rekado_>so, for luks2 I suggest checking this: a) are all required tools available in Guix? b) how are we mounting a LUKS encrypted root file system right now? c) what would need to change to support LUKS2? <rekado_>if you can answer some of these questions it would be great if you could send your results to bug-guix@gnu.org so that we can keep track of this. <rekado_>a random Debian page I found about LUKS2 says that GRUB does not support the LUKS2 format yet. <rekado_>I guess this would need to be checked first: does any version of GRUB support unlocking a LUKS2 container? Do we have that version in Guix? <sirmacik>rekado_: it supports luks2 just fine, I have it right now on arch <sirmacik>yes, but not before 14th of oct though >: <sirmacik>hm why cryptsetup in guix is in so ancient version? :o <nckx>sirmacik: Because you haven't updated it yet? :o) <nckx>(Probably because it ‘just works’, once people get LUKS to work they don't really care about newer cryptsetup, and last time I wanted to update to 2.x GRUB support was still iffy.) <sirmacik>I need to get better at writig guix packages <nckx>Arch likes to patch stuff. Maybe they patched GRUB. <janneke>hmm, we have debootstrap and fakeroot...but no fakechroot? <nckx>The Arch Wiki also explicitly says GRUB doesn't support LUKS2. <sirmacik>I don't know if I'm too tired or what but i just realized I have systemd-boot not grub on this setup... <nckx>This all jives with my previous research. <nckx>I'm as disappointed nothing has progressed in the past year as you… <sirmacik>but it would be nice to at least to read luks2 partitions <nckx>Sure. It just explains the lack of ‘packaging pressure’. *nckx 's giving packaging cryptsetup-2 a whirl just to see what happens. <dongcarl>sneek: later tell civodul I'm sorry I didn't respond to your email fixing the store-error-protocol, but everything seems to be working alright now :-) Thank you! <c0c0>on the try-out qemu image version of guix, i can run "guix package --list-profiles", whereas on a freshly installed guix on another machine, running the same command results in "guix package: error: list-profiles: unrecognized option". i don't get it. what am i doing wrong?