| *** zoli___ has quit IRC | 01:23 | |
| *** zoli__ has joined #baserock | 02:39 | |
| *** zoli__ has quit IRC | 02:50 | |
| *** mwilliams_ct has quit IRC | 03:54 | |
| *** mwilliams_ct has joined #baserock | 03:55 | |
| *** zoli__ has joined #baserock | 06:12 | |
| *** zoli__ has quit IRC | 06:20 | |
| *** petefoth has joined #baserock | 06:26 | |
| *** petefoth has quit IRC | 06:39 | |
| paulsherwood | erk! | 06:49 |
|---|---|---|
| paulsherwood | radiofree: in master? | 06:51 |
| *** zoli__ has joined #baserock | 06:56 | |
| *** petefoth has joined #baserock | 07:08 | |
| SotK | argh, my bad | 07:32 |
| * SotK fixes it | 07:32 | |
| radiofree | yep, was in master | 07:35 |
| * SotK had no brain yesterday afternoon | 07:36 | |
| SotK | easiest fix is probably to revert bf6e47a641248f713a64d918c92fb2b17dadbdd3 | 07:37 |
| SotK | pull request sent | 07:41 |
| paulsherwood | merged! thanks :) | 07:49 |
| paulsherwood | radiofree: apart from that, how is ybd working on arm? | 07:51 |
| radiofree | still not, looks like an issue with sandbox lib now? | 07:52 |
| radiofree | i'm getting this when trying to build a system | 07:53 |
| radiofree | http://fpaste.org/231357/43409560/ | 07:53 |
| radiofree | i have a clean /src/cache etc.. | 07:54 |
| *** a1exhughe5 has joined #baserock | 07:54 | |
| paulsherwood | that's not sandbox, i think... what arch are you trying to build? | 07:54 |
| radiofree | oops | 07:54 |
| SotK | what commandline were you using? | 07:54 |
| radiofree | armv8l64 not armv8lhf | 07:54 |
| * radiofree smacks head | 07:55 | |
| paulsherwood | heh! | 07:55 |
| SotK | its a shame that baserock's architecture strings don't match the output of platform.machine() | 07:55 |
| paulsherwood | i guess we need better validation that arch is possible | 07:55 |
| paulsherwood | SotK: +1 | 07:55 |
| paulsherwood | rjek: why is that? | 07:55 |
| * paulsherwood doesn't begin to understand the arch string conundrum, but is sure rjek knows it better than most | 07:56 | |
| *** edcragg has joined #baserock | 07:57 | |
| paulsherwood | SotK: what happened on the 'controversial' patch series? is it -1d still? | 07:57 |
| SotK | paulsherwood: yes :( | 07:57 |
| paulsherwood | remind me, which repo does this affect? | 07:57 |
| SotK | definitions | 07:57 |
| radiofree | i guess it's because we want to be able to say "this is aarch64 little endian", and "aarch64, little endian, hardfloat" | 07:58 |
| radiofree | where platform machine would just return aarch64 | 07:58 |
| SotK | richard_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 though | 07:58 |
| paulsherwood | SotK: is that -1d by anyone? | 07:59 |
| SotK | paulsherwood: nope | 07:59 |
| paulsherwood | and that's morph, not definitions? | 07:59 |
| SotK | correct | 08:00 |
| paulsherwood | gerrit link, please? | 08:00 |
| SotK | https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:master+topic:strip-commands | 08:00 |
| paulsherwood | all of them???? | 08:01 |
| paulsherwood | with the merge conflicts, too? | 08:01 |
| SotK | the merge conflicts are probably just Gerrit being weird | 08:01 |
| paulsherwood | i'm happy to review them, but i have no clue how to deal with gerrit merge conflicts | 08:02 |
| paulsherwood | is the series order top to bottom (ie first apply top?) | 08:02 |
| richard_maw | paulsherwood: no, gerrit is bad at displaying things in order | 08:03 |
| paulsherwood | erk | 08:03 |
| richard_maw | paulsherwood: this is why I switched back to the old UI, since at least the patch view gives dependency information | 08:03 |
| paulsherwood | i can't help, then. out of my depth again | 08:03 |
| richard_maw | paulsherwood: I can do the merging, I think we just need another pair of eyes to see if anyone objects to various changes | 08:04 |
| paulsherwood | richard_maw: i'm trying. https://gerrit.baserock.org/#/c/778/ has two +1s but no testing... did you test it? | 08:08 |
| richard_maw | paulsherwood: I did | 08:09 |
| richard_maw | many times | 08:09 |
| paulsherwood | ok. i see that some of the patches already have 2x+1 ... whats holding them up? | 08:09 |
| *** jonathanmaw has joined #baserock | 08:09 | |
| rjek | paulsherwood: Why is what sorry? | 08:10 |
| richard_maw | paulsherwood: 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 |
| paulsherwood | rjek: 08:55 < SotK> its a shame that baserock's architecture strings don't match the output of platform.machine() | 08:10 |
| rjek | I have no idea why that might be. What does platform.machine() return? | 08:11 |
| Kinnison | It is not a shame at all | 08:11 |
| paulsherwood | i'm trying to udnerstand the arch string conundrum | 08:11 |
| Kinnison | It's a shame that platform.machine() doesn't return Baserock's architecture strings | 08:11 |
| rjek | It sounds like platform.machine() might return what uname() returns, which is not precise enough | 08:11 |
| Kinnison | Baserock's architecture strings are more precise and better constructed | 08:11 |
| paulsherwood | Kinnison: oh, interesting. could/should we implement a version that does? | 08:12 |
| Kinnison | No | 08:12 |
| Kinnison | because people will be expecting the behaviour of platform.machine() | 08:12 |
| Kinnison | Now, on Debian there's dpkg --print-architecture to tell you the OS name for the system platform | 08:12 |
| Kinnison | Perhaps we need an equivalent teeny tool on baserock | 08:12 |
| paulsherwood | Kinnison: ok, under a different name. could we implement something that returns a properly contstructed strign? | 08:12 |
| Kinnison | Yes, you can trivially write a module to do it | 08:13 |
| paulsherwood | might it be generally useful? | 08:13 |
| Kinnison | just don't monkeypatch it into the python stdlib | 08:13 |
| paulsherwood | agreed | 08:13 |
| rjek | Basicallym armv8lhf tells you nothing of which of the three instruction sets you might be using. | 08:14 |
| rjek | And 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 |
| Kinnison | we don't say hf | 08:19 |
| Kinnison | we say armv8l64 | 08:19 |
| Kinnison | IIRC | 08:19 |
| Kinnison | richard_maw: if you've not materially changed any patch since I last +1'd it, my +1 stands | 08:20 |
| paulsherwood | richard_maw: afaict all of that series now have 2x+1 except SotK's patch. could you review that please? | 08:20 |
| richard_maw | can do | 08:20 |
| paulsherwood | tvm :) | 08:20 |
| rjek | Kinnison: armv8lhf is what radiofree was mentioning was not armv8l64 | 08:20 |
| richard_maw | I'm just wondering whether the changes that request extra documentation should be done now, or as a follow up. | 08:21 |
| radiofree | yeah i made my own one up... | 08:21 |
| Kinnison | I see | 08:21 |
| * Kinnison is not good at reading dense scrollback | 08:21 | |
| rjek | I don't think we're planning on doing an armv8l16, but still... :) | 08:22 |
| paulsherwood | do alll the things :) | 08:22 |
| * paulsherwood is out of time and out of battery. ttyl | 08:23 | |
| *** mariaderidder has joined #baserock | 08:31 | |
| SotK | :( https://mason-x86-64.baserock.org/ is red | 08:37 |
| *** edcragg has quit IRC | 08:43 | |
| richard_maw | erlang sd-notify? | 08:45 |
| richard_maw | c_src/sd_notify.c:25:31: fatal error: systemd/sd-daemon.h: No such file or directory | 08:46 |
| richard_maw | the stratum erlang-sd_notify is in doesn't depend on foundation | 08:46 |
| Kinnison | Presumably this is a case of a removed build-dependency not being properly validated | 08:47 |
| richard_maw | that was the initial reason for its move out of the erlang stratum and into an openstack one | 08:47 |
| richard_maw | but it looks like it wasn't validated whether the openstack one had foundation either | 08:48 |
| franred | that build is pretty old | 08:48 |
| franred | the fix for this is already in master definitions | 08:48 |
| franred | commit 93a67f51872288da56363bbe3eec0e530c6d6c1b | 08:49 |
| franred | so it is mason which is building pretty slow | 08:49 |
| * richard_maw begins merging strip-commands patches | 08:50 | |
| * SotK notes the x86_32 mason is also failing | 08:50 | |
| *** tiagogomes has joined #baserock | 08:55 | |
| * bashrc notices some firehose patches got merged | 08:56 | |
| richard_maw | strip-commands merged, will do wiki updates next | 09:01 |
| Kinnison | nice | 09:01 |
| *** ssam2 has joined #baserock | 09:02 | |
| *** ChanServ sets mode: +v ssam2 | 09:02 | |
| *** gary_perkins has joined #baserock | 09:09 | |
| ssam2 | jmacs, franred: I'm thinking of going ahead and merging the Java changes (https://gerrit.baserock.org/#/c/856/1 and related) | 09:11 |
| ssam2 | I don't have time to test, but I don't think anything crucial will break anyway | 09:11 |
| franred | ssam2, sounds good to me | 09:11 |
| ssam2 | one 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 otherwise | 09:11 |
| franred | jmacs, ^^ | 09:12 |
| *** lachlanmackenzie has joined #baserock | 09:15 | |
| *** edcragg has joined #baserock | 09:19 | |
| franred | ssam2, I would say that you can go ahead with the addition and merge the patches | 09:19 |
| jmacs | ssam2: That's fine by me | 09:21 |
| ssam2 | great | 09:21 |
| jmacs | As 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 it | 09:21 |
| richard_maw | version 5 described in wiki | 09:28 |
| * ssam2 tries to merge JDK patches, breaks Gerrit | 09:32 | |
| Kinnison | :( | 09:33 |
| Kinnison | poor gerrit | 09:33 |
| franred | oops | 09:34 |
| *** zoli__ has quit IRC | 09:50 | |
| *** zoli__ has joined #baserock | 09:50 | |
| *** zoli___ has joined #baserock | 09:51 | |
| *** zoli__ has quit IRC | 09:51 | |
| *** mariaderidder has quit IRC | 09:59 | |
| *** mariaderidder has joined #baserock | 10:11 | |
| richard_maw | ssam2: Does https://gerrit.baserock.org/#/c/857/ cover all the things you wanted comments on for the strip command? | 10:27 |
| ssam2 | richard_maw: looks great, thanks | 10:29 |
| ssam2 | java improvements are now merged. | 10:41 |
| ssam2 | One thing I'd like to do today is merge the outstanding firehose branches to 'master' | 10:42 |
| ssam2 | as 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 Gerrit | 10:42 |
| ssam2 | especially as they have been reviewed quite a bit now | 10:42 |
| SotK | ssam2: that sounds like a sensible idea | 10:42 |
| ssam2 | so unless anyone objects, I'll merge the firehose patches from gerrit, and the patches from Lauren that were sent to the mailing list | 10:42 |
| franred | ssam2, sounds sensible to me | 10:43 |
| ssam2 | oh, seems the baserock/lauren/firehose branch was merged to master of firehose.git already | 11:02 |
| ssam2 | no merge commit so i'm not sure who did it | 11:03 |
| ssam2 | but nobody seems to actively maintain firehose right now anyway, so whatever | 11:04 |
| franred | ssam2, I think wdutch was having a look at it | 11:04 |
| ssam2 | he doesn't have a Gitano account on git.baserock.org though, so I doubt it was him | 11:05 |
| wdutch | I am looking at hirehose | 11:06 |
| wdutch | I 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 not | 11:07 |
| ssam2 | wdutch: cool! have you got it working yet? | 11:07 |
| * wdutch shakes head | 11:07 | |
| ssam2 | heh | 11:07 |
| ssam2 | I 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 stuff | 11:08 |
| wdutch | I've spent a lot of time figuring out how cliapp works and how morph does plugins | 11:08 |
| ssam2 | oh :( | 11:08 |
| * Kinnison finds that sad | 11:08 | |
| Kinnison | esp. given that the firehose state when I left it contained scripts to abstract all that away | 11:08 |
| ssam2 | in fairness, just because something is "abstracted" doesn't mean one can ignore it | 11:09 |
| Kinnison | wdutch: If you asked here and I failed to help you, then I sincerely apologise | 11:09 |
| wdutch | I didn't ask | 11:10 |
| Kinnison | aah | 11:10 |
| * Kinnison tsks | 11:10 | |
| ssam2 | if 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 it | 11:11 |
| * Kinnison too | 11:11 | |
| wdutch | that would be useful but I'd need some time to organise my thoughts first | 11:11 |
| ssam2 | fair enough | 11:12 |
| radiofree | today ybd deployment bug: no deployment.meta file breaks deployment when using things like DTB_PATH, kernel args etc... | 11:28 |
| radiofree | since there's no deployment.meta file for system-version-manager to use | 11:28 |
| ssam2 | we really need to define that interface somewhere... | 11:39 |
| ssam2 | i'm not sure the metadata format belongs in http://wiki.baserock.org/definitions/current/ | 11:40 |
| ssam2 | alternately, the requirements of system-version-manager could be documented here: http://wiki.baserock.org/guides/upgrades/#index7h2 | 11:40 |
| ssam2 | where the requirements are: btrfs, a /baserock/deployment.meta file formatted a certain way, and Python | 11: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 exist | 11:53 | |
| *** nowster has quit IRC | 11:54 | |
| ssam2 | wow, seems when I add the missing .morph file YBD doesn't rebuild the chunk, either | 11:57 |
| perryl | :( | 11:58 |
| SotK | that sounds bad | 11:58 |
| ssam2 | oh, false alarm | 12:00 |
| ssam2 | it did rebuild the chunk, but the chunk is still broken :) | 12:00 |
| * SotK stops worrying | 12:00 | |
| perryl | ssam2: i got `make: *** [busybox_unstripped] Error 1`, is that what you got? | 12:01 |
| ssam2 | still trying to get ybd to find libfaketime... it's present in the staging area now, but something is still going wrong | 12:03 |
| ssam2 | seems this['sandbox'] is '' | 12:03 |
| perryl | :( | 12:03 |
| * ssam2 breaks out pdb | 12:04 | |
| ssam2 | ah... the problem is os.path.join | 12:04 |
| ssam2 | os.path.join has this fucking stupid behaviour where if you do os.path.join('foo, 'bar', '/usr') it returns '/usr' | 12:05 |
| ssam2 | i'm pretty sure I make this mistake every week | 12:05 |
| *** nowster has joined #baserock | 12:05 | |
| SotK | :( | 12:05 |
| richard_maw | I'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 |
| Kinnison | it's exactly what I'd expect | 12:06 |
| Kinnison | and frankly exactly what I'd want | 12:06 |
| Kinnison | since otherwise you'd need special casing | 12:06 |
| Kinnison | It's also well documented | 12:07 |
| ssam2 | php is well documented too | 12:08 |
| ssam2 | perryl: ok, i've managed to reproduce the build failure of busybox with libfaketime under ybd now! | 12:08 |
| perryl | hooray! ish | 12:08 |
| ssam2 | does seem like it's trying to link in modules that it never actually built.. very strange | 12:09 |
| ssam2 | the error is http://paste.baserock.org/oyosirapoj by the way | 12:12 |
| richard_maw | ooh, I see patches to rawdisk.write to add partitioning support | 12:13 |
| ssam2 | perryl: right, I think part of the problem is that sandboxlib sets the LD_PRELOAD environment outside the linux-user-chroot command, which won't work | 12:35 |
| ssam2 | oh. hmm | 12:35 |
| ssam2 | it logs an error when it runs linux-user-chroot, but it doesn't prevent libfaketime being preloaded for things run inside the chroot | 12:36 |
| ssam2 | so faketime is actually working inside the staging area. But i'm still not sure why that is breaking busybox's build | 12:37 |
| ssam2 | I hoped setting the mtime of all the files to match the fake timestamp , but it hasn't | 12:37 |
| ssam2 | +would work | 12:37 |
| ssam2 | i'll try eating some food, maybe that will help | 12:38 |
| richard_maw | edcragg: I lack the context to understand what all the SoCFPGA patches are for | 12:50 |
| richard_maw | edcragg: 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 place | 12:51 |
| richard_maw | edcragg: So I'm going to do just a code review for now. | 12:52 |
| SotK | richard_maw: it lives in definitions.git/extensions/rawdisk.write | 12:53 |
| richard_maw | I see changes to both baserock/baserock/morph and baserock/baserock/definitions on gerrit | 12:53 |
| richard_maw | ah, these patches have been consolidated too | 12:54 |
| SotK | yeah, that branch also changes writeexts.py, which at the moment is living in morph.git still | 12:54 |
| richard_maw | ok, I think edcragg or someone with more permissions needs to drop the old versions targetting morph.git then | 12:55 |
| SotK | that sounds sensible | 12:55 |
| * SotK sends a patch to update morph in definitions | 13:07 | |
| richard_maw | hmm, 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 moving | 13:12 |
| jmacs | What's the purpose of the <morph name>.inst directory in the staging area? | 13:25 |
| richard_maw | that's what $DESTDIR points to | 13:25 |
| richard_maw | which then gets tarred up to be a later artifact | 13:26 |
| jmacs | hmm, but in stage2-* components, everything ends up in /tools/bin, rather than /stage2-*.inst, doesn't it? | 13:26 |
| Kinnison | yes, the .inst is the *base* of the destdir | 13:27 |
| Kinnison | so anything in .inst/foo ends up in /foo in the target | 13:27 |
| jmacs | Is there another hidden stage that moves everything from .inst to tools then? | 13:28 |
| jmacs | .inst doesn't include tools | 13:28 |
| Kinnison | By the time install-commands are complete, it should | 13:28 |
| Kinnison | once the build/install is complete, the tooling collects up the content of the .inst directory and stores it as the artifact | 13:29 |
| Kinnison | then when it puts the artifact into a build-tree for another build, it unpacks it at the base of the new staging area | 13:29 |
| jmacs | OK, so my problem is that my binaries are in .inst and not in /tools; I thought I would be installing to /tools directory | 13:47 |
| jmacs | directly* | 13:47 |
| jmacs | I have stage2-zip.inst/409PREFIX/bin/zip | 13:48 |
| jmacs | Whatever 409PREFIX is, it doesn't look good | 13:48 |
| jmacs | Hmm, process number? | 13:48 |
| jmacs | Leave me to have a fiddle with definitions for a bit | 13:48 |
| radiofree | looks like you didn't use $PREFIX? | 13:49 |
| jmacs | I think I used $$PREFIX | 13:49 |
| radiofree | or maybe $PREFIX got set to 409PREFIX somehow... | 13:50 |
| richard_maw | $$ expands to a process ID | 13:50 |
| radiofree | heh | 13:50 |
| jmacs | Exactly. | 13:50 |
| radiofree | there you go then | 13:50 |
| * rjek remembers the nightmare of using expect and having to escape three times in three different ways when dealing with such horrors | 13:50 | |
| richard_maw | could be worse, you could be trying to put $ORIGIN into an rpath | 13:51 |
| richard_maw | I think that involves 4 levels of escaping | 13:52 |
| rjek | eugh | 13:52 |
| rjek | But tcl escaping is different from sh escaping, leading to additional excitement. | 13:53 |
| richard_maw | Make escaping is different from shell escaping, so there's still that fun with $ORIGIN | 13:59 |
| ssam2 | mason-x86-32.baserock.org is red: https://mason-x86-32.baserock.org/log/ade2a2957bdd7481237f35fde6dcf06bd2f7cbaf--2015-06-12%2013:52:26.log | 13:59 |
| ssam2 | seems to be a build error in 'gfcomplete' | 13:59 |
| * Kinnison doubletakes | 14:01 | |
| * Kinnison phews | 14:01 | |
| SotK | Kinnison: ? | 14:02 |
| * Kinnison maintains a library called 'libgfshare' which exposes, among other things, 'gfsplit' and 'gfcombine' | 14:02 | |
| * Kinnison misread 'gfcomplete' as 'gfcombine' at first | 14:03 | |
| SotK | aha! | 14:03 |
| * Kinnison was simultaneously worried that (a) baserock was using libgfshare without me realising it, and (b) that there was a bug in it | 14:04 | |
| kejiahu_ | with same defintion, YBD and morph build different systems on armv7. YBD results roughly 1G, but morph results 120M | 14:12 |
| Kinnison | minimal system? | 14:13 |
| kejiahu_ | yes, 120M should be reasonable | 14:13 |
| Zara | maybe there's no artifact-splitting in YBD? | 14:14 |
| kejiahu_ | as I simply used bsp-jetson without any stripping | 14:14 |
| ssam2 | there's no artifact splitting in YBD, indeed | 14:14 |
| Kinnison | ybd is not a full implementation of what we still don't know definitions to mean :) | 14:15 |
| paulsherwood | bwh: what have you been saying? :-) http://lists.linuxfoundation.org/pipermail/automotive-discussions/2015-June/000421.html | 14:16 |
| bwh | I don't remember | 14:16 |
| paulsherwood | i wonder when you spoke to folks were you speaking as 'Codthink's bwh' "Debian's bwh' or just bwh? :-) | 14:17 |
| paulsherwood | anyway 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 |
| bwh | Certainly not as Codethink's bwh | 14:18 |
| paulsherwood | understood. i'll correct that for you when i reply, unless you'd rather i didn't? | 14:19 |
| paulsherwood | baserockers - sorry for the noise -this is tyhe only public channel where bwh and currently overlap, i think | 14:20 |
| *** zoli___ has quit IRC | 14:20 | |
| Kinnison | it's amazing how well /msg works | 14:20 |
| Kinnison | :) | 14:20 |
| bwh | paulsherwood: Yes, fine | 14:20 |
| bashrc | does that make me "Coethink's bashrc' ? | 14:21 |
| paulsherwood | Kinnison: 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 |
| bwh | Actually it's cc'd to me | 14:21 |
| paulsherwood | bashrc: if you like :) | 14:26 |
| paulsherwood | http://lists.linuxfoundation.org/pipermail/automotive-discussions/2015-June/000422.html | 14:42 |
| jmacs | Ooh, I think gcj just built. | 14:46 |
| Kinnison | ooooh | 14:46 |
| rjek | ooh | 14:46 |
| paulsherwood | ooooo:) | 14:47 |
| rjek | That's a lot of halos on your head, paulsherwood. | 14:47 |
| rjek | One is normally enough. | 14:47 |
| Kinnison | rjek: perhaps paulsherwood is a conehead and those are the donuts he stores there | 14:47 |
| * persia ponders a game of tower-of-hanoi | 14:48 | |
| paulsherwood | jmacs: key question... morph or ybd? :) | 14:48 |
| Kinnison | persia: after I solved that in Zeus' equivalent of mod_rewrite, returning a server-push animated GIF I got bored | 14:48 |
| paulsherwood | or both? | 14:48 |
| rjek | jmacs: Say bitbake. | 14:48 |
| jmacs | paulsherwood: morph for now - I did use ybd earlier in the week, and had identical results | 14:48 |
| jmacs | This is all definitions work | 14:49 |
| paulsherwood | cool! | 14:49 |
| jmacs | Pity everything relies on gcc, so I'll have to wait for a full build | 14:58 |
| SotK | Does 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.log | 15:19 |
| SotK | franred maybe? ^^ | 15:19 |
| franred | SotK, no, no idea, but I can have a look at it | 15: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 ago | 15:22 | |
| radiofree | :\ | 15:26 |
| *** zoli__ has joined #baserock | 15:26 | |
| radiofree | i think pedroalvarez can read those particular mason runes | 15:26 |
| SotK | indeed, but I don't think he's around :/ | 15:27 |
| * SotK would guess anyone on the ops team can, but may be wrong | 15:27 | |
| franred | SotK, gf-complete builds in a x86_64 devel machine | 15:28 |
| SotK | hmm, must be a problem with x86_32 only then :/ | 15:28 |
| *** zoli__ has quit IRC | 15:28 | |
| SotK | franred: thanks for investigating | 15:28 |
| * SotK is stuck building things from way before gf-complete :( | 15:29 | |
| ssam2 | https://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 failure | 15:30 |
| ssam2 | the chunk is just broken on x86_32 | 15:30 |
| * SotK thought radiofree was referring to where the x86_64 build is up to | 15:30 | |
| franred | yes, I think _mm_insert_epi64 <-- this 64 is very suspicious | 15:31 |
| SotK | indeed | 15:31 |
| radiofree | SotK: that is what i meant | 15:32 |
| franred | I wondering why we are using a branch for it | 15:34 |
| paulsherwood | jmacs: what are you trying to verify? | 15:35 |
| franred | straycat, do you remember why we are using v2 branch for gf-complete in the swift stratum? | 15:35 |
| jmacs | paulsherwood: I need a system with gcj in it, it's part of the requirements to build IcedTea | 15:35 |
| paulsherwood | jmacs: 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 |
| franred | straycat, never mind, master does use the same | 15:36 |
| jmacs | paulsherwood: Not really worth the extra complication. I've got plenty of other stuff to research in the meantime. | 15:37 |
| paulsherwood | ok np | 15:37 |
| jmacs | Good suggestion, though | 15:37 |
| *** a1exhughe5 has quit IRC | 15:38 | |
| * franred wonders if adding --disable-sse to the configure in gf-compete will fix the error ;-) | 15:41 | |
| paulsherwood | radiofree: does self-upgrade with ybd work now? | 15:56 |
| radiofree | sure | 15:56 |
| paulsherwood | w00t! | 15:56 |
| paulsherwood | on which kit have you tried? | 15:56 |
| radiofree | jetson | 15:56 |
| radiofree | it probably would have worked on x86 anyway, since you don't need anything special there | 15:57 |
| radiofree | however on things like the jetson where you need to pass device tree information etc.. it wouldn't | 15:57 |
| radiofree | but now does | 15:57 |
| paulsherwood | interesting... i think i managed to do it on x86 a month or so ago, without a manifest | 15:57 |
| paulsherwood | right | 15:57 |
| * paulsherwood does another little jig :-) | 15:58 | |
| paulsherwood | cross-bootstrap next :-) | 15:58 |
| ssam2 | here is the first patch from attempts to make things bit-for-bit reproducible: https://gerrit.baserock.org/#/c/859/ | 15:59 |
| ssam2 | the main discovery this week has been that 'faketime' breaks build systems, though, and isn't usable as a general solution | 15:59 |
| tlsa | still don't see why it worked with my manual builds, but not as part of the ybd build | 16:00 |
| ssam2 | the breakage in Busybox was to do with config/autoconf.h not being regenerated after changes to .config | 16:01 |
| ssam2 | so 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 YBD | 16:01 |
| paulsherwood | ssam2: with that patch, how far up the stack can be shown b4b? | 16:10 |
| paulsherwood | ssam2: interesting about libfaketime. how/why does it break buildystems? could that be written up for the lsit? | 16:12 |
| ssam2 | i'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 yet | 16:12 |
| *** CTtpollard has quit IRC | 16:13 | |
| ssam2 | i'll write up about faketime on the wiki | 16:13 |
| ssam2 | I know that with that patch, busybox is bit for bit except for the /baserock/busybox.meta file | 16:13 |
| ssam2 | which contains 'elapsed_time' | 16:13 |
| paulsherwood | wiki - even better :) | 16:13 |
| paulsherwood | ssam2: bug in my thinking there, then - need to have elapsed_time in the log, not the metafile i think | 16:14 |
| ssam2 | sotk: fyi mason-x86-64 is building 'mesa' right now | 16:16 |
| * SotK wonders what's taking it so long | 16:17 | |
| ssam2 | if 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 | |
| ssam2 | this http://paste.baserock.org/yonokabose looks suspicious (from mason-x86-64.baserock.org) | 16:22 |
| ssam2 | no, I guess that's how it always worked | 16: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 | |
| ssam2 | you said yourself that build systems are boring, though | 16:44 |
| paulsherwood | i know. hence the need for exciting videos. | 16:44 |
| paulsherwood | ybd is not a build system, though :-) | 16:44 |
| ssam2 | what is it, then? | 16:44 |
| paulsherwood | from the readme ... 'ybd is a tool for integrating software stacks.' | 16:45 |
| rjek | What does that mean? | 16:45 |
| paulsherwood | rjek: excactly | 16:46 |
| DavePage | It means it's not a build system, obviously :) | 16:46 |
| * richard_maw is all reviewed-out after reading through the rawdisk.write series | 16:47 | |
| rjek | It's a thing for building and combining other people's awful stuff | 16:47 |
| paulsherwood | i'm working on a submission for elce - if anyone can explain it in different words, pleas let me know :) | 16:47 |
| rjek | paulsherwood: ^ | 16:47 |
| paulsherwood | ROFL | 16:47 |
| robtaylor | paulsherwood: s/stacks// | 16:48 |
| paulsherwood | robtaylor: why? | 16:48 |
| rjek | Because stacks means nothing | 16:49 |
| paulsherwood | software on its own is too nebulous imo? | 16:49 |
| rjek | so's what the tool does | 16:49 |
| paulsherwood | rjek: really? doesn't the readme spell it out quite precisely? | 16:50 |
| robtaylor | paulsherwood: maybe 'ybd is a tool for reliably integrating software' ? :) | 16:50 |
| rjek | If you're having trouble defining what it does in a short sentence, I think that demonstrates that it's a bit nebulous :) | 16:50 |
| paulsherwood | robtaylor: yes | 16:50 |
| paulsherwood | rjek: define debian in a short sentence? | 16:50 |
| paulsherwood | but i take your point | 16:51 |
| rjek | paulsherwood: 20,000 pre-packaged pieces of software tested to work well with each other. | 16:51 |
| paulsherwood | rjek: nicely done | 16:51 |
| paulsherwood | not sure that's accurate, though... others have claimed 35,000 and i don't know that it's all cross-tested? | 16:52 |
| robtaylor | paulsherwood: but in answer to 'why not stacks' becasue its about integrating for delivery, which means it integrates software that uses stacks too. | 16:52 |
| paulsherwood | robtaylor: ah, i get your point | 16:52 |
| paulsherwood | thanks | 16:52 |
| robtaylor | np :) | 16:52 |
| paulsherwood | 'ybd is a tool to integrate software collections for delivery' ? | 16:54 |
| rjek | eugh | 16:55 |
| paulsherwood | rjek: :-) | 16:56 |
| *** jonathanmaw has quit IRC | 16:56 | |
| rjek | Go 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 himself | 16:57 | |
| radiofree | needs more cloud | 16:57 |
| rjek | Add "cloud-ready" :) | 16:58 |
| rjek | Add it anywhere, it doesn't matter | 16:58 |
| Kinnison | cloud-enabled sounds better | 16:59 |
| paulsherwood | https://twitter.com/codethink/status/609404621241589760 | 16:59 |
| rjek | Sickening, paulsherwood. | 17:00 |
| radiofree | :) | 17:00 |
| rjek | You missed the cloud-ready bit | 17:00 |
| * Kinnison blocks @codethink and reports it for spam | 17:00 | |
| radiofree | rjek: he didn't! | 17:00 |
| rjek | OK, it's been a long day. | 17:00 |
| rjek | Can we pub now? | 17:00 |
| paulsherwood | rjek: you mis-spelled reproducible, btw :) | 17:00 |
| rjek | My spelling of repoducable is not repruducable. | 17:01 |
| paulsherwood | rjek: 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 IRC | 17:14 | |
| *** ssam2 has quit IRC | 17:16 | |
| *** mariaderidder has quit IRC | 17:24 | |
| *** nowster has quit IRC | 17:26 | |
| *** gary_perkins has quit IRC | 17:30 | |
| *** tiagogomes has quit IRC | 17:33 | |
| *** lachlanmackenzie has quit IRC | 18:15 | |
| * Kinnison ponders streaming a live code review | 18:23 | |
| paulsherwood | Kinnison: that would be great, actually, if you think it's worth your time? | 18:26 |
| *** zoli__ has joined #baserock | 18:29 | |
| Kinnison | Sadly I have a weekend of university work todo, so perhaps you ahve a chance to tidy up a bit first :-) | 18:29 |
| paulsherwood | heh | 18:31 |
| paulsherwood | Kinnison: what are you studying these days? | 18:31 |
| Kinnison | Currently a concurrency/distributed systems thing | 18:31 |
| Kinnison | It's a little crunchy currently, but I hope there'll be something worth sinking my teeth into toward the end of it | 18:32 |
| paulsherwood | :) | 18:32 |
| Kinnison | Still, it'll make for an interesting additional topic on the final record | 18:33 |
| Kinnison | Basic CS, maths, psychology, AI, music, and now distributed systems | 18:33 |
| * Kinnison hopes his degree manages to finish :) | 18:33 | |
| paulsherwood | that's quite a mix :) | 18:33 |
| Kinnison | Well, I can't do something boring | 18:34 |
| *** zoli__ has quit IRC | 18:34 | |
| * Kinnison thinks he's going to go plan his next controversial blog posting | 18:34 | |
| *** edcragg has joined #baserock | 19:46 | |
| *** paulw has quit IRC | 20:07 | |
| *** dabukalam has quit IRC | 20:07 | |
| *** bwh has quit IRC | 20:07 | |
| *** bwh has joined #baserock | 20:07 | |
| *** paulw has joined #baserock | 20:08 | |
| *** dabukalam has joined #baserock | 20:09 | |
| *** edcragg has quit IRC | 20:23 | |
| *** edcragg has joined #baserock | 20:43 | |
| *** edcragg has quit IRC | 21:35 | |
| *** edcragg has joined #baserock | 21:37 | |
| *** edcragg has quit IRC | 22:33 | |
| *** edcragg has joined #baserock | 22:35 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!