| *** fay [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 07:02 | |
| fay is now known as Guest11719 | 07:02 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 07:12 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Remote host closed the connection] | 07:59 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:00 | |
| *** flatmush [~flatmush@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 240 seconds] | 08:26 | |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:29 | |
| *** flatmush [~flatmush@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:29 | |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:53 | |
| liw-orc | pedroalvarez, there's potentially a lot to configure in a Trove -- would it make sense to be able to provide all of lorry-controller.conf instead of breaking it into many small variables? | 09:42 |
|---|---|---|
| persia | That makes more sense to me: reduced comprehension overhead for the user. | 09:42 |
| *** Guest11719 [~fay@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 09:45 | |
| *** fay [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:45 | |
| pedroalvarez | liw-orc: no sur about how to implement your suggestion | 09:45 |
| *** fay [~fay@82-68-191-81.dsl.posilan.com] has quit [Client Quit] | 09:45 | |
| *** Guest76659 [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:45 | |
| *** Guest76659 [~fay@82-68-191-81.dsl.posilan.com] has quit [Client Quit] | 09:45 | |
| liw-orc | pedroalvarez, I'd sugest something like TROVE_LORRY_CONTROLLER_CONFIG=path/to/lorry-controller.conf | 09:45 |
| liw-orc | and if that's not given, use a default file instead | 09:46 |
| liw-orc | (a default that uses http to mirror git.baserock.org, to avoid having to set up ssh keys and things; alternatively, a default that doesn't mirror anything) | 09:47 |
| pedroalvarez | that change will make more complicated the things I've made simple :/ | 09:50 |
| * pedroalvarez ponders adding a cloud-devel system to the release cluster | 10:52 | |
| pedroalvarez | cloud= wih initramfs and cloud-init enabled | 10:53 |
| persia | Maybe a trove? | 10:56 |
| richard_maw | hmm, I'm tempted to suggest we make the normal systems cloud compatible | 10:56 |
| persia | cloud-init being configured can ease getting it started in libvirt environments also | 10:56 |
| persia | richard_maw: The problem with enabling cloud-init by default is that it does odd things for folk not working in virtual or highly-networked environments. | 10:57 |
| pedroalvarez | indeed | 10:57 |
| richard_maw | and the initramfs means you don't need to hunt for the OS type without a virtio rootfs when importing a VM into virt-manager | 10:57 |
| ssam2 | pedroalvarez: would that not be a cluster morph rather than a system ? | 10:58 |
| pedroalvarez | agree with using initramfs in all of them | 10:58 |
| pedroalvarez | ssam2: yes, I meant, add an entry in the release cluster morph | 10:58 |
| ssam2 | pedroalvarez: ah, OK. Certainly it's worth adding an example, I think | 10:58 |
| ssam2 | i.e. something we could easily paste into release.morph if we wanted to at a later date | 10:59 |
| * pedroalvarez nods | 11:00 | |
| pedroalvarez | persia: yes, I also want to add the trove to the cluster :) | 11:01 |
| persia | richard_maw: Using an initramfs by default seems sensible that change needn't get stuck in the cloud-init discussions. | 11:01 |
| persia | pedroalvarez: So add a cloud-trove to the release set. It's independent from the others, so not likely to cause issues, and it makes it easy for folk to try a local trove, without lots of fussy setup. | 11:02 |
| persia | (plus having a trove in the release set makes it easier to test if a given change in definitions causes behaviour changes for the associated trove). | 11:03 |
| pedroalvarez | this is my proposal: http://pastebin.com/uUcq3sSE | 11:21 |
| persia | pedroalvarez: I thought you had proposed putting something in release.morph | 11:42 |
| pedroalvarez | since I don't know the consecuences of adding things in the release.morph, I decided to add them in an example for now | 11:43 |
| persia | I think you're running into the same duplication trap as the potential for creating the cloud-specific devel system. | 12:03 |
| persia | If you're uncertain, ask for someone who does releases to give an opinion here, or if none are about, ask on the mailing list. | 12:04 |
| persia | If there is any negative impact from adding directly to release.morph, this will be discussed in review, and then it can be split out. | 12:04 |
| persia | If you split it out, the review goes quickly, but then we have to do it all over again with a new review of a patch series to add to release. | 12:04 |
| ssam2 | I disagree. The second review would be super quick, if it simply involves moving a definition that already exists and has been used into a different cluster morph | 12:06 |
| ssam2 | The first review would also be super quick, since it can't possibly break anything that exists | 12:07 |
| ssam2 | I don't know if patch review is the best way to discuss what we should release | 12:07 |
| ssam2 | it might be, I guess | 12:07 |
| persia | Easier to discuss a concrete patch than some vague commentary (all of my email aside) | 12:12 |
| pedroalvarez | then I'm going to send a patch for what I really want to happen | 12:22 |
| persia | That's usually the best plan :) | 12:27 |
| *** fay [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 12:28 | |
| *** fay [~fay@82-68-191-81.dsl.posilan.com] has quit [Client Quit] | 12:28 | |
| pedroalvarez | I found a problem with baserock and volumes creation in openstack. I need to reboot the system to mount a volume :/ | 13:40 |
| pedroalvarez | can be solved with CONFIG_HOTPLUG? | 13:41 |
| pedroalvarez | (kernel) | 13:41 |
| pedroalvarez | or it's something more complicated? | 13:42 |
| richard_maw | pedroalvarez: to mount the volume? | 13:58 |
| richard_maw | so, newly added hardware in OpenStack isn't showing up immediately, or it's not auto-mounting? | 13:59 |
| pedroalvarez | richard_maw: the fomrer | 13:59 |
| pedroalvarez | s/fomer/former/ | 13:59 |
| richard_maw | pedroalvarez: hm, I'm not sure what normal behaviour for this is, since I could add a USB attached storage to a local VM, but virtio didn't show up the first time I tried it, and the second time it failed to attach | 14:05 |
| persia | Does it work in cirros? | 14:07 |
| pedroalvarez | persia: yes | 14:07 |
| persia | Hmm. Complicated. | 14:08 |
| persia | And with Baserock, nothing in the system log? | 14:08 |
| pedroalvarez | nope :/ | 14:13 |
| liw-orc | I suspect that pedroalvarez's analysis is correct and that our kernel doesn't notice new (virtual) hard disks via virtio or SATA, after boot, but that is just a guess | 14:14 |
| doffm | I'm having trouble building trove-system-x86: | 14:17 |
| doffm | ERROR: Failed to update cached version of repo git://git.baserock.org/delta/luxio | 14:17 |
| Kinnison | Interesting. Can you get some more log details and pastebin them? | 14:18 |
| * pedroalvarez waits the log, and assumes is not a prblem with the trove itself | 14:19 | |
| liw-orc | also, details of the host (which release of Baserock and which version of morph?) | 14:19 |
| persia | It's more complicated than CONFIG_HOTPLUG though: that seems not to even exist anymore. | 14:24 |
| jjardon | I think this would be on interest here (just made the GNOME/Wayland smoke test succeeded all the way to taking a screenshot of the session) http://blogs.gnome.org/mclasen/2014/07/23/continuous-testing-and-wayland/ | 14:30 |
| liw-orc | jjardon, nice | 14:32 |
| jjardon | current image here if someone fancy a try ;) http://build.gnome.org/continuous/buildmaster/images/z/current/ | 14:32 |
| pedroalvarez | jjardon: using baserock? :) | 14:35 |
| jjardon | pedroalvarez: nope (yet ;)) the current instance of build.gnome.org uses ostree | 14:37 |
| rjek | Sadface: http://pastebin.com/zdGdRsV2 | 14:39 |
| rjek | (During stage 3 native) | 14:39 |
| * rjek wonders why it doesn't work now. | 14:40 | |
| pedroalvarez | See `config.log' for more details. | 14:40 |
| pedroalvarez | anything there? | 14:41 |
| rjek | There are dozens of config.logs; just looking through them | 14:42 |
| rjek | (not helped that the environment's 'less' appears to be cat) | 14:42 |
| persia | rjek: You want /gcc.inst/gcc.build/o/config.log | 14:43 |
| pedroalvarez | Could be the -j2? | 14:43 |
| rjek | persia: It worked fine with the -j2 before. | 14:43 |
| liw-orc | rjek, that sounds like busybox's less, alas | 14:43 |
| rjek | The only real difference here is that this is gcc 4.7 not 4.6. | 14:43 |
| rjek | (I imagine) | 14:43 |
| Kinnison | rjek: I'd start by dropping back to not -j2 for gcc just in case | 14:46 |
| rjek | We'll have to wait until tomorrow, then. | 14:54 |
| robtaylor | rjek: can you paste the config.log persia metnioned? | 14:54 |
| rjek | Not easily, no. | 14:55 |
| robtaylor | boh :( | 14:56 |
| rjek | And when I tailed that one, it looked like it existed with success | 14:56 |
| persia | clearly pastebinit or equivalent should be part of the devel system | 14:56 |
| persia | Yes, it seems to have configured sucessfully, but incorrectly. | 14:56 |
| Kinnison | rjek: unfortunately the bit you really need in config.log is usually nowhere near the end of it :-( | 14:57 |
| Kinnison | rjek: If you're currently mid-bootstrap it's possible the only tool to get content off your device usefully might be the busybox built-in nc | 14:57 |
| Kinnison | rjek: if you check for .../o/libgcc/config.log and there is one, that might be the one we need | 14:58 |
| * Kinnison really hates that the toolchain parts (binutils, gcc, glibc) seem to be stuffed full of configures run at build time | 14:59 | |
| rjek | xgcc: internal compiler error: Segmentation fault (program cc1) | 15:02 |
| rjek | Kinnison: Quick chat with robtaylor, I mentioned I would now like different architectures to have different compilers. We can't do this, because there's only one build-essential.morph. He says this is a good argument for manifests. | 15:06 |
| rjek | I'm abandoning hope on this again for the day. It is too late to be going down that particular rabit hole. | 15:06 |
| pedroalvarez | Added a "Instantiate a generic Trove" section on the wiki! http://wiki.baserock.org/guides/deploying-a-trove/#index3h1 | 15:07 |
| Kinnison | rjek: my understanding of manifests wouldn't solve that. I wanted conditionals in strata, so I could say "repo foo sha bar for arch baz, everything else, sha wibble" | 15:08 |
| Kinnison | rjek: but that's a whole n'other kettle of flesh eating worms | 15:09 |
| * rjek thinks it's pretty important to be able to control what GCC gets used to build things. | 15:10 | |
| rjek | As basically only x86 is guarenteed to work in any given release, IME. | 15:11 |
| rjek | I'm now basically at a complete loss for what to do apart from revert the gcc 4.7 upgrade. | 15:11 |
| robtaylor | rjek: rpobably best thing is to find out what's making it blow up | 15:12 |
| rjek | robtaylor: I have no gdb or anything. | 15:12 |
| * robtaylor is suddenly reminded of star trekkin | 15:12 | |
| jjardon | rjek: try to upgrade to 4.8? | 15:12 |
| robtaylor | rjek: gah! | 15:12 |
| rjek | jjardon: Not sure if trolling or not. | 15:13 |
| rjek | gcc 4.8 will be a world of pain because it requires a C++ compiler to bootstrap. | 15:13 |
| rjek | IIRC | 15:13 |
| robtaylor | rjek: do you have a working 4.6 based devel system? | 15:13 |
| rjek | robtaylor: nope. | 15:13 |
| robtaylor | rjek: as it 'not at this time' or 'its not possible to have one' ? | 15:14 |
| jjardon | rjek: not trolling :) I think that was for 4.9? | 15:14 |
| rjek | robtaylor: I had a completed 4.6-based stage 3 bootstrap which then couldn't build anything for MIPS because it used upstream morph rather than my patched version, which is how all this started... | 15:14 |
| robtaylor | rjek: i say, make a branch which builds a working system | 15:14 |
| rjek | (the pushing of needed changes to git.br.org, and discovering gcc had moved on) | 15:14 |
| robtaylor | rjek: then use that to debug why your stage 3 doesnt work with 4.7 | 15:15 |
| rjek | I can of course just try that successful stage 3 build with a locally-patched morph rather than the one in my branch. | 15:15 |
| robtaylor | yep | 15:15 |
| * rjek is not sure if that might cause provenence problems. | 15:15 | |
| jjardon | rjek: you are rigth, 4.8 need a c++ compiler, nevermind | 15:16 |
| Kinnison | rjek: It'd be good enough to get us going, but overall it still hilights that we have the 4.6 vs. 4.7 discrepancy | 15:16 |
| robtaylor | rjek: well, just push a developer branch with your changes in | 15:16 |
| robtaylor | rjek: and use that in your branch | 15:16 |
| rjek | robtaylor: I was more thinking of just checking that branch out inside the bootstrapped system, and setting PATH... | 15:16 |
| Kinnison | rjek: backing the gcc sha down to your 4.6 one would let us get closer to something reviewable for merge | 15:17 |
| robtaylor | rjek: i understand, but that won't build you a stage three with a morph with your pachtes | 15:17 |
| Kinnison | rjek: even if we can't merge it yet | 15:17 |
| rjek | robtaylor: I have a built stage three. It's just got a morph which doesn't know what mips is. | 15:17 |
| robtaylor | rjek: indeed, which is why i'm suggesting what im suggesting | 15:17 |
| * robtaylor wonders if rjek is reading the same things robtaylor thinks he's writing | 15:18 | |
| rjek | I don't understand why running a locally-patched morph won't let me build a devel system. | 15:18 |
| rjek | I don't understand much :) | 15:18 |
| robtaylor | oh, i see, you're saying boot your stage 3 and then check out a new morph | 15:18 |
| robtaylor | sure that'd work | 15:18 |
| rjek | yeah | 15:18 |
| robtaylor | better to do what i said though | 15:19 |
| rjek | I don't understand what it is you said :) | 15:19 |
| rjek | "just push a developer branch with your changes in and use that in your branch" | 15:19 |
| robtaylor | rjek: do you have a branch with your cahnegs to morph | 15:19 |
| robtaylor | ? | 15:19 |
| rjek | yo dawg, etc. | 15:19 |
| robtaylor | rjek: and have you pushed that branch up to git.baserock.org? | 15:19 |
| rjek | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=baserock/robkendrick/mips64 | 15:20 |
| robtaylor | rjek: ok, so all you need to do is update the ref for morph in you defintions.git | 15:20 |
| robtaylor | rjek: to point at that sha | 15:20 |
| robtaylor | and run your bootstrap | 15:20 |
| rjek | And rerun the whole stage1 and stage2? | 15:20 |
| robtaylor | yup | 15:21 |
| rjek | What that actually boils down to is what Kinnison suggested: change the gcc refs to when it was still 4.6 | 15:21 |
| robtaylor | heh, yep | 15:21 |
| rjek | (Rather than change the morph ref, which obviously I already have :) | 15:21 |
| rjek | I will try to work out how to do that without giving up all hope, and kicking off a build to run overnight, then :) | 15:22 |
| robtaylor | ah i was confused where you were at exactly.. | 15:22 |
| rjek | I could write a book describing the story so far :) | 15:22 |
| paulsherwood | rjek: i'd read it :) | 15:23 |
| robtaylor | I think that#s not a terrible plan at all | 15:23 |
| rjek | If Baserock had a mechanism that let me say "When building for architecture X, use this specific compiler instead", I think a lot of the friction I've had in the past three weeks would have not occured. | 15:24 |
| robtaylor | mm, we discussion variable and conditionals many many moons ago but did nothing on it | 15:25 |
| * robtaylor feels theres still a lot of basics not right in morph still | 15:26 | |
| rjek | IOError: [Errno 28] No space left on device | 15:40 |
| rjek | Bah! | 15:40 |
| rjek | What's the incantation for clearing the cache, but not too much? | 15:40 |
| paulsherwood | morph gc | 15:41 |
| rjek | ta | 15:41 |
| liw-orc | rjek, also, 'cause I don't think morph gc does that, rm *.system.* removes the system artifacts, which are huge, and not particularly interesting most of the time | 15:42 |
| paulsherwood | you could consider rm /src/cache/artifacts/*rootfs too | 15:42 |
| liw-orc | (morph gc keeps the few latest ones, I believe) | 15:42 |
| rjek | Thanks | 15:42 |
| jjardon | Should we add a note to the wiki? | 15:43 |
| * jjardon has the same problem as rjek the other day | 15:43 | |
| paulsherwood | i'll do it | 15:43 |
| liw-orc | thanks, paulsherwood | 15:43 |
| rjek | I was just thinking that even with a top-shelf SSD, this is slow. Then I remembered how slow OE is. | 15:48 |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Quit: Leaving] | 15:50 | |
| paulsherwood | done: Build failures | 15:56 |
| paulsherwood | ============== | 15:56 |
| paulsherwood | http://wiki.baserock.org/tips-and-tricks | 15:56 |
| * rjek runs his native-bootstrap script fixing script | 16:04 | |
| paulsherwood | does cache-key calculation depend on the version of morph, now? | 16:20 |
| pedroalvarez | paulsherwood: I don't think so | 16:20 |
| pedroalvarez | but I think that one of the last commits in morph changes the cache-keys | 16:21 |
| Kinnison | I think the chunks-in-definitions might have | 16:21 |
| richard_maw | chunks in definitions did | 16:21 |
| paulsherwood | was that unavoidable? | 16:23 |
| Kinnison | I believe so. | 16:24 |
| Kinnison | Because previously the chunk morphology content was encoded as part of the chunk tree SHA but with it definitions, the content needed to be part of the key | 16:24 |
| pedroalvarez | oh yes, because of that | 16:25 |
| pedroalvarez | without the change, any change in the chunk morpholgy won't trigger a rebuild | 16:25 |
| paulsherwood | right, thanks, i get it now | 16:26 |
| Kinnison | I *think* this was covered in Richard's mails on baserock-dev | 16:26 |
| Kinnison | if you need more detail | 16:26 |
| paulsherwood | thanks | 16:26 |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 16:29 | |
| paulsherwood | is there any version of definitions artifacts cached at g.b.o based on the new calculation? | 16:29 |
| Kinnison | I don't think so. gbo's cache tends to only contain artifacts for releases | 16:29 |
| paulsherwood | ok | 16:29 |
| pedroalvarez | Seems like youtube is taking its time today, but here will appear a video about configuring a generic Trove in OpenStack using a tiny cloud-init script: https://www.youtube.com/watch?v=JmH4cCjs5-M | 17:00 |
| pedroalvarez | around 3 minutes, some mouse clicks, and some easy instrucitons, a Trove configured in the cloud :) | 17:01 |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 17:08 | |
| paulsherwood | super! what would it take to get that same soln ito AWS? | 17:23 |
| persia | A set of AWS clients, to start. | 17:24 |
| paulsherwood | pedroalvarez: could that be put onto the vimeo channel? | 17:24 |
| pedroalvarez | paulsherwood sure! | 17:35 |
| pedroalvarez | I think the YouTube video is working now :) | 17:36 |
| jjardon | Hi, would be possible to replace the busybox sed for the real one? | 21:02 |
| jjardon | Im getting a compilation error because the -E option is not supported | 21:03 |
| persia | Looks like it would need lorrying (I don't see it lorried). | 21:07 |
| persia | So for now, you'd have to have a local chunk. | 21:07 |
| persia | But once you have that, you can set whatever needs real sed to build-depend on real sed, and you should be fine. | 21:07 |
| persia | There is some way to manage overlays to replace busybox sed, but I don't really know how that works. | 21:08 |
| jjardon | I have a similar problem, so maybe it would be good replace all the commands for the real ones | 21:22 |
| jjardon | s/similar problem/similar problem with diff/ | 21:23 |
| persia | If you're building a system that needs GNU utilities, then use them. | 22:05 |
| persia | I doubt the default will change, because lots of folk seem to be striving for very small systems. | 22:05 |
| persia | But there's not reason that if you're making, say, a GNOME desktop environment, you couldn't use the GNU utilities rather than busybox. | 22:06 |
| pedroalvarez | I had a similar problem with cloudinit, and I persuaded upstream to support busybox :) | 22:06 |
| * persia suspects its an easier sell to convince folk working on appliance enablement code to support simple stuff, and that folk building a full-featured desktop system probably don't find the difference in size between busybox and GNU signifcant :) | 22:07 | |
| jjardon | what is our version of busybox? | 22:16 |
| * jjardon checks | 22:16 | |
| jjardon | Seems its 1.20.1, more than 2 years old ... Maybe in the new version the functionality has been added in the previous commands | 22:21 |
| jjardon | with more problems than expected but ... gnome-shell master compiled with baserock! :) time to go home, I will setup a vitual machine and deploy tomorrow when travelling to GUADEC and see if everything works correctly | 22:34 |
| persia | Nice! | 23:01 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!