***samigarus is now known as oahong
<lfam>Can someone give me a refresher on the difference between inputs and propagated-inputs? I thought that propagated-inputs were installed into my profile along with their referrer. But I have a WIP python package with tons of propagated-inputs, and it works, but they are not in my profile. So clearly I don't understand fully. <Steap_>lfam: weird, I use "propagated-inputs" for inputs that I need at runtime <Steap_>not sure whether they actually end up in your profile, but aren't they at least in your PYTHONPATH? <lfam>They must be because the software works :) <lfam>I've seen propagated-inputs in my profile before, but that wasn't for python. Maybe the python-build-system does some magic to keep the profiles clean? <Steap_>I'm pretty sure that if you install "python-foo" and "python-bar" is one of its propagated inputs, then pytho-nbar cannot be removed by "guix gc" as long as python-foo is installed <lfam>My understanding is that native-inputs are build-time only dependencies, inputs are run-time dependencies whose paths can be patched into the source files, and propagated-inputs are run-time dependencies that must be on some variant of $PATH. Is that correct? <lfam>I think I used to know this better... the last few weeks have damaged my brain :p <Steap_>native-inputs is used for cross-compilation <Steap_>if you need autoconf/automake/... you want to run a version that works on the build machine <lfam>Ah, the meaning of "native" <lfam>Well, I have a ton of packages that make up the lets-encrypt client and its closure. TBH I'm not sure what type of input every dependency should be. I will send the patches as WIP to the ML for advice. <lfam>It would be nice to have the package ready for the open beta on 2015-12-03 <mark_weaver>lfam: if package A has package B as a propagated-input, and package A is in your profile, then package B will also be added to it, but B still won't show up in the output of "guix package -I" ***hacker is now known as y
***y is now known as exio
<lfam>I see that the build system has automatically wrapped the output binaries to provide PYTHONPATH. Nice! <lfam>Now I will test wrapping the wrapper <davexunit>are there any ARMv7 boards that have a liberated GPU? <davexunit>I want an ARM machine similar in size to the raspberry pi, but with free gpu drivers. I don't think there's anything around yet. <davexunit>there's a metric ton of dependencies for this thing. <davexunit>and I still can't it past the bootstrap phase ***mark-otaris is now known as mark_otaris
***bmpvieira_ is now known as bmpvieira
***bmpvieira_ is now known as bmpvieira
<fps>btw: i just had a discussion with thorwil (linux audio buddy) about packaging unity <fps>and how other distris have problems with it since it uses hacky-patched versions of some libs <fps>might be a showcase for guix ;) <rekado>well, we are not happy with "hacky-patched" libs either :) <rekado>bundling of patched libs is a common annoyance. <fps>rekado: but at least it's possible rather easily to separate the dependencies of different packages <fps>so the hacky-patched libs don't break everything else <fps>hmm, if a package definition inherits from another and i want to add an input <fps>won't specifying input completely override the inherited one? <rekado>fps: yes, but you can reference the other inputs with (package-inputs the-package) <rekado>the guile-emacs package does something like that, for example. <fps>rekado: oh, awesome. thanks <civodul>andreoss: it's not working as expected currently? <civodul>i'm not sure exaclty where curses looks for termcaps <andreoss>Cannot find terminfo entry for 'rxvt-unicode'. <andreoss>i guess it should be TERMCAP variable pointing somewhere in .guix-profile <civodul>'screen' doesn't even print anything in rxvt for me <civodul>andreoss: could you send this info to bug-guix@gnu.org so we don't lose track of it? <andreoss>though it searches for files in /usr/share/terminfo and i don't have rxvt-unicode there <andreoss>.guix-profile/share/terminfo/ misses that file too <Steap_>ACTION has finally installed GuixSD <mthl>Steap_: how does it feel? <mthl>That was part of the expected effect ;) <andreoss>civodul: after all it seems to be a bug either of ncruses or urxvt, so i'm not sure why debian's urxvt works without this file <amz3>st also requires to install terminfo file to work properly, but the feature is disabled <amz3>ACTION will install st to see how it works ***brainpro1 is now known as brainproxy
<civodul>andreoss: maybe the urxvt package for Debian installs terminfo where ncurses expects it? <Steap_>btw, I'm thinking of running (parts of) OpenStack as a set of services <rgrau>hi guixers. Is gitk packaged for guix? I can't find it , but there's 'tig' which is much less common. <Steap_>but I'm a bit worried about the proper way to do this <civodul>Steap_: yes, i'm guessing you could come up with a nice testing environment for OpenStack <civodul>like if it could start the various daemons and all that <civodul>which you don't get with 'guix environment' alone <Steap_>OpenStack comes with incredibly long config files, and it seems like we do not just pass a config file to the services <civodul>Steap_: you can pass whatever files you want <civodul>see local-file and plain-file, for instance <civodul>yeah, see how syslog-service does it <civodul>or some other service of your choice ;-) <Steap_>do we have services that need some kind of bootstrapping as well ? <rgrau>installed git:gui, thanks. Is ':' a special syntax for sub-packages ? 'guix package -s git' doesn't show git:gui . <Steap_>civodul: for instance, Keystone, the authentication module of OpenStack, must be configured by doing: <Steap_>1) running it with a config file containing a "secret" token <Steap_>2) use that token to create an "admin" user <Steap_>3) re-run Keystone without the secret token <Steap_>4) do whatever you want using the "admin" user <Steap_>I feel like it is going to be a bit of a pain <civodul>wingo: ooh that's iElectric of NixOS <Steap_>wingo: yeah but I do not think they run services as well, do they ? <civodul>that's also a company Igalia works with, right? <wingo>we work with snabb, yeah -- they decided to build all their things on nixos, with some docker stuff as a shim for people that want more 'normal' environments <Steap_>iElectric: aren't wheels binaries ? <Steap_>I fail to see howthat integrates well with a source-based package manager <wingo>igalia works with snabb, i didn't mean to imply that you iElectric worked with igalia, sorry for the confusion :) <wingo>very excited to see the nix uptake in the snabb world tho! <davexunit>Steap_: does the build system produce wheels, or does it download them from somewhere? <Steap_>davexunit: iirc, you can download a wheel from PyPI which is just a binry <iElectric>so now we have buildPythonPackage that builds wheels from source and then installs it <Steap_>but I'm lost in Python packaging <iElectric>we could override it and have buildWheelPackage that replaces build step by just unpacking a wheel <Steap_>iElectric: isn't the point of wheels to not build stuff ? <civodul>as a user, what difference does it make if it's "wheels" vs. "eggs"? <iElectric>Steap_: python folks dream of the world where they can tag wheels and ship them to all linux distros <iElectric>that will just never happen because binary compatibility is a mess <Steap_>iElectric: let alone Python and Python packaging <iElectric>civodul: not much, wheels are documented and specified <Steap_>iElectric: the main issue is I depend on their crazy dreams to make a living <Steap_>iElectric: but how is it better for Nix to have wheels instead of the normal stuff ? <civodul>so "wheel" is immature, and "eggs" are deprecated <Steap_>ACTION likes to do "python3 myscript.py" <iElectric>python setup.py build -> python setup.py bdist_wheel <Steap_>civodul: C never changes, Python changes every 5 years, Javascript changes every 5 days <iElectric>python setup.py install -> pip install bla.whl <Steap_>davexunit: you can build the .whl anyway <davexunit>we unpack a gem, build a new gem, and install *that* gem. <Steap_>davexunit: same craziness in the build/packaging tool <Steap_>Python is easier to write than C, but you get craziers tools <davexunit>python and ruby is seriously amateur hour when it comes to this stuff <davexunit>yeah but good luck actually satisfying dependencies without using npm <davexunit>I tried and it's a nightmare. npmjs.org hosts *binaries*, not source, so it's useless. <davexunit>and the node folks think it is just swell that they don't ship corresponding source. <davexunit>so I guess we're left with having to build things from tarballs off of github <davexunit>that aren't proper release tarballs, just gzipped snapshots of the repo. <davexunit>paroneayea attempted to package jQuery, only to find that the 'node_modules' directory had *hundreds* of 'node_modules' directories within it. <davexunit>so the road to even having something as simple as jQuery available seems treacherous. <Steap_>do people actually install jquery ? <davexunit>Steap_: wouldn't it be nice if your web application didn't have to bundle copies of its javascript dependencies? <Steap_>davexunit: yes but Javascript is already crappy enough <Steap_>+ my "web applications" are simple enough <Steap_>so I can just copy that jquery crap <Steap_>but yes, that is terrible engineering <davexunit>then if you distribute that to someone, you aren't actually providing the source code <davexunit>I tried to compile firmware for my arcade stick several months ago and couldn't get it to work. <Steap_>iElectric: so, does Nix allow users to define services (like Guix)? ***JamesJRH_ is now known as JamesJRH
<civodul>Steap_: NixOS allows that, of course <Steap_>civodul: yeah, not sure whether that was done in a similar fashion <Steap_>iElectric: are you thinking of adding services for Keystone, Nova etc. after everything is packaged? <rekado>davexunit: no, avr-gcc fails with a linker error for me. Haven't investigated more yet. <rekado>very sad, because I'd like to hack up a little MIDI tool and recently rediscovered microscheme. <davexunit>rekado: yeah, I'd like to tinker with some stuff, too. <rekado>davexunit: I thought it would just be a matter of adding some search path or patching the sources. <davexunit>I can't remember what I tried, but I tried a good number of things <davexunit>would love to be able to flash my arcade stick's firmware again :/ <davexunit>I'm also looking into making my own handheld ARM computer <davexunit>and part of that project would involve an Ateml microcontroller which I'd need avr-gcc and avrdude for. <davexunit>though this project is dead in the water because I don't know of any small ARM board that has libre hardware accelerated graphics. <bavier>they're a bit tight on who they send <civodul>bavier: one wouldn't expect that from such companies ;-) <Steap_>From what I've heard, it is mostly people paying to be able to hear propaganda from Intel & co. <mark_weaver>civodul: so, I was thinking, as a way to make 'guix pull' builds go faster and also evaluations, maybe we could split the building of guix into a bunch of finer-grained derivations, where each one compiles a single file, and has as inputs the files it references. <mark_weaver>of course, the circular dependencies between modules are perhaps a blocker for this, but IMO we should try to eliminate those anyway. <mark_weaver>we could start by only making the package modules compiled in a fine-grained fashion. <mark_weaver>the rest of guix could be compiled in a single derivation that build everything except for the package modules, and that would be an input to all the other derivations. <mark_weaver>and then there'd be one derivation per package module <civodul>i think what taylan came up with is already an improvement for 'guix pull' (we should commit it BTW) <civodul>but evaluations are a different story <mark_weaver>and then a final derivation that puts it all together. <civodul>yes, that could work for guix pull maybe <civodul>for evaluations we need a different solution <civodul>because Hydra basically just runs build-aux/hydra/gnu-system.scm <iElectric>bavier: even worse, continiuum got 20M for conda package manager that is a bad copy of Nix/guix <bavier>iElectric: conda has some significant traction through some high-profile funded HPC projects <civodul>mark_weaver: there's a chicken-and-egg problem for hydra, similar to guix pull <civodul>for guix pull, we use the currently-installed guix to build the new one <civodul>so we'd be doing something similar for Hydra? <civodul>or we could build guix/*.scm and evaluate gnu/packages/*.scm <bavier>conda is their preferred non-binary distribution method <iElectric>which is the only reasonable funding for package managers <Steap_>iElectric: I took a look at your Keystone configuration in NixOS <iElectric>bavier: but in Nix we'll soon be better than conda wrt python packaging <Steap_>iElectric: are you leaving the authentication through the admin token as a possibility ? <iElectric>Steap_: currently that's just something I typed in together <Steap_>but should be removed once there is an admin user <Steap_>otherwise that is a security issue <iElectric>Steap_: could you leave a comment about that? <taylan>civodul: I kind of had to take a break, will get back to working on it soon I hope <civodul>taylan: great, and np; taking a break is always helpful <iElectric>Steap_: do you know how to setup openstack and operate it? <civodul>mark_weaver: hackish idea: it might be that in gnu-system.scm, replacing (set! %fresh-auto-compile #t) with (set! %load-compiled-path '()) would work better? (evaluate everything instead of building everything) <Steap_>no, I'm just an OpenStack developer. <Steap_>iElectric: but I was trying to set up Keystone last night, in order to write a service for Guix <Steap_>and it seems to be done with a bootstrap phase, as I wrote on your PR <Steap_>I think it would make sense to let the user provide their secret token <Steap_>then they can add an admin user to the SQL database <mark_weaver>it's worth a try, I suppose. I'm not sure how well it would perform. <Steap_>and then, reconfigure the service by removing the secret token <Steap_>after that they can just set OS_USERNAME, OS_TENANT_NAME etc., and use Keystone as they would do on Debian/Fedora/whatever <civodul>mark_weaver: "guix lint -c derivation", which builds all the derivations, takes ~15s on my laptop; that's the best we could possibly achieve <Steap_>if someone guesses the secret token, they might be able to do a remote attack, so that'd be pretty bad :) <civodul>mark_weaver: here (guix derivations) and friends would be evaluated, so we get a 2x or more i guess <davexunit>rekado: how do you like microscheme, anyway? <davexunit>I know that in C there is LUFA which can do tons of stuff out-of-the-box <mark_weaver>civodul: as a half-way measure, we could compile some selected modules with the hottest code, and evaluate the rest. <davexunit>isn't it all hot code once the user does 'guix package -s foo' ? <mark_weaver>well, I'm assuming that the package derivations are memoized, so hopefully most of the code in gnu/packages/*.scm is only run once per evaluation. <mark_weaver>I guess I should point out that although my initial idea above was for optimizing all builds of 'guix' (include evaluations on hydra, 'guix pull', and 'guix build guix'), our immediate concern is optimizing evaluations on hydra, and civodul's recent suggestions are specific to that. <mark_weaver>and they have the benefit of being easier to implement <mark_weaver>civodul: setting %load-compiled-path to '() seems too extreme. we want to be able to load Guile's own compiled modules. <rekado>davexunit: I haven't actually used microscheme for anything yet. I did most work in assembly in past projects. <rekado>but I think I got avr-gcc to work. It's just not pretty how I did it (see emails to the list) <civodul>mark_weaver: good point, i *think* %load-compiled-path doesn't affect Guile's own modules, but i'm not completely sure <civodul>mark_weaver: so we would set %fresh-auto-compile to #f and call 'compile-file' for guix/*.scm for instance? <mark_weaver>civodul: I suspect it does. GUILE_LOAD_COMPILED_PATH doesn't, because it is only part of what goes into the default value of %load-compiled-path <mark_weaver>civodul: as long as there are no possibly stale *.go files for guix modules in %load-compiled-path <davexunit>rekado: thanks for the report. I'm going to try to compile my KADE firmware again and see if your hacks make it work. <civodul>davexunit: in guix env --container, /homeless-shelter appears to be writable <civodul>any idea where those files are going? :-) <civodul>it's basically in /tmp/guix-directory.xxx, right? <civodul>mark_weaver: 1m31 to autocompile everything on my laptop, per: time guile -L . -l build-aux/hydra/gnu-system.scm -e '(hydra-jobs (open-connection) (list))' <civodul>it's on an SSD, but still, hydra.gnu.org has serious i/o issues <andreoss>how can i skip bootloder instalation in system-init? <andreoss>should chroot work for inited directory? <andreoss>/mnt/var/guix/profiles/per-user/root/ is missing <andreoss>davexunit: i meant would i chtoot in some working evironment this way <andreoss>i did't, i have only bash in /bin and profile is missing <rekado>how do I add custom udev rules in GuixSD? <rekado>I see that %base-services has a udev-rules expression, but I don't know where the rules come from. <rekado>oh, I was reading the old manual; no wonder it didn't say anything about the new extensible services... <nalck>Hello, I am sorry to say I've been unable to get GuixSD running on three different machines. <davexunit>rekado: couple of issues that jump out to me: avr binutils not a public package, easy fix. missing native search paths on the avr-gcc <taylan>nalck: can you report bugs detailing what went wrong? :) <davexunit>added "avr/include" and "avr/lib" to avr-gcc's native search paths <nalck>I am looking through the bug db now. <nalck>I would like to ask before reporting: have there been problems with the GuixSD servers? <nalck>It seems that the install process breaks because of server issues. <davexunit>rekado: bah, another problem that I solved awhile ago but forgot about... avr-gcc doesn't respect the usual env vars! <nalck>I see. I found the install process quite painless otherwise. <nalck>Are there steps I could take to work around this overload? <davexunit>we are trying to figure out how to raise the money to buy dedicated machines for our build farm <nalck>How much do you need, roughly speaking? <mark_weaver>replacing hydra will probably be on the order of 1000 USD, although I haven't fully spec'd it out yet. <nalck>Do you intended to replace the software also? <mark_weaver>initially, no, except to switch to GuixSD from Trisquel. <nalck>Thanks for the answers, sounds good. <sprang>are you able to take donations through the FSF yet? <nalck>Is the GuixSD Hydra port very different from the NixOS version? <efraim>I looked a bit at SPI since we mentioned them a while ago, but their thing is at the end of the day any hardware they buy on our behalf is owned by them and nontransferable to another 501c3 <mark_weaver>well, if someone wanted to donate a significant amount now, we could arrange it even before we're officially part of the Free Software Fund. <nalck>Frankly, the GNU side of GuixSD is far less interesting than the Scheme part. <mark_weaver>and that would certainly be helpful, since hydra is obviously badly overloaded, and the legal stuff is taking a bit longer than we hoped. <nalck>I'll talk to some friends interested in the project about these matters. <mark_weaver>iiuc, our hydra instance is only slightly modified from the one at NixOS <nalck>We'd speculated that the build servers were somehow at fault. <nalck>Also, GuixSD doesn't support 32-bit machines at all, correct? <rekado>davexunit: "avr-gcc doesn't respect the usual env vars" <-- like what? As a cross-compiler it doesn't have to respect LIBRARY_PATH, as far as I understand. <sprang>mark_weaver: if it would still be tax-deductible, I could donate something sooner rather than later <rekado>I have it running on a Thinkpad T60. <mark_weaver>the main problem with our hydra is that it's an underprovisioned VM, with not enough memory allocated to it, and with a very braindead RAID set up that basically turns every disk operation into multiple accesses with seeks across the disk. <davexunit>rekado: I try to compile a firmware and it complains that it can't find <avr/io.h> <rekado>davexunit: that's part of avr-libc. <mark_weaver>sprang: yes, it would still be tax-deductible, to the FSF. basically I would just have to give John Sullivan a heads-up that a particular donation was intended to go to us. <davexunit>but I need to set some search path for avr-gcc to find it <davexunit>I recall it being difficult to figure out before <nalck>rekado: It failed on my Samsung N310, possibly the Hydra issue. <rekado>this is also the reason why I had to copy "$out/avr/lib/avr5/crtm328p.o" because avr-gcc doesn't know that it should look in the output of avr-gcc. <mark_weaver><nalck> Also, GuixSD doesn't support 32-bit machines at all, correct? <mark_weaver>nalck: GuixSD supports, x86_64, i686, armhf, and mips64el <mark_weaver>oh, sorry, I mispoke: Guix supports those platforms. GuixSD itself only supports x86_64 and i686 at present. <mark_weaver>on armhf and mips64el, it has to be run on top of another system. <nalck>I know that these are the official lines, but being at 0.9 I thought it may simply be out of order. <davexunit>rekado: debian works without all this hubub somehow <nalck>My i686 pc could not boot post-install. <nalck>It is possible that I made an error. <nalck>I think I will wait until the next release and attempt again. The project seems quite promising. <mark_weaver>(I actually have GuixSD running on a Lemote YeeLoong (mips-based), based roughly on the wip-loongson2f branch, but it hasn't yet been fully merged into master) <mark_weaver>we definitely support i686. I'm typing this on a Libreboot X60 running GuixSD. <davexunit>I've also installed guixsd on a 32 bit machine in the past <davexunit>mark_weaver: have you tried building the as-of-yet unreleased GRUB with ARM support? <mark_weaver>nalck: were you able to boot our USB installer on your i686 machine? <nalck>Oh yes, the install went swimmingly. <mark_weaver>okay, then you probably made a mistake in your OS configuration. <mark_weaver>once you have one good configuration, then you can always roll-back to it easily, but getting the first OS configuration right is a common hang up for new users. <nalck>I see. What do you recommend viz. disk encryption? <nalck>For me FDE is a requirement. <nalck>I did it all manually, with success. <nalck>But once booted into the operating system, the machine kicked over. <rekado>davexunit: full disk encryption works, but LVM with encryption does not. <taylan>only 1k $ (or a bit more) to replace Hydra? that's nice. <davexunit>rekado: you can't encrypt the root partition <davexunit>civodul has an encrypted /home, but not an encrypted / <nalck>Why not? Can't you simply have GRUB unlock the disk? <mark_weaver>davexunit: I think you're mistaken about that. I thought we resolved that. <rekado>I have an encrypted /home, too (though it's not mounted on boot). <davexunit>mark_weaver: I will gladly stand corrected, but I seriously remember this being brought up just before the 0.9.0 release when someone found a problem <mark_weaver>as I recall, a couple of months ago karhunguixi wanted an encrypted root, and I looked into it and suggested a patch to our initrd code to enable it, and he got it working, posted the patch, and it went into master a while ago. <nalck>I don't mean to step on toes, but is this a Libre kernel issue? <nalck>(I have little experience with such) <nalck>I don't see how GuixSD should be different than any other system that implements GRUB and LUKS. <mark_weaver>the issue was that we have a very unusual initrd system based on guile, and it needed to be adjusted to support an encrypted root partition, but as I recall we resolved it a while ago, and karhunguixi has been successfully using GuixSD with an encrypted root. <nalck>so "mkinitcpio -p linux" isn't an option. <rekado>davexunit, mark_weaver: see commit 316d65b <mark_weaver>okay, so, as I recall, karhunguixi is using Libreboot, which includes GRUB and grub.cfg burned into the boot ROM, so it doesn't actually use GRUB from GuixSD. <mark_weaver>there may still be issues with using an encrypted root partition on a non-Libreboot machine. <nalck>Libreboot is an aftermarket BIOS, correct? <mark_weaver>nalck: not a BIOS, but a boot program. it's basically coreboot with the non-free blobs removed (so it only works on a few machines, but yay for no more back doors like Intel AMT), and packaged in a way that makes installation vastly easier than coreboot. <mark_weaver>it does part of the job than a BIOS does, but doesn't provide all the functionality of a BIOS. it can be used together with SeaBIOS if you really need a BIOS. <mark_weaver>but GRUB can be compiled to work on coreboot/libreboot directly, so there's usually no need to SeaBIOS. <mark_weaver>the folks at #libreboot can tell you more about all of these details. <mark_weaver>but if you don't like the idea of your machine having a separate processor running a complete proprietary OS with direct access to the entire system memory, BIOS configuration, and out-of-band network access, accessible remotely even when the machine is powered off, then I would recommend checking out Libreboot. <mark_weaver>e.g. the hardware is rigged so that incoming network packets of a certain kind will be directed to the AMT without the host OS even seeing the packet. <rekado>I wonder: should service type constructors in (gnu services base) not be exported? <rekado>I want to create a service of type "udev-service-type" so that I can add a custom udev rule. <mark_weaver>rekado: sorry, I've been too overloaded lately to learn the new service refactoring yet. <rekado>at least field accessors like "udev-configuration-rules" should be exported I think, or else it would not be possible to easily extend existing services. <nalck>Thanks everybody, hopefully we can get those build servers boosted :). <davexunit>ooh, I finally located a 4.3" LCD screen with a free hardware controller board <davexunit>I want to make a mini ARM machine (and run Guix on it, of course) <efraim>not sure about the free hardware side, but 96boards.org has some ~$100 arm64 boards <rekado>davexunit: please blog about it! <davexunit>rekado: will do, if this ever becomes more than just a nice thought! <mark_weaver>davexunit: the wandboard seems pretty decent, and has the same processor as the Novena. <davexunit>mark_weaver: do you think it could be used in a handheld computer? <mark_weaver>I guess that means that it's in the same boat as the Novena in terms of graphics acceleration. <davexunit>because that GPU driver is actively being worked on <mark_weaver>*nod*, it's about the best we have in the ARM world for graphics acceleration, afaik. <davexunit>I am hoping that I can run something off of a small battery, the raspberry pi would be great... if it didn't need blobs <davexunit>I do currently own a raspberry pi (buyer's remorse), so I could prototype with it until a real solution comes along. <davexunit>rekado: my parts list is quicly becoming very expensive, though. $80 for the screen really jacks the price up. <rekado>for a one-off assembly it's expensive; how about the prices if a bulk order is made? <davexunit>I'll be lucky if I actually buy all the parts and don't get bored <roelj>I'm preparing a patch for Guix, but when I use git format-patch it generates 164 patches! I only changed one file.. What am I doing wrong? <efraim>I also normally tell it exactly how many patches I want with -1 for 1 <roelj>efraim: Yes. And the -1 works! Thanks a lot ***octe_ is now known as octe
<roelj>Which commit id is supposed to be in the "From:" field? <paroneayea>I need to supply my ssh key to the VMs I'm auto-generating for guixops stuff, but I'm not sure where to do it. Normally I'm used to putting things in ~/.ssh/authorized_keys <paroneayea>but home-things are mutable state, not really described by the guix system stuff <paroneayea>okay I guess I'll try with passwords initially for now <davexunit>a question I have is: can we do this without involving home directories? <rekado>roelj: I don't think this matters. Just attach whatever "git format-patch" produces to an email. <alezost>roelj: commit? in "From:" you specify your email address <paroneayea>davexunit: I guess it depends on if lsh's config permits taht <civodul>paroneayea: it's an unsolved issue, but you could hack your way around it :-) <civodul>namely, you could extend activation-service-type <civodul>by adding code that copies the key in the right place <alezost>roelj: oh, you mean inside a patch; you shouldn't modify the generated patch <davexunit>there *has* to be a way to specify authorized keys without silly home dir stuff <paroneayea>yes we'll have to do it if we want to succeed with guixops <paroneayea>figuring out how to get this image up to openstack is enough to do right now <civodul>we could package it as a user-file-service or something <paroneayea>civodul: I'll queue this as something to look at. <davexunit>the service layer is the place for stateful stuff <davexunit>I like the clean separation between stateless and stateful that guix maintains. <civodul>i think i'll write about it on the Savannah thing ***boegel|quassel is now known as boegel
<davexunit>so people that aren't us know why it's so cool <civodul>yes, i realized we should do more of this <efraim>where does root store their authorized ssh keys? <davexunit>it creates the home dirs for all users who are configured to have home dirs <civodul>guix env --container is awesome: you can just go ahead and launch a daemon in there <civodul>it has its own database and everything <davexunit>and you can persist the database between runs if you want with --share <civodul>we'd need to have a unionfs layered on top of the real store <civodul>because here the daemon can't actually modify the store <davexunit>you couldn't have a completely separate store without changing the prefix from /gnu/store <efraim>or change the --share option to --share=host_location::container_location <civodul>yes but the store is automatically mounted <hhynek>I'm just trying out guix for the first time, playing with it to see what it does and what it feels like. (On Debian, so no GuixSD.) <efraim>i suppose it could be a security risk to let the container add to the store, even if guix gc were disabled in the container <civodul>efraim: yes but there's no such risk since the container doesn't have write access to the real store <efraim>right but i mean if it were given write access <civodul>did you see a message like "updating the list of substitutes"? <roelj>I had to add hydra to the trusted list (it's in the manual). <roelj>before it would download substitutes <hhynek>I did run the "guix archive --authorize" command with the .pub file from the tarball and it doesn't say anything. <hhynek>It says that "server is somewhat slow" so I thought perhaps it has some problems now. <hhynek>If that's not the case then I'll have a closer look at it :) Thanks. <civodul>hhynek: it's just slow, but that's fine, you just have to wait a little longer ;-) <civodul>that server's slowness is a known issue that we hope to address Real Soon <hhynek>Well, when I do guix build --dry-run, it still says "The following derivations would be built" <hhynek>I expected something different from the manual <keverets>is there an easy way to tie M-x doctor to ERC to form a quick-and-dirty bot? <civodul>mark_weaver: "time XDG_CACHE_HOME=/tmp/cache guile -L . -l build-aux/hydra/gnu-system.scm -c '(hydra-jobs (open-connection) (list))'" with an actual connection to the store takes 2m5s on my laptop <rekado>alezost: "M-x guix e pkg-name RET" is extremely useful! <rgrau>btw, I was trying to use guix.el, and I'm finding some issues: guix-init.el does a (require 'guix-autoloads), but this file doesn't exist. also, I see some .el.in, which probably have to be 'compiled', but there's no make in there. <rgrau>this is from the git source. but I installed the binary guix, and can't do a full compilation of guix from source <rgrau>oks. Is it really necessary to have the built guix to use guile.el? Or it's just something in the TODO list? <davexunit>to generate the files that the .in files correspond to <alezost>rekado: I also think so :-) I even bound "M-x guix-edit" (which is the same) to a global key <alezost>rgrau: no it is not necessary; if you used a binary installation method, you can just install guix into your profile: see (info "(guix) Emacs Initial Setup") <hhynek>Could it be that substitutes are not downloaded from hydra when I use a different store directory than /gnu/store? <davexunit>hhynek: yes, you will build everything from source that way. <hhynek>I'm just looking at guix/scripts/substitute.scm, line 571, and it seems to try to match my store prefix with a prefix that comes from hydra <davexunit>changing the store directory changes the hashes of everything <davexunit>and thus you won't be able to get any substitutes <hhynek>Oh, ok, at least I know why it doesn't work. <Digit>any more video presentations planned? i really liked those, n i'm sure theres much more that can be explored/explained, n many peeps who've yet to be exposed to guix / guix sd. :) <hhynek>Out of curiosity, perhaps it's obvious, but why is store directory part of the hash? <davexunit>hhynek: because naturally there are references to other store items that appear in the built software <davexunit>plenty of software will use an absolute path to refer to something <davexunit>and we also do things like refer to shared libraries via absolute paths <davexunit>so different store directories will cause different build results <davexunit>oh no, I don't know if this one is really a free hardware design <mark_weaver>civodul: after the build-aux script finished, the latter part of the evaluator code (the perl script that creates the builds, etc) seems to be stuck. the last thing it printed was "warning: SQLite database is busy" <bavier>davexunit: the schematics appears to be on their wiki <davexunit>"All of our software and hardware are created with open licenses – meaning anyone can use or alter them as they wish" <davexunit>the work on freeing the novena's GPU will apply directly to this <bavier>I was considering getting one; it'd be nice to have other guix hackers using it <davexunit>now to make sure that other blobs aren't needed <Steap_>davexunit: pardon my ignorance, but can you really trust hardware, since you cannot "recompile" it ? <mark_weaver>Steap_: the answer is "no", but it's the best we can do now <davexunit>Steap_: that's a tricky question, but I'm trying to support people who do publish specifications <rekado>bleh, avrdude says it's been compiled without USB support :( <rekado>"DON'T HAVE libusb" but "DO HAVE libusb_1_0" <davexunit>I believe I have sourced all the parts I need for what I want to do. <mark_weaver>Steap_: anyway, these are only free board-level designs at this point, and the other thing we can hope for now are chips with good documentation that can be freely acquired without NDA. <davexunit>I just want to do my part in supporting the people that are taking the first steps towards liberated hardware. <davexunit>and that hardware tends to work with less or no blobs <mark_weaver>on the hopeful side, work is being done on free CPU designs, e.g. lowrisc <civodul>mark_weaver: the Perl part has to parse loads of XML, so it's probably not very fast <civodul>the warning happens when there are concurrent accesses to the sqlite db <rekado>yay, it works. Just needed to add libusb-compat in addition to libusb. <davexunit>I have to continue to investigate my avr-gcc issues <mark_weaver>civodul: okay, I guess it's doing work, but very slowly ***JamesJRH is now known as JRHaigh
***JRHaigh is now known as JamesJRH
<civodul>mark_weaver: "time XDG_CACHE_HOME=/tmp/cache ~/src/hydra/src/script/hydra-eval-guile-jobs --entry hydra-jobs -l build-aux/hydra/gnu-system.scm > out.xml" takes 8mn here; that's without the Perl thing <civodul>just sharing measurements as i make progress :-) <Shibe>guys i have a question about package managers <Shibe>functional package managers give programs their own dependency tree right? <Shibe>so newer versions of libraries can't break other programs? <Shibe>but they take up more space right? since every program has their own libraries and whatnot <Shibe>wouldn't it be possible to have both? as in if in a package's metadata it is confirmed that package a works with library c version 2, and package b also works with that, couldn't they share the library? <mark_weaver>libraries are shared in guix, if precisely the same version is used from multiple programs. ***dmcp_ is now known as dmpcmpcmp
***dmpcmpcmp is now known as dmcp
<lfam>What is the default verbosity level of `guix build`? It would be good to give the default and the range in `guix build -h`