IRC logs for #baserock for Thursday, 2014-09-25

*** jjardon [sid723@gateway/web/] has quit [Ping timeout: 272 seconds]05:47
*** jjardon [sid723@gateway/web/] has joined #baserock05:49
*** tiagogomes [~tiagogome@] has joined #baserock07:38
jjardonSome numbers of gnome-continuous that could be of interest here:
*** dutch_ [] has joined #baserock07:49
paulsher1oodjjardon: yes. very impressive07:51
*** violeta [] has joined #baserock08:05
*** jonathanmaw [] has joined #baserock08:28
*** juergbi [] has quit ["Ex-Chat"]08:29
*** juergbi [] has joined #baserock08:32
* pedroalvarez installs dialog in baserock08:33
petefothDoes the `morph git` command still exist?08:36
pedroalvarezERROR: unknown subcommand git08:37
pedroalvarezI guess that's a no08:37
pedroalvarezI never heard of it08:37
KinnisonI don't remember us every having one08:38
pedroalvarezpetefoth: is that mentioned anywhere?08:38
petefothpedroalvarez: ta. I am looking at whihc says that morph git runs git with the arguments on the command line in each local git repository in the workspace. (which seems like it might be useful)08:38
petefothI'm looking at what commands could be taken out / deprecated to simplify the workflows08:39
Kinnisonisn't that morph foreach ?08:39
Kinnisonmorph foreach -- git push origin HEAD08:39
pedroalvarezno mention of foreach in that document08:40
Kinnisonpedroalvarez: okay then, morph foreach -- git push origin $(morph show-system-branch)08:41
Kinnisonless dangerous08:41
petefothpedroalvarez: as far as I know that doc has no 'official' status but it was updated relatively recently (2014-08-12) by richard_maw08:41
richard_mawI generally do `morph foreach -- sh -c 'git push -n origin HEAD 2>&1'` first, then remove the -n if it looks ok08:43
Kinnisonrichard_maw: why do the 2>&1 ?08:46
richard_mawbecause otherwise the stderr gets swallowed08:46
Kinnisoncan we fix that?08:46
richard_mawyeah, we didn't at the time because we also want to print the errors out for commands that fail after they have done, and we can report the error code08:47
richard_mawthe ExtensionSubcommand class would let us pass a callback for stderr handling that saved it and wrote it out to stderr08:48
* Kinnison would rather see normal UI from each subcommand08:48
Kinnisonesp. given some commands won't produce verbose output if their stdout/stderr are not ttys08:48
*** ssam2 [] has joined #baserock09:01
pedroalvarezI've found pythondialog as a python wrapper for dialog09:09
pedroalvarezalso, "import curses" from python doesn't work.09:09
ssam2in Baserock ?09:11
pedroalvarezI've read that can be caused because ncurses wasn't present when installing python09:11
pedroalvarezssam2: yeah! this is #baserock09:11
ssam2yeah, I expect that's the problem09:11
jmacs"import curses" works OK on my baserock system09:11
pedroalvarezjmacs: good to know, then is only my problem09:12
jmacsIt's strange. It should be a standard library.09:12
pedroalvarezthis is the error I get:
KinnisonHmm, looks like perhaps libncurses isn't available when cpython is built?09:16
ssam2works in my Baserock VM, too09:16
pedroalvarezI see09:19
pedroalvarezncurses was moved to the build dependencies of cpython after my vm was built09:19
pedroalvarezwhen I saw the problem I thought: ok, lets move ncurses, but it was already there, and hence my confusion09:20
jmacsThat explains it. I've got a pretty recent built09:20
pedroalvarezthanks for your help09:21
*** Krin [] has joined #baserock09:21
* Kinnison is tempted to ask for mosh support in Baserock09:28
richard_mawpatches welcome09:28
KinnisonUnfortunately it needs a number of icky perl modules09:28
pedroalvarezI tried to intall it once, and got blocked with utf809:33
ssam2Kinnison: would be fun to write a CPAN importer for the import tool09:36
ssam2for someone who finds writing Perl fun :)09:36
* Kinnison does not09:36
*** De|ta [~arc@] has quit [Quit: rebooting]09:41
*** jonathanmaw [] has quit [Ping timeout: 245 seconds]09:51
*** jonathanmaw [] has joined #baserock09:51
jjardonCould someone merge my mesa branch? It already got two +1 :) . thanks!09:52
*** CTtpollard [] has joined #baserock09:55
paulsher1oodjjardon: are you still waiting +2 on others?09:55
ssam2can we sort jjardon with commit access, as agreed on the list several weeks ago?09:55
KinnisonThe one upstream person with the right to do that has not been around, we clearly need to repair that flaw09:56
richard_mawjjardon: you can have a +1 for the dbus-glib one too. I'll respond on the ML09:56
jjardonpaulsher1ood: the dbus-glib ones09:56
jjardonrichard_maw: thanks09:56
paulsher1oodjjardon: i built it. if there's something i can run to test it, i'll +109:57
Krinmorning all, here's your resident problem and headache causer :)   so "morph --verbose build systems/devel-system-armv7lhf-jetson.morph" got terminated through a broken pipe at step 560 of 790 last night, is this likely to be recoverable?09:57
paulsher1oodKrin: just restart09:57
Kinnisonyep, just start it again09:57
paulsher1oodshould pick up at 56009:58
paulsher1oodyou might want to run screen first, so that it can continue even if your ssh drops09:58
jjardonKinnison: what is the process? Should I send my public SSH key to someone/somewhere?09:58
Kinnisonjjardon: Persia is supposed to have sorted all this, but he's not been around (very unwell as I understand)09:58
Kinnisonjjardon: I don't know what the Baserock upstream team decided for this09:59
Krinstarting again, at the end gives me "ERROR: Failed to update cached version of repo git://" is this just it's way of saying "already up to date"?09:59
paulsher1oodKrin: nope. can you ping anything on that jetson?09:59
jjardonKinnison: OK, I will ping him when I see him around10:00
Krinseem to be able to ping fine.10:00
Kinnisonjjardon: I'm starting to think that the rest of the upstream team may have to make a decision about who else can grant these rights10:00
ssam2Kinnison: who has the ability to add users on, other than you? Would you be willing to grant that ability to someone the upstream team ?10:00
Kinnisonjjardon: since clearly having a SPoF is a bad idea10:00
ssam2*someone on10:01
Kinnisonssam2: Richard Maw is also in that team10:01
paulsher1oodKrin: please retry your command with --no-git-update10:01
* paulsher1ood is confused as to what's breaking for Krin, though10:01
ssam2ok. come in richard_maw! would you be able to grant jjardon commit access, in persia's absence ?10:01
* paulsher1ood considers requesting/using supercowpowers on gbo, since he's online at times when others aren't10:02
Krinthat's one of my magic things paulsher1ood, if it can go wrong around me, it will, usually in spectacular fashion, sometimes involving fire :)10:02
paulsher1oodKrin: it's a talent. nurture it. but also nurture precision in identifying and describing exactly what happens10:03
richard_mawssam2: only when I make it into the office, working from home this morning, and I haven't authorized my personal laptop to be able to do that10:04
Krinhuh... interesting. adding the --no-git-update command gave a result i would not have expected for git not10:06
Kringit being told not to update10:06
ssam2ok. in the meantime I'll merge your mesa patch jjardon !10:06
Krinthis requires a cup of tea.10:06
KrinERROR: Ref 9359b61ca44980d33c0bee42b9bb2e36e72835dd is an invalid reference for repo git://
jjardonssam2: thanks!10:07
*** De|ta [~arc@] has joined #baserock10:14
jjardonrichard_maw: you are rigth about the llvm dependency, I will send a new patch shortly. I got confused as mesa didnt depend on anything when I moved it to its own stratum from x-generic. But llvm is in x-common, not x-generic10:18
* ssam2 apologies for attempting push the whole of linux.git to baserock:baserock/definitions10:31
ssam2i was wondering why 'git remote update' was taking so long ...10:31
pedroalvarezwho pushed morph.git into definitions.git in the past?10:32
SotKthat was me10:32
ssam2that wasn't on, at least :)10:32
SotKthat is true :)10:32
pedroalvarezI once screwed up morphs.git (old definitions.git), but I even don't know what I did, I was still learning git :)10:33
jjardonmmm, seems that the llvm repo stop being updated.10:40
jjardonlike 3 weeks ago10:40
jjardonalso it didnt import the tags. llvm is a svn repo, maybe lorry still doesnt support this?10:42
KinnisonDepends on the layout, git-svn should import tags10:42
jjardonKinnison: Do you know if this one is supported?
jjardonoh, wait, we are using their git mirror10:45
jjardon that seems to be empthy, that would explain the lack of updates10:46
jjardonthe github mirror is still working though:
pedroalvarezjjardon:  `git clone` works for me10:50
jjardonpedroalvarez: yeah, here too... problem with lorry then?10:51
pedroalvarezjjardon: or maybe the mirror is out of date10:52
jjardonpedroalvarez: just cloned it, last change is from today10:53
pedroalvarezjjardon: right, I'll take at what's going on10:54
jjardonpedroalvarez: thanks!10:54
Krinok, if anyone gets that above error again, with the git having issues picking up where it left off, the cache needed removing, the artifacts/*kexec* and gits/*kexec*10:55
pedroalvarezKrin: corrupted data then?10:56
paulsher1oodseemed to be10:56
ssam2oops, I have a feeling I just used git-send-email to spam a whole bunch of unrelated Linux people10:57
KinnisonOh dear10:57
paulsher1oodssam2: oops10:57
ssam2question is, is it better to send further spam to apologise to them ?10:57
jonathanmawssam2: probably better to apologize, otherwise they don't know if you might do it again10:58
Krinit's always better to send more spam, then they have more to moan about, and everyone in england is only happy when complaining :)10:59
ssam2yeah, I shall do10:59
* ssam2 changes sendemail.suppresscc from 'self' to 'all' in git config11:06
pedroalvarezFound what is causing llvm not to be updated:
jmacsOh, no 'objects' directory in the source git repo... we saw this during the upgrade of gbo but I can't remember any more details :/11:11
ssam2paulsherwood: seems you changed the command in to be 'morph --verbose build systems/base-system-x86_64-generic'11:16
pedroalvarezso, lorry tries to do do a backup before lorry new content, but it fails if the things that it's trying to backup are not there11:16
ssam2paulsherwood: but that won't work with the 14.29.1 tag of definitions, it should be 'morph --verbose build base-system-x86_64-generic'11:17
ssam2paulsher1ood: should I change it back , or am I missing something ?11:17
pedroalvarezversioned documentation! ftw!11:17
pedroalvarezjjardon: llvm lorry is working again11:19
paulsher1oodssam2: my mistake, please revert.11:19
paulsher1oodi'm sure i had a reason, though11:19
paulsher1oodlost in backscroll11:19
ssam2it'd have made sense if we also updated devel-with to be using latest morph11:21
ssam2(although it'd need to be 'morph --verbose build systems/base-system-x86_64-generic.morph' in that case)11:22
ssam2I've also updated to recommend 'git send-email --supress-cc=all' so that others don't do the same dumb thing I just did11:22
paulsher1oodssam2: i want to propose use latest morph by default. since morphs-in-definitions release morph can't cope anyway11:25
ssam2I don't understand your last sentence ... morph from 14.29 can build the 14.29.1 tag11:26
ssam2I'm not necessarily against recommending using latest morph by default, but I think the real problem is we need a coherent release policy11:27
jjardonpedroalvarez: thanks! what was the problem?11:27
paulsher1oodssam2: yes. but really, who cares? life is so much nicer with chunks-in-definitions11:27
ssam2even if that policy is "every commit to definitions is a release"11:27
paulsher1ood(who cares that 1.49 can build 14.29.1)11:28
ssam2when new users are playing with master, it adds overhead for us to support them11:28
pedroalvarezjjardon: there is a bug in the lorry code, I don't know all the codebase to do a fix though11:28
ssam2it also highlights new bugs, which is useful11:28
paulsher1oodssam2: yes, agreed. but to be clear as a project, we're moving forward -'stable' and 'backporting' are not what we're aiming at. by default our users should be expecting to move forwards on an ongoing basis. we need to make that process simpler and less error-prone, but that's definitely the direction imo11:31
paulsher1oodif users want to stabilize and backport they are welcome to, of course11:31
ssam2Ok.  using a 14.29 devel image with 'master' of Morph and 'master' of definitions is a good step towards that goal, then11:32
paulsher1oodi agree. it's minimal pain, too11:34
paulsher1oodinterestingly, does mason use latest morph?11:34
ssam2as I understand it, Mason uses whatever it was built with11:34
paulsher1oodhmmm... could we easily fix that?11:34
ssam2what it should do is build itself, then update itself to the new version that it just built11:34
paulsher1oodthat sounds different11:35
ssam2well, it's not just Morph that changes11:35
ssam2it's mostly Morph11:35
paulsher1oodi was thinking of getting mason to do what you suggested as the good step11:35
ssam2oh. That'd be a good compromise too, I think11:36
ssam2in fact, it's really only when we mess with the bootstrap that the system needs to upgrade itself11:36
paulsher1oodie, if our default for user is [14.29 devel + latest morph + master definitions] until we s/14.29/XX.YY/ then cause mason to be the same thing11:36
ssam2makes sense11:37
paulsher1oodit seems like a good place between - change machines every time we do a commit - and - 14.29 until we decide otherwise11:37
paulsher1oodothers may disagree, though. i expect persia in particular could throw a grenade at this11:39
pedroalvarezpaulsher1ood: public mason is not using latest morph, since in that morph, distbuild is broken11:39
paulsher1oodheh :)11:39
pedroalvarezI tried to upgrade it this tuesday11:39
paulsher1oodand if it was, it would have spotted the problem at commit time11:39
paulsher1oodso actually that's a datapoint in favour of this suggestion i think :-)11:40
pedroalvarezI think mason should also run the morph test suite11:40
* persia doesn't have a grenade: until elastic instances are used for system testing, there's no point fussing about the version used to do a test (because we're doing post-commit testing).11:41
paulsher1ood+1 for whichever subset of tests currently pass :)11:41
persiaWhen we migrate to pre-merge testing, we should be testing with elastic instances of master.11:41
paulsher1oodpersia: yup11:41
* persia crawls back in the no-distractions box, and will read backscroll later11:42
paulsher1oodso leave it as is on mason for the moment? but in the meantime fix the wiki to [14.29 devel + latest morph + master definitions], ssam2 ?11:42
pedroalvarezwe had automated deploy and test in openstack working11:42
paulsher1oodpedroalvarez: can we return to that state?11:43
pedroalvarezit was a workin progress, there is a branch in definitions iirc, but it nieed some extra work before it can be merged11:43
* paulsher1ood notes that the default wiki documentation covers build, not distbuild11:44
ssam2paulsher1ood: ok, i'll fix the wiki11:44
ssam2(about latest morph, I don't know what you mean about build vs distbuild)11:44
paulsher1oodssam2: i just mean, for new users, the default examples are using build. setting up a distbuild network is, er, an advanced topic :)11:45
ssam2I agree11:45
paulsher1oodbut i've heard some discussion about scrapping one or the other to have only one path here11:46
ssam2oh, I've missed that11:46
paulsher1oodshall i precis here, or on the ml?11:46
paulsher1oodactually i notice i've started several threads about workflow, with limited uptake :)11:47
petefothDid you spot this in #baserock?11:48
petefoth * persia crawls back in the no-distractions box, and will read backscroll later11:48
petefothHe's alive !11:48
paulsher1oodpetefoth: yes, be happy, and try not to distract him further :)11:48
petefothworng widnow error!11:49
paulsher1oodothers have started threads too, looking back11:49
* petefoth thinks (FWIW) that the command should be `morph build` and whether or not that build is actually a distbuil depends on current configuration11:51
ssam2petefoth: that's how it used to be, but it can be annoying to have a single command that can change its behaviour in hard-to-understand ways11:52
ssam2config file changes can cause something that previously worked to fail with an unexpected error11:52
ssam2paulsher1ood: yes, I think a mailing list thread isn't really the right place to discuss something as complex as workflow11:53
ssam2such topics that involve a lot of design are hard to do via email11:53
petefothssam2: hopefully the upcoming discussions about workflows can deal with issue and arrive at aconsensus onthe best way forward11:54
ssam2yeah, I'm looking forward to that11:54
paulsher1oodssam2: how then, if not email? irc is worse, clearly11:55
paulsher1ooda meetup, perhaps? :)11:55
ssam2i don't know. Many distributed free software projects are terrible at design11:56
ssam2The good ones are usually lead by a few individuals11:56
ssam2or have a dedicated 'design team'11:56
ssam2doesn't mean we should give up, but it's hard for me to make recommendations on what to do!11:57
petefothssam2: where 'design team' is alos reponsible for deciding which features / requirments get implemented?11:57
ssam2petefoth: not necessarily11:57
ssam2but there must be core developers who respect the design team11:58
ssam2and try to implement the work they do11:58
* petefoth would really like to know of good ways of doing that!11:58
ssam2otherwise the design team will realise nothing is changing and give up11:58
ssam2I prepared in case we want to change the wiki11:59
ridgerunnerfailed to upgrade Baserock on jetson TK1:
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 258 seconds]12:05
petefothssam2: b/devel-with.mdwn - s/mastere/master/ (says Mr Picky;)12:05
paulsher1oodssam2: works for me12:07
paulsher1oodbut then the build commands need fixing too12:07
paulsher1oodsince master has systems/foo12:07
paulsher1oodand morph is now picky12:08
pedroalvarezridgerunner: Trying to figure out what happened12:08
ridgerunnerThanks, do you want to see the .morph?12:08
paulsher1oodpedroalvarez: this is the problem i had over the weekend. glad it's not just me :)12:09
ridgerunnerAs a bugfinder I am in your shadow :-)12:09
pedroalvarezpaulsher1ood: also upgrading a jetson?12:09
paulsher1oodi removed the hostname stuff to get round it12:10
paulsher1oodridgerunner: try morph deploy --upgrade jetson-upgrade.morph jetson.VERSION_LABEL=ridgerunner12:11
paulsher1oods/get round it/find a different problem further on/12:11
pedroalvarezpaulsher1ood, ridgerunner: so you both were trying to self upgrade the jetson?12:12
ridgerunnerRunning that now.12:13
paulsher1oodwhich according to radiofree was/is possible12:13
jjardonpaulsher1ood: Im building llvm inside mesa-common at the moment. if you want it in different stratum, I think it should go in llvm-common and the "compiler" stratum (with clang and gcc) should depend on it12:13
paulsher1oodi think :)12:13
pedroalvarezpaulsher1ood, ridgerunner: Is the upgrade process asking for passwords during the upgrade?12:14
ridgerunnerNot here, no12:14
pedroalvarezthis is a weird error and difficult to debug :(12:18
ridgerunnerWoot paulsher1ood that ran to "Finished deployment"12:18
ridgerunnerOnwards and upwards.12:18
jjardonmmmm, where morph configure how many cpus it should use? Im using the c++ compiler and only 1 cpu has being used12:19
pedroalvarezridgerunner: was $VERSION_LABEL something useful?12:20
pedroalvarezridgerunner: if you are not familiar with shell, can you run `echo $VERSION_LABEL` ?12:20
pedroalvarezI think the upgrade is failing because of that12:20
ridgerunnerI had set it to "rdj.v1"12:21
richard_mawjjardon: it guesses based on the number of CPUs it has, or is limited to the number set in the morphology e.g. `max-jobs: 1`, or set globally on the morph command line/config file with --max-jobs12:22
paulsher1oodpedroalvarez: do you have a jetson?12:23
paulsher1oodit's easy enough to replicate12:24
paulsher1ood(doesn't happen on x86 afaict)12:24
jjardonrichard_maw: no configure/command line option, and I have 4 cores (building llvm, I will check if the package itself only allow one compilation thread)12:24
jjardonrichard_maw: can be a difference that Its using the c++ (cc1plus) compiler instead the c one (gcc)?12:25
richard_mawc++ shouldn't make a difference, but if they're doing something weird in the Makefile, such as re-defining their own MAKEFLAGS, then it will ignore the parallelism morph has determined for it, and default to 112:28
richard_mawthe linux chunk used to have this issue12:28
richard_mawIIRC we fixed it by changing the build-commands to be `make $MAKEFLAGS` instead12:29
pedroalvarezpaulsher1ood: I don't have a jetson12:35
pedroalvarezbut this problem should be happening in x86 as well12:41
* SotK has a jetson, and has upgraded it in the past and has never seen that issue12:41
paulsher1oodSotK: try the command line with $(hostname)12:41
pedroalvarezweird, HOSTNAME has nothing to do in that error12:43
SotKpaulsher1ood: my jetson needs reflashing atm, I can try later perhaps12:43
SotKridgerunner: what does your deployment morphology look like ooi?12:46
paulsher1oodridgerunner: my guess is that even though your deployment worked, rebooting puts you in factory, rather than your upgrade?12:48
SotKridgerunner: are you using jetson-upgrade.morph from master of definitions?12:48
pedroalvarezSotK: this is the error:
SotKthe deployment name in jetson-upgrade.morph in master of definitions is "jetson" not "self"12:49
SotKso self.VERSION_LABEL and self.HOSTNAME aren't setting anything12:50
ssam2second version of 'use latest morph in wiki` patch:
SotKif that is the case in ridgerunner's morphology12:50
ssam2thanks for the comments on the first one12:50
* paulsher1ood hopes this self thing is not all his fault :)12:50
pedroalvarezthat explains why it works in x86 and not in armv712:52
paulsher1oodssam2: looks good. did you grep for 'morph build' to be sure there are not other instances?12:52
pedroalvareznow I wonder why it succeded without the hostname12:53
SotKconfusingly, it is self in the x86 upgrade morphology example12:53
ssam2paulsher1ood: I did :)12:53
* paulsher1ood really does not understand all the deploy magic, starting at calling them 'clusters' instead of 'deploys'12:53
SotKpedroalvarez: there is a default hostname in jetson-upgrade.morph12:53
* ssam2 has considered a `morph upgrade-self` command in the past12:55
pedroalvarezSotK: but the error that ridgerunner was hitting I think it was caused because the version label was not set12:57
SotKpaulsher1ood: A "cluster" contains "systems" which have one or more specified "deployments"/"deploys". Deploying a cluster defaults to deploying every deployment of every system in the cluster, but it is possible to specify individual deployments to do.12:59
SotKpedroalvarez: hmm, then I too am confused12:59
jjardonrichard_maw: confirming the `make $MAKEFLAGS` trick worked, thanks!13:02
* jjardon using 100% of his 4 cores now13:02
* jjardon has commit access now :) (thanks richard_maw)13:05
* richard_maw ponders whether to give jjardon trove-admin access, so jjardon is on the hook to add people's keys next time13:06
petefothis git help add-binary13:24
petefothKinnison: EWRONGINDOW and ECRAPTYPING13:27
*** dutch__ [] has joined #baserock13:42
*** ssam2_ [] has joined #baserock13:43
*** sam__ [] has joined #baserock13:43
*** violeta_ [] has joined #baserock13:43
*** fay__ [] has joined #baserock13:43
*** tpollard_ [] has joined #baserock13:43
*** jonathanmaw_ [] has joined #baserock13:43
*** Blacksnow [] has joined #baserock13:43
*** flatmush1 [] has joined #baserock13:44
*** jonathanmaw [] has quit [Ping timeout: 250 seconds]13:45
*** sambishop [] has quit [Ping timeout: 250 seconds]13:45
*** CTtpollard [] has quit [Ping timeout: 258 seconds]13:45
*** ssam2 [] has quit [Ping timeout: 245 seconds]13:45
*** violeta [] has quit [Ping timeout: 246 seconds]13:46
*** flatmush [] has quit [Ping timeout: 272 seconds]13:46
*** Krin [] has quit [Ping timeout: 272 seconds]13:46
*** fay_ [] has quit [Ping timeout: 260 seconds]13:46
*** dutch_ [] has quit [Ping timeout: 260 seconds]13:46
ridgerunnerOK, when I reboot the TK1, I get offered a choice of 1. Factory and 2. ridgerunner. I selected 2 and it booted successfully.13:49
SotKridgerunner: great :)13:50
jonathanmaw_ is now known as jonathanmaw13:50
ridgerunnerjooi, how does the bootloader know that there are now two systems on the disk?13:51
pedroalvarezwhen upgrading the system, the bootloader gets updated13:52
richard_mawconfig file for bootloader gets updated13:52
flatmush1 is now known as flatmush13:52
* pedroalvarez is not familiar yet with these terms13:53
paulsher1oodridgerunner: uname -a13:59
paulsher1ooddid it actually boot into 2. ?13:59
paulsher1oodsystem-version-manager get-running13:59
paulsher1oodridgerunner: ^^14:00
*** thecorconian [] has joined #baserock14:05
ridgerunnerSorry paulsher1ood my notifications cript failed again.14:07
ridgerunneruname -a returned: Linux baserock-jetson 3.10.24-gde3664e #1 SMP PREEMPT Wed Sep 24 12:02:11 UTC 2014 armv7l GNU/Linux14:07
ridgerunnerWhich sounds, to me, pretty good. Is it?14:07
paulsher1oodsysem-version-manager get-running (should tell you you're still in factory, if i'm not mistaken)14:08
ridgerunnerThat returns: [ 1349.746666] device label baserock devid 1 transid 1618 /dev/mmcblk0p114:10
ssam2_that's a kernel message that happened to be dumped on your console, not the output of `system-version-manager get-running`14:10
ssam2_i realise it's hard to tell the difference between those two things14:10
ridgerunnerIt pretty reliably displays that when I enter the command. Oh, and it has "ridgerunner" at the end but line wrap cut it off when I pasted.14:11
pedroalvarezthat sounds good then :)14:11
ridgerunnerThe transid changes (-> 1619, 1620, 1620...)14:12
SotKI assume you changed self to jetson on your deploy command then?14:12
ssam2_ridgerunner: the tool mounts your root disk, which causes the kernel to log a message, which happens to go to your console14:12
ssam2_it'd be nice if that didn't happen, but I'm not sure what we'd need to tweak14:13
SotKhooray, fuel-stop-advisor is finally built14:13
pedroalvarezSotK: great!14:13
paulsher1oodSotK: WOW! w00t! Fred at Wind River will be pleased :)14:13
SotK*built*, not running yet :P14:13
ridgerunnerSotK: I don't know what that means.14:14
paulsher1oodSotK: he'd probably be even more pleased if it stays like that :)14:14
SotKpaulsher1ood: indeed14:15
ridgerunnerSotK: that is re "self" not re "fuel-stop-advisor"14:15
paulsher1oodridgerunner: can you confirm what you did to achieve this 'working' upgrade? did you have to change anything vs the instructions on the wiki?14:15
paulsher1oodor modify jetson-upgrade.morph?14:15
SotKridgerunner: when you did morph deploy --upgrade, what was the full command? :)14:15
ridgerunnerHang on, I'll go back up the buffer...14:16
ridgerunnermorph deploy --upgrad14:16
ridgerunnere jetson-upgrade.morph jetson.VERSION_LABEL=ridgerunner14:16
ridgerunnerscuse the line wrap14:17
ridgerunnerpaulsher1ood: the first thing I realised whe it failed last night was that I hadn't actually built the .morph file mentioned in the deploy script.14:17
SotKI guess switching from self.VERSION_LABEL to jetson.VERSION_LABEL fixed it then14:18
ridgerunnerI hope I'm using the right terms.14:18
*** tiagogomes [~tiagogome@] has joined #baserock14:18
* SotK wonders why the deployment "succeeded" when no hostname was given earlier14:18
ridgerunnerpaulsher1ood: So the TK1 spent a very large chunk of this morning doing that :-)14:19
ridgerunnerI had successfully built for a different target.14:19
ridgerunner+1 for morph giving me an error message that made it clear what my goof had been14:20
paulsher1oodridgerunner: alternatively you could have adjusted the target in the jetsion-upgrade.morph to reflecyt what you had built :)14:21
SotKnow to figure out what on earth the run script is doing14:21
paulsher1oodridgerunner: if you ssh in to your jetson you can a) avoid the kernel logs and b) have more history and no spurious linewrap14:21
ridgerunnerYes, I think I understand that now. But, of course, I then wouldn't have been able to deploy to the TK114:21
paulsher1oodyes you would, assuming you built a jetson system?14:22
ridgerunnerI do ssh in. I only use serial for the boot.14:22
paulsher1oodso the line-wrap is your terminal?14:22
ridgerunnerI think I had built a generic arm7xxx of the same processor type as the TK1, I was just trying to firure out how to get Baserock going, nit neccessarilt do anything useful per se.14:23
* pedroalvarez realises that our initramfs system kind of big, 114M14:24
pedroalvarezI somehow expected it to be smaller than that14:24
ridgerunnerre line wrap: yes, I haven't quite figured out why sometimes wrapped lines will transcribe with no newline, other times it puts a (very annoying) new line in at the wrap point.14:24
paulsher1oodall of our sytems could do with a diet14:24
ridgerunnerI think my sausage fingers could do with going on a diet. They might it the correct keys then/14:25
richard_mawpedroalvarez: hm, it used to be smaller14:25
ridgerunner*HIT* dammit *HIT*14:26
ridgerunnerI need a cuppaT14:26
pedroalvarezridgerunner: if you were getting kernel messages when running `system-version-manager get-running`, then I think you are not using the ssh session14:27
* paulsher1ood contemplates trying the upgrade again14:27
richard_mawpedroalvarez: the initramfs is big because gcc-libs contains stuff from /usr/libexec14:28
richard_mawa large amount of the initramfs size is probably because we've accidentally fot the gcc compiler backends included14:28
* pedroalvarez hacks the bugsmagnet of paulsher1ood14:29
richard_mawpedroalvarez: if you want to make it tiny again, you could try adding the products: fields from
pedroalvarezI'd like it to be tiny, yeah14:31
pedroalvarezI'll try to add that14:31
richard_mawunfortunately it's going to require rebuilding everything from build-essential upwards14:31
pedroalvarezyeah, but IMO is a nice improvement14:32
ridgerunnerpedroalvarez: Darn it, you're right I picked the wrong window.14:32
ridgerunnerThey are in adjacent tabs :-(14:33
ridgerunnerOn an ssh session it just outputs "ridgerunner". Which means it wasn't line wrap at all. Ho hum.14:34
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 250 seconds]14:36
*** thecorconian [] has quit [Remote host closed the connection]14:37
pedroalvarezrichard_maw: yeah, 289M of libexec14:37
*** thecorconian [] has joined #baserock14:37
pedroalvarez* /usr/libexec14:38
*** tiagogomes [~tiagogome@] has joined #baserock14:49
violeta_ridgerunner, how long did the upgrade take to build?14:51
violeta_ is now known as violeta14:51
*** thecorconian [] has quit [Quit: Leaving.]14:52
doffmHi guys, I'm still having difficulty lorrying some packages. If you take a look at there are alot of 'python-packages' that are scheduled to be lorried that arn't present in
doffmIts been stuck in that state for a while and I don't have any error output.15:02
KinnisonCan you give us a list of the failing lorries, we think there was an FS issue which led to non-continuable lorries in some cases15:02
doffmKinnison: Sure. I think its a long list.15:04
Kinnisonno probs, if you have a list, we can cross-check it against the todo list of things we know are wrong15:05
Kinnisonif your list contains things we're not aware of, then that'll help us find other things to check for15:05
pedroalvarezrichard_maw: i rebased your gcc finer splitting in definitions.git (baserock/pedroalvarez/finer-splitting-gcc)15:05
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 260 seconds]15:21
doffmKinnison: There might be a few more, but thats what I think i'm missing.15:24
doffmall under 'python-packages'15:24
Kinnisondoffm: ta, I'll just turn that into something I can use :-)15:25
Kinnisonis that *all* of python-packages/ or just some?15:25
doffmJust some.15:26
doffmAbout 50% :)15:26
*** tiagogomes [~tiagogome@] has joined #baserock15:32
Kinnisondoffm: interesting intersection but neither ours nor yours is a subset :-(15:34
* Kinnison will investigate15:34
cyndis_ is now known as cyndis15:37
pedroalvarezKinnison: to start te investigation;
* pedroalvarez releases tje 12765 port of g.b.o15:49
paulsher1oodpedroalvarez: is that public?15:49
pedroalvarezwrong channel15:50
pedroalvareznothing private, though, here is a public copy:
pedroalvarezsome lorry errors15:51
Kinnisondoffm: Right, I've worked out what's going on, we just need to work out the best way to fix things15:52
jjardonssam2_: fix coming for the NetworkManager issue15:53
doffmKinnison: Whats the problem?15:53
Kinnisondoffm: I think there was some corruption on g.b.o at some point15:53
doffmOh dear.15:54
Kinnisondoffm: we're currently tracing the extent of the damage so we can do some restores15:54
jjardonoh Its already there: ;)15:55
jjardonI think the upgrade to new linux-headers is still worth though15:56
* paulsher1ood confirms that he can build and use latest cmake in baserock, on top of our bootstrapped cmake16:03
ssam2_jjardon: oh, interesting16:06
jjardonpaulsher1ood: upgrade everything! :)16:06
ssam2_still, cleaning up the linux-api-headers branch was worthwhile, I guess16:06
ssam2_in fact, I just successfully built the genivi baseline on x86_64 with that branch, so I guess I'll send a patch for definitions16:07
jjardonssam2_: sure16:07
ridgerunnervioleta: you asked how long the upgrade took. The actual morph deploy --upgrade only took a few minutes. The preceding build took about another 10 minutes but I had previously run a build for the same processor (arm7lhf) which had taken about 3 hours 25 minutes. I suspect if I had gone straight to the correct build it would have been about three and a half hours.16:13
paulsher1oodi fear i've asked this before - is there a good reason why morph and tbdiff should be in with other stuff? why not have a baserock-tools stratum?16:16
violetaridgerunner, I'm 1.30h into the 3.30h build, thanks ;-)16:16
paulsher1oodwe need to establish a public distbuild network for jetsons16:17
ridgerunnervioleta: the other thing I have determined is that you can control-C a build and then run it again later and it will resume more or less where it left off.16:19
ridgerunnerVery handy if you don't want to leave something on overnight :-)16:19
violetayes, very handy, thanks16:19
*** genii [~quassel@ubuntu/member/genii] has joined #baserock16:23
ssam2_paulsher1ood: I don't remember you asking that. Not sure of any convincing arugments either way16:24
paulsher1oodwhy would you not leave it overnight?16:24
paulsher1oodit's not like a build needs a babysitter!16:24
rjekwin 2116:26
* rjek is paulsher1ood 16:26
*** jonathanmaw [] has quit [Quit: Leaving]16:32
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 260 seconds]16:39
paulsher1oodERROR: System time is far in the past, please set your system clock16:40
paulsher1oodon jetson... that's a first for me :)16:40
rjekDoes jetson have an RTC?16:40
paulsher1oodnormally yes, i think16:41
rjekHave you ever put truth into it? :)16:42
paulsher1oodreboot, same problem. dead battery, maybe? doesn't baserock get its time from the network anyway?16:43
rjekIIRC, the ntp client may panic and not touch the clock if it's /way/ out16:45
ssam2_baserock spams your console with systemd error messages if it failed to get the time from the network, in my experience16:45
rjekAlso, not sure if Baserock does the "write system clock back into RTC" thing at shutdown16:45
rjekpaulsher1ood: Probably the best approach is to set the time manually with `date`, shutdown cleanly, reboot, see if it's happier.16:46
paulsher1oodi'm back in Feb 2000...  probably in Sweden, celebrating16:46
jjardonis baserock using the same kernel for all the bsp or different one?16:49
ssam2_jjardon: same commit of Linux for all systems, I believe16:50
paulsher1oodjetson kernel is the nvidia one by default16:50
paulsher1oodso different16:50
ssam2_ah, true16:50
ssam2_different kernel config for each system, too16:51
* paulsher1ood and bash date are confusing each other. now i'm in 2012 - marty mcfly is dating my daughter16:51
jjardonssam2_: ah, ok. the version to build is replicated in every bsp, rigth? It would be good to have that in a single place instead but not sure if you can specify a different morph file depending on some configuration parameter ?16:53
paulsher1oodi mean wtf16:53
jjardonpaulsher1ood: date --set 20140925190016:55
Kinnisonand then hwclock --systohc16:57
*** Blacksnow [] has quit [Remote host closed the connection]17:02
*** ssam2_ [] has quit [Remote host closed the connection]17:09
paulsher1oodthat worked, thanks17:13
*** dutch__ [] has quit [Ping timeout: 250 seconds]17:30
*** dutch__ [] has joined #baserock17:47
jjardonany idea why lsmod doesnt work in genivi-baseline system?17:48
*** SotK [] has quit [Remote host closed the connection]17:53
*** ridgerunner [] has quit [Remote host closed the connection]17:53
*** jmacs [] has quit [Read error: Connection reset by peer]17:53
*** paulsher1ood [] has quit [Read error: Connection reset by peer]17:53
*** benbrown_ [] has quit [Read error: Connection reset by peer]17:53
*** petefoth [] has quit [Read error: Connection reset by peer]17:53
*** mwilliams_ct [] has quit [Read error: Connection reset by peer]17:53
*** pdar [] has quit [Read error: Connection reset by peer]17:53
*** liw-orc [] has quit [Quit: Coyote finally caught me]17:53
*** dutch__ [] has quit [Quit: Quit]18:30
*** doffm [~mdoff@] has quit [Remote host closed the connection]18:36
*** ridgerunner [] has joined #baserock19:31
*** tiagogomes [] has joined #baserock19:32
*** tiagogomes [] has quit [Client Quit]19:34
pedroalvarezjjardon: if it should work make is because we remove all the gplv3 chunks from the system 20:47
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]21:42

Generated by 2.14.0 by Marius Gedminas - find it at!