| *** zoli__ has joined #baserock | 03:24 | |
| *** zoli__ has quit IRC | 05:56 | |
| *** zoli__ has joined #baserock | 06:16 | |
| *** mariaderidder has joined #baserock | 06:45 | |
| *** ssam2 has joined #baserock | 06:47 | |
| *** ChanServ sets mode: +v ssam2 | 06:47 | |
| *** a1exhughe5 has joined #baserock | 07:11 | |
| *** Albert_ has joined #baserock | 07:31 | |
| *** zoli___ has joined #baserock | 07:39 | |
| *** zoli__ has quit IRC | 07:39 | |
| petefoth | The new guide at http://wiki.baserock.org/guides/ceph-cluster-deploy/ referes in a few places to pdar's github 'working copy' clone of definitions.git. Can this be changed to refer to g.b.o instead? | 07:41 |
|---|---|---|
| pedroalvarez | I like to have someone checking the wiki :) Thanks petefoth | 08:01 |
| petefoth | pedroalvarez: There are a couple of typos that I'll correct but I don't want to mess with the technical stuff ;) | 08:02 |
| pedroalvarez | STATUS UPDATE of Mason: Cleaning the cache fixed the error, but some weird error happened (kernel panic), so it has started building 3 hours ago | 08:03 |
| *** sherm_ has joined #baserock | 08:04 | |
| *** bashrc_ has joined #baserock | 08:05 | |
| pedroalvarez | petefoth: IMO yes, we should merge the content of that branch (of that gihub repo) in master of definitions.git on g.b.o | 08:07 |
| *** edcragg has joined #baserock | 08:08 | |
| pedroalvarez | let's wait for pdar's input and see what we can do | 08:08 |
| petefoth | pedroalvarez: but probably best not to change the wiki until the merge is done. That could be added as a comment in gerrit to the review of pdar's patch(es) | 08:09 |
| *** jonathanmaw has joined #baserock | 08:19 | |
| pdar | petefoth: Thanks for having a look over the new page, hope there wernt too many typos! Yep, aiming to get it merged with master at some point in the coming day/s. | 08:35 |
| pdar | Then i'll update the wiki accordingly | 08:36 |
| petefoth | pdar: OK | 08:36 |
| *** rdale has quit IRC | 08:48 | |
| *** gary_perkins has joined #baserock | 08:52 | |
| *** rdale has joined #baserock | 08:53 | |
| *** ratmice__ has quit IRC | 09:04 | |
| *** ratmice__ has joined #baserock | 09:04 | |
| *** lachlanmackenzie has joined #baserock | 09:15 | |
| *** Krin has joined #baserock | 09:24 | |
| *** mauricemoss_ has joined #baserock | 09:29 | |
| pedroalvarez | franred: you could have sent the patch using the same change ID (git upgrade) | 10:01 |
| franred | pedroalvarez, I though that sending with the same topic it will rewrite the previous one... now I know I can use the same ID - thanks | 10:02 |
| jjardon | weston system built without problem in armv7 as well, time to upgrade to GCC 5.1? :) https://gerrit.baserock.org/#/c/462/1 | 10:04 |
| franred | jjardon, I've tested git 2.3.7 so you can abandon 2.3.5 patch ;-) | 10:04 |
| franred | jjardon, https://gerrit.baserock.org/#/c/484/ | 10:05 |
| jjardon | franred: nice!, next time rebase and submit again instead open a new change! | 10:06 |
| franred | jjardon, ok!! | 10:06 |
| Kinnison | franred: in addition to lorry, things which interface to git on the trove include gitano and the morph cache server | 10:25 |
| franred | Kinnison, aham, can we create tests for checking that these interfaces do not break trove when we update git? | 10:28 |
| Kinnison | The best test is to instantiate a trove, let it populate, and do a system build against it with a morph whose local caches are not populated | 10:29 |
| Kinnison | The git server does have some tests but its test suite is vastly incomplete | 10:30 |
| * Kinnison is also unsure if we run that suite (which ought to work during build, providing yarn, ssh etc are available) | 10:30 | |
| franred | Kinnison, ok, I will set up a trove to test it, but this is a very time consuming way to test that we can upgrade git... | 10:32 |
| Kinnison | Also you should probably verify that the new git works against gerrit | 10:33 |
| Kinnison | since gerrit's internals are special | 10:33 |
| pedroalvarez | franred giving up in 5 | 10:33 |
| pedroalvarez | 4 | 10:33 |
| pedroalvarez | 3 | 10:33 |
| franred | Kinnison, I've tested gerrit yesterday, I've sent the patch to fix the morph check failure from the new VM :) | 10:34 |
| Kinnison | franred: sounds good | 10:34 |
| Kinnison | so just trove to validate :) | 10:34 |
| franred | Kinnison, hehe, I think that is not an easy task ;-) | 10:35 |
| pedroalvarez | it should be! :) | 10:36 |
| Kinnison | franred: it should be easy, just perhaps wallclock time consuming | 10:37 |
| Kinnison | franred: just deploy a trove, let it populate, and run some builds against it | 10:37 |
| Kinnison | most of that is waiting | 10:37 |
| * pedroalvarez is making a video about deploying openstack on baserock to hardware using pxeboot.write , and then deploying a trove and a devel system to it | 10:38 | |
| franred | build trove, deploy it and configure trove, wait until populate, change a system to point to that trove ... and build something from it... | 10:38 |
| pedroalvarez | believe me, deploying the trove is one of the easier parts of the video | 10:38 |
| franred | it sounds very time consuming | 10:38 |
| Kinnison | franred: Yes, but mostly wallclock time, not your brain time | 10:39 |
| Kinnison | franred: are you anxious that this patch should be merged very soon? | 10:39 |
| franred | Kinnison, no, not really, I prefer that it does not break anything | 10:40 |
| *** DavePage_ has joined #baserock | 11:04 | |
| *** straycat has quit IRC | 11:28 | |
| *** petefoth has quit IRC | 11:36 | |
| richard_maw | Hi, I've got a patch to add a `morph anchor` command, that pushes branches to the trove to ensure commits that are needed to build are not lost. https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:master+topic:morph-anchor is the gerrit topic. | 11:40 |
| richard_maw | It's 7 patches long, but 5 of them are only a couple of lines each | 11:41 |
| jjardon | Hi ssam2 ! about https://gerrit.baserock.org/#/c/433/ : I agree with you, but, shouldn't we do the same every time a new extension is introduced in morph as well? | 11:41 |
| franred | I want to move pexpect out from cxmanage and openstack-services strata...it is a python package so even I can move it to python-core, python-common or python-tools... but cxmanage does not have any of these strata as build dependecy nor in the system | 11:41 |
| richard_maw | I'm aware of cases I need to test for and possibly bugfix for the command itself, but I thought I'd send the series now, as its basic functionality works, and I'd like feedback. | 11:42 |
| richard_maw | btw, the point of `morph anchor` would be to allow reproducibility of a system even if upstream decided to delete those commits | 11:43 |
| richard_maw | jjardon: ^ means that if we only care about reproducibility of releases, we may be able to just use the tag name as the ref | 11:45 |
| jjardon | \o/ | 11:46 |
| richard_maw | don't celebrate yet, we haven't yet decided that only releases are important for reproducibility | 11:46 |
| jjardon | :) sure, but at least we now have the tooling to make the decision possible | 11:47 |
| richard_maw | but it does mean that in the case of upstream discarding commits, you don't need to grobble around in the repo caches of everyone who has built that system to be able to resurrect the commit | 11:47 |
| jjardon | franred: Id use python-common | 11:57 |
| franred | jjardon, and add python-common to cxmanage? it would add a lot of python packages not required by cxmanage system | 11:58 |
| radiofree | jjardon: did the gcc 5.1 on arm build work? | 11:58 |
| jjardon | radiofree: yes | 11:58 |
| ssam2 | jjardon: yes, every time we make a change that means the last released version of Morph can't build 'master' of definitions we need to wait to merge it until we have done a release | 11:58 |
| ssam2 | otherwise we get in situations where people have to hack Morph into working just to be able to upgrade | 11:59 |
| *** straycat has joined #baserock | 12:00 | |
| radiofree | jjardon: nice! | 12:01 |
| ratmice__ | richard_maw: an escape hatch allowing history rewrite, for unfortunate 'legal reasons'? | 12:02 |
| jjardon | ssam2: ok, IIRC we have introduced and use several extensions in this cycle, so I guess we have to do better in the next one | 12:04 |
| radiofree | is there a quick way of adding a change-id to an existing set of commits? | 12:05 |
| richard_maw | ratmice__: it makes reproducibility possible if upstream had to do a rewrite, but odds are if that happens you're not supposed to have the anchor refs, so you may have to do a point release with the rewritten history and remove the anchors for the release you have to drop | 12:06 |
| richard_maw | radiofree: add the hook and do a git rebase -i and pick reword | 12:06 |
| radiofree | ah, so reword on each commit is sufficient? | 12:06 |
| radiofree | richard_maw: thanks | 12:07 |
| ratmice__ | ssam2: in theory a release could contain a placeholder morph package, upon release of the next delta of baserock release an update to the previous system which turns the placeholder into a version of morph capable of building the delta | 12:07 |
| ratmice__ | that might at least get rid of the 'hack morph into working' into a well defined process | 12:08 |
| jjardon | franred: yeah :( the only solution for that is to create its own stratum :/ | 12:08 |
| radiofree | the "contributing" wiki page is excellent! thanks to whoever wrote that | 12:21 |
| *** a1exhughe5 has quit IRC | 12:31 | |
| *** sherm_ has quit IRC | 12:34 | |
| *** a1exhughe5 has joined #baserock | 12:43 | |
| *** sherm_ has joined #baserock | 12:48 | |
| jjardon | ssam2: hey, when I try to add you as a reviewer, I get this error: "Sam Thursfield <sam.thursfield@codethink.co.uk> does not identify a registered user or group" | 13:05 |
| jjardon | (It doesnt happen with others) | 13:06 |
| ssam2 | weird, i don't know why | 13:11 |
| jjardon | ssam2: anyway, this is the patch Id like you to take a look when you have some time: https://gerrit.baserock.org/#/c/499/ | 13:15 |
| jjardon | radiofree: thanks for the review! I guess you agree with https://gerrit.baserock.org/#/c/461/ as well? | 13:19 |
| radiofree | yes | 13:23 |
| *** Albert_ has quit IRC | 13:28 | |
| *** Albert_ has joined #baserock | 13:33 | |
| ssam2 | jjardon: that will break the next release | 13:43 |
| ssam2 | Morph from 15.17-rc doesn't understand version 3 so won't be able to build it | 13:43 |
| ssam2 | we need to make a release with Morph that understands version 3, *then* bump the version of our reference definitions | 13:43 |
| Kinnison | I continue to worry that we're incrementing the version number while still not knowing what the current behaviour truly is | 13:44 |
| ssam2 | it could be merged to a branch while we wait for that to happen | 13:44 |
| jjardon | ssam2: https://gerrit.baserock.org/#/c/499/ is the patch to add support to version 3 in morph :) | 13:44 |
| ssam2 | Kinnison: what can we do to remove your worries? | 13:44 |
| ssam2 | jjardon: ah, ok. I thought it was a patch for definitions, not morph :) | 13:44 |
| Kinnison | ssam2: sadly the only thing to do is to invest the time to do the documentation | 13:44 |
| jjardon | ssam2: this is the one for definitions: https://gerrit.baserock.org/#/c/433/ | 13:45 |
| ssam2 | Kinnison: in that case, I share your worries. | 13:45 |
| richard_maw | \o/ gertty shows dependency trees like mutt! | 13:45 |
| ssam2 | jjardon: could you update http://wiki.baserock.org/definitions/historical/ with V2 and V3 ? | 13:48 |
| jjardon | ssam2: sure | 13:49 |
| radiofree | jjardon: how do i add a comment in yaml? | 13:58 |
| Kinnison | yaml comments are prefixed by # | 13:59 |
| paulsherwood | radiofree: eg http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/build-essential/stage1-gcc.morph | 14:00 |
| radiofree | ta | 14:00 |
| * radiofree wonders if adding a comment forces a rebuild | 14:00 | |
| paulsherwood | radiofree: do you want to force a rebuild? | 14:01 |
| radiofree | no | 14:02 |
| radiofree | "echo hello" is my goto for force-rebuilds | 14:02 |
| *** zoli___ has quit IRC | 14:03 | |
| paulsherwood | :) | 14:03 |
| persia | gertty is workig now? What was the change that was required? | 14:04 |
| Kinnison | persia: proper https IIRC | 14:05 |
| persia | Ah, that would do it. | 14:05 |
| Kinnison | persia: and enabling some config or other | 14:05 |
| radiofree | i thought pedroalvarez installed a module? | 14:05 |
| radiofree | jjardon: http://fpaste.org/216739/30316313/ is ok? | 14:05 |
| jjardon | radiofree: sure | 14:06 |
| radiofree | you're a tough man to please jjardon, resubmitted | 14:09 |
| pedroalvarez | persia: proper https and download-commands plugin | 14:13 |
| persia | Ah, the plugin. That was the confusing bit. Thanks. | 14:13 |
| * radiofree will try gerrty | 14:15 | |
| radiofree | s/gerrty/gertty/ | 14:15 |
| radiofree | nowster: i think you looked into an issue where baserock would dirty the kernel trees? | 14:18 |
| nowster | yes | 14:18 |
| radiofree | what was the cause? | 14:18 |
| richard_maw | radiofree: adding comments doesn't cause a reubild | 14:19 |
| richard_maw | or a rebuild | 14:19 |
| nowster | git tree in inconsistent state. Cure was to run "git status" before the make xxxx_defconfig | 14:19 |
| Kinnison | nowster: bleurgh | 14:20 |
| radiofree | :\ | 14:21 |
| jjardon | ssam2: done, maybe you can take a look to check everything is ok | 14:30 |
| * radiofree thinks system-version-manager is the best thing ever | 14:34 | |
| jjardon | radiofree: whats that? | 14:38 |
| richard_maw | radiofree: it'll be better when I have the time to do live atomic update | 14:38 |
| *** bashrc_ has quit IRC | 14:41 | |
| *** bashrc_ has joined #baserock | 14:42 | |
| pedroalvarez | radiofree: thanks for the compliment | 14:45 |
| pedroalvarez | well, it has many authors now | 14:46 |
| paulsherwood | i saw this question and wondered if anyone here might know 'Anyone know how Thrift is implementing their interface-to-C mapping?' ? | 14:47 |
| *** zoli__ has joined #baserock | 14:47 | |
| paulsherwood | (from http://lists.genivi.org/pipermail/genivi-ipc/2015-April/000348.html) - i appreciate it's off-topic here, though | 14:48 |
| ssam2 | jjardon: there are two ways to do this I guess | 14:49 |
| ssam2 | jjardon: one is to create a http://wiki.baserock.org/definitions-V3/, http://wiki.baserock.org/definitions-V4/, http://wiki.baserock.org/definitions-V5/ etc. | 14:50 |
| ssam2 | I prefer the approach of having http://wiki.baserock.org/definitions/current/ http://wiki.baserock.org/definitions/historical/ and http://wiki.baserock.org/definitions/planned/ | 14:50 |
| ssam2 | I think will be annoying having the format of definitions spread over N wiki pages | 14:50 |
| paulsherwood | ssam2: +1 | 14:50 |
| jjardon | yeah, me too, I will move them | 14:51 |
| ssam2 | cool | 14:51 |
| jjardon | jonathanmaw: thanks for fixing logind/pam! | 15:01 |
| radiofree | does this mean gnome will work now?! | 15:01 |
| * Kinnison thinks that to have a competent description of the definitions format in a single wiki page will be horrendously unpleasant | 15:02 | |
| jjardon | maybe :) | 15:02 |
| nowster | who are the best people to request reviews of a lorry addition? | 15:03 |
| paulsherwood | us! :) | 15:03 |
| radiofree | if you're talking about https://gerrit.baserock.org/#/c/501/ i've already +1ed it | 15:03 |
| nowster | oh! ta, radiofree :) | 15:04 |
| paulsherwood | merged | 15:04 |
| nowster | that was quick! | 15:04 |
| paulsherwood | :-) | 15:04 |
| paulsherwood | baserockers... could/should gerrit notify the list of patches for review? since gerrit i feel out of touch | 15:05 |
| Kinnison | gerrit's notification format is.... unpleasant | 15:06 |
| SotK | paulsherwood: you can set it to email you if a new patch is submitted | 15:06 |
| paulsherwood | SotK: wouldn't list members prefer to know in general (ie not just me)? it seems we took this info away without consensus | 15:09 |
| *** wschaller has joined #baserock | 15:09 | |
| ssam2 | we could set up a second list for notifications from Gerrit, maybe | 15:10 |
| * Kinnison would be fine with a second list | 15:10 | |
| * Kinnison wouldn't like to see patch notifications going to -dev given half the reason for gerrit was to get patch discussion *off* the list | 15:10 | |
| * richard_maw would be fine with it going to the current list, provided it is just merges and reverts | 15:10 | |
| ssam2 | people have complained about how high-traffic baserock-dev was when all patches went through it, so it seems like it'd be good to not send lots of generated emails from gerrit to baserock-dev | 15:10 |
| Kinnison | If we want another list @baserock.org, please leave me a /msg with the desired name and initial list owner and I'll sort it out later | 15:11 |
| * Kinnison has to run away now to get his car back | 15:11 | |
| DavePage_ | This is possibly a philosophical question, but if you're deploying a web app server image with Baserock there are basically three components - (a) the underlying OS, web server and interpreter; (b) the web application code; and (c) the data the web app operates on. Do people think it makes most sense to use the Baserock tooling to create reproducible builds of a, a&b, or a&b&c? | 15:13 |
| jjardon | paulsherwood: you can select the project you want to watch (and in what detail) here: https://gerrit.baserock.org/#/settings/projects | 15:14 |
| richard_maw | jjardon: notably there is no option for *no* e-mail | 15:14 |
| jjardon | richard_maw: Not sure I understood you sentence correctly, but I think you achieve that if you uncheck all the boxes? | 15:17 |
| paulsherwood | DavePage_: depends on the app... what kind of 'data' for example? | 15:17 |
| richard_maw | jjardon: I have no boxes to tick, I never selected to watch any projects, but I get e-mail from gerrit about reviews all the time | 15:18 |
| DavePage_ | paulsherwood: As an example, a wiki instance. | 15:18 |
| persia | DavePage_: I'd do a&b&c, and use different sets of strata for each. This would give me confidence that I could adjust the strata for c, without changing a&b, or the strata for a, without changing b&c, safely. If a change in a is low enough to require a rebuild of b or c, morph will manage this for you, but your artifacts will differ, so you can know (but never have to ship an A that provides a different ABI than your B expects, etc.) | 15:19 |
| * persia adds to the chorus for having a baserock-changes@ or similar list, rather than causing non-patch discussions to be lost in baserock-dev again. | 15:20 | |
| jmacs | a&b definitely. C gets interesting - the data would be coming from some existing external source, not git, wouldn't it? | 15:20 |
| DavePage_ | Unless you start keeping verbose MySQL dumps in git, I guess | 15:20 |
| DavePage_ | Which sounds like it'd get rapidly painful. | 15:20 |
| rdale | i could see how you could define a specific database schema for 'c', and configuration, but not the data itself | 15:21 |
| paulsherwood | DavePage_: if the wiki is git-backed, a+b+c imo | 15:21 |
| jjardon | richard_maw: oh, probably because you are one of the reviewers. Not sure you can deactivate that | 15:21 |
| DavePage_ | paulsherwood: And if it isn't? | 15:21 |
| jmacs | Yes, I suppose you could just treat the wiki's repository as a component and grab the latest version of it | 15:22 |
| jmacs | Dump existing MySQL database, then import it as tarball, rather than a repository | 15:23 |
| DavePage_ | And then rebuild the whole image when the web app code (b) changes? | 15:23 |
| SotK | DavePage_: yes, but assuming you don't lose the cached artifacts only the web app code and anything which depends on it will actually be rebuilt | 15:25 |
| DavePage_ | *nods* | 15:26 |
| *** jonathanmaw has quit IRC | 15:26 | |
| DavePage_ | I'm just trying to groupthink what "best practice" is here | 15:26 |
| gary_perkins | In a recent project, the web-app code was just ruby, so nothing to buid as such. It might as well be just HTML. | 15:26 |
| DavePage_ | Well, building can just be copying files into the right place :) | 15:26 |
| DavePage_ | See `man install` for details :) | 15:27 |
| gary_perkins | Seems a lot easier to maintain the web-app code separately in a differnt repo and have the web-system pull from it | 15:27 |
| DavePage_ | Or just lorry it from that different repo? | 15:27 |
| ssam2 | DavePage_: in practice, I've found that it's much quicker to develop the web application from a git checkout on the target | 15:29 |
| jjardon | can I have a quick review of (use latest morph in definitions) https://gerrit.baserock.org/#/c/485/ | 15:30 |
| gary_perkins | DavePage_: That sounds like it could work, but I'm open to suggestions. I've never actully setup lorrying myself. | 15:30 |
| DavePage_ | ssam2: Yeah, I'm sure it's quicker, but that doesn't mean it's necessarily right :) Particularly if you're not actively developing, but providing Baserock systems using an upstream. | 15:30 |
| ssam2 | DavePage: and so if the web application is reasonably self-contained, I'd recommend deploying the base OS with Baserock, then deploying the web-app after the fact with an Ansible script that you run after deployment | 15:30 |
| ssam2 | if the Ansible script is commited to Git, then the process is just as reproducible as if you used Morph, but it makes it much easier to hack on the application if you need to | 15:31 |
| ssam2 | when you're done hacking, update the ansible script and rerun it, and your running system is in the same state as if you had redeployed it | 15:31 |
| ssam2 | (modulo any bugs in Ansible) | 15:31 |
| ssam2 | if you're not actively developing then there probably isn't any advantage to that approach | 15:32 |
| DavePage_ | ssam2: And your way does assume the upstream does't disappear... | 15:34 |
| * radiofree wonders what mason is up to these days | 15:34 | |
| ssam2 | DavePage_: in my case, I was the upstream, so was pretty confident of that :) | 15:34 |
| DavePage_ | ssam2: Yes, that won't always be the case though :) | 15:35 |
| ssam2 | tiagogomes: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/morphlib/exts/sysroot.write?id=807e6a90876c5469d2421a47649d15f06e94ca36 has broken sysroot.write for some users | 15:36 |
| ssam2 | who are using a cluster like this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/sdk-example-cluster.morph | 15:36 |
| ssam2 | the errors we get are stuff like "mv: can't rename '/src/tmp/deployments/.../sbin': Directory not empty" | 15:37 |
| ssam2 | seems that before, the sdk system contained a bunch of toolchain stuff in /usr/armv7lhf.../sys-root which the sysroot.write extension deleted | 15:37 |
| ssam2 | but now that sysroot.write doesn't delete that directory, we get errors moving stuff into place | 15:38 |
| ssam2 | i'm struggling to understand why things work this way | 15:38 |
| ssam2 | in particular I'm confused why we had armv7lhf-cross-toolchain stratum installing a bunch of stuff into /usr/armv7lhf../sysroot/ that was then deleted again | 15:41 |
| radiofree | pedroalvarez: what's mason doing? | 15:44 |
| ssam2 | we have worked around it by changing 'mv' to 'cp', but it seems that something more fundamental is wrong with this approach... | 15:46 |
| ssam2 | i'll send a patch to change sysroot.write and we can discuss further what's actually going on with it :) | 15:46 |
| tiagogomes | ssam2 IIRC, the reason why I added code to force the directory to not exist was because of you set a sysroot=/ you would delete your host system files. But if we run the configuration extension in a chroot I guess it is safe | 15:47 |
| ssam2 | ah, ok | 15:47 |
| ssam2 | it's still annoying to delete your whole chroot... it's kind of a problem with .configure and .write extensions in general | 15:48 |
| ssam2 | thanks for the explaination, makes sense anyway | 15:48 |
| radiofree | nowster: git status worked for me as well | 15:49 |
| radiofree | x86 images don't seem to suffer from this | 15:49 |
| radiofree | gcc 5.1! | 15:50 |
| *** a1exhughe5 has quit IRC | 15:50 | |
| ssam2 | I've sent https://gerrit.baserock.org/#/c/502/ about the sysroot.write issue. would like to investigate more but don't have time right now | 15:54 |
| *** ssam2 has quit IRC | 15:56 | |
| *** mariaderidder has quit IRC | 15:59 | |
| persia | I missed the good bit, but I'm actively against using a local checkout of code on production systems. | 16:00 |
| persia | One should develop it on a development system: running `morph update` to update a target with the new changes in the updated git repo is relatively easy and smooth. | 16:01 |
| * persia has seen too many cases where the production checkout was dirty, causing all sorts of headaches when troubleshooting production issues | 16:01 | |
| jjardon | pedroalvarez: Do you know what was the last commit in definitions mason built correctly? | 16:11 |
| * jjardon want to use the cache instead build master | 16:11 | |
| rdale | can gerrit patches for different repos have the same topic name? | 16:14 |
| paulsherwood | rdale: only one way to find out | 16:20 |
| rdale | yes, i'll try it - i have two related patches for different repos, and it would be nice to be able to tie them together | 16:20 |
| paulsherwood | am i the only person that thinks extensions might be better in definitions, rather than morphlib? | 16:21 |
| * radiofree uses baserock on a t510 | 16:23 | |
| radiofree | i think i'll put a weston system on here | 16:23 |
| persia | paulsherwood: I don't believe so: I seem to recall someone saying "when we move all the extensions to definitions" at some point in the past. | 16:25 |
| persia | That said, I don't really like the mixing of declaratove definition with executable code. | 16:25 |
| robtaylor | persia: its not too bad as long as you treat the executable code as 'data' whose use is defined declaritively | 16:27 |
| robtaylor | paulsherwood: i belive at least me and jjardon also agree that extensions should go in definitions | 16:29 |
| jjardon | radiofree: NICE!! | 16:29 |
| radiofree | mandatory video http://seriousinternetbusiness.com/james/baserock-thinkpad.mp4 | 16:31 |
| *** mauricemoss_ has quit IRC | 16:31 | |
| pedroalvarez | radiofree: cool | 16:35 |
| paulsherwood | all your thinkpad r belong to us :-) | 16:36 |
| paulsherwood | robtaylor: :-) | 16:36 |
| pedroalvarez | radiofree: sorry, I was busy before, mason is building things :) | 16:45 |
| pedroalvarez | we had some problems with it yesterday | 16:46 |
| pedroalvarez | jjardon: d4934769e522137f872cece4e86002cfbb45f62d | 16:46 |
| radiofree | mason is red | 16:46 |
| pedroalvarez | jjardon: but it has to have some new cache | 16:46 |
| pedroalvarez | radiofree: yes yes I know | 16:46 |
| pedroalvarez | nothing to worry about | 16:46 |
| jjardon | pedroalvarez: thanks! | 16:46 |
| radiofree | trying to read the log crashed my firefox :( | 16:47 |
| pedroalvarez | hah | 16:47 |
| pedroalvarez | oh, I think mason now needs a newer version of morph | 16:47 |
| *** Krin has quit IRC | 16:54 | |
| pedroalvarez | urgh... I think I upgraded mason to a broken version of morph: https://mason-x86-64.baserock.org/log/e6befc339259a9d45295ae25e575a847033ac420--2015-04-29%2017:12:01.log | 17:15 |
| radiofree | :/ | 17:16 |
| pedroalvarez | Don't have time to investigate now, so I moved to a previous version | 17:17 |
| radiofree | compiling this fedora kernel takes aaaaaages | 17:19 |
| radiofree | so many modules... | 17:19 |
| *** De|ta_ has joined #baserock | 17:22 | |
| *** radiofree is now known as Radiofree | 17:24 | |
| *** Radiofree is now known as radiofree | 17:24 | |
| *** wschaller has quit IRC | 17:30 | |
| jjardon | Can I have a quick review for: https://gerrit.baserock.org/#/c/529/ (use hash instead tag) | 17:31 |
| franred | jjardon, done | 17:36 |
| jjardon | cheers | 17:36 |
| *** franred has quit IRC | 17:39 | |
| tlsa | benucrush | 17:58 |
| tlsa | wrong window! | 17:58 |
| *** lachlanmackenzie has quit IRC | 18:31 | |
| *** sherm_ has quit IRC | 20:02 | |
| *** gary_perkins has quit IRC | 20:23 | |
| jjardon | mmm, seems the btrfs-progs repo has not been updated for the last 3 months: http://git.baserock.org/cgi-bin/cgit.cgi/delta/btrfs-progs.git/ | 20:23 |
| jjardon | current upstream: http://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git | 20:23 |
| *** flatmush has quit IRC | 20:24 | |
| *** Albert_ has quit IRC | 20:41 | |
| pedroalvarez | jjardon: is not pointing to the right one? | 20:51 |
| jjardon | pedroalvarez: the lorry is pointing to the correct one | 20:52 |
| pedroalvarez | BTW, we had some issues the last time that we upgraded it | 20:52 |
| pedroalvarez | jjardon: Ok, I'll take a look | 20:52 |
| * jjardon thinks found a bug in the install-files extension. will submit a patch | 21:55 | |
| * jjardon files https://gerrit.baserock.org/#/c/530/ | 22:03 | |
| *** zoli__ has quit IRC | 22:11 | |
| pedroalvarez | jjardon: btrfs-progs was OK, I think | 23:00 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!