| *** gtristan has joined #baserock | 02:02 | |
| *** zoli_ has joined #baserock | 05:42 | |
| jjardon | pedroalvarez: check wayland-gdp depends on input-common | 05:43 |
|---|---|---|
| *** zoli_ has quit IRC | 06:23 | |
| *** gtristan has quit IRC | 06:40 | |
| *** paulwaters_ has joined #baserock | 06:43 | |
| *** ssam2 has joined #baserock | 07:08 | |
| *** ChanServ sets mode: +v ssam2 | 07:08 | |
| pedroalvarez | jjardon: thanks for the hint. I'll take a look at that | 07:15 |
| pedroalvarez | jjardon: I finally managed to get the drm backend working on rpi2, but with some horrible patches on top, and it's not very stable :/ | 07:16 |
| *** gtristan has joined #baserock | 07:30 | |
| *** edcragg has joined #baserock | 07:48 | |
| *** CTbruce has joined #baserock | 07:52 | |
| *** CTbruce has quit IRC | 07:54 | |
| *** ctbruce has joined #baserock | 07:54 | |
| * paulsherwood finds consistent broken build at westongdp | 07:56 | |
| *** jonathanmaw has joined #baserock | 07:56 | |
| *** toscalix__ has joined #baserock | 07:57 | |
| paulsherwood | jonathanmaw: ^^ any ideas? | 08:00 |
| jonathanmaw | paulsherwood: the weston-gdp build failure? | 08:00 |
| paulsherwood | yup | 08:01 |
| jonathanmaw | my first guess is that it's because it shares the same chunk name as another weston in definitions, so ybd picked the wrong one (hence libinput dependency problems) | 08:01 |
| jonathanmaw | I'm looking to see whether that's the case | 08:01 |
| paulsherwood | :/ | 08:02 |
| paulsherwood | i see muliple definitions of libinput, not of westin | 08:04 |
| paulsherwood | weston | 08:04 |
| paulsherwood | still, if we're going to continue allowing multiple definitions of foo, this is a bug in ybd | 08:05 |
| *** bashrc_ has joined #baserock | 08:05 | |
| *** franred has joined #baserock | 08:09 | |
| persia | I don't think we should permit multiple defintions of foo: it's confusing to humans as well as tools. | 08:09 |
| paulsherwood | i agree, but definitions has been in that state forever | 08:10 |
| paulsherwood | and in the real world, if we have, say an openstack system and an openwrt system and a genivi system, they may not all agree on version of foo | 08:14 |
| jonathanmaw | it looks like we're using the wrong version of libinput - ybd used the one in input-common, when it should have used the one from input-genivi | 08:14 |
| paulsherwood | jonathanmaw: any objection to us renaming libinput => libinput genivi ? | 08:14 |
| paulsherwood | libinput-genivi, or libinput@genivi | 08:15 |
| jonathanmaw | my guess is because ybd looked for the chunk named "libinput", not the chunk named "libinput" inside the current strata | 08:15 |
| paulsherwood | yup | 08:15 |
| jonathanmaw | I'll try with libinput@genivi | 08:15 |
| paulsherwood | +1 | 08:16 |
| paulsherwood | if you push that, i can build it too | 08:16 |
| jonathanmaw | pushed | 08:17 |
| paulsherwood | tvm | 08:19 |
| jonathanmaw | looks like weston built | 08:21 |
| paulsherwood | yup, for me too | 08:21 |
| pedroalvarez | weston-gdp name on the strata and in the chunk differ | 08:21 |
| paulsherwood | ? | 08:22 |
| pedroalvarez | strata/weston-genivi-gdp.morph has "name: weston" for the weston chunk, but "strata/weston-genivi/weston-gdp.morph" has "name: weston-gdp" | 08:24 |
| paulsherwood | erk | 08:24 |
| pedroalvarez | and now I see the libinput problem you were talking about | 08:25 |
| paulsherwood | jonathanmaw: i guess we should fix that | 08:28 |
| jonathanmaw | ok, changing the chunk spec in the weston-genivi-gdp stratum to be named "weston-gdp" | 08:34 |
| * paulsherwood waits for the push | 08:35 | |
| * paulsherwood waits for the push | 08:36 | |
| paulsherwood | sorry... i'm not impatient... faulty keypresses | 08:36 |
| * pedroalvarez is working on a rebased version of the gdp branch | 08:37 | |
| pedroalvarez | to see what problems we are going to face beforehand | 08:37 |
| paulsherwood | pedroalvarez: with jonathanmaw's changes? | 08:37 |
| pedroalvarez | yes | 08:38 |
| paulsherwood | kewl | 08:38 |
| jonathanmaw | pushed | 08:38 |
| paulsherwood | [weston] ERROR: No definition found for weston | 08:39 |
| pedroalvarez | jonathanmaw: I think there is a build-dependency on the same stratum that also should be chaned to weston-gdp | 08:39 |
| jonathanmaw | gah! so there is! | 08:40 |
| jonathanmaw | pushed again ¬_¬ | 08:40 |
| * paulsherwood and pedroalvarez are contributing to this discussion to cheer ourselves up while in a meeting :) | 08:40 | |
| pedroalvarez | that is actually true | 08:40 |
| pedroalvarez | paulsherwood: do we know how long takes to build the qt stuff in moonshot? | 08:41 |
| pedroalvarez | around 40 minutes :) | 08:43 |
| paulsherwood | 15-10-13 02:15:21 [42/322/322] [qtwebkit] Elapsed time for build of qtwebkit.01684e28d15542557e00826028910ff0e02e1ee4b2167e9b0612e47fe58cd3d4 00:40:16 | 08:43 |
| pedroalvarez | let's use that monster to build our stuff! | 08:44 |
| paulsherwood | pedroalvarez: i have five of them at themoment. can create another few if we need them | 08:46 |
| jonathanmaw | \o/ system artifact assembled! | 08:47 |
| paulsherwood | here too... x5 :) | 08:47 |
| pedroalvarez | woot | 08:47 |
| paulsherwood | does it blend, though? | 08:47 |
| paulsherwood | s/blend/work/ | 08:47 |
| *** mariaderidder has joined #baserock | 08:48 | |
| * jonathanmaw tries the cluster morph | 08:49 | |
| pedroalvarez | suspense music playing | 08:50 |
| jonathanmaw | it took 21 seconds to not do much... | 08:50 |
| paulsherwood | what's in your cluster? | 08:50 |
| jonathanmaw | http://paste.baserock.org/cozotuliso | 08:51 |
| *** toscalix__ is now known as toscalix | 08:53 | |
| * paulsherwood may have broken deploy lately | 08:56 | |
| * jonathanmaw hides under a desk and waits for the world to end | 08:57 | |
| *** tiagogomes has joined #baserock | 08:57 | |
| paulsherwood | lol | 08:57 |
| paulsherwood | jonathanmaw: try an older version of ybd, just to humour me, say 15.38 | 08:58 |
| jonathanmaw | nope | 09:00 |
| paulsherwood | :/ | 09:01 |
| paulsherwood | where's radiofree when we need 'im? :) | 09:02 |
| jonathanmaw | for lack of ability to deploy, I've decided to see what happens when I rebase against master and try building | 09:09 |
| jonathanmaw | I seem to be in multimedia, at the moment | 09:09 |
| paulsherwood | jonathanmaw: can you paste your deploy output? | 09:10 |
| *** gtristan has quit IRC | 10:00 | |
| *** gtristan has joined #baserock | 10:16 | |
| paulsherwood | couple of quick morph questions... | 10:30 |
| paulsherwood | in the absence of any config, which directory does 'Fetching to local cache' use? | 10:30 |
| paulsherwood | and does anyone know what the actual url is that morph creates to request a given artifact foo? | 10:31 |
| SotK | 1) I think `~/.cache/morph/artifacts` or similar | 10:32 |
| paulsherwood | tvm | 10:33 |
| SotK | 2) `$ARTIFACT_CACHE_SERVER/1.0/artifacts?filename=foo` I think | 10:34 |
| SotK | where $ARTIFACT_CACHE_SERVER is the value of artifact-cache-server in your config | 10:35 |
| paulsherwood | ok, i'll try that, tvm | 10:35 |
| pedroalvarez | I wonder if morph does a check before fetching | 10:36 |
| pedroalvarez | nope | 10:38 |
| pedroalvarez | tries, and if that doesn't work then continues | 10:38 |
| pedroalvarez | and SotK answer to 2) looks right looking at the code | 10:39 |
| pedroalvarez | paulsherwood: it think the default location for the artifacts is "/tmp/morph_tmp/chunks" | 11:07 |
| paulsherwood | pedroalvarez: i think SotK was correct, actually | 11:07 |
| pedroalvarez | mm.. ok, I wonder why they are not going in there in my environment | 11:08 |
| paulsherwood | maybe you have a morph.conf file? | 11:10 |
| pedroalvarez | I do have a morph.conf file but just to set up the cache server | 11:11 |
| pedroalvarez | hm.. I found this: http://paste.baserock.org/usuniwonak | 11:12 |
| pedroalvarez | no, it doesn prove I'm right | 11:13 |
| pedroalvarez | let me research a bit more | 11:13 |
| *** gary_perkins has quit IRC | 11:14 | |
| *** gary_perkins has joined #baserock | 11:15 | |
| pedroalvarez | hah, I see. my cachedir is /home/ubuntu/.cache/morph/, but that is being created inside of the chroot, where the ubuntu user doesn't exist | 11:20 |
| paulsherwood | hah | 11:22 |
| SotK | pedroalvarez: /tmp/morph_tmp/chunks is the chunk hardlink cache IIRC | 11:22 |
| pedroalvarez | it is | 11:23 |
| pedroalvarez | sorry for the confusion | 11:23 |
| *** ssam2 has quit IRC | 11:33 | |
| gtristan | Hey... | 11:49 |
| * gtristan just submitted a few gerrit patches (hopefully less of a mess than last time !) which integrate GDM in the gnome-system-x86_64 build | 11:50 | |
| gtristan | https://gerrit.baserock.org/#/q/topic:startup-shell-with-gdm | 11:50 |
| gtristan | only 4 patches this time, and pretty isolated | 11:50 |
| pedroalvarez | gtristan: good | 11:51 |
| gtristan | currently I did not enable gdm by default, since it doesnt really work without first creating a user | 11:51 |
| * paulsherwood can has http://185.98.148.254:8000/artifacts/* serving artifacts..... TO MORPH!!!!! | 11:51 | |
| pedroalvarez | gtristan: there is still a bug on your latest patch series | 11:51 |
| pedroalvarez | which has been merged | 11:51 |
| gtristan | pedroalvarez, which one... is it the dependency order thing ? | 11:52 |
| * gtristan though jjardon fixed that | 11:52 | |
| pedroalvarez | gtristan: "gnome-shell" has gitmodules | 11:52 |
| gtristan | hmmm, this part is tricky for me :-/ | 11:52 |
| pedroalvarez | I can take a look at that, but not right now | 11:53 |
| pedroalvarez | gtristan: oh, because you don't have push access to g.b.o, right? | 11:53 |
| gtristan | pedroalvarez, afaics, the baserock strategy is to include a delta/patch which changes that on git.baserock.org correct ? | 11:53 |
| pedroalvarez | paulsherwood: woot! | 11:53 |
| pedroalvarez | gtristan: yup | 11:53 |
| jjardon | gtristan: pedroalvarez there is a patch in gerrit to fix that | 11:53 |
| pedroalvarez | jjardon: nice, sorry for not checking before | 11:53 |
| * SotK wonders how paulsherwood did that | 11:53 | |
| gtristan | pedroalvarez, right basically... actually I have to write another email to the list about that - we need some CI strategy for cases where we want to automatically rebase our gitmodule patches (or, perhaps handle the gitmodules differently than with deltas) | 11:54 |
| paulsherwood | +1 | 11:55 |
| richard_maw | gtristan: or to do our own translation of the repository url for the submodules | 11:55 |
| * gtristan was too busy getting burried under PAM today to give thought to the list :-/ | 11:55 | |
| richard_maw | there was a proposal to change the definitions format to allow a method of translating the submodule paths at build time, but it hasn't happened yet | 11:56 |
| paulsherwood | SotK: https://github.com/devcurmudgeon/ybd/commit/97a8281cc3277dca50ee7589c9e8486ec683f622 | 11:56 |
| paulsherwood | SotK: i ran morph to build a system... it pulled artifacts from whereever it normally does | 11:57 |
| SotK | paulsherwood: nice :) | 11:57 |
| paulsherwood | SotK: then i ran kbas to serve artifacts from the directory where morph put its artifacts | 11:57 |
| paulsherwood | s/kbas/my newly hacked kbas/ | 11:58 |
| paulsherwood | SotK: and then `morph build systems/base-system-armv7lhf-highbank.morph --artifact-cache-server=http://185.98.148.254:8000/` | 11:58 |
| pedroalvarez | gtristan: a lot of things merged :) | 11:58 |
| gtristan | pedroalvarez, so quick ! | 11:59 |
| pedroalvarez | I liked you moved from master to tags | 11:59 |
| * paulsherwood decides he deserves lunch today | 11:59 | |
| * SotK is happy to see kbas moving closer to being a universal artifact cache server | 11:59 | |
| gtristan | yeah... well I did pickup on the comments from the last patchset (amid the 300+ emails received) :) | 11:59 |
| gtristan | pedroalvarez, next I will be looking into some CI strategies for the gnome strata (after I get some applications and smooth bootup)... and I am thinking: | 12:00 |
| gtristan | A.) Split up dependencies into a gnome-deps strata separately, with only stable release tags | 12:01 |
| gtristan | B.) Isolate everything that is eligible for CI style builds, and continuously pull from master, but only for gnome.morph | 12:01 |
| paulsherwood | SotK: noted | 12:02 |
| gtristan | pedroalvarez, I'll bring this up on the list soon, but it's something to think about, perhaps we will want a gnome-stable/ and gnome-continuous/ directory ? | 12:02 |
| *** persia has quit IRC | 12:02 | |
| SotK | gtristan: sounds like a job for CIAT | 12:03 |
| pedroalvarez | SotK: shh!! the more help we have the better! | 12:03 |
| gtristan | hahah, yes well I'm sure CIAT will have something to do with it | 12:03 |
| *** persia has joined #baserock | 12:03 | |
| pedroalvarez | gtristan: moving the deps to gnome-deps makes a lot of sense to me | 12:04 |
| gtristan | there needs to be some automation, but also there needs to be some strategy in definitions | 12:04 |
| pedroalvarez | about gnome-stable and gnome-continuous.. would they be the same but one of them using master and the other using tags? | 12:04 |
| gtristan | pedroalvarez, its just a random off-the-top-of-my-head idea, but basically that was the idea yeah | 12:04 |
| gtristan | one would be dedicated to being overwritten by some automated process (-continuous) and the other would be stable release tags only | 12:05 |
| pedroalvarez | I'believe jjardon's dream is to go with latest master for everything | 12:05 |
| gtristan | I think that has about 0.1% chance of booting (if you really mean *everything*) | 12:06 |
| pedroalvarez | maybe we can configure CIAT to: | 12:06 |
| pedroalvarez | 1) check that master keeps building | 12:06 |
| pedroalvarez | 2) Propose changes only for new tags | 12:06 |
| pedroalvarez | nono, everything for gnome | 12:06 |
| pedroalvarez | so it will at least boot :) | 12:07 |
| gtristan | well - I think there is value in both to be honest | 12:07 |
| pedroalvarez | I believe we have been using master on systemd and linux having as a result fully working systems | 12:08 |
| gtristan | they are different goals of course | 12:08 |
| pedroalvarez | yes | 12:09 |
| gtristan | there is also the aspect/possibility of tagging the definitions repository at auto-build time, so that a given 'nightly' build or such can be exactly reproducible at a later date | 12:09 |
| gtristan | anyway I am getting a bit ahead of myself :) | 12:10 |
| jonathanmaw | I'm updating the GENIVI Demo Platform morphs to the latest master, and it's complaining about not defining the build system. I take it I should be running the migrations to fix that. How do I run the migrations? | 12:11 |
| jjardon | about not booting: for reference gnome-continuous builds master of everything (with some temporal exceptions) from systemd up | 12:12 |
| pedroalvarez | jonathanmaw: `./migrations/run-all` | 12:13 |
| pedroalvarez | jonathanmaw: if you have rebaed, then your VERSION file will have version: 6, and then ignore the migrations from 5 to 6 | 12:13 |
| jonathanmaw | so I should run the migrations, then rebase, correct? | 12:14 |
| SotK | jonathanmaw: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/README#n21 has a suggested workflow | 12:14 |
| SotK | idk if thats actually useful in this situation though | 12:15 |
| jjardon | gtristan: IMHO, tracking master is the only way baserock can be useful to contribute upstream | 12:15 |
| jonathanmaw | hrm, no module named ruamel.yaml | 12:16 |
| jonathanmaw | python with a makefile? weird. | 12:17 |
| pedroalvarez | jonathanmaw: my rebase here: baserock/pedroalvarez/gdp-rebase-wip | 12:17 |
| pedroalvarez | this hack make it build http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/pedroalvarez/gdp-rebase-wip&id=8e04dfcc2a88432180f021aff447c8d156e4c83f | 12:17 |
| gtristan | jjardon, if it actually builds more than 1 time out of 10 then that may be viable, but I still tend to disagree | 12:18 |
| gtristan | jjardon, for instance, take the perspective of a GNOME module maintainer, Am I really interested to know that my software breaks when built againt a low level unstable package ? | 12:18 |
| gtristan | I dont think so | 12:18 |
| gtristan | the reverse is also true | 12:18 |
| jjardon | gtristan: mmm, I think disagree: Im interesed in notify mesa devels that a change in its driver broke gnome-shell | 12:19 |
| gtristan | it becomes interesting though, when you take the whole system, and do separate CI for say, Xorg - this tells Xorg developers that *their* latest master may have problems with *stable* dependencies and cause problems in *stable* GNOME, which is more useful | 12:19 |
| gtristan | right, and I would rather root out noise coming from notifying mesa developers about breakage in unstable highlevel soft | 12:20 |
| toscalix | gtristan: I would be interested in evaluate the integration agains a lower level component that is instable if it brings a new feature that I am interested on | 12:22 |
| gtristan | and anyway, this is really only CI related | 12:22 |
| toscalix | I would also be interested depdnding on the release cycle of my project compared to the release cycle of the lower level *in the stack( component | 12:23 |
| gtristan | there are a lot of ifs | 12:23 |
| toscalix | gtristan: agree | 12:24 |
| gtristan | one becomes dependent on bleeding edge dependencies when one branches away from stable, *sometimes* | 12:24 |
| gtristan | this is hopefully advertised in a modules configure script, too | 12:24 |
| toscalix | Am I really interested to know that my software breaks when built againt a low level unstable package ? Sometimes | 12:25 |
| * jonathanmaw is not sure how to install ruamel (so that migrations can run). I ended up with a load of .egg files in /usr/lib/python2.7/site-packages, but "import ruamel.yaml as yaml" throws "ImportError: No module named yaml" | 12:26 | |
| gtristan | jjardon, to be honest though, *personally* I am more interested in baserock's capability of creating a repeatable/stable system, if I were to use it for embedded, the flipside is, "Are we good at producing a stable firmware" | 12:26 |
| jjardon | think big: if everyone work in master, all the components gets integrated all the time, so you dont need to spend large amount of time integrating stuff: for example, gcc developers doesnt get a lot of feedback of the software they are releasing until is packaged by the distros and they start to rebuild everything; Im sure it would interesting for them check | 12:27 |
| jjardon | if a commit breaks a lot of other components or not | 12:27 |
| gtristan | jjardon, which is why essentially I think they are separate goals - and probably we need some way to separate those "build-stable" and "build-continuous" | 12:27 |
| jjardon | we can have both worlds; but all master is definelety more challenging | 12:27 |
| jjardon | gtristan: yeah, I think we agree | 12:28 |
| Phlogistique | Is there a "Why baserock" design document besides http://wiki.baserock.org/overview/ http://wiki.baserock.org/developer-experience/ ? In particular from reading the docs it looks like Baserock does not embrace cross-developpement and instead prefers developpers to work inside a VM; is there a rationale for that? | 12:46 |
| toscalix | so do you guys agree that we have here two different use cases? 1.- upstream developer that wants to know how her code behaves in its environment (other upstream components. 2.- Linux based embedded system integrators | 12:46 |
| toscalix | jjardon: gtristan did I understand it right? | 12:47 |
| richard_maw | Phlogistique: by cross-development do you mean cross-compiling to build your system to target another CPU architecture to that you build from, or cross-platform where the tooling is expected to be run from a variety of platforms? | 12:52 |
| Phlogistique | richard_maw: the former | 12:53 |
| Phlogistique | cross-compiling | 12:53 |
| gtristan | toscalix, on that much I think we agree; I dont see the tool as very useful if I cannot get a reliable base system and build my $product on top of it, and I think it's interesting to have CI of upstream third parties as a side-effect | 12:53 |
| jjardon | toscalix: I think so, but I think they overlap in a lot of cases: you want to work close to upstream if you want to add support to a new driver/hardware | 12:53 |
| gtristan | toscalix, probably, my own priority is the opposite of jjardon's | 12:54 |
| toscalix | one of things I am interesting in figuring out is how much they overlap. That would help us to establish priorities in the near future | 12:54 |
| gtristan | for instance, I want to take my $product deployed using baserock, and run my own CI against the *latest stable* upstream baseline too | 12:54 |
| toscalix | I assume that we have developers which personal interest is upstream development vs other which have "heartbeat piple" as main motivation | 12:55 |
| richard_maw | Phlogistique: ah, then the rationale for that is that there's many projects that dont cross-compile successfully without patching, and the patches may not be acceptable by upstream, since they don't habitually cross-compile. We instead prefer native builds so that it's easier to update those components to new versions, since we don't need to keep rebasing the cross-compilation support patches. | 12:56 |
| * gtristan looks up heartbeat piple | 12:56 | |
| toscalix | s/piple/pipeline | 12:56 |
| jjardon | toscalix: basically if you manage to track master of everything successfully, its quite trivial to implement the other use case (keep some chunk without changes) | 12:56 |
| toscalix | gtristan: http://wiki.baserock.org/ciat | 12:57 |
| Zara | richard_maw: I didn't ask the original question, but thanks for that, was wondering about it. :) | 12:57 |
| pedroalvarez | paulsherwood: hm.. my qtwebkit build is taking longer than 40 minutes, I wonder if I have to set up different makeflags or something | 12:57 |
| toscalix | jjardon: I see. That clarification helps | 12:57 |
| * SotK wonders if the wiki needs that answer on an FAQ page or something | 12:57 | |
| jjardon | so thats why I think we should approach the most difficult use case | 12:57 |
| Zara | SotK: +1 | 12:58 |
| gtristan | toscalix, "Staying as close to upstream as possible simplifies integration and maintenance at big scale", I believe this to be true, but it's hard to convince people of that | 12:58 |
| richard_maw | Phlogistique: as for why we prefer to work in VMs (or chroots), it's because while we take great efforts to improve reproducibility and reliability with sandboxed builds, for the early bootstrap steps it depends on what you have available in your host system, so we prefer you run the Baserock tools from a known working system | 12:58 |
| toscalix | SotK: we will put some effort in the coming weeks in simplifying the entry point for a newcommer | 12:59 |
| petefoth | Cross-compilation is mentioned (under 'Uncertain wishes') on the Wishlist page http://wiki.baserock.org/wishlist/ | 12:59 |
| toscalix | gtristan: nobody that integrates software will believe you if you put the concept simple and integration in the same sentence | 13:00 |
| gtristan | toscalix, for instance just this summer, we had our downstream of debian jessie as our base system on which we built our $product - to me it seemed a no-brainer to regularly integrate from upstream jessie, but it's amazing the stop energy I encountered there | 13:00 |
| toscalix | and there are very limited proofs of that | 13:00 |
| toscalix | the other case is easier to sell, maintenance becomes easier | 13:01 |
| gtristan | I mean, we of course have our *own* testing process, and upgrading the OS invalidates *everything*, welcome to a new set of bugs | 13:01 |
| toscalix | gtristan: I get it, I believe | 13:01 |
| gtristan | of course it becomes interesting to have immense validation, if I can test my downstream 'baserock' with the latest 'stable upstream' and automate as much testing as possible - that reduces the stop energy | 13:03 |
| * SotK hopes that effort will involve creating an FAQ page rather than just tidying up guides :) | 13:03 | |
| * gtristan heads out... it's getting late | 13:04 | |
| gtristan | interesting chat :) | 13:04 |
| *** gtristan has quit IRC | 13:05 | |
| toscalix | SotK: I think we miss an approach that clarifies what is BAserock for, how can benefit certain use cases.... | 13:05 |
| Phlogistique | richard_maw petefoth: interesting, thanks for the answer | 13:05 |
| SotK | toscalix: +1 | 13:05 |
| toscalix | SotK: which will require an exercise of "let's raise our head and look around" | 13:06 |
| petefoth | toscalix: I think we haven't documented that, because we don't really know yet | 13:06 |
| toscalix | petefoth: we will | 13:06 |
| petefoth | Gppd | 13:06 |
| petefoth | Good | 13:06 |
| toscalix | we need to | 13:06 |
| toscalix | and we will | 13:06 |
| paulsherwood | pedroalvarez: using ybd or morph? | 13:09 |
| paulsherwood | pedroalvarez: check if max-jobs is set in the morph file? | 13:10 |
| pedroalvarez | paulsherwood: do you have a suggestion for the right number on the moonshot? | 13:10 |
| *** ssam2 has joined #baserock | 13:10 | |
| *** ChanServ sets mode: +v ssam2 | 13:10 | |
| pedroalvarez | i've set it to 8 after realising that the default is 2 | 13:10 |
| paulsherwood | pedroalvarez: max-jobs = number of cores or 9, whichever is less (is my current engineering approximation) | 13:12 |
| paulsherwood | someone should fix morph to not do 1.5*cores. | 13:12 |
| pedroalvarez | I guess morph failed to figure out the number of cores on the chroot because /proc is not mounted | 13:14 |
| richard_maw | pedroalvarez: it's using the wrong API to find out the number of cores then | 13:16 |
| richard_maw | you don't need to use /proc/cpuinfo | 13:16 |
| richard_maw | there's the nproc command, which uses the right getconf call | 13:16 |
| richard_maw | sysconf(_SC_NPROCESSORS_ONLN) | 13:17 |
| pedroalvarez | cpu_count() returns 1 :/ | 13:21 |
| pedroalvarez | multiprocessing.cpu_count | 13:22 |
| richard_maw | pedroalvarez: weird, what version of python are you running there? it should have multiprocessing.cpu_count() | 13:23 |
| pedroalvarez | richard_maw: I mean, I can import it, and when executing it it returns 1, as number of cores | 13:24 |
| richard_maw | pedroalvarez: multiprocessing, or morphlib? | 13:25 |
| pedroalvarez | richard_maw: multiprocessing.cpu_count | 13:26 |
| richard_maw | hm, then that's the glibc call returning 1 | 13:27 |
| richard_maw | bah, that sysconf isn't a nice syscall, it reads it out of /sys | 13:28 |
| richard_maw | so yes, it's falling back to 1 because it's unable to determine it any other way | 13:29 |
| pedroalvarez | jonathanmaw: I managed to do the migration to v6 on "baserock/pedroalvarez/gdp-rebase-wip" | 13:31 |
| jonathanmaw | I tried that and it told me I had 404 errors when getting something for qtwayland and audiomanagerdemo, so I fixed that manually | 13:31 |
| jonathanmaw | I'm currently building gcc, so that looks like it'll be a long haul | 13:32 |
| pedroalvarez | jonathanmaw: are you using morph? | 13:33 |
| jonathanmaw | yep | 13:33 |
| pedroalvarez | on a moonshot chroot? | 13:33 |
| jonathanmaw | currently on Jetson, looking into starting it on a moonshot chroot | 13:33 |
| pedroalvarez | ok, for the moonshot: http://paste.baserock.org/uqidaxuhaf | 13:34 |
| pedroalvarez | jonathanmaw: for the jetson, use the same artifact-cache-server | 13:34 |
| paulsherwood | jonathanmaw: http://wiki.baserock.org/ybd/?updated#index5h2 may help... but don't move linux-user-chroot | 13:34 |
| *** paulwaters_ has quit IRC | 13:56 | |
| paulsherwood | jonathanmaw: i've checked that morph builds systems if they're in (say) an automotive directory, rather than the systems dir. could we move all genivi systems to a new automotive dir? | 13:58 |
| paulsherwood | (and clean up strata later) | 13:58 |
| jonathanmaw | paulsherwood: ok, I'll start on that | 13:59 |
| jonathanmaw | (I hope that won't affect cache-keys) | 13:59 |
| richard_maw | it shouldn't | 13:59 |
| paulsherwood | doesn't seem to | 14:00 |
| *** CTtpollard has quit IRC | 14:00 | |
| pedroalvarez | 2015-10-14 14:00:03 [Build 334/370] [qtwebkit] Elapsed time 00:52:33 | 14:00 |
| paulsherwood | told you... morph is slower than ybd :) | 14:01 |
| pedroalvarez | hah | 14:01 |
| *** fay_ has quit IRC | 14:01 | |
| paulsherwood | to be fair, that might be a different measure... maybe it includes artifact creation etc | 14:02 |
| pedroalvarez | it does, but only the build-commands took 52 minutes | 14:05 |
| paulsherwood | max-jobs = 8? | 14:05 |
| pedroalvarez | yes | 14:05 |
| paulsherwood | odd, then | 14:05 |
| pedroalvarez | yes | 14:06 |
| pedroalvarez | I wonder if anything else slows down a bit the build | 14:06 |
| pedroalvarez | linux-user-chroot vs chroot | 14:06 |
| pedroalvarez | or writing the stdout somewhere (idk if ybd also does that) | 14:07 |
| paulsherwood | ybd writes to a log | 14:07 |
| persia | (catching up on backscroll): regarding cross-compilation: I don't know of a cross-compiler that generates the same code as a native compiler would generate. I know of several projects to address this, but even if there are no patches required upstream, the results can differ in surprising ways, and the problems inherent in this have not yet been fully addressed. | 14:13 |
| pedroalvarez | richard_maw: thanks for your lorry-controller patch | 14:17 |
| pedroalvarez | makes me happy, I'll don't have to care about the db anymore | 14:17 |
| * richard_maw prepares a definitions patch | 14:18 | |
| pedroalvarez | :D | 14:19 |
| tiagogomes | was morph ever profiled? | 14:21 |
| richard_maw | early versions were | 14:21 |
| persia | tiagogomes: Parts of it were, several times. I don't know if all of it was. I know that some bits were sped up at the cost of others at some points, depending on what was more frequently used and/or painfully slow. | 14:23 |
| *** fay_ has joined #baserock | 14:32 | |
| paulsherwood | anyone know what the default serial terminal settings shoudl be for a jetson? | 14:59 |
| pedroalvarez | screen /dev/ttyUSB0 115200 ? | 15:00 |
| paulsherwood | splurge of random characters | 15:01 |
| *** jonathanmaw has quit IRC | 15:01 | |
| pedroalvarez | then it isn't | 15:01 |
| pedroalvarez | 57600? | 15:01 |
| pedroalvarez | hehe, when I forget I try all the possibilities :) | 15:02 |
| * SotK has always had success with 115200 on a jetson | 15:02 | |
| pedroalvarez | yes, just checked and it is 115200 | 15:02 |
| paulsherwood | that's what i thought. my jetson is misbehaving, then | 15:03 |
| pedroalvarez | I can check that if that's true if you want | 15:05 |
| pedroalvarez | s/that// | 15:05 |
| pedroalvarez | btw, boost also takes ages to compile? | 15:05 |
| SotK | quite a while, yeah | 15:05 |
| paulsherwood | pedroalvarez: http://wiki.baserock.org/build-times/ | 15:07 |
| pedroalvarez | looks like it only uses one core | 15:09 |
| pedroalvarez | [boost] Elapsed time 00:43:12 | 15:10 |
| paulsherwood | :/ | 15:12 |
| pedroalvarez | dbus-python fails with: http://paste.baserock.org/axegarusud | 15:15 |
| pedroalvarez | looking into that | 15:15 |
| * pedroalvarez adds audio-bluetooth.morph as dependency for genivi-demo-platform-libs.morph | 15:18 | |
| * paulsherwood establishes that it must be his mac playing silly rather than the jetson | 15:23 | |
| paulsherwood | turned out to be the serial cable | 15:41 |
| pedroalvarez | aha! boost building in 8 cores! | 15:52 |
| pedroalvarez | https://jedipretzel.files.wordpress.com/2012/06/tumblr_lyonsbnk8s1qazqlgo2_500.gif | 15:53 |
| *** fay_ has quit IRC | 15:56 | |
| *** ssam2 has quit IRC | 15:57 | |
| pedroalvarez | [boost] Elapsed time 00:10:49 | 16:02 |
| pedroalvarez | much better | 16:02 |
| pedroalvarez | looks like I'll be deploying shortly gdp to raspberry pi :) | 16:08 |
| paulsherwood | c00l! | 16:08 |
| pedroalvarez | paulsherwood: would it be possible to have that kbas serving morph artifacts in my moonshot node too? | 16:09 |
| pedroalvarez | Or should I push these artifacts to that node | 16:09 |
| paulsherwood | pedroalvarez: there's broadly two possibilities... | 16:10 |
| paulsherwood | (for ybd) | 16:10 |
| paulsherwood | - upload artifacts as they are built | 16:10 |
| paulsherwood | - run ybd to pull artifacts from another server | 16:11 |
| paulsherwood | but are you using morph, or ybd? | 16:11 |
| pedroalvarez | morph | 16:11 |
| paulsherwood | you could run kbas there, to serve those artifacts | 16:11 |
| pedroalvarez | but my build just failed :/ | 16:11 |
| paulsherwood | shame | 16:11 |
| pedroalvarez | yes, that would be ideal | 16:12 |
| pedroalvarez | I could also run morph-cache-server to be fair | 16:12 |
| paulsherwood | true | 16:12 |
| pedroalvarez | build error: http://paste.baserock.org/utizilowij | 16:13 |
| pedroalvarez | looking into that right now | 16:13 |
| paulsherwood | for kbas... ssh in, then in an uptodate checkout of ybd, create a kbas.conf file and set artifact-dir: /src/armv7chroot/root/.cache/morph/artifacts or whatever is the full path | 16:15 |
| pedroalvarez | paulsherwood: easy! thanks | 16:16 |
| paulsherwood | maybe you'll want mode: production as well | 16:17 |
| paulsherwood | in other news, i'm now running ybd on jetson, downloading cached artifacts from moonshot :) | 16:18 |
| paulsherwood | which is rather faster than building them, i notice | 16:19 |
| pedroalvarez | audiomanagerdemo building \o/ | 16:19 |
| pedroalvarez | it was missing a dependency | 16:19 |
| *** ctbruce has quit IRC | 16:20 | |
| paulsherwood | note to self... ybd counter doesn't incrememt on cache downloads | 16:20 |
| paulsherwood | 15-10-14 00:19:39 [33/322/322] [genivi-demo-platform-armv7lhf-jetson] Elapsed time for artifact creation 00:03:40 | 16:27 |
| *** franred has quit IRC | 16:41 | |
| *** Stanto has quit IRC | 16:50 | |
| *** richard_maw has quit IRC | 16:50 | |
| *** ctgriffiths has quit IRC | 16:50 | |
| *** dabukalam has quit IRC | 16:50 | |
| *** JPohlmann has quit IRC | 16:50 | |
| *** nowster has quit IRC | 16:50 | |
| *** pedroalvarez has quit IRC | 16:50 | |
| *** benbrown_ has quit IRC | 16:50 | |
| *** pedroalvarez has joined #baserock | 16:55 | |
| *** ChanServ sets mode: +v pedroalvarez | 16:55 | |
| pedroalvarez | this kbas serving morph artifacts works | 16:56 |
| *** nowster has joined #baserock | 16:59 | |
| *** benbrown_ has joined #baserock | 16:59 | |
| * pedroalvarez deploys gdp to a rpi | 17:00 | |
| pedroalvarez | let's see how it blows up :) | 17:00 |
| *** mariaderidder has quit IRC | 17:02 | |
| * paulsherwood deploys it to a jetson, using ybd | 17:02 | |
| *** bashrc_ has quit IRC | 17:04 | |
| *** nowster has quit IRC | 17:07 | |
| *** benbrown_ has quit IRC | 17:07 | |
| *** JPohlmann has joined #baserock | 17:07 | |
| *** JPohlmann has joined #baserock | 17:07 | |
| *** richard_maw has joined #baserock | 17:08 | |
| *** ChanServ sets mode: +v richard_maw | 17:08 | |
| *** ctgriffiths has joined #baserock | 17:08 | |
| *** dabukalam has joined #baserock | 17:08 | |
| *** Stanto has joined #baserock | 17:10 | |
| *** nowster has joined #baserock | 17:10 | |
| *** benbrown_ has joined #baserock | 17:10 | |
| paulsherwood | gah!!! https://github.com/devcurmudgeon/ybd/commit/ef528b64d4d223045e904ebf504a702aea0d3033 | 17:12 |
| paulsherwood | /src/definitions # system-version-manager list | 17:12 |
| paulsherwood | [ 5660.123183] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null) | 17:12 |
| paulsherwood | factory (running) | 17:13 |
| paulsherwood | foo-bar (default) | 17:13 |
| paulsherwood | deploy with (fixed) ybd successful... now to reboot :) | 17:13 |
| paulsherwood | it boots | 17:14 |
| paulsherwood | it's beer o'clock | 17:14 |
| *** gary_perkins has quit IRC | 17:29 | |
| pedroalvarez | Hmm it look like it works, but this kernel is not stable. Doesn't show anything on the screen | 17:47 |
| *** edcragg has quit IRC | 17:59 | |
| *** brlogger has joined #baserock | 19:23 | |
| *** toscalix__ has joined #baserock | 22:30 | |
| *** toscalix has quit IRC | 22:30 | |
| *** toscalix__ has quit IRC | 22:34 | |
| *** toscalix__ has joined #baserock | 22:34 | |
| *** petefoth_ has joined #baserock | 23:58 | |
| *** petefoth has quit IRC | 23:59 | |
| *** petefoth_ is now known as petefoth | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
