IRC logs for #baserock for Wednesday, 2014-09-24

*** Aaliyah_Marquard [] has joined #baserock00:45
*** Aaliyah_Marquard [] has quit [Remote host closed the connection]01:24
*** thecorconian [~thecorcon@] has joined #baserock05:04
*** thecorconian [~thecorcon@] has quit [Remote host closed the connection]05:09
*** fay_ [] has joined #baserock07:13
*** dutch [] has joined #baserock07:19
petefothINteresting quote from an article on 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
paulsher1oodyes. saw that and wept07:34
*** tiagogomes [~tiagogome@] has joined #baserock07:37
rjekpetefoth: All people want to see in the first 10 minutes is the lights blink.07:38
petefothrjek: yep! Baserock needs some blinking lights!07:39
SotKwhat version of GCC do we have in Baserock at the moment?07:39
rjek4.7 IIRC07:39
rjek(4.8 and newer require a C++ compiler to bootstrap)07:40
* SotK cries07:40
rjekSotK: What's your problem?07:41
SotKI'm getting `error: 'class std::multimap<AbstractSource*, std::basic_string<char> >' has no member named 'emplace'`07:42
paulsher1oodwouldn't it be trivial to use our gcc to add a later one?07:43
SotKI don't know enough about our bootstrap process to know if it would be trivial07:45
*** violeta [] has joined #baserock07:48
paulsher1oodi wasn't thinking bootstrapping it, just sticking it over the top :)07:50
paulsher1oodpedroalvarez may know about the bootstrap angle07:50
pedroalvarezhm..building gcc over the top maybe is easy.08:07
pedroalvarezI rjek is right, then upgrade to gcc 4.8 on the right way is going to be complicated08:08
pedroalvarezs/4.8/4.8 or newer/08:08
pedroalvarezrjek: I'm not good at compilers, but doesn't gcc include a c++ compiler?08:12
pedroalvarezrjek: If it does, I'm not understanding your "4.8 and newer require a C++ compiler to bootstrap"08:13
rjekpedroalvarez: GCC 4.7 and older are written in C.08:16
rjekNewer are written in C++.08:16
rjekBaserock's bootstrapping only builds a C compiler for stage 1, IIRC.08:17
pedroalvarezhm.. that's why stage1 and stage2 build faster than gcc stage308:17
pedroalvarezSotK: but are you sure that upgrading gcc would solve your problems?08:20
SotKpedroalvarez: multimap::emplace is apparently implemented in 4.8 so it should do08:21
SotKpedroalvarez: I seem to remember building some version of the thing that is failing successfully though, so I can try and work around it I think08:22
jjardonIn 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
pedroalvarezjjardon: no at the moment08:41
Kinnisonupdating gcc will be a pain because of the C++ness08:41
Kinnisonwe may have to introduce a stage408:42
Kinnisonesp. given some platforms haven't been ported to newer gccs yet08:42
Kinnisonpedroalvarez: who's palm do I grease with what kind of silver to get a devel vm on ct-stack ?08:42
*** jonathanmaw [] has joined #baserock08:43
* pedroalvarez tries to make sense of that08:43
richard_mawjjardon: No current plans to update those. systemd ought to be easier than the others, but I want inline morphologies before I touch the bootstrap again08:54
*** ssam2 [] has joined #baserock08:58
jjardonrichard_maw: inline morphologies?09:00
richard_mawso 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 file09:01
jjardonOh, 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 place09:07
richard_mawI'd like us to be closer to the idea that separate morphology files are just a tool for code reuse09:09
richard_mawat least, as far as Chunk morphologies are concerned09:09
richard_mawI currently still think that stratum morphologies should be in different files09:10
richard_mawbut I want a way to include a stratum in another, rather than just build-depend09:10
pedroalvarezIf all the chunks morphologies were inlined in the strata, then the strata would be unreadable (IMO)09:12
richard_mawI'm not suggesting it should be mandatory09:14
richard_mawbut if it's one line, then it's the same amount of data in the stratum morphology, and you don't need a separate file09:15
pedroalvarezI'm just saying that "having the stemps to buiild and the sha1 in the same place" doesn't make sense to me yet09:15
jjardonrichard_maw: yeah, I remember to suggest that long time ago ;) (the possibility to include strata in another)09:16
jjardonpedroalvarez: why not? Maybe  I'm biased but its what jhbuild or gnome-continuous do for exemple09:18
pedroalvarezjjardon: how would be your ideal scenario? moving the build steps to the strata? Move the sha1 to the chunk morphology?09:21
pedroalvarezother options?09:21
*** fay__ [] has joined #baserock09:30
*** fay_ [] has quit [Ping timeout: 272 seconds]09:34
jjardonId like to have everythng in the same file, as richard_maw suggest. The less you have to swtich between files, the best09:52
fay__ is now known as fay_09:52
jjardonMove 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 work09:52
* Kinnison wishes we had that, but understands why (for now) we don't09:53
* Kinnison would couple it with being able to embed the chunk morphology content into the stratum09:53
richard_mawI'm not suggesting moving every chunk morphology into the strata. gcc should remain as a separate file, but there's many small morphologies09:54 is about to reboot to apply updates.09:57
pedroalvarez yay \o/09:58
richard_mawssam2: wrong channel?09:59
Kinnisonssam2: leak09:59
ssam2oops, sorry09:59
paulsher1oodjmacs: did it work?10:01
jjardonrichard_maw: agree its good to have the ability to separate big morphologies in a different file. But this should be the exception10:02
* paulsher1ood is impatient10:02
jmacsNot yet, one problem which we expected10:02
*** Krin [] has joined #baserock10:03
violetaradiofree, what would be the difference between manually booting the kernel with 'sysboot' and doing it with your script?10:09
radiofreevioleta: my script replaces fastboot with u-boot (with some patches to load from btrfs) + flashes baserock to the emmc10:09
paulsher1oodyou mean ./ i assume on
radiofreeonce you've done that, you have u-boot on there, that can read it's configuration information from a file10:10
radiofreeon an sd card...10:10
paulsher1oodso 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
violetathen if I use do I have to flash a BE baserock with it too?10:11
radiofreeu-boot.img ends up in /boot but you still need to manually flash u-boot onto the board10:12
radiofreevioleta: if you ran that script then there's no need to run it again10:12
radiofreeyou have a BE rootfs right?10:12
violetaAh, got it, yes10:12
radiofreeextract that to an SD card10:12
radiofreecreate an extlinux.conf in /boot on the sd card10:12
radiofreeplace sd card in jetson10:12
radiofreeit will boot from the sd card10:13
violetaI 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
radiofreeyes sure you can10:13
radiofreeit'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 emmc10:14
violetayes, I'll try it now, thanks10:14
radiofreeso anything you put in /extlinux.conf (or /boot/extlinux.conf) on an sd card will get loaded first10:14 is back up again. The upgrade failed, so we've rolled back to the previous version.10:15
paulsher1oodjmacs: ok, rinse and repeat,, then :)10:15
richard_mawI bumped into an issue requiring this patch:
ssam2richard_maw: liw-orc and jmac pointed that one out to me in person yesterday, too10:22
ssam2+1 to merge the fix10:23
ssam2the 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_mawI don't have push credentials on this machine10:23
richard_mawssam2: yep10:23
richard_mawprobably other ways to trip it, but that's what's happening to me10:23
ssam2ok. 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 +110:24
richard_mawthere's no rush from me, it'll be in my next patch series if it isn't adopted sooner10:24
ssam2ok. since it's now tripped up two people, probably best to have it in as soon as possible10:25
pedroalvarezI don't understand the patch yet :/10:25
ssam2if value is '%d', value_msg is '= %d', and then msg='foo environment variable bar = %d'10:26
Kinnisonrichard_maw: are you trying to fix the distbuild fallout from your previous patches?10:26
ssam2in app.status, it calls msg % args, msg contains a %d but args is empty10:26
richard_mawKinnison: 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 again10:28
pedroalvarezrichard_maw: +110:29
richard_mawtoday is about plugging holes in test-suite coverage that caused my per-source building patches to break things10:31
richard_mawit's just a shame it means that I can't have a go at `morph build $CLUSTER` , inline chunk morphologies or embedded strata10:38
Kinnisonthere's always next week10:38
*** fay_ [] has quit [Ping timeout: 260 seconds]10:44
richard_mawI suppose so, but those are features I've wanted for a while10:44
*** sambishop [] has joined #baserock10:44
KinnisonCan't have fancy new features when the current stuff is broke10:44
* Kinnison is a meanie10:44
Kinnisontbf, you can do whatever you want with your upstream time10:44
Kinnisonbut I'd pout a lot10:44
richard_mawoh I know this is the top priority, just I'd rather do the others tomorrow instead of next week10:45
richard_maw(i.e. 100% time rather than 20% time)10:45
* Kinnison chuckles10:46
*** fay_ [] has joined #baserock10:51
jmacsWe're going to try the upgrade again, so will be rebooted in a few minutes.10:52
* richard_maw goes to lunch10:53
*** fay_ [] has quit [Read error: Connection reset by peer]10:53
*** fay_ [] has joined #baserock10:54 seems to be back :)11:02
pedroalvarezand looks like the new version11:03
violetaunfortunately my BE kernel didn't work, seems like there is a problem with voltage regulators11:04
jmacspedroalvarez to the rescue.11:05
pedroalvarezhehe, I've been monitoring the process11:05
jmacsIt looks like the error with TROVE_GENERIC was the only unexpected problem.11:07
Krinhey 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 this11:10
Krin/dev/mmcblk0p1            3.0G      1.1G      1.7G  39%11:10
Krinjust wondering why it's so small? using the stock installer i can specify the size to be up to 14500MiB11:10
Krinam i missing a trick?11:11
radiofreeuse ROOTFS_SIZE11:12
radiofreewhat exactly are you trying to do?11:12
Krinjust upgrade the jetson to the newer baserock as discribed on the Wiki11:13
paulsher1oodjmacs: congratulations :-)11:13
radiofreehow are you trying to do that?11:14
Krinfollowing those instructions. got all the way up to running the morph before I hit an issue11:14
radiofreeso you're running baserock and it's *morph* complaining about lack of disk space?11:15
radiofreeyou haven't setup /src correctly then11:15
radiofreebaserock 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 sata11:16
radiofreealso that guide assumes someone is already familiar with baserock11:17
radiofree is probably what you need11:17
* paulsher1ood checks the instructions... 11:19
paulsher1oodKrin: did you add the extra src drive as it says?11:20
radiofreeshould probably add a link to there11:20
radiofreesince it doesn't mention you need to setup /etc/morph.conf11:21
* radiofree does that11:21
ssam2i've merged to master, thanks richard_maw11:22
* paulsher1ood wishes the default behaviour without the fiddlings would be friendlier11:22
richard_mawthanks ssam211:23
ssam2and updated definitions.git11:23
richard_mawpaulsher1ood: 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-place11:26
richard_mawso you don't need to fiddle with morph.conf, but there's more stuff to add to /etc/fstab11:26
radiofreelarger root disk isn't an option on the jetson11:27
Krinwhy not radiofree? the nvidia stock installer allows a larger root disk of up to 14GB11:29
richard_mawhm, perhaps we should also have it put /home, /root and /var on the extra disk too11:29
radiofree14G is not enough for baserock11:29
pedroalvarezineed, is not enough11:29
ssam2since we only support running Morph in Baserock, having the default cachedir = /src/cache and default tempdir = /src/tmp wouldn't be crazy11:30
paulsher1oodrichard_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 exist11:30
ssam2that was strange11:30
Krinwell, 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 way11:31
paulsher1oodKrin: whoa11:31
radiofreeKrin: "starting Kernel"?11:31
paulsher1ooddo you have a serial cable?11:31
Krinpaulsher1ood, ?11:31
radiofreeplease paste your logs11:31
paulsher1oodbetter to debug what's going on, then.11:31
radiofreeif you're using screen, control-a + H11:32
radiofreethen reboot the jetson11:32
paulsher1oodwow... so much magic11:32
radiofreethen pastebin the screenlog.* file11:33
radiofree(it will probably be in /root)11:33
radiofreethis is an interesting bug considering u-boot can't actually discover the SSD11:34
radiofreeso please don't reflash11:34
paulsher1oodKrin: ^^ (better to try to diagnose, than loas an hour reflashing to get back to the same or a differnt place)11:34
Krinaye, gabbing the log,11:35
Krinwell 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 appreciated11:37
pedroalvarezKrin: can you use a public pastebin service?11:38
radiofreeoh wow that's special!11:39
paulsher1oodKrin: public version please?11:40
Krin this more appropriate pedroalvarez11:40
radiofreedoes restarting it help?11:40
Krinit does not seem to, but i'm sure if you come and watch me then it will help then and make me a liar11:40
radiofreei don't think there's anything you can do there then, if it's stuck on Starting kernel ... you'll need to reflash11:41
radiofreei wonder what caused that11:41
Krinoh wait, 4 restarts in a row and it's running now... O.o11:42
pedroalvarezrichard_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
radiofreeKrin: yay for "turning it on and off again a few times"11:43
SotKKrin: what did you put in fstab ooi?11:43
pedroalvarezrichard_maw: a "yes" or "no" is enough11:43
Krinlemme open it up and get an exact copy11:43
Krinaside, it's still not got enough space11:43
SotKpedroalvarez: I think that richard_maw told me that that was possible when I was doing the partial deployment stuff11:44
KrinLABEL=src /src btrfs defaults 0 211:44
KrinSotK, ^^11:44
radiofreedid you confirgure morph to use it?11:44
pedroalvarezSotK: great11:45
Krinno, 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 now11:45
paulsher1oodssam2, richard_maw -
paulsher1oodseems to work with no morph.conf, even for a symlink /src. fails nastily if /src doesn't exist, which is ok imo11:52
radiofreewill that cause a spectacular failure if /src doesn't exist?11:52
pedroalvarezmorph works without /src and without morph.conf at the moment11:53
pedroalvarez(if the root disk has space)11:53
paulsher1oodit 'works' in the sense that it won't bork on directories, but won't have enough space to actually build anything by default, i think11:54
Krinthis is likely because i have no idea how to use morph, but i'm now getting this error.11:59
KrinL="my new version"11:59
KrinERROR: Can't find the workspace directory.11:59
KrinMorph must be built and deployed within the system branch checkout within the workspace directory.11:59
KrinL="my new version"11:59
KrinERROR: Can't find the workspace directory.11:59
KrinMorph must be built and deployed within the system branch checkout within the workspace directory.11:59
Krinfull command included this time12:00
CTtpollardmorph init workspace?12:00
Krinwait, why is it not copying the first line... ¬.¬12:00
Krinahh ok12:00
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 245 seconds]12:03
KrinCTtpollard, 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 first12:04
pedroalvarezKrin: creating the workspace is the first step :)12:05
CTtpollardcd into it and retry?12:05
Krintried that CTtpollard12:05
Krinalso had previusly tried making the workspace directory manualy12:05
Krinpedroalvarez, could you tell me where to find steps 2 - X ? :)12:06
pedroalvarezKrin: sure12:07
Krinthank you pedroalvarez :)12:14
richard_mawpaulsher1ood: 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_mawpaulsher1ood: would you be satisfied by released images intended for VM deployments including an /etc/morph.conf?12:33
paulsher1oodrichard_maw: if that could be done, it would be lovely, yes :)12:40
paulsher1oodincidentally, we should try to scrap the whole workspace concept if we can, i think :)12:41
richard_mawok, how do you propose to manage local changes to chunk sources?12:42
paulsher1oodrichard_maw: you mean if we scrapped workspaces?12:42
richard_mawyeah, it's convenient to be able to `morph edit` a chunk, so you can fiddle with it12:43
paulsher1oodi agree... but couldn't that just do its stuff into a sibling directory of the definitions checkout?12:43
richard_mawsomething Kinnison and I discussed was to instead have a morph command that would link the definitions checkout with the chunk checkout12:44
richard_mawit would be a sibling directory, but we'd need a way to tell morph to build using that instead12:44
richard_mawand I'd rather not require people put repo: file:///... and ref: HEAD in themselves12:45
petefothany 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 folder12:52
richard_mawpaulsher1ood 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 that12:54
richard_mawpetefoth: true, but projects involve a lot of tools and sources, we're proposing that morph isn't responsible for workspace management12:55
petefothrichard_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
paulsher1oodpetefoth: 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
richard_mawpetefoth: 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 anyway13:03
* petefoth backs away due to insuffucient context13:04
richard_mawcontext is precisely the problem for having a default workspace :-)13:05
ssam2we 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 Baserock13:09
ssam2it would mean lots of rebuilds and might trigger lots of new issues13:10
paulsher1oodssam2: whay about adding it later (just for *use* in devel, not building devel)... would that allow experimentation in a useful way?13:11
KinnisonInteresting issues could arise wrt. conflicts between 4.7 and 4.8 content13:11
Kinnisonincomplete overlaps fr.ex.13:12
richard_mawyou could do some artifact splitting to make 4.7 a pure build-depend13:13
* petefoth stumbles across 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
petefothCertainly more accessible than the pages I published earlier13:20
ridgerunnerWhoot! the build I started yesterday afternoon has just finished successfully! Now to try a Baserock upgrade.13:22
radiofreewhat's the procedure for building out-of-tree kernel modules in baserock?13:23
pedroalvarezradiofree: let me dig out that infomration13:25
pedroalvarezradiofree: first of all the kenel module has to build depend on the "linux" chunk13:28
pedroalvarezbecause the linux chunk intall the kernel headers13:29
petefothwhere do I find the code for system-version-manager?13:29
petefothpedroalvarez: ta!13:29
pedroalvarezpetefoth: just in case:
ridgerunnerFirst question: on 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
radiofreepedroalvarez: 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 anything13:31
radiofreeridgerunner: i'd suggest reading through first13:31
radiofreespecifically "Upgrading a Baserock installation"13:31
radiofreesame for you Krin13:32
radiofreethe jetson guide assumes some knowledge of how to use baserock13:32
Krini'm doing that at the moment radiofree, bit lost on where to get the files to do the build for the jetson13:32
pedroalvarezradiofree: 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
Krini'v got the one from upgrading baserock installation working, but it quite rightly warns me that it is for the wrong platform13:33
radiofreepedroalvarez: ok i'll give it a go, manually building it for now13:33
ridgerunnerradiofree: thanks, I'll do that. I think that a cross link would be helpful, I'll put one in13:33
radiofreeridgerunner: yep it would, noticed that before13:33
radiofreehave edited it today to point to "configure morph" now though13:33
pedroalvarezradiofree: the morphology to build a moudule should be like this:
ridgerunnerAh, it's askiing me to sign in. What credentials should I use?13:34
radiofreeKrin: what command are you issuing?13:34
pedroalvarezradiofree: btw, this is in x8613:34
paulsher1oodridgerunner: whatever you like13:35
Krinradiofree, 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
Krini have tried the following13:35
radiofreewhy would morph be correct in telling you it's the wrong platform type?13:36
Krinmorph --verbose13:36
Krinbuild base-system-x86_64-generic13:36
Krinobviusly wrong13:36
radiofreeyes, that's wrong13:36
radiofreeyou're trying to build an x86 image on arm13:36
Krinmorph --verbose13:36
Krinbuild base-system-armv7lhf13:36
radiofreedon't do that13:36
KinnisonKrin: The target platform is defined by the system morphology.  What you *can* build is defined by the platform you're on13:36
* paulsher1ood will fix the wiki on this13:36
radiofreedoes morph build  devel-system-armv7lhf-jetson work?13:36
Krinyes radiofree i can see that is wrong, what i cant see is what is right13:37
paulsher1oodridgerunner: stand down :)13:37
Krini'll try that radiofree13:37
ridgerunnerpaulsher1ood: ok.13:37
ridgerunnerat least I got to create a user account :-)13:38
radiofreethere isn't a "base-system-armv7lhf" is there?13:38
Krini dont know, that seemed the most logical to me as it said that was the architecture i was running13:38
radiofreewhat was the error message? it's more helpful if you pastebin logs13:39
radiofreealso will be useful13:40
radiofreeare you using screen?13:46
radiofreessh into the device, makes it easier to copy13:46
radiofreeFile devel-system-armv7lhf-jetson.morph doesn't exist: attempting to infer chunk morph from repo's build system13:47
radiofreeERROR: Couldn't find morphology: devel-system-armv7lhf-jetson.morph13:47
Kinnisonyou might need systems/ on the front of that13:47
Kinnisonmorph needs the full path within the definitions repo IIRC13:47
radiofreewiki needs updating then :\13:47
paulsher1oodi'll do it13:49
Krinsystems/ at the front had no effect Kinnison13:49
SotKKrin: what ref of definitions is this?13:51
KinnisonI happen to have a few mins while a build runs, I'll pop over and see what Krin's up to13:51
SotKany luck?13:57
ssam2it turns out the Chef guys have literally created their own packaging system for the server and the developer kit13:58
ssam2they then use this to generate mega-RPM, mega-.deb, windows installer, etc. packages13:58
ssam2it looks pretty well executed, for what it is13:59
ssam2but, it's basically yet another symptom of how difficult life is for ISVs on every operating system14:00
*** tiagogomes [~tiagogome@] has joined #baserock14:02
radiofreei think this might work14:07
*** sambishop [] has quit [Ping timeout: 272 seconds]14:08
paulsher1oodso my documentation dilemma is this...14:09
paulsher1ooda 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
radiofreeKinnison: was the hdmi working for you?14:11
radiofree(on the jetson)14:11
paulsher1oodi 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
Kinnisonradiofree: yes14:12
Kinnisonradiofree: At least, the console appeared14:13
SotKpaulsher1ood: I think we should do a release14:13
pedroalvarezpaulsher1ood: versioned documentation!14:13
petefothpedroalvarez: +114:14
petefothat least, when we make and review changess we need to consider the impact of the changes on (a subset of) the w.b.o documentation14:14
petefothI don't think we should rely on newcomers not being able to do stuff as the test that we haven't 'broken' the docs14:16
ssam2paulsherwood: I'd rather we did a release14:16
radiofreeKinnison: hmm i don't get anything with this kernel :\14:16
radiofree3.10 i see the console14:16
paulsher1oodi'd be happy to see a release... but iirc persia has some deep concerns about releases in general14:18
Kinnisonradiofree: with the kernel built from my branch?14:18
radiofreeKinnison: yeah14:18
Kinnisonradiofree: with my morphology?14:18
radiofreeplus some other patches though14:18
Kinnisonradiofree: e.g. have you got the right dtb?14:19
radiofreeyep, modified it for the gpu though, that *might* be the problem14:19
* radiofree checks14:19
ssam2paulsher1ood: I think persia recognises the need for us to provide prebuild devel system images14:19
* Kinnison definitely had login prompts on the hdmi14:19
ssam2which is all our release needs to be14:19
pedroalvarezbut he mentioned that the version to download should always be the latest of definitions.git14:21
ridgerunnerQuestion: 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
ridgerunnerThat way I could ssh to it wherever I am, even from home.14:23
Kinnisonthe jetson setup is not a server, so it should be safe for you to attach to whatever network you like14:23
ridgerunnerAnd my laptop wouldn't have to be there acting as a conduit for iternet access14:24
ridgerunnerThanks, that was what I was hoping but I wouldn't want to be responsible for borking the network.14:27
ridgerunnerSo best to ask.14:27
*** sambishop [] has joined #baserock14:30
violetaradiofree, 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
radiofreei dont see why not14:38
paulsher1oodridgerunner: 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
violetaI don't see it either!14:39
dutch is now known as ctdutch14:43
ssam2I love a good profane sed command. 's!^.*/!!'14:44
* rjek blushes14:44
ridgerunnerpaulsher1ood: I suppose it would have been better asked on #tegra but that is usually very quiet14: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
KinnisonE.g. for the 241 seconds it took to build the lsof chunk artifacts, 215s of it was the configure stage14:56
ssam2i've thought before we should look at providing a system-wide 'config.cache' file14:58
ssam2seems that might speed it up. I might misunderstand it, though14:58
KinnisonIt'd be a risky thing given that the cache might be invalidated by new chunks becoming available in the staging area14:59
Kinnisonif each chunk could supply new parts for a cache then we might be able to do something reliable14:59
*** ctdutch [] has quit [Ping timeout: 260 seconds]16:19
*** sambishop [] has quit [Ping timeout: 260 seconds]16:20
*** tiagogomes [~tiagogome@] has quit [Quit: Leaving]16:34
*** jonathanmaw [] has quit [Quit: Leaving]16:38
richard_mawhm, my internet is not happy with me16:39
* richard_maw restarts laptop16:40
*** sambishop [] has joined #baserock16:40
* paulsher1ood has bad internet everywhere today16:48
paulsher1oodhome, office, phone16:48
*** ssam2 [] has quit [Remote host closed the connection]16:53
paulsher1oodbaserockers... any ideas on
paulsher1oodlooks to me like gbo misbehaving?17:08
*** thecorconian [~thecorcon@] has joined #baserock17:13
*** CTtpollard [] has quit [Quit: Ex-Chat]17:42
*** violeta [] has quit [Ping timeout: 272 seconds]17:44
pedroalvarezHm.. Delta/tox doesn't exist in gbo17:58
paulsher1oodah.. python-packages18:02
paulsher1oodmy bad18:02
paulsher1oodwhile you're on...18:02
paulsher1oodmariadb does everything else ok, but is looking for liblzma.a in a strange place i think... we have /usr/lib/liblzma.a18:04
paulsher1ood(it seems we'll need mariadb if we want storyboard)18:05
paulsher1oodi guess i can try --without-plugin=tokudb18:07
*** Krin [] has quit [Ping timeout: 272 seconds]18:18
pedroalvarezWow, I have no idea what's failing there..  :/18:40
paulsher1ood+1 :)18:41
*** thecorconian [~thecorcon@] has quit [Ping timeout: 272 seconds]18:42
*** thecorconian [] has joined #baserock19:00
richard_mawCVE-2014-6271, bash's inheriting functions through the environment will evaluate arbitrary commands19:02
richard_mawrather trivial too, you just need to make a variable's contents start `(){ come command; }`19:03
richard_mawmore difficult to exploit on Baserock than Ubuntu, as we don't use bash for /bin/sh19:06
paulsher1oodrichard_maw: don't you mean, pretty much impossible to exploit on Baserock by default?19:09
*** thecorconian [] has quit [Ping timeout: 272 seconds]19:12
*** thecorconian [] has joined #baserock19:27
*** thecorconian1 [] has joined #baserock19:32
*** thecorconian [] has quit [Remote host closed the connection]19:32
richard_mawpaulsher1ood: possibly, but you'd need an audit to be sure about something like that19:33
richard_mawsince you could have things specifically invoking /bin/bash19:35
richard_mawthe CVE specifically mentions cgi scripts written in bash19:36
paulsher1oodrichard_maw: how would you feel about having morph build run morph gc by default?19:38
*** thecorconian1 [] has quit [Ping timeout: 260 seconds]19:41
richard_mawpaulsher1ood: 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-used19:41
paulsher1oodrichard_maw: issue is, as a user, i'd rather be sure my build happens, than find it didn't through lack of space19:44
richard_mawat 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 storage19:50
paulsher1oodrichard_maw: no, really. every time i run morph build and it stops through lack of space,  i curse it :)19:55
*** thecorconian [] has joined #baserock20:00
richard_mawand I would curse even more when I returned to a build, and discovered it had failed due to lack of space20:03
*** thecorconian [] has quit [Quit: Leaving.]21:59
richard_mawI 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 cmdtests22:34
richard_mawmost of the way through though22:34
richard_mawand now I sleep22:34

Generated by 2.15.3 by Marius Gedminas - find it at!