| petefoth | So, CP/M in BAserock? http://www.theregister.co.uk/2014/10/02/cpm_source_code_release/ | 07:36 |
|---|---|---|
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:39 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:49 | |
| paulsherwood | heh | 07:55 |
| paulsherwood | richard_maw: it's not clear from your comments, does your series fix distbuild? | 07:55 |
| paulsherwood | franred: please can you merge the bash update? | 07:56 |
| paulsherwood | (+3 should be more than enough) | 07:57 |
| franred | paulsherwood, sure | 07:57 |
| paulsherwood | tvm | 07:57 |
| paulsherwood | are we near to gerrit yet? :) | 07:57 |
| pedroalvarez | petefoth: CP/M? | 07:59 |
| petefoth | pedroalvarez: an OS for microcomputers that predated DOS | 08:01 |
| petefoth | https://en.wikipedia.org/wiki/CP/M | 08:01 |
| pedroalvarez | paulsherwood: hey! I like your cycle.sh cript, but I think we could do with a better name :/ | 08:01 |
| pedroalvarez | script* | 08:01 |
| petefoth | It ran the first computer I owned, an Amstrad PCW | 08:01 |
| pedroalvarez | I had to use DOS yesterday... after many years | 08:06 |
| pedroalvarez | hmm.. also the cycle.sh script could be improved to work also in jetsons | 08:08 |
| pedroalvarez | but for now I think it's ok | 08:09 |
| franred | paulsherwood, gerrit was handover to a another team and they are working on the configuration part | 08:11 |
| paulsherwood | pedroalvarez: i would like it to work on jetsons... but i need help from experts to achieve that. | 08:12 |
| paulsherwood | it seems clunky to have to have separate upgrade-foo.morph clusters | 08:14 |
| SotK | paulsherwood: the jetson needs different kernel args in its upgrade cluster though | 08:14 |
| pedroalvarez | paulsherwood: yeah, having only one could be possible | 08:14 |
| pedroalvarez | SotK: a cluster morphology with various deployments defined | 08:14 |
| SotK | pedroalvarez: I was just typing that exact suggestion :) | 08:15 |
| SotK | however, the "self.HOSTNAME" and "self.VERSION_LABEL" bits would need to change since we couldn't have every deployment called "self" | 08:16 |
| paulsherwood | why can't the kernel args be with the system, not the cluster? | 08:17 |
| paulsherwood | and then we have one upgrade.morph for self | 08:18 |
| * SotK lacks the knowledge to answer that | 08:21 | |
| SotK | there are other things needed by the jetson in its upgrade cluster too though | 08:22 |
| paulsherwood | ok | 08:22 |
| paulsherwood | please comment on the patch on the ML. i'm hoping folks will agree it as is, since it works for local vm and cloud. but if someone can help tweak the principle to apply to jetson etc even better | 08:24 |
| pedroalvarez | the kernel args are used when deploying a system. I think is not appropiate to set them when building. I wouldn't know where to put them :/ | 08:25 |
| paulsherwood | ok | 08:25 |
| * paulsherwood doesn't deeply understand this. | 08:25 | |
| * paulsherwood just wants a simple workflow :) | 08:25 | |
| paulsherwood | note with the current script, i can cycle into a base system, or a devel, or a genivi system, and then back to my factory... rinse and repeat | 08:27 |
| paulsherwood | (on x86 and cloud) | 08:27 |
| pedroalvarez | paulsherwood: works in the cloud? | 08:28 |
| paulsherwood | yup | 08:28 |
| * pedroalvarez wonders if his patch landed | 08:28 | |
| * paulsherwood used the uuid patch, if that's what pedroalvarez means | 08:28 | |
| * SotK updates morph and has to rebuild the world :( | 08:28 | |
| paulsherwood | SotK: why do that? | 08:29 |
| pedroalvarez | paulsherwood: that's what I meant :) | 08:31 |
| SotK | because I got the xfer-hole bug and so updated to the branch containing the fix (note: I was a couple of weeks behind master beforehand) | 08:31 |
| paulsherwood | pedroalvarez: i've +1 that patch, so can merge | 08:32 |
| paulsherwood | (if you trust my +1) :-) | 08:32 |
| pedroalvarez | oh! does it already have +2? | 08:32 |
| pedroalvarez | great | 08:32 |
| paulsherwood | richard_maw + paulsherwood = +2 i think | 08:33 |
| * pedroalvarez is really going to enjoy gerrit | 08:33 | |
| * paulsherwood too | 08:33 | |
| paulsherwood | i'll be even happier when mason is building and publishing latest morph, latest artifacts all the time | 08:34 |
| * franred really wants to have an auto-tester which votes in gerrit | 08:34 | |
| paulsherwood | +1 | 08:34 |
| paulsherwood | can we get it done today? :) | 08:34 |
| pedroalvarez | hahahah we have paulsherwood for that | 08:34 |
| * paulsherwood is not entirely kidding | 08:34 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:35 | |
| * pedroalvarez is going to think about it in its spare brain time | 08:36 | |
| petefoth | Could we not use the tests that Firehose did (build, deploy, check deployed systems can a start and b: build a minimal system) as the startign poitn for such an autotester? | 08:39 |
| petefoth | And then add tests for upgrading | 08:39 |
| paulsherwood | yes we could | 08:39 |
| pedroalvarez | after a quick converstaion with franred seems we have to integrate more software to make the gerrit testing happens | 08:40 |
| paulsherwood | how much more? | 08:40 |
| petefoth | so we could put gerrit in place witout and autotester, then add the autotester when we've integrated whatever else we need? | 08:41 |
| petefoth | Or we could wait unitl everything is finished before we start using Gerrit :) | 08:41 |
| franred | paulsherwood, we want to use zuul and turbo-hipster to to the build and testing part for voting in the autotest, AFAIK | 08:42 |
| paulsherwood | yes | 08:42 |
| franred | not sure how difficult will use Firehose/mason for testing branches in one shot and return +1/-1 | 08:43 |
| franred | petefoth, the idea is use Gerrit first and then integrate the other parts step by step. Gerrit can live by itself | 08:44 |
| paulsherwood | can we use gerrit on its own first? would adding the test stuff later be harder? | 08:44 |
| petefoth | franred: great! Can I have StoryBoard after Gerrit too please? | 08:44 |
| paulsherwood | storyboard is happening | 08:45 |
| franred | petefoth, Im not the guy in charge of that anymore | 08:45 |
| petefoth | franred: paulsherwood: I know, I'm just impatient :) | 08:46 |
| paulsherwood | me too :) | 08:46 |
| franred | paulsherwood, yes,you can use gerrit and AFAIK you could add stuff later, not sure how much work will be involve but I will not expect a lot of clashes | 08:46 |
| jjardon | petefoth: what's the storyboard for? | 08:49 |
| petefoth | jjardon: Tracking issues, new and changed requirements and features. PLus a linked Kanban view | 08:50 |
| petefoth | jjardon: OpenStack are startign to use instead of blueprints, though In don'g think they are using it for tracking issues and bugs | 08:52 |
| straycat | paulsherwood, There are a couple of problems with distbuild just now, I expect richard_maw's series fixes the serialisation problems brought about switching to per source builds. The other issue is an encoding one, which I think we're going to fix by encoding distbuild messages in base64, I was planning to make a start on that today assuming there's no objections. | 08:53 |
| jjardon | Oh, yeah a place to report bug will be helpful. petefoth do you have a link to the webpage of the project? Seems my search abilities are not as good today | 08:55 |
| paulsherwood | jjardon: we don't quite have storyboard setup for baserock yet | 08:56 |
| jjardon | I know, I mean the webpage of the storyboard software. I assume is a independent project like gerrit? | 08:57 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:58 | |
| paulsherwood | https://wiki.openstack.org/wiki/StoryBoard | 08:58 |
| ssam2 | Mason is broken in a very exciting new way | 09:01 |
| ssam2 | http://85.199.252.101/log/17d6673d64a2e78534c12c92a18e90def9ac31cd--2014-10-02%2008:59:01.log | 09:01 |
| ssam2 | '413 - Request Entity Too Large' while annotating the build graph | 09:01 |
| paulsherwood | ssam2: revert the bash patch? | 09:02 |
| petefoth | jjardon: and http://ci.openstack.org/storyboard/ fior documentation :) | 09:02 |
| paulsherwood | actually, we have 2 masons. when did the other one break? | 09:02 |
| ssam2 | 'Update morph to include per-source building changes' | 09:03 |
| paulsherwood | hmmm | 09:04 |
| ssam2 | but that wouldn't affect the Morph running inside the Mason | 09:04 |
| paulsherwood | this is exciting indeed | 09:04 |
| ssam2 | I think it's some message size limit that's randomly being exceeded now | 09:04 |
| ssam2 | possibly a limit Bottle sets on the size of the 'artifacts' query to morph-cache-server | 09:05 |
| jjardon | paulsherwood: petefoth thanks for the links, looks promising indeed | 09:06 |
| ssam2 | i'll have a poke and see | 09:06 |
| ssam2 | the Trove that the Mason is using has no free disk space | 09:13 |
| ssam2 | that could be part of the problem | 09:13 |
| ssam2 | hardly unexpected since Mason is continuously uploading artifacts there ;) | 09:13 |
| * ssam2 deletes /home/cache/artifacts/*devel-system* | 09:14 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 09:14 | |
| jjardon | I'm planning to move llvm to its own stratum: it takes ages to build and do not want to rebuild it for any change in foundation or Wayland. Also it can be a dependency of a future "compilers" stratum. Does this look like a good plan? | 09:17 |
| ssam2 | the other Mason we have running internally also has a full artifact-cache-server. I guess they both filled up at the same time. | 09:19 |
| ssam2 | jjardon: I'm not sold on the idea of 'compilers' stratum | 09:19 |
| ssam2 | but reducing the amount of times I have to build LLVM is definitely welcome | 09:19 |
| ssam2 | really we should only be using one C compiler in Baserock, I think | 09:19 |
| ssam2 | but I guess that's not really achievable | 09:20 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:21 | |
| jjardon | Me neither, the main advantage of the patch is to avoid rebuilds really | 09:23 |
| ssam2 | cool, well it sounds good anyway | 09:25 |
| jjardon | BTW, IIRC llvm is not the compiler, that would be clang, that has llvm as dependency | 09:25 |
| ssam2 | good point | 09:25 |
| jmacs | "clang" is the name of the binary you invoke to compile C compilers, but llvm is still the compiler | 09:50 |
| jmacs | s/compilers/source/ | 09:51 |
| rjek | jmacs: They're compile compilers aren't they? | 09:53 |
| rjek | clang translates C to LLVM bitcode, LLVM translates LLVM bitcode to native code? | 09:53 |
| richard_maw | AIUI clang is the C frontend, which turns it into an IR, and llvm turns that into code | 09:53 |
| richard_maw | rjek: snap | 09:53 |
| jmacs | Yes, I wouldn't call clang a compiler | 09:53 |
| rjek | richard_maw: Not only an IR, but something you can run directly with a VM or JIT. | 09:54 |
| rjek | So conceptually it's in the same place as javac. | 09:54 |
| straycat | richard_maw, The comment in artifact.py about add_dependencies doesn't apply anymore does it? | 10:00 |
| richard_maw | straycat: let me go check which comment this is, please hold | 10:07 |
| richard_maw | straycat: yep, they should go | 10:08 |
| paulsherwood | does morph gc remove artifacts? | 10:08 |
| paulsherwood | ssam2, richard_maw ^^ | 10:08 |
| paulsherwood | assuming so, should mason run morph gc? | 10:08 |
| richard_maw | paulsherwood: we discussed this IRL. AIUI mason does run morph gc | 10:09 |
| richard_maw | but | 10:09 |
| * paulsherwood waits | 10:10 | |
| richard_maw | the cache that filled up is the one that traditionally sits on a trove, and is served by `morph-cache-server`, which doesn't have a gc | 10:10 |
| paulsherwood | would morph gc on morph-cache-server do the right thing? | 10:12 |
| paulsherwood | ssam2: it is not clear that deleting artifacts has helped.... are you confident it did? | 10:14 |
| richard_maw | paulsherwood: not currently, as the cache server doesn't update mtimes of artifacts it serves | 10:14 |
| richard_maw | the repository format _may_ be compatible, but without the mtime updating, they'll be cleaned up in insertion order, rather than least-recently-used | 10:15 |
| paulsherwood | richard_maw: that would still be better than falling over in a heap? | 10:15 |
| * paulsherwood may be wrong, as usual | 10:16 | |
| richard_maw | it would be better than falling in a heap, but it would be really sub-optimal, since the things low in the dependency graph, which we don't tend to rebuild often, would be the first to be gc'd even though we're frequently making top-level artifacts that get quickly superceded by more recent versions | 10:19 |
| ssam2 | paulsherwood: the continual failures on the masons have stopped | 10:20 |
| ssam2 | so I assume it's in the process of building something | 10:20 |
| ssam2 | I'm trying to hack together a quick 'trove-gc' script, which just runs 'morph gc' with appropriate config | 10:20 |
| ssam2 | for the Mason artifact cache servers, that'll be fine. On git.baserock.org we'll not want to ever run that, because it'll remove release artifacts. | 10:21 |
| paulsherwood | aha | 10:25 |
| paulsherwood | ssam2: i'm imagining that in future git.baserock.org has a mason/firehose (or maybe it's edge.baserock.org) with a rolling pool of 'current' artifacts, separate from whatever we call releases | 10:27 |
| ssam2 | that'd make sense | 10:28 |
| ssam2 | all we'd need is a way to mark to the trove-gc script "don't delete these ones!" | 10:29 |
| ssam2 | we could achieve that today, in fact, as persia suggested a few weeks ago | 10:29 |
| richard_maw | or have the morph cache server able to be given multiple artifact directories, one of which we manually put artifacts in, and another that gets populated by a mason | 10:29 |
| ssam2 | we could set up 'artifacts.baserock.org' to point to 85.199.252.93 and have morph's 'artifact-cache-server' setting default to artifacts.baserock.org | 10:30 |
| ssam2 | I suppose then we'd not have the release artifacts available by default any more | 10:30 |
| ssam2 | if Morph supported a list of multiple artifact cache servers it'd work, I guess, but it doesn't right now | 10:31 |
| paulsherwood | i like the 'today' idea :) | 10:32 |
| violeta | radiofree, what should be the DISK_SIZE for the Baserock image? | 10:32 |
| radiofree | 3G is reasonable | 10:32 |
| richard_maw | I usually put 4G, so I have room for a few upgrades | 10:32 |
| radiofree | is this a devel image or a genivi one? | 10:32 |
| violeta | radiofree, ehm, devel AFAICT | 10:33 |
| ssam2 | to be clear, the 'today' idea was to set up an 'artifacts.baserock.org' redirect to 85.199.252.93 and change morph's default artifact cache server | 10:33 |
| radiofree | put 4G then | 10:33 |
| violeta | ok | 10:33 |
| ssam2 | if we do the 'Everyone should use latest Morph' thing (which I assume everyone agrees with, since they haven't responded) it'd be fine to not have release artifacts available anyway | 10:33 |
| paulsherwood | i'm ok with that so long as we are confident in reproducibility. which i believe we are, now? | 10:35 |
| paulsherwood | ssam2: i'm still liking the 'today' idea | 10:36 |
| pedroalvarez | ssam2: but you have to download baserock to be able to use morph, so we need to release something | 10:36 |
| radiofree | violeta: do the flashing on your laptop btw, not in a vm | 10:37 |
| violeta | radiofree, yes, I learnt that lesson the hard way :-P | 10:37 |
| radiofree | you could actually use baserock to upgrade your jetson, then only flash the new u-boot with https://github.com/NVIDIA/tegra-uboot-flasher-scripts | 10:38 |
| radiofree | but just try flashing it first! | 10:39 |
| violeta | hmmm | 10:39 |
| radiofree | for testing it's generally much easier just cross-compile u-boot and use those scripts | 10:39 |
| ssam2 | pedroalvarez: yeah, but that 'something' could be the latest devel system that the Mason built | 10:40 |
| paulsherwood | pedroalvarez: currently yes. soon, maybe not :) | 10:40 |
| violeta | could I have just built u-boot? | 10:40 |
| radiofree | violeta: for what you're trying to do? no, you need all of this stuff to get the graphics working with 3.17 | 10:41 |
| radiofree | is the goal to have something to show in git for this? | 10:41 |
| radiofree | i suppose it needs to be done the baserock way, for a baserock demo | 10:42 |
| violeta | ok | 10:42 |
| paulsherwood | :) | 10:43 |
| paulsherwood | pedroalvarez: have we tried openstack on jetsons? or is this a dumb question? | 10:53 |
| pedroalvarez | the question is: do the jetson support virtualization? | 10:54 |
| paulsherwood | A15.. bound to? :) | 10:54 |
| pedroalvarez | paulsherwood: so the answer is no, we haven't tried | 10:57 |
| pedroalvarez | to me is not a dumb question | 10:57 |
| pedroalvarez | I also wondered the same in the past | 10:58 |
| paulsherwood | is it just a matter of adding some strata to a jetson distbuild system? | 10:58 |
| richard_maw | and ensuring we've enabled kvm in the kernel | 10:58 |
| * paulsherwood has a jetson, as regular readers may know :) | 10:58 | |
| paulsherwood | no need for modules and such? | 10:59 |
| pedroalvarez | paulsherwood: we don't have openstack in definitions yet | 10:59 |
| paulsherwood | is kvm enabled in baserock kernels by default? | 10:59 |
| paulsherwood | oh, i thought we did, pedroalvarez | 11:00 |
| richard_maw | paulsherwood: kvm is not enabled by default AFAIK. Container stuff only is because we need it in morph | 11:00 |
| richard_maw | we don't need a full OpenStack to try virtualisation on a Jetson | 11:00 |
| pedroalvarez | kvm is maybe enabled in x86, since we integrated kvm in the past | 11:00 |
| pedroalvarez | paulsherwood: I agree with richard_maw, before testing openstack we could test virtualisation | 11:01 |
| pedroalvarez | since openstack is going to use that anyway | 11:01 |
| paulsherwood | kvm enabled by default in x86, not jetson. i'll try that :) | 11:02 |
| pedroalvarez | paulsherwood: this info may be useful: http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/commit/?h=baserock/markdoffman/virtualization&id=49a0649b8b44b28ee62770e7394c922a6ba7f894 | 11:03 |
| paulsherwood | not the KVM_INTEL flag, i guess :) | 11:06 |
| paulsherwood | thanks | 11:07 |
| pedroalvarez | yeah... maybe another different one is needed | 11:08 |
| pedroalvarez | words... | 11:09 |
| richard_maw | another different one is perfectly valid, just a plain another is ambigous, putting KVM_INTEL twice wouldn't help | 11:15 |
| pedroalvarez | linux$ git checkout master | 11:16 |
| pedroalvarez | Switched to branch 'master' | 11:16 |
| pedroalvarez | Your branch is behind 'origin/master' by 23047 commits, and can be fast-forwarded. | 11:16 |
| pedroalvarez | heheh long time without pulling | 11:16 |
| * paulsherwood sees green http://85.199.252.101 | 11:22 | |
| ssam2 | excellent | 11:32 |
| paulsherwood | assuming i manage to build with KVM etc enabled, what would i try on the resulting system? | 11:37 |
| pedroalvarez | paulsherwood: some of this flag may be needed KVM KVM_ARM_HOST KVM_ARM_VGIC KVM_ARM_TIMER | 11:38 |
| radiofree | paulsherwood: wiki.qemu.org/KVM | 11:38 |
| paulsherwood | shall i add them all? | 11:38 |
| radiofree | try booting a baserock system with kvm | 11:38 |
| paulsherwood | radiofree: once more in dutch, please? | 11:39 |
| paulsherwood | or even better, as commands? :) | 11:39 |
| pedroalvarez | paulsherwood: I thing there is not harm in enabling all of them | 11:39 |
| paulsherwood | sorry - i've never done anyrthing with kvm before | 11:39 |
| pedroalvarez | paulsherwood: I assume you are adding virtaulization stratum to your devel system definition | 11:40 |
| paulsherwood | that would be a good idea too :) | 11:40 |
| radiofree | paulsherwood: qemu-kvm -kernel /boot/zImage -append "root=/dev/sda rootfstype=btrfs rootflags=subvol=systems/default/run init=/sbin/init rw BOOT_IMAGE=/systems/default/kernel" -hda jetson-deploy.raw -vga std | 11:40 |
| radiofree | should do the trick | 11:41 |
| paulsherwood | radiofree: super. do you mean to try that after i've booted, or replace existign boot magic with that? | 11:42 |
| radiofree | boot into your jetson image | 11:42 |
| radiofree | have access to some jetson-deploy.raw image (something you have built before) | 11:43 |
| radiofree | then run that command | 11:43 |
| radiofree | it will just use the kernel in /boot to run the jetson image | 11:43 |
| radiofree | you might have to add arm stuff to the --target-list of qemu though | 11:44 |
| radiofree | (during the build) | 11:44 |
| paulsherwood | ok, we'll see :) | 11:45 |
| paulsherwood | thanks! | 11:45 |
| radiofree | add --target-list=arm-softmmu to the ./configure for qemu | 11:46 |
| * paulsherwood copies the magic somewhere, for fear of losing it forever | 11:47 | |
| radiofree | violeta: how did they deploy go? or are you still building? | 11:52 |
| * paulsherwood wonders if mason could be made to cycle itself into the latest master system periodically (say weekly, at the weekend) | 12:09 | |
| paulsherwood | (along the lines of the cycle script i sent today... would need a convention for system names) | 12:10 |
| ssam2 | that's required for it to be useful, sooner or later | 12:16 |
| richard_maw | it was in the initial spec, but we took that out because it was a headache | 12:16 |
| ssam2 | doing it at the weekend seems a good compromise. After each commit would be better for correctness, but it'd make feedback so slow that the whole thing would be a bit pointless | 12:16 |
| ssam2 | one could always manually trigger a Mason upgrade if something changed that meant one was needed, such as changing the requirements of the bootstrap | 12:17 |
| paulsherwood | i'd prefer the default automatic weekend approach. some excitement for each sunday morning :) | 12:37 |
| petefoth | /join #amethyst | 12:37 |
| paulsherwood | heh | 12:38 |
| richard_maw | paulsherwood: each monday morning please, I'd rather not have it broken over the weekend | 12:49 |
| rjek | It will ruin your Monday mornings :) | 12:50 |
| richard_maw | which are already awful | 12:51 |
| rjek | :) | 12:51 |
| paulsherwood | richard_maw: i strongly prefer sunday, so no surprises monday | 12:51 |
| paulsherwood | or even saturday | 12:52 |
| paulsherwood | but i may be alone on this :) | 12:52 |
| franred | fridays after 7-ish will ruin us the weekend, if you need any other mean idea | 12:56 |
| franred | ;-) | 12:56 |
| * paulsherwood may have to settle for creating his own 'canary' | 12:59 | |
| violeta | radiofree, currently flashing! | 13:07 |
| radiofree | did you extract the new u-boot from the image? | 13:07 |
| violeta | yes | 13:09 |
| radiofree | cool, hopefully should work now! | 13:09 |
| * paulsherwood awaits news of violeta's success | 13:10 | |
| radiofree | is it a genivi image? | 13:10 |
| violeta | I think it's a devel image, but I'm not sure of the implications | 13:10 |
| radiofree | well there will be nothing on there to test the graphics... | 13:11 |
| violeta | hmmm | 13:11 |
| radiofree | i have a precompiled kmscube though, use that | 13:11 |
| violeta | radiofree, what's the difference between a GENIVI and a devel image and how do I build one or the other? | 13:12 |
| radiofree | genivi image has all sorts of stuff on it, but no compiler etc.. i think someone else is currently working on the jetson-genivi image though, so don't worry about it | 13:12 |
| radiofree | as long as kmscube works, then your work will be good to integrate into the jetson-genivi image | 13:13 |
| radiofree | ah, actually you'll need to compile some stuff, but deal with that when it boots... | 13:13 |
| violeta | uffff | 13:13 |
| radiofree | jjardon: tegra support in libdrm is not longer experimental right? | 13:13 |
| radiofree | violeta: compile some stuff *on the board* | 13:14 |
| radiofree | oh actually you'll need mesa as well | 13:14 |
| radiofree | compile it all on the board though, shouldn't take too long | 13:15 |
| *** paulsherwood [~paulsherw@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 250 seconds] | 13:17 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 260 seconds] | 13:18 | |
| *** paulsherwood [~paulsherw@access.ducie-dc1.codethink.co.uk] has joined #baserock | 13:18 | |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 272 seconds] | 13:18 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has joined #baserock | 13:18 | |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 13:18 | |
| straycat | The distbuild docs should probably mention that you need to have cloned definitions from the trove that your distbuild cluster uses. | 13:19 |
| *** ctgriffiths_ [~quassel@ec2-54-72-26-210.eu-west-1.compute.amazonaws.com] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] | 13:22 | |
| violeta | Linux baserock-jetson 3.17.0-rc5-00084-gffdbeb8-dirty #1 SMP PREEMPT Tue Sep 30 17:33:19 UTC 2014 armv7l GNU/Linux | 13:24 |
| paulsherwood | w00t! :) | 13:24 |
| violeta | :-) | 13:24 |
| paulsherwood | do you have sata? | 13:24 |
| *** ctgriffiths [~quassel@ec2-54-72-26-210.eu-west-1.compute.amazonaws.com] has joined #baserock | 13:24 | |
| violeta | yes | 13:24 |
| paulsherwood | i suggest you push your work somewhere :) | 13:25 |
| paulsherwood | ideally gbo | 13:25 |
| radiofree | violeta: ok let's test stuff! | 13:25 |
| * paulsherwood loves to see folks excited about testing | 13:27 | |
| radiofree | looks like it worked | 13:32 |
| violeta | :-) | 13:32 |
| pedroalvarez | did it?! | 13:33 |
| pedroalvarez | :) | 13:33 |
| franred | \o/ | 13:34 |
| jjardon | radiofree: no, at least the -enable-experimental-tegra is not there anymore | 13:41 |
| radiofree | jjardon: anymore? | 13:42 |
| jjardon | Its not in current master | 13:43 |
| jjardon | Its there in the version baserock currently uses | 13:43 |
| radiofree | jjardon: that was someone from nvidia's branch of libdrm | 13:44 |
| radiofree | as far as i'm aware the experimental stuff never landed in libdrm master | 13:44 |
| radiofree | and looking at master now, tegra support is *not* there | 13:44 |
| radiofree | for jetson, we'll need a different mesa then? | 13:46 |
| liw | pedroalvarez, did you merge the xfer-hole fix? | 13:46 |
| radiofree | + weston | 13:46 |
| pedroalvarez | I'm about to | 13:46 |
| liw | pedroalvarez, coll, thanks | 13:46 |
| radiofree | i suppose we could apply the patches on top of libdrm master | 13:48 |
| pedroalvarez | liw: xfer-hole fix merged into master of morph.git | 13:50 |
| paulsherwood | radiofree: http://fpaste.org/138534/ | 14:25 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:55 | |
| paulsherwood | radiofree: does that mean i need to frab u-boot? | 14:58 |
| * paulsherwood has been away.... is distbuild fixed? | 15:02 | |
| straycat | No | 15:03 |
| richard_maw | I've got a patch that's in testing before it can be sent for review. | 15:03 |
| paulsherwood | ssam2, SotK - if that's 2 +1s, can cycle be merged? | 15:04 |
| * paulsherwood wonders if anyone has a better name for it | 15:05 | |
| * paulsherwood thought of build-and-deploy... bad.sh :) | 15:05 | |
| pedroalvarez | given that it only works for x86_64, maybe add that to the name | 15:05 |
| paulsherwood | ok. would you accept a patch with two scripts? one for x86, one for jetson? | 15:07 |
| * paulsherwood assumes that it may work for x86_32 | 15:07 | |
| pedroalvarez | I would | 15:08 |
| paulsherwood | maybe SotK's idea is better though - one script, specify both system and cluster | 15:09 |
| * paulsherwood will try that first | 15:09 | |
| paulsherwood | how long does qemu take top build on x86 normally? | 15:11 |
| pedroalvarez | we haven't build that in a while | 15:11 |
| radiofree | paulsherwood: yes, good luck! | 15:13 |
| paulsherwood | heh | 15:13 |
| radiofree | ben or ian should be able to help you with that | 15:13 |
| radiofree | ian got u-boot doing that working for an omap5 at least | 15:13 |
| ssam2 | hooray! I just spent an hour debugging something which turned out to be caused by a temporary hack I put in last night | 15:26 |
| paulsherwood | ouch | 15:27 |
| pedroalvarez | wayland libinput and linux-pam refs are pointing to branches! :/ | 15:33 |
| paulsherwood | any good reason we couldn't have KERNEL_ARGS: vga=788 by default in upgrade-devel.morph? | 15:33 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 15:34 | |
| radiofree | 794 would probably be nicer | 15:35 |
| radiofree | 1280x1024 rather than 800x600 | 15:35 |
| paulsherwood | currently we have nothing. i'm only thinking to save having to futz it if someone wants to cycle devel - genivi and back | 15:36 |
| radiofree | seems sensible | 15:38 |
| paulsherwood | better 794, then? shall we also update the wiki? | 15:39 |
| paulsherwood | and the current occurences of 788? | 15:39 |
| radiofree | most people would ssh into the vm though right? 788 is probably a reasonable value | 15:41 |
| paulsherwood | 2014-10-02 15:39:02 [Build 151/173] [qemu] Elapsed time 01:33:32 | 15:41 |
| paulsherwood | (on jetson) | 15:41 |
| richard_maw | I wonder if it's one of those chunks that doesn't like MAKEFLAGS in the environment | 15:42 |
| paulsherwood | i'm not unhappy... it built. | 15:43 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 15:50 | |
| pedroalvarez | woot! | 15:52 |
| richard_maw | it doesn't look like qemu's doing something that means you can't pass MAKEFLAGS in the environment | 15:52 |
| paulsherwood | is github:Gnurou/nouveau upstream? | 16:03 |
| paulsherwood | is so, can we lorry it? | 16:03 |
| pedroalvarez | oh, I forgot to comment that | 16:05 |
| violeta | I have a commit in delta/u-boot and another one in baserock/definitions (to update the ref for u-boot), how do I send that like a patch? | 16:05 |
| pedroalvarez | paulsherwood: yes, it should be lorried. | 16:06 |
| pedroalvarez | not sure if it's upstream though | 16:06 |
| pedroalvarez | but it has the fix needed | 16:06 |
| pedroalvarez | or the kernel module needed | 16:07 |
| radiofree | violeta: we don't actually need these things for the devel image, though it would be nice to have | 16:07 |
| radiofree | i'm not sure what the procedure is here though | 16:09 |
| violeta | oh | 16:09 |
| violeta | can anyone else help? :-) | 16:09 |
| radiofree | create a new baserock/arm/tegra-uboot-btrfs-2 branch? | 16:09 |
| radiofree | then submit a patch to the mailing list to update the jetson devel bsp to use HEAD there? | 16:10 |
| ssam2 | violeta: I'd be happy if you just submit the patch to delta/u-boot | 16:10 |
| ssam2 | and note that definitions.git will need to be updated by whoever merges it | 16:10 |
| ssam2 | it's just too much work and too much pointless email otherwise | 16:11 |
| violeta | ok | 16:11 |
| violeta | and we don't need the cluster for jetson rawdisk deployment? | 16:12 |
| radiofree | violeta: i'm going to -1 your patches btw | 16:12 |
| radiofree | we don't want to use that kernel in a developement image | 16:12 |
| violeta | ok | 16:12 |
| violeta | xD | 16:12 |
| radiofree | actually let me test building the kernel on it first | 16:12 |
| radiofree | i think the whole board is running slow, so it's not useful for a devel image | 16:12 |
| radiofree | upgrading u-boot is fine | 16:12 |
| pedroalvarez | radiofree: so the kernel upgrade is only useful for genivi-baeline in jetson? | 16:13 |
| radiofree | pedroalvarez: yes | 16:13 |
| pedroalvarez | erm.. | 16:14 |
| pedroalvarez | we need them 2 bsp for jetson | 16:14 |
| radiofree | isn't it common to have devel bsp and genivi bsps files? | 16:14 |
| radiofree | apparently not | 16:15 |
| radiofree | yeah, you'll need a new bsp-jetson-genivi then | 16:15 |
| radiofree | ssam2: the u-boot here is from u-boot-tegra not u-boot master | 16:17 |
| radiofree | the current u-boot used for the jetson is from nvidia | 16:17 |
| violeta | pedroalvarez, do I have to send a v2 PATCH without the lines you want? | 16:20 |
| pedroalvarez | no, is ok if you remove them during the merge | 16:20 |
| paulsherwood | i suggest leave default kernel in our master for jetson systems, demo upgrading it for GENIVI demo and baseline systems | 16:20 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:21 | |
| paulsherwood | but maybe tht doesn't work with all this wayland + u-boot gubbins | 16:21 |
| pedroalvarez | paulsherwood: afaiui genivi baseline needs a kernel update + some drm fixes | 16:22 |
| radiofree | paulsherwood: we can use this new u-boot for our devel systems | 16:22 |
| radiofree | once that's on we'll be able to upgrade it to the genivi baseline with the new kernel | 16:22 |
| radiofree | violeta: i'd prefer you sent a V2 patch, just to be on the safe side | 16:23 |
| radiofree | there's a lot of changes in there that will make a devel system slooooooow | 16:23 |
| radiofree | i think anyway... i'm copying a kernel tree over now, will see if it is slow | 16:24 |
| violeta | ok | 16:25 |
| radiofree | actually, no, just don't use it for the devel system... | 16:26 |
| paulsherwood | ok | 16:29 |
| paulsherwood | violeta: great work, never mind the -1 :) | 16:31 |
| violeta | radiofree, actually I'm missing something from my patch :-S | 16:32 |
| violeta | I forgot to point to my linux kernel branch, where all the commits from Daniel's branch are | 16:33 |
| violeta | but I didn't do any other changes, only cherrypicked his branch | 16:33 |
| paulsherwood | keep going :) | 16:34 |
| violeta | so should I send that for revision too or... ? ehm | 16:34 |
| violeta | paulsherwood, thanks :-) | 16:34 |
| pedroalvarez | violeta: I'm going to create baserock/jetson/3.17.0-rc branch in linux based in your branch, is that ok? | 16:36 |
| pedroalvarez | s/rc/rc5/ | 16:36 |
| violeta | pedroalvarez, if that's what danielsilverstone/jetson-genivi has in it, then yes | 16:36 |
| violeta | but there are probably other changes | 16:37 |
| violeta | radiofree, ^^ ? | 16:37 |
| pedroalvarez | violeta: actually I used baserock/violetamenendez/nouveau-jetson | 16:37 |
| violeta | pedroalvarez, then yes :-) | 16:37 |
| radiofree | it's not really a 3.17 kernel anymore, it's more like a 3.18! | 16:37 |
| pedroalvarez | but is not 3.18, no? | 16:38 |
| radiofree | no it's not, its base is 3.17-rc5 | 16:38 |
| radiofree | so call it that i suppose | 16:38 |
| pedroalvarez | we will change that soon | 16:38 |
| radiofree | i didn't say it wasn't great work! I just -1ed it because it shouldn't be used in the devel image! | 16:39 |
| radiofree | it's a pity adnans btrfs patches didn't get upstreamed | 16:39 |
| violeta | radiofree, haha, don't worry, I didn't feel bad about the -1 :-) | 16:40 |
| richard_maw | adnan tried; he was onto the 6th version of the series before he stopped trying | 16:41 |
| radiofree | richard_maw: he got up to 15 actually :) | 16:42 |
| richard_maw | bloody hell | 16:42 |
| radiofree | needs reworking now though | 16:42 |
| richard_maw | distbuild patches sent for review | 16:43 |
| pedroalvarez | woot! distbuild is getting fixed! | 16:45 |
| violeta | should I send a v2 patch without the lines and the proper references for the kernel? even if it's going to get -1? | 16:46 |
| radiofree | nah, just send a patch to upgrade u-boot | 16:47 |
| violeta | and that's my delta/u-boot change + a comment to change the references when merging? or should I send my baserock/definitions too? (I added a cluster for jetson image deploy too, but not sure if it should go with this) | 16:49 |
| radiofree | you don't need to touch the upgrade cluster now there's not going to be a kernel upgrade | 16:52 |
| violeta | no, but for flashing u-boot I added an image cluster, I guess I don't need to add that | 16:52 |
| radiofree | i don't know what the procedure is on adding deployment clusters, i'd find it useful to have one in there | 16:54 |
| pedroalvarez | yeah, one in clusters/release.morph for a jetson devel system would be great | 16:54 |
| * pedroalvarez needs to merge this: http://pastebin.com/umnSjTCQ | 16:59 | |
| radiofree | +2 | 17:00 |
| straycat | I don't know what that it is, but it looks syntactically fine. | 17:00 |
| pedroalvarez | thanks guys :) | 17:01 |
| pedroalvarez | lorried | 17:01 |
| violeta | ehm... | 17:02 |
| pedroalvarez | violeta: :) | 17:02 |
| violeta | not that | 17:02 |
| violeta | I'm having problems with send-email | 17:02 |
| violeta | :-S | 17:03 |
| pedroalvarez | hmm | 17:03 |
| pedroalvarez | what's the error? | 17:03 |
| violeta | ssam2, helped me, thanks | 17:06 |
| violeta | and sorry for sending an extra email | 17:06 |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:13 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:15 | |
| * ssam2 wins at evil shell quoting | 17:16 | |
| ssam2 | `bundle exec sh -c '(cd '"'"'/home/shared/baserock/morph/import test'"'"'; exec python ./main.py omnibus /home/shared/baserock/omnibus-chef chefdk chefdk --log=/dev/stdout --log-level=debug)'` | 17:16 |
| ssam2 | I never knew you could do `echo '"''"'foo'"''"'` | 17:17 |
| ssam2 | I never wanted to, either | 17:17 |
| pedroalvarez | thats useful when you do things like `su user -c ssh command` | 17:23 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:03 | |
| jjardon | mmm, I do not think we need a special libdrm for the jetson board; I think it has a GK20 gpu inside? | 18:44 |
| * straycat taps gbo impatiently | 18:49 | |
| jjardon | I though the graphics support for GK20 it's built atop the Nouveau driver, not the Tegra one ? | 18:51 |
| jjardon | mmm, looking at https://github.com/Gnurou/tegra-nouveau-rootfs seems a special libdrm is necessary, nevermind | 18:56 |
| straycat | looks like gbo is down for some reason | 19:06 |
| straycat | No it's fine, my connection screwed up is all. | 19:11 |
| jjardon | pedroalvarez: Id put that repo inside a namespace ( like Gnurou/nouveau), as that one is not the upstream nouveau repo | 20:04 |
| jjardon | (and hopefully will be obsolete soon when all the stuff gets merged ustream) | 20:05 |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 21:39 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!