*** Walkerdine has joined #baserock | 01:17 | |
*** gtristan has quit IRC | 02:45 | |
*** gtristan has joined #baserock | 03:16 | |
*** zoli__ has joined #baserock | 03:24 | |
*** zoli__ has quit IRC | 03:50 | |
gtristan | Ok this ybd warning message is just killing me: WARNING: rogue builds in a chroot sandbox may overwrite your system | 03:54 |
---|---|---|
gtristan | following the rabbit hole... turns out it's when ybd encounters a sandboxlib using traditional chroot where linux-user-chroot is not found | 03:55 |
* gtristan wonders... it 'may' overwrite my system... yet it's not an error and doesnt halt the build... you just hit CNTL-C repeatedly after that... hoping no damage was done | 03:56 | |
gtristan | hmmm, well, it's looking good | 04:10 |
gtristan | so, building with ybd, stage2-make fails to find gmp.h while compiling guile.c... causing subsequent builds to fail to find make | 04:51 |
gtristan | sound familiar ? | 04:52 |
gtristan | richard_maw, I suspect reverting caf277de258967d361f07d636fa6805652462a9f will fix this... | 04:53 |
gtristan | hmmm, this is from 2012... looks like I'm the only one left who never updated their base system since then | 05:03 |
gtristan | anyway, excuse random remarks... trying to get through my first ybd build, with an old ubuntu (12.04) install | 05:04 |
* gtristan thinks it should still work though... | 05:05 | |
* gtristan wipes slate clean... installs baserock build system image in kvm... if ybd builds anywhere, it will build in that vm | 06:15 | |
*** zoli__ has joined #baserock | 06:51 | |
*** paulwaters_ has joined #baserock | 06:54 | |
*** zoli__ has quit IRC | 06:55 | |
*** gtristan has quit IRC | 07:01 | |
*** fay_ has joined #baserock | 07:12 | |
*** Walkerdine has quit IRC | 07:33 | |
paulsherwood | i guess i need to fix that 'rogue builds' message. any rogue software could overwrite someone's system, but we don't say it all the time | 07:34 |
*** gtristan has joined #baserock | 07:43 | |
gtristan | paulsherwood, hi... just got back from a late lunch and reading your comments now... | 07:55 |
paulsherwood | gtristan: hi! | 07:55 |
paulsherwood | basically i'm just surprised how broken things seemed to be when you tried | 07:56 |
paulsherwood | i've fixed the warning message... | 07:56 |
gtristan | yeah, I have been extremely lazy about upgrading my own laptop, I avoid that normally but should upgrade | 07:56 |
paulsherwood | https://github.com/devcurmudgeon/ybd/blob/master/ybd/__main__.py#L51 | 07:56 |
gtristan | note, I cannot install linux-user-chroot here, tried building it manually... fails building on an outdated (unversioned!?) seccomp library | 07:58 |
paulsherwood | aha | 07:58 |
paulsherwood | gtristan: ok, well for getting started, chroot should be fine. that's my default setup anyway | 07:58 |
gtristan | I have master of both baserock definitions and ybd | 07:58 |
*** tiagogomes_ has joined #baserock | 07:59 | |
paulsherwood | ok. i may have broken some thingds over the last week in ybd... safest would be 15.39 | 07:59 |
gtristan | one thing is... I ran initially as not root (maybe causes permissions issues ?)... and then re-ran it as sudo | 07:59 |
gtristan | and... once stage2-make failed to build, the build 'completed' mysteriously with no output... it would seem ybd also leaves the tree in a tagged state and doesnt try to rebuild failed builds | 08:00 |
gtristan | so not sure if I need to remove that cache | 08:01 |
paulsherwood | gtristan: i think that's a bug. almost certainly introduced since 15.39 | 08:01 |
gtristan | aha | 08:01 |
gtristan | ok, well, I should try that tag | 08:01 |
paulsherwood | i suggest you clear the cache, reset ybd to 15.39. sorry for the confusion | 08:01 |
paulsherwood | i was hoping to tidy some stuff over the weekend but injured myself instead | 08:02 |
gtristan | honestly, I ran the baserock vm thinking it would be a good reference, but then got stumped with trying to sort out it's internet connection (playing with routing tables, nats and stuff... is /really/ my weak point) | 08:02 |
paulsherwood | mine too. :) | 08:02 |
gtristan | heh | 08:02 |
gtristan | it's all gibberish, goes in one ear and out the other | 08:02 |
paulsherwood | lol | 08:02 |
gtristan | so, I was about to resort to using a virtualbox of a recent ubuntu distro and trying there | 08:03 |
gtristan | I think I may try both in parallel | 08:03 |
gtristan | paulsherwood, did you see the commit from 2012 ? | 08:03 |
paulsherwood | i saw what you wrote, but didn't understand the meaning | 08:04 |
gtristan | I find it suspicious, as gmp was listed 'directly' before make in the old bootstrap json file | 08:05 |
gtristan | the commit removes it, stating it was only a dependency for gcc | 08:05 |
pedroalvarez | but that is really really old | 08:05 |
gtristan | and so is my OS ;-) | 08:05 |
gtristan | heh | 08:05 |
paulsherwood | aha | 08:05 |
pedroalvarez | heh :) | 08:05 |
gtristan | should not be any correlation I think, as it's all from source | 08:05 |
gtristan | just suspicious | 08:05 |
paulsherwood | well, if you could try again with clean cache and 15.39, i hope all will be hunky dory | 08:05 |
gtristan | I will try both | 08:06 |
radiofree | Maybe you should upgrade your distro | 08:06 |
gtristan | radiofree, yeah, been saying that about 3 times now ;-) | 08:06 |
gtristan | guess every 2 years it's about time | 08:07 |
*** jonathanmaw has joined #baserock | 08:09 | |
gtristan | paulsherwood, just to double-check, is it important to *be root*, or is 'sudo ybd.py...' sufficient ? | 08:09 |
tiagogomes_ | IIRC you need to change the network adapter virtual driver on VBox for having Internet on Baserock | 08:10 |
*** mariaderidder has joined #baserock | 08:17 | |
wdutch | I think that CIAT pipeline config should look something like this http://paste.baserock.org/tifatakere , firehose config would exist separately | 08:19 |
Kinnison | Where would the slave configs come from? | 08:20 |
gtristan | so, is there a nifty way to 'parent' a baserock environment to another ? perhaps avoiding the trip to git.baserock.org/delta ? | 08:20 |
Kinnison | gtristan: not trivially, though you *should* be able to transfer the git cache from one system to another, and there are ways to transfer artifacts around too | 08:20 |
Kinnison | gtristan: everything is kinda oriented (for now) around the idea that you'd have a local git service anyway | 08:21 |
gtristan | nod | 08:21 |
Kinnison | gtristan: the git server (trove) is designed to parent to another, to build a tree | 08:21 |
wdutch | Kinnison: I guess they would have to exist before that is processed. I don't think slaves should be defined in conjunction with the pipelines | 08:21 |
Kinnison | wdutch: I'm happy for it to be nearby, but it's important to consider all the inputs at once | 08:21 |
wdutch | okay | 08:21 |
Kinnison | wdutch: Also I'm leery of the pipelines specifying the build slaves | 08:21 |
Kinnison | wdutch: I'd rather they didn't | 08:21 |
Kinnison | wdutch: otherwise elasticity becomes a pain | 08:22 |
*** paulwaters_ has quit IRC | 08:22 | |
wdutch | so just speicify architecture? It might get a bit tricky when flavours and things get involved | 08:22 |
Kinnison | flavours? | 08:23 |
* wdutch was thinking of openstack | 08:23 | |
Kinnison | I think builders are builders | 08:23 |
wdutch | pardon? | 08:24 |
Kinnison | the important thing here is that we don't want to have to rewrite configurations to spawn more build slaves | 08:24 |
Kinnison | I'm fine if we specify a kind of build slave appropriate in the config, but it should be exactly that -- a kind | 08:24 |
wdutch | okay | 08:24 |
*** paulwaters_ has joined #baserock | 08:24 | |
wdutch | we shall call it slavour: slave flavour | 08:25 |
* Kinnison isn't trying to make your life difficult, just trying to ensure that you don't make our future lives difficult | 08:25 | |
wdutch | I think it's a valid point | 08:25 |
* wdutch wonders what the collective noun for slaves is | 08:26 | |
wdutch | a coffle it seems | 08:26 |
wdutch | that's a bit obscure | 08:26 |
pedroalvarez | we could call them "workers" | 08:31 |
wdutch | that doesn't really abstract away the notion though | 08:32 |
pedroalvarez | I'm trying to figure out, how to get, for a given firehose change, the build number of the integration, build, deploy, and testing steps | 08:33 |
pedroalvarez | s/steps/columns/ | 08:34 |
wdutch | one could track the sha of the candidate ref of definitions | 08:34 |
pedroalvarez | that's what I was thinking. It is possible to add steps that run in the master | 08:35 |
wdutch | you'd have to add it to bottlerock, buildbot master doesn't execute code unless reconfigured | 08:35 |
pedroalvarez | hm.. I haven't looked at bottlerock yet | 08:35 |
wdutch | it's just python and bottle to expose buildbot to the webz | 08:36 |
pedroalvarez | My current idea was to add an extra step in buildbot, that writes the info I need in a DB/file on the master | 08:37 |
pedroalvarez | (sha, column, buildnumber) | 08:37 |
wdutch | sounds sensible | 08:39 |
wdutch | I should probably store the clusters and their dependencies in the database | 08:39 |
wdutch | I'll have to learn to use sqlachemy | 08:39 |
*** toscalix__ has joined #baserock | 08:40 | |
pedroalvarez | once I have the relation of sha1 -> buildnumber, we can do whatever we want with the UI | 08:40 |
wdutch | muahahhaa | 08:41 |
*** mariaderidder has quit IRC | 08:46 | |
*** mariaderidder has joined #baserock | 08:46 | |
*** rdale has joined #baserock | 08:47 | |
*** franred has joined #baserock | 09:00 | |
*** ssam2 has joined #baserock | 09:03 | |
*** ChanServ sets mode: +v ssam2 | 09:03 | |
paulsherwood | gtristan: i don't know the answer to that, sorry. anyone? do we need to be root for ybd/sandboxlib/morph, or is sudo sufficient? | 09:07 |
Kinnison | In general I'd recommend sudo -H $app | 09:08 |
Kinnison | otherwise you get root-owned stuff in your ~ | 09:08 |
gtristan | alright, no problem | 09:09 |
gtristan | paulsherwood, I take it you generally become root | 09:10 |
paulsherwood | yup | 09:10 |
paulsherwood | well, actually i normally sudo -i, and then run ybd | 09:10 |
paulsherwood | (having had Kinnison explain to me what sudi -i is) | 09:10 |
gtristan | I doubt it will make a difference to the build | 09:11 |
ssam2 | the 'root' requirement is discussed a bit here: https://github.com/devcurmudgeon/ybd/issues/24 | 09:11 |
pedroalvarez | wdutch: I guess the best way to fiddle with orch_config.py is to create my own instance, not touching ciat.baserock.org's one | 09:40 |
wdutch | pedroalvarez: yes tis probably for the best, I'm hoping to get rid of that file at some point though | 09:41 |
wdutch | moving things like urls and name to yaml and python to a separate module ciatlib which is in trove | 09:42 |
paulsherwood | seems like no builds have happened today... is upstream havign a day off? | 10:16 |
paulsherwood | (ciat.baserock.org) | 10:17 |
pedroalvarez | hm.. | 10:18 |
pedroalvarez | nothing since Mon 28 Sep 2015 17:13:26 | 10:18 |
Kinnison | anything in the bottlerock logs? | 10:19 |
* paulsherwood has deja vu again | 10:21 | |
* richard_maw doesn't see any recent systemd changes, but we should be seeing firehose changes | 10:22 | |
rjek | again? is that déjà déjà vu vu? | 10:23 |
richard_maw | last thing in the bottlerock logs too, it's running but hasn't seen any triggers | 10:24 |
Kinnison | there's definitely changes hitting cu010-trove in the past few hours | 10:24 |
richard_maw | wdutch: what did you do to change the url from 0.0.0.0? | 10:24 |
richard_maw | since that happened roughly at the time when it stopped sending changes | 10:25 |
wdutch | changed orchenv-master/master/master.cfg line 123 | 10:26 |
richard_maw | hm, unlikely to be the cause | 10:27 |
* richard_maw checks netstat to see if bottlerock.py is even listening | 10:28 | |
richard_maw | definitely thinks it's listening on 0.0.0.0:8080 | 10:31 |
Kinnison | richard_maw: I'm trying a curl from the trove | 10:31 |
Kinnison | it's not responding | 10:31 |
Kinnison | afaict | 10:31 |
Kinnison | The connect is timing out | 10:32 |
Kinnison | which is fun | 10:32 |
* Kinnison tries some tcpdumping | 10:32 | |
Kinnison | Okay that time it connected but the post is blocking | 10:33 |
Kinnison | interesting | 10:33 |
richard_maw | it's blocking in recvfrom, but there's 2 sockets open | 10:34 |
Kinnison | mmm | 10:34 |
richard_maw | I'll double check, but it looks like while it's got the right socket open, it's blocking on the wrong one | 10:34 |
Kinnison | single-threaded bottle | 10:34 |
Kinnison | someone opened a connection | 10:34 |
Kinnison | We've seen this kind of cockup before we switched the morph artifact cache | 10:35 |
Kinnison | to a proper web frontend | 10:35 |
*** brlogger` has joined #baserock | 10:37 | |
*** brlogger has quit IRC | 10:38 | |
richard_maw | looks like it's blocking on a connection from 80.35.3.156 | 10:39 |
Kinnison | kill it and restart it | 10:39 |
Kinnison | so it at least gets on with things | 10:39 |
richard_maw | restarted it, let's see what happens | 10:42 |
* richard_maw wonders what the IP address of the arm build slave is | 10:42 | |
* richard_maw finds http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/VMImportPrerequisites.html and is amused by the quaint list of supported operating systems for import | 10:47 | |
richard_maw | it looks like Amazon has eaten its old tooling, which trusted you to do the right thing | 10:48 |
wdutch | toscalix__: I'm here | 10:49 |
richard_maw | unfortunately there appears to have been enough churn in the tooling that a lot of old guides no longer work | 10:49 |
toscalix__ | wdutch: sorry | 10:49 |
wdutch | :) | 10:49 |
toscalix__ | wdutch: thanks for the paragraph for the wiki | 10:49 |
richard_maw | "Make sure that you have at least 250 MB of available disk space for installing drivers and other software on any VM you want to import into an Amazon EC2 AMI running Microsoft Windows or Linux." O_O | 10:50 |
richard_maw | it looks like as part of the import process they install packages | 10:50 |
pedroalvarez | lovely | 10:51 |
richard_maw | so unless the old ec2-bundle-image tooling still works, it may not currently be possible to import a Linux VM that isn't a Debian or RHEL derivative | 10:53 |
ssam2 | we could hack something useful that pretends to be 'rpm', perhaps. Pretty ugly though | 11:07 |
paulsherwood | richard_maw, Kinnison - did you see my comments yesterday about not setting instances: 5 on a single arm builder? | 11:11 |
paulsherwood | it's causing a herd of 5, each with max-jobs: 1 | 11:12 |
*** franred has quit IRC | 11:53 | |
*** gtristan has quit IRC | 12:13 | |
*** paulwaters_ has quit IRC | 12:18 | |
* richard_maw had not seen that comment | 12:25 | |
paulsherwood | best for a moonshot cartridge is just default. instances will be automatically 1, max-jobs automatically 8 | 12:26 |
* paulsherwood *thinks* it's best, at least | 12:26 | |
* Kinnison imagines 2 with 4 will be better for most situations | 12:27 | |
paulsherwood | easy to try - just set instances: 2 | 12:29 |
richard_maw | so number of builders to try is number of cores / 4 rounded down? | 12:29 |
paulsherwood | i was assuming we'd have mulyiple cartridges in working at once | 12:29 |
paulsherwood | https://github.com/devcurmudgeon/ybd/blob/master/ybd/app.py#L131 | 12:30 |
* richard_maw is looking for a metric for splitting up a single node | 12:30 | |
paulsherwood | based on my testing of full builds, i believe one instance is faster for full builds unless the node has significantly more than 10 cores | 12:31 |
paulsherwood | but i'm interpolating and extrapolating. mileage may vary based on actual loads | 12:32 |
* richard_maw is just thinking that 8 cores is a more common configuration than 10, and 8 cores sounds meaty enough to handle two parallel builds. | 12:33 | |
paulsherwood | given most of our builds at this point will be systemd, we could test easily over a few iterations? | 12:33 |
paulsherwood | yes it can handle the parallel builds, but the compiles will take twice as long? | 12:34 |
paulsherwood | it's easy to try this, though :) | 12:34 |
*** paulwaters_ has joined #baserock | 12:35 | |
richard_maw | paulsherwood: it's a difficult metric to guess for, you need to know the average parallelism of each of the chunks to make reliable estimates, which entirely depends on how the chunk is configured | 12:36 |
paulsherwood | to be clear i established in my testing it's definitely better to have parallel instances on the big AWS machines, becuase max-jobs > 10 seems like a waste of time. i didn't look deeply at the performance on these 8 core machines so far | 12:36 |
paulsherwood | richard_maw: yup. but we can know after a few runs | 12:36 |
richard_maw | tbh, I think having multiple builds going on at once is better, partly just to test that it's handling multiple builds better, and to keep it looking busy | 12:38 |
paulsherwood | :-) | 12:38 |
* richard_maw puts banging his head against AWS on hold to see what he can do to make parallelism on ARM better | 12:39 | |
*** gtristan has joined #baserock | 12:55 | |
*** rdale has quit IRC | 13:05 | |
*** rdale has joined #baserock | 13:12 | |
richard_maw | there, should get 2 builders on ARM with max-jobs 4, rather than 5 with max-jobs 1 | 13:21 |
* richard_maw tries to work out whether he can find the old version of the AWS tools that try to be less helpful, hence are more useful when you're doing something they don't expect. | 13:25 | |
Kinnison | do the eucalyptus tools work with ec2 ? | 13:29 |
richard_maw | don't know | 13:29 |
* richard_maw has another thing to research | 13:29 | |
richard_maw | it says they at least did | 13:30 |
richard_maw | hm, possibly not, given it said the AWS APIs were built on top of Eucalyptus, so potentially their own tooling uses their own APIs instead | 13:31 |
richard_maw | ooh, euca2ools is python | 13:32 |
richard_maw | o_O that's a lot of binaries installed | 13:33 |
richard_maw | 200 odd | 13:34 |
richard_maw | but it does appear to have equivalent tools that I need | 13:36 |
*** rdale has quit IRC | 13:38 | |
Kinnison | richard_maw: also http://www.daemonology.net/blog/2014-02-16-FreeBSD-EC2-build.html might be of use | 13:39 |
Kinnison | richard_maw: esp. given it's for FreeBSD which definitely isn't ubuntu or redhat | 13:39 |
richard_maw | Kinnison: no… but at least initially it was bootstrapped by taking a Windows instance and installing FreeBSD on its disk and snapshotting that. I'm trying to work out whether subsequent builds work by taking a FreeBSD image and doing the same dance, or whether he's just building in the cloud out of convenience. | 13:47 |
Kinnison | I think he said that it's no longer necessary, the Windows bit was only to get HVM back when it wasn't the standard option | 13:49 |
Kinnison | Unless I misread it | 13:49 |
richard_maw | oh he's saying that's no longer necessary to be able to register images, but AFAICT he's still producing the images by taking an existing image and trashing the disk with a new install | 13:50 |
richard_maw | bundle/import is apparently a separate step to registration | 13:50 |
Kinnison | hmm | 13:51 |
*** ssam2 has quit IRC | 13:53 | |
richard_maw | hm, he's building his systems in the cloud by spawning a VM with extra volumes attached and snapshotting those volumes, then registering those volumes in images | 13:59 |
* paulsherwood tried something similar at scaleway | 14:00 | |
paulsherwood | (failed, but should be possible) | 14:00 |
richard_maw | so it's an approach which ought to work without needing to already be in the Amazon cloud | 14:02 |
richard_maw | we should jut be able to import a volume and register an image with it, provided with the right manifest | 14:02 |
*** ssam2 has joined #baserock | 14:06 | |
*** ChanServ sets mode: +v ssam2 | 14:06 | |
* richard_maw wonders what an S3 bucket name is | 14:17 | |
paulsherwood | it's the id for a storage location | 14:18 |
richard_maw | is that like availability zones? | 14:18 |
* paulsherwood doesn't know, sorry | 14:19 | |
richard_maw | hm, appears to be some arbitrary label for grouping | 14:20 |
* richard_maw uses the pre-existing ciat-bucket | 14:21 | |
Kinnison | s3 buckets are labels for groupings of storage which can have policy and access control applied to them | 14:25 |
Kinnison | essentially | 14:25 |
richard_maw | 'tis uploadin' | 14:26 |
Kinnison | mmmm | 14:26 |
richard_maw | slowly | 14:26 |
richard_maw | uploading a bunch of 10M chunks, half of which are likely to be empty | 14:27 |
Kinnison | heh | 14:28 |
* richard_maw guesses this is why the BSD guy did his builds in the cloud | 14:28 | |
Kinnison | in part, almost certainly | 14:28 |
richard_maw | you never get bored in this job eh, there's always some new technology you've got to work out htf to use | 14:30 |
tiredcat | until the technology figures out how to use us that is | 14:36 |
richard_maw | heh | 14:37 |
*** toscalix__ has quit IRC | 14:45 | |
*** toscalix__ has joined #baserock | 14:47 | |
*** franred has joined #baserock | 14:56 | |
*** tiredcat has quit IRC | 15:00 | |
paulsherwood | is the pipelining working now? arm build hasn't run for a while iiuc | 15:00 |
richard_maw | last systemd merge was 13:32 < sd-bot1> [systemd|michich] Merge pull request #1403 from dvdhrm/prioq-comment https://github.com/systemd/systemd/commit/9d66db1 | 15:02 |
SotK | looks to me like the last builds were at 10:47 | 15:03 |
richard_maw | it's not impossible that we just happen to have hit a poor synchronisation between the two troves involved in fetches before it turns up in CIAT | 15:04 |
richard_maw | but it's rather unlikely | 15:04 |
Kinnison | check bottlerock again? | 15:04 |
Kinnison | though the firehose triggers are running | 15:05 |
Kinnison | so it's unlikely to be that | 15:05 |
richard_maw | it's not stuck like it used to be | 15:05 |
paulsherwood | no x86 build at that time either? | 15:05 |
richard_maw | pardon? | 15:05 |
paulsherwood | 13:32? | 15:06 |
richard_maw | we don't get build triggers immediately as upstream pushes changes, since troves have to poll for changes | 15:06 |
wdutch | I can see a problem | 15:06 |
wdutch | http://paste.baserock.org/jaxuvenohe | 15:07 |
wdutch | I'm not sure what terminated | 15:07 |
richard_maw | ouch, is that from buildbot? | 15:07 |
wdutch | bottlerock looks to be running | 15:07 |
* wdutch will just restart everything | 15:08 | |
richard_maw | wdutch: can we do that without buildbot losing state? | 15:08 |
wdutch | errm | 15:08 |
wdutch | I think interupted builds restart | 15:08 |
wdutch | but I could be wrong | 15:08 |
wdutch | any sendchanges between two nodes will probably be lost | 15:09 |
wdutch | but I don't see how we could have any | 15:09 |
wdutch | seems odd that bottlerock has a much lower pid that buildbot | 15:10 |
wdutch | or does that not imply order once it's been running this long? | 15:11 |
richard_maw | wdutch: correct | 15:11 |
richard_maw | pids get reused all the time | 15:11 |
wdutch | ahh | 15:12 |
richard_maw | though there's a sysctl to increase the maximum pid number | 15:12 |
wdutch | I knew that :) I didn't know if they eventually just cycled or what | 15:12 |
wdutch | anyway | 15:12 |
richard_maw | though generally you don't want to touch it, as if you have a wider range of pids, it can be harder to find a free one | 15:12 |
wdutch | kill all the things! | 15:12 |
wdutch | restarted | 15:12 |
pedroalvarez | I was wondering 10 minutes ago what was going on... | 15:23 |
pedroalvarez | now I know | 15:23 |
pedroalvarez | Dev version of the UI: http://ciat.baserock.org:8888/#/ | 15:23 |
wdutch | now we know | 15:23 |
wdutch | sorry pedro | 15:23 |
pedroalvarez | wdutch: no worries :) | 15:23 |
wdutch | purdy | 15:24 |
paulsherwood | kewl | 15:24 |
pedroalvarez | kind of :) | 15:24 |
pedroalvarez | I've been learning js | 15:25 |
pedroalvarez | took me a while to do something useful | 15:25 |
pedroalvarez | and of course, is code I'm not proud of | 15:25 |
*** doffm_ is now known as doffm | 15:25 | |
radiofree | pedroalvarez: i know it's a WIP, but there's a couple of issues with firefox | 15:26 |
pedroalvarez | radiofree: please, go ahead with them | 15:26 |
pedroalvarez | I hope nobody tries it in their phones :) | 15:26 |
paulsherwood | great idea! | 15:27 |
* paulsherwood does | 15:27 | |
pedroalvarez | thanks pedro.. | 15:28 |
SotK | it needs to not have the vertical centering on mobile, but other than that looks fine IMO | 15:28 |
paulsherwood | the boxes appear in a column on safari/iphone | 15:29 |
paulsherwood | as opposed to a row by default | 15:29 |
radiofree | pedroalvarez: ok, 1, the title text goes onto a new line at my resolution : http://i.imgur.com/RTVyhkN.png | 15:31 |
radiofree | pedroalvarez: 2, the scrollbar on the right? It scrolls the header http://i.imgur.com/34mcwyh.png | 15:31 |
radiofree | pedroalvarez: 3, clicking something that requires you to scroll down (e.g arm build) results in a brand new scrollbar! http://i.imgur.com/kxoy40G.png | 15:31 |
*** tiredcat has joined #baserock | 15:37 | |
wdutch | "TESTING_SHA=HEAD" | 15:38 |
wdutch | I didn't think that was possible any more :/ | 15:38 |
*** tiredcat has quit IRC | 15:40 | |
*** tiredcat has joined #baserock | 15:43 | |
*** ssam2 has quit IRC | 15:49 | |
*** ssam2 has joined #baserock | 15:51 | |
*** ChanServ sets mode: +v ssam2 | 15:51 | |
richard_maw | ooh | 16:07 |
* richard_maw has a baserock-test AMI now | 16:07 | |
pedroalvarez | richard_maw: ohh! | 16:10 |
tlsa | pedroalvarez: the css from my branch should have fixed radiofree's 2nd and 3rd things | 16:10 |
pedroalvarez | radiofree: haha! | 16:11 |
pedroalvarez | thanks | 16:11 |
pedroalvarez | tlsa: you are a star | 16:12 |
pedroalvarez | I don't know what I've done with that merge.. | 16:15 |
richard_maw | the hypervisor doesn't think it's crashed, but since I didn't upload a system with cloud-init, I doubt we'll actually be able to do anything with it | 16:15 |
* richard_maw wonders if there's a way to get a console | 16:15 | |
Kinnison | No | 16:15 |
Kinnison | You might be able to get the current full-content of the serial port output | 16:16 |
Kinnison | but that's it | 16:16 |
Kinnison | it's possible that it DHCP'd okay | 16:16 |
pedroalvarez | radiofree: try now? | 16:16 |
richard_maw | Kinnison: it says it has a public IP | 16:16 |
Kinnison | so if it has an SSH server open etc, then if the web UI shows you an IP then you could try SSHing to it | 16:16 |
radiofree | pedroalvarez: marvellous! | 16:16 |
radiofree | however clicking on the "arm build" forces the title to wrap (since there's now a scrollbar) | 16:17 |
pedroalvarez | I think I'll make it smaller | 16:17 |
radiofree | maybe get rid of "with baserock"? | 16:18 |
Kinnison | richard_maw: any luck? | 16:18 |
pedroalvarez | radiofree: done | 16:19 |
richard_maw | Kinnison: ssh connection timed out | 16:19 |
radiofree | pedroalvarez: nice :D | 16:19 |
Kinnison | what security domain did you stand the server up in? | 16:19 |
richard_maw | security group is launch-wizard-2, it's got inbound SSH from anywhere and outbound everything | 16:20 |
*** toscalix__ is now known as toscalix | 16:20 | |
SotK | pedroalvarez: looks good! | 16:20 |
Kinnison | richard_maw: hmm | 16:20 |
toscalix | pedroalvarez: I suggest you deploy the changes you have done so far first thing tomorrow morning....not late this afternoon | 16:21 |
* toscalix advices: deployments early in the morning if possible | 16:22 | |
*** tiagogomes_ has quit IRC | 16:28 | |
richard_maw | hmm, potentially we'd need to depoly with console=ttyS0 to get any logs | 16:30 |
richard_maw | though it could be a driver problem with xen | 16:31 |
pedroalvarez | toscalix: I'll take your advice | 16:31 |
pedroalvarez | SotK: don't look at the code :) | 16:31 |
*** toscalix has quit IRC | 16:32 | |
*** toscalix has joined #baserock | 16:32 | |
pedroalvarez | are ther plans to add an extra Column in buildbot to publish after testing? | 16:33 |
Kinnison | I'd hope there'll be a job to publish the changeset at minimum to a candidate review system | 16:34 |
toscalix | wdutch: we need that, if you think you canoot make it, please let me know and I will find somebody to help | 16:35 |
toscalix | cannot | 16:35 |
toscalix | I understand you have a lot in your plate already | 16:36 |
*** mariaderidder has quit IRC | 16:37 | |
*** franred has quit IRC | 16:40 | |
*** gtristan has quit IRC | 16:40 | |
*** ssam2 has quit IRC | 16:50 | |
*** paulwaters_ has quit IRC | 16:51 | |
*** jonathanmaw has quit IRC | 16:54 | |
*** toscalix has quit IRC | 16:58 | |
*** toscalix has joined #baserock | 17:01 | |
pedroalvarez | it would be something simple, to move the file to the rigth place of a file server | 17:03 |
pedroalvarez | I need to read the backlog, I missed a lot of things and I don't know where we are now | 17:03 |
wdutch | yes a file could be moved somewhere by orchestration | 17:17 |
wdutch | I do wonder if that's not a job for ciat-testing | 17:17 |
pedroalvarez | Nope, is something different | 17:26 |
SotK | can it not just push its change to Gerrit? | 17:26 |
pedroalvarez | After testing we might want to send a patch to Gerrit, or publish the images, or send an email | 17:27 |
pedroalvarez | Maybe all of them | 17:27 |
wdutch | okay I'll set that up tomorrow | 17:27 |
pedroalvarez | Yay! | 17:27 |
SotK | pedroalvarez: Also, too late, I already did! It's no worse than what I gave you to begin with :) | 17:39 |
pedroalvarez | Heh, it's ok for now I think | 17:41 |
*** Stanto has quit IRC | 17:54 | |
*** Stanto has joined #baserock | 17:59 | |
paulsherwood | ybd can and does already 'publish' if it knows about a kbas server. currently it only publishes chunks, and it needs a proper security scheme. | 18:03 |
paulsherwood | rjek: did you manage to take a look at that? | 18:03 |
*** toscalix has quit IRC | 18:53 | |
rjek | paulsherwood: I looked, but not close enough sadly. I have a plan this evening. | 22:22 |
*** paulsherwood has quit IRC | 23:33 | |
*** paulsherwood has joined #baserock | 23:33 | |
*** De|ta has quit IRC | 23:34 | |
*** De|ta has joined #baserock | 23:34 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!