| paulsher1ood | http://www.bbc.co.uk/news/world-us-canada-33017310 | 01:37 |
|---|---|---|
| *** zoli__ has joined #baserock | 04:06 | |
| *** edcragg has joined #baserock | 04:21 | |
| *** edcragg has quit IRC | 04:26 | |
| *** zoli__ has quit IRC | 07:44 | |
| Kinnison | need more proprietary crap with insufficient eyes on it | 07:59 |
| *** zoli__ has joined #baserock | 08:01 | |
| jmacs | I'm using latest morph, definitions as of about midday yesterday | 08:07 |
| *** bashrc_ has joined #baserock | 08:10 | |
| paulsher1ood | jmacs: i'd suggest using ybd :) but it's not working since sandboxlib :/ | 08:14 |
| jmacs | I'm not familiar with ybd, and as a part-timer on baserock, I'm not sure whether I can invest time in learning it | 08:15 |
| SotK | jmacs: thats probably my fault, are you using a system which isn't in master? | 08:17 |
| jmacs | It's four patches on top of master | 08:17 |
| SotK | what does the `configure-extensions` part of the system definition look like? | 08:17 |
| SotK | each of the names needs to be prefixed with extensions/ since I moved them all | 08:18 |
| * SotK thought he had updated all of the systems in master, but might have missed something | 08:18 | |
| *** gary_perkins has joined #baserock | 08:18 | |
| paulsher1ood | SotK: maybe there's some documentation needs updating, and an email to the list describing this change for users? | 08:19 |
| jmacs | That sounds like it - my patch includes a new system definition | 08:21 |
| SotK | paulsher1ood: that sounds like a sensible idea | 08:22 |
| * SotK apologises for not thinking to do it at the time | 08:23 | |
| paulsher1ood | we all make mistakes, SotK :-) | 08:24 |
| paulsher1ood | SotK: at least you didn't break ybd... :) | 08:25 |
| SotK | heh :) | 08:25 |
| jmacs | Yep, that's fixed it | 08:25 |
| paulsher1ood | w00t :) | 08:26 |
| * paulsher1ood notices ssssam is not around to see https://github.com/CodethinkLabs/sandboxlib/issues/1 | 08:27 | |
| *** Krin has joined #baserock | 08:29 | |
| *** CTtpollard has joined #baserock | 08:30 | |
| pedroalvarez | paulsher1ood: so it bulds but it complains? | 08:35 |
| paulsher1ood | pedroalvarez: no, it breaks | 08:38 |
| paulsher1ood | i wonder how it was tested :) | 08:38 |
| *** edcragg has joined #baserock | 08:45 | |
| *** ssam2 has joined #baserock | 08:46 | |
| *** ChanServ sets mode: +v ssam2 | 08:46 | |
| straycat | python scoping strikes again | 08:46 |
| * Kinnison wonders why paulsher1ood blithely merged something without testing it first :) | 08:47 | |
| paulsher1ood | Kinnison: to explain some things by example :-) | 08:49 |
| paulsher1ood | Kinnison: at this point the cost of someone breaking master ybd is approximately zero | 08:50 |
| Kinnison | I see | 08:50 |
| *** mariaderidder has joined #baserock | 08:58 | |
| *** jonathanmaw has joined #baserock | 08:59 | |
| *** lachlanmackenzie has joined #baserock | 09:19 | |
| * richard_maw has ybd doing file stripping, unfortunately because ybd treats the system artifact construction as a definition that just has install-commands of the system integration commands, everything is then stripped again. | 09:32 | |
| richard_maw | Though this has no ill effects as the system artifact build never puts anything in the DESTDIR it creates | 09:33 |
| *** zoli__ has quit IRC | 09:33 | |
| *** zoli__ has joined #baserock | 09:34 | |
| paulsher1ood | richard_maw: is there much of a performance penalty? | 09:37 |
| paulsher1ood | (w00t, by the way :-)) | 09:37 |
| paulsher1ood | richard_maw: i confesst i still don't understand the si commands/install-commands thing... that was hard, so Kinnison did it :-) | 09:38 |
| *** zoli__ has quit IRC | 09:38 | |
| Kinnison | Meh, it just hoists content from one definition to another | 09:38 |
| Kinnison | mmmm hoist | 09:38 |
| paulsher1ood | petard :) | 09:39 |
| richard_maw | paulsher1ood: erm, performance penalty? In the system artifact construction it's a negligible constant factor (most expensive being another couple of calls to fork and exec). | 09:46 |
| richard_maw | paulsher1ood: For all the other builds it's pretty much O(N) where N is the number of executables or files with names that look like libraries, as the checks built-in to the find command are very cheap, since some of them are already in the dentry, and the stat result is cached by linux | 09:49 |
| ssam2 | seems that I broke system builds in YBD, oops | 09:53 |
| paulsher1ood | ssam2: i break it a lot, np :) | 09:53 |
| paulsher1ood | ssam2: is it easy to fix? | 09:53 |
| * richard_maw reworks the docstring of get_build_commands since it is incorrect after his change | 09:54 | |
| paulsher1ood | richard_maw: sorry, i asked the wrong question. re-trying: how much extra time does running split take? and how much extra time does re-running it take? | 09:55 |
| * paulsher1ood hears maniacal cackling in the office next door, and is reminded of: <richard_maw> morph deploy missiles missile-system-X32-generic planet://milky-way/sol/earth/luna TWIDDLE_BEARD=true | 09:56 | |
| richard_maw | paulsher1ood: yeah, X32 is a silly ABI | 09:57 |
| paulsher1ood | :) | 09:57 |
| richard_maw | For all the log information i have currently on screen, there's pretty much nothing in DESTDIR, so stripping takes less than a second. | 09:57 |
| richard_maw | It probably takes something on the order of milliseconds, but I don't have that fine-grained logging | 09:58 |
| paulsher1ood | ok seems tolerable :) | 09:58 |
| * Kinnison tsks | 09:58 | |
| Kinnison | luna is not a planet | 09:58 |
| paulsher1ood | lol | 09:58 |
| paulsher1ood | since Kinnison joined in, i hope he won't mind me quoting, from the same (private) page: < Kinnison> It must be easy though, since I know nothing about it | 09:59 |
| richard_maw | paulsher1ood: oh, and since timings aren't stored in the cache in YBD I can't give any data for anything with a meatier DESTDIR | 09:59 |
| Kinnison | I am emminently quotable | 09:59 |
| paulsher1ood | richard_maw: good point. that's an interesting feature to add... i'll make a note | 10:00 |
| paulsher1ood | how would someone glean that info in morph? | 10:00 |
| richard_maw | paulsher1ood: it's stored in the .meta file | 10:00 |
| paulsher1ood | makes sense | 10:01 |
| ssam2 | It seems wrong that https://github.com/devcurmudgeon/ybd/commit/4219d57ab3006b92ba0e157e45a49539c17689f1 (adding 'TZ' to build-time environment variables) hasn't triggered a change in the cache keys YBD generates for chunks | 10:26 |
| ssam2 | does the cache key algorithm not take environment variables into account? | 10:26 |
| paulsher1ood | good point± | 10:28 |
| paulsher1ood | i'll need to check | 10:28 |
| paulsher1ood | i don't claim that it takes everything into account... i got it close enough for my own purposes at the time | 10:28 |
| paulsher1ood | ssam2: thanks for the fix, btw | 10:29 |
| paulsher1ood | and tested on armv7 ... yay! | 10:29 |
| richard_maw | I know build commands that came from the build systems aren't part of the cache key, since they only get unified during assembly.build(), and the cache checking happens before that. | 10:29 |
| ssam2 | generating cache keys is really tricky to get right. It's a small amount of code but really important | 10:29 |
| paulsher1ood | richard_maw: true | 10:29 |
| ssam2 | miss something, and you can't trust the bit-for-bit reproducibility. Include too much, and you're constantly rebuilding stuff | 10:30 |
| paulsher1ood | richard_maw: does morph process those commands into its key? | 10:30 |
| richard_maw | paulsher1ood: It does | 10:30 |
| paulsher1ood | ssam2: yup :) | 10:30 |
| paulsher1ood | ssam2: however, i have a surprise for you.... | 10:30 |
| richard_maw | paulsher1ood: So we can change the build systems without needing to invalidate all previously cached objects | 10:31 |
| paulsher1ood | would you like to take a guess? | 10:31 |
| ssam2 | it does include the environment? | 10:31 |
| richard_maw | If it's a Mac, I think he's already got one. | 10:31 |
| paulsher1ood | ssam2: no, not that | 10:31 |
| ssam2 | ok, i'm stuck | 10:31 |
| ssam2 | is it a pie? | 10:31 |
| paulsher1ood | heh. ok. i'm doign a talk on ybd tonight, i'll save it for then if that's ok | 10:31 |
| paulsher1ood | i believe the talk may be recorded, so it might get shared publicly if i don't swear too much or mention wind river :0 | 10:32 |
| paulsher1ood | oops | 10:32 |
| ssam2 | more excitement in my day! | 10:32 |
| * SotK hopes it is recorded | 10:32 | |
| paulsher1ood | DavePage: no pressure ^^ | 10:32 |
| richard_maw | paulsher1ood: Erm, YBD's caching logic is wrong. assembly.assemble() checks whether it's built it before by generating the cache key before build and checking whether the cache has that. If there's a cache miss though, it does a build, and as part of assembly.build() it modifies its state by including commands from the build system. The result being that it will then cache the result as something entirely different to that which it checked for | 10:37 |
| paulsher1ood | richard_maw: wow. that's serious, if you're right | 10:38 |
| Kinnison | no it won't | 10:39 |
| paulsher1ood | richard_maw: but ybd generates the cache-keys before assembel? | 10:39 |
| Kinnison | it'll cache it under the key it generated pre-frobbing | 10:39 |
| Kinnison | so it caches it under a key which doesn't represent what was built | 10:39 |
| Kinnison | hence it doesn't permanently rebuild | 10:39 |
| * paulsher1ood wipes his brow, and returns to emails | 10:40 | |
| Kinnison | Oh it's still bloody awful | 10:40 |
| Kinnison | But it's less awful than it could have been | 10:40 |
| Kinnison | It's just dangerously wrong, rather than annoying | 10:40 |
| richard_maw | oh, I missed how cache.cache_key caches the cache key computation | 10:40 |
| * paulsher1ood looks at the commandments, to see which one insists that code must not be awful | 10:40 | |
| Kinnison | Your commandments are not the be-all-and-end-all | 10:41 |
| paulsher1ood | Kinnison: not in general, no. but for ybd, they are | 10:41 |
| Kinnison | Also, commandment 22 | 10:41 |
| Kinnison | 22. Quality code WORKS! All the time | 10:41 |
| Kinnison | this requires that your code have this enigmatic 'quality' | 10:42 |
| Kinnison | which awful code does not (IMO) | 10:42 |
| paulsher1ood | yup. ybd is getting there on that one. all bugs gratefully accepted. | 10:42 |
| * Kinnison makes a note to code up a PR full of bugs | 10:42 | |
| paulsher1ood | yummy :) | 10:43 |
| *** straycat has left #baserock | 10:43 | |
| ratmice___ | now if we could just get phaedrus to define quality for us | 10:43 |
| * richard_maw foolishly assumed that cache_key didn't have side-effects | 10:43 | |
| paulsher1ood | :) | 10:44 |
| paulsher1ood | is this a bit like one person's bug is another's feature? | 10:47 |
| paulsher1ood | cache_key returns the key. if it hasn't been calculated yet it does that, and saves it in definitions. what's the side-effect? | 10:48 |
| Kinnison | I just had a discussion with richard -- nominally it's mutating its input | 10:51 |
| Kinnison | however really the bad side-effect is in assembly.build() | 10:51 |
| Kinnison | where it mutates the input to an earlier computation | 10:51 |
| Kinnison | which, if ybd were implemented in k, wouldn't be an issue | 10:51 |
| Kinnison | but in almost every other language, it is | 10:51 |
| * paulsher1ood will need caffiene before attempting ton understand the above... but thanks! | 10:53 | |
| rjek | K is not a language you want to read about unless you enjoy headaches. | 10:53 |
| Kinnison | paulsher1ood: If you want, and are closeby, I can draw you a diagram on the whiteboard | 10:53 |
| paulsher1ood | let me phrase this another way... is the issue here 'code style' or 'actual risk of breakage' ? | 10:54 |
| Kinnison | the latter | 10:54 |
| Kinnison | hence: 11:40 < Kinnison> It's just dangerously wrong, rather than annoying | 10:54 |
| paulsher1ood | ok, then i need to understand, will get my coffee and think harder. thanks | 10:54 |
| Kinnison | :) | 10:54 |
| richard_maw | hm, mason is confused because it successfully built, but failed to find what it build to do the deploy test | 10:54 |
| Kinnison | richard_maw: oops? | 10:54 |
| richard_maw | https://mason-x86-64.baserock.org/log/b6cdb33f041fbeab7aba4c2658d5163fe7410871--2015-06-04%2021:27:27.log | 10:54 |
| Kinnison | richard_maw: btw, how is your strip-commands topic for morph coming? | 10:55 |
| richard_maw | Kinnison: I'm done with the YBD support changes now, so I'm going to send that to paulsher1ood, then go and fix up the bits for the review. | 10:56 |
| Kinnison | cool | 10:56 |
| * richard_maw is annoyed by github pull requests | 10:57 | |
| Kinnison | shocking | 10:57 |
| * richard_maw actually prefers Gerrit | 10:58 | |
| Kinnison | Outrageous! | 10:59 |
| richard_maw | paulsher1ood: pull request sent | 11:01 |
| paulsher1ood | richard_maw: tvm! | 11:01 |
| * richard_maw is too annoyed by Github's UI to attach any message to the cover letter | 11:01 | |
| paulsher1ood | merged :) | 11:02 |
| * richard_maw attempts to locate caffeine | 11:02 | |
| * Kinnison attempts to locate food | 11:02 | |
| ssam2 | tlsa: regards specifying environment variables for sandboxlib, the run_sandbox() function takes an 'env' parameter | 11:05 |
| ssam2 | if 'env' is None or empty then so is the environment in the sandbox | 11:05 |
| ssam2 | if it's a dict (in the style of os.environ) then those environment variables are set in the sandbox | 11:06 |
| tlsa | I need to set a couple of environement vaiables in the sandbox, if a particular library is present in the sandbox | 11:06 |
| ssam2 | ok, look in sandbox.run_sandboxed() in ybd | 11:07 |
| ssam2 | it does 'env = os.environ' in there | 11:07 |
| tlsa | ok | 11:07 |
| ssam2 | so you can either add the vars to 'env' after that line | 11:07 |
| ssam2 | or modify os.environ directly in the clean_env() function (or wherever else) if that's easier | 11:07 |
| richard_maw | just be careful modifying os.environ, it's a magic dict that modifies your process' environment | 11:08 |
| richard_maw | so pass around copy of it rather than the object itself | 11:08 |
| ssam2 | ybd mutates it directly in sandbox.setup() | 11:09 |
| richard_maw | so it mutates the current environment, rather than passing a copy of it to subprocess.Popen? | 11:15 |
| tlsa | would it be OK to run | 11:16 |
| tlsa | [ -f /usr/lib/faketime/libfaketime.so.1 ] && export FAKETIME="2015-01-01 00:00:00" && export LD_PRELOAD="/usr/lib/faketime/libfaketime.so.1" | 11:16 |
| tlsa | in the sandbox? | 11:16 |
| paulsher1ood | tlsa: why wouldn't it be? | 11:21 |
| ssam2 | richard_maw: it now mutates its own environment, *then* passes a copy of it to sandboxlib.run_sandbox(). Previously it mutated the current environment and then subprocess.Popen() inherited it | 11:21 |
| paulsher1ood | looks ok to me? | 11:21 |
| ssam2 | tlsa: as long as the libc ABI matches ... I don't know if that would work with musl, for example. | 11:22 |
| ssam2 | i don't think we have an alternative though, other than running builds in a VM where the clock never ticks | 11:22 |
| paulsher1ood | ssam2: so if (various checks which we learn as folks break them): do what tlsa suggests, else report (can't use libfaketime)? | 11:23 |
| tlsa | paulsher1ood: I don't know, hence the question. :) | 11:23 |
| tlsa | for one thing, I'd be trampling LD_PRELOAD. Does anything else about sandboxing use it? If so what's it doing? | 11:24 |
| paulsher1ood | tlsa: let's try it, then. so long as it doesn't break the main use case (ybd clusters/release.morph and whatever else in mainline), and works as you expect, i'll take it | 11:24 |
| richard_maw | possibly a good reason to use the faketime binary instead of setting LD_PRELOAD directly | 11:24 |
| ssam2 | paulsher1ood: I fear that's the only approach, yes. But all these condition shell scripts remind me of OpenEmbedded. | 11:24 |
| ssam2 | *conditional | 11:24 |
| ssam2 | tlsa: nothing in sandboxlib uses LD_PRELOAD right now | 11:24 |
| tlsa | ok | 11:25 |
| paulsher1ood | ssam2: i am hurt :) | 11:25 |
| paulsher1ood | or maybe i should feel complemented. OE is a very popular project with a long pedigree | 11:25 |
| ssam2 | no personal offence intended. But one thing I like about Baserock right now is we avoid needing stuff like this: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/bitbake.conf | 11:27 |
| ssam2 | but the more "load libfaketime if it exists in the staging area"-type things we add, the more code paths there are to test, and the harder the code becomes to understand | 11:27 |
| tlsa | richard_maw: to use the faketime binary, before running any chunk commands, I'd need to inspect the sandbox contents in ybd, and depending on whether faketime binary is there, decide whether to prepend faketime to the chunk commands | 11:27 |
| ssam2 | this may be an unavoidable part of making the tools actually do useful things, of course! | 11:27 |
| ssam2 | code and reality never get on very well | 11:28 |
| paulsher1ood | gah.... MY EYES!!!! | 11:28 |
| * richard_maw tries to work out exactly what language that is written in | 11:28 | |
| paulsher1ood | cobol? | 11:28 |
| *** zoli__ has joined #baserock | 11:28 | |
| richard_maw | it's an unholy union of Make, shell and python | 11:29 |
| *** zoli___ has joined #baserock | 11:37 | |
| *** Krin has quit IRC | 11:39 | |
| *** zoli__ has quit IRC | 11:40 | |
| paulsher1ood | radiofree: are you looking at moonshot? | 11:40 |
| paulsher1ood | if you're using ybd you may need latest version | 11:41 |
| radiofree | why would i need the latest version? | 11:41 |
| radiofree | morph built stage2-glibc fine btw | 11:41 |
| radiofree | trying ybd under baserock now | 11:41 |
| radiofree | does the latest version fix that issue? | 11:42 |
| paulsher1ood | radiofree: something was screwy if /src didn't exist | 11:42 |
| paulsher1ood | fixed now (it makes /src if there isn't one) | 11:42 |
| radiofree | that doesn't seem like a very good fix | 11:42 |
| paulsher1ood | i agree, but it's a fix | 11:42 |
| radiofree | does that fix the issue with stage2-glibc? | 11:43 |
| * paulsher1ood can't remember what that issue looked like | 11:43 | |
| paulsher1ood | what's the error? | 11:43 |
| paulsher1ood | if it's MSBIND, then yes i think it fixes it | 11:43 |
| richard_maw | paulsher1ood: issue was a crash on the first build due to mount(MS_BIND) failing | 11:43 |
| paulsher1ood | :) | 11:43 |
| paulsher1ood | i think permissions under /root are different | 11:44 |
| radiofree | no it's not that issue | 11:44 |
| radiofree | i don't have the log to hand | 11:44 |
| paulsher1ood | ok np | 11:44 |
| paulsher1ood | i need to eat anyway | 11:44 |
| * paulsher1ood heads for biryani | 11:44 | |
| * radiofree will try master in a moment anyway | 11:44 | |
| richard_maw | a. That's not usually the case and b. File permissions wouldn't cause the mount to fail. The error code was because some file that we asked it to mark as read-only didn't exist. | 11:45 |
| richard_maw | I have no idea how that works back to not having /src | 11:45 |
| radiofree | i'll do a full build of baesrock on this moonshot (using morph) later actually, just to make sure everything aarch64 is well | 11:45 |
| paulsher1ood | richard_maw: ack | 11:45 |
| paulsher1ood | radiofree: great! | 11:45 |
| paulsher1ood | richard_maw: it's a head scratcher, but too deep for me | 11:47 |
| richard_maw | btw, going back to the /home/root vs /root confusion. It's separate because /home may be mounted from a different disk, and you need some user around to do the maintainance, so /root is stored separately | 11:47 |
| *** radiofree has quit IRC | 11:48 | |
| *** radiofree has joined #baserock | 11:49 | |
| *** Krin has joined #baserock | 11:51 | |
| rdale | what is a python .egg package? i can't seem to import on i've just installed | 12:04 |
| richard_maw | Kinnison: what is your opinion of my justification for not using pyfilesystem in https://gerrit.baserock.org/#/c/772/ ? | 12:45 |
| *** zoli___ has quit IRC | 12:46 | |
| Kinnison | given the utf8 thing, I'm fine with your approach and my +1 stands | 12:46 |
| *** zoli__ has joined #baserock | 12:46 | |
| richard_maw | cool, I've got a v2 of the next patch after that, which gets rid of the last place we used the pyfilesystem cleaning up tempdir abstraction that I could find | 12:47 |
| paulsher1ood | richard_maw: would you be willing to put the equivalent into ybd? it looks sensiblbe | 12:48 |
| *** zoli___ has joined #baserock | 12:49 | |
| richard_maw | paulsher1ood: you've already got your strip-commands patches! | 12:49 |
| paulsher1ood | richard_maw: lol | 12:49 |
| paulsher1ood | i want the moon on a stick :) | 12:49 |
| paulsher1ood | i'll crib yours and claim i thought of it, then | 12:49 |
| paulsher1ood | richard_maw: i'm already using the strip-commands patches and everything seems lovely :-) | 12:50 |
| richard_maw | paulsher1ood: if you meet your claim of supporting python3, then you don't need our implementation, as there's a version in the tempfile standard library module | 12:51 |
| paulsher1ood | ah, my claim of python3? not checked. jjardon suggested it, i'd like it to be true | 12:51 |
| richard_maw | I'm fairly sure you don't btw, I saw a bare print statement, which is forbidden in python3 | 12:52 |
| paulsher1ood | i found it irritatingly difficult to have python3 on br | 12:52 |
| *** zoli__ has quit IRC | 12:52 | |
| SotK | that bare print is the only thing I've noticed that would stop it I think | 12:52 |
| paulsher1ood | what's the easiest way to try? is anyone running ybd already on a linux with python3? | 12:53 |
| richard_maw | SotK: that's what would make it fail immediately, there's a few more subtle changes involved too | 12:53 |
| * SotK finds it mildly annoying that ybd has `#!/usr/bin/env python3` when its not quite the case | 12:53 | |
| paulsher1ood | SotK: would you like to offer a pr? if not i'll get to it | 12:54 |
| SotK | paulsher1ood: I'm accumulating a branch of small fixes locally, but feel free to fix it if you have time :) | 12:55 |
| paulsher1ood | ok, let's see who gets to it first. i won't be touching ybd myself til after the talk, now. will accept pr though | 12:57 |
| richard_maw | hmm, the tempfile module in python3 doesn't cater too well to the use-case of atomic file/directory creation | 13:03 |
| Kinnison | quick, port the whole lot to caml | 13:04 |
| richard_maw | er, what? | 13:04 |
| *** straycat has joined #baserock | 13:06 | |
| pedroalvarez | jmacs, straycat: do you remember why ntpd has to be used (swift and ceph) and why we don't use systemd's ntpd service instead? | 13:07 |
| pedroalvarez | systemd-timesyncd, i believe | 13:07 |
| straycat | pedroalvarez, because swift nodes need to have their time internally synchronised | 13:07 |
| jmacs | Not immediately, but I could check my notes | 13:07 |
| richard_maw | pedroalvarez: AIUI it's because swift needed one of hte nodes to be an NTP server | 13:07 |
| richard_maw | pedroalvarez: systemd's ntpd is client only | 13:07 |
| pedroalvarez | ah,. | 13:09 |
| pedroalvarez | I thought they only needed ntpd runing, to sync the time with a time server, and all of them syncing with the same one | 13:10 |
| jmacs | The original reason we added a ntpd explicitly is because Chef was trying to check the version of it, and "ntpd --version" doesn't work if ntpd is actually busybox. | 13:10 |
| pedroalvarez | I see | 13:11 |
| richard_maw | Kinnison: I pushed a v2 branch of https://gerrit.baserock.org/#/c/773/2 The change is to https://gerrit.baserock.org/#/c/773/2/morphlib/plugins/artifact_inspection_plugin.py | 13:16 |
| pedroalvarez | ok, then, if I want to sync some servers, I have to run ntpd in one of them, and then the others can just run systemd-timesyncd | 13:22 |
| pedroalvarez | hm.. I think that in a 3 nodes deployment of OpenStack, everynode is going to run ntpd | 13:25 |
| *** Krin has quit IRC | 13:26 | |
| straycat | pedroalvarez, yes, but only the controller will run as a time server | 13:27 |
| straycat | the rest will fetch their time from the controller | 13:27 |
| pedroalvarez | ahá | 13:27 |
| * pedroalvarez continues investigating then :) | 13:28 | |
| pedroalvarez | straycat: is "the rest", "swift storage nodes" ? | 13:29 |
| pedroalvarez | or it will also be network and compute node? | 13:29 |
| straycat | it also includes network and compute, see http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/install-files/swift/etc/ntp.conf | 13:31 |
| pedroalvarez | oh, I failed to find that file | 13:32 |
| pedroalvarez | straycat: thanks | 13:32 |
| straycat | np :) | 13:32 |
| pedroalvarez | great | 13:33 |
| *** Krin has joined #baserock | 13:34 | |
| ssam2 | Kinnison: I've discovered a repo in a Trove (thankfully an internal one!) where the gitano admin ref is corrupt | 13:50 |
| ssam2 | any advice on what to do? | 13:50 |
| ssam2 | I get this: | 13:50 |
| ssam2 | git cat-file -t refs/gitano/admin | 13:50 |
| ssam2 | error: object file objects/92/90a4c6a7838a6f169b26d0d7b6142a36641d11 is empty | 13:50 |
| ssam2 | fatal: git cat-file refs/gitano/admin: bad file | 13:50 |
| jjardon | paulsher1ood: when I made the patch, all the code of ybd was python3 compliant; not sure if changes after make this not true | 13:50 |
| jjardon | BTW, there is a python3 stratum if you want to create a system with it | 13:51 |
| Kinnison | ssam2: Oh dear, that's not good | 13:51 |
| Kinnison | ssam2: from that I take it you have access to the git@ user on the trove? | 13:51 |
| ssam2 | `git fsck` reports the same thing: that object is empty | 13:51 |
| Kinnison | ssam2: from a shell? | 13:51 |
| ssam2 | Kinnison: yes | 13:51 |
| ssam2 | (it's ct-mcr-1) | 13:51 |
| Kinnison | ssam2: step one then will be: git update-ref -d refs/gitano/admin | 13:52 |
| Kinnison | ssam2: then ssh git@localhost config repo/path/and/name project.owner $whoevershouldownthis | 13:52 |
| Kinnison | erm | 13:52 |
| Kinnison | ssam2: then ssh git@localhost config repo/path/and/name set project.owner $whoevershouldownthis | 13:52 |
| Kinnison | that | 13:52 |
| Kinnison | if it's in delta/ then the owner should always be lorry | 13:52 |
| ssam2 | ok, thanks | 13:53 |
| Kinnison | If you have further issues, let me know | 13:53 |
| Kinnison | (It might be a good idea for you to put together a troubleshooting-troves page on the wiki with things like that in) | 13:53 |
| ssam2 | same problem with another repo further down the list... | 13:58 |
| ssam2 | maybe this is a bug in commit 4b8ce6875266fdd6609a217dcf2924d7d4815cc2 of gitano... | 13:58 |
| ssam2 | (or earlier) | 13:58 |
| * Kinnison hmms and looks | 14:03 | |
| Kinnison | that's not a commit of gitano | 14:04 |
| ssam2 | right, it's http://git.baserock.org/cgi-bin/cgit.cgi/delta/gitano/gitano.git/commit/?id=4b8ce6875266fdd6609a217dcf2924d7d4815cc2 | 14:04 |
| ssam2 | maybe that's BR-specific | 14:04 |
| ssam2 | actually, this Trove is old and unloved, but was updated a month or two ago | 14:05 |
| ssam2 | so the ref of Gitano that it's currently using isn't so relevant, the breakage could have been caused before it was upgraded | 14:05 |
| ssam2 | or by something during the upgrade | 14:05 |
| ssam2 | ignore me :) | 14:05 |
| * Kinnison has never had any other gitano instance have this kind of issue | 14:06 | |
| Kinnison | *but* troves are among the heaviest gitano users | 14:06 |
| rjek | ISTR a trove here getting into an awful mess with similar-sounding git errors when a btrfs got full once | 14:07 |
| radiofree | so ybd thinks it's building arm32 | 14:08 |
| radiofree | checking linker output format... elf32-littlearm | 14:08 |
| radiofree | probably due to some armv8l64 -> aarch64 confusion | 14:08 |
| paulsher1ood | radiofree: what command line did you give it/ | 14:09 |
| radiofree | ybd systems/build-system-armv8l64.morph armv8l64 | 14:09 |
| Kinnison | If ybd isn't setting the target arch environment right it could be a problem | 14:10 |
| radiofree | paulsher1ood: this is the same issue you had the other day http://paste.baserock.org/ateyezikod#394 | 14:10 |
| radiofree | line 394 | 14:10 |
| radiofree | yes, forcing the arch in the system/command line to aarch64 works | 14:14 |
| radiofree | at least we know what it is now | 14:15 |
| * radiofree prods things | 14:15 | |
| radiofree | does gcc get the target from the first bit of the TARGET env? | 14:23 |
| radiofree | e.g AARCH64-this-can-be-whatever-it-doesnt-matter | 14:23 |
| *** zoli___ has quit IRC | 14:28 | |
| Kinnison | ssam2: the commit you mention doesn't touch repo.lua which is pretty much the only place that ref is mangled | 14:29 |
| Kinnison | ssam2: I'd be willing to bet it's an FS corruption or similar | 14:29 |
| * Kinnison is surprised gitano didn't repair it though | 14:29 | |
| Kinnison | normally it tries to repair (even if by replacement) the adminref | 14:31 |
| *** zoli__ has joined #baserock | 14:35 | |
| radiofree | paulsher1ood: i take it you're supposed to be allowed to do ybd system/system-armv8l64.morph aarch64 ? | 14:42 |
| radiofree | it doesn't work anyway, i think i'll just do the same mapping morph does | 14:42 |
| ssam2 | Kinnison: does https://gerrit.baserock.org/#/c/790 look ok for the 'allow pushing tags in mirrored repos' patch we talked about? | 15:03 |
| Kinnison | see comments | 15:05 |
| ssam2 | thanks | 15:07 |
| *** jonathanmaw has quit IRC | 15:12 | |
| franred | Openstack in Baserock Kilo tempests results: Running Api tests: Ran 1121 tests in 6572.448s FAILED (failures=11) Skipped 143 | 15:12 |
| franred | Services: Ran 26 tests in 49.197s FAILED (failures=1) Skipped 6 | 15:12 |
| Kinnison | Getting close | 15:13 |
| franred | cmd: Ran 1 test in 3.584s No failures Skipped 1 | 15:13 |
| pedroalvarez | really close :) | 15:13 |
| franred | cli: Ran 33 tests in 45.029s No failures Skipped 1 | 15:13 |
| franred | scenario, stress and thirparty are not configured at the moment | 15:13 |
| franred | to run any test for them | 15:13 |
| franred | yeah, pretty pretty close :) | 15:14 |
| *** Krin has quit IRC | 15:34 | |
| *** Krin has joined #baserock | 15:46 | |
| richard_maw | \o/ mason is green again | 15:46 |
| SotK | at last! | 15:46 |
| richard_maw | build started at midnight, duration 52883s | 15:47 |
| pedroalvarez | that is because it builds 4 times every chunk | 15:50 |
| paulsher1ood | radiofree: i don't know, the aarch stuff is a mystery to me still | 15:51 |
| radiofree | paulsher1ood: i like the idea of having it as a command line option, but it's a bit useless at the moment | 15:52 |
| radiofree | although, since we don't cross compile it's always going to be useless? | 15:52 |
| radiofree | e.g you'll never be able to do ybd build-system.morph armv7 | 15:52 |
| radiofree | on x86 | 15:52 |
| *** Krin has quit IRC | 15:53 | |
| radiofree | paulsher1ood: make fails | 16:04 |
| * radiofree will check morph can build it | 16:05 | |
| radiofree | builds using morph, could be the aarch change, test again | 16:33 |
| *** CTtpollard has quit IRC | 16:53 | |
| *** bashrc_ has quit IRC | 17:03 | |
| *** edcragg has quit IRC | 17:09 | |
| *** gary_perkins has quit IRC | 17:10 | |
| radiofree | 2015-06-05 17:02:47 [stage2-make] Elapsed time 00:00:19 | 17:25 |
| radiofree | as good a place to leave it as any i think | 17:25 |
| *** mariaderidder has quit IRC | 17:25 | |
| *** ssam2 has quit IRC | 17:36 | |
| *** zoli___ has joined #baserock | 17:50 | |
| *** zoli__ has quit IRC | 17:54 | |
| *** zoli___ has quit IRC | 18:03 | |
| *** lachlanmackenzie has quit IRC | 18:33 | |
| *** zoli__ has joined #baserock | 20:04 | |
| *** zoli___ has joined #baserock | 20:06 | |
| *** zoli__ has quit IRC | 20:10 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!