| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 07:14 | |
| rjek | Nope, that didn't work: http://pastebin.com/0NxyChj0 | 08:06 |
|---|---|---|
| rjek | (Still no bin symlink) | 08:06 |
| Kinnison | rjek: hrf | 08:08 |
| Kinnison | rjek: could you please delete your stage2-fhs-dirs artifacts from your artifact cache and also the unpacked chunk directories in your tmpdir, and then run: | 08:08 |
| Kinnison | $MORPH --log=/src/log-making-fhs-dirs.txt --log-level=debug build my-system | 08:08 |
| Kinnison | and then put that log file somewhere we can review it to see if anything odd happens during the fhs-dirs chunk build | 08:09 |
| * rjek thinks about this for a moment | 08:11 | |
| rjek | It would be nicer if the hashes came after the names in these caches and chunk directories; it means you can more usefully employ tab completion | 08:13 |
| rjek | https://www.rjek.com/log-making-fhs-dirs.txt | 08:18 |
| Kinnison | Thank you. I can't guarantee I'll be able to work it out from that, but hopefully a colleague will come along soon who can. | 08:20 |
| persia | +1 on renaming everything to be easier for humans to parse. | 08:20 |
| persia | (note that this requires rebuilding the world, and repopulating every baserock artifact cache in existence, so is rather invasive: best to do sooner, rather than later) | 08:21 |
| * Kinnison strongly believes the naming scheme right now is correct | 08:21 | |
| persia | Kinnison: Why? | 08:21 |
| Kinnison | because normally you're more interested in finding an artifact by cache ID | 08:21 |
| Kinnison | rjek's situation is unusual | 08:21 |
| persia | I've never known the cache ID *except* by parsing the filename. | 08:22 |
| persia | Please explain this "usual" situation :) | 08:22 |
| Kinnison | morph's output tells you it at various points | 08:22 |
| * Kinnison is usually interested in $cacheid.* | 08:22 | |
| persia | At a speed I can't follow, as part of a volume that makes it uninteresting. | 08:22 |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:22 | |
| * rjek has never wanted to find something by hash, tbh. | 08:23 | |
| persia | Ah, $cacheid.* is an interesting point. | 08:23 |
| persia | But still, the current model is mostly user-frustrating. | 08:23 |
| rjek | Oh yesl | 08:25 |
| * persia vaguely wonders what nifty punctuation lives near the 'l' key on rjek's keyboard | 08:26 | |
| Kinnison | Unfortunately I'm not doing my degree course in user interaction design until 2016 | 08:26 |
| rjek | persia: . is drectly below l | 08:26 |
| persia | Thanks. | 08:27 |
| rjek | God, it gets worse. | 08:27 |
| persia | Kinnison: Which means this is an excellent time to start working on the concepts, so that you don't need to think so much during the course :) | 08:27 |
| Kinnison | hah | 08:27 |
| persia | rjek: How? | 08:27 |
| * Kinnison chose a distributed/concurrent systems course to do next | 08:27 | |
| rjek | persia: My typing. | 08:28 |
| persia | You might try a Handmaster Plus, or similar product: tends to help keep one's fingers from binding. | 08:31 |
| * persia has trouble deciding if Baserock tooling needs integration with distributed systems or UX more | 08:32 | |
| Kinnison | persia: Whatever it needs more, the distributed/concurrent systems course is in its last cycle so I gotta take it first | 08:33 |
| rjek | I am not interested in an experience; I simply want an interface with which I can describe to the computer what it is I want it to do. The less experiences I have doing it the better. | 08:34 |
| * persia hopes "in it's last cycle" doesn't mean "scheduled for review because the material is outdated" | 08:34 | |
| persia | rjek: Have you tried any of the brain-computer-interfaces yet? | 08:34 |
| rjek | I have not. | 08:34 |
| rjek | But I don't think I'd want to :0 | 08:34 |
| * persia likes to set focus-follows-thought in the window manager, but hasn't explored too much further yet | 08:34 | |
| rjek | :) | 08:34 |
| Kinnison | persia: I think it's just not popular enough (which I hope means it's interestingly hard) | 08:35 |
| persia | Distributed systems is indeed interestingly hard. | 08:35 |
| persia | If the course doesn't meet your expectations, it's trivial these days to spin up 10-100 instances somewhere to play with the ideas. | 08:36 |
| Kinnison | :_) | 08:37 |
| * Kinnison might indeed have to play with EC2 or similar | 08:37 | |
| Kinnison | I think for a few 10s of $s I can do some fun stuff | 08:37 |
| persia | There's free clouds for folk playing, and some of the pay clouds have free space if you can show you're taking a course. | 08:37 |
| persia | e.g. http://trystack.org/ | 08:39 |
| * persia doesn't like the signup conditions for that, but it's the first hit for search terms | 08:40 | |
| Kinnison | "For access to the x86 zone, join our Facebook Group" | 08:40 |
| Kinnison | erm no. | 08:40 |
| * persia did say something about not liking the signup conditions | 08:46 | |
| Kinnison | :-) | 08:46 |
| persia | There are alternatives. I can't find the page right now, but I know HP has an academic program. | 08:46 |
| persia | (or had, or something) | 08:46 |
| Kinnison | s'fine | 08:46 |
| Kinnison | for a few 10s of $s I can spool up some tiny instances in EC2 with little effort | 08:47 |
| *** stetaylor [~stetaylor@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:57 | |
| benbrown1 is now known as benbrown_ | 08:57 | |
| Kinnison | rjek: I haven't forgotten you, I was looking at stuff. Is there a build log for stage2-fhs-dirs in your artifact cache directory? If so, could you pop that somewhere for us too? | 09:27 |
| paulsherwood | Kinnison: EC2 running baserock? | 09:28 |
| Kinnison | paulsherwood: down boy. | 09:28 |
| persia | Baserock is actually a nice platform for distributed system work, because morph deploy makes it easy to deploy several things together. | 09:28 |
| paulsherwood | Kinnison: i'm old enough to be your father, i believe ;) | 09:29 |
| Kinnison | naah, my dad is, erm, err. | 09:29 |
| * Kinnison does maffs | 09:29 | |
| Kinnison | 86 | 09:29 |
| Kinnison | You're not that old | 09:29 |
| rjek | Kinnison: https://www.rjek.com/386975cc1a9428590a83bcf81263af4b990838caf6db70ee3e2793af27174e06.build-log | 10:05 |
| rjek | Second request: build logs have the artifact name in like everything else does | 10:05 |
| persia | That has been requested: apparently there's some annoying obstacle to implementation. | 10:06 |
| richard_maw | rjek: it would be more plausible to have the source name in there | 10:06 |
| persia | ripsum had some ideas about a workaround, but then got distracted and solved several more annoying problems that he noticed. | 10:06 |
| Kinnison | rjek: Okay, so there's nothing showing in that log around the ln line which would suggest it had failed in some non-detected manner | 10:07 |
| * Kinnison guesses the next step is to edit that chunk so we can fail it at the end of install-commands and see if the symlink is on the filesystem | 10:07 | |
| Kinnison | if it's on the filesystem and not in the chunk then we've narrowed the scope of where the problem can be, quite a lot | 10:08 |
| richard_maw | Kinnison: if you're going to add a command to make it fail, quote "false", otherwise it turns it into a boolean False | 10:08 |
| Kinnison | rjek: Could you please 'morph edit stage2-fhs-dirs' go into the checked out directory, and add: - "false" as a command to the end of the install commands in the stage2-fhs-dirs.morph file? | 10:09 |
| Kinnison | rjek: then retry your build and we should get a failed/ dir | 10:09 |
| Kinnison | rjek: in that failed/ dir, check stage2-fhs-dirs.inst for the presence of the bin symlink | 10:09 |
| rjek | eh? | 10:11 |
| rjek | There's only one thing left in failed/ and that's the linux-api-headers | 10:11 |
| rjek | (And it has no bin) | 10:11 |
| Kinnison | did you do the edit as requested? | 10:12 |
| rjek | No. | 10:12 |
| rjek | I'm still trying to work out what you mean. | 10:12 |
| rjek | I'm normally wary of ever using morph edit because it doesn't ever seem to do the right thing... | 10:12 |
| persia | You can do it with git, if you prefer. | 10:13 |
| rjek | Also: ERROR: morph edit needs the names of a system, a stratum and optionally a chunk as parameters | 10:13 |
| Kinnison | rjek: use your $MORPH please | 10:13 |
| rjek | Oh yes | 10:13 |
| persia | Which morph are you running? | 10:13 |
| *** franred [~franred@82-68-191-81.dsl.posilan.com] has joined #baserock | 10:14 | |
| Kinnison | rjek's system installed morph is wrong, he has a /src checkout which he sometimes forgets to use | 10:14 |
| rjek | Kinnison: I assume your request is missing some steps. Do I need to commit and push this change somewhere, or edit a hash somewhere? | 10:15 |
| rjek | (the "- false" change) | 10:15 |
| richard_maw | if you use `morph edit` it will make the changes to your stratum morphologies, and you just need to make the change to the morphology in ../fhs-dirs/stage2-fhs-dirs.morph | 10:17 |
| Kinnison | rjek: morph *should* pick up the change (and since it's temporary, we don't care about keeping it) | 10:17 |
| rjek | How confident are you that it will, though? :) | 10:17 |
| * rjek kicks off anotgher build | 10:17 | |
| richard_maw | rjek: normally I'd be 100% sure, but you attract software spectres | 10:18 |
| rjek | :) | 10:18 |
| liw-orc | richard_maw, are you saying you're James Bond and rjek is Blofeld? :) | 10:19 |
| rjek | TypeError: sequence item 2: expected string, bool found | 10:19 |
| richard_maw | liw-orc: no, I'm saying rjek is haunted | 10:19 |
| * rjek laughs | 10:19 | |
| rjek | I forgot the "" | 10:19 |
| rjek | A big fat stack backtrace when I fumble my YAML isn't very friendly :) | 10:20 |
| liw-orc | rjek, agreed; we should catch the exception and produce a nicer error message | 10:20 |
| Kinnison | We could, perhaps, use Rx | 10:21 |
| Kinnison | http://rx.codesimply.com/ | 10:21 |
| * richard_maw thinks we should hook into the yaml parser to make it create objects, so we have textual context when it goes wrong | 10:22 | |
| rjek | Use Lua! >:) | 10:22 |
| richard_maw | rjek: no, we don't want anything turing complete | 10:22 |
| richard_maw | it makes it more difficult to cache | 10:22 |
| richard_maw | and reason about for users reading it | 10:23 |
| rjek | Kinnison: stage2-fhs-dirs.inst has a symlink | 10:24 |
| * persia mumbles about how most of morph could be replaced by a make library, and morphologies as makefiles, easing the transition for folk familiar with make | 10:24 | |
| rjek | /src/tmp/failed/tmp7JSTVt/stage2-fhs-dirs.inst # ls -l | 10:24 |
| rjek | total 68 | 10:24 |
| rjek | lrwxrwxrwx 1 root root 10 Jul 29 10:21 bin -> /tools/bin | 10:24 |
| Kinnison | rjek: thank you | 10:24 |
| persia | So that means it is created, but not included in the chunk? | 10:24 |
| rjek | persia: I have noticed the similarity with Make before. | 10:24 |
| Kinnison | richard_maw: so, we have a pair of boundaries as close as we can expect rjek to find... the symlink is in the .inst but not in any of the chunks | 10:24 |
| persia | rjek: What similarity? | 10:25 |
| Kinnison | Having written distributed build systems in make before, I wouldn't want to do it again | 10:25 |
| rjek | persia: That they're basically Makefiles, except in a pickier format. | 10:25 |
| richard_maw | Kinnison: then it has to be in the artifact splitting logic, but it's working for x86_64 | 10:25 |
| persia | rjek: I take it you've never written an executable in make. | 10:25 |
| Kinnison | richard_maw: is there any logging in there rjek can turn on, or is it time for someone to write some investigatory tools to see if it's our filesystem interface squiffing on a combination of MIPS64 and ext3 ? | 10:28 |
| richard_maw | Kinnison: morphlib.builder2.ChunkBuilder.assemble_chunk_artifacts line 488 is where we get the file listing | 10:31 |
| Kinnison | yeah that was where I was | 10:33 |
| * richard_maw is currently pondering if the `os.path.islink` is failing | 10:34 | |
| Kinnison | can you write a quick test for rjek? | 10:34 |
| richard_maw | already working on it | 10:34 |
| rjek | >>> os.path.islink("bin") | 10:35 |
| rjek | True | 10:35 |
| richard_maw | rjek: that assumes the path is being checked in the same directory | 10:37 |
| rjek | >>> os.path.islink("../stage2-fhs-dirs.inst/bin") | 10:38 |
| rjek | True | 10:38 |
| rjek | >:) | 10:38 |
| richard_maw | I mean, the problem may be that the morph build code is checking whether the wrong "bin" is a symlink | 10:38 |
| rjek | Ah, right | 10:38 |
| richard_maw | the only chdir we do is for subprocesses | 10:41 |
| richard_maw | rjek: Can you strace the build, looking for stat calls? | 10:41 |
| richard_maw | without the "false" command to make it fail | 10:41 |
| rjek | /bin/sh: strace: not found | 10:42 |
| rjek | Also, I'm not sure strace is even supported on MIPS64 if I did have it. | 10:42 |
| richard_maw | hmm, then we'd have to instrument the call so we know its result, or take a leap of faith and change it to `if os.path.islink(os.path.join(dirname, x))` | 10:45 |
| richard_maw | and I'm not convinced we've found the culprit yet, since this link turns up on x86 builds | 10:45 |
| persia | instrumentation sounds safer, as it it doesn't work, it explains why, and if it does, it helps lead toward a real fix, rather than just something that happened to work today. | 10:46 |
| richard_maw | wait, the sumllink doesn't end up in the subdirs list anyway | 10:47 |
| richard_maw | s/sumllink/symlink/ | 10:47 |
| richard_maw | it's part of basenames | 10:47 |
| richard_maw | rjek: in the stage2-fhs-dirs.inst direcctory, can you run the following | 10:48 |
| richard_maw | import os | 10:48 |
| richard_maw | for dirname, subdirs, basenames in os.walk('.'): | 10:48 |
| richard_maw | for bn in basenames: print bn | 10:48 |
| rjek | Oh, that's interesting | 10:49 |
| rjek | http://pastebin.com/p1SCQ22f | 10:49 |
| Kinnison | erm, that's the etc | 10:50 |
| Kinnison | which we'd expect to see from the walk | 10:50 |
| richard_maw | but no "bin" | 10:50 |
| Kinnison | indeed | 10:50 |
| richard_maw | that's the interesting part | 10:50 |
| rjek | Shouldn't that be waling ./ not ./etc/ ? | 10:51 |
| richard_maw | walk is recursive | 10:51 |
| rjek | There are a lot more files in that directory than are listed there | 10:51 |
| Kinnison | If the symlink points at something which *works* then os.walk seems to not list it | 10:52 |
| rjek | I don't understand what that python snippet is doing | 10:52 |
| rjek | It appears to be listing only the files in ./etc | 10:53 |
| richard_maw | hm, links that point to an existing directory end up in the subdirs list, and links that are dangling end up in basenames | 10:55 |
| richard_maw | I think it's failing for you because you have a /tools/bin, so the link ends up in subdirs, and the os.path.islink check is failing | 10:56 |
| richard_maw | which explains why it worked for us, as we don't have a /tools/bin | 10:56 |
| richard_maw | and why it failed for you | 10:56 |
| rjek | So, this would still fail for x86_64 if it were beign cross bootstrapped? | 10:56 |
| richard_maw | yes | 10:56 |
| richard_maw | so the proper fix is to change it to os.path.islink(os.path.join(dirname, x)) | 10:57 |
| richard_maw | but you should be able to continue your builds by removing /tools | 10:57 |
| * rjek tries that | 10:57 | |
| Kinnison | s/removing/renaming | 10:57 |
| Kinnison | just in case | 10:57 |
| rjek | How do I unedit? | 10:57 |
| rjek | ie, the morph edit stage2-fhs-dirs I did. | 10:58 |
| Kinnison | delete the checked out branch and if you had made no other changes, git reset --hard in your definitions | 10:58 |
| * rjek types the magic runes in | 10:58 | |
| Kinnison | there's no 'morph unedit' :-( | 10:58 |
| rjek | OK, I don't think it's going to be safe to rename/remove /tools | 10:59 |
| rjek | Because the system's /bin and /lib64 etc are still symlinks to /tools | 10:59 |
| Kinnison | hmm | 10:59 |
| rjek | I need lunch. | 11:01 |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has joined #baserock | 11:03 | |
| *** stetaylor [~stetaylor@82-68-191-81.dsl.posilan.com] has quit [Remote host closed the connection] | 11:36 | |
| *** stetaylor [~stetaylor@82-68-191-81.dsl.posilan.com] has joined #baserock | 11:37 | |
| *** stetaylor [~stetaylor@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 240 seconds] | 11:41 | |
| * rjek has had lunch. | 12:13 | |
| Kinnison | I believe richard_maw has been working on a patch for the problem rjek exposed | 12:13 |
| rjek | yay | 12:16 |
| richard_maw | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=baserock/richardmaw/bugfix/symlink-include should fix it | 12:22 |
| *** stetaylor [~stetaylor@82-68-191-81.dsl.posilan.com] has joined #baserock | 12:23 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 240 seconds] | 12:33 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 12:38 | |
| richard_maw | SotK, persia: Sorry I haven't responded to e-mails yet, I'm needed to dig through the code to locate strange bugs | 13:12 |
| persia | richard_maw: No worries. On IRC, I expect replies in a day or so, but I belei.ve in symmetry, so if people respond to my email within three or four months, I count myself lucky | 13:13 |
| Kinnison | Goodnews, richard_maw's branch worked and we fixed the problem rjek was enduring. sotk will merge it | 13:19 |
| Kinnison | Badnews, rjek's back to stage2-eglibc -- yay interp. paths | 13:20 |
| rjek | :'-( | 13:22 |
| SotK | merged, and definitions updated | 13:25 |
| Kinnison | thanks sotk | 13:26 |
| Kinnison | SotK: Did you update both tools.morph and cross-bootstrap.morph ? | 13:26 |
| SotK | I updated the ref in both tools.morph and cross-bootstrap.morph so we don't get that problem again | 13:26 |
| Kinnison | yay | 13:26 |
| jjardon | Hi, today I had problem compiling another module because seems baserock version of busybox "ln" command doesnt support --relative. Any idea what is the plan forward for this? upgrade busybox? or maybe switch to use coreutils? | 13:29 |
| Kinnison | In the short-term I'd say "Upgrade busybox" | 13:30 |
| persia | jjardon: Is newer busybox free of these issues? If so, you might want to upgrade it (which would be useful anyway). | 13:30 |
| Kinnison | But if that won't solve your problem, then we may have to look at the harder-to-do coreutils switch | 13:30 |
| persia | jjardon: But given the number of issues you're finding, I wonder if you wouldn't do better to change your system to use coreutils. | 13:30 |
| * persia decides to stop typing, because Kinnison is saying the same things more concisely and faster | 13:31 | |
| jjardon | sure, only wanted to know if there was a prefered path to fix this. | 13:34 |
| jjardon | Can I ask why busybox is currently used instead coreutils? | 13:35 |
| Kinnison | Because busybox is one thing which gives us coreutils, findutils, util-linux etc | 13:36 |
| Kinnison | and has significantly less in the way of build-dependencies | 13:36 |
| Kinnison | because it's not autotoolised | 13:36 |
| jjardon | rigth, thanks for the explanation | 13:37 |
| liw-orc | we do have coreutils, but we prefer busybox in build-essential | 13:44 |
| persia | Is there a strong reason not to use coreutils in build-depends for GNOME? | 13:51 |
| jjardon | do not think this should be GNOME specific (the compilation problem is in systemd, for example) | 13:52 |
| richard_maw | jjardon: it's systemd specific, if you read back upstream were told by debian maintainers that this doesn't work on their build systems, and were told to either patch it, or update coreutils | 14:02 |
| richard_maw | so I think there's a patch floating around somewhere | 14:02 |
| richard_maw | IIRC we _have_ built coreutils by this point, so you could see if the version of coreutils we're using is too old to support --relative, or if we've told it not to provide ln | 14:03 |
| jjardon | richard_maw: ok, thanks. But AFAIK coreutils is in tools, and foundation doesnt depend on that strata | 14:05 |
| richard_maw | hm, I thought it was in core | 14:06 |
| jjardon | richard_maw: also we disable the build of all commands that are already in busybox | 14:16 |
| persia | Reviewing backscroll here, I wonder if we're being a bit overambitious to have a single "core", etc. | 14:21 |
| persia | While it makes thinking about these things convenient, I suspect that as we seek to support a wider variety of systems, it makes sense to have multiple paths. | 14:22 |
| persia | So that we can use the same build-essential suite over (slightly) different platforms to support variants from tiny little systems suitable for monitoring solar panel performance through to complex desktop environments. | 14:23 |
| persia | (MPI applications and distributed systems being somewhere between those extremes in terms of "system" compelxity for the semantic value of "system" used in Baserock, despite being massively more complicated than desktop environments for the semantic value of "system" used by HPC folk) | 14:24 |
| persia | Is this possible to achieve without either forking or massive duplication with current morph? | 14:24 |
| rjek | I think the only other "Linux distro" that aims to be universal in use (from embedded to supercomputer) is Debian, and it's not great at it. | 14:25 |
| persia | I'm not convinced "Baserock" and "Linux distro" are really the same category: I think of "Baserock" as being a set of tools to build distros. | 14:26 |
| persia | But that niggle aside, I entirely agree :) | 14:26 |
| persia | Plus, as my parenthetical note was intended to imply, desktops are harder than supercomputers. | 14:27 |
| persia | (To make a supercomputer, wire up as much of the newest, coolest kit one can afford via the fastest available interconnect, install a kernel, busybox, an MPI environment, and drivers for any co-processors, and create an account on a head node for a researcher. Sit back and pay cooling and electric bills. Simple.) | 14:28 |
| jjardon | FYI, our coreutils are indeed new enough to support --relative. Would it be ok to move them to foundation? | 15:18 |
| persia | I don't think that question can be answered here, but suspect there would be concerns about the minimal system at least. | 15:21 |
| persia | For your local definitions.git, I think it makes perfect sense to do the move: that will significantly reduce your build issues. | 15:21 |
| persia | For master, it probably needs discussion on the mailing list. | 15:21 |
| radiofree | i don't think the minimal system uses foundation? | 15:22 |
| pedroalvarez | iirc they dont'y use even core | 15:23 |
| Kinnison | pedro! | 15:23 |
| pedroalvarez | daniel! :D | 15:29 |
| rjek | Aww, sweet love. | 15:31 |
| pedroalvarez | btw, I can now confirm that a devel system running on OpenStack works with a Trove running on the same cloud | 15:33 |
| Kinnison | cool | 15:33 |
| persia | \o/ | 15:35 |
| richard_maw | minimal systems don't even use all of build-essential | 15:47 |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has quit [Remote host closed the connection] | 15:48 | |
| *** stetaylor [~stetaylor@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving...] | 16:26 | |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 17:00 | |
| *** franred [~franred@82-68-191-81.dsl.posilan.com] has quit [Remote host closed the connection] | 17:38 | |
| *** flatmush [~flatmush@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 260 seconds] | 17:53 | |
| *** flatmush [~flatmush@82-68-191-81.dsl.posilan.com] has joined #baserock | 19:03 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!