| paulsherwood | pedroalvarez: did you get a chance to check out the room for tomorrow's hands-on? | 00:22 |
|---|---|---|
| pedroalvarez | paulsherwood: I did, but they were setting things up | 00:24 |
| pedroalvarez | I'm going there now btw | 00:24 |
| paulsherwood | which room is it? | 00:26 |
| * paulsherwood looks at schedule | 00:26 | |
| *** gtristan has quit IRC | 01:03 | |
| *** gtristan has joined #baserock | 01:17 | |
| * paulsherwood can has ybd running in a browser | 03:33 | |
| paulsherwood | (with shell-in-a-box) | 03:34 |
| gtristan | nice :) | 03:45 |
| pedroalvarez | Hehe, it will be useful for the hands on | 04:05 |
| *** gtristan has quit IRC | 05:28 | |
| *** zoli_ has left #baserock | 05:38 | |
| *** gtristan has joined #baserock | 06:30 | |
| *** paulwaters_ has joined #baserock | 06:38 | |
| *** gtristan has quit IRC | 06:49 | |
| *** gtristan has joined #baserock | 06:59 | |
| gtristan | In chunks configure-commands, build-commands and install-commands... does every line which starts with a '-' run in a separate shell ? | 07:09 |
| paulsherwood | suspiciously kbas on both artifacts0.baserock.org (datacentred) andartifacts1.baserock.org (scaleway) have disappeared | 07:09 |
| paulsherwood | gtristan: i believe so | 07:09 |
| gtristan | as opposed to when you have - | ... and then the following lines run in the same shell ? | 07:09 |
| gtristan | ok | 07:10 |
| *** franred has joined #baserock | 07:10 | |
| Kinnison | That is YAML string folding/unfolding rules and lists | 07:11 |
| Kinnison | - one item | 07:11 |
| Kinnison | - another item | 07:11 |
| Kinnison | - another | 07:11 |
| Kinnison | vs. | 07:11 |
| Kinnison | - | | 07:11 |
| Kinnison | one long | 07:12 |
| Kinnison | item with | 07:12 |
| Kinnison | multiple lines | 07:12 |
| Kinnison | - and another | 07:12 |
| persia | gtristan: Everything runs in the same shell, in my experience. | 07:13 |
| gtristan | ok so one must preserve CWD | 07:14 |
| persia | Unless one wishes to alter it in a cascading way :) | 07:14 |
| gtristan | and exit status for each line | 07:14 |
| Kinnison | each list item runs in a new subshell | 07:15 |
| persia | Ideally, one has very little there. The need for a complicated stanza likely represents a bug in the upstream build system, which ought be resolved by landing an appropriate patch upstream. | 07:15 |
| paulsherwood | anyone have any ideas how to either work out why a simple bbottle server died, or what to instrument to help diagnose next time it happens? | 07:16 |
| persia | Kinnison: Hrm? I thought there were some that used shell variables. | 07:16 |
| Kinnison | persia: those are likely to be multiline items, rather than multiple items | 07:16 |
| Kinnison | paulsherwood: I think bottle defaults to having a --debug or similar | 07:16 |
| persia | Kinnison: That makes sense. Also ugh. | 07:17 |
| Kinnison | paulsherwood: If I misremembered, then there's probably a debug=True argument to the bottle initialiser | 07:17 |
| *** ssam2 has joined #baserock | 07:17 | |
| *** ChanServ sets mode: +v ssam2 | 07:17 | |
| lostduck | gtristan, it is as you suspect, http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/builder.py#n312 may be a useful reference | 07:17 |
| Kinnison | paulsherwood: yo umay also want reloader=True | 07:18 |
| Kinnison | paulsherwood: which will cause it to restart its child app if it crashes | 07:18 |
| gtristan | lostduck, got it :) | 07:18 |
| gtristan | for cmd in cmds; ... self.runcmd() | 07:19 |
| gtristan | that makes more sense :) | 07:19 |
| gtristan | (and it safer, actually) | 07:19 |
| paulsherwood | Kinnison: tvm. i'll try that. | 07:26 |
| paulsherwood | while the gang's all here, what's hthe plan for the git candidate stuff wrt baserock? | 07:27 |
| Kinnison | magic 8 ball says outlook unclear :-/ | 07:28 |
| paulsherwood | how do we clarify it? | 07:29 |
| Kinnison | I need time to follow up to the RFC on the git lists, etc. Hopefully I'll know more thu/fri | 07:30 |
| paulsherwood | what's the holdup? if it works, can't we get started with a tutorial to tell people how to set it up and use it, and then trial it for patch reviews here? | 07:30 |
| paulsherwood | then we can maybe feed back to the git folks showing them how awesome it is | 07:31 |
| Kinnison | s'a plausible way to generate some buzz I'll admit | 07:31 |
| Kinnison | poke straycat when you next see him | 07:31 |
| * Kinnison bimbles off to pack and head to an all day meeting | 07:32 | |
| paulsherwood | lostduck: if you see straycat, pls draw attention to the above? | 07:32 |
| * lostduck nods | 07:37 | |
| lostduck | I think they want feedback from git before proceeding further | 07:38 |
| persia | I don't think Baserock has to wait to use software. | 07:39 |
| persia | If someone wants to review git-candidate, and propose it as an alternative to our use of Baserock, that would seem sensible to me. | 07:40 |
| persia | Last I read, it was only in RFC state, so there may be warts, but reporting them may help ensure that development is aligned with Baserock needs. | 07:40 |
| paulsherwood | lostduck: who is 'they'? i want to use it | 07:40 |
| persia | paulsherwood: the RFC is mirrored at http://www.mail-archive.com/git@vger.kernel.org/msg79461.html | 07:41 |
| *** rdale has quit IRC | 07:41 | |
| persia | Patch git and use it, if you like. | 07:41 |
| persia | Err, I should have written above "propose it as an alternative to our use of gerrit". | 07:42 |
| lostduck | the gang | 07:42 |
| lostduck | I'd want to rework the interface before suggesting it for use, that RFC really was just an RFC with too much code. | 07:42 |
| paulsherwood | when i looked there, i saw nothing telling me how to actually install it | 07:42 |
| *** gtristan has quit IRC | 07:42 | |
| paulsherwood | 'the gang'? | 07:42 |
| persia | paulsherwood: Apply the patches to git, build git. Go. | 07:42 |
| paulsherwood | persia: i repeat my reqest for those instructiosn to be written somewhere properly, and a tutorial | 07:43 |
| lostduck | persia, subcmds in contrib tree won't be available by default? you'd have to copy it into $GIT_EXEC_PATH | 07:43 |
| persia | lostduck: Oh. I thought the patch was complete. You're right, it's more of an RFC. | 07:44 |
| * paulsherwood needs a simpler 'quickstart' than this | 07:44 | |
| persia | It's all part of the fun of pulling patches not yet upstream. If one wants things nice, one has to wait for things to hit master :) | 07:45 |
| paulsherwood | cna't someone do a page on the baserock wiki to explain the full thing so i can try it? | 07:45 |
| persia | Of course, it's delightful to have this sort of conversation: most of the version discussions I've been having have been with folk trying to use things way downstream, rather than ahead of upstream. | 07:46 |
| paulsherwood | catch 22. i if no-one uses it, or reports how fantastic it is how will it ever be interesting for upstream? | 07:46 |
| persia | Heh, it's always like that. But the first person gets to do it the hard way :) | 07:48 |
| lostduck | paulsherwood, if you are curious, most likely all you'll need is cp git-candidate.perl /usr/lib/git-core/git-candidate; cp GitUtils.pm /usr/lib/git-core then you can use candidate as a regular subcommand to git. | 07:50 |
| paulsherwood | lostduck: if i do that on my own, will anyone else be able to intract with candidates i create? | 07:55 |
| lostduck | no | 07:56 |
| paulsherwood | so how do we get this fire started, then? | 07:56 |
| *** gtristan has joined #baserock | 08:00 | |
| lostduck | i really don't know | 08:01 |
| lostduck | the RFC is not really ready for use in production | 08:01 |
| wdutch | do all systemd patches end up in trove? | 08:02 |
| wdutch | is it unusual for there to be a day without systemd patches? it doesn't seem that weird to me | 08:02 |
| persia | wdutch: check the lorry configuration. | 08:02 |
| ssam2 | wdutch: everything from upstream systemd.git on freedesktop.org should end up in our mirror | 08:04 |
| ssam2 | if our master and their master ref point at different SHA1s, maybe we have a problem | 08:04 |
| tiagogomes_ | ssam2 nice post about cmake | 08:07 |
| ssam2 | ta | 08:08 |
| ssam2 | I have another lined up which is not so nice. I thought I'd start with the more positive one ;) | 08:08 |
| ssam2 | (https://samthursfield.wordpress.com/2015/10/20/some-cmake-tips/) | 08:08 |
| *** bashrc has joined #baserock | 08:08 | |
| paulsherwood | lostduck: best way to help it get ready for production is user feebback, surelty? | 08:09 |
| ssam2 | i have no context here, but it does seem like Baserock is one of the obvious places to test such a thing. and clearly not everyone here likes Gerrit, so there should be some interest | 08:10 |
| lostduck | yes, i'm just dealing with the reality that my attempts to engage with git have been largely ignored, from that i can only assume that they're not even slightly interested in what we're trying to do, and i don't know how to overcome that. | 08:10 |
| paulsherwood | lostduck: you're reading this wrong. folks are busy. probably they don't have time and they don't understand the context for the rfq, so they end up focusing on other stuff that they do understand | 08:12 |
| lostduck | okay | 08:14 |
| paulsherwood | so c'mon... remove the blockers so that me, you and others can get using it and tell the world | 08:15 |
| lostduck | okay | 08:15 |
| lostduck | I will add some sort of quick-start guide to the repo then | 08:17 |
| paulsherwood | tvm | 08:17 |
| ssam2 | does git-candidate need to be in git.git to work, or can it exist independently? | 08:18 |
| lostduck | it could exist independently | 08:18 |
| ssam2 | so all it needs is a nice looking website like http://git-dependency-manager.info/ | 08:24 |
| ssam2 | (random example) | 08:24 |
| ssam2 | if only codethink had some web designers... | 08:26 |
| paulsherwood | lol | 08:28 |
| De|ta | That's generated by http://www.mkdocs.org/ | 08:28 |
| paulsherwood | i was about to say that :) | 08:29 |
| ssam2 | ha, so it is | 08:34 |
| ssam2 | then we have no excuse :) | 08:34 |
| ssam2 | although i'm not sure I quite agree with the term 'downright gorgeous' for something that looks like a maths book :-) | 08:35 |
| franred | ssam2, paulsherwood, lostduck, or github with a proper README | 08:35 |
| franred | ? | 08:35 |
| *** edcragg has joined #baserock | 08:36 | |
| paulsherwood | franred: that too :) | 08:36 |
| *** rdale has joined #baserock | 08:38 | |
| *** nowster has joined #baserock | 08:38 | |
| *** mariaderidder has joined #baserock | 08:40 | |
| *** jonathanmaw has joined #baserock | 08:41 | |
| wdutch | does anybody know why I'm getting this error when morph is run? http://ciat1.baserock.org:8010/builders/Integration/builds/243/steps/shell/logs/stdio | 08:47 |
| wdutch | does morph require a speicific version of argparse? | 08:48 |
| SotK | we use a forked version of cliapp | 08:48 |
| SotK | oh weird, you are using the right branch | 08:49 |
| wdutch | I installed cliapp from it's repo on liw.fi | 08:49 |
| ssam2 | you have to use the baserock/morph branch from git.baserock.org | 08:49 |
| wdutch | okay | 08:49 |
| ssam2 | it's a pain | 08:49 |
| ssam2 | sorry! | 08:50 |
| * SotK wonders what "+ git clone -b baserock/morph git://git.baserock.org/delta/cliapp.git ./src/cliapp" in that log is for then | 08:50 | |
| wdutch | I got an error that it couldn't import cliapp and installed it manually, possibly it's conflicting | 08:51 |
| SotK | ah, perhaps you need to make sure that ./src/cliapp is in your PYTHONPATH? | 08:52 |
| * gtristan palmface... must rebuild WebKitGtk again :-/ | 08:54 | |
| ssam2 | git-minimal seems to have broken Mason build: https://mason-x86-64.baserock.org/log/da1badcc76be85d324f8b9c1c34fbe2274a49ac1--2015-10-20%2002:17:28.log | 08:59 |
| ssam2 | something to do with debug stripping, by the looks of it, no idea what | 09:02 |
| ssam2 | oh, i'm talking complete nonsense | 09:04 |
| ssam2 | seems to have been a series of false positives, and now it has built | 09:04 |
| ssam2 | stupid Mason | 09:04 |
| wdutch | weird, aws doesn't think "git reset --hard origin/cu010-trove/br6/genivi-demo-platform" is a valid git command | 09:18 |
| wdutch | amazon seem to have their own version in yum | 09:19 |
| wdutch | richard_maw: do you remember if we had to build git from source last time? | 09:19 |
| richard_maw | wdutch: we did not have to, | 09:22 |
| richard_maw | wdutch: do you have a command log? | 09:23 |
| wdutch | richard_maw: http://ciat1.baserock.org:8010/builders/Integration/builds/247/steps/shell/logs/stdio | 09:23 |
| richard_maw | wdutch: the command exists, but it doesn't think the branch does | 09:24 |
| wdutch | oh | 09:24 |
| *** franred has quit IRC | 09:25 | |
| richard_maw | wdutch: just to check, have we changed which definitions repository it fetches sources from without also changing the branch? | 09:26 |
| wdutch | it seems I missed that branch | 09:26 |
| wdutch | "ERROR: Woah! expected 1 chunk matching genivi-demo-platform:poi-service (got 0)" | 09:29 |
| *** edcragg has quit IRC | 09:34 | |
| *** edcragg has joined #baserock | 09:35 | |
| *** franred has joined #baserock | 09:35 | |
| wdutch | does that mean firehose is looking for strata/genivi-demo-platform/poi-service.morph? | 09:35 |
| wdutch | because that seems to exist in that branch | 09:35 |
| gtristan | Can anyone take care of this webkit lorry import ? see if it actually works ? | 09:37 |
| gtristan | it will take about 10min of your time, and then 2min every following day to see if it completes | 09:37 |
| gtristan | without doing the import properly, we resort to tarball lorries - which is... eh, not the point right ? | 09:38 |
| ssam2 | i'll try to get to it, am 2 days from a deadline at the moment though | 09:47 |
| ssam2 | you could also try to convince pedroalvarez, i think you are near him right now? :) | 09:48 |
| * richard_maw just got the Lorry e-mail | 09:55 | |
| gtristan | ssam2, yeah he offered to do that yesterday, didnt wanna bother since he may be busy at the conference :) | 09:56 |
| wdutch | richard_maw: you commented out poi-service in genivi-demo-platform, why? | 09:56 |
| richard_maw | we've preivously given up for lorries that take longer than 2h… but gtristan has an excellent point, it should be possible to run the lorry manually on g.b.o before pushing the lorry-controller config change | 09:57 |
| richard_maw | wdutch: couldn't get it to build in the given version | 09:57 |
| wdutch | richard_maw: somehow firehose is still looking for it when walking the specs and getting upset because it's not there | 09:57 |
| richard_maw | where is the firehose config defined? | 09:58 |
| gtristan | richard_maw, my assumption is that only the import takes a huge amount of time, and that subsequent lorries will only pull recent changes | 09:59 |
| gtristan | but I could be assuming wrong ? | 09:59 |
| richard_maw | gtristan: that's what we've experienced | 09:59 |
| * gtristan has no idea *why* it takes so long really... the process doesnt seem to take lots of cpu, and my network connection is fast | 10:00 | |
| gtristan | but it may be making many connections | 10:01 |
| richard_maw | gtristan: I'll take a look to see whether it's safe to run it on git.baserock.org | 10:04 |
| * gtristan wonders if the svn lorry code could be optimized by pulling the entire svn separately, and then doing the git svn fetch from a local directory | 10:05 | |
| * gtristan can try to do a full checkout later when I get home | 10:05 | |
| richard_maw | gtristan: I thought you couldn't guarantee that for every svn server | 10:06 |
| gtristan | and point the lorry to a file:// location to the svn | 10:06 |
| richard_maw | if we had a full copy of the svn repository then there's an svn fastimport | 10:06 |
| gtristan | that could potentially be much faster than the current approach (while taking effectively twice as much disk space) | 10:08 |
| richard_maw | IIRC there's two reasons why we use git-svn. 1. historical reasons, there was no svn-fastimport at the time, 2. no guarantee that the svn server will let us fetch everything needed | 10:09 |
| gtristan | I see, yeah I dont know the details | 10:10 |
| gtristan | have only been a basic user of svn :) | 10:10 |
| gtristan | (and it's been a while, happy it's mostly gone) | 10:10 |
| richard_maw | gtristan: the version of lorry on g.b.o requires tags to be specified in the lorry file | 10:13 |
| gtristan | that might not work | 10:13 |
| * richard_maw wonders if the webkit repository even has any tags | 10:14 | |
| gtristan | well, I tried with specifying tags/ ... and it crapped out for some reason | 10:14 |
| gtristan | richard_maw, it has trunk/ branches/ and tags/ ... but the problem is, *none* of those contain the code we want it would seem | 10:14 |
| * richard_maw wonders how gtristan can tell | 10:15 | |
| gtristan | instead, the webkitgtk folks work in the same repository, in the releases/WebKitGtk branches... and I think they basically aim to merge back into trunk/ whatever work is usable | 10:15 |
| richard_maw | I can't do the usual trick of looking at the repo in my web browser | 10:15 |
| gtristan | yeah; webbrowser | 10:16 |
| richard_maw | weird, it's now showing up for me | 10:16 |
| gtristan | honestly I've kill firefox right now because webkit is building a bit faster with that | 10:16 |
| * gtristan had missed the -DCMAKE_INSTALL_PREFIX... resulting in an install in /usr/local... and then gnome-online-accounts doesnt find the .pc | 10:17 | |
| *** franred has quit IRC | 10:17 | |
| gtristan | gah, what a waste | 10:17 |
| richard_maw | oh, so is the web UI for it the trac.webkit.org thing while you actually reach it through the svn.webkit address then? | 10:17 |
| lostduck | paulsherwood, you should now find INSTALLING.md which explains how to install git-candidate, there's a makefile now. the README.md already covers a basic workflow, i'd like a man page too, but i expect we'll want to change everything | 10:17 |
| richard_maw | gtristan: ouch, yeah, that's a huge number of tags that we don't care about | 10:18 |
| richard_maw | and we don't even want the regular branches | 10:19 |
| gtristan | richard_maw, fwiw, how I'm currently building, I built the advertized git mirror | 10:19 |
| richard_maw | gah! I'll take a look at what git-svn is capable of | 10:19 |
| gtristan | richard_maw, which only mirrors trunk/ | 10:19 |
| gtristan | and then followed these instructions: | 10:19 |
| gtristan | http://trac.webkit.org/wiki/WebKitGTK/2.10.x#Howtoaddawebkit-2.10branchtoexistinggit-svnclone | 10:19 |
| gtristan | right, they are far away from a standard setup | 10:21 |
| gtristan | lorry master, with the given lorry file, seems to do the right thing... but one would have to run it for a few days to find out :) | 10:21 |
| richard_maw | gtristan: the lorry interface to git-svn doesn't let you specify multiple locations for branches, so fetching the whole repository is not currently possible, though we could have the WebKitGTK releases/ as the tags instead | 10:25 |
| wdutch | richard_maw: firehose is running with config examples/genivi-persistence-client-library.yaml | 10:25 |
| gtristan | richard_maw, would that "work" ? | 10:26 |
| richard_maw | gtristan: I'll have to have a look to see if we can have the url as https://svn.webkit.org/repository/webkit/releases/WebKitGTK and see if we can set tags=/ | 10:26 |
| wdutch | actually it's funning with a whole bunch of configs, all of them in examples | 10:27 |
| *** franred has joined #baserock | 10:27 | |
| richard_maw | gtristan: it should, but it would still be fetching in all the branches and trunk we don't care about | 10:27 |
| richard_maw | since it's not actually the same project | 10:27 |
| gtristan | richard_maw, I would expect it to create git tags for what is found at the tip of "tags" | 10:27 |
| richard_maw | gtristan: it can create tags based on whichever paths you specify | 10:27 |
| gtristan | what we would want though, is to create one git branch for each of the releases/WebKitGtk/* tips | 10:28 |
| gtristan | right ? | 10:28 |
| * richard_maw is unsure about that | 10:28 | |
| richard_maw | is active development done on those tips? | 10:29 |
| richard_maw | do they make changes on top | 10:29 |
| gtristan | when a bugfix is backported to a stable branch, we wouldnt want a git tag to suddenly "shift" | 10:29 |
| richard_maw | they look more like tags than branches to me | 10:29 |
| gtristan | do they ? | 10:29 |
| gtristan | hmmm | 10:29 |
| gtristan | that part I'm unsure of, I had perceived them as stable branches | 10:29 |
| gtristan | but I dont maintain webkitgtk hehe | 10:30 |
| gtristan | richard_maw, seeing as they lack micro points, it makes more sense if they are branches though | 10:30 |
| gtristan | otherwise one would expect a separate tip for each and every release | 10:31 |
| richard_maw | I don't know how they version it, I'll take your word for it, it's just that http://trac.webkit.org/browser/releases/WebKitGTK looks like a list of tags to me | 10:31 |
| gtristan | actually | 10:32 |
| gtristan | it is definitely a stable branch | 10:33 |
| gtristan | richard_maw, according to http://trac.webkit.org/wiki/WebKitGTK/2.10.x#Howtoaddawebkit-2.10branchtoexistinggit-svnclone | 10:33 |
| richard_maw | cool, thanks for clarifying | 10:33 |
| *** nowster has quit IRC | 10:33 | |
| *** franred has quit IRC | 10:33 | |
| richard_maw | I'll have a read to see if git-svn is capable of fetching, and if we can do so without needing to change lorry-controller | 10:34 |
| *** locallycompact has joined #baserock | 10:34 | |
| persia | richard_maw: `git svn fetch` is a command I run regularly, to update the svn repo (and show new branches, tags, etc.) | 10:38 |
| wdutch | [trove.baserock.org] CRIT: This repository is not for you | 10:42 |
| * wdutch chuckles | 10:42 | |
| wdutch | do I have permission to give ciat permission to push to trove? | 10:45 |
| persia | I think only the ops team can grant push permissions there. | 10:47 |
| wdutch | ssam2: ciat needs to be able to push to definition, could you give it that powah please? :) | 10:48 |
| gtristan | wdutch, I dont think CI should be pushing to upstream definitions - we need to have a review process where CI proposes merge candidates | 10:57 |
| *** nowster has joined #baserock | 10:57 | |
| gtristan | and we need to have a stable branching scheme for upstream definitions | 10:58 |
| gtristan | otherwise upstream definitions will be even more chaotic and unpredictable | 10:58 |
| wdutch | gtristan: it pushes to a speical branch which can then be reviewed by a hooman | 10:58 |
| gtristan | that also works :) | 10:58 |
| wdutch | I don't know what the best solution is in the longterm, possibly to have it work with gerrit | 10:59 |
| gtristan | I have a pending email/draft :-S | 11:00 |
| gtristan | wdutch, but as webkit is still compiling (fscking c++ !)... | 11:00 |
| gtristan | wdutch, what do you think about having a definitions-wide branching/release scheme ? | 11:01 |
| gtristan | I think we need one, like... currently we could branch baserock-1.0 in definitions | 11:01 |
| gtristan | then I would shoot for gnome 3.18 in baserock-1.0, and be preparing for gnome 3.20 in master, or whatever release of GNOME is stable when we are ready to branch baserock-2.0 | 11:02 |
| gtristan | we would just take "whatever is stable" for each "system" in definitions for baserock-1.0 | 11:03 |
| gtristan | and "whatever is experimental" in master, but coordinate for a definite baserock-2.0 in say, 6 months or 1 year | 11:03 |
| wdutch | sounds like debian :P | 11:03 |
| gtristan | wdutch, then we would have separate instances of CI - we would have continuous integration of stable upstream branches proposing candidates for baserock-1.0 | 11:04 |
| gtristan | and also CI for master | 11:04 |
| wdutch | I don't know if having a collection of what is considered to be stable is inkeeping with how this project is used | 11:04 |
| * gtristan had envisioned the CI safely on a separate machine with a separate clone of upstream definitions.git, honestly | 11:04 | |
| gtristan | but maybe a branch of ci-dev and ci-stable works just as well | 11:05 |
| gtristan | wdutch, well, I guess we'll just have to have a group wide mud-wrestling match for that | 11:06 |
| wdutch | currently it does use a different trove which mirrors git.baserock.org, a lot of people didn't want this and wanted it to work directly with git.baserock.org | 11:06 |
| gtristan | or a wet tee-shirt contest | 11:06 |
| wdutch | lol! | 11:06 |
| gtristan | but honestly, I dont see the point if we cannot focus on providing a stable baseline | 11:06 |
| gtristan | currently I am focusing on GNOME bleeding edge, and every time I upgrade some dependency to bleeding edge, I get a sick feeling in my stomach | 11:07 |
| *** ssam2 has quit IRC | 11:07 | |
| gtristan | I think: Ouch, that entity which actually *uses* baserock as a baseline for something in production... | 11:07 |
| gtristan | their whole upstream baseline is totally compromised, just because I wanted to fool around building a silly bleeding edge GNOME | 11:08 |
| * gtristan thinks it's a no-brainer that a basic branching scheme will fix this | 11:08 | |
| persia | wdutch: Could ciat just submit a candidate to gerrit, and update it regularly? If it merges, start a new one? | 11:10 |
| wdutch | it probably could | 11:11 |
| persia | Pushing directly to a branch on git.baserock.org sounds to me like a recipe to have the system be entirely ignored, as we don't review branches there, typically. | 11:11 |
| SotK | persia: +1 | 11:11 |
| wdutch | this will slow down the migration of the server, I'd like to migrate it as-is first then start making changes | 11:12 |
| gtristan | wdutch, curiously (and I have no knowledge of ciat yet)... can we easily have read-only access to ciat's definitions ? | 11:13 |
| gtristan | if for instance, I would want to produce an automated image of GNOME from there directly | 11:13 |
| wdutch | I guess so? I don't really know how trove permissions work | 11:13 |
| *** ssam2 has joined #baserock | 11:15 | |
| *** ChanServ sets mode: +v ssam2 | 11:15 | |
| SotK | I assume CIAT will just work in git.baserock.org/baserock/baserock/definitions | 11:15 |
| wdutch | SotK: the pipelines themselves are not not defined there, kinnison did not like the idea so they are in http://git.baserock.org/cgi-bin/cgit.cgi/baserock/ciat/ciatconfig.git/ | 11:17 |
| gtristan | SotK, wdutch says it currently use a different mirror, and could potentially submit candidates over gerrit | 11:17 |
| gtristan | SotK, honestly I have some reservations about letting a bot commit to the upstream "crown jewels", but that's just me :) | 11:17 |
| SotK | we can probably set the acls so it can only commit to some subset of branches in there | 11:19 |
| * SotK is guessing there though | 11:19 | |
| * SotK is glad the config isn't in definitions :) | 11:20 | |
| paulsherwood | how does one upload images to w.b.o? via git only? | 11:23 |
| persia | wdutch: Please do it right, rather than doing it wrong fast, cleaning up, and then trying to figure out how to resolve the mess in git.baserock.org (which has a never-garbage-collect policy). | 11:23 |
| ssam2 | paulsherwood: what's w.b.o ? | 11:23 |
| paulsherwood | wiki.baserock.org | 11:24 |
| ssam2 | ah, I don't know | 11:24 |
| wdutch | persia: it's a bit late for that ... | 11:24 |
| persia | wdutch: For any git server on which garbage collection was done, your plan isn't quite as terrible: it's just that the policy in this case means you can *never* clean up the mess later. | 11:24 |
| persia | Lovely. | 11:24 |
| paulsherwood | is ths a good time to mention that ciat code has odd examples of personal nicks in it,and is missing license info | 11:24 |
| persia | Yes, beacuse it means that g.b.o is in license violation, so we can wipe it entirely, and clean up after wdutch's mess. | 11:25 |
| persia | Mind you, this isn't ideal for any baserock users | 11:25 |
| persia | </unhelpful sarcastic irritation> | 11:25 |
| paulsherwood | persia: i don't think it's in violation. just that folks didn't stick license headers in the code they wrote..... | 11:26 |
| paulsherwood | which can and should be fixed | 11:26 |
| persia | Ask counsel. My understanding is that outside a few commonwealth countries, the provider is liable for the copyright violation inherent in distributing code without a license to do so, as there are no common carrier provisions without prior arrangement. | 11:27 |
| persia | My understanding may be incomplete or flawed. | 11:27 |
| *** gtristan has quit IRC | 11:30 | |
| wdutch | how should it be licenced? | 11:31 |
| ssam2 | copy the notice from morph or ybd or some other bit of Baserock | 11:32 |
| ssam2 | they should all be the same (GPLv2) | 11:32 |
| paulsherwood | gplv2. use the same style of header as all of the morph and ybd code. you'll need to add the gplv2 license too | 11:32 |
| wdutch | okeedoke, cool | 11:32 |
| wdutch | should repos containing only config also be GPL'd? | 11:33 |
| persia | Ask the author. They can be GPL'd, which makes it easier to modify and distribute with code, but it makes writing a book about it all harder, as the GPL snippets are considered inclusive by some folk. | 11:37 |
| wdutch | I don't plan to write a book about it, does anybody else? | 11:37 |
| *** nowster has quit IRC | 11:42 | |
| pedroalvarez | wow this jetson is failing with this http://paste.baserock.org/jemunenosa | 11:47 |
| *** gtristan has joined #baserock | 11:48 | |
| pedroalvarez | radiofree: any idea about this ^? | 11:48 |
| gtristan | instances:2 for ybd is really working nicely | 11:55 |
| radiofree | pedroalvarez: no, not seen that before, issue with nouveau | 11:56 |
| radiofree | is it happening all the time? | 11:56 |
| radiofree | what version of mesa/kernel | 11:56 |
| ssam2 | I've added the start of some documentation on caching in Baserock, feedback welcome: http://wiki.baserock.org/caching/ | 11:56 |
| ssam2 | it's quite tricky to explain so it might not make any sense so far | 11:57 |
| gtristan | the build count needs fixing though... 'step' number should be 'completed builds + 1', instead of 'how many builds this instance built' :D | 11:58 |
| ssam2 | Vagrantfile in ybd -- nice!! i missed that before | 12:01 |
| ssam2 | if only Vagrant didn't force you to pick a specific vm provider in advance! but it will still be pretty useful I think | 12:01 |
| richard_maw | ssam2: your links are a bit off | 12:02 |
| *** franred has joined #baserock | 12:02 | |
| richard_maw | otherwise it's all accurate | 12:02 |
| ssam2 | you mean, not linkified? i fixed that | 12:03 |
| ssam2 | thanks | 12:03 |
| richard_maw | gtristan: I think we can do a full import of every webkit branch, though arguably we actually just want a repository that has the branches, which we don't currently support, but could with a patch to lorry to make trunk also optional | 12:07 |
| * richard_maw never considered that a project might not have a main development branch | 12:07 | |
| tlsa | ssam2: could mention ccache on the list of other tools | 12:09 |
| ssam2 | i guess.. it operates at a different level to bitbake, morph, ybd etc | 12:14 |
| ssam2 | related though | 12:14 |
| gtristan | richard_maw, yeah I dont think supporting master-less projects is important, in any case, those webkitgtk branches - even if they never completely merge to master... have patches that do get merged | 12:23 |
| gtristan | richard_maw, they basically share the same engine and work alongside trunk, upstreaming engine fixes to trunk - maybe one day it will merge there, who knows | 12:24 |
| pedroalvarez | radiofree: the versions of the latest tag of definitions | 12:24 |
| pedroalvarez | Genivi-k something | 12:25 |
| pedroalvarez | The thing is that the same version of the system works in 8 Jetsons | 12:25 |
| pedroalvarez | Fails in 3 | 12:25 |
| pedroalvarez | I'm blaming hardware.. | 12:25 |
| richard_maw | gtristan: I see, in which case we ought to be able to do the import with a newer version of lorry on git.baserock.org | 12:25 |
| richard_maw | pedroalvarez: are you still part of Baserock Ops? How would you recommend the lorry update happen? | 12:26 |
| ssam2 | the dirty way is fine by me | 12:27 |
| ssam2 | i.e. 'sudo python ./setup.py install' from a checkout of lorry.git | 12:27 |
| ssam2 | as long as everyone is kept in the loop that it was done | 12:27 |
| richard_maw | ssam2: how do you normally keep people in the loop about this? | 12:28 |
| gtristan | richard_maw, one thing about your email I'm unclear about... the branch names might be strange with "{branches,releases}/*" ... but I guess that would just be a 'baserock-ism' and perfectly acceptable as such | 12:28 |
| pedroalvarez | richard_maw: if definitions.git is updated, then when we upgrade the new version will be in | 12:28 |
| gtristan | i.e. we wouldnt have a 'webkitgtk-2.10' branch, as one might expect, but rather a 'WebKitGtk-webkitgtk-2.10' ? or something namespaced with the intermediate path ? | 12:29 |
| pedroalvarez | I'm fine with ssam2 approach as long as definitions has the change too | 12:29 |
| richard_maw | gtristan: we'd have safari-xxx-branch and Apple/Leopard and WebKitGTK/webkit-1.1.1 as branches | 12:30 |
| richard_maw | we'd be stripping the releases/ bit off the beginning | 12:30 |
| gtristan | richard_maw, yeah I think that's totally fine, probably the way to go too | 12:30 |
| gtristan | in the definitions we would have a WebKitGtk.morph which would build the WebKitGtk branch, of the WebKit repo | 12:31 |
| richard_maw | grand, I'll start trying to import the whole thing then | 12:31 |
| gtristan | nice, thanks for the assistance ! :) | 12:32 |
| * gtristan has been trying and... just takes too long :) | 12:32 | |
| gtristan | alright, one last dependency build failure, libpwquality needs some touch up... and then gnome-initial-setup has all of it's deps: next milestone close ! | 12:33 |
| richard_maw | "Bad URL passed to RA layer: Unrecognized URL scheme for 'https://svn.webkit.org/repository/webkit' at /usr/share/perl/Git/SVN.pm line 148." O_o | 12:35 |
| gtristan | I heard that with another lorry last week... | 12:37 |
| gtristan | but it is *not* an issue with lorry from master :-/ | 12:37 |
| richard_maw | http://stackoverflow.com/questions/13571944/git-svn-unrecognized-url-scheme-error suggests it might be a problem with the version of svn | 12:37 |
| gtristan | last week we pointed the svn lorry to a github instead and avoided the problem | 12:37 |
| gtristan | ah | 12:37 |
| gtristan | that could be | 12:37 |
| gtristan | correction: it is *not* an issue with lorry master and whatever stuff I happen to have on my laptop :) | 12:38 |
| gtristan | haha | 12:38 |
| * richard_maw grumbles | 12:38 | |
| richard_maw | looks like our version of SVN is compiled without http | 12:39 |
| * richard_maw tries with svn:// url | 12:41 | |
| richard_maw | didn't work, timed out connecting to the svn port | 12:47 |
| ssam2 | richard_maw: keep us in the loop by emailing baserock-dev, or admin@baserock.org | 12:47 |
| ssam2 | admin@baserock.org reaches all current 'ops team' people (me, gary, fran, pedro) | 12:47 |
| ssam2 | thanks for looking at this by the way! | 12:47 |
| richard_maw | grr, we have serf and neon libraries as dependencies, both of which can provide the http backend, why should subversion decide not to build with them! | 12:54 |
| lostduck | no longer certain of process for handling binaries in baserock, i have cause to depend on a binary, how would i set this up? | 12:56 |
| lostduck | oh there seems to be a morph add-binary command | 13:00 |
| richard_maw | that's for git-fat | 13:01 |
| *** paulwaters_ has quit IRC | 13:01 | |
| richard_maw | careful with it, git becomes decentralised, as you need to fetch the objects over rsync | 13:01 |
| lostduck | okay so if i create an empty repo on my trove and use morph add-binary to add the binary, then i should be fine. | 13:01 |
| *** paulwaters_ has joined #baserock | 13:03 | |
| richard_maw | grr, we don't have http support in our version of svn, because our libserv version is 1.1.0, rather than the required 1.2.1 | 13:06 |
| richard_maw | s/libserv/libserf/g | 13:07 |
| * richard_maw preps definitions patches to update lorry and libserf | 13:12 | |
| * richard_maw grumbles that libserf is from a tarball | 13:15 | |
| paulsherwood | why was that? | 13:16 |
| richard_maw | I don't recall | 13:16 |
| richard_maw | and it's not encouraging that the only version control I can see is https://code.google.com/p/serf/ which is an archived google code page | 13:18 |
| paulsherwood | richard_maw: https://serf.apache.org/download | 13:21 |
| richard_maw | ah, grand! my google bubble wasn't displayin ghtat | 13:21 |
| richard_maw | hmm, unfortunately we're in a bit of a bootstrapping problem, since we need a version of subversion that supports http to get the latest libserf via version control… | 13:22 |
| richard_maw | https://gerrit.baserock.org/1277 for the update to the version of lorry to one that can handle absent tags for subversion imports | 13:25 |
| * richard_maw will prepare a lorry change to update the libserf-tarball lorry | 13:26 | |
| richard_maw | http://imgur.com/gallery/t0XHtgJ | 13:26 |
| ssam2 | integration work is fun! | 13:26 |
| lostduck | just after i read http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gsb2000-02-11.html gitano errd applying some hook after i pushed the change to allow anon access to all repos so that i can view the new repo i created on this trove so that i can add a dependency for the thing i'm trying to build | 13:31 |
| *** franred has quit IRC | 13:32 | |
| gtristan | Well... libpwquality builds with --disable-nls... but we probably want the translations (looking at the po files, they are like "The password is too similar to the old one"... and lots of rich messages that are nice to translate in a UI) | 13:33 |
| gtristan | However: https://git.gnome.org/browse/jhbuild/tree/patches/libpwquality.libintl-link.patch | 13:33 |
| gtristan | jjardon, good candidate for a downstream delta I think... | 13:34 |
| * richard_maw is not going to attempt to integrate libserf 1.3.8, since they changed build-system to scons | 13:35 | |
| paulsherwood | erk. | 13:36 |
| wdutch | if ciat were to push to gerrit then would it need an openid? | 13:36 |
| persia | wdutch: Yes | 13:36 |
| *** nowster has joined #baserock | 13:37 | |
| * wdutch wonders if this means that it shoudl also have an email address | 13:37 | |
| wdutch | if we don't want peoples names involved any more | 13:39 |
| wdutch | must it be a valid email address? | 13:40 |
| persia | When automation is replacing a human function, that automation should be granted many of the things we usually consider to belong to humans. | 13:40 |
| persia | While the current implementation may not, it is not inconceivable that integration automation would want to receive feedback from the review system, so as to have a current understanding of reviews, with email being a reasonably sane event-based notification mechanism. | 13:41 |
| persia | As long as the automation is not yet smart enough to read it's email, it should probably go to a human, but the mailbox should likely be a real mailbox. | 13:42 |
| persia | s/'// | 13:42 |
| *** franred has joined #baserock | 13:44 | |
| wdutch | so have a ciat@baserock.org and for now it can forward to me? who could create this email adress? | 13:44 |
| persia | Once the automation learns to read email, the mail can stop being monitored by a human (although the automation may want to escalate unparseable messages to a human, to avoid needing to have full natural language parsing capabilities) | 13:44 |
| *** zoli_ has joined #baserock | 13:45 | |
| SotK | wdutch: I'd guess ssam2, gary_perkins, franred, or pedroalvarez could create it for you | 13:45 |
| richard_maw | https://gerrit.baserock.org/1278 is the libserf lorry update, so we can update libserf to fix svn to fix lorry | 13:45 |
| persia | That email isn't a bad start. I think you need a member of the ops team to request a mail address from the provider (I don't think we run our own mailserver). | 13:45 |
| wdutch | don't let it learn to read email, it'll just read everythign as 'dog' | 13:45 |
| persia | wdutch: Please do teach it to read review vote feedback, so that it can respond to some things (like if something gets a -1, it ought try to understand why, rahter than just blindly moving forward, etc.) | 13:46 |
| wdutch | if it were smart enough to understand why then the reviewer would not be needed in the first place | 13:47 |
| ssam2 | yep, ops team can create email addresses @baserock.org, just request in email on baserock-dev@ please (so there's a log) | 13:59 |
| ssam2 | might be better to have it forward to you and the rest of the ops team, to reduce bus factor | 14:00 |
| *** mariaderidder has quit IRC | 14:00 | |
| wdutch | okay | 14:01 |
| *** persia has quit IRC | 14:02 | |
| *** locallycompact_ has joined #baserock | 14:03 | |
| richard_maw | franred has +1d https://gerrit.baserock.org/#/c/1278/1, anyone else able to take a quick look? | 14:03 |
| franred | richard_maw, you have my +2 if no one check it in one minute | 14:04 |
| richard_maw | franred: I've got my own +2 for that, I'm hoping for another opinion | 14:04 |
| franred | richard_maw, ok | 14:05 |
| richard_maw | franred: thanks for the offer | 14:05 |
| *** locallycompact has quit IRC | 14:05 | |
| franred | :) no probs | 14:05 |
| *** persia has joined #baserock | 14:10 | |
| *** persia has quit IRC | 14:10 | |
| *** persia has joined #baserock | 14:10 | |
| *** locallycompact_ has quit IRC | 14:11 | |
| richard_maw | thanks ssam2 | 14:12 |
| *** locallycompact has joined #baserock | 14:12 | |
| *** mariaderidder has joined #baserock | 14:16 | |
| *** nowster has quit IRC | 14:24 | |
| *** ssam2 has quit IRC | 15:03 | |
| *** paulwaters_ has quit IRC | 15:27 | |
| wdutch | does firehose work with gerrit? | 15:37 |
| richard_maw | how do you mean? | 15:38 |
| wdutch | it looks to me like to use gerrit you need to clone from gerrit, and do something else to get the hooks | 15:40 |
| wdutch | does firehose support this? | 15:40 |
| SotK | you don't need to clone from gerrit, but you do need to have the commit-msg hook | 15:40 |
| wdutch | okay | 15:40 |
| richard_maw | no, it doesn't support gerrit-style candidate generation | 15:41 |
| SotK | (since commits need change-ids to go on gerrit) | 15:41 |
| bashrc | if it hasn't changed since I last worked on it then yes | 15:41 |
| richard_maw | bashrc: it has, we don't want to generate gerrit candidates until it's been through the pipeline any more | 15:41 |
| *** mariaderidder has quit IRC | 15:41 | |
| richard_maw | bashrc: otherwise you'd just get swamped with candidates, and have robots pushing changes that other robots decide are wrong | 15:41 |
| wdutch | ^_^ | 15:42 |
| wdutch | the intelligent bots that persia wants arguing in mailing lists and on gerrit! | 15:43 |
| wdutch | on the plus side skynet will never happen because they'll be too busy arguing | 15:44 |
| wdutch | does firehose support having base and candidate refs in different hosts? | 15:47 |
| richard_maw | wdutch: erm, not sure | 15:49 |
| wdutch | it doesn't look like it from any of the examples but I'll have a look and see if I can see in the code | 15:49 |
| richard_maw | doesn't appear so | 15:49 |
| Kinnison | Firehose is well before candidates need to be offered to gerrit anyway though, right? | 15:50 |
| wdutch | yes | 15:50 |
| Kinnison | so just have that handled in the "publish" phase at the end of the test cycle | 15:50 |
| wdutch | but if people don't want CIAT pushing to gbo, firehose needs to put it somewhere else for the rest of the pipeline to get it before publish hands it over to gerrit | 15:50 |
| wdutch | 'it' being definitions | 15:51 |
| SotK | can the orchestration machine serve its own mirror or something? | 15:51 |
| wdutch | this is what I'm thinking but firehose will always try and push definitions to the repo it got it from afaict | 15:52 |
| Kinnison | Why would firehose not push to gbo? | 15:52 |
| wdutch | Kinnison: see discussion from 11:45 | 15:54 |
| richard_maw | wdutch: that was a misconception of what it would be pushing I think | 15:54 |
| wdutch | people said they don't want gbo cluttered with branches being used by CIAT | 15:55 |
| richard_maw | if they are ephemeral, namespaced and not too many, I don't think it matters too much, though there is the point that temporary branches would get lorried downstream | 15:56 |
| Kinnison | so namespace them outside of refs/heads and refs/tags | 15:57 |
| Kinnison | I think we explicitly don't lorry anything outside of those refs spaces | 15:57 |
| Kinnison | But if people are really that whingy, set up a separate trove which mirrors just the definitions repo and have firehose operate on that | 15:57 |
| Kinnison | seems a tad overkill though | 15:57 |
| *** toscalix__ has joined #baserock | 15:58 | |
| Kinnison | However if people really want, then yeah, you could trivially add an additional remote support into firehose and have it pull from one remote and push to another | 15:58 |
| richard_maw | Kinnison: I'd prefer that, and while you wouldn't get the non-heads or tags downstream, you've also got to persuade lorry that you're allowed to push outside of refs/heads and refs/tags | 15:59 |
| Kinnison | Meh it's trivial to futz about with a trove's ruleset, esp. if it's a special-case one | 16:00 |
| *** CTtpollard has quit IRC | 16:01 | |
| *** ssam2 has joined #baserock | 16:17 | |
| *** ChanServ sets mode: +v ssam2 | 16:17 | |
| *** toscalix__ is now known as toscalix | 16:20 | |
| *** ssam2 has quit IRC | 16:43 | |
| richard_maw | https://gerrit.baserock.org/1279 to fix the libserf thing | 16:44 |
| richard_maw | though being able to lorry webkit will require a proper update to git.baserock.org after that has been merged | 16:45 |
| franred | richard_maw, just a little comment about it.... unpetrify-ref :D | 16:52 |
| richard_maw | ha!, you're right | 16:53 |
| richard_maw | master and baserock/morph used to be the same | 16:53 |
| richard_maw | updated | 16:54 |
| franred | :D | 16:56 |
| *** bashrc has quit IRC | 17:00 | |
| *** jonathanmaw has quit IRC | 17:00 | |
| *** toscalix has quit IRC | 17:27 | |
| *** locallycompact has quit IRC | 17:33 | |
| *** persia has quit IRC | 17:35 | |
| *** persia has joined #baserock | 17:36 | |
| *** persia has quit IRC | 17:36 | |
| *** persia has joined #baserock | 17:36 | |
| *** toscalix has joined #baserock | 17:43 | |
| *** SotK has quit IRC | 17:45 | |
| *** SotK has joined #baserock | 17:45 | |
| *** toscalix has quit IRC | 17:48 | |
| *** franred has quit IRC | 17:48 | |
| *** franred has joined #baserock | 18:21 | |
| *** locallycompact has joined #baserock | 18:27 | |
| SotK | anyone around that knows if it would be feasible to make the ciat pipeline config accessible using the API? | 18:40 |
| jjardon | seems mason disk is full | 18:40 |
| *** franred has quit IRC | 18:56 | |
| *** locallycompact has quit IRC | 20:48 | |
| *** robtaylor has quit IRC | 21:26 | |
| pedroalvarez | jjardon: mason failure looks really weird.. | 21:37 |
| pedroalvarez | It has around 70G available | 21:37 |
| pedroalvarez | it seems to me that the gnome rootfs doesn't fit in the 6G of DISK_SIZE | 21:38 |
| pedroalvarez | but I may be wrong | 21:39 |
| pedroalvarez | yeah, is not Mason's disk, it's gnome's image disk | 21:46 |
| *** gtristan has quit IRC | 22:10 | |
| paulsherwood | Baserock GENIVI Demo Platform in Seoul will be livecast https://t.co/V2pevEDynq | 23:26 |
| pedroalvarez | exciting! | 23:41 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!