IRC logs for #baserock for Thursday, 2014-11-06

*** rdale [] has quit [Ping timeout: 256 seconds]01:54
*** rdale [] has joined #baserock01:56
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock04:47
*** rdale_ [] has joined #baserock06:32
*** rdale [] has quit [Ping timeout: 255 seconds]06:36
*** rdale [] has joined #baserock06:47
*** rdale_ [] has quit [Ping timeout: 256 seconds]06:50
*** dutch [] has joined #baserock08:21
dutch is now known as wdutch08:27
*** wdutch [] has quit ["Ex-Chat"]08:29
*** tiagogomes [~tiagogome@] has joined #baserock08:32
*** mariaderidder [] has joined #baserock08:57
*** mauricemoss_ [] has joined #baserock09:05
paulsher1oodrobtaylor: ^^09:17
paulsher1oodi am strongly against richard_maw's proposal for runtime depends. i would like to see strata gone entirely, not made even more complex. am i alone in this?09:18
paulsher1oodcosm: could we do the same to the acer cb5, do you know?09:19
*** jonathanmaw [] has joined #baserock09:20
Kinnisonpaulsher1ood: I'm strongly in favour of runtime-depends because I see it as a step towards simplifying the model09:20
*** dutch [] has joined #baserock09:20
dutch is now known as wdutch09:21
paulsher1oodi still do not see the need for them at all. and looking at richard_maw's patch series there's a whole load of new 'validation' so as a user i fear that means that morph will once again error at me in new obscure ways09:23
* Kinnison utterly failed to understand your proposed content model, but will admit to being un-caffeinated while reading it09:25
Kinnisonruntime-depends are a step along the way of removing system as a morphology kind09:25
Kinnisonwhich I see as a simplification of the model09:25
paulsher1oodat the price of adding runtime-depends, which is more complexity09:26
KinnisonI think it'll actually reduce cognitive load over all09:26
rjekThe problem sounds complex.09:26
KinnisonHowever I think Richard Maw will do better at explaining than I will, given it's his idea09:26
*** wdutch [] has quit [Quit: Quit]09:27
*** wdutch [] has joined #baserock09:27
paulsher1oodthe problem is not as complex as we've made it, afaict09:27
KinnisonAt the moment, authors of system morphologies have to be fully conscious of the unexpressed runtime dependencies of everything they have expressed a runtime dependency on09:28
KinnisonWhich is (IMO) a high cognitive load to maintain, especially across a team09:28
paulsher1oodhistorically this kind of change has caused unnecessary pain for users imo09:28
KinnisonIf we've not learned from that and provide a good migration path then we're not doing well at life IMO09:28
petefothI am not convinced that we are all trying to achieve the same things: so far in emails and irc I have seen all of the things  listed below as possible aims for the proposed changes. Before we can decide on whether Ricard’s RFC and.or his patches acieve what we want, we need to be clearer abotu what we do want, and whether we want the same things09:34
petefoth* Simplifying the model'09:35
petefoth* Removing 'system' as a morphology kind09:35
petefoth* to see strata gone entirely09:35
petefoth* split the strata up to be smaller09:35
petefoth* fewer superfluous dependencies, meaning fewer rebuilds after things are changed.09:35
petefoth* make the run-depends shorter while still handling split strata09:35
Kinnisonpetefoth: that's a good summary, and perhaps worth tidying up and posting to the RFC thread and/or the patch cover-note09:36
* petefoth goes to do that very thing09:36
*** ssam2 [] has joined #baserock09:42
Mode #baserock +v ssam2 by ChanServ09:42
* persia has not yet entirely understood either the RFC nor the patch series, but ferverently hopes that this is one more stage towards cleaning semantics for run-time and build-time dependencies, and allowing arbitrary hierarchies09:43
*** jonathanmaw [] has quit [Ping timeout: 255 seconds]10:18
richard_mawthe migration path for runtime dependencies is to list everything in the system morphology until you've finished adding runtime depends to all your strata10:23
*** franred [] has joined #baserock10:23
persiaThat isn't an insane migration path, and it is a huge improvement over the current model where one's build dependencies often seem to end up installed on systems because stratum implementors do not always maintain a system-level view10:28
*** tiagogomes_ [~tiagogome@] has joined #baserock10:29
*** rdale [] has quit [Read error: Connection reset by peer]10:29
*** tiagogomes_ [~tiagogome@] has quit []10:29
*** rdale [] has joined #baserock10:30
* straycat thinks it would be clearer if runtime dependency were done purely at system artifact construction but can appreciate not wanting to define build-time-runtime-depends as build-depends10:36
richard_mawlet's consider python modules10:38
richard_mawthey can use other modules, but these modules don't need to be available at build time10:38
richard_mawsince the loading is done at run time10:38
richard_mawso you could handily build every python module in parallel10:38
richard_mawhowever, if you _do_ actually need one of those modules at build time, then you need to include all of its runtime dependencies10:39
richard_mawsince otherwise you wouldn't be able to use it in your build10:39
richard_mawit's sub-optimal to refer to a python module's runtime dependencies as build-depends, since it reduces the amount of work you can do in parallel10:40
*** jonathanmaw [] has joined #baserock10:44
ssam2'transitive dependencies' is a useful term here10:50
ssam2meaning dependencies that aren't immediate dependencies of the object under consideration, but that are pulled in by one of its dependencies10:51
richard_mawI avoided that term, since people without a CS background are more likely to understand "recursive dependencies"10:51
robtaylorssam2: aren't dependencies transitive by defintion?10:52
ssam2that doesn't fit with the understanding of the term I picked up a couple of weeks ago10:52
ssam2I could be totally wrong, though10:52
richard_mawyes, but sometimes you just want to describe the first level of dependencies, and sometimes you want to describe all of them10:52
robtaylorssam2: you usually use 'transitive' as a decription of the properties of an operation10:53
richard_mawdependencies could either mean direct dependencies or transitive dependencies10:53
Kinnisondependency is a transitive operation, transitive dependencies are indirect dependencies brought in by that transitive property10:53
robtaylorso the 'dependancy' operation is by definition transitive10:53
KinnisonBut given we're discussing this, it's clearly not an immediately comprehensible term :-(10:54
robtaylorKinnison: yup10:54
straycat*nod* a depends on b, b depends on c, therefore a depends on c, transitively. not sure the term adds anything really10:54
robtaylorrecursive would be probably more correct tbh10:54
KinnisonBut a lot of non CS people are scared by 'recursive' as a concept :-(10:54
* Kinnison thinks they should all learn lisp and then stop being scared10:54
richard_mawthey'll be terrified by transitive then10:54
robtaylor'transitive closure of the dependancy operation' would be the corretc term  ;)10:54
Kinnisonrobtaylor: :-)10:55
ssam2i'll go back to 'dependencies that you don't depend on directly but that are dependencies of things you do depend on' :(10:55
robtaylorindirect dependencies10:55
petefothrobtaylor: +1 . Pretty clear, and not scary at all :)10:56
ssam2sweet! i'll try that one10:56
* robtaylor hopes the mail he just sent makes sense and isn't disruptive10:57
straycatrichard_maw, i agree it's sub-optimal but it does seem simpler10:58
richard_mawstraycat: we currently have run-depends in a way that is hard to work with, since it requires the system definer to track down the dependencies themself. Do you propose to indirectly include a stratum's build dependencies at system build time instead?11:00
robtaylorone historical problem with runtime dependencies is what you need can changfe based on context11:01
richard_mawwhich is where the conditionalisation comes in11:01
robtaylorso in some cases, I may want to (say) runtime depend on polkit, and others not11:01
richard_mawI expect we'll allow runtime dependencies to change based on the tag11:01
robtaylorso back at the start the general idea was that you were expressin integration rather than packaging a component11:02
richard_mawyep, and from my understanding we still are11:02
straycatrichard_maw, No11:03
robtaylorwell, you could consider 'runtime depends' as default integrations of a compoent11:03
richard_mawunconditional runtime depends would be the default integrations11:04
richard_mawbut there will be unarguable runtime dependencies based on how you've built your chunk11:04
straycat"We can either include runtime dependencies of artifacts we build-depend11:05
straycaton, or leave runtime dependencies to being purely for system artifact11:05
straycatconstruction time."11:05
richard_mawstraycat: the implementation includes it at build time11:05
richard_mawI had a further think, and I think it makes more sense this way11:05
straycatI was expressing a preference for the latter is all :)11:05
robtaylorrichard_maw: im not sure you're underdtanding 'default integrations' the way i mean it there11:06
robtaylorrichard_maw: it was plural deliberately, as in there may be a number of standard ways to integrate a component11:07
richard_mawstraycat: it means we don't have to special case the system so much, which means we're closer to merging the concepts of systems and strata11:07
robtaylorbut maybe the important thing here is to represent *unavoidable runtime dependencies*11:07
robtaylorand a lot of the time you can calulate those11:08
robtaylor(python modules from the imports, c libraries from ldd, etc)11:08
robtaylorindeed, debian already has a lot of stuff for doing that11:08
straycatrichard_maw, Okay11:09
robtaylorthen exactly how you put stuff together in a final system would be by composition (system/strata definitions as are now)11:09
robtaylorthat would abvoid the general messyness you see in debian Depends: where you end up encoding system integration decisions in Depends: lines in packages..)11:11
robtaylor(and yeah, conditionalising would still be needed)11:12
ssam2yeah, the distinction between required and optional runtime dependencies seems a useful one11:12
ssam2especially given it's quite common for packages to change their behaviour based on what dependencies are available at configure-time11:13
robtaylorI worry that expressing optional runtime dependencies in any meaningful way would just make things less clear11:13
richard_mawssam2: that's an optional build-depend11:14
robtaylorDocumentation is probably best11:14
ssam2richard_maw: well, it's both11:14
richard_mawno, it becomes a mandatory run-depend once you optionally build-depend on it11:14
ssam2it may not necessarily be a build-depend, either11:14
robtaylors /meaningful way /meaninfully structured/11:14
ssam2(./configure may detect something and enable code that uses it without actually needing to link to it)11:15
robtaylorssam2: very true11:15
richard_mawgood point, well made11:15
ssam2I guess that's rare actually, it could just be detected at runtime. But the point is that it's tied in with enabling/disabling features at integration time11:15
robtaylorssam2: its not that rare in system components11:16
robtayloryeah, it ends up its really hard to represent all this11:16
robtaylor(and represent it acurrately)11:16
*** rdale_ [] has joined #baserock11:17
robtaylorand at the end of the day, you'll find out you did something wrong when you build your system and test it11:17
robtaylorbut, having said that, having useful information in components so they're more easiely reuable isn't a bad thing11:18
robtaylorbut maybe that's bettwe done outside of a component (that was the original idea with strata)11:18
robtaylor(in other words, runtime depends could always be expressed as a 'metapackage' type thing)11:20
*** rdale [] has quit [Ping timeout: 250 seconds]11:20
robtayloroh, there's an idea11:20
robtaylormaybe we just allow multiple component defintions in a file11:20
*** locallycompact [] has joined #baserock11:21
straycathello locallycompact11:21
robtaylorand your runtime depends is just a composed component that's defined along with the root component11:21
* robtaylor is totally shooting from the hip here11:21
richard_mawrobtaylor: you're bringing in a lot of interesting ideas, but I can't keep up with talking about them on IRC, so e-mails would be more useful to me11:21
richard_mawthough about your last point, I was just describing that idea to ssam211:22
robtaylorrichard_maw: hard to discuss random ideas in email :(11:22
robtaylorpeople tend to take it the wrong way, i find...11:22
richard_mawrobtaylor: hard to respond to them by IRC when there's so many so quickly. There's a lot of interesting points that need to be given more thought.11:23
richard_mawwhich is not to suggest that you haven't thought deeply about the ideas, just that I can't when there's so many so quickly11:23
ssam2I find that chatting in IRC takes almost 100% of my attention, which distracts me from the work I'm meant to be doing11:24
robtaylori understand. I haven't thought deeplyt, that's why i can't write a mail yet ;)11:24
robtayloryou all don't need to respond right now, thats the beuty of IRC...11:25
* robtaylor will try and compose somthing cohesive11:25
robtaylorbut feel free to carry on discussing with me here if you find some time11:25
richard_mawrobtaylor: no, that's the beauty of E-Mail. If we don't respond soon it'll be lost in the back-scroll.11:26
richard_mawbut we're running into holy war territory here11:26
richard_mawsince people have different opinions on how people should use the tools11:27
richard_mawbased on their own experiences11:27
petefothWhere are we and Datacentered in terms of them being ready to host Baserock project's public-facing infra-structure?11:30
pedroalvarezpetefoth: they are getting there11:39
ssam2I'm going to look at StoryBoard on Friday, if that's what you're interested in :)11:41
pedroalvarezpetefoth: looks like they will be ready next week11:41
ssam2I got a prototype OpenID provider working two weeks ago last friday11:41
pedroalvarezoh! cool!11:41
ssam2I hope to have a prototype storyboard that uses it by the end of the week11:41
ssam2once that's done, we'll need to come up with a way of doing backups, and then it should be usable11:42
pedroalvarezdid you test the openid with the gerrit instance?11:42
ssam2no, I didn't think of that11:42
ssam2I tested it with wiki.baserock.org11:42
ssam2will try it tomorrow11:42
pedroalvarezssam2: ta! although testing it with w.b.o is more than enough to me11:43
ssam2if it doesn't work with Gerrit it's kind of useless though :)11:43
pedroalvarezhm.. rawdisk.write succeeds when deploying a fake system with an /etc folder11:51
pedroalvarezI gess I have to check that what I'm installing is actually a system11:52
franredssam2, you may need to configure Gerrit to accept your openID provider as a trustful provider11:52
pedroalvarezfranred: let's leave that for tomorrow as he said11:52
franredwhich it wasn't obvious when I was working on it11:53
franredpedroalvarez, ok11:53
pedroalvarezso I wonder, how can I check that a folder contains a baserock rootfs?11:55
radiofreeit has a /baserock folder?11:55
*** rdale [] has joined #baserock11:57
pedroalvarezradiofree: I guess that would be enough11:59
*** rdale_ [] has quit [Ping timeout: 256 seconds]12:00
robtaylorrichard_maw: i simply choose times when i go on irc and respond to highlights...12:00
cosmpaulsher1ood: I think so, since there is a 4 GB version I imagine that all boards are the same and there are enough DDR footprints and address pins connected12:01
cosmbut someone should take it apart and check12:01
paulsher1oodwe have a spare one... i just need a volunteer with a screwdriver and relevant knowledge :)12:01
* pedroalvarez drops his screwdriver12:02
straycatwoah, where did you get that screwdriver?12:02
paulsher1oodknowledge to look at the board layout, identify what can be done to add memory12:03
cosmyou also need to be able to load a new BCT and new kernel image with LPAE support, if not already available12:03
paulsher1oodalternatively, a camera to post a pic on the internet and we ask cosm :)12:03
paulsher1oodcosm: i reckon radiofree may know how to do that :)12:03
*** rdale_ [] has joined #baserock12:06
radiofreepaulsher1ood: i have br working in a chroot on the chromebook12:06
radiofreeyou can use ctrl+atl-f1/f2 to switch between fullscreen baserock and chromeos12:07
paulsher1oodthat's cool. any thoughts on how to get it native?12:07
richard_mawwas this with the `crouton` thing?12:07
radiofreeit uses , maybe i should make a proper br target for it?12:07
radiofreepaulsher1ood: yeah we're looking at native as well12:07
paulsher1oodyes a baserock target for crouton would be cool12:07
richard_mawpaulsher1ood: I've done such thinking. There's chrubuntu, which you can crib off.12:07
radiofreehowever, it's actually pretty useful to be able to switch between br and chromeos (e.g to use a webbrowser)12:08
paulsher1oodtrue, radiofree 12:08
richard_mawyeah, but you have to use the chromeos kernel for it12:08
* richard_maw wants to be able to dual boot12:08
radiofreethere's a device tree for this chromebook upstream12:08
rdale_i haven't been able to get a chromebook to boot from a usb stick with cntrl+u at startup12:09
richard_mawI think you can dual-boot by adding a new GPT partition and making it have a higher boot priority.12:09
*** rdale [] has quit [Ping timeout: 245 seconds]12:09
cosmrichard_maw: depending on what feature of ChromeOS you want, I would suggest simply running Chrome(OS) as a application on top of GNU/Linux12:11
*** rdale [] has joined #baserock12:21
radiofreei don't really see the benefit in booting this natively (no network, browser, work tools etc)12:23
radiofreeall the networking etc.. taken care of by booting it like this12:23
radiofreei'll try building a branch and upgrading a jetson over ssh to see if it all works12:23
radiofreeit already fulfils the "baserock laptop you can use to develop arm images with" job running in a chroot12:24
*** rdale_ [] has quit [Read error: Connection reset by peer]12:24
radiofreerunning in a chroot like this also has the added advantage of being able to view cat pictures while you build12:26
rdaleyou didn't need 'schroot' to build?12:27
mauricemoss_radiofree: fullack, cat pictures increase the happiness :)12:27
radiofreerdale: i'm going to test building something when i get a /src directory12:29
rdaleah i see - you copied an existing image into the chroot?12:29
*** aananth [~caananth@] has joined #baserock12:41
locallycompactg.b.o 500 internal server error?
*** aananth [~caananth@] has quit [Quit: Leaving]12:48
cosmradiofree: I guess I've missed some context; I was thinking of using the chromeos or L4T downstream kernels with a standard standard GNU/Linux userspace12:48
pedroalvarezlocallycompact: thanks for the warning12:49
pedroalvarezthis is on the journal of g.b.o:
radiofreecosm: ah, we're current using a chroot of baserock on the chromeos that came with the acer chromebook12:50
radiofreeclocked lower than a jetson board12:51
radiofreecat scaling_max_freq12:51
richard_mawpedroalvarez: I usually see that when there's someone's been trying to get a tarball of a large checkout using cgit12:53
rdaleyou can build custom chrome os images, and use portage to add any extra packages you want like schroot. but i haven't managed to get an image to boot from a usb stick yet and haven't managed to get started with that yet12:53
richard_mawand Kinnison can tell you how doomful it is to even get started with building ChromeOS12:53
rdalei managed to build an image ok - although it didn't work on my encrypted home partition. the image would run in kvm, but not from a usb stick on the chromebook12:54
radiofreerichard_maw: i was downloading the gcc tarball12:54
radiofreevia morph though12:54
radiofree(gcc git tarball)12:54
radiofreewhich seems to have hung on git checkout hsa12:55
richard_mawhm, that's particularly poor, since AIUI we're using something built-in to lighttpd to serve that12:56
radiofreei'm not saying that was the cause, by my timestamps correspond with the log pedroalvarez posted12:56
pedroalvarezthis log h appens everytime I try to load g.b.o in a browser12:57
radiofreeah it's extracting12:58
radiofreei'm used to this happening on an ssd.. i suppose it takes a while to extract gcc onto an sd card12:58
pedroalvarezright, g.b.o is back12:59
radiofreecan we lorry please13:02
locallycompactBuilding trove from definitions master reports that ERROR: Ref 9fe25bf02dceec04f0ffd6a05cc47146ceab9904 is an invalid reference for repo git://
locallycompactshould be ede3f337e9769b0e6756d4b9cc37d33aa62b82ba13:29
richard_mawBah! I forgot to push the update to lorry when I updated definitions.git, but I don't have access to the machine I did the merge on currently.13:34
richard_mawlocallycompact: we can either roll back, or wait until this evening when I can push that commit13:45
locallycompactrichard_maw: as you like, I'll just continue on with $latest_master13:46
* richard_maw will have to see where the git signed push stuff has gotten to13:48
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]14:07
*** abdul [~abdul@] has joined #baserock14:19
abdulssam2, hi sam. i am getting build error for the package "node" i have attached error log in 146 packages built successfully out of 158 for wandboard in our hardware.14:21
richard_maw../deps/v8/src/ internal compiler error: Segmentation fault                    14:21
richard_mawhm, we've previously seen this happen for compiler bugs, or running out of memory14:22
pedroalvareznode doesn't build in ppc64 and  neither in armv7b14:23
pedroalvarezI'm now checking in armv7lhf14:24
paulsher1oodpedroalvarez: it builds on jetson, i did this last night14:25
pedroalvarezgood to know14:29
*** cosm [] has quit [Quit: Leaving]14:31
paulsher1oodactually, maybe i didn't, pedroalvarez. let me check14:31
pedroalvarezpaulsher1ood: I'll double check it anyway14:34
*** CTtpollard [] has joined #baserock14:36
ssam2abdul: given that Node.js uses V8, which is some pretty heavy C++, it's probably due to the compiler running out of memory and crashing14:36
CTtpollardHI, quick guestion as just jumping onto baserock after not using it for a while, I've im trying to morphcheckout, can I specify my own branchname at the end of the command14:36
CTtpollardI've got directories called gerrit & tpollard so I know I have in the past14:37
ssam2abdul: unless you're planning on writing node.js apps, I suggest you just remove the 'node' stratum from the system you are building14:37
paulsher1oodCTtpollard: morph branch14:43
paulsher1oodmorph branch baserock:baserock/definitions yourbranchname [optional-ref-to-branch-from]14:44
CTtpollardis checkout on the wiki outdated then?14:44
paulsher1oodi would prefer to see morph checkout deprecated, since it has known bugs14:45
paulsher1oodwhich are unlikely to be fixed14:45
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock14:45
paulsher1oodbut others may disagree14:45
CTtpollardok ty paulsher1ood14:46
franredCTtpollard, we morph checkout for checkout branches/tags which already exist14:46
franreds/we/we use/14:46
paulsher1oodfor that case morph checkout may be mostly fine. but if the branch/tag clashes with an upstream's use of the same thing problems occur. the best example is 'master'14:48
paulsher1oodpedroalvarez: yes, node does definitely build on jetson14:50
pedroalvarezpaulsher1ood: good14:52
pedroalvarezthen: architectures affected by node: ppc64, armv7b14:53
pedroalvarezand here is the error log in ppc64:
ssam2that raises an interesting question, really14:56
ssam2actually, since Node is in its own stratum, we can just remove Node from the devel systems where it doesn't build, for now14:56
pedroalvarezpaulsher1ood: no, missing libraries14:57
paulsher1oodhow can libraries be missing on some architectures?14:58
ssam2note 'target_arch': 'ia32',' appears in the configuration14:58
ssam2of the ppc64 build log14:58
pedroalvarezssam2: good catch14:58
ssam2I doubt the Node.js developers have given the slightest thought to whether Node builds on PPC64 or big-endian ARM14:58
paulsher1oodfair point14:58
ssam2pedroavarez: it was Richard Maw who spotted it ;)14:59
SotKSo I've been looking at improving Mason using Zuul to cause builds/tests/things to happen. Zuul creates jobs based on commits to some Gerrit and its configuration and passes them to its job server. There is a job runner called turbo-hipster which allows the creation of plugins to run arbitrary jobs which works with Zuul.15:15
SotKHowever, I've hit a problem: Mason uses (and should continue to use) distbuild for its builds - which works against a Trove, but Zuul gives turbo-hipster a SHA which it creates on the Gerrit it is triggered by. This SHA will never be on the Trove as it stands at the moment.15:17
CTtpollardis that using a gearman server to allocate the jobs to turbo-hipster workers Sotk?15:17
SotKCTtpollard: yep15:17
SotKI understand the plan is for the git server in Trove to be configurable, so in future Gerrit could slot in and all will be well.15:18
SotKHowever, that makes me wonder if there is a plan for CI/CD in the general case (i.e. some undefined git server)15:19
ssam2why are the commits in Gerrit never in a Trove?15:20
ssam2could the trove not mirror the Gerrit, for example?15:20
ssam2i'm probably missing something about how Gerrit works here15:20
SotKif the Trove was mirroring from Gerrit, and could be persuaded to pull the latest definitions between Zuul creating its commit and turbo-hipster trying to start a build at that commit it would work15:22
SotKsimilarly if Gerrit was the git server in the Trove then there wouldn't be a problem15:23
ssam2you can tell a Trove to promote a lorry job to the top of its queue15:24
ssam2I don't think there's a way to tell Trove to notify you once it's finished, though15:25
ssam2also, this sounds quite fragile and really only suitable for a prototype15:25
ssam2could the Gerrit mirror the Trove?15:25
ssam2that way Trove remains the 'canonical' git server15:26
ssam2on the downside, we have another code path doing mirroring then15:26
ssam2was part of your question about if we have a plan for doing CI independently of Gerrit ?15:26
ssam2if so, I think if Zuul and Gearman require Gerrit, we'll have to require Gerrit for CI, for now15:27
ssam2does Zuul/Gearman have to be triggered by Gerrit? can it not just be a git post-commit hook on the Trove?15:28
radiofreei've sent a patch to lorry linux-firmware15:28
ssam2I see, Zuul has pluggable 'triggers'15:28
petefothLooking at write and config extensions (.write and .configure files), I note we also have .check files (e.g. nfsboot.check) These seem to perform '''Preparatory checks for Morph ‘xxxx’ write extension’’’. Should these have their own entry in the Glossary? If so is ‘check extension’ the best pharse to use?15:28
radiofreeany objections to that? (assuming the patch checks out)15:29
ssam2SotK: so, we could add a trigger to Zuul that fired off some kind of git post- or pre-commit hook15:29
richard_mawpetefoth: the checks are per write extension, so it may be better to mention them there15:29
SotKssam2: I believe we could do that, yes15:29
ssam2radiofree: don't know what it is exactly, but I doubt I object15:29
petefothrichard_maw: thanks15:30
pedroalvarezradiofree: is that chunk going to be needed in every bsp?15:30
radiofreepedroalvarez: i wouldn't have thought so, i only need to it to send a patch to add nvidia firmware, which i'll use in bsp-jetson15:30
radiofreeno more bsp-jetson-devel and bsp-jetson-genivi yay!15:31
radiofreebut i suppose if we're moving to "baserock on hardware" it might be useful for others15:31
jjardonradiofree: nice15:58
jjardonwhat linux kernel version?15:58
pedroalvarez3.18 15:59
radiofreefranred: ssam2: can you merge the lorry? I don't have access16:05
franredradiofree, yes, I can do it16:06
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]16:15
franredradiofree, merged16:16
franredssam2, thank you for the help :) with .mbox files git am also works :)16:17
pdarI'd like to update the version of ceph in my trove, if someone could point me to some documentation on updating the contents of a trove I'd be most grateful16:32
*** Krin [] has joined #baserock16:35
locallycompactpdar: That should happen automatically if your upstream trove is, how did you deploy your trove?16:37
radiofreehmmm "removing staging area for..." for 20 minutes so far16:38
franredpdar, do you have a local trove or you are talking about the baserock-clone?16:39
radiofreei think the sd card on this is quite slow16:40
radiofreebut the build worked!16:40
pdarlocallycompact: franred: I was using g.b.o. Now I'm using baserock-clone16:40
locallycompactWhat is baserock-clone?16:40
pdarlocallycompact: a clone of g.b.o used for testing I think16:41
franredpdar, are you said that ceph in g.b.o is pointing to a wrong repo? is ceph a tarball import repository?16:42
pedroalvareznot really a clone, but yes, for testing16:42
locallycompactceph in g.b.o seems to be several versions behind16:42
pdarlocallycompact: it is yes16:43
pdarfranred: I dont know, how would I find out?16:43
pedroalvarezhere is the ceph.lorry:
pedroalvarezseems to be pointing to the right repo16:44
*** cosm [] has joined #baserock16:46
pedroalvarezhere is the error:
*** Krin [] has quit [Remote host closed the connection]16:48
pdarpedroalvarez: aha, I guess that is why it stopped updating then.16:49
*** Krin [] has joined #baserock16:50
pedroalvarezpdar: yup, we are lokking into it16:50
pedroalvarezlooking even16:50
franredin github there is a cls-lua branch but not a cis-lua branch16:52
franredpdar, pedroalvarez ^^16:53
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 260 seconds]16:53
pedroalvarezhm.. maybe a typo from Kinnison?16:54
pedroalvareznot sure if we should fix that "typo" or change the refspecs16:54
richard_mawforce push16:55
richard_mawforce push all the things16:55
pedroalvarezhe did that change a year ago, and this repo hasn't worked for a year16:56
pedroalvarezso yeah, I think it's a typo16:56
*** Blacksnow [] has joined #baserock16:56
*** Krin [] has quit [Quit: Leaving]16:56
franredso add a + before: refs/heads/master:refs/heads/master -> "+refs/heads/master:refs/heads/master"16:56
franredto force push master16:57
*** Blacksnow [] has quit [Client Quit]16:57
*** Krin [] has joined #baserock16:57
richard_mawnah, do `["+refs/heads/*:refs/heads/*", "+refs/tags/*:refs/tags/*"]`16:57
pedroalvarezfranred: pushing master is not failing16:57
*** jonathanmaw [] has quit [Quit: Leaving]16:59
pedroalvarezfranred: are you going to fix this then?17:00
franredpedroalvarez, pdar, fixed in g.b.o17:03
radiofreeridgerunner: can you paste the output of your current screen to fpaste or something?17:06
violeta_ is now known as violeta17:06
franredradiofree, ridgerunner,
*** sambishop [] has joined #baserock17:11
pedroalvarezpdar: fixed! locallycompact thanks for spotting this!17:13
pdarThanks franred!17:13
pdarand pedroalvarez and locallycompact 17:14
*** jjardon84 [] has quit [Ping timeout: 260 seconds]17:15
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Quit: Bye]17:28
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock17:28
*** rjek [~rjek@gateway/shell/pepperfish/x-rjmkpdzfhqiuguqz] has quit [Quit: Reconnecting]17:32
*** rjek [~rjek@gateway/shell/pepperfish/x-yipgojttzsfgxzpj] has joined #baserock17:32
*** jjardon84 [] has joined #baserock17:32
*** rdale [] has quit [Ping timeout: 245 seconds]17:34
pedroalvarezbtw, node failing in armv7b:
pedroalvarezI guess a max-job: 1 would fix it17:44
robtaylorpedroalvarez: ../deps/v8/src/globals.h:90:2: error: #error Host architecture was not detected as supported by v817:45
robtaylor../deps/v8/src/globals.h:120:2: error: #error Target architecture arm is only supported on arm and ia32 host17:45
robtaylorpedroalvarez: i'm guessing however its' detecting the arch is having problems17:45
robtayloroh, hang on, is armv7b big endian?17:46
robtaylorpedroalvarez: probably wont work without adding support to v8 for big endian then17:46
*** mauricemoss_ [] has quit [Quit: Leaving]17:48
rjekOh god, that past server17:48
rjekHow do I enable wrapping?17:48
pedroalvarezrjek: ctrl + shift + r17:49
rjekpedroalvarez: That's a raw view!17:49
* rjek applies eye bleach17:49
pedroalvarezrjek: and wrapped!17:49
pedroalvarezrobtaylor: very useful info, thanks!17:50
*** wdutch [] has quit [Quit: Quit]17:50
pedroalvarezI thought there were less differences between compiling something in little endian and compiling the same in big endian17:51
paulsher1ooddo we have v8 in baserock?17:52
*** CTtpollard [] has quit [Quit: Ex-Chat]17:53
pedroalvarezi'm still not sure about what is it :)17:55
pedroalvarezs/is it/it is/17:55
radiofreeit's a javascript engine that we probably use for node?17:56
robtaylorpedroalvarez: when that component has code generation in, almost certainly not..17:56
robtaylor same would go for, say, orc or qemu or other JITs17:57
*** genii [~quassel@ubuntu/member/genii] has joined #baserock17:57
Zaranodejs can work on baserock so I'm guessing we do have v8 in baserock, but I might have misunderstood something17:57
*** mariaderidder [] has quit [Quit: Ex-Chat]17:58
radiofreeyes, but it won't compile bigendian. However i can't imagine many people wanting to use bigendian arm systems will want javascript? 17:58
jmacsGoogle V8, it's the javascript engine in Chrome/Chromium17:58
robtaylorZara: the problem is that anything that generates code for the CPU needs to knwo how to generate code for that CPU17:58
robtaylorZara: v8 is a JIT, and hence gnerates code17:59
*** Krin [] has quit [Remote host closed the connection]17:59
robtaylorZara: it doesnt know how to generate code for ARM big enian or powerpc17:59
robtaylorZara: so not a baserock thing, but a 'does it support this processor' thing17:59
Zararobtaylor: ah, ok, that makes sense18:01
*** rdale [] has joined #baserock18:05
* paulsher1ood can't see V8 on, wonders how it's snuck into baserock systems18:17
ssam2there's a copy of V8 inside the Node.js source tree18:19
* paulsher1ood feels deja vu... maybe he asked this before, and forgot the answer18:22
*** ssam2 [] has quit [Remote host closed the connection]18:26
*** wdutch [95aadb3d@gateway/web/freenode/ip.] has joined #baserock18:27
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:37
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:37
*** CTtpollard [95aadb3e@gateway/web/freenode/ip.] has joined #baserock18:40
*** CTtpollard [95aadb3e@gateway/web/freenode/ip.] has quit [Quit: Page closed]20:22
*** wdutch [95aadb3d@gateway/web/freenode/ip.] has quit [Quit: Page closed]20:30
*** cosm [] has quit [Ping timeout: 256 seconds]21:02
*** cosm [] has joined #baserock21:37
*** cosm [] has quit [Client Quit]21:37
*** cosm [] has joined #baserock21:37
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]22:06
radiofreejjardon: hi, checked through your weston branch, will reply tomorrow22:38
radiofreelooks good though22:38
radiofreeone comment about your weston branch though, what are those two commits on top for?22:41
radiofreeweston 1.6.0 seems to compile fine on my (admittedly older) baserock system22:41

Generated by 2.15.3 by Marius Gedminas - find it at!