IRC channel logs


back to list of logs

<lfam>My job has nothing to do with software, and it's a mixed blessing. I'm looking to move into a software job of some sort
<lfam>I have the rare job that only requires a few days a week, leaving plenty of time for Guix :)
<dvc>lfam: consulting?
<lfam>I do technical work for large audio / video productions. Not exactly consulting but a quasi-freelance position.
<lfam>Live productions, that is
<lfam>But, like I said, I want to work in software. This job is boring :)
<OrangeShark>I just started my first real software dev job
<dvc>OrangeShark: Nice! How do you like it?
<OrangeShark>it is alright, the people are nice and stuff, but the code base...
<davexunit>OrangeShark: every codebase sucks. :)
<dvc>haha. I worked for a project on a 4 day old codebase from a different team - that was bad enough
<davexunit>get used to it. :)
<OrangeShark>davexunit: ya :p
<OrangeShark>it also all on windows :(
<davexunit>oh well that sucks :(
<davexunit>I use an ubuntu workstation which is nice
<OrangeShark>they also should introduce automated testing...
<davexunit>I use guix to provide a lot of my dev tools, though. :)
<OrangeShark>I actually mentioned guix in the interview for it haha
<lfam>Hm, python-pillow is failing on armhf, in a way that looks related to openjpeg, which I just made a bunch of changes to:
<dvc>timeout is not a very helpful error message...
<lfam>We could try updated python-pillow. There are several later versions
<lfam>dvc: Lol. Keep trying
<dvc>I'm still building the kernel on my beagle bone. Sooo slow
<dvc>This takes 20min to cross compile - it's been at it for hours
<lfam>Wow, that could take a while
<dvc>it's beyond me at the moment - but moving builds from real hardware to qemu is something we should do...
<lfam>Why do you think we should do that?
<lfam>dvc ^
<sajt_>hm, I'm getting "build failed: some substitutes for the outputs of derivation" for python 3.4.3, any ideas?
<lfam>sajt_: What command are you running?
<dvc>why not? more speed, more automation, no need for hardware...
<davexunit>we should keep doing builds on bare metal
<davexunit>much better use of resources
<lfam>I updated python-pillow to the latest. We'll see if that fixes this armhf failure
<sajt_>lfam: I'm doing guix system reconfigure
<lfam>sajt_: In general, I would add --fallback to that command
<sajt_>lfam: sorry, I'm pretty new: what does fallback do?
<lfam>If substitution fails, it builds from source
<sajt_>lfam: ok, great! thanks
<sajt_>lfam: just out of curiousity... substitution, what does that term mean?
<lfam>sajt_: Guix is a hybrid of build-from-source and binary package management systems. When you get a binary for a package in Guix, we consider it a substitute for a source build. Normally, this difference is transparent; you will build if no substitute is available.
<dvc>davexunit: Landley makes a case for the oposite:
<lfam>In this case, your Guix thought there was a substitute available, but something went wrong. This case is unusual, so --fallback is not the default
<lfam>If we were to start using QEMU like that, we would need to pay a lot more attention to QEMU security issues. QEMU is probably the most common program reported on oss-sec
<dvc>He says it's 20% of native performance
<davexunit>we still need to manage all the hardware anyway
<sajt_>lfam: ok, sounds nice. I've always liked source-based package management and having binaries is a perk on low-end machines
<dvc>davexunit: how so?
<lfam>sajt_: Yeah, I really like the hybrid system. And it works because Guix accounts for the entire dependency tree of any build, so substitutes are exact.
<davexunit>dvc: VMs can't exist on their own.
<davexunit>we still need to maintain servers that host them
<dvc>yes, but we can use homogenous hardware with best $ per watt (which probably is arm =P)
<lfam>We already do use QEMU for some core parts of the distro, like building the installer.
<sajt_>lfam: so it doesn't happen that a build breaks because you haven't rebuilt some dependency? (like in BSD ports)
<lfam>sajt_: I'm not familiar with how the ports system works, so I'm not sure exactly what you are asking
<sajt_>lfam: lets say I build package A, then B (which depends on A). now I want to update B, but don't rebuild/update A before that
<lfam>sajt_: I recommend the paper "Functional Package Management with Guix", found here:
<lfam>I think it will help you understand how Guix works :)
<lfam>It will answer that question and many others :)
<sajt_>lfam: ok, thanks. I've heard a few things about nix before and I like haskell (so I'm used to reading papers instead of docs) ;-)
<lfam>Our manual is very good, too, but I think that for a general understand of treating software building as a function (functional package management), that paper is pretty good. There is another good paper by Eelco Dolstra, who started Nix. "Nix: A Safe and Policy-Free System for Software Deployment", found here:
***edangor_ is now known as edangor
<dvc>davexunit: failed with can't allocate memory after 20749s
<dvc>that's nearly 6 hours!
<dvc>even in qemu that would be less than one on my laptop...
<dvc>maybe I'm doing something completely wrong - the beagle bone black isn't the slowest of the arm boards...
<mark_weaver>dvc: I would suggest getting a Novena board or Wandboard Quad, both of which are used as Hydra build slaves for armhf.
<mark_weaver>the beaglebone black is a nice little box for some purposes (I use them as remote serial consoles and SPI flash programmers), but it's terribly underpowered for compiling things.
<dvc>I have a zybo too, is that any good? =P
<mark_weaver>never heard of it
<dvc>but you get my point on the qemu thing...
<mark_weaver>I agree that we should have support for building things using qemu, but I don't want to use qemu in our build farm.
<mark_weaver>decent ARM boards are just not that expensive
<mark_weaver>the Wandboard Quad in particular works well and is not very expensive
<dvc>ah yes the price tag doesn't look too steep
<dvc>but I'm unlikely to buy one for compiling a kernel for bbb this one time...
<mark_weaver>*nod* qemu build support would be a huge win for individual developers without the necessary hardware
<dvc>probably gone to bed...
<edangor>ah ok...
<mark_weaver>edangor: if you have a question about guix, you can ask; maybe someone else here knows the answer
<edangor>no, it's just that this is taking so long...
<edangor>(the installation)
<dvc>mark_weaver: openldap fails to build on arm, I'm screwed with the bbb project, giving up :)
<dvc>now time for bed...
<nichi_>let's say i have a package that puts some conf files in /etc - if i edit the files and the package is later upgraded, does guix have a method to prevent the files from being overwritten?
<mark_weaver>nichi_: guix packages can't put files in /etc
<mark_weaver>guix packages can only put files in their output directories, in /gnu/store
<nichi_>sorry, that was what i meant, /gnu/store/.../etc
<nichi_>is there a mechanism for persistent configuration?
<mark_weaver>you can't edit files in /gnu/store. everything in /gnu/store is immutable, and must never be changed.
<mark_weaver>guix will break badly if you change anything in /gnu/store
<mark_weaver>well, there are ways to verify that it hasn't been changed and rebuild the damaged store items in that case, but it's not pretty
<mark_weaver>anyway, in GuixSD the idea is that configuration goes in your OS configuration file, and that is used to build /etc
<nichi_>i see, thanks for the help
<mark_weaver>having said that, it is possible to create additional files in /etc yourself, but for any given file, either guix generates it based on the OS config, or you added yourself and manage it yourself.
***snape` is now known as snape
<snape>hi, is there a way I can see Hydra's current status?
<snape>I mean, I want to know when linux-libre is built
<snape>so I can update my OS without having to build it
<mark_weaver>snape: hydra built it about 30 minutes ago, or so.
<mark_weaver>you might have a negative cache entry in your substitutes cache, though.
<snape>thanks mark_weaver
<mark_weaver>that's linked from the package list on our website
<jmd>mark_weaver: So is there a conventional adduser/deluser in Guix or is the only way to do that by editing /etc/config.scm and reconfiguring?
<mark_weaver>jmd: the only way is to edit the OS config and reconfiguring
<mark_weaver>iirc, if you add a user or group manually, it will be removed the next time you reconfigure. guix assumes that it's in charge of those files.
<snape>mark_weaver: I see, nice. How can I clear the substututes cache?
<jmd>"Those files" being /etc/passwd &c ?
<mark_weaver>jmd: right
<jmd>So how is it going to work with NIS or LDAP ?
<mark_weaver>snape: run this as root: find /var/guix/substitute/cache/ -size 106c
<mark_weaver>sorry, that's not complete.
***tschwing_ is now known as tschwinge
<mark_weaver>snape: run this as root: find /var/guix/substitute/cache/ -size 106c | xargs rm -v
<snape>ok thanks
<mark_weaver>bah, not quite
<mark_weaver>snape: run this as root: find /var/guix/substitute/cache/ -size -106c | xargs rm -v
<mark_weaver>(minus sign before the 106c)
<mark_weaver>that deletes all files in there smaller than 106 bytes, which are the negative cache entries
<mark_weaver>(the size of those negative cache entries varies with the substitute URL, but that covers the default substitute URLs)
<mark_weaver>jmd: I don't know what the plan is for that. better ask on guix-devel
<snape>mark_weaver: it works well!
<mark_weaver>I'm glad to hear it :)
<jmd>Something is wierd with slim. If I try to login with an incorrect password, then subsequent logins always give me a wmaker session, regardless of what I had selected.
<jmd>What is it that maintains the files in /etc/pam.d ?
<mark_weaver>jmd: see gnu/system/pam.scm
<mark_weaver>specifically /etc-entry
<jmd>Yeah just found that.
<jmd>I'll have to get ludo to explain the magic.
<efraim>hmm, python-peewee maintains a reference in `guix gc --references' to python-cython
<jmd>Presumably there is a list of base services which run even if not in /etc/config.scm ?
<efraim> license check?
<janneke>jmd: i surely hope not
<jmd>janneke: Well for example, what starts the gettys ?
<janneke>unless you consider %base-services in (cons* ... %base-services) to be `not in config.scm'
<efraim>MIT is expat or X11?
<janneke>jmd: mingetty-service?
<janneke>see gnu/services/base.scm (%base-services)
<jmd>janneke: Well I don't have that in my config.scm, yet I have gettys running.
<janneke>jmd: hmm, i cannot imagine how that would work; weird.
<janneke>i would hope that config.scm somehow references %base-services...
<jmd>Perhaps %desktop-services includes %base-services. Although that would be wrong IMO.
<wingo>see "Base Services" in the manual
<jmd>wingo: Well that merely tells me about %base-services and says that it is the default value of operating-system services.
<jmd>But I have a non-default entry there, yet I still see gettys runnning in the background.
<iyzsong>yeah, %desktop-services does include %base-services (gnu/service/desktop.scm)
<jmd>Seems odd to me.
<wingo>"Desktop Services" in the manual does mention that it builds on %base-services
<gunoob1>hi there. i managed to create a package which installs some extra config in etc. the package works and the files show up in the store. how can manage that it will be linked i the current system ?
<wingo>gunoob1: if you want it as a user, guix package -i your-package
<wingo>if you want it in the system, there are two things
<wingo>you can add it as a package
<wingo>in the operating-system definition
<wingo>but probably what you want is for it to run as a service
<wingo>for that you have to define a service definition and add that to your operating-system
<wingo>see "services" in the manual for more info
<wingo>it's a bit underdocumented tho, feel free to ask when you get stuck :)
<gunoob1>i made a local package, and installed it with -f
<gunoob1>where i need to put it, so that it will be found in case of "system reconfigure.."?
<wingo>do you want it available as a package or as a service?
<gunoob1>i want it as a simple package
<gunoob1>if possible
<gunoob1>as i said that already works. it puts a entry in the store with the correct path and files
<wingo>one possibility is, in your os definition, put (add-to-load-path "/path/to/directory/containing/foo.scm"), then (use-modules (foo))
<gunoob1>but it doesn't get linked into the current-system etc
<wingo>assuming your package is in a module named (foo)
<gunoob1>sure :)
<wingo>otherwise if it is just a simple package with no module decl you might try (load "./path-to/fo.scm")
<wingo>good luck :)
<gunoob1>in that case a system reconfigure will link it?
<wingo>then you need to add the package to the `packages' field in your os
<wingo>(operating-system ... (packages (cons my-package %base-packages))) or so
<efraim>looking at my old connman patch attempts, I think I need to readd sysconfdir and localstatedir back to the configure flags :/
<efraim>but anyway, here's a snippet I have for switching around services: (services (cons* (connman-service) (delete (wicd-service) %desktop-services)))
<efraim>does guixsd use a compressed initramfs?
<gunoob1>wingo: ok, that somehow worked. i have now an own package module with my selfdefined packages, which get installd via guix system reconfigure
<gunoob1>but those files get not linked into the current-system
<gunoob1>am i missing somethin?
<janneke>l /run
<janneke>gunoob1: i think after reconfigure your packages should show up in /run/current-system/profile/
<gunoob1>ok... i'll search & find it :)
<gunoob1>oh.. indeed ... thx.. just made an typo.
<gunoob1>(wrong place :D )
<adfeno>Hi all :)
<adfeno>I'm trying to make a Guix package recipe...
<gunoob1>adfeno: just managed to do that :D
<gunoob1>at least i can give you a very simple example that works
<adfeno>gunoob1: Thanks! :)
<gunoob1>wait a sec.
<adfeno>So... But when testing with `guix build`, it seems that `guix build` tries to download a package called module-import-compiled, but the substituter fails saying that there is a hash mismatch.
<wingo>that's pretty weird :)
<adfeno>See the recipe I'm making:
<adfeno>↑ Expires after one hour.
<adfeno>I have annotated the build command used, just visit the link I gave and scroll to the bottom to see the annotation.
<efraim>Try it without the quotes
<adfeno>efraim: Doing `GUIX_PACKAGE_PATH=$HOME/Testes/Guix guix build tahoe-lafs` without quotes doesn't change the hash mismatch on module-import-compiled.
<adfeno>I have annotated the original paste with the guix build error in details.
<iyzsong>adfeno: the source hash is wrong, the correct one (base32) starts with 09jxb4...
<adfeno>iyzsong: Are you talking about Tahoe LAFS?
<adfeno>Because if I do `guix hash "[Path to the manually downloaded tahoe-lafs-1.11.0.tar.gz file]"` I get: 0dn2i9zmqhnlcbypgwh6y75rvf5ss7651l6p10nc83c8vmlcqawj
<iyzsong>I can't reproduce that, maybe you just catch a broken download :-
<adfeno>I'll try with the .tar.bz2 file instead then.
<dvc>how do I make a shepherd service require a dbus service?
<adfeno>About the hash mismatch on module-import-compiled: I tried putting the .tar.bz2 and its nix-base32 hash in the source declaration, but got the same error.
<adfeno>The error doesn't seem to refer to the hash of the source or derivative being made, quite the contrary: it seems that guix build is trying to do something with module-import-compiled, but it's failling.
<iyzsong>adfeno: oh, that's really strange... you can try add '--fallback'. I append my output to your paste (didn't get that error).
<adfeno>I have done `guix pull; guix package --upgrade; guix gc` both as root and normal user (in that order) two times yesterday when facing the error, but I'll do it again just in case.
<quigonjinn>I want to remove multiple flags from the ones my package inherits. Is nesting deletes from srfi-1 a bad approach? I am looking into (remove pred ,flags) now
<adfeno>About hash mismatch again: Tried again and got same error.
<iyzsong>adfeno: at last, you can use '--no-substitutes'.. it seems hydra serve a broken cache here.
<adfeno>I think I got an idea of the problem.
<adfeno>iyzsong: I might try that too.
<adfeno>First, I'll see if `guix download` and `guix hash` produce different hashes.
<adfeno>They do produce different hashes...
<adfeno>Now the error is different....
<adfeno>(Another paste since the recipe was changed).
<iyzsong>I can get it ok from hydra.
<adfeno>I'll do guix gc and try again. :)
<adfeno>Now I got the module-import-compiled error again.
<adfeno>I have made a new annotation, see the last paste.
<jmd>How can I add a new pam service to GuixSD ?
<civodul>jmd: by extending pam-root-service-type
<rekado>after adding two mapped devices to my OS config I get this error upon reconfigure (and upon starting the two new services):
<sneek>rekado, you have 1 message.
<sneek>rekado, lfam says: Are you using prosody? If so, can you test that it still works with these changes?
<rekado>herd: exception caught while executing 'start' on service 'device-mapping-rekado-home':
<rekado>ERROR: Unbound variable: bytevector?
<rekado>adding (rnrs bytevectors) to the modules in my config now, but I think this needs to be added elsewhere
<rekado>I find this strange as (rnrs bytevectors) is used in “open-luks-device”.
<adfeno>On the hash mismatch: I made some progress, I had to use --fallback.
<civodul>adfeno: i experienced a hash mismatch for /gnu/store/hzlzcvzrlc0k182l3hw6wq6mpr5m4wjy-module-import-compiled
<civodul>this one should be fixed now
<adfeno>civodul: Did you experienced it rescently?
<civodul>rekado: open-luks-device does (use-modules (rnrs bytevectors))
<civodul>minutes ago
<civodul>ACTION goes afk
<adfeno>Oh... OK :)
<rekado>civodul: I must be doing something wrong as I still get this error, despite the use-modules line in open-luks-device
<brendyn>I think I've gotten myself stuck in a Python dependancy loop. Someone call The Doctor.
<dvc>civodul: Have you looked at the linux-libre patches yet?
<dvc>I renamed linux-libre-multi-v7 to linux-libre-arm-generic, updated the docstring in (system->architecture) and moved (base32) to the caller.
<ng0>what do you do when an setup which behaves a bit weird generates something which it also runs with interruption which includes -R/path/to/something while it shoiuld be -L/path/to/something? There are also -L in there, which makes it weird.
<ng0>i mean, how do you prevent or correct -R ? and what is -R?
<janneke>ng0: it it's for the linker, -R is --rpath
<ng0>i already ran a search but didn't read much about it. i wonder what pike wants.
<ng0>there is a script which is generated and the last attempts to fix the package I have spent with trying to fix this generated scripts shebang.
<adfeno>What does the package "input" tuple means?
<adfeno>I mean... Is there a difference in functionallity if I do, for example:
<adfeno>`(("python-setuptools" ,python2-setuptools)) ?
<adfeno>and ...: `(("python2-setuptools" ,python-setuptools)) ?
<janneke>the left bit, the string, is `just' a name
<janneke>if you may need to access the package by name
<janneke>adfeno: the right is the actual package, using python2 in your first line and python3 in the second line
<adfeno>Will the left part be used in while building/following the recipe?
<janneke>that depends on the recipe, often it's not really used
<adfeno>Or, is the left part used only for package management?
<adfeno>To say like: if left part is "test-2.1+" then package manager will check for version 2.1 or above of test packge.
<ng0>maybe i can fix it once i have figured out how to make pike not ignore options passed.
<janneke>adfeno: no the right bit is used for that; guix uses only exact matches
<janneke>there is no such thing as .. 2.1 and above
<adfeno>Oh... OK. :)
<adfeno>Python's Nevow doesn't have a Guix recipe...
<adfeno>I think I'll make one in the future.
<ngz>Hello. An application, namely pharo-vm, requires 32-bit headers for some libraries (e.g., libc6-dev:386 under Debian) in order to be built. Can this kind of application be packaged under Guix, or is it bound to fail?
<efraim>So it wants 32 bit and 64 bit inputs?
<efraim>Or it's only available as 32 bits
<jmd>ngz: Well if, for some strange reason, it can *only* be built againt a 32 bit kernel, then of course it will only work on the i686 versions.
<jmd>ngz: But that would really be a very unusual application. Why do you think it only works on 32 bit?
<ngz>jmd: Because their website states that "A 64-bit binary is on our horizon, but currently Pharo is 32-bit, requiring a bit of extra setup on 64-bit systems.", which means installing 32 bit headers.
<jmd>This is binary only software ?
<efraim>You can also mark supported systems as i686-linux only
<efraim>You'll have to go through and unbundle it
<ngz>jmd: No it is not. Building it requires 32 bit headers of, e.g., libc6
<ngz>efraim: Wouldn't that mean I cannot use it on my x86_64 system?
<efraim>I assume it should be installable anyway
<jmd>The normally, sofware works on any platform for which it is targetted. If for some reason there is close interaction to the kernel, then that could be a special case - but it would be highly unusual.
<jmd>ngz: Why don't you try it, and see?
<ngz>jmd: I was hoping to avoid a couple of hours of unnecessary work if it is bound to fail.
<jmd>Well I don't know. That quote you gave, seems odd and doesn't make a lot of sense. What software is this?
<ngz>Pharo VM
<ngz>BTW, IIRC, Wine is in the same situation (32 bit build only)
<jmd>whihc means?
<ngz>jmd: I don't understand your question.
<lfam>ngz: If pharo-vm really cannot be used on 64 bit systems, you could probably take some guidance from the wine package
<lfam>That package sets supported-systems to i686-linux and x86_64-linux, and then builds for a i686-linux system. So it's limited to 32-bit Intel compatible
<ngz>lfam: Yes I'm currently looking at wine.scm. Basically, it adds #:system "i686-linux" in arguments.
<lfam>Don't miss the last line, which sets supported-systems
<ngz>I guess I can try to do the same with Pharo.
<lfam>It's worth a shot. I guess if the upstream does not support 64-bit Intel-compatible systems, it's not worth it to try to change that unless you have some pressing reason
<brendyn>ACTION package -s ""| recsel -P license|sed 's/, /,/g'|tr , '\\n'|sort|uniq -c|sort
<brendyn>I don't suppose there is a simpler way to do that?
<lfam>There's a way to do it in Guile, but I'm not sure how
<davexunit>ACTION doesn't even know what the above does
<davexunit>but it would surely be more understandable in guile
<lfam>It gives you a list of the licenses used by packages, with a count of how many times each licensed is used
<lfam>I guess you'd want the list sorted, but that command doesn't do that
<lfam>It also counts a blank line per-package
<lfam>Text-munging problems
<brendyn>Well currently guix doesn't provide a convenient way to search packages. It searches descriptions and synopsis, so you have to cut the results down with external tools
<davexunit>if you want advanced searching you can easily use guile to do it
<davexunit>but a CLI for searching by license would be good
<lfam>I think using recutils is a decent half-way point for non-Schemers
<ng0>ideally, 'guix package -s -l licenseyouwant' and there would also be something like -i for 'installed in profile' or something
<brendyn>Well regardless, I think having to jump through hoops for such features is crazy. I'm pondering changes I'd like to make. For example you have to do -s . or -s "" to list all packages. It seems like a bit of a hack. Maybe we can patch -s with no arguments to simply list all packages
<brendyn>`guix' with no arguments tells the user to type `guix --help'. Why not just list the help menu straight away like `git' does?
<JamesRichardson>I just tried to build guix from a git checkout. running make check I get an error gnu/system/install.scm:270:24 mingetty-configuration: extraneous field initializers (motd) in form (mingetty-configuration (tty tty) (motd motd) (auto-login "root") (login-pause? #t))
<JamesRichardson>guix is installed on top of Debian Sid. I get a similar error with guix pull.
<JamesRichardson>Is such things only supported on the actual guixsd?
<ng0>it reads like you wanted to install guixsd ontop of debian ?
<efraim>No, motd as declared there was removed about 1.5 hours ago
<dvc>efraim: found your fork :) does inox build? I see some duplicate work going on =P
<efraim>I saw it and thought it looked interesting
<efraim>Haven't done much besides look at the pkgbuild in the aur
<lfam>JamesRichardson: Are you using the latest commit on the master branch?
<JamesRichardson>I'm running guix on debian as a foreign package manager.
<dvc>so doesn't build yet?
<efraim>And building from git
<JamesRichardson>lfam: I ran git checkout minutes ago.
<lfam>JamesRichardson: Okay, there was a recent change related to the motd. I recommend `make clean-go` in case of ABI breakage
<efraim>Its in a test
<lfam>Ah, so the test should be adjusted
<lfam>dvc ^ :)
<lfam>Actually, it's not just the test. `guix pull` is broken too
<dvc>oh now I see
<dvc>yep sorry about that... xD
<lfam>Perhaps it's best to revert the change while we adjust the commit
<dvc>Which commit?
<dvc>Did something break?
<dvc>I tested it to death
<JamesRichardson>Is there a how to or best practice for how to setup a box to dual boot guixsd and another distro (Debian in my case)?
<ngz>How one can specify the location of the CMakeLists.txt file using cmake-build-system? By default, it looks for this file in the root source dir, but in my case, it is located in the "build/" subdir.
<dvc>lfam: I think that's his guix configuration that broke, my commits are solid =P
<JamesRichardson>lfam: I ran make clean-go; make check ; I see the same error. I also ran git pull, says Already up-to-date.
<dvc>JamesRichardson: You have to remove the motd field
<dvc>It's part of the login-service now
<ng0>yay, some progress with ghc 8.0.1 :)
<lfam>dvc: I'm guessing 317d3b474a (services: Add login-service.), since the error message is related to the MOTD. `guix pull` fails:
<alezost>brendyn: if you want search packages by licenses, in Emacs you can use "M-x guix-packages-by-license" (license names are completed) or "M-x guix-licenses" and press RET on any line there
<dvc>lfam: give me a sec...
<dvc>pushed a fix
<lfam>It's fun when a minor version bump results in "70 of 70 tests failed"
<lfam>I guess it wasn't so minor
<dvc>JamesRichardson: should work now, can you try again?
<dvc>lfam: such big failures are a lot better than only one test failing. Usually there is a simple fix like setting an env variable or adding a dependency...
<lfam>Yes, it's true. It would be worse if it said something like "11 of 70 tests failed"
<JamesRichardson>dvc: trying make check now. seems to be getting farther.
<lfam>sneek: later tell rekado: The new Ardour failed to build:
<sneek>Got it.
<jmd>I'm sure this has been discussed before, but I think that the multitude of warnings everytime one runs "guix package --install" is a problem.
<jmd>Perhaps the warnings are harmless, but large numbers of warnings are a bad user experience. It'll alarm new users.
<lfam>Agreed that it's a bad experience, but what is the solution to the problem? You're talking about the collision warnings, right?
<lfam>They need to be examined on a case by case basis
<ng0>hrm.. i think we need a ncurses-5. or at least symlinks
<lfam>There are some "classes" of collision warnings that can be analyzed all at once. For example, there are lots of warnings with Python software
<jmd>Right. Examining every one is impractical. On my modest system, there are dozens - perhaps over a hundred.
<lfam>So what do you propose?
<jmd>One option would be simply not to display them by default.
<JamesRichardson>dvc: make check is working now. Thanks.
<alezost>jmd: try to upgrade your profile ("guix package -u"), I think it will reduce the number of collision warnings for you
<lfam>I don't think we should hide the warnings by default. Some of them could be very serious
<lfam>For example, installing both the parallel and moreutils package will create a collision at ~/.guix-profile/bin/parallel
<lfam>But, those programs are not compatible at all
<jmd>Having the serious ones in the middle of 99 others they are pretty well hidden anyway.
<lfam>This is true, which is why I think we should analyze the common collision cases and work on a solution
<lfam>It seems like most of the collisions are of a specific type that repeats over and over again
<jmd>In my case, the common ones are libtool objects.
<janneke>lfam: You say: /some/ could be there any way to heuristically identify those?
<lfam>I don't know, janneke
<jmd>Some users might not care two hoots about libtool objects.
<janneke>ACTION likes `i don't know, in general' ;-)
<lfam>Also, by printing the collisions warnings, users are reminded of the possibility of collision, and will hopefully not try to do things like install both gnupg@2.0 and gnupg@2.1
<lfam>I think it's worth developing a solution to the common collisions that we know are harmless. It would be interesting to see what Nix does about this
<brendyn>Are collisions usually instances of the same file? can a hash check not be made?
<janneke>just wondering, why did you say `some'? I have the idea that certain collisions are almost certainly harmless -- is that what you are hinting at?
<lfam>Some collisions are harmless, because we know the files are the same. But others are genuinely different files with the same name.
<lfam>And by "know the files are the same", I mean we as humans can confirm it. The Guix code doesn't know it
<lfam>But it could. A hash check would help
<janneke>That would be quite an interesting distinction.
<jmd>Most will differ in some way.
<janneke>Having the same file referenced twice could be a bug, but is certainly harmless?
<janneke>I noticed collisions between emacs-24.5 and emacs-minimal-25.5
<brendyn>Doesn't the guix store reduce identical files to a single file + symlinks anyway?
<jmd>brendyn: No. It uses hardlinks.
<lfam>Hard links
<brendyn>well hardlinks. then. Will a collision between a file and another file hardlinked to the first cause a collision error?
<lfam>iyzsong has proposed some patches recently to reduce the conflicts. Look for (and comment on!) 'icon-theme' on guix-devel
<jmd>I'll have a look.
<nckx>lfam: IIRC, Nix uses per-package priorities and refuses to randomly pick between two colliding files of equal priority like Guix does.
<jmd>Even having package --install/--remove give the user a hint to run --upgrade might be worthwhile.
<davexunit>the picking is deterministic, not random, but it is arbitrary.
<lfam>brendyn: Profiles are basically symlinked unions of the packages the user wants installed. So, if two store directories with a same-named file are symlinked into the profile, they collide. We know it's fine when we can see that the colliding files are hard linked to the same inode
<nckx>davexunit: point taken. I meant arbitrary, though I doubt most users appreciate the difference ;-)
<brendyn>Ok, but guix will still throwing a warning?
<davexunit>anyway, there are mailing list threads dedicated to this topic for those that want to learn more about the potential solutions discussed
<lfam>davexunit: I noticed that kodi is failing to build:
<davexunit>I have no time to fix it.
<lfam>nckx: That's interesting. Any ideas where in the source tree I should look for that mechanism?
<alezost>janneke: did you install both emacs and emacs-minimal?
<lfam>davexunit: It might be an incompatibility with our ffmpeg
<davexunit>could very well be the case
<davexunit>ACTION waits for Kodi 17 to be released any day now
<lfam>Sounds like a good plan :)
<lfam>dvc: kmscon is failing on mips64el. Can you take a look? Maybe it doesn't work on that architecture anyways?
<lfam>vigra is broken!
<janneke>alezost: no... i guess that emacs-minimal is a dependency of something else
<alezost>janneke: most likely it is a mistake, it would be good if you could find out what package brings emacs-minimal to your profile
<lfam>jellyfish fails on i686:
<lfam>I wonder if that's expected?
<nckx>lfam: I don't have a nixpkgs handy right now, but I think it's as simple as meta.priority. Then there are the lib.lowPrio/hiPrio wrappers which litter the source tree (it's not the most elegant solution), and most people actually use in their configuration.nix. No idea if/how/where this is respected in the daemon, though. Sorz.
<lfam>Okay, that's a good place to start, thanks :)
<janneke>alezost: how would i do that?
<efraim>re jellyfish: long long unsigned is a 128 bit integer, not available to 32-bit systems
<alezost>janneke: I don't know :-) can you show what packages do you have installed?
<efraim>well, actually it depends on the platform, but it normally means 128 bit
<efraim>but it looks like it never built
<alezost>janneke: oh, I think I know: search for emacs-minimal in "~/.guix-profile/manifest"
<alezost>janneke: this is really interesting, I don't see any package propagating emacs-minimal
<janneke>alezost: i haven't got this in any of my 2 profiles...
<janneke>let me see where the collisions happened
<alezost>janneke: sorry, what you haven't got?
<janneke>emacs-minimal is not in my manifest file[s]
<alezost>hm, ok, so if it's not in your profile, what collisions did you mean?
<janneke>here's what i typed: guix environment guix --ad-hoc autoconf automake gettext guile gnutls texinfo libtool cvs git guix emacs sqlite
<janneke>and i got colissions like:
<janneke>warning: collision encountered: /gnu/store/?-emacs-24.5/bin/etags /gnu/store/?-emacs-minimal-24.5/bin/etags
<janneke>warning: arbitrarily choosing /gnu/store/?-emacs-24.5/bin/etags
<alezost>janneke: why do you need all these ad-hocs?
<alezost>emacs-minimal is already a non-direct dependency for guix (to build guix.el)
<janneke>alezost: that was a question i've been sitting on for a while...
<janneke>guix environment guix --pure and then ./bootstrap; ./configure; make
<janneke>does not work for me...also, i like to have emacs, the other may not be necessary...dunno `It finally worked' and i left it there until later
<janneke>this is on a ubuntu machine at work, the first one i managed to use guix on, after fixing troubles with .bashrc setting variables and whatnot
<alezost>janneke: ok, so the collision comes because you add 'emacs' while "guix environment guix" already provides emacs-minimal, but I can assure you don't need to --ad-hoc all these things. also why do you want to have emacs in this enviroment?
<janneke>i'm using this environment before starting work on guile -- and emacs is my editor ;-)
<janneke>that's another question i'v been sitting on; how do you all switch profiles (esp. between guile-2.0 and guile-2.2/-next within one emacs session, eps. wit geiser?)
<janneke>*work on guix
<alezost>janneke: I don't understand: do you start emacs from this environment? "guix environment guix" is intended to built guix, not to start emacs
<janneke>it sets up all build dependencies for guix, so that' perfect for guix development?
<alezost>yes it's perfect for guix development, but why do you want to start emacs from this environment, and not from your usual environment?
<janneke>i have guile-next/guile-2.2 in my main profile, so if i don't do guix environment guix before starting emacs to work on guix, emacs/geiser has the wrong guile
<janneke>there must be a better way, i just haven't figured that out :-(
<alezost>yeah, there probably is, I don't switch between guiles like you do, but if you want to do it inside a single emacs session, I see only one way: to set PATH, GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH using (setenv ...)
<janneke>yes, i'm going to try something like that
<janneke>M-x guix-set-profile RET ~/.config/guix/devel ... something like that would be nice
<lostcoff`>hey guys, I'm trying to get guile-wm to be selectable from slim. I've got it making a .desktop file like other wms do, but how do I get that file into /run/current-system/profile/share/xsessions as described in ?
<janneke>lostcoff`: write it to: out "/share/xsessions/"
<janneke>and install guile-wm into the operating-system's packages
<janneke>(lostcoff`: + gals ;-)
<lostcoff`>janneke: good point, sorry
<ngz>How can one specify the location of the CMakeLists.txt file using cmake-build-system? By default, it looks for this file at the root of source dir, but in this case, it is located in the "build/" subdir.
<efraim>you can add a phase before 'build to change dirs
<janneke>lostcoff`: great that you're looking at guile-wm
<janneke>i tried it again last week and got further than before, only i could not get (topl-evel-windows) to some xcb error
<lostcoff`>janneke: I think my problem is installing it for all users.
<janneke>i'd be very happy to learn from anyone who's using guile-wm and what they're doing
<lostcoff`>I switched the the root user's guix to my version so it would pick up my package definition
***lostcoff` is now known as lostcoffee
<lostcoffee>I am getting a "source file newer than compiled" warning. Can I force reinstall somehow?
<efraim>you can run make
<dvc>I think better collision resolution is on the roadmap for 1.0. But we shouldn't hide the warnings for now...
<lostcoffee>efraim: where?
<dvc>lfam: I can't reproduce the issue, I don't have a mips machine :/
<lostcoffee>janneke: I did sudo guix package -i guile-wm , is that right for installing system-wide, or is there something else I have to do?
<dvc>has anyone taken a look at my linux-libre patches? I'm starting school tomorrow, so I don't know my workload yet. would be nice to get this of my todo list :)
<janneke>lostcoffee: that will just install guile-wm for the root user
<janneke>in /root/.guix-profile
<janneke>to add guile-wm to the /run/current-system/profile, you'll have to add guile-wm
<janneke>... to your operating-system's (packages ...) in your config.scm and do: guix system reconfigure confnig.scm
<janneke>*config.scm (or whatever your os file is called)
<lostcoffee>ah! alright, that clears a lot up for me. I had a very debian mindset to this ☺
<adfeno>Hi all! :)
<lostcoffee>how do I restart slim with herd?
<dvc>lostcoffee: herd status to find the name of the service
<dvc>maybe display-manager?
<brendyn>I get this error running duplicity. Can someone do me a favour and tell me if they get the same error?
<dvc>herd stop display-manager && herd start display-manager
<civodul>dvc: i'll look at it Real Soon :-)
<civodul>rekado: re open-luks-device, what are you doing?
<lostcoffee>dvc: didn't have display-manager, but I had xorg-server. Restarting that killed X but failed to restart it. I'll just reboot, oh well
<dvc>lostcoffee: I checked the source, restarting xorg-server should have done the trick
<dvc>lostcoffee: can you provide some more info on what you are trying to do?
<dvc>civodul: thanks! :)
<paroneayea>just realized that being over 4k packages means we are > 1/3 the packages in nixos :)
<paroneayea>catching up!
<brendyn>But we are made with > 3/1 more ♥
<paroneayea>and about 7% of the packages in Debian ;)
<paroneayea>brendyn: heh
<brendyn>paroneayea: Would you mind doing me the favour of testing `guix package -i duplicity; duplicity --version' ?
<paroneayea>brendyn: sure, I haven't upgraded guix in like 2 weeks though
<paroneayea>so let me build the latest version
<brendyn>It doesn't matter, the current duplicity version is from 2015
<davexunit>ACTION attempts to fix issues with avr-gcc
<paroneayea>oh well I started building anyway :)
<paroneayea>brendyn: will report back as soon as it finishes :)
<cbaines>Does anyone know of a Guix "installer"? I'm getting a bit bored of repeating the binary installation steps?
<brendyn>Why do you have to repeat them?
<cbaines>When I'm installing Guix on a machine I am yet to install it on, or reinstalling it as I've broken it
<dvc>cbaines: I'm hopping to get calamares working this or next month....
<dvc>if you break it you should be able to choose the last working version
<dvc>on boot
<cbaines>Ah, while I would love an installer for GuixSD, that won't help me installing Guix (as far as I am aware?)
<cbaines>would calamares mean that an installer would be available as an ISO image, as I would love that?
<dvc>cbaines: yes
<dvc>did you break the guix install? how did you manage that?!
<lostcoffee>dvc: I've worked around it, but I was trying to restart slim to use a different wm
<cbaines>Actually, I'm less sure its broken
<dvc>does the wm have a desktop file in /run/current-system/profiles/share/xsessions?
<dvc>then restarting xorg-server should list it...
<cbaines>I'm trying to get build offloading working, and at the moment, I think its erroring on the machine its offloading to with "failed to create remote GC root directory /var/guix/gcroots/tmp"
<cbaines>So maybe I've just not got build offloading setup quite right yet...
<dvc>does the remote machine run lsh?
<dvc>it won't work with openssh
<cbaines>Ah, no it does not
<dvc>I have a hacky patch that would make it work with openssh
<lostcoffee>dvc: I made sure it did, that's what I was working on ☺ I've got it now, but now guile-wm needs work
<cbaines>I have got the logging in part done, at least I thought I have?
<cbaines>dvc, why do you say it does not work with lsh?
<lostcoffee>(or my config of it. The package seems good)
<dvc>because offload.scm uses the lsh ssh client - that's hard coded
<cbaines>Ah, so it uses the lsh client from the offload machine?
<dvc>the lsh ssh client has some trouble with an openssh server...
<dvc>I'm sure you can get it to work if you fiddle with it
<cbaines>That should be ok, as I can just install lsh?
<dvc>it uses lsh on the machine that runs guix build
<dvc>guix build calls the guix-daemon
<dvc>the daemon calls guix offload to see if there is a remote machine available
<dvc>if there is - meaning you declared one in /etc/guix/machines.scm
<dvc>then it will use that one
<dvc>so you need to make sure that lsh can log in to your remote machine too
<dvc>*afk for a couple of minutes*
<civodul>paroneayea: 7% of Debian, damn it!
<civodul>we'll have to auto-generate more package variants
<dvc>civodul: xD
<dvc>civodul: do we have a way to track guixsd installs?
<dvc>I'm guessing we have less guixsd installs than packages...
<cbaines>civodul, when doing the python stuff, I implemented setuptools extras (which are sets of optional dependencies), and created packages for each combination (e.g no extras, set A, set B, set A + B), and obviously this can lead to lots and lots of packages being generated
<cehteh>how do I delete a system generation (from system reconfigure)?
<dvc>cehteh: guix gc --collect-garbage
<dvc>cehteh: you have to run guix gc --delete-generations first
<cehteh>ah that
<cbaines>In other news, I've managed to get build offloading working between my GuixSD system, and my Debian system with Guix (and OpenSSH) installed :D
<cehteh>looks a bit non orthogonal .. there isnt a --roll-back for system configs or?
<janneke>cbaines: nice!
<dvc>cehteh: you should be able to select the previous generation during boot
<cehteh>i have offloading between some vms here :D
<dvc>after deleting the old generations this option is lost...
<dvc>nice! me too! :)
<janneke>i just got cuirass operational on ubuntu+guix
<cehteh>dvc: yes i know, but that doesnt roll it back or? next boot it will boot into the latest generation right?
<dvc>janneke: do you have a recipe for that? I'm interested too...
<janneke>dvc: i think so, depends on what you need
<dvc>cehteh: the idea is that the guix config.scm is the source of truth
<janneke>cuirass is fairly out of the box
<dvc>so you'll have fix config.scm
<cehteh>i see
<dvc>the generations thing helps to unbrick your machine
<dvc>cehteh: you can use git to version control your config.scm if you like
<janneke>i have hacked build-aux/hydra/gnu-system.scm further to also build vms and build my specific package sets
<dvc>janneke: I'm not exactly sure what you mean but it sounds cool :)
<cehteh>i wonder if /root/ would be a better place than /etc for the config .. but maybe i just put /etc under etckeeper
<cehteh>while this way we have editable and generated content in /etc
<dvc>cehteh: it is system configuration and not user configuration
<dvc>but there is nothing stopping you from symlinking it from /root
<cehteh>but root is the admin .. name it /root/system-config.scm then :D ...
<cehteh>but this is just nitpicking
<janneke>cbaines: any findings/recipe that you would like to post?
<cehteh>i just wonder if there could be any more/proper space .. is /gnu writeable by root? /gnu/system-config.scm ...
<dvc>anything is writeable by root, but I'd strongly recommend not to do so...
<cehteh>the store is mounted ro root cant write there
<cehteh>(well with some tricks)
<dvc>ah, but you are running it in a vm then
<edangor>lfam: hi
<cehteh>guix daemon makes a readonly bind mount
<dvc>when you run guix system vm the store from the host is mounted read only
<paroneayea>civodul: :)
<cehteh>nah on a normal guixsd the store is ro
<cehteh>and since the /gnu dir isnt really used for anything but the store yet, i wonder if it would make sense to drop the config there too, cant hurt
<cbaines>janneke, Ludo helped me with the ssh options in the machines.scm file, and I had to fix some issues with the loading of .guix-profile/etc/profile on the offload machine, but those are the only things I remember which are not in the docs
<dvc>well, I'm not actually running guixsd yet... But it sound weird that root can't write there
<cehteh>dvc: actually it exists somewhere else (or maybe its overmounted? didnt checkd the details) but one can make a readonly bind mount where even root cant write
<janneke>cbaines: sweet!
<cehteh>of course root can remount or peek into the original location
<edangor>ok there's no lfam in here, who can help me?
<brendyn>Root could take back write permissions if it wanted to, but you can mount thinks such that just trying to edit a file will be denied. Another way is for example to set chattr +i file and that well make file immutable until chattr -i file is run
<dvc>edangor: you'll have to ask a question before someone can answer
<edangor>dvc: yeah ok
<cehteh>brendyn: well we just talking about accidental tihngs, not intentional
<dvc>*needs to feed his nicotine addiction*
<cehteh>but that counts only for /gnu/store .. i am thinking that /gnu/config.scm would be a nice place for the config
<brendyn>How do I define multiple sources for a package?
<edangor>i did this: "guix system init /mnt/etc/config.scm /mnt --fallback" and I've got this 2 screens & for more than 12 hours
<janneke>brendyn: you can have a look at icetea
<davexunit>a-ha, it's our avr-gcc@5 package that is broken
<janneke>basically, you add extra (origin ..) in native-inputs
<ngz>See also "ghc" for a sligthly less convoluted definition.
<paroneayea>angband seems really easy to package
<dvc>edangor: did you copy your configuration file to /mnt/etc/config.scm first?
<paroneayea>I could package it... and maybe destroy myself..
<dvc>edangor: don't know sounds weird. should probably CTRL-C and try again...
<dvc>edangor: why did u use --fallback in the fist place?
<ngz>How can one specify the location of the CMakeLists.txt file using cmake-build-system? By default, it looks for this file at the root of source dir, but in this case, it is located in the "build/" subdir.
<brendyn>janneke: Ok I'm rather confused. I can't understand it
<dvc>ngz: have you tried passing -DROOT_SOURCE_DIR in #:configure-flags?
<janneke>brendyn: possibly ghc is easier to understand?
<alezost>brendyn: or tzdata
<dvc>ngz: adding a phase before configure that changes the cwdir should work
<edangor>dvc: i made everything acordingly to the manual, and the screenshots are the result of the "--fallback" mode
<dvc>edangor: what screenshots?
<edangor>dvc: &
<brendyn>Ok tzdata sorta makes sense. I never imagined it would be so convoluted to have mirrors
<brendyn>wait no, that's not even a mirror, it's a different thing, tzcode
<dvc>edangor: I see. I have no clue what's going on there... Maybe you have the rare experience of a dead lock?
<dvc>have you tried restarting the installation?
<rekado>sneek: later tell lfam re ardour: “g++: internal compiler error: Killed (program cc1plus)”
<sneek>rekado, you have 1 message.
<sneek>rekado, lfam says: The new Ardour failed to build:
<sneek>Will do.
<rekado>sneek: later tell lfam I didn’t see this on my machine. It built just fine. Maybe we should just restart it…?
<sneek>Got it.
<edangor>dvc: ok the hole problem was that at running: "guix system init /mnt/etc/config.scm /mnt" there was a problem with openldap so lfam told me to do the --fallback and after installing a bunch of things it got like it's now
<rekado>civodul: I was trying to map my two LVs that both sit on a LUKS encrypted device.
<rekado>civodul: the shepherd services that are created for the two LVs (“device-mapper-*”) both fail with the same error, namely that they cannot find “bytevector?”.
<rekado>BTW: tomorrow I’ll give a talk about Guix in HPC:
<rekado>ACTION –> zzZz
<dvc>civodul: I still have to wrap my head around your feedback, but I don't understand what you mean with "Why not, but from the rest of the patch it’s not clear if it’s actually
<dvc>used, is it?"
<dvc>+ (display ,additional-configuration port)
<cehteh>i wonder if i can make a local publish server as proxy, aka my machines only have that server for querying substitutes, and when they are not available there, it fetches them from hydra
<cehteh>(or finally builds them)
<dvc>cehteh: that should be possible... what have you tried already?
<dvc>I think there is a --substitue-urls option you can pass to guix build to point to your server
<cehteh>well publishing is served by http .. if not available one gets a 404 and tries the next substitute or?
<dvc>but I'm not sure what setting up such a server entails
<cehteh>you got me wrong
<cehteh>i meant if *my* server doesnt have the package, instead 404 it should fetch it from hydra (or any other substitute)
<cehteh>transparent to the client, the clients then only have my server configured for substitutes
<cehteh>i guess that needs some hacking
<brendyn>janneke: I want to have multiple urls for the same file as like with mirror://
<dvc>cehteh: I think that --substitute-urls takes a list, so you could prepend your server
<janneke>brendyn: i've seen mirror:// but haven't looked into how it works
<brendyn>It seems to have a list of mirror sites in guix/download.scm
<cehteh>but the publish server wont query them
<cehteh>would be bad if it would do so by default
<brendyn>But that makes sense when many packages share a common mirror system. I just have a single package with 10 possible download locations
<cehteh>anyway .. i am still battleing scheme :D
<dvc>brendyn: you can add a list
<dvc>check the linux-libre package for an example
<dvc>(uri (list "uri1" "uri2"))
<cehteh>Scheme Procedure: guix-publish-service [#:guix guix] [#:port 80] [#:host "localhost"]
<cehteh>how do i translate that into actual code, when i want to set host=
<brendyn>Oh!, thanks dvc
<cehteh>( guix-publish-service ....?..)
<dvc>(guix-publish-service #:host "")
<brendyn>dvc: Would it be OK to randomize the list each time it is built?
<cehteh>doh .. windows feeling .. reconfiguring the system needs a reboot?
<dvc>brendyn: It'll go through the list one by one - I wouldn't
<dvc>cehteh: that doesn't sound right
<dvc>I think that reconfigure doesn't restart services at the moment
<cehteh>not it does not
<dvc>so you'll have to do that manually till the 1.0 release, it's on the roadmap
<cehteh>but i did herd restart guix-publish and it still took the old value
<brendyn>dvc: Maybe we should change guix to select randomly if it is a list, to aleviate mirror load?
<dvc>brendyn: I've suggested that before - you'll have to talk to civodul about this
<dvc>but usually if load is a problem the main download link already does load balancing
<brendyn>Well this one doesn't
<ngz>dvc: Does -DROOT_SOURCE_DIR expect an absolute path ?
<dvc>ngz: we usually use absolute paths in our packages - don't know if it's explictly required, the cmake docs may tell you more
<dvc>so that would be #:configure-flags (list (string-append "-DROOT_SOURCE_DIR" (assoc-ref %outputs "out") "/build"))
<ngz>Yes, I'm currently trying this. Thank you.
<dvc>civodul: extra-version is a kernel thing - I explicitly chose that name since it's "a thing"
<ngz>(with an additional "=" after DIR)
<dvc>ngz: :)
<civodul>dvc: oh, fine then :-)
<civodul>anyone has Guix on armv7 here?
<civodul>i'd like someone to test this: in nix-system->gnu-triplet in guix/utils.scm, replace "arm-" with "armv7l-"
<civodul>and then: ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gcc-final)'
<ngz>dvc: Failure. This argument is ignored altogether. Only the first argument in the list is taken in consideration (cmake is called with the directory containing the source as its first argument).
<dvc>civodul: yesterday I tried building the linux-libre-beagle-bone-black on my bbb but got a failed to allocate memory after 6h... Maybe it's related to the bug you found where it always passes a configuration-file
<dvc>after that openldap failed to build on arm...
<dvc>so I gave up :)
<dvc>civodul: why do we depend on openldap?
<civodul>for linux-libre? no idea
<civodul>it does sound surprising :-)
<dvc>no for guix
<dvc>guix environment guix requires openldap for some reason
<civodul>"guix graph guix" doesn't show any dependency on openldap
<dvc>weird, I'll have to look into it... but I've heard a few reports in the last few days that guixsd install failed and people had to use --fallback
<dvc>because of openldap
<civodul>oh, that sounds bad
<dvc>anyway - I've got to go... I posted another question earlier, regarding your feedback, don't know if you've seen it...