IRC channel logs


back to list of logs

<atw>apteryx, efraim: thanks to you: !
<pkill9>wow, my script to run downloaded binaries worked with the blender bundle
<reepca-laptop>sneek: you around? botsnack
<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
<reepca-laptop>this node, then recurse into subdirectories)?
<apteryx>atw: cool!
<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>no problem, it was fun :-)
<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)
<apteryx>(and 89ccd9f3ba)
<kristianpaul>quiliro: algo, me interesa el software defined infra
<quiliro>kristianpaul: como es eso?
<apteryx>mbakke: I have a fix for it :-)
<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.
<civodul>Hello Guix!
<Blackbeard[m]>civodul: hello ٩(◕‿◕。)۶
<Blackbeard[m]>civodul: ping
<Blackbeard[m]>this is the code you told me to check right?
<Blackbeard[m]>substitute.scm\scripts\guix - guix.git
<Blackbeard[m]>and I think
<civodul>for a start you can look at the HTTP API, which is briefly describe towards the end of <>
<Blackbeard[m]>I should understand how NARINFO works
<civodul>(search for "wget")
<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]>civodul: oh ok thanks ٩(◕‿◕。)۶
<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.
<Blackbeard[m]>civodul that would be so awesome ^
<Blackbeard[m]>that is awesome
<Blackbeard[m]>I want to start a project
<Blackbeard[m]>where lawyers can write law suits to help non profits
<Blackbeard[m]>but maybe I am dreaming too much
<Blackbeard[m]>like arguments that can be used in most of the world
<Blackbeard[m]>no matter what jurisdiction you are on
<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? :-)
<efraim>I tried that
<civodul>hmm, i see
<efraim>and the it's only ~$100
<efraim>and it's easy to carry around
<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
<civodul>oh yet another incentive
<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>I think so
<roptat>hi guix!
<efraim>Travel laptop would be a good use
<efraim>I wonder how free the wifi is
<efraim>Kdeconnect into kde.scm?
<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?
<roptat>I agree
<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
<civodul>rekado: WDYT?
<rekado>we can’t configure IBus through the operating-system configuration. Is this a problem?
<civodul>yes and no
<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
<civodul>so it's definitely on topic
<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>roptat: says that xorg's config should also be honored
<civodul>so i'm trying to see whether we're doing something wrong
<civodul>looking at .js files...
<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)
<roptat>good luck :/
<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
<wednesday>works fine for slim thought
<civodul>wednesday: ouch, could you email with all the details?
<civodul>i suppose one bug report for the bootloader, and another one for sddm
<civodul>we'd rather fix this!
<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>efraim: you have a ppc *laptop*?
<efraim>civodul: an iBook G4
<efraim>upgraded to 1.5GB of ram
<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
<civodul>wednesday: hmm that's weird as well
<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>do you know what I’m missing?
<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
<roptat>you don't need anything else
<shcv>roptat: what about adding user accounts? Should that be done by reconfiguring the system, or through normal useradd-type commands?
<roptat>through reconfiguring too
*jonsger tries to package an OSM desktop app...
<shcv>also, I was wondering about how to package the caddy server (, 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
<shcv>roptat: you have to add a separate import line in the main source file to get it to use the plugins, usually as a reference to the git repository, though the code does get downloaded and added to the GOPATH:
<roptat>that is... bad
<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?
<roptat>it can do anything it wants
<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
<efraim>my mouse turned invisible :/
<jlicht>hi guix!
<wednesday>who needs a visable mouse
<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>I haven't tried it yet
<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.
<sneek>Will do.
<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
<civodul>jlicht: living dangerously :-)
<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"
<jlicht>civodul: heh, most likely :P