<ng0>Can we predict the UNIXPATH length for stores like Guix and Nix? <Apteryx>What is the difference between cons* and append? <mekeor>(append LIST LIST) (cons* ELEM ELEM ... ELEM LIST) ***reepca` is now known as reepca
<cbaines>divansantana, so, I would guess that you need to get the source of the luks-device-mapping mapped-device to refer to the target of the raid-device-mapping mapped-device <cbaines>from the docs, it looks like source can be a (uuid "...") as shown in the example, or a device, e.g. "/dev/md0" <cbaines>In the operating-system record, mapped-devices is a list, so you would want to specify your two mapped devices seperately in that list <cbaines>So, instead of the single (mapped-device ...) you have im the paste you posted, you'd want (mapped-devices (list (mapped-device ...) (mapped-device ...))) <xd1le>Noob question: I'm trying to package something do I write it's package definition and put it as 'guix.scm' under the packages source directory. Then I run `guix build -f guix.scm --with-source=.` from the source directory but it says "guix build: warning: transformation 'with-source' had no effect on polybar-2.5.2" :( . So how do I get guix to build from source directory? (To check if my package object is correct.. I assume this is what people do?) <xd1le>I've packaged things before but they were much simpler do didn't need to check it with guix build <cbaines>Are you using a checkout of the main guix git repository? <xd1le>Also does git-fetch, from (guix git-download) clone recursively? Because that's what I need <cbaines>I'm a bit confused where guix.scm is involved <cbaines>Are you talking about the guix.scm file that can be found in the root of the git repository <xd1le>no it's my own file I put in the source directory <cbaines>Ok, where exactly is the source directory <xd1le>like how it's used with guix environment <cbaines>Do you mean gnu/packages/ in a repository checkout? <xd1le>so I clone that. then I put my own guix.scm there <cbaines>Do you intend to submit this package to Guix, to get it included in Guix itself? <xd1le>kind of like how with nix, people sometimes like to put default.nix files in their root source directories <xd1le>yes but once I've confirmed it's working <cbaines>Ok, given that you are working towards submitting it, I'd recommend just adding the package definition to a checkout of the guix repository <cbaines>So, pick an appropriate file in gnu/packages/ and then add a package record for polybar <xd1le>So in short I want to know how to have a local file for the source part of a package object <xd1le>oh I know that, but it's like a workflow question <xd1le>docs point to g expressions, but it's too hard for me to wrap my head around without allocating a lot more time to sit down and understand it all :/ <xd1le>for example, say if you don't just want to package it, but say you're a developer who wants to integrate guix into the development process.. <cbaines>Ok, so if you don't want to put the code in the guix repository at the moment, what do you want to do with the source park of the package record <cbaines>Do you want the package to use the local files, just as files <cbaines>Or do you want to do something smarter with using Git metadata about local files as well? <xd1le>I guess that would be nice as well? <cbaines>So, you can just use the files by using the local-file function <cbaines>so the source would be (local-file ".") I think <cbaines>ah, you're going to need to set the #:recursive argument to #t <divansantana>cbaines: thanks a ton. That helped. Sorted now. /Slowly/ learning. <xd1le>brilliant, where is local-file? <xd1le>recursive for git-fetch you mean? <cbaines>xd1le, its in the (guix gexp) module if I remember correectly <cbaines>recursive in this case I think means that local-file will treat it as a directory, kind of, my understanding is a bit vague <xd1le>sorry to hijack the channel over this though :/ <cbaines>it uses a custom select? function to extract only files in the Git repository, you might not need to do that just yet though <cbaines>there was a request to make that functionality part of the public API recently, and when that happens, this should get a bit easier <cbaines>divansantana, great to hear its sorted :D <xd1le>cbaines: "guix build: error: build failed: illegal name: `.'" <cbaines>xd1le, maybe local-file can't use relative paths, I can see the current-guix package uses (current-source-directory) to make the path absolute <divansantana>During install, I want to use a proxy. I've set http_proxy var. And done herd stop guix-daemon, export proxy and herd start guix-daemon <xd1le>vim doesn't have clipboard so had to git push it somewhere <xd1le>cbaines: thanks, does (current-source-directory) evaluate to the current directory? <cbaines>I would assume so, I just spotted it used in the current-guix package in package-management.scm <xd1le>yup I see it in your link, trying it out now <cbaines>divansantana, looks like the Guix manual says that the daemon honors the http_proxy environment variable <cbaines>I think the problem that you are having is that you need to set it in the environment which the daemon is running <cbaines>divansantana, are you using the USB install image? <cbaines>The only thing that comes to mind is running the daemon in another tty <cbaines>You would need to work out what command line flags the daemon is being run with, perhaps using the ps command <cbaines>Then switch to another tty and make sure you are root <cbaines>Stop the daemon using herd stop guix-daemon <cbaines>Then set the http_proxy environment variable <cbaines>Then start the daemon with command line flags it was using <cbaines>At that point, the daemon might be running with the http_proxy environment variable set <xd1le>cbaines: it's downloading dependencies so I think it may have worked! hopefully current-source-directory doesn't mean the currently used guix source directory or something though <cbaines>xd1le, great, I think (current-source-directory) is a guile thing, so I think you are ok <cbaines>I've got to go now, but I'll be back later :) <xd1le>thanks for your help! appreciate it! :) <divansantana>weird, still not working. On tt1 I did herd stop guix-daemon, set http_proxy and ran `/gnu/store/3q8n67qwz3vslzbq3kpl03hhlvj6isc0-guix-0.12.0-1.c8e2/bin/guix-daemon --build-users-group guixbuild --substitute-urls https://mirror.hydra.gnu.org` <divansantana>on tty2 I try guix package -i wget and I see it's still not using proxy <xd1le>cbaines: for reference, the docstring says it gives the absolute name of the current directory, so it's good! also the build tried to build the correct source! :) <xd1le>A cmake-build-system build fails because it requires either clang-3.4+ or gcc-5.1+. Anyone know how to point the build process to gcc-5.1+? <xd1le>I think the answer might be just to add the appropriate gcc as an input.. <ng0>what's the difference between (package) gettext and gettext-minimal? minimal has no dependency on X, or what? <ng0>(X or anything other big) <efraim_>Minimal is used as an input for Emacs, as a native input the minimal one is probably enough <ng0>and when it isn't native? I wasn't following the discussion around moving many packages to -minimal, was it simply because of the 'gettext' in scheme? <rekado_>"gettext" is the same as "gettext-minimal", but with added tools for Emacs <rekado_>"gettext" is what you would install, gettext-minimal is what you use to build packages <ng0>I don't see where (gnu packages gnunet) uses either of gettext, gettext-minimal or po4a, but the module is imported <ng0>i will check again and make the change later <ng0>I have an more up to date collection somewhere, maybe it is used and I forgot to add it to guix ***HoloIRCUser7 is now known as jmi2k_
<cehteh>why doesnt guix have a rather normal /etc where *all* daemon configuratons are editable in their native format, and on 'system reconfigure' this gets imported and nailed down into the store (sans git/etckeeper) *thinking* <cehteh>would need some solution for the mutable files in etc (resolv.conf, mtab ..) <davexunit>cehteh: that goes counter to what guixsd aims to achieve <cehteh>yes eventually these mutable things should be removed <davexunit>I haven't seen a single service that would call for such a thing. <cehteh>davexunit: i only meant to make the configuration more 'normal' and easier, not breaking the immutability <adfeno>I wonder if Disq.us has a way to view comments in plain text. <davexunit>cehteh: I'm not sure how such a system could work. <cehteh>in the long run i dont think having each daemon configured by scheme expressions will scale, its a pita to learn and has a lot overhead for each service <davexunit>it may require work for each service, but people write Chef cookbooks, Ansible playbooks, etc. that are analogous to GuixSD services in many ways that allow programmatic configuration of software. <davexunit>at work we use Chef and I can find a cookbook for just about any daemon that provides a Ruby interface to all of the possible configuration. <cehteh>davexunit: etc should just become part of a profile (entirely), but root (or whoever is allowed too) has some shadow copy which is editable, but not active, system reconfigure imports this shadow /etc into the store and from there its hooked into the system profile and used <cehteh>the scheme expessions can still generate the configs <cehteh>easier transition, and not mandatory to use scheme expressions <davexunit>and it's also not clear how it would be possible to implement. <davexunit>the user still needs to write a scheme expression for their OS <cehteh>doesnt the current scheme expessions generate config files already for some daemons? <cehteh>i dont want to abadon that, i just would like to have an alternative <civodul>cehteh: i think the problem is that there's no way to "map back" from the native config file to the GuixSD config <civodul>it's a bit like disassembling native code <cehteh>like for example you have openssh: (service openssh-service-type (openssh-configuration (x11-forwarding? #t) .... <cehteh>how if this could be configured *alternatively* as: (service openssh-service-type (openssh-configfile "/root/ssh_config")) <davexunit>and if the service is just given a text file, it may not know what to initialize <davexunit>additionally, some daemons handle dropping privileges on their own so you need to specify user/group in a config file, so shepherd wouldn't know which user/group to create. <cehteh>what are these cases? key generating? <davexunit>creating log directories, initializing mysql data directory, <civodul>i think there's a need for a "quick-hack" more that does not involve a full reconfigure <cehteh>and if so, still i dont see a difference, i am only talking about the bits generating the configfile which is currently done with scheme expressions, not about any additionally machinery <davexunit>there's enough of these cases where using opaque config files isn't going to work well. <civodul>but it should be possible to do so by generating service/config files and telling shepherd to load them <davexunit>because you haven't eliminated the need to write scheme. you still need to tell shepherd a bunch of things about what's in the config file. <cehteh>the problem i have with the scheme thing is that i am not that much familar with scheme, still learning and when i look at some config files (squid for example) which are excellent documented from their examples, it makes me a bit sad that so much information gets lost <cehteh>also on servers i administrate i often write annotations for other admins into the config file; ok that would be possible in scheme too <cehteh>biut the scheme stuff has a steep learning curve and doesnt scale well <davexunit>"doesn't scale well" is an unsubstantiated claim. <jmd>cehteh: I think scheme is relatively easy to learn. <davexunit>I would argue that it does scale well given what I've seen done in other programming languages <davexunit>again, Chef cookbooks. they're written in Ruby and often they provide a Ruby interface to every configuration knob of the software they manage. <davexunit>and the result is *easier* system maintenance. <cehteh>i dont meant that in performance sense, i meant the repetive work which is needed to integrate new services with possibly strange config formats into guix <jmd>The real issue I have come across with scheme is that some bindings for things are missing. <jmd>cehteh: That could happen regardless of the language. <cehteh>and the learning curve that each service gets a new set of scheme variables even when i know how to setup apache, ssh, whatever, i have to relearn that for guix <civodul>cehteh: true; that's why for some key packages like nginx we have an "escape route" where users can pass a native config file <jmd>There's nothing to stop you overriding that service with a procedure (service-config-from-string "....... ") <cehteh>well there is my lack of scheme :D <cehteh>i should learn it and it is not hard, but i think anything which lowers the barrier would be a good thing <rekado_>in a test suite I have this problem: The name org.freedesktop.login1 was not provided by any .service files <rekado_>I stert dbus in a phase before the check phase and elogind is among the inputs. <rekado_>do you know of any other magic that needs to happen to have elogind be started by dbus? <civodul>rekado_: dbus-daemon needs to know where to look for .service files <civodul>by default it looks at /etc/dbus-1/system-services/ <civodul>but that's for the 'system bus', not something you can start in the build env i think <rekado_>cehteh: you can already use plain config files and tell guix to use those. <rekado_>cehteh: what's not so nice is that you may need to reference store items in them <rekado_>so you'd need a pre-processing step to replace placeholders with actual store paths (see gexps) <rekado_>for nginx, for example, I use a pretty boring configuration file and reference it in my operating system configuration. <rekado_>the reason for that is that the nginx bindings didn't cover enough of my use case back then. <rekado_>cehteh: I see your point about scalability, though. Other systems like puppet and chef have shown that it's not a real problem to worry about. <rekado_>it does mean that admins need to learn new things, and if there's one thing admins hate it's learning new stuff <davexunit>it pays off to have to learn a new configuration syntax for each application <davexunit>guix, and other config management systems, present a unified interface. <davexunit>which could be considered frustrating for people that already know all of the configuration languages for the services they want to run <rekado_>having a *different* interface to configuration often means that admins cannot copy and paste from the usual resources. <rekado_>but we can make up for it by making configuration easier. <davexunit>our service extension feature is one such benefit we get from having everything in scheme <davexunit>we can collect additional nginx config from services that want to run a web server and guix will do the right thing to build a config file that honors that <janneke>any pointers for a complete tor newbe about browsing over tor using guix? <janneke>there was talk about `torbrowser' but we don't have such a package <janneke>the manual talks about "tor anonymous networking daemon", but google only knows about that string in our guix manual <rekado_>janneke: (I'm also a newbie.) I added "(tor-service)" to my services, which starts a SOCKS proxy on port 9050; then I told my browser to connect through that SOCK proxy. <rekado_>janneke: and I checked the "remote DNS" checkbox <rekado_>(that's to make sure that DNS queries aren't leaked) <janneke>rekado_: btw, have you found a way to repl stumpwm? it seems to be possible, somehow, maybe...but it's not configured ootb like guile-wm <rekado_>janneke: no, I haven't yet tried hard enough. <rekado_>janneke: someone said we need a package variant that includes swank. <rekado_>I don't understand why it's not enough to just install swank, i.e. without having to bake it into the package. <janneke>yeah...i read some cryptic (for me) advice on some mailing list... <janneke>whereas guile-wm has a `sample' config file that has <janneke>;; Start repl server on the default port <rekado_>it seems to be a problem with our sbcl-stumpwm package. <civodul>janneke: is it true that you're going to fix all the glitches in guile-wm? :-P <pareidolia>When I do a guix pull, loading and compiling is kind of slow. Is this normal? <civodul>pareidolia: yeah it takes a bit of time <pareidolia>civodul: What's the current status of guix-nix compatibility? I tried to get nix to talk to the guix server, but it failed because a "builtin:fetchurl" builder was not found <janneke>civodul: i tried to start guile-wm and failed again...i was almost ready to ask here about it, when i found that i can simply run it in my stumpwm environment. so, i'm again looking into it...a bit. now that you ask... <janneke>when i choose `guile-wm' in slim, i get my desktop background and the message: `logging in...' <janneke>after < 0.5s an error-message is printed right over that, saying something like; `login failed' but i cannot read it because it dissapears quickly and is scrambled by the `logging in...' background <janneke>are these messages logged somewhere/how do i debug this? <civodul>so you're running guile-wm in addition to stump? <janneke>i have just switched to stump and am happy with the concept, but disappointed by the implementation/delivery -- eg, i am flabbergasted that there's no nice example and no repl etc... <janneke>so, i have renewed inspiration to want to run guile-wm and am trying that, but not really `running' it <civodul>ACTION recovers from an Emacs crash grrrr <pareidolia>Can someone please try ao-cad and see if it crashes with an "Illegal instruction error? <rekado_>pareidolia: It doesn't work on my machine. <ng0>fish has the policy to include all/many completions in their upstream. if my completion for guix will use the license of guix, will it still be compatible to the way they do this, or is there some fundamental difference between their license and ours? afaik its gpl2 vs gpl3 <janneke>civodul: ugh! i have given up on our emacs, using an older version <ng0>I could however make my completion either external OR just make it CC0 <ng0>CC0 would allow it to be in the guix source and in fish source <cehteh>davexunit: i see the advantages too, but to be truely unified there is still a lot to do like (ssh-sevice-flavor "lsh") (or "openssh") and then (ssh-service ... with one unified configuration, only things which are special to each flavor are unique then <rekado_>ng0: you only have problems when they have GPLv2 only. <rekado_>ng0: then it makes sense to just use that license as well and contribute upstream. <ng0>I'd rather have the easy way and put it into etc/completion where already zsh and bash are <cehteh>there are also a lot bumps on the road, i asked some time ago, why not pick the first service definition instead error out with double service definiton, because most people dont know what exactly %base-services or %desktop-services contain and want to customize single things without the whole rewriting lore <ng0>I think I will choose the middlepath, cc0 in an external project which both projects can then use and include if they want to. ***jonsger1 is now known as jonsger
<Apteryx>Is there a way to query the guix-daemon to determine what values it's using? <Apteryx>I'd like to know what authorized-keys it's configured to use to validate that my recent addition to config.scm works. <ng0>the process list is one way <ng0>like with top or htop <Apteryx>I could see the --substitute-urls in the command line from the process list, but for authorized-keys i'm not sure. <Apteryx>I think I've read somewhere it's supposed to put those under /etc/guix/acl <Apteryx>I'll clear that file and rerun 'guix system reconfigure /etc/config.scm' to see if that's true. <Apteryx>Yes, that seems to be defined in (gnu services base), in the function hydra-key-authorization. <Apteryx>But this only gets run if the file does not exist (unless (file-exists? "/etc/guix/acl") <davexunit>cehteh: sorry, but I just don't agree that these are problems. <cehteh>problems are in the eye of the beholder, someone who develops for guix and has some deeper knowledge may find a lot things trivial which are hard for someone new and maybe even turn people away <davexunit>I'm personally okay with some amount of that. <cehteh>i didnt spend enough time learning guix/guile yet, but at a start it already confused me when to use cons cons* or list <cehteh>(ok got that now, i am not that much of a noob, just not enough time to study) <cehteh>but lowering entry barriers is imo one of the most important thing for free software and i like to take the devils advocate part and pointing out what things are hard for someone new ***orly_owl_ is now known as orly_owl
<davexunit>I would like to make everything easier that can be made easier without sacrificing good software design. <cehteh>about the services list thing, maybe i try to make a list-unifier which removes duplicate entriies and keeps only the first, using that would be explicit and handy <davexunit>that could work, but we also have the modify-services macro for manipulating service objects. <davexunit>what you suggest is similar to a procedure guile has called delete-duplicates <cehteh>i am pretty much in line with you that things should stay clean and explicit <davexunit>disagreeing on implementation is well and good provided that we both agree on the general principles. :) <cehteh>but some things could be unarguably being easier, like the example configs could have commented out templates for things, they should all have a setup wich includes networking, whenever lists are concatenated cons* should be used even in the simple (cons* element %defaults) case <cehteh>this are little things which wont break anything, but make configuration easier and more orthogonal <Apteryx>Finally found how to make scroll lock work for XTerm: in ~/.Xresources, add "XTerm*vt100.allowScrollLock: true". Then run "xrdb ~/.Xresources". Relaunch XTerm; when you need to lock srolling the "scroll lock" keyboard key should do it. <cehteh>also an example about how to modularize the config.scm would be nice, putting users, services preinstalled packaged into distinct files <cehteh>something else, is there any standard way to pass a secret from grub to the initrd. I am thinking about full system encryption, when the user enters the passphrase it might be hashed again and that passed to the initrd <cehteh>using a 2nd slot to unlock the partition on kernel boot, and then dispose it <Apteryx>It'd be nice if we could see the download speed of substitutes. <Apteryx>The system reconfigure process appears hang on: From ftp://ftp.ciril.fr/pub/cpan/authors/id/J/JS/JSTOWE/TermReadKey-2.32.tar.gz... (like 10 minutes), but it might just be that it's downloading at 0.1 kbps. <Apteryx>Oh actually for the previous substitutes it was displayed. <Apteryx>Looks like the 2.32 URL was purged. The oldest version of TermReadKey is now 2.33. <ng0>how many packages depend on that package? <ng0>you could sent an update :) <Apteryx>I think the only reason I'm finding that problem is because I cleared my "/etc/guix/acl" file (this is required currently to get my reconfigure to create it... suboptimal I feel). <Apteryx>So it's trying to build everything from scratch. Still a bug though. <Apteryx>Also I can't seem to be able to start M-x guix anymore in Emacs. <alezost>Apteryx: re "M-x guix" any error? anymore since when? <Apteryx>Hmm, maybe since I rebuilt guix from master this morning or yesterday... But it could be the previous rebuild 2 days ago too (I hadn't used M-x guix since I think). <Apteryx>The *Messages* buffer is silent about it. <Apteryx>Doing M-x guix doesn't make the pop-up appear. It doesn't appear to do anything. <alezost>Apteryx: does "guix -h" shell command work? <Apteryx>ng0: I think perl-term-readkey is mosly used by git to provide git-svn <Apteryx>ng0: I'll try updating it to the latest 2.3x version. <ng0>you can check via some guix function <ng0>the depndencies I mean <Apteryx>I tried "guix gc --referrers perl-term-readkey", but it seems it wanted to build it at first. <davexunit>Apteryx: does the 'guix' function even exist? <davexunit>the guix emacs integration was deleted from the source tree awhile ago. <davexunit>so if you are using a recent guix then there's no more emacs integration. ***Piece_Maker is now known as Acou_Bass
<alezost>Apteryx: can you go to the Guix REPL buffer and evaluate (help-string) there <Apteryx>davexunit: That might be it, I haven't bothered installing emacs-guix yet, since it was working. <Apteryx>Shouldn't emacs-guix be part of our base packages anyway? <davexunit>things are more complicated now than they used to be. <davexunit>I don't know what the right answer is. personally I've gone back to using the CLI only. <Apteryx>alezost: I guess I should install emacs-guix then? Not sure why emacs is still "running" M-x guix at all (if I do: M-x foobar it tells me there aren't any match for that). <alezost>Apteryx: look at "C-h f guix" to find out where this false "guix" command comes from <alezost>maybe it's from a stale autoloads file <Apteryx>"C-h f guix" requests more input to complete: --> Describe function: guix-emacs- <Apteryx>Then if I choose "guix-emacs-autoload-packages" it shouws me the docstring of it, apparently it comes from "guix-emacs.el" which lives in /gnu/store/dvfnvxq3hy0b56bdcyw0730gvl8s3vdx-emacs-25.1/share/emacs/site-lisp/ <alezost>Apteryx: so davexunit is right; you had an old emacs stuff that was bundled with Guix, but it's not anymore; so if you still want to use it you can do "guix package -i emacs-guix" <alezost>Apteryx: yes that "guix-emacs.el" is the only file that is a part of Guix: it is used to patch our Emacs, so that it can found Emacs packages in your guix profile <Apteryx>OK! Maybe it could by smart enough to educate users about "emacs-guix doesn't appera to be installed" when attempting "M-x guix" ? <davexunit>I think we should just dump the code back in. <alezost>Apteryx: I think that when you run "M-x guix RET" you actually run "M-x guix-emacs-autoload-packages" (emacs probably does this completion automatically); that's why you had no error <alezost>davexunit: I think no one will do it but you ;-) <Apteryx>alezost: That seems to be what happens. A single tab expands to 'guix-emacs-autoload-pacakges' <Apteryx>It makes for a confusing transition :D <Apteryx>For now I have to bike to work in a torrent :D <Apteryx>alezost: It works after installing emacs-guix (duh). <alezost>Apteryx: btw you may look at "M-x guix-help" and "M-x guix-about" :-) ***jonsger1 is now known as jonsger
<Apteryx>Anyone knows how to retrieve the log of my last "guix system reconfigure" ? <Apteryx>Sadly there is no such thing as "guix system build --log-file" <adfeno>ng0: Seriously??? THe project said that? <ng0>but it happens very often <adfeno>Oh.... I see... No LICENSE file. <ng0>I'm asking for license now, sometimes it helps <alezost>Apteryx: right, there is no way to a previous system build log ***paolo_ is now known as paolo
<cbaines>Does anyone know much about the system tests? I've been using guix system container lots, and want to write some tests, but I think all of the system tests in Guix use a VM. How easy would it be to adapt the system test code to work with containers or VMs? <civodul>cbaines: the problem is that system containers need to run as root <civodul>so right now using them is not an option <civodul>do you have an aversion for VMs or something? :-) <cbaines>I'm not sure if some of the functionality of containers will work with a VM <civodul>for tests it shouldn't matter whether the thing runs in a VM or a container (or a physical machine, even) <cbaines>In particular, sharing directories, and running in a VM (as I'd like to not rule out running anything I write in a VM, and I'm not sure how well virtualisation will nest) <civodul>you mean in general or for the system tests? <ng0>the arguments whcih end with = (like --install-from-file=FILE), do they REQUIRE it to be one continuos thing, like --install-from-file=FILE or is a space between = and FILE okay too? <civodul>cbaines: i mean i understand the container vs. VM argument, but i don't see how this applies to the specific case of system tests <civodul>we're not going to write nested system tests, right? :-) <cbaines>but I want to be able to run any tests I write in a VM, so I don't need access to a physical machine <cbaines>I also want to be able to get files from the test system, which I am doing at the moment by sharing directories <civodul>i suppose running the tests always works, even if you're already within a VM; at worst it's slower, but that's ok <civodul>sharing the files is possible, like 'guix system vm --share, but in my experience it's not really necessary <nliadm>ng0: I would assume they're either '--flag' 'arg' or '--flag=arg'? I would expect "--flag= arg" to get parsed like '--flag' '' 'arg' <civodul>maybe because i've mostly written simple tests <ng0>I'm ooking into getting the --bla= not to include the whitespace in my fish completion <cbaines>for this particular thing, I'm looking to use the test framework from Guix to actually just kick off tests within the system, and report back the status of those tests <ng0>i also managed to get package listing in subshell etc :) <ng0>ng0@wasp ~> guix package --show= lisp <ng0>guix package: error: lisp: extraneous argument <civodul>cbaines: like you want to use the test frameworks for external tests or something, right? <ng0>for a first day in writing completions it's okay what I came up with, improvements can come later <civodul>it's Friday night, i guess i'm not working at full speed ;-) <civodul>so yes, the test framework has VMs and QEMU pretty much hardcoded right now <cbaines>at the moment, I've got as far as a guix system container which has a service that runs some tests (written in ruby, testing other services), and then writes the results to a file, and then tells shepherd to stop the system <civodul>i'd welcome improvements to make it more abstract <civodul>so you run the tests from within the system under test? <civodul>the tests we have try to run most of the code on the host <civodul>but yeah, you have to instrument the guest one way or another <civodul>so if you have ideas (or code!) to make the test framework more flexible and all, i'm all for it! <cbaines>At the moment, my instrumentation is having the service kicking off the tests to capture the exit code, and create a all-tests-succeeded file if they did all succeed <cbaines>but, I'm probably going to end up writing some more bash to make this more usable, and what I'd really like to do is write some tests in the style of the system tests in Guix <cbaines>which is why I'm making these enquiries to better understand my options <cbaines>civodul, I don't think I've read that, at least not recently, I'll take a look <ng0>buenouanq: grothoff started fixing cadet <ZombieChicken>civodul: You handle a lot of the file-system related code, right? <ng0>pushing code like a one-person-coding-script <civodul>cbaines: it should give you an idea of how system tests work <civodul>also i'll probably mention it at FOSDEM <civodul>ZombieChicken: not me personally, but GuixSD does :-) <ZombieChicken>ng0: Given another decade, we might have a script the could write Guix <ng0>I'd rather have spoken coding.. but this will never happen probably <ng0>with correct indendation etc <ZombieChicken>I was just wondering if there was any known reason why Grub wouldn't install onto a seperate drive (say, a USB) that was used to boot another set of disk (so /boot is on a removeable thumb drive) <buenouanq>that's not true, the problems would be efficiency and ambiguity <buenouanq>the latter would be taken care of my customizing your personal coding interface <buenouanq>not necessarily - think of it like using someone else"s .emacs <ZombieChicken>and while i'll give it some props on doing some things right, I simply can't get past the horrid UI, nor the apparent need to rewrite the "editor" so that it's actually usable <ZombieChicken>yes. I've used it some. I also wonder at what point it will cause breakage because of the cobbled-together conglomerate of crap that comes with emcas <buenouanq>it is not a product, it is a process - a language and a way of thinking and interacting with your machine <ZombieChicken>Long story short it's a shitty LispM built atop an inefficent editor <ZombieChicken>Like I said, I'll give Emacs props for doing some things right, like being able to actually work with the system unlike vim, which can't <adfeno>But it's often more portable and provides more integration than some other text editors. <adfeno>Being an Emacs user myself, I was once skeptical myself. I couldn't view me using it. <buenouanq>If you don't think Emacs is one of the greatest most beautiful things ever, you haven't read the manual enough times. <ZombieChicken>buenouanq: That sounds quite a lot like "If you aren't a good Christan, you havn't read your Bible enough" <adfeno>also, you don't need to read the manual. <adfeno>You can learn within Emacs itself. <ZombieChicken>I'm convinced there is a middle ground between vim and emacs that would make both parties happy <buenouanq>I'm sure vim is a fine way to edit - But if you're not using it through emacs (with evil-mode or whatever), you don't understand something. I'm not sure what exactly, but it's very important. <buenouanq>like with that sentence, vim and emacs shouldn't be compared like that in any way <buenouanq>one is a text editor, and one is as close as we've ever come to a true universal machine <adfeno>... I only use mostly arrow keys, M-x, C-x b, C-x arrowleft/arrowright, C-x C-s, C-x k, M-w, C-y, and sometimes C-SPC. <buenouanq>they're categorically different things, there is no middle ground as such <ZombieChicken>If you look at emacs from the Lisp Machine perspective, it's crap. You have no real control over the graphic stack, or any of the OS really <buenouanq>and what I'm say is to see it as `just another editor' or whatever is wrong <ZombieChicken>If you look at it from the editor perspective, it's bloated, slow, and the UI is a pain in the ass <adfeno>ZombieChicken: You do have control of OS. <buenouanq>once we can 3D print elisp processors at home, stuff like that will really begin to finally take off <adfeno>One can (start-process ...) and do asynchronous things and even try killing init if not careful. <ZombieChicken>buenouanq: printing processors at home is a long ways off. Might look at FPGAs for Lisp, though <adfeno>You can talk to existing system tools or start some from start-process. <adfeno>But with pure Emacs Lisp, I don't think it's possible. <ZombieChicken>buenouanq: Seriously though, if you know enough to get an FPGA and see if you can get ANY Lisp to run reasonably fast in it. Frankly, I'd rather like to see that done <buenouanq>emacs is a true computer, you are only held back by your knowledge and imagination~ <ZombieChicken>Sure you can write an AI in Bash, but that doesn't mean you won't be commited to an asylum for trying <adfeno>Now... Can you do the same things as you asked with vim? <ZombieChicken>abbe: Hell no. I make it a point to try and avoid writing crap for vim <adfeno>You see... Emacs doesn't need to start window manager, doesn't need to raise a full distro from it, it just needs to integrate with what already exists. <adfeno>I could lanch the system's Python or Perl interpreter and get output. <ZombieChicken>iirc, Vim implemented it's own grep internally instead of simply letting the user call the system's grep implementation <adfeno>I wish GNU Freetalk would be for Emacs. :) <ZombieChicken>Is gnunet useable these days? My last look at it said it ran, but there was no content <buenouanq>we're waiting for the next subversion to be release, which as I understand is not back compatible <buenouanq>10.1 is perfectly usable though - But yes, there are few people and things on it. ***jonsger1 is now known as jonsger
<adfeno>I'm slowly setting my copy of GNUnet. <adfeno>I took the Guix recipe from developmento repository. <ZombieChicken>Well, if you happen to have it going see if you can find Alice in Wonderland on there. Should be in .txt format <adfeno>Don't worry, you probably didn't run it long enough. <adfeno>It takes two weeks to see lots of content in the network. <adfeno>Because, since it's distributed, the peers aren't generally aware of themselves. <buenouanq>mines been down for a while, just started it up again <buenouanq>if I find it, I'll let you know ZombieChicken <adfeno>I'm going to provide my original content throug it. <adfeno>There's also the GNU audio-video archive on it if I'm not mistaken. <ZombieChicken>I recall one of my biggest problems with running Gnunet was resource usage. I seem to recall it really liked my RAM <adfeno>Well... as far as my last test results indicated: I acted as a peer for some contents for a while and it didn't take much.