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

*** ratmice_________ [] has joined #baserock02:14
*** ridgerunner [] has joined #baserock02:14
*** ridgerun1er [] has quit [Ping timeout: 258 seconds]02:14
*** ratmice________ [] has quit [Ping timeout: 258 seconds]02:14
*** cyndis_ [] has joined #baserock04:06
*** petefoth2 [] has joined #baserock04:09
*** radiofree_ [radiofree@unaffiliated/radiofree] has joined #baserock04:10
*** br_logge1 [~ubuntu@] has joined #baserock04:11
*** cyndis [] has quit [Ping timeout: 272 seconds]04:11
*** petefoth1 [] has quit [Ping timeout: 272 seconds]04:11
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 272 seconds]04:11
*** br_logger [~ubuntu@] has quit [Ping timeout: 272 seconds]04:11
*** thecorconian [] has quit [Remote host closed the connection]05:33
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock05:38
*** robtaylor [] has quit [Ping timeout: 245 seconds]07:39
persiaI think a lot of older lorries happen from tarball because it was easier on the day it was written, and especially for some of the lower-level stuff, nobody was really using morph much yet, so some of the things that we consider normal now were still new and odd.08:19
*** wdutch [] has joined #baserock08:25
*** tiagogomes [~tiagogome@] has joined #baserock08:43
aananthpedroalvarez: today I corrected my mistakes and I am able to add proxy configurations to lorry. But still the trove does not sync with Log:
* paulsher1ood fails to build alinux-pam08:45
persiaThat apparently build-depends on a provider of file(1)08:52
persiaRLIMIT_NOFILE should be declared in /usr/include/x86_64-linux-gnu/sys/resource.h: can you inspect the staging area to confirm this?08:56
aananthWhat does "GitanoCommandFailure: Failed to run "ls" on Gitano on" mean?08:57
persiaI suspect it means that the gitano on was unable to provide some listing.  Were there any surrounding errors?09:01
paulsher1oodit may be that needs to have a key added for aananth's trove - but i thought there was a way to be downstream of gbo without that?09:05
*** jonathanmaw [] has joined #baserock09:06
persiaThere certainly was, but I also thought gitano provided some info via http unauthenticated as well.09:06
SotKit is indeed possible to use a trove mirroring g.b.o over http09:06
* persia still worries about this concept of upstream/downstream troves, as it reduces the horizon of trust for any code09:07
*** mariaderidder [] has joined #baserock09:07
pedroalvarezpaulsher1ood: re linux-pam. I'm fixing it atm09:13
paulsher1oodaananth: is your trove configured to mirror using http by default?09:13
paulsher1oodpedroalvarez: aha :-)09:13
SotKaananth: can you show us what in /home/lorry/webapp.log at that point?09:14
pedroalvarezacutally I found the soultion yesterday evening09:14
pedroalvarezto fix it first of all I have to update the linux-pam version:
pedroalvarez(I can also fix it just appying a patch as I did in the baserock/Linux-PAM-1.1.5 branch, but I think is better to upgrade the component)09:19
aananthSotK: Here is the log
pedroalvarezaha, so it's using http for the ls09:24
aananthpaulsherlood: Yes, the protocol is configured for http. I have pasted my config in I could be wrong.09:27
paulsher1oodpedroalvarez: isn't there a git repo for linux-pam?09:28
aananthpersia: You can look for other errors in
pedroalvarezpaulsher1ood: there is, but the build fails and I couldn't figure out why.09:29
paulsher1oodand you're in a rush :-)09:30
paulsher1oodpedroalvarez: let's lorry the git repo too? but +1 on getting later tarball version09:31
Kinnisonaananth: the critical error you're looking for is: <urlopen error [Errno -2] Name or service not known>09:32
Kinnisonaananth: the lorry controller cannot resolve git.baserock.org09:32
pedroalvarezKinnison: he is using a proxy, (just for context)09:32
KinnisonAnd proxy.conf is configured appropriately?09:33
SotKaananth: have you set up proxy.conf in the lorry-controller config repository?09:33
KinnisonCould you paste proxy.conf for me?09:33
* Kinnison will just double-check it against what l-c is expecting09:34
aananthKinnison, SotK: Please find my proxy conf 09:36
Kinnisonport *may* need to be a string09:36
KinnisonNot certain, python might interpolate integers into %s okay09:37
aananthKinnison: I think the problem is with the DNS. Let me work on that. Also try changing the port to string. Thanks.09:37
aananthmy resolv.conf is in
* Kinnison nods. I don't see what it would be resolving if it's meant to go via an IP-based proxy though09:44
Kinnisonvery odd09:44
Kinnisonaaaah I think I may have found something09:45
Kinnisonaananth: Could you try restarting the lorry controller webapp service09:45
* Kinnison will find you the command, one sec09:46
Kinnisonsystemctl restart lighttpd-lorry-controller-webapp.service09:47
pedroalvarezI apologise for the Author used in the latest 2 commits in definitions... Just realised..09:49
* Kinnison tuts09:51
aananthKinnison: I restarted, here is the log
KinnisonIn a little while it'll ls-troves again09:52
Kinnisonwhen that happens, we'll need to see how it does09:52
pedroalvarezI'm really sorry, my brain wasn't really ok yesterday..09:54
*** franred [] has joined #baserock09:54
KinnisonWe'll forgive you... this time :-)09:54
KinnisonWell, I will09:54
Kinnisondunno if richard_maw will09:54
* persia wants robots involved in the merge decision loop: humans are prone to frailty09:55
* SotK is working on it :)09:55
richard_mawpedroalvarez: you can push some git notes to say who the actual author was!10:00
*** Krin [] has joined #baserock10:00
pedroalvarezrichard_maw: can the notes be pushed, and modified, and removed without changing the commits sha1?10:04
richard_mawthat is their purpose, but they're opt-in and can't affect the trees, so they're safer than git-replace10:05
richard_mawthey only affect the log messages10:05
pedroalvarezI'll create a note for both commits with the real author then10:05
franredhow can I free space in /tmp to be able to build or run check --full in morph ?10:11
richard_mawfranred: `rm -rf /tmp/tmp*` usually works10:12
richard_mawif you update your version of cmdtest the new version uses less space10:12
richard_mawplus you could set `TMPDIR=/src2/tmp ./check --full`10:12
*** jonathanmaw [] has quit [Ping timeout: 244 seconds]10:13
franredrichard_maw, cheers10:14
* pedroalvarez has pushed the commit notes :)10:14
richard_mawLooks to be working:
*** jonathanmaw [] has joined #baserock10:16
pedroalvarezalthough I think that the notes are not cloned by default10:21
richard_mawhence opt-in10:22
*** locallycompact [] has joined #baserock10:24
KinnisonAye, notes are in refs/notes/ IIRC10:25
Kinnisonand thus will only be cloned by full mirror operations10:25
* pedroalvarez sends a patch to upgrade linux-pam10:26
franredpedroalvarez, our gstreamer does not have the submodules parsed to gbo:
* franred was about to test a patch for the error with bison10:28
pedroalvarezfranred: I think it does:
paulsher1oodpedroalvarez: i've built linux-pam with your patch, so +1 (unless there's something i need to test too?)10:34
paulsher1oods/your patch/your update/10:34
franredpedroalvarez, I forgot that I cloned master and not the branch, sorry, and thanks10:37
paulsher1oodrichard_maw - sorry, but i can't find the import tool source review? where should i look?10:41
richard_maw I think10:41
paulsher1oodand this was reviewed on the list?10:42
richard_mawthe first version was, I don't know if it's changed significantly since then, I haven't looked at it recently10:43
paulsher1oodah, ok. i see it now - thanks10:45
pedroalvarezpaulsher1ood: thanks, I think there is not harm in upgrading linux-pam for weston, but yeah, I'd like to hear radiofree_ or jjardon opinion10:45
radiofree_shouldn't be a problem, what version are you upgrading it to (i can test it)10:46
SotKI just had a build of tar fail:
Kinnisonmight need a newer tar10:49
paulsher1oodouch! what system is that?10:49
Kinnisongets is a srsly bad function to use10:49
SotKpaulsher1ood: systems/web-system-x86_64-generic.morph10:49
aananthKinnison: I replaced "" with "" in lorry-controller.conf. Still I get errors. Check
aananthI suspect, if nameserver resolution is alone a problem. Any other clues?10:53
paulsher1oodpedroalvarez: weston works after the linux-pam upgrade on x86_6410:54
pedroalvarezradiofree_: to 1.1.810:54
Kinnisonaananth: Very odd10:55
Kinnisonaananth: I'd want to strace things and that's very hard to do remotely over IRC.  I hope perhaps sotk might have some insights10:55
pedroalvarezSotK: I can take a look at that, is caused by the glibc upgrade10:56
jjardonpedroalvarez: it should not be a problem to upgrade linux-pam, no10:56
SotKaananth: did you get your Trove to reload its config after you changed that?10:57
SotKThat log looks like its still trying to use git.baserock.org10:57
* SotK looks for the request you need to send to tell it to read config10:58
aananthSotk: are you referring to "systemctl start lorry-controller-readconf.service" command?10:59
aananthI did few re-boots.11:00
pedroalvarezjjardon: thanks, and also paulsher1ood thanks for testing that11:00
SotKaananth: that sounds like it should do it, its strange that is mentioned rather than the IP in that log11:01
SotKcan you pastebin the contents of /home/lorry/confgit/lorry-controller.conf please?11:02
pedroalvarezSotK: I think we should upgrade tar11:02
SotKpedroalvarez: me too, the current ref is years old11:03
pedroalvarezaananth: please, don't paste users and passwords  :)11:03
pedroalvarez(if you are going to paste lorry-controller.conf with your proxy setting)11:03
aananthSotK: Here it is
aananthHi pedroalvarez, thanks :-)11:05
aananthSotK: I may not respond for another 1.5 hours, as I have an important meeting. Sorry.11:06
pedroalvarezI think I found the problem11:07
pedroalvarezis not valid JSON! :)11:08
pedroalvarezaananth: you are missing a comma at the end of the username of your proxy configuration11:09
pedroalvarezaananth: I looked at our docs, and it's present there:
SotKpedroalvarez: good spot11:11
pedroalvarezreally easy to copy json and paste it in a jsonlint page :)11:12
radiofree_ is now known as radiofree11:13
pedroalvarezSotK: I also wonder, why is tar in webtools?11:17
richard_mawpresumably something in there depended on GNU tar, and it was easiest to just put it there11:18
pedroalvarezI see, gitlab-ci depends on webtools, so maybe it was because of that11:22
SotKpedroalvarez: looks like its been in there since paulsher1ood made the example web system11:26
pedroalvarezSotK: hm.. maybe he found it was needed at run-time11:27
pedroalvarezSotK: are you looking at the tar upgrade or should I?11:29
SotKpedroalvarez: could you please look at it if you have time? :)11:30
pedroalvarezSotK: can you please review my linux-pam upgrade in exchange? :)11:31
SotKpedroalvarez: sure11:31
pedroalvarezit has already been tested by Paul11:31
*** CTtpollard [] has joined #baserock11:32
radiofreecan someone take a look at "[PATCH] Don't use cairo-glesv2 for weston clients"? it's important for the jetson genivi user experience :)11:33
richard_mawI don't understand the graphics stack, but I trust you to, so +1.11:33
CTtpollardquick question, is build time more cpu or memory dependant?11:33
richard_mawIO dependent is also a problem to consider11:34
richard_mawwhy do you ask?11:34
CTtpollardjust curious mainly, about whether to allocate more ram or cpu overhead to my devel VM11:35
richard_mawyou need to weigh it more heavily towards RAM if you're building things like WebKit11:36
richard_mawbut I think you need half a GB per CPU core to build gcc11:36
CTtpollardcool, ty richard_maw11:41
jjardonradiofree: if you have tested it, +111:44
jjardonshould we disable the cairo gl2 backend then? I think is only activated for this11:45
radiofreejjardon: nah leave it on11:47
radiofreewe'll want to use it again in the future, this is a temporary measure!11:47
aananthSam, Kinnison, pedroalvarez, SotK, paulsher1ood: Big thanks, I could see lorry loading data into vtsc-trove. IMAGE:
jjardonradiofree: sure11:53
aananthpedroalvarez: special thanks :-)11:53
pedroalvarezaananth: yay!!!11:53
*** aananth [~caananth@] has quit [Ping timeout: 244 seconds]12:04
radiofreewhat does the fstab configuration extension do?12:11
pedroalvarezradiofree: you can add entries to your fstab file 12:12
radiofreewhy does the genivi system need it, but not the devel system?12:13
pedroalvarezthey don't need it, but is nice to have12:14
pedroalvarezso we should enable it on the devel system as well12:14
*** aananth [~caananth@] has joined #baserock12:14
pedroalvarezif is enabled, you can add entries to the fstab at deployment time, just modifying your cluster morphology12:14
persiaI think the reason it isn't in devel is that the docs suggest mounting /src manually, and most folk who write the docs and code have a working /src that they want to remount, rather than working from scratch.12:14
radiofreehmm, don't we have  FSTAB_SRC in the deploy for that though?12:16
pedroalvarezradiofree: just spotted that12:16
pedroalvarezI think we should't assume that when doing a jetson  upgrade there is a device labelled as 'src'12:16
radiofreepedroalvarez: one of my patches added "nofail" to that12:23
radiofreeso you can at least still boot it if it's not there12:23
*** robtaylor [] has joined #baserock12:24
pedroalvarezthat's cool but a jetson upgrade should update the fstab entries with the old ones, not add new entries IMO12:24
radiofreeah yeah, good point12:25
persiaAny upgrade should do that.12:26
pedroalvarezyeah, any12:26
*** aananth [~caananth@] has quit [Quit: Leaving]12:28
pedroalvarezpatches to fix GNU tar sent12:32
SotKpedroalvarez: thanks :)12:33
* paulsher1ood cannot remember what needed tar at runtime, sorry12:35
pedroalvarezpaulsher1ood: pip?12:35
* paulsher1ood can remember being surprised that tar was not present in baserock when he needed it12:35
paulsher1oodpedroalvarez: possibly. 12:35
franredpip needs tar?12:37
* paulsher1ood cannot comment12:37
paulsher1oodit might have been pip, or gem, or npm, or me12:38
radiofreeshonky stuff here12:38
radiofreedid an upgrade to a system with factory, newgenivi12:38
radiofreecalled it newgenivi212:38
franredIm almost sure pip does not need it, pip is in my system but not tar12:38
radiofreeu-boot failed, complained about the extlinux.conf12:38
radiofreemanually changed the name of newgenivi2 in the extlinux.conf file to "genivi2", boots....12:39
paulsher1oodradiofree: is this the same problem is i've hit? can't boot12:40
*** Blacksnow [] has joined #baserock12:40
*** Blacksnow [] has quit [Client Quit]12:40
franredradiofree, could create a configuration extension which change extlinux.conf with the new name for your system solve the problem? (it is a hack but may work)12:41
radiofreepaulsher1ood: pretty sure12:41
radiofreefranred: well i should really be able to call it newgenivi212:41
radiofreei'll test it from an sd card and see if u-boot complains from that12:41
paulsher1oodpedroalvarez: has 'This is necessary because we do not currently have PAM in Baserock.' - is that no longer true?12:47
pedroalvarezpaulsher1ood: I'm not sure about that. The bit 'we do not currently have PAM' is not true, but I think that is still needed to run that12:49
radiofreemaybe also add a "How to use wayland-ivi-extenions (layermanager) in Baserock GENIVI Baseline"12:50
paulsher1oodi propose to remove that line from the wiki. we have PAM, but you still need to set the XDG_RUNTIME_DIR12:50
paulsher1oodradiofree: feel free :-)12:50
radiofreethe same config i had problems with loads fine from an ext2 sdcard :\12:52
radiofreeso now if i replace the config with the exact same config that was causing an error it's working12:54
radiofreefile getting corrupted or something?12:54
paulsher1oodthat's what you suggested yesterday... but there must be something *doing* the corrupting.. it's not a random corruption12:57
paulsher1oodradiofree: anything to test in your latest weston branch?12:57
* persia thinks that the practice of sticking random chunks at the highest level they are needed (e.g. tar in webtools), and only rationalising later as wider needs are discovered is a good one12:59
SotKpedroalvarez: you typo'd in your "baserock/pedroavarez/tar" branch name :)12:59
paulsher1oodpersia: yes, but would be better if i'd noted why i did it when i submitted the patch13:00
persiaThis is why we should insist on verbose commit messages :)13:00
paulsher1oodradiofree: interestingly the wiki instructions to run weston-ivi-shell don't actually lead to weston-ivi-shell any more13:03
cyndis_ is now known as cyndis13:03
paulsher1ood(i don't think that's related to your branch though - i noticed it earlier today)13:03
paulsher1oodmaybe it's me...13:03
locallycompactSome questions, I have a cmake (in opencv) that is pulling in random tarballs from the internet. How should I best handle this?13:06
locallycompactAnd secondly, why is it that it downloads correctly in a loose devel system but fails in a morph environment13:07
locallycompactpaste coming13:07
pedroalvarezSotK: ouch, thanks for reviewing13:08
Kinnisonlocallycompact: morph runs builds in a container which has no network access13:08
KinnisonSo opencv needs to be made to not try and download things13:10
persialocallycompact: Often looking at the Debian packaging provides good hints about how to cause things to build in a networkless environment13:13
locallycompactpersia: Thanks, I will try and hunt that out.13:14
persiaDebian has reached a consensus opinion that builds that access the internet are not compliant with license terms that require provision of full source of the built artifact, so disabled those about a decade ago13:14
persia is an excellent resource for this purpose13:15
persiaTypically the "rules" file explains how to do the build, and the "watch" file explains what to download in advance13:16
persiaThere is sometimes a "README.source" file that provides more explanation, and sometimes there is more explanation in the "copyright" file.13:16
persiaOh, and all those files would be in the "debian" directory if you browsed from the URL above.13:17
pedroalvarezradiofree: so,' wayland-ivi-shell & weston-ivi-extension + downgrade of cairo + unifying kernels' will be the merges remaining to do the release, right?13:43
juergbii just got a report that u-boot built by baserock doesn't work properly. you can boot it to the command line but it doesn't recognize any commands, not even 'help'13:46
juergbiit works fine if u-boot is built manually with a cross compiler (even with a baserock-built cross-toolchain)13:46
juergbihas anyone seen anything like this before?13:46
juergbimiscompilation by gcc could be an issue (known to happen with certain gcc versions), however, it's strange that it works with cross-compiler but not with native compiler even though they are the same version13:48
richard_mawnever heard of anything like that before13:50
paulsher1oodrichard_maw: ^^ ?13:50
*** thecorconian [] has joined #baserock14:01
*** thecorconian [] has quit []14:02
radiofreepedroalvarez: downgrade of cairo?14:02
pedroalvarezmaybe I made up that14:03
radiofreepedroalvarez: please check the baseline to see if there's a hard requirement for the version of ivi-shell/extensions14:03
radiofreeif it's just a "minimum version" then those patches are fine14:03
radiofreeso yes, "don't use glesv2 for weston clients", "unified kernel", "weston-ivi-shell + wayland ivi extension" are the upgrades from me14:04
radiofreeerg [ 3193.481476] systemd-journald[137]: Failed to write entry, ignoring: Read-only file system14:04
rdale_what happened to the gstreamer 0.10 build patch - has that gone in?14:05
pedroalvarezis not genivi using gstreamer 1.2?14:05
rdale_it's for qtmultimedia which needs an old gstreamer14:05
radiofreerdale_: HEAD of baserock/morph/0.10 works14:06
radiofreeso update the sha in definitions to use that 14:06
rdale_ok sounds good14:07
pedroalvarezradiofree: they say:14:09
pedroalvarezWeston-ivi-shell repo, Tag weston-ivi-shell-1.4.93-v3-transition 14:09
pedroalvarez- Wayland IVI extension repo, Tag 1.2.0-rc6 14:09
radiofreeman that's old14:09
radiofreeis that a minimum version?14:10
pedroalvarezwhat versions are you using?14:10
pedroalvarezTBF, they normally point to tags that doesn't exist...14:11
radiofreemaster for ivi-extension, the 1.3.0 branch for weston-ivi-shell14:11
radiofreeivi-extension master is post 1.2.0 release tag14:11
pedroalvarezIs not clear if it has to be an specific version, so I'd say, let's stick with what you have done14:13
*** thecorconian [] has joined #baserock14:24
richard_mawhm, more digging has lead to a list of caveats for pivot_root based filesystem update15:16
richard_maw1. it only affects my mount namespace, so you'd need to run pivot_root in all your sub-namespaces too15:17
richard_maw2. pivot_root doesn't change processes that have already chrooted, so to make that work you'd need to chroot into their chroot before pivot_rooting to the accompanying chroot in the new tree15:17
CTtpollardI've just had a build error when trying to build the latest web-system image15:18
CTtpollard137/156 tar15:18
richard_maw3. it doesn't chdir, unless cwd==/, so file accesses by relative paths will still point to the old rootfs until the process is restarted15:19
richard_mawCTtpollard: I think someone's already looking at that15:19
CTtpollardis that a more wider problem?15:20
CTtpollardtar failing to build, or it just in relation to this specific system build15:21
richard_mawtar in general after the glibc update I think15:21
richard_mawwe tend to use busybox tar for everything else, but it's in web-system, presumably because there's one of the components doesn't work with busybyox tar15:32
paulsher1oodrichard_maw: CTtpollard maybe just remove tar altogether and see how you get on? :)15:33
* CTtpollard investigates 15:33
CTtpollardI'll remove it from the webtools strata locally and see how it goes15:34
pedroalvarezradiofree: the weston example of a triangle rotating doesn't work in x8615:36
radiofreepedroalvarez: start weston, separate terminal export XDG_RUNTIME_DIR=/tmp EGL_LOG_LEVEL=debug weston-simple-egl15:38
radiofreepaste the output from that please15:38
paulsher1oodpedroalvarez: i remain confused by genivi versions, so i think in general we just aim to be as current as we can15:40
paulsher1oodpedroalvarez: i believe ygb is using gstreamer 1.415:41
radiofreepedroalvarez: try XDG_RUNTIME_DIR=/tmp EGL_LOG_LEVEL=debug weston-simple-egl15:41
radiofreepedroalvarez: there's no /usr/lib/egl/egl_gallium?15:44
radiofreepedroalvarez: there's no /usr/lib/egl/egl_gallium.so15:44
radiofreehas the egl client ever worked in the vm?15:45
radiofreeI would imagine you probably want to build mesa with "--enable-gallium-egl"15:45
radiofreejjardon: ?^15:46
pedroalvarezI thought we were doing that15:46
radiofreeonly for arm apparently15:46
radiofreepedroalvarez: what do you have in /usr/lib/dri ?15:46
pedroalvarezah, I don't have /usr/lib/egl15:47
pedroalvarezlet's see dri15:47
radiofreethere we go then :)15:47
pedroalvarezthere are things there!15:47
pedroalvarezradiofree: so, I just have to enable that in mesa?15:48
SotKCTtpollard: building from baserock/pedroavarez/tar should work15:51
pedroalvarezgit blames jjardon :(15:52
radiofreewhat do you have in dri?15:53
CTtpollardSotK: cool, currently building without tar, off the top of my head I can't see a reason why I'd need it so it should be fine15:54
pedroalvarezradiofree: are them ok? or should I change anything else in mesa?15:57
*** Krin [] has quit [Ping timeout: 255 seconds]16:00
radiofreewell it looks ok, i'm assuming swrast is the llvmpipe driver as well?16:00
radiofree(sorry i don't know much about this on x86)16:00
*** fay_ [] has quit [Quit: Leaving]16:01
*** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 265 seconds]16:01
*** fay [] has joined #baserock16:02
fay is now known as Guest916716:02
pedroalvarezradiofree: IIRC you are right16:02
Guest9167 is now known as fay_16:03
jjardonDont do that16:19
radiofreedon't do what?16:20
jjardonEnabling egl will work but veerery slow in the vm16:20
radiofreeworking very slow is better than not working at all16:20
radiofreealso that sounds to me like the llvmpipe driver isn't working then?16:20
radiofreeor does it just not work very well in the vm?16:21
jjardonpedroalvarez: for what Im being blamed?16:24
jjardonwe never enabled gallium-egl for x8616:27
jjardonradiofree: thinking twice maybe is worth a try; didnt know about --enable-kvm when I build a system with gallium-egl enabled for x8616:28
jjardonbut anyway, those demos never worked in x86, its not a regression16:30
*** zoli_ [] has joined #baserock16:31
*** zoli_ [] has quit [Changing host]16:31
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock16:31
pedroalvarezjjardon: hmm not sure now, but anyway, we reviewed your patches, is not your fault in any case16:36
pedroalvarezradiofree: ip ad16:42
pedroalvarezsorry, multiple keyboards, one brain16:42
franredradiofree, "ctrl+r" "ip ad" \tab enter16:44
franredi missed a tab16:44
*** jonathanmaw [] has quit [Quit: Leaving]16:51
pedroalvarezradiofree: genivi in arm works great :)16:51
radiofreehurrah! :D16:57
*** Krin [] has joined #baserock16:58
radiofreepedroalvarez: for
radiofreethe DTB_PATH for jetson-upgrade needs to change to tegra124-jetson-tk1.dtb17:03
radiofreeand in release.morph as well17:03
pedroalvarezgood to know, thanks!17:04
pedroalvarezhere we go, egl working in genivi x86 17:14
*** wdutch [] has quit [Quit: Quit]17:19
pedroalvarezwow, morph built a system with a stratum that doesn't exsist, but it fails to deploy:
pedroalvarezwait, I may be wrong17:28
pedroalvarezaha! is not complaining because of that system17:29
pedroalvarezis complaining because of build-system-armv7lhf-jetson.morph17:29
straycatOur import tool needs to not have this x.y scheme for its extensions.17:29
straycatNow I'm going to have to do something weird with imp to import my exts.17:29
straycatThat is all.17:30
radiofreepedroalvarez: ah, i didn't even see that one17:31
radiofreewhat's a "build-system"?17:31
pedroalvarezit was the distbuild system17:33
straycatWell almost, I suppose this is good in that it does give me an excuse to use imp. >.>17:34
paulsher1ooddid someone comment on juergbi's u-boot weirdness earlier?17:40
juergbirichard_maw mentioned that he hasn't heard of anything like that17:41
juergbiwe'll use a manually built version for now but it would be good to figure out the cause of this issue17:42
radiofreejuergbi: how are you building it in baserock?17:42
radiofreei had to set CROSS_COMPILE to /usr/bin17:43
juergbiit was a simple make BOARDNAME17:43
juergbii then suggested to set CROSS_COMPILE to /usr/bin/ based on your branch17:43
juergbihowever, there was no difference17:43
radiofreeit's worth noting before that we never actually built u-boot in baserock17:44
radiofreeare you using baserock/morph ?17:44
radiofreeas the branch for u-boot17:44
juergbiit's based on a vendor branch17:44
juergbii actually don't have access to that trove, unfortunately17:44
juergbii can get you the public vendor branch that we use as base, i suppose17:45
radiofreewe use the u-boot we build in br (not baserock/morph branch, that's ancient) on the jetsons17:46
radiofreeso we not it works there17:46
juergbiour branch is currently based on lager build of;a=shortlog;h=refs/heads/renesas/bsp/rcar-gen2-617:46
juergbiwe could check a rebase to the latest version but it works fine with the cross compiler, so....17:47
juergbi(and i don't have a recovery possibility in my office, so i try to avoid flashing u-boot myself here)17:47
radiofreehow bizarre17:49
*** Krin [] has quit [Remote host closed the connection]17:50
radiofreedo any of the commands specific to the board config work?17:50
radiofreecmd_help should always be built though i suppose17:50
juergbii know that at least 'help', 'printenv', and 'setenv' are not recognized17:51
juergbiand it's not like u-boot builds a default config if you make a typo in the board name or similar17:52
juergbiand serial port works, which is something board-specific17:52
radiofreeso for the cross compilation are they just doing make BOARDCONFIG CROSS_COMPILE=/foo/bar/arm-gcc17:53
radiofreeor is there some build environment they use for that?17:54
juergbii didn't see the exact command but should be just that + ARCH=arm17:54
juergbino special build environment except for baserock cross toolchain17:54
radiofreeand it's someone doing that on their desktop machine, with the same source code?17:54
juergbiin the past, i always built it myself with my own cross toolchain and that worked fine as well17:55
juergbii guess i'll either need to debug it in an environment where i have at least access to a lauterbach for recovery, or alternatively, wait until gcc is upgraded in baserock and try again ;)17:57
radiofreeheh yeah17:58
radiofreeit's quite odd that it would work at all though17:58
juergbiwhy odd that it works at all?17:58
radiofreesounds like the commands don't get compiled, when you type help does it say "Unknown command 'help'"17:58
radiofreeor just nothing?17:58
juergbiit says something funny17:59
juergbiUnknown command 'help' - try 'help'17:59
radiofreeunknown command 'help' - try 'help'17:59
pedroalvarezindeed, it's funny17:59
radiofreeso it sounds like the common commands aren't getting built for some reason?17:59
juergbinow we have a few deadlocked engineers ;)17:59
pedroalvarezare they still typing "help"?18:00
juergbimaybe ;)18:00
juergbii didn't check whether we get .o files for the commands18:00
franredman - try 'help'18:00
*** DavePage_ [] has joined #baserock18:04
DavePage_ is now known as DavePage18:05
radiofreejuergbi: well here he seems to suggest it's something as weird as LC_ALL being set18:06
radiofreebut i can't see that being true ._o18:07
juergbiwell, libc has some inconveniently locale dependent parsing functions18:08
radiofreeLANG=en_GB.UTF-8 is set in the chroot18:08
juergbialthough, not sure what build tool would mess up like that18:08
juergbilooks like this was never fixed18:10
juergbiit sets LC_COLLATE but not LC_ALL18:10
juergbiif chroot also sets LC_ALL for some reason, we see the issue18:10
*** CTtpollard [] has quit [Quit: Ex-Chat]18:11
juergbiradiofree: i assume environment variables are visible in baserock build logs?18:11
pedroalvarezwhen building using morph, yes18:11
juergbiok, i'll check that18:12
juergbithanks for the pointer18:12
pedroalvarezactually, the environment is stored in the metadata file inside of the artifact18:12
radiofreein the makefile for our jetson branch they do
radiofreealso in master;a=blob;f=Makefile;h=ddea53485a1e016ec80e8e4dc5a526a72fada41d;hb=HEAD18:13
juergbiright, i thought the upstream base of the renesas branch was more recent18:16
juergbiapparently, it was fixed in master beginning of this year18:16
juergbibut it's based on 2013.01.01 :/18:17
juergbivendor trees...18:17
*** rdale [] has joined #baserock18:30
*** rdale_ [] has quit [Read error: Connection reset by peer]18:30
*** rdale_ [] has joined #baserock18:34
*** rdale__ [] has joined #baserock18:35
*** rdale [] has quit [Ping timeout: 250 seconds]18:37
*** rdale__ [] has quit [Read error: Connection reset by peer]18:37
*** rdale_ [] has quit [Ping timeout: 256 seconds]18:39
*** rdale [] has joined #baserock18:41
vmesons is now known as vmeson19:43
vmeson is now known as vmesons20:26
vmesons is now known as vmeson20:30
straycathey DavePage :)20:58
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock23:21
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]23:24
*** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 258 seconds]23:30

Generated by 2.14.0 by Marius Gedminas - find it at!