IRC logs for #baserock for Wednesday, 2015-06-24

*** sambishop has quit IRC05:07
*** mike has joined #baserock05:18
*** zoli__ has joined #baserock05:19
*** mike is now known as Guest2726005:19
*** zoli__ has quit IRC05:43
*** Guest27260 has quit IRC05:45
*** Guest27260 has joined #baserock06:00
*** zoli__ has joined #baserock06:14
*** sambishop has joined #baserock06:45
*** fay_ has joined #baserock07:04
*** a1exhughe5 has joined #baserock07:20
*** mariaderidder has joined #baserock07:40
*** sambishop has quit IRC07:58
*** Gest4651 has joined #baserock07:58
*** Gest4651 has quit IRC08:01
*** bashrc_ has joined #baserock08:03
* SotK likes the new changes to Mason08:13
petefothrichard_maw: is either wearing his cloak of invisibility, or WFH08:14
pedroalvarezSotK: :D08:16
pedroalvarezI missed a few things, but I'm going to put the new version soon08:16
*** mdunford has joined #baserock08:17
*** ssam2 has joined #baserock08:30
*** ChanServ sets mode: +v ssam208:30
*** gary_perkins has joined #baserock08:35
*** CTtpollard has joined #baserock08:51
*** jonathanmaw has joined #baserock08:58
*** edcragg has joined #baserock09:07
*** mdunford has quit IRC09:31
* pedroalvarez notices that now distbuild shows the real number of artifacts09:43
pedroalvarezbut now it doesn't count how many has it has already built09:43
pedroalvareze.g. "Need to build 260/260 artifacts"09:43
pedroalvarezbut it didn't start from the beggining09:44
pedroalvarezminour problem compared to the previous one, though :)09:45
*** mdunford has joined #baserock09:48
persiaRearranging the string might solve that.09:54
persiae.g. "Need to build artifact 260 of 260".09:54
* SotK isn't sure how that is any better09:55
ssam2pedroalvarez: that will be a bug in the patches I sent..09:56
pedroalvarezpersia: the thing is that it doesnt need to build 26009:58
ssam2not immediately obvious where the bug is though. the message is sent here:
ssam2and it pretty clearly sets artifact.state to BUILT or UNBUILT based on the cache response, /then/ sends the CacheStatus message based on those values..09:58
ssam2oh, actually the bug is obvious09:59
tiagogomes_is there any particular software that someone would like to see in baserock?10:03
rjekExim, SpamAssassin, ClamAV, Pyzor.10:03
tiagogomes_is there any particular software that someone would like to see in baserock that is not related with email?10:04
rjekScummVM is all I have that is not email-related, sorry.10:05
Kinnisonbind9, dnssec-tools,10:06
persiatiagogomes_: Pascal, Go, and Java compilers, bootstrapped without blobs.  No, the gcc implementations for these languages aren't enough.10:06
persiabind would indeed be lovely.10:06
KinnisonAnd haskell10:06
ssam2tiagogomes_: for infrastructure, Cherokee, HAProxy, and exim would all be useful10:06
persiaFor Haskell, my preference is ghc.10:06
* Kinnison hides10:07
tiagogomes_Go looks interesting, but doesn't need/will need go to compile?10:07
persiaKinnison: Why hide?  Do you have another Haskell compiler you'd prefer?10:07
Kinnisonpersia: I'm hiding from Cherokee10:07
Kinnisonpersia: for haskell, ghc is definitely my preference10:07
*** zoli__ has quit IRC10:07
* rjek wishes people would stop writing self-hosted compilers.10:08
* Kinnison doesn't mind self-hosted compilers, so long as they can cross-prep with a C backend10:08
KinnisonSadly that set is pretty much limited to valac10:08
persiatiagogomes_: That is the fundamental issue with all the languages Kinnison and I named.  There may be ancient versions of codebases that can compile in other languages and be used to compile early versions of interpreters, which can then be used to compile more recent ones, etc.10:08
persiaFor fpc, I know that not to be true, as the early development compiler was a proprietary one.  For Java, we haven't been able to replicate a pure from-gcc build without a blob.10:10
persiaI don't know if anyone has recently investigated ghc or golang10:10
KinnisonI investigated ghc about a year ago10:10
Kinnisonsadly its from-C stuff had atrophied and its cross-compilation support was a tad grindy10:10
rjekFree Pascal is very good, but it has *always* been written in Pascal.10:11
rjek(Originally built using Borland Turbo Pascal)10:11
persiarjek: Yes, but it used to be possible to compile fpc with non-fpc.  I do not believe this to still be true.10:11
rjekAnd I don't think gcc's Pascal compiler can build stuff written in Borland's dialect to let you bootstrap.10:11
KinnisonAnyway, Cherokee is a nice httpd and its inclusion in baserock would be good10:12
KinnisonJust don't expect upstream to respond nicely10:12
* Kinnison is grumpy today10:12
KinnisonThen again, Stefan likely will respond -- he's much nicer than I am10:13
persiaIf we restricted lorries only to upstream projects where upstream had expressed a willingness to resolve problems we report, we'd have a much smaller set of software available.10:13
ssam2i've redeployed the frontend (haproxy) system at to be Fedora 21 instead of Fedora 20. Let me know if any infrastructure is suddenly broken10:15
ssam2about compilers, it seems pretty clear we're going to have to make the bootstrapping requirements for Baserock systems more complex. e.g. 'the build-system can be built anywhere you have a C compiler plus these tools'; 'the java-system can be built anywhere you have everything needed for the build-system plus a Java compiler', etc10:17
ssam2seems ugly, but the alternative of making everything bootstrappable from C seems impossibles10:17
pedroalvarezthen we will end up releasing a java system, and a pascal system, and so on10:21
persiaThis makes integration hard.10:21
persiaHow large would we need to make a development system to include C, Pascal, Java, Haskell, and Go?10:22
rjekContribute C backends to all the languages :)10:22
*** lachlanmackenzie has joined #baserock10:22
persiaSome upstreams are actively unsupportive of that (fpc, golang), others don't want to maintain it (ghc, Java)10:23
* rjek is left with rewriting all software in C.10:23
rjekWhich isn't ideal either10:23
persiaRight, hence my query about size.10:23
ssam2persia: we could just provide instructions of how to use the upstream binaries that projects provide in order to bootstrap them10:24
persiaI don't like blobs, but if we do the bootstrap from blobs in a repeatable and declarative manner, then publishing a system supporting those bootstraps is a useful service.10:24
ssam2if the upstream project is unbootstrappable but doesn't provide binaries either, I think they are too unhelpful for us to care about10:24
persiassam2: The problem is new / different architectures.10:25
ssam2I think that's their problem, again10:25
ssam2as long as our inclusion of such flawed compilers doesn't affect the portability of the rest of the software we built in Baserock, I don't think we should worry about it10:26
persiaIt's an adoption problem.  If the upstreams are supported by distros, and developers expect it to work and write useful software in those languages, then people who use those distros may not be able to use Baserock.10:26
ssam2if it's supported by a distro for a given architecture, we have a blob we can use to bootstrap10:27
ssam2this discussion feels like the exact inverse of one that we had about this time last year :-)10:27
persiaDistro architecture support changes over time.10:27
persiaA recent example being BE POWER, where it used to be that everyone supported it, and now very few support it.10:28
persiaAs a result, if we aren't maintaining the bootstrapped blob, it becomes unavailable to users over time.10:28
ssam2I guess... but again, if people want to use Java on BE POWER and we can't built it for BE POWER because of the way Java is written, I think that's a problem for the Java folk to solve10:28
persiaA less recent example is that Java used to be bootstrappable, but the code that was used to bootstrap has bitrotted, so it is no longer bootstrappable from C, even with the old code.10:28
ssam2not that we can't help them solve it, but we shouldn't try to move the problem into Baserock10:29
persiaMy points are 1) that we *can* often build any given self-hosting compiler for any of our architectures today (but that it is hard to promise users they can continue to do so in the future, complicating long-term maintenance), and 2) that if the process for getting working self-hosting compilers requires users to maintain their own development system forks, we can't expect anyone to use our reference development system (currently an assumption for a10:30
persia number of our transitions).10:30
persiaI don't understand why these aren't Baserock problems, or why the relevant upstream projects should care about our specialised needs.10:31
tiagogomes_re Java. Can't you build openjdk with GCJ?10:34
persiatiagogomes_: no.  You could build ecj with gcj, and then use that to get to OpenJDK, but that doesn't work anymore.10:42
ssam2persia: the bit that confuses me is your saying "our specialised needs." I don't have any specialised needs, myself10:45
ssam2i'm quite happy with x8610:45
ssam2well, ARM is nice too. but you get my point -- i've little interest in spending time making sure things work on obscure architectures, although I like that it's possible10:46
ssam2and it's clearly decisions by the upstream project (deciding not to have their implementation be bootstrappable from C, and/or deciding not to care about cross-compiling to those architectures) that cause problems for people who want to use those projects on unusual architectures10:48
*** zoli__ has joined #baserock10:49
persiassam2: "Our specialised needs" being an apparent unwillingness to host blessed blobs that are not trivally bootstrappable.10:49
persiaThere are good and valid reasons for this, but I'm not convinced that a random upstream project is likely to care what our project wants, when compared to other consumers of their code.10:50
ssam2I'm proposing that we host blessed blobs for cases like these10:51
ssam2at arm's length.10:51
ssam2but, it will be nice to not be going against the will of the projects which think they are a good idea, for however long it takes them to realise that they aren't a good idea10:52
richard_maw'they' being the blobs, rather than the project10:52
ssam2either ;)10:52
persiaJust as a matter of record, all of baserock depends on such a blob model.  We can't start without a C compiler.10:57
persiaThat we chose C is arguably a choice that directly discriminates against the other projects.10:57
persiaAnd for C, we do host the blessed blobs, and distribute them in our development system.10:58
persiaI think we've a bit of work to justify why we don't want to do that for other environments.10:58
persiaAnd as such, I wonder if it isn't easier to just include all of them in our development systems.10:59
ssam2the 'blessed blobs' being the 'build' system images at ?11:01
persiaThat contains a blessed binary C compiler, yes.11:02
persiaWell, to be fair, an entire C-based toolchain.11:02
persiaMost of the rest of it was built from source, so avoids the need to be blessed.11:03
richard_mawthough morph isn't picky about who blessed the C toolchain, so long as someone has11:03
ssam2is there a usable free software kernel and userland written in a language that we don't treat in the same way we treat C?11:03
ssam2I think treating C specially is justifiable because Linux and GNU are written in it11:03
persiaRight.  I don't assert morph should be picky about who blessed fpc, ghc, etc.  Just that we should expect someone to have blessed it, and provide blessed versions.11:04
persiaNot all of GNU is in C, but I can see that argument.  There are kernels and runtimes that are written in other languages, but last I checked morph expects to be building linux systems in ways that are hard to detangle.11:05
persiaWhere I'm more uncertain is why e.g. ghc upstream cares that we're only treating C specially.11:06
persiaOr, for that matter, why they should treat C as special when they are Haskell folk, and may not be comfortable (or even knowledgeable) in C.11:07
ssam2persia: I think that if we want GHC we should treat it specially too11:08
ssam2persia: but I think we should treat it separately, so that people who don't use GHC don't get limited by its portability constraints11:09
persiassam2: OK.  Can you think of any reason not to treat Java, Python, Go, and Haskell as special and include them in the reference build systems?11:09
ssam2persia: I think we should do that. But I don't think we should put them in 'build-system-x86_64.morph'11:10
persiaHrm.  How do we avoid end-users needing to fork their own build systems then?11:10
ssam2'java-system-x86_64', 'go-system-x86_64', 'haskell-system-x86_64', ...11:10
persiaWhat if I want Java and Go?11:10
ssam2the composability of strata theoretically makes this easy11:11
ssam2the reference systems are examples, after all11:11
ssam2to be honest, putting them all in 'devel-system-x86_64' would be fine, as long as we continue not to release that11:11
persiaSo I need to maintain my own reference system?11:11
persiaHow can I build it, if I don't have a build system with the blessed blobs?11:11
ssam2someone needs to maintain it, I'm not going to do it for you11:11
ssam2unless I'm hired to of course :)11:12
persiaThat part goes without saying :)11:12
ssam2as someone who makes releases, i would stop doing them if I suddenly had to care about GHC, Java and Go just to make releases11:12
ssam2unless someone had made it really easy to make releases with all those systems in11:13
SotKssam2: +111:13
persiaIf there were blessed blobs in the default reference build system, such that you had the blobs to build each release, would you consider that being easy?11:14
SotKit took me more than a day to do 15.25, I wouldn't want to suddenly have vastly more to do on top of what I did11:14
ratmice___well, there is concern that given some binary blob for one arch/libc variation, or it introduces some disjointedness11:14
ssam2persia: depends how often each of them broke11:14
ssam2but I think I see your point better suddenly11:15
persiaratmice___: How do you mean?  Also, for non-C and non-C hosted, why libc?11:15
persiassam2: Oh yes, when the compilers break, that's annoying.  I presume that in most cases one would revert the commits that broke the compiler and just build the old compiler known to be self-hosting on the blessed blob.11:16
persiaAnd then it becomes an upstream bug: "foo-X can't build foo-X+1, breaking bootstrapping.  Please tell another bootstrapping story."11:16
persiaAnd, for architecture support variations, I think the right answer is to not include runtimes in the build-arch.morph files if they are unsupported by that arch.11:17
persiaAs they become supported, they can be added there.11:17
ssam2ok, I think I'm OK with this other than the fact that 'build' may become huge11:18
persiaThat's the core of my original question: how big would we expect 'build' to get if we expand from "C" to "C, Java, Pascall, Haskell, Go"?11:19
persiaIf one of those is particularly large, and particularly unpopular, then maybe we have some rationale to use to talk to upstream about why they are getting less support, and how they can help resolve that.11:20
ssam2I think i'd still like to have a 'build-c' system in this case though. It's just a kind of gut feeling that we *should* continue to treat C specially.11:24
richard_mawI think the limit of treating it specially should be that build-essential is C, but we have separate java-bootstrap, pascal-bootstrap, haskell-bootstrap and go-bootstrap strata11:25
richard_mawand all the foo-bootstrap strata can depend on build-esential for sufficient shell utilities to be able to invoke the build11:26
ssam2fair enough11:28
* paulsher1ood thought jmacs did build java?11:28
persiaMy only concern is that this applies to linux systems.11:28
persiapaulsher1ood: Not without a blob.11:28
persiaFor systems that don't depend on the C toolchain to build at all, C isn't build-essential.11:28
paulsher1oodand the go implementation we have is not good enough somehow?11:29
ratmice___persia: because binaries for different c runtime from libc.. It probably sits more on the OS side of things than people would typically consider I guess, if morph can't build a blessed binary _somehow_, you are reliant on upstreams ability to port it, not sure how be it something like treb, or some mechanism for mounting images, I just concerned when I see it consuming rather than producing images11:29
persiaBut that's a implementation detail for folk building those systems in the future.11:29
* ratmice___ likes how ellcc looks11:29
richard_mawpersia: true, but bootstrapping up a shell is intertwined with C, and you need a shell to invoke the builds of other languages' toolchains11:30
ratmice___I think it comes with qemu and stuff so it can even bootstrap itself under emulation :)11:30
persiarichard_maw: Depends on the OS: there are OSes written in Pascal and Java that have other ways to spawn jobs, but yes.11:30
ssam2persia: I'm confused that you say 'not without a blob', when I thought we agreed that blobs will be necessary, and they will be in the build-system11:31
persiaSo, suitably informed, I'm +1 to richard_maw's model11:31
persiassam2: We did.  Part of why I developed the opinion that I brought to this discussion was the results from jmacs' work on Java.11:31
ssam2ah, right11:31
persiaratmice___: Ah, so arbitrary compilers that need to interact with Linux end up using a C ABI to do so, such that all languages are essentially dependent on the C toolchain implementation?11:33
ratmice___persia: yeah, like the MLWorks compiler, they have binaries for it, and the source code :), but any way at rebuilding it has been an effort, so I don't think there is any linux port, even though there do actually exist commercial binaries for linux somewhere :)11:36
ratmice___someone had to go back i believe and rebootstrap it with the smlnj compiler that it was initially bootstrapped from11:37
paulsher1oodrichard_maw: what about stage1-bootstrap, stage2-bootstrap, then c-bootstrap, then the other languages?11:39
persiaratmice___: Aha.  I suppose we'll end up doing a few of those as we improve our blessing process.  Thanks for the warning.11:40
ssam2seems clear (also stage1-c-bootstrap and stage2-c-bootstrap might be clearer still)11:40
persiaI like stageN-c-bootstrap11:40
richard_mawpaulsher1ood: not possible, the result of a bootstrap stratum must contain chunks that aren't built in bootstrap mode11:41
richard_mawso you can't do stage111:41
persiaBut the point that we're using linux, means that it's really a "bootstrap", not just a C bootstrap, because of ratmice___'s point.11:41
*** pacon has joined #baserock11:42
richard_mawand given the incestuous relationship between libc and /bin/sh, you probably want to keep those two together too11:42
paulsher1oodrichard_maw: so just bootstrap, c-bootstrap or bootstrap-essential for stage1+2?11:43
persiaStack Overflow seems to share the opinion that there are no POSIX shells implemented in non-C11:43
richard_mawpaulsher1ood: let me check something first.11:44
richard_mawpaulsher1ood: stage1, stage2 and stage3 all need to be in the same stratum unless we want to re-work how we define a stratum's products11:45
persiaI think we can safely separate the languages by strata.  Just have strata for each runtime, each of which starts with bootstrapping, based on a minimal set of blessed binaries included in build systems.11:54
persiaAnd then we can just leave the build-essential stack as it is today.11:54
ssam2got that tiagogomes? :)12:01
* richard_maw pushes another version of
richard_mawthis one should have proper caching, though I had to throw away the memoise implementation for some more wrapper objects12:33
*** mdunford has quit IRC12:39
*** mdunford has joined #baserock12:51
*** pacon has quit IRC13:03
*** mdunford has quit IRC13:11
jonathanmawI'd like to be able to ssh into to look at why my build isn't using the cached artifacts radiofree uploaded13:15
jonathanmawI suspect it's because I'm using the wrong version of morph, but I don't think I can work out which version of morph it was without looking at the cached artifacts.13:16
SotKISTR radiofree uploaded artifacts to rather than, but I may be wrong13:16
jonathanmawah, I have access to I'll see what I can find.13:17
pedroalvarezjonathanmaw: if they were uploaded to g.b.o, you have to remove from your morph.conf13:18
pedroalvarezbut nothing seems to habe been uploaded on 2015 to g.b.o cache13:19
jonathanmawpedroalvarez: I see files on g.b.o in the cache that were created June 17th 201513:21
pedroalvarezmeh, I'd like to know how you found them13:21
jonathanmaw`ls -lt /home/cache/artifacts | head` on g.b.o13:22
* pedroalvarez facepalms13:23
*** mdunford has joined #baserock13:24
pedroalvarezI didn't know that `ls` doesn't show the year when it was created on the current year13:24
tiagogomes_Is it possible to start an interactive shell in replacement of the current program using cliapp.runcmd? I can do it with subprocess.13:29
Kinnisongiven that under the hood runcmd is subprocess.Popen, I'd expect so13:29
tiagogomes_experimentation suggests otherwise13:30
*** mdunford has quit IRC13:31
*** mdunford has joined #baserock13:35
KinnisonFind and ask the cliapp author?13:35
persiaTo avoid the need to SSH, can we expose the cache filesystem in some way for debugging?13:37
ssam2persia: morph-cache-server is probably the best way to do that, if someone is interested in doing it. it already runs on and (on port 8080) and provides an API for performing operations on the cache13:38
persiajonathanmaw: For your debugging, what extensions would you need to the morph-cache-server API?13:38
ssam2tiagogomes_: if you want to replace the current program, surely you want execl() rather than subprocess.Popen() or cliapp.runcmd() ?13:38
*** mdunford has quit IRC13:47
jonathanmawpersia: To do it without SSHing in, I'd have to be able to ask the cache server which artifacts were created within a certain date range, which is really only necessary for troubleshooting, where you'll be in contact with someone who has access to the cache server, anyway13:47
richard_mawtiagogomes_: If you want the shell to be useable properly the first step is to make runcmd not replace the file descriptors. Set stdin=None, stdout=None and stderr=None13:50
tiagogomes_ssam2 maybe. I am exploring the possibility of based in some flag, make morph drop into the chroot environment to debug an build failure13:50
ssam2i see, cool. for me, just printing out a suitable command that I can copy n paste would be enough13:53
ssam2bonus points if you can solve it for distbuild ;)13:53
pedroalvarezheh, that would be a lot of bounus points13:53
richard_mawspawn an sshd in the chroot on a random port and copy the public key from the caller into its authorized_keys13:55
tiagogomes_ssam2 that was my original plan. But after I seeing the length of the command that morph uses to chroot I gave up of the idea. The command even has shell script embedded.13:55
ssam2true.. to reproduce the chroot exactly is a long cmdline13:56
ssam2i'd like to replace that part of the code with
ssam2but that would make it harder still to paste a commandline13:57
richard_mawhmm, parhaps we ought to see if we can get the logic for whitelisting writable paths into linux-user-chroot, but sandboxlib includes a nice change that should make it possible to get rid of the embedded shell script AIUI13:57
ssam2the only blocker to using sandboxlib in Morph is that there needs to be a way of either running a pipeline, or piping stdout and stderr into more than 1 place13:57
ssam2i was having a look at the 2nd option, so we wouldn't have to create a pipeline with `tee` any more13:58
richard_mawssam2: you're in asyncore/asynchat territory there, we might be able to re-use some of the code we used for write extensions there13:59
ssam2way ahead of you ;)13:59
ssam2just trying to write some tests for it13:59
persiajonathanmaw: Unfortunately, the ops team doesn't have 24 hour coverage, so many users end up not being able to ask that sort of thing from a human.  Would being able to get a list of all the artifacts with creation dates be sufficient, for local filtering?13:59
* richard_maw would prefer porting to python 3.4 and using asyncio13:59
ssam2i'd rather sandboxlib stayed usable by python 2.7 for the time being, otherwise that'd be great14:00
SotKssam2: cliapp.runcmd() runs a pipeline if you give it more than one list (e.g. `cliapp.runcmd(cmd1, cmd2)`)14:00
* SotK may be misunderstanding the problem14:01
richard_mawSotK: sandboxlib does not use cliapp14:01
richard_mawssam2: may be of interest then14:01
SotKah, the problem is in sandboxlib... I was indeed misunderstanding the problem then14:03
jonathanmawpersia: it'd be sufficient (alongside knowing how to use this API). I had some concerns about whether that'd be open to abuse, but sending the whole file list would come to about 4Mb, whereas individual files can come to up to 400Mb.14:06
*** mdunford has joined #baserock14:18
*** petefoth has quit IRC14:23
*** mdunford has quit IRC14:23
*** mdunford has joined #baserock14:23
richard_mawhas anyone got a few moments to look over ? It'd be nice to get a couple of months old change merged.14:31
richard_mawIt mostly looks fine, but SotK may have opinions, since it adds a write extension.14:34
* SotK takes a look at it14:35
*** benbrown1 is now known as benbrown_14:39
richard_mawhrm, pushing a new version of a patch to gerrit isn't sufficient to change its owner15:05
richard_mawmy google bubble does not allow me to search for documentation on how to change an aspect of a change in gerrit15:12
richard_mawKinnison: I saw that one, that's about pushing a new change as someone else, the title is misleading.15:14
Kinnisonmaybe ssam2 can do it as a gerrit admin15:15
ssam2why do you need to change the owner?15:17
ssam2google bubbles can be fixed by using duckduckgo ;)15:17
richard_mawbecause straycat is no longer working on those changes, and I promised I'd adopt them15:18
ssam2right. maybe abandon and resubmit as yourself?15:18
ssam2hmm, in fact you might need an admin to abandon them. I can do that. I'd rather not poke around in Gerrit's internals though15:19
*** zoli__ has quit IRC15:19
richard_mawright, I'll google around a bit more to see if there is anything, but if not I'll submit them as new changes and let you or another admin know which ones need to be abandoned15:20
richard_mawhrm, there's no magic %foo=bar option on push either15:24
* richard_maw begins resubmission15:25
richard_mawbah, wrong window15:26
*** gary_perkins has quit IRC15:27
richard_mawKinnison: Yes, one bad submission per river.15:27
Kinnisonsounds uncomfortable15:27
* richard_maw generates a new gerrit password15:29
richard_mawhm, don't have time to rebase all the changes properly, so I'll jut re-submit those for now15:40
richard_mawI don't know why gerrit generates passwords that have a / in them, but I get authentication failures when trying to use them15:42
* richard_maw laughs maniacally as he cherry-picks a change to a write extension in morph, into definitions.git15:47
* rjek steps away15:47
*** a1exhughe5 has quit IRC15:48
*** jonathanmaw has quit IRC16:01
*** mdunford has quit IRC16:03
richard_mawssam2: I've adopted All in and
richard_mawI understood that SotK offered to adopt (The patch-set of the beast!)16:12
* SotK thought that perryl offered to do that, but might be misremembering16:12
richard_mawI think must have come in after I offered to adopt things, as I don't have sufficient understanding to import to adopt
richard_mawSotK: I could easily be mistaken16:13
perrylyes, i've adopted 66616:13
* pedroalvarez now gets "the patchset of the beast" when thinking about doing the same joke16:15
perrylspeaking of, having looked at patchset 666, the comments mention reading in the database path and database age from a config file. is there a defined way of doing this, or should i just create a distbuild.conf file, check it exists and if so parse in the files?16:17
SotKmaybe put them in morph-controller.conf?16:18
ssam2richard_maw: so should I abandon all the patch sets you linked to now?16:19
richard_mawssam2: yes please16:19
perrylSotK: is there a morph-controller.conf? i'm looking at the distbuild page and it only mentions setting up morph.conf16:24
SotKperryl: yeah, I think the distbuild configure extension creates it16:24
pedroalvarezshould be in install-files/distbuild16:25
perrylthanks, i'll check16:25
paulsher1oodssam2: does abandonment dstroy the work? i hope we can still use it if/when?16:26
SotKpaulsher1ood: you can still see abandoned changes16:26
paulsher1oodSotK: i guess i mean, are we keeping such work in branches anywhere, eg on g.b.o?16:26
SotKpaulsher1ood: I *assume* you can still get the work from gerrit using git-review or such tools, but I haven't tried it.16:27
SotKthe changes definitely still exist, so I don't see why it wouldn't work16:27
pedroalvarezit should be possible, and you can recover also recover them16:28
richard_mawalso, I explicitly made sure that I pushed my own version of the patches that ssam2 is abandoning16:28
paulsher1oodah, ok, thanks :)16:28
*** mariaderidder has quit IRC16:29
paulsher1oodssam2: so an example use-case of the many-definitions-versions problem - there are many versions/flavours of OpenWRT - how would we practically describe the many different versions, all as first-class citizens, run ci on some/all, compare them, take bits from one combine them with another etc16:34
paulsher1ood(while dealing with schema changes)16:34
rdalei'm very interested in this16:36
paulsher1oodrdale: me too.. .do you have any potential solutions? :)16:37
rdalewell 'being interested' is i feel a good first step16:38
ssam2paulsher1ood: ok, thanks for that16:39
paulsher1oodrdale: is there a definitions branch with a MIPS openWRT example system anywhere?16:47
rdaleno, nowster has that on github16:48
rdale openwrt-musl branch16:49
pedroalvarezwe can call that a definitions branch too16:50
* paulsher1ood can't find the actual system definition in that16:51
rdalelook for edgerouterpro16:52
pedroalvarezsystems/build-system-mips32l.morph ?16:52
*** bashrc_ has quit IRC16:52
*** Guest27260 has quit IRC16:54
paulsher1oodrdale: would be great to get that tidied up, work with latest deployments etc? all those configure scripts in the root dir look really messy now :)17:07
rdalei hadn't noticed the configure scripts. i've sent nowster's patch series for mips/openwrt/musl to our internal dev list so that we can discuss how best to get it merged into the baserock definitions master. unfortunately nowster is off on leave and i don't want to do anything without discussing it with him17:10
*** ssam2 has quit IRC17:15
*** edcragg has quit IRC17:24
*** fay_ has quit IRC17:40
*** lachlanmackenzie has quit IRC17:40
persiardale: My recommendation would be to clean things and submit upstream.  The existing branch can remain, so nothing is lost.  If a wrong choice is made, it can be fixed in a later update.18:28
persiaWaiting indefinitely to submit something because it might not be right is somewhat counterproductive, as without undergoing review by the review team, one ends up trying to guess what they might be thinking.18:29
persiaIn my experience, humans tend to have limited capacities for understanding what other humans are thinking in any detail: one may have functional models for the results, but the process is usually opaque.18:30
*** zoli__ has joined #baserock18:46
*** edcragg has joined #baserock20:04
*** zoli__ has quit IRC20:39
*** zoli__ has joined #baserock20:49
*** franred has joined #baserock21:04
*** franred has quit IRC21:34
*** zoli__ has quit IRC22:13
*** edcragg has quit IRC23:45

Generated by 2.14.0 by Marius Gedminas - find it at!