| *** zoli__ has quit IRC | 05:27 | |
| *** zoli__ has joined #baserock | 05:27 | |
| *** zoli___ has joined #baserock | 05:43 | |
| *** zoli__ has quit IRC | 05:43 | |
| *** zoli___ has quit IRC | 05:51 | |
| *** zoli__ has joined #baserock | 05:51 | |
| *** zoli___ has joined #baserock | 06:00 | |
| *** zoli__ has quit IRC | 06:00 | |
| *** zoli___ has quit IRC | 06:01 | |
| *** zoli__ has joined #baserock | 06:01 | |
| *** zoli__ has quit IRC | 06:34 | |
| *** zoli__ has joined #baserock | 06:34 | |
| *** zoli__ has quit IRC | 06:35 | |
| paulsherwood | i think so | 07:01 |
|---|---|---|
| * straycat thinks that would be slower, and might make it more difficult to express situations where 2 chunks build-depend on 2 different versions of the same software | 07:50 | |
| *** a1exhughe5 has joined #baserock | 08:01 | |
| *** paulw has quit IRC | 08:04 | |
| *** paulw has joined #baserock | 08:07 | |
| *** rdale has joined #baserock | 08:14 | |
| ratmice__ | also for gcc/flex/bison and other dev tools they don't necessarily need to be there at runtime | 08:17 |
| *** jonathanmaw has joined #baserock | 08:26 | |
| *** gfinney has joined #baserock | 08:27 | |
| paulsherwood | i was meaning build-depends within a stratum. could still have build-depend strata | 08:30 |
| paulsherwood | not sure why this would be slower? less logic | 08:30 |
| paulsherwood | (build-depend strata not present at runtime) | 08:31 |
| paulsherwood | the only difference achieved by the current (imo obscure) behaviour is that some chunks which will be present at runtime are caused to be absent at build-time for some other chunks | 08:33 |
| paulsherwood | straycat: for the 2 chunks build depend on different versions, have 2 different strata? isn't that how we've dealt with gstreamer, for example? | 08:36 |
| straycat | if you implicitly build-depend on everything that's in your stratum then you'll have to, for each chunk in the stratum, unpack everything that's in your stratum into the staging area, so you'll end up unpacking a ton of stuff you don't build-depend on which will slow the build time. | 08:58 |
| *** mdunford has joined #baserock | 09:04 | |
| *** bashrc_ has joined #baserock | 09:04 | |
| Kinnison | paulsherwood: massively less efficient | 09:09 |
| Kinnison | paulsherwood: because it linearises the build of a stratum | 09:09 |
| Kinnison | paulsherwood: making parallel building of systems very hard | 09:09 |
| Kinnison | paulsherwood: Morph originally built strata in-order with chunk n implicitly b-depping on n-1..0 | 09:10 |
| Kinnison | paulsherwood: we introduced build-depends proper as a way to remove this linearisation | 09:10 |
| * pedroalvarez agrees after building a 10-node distbuild network to speed up things | 09:11 | |
| Kinnison | :) | 09:11 |
| * Kinnison doesn't understand why people are arguing so much regarding this build-dependency thing -- To me it's a "simple" case of transitive dependencies (pro: brevity of declaration, con: cognitive complexity on parsing) vs. explicit dependencies (pro: clarity of declaration, con: increased cognitive load to parse the definition) | 09:13 | |
| Kinnison | Both aspects have a cognitive load | 09:13 |
| Kinnison | both aspects have plusses | 09:13 |
| Kinnison | everyone should pick a side, and then the lead architect should pick one | 09:14 |
| Kinnison | and it should be codified/documented | 09:14 |
| *** mdizzle has joined #baserock | 09:14 | |
| *** gary_perkins has joined #baserock | 09:18 | |
| *** CTtpollard has joined #baserock | 09:21 | |
| straycat | fwiw, i'm fine with build-depends as it is, it's just transitive dependencies, 's not like we're talking about abstract machines for higher-order term sharing or something | 09:21 |
| Kinnison | Cool, so that's one vote for "Keep them transitive" | 09:24 |
| *** lachlanmackenzie has joined #baserock | 09:27 | |
| SotK | I agree with straycat | 09:28 |
| Kinnison | Ruhroh, straycat is Nick Clegg? | 09:30 |
| straycat | meow what? | 09:30 |
| richard_maw | The only issue with transitive dependencies is the odd case where you explicitly don't want the indirect dependencies, but we currently only need that for things which are also in bootstrap mode, so we're probably fine keeping a special case there. | 09:36 |
| paulsherwood | Kinnison: ok, i understand the 'slower' point, now. i'll demur on 'transitive' dependencies if that's the consensus, but as i've said many times now - i believe it makes for unnecessary obscurity and thus harder for users to understand what's going on. | 09:37 |
| Kinnison | paulsherwood: I think having it not explicitly documented obscures things (and I personally would prefer explicit deps over implicit ones) but I also understand that it'll annoy other people who find the increase in b-deps sizes to be difficult to deal with | 09:38 |
| * richard_maw thinks things would be obscured worse by unreadably large dependency lists | 09:38 | |
| Kinnison | paulsherwood: hence I suggested everyone interested state their position (along with justification) and then trust to the lead architect to make an informed decision | 09:38 |
| paulsherwood | is there a lead architect? :-) | 09:40 |
| Kinnison | As far as I understand, yes, richard_maw | 09:40 |
| petefoth | /me thinks that a 'list-depends' command could be added to morph with relatively litle effort, to output the dependencies of any chunk, stratum or system, so definition files don't get verbose, but full dependency information is only ever one step away | 09:41 |
| Kinnison | petefoth: an interesting idea, and not without precedent in other systems | 09:41 |
| paulsherwood | so would it make sense to bring this to a vote? etherpad style? or some other mechanism? | 09:42 |
| * petefoth suspects that most fo the code to do it already exists, bioth in morph and in ybd | 09:42 | |
| paulsherwood | petefoth: you may be correct :) | 09:42 |
| Kinnison | paulsherwood: it's not a vote | 09:42 |
| SotK | petefoth: you are correct | 09:42 |
| Kinnison | paulsherwood: it's everyone interested expressing their opinion and then accepting that whatever the lead-architect chooses is "right" for the project | 09:42 |
| * Kinnison doesn't think software projects work well as democracies | 09:43 | |
| petefoth | Benevolent dictatorship, with consultation FTW! | 09:43 |
| paulsherwood | sorry, i mis-spoke. where/how do you suggest folks communicate this opinion for richard_maw's consideration? is the existing ml and irc discussion already enough? (or too much :) ) | 09:43 |
| Kinnison | up to richard_maw | 09:43 |
| * paulsherwood was advocating benevolent dictatorship when richard_maw was still at school, incidentally :-) | 09:44 | |
| bashrc_ | :) | 09:44 |
| petefoth | :) | 09:44 |
| SotK | petefoth: except chunk dependencies are "interesting" with our current definitions format unless you know at least which stratum the chunk is in | 09:45 |
| petefoth | SotK: implementation detail! ;) | 09:45 |
| franred | is not the dependencies information available when we build the build-graph? I though also that that information is available via command line, but I can be wrong | 09:47 |
| richard_maw | It's currently just all speculation as to whether making transitive dependencies explicit is more or less readable. I think we've already discussed all the relevant points. I don't believe we'll get any further without someone making a tool to mechanically alter the definitions to make them declare all their indirect dependencies. | 09:48 |
| richard_maw | Since we'd need a script to do the migration if we later decided to go down this route anyway, we could at least save some manual effort in the translation phase if we decide to go down this route, and if we don't at least we can say that we tried it and avoid having to expend time in further discussions. | 09:50 |
| *** pacon has joined #baserock | 09:51 | |
| bashrc_ | in the wild, how often are transitive dependency issues encountered? | 09:51 |
| SotK | franred: Yes, but we can only create the build-graph for a system at the moment (we could probably do it for a stratum with a minimal amount of fiddling, but chunk morphologies give no indication of what they depend on). The `morph list-artifacts` command lists all the build-dependencies of a system. | 09:52 |
| Kinnison | richard_maw: sounds good | 09:52 |
| Kinnison | paulsherwood: Since you're the primary driver of "explicit deps would be better" -- could you write a tool to generate the expanded stratum definitions? | 09:52 |
| richard_maw | bashrc_: would this be "issues where we actually don't want the implied indirect dependencies" or "issues with removing transitive dependencies causing things to stop working because we relied on it"? | 09:53 |
| richard_maw | I have data on the former, but not the latter | 09:53 |
| paulsherwood | Kinnison: actually, i don't think i can. the reality of what depends is *hidden* by the current algorithm in morph. for example m4 requiring gawk. short of tring all build combinations to see what breaks, the answer is just if foo depends on bar, it also depends on what bar depends on, all the way down | 09:54 |
| bashrc_ | if it's not something which crops up very often then go with the existing build-depends but with an additional tool to check all dependencies | 09:54 |
| Kinnison | paulsherwood: Right, so it needs someone to define what currently happens in english first | 09:55 |
| paulsherwood | Kinnison: i think i just did? :-) | 09:55 |
| Kinnison | paulsherwood: I believe richard_maw might be the best person to write a one or two sentence statement on that | 09:55 |
| richard_maw | paulsherwood: that's a different issue for exploring which indirect dependencies aren't actually required, rather than changing the representation | 09:55 |
| Kinnison | paulsherwood: no, since you didn't mention bootstrap mode, which richard_maw mentioned was different | 09:55 |
| *** ssam2 has joined #baserock | 09:56 | |
| *** ChanServ sets mode: +v ssam2 | 09:56 | |
| paulsherwood | i don't think it's different in this respect, but i may be wrong | 09:56 |
| Kinnison | That you're not *certain* implies that we need a clear statement first | 09:57 |
| paulsherwood | richard_maw: since there seems to be a reasonable level of support for sticking with what currently works, and 'fixing' it would mean 'breaking' things for real users, it's probably simplest to leave things as is | 09:58 |
| * gfinney is finding this conversation quite interesting | 09:59 | |
| paulsherwood | heh. i'm somewhat sorry i started it :) | 09:59 |
| Kinnison | Naah, discussions are good, even if all it results in is extra documentation then it's a good thing | 10:00 |
| Kinnison | You've identified a failing. If it's not in how it works, then it's in how it's documented. | 10:00 |
| paulsherwood | thank you for those small crumbs of comfort, Kinnison :-) in any case i'll now crawl back under my rock... | 10:01 |
| Kinnison | please don't drop this until at least there's a good statement somewhere permanent (ML at min, wiki may be better) about how it works | 10:02 |
| ssam2 | basically we need to remove the documentation of the current morphology format from morph's readme, update it, and put it on the wiki | 10:03 |
| Kinnison | ssam2: +1 | 10:03 |
| paulsherwood | gfinney: you seem interested, are you knowledgeable enough to attempt to document this yet? | 10:03 |
| gfinney | Hah! | 10:03 |
| * paulsherwood takes that as a yes | 10:03 | |
| paulsherwood | :-) | 10:04 |
| * gfinney is going to find a rock to hid under | 10:04 | |
| ssam2 | gfinney: there is already fairly detailed (but fairly out of date) in Morph's README, so you wouldn't need to start from scratch at all | 10:04 |
| petefoth | gfinney: take your laptop with you :) | 10:04 |
| ssam2 | (the word 'documentation' was missing from my last sentence) | 10:04 |
| * richard_maw things that http://wiki.baserock.org/definitions-V0/ would be a good place to put such documentation | 10:06 | |
| richard_maw | s/things/thinks/ | 10:06 |
| *** edcragg has joined #baserock | 10:11 | |
| *** gfinney has quit IRC | 10:13 | |
| *** gfinney has joined #baserock | 10:13 | |
| *** Krin has joined #baserock | 10:16 | |
| ssam2 | richard_maw: that implies that we'd either duplicate most of the content of definitions-V0 each time we changed the version of definitions, or that the documentation of the latest version of definitions would be spread across multiple pages | 10:16 |
| ssam2 | I think having an up to date http://wiki.baserock.org/definitions/ would be better, and http://wiki.baserock.org/definitions-V0/ could describe just the obsolete features of V0 | 10:16 |
| *** wschaller has joined #baserock | 10:26 | |
| *** tiagogomes_ has joined #baserock | 10:31 | |
| Kinnison | I am an awkward sod and think that best would be to have /definitions/ which documents the current standard, along with a changelog of what has altered since V(n-1) | 10:33 |
| Kinnison | And each time we increment N, we archive the statement of what n-1 was | 10:33 |
| Kinnison | as a read-only document | 10:33 |
| ssam2 | seems reasonable. is it possible to archive a document in our current wiki as a readonly document? | 10:33 |
| Kinnison | Take markdown, pandoc it to pdf, publish that | 10:34 |
| Kinnison | git can keep the history of the markdown | 10:34 |
| Kinnison | \o/ git | 10:34 |
| ssam2 | seems a bit longwinded | 10:36 |
| * Kinnison shrugs -- your choice in the end, obviously :)_ | 10:38 | |
| * Kinnison is just suggesting an approach | 10:38 | |
| * Kinnison dislikes the idea that V(n-1) remains editable wiki content | 10:38 | |
| ssam2 | me too. | 10:38 |
| ssam2 | but I'd hoped ikiwiki would let us mark a page as readonly, rather than requiring someone to manually generate a PDF | 10:38 |
| ssam2 | which doesn't stop anyone editing the wiki page anyway | 10:39 |
| ssam2 | maybe I'm misunderstanding | 10:39 |
| petefoth | howaboot twp pages - current version, and previous versions whcih gets added to | 10:39 |
| Kinnison | Ultimately it'd still be editable from git | 10:39 |
| ssam2 | i suppose so | 10:39 |
| Kinnison | ikiwiki can't stop you editing files in the git repo | 10:39 |
| Kinnison | which is why making it into a file not commonly edited (PDF) seemed like a plan | 10:39 |
| paulsherwood | can we just put READONLY - please do not edit at the top of applicable pages, and trust folks to do the right thing? | 10:41 |
| paulsherwood | (for now?) | 10:41 |
| Kinnison | perhaps | 10:41 |
| ssam2 | works for me. we have to monitor the wiki changelog in any case | 10:41 |
| * Kinnison nods | 10:41 | |
| * paulsherwood is far too interested in #baserock today | 10:41 | |
| Kinnison | paulsherwood: stand in the corner, facing the wall, and whatever you do, do NOT think about purple elephants | 10:42 |
| * Kinnison hides | 10:42 | |
| paulsherwood | heh | 10:42 |
| straycat | #baserock - better than pictures of cats | 10:43 |
| straycat | it's a good job i don't have op | 10:43 |
| straycat | and that this channel is +t | 10:43 |
| ratmice__ | I think one issue with explicitly specifying all dependencies (rather than transitively) is that when something has optional dependencies they cannot be changed in one place, so when you want to remove one, you are back figuring out if it was an explicitly specified dependency required by something or an actual dependency... | 10:45 |
| ratmice__ | it seems like it might be reasonable to me to have 2 forms of build-dep one which implies a transitive dependency and one which does not? (IIUC the conversation anyways) | 10:46 |
| Kinnison | ratmice__: An interesting proposal. I'd be worried that there's too many possible forms at that point. "transitive dep" "dep on foo only" "dep on foo, and its b-deps but not further" etc. | 10:47 |
| ssam2 | ratmice__: i'm trying to think of an example where that might actually be a problem | 10:48 |
| ssam2 | let's say I want to remove X as a dependency of D-Bus. All I need to do is remove 'x' as a build-dep of 'dbus' | 10:48 |
| ssam2 | oh no, you're right | 10:48 |
| ssam2 | because then suddenly I have to work out what stuff that was in dbus' build dependencies that was actually only there because X needed it | 10:48 |
| ratmice__ | ssam2: largely things like libsoundfile, assimp, etc which aggregate various file formats into an API i think | 10:49 |
| ssam2 | and gst-plugins-*, that would be a nightmare :) | 10:49 |
| *** gary_perkins has quit IRC | 11:06 | |
| *** gary_perkins has joined #baserock | 11:06 | |
| bashrc_ | so how is a baserock rootfs made? | 11:23 |
| richard_maw | at deployment time the cluster definition file lists type: rawdisk, which causes it to run rawdisk.write, which if given a file path and a disk size, creates a disk image, formats it with btrfs and copies the files made a build time into it | 11:25 |
| bashrc_ | aha | 11:25 |
| richard_maw | we used to make disk images as system artifacts a while back, but this proved to be too inflexible | 11:25 |
| *** zoli__ has joined #baserock | 11:53 | |
| bashrc_ | is there any documentation on the cluster format? what the possible deployment types are, etc | 11:55 |
| paulsherwood | bashrc_: do the existing examples not give enough info? | 11:59 |
| bashrc_ | so under deploy: tere are various types such as build-controller. what's the syntax of that? Is there a manpage? | 12:01 |
| paulsherwood | bashrc_: morph deploy --help ? | 12:01 |
| ssam2 | wow, 'btrfs filesystem usage /' is infinitely more useful than 'btrfs filesystem df /' | 12:02 |
| paulsherwood | :) | 12:03 |
| ssam2 | the former makes it look like I have .4 GB free on this system when actually there is at least 17GB free | 12:03 |
| bashrc_ | looks like the label under deploy can be arbitrary | 12:04 |
| ssam2 | bashrc_: I see what you mean. it's a label, which can be passed on the commandline to `deploy` if you want to deploy only that system | 12:04 |
| ssam2 | or set options for that system | 12:04 |
| ssam2 | if the label is foo you can run `morph deploy foo foo.HOSTNAME=bar` to deploy only 'foo' and set its hostname | 12:05 |
| ssam2 | wait, it'd be `morph deploy cluster.morph foo foo.HOSTNAME=bar' | 12:05 |
| bashrc_ | oh I see | 12:06 |
| ssam2 | interesting crash while trying to deploy an upgrade: http://paste.baserock.org/caxehococa | 12:13 |
| paulsherwood | ouch | 12:14 |
| ssam2 | I think this is because this system has a blank line in /etc/fstab | 12:16 |
| ssam2 | and the code wasn't expecting one | 12:16 |
| ssam2 | this bug has been present the whole time ssh-rsync has existed, I can't believe it's taken two years to hit it | 12:18 |
| ssam2 | wait, it's parsing /proc/mounts not /etc/fstab. not so simple after all | 12:19 |
| ssam2 | right. So I was trying to upgrade the wrong machine, and that function was actually parsing an SSH error message. | 12:23 |
| ssam2 | and because all of the checks in ssh-rsync.check only look for a specific message to determine failure, they didn't catch this. | 12:24 |
| *** gary_perkins has quit IRC | 13:12 | |
| *** gary_perkins has joined #baserock | 13:13 | |
| *** gallit has joined #baserock | 13:13 | |
| ssam2 | i'm going to reboot gerrit.baserock.org for an upgrade, will be down for a few minutes | 13:15 |
| *** gallit has joined #baserock | 13:15 | |
| ssam2 | it's back now | 13:17 |
| *** wschaller_ has joined #baserock | 13:20 | |
| *** wschaller has quit IRC | 13:23 | |
| SotK | I sent an RFC for partial deployment a week or so ago, does anyone have an opinion on what a partial deployment command as described therein should look like? | 13:39 |
| bashrc_ | within the valid architectures is armv7b the same as armv7bhf ? | 13:52 |
| *** gfinney has quit IRC | 13:52 | |
| persia | bashrc_: No: the ABIs differ. The ISA supports both ABIs. | 13:53 |
| ssam2 | krin: I'll review your mox3 patch if you send it to gerrit.baserock.org instead of the mailing list | 13:56 |
| Krin | umm, ok ssam2. | 14:00 |
| *** gfinney has joined #baserock | 14:01 | |
| *** gfinney has joined #baserock | 14:01 | |
| paulsherwood | and we're off!? | 14:02 |
| paulsherwood | is pedroalvarez going on camera? :_) | 14:02 |
| pedroalvarez | did the openssl came out? | 14:03 |
| pedroalvarez | release* | 14:03 |
| paulsherwood | https://openssl.org/news/vulnerabilities.html | 14:03 |
| persia | Catching up on backscroll: to me the huge win for multiple +1s not meaning +2 is that one doesn't have to set an ACL on reviewers: anyone can review, but only some folk can accept the reviews. | 14:04 |
| paulsherwood | https://github.com/openssl/openssl | 14:04 |
| *** pacon has quit IRC | 14:05 | |
| persia | For the workflow problem with the Submit button, we ought use some gate management software that verifies that a given change has met a certain set of criteria, and if so, automatically does the submission. | 14:05 |
| pedroalvarez | should then we upgrade to this commit? http://git.baserock.org/cgi-bin/cgit.cgi/delta/openssl-new.git/commit/?h=OpenSSL_1_0_1-stable&id=506c1068801fdeef5cb00f2053854bf56150fb6d | 14:07 |
| pedroalvarez | ok, g.b.o has lorried the branch | 14:14 |
| pedroalvarez | :) | 14:14 |
| paulsherwood | screencast? | 14:14 |
| paulsherwood | pedroalvarez: ^^ | 14:14 |
| pedroalvarez | http://youtu.be/MC3FZLkVPQw | 14:14 |
| paulsherwood | oh, you're on! :-) | 14:15 |
| pedroalvarez | no audio live audio though | 14:16 |
| pedroalvarez | let's start with this | 14:16 |
| jjardon | pedroalvarez: I would go ahead an update to 1.0.2: http://git.baserock.org/cgi-bin/cgit.cgi/delta/openssl-new.git/commit/?h=OpenSSL_1_0_2-stable&id=3df69d3aefde7671053d4e3c242b228e5d79c83f | 14:20 |
| pedroalvarez | hm.. I've been told that is better to stick to 1.0.1 for now | 14:21 |
| straycat | paulsherwood, fwiw i do feel it would be nice to be able to tag a chunk with its direct dependencies in definitions, so that even if i "inherit" a chunk from some other stratum my current stratum build-depends on, or otherwise transitively depend on something within this stratum, i still have this chunk's direct dependencies visible. | 14:21 |
| straycat | even a comment would do, though morph edit would rip them out | 14:22 |
| *** CTtpollard has quit IRC | 14:22 | |
| straycat | all the ideas i have in this park are stupid though | 14:23 |
| * straycat makes do with comments | 14:23 | |
| paulsherwood | straycat: i wouldn't say that. we're in a complex area - it's hard to tease out all the threads | 14:24 |
| * paulsherwood values straycat's input, even when we disagree | 14:24 | |
| pedroalvarez | review for openssl upgrade sent to gerrit | 14:25 |
| * paulsherwood hits submit | 14:26 | |
| pedroalvarez | ta! | 14:27 |
| * pedroalvarez distbuilds | 14:27 | |
| straycat | paulsherwood, :) the tags would need to be verified against the actual build graph somehow and then there'd be duplication between build-depends and the direct-depends and... it'd be terrible | 14:28 |
| * straycat goes back to doing something useful | 14:28 | |
| * jjardon is convinced about the need of transitive dependencies after reading ratmice__ comment | 14:28 | |
| *** CTtpollard has joined #baserock | 14:35 | |
| tlsa | NetSurf is sticking with openssl 1.0.1 for now too. 1.0.2 is too new and openssl too critical. | 14:37 |
| straycat | part of the problem i have with not easily being able to specify direct dependencies is caused by this flat namespace we've imposed i guess. if i were able to override chunks i've inherited from strata i depend on then i could easily specify the direct dependencies, happen to be thinking about this because i'm shuffling strata around atm | 14:37 |
| tlsa | most of the vulnerabilities was for 1.0.2 | 14:38 |
| straycat | like with nixos you can say, i want this desktop environment, but i want to override chrome with a version of chrome that doesn't have flash in it... or something like that | 14:39 |
| persia | straycat: One of the things I like about Baserock is that not all the direct dependencies are specified, giving one apparently more control over the content of an image. | 14:39 |
| persia | When I built images from distros, there was always argument and debate over whether a given runtime dependency was really a dependency or not, especially things that were only required in certain use cases. | 14:40 |
| persia | overrides might help with that, but it is an area in which much thought is beneficial to finding a solution that meets many needs. | 14:41 |
| * petefoth notes that with local build you get an idea how far through the build is ("step x of y") but there are no clues to that when ditdbuilding | 14:44 | |
| Kinnison | petefoth: yeah, it's one of the reasons I'd like to see local and dist building code unified at some point | 14:45 |
| edcragg | hi, i'm trying to get internet working within a completed native build bootstrap on a second NIC, booted directly with a kernel. i've tried adding the interface to /etc/network/interfaces, and setting routing manually. it apparently gets a response with an IP from udhcpc, but there is no IP showing up in ifconfig, and get 'network is unreachable' messages. any clues? | 14:47 |
| persia | Another reason I'd like to see it combined is that I don't understand why I have to build serially locally: even with large -j values, if I have tens of cores and tens of GB of RAM, I want to parallelise as much as possible. | 14:48 |
| edcragg | i also added nameservers to /etc/resolv.conf | 14:48 |
| persia | edcragg: I would recommend initially ignoring config files. If you know the network environment, use ifconfig to manually bring the interfaces up with the correct values, and route to manually set the routes. | 14:49 |
| persia | Once you have that working, try adjusting /etc/resolv.conf to set up the resolver. | 14:49 |
| edcragg | persia: you mean use a static IP? | 14:50 |
| persia | This will give you a reference configuration that you can use to validate the automation. | 14:50 |
| persia | edcragg: For initial testing, yes, that's how I'd start. | 14:50 |
| edcragg | ok | 14:51 |
| persia | Also, if you are using systemd-networkd, I think /etc/network/interfaces isn't where you want to configure the interfaces (but I don't recall the correct location off the top of my head) | 14:51 |
| edcragg | it's a bootstrap tarball, no init | 14:51 |
| persia | /etc/resolv.conf should be independent of any interface enablement, address assignment, or routing, but some automation will clobber it in some cases, so only validate that once the rest works, and be prepared to see change as you enable automation. | 14:51 |
| persia | If there is no init, then /etc/network/interfaces is definitely useless. | 14:52 |
| edcragg | it seems to work | 14:52 |
| persia | Then you are running some sort of init. | 14:52 |
| persia | Or at least, some automation for bringing up interfaces. | 14:52 |
| persia | The kenel won't bring up any intefaces by default with init=bash | 14:53 |
| edcragg | i was assuming there is some magic in the cross-bootstrap system | 14:54 |
| edcragg | thanks | 14:55 |
| persia | There may be such magic, but if so, it is running under init. | 14:55 |
| persia | Essentially, when the kernel boots, it hands control to PID 1, which we call init. | 14:56 |
| persia | PID 1 may be something simple (e.g. a shell), or interestingly complex automation (e.g. systemd). | 14:56 |
| persia | And network configuration happens in userspace, so that is the result of whatever PID 1 happens to do. | 14:56 |
| ssam2 | the cross-bootstrap rootfs has no magic that I know off | 14:58 |
| persia | init=bash? | 14:58 |
| persia | Or is it just a tarball for use with chroot()? | 14:59 |
| edcragg | init=/bin/sh | 15:04 |
| ssam2 | persia: it can be used either as a chroot or with init=/bin/sh | 15:05 |
| edcragg | or `init=/tools/bin/sh` even | 15:05 |
| ssam2 | heh, yeah | 15:06 |
| pdar | heya, has anyone used kmod with baserock to load kernel modules? | 15:07 |
| persia | Right then. WIth init=/bin/sh, there's definitely no magic happening. | 15:10 |
| persia | Or if there is, something is very deeply wrong with the implementation of /bin/sh | 15:10 |
| pedroalvarez | pdar: is this an out-of-tree kernel module? | 15:12 |
| pdar | pedroalvarez: I dont think so. But I guessed what out-of-tree kernel module meant. | 15:16 |
| pdar | what does that mean? | 15:16 |
| pedroalvarez | i don't really know what kmod is, though | 15:17 |
| edcragg | persia: yep | 15:17 |
| pedroalvarez | pdar: an out of tree kernel module is a kernel module that is not included in the kernel tree (repository) | 15:17 |
| pedroalvarez | pdar: so that it has to be built in a different chunk | 15:18 |
| pdar | it handles things like modprobe and lsmod. Loading and unloading kernel modules | 15:19 |
| pdar | pedroalvarez: as I suspected. its not out-of-tree. | 15:20 |
| pedroalvarez | pdar: so, if I understand correcly, you want to enable a kernel module, that is already built in your kernel but not enabled | 15:21 |
| pedroalvarez | pdar: you can specify in the kernel chunk that you want to enable that module always, and then you don't need to use modprobe to enable anything | 15:22 |
| radiofree | pdar: if you do make modules_install properly, and depmod, systemd should take care of it | 15:23 |
| radiofree | pdar: here's an example http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/bsp-jetson/nouveau-drm.morph | 15:24 |
| pdar | pedroalvarez: ha, nope, it is enabled. I just wanted to know if anyone knew why running modprobe doesnt behave as i expected it to. | 15:24 |
| radiofree | pdar: you probably need to run depmod before modprobe will behave as you expect it to | 15:25 |
| pedroalvarez | `depmod -a` ? | 15:26 |
| radiofree | you don't need the -a | 15:26 |
| radiofree | `depmod` is fine (a is default if nothing is specified) | 15:26 |
| *** gfinney has quit IRC | 15:27 | |
| pdar | great! depmod worked! thanks radiofree, pedroalvarez | 15:28 |
| *** gfinney has joined #baserock | 15:32 | |
| *** petefoth has quit IRC | 15:51 | |
| *** jonathanmaw has quit IRC | 16:07 | |
| tiagogomes_ | I was wondering why I am not seeing patches on baserock-dev lately, is it because everything is done through Gerrit now? | 16:19 |
| Kinnison | where possible, yes | 16:19 |
| pedroalvarez | We were discussing yesterday the creation of another mailing list, so gerrit sends all the patches and comments there | 16:24 |
| persia | In another context, such a mailing list was created, and most of the discussion about it was on how to remove oneself from subscription. | 16:25 |
| pedroalvarez | I sometimes find useful the fact that one can google things and find the patch in the mail list | 16:26 |
| persia | In the archives, there were no cases of mail being sent to that list by humans. There were rare cases of humans replying to mails to that list and sending to other lists, to highlight reviews that might have set precedent in ways with which the author disagreed, but I don't think it is onerous to reference a gerrit comment in a mail by hand, rather than subscribing to a list that one doesn't use, and replying to mail from that. | 16:26 |
| persia | If we insist on good commit messages, git can handle that. | 16:27 |
| *** gallit has quit IRC | 16:31 | |
| bashrc_ | trying to cross boot to armv7bhf I get: GCC is not passing the correct host/target flags to GMP's configure script | 16:33 |
| ssam2 | any reason why we still don't set 'CLOUD_INIT: yes' in release.morph for any of the systems? | 16:34 |
| ssam2 | would be nice to be able to deploy the released images straight into openstack | 16:35 |
| pedroalvarez | bashrc_: yeah, there is a bug in stage1-gcc | 16:35 |
| pedroalvarez | bashrc_: I never had time to get around it | 16:35 |
| bashrc_ | so is that a bug in gcc itself? | 16:36 |
| pedroalvarez | well, let's say is a bug in our workaround for a bug in gcc | 16:38 |
| bashrc_ | heh | 16:38 |
| pedroalvarez | our workaround is here: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/build-essential/stage1-gcc.morph#n72 | 16:38 |
| tiagogomes_ | right, I should had been explicit in the case | 16:40 |
| pedroalvarez | tiagogomes_: workaround works for a native build, but not for cross-bootstrap builds | 16:41 |
| bashrc_ | ok | 16:41 |
| tiagogomes_ | mm, wondering why. Is the build of the cross-bootstrap tarball that is failing? Or is it after when the native-build script runs | 16:44 |
| Kinnison | stage 1 is during the morph cross-bootstrap phase I think | 16:44 |
| bashrc_ | tiagogomes: building to the tarball | 16:45 |
| pedroalvarez | tiagogomes_: when building stage1-gcc, you can't assume "host=armv7a" if you are running the build on x86 | 16:45 |
| bashrc_ | it appears that the workaround is doing something resembling that | 16:46 |
| tiagogomes_ | pedroalvarez right | 16:46 |
| Kinnison | stage 1 needs host == build and stage 2 needs host == target | 16:47 |
| Kinnison | I think | 16:47 |
| pedroalvarez | I'd say that it also needs host == build host | 16:47 |
| pedroalvarez | hm.. | 16:48 |
| pedroalvarez | no, I don't have brain left to think about this | 16:48 |
| Kinnison | ssam2: might need to weigh in | 16:49 |
| Kinnison | my brain runs in circles thinking about the bootstrap | 16:49 |
| ssam2 | i sent a mail a few weeks ago with a table of host, build, target | 16:49 |
| pedroalvarez | he did :) | 16:50 |
| paulsherwood | i saw that mail, meant to say thanks! | 16:50 |
| Kinnison | ssam2: my -dev backlog is over 1200 mails | 16:50 |
| Kinnison | ssam2: some of which are unresolved threads from the start of the year | 16:50 |
| ssam2 | http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-March/012481.html | 16:50 |
| paulsherwood | my *unread* backlog is 6912 mails :/ | 16:51 |
| tiagogomes_ | how do I clone a repository from gerrit using SSH? I am trying `git clone ssh://git@gerrit.baserock.org/baserock/local-config/lorries.git`. Wasn't my public key automatically added to gerrit? | 16:51 |
| pedroalvarez | tiagogomes_: you have to use your username instad of "git" | 16:51 |
| ssam2 | tiagogomes_: look in the Gerrit web UI for the exact clone URL | 16:51 |
| ssam2 | you also need to use port 29418 | 16:51 |
| bashrc_ | I think there's a clone command which you can copy on each project site | 16:53 |
| tiagogomes_ | it still doesn't work: `git clone ssh://tiagogomes@gerrit.baserock.org:29418/baserock/local-config/lorries.git` | 16:53 |
| ssam2 | what is the error? | 16:54 |
| SotK | tiagogomes_: have you added your SSH public key? | 16:54 |
| tiagogomes_ | I think that is the problem: http://paste.baserock.org/uyoguziwak | 16:55 |
| ssam2 | there'll be 30 seconds or so of Gerrit downtime coming up as I take a backup | 16:56 |
| *** a1exhughe5 has quit IRC | 17:01 | |
| tiagogomes_ | heh, for some reason I didn't had an username in the gerrit account | 17:07 |
| rdale | you have to add one, even though to register your openid you need a username | 17:15 |
| *** zoli__ has quit IRC | 17:22 | |
| straycat | take it i'm the only person who seems to have intermittent connection problems with gbo? | 17:27 |
| straycat | (deploying a new trove and got another connection refused when morph tried to fetch cpython) | 17:28 |
| pedroalvarez | didn't you had also problems with cache.baserock.org? | 17:28 |
| paulsherwood | maybe it's suffering a DoS? | 17:28 |
| paulsherwood | :) | 17:28 |
| rjek | hah | 17:28 |
| straycat | pedroalvarez, sorry i meant cache.baserock.org, though i also have intermittent issues pulling over ssh from gbo | 17:29 |
| straycat | maybe i have some dodgy networking at my end | 17:29 |
| pedroalvarez | ANNOUNCEMENT: There will be some g.b.o downtime due OpenSSL upgrade | 17:32 |
| pedroalvarez | Sorry about the short notice, but I couldn't estimate how long the build was going to take | 17:33 |
| pedroalvarez | I actually thought it was going to take less than 2 hours and it took 3 | 17:33 |
| paulsherwood | pedroalvarez: how long? | 17:34 |
| pedroalvarez | Just a reboot, less than 3 minutes | 17:34 |
| paulsherwood | cool, can't wait :) | 17:34 |
| pedroalvarez | (assuming everything works :) | 17:34 |
| straycat | will cache.baserock.org stay up? | 17:35 |
| *** wschaller_ has quit IRC | 17:37 | |
| paulsherwood | weirdly, with master morph and master definitions, i appear to *not* be getting cached artifacts | 17:37 |
| pedroalvarez | straycat: yes | 17:37 |
| pedroalvarez | ok, g.b.o is going down now | 17:37 |
| straycat | paulsherwood, maybe one of your fetches failed and morph started building, as mine just did? | 17:38 |
| paulsherwood | ah, that might be it | 17:39 |
| paulsherwood | nope... im an idiot. no artifact.cache.server specified :) | 17:39 |
| *** wschaller has joined #baserock | 17:40 | |
| pedroalvarez | phew | 17:42 |
| paulsherwood | congrats | 17:43 |
| paulsherwood | now we should think about how to make it faster :-) | 17:43 |
| pedroalvarez | the upgrade was pretty quick | 17:44 |
| pedroalvarez | the build was really really slow for this | 17:44 |
| pedroalvarez | putting the new openssl on top of the system can be the fastest way to get a security fix on a system without building everything | 17:45 |
| * pedroalvarez upgrades cache.baserock.org | 17:47 | |
| *** jonathanmaw has joined #baserock | 17:52 | |
| *** mdizzle has quit IRC | 17:56 | |
| *** zoli__ has joined #baserock | 18:01 | |
| *** wschaller_ has joined #baserock | 18:02 | |
| *** bashrc_ has quit IRC | 18:03 | |
| *** gary_perkins has quit IRC | 18:04 | |
| *** wschaller has quit IRC | 18:04 | |
| *** gary_perkins has joined #baserock | 18:04 | |
| *** Krin has quit IRC | 18:04 | |
| *** mdunford has quit IRC | 18:05 | |
| *** gary_perkins has quit IRC | 18:06 | |
| *** gary_perkins has joined #baserock | 18:06 | |
| edcragg | does anyone recognise this build error (stage 2 gawk)? http://paste.baserock.org/ufarinebif | 18:14 |
| *** jonathanmaw has quit IRC | 18:18 | |
| *** wschaller has joined #baserock | 18:19 | |
| *** gary_perkins has quit IRC | 18:20 | |
| *** gary_perkins has joined #baserock | 18:20 | |
| *** wschaller_ has quit IRC | 18:21 | |
| *** gary_perkins has quit IRC | 18:22 | |
| *** gary_perkins has joined #baserock | 18:22 | |
| pedroalvarez | edcragg: make is trying to remove things from the read-only filesystem | 18:27 |
| pedroalvarez | Oh, given that is in stage 2, is trying to remove things from your host! | 18:28 |
| pedroalvarez | E | 18:30 |
| pedroalvarez | edcragg: you may want to take a look at how gawk stage2 is being built? | 18:31 |
| pedroalvarez | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/build-essential/stage2-gawk.morph | 18:31 |
| gary_perkins | pedroalvarez: is it normal for my morph file to disappear (despite me chmodding it to 400!) from the definitions directory? | 18:32 |
| pedroalvarez | gary_perkins: I'm not sure about what you mean | 18:37 |
| pedroalvarez | When is this file being removed? | 18:38 |
| gary_perkins | it keeps disappearing after my morph deploy, which is currently not working due to credenials not working | 18:38 |
| *** gfinney has quit IRC | 18:40 | |
| edcragg | pedroalvarez: thanks... i was thinking the read only thing was something to do with containerisation? | 18:40 |
| gary_perkins | /ws/master/git.baserock.org/baserock/baserock/definitions # morph deploy ct-trove-openstack.morph trove.OPENSTACK_PASSWORD=*************** | 18:40 |
| gary_perkins | ERROR: OPENSTACK_PASSWORD was not given | 18:40 |
| gary_perkins | ERROR: openstack.check failed with code 1: ERROR: OPENSTACK_PASSWORD was not given | 18:40 |
| gary_perkins | is the "trove." supposed to be the name of the cluster morph? | 18:43 |
| pedroalvarez | gary_perkins: the file going away is really odd | 18:43 |
| gary_perkins | pedroalvarez: it is. It just disappeared now, without a morph deploy | 18:44 |
| pedroalvarez | Is the name of the deployment, no the name defined on the morphology file on the top | 18:44 |
| gary_perkins | that root fs is 88% full | 18:44 |
| gary_perkins | it's gone again | 18:44 |
| gary_perkins | btrfs bug? | 18:46 |
| *** mwilliams_ct has quit IRC | 18:49 | |
| *** benbrown_ has quit IRC | 18:49 | |
| *** perryl has quit IRC | 18:49 | |
| *** pdar has quit IRC | 18:49 | |
| *** petefotheringham has quit IRC | 18:49 | |
| *** wdutch has quit IRC | 18:49 | |
| *** Zara has quit IRC | 18:49 | |
| *** jmacs has quit IRC | 18:49 | |
| *** paulsherwood has quit IRC | 18:49 | |
| *** bwh has quit IRC | 18:49 | |
| *** kejiahu has quit IRC | 18:49 | |
| *** SotK has quit IRC | 18:50 | |
| pedroalvarez | gary_perkins:... Maybe? | 18:50 |
| *** rdale has quit IRC | 18:50 | |
| *** pedroalvarez has quit IRC | 18:51 | |
| gary_perkins | I tried running 'sync' after copying etc. to try and make sure what I'm seeing is what is there. Doesn't really help | 18:51 |
| *** pedroalvarez has joined #baserock | 18:52 | |
| *** ChanServ sets mode: +v pedroalvarez | 18:52 | |
| gary_perkins | I did a morph gc before, because the fs was 97% full | 18:52 |
| gary_perkins | <gary_perkins> I tried running 'sync' after copying etc. to try and make sure what I'm seeing is what is there. Doesn't really help | 18:52 |
| *** gary_perkins has quit IRC | 18:54 | |
| *** gary_perkins has joined #baserock | 18:54 | |
| *** bwh has joined #baserock | 18:54 | |
| *** petefotheringham has joined #baserock | 18:54 | |
| pedroalvarez | regarding the other error, can I see your cluster morpholgy? | 18:55 |
| *** DavePage has joined #baserock | 18:55 | |
| gary_perkins | http://paste.baserock.org/hibubivuqo | 18:56 |
| pedroalvarez | right, "trove." has to be "ct-trove-openstack." for this morphology | 18:57 |
| *** wschaller has quit IRC | 18:57 | |
| *** pedroalvarez has left #baserock | 18:57 | |
| *** pedroalvarez has joined #baserock | 18:57 | |
| *** ChanServ sets mode: +v pedroalvarez | 18:57 | |
| gary_perkins | yes, I tried that :) Also, I need to change the tenancy again | 18:57 |
| *** SotK has joined #baserock | 18:57 | |
| gary_perkins | trying again, but with a different password, seems to be working! :) | 18:59 |
| gary_perkins | thanks pedroalvarez, I think it might work now :) | 19:00 |
| gary_perkins | Nope :( | 19:05 |
| gary_perkins | Error creating Btrfs system layoutERROR: Command failed: cp -a /srv/distbuild/tmp/deployments/tmpDBi2LH/tmp52W6pR/. /srv/distbuild/tmp/deployments/tmpDBi2LH/tmp_zUjJU/tmpTuLowG/systems/factory/orig/. | 19:05 |
| gary_perkins | cp: write error: No space left on device | 19:05 |
| pedroalvarez | sigh.. | 19:05 |
| pedroalvarez | I guess we can blame btrfs :) | 19:06 |
| pedroalvarez | can you redeploy your devel system or use a different one? | 19:06 |
| gary_perkins | now df -h and btrfs filesystem df / report only 28% full! | 19:07 |
| *** zoli__ has quit IRC | 19:07 | |
| gary_perkins | I think it would be best if /ws on the instance was a good size ext4 fs | 19:08 |
| DavePage | gary_perkins: Run out of inodes (or btrfs equivalent) rather than disk space? | 19:08 |
| gary_perkins | btrfs does strange things when almost full :( | 19:09 |
| *** wschaller has joined #baserock | 19:09 | |
| *** lachlanmackenzie has quit IRC | 19:10 | |
| ssam2 | gary_perkins: try `btrfs filesystem usage /` instead | 19:11 |
| ssam2 | it's a bit better | 19:11 |
| pedroalvarez | he said that it also reported only 28% full | 19:11 |
| gary_perkins | ssam2: Yes, that's much better, and it reports ~75GB allocated out of 80GB | 19:12 |
| gary_perkins | I'll try the other devel instance, cheers | 19:13 |
| straycat | pedroalvarez, i have a machine that's got libvirt but uses bridged networking rather than nat, i think i see your concern wrt to the kvm check i added | 19:14 |
| pedroalvarez | which I don't remember :) | 19:15 |
| pedroalvarez | iirc my main concern was that having the network active wasn't a blocker to create a vm. | 19:15 |
| pedroalvarez | Is a blocker if you want to boot it afterwards | 19:15 |
| straycat | oh, well it is a blocker | 19:16 |
| straycat | (iirc) | 19:16 |
| pedroalvarez | :) | 19:16 |
| straycat | but morph by default expects the virtual network 'default' to be started, which it doesn't need to be if you're using bridged networking | 19:16 |
| pedroalvarez | aha! that's another point | 19:16 |
| straycat | yay new trove | 19:17 |
| pedroalvarez | I think is only a blocker if your deplyment tries to boot it (AUTOSTART: Yes) | 19:17 |
| pedroalvarez | but I may be wrong | 19:17 |
| *** zoli__ has joined #baserock | 19:18 | |
| straycat | btw, why does the example http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/trove-example.morph specify --upgrade for an initial deployment? | 19:18 |
| straycat | is that meant to be there? | 19:18 |
| straycat | i didn't use it and my new trove seems okay | 19:19 |
| *** tiagogomes_ has quit IRC | 19:20 | |
| ssam2 | must be a mistake | 19:20 |
| straycat | okay, i'll fix it then | 19:21 |
| pedroalvarez | yeah, looks like a mistake | 19:21 |
| pedroalvarez | I sen't today the first patch to gerrit.baserock.org today and it was brilliant | 19:21 |
| pedroalvarez | I did it on live in the screencast :) | 19:22 |
| straycat | oh, is git.baserock.org not the default upstream trove? | 19:24 |
| pedroalvarez | why wouldn't it? | 19:26 |
| straycat | the list of remote troves is empty | 19:27 |
| straycat | i didn't specify anything in UPSTREAM_TROVE because i assumed gbo would be default | 19:27 |
| *** wschaller has quit IRC | 19:30 | |
| pedroalvarez | ah, I understand now | 19:34 |
| pedroalvarez | no, now is not the default, so you can deploy troves that don't do any mirroring | 19:35 |
| straycat | oh | 19:35 |
| pedroalvarez | this way we can deploy git.baserock.org :) | 19:35 |
| straycat | ok | 19:35 |
| straycat | guess i get to upgrade my trove then | 19:36 |
| pedroalvarez | an upgrade might not work, since the UPSTREAM_TROVE information is in a git repo | 19:37 |
| straycat | good point, okay i guess i'll fix it in that repo | 19:38 |
| pedroalvarez | :) | 19:40 |
| * straycat adds lorry-controller client to wishlist | 19:44 | |
| straycat | oh, lorry-controller automatically reread its configuration before i figured out what POST request to send >.> | 19:46 |
| straycat | also whilst i'm being annoying isn't deploy --upgrade deprecated? if so should we update http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/upgrade-devel.morph ? | 19:49 |
| straycat | at the same time adding whatever command you're supposed to use to http://wiki.baserock.org/quick-start/#index7h2 ? | 19:51 |
| straycat | i used deploy --upgrade the other day and it worked great, but still | 19:51 |
| *** gary_perkins has quit IRC | 20:00 | |
| straycat | perhaps a task for another day | 20:16 |
| * straycat disappears | 20:16 | |
| *** ssam2 has quit IRC | 20:39 | |
| *** paulsherwood has joined #baserock | 21:16 | |
| *** edcragg has quit IRC | 21:59 | |
| *** zoli__ has quit IRC | 22:18 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!