| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 06:44 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 245 seconds] | 08:03 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:18 | |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:32 | |
| *** ripsum [~richardip@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:05 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 255 seconds] | 09:06 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:07 | |
| *** motters [~motters@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:07 | |
| *** inara [~inara@192.241.198.49] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] | 09:08 | |
| *** inara [~inara@192.241.198.49] has joined #baserock | 09:12 | |
| *** ripsum [~richardip@82-68-191-81.dsl.posilan.com] has quit ["Leaving"] | 09:36 | |
| motters is now known as bmottram | 10:09 | |
| bmottram | Question: is it possible to create licensing reports for baserock builds? | 10:10 |
|---|---|---|
| persia | There's a check-licenses script, which I heard might do something like that, but I don't know how to run it. | 10:12 |
| * pedroalvarez wonders if bmottram is looking for an output like this: http://download.baserock.org/baserock/genivi-h0.1r2-genivi-baseline-system-x86_64-generic-license-manifest.txt | 10:12 | |
| persia | Morphologies don't capture anything specific about licensing, so it depends on the original sources having valid parseable data. | 10:12 |
| bmottram | similar, but the reverse | 10:12 |
| bmottram | for each license type | 10:13 |
| persia | How do you mean "the reverse"? | 10:13 |
| bmottram | for every license type what packages exist in the build under those | 10:13 |
| persia | pedroalvarez: That comes from the licensecheck script, right? | 10:14 |
| bmottram | If I were a lawyer first I'd want to know what licenses exist within the build, then go from there. I might have predelections for some and aversions to others | 10:16 |
| persia | given my experience with practicing litigants, the format of the information is rarely interesting | 10:17 |
| persia | Looking quickly at the implementation, it loops over the set of components in a system, and then extracts licenses, so the implrmentation drives the format (there does not appear to be an intermediate representation from which a report is generated). | 10:17 |
| pedroalvarez | persia: yes | 10:18 |
| persia | It should be relatively easy to parse that output, and generate the alternate hierarchy. | 10:18 |
| rjek | What's involved in setting up a dist-build network? Is there a page on the wiki I am yet to find? | 10:18 |
| persia | pedroalvarez: Thanks for the confirmation. You've just made me confident what I just said was true, rather than hopeless speculation :) | 10:18 |
| persia | rjek: You need a bunch of machines. | 10:18 |
| * persia finds the page | 10:18 | |
| persia | http://wiki.baserock.org/guides/jetson_distbuild_cluster/ | 10:19 |
| bmottram | From what I've read, Yokto can automatically extract licenses and highlight any known incompatabilities | 10:19 |
| persia | There's some stuff in there which is jetson-specific, but the equivalent for x86 is essentially the same. | 10:20 |
| persia | bmottram: Are they using SPDX? | 10:20 |
| bmottram | persia: I don't know | 10:21 |
| persia | rjek: if the documentation doesn't work, please complain (ideally with a lsit), and someone (quite possibly me) will fix it. | 10:21 |
| persia | bmottram: It might be worth investigating what the described feature claim means: it may be that baserock does it (or can trivally do so with a simple script), or it may be that it doesn't, but it's hard to know without specifics. | 10:22 |
| rjek | persia: It's going to be a long while before I can try it, I think... | 10:24 |
| rjek | 2014-07-28 10:05:54 [Build 7/751] [stage1-gcc-bins] Running build-commands | 10:24 |
| persia | stage1 again :( | 10:42 |
| rjek | Well, this is morph build rather than the native-bootstrap script. | 10:44 |
| rjek | So hopefully in a couple of days I'll have a real BR system :) | 10:44 |
| persia | Ooh! That is progress. | 10:44 |
| rjek | (But the USB is unreliable, so I expect to have to restart this several times.) | 10:44 |
| persia | You're running native in the bootstrapped environment? | 10:44 |
| rjek | Yep. | 10:44 |
| persia | My recommendation would be to do a trove next. | 10:45 |
| persia | While I've been seen to argue against troves, there's not currently any other sensible way to share cache, and you'll want to get the cache somewhere safe soonest. | 10:45 |
| rjek | Nod. | 10:45 |
| persia | (Ideally to git.baserock.org, but I suspect someone will want to replicate your work all over again before it lands there) | 10:45 |
| rjek | Well, it'll need merging, and we have another problem before we can do that. | 10:46 |
| persia | Once you have a trove, a distbuild cluster should be relatively easy. | 10:46 |
| persia | What's the other pre-merge problem? | 10:46 |
| rjek | I've had to use GCC 4.6 for both stage 1 and 2, as well as 3. On other platforms, we use GCC 4.6 only for 1 and 2, and use 4.7 for 3. | 10:46 |
| paulsherwood | bmottram: iiuc yocto extracts information which humans have added to recipes - ie the actual consideration of applicable license(s) per component is done manually | 10:46 |
| rjek | persia: And currently there's no way to change which compilers are used dependant on architecture. | 10:46 |
| persia | Ah, yes, logic in stratum morphologies. | 10:47 |
| persia | Technically, it could be done by mangling all the chunk morphologies very aggressively, but that's an unpleasant prospect. | 10:47 |
| persia | paulsherwood: So a model akin to Debian's DEP5? | 10:48 |
| paulsherwood | persia: for better or worse, i have no experience at all with debian | 10:49 |
| persia | Oh heh. | 10:49 |
| bmottram | paulsherwoo: https://wiki.yoctoproject.org/wiki/License_Infrastructure_Interest_Group | 10:50 |
| persia | paulsherwood: e.g. http://metadata.ftp-master.debian.org/changelogs/main/w/wildmidi/unstable_copyright | 10:50 |
| persia | Ah, yes, yocto *is* using SPDX | 10:52 |
| paulsherwood | just because SPDX says a component is foo-licenced, doesn't make it true, afaik. | 10:53 |
| persia | Same for DEP5 or the output of licensecheck.pl | 10:53 |
| persia | I don't know if they ever implemented it, but I remember speaking to some SPDX folk about a format to express warrants of licensing, with the warrantor identified, to ease indemnity and liability considerations for recipient organisations. | 10:55 |
| persia | (because, we can't actually *know* the license for a given piece of code with any specificity, regardless of the textual content made available for download) | 10:56 |
| paulsherwood | licensecheck.pl at least reports all license instances, based on checking each file. that's better, imo. | 10:56 |
| * persia will now stop writing about issues with licensing and compliance until and unless someone else particularly wants to have a discussion now, and there is a sane plan to turn said discussion into something useful | 10:57 | |
| paulsherwood | i was only rplying to bmottram's earlier comment | 10:57 |
| * paulsherwood goes back to work :) | 10:57 | |
| * persia fails to refrain from writing that licensecheck.pl assumes 1) the text of the source code has any relation to the user's license terms, and 2) there are no irregularities in the format of expressed licenses (the number of sources with spacing issues in copied GPL preambles is not small). | 10:59 | |
| * persia tries harder | 10:59 | |
| rjek | Boohiss http://pastebin.com/U8F3TDXd | 13:22 |
| * richard_maw boggles at /bin/sh command not found | 13:24 | |
| Kinnison | That sometimes happens if the dynamic loader isn't found | 13:24 |
| Kinnison | I seem to recall that symptom when pedro was doing ppc64 support | 13:25 |
| Kinnison | when the loaders got installed to a different path | 13:25 |
| rjek | Any suggestions for what I should do to debug? Will it have left the build directory around for me to nose in? | 13:26 |
| Kinnison | It will have left the staging area in $MORPH_TEMPDIR/failed/ | 13:26 |
| Kinnison | for you to poke at | 13:26 |
| * richard_maw still boggles, since morph runs `sh -c 'make mrproper'` | 13:26 | |
| rjek | /src/tmp/failed # chroot tmpeViDuV/ /bin/sh | 13:27 |
| rjek | chroot: can't execute '/bin/sh': No such file or directory | 13:27 |
| rjek | That chroot doesn't even have a bin directory | 13:27 |
| richard_maw | ah, it must be /tools/bin/sh | 13:27 |
| Kinnison | While bootstrap is still underway, /bin is likely a symlink to /tools/bin | 13:28 |
| rjek | Yeah, that exists. | 13:28 |
| * richard_maw thought the bootstrap created the /bin/sh symlink for you | 13:28 | |
| rjek | In that, I mean that /src/tmp/failed/tmpeViDuV/ has no bin. | 13:28 |
| Kinnison | rjek: Hmm | 13:28 |
| rjek | It does have tools/bin/ | 13:28 |
| Kinnison | This is most confuzzling :-( | 13:29 |
| Kinnison | We've recently done from-scratch builds on other architectures | 13:29 |
| Kinnison | which worked | 13:29 |
| Kinnison | so it's not a systemic fault | 13:29 |
| rjek | "recently" ? | 13:29 |
| Kinnison | last Friday | 13:30 |
| Kinnison | Could you pastebin the meta file for stage2-fhs-dirs misc chunk? | 13:33 |
| Kinnison | it should be in the /baserock of that failed chroot | 13:33 |
| rjek | http://pastebin.com/rJvQWLFn | 13:34 |
| Kinnison | and the -bins ? | 13:35 |
| rjek | http://pastebin.com/ixHANZ8T | 13:36 |
| Kinnison | Interesting | 13:37 |
| Kinnison | the symlink is entirely missing | 13:37 |
| rjek | How do I fix this? :) | 13:40 |
| richard_maw | rjek: once we know how it happened we can provide advice, but until then any suggestions might be entirely wrong | 13:42 |
| Kinnison | Stage2 FHS-Dirs does: | 13:43 |
| Kinnison | - ln -s "$PREFIX/bin" "$DESTDIR/bin" | 13:43 |
| Kinnison | which *SHOULD* have put a bin symlink in place | 13:43 |
| Kinnison | the presence of etc/passwd etc suggests that the chunk ran properly | 13:43 |
| Kinnison | It'd be handy if you happen to have the morph log of running the build for stage2-fhs-dirs so we can confirm if it ran that command | 13:43 |
| richard_maw | so, 1. is this file in the hardlink cache 2. is this file in the chunk artifact | 13:43 |
| Kinnison | richard_maw: I think you'll need to help rjek identify the chunk file so he can find out | 13:44 |
| richard_maw | ok, run `morph --dump-config | grep tempdir` and look in the chunks subdir of the directory that command lists | 13:45 |
| richard_maw | there's a cb3184d7bbd3991492725de83743fd48b9479a70d7b0ab42a858b6fffaaba1ae* subdirectory for each of the artifacts produced by stage2-fhs-dirs | 13:46 |
| richard_maw | I don't recall the naming off the top of my head, but look in those to see if any has a bin symlink | 13:46 |
| rjek | http://pastebin.com/nxhYZpkb | 13:48 |
| rjek | (no) | 13:48 |
| richard_maw | ok, that's a possible culprit, now we need to work out whether it's the cache that's wrong or the chunk artifact | 13:49 |
| richard_maw | `morph --dump-config | grep cachedir` for the directory your cache is in, and `tar -tf $cachedir/artifacts/cb3184d7bbd3991492725de83743fd48b9479a70d7b0ab42a858b6fffaaba1ae.chunk.stage2-fhs-dirs-misc` and `tar -tf $cachedir/artifacts/cb3184d7bbd3991492725de83743fd48b9479a70d7b0ab42a858b6fffaaba1ae.chunk.stage2-fhs-dirs-bins` please | 13:51 |
| rjek | There is no artifacts directory in /src/tmp | 13:53 |
| richard_maw | your cache dir, not your temp dir | 13:53 |
| rjek | Oh, sorry | 13:54 |
| rjek | http://pastebin.com/hS8ym8sA | 13:55 |
| Kinnison | so the bin symlink is indeed entirely missing from the artifacts | 13:57 |
| Kinnison | Very odd | 13:57 |
| * richard_maw can feel this draining his sanity | 13:58 | |
| Kinnison | rjek: Could you please confirm the SHA1 of stage2-fhs-dirs in your build-essential morphology? | 13:59 |
| * rjek spends a few moments parsing that request to work out what is being asked. | 13:59 | |
| rjek | Kinnison: Where is it? There isn't a stage2-fhs-dirs in build-essential. | 14:00 |
| Kinnison | erm, there really ought to be | 14:01 |
| Kinnison | it's line 116 in master's build-essential.morph | 14:01 |
| Kinnison | with the SHA1 on line 118 | 14:01 |
| rjek | Ah. Sorry. I couldn't see the SHA1 for the hashes. | 14:02 |
| rjek | ref: 41bbb474cd4647ee715bc94c21c161d12a20deb4 | 14:02 |
| richard_maw | that's up to date, and makes the symlink | 14:03 |
| * Kinnison concurs | 14:04 | |
| * Kinnison also boggles | 14:04 | |
| rjek | This isn't the only thing that isn't working for me today that should, btw. | 14:04 |
| Kinnison | What FS is /src ? | 14:05 |
| rjek | Steve Jobs had a reality distortion field. I have a reality breaking field. | 14:05 |
| rjek | Kinnison: ext3. (same filesystem as /, which is actually /mnt but I chrooted in) | 14:05 |
| Kinnison | Okay, that should be fine | 14:06 |
| Kinnison | We're currently thinking that we want to cause the fhs-dirs chunk to fail to build so that we can see if the symlink is present in the .inst directory | 14:10 |
| Kinnison | I think the easiest (sic) way to do that is to morph edit stage2-fhs-dirs | 14:10 |
| Kinnison | and then add 'false' to the end of the install commands | 14:10 |
| Kinnison | And then examine the failed/ chroot | 14:10 |
| richard_maw | well, in stage2 it's not a chroot | 14:10 |
| Kinnison | rjek: Do you think you could do that? | 14:10 |
| Kinnison | richard_maw: true | 14:10 |
| Kinnison | richard_maw: failed/ space then | 14:11 |
| rjek | Give me a few moments to try to understand what it is you're asking. | 14:11 |
| rjek | gah | 14:14 |
| rjek | /src/workspace/baserock/robkendrick/mips64/baserock/baserock/definitions # morph edit stage2-fhs-dirs | 14:14 |
| rjek | ERROR: morph edit needs the names of a system, a stratum and optionally a chunk as parameters | 14:14 |
| * rjek tries to untwist in his mind where he is | 14:15 | |
| paulsherwood | rjek: wrong version of morph | 14:15 |
| Kinnison | That's a surprisingly old morph error message actually | 14:15 |
| rjek | Well, it's what it's built and installed. | 14:15 |
| Kinnison | rjek: based on the branch you and I made the other day? | 14:15 |
| rjek | It's whatever's mentiong in baserock/robkendrick/mips64/ | 14:16 |
| Kinnison | How odd | 14:16 |
| Kinnison | that's ancient | 14:16 |
| Kinnison | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=baserock/robkendrick/mips64 | 14:16 |
| Kinnison | shows your commit on top of one from march | 14:16 |
| * Kinnison is sure when we made your branch we based it off the current morph at that point | 14:17 | |
| rjek | I'm not sure what I'll do if it turns out I need to build all this again. But it will involve tears, and possibly a tantrum. | 14:20 |
| Kinnison | We might get away with replacing your morph with one in /src and then making sure what you build subsequently uses the right thing | 14:20 |
| * Kinnison is trying to work out how you ended up with a morph this old | 14:20 | |
| * Kinnison remembers sitting with you to make the branch | 14:21 | |
| Kinnison | and I'm sure there were commits from Sam from last week in it | 14:21 |
| persia | Should be able to quickly rebase it against master. | 14:22 |
| persia | Or, for safety, the commit in definitions.git today | 14:22 |
| Kinnison | Currently richard_maw and I are erring on the side of rjek having a haunted machine because this is super-duper-wierd | 14:23 |
| SotK | Kinnison: the morph ref in cross-bootstrap.morph points to a commit from March | 14:25 |
| Kinnison | Okay, for reference, I've helped rjek to update his morph to be rebased from current morph master | 14:44 |
| Kinnison | and on his branch we've updated both the cross-bootstrap and the tools references to morph | 14:44 |
| Kinnison | Unfortunately this means his build is going from step 1 again | 14:45 |
| Kinnison | so it'll be a while before we know if this worked | 14:45 |
| persia | I suspect the chances are much better. | 14:45 |
| rjek | At least 6 hours. | 14:45 |
| rjek | Which basically means: tomorrow morning. | 14:45 |
| persia | Out of curiosity, is there a way to cause cross-bootstrap to use the morph ref from tools? | 14:45 |
| Kinnison | Currently, no. | 14:45 |
| Kinnison | I'd be interested in ideas on that front | 14:45 |
| persia | What blocks it? | 14:45 |
| Kinnison | persia: cross-bootstrap needs to be minimal in order to be buildable -- the cross built environment is very quirky due to bootstrap stuff still being around, so we need to keep minimal the stuff we build | 14:46 |
| Kinnison | there's no easy way to refer from one stratum to another, and no way to share that data (currently) | 14:46 |
| Kinnison | thus the separation and confusion | 14:46 |
| * Kinnison would welcome any ideas on fixing this | 14:46 | |
| persia | Could morph (and a few other bits) be split out, to be consumed by cross-bootstrap, and whatever else needs them? | 14:47 |
| Kinnison | It's tough because cross-bootstrap is a cross (sic) between core, foundation and tools | 14:47 |
| Kinnison | so there's different build-dep structures in place | 14:48 |
| * Kinnison would love to be able to unify things, but until and unless we have conditional control over stratum content, I doubt we can. (note: I don't say we can't, just that I doubt we can) | 14:49 | |
| persia | I don't understand why more modularisation wouldn't help. | 14:49 |
| persia | Have core-minimal, foundation-minimal, and tools-minimal, and then build atop them. | 14:49 |
| Kinnison | I seem to recall there being a reason that wasn't easy to do, but I don't recall what the reason was | 14:50 |
| persia | I suspect it of being easy to do, but hard to manage. | 14:50 |
| persia | Lots more strata adds confusion. | 14:51 |
| persia | But in this case, less strata has wasted a week or so :( | 14:51 |
| Kinnison | fewer strata has indeed caused confusion | 14:52 |
| Kinnison | To be fair, it'd have caused less confusion if we hadn't done the "morph edit chunkonly" syntax change | 14:52 |
| Kinnison | because I'd have been more aware of the possibility of it being elsewhere | 14:52 |
| rjek | It would be nice if "morph edit foo", when faced with multiple options for foo, instead of checking out out at random instead give you a list of more precise descriptions that you could copy-and-paste the appropriate one from. | 14:52 |
| Kinnison | but I take on responsibility | 14:52 |
| persia | It would be nice if `morph edit` returned an error about the lack of such a command. | 14:52 |
| rjek | Actually, I'm not sure morph edit does select at random. IME, it always selects the least appropriate :) | 14:52 |
| * Kinnison is going to have to bow out of this discussion now. rjek: please hilight me if you have any updates on how your build goes :_) | 14:53 | |
| rjek | 2014-07-28 14:52:08 [Build 1/752] [stage1-binutils-bins] Removing staging area | 15:29 |
| rjek | 2014-07-28 14:52:11 [Build 7/752] [stage1-gcc-bins] Building chunk stage1-gcc-bins | 15:29 |
| * rjek wonders what happened to builds 2, 3, 4, 5, and 6. | 15:29 | |
| richard_maw | rjek: they were stage1-binutils-{libs,misc,doc,...} | 15:32 |
| richard_maw | rjek: I've been working on a patch to fix this, and your issues with needing to remove large amounts of the cross-bootstrap script | 15:32 |
| richard_maw | since their root cause is the same | 15:32 |
| rjek | Ah, right. | 15:35 |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 16:35 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 16:47 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has quit [Remote host closed the connection] | 16:50 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 264 seconds] | 16:52 | |
| *** bmottram [~motters@82-68-191-81.dsl.posilan.com] has quit [Quit: Lost terminal] | 16:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!