<tune>is there anything I can read on the state of ARM support for Guix System?
<tune>I am interested in running Guix System on some sort of ARM device in the future
<rekado_>truby: building Guile outside of Guix is done fairly quickly, as long as you already have a version of Guile. But in Guix we bootstrap Guile using its own Scheme interpreter that’s written in C.
<rekado_>truby: so there are several passes, and one of them involves interpreting lots of Scheme code, which is not fast.
<rekado_>using an existing Guile during the build would speed this up dramatically.
<rekado_>Actually, I do wonder why we aren’t using the bootstrap Guile to build the later Guile.
<janneke_>rekado_: bootstrap-guile is 2.0.9, would that work?
***janneke_ is now known as janneke
<janneke>hmm, and it seems %bootstrap-guile is an input for guile-final
<raghavgururajan>After `guix pull`, I usually run `guix upgrade --dry-run` to check which derivations will be built. If I find heavy ones like icecat, evolution, calibre, kodi, qtwebkit etc., what is the general rule of thumb waiting period for the substitutes to be available for those packages, before I re-run `guix upgrade`? Assuming I will not be doing another `guix pull` during the waiting.
<roptat>it's weird how it sounds childish when it comes from a software, but totally normal from a human being :)
<jonsger>roptat: does it sound better with "on" instead of "tu"
<rekado_>raghavgururajan: you can also limit the search to a “spec” and “system”, such as “icecat spec:guix-master system:x86_64-linux”
<rekado_>raghavgururajan: this will give you the lastest builds for the “master” branch on x86_64 systems
<rekado_>you can’t yet see directly what commit this belongs to, but the guix data service will make this easier in the future.
<roptat>jonsger, sounds better, but then we can't use an imperative
<roptat>maybe it could become "Sur le système Guix, on peut ajuster le champ locale-libcs de la forme operating-system. On lancera info guix.fr pour plus de détails" with a future tense instead of the imperative
<roptat>it's not childish, but it sounds a bit weird
<jonsger>roptat: the first sentence sounds good for me, but the second sounds weird :P
<civodul>plus we need more people testing on AArch64, so your feedback will be welcome!
<truby>yeah, happy to help! We're looking at using guix at work so that we devs have isolated environments from each other on shared servers, because people keep sudo apt-get installing stuff and breaking someone else's workflow heh
<truby>civodul: so far though the experience has been good on AArch64, haven't hit any issues that I didn't get on x86_64 too. Although it seems many less substitutions are available; guix pull takes maybe half an hour after a day of not running it :-)
<truby>When I look at some packages, the current release version is just called package-name and then older versions inherit that, but for some the main version is called package-name-version and there's a (define package-name package-name-version) in the file.. is there any preference on which to use or does it not matter at all?
<nckx>truby: It's a somewhat subjective gamble about what will cause the least trouble/maintenance work in future, and what ‘makes sense’. ‘The default GCC’ is a switch we want to easily flip once in a while; some old crufty library required for a handful of packages: not so much.
<truby>nckx: that makes sense, I was just looking at the llvm package and that uses llvm-8 as the main variable and then (define-public llvm llvm-8) which... seems wrong to me as I can't see why you wouldn't want to bump the 'default llvm' every 6 months? In the same way as gcc
<idnull>nckx: if you're asking me, then for the whole system, yes. I still want to build the system from scratch, maybe I should redefine packages then&
<nckx>truby: Maybe (I can't speak for whomever wrote it like that) exactly because it allows you to decouple adding an llvm-9, & letting it mature, from making it the default? Or I misunderstand.
<truby>at least, I don't see a reason not to really, things that depend on LLVM as a library should ask for a specific version already as LLVM's libraries provide absolutely 0 guarantee of backwards compat :-)
<nckx>idnull: Input rewriting is the way to do that, in general, I'm just not sure if there are gotchas involved when rewriting implicit inputs like GCC.
<nckx>truby: Heh, that's my practicial experience with LLVM all right, but I'm not an authority on it.
<truby>oh, possibly that's why it was done that way. I didn't think of that :-) but isn't that equally easy to do the other war around? perhaps not. Anyway, I was only asking because I have a fix for some stuff in the llvm package, plus a version bump, and was wondering what the best format to put that in was
<truby>I guess the answer is "stick to how the package already does it"
<idnull>I haven't tested it yet as I am trying to package doom source-port now
<tune>it's not urgent, I am just reading about it now and it seems cool
<tune>I'll be glad if you submit it to the repo at some point
<apteryx>Hmm; I'm hitting some problem I can't seem to solve: warning: failed to load '(gnu tests install)':\nIn procedure abi-check: #<record-type <file-system>>: record ABI mismatch; recompilation needed
<apteryx>Yes, I've modified the <file-system> record; but I've ran 'make clean-go', then 'make' and it bulids completely fine, then 'make check-system TESTS=btrfs-root-os' triggers the problem again.
<idnull>so i can do something like that ;;(patches (search-patches "/home/id0/git/packages/st/st.patch")) but with git?
<apteryx>idnull: these patches are not git specific, so you can either use 'git apply /home/id0/git/packages/st/st.patch' or 'patch -p1 < /home/id0/git/packages/st/st.patch' while the CWD is the root of the sources of 'st'.
<idnull>oh, sorry I misguided you. I want to apply patch from a separate repo
<krusnus>nckx Oh ok. i have no idea of the differences between different types of nwtwork services (dhcp, NM and all that) but i usually use dhcp on my wired setups (at least i did when i used arch) but when i add (service dhcp-client-service-type) guix complains about it being an unbuound variable
<krusnus>and yes i have loaded (gnu services networking)
<nckx>idnull: 1) You'll have to submit it as a patch to games.scm, not its own file 2) indent it (using C-M-q in emacs or etc/indent-code.el in the guix tree 3) I don't think MODULES in SOURCE is needed? 4) move build-system above arguments 5) expand the description (and make it a real full sentence ;-) 6) Is there a… better-looking home page? 7) we can't package ‘master’, choose a tag or commit if there are no releases (although that might make it hard to ups
<nckx>tream — we prefer released software); you can't ‘skip’ sha256 8) lots of stuff I forgot I'm sure.
<nckx>idnull: If you can ‘defend’ that home page on the ML (and it seems you can; I do see your point), go ahead and submit it. It's unconventional but the conventional choice — a link to the git web view — would be less informative.
<apteryx>in a system test: file-size: /gnu/store/kw357rqfm7kw4rhx1sbakw3jc4zpi6gy-nss-certs-3.45/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:126.96.36.199.188.8.131.52.pem: No such file or directory
<nckx>Just be prepared for others to ask the same annoying thing 🙂
<idnull>nckx: ty! I'll make ait a patch to git then and fix other things like indent one.
<nckx>Describing packages like these is never fun, because it's hard to find a balance between ‘foodoom is a form of bardoom by baz but with a new shader algo by buz1996’ and ‘What's Doom? Doom is a first-person shooter…’.
<nckx>bricewge: I downloaded it myself, I wasn't accusing you of editing anything, git was.
<nckx>bricewge: Never mind, thought you meant ‘git won't accept even the fixed file’.
<truby>can you override a dependency in a package you depend on? I.e. I need to build my package with a specific gcc, and I also need one of my dependencies to be built with that same gcc
<bavier>truby: I think it's the 'package-input-rewriting' procedure you need
<bricewge>nckx: The encoding was `quoted-printable`. I managed to apply the patch by getting the mbox file, converting it ot mdir with `mb2md`, extracting the attachement with `munpack` and applaying it with `git am`.
<vixus>Hi all, I've got a slightly customised install.scm defining an operating-system that inherits from installation-os. I was wondering if I could also get the installation disk image to build with some of my own files in /etc. I tried appending an etc-service to %installation-services but the latter isn't exported by the gnu/system/install module. Any ideas?
<nckx>bricewge: Great to hear! (And I'll jot that down for myself, too.)
<nckx>vixus: You can ‘force-import’ symbols with (@@ (gnu system install) %installation-services). It looks ugly to remind you that it is ugly, and you should be doing something else instead, but it's a handy hammer if there's no other way.
<jlicht>Does anyone else have a lot of "Name or service not known"-esque messages when using a Guix system under load?
<jlicht>* while using okay-but-not-perfect WiFi connections
<jlicht>I finally figured out that I can `herd invalidate nscd hosts' to at least invalidate the cache with borked entries once this happens, but it would be nice to not have this happen at all :/
***wopwop is now known as nootboot
<nootboot>hey everyone i was just wondering how one would go about configuring Xorg in a way that doesn't require a login manager? the reference manual say that "there is not Xorg service; instead, the X server is started by a “display manager”" but i would be verry surprised if there waasnt a way to do this
<emacsomancer>I was finally able to get guix to install (on top of a foreign distro) on a raspberry pi. (A year or two ago I had no luck with this.)
<jlicht>nootboot: Alex Kost used to do something like that.
<nootboot>jlicht huh why is that? maybe i wasnt clear about my intentions but i just want xorgg to start with a simple startx as one would with any other system but the X Window entry in the manual is written as though login manager is the only option
<nootboot>seems to me like that should be easier to do than to use GDM