<pkill9>wow, my script to run downloaded binaries worked with the blender bundle <reepca-laptop>The order in which imported modules get compiled is depth-first based on a scandir, meaning we compile leaves first in ascending alphabetical order. If I understand correctly, we need to compile higher-level modules before the stuff they depend on. Since we try to make it so that modules in subdirectories never depend on stuff at a higher level, would it work to just switch to breadth-first compiling (first compile all the leaves of <apteryx>mmh? Why is `guix lint python-request' using more that 2.5 GiB of RAM, computing its derivation? <apteryx>ah, no, it seems to be with my updated version only... Maybe I've introduced a circular dependency or something? <apteryx>interesting, the problem occurs when adding the propagated input: ("python-urllib3" ,python-urllib3) <apteryx>yep, even just 'guix lint python-urllib3' triggers it... :-/ <jackhill>apteryx: yikes! I have no real advice, but wow. Also, thankes for you work making the importer better ☺ <apteryx>I had not touched an importer yet, so it was interesting to discover how things were wired <apteryx>regarding the circular dependency with python-urllib3, seems to be a problem on my side (maybe one of the patches I have on my stack, adding some Python dependencies), as I can't reproduce using my 'guix pull'd' guix. <apteryx>OK, figured out the circular deps caused by adding python-urllib3 to python-requests: urllib3 -> cffi -> sphinx -> requests // requests -> urllib3 <apteryx>it's unfortunate, since sphinx is only used as a native dependency of cffi (build time only). I'm not sure how to fix this. <apteryx>I could make a 2nd requests package derive from the original requests, but that seems a ugly hack <mbakke>apteryx: The requests<->urllib3 cycle is solved on the staging branch. <apteryx>mbakke: oh! I'll have a look! thanks <apteryx>mbakke: are you referring to commit 85ef07c4b278200db7c396f4021146916588f2fb? <apteryx>The dependency cycle I'm talking about seems to be caused by: urllib3 -> cryptography -> cffi -> sphinx -> requests, which this commit doesn't seem to address? <apteryx>or maybe I'm misunderstanding (I've grepped the output of 'guix refresh --list-transitive' for requests in the dependencies of urllib3 to arrive at that conclusion). <apteryx>I'll try the fix and see if it works! <apteryx>I'm still having the cycle... so my conclusion might be good. <apteryx>(after cherry-picking 85ef07c4b278200db7c396f4021146916588f2fb to master) <efraim>it turns out lynx has gopher support, are there other CLI clients still around? <efraim>actually, according to wikipedia, elinks and w3m are two others, but links isn't <calher>Is there any way to port CWirc to Guix? It's huge plugin, nearly an entire program, that relies on an old version of XChat. <Blackbeard[m]>(define (equivalent-narinfo? narinfo1 narinfo2) "Return true if NARINFO1 and NARINFO2 are equivalent--i.e., if they describe the same store item. This ignores unnecessary metadata such as the Nar URL." (and (string=? (narinfo-hash narinfo1) (narinfo-hash narinfo2)) <Blackbeard[m]>I am sorry I haven't done my proposal earlier I had a few family issues <Blackbeard[m]>Longer-term, binaries could very well be downloaded from a content-addressed store such as IPFS orGNUnet without having to forego our existing infrastructure. Peer-to-peer distribution of binaries has been on our mind for a while, but we hadn’t quite realized this decoupling and how it would allow us to support a smooth transition. <efraim>I just got my invite email to buy a pinebook 11", but I need to convince my wife I should get it <efraim>Any suggestions on why I "need it"? <civodul>efraim: i guess you've already thought about "because it's sooo coool", right? :-) <civodul>and it would allow you to do... things <civodul>things you can't really do right now <civodul>these all sound like pretty compelling arguments to me <efraim>I even said it would let me do Guix things <efraim>I should ask vagrant about the pinebook bootloader we have in guix <civodul>i think vagrant got the system running on the pinebook, no? <efraim>Travel laptop would be a good use <kmicu>Guix on Pinebook is the latest fashion hit. <kmicu>(So naturally buying it is justified.) <efraim>i'm building pine64-plus-installation-os ATM so I can see (for real this time) installing Guix System on my pine64+ <civodul>roptat: i think we should send a new tarball to the TP soon, WDYT? <civodul>i'd like to update the keyboard layout bit for Xorg, to simplify it <civodul>but other than that, i think the manual and everything is ready to get translated <civodul>gdm downright ignores the XkbLayout setting grrr <civodul>maybe we should mention IBus in the "Keyboard Layout" section <rekado>we can’t configure IBus through the operating-system configuration. Is this a problem? <civodul>i don't like it, but OTOH it provides a great UI <civodul>and concretely, people using GNOMish things are going to use IBus <efraim>I forgot how long it takes to build the kernel <roptat>I don't use gnomish things, so I'd like to have a way to properly hand keyboard layouts <roptat>doesn't gdm have some configuration for that? <roptat>civodul, it doesn't :/ but the internet seems to say that we should use "localectl", which is a systemd thing that changes /etc/locale.conf and /etc/vconsole.conf <roptat>so maybe we should create these files? <civodul>so i'm trying to see whether we're doing something wrong <civodul>it's funny: GNOME code now inherits that property from JS that errors are silently ignored <civodul>(one of the original design goals of JS) <wednesday>civodul: for me the operating-system keyboard-layout gives errors, bootleader keyboard-layout leaves me with no keyboard, and I think the whole update broke sddm because it starts with no x config now, that's what I've found out about the whole keyboard thing heh <civodul>wednesday: ouch, could you email bug-guix@gnu.org with all the details? <civodul>i suppose one bug report for the bootloader, and another one for sddm <wednesday>I'll see if I can do that later, will probably half brick my system getting logs again heh <civodul>perhaps you can reproduce it with 'guix system vm'? <efraim>civodul: I have more time to think about the pinebook, but other than running Guix System on it, it doesn't seem very different than using my powerpc laptop (which has working wifi) <wednesday>maybe, I'll give it all a go in a few minutes <civodul>the good thing with JS in GNOME is that you get warnings and errors with precise line and column numbers <civodul>the bad thing is that there's no file name <efraim>still using the original 60GB HDD, haven't gotten around to taking it apart to put in an SSD <efraim>and I figure with either one I'd be running 'ssh -X other-machine web-browser' which is always the oversized program <efraim>Thinking out loud, I need to check if it's even a SATA slot ***dddddd_ is now known as dddddd
<wednesday>civodul: well the vm gives me some error about mounting /dev/vda1 (unknown file) so I might just go down the route of messing around on my pc again ha <ArneBab>when trying to build gdal with Python support, I get the error "error: unknown type name '__gnuc_va_list'; did you mean 'va_list'" <ArneBab>(this is a local build, because it’s faster to debug than adjusting the guix recipe) <civodul>ArneBab: perhaps a missing <stdarg.h>? <wednesday>civodul: pretty sure that was just because i didnt have the right initrd modules because it boots now, but the vm skips the bootloader and fails loading x heh <civodul>stackoverflow is worth a look today :-) <shcv>what's the process for changing the hostname? <shcv>I have it in /etc/config.scm where it defines the operating system as described in the installation instructions <roptat>shcv, change it there and reconfigure <shcv>roptat: what about adding user accounts? Should that be done by reconfiguring the system, or through normal useradd-type commands? *jonsger tries to package an OSM desktop app... <shcv>also, I was wondering about how to package the caddy server (https://caddyserver.com/), which supports plugins by importing go modules. What's the right way to make a modular package, instead of requiring everyone who wants to install it to repackage it themselves with a different set of plugins? <shcv>(importing them before building the server, that is) <roptat>usually, that is done with environment variables <roptat>does it use a PATH-like variable to find its plugins? <roptat>shcv, you can find an example in gnu/packages/ocaml.scm for instance : the ocaml package defines native-search-paths to have users define OCAMLPATH in their environment <roptat>I think you'll have to package the server and its plugins as separate packages, then it's only in the service definition that you'll be able to plug them in <roptat>if you take a look at the postgresql service, that's what we do <shcv>but does the service definition build the service? <shcv>ok, I'll look at postgres then <roptat>in the posgresql case, we build a new package that's the union of postgresql and the plugins that were defined by the user <roptat>and we start postgresql from that new package <shcv>sounds about right. Though I'll have to inject the deps into the run.go file <roptat>can you build the service and its plugins as separate packages, and then build run.go separately? <roptat>any package defined in the services will not be built by the build farms, so we don't want it to be too resource intensive <shcv>I rather doubt it, but I haven't tried. Fortunately most of the modules are small, and golang builds pretty fast <efraim>linux-libre@5.0.5 FTBFS on aarch64 <jlicht>I think this might not be possible at this time, but does anyone know how to build arm software using x86_64 binary guix on top of a different distro? I seem to recall this working really well using the binfmt service, but don't really know how to have my current guix-daemon do something similar <jlicht>(as in, I already had this working some time ago on a Guix System machine, but I want to do the same thing on a non-Guix System system) <efraim>perhaps `sudo qemu-user-armsomething ./pre-inst-env guix-daemon --build-users-group=buildsomething &' to run the daemon and similar for the build? <efraim>is there a way to create a custom kernel with just the modules I need without including a whole kernel config? <efraim>I want to do something similar to the %default-extra-linux-options of gnu/packages/linux <jlicht>efraim: meh, seems to not do what I want it to. I'll try something else, but thanks for the pointer anyway :-) <ArneBab>sneek: later tell civodul: no, it’s during configure and stdarg is included. <jlicht>I figured it out; simply adding the right directories to guix-daemon via --chroot-directory=/usr/arm-linux-gnueabi and adding qemu-arm-static to the chroot seems to allow me to build armhf stuff using guix on a foreign distro :D <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, ArneBab says: no, it’s during configure and stdarg is included. <vagrantc>can GDM in guix do wayland sessions yet? <vagrantc>alternately, how would i enable desktop services, but disable start of a login manager? e.g. logging in via the console and running sway <vagrantc>i'm able to do that by "herd stop xorg-server ; exec sway"