| *** edcragg has quit IRC | 01:17 | |
| *** gtristan has quit IRC | 04:22 | |
| *** gtristan has joined #baserock | 04:52 | |
| paulsherwood | gtristan: if not get_cache(defs, this) and this.get('kind') != 'cluster': | 07:18 |
|---|---|---|
| paulsherwood | app.config['tasks'] += 1 | 07:18 |
| paulsherwood | bah | 07:18 |
| paulsherwood | gtristan: WebKitGtk is quite a bottleneck... any chance it can be kicked off lower/earlier? | 07:19 |
| persia | How does one make a build earlier? I thought that we built opportunistically as soon as the build dependency graph permitted. | 07:21 |
| gtristan | paulsherwood, I still have a branch which untangles gnome strata so that WebKitGtk sits outside of it | 07:26 |
| gtristan | persia, problem is that if *anything* below gnome.morph changes, *everything* in gnome.morph rebuilds | 07:27 |
| gtristan | including, of course, webkit :) | 07:27 |
| persia | gtristan: Ah, right, strata :( | 07:27 |
| gtristan | oh btw, I got to the bottom of broken lorry today: https://gerrit.baserock.org/#/c/1411/ | 07:27 |
| gtristan | my whole branch depends on that being fixed... can I get some +1s ? | 07:28 |
| gtristan | thanks jjardon :) | 07:52 |
| jjardon | gtristan: no, thank you! | 07:54 |
| gtristan | I just ran the lorry locally and the stack trace told me | 07:58 |
| gtristan | honestly, by eye I wasn't going to find it :) | 07:58 |
| gtristan | tonight we should have input methods :) | 07:59 |
| *** paulwaters_ has joined #baserock | 08:30 | |
| *** tiagogomes has joined #baserock | 08:34 | |
| *** CTtpollard has joined #baserock | 08:54 | |
| *** CTtpollard has quit IRC | 08:59 | |
| *** CTtpollard has joined #baserock | 08:59 | |
| *** CTtpollard has joined #baserock | 09:00 | |
| *** bashrc has joined #baserock | 09:01 | |
| *** CTtpollard has quit IRC | 09:01 | |
| *** CTtpollard has joined #baserock | 09:01 | |
| paulsherwood | persia: https://raw.githubusercontent.com/devcurmudgeon/build-logs/master/ci.15-45.x86_64.log | 09:13 |
| paulsherwood | WebKitGtk 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:33 | 09:15 |
| *** ctbruce has joined #baserock | 09:15 | |
| paulsherwood | so pruning WebKitGtk dependencies would improve this i think | 09:16 |
| persia | Yes, 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 |
| persia | As 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 |
| paulsherwood | exactly | 09:17 |
| paulsherwood | i'm only citing this as a practical example to support gtristan's argument | 09:17 |
| paulsherwood | s/only/mainly/ | 09:17 |
| *** nowster has joined #baserock | 09:17 | |
| *** toscalix has joined #baserock | 09:17 | |
| gtristan | jjardon, ... in relation to the above discussion, ... I've also been thinking about that decision of creating 'gnome-apps' stratum | 09:18 |
| gtristan | jjardon, maybe we should just add a fat comment at the (current) bottom of gnome.morph ############### Apps here ############# | 09:19 |
| gtristan | and stick the apps near the bottom | 09:19 |
| gtristan | otherwise we will again lose all the dependency information for apps we add to gnome-apps.morph | 09:19 |
| gtristan | thoughts ? | 09:19 |
| persia | paulsherwood: 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 |
| gtristan | as 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 | No. | 09:22 |
| * persia finds an example | 09:22 | |
| *** toscalix has quit IRC | 09:22 | |
| paulsherwood | persia: 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 |
| gtristan | I only started a downstream of debian last year, so I'm a debian newbie :) | 09:22 |
| persia | paulsherwood: I think we should not try to combine different variants of a component into the same definition. | 09:23 |
| persia | Because it causes multi-build issues and/or constrains the set of runtime dependnencies. | 09:23 |
| persia | Rather, 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 |
| gtristan | dependencies can defined on a per-variant basis | 09:24 |
| gtristan | persia, 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 stack | 09:25 |
| *** edcragg has joined #baserock | 09:25 | |
| persia | gtristan: 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 |
| gtristan | if 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 care | 09:27 |
| paulsherwood | which provokes an interesting question... where would we get ABI information from, in general? | 09:27 |
| gtristan | of course, the artifacts would be different, if compiled against mesa-1 or mesa-2 | 09:27 |
| gtristan | the ABI is from the artifact key, I would think | 09:27 |
| persia | yabause 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). https://sources.debian.net/src/yabause/0.9.14-1/debian/ | 09:27 |
| radiofree | it 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 mesa | 09:27 |
| persia | paulsherwood: Most of the ABI is available by object inspection, but some bits aren't encoded. | 09:28 |
| *** toscalix has joined #baserock | 09:28 | |
| radiofree | not 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 |
| persia | gtristan: But, as a system designer, I want to choose what mesa I'm using, etc. | 09:29 |
| persia | I want to be able to compile things with or without various compile options. | 09:29 |
| gtristan | persia, right, the variants allow you to chose that at the system level, while keeping ambivalent chunks which depend on "a version of mesa" in between | 09:29 |
| persia | And 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 |
| persia | gtristan: 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 |
| persia | Which 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 |
| gtristan | this boils down to your preference of duplicating everything for each system, I think. | 09:31 |
| gtristan | Which I wont agrue against really, it's got it's merit | 09:31 |
| gtristan | I just doubt that it's the baserock ethos, which is why I was not going to propose that | 09:32 |
| persia | More, it's a reaction to my pain building systems from debian-format packages. | 09:32 |
| persia | For 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 |
| gtristan | persia, 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 refactor | 09:33 |
| persia | Don't conflate the two: strata distort the dependency graphs in ways that make it hard to do all sorts of things. | 09:33 |
| gtristan | so, 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 |
| gtristan | Well | 09:34 |
| persia | This is independent of whether individual component defintions should contain multiple variants. | 09:34 |
| gtristan | they are the input | 09:34 |
| gtristan | persia, I completely agree | 09:34 |
| gtristan | persia, except that I dont expect baserock to accept any proposal which enforces that every system have duplication | 09:34 |
| persia | The duplication is inherent in the desire to have multiple environments. | 09:35 |
| gtristan | so they are both, decidedly separate requirements, which I set out to satisfy | 09:35 |
| persia | So, for example, we have a build-essential that uses glibc, and we have another that uses musl. | 09:35 |
| persia | Nothing can safely depend on an arbitrary one of these. | 09:35 |
| persia | Some 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 |
| gtristan | persia, 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-dev | 09:37 |
| gtristan | it's much more difficult to have a sensible conversation at this level of depth on IRC | 09:37 |
| persia | For me, the converse is true. I find discussions via email essentially impossible. | 09:38 |
| persia | So I'll point things out when they are mentioned, but otherwise let consensus form elsewhere. | 09:38 |
| gtristan | persia, regarding your last statement, the problem is that many components can be shared at *all levels* in fact | 09:41 |
| persia | May I have an example? | 09:41 |
| gtristan | for instance, GTK+ is quite high up in the stack, low level in terms of desktops, quite high level in terms of an OS | 09:41 |
| *** paulwaters_ has quit IRC | 09:42 | |
| gtristan | so, what happens when you have 2 systems which want to include GTK+, but one of them wants to install cracklib before compiling shadow | 09:42 |
| gtristan | and the other does not | 09:42 |
| *** paulw has joined #baserock | 09:42 | |
| gtristan | these are seemingly unrelated, and in this case not really related | 09:42 |
| gtristan | but, 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 foundation | 09:42 |
| gtristan | and so, we must declare 2 chunk morphs for GTK+ | 09:43 |
| persia | Right. | 09:43 |
| gtristan | with variants of course, the *artifacts* and cache keys are safely different | 09:43 |
| *** edcragg has quit IRC | 09:43 | |
| gtristan | but one can easily just pull in GTK+, which may be ambivalent about one of it's dependencies | 09:44 |
| gtristan | the moment we have a differing GTK+, *everything* which depends on one GTK+ morph must be duplicated for the other | 09:44 |
| persia | I still have that problem with variants, as I need to adjust the variant in every depending definition. | 09:45 |
| gtristan | that is untrue | 09:45 |
| gtristan | because of ambivalence | 09:45 |
| * persia rereads the proposal | 09:46 | |
| gtristan | most, if not all things which depend on GTK+, do not care which variant of GTK+ is used | 09:46 |
| gtristan | and so they simply depend on GTK+ ambivalently | 09:46 |
| persia | Right, but if they are not forcing a specific variant, how does a system builder enforce it? | 09:48 |
| gtristan | As richard points out, it's logical that higher level morphs break any ties | 09:48 |
| persia | Looking 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 |
| persia | So, my presumption is that I need to enforce this along the way if I want to force some variant. | 09:49 |
| *** jonathanmaw has joined #baserock | 09:51 | |
| gtristan | persia, 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 error | 09:52 |
| persia | Right, so presume you and I are building identical systems, excepting that I want cracklib and you do not. | 09:53 |
| gtristan | then you would want shadow to depend on it in a variant | 09:54 |
| persia | What is the variance expected in the system definition to indicate that? | 09:54 |
| gtristan | because you need cracklib to be build before shadow | 09:54 |
| gtristan | lets say that originally, there was no cracklib, in that case, the default should remain without cracklib in the shadow morph | 09:54 |
| gtristan | directly at the system level, one may explicitly say that this system wants a libshadow with cracklib | 09:55 |
| persia | So, 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 |
| gtristan | sure, I am not familiar with LiCI but that sounds about correct | 09:57 |
| gtristan | persia, 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 it | 09:58 |
| gtristan | well, strata can remain and be very useful for simplifying the creation of systems, indeed | 10:00 |
| persia | Heh, 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 |
| gtristan | just that we regain all our dependency information if at least "chunks never depend on strata" | 10:00 |
| persia | In the special case of build-essential, I think components need to depend on it as a whole, rather than components thereof. | 10:01 |
| persia | Other than that, I think I agree, except I don't like the terms "chunk" or "stratum" :) | 10:01 |
| gtristan | heh, 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 |
| gtristan | :D | 10:02 |
| persia | We've had that war before. I think we settled on "component" in the model where we had no strata. | 10:02 |
| persia | That 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 |
| persia | And, 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 |
| gtristan | I would call a chunk a "module" I think | 10:04 |
| gtristan | or, a chunk could be a component, and a strata could instead become a "group" | 10:04 |
| *** paulw has quit IRC | 10:05 | |
| *** paulw has joined #baserock | 10:05 | |
| gtristan | sigh... pinyin's makefiles do wget :'( | 10:06 |
| *** edcragg has joined #baserock | 10:07 | |
| *** ssam2 has joined #baserock | 10:08 | |
| *** ChanServ sets mode: +v ssam2 | 10:08 | |
| persia | gtristan: Which specific component? | 10:08 |
| persia | ibus-pinyin? | 10:09 |
| *** paulw has quit IRC | 10:09 | |
| *** paulw has joined #baserock | 10:09 | |
| gtristan | no, libpinyin | 10:10 |
| *** mariaderidder has joined #baserock | 10:16 | |
| tiagogomes | mm, I think we should make lorry to follow URL redirects properly, so that we don't need to use downstream URL links: https://gerrit.baserock.org/#/c/1414/ | 10:22 |
| ssam2 | wow, there are some patches | 10:24 |
| gtristan | tiagogomes, wget tracks the URL redirects | 10:27 |
| gtristan | tiagogomes, the problem is, *ANY* link I can find on the original site, brings me to a "please wait for your download to start" splash page | 10:28 |
| gtristan | and then some kind of evil JS in the background brings up the download | 10:28 |
| gtristan | there is just no link you can get to | 10:28 |
| gtristan | hmmm, this seems to be the ultimate link: http://osdn.jp/frs/redir.php?m=iij&f=%2Fanthy%2F37536%2Fanthy-9100h.tar.gz | 10:32 |
| gtristan | wget receives 404 | 10:32 |
| gtristan | browser proposes a download | 10:32 |
| tiagogomes | gtristan that link worked for me# | 10:35 |
| gtristan | tiagogomes, with wget ? not for me :-/ | 10:35 |
| tiagogomes | Using "curl -L" | 10:35 |
| tiagogomes | does wget follow redirects by default? | 10:35 |
| gtristan | most certainly, I've seen it doing that today a lot | 10:35 |
| radiofree | it redirects to http://iij.dl.osdn.jp/anthy/37536/anthy-9100h.tar.gz | 10:36 |
| gtristan | radiofree, beautiful, I'll change the lorry for that straight away | 10:37 |
| tiagogomes | mm | 10:38 |
| persia | anthy upstream is fairly friendly: it might be worth an email request. | 10:38 |
| gtristan | I'm going to try building libpinyin from the tarball, as I dont know how else to work around the makefile/wget issue | 10:44 |
| gtristan | thoughts ? | 10:44 |
| *** locallycompact has joined #baserock | 10:45 | |
| persia | Maybe ask happyaron for advice? | 10:46 |
| persia | It's 18:47 for him, but he is often around in the evenings. | 10:47 |
| gtristan | well, 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 |
| gtristan | as the makefile just basically creates a binary thing from it, and the rule is pretty dumb | 10:51 |
| gtristan | it will download it every time :-/ | 10:51 |
| persia | What happens if you touch the file before the Makefile runs during the build? | 10:52 |
| persia | git 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 |
| gtristan | The data file is required, and what it does with the data file is required | 10:54 |
| gtristan | persia, http://paste.baserock.org/uricasiwig | 10:54 |
| gtristan | thats the rule anyway | 10:55 |
| gtristan | hmmm, or wait, maybe thats the wrong rule | 10:55 |
| persia | Right, so you want to touch bigram.db early enough that it thinks it is complete. | 10:55 |
| gtristan | http://paste.baserock.org/elugocasib thats better | 10:56 |
| gtristan | well I dont think so | 10:56 |
| gtristan | I need bigram.db to *actually be the right data* | 10:56 |
| gtristan | untarring the downloaded file might do the trick | 10:57 |
| persia | Yes, and then touching interpolation2.text to tell it you did that. | 10:57 |
| gtristan | So 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 |
| jjardon | gtristan: 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 dependencies | 11:04 |
| *** paulw has quit IRC | 11:04 | |
| *** paulw has joined #baserock | 11:05 | |
| * tiagogomes would prefer delta without added submodule | 11:05 | |
| persia | I think (B) + (C), where (C) is just the `touch` command. | 11:06 |
| tiagogomes | It seems overkill to create a submodule to just host the tarball contents | 11:06 |
| persia | Oh, yes, except (B) - module | 11:06 |
| gtristan | tiagogomes, 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 release | 11:08 |
| gtristan | While the tarball; which is what the maintainer intends downstream people to consume/build, contains an already prepared in-sync data directory | 11:09 |
| gtristan | so... using the git source in this instance is superior... how ? | 11:09 |
| gtristan | jjardon, that would be nice... I've went pretty much off-the-reserve with this proposal already, and have to catch up with GNOME integration | 11:10 |
| gtristan | jjardon, 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 |
| persia | gtristan: 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 indeed | 11:13 | |
| gtristan | persia, 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 |
| gtristan | but I'm waiting for 2) :) | 11:13 |
| persia | Oh, right. 2) turned out to be irrelevant, and I failed to remove 1) | 11:13 |
| gtristan | heh | 11:13 |
| persia | or maybe 2) was the automatic updates bit. Hard to say. | 11:14 |
| gtristan | right, unusable automatic updates :-/ | 11:14 |
| * gtristan tried the tarball and it builds really beautifully :D | 11:14 | |
| persia | Yes, which is better than silent use of increasingly deprecated components. | 11:14 |
| gtristan | what a pleasure to build something that just builds :) | 11:14 |
| persia | Yeah, tarball is easier. | 11:15 |
| persia | But currently lorry lacks the ability to watch for new tarballs or update tarball repos sanely, which complicates things considerably. | 11:15 |
| gtristan | I do see the point against silent use of increasingly deprecated components | 11:15 |
| gtristan | however in this case, the git brings nothing different here | 11:15 |
| persia | It brings unusable updates, which can act as a trigger to make them usable. | 11:16 |
| gtristan | tarballs go stale because people dont update them | 11:16 |
| persia | And it gives protection from upstream deciding they don't want to offer a public repo anymore (which has happened before) | 11:16 |
| gtristan | This sounds like quite a high cost in general, deterring from the actual goal of building a well integrated GNOME system | 11:22 |
| pedroalvarez | nice, `git clone https://git.baserock.org/git/baserock/baserock/definitions.git` now asks for an user and pass | 11:24 |
| gtristan | lets 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 tarball | 11:24 |
| gtristan | see if it builds | 11:24 |
| gtristan | if 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 git.baserock.org...libpinyin | 11:25 |
| gtristan | I guess no input methods for today, though | 11:26 |
| ssam2 | pedroalvarez: is that expected? | 11:26 |
| pedroalvarez | ssam2: hm.. to be honest, I don't know | 11:26 |
| tiagogomes | heh | 11:28 |
| pedroalvarez | but at least that means the SSL certificate is in place and working | 11:30 |
| persia | gtristan: 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 |
| gtristan | I have already started out on the time consuming path | 11:34 |
| ssam2 | pedroalvarez: for github, if I clone https://github.com/... then I don't need a password | 11:34 |
| ssam2 | pedroalvarez: but if I clone https://ssssam@github.com/... then I do | 11:35 |
| ssam2 | presumably I can only push to the latter one | 11:35 |
| gtristan | I 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 libpinyin | 11:35 |
| ssam2 | Git also asks for a password if I try to clone https://github.com/repo-that-doesnt-exist which is really annoying | 11:35 |
| gtristan | by someone with that power-of-god | 11:35 |
| ssam2 | i'm happy to annoint you with that power if others agree | 11:35 |
| ssam2 | or just apply the patch, if you email it to baserock-dev | 11:37 |
| gtristan | ssam2, 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 |
| pedroalvarez | ssam2: i do agree | 11:38 |
| persia | Erm, 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 IRC | 11:39 | |
| persia | This 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 |
| ssam2 | good point, we should do that | 11:40 |
| ssam2 | http://wiki.baserock.org/policies/ | 11:40 |
| pedroalvarez | Hm... gerrit has the same behaviour as github, I should investigate why this with our current gitano setup | 11:42 |
| gtristan | ssam2, ok I wont attach the patch to a mail to baserock-dev | 11:43 |
| ssam2 | well, you can do that too if you want :-) | 11:43 |
| gtristan | ssam2, since the patch, I just realized, after the message not getting through... | 11:43 |
| gtristan | is 74MB | 11:43 |
| ssam2 | ok, you can't do that | 11:43 |
| ssam2 | heh | 11:44 |
| *** paulw has joined #baserock | 11:45 | |
| tiagogomes | :) | 11:47 |
| gtristan | Ok so I expect there will be fallout from this https://gerrit.baserock.org/#/q/topic:color-manager-and-grilo-plugins | 11:59 |
| gtristan | maybe, maybe not | 11:59 |
| gtristan | order should be libexif, libexif-nautilus, libarchive, gcab, appstream-glib, gnome-color-manager, gmime, totem-pl-parser, liboauth, libmediaart, libgdata, grilo-plugins | 12:01 |
| gtristan | attempting to merge that in the wrong order will result in non-functional builds, and possibly merge conflicts later | 12:01 |
| gtristan | The EDS patch should also be applied after the branch merge | 12:02 |
| gtristan | icon cache and d-feet fix wont conflict anything I think | 12:02 |
| *** franred has joined #baserock | 12:07 | |
| ssam2 | gerrit does actually enforce ordering, in the mode which we use it | 12:10 |
| ssam2 | even though it pretends not to | 12:10 |
| jmacs | 12:04 < h01ger> jmac: are there public continous tests of baserock we could | 12:11 |
| jmacs | link at https://reproducible-builds.org/who/ ? | 12:11 |
| perryl | jmacs: 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 present | 12:13 |
| perryl | i'm in #debian-reproducible so i can cross-post my answer there | 12:14 |
| jmacs | Please. | 12:14 |
| *** radiofree has quit IRC | 12:16 | |
| *** radiofree has joined #baserock | 12:16 | |
| perryl | anyone 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 |
| paulsherwood | perryl: lots of build logs at https://github.com/devcurmudgeon/build-logs | 12:19 |
| perryl | paulsherwood: thanks! | 12:19 |
| persia | perryl: Depends on the IO: system builds are largely IO dependent. | 12:19 |
| Zara | perryl: 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 |
| paulsherwood | also depends on whether gits are pre-cloned, whether build-essential needs to bee built from scratch | 12:20 |
| paulsherwood | and whether one is using morph or ybd :) | 12:20 |
| tiagogomes | Does the time to build a system depends on the build tool used? | 12:21 |
| paulsherwood | yes | 12:22 |
| perryl | i'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 specifies | 12:22 |
| paulsherwood | perryl: https://raw.githubusercontent.com/devcurmudgeon/build-logs/master/mbp.build-system.verbose.log maybe close enough... that was a 4 core machine, pre-existing gits, from scratch | 12:23 |
| paulsherwood | so you could argue it would be faster on the config you've described, but maybe not twice as fast | 12:24 |
| perryl | i'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 also | 12:28 |
| paulsherwood | tiagogomes: 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 too | 12:29 |
| perryl | it looks like there's interest in running baserock builds by debian-reproducible! \o/ | 12:30 |
| perryl | 12:28 < h01ger> perryl: so we easily have the ressources. | 12:30 |
| perryl | https://jenkins.debian.net/munin/debian.net/profitbricks-build3-amd64.debian.net/index.html is mostly idle atm, though | 12:30 |
| perryl | we'll build more archlinux packages on it and fedora too. but it already builds coreboot, openwrt, netbsd and those 500 | 12:30 |
| perryl | archlinux base packages. and look at cpu and ram graphs :) | 12:30 |
| gtristan | ssam2, I see... note that the branch was rebased a couple of times | 12:33 |
| gtristan | ssam2, so the order in which they appear on the list, is not the order of the branch which went through git review | 12:33 |
| gtristan | we'll see what happens, I'm pretty sure I crammed in commits before grilo-plugins, originally the branch did not come with all plugins enabled | 12:34 |
| *** gtristan has quit IRC | 12:38 | |
| ssam2 | paulsherwood: do you have a link to the research that showed that max-jobs should = cores ? i can't find it in the baserock-dev archives | 12:39 |
| ssam2 | oh, sorry, I found it | 12:40 |
| ssam2 | http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-September/013264.html | 12:40 |
| pedroalvarez | right, I know now what was missing for anonymous git clone over https :) | 12:42 |
| ssam2 | https://gerrit.baserock.org/#/c/1418/ fixes max-jobs in morph | 12:47 |
| *** straycat has left #baserock | 13:21 | |
| *** gtristan has joined #baserock | 13:26 | |
| *** toscalix has quit IRC | 13:42 | |
| *** toscalix has joined #baserock | 13:42 | |
| *** toscalix has quit IRC | 14:16 | |
| gtristan | ssam2, yay ! | 14:35 |
| gtristan | thanks, now... how would I clone a writable pinyin ? git clone ssh://tristanvb@git.baserock.org/git/delta/libpinyin.git... doesnt seem to get through | 14:37 |
| SotK | ssh://git@git.baserock.org/git/delta/libpinyin.git | 14:38 |
| SotK | maybe you dont need the /git bit too | 14:38 |
| gtristan | yeah, no need for /git... got it thanks ! | 14:39 |
| gtristan | so to stick with the standard... | 14:40 |
| gtristan | I am creating a 'baserock/1.2.x' branch, based on the upstream 1.2.x branch | 14:40 |
| gtristan | to stage the said commit there | 14:40 |
| gtristan | good ? | 14:41 |
| tiagogomes | perfect | 14:41 |
| gtristan | great | 14:41 |
| *** toscalix has joined #baserock | 14:58 | |
| pedroalvarez | gtristan: please, if you create branches that you think are not ready to be used, create a personal branch | 14:59 |
| pedroalvarez | baserock/<username>/foo | 14:59 |
| gtristan | pedroalvarez, sure - I dont expect to be doing that anytime soon | 15:00 |
| pedroalvarez | :) | 15:01 |
| pedroalvarez | if you want to push a wip branch to definitions.git, for example.. | 15:01 |
| gtristan | yeah I got it, that can come in handy for a complex review :) | 15:01 |
| gtristan | I'll try to get by with gerrit for the GNOME work, though | 15:02 |
| gtristan | no worry :) | 15:02 |
| gtristan | one last lorry for the input methods btw: https://gerrit.baserock.org/#/c/1420/ | 15:40 |
| jmacs | I was trying to get ansible to run continuous/deploy.yaml, as per http://wiki.baserock.org/projects/deterministic-builds/, and I got this error: http://paste.baserock.org/ewohuqanoj | 17:12 |
| jmacs | (192.168.122.176 is localhost; it pings and you can ssh to it) | 17:12 |
| *** tiagogomes has quit IRC | 17:12 | |
| *** mariaderidder has quit IRC | 17:13 | |
| ssam2 | jmacs: try passing -vvvv to ansible | 17:13 |
| ssam2 | it should show you the actual error from SSH then | 17:13 |
| jmacs | Ah, does it expect passwordless login? | 17:14 |
| ssam2 | yes | 17:14 |
| jmacs | That'll be it | 17:14 |
| * jmacs could probably have worked that out himself | 17:16 | |
| *** ctbruce has quit IRC | 17:21 | |
| *** nowster has quit IRC | 17:42 | |
| *** locallycompact has quit IRC | 17:43 | |
| *** jonathanmaw has quit IRC | 18:02 | |
| *** bashrc has quit IRC | 18:02 | |
| *** ssam2 has quit IRC | 18:11 | |
| *** toscalix has quit IRC | 18:14 | |
| *** edcragg has quit IRC | 18:24 | |
| gtristan | sadly, chinese, japanese and korean are not working :'( | 18:33 |
| persia | Font support? | 18:44 |
| *** edcragg has joined #baserock | 19:56 | |
| gtristan | persia, yes thats the conclusion I came to | 20:15 |
| gtristan | I'll take a nap and tomorrow should be able to have full IM support | 20:15 |
| persia | Cool! | 20:17 |
| persia | Does 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 |
| gtristan | my keyboard does yes :) | 20:28 |
| gtristan | its right alt here | 20:29 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!