| *** gtristan has quit IRC | 00:07 | |
| *** bfletcher has quit IRC | 00:23 | |
| *** bfletcher has joined #baserock | 00:28 | |
| *** fay_ has joined #baserock | 00:46 | |
| *** fay_ has quit IRC | 00:55 | |
| *** fay_ has joined #baserock | 01:06 | |
| *** fay_ has quit IRC | 01:20 | |
| *** gtristan has joined #baserock | 01:29 | |
| *** gtristan has quit IRC | 06:09 | |
| *** gtristan has joined #baserock | 06:10 | |
| *** franred has joined #baserock | 06:11 | |
| paulsherwood | surprisingly, instances:2, max-jobs:8 is even faster... | 06:19 |
|---|---|---|
| paulsherwood | 1 15-10-07 03:23:17 [172/278/278] [TOTAL] Elapsed time 03:23:17 | 06:20 |
| paulsherwood | 0 15-10-07 03:23:21 [106/278/278] [TOTAL] Elapsed time 03:23:21 | 06:20 |
| gtristan | hmmm, any tips on getting the pointer device working in kvm ? | 06:43 |
| gtristan | seems the baserock built Xorg doesnt have any appropriate driver for the device kvm is exporting | 06:44 |
| * gtristan thinks, kvm is just mirroring what is on my laptop ? | 06:45 | |
| * gtristan 's host Xorg loads synaptics_drv, better to try VirtualBox, maybe it will at least emulate something easier to cope with | 06:52 | |
| tiredcat | wouldn't it be beter to just fix X? | 06:53 |
| tiredcat | also if you're using virt-manager you can specify what sort of mouse to add ps/2, usb etc | 06:53 |
| * gtristan installs virt-manager | 06:56 | |
| gtristan | tiredcat, I'm not sure honestly, havent had to dabble in VMs until now | 06:57 |
| gtristan | if the statement 'kvm mirrors my host system' is a true one, then yeah, ensuring that xorg has the synaptics input drivers built and installed would be the solution | 06:58 |
| tiredcat | i don't think kvm mirrors your host drivers | 06:59 |
| gtristan | I mean devices, not drivers, but I have no clue really | 07:01 |
| tiredcat | yes i also meant devices :) | 07:01 |
| *** ssam2 has joined #baserock | 07:09 | |
| *** ChanServ sets mode: +v ssam2 | 07:09 | |
| jjardon | gtristan: do you get the same if you try to start a Wayland session? I ask because weston seems to work correctly in KVM (with the fb backend)(i think I added weston to the GNOME system just to test this things) | 07:17 |
| jjardon | gtristan: did you fix the gnome-keyring issue yesterday? The link you posted seems to en empthy | 07:20 |
| gtristan | jjardon, did not get to the bottom of gnome-keyring | 07:22 |
| gtristan | jjardon, question: has the xorg build been tested in anything else, other than gnome-system-x86_64 ? | 07:23 |
| jjardon | No that im aware of | 07:24 |
| gtristan | aha | 07:24 |
| gtristan | that's nice to know :) | 07:24 |
| gtristan | well, kvm gives us a mouse and it works, that's for sure | 07:26 |
| gtristan | so says cat /dev/input/mouse0 | 07:26 |
| gtristan | so then I have xorg stuff to figure out | 07:27 |
| gtristan | jjardon, you are building *everything* in xorg ? or have you left anything out ? | 07:27 |
| jjardon | Xorg has a lot of diferentes modules, its possible that something is missing | 07:30 |
| gtristan | I notice that there are complaints about fonts, but that's a tricky part of the config, and may have to do with missing --sysconfdir=/etc | 07:31 |
| gtristan | probably we still have fc-cache things to call also | 07:31 |
| gtristan | but I think the input drivers are there | 07:31 |
| *** paulw has joined #baserock | 07:42 | |
| *** persia has quit IRC | 07:59 | |
| *** persia has joined #baserock | 08:00 | |
| *** toscalix__ has joined #baserock | 08:04 | |
| *** bashrc has joined #baserock | 08:05 | |
| *** mariaderidder has joined #baserock | 08:12 | |
| gtristan | with some tweaking, X -retro shows a working pointer device, but gnome-shell still hangs... lets look at what mutter is doing wrong... | 08:28 |
| *** De|ta has quit IRC | 08:29 | |
| *** De|ta has joined #baserock | 08:29 | |
| Kinnison | isn't mutter built into gnome-shell these days? | 08:29 |
| gtristan | not that I can see | 08:32 |
| gtristan | but this looks like the culprit: https://mail.gnome.org/archives/commits-list/2014-July/msg04275.html | 08:33 |
| gtristan | well, that looks like the fix for the problem | 08:33 |
| * gtristan thinks better try master of gnome-shell/gnome-session/mutter | 08:33 | |
| Kinnison | Modern gnome-shell seems to fold window-management into itself | 08:33 |
| Kinnison | Certainly since 3.14 I've been unable to run xmonad with gnome-shell | 08:34 |
| gtristan | well, the calls are all library calls, there is no separate process | 08:34 |
| gtristan | jjardon, why is gnome-shell unpetrify-ref baserock/3.18.0 ? | 08:38 |
| ssam2 | probably he had to apply a patch | 08:38 |
| ssam2 | so that branch will exist in gnome-shell.git on git.baserock.org | 08:38 |
| gtristan | ok, that would explain why I dont have the commit id in upstream | 08:38 |
| *** De|ta has left #baserock | 08:39 | |
| jjardon | Yeah, to change the submodules thing | 08:40 |
| jjardon | Is there a story to fix that at some point? | 08:41 |
| gtristan | I dont know what the submodules thing is | 08:41 |
| gtristan | gnome-shell has some kind of git trigger which needs to be disabled by your patch, is it ? | 08:42 |
| *** De|ta has joined #baserock | 08:43 | |
| gtristan | http://git.baserock.org/cgi-bin/cgit.cgi/delta/gnome/gnome-shell.git/commit/?h=baserock/3.18.0&id=7d01383b8ee4919534a5df11e4f22ab43c240d4e | 08:45 |
| gtristan | sigh, /me has a bad feeling about this | 08:45 |
| *** De|ta has quit IRC | 08:47 | |
| Kinnison | why a bad feeling? | 08:47 |
| Kinnison | all that commit does is rewrite the submodule URLs to point at the trove | 08:47 |
| gtristan | The bad feeling: I may not even be able to build and test it without actually patching the upstream git.baserock.org/delta thing | 08:48 |
| gtristan | but looks like it's happily downloading from git.gnome.org and building | 08:48 |
| Kinnison | Oh yeah, you *can* run without patching .gitmodules | 08:49 |
| Kinnison | but in the future that will fail because builders won't have network access outside of the trove | 08:49 |
| Kinnison | so it's best to ensure you've patched .gitmodules before submitting for merge :_) | 08:49 |
| *** De|ta has joined #baserock | 08:49 | |
| gtristan | or | 08:50 |
| Kinnison | I believe we've had discussion about putting that rewrite into the morphologies, but we've not gotten anywhere with making that happen yet | 08:50 |
| gtristan | perhaps it's better in the .morph to patch the .gitmodules, so as to not even require a patch to gnome-shell itself | 08:50 |
| Kinnison | Currently that's not possible because the build tool sorts out the submodules | 08:51 |
| gtristan | right, think we're saying approximately the same :) | 08:51 |
| Kinnison | But yes, it'd be nice | 08:51 |
| gtristan | an inline sed, in the configure-instructions | 08:51 |
| * gtristan crosses fingers... and wants to see a GUI ! | 08:52 | |
| Kinnison | sadly configure is run well after the git submodules are acquired | 08:54 |
| Kinnison | because by then, network access is entirely removed, for reproducibility reasons | 08:54 |
| franred | I think the modules are downloaded before you run pre-configure commands (but I can be wrong) - so the sed line won't work / we need to change definitions-morph to replace the submodules by trove/other location repositories | 08:55 |
| franred | Kinnison, snap :) | 08:55 |
| *** jonathanmaw has joined #baserock | 08:57 | |
| gtristan | same result with master gnome-shell/gnome-session/mutter | 09:17 |
| gtristan | eek, something went wrong somewhere it seems... see ybd log here: http://paste.baserock.org/zixesaqeho | 09:30 |
| gtristan | one sec... | 09:31 |
| gtristan | and this is what I put for mutter in gnome.morph: http://paste.baserock.org/qoqiquloko | 09:31 |
| gtristan | now specifically at line 421 in the build log, we find: | 09:32 |
| gtristan | 15-10-08 00:01:41 [1/7/345] [mutter] Upstream version b975676c 3.18.0-25-gb975676 (3.18.0 + 25 commits) | 09:32 |
| gtristan | commit ID looks right... not sure what 3.18.0-25-gb975676 is all about... | 09:33 |
| gtristan | and in the resulting build I get the same hang here: http://fpaste.org/276279/29600414/ | 09:33 |
| gtristan | But, looking at master's sources... it really does not follow the right codepath | 09:33 |
| gtristan | it looks like ybd did rebuild mutter, but not from master | 09:33 |
| gtristan | possible ? | 09:34 |
| tiagogomes | gtristan I think it build from b975676c, which is the SHA1 that you set on the 'ref' field | 09:35 |
| gtristan | yeah, I checked my ~/.cache/ybd/gits...git_something__mutter/ ... and it does have the correct tip | 09:37 |
| gtristan | so the lorry is not out of sync (the commit in question is from only yesterday) | 09:37 |
| gtristan | only stack trace seems to disagree :-/ | 09:37 |
| gtristan | it should have passed through clutter_init() instead | 09:37 |
| paulsherwood | gtristan: fwiw the ./cache path is set to that by default by a commit from jjardon because of XDG sometihng or other | 09:38 |
| paulsherwood | iiuc you found it non-obvious? | 09:38 |
| * paulsherwood had originally opted for /src/ | 09:38 | |
| tiagogomes | gtristan which stacktrace ? Where it says " Upstream version b975676c 3.18.0-25-gb975676 (3.18.0 + 25 commits)" ? | 09:39 |
| gtristan | tiagogomes, http://fpaste.org/276279/29600414/ | 09:39 |
| gtristan | paulsherwood, ummm, now I *really* dont follow... | 09:40 |
| paulsherwood | gtristan: 3.18.0-25-gb975676 is a combination of last tag (3.18.0-25) and commit id (b975676) returned by asking git | 09:40 |
| gtristan | paulsherwood, the .morph had unpetrify-ref 3.18.0... but I changed the morph to 'master' | 09:40 |
| gtristan | ok... | 09:41 |
| paulsherwood | gtristan: https://github.com/devcurmudgeon/ybd/blob/master/ybd/app.py#L31 (for the directory thing) | 09:41 |
| paulsherwood | gtristan: ybd completely ignores unpetrify ref | 09:41 |
| SotK | gtristan: unpetrify-ref doesn't actually do anything, morph and ybd use the `ref` field to decide what to build | 09:41 |
| gtristan | paulsherwood, so basically you are saying the line "Upstream version b975676c 3.18.0-25-gb975676 (3.18.0 + 25 commits)" is telling me... first the new version 'b97...' _and_ the version it was currently at '3.18.0-...' ? | 09:42 |
| gtristan | anyway, what I am observing is that, in mutter master (b975676c)... core/main.c:358 calls meta_clutter_init()... but this is not reflected in the stack trace | 09:47 |
| gtristan | which is collected from the fresh build | 09:47 |
| gtristan | well | 09:47 |
| gtristan | let me clean up and try to deploy that again | 09:47 |
| gtristan | in this kind of scenario, it can always be a slip somewhere on my part | 09:48 |
| gtristan | is there any way to get rid of all of the outdated caches in ~/.cache/ybd/artifacts ? | 09:48 |
| * gtristan is quickly running out of harddrive | 09:48 | |
| paulsherwood | gtristan: sadly not yet. i tend to remove all of them at once. patches welcome, but i'm aiming to get to it over the next week or so | 09:50 |
| gtristan | well, mutter is not rebuilding | 09:51 |
| paulsherwood | gtristan: it's saying that the actual commit is b975676, which is 25 commits applied on top of tag 3.18.0 | 09:51 |
| * gtristan tries some ldd-foo in the latest artifact directory | 09:51 | |
| gtristan | see if I can find at least the new meta_clutter_init() symbol | 09:51 |
| gtristan | paulsherwood, right, that's what I wonder about... why does it care about 3.18.0 or tell me anything about how far ahead it is from 3.18.0 ? | 09:52 |
| gtristan | the morph only says b975676 :) | 09:52 |
| pedroalvarez | gtristan: just free human readable information | 09:52 |
| richard_maw | gtristan: it thinks the user might be interested | 09:52 |
| gtristan | ok but... why did it choose to say anything about 3.18.0... where is that coming from ? | 09:53 |
| richard_maw | gtristan: git tag | 09:53 |
| Kinnison | git describe | 09:53 |
| richard_maw | yes, that one | 09:53 |
| gtristan | is it the place where it currently was ? | 09:53 |
| richard_maw | yep | 09:53 |
| gtristan | ok, that's what I was curious about | 09:53 |
| gtristan | ot wants me to know... from where to where it went in the history | 09:53 |
| gtristan | s/ot/it | 09:53 |
| paulsherwood | gtristan: because some use-cases make people interested in that | 09:54 |
| paulsherwood | eg, if i have to complete a compliance matrix and folks want to know which 'version' of Linux kernel is present in my build... quoting a SHA is not very helpful | 09:55 |
| paulsherwood | conversely... claiming 3.18 is dishonest, if there are patches applied to it | 09:55 |
| gtristan | right, it only threw me off | 09:56 |
| gtristan | as I am seeing the incorrect stack trace | 09:56 |
| paulsherwood | (eg i could go 3.18 and apply patches to revert loads of stuff to take the actual version back to 3.17) | 09:56 |
| gtristan | which doesnt coincide with the version | 09:56 |
| paulsherwood | gtristan: intersesting. i'm normally highly confident that ybd is actually building the version it says it's building.... are you suggesting it may not be? | 09:57 |
| *** fay__ has joined #baserock | 09:57 | |
| gtristan | it may be more helpful btw to say: Building new version "<newversion>" (Previous build "<oldversion>") | 09:57 |
| gtristan | instead of: Upstream version: <newversion> <oldversion> | 09:58 |
| gtristan | paulsherwood, yes I am suggesting that, but I'm re-assembling the image | 09:58 |
| gtristan | it looks like, possibly the correct version was built but wrong artifact included ? | 09:59 |
| paulsherwood | gtristan: sorry... that's not what it's saying. it's describing one version in two different ways | 09:59 |
| gtristan | paulsherwood, so then the question arises again, where is 3.18.0-25-gb975676 coming from ? | 10:00 |
| gtristan | I mean, why 3.18.0-25 ? | 10:00 |
| paulsherwood | git | 10:00 |
| paulsherwood | 3.18.0 + 25 packages | 10:00 |
| paulsherwood | s/packages/commits/ | 10:00 |
| paulsherwood | 3.18.0 + 25 commits | 10:01 |
| gtristan | aha | 10:01 |
| paulsherwood | b975676 *is* 3.18.0 + 25 commits | 10:01 |
| * gtristan runs git describe in mutter master | 10:01 | |
| gtristan | right, what I was thrown off by, is why git (or ybd), would choose to describe the version in relation to 3.18.0 | 10:02 |
| gtristan | I suspect, it may just be the most recent tag created in that repo ? | 10:02 |
| gtristan | (when I say why 3.18.0-25, I wondered why not 3.16-466 or whatever) | 10:03 |
| *** fay__ has quit IRC | 10:04 | |
| paulsherwood | gtristan: yes, most recent tag, since i think that is most useful for answering human question 'which version of foo are we using' | 10:04 |
| *** fay__ has joined #baserock | 10:06 | |
| gtristan | I see, it seemed quite arbitrary, and as I've never seen a version described in that way - I was worried it could be the reason the image did not end up with the right mutter lib | 10:06 |
| * gtristan has a new image | 10:07 | |
| paulsherwood | gtristan: i've never seen a version described this way either, but i strongly believe that describing it this way is better than any other description i've seen | 10:08 |
| paulsherwood | :) | 10:08 |
| gtristan | 0000000000046620 T meta_clutter_init | 10:09 |
| gtristan | well, that's in the image | 10:09 |
| gtristan | unfortunately I did not keep the old one... disk space :-/ | 10:09 |
| gtristan | gah, but here we are at the same stack trace | 10:12 |
| gtristan | oddly, the code paths have changed from one version to the other, but they land on an almost identical call stack | 10:13 |
| gtristan | (and meta_clutter_init() is simply omitted from the trace by gdb) | 10:13 |
| gtristan | so, all is well in ybd land, I'm due to clean out the artifacts and rebuild all | 10:14 |
| gtristan | and still don't have a solution for hang in XIGrabTouchBegin | 10:14 |
| gtristan | at this point, a checked out sandbox of mutter/gnome-shell would be useful... | 10:15 |
| gtristan | and a ybd 'buildone' command would be useful | 10:15 |
| * SotK wonders what buildone would do | 10:15 | |
| gtristan | just build one artifact and update the image directly... ignoring modules which depend on that | 10:15 |
| gtristan | 'use at your own risk, get it done now' | 10:16 |
| gtristan | alternative... scp source trees into the VM, and build mutter/gnome-shell directly there, with make install directly into /usr | 10:16 |
| *** fay__ has quit IRC | 10:18 | |
| *** persia has quit IRC | 10:26 | |
| *** persia has joined #baserock | 10:27 | |
| gtristan | nod, fwiw, here are 2 *almost* identical stack traces: http://fpaste.org/276233/44286049/ (old mutter) http://fpaste.org/276279/29600414/ (new mutter) | 10:30 |
| gtristan | that's what led me to panic, and presume I did not pick up the change | 10:31 |
| gtristan | well, I've taken 2 approaches: bottom up - address as many errors as possible in the systemd journal | 10:42 |
| gtristan | a lot of things fixed in that direction | 10:42 |
| gtristan | and: top-down; checking the stack traces where gnome-session/gnome-shell hang | 10:43 |
| paulsherwood | gtristan: you can specify mutter (say) as your target, and it will rebuild that artifact | 10:44 |
| gtristan | this allowed me to A.) identify that we needed to enable glx for gnome-session to detect HW acceleration | 10:44 |
| paulsherwood | then 'deploy' would be a matter of untarring the result in the right place | 10:44 |
| gtristan | and B.) Identify a hang | 10:44 |
| paulsherwood | gtristan: to get to a checked out sandbox you could put 'exit 1' as a configure-command? | 10:46 |
| paulsherwood | and then ybd will stop and give you the directory for the debris - which is what you want? | 10:47 |
| gtristan | I was thinking I would have to point the morph to a file:// checkout, but that could work | 10:47 |
| gtristan | what I want, is to build and deploy dozens of times in a row, with as least steps getting in the way | 10:48 |
| * paulsherwood hopes it does :) | 10:48 | |
| richard_maw | you can use file:// paths for git repositories in morph and ybd | 10:48 |
| richard_maw | you need to remember to commit your changes before building though | 10:48 |
| paulsherwood | gtristan: deploy into what kind of target? a vm? | 10:49 |
| gtristan | richard_maw, this would mean in any case, that I have to A.) Commit a change to get it included... B.) Build the artifact... C.) scp the artifact to the vm and D.) untar the artifact on that VM... *for every single deployment* ;-) | 10:49 |
| gtristan | yeah in a VM | 10:49 |
| gtristan | probably I'm better off just scp the sources and ./configure, make, install in there | 10:50 |
| paulsherwood | sadly, i fear you're right at this point | 10:50 |
| gtristan | but then, I may not need this right now - but it's certainly what I want | 10:50 |
| * paulsherwood notes the use-case | 10:50 | |
| gtristan | paulsherwood, you're on CC in an email where I asked this | 10:51 |
| gtristan | basically, "what is the dev story for when I need to add some debug log, and deploy at least 10 time in the space of one hour" | 10:51 |
| gtristan | right now the sensible thing for me to ask myself though, is why... certainly I am getting this hang and others are not | 10:52 |
| persia | I think I don't understand the use-case. | 10:53 |
| persia | When doing rapid development, do we really want to deploy whole systems to see if the last 4-character change happened, or just havea means to test the code, with formal system validation as a separate step? | 10:53 |
| gtristan | persia, some past scenarios I've dealt with is... We maintain a build server with the target architecture but much more CPU/ram; developers build on that host and scp the binaries to a target system for testing | 10:56 |
| gtristan | persia, another scenario is say, with buildroot, you painfully reproduce the entire image each time | 10:56 |
| gtristan | it's interesting that the image I have which runs in a VM happens to have all the dev tooling on it, though, at least it does allow me to build in the VM | 10:58 |
| persia | Hrm. I think that workflow can be improved, but I think I need to think more :) | 11:01 |
| paulsherwood | gtristan: i believe that radiofree normally does his fast loops directly on the target | 11:02 |
| paulsherwood | and that's probably what i'd recommend here | 11:02 |
| paulsherwood | if it's feasible for you | 11:02 |
| gtristan | paulsherwood, sometimes making noise on IRC is the fastest route... chances are someone else has seen the problem | 11:03 |
| gtristan | http://paste.baserock.org/erabepupef :) | 11:03 |
| * gtristan breaths sigh of relief | 11:03 | |
| gtristan | and decides it's time he can eat supper | 11:03 |
| paulsherwood | gtristan: :-) | 11:03 |
| *** gtristan has quit IRC | 11:28 | |
| *** zoli__ has joined #baserock | 11:55 | |
| *** gtristan has joined #baserock | 12:18 | |
| perryl | i'm trying to deploy a trove and getting the following issue in the process, can anyone help with what's going wrong? 'ERROR: The ssh-rsync write is for upgrading existing remote Baserock machines. It cannot be used for an initial deployment.' | 13:00 |
| richard_maw | perryl: what's in your cluster file? | 13:00 |
| richard_maw | it sounds like you're using the upgrade cluster rather than the initial deployment one | 13:01 |
| perryl | richard_maw: clusters/trove-example, the description says it can be used for initial deployment and upgrade | 13:02 |
| perryl | yep, forgot to remove the upgrade lines | 13:02 |
| *** wschaller has joined #baserock | 13:11 | |
| *** CTtpollard has joined #baserock | 13:12 | |
| *** zoli__ has quit IRC | 13:16 | |
| *** flatmush has joined #baserock | 13:31 | |
| *** fay_ has joined #baserock | 13:34 | |
| *** franred has quit IRC | 14:21 | |
| richard_maw | toscalix__: you had questions about the publish candidate step of http://ciat.baserock.org/#/ ? | 14:47 |
| toscalix__ | richard_maw: I have a note from a meeting in which it was mentioned a notification system once the candidate is published | 14:48 |
| SotK | any chance someone can put my ssh key on storyboard.baserock.org for me to have a look around? :) | 14:49 |
| toscalix__ | I am unsure if you have had it in mind or is something I need to write down in the wiki page | 14:49 |
| richard_maw | toscalix: I can't parse that, are you asking if there is one, whether we have ideas for one, or what? | 14:49 |
| richard_maw | currently it is a stub | 14:50 |
| richard_maw | eventually we need it to produce a report, which includes things like the test results, where the artifacts that were produced can be reached, and how to fetch and apply the candidate | 14:51 |
| pedroalvarez | SotK: has anybody looked at that? | 15:05 |
| ssam2 | SotK: yes | 15:05 |
| ssam2 | pedroalvarez: I haven't touched storyboard.baserock.org myself | 15:05 |
| ssam2 | recently | 15:05 |
| pedroalvarez | neither have I | 15:06 |
| pedroalvarez | is there anything that needs attention? or is just SotK wanting to look around to (some day) automate the process of deploying it :) | 15:06 |
| SotK | the latter, and also maybe looking at updating it in place to something more recent for the time being | 15:07 |
| *** wschaller has quit IRC | 15:14 | |
| *** paulwaters_ has joined #baserock | 15:16 | |
| ssam2 | SotK: done. don't break it! | 15:17 |
| SotK | I won't :) | 15:17 |
| SotK | thanks! | 15:17 |
| *** paulw has quit IRC | 15:18 | |
| * SotK wonders if there is a snapshot of storyboard.openstack.org lying around anywhere | 15:30 | |
| toscalix__ | richard_maw: sorry, got a phone call. Got you point. I will include report and notification. At least it will be recorded that we need to havethem in consideration | 15:32 |
| *** wschaller has joined #baserock | 15:36 | |
| ssam2 | SotK: there's one on the datacentred openstack.. | 15:37 |
| ssam2 | which I took a while ago | 15:38 |
| ssam2 | maybe pedroalvarez could fetch it for you | 15:38 |
| * SotK hopes he can :) | 15:38 | |
| Zara | ssam2: ahhh, that's where it went! (we were wondering about where that was a while ago. looked in emails and nothing. meant to ask and forgot about it.) | 15:39 |
| Zara | I'm glad there is one :) | 15:39 |
| ssam2 | it took *hours* to make, so I hope it's useful :) | 15:39 |
| ssam2 | i could download it for you but i'm in Germany so it is probably quicker if pedro (or anyone else with access to DC) downloads it straight to the office | 15:40 |
| ssam2 | rather than me trying to upload it to a CT server from here... | 15:40 |
| Zara | ssam2: I'm sorry about that, I think the development on worklists and boards work got pushed hard and the baserock side of things fell by the wayside. :( and I agree it doesn't make sense for you to do it from Germany. | 15:43 |
| Zara | pedroalvarez: would you be able to help us with this? | 15:44 |
| rjek | w/win 49 | 15:46 |
| rjek | x | 15:46 |
| perryl | the latest in my trove deployment woes: deploy gets as far as create_libvirt_guest in extensions/kvm.write then exits with the error 'ERROR: extensions/kvm.write failed with code 1: /src/tmp/deployments/tmpFseHYq/tmpTfhhsE/tmpvK5IIo is device /dev/loop0 | 15:51 |
| ssam2 | ouch, bug in kvm.write I guess. no idea what | 15:53 |
| ssam2 | if you don't have time to dig into kvm.write, you could deploy to rawdisk instead and set up the VM manually, as a workaround | 15:54 |
| pedroalvarez | ssam2, Zara: sure!! | 15:54 |
| perryl | ssam2: that might be an option at this stage :/ i was thinking of writing a patch for kvm.write to make it a bit more explanatory of what's going on at some point, for that matter | 15:55 |
| Zara | pedroalvarez: thanks :) | 15:57 |
| pedroalvarez | wow, 40G of snapshot | 15:57 |
| ssam2 | perryl: that would be cool! | 16:05 |
| Zara | o.O sounds like one exciting snapshot! | 16:06 |
| ssam2 | pedroalvarez: that's why it took hours! | 16:07 |
| *** ssam2 has quit IRC | 16:08 | |
| toscalix__ | I would appreciate a review of the CIAT next steps> http://wiki.baserock.org/ciat/?updated#index4h2 | 16:28 |
| rjek | toscalix__: analised does not mean what you think it means. | 16:29 |
| rjek | toscalix__: I think you mean "analysed" | 16:29 |
| toscalix__ | rjek: you are right | 16:29 |
| rjek | Well, you might mean what analised means, but that would surprise me. | 16:30 |
| toscalix__ | editing | 16:30 |
| *** toscalix__ is now known as toscalix | 16:30 | |
| SotK | can you make the repo urls git:// rather than ssh:// too please? | 16:32 |
| *** paulwaters_ has quit IRC | 16:32 | |
| toscalix | SotK: yep | 16:35 |
| *** mariaderidder has quit IRC | 16:48 | |
| *** tiagogomes has quit IRC | 16:52 | |
| *** De|ta has quit IRC | 16:56 | |
| *** bashrc has quit IRC | 17:00 | |
| *** De|ta has joined #baserock | 17:09 | |
| *** wschaller has quit IRC | 17:12 | |
| *** jonathanmaw has quit IRC | 17:22 | |
| *** edcragg has quit IRC | 17:43 | |
| *** paulwaters_ has joined #baserock | 17:43 | |
| *** zoli_ has joined #baserock | 17:51 | |
| *** paulwaters_ has quit IRC | 18:03 | |
| *** zoli_ has quit IRC | 18:51 | |
| *** paulwaters_ has joined #baserock | 19:47 | |
| *** paulwaters_ has quit IRC | 20:03 | |
| *** tiagogomes has joined #baserock | 20:32 | |
| *** zoli_ has joined #baserock | 20:39 | |
| *** zoli_ has quit IRC | 20:44 | |
| *** tiagogomes has quit IRC | 21:10 | |
| *** zoli_ has joined #baserock | 21:41 | |
| *** zoli_ has quit IRC | 21:46 | |
| *** fay_ has quit IRC | 21:57 | |
| *** flatmush has quit IRC | 21:57 | |
| *** edcragg has joined #baserock | 22:01 | |
| *** tiagogomes has joined #baserock | 22:03 | |
| *** tiagogomes has quit IRC | 23:04 | |
| *** zoli_ has joined #baserock | 23:27 | |
| *** zoli_ has quit IRC | 23:31 | |
| *** edcragg has quit IRC | 23:35 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!