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

paulsher1oodhttp://www.bbc.co.uk/news/world-us-canada-3301731001:37
*** zoli__ has joined #baserock04:06
*** edcragg has joined #baserock04:21
*** edcragg has quit IRC04:26
*** zoli__ has quit IRC07:44
Kinnisonneed more proprietary crap with insufficient eyes on it07:59
*** zoli__ has joined #baserock08:01
jmacsI'm using latest morph, definitions as of about midday yesterday08:07
*** bashrc_ has joined #baserock08:10
paulsher1oodjmacs: i'd suggest using ybd :) but it's not working since sandboxlib :/08:14
jmacsI'm not familiar with ybd, and as a part-timer on baserock, I'm not sure whether I can invest time in learning it08:15
SotKjmacs: thats probably my fault, are you using a system which isn't in master?08:17
jmacsIt's four patches on top of master08:17
SotKwhat does the `configure-extensions` part of the system definition look like?08:17
SotKeach of the names needs to be prefixed with extensions/ since I moved them all08:18
* SotK thought he had updated all of the systems in master, but might have missed something08:18
*** gary_perkins has joined #baserock08:18
paulsher1oodSotK: maybe there's some documentation needs updating, and an email to the list describing this change for users?08:19
jmacsThat sounds like it - my patch includes a new system definition08:21
SotKpaulsher1ood: that sounds like a sensible idea08:22
* SotK apologises for not thinking to do it at the time08:23
paulsher1oodwe all make mistakes, SotK :-)08:24
paulsher1oodSotK: at least you didn't break ybd... :)08:25
SotKheh :)08:25
jmacsYep, that's fixed it08:25
paulsher1oodw00t :)08:26
* paulsher1ood notices ssssam is not around to see https://github.com/CodethinkLabs/sandboxlib/issues/108:27
*** Krin has joined #baserock08:29
*** CTtpollard has joined #baserock08:30
pedroalvarezpaulsher1ood: so it bulds but it complains?08:35
paulsher1oodpedroalvarez: no, it breaks08:38
paulsher1oodi wonder how it was tested :)08:38
*** edcragg has joined #baserock08:45
*** ssam2 has joined #baserock08:46
*** ChanServ sets mode: +v ssam208:46
straycatpython scoping strikes again08:46
* Kinnison wonders why paulsher1ood blithely merged something without testing it first :)08:47
paulsher1oodKinnison: to explain some things by example :-)08:49
paulsher1oodKinnison: at this point the cost of someone breaking master ybd is approximately zero08:50
KinnisonI see08:50
*** mariaderidder has joined #baserock08:58
*** jonathanmaw has joined #baserock08:59
*** lachlanmackenzie has joined #baserock09: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_mawThough this has no ill effects as the system artifact build never puts anything in the DESTDIR it creates09:33
*** zoli__ has quit IRC09:33
*** zoli__ has joined #baserock09:34
paulsher1oodrichard_maw: is there much of a performance penalty?09:37
paulsher1ood(w00t, by the way :-))09:37
paulsher1oodrichard_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 IRC09:38
KinnisonMeh, it just hoists content from one definition to another09:38
Kinnisonmmmm hoist09:38
paulsher1oodpetard :)09:39
richard_mawpaulsher1ood: 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_mawpaulsher1ood: 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 linux09:49
ssam2seems that I broke system builds in YBD, oops09:53
paulsher1oodssam2: i break it a lot, np :)09:53
paulsher1oodssam2: is it easy to fix?09:53
* richard_maw reworks the docstring of get_build_commands since it is incorrect after his change09:54
paulsher1oodrichard_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=true09:56
richard_mawpaulsher1ood: yeah, X32 is a silly ABI09:57
paulsher1ood:)09:57
richard_mawFor 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_mawIt probably takes something on the order of milliseconds, but I don't have that fine-grained logging09:58
paulsher1oodok seems tolerable :)09:58
* Kinnison tsks09:58
Kinnisonluna is not a planet09:58
paulsher1oodlol09:58
paulsher1oodsince 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 it09:59
richard_mawpaulsher1ood: oh, and since timings aren't stored in the cache in YBD I can't give any data for anything with a meatier DESTDIR09:59
KinnisonI am emminently quotable09:59
paulsher1oodrichard_maw: good point. that's an interesting feature to add... i'll make a note10:00
paulsher1oodhow would someone glean that info in morph?10:00
richard_mawpaulsher1ood: it's stored in the .meta file10:00
paulsher1oodmakes sense10:01
ssam2It 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 chunks10:26
ssam2does the cache key algorithm not take environment variables into account?10:26
paulsher1oodgood point±10:28
paulsher1oodi'll need to check10:28
paulsher1oodi don't claim that it takes everything into account... i got it close enough for my own purposes at the time10:28
paulsher1oodssam2: thanks for the fix, btw10:29
paulsher1oodand tested on armv7 ... yay!10:29
richard_mawI 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
ssam2generating cache keys is really tricky to get right. It's a small amount of code but really important10:29
paulsher1oodrichard_maw: true10:29
ssam2miss something, and you can't trust the bit-for-bit reproducibility. Include too much, and you're constantly rebuilding stuff10:30
paulsher1oodrichard_maw: does morph process those commands into its key?10:30
richard_mawpaulsher1ood: It does10:30
paulsher1oodssam2: yup :)10:30
paulsher1oodssam2: however, i have a surprise for you....10:30
richard_mawpaulsher1ood: So we can change the build systems without needing to invalidate all previously cached objects10:31
paulsher1oodwould you like to take a guess?10:31
ssam2it does include the environment?10:31
richard_mawIf it's a Mac, I think he's already got one.10:31
paulsher1oodssam2: no, not that10:31
ssam2ok, i'm stuck10:31
ssam2is it a pie?10:31
paulsher1oodheh. ok. i'm doign a talk on ybd tonight, i'll save it for then if that's ok10:31
paulsher1oodi believe the talk may be recorded, so it might get shared publicly if i don't swear too much or mention wind river :010:32
paulsher1oodoops10:32
ssam2more excitement in my day!10:32
* SotK hopes it is recorded10:32
paulsher1oodDavePage: no pressure ^^10:32
richard_mawpaulsher1ood: 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 for10:37
paulsher1oodrichard_maw: wow. that's serious, if you're right10:38
Kinnisonno it won't10:39
paulsher1oodrichard_maw: but ybd generates the cache-keys before assembel?10:39
Kinnisonit'll cache it under the key it generated pre-frobbing10:39
Kinnisonso it caches it under a key which doesn't represent what was built10:39
Kinnisonhence it doesn't permanently rebuild10:39
* paulsher1ood wipes his brow, and returns to emails10:40
KinnisonOh it's still bloody awful10:40
KinnisonBut it's less awful than it could have been10:40
KinnisonIt's just dangerously wrong, rather than annoying10:40
richard_mawoh, I missed how cache.cache_key caches the cache key computation10:40
* paulsher1ood looks at the commandments, to see which one insists that code must not be awful10:40
KinnisonYour commandments are not the be-all-and-end-all10:41
paulsher1oodKinnison: not in general, no. but for ybd, they are10:41
KinnisonAlso, commandment 2210:41
Kinnison22. Quality code WORKS! All the time10:41
Kinnisonthis requires that your code have this enigmatic 'quality'10:42
Kinnisonwhich awful code does not (IMO)10:42
paulsher1oodyup. ybd is getting there on that one. all bugs gratefully accepted.10:42
* Kinnison makes a note to code up a PR full of bugs10:42
paulsher1oodyummy :)10:43
*** straycat has left #baserock10:43
ratmice___now if we could just get phaedrus to define quality for us10:43
* richard_maw foolishly assumed that cache_key didn't have side-effects10:43
paulsher1ood:)10:44
paulsher1oodis this a bit like one person's bug is another's feature?10:47
paulsher1oodcache_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
KinnisonI just had a discussion with richard -- nominally it's mutating its input10:51
Kinnisonhowever really the bad side-effect is in assembly.build()10:51
Kinnisonwhere it mutates the input to an earlier computation10:51
Kinnisonwhich, if ybd were implemented in k, wouldn't be an issue10:51
Kinnisonbut in almost every other language, it is10:51
* paulsher1ood will need caffiene before attempting ton understand the above... but thanks!10:53
rjekK is not a language you want to read about unless you enjoy headaches.10:53
Kinnisonpaulsher1ood: If you want, and are closeby, I can draw you a diagram on the whiteboard10:53
paulsher1oodlet me phrase this another way... is the issue here 'code style' or 'actual risk of breakage' ?10:54
Kinnisonthe latter10:54
Kinnisonhence: 11:40 < Kinnison> It's just dangerously wrong, rather than annoying10:54
paulsher1oodok, then i need to understand, will get my coffee and think harder. thanks10:54
Kinnison:)10:54
richard_mawhm, mason is confused because it successfully built, but failed to find what it build to do the deploy test10:54
Kinnisonrichard_maw: oops?10:54
richard_mawhttps://mason-x86-64.baserock.org/log/b6cdb33f041fbeab7aba4c2658d5163fe7410871--2015-06-04%2021:27:27.log10:54
Kinnisonrichard_maw: btw, how is your strip-commands topic for morph coming?10:55
richard_mawKinnison: 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
Kinnisoncool10:56
* richard_maw is annoyed by github pull requests10:57
Kinnisonshocking10:57
* richard_maw actually prefers Gerrit10:58
KinnisonOutrageous!10:59
richard_mawpaulsher1ood: pull request sent11:01
paulsher1oodrichard_maw: tvm!11:01
* richard_maw is too annoyed by Github's UI to attach any message to the cover letter11:01
paulsher1oodmerged :)11:02
* richard_maw attempts to locate caffeine11:02
* Kinnison attempts to locate food11:02
ssam2tlsa: regards specifying environment variables for sandboxlib, the run_sandbox() function takes an 'env' parameter11:05
ssam2if 'env' is None or empty then so is the environment in the sandbox11:05
ssam2if it's a dict (in the style of os.environ) then those environment variables are set in the sandbox11:06
tlsaI need to set a couple of environement vaiables in the sandbox, if a particular library is present in the sandbox11:06
ssam2ok, look in sandbox.run_sandboxed() in ybd11:07
ssam2it does 'env = os.environ' in there11:07
tlsaok11:07
ssam2so you can either add the vars to 'env' after that line11:07
ssam2or modify os.environ directly in the clean_env() function (or wherever else) if that's easier11:07
richard_mawjust be careful modifying os.environ, it's a magic dict that modifies your process' environment11:08
richard_mawso pass around copy of it rather than the object itself11:08
ssam2ybd mutates it directly in sandbox.setup()11:09
richard_mawso it mutates the current environment, rather than passing a copy of it to subprocess.Popen?11:15
tlsawould it be OK to run11: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
tlsain the sandbox?11:16
paulsher1oodtlsa: why wouldn't it be?11:21
ssam2richard_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 it11:21
paulsher1oodlooks ok to me?11:21
ssam2tlsa: as long as the libc ABI matches ... I don't know if that would work with musl, for example.11:22
ssam2i don't think we have an alternative though, other than running builds in a VM where the clock never ticks11:22
paulsher1oodssam2: so if (various checks which we learn as folks break them): do what tlsa suggests, else report (can't use libfaketime)?11:23
tlsapaulsher1ood: I don't know, hence the question.  :)11:23
tlsafor one thing, I'd be trampling LD_PRELOAD.  Does anything else about sandboxing use it?  If so what's it doing?11:24
paulsher1oodtlsa: 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 it11:24
richard_mawpossibly a good reason to use the faketime binary instead of setting LD_PRELOAD directly11:24
ssam2paulsher1ood: I fear that's the only approach, yes. But all these condition shell scripts remind me of OpenEmbedded.11:24
ssam2*conditional11:24
ssam2tlsa: nothing in sandboxlib uses LD_PRELOAD right now11:24
tlsaok11:25
paulsher1oodssam2: i am hurt :)11:25
paulsher1oodor maybe i should feel complemented. OE is a very popular project with a long pedigree11:25
ssam2no 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.conf11:27
ssam2but 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 understand11:27
tlsarichard_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 commands11:27
ssam2this may be an unavoidable part of making the tools actually do useful things, of course!11:27
ssam2code and reality never get on very well11:28
paulsher1oodgah.... MY EYES!!!!11:28
* richard_maw tries to work out exactly what language that is written in11:28
paulsher1oodcobol?11:28
*** zoli__ has joined #baserock11:28
richard_mawit's an unholy union of Make, shell and python11:29
*** zoli___ has joined #baserock11:37
*** Krin has quit IRC11:39
*** zoli__ has quit IRC11:40
paulsher1oodradiofree: are you looking at moonshot?11:40
paulsher1oodif you're using ybd you may need latest version11:41
radiofreewhy would i need the latest version?11:41
radiofreemorph built stage2-glibc fine btw11:41
radiofreetrying ybd under baserock now11:41
radiofreedoes the latest version fix that issue?11:42
paulsher1oodradiofree: something was screwy if /src didn't exist11:42
paulsher1oodfixed now (it makes /src if there isn't one)11:42
radiofreethat doesn't seem like a very good fix11:42
paulsher1oodi agree, but it's a fix11:42
radiofreedoes that fix the issue with stage2-glibc?11:43
* paulsher1ood can't remember what that issue looked like11:43
paulsher1oodwhat's the error?11:43
paulsher1oodif it's MSBIND, then yes i think it fixes it11:43
richard_mawpaulsher1ood: issue was a crash on the first build due to mount(MS_BIND) failing11:43
paulsher1ood:)11:43
paulsher1oodi think permissions under /root are different11:44
radiofreeno it's not that issue11:44
radiofreei don't have the log to hand11:44
paulsher1oodok np11:44
paulsher1oodi need to eat anyway11:44
* paulsher1ood heads for biryani11:44
* radiofree will try master in a moment anyway11:44
richard_mawa. 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_mawI have no idea how that works back to not having /src11:45
radiofreei'll do a full build of baesrock on this moonshot (using morph) later actually, just to make sure everything aarch64 is well11:45
paulsher1oodrichard_maw: ack11:45
paulsher1oodradiofree: great!11:45
paulsher1oodrichard_maw: it's a head scratcher, but too deep for me11:47
richard_mawbtw, 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 separately11:47
*** radiofree has quit IRC11:48
*** radiofree has joined #baserock11:49
*** Krin has joined #baserock11:51
rdalewhat is a python .egg package? i can't seem to import on i've just installed12:04
richard_mawKinnison: what is your opinion of my justification for not using pyfilesystem in https://gerrit.baserock.org/#/c/772/ ?12:45
*** zoli___ has quit IRC12:46
Kinnisongiven the utf8 thing, I'm fine with your approach and my +1 stands12:46
*** zoli__ has joined #baserock12:46
richard_mawcool, 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 find12:47
paulsher1oodrichard_maw: would you be willing to put the equivalent into ybd? it looks sensiblbe12:48
*** zoli___ has joined #baserock12:49
richard_mawpaulsher1ood: you've already got your strip-commands patches!12:49
paulsher1oodrichard_maw: lol12:49
paulsher1oodi want the moon on a stick :)12:49
paulsher1oodi'll crib yours and claim i thought of it, then12:49
paulsher1oodrichard_maw: i'm already using the strip-commands patches and everything seems lovely :-)12:50
richard_mawpaulsher1ood: 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 module12:51
paulsher1oodah, my claim of python3? not checked. jjardon suggested it, i'd like it to be true12:51
richard_mawI'm fairly sure you don't btw, I saw a bare print statement, which is forbidden in python312:52
paulsher1oodi found it irritatingly difficult to have python3 on br12:52
*** zoli__ has quit IRC12:52
SotKthat bare print is the only thing I've noticed that would stop it I think12:52
paulsher1oodwhat's the easiest way to try? is anyone running ybd already on a linux with python3?12:53
richard_mawSotK: that's what would make it fail immediately, there's a few more subtle changes involved too12:53
* SotK finds it mildly annoying that ybd has `#!/usr/bin/env python3` when its not quite the case12:53
paulsher1oodSotK: would you like to offer a pr? if not i'll get to it12:54
SotKpaulsher1ood: I'm accumulating a branch of small fixes locally, but feel free to fix it if you have time :)12:55
paulsher1oodok, let's see who gets to it first. i won't be touching ybd myself til after the talk, now. will accept pr though12:57
richard_mawhmm, the tempfile module in python3 doesn't cater too well to the use-case of atomic file/directory creation13:03
Kinnisonquick, port the whole lot to caml13:04
richard_mawer, what?13:04
*** straycat has joined #baserock13:06
pedroalvarezjmacs, 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
pedroalvarezsystemd-timesyncd, i believe13:07
straycatpedroalvarez, because swift nodes need to have their time internally synchronised13:07
jmacsNot immediately, but I could check my notes13:07
richard_mawpedroalvarez: AIUI it's because swift needed one of hte nodes to be an NTP server13:07
richard_mawpedroalvarez: systemd's ntpd is client only13:07
pedroalvarezah,.13:09
pedroalvarezI thought they only needed ntpd runing, to sync the time with a time server, and all of them syncing with the same one13:10
jmacsThe 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
pedroalvarezI see13:11
richard_mawKinnison: 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.py13:16
pedroalvarezok,  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-timesyncd13:22
pedroalvarezhm.. I think that in a 3 nodes deployment of OpenStack, everynode is going to run ntpd13:25
*** Krin has quit IRC13:26
straycatpedroalvarez, yes, but only the controller will run as a time server13:27
straycatthe rest will fetch their time from the controller13:27
pedroalvarezahá13:27
* pedroalvarez continues investigating then :)13:28
pedroalvarezstraycat: is "the rest", "swift storage nodes" ?13:29
pedroalvarezor it will also be network and compute node?13:29
straycatit also includes network and compute, see  http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/install-files/swift/etc/ntp.conf13:31
pedroalvarezoh, I failed to find that file13:32
pedroalvarezstraycat: thanks13:32
straycatnp :)13:32
pedroalvarezgreat13:33
*** Krin has joined #baserock13:34
ssam2Kinnison: I've discovered a repo in a Trove (thankfully an internal one!) where the gitano admin ref is corrupt13:50
ssam2any advice on what to do?13:50
ssam2I get this:13:50
ssam2git cat-file -t refs/gitano/admin13:50
ssam2error: object file objects/92/90a4c6a7838a6f169b26d0d7b6142a36641d11 is empty13:50
ssam2fatal: git cat-file refs/gitano/admin: bad file13:50
jjardonpaulsher1ood: when I made the patch, all the code of ybd was python3 compliant; not sure if changes after make this not true13:50
jjardonBTW, there is a python3 stratum if you want to create a system with it13:51
Kinnisonssam2: Oh dear, that's not good13:51
Kinnisonssam2: 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 empty13:51
Kinnisonssam2: from a shell?13:51
ssam2Kinnison: yes13:51
ssam2(it's ct-mcr-1)13:51
Kinnisonssam2: step one then will be: git update-ref -d refs/gitano/admin13:52
Kinnisonssam2: then ssh git@localhost config repo/path/and/name project.owner $whoevershouldownthis13:52
Kinnisonerm13:52
Kinnisonssam2: then ssh git@localhost config repo/path/and/name set project.owner $whoevershouldownthis13:52
Kinnisonthat13:52
Kinnisonif it's in delta/ then the owner should always be lorry13:52
ssam2ok, thanks13:53
KinnisonIf you have further issues, let me know13: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
ssam2same problem with another repo further down the list...13:58
ssam2maybe this is a bug in commit 4b8ce6875266fdd6609a217dcf2924d7d4815cc2 of gitano...13:58
ssam2(or earlier)13:58
* Kinnison hmms and looks14:03
Kinnisonthat's not a commit of gitano14:04
ssam2right, it's http://git.baserock.org/cgi-bin/cgit.cgi/delta/gitano/gitano.git/commit/?id=4b8ce6875266fdd6609a217dcf2924d7d4815cc214:04
ssam2maybe that's BR-specific14:04
ssam2actually, this Trove is old and unloved, but was updated a month or two ago14:05
ssam2so the ref of Gitano that it's currently using isn't so relevant, the breakage could have been caused before it was upgraded14:05
ssam2or by something during the upgrade14:05
ssam2ignore me :)14:05
* Kinnison has never had any other gitano instance have this kind of issue14:06
Kinnison*but* troves are among the heaviest gitano users14:06
rjekISTR a trove here getting into an awful mess with similar-sounding git errors when a btrfs got full once14:07
radiofreeso ybd thinks it's building arm3214:08
radiofreechecking linker output format... elf32-littlearm14:08
radiofreeprobably due to some armv8l64 -> aarch64 confusion14:08
paulsher1oodradiofree: what command line did you give it/14:09
radiofreeybd systems/build-system-armv8l64.morph armv8l6414:09
KinnisonIf ybd isn't setting the target arch environment right it could be a problem14:10
radiofreepaulsher1ood: this is the same issue you had the other day http://paste.baserock.org/ateyezikod#39414:10
radiofreeline 39414:10
radiofreeyes, forcing the arch in the system/command line to aarch64 works14:14
radiofreeat least we know what it is now14:15
* radiofree prods things14:15
radiofreedoes gcc get the target from the first bit of the TARGET env?14:23
radiofreee.g AARCH64-this-can-be-whatever-it-doesnt-matter14:23
*** zoli___ has quit IRC14:28
Kinnisonssam2: the commit you mention doesn't touch repo.lua which is pretty much the only place that ref is mangled14:29
Kinnisonssam2: I'd be willing to bet it's an FS corruption or similar14:29
* Kinnison is surprised gitano didn't repair it though14:29
Kinnisonnormally it tries to repair (even if by replacement) the adminref14:31
*** zoli__ has joined #baserock14:35
radiofreepaulsher1ood: i take it you're supposed to be allowed to do ybd system/system-armv8l64.morph aarch64 ?14:42
radiofreeit doesn't work anyway, i think i'll just do the same mapping morph does14:42
ssam2Kinnison: does https://gerrit.baserock.org/#/c/790 look ok for the 'allow pushing tags in mirrored repos' patch we talked about?15:03
Kinnisonsee comments15:05
ssam2thanks15:07
*** jonathanmaw has quit IRC15:12
franredOpenstack in Baserock Kilo tempests results: Running Api tests: Ran 1121 tests in 6572.448s FAILED (failures=11) Skipped 14315:12
franredServices: Ran 26 tests in 49.197s FAILED (failures=1) Skipped 615:12
KinnisonGetting close15:13
franredcmd: Ran 1 test in 3.584s No failures Skipped 115:13
pedroalvarezreally close :)15:13
franredcli: Ran 33 tests in 45.029s No failures Skipped 115:13
franredscenario, stress and thirparty are not configured at the moment15:13
franredto run any test for them15:13
franredyeah, pretty pretty close :)15:14
*** Krin has quit IRC15:34
*** Krin has joined #baserock15:46
richard_maw\o/ mason is green again15:46
SotKat last!15:46
richard_mawbuild started at midnight, duration 52883s15:47
pedroalvarezthat is because it builds 4 times every chunk15:50
paulsher1oodradiofree: i don't know, the aarch stuff is a mystery to me still15:51
radiofreepaulsher1ood: i like the idea of having it as a command line option, but it's a bit useless at the moment15:52
radiofreealthough, since we don't cross compile it's always going to be useless?15:52
radiofreee.g you'll never be able to do ybd build-system.morph armv715:52
radiofreeon x8615:52
*** Krin has quit IRC15:53
radiofreepaulsher1ood: make fails16:04
* radiofree will check morph can build it16:05
radiofreebuilds using morph, could be the aarch change, test again16:33
*** CTtpollard has quit IRC16:53
*** bashrc_ has quit IRC17:03
*** edcragg has quit IRC17:09
*** gary_perkins has quit IRC17:10
radiofree2015-06-05 17:02:47 [stage2-make] Elapsed time 00:00:1917:25
radiofreeas good a place to leave it as any i think17:25
*** mariaderidder has quit IRC17:25
*** ssam2 has quit IRC17:36
*** zoli___ has joined #baserock17:50
*** zoli__ has quit IRC17:54
*** zoli___ has quit IRC18:03
*** lachlanmackenzie has quit IRC18:33
*** zoli__ has joined #baserock20:04
*** zoli___ has joined #baserock20:06
*** zoli__ has quit IRC20:10

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