| *** rdale has joined #baserock | 07:09 | |
| *** Albert_ has joined #baserock | 07:18 | |
| *** jonathanmaw has joined #baserock | 07:33 | |
| *** sambishop has quit IRC | 07:41 | |
| *** sambishop has joined #baserock | 07:41 | |
| *** bashrc_ has joined #baserock | 08:03 | |
| *** mwilliams_ct has quit IRC | 08:06 | |
| jonathanmaw | hrm, it looks like the browser-PoC won't work without a dbus connection, I assume on a session bus. | 08:17 |
|---|---|---|
| jonathanmaw | I managed to get it running with a wayland connection (the secret is "-platform wayland"), but now dbus reared its ugly head again. | 08:17 |
| SotK | I had to start dbus to get it to work | 08:20 |
| * SotK should probably have documented how far he got better | 08:20 | |
| SotK | I think I just did "export `dbus-launch`" before running it when I was testing | 08:23 |
| *** ssam2 has joined #baserock | 08:25 | |
| *** ChanServ sets mode: +v ssam2 | 08:25 | |
| *** fay_ has quit IRC | 08:30 | |
| SotK | I sent new versions of my partial distbuild and partial build test changes to Gerrit to get round the weird Merge conflict issue | 08:30 |
| SotK | they now need code review votes again though :( | 08:30 |
| ssam2 | thanks, I've submitted them now | 08:33 |
| SotK | thanks | 08:33 |
| ssam2 | I think the 'rebase' button in the UI might have been enough | 08:33 |
| ssam2 | although that also means the patch needs votes again | 08:33 |
| radiofree | jonathanmaw: you can do dbus-launch --sh-syntax > /tmp/dbus-session | 08:35 |
| *** fay_ has joined #baserock | 08:35 | |
| radiofree | Then source /tmp/dbus-session whenever you need to use a session bus | 08:35 |
| *** tiagogomes_ has joined #baserock | 08:36 | |
| radiofree | Also probably a good idea to set QT_QPA_PLATFORM to wayland-egl | 08:38 |
| *** fay_ has quit IRC | 08:42 | |
| *** mdizzle has joined #baserock | 08:46 | |
| *** franred has joined #baserock | 08:47 | |
| *** fay_ has joined #baserock | 08:49 | |
| jonathanmaw | How do I make a baserock VM provide /dev/fb0? | 08:50 |
| jonathanmaw | it seems my kernel command-line is missing vga=<thing> | 08:51 |
| radiofree | Look in the logs from last night | 08:54 |
| radiofree | There's a discussion on how to add it | 08:54 |
| radiofree | Around 10pm | 08:54 |
| jjardon | ssam2: the /etc/profile part is done in the next patch of the same topic | 08:58 |
| *** gary_perkins has joined #baserock | 08:59 | |
| jjardon | BTW, if you put the bash-completion patch on top you will have auto completion enable by default when using bash | 09:00 |
| *** gary_perkins has quit IRC | 09:00 | |
| *** gary_perkins has joined #baserock | 09:00 | |
| jonathanmaw | is there a way to read the irc logs? I wasn't on this channel at 10PM last night. | 09:04 |
| SotK | jonathanmaw: http://irclogs.baserock.org/ | 09:04 |
| *** edcragg has joined #baserock | 09:04 | |
| ssam2 | jjardon: that's cool, i've got so used to it not being there that I don't even miss it, but that's not really a good thing | 09:05 |
| ssam2 | jjardon: I missed part 2 of the patch | 09:05 |
| ssam2 | it's a bit weird that we set up /etc/profile in the busybox chunk | 09:06 |
| jjardon | Yeah, I plan to change that | 09:06 |
| jjardon | It should be done in our fhs-dirs | 09:07 |
| ssam2 | yeah that would make more sense | 09:07 |
| rdale | as long as it isn't shell specific | 09:07 |
| ssam2 | jjardon: might be nice to have it done in a configure extension instead, because it doesn't need to be present at build time | 09:07 |
| ssam2 | if it's in fhs-dirs then every change to /etc/profile triggers a rebuild of everything | 09:08 |
| paulsherwood | we have two fhs-dirs already, why not have another one :) | 09:13 |
| paulsherwood | stage3-fhs-dirs, fhs-dirs for example? | 09:13 |
| paulsherwood | then fhs dirs could be done *last* maybe? | 09:13 |
| jonathanmaw | hrm, the browser PoC is running without spewing errors, but I don't see anything other than console logging :¬| | 09:14 |
| * paulsherwood may be missing something | 09:14 | |
| ssam2 | paulsherwood: that might work, it's hard to express in definitions 'build this last' right now though | 09:14 |
| SotK | jonathanmaw: how did you run it? | 09:14 |
| ssam2 | paulsherwood: we could have fhs-dirs in its own strata, then we have yet another stratum to add to systems | 09:14 |
| ssam2 | paulsherwood: but seems a good simple solution | 09:15 |
| paulsherwood | ssam2: no it's not? stick it in its own stratum, and make that depend on stuffs? or stick iit in bsp | 09:15 |
| jonathanmaw | SotK, inside weston, with /usr/lib/browser-poc/browser/bin/browser | 09:15 |
| paulsherwood | (bsp already gets built approximately last iiuc) | 09:15 |
| *** Krin has joined #baserock | 09:15 | |
| ssam2 | paulsherwood: a system has to list every stratum it wants to contain, build-dependencies don't affect system contents | 09:15 |
| jonathanmaw | with a running session bus, and QT_QPA_PLATFORM=wayland-egl | 09:16 |
| SotK | jonathanmaw: aha, you also need to run the demoui to actually see anything IIRC | 09:16 |
| ssam2 | paulsherwood: putting it in BSP seems weird, but BSP is a weird name anyway :) | 09:16 |
| paulsherwood | ssam2: well, in spite of the above, which may all be true, if the 'last' fhs-dirs was in bsp, it would get built last-ish, i believe | 09:16 |
| paulsherwood | (but this might have other side-effects) | 09:17 |
| SotK | FSVO last, unless anything depends on the bsp stratum I think | 09:17 |
| paulsherwood | FSVO? | 09:17 |
| persia | Isn't fhs-dirs a build-dependency for some things? | 09:17 |
| SotK | paulsherwood: for some value of | 09:18 |
| paulsherwood | persia: yes, hence i'm suggesting having stage3-fhs-dirs to achieve what the current fhs-dirs does | 09:18 |
| persia | paulsherwood: high-level stuff like X might build after the BSP, as it has more build-deps and isn't needed for BSP. BSP only builds last for simple systems. | 09:18 |
| paulsherwood | (but this might lead to a twisty maze of everything depending on everything else) | 09:18 |
| SotK | It might not actually be the *last* think built, but rebuilding it wouldn't cause anything else to be rebuilt unless other things depend on the BSP stratum | 09:18 |
| paulsherwood | persia: what SotK said | 09:19 |
| ssam2 | has anyone done a build of a459c78d170f5c8bc469229425e036f4c3302e95 of definitions on ARM ? I'm getting a build failure with stage2-glibc | 09:19 |
| ssam2 | configure: error: cannot compute suffix of object files: cannot compile | 09:19 |
| SotK | persia: only two strata depend on the BSP at the moment, virtualization and virtualbox-guest-x86_64 | 09:19 |
| paulsherwood | missing build-dependency, ssam2 i think. | 09:20 |
| persia | SotK: Right, but if I build xgalaga, there's a decent chance that the BSP builds before this (but it doesn't matter). | 09:20 |
| ssam2 | weird, did we remove one? | 09:20 |
| SotK | in fact, maybe virtualization doesn't | 09:20 |
| persia | VB guest should need to know the kernel to make the right modules. | 09:21 |
| paulsherwood | ssam2: i don't believe so, but could you check whether that build-essential has the same build-deps explicit as in master? | 09:21 |
| ssam2 | this is master | 09:21 |
| paulsherwood | oh!? | 09:21 |
| ssam2 | could be some weird fs corruption on this Jetson | 09:21 |
| ssam2 | btrfs has been acting up on it alreayd | 09:22 |
| ssam2 | *already | 09:22 |
| paulsherwood | odd, then. i built past that this morning on x86 with ybd | 09:22 |
| paulsherwood | for that sha12 | 09:22 |
| paulsherwood | sha1 | 09:22 |
| ssam2 | x86 is fine, https://mason-x86-64.baserock.org/ is green | 09:22 |
| paulsherwood | ssam2: ok so yes corruption is one possibility | 09:23 |
| paulsherwood | maybe blow your artifats away? | 09:23 |
| ssam2 | I don't see anything in master that suggests 'break bootstrap on ARM', so I guess so | 09:23 |
| ssam2 | yeah, maybe my cache is corrupt. | 09:23 |
| ssam2 | which reminds me, need to investigate how OSTree handles cache corruption. Hopefully it detects such things! | 09:23 |
| * paulsherwood intends to use MD5 for ybd | 09:24 | |
| ssam2 | seems OSTree has a 'fsck' command :) | 09:29 |
| jjardon | paulsherwood: I'd go for sha256 instead | 09:29 |
| ssam2 | since it is content-addressed, like Git, detecting corruption is probably easy | 09:29 |
| ssam2 | (in OStree) | 09:29 |
| richard_maw | paulsherwood: we should be taking configuration files out of fhs-dirs, not putting more fhs-dirs chunks in the system. fhs-dirs was initially supposed to be just enough of a filesystem structure to handle builds that expect the filesystem to be set up | 09:29 |
| richard_maw | paulsherwood: we've put configuration files for things that aren't needed at build time in there just for lack of a good place to put them | 09:30 |
| richard_maw | paulsherwood: I'd prefer that configuration files be added by system-integration commands, so that they can programmatically select the best thing, like only include /etc/inittab if /sbin/init is a symlink to busybox | 09:31 |
| richard_maw | paulsherwood: but a lot of these configuration files are actually more appropriate to generate at deployment time anyway, where they can be parameterised, so I'd like to have the inclusion of a chunk trigger a certain configuration extension to be run | 09:32 |
| jjardon | richard_maw: I plan to do modification in /etc/profile and /etc/password, and Id like to introduce /etc/os-release in definitions (rigth now that one is hardcoded in morph!!). How should I proceed? | 09:38 |
| paulsherwood | richard_maw: i think you understand this way more deeply than me, so i leave it to you and others to establish the best soln here :-) | 09:39 |
| paulsherwood | jjardon: agreed, you're right | 09:39 |
| persia | jjardon: When introducing os_release, please be sure to use "reference" or similar to indicate that the result is not usefully branded "Baserock". | 09:42 |
| jjardon | I can do the easy way (modify fhs-dirs), then implement the proper way; or go for the proper way directly: what should I do in this case? Implement a new extension? I think I remember there there is already an extension to copy files to the system? | 09:42 |
| richard_maw | jjardon: yeah, the install-files extension | 09:42 |
| jjardon | persia: our reference system will all be branded Baserock | 09:42 |
| persia | Please no. Please brand "Baserock reference" or similar. | 09:42 |
| jjardon | persia: lets talk about that when we get there | 09:43 |
| persia | There is already too much confusion surrounding people saying "foo is in a Baserock system", or "Baserock systems default to having bar (not) installed". | 09:43 |
| richard_maw | jjardon: for /etc/profile and /etc/os-release, dropping install-files in may be appropriate, /etc/passwd is more complicated though | 09:43 |
| persia | When Baserock itself only provides tooling to define, build, and deploy systems. | 09:43 |
| jjardon | persia: FYI, rigth now _any_ system builded with morph will be "Baserock" | 09:43 |
| paulsherwood | ssam2: i'll be really interested to know full-build comparison time with and without ostree... do you know if anyone has done that yet? | 09:43 |
| paulsherwood | s/builded/built/ jjardon :) | 09:43 |
| persia | Ah. I consider that a serious bug, and understand the confusion I just described in more detail. Thanks for the explanation. | 09:44 |
| jjardon | richard_maw: problem is that we have to check that /etc/passwd, /etc/shadow and groups are in sync | 09:45 |
| jjardon | paulsherwood: thanks :) | 09:46 |
| richard_maw | jjardon: yep, and the lack of any infrastructure to set it up in a way which is reliably consistent with how it will be interpreted at run-time, given the mess of nss modules | 09:46 |
| richard_maw | jjardon: it's for this reason that systemd has added the sysusers stuff | 09:47 |
| richard_maw | jjardon: but we haven't had time to evaluate whether sysusers is suitable for our needs | 09:47 |
| jjardon | ok, I will submit tasks to storyboard so all this doesnt get lost | 09:47 |
| SotK | paulsherwood: I've tested deploying a build-system tarball with and without ostree, and found it takes less than half the time with ostree (2m20s compared with 5m56s without on average) | 09:49 |
| robtaylor | \o/ | 09:50 |
| richard_maw | SotK: that sounds about right, given it ought to cut out a redundant copy | 09:50 |
| richard_maw | and a lot of building is IO bound | 09:51 |
| richard_maw | but I think it's the reworking of system artifact creation in particular that's cutting the time down there | 09:51 |
| * richard_maw missed that you were talking about deploying only | 09:51 | |
| jjardon | SotK: amazing, does the ostree community know we are using it in baserock? | 09:52 |
| SotK | jjardon: I don't think so yet | 09:53 |
| ssam2 | paulsherwood: not yet | 09:53 |
| ssam2 | I'm planning on setting up 2 Jetsons, one with OStree, one without. But the one with OSTree turned up a bug, so I'm waiting for the v2 branch | 09:53 |
| SotK | richard_maw: yeah, `ostree checkout` is much quicker than unpacking a tarball | 09:53 |
| paulsherwood | ssam2: how hard is it to set this up on x86? | 09:54 |
| paulsherwood | are we using ostree? is it actually merged to master now? | 09:54 |
| SotK | not yet | 09:55 |
| paulsherwood | jjardon: please hold, then :-) | 09:55 |
| ssam2 | paulsherwood: not too hard, you need a branched definitions, and a branched morph | 09:55 |
| paulsherwood | and a system with ostree, surely? | 09:56 |
| ssam2 | that's what I meant by 'branched definitions' | 09:56 |
| paulsherwood | i mean to run the build on | 09:56 |
| ssam2 | your build system needs to be built from adam's branch with ostree | 09:56 |
| paulsherwood | right. | 09:56 |
| ssam2 | it can build current master of definitions | 09:56 |
| paulsherwood | so i would need to update to a system containing ostree, and then run the test there | 09:57 |
| ssam2 | the current Morph branch has some bugs that make things much slower than they should be, so best to wait for the v2 branch | 09:57 |
| richard_maw | paulsherwood: the issues with merging the ostree work were sam's bugs, bugs with sharing artifacts between ostree and non-ostree, and the fact that it was so large a patch series that it took me all day to review and I didn't catch everything | 09:57 |
| ssam2 | I think SotK has about 3 different tasks in progress right now :) | 09:57 |
| paulsherwood | richard_maw: understood. i'm very happy to see this work being done, and i appreciate it's a significant change | 09:57 |
| * SotK will push his WIP v2 branch if that would be useful | 09:58 | |
| jjardon | ssam2: thanks for the reviews! :). In case you have some time, the "terminal_title" patches to show the build progression in the terminal title should work now with the bash fixes | 09:58 |
| ssam2 | cool, will look later (I have a call now) | 09:59 |
| richard_maw | SotK: unless it's significantly changed such that we could review and even accept most of the commits independently, I'm not sure we can usefully review it | 10:00 |
| *** Albert__ has joined #baserock | 10:01 | |
| *** Albert_ has quit IRC | 10:01 | |
| edcragg | has anyone seen problems building erlang for BE vs. LE? http://paste.baserock.org/futitajuvi | 10:02 |
| edcragg | LE builds fine | 10:03 |
| radiofree | is erlang on a build-system? | 10:06 |
| edcragg | no, this is the openstack-server system | 10:07 |
| radiofree | ah, then i have no idea, didn't have problems building a BE build-system at least | 10:07 |
| SotK | splitting the ostree branch into atomic changes seems like a lot of work just to undo it all to get back to where it is now at the end... | 10:09 |
| edcragg | seems the built erlang compiler segfaults | 10:11 |
| jjardon | richard_maw: ssam2 where the "manifest" with the files to install (/etc/profile, /etc/os-release) should be? (looking to another systems, they are in distbuild/manifest, chef/manifest,moonshot/manifest ... ) | 10:11 |
| jjardon | maybe in /generic/manifest ? Problem is that these files are mandatory, not optional, so it will be problems if a user forget to put INSTALL_FILES in his cluster definition | 10:13 |
| rjek | i/win 25 | 10:14 |
| rjek | x | 10:14 |
| rdale | there seem to be two hosts involved in the baserock org infrastructure - trove.baserock.org and git.baserock.org. the url for the definitions.git repo is on the git.baserock.org host. i wonder how does 'trove-host' seem to refer to both? | 10:25 |
| richard_maw | jjardon: this is why I wanted chunks to provide a default configuration file for the networking, but have it be overridden by configuration extensions | 10:32 |
| richard_maw | jjardon: that, or a way to have configuration extensions be triggered by a chunk's inclusion | 10:32 |
| gary_perkins | rdale: trove.b.o and git.b.o are the same thing. I got confused about it too a while ago | 10:33 |
| rdale | oh ok | 10:33 |
| ssam2 | SotK: I can usefully review V2 :) | 10:33 |
| richard_maw | jjardon: fortunately you can overwrite a file with install-files, and you can use multiple manifests | 10:33 |
| ssam2 | when its ready | 10:33 |
| SotK | ssam2: great, thanks :) | 10:33 |
| ssam2 | jjardon: I hate the install-files extension with a passion | 10:34 |
| ssam2 | but maybe it is the best interim solution for /etc/profile etc. | 10:34 |
| straycat | it could certainly be improved | 10:34 |
| jjardon | :) ok, /etc/profile, /etc/os-release doesnt belong to a specific chunk, but fhs-dirs. Should I patch fhs-dirs with a minimal version of these files, then add the specific info as an extension? | 10:35 |
| ssam2 | I think it's OK to have a mandatory INSTALL_FILES line when deploying a system for now.. cluster morphs are too complex for most people to be able to write then out from memory anyway | 10:35 |
| jjardon | ssam2: are you ok to have those files list in generic/manifest and the files itsself in generic/system/profile, generic/system/os-release ... in the definitions repo? | 10:37 |
| ssam2 | jjardon: does anything break at build-time if there's no /etc/profile or /etc/os-release file? I don't see why we'd need skeleton versions in fhs-dirs | 10:37 |
| ssam2 | jjardon: maybe 'base' ? | 10:38 |
| pedroalvarez | edcragg: no clue about that problem building erlang in BE | 10:38 |
| ssam2 | 'base' is as overloaded as 'generic' I guess | 10:38 |
| ssam2 | base-files/ or essential-files/ or somthing | 10:39 |
| ssam2 | and why system/profile instead of etc/profile ? | 10:39 |
| jjardon | system/profile is only the location of the file in the repo. It will be moved to /etc/profile (or /usr/shared/etc/profile eventuyally) at deploy time | 10:41 |
| jjardon | ok, what about: essential-files/generic/manifest , then we can move the different manifest to the essential-files directory: essential-files/distbuild, essential-files/moonshot ... etc | 10:42 |
| richard_maw | I'd prefer a multitude of chunks which aren't depended on by anything providing this stuff, but the only way to sanely do this with the current tooling is to introduce a splitting rule to build-essential or core or whatever chunk which has $foo-runtime-config, and we change all the stratum build-depends to not include it | 10:43 |
| * richard_maw said the above with far more certainty than there actually exists for thing being the best solution | 10:45 | |
| richard_maw | the problem is that we want to avoid unnecessary dependencies and want the config to be included by default in some form | 10:45 |
| richard_maw | and we'd like to avoid creating strata just for config files, as we'd just forget them | 10:46 |
| ssam2 | jjardon: if it's going to be called etc/profile in the system, why not call it etc/profile in definitions.git as well? | 10:46 |
| ssam2 | seems confusing to call it system/profile when it gets installed as etc/profile | 10:46 |
| ssam2 | I was thinking keep distbuild/ (maybe rename it to distbuild-files), add a new essential-files/ with essential-files/etc/profile etc. | 10:46 |
| ssam2 | richard_maw: I think having a set of files that get installed in a system post-deploy is something we'll aways need, so we should try to make it really easy to have some files from definitions.git appear directly in the resulting system | 10:48 |
| ssam2 | richard_maw: I agree we'll need a more clever solution for some files (/etc/passwd for example) | 10:48 |
| jjardon | the reason for grouping is because rigth now we already have chef/manifest, distbuild/manifest and moonshot/manifest. This will add another essential-files/manifest | 10:48 |
| ssam2 | s/post-deploy/at deploy time/ | 10:48 |
| ssam2 | jjardon: let's not muddle two problems together, though | 10:49 |
| jjardon | ok | 10:49 |
| ssam2 | jjardon: creating a toplevel files/ directory to hold files/distbuild/, files/chef/ files/essential etc. sounds like quite a good idea | 10:50 |
| ssam2 | but I think it should be proposed separately to this | 10:50 |
| jjardon | yep, agree | 10:50 |
| * jjardon seems to have on a infinite loop of things to fix underneath when he tries to fix something :) | 10:51 | |
| jjardon | ok, so is it ok to follow this plan?: modify all the clusters from the generic systems to include INSTALL_FILES and also to generate essential-files/manifest and essential-files/etc/profile and essential-files/etc/os-release (probably more in the future) | 10:55 |
| ssam2 | I would +1 that | 10:56 |
| * SotK too | 10:56 | |
| ssam2 | especially if a patch to remove /etc/profile from fhs-dirs was promised as well :) | 10:56 |
| pedroalvarez | was the idea of adding a configure exts for this dropped? | 10:57 |
| ssam2 | I'd rather see install-files.configure become easier to use, personally | 10:57 |
| pedroalvarez | so nobody can avoid the creation of this file (muahah) | 10:57 |
| ssam2 | there is that ... | 10:57 |
| straycat | hrm | 10:58 |
| ssam2 | but I think what Javier proposes is still an improvement, so I'd still +1 it | 10:58 |
| straycat | we'd need to make INSTALL_FILES a mandatory key in cluster morphs to avoid mistakes | 10:58 |
| ssam2 | I think writing clusters is hard enough that you have to copy an existing one already | 10:58 |
| * straycat doesn't | 10:59 | |
| jjardon | ssam2: done, /etc/profile is not in fhs-dirs already :) | 10:59 |
| straycat | I write the simple ones | 10:59 |
| straycat | that's also not a terribly good reason for making the ui worse than it already is | 10:59 |
| straycat | i'm not against this change per se, but you need to make it easy for the user to spot the error up front i.e. really early in the deploy stage | 11:00 |
| straycat | and i kinda thing a conf ext might be better for this | 11:00 |
| straycat | *think | 11:00 |
| ssam2 | maybe an easy middle ground is create a new configure extension that just chains to 'install-files essential-files/MANIFEST' | 11:00 |
| straycat | yes i think that would be better | 11:02 |
| bashrc_ | is there any documentation on "morph branch"? I may be misunderstanding what it's doing | 11:02 |
| straycat | bashrc_, besides morph help branch, i'm not sure | 11:03 |
| SotK | bashrc_: I don't know if there is anything beyond `morph branch --help` | 11:03 |
| SotK | bashrc_: what's the misunderstanding? | 11:03 |
| bashrc_ | I was thinking that it creates a new branch | 11:05 |
| bashrc_ | but actually in my tests I don't think it does. It looks like it just uses an existing branch | 11:05 |
| SotK | that's weird, it should create a new branch | 11:06 |
| ssam2 | it creates a new 'morph system branch', which isn't the same as a Git branch | 11:07 |
| ssam2 | I think it does create a new Git branch in the local clone of definitions it creates, too | 11:07 |
| bashrc_ | I think morph branch probably is doing what I originally thought, but that there's a bug which causes different behaviour | 11:07 |
| gary_perkins | does "UPSTREAM_TROVE:" default to anything? or will it remain blank if I comment it out? I just want a trove to not lorry anything from upstream | 11:07 |
| straycat | gary_perkins, nahh it defaults to nothing | 11:08 |
| gary_perkins | straycat: Cool thanks :) | 11:08 |
| straycat | kinda handy if you just want a gitano box for your own stuff :) | 11:09 |
| jjardon | ssam2: ok, and that configure extension should be addded to all the systems/* , no need to modify the clusters as essential-files/MANIFEST will be hardcoded in the extension, rigth? | 11:19 |
| ssam2 | yes | 11:21 |
| *** mdunford has quit IRC | 11:48 | |
| *** ssam2 has quit IRC | 12:33 | |
| *** mdunford has joined #baserock | 12:40 | |
| *** ssam2 has joined #baserock | 12:48 | |
| *** ChanServ sets mode: +v ssam2 | 12:48 | |
| *** ssam2 has quit IRC | 13:03 | |
| *** ssam2 has joined #baserock | 13:15 | |
| *** ChanServ sets mode: +v ssam2 | 13:15 | |
| *** mdunford has quit IRC | 13:19 | |
| *** mdunford has joined #baserock | 13:34 | |
| pedroalvarez | I wonder how can a boot a system that doesn't run networkd | 13:44 |
| pedroalvarez | I mean, I'd like to investigate the status of the system before it networkd starts | 13:45 |
| richard_maw | pedroalvarez: you can change the default target with systemctl, or on the kernel command line | 13:47 |
| richard_maw | pedroalvarez: I had to look at stuff pre-networkd too, and found that setting the default target to getty.target worked | 13:47 |
| pedroalvarez | richard_maw: will try that! thanks | 13:47 |
| pedroalvarez | indeed, that workd | 13:56 |
| pedroalvarez | ed* | 13:56 |
| *** sambishop has quit IRC | 14:04 | |
| jjardon | tiagogomes_: seems you added a drop-config-files extension, is this being used somewhere? | 14:05 |
| tiagogomes_ | did I? | 14:06 |
| bashrc_ | I don't think I have permission to push to http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/firehose.git | 14:06 |
| straycat | pedroalvarez, git-review does make that easier thanks pedroalvarez | 14:08 |
| pedroalvarez | good, it's already in devtools :) | 14:08 |
| jjardon | tiagogomes_: yes, in 2013: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/morphlib/exts/add-config-files.configure?id=38153ff6cc71ed5d0010869a68e88477d7ebb4e9 | 14:08 |
| straycat | sweeeet | 14:09 |
| jjardon | I ask because seems to overlap with what we discuss before | 14:09 |
| tiagogomes_ | jjardon I think that was superseded by install-files, which hopefully will be superseded by something else | 14:10 |
| tiagogomes_ | 2013! | 14:10 |
| pedroalvarez | bashrc_: see http://wiki.baserock.org/policies/ | 14:10 |
| pedroalvarez | "Maintainership" | 14:10 |
| tiagogomes_ | that's centuries ago for baserock | 14:10 |
| pedroalvarez | bashrc_: why would you need push access? | 14:11 |
| *** sambishop has joined #baserock | 14:15 | |
| jjardon | ssam2: is it ok to reuse add-config-files or should I create a new one? | 14:22 |
| gary_perkins | Perhaps I'm doing this wrong, but deploying a trove to openstack and while attaching a /dev/vdb as /home just doesn't work smoothly. Because, of course, mounting a new /home makes all the previous contents disappear. | 14:22 |
| pedroalvarez | gary_perkins: have you removed the previous entry for /home in /etc/fstab? | 14:23 |
| pedroalvarez | also, define "doesn't work smoothly" | 14:24 |
| pedroalvarez | I would expect that things in /home are regenerated if you re-run the trove-setup systemd unit | 14:24 |
| gary_perkins | I followed the "nova bott" command from the docs, but it doesn't attach /dev/vdb. But I did that anyway. | 14:27 |
| gary_perkins | So I think, the procedure should just be nova boot with attached /dev/vdb, then manually run the trove-setup script? | 14:28 |
| gary_perkins | s/bott/boot/ | 14:28 |
| gary_perkins | or have it run trove-setup twice? At instance creation and manually once it's completed booting? | 14:30 |
| jonathanmaw | hrm, ambctl (for automotive-message-broker) fails because it can't 'import dbus'. I can't 'import dbus' in a baserock devel environment either. | 14:30 |
| jonathanmaw | how do I make sure dbus is in python? | 14:31 |
| radiofree | http://www.freedesktop.org/wiki/Software/DBusBindings/ ? | 14:31 |
| jonathanmaw | ooh, pydbus | 14:32 |
| radiofree | actually probably not that | 14:32 |
| radiofree | http://dbus.freedesktop.org/releases/dbus-python/ | 14:32 |
| radiofree | dbus-python i think | 14:32 |
| radiofree | http://cgit.freedesktop.org/dbus/dbus-python/ | 14:33 |
| jjardon | I think the prefered way nowadays is to use the python GDBus bindings | 14:33 |
| bashrc_ | pedroalvare: I was going to create a baserock/bmottram/firehose branch which matches the current readme | 14:34 |
| jjardon | nevermind, do not think thats actually true | 14:34 |
| radiofree | jjardon: cool, fancy porting over a genivi component to use them? | 14:34 |
| ssam2 | jjardon: what is add-config-files ? | 14:41 |
| jjardon | ssam2: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/exts/add-config-files.configure | 14:42 |
| jjardon | I mean reuse the name, as seems is was done for exactly the same what we want to achieve here | 14:42 |
| ssam2 | I think install-essential-files would be a better name | 14:43 |
| ssam2 | I don't we should have one extension use 'add' and another extension say 'install' to mean the same thing | 14:43 |
| ssam2 | *I don't think | 14:44 |
| jjardon | rigth | 14:44 |
| jjardon | does baserock support ARMv5? is it possible with current morph to bringup a Baserock-built linux on an ARMv5 system? | 14:52 |
| paulsherwood | good question.... richard_maw ? | 14:53 |
| paulsherwood | i fear most of the folks that may know are eastering | 14:53 |
| Kinnison | Last I heard, we had not done an ARMv5 port, but I'd guess it wouldn't be *that* hard and in theory once you had a cross-bootstrap, an armv7lhf environment ought to be able to run an armv5 chroot | 14:54 |
| paulsherwood | you were one of the easterers i was thinking about, Kinnison :) | 14:55 |
| * Kinnison has no chocolate :( | 14:56 | |
| jjardon | Kinnison: ok, so I guess that means "no with current morph"? Or I misunderstand your sentence? | 14:57 |
| Kinnison | I doubt current morph has the architecture strings for it | 14:57 |
| Kinnison | and I doubt we have any build-essential tweaks for it (though I imagine little will be needed beyond the architecture strings in the compilers) | 14:58 |
| paulsherwood | could the arch strings be in definitions somehow? | 14:59 |
| paulsherwood | (in future) | 14:59 |
| Kinnison | There's actually logic behind them -- it might be a tad tough | 14:59 |
| jjardon | Kinnison: ok, thanks for the clarification. Still, can the rootfs be built in armv7lhf or it has to be built natively in a ARMv5 board? | 15:00 |
| Kinnison | It's *possible* you might get away with uilding it on armv7lhf | 15:01 |
| pedroalvarez | that would be good and fast | 15:01 |
| Kinnison | But you might need to tweak morph quite hard | 15:01 |
| pedroalvarez | if using an armv5 chroot inside of armv7 makes things easier, I would do that | 15:02 |
| * pedroalvarez wonders if the same conditions apply for armv6 | 15:02 | |
| * Kinnison would imagine so | 15:02 | |
| Kinnison | It'll be to do with how morph detects its host architecture | 15:02 |
| pedroalvarez | ahh | 15:03 |
| pedroalvarez | jjardon: easy! | 15:03 |
| richard_maw | Also, how every single component detects the architecture to build for. It _ought_ to leave that to the ABI the toolchain is configured to build, but there may be problems | 15:04 |
| jjardon | pedroalvarez: so the idea you are suggesting is: I develop in a ARMv7 board - > create ARMv5 chroot in it -> use morph there to generate the ARMv5 rootfs -> deploy in the ARMv5 board | 15:06 |
| pedroalvarez | but being "create ARMv5 chroot in it" `morph cross-bootstrap` | 15:07 |
| jjardon | pedroalvarez: ah, so morph will create the necessary stuff to generate the ARMv5 rootfs for me? nice | 15:12 |
| pedroalvarez | yup, but you will have to add support in morph/definitions for that architecture | 15:13 |
| jjardon | pedroalvarez: rigth, thanks | 15:14 |
| pedroalvarez | I'd be happy to give you some support, but basically you have to follow this: http://wiki.baserock.org/guides/how-to-cross-bootstrap/ | 15:15 |
| jjardon | Shouldn't be this the "official" way to add baserock support for new boards? Or maybe already is and I miss that documentation? | 15:16 |
| pedroalvarez | note that to generate the armv5 rootfs you can do it from x86 too | 15:16 |
| jjardon | pedroalvarez: nice, thanks! | 15:16 |
| pedroalvarez | jjardon: did my link answer your question? or you asked after seeing the link? | 15:17 |
| jjardon | pedroalvarez: I asked after as this seems a good way to add support to new boards but seems is not explicitly mention anywhere | 15:18 |
| pedroalvarez | well, we call the process of porting to another architecture "cross-bootsrap" | 15:20 |
| jjardon | I mean, seems you can add support for the a new ARM board without the need to have already an ARM board, as you can build the roots in your personal laptop, then deploy. Or am I completely wrong? | 15:23 |
| pedroalvarez | oh, forgot to mention, the rootfs generated will only have stage2 chunks of build essential, and first thing you have to do is to run a script to build stage3 and everything else | 15:26 |
| radiofree | i'm not sure you could build an arm image in a chroot on an x86, which some magic | 15:26 |
| radiofree | maybe using qemu-user-arm or something | 15:26 |
| radiofree | qemu-user-static | 15:27 |
| jjardon | pedroalvarez: seems that point "2. Generate a bootstrap Baserock tarball" in http://wiki.baserock.org/guides/how-to-cross-bootstrap/ ? | 15:29 |
| jjardon | pedroalvarez: but "3. Native building of the cross-bootstrap process" says that I still have to build natively in the target ... | 15:30 |
| pedroalvarez | is exactly what I just tried to explain :) | 15:30 |
| * paulsherwood is constantly surprised that no-one ever resorts to spanish on this channel :) | 15:32 | |
| pedroalvarez | que? | 15:32 |
| paulsherwood | nada | 15:33 |
| pedroalvarez | basederoca | 15:33 |
| paulsherwood | lol | 15:33 |
| jjardon | pedroalvarez: rigth, so, to be clear, Do I have to actually build in the ARMv5 board to do the step 3? "3. Native building of the cross-bootstrap process" ? | 15:34 |
| jonathanmaw | hrm, ambctl also imports gobject. I've added the pygobject chunk that was in strata/virtualization, but 'import gobject' still doesn't work. | 15:35 |
| straycat | that would make it somewhat difficult for non-spanish speakers to contribute to the discussion | 15:36 |
| * SotK doesn't think pygobject provides a "gobject" module | 15:37 | |
| pedroalvarez | jjardon: you can do that in an armv7 board IIUC | 15:37 |
| jjardon | pedroalvarez: ok, then seems the documentation is not complete: "This is the second part of the cross-build process and it has to be done in the target architecture." Maybe we should add a note there? | 15:38 |
| jjardon | jonathanmaw: I think you need the deprecated python bindings for that: pygtk | 15:39 |
| pedroalvarez | jjardon: I agree | 15:39 |
| jonathanmaw | jjardon: ok | 15:43 |
| jonathanmaw | also, hooray for using deprecated code... | 15:43 |
| pedroalvarez | :) | 15:46 |
| jjardon | pedroalvarez: So, any idea what is the rule here? "You can create a x86-32 roots from a x86-64, also a ARMv5/v6/v7 from a ARMv8 board" ? | 15:47 |
| pedroalvarez | s/create/run/ | 15:47 |
| pedroalvarez | jjardon: no idea about what the rule is, if any | 15:48 |
| * jjardon confused | 15:50 | |
| pedroalvarez | hahah why :) | 15:51 |
| jjardon | pedroalvarez: I though you said that it migth be possible to do step "3. Native building of the cross-bootstrap process" for ARMv5 using a ARMv7 board instead | 15:51 |
| pedroalvarez | yes, and that means that you will be running armv5 code in an armv7 board | 15:52 |
| pedroalvarez | I'm not an expert on this field, apologies if I'm saying things with the wrong words | 15:53 |
| jjardon | :) np, I appreciate the help! (I'm sure I'm much less expert than you) | 15:54 |
| jonathanmaw | hrm, pygtk fails to build because it can't handle versions of automake after 1.1 | 15:57 |
| jjardon | 1.1? haha | 16:01 |
| pedroalvarez | jonathanmaw: I think is better if you base your changes in baserock 4 | 16:01 |
| jonathanmaw | ¬_¬ | 16:02 |
| pedroalvarez | :) | 16:02 |
| jjardon | jonathanmaw: simply add automake 1.15 to this list: https://git.gnome.org/browse/pygtk/tree/autogen.sh#n299 | 16:03 |
| jonathanmaw | jjardon: yep | 16:03 |
| *** mdunford has quit IRC | 16:05 | |
| straycat | did someone say newer versionf of gerrit will let you resolve merge commits from the web interface, or did i imagine that? | 16:17 |
| *** jonathanmaw has quit IRC | 16:18 | |
| pedroalvarez | straycat: s/commits/conflicts/? | 16:18 |
| straycat | yes that one | 16:18 |
| * straycat needs a nap | 16:19 | |
| jjardon | should we move this script: http://git.baserock.org/cgi-bin/cgit.cgi/delta/glibc.git/tree/stage2-glibc-fix-specs?h=baserock/glibc-2.20 to the stage2-glibc morphology? | 16:25 |
| *** CTtpollard has quit IRC | 16:25 | |
| ssam2 | jjardon: how? | 16:31 |
| ssam2 | if I remember right, it runs at a different time | 16:32 |
| jjardon | seens it only runs in stage2-glibc: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/build-essential/stage2-glibc.morph#n44 (I only looked in definitions, though) | 16:33 |
| pedroalvarez | it could be in the morphology file, yes | 16:35 |
| * jjardon building | 16:35 | |
| *** Albert__ has quit IRC | 16:35 | |
| ssam2 | ah. I'm sure we removed it for a reason though | 16:41 |
| ssam2 | maybe I'm thinking of something else... | 16:41 |
| ssam2 | jjardon: OH! I was thinking of the stage2-reset-specs chunk | 16:42 |
| pedroalvarez | this file is being called only from stage2-glibc iirc. And it could go to the morpholgy file I think | 16:42 |
| ssam2 | you're right, the stage2-glibc-fix-specs script could be inlined | 16:42 |
| pedroalvarez | I'm stuck at creating an Ansible task to check how many elements of a list match a pattern... | 16:43 |
| pedroalvarez | don't know even if that is possible | 16:43 |
| *** Krin has quit IRC | 16:55 | |
| * pedroalvarez decides to use shell to get that information | 16:55 | |
| *** bashrc_ has quit IRC | 16:58 | |
| straycat | re https://gerrit.baserock.org/#/c/194/1/swift-storage.configure what's the advantage of using arrays there? | 17:01 |
| * straycat seldom writes shell | 17:01 | |
| franred | straycat, it makes things more readable than a massive string | 17:03 |
| straycat | how is it more readable? | 17:04 |
| franred | straycat, I wrote an example for you in the comments | 17:04 |
| straycat | i can see that | 17:04 |
| franred | so? | 17:04 |
| straycat | so i don't see the advantage | 17:04 |
| franred | you can split in lines, you can read every variable separate, when you make a change on it you will see the change in the line and no in a bunch of variables in a line in a string | 17:05 |
| DavePage | Note that =~ is a bash 4ism IIRC | 17:06 |
| franred | DavePage, it is a bash script | 17:06 |
| DavePage | A bash 4 script? :) | 17:06 |
| franred | DavePage, my fast brain.... :/ | 17:07 |
| DavePage | http://mywiki.wooledge.org/BashFAQ/054 anyway | 17:07 |
| straycat | franred, i can put a string on multiple lines too | 17:07 |
| DavePage | I tell a lie, =~ is bash 3 | 17:07 |
| DavePage | http://mywiki.wooledge.org/BashFAQ/061 | 17:08 |
| franred | DavePage, ta! | 17:08 |
| jmacs | Yes, I was just about to say you can do http://pastebin.com/LhUddXMK | 17:08 |
| franred | straycat, ok, then in this case there are not other advantage | 17:10 |
| DavePage | I also don't think that line 32 means what you think it means; franred's use of -z is correct (though I don't think the quoting is necessary in [[ in bash) | 17:11 |
| franred | DavePage, quote is not necessary but I quote variables by default | 17:14 |
| straycat | i think DavePage means that i'm testing for equality with a string 'None' rather than the empty string | 17:14 |
| franred | ohh, I see | 17:15 |
| straycat | yes that confused me too :p | 17:16 |
| straycat | presumably that gets assigned by the yaml parser when the string is empty | 17:16 |
| *** ssam2 has quit IRC | 17:17 | |
| *** edcragg has quit IRC | 17:43 | |
| *** tiagogomes_ has quit IRC | 17:56 | |
| *** rdale has quit IRC | 18:13 | |
| *** mdizzle has quit IRC | 18:15 | |
| *** gary_perkins has quit IRC | 18:20 | |
| *** franred has quit IRC | 20:45 | |
| *** persia_ has quit IRC | 21:35 | |
| *** persia_ has joined #baserock | 21:37 | |
| *** persia_ has joined #baserock | 21:37 | |
| *** persia has quit IRC | 21:38 | |
| *** persia has joined #baserock | 21:39 | |
| *** persia has joined #baserock | 21:39 | |
| *** pacon has joined #baserock | 23:39 | |
| *** pacon has quit IRC | 23:43 | |
| *** pacon has joined #baserock | 23:44 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!