<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 :) <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 :) <dvc>OrangeShark: Nice! How do you like it? <OrangeShark>it is alright, the people are nice and stuff, but the code base... <dvc>haha. I worked for a project on a 4 day old codebase from a different team - that was bad enough <davexunit>I use guix to provide a lot of my dev tools, though. :) <OrangeShark>I actually mentioned guix in the interview for it haha <dvc>timeout is not a very helpful error message... <lfam>We could try updated python-pillow. There are several later versions <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? <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... <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: 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 <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>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>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: http://nixos.org/~eelco/pubs/ ***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 <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>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... <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... <dvc>mark_weaver: openldap fails to build on arm, I'm screwed with the bbb project, giving up :) <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>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 <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>you might have a negative cache entry in your substitutes cache, though. <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 ? <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 ***tschwing_ is now known as tschwinge
<mark_weaver>snape: run this as root: find /var/guix/substitute/cache/ -size 106c | xargs rm -v <mark_weaver>snape: run this as root: find /var/guix/substitute/cache/ -size -106c | xargs rm -v <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 <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 ? <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 ? <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' <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) <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>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>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) <wingo>otherwise if it is just a simple package with no module decl you might try (load "./path-to/fo.scm") <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 <janneke>gunoob1: i think after reconfigure your packages should show up in /run/current-system/profile/ <gunoob1>oh.. indeed ... thx.. just made an typo. <adfeno>I'm trying to make a Guix package recipe... <gunoob1>at least i can give you a very simple example that works <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. <adfeno>I have annotated the build command used, just visit the link I gave and scroll to the bottom to see the annotation. <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>First, I'll see if `guix download` and `guix hash` produce different hashes. <adfeno>They do produce different hashes... <adfeno>(Another paste since the recipe was changed). <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): <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 <adfeno>civodul: Did you experienced it rescently? <civodul>rekado: open-luks-device does (use-modules (rnrs bytevectors)) <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>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>BTW, IIRC, Wine is in the same situation (32 bit build only) <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 <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. <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? <dvc>so doesn't build yet? <lfam>JamesRichardson: Okay, there was a recent change related to the motd. I recommend `make clean-go` in case of ABI breakage <lfam>Ah, so the test should be adjusted <lfam>Actually, it's not just the test. `guix pull` is broken too <dvc>yep sorry about that... xD <lfam>Perhaps it's best to revert the change while we adjust the 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 :) <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... <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" <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. <jmd>One option would be simply not to display them by default. <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 serious...is there any way to heuristically identify those? <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. <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 <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>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>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? <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>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 :) <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>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?) <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 <janneke>lostcoff`: write it to: out "/share/xsessions/" <janneke>and install guile-wm into the operating-system's packages <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 work...got 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? <dvc>I think better collision resolution is on the roadmap for 1.0. But we shouldn't hide the warnings for now... <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>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 ☺ <dvc>lostcoffee: herd status to find the name of the service <dvc>maybe display-manager? <dvc>herd stop display-manager && herd start display-manager <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? <paroneayea>just realized that being over 4k packages means we are > 1/3 the packages in nixos :) <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 <brendyn>It doesn't matter, the current duplicity version is from 2015 <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? <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 <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>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 <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 <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? <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>we'll have to auto-generate more package variants <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 <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? <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... <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 <dvc>so you'll have fix config.scm <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 ... <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 <dvc>ah, but you are running it in a vm then <cehteh>guix daemon makes a readonly bind mount <dvc>when you run guix system vm the store from the host is mounted read only <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 <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 <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? <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. <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? <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? <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)” <rekado>sneek: later tell lfam I didn’t see this on my machine. It built just fine. Maybe we should just restart 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?”. <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>+ (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 <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>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 <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=0.0.0.0 <dvc>(guix-publish-service #:host "0.0.0.0") <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 <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 <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) <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>civodul: why do we depend on openldap? <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>anyway - I've got to go... I posted another question earlier, regarding your feedback, don't know if you've seen it...