IRC logs for #baserock for Monday, 2015-11-09

*** edcragg has quit IRC01:17
*** gtristan has quit IRC04:22
*** gtristan has joined #baserock04:52
paulsherwoodgtristan:     if not get_cache(defs, this) and this.get('kind') != 'cluster':07:18
paulsherwood        app.config['tasks'] += 107:18
paulsherwoodgtristan: WebKitGtk is quite a bottleneck... any chance it can be kicked off lower/earlier?07:19
persiaHow does one make a build earlier?  I thought that we built opportunistically as soon as the build dependency graph permitted.07:21
gtristanpaulsherwood, I still have a branch which untangles gnome strata so that WebKitGtk sits outside of it07:26
gtristanpersia, problem is that if *anything* below gnome.morph changes, *everything* in gnome.morph rebuilds07:27
gtristanincluding, of course, webkit :)07:27
persiagtristan: Ah, right, strata :(07:27
gtristanoh btw, I got to the bottom of broken lorry today:
gtristanmy whole branch depends on that being fixed... can I get some +1s ?07:28
gtristanthanks jjardon :)07:52
jjardongtristan: no, thank you!07:54
gtristanI just ran the lorry locally and the stack trace told me07:58
gtristanhonestly, by eye I wasn't going to find it :)07:58
gtristantonight we should have input methods :)07:59
*** paulwaters_ has joined #baserock08:30
*** tiagogomes has joined #baserock08:34
*** CTtpollard has joined #baserock08:54
*** CTtpollard has quit IRC08:59
*** CTtpollard has joined #baserock08:59
*** CTtpollard has joined #baserock09:00
*** bashrc has joined #baserock09:01
*** CTtpollard has quit IRC09:01
*** CTtpollard has joined #baserock09:01
paulsherwoodWebKitGtk starts at 1:31:00 or so, other instances run out of stuff to do at 01:39:44, everything waits on WebKitGtk til 02:05:3309:15
*** ctbruce has joined #baserock09:15
paulsherwoodso pruning WebKitGtk dependencies would improve this i think09:16
persiaYes, but I would have expected Webkit to build as soon as the dependencies were satisfied, and for other things that waited on it to need to wait because webkit was not yet available (but only things that depend on webkit).09:16
persiaAs gtristan points out, the use of strata as build-dependencies means that the graph is artificially skewed, such that my naive assumption is not valid.09:16
paulsherwoodi'm only citing this as a practical example to support gtristan's argument09:17
*** nowster has joined #baserock09:17
*** toscalix has joined #baserock09:17
gtristanjjardon, ... in relation to the above discussion, ... I've also been thinking about that decision of creating 'gnome-apps' stratum09:18
gtristanjjardon, maybe we should just add a fat comment at the (current) bottom of gnome.morph ############### Apps here #############09:19
gtristanand stick the apps near the bottom09:19
gtristanotherwise we will again lose all the dependency information for apps we add to gnome-apps.morph09:19
gtristanthoughts ?09:19
persiapaulsherwood: I'm in favour of dropping strata: my objection to gtristan's model is the variants bit: I do not see how, if we adopt variants, we would have different information in our definitions than is contained in Debian.09:19
gtristanas I understand it, and I might not understand it well - debian does not do variants really, instead they have separately revisioned packages for separate targets, no ?09:21
* persia finds an example09:22
*** toscalix has quit IRC09:22
paulsherwoodpersia: in your view how would we best deal with support for variants (ie the requirement of maintaining multiple similar-but-different systems) if not via gtristan's suggestion?09:22
gtristanI only started a downstream of debian last year, so I'm a debian newbie :)09:22
persiapaulsherwood: I think we should not try to combine different variants of a component into the same definition.09:23
persiaBecause it causes multi-build issues and/or constrains the set of runtime dependnencies.09:23
persiaRather, I think we should encourage variants to be separate definitions, so one has e.g. two different defintions for mesa, with some indicator as to which is which, and selects one when composing a system.09:24
gtristandependencies can defined on a per-variant basis09:24
gtristanpersia, the problem with that is that one can no longer remain 'ambivalent' about which variant is required, I think this is the key to avoiding the exponential explosion while crawling up the stack09:25
*** edcragg has joined #baserock09:25
persiagtristan: The ambivalence of which you speak leaks into ABI, making things either invalid or unreliable.  It may be that there is coincidentally the same ABI, but one has no guarantee.09:26
persia(or at least, we aren't tracking ABI as part of our cache key currently)09:26
gtristanif one chunk requires mesa, that same chunk must be duplicated for every system which requires it to depend on a different mesa, even if *that* chunk doesnt really care09:27
paulsherwoodwhich provokes an interesting question... where would we get ABI information from, in general?09:27
gtristanof course, the artifacts would be different, if compiled against mesa-1 or mesa-209:27
gtristanthe ABI is from the artifact key, I would think09:27
persiayabause is an example of a Debian package that has gtk and qt variants (although this is due to a cooperative upstream: I have seen examples of less cooperative upstreams, but do not see them now).
radiofreeit would be nice to be able to abstract things like mesa away, "graphic stack" or something, it's entirely possible you might not want to use mesa09:27
persiapaulsherwood: Most of the ABI is available by object inspection, but some bits aren't encoded.09:28
*** toscalix has joined #baserock09:28
radiofreenot all blobs are drop in replacements, e.g for the vivante stuff you have to compile against the headers (with certain defines set depending on what system you want to build... horrible i know)09:29
persiagtristan: But, as a system designer, I want to choose what mesa I'm using, etc.09:29
persiaI want to be able to compile things with or without various compile options.09:29
gtristanpersia, right, the variants allow you to chose that at the system level, while keeping ambivalent chunks which depend on "a version of mesa" in between09:29
persiaAnd I'd rather be able to easily derive from someone else's example, rather than trying to find a way to get both in a single definition.09:29
persiagtristan: Except the dependencies are a result of the configuration options, so if I want to include new libraries or disinclude libraries, I have to go edit the entire dependency tree file-by-file.09:30
persiaWhich is precisely what I don't want to do.09:30
persia(because I can't share my edited files, as they aren't valid for a different system with different variant choices)09:31
gtristanthis boils down to your preference of duplicating everything for each system, I think.09:31
gtristanWhich I wont agrue against really, it's got it's merit09:31
gtristanI just doubt that it's the baserock ethos, which is why I was not going to propose that09:32
persiaMore, it's a reaction to my pain building systems from debian-format packages.09:32
persiaFor one project, I was asked to remove bluetooth support.  This required editing the source files for nearly all of GNOME, beause of the vast number of systems that expect bluetooth support one way or another.09:32
gtristanpersia, the problem I face, is that baserock people want to share stuff in their systems, so I dont get one gnome.morph which I can safely update without risking anything else breaking, and we have all of this middle strata on top of it which is insanely difficult to refactor09:33
persiaDon't conflate the two: strata distort the dependency graphs in ways that make it hard to do all sorts of things.09:33
gtristanso, the input on my end is "We want to share everything as much as possible, but we're stuck with these stratum that are hard to refactor"09:33
persiaThis is independent of whether individual component defintions should contain multiple variants.09:34
gtristanthey are the input09:34
gtristanpersia, I completely agree09:34
gtristanpersia, except that I dont expect baserock to accept any proposal which enforces that every system have duplication09:34
persiaThe duplication is inherent in the desire to have multiple environments.09:35
gtristanso they are both, decidedly separate requirements, which I set out to satisfy09:35
persiaSo, for example, we have a build-essential that uses glibc, and we have another that uses musl.09:35
persiaNothing can safely depend on an arbitrary one of these.09:35
persiaSome systems are similar enough that some components can be shared (for example, if one is building desktop systems, lots of the underlying plumbing is independent of the desktop environment), but some systems are not (I wouldn't want to try to build a hard-drive controller starting with desktop-optimised components)09:37
gtristanpersia, I see you have strong feelings about this and strong arguments to back up your point of view - I honestly think it would be much more productive if you would organize these arguments and summarize them in a reply on baserock-dev09:37
gtristanit's much more difficult to have a sensible conversation at this level of depth on IRC09:37
persiaFor me, the converse is true.  I find discussions via email essentially impossible.09:38
persiaSo I'll point things out when they are mentioned, but otherwise let consensus form elsewhere.09:38
gtristanpersia, regarding your last statement, the problem is that many components can be shared at *all levels* in fact09:41
persiaMay I have an example?09:41
gtristanfor instance, GTK+ is quite high up in the stack, low level in terms of desktops, quite high level in terms of an OS09:41
*** paulwaters_ has quit IRC09:42
gtristanso, what happens when you have 2 systems which want to include GTK+, but one of them wants to install cracklib before compiling shadow09:42
gtristanand the other does not09:42
*** paulw has joined #baserock09:42
gtristanthese are seemingly unrelated, and in this case not really related09:42
gtristanbut, its quite possible that a GTK+ compiled against a foundation which includes cracklib, is suddenly a different GTK+ than the one which compiles against another foundation09:42
gtristanand so, we must declare 2 chunk morphs for GTK+09:43
gtristanwith variants of course, the *artifacts* and cache keys are safely different09:43
*** edcragg has quit IRC09:43
gtristanbut one can easily just pull in GTK+, which may be ambivalent about one of it's dependencies09:44
gtristanthe moment we have a differing GTK+, *everything* which depends on one GTK+ morph must be duplicated for the other09:44
persiaI still have that problem with variants, as I need to adjust the variant in every depending definition.09:45
gtristanthat is untrue09:45
gtristanbecause of ambivalence09:45
* persia rereads the proposal09:46
gtristanmost, if not all things which depend on GTK+, do not care which variant of GTK+ is used09:46
gtristanand so they simply depend on GTK+ ambivalently09:46
persiaRight, but if they are not forcing a specific variant, how does a system builder enforce it?09:48
gtristanAs richard points out, it's logical that higher level morphs break any ties09:48
persiaLooking at the proposal, I see examples of how to assert that some variant of some component requires some variant of some dependency, but not how to choose at a higher level.09:48
gtristan(richard maw, there is more than one richard :) )09:49
persiaSo, my presumption is that I need to enforce this along the way if I want to force some variant.09:49
*** jonathanmaw has joined #baserock09:51
gtristanpersia, to clarify then: The first declared variant is default if no variants have been depended on, and the highlevel system morph has a higher priority when selecting a variant, in the odd case where some chunks may agree on 2 acceptable variants - if there is a conflict on the selected variants, or an undecided tie; this produces a build error09:52
persiaRight, so presume you and I are building identical systems, excepting that I want cracklib and you do not.09:53
gtristanthen you would want shadow to depend on it in a variant09:54
persiaWhat is the variance expected in the system definition to indicate that?09:54
gtristanbecause you need cracklib to be build before shadow09:54
gtristanlets say that originally, there was no cracklib, in that case, the default should remain without cracklib in the shadow morph09:54
gtristandirectly at the system level, one may explicitly say that this system wants a libshadow with cracklib09:55
persiaSo, presuming one wants a minimal system just targeting e.g. LuCI, one's system definition specifies LuCI and then some of the deeper dependencies with the appropriate flavours (e.g. build-essential:musl)?09:56
gtristansure, I am not familiar with LiCI but that sounds about correct09:57
gtristanpersia, honestly I would prefer to remove strata as much as possible and speak only of chunks, but build-essential seems practical to "stratize" so that a chunk may depend on it09:58
gtristanwell, strata can remain and be very useful for simplifying the creation of systems, indeed10:00
persiaHeh, indeed.  For most things, I agree with you.  In the specific case of build-essential, there are too many complexities for me to trust components to specify things usefully themselves.10:00
gtristanjust that we regain all our dependency information if at least "chunks never depend on strata"10:00
persiaIn the special case of build-essential, I think components need to depend on it as a whole, rather than components thereof.10:01
persiaOther than that, I think I agree, except I don't like the terms "chunk" or "stratum" :)10:01
gtristanheh, I wasnt going to start a war and say "lets also rename everything !" but sure :)10:01
gtristan "lets call systems planets instead !"10:02
persiaWe've had that war before.  I think we settled on "component" in the model where we had no strata.10:02
persiaThat said, I've come to believe that is perhaps too simplistic, unless we adopt the components-contain-components model paulsherwood was advocating, if only because of build-essential.10:02
persiaAnd, in practice, one has a variety of toolchain complexes with the same problem.  For instance, it would be handy to depend on "JDK" or "JVM", without trying to understand how those were constructed.10:03
gtristanI would call a chunk a "module" I think10:04
gtristanor, a chunk could be a component, and a strata could instead become a "group"10:04
*** paulw has quit IRC10:05
*** paulw has joined #baserock10:05
gtristansigh... pinyin's makefiles do wget :'(10:06
*** edcragg has joined #baserock10:07
*** ssam2 has joined #baserock10:08
*** ChanServ sets mode: +v ssam210:08
persiagtristan: Which specific component?10:08
*** paulw has quit IRC10:09
*** paulw has joined #baserock10:09
gtristanno, libpinyin10:10
*** mariaderidder has joined #baserock10:16
tiagogomesmm, I think we should make lorry to follow URL redirects properly, so that we don't need to use downstream URL links:
ssam2wow, there are some patches10:24
gtristantiagogomes, wget tracks the URL redirects10:27
gtristantiagogomes, the problem is, *ANY* link I can find on the original site, brings me to a "please wait for your download to start" splash page10:28
gtristanand then some kind of evil JS in the background brings up the download10:28
gtristanthere is just no link you can get to10:28
gtristanhmmm, this seems to be the ultimate link:
gtristanwget receives 40410:32
gtristanbrowser proposes a download10:32
tiagogomesgtristan that link worked for me#10:35
gtristantiagogomes, with wget ? not for me :-/10:35
tiagogomesUsing "curl -L"10:35
tiagogomesdoes wget follow redirects by default?10:35
gtristanmost certainly, I've seen it doing that today a lot10:35
radiofreeit redirects to
gtristanradiofree, beautiful, I'll change the lorry for that straight away10:37
persiaanthy upstream is fairly friendly: it might be worth an email request.10:38
gtristanI'm going to try building libpinyin from the tarball, as I dont know how else to work around the makefile/wget issue10:44
gtristanthoughts ?10:44
*** locallycompact has joined #baserock10:45
persiaMaybe ask happyaron for advice?10:46
persiaIt's 18:47 for him, but he is often around in the evenings.10:47
gtristanwell, the wget is not acceptable, maybe we could treat it as a submodule of sorts, but then, placing the .tar.gz it downloads into the data/ directory is not enough to satisfy the build rule (I tried putting it there manually)10:50
gtristanas the makefile just basically creates a binary thing from it, and the rule is pretty dumb10:51
gtristanit will download it every time :-/10:51
persiaWhat happens if you touch the file before the Makefile runs during the build?10:52
persiagit is known to interact badly with make (overbuilds), but you should be able to touch between git and make to instruct make that things don't need doing.10:53
gtristanThe data file is required, and what it does with the data file is required10:54
gtristanthats the rule anyway10:55
gtristanhmmm, or wait, maybe thats the wrong rule10:55
persiaRight, so you want to touch bigram.db early enough that it thinks it is complete.10:55
gtristan thats better10:56
gtristanwell I dont think so10:56
gtristanI need bigram.db to *actually be the right data*10:56
gtristanuntarring the downloaded file might do the trick10:57
persiaYes, and then touching interpolation2.text to tell it you did that.10:57
gtristanSo what would we do: A.) create a separate lorry for the tarball ... B.) add it as a delta with an added gitmodule.. C.) add some pre-configure-commands to pre-roll in that tarball ?10:59
jjardongtristan: hi, to make clear how you proposal would like, I would explain by an example; how it would like if I want to build a system that support x11, Wayland or both; would it be possible to select that at system level? I think is a good example because you will have chunks with different build options and also different dependencies11:04
*** paulw has quit IRC11:04
*** paulw has joined #baserock11:05
* tiagogomes would prefer delta without added submodule11:05
persiaI think (B) + (C), where (C) is just the `touch` command.11:06
tiagogomesIt seems overkill to create a submodule to just host the tarball contents11:06
persiaOh, yes, except (B) - module11:06
gtristantiagogomes, persia; Ok so my thoughts are these: Whenever we want to build the latest libpinyin, we anyway have to re-apply that same delta against the new libpinyin version manually in the trove, _AND_ we probably normally also want to change that delta, so that it contains the new data tarball which would presumably come with a new release11:08
gtristanWhile the tarball; which is what the maintainer intends downstream people to consume/build, contains an already prepared in-sync data directory11:09
gtristanso... using the git source in this instance is superior... how ?11:09
gtristanjjardon, that would be nice... I've went pretty much off-the-reserve with this proposal already, and have to catch up with GNOME integration11:10
gtristanjjardon, sounds like a presentation which would set me back another day... is it acceptable to fall behind the task at hand that much ? are these hours billable ?11:11
persiagtristan: the git source is superior because 1) we get history, we get automatic updates of upstream showing somewhere.11:12
* tiagogomes agrees, although it will make it harder to update indeed11:13
gtristanpersia, anyone who wants to actually build them has extra leg-work to do because of this (and most probably not with permissions to modify upstream baserock deltas)...11:13
gtristanbut I'm waiting for 2) :)11:13
persiaOh, right.  2) turned out to be irrelevant, and I failed to remove 1)11:13
persiaor maybe 2) was the automatic updates bit.  Hard to say.11:14
gtristanright, unusable automatic updates :-/11:14
* gtristan tried the tarball and it builds really beautifully :D11:14
persiaYes, which is better than silent use of increasingly deprecated components.11:14
gtristanwhat a pleasure to build something that just builds :)11:14
persiaYeah, tarball is easier.11:15
persiaBut currently lorry lacks the ability to watch for new tarballs or update tarball repos sanely, which complicates things considerably.11:15
gtristanI do see the point against silent use of increasingly deprecated components11:15
gtristanhowever in this case, the git brings nothing different here11:15
persiaIt brings unusable updates, which can act as a trigger to make them usable.11:16
gtristantarballs go stale because people dont update them11:16
persiaAnd it gives protection from upstream deciding they don't want to offer a public repo anymore (which has happened before)11:16
gtristanThis sounds like quite a high cost in general, deterring from the actual goal of building a well integrated GNOME system11:22
pedroalvareznice, `git clone` now asks for an user and pass11:24
gtristanlets see, I will give it a shot by redirecting the git origin to a local repo, untarring the data tarball in the data directory and staging a commit with the untarred tarball11:24
gtristansee if it builds11:24
gtristanif it builds, then someone who does have access, can consume the output of a git format-patch of that commit, and add an appropriate delta to
gtristanI guess no input methods for today, though11:26
ssam2pedroalvarez: is that expected?11:26
pedroalvarezssam2: hm.. to be honest, I don't know11:26
pedroalvarezbut at least that means the SSL certificate is in place and working11:30
persiagtristan: The other option is to create a libpinyin-tarball lorry, and to consume that.  It has downsides (mentioned above), but if you are concerned about lack of review bandwidth, it may be better.11:33
gtristanI have already started out on the time consuming path11:34
ssam2pedroalvarez: for github, if I clone then I don't need a password11:34
ssam2pedroalvarez: but if I clone then I do11:35
ssam2presumably I can only push to the latter one11:35
gtristanI will have a `git format-patch` output which needs to be applied to the tip of the 1.2.x branch in baserock's upstream libpinyin11:35
ssam2Git also asks for a password if I try to clone which is really annoying11:35
gtristanby someone with that power-of-god11:35
ssam2i'm happy to annoint you with that power if others agree11:35
ssam2or just apply the patch, if you email it to baserock-dev11:37
gtristanssam2, as was discussed a week or two, there is no formal application or "thing" which I have to do, so all I can say is "yes please" :)11:37
pedroalvarezssam2: i do agree11:38
persiaErm, there is a formal process to getting commit rights to g.b.o: one has to email the list asking for them, and get confirmation by at least two current committers.11:39
*** paulw has quit IRC11:39
persiaThis isn't a high bar, but let's make sure we have the email as a record (since we went to the trouble of establishing the policy last year)11:39
ssam2good point, we should do that11:40
pedroalvarezHm... gerrit has the same behaviour as github, I should investigate why this with our current gitano setup11:42
gtristanssam2, ok I wont attach the patch to a mail to baserock-dev11:43
ssam2well, you can do that too if you want :-)11:43
gtristanssam2, since the patch, I just realized, after the message not getting through...11:43
gtristanis 74MB11:43
ssam2ok, you can't do that11:43
*** paulw has joined #baserock11:45
gtristanOk so I expect there will be fallout from this
gtristanmaybe, maybe not11:59
gtristanorder should be libexif, libexif-nautilus, libarchive, gcab, appstream-glib, gnome-color-manager, gmime, totem-pl-parser, liboauth, libmediaart, libgdata, grilo-plugins12:01
gtristanattempting to merge that in the wrong order will result in non-functional builds, and possibly merge conflicts later12:01
gtristanThe EDS patch should also be applied after the branch merge12:02
gtristanicon cache and d-feet fix wont conflict anything I think12:02
*** franred has joined #baserock12:07
ssam2gerrit does actually enforce ordering, in the mode which we use it12:10
ssam2even though it pretends not to12:10
jmacs12:04 < h01ger> jmac: are there public continous tests of baserock we could12:11
jmacs                link at ?12:11
perryljmacs: according to the deterministic builds wiki there's a prototype for ybd that i believe ssam2 created, but there's nothing continuous being performed at present12:13
perryli'm in #debian-reproducible so i can cross-post my answer there12:14
*** radiofree has quit IRC12:16
*** radiofree has joined #baserock12:16
perrylanyone know how long it would take to build the base/build/devel systems with 8 cores and 16Gb ram? just an estimate could be useful if possible, i know it can be a case of "how long is a piece of string"12:18
paulsherwoodperryl: lots of build logs at
perrylpaulsherwood: thanks!12:19
persiaperryl: Depends on the IO: system builds are largely IO dependent.12:19
Zaraperryl: from scratch or with some things cached? not that I'd be up to date, either way, but might help others narrow it down.12:20
paulsherwoodalso depends on whether gits are pre-cloned, whether build-essential needs to bee built from scratch12:20
paulsherwoodand whether one is using morph or ybd :)12:20
tiagogomesDoes the time to build a system depends on the build tool used?12:21
perryli'd say from scratch; i've been asked in #debian-reproducible as there is some interest in adding builds to their jenkins instance. i would hazard a guess that they'd be looking at ybd if only because the deterministic builds prototype specifies12:22
paulsherwoodperryl: maybe close enough... that was a 4 core machine, pre-existing gits, from scratch12:23
paulsherwoodso you could argue it would be faster on the config you've described, but maybe not twice as fast12:24
perryli've relayed the info; on 4 cores i think the minimal time i've seen is the base systems clocking in at around an hour. i think trove-setup from scratch takes 2-3 hours from scratch on 4 cores also12:28
paulsherwoodtiagogomes: for example morph continues to set max-jobs = 1.5*cores, which in all my tests proves to be slower than max-jobs = cores. there are lots of other optimisations in ybd too12:29
perrylit looks like there's interest in running baserock builds by debian-reproducible! \o/12:30
perryl12:28 < h01ger> perryl: so we easily have the ressources.12:30
perryl       is mostly idle atm, though12:30
perryl                we'll build more archlinux packages on it and fedora too. but it already builds coreboot, openwrt, netbsd and those 50012:30
perryl                archlinux base packages. and look at cpu and ram graphs :)12:30
gtristanssam2, I see... note that the branch was rebased a couple of times12:33
gtristanssam2, so the order in which they appear on the list, is not the order of the branch which went through git review12:33
gtristanwe'll see what happens, I'm pretty sure I crammed in commits before grilo-plugins, originally the branch did not come with all plugins enabled12:34
*** gtristan has quit IRC12:38
ssam2paulsherwood: do you have a link to the research that showed that max-jobs should = cores ? i can't find it in the baserock-dev archives12:39
ssam2oh, sorry, I found it12:40
pedroalvarezright, I know now what was missing for anonymous git clone over https :)12:42
ssam2 fixes max-jobs in morph12:47
*** straycat has left #baserock13:21
*** gtristan has joined #baserock13:26
*** toscalix has quit IRC13:42
*** toscalix has joined #baserock13:42
*** toscalix has quit IRC14:16
gtristanssam2, yay !14:35
gtristanthanks, now... how would I clone a writable pinyin ? git clone ssh:// doesnt seem to get through14:37
SotKmaybe you dont need the /git bit too14:38
gtristanyeah, no need for /git... got it thanks !14:39
gtristanso to stick with the standard...14:40
gtristanI am creating a 'baserock/1.2.x' branch, based on the upstream 1.2.x branch14:40
gtristanto stage the said commit there14:40
gtristangood ?14:41
*** toscalix has joined #baserock14:58
pedroalvarezgtristan: please, if you create branches that you  think are not ready to be used, create a personal branch14:59
gtristanpedroalvarez, sure - I dont expect to be doing that anytime soon15:00
pedroalvarezif you want to push a wip branch to definitions.git, for example..15:01
gtristanyeah I got it, that can come in handy for a complex review :)15:01
gtristanI'll try to get by with gerrit for the GNOME work, though15:02
gtristanno worry :)15:02
gtristanone last lorry for the input methods btw:
jmacsI was trying to get ansible to run continuous/deploy.yaml, as per, and I got this error:
jmacs( is localhost; it pings and you can ssh to it)17:12
*** tiagogomes has quit IRC17:12
*** mariaderidder has quit IRC17:13
ssam2jmacs: try passing -vvvv to ansible17:13
ssam2it should show you the actual error from SSH then17:13
jmacsAh, does it expect passwordless login?17:14
jmacsThat'll be it17:14
* jmacs could probably have worked that out himself17:16
*** ctbruce has quit IRC17:21
*** nowster has quit IRC17:42
*** locallycompact has quit IRC17:43
*** jonathanmaw has quit IRC18:02
*** bashrc has quit IRC18:02
*** ssam2 has quit IRC18:11
*** toscalix has quit IRC18:14
*** edcragg has quit IRC18:24
gtristansadly, chinese, japanese and korean are not working :'(18:33
persiaFont support?18:44
*** edcragg has joined #baserock19:56
gtristanpersia, yes thats the conclusion I came to20:15
gtristanI'll take a nap and tomorrow should be able to have full IM support20:15
persiaDoes this mean I can complain about Alt+Space vs. Ctrl-J vs. Hankaku/Zenkaku?20:17
persia(or does your keyboard have the "Hangul" key?)20:18
gtristanmy keyboard does yes :)20:28
gtristanits right alt here20:29

Generated by 2.15.3 by Marius Gedminas - find it at!