<Rovanion>Is there a way to use a python projects requirements.txt as an input to a Guix package definition? I have an existing project made by a friend here, and I would like to as unobtrusively as possible use Guix as the package manager when trying to develop in it.
<baryluk>lfam: I would check for example wget. It responds to resizing pretty well. Not sure if it listens to SIGWINCH, or check stuffs every time it tries to update it, but it manages to remove the previous progress in most of the cases.
<baryluk>In my tests, guix, would produce a enormous triangle of #s in terminal after resize :D
<mbakke>Derp, I made a thinko in the ungoogled-chromium update, so now it will always use 8 parallel processes at the final linking step. Will fix at the next update, I doubt it makes much difference in practice.
<roptat>alright, I can parse all of the hundreds of Android.bp in android sources now :)
<chipb>I used puppet as comparison intentionally. ansible is inherently sequential. puppet is sequential in that it applies changes in some order, of course, but to get a defined order you would need to notate that ordering.
<nckx>Guix Deploy is your robot buddy with a flamethrower.
<chipb>I...think I recall propellor being similar in that regard.
<chipb>nickdaly: of course, I don't know if that analogy is helpful to you. :-)
<euandreh>Regardless of the order, it is still way more stateful that Guix. There was a nice talk on NixConf 2019 (I think) that someone categorized things like that between convergent, declarative and X configuration manager. I liked the terminology, I'm searching for it now
<chipb>yeah, it builds a full system snapshot then switches to that atomically. it kindof needs some sense of distribution support to do.
<chipb>guix/nixos aren't the only way to do that, but they're ones I happen to like.
<euandreh>It only needs to own the full tree of packages it will use, so it can have full agency over them
<chipb>you could do something similar with another distro by mashing it with ostree.
<apteryx>interesting problem; I'm trying to set "-DCMAKE_CTEST_ARGUMENTS=-E expensive -L -tests?-" as the #:configure-flags argument, but it gets expanded as '...bin/ctest --force-new-ctest-process -E\ expensive\ -L\ -tests?-' when it gets run. CMake doesn't seem to like the escaped spaces.
*vagrantc will follow-up to the parallelism bug too
<PotentialUser-49>hello everyone, just installed guix on this laptop here and following along the (absolutely excellent) manual, and "time guix install emacs-guix" reports 2m29s. Is this typical performance of the package manager or am I doing something wrong? It seems to download a package and then sit a while, download another, sit a while, etc. in a very sequenti
<baryluk>nice indeed. hope you can enable it for more archs later. just for guix, even if there is no repos for it, and probably bugs here and there to support it ;D
<wleslie>ryanprior: is the circular dependency anything like hurd, where the cross compiler requires headers from hurd and gnumach, but you can't build hurd without the compiler?
<vagrantc>baryluk: well, they'll need support in upstream guix before adding more ... arm64/aarch64 doesn't build on debian because guile-gnutls with guile-3.0 didn't successfully build for arm64
<ryanprior>wleslie: I don't think it's that tangled. Basically these two packages want to have the others' source at build-time. So practically speaking it's one package source, but with split names, outputs, metadata, upstream repo, etc
<db48x>ryanprior: why not just make a single package then?
<ryanprior>Because then users would need to know about the relationship between the packages, which I don't know how you make that discoverable.
<ryanprior>For example, the go package apex/log depends on tj/go-kinesis. If you want one, there's no reason you'd search for the other or assume any relationship. Many apex/log users will probably never use kinesis.
<ryanprior>But yet there is a relationship between those packages where in order to build either one you need the source code for both.
<Rovanion>leoprikler, baryluk: If the package is not in pypi but something unpublished? Is there anything that can help me there?
<xelxebar>Is there some baked-in way to check the word size of a build target machine? I need to do different build steps depending on whether it's 32- or 64-bit
<wleslie>is there a way I can get host /usr/bin/glxinfo and .guix-profile/bin/glxinfo to agree on available features?
<civodul>not sure why though because the freetype change looks right to me
<civodul>efraim: could you explain how to reproduce what 34a6f123514b5677d442ed7cd609ff01534904b8 is fixing?
<efraim>it uses the BUILD_FREETYPE vars for compiling build-grub-mkfont, but only under certain circumstances. I thought i was being clever with (or native-inputs inputs) but apparently I was too clever
<efraim>I suppose we could just add freetype as a native input when its (%current-target-system) for mips64el
<civodul>mothacehe, cbaines: by looking at Cuirass, i wasn't able to tell when the "childhurd" test started failing
<efraim>haven't tried natively compiling grub on mips64el yet to see if it still builds correctly
<civodul>ideas on how to get that info, either from Cuirass or the Data Service?
<efraim>right now I'm the only user of grub for mips64el, so either it was building natively fine before and should continue, or it wasn't before, worked with my patch and might break again when only adding it for cross compiling
<cbaines>civodul, at the moment, the Guix Data Service doesn't have build information on system tests. Cuirass is building different derivations to what's associated with the system test, and I haven't got an instance of the Guix Build Coordinator building them yet
<efraim>we could just add it for (or (%current-target-system) (%current-system)) mips64el-linux
<cbaines>but I'm hoping to start building system tests soon
<nckx>vits-test: Because it's the right thing to do. Imagine you ran ‘guix install emacs-no-x’, then one day ran ‘guix upgrade’ and Guix silently replaced it with the full emacs. Wrong, right? Transformation options are the same: ‘guix install --with-debug-info emacs’ installs a different package from than ‘guix install emacs’, and Guix now remembers that fact. So this change actually fixes --flags and you should use them more often now 😉
<civodul>mothacehe: on berlin, we just consumed 400G in /gnu in 2h
<nckx>vits-test: This sounds a bit like an X-Y problem to me personally. You were counting on a bit of a bug: a small part of your profile was less permanent than it should have been. But ‘guix install’ is supposed to be permanent. Use environments if you want Guix to do your forgetting for you, and get that ‘clean’ feeling when you exit.
<nckx>vits-test: What else did you think it applied to? (Curious.)
<nckx>Oh, I think I know. No, ‘guix install --with-debug-info emacs’ won't set some magic horrible state flag somewhere that suddenly makes any mention of ‘emacs’ on the command line the debug-emacs.
<mothacehe>civodul: terrible. It would be nice to have a breakdown of those new store elements. I guess most of them are images related to system tests.
<civodul>mothacehe: yes, we could check cuirass.log actually
<civodul>yeah, partition.img (many of them!), image.iso, qemu-image
<mothacehe>Yes, or extract it from the database. Even though we save those items only as nar files, it will still take a lot of space.
<civodul>in fact, looking at that log, it looks as if Cuirass builds nothing but images
<wleslie>gcc is looking for system headers in /gnu/store/*-capos-newlib-*/include, but newlib has placed them in /gnu/store/*-capos-newlib-*/i386-unknown-capros/include. is there a nice way to chop off the /i386-unknown-capros folder in the output?
<leoprikler>wleslie: passing some #:configure-flags hopefully, otherwise patching the build system
<wleslie>I've been making guesses about what configure flags might chop it based on the configure file and makefile templates, but no luck yet
<wleslie>I currently have --with-sysroot=/ and --with-target-subdir=.
<wleslie>tbf it might be worthwhile overriding the default gcc configure flags myself
<mroh>I try `guix deploy` for the first time and it looks like the target machine doesn't like my initrd. Perhaps, a skip-checks? (and maybe no-bootloader?) boolean in the machine-ssh-configuration would make sense?
<pineapples>Hello Guix. Today I've got a peculiar error during guix reconfigure: "File system check corrected errors on /dev/sda1; continuing" and "In procedure mount: "mount /dev/sda1 on ///boot/efi: Device or resource busy". Running the command again yields a similar result, but the "File system check corrected errors" message is gone. Is this possible that the file-system-/boot/efi service could corrupt the ESP?
<PotentialUser-68>hello. i hate to ask this, because i respect the mission, but can someone point me to resources on how to run the vanila kernel instead of the libre kernel, firefox? life and family dictate how much friction I can permit, i have to pick my battles and start somewhere...
<PotentialUser-68>unrelated and silly (new here), if i just want to update the system, do i run `guix pull` and reconfigure with sudo or as the logged in user? it seems to permit both?
<mbakke>PotentialUser-68: that blog post is good if you want to run a custom kernel indeed
<mbakke>PotentialUser-68: you can reconfigure either as root or through sudo, you choice :-)
<dissoc>PotentialUser-68: that's a starting point of doing it yourself. however there are already packages to do what you are asking. you just have to add a channel (and verify the code). probably path of least resistance if you're just taking guix for a test drive
<PotentialUser-68>mbakke: what is the difference between reconfigure as root vs user? thats the confusing part for me
<mbakke>PotentialUser-68: with sudo, reconfigure will use your users guix (the one you get with 'guix pull'), but when you are logged in as root, it will use the root users guix (i.e. you need to run 'guix pull' as root to get the latest code)
<mbakke>PotentialUser-68: the difference is in what 'guix describe' says for each user
<PotentialUser-68>dissoc: im in for the long haul, with either nix or guix, because I am throroughly sick of the dependency hell that has been my career, etc etc. im not too concerned with initial time investment, but not having hardware support and not having a "standard" browser that i can use to do my job would just nudge me toward nix. i do prefer guix conceptua
<PotentialUser-68>lly, the declarative language part of nix im not too keen on (seen it fail too many times) and i actually care about GNUs mission quite a bit, im at that point... just have to pick my battles as i said. im ok invensting time into doing the kernel on my own because i will learn a lot and get a true sense of the system/package manager. in other words
<lfam>Great :) Please feel free to keep asking questions!
<euandreh>PotentialUser-68: There's also the very good qutebrowser, other than the frequently mentioned icecat
<lfam>PotentialUser-68: Another bit of advice on this subject. The way that Guix does things "per-user" is by setting up some environment variables when the user logs in. This means that, if you want to elevate privileges to use a feature of Guix, it's important to elevate in a way that creates a login shell. That means `sudo --login` or `su --login`
<lfam>But, if you wanted to reconfigure using your normal user's view of Guix, you'd want to preserve that user's environment, and so you'd use `sudo --preserve-env`
<PotentialUser-68>euandreh: thank you, ill check it out, for my personal browsing need i think icecat, etc. will work great, even GNOME Web is a wonderful thing to have, the few browsers driving the entire web is very concerning to me, work stuff will go into a VM anyway...
<mbakke>I don't think 'sudo -E' is actually necessary, because the 'guix' executable obtained with 'guix pull' is self-contained, i.e. it does not rely on any variables from the profile
<mbakke>I sometimes invoke /var/guix/profiles/per-user/me/current-guix/bin/guix directly as a different user to avoid pulling :P
<mbakke>sudo --login or su --login is definitely required though, when switching users
<PotentialUser-68>lfam: that is very helpful, thank you. i did notice a treatment of the `-i` (ie --login) parameter in the manual, but your description made it clear. as an aside having an actual manual made me shed a tear of joy...
<civodul>mbakke: hash-tee! well, there was, i dare say, consensus on getting rid of them, provided the value of return phases is actually ignored (which is not the case in 'master')
<mbakke>adfeno: being a third-party kernel module, you would need to compile the trisquel kernel with it
<rekado_>the first draft of the blog post is ready; I still need to take a whole bunch of screenshots and edit them, but at least the text is pretty much done, I think.
<rekado_>should I send it to guix-devel or would it be better to send it to someone (or sometwo or somethree) else first?
<mbakke>adfeno: you could try to find a similar kernel revision in guix, run 'guix time-machine --commit=$revision_with_trisquel_kernel -- build v4loopback-linux-module', and "insmod" the resulting .ko file
<adfeno>mbakke: But, does Guix's obs recipe work well with system kernel (and modules) once v4l2loopback is built in Trisquel, or do I need to tell obs to do something else?
<mbakke>adfeno: if you can load the module, obs should be able to find it
<rekado_>lfam: it’s very much tied to the release song, so please let me know if you think I should go into any more detail or lean a little more into recommendations for generic music production purposes