IRC logs for #baserock for Wednesday, 2015-09-30

*** gtristan has joined #baserock02:05
*** gtristan has quit IRC03:42
*** gtristan has joined #baserock03:59
*** gtristan has quit IRC04:44
*** gtristan has joined #baserock05:05
gtristanoddly, 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 build05:24
gtristanany idea why this is ?05:24
* gtristan delves deeper into the python sources while stuff downloads05:26
* gtristan thinks it has to do with presence or not of the tree server05:27
*** paulwaters_ has joined #baserock06:46
*** tiagogomes has joined #baserock06:52
wdutchpedroalvarez: in CIAT what will testing pass to publish?07:10
pedroalvarezwdutch: I don't understand the question :/07:29
pedroalvarezWhat will trigger a publish?07:29
wdutchtesting I assume07:29
wdutchbut the publish step will, I assume, need to be given some data07:29
pedroalvarezAhh ok07:30
pedroalvarezSha1, to send it for review if needed07:30
pedroalvarezAnd the image, to upload it somewhere if needed07:31
paulsherwoodgtristan: yes, it has to do with presence or not of tree server07:31
paulsherwoodi think there are two conflicting use-cases...07:31
paulsherwoodwe want that th build can work without network as far as possible. but when we first run ybd it needs network obviously.07:32
paulsherwoodso 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_keys07:32
gtristanpaulsherwood, good morning :)07:35
paulsherwoodhi there :)07:36
gtristanafter 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 night07:36
gtristanit turns out the gmp.h issue is real, afaics07:36
gtristanso... I *think* I tracked it down to a required --without-guile passed to make's configure in stage2-make.morph07:37
gtristanright now I'm on stage2-gcc, so it should be soon...07:37
gtristanin the meantime I've mostly been reading the baserock wiki...07:38
paulsherwoodthis gmp.h thing is strange... i wonder why it's not been seen on any other setup?07:41
gtristanoh, 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 that07:41
gtristanI have no idea yet :-/07:41
gtristanstage2-make passed !07:41
gtristanw00t07:41
* gtristan looks forward to not downloading gits and becoming productive07:42
paulsherwoodheh07:42
gtristanpaulsherwood, I have a tiny patch for stage2-make.morph which should be harmless, too ;-)07:42
paulsherwoodi'm still surprised at the speeds you're seeing07:42
paulsherwoods/speeds/slowness/07:42
gtristanhonestly... the git downloading part... is averaging around 1.5 MB per second07:42
paulsherwooderk.07:43
gtristanit goes up to 2.507:43
gtristanbut on smaller packages it doesnt have time to ramp up07:43
gtristanso I'm guessing around 1.5MB average07:43
paulsherwoodstill, two hours downloading gits?07:43
gtristanI dont find that very slow... it's a *lot* of data... with my connection I can usually get up to 5MB07:44
paulsherwoodi hope you're not blowing away the downloaded gits each time?07:44
gtristanI had, but I will cease that07:44
wdutchpedroalvarez: so for now just a sha? not a pass-fail value or anything?07:44
gtristansince last time the make build failed, I had this broken tree07:44
gtristanand didnt want to risk that, although it could be because I was on ybd master07:45
gtristanpaulsherwood, build is at [13/339/339]... so I guess that means over 300 repositories07:45
gtristanI'll paste the build log if you like07:46
paulsherwoodyes please07:46
paulsherwoodthat 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 target07:46
paulsherwoods/none are/none is/07:47
paulsherwoodpedroalvarez: why 'Provisioning' instead of 'Deployment'?07:48
paulsherwoodand could we try the background of the main panel in white, just to see how it looks?07:48
wdutchpaulsherwood: pertty bad without making a lot of other colour changes :P07:50
gtristanpaulsherwood, this is the build so far: http://paste.baserock.org/xusohiwiri07:50
* wdutch turned it off in the browser console07:50
SotKwdutch: +107:51
gtristanpaulsherwood, and, found this slackware related discussion which gave me the hint: http://sourceforge.net/p/kaarpux/tickets/4/07:54
gtristanseems like a common thing07:55
SotKpaulsherwood: http://i.imgur.com/Cjwrn9z.png07:55
paulsherwoodgtristan: ok that build looks promising :)07:56
paulsherwoodgtristan: ok, so i understand - your machine has guile already, hence the clash?07:57
gtristanpaulsherwood, thats my thinking yeah07:57
gtristanbut stage2-make builds in a sandbox, so if it's supposed to detect missing guile anyway, technically it shouldnt be needed ?07:57
paulsherwoodSotK: i think that looks great, except that the top bar should be backgrounded grey (would match wiki.baserock.org)07:57
gtristanwell, perhaps it is07:57
* gtristan has a call pending with Bruce...07:58
paulsherwoodgtristan: for stage1 and stage2 it's still using host tools07:58
gtristanah that makes sence07:58
gtristansense07:58
gtristanhost tools find it, but headers not present07:58
pedroalvarezpaulsherwood: deployment may mean another different thing, that's why toscalix decided that Provisioning was a better word08:02
KinnisonStage 2 is still bootstrap, so it can be conflating facilities present on the host with facilities present in its sysroot08:03
Kinnisonsome configure scripts are broken like that08:03
paulsherwoodKinnison: 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 iptables08:06
paulsherwoodhttp://paste.baserock.org/xupaziwanu08:06
*** tiredcat is now known as straycat08:07
Kinnisonthat message normally only comes from stash pop08:07
KinnisonDo 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
paulsherwoodi don't think measure.py is at that level of maturity yet, no08:09
* Kinnison recommends you gather useful debug, rather than trying to debug by zen inspection08:09
paulsherwoodnot to worry, i'll figure it out :)08:10
paulsherwoodKinnison: do you think my normal approach is zen inspection? :-)08:10
KinnisonNo, but what you just asked me to do is08: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
Kinnisonessentially :-)08:11
paulsherwoodheh. that's not what i asked08:12
paulsherwoodanyways, i'll stop bothering you (for the moment) :)08:13
*** zoli__ has joined #baserock08:17
*** straycat is now known as tiredcat08:25
*** mariaderidder has joined #baserock08:31
*** zoli__ has quit IRC08:35
gtristanpaulsherwood, does the ybd build resume well if interrupted ?08:40
pedroalvarezwdutch: yay Publish column! thanks!08:44
wdutchpedroalvarez: it's there but never triggered and doesn't do anything if triggered08:45
*** jonathanmaw has joined #baserock08:45
pedroalvarezI know :)08:46
*** mariaderidder has quit IRC08:46
*** mariaderidder has joined #baserock08:47
*** toscalix__ has joined #baserock08:49
pedroalvarezwdutch: bottlerock looks wrong08:53
pedroalvarez(I was trying to work out how to trigger a publish after a testing is done)08:53
pedroalvarezthere are 2 "if __name__ == '__main__':"08:54
wdutchso there are08:54
wdutchthat's what copypasting first thing in the morning will do08:55
pedroalvarezchange the "deploy_complete" for "publish"08:55
wdutchdeploy_complete triggers the testing08:55
* wdutch changes "testing_complete to "publish"08:55
wdutchoh in send changes?08:56
pedroalvareztesting_complete is calling "sendchange('deploy_complete',properties)"08:56
pedroalvarezyes08:56
wdutchdone08:57
pedroalvarezyay! now I can trigger this from testing :)08:57
pedroalvarezthanks08:58
*** franred has joined #baserock09:01
paulsherwoodgtristan: yes it should09:08
gtristangreat, 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 #baserock09:12
*** tiagogomes has quit IRC09:42
*** gtristan has quit IRC09:54
paulsherwoodi 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
paulsherwoodradiofree: nice email :)10:22
franredpaulsherwood, 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 reference10:22
radiofreepaulsherwood: 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 recently10:22
paulsherwoodfranred: sloccount is not in any system afaik so far10:23
radiofrees/through/threw10:23
pedroalvarezpaulsherwood: are you suggesting to override the existing one given that is not being used?10:23
paulsherwoodi would like to... but others may disagree10:24
paulsherwoodradiofree: 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
paulsherwoodi need to write something on devcurmudgeon about this10:26
paulsherwoodbecause i'm really quite irritated now :)10:26
pedroalvarezpaulsherwood: overriding it would be a bad idea if anyone anywhere is using it, and if other downstream troves already have the previous sources10:27
paulsherwoodack.10:27
pedroalvarezbut if we only care about us, I'd override it10:27
persiaThere are too many downstream troves.10:28
franredpedroalvarez, I would add...if you are going to add it to a system.10:28
persiaPersonally, 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
radiofreepaulsherwood: http://i.imgur.com/uvLaVfR.png10:28
rjekhaha10:29
rjekEnvious Photoshop skills.10:29
paulsherwoodwell, 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
rjekErr, enviable10:29
radiofreeit's remarkably hard to write with a trackpad10:29
rjekradiofree: If only your laptop had some sort of efficient text entry peripheral?10:29
persiaIgnoring 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
franredpaulsherwood, if we want reproduction in previous builds you will need to maintain duplicity10:31
persiaEssentially, if one ever changes a repo, any old definitions that reference the old repo suddenly are no longer reproducible.10:31
paulsherwoodi understand the issues. question is how do we want to set the policy10:32
persiaSo, 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
persiaTo 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
paulsherwoodack10:33
pedroalvarezI hope that -git -svn -tarball is enough10:34
pedroalvarez(given that even if they move, they will have the same history)10:34
persiapedroalvarez: Absolutlely not.  Consider the case where one needs to decide between github.com/project and git.project.org10:34
persiaIn some cases those are mirrors, and in some cases one or the other is a different construction of some sort.10:35
pedroalvarez-git-new10:35
pedroalvarezas we did with openssh? heh10:35
franredpersia, I thought that is implicit in our mirroring (I mean, you can track it back to our/your trove)10:35
persiafranred: The problem is to track from *definitions*.10:36
franredpersia, aham, I got you10:36
paulsherwoodin this specific case, the sf git://git.code.sf.net/p/sloccount/code does not share history with our conversion from their original svn10:36
persiaThat's not uncommon: there are several ways to transition from svn to git, and different choices result in different SHAs.10:37
paulsherwoodack10:37
persiaShort-term, I think we have a mess.10:37
paulsherwoodwell, long term everyone is using git, so things improve :)10:38
persiaLonger 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 content10:38
persiaRather, than trying to provide shortnames for everything.10:38
persiaEven if everyone uses git, there's no promise of reliable history.10:39
persiaThe git suite itself contains all sorts of useful tools to break history in ways that destroy reproducibility.10:39
paulsherwoodyup10:39
franreddoes the lorried reposirtory contains any metadata from where it was lorried?10:40
paulsherwoodwe can deduce that from local-configs/lorries10:40
paulsherwoodi don't think the repo itself has the data10:40
pedroalvarezI don't think it should. That would modify the repo10:41
paulsherwood+110:41
franredwell we modify the repo adding branches and tags - add a file with metadata will not harm - but ok10:42
paulsherwoodactually, 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
franredpaulsherwood, sounds fine by me10:45
paulsherwoodpersia: ^^ ?10:46
paulsherwood(and would this be workable for the general case?)10:46
franredpaulsherwood, no, I won't use as a general case10:46
franred:)10:46
franredpaulsherwood, Im still thinking that duplicity is not a problem10:47
paulsherwoodduplicity means something different from what you think it means. what do you mean?10:47
nowsterenormity? :)10:48
paulsherwoodduplicity is definitely a problem10:48
pedroalvarezpaulsherwood: other branches and tags may clash10:48
franredpaulsherwood, duplication10:49
paulsherwoodok10:49
paulsherwoodin in the sloccount case there are no tags, and just the one branch10:50
pedroalvarezthat makes it a special case. I would disagree if you suggest to do that for all the cases10:51
pedroalvarezfor this case, that would be ok10:52
pedroalvarezOOI, are you planning to use it?10:53
* pedroalvarez is normally against lorrying things that are not going to be used10:53
* Kinnison is generally against lorrying things which are not to be part of a supported system10:54
paulsherwoodpedroalvarez: i'm already using it.10:54
pedroalvarezKinnison: that's what I wanted to say10:55
paulsherwoodKinnison: we don't have a precise definition of what 'supported' means here, afaik10:55
pedroalvarezwell, things in definitions.git, I'd say10:55
paulsherwoodi've used sloccount to help explain some of what baserock is doing, for example10:55
persiaThe 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
Kinnisonpacking actually doesn't care too much about history10:56
paulsherwoodit 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
Kinnisonit's more interested in similar content10:56
persiaKinnison: Right, so if I have two histories in one repo with similar content, the pack results differ.10:57
Kinnisonpersia: but not adversely10:58
persiapaulsherwood: If you want a system with sloccount, add it to something.10:58
paulsherwoodi have done so.10:58
Kinnisonpersia: this is one of the things git's pack stuff gets right10:58
persiaKinnison: Define "adversely" :)  There are operations whilch generate different results in the different environments, which may impact some operations.10:58
Kinnisonpersia: I was thinking from a pack-size PoV10:59
persiapaulsherwood: 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 about10:59
persiaKinnison: Oh, yes, from that PoV, it doesn't matter.  From a mirror PoV, it's more complicated.10:59
paulsherwoodit's in one of my systems, not upstream10:59
persiapaulsherwood: Then put it in your mirror.  If you want it in the upstream lorry, put it in an upstream system.10:59
Kinnisonpersia: I'm all for namespaces in that instance, but the tooling is squiffy11:00
paulsherwoodi have no mirror11:00
persiaKinnison: Yes, which is why it needs thought about the right way to do it.11:00
Kinnisonnew repo is the only completely safe approach11:00
Kinnisonasyou mentioned earlier11:00
pedroalvarezIf we add lorries for anyone that want's to add something to their systems, this wouldn't scale11:02
paulsherwoodagreed11:03
pedroalvarezI wold approve a patch to add a git lorry, though11:03
* paulsherwood has mailed the list11:04
persiaI 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 #baserock11: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 it11:22
*** toscalix__ is now known as toscalix11:22
toscalixI want to know if I have to focus on something beyond the content on the wiki and also understand where are you guys at11:23
toscalixpedroalvarez: I see quite some progress in production as planned so maybe we should talk about the next step11:24
toscalixI assume you have some ideas already11:25
pedroalvareztoscalix: I'm currently trying to make the titles look as cilckable, so that people clicks on them and we send them to the wiki11:25
toscalixso maybe we can talk at the end of the day about next steps. what do you think?11:25
*** zoli__ has quit IRC11:26
pedroalvarezand we need to do something in the publishing step, so that we can put another link on there11:26
toscalixso it is better to talk tomorrow at lunch?11:26
pedroalvareztoscalix: yes, feel free to give ideas in the meantime11:26
*** zoli__ has joined #baserock11:26
pedroalvarezthat yes wasn't for the "tomorrow at lunch"11:27
toscalixah, ok. I prefer end of day (EOD)11:27
pedroalvarezok :)11:27
toscalixthanks11:27
pedroalvarezOk, now Test triggers Publishing once it's done11:32
pedroalvarezwe have to put something useful there :)11:32
paulsherwoodno arm builds today?11:38
* richard_maw checks when systemd last pushed a change11:39
richard_mawa flurry of activity ar 11AM according to IRC logs11:40
* richard_maw checks whether that made it to the trove yet11:40
richard_mawlast systemd update made it to the trove 16 hours ago11:41
* richard_maw checks lorry controller status11:41
richard_mawsystemd 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 yet11:42
richard_maw(we might want to think about moving from cu010-trove to reduce the latency)11:42
richard_mawit's entirely plausible at this point that we've just gotten unlucky with the trove mirroring at this point11:44
richard_mawsince the last update to git.baserock.org happened a handful of minutes after cu010-trove scanned11:46
richard_mawooh, 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 rules11:49
*** toscalix has quit IRC11:59
*** gtristan has joined #baserock12:08
Kinnisonrichard_maw: oooh12:31
richard_mawyep, handy for some projects12:33
Kinnisonindede12:34
Kinnisonindeed too12:34
richard_mawwe'll know in 15m or so whether we've just not seen any builds from being exceedingly unlucky with the lorry times12:35
Kinnisonhas anyone doublechecked bottlerocket?12:36
Kinnisonbottlerock even12:36
richard_mawit's been used to trigger continuations from earlier jobs in the quiet period between builds12:36
Kinnisonkay12:37
*** zoli__ has quit IRC12:55
richard_mawsystemd is due for an update any minute now12:57
* rjek is on the edge of his seat.12:58
* Kinnison recommends rjek sit comfortably, before we begin12:58
rjekYou're right.  The edge is hard and it's denting my posterior.12:58
paulsherwooddo 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 that13:02
* paulsherwood sadfaces right back at rjek 13:03
rjek:)13:03
KinnisonIn a fit of amusing coincidence, async seems to be taking a significant amount of time, blocking the queue13:03
richard_mawsystemd updated13:05
richard_mawx86 is building13:05
richard_mawarm is building13:06
richard_mawit's working13:06
richard_mawjust… quite a painful wait for changes13:06
KinnisonI'm all for migrating from cu010-trove to git.baserock.org if everyone else is13:06
* richard_maw would be happy with that, or work to make troves able to notify each other of changes13:07
persiaI'm much more in favour of migration.13:11
persiaInter-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
KinnisonI want both, but the notification bit needs some careful thought13:12
paulsherwoodKinnison: +113:13
persiaIt 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
pedroalvarezKinnison: you have the +1 from baserock-ops13:15
pedroalvarezKinnison: also, I'd be interested in knowing what changes are needed13:16
Kinnisonfor moving ciat.b.o to running from git.b.o ?13:16
franredwhere does CIAT code-base live? I was expecting seen some patches in gerrit or in the mailing list.13:16
KinnisonMostly it's about migrating the relevant repos to git.baserock.org and reconfiguring things13:16
pedroalvarezKinnison: for enabling the notifications in g.b.o13:16
Kinnisonfranred: It's currently on cu010-trove.codethink.com because that's where we were developing it (in the public, but not publicised)13:17
Kinnisonpedroalvarez: Oh, Well, basically we need the git server to support subscriptions to do it in a way I'd actually approve of13:17
franredKinnison, cheers :)13:18
*** paulwaters__ has joined #baserock13:20
*** paulwaters_ has quit IRC13:21
*** paulwaters__ has quit IRC13:26
*** gtristan has quit IRC13:34
*** paulwaters__ has joined #baserock13:35
*** toscalix__ has joined #baserock13:50
* paulsherwood wonders why ciat is trying 10 instances for x86 builds....13:51
*** gtristan has joined #baserock13:52
paulsherwoodit 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
KinnisonI think it's an m4.10x13:54
Kinnisoncurrently at least13:54
paulsherwoodso 5 should be faster13:54
paulsherwoodand cx with 4 instances would be both faster and cheaper :)13:56
*** toscalix__ is now known as toscalix14:06
*** paulwaters__ has quit IRC14:09
* pedroalvarez hates css14:54
tlsa:)14:55
Zara:D14:55
*** zoli__ has joined #baserock14:56
SotKpedroalvarez: now look in a different web browser :)14:56
Zarapedroalvarez: try different zooms14:56
jmacsI tried it in Links; it's a masterpiece of simplicity there.14:56
rjekAnd in NetSurf :)14:57
pedroalvarezplease, let me hate css, and don't make me hate you14:58
rjekpedroalvarez: https://lh4.ggpht.com/uAVWC5KAFitSqKYLt_KdZXjVG9fO6Kue_wDn3nAo22U7KQdd9zGNdcziPw-pzPh7LSxLTpYNvELSZJmtqRAQANr5cSg?.gif14:58
pedroalvarezit is exatly like that14:59
rjekThe more you try to fix it the worse it gets14:59
* pedroalvarez reverts work to make it prettier14: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 does15:00
ZaraI get irritated at frameworks around it that map everything to exact sizes rather than percentages of the available screen.15:01
*** franred has quit IRC15:01
persiaAny 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
ZaraI'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
Kinnisonthat makes life quite hard :-)15:09
KinnisonOnce I learned bootstrap's grid system I managed to make sites which didn't look eyebleedingly 90s in style15:10
persiaZara: That breaks for environments is highly variable DPI, especially high-DPI, low resolution screens and low-DPI, high-resolution screens.15:10
KinnisonBut I think that relies on too much JS15:10
persias/resolution/pixel-count/g15:10
rjekBootstrap's grid system doesn't quite solve the problem I'm having with HTML/CSS atm15:10
Kinnisonrjek: It's certainly not meant to solve the problem you're having right now, no15:10
* Kinnison notes that most people deal in CSS pixels or in DIPs these days15:11
rjekWhich I will continue to to beat my head against when I get home this morning15:11
rjekthis morning?15:11
Zarayeah, 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
rjekthis evening15:11
persiaKinnison: What is DIPs?15:16
Kinnisondevice-independent-pixels15:17
Kinnisonbasically a way to think about pixels without having to worry about real pixels15:17
Kinnisonbecause so many devices have maddeningly huge DPIs15:17
jmacsMeaningless Indication of Pixel Size?15:17
persiaRight, but both still break on my 600DPI 800x400 screen or on some of the single-digit DPI 1920x1080 screens.15:18
rjekSimply use vector graphics, and co-ordinates stored in floating point based on the planck length.15:19
Kinnisonwide range, but risky precision15:21
persiarjek: Presumes a fixed visual area occupied by the screen.  Plain vector graphics without the sizing is safer.15:21
pedroalvarezciat red!!!15:24
pedroalvarezwdutch: ^15:25
pedroalvarezI can't figure out what failed15:25
jmacsHmm, should we have a CIAT bot in this channel?15:25
pedroalvareznobody here seems to like irc bots15:26
wdutchjmacs: oh god no15:26
KinnisonI don't mind a bot which announces *changes* in stte15:26
Kinnisonstate15:26
KinnisonI dislike ones which announce every little thing15:26
jmacsNoise is always bad15:28
radiofreeoooh progress bars15:29
Kinnison?15:29
paulsherwoodjmacs: noise is not always bad. sometimes it's a signal.15:29
* Kinnison refreshes15:29
wdutchpedroalvarez: no idea what happened :(15:29
jmacspaulsherwood: Noise and signal are opposites in my dictionary15:30
jmacsAnyway, I'll shelve that under "ideas to do sometime"15:30
paulsherwoodjmacs: :)15:32
wdutchpedroalvarez: how attached is the UI to the column names? It'll be awkward for me to preserve them when I swap in the pipeline config16:00
pedroalvarezwdutch: thanks for asking. It is a bit attached16:01
pedroalvarezwdutch: Depends on how are they named, to go to different columns16:02
*** jonathanmaw has quit IRC16:02
pedroalvarezwdutch: the code looks for the following keywords: Integration, Build, Deploy, Test, Publishing16:02
wdutchoh cool16:03
wdutchthen all is well16:03
pedroalvarezyay!16:03
wdutch:)16:03
* wdutch is now annoyed by the ing on Publishing16:04
pedroalvarezheheh16:05
pedroalvarezI can remove that from the code, if you are going to change its name16:05
pedroalvarezdone16:06
* wdutch didn't do it in orchestration quick enough16:07
wdutchwe've lost the history :(16:08
pedroalvarezyup,16:10
pedroalvarezand the UI is showing the previous bulder still16:11
pedroalvarezoh, it was my cache16:12
pedroalvarezwe are good16:12
pdarhow could i make the publishing thing trigger a publishing script?16:18
pedroalvarezit is running a publishing script currently16:19
pedroalvarezbut is empty16:19
pedroalvarezit is this one http://cu010-trove.codethink.com/cgi-bin/cgit.cgi/cu010-trove/br6/buildslave-scripts.git/tree/triggers/publish_trigger.sh16:21
pdarcool16:22
pdarthanks pedro16:22
* pedroalvarez now hates callbacks16:30
pedroalvarezmy most voted question in stackoverflow: "Wait for callback in javascript"16:31
Kinnisonheh16:32
Zarathis horror is comfortingly familiar to me.16:42
*** mariaderidder has quit IRC16:43
SotKpedroalvarez: :D17:31
*** zoli__ has quit IRC18:26
*** zoli__ has joined #baserock18:29
*** toscalix has quit IRC19:42
*** toscalix__ has joined #baserock19:48
*** toscalix__ has quit IRC20:46
*** zoli__ has quit IRC21:14

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!