IRC logs for #baserock for Thursday, 2014-10-02

petefothSo, CP/M in BAserock?
*** tiagogomes [~tiagogome@] has joined #baserock07:39
*** dutch [] has joined #baserock07:49
paulsherwoodrichard_maw: it's not clear from your comments, does your series fix distbuild?07:55
paulsherwoodfranred: please can you merge the bash update?07:56
paulsherwood(+3 should be more than enough)07:57
franredpaulsherwood, sure07:57
paulsherwoodare we near to gerrit yet? :)07:57
pedroalvarezpetefoth: CP/M?07:59
petefothpedroalvarez: an OS for microcomputers that predated DOS08:01
pedroalvarezpaulsherwood: hey! I like your cript, but I think we could do with a better name :/08:01
petefothIt ran the first computer I owned, an Amstrad PCW08:01
pedroalvarezI had to use DOS yesterday... after many years08:06
pedroalvarezhmm.. also the script could be improved to work also in jetsons08:08
pedroalvarezbut for now I think it's ok08:09
franredpaulsherwood, gerrit was handover to a another team and they are working on the configuration part08:11
paulsherwoodpedroalvarez: i would like it to work on jetsons... but i need help from experts to achieve that.08:12
paulsherwoodit seems clunky to have to have separate upgrade-foo.morph clusters08:14
SotKpaulsherwood: the jetson needs different kernel args in its upgrade cluster though08:14
pedroalvarezpaulsherwood: yeah, having only one could be possible08:14
pedroalvarezSotK: a cluster morphology with various deployments defined08:14
SotKpedroalvarez: I was just typing that exact suggestion :)08:15
SotKhowever, the "self.HOSTNAME" and "self.VERSION_LABEL" bits would need to change since we couldn't have every deployment called "self"08:16
paulsherwoodwhy can't the kernel args be with the system, not the cluster?08:17
paulsherwoodand then we have one upgrade.morph for self08:18
* SotK lacks the knowledge to answer that08:21
SotKthere are other things needed by the jetson in its upgrade cluster too though08:22
paulsherwoodplease 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 better08:24
pedroalvarezthe 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 doesn't deeply understand this.08:25
* paulsherwood just wants a simple workflow :)08:25
paulsherwoodnote 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 repeat08:27
paulsherwood(on x86 and cloud)08:27
pedroalvarezpaulsherwood: works in the cloud?08:28
* pedroalvarez wonders if his patch landed08:28
* paulsherwood used the uuid patch, if that's what pedroalvarez means08:28
* SotK updates morph and has to rebuild the world :(08:28
paulsherwoodSotK: why do that?08:29
pedroalvarezpaulsherwood: that's what I meant :) 08:31
SotKbecause 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
paulsherwoodpedroalvarez: i've +1 that patch, so can merge08:32
paulsherwood(if you trust my +1) :-)08:32
pedroalvarezoh! does it already have +2?08:32
paulsherwoodrichard_maw + paulsherwood = +2 i think08:33
* pedroalvarez is really going to enjoy gerrit08:33
* paulsherwood too08:33
paulsherwoodi'll be even happier when mason is building and publishing latest morph, latest artifacts all the time08:34
* franred really wants to have an auto-tester which votes in gerrit 08:34
paulsherwoodcan we get it done today? :)08:34
pedroalvarezhahahah we have paulsherwood  for that08:34
* paulsherwood is not entirely kidding08:34
*** jonathanmaw [] has joined #baserock08:35
* pedroalvarez is going to think about it in its spare brain time08:36
petefothCould 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
petefothAnd then add tests for upgrading08:39
paulsherwoodyes we could08:39
pedroalvarezafter a quick converstaion with franred seems we have to integrate more software to make the gerrit testing happens08:40
paulsherwoodhow much more?08:40
petefothso we could put gerrit in place witout and autotester, then add the autotester when we've integrated whatever else we need?08:41
petefothOr we could wait unitl everything is finished before we start using Gerrit :)08:41
franredpaulsherwood, we want to use zuul and turbo-hipster to to the build and testing part for voting in the autotest, AFAIK08:42
franrednot sure how difficult will use Firehose/mason for testing branches in one shot and return +1/-108:43
franredpetefoth, the idea is use Gerrit first and then integrate the other parts step by step. Gerrit can live by itself08:44
paulsherwoodcan we use gerrit on its own first? would adding the test stuff later be harder?08:44
petefothfranred: great! Can I have StoryBoard after Gerrit too please?08:44
paulsherwoodstoryboard is happening08:45
franredpetefoth, Im not the guy in charge of that anymore08:45
petefothfranred: paulsherwood: I know, I'm just impatient :)08:46
paulsherwoodme too :)08:46
franredpaulsherwood, 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 clashes08:46
jjardonpetefoth: what's the storyboard for?08:49
petefothjjardon: Tracking issues, new and changed requirements and features. PLus a linked Kanban view08:50
petefothjjardon: OpenStack are startign to use instead of blueprints, though In don'g think they are using it for tracking issues and bugs08:52
straycatpaulsherwood, 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
jjardonOh, 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 today08:55
paulsherwoodjjardon: we don't quite have storyboard setup for baserock yet08:56
jjardonI know, I mean the webpage of the storyboard software. I assume is a independent project like gerrit?08:57
*** ssam2 [] has joined #baserock08:58
ssam2Mason is broken in a very exciting new way09:01
ssam2'413 - Request Entity Too Large' while annotating the build graph09:01
paulsherwoodssam2: revert the bash patch?09:02
petefothjjardon: and fior documentation :)09:02
paulsherwoodactually, we have 2 masons. when did the other one break?09:02
ssam2'Update morph to include per-source building changes'09:03
ssam2but that wouldn't affect the Morph running inside the Mason09:04
paulsherwoodthis is exciting indeed09:04
ssam2I think it's some message size limit that's randomly being exceeded now09:04
ssam2possibly a limit Bottle sets on the size of the 'artifacts' query to morph-cache-server09:05
jjardonpaulsherwood: petefoth thanks for the links, looks promising indeed09:06
ssam2i'll have a poke and see09:06
ssam2the Trove that the Mason is using has no free disk space09:13
ssam2that could be part of the problem09:13
ssam2hardly unexpected since Mason is continuously uploading artifacts there ;)09:13
* ssam2 deletes /home/cache/artifacts/*devel-system*09:14
*** franred [] has quit [Ping timeout: 260 seconds]09:14
jjardonI'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
ssam2the 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
ssam2jjardon: I'm not sold on the idea of 'compilers' stratum09:19
ssam2but reducing the amount of times I have to build LLVM is definitely welcome09:19
ssam2really we should only be using one C compiler in Baserock, I think09:19
ssam2but I guess that's not really achievable09:20
*** franred [] has joined #baserock09:21
jjardonMe neither, the main advantage of the patch is to avoid rebuilds really09:23
ssam2cool, well it sounds good anyway09:25
jjardonBTW, IIRC llvm is not the compiler, that would be clang, that has llvm as dependency09:25
ssam2good point09:25
jmacs"clang" is the name of the binary you invoke to compile C compilers, but llvm is still the compiler09:50
rjekjmacs: They're compile compilers aren't they?09:53
rjekclang translates C to LLVM bitcode, LLVM translates LLVM bitcode to native code?09:53
richard_mawAIUI clang is the C frontend, which turns it into an IR, and llvm turns that into code09:53
richard_mawrjek: snap09:53
jmacsYes, I wouldn't call clang a compiler09:53
rjekrichard_maw: Not only an IR, but something you can run directly with a VM or JIT.09:54
rjekSo conceptually it's in the same place as javac.09:54
straycatrichard_maw, The comment in about add_dependencies doesn't apply anymore does it?10:00
richard_mawstraycat: let me go check which comment this is, please hold10:07
richard_mawstraycat: yep, they should go10:08
paulsherwooddoes morph gc remove artifacts?10:08
paulsherwoodssam2, richard_maw ^^10:08
paulsherwoodassuming so, should mason run morph gc?10:08
richard_mawpaulsherwood: we discussed this IRL. AIUI mason does run morph gc10:09
* paulsherwood waits10:10
richard_mawthe 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 gc10:10
paulsherwoodwould morph gc on morph-cache-server do the right thing?10:12
paulsherwoodssam2: it is not clear that deleting artifacts has helped.... are you confident it did?10:14
richard_mawpaulsherwood: not currently, as the cache server doesn't update mtimes of artifacts it serves10:14
richard_mawthe repository format _may_ be compatible, but without the mtime updating, they'll be cleaned up in insertion order, rather than least-recently-used10:15
paulsherwoodrichard_maw: that would still be better than falling over in a heap?10:15
* paulsherwood may be wrong, as usual10:16
richard_mawit 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 versions10:19
ssam2paulsherwood: the continual failures on the masons have stopped10:20
ssam2so I assume it's in the process of building something10:20
ssam2I'm trying to hack together a quick 'trove-gc' script, which just runs 'morph gc' with appropriate config10:20
ssam2for the Mason artifact cache servers, that'll be fine. On we'll not want to ever run that, because it'll remove release artifacts.10:21
paulsherwoodssam2: i'm imagining that in future has a mason/firehose (or maybe it's with a rolling pool of 'current' artifacts, separate from whatever we call releases10:27
ssam2that'd make sense10:28
ssam2all we'd need is a way to mark to the trove-gc script "don't delete these ones!"10:29
ssam2we could achieve that today, in fact, as persia suggested a few weeks ago10:29
richard_mawor 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 mason10:29
ssam2we could set up '' to point to and have morph's 'artifact-cache-server' setting default to artifacts.baserock.org10:30
ssam2I suppose then we'd not have the release artifacts available by default any more10:30
ssam2if Morph supported a list of multiple artifact cache servers it'd work, I guess, but it doesn't right now10:31
paulsherwoodi like the 'today' idea :)10:32
violetaradiofree, what should be the DISK_SIZE for the Baserock image?10:32
radiofree3G is reasonable10:32
richard_mawI usually put 4G, so I have room for a few upgrades10:32
radiofreeis this a devel image or a genivi one?10:32
violetaradiofree, ehm, devel AFAICT10:33
ssam2to be clear, the 'today' idea was to set up an '' redirect to and change morph's default artifact cache server10:33
radiofreeput 4G then10:33
ssam2if 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 anyway10:33
paulsherwoodi'm ok with that so long as we are confident in reproducibility. which i believe we are, now?10:35
paulsherwoodssam2: i'm still liking the 'today' idea10:36
pedroalvarezssam2: but you have to download baserock to be able to use morph, so we need to release something10:36
radiofreevioleta: do the flashing on your laptop btw, not in a vm10:37
violetaradiofree, yes, I learnt that lesson the hard way :-P10:37
radiofreeyou could actually use baserock to upgrade your jetson, then only flash the new u-boot with
radiofreebut just try flashing it first!10:39
radiofreefor testing it's generally much easier just cross-compile u-boot and use those scripts10:39
ssam2pedroalvarez: yeah, but that 'something' could be the latest devel system that the Mason built10:40
paulsherwoodpedroalvarez: currently yes. soon, maybe not :)10:40
violetacould I have just built u-boot?10:40
radiofreevioleta: for what you're trying to do? no, you need all of this stuff to get the graphics working with 3.1710:41
radiofreeis the goal to have something to show in git for this?10:41
radiofreei suppose it needs to be done the baserock way, for a baserock demo10:42
paulsherwoodpedroalvarez: have we tried openstack on jetsons? or is this a dumb question?10:53
pedroalvarezthe question is: do the jetson support virtualization?10:54
paulsherwoodA15.. bound to? :)10:54
pedroalvarezpaulsherwood: so the answer is no, we haven't tried10:57
pedroalvarezto me is not a dumb question10:57
pedroalvarezI also wondered the same in the past10:58
paulsherwoodis it just a matter of adding some strata to a jetson distbuild system?10:58
richard_mawand ensuring we've enabled kvm in the kernel10:58
* paulsherwood has a jetson, as regular readers may know :)10:58
paulsherwoodno need for modules and such?10:59
pedroalvarezpaulsherwood: we don't have openstack in definitions yet10:59
paulsherwoodis kvm enabled in baserock kernels by default?10:59
paulsherwoodoh, i thought we did, pedroalvarez11:00
richard_mawpaulsherwood: kvm is not enabled by default AFAIK. Container stuff only is because we need it in morph11:00
richard_mawwe don't need a full OpenStack to try virtualisation on a Jetson11:00
pedroalvarezkvm is maybe enabled in x86, since we integrated kvm in the past11:00
pedroalvarezpaulsherwood: I agree with richard_maw, before testing openstack we could test virtualisation11:01
pedroalvarezsince openstack is going to use that anyway11:01
paulsherwoodkvm enabled by default in x86, not jetson. i'll try that :)11:02
pedroalvarezpaulsherwood: this info may be useful:
paulsherwoodnot the KVM_INTEL flag, i guess :)11:06
pedroalvarezyeah... maybe another different one is needed11:08
richard_mawanother different one is perfectly valid, just a plain another is ambigous, putting KVM_INTEL twice wouldn't help11:15
pedroalvarezlinux$ git checkout master11:16
pedroalvarezSwitched to branch 'master'11:16
pedroalvarezYour branch is behind 'origin/master' by 23047 commits, and can be fast-forwarded.11:16
pedroalvarezheheh long time without pulling11:16
* paulsherwood sees green
paulsherwoodassuming i manage to build with KVM etc enabled, what would i try on the resulting system?11:37
pedroalvarezpaulsherwood: some of this flag may be needed KVM KVM_ARM_HOST KVM_ARM_VGIC KVM_ARM_TIMER11:38
paulsherwoodshall i add them all?11:38
radiofreetry booting a baserock system with kvm11:38
paulsherwoodradiofree: once more in dutch, please?11:39
paulsherwoodor even better, as commands? :)11:39
pedroalvarezpaulsherwood: I thing there is not harm in enabling all of them11:39
paulsherwoodsorry - i've never done anyrthing with kvm before11:39
pedroalvarezpaulsherwood: I assume you are adding virtaulization stratum to your devel system definition11:40
paulsherwoodthat would be a good idea too :)11:40
radiofreepaulsherwood: 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 std11:40
radiofreeshould do the trick11:41
paulsherwoodradiofree: super. do you mean to try that after i've booted, or replace existign boot magic with that?11:42
radiofreeboot into your jetson image11:42
radiofreehave access to some jetson-deploy.raw image (something you have built before)11:43
radiofreethen run that command11:43
radiofreeit will just use the kernel in /boot to run the jetson image11:43
radiofreeyou might have to add arm stuff to the --target-list of qemu though11:44
radiofree(during the build)11:44
paulsherwoodok, we'll see :)11:45
radiofreeadd --target-list=arm-softmmu to the ./configure for qemu11:46
* paulsherwood copies the magic somewhere, for fear of losing it forever11:47
radiofreevioleta: 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
ssam2that's required for it to be useful, sooner or later12:16
richard_mawit was in the initial spec, but we took that out because it was a headache12:16
ssam2doing 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 pointless12:16
ssam2one could always manually trigger a Mason upgrade if something changed that meant one was needed, such as changing the requirements of the bootstrap12:17
paulsherwoodi'd prefer the default automatic weekend approach. some excitement for each sunday morning :)12:37
petefoth /join #amethyst12:37
richard_mawpaulsherwood: each monday morning please, I'd rather not have it broken over the weekend12:49
rjekIt will ruin your Monday mornings :)12:50
richard_mawwhich are already awful12:51
paulsherwoodrichard_maw: i strongly prefer sunday, so no surprises monday12:51
paulsherwoodor even saturday12:52
paulsherwoodbut i may be alone on this :)12:52
franredfridays after 7-ish will ruin us the weekend, if you need any other mean idea12:56
* paulsherwood may have to settle for creating his own 'canary'12:59
violetaradiofree, currently flashing!13:07
radiofreedid you extract the new u-boot from the image?13:07
radiofreecool, hopefully should work now!13:09
* paulsherwood awaits news of violeta's success13:10
radiofreeis it a genivi image?13:10
violetaI think it's a devel image, but I'm not sure of the implications13:10
radiofreewell there will be nothing on there to test the graphics...13:11
radiofreei have a precompiled kmscube though, use that13:11
violetaradiofree, what's the difference between a GENIVI and a devel image and how do I build one or the other?13:12
radiofreegenivi 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 it13:12
radiofreeas long as kmscube works, then your work will be good to integrate into the jetson-genivi image13:13
radiofreeah, actually you'll need to compile some stuff, but deal with that when it boots...13:13
radiofreejjardon: tegra support in libdrm is not longer experimental right?13:13
radiofreevioleta: compile some stuff *on the board*13:14
radiofreeoh actually you'll need mesa as well13:14
radiofreecompile it all on the board though, shouldn't take too long13:15
*** paulsherwood [] has quit [Ping timeout: 250 seconds]13:17
*** pdar [] has quit [Ping timeout: 260 seconds]13:18
*** paulsherwood [] has joined #baserock13:18
*** jmacs [] has quit [Ping timeout: 272 seconds]13:18
*** pdar [] has joined #baserock13:18
*** jmacs [] has joined #baserock13:18
straycatThe distbuild docs should probably mention that you need to have cloned definitions from the trove that your distbuild cluster uses.13:19
*** ctgriffiths_ [] has quit [Quit: - Chat comfortably. Anywhere.]13:22
violetaLinux baserock-jetson 3.17.0-rc5-00084-gffdbeb8-dirty #1 SMP PREEMPT Tue Sep 30 17:33:19 UTC 2014 armv7l GNU/Linux13:24
paulsherwoodw00t! :)13:24
paulsherwooddo you have sata?13:24
*** ctgriffiths [] has joined #baserock13:24
paulsherwoodi suggest you push your work somewhere :)13:25
paulsherwoodideally gbo13:25
radiofreevioleta: ok let's test stuff!13:25
* paulsherwood loves to see folks excited about testing13:27
radiofreelooks like it worked13:32
pedroalvarezdid it?!13:33
jjardonradiofree: no, at least the -enable-experimental-tegra is not there anymore13:41
radiofreejjardon: anymore?13:42
jjardonIts not in current master13:43
jjardonIts there in the version baserock currently uses13:43
radiofreejjardon: that was someone from nvidia's branch of libdrm13:44
radiofreeas far as i'm aware the experimental stuff never landed in libdrm master13:44
radiofreeand looking at master now, tegra support is *not* there13:44
radiofreefor jetson, we'll need a different mesa then?13:46
liwpedroalvarez, did you merge the xfer-hole fix?13:46
radiofree+ weston13:46
pedroalvarezI'm about to13:46
liwpedroalvarez, coll, thanks13:46
radiofreei suppose we could apply the patches on top of libdrm master13:48
pedroalvarezliw: xfer-hole fix merged into master of morph.git13:50
*** genii [~quassel@ubuntu/member/genii] has joined #baserock14:55
paulsherwoodradiofree: does that mean i need to frab u-boot?14:58
* paulsherwood has been away.... is distbuild fixed?15:02
richard_mawI've got a patch that's in testing before it can be sent for review.15:03
paulsherwoodssam2, SotK - if that's 2 +1s, can cycle be merged?15:04
* paulsherwood wonders if anyone has a better name for it15:05
* paulsherwood thought of build-and-deploy... :)15:05
pedroalvarezgiven that it only works for x86_64, maybe add that to the name15:05
paulsherwoodok. would you accept a patch with two scripts? one for x86, one for jetson?15:07
* paulsherwood assumes that it may work for x86_3215:07
pedroalvarezI would15:08
paulsherwoodmaybe SotK's idea is better though - one script, specify both system and cluster15:09
* paulsherwood will try that first15:09
paulsherwoodhow long does qemu take top build on x86 normally?15:11
pedroalvarezwe haven't build that in a while15:11
radiofreepaulsherwood: yes, good luck!15:13
radiofreeben or ian should be able to help you with that15:13
radiofreeian got u-boot doing that working for an omap5 at least15:13
ssam2hooray! I just spent an hour debugging something which turned out to be caused by a temporary hack I put in last night15:26
pedroalvarezwayland libinput and linux-pam refs are pointing to branches! :/15:33
paulsherwoodany good reason we couldn't have KERNEL_ARGS: vga=788 by default in upgrade-devel.morph?15:33
*** CTtpollard [] has quit [Remote host closed the connection]15:34
radiofree794 would probably be nicer15:35
radiofree1280x1024 rather than 800x60015:35
paulsherwoodcurrently we have nothing. i'm only thinking to save having to futz it if someone wants to cycle devel - genivi and back15:36
radiofreeseems sensible15:38
paulsherwoodbetter 794, then? shall we also update the wiki?15:39
paulsherwoodand the current occurences of 788?15:39
radiofreemost people would ssh into the vm though right? 788 is probably a reasonable value15:41
paulsherwood2014-10-02 15:39:02 [Build 151/173] [qemu] Elapsed time 01:33:3215:41
paulsherwood(on jetson)15:41
richard_mawI wonder if it's one of those chunks that doesn't like MAKEFLAGS in the environment15:42
paulsherwoodi'm not unhappy... it built.15:43
*** tiagogomes [~tiagogome@] has quit [Quit: Leaving]15:50
richard_mawit doesn't look like qemu's doing something that means you can't pass MAKEFLAGS in the environment15:52
paulsherwoodis github:Gnurou/nouveau upstream?16:03
paulsherwoodis so, can we lorry it?16:03
pedroalvarezoh, I forgot to comment that16:05
violetaI 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
pedroalvarezpaulsherwood: yes, it should be lorried.16:06
pedroalvareznot sure if it's upstream though16:06
pedroalvarezbut it has the fix needed16:06
pedroalvarezor the kernel module needed16:07
radiofreevioleta: we don't actually need these things for the devel image, though it would be nice to have16:07
radiofreei'm not sure what the procedure is here though16:09
violetacan anyone else help? :-)16:09
radiofreecreate a new baserock/arm/tegra-uboot-btrfs-2 branch?16:09
radiofreethen submit a patch to the mailing list to update the jetson devel bsp to use HEAD there?16:10
ssam2violeta: I'd be happy if you just submit the patch to delta/u-boot16:10
ssam2and note that definitions.git will need to be updated by whoever merges it16:10
ssam2it's just too much work and too much pointless email otherwise16:11
violetaand we don't need the cluster for jetson rawdisk deployment?16:12
radiofreevioleta: i'm going to -1 your patches btw16:12
radiofreewe don't want to use that kernel in a developement image16:12
radiofreeactually let me test building the kernel on it first16:12
radiofreei think the whole board is running slow, so it's not useful for a devel image16:12
radiofreeupgrading u-boot is fine16:12
pedroalvarezradiofree: so the kernel upgrade is only useful for genivi-baeline in jetson?16:13
radiofreepedroalvarez: yes16:13
pedroalvarezwe need them 2 bsp for jetson16:14
radiofreeisn't it common to have devel bsp and genivi bsps files?16:14
radiofreeapparently not16:15
radiofreeyeah, you'll need a new bsp-jetson-genivi then16:15
radiofreessam2: the u-boot here is from u-boot-tegra not u-boot master16:17
radiofreethe current u-boot used for the jetson is from nvidia16:17
violetapedroalvarez, do I have to send a v2 PATCH without the lines you want?16:20
pedroalvarezno, is ok if you remove them during the merge16:20
paulsherwoodi suggest leave default kernel in our master for jetson systems, demo upgrading it for GENIVI demo and baseline systems16:20
*** jonathanmaw [] has quit [Quit: Leaving]16:21
paulsherwoodbut maybe tht doesn't work with all this wayland + u-boot gubbins16:21
pedroalvarezpaulsherwood: afaiui genivi baseline needs a kernel update + some drm fixes16:22
radiofreepaulsherwood: we can use this new u-boot for our devel systems16:22
radiofreeonce that's on we'll be able to upgrade it to the genivi baseline with the new kernel16:22
radiofreevioleta: i'd prefer you sent a V2 patch, just to be on the safe side16:23
radiofreethere's a lot of changes in there that will make a devel system slooooooow16:23
radiofreei think anyway... i'm copying a kernel tree over now, will see if it is slow16:24
radiofreeactually, no, just don't use it for the devel system...16:26
paulsherwoodvioleta: great work, never mind the -1 :)16:31
violetaradiofree, actually I'm missing something from my patch :-S16:32
violetaI forgot to point to my linux kernel branch, where all the commits from Daniel's branch are16:33
violetabut I didn't do any other changes, only cherrypicked his branch16:33
paulsherwoodkeep going :)16:34
violetaso should I send that for revision too or... ? ehm16:34
violetapaulsherwood, thanks :-)16:34
pedroalvarezvioleta: I'm going to create baserock/jetson/3.17.0-rc branch in linux based in your branch, is that ok?16:36
violetapedroalvarez, if that's what danielsilverstone/jetson-genivi has in it, then yes16:36
violetabut there are probably other changes16:37
violetaradiofree, ^^ ?16:37
pedroalvarezvioleta: actually I used baserock/violetamenendez/nouveau-jetson16:37
violetapedroalvarez, then yes :-)16:37
radiofreeit's not really a 3.17 kernel anymore, it's more like a 3.18!16:37
pedroalvarezbut is not 3.18, no?16:38
radiofreeno it's not, its base is 3.17-rc516:38
radiofreeso call it that i suppose16:38
pedroalvarezwe will change that soon16:38
radiofreei didn't say it wasn't great work! I just -1ed it because it shouldn't be used in the devel image!16:39
radiofreeit's a pity adnans btrfs patches didn't get upstreamed16:39
violetaradiofree, haha, don't worry, I didn't feel bad about the -1 :-)16:40
richard_mawadnan tried; he was onto the 6th version of the series before he stopped trying16:41
radiofreerichard_maw: he got up to 15 actually :)16:42
richard_mawbloody hell16:42
radiofreeneeds reworking now though16:42
richard_mawdistbuild patches sent for review16:43
pedroalvarezwoot! distbuild is getting fixed!16:45
violetashould 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
radiofreenah, just send a patch to upgrade u-boot16:47
violetaand 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
radiofreeyou don't need to touch the upgrade cluster now there's not going to be a kernel upgrade16:52
violetano, but for flashing u-boot I added an image cluster, I guess I don't need to add that16:52
radiofreei don't know what the procedure is on adding deployment clusters, i'd find it useful to have one in there16:54
pedroalvarezyeah, one in clusters/release.morph for a jetson devel system would be great16:54
* pedroalvarez needs to merge this:
straycatI don't know what that it is, but it looks syntactically fine.17:00
pedroalvarezthanks guys :)17:01
pedroalvarezvioleta: :)17:02
violetanot that17:02
violetaI'm having problems with send-email17:02
pedroalvarezwhat's the error?17:03
violetassam2, helped me, thanks17:06
violetaand sorry for sending an extra email17:06
*** dutch [] has quit [Quit: Quit]17:13
*** franred [] has quit [Quit: Leaving]17:15
* ssam2 wins at evil shell quoting17:16
ssam2`bundle exec sh -c '(cd '"'"'/home/shared/baserock/morph/import test'"'"'; exec python ./ omnibus /home/shared/baserock/omnibus-chef chefdk chefdk --log=/dev/stdout --log-level=debug)'`17:16
ssam2I never knew you could do `echo '"''"'foo'"''"'`17:17
ssam2I never wanted to, either17:17
pedroalvarezthats useful when you do things like `su user -c ssh command`17:23
*** ssam2 [] has quit [Remote host closed the connection]18:03
jjardonmmm, 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 impatiently18:49
jjardonI though the graphics support for GK20 it's built atop the Nouveau driver, not the Tegra one ?18:51
jjardonmmm, looking at seems a special libdrm is necessary, nevermind18:56
straycatlooks like gbo is down for some reason19:06
straycatNo it's fine, my connection screwed up is all.19:11
jjardonpedroalvarez: Id put that repo inside a namespace ( like Gnurou/nouveau), as that one is not the upstream nouveau repo20: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 2.14.0 by Marius Gedminas - find it at!