IRC logs for #baserock for Thursday, 2015-04-02

*** rdale has joined #baserock07:09
*** Albert_ has joined #baserock07:18
*** jonathanmaw has joined #baserock07:33
*** sambishop has quit IRC07:41
*** sambishop has joined #baserock07:41
*** bashrc_ has joined #baserock08:03
*** mwilliams_ct has quit IRC08:06
jonathanmawhrm, it looks like the browser-PoC won't work without a dbus connection, I assume on a session bus.08:17
jonathanmawI managed to get it running with a wayland connection (the secret is "-platform wayland"), but now dbus reared its ugly head again.08:17
SotKI had to start dbus to get it to work08:20
* SotK should probably have documented how far he got better08:20
SotKI think I just did "export `dbus-launch`" before running it when I was testing08:23
*** ssam2 has joined #baserock08:25
*** ChanServ sets mode: +v ssam208:25
*** fay_ has quit IRC08:30
SotKI sent new versions of my partial distbuild and partial build test changes to Gerrit to get round the weird Merge conflict issue08:30
SotKthey now need code review votes again though :(08:30
ssam2thanks, I've submitted them now08:33
ssam2I think the 'rebase' button in the UI might have been enough08:33
ssam2although that also means the patch needs votes again08:33
radiofreejonathanmaw: you can do dbus-launch --sh-syntax > /tmp/dbus-session08:35
*** fay_ has joined #baserock08:35
radiofreeThen source /tmp/dbus-session whenever you need to use a session bus08:35
*** tiagogomes_ has joined #baserock08:36
radiofreeAlso probably a good idea to set QT_QPA_PLATFORM to wayland-egl08:38
*** fay_ has quit IRC08:42
*** mdizzle has joined #baserock08:46
*** franred has joined #baserock08:47
*** fay_ has joined #baserock08:49
jonathanmawHow do I make a baserock VM provide /dev/fb0?08:50
jonathanmawit seems my kernel command-line is missing vga=<thing>08:51
radiofreeLook in the logs from last night08:54
radiofreeThere's a discussion on how to add it08:54
radiofreeAround 10pm08:54
jjardonssam2:  the /etc/profile part is done in the next patch of the same topic08:58
*** gary_perkins has joined #baserock08:59
jjardonBTW, if you put the bash-completion patch on top you will have auto completion enable by default when using bash09:00
*** gary_perkins has quit IRC09:00
*** gary_perkins has joined #baserock09:00
jonathanmawis there a way to read the irc logs? I wasn't on this channel at 10PM last night.09:04
*** edcragg has joined #baserock09:04
ssam2jjardon: 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 thing09:05
ssam2jjardon:  I missed part 2 of the patch09:05
ssam2it's a bit weird that we set up /etc/profile in the busybox chunk09:06
jjardonYeah, I plan to change that09:06
jjardonIt should be done in our fhs-dirs09:07
ssam2yeah that would make more sense09:07
rdaleas long as it isn't shell specific09:07
ssam2jjardon: might be nice to have it done in a configure extension instead, because it doesn't need to be present at build time09:07
ssam2if it's in fhs-dirs then every change to /etc/profile triggers a rebuild of everything09:08
paulsherwoodwe have two fhs-dirs already, why not have another one :)09:13
paulsherwoodstage3-fhs-dirs, fhs-dirs for example?09:13
paulsherwoodthen fhs dirs could be done *last* maybe?09:13
jonathanmawhrm, the browser PoC is running without spewing errors, but I don't see anything other than console logging :¬|09:14
* paulsherwood may be missing something09:14
ssam2paulsherwood: that might work, it's hard to express in definitions 'build this last' right now though09:14
SotKjonathanmaw: how did you run it?09:14
ssam2paulsherwood: we could have fhs-dirs in its own strata, then we have yet another stratum to add to systems09:14
ssam2paulsherwood: but seems a good simple solution09:15
paulsherwoodssam2: no it's not? stick it in its own stratum, and make that depend on stuffs? or stick iit in bsp09:15
jonathanmawSotK, inside weston, with /usr/lib/browser-poc/browser/bin/browser09:15
paulsherwood(bsp already gets built approximately last iiuc)09:15
*** Krin has joined #baserock09:15
ssam2paulsherwood: a system has to list every stratum it wants to contain, build-dependencies don't affect system contents09:15
jonathanmawwith a running session bus, and QT_QPA_PLATFORM=wayland-egl09:16
SotKjonathanmaw: aha, you also need to run the demoui to actually see anything IIRC09:16
ssam2paulsherwood: putting it in BSP seems weird, but BSP is a weird name anyway :)09:16
paulsherwoodssam2: 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 believe09:16
paulsherwood(but this might have other side-effects)09:17
SotKFSVO last, unless anything depends on the bsp stratum I think09:17
persiaIsn't fhs-dirs a build-dependency for some things?09:17
SotKpaulsherwood: for some value of09:18
paulsherwoodpersia: yes, hence i'm suggesting having stage3-fhs-dirs to achieve what the current fhs-dirs does09:18
persiapaulsherwood: 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
SotKIt 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 stratum09:18
paulsherwoodpersia: what SotK said09:19
ssam2has anyone done a build of a459c78d170f5c8bc469229425e036f4c3302e95 of definitions on ARM ? I'm getting a build failure with stage2-glibc09:19
ssam2configure: error: cannot compute suffix of object files: cannot compile09:19
SotKpersia: only two strata depend on the BSP at the moment, virtualization and virtualbox-guest-x86_6409:19
paulsherwoodmissing build-dependency, ssam2 i think.09:20
persiaSotK: Right, but if I build xgalaga, there's a decent chance that the BSP builds before this (but it doesn't matter).09:20
ssam2weird, did we remove one?09:20
SotKin fact, maybe virtualization doesn't09:20
persiaVB guest should need to know the kernel to make the right modules.09:21
paulsherwoodssam2: i don't believe so, but could you check whether that build-essential has the same build-deps explicit as in master?09:21
ssam2this is master09:21
ssam2could be some weird fs corruption on this Jetson09:21
ssam2btrfs has been acting up on it alreayd09:22
paulsherwoododd, then. i built past that this morning on x86 with ybd09:22
paulsherwoodfor that sha1209:22
ssam2x86 is fine, is green09:22
paulsherwoodssam2: ok so yes corruption is one possibility09:23
paulsherwoodmaybe blow your artifats away?09:23
ssam2I don't see anything in master that suggests 'break bootstrap on ARM', so I guess so09:23
ssam2yeah, maybe my cache is corrupt.09:23
ssam2which reminds me, need to investigate how OSTree handles cache corruption. Hopefully it detects such things!09:23
* paulsherwood intends to use MD5 for ybd09:24
ssam2seems OSTree has a 'fsck' command :)09:29
jjardonpaulsherwood: I'd go for sha256 instead09:29
ssam2since it is content-addressed, like Git, detecting corruption is probably easy09:29
ssam2(in OStree)09:29
richard_mawpaulsherwood: 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 up09:29
richard_mawpaulsherwood: 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 them09:30
richard_mawpaulsherwood: 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 busybox09:31
richard_mawpaulsherwood: 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 run09:32
jjardonrichard_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
paulsherwoodrichard_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
paulsherwoodjjardon: agreed, you're right09:39
persiajjardon: When introducing os_release, please be sure to use "reference" or similar to indicate that the result is not usefully branded "Baserock".09:42
jjardonI 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_mawjjardon: yeah, the install-files extension09:42
jjardonpersia: our reference system will all be branded Baserock09:42
persiaPlease no.  Please brand "Baserock reference" or similar.09:42
jjardonpersia: lets talk about that when we get there09:43
persiaThere 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_mawjjardon: for /etc/profile and /etc/os-release, dropping install-files in may be appropriate, /etc/passwd is more complicated though09:43
persiaWhen Baserock itself only provides tooling to define, build, and deploy systems.09:43
jjardonpersia: FYI, rigth now _any_ system builded with morph will be "Baserock"09:43
paulsherwoodssam2: 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
paulsherwoods/builded/built/ jjardon :)09:43
persiaAh.  I consider that a serious bug, and understand the confusion I just described in more detail.  Thanks for the explanation.09:44
jjardonrichard_maw: problem is that we have to check that /etc/passwd, /etc/shadow and groups are in sync09:45
jjardonpaulsherwood: thanks :)09:46
richard_mawjjardon: 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 modules09:46
richard_mawjjardon: it's for this reason that systemd has added the sysusers stuff09:47
richard_mawjjardon: but we haven't had time to evaluate whether sysusers is suitable for our needs09:47
jjardonok, I will submit tasks to storyboard so all this doesnt get lost09:47
SotKpaulsherwood: 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
richard_mawSotK: that sounds about right, given it ought to cut out a redundant copy09:50
richard_mawand a lot of building is IO bound09:51
richard_mawbut I think it's the reworking of system artifact creation in particular that's cutting the time down there09:51
* richard_maw missed that you were talking about deploying only09:51
jjardonSotK: amazing, does the ostree community know we are using it in baserock?09:52
SotKjjardon: I don't think so yet09:53
ssam2paulsherwood: not yet09:53
ssam2I'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 branch09:53
SotKrichard_maw: yeah, `ostree checkout` is much quicker than unpacking a tarball09:53
paulsherwoodssam2: how hard is it to set this up on x86?09:54
paulsherwoodare we using ostree? is it actually merged to master now?09:54
SotKnot yet09:55
paulsherwoodjjardon: please hold, then :-)09:55
ssam2paulsherwood: not too hard, you need a branched definitions, and a branched morph09:55
paulsherwoodand a system with ostree, surely?09:56
ssam2that's what I meant by 'branched definitions'09:56
paulsherwoodi mean to run the build on09:56
ssam2your build system needs to be built from adam's branch with ostree09:56
ssam2it can build current master of definitions09:56
paulsherwoodso i would need to update to a system containing ostree, and then run the test there09:57
ssam2the current Morph branch has some bugs that make things much slower than they should be, so best to wait for the v2 branch09:57
richard_mawpaulsherwood: 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 everything09:57
ssam2I think SotK has about 3 different tasks in progress right now :)09:57
paulsherwoodrichard_maw: understood. i'm very happy to see this work being done, and i appreciate it's a significant change09:57
* SotK will push his WIP v2 branch if that would be useful09:58
jjardonssam2: 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 fixes09:58
ssam2cool, will look later (I have a call now)09:59
richard_mawSotK: 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 it10:00
*** Albert__ has joined #baserock10:01
*** Albert_ has quit IRC10:01
edcragghas anyone seen problems building erlang for BE vs. LE?
edcraggLE builds fine10:03
radiofreeis erlang on a build-system?10:06
edcraggno, this is the openstack-server system10:07
radiofreeah, then i have no idea, didn't have problems building a BE build-system at least10:07
SotKsplitting 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
edcraggseems the built erlang compiler segfaults10:11
jjardonrichard_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
jjardonmaybe 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 definition10:13
rjeki/win 2510:14
rdalethere seem to be two hosts involved in the baserock org infrastructure - and the url for the definitions.git repo is on the host. i wonder how does 'trove-host' seem to refer to both?10:25
richard_mawjjardon: this is why I wanted chunks to provide a default configuration file for the networking, but have it be overridden by configuration extensions10:32
richard_mawjjardon: that, or a way to have configuration extensions be triggered by a chunk's inclusion10:32
gary_perkinsrdale: trove.b.o and git.b.o are the same thing. I got confused about it too a while ago10:33
rdaleoh ok10:33
ssam2SotK: I can usefully review V2 :)10:33
richard_mawjjardon: fortunately you can overwrite a file with install-files, and you can use multiple manifests10:33
ssam2when its ready10:33
SotKssam2: great, thanks :)10:33
ssam2jjardon: I hate the install-files extension with a passion10:34
ssam2but maybe it is the best interim solution for /etc/profile etc.10:34
straycatit could certainly be improved10: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
ssam2I 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 anyway10:35
jjardonssam2: 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
ssam2jjardon: 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-dirs10:37
ssam2jjardon: maybe 'base' ?10:38
pedroalvarezedcragg: no clue about that problem building erlang in BE10:38
ssam2'base' is as overloaded as 'generic' I guess10:38
ssam2base-files/ or essential-files/ or somthing10:39
ssam2and why system/profile instead of etc/profile ?10:39
jjardonsystem/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 time10:41
jjardonok, what about: essential-files/generic/manifest , then we can move the different manifest to the essential-files directory: essential-files/distbuild, essential-files/moonshot ... etc10:42
richard_mawI'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 it10:43
* richard_maw said the above with far more certainty than there actually exists for thing being the best solution10:45
richard_mawthe problem is that we want to avoid unnecessary dependencies and want the config to be included by default in some form10:45
richard_mawand we'd like to avoid creating strata just for config files, as we'd just forget them10:46
ssam2jjardon: 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
ssam2seems confusing to call it system/profile when it gets installed as etc/profile10:46
ssam2I was thinking keep distbuild/ (maybe rename it to distbuild-files), add a new essential-files/ with essential-files/etc/profile etc.10:46
ssam2richard_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 system10:48
ssam2richard_maw: I agree we'll need a more clever solution for some files (/etc/passwd for example)10:48
jjardonthe reason for grouping is because rigth now we already have chef/manifest, distbuild/manifest and moonshot/manifest. This will add another essential-files/manifest10:48
ssam2s/post-deploy/at deploy time/10:48
ssam2jjardon: let's not muddle two problems together, though10:49
ssam2jjardon: creating a toplevel files/ directory to hold files/distbuild/, files/chef/ files/essential etc. sounds like quite a good idea10:50
ssam2but I think it should be proposed separately to this10:50
jjardonyep, agree10:50
* jjardon seems to have on a infinite loop of things to fix underneath when he tries to fix something :)10:51
jjardonok, 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
ssam2I would +1 that10:56
* SotK too10:56
ssam2especially if a patch to remove /etc/profile from fhs-dirs was promised as well :)10:56
pedroalvarezwas the idea of adding a configure exts for this dropped?10:57
ssam2I'd rather see install-files.configure become easier to use, personally10:57
pedroalvarezso nobody can avoid the creation of this file (muahah)10:57
ssam2there is that ...10:57
ssam2but I think what Javier proposes is still an improvement, so I'd still +1 it10:58
straycatwe'd need to make INSTALL_FILES a mandatory key in cluster morphs to avoid mistakes10:58
ssam2I think writing clusters is hard enough that you have to copy an existing one already10:58
* straycat doesn't10:59
jjardonssam2: done, /etc/profile is not in fhs-dirs already :)10:59
straycatI write the simple ones10:59
straycatthat's also not a terribly good reason for making the ui worse than it already is10:59
straycati'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 stage11:00
straycatand i kinda thing a conf ext might be better for this11:00
ssam2maybe an easy middle ground is create a new configure extension that just chains to 'install-files essential-files/MANIFEST'11:00
straycatyes i think that would be better11:02
bashrc_is there any documentation on "morph branch"? I may be misunderstanding what it's doing11:02
straycatbashrc_, besides morph help branch, i'm not sure11:03
SotKbashrc_: I don't know if there is anything beyond `morph branch --help`11:03
SotKbashrc_: what's the misunderstanding?11:03
bashrc_I was thinking that it creates a new branch11:05
bashrc_but actually in my tests I don't think it does. It looks like it just uses an existing branch11:05
SotKthat's weird, it should create a new branch11:06
ssam2it creates a new 'morph system branch', which isn't the same as a Git branch11:07
ssam2I think it does create a new Git branch in the local clone of definitions it creates, too11:07
bashrc_I think morph branch probably is doing what I originally thought, but that there's a bug which causes different behaviour11:07
gary_perkinsdoes "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 upstream11:07
straycatgary_perkins, nahh it defaults to nothing11:08
gary_perkinsstraycat: Cool thanks :)11:08
straycatkinda handy if you just want a gitano box for your own stuff :)11:09
jjardonssam2: 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
*** mdunford has quit IRC11:48
*** ssam2 has quit IRC12:33
*** mdunford has joined #baserock12:40
*** ssam2 has joined #baserock12:48
*** ChanServ sets mode: +v ssam212:48
*** ssam2 has quit IRC13:03
*** ssam2 has joined #baserock13:15
*** ChanServ sets mode: +v ssam213:15
*** mdunford has quit IRC13:19
*** mdunford has joined #baserock13:34
pedroalvarezI wonder how can a boot a system that doesn't run networkd13:44
pedroalvarezI mean, I'd like to investigate the status of the system before it networkd starts13:45
richard_mawpedroalvarez: you can change the default target with systemctl, or on the kernel command line13:47
richard_mawpedroalvarez: I had to look at stuff pre-networkd too, and found that setting the default target to worked13:47
pedroalvarezrichard_maw: will try that! thanks13:47
pedroalvarezindeed, that workd13:56
*** sambishop has quit IRC14:04
jjardontiagogomes_: 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
straycatpedroalvarez, git-review does make that easier thanks pedroalvarez14:08
pedroalvarezgood, it's already in devtools :)14:08
jjardontiagogomes_: yes, in 2013:
jjardonI ask because seems to overlap with what we discuss before14:09
tiagogomes_jjardon I think that was superseded by install-files, which hopefully will be superseded by something else14:10
pedroalvarezbashrc_: see
tiagogomes_that's centuries ago for baserock14:10
pedroalvarezbashrc_: why would you need push access?14:11
*** sambishop has joined #baserock14:15
jjardonssam2: is it ok to reuse add-config-files or should I create a new one?14:22
gary_perkinsPerhaps 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
pedroalvarezgary_perkins: have you removed the previous entry for /home in /etc/fstab?14:23
pedroalvarezalso, define "doesn't work smoothly"14:24
pedroalvarezI would expect that things in /home are regenerated if you re-run the trove-setup systemd unit14:24
gary_perkinsI followed the "nova bott" command from the docs, but it doesn't attach /dev/vdb. But I did that anyway.14:27
gary_perkinsSo I think, the procedure should just be nova boot with attached /dev/vdb, then manually run the trove-setup script?14:28
gary_perkinsor have it run trove-setup twice? At instance creation and manually once it's completed booting?14:30
jonathanmawhrm, 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
jonathanmawhow do I make sure dbus is in python?14:31
radiofree ?14:31
jonathanmawooh, pydbus14:32
radiofreeactually probably not that14:32
radiofreedbus-python i think14:32
jjardonI think the prefered way nowadays is to use the python GDBus bindings14:33
bashrc_pedroalvare: I was going to create a baserock/bmottram/firehose branch which matches the current readme14:34
jjardonnevermind, do not think thats actually true14:34
radiofreejjardon: cool, fancy porting over a genivi component to use them?14:34
ssam2jjardon: what is add-config-files ?14:41
jjardonI mean reuse the name, as seems is was done for exactly the same what we want to achieve here14:42
ssam2I think install-essential-files would be a better name14:43
ssam2I don't we should have one extension use 'add' and another extension say 'install' to mean the same thing14:43
ssam2*I don't think14:44
jjardondoes baserock support ARMv5? is it possible with current morph to bringup a Baserock-built linux on an ARMv5 system?14:52
paulsherwoodgood question.... richard_maw ?14:53
paulsherwoodi fear most of the folks that may know are eastering14:53
KinnisonLast 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 chroot14:54
paulsherwoodyou were one of the easterers i was thinking about, Kinnison :)14:55
* Kinnison has no chocolate :(14:56
jjardonKinnison: ok, so I guess that means "no with current morph"? Or I misunderstand your sentence?14:57
KinnisonI doubt current morph has the architecture strings for it14:57
Kinnisonand 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
paulsherwoodcould the arch strings be in definitions somehow?14:59
paulsherwood(in future)14:59
KinnisonThere's actually logic behind them -- it might be a tad tough14:59
jjardonKinnison: 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
KinnisonIt's *possible* you might get away with uilding it on armv7lhf15:01
pedroalvarezthat would be good and fast15:01
KinnisonBut you might need to tweak morph quite hard15:01
pedroalvarezif using an armv5 chroot inside of armv7 makes things easier, I would do that15:02
* pedroalvarez wonders if the same conditions apply for armv615:02
* Kinnison would imagine so15:02
KinnisonIt'll be to do with how morph detects its host architecture15:02
pedroalvarezjjardon: easy!15:03
richard_mawAlso, 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 problems15:04
jjardonpedroalvarez: 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 board15:06
pedroalvarezbut being "create ARMv5 chroot in it"  `morph cross-bootstrap`15:07
jjardonpedroalvarez: ah, so morph will create the necessary stuff to generate the ARMv5 rootfs for me? nice15:12
pedroalvarezyup, but you will have to add support in morph/definitions for that architecture15:13
jjardonpedroalvarez: rigth, thanks15:14
pedroalvarezI'd be happy to give you some support, but basically you have to follow this:
jjardonShouldn't be this the "official" way to add baserock support for new boards? Or maybe already is and I miss that documentation?15:16
pedroalvareznote that to generate the armv5 rootfs you can do it from x86 too15:16
jjardonpedroalvarez: nice, thanks!15:16
pedroalvarezjjardon: did my link answer your question? or you asked after seeing the link?15:17
jjardonpedroalvarez: I asked after as this seems a good way to add support to new boards but seems is not explicitly mention anywhere15:18
pedroalvarezwell, we call the process of porting to another architecture "cross-bootsrap"15:20
jjardonI 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
pedroalvarezoh, 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 else15:26
radiofreei'm not sure you could build an arm image in a chroot on an x86, which some magic15:26
radiofreemaybe using qemu-user-arm or something15:26
jjardonpedroalvarez: seems that point "2. Generate a bootstrap Baserock tarball" in ?15:29
jjardonpedroalvarez: but "3. Native building of the cross-bootstrap process" says that I still have to build natively in the target ...15:30
pedroalvarezis 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
jjardonpedroalvarez: 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
jonathanmawhrm, ambctl also imports gobject. I've added the pygobject chunk that was in strata/virtualization, but 'import gobject' still doesn't work.15:35
straycatthat would make it somewhat difficult for non-spanish speakers to contribute to the discussion15:36
* SotK doesn't think pygobject provides a "gobject" module15:37
pedroalvarezjjardon: you can do that in an armv7 board IIUC15:37
jjardonpedroalvarez: 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
jjardonjonathanmaw: I think you need the deprecated python bindings for that: pygtk15:39
pedroalvarezjjardon: I agree15:39
jonathanmawjjardon: ok15:43
jonathanmawalso, hooray for using deprecated code...15:43
jjardonpedroalvarez: 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
pedroalvarezjjardon: no idea about what the rule is, if any15:48
* jjardon confused15:50
pedroalvarezhahah why :)15:51
jjardonpedroalvarez: 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 instead15:51
pedroalvarezyes, and that means that you will be running armv5 code in an armv7 board15:52
pedroalvarezI'm not an expert on this field, apologies if I'm saying things with the wrong words15:53
jjardon:) np, I appreciate the help! (I'm sure I'm much less expert than you)15:54
jonathanmawhrm, pygtk fails to build because it can't handle versions of automake after 1.115:57
jjardon1.1? haha16:01
pedroalvarezjonathanmaw: I think is better if you base your changes in baserock 416:01
jjardonjonathanmaw: simply add automake 1.15 to this list:
jonathanmawjjardon: yep16:03
*** mdunford has quit IRC16:05
straycatdid 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 IRC16:18
pedroalvarezstraycat: s/commits/conflicts/?16:18
straycatyes that one16:18
* straycat needs a nap16:19
jjardonshould we move this script: to the stage2-glibc morphology?16:25
*** CTtpollard has quit IRC16:25
ssam2jjardon: how?16:31
ssam2if I remember right, it runs at a different time16:32
jjardonseens it only runs in stage2-glibc: (I only looked in definitions, though)16:33
pedroalvarezit could be in the morphology file, yes16:35
* jjardon building16:35
*** Albert__ has quit IRC16:35
ssam2ah. I'm sure we removed it for a reason though16:41
ssam2maybe I'm thinking of something else...16:41
ssam2jjardon: OH! I was thinking of the stage2-reset-specs chunk16:42
pedroalvarezthis file is being called only from stage2-glibc iirc. And it could go to the morpholgy file I think16:42
ssam2you're right, the stage2-glibc-fix-specs script could be inlined16:42
pedroalvarezI'm stuck at creating an Ansible task to check how many elements of a list match a pattern...16:43
pedroalvarezdon't know even if that is possible16:43
*** Krin has quit IRC16:55
* pedroalvarez decides to use shell to get that information16:55
*** bashrc_ has quit IRC16:58
straycatre what's the advantage of using arrays there?17:01
* straycat seldom writes shell17:01
franredstraycat, it makes things more readable than a massive string17:03
straycathow is it more readable?17:04
franredstraycat, I wrote an example for you in the comments17:04
straycati can see that17:04
straycatso i don't see the advantage17:04
franredyou 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 string17:05
DavePageNote that =~ is a bash 4ism IIRC17:06
franredDavePage, it is a bash script17:06
DavePageA bash 4 script? :)17:06
franredDavePage, my fast brain.... :/17:07
DavePage anyway17:07
straycatfranred, i can put a string on multiple lines too17:07
DavePageI tell a lie, =~ is bash 317:07
franredDavePage, ta!17:08
jmacsYes, I was just about to say you can do
franredstraycat, ok, then in this case there are not other advantage17:10
DavePageI 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
franredDavePage, quote is not necessary but I quote variables by default17:14
straycati think DavePage means that i'm testing for equality with a string 'None' rather than the empty string17:14
franredohh, I see17:15
straycatyes that confused me too :p17:16
straycatpresumably that gets assigned by the yaml parser when the string is empty17:16
*** ssam2 has quit IRC17:17
*** edcragg has quit IRC17:43
*** tiagogomes_ has quit IRC17:56
*** rdale has quit IRC18:13
*** mdizzle has quit IRC18:15
*** gary_perkins has quit IRC18:20
*** franred has quit IRC20:45
*** persia_ has quit IRC21:35
*** persia_ has joined #baserock21:37
*** persia_ has joined #baserock21:37
*** persia has quit IRC21:38
*** persia has joined #baserock21:39
*** persia has joined #baserock21:39
*** pacon has joined #baserock23:39
*** pacon has quit IRC23:43
*** pacon has joined #baserock23:44

Generated by 2.15.3 by Marius Gedminas - find it at!