| persia | jjardon: I certainly hope so: busybox is great for small, but not so great for not so small. | 03:25 |
|---|---|---|
| *** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:20 | |
| paulsher1ood | 2014-09-19 07:44:56 [Build 410/1164] [dbus-pre-devel] Removing staging area | 07:48 |
| paulsher1ood | 2014-09-19 07:45:37 [Build 436/1164] [systemd-devel] Building chunk systemd-devel | 07:48 |
| paulsher1ood | ERROR: Failed to update cached version of repo git://git.baserock.org/delta/systemd | 07:48 |
| paulsher1ood | i wonder if that's me, or gbo? | 07:48 |
| paulsher1ood | it worked next time round | 07:48 |
| * SotK is starting to wonder how he ever built glibmm | 08:01 | |
| paulsher1ood | SotK: do you have a definitions branch we could try? | 08:02 |
| paulsher1ood | (on gbo or anywhere else?) | 08:02 |
| SotK | I built it (and its dependencies) fine in a system, then added them to a stratum and got a strange failure | 08:02 |
| paulsher1ood | how did you build it originally? | 08:03 |
| paulsher1ood | with morph? | 08:03 |
| SotK | manually | 08:04 |
| SotK | I have had the same build failure again when building manually on a slightly different system though | 08:04 |
| SotK | I'm now deploying the exact same system to try to see if it was something I did earlier that somehow made it work | 08:04 |
| SotK | paulsher1ood: I have a messy local branch, I can tidy it up and push to somewhere if you like, but the build will probably take a while since it includes Qt | 08:06 |
| paulsher1ood | SotK: i'm willing to try it, at least :) | 08:07 |
| SotK | when I get this system deployed I'll tidy up and push then :) | 08:10 |
| paulsher1ood | cool | 08:11 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:18 | |
| petefoth | liw-orc: thanks for the RSS/Atom tip | 08:29 |
| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:29 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [Remote host closed the connection] | 08:33 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:36 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 08:37 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:47 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:09 | |
| richard_maw | it looks like Docker's going to depend on CRUI soon to enable checkpoint/restore and migration; LXC is going to support this in its next release | 10:48 |
| ssam2 | what's CRUI ? | 10:48 |
| ssam2 | ah, http://criu.org/Main_Page | 10:49 |
| ssam2 | Docker has pluggable storage backends which all implement copy-on-write snapshots, so I'm not sure why a hard dependency on this would be needed | 10:50 |
| ssam2 | oh, it's for *running* apps | 10:50 |
| ssam2 | cool! | 10:50 |
| pedroalvarez | Cool! enabling the following in the kernel I managed to make baserock able to recognize Volumes in Openstack without rebooting!CONFIG_HOTPLUG_PCI=y | 11:33 |
| pedroalvarez | CONFIG_HOTPLUG_PCI_ACPI=y | 11:33 |
| franred | woot! | 11:35 |
| pedroalvarez | not sure if it's the right approach, though. This is the dmesg ouput: http://pastebin.com/EQFLWQSc | 11:36 |
| ssam2 | i don't know what that means! maybe ask some friendly Linux experts | 11:54 |
| ssam2 | seems like enabling HOTPLUG is the right approach, but there might be some further config needed | 11:55 |
| paulsher1ood | can we have some kind of unionfs approach for layers/strata/changes/ please? can we? huh? ? are we there yet? | 11:55 |
| Kinnison | If you want to write a stable, well defined, and supportable unionfs for Linux which upstream will take, then sure | 11:57 |
| *** thecorconian [~thecorcon@136.1.1.102] has joined #baserock | 11:58 | |
| richard_maw | paulsher1ood: not for strata, one of these days I'm going to remove stratum artifacts entirely | 12:00 |
| paulsher1ood | richard_maw: nod | 12:01 |
| paulsher1ood | are we heading for chunk + assembly, or some other name? | 12:01 |
| richard_maw | they duplicate information that's already available in the build graph | 12:01 |
| richard_maw | paulsher1ood: we were thinking integration instead of stratum/system | 12:01 |
| paulsher1ood | please no | 12:01 |
| paulsher1ood | integration means too many things already | 12:02 |
| rjek | integration is a horribily over... that | 12:02 |
| richard_maw | we're far enough away from implementation that the name doesn't matter yet | 12:02 |
| rjek | All it Jeff. | 12:03 |
| rjek | Call it Jeff, even. | 12:03 |
| paulsher1ood | richard_maw: to you perhaps. i and others have to 'socialize' concepts with non-baserockoers, so if we could agree the naming it'll make things easier. i've suffered a lot because of morph/stratum etc | 12:03 |
| paulsher1ood | Kinnison: re stable unionfs, whatever docker are using? | 12:03 |
| paulsher1ood | i think the docker train is unlikely to stop any time soon | 12:04 |
| richard_maw | paulsher1ood: so you want a name that's used more than stratum, and used less than integration | 12:04 |
| paulsher1ood | richard_maw: i would say i'm relatively good at names. and integration is a bad one. | 12:05 |
| richard_maw | paulsher1ood: it depends on whether the momentum of docker is sufficient that people are willing to put effort into getting AUFS in a state that upstream is happy to merge it | 12:05 |
| paulsher1ood | richard_maw: fair. | 12:05 |
| richard_maw | paulsher1ood: oh, and btw, one of the backends Docker uses is btrfs, in a way that I first suggested somewhere near 2 years ago | 12:06 |
| * richard_maw ducks | 12:06 | |
| franred | just FYI, the new coreutils patch makes chunk.coreutils-bins grown from 4.2 MB to 22.6 MB (some of us wanted to know this) | 12:09 |
| paulsher1ood | richard_maw: no need to duck :) | 12:11 |
| paulsher1ood | wrt jjardon's coreutils and network mgr patches, i've built them on master, confirm the resulting weston works. what else to test? | 12:21 |
| paulsher1ood | and what franred said - is that a problem? | 12:21 |
| richard_maw | systems are 18MB larger, but the tools don't have the weird issues that busybox's versions have | 12:22 |
| franred | agreed | 12:23 |
| franred | paulsher1ood, I want to deploy a system before giving it my +1 | 12:23 |
| ssam2 | also check there's no GPL3 in coreutils | 12:24 |
| paulsher1ood | can i rent you my 6 line script? | 12:24 |
| ssam2 | otherwise we need to make effort to split it out of the GENIVI systems | 12:24 |
| paulsher1ood | franred: ^^ | 12:24 |
| franred | paulsher1ood, sure | 12:24 |
| paulsher1ood | whoa.. can we at this point properly separate dev/build from targets? this creutils shouldn't end up in targets by default? | 12:25 |
| ssam2 | your second question isn't worded as a question | 12:25 |
| ssam2 | we can do splitting, to a point | 12:26 |
| ssam2 | the implementation of splitting needs a bit of work to make it simpler, I think | 12:26 |
| ssam2 | simpler for the user, I mean. The code is simple enough :) | 12:26 |
| richard_maw | you could do splitting to not get coreutils in your system | 12:27 |
| paulsher1ood | franred: http://fpaste.org/134854/ | 12:27 |
| richard_maw | in its current state | 12:27 |
| paulsher1ood | franred: put it in /src, i call mine cycle.sh - it just builds and deploys to self, in an idempotent styleee | 12:28 |
| richard_maw | what it's missing (apart from better validation) is the ability for a stratum to depend on a subset of the artifacts produced by another stratum | 12:28 |
| franred | paulsher1ood, cheers, I will give it a go | 12:30 |
| paulsher1ood | richard_maw, ssam2 - let me backtrack - we opted for busybox because that's the right soln for embedded. no particular need to have it by default in our build/devel systems. why can't we be clear about this distinction and show example embedded target with busybox less coreutils, and have mainline tools in our build/devel/infrastructure systems? | 12:31 |
| ssam2 | we can. Right now 'minimal-system' is Busybox-only | 12:32 |
| ssam2 | but 'base-system' is a bit confused about what it is, I think | 12:32 |
| paulsher1ood | ok, cool. need minimal for amr, though | 12:32 |
| paulsher1ood | arm | 12:32 |
| paulsher1ood | amd mips at some point | 12:33 |
| ssam2 | no reason it shouldn't work now, just needs a morphology with the correct 'arch' field | 12:33 |
| paulsher1ood | ssam2: yup about the confusion. | 12:33 |
| paulsher1ood | was it you who suggested distinguishin infrastructure from examples? | 12:33 |
| ssam2 | yeah | 12:34 |
| paulsher1ood | how many +1s do we need for that? you have mine :) | 12:34 |
| ssam2 | just need to decide what to call the new directories holding the system morphs. 'infrastructure' and 'examples' ? I'm going to go eat lunch and maybe send a patch to do this after lunch :) | 12:37 |
| ssam2 | although it's not so simple, of course. scripts/organise-morphologies.py needs to be updated, as does the wiki | 12:38 |
| ssam2 | or, we could wait until all the forks of Baserock we know about have used scripts/organise-morphologies.py so that we no longer need to care about it | 12:38 |
| richard_maw | it would be nice to rework it to be "normalise-morphologies.py", where it'll remove any morphologies not referenced anywhere, re-work the yaml to be in the preferred formatting, and in-line small ones | 12:40 |
| *** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 13:02 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:04 | |
| paulsher1ood | i remember the days when the plan was to re-shuffle all the morphologies without providing a script at all :) | 13:28 |
| richard_maw | the original plan was to not move all the chunk morphologies in, only the large ones, and wait for inlining to do the rest of them | 13:31 |
| richard_maw | we need the script to tidy up what the script has done | 13:32 |
| paulsher1ood | :-) | 13:32 |
| paulsher1ood | richard_maw: i have used your latest series, for builds and deploys, no problems | 13:32 |
| richard_maw | paulsher1ood: can I take that as a +1? | 13:33 |
| paulsher1ood | e one tiny question - on my latest depl;oyed devel, i see http://fpaste.org/134879/11133593/ | 13:34 |
| paulsher1ood | is that unrelated? | 13:34 |
| paulsher1ood | assuming so +1 | 13:34 |
| richard_maw | nothing related to what I've done, but your local clone of morph is having trouble | 13:34 |
| paulsher1ood | ok, +1 | 13:34 |
| paulsher1ood | shall i mail the list? | 13:35 |
| richard_maw | I'm ok with it being on-channel | 13:35 |
| paulsher1ood | ok :) | 13:35 |
| richard_maw | but you need to `git fsck` your morph clone | 13:35 |
| franred | out of the topic, would be useful to run the licensecheker script when we lorry the repositories and track when the repos has been change their licenses? | 13:36 |
| richard_maw | I don't think so, I'd rather it be part of the system tests that we assert the genivi systems don't have GPLv3 in them | 13:38 |
| richard_maw | since then we could hook that up with firehose instead, and if the license hasn't changed, it automatically merges the new version in | 13:38 |
| paulsher1ood | richard_maw: git fsck where? where is the git repo morph hits for --version? | 13:39 |
| richard_maw | in this case, I think it's your git cache | 13:39 |
| richard_maw | the --version output there is baked in at build time | 13:39 |
| paulsher1ood | richard_maw: this is weird, then. morph --version works ok on my normal devel. the git error happens when i boot into a self upgarde | 13:42 |
| richard_maw | that's because the git cache that built your normal devel didn't have corrupted packs, but the one you used to build your self-upgrade did | 13:44 |
| jjardon | Hi, patch is currently in foundation and its GPLv3. Reading the review of coreutils patches seems this is a bug? | 13:50 |
| liw-orc | only if it ends up in a (deployed) genivi system | 13:51 |
| Krin | Ok, guess it's time for me to speak up in here as I'v run out of ideas. Hey all, i'm trying to get the CUDA toolkit working on baserock, I've found a version of the kit that should be compatible with the kernal that is currently on the jetson board i'm using, toolkit installs fine, but the nvcc (cuda compiler) is having behaviour that is not defined in the documentation. could someone with more experiance of baserock and / or linux | 13:52 |
| Krin | give me a bit of time? (note, it's not difficult to fill either criteria) | 13:52 |
| jjardon | liw-orc: strata/foundation.morph is included in genivi-baseline-system-x86_64-generic | 13:52 |
| liw-orc | jjardon, we have, or used to have, a script in definitions.git that removes things of the system during deployment, to avoid putting gpl3 stuff on deployed systems | 13:53 |
| liw-orc | jjardon, I forget the name of the script, however | 13:54 |
| SotK | don't we run a script on the genivi systems at deploy time to strip the GPLv3 componenets? | 13:54 |
| paulsher1ood | yes | 13:54 |
| SotK | the standard minute of lag again there :( | 13:55 |
| SotK | its strip-gplv3.configure I think? | 13:55 |
| SotK | jjardon ^^ | 13:56 |
| jjardon | SotK: thanks | 13:56 |
| paulsher1ood | Krin: can you paste log of you strange output? | 13:56 |
| pedroalvarez | Ermmm.. I think the script doesn't strip 'patch' | 13:56 |
| SotK | pedroalvarez: indeed it would appear not | 13:56 |
| Krin | it's very short strange output. i'll post the line i get and what is actualy expected | 13:56 |
| pedroalvarez | I'm the one who moved patch to foundation, but when I did it I didn't know about genivi | 13:57 |
| Krin | /usr/local/cuda/bin/nvcc: line 1: syntax error: unexpected "(" | 13:57 |
| Krin | this line should actualy just run the compiler, calling nvcc alone should simply display the version, but has the same result | 13:58 |
| paulsher1ood | Krin: maybe your invocation, too? | 13:58 |
| Krin | huh, i copied the invocation, wonder why it didnt print... | 13:58 |
| Krin | / # /usr/local/cuda/bin/nvcc -o test hello-world.cu | 13:58 |
| paulsher1ood | and your hello-world.cu? what happens is you supply an empty one? | 13:59 |
| Krin | i get the same output even if i simply type | 13:59 |
| Krin | / # /usr/local/cuda/bin/nvcc | 14:00 |
| Krin | which should give the nvcc version number | 14:00 |
| paulsher1ood | weird | 14:01 |
| radiofree | Krin: is nvcc a binary or a script? | 14:01 |
| liw-orc | Krin, what does nvcc contain? | 14:01 |
| Krin | nvcc is nvidia's cuda compiler. it is a binary. | 14:02 |
| liw-orc | Krin, have you looked at it with less? | 14:02 |
| Krin | i have not, however it works when it's not on baserock but on the default software that the jetson comes with | 14:03 |
| radiofree | does nvcc --help do anything? | 14:03 |
| Krin | yes nvcc -- help returns | 14:03 |
| paulsher1ood | Krin: is it an ARM binary? | 14:03 |
| Krin | yes it is an arm binary, | 14:04 |
| paulsher1ood | ok | 14:04 |
| paulsher1ood | link to nvcc install instructions, please? | 14:04 |
| *** benbrown1 [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock | 14:04 | |
| Krin | / # /usr/local/cuda/bin/nvcc --help | 14:04 |
| Krin | /usr/local/cuda/bin/nvcc: line 1: syntax error: unexpected "(" | 14:04 |
| paulsher1ood | i mean, how/why did it end up there? | 14:05 |
| Krin | that was the default location for it's install | 14:05 |
| paulsher1ood | baserock doesn't have in normally :) | 14:05 |
| radiofree | /usr/local/cuda/bin/nvcc: line 1: syntax error: unexpected "(" makes me think it's some kind of script.. | 14:05 |
| ssam2 | oops, I forgot about strip-gplv3.configure and thus gave franred bad advice. Sorry! | 14:05 |
| Krin | there where no install instructions other that to download the .run | 14:05 |
| Krin | and run it. | 14:05 |
| paulsher1ood | .run? | 14:05 |
| richard_maw | paulsher1ood: a shell archive typicall | 14:05 |
| richard_maw | self-extracting installer | 14:06 |
| * paulsher1ood learns something every day | 14:06 | |
| Krin | .run works simmilar to a .exe in windows i discovered, you make it executable and linux can use it | 14:06 |
| Krin | i learnt that one today too :) | 14:06 |
| paulsher1ood | ok, i have a jetson, tell me whewre to get this magic binary from please? | 14:06 |
| jjardon | SotK : where is that script? its not in defnitions neither in morph repo | 14:06 |
| SotK | definitions.git I thought? | 14:07 |
| Krin | https://developer.nvidia.com/cuda-downloads#linux | 14:07 |
| SotK | jjardon: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strip-gplv3.configure | 14:08 |
| Krin | under the ARM tab, the generic CUDA toolkit should be compatible with the Kernal curenly installed | 14:08 |
| Krin | s/curenly/currently | 14:08 |
| Krin | which is 3.10.24 | 14:09 |
| paulsher1ood | that's quite a big blob :) | 14:10 |
| richard_maw | well, they've probably statically linked everything | 14:11 |
| pedroalvarez | Krin: Isn't that version for armv8? | 14:12 |
| radiofree | good spot pedroalvarez :P | 14:13 |
| jjardon | SotK: thanks. pedroalvarez maybe patch should be added to the list of modules in that script? | 14:14 |
| radiofree | Krin: what does file /usr/local/cuda/bin/nvcc say? | 14:15 |
| * Krin looks again. blinks, introduces his face to the desk "you are quite correct, yes it is and i'm an idiot" | 14:15 | |
| pedroalvarez | Hahahah | 14:15 |
| radiofree | Krin: don't feel too bad, had the network not been so slow i was actually going to download the same file to run the same test... | 14:16 |
| pedroalvarez | jjardon: yes, we missed that bit when moving patch to foundation | 14:16 |
| radiofree | Krin: there's CUDA toolkit stuff on https://developer.nvidia.com/jetson-tk1-support | 14:16 |
| radiofree | but i think you have to register | 14:16 |
| Krin | aye radiofree, but when i was researching before, that was not going to run on the current kernal, i'll have a seccond look though, obviusly i need my perscription updating after that | 14:17 |
| paulsher1ood | Krin: put current kernel on your jetson :) | 14:17 |
| radiofree | the kernel in the baserock image is the same 3.10 kernel from the R19 release | 14:18 |
| radiofree | so i think it should work | 14:18 |
| Krin | but the L4T cuda was for 3.13 if i recall correctly, i'll look again as i say, also if i do ned to change the kernal, paulsher1ood, i would have not the faintest notion how | 14:19 |
| * paulsher1ood enjoys scrolling through 100 pages of licence info | 14:19 | |
| Krin | ahh! that was the issue with the Tegra one! it's not just CUDA, it's the whole jetson OS, that would overwrite baserock and put me back to where i was before | 14:20 |
| radiofree | maybe just extract the cuda parts from it? | 14:20 |
| Krin | paulsher1ood, just quit out of it, it will ask you if you read it afterwards :) | 14:20 |
| Krin | radiofree, i'll try, that was what i tried the first time, but i couldent work out which bit was which, i'll have another look though. | 14:21 |
| * SotK makes glibmm build again | 14:31 | |
| pedroalvarez | \o/ | 14:31 |
| SotK | ./autogen.sh; make; make install; works (but installs to /usr/local), ./autogen.sh; ./configure; make; make install; does not work | 14:32 |
| * SotK is so confused | 14:32 | |
| richard_maw | is this one of those ./autogen.sh scripts that secretly runs ./configure "$@"? | 14:33 |
| SotK | richard_maw: aha, yes | 14:34 |
| richard_maw | perhaps you can run `./autogen.sh --prefix="$PREFIX"` then | 14:35 |
| SotK | richard_maw: probably | 14:37 |
| radiofree | i think NOCONFIGURE=1 | 14:41 |
| radiofree | or you can just run autoreconf && ./configure, which i thought was the default in baserock? | 14:42 |
| richard_maw | if there's an autogen.sh, I think we run that | 14:42 |
| radiofree | ah | 14:42 |
| *** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock | 14:46 | |
| *** benbrown1 [~benbrown@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 272 seconds] | 14:47 | |
| *** thecorconian [~thecorcon@136.1.1.102] has quit [Ping timeout: 272 seconds] | 14:49 | |
| ridgerunner | can someone shed light on "ERROR: Field comments not allowed in morphology string" during a build? | 14:50 |
| richard_maw | you're using a newer version of definitions.git than your version of morph supports I think | 14:50 |
| ssam2 | this is probably because latest Morph can't build definitions from baserock-14.29 | 14:50 |
| jmacs | Yes, sounds like the error I had yesterday when trying to build with an old morph | 14:50 |
| ssam2 | oh, or maybe the opposite. | 14:51 |
| ssam2 | we should do a release! | 14:51 |
| ridgerunner | Ok, I was trying to: "morph --verbose build b | 14:51 |
| ridgerunner | ase-system-armv7-versatile.morph" | 14:51 |
| ridgerunner | 'scuse the line wrap | 14:51 |
| ridgerunner | ssam2: I'm following/adapting the instructions on http://wiki.baserock.org/devel-with/ | 14:53 |
| *** thecorconian [~thecorcon@136.1.1.102] has joined #baserock | 14:53 | |
| ridgerunner | Or trying to. | 14:54 |
| * paulsher1ood is hacking said instructions to try to plug the hole ridgerunner fell into | 14:54 | |
| rjek | This also explains I problem I have had. | 14:55 |
| ridgerunner | Thanks paulsher1ood, I hope my dumbness is proving useful. | 14:55 |
| SotK | ridgerunner: you'll need to follow the instructions at http://wiki.baserock.org/using-latest-morph/ to build modern definitions I think | 14:55 |
| paulsher1ood | ughhh | 14:56 |
| ridgerunner | SotK: ta, reading now. | 14:57 |
| SotK | ssam2 is right, we should do a release to avoid this :) | 14:57 |
| paulsher1ood | so are we back now to *recommending* using latest morph? | 14:57 |
| ridgerunner | Could I suggest that pages like that could benefit from a bit more explanation as to what they are instructing you to do, and why? | 14:59 |
| radiofree | so latest release baserock can't build master baserock? | 14:59 |
| radiofree | or is that jetson image really old now | 14:59 |
| SotK | radiofree: correct, but it can build something which can build master baserock | 14:59 |
| ridgerunner | It's whatever I pulled following the /devel-with/ page. | 15:00 |
| paulsher1ood | fastest fix for now is to return to 'use latest morph by default', correct? | 15:01 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 15:01 | |
| radiofree | SotK: wouldn't you have to know what sha1 of definitions to build though? | 15:01 |
| ssam2 | paulsher1ood: we're in a situation where morph from baserock 14.29 can't build master of definitions, as I understand it | 15:01 |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 15:01 | |
| ssam2 | seems that morph from Baserock 14.29 should be able to build the baserock-14.29 tag of definitions, though | 15:01 |
| * ridgerunner is confused. TGIF. | 15:02 | |
| SotK | radiofree: nope, just update the morph sha in tools.morph to HEAD and then upgrade your devel system with that | 15:02 |
| paulsher1ood | ssam2: so any new user would hit this. hence my proposal. unless someone would like to do a release? | 15:02 |
| radiofree | SotK: is that documented/discussed anywhere? | 15:02 |
| paulsher1ood | radiofree: i have been considering doing an up-to-date tutorial. i could cover that | 15:03 |
| radiofree | it's not exactly elegant | 15:03 |
| ssam2 | paulsher1ood: what's your proposal? i'd like to do a release, but we've previously discussed waiting until the next GENIVI Baseline release is due to do one | 15:03 |
| radiofree | "welcome to baserock - first rebuild your system with a new version of morph" | 15:03 |
| radiofree | although it might make a good tutorial! | 15:03 |
| ssam2 | radiofree: the alternative is base any changes you want to make on the baserock-14.29 tag of definitions.git | 15:04 |
| paulsher1ood | ssam2: fix the wiki. | 15:04 |
| SotK | radiofree: only if you want to use master of definitions, and then only because we haven't done a release since we moved to chunks in definitions | 15:04 |
| ssam2 | paulsher1ood: I'm completely in favour of that ! | 15:04 |
| paulsher1ood | so i propose to fix the wiki to 'use current morph by default' for now? | 15:04 |
| ridgerunner | To be fair, Baserock *is* a work in progress so it's not *too* outlandish :-) | 15:04 |
| SotK | paulsher1ood: +1 | 15:04 |
| pedroalvarez | this is why I'd like to have documentation in a read-the-docs style | 15:04 |
| paulsher1ood | actuallty, hold on. the default instructions should work, since they talk about checkout on the 14.29 tag. | 15:09 |
| paulsher1ood | unless something bad happened, or ridgerunner did something else? | 15:09 |
| paulsher1ood | in any case would be nice to do a release, especially since persia doesn't seem to be around to say releases are superfluous | 15:10 |
| paulsher1ood | :-) | 15:11 |
| ssam2 | the team at Codethink recently discussed waiting until the next GENIVI Intrepid release and doing a full Baserock release at the same time | 15:11 |
| ssam2 | which is 3rd Oct or something | 15:11 |
| ridgerunner | As far as I know, I followed the instructions verbatim up to the point at which I changed to trying to do an ARM build rather than an x86 one (with the proviso that I inadvertently skipped on whole section of the nstructions. | 15:11 |
| ssam2 | ridgerunner: could I come see you in person and sanity check my various assumptions about this? | 15:12 |
| ridgerunner | ssam2: abso-fragging-lutely. | 15:12 |
| ssam2 | ok :) | 15:13 |
| paulsher1ood | in other news, i can't fix my morph version git index bug, richard_maw :/ | 15:15 |
| paulsher1ood | i tried removing /src/cache/artifacts/*morph* | 15:16 |
| paulsher1ood | and deleting morph from /src/cache/gits/ | 15:16 |
| paulsher1ood | ssam2: how would i test your tbdiff patch? | 15:18 |
| paulsher1ood | (symlink) | 15:18 |
| richard_maw | http://lists.freedesktop.org/archives/systemd-devel/2014-September/023177.html might be of interest to people in this channel | 15:20 |
| richard_maw | (some chap wanting to build systemd against musl, rather than glibc) | 15:20 |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:20 | |
| paulsher1ood | Kinnison was interested iirc? | 15:21 |
| richard_maw | mostly positive (with the exception of Cristian Rodríguez), most of the strict POSIX compatibility ones were taken | 15:21 |
| ssam2 | paulsherwood: build a system where the tbdiff chunk uses ref sam/allow-file-migrations | 15:21 |
| ssam2 | then try to update an instance to that system | 15:22 |
| ssam2 | by instance I mean 'an existing VM' | 15:22 |
| richard_maw | most of the missing functionaliy ones told to add the function to musl, the only real point of contention is the functions to extend printf | 15:22 |
| ssam2 | turns out ridgerunner followed the instructions exactly, and they don't work | 15:22 |
| ssam2 | morph from a baserock 14.29 system can't build the baserock-14.29 tag, due to the invalid field 'comments' in upstream:attr attr.morph | 15:23 |
| ssam2 | the best way to fix this is change the instructions to require everyone uses latest morph :( | 15:23 |
| ssam2 | we could also fix the 14.29 definitions and force-push the tag (but let's not!) | 15:24 |
| ssam2 | or make a 14.39 release so that we can ignore the problem | 15:24 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 15:25 | |
| ridgerunner | Have upgraded to latest version of morph and am trying again | 15:26 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 15:27 | |
| ridgerunner | Same result, I'm afraid. | 15:29 |
| *** De|ta_ [~arc@195.242.156.171] has joined #baserock | 15:30 | |
| *** jmacs_ [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 15:30 | |
| *** JPohlman1 [~jannis@m65s13.vlinux.de] has joined #baserock | 15:30 | |
| *** doffm_ [~mdoff@23.226.235.108] has joined #baserock | 15:31 | |
| *** De|ta [~arc@195.242.156.171] has quit [Ping timeout: 250 seconds] | 15:31 | |
| *** doffm [~mdoff@23.226.235.108] has quit [Ping timeout: 250 seconds] | 15:31 | |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 250 seconds] | 15:31 | |
| *** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has quit [Ping timeout: 250 seconds] | 15:31 | |
| *** juergbi [~juerg@vserver.paldo.org] has quit [Ping timeout: 250 seconds] | 15:31 | |
| *** juergbi [~juerg@vserver.paldo.org] has joined #baserock | 15:33 | |
| paulsher1ood | ssam2: remove comments field? | 15:34 |
| ssam2 | paulsher1ood: that doesn't fix baserock-14.29, though | 15:34 |
| paulsher1ood | the tag, you mean? | 15:34 |
| ssam2 | yeah | 15:34 |
| ssam2 | ridgerunner: sorry, I'm still giving you bad / incomplete advice. | 15:34 |
| paulsher1ood | heh | 15:34 |
| ssam2 | ridgerunner: build master of definitions, too | 15:35 |
| ssam2 | this sucks. | 15:35 |
| radiofree | so new morph can't build baserock-14.29? | 15:35 |
| ssam2 | no, because the invalid 'comments' field is still there | 15:35 |
| ridgerunner | ssam2: I don't know what that means. | 15:35 |
| ssam2 | ridgerunner: in the instructions that say 'morph checkout baserock-14.29', replace 'baserock-14.29' with 'master' | 15:35 |
| ssam2 | what we could do is make a 'baserock-14.29-v2' tag | 15:36 |
| ssam2 | with just the 'comments' field removed, so that it builds OK | 15:36 |
| ssam2 | that might be better than changing the getting started instructions to be 'use our latest unstable code' :) | 15:36 |
| paulsher1ood | yup | 15:37 |
| richard_maw | baserock-14.29.1 | 15:37 |
| paulsher1ood | +1 | 15:37 |
| ssam2 | ok, I'll do that | 15:37 |
| ridgerunner | That makes sense to me ssam2 | 15:37 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Remote host closed the connection] | 15:37 | |
| ssam2 | this is a situation where being able to launch a 14.29 image in OpenStack in 3 clicks is very handy ! :) | 15:39 |
| ridgerunner | ssam2: is it likely to happen this afternoon? If not, I'll do some more kernel work. | 15:39 |
| pedroalvarez | ssam2: iirc, attr was one of the 4 problematic chunks | 15:40 |
| ssam2 | ridgerunner: I can push a fix in a few minutes if you're OK to test it for me | 15:40 |
| paulsher1ood | ssam2: and fix the wiki? :) | 15:40 |
| ridgerunner | np. Ahm a-waitin. | 15:40 |
| ssam2 | in fact, we could do it together :) | 15:40 |
| ridgerunner | I'll get a cuppaT | 15:41 |
| *** richard_1aw [~richard_m@xvm-21-133.ghst.net] has joined #baserock | 15:44 | |
| pedroalvarez | Is intentional that `morph --version` says things like "baserock-14.26-124-g7b73af4" when using morph from git? | 15:44 |
| pedroalvarez | I was going to send a patch to change that, but I wanted to ask before | 15:45 |
| *** richard_maw [~richard_m@xvm-21-133.ghst.net] has quit [Ping timeout: 250 seconds] | 15:45 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 15:45 | |
| persia | I thought that was the consensus after the last discussion of the right value for `morph --version`. | 15:46 |
| persia | But that consensus was established when there was a new tag every fortnight, so perhaps it is worth discussing it again. | 15:46 |
| paulsher1ood | the discussion was a nightmare | 15:46 |
| paulsher1ood | i thought we settled on just the SHA1 | 15:47 |
| persia | Indeed, and took a lot of time from a lot of folks for what seems to me to be little value. | 15:47 |
| paulsher1ood | +1 | 15:47 |
| * richard_1aw was of the opinion that the problem wasn't the output, but that people had inferred the requirement that the output had to look nice after a release | 15:47 | |
| richard_1aw | I'm still not sure how that became "only show the sha1" | 15:47 |
| pedroalvarez | in a devel system fresh deployed, `morph --version` shows the sha1 | 15:48 |
| straycat | Well, switching to using the sha for the version number did make the release process simpler, indirectly. | 15:48 |
| pedroalvarez | but if you use the latest morph, it shows the tag, and short sha1 | 15:48 |
| * paulsher1ood drops out of this conversation | 15:48 | |
| persia | Excellent. When the behaviour differs in surprising ways, that can probably be classed as a bug. | 15:49 |
| persia | Making it sensible to submit a patch causing the behaviour when running from git to match the behaviour when running from a fresh release. | 15:49 |
| persia | (without needing long discussion, or considering any other potential values) | 15:50 |
| pedroalvarez | that's what I mean, people using latest morph, and running morph --version think that they are running 14.26 | 15:50 |
| pedroalvarez | I have the patch ready to send | 15:50 |
| paulsher1ood | ssam2: gap in my knowledge. how do hookup my /src disk image to an updated devel? | 16:06 |
| paulsher1ood | when i edit the fstab, i get timeout waiting for my device | 16:06 |
| persia | Do you have a /dev/disk/by-label/src ? | 16:08 |
| paulsher1ood | src2 in my case, but yes | 16:08 |
| persia | Can you mount it manually? | 16:09 |
| paulsher1ood | what's the fu please? | 16:09 |
| persia | `mount /dev/disk/by-label/src2 /src` or so | 16:10 |
| paulsher1ood | bah! forgot to make /src2 :) | 16:10 |
| paulsher1ood | still not working, though... | 16:11 |
| * paulsher1ood waits for the timeout | 16:12 | |
| paulsher1ood | user error | 16:12 |
| paulsher1ood | :) | 16:13 |
| persia | Since that works for me when I upgrade, you have an interesting problem. Maybe start by reviewing dmesg to see when /dev/by-label/src2 appeared to get a hint as to what is supposed to be providing it. | 16:13 |
| paulsher1ood | i futxed my fstab edit | 16:13 |
| paulsher1ood | all good now | 16:13 |
| persia | As a side note, in technology circles "fu" is usually interpreted as 文 (style, artistry). I think this is the first time I've seen it used for 咐r (command, strike, blow) | 16:16 |
| * persia grumbles about the imprecision of phonetic transliteration systems for ideographic vocabularies | 16:16 | |
| paulsher1ood | thank you - i learn a lot here :) | 16:17 |
| * petefoth grumbles about persia using long words he doesn't understand | 16:17 | |
| * paulsher1ood has heard persia note that persia has a limited vocabulary... perhaps it's the short words he's missing :) | 16:18 | |
| persia | petefoth: Had I my druthers, I'd be using short ideograms you didn't understand instead, but I fear I may never reach a sufficient level of erudition to do this well, and did I, I'm not sure I'd find a community of peers to receive them :) | 16:18 |
| petefoth | persia: then I could fail to pronounce as well as fail to understand | 16:19 |
| * petefoth runs away to have a weekend | 16:19 | |
| persia | No worries. There's well over a billion people who use ideographic vocabularies daily, and they have pitched arguments on a regular basis over which of them is pronouncing everything horridly incorrectly. | 16:19 |
| paulsher1ood | we really should take morph out of tools... changing it causes lots to need to 'rebuild' | 16:19 |
| persia | Have a good weekend :) | 16:19 |
| persia | paulsher1ood: An alternative viewpoint is that folk maintaining systems should be changing other stuff more than they change morph. | 16:20 |
| paulsher1ood | yes, ok :) | 16:20 |
| paulsher1ood | persia: did you see my 6 line cycle.sh script? | 16:21 |
| persia | Personally, I'm not convinced that we rebuild enough when we change morph. | 16:21 |
| persia | Changing morph doesn't require rebootstrapping, which means that it is possible to construct a system that cannot bootstrap. | 16:21 |
| persia | I didn't. Was it something like `git rebase master; morph build mytoysystem; morph upgrade mytoysystem; reboot`? | 16:22 |
| paulsher1ood | close. that's not idempotent | 16:22 |
| persia | Now I'm curious | 16:23 |
| persia | Firstly, if that isn't idempotent, I think there's a bug, and secondly, I wonder what other two commands were especially useful | 16:24 |
| paulsher1ood | http://fpaste.org/134937/ | 16:25 |
| persia | Morph should auto-gc when it needs, rather than requiring the user to do it. | 16:26 |
| paulsher1ood | +1 | 16:27 |
| paulsher1ood | but that would make its response time unpredicatable | 16:27 |
| persia | That's OK. It is already unpredictable because it uses git, which might decide to gc on any given operation. | 16:27 |
| paulsher1ood | yup | 16:27 |
| persia | Ah, so you're concerned about the state of the system-version-manager output as well, I see. | 16:28 |
| paulsher1ood | my key point is can do whatever git/edit operations, then run this, boot into my target | 16:28 |
| paulsher1ood | then get back to where i was | 16:28 |
| persia | Yes, that is more idempotent, although it 1) relies on what I consider a bug about use of "factory", and 2) does not permit recovery from failed upgrades. | 16:28 |
| paulsher1ood | i've recovered from failed upgrades on this. | 16:29 |
| persia | For example, if you change the kernel into something that doesn't boot, you can't return to your working development environment to fix it. | 16:29 |
| paulsher1ood | but some fail modes may kill it | 16:29 |
| paulsher1ood | yes i can | 16:29 |
| paulsher1ood | i've done it | 16:29 |
| persia | I suspect you're confusing "default devel environment set as "factory" and "your working development environment". | 16:30 |
| paulsher1ood | this is how i bisected the btrfs problem - all the bads didn't boot | 16:30 |
| paulsher1ood | no, i'm not confusing. my workign environment is factory | 16:30 |
| paulsher1ood | i agree we could generalize this | 16:31 |
| persia | Ah, then yes, in the event that "factory" happens to be a suitable development environment, then this works. | 16:31 |
| persia | Although I assert that given the nature of development preferences, that will only be true for one person. | 16:31 |
| paulsher1ood | yes, exactly | 16:31 |
| persia | Next question: why do you call this a "6-line" script? | 16:32 |
| paulsher1ood | this is a pretty nice workflow. and i've completely said goodbye to morph edit | 16:32 |
| persia | Is the final newline especially important in a way I don't understand? | 16:32 |
| paulsher1ood | because i can't count? | 16:32 |
| paulsher1ood | :) | 16:32 |
| paulsher1ood | no the newline is just mess | 16:32 |
| persia | Do you end up deploying a new VM whenever you start a problem to get a "just before" working state? | 16:34 |
| persia | One of the reasons I don't like factory is that it quickly became ancient in my usage. | 16:34 |
| paulsher1ood | no, i've not had to do that. | 16:34 |
| paulsher1ood | i'm on a 14.28 machine, i just keep updating morph (and sometimes downdating it) | 16:35 |
| persia | Aha, so you're running locally-built software, which explains how this works. | 16:35 |
| * persia defined systems including stuff like newer morph, tig, etc. to make a working environment, but then didn't want to go back to "factory" | 16:35 | |
| paulsher1ood | persia: then for you, replace factory with yourlabel | 16:38 |
| paulsher1ood | the key point for me is i can fire and forget the build-deploy as one command. then reboot when i come back to it to test | 16:39 |
| paulsher1ood | ssam2: i believe that i have updated from a machine with your tbdiff fix | 16:40 |
| ssam2 | paulsher1ood: cool! | 16:42 |
| persia | I thought that replacing "factory" didn't work, because the upgrade logic depended on a hidden symlink named "factory" to work. | 16:42 |
| * persia has previously redirected factory, but it required a fair bit of time and instruction | 16:42 | |
| ssam2 | I have on my list that we should fix the upgrade logic to upgrade from the running system, rather than 'factory' | 16:43 |
| ssam2 | but have not got to it yet | 16:43 |
| persia | paulsher1ood: And now I understand what should be the 6th line of your script: 'reboot\n' | 16:43 |
| paulsher1ood | yes, there's some kinks to iron out | 16:43 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:44 | |
| paulsher1ood | persia: no, i need to reboot when i'm there. i want to be sure i choose the label | 16:44 |
| * persia wants an issue tracker harder, so bugs tracking doesn't involve knowing on whose TODO lists things exist | 16:44 | |
| paulsher1ood | yup | 16:44 |
| persia | paulsher1ood: Doesn't it default to the most recently installed version? | 16:45 |
| paulsher1ood | question: i've lately been giving +1 based on *testing* things in some instances, rather than reviewing code, since imo others are better placed to assess code and i'm relatively brutal at testing. | 16:46 |
| paulsher1ood | are others happy with that? | 16:46 |
| paulsher1ood | or should i just say 'works for me' and leave it to others to add up to +2 | 16:47 |
| ssam2 | i'm very happy that you're helping out with testing changes and I consider your opinion significant as to whether something should be merged | 16:47 |
| persia | I'm happy as long as we don't have any robots participating in the review process. If we reach the point where both robots and humans are reviewing code, I think humans should restrict themselves to semantic review. | 16:47 |
| paulsher1ood | ok thank you. | 16:47 |
| ssam2 | i'd be happier if robots could do more of the testing, indeed | 16:47 |
| paulsher1ood | i may disagree on the robots, since i don't trust them :) | 16:47 |
| persia | We have robot testers, but the missing bit is a patch management system. | 16:48 |
| persia | I suppose we could teach the robots to read baserock-dev, but I'd prefer something more robust. | 16:48 |
| paulsher1ood | obviously i'm happy for effective robot testing, but i like finding unique ways to break sw | 16:48 |
| persia | paulsher1ood: Why don't you trust robots? | 16:48 |
| paulsher1ood | because autotesting is not complete, and sometimes engineers develop a false sense of security because the robots smile | 16:49 |
| liw-orc | robots aren't innovative. exploratory testing by humans is extremely valuable. | 16:49 |
| persia | paulsher1ood: I fail to see the difference between that and the engineers feeling a false sense of security because you smile. | 16:49 |
| jmacs_ | They are extremely dogmatic though, which human testers aren't. You need a combination of both. | 16:50 |
| liw-orc | (both are needed, IMO) | 16:50 |
| persia | In my dream world, there's a git repo to which humans that are good at breaking software submit instructions to break software so the robots get better. | 16:50 |
| paulsher1ood | lol | 16:51 |
| liw-orc | what we need is a robot that is controlled by an AI that is based in paulsher1ood, obviously | 16:51 |
| paulsher1ood | when i smile, usually engineers do *not* feel secure :-) | 16:51 |
| paulsher1ood | liw-orc: thank you :-) | 16:51 |
| Kinnison | We could just lock paulsher1ood in a box with some food, water, internets, and a mandate to find bugs and provide fixes in return for beer | 16:51 |
| persia | paulsher1ood: The trick is to find something more humourous and less hyena-like | 16:51 |
| Kinnison | Then we can write on the outside of the box "QA Robot" | 16:52 |
| persia | Kinnison: You'd need a really thick heer | 16:52 |
| persia | s/heer/beer/ | 16:52 |
| paulsher1ood | Kinnison: that would work | 16:52 |
| Kinnison | Blueberry Oatmeal Stout | 16:52 |
| Kinnison | That was chewwy | 16:52 |
| liw-orc | Kinnison, that doesn't scale well enough to be a product we can sell, alas | 16:52 |
| paulsher1ood | my family might object, thouhhjgh | 16:52 |
| Kinnison | liw-orc: More holes in the box for more internets? | 16:52 |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 16:53 | |
| persia | Just scan the brain and replicate it on some cloud for scaling. | 16:53 |
| persia | (note that the scanning process may be destructive) | 16:54 |
| paulsher1ood | liw-orc: stick a phone in the box, i'll make acalls while i'm testing :) | 16:54 |
| paulsher1ood | in other news, it's beer o'clock | 16:54 |
| liw-orc | it is, I should go home | 16:55 |
| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 16:56 | |
| ssam2 | i'll merge this: http://sprunge.us/FUWa to upstream:attr and push a 14.29.1 tag | 16:56 |
| ssam2 | no need, actually | 16:57 |
| ssam2 | I just need to update the ref in definitions | 16:57 |
| persia | ssam2: Is that the only change required to build 14.29 with current morph? | 16:57 |
| persia | Yes, downgrading the ref in definitions is a cleaner solution. | 16:58 |
| ssam2 | persia: a suitable fix is already in the attr baserock/morph branch | 17:01 |
| ssam2 | I just need to morph the ref in definitions forward to include that fix | 17:01 |
| ssam2 | Morph from 14.29 will also be able to build the 14.29.1 tag | 17:02 |
| persia | Ah, OK. | 17:03 |
| persia | Having 14.29.1 morph build 14.29.1 attr makes sense. | 17:04 |
| persia | Despite being down in the very idea of versions, with the lack of robots ensuring cache and download images are always up-to-date, I'm looking forward to 14.39 | 17:09 |
| paulsher1ood | :) | 17:09 |
| paulsher1ood | isn't that a single command these days? | 17:09 |
| persia | Not reliably. | 17:09 |
| paulsher1ood | :) | 17:10 |
| persia | There's lots of things humans have to do to make sure they don't make human-class mistakes because of the aforementioned lack of robots. | 17:10 |
| persia | humans tend to skip steps, or take shortcuts, because humans lack the patience of the inanimate | 17:10 |
| persia | So, paradoxically, a human-based process requires lots more care and lots more steps and lots more verification, so that when the humans take shortcuts, they don't end up skipping anything important. | 17:11 |
| * persia thinks humans are warm and cuddly and smart and utterly untrustworthy when it comes to things like releasing software or manufacturing goods, etc. | 17:12 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:13 | |
| JPohlman1 is now known as JPohlmann | 17:18 | |
| straycat | I've made quite a lot of changes to the wiki, but it's mostly cosmetic - can I just merge this stuff or do you want me to send it for review - it's still a work in progress. | 17:19 |
| Kinnison | I'd just push it all up there, and perhaps drop a mail to the list hilighting the major things | 17:20 |
| * straycat nods | 17:20 | |
| straycat | I'm not completely happy with it yet, but I'd like to push these changes and go from there. | 17:21 |
| straycat | s/completely // | 17:21 |
| straycat | I thought about branching the entire site, and working on a branch, but I guess that's probably overkill? | 17:21 |
| Kinnison | probably | 17:22 |
| paulsher1ood | straycat: fwiw i was hacking there today, i hope nothing i did conflicts | 17:23 |
| straycat | That's okay the conflicts shouldn't be too difficult to resolve | 17:25 |
| paulsher1ood | hmmm... | 17:26 |
| paulsher1ood | i hate a mystery | 17:26 |
| persia | Do share, as sharing that there is a mystery is unfufilling :) | 17:27 |
| paulsher1ood | i have a jetson which is suddnly very sluggish on ssh | 17:27 |
| persia | What's the load balance? IO load? Is it swapping? | 17:27 |
| paulsher1ood | i have no clue | 17:27 |
| paulsher1ood | it's a devel, not a distbuild | 17:28 |
| * Kinnison wonders if anyone here knows of something like travis or drone.io but for non-github/bitbucket hosted content? | 17:28 | |
| paulsher1ood | has been fine, did a full build today | 17:28 |
| paulsher1ood | sluggishness started after that | 17:28 |
| persia | `uptime` will print the load average: anything more than the number of cores indicates CPU overload | 17:28 |
| persia | Hmm. None of my favorite debugging commands seem to be installed on devel systems. | 17:30 |
| paulsher1ood | 17:29:27 up 3 min, 0 users, load average: 0.80, 0.28, 0.10 | 17:30 |
| persia | busybox top will show current memory and swap usage with not very much granularity. | 17:30 |
| paulsher1ood | but i rebooted | 17:30 |
| persia | 0.80 is less than your number of cores, so you're not CPU-bound. | 17:30 |
| paulsher1ood | so maybe i'll never know | 17:30 |
| * paulsher1ood is too impatient | 17:30 | |
| persia | Yes, if it's not sluggish now, we can't figure out why it's sluggish now | 17:30 |
| paulsher1ood | heh | 17:31 |
| persia | There may be logs, but it's hard to know which ones (most of the things that cause a system to slow don't get logged, as that would make it *even* slower, and irritate folk) | 17:31 |
| paulsher1ood | enough. i give up. beer | 17:31 |
| persia | For completeness, if this situation reoccurs, the tools you probably want to use are `top` and `iostat` from what is installed by default. | 17:32 |
| persia | The first can tell if you are memory or CPU bound, and help identify the responsible process. | 17:33 |
| persia | The second can tell you if you are IO-bound, but the busybox implementation doesn't seem to have any way to determine the responsible process or device. | 17:33 |
| persia | Note that one can also be network-bound, but I've not found any good tools to check this (I tend to use iftop and lsof as a start when encountering this, but generally try to get a faster network) | 17:35 |
| * straycat is smitten with https://github.com/milkbikis/powerline-shell | 17:56 | |
| * persia wonders how it determines when you should run git pull | 18:16 | |
| genii is now known as gunner_genii | 18:43 | |
| * paulsher1ood returns, slightly intoxicated and intent on improving some tiny corner of baserock | 19:22 | |
| straycat | :) | 19:31 |
| paulsher1ood | :( | 20:06 |
| paulsher1ood | morph edit linux-x86-64-generic gives ERROR: Failed to clone upstream:linux into /src2/workspace/reference/upstream/linux | 20:07 |
| paulsher1ood | i'm blaming gbo | 20:07 |
| paulsher1ood | http://fpaste.org/134997/ | 20:08 |
| persia | Yes, that is a gbo problem | 20:09 |
| persia | But I like this behaviour better than the previous hang-for-periods-in-excess-of-100000s-trying-to-clone-linux | 20:10 |
| persia | Wait, no, that's not gbo at all: you have linux cached. | 20:10 |
| persia | But perhaps the cache doesn't have HEAD? | 20:11 |
| persia | (I'm unsure, but I think only working trees have HEAD) | 20:11 |
| paulsher1ood | it failed with linux cached, so i removed the cache | 20:12 |
| paulsher1ood | same fail with and without | 20:12 |
| persia | Does it still fail if you change the ref to something other than HEAD? | 20:13 |
| paulsher1ood | trying | 20:13 |
| persia | I have to head off for a while, but best of luck | 20:17 |
| paulsher1ood | :) | 20:17 |
| paulsher1ood | i'll be back in the real world soon myself | 20:18 |
| paulsher1ood | works with !HEAD | 20:18 |
| paulsher1ood | well spotted | 20:19 |
| *** thecorconian [~thecorcon@136.1.1.102] has quit [Remote host closed the connection] | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!