| *** paulw has quit IRC | 00:40 | |
| *** paulsherwood has quit IRC | 00:49 | |
| *** paulsherwood has joined #baserock | 00:49 | |
| *** jjardon has quit IRC | 02:01 | |
| *** jjardon has joined #baserock | 02:05 | |
| *** zoli__ has joined #baserock | 04:57 | |
| *** zoli__ has quit IRC | 04:59 | |
| *** zoli__ has joined #baserock | 05:01 | |
| *** zoli__ has quit IRC | 05:53 | |
| *** zoli__ has joined #baserock | 06:20 | |
| *** paulw has joined #baserock | 06:47 | |
| *** a1exhughe5 has joined #baserock | 07:04 | |
| *** perryl has joined #baserock | 07:15 | |
| *** Albert has joined #baserock | 07:30 | |
| *** Albert has joined #baserock | 07:30 | |
| *** bashrc_ has joined #baserock | 08:03 | |
| *** jonathanmaw has joined #baserock | 08:03 | |
| jonathanmaw | *sigh*. AudioManager PoC is a project that builds separately from AudioManager (it's a qt build system, while AudioManager is CMake) and exists entirely in a subdirectory of the AudioManager repo. | 08:08 |
|---|---|---|
| jonathanmaw | so the most sensible thing for it seems to have been to have a separate chunk for the PoC that is built after qt5-tools, and has a completely separate chunk morphology | 08:09 |
| jonathanmaw | it also tries to install things to /opt | 08:09 |
| jjardon | jonathanmaw: what PoC? | 08:11 |
| jonathanmaw | jjardon: AudioManager PoC, part of the GENIVI Demo Platform | 08:11 |
| jonathanmaw | but annoyingly, hasn't been merged yet | 08:11 |
| jonathanmaw | http://wiki.projects.genivi.org/index.php/GENIVI_Demo_Platform#Major_Software_components | 08:11 |
| jonathanmaw | rather than try and make a patch file out of the gigantic E-mail that E-mail links to, I stole meta-genivi-demo's patches, instead. | 08:12 |
| pedroalvarez | sigh | 08:13 |
| pedroalvarez | 2 different chunk definitions using the same repo makes sense to me, and also sound like the right thing to do | 08:15 |
| jjardon | jonathanmaw: right, put those things in a separate stratum on top of Qt seems sensible | 08:15 |
| jonathanmaw | also, the stuff installed into /opt is hard-coded to that path :¬| | 08:15 |
| *** persia_ has quit IRC | 08:16 | |
| *** rdale has joined #baserock | 08:16 | |
| *** persia_ has joined #baserock | 08:17 | |
| *** persia_ has joined #baserock | 08:17 | |
| *** fay_ has quit IRC | 08:17 | |
| *** fay has joined #baserock | 08:18 | |
| *** fay is now known as fay_ | 08:18 | |
| *** tiagogomes has quit IRC | 08:19 | |
| *** mike has joined #baserock | 08:19 | |
| *** tiagogomes_ has joined #baserock | 08:19 | |
| *** mike is now known as Guest97990 | 08:19 | |
| pedroalvarez | :/ sed? | 08:27 |
| pedroalvarez | but that can go really wrong hehe | 08:28 |
| *** edcragg has joined #baserock | 08:28 | |
| *** gary_perkins has joined #baserock | 08:29 | |
| *** benbrown_ has joined #baserock | 08:35 | |
| *** gary_perkins_ has joined #baserock | 08:49 | |
| *** gary_perkins has quit IRC | 08:49 | |
| *** gary_perkins_ has quit IRC | 08:52 | |
| *** gary_perkins has joined #baserock | 08:52 | |
| *** jmacs has joined #baserock | 09:02 | |
| persia | jonathanmaw: For /opt installation: is the upstream build system written in a way that DESTDIR=/opt would achieve the current goal, if it had proper DESTDIR support? If so, submitting a build-system patch upstream might be the easiest way around the problem. | 09:14 |
| jonathanmaw | persia: nope, hard-coded paths in the qt project file for where to install the files, and hard-coded paths in the source code to where some things should be. | 09:18 |
| persia | Ugh. The former is usually sortable, but the latter indicates poor practice. It ought use one of the many available dynamic schemes for this sort of thing. | 09:19 |
| persia | What sort of things does it try to find? | 09:19 |
| *** franred has joined #baserock | 09:21 | |
| jonathanmaw | persia: it installs scripts and audio files to /opt/audiomanager-poc/{scripts,audio-files} respectively | 09:21 |
| jonathanmaw | the scripts look for the hard-coded paths to those audio files | 09:21 |
| jonathanmaw | and the source code has the hard-coded paths to the scripts | 09:21 |
| persia | Does it leave anything in /etc ? | 09:22 |
| jonathanmaw | persia: I don't think so. | 09:22 |
| jonathanmaw | nope, nothing in /etc | 09:23 |
| persia | Hrm. You might introduce an /etc/defaults/audiomanager-poc that contains scripts and audio-files directives, but that gets more invasive. | 09:23 |
| jjardon | What's the problem with installing in /opt ? | 09:23 |
| jonathanmaw | jjardon: from my experience, the files don't appear, due to deployment things | 09:24 |
| *** kejiahu has joined #baserock | 09:25 | |
| jjardon | So its a morph bug then? | 09:26 |
| jonathanmaw | jjardon: I hadn't considered whether it was intentional | 09:28 |
| persia | Whether Baserock-generated systems should have and/or use /opt is a complicated question. | 09:29 |
| persia | It's probably a bug in morph that there is no way to do this, but it is also arguably a bug in any software that forces doing this, as it cannot be part of the distributed system and remain in compliance with FHS. | 09:30 |
| persia | /opt is generally for software added to a system, post deployment. | 09:32 |
| persia | (that line should have appeared above the other two, but was initially interpreted as a command: apologies for confusion) | 09:33 |
| jjardon | AFAIK /opt is part of the FHS. But even if not, i think morph should support installing components there (we create /opt in baserock BTW, see the fhs-dirs chunk) | 09:41 |
| richard_maw | jjardon: yep, nobody is suggesting that it isn't a bug that we can't install stuff into /opt as part of a baserock build | 09:42 |
| franred | good morning, this week and the next, the Openstack in Baserock team is going to be upstreaming their branch, we will be very grateful if some other baserock member can have a look at the patches we will be posting here, thank you in advance!! | 09:43 |
| persia | jjardon: Yes, /opt is part of FHS, but it's reserved for stuff being installed later. | 09:43 |
| franred | https://gerrit.baserock.org/#/c/227/ <<-- Kmod fixes for working with iSCSI modules and userland | 09:44 |
| persia | Specifically, from FHS 2.3, section 3.13.1: "/opt is reserved for the installation of add-on application software packages", which is not generally interpreted to include anything that is part of a deployed system. | 09:44 |
| persia | And 3.13.2 indicates that the child directories of /opt are "reserved for local system administrator use". | 09:45 |
| persia | Given the blurring between system developers and system administrators implied by Baserock, this isn't as simple as it looks, but still a strong indicator that there is reason for controversy. | 09:46 |
| pedroalvarez | ATM one can install things in /opt on a running system, and they will be there after a system upgrade | 09:47 |
| persia | That is definitely correct behaviour, and should be retained. | 09:51 |
| persia | But I believe it to be orthogonal to installing software in /opt as part of deployment. | 09:52 |
| pedroalvarez | It is a side effect. Upgrades will be more complex if we allow installing things in /opt | 09:55 |
| pedroalvarez | Something similar happens with /var, which contains things installed at build time, and things that are added later. (things that we want to keep after upgraing a system) | 09:56 |
| pedroalvarez | Now upgrades will override /var with the new /var created when upgrading. | 09:57 |
| pedroalvarez | If that is sensible for /opt too, we could do the same. | 09:57 |
| richard_maw | /var ought to be a bit simpler, software ought to not require any setup at build or deployment time, we ought to be able to leave /var as-is, because a system ought to be able to boot with an empty /var | 09:58 |
| jjardon | pedroalvarez: : there is some WIP trying to tackle that problem: http://0pointer.net/blog/projects/stateless.html | 10:00 |
| persia | My main issue with overwriting /var is the potential to lose logs or critical historical data from /var/lib | 10:04 |
| *** persia_ has quit IRC | 10:04 | |
| *** persia_ has joined #baserock | 10:05 | |
| *** persia_ has joined #baserock | 10:05 | |
| straycat | Does anyone think it would be useful to put .gitreview files into all the repos that are now on gerrit? | 10:11 |
| bashrc_ | I did start doing that on gerrit | 10:12 |
| *** DavePage has joined #baserock | 10:12 | |
| persia | straycat: +1 | 10:13 |
| * straycat updates change https://gerrit.baserock.org/194 | 10:16 | |
| straycat | it's also quicker to send subsequent versions with this | 10:19 |
| * richard_maw needs to sit down and have a go at `git review` at some point | 10:28 | |
| straycat | it's pretty much just, git review -s (to setup), git review -R (to submit the current branch without rebasing), and git review -d <change number> to download the change. You also want a .gitreview file in the repo telling git-review where to get its git review, but if we push those into all gerrit repos then it should be very convenient | 10:32 |
| *** wschaller has joined #baserock | 10:36 | |
| bashrc_ | is there any existing code for determining the dependency order of a set of morph files? | 10:45 |
| nowster | presumably there is within morphlib... | 10:45 |
| bashrc_ | might save me from rewriting something | 10:46 |
| straycat | franred, richard_maw, i'm slightly confused by the addition of $PREFIX to the kmod morph? | 10:47 |
| franred | straycat, what are your concerns? | 10:48 |
| straycat | i thought it was supposed to be installed into /bin ? | 10:48 |
| *** sambishop has quit IRC | 10:56 | |
| franred | straycat, iscsi kernel modules suppose to be installed in /sbin | 10:56 |
| franred | straycat, also we want to move every binary to be installed in /usr/bin, /usr/sbin to be able to merge /bin /sbin to /usr/bin /usr/sbin, so I moved it. Why did you think that kmod has to be installed in /bin? what are your reasons? | 10:58 |
| * pedroalvarez appreciates that | 10:59 | |
| straycat | oh i didn't even know we were doing that | 10:59 |
| straycat | and just that my debian box has it in /bin, and that's for "essential" binaries, which i guess might include kmod? so that's why i asked | 11:00 |
| pedroalvarez | straycat: we sould like to do that afaik. Problems like "foo is not overriding busybox-foo" will disappear | 11:00 |
| pedroalvarez | s/sould/would/ | 11:01 |
| * bashrc_ finds ArtifactResolver | 11:01 | |
| straycat | moving all the binaries into /usr might be interesting, given that some things in build essential use hardcoded paths to binaries in /bin | 11:02 |
| straycat | i guess you can leave symlinks for those | 11:02 |
| pedroalvarez | /bin /sbin and /usr/sbin will be symlinks to /usr/bin, yes | 11:03 |
| * persia actually liked the separation, and used to use environments where it was important, but acknowledges that in modern systems with massive available secondary storage (measured in multiple megabytes), it doesn't matter. | 11:06 | |
| *** sambishop has joined #baserock | 11:11 | |
| *** Krin has quit IRC | 11:25 | |
| *** Krin has joined #baserock | 11:29 | |
| *** mdunford has quit IRC | 11:33 | |
| richard_maw | AIUI we expect that the initramfs is the one to make /usr available now | 11:34 |
| franred | straycat, richard_maw, https://gerrit.baserock.org/#/c/227/ <-- I've added richard_maw's comment as a warning | 11:35 |
| * paulsherwood is up to his ears, but would like to understand whether morph *really* ignores names, or not. | 11:35 | |
| * paulsherwood notices that foo chunk can have many build-depends... aren't those are only referred to by name? | 11:36 | |
| paulsherwood | richard_maw, straycat ^^ ? | 11:36 |
| richard_maw | I'm not sure I follow the question, or the source of your confusion as to whether morph ignores names. the build-depends refer to other components by name, but currently I'm a little fuzzy about whether it's the "name" field in the stratum or in the chunk that is being discussed | 11:38 |
| *** mdunford has joined #baserock | 11:49 | |
| *** wschaller has quit IRC | 11:56 | |
| paulsherwood | richard_maw: eg stage1-gcc build-depends on stage1-binutils, or more crucially, http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/ruby.morph#n37 | 12:25 |
| paulsherwood | i assume hoe depends on ruby the chunk, based on its name | 12:26 |
| richard_maw | it must, since it cannot be depending on its stratum, or it would fail to build because of a dependency loop | 12:27 |
| paulsherwood | correct. so i believe this establishes that morph *does* use the name field? | 12:28 |
| richard_maw | do you mean the name field in the chunk definition or in the chunk list in the stratum definition? | 12:29 |
| paulsherwood | either or both, for my purposes i'm just trying to establish that morph relies on the name - removing name: would break morph | 12:30 |
| richard_maw | removing the name completely would yes, since it would have no other way to represent build dependencies | 12:30 |
| paulsherwood | right | 12:30 |
| paulsherwood | and trying to rely on path instead would not work unless *all* details for ruby (eg repo ref as well as *commands) would need to be in strata/ruby/ruby.morph | 12:31 |
| richard_maw | paulsherwood: yep, that plus you couldn't ever depend on a split artifact without us changing how they are defined completely | 12:32 |
| paulsherwood | which is a much more invasive change, than (say) dropping path and making name:s unique? :-) | 12:33 |
| paulsherwood | (which would improve clarity imo) | 12:33 |
| *** Guest97990 has quit IRC | 12:33 | |
| richard_maw | it would be a more invasive change, but it may also make split artifacts more intuitive | 12:33 |
| richard_maw | since currently the rules are half built-in and half complicatedly defined, but if we split them out into a flie, then it can be made more obvious how they are defined | 12:34 |
| richard_maw | I like the idea of file paths, because it forces the structure to have no duplicates, and we don't need to load every definition file in the repository to make sense of the definitions, but it is a wider change to how splitting rules work, and prevents us ever doing in-line chunks | 12:36 |
| straycat | there's no reason logically to enforce the definitions of a name in the strata if it's defined in the chunk that's being referenced from the stratum | 12:36 |
| richard_maw | straycat: well, I'd prefer it went the other way around, since you need to use the name in the stratum | 12:37 |
| richard_maw | you don't need to use the name in the chunk definition | 12:37 |
| straycat | i don't see why we can't have them defined in the chunk definition and optionally inlined in the stratum | 12:38 |
| straycat | but i was just suggesting random ideas that have been suggested before, which https://gerrit.baserock.org/#/c/43/ has brought new attention to | 12:39 |
| richard_maw | oh you could, I just think it's extra congnitive load when trying to reason about a stratum if you have to constantly flick between two files to see what's going on | 12:39 |
| * paulsherwood notes believes the claim that morph doesn't use name has been refuted. and that therefore morph is currently relying on path *and* name | 12:40 | |
| straycat | i don't see where it got refuted | 12:40 |
| paulsherwood | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/ruby.morph#n37 | 12:41 |
| paulsherwood | morph ties hoe's dependency to ruby based on the name: field for the ruby chunk | 12:42 |
| straycat | i think i've misunderstood what we mean by 'name' then, i was talking about the name field defined in the stratum, which doesn't add any information | 12:42 |
| *** gary_perkins has quit IRC | 12:42 | |
| richard_maw | we're currently arguing about the duplication of 'name' in both the stratum and the chunk | 12:43 |
| *** gary_perkins has joined #baserock | 12:43 | |
| paulsherwood | i'm interested in making this generic, as you know - a definition can contain definitions. special handling for 'chunk' and 'strata' shouldn't be necessary imo | 12:44 |
| paulsherwood | anyways, i'm labouring my point and should let folks get on with more useful stuff :) | 12:45 |
| * richard_maw is as-yet unconvinced that bringing it down to one kind of definition will work, but we ought to be able to merge systems and strata | 12:57 | |
| *** mdunford has quit IRC | 13:00 | |
| *** Krin has quit IRC | 13:01 | |
| * richard_maw actually feels like we should introduce new definition types such as 'build-system', 'split-rule' and 'split-artifact' | 13:02 | |
| paulsherwood | richard_maw: what would convince you? if we make things unique i can already show build working, while dropping the meaning of the kind: field ('chunk' 'strata' 'system') entirely | 13:04 |
| paulsherwood | (for a certain value of working.. i've not deployed anything yet) | 13:06 |
| bashrc_ | the three layer structure is probably ok. I think of it as programs, groups of programs and systems. It could all be defined in a single file, but that be quite messy. | 13:06 |
| bashrc_ | the fieldnames of things should be unique, for machine readability | 13:06 |
| paulsherwood | the suggestion is more nesting, not less bashrc_ | 13:06 |
| paulsherwood | we already have it, in effect, with clusters | 13:07 |
| paulsherwood | (but that's me digressing) | 13:07 |
| bashrc_ | merging systems and strata might simplify things, but also might result in more duplicated maintenance. A big factor is the ability to maintain and add new things to a system. If the complexity is too great then users will just go elsewhere. | 13:10 |
| *** franred has quit IRC | 13:12 | |
| paulsherwood | i'm not suggesting merging them | 13:15 |
| paulsherwood | i'm suggesting possibility of a stratum containing other strata, or systems containing subsystems which contain strata containing chunks. but all those nouns go away and we have a definition can contain definitions, where definition replaces system, subsystem, stratum, chunk | 13:17 |
| pedroalvarez | so, one can define everything in one definition, but is not mandatory :) | 13:18 |
| pedroalvarez | I like the idea | 13:18 |
| paulsherwood | pedroalvarez: yes, that's my hope. one or many, in one directory or many, user can choose | 13:19 |
| *** franred has joined #baserock | 13:21 | |
| *** gary_perkins has quit IRC | 13:23 | |
| *** gary_perkins has joined #baserock | 13:26 | |
| *** wschaller has joined #baserock | 13:29 | |
| straycat | can anyone review this quick change: https://gerrit.baserock.org/#/c/194/ ? | 13:40 |
| *** franred has quit IRC | 13:45 | |
| *** edcragg has quit IRC | 13:48 | |
| *** zoli__ has quit IRC | 13:53 | |
| *** simonh_ has quit IRC | 13:57 | |
| *** franred has joined #baserock | 13:57 | |
| *** Krin has joined #baserock | 13:57 | |
| *** simonh_ has joined #baserock | 13:57 | |
| *** edcragg has joined #baserock | 13:59 | |
| *** Zara has joined #baserock | 14:00 | |
| *** gary_perkins_ has joined #baserock | 14:06 | |
| *** mdunford has joined #baserock | 14:06 | |
| *** gary_perkins has quit IRC | 14:06 | |
| *** tiagogomes_ has quit IRC | 14:08 | |
| richard_maw | paulsherwood, bashrc_, jonathanmaw, persia: any chance any of you have time to review ^ or https://gerrit.baserock.org/#/c/227/ ? I'd like someone who isn't working on OpenStack to be aware of the changes involved, rather than having the slightly suspect practise of approving it internally. | 14:09 |
| *** tiagogomes_ has joined #baserock | 14:09 | |
| jonathanmaw | richard_maw: done | 14:20 |
| richard_maw | jonathanmaw: and https://gerrit.baserock.org/#/c/194/ ? | 14:22 |
| jonathanmaw | richard_maw: more than I have time to think about that the moment, sorry. | 14:23 |
| *** zoli__ has joined #baserock | 14:23 | |
| richard_maw | thanks for reviewing #227 | 14:23 |
| * straycat discovers gerrit themes | 14:26 | |
| bashrc_ | can chunks contain build-depends? | 14:30 |
| richard_maw | no | 14:30 |
| straycat | 14:40 straycat$ can anyone review this quick change: https://gerrit.baserock.org/#/c/194/ ? | 14:41 |
| richard_maw | jjardon maybe? ^ | 14:46 |
| *** petefoth has quit IRC | 14:49 | |
| richard_maw | I've pinged everyone active today. straycat: how much is this change blocking you? | 14:50 |
| straycat | eh, i'll live | 14:52 |
| franred | in any case I vote +1 - so you have 2 +1 anyone external to Openstack project can also review it but if this does not happened it can be merged | 14:55 |
| franred | richard_maw, straycat ^^ | 14:55 |
| straycat | ok cool thanks | 14:55 |
| *** paulw has quit IRC | 15:03 | |
| *** paulw has joined #baserock | 15:05 | |
| * straycat wonders if it'd be nice to allow the use of multiple artifact cache servers | 15:08 | |
| pedroalvarez | it would be really really nice | 15:08 |
| pedroalvarez | so that a distbuild I have running here locally can reuse cache.baserock.org artifacts | 15:09 |
| jjardon | Hi, I heard baserock has a import tool, where is it? | 15:48 |
| straycat | gbo:baserock/baserock/import | 15:48 |
| *** mike has joined #baserock | 15:49 | |
| jjardon | straycat: thanks! | 15:49 |
| pedroalvarez | and some docs: http://wiki.baserock.org/guides/import-tool/quickstart/ | 15:49 |
| *** mike is now known as Guest53106 | 15:49 | |
| pedroalvarez | well, this one better: http://wiki.baserock.org/guides/import-tool/ | 15:49 |
| jjardon | pedroalvarez: amazing, thanks | 15:49 |
| *** simonh_ has quit IRC | 15:57 | |
| *** simonh_ has joined #baserock | 15:58 | |
| franred | new changes https://gerrit.baserock.org/#/c/228/ and https://gerrit.baserock.org/#/c/229/ | 16:01 |
| *** a1exhughe5 has quit IRC | 16:02 | |
| *** DavePage has quit IRC | 16:03 | |
| straycat | why do we want to move that to python-common? | 16:11 |
| franred | straycat, we need it for openstack-services.morph for cinder | 16:11 |
| straycat | if it's solely for openstack can it not stay in one of the openstack strata? | 16:12 |
| franred | straycat, it is cluod-init | 16:12 |
| franred | is in* | 16:12 |
| * franred sight.... | 16:13 | |
| franred | straycat, it is in cloudinit-support.morph and we will need it in openstack-services.morph | 16:13 |
| franred | (I can't do English today...) | 16:13 |
| straycat | oh i see | 16:14 |
| *** DavePage has joined #baserock | 16:14 | |
| straycat | that seems reasonable then | 16:17 |
| pedroalvarez | uh.. | 16:21 |
| pedroalvarez | base systems don't have python-common/python-core? | 16:21 |
| straycat | oh dear | 16:22 |
| straycat | that might be a problem then | 16:22 |
| straycat | wait, why do base systems need cloud-init? | 16:22 |
| pedroalvarez | git blame will blame me, since I added cloud-init to baserock | 16:23 |
| richard_maw | straycat: because they might be deployed into an openstack | 16:23 |
| franred | pedroalvarez, only x86 base-systems have cloud-init configuration extension | 16:24 |
| straycat | since we've been having abstract debates about definitions formats, i'll add that having this flat name space is perhaps not the best, generally people are working on a subset of definitions and maybe it's unreasonable to expect them to reason about the whole thing | 16:24 |
| pedroalvarez | richard_maw: I agree with that, but I wouldn't mind if we remove it from base systems | 16:24 |
| straycat | i mean here we are making changes to openstack and we've somehow almost broken the base system | 16:26 |
| straycat | were it not for pedroalvarez spotting that :) | 16:26 |
| franred | jjardon, could you have a look at https://gerrit.baserock.org/#/c/228/ ? | 16:26 |
| franred | straycat, the basesystem were broken before this patches arrived | 16:26 |
| *** flatmush has quit IRC | 16:27 | |
| straycat | franred, oh? | 16:27 |
| pedroalvarez | yup | 16:27 |
| franred | and I have to blame me for not realizing about that when I moved things from cloud init | 16:27 |
| richard_maw | runtime dependencies! | 16:27 |
| straycat | how are they broken? | 16:27 |
| pedroalvarez | richard_maw: +1! | 16:27 |
| pedroalvarez | straycat: well, cloud init stratum needs python-core and python-whatever to run I guess | 16:28 |
| straycat | right | 16:28 |
| jjardon | franred: sure | 16:28 |
| pedroalvarez | I'm sure that we will end up adding support for runtime dependencies, but is taking time for other people to see that need :) | 16:29 |
| franred | pedroalvarez, python-core and python-common | 16:29 |
| straycat | pedroalvarez, sorry i still don't understand why the base system is broken? | 16:29 |
| franred | I can make a fast patch to add these to base-systems if we want to continue supporting them to deploy to openstack | 16:30 |
| franred | pedroalvarez, ^^ | 16:30 |
| straycat | i'm talking about current HEAD sans franred's patches | 16:30 |
| pedroalvarez | straycat: base system is missing runtime depencencies for cloud-init | 16:30 |
| straycat | the base system includes cloudinit-support? | 16:31 |
| straycat | well the x86 ones do | 16:31 |
| pedroalvarez | is not really broken, but cloud-init won't work | 16:31 |
| straycat | why not? | 16:31 |
| pedroalvarez | if cloud-inits is missing runtime dependencies, I can't see how it might work | 16:31 |
| pedroalvarez | some things were moved from cloudinit-support to python-*, and those strata weren't added to the base systems | 16:32 |
| pedroalvarez | That's why I'm saying that it might be missing runtime depenencies | 16:33 |
| straycat | ahh okay | 16:33 |
| pedroalvarez | \o/ | 16:33 |
| * franred creates a patch to fix that | 16:34 | |
| pedroalvarez | franred: thanks | 16:35 |
| straycat | what fix are you going to apply? | 16:35 |
| franred | straycat, I will add python-common and python-core to the systems which have cloudinit-support.morph | 16:36 |
| jjardon | Id create a new system: base-system-opensatack os something like that instead change our current base systems | 16:36 |
| franred | pedroalvarez, I don't understand why cloudinit-support.morph needs build-essential and foundation as build dependencies... is not the former inside the latest? | 16:37 |
| richard_maw | yes, but there was a push for more explicit build dependencies | 16:37 |
| pedroalvarez | we are not being consistent anyway :/ | 16:37 |
| franred | richard_maw, can I not remove build-essential as a build dependency then? | 16:38 |
| straycat | oh damn, i thought people were only going to do that for chunk dependencies | 16:38 |
| richard_maw | straycat: that's only the latest push, we've had pushes to do so before | 16:38 |
| * jjardon prefer everything explicit | 16:39 | |
| jjardon | Its a mess when you create/change strata and you have to move things around | 16:40 |
| richard_maw | what bites us when moving things around is how you need to list everything in the system, but it includes recursively in the stratum, we could fix this by having some form of implicit dependencies in the system | 16:43 |
| *** flatmush has joined #baserock | 16:43 | |
| *** Guest53106 has quit IRC | 16:46 | |
| straycat | i also think what bites us is we expect the user to reason about an entire graph of components where changes in one section can propagate to changes in another completely unrelated section. i keep thinking it'd be nice to allow subgraphs to override components inherited from other sections, but that might be stupid/crazy | 16:46 |
| straycat | i'll quiet down now and go do something useful :) | 16:47 |
| straycat | but other things do it, so it's obviously not that stupid | 16:51 |
| *** Albert has quit IRC | 16:58 | |
| *** bashrc_ has quit IRC | 17:02 | |
| franred | pedroalvarez, https://gerrit.baserock.org/#/c/230/ | 17:06 |
| franred | straycat, ^^ | 17:10 |
| straycat | that makes the x86 base systems inconsistent with all other base systems? | 17:12 |
| franred | straycat, the other base systems doesn't have cloudinit-support | 17:18 |
| straycat | i know, one base system having python and another not having python seems like a substantial difference for something that's supposedly the same system | 17:19 |
| straycat | could you not create a common stratum that cloud-init and openstack could depend on? | 17:21 |
| franred | straycat, what you are describing is python-common | 17:22 |
| straycat | no | 17:23 |
| franred | straycat, also the base-systems are already differents because some of them support cloudinit and other no | 17:23 |
| franred | I can't ses your point sorry | 17:23 |
| franred | s/ses/see/ | 17:23 |
| pedroalvarez | straycat: so you are suggesting to remove cloudinit from those systems? | 17:24 |
| pedroalvarez | or adding them also to the others? | 17:24 |
| straycat | that or create a common stratum for configobj | 17:24 |
| pedroalvarez | straycat: but they were more things in common between cloud-init and openstack | 17:25 |
| pedroalvarez | that's when we decided to create python-common | 17:25 |
| *** edcragg has quit IRC | 17:25 | |
| pedroalvarez | straycat: so you are suggesting to create another stratum for configobj? | 17:32 |
| straycat | either that or remove cloud-init from base-system, or if you need python-common then add it to all base systems, or if you need python-{common,core} add it to all base systems, but i doubt people would want python in the base system | 17:34 |
| pedroalvarez | just answered in gerrit about "python in the base system" | 17:36 |
| pedroalvarez | I see your point though. | 17:38 |
| straycat | i replied :) | 17:38 |
| pedroalvarez | I'm starting to think that we could remove cloud-init from there | 17:40 |
| pedroalvarez | one can deploy them to opentack anyway | 17:40 |
| straycat | that would probably be ok then | 17:41 |
| straycat | i wish we could just define these things in multiple places it'd be much simpler | 17:42 |
| pedroalvarez | "The set of strata required to have a minimal system" | 17:43 |
| pedroalvarez | maybe makes sense to remove it from the base systems | 17:43 |
| pedroalvarez | maybe creating a cloud-base system? | 17:43 |
| straycat | maybe | 17:45 |
| *** franred has quit IRC | 17:52 | |
| *** franred has joined #baserock | 17:54 | |
| *** franred has quit IRC | 17:55 | |
| *** wschaller has quit IRC | 18:12 | |
| *** zoli__ has quit IRC | 18:29 | |
| jjardon | That's what I suggested before:17:36 <jjardon> Id create a new system: base-system-opensatack os something like that instead change our current base systems | 18:40 |
| *** gary_perkins_ has quit IRC | 20:24 | |
| *** flatmush has quit IRC | 20:26 | |
| paulsherwood | i was arguing for explicit dependencies for chunks, not for strata. for strata they nest anyway. if strata-c depends on strata-b which depends on strata-a, no need to specify strata-a in c | 20:55 |
| paulsherwood | (and only to be explicit about depencies on sibling chunks in the same stratum, since the chunks in build-depend strata are clearly implied) | 20:56 |
| *** pedroalvarez has quit IRC | 23:50 | |
| *** pedroalvarez has joined #baserock | 23:51 | |
| *** ChanServ sets mode: +v pedroalvarez | 23:51 | |
| *** juergbi has quit IRC | 23:57 | |
| *** juergbi has joined #baserock | 23:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!