IRC logs for #baserock for Wednesday, 2016-03-30

*** gtristan has quit IRC00:18
*** gtristan has joined #baserock00:19
*** gtristan has quit IRC02:37
*** gtristan has joined #baserock02:41
*** edcragg has quit IRC02:45
*** gtristan has quit IRC04:11
*** gtristan has joined #baserock04:44
*** fay has joined #baserock07:12
*** fay is now known as Guest7052107:13
*** paulwaters_ has joined #baserock07:33
*** lc_ has joined #baserock07:35
*** bashrc_ has joined #baserock08:02
*** ssam2 has joined #baserock08:17
*** ChanServ sets mode: +v ssam208:17
*** anahuelamo has joined #baserock08:19
*** rdale has joined #baserock08:24
*** edcragg has joined #baserock08:44
*** jonathanmaw has joined #baserock08:45
*** lc_ has quit IRC08:45
*** bruce_ has joined #baserock08:59
*** franred has joined #baserock09:01
*** edcragg has quit IRC09:03
pedroalvarezHi guys09:03
pedroalvarezI wonder if there is any ybd user around that wants to test
*** Guest70521 is now known as faybrocklebank09:04
*** jmacs_ is now known as jmacs09:05
franredpedroalvarez, I will review it but I don't have the time to test the change.09:07
pedroalvarezfranred: no worries, I think we are not in a rush anyway09:08
franredpedroalvarez, ok, also I think the only way to test that change is to build all the ci systems and the easy way to do it is just merging it09:09
franredI love that you like my suggestion :P09:10
pedroalvarezit's a good one indeed09:11
pedroalvarezbut I was hoping someone could do a basic test with ybd before merging it09:11
franredI though ybd was already working with submodules before you patch for morph09:12
franredpedroalvarez, &&09:12
pedroalvarezalthough given that locallycompact added support to ybd, and also created the migration script, I expect it to work09:12
pedroalvarezas you can see, I was thinking the same thing09:13
*** edcragg has joined #baserock09:22
*** locallycompact has joined #baserock09:34
jjardonpedroalvarez: is your cache for Qt available somewhere?09:34
jjardonalso, can we reconsider ?09:35
pedroalvarezjjardon: note that all my genivi-demo-platform testing is for armv7, I had some problems with x86, radiofree suggested that qt upgrade would help, but never tested that09:48
franredpedroalvarez, in the submodules patch, when the submodule is defined in the definition, it is defined by its name or by its path? <-- locallycompact?09:48
pedroalvarezjjardon: so, qt cache would be for armv7, if that helps I can upload it somewhere09:48
franredlocallycompact, ok, thanks :)09:48
pedroalvarezjjardon: regarding ci.morph, I want to still check that baselines build. Given that x86 GDP version doesn't work, I didn't see any value on testing it09:51
jjardonpedroalvarez: ok, can we consider this working system instead then?
pedroalvarezjjardon: yeah, I didn't -1 it, just wanted to raise the point that ci builds will take a few hours more09:59
pedroalvarezmy suggestion was to think about everything before going forward, but no discussion happened10:00
franredjjardon, pedroalvarez, it is fine few hours more at the moment if people gets the cache. So Im up for it, at least we will be building more chunks constantly and testing that buuild doesn't break for systems some people are using10:02
jjardonbetter a couple of hours more in one machine than a couple of hours in every single person that want to build the Qt stratum, isn't? :)10:02
pedroalvareznote that is morph cache10:03
pedroalvarez(just in case you are expecting it to work with ybd)10:03
jjardonpedroalvarez: I do not care what cache is really. But the ybd mantainer keeps a cache of what is in ci.morph anyway10:05
*** bashrc_ has quit IRC10:06
pedroalvarezI see10:09
pedroalvarezright, that makes sense10:09
franredpedroalvarez, looks fine so far, except from some github repositories which we may want to transform in upstream ones?10:13
pedroalvarezfranred: yeah, I spotted that too, but didn't want to take care of that in the same patch10:15
*** franred has quit IRC10:19
*** franred has joined #baserock10:31
pedroalvarezlocallycompact: some questions: 1)  does ybd fails if it tries to build a chunk with submodules that aren't defined in the stratum?10:32
pedroalvarezlocallycompact: 2) Could you give a try to using ybd?10:32
franredpedroalvarez, oh, I see. ok, I will remove the -1 then10:32
locallycompactyeah it will fail10:33
locallycompactor it should fail if I write it correctly10:34
pedroalvarezlocallycompact: hm.. I thought about making it an error in morph too, but I thought that then, sometimes you don't really care about the submodules10:34
pedroalvarezyou just want to try something10:35
*** gtristan has quit IRC10:42
*** franred has quit IRC11:24
*** gtristan has joined #baserock11:28
*** franred has joined #baserock11:37
*** bashrc_ has joined #baserock12:59
*** toscalix has joined #baserock13:12
*** toscalix has quit IRC13:17
*** toscalix has joined #baserock13:21
*** toscalix has quit IRC13:21
*** toscalix has joined #baserock13:22
*** toscalix has quit IRC13:22
*** toscalix has joined #baserock13:24
*** toscalix has quit IRC13:31
*** franred has quit IRC14:02
*** gtristan has quit IRC14:03
*** franred has joined #baserock14:14
*** gtristan has joined #baserock14:39
anahuelamoHi! I tried to deploy systems/build-system-x86_64.morph using clusters/minimal-system-deploy.morph and when I create the VM I get this: "Booting from Hard Disk... SYSLINUX 6.03 EDD 20150313 Copyright (C) 1994-2014 H Peter Anvin et al  Boot error"14:39
anahuelamoany help with this?14:39
ssam2I think the issue is:!/story/6514:40
ssam2seems gtristan got around this by modifying the deployment code, i wonder if he can share what he did?14:42
richard_mawlast time I did it, it was just to add a couple more flags to the command-line to turn off features that version of syslinux doesn't understand14:43
gtristanrichard_maw, it's not that error, it's version mismatch of syslinux/btrfs tools14:43
gtristanWhat I did was completely totally ugly14:43
gtristanHere... to be viewed in all it's gory ugliness:
gtristanI used a btrfs-tools that I built myself, and used extlinux built inside the staged system14:46
pedroalvarezright, this workaround is not nice at all14:48
ssam2definitely not the ideal solution ! but it's a sensible thing for anahuelamo to try, right?14:48
pedroalvarezwe are going to face a lot of problems if we stop controlling the environment14:48
ssam2a few folk suggest continuing to control the environment, but in a different way14:49
ssam2i.e. you specify 'deploy within this system', the build tool builds that system, then executes the deployment commands inside it using a chroot14:49
ssam2which is more or less what I do now, except I install the chroot manually, then run the build tool inside the chroot :-)14:49
gtristanIt's what I did, and its the reason that no patch ever came from it :)14:50
gtristanssam2, interesting, I hadnt thought of building all the way up to say, core.morph and then installing/running ybd from inside a chroot14:52
pedroalvarez"oh, nice, my build server has built my system, I'm going to deploy it...  building stage1-binutils?? hang on"14:52
pedroalvarezall of these workflows need a bit of thinking14:52
gtristanpedroalvarez, yes, thats why in aboriginal-ybd I wanted to have 'deploy-depends', that would work without building everything twice14:53
edcraggi've taken to running the rawdisk extension directly, without morph or ybd14:53
gtristanhowever, it would again make more sense if strata were not so rigid, i.e. it would make sense that deployment.morph strata declare chunks that are shared with other strata14:54
pedroalvarezedcragg: totally possible, here we are talking about dependencies like btrfs-tools and syslinux14:54
edcraggindeed, i've had a lot of problems with compatibilty with btrfs tools versions in distros when deploying14:55
gtristananecdotal at best: I installed btrfs-tools on debian stretch, and it assumed that my own system was using btrfs, and proceeded to overwrite my initramfs with something ridiculous, which did not contain the required cryptfs tooling14:56
* gtristan rescued and manually created an initrd in a chroot... on the plane to Brussels14:57
* richard_maw wonders if it might be better short-tem to give up on the idea that we can use the extlinux we built, and rely entirely on the version from the host15:02
richard_mawsince AIUI the biggest problem is the mismatch there15:02
gtristanrichard_maw, I think the opposite15:02
richard_mawso perhaps changing install_syslinux_blob to use the mbr.bin from the host system15:02
richard_mawgtristan: long term I agree with you, I think short term we're better off making it work for now15:03
gtristanOh you mean the blob from the host, I see... yeah if that works15:04
richard_mawfiddling with the mkfs.btrfs to turn off more flags and fixing the mismatch between the mbr.bin and the extlinux --install ought to get you closer quicker than having extensions run tools from a chroot15:04
*** franred has quit IRC15:05
ssam2anahuelamo: if you do want to test deploying from inside a chroot, you can get a chroot from here:
anahuelamothank you all! I'll see what I can do15:12
*** franred has joined #baserock15:18
*** franred has quit IRC16:19
*** ssam2 has quit IRC16:33
*** jonathanmaw has quit IRC16:37
*** faybrocklebank has quit IRC16:44
*** bruce_ has quit IRC16:55
*** bashrc_ has quit IRC17:01
*** edcragg has quit IRC17:06
*** anahuelamo has quit IRC17:41
*** locallycompact has quit IRC17:41
*** edcragg has joined #baserock18:39
*** locallycompact has joined #baserock19:02
*** cosm has quit IRC19:04
*** locallycompact has quit IRC19:05
*** trn has quit IRC20:04
*** trn has joined #baserock20:25
*** edcragg has quit IRC23:57

Generated by 2.15.3 by Marius Gedminas - find it at!