IRC logs for #baserock for Thursday, 2015-09-03

WalkerdineOkay I'm building it finally00:11
WalkerdineI'll also include to rename the morphologies so that when the build comes up it doesn00:16
Walkerdinesay its building a x86_64 system00:16
WalkerdineI panicked for a second then remembered when I was playing around with the morph I saw the names didnt match with the build00:17
*** lachlanmackenzie has quit IRC03:31
*** lachlanmackenzie has joined #baserock03:31
*** Walkerdine has quit IRC03:32
*** Walkerdine has joined #baserock03:34
*** perryl has joined #baserock05:33
*** zoli__ has joined #baserock05:47
*** zoli__ has quit IRC06:17
*** rdale has quit IRC06:23
*** zoli__ has joined #baserock06:23
WalkerdineHa my build ran out of space06:46
Walkerdineguess I should have used the SSD06:46
*** zoli__ has quit IRC06:51
paulsherwoodack06:53
Walkerdineoh well06:56
WalkerdineIll have to try again tomorrow07:00
paulsherwoodgnite! sleep now! :)07:01
*** zoli__ has joined #baserock07:08
*** toscalix has joined #baserock07:53
*** mdunford has joined #baserock08:09
*** jonathanmaw has joined #baserock08:15
toscalixgood morning08:18
tiagogomes_good morning toscalix08:24
*** petefoth has quit IRC08:30
*** tiagogomes__ has joined #baserock08:42
*** nowster has quit IRC08:42
*** CTtpollard has quit IRC08:42
*** tiagogomes_ has quit IRC08:42
*** gary_perkins has quit IRC08:42
*** mdunford has quit IRC08:42
*** jonathanmaw has quit IRC08:42
*** mdunford has joined #baserock08:43
*** nowster has joined #baserock08:43
*** jonathanmaw has joined #baserock08:43
*** gary_perkins has joined #baserock08:43
*** CTtpollard has joined #baserock08:43
*** franred has joined #baserock08:52
wdutchfirehose question: if chunk x depends on y and x is being watched by firehose and requires a new version of y, will firehose update y?08:53
*** flatmush has joined #baserock08:54
KinnisonCurrently, I doubt it08:56
KinnisonBut configuration could likely be constructed to permit that08:56
Kinnisonthe firehose codebase is currently very much prototypical08:57
wdutchfirehose does very little of what I thought :/ this will give CIAT orchestration a lot of work to do08:59
KinnisonCIAT orchestration can assume firehose will do things it can't currently do09:00
Kinnisonand we can pick and choose our initial software set09:00
Kinnisonthat's fine09:00
KinnisonOver time, things can improve09:00
wdutchokay09:00
Kinnisondon't compensate for missing but intended features09:00
*** Zara has joined #baserock09:08
*** fay_ has joined #baserock09:16
*** pdar has joined #baserock09:18
tlsastratum level build deps will make auto updating of just the actual deps impossible for firehose.  It would need to update every chunk in the build dep statum09:19
Kinnisonindeed09:21
KinnisonTo some extent that's a + and to some extent a -09:22
*** lachlan75 has joined #baserock09:22
*** pdar has quit IRC09:22
*** benbrown_ has joined #baserock09:22
*** lachlan75 has quit IRC09:25
*** pdar has joined #baserock09:25
*** toscalix has quit IRC09:27
*** flatmush has quit IRC09:57
*** tiagogomes__ has quit IRC09:57
*** tiagogomes__ has joined #baserock09:57
*** flatmush has joined #baserock09:58
wdutchnew CIAT diagram: http://i.imgur.com/1FfWvKa.png10:03
*** mdunford has quit IRC10:06
*** toscalix__ has joined #baserock10:10
*** toscalix__ is now known as toscalix10:10
*** mdunford has joined #baserock10:26
wdutchnew new diagram, http://i.imgur.com/y2ezdZ8.png10:34
wdutchI think that is now what Kinnison is describing10:35
tlsalooks good to me10:38
Kinnisonlooks pretty good.  there's a definitoins and we need to ensure the test framework publishes test results to the 'fileserver' block, otherwise that looks good for the basic scheme we're aiming at as a starter-for-ten10:39
wdutchoops10:40
*** rdale has joined #baserock10:44
toscalixwdutch: I will add it to the wiki10:51
KinnisonDo we have a space on the baserock wiki for the CIAT work we're doing?10:51
toscalixno10:52
toscalixI don-t think so10:52
KinnisonPerhaps we should10:52
toscalixhummmmm...... I think that when we come to a positive result, yes10:52
toscalixspecially if we will have a test environment for others to try10:53
toscalixotherwise it is just a "use case"10:53
KinnisonWell, hopefully that'll be by the end of next week10:53
toscalixwhich we should document once it is a success10:53
* Kinnison isn't against displaying use-cases10:53
paulsherwoodin general i think it's better to encourage people to put stuff on the wiki early, so it doesn't get lost/forgotten10:54
toscalixI love use cases10:54
* Kinnison concurs with paulsherwood 10:54
toscalixcan we say that the technology we are using is baserock?10:55
toscalixor is the next generation of baserock?10:55
paulsherwoodbaserock is an 'umbrella'10:55
toscalix* lack info at this point10:55
* toscalix lack info10:55
Kinnisonyeah, baserock is a project in which there's lots of technology10:55
Kinnisonwe'll be basing our solution, for now, on the baserock-style definitions model10:56
toscalixI think the more public we go, the better10:56
toscalixin general10:56
paulsherwoodiiuc what's beeing done is using some existing baserock tooling, improving some other baserock tooling, and integrating some non-baserock tooling10:56
Kinnisonyep10:56
Kinnisonall in a fungible way10:56
* Kinnison is all for modularity this week10:56
paulsherwoodin other news, on #automotive i seem to be completely failing to explain why keeping all the things in git is necessary10:56
paulsherwoodand it's sapping my will to type :)10:57
KinnisonOh dear10:57
toscalixso, instead of documenting CIAT internally and then adding it on baserock once it is done, we will go for documenting it directly on baserock. Am I correct?10:58
KinnisonI'd prefer that10:58
paulsherwoodtoscalix: that would be lovely10:58
paulsherwoodespecially since i'm trying to establish a workable approach for CIAT at GENIVI, AGL and other places10:59
paulsherwoodso being able to point to documentation/discussion/code would be a big help10:59
paulsherwoodbut fwiw the upshot on #automotive is that some folks there consider that tarballs are better, and there's an outstanding action to discuss mirroring with yocto upstream to establish what the community recommends11:00
toscalixThe only thing I need then is a wiki account so I can start11:00
paulsherwoodi think i'm the wrong person to to lead the discussion with yocto upstream11:01
paulsherwood(mainly but not entirely because i can't face learning bitbake in enough detail to have the right level of conversation)11:01
toscalixI cannot help much there. For me it would be a high learning curve too at this point11:03
* Kinnison sadly only knows enough about bitbake to not want to touch it again11:04
paulsherwoodlol11:04
* Kinnison knows this is not a good attitude to have11:04
Kinnisonbut then again, I know enough about nettles to not want to touch them again too11:04
* paulsherwood sympathises11:04
toscalixWould CIAT fit in the Distbuild section of this page as root page? http://wiki.baserock.org/guides/11:06
toscalixnop, the Workflow section could be better....11:07
* toscalix unsure11:07
paulsherwoodtoscalix: i suggest start a new wiki.baserock.org/ciat page, don't add it to guides until there's something for users to do with it?11:08
*** petefoth has joined #baserock11:55
wdutchthe easiest way to have Trove trigger orchestration requires buildbot, would this be a problem?12:14
paulsherwoodwhat are the alternatives?12:17
wdutchhave it ping something living where orchestration lives which then uses buildbot to send it to the localhost, or find out what buildbot actually sends over the network and create it from a script12:18
paulsherwoodi haven't used buildbot, but others like it i know.12:18
wdutchI think we have settled on buildbot for some components, my worry is that it might not to be good to need it on the same box hosting Trove12:19
paulsherwoodack12:19
* wdutch won't worry about it for now12:21
*** tiagogomes__ has quit IRC12:30
*** tiagogomes_ has joined #baserock12:42
Kinnisonwdutch: Find out how to ping over http13:02
Kinnisonwdutch: it's the *only* way you'll get a notification out of trove13:03
wdutchI thought about having something like flask in orchestration13:06
paulsherwoodnot bottle?13:07
wdutchwhichever, I didn't give that bit much thought13:07
wdutchyet13:07
paulsherwood:)13:07
toscalixpaulsherwood: ok, I will create a new page13:16
*** tlsa has quit IRC13:19
*** tlsa_ has joined #baserock13:20
*** tlsa_ is now known as tlsa13:25
toscalixpaulsherwood: it looks like, a month ago, you already created that page. I work on it13:29
toscalixon the wiki I mean13:29
paulsherwood:-)13:30
paulsherwoodi'd forgotten... i started there, then sent the outline to genivi and agl for review13:30
paulsherwoodit's missing my picture13:30
toscalixin one month we have moved forward13:31
*** Walkerdine_ has joined #baserock13:31
paulsherwood:)13:34
toscalixpaulsherwood: did you know about this? http://kernelci.org13:41
toscalixKevin Hilman will be talking about it at ELCE13:41
paulsherwoodi had heard of it, don't know much about it13:42
rjekThat looks very similar in concept to what Simtec did for the ARM kernel13:43
toscalixKevin is now in charge of the Linaro Stable Kernel build-test-release13:44
rjekIt stopped some time ago though: http://armlinux.simtec.co.uk/kautobuild/stats.html13:44
toscalixhe used to be in my group13:45
toscalixseveral of the simtec guys moved to linaro13:46
toscalixlike Nicolas or Deepak13:46
toscalixah, Ben Dooks.....13:47
toscalix:-)13:47
rjekI can tell you with total confidence that neither Nicolas or Deepak are ex-Simtec.13:47
* paulsherwood concurs13:48
toscalixrjek: http://armlinux.simtec.co.uk/whoswho.html13:48
rjekMainly because I've never heard of them :)13:48
toscalixthere is where I got it.13:48
rjektoscalix: ARMLinux != Simtec :13:48
rjek:)13:48
toscalixrjek: ok13:48
* rjek , bjdooks, nowster, Kinnison, and Vincent Sanders are ex-Simtec.13:49
rjekBut Simtec did provide quite a bit of infrastructure for the ARMLinux project.13:49
* wdutch chuckles at the pictures of ben and vince13:50
toscalixunderstood13:50
rjekwdutch: I can find older ones if you want13:50
rjekwdutch: Enjoy this state-of-the-art-for-the-time digital photograph of Dave Walker, Vince, and Ben http://eh.org/cgi-bin/pics.cgi?smiles.jpg13:52
wdutchthose pictures are unflattering enough13:52
*** toscalix has quit IRC14:14
*** toscalix__ has joined #baserock14:15
Walkerdine_My goal for today is to find out how to partition the SSD14:21
paulsherwoodinfrastructure/extensions/simple-network.configure requires cliapp, so ybd can't deploy it14:26
*** tiagogomes_ has quit IRC14:32
*** tiagogomes_ has joined #baserock14:35
KinnisonI thought simple-network had been superceded by systemd-networkd stuff14:43
paulsherwoodmaybe it was in definitions. not in infrastructure it seems14:44
paulsherwoodi'm only trying it because deifnitions doesn't seem to have any examples of 'subsystem'14:44
paulsherwoodsome of the cluster files look extremely weird to me14:45
paulsherwood(fwiw)14:45
*** Walkerdine_ has quit IRC14:48
*** rdale has quit IRC14:56
* paulsherwood can't believe that distcc requires all this ... http://paste.baserock.org/lulacekufa15:03
rjeklol rpm15:04
rjekpaulsherwood: But no, I don't believe it either15:04
*** rdale has joined #baserock15:05
paulsherwoodrjek: have you used distcc?15:05
rjekIn the past, yes15:06
radiofreeyes i think that's just poor dependency management15:06
rjek rjek ▶ platypus ▶ SSH ▶ ~ ▶ $ ▶ apt-cache show distcc15:06
rjekPackage: distcc15:06
rjekVersion: 3.1-515:06
rjekInstalled-Size: 47715:06
rjekMaintainer: Daniel Hartwig <mandyke@gmail.com>15:06
rjekArchitecture: amd6415:06
rjekDepends: libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16), libc6 (>= 2.8), libpopt0 (>= 1.14), adduser (>= 3.52), debconf (>= 0.5) | debconf-2.0, netbase (>= 4.09), lsb-base (>= 3.2-13)15:06
radiofreemesa-libGL-10.6.3-1.20150729.fc22.armv7hl.rpm  ...15:06
radiofreecairo?!15:06
radiofreemesa?!15:06
paulsherwoodso imagine my scenario... n scaleway instances all running ybd and/or distcc15:06
rjeklibavahi-client3 depends on dbus, but that's the only other semi-surprising dependancy in wheezy15:07
paulsherwoodcand distcc clients serve multiple requests at once? requesters?15:07
radiofreepaulsherwood: that seems like a lot of effort for something that probably won't end up being much faster than a chroot on a moonshot15:07
rjekI believe it's quite flexible, yes15:07
* wdutch uses buildbot to open Guess over http :)15:08
paulsherwoodradiofree: i agree it may not stack up, but i'm interested to try it to see what the numbers work out at15:08
rjekI would expect the Moonshut to be faster: the ArmadaXP's Ferocean core is a little faster than a Cortex-A9 and the X-Gene's core a little slower than an Cortex-A53.15:08
rjekMootshut?  Moonshot.15:08
rjekAlso the X-Gene has twice the cores and sixteen times the RAM15:09
rjekpaulsherwood: I may sound trolly, but try using Debian on the Scaleway instead?15:09
paulsherwoodbut also i'm thinking generically.... iirc radiofree you suggested distcc - i'm thinking of trying it on scaleway just cos lots of instances are very cheap15:09
radiofreeyes i think distcc would be excellent to integrate15:09
radiofreedistcc and n moonshot nodes!15:10
rjek+115:10
paulsherwoodrjek: instead of the fedora? i did. there's a compiler bug won't build our stage1-gcc15:10
rjekpaulsherwood: Erk?15:10
rjekDid you file a bug? :)15:10
paulsherwoodradiofree: ack. i'd get it working on scaleway first, then move the approach to moonshot and aws :)15:10
Kinnisondistcc introduces a lot of latency into the compile pipeline, so you need larger parallel build jobs to really take advantage of it15:11
rjekAlso remember that with distcc all pre-processing happens on one box15:11
rjekWhich may be a bottleneck too15:11
paulsherwoodrjek: who do i file the bug against?15:11
radiofreeKinnison: i originally thought it would be good to integrate into distbuild when you reached a chunck that was blocking15:11
radiofreethese tended to be pretty big things, qt-base etc...15:12
rjekpaulsherwood: Probably Debian?  What is the nature of the bug?15:12
radiofreei'd have 5 jetsons all waiting on qt-base15:12
paulsherwoodrjek, Kinnison - yup. but if the concepr proves sound, it may be useful and applicable for other configurations15:12
Kinnisonradiofree: Mmm15:12
Kinnisonpaulsherwood: oh it's certainly worth a play15:13
paulsherwoodi'm thinking that i could (say) have an AWS host or x86 laptop farming arm compiles to lots of (say) scaleway boxes, or jetsons15:13
Kinnisonpaulsherwood: NetSurf uses a 3-way distcc cluster for our armv7hf builds15:13
radiofreeit would still be large for those large things, but when you can build gcc in 10 minutes on a mustang it's not as crucial to me as it once was15:13
radiofrees/large for those/good for those/15:13
paulsherwoodKinnison: please expand on 3-way distcc cluster?15:14
paulsherwood(what hw, and what's 3-way)?15:14
rjekRaspberry Pis15:14
rjekThree of them15:15
Kinnison15:43 < kyllikki> we have a cubietruck 3+rpi2+rpi2 giving a distcc -j9 on two parallel build slots15:15
paulsherwoodrilly?15:15
rjekNetSurf's not written in C++ like Qt, so doesn't need to be sent into the future to be compiled by Skynet.15:15
Kinnisonrjek: 2 raspis not 315:15
rjekOh right15:15
* paulsherwood wonders how long to build the genivi demo platform on that puppy :)15:15
rjekCubie too15:15
rjekI think it takes a few minutes to build NetSurf15:15
Kinnisonpaulsherwood: about two hundred billion years15:15
radiofreeqtwebkit...15:16
paulsherwoodlol15:16
Kinnison15:43 < kyllikki> twenty minutes for all six builds from stone cold cleared ccache15:16
Kinnisonfor NetSurf15:16
KinnisonBut, as rjek says, NetSurf in written in a sane language, rather than C++15:16
paulsherwoodack15:16
paulsherwoodcan a distcc client handle jobs from multiple sources?15:17
jmacsPretty sure ours did when we had a cluster15:18
Kinnisona distcc server can handle requests from more than one place, yes15:18
rjekpaulsherwood: Yes.15:18
KinnisonBut remember, it's entirely up to you to secure the cluster15:18
paulsherwoodack15:18
KinnisonAlso remember that you need to distribute compilers appropriately15:18
Kinnisonwhich for a Baserock build would be very hard15:19
rjekYeah, each system needs to have the same and right compiler on it15:19
paulsherwoodfor 3 quid a moth i may not spend too much time on security. i'd only be playing15:19
rjekWhich you could perhaps do by sharing via NFS15:19
rjekpaulsherwood: You can provide a server with a list of IP addresses to accept jobs from IIRC15:19
rjekpaulsherwood: Do Scaleway give you a VLAN for private communications between all your own systems?15:20
radiofreecouldn't you just do that via nfs?15:20
radiofreeoh rjek said that15:20
rjekYeah, if you set all your systems up to share a single /bin /sbin /usr it might even work :)15:21
radiofreejust share the build area over nfs and chroot into it?15:21
radiofreethe distcc server works in a chroot15:21
rjekFor each build you did you'd need to share it over NFS, chroot, and launch a distcc15:22
rjekRather than the workers being persistent beings.15:22
rjekWhich may or may not be a problem.15:22
paulsherwoodthere's a private ip and public for each mc15:23
rjekMC?15:23
paulsherwoodserver15:23
rjekWhat does the private IP "go to" ?  A virtual network with all a specific customers servers on?15:24
radiofreemaybe you could just tell each node to construct the same build area from a shared cache and chroot into that15:24
paulsherwoodunclear15:24
radiofreedoes distbuild work like that?15:24
rjekIf so, you can just run distcc only on that network interface and tell it to allow the whole network15:24
rjekBut it does seem that getting a consistent and correct environments between all your nodes will be the tricky bit15:29
paulsherwoodi think that's already handled by the sandboxing if we could get distcc to understand that15:33
radiofreewell i *believe* distbuild informs a node to "construct this build area from this cache" and then builds it on the node in that, you'd essentially have to tell each node to "build the same build area from the same cache and launch a distcc server inside it"15:35
radiofreethere's going to be some overhead to distributing the build area anyway15:35
paulsherwoodack15:36
*** fay_ has quit IRC15:39
*** Walkerdine__ has joined #baserock15:52
Walkerdine__I don't think I'm going to be able to figure out how to use the SSD instead of the eMMC :/16:26
*** jonathanmaw has quit IRC16:27
SotKWalkerdine__: how far have you got?16:36
Walkerdine__Well I have everything set up to build but I couldn't get it to build without using the SSD becasue the eMMC doesnt have enough space16:38
Walkerdine__I was told that I could partition the SSD manually but I'm not sure how I should partition it16:39
*** toscalix__ has quit IRC16:40
SotKWhen I was messing with a Jetson I just formatted the whole thing as one ext3 (or maybe btrfs) partition IIRC16:41
SotKs/whole thing/whole SSD/16:41
rjekthen root=/dev/sda in your boot config?16:42
SotKI just added it to my fstab to mount on /src I think16:43
Walkerdine__So root would be on the SSD and the boot would still be eMMC?16:43
paulsherwoodyup16:43
rjekAha16:44
Walkerdine__And the commands are just normal fdisk commands?16:45
Walkerdine__So I can create one partition(ext3? or 4? does it matter?) out of my SSD create a src and set up the workspace like normal and all I have to change is the ROOT in jetson-upgrade.morph16:48
*** toscalix__ has joined #baserock16:48
rjekI would recommend ext4 or XFS as they both support TRIM in order to maximise the lifetime of your SSD16:48
rjek(make sure they are mounted with the option 'discard')16:48
Walkerdine__What does that do16:48
Walkerdine__discard16:49
rjekWalkerdine__: When the file system is done with a block on the underlying device, it causes it to send a TRIM ATA command which tells the SSD's controller that part of the flash is no longer used.16:49
rjekSo it can do better wear-leveling16:49
Walkerdine__okay I'll make sure to do that16:50
* SotK doesn't know how ROOT_DEVICE works off the top of his head16:51
SotKlooks like the device specified as ROOT_DEVICE gets an entry added to the fstab at deploy time expecting it to be btrfs16:54
*** zoli__ has quit IRC16:54
Walkerdine__ooooo so that would change how I partition the drive16:55
SotKyou can probably just leave ROOT_DEVICE in the cluster as the eMMC and mount the SSD somewhere and work in there if you like16:55
radiofreeSotK: i use the ssd for my root device16:56
radiofreehowever had to manually create the partition table on the SSD16:56
radiofreeso 50G for /dev/sda1 (BTRFS) rest for /dev/sda2 (ext4) which will be /src16:57
radiofreeactually this will probably work16:58
* radiofree thinks about it a bit more16:58
radiofree...16:59
radiofreeright got it16:59
Walkerdine__radiofree: yeah i ran out of room when I tried to build jus using the emmc16:59
radiofreeWalkerdine__: that's more down to your lack of /src17:00
radiofreeyou can format the ssd as an ext4 partition and mount that as /src17:00
radiofreei believe the guide mentions that17:00
radiofreehowever, if you did want to put the whole thing on the ssd17:00
radiofree1) create partition table on ssd, /dev/sda1 (btrfs) /dev/sda2 (ext2)17:00
radiofrees/ext2/ext417:00
radiofreesda2 should be bigger17:00
radiofree2) mount a jetson devel image `mount devel-system-armv7lhf-jetson.img /mnt`17:01
radiofree3) copy everything to /dev/sda1 `cp -r /mnt/* /where/your/ssd/sda1/is/mounted`17:01
radiofree4) plug into jetson17:01
radiofreethere are multiple ways to do the next bit (e.g mount it as usb device), but i'll go with the easiest17:02
radiofree5) boot into the devel system already on the jetson, and mount /dev/mmcblk0p1 `mount /dev/mmbclk0p1 /mnt`17:02
radiofree6) edit extlinux.conf to point at /dev/sda1 instead of /dev/mmcblk0p2 (any time there is a root=/dev/mmbclk0p2, replace with root=/dev/sda1)17:02
radiofreenow it'll boot into the ssd instead of emmc, from there on in you can just set ROOT_DEVICE to /dev/sda1 in your cluster17:03
radiofreeit's what i do anyway17:03
radiofreebut as i said before, i only do that because i deploy quite a lot of upgrades for testing etc... so i needed the rootfs to be much bigger than 10G17:04
radiofreei can't remember if the version of u-boot we're using supports sata, if it did you probably could create an image with a partition table and just flash the whole thing to a ssd17:06
radiofreeu-boot will check emmc -> sdcard -> ssd (maybe a more recent version will do it)17:06
* radiofree doesn't have access to a jetson atm so can't check17:07
Walkerdine__I'm also going to be deploying quite a lot of upgrades. I'm going to try this when I get home17:07
*** rdale has quit IRC17:13
Walkerdine__Oh I see what you're talking about with the ext4 partion in the guide17:14
*** Walkerdine__ has quit IRC17:24
*** Walkerdine__ has joined #baserock17:26
*** zoli__ has joined #baserock17:55
*** toscalix__ has quit IRC18:00
*** Walkerdine_ has joined #baserock18:26
*** Walkerdine__ has quit IRC18:27
*** Walkerdine_ has quit IRC18:33
*** Walkerdine_ has joined #baserock18:39
*** Walkerdine_ has quit IRC18:52
*** zoli__ has quit IRC19:01
*** Walkerdine_ has joined #baserock19:26
*** Walkerdine_ has quit IRC20:21
*** Walkerdine_ has joined #baserock20:41
*** Walkerdine_ has quit IRC21:27
*** Walkerdine_ has joined #baserock21:51
*** toscalix__ has joined #baserock22:56
*** Walkerdine_ has quit IRC22:58
*** toscalix__ has quit IRC23:28

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!