<vagrantc>janneke: thanks. i hope i do it justice :) <ray__>Quick question: I think I can use rename-file to move files, how do I move a directory? <brendyn>ray__: im not sure if there is a single function but there is copy-recursively and delete-recursively ***payphone is now known as takkl
***takkl is now known as payphone
<snape>ray__: a directory is a special type of file that contains a list of file names and the corresponding inodes for each file and directory that it appears to contain (see http://www.linfo.org/directory.html) <snape>so you can move a directory like you'd move a file: it'll work, even if it contains stuff <brendyn>How strict are we about how wide code can be? <rk4>ACTION has a 11" screen <efraim>we aim for 80, the linter is set to complain at 90+ <brendyn>ok it looks ugly but I'll cut every line in half <snape>and the Emacs .dir-locals.el shipped with Guix sets the limit to 78 :-) <mbakke>Ooh, our single point of failure is down. <brendyn>What's the ideal number of packages per .scm file? <g_bor[m]>mbakke: My github repo is not uptodate either, it's one week old. Does it help? <brendyn>I wish to add more input method stuff. Is it reasonable to merge anthy.scm, ibus.scm and fcitx.scm into a single input-methods.scm ? <OriansJ>brendyn: well the number of packages per .scm isn't a meaningful question; as the point of seperate .scm files is to allow one to better organize pieces to enable others to know where to go to get the changes they want done. So when multiple programs share a single thought, then they should be grouped together. Otherwise it probably better to keep them seperate <brendyn>OriansJ: well there is an upper bound because large files cause compilation overhead, and having many small files also would <brendyn>and it's quite arbitrary how things have been sorted to date <OriansJ>brendyn: I don't believe that is correct. Unless one overhead for opening a file handle is huge <brendyn>OriansJ: python.scm was split precisely because of this reason <OriansJ>brendyn: I thought that had to do with too many unrelated packages being clumped together just because they depended on python <OriansJ>As for compilation times, there is not difference between 1 huge file, 4 medium file or 1000 small files or 100000 tiny files; especially for languages where cat *.scm > ../temp.scm doesn't break the program <OriansJ>Source code is for human understanding and organization and incidentally for machines to compile and run <OriansJ>brendyn: compilation is cheap if you don't do optimizations (M2-Planet compiled by GCC can easy compile 6+MLoc/s) <brendyn>OriansJ: We are using guile, so what gcc does is irrelevant <OriansJ>brendyn: yes I know we are using guile but the point isn't about gcc or guile or any particular language. The point is that compilation is cheap, optimization is expensive. <OriansJ>Turning off optmizations for things that run rarely but are expensive to optimize are where the biggest benefits for improving the build and not reducing the user experience. It requires understanding the performance profile of the code involved and performing basic experiments with the code involved. For example compare the runtime and compiletime differences between icecat with PGO turned on and off; asking yourself is it truely <OriansJ>justified on any system except a central distribution model. <OriansJ>It is one avenue which we have failed to take advantage of; we could incrementally add support for various levels of optimization into our package definitions and allow the users to indicate their preference (fast local compile or expensive compile for centralized servers). That way those using --fallback have to wait 8 hours for a package to be built and then installed. <OriansJ>efraim: I think that is why triple redundency is generally essential for anything central to one's process. <OriansJ>Is it possible for guix system init file.scm /mnt/ to also setup the first generation of user packages? I know the packages section can be used to install global packages but I am wondering about is there a section for configuring specific users to have seperate packages be installed in their profiles on system initialization? <cehteh>i still hope for group-profiles make it into mainstream <OriansJ>efraim: unfortunate, that sort of thing is really helpful in system administration. cehteh that seems extremely useful as well <cehteh>some time ago someone here explained a hack for that, but imo that should be mainstream eventually <pkill9>how do i find out which commit my guix is? <pkill9>if i run a remote `guix publish` instance, do i need to import the public key for that instance? <pkill9>before i can use it's substitutes on my local computer? <pkill9>well, before my local machine will download substituutes from it <cbaines>Possibly not... I think if it's serving the same content as another substitute server which is explicitly trusted, then it can be used <pkill9>it won't be serving the same content as another server <cbaines>then yes, if you want it to serve substitutes, you'll need to trust it <mbowcutt>what does an invalid build result mean when running 'guix pull'? it fails on compute-guix-derivation.drv <cbaines>mbowcutt, can you tell anything more about the error from the output? <cbaines>mbowcutt, this looks to be the rough error it encountered: <cbaines>In procedure package-transitive-propagated-inputs: <cbaines>In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #f <taylan>does anyone know in which package to find a 'pax' command? (POSIX archiving tool akin to tar) <cbaines>mbowcutt, I'd suggest trying again. If it works, then you probably just hit a bug in Guile. <taylan>by the way, regarding bluetooth: I found out that if you 'trust' and/or 'pair' a device, you don't need to manually reconnect it. even across reboots, my devices now connect automatically! <mbowcutt>cbaines: the same output happens every time I pull <cbaines>mbowcutt, well that's pretty bad. Let's see if I get the same behaviour... <mbowcutt>cbaines: I'm going to try to uninstall all guix/guile stuff and start again. I'm working with a foreign distro so it's strange <cbaines>mbowcutt, it's just worked for me, so maybe it is something about the wider environment <pkill9>does anyone have an example of how to compile the kernel with the addition of other modules? <pkill9>basically, the modules you would load with modprobe when they're not built into the kernel <infandum>Hi all, I'm interested in putting GuixSD on my computer. I have a question though: I know GuixSD is beta -- I am fine with this fact, but is the upgrade path simple from version to version? Especially when it leaves beta, can I follow that same upgrade path? If not, is the path well documented? <vagrantc>it's pretty much a rolling release, so it's constantly upgrading <infandum>Okay, perfect, as I'm on arch right now. <infandum>If I use a custom kernel, will that be automatically updated? <infandum>Or would that have to be manually updated with each release? <vagrantc>the concept of a release in guix seems more like a somewhat tested snapshot than what i would call a release <vagrantc>if you're using a custom kernel, you'll updated it when you update it <vagrantc>linux-libre gets updated with most upstream point releases, from what i've observed <infandum>guix import seems to support nix repositories -- does that mean I can install packages from the nix repositories? <vagrantc>it basically just creates a package definition in the guix syntax for packages, it might need additional tweaking to actually do anything <infandum>vagrantc: So, for instance, it converts a PKGBUILD in arch to a guix recipe kinda thing? <vagrantc>other than nix, it's pretty hard to draw parallels with other packaging formats ... it's pretty fundamentally different <infandum>Last question: I'm big into Haskell. I understand that many Haskell people go for NixOS, but I'm also big into emacs and having a whole system in a lispy functional language. I prefer Haskell, but the Nix language to me doesn't seem as feature full as Guile. With this in mind, should I still use GuixSD as a Haskell person or is NixOS better for someone like me? <kmicu>infandum: we have Haskellers here too. The real question is whether you prefer GNU and ethics in your software :)? <efraim>I'm not sure how much guix still supports importing nix package definitions, I don't its been tested in some time <infandum>efraim: Are they all like that? Is guix import with cran and bioconductor up to date? <efraim>infandum: yeah those are definately in use <efraim>i think its just the nix one that might not be working ***jonsger1 is now known as jonsger
<sneek>Its been said that the cake is a lie <pkill9>someone must have built kernel modules for guixsd <Perelandra>mbowcutt: Perelandra is the soul of planet Venus in a book written by C.S. Lewis <sneek>I've heard recursion is The first step in learning recursion is to learn recursion. <pkill9>something to note: /run/booted-system/kernel/lib/modules/<kernel version>/build is a broken symbolic link <efraim>pkill9: i think that warrants a bug report <pkill9>i ordered an ssd, looking forward to the increased speed <efraim>whoops, I messed up the copyright line in tor.scm <OriansJ>efraim: Do you know if guix is going to get the tor-browser? <pkill9>if i add the source of the kernel module (<kernel module>.c) to the linux source, will it automaticlaly be built? <pkill9>as in, when you build the kernel, will it automatically compile that kernel module with the kernel <pkill9>or do i need to configure it to do so somewhere <Thra11>pkill9: A kernel module foo.c will usually have a corresponding CONFIG_FOO option (defined in a Kconfig file), which needs to be set to 'y' (builtin) or 'm' (module) for the module to be built. I believe guix allows you to extend an existing linux definition by specifying/overriding "extra-options".