IRC logs for #baserock for Friday, 2015-06-12

*** zoli___ has quit IRC01:23
*** zoli__ has joined #baserock02:39
*** zoli__ has quit IRC02:50
*** mwilliams_ct has quit IRC03:54
*** mwilliams_ct has joined #baserock03:55
*** zoli__ has joined #baserock06:12
*** zoli__ has quit IRC06:20
*** petefoth has joined #baserock06:26
*** petefoth has quit IRC06:39
paulsherwooderk!06:49
paulsherwoodradiofree: in master?06:51
*** zoli__ has joined #baserock06:56
*** petefoth has joined #baserock07:08
SotKargh, my bad07:32
* SotK fixes it07:32
radiofreeyep, was in master07:35
* SotK had no brain yesterday afternoon07:36
SotKeasiest fix is probably to revert bf6e47a641248f713a64d918c92fb2b17dadbdd307:37
SotKpull request sent07:41
paulsherwoodmerged! thanks :)07:49
paulsherwoodradiofree: apart from that, how is ybd working on arm?07:51
radiofreestill not, looks like an issue with sandbox lib now?07:52
radiofreei'm getting this when trying to build a system07:53
radiofreehttp://fpaste.org/231357/43409560/07:53
radiofreei have a clean /src/cache etc..07:54
*** a1exhughe5 has joined #baserock07:54
paulsherwoodthat's not sandbox, i think... what arch are you trying to build?07:54
radiofreeoops07:54
SotKwhat commandline were you using?07:54
radiofreearmv8l64 not armv8lhf07:54
* radiofree smacks head07:55
paulsherwoodheh!07:55
SotKits a shame that baserock's architecture strings don't match the output of platform.machine()07:55
paulsherwoodi guess we need better validation that arch is possible07:55
paulsherwoodSotK: +107:55
paulsherwoodrjek: why is that?07:55
* paulsherwood doesn't begin to understand the arch string conundrum, but is sure rjek knows it better than most07:56
*** edcragg has joined #baserock07:57
paulsherwoodSotK: what happened on the 'controversial' patch series? is it -1d still?07:57
SotKpaulsherwood: yes :(07:57
paulsherwoodremind me, which repo does this affect?07:57
SotKdefinitions07:57
radiofreei guess it's because we want to be able to say "this is aarch64 little endian", and "aarch64, little endian, hardfloat"07:58
radiofreewhere platform machine would just return aarch6407:58
SotKrichard_maw's strip_commands patches (which now include my patch for setting PYTHONPATH) also need another +1 before the most controversial patch in that series can be merged though07:58
paulsherwoodSotK: is that -1d by anyone?07:59
SotKpaulsherwood: nope07:59
paulsherwoodand that's morph, not definitions?07:59
SotKcorrect08:00
paulsherwoodgerrit link, please?08:00
SotKhttps://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:master+topic:strip-commands08:00
paulsherwoodall of them????08:01
paulsherwoodwith the merge conflicts, too?08:01
SotKthe merge conflicts are probably just Gerrit being weird08:01
paulsherwoodi'm happy to review them, but i have no clue how to deal with gerrit merge conflicts08:02
paulsherwoodis the series order top to bottom (ie first apply top?)08:02
richard_mawpaulsherwood: no, gerrit is bad at displaying things in order08:03
paulsherwooderk08:03
richard_mawpaulsherwood: this is why I switched back to the old UI, since at least the patch view gives dependency information08:03
paulsherwoodi can't help, then. out of my depth again08:03
richard_mawpaulsherwood: I can do the merging, I think we just need another pair of eyes to see if anyone objects to various changes08:04
paulsherwoodrichard_maw: i'm trying. https://gerrit.baserock.org/#/c/778/ has two +1s but no testing... did you test it?08:08
richard_mawpaulsherwood: I did08:09
richard_mawmany times08:09
paulsherwoodok. i see that some of the patches already have 2x+1 ... whats holding them up?08:09
*** jonathanmaw has joined #baserock08:09
rjekpaulsherwood: Why is what sorry?08:10
richard_mawpaulsherwood: someone going through and merging them. There's many of us with the capability to do that, but it's fair to expect the proposer to do it if they have the power.08:10
paulsherwoodrjek: 08:55 < SotK> its a shame that baserock's architecture strings don't match the output of platform.machine()08:10
rjekI have no idea why that might be.  What does platform.machine() return?08:11
KinnisonIt is not a shame at all08:11
paulsherwoodi'm trying to udnerstand the arch string conundrum08:11
KinnisonIt's a shame that platform.machine() doesn't return Baserock's architecture strings08:11
rjekIt sounds like platform.machine() might return what uname() returns, which is not precise enough08:11
KinnisonBaserock's architecture strings are more precise and better constructed08:11
paulsherwoodKinnison: oh, interesting. could/should we implement a version that does?08:12
KinnisonNo08:12
Kinnisonbecause people will be expecting the behaviour of platform.machine()08:12
KinnisonNow, on Debian there's dpkg --print-architecture to tell you the OS name for the system platform08:12
KinnisonPerhaps we need an equivalent teeny tool on baserock08:12
paulsherwoodKinnison: ok, under a different name. could we implement something that returns a properly contstructed strign?08:12
KinnisonYes, you can trivially write a module to do it08:13
paulsherwoodmight it be generally useful?08:13
Kinnisonjust don't monkeypatch it into the python stdlib08:13
paulsherwoodagreed08:13
rjekBasicallym armv8lhf tells you nothing of which of the three instruction sets you might be using.08:14
rjekAnd I *think* the hf is totally redundant.08:15
* paulsherwood can't see which are +2 and which are +1 in gerrit... :/08:15
rjek(I think ARMv8 mandates an FPU)08:15
Kinnisonwe don't say hf08:19
Kinnisonwe say armv8l6408:19
KinnisonIIRC08:19
Kinnisonrichard_maw: if you've not materially changed any patch since I last +1'd it, my +1 stands08:20
paulsherwoodrichard_maw: afaict all of that series now have 2x+1 except SotK's patch. could you review that please?08:20
richard_mawcan do08:20
paulsherwoodtvm :)08:20
rjekKinnison: armv8lhf is what radiofree was mentioning was not armv8l6408:20
richard_mawI'm just wondering whether the changes that request extra documentation should be done now, or as a follow up.08:21
radiofreeyeah i made my own one up...08:21
KinnisonI see08:21
* Kinnison is not good at reading dense scrollback08:21
rjekI don't think we're planning on doing an armv8l16, but still... :)08:22
paulsherwooddo alll the things :)08:22
* paulsherwood is out of time and out of battery. ttyl08:23
*** mariaderidder has joined #baserock08:31
SotK:( https://mason-x86-64.baserock.org/ is red08:37
*** edcragg has quit IRC08:43
richard_mawerlang sd-notify?08:45
richard_mawc_src/sd_notify.c:25:31: fatal error: systemd/sd-daemon.h: No such file or directory08:46
richard_mawthe stratum erlang-sd_notify is in doesn't depend on foundation08:46
KinnisonPresumably this is a case of a removed build-dependency not being properly validated08:47
richard_mawthat was the initial reason for its move out of the erlang stratum and into an openstack one08:47
richard_mawbut it looks like it wasn't validated whether the openstack one had foundation either08:48
franredthat build is pretty old08:48
franredthe fix for this is already in master definitions08:48
franredcommit 93a67f51872288da56363bbe3eec0e530c6d6c1b08:49
franredso it is mason which is building pretty slow08:49
* richard_maw begins merging strip-commands patches08:50
* SotK notes the x86_32 mason is also failing08:50
*** tiagogomes has joined #baserock08:55
* bashrc notices some firehose patches got merged08:56
richard_mawstrip-commands merged, will do wiki updates next09:01
Kinnisonnice09:01
*** ssam2 has joined #baserock09:02
*** ChanServ sets mode: +v ssam209:02
*** gary_perkins has joined #baserock09:09
ssam2jmacs, franred: I'm thinking of going ahead and merging the Java changes  (https://gerrit.baserock.org/#/c/856/1 and related)09:11
ssam2I don't have time to test, but I don't think anything crucial will break anyway09:11
franredssam2, sounds good to me09:11
ssam2one thing -- mind if I edit the commit message of https://gerrit.baserock.org/#/c/758/4 to note that --no-same-owner is needed because of the build sandboxing we do? i'll forget why it's there otherwise09:11
franredjmacs, ^^09:12
*** lachlanmackenzie has joined #baserock09:15
*** edcragg has joined #baserock09:19
franredssam2, I would say that you can go ahead with the addition and merge the patches09:19
jmacsssam2: That's fine by me09:21
ssam2great09:21
jmacsAs I said yesterday, I've only done a build of the two zookeeper systems with those patches, but I am confident they won't break it09:21
richard_mawversion 5 described in wiki09:28
* ssam2 tries to merge JDK patches, breaks Gerrit09:32
Kinnison:(09:33
Kinnisonpoor gerrit09:33
franredoops09:34
*** zoli__ has quit IRC09:50
*** zoli__ has joined #baserock09:50
*** zoli___ has joined #baserock09:51
*** zoli__ has quit IRC09:51
*** mariaderidder has quit IRC09:59
*** mariaderidder has joined #baserock10:11
richard_mawssam2: Does https://gerrit.baserock.org/#/c/857/ cover all the things you wanted comments on for the strip command?10:27
ssam2richard_maw: looks great, thanks10:29
ssam2java improvements are now merged.10:41
ssam2One thing I'd like to do today is merge the outstanding firehose branches to 'master'10:42
ssam2as I understand it, we're not using firehose for anything, but the outstanding patches were all tested by Bob so it makes no sense to keep them sitting around in Gerrit10:42
ssam2especially as they have been reviewed quite a bit now10:42
SotKssam2: that sounds like a sensible idea10:42
ssam2so unless anyone objects, I'll merge the firehose patches from gerrit, and the patches from Lauren that were sent to the mailing list10:42
franredssam2, sounds sensible to me10:43
ssam2oh, seems the baserock/lauren/firehose branch was merged to master of firehose.git already11:02
ssam2no merge commit so i'm not sure who did it11:03
ssam2but nobody seems to actively maintain firehose right now anyway, so whatever11:04
franredssam2, I think wdutch was having a look at it11:04
ssam2he doesn't have a Gitano account on git.baserock.org though, so I doubt it was him11:05
wdutchI am looking at hirehose11:06
wdutchI have no objection to all the patches being merged, I've not looked at them all yet but I don't see how it makes a difference if they're in master or not11:07
ssam2wdutch: cool! have you got it working yet?11:07
* wdutch shakes head11:07
ssam2heh11:07
ssam2I figure there are so many patches in-flight that the easiest option is merge them all, then take stock of what's needed to get it doing useful stuff11:08
wdutchI've spent a lot of time figuring out how cliapp works and how morph does plugins11:08
ssam2oh :(11:08
* Kinnison finds that sad11:08
Kinnisonesp. given that the firehose state when I left it contained scripts to abstract all that away11:08
ssam2in fairness, just because something is "abstracted" doesn't mean one can ignore it11:09
Kinnisonwdutch: If you asked here and I failed to help you, then I sincerely apologise11:09
wdutchI didn't ask11:10
Kinnisonaah11:10
* Kinnison tsks11:10
ssam2if you're going to be working on it for a while, it's probably worth organising a meet in-person with people who are interested in it that can share context and stuff. i'd be happy to spend an hour trying to explain what I understand of it11:11
* Kinnison too11:11
wdutchthat would be useful but I'd need some time to organise my thoughts first11:11
ssam2fair enough11:12
radiofreetoday ybd deployment bug: no deployment.meta file breaks deployment when using things like DTB_PATH, kernel args etc...11:28
radiofreesince there's no deployment.meta file for system-version-manager to use11:28
ssam2we really need to define that interface somewhere...11:39
ssam2i'm not sure the metadata format belongs in http://wiki.baserock.org/definitions/current/11:40
ssam2alternately, the requirements of system-version-manager could be documented here: http://wiki.baserock.org/guides/upgrades/#index7h211:40
ssam2where the requirements are: btrfs, a /baserock/deployment.meta file formatted a certain way, and Python11:40
ssam2(and maybe other stuff I'm missing_)11:41
* ssam2 gets bitten by the fact that YBD doesn't warn if a .morph file doesn't actually exist11:53
*** nowster has quit IRC11:54
ssam2wow, seems when I add the missing .morph file YBD doesn't rebuild the chunk, either11:57
perryl:(11:58
SotKthat sounds bad11:58
ssam2oh, false alarm12:00
ssam2it did rebuild the chunk, but the chunk is still broken :)12:00
* SotK stops worrying12:00
perrylssam2: i got `make: *** [busybox_unstripped] Error 1`, is that what you got?12:01
ssam2still trying to get ybd to find libfaketime... it's present in the staging area now, but something is still going wrong12:03
ssam2seems this['sandbox'] is ''12:03
perryl:(12:03
* ssam2 breaks out pdb12:04
ssam2ah... the problem is os.path.join12:04
ssam2os.path.join has this fucking stupid behaviour where if you do os.path.join('foo, 'bar', '/usr') it returns '/usr'12:05
ssam2i'm pretty sure I make this mistake every week12:05
*** nowster has joined #baserock12:05
SotK:(12:05
richard_mawI'd guess the reason is that it would be how it would work if you successively chdir'd into each argument, but I agree, it's never what I want.12:06
Kinnisonit's exactly what I'd expect12:06
Kinnisonand frankly exactly what I'd want12:06
Kinnisonsince otherwise you'd need special casing12:06
KinnisonIt's also well documented12:07
ssam2php is well documented too12:08
ssam2perryl: ok, i've managed to reproduce the build failure of busybox with libfaketime under ybd now!12:08
perrylhooray! ish12:08
ssam2does seem like it's trying to link in modules that it never actually built.. very strange12:09
ssam2the error is http://paste.baserock.org/oyosirapoj by the way12:12
richard_mawooh, I see patches to rawdisk.write to add partitioning support12:13
ssam2perryl: right, I think part of the problem is that sandboxlib sets the LD_PRELOAD environment outside the linux-user-chroot command, which won't work12:35
ssam2oh. hmm12:35
ssam2it logs an error when it runs linux-user-chroot, but it doesn't prevent libfaketime being preloaded for things run inside the chroot12:36
ssam2so faketime is actually working inside the staging area. But i'm still not sure why that is breaking busybox's build12:37
ssam2I hoped setting the mtime of all the files to match the fake timestamp , but it hasn't12:37
ssam2+would work12:37
ssam2i'll try eating some food, maybe that will help12:38
richard_mawedcragg: I lack the context to understand what all the SoCFPGA patches are for12:50
richard_mawedcragg: Also, I'm unsure of where the code for rawdisk.write lives, I don't know whether some of your changes are applied to the right place12:51
richard_mawedcragg: So I'm going to do just a code review for now.12:52
SotKrichard_maw: it lives in definitions.git/extensions/rawdisk.write12:53
richard_mawI see changes to both baserock/baserock/morph and baserock/baserock/definitions on gerrit12:53
richard_mawah, these patches have been consolidated too12:54
SotKyeah, that branch also changes writeexts.py, which at the moment is living in morph.git still12:54
richard_mawok, I think edcragg or someone with more permissions needs to drop the old versions targetting morph.git then12:55
SotKthat sounds sensible12:55
* SotK sends a patch to update morph in definitions13:07
richard_mawhmm, can't do anything with the rawdisk.write patch at the moment, because most of the change is in writeexts.py, which is in the process of moving13:12
jmacsWhat's the purpose of the <morph name>.inst directory in the staging area?13:25
richard_mawthat's what $DESTDIR points to13:25
richard_mawwhich then gets tarred up to be a later artifact13:26
jmacshmm, but in stage2-* components, everything ends up in /tools/bin, rather than /stage2-*.inst, doesn't it?13:26
Kinnisonyes, the .inst is the *base* of the destdir13:27
Kinnisonso anything in .inst/foo ends up in /foo in the target13:27
jmacsIs there another hidden stage that moves everything from .inst to tools then?13:28
jmacs.inst doesn't include tools13:28
KinnisonBy the time install-commands are complete, it should13:28
Kinnisononce the build/install is complete, the tooling collects up the content of the .inst directory and stores it as the artifact13:29
Kinnisonthen when it puts the artifact into a build-tree for another build, it unpacks it at the base of the new staging area13:29
jmacsOK, so my problem is that my binaries are in .inst and not in /tools; I thought I would be installing to /tools directory13:47
jmacsdirectly*13:47
jmacsI have stage2-zip.inst/409PREFIX/bin/zip13:48
jmacsWhatever 409PREFIX is, it doesn't look good13:48
jmacsHmm, process number?13:48
jmacsLeave me to have a fiddle with definitions for a bit13:48
radiofreelooks like you didn't use $PREFIX?13:49
jmacsI think I used $$PREFIX13:49
radiofreeor maybe $PREFIX got set to 409PREFIX somehow...13:50
richard_maw$$ expands to a process ID13:50
radiofreeheh13:50
jmacsExactly.13:50
radiofreethere you go then13:50
* rjek remembers the nightmare of using expect and having to escape three times in three different ways when dealing with such horrors13:50
richard_mawcould be worse, you could be trying to put $ORIGIN into an rpath13:51
richard_mawI think that involves 4 levels of escaping13:52
rjekeugh13:52
rjekBut tcl escaping is different from sh escaping, leading to additional excitement.13:53
richard_mawMake escaping is different from shell escaping, so there's still that fun with $ORIGIN13:59
ssam2mason-x86-32.baserock.org is red: https://mason-x86-32.baserock.org/log/ade2a2957bdd7481237f35fde6dcf06bd2f7cbaf--2015-06-12%2013:52:26.log13:59
ssam2seems to be a build error in 'gfcomplete'13:59
* Kinnison doubletakes14:01
* Kinnison phews14:01
SotKKinnison: ?14:02
* Kinnison maintains a library called 'libgfshare' which exposes, among other things, 'gfsplit' and 'gfcombine'14:02
* Kinnison misread 'gfcomplete' as 'gfcombine' at first14:03
SotKaha!14:03
* Kinnison was simultaneously worried that (a) baserock was using libgfshare without me realising it, and (b) that there was a bug in it14:04
kejiahu_with same defintion, YBD and morph build different systems on armv7. YBD results roughly 1G, but morph results 120M14:12
Kinnisonminimal system?14:13
kejiahu_yes, 120M should be reasonable14:13
Zaramaybe there's no artifact-splitting in YBD?14:14
kejiahu_as I simply used bsp-jetson without any stripping14:14
ssam2there's no artifact splitting in YBD, indeed14:14
Kinnisonybd is not a full implementation of what we still don't know definitions to mean :)14:15
paulsherwoodbwh: what have you been saying? :-) http://lists.linuxfoundation.org/pipermail/automotive-discussions/2015-June/000421.html14:16
bwhI don't remember14:16
paulsherwoodi wonder when you spoke to folks were you speaking as 'Codthink's bwh' "Debian's bwh' or just bwh? :-)14:17
paulsherwoodanyway i'm happy that the discussion is happening, and as 'Codehink's paulsherwood' 'GENIVI's Paul Sherwood' and devcurmudgeon i will have to reply once i have time to understand the details :)14:18
bwhCertainly not as Codethink's bwh14:18
paulsherwoodunderstood. i'll correct that for you when i reply, unless you'd rather i didn't?14:19
paulsherwoodbaserockers - sorry for the noise -this is tyhe only public channel where bwh and currently overlap, i think14:20
*** zoli___ has quit IRC14:20
Kinnisonit's amazing how well /msg works14:20
Kinnison:)14:20
bwhpaulsherwood: Yes, fine14:20
bashrcdoes that make me "Coethink's bashrc' ?14:21
paulsherwoodKinnison: where's the fun in that? and i know some baserockers are actually interested in the debian/genivi/agl discussion :-)14:21
Kinnison:)14:21
bwhActually it's cc'd to me14:21
paulsherwoodbashrc: if you like :)14:26
paulsherwoodhttp://lists.linuxfoundation.org/pipermail/automotive-discussions/2015-June/000422.html14:42
jmacsOoh, I think gcj just built.14:46
Kinnisonooooh14:46
rjekooh14:46
paulsherwoodooooo:)14:47
rjekThat's a lot of halos on your head, paulsherwood.14:47
rjekOne is normally enough.14:47
Kinnisonrjek: perhaps paulsherwood is a conehead and those are the donuts he stores there14:47
* persia ponders a game of tower-of-hanoi14:48
paulsherwoodjmacs: key question... morph or ybd? :)14:48
Kinnisonpersia: after I solved that in Zeus' equivalent of mod_rewrite, returning a server-push animated GIF I got bored14:48
paulsherwoodor both?14:48
rjekjmacs: Say bitbake.14:48
jmacspaulsherwood: morph for now - I did use ybd earlier in the week, and had identical results14:48
jmacsThis is all definitions work14:49
paulsherwoodcool!14:49
jmacsPity everything relies on gcc, so I'll have to wait for a full build14:58
SotKDoes anyone have any idea why gf-complete is failing on mason-x86_32? https://mason-x86-32.baserock.org/log/4f1e6e133d63a415d08126768aa7680de986d89f--2015-06-12%2015:12:13.log15:19
SotKfranred maybe? ^^15:19
franredSotK, no, no idea, but I can have a look at it15:21
* SotK also wonders if anyone has an idea how close mason-x86_64 is to finishing the build it seems to have started almost 48 hours ago15:22
radiofree:\15:26
*** zoli__ has joined #baserock15:26
radiofreei think pedroalvarez can read those particular mason runes15:26
SotKindeed, but I don't think he's around :/15:27
* SotK would guess anyone on the ops team can, but may be wrong15:27
franredSotK, gf-complete builds in a x86_64 devel machine15:28
SotKhmm, must be a problem with x86_32 only then :/15:28
*** zoli__ has quit IRC15:28
SotKfranred: thanks for investigating15:28
* SotK is stuck building things from way before gf-complete :(15:29
ssam2https://mason-x86-32.baserock.org/log/4f1e6e133d63a415d08126768aa7680de986d89f--2015-06-12%2015:12:13.log isn't 'runes', it's an actual log of the build failure15:30
ssam2the chunk is just broken on x86_3215:30
* SotK thought radiofree was referring to where the x86_64 build is up to15:30
franredyes, I think _mm_insert_epi64 <-- this 64 is very suspicious15:31
SotKindeed15:31
radiofreeSotK: that is what i meant15:32
franredI wondering why we are using a branch for it15:34
paulsherwoodjmacs: what are you trying to verify?15:35
franredstraycat, do you remember why we are using v2 branch for gf-complete in the swift stratum?15:35
jmacspaulsherwood: I need a system with gcj in it, it's part of the requirements to build IcedTea15:35
paulsherwoodjmacs: reason i ask is you could maybe grab a fast VM on something and run your job there. eg AWS or DC OpenStacK?15:36
franredstraycat, never mind, master does use the same15:36
jmacspaulsherwood: Not really worth the extra complication. I've got plenty of other stuff to research in the meantime.15:37
paulsherwoodok np15:37
jmacsGood suggestion, though15:37
*** a1exhughe5 has quit IRC15:38
* franred wonders if adding --disable-sse to the configure in gf-compete will fix the error ;-)15:41
paulsherwoodradiofree: does self-upgrade with ybd work now?15:56
radiofreesure15:56
paulsherwoodw00t!15:56
paulsherwoodon which kit have you tried?15:56
radiofreejetson15:56
radiofreeit probably would have worked on x86 anyway, since you don't need anything special there15:57
radiofreehowever on things like the jetson where you need to pass device tree information etc.. it wouldn't15:57
radiofreebut now does15:57
paulsherwoodinteresting... i think i managed to do it on x86 a month or so ago, without a manifest15:57
paulsherwoodright15:57
* paulsherwood does another little jig :-)15:58
paulsherwoodcross-bootstrap next :-)15:58
ssam2here is the first patch from attempts to make things bit-for-bit reproducible: https://gerrit.baserock.org/#/c/859/15:59
ssam2the main discovery this week has been that 'faketime' breaks build systems, though, and isn't usable as a general solution15:59
tlsastill don't see why it worked with my manual builds, but not as part of the ybd build16:00
ssam2the breakage in Busybox was to do with config/autoconf.h not being regenerated after changes to .config16:01
ssam2so if your build tree was in a state where config/autoconf.h matched .config, or .config had a newer timestamp than include/autoconf.h, you'd not have seen the linker issue that you saw when building it from definitions with YBD16:01
paulsherwoodssam2: with that patch, how far up the stack can be shown b4b?16:10
paulsherwoodssam2: interesting about libfaketime. how/why does it break buildystems? could that be written up for the lsit?16:12
ssam2i'm not sure, i've only been involved in this the last couple of days, and there's no test infrastructure to help with doing such measurements yet16:12
*** CTtpollard has quit IRC16:13
ssam2i'll write up about faketime on the wiki16:13
ssam2I know that with that patch, busybox is bit for bit except for the /baserock/busybox.meta file16:13
ssam2which contains 'elapsed_time'16:13
paulsherwoodwiki - even better :)16:13
paulsherwoodssam2: bug in my thinking there, then - need to have elapsed_time in the log, not the metafile i think16:14
ssam2sotk: fyi mason-x86-64 is building 'mesa' right now16:16
* SotK wonders what's taking it so long16:17
ssam2if you feel like debugging, I can give you access :)16:19
* SotK doesn't feel enthused at the idea of looking at distbuild logs at this time on a Friday :)16:21
ssam2this http://paste.baserock.org/yonokabose looks suspicious (from mason-x86-64.baserock.org)16:22
ssam2no, I guess that's how it always worked16:22
* paulsherwood considers offering a prize for the most exciting/interesting demo video of ybd in action... but maybe it's too early for that, since ybd hasn't been 'released' yet :)16:43
ssam2you said yourself that build systems are boring, though16:44
paulsherwoodi know. hence the need for exciting videos.16:44
paulsherwoodybd is not a build system, though :-)16:44
ssam2what is it, then?16:44
paulsherwoodfrom the readme ... 'ybd is a tool for integrating software stacks.'16:45
rjekWhat does that mean?16:45
paulsherwoodrjek: excactly16:46
DavePageIt means it's not a build system, obviously :)16:46
* richard_maw is all reviewed-out after reading through the rawdisk.write series16:47
rjekIt's a thing for building and combining other people's awful stuff16:47
paulsherwoodi'm working on a submission for elce - if anyone can explain it in different words, pleas let me know :)16:47
rjekpaulsherwood: ^16:47
paulsherwoodROFL16:47
robtaylorpaulsherwood: s/stacks//16:48
paulsherwoodrobtaylor: why?16:48
rjekBecause stacks means nothing16:49
paulsherwoodsoftware on its own is too nebulous imo?16:49
rjekso's what the tool does16:49
paulsherwoodrjek: really? doesn't the readme spell it out quite precisely?16:50
robtaylorpaulsherwood: maybe 'ybd is a tool for reliably integrating software' ? :)16:50
rjekIf you're having trouble defining what it does in a short sentence, I think that demonstrates that it's a bit nebulous :)16:50
paulsherwoodrobtaylor: yes16:50
paulsherwoodrjek: define debian in a short sentence?16:50
paulsherwoodbut i take your point16:51
rjekpaulsherwood: 20,000 pre-packaged pieces of software tested to work well with each other.16:51
paulsherwoodrjek: nicely done16:51
paulsherwoodnot sure that's accurate, though... others have claimed 35,000 and i don't know that it's all cross-tested?16:52
robtaylorpaulsherwood: but in answer to 'why not stacks'  becasue its about integrating for delivery, which means it integrates software that uses stacks too.16:52
paulsherwoodrobtaylor: ah, i get your point16:52
paulsherwoodthanks16:52
robtaylornp :)16:52
paulsherwood'ybd is a tool to integrate software collections for delivery' ?16:54
rjekeugh16:55
paulsherwoodrjek: :-)16:56
*** jonathanmaw has quit IRC16:56
rjekGo the whole hog: "ybd is a workflow toolset enabling cost-reduced reproducable synergy between software stacks, open and proprietary alike"16:57
* rjek sets fire to himself16:57
radiofreeneeds more cloud16:57
rjekAdd "cloud-ready" :)16:58
rjekAdd it anywhere, it doesn't matter16:58
Kinnisoncloud-enabled sounds better16:59
paulsherwoodhttps://twitter.com/codethink/status/60940462124158976016:59
rjekSickening, paulsherwood.17:00
radiofree:)17:00
rjekYou missed the cloud-ready bit17:00
* Kinnison blocks @codethink and reports it for spam17:00
radiofreerjek: he didn't!17:00
rjekOK, it's been a long day.17:00
rjekCan we pub now?17:00
paulsherwoodrjek: you mis-spelled reproducible, btw :)17:00
rjekMy spelling of repoducable is not repruducable.17:01
paulsherwoodrjek: go pub, with my best wishes :-)17:01
* paulsherwood decides that any and all ybd demo videos, no matter how boring, will receive a prize. however there may be a correlation between the entertainment content of the video, and the prize it lands :-)17:11
*** edcragg has quit IRC17:14
*** ssam2 has quit IRC17:16
*** mariaderidder has quit IRC17:24
*** nowster has quit IRC17:26
*** gary_perkins has quit IRC17:30
*** tiagogomes has quit IRC17:33
*** lachlanmackenzie has quit IRC18:15
* Kinnison ponders streaming a live code review18:23
paulsherwoodKinnison:  that would be great, actually, if you think it's worth your time?18:26
*** zoli__ has joined #baserock18:29
KinnisonSadly I have a weekend of university work todo, so perhaps you ahve a chance to tidy up a bit first :-)18:29
paulsherwoodheh18:31
paulsherwoodKinnison: what are you studying these days?18:31
KinnisonCurrently a concurrency/distributed systems thing18:31
KinnisonIt's a little crunchy currently, but I hope there'll be something worth sinking my teeth into toward the end of it18:32
paulsherwood:)18:32
KinnisonStill, it'll make for an interesting additional topic on the final record18:33
KinnisonBasic CS, maths, psychology, AI, music, and now distributed systems18:33
* Kinnison hopes his degree manages to finish :)18:33
paulsherwoodthat's quite a mix :)18:33
KinnisonWell, I can't do something boring18:34
*** zoli__ has quit IRC18:34
* Kinnison thinks he's going to go plan his next controversial blog posting18:34
*** edcragg has joined #baserock19:46
*** paulw has quit IRC20:07
*** dabukalam has quit IRC20:07
*** bwh has quit IRC20:07
*** bwh has joined #baserock20:07
*** paulw has joined #baserock20:08
*** dabukalam has joined #baserock20:09
*** edcragg has quit IRC20:23
*** edcragg has joined #baserock20:43
*** edcragg has quit IRC21:35
*** edcragg has joined #baserock21:37
*** edcragg has quit IRC22:33
*** edcragg has joined #baserock22:35

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!