| *** seb__ has joined #baserock | 01:04 | |
| *** seb__ has quit IRC | 02:19 | |
| *** rdale_ has joined #baserock | 02:31 | |
| *** rdale has quit IRC | 02:34 | |
| *** seb__ has joined #baserock | 02:44 | |
| *** seb__ has quit IRC | 03:10 | |
| *** seb__ has joined #baserock | 04:05 | |
| *** seb__ has quit IRC | 04:10 | |
| *** zoli__ has joined #baserock | 04:47 | |
| *** zoli___ has joined #baserock | 05:28 | |
| *** zoli__ has quit IRC | 05:30 | |
| *** franred has joined #baserock | 06:04 | |
| *** seb__ has joined #baserock | 06:05 | |
| *** zoli__ has joined #baserock | 06:34 | |
| *** zoli___ has quit IRC | 06:37 | |
| *** zoli__ has quit IRC | 06:38 | |
| *** zoli__ has joined #baserock | 06:57 | |
| *** a1exhughe5 has joined #baserock | 07:01 | |
| *** seb__ has quit IRC | 07:04 | |
| straycat | Do we know what's going on with https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:ostree-staging+topic:ostree ? | 07:13 |
|---|---|---|
| *** mariaderidder has joined #baserock | 07:33 | |
| *** mike has joined #baserock | 08:04 | |
| *** bashrc_ has joined #baserock | 08:04 | |
| *** mike is now known as Guest49443 | 08:04 | |
| Kinnison | It's incomplete and has issues | 08:11 |
| Kinnison | I know richard_maw has been pondering it | 08:11 |
| *** edcragg has joined #baserock | 08:12 | |
| *** jonathanmaw has joined #baserock | 08:19 | |
| *** Guest49443 has quit IRC | 08:19 | |
| *** Guest49443 has joined #baserock | 08:32 | |
| *** seb__ has joined #baserock | 08:34 | |
| *** gary_perkins has joined #baserock | 08:43 | |
| *** seb__ has quit IRC | 08:56 | |
| richard_maw | it's all parked pending moving everything into /usr. We may be able to improperly do it by having a configuration extension merge /bin and /usr/bin etc., and move everything in /etc and /var into /usr/share/factory or /usr/etc | 08:58 |
| pedroalvarez | is that going to be needed for ostree? why? | 09:17 |
| radiofree | jjardon: good news is that the new mesa swrast dri driver works for most things! bad news is if you use a qt5 qml app and set "QT_WAYLAND_DISABLE_WINDOWDECORATION=1" there's a segfault | 09:18 |
| richard_maw | pedroalvarez: it deduplicates all files by hardlinking, so all empty files are the same, so when /etc/machine-id is written all empty files now contain the machine id | 09:20 |
| SotK | I want to send a patch to put all the deployment extensions which currently live in morphlib in definitions, whilst copying their history too. I've done this with `git filter-branch` in a morph checkout to get just the relevant history, then merged the result into definitions. | 09:22 |
| jjardon | radiofree: :( does this happen with the hardware accelerated driver as well? | 09:22 |
| radiofree | nope | 09:22 |
| Kinnison | SotK: sounds complex | 09:23 |
| radiofree | jjardon: the crash is in mesa's swrast driver | 09:23 |
| SotK | I fear that if I try to push this to Gerrit it will either try to create hundreds of changes or not work correctly | 09:23 |
| Kinnison | SotK: is the history valuable? | 09:23 |
| richard_maw | yes | 09:23 |
| Kinnison | i.e. valuable for being *in* definitions | 09:23 |
| jjardon | radiofree: time to file a bug report? | 09:23 |
| Kinnison | rather than the add commit saying "look at history from commit X in morph" ? | 09:23 |
| radiofree | jjardon: yeah, i'll try master then submit a bug | 09:23 |
| SotK | it means that git blame will still work without having to go looking in a different repo | 09:24 |
| radiofree | i need to test with a "clean" version of qt5 wayland as well, just to make sure it's not something we've added | 09:24 |
| richard_maw | SotK: IMO we should have a review of your changes to strip away the dependencies, and then push outside the gerrit workflow | 09:24 |
| SotK | richard_maw: I haven't stripped any dependencies in this branch, just moved everything into one place and rearranged definitions to make it less of a mess | 09:26 |
| *** mariaderidder has quit IRC | 09:27 | |
| jjardon | Uh, seems the tarball committed to the branch we are using of binutils-redhat repo doesn't contain the same as the binutils-tarball one | 09:27 |
| richard_maw | SotK: I see. Given a normal review won't work, I'll take a look at your branch directly. | 09:29 |
| jjardon | And it actually fails if you try to build from the binutils-tarball repo | 09:29 |
| SotK | richard_maw: thanks, I'll push it once I've finished tidying it up | 09:30 |
| paulsher1ood | SotK: why not request review old-style, on the mailing list? | 09:33 |
| richard_maw | paulsher1ood: because patches can't verify that the branch has been filtered appropriately | 09:34 |
| richard_maw | paulsher1ood: there's no code change yet, so the only thing that is there to be reviewed is that it's been spliced into the history correctly | 09:34 |
| richard_maw | and that is not representable as a patch | 09:34 |
| * richard_maw assumes the patches to reduce dependencies will be re-applied later via gerrit | 09:35 | |
| SotK | indeed | 09:36 |
| *** mariaderidder has joined #baserock | 09:39 | |
| richard_maw | systemd has officially moved to github now, though AIUI they are currently trying to work out which of the 3 repositories they have is going to be the canonical one | 09:42 |
| Kinnison | Heh | 09:43 |
| Kinnison | What was their justification? | 09:43 |
| Kinnison | They were fed up of having to work when all their friends and colleagues got the day off because github was down? | 09:43 |
| richard_maw | same as ours, they couldn't keep track of patches on the mailing list | 09:43 |
| Kinnison | aah | 09:43 |
| Kinnison | So they're going for pull requests? Oh well | 09:43 |
| richard_maw | AIUI they are still going to accept patches on the mailing list, but they hope that having pull requests will result in fewer patches on the ML | 09:44 |
| richard_maw | and get some more drive-by patches from people who are better versed in github pull requests than mailing lists | 09:45 |
| Kinnison | Fair enough | 09:45 |
| Kinnison | They're high enough profile that drive-by patching is more plausible | 09:45 |
| * richard_maw has done a few drive-by patches on the mailing list | 09:46 | |
| richard_maw | they've got 1 repository which was the read-only mirror from freedesktop.org, 1 which was imports of patches submitted to the mailing list and the new 1 which they intended to make the canonical one, but they appear to be looking into repurposing the first one instead | 09:48 |
| Kinnison | The first makes sense | 09:50 |
| Kinnison | since people may already have been pulling from it | 09:50 |
| richard_maw | yep, it's also got the best name: github.com/systemd/systemd.git, the second is github.com/systemd-patches/systemd.git, the third is github.com/systemd-devs/systemd.git | 09:51 |
| pedroalvarez | ew... I just added a stratum to the top of a sytem and nothing is happening | 09:59 |
| pedroalvarez | nothing new builds | 09:59 |
| SotK | with --local-changes=include? | 10:00 |
| pedroalvarez | yes | 10:01 |
| pedroalvarez | I wonder Morph also includes files that are not even commited | 10:01 |
| pedroalvarez | (new files) | 10:01 |
| richard_maw | pedroalvarez: it didn't used to | 10:02 |
| pedroalvarez | confirmed, I'm stupid | 10:02 |
| pedroalvarez | I'm using a sha1 of a component that is already cached | 10:03 |
| * pedroalvarez changes the sha1 | 10:03 | |
| *** tpollard_ has quit IRC | 10:03 | |
| pedroalvarez | and yes, Morph includes new files in the build | 10:04 |
| * jonathanmaw remembered a time when there was `morph petrify` what's the recommended way of doing it now? | 10:08 | |
| richard_maw | of doing what? | 10:08 |
| Kinnison | replacing refs with sha1s presumably | 10:08 |
| jonathanmaw | richard_maw: ^ that | 10:08 |
| SotK | by hand afaik :( | 10:08 |
| richard_maw | I thought someone added a command for modifying definitions | 10:09 |
| paulsher1ood | richard_maw: ah, ok | 10:10 |
| jjardon | richard_maw: there is a branch for morph from sam where you can use morph petrify: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=sam/petrify-hack | 10:10 |
| radiofree | lifesaver | 10:11 |
| radiofree | although that branch is pretty old now? | 10:11 |
| jjardon | last time I tried it was easy to rebase | 10:12 |
| * jonathanmaw doesn't have enough floating refs to bother with a hacky old morph. ta, though | 10:17 | |
| paulsher1ood | pedroalvarez: fwiw ybd does use uncommitted files | 10:18 |
| *** tpollard_ has joined #baserock | 10:18 | |
| *** zoli__ has quit IRC | 10:18 | |
| pedroalvarez | apparently, Morph too | 10:18 |
| paulsher1ood | if you have the right option set :) | 10:20 |
| straycat | morph's uncommitted files are committed though, which is useful for distbuilding | 10:21 |
| paulsher1ood | good point | 10:21 |
| jjardon | mmm, seems our bootstrap process depend on some modifications made together with a gigantic commit here: http://git.baserock.org/cgi-bin/cgit.cgi/delta/binutils-redhat.git/log/?h=baserock/build-essential :( | 10:24 |
| jjardon | Im getting "configure: error: C++ preprocessor "/lib/cpp" fails sanity check" trying to compile stage2-binutils. Does it ring a bell to anyone? | 10:25 |
| paulsher1ood | jjardon: with morph? | 10:25 |
| * paulsher1ood had that error a lot with ybd initially | 10:25 | |
| jjardon | yes, with morph | 10:26 |
| pedroalvarez | ew.. I don't understand Morph today | 10:27 |
| paulsher1ood | iirc Kinnison was usually the solution to problems like that :) | 10:27 |
| pedroalvarez | I've just created a stratum, which is a copy of foundation but only with things related to systemd (and systemd itself). I added this stratum to a system, without modifying foundation, and now I'm building things from tools.morph | 10:28 |
| Kinnison | pedroalvarez: did you fail to change the name: field? | 10:29 |
| richard_maw | did this system already contain foundation? | 10:29 |
| * SotK pushes his all-extensions-in-definitions branch: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/?h=baserock/adamcoldrick/all-exts-in-definitions | 10:30 | |
| *** tpollard_ has quit IRC | 10:32 | |
| *** CTtpollard has joined #baserock | 10:32 | |
| * richard_maw is reading the changes | 10:34 | |
| pedroalvarez | Kinnison, richard_maw: the system has foundation, and also the new sytemd stratum. And I didn't change the name of anything. | 10:34 |
| paulsher1ood | SotK: looks tidy :) would it make any sense to call it deployment rather than extensions? | 10:34 |
| Kinnison | pedroalvarez: my point is, if you didn't change the name: in your systemd stratum it might be squiffing 'foundation' | 10:34 |
| richard_maw | pedroalvarez: it's likely going insane because systemd indirectly depends on itself | 10:35 |
| Kinnison | oh if your chunks have the same names it'll be confused yes | 10:35 |
| pedroalvarez | Kinnison: Indeed, but I though we were immune to that "bug" | 10:35 |
| Kinnison | hahaha | 10:35 |
| pedroalvarez | richard_maw: hm.. no, new systemd stratum doesn't depend on foundation | 10:35 |
| Kinnison | pedroalvarez: no, we're very vulnerable to it, as is ybd | 10:36 |
| richard_maw | pedroalvarez: ok, differently insane then | 10:36 |
| Kinnison | but at least ybd reports it | 10:36 |
| richard_maw | SotK: Is there any way to filter out the merge commits in the right parent of the commit to merge extensions into definitions? | 10:36 |
| pedroalvarez | Kinnison, richard_maw: ok, understood. Thanks for clarifying | 10:37 |
| richard_maw | SotK: Otherwise it looks good to me. | 10:37 |
| jjardon | paulsher1ood: any idea how did you fix it? | 10:45 |
| paulsher1ood | jjardon: cant remember, sorry - but Kinnison is normally expert in this kind of thing? I can try building on ybd if you want to put a branch somewhere? | 10:47 |
| *** zoli__ has joined #baserock | 10:47 | |
| paulsher1ood | SotK: does this need a VERSION update? | 10:50 |
| * paulsher1ood also notices that README still talks about morphs, but that's a separate issue | 10:50 | |
| pedroalvarez | jjardon: have you checked the differences between that version of binutils and the version we are using? | 10:51 |
| jjardon | paulsher1ood: not sure is a tooling issue, but thanks for trying: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=jjardon/binutils-tarball | 10:51 |
| jjardon | pedroalvarez: yes | 10:52 |
| pedroalvarez | jjardon: are they massive? | 10:52 |
| jjardon | and its quite different | 10:52 |
| jjardon | yep | 10:52 |
| paulsher1ood | jjardon: which target are you building? | 10:52 |
| jjardon | paulsher1ood: systems/base-system-x86_64-generic.morph | 10:53 |
| pedroalvarez | jjardon: is this relevant? http://git.baserock.org/cgi-bin/cgit.cgi/delta/binutils-redhat.git/commit/?h=baserock/build-essential&id=e7277 | 10:54 |
| jjardon | pedroalvarez: yes, I think so | 10:54 |
| jjardon | pedroalvarez: actually, I think thats the solution of the problem, thanks! :) | 10:55 |
| pedroalvarez | great! | 10:55 |
| * paulsher1ood stops :) | 10:56 | |
| * straycat isn't sure about having to write 'extensions/type' in the cluster | 11:00 | |
| straycat | but other than that, seems better | 11:02 |
| jjardon | pedroalvarez: thinking twice, we now generate a c++ compiler in stage 1, so maybe that hack is not necessary anymore, let me try one thing | 11:17 |
| *** pacon has joined #baserock | 11:29 | |
| jjardon | what build-mode: bootstrap means? | 11:30 |
| *** lachlanmackenzie has joined #baserock | 11:34 | |
| jjardon | mmm, any idea why after this the stage2-binutils build still fail with the same cpp error? http://paste.baserock.org/ahowavuqow in this case stage2-binutils has the same build-deps as stage2-gcc, wich needs a g++ compiler as well | 11:37 |
| straycat | in bootstrap mode the chunk has access to the host's tools | 11:55 |
| SotK | paulsher1ood: thankfully not, working around needing to do that is why the clusters now say things like "type: extensions/kvm" and systems list configuration extensions simlarly. | 11:58 |
| jjardon | ah, ok, thanks straycat | 11:58 |
| SotK | straycat: I'm not a huge fan either, but other than causing a version increase (and therefore needing a release doing before it can be fixed) there is nothing stopping us patching morph to return to the old look whilst keeping the extensions in a subdir | 11:59 |
| SotK | paulsher1ood: I think I prefer "extensions" to "deployment", but thats probably because I'm used to thinking of them as "extensions" rather than something more generic and so am happy to change it based on other people's opinions | 12:00 |
| * straycat nods | 12:01 | |
| SotK | richard_maw: I'm not sure what you mean by that :/ | 12:06 |
| * SotK wonders what paulsher1ood means when he says YBD builds without creating a graph | 12:13 | |
| SotK | paulsher1ood: do you still want YBD to look in $ybd-source-dir/exts for deployment extensions? | 12:16 |
| *** lachlanmackenzie has quit IRC | 12:23 | |
| * richard_maw suspects YBD does actually use a graph, but that it's virtual rather than explicit | 12:35 | |
| SotK | that is how it appears to me after looking at the code | 12:36 |
| * straycat wonders how ybd would do loop detection readably without constructing a graph | 12:37 | |
| rjek | Mark nodes already built? | 12:51 |
| Kinnison | that'd imply a graph for there to be nodes | 12:51 |
| rjek | A hash table containing already-built things? | 12:54 |
| paulsher1ood | ybd recurses, and doesn't rebuild what's already there | 12:54 |
| paulsher1ood | (notices the artifact) | 12:55 |
| paulsher1ood | hence no graph | 12:56 |
| rjek | How deep can Python recurse? :) | 12:57 |
| paulsher1ood | deep enough for all of the current definitions in release.morph, for example | 12:59 |
| paulsher1ood | /win 36 | 12:59 |
| paulsher1ood | bah :) | 12:59 |
| richard_maw | The graph in this case is your call stack then. You're evaluating a graph you didn't explicitly construct, which means you can't reason about it before traversal, which we require to be able to provide a list of steps involved. | 13:02 |
| * SotK doesn't see how that means there isn't at least a virtual graph there | 13:02 | |
| wdutch | to be fair you can call anything a graph, a graph is a collection of things and relationships between things. It's only meaningful if you use graph-like metaphors | 13:03 |
| paulsher1ood | wdutch: thanks :) | 13:03 |
| paulsher1ood | richard_maw: why do we require a list of steps? | 13:03 |
| straycat | *readably* | 13:04 |
| * paulsher1ood has not found any requirement requiring reasoning about a graph before traversal so far | 13:04 | |
| * straycat sighs | 13:04 | |
| richard_maw | Well for one it provides the counter of build steps you requested way back. | 13:04 |
| rjek | Progres... what richard_maw said | 13:04 |
| straycat | paulsher1ood, https://gerrit.baserock.org/#/c/219/1 | 13:04 |
| rjek | Also you can warn about loops and perhaps other states before you even begin. | 13:04 |
| paulsher1ood | ok, that's one | 13:05 |
| straycat | but anyway, i was only wondering how you'd solve that problem differently | 13:05 |
| straycat | wasn't saying you couldn't solve it differently :) | 13:05 |
| paulsher1ood | iiuc ybd warns about loops.... morph doesn't | 13:05 |
| straycat | 14:06 straycat$ paulsher1ood, https://gerrit.baserock.org/#/c/219/1 | 13:06 |
| richard_maw | morph does in the cases it understands, but we don't currently put loops in our test suite, so it breaks occasionally | 13:06 |
| paulsher1ood | straycat: thanks :) | 13:06 |
| straycat | paulsher1ood, where does ybd do that, just curious | 13:07 |
| paulsher1ood | ybd understands, and warns, and from my pov has no graph and no test suite (except that i run it on real data all the time). i know this is philosophically different from others' recommended approach :) | 13:08 |
| SotK | ISTM that the graph in YBD is represented in the dict in the Definitions object. The dict contains dicts which represent individual definitions, which have dependencies. The dependencies are a list of keys for the Definitions dict (ie "edges" connecting the "nodes"/individual definition dicts). | 13:08 |
| paulsher1ood | that may be true | 13:09 |
| richard_maw | is *is* true | 13:09 |
| straycat | paulsher1ood, i'm literally asking where you do that, cause i couldn't quickly find any warning messages that might indicate loop detection | 13:09 |
| richard_maw | you *do* have a graph | 13:09 |
| SotK | This is then traversed recursively when you build. | 13:09 |
| richard_maw | and any claims otherwise are just winding people up at this point | 13:09 |
| * richard_maw wonders if he can mute himself | 13:09 | |
| paulsher1ood | ok, i'm wrong then. i'm not trying to wind anyone up. i didn't do comp sci | 13:09 |
| richard_maw | neither did other people here who see it as a graph | 13:10 |
| pedroalvarez | ok, this topic is over :) | 13:11 |
| paulsher1ood | thanks :) | 13:11 |
| richard_maw | yes, and it turns out I'm not able to mute myself | 13:11 |
| paulsher1ood | straycat: i may be wrong about the loop detection, too. i remember hitting examples, and putting code in to deal with it when it happened, but that was a long time ago. | 13:12 |
| * paulsher1ood gets back to work | 13:12 | |
| straycat | it's fine, i'm just sore cause whenever i make patches that involve graphing they never get merged :3 | 13:13 |
| straycat | but hey, that's what weekends are for right | 13:13 |
| straycat | in any case we can't merge that cause it's not exactly sane | 13:13 |
| *** lachlanmackenzie has joined #baserock | 13:22 | |
| * jjardon manages to build a pristine binutils tarball without the c++ hack | 13:31 | |
| paulsher1ood | w00t! | 13:31 |
| jjardon | the patch turns out to be quite simple: http://paste.baserock.org/xitiqoweji | 13:32 |
| SotK | richard_maw: what did you mean by "filter out the merge commits in the right parent of the commit to merge extensions into definitions" earlier? | 13:38 |
| richard_maw | oh sorry, I forgot to respond to that | 13:38 |
| richard_maw | there's merge commits like http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/adamcoldrick/all-exts-in-definitions&id=806de84bee5727d86059837ff62a9bf92aa54e8f in your history | 13:38 |
| richard_maw | which don't appear to touch or be related in any way to the extensions | 13:39 |
| SotK | oh, I see | 13:39 |
| SotK | indeed they don't, I'm not entirely sure why they ended up not being filtered out... I'll see if I can get rid of them | 13:39 |
| richard_maw | cheers | 13:40 |
| richard_maw | if not, no big loss, so don't waste too much time on it | 13:40 |
| *** seb__ has joined #baserock | 13:48 | |
| pedroalvarez | jjardon: make sure you don't break cross-bootstrap :) | 13:50 |
| *** pacon has quit IRC | 13:52 | |
| jjardon | pedroalvarez: you mean the generation of systems/cross-bootstrap-system-* systems? | 13:54 |
| pedroalvarez | jjardon: yes | 13:55 |
| jjardon | ok | 13:56 |
| jjardon | is it ok to run 2 or more "morph build" instances at the same time? Or does morph make any assumption of being the only build process running? | 13:57 |
| richard_maw | it makes assumptions, so concurrent cache access may be an issue, as would any mount namespacey things, though I think I got most of those | 13:57 |
| SotK | richard_maw: I think this should be better now: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/adamcoldrick/all-exts-in-definitions-v2 | 13:58 |
| richard_maw | SotK: +2, are you able to push that to the gerrit master yourself or do you need to have someone else do it? | 13:59 |
| SotK | I can push I think | 13:59 |
| SotK | +2 for all 4 commits? | 13:59 |
| richard_maw | yes | 14:00 |
| SotK | thanks :) | 14:00 |
| * SotK pushes | 14:00 | |
| straycat | cool | 14:00 |
| pedroalvarez | "4 commits" | 14:00 |
| richard_maw | pedroalvarez: well, we've already approved all the others elsewhere | 14:01 |
| pedroalvarez | :) | 14:02 |
| SotK | turns out I don't have permissions to push to master on gerrit :3 | 14:03 |
| pedroalvarez | you can push to master of g.b.o | 14:04 |
| SotK | ok then, I'll do that | 14:04 |
| straycat | hang on? | 14:04 |
| pedroalvarez | ok, hang on | 14:04 |
| * SotK hangs | 14:04 | |
| pedroalvarez | straycat: yes? | 14:04 |
| straycat | last time i pushed to gbo, people asked me not to because it can mess up the replication gerrit does | 14:04 |
| richard_maw | we're going to push to the gerrit branch, not the g.b.o branch | 14:04 |
| richard_maw | that should be replicated properly | 14:05 |
| straycat | 15:05 +pedroalvarez$ you can push to master of g.b.o | 14:05 |
| richard_maw | good catch straycat | 14:05 |
| richard_maw | I missed that | 14:05 |
| richard_maw | yes, definitely don't push to g.b.o | 14:05 |
| pedroalvarez | <SotK> turns out I don't have permissions to push to master on gerrit :3 | 14:05 |
| * SotK doesn't do that | 14:05 | |
| straycat | i think we should give SotK perms | 14:05 |
| * richard_maw agrees but lacks the perms to give SotK perms | 14:06 | |
| straycat | pedroalvarez, do you have perms to set perms so SotK can have perms? | 14:06 |
| * pedroalvarez hms | 14:06 | |
| rjek | We need some sort of graph tracking perm dependancies. | 14:06 |
| pedroalvarez | I have perms to give anyone perms to give perms | 14:07 |
| straycat | cool | 14:07 |
| richard_maw | pedroalvarez: Can I have perms to give SotK perms to push? | 14:07 |
| Zara | I keep tabbing into channel and thinking you're all talking about your hair. | 14:07 |
| pedroalvarez | but they are complex, let me have a look | 14:07 |
| pedroalvarez | richard_maw: you would become part of the baserock-ops team | 14:07 |
| richard_maw | hm, I'll pass then | 14:08 |
| pedroalvarez | SotK: can you try now? | 14:11 |
| * paulsher1ood is on Moonshot, manages to git clone Linux repo... 1,034,023,424 25.2MB/s in 32s | 14:11 | |
| pedroalvarez | paulsher1ood: note that you only have 2 vcp and 2G Ram | 14:12 |
| pedroalvarez | s/vcp/vCPUs/ | 14:12 |
| * SotK pushes successfully | 14:13 | |
| SotK | thanks pedroalvarez, straycat, richard_maw | 14:13 |
| pedroalvarez | If we don't want people pushing to g.b.o, can we disable that? | 14:13 |
| * pedroalvarez reverts the change | 14:14 | |
| SotK | +1, I think that was the original plan too? | 14:14 |
| pedroalvarez | I'm interested on the -1's. I'm sure there is someone that doesn't like the idea | 14:15 |
| jjardon | pedroalvarez: you mean all g.b.o? or only the baserock/ namespace | 14:16 |
| pedroalvarez | jjardon: hm.. maybe only master branch of baserock/* projects? | 14:16 |
| jjardon | Im ok with that | 14:17 |
| Kinnison | that'd be a pretty simple patch providing it's easy to identify how gerrit pushes | 14:18 |
| pedroalvarez | oh, true, we can't block everyone :) | 14:20 |
| paulsher1ood | i know this is not exactly the right place to ask, but how would i install normal tools (gcc, make, autotools etc) on a vanilla ubuntu? | 14:26 |
| rdale_ | apt-get intall build-essential? | 14:26 |
| paulsher1ood | ah, ok | 14:27 |
| paulsher1ood | http://paste.baserock.org/hisojuvufe | 14:28 |
| paulsher1ood | :( | 14:28 |
| radiofree | paulsher1ood: apt-get update | 14:28 |
| radiofree | then do install build-essential | 14:28 |
| radiofree | i think (me doesn't use debian) | 14:29 |
| * radiofree doesn't use debian | 14:29 | |
| paulsher1ood | seems to be working, thanks radiofree ! | 14:29 |
| rjek | You might also want manpages-dev | 14:33 |
| rjek | Which enragingly is not considered essential :) | 14:33 |
| pedroalvarez | Warning with new systemd 220: http://paste.baserock.org/raw/yogisuvava | 14:35 |
| wdutch | is there any documentation anywhere on morph plugins? I don't see anything in --help, the man page or the wiki but maybe I should be looking for something other than 'plugin'? | 14:36 |
| mwilliams_ct | wdutch: maybe extensions are what you mean? | 14:36 |
| SotK | wdutch: you mean the existing plugins? `morph help $command` should work | 14:36 |
| wdutch | SotK: I'm trying to install firehose but just getting a cliapp error "ERROR: unknown subcommand firehose" | 14:38 |
| wdutch | although now I try again I get a different error, time to figure out what I did ... | 14:38 |
| SotK | you need to set MORPH_PLUGIN_PATH to include the directory containing the firehose plugins I imagine | 14:39 |
| wdutch | it looks like firehose.sh does that | 14:39 |
| SotK | hmm, what was the other error you got? | 14:40 |
| wdutch | ERROR: Expected list of firehoses on command line | 14:40 |
| SotK | that sounds like it found the plugin at least that time :) | 14:41 |
| bashrc_ | I think I had similar issues with firehose | 14:41 |
| * SotK doesn't really know much about how firehose is expected to work | 14:42 | |
| perryl | wdutch: you'll need to run one of the YAML files as an argument, they should be in the firehose/examples/ directory | 14:42 |
| wdutch | thanks perryl | 14:42 |
| straycat | what's stopping the merge of https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/firehose+branch:master+topic:bmottram/firehose ? | 14:43 |
| Zara | is that info about running firehose in a readme or on the wiki anywhere? | 14:43 |
| wdutch | Zara: there are instructions for installation in the README | 14:43 |
| wdutch | at least in some branches | 14:44 |
| wdutch | does gerrit provide a way to see merge conflicts? or do I just checkout, merge and see for myself? | 14:46 |
| perryl | i was reviewing the README but wanted to test the instructions worked correctly first, and ran out of time | 14:47 |
| bashrc_ | wdutch: are you using the perryl branch of firehose? I think there were various problems - especially contextmanager - which were resolved in my patch series | 14:47 |
| straycat | richard_maw, any reason not to merge https://gerrit.baserock.org/#/c/679/3 if i give it a +1? | 14:47 |
| wdutch | bashrc_: I think I've checkout'd your patch series (or whatever gerrit calls them) | 14:49 |
| richard_maw | straycat: depends if you feel more strongly about requiring more comments about needing to keep the version numbers up to date | 14:49 |
| straycat | rdale_ suggested checking the version number into the bison repo, i don't see why that's better | 14:49 |
| bashrc_ | wdutch: ok, contextmanager should be ok then, but I do remember that being a cause of command not found | 14:49 |
| bashrc_ | or "unknown subcommand" | 14:50 |
| richard_maw | that was because it was accidentally applied to the class | 14:50 |
| richard_maw | because it belonged to a function that got removed during a rewrite | 14:50 |
| jmacs | What sets the size of /tmp on a baserock linux system? | 14:50 |
| paulsher1ood | win 19 | 14:50 |
| paulsher1ood | gahhhhhh | 14:51 |
| richard_maw | jmacs: systemd sets it to a percentage of your available ram | 14:51 |
| rdale_ | straycat: i believe the version number for bison is part of the tarball, so we just need to not remove it when we check the tarball into the lorry repo | 14:51 |
| richard_maw | rdale_: and what happens if we use bison from git? | 14:51 |
| richard_maw | we should be using things from git rather than their tarballs when possible | 14:51 |
| radiofree | jmacs: if you need a bigger one you can add it to your fstab | 14:52 |
| jmacs | I keep running out of space on /tmp trying to do a morph upgrade; is this a common problem? | 14:52 |
| jmacs | radiofree: I tried adding it to fstab, no effect | 14:52 |
| rdale_ | in that case we would need to add the version to the git repo, if we wished to avoid using git at build time in baserock builds as i think we should | 14:52 |
| radiofree | jmacs: try telling systemd not to do it `systemctl mask tmp.mount` | 14:52 |
| rdale_ | richard_maw: or we can just create the version file in the bison chunk as my patch does at the moment | 14:53 |
| straycat | adding the version to the git repo seems like an unnecessary delta | 14:54 |
| * richard_maw wants version-commands | 14:54 | |
| richard_maw | shove a bunch of information about the build in the environment and let it write the .gitversion file or equivalent | 14:55 |
| jmacs | Right, adding a tmpfs line to fstab and then mount -o remount /tmp seems to have done it | 14:55 |
| straycat | so what do we prefer, depending on git, or having to hardcode version information in a chunk morph? | 14:57 |
| richard_maw | but until and unless we have version-commands, adding the version file in pre-configure commands and keeping comments about needing to keep it in sync when the sha1 changes is the least awful approach | 14:57 |
| jmacs | I don't get it, I've got 6GB clear on /tmp now and it's still running out of space | 14:57 |
| straycat | jmacs, might it just be running out of disk space on the rootfs rather than /tmp, i've had that quite a lot | 14:58 |
| richard_maw | straycat: I'd prefer us to move away from depending on git, as it's technically a reproducibility hole | 14:58 |
| straycat | oh? | 14:58 |
| richard_maw | there's nothing stopping it doing a `git checkout` to a different branch | 14:59 |
| richard_maw | and we've occasionally been hit with a more minor but more likely issue | 14:59 |
| richard_maw | namely that `git describe` works on the entire contents of the repository, rather than the current checkout | 14:59 |
| straycat | ahh | 14:59 |
| richard_maw | and we only use the sha1 of the current checkout in the cache key | 15:00 |
| richard_maw | it's not completely insane that there would be a component that during ./autogen.sh notices that it's run from a git checkout and checks out the most recent tagged release unless you pass an extra option, to stop people accidentally building the development head instead of a stable version | 15:01 |
| richard_maw | yeah, it's awful, but I can see a chain of events leading to it being an approach that is taken | 15:01 |
| * straycat nods | 15:02 | |
| straycat | rdale_, i'm happy to merge https://gerrit.baserock.org/#/c/679, but will add comments on merge, does this seem okay? | 15:02 |
| * richard_maw is re-bootstrapping a system after adding strip-commands | 15:03 | |
| richard_maw | Conditionalised on `version: 5` in the VERSION file too! | 15:03 |
| rdale_ | straycat: yes please merge. i not sure if i have much of an opinion about where the version should go, i mainly want core.morph to not include git and curl | 15:03 |
| straycat | we seem to think leaving it in the chunk morph is the least awful option | 15:04 |
| rdale_ | fine with me | 15:05 |
| richard_maw | rdale_: I'd be fine with leaving curl in there. Git being in there is an unfortunate hack because of tools that fetch their version from git. | 15:05 |
| rdale_ | ok | 15:05 |
| rdale_ | i only know of bison doing that in the core stratum | 15:06 |
| jmacs | straycat: The error I'm getting is http://paste.baserock.org/zacipobune, looks like /tmp to me | 15:06 |
| pedroalvarez | radiofree: do you know if I should be worried about these warnings? http://paste.baserock.org/xivovegigo | 15:06 |
| jmacs | I have 1GB spare on / | 15:06 |
| jmacs | I'm probably doing something very stupid as I can't think clearly today | 15:06 |
| radiofree | pedroalvarez: no | 15:07 |
| pedroalvarez | ok then :) | 15:07 |
| richard_maw | jmacs: the /tmp path is just because it's mounting your root disk on a tempdir | 15:07 |
| richard_maw | jmacs: it will be that / is too small | 15:07 |
| jmacs | OK, I shall fix that then | 15:08 |
| jmacs | I can't see what's going on as it removes the tmp.y9L71cJHme link | 15:08 |
| pedroalvarez | jmacs: that was only a mount point | 15:09 |
| pedroalvarez | jmacs: you can do `mount /dev/sda /mnt` to have the same thing in /mnt | 15:10 |
| jmacs | What's only a mount point? | 15:12 |
| * straycat isn't using workspaces anymore, thanks to sam's patch, it's pretty nice | 15:13 | |
| pedroalvarez | woo | 15:14 |
| pedroalvarez | is it ready? | 15:14 |
| pedroalvarez | /tmp/tmp.y9L71cJHme | 15:14 |
| straycat | well i haven't been able to find much wrong with it :) | 15:14 |
| *** bwh has quit IRC | 15:15 | |
| *** petefotheringham has quit IRC | 15:15 | |
| *** petefotheringham has joined #baserock | 15:15 | |
| *** bwh has joined #baserock | 15:15 | |
| pedroalvarez | ok, systemd v220 worked well in trove & distbuild | 15:17 |
| pedroalvarez | testing now openstack | 15:17 |
| *** zoli__ has quit IRC | 15:17 | |
| Kinnison | cool | 15:17 |
| tlsa | anyone able to +2 this for merge? https://gerrit.baserock.org/#/c/754/ | 15:18 |
| pedroalvarez | tlsa: "which can be useful".. does that mean that you don't know yet if you are going to use it or not? | 15:20 |
| pedroalvarez | the lorry looks ok, but I want to avoid things in g.b.o that aren't needed | 15:22 |
| pedroalvarez | Maintaining them is really painful | 15:22 |
| straycat | richard_maw, https://gerrit.baserock.org/#/c/679/4 is this fine with you? | 15:22 |
| tlsa | to get deterministic builds we need to do things like provide a consistent built hostname and time. libfaketime is used by gitian for this, and seems to be more than enough for our needs, from my investigations | 15:24 |
| rdale_ | did you see the talk at fosdem about reproducible builds? | 15:25 |
| tlsa | pedroalvarez: it can be useful for other things too, but I'm not interested in them at the current time. | 15:25 |
| pedroalvarez | tlsa: I wonder if you can use "https://github.com/wolfcw/libfaketime.git" in your definitions and wait for the lorry once you have something ready | 15:26 |
| tlsa | can do | 15:27 |
| straycat | can we abandon https://gerrit.baserock.org/#/c/560/ ? | 15:27 |
| straycat | jjardon, ^ | 15:27 |
| richard_maw | tlsa: I'd prefer if we could do something with namespaces, but we can't do time with that even if we could patch our tooling to allow changing the hostname. | 15:28 |
| jjardon | straycat: why? | 15:28 |
| tlsa | namespaces? | 15:29 |
| Kinnison | jjardon: because you've done nothing to advance it since May 27th ? | 15:30 |
| straycat | jjardon, cause there's no clear plan to do anything with it | 15:30 |
| richard_maw | tlsa: you can have a different UTS namespace between processes, which lets different processes have a different hostname or domain name. | 15:30 |
| jjardon | Kinnison: I did | 15:30 |
| richard_maw | tlsa: so you don't need a LD_PRELOAD to intercept the result of those syscalls | 15:31 |
| Kinnison | jjardon: You've done nothing visible then | 15:31 |
| tlsa | richard_maw: right | 15:31 |
| richard_maw | tlsa: but there's nothing namespacey to do time fixing in-kernel | 15:32 |
| tlsa | mm | 15:32 |
| tlsa | ok | 15:32 |
| jjardon | Kinnison: I think I replied to the requested questions | 15:32 |
| Kinnison | your reply isn't in gerrit | 15:32 |
| jjardon | straycat: ok, I will abandon and maybe resubmit when I will use it for something. Is this a new policy | 15:33 |
| pedroalvarez | I'd like a policy like that | 15:33 |
| richard_maw | we could drop all the ostree patches with a policy like that | 15:33 |
| straycat | not exactly, but it seems logical to request lorries when we know for sure that we want them | 15:34 |
| tlsa | What's the pain from maintaining lorries? | 15:35 |
| richard_maw | that downstream troves also get them | 15:35 |
| tlsa | they might have tiny discs, or something? | 15:35 |
| jjardon | Kinnison: they are, please be specific if you want to discuss about something | 15:35 |
| jjardon | straycat: abandoned | 15:36 |
| straycat | cheers | 15:36 |
| richard_maw | straycat, rdale_: bison change approved and merged | 15:41 |
| jjardon | maybe downstream troves should have the capability to choose what repos want to mirror? | 15:41 |
| rdale_ | great, thanks | 15:41 |
| richard_maw | jjardon: they do, that doesn't mean we should be offering repositories we don't currently have a use for and may later remove | 15:42 |
| richard_maw | since then the burden of continuing to update that repository is moved onto the downstream repository | 15:42 |
| richard_maw | and we have no way to notify that this has happened currently | 15:42 |
| straycat | cool thanks richard_maw | 15:44 |
| jjardon | ok, understandable | 15:46 |
| *** a1exhughe5 has quit IRC | 15:48 | |
| jjardon | btw, Im working in a branch to separate glib and gobject-introspection from core. Is this something we want to do? Not sure if someone more replay to rdale_ mail about trying to do a smaller core | 15:48 |
| rdale_ | yes, i would prefer them in gnome-core or similar if possible | 15:49 |
| * paulsher1ood fails to build stage2-glibc on ubuntu moonshot http://paste.baserock.org/ateyezikod | 15:49 | |
| pedroalvarez | oh, re - arm64. I wonder if anybody has baserock image around | 15:50 |
| pedroalvarez | for arm64 | 15:50 |
| richard_maw | paulsher1ood: looks like a bunch of missing header defines. This is partly why we build on Baserock systems, though I'm currently waiting on a build, so I can have a bit of a poke. | 15:57 |
| *** mariaderidder has quit IRC | 15:58 | |
| *** CTtpollard has quit IRC | 16:00 | |
| paulsher1ood | richard_maw: thanks! | 16:01 |
| richard_maw | paulsher1ood: That's a bit of a headscratcher. Did we completely land the aarch64 definitions from the port? If it builds with morph then some part of ybd isn't setting up the environment for the build commands to find the sysroot where the headers are located. | 16:03 |
| richard_maw | paulsher1ood: If it fails with morph too, then the definitions are missing something to make them use the linux-api-headers that were prepared just before the stage2-glibc build. | 16:03 |
| * richard_maw will have a poke to see what provides those definitions normally | 16:04 | |
| richard_maw | I'm assuming it's linux-api-headers at the moment | 16:04 |
| * richard_maw scratches his head a little at "checking whether the compiler is using the ARM hard-float ABI... no" | 16:08 | |
| paulsher1ood | one thing, i'm assuming the target arch is armv8l64 | 16:10 |
| paulsher1ood | ? | 16:10 |
| radiofree | richard_maw: i don't think we're compiling for aarch64 HF | 16:10 |
| radiofree | also there's no guarantee the aarch64 stuff in baserock builds anymore | 16:10 |
| radiofree | there hasn't been any hardware to test it on | 16:10 |
| radiofree | i'd suggested checking out definitions from when those patches landed and see if they work | 16:11 |
| rdale_ | the linux headers for stage2 are quite old, 3.12 iirc | 16:12 |
| radiofree | i believe they have been upgraded | 16:12 |
| rdale_ | ah ok | 16:12 |
| richard_maw | they're on 4.0 | 16:12 |
| radiofree | however i know the upgrade to gcc 5 (now reverted) killed aarch64, so it's entirely possible something else has broken it | 16:13 |
| richard_maw | paulsher1ood: I'm out of ideas. Those definitions should definitely have come from the linux-api-headers, but I can't see any reason why your build shouldn't be finding them. I'd need to have a proper sit-down in front of a build debugging session to work out why it's not finding the right headers. | 16:24 |
| paulsher1ood | this could be a ybd-specific issue, of course? | 16:24 |
| richard_maw | paulsher1ood: You could see if Ubuntu offers a way to download the right kernel headers and see if it's that we depend on the host there. | 16:24 |
| paulsher1ood | richard_maw: but thanks for trying | 16:24 |
| paulsher1ood | will do | 16:24 |
| richard_maw | paulsher1ood: If it fails with morph I would have a higher degree in confidence that there's something wrong with the definitions (I'm not criticising YBD here, I'm just not familiar enough with the code). | 16:26 |
| paulsher1ood | richard_maw: yup | 16:26 |
| jjardon | rdale_: maybe you can take a look to this when you have some time: https://gerrit.baserock.org/#/c/762/ | 16:47 |
| rdale_ | jjardon: looks good to me - those two repos must have a version file in them then? | 16:51 |
| *** CTtpollard has joined #baserock | 16:53 | |
| *** franred has quit IRC | 16:54 | |
| *** bashrc_ has quit IRC | 17:01 | |
| jjardon | I think is generated in bootstrap; they compile without problems | 17:04 |
| rdale_ | ok, i've just given it a +1 then | 17:09 |
| *** CTtpollard has quit IRC | 17:11 | |
| *** jonathanmaw has quit IRC | 17:11 | |
| jjardon | What is the fastest way to see the config.log of some chunk that has been already built? | 17:15 |
| *** gary_perkins has quit IRC | 17:34 | |
| *** lachlanmackenzie has quit IRC | 17:53 | |
| *** edcragg has quit IRC | 17:55 | |
| *** Guest49443 has quit IRC | 17:55 | |
| *** CTtpollard has joined #baserock | 18:09 | |
| jjardon | Hi, Im getting a weird error trying to deploy a system: http://paste.baserock.org/susarikiwe Anyone more with the same problem? | 18:33 |
| jjardon | Oh, the extensions have been moved | 18:36 |
| jjardon | seems the problems is that essential-files/ has been moved to install-files/essential-files/ . Should I revert that or fix the essential-files extension to look in install-files/essential-files instead essential-files? | 18:46 |
| *** CTtpollard has quit IRC | 19:01 | |
| jjardon | nevermind, seems the install-files ext doesn't pick the INSTALL_FILES environment variable set in install-essential-files | 20:12 |
| *** seb__ has quit IRC | 21:33 | |
| *** jjardon has quit IRC | 22:06 | |
| *** edcragg has joined #baserock | 22:07 | |
| *** jjardon has joined #baserock | 22:45 | |
| *** edcragg has quit IRC | 23:22 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!