| *** Aaliyah_Marquard [~nodebot@li604-225.members.linode.com] has joined #baserock | 00:45 | |
| *** Aaliyah_Marquard [~nodebot@li604-225.members.linode.com] has quit [Remote host closed the connection] | 01:24 | |
| *** thecorconian [~thecorcon@136.1.1.104] has joined #baserock | 05:04 | |
| *** thecorconian [~thecorcon@136.1.1.104] has quit [Remote host closed the connection] | 05:09 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:13 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:19 | |
| petefoth | INteresting quote from an article on opensource.com: One of the things that allowed Ansible to spread very quickly was that both the product and the documentation were optimized for the quickest possible successful first experience. ' | 07:21 |
|---|---|---|
| petefoth | http://opensource.com/business/14/9/community-best-practices-new-era-open-source | 07:21 |
| paulsher1ood | yes. saw that and wept | 07:34 |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:37 | |
| rjek | petefoth: All people want to see in the first 10 minutes is the lights blink. | 07:38 |
| petefoth | rjek: yep! Baserock needs some blinking lights! | 07:39 |
| SotK | what version of GCC do we have in Baserock at the moment? | 07:39 |
| rjek | 4.7 IIRC | 07:39 |
| rjek | (4.8 and newer require a C++ compiler to bootstrap) | 07:40 |
| * SotK cries | 07:40 | |
| rjek | SotK: What's your problem? | 07:41 |
| SotK | I'm getting `error: 'class std::multimap<AbstractSource*, std::basic_string<char> >' has no member named 'emplace'` | 07:42 |
| paulsher1ood | wouldn't it be trivial to use our gcc to add a later one? | 07:43 |
| SotK | I don't know enough about our bootstrap process to know if it would be trivial | 07:45 |
| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:48 | |
| paulsher1ood | i wasn't thinking bootstrapping it, just sticking it over the top :) | 07:50 |
| paulsher1ood | pedroalvarez may know about the bootstrap angle | 07:50 |
| pedroalvarez | hm..building gcc over the top maybe is easy. | 08:07 |
| pedroalvarez | I rjek is right, then upgrade to gcc 4.8 on the right way is going to be complicated | 08:08 |
| pedroalvarez | s/4.8/4.8 or newer/ | 08:08 |
| pedroalvarez | rjek: I'm not good at compilers, but doesn't gcc include a c++ compiler? | 08:12 |
| pedroalvarez | rjek: If it does, I'm not understanding your "4.8 and newer require a C++ compiler to bootstrap" | 08:13 |
| rjek | pedroalvarez: GCC 4.7 and older are written in C. | 08:16 |
| rjek | Newer are written in C++. | 08:16 |
| rjek | Baserock's bootstrapping only builds a C compiler for stage 1, IIRC. | 08:17 |
| pedroalvarez | hm.. that's why stage1 and stage2 build faster than gcc stage3 | 08:17 |
| pedroalvarez | SotK: but are you sure that upgrading gcc would solve your problems? | 08:20 |
| SotK | pedroalvarez: multimap::emplace is apparently implemented in 4.8 so it should do | 08:21 |
| SotK | pedroalvarez: I seem to remember building some version of the thing that is failing successfully though, so I can try and work around it I think | 08:22 |
| jjardon | In my opinion there are 3 critical components that needs an update in baserock: systemd, gcc and port from eglibc to glibc. Is anyone working (or plan to work) in any of those? | 08:40 |
| pedroalvarez | jjardon: no at the moment | 08:41 |
| Kinnison | updating gcc will be a pain because of the C++ness | 08:41 |
| Kinnison | we may have to introduce a stage4 | 08:42 |
| Kinnison | esp. given some platforms haven't been ported to newer gccs yet | 08:42 |
| Kinnison | pedroalvarez: who's palm do I grease with what kind of silver to get a devel vm on ct-stack ? | 08:42 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:43 | |
| * pedroalvarez tries to make sense of that | 08:43 | |
| richard_maw | jjardon: No current plans to update those. systemd ought to be easier than the others, but I want inline morphologies before I touch the bootstrap again | 08:54 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:58 | |
| jjardon | richard_maw: inline morphologies? | 09:00 |
| richard_maw | so if you've got a chunk morphology that's really trivial, you can just write it in the stratum, rather than needing to add another file | 09:01 |
| jjardon | Oh, that would be helpful: currently the separation of information to build a chunk is a bit weird: you have the steps to build a chunk in the morphology, but the commit you want to build in another file: it would be good that all the information to build a chunk would be in the same place | 09:07 |
| CTtpollard | +1 | 09:08 |
| richard_maw | I'd like us to be closer to the idea that separate morphology files are just a tool for code reuse | 09:09 |
| richard_maw | at least, as far as Chunk morphologies are concerned | 09:09 |
| richard_maw | I currently still think that stratum morphologies should be in different files | 09:10 |
| richard_maw | but I want a way to include a stratum in another, rather than just build-depend | 09:10 |
| pedroalvarez | If all the chunks morphologies were inlined in the strata, then the strata would be unreadable (IMO) | 09:12 |
| richard_maw | I'm not suggesting it should be mandatory | 09:14 |
| richard_maw | but if it's one line, then it's the same amount of data in the stratum morphology, and you don't need a separate file | 09:15 |
| pedroalvarez | I'm just saying that "having the stemps to buiild and the sha1 in the same place" doesn't make sense to me yet | 09:15 |
| pedroalvarez | s/stemps/steps/ | 09:16 |
| jjardon | richard_maw: yeah, I remember to suggest that long time ago ;) (the possibility to include strata in another) | 09:16 |
| jjardon | pedroalvarez: why not? Maybe I'm biased but its what jhbuild or gnome-continuous do for exemple | 09:18 |
| pedroalvarez | jjardon: how would be your ideal scenario? moving the build steps to the strata? Move the sha1 to the chunk morphology? | 09:21 |
| pedroalvarez | other options? | 09:21 |
| *** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:30 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 09:34 | |
| jjardon | Id like to have everythng in the same file, as richard_maw suggest. The less you have to swtich between files, the best | 09:52 |
| fay__ is now known as fay_ | 09:52 | |
| jjardon | Move the sha in the morphology would mean we need a morphology for _all_ the chunks, not only the ones that need some special configuration/build parameters, so it would be more work | 09:52 |
| * Kinnison wishes we had that, but understands why (for now) we don't | 09:53 | |
| * Kinnison would couple it with being able to embed the chunk morphology content into the stratum | 09:53 | |
| richard_maw | I'm not suggesting moving every chunk morphology into the strata. gcc should remain as a separate file, but there's many small morphologies | 09:54 |
| jmacs | git.baserock.org is about to reboot to apply updates. | 09:57 |
| pedroalvarez | yay \o/ | 09:58 |
| ssam2 | standup: https://ct098.project.codethink.co.uk/log/2014/standup-20140924/ | 09:58 |
| richard_maw | ssam2: wrong channel? | 09:59 |
| Kinnison | ssam2: leak | 09:59 |
| ssam2 | oops, sorry | 09:59 |
| paulsher1ood | jmacs: did it work? | 10:01 |
| jjardon | richard_maw: agree its good to have the ability to separate big morphologies in a different file. But this should be the exception | 10:02 |
| * paulsher1ood is impatient | 10:02 | |
| jmacs | Not yet, one problem which we expected | 10:02 |
| paulsher1ood | ok | 10:02 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:03 | |
| violeta | radiofree, what would be the difference between manually booting the kernel with 'sysboot' and doing it with your script? | 10:09 |
| radiofree | violeta: my script replaces fastboot with u-boot (with some patches to load from btrfs) + flashes baserock to the emmc | 10:09 |
| paulsher1ood | you mean ./baserock-jetson-flash.sh i assume on http://wiki.baserock.org/guides/baserock-jetson | 10:10 |
| radiofree | once you've done that, you have u-boot on there, that can read it's configuration information from a file | 10:10 |
| radiofree | on an sd card... | 10:10 |
| paulsher1ood | so once that initial flashing is done, does the morph deploy --upgrade put everything exccept u-boot on SSD? | 10:11 |
| paulsher1ood | (so we could cycle upgrades without wearing emmc?) | 10:11 |
| violeta | then if I use baserock-jetson-flash.sh do I have to flash a BE baserock with it too? | 10:11 |
| radiofree | u-boot.img ends up in /boot but you still need to manually flash u-boot onto the board | 10:12 |
| radiofree | violeta: if you ran that script then there's no need to run it again | 10:12 |
| radiofree | you have a BE rootfs right? | 10:12 |
| violeta | Ah, got it, yes | 10:12 |
| radiofree | extract that to an SD card | 10:12 |
| radiofree | create an extlinux.conf in /boot on the sd card | 10:12 |
| radiofree | place sd card in jetson | 10:12 |
| radiofree | it will boot from the sd card | 10:13 |
| violeta | I thought I could test the kernel before having a rootfs (or that's what I infer after talking with Ben) | 10:13 |
| radiofree | (as long as you tell it rootfs=/dev/mmcblk1p1) | 10:13 |
| radiofree | yes sure you can | 10:13 |
| radiofree | it's not particularly difficult to comprehend - u-boot looks for an extlinux.conf on the sdcard, first in /, then in /boot, if it can't find it it will look for it in / on the emmc | 10:14 |
| violeta | yes, I'll try it now, thanks | 10:14 |
| radiofree | so anything you put in /extlinux.conf (or /boot/extlinux.conf) on an sd card will get loaded first | 10:14 |
| jmacs | git.baserock.org is back up again. The upgrade failed, so we've rolled back to the previous version. | 10:15 |
| paulsher1ood | jmacs: ok, rinse and repeat,, then :) | 10:15 |
| richard_maw | I bumped into an issue requiring this patch: http://pastebin.com/3k88RytK | 10:22 |
| ssam2 | richard_maw: liw-orc and jmac pointed that one out to me in person yesterday, too | 10:22 |
| ssam2 | +1 to merge the fix | 10:23 |
| ssam2 | the issue is that if you use screen you get an env var with '%d' in it which breaks the interpolation in app.status(), right ? | 10:23 |
| richard_maw | I don't have git.baserock.org push credentials on this machine | 10:23 |
| richard_maw | ssam2: yep | 10:23 |
| richard_maw | probably other ways to trip it, but that's what's happening to me | 10:23 |
| ssam2 | ok. I think you should organise push credentials for your computer :) but I'm happy to merge the patch for you if someone else gives it a +1 | 10:24 |
| richard_maw | there's no rush from me, it'll be in my next patch series if it isn't adopted sooner | 10:24 |
| ssam2 | ok. since it's now tripped up two people, probably best to have it in as soon as possible | 10:25 |
| pedroalvarez | I don't understand the patch yet :/ | 10:25 |
| ssam2 | if value is '%d', value_msg is '= %d', and then msg='foo environment variable bar = %d' | 10:26 |
| Kinnison | richard_maw: are you trying to fix the distbuild fallout from your previous patches? | 10:26 |
| ssam2 | in app.status, it calls msg % args, msg contains a %d but args is empty | 10:26 |
| richard_maw | Kinnison: that's one of my goals, but first I want to have distbuild tests part of the main test suite, so it doesn't happen again | 10:28 |
| Kinnison | :-) | 10:28 |
| pedroalvarez | richard_maw: +1 | 10:29 |
| richard_maw | today is about plugging holes in test-suite coverage that caused my per-source building patches to break things | 10:31 |
| richard_maw | it's just a shame it means that I can't have a go at `morph build $CLUSTER` , inline chunk morphologies or embedded strata | 10:38 |
| Kinnison | there's always next week | 10:38 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 10:44 | |
| richard_maw | I suppose so, but those are features I've wanted for a while | 10:44 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:44 | |
| Kinnison | Can't have fancy new features when the current stuff is broke | 10:44 |
| * Kinnison is a meanie | 10:44 | |
| Kinnison | tbf, you can do whatever you want with your upstream time | 10:44 |
| Kinnison | but I'd pout a lot | 10:44 |
| richard_maw | oh I know this is the top priority, just I'd rather do the others tomorrow instead of next week | 10:45 |
| richard_maw | (i.e. 100% time rather than 20% time) | 10:45 |
| * Kinnison chuckles | 10:46 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:51 | |
| jmacs | We're going to try the upgrade again, so git.baserock.org will be rebooted in a few minutes. | 10:52 |
| * richard_maw goes to lunch | 10:53 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 10:53 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:54 | |
| ssam2 | git.baserock.org seems to be back :) | 11:02 |
| pedroalvarez | and looks like the new version | 11:03 |
| violeta | unfortunately my BE kernel didn't work, seems like there is a problem with voltage regulators | 11:04 |
| jmacs | pedroalvarez to the rescue. | 11:05 |
| pedroalvarez | hehe, I've been monitoring the process | 11:05 |
| jmacs | It looks like the error with TROVE_GENERIC was the only unexpected problem. | 11:07 |
| Krin | hey all, trying the jetson baserock install and upgrade, but i'm having an issue where the upgrade is too large for the currently allocated space. just had a look and the usage looks like this | 11:10 |
| Krin | /dev/mmcblk0p1 3.0G 1.1G 1.7G 39% | 11:10 |
| Krin | just wondering why it's so small? using the stock installer i can specify the size to be up to 14500MiB | 11:10 |
| Krin | am i missing a trick? | 11:11 |
| radiofree | use ROOTFS_SIZE | 11:12 |
| radiofree | what exactly are you trying to do? | 11:12 |
| Krin | just upgrade the jetson to the newer baserock as discribed on the Wiki | 11:13 |
| paulsher1ood | jmacs: congratulations :-) | 11:13 |
| radiofree | how are you trying to do that? | 11:14 |
| Krin | http://wiki.baserock.org/guides/baserock-jetson/ | 11:14 |
| Krin | following those instructions. got all the way up to running the morph before I hit an issue | 11:14 |
| radiofree | so you're running baserock and it's *morph* complaining about lack of disk space? | 11:15 |
| radiofree | you haven't setup /src correctly then | 11:15 |
| radiofree | baserock needs quite a lot of space to build things, you could use an sd card (never tried this though, might be slow), or grab a SSD and plug it into the sata | 11:16 |
| radiofree | also that guide assumes someone is already familiar with baserock | 11:17 |
| radiofree | http://wiki.baserock.org/quick-start/#index4h2 is probably what you need | 11:17 |
| * paulsher1ood checks the instructions... | 11:19 | |
| paulsher1ood | Krin: did you add the extra src drive as it says? | 11:20 |
| paulsher1ood | http://wiki.baserock.org/guides/baserock-jetson/#index2h2 | 11:20 |
| radiofree | should probably add a link to http://wiki.baserock.org/quick-start/#index4h2 there | 11:20 |
| radiofree | since it doesn't mention you need to setup /etc/morph.conf | 11:21 |
| * radiofree does that | 11:21 | |
| paulsher1ood | cool | 11:22 |
| ssam2 | i've merged http://pastebin.com/3k88RytK to master, thanks richard_maw | 11:22 |
| * paulsher1ood wishes the default behaviour without the fiddlings would be friendlier | 11:22 | |
| richard_maw | thanks ssam2 | 11:23 |
| ssam2 | and updated definitions.git | 11:23 |
| richard_maw | paulsher1ood: we could instead have a larger root disk, at which point those instructions aren't necessary, or provide instructions how to mount the extra disk in-place | 11:26 |
| richard_maw | so you don't need to fiddle with morph.conf, but there's more stuff to add to /etc/fstab | 11:26 |
| radiofree | larger root disk isn't an option on the jetson | 11:27 |
| Krin | why not radiofree? the nvidia stock installer allows a larger root disk of up to 14GB | 11:29 |
| richard_maw | hm, perhaps we should also have it put /home, /root and /var on the extra disk too | 11:29 |
| radiofree | 14G is not enough for baserock | 11:29 |
| pedroalvarez | ineed, is not enough | 11:29 |
| ssam2 | since we only support running Morph in Baserock, having the default cachedir = /src/cache and default tempdir = /src/tmp wouldn't be crazy | 11:30 |
| paulsher1ood | richard_maw: why not have default morph.conf in morph and be done? if no /etc/morph.conf assume defaults, fall over if /src doesn't exist | 11:30 |
| ssam2 | that was strange | 11:30 |
| ssam2 | synergy! | 11:30 |
| paulsher1ood | :-) | 11:30 |
| Krin | well, re-followed the instructions for adding the SSD to the system, now the jetson wont boot at all, gets stuck on "starting Kernel" i'll do a freash flash and see if i did something weird along the way | 11:31 |
| paulsher1ood | Krin: whoa | 11:31 |
| radiofree | Krin: "starting Kernel"? | 11:31 |
| paulsher1ood | do you have a serial cable? | 11:31 |
| Krin | paulsher1ood, ? | 11:31 |
| Krin | yes | 11:31 |
| radiofree | please paste your logs | 11:31 |
| paulsher1ood | better to debug what's going on, then. | 11:31 |
| radiofree | if you're using screen, control-a + H | 11:32 |
| radiofree | then reboot the jetson | 11:32 |
| paulsher1ood | wow... so much magic | 11:32 |
| radiofree | then pastebin the screenlog.* file | 11:33 |
| radiofree | (it will probably be in /root) | 11:33 |
| radiofree | this is an interesting bug considering u-boot can't actually discover the SSD | 11:34 |
| radiofree | so please don't reflash | 11:34 |
| paulsher1ood | Krin: ^^ (better to try to diagnose, than loas an hour reflashing to get back to the same or a differnt place) | 11:34 |
| paulsher1ood | s/loas/lose/ | 11:34 |
| Krin | aye, gabbing the log, | 11:35 |
| paulsher1ood | tvm | 11:35 |
| Krin | well here are my logs, starting from the point where i had edited etc/fstab i'm still not sure how to realy read these things well so any help would be appreciated | 11:37 |
| Krin | https://admin.codethink.co.uk/pnopaste/?1879 | 11:37 |
| pedroalvarez | Krin: can you use a public pastebin service? | 11:38 |
| radiofree | oh wow that's special! | 11:39 |
| paulsher1ood | Krin: public version please? | 11:40 |
| Krin | http://pastebin.com/kuvi8JQD this more appropriate pedroalvarez | 11:40 |
| radiofree | does restarting it help? | 11:40 |
| Krin | it does not seem to, but i'm sure if you come and watch me then it will help then and make me a liar | 11:40 |
| radiofree | i don't think there's anything you can do there then, if it's stuck on Starting kernel ... you'll need to reflash | 11:41 |
| radiofree | i wonder what caused that | 11:41 |
| Krin | oh wait, 4 restarts in a row and it's running now... O.o | 11:42 |
| pedroalvarez | richard_maw: can a sbusystem have a subsystem? Use case: deploy a system with a system inside (.img) and the system inside using initramfs. | 11:42 |
| radiofree | Krin: yay for "turning it on and off again a few times" | 11:43 |
| SotK | Krin: what did you put in fstab ooi? | 11:43 |
| pedroalvarez | richard_maw: a "yes" or "no" is enough | 11:43 |
| Krin | lemme open it up and get an exact copy | 11:43 |
| Krin | aside, it's still not got enough space | 11:43 |
| SotK | pedroalvarez: I think that richard_maw told me that that was possible when I was doing the partial deployment stuff | 11:44 |
| Krin | LABEL=src /src btrfs defaults 0 2 | 11:44 |
| Krin | SotK, ^^ | 11:44 |
| radiofree | did you confirgure morph to use it? | 11:44 |
| pedroalvarez | SotK: great | 11:45 |
| pedroalvarez | thanks | 11:45 |
| Krin | no, that was only added by yourself radiofree after i tried this the first time, then the kernel thing made me forget about it, i'll do that now | 11:45 |
| paulsher1ood | ssam2, richard_maw - http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?h=baserock/ps/hardcode-default-dirs | 11:51 |
| paulsher1ood | seems to work with no morph.conf, even for a symlink /src. fails nastily if /src doesn't exist, which is ok imo | 11:52 |
| radiofree | will that cause a spectacular failure if /src doesn't exist? | 11:52 |
| paulsher1ood | yup | 11:52 |
| pedroalvarez | hmm | 11:52 |
| pedroalvarez | morph works without /src and without morph.conf at the moment | 11:53 |
| paulsher1ood | really? | 11:53 |
| pedroalvarez | (if the root disk has space) | 11:53 |
| paulsher1ood | it 'works' in the sense that it won't bork on directories, but won't have enough space to actually build anything by default, i think | 11:54 |
| Krin | this is likely because i have no idea how to use morph, but i'm now getting this error. | 11:59 |
| Krin | L="my new version" | 11:59 |
| Krin | ERROR: Can't find the workspace directory. | 11:59 |
| Krin | Morph must be built and deployed within the system branch checkout within the workspace directory. | 11:59 |
| Krin | L="my new version" | 11:59 |
| Krin | ERROR: Can't find the workspace directory. | 11:59 |
| Krin | Morph must be built and deployed within the system branch checkout within the workspace directory. | 11:59 |
| Krin | full command included this time | 12:00 |
| CTtpollard | morph init workspace? | 12:00 |
| Krin | wait, why is it not copying the first line... ¬.¬ | 12:00 |
| Krin | ahh ok | 12:00 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 245 seconds] | 12:03 | |
| Krin | CTtpollard, that made a directory called workspace but no other effect. i'll see if i can find some documentation concerning morph and get a little familiar with it first | 12:04 |
| pedroalvarez | Krin: creating the workspace is the first step :) | 12:05 |
| CTtpollard | cd into it and retry? | 12:05 |
| Krin | tried that CTtpollard | 12:05 |
| Krin | also had previusly tried making the workspace directory manualy | 12:05 |
| Krin | pedroalvarez, could you tell me where to find steps 2 - X ? :) | 12:06 |
| pedroalvarez | Krin: sure | 12:07 |
| pedroalvarez | Krin: http://wiki.baserock.org/devel-with/ | 12:07 |
| Krin | thank you pedroalvarez :) | 12:14 |
| richard_maw | paulsher1ood: the defaults are sufficient for the OpenStack deployed images, and they will be for deployments to physical x86 hardware. I _really_ don't want to hard-code the defaults to /src, partly because this will add another block in the way of building as a non-root user. | 12:32 |
| richard_maw | paulsher1ood: would you be satisfied by released images intended for VM deployments including an /etc/morph.conf? | 12:33 |
| paulsher1ood | richard_maw: if that could be done, it would be lovely, yes :) | 12:40 |
| paulsher1ood | incidentally, we should try to scrap the whole workspace concept if we can, i think :) | 12:41 |
| richard_maw | ok, how do you propose to manage local changes to chunk sources? | 12:42 |
| paulsher1ood | richard_maw: you mean if we scrapped workspaces? | 12:42 |
| richard_maw | yeah, it's convenient to be able to `morph edit` a chunk, so you can fiddle with it | 12:43 |
| paulsher1ood | i agree... but couldn't that just do its stuff into a sibling directory of the definitions checkout? | 12:43 |
| richard_maw | something Kinnison and I discussed was to instead have a morph command that would link the definitions checkout with the chunk checkout | 12:44 |
| richard_maw | it would be a sibling directory, but we'd need a way to tell morph to build using that instead | 12:44 |
| richard_maw | and I'd rather not require people put repo: file:///... and ref: HEAD in themselves | 12:45 |
| paulsher1ood | agreed | 12:46 |
| petefoth | any users od Eclipse will be familiar with the 'workspace' idea. It's not uncommon to keep all your develoment files and directories somewhere other than your home folder | 12:52 |
| richard_maw | paulsher1ood but `morph build $CLUSTER`, inline chunk morphologies and embedding strata currently have a higher priority for me, so I wouldn't get to it for a while if we end up relying on me to implement that | 12:54 |
| richard_maw | petefoth: true, but projects involve a lot of tools and sources, we're proposing that morph isn't responsible for workspace management | 12:55 |
| petefoth | richard_maw: fair point. By default, Eclipse will use $HOME/workspace as its workspace directory. COuld morph not default to doing something similar (i.e use /src/workspace) and allow the user to specify a different directory if they wish? | 12:58 |
| paulsher1ood | petefoth: if we can't default to /src, we can't default to /src/workspace :) | 13:01 |
| * petefoth missed the bit that said 'we can't default to /src. Clearly not paying clode enoyugh attention :)' | 13:02 | |
| petefoth | s/clode/.... | 13:03 |
| richard_maw | petefoth: no, I don't think that makes sense, since morph build works on which directory you're currently in, so `morph checkout baserock:baserock/definitions master` doesn't do you much good putting it in a default location when you need to chdir into that anyway | 13:03 |
| * petefoth backs away due to insuffucient context | 13:04 | |
| paulsher1ood | :) | 13:04 |
| richard_maw | context is precisely the problem for having a default workspace :-) | 13:05 |
| petefoth | :) | 13:06 |
| ssam2 | we could add gcc 4.8 in after gcc 4.7 in the build-essential stratum, as a temporary way of getting gcc 4.8 in Baserock | 13:09 |
| ssam2 | it would mean lots of rebuilds and might trigger lots of new issues | 13:10 |
| paulsher1ood | ssam2: whay about adding it later (just for *use* in devel, not building devel)... would that allow experimentation in a useful way? | 13:11 |
| paulsher1ood | s/whay/what/ | 13:11 |
| Kinnison | Interesting issues could arise wrt. conflicts between 4.7 and 4.8 content | 13:11 |
| Kinnison | incomplete overlaps fr.ex. | 13:12 |
| paulsher1ood | ok | 13:13 |
| richard_maw | you could do some artifact splitting to make 4.7 a pure build-depend | 13:13 |
| Kinnison | aye | 13:14 |
| * petefoth stumbles across http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/doc/branching-merging-systems.mdwn Specifies in a lot of detail a couple of workflows and describes how they are / could be implemented with morph. I think it =would make a goos startign point for discussions about simplifying workflows. | 13:20 | |
| petefoth | Certainly more accessible than the pages I published earlier | 13:20 |
| ridgerunner | Whoot! the build I started yesterday afternoon has just finished successfully! Now to try a Baserock upgrade. | 13:22 |
| radiofree | what's the procedure for building out-of-tree kernel modules in baserock? | 13:23 |
| pedroalvarez | radiofree: let me dig out that infomration | 13:25 |
| pedroalvarez | radiofree: first of all the kenel module has to build depend on the "linux" chunk | 13:28 |
| pedroalvarez | because the linux chunk intall the kernel headers | 13:29 |
| petefoth | where do I find the code for system-version-manager? | 13:29 |
| pedroalvarez | petefoth: tbidiff.gi/system-version-manager | 13:29 |
| pedroalvarez | s/gi/git/ | 13:29 |
| petefoth | pedroalvarez: ta! | 13:29 |
| pedroalvarez | petefoth: just in case: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/tbdiff.git/tree/system-version-manager | 13:30 |
| ridgerunner | First question: on http://wiki.baserock.org/guides/baserock-jetson/ section "Upgrading your Jetson to a new or custom Baserock system" what directory should I create the new .morph file in? I'm guessing somwhwere in /src, but should it be in a new directory? an existing workspace? Somewhere else entirely? | 13:31 |
| radiofree | pedroalvarez: what about modules that need the kernel source? | 13:31 |
| Krin | "After building your new or custom devel-system-armv7lhf-jetson, create a file "jetson-upgrade.morph":" Ok... umm, trying to build the system, is there a different place i need to point morph at the get the details of that build? i'v tried changing the command to reflect the desired build type, but it's not finding anything | 13:31 |
| radiofree | ridgerunner: i'd suggest reading through http://wiki.baserock.org/devel-with/ first | 13:31 |
| radiofree | specifically "Upgrading a Baserock installation" | 13:31 |
| radiofree | same for you Krin | 13:32 |
| radiofree | the jetson guide assumes some knowledge of how to use baserock | 13:32 |
| Krin | i'm doing that at the moment radiofree, bit lost on where to get the files to do the build for the jetson | 13:32 |
| pedroalvarez | radiofree: hmm.. I think that I didn;t use "kernel headers" right. I think that the linux chunk installs also some part of the kernel source. | 13:32 |
| Krin | i'v got the one from upgrading baserock installation working, but it quite rightly warns me that it is for the wrong platform | 13:33 |
| radiofree | pedroalvarez: ok i'll give it a go, manually building it for now | 13:33 |
| ridgerunner | radiofree: thanks, I'll do that. I think that a cross link would be helpful, I'll put one in | 13:33 |
| radiofree | ridgerunner: yep it would, noticed that before | 13:33 |
| radiofree | have edited it today to point to "configure morph" now though | 13:33 |
| pedroalvarez | radiofree: the morphology to build a moudule should be like this: http://pastebin.com/PhAV5KBQ | 13:33 |
| radiofree | ta | 13:34 |
| ridgerunner | Ah, it's askiing me to sign in. What credentials should I use? | 13:34 |
| radiofree | Krin: what command are you issuing? | 13:34 |
| pedroalvarez | radiofree: btw, this is in x86 | 13:34 |
| paulsher1ood | ridgerunner: whatever you like | 13:35 |
| Krin | radiofree, i'v been following the page you suggested above, but morph is correctly telling me that i'm building something for the wrong platform type, is there a way to alter the target platform? | 13:35 |
| Krin | i have tried the following | 13:35 |
| radiofree | why would morph be correct in telling you it's the wrong platform type? | 13:36 |
| Krin | morph --verbose | 13:36 |
| Krin | build base-system-x86_64-generic | 13:36 |
| Krin | obviusly wrong | 13:36 |
| radiofree | yes, that's wrong | 13:36 |
| radiofree | you're trying to build an x86 image on arm | 13:36 |
| Krin | morph --verbose | 13:36 |
| Krin | build base-system-armv7lhf | 13:36 |
| radiofree | don't do that | 13:36 |
| Kinnison | Krin: The target platform is defined by the system morphology. What you *can* build is defined by the platform you're on | 13:36 |
| * paulsher1ood will fix the wiki on this | 13:36 | |
| radiofree | does morph build devel-system-armv7lhf-jetson work? | 13:36 |
| Krin | yes radiofree i can see that is wrong, what i cant see is what is right | 13:37 |
| paulsher1ood | ridgerunner: stand down :) | 13:37 |
| Krin | i'll try that radiofree | 13:37 |
| ridgerunner | paulsher1ood: ok. | 13:37 |
| ridgerunner | at least I got to create a user account :-) | 13:38 |
| radiofree | there isn't a "base-system-armv7lhf" is there? | 13:38 |
| Krin | i dont know, that seemed the most logical to me as it said that was the architecture i was running | 13:38 |
| radiofree | what was the error message? it's more helpful if you pastebin logs | 13:39 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/systems | 13:39 |
| radiofree | also http://wiki.baserock.org/devel-with/ will be useful | 13:40 |
| Krin | radiofree, http://pastebin.com/qMB2QjVK | 13:42 |
| radiofree | are you using screen? | 13:46 |
| radiofree | ssh into the device, makes it easier to copy | 13:46 |
| radiofree | File devel-system-armv7lhf-jetson.morph doesn't exist: attempting to infer chunk morph from repo's build system | 13:47 |
| radiofree | ERROR: Couldn't find morphology: devel-system-armv7lhf-jetson.morph | 13:47 |
| Kinnison | you might need systems/ on the front of that | 13:47 |
| Kinnison | morph needs the full path within the definitions repo IIRC | 13:47 |
| radiofree | wiki needs updating then :\ | 13:47 |
| radiofree | http://wiki.baserock.org/devel-with/#index1h2 | 13:48 |
| paulsher1ood | i'll do it | 13:49 |
| Krin | systems/ at the front had no effect Kinnison | 13:49 |
| SotK | Krin: what ref of definitions is this? | 13:51 |
| Kinnison | I happen to have a few mins while a build runs, I'll pop over and see what Krin's up to | 13:51 |
| Kinnison | :-) | 13:51 |
| SotK | any luck? | 13:57 |
| ssam2 | it turns out the Chef guys have literally created their own packaging system for the server and the developer kit | 13:58 |
| ssam2 | https://github.com/opscode/omnibus-software/tree/master/config/software | 13:58 |
| ssam2 | they then use this to generate mega-RPM, mega-.deb, windows installer, etc. packages | 13:58 |
| Kinnison | cripes | 13:59 |
| ssam2 | it looks pretty well executed, for what it is | 13:59 |
| ssam2 | but, it's basically yet another symptom of how difficult life is for ISVs on every operating system | 14:00 |
| Kinnison | Aye | 14:00 |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 14:02 | |
| radiofree | i think this might work | 14:07 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 14:08 | |
| paulsher1ood | so my documentation dilemma is this... | 14:09 |
| paulsher1ood | a lot has changed since the last release. and some breakages have happened. so eg devel-with no longer describes what a new user should be doing. | 14:11 |
| radiofree | Kinnison: was the hdmi working for you? | 14:11 |
| radiofree | (on the jetson) | 14:11 |
| paulsher1ood | i would much prefer to document how things are now, but that either requires a new release, or a switch to 'use latest morph by default' | 14:12 |
| paulsher1ood | (or both) ... thoughts? | 14:12 |
| Kinnison | radiofree: yes | 14:12 |
| Kinnison | radiofree: At least, the console appeared | 14:13 |
| SotK | paulsher1ood: I think we should do a release | 14:13 |
| pedroalvarez | paulsher1ood: versioned documentation! | 14:13 |
| petefoth | pedroalvarez: +1 | 14:14 |
| petefoth | at least, when we make and review changess we need to consider the impact of the changes on (a subset of) the w.b.o documentation | 14:14 |
| petefoth | I don't think we should rely on newcomers not being able to do stuff as the test that we haven't 'broken' the docs | 14:16 |
| ssam2 | paulsherwood: I'd rather we did a release | 14:16 |
| radiofree | Kinnison: hmm i don't get anything with this kernel :\ | 14:16 |
| radiofree | 3.10 i see the console | 14:16 |
| paulsher1ood | i'd be happy to see a release... but iirc persia has some deep concerns about releases in general | 14:18 |
| Kinnison | radiofree: with the kernel built from my branch? | 14:18 |
| radiofree | Kinnison: yeah | 14:18 |
| Kinnison | radiofree: with my morphology? | 14:18 |
| radiofree | plus some other patches though | 14:18 |
| Kinnison | radiofree: e.g. have you got the right dtb? | 14:19 |
| radiofree | yep, modified it for the gpu though, that *might* be the problem | 14:19 |
| * radiofree checks | 14:19 | |
| ssam2 | paulsher1ood: I think persia recognises the need for us to provide prebuild devel system images | 14:19 |
| * Kinnison definitely had login prompts on the hdmi | 14:19 | |
| ssam2 | which is all our release needs to be | 14:19 |
| ssam2 | *prebuilt | 14:19 |
| pedroalvarez | but he mentioned that the version to download should always be the latest of definitions.git | 14:21 |
| ridgerunner | Question: I'm wondering if it would be safe to connect the TK1 to the office network. I'd hope it doesn't have any gotchas like DHCP servers or anything. What does the team think? | 14:22 |
| ridgerunner | That way I could ssh to it wherever I am, even from home. | 14:23 |
| Kinnison | the jetson setup is not a server, so it should be safe for you to attach to whatever network you like | 14:23 |
| ridgerunner | And my laptop wouldn't have to be there acting as a conduit for iternet access | 14:24 |
| Kinnison | indeed | 14:24 |
| ridgerunner | Thanks, that was what I was hoping but I wouldn't want to be responsible for borking the network. | 14:27 |
| ridgerunner | So best to ask. | 14:27 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:30 | |
| violeta | radiofree, if I try to put the old LE kernel back in the same way I'm trying to load the BE kernel (the instructions you gave me with sysboot and the zImage/dtb in the SDcard), it should work, doesn't it? | 14:36 |
| radiofree | i dont see why not | 14:38 |
| paulsher1ood | ridgerunner: you're asking about free open source software, on a public channel. if you break your office network, you get to keep the pieces :) | 14:38 |
| violeta | I don't see it either! | 14:39 |
| dutch is now known as ctdutch | 14:43 | |
| ssam2 | I love a good profane sed command. 's!^.*/!!' | 14:44 |
| * rjek blushes | 14:44 | |
| ridgerunner | paulsher1ood: I suppose it would have been better asked on #tegra but that is usually very quiet | 14:53 |
| * Kinnison wonders if we could use the statistics in the meta files in a morph cache to tell us how much of our lives we waste waiting for autoconf? | 14:55 | |
| Kinnison | E.g. for the 241 seconds it took to build the lsof chunk artifacts, 215s of it was the configure stage | 14:56 |
| ssam2 | i've thought before we should look at providing a system-wide 'config.cache' file | 14:58 |
| ssam2 | seems that might speed it up. I might misunderstand it, though | 14:58 |
| Kinnison | It'd be a risky thing given that the cache might be invalidated by new chunks becoming available in the staging area | 14:59 |
| Kinnison | if each chunk could supply new parts for a cache then we might be able to do something reliable | 14:59 |
| ssam2 | true | 15:02 |
| *** ctdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 16:19 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 16:20 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 16:34 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:38 | |
| richard_maw | hm, my internet is not happy with me | 16:39 |
| * richard_maw restarts laptop | 16:40 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:40 | |
| * paulsher1ood has bad internet everywhere today | 16:48 | |
| paulsher1ood | home, office, phone | 16:48 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 16:53 | |
| paulsher1ood | baserockers... any ideas on http://fpaste.org/136154/ | 17:08 |
| paulsher1ood | looks to me like gbo misbehaving? | 17:08 |
| *** thecorconian [~thecorcon@136.1.1.104] has joined #baserock | 17:13 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:42 | |
| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 17:44 | |
| pedroalvarez | Hm.. Delta/tox doesn't exist in gbo | 17:58 |
| paulsher1ood | ah.. python-packages | 18:02 |
| paulsher1ood | my bad | 18:02 |
| paulsher1ood | while you're on... | 18:02 |
| paulsher1ood | http://fpaste.org/136176/ | 18:03 |
| paulsher1ood | mariadb does everything else ok, but is looking for liblzma.a in a strange place i think... we have /usr/lib/liblzma.a | 18:04 |
| paulsher1ood | (it seems we'll need mariadb if we want storyboard) | 18:05 |
| paulsher1ood | i guess i can try --without-plugin=tokudb | 18:07 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 18:18 | |
| pedroalvarez | Wow, I have no idea what's failing there.. :/ | 18:40 |
| paulsher1ood | +1 :) | 18:41 |
| *** thecorconian [~thecorcon@136.1.1.104] has quit [Ping timeout: 272 seconds] | 18:42 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 19:00 | |
| richard_maw | CVE-2014-6271, bash's inheriting functions through the environment will evaluate arbitrary commands | 19:02 |
| richard_maw | rather trivial too, you just need to make a variable's contents start `(){ come command; }` | 19:03 |
| richard_maw | s/come/some/g | 19:05 |
| richard_maw | more difficult to exploit on Baserock than Ubuntu, as we don't use bash for /bin/sh | 19:06 |
| paulsher1ood | richard_maw: don't you mean, pretty much impossible to exploit on Baserock by default? | 19:09 |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [Ping timeout: 272 seconds] | 19:12 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 19:27 | |
| *** thecorconian1 [~thecorcon@eccvpn1.ford.com] has joined #baserock | 19:32 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [Remote host closed the connection] | 19:32 | |
| richard_maw | paulsher1ood: possibly, but you'd need an audit to be sure about something like that | 19:33 |
| richard_maw | since you could have things specifically invoking /bin/bash | 19:35 |
| richard_maw | the CVE specifically mentions cgi scripts written in bash | 19:36 |
| paulsher1ood | right | 19:38 |
| paulsher1ood | richard_maw: how would you feel about having morph build run morph gc by default? | 19:38 |
| *** thecorconian1 [~thecorcon@eccvpn1.ford.com] has quit [Ping timeout: 260 seconds] | 19:41 | |
| richard_maw | paulsher1ood: only after we make the build graph parsing faster, since if we can't deduct the space taken by artifacts we already have from the build graph, then we could end up removing artifacts we could have re-used | 19:41 |
| paulsher1ood | richard_maw: issue is, as a user, i'd rather be sure my build happens, than find it didn't through lack of space | 19:44 |
| richard_maw | at least with the warning you don't get part-way through a build before failing, you're in a better position to react to the lack of storage | 19:50 |
| paulsher1ood | richard_maw: no, really. every time i run morph build and it stops through lack of space, i curse it :) | 19:55 |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 20:00 | |
| richard_maw | and I would curse even more when I returned to a build, and discovered it had failed due to lack of space | 20:03 |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [Quit: Leaving.] | 21:59 | |
| richard_maw | I wanted to do 3 things today, I didn't finish the first, because getting rid of build-mode: test requires cleaning out a lot of cmdtests | 22:34 |
| richard_maw | most of the way through though | 22:34 |
| richard_maw | and now I sleep | 22:34 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!