| *** rdale has quit IRC | 02:34 | |
| *** zoli__ has joined #baserock | 04:13 | |
| *** zoli__ has quit IRC | 05:26 | |
| *** zoli__ has joined #baserock | 05:49 | |
| *** fay_ has quit IRC | 06:41 | |
| *** fay_ has joined #baserock | 06:42 | |
| *** a1exhughe5 has joined #baserock | 07:03 | |
| *** a1exhughe5 has quit IRC | 07:10 | |
| *** a1exhughe5 has joined #baserock | 07:12 | |
| *** Albert has joined #baserock | 07:44 | |
| *** rdale has joined #baserock | 07:50 | |
| *** mike has joined #baserock | 07:52 | |
| *** mike is now known as Guest22017 | 07:52 | |
| *** mariaderidder has joined #baserock | 07:54 | |
| *** bashrc has joined #baserock | 08:03 | |
| *** Guest22017 has quit IRC | 08:05 | |
| *** 7YUAAB3S9 has joined #baserock | 08:09 | |
| *** Guest22017 has joined #baserock | 08:17 | |
| wdutch | is there an example cluster morph for deploying for a chroot? I have a build system chroot and would like a devel chroot | 08:21 |
|---|---|---|
| Kinnison | I think in release.morph there may be sections for the chroot systems | 08:22 |
| petefoth | wdutch: have you had a poke round on wiki.baserock.org? | 08:22 |
| *** jonathanmaw has joined #baserock | 08:22 | |
| wdutch | petefoth: yes I couldn't find anything describing how to deploy a tarball for the chroot tool | 08:23 |
| petefoth | wdutch: OK | 08:23 |
| wdutch | ah yes I can see how it is done in release.morph, thanks Kinnison | 08:24 |
| Kinnison | you're welcome. | 08:24 |
| *** gary_perkins has joined #baserock | 08:56 | |
| *** Krin has joined #baserock | 09:00 | |
| *** ssam2 has joined #baserock | 09:02 | |
| *** ChanServ sets mode: +v ssam2 | 09:02 | |
| straycat | ssam2, richard_maw, can i merge https://gerrit.baserock.org/#/c/622/ now? | 09:10 |
| richard_maw | straycat: reading, allow me a few minutes to catch up on the responses | 09:12 |
| straycat | richard_maw, thanks | 09:12 |
| ssam2 | straycat: looks fine to me | 09:13 |
| richard_maw | straycat: and to me as well, I'm happier with the "catch everything" than the just catching ValueError if the cause is to handle potentially invalid input | 09:15 |
| straycat | well originally i thought i could remove the exception handler altogether, but ofcourse it's better to keep it. anyway thanks, i'll merge this | 09:19 |
| SotK | ssam2: is there any chance you could make my account on testgerrit an Administrator please? :) | 09:24 |
| ssam2 | sure | 09:25 |
| SotK | thanks! | 09:25 |
| ssam2 | argh, i've broken it | 09:29 |
| ssam2 | I disabled OpenID single sign-on again so that i could actually use my Administrator account | 09:29 |
| ssam2 | now when I try add you as an administrator i get 'Account Not Found: Adam Coldrick <adam.coldrick@codethink.co.uk>' | 09:30 |
| SotK | o.0 | 09:30 |
| richard_maw | ssam2: biff re https://gerrit.baserock.org/#/c/581/ | 09:32 |
| ssam2 | thanks | 09:33 |
| ssam2 | SotK: seems if I add you by user ID number it works | 09:35 |
| straycat | worth mentioning that when I tried to add ssam2 to a review yesterday I got a similar error | 09:36 |
| ssam2 | straycat: in the real gerrit.baserock.org? that's a pain | 09:36 |
| * straycat nods | 09:36 | |
| ssam2 | oh well. Hopefully updating to 2.10 will fix, i want to do that at some point | 09:38 |
| ssam2 | SotK: did you ever use 'tools/trigger-job.py' that comes in zuul.git? | 09:39 |
| ssam2 | if so, do you think it might work as a way to trigger a build of 'master', rather than a build of a Gerrit change? | 09:39 |
| SotK | ssam2: nope | 09:41 |
| SotK | ssam2: I'm currently looking at using the ref-updated event as a way of doing that | 09:41 |
| ssam2 | right | 09:41 |
| SotK | ssam2: also, thanks :) | 09:42 |
| ssam2 | SotK: ref-updated seems like a much more sensible approach | 09:43 |
| *** pacon has joined #baserock | 09:43 | |
| wdutch | is wiki.baserock.org down? | 09:43 |
| *** Guest22017 has quit IRC | 09:43 | |
| ssam2 | wdutch: I can't reach branchable.com or wiki.baserock.org at the moment, so perhaps it is down | 09:43 |
| ssam2 | actually, I can reach branchable.com, it's just a bit slow | 09:44 |
| De|ta | wiki.baserock.org is responding too, very slowly. | 09:45 |
| rjek | I'd say something unsavory about cloud providers, but I like liw and joeyh. | 09:45 |
| * Kinnison has raised the issue with liw and joeyh | 09:45 | |
| ssam2 | De|ta: oh yeah, i've managed to load wiki.baserock.org now too | 09:45 |
| ssam2 | SotK: what do you think about the idea of having zuul-layout.yaml defined by the user who deploys the Mason, rather than being auto-generated? | 09:49 |
| ssam2 | it seems like each user of a Mason might have different requirements. But at the same time, it'd be nice to have it work automatically without the user first having to write a zuul-layout.yaml | 09:49 |
| ssam2 | s/user/administrator/ I guess | 09:49 |
| SotK | I think the best we can do is provide an example one (eg. one which we will use in our CI) and some documentation on how to set it up | 09:50 |
| SotK | I don't see how we can easily set up one which "works by default", given we won't know anything about the layout of other people's Gerrits | 09:51 |
| ssam2 | that makes sense | 09:51 |
| *** a1exhughe5 has quit IRC | 09:52 | |
| *** Guest22017 has joined #baserock | 09:56 | |
| *** a1exhughe5 has joined #baserock | 09:57 | |
| richard_maw | hrm, we could do with patching morph gc so that it moves the extracted chunk tree in the hardlink cache to a tempdir, so that if you ^C a `morph gc` it can't leave you with a partially removed cached extraction | 10:10 |
| richard_maw | but hopefully we'll be moving to ostree soon enough anyway, and we won't need this | 10:10 |
| *** Guest22017 has quit IRC | 10:33 | |
| *** mike has joined #baserock | 10:33 | |
| *** mike is now known as Guest68378 | 10:33 | |
| Zara | hi, I tried to cross-bootstrap the armvl5 generic system, and this script was generated. Apparently it contains a bunch of things that it shouldn't contain (and it didn't build when I tried to run the script). Does anyone have any insight? http://sprunge.us/ihge | 10:38 |
| pedroalvarez | Zara: the script looks ok, can you paste the error you got when running it? | 10:39 |
| Zara | this is the full build.log (sorry about the length, it may freeze your computer for a second but it should load eventually): http://sprunge.us/OASH | 10:40 |
| pedroalvarez | Zara: I assume that you have generated a tarball using `morph cross-bootstrap`, then moved the tarball to a armv5 (maybe armv7) board, chrooted, and ran the script | 10:41 |
| pedroalvarez | is that correct? | 10:41 |
| nowster | Is it not making the link from /bin to /tools/bin ? | 10:42 |
| Zara | yes, I moved the tarball over (to an armv7 board), extracted it, chrooted in and ran the script | 10:42 |
| pedroalvarez | nowster: hm.. why? | 10:46 |
| nowster | /usr/bin/libtoolize: line 2508: /bin/sed: not found | 10:46 |
| nowster | etc | 10:46 |
| pedroalvarez | right | 10:46 |
| pedroalvarez | I think that /bin/sed is being used before | 10:47 |
| nowster | I noticed that too | 10:47 |
| pedroalvarez | this might be an issue with coreutils sed, then? | 10:47 |
| nowster | It might be a linker error. | 10:47 |
| jjardon | sed is not part of coreutils | 10:48 |
| pedroalvarez | jjardon: coreutils-common, sorry for the confusion | 10:49 |
| pedroalvarez | which is a stratum with coreutils, sed, diff.. | 10:49 |
| jjardon | pedroalvarez: It looks a bit strange that you have to compile even systemd to build the cross-* system, isnt it? | 10:49 |
| pedroalvarez | didn't notice that | 10:50 |
| pedroalvarez | ok, let's take a deeper look | 10:50 |
| jjardon | even coreutils stratum should not be build | 10:50 |
| jjardon | Zara: to generate the tarball, you used the cross-bootstrap-system-armv5l-generic system, rigth? | 10:51 |
| Zara | yes | 10:51 |
| pedroalvarez | ew | 10:52 |
| pedroalvarez | it should be built | 10:52 |
| pedroalvarez | ostee-core depends on foundation | 10:53 |
| pedroalvarez | foundation has systemd | 10:53 |
| pedroalvarez | and depends on coreutils-common | 10:53 |
| pedroalvarez | so the behavior is ok | 10:53 |
| jjardon | thats abug I think, I think ostree-core should not depend on foundation now that glib is in core | 10:54 |
| pedroalvarez | I hope so :) | 10:54 |
| * SotK thinks jjardon is correct | 10:55 | |
| jjardon | haha | 10:56 |
| * jjardon sent the path to move GLib to core but forgot to remove the 'foundation' dependency in ostree-core | 10:57 | |
| * jjardon will send a patch ASAP | 10:57 | |
| ratmice__ | Zara: soon before the error it switches from finding /bin/sed to /usr/bin/sed, maybe something to do with bash path caching? e.g. a missing hash -d sed? | 10:59 |
| jjardon | Zara: remove the foundation stratum from the build-depends of the cross- system and generate the tarball again | 11:00 |
| * SotK despairs at the length of the stratum list in this Mason system | 11:02 | |
| Zara | ratmice__: I don't know, it might be worth someone looking into it who needs to build that stratum (since the thing that fails to build is part of the foundation stratum that I'll be taking out, I'm not going to go digging just now) | 11:05 |
| pedroalvarez | jjardon: remember when I told you that you cross-bootstraping bigger systems will introduce errors? | 11:07 |
| jjardon | pedroalvarez : there is not another option for us | 11:08 |
| jjardon | pedroalvarez: as we have to build a build- system to deploy anyway | 11:09 |
| jjardon | Zara: removing foundation stratum is not going to work, as ostree depends in more stuff that is currently in foundation (e2fsprogs) | 11:10 |
| Zara | Oh, I should cancel this build, then. :D | 11:12 |
| jjardon | Zara: so, I will try to move e2fsprogs to -core, to try to keep foundation out of the ostree stratum deps. | 11:13 |
| ssam2 | ouch | 11:14 |
| * SotK notes that the x86_64 Mason's disk looks to be full | 11:14 | |
| ssam2 | jjardon: morph doesn't actually depend on ostree right now, so you could also just remove ostree from your system while bootstrapping | 11:14 |
| perryl | i've been looking at adding a username field to distbuild-cancel requests to log whoever cancels a build, but i'm wondering if it would be better to only allow the user/machine that started a build to cancel it; would this be viable or too restrictive, and is it worth sending an RFC to baserock-dev? | 11:16 |
| ssam2 | perryl: I think there's a bit of a wider discussion needed about the scope of distbuild, i.e. whether it should be something that only works within a private, trusted environment, or whether it should be secure in all cases | 11:17 |
| jjardon | Ah! Zara what Sam said then :) | 11:17 |
| ssam2 | perryl: so best so send something to the mailing list | 11:17 |
| ssam2 | *to | 11:17 |
| radiofree | jjardon: i don't have merge powers https://gerrit.baserock.org/#/c/678/ | 11:17 |
| perryl | ssam2: thanks, i'll write something up and send :) | 11:17 |
| radiofree | getting stuff lorried used to be so simple | 11:17 |
| radiofree | should i resubmit that patch again? | 11:18 |
| ssam2 | SotK: weirdly, neither cache.baserock.org or mason-x86-64.baserock.org seem to be full | 11:18 |
| rjek | If we just lorried all software in the universe, we wouldn't need to do this merge request thing. | 11:18 |
| SotK | ssam2: very weird | 11:19 |
| ssam2 | SotK: maybe pedroalvarez fixed it but didn't tell us | 11:19 |
| straycat | perryl, outside of a trusted environment distbuild needs an auth mechanism to do anything like that | 11:20 |
| jjardon | radiofree: done | 11:20 |
| straycat | perryl, and inside of a trusted environment using the hostname would probably be sufficient | 11:20 |
| radiofree | thanks jjardon | 11:21 |
| perryl | straycat: indeed, i was considering a function more for inside a trusted environment (as currently anyone can cancel anyone else's build) but i've not put a lot of thought to cases outside that; might be worth looking into before i send an RFC! | 11:21 |
| straycat | why would anyone cancel anyone's build within a trusted environment though? | 11:22 |
| pedroalvarez | ssam2: oh, just ran `morph gc` but I thought that wasn't going to be enough | 11:22 |
| ratmice__ | straycat: because they fired off a build before leaving the office and it's presumably triggered some awful bug causing an infinite loop? :) | 11:23 |
| pedroalvarez | ssam2: and is not enough, only 12G free | 11:23 |
| perryl | straycat: mistaken build identity if anything, but it may be useful if a user suddenly wonders why they have no recorded history of cancelling their own build | 11:23 |
| straycat | what do you mean by "mistaken build identity"? | 11:23 |
| pedroalvarez | ssam2, SotK: I'll clean them up | 11:24 |
| SotK | pedroalvarez: thanks! | 11:24 |
| perryl | straycat: morph distbuild-cancel InitiatorConnection-11 instead of InitiatorConnection-1 | 11:24 |
| straycat | perryl, that's a ui problem though | 11:24 |
| ssam2 | perryl: I think it'd be useful to make the job names less confusing | 11:24 |
| straycat | job names are now uuids | 11:24 |
| straycat | at least https://gerrit.baserock.org/#/c/666/ makes them uuids | 11:25 |
| straycat | so you're unlikely to accidentally cancel someone elses build in that manner | 11:25 |
| perryl | straycat: ahh, has that been merged? | 11:25 |
| straycat | perryl, no, it's an rfc i'm working on | 11:25 |
| Zara | ssam2, jjardon: thanks, I'll take ostree out then! | 11:25 |
| perryl | ah, not yet :) in that case i'll leave it for now | 11:25 |
| straycat | i'd be up for having users, but only with a proper auth mechanism, otherwise i don't see the point | 11:26 |
| jjardon | straycat: +1 | 11:27 |
| ratmice__ | i think user identity is never an acceptable auth mechanism | 11:28 |
| ssam2 | perryl: so, if you're up for it, maybe you could start a thread on baserock-dev about how best to add user authentication to distbuild | 11:29 |
| ssam2 | I think there's still interest in having 'build as a service' in some form, so it's useful to think about that | 11:29 |
| perryl | ssam2: i can look into it! | 11:29 |
| ssam2 | there are some quite simple ways to get user auth, e.g. reusing SSH like 'gitano' does | 11:30 |
| ratmice__ | it always leads to a case where it's easier to just share identity than give authorization in which case the whole metaphor is broken, e.g. sharing or not sharing build id's should be the discriminating factor of whether you can kill a job | 11:30 |
| Zara | just to check, would this be removing ostree-core from the system, or removing ostree from ostree core? (ie: do I still need libgsystem?) | 11:33 |
| SotK | Zara: removing ostree-core from the system | 11:33 |
| Zara | cool, glad I guessed that one :D | 11:34 |
| Zara | had a moment of... not panic, but potential gloom. | 11:35 |
| * SotK complains about the lack of runtime dependencies again | 11:35 | |
| SotK | I wonder if morph should warn if you include something but not one of its build deps | 11:35 |
| * straycat says he would like runtime dependencies again | 11:36 | |
| * pedroalvarez complains about the lack of build dependencies information | 11:37 | |
| paulsherwood | remind me, syntactically, how folks would like to do runtime dependencies? | 11:37 |
| * paulsherwood agrees that build dependencies already *obscures* what is really depended on, in most cases | 11:37 | |
| paulsherwood | but if we actually specified all the build-depends, definitiosn would be unworkable | 11:38 |
| pedroalvarez | I agree, that's why I'm not complaining louder | 11:38 |
| paulsherwood | (imo) | 11:38 |
| straycat | http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-November/009162.html was one suggestion | 11:39 |
| pedroalvarez | but I also have a feeling that this might bite us in the future | 11:39 |
| pedroalvarez | or maybe is already bitting us every day | 11:39 |
| ssam2 | paulsherwood: we could make use of strata to make things less unworkable. e.g. rather than saying 'this build-depends on make, gcc, libstdc++, glibc and busybox' you can say 'this build-depends on the build-essential stratum' | 11:39 |
| paulsherwood | isn't that what we already do, ssam2 / | 11:40 |
| paulsherwood | ? | 11:40 |
| paulsherwood | but the result of that is that the information is hidden | 11:40 |
| pedroalvarez | ssam2: do you mean stop adding the strata build-dependencies recursively? | 11:42 |
| paulsherwood | straycat: i remember now. my problem was mainly that this would further complicate definitions in the same vein as stratum splitting. and in practice i fear that we don't use stratum-splitting because it's too hard to comprehend | 11:42 |
| ssam2 | paulsherwood: well, right now we say 'this build-depends on foundation', then we say 'foundation build-depends on core', then we say 'core build-depends on build-essential' | 11:45 |
| straycat | fair enough i can't say i've ever used the split rules for anything, richard_maw suggested part of the problem there is that the split rules aren't very accessible, they're buried in morph | 11:46 |
| paulsherwood | ssam2: yes. because previously we had them explicit and *that* became unwieldy (the genivi/x saga) | 11:46 |
| ssam2 | ah, ok | 11:46 |
| ssam2 | i don't think the result of that information is 'hidden', it's all available in definitions.git | 11:46 |
| radiofree | we've worked around runtime dependencies for now by just replacing the build-time dependency in the system with the runtime one | 11:47 |
| ratmice__ | i'm not sure, graph clustering of the dependency graph seems alright and non-hiding iff things which depend on the cluster depend on everything inside the cluster, that is there is a way to go from absolute dependencies to clustering, but not so much depending on clusters directly | 11:47 |
| radiofree | e.g mesa-common because mesa-common-vm for x86 images | 11:47 |
| paulsherwood | ssam2: what i mean is, if foo depends on bar stratum, which depends on quux stratum, we are hiding that foo only depends on some unknown subset of bar and quux | 11:47 |
| ssam2 | paulsherwood: ah, I see what you mean. It might be clearer to call that 'misrepresenting' the dependency info | 11:48 |
| paulsherwood | ok | 11:48 |
| SotK | my problem was that I'm rebasing an old branch and a bunch of components have been moved into their own strata | 11:48 |
| SotK | the new strata were in the build-depends for the strata they used to be in, but the changes obviously weren't reflected in the system definition from the old branch | 11:49 |
| ratmice__ | not sure if that observation really helps though, it means we can bootstrap a clustered/simplified view of the dependency graph from the absolute dependencies, but we still have an awful large absolute dependency graph around we have to work with :/ | 11:50 |
| SotK | so I keep rebuilding without trouble then noticing something else is missing from my deployed system | 11:50 |
| paulsherwood | SotK: i don't think runtime depends would have made that easier? there would have been *more* stuff to fix i think? :) | 11:50 |
| SotK | s/missing/doesn't work/ | 11:50 |
| *** jmacs has joined #baserock | 11:50 | |
| * paulsherwood may be wrong, of course | 11:51 | |
| SotK | paulsherwood: in my head, runtime depends would have either caused the deployed system to contain the missing things, or caused an error to be raised because the system doesn't contain a runtime depend of some stratum foo | 11:51 |
| ssam2 | ratmice_: I worry that the task of representing dependencies can always be done in finer detail | 11:51 |
| paulsherwood | ratmice__: yup, that's the problem. i've been aiming to keep definitions as simple as possible, for ease-of-use | 11:51 |
| ssam2 | ratmice__: in Fedora, a lot of RPMs now depend on a specific feature rather than a package by name | 11:52 |
| paulsherwood | owww | 11:52 |
| ssam2 | e.g. they'll depend on /bin/sh, then a package will define that it provides /bin/sh | 11:52 |
| SotK | rather than the current situation of "build all of the things and their dependencies (even if the dependency is not listed in the system), then only deploy the listed things" | 11:52 |
| ssam2 | or depend on 'pip package foo' rather than 'rpm python-foo-1.2.3' | 11:52 |
| paulsherwood | SotK: so by default we just end up with most things having a runtime-depends list which is the same as its build-depends list? | 11:53 |
| * SotK doesn't know | 11:54 | |
| SotK | my problem was the python-wsgi and python-cliapp strata didn't exist in my old branch, which are both strictly runtime depends but listed as "build depends" afaik | 11:55 |
| paulsherwood | we have a python-cliapp stratum? | 11:56 |
| straycat | having re-read the stratum runtime deps patch i admit that i don't understand why stratum runtime dependencies can't be specified in a similar way to stratum build dependencies | 11:57 |
| SotK | paulsherwood: indeed | 11:58 |
| ratmice__ | SotK: is this something to do with BUILD_DEP'ing on a thing with runtime-dep's necessitates the inclusion of the runtime-dep at build time? | 11:58 |
| SotK | ratmice__: I don't think so | 11:59 |
| paulsherwood | so just call them 'dependencies' and be done? :) | 11:59 |
| paulsherwood | straycat: ^^ | 11:59 |
| * SotK notes that some of the things in python-cliapp look unrelated to cliapp, but may be wrong | 12:00 | |
| * paulsherwood notes that the only thing depending on cliapp is likely to be morph | 12:00 | |
| * paulsherwood notes that ybd can build all of release.morph without morph, or cliapp, but cannot deploy all the things because deployment is coupled to morph which is coupled to... | 12:01 | |
| paulsherwood | s/deployment is/deployment extensions are/ | 12:02 |
| straycat | paulsherwood, that would lead to potentially quite large amounts of inefficiency though, e.g. i'd end up having swift build-depend on ansible for example, so a change in something unrelated like jinja2 would cause an unnecessary rebuild of swift | 12:03 |
| * SotK was referring to python-coveragepy and python-coverage-test-runner, which are part of the python-cliapp stratum... | 12:03 | |
| paulsherwood | how long does it take to build those things? | 12:03 |
| paulsherwood | SotK: all only there because morph, i believe | 12:04 |
| ratmice__ | longer than it takes not to :) | 12:04 |
| paulsherwood | ratmice__: actually, not necessarily. | 12:04 |
| straycat | not much time at all, but i'm not really sure that's the point? if people have been complaining that morph takes 10 seconds to "decide on task order" then i hate to imagine how they're react when they work out morph is spending a total of let's say 3 minutes building stuff it didn't need to | 12:04 |
| SotK | probably, but in that case the stratum probably shouldn't be called python-cliapp | 12:05 |
| straycat | *they will | 12:05 |
| ssam2 | the reason for python-cliapp existing is that both lorry-controller and morph use it | 12:05 |
| paulsherwood | if build is longer but normally works, that's better than shorter builds which normally break or lead to unexpected results and therefore need to be re-done | 12:05 |
| ssam2 | and I wanted to have lorry-controller in the gerrit system, without Morph | 12:05 |
| paulsherwood | ah, i'm wrong, then. cliapp is required by lc | 12:06 |
| paulsherwood | i don't think i'm wrong on the efficiency argument, though :) | 12:07 |
| ssam2 | i'm sure we could find a pathological case | 12:07 |
| paulsherwood | i daresay :) | 12:08 |
| straycat | paulsherwood, so i can revert all the morph speedup commits then, and no one will mind? :) | 12:08 |
| paulsherwood | i won't mind - i'm using ybd as you know :) | 12:09 |
| straycat | with an awareness that i'm quite (very) crap, something i was told a few years ago which i always try to bear in mind is that, roughly, you haven't achieved simplicity by excluding a feature, you've just failed to solve a problem, simplicity isn't actually about just cutting things out, it's harder than that, and the fact that simplicity is hard is what makes it difficult to achieve, and why we have complex things. so when you say "just treat eve | 12:21 |
| * radiofree waits for that anecdote to finish | 12:22 | |
| SotK | (it got cut off at "treat eve") | 12:22 |
| straycat | so when you say "just treat everything | 12:22 |
| straycat | as a dependency" or "use random.shuffle() on the chunk list to avoid redundant building in a | 12:22 |
| straycat | distbuild", you haven't actually made anything simpler, you've just failed to solve the | 12:23 |
| straycat | problem. | 12:23 |
| DavePage | I'm pretty sure Eve would appreciate being treated | 12:23 |
| paulsherwood | straycat: we'll have to see, i think. i've been wrong many times before. but here, i'm pretty confident :) | 12:25 |
| rjek | We should keep a log; the statistics might be interesting. | 12:26 |
| paulsherwood | fwiw i don't think i said the shuffle was to avoid redundant building. i'm *happy* with some redundancy, ad shuffling definitely causes some | 12:27 |
| paulsherwood | anyway i've yet to prove my point, so i'll be quiet now :) | 12:28 |
| *** zoli__ has quit IRC | 12:29 | |
| ratmice__ | I suppose this is where haskell would help in having some infinite list of dependencies, which we compute lazily :) | 12:29 |
| *** zoli__ has joined #baserock | 12:29 | |
| Kinnison | Sadly haskell is a total pig to cross-bootstrap | 12:30 |
| Kinnison | Otherwise I'd have it in build-essential by now | 12:30 |
| jmacs | The "Doing stuff on baserock" wiki page mentions Raspberry Pi - does that mean the ARMv6 version, or the ARMv7? | 12:30 |
| Kinnison | jmacs: most likely the former | 12:30 |
| rjek | jmacs: I believe pedroalvarez did an ARMv6 port as a proof-of-concept | 12:31 |
| ssam2 | jmacs: i wondered about separating the two | 12:32 |
| ssam2 | it kind of means 'either' right now | 12:32 |
| *** fay__ has joined #baserock | 12:33 | |
| *** fay_ has quit IRC | 12:33 | |
| *** zoli__ has quit IRC | 12:34 | |
| ssam2 | i'm having a nightmare trying to log into the openstack gerrit, I'm glad we decided not to use Ubuntu One ID's | 12:49 |
| ssam2 | an attempt to reset my password produced an 'Invalid OpenID transaction' and then my password still isn't reset | 12:50 |
| ssam2 | 2nd time round it seems to have worked | 12:50 |
| *** pacon has quit IRC | 12:51 | |
| *** zoli__ has joined #baserock | 12:57 | |
| *** mariaderidder has quit IRC | 12:59 | |
| *** mariaderidder has joined #baserock | 13:11 | |
| Zara | I'm back! I built my beautiful tarball, extracted it, read the native-bootstrap script-- only to find it still contained ostree! oh no! closer inspection reveals that the devious morph-utils also depends on ostree-core, which in turn depends on foundation, etc etc etc... | 13:14 |
| SotK | you can remove ostree-core from the build-depends list in morph-utils too | 13:16 |
| SotK | its not actually needed yet | 13:16 |
| Zara | heh :) is it likely to be lurking anywhere else? | 13:16 |
| SotK | I don't think so | 13:16 |
| SotK | `git grep ostree-core` should show all the places it is, only some of which will matter to you I imagine | 13:17 |
| Zara | oh good, just the two strata | 13:18 |
| * SotK discovers that Zuul's documentation contains bugs | 13:19 | |
| pdar | is anyone else having difficulty accessing w.b.o? | 13:37 |
| rjek | pdar: Branchable's having a bad day today. | 13:37 |
| jmacs | Now you mention it, yes | 13:37 |
| Zara | pdar: yeah, intermittently | 13:38 |
| pdar | phew, I'm glad im not alone | 13:40 |
| petefoth | pdar: ti was v. slow for me earlier | 13:42 |
| ssam2 | SotK: i hope you're going to submit fixes to review.openstack.org ! | 13:44 |
| ssam2 | i'm trying to fix the bug where the 'zuul' program hangs completely if it can't contact the server and has to be kiiled with -9 | 13:44 |
| ssam2 | because that super annoying | 13:44 |
| jmacs | In the absence of wiki.baserock.org, could someone point me to a recent build/dev image of baserock (x86)? | 13:52 |
| jmacs | Oh, it's back up now | 13:52 |
| jmacs | Well... kind of back up | 13:59 |
| *** mdunford has joined #baserock | 13:59 | |
| ssam2 | remember you can do `git clone git://baserock.branchable.com/` and get the whole wiki locally | 14:06 |
| ssam2 | not ideal, but it's a workaround | 14:06 |
| Kinnison | Apparently branchable is undergoing some crunchy rebuilds which are causing issues | 14:06 |
| Kinnison | the owners are working on it | 14:06 |
| ssam2 | what would my Baserock system be missing in order that terminal colour codes wouldn't work? | 14:17 |
| Kinnison | 1. is TERM set right | 14:17 |
| ssam2 | TERM=xterm | 14:17 |
| ssam2 | in my SSH session | 14:17 |
| Kinnison | Do you have /usr/share/terminfo/xterm ? | 14:17 |
| ssam2 | yes | 14:17 |
| Kinnison | might be .../x/xterm | 14:17 |
| ssam2 | yeah, it's that in fact | 14:18 |
| Kinnison | not sure, I'd expect that to be enough | 14:18 |
| Kinnison | is ncurses built properly? | 14:18 |
| ssam2 | /lib/libncursesw.so.5.9 exists, at least | 14:19 |
| Kinnison | Is it that echoing colour codes isn't working, or simply that programs you expect to be colourised are not? | 14:26 |
| DavePage | ssam2: Is the best workaroudn not to lorry baserock.brnachable.com to trove.baserock.org? ;) | 14:28 |
| paulsherwood | +1 | 14:30 |
| jjardon | would it be ok to move e2fsprogs to -core so the -cross systems are not massive? | 14:31 |
| paulsherwood | +1 | 14:31 |
| Kinnison | DavePage: I wouldn't do that | 14:33 |
| Kinnison | jjardon: are any of e2fsprogs' outputs used in the deployment mechanisms which might be used to create the proper build system out of a cross-bootstrapped environment? | 14:33 |
| Kinnison | jjardon: if so, we cannot remove them from the cross systems | 14:33 |
| SotK | Kinnison: I believe the idea is to move them into core so that they can be in the cross systems without the cross systems needing to include foundation+deps | 14:34 |
| * SotK may be misunderstanding this though | 14:34 | |
| rdale | i think core should contain build tools, it seems to be a general dumping ground | 14:34 |
| jjardon | Kinnison: Im not suggesting that, but move e2fsprogs from foundation to core; morph depends on ostree, wich depends on the whole foundation because e2fsprogs only | 14:34 |
| * Kinnison got the layer-up the wrong way around | 14:35 | |
| Kinnison | jjardon: So long as cross-bootstrapped systems can still deploy things effectively I'm okay with that | 14:35 |
| Kinnison | the sole purpose of the result of cross-bootstrapping is to have something capable of properly building and deploying a build system | 14:36 |
| pedroalvarez | indeed | 14:36 |
| pedroalvarez | although at the moment they have even systemd | 14:36 |
| jjardon | Kinnison: well, until very recently they can not deploy as btrfs-progs is in foundation | 14:37 |
| pedroalvarez | jjardon: +1 to make the ostree depend on less things | 14:37 |
| * Kinnison will gladly review anything which makes cross-bootstrapped systems smaller, but still fully functional | 14:37 | |
| jjardon | I suggested to move btrfs-progs to core to avoid that but seems it was not a good idea | 14:38 |
| * jjardon cooking a patch | 14:38 | |
| * pedroalvarez will wait for the chef | 14:38 | |
| rjek | We use ansible, pedroalvarez | 14:39 |
| jjardon | rdale: me too, but I can not find a better solution in this case. Any other idea? | 14:40 |
| rdale | another stratum between core and foundation? | 14:40 |
| pedroalvarez | rjek: :) | 14:41 |
| * rjek fears we may end up with one chunk per stratum | 14:41 | |
| * SotK wonders if strata should be able to depend on single chunks | 14:42 | |
| * jjardon fears the same since a long time ago | 14:42 | |
| * richard_maw isn't worried about 1 chunk per stratum, provided we can reduce the overhead in the definition, and have runtime depends to ease the burden when defining systems | 14:45 | |
| ssam2 | Kinnison: the colour codes are showing up on screen | 14:46 |
| ssam2 | it does seem that splitting 'foundation' is on the horizon | 14:48 |
| ssam2 | that's even more of a dumping ground than 'core' | 14:48 |
| pedroalvarez | ssam2: last time I had that issue was because my system didn't have `less`, and it was using busybox less | 14:48 |
| ssam2 | ah | 14:48 |
| ssam2 | pedroalvarez: that's probably the issue here too, thanks | 14:49 |
| pedroalvarez | ssam2: sorry I didn't say that before, I thought you were trying to solve a different problem | 14:49 |
| Kinnison | ssam2: Hmm that's very odd | 14:50 |
| * richard_maw kicks baserock-system-config-sync | 14:54 | |
| straycat | aww :( | 14:54 |
| richard_maw | because I have a systemd unit with escape sequences in its name (because it escapes the value in templated units) it's refusing to allow me to perform an upgrade | 14:55 |
| richard_maw | the fault, is that the `read` builtin will unescape some things | 14:55 |
| richard_maw | hence when it goes to look for the file, it can't find it any more | 14:55 |
| * tlsa would get rid of stratum, and just make chunks have explicit dependencies on chunks. | 14:57 | |
| jjardon | pedroalvarez: dinner is ready: https://gerrit.baserock.org/#/c/681/ | 14:58 |
| rjek | One of the original design goals was to avoid that, IIRC | 14:58 |
| Kinnison | tlsa: that way "packaged" systems lies | 14:58 |
| jjardon | also Kinnison ^^ | 14:58 |
| * Kinnison has a nibble | 14:58 | |
| * SotK gets hungry | 14:58 | |
| tlsa | Kinnison: to me the good thing about baserock is its well defined, and reproducable definitions | 14:58 |
| tlsa | stratum just get in the way the whole time | 14:59 |
| * rjek basically agrees. | 14:59 | |
| tlsa | it's an artificial indirection of dependencies | 14:59 |
| rjek | A warm fuzzy feeling, but not really pragmatic or workable | 14:59 |
| jjardon | tlsa: so, for example, for every chunk you should have to specify all its dependencies ? | 15:00 |
| tlsa | yes | 15:00 |
| * Kinnison is worried that if we drop strata as a concept then we're simply back to the combinatorial explosion issues that plague normal "packaged" distros | 15:00 | |
| * richard_maw thinks there's still call for a physical format level aggregation of multiple definitions for well integrated components | 15:00 | |
| rjek | metapackages :) | 15:00 |
| jjardon | tlsa: until binutils? thats a long list, and a lot of duplication | 15:00 |
| * SotK thinks it would be nice to keep strata but allow them to depend on individual chunks | 15:00 | |
| richard_maw | rjek: not for grouping, just to make it easy to define all the interrelations in one file | 15:00 |
| * rjek nods | 15:01 | |
| tlsa | jjardon: I'd probably investigate scraping the base definitions from linux from scratch | 15:01 |
| jjardon | I like more the SotK idea. I didnt think in the implications though | 15:01 |
| * Kinnison has no desire for Baserock to essentially become yet-another-source-based-distro | 15:01 | |
| Kinnison | we may as well use Gentoo at that point | 15:01 |
| pedroalvarez | can we now build a straum? | 15:02 |
| Kinnison | ssam2: Have you bugged anyone else for a review of https://gerrit.baserock.org/#/c/641/ ? | 15:02 |
| tlsa | Kinnison: getting rid of stratum has no affect on it being about fully defined systems, with atomic upgrades | 15:02 |
| pedroalvarez | yes we can! | 15:03 |
| ssam2 | Kinnison: no, jjardon maybe you could look at it again? | 15:04 |
| Kinnison | tlsa: My point is, if the tooling ends up defining something akin to that defined by portage, bitbake, whatever. Then there's little benefit in maintaining our own tooling and we'd be better off augmenting existing stuff | 15:04 |
| tlsa | I don't know anything of these alternatives | 15:05 |
| tlsa | Kinnison: my opinion is based on my experience of all baserock pain deriving from stratum | 15:05 |
| rjek | They're all worse | 15:05 |
| Kinnison | Sadly, software integration is not easy | 15:05 |
| ssam2 | Kinnison: I agree, but I don't think that is a logical argument about whether to keep or drop strata | 15:06 |
| ssam2 | gentoo supported metapackages since before Baserock existed, anyway | 15:06 |
| Kinnison | ssam2: If the defining characteristic difference is in our striated system definitions, removing the strata from the model leaves us with no defining characteristic not implementable in other systems | 15:06 |
| Kinnison | ssam2: metapackages are subtly different from a striated system | 15:07 |
| ssam2 | but strata can be implemented in other systems anyway | 15:07 |
| Kinnison | though perhaps the subtlety is lost in our approach | 15:07 |
| ssam2 | I really don't think they are the one differentiating factor of Baserock's tooling... | 15:07 |
| jjardon | ssam2: done, next time assume the my +1 is still there if you are only improving things :) | 15:07 |
| ssam2 | jjardon: ok | 15:07 |
| ssam2 | Kinnison: I've no idea how strata differ from metapackages, it might be useful if you could explain what subtlety we have lost | 15:07 |
| Kinnison | metapackages are about runtime dependencies where strata are about both runtime and build-time behaviour | 15:08 |
| ssam2 | ah, ok | 15:08 |
| Kinnison | Also, strata are meant to be integration points (though we've never quite gotten to that) | 15:08 |
| Kinnison | whereas in a package/metapackage system, integration remains the domain of the package | 15:08 |
| ssam2 | i'm pretty sure that could be implemented in Bitbake or Gentoo for less effort than it took to create the whole of Baserock ;) | 15:08 |
| * richard_maw grumbles that https://gerrit.baserock.org/#/c/641/ was merged before he could point out that the conditional, while it will always work as expected, does so in a *nasty* way | 15:09 | |
| tlsa | strata mean when you build something that's quite far up the tree of strata, there's masses of unrelated stuff in the build chroot | 15:09 |
| Kinnison | ssam2: perhaps so | 15:09 |
| Kinnison | tlsa: Yes, the striated model does mean build chroots are larger than they might be | 15:09 |
| Kinnison | tlsa: there's little we can safely do to find a halfway house between striation and packages though | 15:10 |
| richard_maw | ssam2: the unquoted $sessions can cause parse errors in the `test` command, but since you invert the result, and can only get parse errors when you have multiple sessions, it works | 15:10 |
| richard_maw | but… eww | 15:10 |
| ssam2 | ah, I didn't realise. I hate shell! | 15:11 |
| ssam2 | will it fix it to put "$sessions" in quotes there? | 15:11 |
| richard_maw | it isn't broken, it will behave as it's supposed to, but `test -n "$sessions"` is much nicer than `! test -z $sessions` | 15:11 |
| ssam2 | ok, i'll try to remember that for the future | 15:12 |
| * richard_maw prepares a patch to baserock-system-config-sync so he can submit a patch to morph to sort out --upgrade propagating to subsystem deployments so he can submit fixed versions of the shutdownramfs patches to he can get on with his experiments in fixing command-line parsing in systemd | 15:13 | |
| jjardon | ssam2: Would it I change your -1 for a +[0|1] if I promise to work in a filesystem-stratum as soon as it gets merged? | 15:14 |
| tlsa | Kinnison: to me "packages" mean installing partial changes to the running system, and that's irrelevent to baserock. I don't think "either you have stratum or you have packages" makes sense. | 15:17 |
| jonathanmaw | richard_maw: http://i.imgur.com/t0XHtgJ.gif | 15:17 |
| Kinnison | tlsa: without strata, you have no runtime groupings available | 15:18 |
| Kinnison | tlsa: which implies each software source needs to state its runtime dependencies | 15:18 |
| Kinnison | tlsa: thus packages | 15:18 |
| richard_maw | jonathanmaw: exactly | 15:18 |
| Kinnison | tlsa: whether your resultant system has binary packages or not is an implementation detail | 15:18 |
| tlsa | Kinnison: no, I omitted the other part of my plan | 15:18 |
| tlsa | 1. get rid of stratum | 15:18 |
| tlsa | 2. add runtime deps to chunks, in addition to build time | 15:19 |
| Kinnison | now chunks are packages | 15:19 |
| Kinnison | by any other name | 15:19 |
| richard_maw | https://gerrit.baserock.org/#/c/682/1 | 15:19 |
| rjek | Kinnison: I never understood why that's a bad thing. | 15:19 |
| Kinnison | It's to do with presenting well integrated collections, but frankly I'm fed up with going round and round this point | 15:20 |
| tlsa | 3. systems just list the few things that make it stand out; e.g. linux, gnome shell, firefox (for a web browser system), and the system builder puts together a system that has all that incusing the deps it needs | 15:20 |
| Kinnison | if enough people hate strata -- come up with a replacement set of tooling which does away with them and propose it | 15:20 |
| rjek | morph doesn't really enforce their use, does it? | 15:21 |
| Kinnison | only that currently systems contain strata | 15:22 |
| tlsa | I would have "groups" rather than strata. e.g. "productivity" group would list chunks like "abiword, open office, inkscape, gimp", and a productivity system could have "linux, kde, group:productivity" | 15:22 |
| ratmice__ | i'm a bit annoyed that the list of files installed by a build is only available as a effect of 'make install', so we can't even make some sort of nutso filesystem which builds packages on use | 15:22 |
| tlsa | and the system builder would flatten the groups out to chunk lists, pull in deps, etc | 15:23 |
| Kinnison | tlsa: So if I did away with strata and instead had "aggregate chunks" (essentially your 'group' concept) would you be happy? | 15:24 |
| tlsa | as long as "aggregate groups" couldn't be used as build deps | 15:25 |
| ratmice__ | what annoys me is that all these dependencies are built into the blob, and then respecified outside of the blob, simply because it's all wrapped up in stupid effects, without a way to get the dependencies without producing the effect | 15:25 |
| Kinnison | tlsa: why prevent their use as build-deps? | 15:25 |
| Kinnison | ratmice__: yeah we did originally look into trying to auto-extract dependencies from the source trees but it turned out to be delightfully turing-complete | 15:25 |
| tlsa | Kinnison: that inderection is where all my baserock pain comes from | 15:25 |
| Kinnison | tlsa: So in your model you would have to explicitly list every single one of your build-dependencies? | 15:26 |
| Kinnison | tlsa: from fhs-dirs up? | 15:26 |
| tlsa | yes, probably. Is that not how other systems do it? | 15:27 |
| Kinnison | No | 15:27 |
| tlsa | how then? | 15:27 |
| Kinnison | other systems allow you to build-depend on aggregations | 15:27 |
| Kinnison | e.g. meta-packages | 15:27 |
| tlsa | well, maybe the low level stuff you need can be grouped | 15:27 |
| Kinnison | also build-depending on foo, means you implicitly build-depend on all of foo's runtime dependencies | 15:27 |
| Kinnison | tlsa: But you said that the data model was not to permit build-depending on aggregations | 15:28 |
| tlsa | but atm, if you want to move a chunk from stratum A to stratum that A build depends on, B, the info about what in B it depended on is not stored anyware, so you have to include stuff by trial and error | 15:29 |
| Kinnison | Correct | 15:29 |
| * Kinnison doesn't see that as a problem | 15:30 | |
| Kinnison | We simply shifted work from when the chunk was in A to when you wanted to move the chunk to B | 15:30 |
| Kinnison | it's not a case that more work has to be done, simply that when the work is done has moved | 15:30 |
| Kinnison | And that in the case the chunk is not moved, less work is done over-all | 15:30 |
| tlsa | another is if you have a branch of defintions, and you add a stratum that depends on other stratum for some software, you get everything working, merge it to master, no conflicts happen, but your system now either fails to build or fails to run, because some chunk moved between 2 stratum on master while you were branched | 15:31 |
| tlsa | with explicit chunk dependencies, that couldn't happen | 15:31 |
| ssam2 | jjardon: you can ignore my -1 if so | 15:32 |
| ssam2 | jjardon: remember -1 doesn't block merging it | 15:33 |
| Kinnison | tlsa: Your best bet for getting your idea considered is to produce a definitions set which looks like you wish it did. Then ask for commentary | 15:35 |
| Kinnison | tlsa: Right now I think your approach would be way more work in the general case, to solve a few niggles in rarer cases | 15:35 |
| Kinnison | tlsa: BICBW | 15:35 |
| tlsa | Kinnison: there's much more work involved when you remove chunk from A and put it in B | 15:35 |
| Kinnison | right, but is moving chunks a common action or not? | 15:35 |
| Kinnison | I think you need to do some analysis | 15:36 |
| tlsa | it's not only finding out which things in B the moved chunk might dep on | 15:36 |
| Kinnison | "I have pain when I do foo, therefore we should redesign to eliminate foo" is only a good thing when the redesign doesn't make 'bar' more painful where 'bar' is far more common than 'foo' | 15:36 |
| tlsa | does chunk A still need to dep on B, or does other stuff in there need it? | 15:36 |
| tlsa | s/cunk/stratum/ | 15:37 |
| tlsa | Kinnison: moving chunks seems to be routine | 15:37 |
| Kinnison | tlsa: then you have a data point | 15:37 |
| * Kinnison says again -- further discussion here without data to back things up, and a fully fleshed out proposed reshape will be less than useful | 15:38 | |
| ssam2 | agreed, one point in favour of the current system is that it more or less works, and we can use it | 15:39 |
| ssam2 | not that your complaints aren't valid, just that i don't know of anyone personally motivated to take time to change things right now | 15:39 |
| ratmice__ | i'd guess something can be done with atime to look at the files of a chunk and see if none of them were accessed? | 15:40 |
| Kinnison | ratmice__: I doubt atime is altered for a stat() and that might be all that's used in the build process | 15:41 |
| * jjardon would like (and would work) to make everything explicit, if we agree on that (but keeping the stratum model, ie, build-deps explicit between strata, and explicit between the chunks within a stratum) | 15:42 | |
| Kinnison | ratmice__: basically unless we had binary-reproducible builds (which I'd like us to work toward at some point), it's hard to determine if removing a b-dep causes a change in the resultant built chunk | 15:42 |
| Kinnison | jjardon: We already had a discussion which ended with "explicit b-deps within a stratum is too hard / too much work / cannot be bothered" | 15:43 |
| Kinnison | jjardon: No idea if that opinion has changed though | 15:43 |
| tlsa | earlier SotK mentioned the length of the mason system's stratum list. It's long and full of many generic names that could mean anything, yet it would break without them. With chunk runtime deps, you could have a system that has "linux-system, mason, morph". i.e. just listing what it needs that differentiates it. | 15:43 |
| tlsa | just throwing out ideas :) | 15:43 |
| * richard_maw *finally* updated his shutdownramfs patches | 15:45 | |
| ssam2 | i'm quite interested to see how the definitions would look with these different ideas, it'd make it much easier to evaluate the different approaches | 15:45 |
| jjardon | ssam2: I will try to have something when I have time, can you point me to the part of the morph code where the dependencies are resolved, so I can set everything explicit? | 15:47 |
| ssam2 | jjardon: it's around here: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/artifactresolver.py#n118 | 15:52 |
| jjardon | ssam2: cheers, thanks | 15:52 |
| ssam2 | i've always found that code quite confusing | 15:53 |
| paulsherwood | ssam2: try ybd :) https://github.com/devcurmudgeon/ybd/blob/master/definitions.py | 15:53 |
| ssam2 | looks simpler | 15:54 |
| paulsherwood | that's all of it :) | 15:55 |
| * Kinnison cannot understand ybd | 15:56 | |
| paulsherwood | heh. | 15:56 |
| Kinnison | it is too highly coupled and poorly documented | 15:56 |
| * paulsherwood cannot understand morph, for the same reasons | 15:56 | |
| Kinnison | (and given I wrote part of it, that's worrisome) | 15:56 |
| * richard_maw rebuilds the world because of a change to tbdiff | 15:57 | |
| *** a1exhughe5 has quit IRC | 16:06 | |
| *** franred has quit IRC | 16:08 | |
| paulsherwood | git.baserock.org downloads are stalling for me... | 16:15 |
| *** Krin has quit IRC | 16:24 | |
| *** Krin has joined #baserock | 16:24 | |
| *** ssam2 has quit IRC | 16:26 | |
| *** flatmush has quit IRC | 16:26 | |
| *** fay__ has quit IRC | 16:26 | |
| *** mariaderidder has quit IRC | 16:26 | |
| *** nowster has quit IRC | 16:26 | |
| *** mdunford has quit IRC | 16:26 | |
| *** CTtpollard has quit IRC | 16:26 | |
| *** paulw has quit IRC | 16:26 | |
| *** gary_perkins has quit IRC | 16:26 | |
| *** bashrc has quit IRC | 16:26 | |
| *** petefoth has quit IRC | 16:26 | |
| *** Guest68378 has quit IRC | 16:26 | |
| *** sambishop has quit IRC | 16:26 | |
| *** jonathanmaw has quit IRC | 16:26 | |
| *** 7YUAAB3S9 has quit IRC | 16:26 | |
| *** Krin has quit IRC | 16:26 | |
| *** edcragg has quit IRC | 16:26 | |
| *** bashrc has joined #baserock | 16:26 | |
| *** edcragg has joined #baserock | 16:26 | |
| *** paulw has joined #baserock | 16:26 | |
| *** sambishop has joined #baserock | 16:26 | |
| *** Krin has joined #baserock | 16:26 | |
| *** tiagogomes_ has joined #baserock | 16:26 | |
| *** Guest68378 has joined #baserock | 16:26 | |
| *** mdunford has joined #baserock | 16:26 | |
| *** jonathanmaw has joined #baserock | 16:26 | |
| *** mariaderidder has joined #baserock | 16:26 | |
| *** petefoth has joined #baserock | 16:27 | |
| *** fay__ has joined #baserock | 16:27 | |
| *** nowster has joined #baserock | 16:27 | |
| *** CTtpollard has joined #baserock | 16:27 | |
| *** ssam2 has joined #baserock | 16:27 | |
| *** ChanServ sets mode: +v ssam2 | 16:27 | |
| *** gary_perkins has joined #baserock | 16:27 | |
| ssam2 | paulsherwood: if you're in the same place as me, perhaps it's our internet connection! | 16:27 |
| *** flatmush has joined #baserock | 16:28 | |
| ssam2 | the machine has one CPU at 100% on a CVS import and another spending lots of effort to run lorry-controller-webapp (probably because the webapp.db file is huge again...), but it doesn't look broken | 16:28 |
| Kinnison | CVS import :( | 16:29 |
| paulsherwood | i'm on adifferent continent i think | 16:32 |
| ssam2 | probably not that then | 16:33 |
| pedroalvarez | oh, cvs import processes again | 16:33 |
| pedroalvarez | kill 'em | 16:34 |
| ssam2 | done | 16:34 |
| pedroalvarez | thanks | 16:34 |
| pedroalvarez | ssam2: I normally notice that g.b.o is going wrong when the there are too many "now"s in the LC status page | 16:35 |
| pedroalvarez | and always related to these cvs processes | 16:35 |
| *** mariaderidder has quit IRC | 16:39 | |
| *** mariaderidder has joined #baserock | 16:40 | |
| *** mariaderidder has quit IRC | 16:42 | |
| * pedroalvarez is not an emails guy | 16:51 | |
| *** Krin has quit IRC | 16:52 | |
| *** ssam2 has quit IRC | 16:54 | |
| * paulsherwood is failing completely to download dropbear. i wonder if my hotel has throttled me | 16:57 | |
| *** Guest68378 has quit IRC | 16:57 | |
| rdale | are you building the openwrt system? | 16:58 |
| radiofree | any chance someone could +1 https://gerrit.baserock.org/#/c/656/ ? | 16:58 |
| richard_maw | radiofree: merged | 16:59 |
| radiofree | richard_maw: thanks very much | 17:00 |
| *** jonathanmaw has quit IRC | 17:02 | |
| *** bashrc has quit IRC | 17:28 | |
| *** mdunford has quit IRC | 17:31 | |
| *** gary_perkins has quit IRC | 17:38 | |
| *** edcragg has quit IRC | 17:40 | |
| paulsherwood | rdale: trying to, modulo throttling | 18:33 |
| rdale | paulsherwood: ok i hope you can build it. we were thinking about a luci2 web based demo to show we had made some progress with the baserock openwrt port, but maybe demostrating an openwrt system being built under baserock is possible? | 19:30 |
| paulsherwood | rdale: both :) | 19:30 |
| paulsherwood | rdale: http://paste.baserock.org/sakotukore | 19:50 |
| rdale | i think uhttpd is lorried, and so it should be upstream:openwrt/uhttpd | 19:52 |
| pedroalvarez | jjardon: both lorries fixed (gnome-shell and perl) | 19:55 |
| paulsherwood | rdale: http://paste.baserock.org/holozejoxu did you do something to it? | 19:56 |
| jjardon | pedroalvarez: thanks! :) | 19:56 |
| pedroalvarez | jjardon: keep reporting them, even if you don't mind they are not up-to-date. Is useful to know all of these problems | 19:57 |
| paulsherwood | rdale: ? | 20:09 |
| *** zoli__ has quit IRC | 20:32 | |
| *** Albert has quit IRC | 21:20 | |
| * paulsherwood gives up and tries master | 21:46 | |
| * radiofree is glad he checked on this build, nearly up to qtwebkit and forgot to do "swapon" | 21:47 | |
| paulsherwood | is that on jetson? | 21:48 |
| radiofree | yes | 21:49 |
| paulsherwood | have you tried ybd on one yet? | 21:50 |
| radiofree | not yet, i think that's more "something for the weekend", the one i have is currently very incrementally getting to version 0.1 of the genivi demo platform | 21:51 |
| radiofree | tweak, rebase against master... rebuild from core | 21:51 |
| paulsherwood | ah, right | 21:51 |
| radiofree | i really need to e-mail the gdp mailing list as well.... the genivi demo platform: a tale of two genivis | 21:52 |
| paulsherwood | you've reminded me, there was discussion about getting the gdp to be discussed on genivi-projects, as opposed to meta-ivi | 21:54 |
| paulsherwood | i should follow up on that | 21:54 |
| radiofree | yes, needs to be discussed properly | 21:55 |
| paulsherwood | rdale: http://paste.baserock.org/figezolise another one | 21:56 |
| radiofree | if it's supposed to be a demonstration of upstream genivi components it's failing miserably, based on the number of patches anyone integrating have to apply to these components to get this g-d-p to do anything | 21:56 |
| paulsherwood | i feel your pain, rdale | 22:00 |
| paulsherwood | radiofree, i mean | 22:00 |
| rjek | My libvirt clone has finally finished. Sadly my ansible role has failed. | 22:23 |
| * rjek mutters; #ansible tells me to use Vagrent and he's not happy about that. | 22:23 | |
| * rjek does not want to have to learn another tool just to do something he already knew how to do. | 22:26 | |
| * rjek sadfaces and beds. | 22:26 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
