| persia | Catching up on the ML: did the 404s at http://cache.baserock.org:8080/ get resolved? Is this a filtering issue, or something more complex? | 03:36 |
|---|---|---|
| persia | Also, now that we have a nice system with a nice name, how would I go about submitting changes to cause it to provide x86_32 artifacts as well? | 03:36 |
| *** elevenarms__ [~elevenarm@c-69-181-189-77.hsd1.ca.comcast.net] has quit [Quit: Be back later ...] | 04:53 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:03 | |
| paulsher1ood | persia: I believe that petefoth had misunderstood how this works - cache.baserock.org:8080 is working fine for morph. it's just that url is not browsable. maybe we could extend the api to report something useful there, but i'm not sure it's worth the effort | 08:24 |
| paulsher1ood | s/that url/the root url/ | 08:25 |
| paulsher1ood | persia: by submitting changes, do you mean code? if so, mailing list i think | 08:25 |
| petefoth | paulsher1ood: indeed I was trying to browse to that url. Failed to understand / notice that was not its purpose :( | 08:26 |
| paulsher1ood | petefoth: no problem. i did the same originally... the only diff is i didn't email the list :-) | 08:26 |
| petefoth | paulsher1ood: :) | 08:27 |
| persia | paulsher1ood: Heh, of course the lst, but I don't know precisely what is needed. I presume a tested cluster morphology (or an extension to the existing one), but I'm not sure of the details. | 08:27 |
| petefoth | paulsher1ood: before I go searching, did you find the Storyboard roadmap that krotschec referred to in #storyboard? | 08:29 |
| paulsher1ood | nor am i, sadly, persia. this seems to fall somewhere between the current mason which folks don't want to improve, because it's only a poc, and future mason which doesn't exist yet | 08:30 |
| paulsher1ood | petefoth: https://wiki.openstack.org/wiki/StoryBoard/Roadmap | 08:31 |
| persia | It's not just that, it is also that the deployments into production seem to be non-automated: the deploy commands we're using for infrastructure don't seem to be in a git repo anywhere. | 08:31 |
| petefoth | paulsher1ood: tvm | 08:31 |
| paulsher1ood | incidentally, i like how logical that url is | 08:31 |
| paulsher1ood | persia: that is probably true | 08:32 |
| persia | paulsher1ood: smaffuli just completed a large effort to more logically structure all those URLs :) | 08:33 |
| paulsher1ood | persia: but in the context of this, where is the deploy? current mason just builds stuff, successfully or not, from master definitions? and cache is populated as a by-product of that i think? | 08:33 |
| persia | Right, so the changes would be to cause to exist a mason for the desired architecture, deployed in such a way to populate that cache. | 08:34 |
| paulsher1ood | persia: pity they are case-sensitive! :) | 08:34 |
| paulsher1ood | persia: yup | 08:34 |
| persia | mediawiki | 08:34 |
| paulsher1ood | sucks, imo. :-) | 08:34 |
| paulsher1ood | oops. i should never do that. i'm sorry, any mediawiki fans | 08:35 |
| petefoth | so w.b.o should have urls like mason/reference-manual and (some more examples that I haven’t made up yet). WE could look at the structure for the wiki that was proposed in the ML and restructure the urls to match | 08:35 |
| paulsher1ood | we've had lots of good use out of mediawiki. | 08:35 |
| persia | They volunteered, and made lots of changes to meet the desires of the openstack folk. | 08:35 |
| paulsher1ood | petefoth: talk is cheap :) | 08:35 |
| persia | petefoth: I don't think current mason ought be documented, because I'll be delighted when it dies (I liked the previous jenkins-based Mason better) | 08:36 |
| paulsher1ood | persia: i disagree. the previous one didn't really work, afaict. this one seems to :) | 08:36 |
| petefoth | paulsher1ood: https://trello.com/c/t0M2NL9L/18-experimental-restructured-wiki-to-match-documentation-complexity-email-thread - it’s on my ToDo list | 08:36 |
| persia | But rather, I think that we need a way to store operational deployments for automation, and we ought be doing that as best-practice in the baserock project. | 08:36 |
| persia | And I want to add to that (by using the existing scripts as reference) another architecture. | 08:37 |
| * paulsher1ood sighs...the kanban wars are like the wiki wars all over again | 08:37 | |
| paulsher1ood | persia: acknowledged, and i wholeheartedly agree | 08:37 |
| * persia suspects that two non-operators agreeing doesn't help as much as it might seem | 08:38 | |
| paulsher1ood | persia: i think we have some standing in the community... | 08:38 |
| paulsher1ood | but you're right :) | 08:38 |
| paulsher1ood | (and maybe i'm deluding myself about the standing) | 08:39 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:48 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:03 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:04 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:11 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:24 | |
| pedroalvarez | good morning! | 09:27 |
| paulsher1ood | hi! | 09:27 |
| pedroalvarez | I wonder if we are going to do something with the systemd misconfiguration, and if anybody else is having problems with it | 09:28 |
| persia | Which systemd misconfiguration? | 09:28 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:29 | |
| pedroalvarez | network configuration, networkd is configured to use DHCP in en* interfaces, but my systems is still having eth* interfaces for ethernet | 09:29 |
| pedroalvarez | s/is/are/ | 09:29 |
| persia | Oh, ugh. | 09:33 |
| *** ssam2 [~ssam2@cpc7-asht7-2-0-cust170.10-1.cable.virginm.net] has joined #baserock | 09:48 | |
| Mode #baserock +v ssam2 by ChanServ | 09:48 | |
| rdale_ | i've just tried to push a branch to baserock/definitions but i'm not authorized | 09:56 |
| pedroalvarez | rdale_: odd.. can you `ssh git@git.baserock.org whoami` | 09:56 |
| rdale_ | it lists my laptop ssh key ok | 09:58 |
| pedroalvarez | rdale_: I'm interested on the groups that this commands lists | 09:58 |
| pedroalvarez | I assume you need to be in "baserock-writers" | 09:58 |
| rdale_ | local-config-writers: Users who are permitted to write to the local-config project | 09:59 |
| pedroalvarez | and I assume you already are in "local-config-writers:" | 09:59 |
| rdale_ | i'm not in baserock-writers then | 09:59 |
| pedroalvarez | i don't have permissions to add you, I believe that richard_maw can do that | 10:00 |
| rdale_ | ok | 10:00 |
| pedroalvarez | has anybody built mesa since the latest upgrade on armv7lhf? : http://paste.baserock.org/ipobunatij | 10:01 |
| * pedroalvarez upgrades his baserock-almost-14 system using cycle.sh | 10:06 | |
| pedroalvarez | looks like to have a version with eglibc and a version with new glibc living together in the same baserock system, you need 4.5G | 10:07 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:11 | |
| ssam2 | rdale: hi! you should be a member of baserock-writers now and be able to push | 10:13 |
| ssam2 | sorry, must have been an oversight that you were only given access to local-config/lorries.git ! | 10:13 |
| ssam2 | pedroalvarez: once we have some infrastructure i'd really like to actually implement stripping of debug symbols at build time! | 10:14 |
| persia | Hrm? Did I miss the mail about rdale_ being added to the set of folk who can commit? | 10:22 |
| persia | Or do I misundestand the procedures? | 10:22 |
| ssam2 | rdale_ has had commit access for a couple of years, but had let it lapse. That's my understanding, anyway. | 10:23 |
| pedroalvarez | it is also my understanding | 10:23 |
| rdale_ | yes, i think i used to have write access | 10:23 |
| persia | I'm not good at email, so it might be failure to read, but I believe we should document such changes by list traffic. | 10:25 |
| persia | I can imagine a case where someone who once had access might be expected to do some work (as rdale has been) for a while before having access restored. | 10:25 |
| persia | Note that I'm making a procedural fuss: I'm more than happy with rdale having access. | 10:25 |
| ssam2 | persia: fair point. would you be happy if I sent a mail to baserock-dev explaining that I re-added his access ? | 10:26 |
| persia | Entirely, along with the rationale. Extra points for convincing someone to +1 it :) | 10:26 |
| straycat | I'm not sure it's reasonable to allow more than 2 people named Richard push access to definitions on gbo | 10:26 |
| persia | heh | 10:27 |
| pedroalvarez | It's unlikely that there is another Pedro :) | 10:27 |
| * pedroalvarez gets a grammar book | 10:28 | |
| straycat | I'm more worried that outsiders might think we have some sort of bias promoting people named Richard above others | 10:28 |
| rdale_ | although i don't have a beard | 10:29 |
| ssam2 | we also have a pretty bad bias against people with names beginning with X. I don't think we have a single committer whose name begins with X, actually. | 10:29 |
| petefoth | How can I find out who w.b.o user ‘Robert’ is? He has made some wiki changes that I would like to understand better | 10:29 |
| pedroalvarez | Xavier? | 10:29 |
| pedroalvarez | petefoth: Robert Jones? | 10:30 |
| ssam2 | petefoth: I think it's bashrc | 10:30 |
| ssam2 | petefoth: I used intuition rather than any technical solution to work that out, though | 10:30 |
| pedroalvarez | indeed, because bashrc is Bob, here at least | 10:31 |
| petefoth | pedroalvarez: ssam2: thanks. It would be good to be able to identify users of the wike edit-in-place functionality | 10:31 |
| ssam2 | yes. Once we have our own OpenID provider we could potentially limit wiki access to those with Baserock OpenIDs, perhaps | 10:32 |
| ssam2 | although that would raise the barrier for contributing a little, which I don't particularly like | 10:32 |
| ssam2 | there may be a way to go from a Google OpenID to a full name | 10:32 |
| ssam2 | I don't know what it is, though | 10:33 |
| persia | There isn't, and Google has been making noises about deprecating OpenID support for some time. | 10:33 |
| petefoth | bashrc is Bob Mottram, who may or may not be Robert on w.b.o! | 10:35 |
| ssam2 | I know that Bob likes emacs, that's why I figured it might be him who added those instructions ;) | 10:37 |
| pedroalvarez | oh, bob == robert?? | 10:39 |
| ssam2 | Indeed. If that doesn't blow your mind, did you know Jack is actually short for John? | 10:40 |
| richard_maw | THEY'RE THE SAME LENGTH | 10:40 |
| ssam2 | it dates from the days when it was traditional for a guy named John to name his first son John, at which point you need a way of distinguishing them. | 10:40 |
| bashrc | petefoth: bashrc/bmottram | 10:41 |
| pedroalvarez | other that john junior? | 10:41 |
| Kinnison | richard_maw: Kate is short for Bob, so I don' tknow what you're whinging about :-) | 10:41 |
| pedroalvarez | meh | 10:41 |
| De|ta | :D | 10:42 |
| pedroalvarez | Pepe is short of Jose :) | 10:42 |
| petefoth | bashrc: yes I got that, but are you also SUer Robert on wiki.baserock.org? | 10:42 |
| bashrc | no | 10:42 |
| richard_maw | I think "short for" got confused for "shorter than" | 10:42 |
| petefoth | bashrc: OK thanks | 10:42 |
| ssam2 | bashrc: ah! my apologies for assuming it was you. | 10:43 |
| bashrc | I have edited the wiki in recent times. I don't think I supplied any credentials though so the edits are probably just anon | 10:43 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [] | 10:43 | |
| bashrc | I added some image hashes and some startup instructions for getting a VM going | 10:44 |
| petefoth | bashrc: were you ctearing and editing the guides/vm-script page? | 10:44 |
| petefoth | s/ctearing/creating/ | 10:44 |
| bashrc | yes | 10:44 |
| petefoth | In that case tou *are* user ‘Robert’ :) | 10:45 |
| petefoth | I am looking at that apge and working out where it mignth fit in best to the wikie structure, boith as it is and as proposed in the 'Documentation Complexity' email thread (http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-October/008897.html) | 10:46 |
| petefoth | But I don’t have any answers yet, and I may have to do some other stuff first | 10:47 |
| bashrc | petefoth: it must have generated that username automagically from my Google account | 10:49 |
| petefoth | bashrc: Indeed. | 10:49 |
| * bashrc unmasked again! | 10:49 | |
| paulsher1ood | github has decided i'm not human.... wtf???? | 10:54 |
| bashrc | really?? | 10:54 |
| paulsher1ood | yup. they've taken down my profile | 10:54 |
| bashrc | I don't remember github having CAPTCHAS | 10:54 |
| bashrc | eesh. Any reasoning to it? | 10:55 |
| straycat | wow | 10:55 |
| pedroalvarez | paulsher1ood: yeah, they decided that you should stop hacking :) | 10:55 |
| Kinnison | paulsher1ood: how strange | 10:56 |
| bashrc | :) but seriously, if github are doing that arbitrarily that's worring | 10:56 |
| bashrc | s/worring/worrying | 10:56 |
| * Kinnison checks his github identities | 10:56 | |
| paulsher1ood | "One of our mostly harmless robots seems to think you are not a human. | 10:57 |
| paulsher1ood | Because of that, it's hidden your profile from the public. If you really are human, please contact support to have your profile reinstated. | 10:57 |
| paulsher1ood | We promise we won't require DNA proof of your humanity." | 10:57 |
| jmacs | Gosh | 10:58 |
| richard_maw | ah, cutesy messages | 10:58 |
| bashrc | jeepers | 10:58 |
| * petefoth signs in to github and is reminded he has a repo called Hobokan - eeek! | 10:58 | |
| robtaylor | paulsher1ood: mm, this is why i've decided to steer clear of proprietary centralised services for my code! | 11:05 |
| * rjek read that as petefoth sighs into github | 11:05 | |
| petefoth | rjek: that too! | 11:05 |
| * straycat has been using bitbucket since 2011 and hasn't had any reason to complain | 11:07 | |
| paulsher1ood | just when robtaylor expresses preference against github, it drops my profile... coincidence? :) | 11:07 |
| straycat | Though it would be nicer to use something open source ofcourse. | 11:07 |
| Kinnison | paulsher1ood: presumably if you contact their support they'll fix things | 11:07 |
| paulsher1ood | i have done. and tweeted. dunno what more to do, except switch to something else :_) | 11:08 |
| paulsher1ood | anyway, sorry for the noise, i'm in a venting mood :) | 11:08 |
| straycat | if you have your own server gitano works very well | 11:09 |
| robtaylor | paulsher1ood: they must have been listening to us all the time! maybe facebook feeds them info by listening on the messanger app? =) | 11:09 |
| paulsher1ood | no facebook here | 11:09 |
| robtaylor | paulsher1ood: There was on my phone though... DUM DUM DUUMMMMM | 11:10 |
| * robtaylor may be in a silly mood today | 11:10 | |
| paulsher1ood | it appears my github profile is alive again... | 11:51 |
| Kinnison | paulsher1ood: what had happened? | 11:51 |
| paulsher1ood | no clue.. | 11:52 |
| rjek | A robot decided paulsher1ood was a robot. | 11:52 |
| paulsher1ood | ah.... email response ... 'Sorry for the trouble. We use some automated measures to fight spam, and your account was incorrectly flagged as spammy. I've cleared that flag now, so everything should be back to normal.' | 11:53 |
| * straycat could do with http://sprunge.us/SeVV now | 11:53 | |
| paulsher1ood | straycat: does it need to be in master? | 11:58 |
| paulsher1ood | (of definitions) | 11:58 |
| paulsher1ood | (for what you're doing) | 11:58 |
| straycat | if anybody wants to import python packages they'll need the patched version of pip | 11:58 |
| paulsher1ood | straycat: would be better if proposed a patch which was potentially upstreamable, rather than hacky? | 12:00 |
| * paulsher1ood is reluctant to approve a patch which we know is not good enough | 12:00 | |
| straycat | it's good enough for us | 12:01 |
| straycat | right now the main thing is that we have a way to import python packages | 12:01 |
| straycat | I can ask upstream how best to go about it once we're happy with the import tool | 12:02 |
| persia | Is there any reason we need that order? I'd be happy with a hacky patch if there was active discussion upstream that could lead to fixing it. | 12:03 |
| persia | One of the lovely things about how definitions work is that one can jump to git branches that don't include the history of prior refs, so one has less worries about dead-end patches. | 12:04 |
| paulsher1ood | straycat: i'm disagreeing, i'm afraid. i don't think we should apply a lower standard of review to some patch we create for an upstream, than we do to patches we create to code in baserock in general? | 12:04 |
| Kinnison | While I agree that carrying patches upstream won't like is a potential stone around our neck, it's also sometimes the only way to get enough of a prototype together to convince upstream of our usefulness | 12:06 |
| paulsher1ood | fair point | 12:06 |
| Kinnison | We shouldn't not review it | 12:07 |
| Kinnison | but we shouldn't say "upstream won't like this" as a reason to veto | 12:07 |
| paulsher1ood | so if others want to +1 straycat's propsal, i'm ok | 12:07 |
| Kinnison | paulsher1ood: you should make your concern known on-list, but I'd be confused if, based on what you've said here, you gave it -1 | 12:07 |
| Kinnison | paulsher1ood: I can understand -0 for "I don't like it but I'm not vetoing it" though | 12:07 |
| * paulsher1ood doesn't consider himself competent enough to review python | 12:08 | |
| * persia wants the discussion with upstream to have begun, regardless of the conclusion. Carrying patches without discussion leads to disagreements and blandishments and annoyed upstreams. | 12:08 | |
| * Kinnison believes straycat has been talking with upstream on IRC | 12:08 | |
| * straycat has every intention of discussing with upstream | 12:08 | |
| straycat | It's just that currently I'm focusing on the tool itself. | 12:08 |
| persia | That's fine. Mentioning IRC discussion in the cover letter is sufficient for me. | 12:08 |
| paulsher1ood | Kinnison: i'm not -1, or even -0 | 12:10 |
| Kinnison | paulsher1ood: fair enough | 12:10 |
| Kinnison | persia: that'd be a good approach | 12:10 |
| *** robtaylor [~robtaylor@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Bye!] | 12:10 | |
| Kinnison | straycat: can you follow up with any notes from any chats you *have* had, and any details of overtures you intend to make going forward, I think that'll be enough to convince most people | 12:10 |
| persia | The key thing is that in the event things get odd, it is exceedingly helpful to be able to point to old mail messages detailing that discussion was had. | 12:11 |
| paulsher1ood | one thing - is the patch in question actually in the emailed patch series? or just a ref to it? | 12:11 |
| persia | Once everyone agrees any disagreements are accidental, fixing things becomes lots easier. | 12:12 |
| straycat | Kinnison, *nod* I haven't spoken to them about this patch, yet, again because my main focus is the tool itself | 12:14 |
| jjardon | http://cache.baserock.org:8080/ <-- amazing | 12:16 |
| jjardon | is that configured by default in the baserock images? | 12:16 |
| paulsher1ood | jjardon: no, but we can fix the wiki instructions (and should do) | 12:17 |
| persia | Why not just fix the default of morph? | 12:18 |
| paulsher1ood | we should do that too :-) | 12:18 |
| persia | With the cache server, and the patch pedroalvarez recently sent for more architectures, this will make everyone faster. | 12:18 |
| paulsher1ood | up | 12:18 |
| paulsher1ood | yup | 12:18 |
| jjardon | mmm, cant edit the wiki: "Error: OpenID failure: naive_verify_failed_network: Could not contact ID provider to verify response." | 12:19 |
| * paulsher1ood tries | 12:19 | |
| jjardon | nevermind, it worked with another gmail account | 12:19 |
| paulsher1ood | have you done it? | 12:20 |
| * paulsher1ood was going to do it | 12:20 | |
| jjardon | paulsher1ood: done, feel free to review | 12:28 |
| * jjardon thinks maybe this should be more publicity available, IMHO is one of the main features of baserock | 12:29 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 12:35 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:35 | |
| petefoth | How lomg does it take to kickstart the storyboard - it’s still not there :( | 12:38 |
| paulsher1ood | jjardon: don't tell everyone, or the bandwidth costs will kill us :-) | 12:39 |
| petefoth | sorry - wrong window. (first in a long time :) | 12:40 |
| paulsher1ood | jjardon: i've changed it... http://wiki.baserock.org/quick-start/?updated#index4h2 | 12:43 |
| jjardon | paulsher1ood: thanks, I like that more | 12:44 |
| paulsher1ood | tmv | 12:44 |
| paulsher1ood | tvm | 12:44 |
| paulsher1ood | will someone submit a patch to make morph default to this, or shall i? | 12:45 |
| pedroalvarez | I'm not sure if morph should default to this | 12:50 |
| pedroalvarez | I assume that morph is defaulting to TROVE_HOST:8080 | 12:51 |
| pedroalvarez | so when someone else creates a trove, he can populate its cache, and then this default value is ok | 12:52 |
| persia | But most folk don't have troves. | 12:53 |
| persia | Especially most folk downloading an image for the first time. | 12:53 |
| pedroalvarez | so, the patch would be that morph uses cache.baserock.org, but if there is a TROVE_HOST configured in /etc/morph.conf use TROVE_HOST:8080? | 12:54 |
| persia | I think we should *support* setting a different cache host in morph.conf, but defaulting to "git.baserock.org" is just broken: not only is that cache usually out of date, but it specifically reinforces the idea that the artifact cache and the git server need to be the same machine. | 12:54 |
| persia | pedroalvarez: That would be an ideal patch from my perspective, yes. | 12:54 |
| pedroalvarez | git.baserock.org cache is not broken. it just only have cache for latest releases | 12:55 |
| persia | I'd also like to drop "TROVE_HOST" in favour of separate specification of curated archive and cache server, but that's a separate patch :) | 12:55 |
| persia | pedroalvarez: I assert that defaulting there is broken, not that the server is broken. The problem is that it is always out of date. | 12:56 |
| persia | So one cannot usefully follow development with that default. | 12:56 |
| pedroalvarez | persia: yeah, I agree | 12:56 |
| persia | Ah, good. Sorry for any confusion caused by my excessive verbosity. | 12:57 |
| pedroalvarez | well... I think we have to make a plan to clean cache.baserock.org | 12:59 |
| pedroalvarez | is going to be full of artifacts soon now that we are going to put more masons | 13:00 |
| pedroalvarez | btw, I've created an armv7lhf mason: http://85.199.252.156/ | 13:01 |
| pedroalvarez | but this mason is building also the genivi system, and looks like mesa doesn't buiild :/ | 13:02 |
| petefoth | persia: in your latest email to the list you mention ‘cross and canadian builds’. What’s a canadian build? | 13:03 |
| ssam2 | that's still fucking amazing that we can have an ARMv7lhf Mason! | 13:03 |
| ssam2 | even if the build log is pretty nonsensical. | 13:04 |
| persia | pedroalvarez: Never removing artifacts is the best plan. | 13:05 |
| radiofree | ERROR: Failed to build baserock:baserock/definitions 67be3d4a749a18d2e2ff3ce3dce3a1122e8bc89e systems/build-system-armv7lhf-jetson.morph: Building failed for pytz-misc | 13:06 |
| persia | petefoth: http://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross | 13:06 |
| radiofree | ERROR: In staging area /srv/distbuild/tmp/staging/tmpXFLQqE: running command 'sh -c make' failed. | 13:07 |
| radiofree | builds/build-step-itzam-tarball-misc.log | 13:07 |
| persia | petefoth: Also https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html | 13:07 |
| radiofree | ignore the builds/build-step-itzam-tarball | 13:07 |
| radiofree | *** [freedreno_screen.lo] Error 1 | 13:07 |
| radiofree | has the genivi image been updated to use the latest libdrm? | 13:07 |
| radiofree | with the freedreno api? | 13:07 |
| radiofree | jjardon: ^ | 13:08 |
| radiofree | this might be my fualt, when i +1'ed the new mesa, i had only tested it without freedreno support | 13:08 |
| radiofree | it's possible it needs a newever libdrm | 13:08 |
| pedroalvarez | radiofree: odd, that chunk is also in the devel system, not only in the build system | 13:09 |
| petefoth | persia: thank you. I don’t think I would *ever* have found those links | 13:11 |
| persia | The nomenclature is a bit eccentric :) | 13:12 |
| petefoth | persia: are you sure you are not British - http://www.understatementexamples.com/for/british-understatement/ | 13:14 |
| jjardon | radiofree: we are using baserock/jetson/drm so thats 2.4.56 + patches for tegra (latest is 2.4.58) | 13:16 |
| * straycat likes http://www.understatementexamples.com/understatement/ladies-and-gentlemen-this-is-your-captain-speakin/1039/ | 13:17 | |
| * persia also | 13:17 | |
| jjardon | radiofree: freedreno support is already in 2.4.56 | 13:18 |
| radiofree | jjardon: it's just according to that mason log, mesa failed to build freedreno | 13:20 |
| radiofree | which i hadn't tested when i gave it my +1, sorry :\ | 13:20 |
| jjardon | radiofree: so mesa in ARM is not building? | 13:20 |
| radiofree | i have no idea if it's just a glitch or not | 13:21 |
| radiofree | i'll test it at some point today | 13:21 |
| jjardon | oh, just see the pedroalvarez mesage about the arm mason | 13:21 |
| * jjardon taking a look | 13:21 | |
| radiofree | do you think we can make an assumption that most systems come with "pv" installed? | 13:25 |
| radiofree | the output for kill -USR1 $(pgrep ^dd) is a bit spammy | 13:25 |
| radiofree | actually scrap that, fedora doesn't | 13:25 |
| jjardon | pedroalvarez: what reference system is being build in cache.baserock.org? | 13:36 |
| jmacs | ssam2: What strata should I be importing to get as much chef support as possible? | 13:36 |
| jmacs | ruby, I'm guessing - anything else? | 13:37 |
| jjardon | radiofree: seems is actually a bug in mesa: we need libdrm 2.4.57 but mesa only checks for 2.4.55 | 13:47 |
| * jjardon happy to see baserock is already helping to fix bugs upstream :) | 13:47 | |
| ssam2 | jmacs: I pushed a branch a while back which has the chef client and all its RubyGem deps, it should still be there and should still work | 13:51 |
| ssam2 | jmacs: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/sam/chef | 13:52 |
| ssam2 | created with an old version of the import tool | 13:52 |
| jmacs | Couldn't find it on the mailing list | 13:52 |
| ssam2 | sorry, I never got to properly finishing it | 13:52 |
| jmacs | No problem, I'll give it a try. Thanks. | 13:52 |
| ssam2 | if you have problems, it may well make sense for me to spend time looking at it next week. We can discuss on Monday | 13:53 |
| ssam2 | chef has been a good way to drive the development of the Baserock Import tool, and in fact I think it's one of the original requirements for it | 13:53 |
| jmacs | Yep | 13:54 |
| jmacs | "Field x-build-dependencies-rubygems not allowed in morphology strata/chef/chef-master.morph" | 13:59 |
| ssam2 | jmacs: oh, yeah | 13:59 |
| ssam2 | could you remove the 'x-' fields from all the morphs in strata/chef/* and try again ? | 14:00 |
| ssam2 | I was using a patched morph that ignored all fields with 'x-' | 14:00 |
| jmacs | Sure | 14:00 |
| richard_maw | I had assumed we merged that change, I beliege I +1'd it | 14:00 |
| ssam2 | I think in the end I decided it wasn't needed | 14:00 |
| ssam2 | although my recent thinking is that it might be needed after all :) | 14:00 |
| ssam2 | one of the hard parts of the baserock-import tool is for it to look in an existing definitions.git and say 'hmm, I'm importing something called 'rake', but there's already a morphology for 'rake' -- is that an existing morph for the thing I'm trying to import, or a morph for a totally unrelated component that has the same name' ? | 14:01 |
| ssam2 | currently it punts on that problem and just adds everything, leaving the user to sort it out | 14:02 |
| *** persia [quassel@ubuntu/member/persia] has quit [Read error: Connection reset by peer] | 14:06 | |
| *** persia [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock | 14:06 | |
| *** persia [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host] | 14:06 | |
| *** persia [quassel@ubuntu/member/persia] has joined #baserock | 14:06 | |
| paulsher1ood | ssam2: can we be a bit smarter and look at the basename of repo: when comparing whether proposed 'rake' is the same as the 'rake' we already have? | 14:17 |
| ssam2 | that's harder than it should be because 'repo' is in the stratum, not the chunk | 14:18 |
| ssam2 | and 'rake' could be in many strata, or none | 14:18 |
| persia | Yet another argument for merging strata and chunks | 14:18 |
| ssam2 | indeed | 14:18 |
| ssam2 | I think adding x- fields would be better, because then we can keep track of what upstream version is in use | 14:19 |
| ssam2 | so the tool could tell if it's importing rake 2.1 and the existing definition is for rake 1.0 or something | 14:19 |
| persia | Ah, where it might even be the same git repo, but the versions are (importantly) different? | 14:21 |
| persia | I don't like your suggested nomenclature (with x-), because I consider that to be "experimental", or "extention", but otherwise I think I agree. | 14:22 |
| ssam2 | I was using the x- to mean exactly that, in fact :) | 14:22 |
| paulsher1ood | so on a related note... i'd like to submit patches to make all of our names for things unique... | 14:23 |
| persia | For testing, I liked your use of "x-": as a merge proposal, I'm unhappy with the idea. | 14:23 |
| paulsher1ood | so for example i would like to establish u-boot|jetson and u-boot|wandboard etc | 14:23 |
| persia | paulsher1ood: I'd like to see that. | 14:23 |
| pdar | I've noticed some repeated information at http://wiki.baserock.org/guides/build-failures/, is there a recomended procedure for changing this? Or editing w.b.o in general? | 14:23 |
| paulsher1ood | would folks be happy with that convention? | 14:23 |
| pedroalvarez | jjardon: x86_64 mason is just building the devel system | 14:24 |
| paulsher1ood | pdar: please fix what you think needs fixing, then mention that you've done so here | 14:24 |
| * richard_maw doesn't like the | symbol, and would prefer we were in a world where we don't care about duplicate names in definitions, so long as they're not involved in what you're building | 14:24 | |
| pedroalvarez | jjardon: arm one is building the devel and genivi system, but just because it's using clusters/release.morph | 14:24 |
| persia | paulsher1ood: I thought you wanted to use | for versions, whereas that sounds more like flavours to me. | 14:24 |
| * richard_maw would prefer @ for versions | 14:24 | |
| persia | richard_maw: That means we can't have any tooling that can inject stuff into definitions, because it can't know what you mean. | 14:25 |
| * persia likes the semantics of @ for versions (plus, I have an @ key, and I don't have a | key, making @ easier to type) | 14:25 | |
| paulsher1ood | persia: u-boot|jetson and u-boot|wandboard are different versions. i'm suggesting it could be equally u-boot|some-version-identifier - let users do what they want with this string | 14:25 |
| pdar | paulsher1ood: cool, thanks! | 14:26 |
| paulsher1ood | i'm ok with @ instead, i think, but | looks slightyl shinier to me | 14:26 |
| richard_maw | persia: you could if you tell it which system to start with, but this may not be a suitable time to discuss this | 14:27 |
| * Kinnison is worried that | has semantic meaning in yaml | 14:27 | |
| richard_maw | paulsher1ood: I object to |, since if we ever have command-line tooling that requires names, you'd have to escape the | symbol to avoid it being interpreted by the shell | 14:27 |
| paulsher1ood | richard_maw: as a user, i care to get us to avoid duplications, since they cause confusion. | 14:27 |
| Kinnison | also @ is read as 'at' rather than any of 'pipe' 'bar' 'given' etc. | 14:27 |
| paulsher1ood | richard_maw: ack. what would be the best symbol to use? | 14:27 |
| persia | richard_maw: Hrm. Maybe. On time: yes, we need to get through 1) runtime-depends ,2) merge chunks and strata, and 3) fix cache computation first. | 14:27 |
| * paulsher1ood thought of : for example | 14:28 | |
| Kinnison | colon is bad because shells | 14:28 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:28 | |
| paulsher1ood | ok, not |, not : | 14:28 |
| Kinnison | Lots of revision control systems use '@' for introducing a version | 14:28 |
| paulsher1ood | would there be consensus on @ ? | 14:28 |
| persia | And shells consider @ a normal character | 14:28 |
| * SotK likes @ | 14:28 | |
| persia | We could generate one if we all post to the mailing list fast :) | 14:28 |
| rjek | Many many many other things use @ to indicate revision or time. I think it would be surprising if we used something different. | 14:29 |
| paulsher1ood | ok, i'll submit a patch, to get the ball rolling | 14:29 |
| richard_maw | I have no objections to disambiguating chunks with "@$VERSION", but I'll resist attaching any semantic meaning to the version string after the @ | 14:36 |
| persia | richard_maw: Do you resist asserting that the string after the @ is for "version" as opposed to other classes of disambiguation? | 14:37 |
| richard_maw | I resist any form of machine parsing of the name or version string. I'm happy for it to be a nice human friendly description of what's provided | 14:38 |
| persia | Ah, so it must have arbitrary human meaning? My question was mostly about whether it must be a version. | 14:38 |
| persia | rake@1.0 vs. rake@2.1 is obvious. | 14:38 |
| persia | u-boot@devboardA vs. u-boot@devboardB is less obvious, especially if they both claim to be 2014.10 | 14:39 |
| paulsher1ood | in passing, what is the effect of a -1 vs two +1s? | 14:41 |
| Kinnison | a -1 from someone trusted is a veto | 14:41 |
| Kinnison | no amount of +1s and +2s should counteract it | 14:42 |
| paulsher1ood | ok. so... i wonder what the scores on the doors will be, for this... http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/ps/unique-u-boots&id=e40bd7f09c0f754b0dab83573ef4795137f4857b | 14:42 |
| persia | In the event that a -1 has been sitting around forever, despite folk trying to engage the -1'er, resubmitting the patch series should be considered an acceptable workaround. | 14:43 |
| persia | If the -1'er is responsive, this is nonoptimal, as it will just be -17d again. | 14:44 |
| paulsher1ood | persia: ack. i was just unclear about whether scores got added or not | 14:44 |
| paulsher1ood | anyway... if i submit the above, is someone going to -1 it? | 14:44 |
| * persia would +1 it as obvious, nondisruptive, and helpful | 14:45 | |
| richard_maw | paulsher1ood: it won't be from me, it's valid and allows the cases where we currently require unique names to work, +1 | 14:45 |
| paulsher1ood | ah,ok. that's great. i was misunderstanding the comment about semantic meaning of the version string. jetson and wandboard have semantic meaning, to me :-) | 14:46 |
| persia | The discussion was whether it could have specific semantic meaning, as opposed to human-readable meaning. | 14:47 |
| paulsher1ood | aha | 14:47 |
| persia | I believe we agreed on human-readable. | 14:47 |
| paulsher1ood | excellent | 14:47 |
| richard_maw | I might -1 anything that suggests we should be parsing the name e.g. using stuff after the @ as a replacement for the ref field | 14:47 |
| persia | So if it is required to be @jetson for a jetson system, there is too much magic, and exorcism is required | 14:47 |
| * paulsher1ood goes to write email | 14:47 | |
| paulsher1ood | understood | 14:48 |
| richard_maw | you've already got +2, so an email isn't required if you have your own push access | 14:48 |
| paulsher1ood | i see. i've never merged anything into master, as far as i remember | 14:49 |
| paulsher1ood | i'm a bit reluctant to start now, tbh. better that i continue to believe i can't do it ,to stop me trying in the dark hours of the weekend :) | 14:49 |
| richard_maw | strictly there's a risk that we've not given anyone time to -1 it, who might have good reason to, but reverting is easy enough | 14:49 |
| persia | Send it to the ML if you prefer, and we can do it all again via email. | 14:50 |
| paulsher1ood | can someone tell me their preferred merge git command sequence? | 14:51 |
| persia | git rebase master | 14:51 |
| persia | But I don't think that's the popular one around here :) | 14:51 |
| ssam2 | paulsher1ood: git merge --no-ff --no-commit | 14:52 |
| ssam2 | fix any conflicts, check it works, then 'git commit' and add Reviewed-By tags to the commit message | 14:52 |
| persia | That would be the popular one (that makes visualisation tools sad) | 14:52 |
| ssam2 | makes 'git log --topo-order' quite happy | 14:53 |
| mwilliams_ct | Hi baserockers :). I'm doing some looking into ZFS and whether we could get it on Baserock. I'm only just getting started on this, but one concern is that ZFS is licensed as CCDL which might mean we can't "ship" it as a kernel module. I briefly looked into DKMS as a way round this, but this is a bit un-baserocky. any thoughts? | 14:53 |
| ssam2 | if we can use such terms to describe inanimate bundles of code | 14:53 |
| * persia was thinking of things like gitk, gitg, tig, etc. | 14:53 | |
| persia | mwilliams_ct: According to http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue it seems that ZFS can never be merged, but can be distributed as source and as binary. | 14:55 |
| persia | So if you can create a chunk artifact that contains only the ZFS modules, you should be safe. | 14:55 |
| mwilliams_ct | ahh! OK I've misunderstood that then. thanks persia! Right now I'm focusing on building it at all | 14:56 |
| persia | DKMS is useful for environments where one updates the kernel separately from the modules, so one has to rebuild when the new kernel arrives. | 14:56 |
| persia | In Baserock, we don't do things that way. | 14:56 |
| persia | Since it is all a consistent system, we would autorebuild at build time, rather than when the kernel is updated. | 14:56 |
| paulsher1ood | ssam2: http://paste.baserock.org/akiveturoq.coffee ? | 14:57 |
| persia | That said, I'm not sure that shipping a system with working ZFS already baked in is sufficiently separate. | 14:57 |
| ssam2 | paulsher1ood: works for me | 14:57 |
| richard_maw | my previous discussions about this with rjek suggested that it might not be so clear cut, since in some interpretations you can't distribute binaries, but if the zfs project's interpretation is that you can distribute binaries, I think that counts for a lot | 14:57 |
| persia | It may be the case that we can populate the artifact cache with a ZFS module artifact, but not publish a reference image containing ZFS. | 14:57 |
| * persia would need to learn more to be confident suggesting references offering an authoritative opinion on this | 14:58 | |
| ssam2 | paulsher1ood: although since upstream master has moved, you'll need to 'reset --hard HEAD~1', 'pull --rebase', and do the merge again :( | 14:58 |
| ssam2 | at least, that's how I see it | 14:58 |
| ssam2 | (i note that I don't have a preferred merge workflow, I just value consistency) | 14:58 |
| persia | I just try to pretend I magically did everything 5 seconds ago: my local history is almost always wrong, but it means the merge command is easy to remember :) | 14:59 |
| * richard_maw grubles at protobuf's configure script attempting to download tarballs at configure time | 14:59 | |
| persia | (note, this strategy does not work for people who have shared their work) | 14:59 |
| rjek | richard_maw: ! | 14:59 |
| richard_maw | rjek: it tries to download gtest, as it assumes if you're not building a pre-packaged version you might want to run tests | 15:00 |
| persia | richard_maw: One of those: "it appears you don't have my favorite library: let me install it in some random way to build" things? | 15:00 |
| ssam2 | persia: tracker's git repo uses non-fastforward merges for feature branches and looks fine in 'tig' | 15:00 |
| ssam2 | persia: but it has various commits (translations etc) to master too | 15:00 |
| ssam2 | perhaps it's the fact that we have nothing but merge commits that makes tig produce confusing output | 15:01 |
| straycat | 11:54 ! straycat could do with http://sprunge.us/SeVV now | 15:02 |
| persia | ssam2: It isn't confusing, just wider than I'd prefer, because it keeps all these extra merged branches around. | 15:03 |
| persia | In my preferred workflow, my branches are private, and there are a few public branches for collaboration. | 15:03 |
| persia | Seeing every patchset as a branch in the history seems overly verbose to me. | 15:03 |
| ssam2 | straycat: if you'd like people of this channel to do something, direct requests are generally best. If you'd like patches reviewed I recommend sending them to the mailing list | 15:04 |
| straycat | it's a ref change | 15:04 |
| straycat | there's no need to for such ceremony | 15:04 |
| ssam2 | I can break every baserock system in definitions.git with one ref change | 15:05 |
| * straycat sighs | 15:05 | |
| ssam2 | I'm not trying to be awkward, simply advising why you might not be getting responses | 15:05 |
| persia | Didn't we talk about this before? | 15:06 |
| * persia is definitely -0 until upstream discussion happens, but isn't fussed enough to get in the way of other's positive votes. | 15:06 | |
| persia | s/happens/starts/ | 15:06 |
| straycat | Okay, I will send the pip patch for the associated change to the list | 15:09 |
| paulsher1ood | straycat: i'm guessing you're blocked until this lands? if so we can get it reviewed today | 15:11 |
| straycat | not blocked exactly, but i won't be around for a while over the next few weeks so I want to ensure this is all in a useable state for other people. Which is why I'm deferring upstreaming the change. | 15:13 |
| paulsher1ood | ack | 15:13 |
| radiofree | does github have a git:// clone address? | 15:14 |
| radiofree | or is it fine to use https in a lorry file? | 15:14 |
| richard_maw | github does git:// urls, just replace the https?:// with it | 15:16 |
| radiofree | ta | 15:16 |
| jmacs | ssam2: chef stratum seems to be building now. | 15:25 |
| pedroalvarez | wow, I wasn't aware about the u-boot naming change | 15:25 |
| rdale_ | the xserver chunk from the master branch is failing to build for me - is that a known problem? | 15:26 |
| pedroalvarez | paulsher1ood: looks like you missed this bit: http://paste.baserock.org/opokizeqiz.sm | 15:27 |
| pedroalvarez | btw, the non-official arm mason spotted this: http://85.199.252.156/log/16a188525677106d87373327443ecd83a4fbbdb8--2014-11-21%2015:24:39.log | 15:28 |
| pedroalvarez | (not-official = not yet published, testing it before that) | 15:28 |
| radiofree | eh | 15:30 |
| radiofree | what's that? | 15:30 |
| radiofree | strata/bsp-jetson/u-boot@jetson.morph ?? | 15:30 |
| pedroalvarez | looks like a u-boot renaming to have unique names | 15:31 |
| radiofree | i see | 15:31 |
| radiofree | was that automatic? | 15:31 |
| persia | And generally introducing the use of @ to allow differentiation when identical names are tempting. | 15:31 |
| persia | Patch from paulsher1ood | 15:31 |
| radiofree | u-boot@jetson.morph looks like an e-mail address now though | 15:32 |
| persia | Put on your subversion spectacles, and look again :) | 15:32 |
| *** robtaylor [~robtaylor@xvm-124-143.dc2.ghst.net] has joined #baserock | 15:33 | |
| *** rdale [~quassel@140.Red-79-144-56.dynamicIP.rima-tde.net] has joined #baserock | 15:44 | |
| *** rdale_ [~quassel@123.Red-79-147-219.dynamicIP.rima-tde.net] has quit [Ping timeout: 240 seconds] | 15:47 | |
| paulsher1ood | pedroalvarez: gah! i should not merge to master. _1 for that | 15:53 |
| paulsher1ood | +1 | 15:53 |
| pedroalvarez | paulsher1ood: hahah no worries, you had a +2 | 15:53 |
| paulsher1ood | pedroalvarez: shall i fix it? or will you? | 15:54 |
| pedroalvarez | paulsher1ood: I was merging it | 15:54 |
| paulsher1ood | you're a star :) | 15:54 |
| mariaderidder | I have asked SotK and perryl to use Trello from now on since their work is upstreamed - I would be grateful if the relevant people grant permission please? I believe pedroalvarez would need to grant them access | 15:55 |
| robtaylor | radiofree: will i need to build my own image to get systemd 217? | 15:55 |
| richard_maw | mariaderidder: perefoth or I can also do it | 15:56 |
| pedroalvarez | yeah! more people collaborating with the baserock project!! | 15:56 |
| radiofree | robtaylor: a devel image? | 15:56 |
| radiofree | pedroalvarez: any jetson devel images from master around? | 15:56 |
| robtaylor | radiofree: sure | 15:56 |
| pedroalvarez | mariaderidder: I've seen theirs RFC's and I wouldn't mind if they use the trello board to track their work | 15:56 |
| * robtaylor is sad a closed source project is being used for the kanban | 15:57 | |
| richard_maw | assuming perryl is perryl on trello, everyone involved has access now | 15:57 |
| pedroalvarez | radiofree: i'm trying to do the relevant fixes so I can populate cache.baserock.org with the cache of the *build* system of arm | 15:57 |
| perryl | richard_maw: thanks! | 15:57 |
| mariaderidder | thank you pedroalvarez and richard_maw :) | 15:58 |
| radiofree | robtaylor: i can build one for you if there's no images about already, but i'll have to wait until later (using non-flashing jetson for something testing atm) | 15:58 |
| SotK | thanks richard_maw | 15:58 |
| SotK | also pedroalvarez | 15:58 |
| robtaylor | radiofree: no worries. i have a jetson here. I can try your new scrips | 15:58 |
| * robtaylor can do without for now | 15:59 | |
| radiofree | robtaylor: sure, when they're finished | 15:59 |
| paulsher1ood | radiofree: do you have any way of flashing my jetson? my usb problems seem to make it impossible for me now | 16:02 |
| * paulsher1ood is sad about the trello thing too... but life is too short | 16:03 | |
| radiofree | paulsher1ood: usb problems? | 16:07 |
| paulsher1ood | flashing on my mac takes a variable time. worst case it seems to tend towards more than a day... | 16:07 |
| radiofree | in a baserock vm? | 16:08 |
| paulsher1ood | yup | 16:08 |
| radiofree | ouch | 16:08 |
| radiofree | i can flash it later | 16:08 |
| paulsher1ood | i know i don't have usb3 support in vbox | 16:08 |
| radiofree | but i'm currently running through the things we need to add to baserock to allow baserock to flash a jetson | 16:08 |
| radiofree | (using the open tools) | 16:08 |
| radiofree | so... a bit busy atm, do you need it right now? | 16:09 |
| straycat | richard_maw, SotK, thanks | 16:10 |
| paulsher1ood | no, i'll live | 16:13 |
| radiofree | so i suppose we want to be able to do this in a baserock vm by default? | 16:13 |
| persia | I'd be unhappy if we forced people to use Trello to track their baserock work | 16:14 |
| radiofree | would require adding "nvidia-jetson-flash" to the devel-systems-* though | 16:14 |
| radiofree | that would contain the flashing tools needed to run the flash/installer script | 16:14 |
| paulsher1ood | erk | 16:15 |
| radiofree | paulsher1ood: or you could just run the script and let it clone everything you need and build it | 16:15 |
| paulsher1ood | radiofree: it would be ok to say - download nvidi-jetson-flash | 16:15 |
| paulsher1ood | radiofree: that seems fine | 16:15 |
| radiofree | which is what is going to happen on a normal laptop | 16:15 |
| persia | radiofree: Was 546F641A.3090407@codethink.co.uk intended to have non-quoted content? | 16:23 |
| * Kinnison was close to asking that himself, so is glad persia got there first | 16:23 | |
| persia | The first couple times I read it, I thought it was my mailreader doing something odd | 16:24 |
| Kinnison | hehe | 16:24 |
| jjardon | radiofree: Ive rebased the drm patches in http://git.baserock.org/cgi-bin/cgit.cgi/delta/drm.git/log/?h=baserock/jjardon/drm_2.4.58/jetson if you want to give them a try | 16:25 |
| robtaylor | radiofree: do we just use 3.18 mainline for the jetson? | 16:31 |
| pedroalvarez | hm.. the feedback of the armv7lhf mason is going to be really slow given that its distbuild network associated is using a different trove than g.b.o | 16:44 |
| pedroalvarez | we might want to think about this | 16:45 |
| pedroalvarez | but anyway: first green! http://mason-armv7lhf.baserock.org/ | 16:45 |
| * straycat finds an excuse for a multiplexing generator | 16:45 | |
| * straycat hides | 16:45 | |
| persia | All three masons' distbuild networks should be using the same git server. | 16:46 |
| persia | Artifact cache is a bit trickier: I'd prefer they only uploaded artifacts if the build passed, but that means having separate ephemeral artifact cache servers for each distbuild network. | 16:47 |
| paulsher1ood | persia: istm that if mostly if artifacts are built, from master, they've passed? | 16:49 |
| persia | That presumes that it is impossible to misbuild. | 16:49 |
| paulsher1ood | (even if some later part of the build fails, we'll need them usually) | 16:49 |
| paulsher1ood | i said mostly, usually | 16:49 |
| pedroalvarez | I guess we could configure the armv7 distbuild network to use g.b.o, but that would cause the creation of build branches in g.b.o if we use the distbuild network to build other things | 16:49 |
| persia | Consider the case where something builds, but builds in a way that breaks a future build. We don't really want that artifact cached. | 16:49 |
| * persia dislikes the distbuild architecture harder | 16:50 | |
| paulsher1ood | mason won't catch that anyway... ? | 16:50 |
| pedroalvarez | persia: is a good point that we have to consider | 16:50 |
| persia | Oh, and I added an item to my wishlist for morph today: it should neither notice nor care whether definitions happens to be a git repo (or any class of VCS) :) | 16:50 |
| paulsher1ood | ouch! | 16:50 |
| paulsher1ood | well, ybd would be fine with that already i think :-) | 16:51 |
| persia | paulsher1ood: It will, if it causes a future build to fail. What we don't catch with the current set of tests is when we build something that doesn't work at all, but isn't on the critical path to self-building. | 16:51 |
| straycat | >.> | 16:51 |
| paulsher1ood | straycat: what does that symbol mean? | 16:51 |
| persia | Yes, ybd meets that particular wishlist requirement (and may have been part of the generation thereof, as it was today that I reviewed ybd) | 16:51 |
| straycat | ahh well that would be telling :) | 16:52 |
| pedroalvarez | paulsher1ood: you have to upgrade yourself!! :) | 16:52 |
| pedroalvarez | (using cycle.sh?) | 16:52 |
| paulsher1ood | persia: if it builds, but causes a future build to fail, mason won't spot it? | 16:52 |
| paulsher1ood | or will it? | 16:52 |
| pedroalvarez | paulsher1ood: if I change bison, and then gstreamer doesn't build, then I don't want that bison artifact | 16:53 |
| pedroalvarez | (is what I uderstood from what persia said) | 16:53 |
| persia | If it misbuilds, and sometihng else build-depends on it, mason will probably catch it (depending on the specific nature of the misbuild and the build-dependency) | 16:53 |
| paulsher1ood | ah, ok. yes. sorry. i'll shut up | 16:53 |
| persia | If it misbuilds, and nothing else build-depends on it in the mason-tested build tree, mason won't catch it. | 16:54 |
| persia | pedroalvarez: Precisely. | 16:54 |
| pedroalvarez | note: atm there isn't any artifact uploading, all the artifacts are there becasuse the distbuild networks are using this artifact-cache-server | 16:54 |
| pedroalvarez | but we can change this | 16:55 |
| persia | Ah, so all the misbuilds are also available. Hrm. | 16:55 |
| pedroalvarez | we only need to think about this | 16:55 |
| persia | I'm not that fussed: SotK has a good plan. | 16:55 |
| paulsher1ood | i think that's ok, tbh. we need some gardening of cached artifacts, is all | 16:55 |
| persia | The extra cache we have now slightly increases the chance of collision and uses extra space, but it probably isn't worth trying to fix the current mason. | 16:56 |
| persia | paulsher1ood: But we don't know *which* artifacts are misbuilds today. | 16:56 |
| paulsher1ood | persia: i'd suggest just remove artifacts that have not been used after 6 months, or something? | 16:56 |
| jjardon | pedroalvarez: uh? how is that possible (the green in http://mason-armv7lhf.baserock.org/)? AFAIK we need a new version of libdrm to compile our mesa in arm | 16:57 |
| paulsher1ood | (unless part of a 'release') | 16:57 |
| pedroalvarez | jjardon: is only building the build-system | 16:57 |
| jjardon | pedroalvarez: ah, ok, sorry | 16:57 |
| pedroalvarez | jjardon: we will consider adding the genivi systems to the ci | 16:57 |
| pedroalvarez | (also, I wanted to se the green :) ) | 16:58 |
| paulsher1ood | :-) | 16:58 |
| franred | wen we enable anything in the kernel do we enable it for all the bsps? | 16:58 |
| jjardon | pedroalvarez: maybe you can add a link to the system you are building somewhere in that page? | 16:58 |
| richard_maw | paulsher1ood: ybd appears to not require the definitions tree to be in a git repository, as it currently requires you to run it in the top-level directory. This is one reason why I'd prefer relative file paths to other definitions | 16:58 |
| richard_maw | franred: I tend to | 16:58 |
| persia | paulsher1ood: I hope there aren't any more releases in 6 months, causing that to be less useful than one might think. | 16:58 |
| richard_maw | s/why/one of the reasons why/ | 16:58 |
| franred | richard_maw, cheers | 16:59 |
| persia | Because some folk will still want older cache. | 16:59 |
| pedroalvarez | jjardon: it's in the log: http://mason-armv7lhf.baserock.org/log/da6ead621f82a8fa3fd38c263e498c3d856b2e9e--2014-11-21%2016:41:39.log | 16:59 |
| * richard_maw had to add a bunch of config for CRIU to the kernels recently, so added it to them all | 16:59 | |
| pedroalvarez | jjardon: yeah, is not clear enough, but I think is fine for now | 16:59 |
| paulsher1ood | richard_maw: i could make it take a full or relative path easily enough. but i'd still want it to process *all definitions* in the tree | 16:59 |
| paulsher1ood | (i've convinced myself that there is no appreciable time penalty, so don't need relative file path info) | 17:00 |
| persia | Being able to know what are the set of all definitions in the tree is one of the advantages to having definitions in a git repo. | 17:01 |
| persia | It forces the bottom of the tree in a well-defined way. | 17:01 |
| paulsher1ood | true. but you have a reason for wanting to deal with things that are not in a VCS? | 17:01 |
| persia | Mostly that I thought it would be a nice separation of stuff. | 17:02 |
| persia | That deifnitions is in git encourages morph to use more git internals, which encourages a lot of the things I don't like about morph. | 17:02 |
| persia | But there are also advantages. | 17:02 |
| paulsher1ood | well, i think we get more benefits from git than problems | 17:03 |
| paulsher1ood | s/more/way more/ | 17:03 |
| persia | Don't conflate the use of git to collaborate on definitions with the on-disk representation of definitions at the time one runs the `morph` command. | 17:04 |
| persia | If we're including the former, I agree. If we're only considering the latter, I'm really not sure. | 17:04 |
| paulsher1ood | i was talking much more broadly than both your cases. as for the latter, i agree it doesn't matter much | 17:05 |
| paulsher1ood | (if at all) | 17:06 |
| persia | In the much broader sense, I couldn't agree with you more. It's just this particular very narrow case. | 17:06 |
| paulsher1ood | ack | 17:06 |
| * persia has to go do physical things, and stops paying attention for a while | 17:06 | |
| * paulsher1ood escapes from cyberspace too | 17:06 | |
| radiofree | robtaylor: no, some cpufreq patches | 17:11 |
| radiofree | flashing a jetson from another jetson gives some.. odd behaviour | 17:11 |
| radiofree | i'll investigate that later... | 17:12 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:32 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:33 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 17:37 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:48 | |
| radiofree | paulsher1ood: if you leave your jetson on my desk i'll flash it over the weekend | 17:51 |
| *** darryl [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has joined #baserock | 17:54 | |
| darryl is now known as duderdice | 17:56 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:56 | |
| *** duderdice [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has quit [Client Quit] | 17:56 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:57 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:58 | |
| *** duderdice [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has joined #baserock | 17:59 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:06 | |
| *** rdale [~quassel@140.Red-79-144-56.dynamicIP.rima-tde.net] has quit [Ping timeout: 255 seconds] | 18:08 | |
| paulsher1ood | radiofree: too late... i'll try it again myself. thanks anyway | 18:09 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 18:26 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 18:34 | |
| *** ssam2 [~ssam2@cpc7-asht7-2-0-cust170.10-1.cable.virginm.net] has quit [Quit: Leaving] | 18:54 | |
| *** duderdice [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has quit [Ping timeout: 240 seconds] | 19:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!