| *** rdale [~quassel@55.Red-88-17-108.dynamicIP.rima-tde.net] has quit [Ping timeout: 256 seconds] | 01:54 | |
| *** rdale [~quassel@252.Red-88-13-188.dynamicIP.rima-tde.net] has joined #baserock | 01:56 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 04:47 | |
| *** rdale_ [~quassel@183.Red-88-13-190.dynamicIP.rima-tde.net] has joined #baserock | 06:32 | |
| *** rdale [~quassel@252.Red-88-13-188.dynamicIP.rima-tde.net] has quit [Ping timeout: 255 seconds] | 06:36 | |
| *** rdale [~quassel@251.Red-79-147-216.dynamicIP.rima-tde.net] has joined #baserock | 06:47 | |
| *** rdale_ [~quassel@183.Red-88-13-190.dynamicIP.rima-tde.net] has quit [Ping timeout: 256 seconds] | 06:50 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:21 | |
| dutch is now known as wdutch | 08:27 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit ["Ex-Chat"] | 08:29 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 08:32 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:57 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:05 | |
| paulsher1ood | cool! | 09:17 |
|---|---|---|
| paulsher1ood | robtaylor: ^^ | 09:17 |
| paulsher1ood | i 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 |
| paulsher1ood | cosm: could we do the same to the acer cb5, do you know? | 09:19 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:20 | |
| Kinnison | paulsher1ood: I'm strongly in favour of runtime-depends because I see it as a step towards simplifying the model | 09:20 |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:20 | |
| dutch is now known as wdutch | 09:21 | |
| paulsher1ood | i 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 ways | 09:23 |
| * Kinnison utterly failed to understand your proposed content model, but will admit to being un-caffeinated while reading it | 09:25 | |
| Kinnison | runtime-depends are a step along the way of removing system as a morphology kind | 09:25 |
| Kinnison | which I see as a simplification of the model | 09:25 |
| paulsher1ood | at the price of adding runtime-depends, which is more complexity | 09:26 |
| Kinnison | I think it'll actually reduce cognitive load over all | 09:26 |
| rjek | The problem sounds complex. | 09:26 |
| Kinnison | However I think Richard Maw will do better at explaining than I will, given it's his idea | 09:26 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 09:27 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:27 | |
| paulsher1ood | the problem is not as complex as we've made it, afaict | 09:27 |
| Kinnison | At the moment, authors of system morphologies have to be fully conscious of the unexpressed runtime dependencies of everything they have expressed a runtime dependency on | 09:28 |
| Kinnison | Which is (IMO) a high cognitive load to maintain, especially across a team | 09:28 |
| paulsher1ood | historically this kind of change has caused unnecessary pain for users imo | 09:28 |
| Kinnison | If we've not learned from that and provide a good migration path then we're not doing well at life IMO | 09:28 |
| petefoth | I 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 things | 09:34 |
| petefoth | * Simplifying the model' | 09:35 |
| petefoth | * Removing 'system' as a morphology kind | 09:35 |
| petefoth | * to see strata gone entirely | 09:35 |
| petefoth | * split the strata up to be smaller | 09:35 |
| petefoth | * fewer superfluous dependencies, meaning fewer rebuilds after things are changed. | 09:35 |
| petefoth | * make the run-depends shorter while still handling split strata | 09:35 |
| Kinnison | petefoth: that's a good summary, and perhaps worth tidying up and posting to the RFC thread and/or the patch cover-note | 09:36 |
| * petefoth goes to do that very thing | 09:36 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:42 | |
| Mode #baserock +v ssam2 by ChanServ | 09: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 hierarchies | 09:43 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 10:18 | |
| richard_maw | the migration path for runtime dependencies is to list everything in the system morphology until you've finished adding runtime depends to all your strata | 10:23 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:23 | |
| persia | That 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 view | 10:28 |
| *** tiagogomes_ [~tiagogome@213.15.255.100] has joined #baserock | 10:29 | |
| *** rdale [~quassel@251.Red-79-147-216.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 10:29 | |
| *** tiagogomes_ [~tiagogome@213.15.255.100] has quit [] | 10:29 | |
| *** rdale [~quassel@211.Red-2-136-156.dynamicIP.rima-tde.net] has joined #baserock | 10: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-depends | 10:36 | |
| richard_maw | let's consider python modules | 10:38 |
| richard_maw | they can use other modules, but these modules don't need to be available at build time | 10:38 |
| richard_maw | since the loading is done at run time | 10:38 |
| richard_maw | so you could handily build every python module in parallel | 10:38 |
| richard_maw | however, if you _do_ actually need one of those modules at build time, then you need to include all of its runtime dependencies | 10:39 |
| richard_maw | since otherwise you wouldn't be able to use it in your build | 10:39 |
| richard_maw | it'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 parallel | 10:40 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:44 | |
| ssam2 | 'transitive dependencies' is a useful term here | 10:50 |
| ssam2 | meaning dependencies that aren't immediate dependencies of the object under consideration, but that are pulled in by one of its dependencies | 10:51 |
| richard_maw | I avoided that term, since people without a CS background are more likely to understand "recursive dependencies" | 10:51 |
| robtaylor | ssam2: aren't dependencies transitive by defintion? | 10:52 |
| ssam2 | that doesn't fit with the understanding of the term I picked up a couple of weeks ago | 10:52 |
| ssam2 | I could be totally wrong, though | 10:52 |
| richard_maw | yes, but sometimes you just want to describe the first level of dependencies, and sometimes you want to describe all of them | 10:52 |
| robtaylor | ssam2: you usually use 'transitive' as a decription of the properties of an operation | 10:53 |
| richard_maw | dependencies could either mean direct dependencies or transitive dependencies | 10:53 |
| Kinnison | dependency is a transitive operation, transitive dependencies are indirect dependencies brought in by that transitive property | 10:53 |
| robtaylor | so the 'dependancy' operation is by definition transitive | 10:53 |
| Kinnison | AIUI | 10:53 |
| Kinnison | But given we're discussing this, it's clearly not an immediately comprehensible term :-( | 10:54 |
| ssam2 | indeed | 10:54 |
| robtaylor | Kinnison: yup | 10:54 |
| straycat | *nod* a depends on b, b depends on c, therefore a depends on c, transitively. not sure the term adds anything really | 10:54 |
| robtaylor | recursive would be probably more correct tbh | 10:54 |
| Kinnison | But 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 scared | 10:54 | |
| richard_maw | they'll be terrified by transitive then | 10:54 |
| robtaylor | 'transitive closure of the dependancy operation' would be the corretc term ;) | 10:54 |
| Kinnison | robtaylor: :-) | 10:55 |
| ssam2 | i'll go back to 'dependencies that you don't depend on directly but that are dependencies of things you do depend on' :( | 10:55 |
| robtaylor | indirect dependencies | 10:55 |
| petefoth | robtaylor: +1 . Pretty clear, and not scary at all :) | 10:56 |
| robtaylor | :D | 10:56 |
| ssam2 | sweet! i'll try that one | 10:56 |
| * robtaylor hopes the mail he just sent makes sense and isn't disruptive | 10:57 | |
| straycat | richard_maw, i agree it's sub-optimal but it does seem simpler | 10:58 |
| richard_maw | straycat: 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 |
| robtaylor | one historical problem with runtime dependencies is what you need can changfe based on context | 11:01 |
| richard_maw | which is where the conditionalisation comes in | 11:01 |
| robtaylor | so in some cases, I may want to (say) runtime depend on polkit, and others not | 11:01 |
| richard_maw | I expect we'll allow runtime dependencies to change based on the tag | 11:01 |
| robtaylor | hmm | 11:01 |
| robtaylor | so back at the start the general idea was that you were expressin integration rather than packaging a component | 11:02 |
| richard_maw | yep, and from my understanding we still are | 11:02 |
| straycat | richard_maw, No | 11:03 |
| robtaylor | well, you could consider 'runtime depends' as default integrations of a compoent | 11:03 |
| robtaylor | (maybe..) | 11:04 |
| richard_maw | unconditional runtime depends would be the default integrations | 11:04 |
| richard_maw | but there will be unarguable runtime dependencies based on how you've built your chunk | 11:04 |
| straycat | "We can either include runtime dependencies of artifacts we build-depend | 11:05 |
| straycat | on, or leave runtime dependencies to being purely for system artifact | 11:05 |
| straycat | construction time." | 11:05 |
| richard_maw | straycat: the implementation includes it at build time | 11:05 |
| richard_maw | I had a further think, and I think it makes more sense this way | 11:05 |
| straycat | I was expressing a preference for the latter is all :) | 11:05 |
| robtaylor | richard_maw: im not sure you're underdtanding 'default integrations' the way i mean it there | 11:06 |
| robtaylor | richard_maw: it was plural deliberately, as in there may be a number of standard ways to integrate a component | 11:07 |
| richard_maw | straycat: 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 strata | 11:07 |
| robtaylor | but maybe the important thing here is to represent *unavoidable runtime dependencies* | 11:07 |
| robtaylor | and a lot of the time you can calulate those | 11:08 |
| robtaylor | (python modules from the imports, c libraries from ldd, etc) | 11:08 |
| robtaylor | indeed, debian already has a lot of stuff for doing that | 11:08 |
| straycat | richard_maw, Okay | 11:09 |
| robtaylor | then exactly how you put stuff together in a final system would be by composition (system/strata definitions as are now) | 11:09 |
| robtaylor | that 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 |
| ssam2 | yeah, the distinction between required and optional runtime dependencies seems a useful one | 11:12 |
| ssam2 | especially given it's quite common for packages to change their behaviour based on what dependencies are available at configure-time | 11:13 |
| robtaylor | I worry that expressing optional runtime dependencies in any meaningful way would just make things less clear | 11:13 |
| richard_maw | ssam2: that's an optional build-depend | 11:14 |
| robtaylor | Documentation is probably best | 11:14 |
| ssam2 | richard_maw: well, it's both | 11:14 |
| richard_maw | no, it becomes a mandatory run-depend once you optionally build-depend on it | 11:14 |
| ssam2 | it may not necessarily be a build-depend, either | 11:14 |
| robtaylor | s /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 |
| robtaylor | ssam2: very true | 11:15 |
| richard_maw | good point, well made | 11:15 |
| ssam2 | I 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 time | 11:15 |
| robtaylor | ssam2: its not that rare in system components | 11:16 |
| ssam2 | right | 11:16 |
| robtaylor | yeah, it ends up its really hard to represent all this | 11:16 |
| robtaylor | (and represent it acurrately) | 11:16 |
| *** rdale_ [~quassel@20.Red-2-137-111.dynamicIP.rima-tde.net] has joined #baserock | 11:17 | |
| robtaylor | and at the end of the day, you'll find out you did something wrong when you build your system and test it | 11:17 |
| robtaylor | but, having said that, having useful information in components so they're more easiely reuable isn't a bad thing | 11:18 |
| robtaylor | but 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 [~quassel@211.Red-2-136-156.dynamicIP.rima-tde.net] has quit [Ping timeout: 250 seconds] | 11:20 | |
| robtaylor | oh, there's an idea | 11:20 |
| robtaylor | maybe we just allow multiple component defintions in a file | 11:20 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:21 | |
| straycat | hello locallycompact | 11:21 |
| robtaylor | and your runtime depends is just a composed component that's defined along with the root component | 11:21 |
| * robtaylor is totally shooting from the hip here | 11:21 | |
| richard_maw | robtaylor: 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 me | 11:21 |
| richard_maw | though about your last point, I was just describing that idea to ssam2 | 11:22 |
| robtaylor | richard_maw: hard to discuss random ideas in email :( | 11:22 |
| robtaylor | people tend to take it the wrong way, i find... | 11:22 |
| richard_maw | robtaylor: 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_maw | which is not to suggest that you haven't thought deeply about the ideas, just that I can't when there's so many so quickly | 11:23 |
| ssam2 | I find that chatting in IRC takes almost 100% of my attention, which distracts me from the work I'm meant to be doing | 11:24 |
| robtaylor | i understand. I haven't thought deeplyt, that's why i can't write a mail yet ;) | 11:24 |
| robtaylor | you all don't need to respond right now, thats the beuty of IRC... | 11:25 |
| * robtaylor will try and compose somthing cohesive | 11:25 | |
| robtaylor | but feel free to carry on discussing with me here if you find some time | 11:25 |
| richard_maw | robtaylor: 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_maw | but we're running into holy war territory here | 11:26 |
| richard_maw | since people have different opinions on how people should use the tools | 11:27 |
| richard_maw | based on their own experiences | 11:27 |
| petefoth | Where are we and Datacentered in terms of them being ready to host Baserock project's public-facing infra-structure? | 11:30 |
| pedroalvarez | petefoth: they are getting there | 11:39 |
| ssam2 | I'm going to look at StoryBoard on Friday, if that's what you're interested in :) | 11:41 |
| pedroalvarez | petefoth: looks like they will be ready next week | 11:41 |
| ssam2 | I got a prototype OpenID provider working two weeks ago last friday | 11:41 |
| pedroalvarez | oh! cool! | 11:41 |
| ssam2 | I hope to have a prototype storyboard that uses it by the end of the week | 11:41 |
| ssam2 | once that's done, we'll need to come up with a way of doing backups, and then it should be usable | 11:42 |
| pedroalvarez | did you test the openid with the gerrit instance? | 11:42 |
| ssam2 | no, I didn't think of that | 11:42 |
| ssam2 | I tested it with wiki.baserock.org | 11:42 |
| ssam2 | will try it tomorrow | 11:42 |
| pedroalvarez | ssam2: ta! although testing it with w.b.o is more than enough to me | 11:43 |
| ssam2 | if it doesn't work with Gerrit it's kind of useless though :) | 11:43 |
| pedroalvarez | hm.. rawdisk.write succeeds when deploying a fake system with an /etc folder | 11:51 |
| pedroalvarez | I gess I have to check that what I'm installing is actually a system | 11:52 |
| franred | ssam2, you may need to configure Gerrit to accept your openID provider as a trustful provider | 11:52 |
| pedroalvarez | franred: let's leave that for tomorrow as he said | 11:52 |
| franred | which it wasn't obvious when I was working on it | 11:53 |
| franred | pedroalvarez, ok | 11:53 |
| pedroalvarez | so I wonder, how can I check that a folder contains a baserock rootfs? | 11:55 |
| radiofree | it has a /baserock folder? | 11:55 |
| *** rdale [~quassel@125.Red-2-138-204.dynamicIP.rima-tde.net] has joined #baserock | 11:57 | |
| pedroalvarez | radiofree: I guess that would be enough | 11:59 |
| *** rdale_ [~quassel@20.Red-2-137-111.dynamicIP.rima-tde.net] has quit [Ping timeout: 256 seconds] | 12:00 | |
| robtaylor | richard_maw: i simply choose times when i go on irc and respond to highlights... | 12:00 |
| cosm | paulsher1ood: 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 connected | 12:01 |
| cosm | but someone should take it apart and check | 12:01 |
| paulsher1ood | we have a spare one... i just need a volunteer with a screwdriver and relevant knowledge :) | 12:01 |
| pedroalvarez | knowledge? | 12:02 |
| * pedroalvarez drops his screwdriver | 12:02 | |
| straycat | woah, where did you get that screwdriver? | 12:02 |
| paulsher1ood | knowledge to look at the board layout, identify what can be done to add memory | 12:03 |
| cosm | you also need to be able to load a new BCT and new kernel image with LPAE support, if not already available | 12:03 |
| paulsher1ood | alternatively, a camera to post a pic on the internet and we ask cosm :) | 12:03 |
| paulsher1ood | cosm: i reckon radiofree may know how to do that :) | 12:03 |
| *** rdale_ [~quassel@50.Red-79-144-56.dynamicIP.rima-tde.net] has joined #baserock | 12:06 | |
| radiofree | paulsher1ood: i have br working in a chroot on the chromebook | 12:06 |
| radiofree | you can use ctrl+atl-f1/f2 to switch between fullscreen baserock and chromeos | 12:07 |
| paulsher1ood | that's cool. any thoughts on how to get it native? | 12:07 |
| richard_maw | was this with the `crouton` thing? | 12:07 |
| radiofree | it uses https://github.com/dnschneid/crouton , maybe i should make a proper br target for it? | 12:07 |
| richard_maw | snap! | 12:07 |
| radiofree | paulsher1ood: yeah we're looking at native as well | 12:07 |
| paulsher1ood | yes a baserock target for crouton would be cool | 12:07 |
| richard_maw | paulsher1ood: I've done such thinking. There's chrubuntu, which you can crib off. | 12:07 |
| radiofree | however, it's actually pretty useful to be able to switch between br and chromeos (e.g to use a webbrowser) | 12:08 |
| paulsher1ood | true, radiofree | 12:08 |
| richard_maw | yeah, but you have to use the chromeos kernel for it | 12:08 |
| * richard_maw wants to be able to dual boot | 12:08 | |
| radiofree | there's a device tree for this chromebook upstream | 12:08 |
| rdale_ | i haven't been able to get a chromebook to boot from a usb stick with cntrl+u at startup | 12:09 |
| richard_maw | I think you can dual-boot by adding a new GPT partition and making it have a higher boot priority. | 12:09 |
| *** rdale [~quassel@125.Red-2-138-204.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds] | 12:09 | |
| cosm | richard_maw: depending on what feature of ChromeOS you want, I would suggest simply running Chrome(OS) as a application on top of GNU/Linux | 12:11 |
| cosm | *features | 12:12 |
| *** rdale [~quassel@170.Red-79-145-104.dynamicIP.rima-tde.net] has joined #baserock | 12:21 | |
| radiofree | i don't really see the benefit in booting this natively (no network, browser, work tools etc) | 12:23 |
| radiofree | all the networking etc.. taken care of by booting it like this | 12:23 |
| radiofree | i'll try building a branch and upgrading a jetson over ssh to see if it all works | 12:23 |
| radiofree | it already fulfils the "baserock laptop you can use to develop arm images with" job running in a chroot | 12:24 |
| *** rdale_ [~quassel@50.Red-79-144-56.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 12:24 | |
| radiofree | running in a chroot like this also has the added advantage of being able to view cat pictures while you build | 12:26 |
| rdale | you didn't need 'schroot' to build? | 12:27 |
| mauricemoss_ | radiofree: fullack, cat pictures increase the happiness :) | 12:27 |
| radiofree | rdale: i'm going to test building something when i get a /src directory | 12:29 |
| rdale | ah i see - you copied an existing image into the chroot? | 12:29 |
| radiofree | yep | 12:31 |
| *** aananth [~caananth@74.112.167.117] has joined #baserock | 12:41 | |
| locallycompact | g.b.o 500 internal server error? http://git.baserock.org/cgi-bin/cgit.cgi | 12:44 |
| *** aananth [~caananth@74.112.167.117] has quit [Quit: Leaving] | 12:48 | |
| cosm | radiofree: I guess I've missed some context; I was thinking of using the chromeos or L4T downstream kernels with a standard standard GNU/Linux userspace | 12:48 |
| pedroalvarez | locallycompact: thanks for the warning | 12:49 |
| pedroalvarez | this is on the journal of g.b.o: http://paste.baserock.org/badubenaze | 12:49 |
| radiofree | cosm: ah, we're current using a chroot of baserock on the chromeos that came with the acer chromebook | 12:50 |
| radiofree | clocked lower than a jetson board | 12:51 |
| radiofree | cat scaling_max_freq | 12:51 |
| radiofree | 2014500 | 12:51 |
| richard_maw | pedroalvarez: I usually see that when there's someone's been trying to get a tarball of a large checkout using cgit | 12:53 |
| rdale | you 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 yet | 12:53 |
| richard_maw | and Kinnison can tell you how doomful it is to even get started with building ChromeOS | 12:53 |
| rdale | i 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 chromebook | 12:54 |
| radiofree | richard_maw: i was downloading the gcc tarball | 12:54 |
| radiofree | via morph though | 12:54 |
| radiofree | (gcc git tarball) | 12:54 |
| radiofree | which seems to have hung on git checkout hsa | 12:55 |
| radiofree | s/hsa/sha | 12:55 |
| richard_maw | hm, that's particularly poor, since AIUI we're using something built-in to lighttpd to serve that | 12:56 |
| radiofree | i'm not saying that was the cause, by my timestamps correspond with the log pedroalvarez posted | 12:56 |
| pedroalvarez | this log h appens everytime I try to load g.b.o in a browser | 12:57 |
| radiofree | ah it's extracting | 12:58 |
| radiofree | i'm used to this happening on an ssd.. i suppose it takes a while to extract gcc onto an sd card | 12:58 |
| pedroalvarez | right, g.b.o is back | 12:59 |
| radiofree | can we lorry https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ please | 13:02 |
| locallycompact | Building trove from definitions master reports that ERROR: Ref 9fe25bf02dceec04f0ffd6a05cc47146ceab9904 is an invalid reference for repo git://git.baserock.org/baserock/baserock/lorry | 13:29 |
| locallycompact | should be ede3f337e9769b0e6756d4b9cc37d33aa62b82ba | 13:29 |
| richard_maw | Bah! 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_maw | locallycompact: we can either roll back, or wait until this evening when I can push that commit | 13:45 |
| locallycompact | richard_maw: as you like, I'll just continue on with $latest_master | 13:46 |
| * richard_maw will have to see where the git signed push stuff has gotten to | 13:48 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 14:07 | |
| *** abdul [~abdul@202.0.77.198] has joined #baserock | 14:19 | |
| abdul | ssam, | 14:19 |
| abdul | ssam2, hi sam. i am getting build error for the package "node" i have attached error log in http://fpaste.org/148364/41528334/. 146 packages built successfully out of 158 for wandboard in our hardware. | 14:21 |
| richard_maw | ../deps/v8/src/date.cc:155:1: internal compiler error: Segmentation fault | 14:21 |
| richard_maw | hm, we've previously seen this happen for compiler bugs, or running out of memory | 14:22 |
| pedroalvarez | node doesn't build in ppc64 and neither in armv7b | 14:23 |
| pedroalvarez | I'm now checking in armv7lhf | 14:24 |
| paulsher1ood | pedroalvarez: it builds on jetson, i did this last night | 14:25 |
| pedroalvarez | good to know | 14:29 |
| *** cosm [~Unknown@host-78-150-56-250.as13285.net] has quit [Quit: Leaving] | 14:31 | |
| paulsher1ood | actually, maybe i didn't, pedroalvarez. let me check | 14:31 |
| pedroalvarez | paulsher1ood: I'll double check it anyway | 14:34 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:36 | |
| ssam2 | abdul: given that Node.js uses V8, which is some pretty heavy C++, it's probably due to the compiler running out of memory and crashing | 14:36 |
| CTtpollard | HI, 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 command | 14:36 |
| CTtpollard | I've got directories called gerrit & tpollard so I know I have in the past | 14:37 |
| ssam2 | abdul: unless you're planning on writing node.js apps, I suggest you just remove the 'node' stratum from the system you are building | 14:37 |
| paulsher1ood | CTtpollard: morph branch | 14:43 |
| paulsher1ood | morph branch baserock:baserock/definitions yourbranchname [optional-ref-to-branch-from] | 14:44 |
| CTtpollard | is checkout on the wiki outdated then? | 14:44 |
| paulsher1ood | i would prefer to see morph checkout deprecated, since it has known bugs | 14:45 |
| paulsher1ood | which are unlikely to be fixed | 14:45 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 14:45 | |
| paulsher1ood | but others may disagree | 14:45 |
| CTtpollard | ok ty paulsher1ood | 14:46 |
| franred | CTtpollard, we morph checkout for checkout branches/tags which already exist | 14:46 |
| franred | s/we/we use/ | 14:46 |
| franred | s/we/I/ | 14:47 |
| paulsher1ood | for 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 |
| paulsher1ood | s/best/worst/ | 14:48 |
| paulsher1ood | pedroalvarez: yes, node does definitely build on jetson | 14:50 |
| paulsher1ood | http://fpaste.org/148376/ | 14:52 |
| pedroalvarez | paulsher1ood: good | 14:52 |
| pedroalvarez | then: architectures affected by node: ppc64, armv7b | 14:53 |
| pedroalvarez | and here is the error log in ppc64: http://paste.baserock.org/ahebegabev | 14:55 |
| ssam2 | that raises an interesting question, really | 14:56 |
| pedroalvarez | indeed | 14:56 |
| ssam2 | actually, since Node is in its own stratum, we can just remove Node from the devel systems where it doesn't build, for now | 14:56 |
| richard_maw | yep | 14:57 |
| paulsher1ood | max-jobs? | 14:57 |
| pedroalvarez | paulsher1ood: no, missing libraries | 14:57 |
| paulsher1ood | weird | 14:57 |
| paulsher1ood | how can libraries be missing on some architectures? | 14:58 |
| ssam2 | note 'target_arch': 'ia32',' appears in the configuration | 14:58 |
| ssam2 | of the ppc64 build log | 14:58 |
| pedroalvarez | ssam2: good catch | 14:58 |
| ssam2 | I doubt the Node.js developers have given the slightest thought to whether Node builds on PPC64 or big-endian ARM | 14:58 |
| paulsher1ood | fair point | 14:58 |
| ssam2 | pedroavarez: it was Richard Maw who spotted it ;) | 14:59 |
| pedroalvarez | s/ssam2/richard_maw/ | 14:59 |
| SotK | So 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 |
| SotK | However, 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 |
| CTtpollard | is that using a gearman server to allocate the jobs to turbo-hipster workers Sotk? | 15:17 |
| SotK | CTtpollard: yep | 15:17 |
| CTtpollard | cool | 15:17 |
| SotK | I 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 |
| SotK | However, that makes me wonder if there is a plan for CI/CD in the general case (i.e. some undefined git server) | 15:19 |
| ssam2 | why are the commits in Gerrit never in a Trove? | 15:20 |
| ssam2 | could the trove not mirror the Gerrit, for example? | 15:20 |
| ssam2 | i'm probably missing something about how Gerrit works here | 15:20 |
| SotK | if 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 work | 15:22 |
| SotK | similarly if Gerrit was the git server in the Trove then there wouldn't be a problem | 15:23 |
| ssam2 | you can tell a Trove to promote a lorry job to the top of its queue | 15:24 |
| ssam2 | I don't think there's a way to tell Trove to notify you once it's finished, though | 15:25 |
| ssam2 | also, this sounds quite fragile and really only suitable for a prototype | 15:25 |
| ssam2 | could the Gerrit mirror the Trove? | 15:25 |
| ssam2 | that way Trove remains the 'canonical' git server | 15:26 |
| ssam2 | on the downside, we have another code path doing mirroring then | 15:26 |
| ssam2 | was part of your question about if we have a plan for doing CI independently of Gerrit ? | 15:26 |
| ssam2 | if so, I think if Zuul and Gearman require Gerrit, we'll have to require Gerrit for CI, for now | 15:27 |
| ssam2 | does Zuul/Gearman have to be triggered by Gerrit? can it not just be a git post-commit hook on the Trove? | 15:28 |
| radiofree | i've sent a patch to lorry linux-firmware | 15:28 |
| ssam2 | I see, Zuul has pluggable 'triggers' | 15:28 |
| petefoth | Looking 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 |
| radiofree | any objections to that? (assuming the patch checks out) | 15:29 |
| ssam2 | SotK: so, we could add a trigger to Zuul that fired off some kind of git post- or pre-commit hook | 15:29 |
| richard_maw | petefoth: the checks are per write extension, so it may be better to mention them there | 15:29 |
| SotK | ssam2: I believe we could do that, yes | 15:29 |
| ssam2 | radiofree: don't know what it is exactly, but I doubt I object | 15:29 |
| petefoth | richard_maw: thanks | 15:30 |
| pedroalvarez | radiofree: is that chunk going to be needed in every bsp? | 15:30 |
| radiofree | pedroalvarez: 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-jetson | 15:30 |
| radiofree | no more bsp-jetson-devel and bsp-jetson-genivi yay! | 15:31 |
| radiofree | but i suppose if we're moving to "baserock on hardware" it might be useful for others | 15:31 |
| jjardon | radiofree: nice | 15:58 |
| jjardon | what linux kernel version? | 15:58 |
| pedroalvarez | 3.18 | 15:59 |
| radiofree | franred: ssam2: can you merge the lorry? I don't have access | 16:05 |
| franred | radiofree, yes, I can do it | 16:06 |
| radiofree | ta | 16:13 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:15 | |
| franred | radiofree, merged | 16:16 |
| franred | ssam2, thank you for the help :) with .mbox files git am also works :) | 16:17 |
| ssam2 | sweet | 16:28 |
| pdar | I'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 grateful | 16:32 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:35 | |
| locallycompact | pdar: That should happen automatically if your upstream trove is git.baserock.org, how did you deploy your trove? | 16:37 |
| radiofree | hmmm "removing staging area for..." for 20 minutes so far | 16:38 |
| franred | pdar, do you have a local trove or you are talking about the baserock-clone? | 16:39 |
| radiofree | i think the sd card on this is quite slow | 16:40 |
| radiofree | but the build worked! | 16:40 |
| pdar | locallycompact: franred: I was using g.b.o. Now I'm using baserock-clone | 16:40 |
| locallycompact | What is baserock-clone? | 16:40 |
| pdar | locallycompact: a clone of g.b.o used for testing I think | 16:41 |
| franred | pdar, are you said that ceph in g.b.o is pointing to a wrong repo? is ceph a tarball import repository? | 16:42 |
| pedroalvarez | not really a clone, but yes, for testing | 16:42 |
| locallycompact | ceph in g.b.o seems to be several versions behind | 16:42 |
| pdar | locallycompact: it is yes | 16:43 |
| pdar | franred: I dont know, how would I find out? | 16:43 |
| pedroalvarez | here is the ceph.lorry: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/tree/open-source-lorries/ceph.lorry | 16:44 |
| pedroalvarez | seems to be pointing to the right repo | 16:44 |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has joined #baserock | 16:46 | |
| pedroalvarez | here is the error: http://paste.baserock.org/yiginosege. | 16:46 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 16:48 | |
| pdar | pedroalvarez: aha, I guess that is why it stopped updating then. | 16:49 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:50 | |
| pedroalvarez | pdar: yup, we are lokking into it | 16:50 |
| pedroalvarez | looking even | 16:50 |
| franred | in github there is a cls-lua branch but not a cis-lua branch | 16:52 |
| franred | pdar, pedroalvarez ^^ | 16:53 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 260 seconds] | 16:53 | |
| pedroalvarez | hm.. maybe a typo from Kinnison? | 16:54 |
| pedroalvarez | not sure if we should fix that "typo" or change the refspecs | 16:54 |
| richard_maw | force push | 16:55 |
| richard_maw | force push all the things | 16:55 |
| pedroalvarez | hehe | 16:55 |
| pedroalvarez | he did that change a year ago, and this repo hasn't worked for a year | 16:56 |
| pedroalvarez | so yeah, I think it's a typo | 16:56 |
| *** Blacksnow [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:56 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:56 | |
| franred | so add a + before: refs/heads/master:refs/heads/master -> "+refs/heads/master:refs/heads/master" | 16:56 |
| franred | to force push master | 16:57 |
| *** Blacksnow [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 16:57 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:57 | |
| richard_maw | nah, do `["+refs/heads/*:refs/heads/*", "+refs/tags/*:refs/tags/*"]` | 16:57 |
| pedroalvarez | franred: pushing master is not failing | 16:57 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:59 | |
| pedroalvarez | franred: are you going to fix this then? | 17:00 |
| franred | pedroalvarez, pdar, fixed in g.b.o | 17:03 |
| radiofree | ridgerunner: can you paste the output of your current screen to fpaste or something? | 17:06 |
| violeta_ is now known as violeta | 17:06 | |
| franred | radiofree, ridgerunner, http://paste.baserock.org/ | 17:07 |
| franred | ;-) | 17:08 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:11 | |
| pedroalvarez | pdar: fixed! locallycompact thanks for spotting this! | 17:13 |
| pdar | Thanks franred! | 17:13 |
| pdar | and pedroalvarez and locallycompact | 17:14 |
| *** jjardon84 [~jjardon@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 17:15 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Quit: Bye] | 17:28 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 17:28 | |
| *** rjek [~rjek@gateway/shell/pepperfish/x-rjmkpdzfhqiuguqz] has quit [Quit: Reconnecting] | 17:32 | |
| *** rjek [~rjek@gateway/shell/pepperfish/x-yipgojttzsfgxzpj] has joined #baserock | 17:32 | |
| *** jjardon84 [~jjardon@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:32 | |
| *** rdale [~quassel@170.Red-79-145-104.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds] | 17:34 | |
| pedroalvarez | btw, node failing in armv7b: http://paste.baserock.org/eyudemazed | 17:44 |
| pedroalvarez | I guess a max-job: 1 would fix it | 17:44 |
| robtaylor | pedroalvarez: ../deps/v8/src/globals.h:90:2: error: #error Host architecture was not detected as supported by v8 | 17:45 |
| robtaylor | ../deps/v8/src/globals.h:120:2: error: #error Target architecture arm is only supported on arm and ia32 host | 17:45 |
| robtaylor | pedroalvarez: i'm guessing however its' detecting the arch is having problems | 17:45 |
| robtaylor | oh, hang on, is armv7b big endian? | 17:46 |
| pedroalvarez | yes | 17:46 |
| robtaylor | pedroalvarez: probably wont work without adding support to v8 for big endian then | 17:46 |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:48 | |
| rjek | Oh god, that past server | 17:48 |
| rjek | How do I enable wrapping? | 17:48 |
| pedroalvarez | rjek: ctrl + shift + r | 17:49 |
| robtaylor | https://github.com/v8/v8/blob/master/src/arm/assembler-arm.cc#L2449 | 17:49 |
| rjek | pedroalvarez: That's a raw view! | 17:49 |
| * rjek applies eye bleach | 17:49 | |
| pedroalvarez | rjek: and wrapped! | 17:49 |
| pedroalvarez | robtaylor: very useful info, thanks! | 17:50 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:50 | |
| pedroalvarez | I thought there were less differences between compiling something in little endian and compiling the same in big endian | 17:51 |
| paulsher1ood | do we have v8 in baserock? | 17:52 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:53 | |
| pedroalvarez | i'm still not sure about what is it :) | 17:55 |
| pedroalvarez | s/is it/it is/ | 17:55 |
| radiofree | it's a javascript engine that we probably use for node? | 17:56 |
| robtaylor | pedroalvarez: when that component has code generation in, almost certainly not.. | 17:56 |
| robtaylor | same would go for, say, orc or qemu or other JITs | 17:57 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 17:57 | |
| Zara | nodejs can work on baserock so I'm guessing we do have v8 in baserock, but I might have misunderstood something | 17:57 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:58 | |
| radiofree | yes, but it won't compile bigendian. However i can't imagine many people wanting to use bigendian arm systems will want javascript? | 17:58 |
| jmacs | Google V8, it's the javascript engine in Chrome/Chromium | 17:58 |
| robtaylor | Zara: the problem is that anything that generates code for the CPU needs to knwo how to generate code for that CPU | 17:58 |
| robtaylor | Zara: v8 is a JIT, and hence gnerates code | 17:59 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:59 | |
| robtaylor | Zara: it doesnt know how to generate code for ARM big enian or powerpc | 17:59 |
| robtaylor | Zara: so not a baserock thing, but a 'does it support this processor' thing | 17:59 |
| Zara | robtaylor: ah, ok, that makes sense | 18:01 |
| robtaylor | :) | 18:01 |
| *** rdale [~quassel@170.Red-79-145-104.dynamicIP.rima-tde.net] has joined #baserock | 18:05 | |
| * paulsher1ood can't see V8 on git.baserock.org, wonders how it's snuck into baserock systems | 18:17 | |
| ssam2 | there's a copy of V8 inside the Node.js source tree | 18:19 |
| paulsher1ood | aha | 18:21 |
| * paulsher1ood feels deja vu... maybe he asked this before, and forgot the answer | 18:22 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:26 | |
| *** wdutch [95aadb3d@gateway/web/freenode/ip.149.170.219.61] has joined #baserock | 18:27 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:37 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:37 | |
| *** CTtpollard [95aadb3e@gateway/web/freenode/ip.149.170.219.62] has joined #baserock | 18:40 | |
| *** CTtpollard [95aadb3e@gateway/web/freenode/ip.149.170.219.62] has quit [Quit: Page closed] | 20:22 | |
| *** wdutch [95aadb3d@gateway/web/freenode/ip.149.170.219.61] has quit [Quit: Page closed] | 20:30 | |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has quit [Ping timeout: 256 seconds] | 21:02 | |
| *** cosm [~Unknown@us1x.mullvad.net] has joined #baserock | 21:37 | |
| *** cosm [~Unknown@us1x.mullvad.net] has quit [Client Quit] | 21:37 | |
| *** cosm [~Unknown@us1x.mullvad.net] has joined #baserock | 21:37 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 22:06 | |
| radiofree | jjardon: hi, checked through your weston branch, will reply tomorrow | 22:38 |
| radiofree | looks good though | 22:38 |
| radiofree | one comment about your weston branch though, what are those two commits on top for? | 22:41 |
| radiofree | weston 1.6.0 seems to compile fine on my (admittedly older) baserock system | 22:41 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!