| *** gtristan has joined #baserock | 02:05 | |
| *** gtristan has quit IRC | 03:42 | |
| *** gtristan has joined #baserock | 03:59 | |
| *** gtristan has quit IRC | 04:44 | |
| *** gtristan has joined #baserock | 05:05 | |
| gtristan | oddly, sometimes during a ybd build, it goes ahead and builds packages one by one, downloading them as needed - other times, it downloads everything before starting the build | 05:24 |
|---|---|---|
| gtristan | any idea why this is ? | 05:24 |
| * gtristan delves deeper into the python sources while stuff downloads | 05:26 | |
| * gtristan thinks it has to do with presence or not of the tree server | 05:27 | |
| *** paulwaters_ has joined #baserock | 06:46 | |
| *** tiagogomes has joined #baserock | 06:52 | |
| wdutch | pedroalvarez: in CIAT what will testing pass to publish? | 07:10 |
| pedroalvarez | wdutch: I don't understand the question :/ | 07:29 |
| pedroalvarez | What will trigger a publish? | 07:29 |
| wdutch | testing I assume | 07:29 |
| wdutch | but the publish step will, I assume, need to be given some data | 07:29 |
| pedroalvarez | Ahh ok | 07:30 |
| pedroalvarez | Sha1, to send it for review if needed | 07:30 |
| pedroalvarez | And the image, to upload it somewhere if needed | 07:31 |
| paulsherwood | gtristan: yes, it has to do with presence or not of tree server | 07:31 |
| paulsherwood | i think there are two conflicting use-cases... | 07:31 |
| paulsherwood | we want that th build can work without network as far as possible. but when we first run ybd it needs network obviously. | 07:32 |
| paulsherwood | so i made the default that it downloads all the git repos first time. it needs the repos to map commit => tree for each component in order to create cache_keys | 07:32 |
| gtristan | paulsherwood, good morning :) | 07:35 |
| paulsherwood | hi there :) | 07:36 |
| gtristan | after 2 and a half hours of downloading git... its building again, last night (after upgrading my distro to latest LTS)... I also let a build fail during the night | 07:36 |
| gtristan | it turns out the gmp.h issue is real, afaics | 07:36 |
| gtristan | so... I *think* I tracked it down to a required --without-guile passed to make's configure in stage2-make.morph | 07:37 |
| gtristan | right now I'm on stage2-gcc, so it should be soon... | 07:37 |
| gtristan | in the meantime I've mostly been reading the baserock wiki... | 07:38 |
| paulsherwood | this gmp.h thing is strange... i wonder why it's not been seen on any other setup? | 07:41 |
| gtristan | oh, and linux-user-chroot on ubuntu 14.04 is unfortunately the broken one, also (smth about arbitrary limit of 50 mounts) - I just brute forced that | 07:41 |
| gtristan | I have no idea yet :-/ | 07:41 |
| gtristan | stage2-make passed ! | 07:41 |
| gtristan | w00t | 07:41 |
| * gtristan looks forward to not downloading gits and becoming productive | 07:42 | |
| paulsherwood | heh | 07:42 |
| gtristan | paulsherwood, I have a tiny patch for stage2-make.morph which should be harmless, too ;-) | 07:42 |
| paulsherwood | i'm still surprised at the speeds you're seeing | 07:42 |
| paulsherwood | s/speeds/slowness/ | 07:42 |
| gtristan | honestly... the git downloading part... is averaging around 1.5 MB per second | 07:42 |
| paulsherwood | erk. | 07:43 |
| gtristan | it goes up to 2.5 | 07:43 |
| gtristan | but on smaller packages it doesnt have time to ramp up | 07:43 |
| gtristan | so I'm guessing around 1.5MB average | 07:43 |
| paulsherwood | still, two hours downloading gits? | 07:43 |
| gtristan | I dont find that very slow... it's a *lot* of data... with my connection I can usually get up to 5MB | 07:44 |
| paulsherwood | i hope you're not blowing away the downloaded gits each time? | 07:44 |
| gtristan | I had, but I will cease that | 07:44 |
| wdutch | pedroalvarez: so for now just a sha? not a pass-fail value or anything? | 07:44 |
| gtristan | since last time the make build failed, I had this broken tree | 07:44 |
| gtristan | and didnt want to risk that, although it could be because I was on ybd master | 07:45 |
| gtristan | paulsherwood, build is at [13/339/339]... so I guess that means over 300 repositories | 07:45 |
| gtristan | I'll paste the build log if you like | 07:46 |
| paulsherwood | yes please | 07:46 |
| paulsherwood | that means on step 13 of 339 to do this run (since none are already done), out of a total of 339 steps required for creation of this target | 07:46 |
| paulsherwood | s/none are/none is/ | 07:47 |
| paulsherwood | pedroalvarez: why 'Provisioning' instead of 'Deployment'? | 07:48 |
| paulsherwood | and could we try the background of the main panel in white, just to see how it looks? | 07:48 |
| wdutch | paulsherwood: pertty bad without making a lot of other colour changes :P | 07:50 |
| gtristan | paulsherwood, this is the build so far: http://paste.baserock.org/xusohiwiri | 07:50 |
| * wdutch turned it off in the browser console | 07:50 | |
| SotK | wdutch: +1 | 07:51 |
| gtristan | paulsherwood, and, found this slackware related discussion which gave me the hint: http://sourceforge.net/p/kaarpux/tickets/4/ | 07:54 |
| gtristan | seems like a common thing | 07:55 |
| SotK | paulsherwood: http://i.imgur.com/Cjwrn9z.png | 07:55 |
| paulsherwood | gtristan: ok that build looks promising :) | 07:56 |
| paulsherwood | gtristan: ok, so i understand - your machine has guile already, hence the clash? | 07:57 |
| gtristan | paulsherwood, thats my thinking yeah | 07:57 |
| gtristan | but stage2-make builds in a sandbox, so if it's supposed to detect missing guile anyway, technically it shouldnt be needed ? | 07:57 |
| paulsherwood | SotK: i think that looks great, except that the top bar should be backgrounded grey (would match wiki.baserock.org) | 07:57 |
| gtristan | well, perhaps it is | 07:57 |
| * gtristan has a call pending with Bruce... | 07:58 | |
| paulsherwood | gtristan: for stage1 and stage2 it's still using host tools | 07:58 |
| gtristan | ah that makes sence | 07:58 |
| gtristan | sense | 07:58 |
| gtristan | host tools find it, but headers not present | 07:58 |
| pedroalvarez | paulsherwood: deployment may mean another different thing, that's why toscalix decided that Provisioning was a better word | 08:02 |
| Kinnison | Stage 2 is still bootstrap, so it can be conflating facilities present on the host with facilities present in its sysroot | 08:03 |
| Kinnison | some configure scripts are broken like that | 08:03 |
| paulsherwood | Kinnison: any idea what would cause lots of 'foo already exists, no checkout'? | 08:06 |
| * paulsherwood is looking at https://github.com/CodethinkLabs/research-git-active-days/blob/master/measure.py#L241 which works most of the time, but not for iptables | 08:06 | |
| paulsherwood | http://paste.baserock.org/xupaziwanu | 08:06 |
| *** tiredcat is now known as straycat | 08:07 | |
| Kinnison | that message normally only comes from stash pop | 08:07 |
| Kinnison | Do you have a useful log, covering the command being run, the target dir, the state of the target dir before and after, and the exact error message? | 08:08 |
| paulsherwood | i don't think measure.py is at that level of maturity yet, no | 08:09 |
| * Kinnison recommends you gather useful debug, rather than trying to debug by zen inspection | 08:09 | |
| paulsherwood | not to worry, i'll figure it out :) | 08:10 |
| paulsherwood | Kinnison: do you think my normal approach is zen inspection? :-) | 08:10 |
| Kinnison | No, but what you just asked me to do is | 08:11 |
| Kinnison | "Daniel, here's some code you've never seen before in your life, and an incomplete error message which is seemingly unrelated -- fix pls?" | 08:11 |
| Kinnison | essentially :-) | 08:11 |
| paulsherwood | heh. that's not what i asked | 08:12 |
| paulsherwood | anyways, i'll stop bothering you (for the moment) :) | 08:13 |
| *** zoli__ has joined #baserock | 08:17 | |
| *** straycat is now known as tiredcat | 08:25 | |
| *** mariaderidder has joined #baserock | 08:31 | |
| *** zoli__ has quit IRC | 08:35 | |
| gtristan | paulsherwood, does the ybd build resume well if interrupted ? | 08:40 |
| pedroalvarez | wdutch: yay Publish column! thanks! | 08:44 |
| wdutch | pedroalvarez: it's there but never triggered and doesn't do anything if triggered | 08:45 |
| *** jonathanmaw has joined #baserock | 08:45 | |
| pedroalvarez | I know :) | 08:46 |
| *** mariaderidder has quit IRC | 08:46 | |
| *** mariaderidder has joined #baserock | 08:47 | |
| *** toscalix__ has joined #baserock | 08:49 | |
| pedroalvarez | wdutch: bottlerock looks wrong | 08:53 |
| pedroalvarez | (I was trying to work out how to trigger a publish after a testing is done) | 08:53 |
| pedroalvarez | there are 2 "if __name__ == '__main__':" | 08:54 |
| wdutch | so there are | 08:54 |
| wdutch | that's what copypasting first thing in the morning will do | 08:55 |
| pedroalvarez | change the "deploy_complete" for "publish" | 08:55 |
| wdutch | deploy_complete triggers the testing | 08:55 |
| * wdutch changes "testing_complete to "publish" | 08:55 | |
| wdutch | oh in send changes? | 08:56 |
| pedroalvarez | testing_complete is calling "sendchange('deploy_complete',properties)" | 08:56 |
| pedroalvarez | yes | 08:56 |
| wdutch | done | 08:57 |
| pedroalvarez | yay! now I can trigger this from testing :) | 08:57 |
| pedroalvarez | thanks | 08:58 |
| *** franred has joined #baserock | 09:01 | |
| paulsherwood | gtristan: yes it should | 09:08 |
| gtristan | great, it's going to take a few hours (I know, I should never have passed up that SSD)... and I'll have some errands to run and dinner to eat :) | 09:09 |
| *** zoli__ has joined #baserock | 09:12 | |
| *** tiagogomes has quit IRC | 09:42 | |
| *** gtristan has quit IRC | 09:54 | |
| paulsherwood | i notice that sloccount is being maintained... and there's now an 'official' git upstream (via sourceforge)... what's the best way to tidy this up? | 10:20 |
| paulsherwood | radiofree: nice email :) | 10:22 |
| franred | paulsherwood, we used to create a lorry for the new one with different name and move the related chunks to point to this one - if you are updating a reference | 10:22 |
| radiofree | paulsherwood: it was the "The important point here is that AGL will stay based on Yocto 1.7 - and thus probably on Weston 1.5 - for some time." that through me, you know how good a mood i'm in recently | 10:22 |
| paulsherwood | franred: sloccount is not in any system afaik so far | 10:23 |
| radiofree | s/through/threw | 10:23 |
| pedroalvarez | paulsherwood: are you suggesting to override the existing one given that is not being used? | 10:23 |
| paulsherwood | i would like to... but others may disagree | 10:24 |
| paulsherwood | radiofree: yup. once AGL AMM folks insisted that it was best for AGL to stick with Yocto/poky timings/decisions on versions, i was thrown too :/ | 10:25 |
| paulsherwood | i need to write something on devcurmudgeon about this | 10:26 |
| paulsherwood | because i'm really quite irritated now :) | 10:26 |
| pedroalvarez | paulsherwood: overriding it would be a bad idea if anyone anywhere is using it, and if other downstream troves already have the previous sources | 10:27 |
| paulsherwood | ack. | 10:27 |
| pedroalvarez | but if we only care about us, I'd override it | 10:27 |
| persia | There are too many downstream troves. | 10:28 |
| franred | pedroalvarez, I would add...if you are going to add it to a system. | 10:28 |
| persia | Personally, I think we should deprecate the idea of "downstream trove", and once that has happened, we are more free to do this sort of thing (as this isn't the first time we've wanted to) | 10:28 |
| radiofree | paulsherwood: http://i.imgur.com/uvLaVfR.png | 10:28 |
| rjek | haha | 10:29 |
| rjek | Envious Photoshop skills. | 10:29 |
| paulsherwood | well, this is a general thing... we are not upstreams, we are mirroring upstreams. how do we deal with situations when it turns out that upstream is something other than awhat we are mirroring (either our mistake, or their choice to change something) | 10:29 |
| rjek | Err, enviable | 10:29 |
| radiofree | it's remarkably hard to write with a trackpad | 10:29 |
| rjek | radiofree: If only your laptop had some sort of efficient text entry peripheral? | 10:29 |
| persia | Ignoring downstream troves (which force no decision because of the complications of coordination), the main issue with mirror transitions is that they invalidate history. | 10:31 |
| franred | paulsherwood, if we want reproduction in previous builds you will need to maintain duplicity | 10:31 |
| persia | Essentially, if one ever changes a repo, any old definitions that reference the old repo suddenly are no longer reproducible. | 10:31 |
| paulsherwood | i understand the issues. question is how do we want to set the policy | 10:32 |
| persia | So, unless we can find a way to handle this through indirection and pointers, we probably want to use the never-do-any-transitions model. | 10:32 |
| persia | To future proof this, we probably need to always add metadata to repo names, so foo-github, bar-savannah-svn, etc. | 10:33 |
| persia | (or use some other metadata encoding to make it less annoying) | 10:33 |
| paulsherwood | ack | 10:33 |
| pedroalvarez | I hope that -git -svn -tarball is enough | 10:34 |
| pedroalvarez | (given that even if they move, they will have the same history) | 10:34 |
| persia | pedroalvarez: Absolutlely not. Consider the case where one needs to decide between github.com/project and git.project.org | 10:34 |
| persia | In some cases those are mirrors, and in some cases one or the other is a different construction of some sort. | 10:35 |
| pedroalvarez | -git-new | 10:35 |
| pedroalvarez | as we did with openssh? heh | 10:35 |
| franred | persia, I thought that is implicit in our mirroring (I mean, you can track it back to our/your trove) | 10:35 |
| persia | franred: The problem is to track from *definitions*. | 10:36 |
| franred | persia, aham, I got you | 10:36 |
| paulsherwood | in this specific case, the sf git://git.code.sf.net/p/sloccount/code does not share history with our conversion from their original svn | 10:36 |
| persia | That's not uncommon: there are several ways to transition from svn to git, and different choices result in different SHAs. | 10:37 |
| paulsherwood | ack | 10:37 |
| persia | Short-term, I think we have a mess. | 10:37 |
| paulsherwood | well, long term everyone is using git, so things improve :) | 10:38 |
| persia | Longer term, it might be interesting to do a mass transition to a new mirror URL scheme, so that we are explicitly indicating the thing we are mirroring in definitions, and the mirror then determines if it has a mirror of the described content | 10:38 |
| persia | Rather, than trying to provide shortnames for everything. | 10:38 |
| persia | Even if everyone uses git, there's no promise of reliable history. | 10:39 |
| persia | The git suite itself contains all sorts of useful tools to break history in ways that destroy reproducibility. | 10:39 |
| paulsherwood | yup | 10:39 |
| franred | does the lorried reposirtory contains any metadata from where it was lorried? | 10:40 |
| paulsherwood | we can deduce that from local-configs/lorries | 10:40 |
| paulsherwood | i don't think the repo itself has the data | 10:40 |
| pedroalvarez | I don't think it should. That would modify the repo | 10:41 |
| paulsherwood | +1 | 10:41 |
| franred | well we modify the repo adding branches and tags - add a file with metadata will not harm - but ok | 10:42 |
| paulsherwood | actually, what would be wrong with moving the current gbo sloccount history into a new branch, then reconfiguring to import the real one as master from here on? | 10:43 |
| paulsherwood | (that preserves commits for anyone who might have used them) | 10:43 |
| franred | paulsherwood, sounds fine by me | 10:45 |
| paulsherwood | persia: ^^ ? | 10:46 |
| paulsherwood | (and would this be workable for the general case?) | 10:46 |
| franred | paulsherwood, no, I won't use as a general case | 10:46 |
| franred | :) | 10:46 |
| franred | paulsherwood, Im still thinking that duplicity is not a problem | 10:47 |
| paulsherwood | duplicity means something different from what you think it means. what do you mean? | 10:47 |
| nowster | enormity? :) | 10:48 |
| paulsherwood | duplicity is definitely a problem | 10:48 |
| pedroalvarez | paulsherwood: other branches and tags may clash | 10:48 |
| franred | paulsherwood, duplication | 10:49 |
| paulsherwood | ok | 10:49 |
| paulsherwood | in in the sloccount case there are no tags, and just the one branch | 10:50 |
| pedroalvarez | that makes it a special case. I would disagree if you suggest to do that for all the cases | 10:51 |
| pedroalvarez | for this case, that would be ok | 10:52 |
| pedroalvarez | OOI, are you planning to use it? | 10:53 |
| * pedroalvarez is normally against lorrying things that are not going to be used | 10:53 | |
| * Kinnison is generally against lorrying things which are not to be part of a supported system | 10:54 | |
| paulsherwood | pedroalvarez: i'm already using it. | 10:54 |
| pedroalvarez | Kinnison: that's what I wanted to say | 10:55 |
| paulsherwood | Kinnison: we don't have a precise definition of what 'supported' means here, afaik | 10:55 |
| pedroalvarez | well, things in definitions.git, I'd say | 10:55 |
| paulsherwood | i've used sloccount to help explain some of what baserock is doing, for example | 10:55 |
| persia | The problem with having two histories in two branches in the same repo is that the representations will be entirely different (from packing), complicating things. | 10:56 |
| Kinnison | packing actually doesn't care too much about history | 10:56 |
| paulsherwood | it could be a useful addition to CIAT pipeline for some use-cases (to give mgmt a sense of how much code their systems are dealing with) | 10:56 |
| Kinnison | it's more interested in similar content | 10:56 |
| persia | Kinnison: Right, so if I have two histories in one repo with similar content, the pack results differ. | 10:57 |
| Kinnison | persia: but not adversely | 10:58 |
| persia | paulsherwood: If you want a system with sloccount, add it to something. | 10:58 |
| paulsherwood | i have done so. | 10:58 |
| Kinnison | persia: this is one of the things git's pack stuff gets right | 10:58 |
| persia | Kinnison: Define "adversely" :) There are operations whilch generate different results in the different environments, which may impact some operations. | 10:58 |
| Kinnison | persia: I was thinking from a pack-size PoV | 10:59 |
| persia | paulsherwood: Then I don't understand the issue with lorrying sloccount: if it is in a reference system, surely it ought be lorried. | 10:59 |
| * Kinnison is unsure in what other way you could be worried about | 10:59 | |
| persia | Kinnison: Oh, yes, from that PoV, it doesn't matter. From a mirror PoV, it's more complicated. | 10:59 |
| paulsherwood | it's in one of my systems, not upstream | 10:59 |
| persia | paulsherwood: Then put it in your mirror. If you want it in the upstream lorry, put it in an upstream system. | 10:59 |
| Kinnison | persia: I'm all for namespaces in that instance, but the tooling is squiffy | 11:00 |
| paulsherwood | i have no mirror | 11:00 |
| persia | Kinnison: Yes, which is why it needs thought about the right way to do it. | 11:00 |
| Kinnison | new repo is the only completely safe approach | 11:00 |
| Kinnison | asyou mentioned earlier | 11:00 |
| pedroalvarez | If we add lorries for anyone that want's to add something to their systems, this wouldn't scale | 11:02 |
| paulsherwood | agreed | 11:03 |
| pedroalvarez | I wold approve a patch to add a git lorry, though | 11:03 |
| * paulsherwood has mailed the list | 11:04 | |
| persia | I think it is also sensible to add new lorries for anything already lorried that just needs a new repo because upstream moved. | 11:07 |
| persia | (even if the new location is not yet used by any reference systems) | 11:07 |
| *** tiagogomes has joined #baserock | 11:15 | |
| toscalix__ | pedroalvarez: is it ok to tallk 15 min today about the UI? We can do it through chat if you and Patrick prefer it | 11:22 |
| *** toscalix__ is now known as toscalix | 11:22 | |
| toscalix | I want to know if I have to focus on something beyond the content on the wiki and also understand where are you guys at | 11:23 |
| toscalix | pedroalvarez: I see quite some progress in production as planned so maybe we should talk about the next step | 11:24 |
| toscalix | I assume you have some ideas already | 11:25 |
| pedroalvarez | toscalix: I'm currently trying to make the titles look as cilckable, so that people clicks on them and we send them to the wiki | 11:25 |
| toscalix | so maybe we can talk at the end of the day about next steps. what do you think? | 11:25 |
| *** zoli__ has quit IRC | 11:26 | |
| pedroalvarez | and we need to do something in the publishing step, so that we can put another link on there | 11:26 |
| toscalix | so it is better to talk tomorrow at lunch? | 11:26 |
| pedroalvarez | toscalix: yes, feel free to give ideas in the meantime | 11:26 |
| *** zoli__ has joined #baserock | 11:26 | |
| pedroalvarez | that yes wasn't for the "tomorrow at lunch" | 11:27 |
| toscalix | ah, ok. I prefer end of day (EOD) | 11:27 |
| pedroalvarez | ok :) | 11:27 |
| toscalix | thanks | 11:27 |
| pedroalvarez | Ok, now Test triggers Publishing once it's done | 11:32 |
| pedroalvarez | we have to put something useful there :) | 11:32 |
| paulsherwood | no arm builds today? | 11:38 |
| * richard_maw checks when systemd last pushed a change | 11:39 | |
| richard_maw | a flurry of activity ar 11AM according to IRC logs | 11:40 |
| * richard_maw checks whether that made it to the trove yet | 11:40 | |
| richard_maw | last systemd update made it to the trove 16 hours ago | 11:41 |
| * richard_maw checks lorry controller status | 11:41 | |
| richard_maw | systemd is due to be checked in an hour, which means it was checked 1h ago, which is within the likely boundaries of it not syncing from the other trove yet | 11:42 |
| richard_maw | (we might want to think about moving from cu010-trove to reduce the latency) | 11:42 |
| richard_maw | it's entirely plausible at this point that we've just gotten unlucky with the trove mirroring at this point | 11:44 |
| richard_maw | since the last update to git.baserock.org happened a handful of minutes after cu010-trove scanned | 11:46 |
| richard_maw | ooh, next systemd update lets you set up the net_cls cgroup controller for services, this would in future allow you to specify per-service firewall rules | 11:49 |
| *** toscalix has quit IRC | 11:59 | |
| *** gtristan has joined #baserock | 12:08 | |
| Kinnison | richard_maw: oooh | 12:31 |
| richard_maw | yep, handy for some projects | 12:33 |
| Kinnison | indede | 12:34 |
| Kinnison | indeed too | 12:34 |
| richard_maw | we'll know in 15m or so whether we've just not seen any builds from being exceedingly unlucky with the lorry times | 12:35 |
| Kinnison | has anyone doublechecked bottlerocket? | 12:36 |
| Kinnison | bottlerock even | 12:36 |
| richard_maw | it's been used to trigger continuations from earlier jobs in the quiet period between builds | 12:36 |
| Kinnison | kay | 12:37 |
| *** zoli__ has quit IRC | 12:55 | |
| richard_maw | systemd is due for an update any minute now | 12:57 |
| * rjek is on the edge of his seat. | 12:58 | |
| * Kinnison recommends rjek sit comfortably, before we begin | 12:58 | |
| rjek | You're right. The edge is hard and it's denting my posterior. | 12:58 |
| paulsherwood | do i need to watch http://ciat.baserock.org:8010/waterfall, or is http://ciat.baserock.org/#/ the real deal? :) | 13:01 |
| * rjek sadfaces a bit at the JS-heavyness of that | 13:02 | |
| * paulsherwood sadfaces right back at rjek | 13:03 | |
| rjek | :) | 13:03 |
| Kinnison | In a fit of amusing coincidence, async seems to be taking a significant amount of time, blocking the queue | 13:03 |
| richard_maw | systemd updated | 13:05 |
| richard_maw | x86 is building | 13:05 |
| richard_maw | arm is building | 13:06 |
| richard_maw | it's working | 13:06 |
| richard_maw | just… quite a painful wait for changes | 13:06 |
| Kinnison | I'm all for migrating from cu010-trove to git.baserock.org if everyone else is | 13:06 |
| * richard_maw would be happy with that, or work to make troves able to notify each other of changes | 13:07 | |
| persia | I'm much more in favour of migration. | 13:11 |
| persia | Inter-trove notification encourages folk to mirror other mirrors, which both causes the undesired repo issue and the short horizon issue, neither of which helps ensure a robust environment for traceability. | 13:12 |
| Kinnison | I want both, but the notification bit needs some careful thought | 13:12 |
| paulsherwood | Kinnison: +1 | 13:13 |
| persia | It would take a lot to convince me that the benefit outweighs the cost. To me, the only benefit is reduced admin by a mirror maintainer, whereas the costs are legion. | 13:13 |
| paulsherwood | (for using g.b.o) | 13:13 |
| pedroalvarez | Kinnison: you have the +1 from baserock-ops | 13:15 |
| pedroalvarez | Kinnison: also, I'd be interested in knowing what changes are needed | 13:16 |
| Kinnison | for moving ciat.b.o to running from git.b.o ? | 13:16 |
| franred | where does CIAT code-base live? I was expecting seen some patches in gerrit or in the mailing list. | 13:16 |
| Kinnison | Mostly it's about migrating the relevant repos to git.baserock.org and reconfiguring things | 13:16 |
| pedroalvarez | Kinnison: for enabling the notifications in g.b.o | 13:16 |
| Kinnison | franred: It's currently on cu010-trove.codethink.com because that's where we were developing it (in the public, but not publicised) | 13:17 |
| Kinnison | pedroalvarez: Oh, Well, basically we need the git server to support subscriptions to do it in a way I'd actually approve of | 13:17 |
| franred | Kinnison, cheers :) | 13:18 |
| *** paulwaters__ has joined #baserock | 13:20 | |
| *** paulwaters_ has quit IRC | 13:21 | |
| *** paulwaters__ has quit IRC | 13:26 | |
| *** gtristan has quit IRC | 13:34 | |
| *** paulwaters__ has joined #baserock | 13:35 | |
| *** toscalix__ has joined #baserock | 13:50 | |
| * paulsherwood wonders why ciat is trying 10 instances for x86 builds.... | 13:51 | |
| *** gtristan has joined #baserock | 13:52 | |
| paulsherwood | it will be slower. if it's a cx large, for all my tests the optimal number was 4. if it's mx, the optimal number was 5. | 13:53 |
| Kinnison | I think it's an m4.10x | 13:54 |
| Kinnison | currently at least | 13:54 |
| paulsherwood | so 5 should be faster | 13:54 |
| paulsherwood | and cx with 4 instances would be both faster and cheaper :) | 13:56 |
| *** toscalix__ is now known as toscalix | 14:06 | |
| *** paulwaters__ has quit IRC | 14:09 | |
| * pedroalvarez hates css | 14:54 | |
| tlsa | :) | 14:55 |
| Zara | :D | 14:55 |
| *** zoli__ has joined #baserock | 14:56 | |
| SotK | pedroalvarez: now look in a different web browser :) | 14:56 |
| Zara | pedroalvarez: try different zooms | 14:56 |
| jmacs | I tried it in Links; it's a masterpiece of simplicity there. | 14:56 |
| rjek | And in NetSurf :) | 14:57 |
| pedroalvarez | please, let me hate css, and don't make me hate you | 14:58 |
| rjek | pedroalvarez: https://lh4.ggpht.com/uAVWC5KAFitSqKYLt_KdZXjVG9fO6Kue_wDn3nAo22U7KQdd9zGNdcziPw-pzPh7LSxLTpYNvELSZJmtqRAQANr5cSg?.gif | 14:58 |
| pedroalvarez | it is exatly like that | 14:59 |
| rjek | The more you try to fix it the worse it gets | 14:59 |
| * pedroalvarez reverts work to make it prettier | 14:59 | |
| * tlsa doesn't find css that bad, but only because I have a really deep knowledge of how and why layout works the way it does | 15:00 | |
| Zara | I get irritated at frameworks around it that map everything to exact sizes rather than percentages of the available screen. | 15:01 |
| *** franred has quit IRC | 15:01 | |
| persia | Any layout that makes assumptions about the size of pixels, or the number of pixels available in a given dimension is unusable for someone. | 15:02 |
| Zara | I'd like to be able to list bounds to create sets of axis, then plot the sizes of elements (at different screen sizes) on the graphs, forming lines or curves. then you'd just have to manipulate the curves to change element sizes across all possible screen sizes, and these could be expressed as equations. | 15:08 |
| Kinnison | that makes life quite hard :-) | 15:09 |
| Kinnison | Once I learned bootstrap's grid system I managed to make sites which didn't look eyebleedingly 90s in style | 15:10 |
| persia | Zara: That breaks for environments is highly variable DPI, especially high-DPI, low resolution screens and low-DPI, high-resolution screens. | 15:10 |
| Kinnison | But I think that relies on too much JS | 15:10 |
| persia | s/resolution/pixel-count/g | 15:10 |
| rjek | Bootstrap's grid system doesn't quite solve the problem I'm having with HTML/CSS atm | 15:10 |
| Kinnison | rjek: It's certainly not meant to solve the problem you're having right now, no | 15:10 |
| * Kinnison notes that most people deal in CSS pixels or in DIPs these days | 15:11 | |
| rjek | Which I will continue to to beat my head against when I get home this morning | 15:11 |
| rjek | this morning? | 15:11 |
| Zara | yeah, it's a one-time thing; you'd need it as a framework and then it could just be used from there. in practice it wouldn't happen because you'd have to convince people to use the framework in the first place and that would be a lot of effort. | 15:11 |
| rjek | this evening | 15:11 |
| persia | Kinnison: What is DIPs? | 15:16 |
| Kinnison | device-independent-pixels | 15:17 |
| Kinnison | basically a way to think about pixels without having to worry about real pixels | 15:17 |
| Kinnison | because so many devices have maddeningly huge DPIs | 15:17 |
| jmacs | Meaningless Indication of Pixel Size? | 15:17 |
| persia | Right, but both still break on my 600DPI 800x400 screen or on some of the single-digit DPI 1920x1080 screens. | 15:18 |
| rjek | Simply use vector graphics, and co-ordinates stored in floating point based on the planck length. | 15:19 |
| Kinnison | wide range, but risky precision | 15:21 |
| persia | rjek: Presumes a fixed visual area occupied by the screen. Plain vector graphics without the sizing is safer. | 15:21 |
| pedroalvarez | ciat red!!! | 15:24 |
| pedroalvarez | wdutch: ^ | 15:25 |
| pedroalvarez | I can't figure out what failed | 15:25 |
| jmacs | Hmm, should we have a CIAT bot in this channel? | 15:25 |
| pedroalvarez | nobody here seems to like irc bots | 15:26 |
| wdutch | jmacs: oh god no | 15:26 |
| Kinnison | I don't mind a bot which announces *changes* in stte | 15:26 |
| Kinnison | state | 15:26 |
| Kinnison | I dislike ones which announce every little thing | 15:26 |
| jmacs | Noise is always bad | 15:28 |
| radiofree | oooh progress bars | 15:29 |
| Kinnison | ? | 15:29 |
| paulsherwood | jmacs: noise is not always bad. sometimes it's a signal. | 15:29 |
| * Kinnison refreshes | 15:29 | |
| wdutch | pedroalvarez: no idea what happened :( | 15:29 |
| jmacs | paulsherwood: Noise and signal are opposites in my dictionary | 15:30 |
| jmacs | Anyway, I'll shelve that under "ideas to do sometime" | 15:30 |
| paulsherwood | jmacs: :) | 15:32 |
| wdutch | pedroalvarez: how attached is the UI to the column names? It'll be awkward for me to preserve them when I swap in the pipeline config | 16:00 |
| pedroalvarez | wdutch: thanks for asking. It is a bit attached | 16:01 |
| pedroalvarez | wdutch: Depends on how are they named, to go to different columns | 16:02 |
| *** jonathanmaw has quit IRC | 16:02 | |
| pedroalvarez | wdutch: the code looks for the following keywords: Integration, Build, Deploy, Test, Publishing | 16:02 |
| wdutch | oh cool | 16:03 |
| wdutch | then all is well | 16:03 |
| pedroalvarez | yay! | 16:03 |
| wdutch | :) | 16:03 |
| * wdutch is now annoyed by the ing on Publishing | 16:04 | |
| pedroalvarez | heheh | 16:05 |
| pedroalvarez | I can remove that from the code, if you are going to change its name | 16:05 |
| pedroalvarez | done | 16:06 |
| * wdutch didn't do it in orchestration quick enough | 16:07 | |
| wdutch | we've lost the history :( | 16:08 |
| pedroalvarez | yup, | 16:10 |
| pedroalvarez | and the UI is showing the previous bulder still | 16:11 |
| pedroalvarez | oh, it was my cache | 16:12 |
| pedroalvarez | we are good | 16:12 |
| pdar | how could i make the publishing thing trigger a publishing script? | 16:18 |
| pedroalvarez | it is running a publishing script currently | 16:19 |
| pedroalvarez | but is empty | 16:19 |
| pedroalvarez | it is this one http://cu010-trove.codethink.com/cgi-bin/cgit.cgi/cu010-trove/br6/buildslave-scripts.git/tree/triggers/publish_trigger.sh | 16:21 |
| pdar | cool | 16:22 |
| pdar | thanks pedro | 16:22 |
| * pedroalvarez now hates callbacks | 16:30 | |
| pedroalvarez | my most voted question in stackoverflow: "Wait for callback in javascript" | 16:31 |
| Kinnison | heh | 16:32 |
| Zara | this horror is comfortingly familiar to me. | 16:42 |
| *** mariaderidder has quit IRC | 16:43 | |
| SotK | pedroalvarez: :D | 17:31 |
| *** zoli__ has quit IRC | 18:26 | |
| *** zoli__ has joined #baserock | 18:29 | |
| *** toscalix has quit IRC | 19:42 | |
| *** toscalix__ has joined #baserock | 19:48 | |
| *** toscalix__ has quit IRC | 20:46 | |
| *** zoli__ has quit IRC | 21:14 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
