<civodul>lfam: yeah, i think there's an open bug about it :-/ <civodul>not sure how to address it without breaking the Guix-program use case <lfam>Hm, I wonder which Guix program has recently changed to cause this issue for me <lfam>Or, perhaps something changed in Debian that has made Firefox less resilient <quiliro>lfam: what does debian have to do with Guix's Firefox? <quiliro>civodul: every day guix impresses me! <civodul>lfam: i think the problem has always been there, but maybe for some reason your profile did not define XDG_DATA_DIRS before? <lfam>Yes, that's what I meant. I always source ~/.guix-profile/etc/profile on login, so perhaps something changed add XDG_DATA_DIRS there <lfam>quiliro: We don't have a Firefox package in Guix (we do have IceCat, which is closely related). The problem is between Debian's Firefox and Guix <quiliro>rekado_: would you please pass me the changes so i can type them in my environment and test openmolar? <quiliro>lfam: how it there a problem with debian's firefox in guix? isn't guix working separately with its own libraries? <CharlieBrown>nckx: I see that you worked on the package retroarch. Did you know that it won't play Debian's test ROM for Mupen64+? <CharlieBrown>nckx: I was going to email you about it, but tobias.gr does nothing but redirect to FSFE. <nckx>CharlieBrown: but it does that very, very well. <nckx>CharlieBrown: Hm. No. I didn't know that... <nckx>CharlieBrown: If you have the time, processing power, and motivation you could try bisecting to see if it ever did. I'm on a very weak machine so no dice. <nckx>Nor would I be much help debugging it. <nckx>ACTION → the sweet arms o' Hypnos. ***zetok_ is now known as zetok
<efraim>I learned my lesson from last time, I grepped for ?mmintrin.h and not just sse, roxml is definately x86_64/i686 only <efraim>nicorikken[m]: looks like it needs some of the wrapping magic from the glib-or-gtk build system <nicorikken[m]>Ah, now I see, it is dedicated build-system. I'll look into it. Thanks! <rekado>civodul: some of our users have problems with the new conflict detection. <rekado>civodul: they are stuck with a broken profile that neither allows them to upgrade nor to remove packages. <rekado>civodul: what do you think about adding an escape hatch in form of an environment variable? <civodul>however could you try to see exactly why they're stuck? <civodul>normally "guix package -u" should always succeed, unless the initial profile was already "broken" <efraim>Two packages that depend on one common package, one can upgrade, the other is libreoffice ;) <efraim>--i-really-really-want-to-do-this-action <ZombieChicken>Is hydra just incapable of keeping up with the more recent packages? It seems like every time I do anything with guix, I'm having to compile two packages (in fact, this list time is when I'm trying to /remove/ a package) <civodul>efraim: does LO fail to build on hydra too? <civodul>ZombieChicken: it has a hard time keeping up in general, yes, though currently it seems to be doing okay <ZombieChicken>Also really wondering why it's trying to download a package when I'm trying to remove something unrelated <civodul>hmm there's a substitute for /gnu/store/n7mf8hk262rnlhrjqmacnkp1yn518ks4-cups-minimal-2.2.1 (current master, x86_64) <civodul>ZombieChicken: it's trying to download a package to run the "profile hooks" <civodul>i reckon this is counter-intuitive (and annoying) <ZombieChicken>Weird. The package I'm looking at is bfv1.....cups-minimal-2.2.1 <rekado>civodul: one complaint here is that “-r” should not be prevented because of conflicts. <rekado>with a conflict-ridden profile and an update Guix, “-r” is not permitted as the resulting profile would still have conflicts. <rekado>civodul: one of the conflicts that cannot be resolved with “-u” is “conflicting entries for python:tk” <rekado>“first entry: python@3.5.3:tk”, “second entry: python@2.7.13:tk” <rekado>that’s because the user has python2-matplotlib and multiqc installed. <rekado>multiqc propagates python-matplotlib, which brings in python@3.5.3:tk <rekado>python2-matplotlib brings in python@2.7.13:tk <rekado>I really want to get rid of propagation. <efraim>I have no idea, my aarch64 build machine built libreoffice last week or so no problems <rekado>ZombieChicken: propagated inputs. <rekado>ZombieChicken: that’s when a package installs other packages because they need to be in the same profile. <efraim>It just seemed like a good example, something that could be upgraded but many people might skip if there wasn't a substitute available <rekado>ZombieChicken: this is the case for all Python modules. <efraim>I need to go through and methodically build a kernel config for aarch64, I tried Debian's but it didn't create a bzimage at the end <efraim>Also, we might want to make available the make-linux-libre function, I wanted to try build a kernel for the odroid, which is using 3.14, and a custom defconfig <rekado>efraim: it would be lovely to have more control over the kernel config. <rekado>I often had to build the kernel on my i686 machine and I really don’t need most of the kernel features that our package defaults to. <Jackneillll>i'd like to use it to be able to install it in vbox, how to? <davexunit>Jackneillll: using google I found that you can run 'vboxmanage convertfromraw <disk-image-file-name> vbox-image.vdi --format vdi' to convert raw disk images to vdi format <Jackneillll>davexunit, and i should use it it as live cd to install the system? <davexunit>the disk image contians a very minimal guixsd system for the purpose of running the installer <efraim>It looks like the aarch64 kernel is just 'Image' so I've adjusted the kernel package and am trying again <civodul>rekado: maybe we could add "python2-multiqc", or maybe we could wrap binaries that mutliqc provides to remove the propagation (if possible)? <rekado>civodul: the problem is that multiqc can be used as a library and as a set of tools <rekado>and the user may want to use both <rekado>previously it was just wrapped, but then it was brought to my attention that it should be usable as a library as well, which made me propagate the inputs <rekado>ACTION has to go to the data centre now to replace a server <civodul>rekado: ok; then we're left with the other option: to add "python2-multiqc" (which probably makes sense anyway if it's also a library) <jsierles>if i want to add an old version of a package to my store, one that was previous in guix, should i copy the old definition to a custom module file <civodul>jsierles: you can always make a checkout of a previous version of Guix, and build from there <civodul>yes, or using a Git checkout, though that is more "involved" <jsierles>guix pull is too slow right now, so if the other way is faster, i'm for it <civodul>we compile all of Guix, including package recipes, and compilation with Guile 2.2 is slower than with 2.0 <civodul>(the resulting code is faster, but still) <jsierles>perhaps this is naive, but wouldn't it make sense to split the guix package definitions from the core repo itself? <jsierles>at least ones that have nothing to do with guix itself. <civodul>there are pros and cons, but essentially it's very convenient to have both together <civodul>for instance (guix packages) is what defines the meaning of package definitions <jsierles>ok. so the intent is always to have to recompile guix to get an older package definition? <civodul>yes, but the intent is not to make it slow :-) <efraim>wouldn't GUIX_PACKAGE_PATH be a good choice for this also? <jsierles>i'm guessing there would be conflicts if you pointed that at an older checkout <civodul>efraim: it depends on the exact use case, but it could be an option, yes <civodul>jsierles: there shouldn't be any conflict: each Guix commit is self-contained <jsierles>if there are two packages with the same name, would GUIX_PACKAGE_PATH ones take precedence? <civodul>yes, and you would get a message about the ambiguity, i think <efraim>I have one like that, GUIX_PACKAGE_PATH is rated higher <ng0>civodul: has the upstream unversioned release of noto-sans been a problem in the past? If we split it up in the other hinted variants which exists by now (last emails I've sent just now on the question tumashu has) we have to find out if there's a regular cycle of individual tarball updates <civodul>ng0: no idea, i'm quite ignorant about all this :-) <ng0>At which point is Chromium to be considered for inclusion? I'm using it daily now and I am wondering what's missing that it could be considered for inclusion. it is stable enough and for myself far more usable than Icecat. <ng0>I would guess some patches similar to Icecat would have to be applied on top of it <chewzerita>Hi everyone! I want to package the ufw and gufw firewalls for guix, but I was having some issues. Can anyone help out? <ng0>I think I'll look at parabola and others for what they do with Chromium or Chromium-like browsers <civodul>hi chewzerita! sure, tell us what the problems are and we'll see <chewzerita>civodul: thanks, I think I got ufw packaged properly, but gufw is where I'm having difficulty. I could hard-encode the url for the download for each version, but that would be hard to maintain. <ng0>chewzerita: oO okayy.. so this is how the qtwebengine discussion ended. great. so what about KDE? I think the whole discussion was about KDE in the first place.. <civodul>chewzerita: so what's the problem? the URL scheme? <chewzerita>civodul: the tarball url pattern changes with version 17.10 <chewzerita>civodul: I also don't know how "bleeding edge" guix is. Should I just package 17.04? <chewzerita>civodul: but in that case, there is a 17.04.1 release that messes with the pattern again <ng0>we prefer the latest version, if there is the selection of "stable" and "unstable" release of upstream stable is to be used <civodul>chewzerita: the URL pattern doesn't matter much IMO, we'll adjust to whatever upstream does <civodul>chewzerita: as for the version, the policy is to package the latest stable release, as advertised by upstream, unless there's a very good reason to make a different choice <chewzerita>civodul: is there an accepted way to set a local variable in a package definition? e.g. series=17.04, version=17.04.1 <Salt>?_? "warning: rewriting hashes in `/gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0'; cross fingers" <civodul>rekado: did you have a chance to try the RPC pipelining patch? <catonano_on_mobi>ng0: if you see my last toot, you,ll see that a newer gnome browser exists. It even supports firefox sync <catonano_on_mobi>I wasn,t satisfied with browsing Tumblr with Web but this one might be better <chewzerita>To get the (sha256 (base 32 ... )) hash in a package, should I run `guix hash` on the tarball of the download? <jsierles>civodul: so i updated guix to see if your nar caching fix would fix issues I had with my substitute server. alas, I still see the same problems. Do you have any insight for another debugging route? <efraim>if its of interest to you, I don't have caching turned on for my aarch64 substitute server <ng0>catonano_on_mobi: it's not about gnome browsers <jsierles>efraim: i'ev tried both with and without caching with the same results <civodul>jsierles: not sure, i gave you all the debugging tips i had i think <civodul>if you could pinpoint the problem that would be great <civodul>first try to check 'guix publish', using simply wget and the likes <civodul>if that works, check the client side, looking at what's going on in /var/guix/substitute/cache <jsierles>ok. I think what I'll do is lay out all my steps, with debugging outputs, and compose them into an email so it can be discussed on a list. which list would be best? <civodul>jsierles: bug-guix is good; make sure to choose a title that clearly indicates what the problem is <rekado>catonano_on_mobi: what browser are you referring to? <rekado>civodul: no, I haven’t been able to test the patch yet :( <rekado>catonano_on_mobi: oh, nice. I’m going to give packaging it a try <efraim>Building singular failed hard when adjusting .desktop files <quiliro>rekado: would you pass openmolar1's current state? <rekado>should I be able to use (guix build union) in a regular build phase? I get ERROR: no code for module (guix build union) despite having listed it among the modules. <quiliro>i would like to test it in an environment <nckx>Is building the installer with ‘guix system disk-image’ supposed to guess the size of the image? I get a ‘disk full’ error if I omit ‘--image-size’. <nckx>Might be time to bump the fudge factor if it is. <rekado>civodul: I got a few more complaints about the conflict detection. <rekado>this time it’s also involving Python; a user has both Python versions installed in the same profile. <rekado>I’d like to push a little escape hatch for this today, so that they can disable this feature for now. <magnicida>i am trying to use it set up development environments <magnicida>but i am having trouble understanding how guix environment works <rekado>magnicida: it builds a profile and then starts a sub-shell in which the environment variables needed to use that profile are set. <magnicida>if I do "guix environment guile", i seem to get guile dependencies in the environment, but not guile itself, in particular, i don't get guile-2.2.pc in the /gnu/store/asdasdasd-profile/lib/pkgconfig <magnicida>I do get guile-2.2.pc in the environment if I do an environment for something that depends on guile <magnicida>(in that case though, I don't get guile-lib.pc in the environment, etc.) <magnicida>rekado: how do you explain this particular behavior? <rekado>if you want to create an ad-hoc environment containing the packages themselves you need to use “guix environment --ad-hoc guile foo bar” <rekado>“guix environment guile” gives you an environment containing the dependencies for “guile”. <magnicida>to me it makes more sense to have --ad-hoc be the default and the current default behavior behind a flag, something like --deps or something <magnicida>but this is just nitpicking on an otherwise amazing feature <rekado>quiliro: I’ve sent the patches for a working openmolar to guix-patches@gnu.org. It got the number 27755 in the bug tracker. <davexunit>magnicida: it's hard. a large number of people like the current default, a large number of people wish --ad-hoc were default. <quiliro>rekado: thank you for the explanation....i did not understand guix environment either....i think i have to re-read the manual <magnicida>yeah, I guess --ad-hoc is also kind of very much non descriptive of what it does, at least to me <davexunit>we thought about the name of that flag for awhile <magnicida>maybe its because i haven't writen guix formulas myself <davexunit>most of the time I just run 'guix environment -l guix.scm' to make dev environments for my projects <davexunit>I had plans for numerous workflow improvements but never implemented them <quiliro>davexunit: is --adhoc and default behavior configurable by the user herself or could it be done? <rekado>I’m used to “--ad-hoc” now, but I agree that having a different default would make 2014 rekado happy <rekado>(I guess 2014 rekado would be happy regardless, because the feature didn’t exist then IIRC) <civodul>rekado: ok for the escape hatch, preferably a CLI argumen <quiliro>davexunit: an alias could be set to link 'guix environment' to 'guix environment --ad-hoc' <magnicida>davexunit: wrt naming, maybe --including or --with or --add, but its true that it is hard to name (seems to me easier to name the reversed default) <davexunit>but that would make it impossible to do the default behavior <rekado>civodul: when my boss returns I should ask about our Guix+HPC course in autumn. <quiliro>davexunit: then there should be a --non-ad-hoc <civodul>rekado: yes, we should choose a date ASAP, otherwise we'll keep procrastinating ;-) <davexunit>quiliro: maybe but that changes the interface significantly <davexunit>the position of the --ad-hoc argument is significant <davexunit>consider 'guix environment guile --ad-hoc gdb' <davexunit>that means "get the deps of guile and mix in gdb' <magnicida>yeah, still i understand that most of the time having a .scm filed for your project (probably checked in the repo) is the best solution <magnicida>next day dreaming wish is to have guix support on travis-ci, but that is not in your hands :D <davexunit>there's plenty of things to improve, though. <davexunit>I have never considered 'guix environment' done. I just got something that worked well enough to make people's lives a little easier. <rekado>ACTION tests the RPC pipelining patch now <davexunit>I'd really like it if 'guix environment' could optionally remember the environment it created so it can quickly reconstruct it later. <davexunit>so that you can upgrade guix but just use the old environment until you are ready to upgrade. <civodul>i share the concerns of one of the members of the audience about the SaaSS approach, but otherwise i think it's pretty nice stuff <civodul>and yeah, Guix/Nix/IPFS look like they would fit well in the picture <jsierles>civodul: cool - it's our first attempt at talking about it at depth. we also share the SaaS concern, but also believe that progress in this area cannot be made on grants and free time alone <jsierles>definitely the intent is to open source as much as possible, when it's ready. doing so right now would not be productive since it's changing all the time <magnicida>is there a way I could use that to quickly load a guix environment in a travis run? <rekado>civodul: about the RPC pipelining: this breaks compatibility; if the daemon is not updated the client will just crash. <magnicida>i feel like trying out nix... i am using guix on a debian machine, do you people think it is problemating having both guix and nix installed on top a debian sid at the same time? <rekado>magnicida: that should be no problem. <rekado>magnicida: they both use separate stores (/nix/store and /gnu/store), so you can have both daemons run at the same time. <magnicida>the beauty of functional package management i guess :D <civodul>rekado: yes, known limitation :-) for now you need to upgrade both <civodul>(which is a bit sad because fundamentally this does not change the protocol) <civodul>jsierles: ok, i see; looking forward for a free software nextjournal! :-) <civodul>magnicida: re Travis, you could use "guix environment whatever" in your Travis "recipe" i guess <jsierles>civodul: we'll probably start by open sourcing the frontend. the backend is quite a beast so we'd have to figure that out <Apteryx>civodul: I'm about to leave for work. Any suggestion to test libreoffice build as much as possible while I'm away? I was going to run: ./pre-inst-env guix build --rounds=2 libreoffice -c 1 -M 1, to try to get the compiler bug again. <civodul>jsierles: oh but i guess the area that we're the most interested in from a package management perspective is the backend :-) <jsierles>civodul: yeah, just will take some time :) we'd like to find things we could usefully open source of course <civodul>BTW, "you may also like" (as they say) roelj's "Guix Workflow Language" (GWL) <jsierles>everything we're using is open source at the moment <jsierles>civodul: right, we've been talking about that. <civodul>ACTION didn't know about the domain name, neat! <rekado>ACTION always thinks of a skin condition when hearing or reading “open source” <catonano>I didn't know either ! This is wonderful ! <rekado>civodul: “GUIX_PROFILING=rpc ./pre-inst-env guix build python2-numpy” seems to be stuck :( <rekado>it printed “;;; (flush-pending-rpcs 537)” and then fell silent. <jsierles>we're not ready for workflows yet though. now just trying to get the core execution model stable <civodul>rekado: that said it should not be slower than the current thing, with or without --no-grafts <jsierles>is there a way to query the daemon for 'packages in the store'? <civodul>you can ask the list of live items in the store with "guix gc --list-live" <civodul>some of the items correspond to packages, some don't <jsierles>alright. we're not going to be using /var/guix/profiles in our system, and never will gc <ng0>is there solution for having a patches subdirectory in a GUIX_PACKAGE_PATH? (patches (search-patches "patches/foo.patch")) doesn't work, it works with leaving out the subdir and moving its content to the root of the GPP <civodul>ng0: it's relative to the top directory, if you see what i mean <civodul>or you can do (patches (list (local-file "patches/foo.patch"))) <jsierles>in other words, users will mount a common store, but links to profiles in the store will be local to their document <ng0>that makes absoilute sense, civodul <rekado>civodul: it’s not a matter of speed – it just doesn’t seem to do anything at all (other than printing “flush-pending-rpcs” once. <jsierles>civodul: would --list-live work without relying on /var/guix/profiles? <rekado>I get the same behaviour without grafts. <civodul>rekado: it could be a protocol error; are you talking to the "right" daemon? <jsierles>civodul: alright, that helps. the goal here is just to be able to present a list of software that's already been built and available in the store. for now, we'll be controlling what gets put into the store <rekado>civodul: yes, I’m talking to the local daemon that I’m running with “sudo -E ./pre-inst-env guix-daemon …” <rekado>strace shows me “write(4, "stla\\0\\0\\0\\0G\\0\\0\\0\\0\\0\\0\\0/gnu/store/lsfjq"..., 88” <civodul>could you paste the tell of the strace output? <jsierles>hmm. i have 'r-minimal' installed, but 'guix gc --list-live' doesn't show it <rekado>jsierles: that’s an important difference. <rekado>jsierles: if it is only built but nothing points to it then it is free for garbage collection. <jsierles>rekado: yes. but for my case, i want to see 'all built packages'. in our setup, gc is not part of the picture <rekado>civodul: hmm. it always gets stuck on the same thing. <rekado>civodul: the last message is just that write. <rekado>I use “./pre-inst-env guix build --no-grafts -d python2-numpy” <rekado>“guix build” writes out a derivation, at least that’s what it looks like <rekado>civodul: FWIW “guix build hello” works fine <ng0>offloading big packages like thunderbird for builds is almost as slow as compiling bits of it already locally :/ faster, wifi, faster! <civodul>rekado: hmm! if you have an example that works, could you check over the network how that impacts performance? <civodul>i used a 150ms delay in my testing, i don't know if this is representative <rekado>civodul: I’ll have to do this tomorrow :( Have to leave now. <chewzerita>when I try to start a guix environment I get a backtrace and an error: guix/scripts/environment.scm:283:4: Throw to key `match-error' with args `("match" "no matching pattern" #<unspecified>)' <civodul>chewzerita: what command did you run? <OrangeShark>chewzerita: firewall.scm should evaluate to a package. You probably use define? <reepca>or a variable bound to a package <civodul>chewzerita: this file does not evaluate to a package <civodul>see the example for -l in the manual <civodul>essentially you need to remove the 'define-public' form <civodul>that said the error message could certainly be clearer... <chewzerita>alright, I guess `guix environment` is not what I need. how would I be able to build a packaged defined in firewall.scm <reepca>assuming you've got GUIX_PACKAGE_PATH set to some directory with a gnu/packages/firewall.scm underneath it, then just "guix build gufw" should do it. <chewzerita>reepca: thank you! I was looking for something like GUIX_PACKAGE_PATH <chewzerita>reepca: alright things seem to be happening, instead of just erroring out immediatly <lfam>ng0: Somebody needs to investigate the differences between the available tarball and the tarball we originally packaged <lfam>So that we can tell if the changes are innocent or malicious <ng0>or we could just ask upstream <bavier`>that would be part of the investigation <efraim>I don't know what to do now, I managed to get 'guix system build gnu/system/install.scm' to build on aarch64 with minimal hacking <efraim>I guess I should dig out my hikey board <lfam>Time for a cool beverage ;) <vaeringjar>Anyone here know of a build tool that has compatible members to a guix package, for written in sh or python (for my non-scheme coworkers)? I want to use the same data source to define the packages for software builds and then wrap all that in a makefile for ease. <bavier`>vaeringjar: www.gnu.org/s/gsrc uses a makefile-based build system <nicorikken[m]>efraim: I've been fiddling a bit with glib-or-gtk build system to resolve my Zim desktop wiki port. However I'm not sure how best to combine multiple build-systems in this regard. I was thinking of using #:phases (modify-phases %standard-phases (add-after 'install 'glib-or-gtk-wrap glib-or-gtk-wrap))) but that does not work. Am I right to keep the python-build-system? and is there a better way to combine/replace build <efraim>nicorikken[m]: the easiest is to, in a new phase, do whatever wrapping glib-or-gtk does, the other option is more involved and means you'd be pulling phases from another build system <efraim>I'd suggest the first, if you want the second translate-shell does this, as do some packages in emacs.scm <nicorikken[m]>efraim: I was thinking of refering the 2 steps as definined in %standard-phases in glib-or-gtk-build-system.scm. Like: (add-after 'install 'glib-or-gtk-wrap wrap-all-programs) However I get the 'unbound variable' error, so perhaps I'm importing it right. Could it be that I'm doing something wrong with use-module? <ng0>Is 'mdb.h' located in "lmdb"? <lfam>Hi civodul! Thanks for fixing that issue with guile-static-stripped <ng0>ah great.. portagefilelist.de told me it is in the package I am building for guix <ng0>so it must be something I have to fix <civodul>lfam: yw! glad it also fixed the scary disk-image problem <lfam>civodul: Do you know if it's expected that RAM would be limited in the initrd? I'm not familiar with that part of the system <civodul>the root fs of the initrd is in RAM, so if Guile was writing .go files there, it was consuming more memory <civodul>on top of that there's the memory consumption of the compiler itself <civodul>that may explain the problem we've seen <lfam>I wasn't able to figure out where this memory was being allocated, but my preliminary reading of the OOM log showed that there were zero pages available <ng0>in gnu/packages/linux.scm , ncurses is unbound <lfam>ng0: Hm, what command did you run to reach that error? I'm having trouble reproducing it <ng0>Even after delete gforth.go.. But I am running now clean+everything to see if I can reproduce it <civodul>lfam: the log didn't say "OOM" though, as it normally does for OOM incurred by userland <divansantana>Trying to setup offload facility and following the manual. It says I should be able to run this =ssh build-machine guile -c "'(use-modules (guix config))'"= to test build machine. <divansantana>But if I ssh into the system and run =guile -c "'(use-modules (guix config))'"= the exit status is 0. I noticed GUILE_LOAD_PATH is not set. Though not sure what it's supposed to be set to. The build machine is on arch linux. I followed the build and application setup as per machine (I think). <civodul>divansantana: that's because in the second case, your shell sources its login startup files, whereas in the first case, the shell does not <civodul>the result is that different environment variables end up being defined <civodul>you may need to define GUILE_LOAD_PATH & co. in ~/.bashrc <lfam>civodul: It didn't show OOM while building the disk-image, but it did while building a vm-image: init invoked oom-killer: gfp_mask=0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0 <civodul>ah okay, so that definitely suggests a Guile issue <jlicht>What is the best way to include a copy of a built package in a different package? Can I just create a hard link, or is a symbolic link more appropriate? <jlicht>context: I am currently reworking some npm related things, and decided to try to go with something between npm2nix´ and node2nix´ models, where I need to link all dependencies of a package in the same directory tree <civodul>should we commit (part of) your importer BTW? :-) <jlicht>symlinks work properly with grafting as well? <divansantana>civodul: I though of that but when logging in via shell GUILE_LOAD_PATH is still not being set. I'm not sure what to set it too, and what else is missing. Which part of the manual shows what to set GUILE_LOAD_PATH to? Doing an env|grep -i guix when logged in and ssh user@host env|grep -i guix returns same. <jlicht>civodul: we could, as I saw janneke is already starting pushing some small parts ;-). I´d just really like to still get the fundamentals right first, so we have a proper way forward. NODE_PATH is nice for commands like `guix environment´, but not usable for actual package deployments <janneke>jlicht: not usable, what makes you say that? <civodul>jlicht: symlinks work properly with grafting <janneke>ACTION has been using NODE_PATH with much success, apparently <wigust>divansantana: you grep guix but writing about GUILE_LOAD_PATH <jlicht>NODE_PATH afaik will lead into problems if we ¨want¨ two versions of the same package to be available <divansantana>wigust: True. Urgh. Woops. Ok but same is true for grep -i guile. Searching manual. <reepca>divansantana: are you on GuixSD or running inside another distribution? <janneke>jlicht: i have been using NODE_PATH only for `toplevel' packages <divansantana>reepca: Trying to use guix on parabola linux as my build host. <janneke>packages that have dependencies, use an internal node_modules directory with symlinks to the actual packages <janneke>jlicht: that's how i setup- the `binary' package layout anyway <jlicht>janneke: Do you resolve non-toplevel stuff via symlinks in de node_modules dir? <janneke>jlicht: yes -- all `dependencies' of a package are symlinked inside its own lib/node_modules <jlicht>on a side-note; my libreboot t400 is arriving tomorrow :D. Does anyone have some recent examples of systemconfigs /w encrypted partitions that might be helpful in setting things up? <civodul>jlicht: the examples provided in the install image include one example with encrypted root <jlicht>civodul: cool, out of the box things that work ;-) <janneke>$ l /gnu/store/7gzqn4y6m0c138rik4frpqvyaw7dnvd2-node-accepts-1.3.3/lib/node_modules/ <janneke>lrwxrwxrwx 2 root root 93 Jan 1 1970 negotiator -> /gnu/store/m185crpd1jhr4qfxxh85znlifc9hfzyc-node-negotiator-0.6.1/lib/node_modules/negotiator/ <janneke>lrwxrwxrwx 6 root root 94 Jan 1 1970 mime-types -> /gnu/store/rvxwwqgl42rnxsfmjcvhhnvdzb3wbif2-node-mime-types-2.1.15/lib/node_modules/mime-types/ <janneke>dr-xr-xr-x 2 root root 4096 Jan 1 1970 accepts/ <janneke>where `accepts' is installed at toplevel <civodul>it seems to always miss the plugin it needs <civodul>like it can't even read mp3s, even with all of gst-plugins-* installed <jlicht>ACTION off to check the new goodies in janneke´s guix repo <janneke>jlicht: i only did this for the `binary' packages build atm <janneke>as i --sadly-- did not succeed in a single pure source build <jlicht>janneke: It is still a reasonable approach ;-). Do you still make use of the recursive importer? <janneke>yes, look at the comment at the top of gnu/packages/npm.scm <jlicht>janneke: oh wow, what kind of black magic is that o.O <janneke>jlicht: yeah, terribly ugly...but it works <janneke>the recursive importer only imports new packages, so do recursive one at a time <janneke>it works reasonably well, only some manual intervention needed for our ~300 node packages <janneke>civodul: i think i like your check-system patches, look simplifying -- haven't tried yet <rekado>huh, eolie takes hardly any time to build. <rekado>not what I expected from a browser. <rekado>but sadly it just crashes on start. Have to fiddle with LD_LIBRARY_PATH to make it find libraries at runtime. <roelj>rekado: I didn't know about eolie, but it looks just like Epiphany. <roelj>Oh wait.. Epiphany is GNOME's current browser, right? <buenouanq>they've renamed it `web' which is stupidly confusing <civodul>at least they're not working too hard to find names ;-) <jlicht>that might be one of the worst search terms. ¨issues with web web browser¨ XD <janneke>jlicht: have you ever managed to run npm install in a container? <jlicht>janneke: No, not that I remember. AFAIK, it had something to do with that npm always tries to match some exact versions of stuff <janneke>Error: EACCES: permission denied, mkdir '/usr' <chewzerita>does anyone know the default username and password for the guixsd qemu vm image? <lfam>I think 'Web' is a great name for the GNOME browser. On systems that are really popular like Android or iOS, most users don't know the name of the browser, and they don't want to learn it. It's best to keep the names simple when building an integrated system like that, IMO <jlicht>janneke: no clue what that is about. Did you try npm install -g or something? <lfam>chewzerita: root and no password <lfam>Remember to either set a password or lock the root account :) <civodul>lfam: yes, you're right; the funny names are great for insiders but inconvenient for others <janneke>jlicht: yes, trying something like: node /tmp/.npm/bin/npm --verbose install --prefix=/tmp/.npm --user=root --global --no-registry --cache=/tmp/.npm ./dzn-2.3.0.tar.gz <lfam>Having said that, I don't think we should change the name of our package ;) <roelj>Has anyone tried to compile something vor an Atmega328p with the avr-toolchain in GuixSD? <jlicht>janneke: could you post a paste somewhere of the output leading up to the EACCESS error? And perhaps the command you used to get into the container as well if possible :-) <jlicht>janneke: I have literally no clue what I did, but glad to be of service <janneke>jlicht: using --global without --user did not work, neither did --user=root <janneke>so before sending you the command +failing output, i added a user to my OS: `guix' and used: <janneke>amazing, npm 3.8.6 is broken wrt --no-registry, but 5.3.0 works *sigh* <rekado>roelj: I only heard of Eolie today, thanks to catonano. <rekado>I find GObject Introspection confusing. <rekado>It has some of the worst error messages. <rekado>do you know what I need to do to not get an error when doing this in Python? => from gi.repository import Gtk <rekado>I get “TypeError: must be an interface” <roelj>Are you sure "Gtk" is importable? <rekado>roelj: I don’t know what that means, but I’ll just nod. <rekado>roelj: it’s what eolie does, so I think it makes sense. <roelj>rekado: If you have a package recipe so I can reproduce it, I can have a look <rekado>I’m running “eolie” inside of “guix environment eolie --ad-hoc eolie” <rekado>I also set LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib/ inside that environment. <roelj>rekado: Oh, it's already in.. Good night! <roelj>How can I use virt-manager in GuixSD to boot from an ISO? <roelj>The user-mode connection simply times out (or does nothing) <roelj>And the system connection fails to authenticate.