*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 02:07 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 245 seconds] | 02:11 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:35 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 09:29 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 09:29 | |
Kinnison | SotK_: If you were to do that, it'd make sense to start by making Lorry accept YAML | 10:24 |
---|---|---|
Kinnison | SotK_: (checking that the JSON outputted by current l-c can be parsed as YAML obv.) | 10:25 |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [] | 11:07 | |
* persia has temporarily run out of vitrol, and goes to gain some more before again assulting the baserock-dev backlog | 16:05 | |
* straycat wonders whether install-files should be documented on the wiki | 16:48 | |
persia | I'd prefer documentation to be in the development system than in the wiki. | 16:50 |
persia | Mind you, if we were to create some nice docs in a way that we could autogenerate to a website, I'd be happy with that as well, but I worry that adding lots more docs to the wiki, especially for implementation details ends up being confusing and hard to maintain over multiple revisions. | 16:50 |
straycat | Okay | 16:51 |
persia | That said, I had trouble finding useful documentation for any of the configuration extensions, and having something on the wiki as a start might be a reasonsble thing, as all the better options require more infrastructure. | 16:51 |
straycat | Hrm, maybe we should more clearly document the fact that you can do morph help foo.configure | 16:52 |
persia | That would help, and if `morph help install-files.configure` provides useful information, then perhaps it doesn't need to also be on the wiiki. | 16:54 |
persia | Does morph also have a way to discover the confguration extensions for which help is available? | 16:54 |
persia | If so, that also should be documented, preferably clearly in `morph help` | 16:54 |
* persia also wants manpages, and some /usr/share/doc/morph/ content, but wanting random stuff doesn't make it happen | 16:55 | |
straycat | persia, Exactly, the wiki can just have a section that shows you where to get help. | 16:59 |
persia | That would be lovely. A page on the wiki detailing how to use the online docs helps folk get the right version of the docs for the version of morph (and versions of any configuration extensions provided externally to morph) correctly. | 17:00 |
straycat | There's morph help-extensions, but that doesn't seem to work on my system. | 17:01 |
persia | :( | 17:15 |
paulsher1ood | persia: i think your email to petefoth was rather harsh? he was only trying to help, i think | 17:17 |
* paulsher1ood has been known to be harsh too, of course | 17:19 | |
* petefoth1 can live with 'harsh', and doesn't take this stuff personally, though he will often respond robustly :) | 17:32 | |
paulsher1ood | '/topic grumpy folks discuss Baserock' :-) | 17:43 |
persia | It was mostly harsh because my first knowledge that something like that was being constructed was an email to an address I don't use for Baserock inviting me to a service I disagree about. | 17:59 |
persia | That I've been fairly clear that I believe such systems are anti-community in the past contributed, I'm sure :) | 17:59 |
straycat | oh, colours in systemd aren't being displayed correctly | 19:33 |
rjek | Grumpy old men, eh? | 19:34 |
rjek | The colours in systemd's messages are new-fangled, and thus make me sad. | 19:34 |
rjek | Well, a little sad. Perhaps disappointed is more the word. | 19:34 |
straycat | hello rjek :) | 19:36 |
rjek | Hi there straycat | 19:37 |
* paulsher1ood discovers that morph already has some kind of conditional processing, since there seems to be a case statement in stage2-glibc | 19:42 | |
straycat | you mean the cases in the various commands? install-commands? That doesn't strike me as being the same as having conditional inclusion of chunks. | 19:48 |
paulsher1ood | ok, you're probably right | 19:55 |
paulsher1ood | http://paste.baserock.org/uyesacazel.erlang_repl | 21:23 |
* paulsher1ood seems to have got into an odd state... no space left. morph commands crash | 21:23 | |
paulsher1ood | this is on a brand new br vm (but with existing /src image) | 21:24 |
persia | did you remember to link /src/morph.conf to /etc/morph.conf | 21:30 |
* persia often forgets for new development environments | 21:30 | |
paulsher1ood | yes, did that. | 21:34 |
paulsher1ood | this issue was present in my main machine. i dropped it, created a new one, same effect | 21:34 |
persia | Morph usually doesn't complain at me unless I have < 20G free, so not sure why. | 21:35 |
persia | Does `morph gc` help? | 21:35 |
* persia doubts it, but has to ask | 21:35 | |
paulsher1ood | http://paste.baserock.org/etiledaran.rb | 21:36 |
paulsher1ood | for all morph commands | 21:36 |
paulsher1ood | including gc | 21:36 |
* paulsher1ood wonders if there's some magic in the /src image he doesn't know about | 21:36 | |
* persia has never seen that error before | 21:39 | |
* paulsher1ood neither | 21:39 | |
paulsher1ood | i notice that the thing that's actually full is /run | 21:40 |
paulsher1ood | and that has udev in it | 21:40 |
persia | That isn't a very informative message then. Hrm. | 21:41 |
persia | For that matter, /run probably shouldn't fill up, as it generally only contains tiny runtime information, unless something significant changed whilst I wasn't paying attention to the plumbing. | 21:41 |
paulsher1ood | and i wonder if my previous cyclings into latest systemd could have contributed to this? | 21:42 |
paulsher1ood | this would assume that tmpfs is somehow mounted on the /src | 21:42 |
paulsher1ood | actually /run is 184.0k. tmpfs is claiming 1GB availabile | 21:45 |
paulsher1ood | so my theory fails | 21:46 |
paulsher1ood | in /src/morph, git pull gives 'error: cannot open .git/FETCH_HEAD: No space left on device' | 21:47 |
paulsher1ood | so this is looking like maybe something messed up in my /src btrfs | 21:47 |
persia | I remember seeing a recommendation earlier not to use btrfs for /src, being as ext4 was preferable. | 21:49 |
persia | Mind you, this was for data space: for system space, btrfs allows useful nifty tricks (especially with disposable replacable systems where one doesn't care so much about data integrity) | 21:50 |
jjardon | "Fetching to local cache" <- magic words :) | 22:24 |
* SotK_ has seen that error when his btrfs disk has filled up before... df can sometimes report free space when there isn't actually any when using btrfs | 23:03 | |
SotK_ | paulsher1ood: https://btrfs.wiki.kernel.org/index.php/FAQ#if_your_device_is_large_.28.3E16GiB.29 may be of some help | 23:05 |
*** SotK_ [~adam@host86-149-5-74.range86-149.btcentralplus.com] has quit [Ping timeout: 240 seconds] | 23:09 | |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 23:27 | |
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 23:55 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!