IRC logs for #baserock for Friday, 2014-09-19

persiajjardon: I certainly hope so: busybox is great for small, but not so great for not so small.03:25
*** dutch_ [] has joined #baserock07:20
paulsher1ood2014-09-19 07:44:56 [Build 410/1164] [dbus-pre-devel] Removing staging area07:48
paulsher1ood2014-09-19 07:45:37 [Build 436/1164] [systemd-devel] Building chunk systemd-devel07:48
paulsher1oodERROR: Failed to update cached version of repo git://
paulsher1oodi wonder if that's me, or gbo?07:48
paulsher1oodit worked next time round07:48
* SotK is starting to wonder how he ever built glibmm08:01
paulsher1oodSotK: do you have a definitions branch we could try?08:02
paulsher1ood(on gbo or anywhere else?)08:02
SotKI built it (and its dependencies) fine in a system, then added them to a stratum and got a strange failure08:02
paulsher1oodhow did you build it originally?08:03
paulsher1oodwith morph?08:03
SotKI have had the same build failure again when building manually on a slightly different system though08:04
SotKI'm now deploying the exact same system to try to see if it was something I did earlier that somehow made it work08:04
SotKpaulsher1ood: 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 Qt08:06
paulsher1oodSotK: i'm willing to try it, at least :)08:07
SotKwhen I get this system deployed I'll tidy up and push then :)08:10
*** franred [] has joined #baserock08:18
petefothliw-orc: thanks for the RSS/Atom tip08:29
*** violeta [] has joined #baserock08:29
*** thecorconian [] has quit [Remote host closed the connection]08:33
*** jonathanmaw [] has joined #baserock08:36
*** tiagogomes [~tiagogome@] has joined #baserock08:37
*** Krin [] has joined #baserock08:47
*** ssam2 [] has joined #baserock09:09
richard_mawit 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 release10:48
ssam2what's CRUI ?10:48
ssam2Docker has pluggable storage backends which all implement copy-on-write snapshots, so I'm not sure why a hard dependency on this would be needed10:50
ssam2oh, it's for *running* apps10:50
pedroalvarezCool! enabling the following in the kernel I managed to make baserock able to recognize Volumes in Openstack without rebooting!CONFIG_HOTPLUG_PCI=y11:33
pedroalvareznot sure if it's the right approach, though. This is the dmesg ouput:
ssam2i don't know what that means! maybe ask some friendly Linux experts11:54
ssam2seems like enabling HOTPLUG is the right approach, but there might be some further config needed11:55
paulsher1oodcan we have some kind of unionfs approach for layers/strata/changes/ please? can we?  huh? ? are we there yet?11:55
KinnisonIf you want to write a stable, well defined, and supportable unionfs for Linux which upstream will take, then sure11:57
*** thecorconian [~thecorcon@] has joined #baserock11:58
richard_mawpaulsher1ood: not for strata, one of these days I'm going to remove stratum artifacts entirely12:00
paulsher1oodrichard_maw: nod12:01
paulsher1oodare we heading for chunk + assembly, or some other name?12:01
richard_mawthey duplicate information that's already available in the build graph12:01
richard_mawpaulsher1ood: we were thinking integration instead of stratum/system12:01
paulsher1oodplease no12:01
paulsher1oodintegration means too many things already12:02
rjekintegration is a horribily over... that12:02
richard_mawwe're far enough away from implementation that the name doesn't matter yet12:02
rjekAll it Jeff.12:03
rjekCall it Jeff, even.12:03
paulsher1oodrichard_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 etc12:03
paulsher1oodKinnison: re stable unionfs, whatever docker are using?12:03
paulsher1oodi think the docker train is unlikely to stop any time soon12:04
richard_mawpaulsher1ood: so you want a name that's used more than stratum, and used less than integration12:04
paulsher1oodrichard_maw: i would say i'm relatively good at names. and integration is a bad one.12:05
richard_mawpaulsher1ood: 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 it12:05
paulsher1oodrichard_maw: fair.12:05
richard_mawpaulsher1ood: oh, and btw, one of the backends Docker uses is btrfs, in a way that I first suggested somewhere near 2 years ago12:06
* richard_maw ducks12:06
franredjust 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
paulsher1oodrichard_maw: no need to duck :)12:11
paulsher1oodwrt jjardon's coreutils and network mgr patches, i've built them on master, confirm the  resulting weston works. what else to test?12:21
paulsher1oodand what franred said - is that a problem?12:21
richard_mawsystems are 18MB larger, but the tools don't have the weird issues that busybox's versions have12:22
franredpaulsher1ood, I want to deploy a system before giving it my +112:23
ssam2also check there's no GPL3 in coreutils12:24
paulsher1oodcan i rent you my 6 line script?12:24
ssam2otherwise we need to make effort to split it out of the GENIVI systems12:24
paulsher1oodfranred: ^^12:24
franredpaulsher1ood, sure12:24
paulsher1oodwhoa.. can we at this point properly separate dev/build from targets? this creutils shouldn't end up in targets by default?12:25
ssam2your second question isn't worded as a question12:25
ssam2we can do splitting, to a point12:26
ssam2the implementation of splitting needs a bit of work to make it simpler, I think12:26
ssam2simpler for the user, I mean. The code is simple enough :)12:26
richard_mawyou could do splitting to not get coreutils in your system12:27
richard_mawin its current state12:27
paulsher1oodfranred: put it in /src, i call mine - it just builds and deploys to self, in an idempotent styleee12:28
richard_mawwhat it's missing (apart from better validation) is the ability for a stratum to depend on a subset of the artifacts produced by another stratum12:28
franredpaulsher1ood, cheers, I will give it a go12:30
paulsher1oodrichard_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
ssam2we can. Right now 'minimal-system' is Busybox-only12:32
ssam2but 'base-system' is a bit confused about what it is, I think12:32
paulsher1oodok, cool. need minimal for amr, though12:32
paulsher1oodamd mips at some point12:33
ssam2no reason it shouldn't work now, just needs a morphology with the correct 'arch' field12:33
paulsher1oodssam2: yup about the confusion.12:33
paulsher1oodwas it you who suggested distinguishin infrastructure from examples?12:33
paulsher1oodhow many +1s do we need for that? you have mine :)12:34
ssam2just 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
ssam2although it's not so simple, of course. scripts/ needs to be updated, as does the wiki12:38
ssam2or, we could wait until all the forks of Baserock we know about have used scripts/ so that we no longer need to care about it12:38
richard_mawit would be nice to rework it to be "", where it'll remove any morphologies not referenced anywhere, re-work the yaml to be in the preferred formatting, and in-line small ones12:40
*** dutch_ [] has quit [Quit: Quit]13:02
*** dutch [] has joined #baserock13:04
paulsher1oodi remember the days when the plan was to re-shuffle all the morphologies without providing a script at all :)13:28
richard_mawthe original plan was to not move all the chunk morphologies in, only the large ones, and wait for inlining to do the rest of them13:31
richard_mawwe need the script to tidy up what the script has done13:32
paulsher1oodrichard_maw: i have used your latest series, for builds and deploys, no problems13:32
richard_mawpaulsher1ood: can I take that as a +1?13:33
paulsher1oode one tiny question - on my latest depl;oyed devel, i see
paulsher1oodis that unrelated?13:34
paulsher1oodassuming so +113:34
richard_mawnothing related to what I've done, but your local clone of morph is having trouble13:34
paulsher1oodok, +113:34
paulsher1oodshall i mail the list?13:35
richard_mawI'm ok with it being on-channel13:35
paulsher1oodok :)13:35
richard_mawbut you need to `git fsck` your morph clone13:35
franredout 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_mawI 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 them13:38
richard_mawsince then we could hook that up with firehose instead, and if the license hasn't changed, it automatically merges the new version in13:38
paulsher1oodrichard_maw: git fsck where? where is the git repo morph hits for --version?13:39
richard_mawin this case, I think it's your git cache13:39
richard_mawthe --version output there is baked in at build time13:39
paulsher1oodrichard_maw: this is weird, then. morph --version works ok on my normal devel. the git error happens when i boot into a self upgarde13:42
richard_mawthat'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 did13:44
jjardonHi, patch is currently in foundation and its GPLv3. Reading the review of coreutils patches seems this is a bug?13:50
liw-orconly if it ends up in a (deployed) genivi system13:51
KrinOk, 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 linux13:52
Kringive me a bit of time? (note, it's not difficult to fill either criteria)13:52
jjardonliw-orc: strata/foundation.morph is included in genivi-baseline-system-x86_64-generic13:52
liw-orcjjardon, 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 systems13:53
liw-orcjjardon, I forget the name of the script, however13:54
SotKdon't we run a script on the genivi systems at deploy time to strip the GPLv3 componenets?13:54
SotKthe standard minute of lag again there :(13:55
SotKits strip-gplv3.configure I think?13:55
SotKjjardon ^^13:56
jjardonSotK: thanks13:56
paulsher1oodKrin: can you paste log of you strange output?13:56
pedroalvarezErmmm.. I think the script doesn't strip 'patch' 13:56
SotKpedroalvarez: indeed it would appear not13:56
Krinit's very short strange output. i'll post the line i get and what is actualy expected13:56
pedroalvarezI'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
Krinthis line should actualy just run the compiler, calling nvcc alone should simply display the version, but has the same result13:58
paulsher1oodKrin: maybe your invocation, too?13:58
Krinhuh, i copied the invocation, wonder why it didnt print...13:58
Krin / # /usr/local/cuda/bin/nvcc -o test hello-world.cu13:58
paulsher1oodand your what happens is you supply an empty one?13:59
Krini get the same output even if i simply type13:59
Krin / # /usr/local/cuda/bin/nvcc14:00
Krinwhich should give the nvcc version number14:00
radiofreeKrin: is nvcc a binary or a script?14:01
liw-orcKrin, what does nvcc contain?14:01
Krinnvcc is nvidia's cuda compiler. it is a binary.14:02
liw-orcKrin, have you looked at it with less?14:02
Krini have not, however it works when it's not on baserock but on the default software that the jetson comes with14:03
radiofreedoes nvcc --help do anything?14:03
Krinyes nvcc -- help returns14:03
paulsher1oodKrin: is it an ARM binary?14:03
Krinyes it is an arm binary,14:04
paulsher1oodlink to nvcc install instructions, please?14:04
*** benbrown1 [] has joined #baserock14:04
Krin / # /usr/local/cuda/bin/nvcc --help14:04
Krin/usr/local/cuda/bin/nvcc: line 1: syntax error: unexpected "("14:04
paulsher1oodi mean, how/why did it end up there?14:05
Krinthat was the default location for it's install14:05
paulsher1oodbaserock 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
ssam2oops, I forgot about strip-gplv3.configure and thus gave franred bad advice. Sorry!14:05
Krinthere where no install instructions other that to download the .run14:05
Krinand run it.14:05
richard_mawpaulsher1ood: a shell archive typicall14:05
richard_mawself-extracting installer14:06
* paulsher1ood learns something every day14:06 works simmilar to a .exe in windows i discovered, you make it executable and linux can use it14:06
Krini learnt that one today too :)14:06
paulsher1oodok, i have a jetson, tell me whewre to get this magic binary from please?14:06
jjardonSotK : where is that script? its not in defnitions neither in morph repo14:06
SotKdefinitions.git I thought?14:07
Krinunder the ARM tab, the generic CUDA toolkit should be compatible with the Kernal curenly installed14:08
Krinwhich is 3.10.2414:09
paulsher1oodthat's quite a big blob :)14:10
richard_mawwell, they've probably statically linked everything14:11
pedroalvarezKrin: Isn't that version for armv8? 14:12
radiofreegood spot pedroalvarez :P14:13
jjardonSotK: thanks. pedroalvarez maybe patch should be added to the list of modules in that script?14:14
radiofreeKrin: 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
radiofreeKrin: 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
pedroalvarezjjardon: yes, we missed that bit when moving patch to foundation 14:16
radiofreeKrin: there's CUDA toolkit stuff on
radiofreebut i think you have to register14:16
Krinaye 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 that14:17
paulsher1oodKrin: put current kernel on your jetson :)14:17
radiofreethe kernel in the baserock image is the same 3.10 kernel from the R19 release14:18
radiofreeso i think it should work14:18
Krinbut 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 how14:19
* paulsher1ood enjoys scrolling through 100 pages of licence info14:19
Krinahh! 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 before14:20
radiofreemaybe just extract the cuda parts from it?14:20
Krinpaulsher1ood, just quit out of it, it will ask you if you read it afterwards :)14:20
Krinradiofree, 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 again14:31
SotK./; make; make install; works (but installs to /usr/local), ./; ./configure; make; make install; does not work14:32
* SotK is so confused14:32
richard_mawis this one of those ./ scripts that secretly runs ./configure "$@"?14:33
SotKrichard_maw: aha, yes14:34
richard_mawperhaps you can run `./ --prefix="$PREFIX"` then14:35
SotKrichard_maw: probably14:37
radiofreei think NOCONFIGURE=114:41
radiofreeor you can just run autoreconf && ./configure, which i thought was the default in baserock?14:42
richard_mawif there's an, I think we run that14:42
*** benbrown_ [] has joined #baserock14:46
*** benbrown1 [] has quit [Ping timeout: 272 seconds]14:47
*** thecorconian [~thecorcon@] has quit [Ping timeout: 272 seconds]14:49
ridgerunnercan someone shed light on "ERROR: Field comments not allowed in morphology string" during a build?14:50
richard_mawyou're using a newer version of definitions.git than your version of morph supports I think14:50
ssam2this is probably because latest Morph can't build definitions from baserock-14.2914:50
jmacsYes, sounds like the error I had yesterday when trying to build with an old morph14:50
ssam2oh, or maybe the opposite.14:51
ssam2we should do a release!14:51
ridgerunnerOk, I was trying to: "morph --verbose build b14:51
ridgerunner'scuse the line wrap14:51
ridgerunnerssam2: I'm following/adapting the instructions on
*** thecorconian [~thecorcon@] has joined #baserock14:53
ridgerunnerOr trying to.14:54
* paulsher1ood is hacking said instructions to try to plug the hole ridgerunner fell into14:54
rjekThis also explains I problem I have had.14:55
ridgerunnerThanks paulsher1ood, I hope my dumbness is proving useful.14:55
SotKridgerunner: you'll need to follow the instructions at to build modern definitions I think14:55
ridgerunnerSotK: ta, reading now.14:57
SotKssam2 is right, we should do a release to avoid this :)14:57
paulsher1oodso are we back now to *recommending* using latest morph?14:57
ridgerunnerCould 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
radiofreeso latest release baserock can't build master baserock?14:59
radiofreeor is that jetson image really old now14:59
SotKradiofree: correct, but it can build something which can build master baserock14:59
ridgerunnerIt's whatever I pulled following the /devel-with/ page.15:00
paulsher1oodfastest fix for now is to return to 'use latest morph by default', correct?15:01
*** fay_ [] has quit [Remote host closed the connection]15:01
radiofreeSotK: wouldn't you have to know what sha1 of definitions to build though?15:01
ssam2paulsher1ood: we're in a situation where morph from baserock 14.29 can't build master of definitions, as I understand it15:01
*** dutch [] has quit [Quit: Quit]15:01
ssam2seems that morph from Baserock 14.29 should be able to build the baserock-14.29 tag of definitions, though15:01
* ridgerunner is confused. TGIF.15:02
SotKradiofree: nope, just update the morph sha in tools.morph to HEAD and then upgrade your devel system with that15:02
paulsher1oodssam2: so any new user would hit this. hence my proposal. unless someone would like to do a release?15:02
radiofreeSotK: is that documented/discussed anywhere?15:02
paulsher1oodradiofree: i have been considering doing an up-to-date tutorial. i could cover that15:03
radiofreeit's not exactly elegant15:03
ssam2paulsher1ood: 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 one15:03
radiofree"welcome to baserock - first rebuild your system with a new version of morph"15:03
radiofreealthough it might make a good tutorial!15:03
ssam2radiofree: the alternative is base any changes you want to make on the baserock-14.29 tag of definitions.git15:04
paulsher1oodssam2: fix the wiki.15:04
SotKradiofree: 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 definitions15:04
ssam2paulsher1ood: I'm completely in favour of that !15:04
paulsher1oodso i propose to fix the wiki to 'use current morph by default' for now?15:04
ridgerunnerTo be fair, Baserock *is* a work in progress so it's not *too* outlandish :-)15:04
SotKpaulsher1ood: +115:04
pedroalvarezthis is why I'd like to have documentation in a read-the-docs style15:04
paulsher1oodactuallty, hold on. the default instructions should work, since they talk about checkout on the 14.29 tag.15:09
paulsher1oodunless something bad happened, or ridgerunner did something else?15:09
paulsher1oodin any case would be nice to do a release, especially since persia doesn't seem to be around to say releases are superfluous15:10
ssam2the team at Codethink recently discussed waiting until the next GENIVI Intrepid release and doing a full Baserock release at the same time15:11
ssam2which is 3rd Oct or something15:11
ridgerunnerAs 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
ssam2ridgerunner: could I come see you in person and sanity check my various assumptions about this?15:12
ridgerunnerssam2: abso-fragging-lutely.15:12
ssam2ok :)15:13
paulsher1oodin other news, i can't fix my morph version git index bug, richard_maw :/15:15
paulsher1oodi tried removing /src/cache/artifacts/*morph*15:16
paulsher1oodand deleting morph from /src/cache/gits/15:16
paulsher1oodssam2: how would i test your tbdiff patch?15:18
richard_maw might be of interest to people in this channel15:20
richard_maw(some chap wanting to build systemd against musl, rather than glibc)15:20
*** dutch [] has joined #baserock15:20
paulsher1oodKinnison was interested iirc?15:21
richard_mawmostly positive (with the exception of Cristian Rodríguez), most of the strict POSIX compatibility ones were taken15:21
ssam2paulsherwood: build a system where the tbdiff chunk uses ref sam/allow-file-migrations15:21
ssam2then try to update an instance to that system15:22
ssam2by instance I mean 'an existing VM'15:22
richard_mawmost of the missing functionaliy ones told to add the function to musl, the only real point of contention is the functions to extend printf15:22
ssam2turns out ridgerunner followed the instructions exactly, and they don't work15:22
ssam2morph from a baserock 14.29 system can't build the baserock-14.29 tag, due to the invalid field 'comments' in upstream:attr attr.morph15:23
ssam2the best way to fix this is change the instructions to require everyone uses latest morph :(15:23
ssam2we could also fix the 14.29 definitions and force-push the tag (but let's not!)15:24
ssam2or make a 14.39 release so that we can ignore the problem15:24
*** franred [] has quit [Quit: Leaving]15:25
ridgerunnerHave upgraded to latest version of morph and am trying again15:26
*** Krin [] has quit [Remote host closed the connection]15:27
ridgerunnerSame result, I'm afraid.15:29
*** De|ta_ [~arc@] has joined #baserock15:30
*** jmacs_ [] has joined #baserock15:30
*** JPohlman1 [] has joined #baserock15:30
*** doffm_ [~mdoff@] has joined #baserock15:31
*** De|ta [~arc@] has quit [Ping timeout: 250 seconds]15:31
*** doffm [~mdoff@] has quit [Ping timeout: 250 seconds]15:31
*** jmacs [] has quit [Ping timeout: 250 seconds]15:31
*** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has quit [Ping timeout: 250 seconds]15:31
*** juergbi [] has quit [Ping timeout: 250 seconds]15:31
*** juergbi [] has joined #baserock15:33
paulsher1oodssam2: remove comments field?15:34
ssam2paulsher1ood: that doesn't fix baserock-14.29, though15:34
paulsher1oodthe tag, you mean?15:34
ssam2ridgerunner: sorry, I'm still giving you bad / incomplete advice.15:34
ssam2ridgerunner: build master of definitions, too15:35
ssam2this sucks.15:35
radiofreeso new morph can't build baserock-14.29?15:35
ssam2no, because the invalid 'comments' field is still there15:35
ridgerunnerssam2: I don't know what that means.15:35
ssam2ridgerunner: in the instructions that say 'morph checkout baserock-14.29', replace 'baserock-14.29' with 'master'15:35
ssam2what we could do is make a 'baserock-14.29-v2' tag15:36
ssam2with just the 'comments' field removed, so that it builds OK15:36
ssam2that might be better than changing the getting started instructions to be 'use our latest unstable code' :)15:36
ssam2ok, I'll do that15:37
ridgerunnerThat makes sense to me ssam215:37
*** tiagogomes [~tiagogome@] has quit [Remote host closed the connection]15:37
ssam2this is a situation where being able to launch a 14.29 image in OpenStack in 3 clicks is very handy ! :)15:39
ridgerunnerssam2: is it likely to happen this afternoon? If not, I'll do some more kernel work.15:39
pedroalvarezssam2: iirc, attr was one of the 4 problematic chunks15:40
ssam2ridgerunner: I can push a fix in a few minutes if you're OK to test it for me15:40
paulsher1oodssam2: and fix the wiki? :)15:40
ridgerunnernp. Ahm a-waitin.15:40
ssam2in fact, we could do it together :)15:40
ridgerunnerI'll get a cuppaT15:41
*** richard_1aw [] has joined #baserock15:44
pedroalvarezIs intentional that `morph --version` says things like "baserock-14.26-124-g7b73af4" when using morph from git?15:44
pedroalvarezI was going to send a patch to change that, but I wanted to ask before15:45
*** richard_maw [] has quit [Ping timeout: 250 seconds]15:45
*** genii [~quassel@ubuntu/member/genii] has joined #baserock15:45
persiaI thought that was the consensus after the last discussion of the right value for `morph --version`.15:46
persiaBut that consensus was established when there was a new tag every fortnight, so perhaps it is worth discussing it again.15:46
paulsher1oodthe discussion was a nightmare15:46
paulsher1oodi thought we settled on just the SHA115:47
persiaIndeed, and took a lot of time from a lot of folks for what seems to me to be little value.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 release15:47
richard_1awI'm still not sure how that became "only show the sha1"15:47
pedroalvarezin a  devel system fresh deployed, `morph --version` shows the sha115:48
straycatWell, switching to using the sha for the version number did make the release process simpler, indirectly.15:48
pedroalvarezbut if you use the latest morph, it shows the tag, and short sha115:48
* paulsher1ood drops out of this conversation15:48
persiaExcellent.  When the behaviour differs in surprising ways, that can probably be classed as a bug.15:49
persiaMaking 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
pedroalvarezthat's what I mean, people using latest morph, and running morph --version think that they are running 14.2615:50
pedroalvarezI have the patch ready to send15:50
paulsher1oodssam2: gap in my knowledge. how do  hookup my /src disk image to an updated devel?16:06
paulsher1oodwhen i edit the fstab, i get timeout waiting for my device16:06
persiaDo you have a /dev/disk/by-label/src ?16:08
paulsher1oodsrc2 in my case, but yes16:08
persiaCan you mount it manually?16:09
paulsher1oodwhat's the fu please?16:09
persia`mount /dev/disk/by-label/src2 /src` or so16:10
paulsher1oodbah! forgot to make /src2 :)16:10
paulsher1oodstill not working, though...16:11
* paulsher1ood waits for the timeout16:12
paulsher1ooduser error16:12
persiaSince 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
paulsher1oodi futxed my fstab edit16:13
paulsher1oodall good now16:13
persiaAs 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 vocabularies16:16
paulsher1oodthank you - i learn a lot here :)16:17
* petefoth grumbles about persia using long words he doesn't understand16:17
* paulsher1ood has heard persia note that persia has a limited vocabulary... perhaps it's the short words he's missing :)16:18
persiapetefoth: 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
petefothpersia: then I could fail to pronounce as well as fail to understand16:19
* petefoth runs away to have a weekend16:19
persiaNo 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
paulsher1oodwe really should take morph out of tools... changing it causes lots to need to 'rebuild'16:19
persiaHave a good weekend :)16:19
persiapaulsher1ood: An alternative viewpoint is that folk maintaining systems should be changing other stuff more than they change morph.16:20
paulsher1oodyes, ok :)16:20
paulsher1oodpersia: did you see my 6 line script?16:21
persiaPersonally, I'm not convinced that we rebuild enough when we change morph.16:21
persiaChanging morph doesn't require rebootstrapping, which means that it is possible to construct a system that cannot bootstrap.16:21
persiaI didn't.  Was it something like `git rebase master; morph build mytoysystem; morph upgrade mytoysystem; reboot`?16:22
paulsher1oodclose. that's not idempotent16:22
persiaNow I'm curious16:23
persiaFirstly, if that isn't idempotent, I think there's a bug, and secondly, I wonder what other two commands were especially useful16:24
persiaMorph should auto-gc when it needs, rather than requiring the user to do it.16:26
paulsher1oodbut that would make its response time unpredicatable16:27
persiaThat's OK.  It is already unpredictable because it uses git, which might decide to gc on any given operation.16:27
persiaAh, so you're concerned about the state of the system-version-manager output as well, I see.16:28
paulsher1oodmy key point is can do whatever git/edit operations, then run this, boot into my target16:28
paulsher1oodthen get back to where i was16:28
persiaYes, 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
paulsher1oodi've recovered from failed upgrades on this.16:29
persiaFor 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
paulsher1oodbut some fail modes may kill it16:29
paulsher1oodyes i can16:29
paulsher1oodi've done it16:29
persiaI suspect you're confusing "default devel environment set as "factory" and "your working development environment".16:30
paulsher1oodthis is how i bisected the btrfs problem - all the bads didn't boot16:30
paulsher1oodno, i'm not confusing. my workign environment is factory16:30
paulsher1oodi agree we could generalize this16:31
persiaAh, then yes, in the event that "factory" happens to be a suitable development environment, then this works.16:31
persiaAlthough I assert that given the nature of development preferences, that will only be true for one person.16:31
paulsher1oodyes, exactly16:31
persiaNext question: why do you call this a "6-line" script?16:32
paulsher1oodthis is a pretty nice workflow. and i've completely said goodbye to morph edit16:32
persiaIs the final newline especially important in a way I don't understand?16:32
paulsher1oodbecause i can't count?16:32
paulsher1oodno the newline is just mess16:32
persiaDo you end up deploying a new VM whenever you start a problem to get a "just before" working state?16:34
persiaOne of the reasons I don't like factory is that it quickly became ancient in my usage.16:34
paulsher1oodno, i've not had to do that.16:34
paulsher1oodi'm on a 14.28 machine, i just keep updating morph (and sometimes downdating it)16:35
persiaAha, 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
paulsher1oodpersia: then for you, replace factory with yourlabel16:38
paulsher1oodthe 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 test16:39
paulsher1oodssam2: i believe that i have updated from a machine with your tbdiff fix16:40
ssam2paulsher1ood: cool!16:42
persiaI 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 instruction16:42
ssam2I have on my list that we should fix the upgrade logic to upgrade from the running system, rather than 'factory'16:43
ssam2but have not got to it yet16:43
persiapaulsher1ood: And now I understand what should be the 6th line of your script: 'reboot\n'16:43
paulsher1oodyes, there's some kinks to iron out16:43
*** jonathanmaw [] has quit [Quit: Leaving]16:44
paulsher1oodpersia: no, i need to reboot when i'm there. i want to be sure i choose the label16:44
* persia wants an issue tracker harder, so bugs tracking doesn't involve knowing on whose TODO lists things exist16:44
persiapaulsher1ood: Doesn't it default to the most recently installed version?16:45
paulsher1oodquestion: 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
paulsher1oodare others happy with that?16:46
paulsher1oodor should i just say 'works for me' and leave it to others to add up to +216:47
ssam2i'm very happy that you're helping out with testing changes and I consider your opinion significant as to whether something should be merged16:47
persiaI'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
paulsher1oodok thank you.16:47
ssam2i'd be happier if robots could do more of the testing, indeed16:47
paulsher1oodi may disagree on the robots, since i don't trust them :)16:47
persiaWe have robot testers, but the missing bit is a patch management system.16:48
persiaI suppose we could teach the robots to read baserock-dev, but I'd prefer something more robust.16:48
paulsher1oodobviously i'm happy for effective robot testing, but i like finding unique ways to break sw16:48
persiapaulsher1ood: Why don't you trust robots?16:48
paulsher1oodbecause autotesting is not complete, and sometimes engineers develop a false sense of security because the robots smile16:49
liw-orcrobots aren't innovative. exploratory testing by humans is extremely valuable.16:49
persiapaulsher1ood: 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
persiaIn 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
liw-orcwhat we need is a robot that is controlled by an AI that is based in paulsher1ood, obviously16:51
paulsher1oodwhen i smile, usually engineers do *not* feel secure :-)16:51
paulsher1oodliw-orc: thank you :-)16:51
KinnisonWe could just lock paulsher1ood in a box with some food, water, internets, and a mandate to find bugs and provide fixes in return for beer16:51
persiapaulsher1ood: The trick is to find something more humourous and less hyena-like16:51
KinnisonThen we can write on the outside of the box "QA Robot"16:52
persiaKinnison: You'd need a really thick heer16:52
paulsher1oodKinnison: that would work16:52
KinnisonBlueberry Oatmeal Stout16:52
KinnisonThat was chewwy16:52
liw-orcKinnison, that doesn't scale well enough to be a product we can sell, alas16:52
paulsher1oodmy family might object, thouhhjgh16:52
Kinnisonliw-orc: More holes in the box for more internets?16:52
*** dutch [] has quit [Quit: Quit]16:53
persiaJust scan the brain and replicate it on some cloud for scaling.16:53
persia(note that the scanning process may be destructive)16:54
paulsher1oodliw-orc: stick a phone in the box, i'll make acalls while i'm testing :)16:54
paulsher1oodin other news, it's beer o'clock16:54
liw-orcit is, I should go home16:55
*** violeta [] has quit [Ping timeout: 245 seconds]16:56
ssam2i'll merge this: to upstream:attr and push a 14.29.1 tag16:56
ssam2no need, actually16:57
ssam2I just need to update the ref in definitions16:57
persiassam2: Is that the only change required to build 14.29 with current morph?16:57
persiaYes, downgrading the ref in definitions is a cleaner solution.16:58
ssam2persia: a suitable fix is already in the attr baserock/morph branch17:01
ssam2I just need to morph the ref in definitions forward to include that fix17:01
ssam2Morph from 14.29 will also be able to build the 14.29.1 tag17:02
persiaAh, OK.17:03
persiaHaving 14.29.1 morph build 14.29.1 attr makes sense.17:04
persiaDespite 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.3917:09
paulsher1oodisn't that a single command these days?17:09
persiaNot reliably.17:09
persiaThere'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
persiahumans tend to skip steps, or take shortcuts, because humans lack the patience of the inanimate17:10
persiaSo, 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 [] has quit [Quit: Leaving]17:13
JPohlman1 is now known as JPohlmann17:18
straycatI'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
KinnisonI'd just push it all up there, and perhaps drop a mail to the list hilighting the major things17:20
* straycat nods17:20
straycatI'm not completely happy with it yet, but I'd like to push these changes and go from there.17:21
straycats/completely //17:21
straycatI thought about branching the entire site, and working on a branch, but I guess that's probably overkill?17:21
paulsher1oodstraycat: fwiw i was hacking there today, i hope nothing i did conflicts17:23
straycatThat's okay the conflicts shouldn't be too difficult to resolve17:25
paulsher1oodi hate a mystery17:26
persiaDo share, as sharing that there is a mystery is unfufilling :)17:27
paulsher1oodi have a jetson which is suddnly very sluggish on ssh17:27
persiaWhat's the load balance?  IO load?  Is it swapping?17:27
paulsher1oodi have no clue17:27
paulsher1oodit's a devel, not a distbuild17:28
* Kinnison wonders if anyone here knows of something like travis or but for non-github/bitbucket hosted content?17:28
paulsher1oodhas been fine, did a full build today17:28
paulsher1oodsluggishness started after that17:28
persia`uptime` will print the load average: anything more than the number of cores indicates CPU overload17:28
persiaHmm.  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.1017:30
persiabusybox top will show current memory and swap usage with not very much granularity.17:30
paulsher1oodbut i rebooted17:30
persia0.80 is less than your number of cores, so you're not CPU-bound.17:30
paulsher1oodso maybe i'll never know17:30
* paulsher1ood is too impatient17:30
persiaYes, if it's not sluggish now, we can't figure out why it's sluggish now17:30
persiaThere 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
paulsher1oodenough. i give up. beer17:31
persiaFor completeness, if this situation reoccurs, the tools you probably want to use are `top` and `iostat` from what is installed by default.17:32
persiaThe first can tell if you are memory or CPU bound, and help identify the responsible process.17:33
persiaThe 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
persiaNote 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
* persia wonders how it determines when you should run git pull18:16
genii is now known as gunner_genii18:43
* paulsher1ood returns, slightly intoxicated and intent on improving some tiny corner of baserock19:22
paulsher1oodmorph edit linux-x86-64-generic gives ERROR: Failed to clone upstream:linux into /src2/workspace/reference/upstream/linux20:07
paulsher1oodi'm blaming gbo20:07
persiaYes, that is a gbo problem20:09
persiaBut I like this behaviour better than the previous hang-for-periods-in-excess-of-100000s-trying-to-clone-linux20:10
persiaWait, no, that's not gbo at all: you have linux cached.20:10
persiaBut perhaps the cache doesn't have HEAD?20:11
persia(I'm unsure, but I think only working trees have HEAD)20:11
paulsher1oodit failed with linux cached, so i removed the cache20:12
paulsher1oodsame fail with and without20:12
persiaDoes it still fail if you change the ref to something other than HEAD?20:13
persiaI have to head off for a while, but best of luck20:17
paulsher1oodi'll be back in the real world soon myself20:18
paulsher1oodworks with !HEAD20:18
paulsher1oodwell spotted20:19
*** thecorconian [~thecorcon@] has quit [Remote host closed the connection]23:59

Generated by 2.15.3 by Marius Gedminas - find it at!